翻訳記事「AIコーディングツールによって加速するコード生成に品質保証活動はどう立ち向かうか」

AI 技術 翻訳

はじめに

本記事は、Lilia Abdulina（JetBrains の QA責任者）による研究（Vitaly Sharovatovが協力）である「QA in the Age of AI-Accelerated Development」の翻訳記事です*1*2。

本記事は許諾を得た上で翻訳しています*3。

なお、本記事は現在もGitHub上でディスカッションが続けられています。記事を読んで気になった方や疑問を持った方はぜひディスカッションに参加してください！

本記事の主な見どころ

  • AIによって「理解の負債」だけでなく、「意図の負債」も増えている
  • AI以前では副産物として獲得できていた「ビジネスドメインの知識」を蓄積できなくなっている
  • 「評価」よりも「予防」に重きを置いている「積極的な品質保証活動を行う企業」と、そうではない「反応的な品質管理を行う企業」が存在する
  • コストはO(n + εn2)で表現でき、2次項（εn2の部分）を如何に小さくできるかが重要になってくる
    • 「積極的な品質保証活動を行う企業」の方が、2次項を小さくする術を持っている可能性が高い
  • AIによって、「コードが増えた」という量的な変化ではなく、「1行あたりのコードの理解が減った」という質的な変化が発生している。そのため、チェック体制の規模を大きくするだけでは解決できない。

訳者注：登場する企業と現在働いている企業とのギャップがあるかもしれません

本記事は、以下を前提としているように見えます。

  • Agileな開発をしている
  • QAエンジニア（テスター）がいないor開発者と非常に近いところにQAエンジニアがいる
    • QAエンジニアが第三者検証会社の人といったチーム外の人物ではない
  • プロダクトのサイズが過度に大きくなっていない
  • 全体テスト計画、テストレベルが必要となるような大規模な開発ではない

そのため、JTCをはじめとした大手企業には本記事の話が適用しづらい可能性が高いです。

目次

1. 課題の定義

多くの企業が同じ壁に直面しています。チームがコード生成にエージェント型AIを導入すると、コードのアウトプットは加速します。しかし、既存の（手動・自動の両方の）テストでは、生成されるコードの量と多様性に対処しきれなくなっています。これは新たな状況であり、まだ誰も明確な解決策を持っていません。

しかし、テストのボトルネックは表面的な症状に過ぎず、根本的な原因ではありません。AI以前は、コードを書くコストは高く、理解するコストは低いものでした。作成者自身が「何を、なぜ作ったのか」というメンタルモデルを持っていたからです。AIはこの関係を逆転させます。コードを書くコストは安くなりますが、代わりに2つの知見が損なわれ始めます。

  1. 「理解」（Comprehension）：コードが「どう動くか」に関する知見です。かつて人間の作成者が持っていた深い理解を、誰も持たなくなるため知見が少なくなります。
  2. 「意図」（Intent）：コードが「なぜ作られたか」「どのビジネス課題を解決するか」「どのようなトレードオフを許容したか」に関する知見です。意思決定を行った人間がいなくなり、実装したエージェントが何も記憶しないため、この知見は消失します。

これらは性質の異なる「負債」です。「理解の負債」は原因分析や手戻りのコストを増大させ、「意図の負債」はシステムが依然として正しいことをしているかどうかの判断を不可能にします。同時に、時間をかけて品質を向上させてきた「テストでバグを発見 → 開発者が学習 → 次のサイクルで同様のバグが減る」というフィードバックループも弱体化します。人間が行なっていた実装部分がセッションごとにほぼゼロの状態から始まるエージェントに置き換わるからです。その結果、単に「テストすべきコードが増える」だけでなく、コストが蓄積する場所や、機能する品質メカニズムそのものが変化してしまいます。

根本的な前提：品質はコード単体で完結する特性ではありません。 コードが「十分良い」かどうかは、解決すべきビジネス課題、失敗時の重大さ、プロダクトのライフサイクル、そしてチームが受け入れたトレードオフに依存します。たとえコードが全く同じでも、プロトタイプと決済システムでは求められる品質が異なります。つまり、こうしたコンテキストを考慮せず、コードの表面だけを見る品質評価（人間・自動問わず）は、表面的な問題しか特定できません。「このコードは正しいことをしているか？」という深い問いは、ドメイン知識なしには答えられないのです。

2. AI以前のベースライン：エージェント登場前の開発と品質保証活動の動き

一般的なプロセス

  1. 決定（Decision）：何を作るべきかについて、人間同士で合意を形成します（アイデア、仮説、PRD、仕様書など呼び方は様々です）。決定事項は常に不完全ですが、人間は共有されたコンテキスト、ドメイン知識、そしてシステムに対する暗黙の理解を用いてそのギャップを埋めます。この「共有された理解」こそが、品質を支える重要なメカニズムとなります。
  2. 実装（Implementation）：合意に基づき、人間が実装（アーキテクチャ、設計、コード、その他のアセット）を設計・構築します。人間が書いたコードベースは「理解可能」です。他の人間がそれを読み、意図を推論し、振る舞いを論理的に考えられます。この理解容易性は、コードレビュー、デバッグ、メンテナンスにおける暗黙の前提となっています。
  3. テスト（Testing）：実装がステップ1の決定事項と一致するかを検証します。しかし、テストは学習も生み出します。仕様の曖昧さ、ユーザーの実際のワークフローとPRDの乖離、機能間の予期せぬ相互作用などの発見です。この学習はステップ1にフィードバックされ、共有された理解を更新します。したがって、テストには「合否判定（Verdict）」と「学習（Learning：チームが持つシステムモデルの更新）」という2つの機能があります。

