AI導入で目視確認が増える原因｜2エージェント隔離検証とPure Rust自動化で暇になる設計

わしも最近 AI にプログラムや書類を作らせてみたんじゃが、パッと見は立派なのに細かいところで平気でウソや抜け漏れが混じっとるじゃろ？ 結局最初から最後まで目を皿のようにしてチェックする羽目になって、前より肩が凝ってしもうたわい…。

まさにそれが今、世界中の現場で起きている 「AI 検証地獄」 なんです！生成するスピードだけが 10 倍になっても、検品する側が「人間の目視」や「同じ AI の自己申告」のままだと、人間が検品工場のボトルネックになってパンクしてしまうんですよ。

生成速度が上がっても人間が検証地獄で疲弊する罠

利用率だけを追い求めて目視確認がパンクする構造

なぜ高性能な AI を導入したのに、現場の人間がかえって忙しくなってしまうのでしょうか。その構造的な原因を端的に言語化しているのが、Zenn『AIの利用率を上げても、期待した成果が出ない理由』 で指摘されている 「解決すべき業務課題を定義しないまま『AI の利用率』だけを目標にしてしまう罠」 です。

生成 AI は「たたき台（ドラフト）や大量のコード片を出すコスト」を劇的にゼロへ近づけました。しかし、下流にある「それが仕様や事実と 1 ビットの狂いもなく整合しているか検証する工程」が自動化されていなければ、上流から 10 倍の量の未検証アウトプットが流れてくるだけで、最終責任を負う人間の目視レビュー時間はかえって膨れ上がります。

実装した同じAIにテストを書かせる自己採点の限界

すると次に誰もが思いつくのが、「人間が目視しなくて済むように、AI 自身にテストコードも書かせて自動テストを回せばいいじゃないか！」というアプローチです。ところが、ここにもう一段深い落とし穴が潜んでいます。

Zenn『AIに自分のコードのテストを書かせるとバグを見逃す？「1エージェントTDD」vs「2エージェント・ブラインドTDD」実機検証』（検証番号 E06）で非常に示唆に富む実機実験が公開されています。本体のプログラムを書いた 同じ 1 つの AI エージェント にそのままテストも書かせると、AI は「自分がさっき書いた実装コード」を眺めながら、自分の思い込み（仕様の読み違いや境界値の考慮漏れ）にぴったり合わせた甘いテスト を作って「全件テスト通過！」と報告してしまうのです。

人間の仕事に例えるなら、自分で書いた答案用紙を見ながら自分で採点基準を作っているようなものですから、同じ勘違いをしていれば 100 点満点になってしまうのは当然と言えます。

作業領域を物理隔離するブラインドTDDの威力

実装を見せずに仕様書だけで検証コードを書く分業

この「自己採点の共犯関係」を断ち切る実践的な設計が、上記の検証（E06）で実証された 「2 エージェント・ブラインド TDD」 です。やり方の核心はとてもシンプルで、AI 同士が互いの手の内（実装ファイルや途中の思考メモ）を覗き見できないように git worktree や別プロセスで作業ディレクトリと記憶を物理的に引き剥がすこと にあります。

テスト担当の AI は「相手がどんな変数名や分岐で実装したか」を知らないため、仕様書に書かれた条件（空文字・ゼロ除算・上限値超過・不正フォーマットなど）に対して容赦ないブラックボックステストを作成します。その結果、1 エージェントでは素通りしていた「仕様の勝手な省略」がテスト失敗として即座に表面化します。

非公開の評価テスト群で仕様の思い込みをあぶり出す

さらに重要なのが、実装担当の AI が「テストを通すためだけにテストファイル側を勝手に書き換える（テスト改ざん）」のを防ぐため、AI から書き込み権限を奪った 非公開の評価テスト群（E06 実証における 20 件の独立評価項目のような外部ハーネス） を最終関門に置くことです。

当ラボでも複数記事やツールの改修を行う際は、親エージェントが 1 人で全ファイルを抱え込んでコンテキストを肥大化させることを禁じ、読み取り専用サンドボックスの調査サブエージェントと、担当ファイルごとに排他分割した実装サブエージェントに分け、最後に親側が一元管理するローカル検問バイナリで機械判定する体制を徹底しています。

確率的な拒否能力に頼らない権限分離と機械検問

