【ITニュース解説】AI Coding Changed the Bottleneck. It Isn't Writing Code Anymore.

数年前まで、AIを活用したプログラミングの典型的な流れは、開発者がコードを書き始め、AIにそのコードの続きを補完させたり、テストコードを生成させたりするといった比較的シンプルなものだった。しかし、このモデルは大きく変わりつつある。今日のAIコーディングエージェントは、単にコードの一部を補完するだけでなく、コードのリポジトリ全体を分析し、ファイル間の関係性を理解し、必要なコマンドを実行し、複数のファイルを変更し、テストを実行してその結果を評価し、失敗があればその原因を調査して修正を続けるといった、より複雑な一連の作業をこなせるようになった。

この変化によって、プログラミングにおけるボトルネック（作業の進行を妨げる最も遅い部分）も移動した。もはや「AIがこのコードを書けるか」が主要な問題ではなく、むしろ「AIが適切なコードを書くのに十分な文脈（コンテキスト）を持っているか」が重要な課題となっている。この視点の転換は、AIによる開発を、単にAIに指示（プロンプト）を与える問題として捉えるのではなく、AIが作業するための環境や制約、フィードバックループを設計する「ハーネスエンジニアリング」という考え方へと導いている。

例えば、新しいAPIパラメータのサポートを追加するという一般的なバックエンドタスクを考えてみよう。人間のエンジニアは、すぐにコードを書き始めるのではなく、まず要件を理解し、関連サービスやアーキテクチャを調べ、既存の実装やAPI規約を確認し、テストケースを調べるといった多くの事前調査を行う。熟練したAIコーディングエージェントもこれらの多くのステップを実行できるが、問題は、経験豊富なエンジニアが長年のプロジェクト経験を通じて培ってきた暗黙の知識、例えば「このモジュールは直接変更すべきではない」「特定の抽象化には理由がある」「プロジェクトが特定のライブラリを優先する」といった情報を、AIエージェントが自動的にすべて知っているわけではない点にある。また、Jiraのチケットに書かれた要件が、重要な実装上の制約をすべて網羅しているわけではないことも珍しくない。

ここで重要になるのが「コンテキストエンジニアリング」だ。AIエージェントに毎回膨大なプロンプトを与える代わりに、リポジトリ自体にAI開発のための情報層を設けることで、必要なコンテキストの大部分を提供できる。これは、リポジトリを単なるコードの保管場所としてではなく、AIエージェントが作業するために必要な情報を提供するインターフェースとして捉える考え方だ。

具体的には、プロジェクト全体に関わる指示をまとめたAGENTS.mdやCLAUDE.mdのようなファイルが挙げられる。これらのファイルには、プロジェクトのアーキテクチャ、使用するプログラミング言語のバージョン、テストの要件、API変更時のルールなど、AIがコードだけでは推測できない、プロジェクト固有のルールや制約を記述する。例えば、「ビジネスロジックをAPIハンドラに記述しない」といった具体的な指示は非常に有用だ。一方で、「きれいなコードを書け」といった一般的な指示は、AIがすでに知っているため、あまり意味がない。重要なのは、AIがコードベースから推論できない、特定の設計上の決定や避けられない制約を伝えることである。

ただし、これらの指示ファイルに何でも詰め込むのは避けるべきだ。ファイルは「このリポジトリに手を付ける前にエンジニアが知るべきこと」という質問に答えるものとし、プロジェクトのアーキテクチャ、規約、重要な制約、テスト要件など、安定した価値の高い情報に限定する。タスク固有の情報は別の場所に置く。

その「別の場所」として有効なのが、specs/ディレクトリに格納されるMarkdown形式の仕様書だ。例えば、Jiraチケットの要件をJIRA-1234.mdのように詳細な仕様書として記述する。ここには、タスクの概要、具体的な要件、受け入れ基準、技術的な注意事項、関連するチケット情報などを網羅的に記載する。これにより、AIエージェントは「JIRA-1234を実装しろ」という漠然とした指示ではなく、具体的な仕様に基づいて作業を開始できる。これは大きな違いを生む。

このようにコンテキストを考える際には、「タスクの仕様」「プロジェクトのコンテキスト」「コードベース」「エージェントが利用できるツール（シェル、Git、テストなど）」というように、複数の層に分けて捉えることが重要だ。それぞれの層が異なる質問（「何を構築すべきか」「どのように作業すべきか」「既存のシステムはどうか」「どのように変更を検証すべきか」）に答えることで、人間のエンジニアが作業するのと同様の多層的な理解をAIに提供する。