テストは主に以下の方法で行われてきました。

  • 完全な手動（人間が決定事項と実装を解釈し、実際に「触ってみて」報告する）
  • 手動と自動の併用（上記に加え、人間が自動テストを書く）
  • 自動テストのみ

ビジネスドメインへの理解

上記の3つのステップすべてにおいて、人間はビジネスドメインの知識を持ち合わせています。そして、日々の業務をこなすだけで、ビジネスドメインの知識を無料で蓄積していきます。

決定において、ドメイン知識は何を明文化し、何を暗黙の了解とするかに影響を与えます。「返金処理が必要だ」という一言も、そのビジネスが前四半期に3ヶ月分のチャージバックを処理したという事実を知っているかどうかで、意味するところは大きく変わります。

実装において、ドメイン知識は設計上の選択に影響を与えます。何を最適化すべきか、どこを慎重に作るべきか、どこを「そこそこで良い」とするか。決済チームに1年所属している開発者は、昨日入ったばかりの業務委託者と同じコードは書きません。

テストにおいて、ドメイン知識はリスクベースの優先順位付けに影響を与えます。ユーザーがエクスポート機能を常に誤用していることを知っているテスターは、その機能をより重点的にテストします。これはプロセス上では目に見えません。「ドメインリスクがあるからここを重点的に」とわざわざ書き記さなくても、人間は自然にそう振る舞うからです。

注意：このドメイン知識は、前述した2つの負債、「理解の負債」（システムがどう動くか）と「意図の負債」（なぜそう作ったか）の両方を補完します。

これが重要なのは、ビジネスドメインの理解が、明示的な活動ではなく、人間がプロセスに関与することによる「副産物」だったからです。誰のコストモデルにも「ドメイン知識の蓄積」という項目が表現されませんでした。自動的に行われるため、予算を組む必要もありませんでした。リスク管理表、アーキテクチャ決定レコード（ADRs）、コンポーネントの重要度分類などを通じて明文化する企業もありましたが、人間が暗黙的に持っている知識のごく一部に過ぎません。明文化された成果物は、人間の判断を補完するものであり、代替するものではなかったのです。

「作業すること」がなぜ学習を生むのか。 この「無料」のドメイン知識蓄積のメカニズムは、認知科学の分野で確立されています。「生成効果（Generation Effect）」（SlameckaとGrafによる1978年の論文、およびMcCurdy他が2020年に行なった126件の論文に書かれていた310件の実験のメタ分析より）によれば、情報を能動的に生成することは、受動的に受け取るよりも劇的に高い定着率をもたらします。その優位性は時間とともに増大し、長期的には約2倍の差が開きます。また、Bjorkの「望ましい困難（Desirable Difficulties）」フレームワーク（1994年および2020年の論文より）は、自分自身で何かを行う際の認知的負荷こそが学習であると定式化しています。苦労は排除すべきコストではなく、理解が形成されるプロセスそのものなのです。

エージェント利用時にドメイン理解の欠如を見落としやすいのは、このためです。学習を生み出していた「生成行為」が失われても、学習を独立した活動として計測していなかったために、その損失に気づけないのです。

ドメイン理解には、「転移可能な専門的ヒューリスティクス」（Howden が「オラクル概念」と呼んだもの）も含まれます。品質保証のプロフェッショナルは、目の前のプロジェクトを知っているだけではありません。他のシステム、言語、ドメインからの類推によって思考します。Kotlinで書かれた新機能をテストする際、テスターはJavaやScalaが同じ概念をどう扱っているかを引き合いに出します。新しいウェブサービスをテストする際は、類似のサービスがどう動くかを参考にします。これはプロジェクト固有の知識ではなく、キャリアを通じて蓄積された、ドメインを横断する専門的な直感です。

ここでエージェントに関する興味深い問いが生じます。LLMは極めて広範なコーパス（数千のシステムのコード、ドキュメント、ポストモーテム）で学習されています。ある意味で、これらもヒューリスティクスの領域で何かを持っています。それは、個人が経験できるよりも遥かに多くのシステムにわたる統計的パターン認識です。これらは非対称なリスクの重み付けを持っています（学習データの中で「決済フロー」は数千の障害報告に登場しますが、「設定ページ」はそうではありません）。しかし、この重み付けは「決済はリスクが高い」「認証はセキュリティに敏感だ」といったレベルに留まります。実際にテストの意思決定を左右するリスク知識は、常にプロジェクト固有のものです（テストの経済学を参照）。