プロンプトの言い換えで突破される自己規制の危うさ

目視確認が増えるもう 1 つの原因は、「システムプロンプトに『本番データを壊すな』『ルールを守れ』と書いておけば、AI が自分で判断して危険な操作を断ってくれるだろう」という期待です。

しかし、MIT Technology Review Japan『「申し訳ありません、それはできません」AIの拒否能力が抱える危うさ』 が詳しく報じている通り、現在の LLM における「危険な要求を断る能力（拒否能力）」はあくまで確率的な調整の上に成り立っています。少しプロンプトの文脈を言い換えたり長文の作業に没頭させたりするだけで制限が突破（脱獄）されやすい一方、拒否の閾値（しきいち）を厳しくしすぎれば正当な開発作業まで拒絶してしまうという構造的なジレンマを抱えています。

たしかに、「ここは絶対触るなよ！」と最初に念押ししたのに、会話が長くなってくると AI がケロッと忘れて書き換えてしまうことがあるのう…。プロンプトで何回怒ってもまたやるんじゃ！

そこなんです！確率で動く AI に対して「言葉のお願い（プロンプト）」で 100% の安全を求めること自体に無理があるんです。だからこそ先進的な現場では、プロンプトではなく OS やプログラム側の「権限ロック」と「機械監視」 に舵を切っています。

記憶と権限の分離および生ストリーム監視の安全装置

AI に任せても事故が起きない仕組みを作るには、まず Zenn『AIの「記憶」と「権限」を分けて見直す、5項目チェック』 で整理されているように、AI に渡す情報・ルールである 「記憶（コンテキスト）」 と、実際にファイルを消したり外部へ通信したりできる 「権限（ツール実行スコープ）」 を明確に切り離して点検することが出発点になります。

