「AI Agent開発を始めて気づいた。コードを書いている時間より、動作確認に費やす時間のほうがはるかに長い。」
これは私だけの悩みではないはずだ。実際に統計を取ってみると、AI Agent開発における時間配分は驚くべき数字を示した——設計と実装が10%、残りの90%が手動テストである。
もっと正確に言えば、「手動テスト」という言葉すら生易しい。実際には、ブラウザを開き、テストしたいデータセットを入力し、Agentの挙動をステップごとに目視し、その結果が「良くなったのか、悪くなったのか」を人間の勘で判断する——この繰り返しだ。
しかも、問題はそれだけではない。AI Agentというシステムは本質的に非決定性である。プロンプトを一文変えただけで、全体が崩壊することもある。そして最悪なのは、その崩壊が一目では分からないことだ。「壊れたのか、壊れていないのか」を確認するために、また同じテストを繰り返す。
いつの間にか、仕事は「コードを書くこと」ではなく、「自分でも理解しきれなくなったシステムを延々と手動で検証すること」に変わっていた。これは正常な状態なのか？
この90%を、自動化できないのか？
Verifier’s Rule——「検証の非対称性」が示す出口
この問いに向き合う前に、まず確認しておきたいことがある。これは果たして「自分だけの問題」なのか？
答えはノーだ。2025年、OpenAIとMetaの研究者であるJason Weiは、ある重要な概念を提示した。「検証の非対称性（Asymmetry of Verification）」——多くのタスクは「実行するのは難しいが、正しいかどうかの検証は容易である」という性質を持つ。
そして彼はここから一つの法則を導いた。Verifier’s Rule——
「可解で、かつ容易に検証可能なあらゆるタスクは、最終的にAIによって解決される。」
この法則と、私の「90%が手動テスト」という現実は、じつは同じコインの裏表だった。
私が90%の時間を検証に費やしているのは、まさに「生成は安くなったが、検証はまだ高価」だからだ。つまり、AI Agentにとって「生成」と「検証」のコストが非対称なのである。
だとすれば、解法は明確だ。「このAgentが正しく動いているか」を判断するプロセスを、人間の目と勘に頼る「難しくて高価な検証」から、コードで自動実行できる「容易で再現可能な検証」へと変換する。 検証が容易になった瞬間、Verifier’s Ruleに従って、その検証自体もAIに任せられるようになる。
そして、私の役割は「コードを書く人」から「検証可能なアーキテクチャを設計する人」へと変わる。
半導体業界が30年前に解いていた問題
この話は抽象的に聞こえるかもしれない。しかし、別の業界では30年前に同じ問題が解決されている。
その業界とは——半導体の設計と検証。私が現在身を置いている世界でもある。
まず、ひとつ冷知識を共有しよう。チップのRTLコードを書くエンジニアより、それを検証するエンジニアの数のほうが多い。 チップが実際に製造（テープアウト）される前、検証に投入される人的リソースは、設計の2倍から3倍に及ぶことが珍しくない。
なぜか？ 答えは単純だ。チップは一度製造すると、バグがあっても「再デプロイ」が効かない。ミス1つで数百万ドルが蒸発する。 だから業界全体が、現実に追い込まれる形で、リソースの大部分を「あらゆるバグを事前に炙り出す仕組み」に投入してきた。
この仕組みの中核にあるのは、「Verilogが書けること」ではない。そうではなく——
- リグレッションテストをどう設計するか
- どの地点にアサーション（チェックポイント）を埋め込むか
- テストカバレッジをどう測定し、どこまで十分と判断するか
つまり、「検証の体系を設計する能力」 が本質的価値なのである。
ここまで読めば、おそらく気づいただろう。これは今、我々がAI Agent開発で直面している問題とまったく同じ構造だ。
AIがコードを書くコストを激減させた——それは、かつてEDAツールがVerilog記述を容易にしたのと同じパラダイムシフトだ。そして、その変化の先に現れる新たな価値は「設計」ではなく、「その設計の正しさをどう検証するか」 にある。
実践：AI Agentのための検証アーキテクチャ
では、具体的にどうやって我々のAI Agentに検証基盤を組み込んだのか。
ステップ0：Agentを「Agentにとって扱いやすい」システムに変える
最初の一歩は、テストを書くことではない。我々のAI Agentそのものを、別のAI Agentから操作・観察可能なシステムに改造することだ。
私の手元には2つのシステムがある。
- 開発対象のAI Agent（テストしたい対象）
- Codingツール（Codex等）（開発に使うAI）
これまでテストが苦痛だった理由は明白だ。開発対象のAI Agentの入り口が「Web UI」だったからだ。テストするには人間が画面をクリックし、データを入力し、出力を目視するしかない。そのシステムは最初から「人間の目と手」のために設計されていたのである。
「AI Agent指向の開発」という言葉の本質は、次の3つの問いに集約される。
- あなたのシステムは、人間の目とUIから切り離された状態でも動作するか？
- 実行中の中間状態は、別のAI Agentが理解できるだけの情報を残しているか？
- AIが自律的にそれらの情報を取得できるよう、専用のインターフェースが設計されているか？
たとえば、AI Agentの実行中に「ワークフロー全体の流れ」「どのツールが呼び出されたか」「各ステップでどんなデータを取得したか」——これらがUIから離れた瞬間に消えてしまう、あるいはUIなしではワークフローが停止してしまうとしたら、それはインターフェースが依然として人間向けであり、AI向けではない証拠だ。
MCPか、それとも分離か？
ここには2つの道がある。
道A：MCP（Model Context Protocol）でWeb操作を模倣する。 AI Agentにブラウザを操作させ、マルチモーダルな観察でUIを読ませるアプローチ。
道B：フロントエンドとバックエンドを完全に分離する。 バックエンドを独立して動作するAI Agentにし、すべての操作をCLIベースで実行可能にする。フロントエンドはバックエンドの状態を人間向けに監視・表示するだけの薄い層に退く。
私が選んだのは道Bだ。理由はシンプルで、認証周りやコーナーケース、実行効率の面で、MCP経由の画面操作より直接的な分離のほうが圧倒的に速く、かつ堅牢だったからだ。
正直なところ、この分離にはかなりの工数を要した。我々はVercelのAI SDKをヘビーに使っていたのだが、これは確かに開発初期の立ち上がりは極めて速い。しかし、フロントエンドとバックエンドを綺麗に引き剥がす段になると、それなりの設計変更が必要になる。
結果として、バックエンドはフロントエンドから独立し、長時間安定して自律動作するシステムへと変わった。
ACI（Agent Computer Interface）——AI Agentは「新しい種類のユーザー」である
この方向性は、我々だけの直感ではない。PrincetonのSWE-Agent論文で提唱された**ACI（Agent Computer Interface）**という概念が、まさにこれを理論化している。
彼らの主張は明確だ——
AI Agentは、人間とは異なる「まったく新しい種類のユーザー」である。だからこそ、専用のインターフェースを設計しなければならない。
そして実験結果が示したのは、インターフェース設計の良し悪しが、より強力なモデルに切り替える以上のパフォーマンス差を生むという事実だ。
毎日のように耳にする「AI Agent指向のプログラミング」「AI Agent指向のサービス」——これらの本質は特定の技術スタックではない。あなたが作るものが、別のAI——あるいはより端的に言えばCodex——によって、必要な情報を素早く自律的に取得できるかどうか。これがすべてだ。
ステップ1：二層の「審判」を設計する
下準備が整ったら、いよいよテストの構築に入る。本質的にはリグレッションテストである。概念自体は難しくない。難しいのは、非決定性システムをどうテストするかだ。
たとえば、AI Agentに新しいツールを追加する場面を考えよう。開発者としての期待は明確だ——「この条件でこのツールが発動し、その後のワークフローがこう進む」。この期待する経路を我々は**ハッピーパス（Happy Path）**と呼び、それが新機能の受け入れ基準となる。
ここで最初に直面する難題が「誰が審判をするのか」である。AI Agentの出力は自然言語の塊であり、実行パスであり、単純な差分比較ができる数値ではない。従来のPass/Fail二分法では対応できない。
私の解法は、審判を二層に分けることだ。確定的な判断は確定性の審判に、曖昧な判断はAI審判に委ねる。
第一層：確定的アサーション（Assertion）
これはハードなチェックの集合である。たとえば——
- テスト実行中に、期待したツールが実際に呼び出されたか？
- 特定のステップ到達時に、中間状態には何件のレコードが存在するか？
- どのような条件分岐がカバーされたか？
この層の特徴は3つ——絶対的信頼性、決定性、そしてゼロコスト。LLMを呼ぶ必要はなく、コードで機械的に検証できる。
第二層：LLMスーパーバイザー（Supervisor）
第一層で捕捉しきれない「曖昧な部分」を扱うのが、LLMによる審判——私はこれをSupervisorと呼んでいる——の役割だ。
このSupervisorの設計には、いくつか決定的に重要なポイントがある。
第一に、Supervisorのコンテキストは完全にクリーンでなければならない。 開発には一切関与させない。コードの来歴も、設計の意図も知らない状態を保つ。その「目」に映るのは、「正しい状態とは何か」という期待値だけである。
第二に、正解のない出力に対して「善し悪し」の二値判断をさせない。 代わりに定量的なスコアリングを行わせる。「この出力は100点満点中78点」——スコアという形で差分を可視化することで、「どれだけ良くなったか」「どれだけ悪化したか」が測定可能になる。
半導体検証の経験がある人なら、この二層構造には見覚えがあるだろう。Assertion、Coverage、Scoreboard——これらはまさにハードウェア検証の標準手法だ。AI Agentは当然ながらハードウェアより曖昧で不確実性が高いが、その分、むしろ不確実性に対する許容度を高く設計することがポイントになる。
ステップ2：テストケースを「貯める」
審判を用意したら、次は事例を蓄積するフェーズに入る。
上述のハッピーパスは、新機能を開発するたびに1つずつ固まっていく。機能が増えれば増えるほど、ハッピーパスの網羅性は自然に高まる。
しかし、それだけでは不十分だ。自分たちが設計していない入力——実ユーザーやテスト実行から採取した、想定外の五花八門なデータ——を積極的にテストスイートに取り込む必要がある。
これら2種類のリグレッションテストによって——
- システムが継続的に変更されても、後退していないこと
- テストの死角が最小化されていること
——この2つを同時に担保できる。
ステップ3：フィーチャーフラグで「差分」を可視化する
もう1つ、私が特に重要視しているプラクティスがある。新機能には必ずフィーチャーフラグ（ON/OFFスイッチ）を付与することだ。
スイッチがあることで、「ONのバージョン」と「OFFのバージョン」という2つの状態が生まれる。これを同一のリグレッションテストで走らせることにより——
- 新機能が何をもたらしたか（どの指標が改善したか）
- 新機能が何を静かに壊したか（どの指標が悪化したか）
この2つが、スコアの差分としてはっきりと浮かび上がる。これがなければ、「良くなった気がする」という印象論から永遠に抜け出せない。
閉ループ——「コードを書く」から「正しさを定義する」へ
ここまでのアーキテクチャが整った時点で、最もエレガントな一歩が可能になる。すべてを閉ループにすることだ。
CodexのようなCoding Agentに、以下のフローを組み込む——
- まずリグレッションテストを設計する（期待する振る舞いを定義）
- 次にフィーチャーフラグを設計する（新旧比較の土台を作る）
- コードを実装する
- フラグON/OFFの両方でリグレッションテストを実行する
- テスト結果をフィードバックとしてコードを修正する
- テストをパスするまで3〜5を繰り返す
このループの中に、人間の判断は介在しない。Codexが検証可能な体系を通じて、設計→実装→検証→修正を自律的に収束させていく。
そしてこの時点で、我々の仕事は「コードを書くこと」でも「手動でテストすること」でもなくなっている。我々がしているのは、「何をもって正しいとするか」を定義することだけだ。 残りは、この閉ループが自動的に収束させる。
これはまさに、冒頭のVerifier’s Ruleが予言した通りだ——「検証可能にできた瞬間、その先はAIがやる。」
90%を占めていた手動テストは、ここで本当に自動化される。
「この通りにやれ」ではなく「自分の90%を探せ」
ここまで紹介したフロントエンド／バックエンド分離、二層評価、リグレッションテスト、フィーチャーフラグ——これらは結局のところ「一つの例」に過ぎない。
私が本当に伝えたいのは、これらの具体的技法そのものではない。伝えたいのは、なぜ我々がこうした技術的決断を下したのか、その理由と思考の筋道だ。
正直に言えば、フロントエンドとバックエンドの分離も、リグレッションテストも、それ自体は多くの技術ブログに書かれている一般的なプラクティスだ。にもかかわらず、なぜ今日、改めてこれを語るのか？
それは、「なぜ」の部分こそが重要だからだ。
もしあの「90%の浪費」が私を崖っぷちに追い込んでいなければ、私はおそらく、これらの技術的決断を真剣に検討しなかったと思う。効率の悪さに徹底的に苦しめられたからこそ、そこから抜け出すための構造的な答えを探さざるを得なかった。
だからこそ、この記事を読んだあなたに考えてほしいのは——
- あなたのプロジェクトに、同じようなボトルネックはないか？
- あなたの時間を静かに食い潰している、繰り返しの作業はないか？
- それがあるとしたら、それは「仕方ない」で済ませていいものか？
もし見つかったなら、あなた自身の方法で解けばいい。私の解法は、あくまで一つのヒントに過ぎない。
「AIでコードを書くか」は、もはや問いではない
1年前、開発者たちは議論していた——「AIでコードを書くべきか？」
2026年の今日、この問いはすでに終わっている。誰もがAIを使っている。
だとすれば、これからの問いは別の次元に移る——
「あなたは、どうやってAIを使えば、他の誰よりも高い効率を得られるのか？」
10分でできた作業にAIを使って2時間かけて、同じ結果しか出せなかったのなら、そこに効率化はない。むしろ本末転倒だ。AIを使ったせいで効率が下がった——これは効率化ではない。
だからこそ、解法は自分で見つけるしかない。
私の話が、あなた自身のプロジェクトを見つめ直すきっかけになり、そこに潜む「90%のムダ」に気づくトリガーになったなら——そして、その解決のヒントがあなたの頭の中に何か新しい発想を生んだなら——それ以上に嬉しいことはない。
あなたの「90%」を、取り戻してほしい。
ネオアナログラボでは、AI Agentの開発効率化、検証アーキテクチャの設計、自律的な開発ワークフローの構築まで一貫して支援しています。AI Agent開発における「手動テストの壁」に直面されている方は、ぜひご相談ください。