AIコーディングエージェントが真に有用になるのは、単にコードを生成するだけでなく、開発環境とインタラクションできるようになった時である。ファイルを読み込み、コードを修正し、テストを実行し、失敗を読み取って再度修正するというフィードバックループの中で作業できることが重要だ。これは、現代のAIエージェントが、単なるコード補完ツールとは根本的に異なる点である。エージェントはコマンドを実行し、その出力を解釈し、次の行動を決定できるのだ。これにより、AI生成コードの評価も変化する。単に「モデルが良いコードを生成したか」だけでなく、「システムが生成されたコードの間違いを確実に検出できるか」が問われるようになる。

コード生成が安価になるにつれて、生成されたコードの「検証」がより重要なプロセスとなる。例えば、AIが数分で300行のコードを生成しても、そのレビューにエンジニアが45分かかれば、ボトルネックはレビューに移る。テストが不十分な場合、この問題はさらに悪化する。そのため、コーディングハーネスは強力なフィードバックループを提供するべきだ。実装後には、リント、単体テスト、結合テスト、型チェック、ビルド、そして差分レビューといった一連の検証ステップをAIエージェント自身が実行できるようにする。さらに、テストの失敗時には「テストが失敗しました」のような曖昧なメッセージではなく、「test_api_returns_existing_error_formatがAssertionErrorを発生。HTTP 400が期待されたがHTTP 500を受信した」のように、AIが原因を推論できる具体的な情報を提供することが重要である。優れたエンジニアリングインフラは、AIエージェントのためのフィードバックインフラとなるのだ。

また、我々は自律的で無制限の自由を持つAIエージェントを求めているわけではない。むしろ、特定の境界内で動作するエージェントを望んでいる。コーディングハーネスは、AIエージェントが変更できるファイル、実行できるコマンド、パスすべきテスト、従うべきパターン、人間によるレビューが必要な変更、タスクの完了条件などを定義し、エージェントに制約を与える。このアプローチは「ハーネスエンジニアリング」と呼ばれ、AIモデルそのものに焦点を当てるのではなく、コーディングエージェントの周囲に制約、フィードバックループ、品質ゲートを設計することの重要性を示している。

AIが間違いを犯した場合、単にその場で修正するだけでなく、その修正内容をプロジェクトの知識として永続化させることも有効なパターンである。例えば、「このプロジェクトでは非同期実行モデルに対応しているため、ライブラリYを使用し、ライブラリXは使わない」といった修正があった場合、この情報をCLAUDE.mdのようなプロジェクト指示ファイルに追記する。こうすることで、次回のAIセッションでは最初からその知識を持って作業を開始し、同じ間違いを繰り返す可能性が低くなる。このように、リポジトリがAIとの協調作業を通じて徐々に賢くなるというフィードバックループが生まれる。

このようなAIの進化は、開発者の役割そのものを変える。開発者は、コードを書いたりデバッグしたりする時間から、要件の理解、制約の定義、コンテキストの提供、実装の委任、結果のレビュー、検証の実行、そしてAIの誤りを修正し、そこから得られた学習を知識として蓄積するといった、より高次の作業に時間を割くようになる。つまり、開発者はシステムを設計し、AIエージェントを監督する立場へと移行する。これは、アーキテクチャ、API、データベース、並行処理、セキュリティ、テスト、パフォーマンスといった、より強固なエンジニアリングの基礎知識が求められることを意味する。AIがコードを高速で生成できるようになった今、そのコードがシステム全体にとって適切かどうかを判断する能力こそが、ますます重要になるのだ。

実用的なワークフローとしては、まずCLAUDE.mdやAGENTS.mdのようなプロジェクト指示ファイルをリポジトリに用意し、次にspecs/JIRA-1234.mdのように要件を機械が読みやすい仕様書に変換してコードの近くに置く。そして、AIエージェントにいきなり実装させるのではなく、まず仕様書を読んで関連コードを調査させ、提案される実装計画を説明させることから始める。これにより、コード生成前に誤解を修正する機会が得られる。計画が承認されたら、エージェントに実装とテストの追加を指示し、その後、エージェントにテスト、リント、型チェック、差分レビューといった検証を実行させる。最終的な変更の承認は、人間が行う。エージェントは提案し、実装し、テストするが、システムにその変更を含めるかどうかを決定するのはエンジニアである。

最大の生産性向上は、より賢いAIモデルから生まれるのではなく、AIが自律的にコンテキストを学習できる「より良い開発環境」を構築することから生まれる。未来のソフトウェア開発は、「開発者＋AIモデル」というシンプルな構図ではなく、「開発者＋コードベース＋コンテキスト＋ツール＋テスト＋AIエージェント」という、全体が連携する「ハーネス」によって実現される。コードを書くこと自体がボトルネックでなくなった時、そこにこそ真に興味深いエンジニアリングの仕事が始まるのである。