AI エージェントと複雑性のラチェット：なぜ 90% のテストカバレッジが必須なのか

私はこの1年間、AIを使ってコードを書いてきました。単なるプロンプトではなく、実際のソフトウェアを構築しています。2つのオープンソースプロジェクトがあります。GStackはAIコーディングエージェントを強化し、GBrainはあなたが読み書きするすべての情報を、AIが利用可能な検索可能な知識ベースに変換します。これら2つで、約97万行のコードと665のテストファイルがあります。ほとんどすべて、Claude CodeとCodexが私の指示の下で書いたものです（ほとんどの場合、15のConductorセッションを同時に実行）。

先週、72時間で14件のプルリクエストをマージしました。約29,000行の新しいコードです。各リリースは、前のものよりもテストが充実していました。

これは不可能と言われてきたことです。スピードと品質はトレードオフの関係にあるとされてきました。速く出荷すれば、物事は壊れる。ゆっくり進めば、正しく出荷できる。どちらかを選べ、と。

もう選ぶ必要はありません。その鍵は90%のテストカバレッジにあり、AIエージェントがそれを無料で実現できるようにしました。50年間、そのレベルの検証を維持するには、人間の意志の力がかかりすぎました。今やエージェントがコードと一緒にテストを書いてくれます。その結果、私が「複雑性ラチェット」と呼ぶものが生まれました。システムは良くなる一方で、決して悪くなることがない仕組みです。