リスク知識を以下の3つのレイヤーに分けて考えると分かりやすくなります。

  1. 戦略的リスク知識（リスクの評価方法、リスク管理表の作成方法、テストをビジネスリスクに紐付ける方法）：プロジェクト間で転移可能です。経験豊富な人間が持ち合わせており、適切なフレームワークで導けば LLM も利用できる可能性があります。テストの経済学はこのレイヤーで機能します。
  2. 母集団レベルのリスク重み付け（決済はリスクが高く、設定ページはそうでないなど）：経験豊富な人間とLLMの両方が持っています。有用な出発点ですが、特定のプロジェクトに対しては調整がずれている（ミスキャリブレーション）可能性があります。前職で決済トラブルを経験したテスターは、新しいチームでも決済に対して過度に慎重になりますが、実際のリスクは誰もテストしていないエクスポートモジュールにあるかもしれません。その場合、「経験に基づく重み付け」は単なるバイアスとなります。LLMも同様で、学習データの関連付けがプロジェクトの現実と一致しないことがあります。
  3. ローカルなリスク調整（「この」プロジェクトでは、エクスポートモジュールに真のリスクがある、など）：特定のコードベース、チーム、プロダクトに関与することでのみ得られます。人間にとっては、作業を通じた暗黙的な学習です。LLMにとっての調整メカニズムは、コンテキスト注入、ファインチューニング、永続的なメモリなどですが、情報の鮮度、開発スピードとのミスマッチ、明文化されていない情報の扱いといった課題が残っています。

レイヤー2と3の間のギャップこそが、真の課題です。LLMのヒューリスティクスが、人間の専門的なヒューリスティクス（網羅性、調整の正確さ、例外の認識力）と比較してどうなのかは、まだ解明されていない研究課題です。今のところ、それに答えるための手法さえ確立されていません。

2種類の企業タイプ

「品質保証活動の文化」や多段階の成熟度モデルを語る人もいますが、ここでは単純化して、市場には2つのタイプの企業があると捉えましょう。異なる品質保証活動のアプローチがどのようにスケールするか、そしてなぜエージェントの登場によってその差がより重要になるかを理解するために、チームレベルでの品質保証活動のコストをモデル化する必要があります。

積極的（プロアクティブ）な品質保証活動を行う企業*4

ステップ1からステップ3のプロセスを人間が設計し、各ステップで高品質なものが作られる確率を高め、その状態を維持しようとする企業です。具体的なプラクティスには、カイゼン（Kaizen）、ゼロバグポリシー、ペア/モブプログラミング、TDD、シフトレフトテスト、継続的なトレーニングなどがあります。品質管理（各段階でのテスト）も行われますが、それは検査や検証（評価）活動として機能します。努力の比重は、「評価」よりも「予防」に置かれています。

ペアプログラミングやモブプログラミングといったプラクティスは、「共有された理解の増幅器」として機能します。これによって、チーム全体のメンタルモデルを一致させ続けます。

ドメイン知識は予防的なプラクティスに組み込まれています。リスクベーステスト、コンポーネントの重要度に応じたクオリティゲート、ビジネスリスクに基づいたアーキテクチャの決定などは、すべてドメイン理解を構造化したものです。

これを運用レベルで見ると「リスクベースの投資モデル」になります。ビジネスリスクを特定し、エクスポージャー（発生確率 × 影響度）で優先順位を付け、最小コストで信頼できる証拠を得られるテスト手法を選択し、定期的にリバランスを行います。これはテストの経済学で詳しく述べられており、テストを「品質コスト（CoQ）」フレームワーク内での経済的投資として捉えています。重要な経済的洞察は、「予防コスト ＜ 評価コスト ＜ 失敗コスト」であるという点です。そのため、積極的な品質保証活動を行う企業は予防に重点的に投資し、リスク削減効果が最も高い場所に絞って評価（テスト）を行います。このモデルのあらゆるステップが、ドメイン知識（どのようなリスクがあるか、失敗のコストはいくらか、何が許容できるトレードオフか）に依存しています。

n個のチームを追加した際ののスケーリング特性は以下の通りです。

チーム内コスト（「線形」の部分）：

  • 品質保証活動の予防的プラクティス（TDD、ペアリングなど）はチーム単位で行われます。各チームが自身の品質保証活動のコストを負担するため、チームの追加に伴う限界コストはほぼ一定です。
  • 自動テストは開発の一部として開発者が記述します。これはチームの規模に比例してスケールし、独立した調整オーバーヘッドにはなりません。

チーム間コスト（「隠れた超線形*5」の部分）：

  • CIインフラへの負荷：テストは共有パイプラインで実行されます。CIの実行時間はテストの総数とともに増加します。また、フレーキーなテスト（Flaky test）の確率は複合的に作用します。t個のテストがそれぞれ独立した失敗確率pを持つ場合、1回の実行で少なくとも1つが失敗する確率は "1-(1-p)t" となり、すぐに1に近づきます。フレーキーなテストの調査コストは複数チーム共有の負担となります。
  • チーム間のテスト衝突：チームAの変更がチームBのテストを壊すことがあります。その調査コストはチームのペア数、つまり O(n2) で増加します。
  • 共有しているテストユーティリティ/フィクスチャ：依存するチームが増えるほど、そのメンテナンスは調整上の問題へと発展します。
  • アーキテクチャの整合性：システム全体を論理的に考えることが難しくなります。調整メカニズム（アーキテクチャレビュー、プラットフォームチーム、インターフェース規約など）が必要になります。

