最終更新日：2026年7月3日

要旨

本稿は、人工知能（Artificial Intelligence: AI）エージェントを用いたソフトウェア開発において、設計意図、不変条件、依存関係、判断理由、検証証拠をどのように共有・維持すべきかを検討する。Wang らの Agentic Consensus は、AI 支援開発においてコード差分とチャット履歴だけが主要な成果物になると、構造的コミットメントや証拠が失われるという問題を指摘し、合意層 C を操作可能な世界モデルとして導入することを提案した（Wang et al. 2026）。同論文は、C を型付きプロパティグラフとして表現し、実行可能成果物を C から導出し、実行可能成果物から C を再構成する往復同期を構想する。本稿はこの問題設定を継承するが、Wang らの提案全体を「孤立した手書き文書」として読むものではない。批判対象は、C をコードベースから独立した一次成果物、あるいは他の成果物が従属すべき単一の真実として運用する解釈である。その運用解釈には、統一モデリング言語（Unified Modeling Language: UML）やモデル駆動工学（Model-Driven Engineering: MDE）が経験した抽象モデルと実装の乖離を再生産する危険がある。

本稿が提案する Codebase-Grounded Consensus は、合意層をコード、テスト、型、スキーマ、設定、マイグレーション、git 履歴、継続的インテグレーション（Continuous Integration: CI）結果、静的解析、アーキテクチャ決断記録（Architecture Decision Record: ADR）、依存関係判断記録、プルリクエスト（Pull Request: PR）、運用証跡から導かれるレビュー用の派生インデックスとして扱う方法である。ここで依存関係判断記録とは、Software Bill of Materials（SBOM）や OpenSSF Scorecard などが与える構成、保守、ライセンス、依存関係更新に関する機械的証拠を、採用・更新・廃止の理由、代替案、リスク受容、移行コストと接続するための本稿の操作的提案である。派生インデックスとは、一次成果物を置き換える文書ではなく、構造的主張（claim）と検証証拠（evidence）の対応をレビュー単位で参照可能にする索引を指す。中核は、証拠を持たない主張（unsupported claim）や証拠と矛盾する主張をレビュー可能にする点にある。

本稿の貢献は、第一に、本稿の問題設定に照らして、既存研究が主目的としてこなかった論点を、構造表現の静態性、証拠接続の不足、コードとの往復同期コスト、メッセージ中心のエージェント協調、正解率中心の評価という五つの観点から整理することである。第二に、Codebase-Grounded Consensus が成立するための操作的条件を定義する。第三に、互換性、依存関係、セキュリティ、データ移行、性能などの主張型と、テスト、静的解析、スキーマ差分、CI 結果、ADR、運用ログ、人間レビューなどの証拠型を対応づける PR 単位の最小データモデルを提示する。第四に、AI エージェントが生成する PR を、設計整理者、実装者、監査者、履歴参照者、レビュー支援者の五つの役割に分解して検証するワークフローを示す。第五に、主張網羅率、証拠なし主張数、アーキテクチャ逸脱率、判断理由網羅率、介入距離、診断遅延を、本稿が操作的に定義する初期指標として提示し、被験者、課題、対照条件、正解セット、評価者間一致を含む実証評価プロトコルを示す。

本稿の限界は、合意層の導入が二重管理、形式化コスト、AI エージェントの誤った確信、複数エージェント構成への過信を生みうる点である。したがって、本稿の主張は、コードだけを唯一の真実とすることではない。コードは実行可能な実装状態の中心的証拠であり、テスト、CI、設定、デプロイ状態、運用ログと結合されて初めて実際のシステム挙動を検証する証拠群となる。合意層は、それらを置き換えるものではなく、人間と AI エージェントが変更の意味、根拠、責任を検査するための派生インデックスとして設計されるべきである。

第1章　序論：AI エージェント時代に失われる「設計意図」

人工知能（Artificial Intelligence: AI）を用いたソフトウェア開発では、実装工程の一部を高速化しうる方法が示されている。とりわけ、大規模言語モデル（Large Language Model: LLM）を基盤とする AI エージェントは、自然言語による指示からコード差分を生成し、テストを実行し、失敗を修正し、変更提案を作成するまでの工程を部分的に自律化しつつある。SWE-bench は実在する GitHub issue を対象にソフトウェア工学タスクを評価する枠組みを示し、SWE-agent、AutoCodeRover、OpenHands などの研究は、エージェントがリポジトリを操作しながら実際のバグ修正や機能変更を行う可能性を示している（Jimenez et al. 2024; Yang et al. 2024; Zhang et al. 2024; Wang et al. 2025）。これらの成果は、実務組織一般における変更頻度の上昇を直ちに実証するものではないが、AI エージェントが単なるコード補完器ではなく、ソフトウェア変更の実行主体として関与しうる段階に達していることを示す。

なお、変更提案、レビュー、統合を扱う単位の名称は製品によって異なる。たとえば GitHub ではプルリクエスト（Pull Request: PR）、GitLab ではマージリクエスト（Merge Request: MR）と呼ばれる。本稿では、こうした変更提案単位を指す代表的な用語として、GitHub の PR を用いる。

しかし、実装工程の高速化可能性は、同時に別種の制御問題を生み出す。AI エージェントが生成する差分は、表面的にはコンパイル可能であり、既存テストを通過し、局所的な要求を満たしているように見える場合がある。それにもかかわらず、その変更がどの不変条件を前提にしているのか、どの設計判断を変更したのか、どの代替案を退けたのか、どの依存関係や運用上の制約を考慮したのかは、コード差分だけからは必ずしも明らかではない。Wang らは、この問題を、AI 支援開発においてコードとチャット履歴が主要な成果物となることで、構造的コミットメント、依存関係、証拠が低次元のテキストへ圧縮される問題として捉え、これを dimension collapse と呼ぶ（Wang et al. 2026）。同論文が指摘するように、問題は AI がコードを生成できないことではなく、人間がその変更を構造的に統制しにくくなることにある。

従来の人間中心の開発でも、設計意図は常に完全に明文化されていたわけではない。設計判断は、レビューコメント、issue、PR、アーキテクチャ決断記録（Architecture Decision Record: ADR）、口頭での説明、過去の障害対応、熟練開発者の経験などに分散して存在してきた。ソフトウェアアーキテクチャを設計判断の集合として理解する研究は、アーキテクチャを単なる構造図ではなく、なぜその構造が選ばれたのかという判断の履歴として扱う必要を示してきた（Jansen and Bosch 2005; Kruchten, Lago, and van Vliet 2006）。また、ADR は重要な設計判断を軽量に記録する実務的な方法として用いられてきた（Tyree and Akerman 2005; Nygard 2011）。しかし、AI エージェントが高頻度で変更を生成する状況では、これらの分散した知識に依存するだけでは、レビュー担当者が変更の意味を追跡する負荷が急速に増大する。

ここで重要なのは、コードが単なる一次元の文字列ではないという点である。現代のコードベースは、型、モジュール境界、インターフェース、テスト、スキーマ、設定、マイグレーション、継続的インテグレーション（Continuous Integration: CI）、静的解析、履歴管理などを通じて、多くの構造的情報をすでに保持している。したがって、設計意図が失われる原因は、コードに表現力がないことだけではない。むしろ、コードが保持する実行可能な構造、git 履歴が保持する時間的文脈、テストが保持する振る舞いの証拠、ADR や PR が保持する判断理由が、相互に結びつけられていないことにある。

Wang らは、この課題に対して、合意層 C を主要な工学成果物とし、コードや設定などの実行可能成果物を C から導出する Agentic Consensus を提案している（Wang et al. 2026）。C は、型付きプロパティグラフとして表現される操作可能な世界モデルであり、構造的主張、不変条件、依存関係、証拠を明示的に接続することを意図している。同論文はまた、実行可能成果物から C を再構成する過程の曖昧さや、人間による確認の必要性も認識している。この提案は、AI エージェント時代のソフトウェア開発において、単なるコード正しさではなく、人間が変更を統制できる形で合意を維持する必要があることを鋭く指摘している。

一方で、本稿は、C をコードとは別の単一の真実として扱う運用には慎重であるべきだと主張する。これは、Wang らが C を手書き文書として孤立させると主張している、という批判ではない。批判対象は、C の一次成果物性を強く解釈し、実務上、コードベースから独立した正本として維持する運用である。抽象モデルを実装より上位の成果物として扱う発想は、統一モデリング言語（Unified Modeling Language: UML）やモデル駆動工学（Model-Driven Engineering: MDE）においても繰り返し試みられてきた。しかし、実務上の MDE は、抽象モデルと実装との対応維持、ツールチェーンの複雑性、組織的導入コストといった課題に直面してきた（France and Rumpe 2007; Whittle, Hutchinson, and Rouncefield 2014）。AI エージェントのために新たな合意層を導入する場合も、それがコードベースから独立した文書やモデルとして維持されるなら、同様の乖離を再生産する危険がある。

そこで本稿は、合意層を外部化された第一級の真実としてではなく、コードベースに接地されたレビュー用の派生インデックスとして再設計する立場を提示する。この立場を、Codebase-Grounded Consensus と呼ぶ。ここでいう派生インデックスとは、コード、テスト、履歴、設計記録、運用証跡の関係を横断的に参照し、変更ごとの主張と証拠をレビュー可能にする索引を意味する。Codebase-Grounded Consensus において、中心に置かれるのは、実行可能なコード、テスト、型、スキーマ、設定、マイグレーション、git 履歴、CI 結果、運用証跡である。設計意図や判断理由は ADR、PR、issue、依存関係判断記録（dependency decision record）などによって補足される。依存関係判断記録とは、SBOM や OpenSSF Scorecard などが提供する構成、脆弱性、ライセンス、保守状況、依存関係更新に関する機械的証拠を踏まえ、ライブラリ、外部サービス、プロトコルなどの採用・更新・廃止について、選定理由、代替案、リスク受容、移行コストを残す本稿の操作的提案である（United States Department of Commerce 2021; OpenSSF Scorecard 2026）。これらは単独で真実を構成するのではなく、コードやテストと接続されることで検証可能な意味を持つ。

本稿の目的は、AI エージェントによるソフトウェア変更を、単なるコード生成の成否ではなく、検証可能な設計変更として扱うための合意層を再構成することである。具体的には、第一に、Wang らの Agentic Consensus が提起した問題意識を整理する。第二に、C をコードから独立した主要成果物にする運用解釈の限界を、UML、MDE、アーキテクチャ知識管理の観点から検討する。第三に、コード、テスト、履歴、ADR、PR、静的解析、アーキテクチャテストを統合する Codebase-Grounded Consensus の構成要素を示す。第四に、AI エージェントを単一の実装者ではなく、設計整理、実装、監査、履歴参照、レビュー支援という複数の役割に分解し、人間のレビュー対象を生の差分から構造的主張と証拠の対応へ移す方法を論じる。最後に、この方法の評価設計、限界、妥当性への脅威を整理し、AI エージェント時代における人間の設計責任の位置づけを明確にする。

本稿の研究課題（Research Question: RQ）は、次の三点である。RQ1 は、AI エージェントが生成する PR において、どの単位の構造的主張と証拠を記録すれば、人間のレビュー可能性が高まるかである。RQ2 は、Codebase-Grounded Consensus が、既存のトレーサビリティ、アーキテクチャ適合性検査、ADR、CI と比べて、どの問題を追加的に扱うのかである。RQ3 は、主張と証拠の対応表が、設計リスク指摘率、原因特定時間、アーキテクチャ逸脱の蓄積にどのような影響を与えるかである。

本稿の基本的な主張は、次のように要約できる。AI エージェント時代に必要なのは、コードの外部にもう一つの真実を作ることではない。必要なのは、コードベースがすでに保持している構造的情報と、人間が記録すべき設計判断とを接続し、変更ごとの主張と証拠をレビュー可能にすることである。コードは実行可能な実装状態の中心的証拠であり、テストは振る舞いの証拠であり、git は時間軸であり、ADR は理由である。合意層は、それらを置き換えるものではなく、それらを横断して AI と人間が共有できる派生的な索引として設計されなければならない。

第2章　先行提案としてのコンセンサス層 C

本章では、Wang らが提案する Agentic Consensus と、その中核に置かれるコンセンサス層 C の問題意識を整理する。LLM を基盤とする AI エージェントは、自然言語の要求からコード変更を生成し、テストを実行し、失敗を修正する能力を高めている。SWE-bench、SWE-agent、AutoCodeRover、OpenHands などの研究は、実在するソフトウェアリポジトリを対象に、AI エージェントがバグ修正や機能変更を行う可能性を示している（Jimenez et al. 2024; Yang et al. 2024; Zhang et al. 2024; Wang et al. 2025）。この進展は、AI エージェントがソフトウェア開発の周辺的な補助ではなく、変更を生成する実行主体として関与しうることを示している。

