知らないコードをAIに1行ずつ説明させる｜安全に触るための読み方

「この関数、仕様がちょっと変わったから直しておいて。数行でしょ？」 開いてみると、見たことのない書き方が並んでいる。書いた人はもう別のチーム。コメントはない。たしかに数行なのに、どこを触っていいのか分からない。

こういうとき、AIに「このコードを説明して」と貼るのは、とても自然な一手です。実際、それらしい説明はすぐ返ってきます。 ただ、説明を読んで「分かった」と思えたのに、直したら別のところが壊れた——そんな経験がある人も多いのではないでしょうか。

それは、あなたの読み方が浅かったからではありません。AIの説明は「何をしているか」には強い一方で、触るときにいちばん大事な「何を前提にしているか」が抜けやすいのです。 この記事では、知らないコードをAIに1行ずつ説明させて、安全に触れる状態まで理解する読み方を整理します。今日は、気になっている関数をひとつ選ぶところから、一緒に進めましょう。

結論：知らないコードをAIに説明させるときは、説明を「答え」ではなく「確かめるための仮説」として受け取ります。手順は4つ。①範囲を関数ひとつに絞って渡す／②1行ずつ説明させ、「確実に言えること」と「推測」を分けさせ、前提条件も出させる／③説明を、小さな入力で実際に動かして確かめる／④分かったことを自分の言葉で書き残してから触る。いちばん効くのは③。数分動かすだけで、説明の抜けが見えてきます。

何が起きているのか——要約は合っていても、「前提」が抜ける

AIにコードを説明させると、たいてい筋の通った文章が返ってきます。そして多くの場合、要約としては合っています。

ただ、コードを触る人に必要なのは要約だけではありません。

• どんな入力を想定しているのか（型、形式、空のとき、重複のとき）
• 想定外の入力が来たら、どうなるのか（エラーになる？　黙って結果が変わる？）
• 結果の順番や件数は、何に左右されるのか

こうした「前提」は、コードの中に書かれていないことが多い部分です。AIはコードの見た目から自然な説明を組み立てるので、書かれていない前提までは、こちらから聞かないと出てこないことがあります。ときには、もっともらしい推測を事実のように書くこともあります（いわゆるハルシネーションです）。

だから「AIの説明は当てにならない」ではなく、聞き方と確かめ方を決めておけば、AIは知らないコードを読むときの心強い相棒になる、と考えるのが現実的です。

具体例：「最新のレコードだけ返す」関数の、書かれていない前提

たとえば、こんなPythonの関数を引き継いだとします。

def pick_latest(rows):
    seen = {}
    for r in sorted(rows, key=lambda r: (r["id"], r["updated_at"])):
        seen[r["id"]] = r
    return [r for r in seen.values() if not r.get("deleted")]

AIに「説明して」とだけ頼むと、こんな答えが返ってくるかもしれません。

「IDごとに、更新日時がいちばん新しいレコードだけを残し、削除済みのものを除いて返す関数です」

要約としては合っています。でも、この関数を触る前に知っておきたいことが、まだいくつか隠れています。

どれも、コードのどこにも「注意」とは書かれていません。そして直すときに壊しやすいのは、まさにこういう所です。

放っておくと、何が起きるか

「分かったつもり」で触ると、次のようなことが起きやすくなります。

• 前提を知らずに書き換えて、静かに挙動が変わる：エラーにはならず、件数や並び順だけが変わるので、気づくのが遅れます。
• レビューで「なぜこう直したの？」に答えられない：AIの説明をそのまま信じていると、根拠を聞かれたときに言葉に詰まります。
• 次に同じコードを開いた人が、また一から読む：分かったことがどこにも残っていないと、チームで同じ苦労を繰り返します。

逆に、説明を一度確かめて書き残しておけば、そのコードはもう「知らないコード」ではなくなります。ここが、この記事でいちばん伝えたいところです。

知らないコードを読む4ステップ

ステップ1：範囲を関数ひとつに絞って渡す

ファイルを丸ごと貼るより、いま触りたい関数ひとつ（目安として数十行まで）に絞るほうが、説明が具体的になります。範囲が広いと、AIは全体をなめらかに要約しようとして、細かい前提が落ちやすくなるからです。

• 触りたい関数と、それが使っている型やデータの形が分かる部分だけを渡す
• 呼び出し元の様子（どこから、どんなデータで呼ばれるか）を一言添える
• 社外のAIサービスに貼る場合は、会社のルールで渡してよいコードかを先に確認する（判断の目安は社内データをAIに渡す前の線引きにまとめています）

周辺のコードの雰囲気まで伝えたいときは、既存コードにAIを馴染ませる文脈の渡し方の要約の作り方が使えます。

ステップ2：1行ずつ説明させ、「確実」と「推測」を分けさせる

「説明して」だけでなく、触る人に必要な情報を指定して頼みます。たとえばこんな頼み方です。

次のコードを、修正する前に正しく理解したいです。

## 説明してほしいこと
- 1行（または意味のまとまり）ずつ、何をしているかを説明してください
- 各説明に「コードから確実に言えること」か「推測」かを付けてください
- このコードが暗黙に前提にしている入力の条件を挙げてください
  （型・形式・空やNoneのとき・重複・件数 など）
