AIによるコード生成は、エンジニアリングの現場に劇的な変化をもたらしました。
しかし、多くの開発者が「最初は魔法のように感じたが、次第にコードの品質管理やデバッグに追われるようになった」という壁に直面しています。
CNCF Sandboxプロジェクトの一つである(KubeStellar)のコンソール開発において、一人の開発者がこの課題を打破し、AIエージェントによるプルリクエスト(PR)の承認率を81％にまで引き上げた手法が注目を集めています。
その核心にあるのは、洗練されたプロンプトではなく、コードベースそのものを進化させる「AI Codebase Maturity Model (AIコードベース成熟度モデル)」という考え方です。
AIコーディングの「ハネムーン期」とその終焉
開発の初期段階では、AIエージェントは驚異的なスピードで成果物を提供します。
Go、React、TypeScript、Helmといったスタックで構成されるKubeStellar Consoleの構築において、当初は人間が3日かかるタスクをAIがわずか2時間で完了させるという「10倍の生産性」を享受していました。
しかし、この幸福な時間は長くは続きませんでした。
プロジェクトの規模が拡大するにつれ、AIは既存のアーキテクチャを密かに上書きし、一箇所を修正すれば三箇所が壊れるという「負の連鎖(カスケード問題)」を引き起こし始めたのです。
AIに自律性を与えれば与えるほど、修正よりも元に戻す(リバート)作業に時間が奪われ、生産性はマイナスへと転じました。
ここで得られた教訓は明確です。
AIモデルそのものの知能に依存するのではなく、コードベースがAIを制御し、計測するための「ループ」を構築しなければならないということです。
インテリジェンスの所在をモデルから「ループ」へ移す
現在のAI開発において、LLM(大規模言語モデル)自体はもはやコモディティであり、モデルの載せ替えは数日の作業に過ぎません。
真の差別化要因は、そのモデルを取り囲む「フィードバック・システム」にあります。
KubeStellarの事例では、4ヶ月の試行錯誤を経て、以下の5段階からなる成熟度モデルが提唱されました。
| 成熟段階 | 名称 | 主な特徴 |
|---|---|---|
| 第1段階 | (Instructed) | 開発者の好みやルールを外部化し、AIに「教示」する |
| 第2段階 | (Measured) | テストを「信頼の層」として位置づけ、決定論的な計測を行う |
| 第3段階 | (Adaptive) | 計測データに基づき、自動化の優先順位を動的に調整する |
| 第4段階 | (Self-Sustaining) | コードベース自体が運用マニュアルとなり、自律的に判断する |
| 第5段階 | (Asking Why) | 「何を直すか」ではなく「なぜ防げなかったか」を問い、システムを改善する |
第1段階：繰り返し修正している内容を言語化する (Instructed)
最もコストが低く、かつリターンの大きい介入は、開発者自身のこだわりや「暗黙の了解」を明文化することです。
プロジェクトのルートディレクトリに CLAUDE.md を配置し、PRの規約を .github/copilot-instructions.md に記述します。
さらに重要なのは、「なぜ過去にAIのPRを却下したのか」という理由をまとめた開発ガイドを作成することです。
これにより、AIエージェントが同じ間違いを繰り返すことを防ぎ、セッションの一貫性が劇的に向上します。
直感でAIを操作するのをやめ、基準を外部化することが成熟への第一歩となります。
第2段階：テストを「信頼の層」として再定義する (Measured)
AIによる自律的なワークフローにおいて、テストは単なる「正誤判定」以上の役割を担います。
それはAIがシステムを改善しているのか、あるいは破壊しているのかを判断するための(唯一の信号)です。
KubeStellar Consoleでは、91％のテストカバレッジを実現し、32のナイトリーテストスイートを構築しました。
ここで最も重視されたのは「決定論(Determinism)」です。
人間にとって、15％の確率で失敗する不安定なテスト(Flaky Test)は「再実行すれば済む煩わしさ」に過ぎません。
しかし、AIエージェントにとって不安定なテストは「信頼モデルの静かな崩壊」を意味します。
不確実な信号の上にオートメーションを築くことは不可能です。
第3段階：計測なしに自動化してはならない (Adaptive)
PRの承認率をカテゴリー別にログに記録し、そのデータに基づいて自動化の重みを変更する段階です。
例えば、アクセシビリティに関するPRの承認率が高ければその活動を強化し、逆に特定のオペレーター層の承認率が極端に低ければ、AIへのCIサイクル割り当てを停止してリソースを再配分します。
auto-qa-tuning.json のようなファイルで、AIの活動実績を数値化し、それに基づいてワークフローを動的に調整する仕組みが、PR承認率81％という数字の裏付けとなっています。
第4段階：コードベースを運用マニュアル化する (Self-Sustaining)
この段階に達すると、システムは人間が介在しなくても自律的に動作し始めます。
コードベースに蓄積された命令ファイル、テスト、ワークフロー、過去の履歴が「意志」を持ち始め、コミュニティからのイシューに対して、人間が起きる前にAIがトリアージを行い、修正案を提示し、テストをパスした状態でレビューを待つようになります。
例えば、あるユーザーが「バグ」として報告した内容が、Kubernetesのアーキテクチャ上の仕様である場合、AIは過去の設計判断をドキュメントやコードから読み取り、「なぜそれがバグではないのか」を論理的に説明することが可能になります。 コードそのものがモデル(知識の源泉)となる状態です。
第5段階： 「何」ではなく「なぜ」を問う (Asking Why)
AIエージェントに対する接し方を「このバグを直せ」から(「なぜこのバグを事前に検知できなかったのか？」)へと変えることで、根本的な解決が促されます。
前者の命令は単なるパッチを生みますが、後者の問いは「新しいテストケース」や「将来の失敗を防ぐための新しいルール」を生みます。
このサイクルを回すことで、コードベースは自己改善を続けるシステムへと進化します。
メンテナンス担当者とリーダーへの示唆
エンジニアリング組織を率いるリーダーは、どのAIモデルを採用するかという微視的な最適化に時間を割くべきではありません。
モデルは週末の作業で交換できる部品です。
それよりも、(インストラクション・ファイル、テストスイート、メトリクス、ワークフロー・ルール)といった「インテリジェンス・インフラストラクチャ」の構築に投資すべきです。
オープンソースのメンテナーにとっても、このモデルはバーンアウト(燃え尽き症候群)に対する強力な解決策となります。
メンテナーの判断基準をコードベースにエンコードできれば、メンテナーの役割は「日々のオペレーター」から「システムのアーキテクト」へとシフトします。
コミュニティはイシューを立てることでプロジェクトを操縦し、AIが実務をこなすという理想的な分業が実現します。
まとめ
KubeStellar Consoleが示したPR承認率81％という成果は、AIモデルの進化によるものではなく、コードベースがAIを使いこなすための知能を備えた結果です。
「AI Codebase Maturity Model」の各段階を一段ずつ登り、フィードバック・ループを閉じていくプロセスこそが、AI時代のソフトウェア開発における正攻法と言えるでしょう。
私たちは今、単にプロンプトを書く段階から、AIと共に成長する「自律的なコードベース」を設計する段階へと移行しています。
最後に残る人間の役割は、何を作る価値があるのかを決定し、何に対して「ノー」と言うべきかを見極め、あるべき理想の姿を定義し続けることにあるのです。