わたしの Claude Code ログを集計してわかった、バイブコーディングで役立ちそうなフレーズ集

ふと「自分は Claude Code に何を喋っているのか」が気になり、~/.claude/projects/ 配下の JSONL を全部舐めて集計してみました。

• 対象: 12,187 件の user message
• 元データ: 2,231 ファイル / 1.9GB
• 期間: バイブコーディング始めてからの全履歴

集計した中から、短いのに繰り返し使っていて効いていたフレーズだけ抜粋します。

前提：どんな使い方をしているときの話か

わたしの Claude Code の使い方には大きく 2 つあります。

(A) goal を与えて自律で回すモード IDD（Issue Driven Development）で issue を書き、ralph-loop に prompt.md を渡して放置するスタイル。実装系の重い仕事はだいたいこっち。ここで使う言葉は 「Definition of Done」「スコープ限定」 みたいなプロンプト技術の世界で、今回のフレーズ集の話とは別物。

(B) 画面の前で逐次やりとりするセッションモード マンガ制作、ちょっとした PoC、思いつきの調査、設定いじり、文章書きなど。画面を見ながら細かく方向を直していく仕事。今回扱うフレーズ集はこっちで効くやつです。

今回集計した 12,187 発言の大半はこの (B) セッションモード由来。ralph-loop の prompt 本体（長文の指示書）はそもそも短いマクラを使わないので、集計対象を「30 文字以内」に絞ると自然に (B) のフレーズが浮き上がってきました。

つかみ：否定と承認、ほぼ拮抗していた

カテゴリ別に件数を出したら、否定系と承認系がほぼ並んでいました。

系統	内訳	合計
否定	違う 612 / ダメ 381 / 止めて 269 / 戻して 105 / やめて 21	1,388
承認	OK 511 / はい 499 / なるほど 321 / いいね 81 / わかった 81	1,493

差 105。誤差。

集計し終わった Claude 本人にコメントを求めたら、こう返ってきました。

5 回褒めるごとに 5 回ちゃぶ台返してる人。

しかも完全一致 Top で「いや」が 6 回ランクインしてるの、たぶん会話のマクラとして反射で出てるやつ。

否定が悪いというより、セッションモードは短い修正指示で方向を細かく直し続ける営みなので、否定語が多くなるのは構造的に妥当だと思います。

実用フレーズ集（セッションモード向け）

ここから本題。実際の使用回数と、自分の体感での効き方をセットで。

注: ここから先はわたし個人の使い方と感想です。同じフレーズが他の人に効くかは分かりませんし、モデルや時期によっても変わると思います。「自分の場合はこういうことを考えながら使っていた」 くらいの読みかたで。

速度を稼ぐ系（コンテキストを節約する）

短い相槌が多いのは、Claude が言うように半分はマクラの反射ですが、もう半分はコンテキスト削減を狙って意図的に短くしている部分もあります。LLM は会話履歴全部を毎回読み直すので、こちらの 1 トークンも積もると効いてくる。意味が変わらないなら短い方が常に得。

フレーズ	出現回数	効く理由
「はい」「OK」「go」	427 / 124 / 22	直前の提案を承認。1〜2 文字でコンテキストを汚さない
「すすめて」「つぎ」「続きを」	15 / 7 / 6	文脈を引き継いで次へ。OK より「次のステップに進め」が明確に伝わる
「じゃあそれで」	7	候補から 1 つを選んだことを明示
「みせて」	9	diff / 画面 / 結果を出させる。確認して より受動的でいい

ダラダラした承認文より、短く / 連打可能 / 意図が一意な語の方が良いマクラ。

結果を見て決める系（決定を遅延させる）

これがセッションモードの中核だと思っています。最初から決めない。試して結果を見て決める。

フレーズ	出現回数	効く理由
「とりあえず〜で」	135	「これは仮、後で直す」が明示的に伝わる。エージェントの過剰な作り込みを抑制
「試しに〜」「いったん挑戦してみて」	—	不確実な案を試行モードで走らせる。失敗しても怒らない宣言
「やってみて」「任せる」	31 / 51	設計判断を委ねて、出てきた結果に対して判断する

決定権をいったん AI に渡して、出てきた成果物を見てから自分が判断する。これでバイブコーディングの速度が出ます。

「とりあえずおすすめで」「とりあえず進めよう」のように、決定そのものを遅延させる宣言として機能している。エージェントは「全部完璧にやり切ろう」とする傾向があるので、仮置きを明示的に許可するフレーズが要るわけです。

暴走を止める系