(これはAIを使った構築に関する連載の第7回です：1 2 3 4 5 6

かつてソフトウェアは脆かった

50年間、ソフトウェアエンジニアリングという学問全体は、一つの考え方に基づいて組織化されていました。それは、エラーは壊滅的だから、エラーを防ぐことです。

コードは最初から正しく書かなければなりませんでした。一つのエッジケースを見逃せば、本番環境でクラッシュします。悪いデータベースマイグレーションを出荷すれば、顧客データを失います。微妙な動作をする関数を書き、それを理解している唯一の人が辞めれば、なぜそれが機能するのか誰も知りません。システム全体は人間が注意深くあることに依存していましたが、人間は注意深くありません。そこで私たちは、コードレビュー、ステージング環境、QAチーム、リリーストレインといった、ユーザーに届く前にミスをキャッチするための複雑なプロセスを構築しました。

ある程度は機能しました。しかし、遅かったのです。そして、どんなソフトウェアシステムの複雑さにも、一つのチームが同時に頭の中に保持できる情報量という厳しい上限があることを意味していました。

今やソフトウェアは柔軟になった

いい加減という意味ではありません。以前は不可能だった方法で、回復力を持つようになったのです。

「モデルがここにある」と言うとき、私が意味するのは、AIコーディングエージェント（Claude、GPT、Codex、そしてそれらを取り巻くエコシステム）が、コードを読み、コンテキストを理解し、エラーを診断し、修正を書けるようになったということです。完璧ではありません。しかし、ソフトウェアのエラーモデルが変わったと言えるほどには十分です。

マイグレーションが壊れた？エージェントがエラーメッセージを読み、45バージョンにわたるデータベーススキーマの履歴を理解し、修正を書き、テストを書きます。ファイル同期が100万のシンボリックリンクでハングする？エージェントがパーサーのタイムアウトを診断し、30秒で制限し、テスト付きで修正を出荷します。抽出パイプラインに帰属バグがある？クロスモデル評価がそれをキャッチし、プロンプトが反復され、データベース層で強制が追加されます。

ほとんどのコードレベルのエラー（ロジックバグ、パースの失敗、壊れたエッジケース）に対して、エージェントは次のターンで診断して修正できるようになりました。これは本当に新しいことです。壊滅的なまま残るエラーは、状態を破壊するものです。本番データに対する悪いマイグレーション、検出前に悪用されるセキュリティホール、取り消せないプライバシー漏洩などです。ラチェットはここでも役立ちます（良いテストはこれらを本番前にキャッチします）が、本当の変化は、コードベース内のエラーの大部分が修正可能な種類になったことです。

これはソフトウェアの構築方法における相転移です。しかし、ラチェットがあって初めて機能します。

エージェント複雑性ラチェット

ラチェットは、一方向にのみ動きを許す機構です。ソケットレンチはボルトを前方に回し、後戻りを防ぎます。それが比喩です。

エージェントがコードを書くソフトウェアでは、AIエージェントとのコーディングセッションごとに、コードベースに3つのものが追加されます。

テスト — 「正しい」とは何かをコード化するもの。誰かがコードを変更するたびに実行され、変更が何かを壊した場合に大きな音を立てて失敗する自動チェック
ドキュメント — なぜ決定が下されたかを記録するもの。コードが何をするかだけでなく、その背後にある推論とトレードオフ
評価結果 — 品質の閾値を確立するもの。出力品質の構造化された評価とスコア。次のバージョンが良いか悪いかを知ることができる

次にエージェントがコードベースで作業するとき、これら3つすべてをコンテキストウィンドウ（AIが見て推論できるテキスト）に読み込みます。テストスイート以下に後退することはできません。テストが失敗するからです。ドキュメントを無視することはできません。コンテキストにすぐそこにあるからです。評価ベースライン以下の品質で出荷することはできません。スコアが記録されているからです。

品質の下限は、ターンごとに上がっていきます。前方のみの動き。それがラチェットです。

実際の様子

具体的に説明します。GBrainは私が構築している知識システムです。人のメモ、会議、会話、研究を保存、インデックス化、検索することで、AIエージェントに長期記憶を与えます。あなたのAIアシスタントが実際に読めるセカンドブレインのようなものです。

その機能の一つに、認識論的抽出があります。数千ページを読み、誰が何を、どの程度の確信を持って、時間をかけて信じているかを抽出します。「Garryはビットコインが30万ドルに達すると考えている（確信度：0.45）」「Jaredはこのスタートアップのリテンションが強いと考えている（確信度：0.80）」といった具合です。これを28,000ページにわたって行います。

最初の抽出実行では、100,720件の主張が抽出されました。クロスモデル評価を使って品質を評価しました。GPT-5.5とClaudeの両方に独立して出力をスコアリングさせました。全体：10点中6.8点。

最大の問題は？私が「保持者混乱」と呼ぶものです。「AIは2027年までにソフトウェアエンジニアの80%を置き換える」という主張を考えてみてください。その信念を持っているのは誰ですか？それを書いた人ですか？引用している誰かですか？それとも、ポッドキャストのトランスクリプトから推論したシステムの分析エンジンですか？バージョン1はこの区別を35%の確率で間違えました。これは重要です。人々が何を信じているかを追跡するシステムを構築しているなら、誰がそれを信じているかを知る必要があります。

そこで、評価結果が文書化されました。6つの特定の障害モードが特定されました。バージョン2のプロンプトは、その6つすべてに対処しました。重みの丸め（確信度スコア）はデータベース層で強制されました。0.75が正直な答えであるときに0.74のような誤った精度はもうありません。17のテストが契約を固定化しました。

これで、将来の抽出バージョンは、それらの17のテストに合格しなければ出荷できません。誰も重みの丸めがなぜ重要なのか、保持者混乱とは何かを覚えておく必要はありません。テストが覚えています。

品質の下限は永久に上がりました。それがラチェットの一回の回転です。

ほとんどのVibecodingプロジェクトが死ぬ理由

「Vibecoding」は、Andrej Karpathyが、自然言語で欲しいものを説明し、モデルにコードを生成させるAIコーディングを指すために作った用語です。それは強力で、私の構築方法でもあります。しかし、YCの応募やオープンソースリポジトリで見た限り、テストをスキップしたほとんどのVibecodingプロジェクトは、中程度の複雑さ（数千行、いくつかの相互作用する機能）に達すると崩壊し始めます。

彼らはラチェットをスキップします。テストも、ドキュメントも、評価もありません。エージェントは複雑さを追加しますが、後退を防ぐものは何もありません。新しい機能ごとに古い機能を壊す可能性があり、テストがなければ、ユーザーが報告するまでわかりません。バージョン0.5までにコードベースは、すべての変更が予期せぬ何かを壊すお化け屋敷と化します。そして、開発者は「AIコーディングは機能しない」というブログ記事を書きます。

AIコーディングは問題なく機能します。彼らがラチェットを構築しなかっただけです。

テストを書くような人は、そもそも良いアーキテクチャを書くような人でもある、と主張することもできるでしょう。それは公平です。しかし、ラチェットメカニズムは人に関するものではありません。次のターンで何が起こるかに関するものです。新しいコントリビューターがPRを開いたとき、モデルのバージョンが変わったとき、午前2時に判断力が低下した状態でコーディングしているとき、テストは誰が書いたかに関係なく後退をキャッチします。ラチェットは、人間が最高の状態でなくても機能します。それがポイントです。

テストがなければ、改善はノイズの多いプロセスです。エージェントは物事を良くしようとしますが、後退のシグナルがなければ、良い変更も悪い変更も同様に見えません。密度の高いテストスイートがあれば、テストされた表面にラチェットがかかります。コード化された動作に対して品質は上がる一方です。それはシステムの大部分ですが、すべてではありません。しかし、スピードを保った前方への動きを維持するには十分です。

制度記憶としてのテスト

従来のソフトウェア企業では、制度記憶は人間の中に存在します。なぜそのキャッシュ層が存在するかを知っているシニアエンジニア。データベースをほぼ破壊したマイグレーションを覚えているアーキテクト。請求システムの奇妙なエッジケースを説明できるテックリード。

人間は去ります。退職し、引き抜かれ、燃え尽きます。彼らが去るとき、知識も一緒に去ります。すべてのソフトウェア企業は、重要なファイルを開いて「これを変更しないでください — Daveに聞いてください」というコメントを見つけ、Daveは3年前に辞めていた、という経験をしたことがあるでしょう。

エージェントのコンテキストウィンドウは辞めません。引き抜かれません。忘れません。テストスイートが「重みの丸めは0.05刻みを使用しなければならない」とコード化し、ドキュメントが「クロスモーダル評価により、誤った精度が確信度スコアへの信頼を損なうことが示されたため」と説明しているとき、その知識は耐久性があります。どんなエージェント、どんなモデル、どんな時でも、そのコンテキストを読み込み、制約を理解できます。

テストは、従業員の離職を乗り越えて生き残る制度記憶です。一人のプロジェクトでは、さらに重要です。それがあなたが持つ唯一の制度記憶だからです。

ハーネス化可能なものはすべてテスト可能

ラチェットは従来のコードだけで機能するわけではありません。コンピューターが観察できるものすべてに機能します。

現代のシステムの層を考えてみてください。OSはプロセスツリー、ファイルシステムの状態、ネットワークソケット、cronスケジュールを提供します。ターミナルはすべてのキーストローク、すべての出力行、すべてのインタラクティブプロンプトを提供します。ブラウザはレンダリングされたページ、ボタンの状態、ナビゲーションイベントを提供します。APIは解析して検証できる構造化されたレスポンスを提供します。そしてAIエージェントは観察可能な振る舞い（何を言うか、どのツールを呼ぶか、どの順序で行うか、行動する前に尋ねるかどうか）を提供します。

これらはすべてハーネス化可能です。そして、ハーネス化できれば、観察できます。観察できれば、アサートできます。アサートできれば、ラチェットをかけられます。

これは従来のユニットテストよりもはるかに広い表面積です。例を示しましょう。

GStackは私のオープンソースコーディングエージェントフレームワークです。GitHubスター93,000、701,000行のコード、46のスキルがあります。その中核機能の一つはインタラクティブな計画レビューです。アーキテクチャのレビューを依頼すると、計画をセクションごとにウォークスルーし、質問をし、エッジケースを探り、前提に挑戦します。実際にコードを読むエンジニアリングマネージャーがいるようなものです。

問題は、Claude Codeがインタラクティブな部分全体をスキップすることがあったことです。計画ファイルを読み、すべての所見を一度にダンプし、ユーザーに質問を一つもせずに終了していました。レビューの要点は双方向の対話です。それをスキップすることは目的を無効にします。

そんなものをどうやってテストするのでしょうか？「AIが会話をしたか」をユニットテストすることはできません。従来のテストフレームワークはこれをカバーしていません。

そこで、BunのTTY機能を使ってテストハーネスを構築しました（PR #1354）。これは文字通り、疑似ターミナル内でClaude Codeを起動し、特定のリポジトリシナリオを与え、レビュースキルをトリガーし、ターミナル出力をリアルタイムで監視します。テストは、エージェントが終了前にインタラクティブな質問を発するかどうかを観察します。所見をダンプして何も尋ねずに終了した場合、テストは失敗します。

これはコードをテストしているのではありません。AIエージェントが行動契約に従うかどうかをテストしているのです。TTYレベルで。文字通りそれが動作するのを見守ることによって。

ラチェットの対応は3つの層でした。

スキル指示内のSTOPゲート — 「次のセクションに進む前にユーザーに尋ねなければならない」という明示的なルールと、モデルがスキップすることを自分自身に言い聞かせられないように特定の障害モードを名指しする反合理化条項
近道禁止条項 — 「計画ファイルはインタラクティブレビューの出力であり、その代わりではない」。モデルが悪用し続けたまさにその抜け穴を塞ぐ一文
ゲート層フロアテスト — 制御されたシナリオでClaude Codeを起動し、エージェントが少なくとも一つのインタラクティブな質問をしない場合に失敗するTTYハーネステスト

これで、Anthropicが新しいモデルバージョンを出荷するとき、または私がスキルプロンプトを変更するとき、テストスイートはインタラクティブ契約の後退をキャッチします。エージェントは静かに質問をやめることができません。テストがターミナルを監視してチェックします。

または、PR #880を見てください。これは新しいOpenClawプラグインを出荷しました。テストはコードがコンパイルされるかどうかをチェックするだけではありません。ソースからプラグインをビルドし、隔離されたプロファイルで実際のOpenClawインスタンスを起動し、CLIを介してプラグインをインストールし、plugins inspectを実行してランタイムがロードしたことを確認し、設定スロットを設定し、設定を検証し、plugins doctorを実行して診断がゼロであることを確認します。2つの別々のプログラムにわたる完全なエンドツーエンドのラウンドトリップ。359行のテストコード。セットアップが面倒すぎるため、人間が手で書くことはほとんどない種類のテストです。Claudeは約5分でそれを書きました。それが、努力の壁がリアルタイムで消えていく様子です。

この原則は一般化できます。OSレベルでテストできます。マイグレーションが正しいテーブルを作成したか、cronジョブが起動したか、プロセスがまだ生きているか。ブラウザレベルで：ページがレンダリングされたか、エージェントがフォームに正しく入力したか。APIレベルで：モデルが正しいスキーマで有効なJSONを返したか。行動レベルで：エージェントがプロトコルに従ったか、削除する前に尋ねたか、止めるように言われたら止まったか。

スタック全体がテスト可能です。ラチェットはそのすべてに適用されます。ほとんどの人はまだこれに気づいていません。なぜなら、彼らはまだテストカバレッジを「私の関数が正しい数値を返したか」と考えているからです。本当のテスト表面は、コンピューターが見ることができるすべてのものです。

90%という数字

では、90%のテストカバレッジは実際に何を買ってくれるのでしょうか？

Capers Jonesは10,000以上のソフトウェアプロジェクトを研究し、欠陥除去効率（DRE）を測定しました。これは、ユーザーに届く前にキャッチされるバグの割合です。彼の著書Applied Software Measurementのデータは、非線形曲線を示しています。カバレッジが70%未満の場合、DREは約65-75%です。85-95%のカバレッジでは、DREは92-97%に跳ね上がります。この関係は線形ではありません。約85%のところに曲線の膝があり、欠陥の流出が急激に減少します。

航空電子工学産業はこれを数十年前に理解していました。DO-178Cは、飛行クリティカルソフトウェアに関するFAA標準であり、レベルAシステム（バグが飛行機墜落を意味するもの）には変更条件/決定カバレッジ（MC/DC）を要求しています。ブランチカバレッジだけでは10-20%の障害を見逃します。ラインカバレッジよりも厳格なMC/DCは、>99%のDREを達成します。官僚が書類仕事を好むからこれを義務付けているのではありません。データが、特定のカバレッジ閾値を下回ると、致命的な欠陥が人を殺さないことと両立しない率で流出することを示したからです。

信頼性工学の類似点は明確です。工場はシックスシグマと呼ばれるシステムを使用して品質を測定します。アイデアは、生産された100万ユニットあたりの欠陥数を数え、それを「シグマレベル」として表現するというものです。シグマが高いほど欠陥が少ないことを意味します。3シグマプロセスは100万あたり約67,000の欠陥を生産します（かなり悪い）。4シグマプロセスは約6,200（10倍良い）。5シグマプロセスは233（さらに27倍良い）。4から5シグマへのジャンプは漸進的な改善ではありません。それは相転移です。

テストカバレッジも同じ曲線に従います。70%から90%のカバレッジに行くことは、30%の改善ではありません。それは一桁少ない流出です。70%で漏れる欠陥は、テストされていない30%のコードに隠れています。90%では、隠れ場所は10%に縮小し、危険な経路のほとんどがロックダウンされます。

さて、研究が示していることについて正直になるべきでしょう。Mockus、Nagappan、Dinh-TrongはWindows Vistaを研究し、カバレッジがリリース後の欠陥の減少と相関する一方で、90%以上に到達するための労力は急激に増加することを発見しました。最後の20%のカバレッジは、最初の70%よりも不釣り合いに多くの作業を要します。これは何十年も真実でした。ほとんどのチームが70-80%で止めて「十分良い」と呼ぶ理由です。

しかし、何かが変わりました。AIコーディングエージェントは努力を経験しません。

彼らは14番目のエッジケーステストを書くのに飽きたりしません。金曜日の午後5時に手を抜いたりしません。厄介な統合テストを見て「後で戻ってこよう」とは思いません。人間のチームを70%で止めた努力の曲線は、エージェントには適用されません。Claudeにモジュールのすべてのエッジケースのテストを書くように頼めば、喜んで、徹底的に、午前2時に、文句も言わずに行います。人間のチームにとって90%のカバレッジを非現実的にした過酷な最後の20%は、まさにAIエージェントが最も得意とする種類の作業です。

これが本当の解放です。AIがコードをより速く書けるようにすることではありません。多くの人がそれに気づいています。AIが、以前は維持するには高すぎたレベルでの検証を可能にすることです。データが魔法だと言う90%の閾値？それは維持するには人間の意志の力がかかりすぎました。今では無料です。

それが重要な違いです。ラチェットは虚栄の指標としてのラインカバレッジについてではありません。それは、行動契約をコード化するテストについてです。保持者混乱テスト、重みの丸めテスト、インタラクティブレビューゲート。各テストは、学んだ特定の教訓を固定化します。カバレッジは、システムの動作のどれだけが契約下にあるかを示す代理指標です。90%では、ほぼすべての動作変更がテストシグナルをトリガーします。エージェントは合格するか（出荷しても安全）、テストを壊すか（即座にキャッチされる）です。

残りの10%は、統合ポイント、インフラストラクチャの配管、そして本当にテストが難しいエッジケースです。それは問題ありません。90%が混沌をラチェットに変えるのです。

90%に到達することは、かつては英雄的な努力でした。今では火曜日の仕事です。それがゲームの変化です。

概念実証

私は両方のプロジェクトを一人で始めました。もう一人ではありません。

GStackには現在37人のコントリビューターがいます。v1.30は単一リリースで21のコミュニティPRを取り込みました。GBrainには25人のコントリビューターがいます。v0.31.1.1は、一つのPRで22のコミュニティ修正（認証フロー、スキーマブートストラップ、同期、プライバシー）を取り込みました。

ラチェットがこれを安全にしています。すべての外部PRは既存のテストスイートに合格しなければなりません。新しいコントリビューターはシステム全体を理解する必要はありません。テストに合格させる必要があるだけです。

先週のGBrainリリースが物語っています。

v0.31.0：リアルタイムメモリのための新しいファクトテーブルと、短期記憶を長期知識に昇格させるドリーム統合フェーズ
v0.31.1：空のローカルデータベースに静かにルーティングされていた25のCLIコマンドを修正
v0.31.1.1：一つのPRで22のコミュニティ報告修正
v0.31.2：シンボリックリンクを持つ大規模リポジトリで永久にハングしていたコード同期を、30秒のタイムアウトを追加して修正

各リリースは前回よりも多くのテストとともに出荷されました。エージェントがコードと一緒にテストを書きます。カバレッジは低下しません。それを維持する労力がもはや人間の負担ではないからです。

新しい複雑性の天井

ソフトウェアの複雑性の天井は、はるかに高くなりました。

かつては、一つのチームがシステムを頭の中に保持する能力によって制限されていました。今では、一人の人間と、コードベース全体、スキーマ履歴、テストスイート、ドキュメントをコンテキストに読み込めるエージェントによって制限されます。

それははるかに大きな数字です。そして、コンテキストウィンドウが大きくなり、モデルがコードについての推論に優れるにつれて、成長し続けます。

このモデル（エージェント＋センス＋上がる一方のテストスイート）を採用しないすべてのソフトウェア企業は、すでにそれを持っている一人の人間よりも遅く、低品質で出荷しています。

ツールはここにあります。コードはオープンです。テストがラチェットです。90%のカバレッジ、すべてのPR、例外なし。

50年間、90%のカバレッジは航空電子工学と医療機器のための贅沢品でした。努力の壁に人間の時間を投じる予算を持つチームのためのものでした。AIエージェントはその壁を打ち壊しました。ソフトウェアを信頼性のあるものにするカバレッジ閾値は、もはや高価ではありません。それは単なる設定です。問題は、90%を負担できるかどうかではありません。負担しないことを選べるかどうかです。

ラチェット、スキル、そして知識システム全体は、GitHubでオープンソースかつ無料です。さあ、構築しましょう。

私のMITライセンスのオープンソースプロジェクト：