実際のコスト関数：O(n + εn2)

ここで各変数は以下の通り

  • n = チーム数
  • ε = チーム間調整係数
  • 積極的な品質保証活動を行う企業では、アーキテクチャ上の工夫（明確なモジュール境界、API、規約）によって、ε を小さく保つ努力がなされています。
  • ε がゼロになることはありません。積極的な品質保証活動を行う企業における「線形性」とは、2次項が消えたということではなく、その係数を小さくするために投資していることを意味します。

積極的な品質保証活動を行う企業と反応的な品質管理を行う企業の差は、単なる ε の大きさだけではありません。「小さいεかつ手戻り倍率なし」か、「大きいεかつ手戻りループによる複合的影響あり」かの違いです。

反応的（リアクティブ）な品質管理を行う企業

積極的な品質保証活動がほとんど行われていない企業です。品質を保証する(Assured)のではなく、事後的に管理し(controlled)ます。テストは開発の「後」に行われ、デリバリーのスピードに追いつけないことが多々あります。開発者とテスターのメンタルモデルが乖離し、テストは「全員で合意したことを検証する」のではなく、「開発者が何を意図したか推測する」作業になってしまいます。

プロセスとして活用されていなくても、ドメイン知識は個人の頭の中に存在しています。テスター個人は依然として「この領域はリスクが高い」と分かっていますが、それを構造的にプロセスに組み込むことができません。

n個のチームを追加した際のスケーリングは、遥かに困難です。

  • 手戻りフィードバックループ（超線形）：欠陥の発見 → 手戻り → 修正による新たな欠陥の混入率r。欠陥解消に要する総労力は約 1/(1-r) 倍になります。システムの複雑さが増すとrも増加し（修正が他を壊す確率が上がる）、倍率そのものが大きくなります。これは正のフィードバックループであり、スケーリングは欠陥混入率に応じて線形と2次関数の間になります。数式で言えば、基本の欠陥数が O(n) でスケールし、各修正がr個の新しい欠陥を生む場合、総労力は O(n / (1-r))に近似します。r自体が複雑さ（nとともに増加）の関数であるため、分母はnの増加とともに小さくなり、実質的なスケーリングは超線形となります。
  • 自動テストのメンテナンス（超線形）：新しいテストを書くコストはO(n)かもしれませんが、メンテナンスコストはシステムの相互接続の度合いとともに増大します。新機能の追加により、バグではなく「前提条件の変化」によって既存のテストが壊れることがあります。この脆さはモジュール間の依存関係の数に比例し、最悪の場合はO(n2)でスケールします。
  • 手動テスト（超線形）：組み合わせの爆発です。システムにk個の相互作用する機能がある場合、状態空間は組み合わせ論的に増加します。新しいチームが既存機能と相互作用する機能を追加するたびに、テストすべき組み合わせは機能数よりも速く増えていきます。

積極的な品質保証活動と同じ枠組みで考えると、コストは同様にO(n + εn2) です。しかし、2次項を抑えるための投資がないため、εは遥かに大きくなります。さらに、手戻りループによる乗数的因子1/(1-r(n))が加わるため、実際のコストはO( (n + εn2) / (1-r(n) ) )に近づきます。これはrが 1 に近づくにつれて急激に増加します。

歴史的証拠：チェック体制のモデルはすでに限界に達していた

AI以前から、システムの複雑化に伴い、決定論的なテストは何度も「組み合わせの壁」に突き当たってきました。その都度、業界は「不完全さ」を受け入れる新しいパラダイムを生み出すことで対応してきました。各パラダイムは、特定の限界に達した歴史的記録とも言えます。

パラダイム 年 限界に達したもの 限界の内容 対応策
ファジング 1988 入力空間 全ての入力を列挙できない 入力空間からランダムにサンプリングし、何が壊れるか観察する
プロパティベーステスト 2000 シナリオ空間 全ての有効な入力と状態の組み合わせを列挙できない 不変条件（インバリアント）を指定し、フレームワークにケースを自動生成させる
カオスエンジニアリング 2011 相互作用/失敗空間 分散システムにおける全ての失敗の組み合わせを列挙できない 本番環境にランダムに失敗を注入し、創発的な振る舞いを観察する

これはリスクベースの E2E テストと同じ原則です。すべてのユーザージャーニーをテストするのは不可能であるため、チームはクリティカルなフローを優先します。つまり、扱いやすさと引き換えに不完全さを受け入れているのです。

共通の動き：列挙が困難になったとき、「決定論的な検証（Deterministic Verification）」から「確率論的な探索（Probabilistic Exploration）」へとシフトします。これはテストに応用したモンテカルロ法です。解析的に積分を計算できないとき、サンプリングを行うのと同じです。