しかし、Wang らが指摘するように、AI エージェントの実装能力が高まるほど、変更の意味を人間がどのように統制するかという問題が顕在化する。コード差分は、実装の結果を示すが、その差分が依拠した構造的前提、設計判断、代替案、リスク評価、検証根拠を自動的に説明するわけではない。AI エージェントとの対話履歴には一部の理由が残ることがあるが、対話はしばしば長く、非構造的であり、後続のレビュー担当者が体系的に参照できる形式ではない。Wang らは、コードとチャット履歴が主要な成果物になることで、構造的コミットメント、依存関係、証拠が低次元のテキストへ圧縮される現象を dimension collapse と呼ぶ（Wang et al. 2026）。

dimension collapse の本質は、単に情報量が減ることではない。より重要なのは、情報の関係性が失われる点である。たとえば、「認証処理を共通ミドルウェアへ移す」という変更は、コード上は関数の移動や呼び出し箇所の変更として表れる。しかし、その背後には、認可の責務境界、例外時の挙動、監査ログの記録方針、既存エンドポイントとの互換性、性能上の制約など、多数の構造的主張が存在する。これらが明示されない場合、レビュー担当者は生の差分から設計意図を推測しなければならない。AI エージェントが生成する差分が大きく、頻度も高い場合、この推測負荷は急速に増大する。

コンセンサス層 C は、この問題に対する先行提案として位置づけられる。C は、単なるコメント、設計メモ、チャット要約ではなく、人間と AI エージェントが共有する操作可能な世界モデルとして構想されている。そこには、構造的主張、不変条件、依存関係、設計判断、ライブラリ選定理由、検証証拠などが明示的に記録される。Wang らは、C を型付きプロパティグラフとして表現することで、個々のコード要素、設計上の制約、証拠、判断理由を関係として接続しようとする（Wang et al. 2026）。プロパティグラフは、ノードとエッジに属性を持たせ、実体と関係を柔軟に表現するモデルであり、複雑な依存関係を扱う基盤として用いられてきた（Angles 2018）。

C が保持しようとする情報は、大きく三種類に分けられる。第一は、ソフトウェア構造に関する主張である。モジュール境界、依存方向、公開インターフェース、データモデル、セキュリティ境界などがこれに含まれる。第二は、判断理由に関する情報である。なぜ特定のライブラリを採用したのか、なぜ既存の抽象を変更したのか、どの代替案を退けたのかという理由は、コードだけからは読み取りにくい。第三は、証拠に関する情報である。テスト、静的解析、CI の結果、運用ログ、性能測定は、構造的主張が実際に満たされているかを検証する根拠となる。

このような C の意義は、人間と AI エージェントの共通理解を、自然言語の会話だけに依存させない点にある。検索拡張生成（Retrieval-Augmented Generation: RAG）は、外部知識を検索して生成に組み込む一般的な自然言語処理手法として提案されてきた（Lewis et al. 2020）。ただし、Lewis らの研究は、ソフトウェアリポジトリ内の設計制約と過去の実装断片を識別する問題を直接扱うものではない。本稿の対象であるソフトウェア変更では、検索された文脈が、現在も守るべき設計制約なのか、単なる過去の実装上の経緯なのかを、PR レビュー時点で区別する必要がある。リポジトリレベルのコード生成においても、関連ファイルや依存関係を適切に取得することの重要性が指摘されている（Shrivastava, Larochelle, and Tarlow 2023; Liu, Xu, and McAuley 2023）。C は、この検索対象を単なるテキスト断片ではなく、構造的に意味づけられた主張と証拠として整理することを目指す。

また、C はレビューの単位を変える。従来の PR レビューでは、レビュー担当者は差分、テスト結果、説明文を横断的に読み、変更の妥当性を判断する。C が存在する場合、レビュー対象は「この関数が変更されたか」だけではなく、「この変更はどの不変条件に影響するか」「その不変条件を支える証拠は何か」「過去の設計判断と矛盾しないか」という問いへ移る。すなわち、C は、コード差分を構造的主張と証拠の対応として再提示するレビュー対象として機能しうる。

Wang らの関連研究整理と本稿が参照するソフトウェア工学文献の範囲からは、本稿の問題設定に照らして既存研究が主目的としてこなかった論点を五つに整理できる。これは各研究領域全体の欠陥を主張するものではなく、AI エージェントが生成する個々の PR において、構造的主張と検証証拠をレビュー単位で対応づけるという本稿の目的から見た整理である。第一に、文芸的プログラミング、実行可能知識グラフ、UML、ADR などの構造表現は、設計意図や再現性を補助しうるが、実装・テスト・運用証跡との双方向同期を PR ごとに保証することを主目的とはしない（Wang et al. 2026）。第二に、CPG や型付きコードグラフを用いる研究は、コード理解の意味的忠実度を高める一方で、判断理由、証拠、不確実性、人間の合意形成までを同じレビュー対象として扱うわけではない（Yamaguchi et al. 2014; Wang et al. 2026）。第三に、Wang らが整理する信頼、安全性、監査可能性、説明可能性に関する研究は、AI エージェントを統制する原則を与えるが、本稿が扱うような個々の PR における構造的主張と検証証拠の対応づけとは焦点が異なる（Wang et al. 2026）。第四に、複数エージェントによるソフトウェア開発フレームワークは、役割分担と反復的改善を導入するが、協調の基盤が主としてメッセージ交換に置かれる場合、合意内容をコードベース上の検証可能な構造として残すには追加の仕組みが必要になる（Tao et al. 2024; Wang et al. 2025）。第五に、SWE-bench などのベンチマークは issue 解決やテスト通過を測るが、構造的整合性、人間の介入距離、証拠に基づくレビュー可能性を主要な評価対象にするものではない（Jimenez et al. 2024; Wang et al. 2026）。

この観点は、AI エージェントの評価にも影響する。単に issue を解決したか、テストを通過したかだけでは、変更が将来の保守性や設計整合性を損なっていないかを十分に評価できない。Wang らの提案は、AI エージェントの能力を、コード生成能力だけでなく、合意を維持する能力として評価すべきだと示唆している（Wang et al. 2026）。これは、ソフトウェア開発における成果物をコードのみに限定せず、コード、設計判断、証拠、履歴を結合したものとして捉え直す発想である。

もっとも、本章での整理は、C を無批判に受け入れるものではない。C が提示する問題意識は重要であるが、C をコードとは別の主要成果物として扱う場合には、抽象モデルと実装の乖離という別の問題が生じうる。この点は次章で検討する。本章で確認すべき結論は、Wang らの提案が、AI エージェント時代において人間のレビュー対象が生の差分だけでは不十分になることを明確化した点にある。C の価値は、コード生成の速度を上げることではなく、変更の意味、制約、証拠を人間と AI エージェントが共有可能な形へ構造化しようとする点にある。

第3章　コンセンサス層 C の運用リスク：統一モデリング言語的失敗の再来可能性

前章で見たように、コンセンサス層 C は、AI エージェントによるソフトウェア変更を、人間が構造的にレビューするための重要な問題提起である。Wang らの提案における C は、単なる自然言語ドキュメントではなく、構造的主張、不変条件、依存関係、証拠を結ぶ操作可能な世界モデルであり、型付きプロパティグラフとして管理されることが想定されている（Wang et al. 2026）。同論文は、コード、設定、テストなどの実行可能成果物と C の関係を問題にしており、C を手書き文書として孤立させることを目的としているわけではない。

したがって、本章の批判対象は、Wang らの問題設定そのものではない。本稿が批判するのは、C をコードベースから独立した単一の真実（single source of truth）、すなわち他の成果物が従属すべき唯一の正本として運用する解釈である。Wang らは、C を主要な工学成果物とし、実行可能成果物を C から導出し、また実行可能成果物から C を再構成する往復同期を重視する（Wang et al. 2026）。この構想は、C を孤立文書にするという単純な提案ではない。しかし、「主要成果物」としての C が、実務上、コードベースから独立した正本として管理されるなら、C の正しさとコードの正しさを別々に維持する必要が生じる。本章では、この運用リスクを、抽象モデルと実行可能コードの乖離、コードベースがすでに持つ構造性、そして本当に不足している情報の所在という三つの観点から検討する。

UML や MDE は、実装より高水準のモデルを用いてソフトウェアを記述し、設計と実装の関係をより明確にしようとする試みであった。UML はクラス、シーケンス、状態、ユースケースなどを記述するための標準的な表記法を提供し、MDE はモデル変換やコード生成を通じて、モデルを開発プロセスの中心に置こうとした（Booch, Rumbaugh, and Jacobson 1999; Atkinson and Kühne 2003）。これらの発想は、設計意図を明示し、抽象度の高いレベルでシステムを理解するためには有用である。しかし、実務においては、モデルとコードの同期、ツールチェーンの複雑性、例外的な実装判断の表現、組織的導入コストが継続的な課題となった（France and Rumpe 2007; Whittle, Hutchinson, and Rouncefield 2014）。

この歴史が示すのは、抽象モデルが価値を持たないということではない。問題は、抽象モデルが実装から独立した中心成果物として扱われたときに、実行環境の複雑性を十分に反映できなくなる点である。現実のソフトウェアは、プログラミング言語の型システム、標準ライブラリ、外部依存、フレームワークの慣習、データベースの制約、設定ファイル、ビルド環境、CI、運用環境によって動作する。性能上の最適化、移行期間中の暫定処理、依存ライブラリの不具合回避、過去の障害対応に由来する例外などは、抽象モデルだけでは十分に表しにくい。

C をコードとは別の主要成果物にする場合も、同様の整合維持コスト（alignment cost）が生じる。すなわち、コードが変更されるたびに C を更新し、C が変更されるたびにコードとの整合性を検査しなければならない。AI エージェントが C を自動更新できるとしても、更新内容が実装の意味を正しく反映しているかを検証する責任は残る。むしろ、もっともらしい自然言語やグラフ構造で誤った設計判断が記録される場合、人間はコードだけでなく C の正しさもレビューしなければならない。このとき C は、レビュー負荷を軽減するのではなく、二重管理の対象になりうる。

この懸念は、Wang らの提案そのものを単純に否定するためのものではない。同論文は、実行可能成果物（artifacts: A）と合意層 C を、実現演算子（realize: Φ）と再水和演算子（rehydrate: Ψ）によって往復同期する必要があると述べ、厳密な同型性ではなく構造的ドリフトを監視する近似として扱う（Wang et al. 2026）。また、Ψ が曖昧な場合には単一の解を確定せず、候補差分と不確実性を提示し、人間への確認を促す設計を想定している。したがって、Wang らは同期問題を認識している。本稿の論点は、この同期問題を設計上の中心に置くなら、C の価値は Φ と Ψ が継続的に機能し、証拠リンクが信頼でき、不確実性の閾値が適切に設定される場合に限って成立する、という点である。これらが満たされない場合、C は統制の手段ではなく、誤った構造的確信を生む原因になりうる。

さらに、Wang らは自らの限界として、証拠の信頼性、エージェントによる構造幻覚、大規模レガシーシステムに対する完全な再水和の困難、低コストな変更に対する逃げ道の必要性を挙げている（Wang et al. 2026）。これは、先行提案としての Agentic Consensus が、原理的には強力であっても、実務導入の単位、証拠の十分性、漸進的採用の境界条件をさらに具体化する余地を残していることを意味する。本稿の批判は、この未解決点に向けられる。すなわち、C が必要か否かではなく、C を何から生成し、何によって検証し、どの粒度で人間の判断へ返すべきかが問題である。

さらに、C の議論には、コードを「一次元のテキスト」として過度に低く評価する危険がある。確かに、ソースコードはファイル上では文字列として保存される。しかし、現代のコードベースは単なる文字列の集合ではない。型、モジュール境界、名前空間、公開インターフェース、依存関係、テスト、スキーマ、マイグレーション、設定、ビルド定義、静的解析、履歴管理によって、多くの構造的情報をすでに保持している。コードプロパティグラフ（Code Property Graph: CPG）は、抽象構文木、制御フロー、データフローなどを統合し、脆弱性発見に用いられてきた（Yamaguchi et al. 2014）。これは、コードが構造的分析の対象になりうることを示している。

リポジトリレベルのコード生成研究も、コードベースが豊富な文脈を持つことを前提としている。Repository-Level Prompt Generation は、単一ファイルではなくリポジトリ全体から関連文脈を取得する必要を示し、RepoBench はリポジトリレベルの補完能力を評価する枠組みを提供した（Shrivastava, Larochelle, and Tarlow 2023; Liu, Xu, and McAuley 2023）。また、GraphCodeAgent は、要求グラフ（requirement graph）とリポジトリ側のコードグラフを用いて、実世界のコード生成に必要な支援コードを検索する方向を示している（Li et al. 2025）。これらの研究は、コードベースが AI エージェントにとって単なる文字列ではなく、検索、解析、推論の対象となる構造的環境であることを示す。