フレーズ	出現回数	効く理由
「いったんやめて」「止めて」	269	中断 → 状況整理。「やめて」単体だと全廃棄に行きがちなので 「いったん」が効く
「なんで？」「なんで X しないの」	—	エージェントが省略した根拠を引きずり出す。設計判断のミスを掘り当てる
「戻して」	105	直近の変更だけロールバック。git revert より柔らかく文脈付きで戻せる

「なんで？」系は、エージェントが自信ありげに省略している部分を露出させるのに役立っている気がします。実例：

• 「なんで 891 行だけ削らないの」
• 「じゃあなんで agent に保存してるの」
• 「なんで？7 件とか絞るの？誰が決めるの」

エージェントが勝手に決めたパラメータを疑うときに自分はよく使っています。

無知を武器にする系（知らないと言って方法を引き出す）

「知らない」395 回、「わからない」71 回。これが実用フレーズとして効くという話。

フレーズ	出現回数	効く理由
「知らない」	395	知ったかぶりせず無知を宣言すると、エージェントが方法から説明してくれる
「説明して」	65	出力にギャップを感じたら立ち止まる。先に進むより理解を取る
「教えて」	285	用語・前提・全体像を引き出す

実例：

• 「いや知らない。初めて触る」
• 「マーケティングを全然知らないから何ができるのかもわからない」
• 「bwrap を詳しく教えて」

バイブコーディングでは自分の知らない技術を呼んで動かす場面が多発します。そこで知ったかぶると、エージェントが「知ってる前提」で進めて噛み合わない出力を返してしまうことがある。「知らない」と明示すると、エージェントが前提・周辺知識・選択肢から出してくれるように感じています。無知を武器にすると言ってもいいかもしれない。

ゴールとインテントに戻す系（質問攻めへの対処）

エージェントが細かい分岐を聞いてきたときに、個別判断には付き合わない戦術。

渡すもの	内容
ゴール	最終的に何が出来上がっていたいか（What）
インテント	どういう方向性・思想にしたいか（Why / How なに重視で）

この 2 つだけ渡せば、細かい判断はエージェントが自分で決められる。

具体例：

• エージェント「A/B/C/D どれにしますか？」
• 自分「やってみて結果を見て決める」（→ 結果を見て決める系に接続）
• 自分「最終的には X したい。優先は速度。あとは任せる」（→ ゴールとインテント宣言）

質問が多いと感じたら、それはエージェントがゴール/インテントを掴めていないサインかもしれない。個別質問に 1 つずつ答えるより、ゴールとインテントを言い直した方が、自分の場合は結果的に速いことが多い気がします。

方向修正のマクラ（部分修正のスコープを絞る）

フレーズ	出現回数	効く理由
「ちがう。〜」	612	1 単語で否定して具体を 1 行で足す。長い修正指示より速い
「やっぱり〜」	93	前の自分の指示を撤回。エージェントは前指示に引っ張られるので明示が要る
「なんか〜じゃない？」	186	違和感を渡して検討させる。原因まで自分で言わなくていい
「ちょっと X が違う」	307	スコープを X に限定。全体を作り直されない

「ちょっと」307 回がここまで多いとは思っていませんでした。全体修正させたくないときの絞り込みワードとして無意識に使っていたようです。

A/B 選択系（番号で答えられる質問にさせる）

フレーズ	出現回数	効く理由
「A で」「A かな」	13 / 4	提案された選択肢への即決
「日本語は B、英語は A で」	—	軸を分けて両方採用

コツは、先にエージェントに番号付き選択肢を出させること。「A/B/C どれにする？」と書かせれば、回答は 1 文字で済む（= コンテキスト削減）。

区切る系（変更を固定する）

フレーズ	出現回数	効く理由
「コミットして」「プッシュして」	4 / 10	動作確認後の固定。ここで切らないと変更が膨らんで rollback できなくなる
「いったんコミットか」	—	自問形式で投げると、エージェントが「コミットしましょうか」と確認する間を作れる

三種の神器：「いったん」「とりあえず」「やっぱり」

実用フレーズを並べていて気づいたのが、この 3 つは全部「エージェントの完璧主義に歯止めをかける」言葉だということ。

• いったん — スコープを時間で区切る（後で続きをやる）
• とりあえず — クオリティを下げる宣言（後で直す）
• やっぱり — 過去の自分を撤回する権利（決定は揺らぐ）

エージェントは指示を真面目に受け取り、「より良い実装」を考え続けて止まらないことがあります。この 3 つは、未完成のまま前に進む権利をユーザー側が明示するためのトリガーになっていました。