- 入力によって、結果が直感と違いそうな所があれば挙げてください
- 結果の順番や件数が、何によって決まるかを説明してください
- 自信がない箇所は「自信がない」と書いてください

## してほしくないこと
- 修正案やリファクタリング案は、今は出さないでください

（ここにコード）

「修正案は出さないで」の一行が、意外と効きます。いきなり直し方が出てくると、理解する前に手が動いてしまうからです。

返ってきた説明で「推測」と付いた所、「自信がない」と書かれた所が、次のステップで確かめる場所になります。

ステップ3：説明を「仮説」として、小さく動かして確かめる

ここがいちばん大事なステップです。AIの説明を読んだら、実際に小さな入力を流して、説明どおりに動くかを見ます。

• 対話型の実行環境（REPL）やテストで、2〜3件だけのデータを流してみる
• 普通の入力に加えて、空・None・重複・桁のそろっていない値など、前提が崩れる入力を1〜2個混ぜる
• 途中の値が気になる所は、print やデバッガで覗く

先ほどの例なら、「最新が削除済みのID」と「updated_at が空のレコード」を1件ずつ混ぜるだけで、表の挙動がすぐ確かめられます。

入力の候補を考えるのはAIに手伝ってもらえます（境界値・異常系をAIに考えさせる手順も参考にどうぞ）。ただし、結果がどうなるかはAIに予想させて終わりにせず、必ず実際に動かして確かめるのがポイントです。予想と実際が食い違った所こそ、理解が深まる所です。

確かめた入力と結果は、そのまま単体テストとして残せます。あとでコードを直したとき、前提を壊していないかを機械が見張ってくれます。

ステップ4：自分の言葉で書き残してから、触る

最後に、分かったことを自分の言葉で書き残します。AIの説明をコピーするのではなく、確かめた結果をもとに、短くまとめ直すのがコツです。

• 関数の先頭に、前提条件と注意点を2〜3行のコメントで書く
• 「最新が削除済みならIDごと消える」のように、仕様か不具合か分からない挙動は、チケットやメモに残して関係者に確認する
• チームのWikiや引き継ぎメモに、読み解いたことを一言残す

自分の言葉で書けない所は、まだ分かっていない所です。そこだけもう一度、ステップ2と3に戻れば大丈夫です。

ここまで来て、ようやく「直す」作業に入ります。書き換えたあとの確認は、AIリファクタリングの差分レビューの手順がそのまま使えます。

明日やること（小さく始める3つ）

1. 触る予定の関数をひとつ選び、上のテンプレでAIに説明させる：「確実」と「推測」が分かれて返ってくるだけで、確かめる場所が見えてきます。
2. 「推測」と書かれた所をひとつだけ、実際に動かして確かめる：2〜3件のデータで十分です。5分で終わることも多いはずです。
3. 分かった前提を、関数の先頭にコメントで1行残す：次にそのコードを開く人（未来の自分を含む）が、同じところで迷わずに済みます。

知らないコードを読む チェックリスト

【必須】の3つだけでも、「分かったつもりで壊す」をかなり防げます。 残りは余裕があるときに。

• 【必須】AIの説明を、実際に小さな入力で動かして確かめたか（説明を読んだだけで済ませていないか）
• 【必須】入力の前提条件（型・形式・空・重複など）を確認したか
• 【必須】仕様か不具合か分からない挙動を、自分で決めずにメモして関係者に確認したか
• （余裕があれば）渡す範囲を、触りたい関数ひとつに絞ったか
• （余裕があれば）社外のAIに貼ってよいコードかを、社内ルールで確認したか
• （余裕があれば）「確実に言えること」と「推測」を分けて説明させたか
• （余裕があれば）理解する前に、AIに修正案を出させていないか
• （余裕があれば）結果の順番・件数が何で決まるかを確認したか
• （余裕があれば）確かめた入力と結果を、テストとして残したか
• （余裕があれば）分かったことを、自分の言葉でコメントやメモに残したか

最後に

知らないコードを前に手が止まるのは、慎重に仕事をしている証拠です。「数行でしょ」と言われても、その数行が何を前提にしているかを知らずに触らない——それは臆病ではなく、ちゃんとした技術です。 AIに1行ずつ説明させて、小さく動かして確かめる。それだけで、知らないコードは、少しずつ「説明できるコード」に変わっていきます。

AIに説明を頼むのは、ずるいことでも手抜きでもありません。確かめる手順さえ持っていれば、読み解く速さも、触るときの安心感も、ぐっと上がります。 まずは明日、気になっている関数をひとつ選んで、「確実」と「推測」を分けて説明してもらうところから始めてみましょう。

よければ、こちらも

• レガシーコードの仕様をAIに読み解かせる｜仕様復元の進め方
• 既存コードにAIを馴染ませる文脈の渡し方｜実務の型
• AIのハルシネーションの見抜き方｜開発現場で気づく型
• 境界値・異常系をAIに考えさせて漏れを減らす手順
• AIに頼りすぎてスキルが育たない｜チームの学習を止めない工夫

関連用語

• ハルシネーション
• 単体テスト
• リファクタリング
• プロンプト