したがって、問題はコードに構造がないことではない。問題は、コードが持つ構造、git 履歴が持つ時間的文脈、テストが持つ振る舞いの証拠、ADR が持つ理由、PR が持つ議論、運用証跡が持つ実行時の事実が、相互に十分接続されていないことにある。たとえば、ある依存ライブラリが採用された理由は ADR に残っていても、そのライブラリを呼び出すコード、失敗時のフォールバック、互換性テスト、過去の障害記録とリンクされていなければ、後続の変更時に実質的な制約として機能しにくい。

この観点から見ると、C の目的は「コードの外部により正しい真実を作ること」ではなく、「コードベースが保持する構造と、コードだけでは表しにくい理由や証拠を接続すること」でなければならない。アーキテクチャ知識管理の研究は、ソフトウェアアーキテクチャを構造だけでなく設計判断の集合として扱う必要を示してきた（Jansen and Bosch 2005; Kruchten, Lago, and van Vliet 2006）。また、ADR は重要な判断を軽量に記録する方法として有用であるが、それがコードやテストと切り離されれば、陳腐化した文書になりうる（Tyree and Akerman 2005; Nygard 2011）。

以上の批判は、C の問題意識を否定するものではない。むしろ、C が解くべき問題をより限定するものである。AI エージェント時代に必要なのは、コードより上位にある完全な抽象モデルではない。必要なのは、実行可能コードを中心に置きながら、設計判断、制約、履歴、証拠を検証可能な形で接続する仕組みである。C がこの接続を支援する派生的な索引であるならば有用である。しかし、C がコードから独立した正本になるならば、UML や MDE と同じく、抽象と実装の乖離を管理するための新たな負荷を生む。本稿が提案する Codebase-Grounded Consensus は、この批判を踏まえ、合意層をコードベースに接地されたレビュー用の派生インデックスとして再設計する試みである。

第4章　代替方針：Codebase-Grounded Consensus

本章では、コンセンサス層 C をコードの外部にある独立した真実として扱うのではなく、コードベースを中心に再構成される派生的な合意層として位置づける方法論を提示する。この方法論を、Codebase-Grounded Consensus と呼ぶ。ここでいう codebase-grounded とは、合意の根拠を抽象的な設計文書だけに置かず、実行可能なコード、テスト、型、スキーマ、設定、マイグレーション、git 履歴、CI 結果、運用証跡に接地させることを意味する。

Codebase-Grounded Consensus が成立したと言えるための最小条件は、次の三点である。第一に、変更ごとに構造的主張（claim）が明示され、互換性、依存関係、セキュリティ、データ移行、性能、運用影響などの型に分類されていること。第二に、各 claim が検証証拠（evidence）に接続され、証拠が存在しない場合には証拠を持たない主張（unsupported claim）として区別されていること。第三に、claim、evidence、判断理由（rationale）、関連コード、関連テスト、履歴が同じレビュー単位で追跡でき、変更後も CI や静的解析によって再検査できること。これらを満たさない記録は、単なる PR 説明や設計メモであり、本稿の意味での合意層ではない。

Codebase-Grounded Consensus の出発点は、ソフトウェアにおける真実の性質を分解して捉えることである。コードは実行可能な実装状態の中心的証拠であるが、実行時挙動の完全な真実ではない。実際の挙動は、設定、デプロイ状態、実行時データ、外部サービス、ライブラリのバージョン、運用環境、未定義動作、障害時条件によって左右される。テストは期待される振る舞いに関する証拠を表し、git は変更の時間的経緯を表し、ADR は判断理由を表し、PR や issue は議論と合意の痕跡を表す。運用ログやメトリクスは実行時の観測事実を表す。これらのいずれか一つだけが、ソフトウェアの全体的な真実を表すわけではない。合意層は、これらを置き換える単一の文書ではなく、それらの関係を横断的に参照する索引でなければならない。

この立場では、C は一次成果物ではなく派生成果物である。一次成果物とは、実行され、テストされ、デプロイされ、障害を起こしうるコードベースと、その実行状態を示す設定、デプロイ情報、運用ログである。派生成果物とは、一次成果物から抽出された構造情報と、人間が明示的に記録した判断理由を結合し、レビューや推論のために提示する索引である。したがって、C は人間が手作業で維持する独立文書ではなく、コード解析、テスト結果、CI 結果、git 履歴、ADR、PR メタデータから継続的に生成・更新されるべきである。

この定義において、構造的主張と検証証拠の関係は、四つの状態語彙に統一する。supported は、主張型ごとに事前定義された必須証拠がそろい、かつ既知の証拠と矛盾しない状態である。partially_supported は、補助証拠はあるが必須証拠の一部が欠けている、または手動確認や ADR のように再現性の低い証拠だけが存在する状態である。unsupported は、主張は存在するが対応する証拠がない、または証拠の十分性が未判断である状態である。contradicted は、証拠が主張と矛盾する状態であり、たとえば「後方互換である」という主張に対してスキーマ差分が破壊的変更を示す場合が該当する。合意層の価値は、すべての主張を自動的に真にすることではなく、これらの状態をレビュー前に可視化することにある。

この方針は、Wang らの問題意識を保持しつつ、その中心を移す。Wang らは、AI エージェントと人間が共有する合意層 C を主要な工学成果物とすることで、構造的主張と証拠を明示化しようとした（Wang et al. 2026）。本稿は、この方向性を、人間の統制可能性を高める重要な提案として評価する。しかし、C をコードより上位の正本として扱うのではなく、コードベースから導かれるレビュー用の派生インデックスとして扱う。これにより、抽象モデルと実装の乖離を避けつつ、設計意図と証拠の接続を強化できる。

この位置づけにより、本稿の独自性は三点に集約される。第一に、合意層の根拠を、抽象グラフの完全性ではなく、コード、テスト、CI、静的解析、スキーマ、git 履歴、ADR、運用証跡からなる証拠群に置く点である。第二に、AI エージェントが生成する自然言語説明を信頼の対象にせず、構造的主張と検証証拠の対応関係をレビュー対象にする点である。第三に、合意層を巨大な世界モデルとして一括導入するのではなく、PR 単位の claim、required evidence、observed evidence、status、人間判断として操作化し、漸進的に導入できるようにする点である。

この差分は、Wang らが示す問題意識と、本稿が参照する周辺研究の射程の差に対応している。文書や ADR が実行可能証拠から切り離される問題に対しては、ADR を単独の真実ではなく関連コード、テスト、CI 結果へのリンクとして扱う。コードグラフ研究が主にコードレベルの意味表現を扱う点に対しては、設計判断、証拠、不確実性を PR レビューの単位へ拡張する。複数エージェントフレームワークがメッセージプロトコルを中心に協調する点に対しては、エージェント間の合意をログではなくコードベース由来の主張と証拠の対応表へ投影する。ベンチマークがテスト通過や issue 解決を主要な評価対象にする点に対しては、証拠なし主張、アーキテクチャ逸脱、診断遅延など、合意の品質を測る候補指標を導入する。したがって、Codebase-Grounded Consensus は Agentic Consensus の反対概念ではなく、同論文が明らかにした表現上のギャップを、既存コードベース上で検証可能に扱うための再設計である。

Codebase-Grounded Consensus の第一原則は、実行可能性である。合意層に記録された主張は、可能な限り実行可能な証拠に接続されなければならない。たとえば、層化アーキテクチャにおけるドメイン層、すなわち事業規則や不変条件を表す層は、インフラストラクチャ層、すなわちデータベースや外部サービスとの接続を担う層に直接依存しない、という主張がある。この主張は、ADR に記述されるだけでは不十分であり、アーキテクチャテスト、静的解析、依存関係検査によって継続的に検証されるべきである。「外部決済のアプリケーションプログラミングインターフェース（Application Programming Interface: API）の失敗時には注文状態を確定しない」という主張は、仕様文書だけでなく、単体テスト、統合テスト、障害時のログ、監視アラートと接続されるべきである。合意は、記述された時点ではなく、検証され続けるときに効力を持つ。

第二原則は、追跡可能性である。あるコード変更がどの設計判断に基づき、どの不変条件へ影響し、どの証拠によって安全と判断されたのかを追える必要がある。アーキテクチャ知識管理の研究は、設計判断の履歴がシステム理解と進化に重要であることを示している（Jansen and Bosch 2005; Kruchten, Lago, and van Vliet 2006）。ADR はこの追跡可能性を軽量に支える実務的手段である（Tyree and Akerman 2005; Nygard 2011）。ただし、ADR が単独で保存されるだけでは不十分であり、関連するコード、テスト、PR、障害記録へリンクされることで、変更時の実用的な文脈となる。

第三原則は、最小十分性である。すべての変更を詳細な形式モデルとして記録しようとすれば、開発速度を損ない、ドキュメント疲れを生む。したがって、明示的な記録対象は、将来の変更コストや障害リスクが高い判断に限定すべきである。依存関係、モジュール境界、データモデル、セキュリティ境界、ライブラリ選定、移行方針、性能上の制約、運用上の制約は記録に値する。一方、局所的で可逆的な実装詳細まで同じ粒度で記録する必要はない。合意層は、網羅的な百科事典ではなく、変更時にリスクを見落とさないための実用的な索引である。

第四原則は、AI エージェントの出力を証拠に従属させることである。LLM を用いるエージェントは、構造的主張や判断理由を自然言語で生成できる。しかし、それらはもっともらしい説明であっても、正しいとは限らない。Chain-of-Thought、ReAct、Tree of Thoughts、Self-Refine などの研究は、LLM の推論や行動の能力を高める方法を示してきたが、それは生成された説明が実行可能な事実と一致することを保証するものではない（Wei et al. 2022; Yao, Zhao, et al. 2023; Yao, Yu, et al. 2023; Madaan et al. 2023）。したがって、AI エージェントが生成した claims は、テスト、静的解析、CI、履歴、レビューによって検証される必要がある。

Codebase-Grounded Consensus は、既存の開発実践を置き換えるものではない。むしろ、既存の実践を接続し直す枠組みである。現代的なソフトウェア開発では、コードレビュー、テスト、静的解析、CI、ADR、変更提案テンプレート、運用監視の一部がすでに導入されていることが多い。しかし、それらはしばしば別々のツールや文脈に分散しており、AI エージェントが変更を生成する際に一貫して参照されない。本稿の提案は、これらを「構造的主張」と「証拠」の対応として再構成し、人間と AI エージェントが同じレビュー対象を共有できるようにすることである。

したがって、本章の結論は次のように整理できる。AI エージェント時代に必要な合意層は、コードの外部に置かれた第二の真実ではない。必要なのは、コードベースがすでに保持する構造的情報と、人間が明示的に記録すべき設計判断を結合し、変更ごとの主張と証拠をレビュー可能にする派生的な合意層である。この方針によって、AI エージェントの速度を利用しながら、人間が設計責任を保持するための実務的な基盤を構築できる。

第5章　構成要素：コード・履歴・テスト・設計記録の統合

本章では、Codebase-Grounded Consensus を構成する具体的な要素を整理する。中心となるのは、コードベース、git 履歴、テスト、静的解析、アーキテクチャテスト、静的な構文・規約検査器である linter、スキーマ、ADR、変更提案テンプレート、issue、運用メトリクスである。重要なのは、これらを単に列挙することではない。それぞれを、構造的主張と証拠の対応を作るための要素として位置づけることである。

第一の構成要素は、コードベースそのものである。コードは、実行可能な実装状態の中心的証拠である。ただし、コードだけが実際のシステム挙動を完全に表すわけではない。設定、デプロイ状態、実行時データ、外部サービス、依存ライブラリ、運用環境と結合して初めて、観測可能な挙動が決まる。型、関数、クラス、モジュール、パッケージ、名前空間、公開インターフェース、設定、ビルド定義は、設計上の境界や依存関係を部分的に表現している。CPG が抽象構文木、制御フロー、データフローを統合して脆弱性発見に用いられるように、コードは構造的解析の対象となる（Yamaguchi et al. 2014）。プロパティグラフモデルは、ノードとエッジに属性を持たせることで、こうした構造を横断的に表現する基盤になりうる（Angles 2018）。

第二の構成要素は、git 履歴である。git は、コードの現在状態だけでなく、変更の時間的文脈を保持する。どのファイルが同時に変更されたのか、どの変更がどの issue や PR と対応するのか、どのコミットで依存関係が導入されたのか、どの revert が過去の失敗を示しているのかは、設計意図を推測するための重要な手がかりとなる。AI エージェントが現在のコードだけを見て変更を行う場合、過去に退けられた設計や障害対応の理由を見落とす可能性がある。履歴参照エージェントが必要になる理由はここにある。

