【ITニュース解説】Everyone's at Level 1, and it unlocks nothing

AIコーディングエージェントの導入が急速に進む現代のソフトウェア開発において、多くのチームが共通の課題に直面している。それは、AIエージェントの挙動をどう管理し、その信頼性をどう確保するかという問題である。多くのチームは、AIエージェントが従うべきコーディング規約やアーキテクチャ、実行すべきテストなどを記したAGENTS.mdのような指示書（コンテキストファイル）を作成することから始める。この指示書は確かに有用だが、問題は、エージェントがその指示に実際に従っているかどうかをどう確認するかという点にある。

ある調査によると、2,853のソフトウェアリポジトリのうち90.6%がこのようなコンテキストファイルを共有している一方で、エージェントの編集ワークフロー中にチェックを実行できる仕組み（フック）を持つリポジトリはわずか0.9%から3.2%に過ぎなかった。これは、ほとんどのチームが指示を共有しているにもかかわらず、エージェントの振る舞いを強制したり監視したりするメカニズムをほとんど持っていない現状を示している。多くのチームは、この最も簡単なステップを、ソフトウェア開発の成熟度を高めるための「最初のステップ」だと誤解しているのかもしれない。

しかし、開発プロセスの成熟度は、単に指示書を作成するといった「ツールを導入した」という事実ではなく、「フィードバックループ」をどれだけ閉じられるかにかかっている。フィードバックループとは、問題が発生した際にそれを検知し、その原因を特定し、改善策を講じ、そしてその改善が機能しているかを継続的に監視する一連の仕組みのことである。例えば、エージェントがファイルを変更し、その後型チェッカーが実行され、エラーを検知したら、その変更をブロックしてエージェントにフィードバックする一連の流れがこれにあたる。さらに、このような失敗を記録し、繰り返される問題を特定し、それを未然に防ぐための制御を導入する段階まで進めば、それは単発の失敗を検出するだけでなく、システム的に学習していると言える。

この考え方に基づき、成熟度を「何が何に依存するか」という観点で整理した新しいモデルが提唱されている。このモデルでは、開発の成熟度を次の5つのレベルで定義する。レベル0は、個人がAIの助けを借りて開発を進める段階である。レベル1は、多くのチームが現在いる段階で、AGENTS.mdのような指示書やコーディング規約をチーム内で共有する。レベル2では、エージェントの変更をブロックするようなチェック機構、システムの挙動を監視するセンサー、そして実行の詳細を記録するトレースの導入が含まれる。これにより、問題を検知し、変更を食い止める能力を獲得する。レベル3は、レベル2で収集された証拠（失敗の記録や実行トレース）を分析し、繰り返し発生する問題を未然に防ぐための自動的な制御（ガードレール）を導入する段階である。このレベルでは、不要になった制御を削除する能力も重要となる。そしてレベル4は、組織全体で共通のテスト環境や開発インフラ（ハーネス）のテンプレートを作成し、他のチームがそれを再利用できるようにする段階である。これは、開発インフラを各チームが独自に構築する手間を省き、組織全体の生産性を高める。

従来の考え方では、まず規約を文書化し（レベル1）、次にそれを自動化し、証拠を収集し、制御を改善し、最終的にシステムを共有するという順序が論理的だとされてきた。しかし、この新しいモデルは、その順序が必ずしも正しいとは限らないと指摘する。例えば、コードの型チェックのようなブロッキングチェックは、AGENTS.mdファイルがなくてもエージェントの編集ワークフロー中に実行できる。コンテキストファイルはエージェントがエラーを理解するのに役立つかもしれないが、チェック実行のための技術的な前提条件ではない。つまり、レベル1はレベル2の前提条件ではないのである。

では、なぜレベル1がこれほど一般的であるのか。その理由はシンプルに、それが「安価」だからである。マークダウンファイルを記述するだけなら数分で済むが、信頼性の高いチェック機構を構築するには、システムへの統合、継続的なメンテナンス、そして何をブロックすべきかという意思決定が必要となる。私たちは、プラクティスが採用される順序と、それらが互いに依存する順序を混同しているのである。もしチームがコンテキストファイルの磨き上げに時間を費やしすぎているなら、それは従来の「はしごを登る」のではなく、「横に移動する」時期が来ているのかもしれない。