ralph-loop の prompt.md にはこの 3 つは書きません（書くと自己増殖して止まらなくなる）。セッションモードで人間が舵を握っているとき限定の道具です。

バイブコーディングの原本と比べてみると

そもそも「バイブコーディング」という言葉は、Andrej Karpathy が 2025 年初めに放ったツイートが原本です。曰く——コードの存在を忘れてノリに身を任せ、"Accept All" を押し続けて diff はもう読まない。エラーが出たら中身を見ずにコピペで投げ返す。直らないバグは適当な変更を頼んで消えるまで繰り返す（"I 'Accept All' always, I don't read the diffs anymore"）。

集計した自分の発言を、これと並べてみます。

同じところ: わたしもコードはほとんど読んでいません。出てきた diff を一行ずつ追ったりしないし、提案が来たらまず受け入れる。ここは原本どおりの vibe coding です。

違うところ: 受け入れ方が 「とりあえず」 なこと。確定ではなく、仮で受ける。そして違和感が出たら——「ちがう」612 回、「戻して」105 回、「やっぱり」93 回——安く巻き戻す。Karpathy の受け入れは確定で後戻りの概念がないけれど、わたしの受け入れは未確定のまま進む。違うのは、ほぼこの一点だけです。

そしてこの差が効く理由を、原本自身が言い当てています。Karpathy はあのツイートを 「It's not too bad for throwaway weekend projects（使い捨ての週末プロジェクトなら悪くない）」 と、適用範囲を週末の遊びに自分で限定していた。確定で受け入れて突き進む以上、捨てられる規模でしか回せないからです。

ところがわたしは、同じ「コードを見ない・受け入れる」を、マンガ制作や一年がかりの PoC みたいな捨てられない本番で回し続けている。それを可能にしていたのが、この「とりあえず受けて、ダメなら安く戻す」という決め切らなさでした。さっきの「いったん・とりあえず・やっぱり」は、まさに受け入れを仮に留めておくための道具だったわけです。

冒頭の「5 回褒めて 5 回ちゃぶ台返し」も、こう見ると違って見える。優柔不断の記録ではなく、仮で受けては安く戻す、を高速で回していた痕跡なんだと思います。

おまけ：集計で発覚した自分のヤバ事実

実用パートは以上ですが、集計してて笑った発見をいくつか。

完全一致 Top の謎ランキング

30 文字以内の完全一致だけで集計した Top：

件数	フレーズ
427	はい
124	OK
22	go
19	そうね
15	すすめて
14	確認して
13	なるほど
11	いいね
10	プッシュして
9	みせて
7	じゃあそれで / つぎ / どう？

「go」が 22 回。コードレビューじゃなくて競馬の合図。

集計を見ての Claude の感想

集計結果を Claude に見せたときの感想を引用しておきます。

「ちがう render するのはあなたの仕事」

これ単体でマンガのオチになる。

バイブコーディングは、こういう発言が許される時代になったということです。

まとめ

セッションモードでバイブコーディングを進めるときに自分が意識していることを、データから言語化してみると次のあたり：

• コンテキストを節約する。承認は短い相槌で済ます（「はい」「go」「すすめて」）
• 決定を遅延させる。最初から決めず「試しに / とりあえず」で結果を見て決める
• 知らないことは知らないと言う。エージェントが方法から説明してくれる
• 質問攻めにはゴールとインテントで返す。個別判断に付き合わず、最終目標と方向性だけ渡して任せる
• 方向修正は短く。「ちがう」「ちょっと」「なんか」でスコープを絞る
• 「いったん」「とりあえず」「やっぱり」 で完璧主義に歯止めをかける

そして全部を一言にすると——コードは見ない、とりあえず受け入れる。そこは Karpathy の原本どおりの vibe coding。違うのは受け入れを「仮」に留めて、ダメなら安く戻すこと。その決め切らなさが、週末の使い捨て向けだった vibe coding を、本番で回せるものに変えていた。これが 12,187 発言を見直して出た、わたしのバイブコーディングの結論です。

くりかえしになりますが、これがどこまで効くかは正直わかりません。同じ言葉でもモデルや時期で挙動が変わるし、人によって合う言葉も違うはず。あくまで「12,187 発言を見直したら自分はこういう癖でやっていた」という個人的な観察記録として読んでもらえると。

ralph-loop で goal を放り投げるモードとは語彙が違う、という点だけ要注意です。

集計スクリプトは ~/.claude/projects/ を舐めるだけの単純な Python なので、似たことやってみたい人は雑に書けます。