第三の構成要素は、テストと CI である。テストは、期待される振る舞いに関する実行可能な証拠である。単体テストは局所的な関数やクラスの契約を示し、統合テストは複数コンポーネントの相互作用を示し、エンドツーエンドテストは利用者視点の振る舞いを示す。CI は、これらのテスト、ビルド、linter、静的解析を変更ごとに実行し、証拠を継続的に収集する。したがって、合意層における claim は、可能な限り CI で再現可能な evidence に接続されるべきである。

第四の構成要素は、静的解析、linter、アーキテクチャテストである。これらは、設計上の制約を機械的に検査可能な形へ変換する。たとえば、「ドメイン層はインフラストラクチャ層に依存しない」という主張は、コードレビューで注意するだけではなく、依存関係検査やアーキテクチャテストとして自動化できる。「公開 API は後方互換性を維持する」という主張は、スキーマ検査や契約テストと接続できる。「機密情報をログに出力しない」という主張は、静的解析やログ検査と接続できる。このような制約は、人間の記憶に依存させるほど脆弱になる。

第五の構成要素は、スキーマとマイグレーションである。多くのソフトウェアでは、データモデルの変更が最も高いリスクを伴う。データベーススキーマ、API スキーマ、イベントスキーマ、設定スキーマは、コンポーネント間の契約を表す。スキーマ変更は、後方互換性、移行順序、データ修復、ロールバック可能性、監視項目と結びつけて扱う必要がある。AI エージェントが局所的なコード変更だけを生成した場合、スキーマ変更に伴う運用上の制約を見落とす危険がある。したがって、合意層はスキーマ差分を単なるファイル変更ではなく、契約変更として扱う必要がある。

第六の構成要素は、ADR、PR、issue である。ADR は重要な設計判断を、背景、決定、代替案、影響として記録する方法であり、アーキテクチャ知識を保持する実務的な手段である（Tyree and Akerman 2005; Nygard 2011）。ソフトウェアアーキテクチャを設計判断の集合として捉える研究も、判断理由の記録と活用の重要性を示している（Jansen and Bosch 2005; Kruchten, Lago, and van Vliet 2006）。PR と issue は、より短期的な変更理由、議論、レビューコメント、合意の痕跡を保持する。これらは、コードだけでは表現しにくい「なぜ」を補足する。

ただし、ADR や PR は、それだけでは合意層として不十分である。記録された理由が、関連コード、テスト、CI 結果、運用証跡と接続されなければ、後続の変更時に実用的な制約になりにくい。たとえば、「外部検索エンジンを採用する」という ADR は、利用箇所、障害時のフォールバック、性能テスト、監視項目、契約更新の責任者と接続されて初めて、将来の変更に対する有効な知識となる。ADR は理由を保存するが、証拠との接続を自動的に保証するわけではない。

第七の構成要素は、運用メトリクスと障害記録である。ソフトウェアの正しさは、開発時のテストだけでは完結しない。実際の負荷、データ分布、外部サービスの失敗、利用者行動、監視アラートは、設計判断の妥当性を検証する実行時の証拠となる。性能改善、キャッシュ導入、リトライ制御、レート制限、データ移行のような判断は、運用上の観測なしには評価できない。Codebase-Grounded Consensus は、開発時の合意だけでなく、運用から得られる証拠を将来の設計判断へ戻す経路を持つ必要がある。

これらの構成要素を統合する鍵は、構造的主張（claim）と検証証拠（evidence）の対応である。本稿では、初出後も、本文では日本語の「主張」「証拠」「判断理由」を主に用い、表やスキーマの列名では claim、evidence、rationale を用いる。構造的主張とは、「この変更は認証境界を変更しない」「この API は後方互換である」「この依存関係はドメイン層に漏れない」「この移行はロールバック可能である」といった、変更が満たすべき検査可能な主張である。検証証拠とは、その主張を支えるテスト、静的解析、CI 結果、スキーマ検査、ADR、レビュー記録、運用ログである。証拠なし主張（unsupported claim）とは、主張として明示されているにもかかわらず、対応する証拠が存在しない、または十分性が未判断の主張である。判断理由（rationale）とは、主張を採用した理由、退けた代替案、リスク許容、組織的制約を説明する情報であり、証拠そのものではない。

主張の粒度は、レビュー担当者が yes、no、unknown のいずれかで判断できる程度でなければならない。「設計を改善した」は広すぎる主張である。一方、「決済ゲートウェイ（gateway）は注文状態を確定する前に冪等性キー（idempotency key）を検証する」は、対象コード、テスト、障害時挙動に接続できるため適切な粒度である。ここでゲートウェイとは、外部サービスとの通信境界を隠蔽するアダプタであり、冪等性キーとは、同一操作の重複実行を識別して二重処理を防ぐためのキーである。アダプタとは、外部サービスや異なるインターフェースを、コードベース内部の期待する形式へ変換する境界部品を指す。Codebase-Grounded Consensus で優先的に扱う主張型は、次のように整理できる。

最小スキーマは、複雑な形式言語である必要はない。PR 単位で、claim_id、claim_type、scope、statement、required_evidence、observed_evidence、status、rationale_ref、human_decision、owner、source、last_checked_at を保持できればよい。status は、第4章で定義した supported、partially_supported、unsupported、contradicted の四値に統一する。重要なのは、AI エージェントの説明をそのまま信用することではなく、主張の型、必要な証拠、実際に得られた証拠、人間が判断すべき残余を同じ表で扱うことである。

PR 単位のデータモデルは、次の入力から生成される。

主張の抽出単位は、レビュー担当者が真偽または未知を判断でき、かつ一つ以上の証拠に接続できる単位とする。抽出規則は、差分に含まれるファイル種別と変更対象から始める。公開 API、イベント、データベーススキーマ、認証・認可、外部依存、設定、マイグレーション、性能に関わる差分は、対応する主張型を必ず生成する。その他の局所的なリファクタリングは、アーキテクチャ境界、公開契約、運用手順に影響しない限り、明示的な主張を要求しない。これにより、すべての実装詳細を形式化する負荷を避ける。

required_evidence は、PR 作成時にその場で恣意的に決めるのではなく、リポジトリごとのポリシーとして事前に定義する。たとえば、互換性主張には契約テストまたはスキーマ差分検査、セキュリティ主張には認可テストと静的解析、データ移行主張にはマイグレーションテストとロールバック計画を要求する。高リスク変更では、人間レビューを必須証拠に含めることもできる。観測された証拠は CI のジョブ名、成果物、ログ、テストケース識別子と結びつける。CI は、ジョブ成功の一覧だけでなく、どのジョブがどの主張を支えたかを機械可読な表として出力する。

矛盾判定は、証拠型ごとの否定条件を明示して実装する。契約テスト失敗、破壊的スキーマ差分、禁止依存の検出、セキュリティスキャンの高重大度検出、性能しきい値超過は、関連する主張を contradicted に遷移させる。必須証拠がすべて成功した場合は supported、一部だけ成功した場合や ADR・手動確認のみの場合は partially_supported、証拠がない場合は unsupported とする。人間は、partially_supported と unsupported に対して、追加証拠を要求するか、リスクを明示的に受容するか、変更を差し戻すかを記録する。

保存形式は、リポジトリ内の変更提案テンプレート、CI 生成の JavaScript Object Notation（JSON）または YAML（YAML Ain't Markup Language）、レビューコメントのいずれでもよい。ただし、履歴分析と再検査を可能にするため、最終的な対応表は PR に紐づく機械可読な成果物として保存される必要がある。これにより、後続の障害調査やアーキテクチャ逸脱分析で、どの主張がどの証拠に基づいて承認されたのかを追跡できる。

したがって、Codebase-Grounded Consensus の構成要素は、既存のツール群を新しい名前で呼び直すことではない。コード、履歴、テスト、設計記録、運用証跡を、変更ごとの構造的主張と証拠の関係として再編成することである。これにより、人間のレビューは、すべての差分を逐語的に読む作業から、重要な主張、証拠不足、設計上の逸脱を検査する作業へと移行できる。

第6章　AI エージェントの役割分担：実装者だけでなく複数の専門エージェントへ

AI エージェントをソフトウェア開発に導入する際、しばしば中心に置かれるのは、実装者（Builder）としての能力である。すなわち、issue を読み、コードを変更し、テストを実行し、失敗を修正する能力である。SWE-agent、AutoCodeRover、OpenHands などの研究は、この方向の能力が急速に発展していることを示している（Yang et al. 2024; Zhang et al. 2024; Wang et al. 2025）。しかし、実装者としてのエージェントだけに依存すると、設計意図、不変条件、依存関係、過去の判断、証拠の対応が十分に整理されないまま変更が進む危険がある。

この問題は、LLM の推論能力だけでは解決しない。Chain-of-Thought や ReAct は、LLM が中間推論や環境操作を組み合わせる方法を示し、Tree of Thoughts や Self-Refine は、複数案の探索や反復的改善の可能性を示した（Wei et al. 2022; Yao, Zhao, et al. 2023; Yao, Yu, et al. 2023; Madaan et al. 2023）。しかし、推論手順が生成されることと、その推論がコードベースの実際の制約、過去の判断、運用上の事実に一致することは別である。したがって、エージェントの役割は、単一の「賢い実装者」ではなく、複数の責務に分解されるべきである。

第一の役割は、設計整理エージェント（Architect）である。設計整理エージェントは、実装前に変更の構造的主張を列挙する。対象となるモジュール、依存関係、データモデル、外部 API、セキュリティ境界、性能制約、後方互換性、移行手順を確認し、変更が影響しうる不変条件を明示する。ここで重要なのは、実装案をただ説明することではない。変更が守るべき制約、変更してよい制約、判断が必要な未確定点を分離することである。これにより、実装エージェントは局所的な実装に入る前に、設計上の境界を把握できる。

第二の役割は、実装エージェント（Builder）である。実装エージェントは、設計整理エージェントが整理した制約の範囲内でコード変更を行う。実装エージェントに求められるのは、単に要求を満たすコードを生成することではなく、既存のコードベースの構造に沿って変更することである。既存の命名規則、エラー処理、テスト構造、依存注入、設定管理、ログ出力、トランザクション境界を尊重し、必要な場合には局所的なリファクタリングを行う。Fowler が論じるように、リファクタリングは外部的振る舞いを保ちながら内部構造を改善する実践であり、変更容易性を維持するために不可欠である（Fowler 2018）。

ここで、準備的リファクタリング（preparatory refactoring）と事後リファクタリング（refactoring）を区別する必要がある。本稿でいう準備的リファクタリングとは、要求された機能変更を安全に入れるために、変更前に依存関係、命名、テストの足場、抽象境界を小さく整える作業であり、広く定着した独立術語としてではなく操作的な区分として用いる。事後リファクタリングとは、機能変更後に残った重複、責務混在、暫定的な条件分岐を、外部的振る舞いを保ったまま整理する作業である。AI エージェントは、明示的な issue を解くことに最適化されると、これらを「要求外の変更」と見なして避けるか、逆に証拠のない大規模整理へ拡張しがちである。Codebase-Grounded Consensus では、準備的リファクタリングと事後リファクタリングも主張と証拠の対象に含める。たとえば、「変更前に外部サービス境界を隠蔽するゲートウェイを分離する」「変更後に一時的なアダプタを削除する」という主張を立て、それぞれアーキテクチャテスト、既存テストの通過、差分範囲、人間レビューに接続する。

第三の役割は、監査エージェント（Auditor）である。監査エージェントは、実装後に、構造的主張と証拠の対応を検査する。単体テスト、統合テスト、CI、静的解析、linter、アーキテクチャテスト、依存関係検査、スキーマ検査を実行し、各 claim がどの evidence によって支えられているかを整理する。ここで linter とは、第5章で述べた静的な構文・規約検査器である。重要なのは、テストが通ったかどうかだけではなく、テストがどの主張を検証しているかを対応づけることである。未検証の claim は、レビュー時に明示的なリスクとして提示されるべきである。

第四の役割は、履歴参照エージェント（Historian）である。履歴参照エージェントは、過去の git 履歴、ADR、PR、issue、障害記録、ライブラリ更新履歴を参照する。ソフトウェアの現在の形は、過去の制約や失敗の蓄積である。ある依存関係がなぜ避けられているのか、ある抽象がなぜ分割されているのか、あるテストがなぜ冗長に見えるのかは、現在のコードだけでは分からない場合がある。履歴参照エージェントは、こうした時間的文脈を変更前後に補足する。

第五の役割は、レビュー支援エージェント（Reviewer Navigator）である。レビュー支援エージェントは、人間のレビュー対象を生の差分から構造的リスクへ変換する。具体的には、変更された不変条件、証拠が不足している主張、過去の ADR と矛盾しうる点、依存方向の変化、スキーマ変更、運用上の影響を要約する。人間はすべての差分を同じ密度で読むのではなく、設計責任を伴う箇所、機械検査では判断できないトレードオフ、将来の変更コストに影響する箇所へ注意を集中できる。