多くのチームにとって実用的な次のステップは、AIエージェントの編集ワークフローに、信頼性の高い計算チェックを統合することである。例えば、コードベースに関連する型チェッカーや適切なテストスイートから始めるのが良いだろう。失敗したチェックは、問題が解決されるまでその変更が先に進むのを防ぐべきである。単に「型チェッカーを動かせ」と指示するのと、ワークフロー自体が型チェッカーを実行し、失敗したら変更をブロックするのとでは、システムの持つ能力が大きく異なる。後者は、失敗のクラスを独立して検知するメカニズムを導入しているからだ。

ブロッキングチェックは失敗を防ぐのに役立つが、それだけではチームが繰り返し発生する問題から学ぶことはできない。エージェントが同じ欠陥を繰り返し導入している場合、それを捕捉するチェックを追加しても、数ヶ月後にその問題がまだ発生しているか、チェックが効果的か、他の失敗が見過ごされていないかといった疑問に答えるためには、有用な記録が必要となる。これが、レベル2にセンサーとトレースキャプチャが含まれる理由である。センサーは実際に何が起こったかを観察し、トレースは実行情報と結果を後で調査できるように保存する。

レベル3では、チームはこれらの証拠を利用して、繰り返し発生する失敗に対応する制御を導入する。しかし、単にセーフガードを追加するだけでは、システムは不必要な複雑さを蓄積する可能性があるため、正当な理由がなくなった制御は削除できることも重要である。成熟とは、証拠から学び、システムを賢くすることであり、無制限に制限を追加することではない。

レベル4は、組織全体に関わる意思決定である。他のチームが利用できる再利用可能な開発ハーネスのテンプレートを作成することは、各チームが開発インフラを個別に再構築するのを防ぐ効果がある。しかし、フレームワーク、デプロイモデル、サービスアーキテクチャがチーム間で異なると、再利用は困難になる。テンプレートは、それを開発していないチームが実際に利用できる場合に初めてその価値を証明する。このレベルに達するには、組織がサポートするサービスアーキテクチャの多様性を制限するといった、技術的なツール導入だけでなく、アーキテクチャやマネジメントに関する組織的な意思決定が必要となる。

このような成熟した開発ライフサイクルは、機械的な失敗をより早く、より安価に検知できるようになるが、チームが「正しいソフトウェア」を構築していることを保証するものではない。要件が不完全であったり、誤解されていたりする場合、システムはすべてのチェックをパスしても、ユーザーにとって間違った結果を生み出す可能性がある。自動化されたテストは、エンコードされた期待を検証するだけであり、その期待がユーザーのニーズをすべて捉えていることを保証するわけではない。また、より良いツールは、影響の大きい変更を安全に委譲できるようにするわけでもない。エンジニアの判断は依然として不可欠である。成熟度は、失敗がどのように検出され、処理されるかを改善するが、システムが正しいことをしているかどうかを判断する必要性を排除するものではない。

チームの現在の成熟度を評価するには、リポジトリやワークフローからの証拠に基づいて、次のような問いに答えてみるとよい。共有され、バージョン管理されたエージェントのコンテキストを持っているか。エージェントの編集サイクル中にチェックが変更をブロックできるか。それらのチェックが観測可能な結果を生み出しているか。実行トレースやセンサーの結果はどこかにクエリ可能な形で保存されているか。繰り返しの失敗に対応して制御を導入したことがあるか。制御を削除し、その理由を文書化したことがあるか。他のチームが作成していないハーネステンプレートを消費したことがあるか。実際に発生したドリルに対してハーネスのカバレッジを測定しているか。これらの質問には、「これから実装しようとしていること」ではなく、「今日チームが実際に示すことができること」に基づいて答えるべきである。また、リスクの低い内部ツールと影響の大きいサービスでは、異なるレベルの制御が必要になる場合があるため、特定の作業クラスごとに成熟度を評価することも重要である。

結論として、すべてのコンテキストファイルを完璧にしてから自動チェックを導入する必要はなく、すべての機能が定められた順序に従う必要もない。チームが現在欠いているフィードバックループを特定することが重要である。多くのチームにとって、それはブロッキングチェックとトレースストアの導入から始めることを意味する。重要なのは、単に「はしごを登る」ことに最適化するのではなく、次に有用なフィードバックループを閉じ、システムが観察し、学習し、改善する能力を高めることに最適化することである。