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

AIコーディング時代の複雑性ラチェット(Complexity Ratchet) - Garry Tanのエッセイ要約

Garry Tan（Y Combinator CEO）がXで共有した長文エッセイで、過去1年間にAIエージェント（Claude Code、Codex など）とともに2つのオープンソースプロジェクトを作った経験を整理した文章です。約97万行のコードと665のテストファイルの大半をAIが作成し、同時に15のエージェントセッションを運用したといいます。彼はこの過程を通じて、「速度と品質は二者択一」というソフトウェア工学の長年の命題が崩れたと主張し、その中核メカニズムとして「複雑性ラチェット（Complexity Ratchet）」という概念を提示しています。

中核概念の整理

• ラチェット（Ratchet）とは 一方向にしか動かない歯車装置を意味する比喩で、コードベースの品質が後退せず前進だけするようにする構造を指します。
• 3つの蓄積物 エージェントとの各コーディングセッションごとに、テスト（何が正しいか）、ドキュメント（なぜそう決めたか）、評価結果（品質ベースライン）の3つがコードベースに蓄積されます。
• コンテキストウィンドウの活用 次のセッションでAIエージェントがこの3つをすべて読んで作業するため、テストを壊したり、ドキュメントを無視したり、評価スコアを下げたりできなくなります。

従来方式との違い

• エラーモデルの変化 過去50年間、ソフトウェア工学は「エラーは致命的だから予防せよ」という前提でコードレビュー、QA、ステージングなど複雑なプロセスを作ってきましたが、今では大半のエラーをエージェントが次のターンで診断して修正できます。
• 複雑性限界の拡張 システム複雑性の上限は「1チームが頭の中に保持できる量」から「1人と、コードベース全体をコンテキストにロードしたエージェントたち」へと広がりました。
• 制度的記憶の永続性 人は退職やバーンアウトで去りますが、テストとドキュメントとして残った知識は、どのモデルでもどの時点でも再び呼び出せます。

90%テストカバレッジの意味

• 非線形な品質曲線 Capers Jonesの1万件超のプロジェクト研究によれば、カバレッジ70%以下では欠陥除去率が65〜75%にとどまる一方、85〜95%では92〜97%へ急上昇する「膝点」が存在します。
• 航空産業の先例 航空ソフトウェア標準DO-178Cは、Level A（致命的）システムにMC/DCカバレッジを義務付けており、これは99%以上の欠陥除去率を達成するためです。
• AIが壊したコスト障壁 最後の20%のカバレッジを埋める作業は人間には退屈でコストが大きかったものの、エージェントは疲れを感じないため、深夜でもエッジケースのテストを際限なく書き続けます。

筆者が示した実例

• GBrainの抽出精度改善 10万件以上の信念抽出において、「誰がその主張をしたのか」を35%誤認していた問題を17のテストで固定し、どの後続バージョンもそれ以下に落ちないようにしました。
• SuperpowersのTTYテスト AIエージェントが対話型レビューをスキップする挙動を、Bunの疑似ターミナル機能で直接監視・遮断し、「AIが対話をしたか」という非伝統的な要件もテスト化しました。

利点と限界

• 利点 外部コントリビューターがシステム全体を理解していなくても、テストさえ通せば安全にPRをマージできるため、協業への参入障壁が下がります。
• 限界 状態を破壊する種類のエラー（誤ったDBマイグレーション、セキュリティ侵害、プライバシー漏えい）は依然として致命的であり、約10%の統合ポイントとインフラは本質的にテストが困難です。
• 反論への回答 「テストをうまく書ける人は、もともとアーキテクチャもうまく設計できる」という指摘に対して、ラチェットの核心は人ではなく次のターンのセーフティネットにある点を強調しています。

この文章で筆者が伝えたい核心は、AIコーディングの本当の価値は「速く書くこと」ではなく、「これまで高コストすぎて諦めていた水準の検証」を無料にした点にある、ということです。50年間にわたり航空・医療分野の専売特許だった90%テストカバレッジが、今や1人の開発者の日常になり得るようになり、その結果、1人の開発者が作れるソフトウェアの複雑性の上限が劇的に高まったという観察です。ただし、文章自体が自身のオープンソースプロジェクト（Superpowers、GBrain）の宣伝も兼ねており、統計引用の一部（例: GPT-5.5）には検証が必要な部分もあるため、批判的読解が必要なテキストでもあります。