この役割分担は、単なる複数エージェント化ではない。重要なのは、責務を分けることによって、AI エージェントの出力を相互に検査可能にする点である。設計整理エージェントが提示した claim は、実装エージェントの実装によって満たされる必要がある。監査エージェントは、その対応を証拠に基づいて検査する。履歴参照エージェントは、現在の claim が過去の判断と矛盾しないかを確認する。レビュー支援エージェントは、それらの結果を人間が判断可能な形に整える。これにより、AI エージェントの自己説明をそのまま信じるのではなく、役割間の緊張によって検証する構造が作られる。

ただし、複数エージェントが常に単一エージェントより優れるわけではない。複数エージェント化が必要になるのは、変更が高リスクであり、単一の実装文脈だけでは証拠の独立性が弱い場合である。具体的には、スキーマ変更、セキュリティ境界変更、外部依存の追加、公開 API の変更、広範なモジュール移動、データ移行、性能制約を伴う変更が該当する。小さな局所修正では、単一の実装エージェントと CI で十分な場合がある。

監査エージェントの独立性も明示的に設計しなければならない。同じ基盤モデル、同じプロンプト履歴、同じ検索結果に依存する監査エージェントは、実装エージェントの誤った前提を反復する可能性がある。独立性を高める方法として、監査エージェントに実装時の会話履歴を渡さない、別モデルまたは別プロンプトを使う、証拠を CI ログ、テスト結果、静的解析、スキーマ差分に限定する、固定ルールに基づくチェックを優先する、人間レビューを最終判断として残す、という方針がある。ここでの独立性は心理的な多様性ではなく、入力、手続き、証拠源の非共有性として定義される。

MAGIS のような複数エージェントを用いる GitHub issue 解決の研究は、役割分担がタスク遂行に寄与しうることを示している（Tao et al. 2024）。一方で、Agentless は、複雑なエージェント構成が必ずしも本質ではなく、適切な問題分解と検索・編集手順が重要であることを示唆している（Xia et al. 2024）。したがって、本稿の提案も、エージェントの数を増やすこと自体を目的としない。目的は、設計、実装、検証、履歴参照、レビュー支援という責務を明確化し、各責務の成果物を主張と証拠の対応として接続することである。

以上のように、AI エージェントは単一の実装者としてではなく、設計前提を整理する設計整理エージェント、実装を行う実装エージェント、証拠を検査する監査エージェント、履歴を参照する履歴参照エージェント、人間レビューを支援するレビュー支援エージェントとして分解されるべきである。この構成により、AI エージェントによる変更は、単なるコード差分ではなく、検証可能な設計変更として扱われる。人間の役割も、すべての行を逐語的に確認することから、構造的主張、証拠不足、責任ある判断を検査することへ移行する。

第7章　実装パターン：変更提案テンプレート、ADR、アーキテクチャテスト、CI の連携

本章では、Codebase-Grounded Consensus を実務に導入するための具体的な実装パターンを示す。中心となるのは、変更提案テンプレート、ADR、依存関係判断記録、アーキテクチャテスト、CI チェック、コード検索、静的解析を組み合わせたワークフローである。ここでいう変更提案テンプレートとは、GitHub の PR テンプレートや GitLab の MR テンプレートのように、レビュー前に変更内容、リスク、検証結果を記入する様式を指す。目的は、新しい大規模な管理ツールを導入することではなく、既存の開発実践を構造的主張と証拠の対応として再編成することである。

この提案は、要求トレーサビリティ、ソフトウェアトレーサビリティ、アーキテクチャ適合性検査、アーキテクチャ知識管理、ソフトウェアプロベナンス、ソフトウェアサプライチェーン管理と連続している。要求トレーサビリティは、要求と成果物の関係を追跡する問題として古くから研究されてきた（Gotel and Finkelstein 1994; Gotel et al. 2012）。アーキテクチャ適合性検査は、高水準設計と実装の差異を検出する手法を提供してきた（Murphy, Notkin, and Sullivan 2001）。アーキテクチャ記述標準は、関心事、ビュー、対応関係を明示する枠組みを与える（ISO/IEC/IEEE 2011）。また、ADR の研究は、判断理由を構造化して記録する方法を発展させてきた（Tyree and Akerman 2005; van Heesch, Avgeriou, and Hilliard 2012）。Supply-chain Levels for Software Artifacts（SLSA）v1.2 は、ビルド成果物の来歴と完全性を検証するソフトウェアサプライチェーン上の実践を整理している（OpenSSF 2026）。SBOM は、ソフトウェアを構成するコンポーネントと依存関係を記録し、脆弱性管理、インベントリ、ライセンス管理を支える基礎データ層として位置づけられている（United States Department of Commerce 2021）。OpenSSF Scorecard は、依存関係が導入するリスク、保守状況、ライセンス、依存関係更新ツール、依存関係の固定などを自動検査の対象に含める（OpenSSF Scorecard 2026）。

Codebase-Grounded Consensus の新規性は、これらを置き換えることではない。また、単に対象を「AI エージェントが生成する PR」に限定する点だけでもない。本稿の差分は、第一に、要求や設計判断から実装への長期的な追跡ではなく、PR レビュー時点の主張、必須証拠、観測証拠、状態、人間判断を同じデータモデルで扱う点にある。第二に、証拠があることだけでなく、証拠が不足していること、または証拠が主張と矛盾していることを一級の状態として扱う点にある。第三に、AI エージェントの自然言語説明を成果物として信頼するのではなく、説明を CI、静的解析、スキーマ差分、履歴、ADR によって検査される対象にする点にある。第四に、評価指標を要求充足やテスト通過だけでなく、証拠なし主張数、診断遅延、介入距離として定義する点にある。

既存手法だけでは扱いにくい反例として、AI エージェントが「性能への影響はない」と記した PR を考える。要求トレーサビリティは、その変更がどの要求に対応するかを示せるが、性能主張に必要な負荷試験が欠けていることを PR レビュー時点で状態として扱うとは限らない。アーキテクチャ適合性検査は、禁止依存を検出できるが、検出結果がどの主張を否定し、誰がリスクを受容したのかまでは別管理になりやすい。ADR は判断理由を保存できるが、その判断を支える証拠が現在も有効かを自動的には保証しない。Codebase-Grounded Consensus は、これらの成果を PR 単位の主張と証拠の対応表へ投影し、supported、partially_supported、unsupported、contradicted の状態としてレビュー可能にする。

第一の実装パターンは、PR テンプレートの拡張である。PR には、何を変更したかだけでなく、なぜ変更したか、どの不変条件に影響するか、どの設計判断を行ったか、どの証拠によって安全性を確認したかを記載する欄を設ける。特に、影響範囲、互換性、データ移行、セキュリティ、性能、運用監視、ロールバック方針は、AI エージェントが生成する変更で見落とされやすい。PR テンプレートは、レビュー担当者に説明を強制するための形式ではなく、エージェントと人間が同じ問いに答えるための足場である。

第二の実装パターンは、ADR と依存関係判断記録の使い分けである。ADR は、アーキテクチャ上の重要な判断を背景、決定、代替案、結果として記録する方法である（Tyree and Akerman 2005; Nygard 2011）。一方、依存関係判断記録は、ライブラリ、外部サービス、フレームワーク、プロトコルの採用・更新・廃止について、選定理由、代替案、ライセンス、セキュリティ、保守状況、移行コストを記録する本稿の操作的提案である。これは SBOM や Scorecard の置き換えではない。SBOM が構成要素と依存関係を識別し、Scorecard が保守状況、ライセンス、依存関係更新ツール、依存関係固定などの機械的証拠を与えるのに対し、依存関係判断記録は、それらの証拠を PR 単位の採用理由、代替案、リスク受容へ結びつける。すべてを ADR に入れると粒度が粗くなり、すべてを PR に閉じ込めると長期的な追跡が難しくなるため、判断の寿命と影響範囲に応じて記録場所を分ける必要がある（United States Department of Commerce 2021; OpenSSF Scorecard 2026）。

第三の実装パターンは、アーキテクチャテストによる制約の自動検証である。モジュール境界、依存方向、命名規則、公開 API、禁止された依存関係、循環依存の有無などは、可能な限り機械的に検査する。たとえば、「ドメイン層はインフラストラクチャ層を import しない」「ユーザインターフェース（User Interface: UI）層はデータベースクライアントを直接参照しない」「外部 API のクライアントはゲートウェイ経由で利用する」といった制約は、レビュー担当者の注意に頼るのではなく、CI で継続的に検証する。これにより、設計上の claim が実行可能な evidence に接続される。

第四の実装パターンは、CI による証拠収集である。CI は、テストを実行するだけでなく、主張と証拠の対応表を生成する場として利用できる。単体テスト、統合テスト、スキーマ互換性検査、静的解析、linter、セキュリティスキャン、依存関係検査、アーキテクチャテスト、性能回帰検査の結果を、PR 上の主張に紐づける。これにより、レビュー担当者は「何が通ったか」だけではなく、「どの主張がどの証拠によって支えられているか」を確認できる。

CI との接続は、主張型ごとの規則として定義する。たとえば次のように、PR テンプレートの主張、リポジトリ内のポリシー、CI ジョブの出力を対応させる。

第五の実装パターンは、AI エージェントによる主張と証拠の対応表の生成である。AI エージェントは PR 作成時に、変更内容から構造的主張を抽出し、それぞれに対応する証拠を提示する。たとえば、「既存 API のレスポンス形式は変更されない」という主張に対して、契約テストとスナップショット差分を証拠として示す。「新しいキャッシュ層は認可判断を変更しない」という主張に対して、認可テストとアーキテクチャテストを証拠として示す。対応する証拠が存在しない場合は、証拠なし主張として明示する。

ただし、AI エージェントが生成した対応表は、それ自体が真実ではない。LLM は、もっともらしい説明を生成できるが、実際のコードやテストとの対応を誤る可能性がある。したがって、主張と証拠の対応表は、CI 結果、テストログ、静的解析結果、git 差分から可能な限り自動的に裏づけられるべきである。人間は、エージェントの説明文そのものではなく、説明と証拠の対応関係をレビューする。

第六の実装パターンは、コード検索と履歴検索の統合である。RAG は、外部知識を検索して生成に組み込む方法として有用である（Lewis et al. 2020）。しかし、ソフトウェア変更においては、単なる全文検索だけでは不十分である。関連ファイル、呼び出し関係、過去の変更、ADR、障害記録、テストケース、issue を組み合わせて検索する必要がある。リポジトリレベルのコード生成研究は、関連文脈を適切に取得することの重要性を示している。たとえば RepoBench はリポジトリレベルのコード補完を評価対象とし、GraphCodeAgent は要求側のグラフとリポジトリ側のコードグラフを用いて、実世界のコード生成に必要な支援コードを検索する（Shrivastava, Larochelle, and Tarlow 2023; Liu, Xu, and McAuley 2023; Li et al. 2025）。

具体例として、架空の PR「注文サービスに外部決済ゲートウェイのリトライ処理を追加する」を考える。従来の生の差分レビューでは、レビュー担当者は変更された関数、追加されたテスト、設定差分を読み、設計上のリスクを推測する必要がある。Codebase-Grounded Consensus を用いる場合、PR は次のような主張と証拠の対応表を提示する。

この例で重要なのは、表が実装の正しさを自動的に証明するわけではない点である。むしろ、レビュー担当者は、性能主張が unsupported であること、監査ログ主張が partially_supported であること、人間判断が必要な論点が残っていることを、生の差分を読む前に把握できる。導入前のレビューが「差分からリスクを推測する」作業であったのに対し、導入後のレビューは「主張、証拠、証拠不足、人間判断を照合する」作業へ移る。

実務導入時には、最初から完全なコンセンサス層を構築する必要はない。最小構成としては、第一に、PR テンプレートに主張、リスク、証拠、証拠なし主張の欄を設ける。第二に、重要な設計判断を ADR または依存関係判断記録に残す。第三に、主要なアーキテクチャ制約を少数のテストや静的解析で自動化する。第四に、CI 結果を PR 上の証拠として参照できるようにする。第五に、AI エージェントには、実装だけでなく主張と証拠の対応表を生成させる。この程度の最小構成でも、人間レビューの焦点は生の差分から構造的リスクへ移る。

以上の実装パターンは、開発プロセスを重くするためのものではない。むしろ、AI エージェントによって実装工程の一部が短縮されうる状況で、レビュー担当者が本質的な判断に集中できるようにするための軽量な構造である。Codebase-Grounded Consensus の実装は、完全な形式モデルの作成ではなく、既存の PR、ADR、テスト、CI、静的解析を接続し、変更ごとの主張と証拠を可視化することから始めるべきである。

第8章　評価設計：合意形成の品質をどう測るか

