powered by TechFeed
表示モード
Deep Dive

AIに説明させても「理解した」にはならない — 未知のコードベースを本当に習得するための4フェーズ戦略

10月29日、Test DoubleのエンジニアであるRiver Lynn Baileyが「Accelerate your understanding of unfamiliar code with AI」と題した記事を公開した。この記事では、AIツールを活用して未知のコードベースを素早く理解するための実践的なアプローチについて詳しく紹介されている。

10月29日、Test DoubleのエンジニアであるRiver Lynn Baileyが「Accelerate your understanding of unfamiliar code with AI」と題した記事を公開した。この記事では、AIツールを活用して未知のコードベースを素早く理解するための実践的なアプローチについて詳しく紹介されている。


「AIで説明してもらった」≠「理解した」

新しいコードベースを開いたときの不快感は誰もが知っている。どこに何があるかわからない、どのファイルが重要かわからない、何かを触ったら何が壊れるかわからない——そのストレスは、今やAIツールに尋ねれば1〜2分で解消できる。

しかし、Bailey氏はここに本質的な罠があると指摘する。スピードと理解は別物だ。AIが流暢に説明してくれると、自分が理解したように感じる。だが実際には、自分ではまだ検証できていない要約を読んだだけかもしれない。

解決策はシンプルだが、手間がかかる。「AIに概要を把握させ、その後で実際のコードと照合して検証する」——この繰り返しだ。ポイントは、「検証」の重さが習熟度のフェーズによって大きく変わるという点にある。


なぜ理解には「形」があるのか

コード理解の研究によると、人はコードベースを一度に把握するのではなく、層を積み重ねるように理解していく。Penningtonの研究("Stimulus Structures and Mental Representations in Expert Comprehension of Computer Programs", 1987)では、コードが初見のとき、まず把握できるのは「制御フロー(何が何を呼んでいるか)」だけであり、データフローや設計意図はその後に理解できるようになるとされている。

この層の形成を導くのが、PirolliとCardが1999年に提唱した「情報の香り(information scent)」——関数名やファイル名といった「次にどこを見ればいいか」を示す手がかりだ。AIモデルも同じ手がかりを辿ってコードを読む。名前が意味不明で依存関係が複雑な箇所では、この香りが弱くなり、AIも人間と同じように道を誤る。自信満々な誤答が積み重なると、誤解が雪だるま式に膨らむ。

この「層の積み重ね」と「香りの弱い箇所での迷子」こそが、新しいコードベースの習得に曲線を描かせる原因だとBailey氏は述べる。


4つのフェーズとAIの役割

本記事は全5回シリーズの第1回で、習熟度の曲線(自信の急上昇→「自信のピーク」→「気づきの谷」→成長の坂→習熟のプラトー)を4つのフェーズに分けて解説する構成だ。各フェーズでAIの使い方は大きく異なる。

  • オンボーディング(「楽勝じゃないか」):AIがコードを読んで説明し、作業の大半をこなす。この「楽勝感」がいかに人を騙すか、そしてピーク時にやっておくべき1つのことが第2回のテーマ。
  • 学習(「無理だ、わからない」):AIはコーダーではなくメンターとして機能する。AIが説明しペースを調整し、コードは自分が書く。最もスローに感じるフェーズ。
  • ベースライン(「少しわかってきた」):通常のペースに戻り、AIが再び重い作業を担う。この時点では自分がAIの出力を検証できるようになっているため、任せることが安全になる。
  • エキスパート(「任せろ」):Claudeを設計・計画に使いつつ、コードの直接編集は自分で行う。

各フェーズにおけるAIへの具体的な問いかけ方については、第2回以降で詳しく扱われる予定だ。たとえばオンボーディング期には「このリポジトリの責務をひと言で説明してほしい」「エントリーポイントから処理が始まる流れを追ってほしい」といった俯瞰的なプロンプトが有効とされ、学習期には「この実装の意図を教えてほしい。ただし、コードは自分で書くので答えは出さないでほしい」という制約付きのプロンプトが推奨されている。シリーズ全体を通じて、フェーズごとの「AIとの付き合い方」が体系的に整理されていく見通しだ。


実務への示唆

Bailey氏が特に強調するのは「ピーク時の過信」と「検証の省略」のリスクだ。初日にAIツールで颯爽と概要を把握した感覚は、実際には制御フローの薄い理解に過ぎない可能性が高い。それを検証せずに進むと、後のフェーズで払うコストが跳ね上がる。

なお、記事内で触れられている「ダニング・クルーガー効果の曲線」は、1999年の原論文ではなく後年のユーモラスなスケッチが元であるという指摘も興味深い。原論文が測定したのは「異なる人々のスナップショット」であり、「個人の成長の旅」ではない——この点はよく誤解されているため、覚えておく価値がある。

本記事はシリーズ第1回にあたり、続く各回では上記4フェーズそれぞれの具体的な戦術が掘り下げられる予定だ。特に「ピーク期にやっておくべきこと」を扱う第2回は、オンボーディング直後のエンジニアにとって実践的な内容になると期待される。Test DoubleのInsightsページで続編を追うことができる。


詳細はAccelerate your understanding of unfamiliar code with AIを参照していただきたい。