これらのパラダイムは従来のテストを置き換えたのではなく、補完したものです。企業は依然としてユニットテストを書くと「同時に」カオステストも行います。以前のレイヤーでは届かなかった種類の欠陥に対処するために、新しいレイヤーとして登場したのです。テストのスタックは成長し続けています。

これら3つのパラダイムは、列挙の不完全さを受け入れつつも、依然として基盤には人間の理解を必要としていました。

  • ファジングでは、どのクラッシュが重要かを認識し、根本原因を診断するために人間が必要です。
  • プロパティベーステストでは、不変条件を指定するために人間が必要です（これには「正しさ」とは何かを理解している必要があります）。
  • カオスエンジニアリングでは、失敗時のシステムの振る舞いを解釈し、レジリエンスパターンを設計するために人間が必要です。

これが、AIへの移行における重要な分岐点です。AI以前のテストの世界は、決定論的な列挙がスケールしないために、すでに確率的なアプローチへと進化していました。しかし、どの新しいパラダイムも、「人間がテストを設計し、結果を解釈し、対策を講じることができるほど深くシステムを理解していること」を前提としていました。AIによる開発の加速は、まさにこの土台を脅かしています。

3. エージェントがいる世界：現在のプロセスの流れ

一般的なプロセス：ステップは同じでも力学が異なる

  1. 決定：何を作るかは依然として人間が決めます。しかし、仕様は「人間」と「エージェント」という2種類の受け手を対象にするようになりました。エージェントには共有された理解も、コードベースの歴史に関する知識も、暗黙知もありません。その結果、仕様はより重要（エージェントは与えられたものからしか動けないため）になると同時に、より不十分（暗黙知という補完メカニズムが欠如しているため）になります。
  2. 実装：エージェントは劇的なスピードでコードを生成しますが、同時にいくつかの要素が崩壊します。
  3. 理解の逆転：以前は実装者がコードを最も理解していました。今では、実装者（エージェント）に永続的な理解はありません。コードは存在しますが、作成者がかつて持っていたような深い理解は誰にもありません。これは「コードが増えた」という量的な変化ではなく、「1行あたりのコードの理解が減った」という質的な変化です。
    • 理解可能な成果物の劣化：AIが生成するコードは文法的には流暢ですが、その「意図」はプロンプトからの派生であり、深い設計上の推論に基づくものではありません。一見熟練の人が好む書き方に見えても、微妙に間違っている可能性があります。
    • 共有理解が蓄積されない：人間の開発者は数ヶ月かけてメンタルモデルを構築しますが、エージェントはセッションごとにほぼゼロから始まります。生成の出来事は毎回、ある程度コンテキストから切り離されています。 この「理解の逆転」には経験的な裏付けがあります。第2節で述べた「生成効果」の観点から言えば、コードを書く行為から「レビューや受け入れ」に回ることは、記憶を定着させる生成行為を放棄することを意味します。2025年にBastani他が行なった調査では、GPT-4 を使用した学生は、アクセスを遮断された後の評価テストにおいて、最初から AI を使わなかった学生よりも17%成績が悪くなりました。2026年のShenとTamkin (Anthropic所属) の研究では、AI にコード生成を丸投げしたエンジニアの理解度は50%で、自力で書いた場合の67%を大きく下回りました*6。興味深いことに、丸投げではなく概念的な質問に AI を使ったエンジニアは理解度を維持していました。また、2025年のBecker他（METR）の研究では、経験豊富な開発者がAI を使用した場合、自分のリポジトリでの作業に19%長い時間がかかったにもかかわらず、本人は「20%速くなった」と認識していることが分かりました。この認識のズレこそが、理解の負債が目に見えない形で蓄積している証拠です。
  4. テスト：3つの機能が異なる形でストレスを与えます。
    • 合否判定機能のパンク：検証すべきコードは激増しますが、検証を行う人数は同じ（あるいは減る）ため、処理能力を超えます。
    • 学習機能の崩壊：テストは学習を生みますが、エージェントには更新すべき永続的なメンタルモデルがありません。「テスト → 実装」のフィードバックループは著しく劣化し、同じ種類のバグが際限なく再発する可能性があります。
    • 意思決定へのフィードバックは維持される：人間は依然としてテストから学びます。しかし、時間の経過とともに実装の品質を改善していくループは消失しました。
    • AI生成テストのブートストラップ問題：AI がコードとテストの両方を生成すると、同じ盲点を共有する恐れがあります。人間のテスターは独立したドメイン理解を持ち込みますが、AIが同じ仕様からコードとテストを作ると、同じ誤解を共有しているためにpassしてしまうテストが生まれます。
    • 障害モードがこれまでと異なる：人間が書くバグは予測可能な箇所（位置や順序ズレ、エッジケースの漏れなど）に発生します。AI生成のバグは異なり、コードは「正しく読める」ように見えるが微妙に間違ったロジックを実装しています。既存のテスト技法では、こうしたバグを体系的に見逃す可能性があります。

