この記事で言いたいこと
Claude CodeやGitHub Copilotに仕事を頼むと、コードが出てくる前に、AIがぶつぶつと「独り言」を話します。
エラーメッセージを確認します。
TypeError: Cannot read properties of undefinedなので、まずこの変数がどこでundefinedになるかを特定します。呼び出し元を検索して……
多くの新人エンジニアは、この部分をスクロールで読み飛ばして、最後に出てくるコードだけを見ています。
GitHub Copilotで独り言が見えるのは、チャットやエージェントモードのときです（タブ補完では見えません）。未体験の方は、エージェントモードで簡単なバグ修正を頼んで、コードが出る前の出力を観察してみてください。この記事の内容が3分で体感できます。
もったいない。捨てているのはそこじゃない方です。
熟練エンジニアにとって、AIの独り言は「当たり前のことを速くやってるだけ」に見えます。でも経験の浅いエンジニアにとっては、普段は絶対に見られない「できる人の頭の中」が、日本語で実況中継されている状態です。
私はSIerで後輩の面倒を見る立場ですが、最近は「AIの答えをコピペするな」に加えて「AIの独り言を読め」と言うようにしています。この記事はその理由の説明です。
先輩の頭の中は、普段は見えない
隣の席の先輩がバグを10分で直したとします。あなたに見えるのは、直ったという結果だけです。
- なぜ最初にログを見たのか
- なぜあのファイルを開いたのか
- なぜ2つの仮説のうち片方を先に試したのか
この「なぜ」は先輩の頭の中にあって、外からは見えません。先輩も無意識にやっているので、聞いても「なんとなく」としか返ってこないことが多い。
ところがAIエージェントは、この過程を言語化しながら作業する設計になっています。つまりAIの独り言とは、熟練者が無意識にやっている判断に相当するものが、日本語で書き出されている状態です。
実例：バグ修正を頼んだときの独り言を分解する
Claude Codeにバグ修正を頼むと、毎回だいたいこういう独り言が流れます。典型的な流れを、学びポイント付きで分解してみます。
AI: まずエラーメッセージ全体を確認します。スタックトレースの最下部ではなく、自分のコードが最初に登場する行を見ます。
📝 学び: スタックトレースは「自分のコードが出てくる行」から読む。ライブラリ内部の行で悩まない。新人が最初につまずくポイントを、AIはさらっと通過しています。
AI: エラーの再現条件を確認します。テストを実行して、失敗することを先に確かめます。
📝 学び: 直す前に「壊れていることを確認する」。これをやらないと、直ったのか元々動いていたのか区別できません。当たり前に見えて、焦っているときほど飛ばしがちな手順です。
AI: 修正候補は2つありますが、影響範囲の小さい方から試します。まずこの関数だけを変更して、テストが通るか確認します。
📝 学び: 修正は「小さい方から」。一度に複数箇所を変えると、どの変更が効いたのか分からなくなります。
AI: テストが通りました。ただし同じパターンが他にもないか、この関数の呼び出し元を全て検索して確認します。
📝 学び: 直して終わりにしない。「同じ間違いが他にもないか」を疑うのは、レビューで先輩がよく指摘するやつです。
どうでしょうか。1つ1つは基本動作です。表にするとこうなります。
| AIの独り言 | 隠れている基本動作 |
|---|---|
| エラー全体を確認します | スタックトレースは自分のコードから読む |
| 失敗することを先に確かめます | 直す前に「壊れていること」を確認する |
| 影響範囲の小さい方から試します | 修正は小さく、1つずつ |
| 呼び出し元を全て検索します | 直して終わりにしない |
「基本動作が正しい順番で並んでいる完全な見本」を、新人が現場で見られる機会はほとんどありません。AIは頼むたびに毎回これを見せてくれます。
実例：実装を頼んだときは「作る前」に注目する
新規実装を頼んだときは、コードを書き始める前の独り言が一番おいしい部分です。こんな動きをよく見かけます。
AI: 実装の前に、既存のコードでどう書かれているかを確認します。類似の機能を検索して、命名規則とエラーハンドリングのパターンを揃えます。
これ、新人がやらなくて一番怒られるやつです。「いきなり書き始めない。まず周りを見る」。AIは毎回これをやります。
AI: この要件は2通りに解釈できます。A案は〜、B案は〜。今回は既存の仕様との一貫性からA案で進めますが、意図が違う場合は指摘してください。
要件の曖昧さに気づき、解釈を明示し、判断の根拠を添えて確認する。報連相のお手本みたいな動きです。
独り言を「教材」に変える3つの使い方
読むだけでも学びになりますが、少し能動的にすると効果が上がります。
1. 次の一手を予想してから読む
AIが「エラーを確認します」と言った時点で一時停止して、「自分なら次に何をするか」を考えてから続きを読みます。予想が外れた箇所が、そのままあなたの伸びしろです。
2. 「なぜ」を聞き返す
独り言で気になった判断があったら、そのまま聞きます。「なぜ影響範囲の小さい方から試したの？」と聞けば、AIは判断基準を説明してくれます。先輩と違って、何回聞いても嫌な顔をしません。
3. 独り言メモを作る
「へえ」と思った手順を1行メモしておきます。私の場合、「直す前に壊れていることを確認する」「書く前に周りのコードを読む」など、数週間で自分用のチェックリストができました。これは実質、熟練者の作業手順書です。
正直に書いておくこと
万能ではないので、注意点も書きます。
- AIの独り言は、後付けの説明であることがあります。 これは私の感覚ではなく、Anthropic自身の研究「Reasoning Models Don't Always Say What They Think」（2025）で示されている話です。独り言は「参考になる思考例」であって「正解の証明」ではない。気になる方は論文名で検索して、一次情報を確認してみてください
- 独り言ごと間違えることがあります。 自信満々に間違った仮説を検証し始めることも普通にあります。むしろ「間違った仮説を立てて、検証して、棄却する」流れが見られたときは、それ自体が一番いい教材です
- 読んでいるだけでは書けるようになりません。 野球の解説を全部聞いてもヒットは打てないのと同じで、最後は自分の手で書く時間が必要です
まとめ
- AIエージェントの独り言は、熟練者の暗黙知が言語化されたもの
- コードという「結果」より、独り言という「過程」の方が、新人にとっての情報量は多い
- 予想して読む、なぜと聞く、メモに残す。この3つで独り言は教材になる
- ただしAIの説明は後付けの可能性があるので、鵜呑みにはしない
AIに仕事を奪われることを心配する前に、まずAIから仕事のやり方を盗みましょう。しかも相手は、盗まれても文句を言いません。