AIに実装をお願いすると、数分でコードが返ってきます。ところが画面を見た瞬間、手が止まる。「動くのはわかる。でも、なぜこの形なのかがわからない」。そんな経験はありませんか。
先輩に「ここ、どうしてこうしたの?」と聞かれて答えられず、気まずい沈黙が流れる。実装は速くなったはずなのに、レビューで詰まって結局遅い。入社1〜3年目のエンジニアが、いまいちばん多くぶつかっている壁です。
結論から言います。AIが書いたコードが理解できない原因の多くは、読む力ではなく、頼む前の準備にあります。この記事では、なぜコードがふくらむのかという仕組みと、依頼前と読む前にはさむ2つの手順を紹介します。読み終わるころには、明日の実装依頼の書き方が変わっているはずです。
AIが書いたコードが理解できないのは、読解力の問題ではない
まず前提を1つ変えましょう。読めないのは、あなたの読解力が足りないからではありません。読む側の想定より、コードのほうが大きくなっているからです。
人がコードを理解するとき、頭の中では「この部分は何のためにあるのか」を1つずつ確かめています。役割がわかれば、次の行に進める。ところがAIが返してくるコードには、あなたが頼んだ覚えのない部品がまじっています。役割を確かめようとしても、そもそも自分の想定に無い部品なので、答えが見つかりません。
Qiitaで話題になった新卒エンジニアの記事も、まさにこの構造を指摘しています。実装の時間は短くなっても、理解の時間が伸びれば、開発全体としては速くなっていない、と。
つまり問題は「読み方」ではなく「渡ってきたものの大きさ」です。ここを取りちがえて読解のコツばかり探すと、いつまでも解決しません。
この「速くなったはずなのに、全体では速くなっていない」という感覚には、実際に測った調査があります。研究機関のMETRが2025年に公開した無作為化比較試験では、大規模なオープンソースの開発に慣れた16人が、実際の課題246件に取り組みました。結果は、AIツールを使ってよいときのほうが完了までに19%長くかかるというものでした（参考リンク3）。
さらに示唆的なのは、開発者自身の見立てです。開始前は「24%速くなる」と予想し、実際には遅くなったあとでも「20%速くなった」と答えています。速くなった感覚と、実際にかかった時間は、ずれることがあるわけです。読む時間が伸びていることに自分では気づきにくいのは、これが理由だと考えられます。
なおこの調査の対象はベテラン開発者で、新人にそのまま当てはまるとは限りません。ただ「実装は速いのに、全体では遅い」という形は共通しています。
AIコードがふくらむ原因は「今回やらないこと」を伝えていないから
ではなぜ、コードは頼んだ以上にふくらむのでしょうか。理由は単純で、AIは範囲を伝えられないと「将来も困らない形」を選ぶからです。
先ほどのQiita記事では、CSV出力機能がわかりやすい例として挙げられていました。「CSVを出力したい」とだけ頼むと、AIは親切に、複数の形式に対応できるしくみ、非同期での処理、ファイル保存の機能まで用意してくれます。どれも間違いではありません。ただ、今回は要らないのです。
この「先まわりして作りすぎる」状態を、オーバーエンジニアリングと呼びます。必要以上に手のこんだ作りにしてしまうこと、という意味の言葉です。
身近な例で言えば、こういう感じです。友人に「明日の弁当を1つ作って」と頼んだら、冷凍で1か月保存できる作り置きが10食分と、専用の保存容器と、解凍手順書まで返ってきた。ありがたいけれど、明日の1食ぶんがどれなのかは、もうわかりません。
コードでも同じことが起きます。各クラスの役割は説明できるのに、なぜそれが必要なのかは判断できない。結果としてAIに何度も質問し、そのたびに時間と利用料が増え、レビューでの指摘も増えていきます。
対策1: AIへの依頼前に「今回やらないこと」を先に決める
いちばん効くのは、依頼を書く前に、扱わない範囲を自分の言葉で決めておくことです。
理由は、判断の基準が手元にできるからです。基準があれば、返ってきたコードを「ただ読む」のではなく「これは基準の中か、外か」と評価できます。読む作業が、探索から確認に変わるわけです。
具体的には、依頼の前に次の3つをメモします。長い文章は要りません。3行で十分です。
- 解決したい課題は何か(例: 経理が手作業で集計している)
- 今回どこまで実現するか(例: 一覧をCSVで出せればよい)
- 今回は扱わないこと(例: CSV以外の形式、非同期処理、保存機能)
そして、このメモをそのまま依頼文に貼りつけます。「今回は扱わない」の行があるだけで、返ってくるコードの量は目に見えて変わります。
この3行は、決めた理由まで書き足せば、そのまま設計の記録になります。判断の経緯を残す文書の書き方はDesign Docとは?できる人ほど書いている「代替案と懸念点」でも紹介しているので、あわせて読んでみてください。
小さくまとめると、依頼前の3行は「AIへの指示」であると同時に「未来の自分への説明メモ」です。
対策2: AIコードを読む前に「中学生向けの図解」を作らせる
すでに大きなコードを前にしている場合はどうするか。ここでも、いきなり読み始めないのが正解です。読む前に、AIへ全体像を1枚にまとめさせます。
Zennで話題になった記事では、こんな頼み方が紹介されていました。「この処理のしくみを、中学生でもわかるように、図解も入れて1枚のHTMLにまとめてください」。著者はこの方法で、2,000行を超えるクラスの全体像を5分で把握できたと書いています。
この頼み方には、3つの制約が効いています。
- 「中学生でもわかるように」→ 専門用語が使えなくなり、しくみの骨格だけが残る
- 「1枚に」→ 全部は入らないので、重要な部分が選ばれる
- 「図解も入れて」→ 部品どうしのつながりが目で見える形になる
むずかしい話を小学生や中学生にもわかる言葉で説明させる考え方は、ELI5とは?むずかしい話を10歳の子に説明する技術で詳しく扱っています。相手の年齢を変えるだけで、同じコードから説明資料を何種類も作れるのも便利なところです。
要するに、地図を持ってから歩き出す、というだけの話です。順番を変えるだけで、読む時間は大きく縮みます。
考察: 理解できないAIコードは「書いた人の負債」になる
ここからは筆者の考えです。この問題を放っておくと、困るのはレビュアーではなく、書いた本人だと思っています。
コードは書いた瞬間から、直され続ける対象になります。半年後に不具合が出たとき、最初に呼ばれるのは、そのコードをコミットした人です。そのときAIが作った部品の意図を説明できなければ、調査は毎回ゼロからになります。
もっと言えば、説明できないコードは、あなたの実績としてカウントされません。「作った」ではなく「通した」だけになってしまうからです。新人のうちは、実装量よりも「なぜそうしたかを言えるか」で評価されます。ここは1年目でも3年目でも変わりません。
逆に言えば、依頼前の3行を残す習慣は、そのまま自分を守る記録になります。時間をかけるべきは、生成のあとではなく前です。
新人エンジニアが今日から試せるAIコード理解の3ステップ
最後に、明日の業務にそのまま持ち込める手順にまとめます。順番が大事なので、上から実行してください。
- 依頼前: 課題・今回の範囲・今回やらないこと、を3行でメモして依頼文に貼る
- 受け取り後: 読み始める前に「中学生でもわかるように図解して」と頼み、全体像をつかむ
- レビュー前: メモの範囲を超えている部品を洗い出し、必要か不要かを自分で判断する
3つ目までやると、レビューでの受け答えが変わります。「AIがそう書きました」ではなく「この部分は今回は不要と判断して外しました」と言えるようになるからです。
なお、こうした使い方の差はチーム内の力の差にもつながります。関心があればAIディバイドとは?生産性3倍の裏でチームが壊れた話もどうぞ。
まとめ
- AIが書いたコードが理解できない原因は、読解力ではなく「今回やらないこと」を伝えていないことにある
- 依頼前に、課題・範囲・扱わないことを3行で決めると、返ってくるコードが自分の想定内におさまる
- すでに大きいコードは、読む前にAIへ「中学生でもわかる1枚の図解」を頼むと全体像を短時間でつかめる
まずは次の実装依頼で、「今回は扱わないこと」の1行を足すところから始めてみてください。
コメント
コメント一覧 （1件）
[…] この構造は、コードそのものにも同じことが言えます。生成物を自分の言葉で説明できるかという論点はAIが書いたコードが理解できない｜原因は読み方より依頼前の準備でも扱いました。テストはその延長線上にあります。 […]