ビジネスドメインの理解は、「方法（How）」と「理由（Why）」の両面で質的に低下します。 エージェントは自分が生成したコードへの「理解（How）」を欠いています。文法的に正しい実装を行いますが、セッションをまたいで持続するメンタルモデルは構築されません。また、エージェントは「意図（Why）」も欠いています。このビジネスドメイン、このリスク特性、このプロダクトの状況、あるいはこのチームが受け入れたトレードオフを知りません。学習データに基づく広範な統計的パターン認識はあっても、結果に裏打ちされた調整、コンテキストに応じた例外の認識、プロジェクト固有の知識の蓄積はありません。プロンプトや設定ファイルで多少のコンテキストを与えることは可能ですが、人間のように時間をかけてドメイン理解を深めることはありません。決済フローの障害対応を経験した人間の開発者は、その後のすべての判断にその経験を活かします。しかし、エージェントは毎回ほぼゼロからスタートします。たとえドメインのコンテキストを明示的に与えても、エージェントには「間違えたときの結果を身をもって知っている」経験から来る判断力が欠けているのです。

劣化したフィードバックループを部分的に補完する3つのメカニズムがあります。外部的な永続化（CLAUDE.md やメモリツール、セッションをまたぐ REVIEW.md ファイルなど）、ホスト型ファインチューニング（プロバイダーAPIを介してチーム固有のパターンに基づいてモデルの重みを調整）、オープンウェイトモデルのローカル調整（Low-Rank Adaptation[LoRA]や同様の手法）です。これらは検討に値する手法です。しかし、これらが提供する「情報の想起」や「パターンの調整」は、AI以前のフィードバックループが提供していたものとは本質的に異なります。AI以前のフィードバックループは「リスク発生 → 痛みを伴う経験 → 根本原因の分析 → 判断の更新 → 行動の変化」という、コード生成速度に合わせた自律的な自己修正プロセスでした。現在の補完メカニズムは過去の結論のスナップショット（事実やルール）を保持するに過ぎず、経済的な重み付け（何と比較してどれほどリスクがあるか）、再評価のトリガー（いつ情報が陳腐化したか）、明文化されていないことへの認識を欠いています。そして何よりも重要なのは、これらは人間のスピードで動作するのに対し、リスクの発生はマシンのスピードで進みます。これらのメカニズムが適切な経済的枠組みと組み合わさることで、機能的なフィードバックループを再構築できるかどうかは、今後の研究課題です。

経済性のシフト：AI時代における Boehm の曲線

AI 以前の Boehm の変更コスト曲線によれば、欠陥の修正コストは、要件定義 → 設計 → コーディング → テスト → 本番環境と進むにつれて指数関数的に増大することを示していました。欠陥の発見が遅れるほど、既に積み上げられた成果物が増えた状態になっており、すべてに手戻りが発生するからです。

AI 時代では、コード生成と書き直しは安価になります。エージェントは数秒で関数を再生成できます。これを聞くと曲線が平坦化するように思えるかもしれませんが、実際は違います。コストの要因が「手戻りの量」から「理解の負債」へとシフトし、曲線はさらに急勾配になります。

アクティビティ AI以前 AI時代
コードを書く 高価（人間の時間） 安価（エージェントが生成）
コードを理解する 無料（作成者が理解している） 高価（誰も深く理解していない）
コードを書き直す 高価（人間の時間） 安価（エージェントが再生成）
書き直すべき場所を見つける 普通（理解しているコードを辿る） 非常に高価（理解のギャップ）

その結果、以下のようになります。

  • 間違ったアイデアはあっという間に広まります。：以前は欠陥のある仕様に対し、一人の開発者が人間のスピードで間違ったコードを書いていました。今はマシンのスピードで大量の間違ったコードが生成されます。そのため、発見し修正すべき「間違った成果物」が激増します。
  • 診断コストの増大：人間が書いたコードで本番障害になった場合、作成者がすぐに修正できることが多いでしょう。作成者は理解しているからです。エージェントが書いたコードは、誰も深く理解していません。書き直しコストは下がっても、診断コストは上がります。
  • 結合コストの維持または悪化：関数の書き直しは安価ですが、その関数がシステム全体とどう相互作用するか、他に何が壊れるか、どのような波及効果があるかを理解するコストは高価なままです。理解度が低下しているため、むしろ状況は悪化します。
  • 本番障害のコストは不変：顧客離れ、サービス停止、制裁金、評判の失墜などは、コードがいかに安く書き直せるかとは無関係です。これらは純粋なビジネスコストです。

AI 時代の Boehm 曲線は、「コーディング」セクションは崩壊します（安価に生成・再生成可能）が、「アイデア → 仕様」セクションはさらに重要（間違いがマシンスピードで増幅されるため）になり、「テスト → 本番」セクションはより急になります（診断が難しく、人間の理解力が低下しているため）。コードを書くコストが下がっても、欠陥による総コストは増加する可能性があるのです。

AI以前の曲線は「欠陥を通じてどれだけの作業が積み上がったか」に支配されていました。AI時代の曲線は「積み上がったものをどれだけ理解していないか」に支配されます。指数関数的なコスト増加の要因は、手戻りの量から「理解の負債」へと移り変わったのです。

