Column

AIでコードは安くなった。高くなったのは「判断」——12週間・42万行の実録が示すガバナンス転換

ベテランエンジニア1人がAIコーディングエージェントと12週間で42万行の本番システムを構築した一人称ケーススタディから、「エージェントの失敗を制御機構へ変換していく」ガバナンス転換の理論が導かれた。Copilot・Cursor導入企業の必読研究。

2026 / 07 / 02 5 分で読める English version →

AIロボットが高速でレンガを積み上げる横で、人間の監督者が設計図と天秤を持って構造を検査している様子のフラットイラスト

こんにちは。Affectosphere Group の三浦です。

AI コーディングエージェントを導入した開発チームで、いま何が起きているか。「コードを書くコストは劇的に下がった。でも、なぜか楽になった気がしない」——こういう声、聞いたことありませんか？

2026年7月に arXiv で公開された研究（Davis et al., arXiv:2607.01087）が、この違和感の正体を12週間の実録データで説明してくれています。

タイトルがすべてを言い表しています。Cheap Code, Costly Judgment——コードは安く、判断は高くつく。

今日の3点

ベテランエンジニア1人が frontier AI コーディングエージェントを使い、12週間で文書アクセシビリティ改善システム（本番コード42万行）を構築した一人称ケーススタディ。88の観察ノートから「ガバナンス転換」のプロセス理論が導出された。
エージェントは同じ種類の構造的失敗（テスト欠落・アーキテクチャ逸脱など）を繰り返す。その失敗が発見されるたびに、CI チェック・スタイル強制・ドキュメント自動検証といった新しいガバナンス機構へ変換されていくパターンが確認された。
従来のガバナンスは「既知の義務」から制御を設計する。この理論の新しさは「エージェントが働く中で初めて可視化される失敗」から制御を発見する点にある。導入企業の評価軸を「生産性」から「ガバナンス構築力」へ広げるべき。

① 12週間・42万行・観察ノート88本という記録

この研究の面白さは、まずデータの生々しさにあります。

著者の一人であるベテランエンジニアが、AI コーディングエージェントを使って文書アクセシビリティ改善システムをゼロから構築しました。期間は12週間。生まれた本番コードは420KLOC、つまり42万行です。

そしてその過程を、88本の観察ノートとして克明に記録した。何を指示したか、エージェントが何をやらかしたか、それにどう対処したか。この一人称の記録を質的分析にかけて、プロセス理論を組み立てています。

1人＋AIで12週間・42万行という数字自体、開発の経済性が変わったことを物語っています。人間のチームなら年単位の規模です。

② エージェントは「同じ種類の失敗」を繰り返す

では、何が高くついたのか。

観察記録から見えたのは、エージェントが繰り返す構造的な失敗パターンです。たとえばテストを書かずに実装を進めてしまう。決めたアーキテクチャから逸脱した実装を混ぜてくる。ドキュメントと実装がずれていく。

重要なのは、これらが「たまたまのミス」ではなく、繰り返し起きる構造的な癖だということです。人間の新人なら一度指摘すれば学びますが、エージェントは文脈が変わると同じ失敗を再生産する。

そこで著者は、失敗が見つかるたびに、それを仕組みに変換していきました。テスト欠落には CI チェックを追加する。アーキテクチャ逸脱にはコードスタイルの強制ルールを入れる。ドキュメントのずれには自動検証を仕込む。

この「失敗 → ガバナンス機構への変換」の積み重ねこそが、研究の言う「ガバナンス転換」です。

③ 「既知の義務」からではなく「発見された失敗」から設計する

ここが理論的にいちばん新しいところです。

従来のソフトウェア開発ガバナンスは、規程・チェックリスト・レビュー体制など、「事前に分かっている義務」から制御を設計します。セキュリティ基準があるからセキュリティレビューを置く、という発想です。

一方この研究が示したのは、逆向きのプロセスです。エージェントに実際に働かせてみて、初めて可視化される失敗がある。その失敗を観察し、制御機構として固定化していく。つまりガバナンスは事前設計するものではなく、エージェントとの協働の中で発見・蓄積されるものになる。

エンジニアの仕事の重心も変わります。コードを書く時間は減り、エージェントの失敗を見抜き、それを仕組みに変換する「判断」の時間が増える。コードは安くなったが、判断は高くなった——タイトルの意味はこれです。

企業への実装提案：導入評価を「スコアカード」にする

想定ユースケースは、GitHub Copilot や Cursor などの AI コーディングツールを導入している、あるいは導入を検討している IT 部門・エンジニアリング組織です。

第一に、導入評価の指標を生産性だけにしないこと。「コード生成量が何倍になったか」だけを見ていると、テスト欠落やアーキテクチャ逸脱の蓄積という負債が見えません。メンテナビリティ・セキュリティの持続可能性まで含めたスコアカードを作る。

第二に、「失敗ログ → ガバナンス機構」の変換プロセスを制度化すること。この研究の著者が個人でやったことを、チームの運用に翻訳します。具体的には、エージェントの失敗を記録する専用のログを設け、月次で「今月見つかった構造的失敗」と「それに対して追加した CI チェック・ルール」をレビューする。ガバナンス機構の追加数自体が、AI 導入の成熟度を測る KPI になります。

第三に、システム監査の観点を更新すること。監査部門は「AI が書いたコードか」ではなく「AI の失敗を検出する機構が整備されているか」を問うべきです。

「AIに任せる」と「AIを統治する」のあいだ

AI コーディングエージェントの議論は、「どこまで任せられるか」に偏りがちです。

でもこの研究が示すのは、任せる範囲の話ではなく、任せながら統治の仕組みを育てていくプロセスの話です。失敗をゼロにはできない。ならば失敗を発見し、仕組みに変換する速度で勝負する。

エンジニアリングマネージャーの方には、自チームの運用を見直すたたき台としてかなり使える一本だと思います。

では！

参考論文

Davis, James C., Amusuo, Paschal C., Singla, Tanmay, Cakar, Berk, & Davis, Kirsten A. (2026). Cheap Code, Costly Judgment: A Case Study on Governable Agentic Software Engineering. arXiv preprint.

※ 本記事は一部 AI により執筆されており、間違った情報が含まれる恐れがあります。