8月29日、Microsoft（devblogs.microsoft.com）が「Only believe what you can validate: a verification framework for agentic AI」と題した記事を公開した。エージェント型AIが生成した出力をどう検証するか、その実践的なフレームワークを詳しく解説した内容だ。記事が一貫して訴えるのは「検証機構なしにエージェント型AIの出力は評価できない」という原則であり、そのための具体的な問いとレイヤー構造を提示している。
「なんとなく正しそう」は正しいのか？
アプリケーションのモダナイゼーション（レガシーシステムの刷新）現場でエージェント型AIを使う際、ある典型的な場面が繰り返される。COBOLモジュールをAIに解析させると、5分で2500語超のドキュメントが生成される。担当者が最初の10〜20行をざっと眺めて「パッと見た感じ、問題なさそうです」と言う。
しかしこれは何も証明していない。検証しやすい箇所はモデルも正確に出力しやすい。冒頭のレコードレイアウトが正しいからといって、残りの2480語が正しいとは言えない。そして、その知識を習得するのに数十年かかった専門家が、出力全体を精査するには数時間かかる。これが150モジュールあるとしたら、スケールしないのは自明だ。
なぜ「良さそうに見える」出力が危険なのか
記事ではコンテキストウィンドウの劣化現象を「context rot（コンテキスト腐敗）」として紹介している。この概念は、長大なコンテキストを扱うLLMの実運用において観察される品質劣化パターンを指す用語として記事中で用いられている。コンテキストウィンドウの使用率が50%を超えると冒頭部分の保持精度も下がり始める一方で、モデルは引き続き自信満々に出力を続ける（この数値は元記事内で言及されているものだ）。
この状態で発生する失敗モードは3つに分類される：
- The miss（見逃し）：含めるべき内容がそもそも抜けている。技術的に間違っているわけではないが不完全。
- The hallucination（幻覚）：存在しない、または事実でない内容をもっともらしく生成する。
- The misinterpretation（誤解釈）：指示が少し曖昧だった結果、モデルが「最善を尽くして」間違った出力を返す。
検証の3プレイヤーとそれぞれの限界
検証には「人間」「AI」「決定論的ツール」の3者が関わる。それぞれ単独ではスケールしない。
- 人間＋AI：AIが誤りを出した場合、人間が気づいてもAIは「根本原因を探れ」と明示的に指示しない限り、指摘された箇所だけを修正して終わる。
- AI＋決定論的ツール：コンパイルは通るが事実として誤っているコードは、パイプラインを緑にしたままプロダクションに出荷される。
- 人間＋決定論的ツール：自動化は依然として難しい。「手作業で5秒でできることをなぜ自動化するのか」という誤った前提が残り続け、技術的負債が積み上がる。
この問題提起に対し記事が示す答えが、冒頭に掲げた原則——「検証機構なしにエージェント型AIの出力は評価できない」——だ。
6つの問いで構成する検証フレームワーク
記事では、どんな用途にも適用できる検証の骨格として以下6つの問いを提示している：
- 何をチェックするか？ ─ 具体的に実行・測定するもの
- 構築コストは？ ─ 金・時間・専門知識・本番データへのアクセス
- 誰が実施するか？ ─ 決定論的ツール、エージェント型AI、人間、またはその組み合わせ
- 何を証明できるか？ ─ そのチェックで実際に何がわかるのかを正直に評価する
- 結果は何か？ ─ 具体的で行動可能なアーティファクト
- 使えるツールは何か？
そしてこのフレームワークをリバースエンジニアリングとコード生成の2領域に適用した検証レイヤー表を提示している。
リバースエンジニアリングへの適用例
| レベル | チェック内容 | コスト | 担当 | ツール例 |
|---|---|---|---|---|
| 0a | 参照エンティティが全てコードベースに存在するか | 低 | 決定論的 | SonarQube、CAST、cobol-rekt |
| 0b | ドキュメント標準への準拠・冗長性チェック | 低 | エージェント型AI | エージェント型AIパイプライン |
| 1 | ドメイン専門家による1モジュールのビジネスルール確認 | 低 | 人間 | 手動レビュー |
| 2 | ユースケース記述からテスト生成・実行（100%カバレッジ） | 中 | 決定論的＋AI | 共通テストFW、AI |
| 3 | 全スコープのビジネスルールを専門家が確認 | 高 | 人間 | 構造化インタビュー |
| 4 | 本番実行トレースとの照合 | 高＋運用コスト | 決定論的＋人間 | OpenTelemetry、Datadog、IBM OMEGAMON |
| 5 | ライブシステムへの継続的バリデーション | 非常に高＋運用コスト | 決定論的 | コントラクトテストFW |
Level 0aで使われる**cobol-rektはCOBOLコードの静的解析・グラフ化を行うオープンソースツール、Level 4のIBM OMEGAMONはメインフレームの本番実行モニタリング製品、OpenTelemetry**は分散トレーシングの業界標準仕様だ。Level 0bの担当を「エージェント型AI」と限定しているのは、単純な補完生成ではなく自律的なタスク実行能力を前提としているためだと記事は説明している。
コード生成への適用例
コード生成は、「成熟したソフトウェアエンジニアリング文化では品質ゲートが既に存在しているはず」という前提のもと、AI生成コードにも同じ基準を適用すればよいと整理されている。
| レベル | チェック内容 | コスト | ツール例 |
|---|---|---|---|
| 0a | コンパイル・実行可能か | 無料 | javac、dotnet build、Maven |
| 0b | リントで重大な違反がないか | 低 | ESLint、SonarQube、PMD |
| 0c | 高/クリティカルな脆弱性・既知CVEがないか | 低 | Snyk、Checkmarx、Semgrep |
| 1 | エッジケースを含む単体テスト | 低 | JUnit、pytest、Jest |
| 2 | 隣接システムとの統合テスト | 中 | Testcontainers、WireMock |
フレームワーク自体の価値——「書き下ろすプロセス」が核心だ
記事が最も強調するのは、表の完成よりも「書き下ろすプロセス」に価値があるという点だ。多くのチームでは検証モデルが専門家の頭の中にしか存在せず、文書化されていないため、一貫性がなく不可視だった。それを言語化することで、「このチェックは意味がほとんどない」「このレイヤーが丸ごと抜けている」という事実が初めて見えてくる。
6つの問いはそのための道具であり、COBOL移行に限らず、エージェント型AIが絡むあらゆるパイプラインに適用できる。名前をつけることが、改善の出発点になる——これが記事全体を貫くメッセージだ。
詳細はOnly believe what you can validate: a verification framework for agentic AIを参照していただきたい。