これには直接的な経済的意味があります。品質コスト（CoQ）のフレームワークでは「予防 ＜ 評価 ＜ 失敗」の順にコストがかかります。AI時代ではこの格差が広がります。間違ったアイデアが大量の間違ったコードへと増幅されるスピードが速まり、理解の負債によって後段の診断が困難になるため、生成後のコードを検査する「評価」に比べて、アイデアや仕様を正しく定義する「予防」の重要性がさらに増すからです。

2種類の企業タイプ：エージェント導入後の変化

積極的な品質保証活動を行う企業

予防的なプラクティスが一部機能しなくなります。

  • TDD は、人間が先にテストを書き、エージェントが実装する形であれば依然として有効です。しかし、良いテストを書くにはシステムへの深い理解が必要であり、結局「仕様の定義」という難題に戻ってきます。
  • ペアプログラミングをエージェントと行うのは、根本的に別物です。エージェントは設計に反対意見を言わず、独立したドメイン知識も持ち合わせません。それは強力な「道具」ではあっても、「思考のパートナー」ではありません。
  • 共有された理解の増幅器は、人間同士の知識伝達のために設計されたものです。一方がエージェントである場合、そのままでは適用できません。

アーキテクチャの整合性コストが増加します。エージェントは明示的に制約を与えない限り、自発的にアーキテクチャの境界を尊重することはないからです。

しかし、積極的な品質保証活動を行う企業の方が有利な位置にいます。「品質をプロセスに組み込む」というマインドセットがすでにあるからです。自然と、エージェントのワークフローに品質の制約（優れたプロンプト、アーキテクチャ上のガードレール、仕様レベルのテストなど）を組み込もうとするでしょう。これは「プラクティスの適応」であり、「崩壊」ではありません。

エージェント利用時のスケーリングについて、O(n + εn2) フレームワークで考えると、2つの影響が同時に発生します。

  1. 実質的なnの増加：エージェントによって1チームあたりのアウトプットが倍増するため、コード量という観点での「実質的なチーム数」が増加します。εが小さくても、n が大きくなればコストは跳ね上がります。
  2. ε自体の増加：従来の調整コストは「人間が互いのコードを読み、衝突を解決できること」を前提としていました。エージェント生成のコードが理解しにくくなると、ペアごとの調整コストは上昇します。つまりεが大きくなります。

O(n + εn2)への複合的な影響：実質チーム数をn'、調整係数をε'とすると、2次項は(ε'/ε)・(n'/n)2倍に膨れ上がります。結果は不透明ですが、予防的なプラクティスを適応させてこれら2つの影響を抑え込むことができれば、おそらく管理可能でしょう。

反応的（リアクティブ）な品質管理を行う企業

すでに超線形のスケーリングに苦しんでいる状況が、さらに悪化します。

  • コード量が倍増 → チェック体制（の規模）を今まで以上のスピードで拡大する必要に迫られます。
  • 手戻りループがさらに加速します。
  • 手動テストが完全に崩壊します。
  • 補完するプロセスがないため、理解のギャップが最も深刻になります。

以下はLilia（本記事の著者）がJetBrainsで目撃している状況です（同社はこれら2つのタイプの中間に位置するため、この兆候はより警報的な意味を持ちます）。

O( (n + εn2) / (1-r(n) ) )フレームワークでのスケーリングは以下のようになります。

  1. 実質的なnが劇的に増加（積極的な品質保証活動を行う企業と同様）。
  2. もともと大きなεがさらに増大（コードの理解しにくさにより調整がより困難に）。
  3. r(n)の増加：修正を行う人間が周囲のコードを理解していないため、手戻り時にバグを混入させる確率が高まります。分母の1-r(n)がより速く小さくなります。

すべての項が同時に悪い方向へ進みます。これらの影響は加算的ではなく乗算的に作用するため、超線形なコストは単に増えるだけでなく、加速度的に増大します。

何が質的に新しいのか（単なる「延長線上」ではない変化）

要因 AI以前 エージェント導入後
コード量 — 加速（量的な変化）
1行あたりの理解度 一定 低下：エージェントが書いたコードを誰も深く理解していない
フィードバックループ（テスト→実装） 機能する 著しく劣化：永続化ツールや LoRA は情報の想起を助けるが、判断力の更新は行わない。人間スピードの文書化とマシンスピードのリスク発生のズレが拡大する
共有された理解 仕様の隙間を埋める エージェント側で欠如：仕様の隙間が埋まらないまま残る
テストの独立性 人間が独立した視点を持ち込む AIテストがコードと同じ盲点を共有する恐れ
失敗モード 予測可能、ヒューリスティクスで検知可能 新しいモード：正しく見えるが微妙に間違っている
ビジネスドメインの理解 人間がコンテキストを保持（リスク、ライフサイクル、トレードオフ）。転移可能な専門的知見（オラクル概念）も含む 質的に異なる：LLM は統計的パターンは持つが、実体験に基づく調整、例外の認識、プロジェクト固有の知識を欠く。「理解が容易な部分」は残っているが、予防に必要な「理解が困難な部分」が失われる
意図の保持 人間が「なぜ」を保持（ビジネス上の理由、設計判断）。決定プロセスへの関与で自然と蓄積される 浸食：エージェントは意図を保持せず、意思決定した人間は配置換えになったり忘れたり退職したりする。意図の負債は目に見えない形で蓄積され、問題が発生した時ではなく、意思決定が必要になった時に顕在化する。例えば、「この機能を実装すべきか？」「この製品はまだ本来の目的を果たしているか？」といったことなど。

