AIの成果物は「未知の言語化」で決まる：Anthropicが説くエンジニアの生存戦略

深夜のデバッグ作業中、AIエージェントに投げたはずのコードが、なぜか全く意図しない方向に爆走し、修正するたびに別の箇所でデッドロックが発生する……そんな経験はないだろうか。我々エンジニアは、AIを「魔法の杖」のように扱いがちだが、実際にはAIは我々が渡した「地図」を頼りに、未知の「土地」を探索しているに過ぎない。Anthropicが公開した『A Field Guide to Claude Fable: Finding Your Unknowns』は、この本質を鋭く突いている。AIの出力が期待値から乖離するのは、AIの性能不足ではなく、我々が渡した地図そのものが、現実のコードベースという土地の複雑さを反映できていないからだ。

ここで重要なのは、AIが「未知（unknowns）」に直面した際、自律的に推測で穴埋めをしてしまうという挙動だ。この推測が、往々にして我々の意図とズレる。例えば、ナビゲーションシステムに目的地を入力しても、地元の人間しか知らない裏道や、時間帯による渋滞の特性までは反映されないのと同様だ。AIは教科書的な最適解を提示するが、それは「我々が言語化できていない暗黙知」を欠いた地図である。シニアエンジニアとして痛感するのは、AIの成果物の質が、モデルのパラメータ数ではなく、我々が「何を分かっていないか」をどれだけ明確に言語化できるかという、極めて人間側の能力に依存しているという現実だ。これは、AIを単なるツールとして使う段階から、AIを「思考の鏡」として使い、自身の認識の解像度を高める段階へのシフトを意味している。

AIとの共同作業において、我々が直面する「未知」は、単一の塊ではない。Anthropicのフレームワークでは、これを4つの象限に分解している。この分類こそが、開発現場における「なぜかうまくいかない」というモヤモヤを解消する鍵となる。以下の表は、開発者がAIと対峙する際に意識すべき未知の構造である。

多くのエンジニアが陥る罠は、この「未知の既知」と「未知の未知」を放置したまま、AIに実装を丸投げすることだ。特に「未知の既知」は、AIが生成したコードを見て初めて「これじゃない」と気づく類のものであり、最初から言語化できていないことがボトルネックとなる。また、「未知の未知」に至っては、経験の浅い領域や、複雑なレガシーコードの改修時に頻発する。我々が明日から取るべき対策は、実装の各フェーズで「Blind Spot Pass（死角の洗い出し）」をAIに要求することだ。実装前に「私の未知の未知を洗い出してくれ」とAIに尋問させることで、地図の解像度を強制的に引き上げる。これは、実装が完了した後に手戻りが発生するコストを考えれば、極めて安価で高効率な投資であると言える。

実装の前後で「未知」を炙り出す手法は多岐にわたるが、私が特に注目したいのは「実装ノート（implementation-notes.md）」の活用だ。これは単なる作業ログではない。未来の自分や、プロジェクトを引き継ぐ誰かに向けた「思考のコンテキスト」の保存である。時間が経過したコードベースは、誰にとっても未知の土地となる。なぜそのライブラリを選んだのか、なぜその分岐条件が必要だったのか。当時の判断基準が失われたコードは、スパゲッティコードへの入り口だ。しかし、AIにこの実装ノートを読ませることで、当時の判断背景を再構築できる。読み手を人間からAIに変えるという発想の転換は、ドキュメント作成のモチベーションを劇的に変えるはずだ。

ここで我々エンジニアに突きつけられる問いは、「AIにコードを書かせること」に満足していないか、という点だ。AIはあくまで「未知を言語化する力」を増幅させる触媒に過ぎない。もし、あなたがAIの出力に対して「なんとなく違う」と感じているなら、それはAIのせいではなく、あなたの「未知」が言語化されていない証拠である。明日から、AIにコードを生成させる前に、まず「自分の未知を一緒に探してほしい」と対話を始めてみてはどうだろうか。実装のスピードを競う時代は終わった。これからは、どれだけ深く、正確に「未知」を言語化し、AIという強力なパートナーと地図を共有できるか。その能力こそが、シニアエンジニアとしての市場価値を決定づけるのではないだろうか。あなたは、自分のコードの「未知」を、今日どれだけ言語化できたか？