AI エージェントの導入効果を評価する際、単純な PR 数、実装速度、生成コード量だけを指標にすると、重要な側面を見落とす。AI エージェントは短時間で多くの差分を生成できるが、その差分が設計意図に沿い、証拠に支えられ、将来の変更を妨げない形でコードベースを進化させているとは限らない。Codebase-Grounded Consensus の目的は、速度そのものではなく、変更の意味、根拠、責任を検証可能にすることである。したがって、評価指標も、合意形成の品質を測るものへ拡張される必要がある。

評価は、少なくとも三つの研究仮説（Hypothesis: H）として定式化できる。H1 は、主張と証拠の対応表を導入した PR は、生の差分と自由記述だけの PR に比べて、レビュー時の設計リスク指摘率を高める、という仮説である。H2 は、証拠なし主張を明示した PR は、障害や回帰が発生した際の原因特定時間を短縮する、という仮説である。H3 は、アーキテクチャ制約を主張と CI 証拠に接続したリポジトリでは、禁止依存、循環依存、スキーマ互換性違反の累積が低下する、という仮説である。これらは、履歴分析、ケーススタディ、リポジトリ実験、開発者実験の組み合わせで検証できる。

再現可能な評価のためには、実験単位を PR とし、条件、正解セット、評価者、統計手続きを固定する必要がある。開発者実験では、AI 生成 PR を三条件で提示する。条件 A は生の差分と CI 成否のみ、条件 B は生の差分と自由記述の PR 説明、条件 C は生の差分、自由記述、主張と証拠の対応表である。ただし、同一被験者に同一 PR を複数条件で反復提示してはならない。反復提示を行うと、後続条件では差分内容や既発見リスクをすでに知っているため、対応表の効果と学習効果が混同されるからである。したがって、本稿の基本設計では、各 PR は各被験者に一条件でのみ提示し、PR と条件の割当を被験者間で交差させる。被験者は、対象言語とフレームワークの経験を持つ開発者とし、各 PR を一定時間内にレビューする。課題は、互換性違反、禁止依存、認可漏れ、データ移行リスク、性能劣化、監視不足を含むように設計する。

設計リスク指摘率を測るためには、正解リスクセットを事前に作る必要がある。正解リスクセットは、二名以上の専門家が独立に PR を分析し、合議によって確定する。正解には、実際にテストで失敗するリスクだけでなく、証拠不足、破壊的変更、運用手順の欠落、設計判断の未記録を含める。被験者の指摘は、正解リスクセットとの一致、過剰指摘、見落としに分類する。分類の信頼性は、二名の評価者による名義尺度の一致では Cohen の kappa、三名以上の評価者または欠測を含む分類では Krippendorff の alpha などによって評価し、十分な一致が得られない分類基準は見直す（Cohen 1960; Krippendorff 2004）。

本稿の初期プロトコルでは、探索的実験として 20 名から 30 名程度の開発者と、リスク種別が異なる 6 件から 10 件程度の PR を用いる。この人数は探索的研究の実行可能性を優先した初期値であり、一般的な推奨値ではない。確証的実験では、事前に効果量を仮定した検出力分析に基づいて被験者数を決める。割当では、各被験者が複数の PR を見る場合でも、同じ PR は一度だけ提示する。条件 A、B、C は被験者内で経験されてもよいが、各条件には異なる PR を割り当て、同一 PR の反復提示を避ける。たとえば、PR 群をリスク種別と難易度で層化し、各被験者には PR ごとに一条件だけを割り当て、被験者全体では各 PR が三条件にほぼ同数回出現するようにする。提示順はラテン方格法などでカウンターバランスし、順序効果を緩和する（Montgomery 2017）。主要な従属変数は、設計リスク指摘率、重大リスク見落とし率、レビュー時間、原因特定時間、NASA Task Load Index（NASA-TLX）などの主観的負荷、対応表への信頼度である。NASA-TLX は、精神的要求、身体的要求、時間的要求、作業成績、努力、フラストレーションの六つの下位尺度に基づく主観的ワークロード尺度として導入された（Hart and Staveland 1988）。統計分析では、条件を固定効果、被験者と PR を交差するランダム効果、提示順や PR サイズを共変量として扱う混合効果モデルを第一候補とする。被験者と PR を交差するランダム効果として扱う場合には、混合効果モデルの利用が適している（Baayen, Davidson, and Bates 2008）。

以下の六指標は、確立済み尺度として引用するものではなく、本稿が Codebase-Grounded Consensus の実証評価のために操作的に定義する初期指標である。NASA-TLX、評価者間一致、混合効果モデルなどは既存研究に基づく評価手続きであるが、主張網羅率、証拠なし主張数、アーキテクチャ逸脱率、判断理由網羅率、介入距離、診断遅延の妥当性は、第8章で述べる実験とケーススタディを通じて検証されるべき対象である。

第一の指標は、主張網羅率（claim coverage）である。これは、PR に含まれる構造的主張のうち、明示的な証拠に接続されている割合を表す。たとえば、互換性、安全性、依存方向、データ移行、性能、ロールバック可能性に関する主張が列挙され、そのうちどれだけがテスト、静的解析、CI 結果、ADR、運用ログに接続されているかを測る。主張網羅率が高いほど、レビュー担当者は主張と証拠の対応を確認しやすい。

第二の指標は、証拠なし主張数（unsupported claim count）である。これは、証拠を持たない構造的主張の数を表す。すべての主張に即座に機械的証拠を用意できるわけではないが、証拠なし主張が可視化されることには意味がある。たとえば、「性能に影響しない」「既存利用者に影響しない」「セキュリティ境界を変更しない」といった主張が証拠なしに残っている場合、レビュー担当者は追加テスト、手動確認、段階的リリース、監視強化を判断できる。重要なのは、証拠不足を隠さないことである。

第三の指標は、アーキテクチャ逸脱率（architecture drift rate）である。これは、アーキテクチャ上の制約からの逸脱が、時間とともにどれだけ発生しているかを表す。モジュール境界違反、禁止依存、循環依存、公開 API の不整合、スキーマ互換性違反などが継続的に増加する場合、AI エージェントの生成する変更が局所的には正しくても、全体構造を劣化させている可能性がある。技術的負債の研究が示すように、短期的な実装上の便宜は、将来の変更コストとして蓄積されうる（Cunningham 1992; Avgeriou et al. 2016; Alves et al. 2016）。

第四の指標は、判断理由網羅率（rationale coverage）である。これは、重要な設計判断のうち、理由、代替案、影響が ADR、PR、issue、依存関係判断記録などに残されている割合を表す。ソフトウェアアーキテクチャを設計判断の集合として捉える研究は、判断理由の喪失が将来の理解と進化を妨げることを示している（Jansen and Bosch 2005; Kruchten, Lago, and van Vliet 2006）。判断理由網羅率は、すべての変更に長文の説明を求める指標ではない。依存関係、アーキテクチャ境界、データモデル、セキュリティ、移行、性能など、将来のリスクが高い判断について、理由が追跡可能かを測る指標である。

第五の指標は、介入距離（intervention distance）である。これは、人間が AI エージェントの作業に介入するまでに、どれだけの変更段階が進んでいるかを表す。本稿の初期プロトコルでは、介入距離の主たる測定単位を、エージェントログに記録された操作ステップ数に固定する。操作ステップとは、ファイル編集、テスト実行、コマンド実行、検索、コミット作成など、エージェントが環境に対して行った一つの記録可能な行為である。経過時間とコミット数は補助変数として記録するが、主分析の介入距離には混在させない。介入が遅すぎる場合、エージェントは誤った前提に基づいて大きな差分を生成し、人間は後から多くの修正を求めることになる。一方、介入が早すぎる場合、エージェントの自律性が低下し、人間の負荷が下がらない。望ましい状態は、設計判断が必要な点、不確実性が高い点、証拠が不足している点で早期に人間へ確認が回り、単純な実装作業や機械的修正はエージェントが進められることである。

第六の指標は、診断遅延（diagnosis latency）である。これは、変更によって発生した問題の原因を特定するまでの時間を表す。AI エージェントが生成した変更で障害や回帰が発生した場合、主張、証拠、ADR、PR、git 履歴、CI 結果が接続されていれば、どの不変条件が破られ、どの証拠が不足していたかを追跡しやすい。逆に、差分だけが残り、判断理由や証拠が分散している場合、原因調査は長期化する。診断遅延は、合意層が単なる文書ではなく、障害対応時の実用的な索引として機能しているかを測る指標である。

各メトリクスは、次のように測定単位を固定する必要がある。

履歴分析では、同一リポジトリの導入前後を比較する。期間は、導入前後でそれぞれ少なくとも一つ以上のリリースサイクルを含める。対象は、AI エージェントが関与した PR、または同程度の規模とリスクを持つ PR に限定する。ドキュメントだけの変更、依存関係更新だけの機械的変更、生成物の再生成だけの PR は、分析目的に応じて除外する。主要アウトカムは、障害、回帰、重大レビュー指摘、禁止依存、スキーマ互換性違反、原因特定時間である。交絡要因として、PR サイズ、変更ファイル数、担当者経験、テスト数、リリース時期、対象モジュールの複雑度を記録し、回帰モデルで調整する。

ケーススタディでは、複数リポジトリに同じ主張と証拠のテンプレートを導入し、レビューコメント、CI 失敗、アーキテクチャ違反の変化を観察する。リポジトリは、言語、規模、テスト文化、運用成熟度が異なるものを選ぶ。外的妥当性を確保するため、単一組織の一種類のサービスだけに限定しない。導入支援の強さが結果に影響するため、教育資料、テンプレート、CI 連携の水準を記録する。

リポジトリ実験では、既存リポジトリへ合成的な禁止依存、互換性違反、認可漏れ、性能劣化を注入し、レビュー支援エージェントがどれだけ早くリスクを提示できるかを測る。合成バグは現実的な差分として作成し、単純な文字列検索だけで検出できるものに偏らないようにする。検出成功は、該当する主張が生成され、必要証拠が要求され、状態が unsupported または contradicted として提示されることによって判定する。

これらの指標は、既存の開発生産性指標と対立するものではない。DevOps Research and Assessment metrics（DORA metrics）は、デプロイ頻度、変更リードタイム、変更失敗率、復旧時間を通じてソフトウェアデリバリー能力を測る枠組みとして広く参照されている（Forsgren, Humble, and Kim 2018）。また、SPACE framework（satisfaction and well-being、performance、activity、communication and collaboration、efficiency and flow の頭文字に由来する生産性評価枠組み）は、生産性を複数次元から捉える（Forsgren et al. 2021）。Codebase-Grounded Consensus の指標は、これらに対して、AI エージェントが生成する変更の説明可能性、追跡可能性、証拠接続性を補足する。

ただし、メトリクスには副作用がある。主張網羅率を高めることだけを目的にすると、形式的な主張が大量に生成され、レビューのノイズになる可能性がある。証拠なし主張数を下げることだけを目的にすると、本来は人間判断が必要な主張に形式的な証拠を添付して済ませる危険がある。アーキテクチャ逸脱率を過度に重視すると、必要な構造変更まで抑制される可能性がある。したがって、指標は評価や監視の補助であり、設計判断そのものを自動化するものではない。

本章の結論は、AI エージェントの生産性を「どれだけ速くコードを書いたか」ではなく、「どれだけ安全に、説明可能に、将来変更可能な形でコードベースを進化させたか」として評価すべきだという点にある。主張網羅率、証拠なし主張数、アーキテクチャ逸脱率、判断理由網羅率、介入距離、診断遅延は、そのための初期的な候補指標群である。これらを用いることで、AI エージェントの導入効果を、単なる作業量ではなく、合意形成の品質として評価するための検証可能な出発点を得られる。

第9章　限界とリスク：二重管理、形式化コスト、AI の誤った確信

Codebase-Grounded Consensus は、AI エージェントによるソフトウェア変更を検証可能にするための実務的な方針である。しかし、この方法論は万能ではない。本章では、主要な限界とリスクを整理する。特に重要なのは、二重管理、形式化コスト、AI エージェントによる誤った構造的主張、複数エージェント構成への過信、人間の責任の曖昧化である。これらを軽視すると、合意層はレビューを支援する仕組みではなく、維持すべき文書と検査項目を増やすだけの負荷になりうる。

第一のリスクは、二重管理である。コンセンサス層が人間によって手作業で維持される独立文書になると、コード、テスト、ADR、PR、C の間で整合性を保つ必要が生じる。これは、UML や MDE が直面してきた、抽象モデルと実装の同期問題に近い（France and Rumpe 2007; Whittle, Hutchinson, and Rouncefield 2014）。合意層が二重管理を生むなら、それは Wang らが dimension collapse と呼ぶ問題を解決するどころか、新たな整合維持コストを追加する。

