先に結論
企業の現場で AI Agent を使うとき、一番ネックになるのはハルシネーションです。今の主流は Human-in-the-Loop、つまり最後は人間が見るやり方ですが、これをやっている限り 100% の自動化にはなりません。
そこで最近ずっと考えているのがこれです。
人間の判断を、事前に書いた「検証プログラム」で置き換えられないか?
結論から言うと、かなり筋が良さそうです。学術的にも Neurosymbolic Agent という形で研究が進んでいて、業界でも同じ方向に動き始めています。
なぜ AI Agent に Human-in-the-Loop が必要なのか
AI Agent を本番に入れようとすると、自信満々に返した回答の中身が間違っていたり、ツール呼び出しのパラメータを捏造したり、業務ルールを「知っている風」に無視したり、という場面にぶつかります。
これは Agent のバグというより、LLM が確率的(非決定的)なシステム だから起きます。プロンプトをどれだけ磨いてもゼロにはなりません。だから企業導入では、今でもほぼ必ず Human-in-the-Loop が入ります。
でも、人間を最終チェッカーに置いている限り、それはもう「自動化」じゃなくて「補助」です。
「100% 自動化」と「100% 正確」のトレードオフ
業務自動化で現場が欲しいのは、速さ(自動化)と、間違えないこと(正確性)です。AI Agent は前者は得意ですが、後者は苦手。だから人間を挟む。すると前者が犠牲になる。
| アプローチ | 自動化率 | 正確性 |
|---|---|---|
| AI Agent 単体 | 100% | 80〜95% |
| AI Agent + Human-in-the-Loop | 60〜80% | 99% 以上 |
| AI Agent + 検証プログラム | 100% | 99% 以上 |
一番下の行が成立するなら、話はかなり変わります。
発想: 人間の判断を、決定論的なプログラムに置き換える
ここで整理したい問いはこれです。
人間がチェックしているのは「何」なのか?
業務を観察してみると、人間がやっているチェックの多くは意外と機械的です。金額の合計が合っているか、必須項目が埋まっているか、上限金額や承認経路のルールを違反していないか、出力の型が正しいか。これらは全部、事前にルールを書けるタイプのチェックで、LLM より決定論的なプログラムに任せた方が速くて確実で、疲れません。
CIO マガジンの記事にこういう一節がありました。
LLM の出力はまず Control Plane(制御面)に入る。そこには、ハードコードされた決定論的なロジックゲートが並んでいる。Control Plane は LLM の推論がどれだけ創造的だったかは気にしない。気にするのは、アクションのパラメータが業務ルールに合っているかだけだ。(CIO)
「AI を賢くする」のではなく、「AI の周りに檻を作る」という発想の転換です。つまり、Human-in-the-Loop から Program-in-the-Loop へ、ということです。
思考実験1: 開発業務 (テスト駆動 × AI Coding)
最初の具体例は「プログラム開発」です。
AI にコードを書かせるのが普通になった今でも、そのコードを 100% 信用するのはまだ無理です。ここで従来のソフトウェアエンジニアリングからヒントが取れます。
- 先にテストコードを書く(ここだけ人間がレビューして正しさを担保する)
- そのテストを使って、AI が書いた本番コードを検証する
- テストが全部通るまで、AI に修正させる
- 通ったら、人間のレビューなしで採用
ポイントは、人間が検証するのは「テストコード」だけ で、本番コードは一行も見なくていい、という割り切り方です。テストコードは業務ルールの集合体なので、金額計算・エッジケース・例外系を書き切れていれば「テストが通る = 正しい」と言えます。
学術的にも裏付けがあります。SymCode という論文では、LLM に Python コードを生成させ、インタプリタでの実行結果を Pass/Fail のシグナル にすることで LLM を Neurosymbolic Reasoner に変えるアプローチが提案されています(arXiv:2510.25975)。
思考実験2: 帳票登録業務
次は、日本企業で山ほどある「帳票登録(伝票入力)」業務です。
この業務を AI Agent に全部任せるのは、正直怖いです。OCR + LLM だと、金額の桁を間違えたり、品目を誤認識したりするからです。
ここで、人間の役割を最小限まで削ぎ落とします。
- 人間は 合計金額だけ を入力する
- AI Agent が明細を OCR + 構造化抽出する
- 検証プログラムが、明細の合計 = 人間が入れた合計 を確認する
- 一致すれば自動で DB 登録、不一致ならそこだけ人間に戻す
「合計の突合」は、Excel で SUM 関数を書くくらい簡単な決定論的ロジックです。でも、これを挟むだけで AI Agent の幻覚がほぼ確実に検出できます。
押さえたいのは、人間の負荷が「合計を 1 つ入力する」だけになっている点です。
「人間が判断する」から「人間が種を 1 粒蒔くだけで、あとはプログラムが検算する」に変わっています。
これは会計の 複式簿記 × 試算表 の発想そのものです。借方と貸方が別ルートで積み上がって、最後に一致しなければどこかが間違っている。AI 時代にこの発想を持ち込むと、ハルシネーション検出の仕組みになる ということです。
Program-in-the-Loop を設計するときの 4 原則
これらのパターンに共通する設計原則を 4 つに整理しておきます。
1. 人間が担保するものを、極端に絞る
本質は、人間がやる作業の量ではなく、「人間が担保する情報の次元」を絞ることです。
- 明細を全部目視レビューしてもらう、ではなく、合計値だけ入力してもらう
- AI が書いたコードを全部レビューしてもらう、ではなく、テスト仕様だけレビューしてもらう
人間が入れるのは「ブレの少ない 1 個の真実」にして、あとはプログラムに任せる。
2. 検算には「AI が通っていないルートの正解」を使う
検算プログラムが機能するかは、「正解」をどこから持ってくるかで決まります。AI 自身の出力を AI 自身にもう一度見せても、同じバイアスで同じように間違えるだけです。
帳票登録でたとえるとこうなります。
ダメな検算は、AI が明細も合計も両方 OCR で読んで突き合わせるパターン。これだと AI が両方同じように間違えたら、検算はすり抜けます。
効く検算は、人間が合計だけを別入力し(または明細とは別のページ/別システムから合計を取ってきて)、AI は明細だけを OCR して、両者を突き合わせるパターン。合計と明細の情報源が分かれている ので、片方が間違っていれば必ず落ちます。
コード生成なら、AI が書いた本番コードを AI 自身にレビューさせるのではなく、独立に書いたテストコードで検証する。これも同じ発想です。
検算の価値の 9 割は、「別ルートから来た正解」を用意できるかどうか で決まります。
3. 合格条件は決定論的に書く
「だいたい合ってたら OK」ではなく、== や不等式、スキーマ、チェックデジットのような、機械が白黒つけられる条件で書きます。LLM-as-a-Judge で曖昧に評価する方法もありますが、それ自体が再びハルシネーションの発生源になりうるので、高リスク業務ほど決定論的な検算を上位に置くべきです。
4. 不合格時は止めるか HITL に戻す
検算が落ちたケースまで自動化する必要はありません。これは HITL をゼロにする設計ではなく、HITL を「例外時のフォールバック」に格下げする 設計です。この発想の転換が、PoC から本番運用への境目になります。
学術・業界での裏付け
自分で思いついたときは不安だったのですが、調べてみるとしっかりした裏付けがありました。
- ATA (Autonomous Trustworthy Agents): LLM は温度を 0 にしてもハルシネーションを根本的に抱えているので、LLM の役割は「自然言語理解とツール選択」に限定し、制約の強制は決定論的なシンボリックルールに任せるべき、という主張(arXiv:2510.16381)
- 業界の実践: Pre/Post-LLM Guardrails、Structured Outputs といったパターンが定石化。AWS の Bedrock Automated Reasoning checks は形式論理で LLM 出力を検証して最大 99% の検証精度を謳っている
要するに、世界の主流も Human-in-the-Loop から Program-in-the-Loop へ という方向に動いています。
ただし、万能ではない
正直に書いておくと、このアプローチには限界もあります。
- 主観的な業務には効かない: 「この提案文書は顧客にとって魅力的か?」のような主観判断はルールに落とせません。ここは人間のレビューが残ります
- そもそもルールが暗黙知: 特に日本の現場では、業務ルールがベテランの頭の中にしかない、ということがよくあります。AI Agent を作る前に、まず業務ルールを明文化するフェーズが必要です。この工程は地味ですが、ルール資産は AI を使わない業務フローにも効くので、実は一番価値が高い工程かもしれません
まとめ
整理するとこうなります。AI Agent の幻覚はプロンプトでもモデルでも完全には潰せないので、企業で使うときは「外側の検証」が必須です。その検証を人間にやらせると 100% の自動化は永遠にできませんが、多くの業務は決定論的なルールで検証できます。なら、人間の代わりに、事前に書いたプログラムに検証させればいい。
開発業務なら「テスト駆動 × AI Coding」、帳票登録なら「合計突合 × OCR Agent」。同じ発想は、契約書レビュー、経費精算、SQL 生成など、幅広い業務に展開できます。
最後に、自分の中で腹落ちした表現を書いておきます。
AI Agent を信頼するのではなく、Agent の出力を検証する「檻」を信頼する。
本番投入するうえで一番工学的に投資すべきなのは、モデルでもプロンプトでもなく、この「檻」の部分ではないかなと思っています。
同じような違和感を持っている方は、ぜひコメントなどで意見交換させてください。