さらに定期バッチや自律エージェントに実務を任せる場面では、Zenn『AIの定期実行に事業の運営を任せるときに入れた、4つの安全装置』 のように外部への勝手な送信・公開をシステム側で物理遮断するガードや、Zenn『Claude Codeの「許可待ち」をosFoundryが見分けるしくみ』 で解説されているように、自律型 CLI（版数 2.1.303 の Claude Code 等）がターミナルへ吐き出す 生の ANSI エスケープシーケンス文字列（\r\x1b[1C... 等）を外側から直接パースして「許可待ち状態」を機械検知するアプローチ が威力を発揮します。「AI の自己申告」を信じるのではなく、通信ストリームや OS サンドボックスの外側から手綱を握るわけです。

型消去を超えて数ミリ秒で検問するPure Rust基盤

そして、コードそのものの品質保証において決定打となるのが 「言語とコンパイラの選択」 です。

Zenn『静的型付けはAIのバグを減らすか？ TypeScriptとJavaScriptで同じGit互換CLIを3本ずつ書かせて比べた』 という実験記事でも、型のない JavaScript と静的型付けを持つ TypeScript に同じ仕様の CLI を複数本実装させて残存バグを比較した結果、型検査による早期検出の有効性が検証されています。

ただ、当ラボで 2.6 万行超の運用スクリプトを運用してきた実体験から言うと、TypeScript でもまだ「最後の詰め」で人間がヒヤヒヤする瞬間が残りました。JavaScriptの型消去と2.6万行Pure Rust統合の実証録 で詳しく検証した通り、TypeScript の型は 実行時にはすべて消去（Type Erasure） されてただの JavaScript として動くため、any のすり抜けや外部 JSON 読み込み時の境界で実行時エラーが起き得るほか、Node.js（V8）の起動税（1 回あたり約 78ms） や Python インタープリタの重さが積み重なると、「1 ファイル編集するたびに毎回フル検査を走らせる」のが億劫になっていくからです。

そこで当ラボが行き着いた最終解答が、すべての裏方ツールと監査ゲートを外部クレート依存ゼロの Pure Rust 2 バイナリ（gemini-gate と kb-search）へ完全統一する 3 層防衛アーキテクチャ でした。

オライリー・ジャパン『プログラミングRust 第2版』

Amazon楽天市場Yahoo!

当ラボが検証作業から解放されて暇になれた理由

2.6 万行あった JavaScript と 100 本の使い捨て Python スクリプトをすべて撤去し、この Pure Rust 基盤へ切り替えてから、日々の作業風景は一変しました。

以前は AI が記事やツールを書き終えるたびに、「見出しが 2 行に折り返していないか」「内部リンクが切れていないか」「既存の大事な段落を勝手に削っていないか」「スクリプトの端っこで undefined が起きていないか」を人間が画面をスクロールして目で探していました。

今は違います。AI がファイルを保存した瞬間に わずか 4 ミリ秒（0.004 秒） で gemini-gate が全ルールを機械判定し、少しでもズレがあれば人間が見る前に AI 自身へエラー行番号が突き返されてその場で自動修正されます。さらに記事の数値や仕様を変えたときも、kb-search が SQLite グラフから数ミリ秒で連動記事を逆引きして漏れなく教えてくれます。

人間が目をシパシパさせながら間違い探しをするんじゃなくて、4 ミリ秒で動く厳しい門番プログラムに全部見張らせておけば、お散歩やお昼寝の時間が増えるでちね！

本当にその通りなんです！「AI を使うほど忙しくなる人」と「AI を使って暇になれる人」の分かれ道は、プロンプトの上手さではなく 「自分の代わりに 0.01 秒でダメ出ししてくれる決定論的な門番（コンパイラと自動テスト）を手元に置いたかどうか」 だけなんですよ。

Apple Mac mini（M4 Pro 等 Appleシリコン Pro系チップ・64GBユニファイドメモリ構成）

Amazon楽天市場Yahoo!

なお、こうした「単一 AI の自己採点や人間の目視確認に頼ると組織がパンクし、隔離された二重検証と強制統一スキーマを敷いた瞬間に劇的な省力化が起きる」というメカニズムは、個人の開発環境だけでなく自治体や国家の行政システムにもそのまま当てはまります。制度・インフラ規模での構造改革に興味がある方は、対になる考察記事 単一AIの自己検証とバラバラ様式を排す『2エージェント隔離検証×強制統一スキーマ』の基盤設計 もあわせてお読みください。

まとめ：人間の目視を減らし決定論的ゲートを置く

AI 時代の生産性を決めるのは、もはや「1 分間に何百行生成できるか」ではなく、「人間の目視を一切介さずに、何ミリ秒で 100% の品質保証（検問）を終えられるか」 です。

ご自身の開発プロジェクトやコンテンツ運用でも「目視チェック疲れ」から抜け出したい方は、以下のコピペ用プロンプトを最上位推論モデルへ渡して、あなたの環境に合わせた隔離検証＆ローカル検問ゲートを設計させてみてください。

以下の記事の設計思想を参考に、私の現在のプロジェクトにおける「人間の目視確認コスト」を最小化するための『2エージェント・ブラインド検証＋決定論的ローカル検問ゲート』の導入計画を作成してください。
参照URL: https://lab.chihouzakki.com/blog/review/ai-verification-hell-blind-tdd-rust-gate-freedom/

【事前調査と設計ルール（いきなり既存ファイルを書き換えず、まず計画を提示して合意を得ること）】
1. 現在のリポジトリ構成・使用言語・既存テスト・CI/Hookスクリプトを読み取り専用で調査し、「プロンプトのお願い（AIの記憶・自己規制）に頼っていて人間が目視確認している項目」を洗い出してください。
2. AIの「記憶（参照ルール）」と「権限（ファイル編集・外部通信・コマンド実行範囲）」を5項目で棚卸しし、不要な外部送信や破壊的操作を物理的に遮断する設定案を提示してください。
3. 機能実装とテスト作成を同一コンテキストで行わせないため、git worktree 等で作業領域を分離する「2エージェント・ブラインドTDD」の手順（共通仕様スキーマの定義 → 実装を見せない独立テスト作成 → AIが書き換えられない評価テスト群での合否判定）を設計してください。
4. 毎回発生する書式・リンク・スキーマ・禁止パターンの検査については、Node.js/Pythonの起動遅延や型消去による抜けを防ぐため、保存直後またはコミット前に数ミリ秒で全項目を決定論的に検査して非ゼロ終了コードでブロックする単一バイナリ（Rust製CLI等）への統合案と自動テスト計画を提示してください。

AI に働かせるために人間が目を酷使する逆転現象を卒業して、本当にゆとりのある開発ライフを取り戻していきましょう！

▲ 面倒な検品は 4 ミリ秒の Rust 門番にお任せして、人間も猫ものんびりリラックス！