コードは読めるのに仕様は読めない — AIが上流工程で躓く本当の理由
# コードは読めるのに仕様は読めない — AIが上流工程で躓く本当の理由
「AIはコードを書くのは得意なのに、仕様書を作るのはなぜこんなに苦手なんだろう」
この疑問を持ったことがある方は、現場でAIを本格活用し始めた人だと思う。
GitHub CopilotやClaude Codeは、コードを驚くほど正確に補完・生成する。バグ修正やリファクタリングも、熟練エンジニアと遜色ないレベルまで来た。なのに、「この業務フローの要件を整理して」と頼むと、途端にハルシネーションが増え、出力が信頼しにくくなる。
この非対称性には、構造的な理由がある。
コードは「文法がある自然言語」だ
プログラミング言語には、文法がある。厳密に定義された構文ルール、型システム、スコープの規則。これらは曖昧さを許さない。
だから、コードをAIに理解させるのは比較的簡単だ。Tree-sitterのような構文解析ライブラリを使えば、どんなコードベースでも抽象構文木（AST）に変換できる。ASTにすれば、「この関数はどこから呼ばれているか」「このクラスの依存関係は何か」が、テキスト検索ではなく構造として取り出せる。
最近Slack上でも話題になっていたが、GitNexusのようなツールがコードベースを「知識グラフ」として扱えるのも、この仕組みのおかげだ。コードは構造化されているから、AIが確定的に解析できる。
さらに、コードはインターネット上に膨大なサンプルがある。GitHubだけで3億以上のリポジトリ。Transformerベースのモデルは、このデータで徹底的に訓練されている。
コードに関しては、AIは「文法書を丸暗記した上に、数億冊の参考書を読んだ人」に近い状態にある。
仕様書には「文法がない」
では仕様書はどうか。
「ユーザーが商品を検索できること」——この一文は、一見シンプルに 見える。しかし実際には無数の解釈が可能だ。
- 検索は全文検索か？それともカテゴリ絞り込みか？
- 在庫切れの商品も表示するのか？
- 検索結果は何件まで返すのか？
- ログインしていないユーザーも検索できるのか？
仕様書の「文法」は存在しない。記述スタイルは会社ごと、プロジェクトごと、担当者ごとにバラバラだ。Wordで書く人もいれば、NotionやConfluenceを使う人もいる。テーブル形式もあれば、箇条書きだけの場合もある。
AIにとって仕様書は、解析ツールのない非構造化テキストだ。
しかもコードと違い、仕様書はビジネスドメインの文脈に依存する。「承認フロー」と書いてあっても、その会社の業務ルールを知らなければ正確に解釈できない。このドメイン知識は、インターネット上には存在しない。
「曖昧さ」こそが本質的な障壁
ここで重要な点がある。仕様書の難しさは、単に「構造がない」だけではない。意図的に曖昧に書かれることがあるという点だ。
要件定義の段階では、まだ決まっていないことがある。「○○の場合の処理は後で決める」「詳細は実装フェーズで検討」——こうした記述は、人間同士のコミュニケーションではよくあることだ。
しかしAIは曖昧さを補完しようとする。仕様書の行間を「合理的な解釈」で埋めようとする。その補完が正しければ問題ないが、ドメイン知識が不足しているともっともらしいハルシネーションが起きる。
特に厄介なのは、出力が自信満々に見えることだ。「この場合、○○という処理が適切です」と断言されても、それが本当にそのビジネスの要件を満たしているかどうかは、人間が検証しなければわからない。
コードのハルシネーションはコンパイルエラーや静的解析で検出できる。仕様書のハルシネーションは、ずっと後になって「あれ、この動きは要件と違うぞ」と気づく。
上流でAIを使えないのか、というと違う
ここまで読んで「じゃあ上流工程にAIは使えないのか」と思った方に、誤解を解いておきたい。
AIが苦手なのは、構造のない仕様書をそのまま渡したときだ。逆に言えば、仕様書を「AIが解析しやすい構造」に変えれば、話は変わる。
私たちが仕様駆動開発（SDD）の文脈で実践していることのひとつが、まさにこれだ。自然言語の要件を、AIが扱いやすい構造化フォーマットに変換してから渡す。
具体的には:
- 機能要件を粒度を揃えて列挙する（「できること」「できないこと」を明示）
- 例外パターンを明示的に書く（「ただし○○の場合は△△」）
- 依存関係を明確にする（「この機能は○○が完了してから動く」）
コードのASTと同じように、仕様書も「AIが構造として認識できる形」にすることで、精度が大きく変わる。
この変換作業自体をAIに手伝わせることも可能だ。「この箇条書きの要件を、前提条件・正常系・異常系の3つに分類して」という指示は、かなり精度よく動く。構造化のルールを与えれば、AIは得意な処理に持ち込める。
現場でできること
抽象論だけでは意味がないので、明日から使える話をしておく。
要件定義の議事録をAIに渡す前に、一手間かける
生の議事録テキストをそのままAIに投げるのは、最も精度が出ない使い方だ。「この議事録から、誰が何を決めたのかを箇条書きにして」という前処理を1ステップ挟むだけで、後続の処理精度が上がる。
AIに「わからないことを聞かせる」役割を与える
「この仕様で不明な点を10個挙げてください」 という使い方が、上流工程では意外に効く。AIが仕様書を読んで「これはどういう意味ですか？」と質問してくれることで、人間では見落としていた曖昧な記述が浮かび上がる。
構造化テンプレートを先に作る
ゼロから仕様書を書かせるのではなく、テンプレートを用意してその空欄を埋めさせる。「機能名：○○ / 対象ユーザー：○○ / トリガー：○○ / 正常系：○○ / 異常系：○○」という形式を固定することで、AIは「何を書けばいいか」の迷いがなくなる。
なぜこれが重要か
コードは書けるが仕様は読めない——これは単なるAIの弱点ではない。
上流工程の品質が低いと、どんなに優秀なAIコーディングツールを使っても、出来上がるものはズレる。「何を作るべきか」が曖昧なまま「速く作る」ことに投資しても、手戻りコストが跳ね上がるだけだ。
AI開発ツールが成熟した今、次のボトルネックは「上流工程をAIが扱えるように構造化すること」に移っている。ここへの投資が、今後の開発生産性を大きく左右する。
アツメルでは、上流工程のAI活用を実践するチームの支援をしています。具体的な導入方法や、仕様書の構造化アプローチについては、お気軽にご相談ください。