このリスクを抑えるには、合意層を可能な限り派生成果物として扱う必要がある。コード解析、テスト結果、CI、静的解析、git 履歴、ADR、PR メタデータから自動的に構造情報を抽出し、人間が手で書く対象を高リスクな判断に限定する。人間が記録すべきなのは、コードから機械的に導けない理由、代替案、リスク許容、運用上の判断である。依存関係の存在はコードから抽出できるが、その依存関係を採用した理由や退けた代替案は、人間が記録しなければ失われやすい。

第二のリスクは、形式化コストである。すべての判断を主張と証拠として厳密に記録しようとすれば、開発速度は落ち、レビュー担当者と実装者はドキュメント疲れに陥る。ソフトウェア開発では、多くの判断が局所的かつ可逆的であり、すべてを長期的な設計記録として保存する必要はない。記録対象は、将来の変更コストや障害リスクが高いものに限定すべきである。具体的には、アーキテクチャ境界、データモデル、外部依存、ライブラリ選定、セキュリティ、移行、性能、運用制約、後方互換性に関わる判断が優先される。

第三のリスクは、AI エージェントが誤った構造的主張や判断理由を、もっともらしく生成することである。LLM は、自然言語で一貫した説明を生成できるが、その説明が実際のコード、テスト、履歴、運用事実と一致するとは限らない。自己修正や反復的改善の手法は、出力品質を改善しうるが、根拠のない説明を完全に防ぐものではない（Shinn et al. 2023; Madaan et al. 2023）。したがって、AI エージェントが生成した rationale は、それ自体を根拠として扱ってはならない。

この問題に対する基本方針は、説明を証拠に従属させることである。AI エージェントが「互換性は維持される」と主張するなら、契約テスト、スキーマ差分、既存利用箇所の検査が必要である。「性能への影響は小さい」と主張するなら、ベンチマーク、プロファイル、運用メトリクスが必要である。「セキュリティ境界は変わらない」と主張するなら、認可テスト、静的解析、コードレビューが必要である。証拠がない場合は、証拠なし主張（unsupported claim）として可視化し、人間がリスクを判断するべきである。

第四のリスクは、合意層が過度に保守的になり、必要な構造変更を妨げることである。アーキテクチャテストや静的解析は、既存の境界を守るために有効であるが、システムの成長に伴って境界そのものを変更する必要が生じる場合もある。技術的負債の管理では、短期的な制約と長期的な改善のバランスが重要である（Cunningham 1992; Avgeriou et al. 2016）。したがって、合意層は既存構造を絶対視するものではなく、構造変更を明示的な判断と証拠に基づいて行うための仕組みでなければならない。

第五のリスクは、指標の形式化による逆機能である。主張網羅率（claim coverage）や判断理由網羅率（rationale coverage）が評価指標になると、実質的な判断ではなく、形式的な記入を増やす行動が生じうる。証拠なし主張数（unsupported claim count）を下げるために弱い証拠を添付したり、アーキテクチャ逸脱率（architecture drift rate）を下げるために必要な設計変更を避けたりする可能性もある。したがって、メトリクスは管理のための絶対的な目標ではなく、レビュー上の問いを発見するための補助として扱うべきである。

第六のリスクは、複数エージェント構成への過信である。設計整理、実装、監査、履歴参照、レビュー支援の役割を分けても、それらが同じ基盤モデル、同じ検索結果、同じ誤った前提を共有していれば、検証独立性は限定的である。さらに、エージェント数を増やすほど、実行時間、計算コスト、ログ量、衝突する提案の調停コストが増える。複数エージェント化は、高リスク変更に対して証拠源と判断手続きを分離するための手段であり、一般的な品質保証を自動的に高めるものではない。低リスク変更では、単一エージェントと CI、または人間レビューだけのほうが費用対効果が高い場合がある。

第七のリスクは、人間の責任が曖昧になることである。AI エージェントが claim を生成し、evidence を収集し、レビュー要約を提示すると、人間はそれを承認するだけで十分だと錯覚しやすい。しかし、どの不変条件を守るべきか、どのリスクを許容するか、どの依存関係を組織として引き受けるか、どの設計変更を将来の負債として認識するかは、人間が責任を持つ判断である。合意層は、人間の判断を置き換えるものではなく、人間が判断すべき点を明確にするための仕組みである。

第八の論点は、実証評価における妥当性への脅威である。内的妥当性の脅威として、主張と証拠の対応表そのものではなく、レビュー時間の増加、被験者の学習効果、対象 PR の難易度差が設計リスク指摘率を変える可能性がある。構成概念妥当性の脅威として、主張網羅率や証拠なし主張数が、実際の設計品質ではなく形式的な記入量を測ってしまう可能性がある。外的妥当性の脅威として、小規模リポジトリ、単一言語、特定の CI 文化に依存した結果が、大規模なレガシーシステムや規制産業の開発に一般化できない可能性がある。結論妥当性の脅威として、障害や重大レビュー指摘は頻度が低く、短期間の観察では統計的に不安定になりやすい。したがって、評価では、対照条件、PR サイズ、変更種別、対象モジュール、開発者経験を記録し、複数リポジトリと複数課題で反復する必要がある。

以上の限界を踏まえると、Codebase-Grounded Consensus は、軽量性、自動生成、証拠接続、責任分界を原則として運用されるべきである。人間が手作業で維持する情報は最小限にし、コード、テスト、CI、静的解析、git 履歴から抽出できる情報は自動化する。AI エージェントが生成した説明は、実行可能な証拠と履歴によって検証する。形式化の対象は、高リスクで長寿命な判断に限定する。最終的な設計責任は、人間が保持する。

本章の結論は、合意層の導入それ自体が安全性を保証するわけではないという点である。合意層がコードベースから切り離されれば二重管理を生み、すべてを形式化すれば開発を鈍らせ、AI エージェントの説明を信じれば誤った確信を増幅する。したがって、Codebase-Grounded Consensus は、コードを中心に置き、証拠に接続し、人間の判断を支援する範囲で設計されなければならない。

第10章　結論：コードを中心にした合意層の設計

本稿は、AI エージェントを用いたソフトウェア開発において、設計意図、不変条件、依存関係、判断理由、証拠をどのように共有し、維持すべきかを検討した。出発点となったのは、Wang らによる Agentic Consensus の提案である。同提案は、AI 支援開発においてコードとチャット履歴だけが主要な成果物になると、構造的コミットメントや証拠が失われ、人間のレビューが表層的な差分確認へ縮退する危険を指摘した。そして、合意層 C を操作可能な世界モデルとして導入し、構造的主張と証拠を明示的に結びつけることを提案した（Wang et al. 2026）。この問題設定は、AI エージェントの能力向上がそのまま人間の統制可能性を高めるわけではない、という重要な論点を提示している。

しかし、本稿は、C をコードとは別の主要成果物、あるいは単一の真実として扱う運用解釈には限界があると論じた。これは、Wang らの提案が C を孤立した手書き文書として扱う、という批判ではない。同論文は、実行可能成果物と C の往復同期、不確実性、人間による確認を明示的に扱っている。本稿の論点は、それでも C の一次成果物性が強く運用されれば、抽象モデルと実装を同期し続ける負荷が中心問題になるという点である。ソフトウェアは抽象的な設計記述だけで存在するのではなく、プログラミング言語、ライブラリ、フレームワーク、データベース、設定、CI、運用環境の上で実行される。UML や MDE の歴史が示すように、抽象モデルを実装から独立した中心成果物として維持しようとすると、モデルとコードの対応維持、例外的な実装判断の表現、ツール導入コスト、組織的運用負荷が問題となる（France and Rumpe 2007; Whittle, Hutchinson, and Rouncefield 2014）。AI エージェントのための合意層も、コードベースと分離された文書やモデルとして維持されるなら、同じ整合維持コストを生む可能性がある。

この批判を踏まえ、本稿は Codebase-Grounded Consensus を提案した。これは、合意層をコードベースの外部に置かれた第一級の真実としてではなく、コード、テスト、型、スキーマ、設定、マイグレーション、git 履歴、CI 結果、静的解析、ADR、PR、運用証跡から導かれるレビュー用の派生インデックスとして扱う方法である。この立場では、コードは実行可能な実装状態の中心的証拠であり、テストは期待される振る舞いの証拠を表し、git は判断の時間的経緯を表し、ADR は判断理由を補足する。合意層はそれらを置き換えるのではなく、構造的主張と証拠の対応を人間と AI エージェントが共同で検査できるようにする索引として機能する。

この再設計により、AI エージェントの役割も再定義される。AI エージェントは単一の実装者としてコードを生成するだけでは不十分である。変更前に不変条件、依存関係、影響範囲、代替案を整理する設計整理エージェント、実装を行う実装エージェント、テストや静的解析やアーキテクチャテストによって主張と証拠の対応を検査する監査エージェント、過去の git 履歴や ADR や障害記録を参照する履歴参照エージェント、人間のレビュー対象を構造的リスクへ整理するレビュー支援エージェントが必要となる。この役割分担は、AI エージェントの出力を単なる生の差分ではなく、検証可能な設計変更として扱うための実務的な構成である。

また、本稿は、AI エージェントの有効性を単純な実装速度や PR 数によって測るべきではないと論じた。重要なのは、生成されたコード量ではなく、構造的主張がどれだけ証拠に接続されているか、設計判断がどれだけ追跡可能か、アーキテクチャの逸脱をどれだけ早く検出できるか、人間の介入がどれだけ意味のある判断へ集中しているかである。主張網羅率、証拠なし主張数、アーキテクチャ逸脱率、判断理由網羅率、介入距離、診断遅延といった指標は、本稿が操作的に定義する初期的な候補指標であり、AI エージェントの生産性を「速く書く能力」ではなく、「安全に、説明可能に、将来変更可能な形でコードベースを進化させる能力」として評価するための検証対象となる。

もっとも、Codebase-Grounded Consensus は万能の解決策ではない。第一に、合意層が人手で維持される独立文書になれば、再び二重管理が発生する。第二に、すべての判断を形式化しようとすれば、開発速度を損ない、ドキュメント疲れを招く。第三に、AI エージェントはもっともらしいが誤った構造的主張や判断理由を生成しうる。したがって、合意層は可能な限りコード、テスト、CI、静的解析、git 履歴から自動生成されるべきであり、人間が明示的に記録する対象は、依存関係、アーキテクチャ境界、データモデル、ライブラリ選定、セキュリティ、移行、性能など、将来の変更コストや障害リスクが高い判断に限定されるべきである。また、AI エージェントが生成した説明は、それ自体を信頼するのではなく、実行可能な証拠によって検証されなければならない。

本稿の結論は、次の命題に集約される。コードは実行可能な実装状態の中心的証拠であり、テスト、CI、設定、デプロイ状態、運用ログはその挙動を検証する証拠群であり、git は時間軸であり、ADR は理由であり、コンセンサス層はそれらを横断して AI と人間がレビュー可能にする派生インデックスである。この命題は、コードだけが常に実際のシステム挙動を完全に表す、という主張ではない。バグ、未定義動作、設定差分、デプロイされていない変更、運用時データとの相互作用によって、コードと実行時挙動はずれうる。したがって、設計判断はコードベースと切り離された抽象文書として保存されるのではなく、実行可能な構造、検証可能な証拠、時間的履歴、明示された理由、運用上の観測の接続として保持されるべきである。

AI エージェント時代の人間の役割は、すべての行を手で書くことから、変更が守るべき構造的制約を定義し、証拠の妥当性を検査し、将来の保守可能性に責任を持つことへ移行する。AI エージェントはコード生成の速度を提供できるが、何を不変条件とし、どのリスクを許容し、どの設計判断を組織として引き受けるかを決める責任は、人間の側に残る。したがって、合意層の設計は、AI に判断を委譲するための仕組みではなく、人間が AI の速度を利用しながら設計責任を保持するための仕組みでなければならない。

今後の課題は、Codebase-Grounded Consensus を具体的なツールチェーンとして実装し、その有効性を実証的に評価することである。特に、既存リポジトリから構造的主張を抽出する方法、ADR とテストと CI 結果を結びつけるスキーマ、アーキテクチャテストによる制約検証、AI エージェントが生成する主張と証拠の対応表の信頼性評価、レビュー担当者の認知負荷への影響を検討する必要がある。最終的に求められるのは、AI エージェントがより多くのコードを書く世界ではなく、人間と AI エージェントがコードベースを媒介として、変更の意味、根拠、責任を検証可能に共有できる世界である。

参考文献

アクセス日は、特に断りのない限り2026年6月25日である。arXiv 文献は確認時点の arXiv レコードに基づき、DOI は arXiv DOI 形式で示す。

中心文献：コードベース中心の合意・AI 協働

• Wang, Tianfu, Zhezheng Hao, Yin Wu, Wei Wu, Qiang Lin, Hande Dong, Nicholas Jing Yuan, and Hui Xiong. 2026. “Scaling Human-AI Coding Collaboration Requires a Governable Consensus Layer.” arXiv preprint, arXiv:2604.17883. DOI: https://doi.org/10.48550/arXiv.2604.17883. URL: https://arxiv.org/abs/2604.17883.

