[完全ワークショップ] AI コーディング：実務エンジニア向け、マット・ポコック氏

AI コーディングの「ダムゾーン」を回避する：並列エージェントと対話的調整の実践ガイド

大規模な LLM（大規模言語モデル）を活用したコード生成において、多くのエンジニアが直面する最大の壁は「コンテキスト長が増えると精度が急落する現象」です。これを解決するためには、従来の「計画して実行する」という静的アプローチから脱却し、タスクを小さく分割して並列処理を行う新しいフレームワークが必要です。

本記事では、AI エンジニアリングの専門家が提唱する「スマートゾーン（賢い領域）」と「ダムゾーン（愚かな領域）」の概念に基づき、大規模開発でも高品質なコードを生み出すための具体的な手法を解説します。単なるコード生成ツールとしてではなく、構造化されたソフトウェアエンジニアリングの一部として AI を活用する方法を学びます。

LLM の限界：なぜ「コンテキストが長い」ほど失敗するのか？

LLM を扱う際に最も重要な前提となるのが、「賢い領域（Smart Zone）」と「愚かな領域（Dumb Zone）」の存在です。これは、Human Layer の代表である Dex H. が提唱した概念で、AI と対話する際の精度がコンテキストの長さによって劇的に変化する現象を指します。

会話が始まったばかりの初期状態では、トークン間の注意関係（attention relationships）が最もシンプルで、モデルは最高のパフォーマンスを発揮します。しかし、コンテキストウィンドウに情報を追加し続けることは、サッカーリーグにチームを追加するのと同じです。試合数（トークン間の関係性）は二次関数的に増加し、モデルの処理能力が限界を超えます。

「10 万トークン程度のコンテキストウィンドウを越えると、賢さが失われ始めます。20 万トークンを使おうと、同じことが起こります。」

コンテキストが長くなると、モデルは重要な情報を見失い、論理的な判断ができなくなります。これを「ダムゾーン」と呼びます。この領域に入ってしまうと、AI は自信満々に間違ったコードを生成し始めます。

したがって、開発者が守るべき第一のルールは「タスクを小さく保つ」ことです。マーティン・ファウラーのリファクタリング原則や『実践的プログラマー』で説かれる「処理能力以上のことを引き受けない」という教えが、AI コーディングにおいては特に重要になります。

垂直スライスによる実装：横断的な機能追加の罠を避ける

巨大なタスク（例：「会社全体をクローンする」）をどうやって小さなタスクに分解するか。多くのエンジニアは、一度に一つの機能を完成させるのではなく、データベース、バックエンド、フロントエンドと横断的に進める「ウォーターフォール型」や、大規模な計画を立てて実行する「マルチフェーズプラン」を採用しがちです。

しかし、Matt Pocock 氏はこれを推奨しません。なぜなら、各フェーズが完了するたびにコンテキストが肥大化し、最終的にダムゾーンに突入してしまうからです。

代わりに提唱されるのが「垂直スライス（Vertical Slice）」の実装アプローチです。

• 従来の方法: スキーマ変更 → バックエンド実装 → フロントエンド実装（横断的）
• 推奨方法: スキーマ変更からフロントエンド表示までを含む一つの機能単位で完結させる（垂直的）

この手法では、スキーマの変更からそのデータを表示する UI までを一つの小さな「スライス」として完成させます。これにより、各タスクは常にスマートゾーン内で処理され、コンテキストの肥大化を防ぎながら、確実に機能を積み上げていくことが可能になります。

「グラリングセッション」：計画書よりも対話的調整が勝つ

AI との協業において、「仕様書（Specs）を作ってコードに変換する」というアプローチが流行しています。しかし、Matt 氏はこれを「バイブコーディング（Vibe Coding）」と批判し、その非効率性を指摘します。

「コードを見ずに仕様の修正を繰り返すのは、コードという戦場を放棄することと同じです。」

仕様書に依存する手法では、AI と開発者の間で意図の齟齬が生じても、コードレベルで確認できないため、修正が無限ループに陥りやすいのです。

Matt 氏が推奨するのは「グラリングセッション（Grilling Session）」です。これは、事前に完璧な計画書を作るのではなく、AI と積極的に対話しながら意図を共有するプロセスです。

1. スキル呼び出し: AI に「私を徹底的に質問してください」と指示し、自分の思考の盲点を突かせる。
2. 共通理解の形成: 設計ツリーの各分岐や依存関係を一つずつ確認し、AI と開発者の間で「同じ波長」に乗る。
3. コードベースの探索: AI にリポジトリを調査させ、具体的な質問（例：「ポイント経済について、どの行動がポイントを獲得するか？」）を通じて文脈を理解させる。

このアプローチは、フレデリック・P・ブルックスが言うところの「共通のアイデア（Design Concept）」を共有することに注力します。計画書よりも対話的な調整の方が、最終的に正確なコードを生み出す確率が高まります。

並列エージェントとコンパクション：効率化の鍵

垂直スライスを実行する際にも、複数のタスクが同時に発生することがあります。ここで重要になるのが「並列エージェント」の活用です。

• 実装エージェント: コードを書き、機能を実装する。
• レビュー用エージェント（Sonnet/Opus など）: 別プロセスでコードをレビューし、バグや改善点を指摘する。

これらを並行して実行することで、開発速度を上げつつ、品質保証を担保します。特に、複雑なタスクはサブエージェントに委任し、その結果を要約して親エージェントに戻す「デレゲーション」の仕組みが有効です。

また、セッション中のコンテキスト管理には「コンパクション（圧縮）」と「クリア」の二つの選択肢があります。多くの開発者は会話履歴を圧縮して保存する傾向がありますが、Matt 氏はこれを推奨しません。

「AI は『メモリー』の主人公のように、常に忘却を繰り返す存在です。各セッションは最初からやり直す方が、性能が安定します。」

コンパクション（履歴の要約）よりも、セッションごとにコンテキストを完全にクリアし、システムプロンプトの状態に戻す方が、モデルの注意力を最大限に引き出せます。トークン使用量を常に監視し、ダムゾーンに近づいたら即座にリセットする習慣が、高品質なコード生成には不可欠です。

まとめ：AI は「構造化されたエンジニアリング」の一部である

AI コーディングの本質は、単なるコード生成ツールとしての活用ではありません。LLM の弱点（コンテキストの限界）を補い、強み（並列処理能力）を活かすために、従来のソフトウェアエンジニアリングの原則——タスクの分割、垂直スライス、対話的調整——を再定義して適用することです。

「計画モード」に固執せず、AI と対話しながら意図を共有する「グラリングセッション」を通じて、開発者は AI を真のパートナーとして使いこなすことができます。このアプローチこそが、エンタープライズレベルの開発において信頼性を高める鍵となります。