1行目は量的な変化ですが、2行目から8行目は質的な変化です。これが「単にチェック体制の規模を拡大する」だけでは解決できない理由です。チェック体制の規模を拡大することは1行目の対策にはなっても、2行目から8行目の質的な課題には届かないからです。

4. 今後の研究課題

今回の分析では、2つの負債は、どちらも等しく譲れないものではないということも指し示しています

「意図」は絶対的です。 「なぜ」がなければ、成功を定義することも、プロダクトを評価することも、次に何を作るべきかを決めることもできません。意図を失えば、それは「プロダクト作り」ではなく単なる「コード生成」に成り下がります。意図の負債は、システムが壊れたときではなく、意思決定が必要なときに露呈します。その瞬間、どれほど「どう動くか」を理解していても、「なぜ存在するのか」を知らなければ、何の役にも立ちません。

「理解」は条件的です。 監視（エージェントの間違いに気づく）、介入（壊れたときのデバッグ）、進化（将来のアーキテクチャ判断）を行うのに十分な程度の理解は必要です。しかし、自分でコードを書いたときのような、1行ごとの深い理解までは必要ないかもしれません。AIを活用したペアリング（ドメインエキスパートとエンジニアが協力し、実装をエージェントに任せる）の経験則では、適切な協力体制があれば、「部分的な理解」と「完全な意図」だけでチームを運用できる可能性が示唆されています。

どれほどの理解が必要かは、エージェントの信頼性と、意図がどれだけ維持されているかに依存します。意図が揺るぎなく、エージェントが極めて信頼できるなら、必要な理解は少なくなります。逆に、エージェントが不安定で意図が曖昧なら、人間にはより深い理解が求められます。

ここから、中心的な研究課題が導き出されます。

「意図の保持」「理解のレベル」「エージェントの学習能力」の間にはどのような関係があるのか。そして、どのような条件下であれば、理解の低下を「より強力な意図のコントロール」と「より優れたエージェントの学習」によって安全に補完できるのか。

これは特定の立場を固持するものではなく、新たな設計の余地を提示するものです。そして、テストの経済学のフレームワークに直結します。「理解」とは一つの投資であり、その必要量は、リスク、エージェントの信頼性、そして「意図」を担保するメカニズムの品質によって決まるのです。

おわりに 〜訳者の感想〜

本記事では、積極的な品質保証活動を行う企業の良さをコスト関数「O(n + εn2)」という形で表現しようと試みているのも良いと感じました。このように表現した結果、なんとなく「この品質保証活動は良さそうだ/良くなさそうだ」と判断していて経営層に伝えづらかった部分を、少しだけ分かりやすくしてくれているのかなと思っています。

また、「意図の負債」という表現で、なかなか明示的に示されなかった部分を示している良い文章だと感じています。この「意図の負債」は、仕様駆動開発（Spec-Driven Development, SDD）では解消しづらい部分であり、広義の振る舞い駆動開発（Behavior-Driven Development）では大切にしている部分だと思っています。詳しくは以下の記事などを参考にしてください*7。

nihonbuson.hatenadiary.jp

本記事を翻訳した結果、今まで学んできたことや経験してきたこと（BDD、テスト要求分析、品質保証活動など）が、AIの時代においてはより一層必要になるなと改めて感じることができました。

私は以上のような感想を持ちましたが、読者の皆さんはいかがでしたでしょうか。品質保証活動に対しての取り組み方や意識が少しでも良い方向に変わることを願っています。

*1:記事内では翻訳した当時の変更履歴のリンクを掲載しています。現在は構成を変更しています。最新版は以下を確認してください。github.com

*2:元記事のタイトルを直訳すると「AI加速開発時代における品質保証活動」ですが、文章の中身はAIコーディングツールに限定した内容になっているため、それに合わせてタイトルを修正しています

*3: id:hazlitt さんに「翻訳権の所在等を記載すべき」という旨をご指摘いただきました。本記事公開前から既に許諾を得てはいたのですが、記載するのを失念していました。ご指摘ありがとうございます！

*4:訳者注：原文は「Proactive QA companies」と書かれています。この中の「QA」は「QAエンジニア」といった職種を指すのではなく、「品質保証活動」を指していると、筆者は全文を読んで理解しました。そのため以降出てくる「QA」は全て「品質保証活動」と訳しています。

*5:訳者注：本記事においての超線形とは指数関数的な意味合いで用いられています。これは、指数関数ではないが傾きがだんだん大きくなる関数も含まれています。例えば、欠陥解消に要する総労力"(n/1-r)"は、指数関数ではないが傾きがだんだん大きくなる関数の一例です。

n/(1-r) のグラフ（画像はn=1を指定）

*6:日本語での解説記事はこちら。magicpod.com

*7:完全なるポジショントークです