• Lewis, Patrick, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen-tau Yih, Tim Rocktäschel, Sebastian Riedel, and Douwe Kiela. 2020. “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.” URL: https://arxiv.org/abs/2005.11401. Advances in Neural Information Processing Systems 33.

• Angles, Renzo. 2018. “The Property Graph Database Model.” URL: https://ceur-ws.org/Vol-2100/paper26.pdf. In Proceedings of the Alberto Mendelzon International Workshop on Foundations of Data Management, CEUR Workshop Proceedings, Vol. 2100.

• Yamaguchi, Fabian, Nico Golde, Daniel Arp, and Konrad Rieck. 2014. “Modeling and Discovering Vulnerabilities with Code Property Graphs.” DOI: https://doi.org/10.1109/SP.2014.44. In 2014 IEEE Symposium on Security and Privacy, 590–604.

• Li, Jia, Xianjie Shi, Kechi Zhang, Ge Li, Zhi Jin, Lei Li, Huangzhao Zhang, Jia Li, Fang Liu, Yuwei Zhang, Zhengwei Tao, Yihong Dong, Yuqi Zhu, and Chongyang Tao. 2025. “GraphCodeAgent: Dual Graph-Guided LLM Agent for Retrieval-Augmented Repo-Level Code Generation.” arXiv preprint, arXiv:2504.10046. DOI: https://doi.org/10.48550/arXiv.2504.10046. URL: https://arxiv.org/abs/2504.10046.

• Shrivastava, Disha, Hugo Larochelle, and Daniel Tarlow. 2023. “Repository-Level Prompt Generation for Large Language Models of Code.” DOI: https://doi.org/10.48550/arXiv.2206.12839. In Proceedings of the 40th International Conference on Machine Learning.

• Liu, Tianyang, Canwen Xu, and Julian McAuley. 2023. “RepoBench: Benchmarking Repository-Level Code Auto-Completion Systems.” DOI: https://doi.org/10.48550/arXiv.2306.03091. arXiv:2306.03091.

LLM エージェント・コード生成・評価ベンチマーク

• Jimenez, Carlos E., John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. 2024. “SWE-bench: Can Language Models Resolve Real-World GitHub Issues?” In International Conference on Learning Representations. arXiv:2310.06770. DOI: https://doi.org/10.48550/arXiv.2310.06770. URL: https://arxiv.org/abs/2310.06770.

• Yang, John, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. 2024. “SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering.” arXiv preprint, arXiv:2405.15793. DOI: https://doi.org/10.48550/arXiv.2405.15793. URL: https://arxiv.org/abs/2405.15793.

• Zhang, Yuntong, Haifeng Ruan, Zhiyu Fan, and Abhik Roychoudhury. 2024. “AutoCodeRover: Autonomous Program Improvement.” arXiv preprint, arXiv:2404.05427. DOI: https://doi.org/10.48550/arXiv.2404.05427. URL: https://arxiv.org/abs/2404.05427.

• Wang, Xingyao, Boxuan Li, Yufan Song, Frank F. Xu, Xiangru Tang, Mingchen Zhuge, Jiayi Pan, Yueqi Song, Bowen Li, Jaskirat Singh, Hoang H. Tran, Fuqiang Li, Ren Ma, Mingzhang Zheng, Bill Qian, Yanjun Shao, Niklas Muennighoff, Yizhe Zhang, Binyuan Hui, Junyang Lin, Robert Brennan, Hao Peng, Heng Ji, and Graham Neubig. 2025. “OpenHands: An Open Platform for AI Software Developers as Generalist Agents.” In International Conference on Learning Representations. arXiv:2407.16741. DOI: https://doi.org/10.48550/arXiv.2407.16741. URL: https://arxiv.org/abs/2407.16741.

• Xia, Chunqiu Steven, Yinlin Deng, Soren Dunn, and Lingming Zhang. 2024. “Agentless: Demystifying LLM-based Software Engineering Agents.” arXiv preprint, arXiv:2407.01489. DOI: https://doi.org/10.48550/arXiv.2407.01489. URL: https://arxiv.org/abs/2407.01489.

• Tao, Wei, Yucheng Zhou, Yanlin Wang, Wenqiang Zhang, Hongyu Zhang, and Yu Cheng. 2024. “MAGIS: LLM-Based Multi-Agent Framework for GitHub Issue Resolution.” arXiv preprint, arXiv:2403.17927. DOI: https://doi.org/10.48550/arXiv.2403.17927. URL: https://arxiv.org/abs/2403.17927.

推論・計画・自己修正に関する基礎文献

• Wei, Jason, Xuezhi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed H. Chi, Quoc V. Le, and Denny Zhou. 2022. “Chain-of-Thought Prompting Elicits Reasoning in Large Language Models.” URL: https://arxiv.org/abs/2201.11903. arXiv:2201.11903.

• Yao, Shunyu, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. 2023. “ReAct: Synergizing Reasoning and Acting in Language Models.” URL: https://arxiv.org/abs/2210.03629. In International Conference on Learning Representations.

• Yao, Shunyu, Dian Yu, Jeffrey Zhao, Izhak Shafran, Thomas L. Griffiths, Yuan Cao, and Karthik Narasimhan. 2023. “Tree of Thoughts: Deliberate Problem Solving with Large Language Models.” URL: https://arxiv.org/abs/2305.10601. In Advances in Neural Information Processing Systems.

• Shinn, Noah, Federico Cassano, Edward Berman, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. 2023. “Reflexion: Language Agents with Verbal Reinforcement Learning.” URL: https://arxiv.org/abs/2303.11366. In Advances in Neural Information Processing Systems.

• Madaan, Aman, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, Shashank Gupta, Bodhisattwa Prasad Majumder, Katherine Hermann, Sean Welleck, Amir Yazdanbakhsh, and Peter Clark. 2023. “Self-Refine: Iterative Refinement with Self-Feedback.” URL: https://arxiv.org/abs/2303.17651. In Advances in Neural Information Processing Systems.

アーキテクチャ知識・ADR・設計判断

• Kruchten, Philippe, Patricia Lago, and Hans van Vliet. 2006. “Building Up and Reasoning About Architectural Knowledge.” DOI: https://doi.org/10.1007/11904912_4. In Quality of Software Architectures, Lecture Notes in Computer Science, Vol. 4214, 43–58. Springer.

• Jansen, Anton, and Jan Bosch. 2005. “Software Architecture as a Set of Architectural Design Decisions.” DOI: https://doi.org/10.1109/WICSA.2005.61. In 5th Working IEEE/IFIP Conference on Software Architecture, 109–120.

• Tyree, Jeff, and Art Akerman. 2005. “Architecture Decisions: Demystifying Architecture.” DOI: https://doi.org/10.1109/MS.2005.27. IEEE Software 22, no. 2: 19–27.

• van Heesch, Uwe, Paris Avgeriou, and Rich Hilliard. 2012. “A Documentation Framework for Architecture Decisions.” DOI: https://doi.org/10.1016/j.jss.2011.10.017. Journal of Systems and Software 85, no. 4: 795–820.

• Nygard, Michael. 2011. “Documenting Architecture Decisions.” URL: https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions.html. Cognitect Blog.

• ISO/IEC/IEEE. 2011. “ISO/IEC/IEEE 42010:2011 — Systems and Software Engineering — Architecture Description.” URL: https://www.iso.org/standard/50508.html. International Organization for Standardization.

トレーサビリティ・適合性検査・プロベナンス

• Gotel, Orlena C. Z., and Anthony C. W. Finkelstein. 1994. “An Analysis of the Requirements Traceability Problem.” DOI: https://doi.org/10.1109/ICRE.1994.292398. In Proceedings of the First IEEE International Conference on Requirements Engineering, 94–101.

• Gotel, Orlena, Jane Cleland-Huang, Jane Huffman Hayes, Andrea Zisman, Alexander Egyed, Paul Grünbacher, Alex Dekhtyar, Giuliano Antoniol, and Jonathan Maletic. 2012. “The Grand Challenge of Traceability.” In Software and Systems Traceability, 343–409. Springer.

• Murphy, Gail C., David Notkin, and Kevin J. Sullivan. 2001. “Software Reflexion Models: Bridging the Gap between Design and Implementation.” DOI: https://doi.org/10.1109/32.917525. IEEE Transactions on Software Engineering 27, no. 4: 364–380.

• OpenSSF. 2026. “SLSA Specification.” SLSA v1.2, Approved. Open Source Security Foundation. URL: https://slsa.dev/spec/v1.2/.

• United States Department of Commerce. 2021. The Minimum Elements For a Software Bill of Materials (SBOM). URL: https://www.ntia.gov/files/ntia/publications/sbom_minimum_elements_report.pdf.

• OpenSSF Scorecard. 2026. “OpenSSF Scorecard.” Open Source Security Foundation. URL: https://securityscorecards.dev/.

ソフトウェア設計・保守性・技術的負債

• Fowler, Martin. 2018. Refactoring: Improving the Design of Existing Code. 2nd ed. Addison-Wesley Professional.

• Cunningham, Ward. 1992. “The WyCash Portfolio Management System.” DOI: https://doi.org/10.1145/157710.157715. In OOPSLA ’92 Addendum to the Proceedings on Object-Oriented Programming Systems, Languages, and Applications, 29–30.

• Avgeriou, Paris, Philippe Kruchten, Ipek Ozkaya, Carolyn Seaman, and Walter Tichy. 2016. “Managing Technical Debt in Software Engineering.” DOI: https://doi.org/10.4230/DagRep.6.4.110. Dagstuhl Reports 6, no. 4: 110–138.

• Alves, Nicolli S. R., Thiago S. Mendes, Manoel G. de Mendonça, Rodrigo O. Spínola, Forrest Shull, and Carolyn Seaman. 2016. “Identification and Management of Technical Debt: A Systematic Mapping Study.” DOI: https://doi.org/10.1016/j.infsof.2015.10.008. Information and Software Technology 70: 100–121.

ソフトウェア開発生産性・DevOps メトリクス

• Forsgren, Nicole, Jez Humble, and Gene Kim. 2018. Accelerate: The Science of Lean Software and DevOps: Building and Scaling High Performing Technology Organizations. URL: https://itrevolution.com/product/accelerate/. Portland, OR: IT Revolution Press.

• Forsgren, Nicole, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, and Jenna Butler. 2021. “The SPACE of Developer Productivity: There's More to It Than You Think.” DOI: https://doi.org/10.1145/3454122.3454124. ACM Queue 19, no. 1: 20–48.

実験計画・評価尺度・統計分析

• Cohen, Jacob. 1960. “A Coefficient of Agreement for Nominal Scales.” DOI: https://doi.org/10.1177/001316446002000104. Educational and Psychological Measurement 20, no. 1: 37–46.

• Hart, Sandra G., and Lowell E. Staveland. 1988. “Development of NASA-TLX (Task Load Index): Results of Empirical and Theoretical Research.” DOI: https://doi.org/10.1016/S0166-4115(08)62386-9. In Human Mental Workload, edited by Peter A. Hancock and Najmedin Meshkati, 139–183. Amsterdam: North-Holland.

• Krippendorff, Klaus. 2004. “Reliability in Content Analysis: Some Common Misconceptions and Recommendations.” DOI: https://doi.org/10.1111/j.1468-2958.2004.tb00738.x. Human Communication Research 30, no. 3: 411–433.

• Montgomery, Douglas C. 2017. Design and Analysis of Experiments. 9th ed. Hoboken, NJ: Wiley.

• Baayen, R. Harald, Douglas J. Davidson, and Douglas M. Bates. 2008. “Mixed-Effects Modeling with Crossed Random Effects for Subjects and Items.” DOI: https://doi.org/10.1016/j.jml.2007.12.005. Journal of Memory and Language 59, no. 4: 390–412.

MDE・UML・DSL への批判的比較

• France, Robert, and Bernhard Rumpe. 2007. “Model-Driven Development of Complex Software: A Research Roadmap.” DOI: https://doi.org/10.1109/FOSE.2007.14. In Future of Software Engineering, 37–54.

• Atkinson, Colin, and Thomas Kühne. 2003. “Model-Driven Development: A Metamodeling Foundation.” DOI: https://doi.org/10.1109/MS.2003.1231149. IEEE Software 20, no. 5: 36–41.

• Whittle, Jon, John Hutchinson, and Mark Rouncefield. 2014. “The State of Practice in Model-Driven Engineering.” DOI: https://doi.org/10.1109/MS.2013.65. IEEE Software 31, no. 3: 79–85.

• Booch, Grady, James Rumbaugh, and Ivar Jacobson. 1999. The Unified Modeling Language User Guide. Addison-Wesley.