生成AIを使ってコードを書く機会が増えました。 実装、テスト、リファクタリング、設計の壁打ち。 さまざまな場面で生成AIは力を発揮してくれます。
一方で、出てきたコードを見て、こう思うこともあります。 「動きそうではある。でも、よくわからない」 「説明を読めばなんとなくわかる。でも、自分の言葉では説明できない」 「レビューで聞かれたら、『AIがそう書いたからです』としか言えないかもしれない」
会社のコードとして扱うなら、「AIが書いたから」という言い訳は通用しません。 半年後、真夜中の障害対応で、そのコードを開く誰かがいるからです。
この記事では、生成AIが書いたコードが「わからない」ときに、自分の言葉で説明できる状態に近づけるための考え方を整理します。
「わからない」とは、まだ分けられていない状態である
植物に詳しくない人が野原を見たとします。 そこにはいろいろな草や花が生えています。 けれど、植物の名前を知らなければ、それらはまとめて「雑草」に見えます。 実際にはカタバミ、オオバコ、タンポポと違う植物があるはずなのに、まだ区別できない。
コードがわからないときも同じです。 AIが出したコードがひとかたまりに見える。 しかし実際にはそこには、入力チェック、データ取得、条件分岐、変換、API呼び出し、例外処理、設計上の判断などが詰まっています。
つまり「わからない」とは、対象を意味のある単位にまだ分けられていない状態です。 「理解する」とは、ひとかたまりに見えていたものを意味のある単位に分けられるようになることです。
わからなさを5つに分けて、AIへの聞き方を変える
雑に「このコードを説明して」と聞くだけでは、わかった気になりやすい。 大切なのは、自分が何をわかっていないのかを分けたうえで聞くことです。
この記事では、コード理解で起きやすい「わからなさ」を5つに分けて見ていきます。
わからない
├─ 全体像 ........... 何のため？ 入力と出力は？
├─ 個々の役割 ....... この関数は？ この変数は？
├─ 順番 ............. 何が先？ 何が後？
├─ 筋 ............... なぜこの順番？
└─ 自分の言葉 ....... 別表現に置き換えられるか
1. 全体像がわからない
このコードは何のためにあるのか。 何を入力として受け取り、何を出力するのか。 地図で言えば目的地がわからない状態です。
このコード全体の目的を説明してください。
入力、処理、出力に分けて整理してください。
成功時と失敗時にどう振る舞う想定かも教えてください。
ここで一番大事なのは、自分がもともと実現したかったこととAIの実装がずれていないかを確認することです。 そもそも目的が違っていれば、その後の細かい理解はあまり意味がありません。
2. 個々の役割がわからない
知らない関数、変数、構文、ライブラリがあるときは、それらの役割を聞きます。
この関数は何をするためのものですか？
この条件分岐は何を判定していますか？
このライブラリ関数の一般的な使い方もあわせて説明してください。
「コード内での役割」と「一般的な意味」の両方を聞くと、知識と文脈がつながります。
3. 順番が追えない
処理の流れがわからないときは、具体値を入れて説明してもらいます。
具体例として userId = 10 が渡された場合に、
上から順番に、各行でどの変数がどう変化するかを説明してください。
抽象的な説明でピンとこなくても、具体値で追うと流れが見えます。
userId = 10
↓
バリデーション
↓ 10 は数値、OK
DB取得
↓ { id: 10, name: "田中" }
変換
↓ { user_name: "田中" }
レスポンス
↓ 200 OK { user_name: "田中" }
AIの説明だけでなく、自分でもデバッガやログで値の変化を追うとさらに理解が進みます。
4. 筋が通らない
順番は追えた。 でも、なぜその順番なのか納得できない。 これが一番厄介な「わからなさ」です。
順番がわかるとは「何がどの順番で起きるか」を追えること。 筋が通るとは「なぜその順番なのか」を説明できること。
[順番がわかる]
バリデーション → DB取得 → 変換 → レスポンス
[筋が通る]
バリデーション
↓ 不正な値でDBアクセスしないため
DB取得
↓ 画面の表示形式に合わせるため
変換
↓ 呼び出し元との契約を満たすため
レスポンス
このとき、AIには代替案と比較してもらうのが有効です。
なぜ先にバリデーションしてからDBアクセスしているのですか？
逆の順番にした場合、どのような問題がありますか？
代替案と比較して説明してください。
「なぜこれなのか」は「ほかではなぜだめなのか」とセットで考えると見えやすくなります。
5. 自分の言葉になっていない
コードを見ながらであれば、なんとなく説明できる。 でもコードから離れると説明できない。
この状態を抜けるには、別の表現に置き換えてみます。
コードを読まない人にも伝わるように日本語で説明してください。
疑似コードにしてください。
テストケースに落とすとどうなりますか？
ここで大事なのは、AIの説明をそのままコピーするのではなく、自分で言い直してみることです。 言い直せないところがあれば、そこがまだ理解できていない部分です。
AIの説明は「答え」ではなく「仮説」として扱う
AIの説明は常に正しいとは限りません。 もっともらしいけれど、コードと照らすと違っていることもあります。 ライブラリの仕様を取り違えていることもあります。
だからAIの説明は「答え」ではなく、「理解を進めるための仮説」として扱うのがよいと思います。
説明させる。
コードと照合する。
具体値で追う。
小さく実行して確かめる。
この過程を通すことで、AIの出力は少しずつ「外から来たコード」から「自分たちが扱えるコード」に変わっていきます。
おわりに
AIが書いたコードを前にして、いきなり全部を理解しようとすると苦しくなります。 まずは、何がわかっていないのかを分ける。
全体像か。
個々の役割か。
順番か。
筋か。
自分の言葉になっていないのか。
わからなさを分けると、AIへの質問の解像度が上がります。 質問の解像度が上がると、返ってくる説明も使いやすくなります。 その説明を検証し、自分の言葉に変換することで、理解が進みます。
生成AIに聞ける時代だからこそ、「何を聞けば理解に近づくのか」を知っていることが大事になるのだと思います。
参考文献
- 山鳥重『「わかる」とはどういうことか ——認識の脳科学』筑摩書房、2002年
https://www.chikumashobo.co.jp/product/9784480059390/
