「精度は何パーセント出ますか」。この春、ある部品メーカーの情報システム部門から回ってきた検討メモは、この一行で終わっていました。私はこの質問に、数字では答えないことにしています。守るべきは出力の正しさではなく業務のほうで、誤りが発注や在庫に届くかどうかを決めるのは精度ではなく設計だからです。

答えられないから避けているのではありません。答えても判断の役に立たないからです。読ませる帳票の様式が一つ変われば取り違えは増え、同じモデルを使っていても数字のほうが動きます。

一件の誤りが致命傷になる工程があり、百件の誤りが誤差で収まる工程もある。設計を預かる立場から見て、精度の数字はこの差について何も教えてくれません。手がかりになるのは、誤りが請求や出荷まで届く経路のほうです。

AI ハルシネーション 対策を精度の問題にすると、なぜ業務を守れないのか？

誤りが確率的に残ることが、生成AIの作り方そのものに由来するからです。精度の改善は誤りの頻度を下げますが、頻度がゼロになる前提で業務を組むことはできません。

米国立標準技術研究所（NIST）は生成AI向けのリスク文書「NIST AI 600-1」で、この現象を、一般に「ハルシネーション」とも呼ばれるconfabulationとして扱い、生成モデルの設計から自然に生じる結果だと位置づけています。モデルは学習データの統計的な分布を近似して次の語を予測する仕組みで、その予測は事実として正確な出力も、事実に反する出力も同じ手続きから生みます。仕組みの副作用ではなく、仕組みそのものの性質だという整理です。

厄介なのは、誤りが自信のある口調で提示される点でしょう。同文書は、システムが答えを正当化するかのような論理や出典まで一緒に作り出すことがあり、それが人に不相応な信頼を抱かせると指摘しています。根拠らしきものが添えられているぶん、読む側は疑う手がかりを失います。

そして誤りの重さは、AIが業務のどこまで踏み込んでいるかで変わります。私たちは自社の立ち位置を「ChatGPTは答えます。WindyFloは働きます。」という一文で示していますが、働く側に回った瞬間、誤りの後始末は訂正ではなく復旧に変わります。

答える段階なら、誤った回答は読んだ人が捨てれば終わりです。実行する段階では、誤った数量が発注データに書き込まれ、取引先へ注文書が飛び、在庫が引き当てられます。

同じ一件の誤りでも、消える誤りと残る誤りがある。

だから設計の焦点は、誤りを減らす努力の手前に置くべきものがある、というところに移ります。誤りが業務に到達する経路のどこかに、止める場所を作っておく。この発想に切り替えると、検討すべき項目は「どのモデルか」ではなく「どこで止め、何を記録し、どう戻すか」の三つに整理されます。

どの処理に人の確認を挟み、どれを自動で流してよいのか？

判断の物差しは三つです。影響の大きさ、届く相手、そして取り消せるかどうか。この三つが重なる処理にだけ人を残し、それ以外は自動で流します。

判断軸	自動で流してよい側	人の確認を挟む側
影響の大きさ	社内向けの集計・分類・下書き	金額や数量が確定する処理
届く相手	自社内で完結する更新	取引先・顧客へ届く発注書・請求・通知
可逆性	訂正で打ち消せる更新	出荷指示・入金消込など取り消しに人手が要る処理
件数と頻度	日に数百件の定型処理	月に数件の非定型・例外
根拠の一意性	参照先が一つに定まる	複数の資料を突き合わせて解釈が要る

表の右側を全部人に回すのではありません。三軸のうちいくつに触れるかで濃淡をつけます。三つとも右側なら承認を必須にし、一つだけなら閾値を設けて超えた件だけを回す。どれも左側なら記録だけ残して流します。

具体的な線引きは、業務ごとの数字に落とす作業になります。発注なら「一件あたり五十万円まで」「新規取引先は金額を問わず承認」、在庫の書き戻しなら「前日残との差が二割を超えたら保留」といった形です。数字の根拠は自社の決裁規程にあるはずで、そこを流用すれば議論は短く済みます。

見落とされやすいのが、件数と頻度の軸でしょう。月に数件しか起きない例外処理は、自動化の効果が小さいわりに誤りの影響が読みにくい。ここを無理に含めると、確認の設計だけが複雑になって全体が止まります。例外は最初から人の担当として残し、機械には定型の大量処理を渡す。

この配分が、導入初期の歩留まりを静かに決めます。

判断軸を先に決めておく利点は、業務が増えたときに議論を繰り返さずに済むことです。新しい工程を自動化したくなったら、三軸に当てて右側にいくつ触れるかを数えるだけで、確認の要否がその場で決まります。

AIエージェント 誤作動を止めるゲートは、どこに置けば業務が詰まらないのか？

外部に届く直前の一点に寄せ、全件ではなく条件に触れた件だけを回すことです。工程の途中に細かく確認を挟むほど、業務は詰まり、確認そのものが形だけになります。

全件確認が効かない理由は、人の性質のほうにあります。NIST AI 600-1は、人がAIの出力に過度に依存し、他の情報源より質が高いと根拠なく感じてしまう傾向を自動化バイアスとして挙げ、それがハルシネーションの危険を増幅すると整理しています。三百件のうち二百九十九件が正しい画面を毎日見せられれば、三百件目も正しく見えてくる。全件を人に見せる設計は、実質的に誰も見ていない状態を作りかねません。

そこで、回す件を絞ります。閾値を超えた金額、初めて登場する取引先、AIが参照元を見つけられなかった件、前月実績から外れた数量。この四種類だけを確認待ちに落とせば、担当者が一日に見る件数は現実的な水準に収まります。残りは記録だけ残して通す設計です。

確認者に何を見せるかも、設計項目のひとつです。AIの出力だけを提示されても、正しいかどうかは判断できません。元になった帳票の該当箇所、参照したマスタの行、AIが選んだ結果を横に並べて、突き合わせるだけで済む画面にする。判断ではなく照合の作業に変えると、一件あたりの所要時間は目に見えて縮みます。

もう一つ、確認待ちが滞留したときの逃げ道を先に決めておきます。承認者が出張で三日不在なら、その間の発注は止まったままになる。一定時間で自動的に保留へ落とす、代理承認者へ回す、期限を過ぎたら通知を上げる。この三つのうちどれを採るかは業務の性質次第ですが、決めていない状態が一番危ない。

確認を誰が担うかという問題も、ゲートの置き場所と一緒に決まります。情報システム部門が引き取るのか、業務チームが自分たちで持つのか。この役割分担については、非エンジニアがAIエージェントを運用する体制の作り方で、権限と例外処理の持ち方から整理しました。

何を記録しておけば、あとから誤りの出どころを追えるのか？

出力だけを残しても再現はできません。入力・根拠・判断・操作者、そして時刻と版。この五つが揃って初めて、誤りがどこで生まれたかを切り分けられます。

記録する項目	具体的に残す内容	これがないと分からないこと
入力	渡した帳票・指示文・参照した期間	誤りが入力側の欠落か出力側の取り違えか
根拠	参照したレコードID・文書の版	古い単価表を見ていなかったかどうか
判断	AIが選んだ結果と、採らなかった候補	迷った末の誤りか、最初から見えていなかったのか
操作者	確認者・承認者・実行した主体（人か機械か）	誰の判断でこの処理が通ったのか
時刻と版	実行時刻・使用したモデルと業務フローの版	更新の前後で挙動が変わったかどうか

このうち実務で抜けやすいのが「判断」の欄です。AIが候補を三つ挙げて一つを選んだのに、選ばれた結果しか残っていない。すると誤りを見つけても、候補に正解が挙がっていたのか、そもそも見えていなかったのかが分からず、直しようがありません。採らなかった候補まで残すと、原因の切り分けが一段速くなります。

人がAIの判断を上書きした事例も、記録の対象です。NIST AI 600-1は、人や別のシステムがAIの判断を覆した場面を監視・文書化し、その事例を評価して、差し戻しが出どころ（来歴）に関わる問題と結びついていないかを確かめるよう促しています。差し戻しの一件一件は、単なる訂正記録ではなく、次にどの条件を閾値に加えるべきかを教えてくれる材料になります。

記録は「残っている」だけでは足りません。誤りが疑われたときに、担当者が数分で該当する一件までたどり着けること。伝票番号や取引先名から引ける索引がなければ、ログはあっても実質的には無いのと変わりません。保管期間と検索の入り口を、設計の段階で決めておきます。

なお、同じ監査ログでも追う対象は一つではありません。この記事で扱っているのは「何が間違えたか」を追う記録で、個人情報や機密データが社外のどこへ渡ったかを追う記録は別の設計になります。後者については、AI業務自動化で個人情報の持ち出しをどこで止めるかで、データが社外に出る地点の特定から扱いました。

AIの出力に、検証できる参照をどう付けるのか？

出力と一緒に「どこを見てそう判断したか」を返させ、その参照が実在するかを機械が突き合わせる形にします。人が正誤を推測する作業を、機械が照合できる作業へ置き換える発想です。

NIST AI 600-1は、AIの出力に含まれる出典や引用を、導入前のリスク測定と運用中の監視の両方で確認・検証するよう挙げています。これは文章生成の話にとどまりません。業務処理でも同じで、AIが「この取引先の単価は八百円です」と返してきたとき、根拠となるマスタの行番号が添えられていなければ、確かめる術がないのです。

実務では、参照の付け方を三段階で設計します。

1. 値そのものをAIに生成させない — 単価も在庫数も税率も、確定した値は業務システムから取り、AIの仕事は「どのレコードを引くか」を決めるところまでに限る。
2. 引いたレコードの識別子を、出力と一緒に返させる。
3. その識別子が実在し、一件に定まるかを機械が検査する。

該当する行が存在しない、あるいは複数該当して一つに絞れない。この二つは、そのまま確認ゲートへ回す条件になります。AIが「見つからなかった」と正直に言えず、それらしい値を埋めてしまう場面こそが、業務で最も危ない誤りの形だからです。

計算も同じ考え方で扱います。数量と単価の掛け算をAIにさせる必要はありません。項目の対応づけまでをAIに任せ、演算は業務システム側で実行する。こうしておくと、金額の誤りは対応づけの誤りへ限定され、原因の探索範囲がひと桁縮みます。

参照を付ける効果は、確認ゲートの負荷にも及びます。参照が揃っていれば、確認者は出力の内容を吟味するのではなく、参照先と出力が一致しているかだけを見ればよい。前の章で触れた「判断ではなく照合へ」という設計は、この参照の付与があって初めて成り立ちます。

誤った処理は、どの経路で元に戻すのか？

業務ごとに取り消し方を先に決め、取り消せない処理は自動化の対象から外します。戻し方が決まっていない処理を自動で流すのは、事故のときに手が打てない状態を選ぶことと同じです。

戻しやすさは三つに分かれます。そのまま消せるもの、訂正で打ち消せるもの、取り消せないもの。社内向けの下書きやメモは一つ目、伝票や在庫の書き戻しは二つ目、発注の確定・出荷指示・社外への通知・入金処理は三つ目に入ります。

三つ目に該当する処理は、承認を必須にするか、そもそも機械に渡さないかの二択です。ここを曖昧にしたまま「あとで直せばいい」と進めると、取引先への謝罪と手作業の突き合わせが待っています。

自動化の範囲を欲張らない判断が、結果として導入速度を上げる。

復旧の手順も、文章にしておく価値があります。誰が異常に気づき、誰へ連絡し、どの順で戻し、いつ再開するか。NIST AI 600-1は、意図した用途と異なる挙動を示したAIシステムを停止・切り離す仕組みと責任の所在を定め、停止に値する基準を定期的に見直すよう求めています。停止の基準を運用開始後に決めようとすると、いざというとき誰も引き金を引けません。

停止の権限を誰が持つかも、あわせて決めておきます。業務チームが自分の判断で止められる状態と、ベンダーへ連絡してから半日待つ状態では、被害の広がり方がまるで違う。管理画面から該当のフローだけを止められること、止めても他の処理が巻き添えにならないこと。この二点は、選定時の確認項目に入れて構いません。

戻し経路の設計は、導入が途中で頓挫する要因とも重なります。自動化が失敗する典型的な原因については、AI導入が失敗する7つの原因と非開発組織の対策で、体制と設計の両面から整理しました。

国のガイドラインは、人の関与と記録に何を求めているのか？

総務省と経済産業省の「AI事業者ガイドライン」は、AIに単独で判断させないことと、追跡できる記録を残すことを、指針として並べています。直近では2026年3月31日に第1.2版が公表されました。

人の関与について、同ガイドラインは公平性の項で「AIの出力結果が公平性を欠くことがないよう、AIに単独で判断させるだけでなく、適切なタイミングで人間の判断を介在させる利用を検討」することを挙げています。文言で注目したいのは「適切なタイミング」という部分でしょう。どこが適切かを国は定めていません。決めるのは業務側で、その決め方が本稿で扱ってきた三つの判断軸にあたります。

記録については、アカウンタビリティの項がより具体的です。トレーサビリティの確保に加え、「関係する情報を文書化して一定期間保管し、必要なときに、必要なところで、入手可能かつ利用に適した形で参照可能な状態とする」ことが挙げられています。保管するだけでなく、必要なときに引ける形であること。前章で索引の話をしたのは、この要請と重なります。

透明性の項では、AIシステム・サービスの検証可能性を確保しながらステークホルダーへ情報を提供することが挙がっています。AI開発者向けの事項では、出力の品質が運用開始後に大きく変動したり想定した精度に達しなかったりする特性を踏まえ、事後検証のための作業記録を保存することが示されました。誤りうる前提で記録を残すという考え方が、国の指針にも書き込まれているわけです。

AIを使う側の事項も見ておきます。同ガイドラインはAI利用者に対し、「AIの出力について精度及びリスクの程度を理解し、様々なリスク要因を確認した上で利用する」ことを挙げています。導入した企業が「ベンダーの製品が誤った」で終われる構図にはなっていない、と読むのが実務的でしょう。

このガイドラインは罰則を伴う規制ではなく、リスクの大きさに対策の程度を対応させるリスクベースアプローチのもとで、事業者の自主的な取組を支援する位置づけです。義務がないぶん、どこに人を置き、何を残したかを自分の言葉で説明できる状態を作る責任は、導入する側に残ります。設計の記録がそのまま説明の材料になる、と考えておくとよいでしょう。

PoCの段階で、この設計をどこまで確かめておくのか？

本番の要件をすべて盛り込む必要はありませんが、確認ゲート・記録・戻し経路の三つだけは、小さくても実際に動かして確かめます。この三つは後付けが最も難しい部分だからです。

対象は一工程、実行は一種類に絞ります。請求書の読み取りなら読み取りだけ、発注なら一つの取引先だけ。範囲を欲張った検証は、うまくいかなかったときに原因の切り分けができず、判断材料が残りません。

確かめ方で私が勧めているのは、わざと誤らせることです。桁を一つ変えた請求書、廃番になった品番、存在しない取引先名。こうした検体を混ぜて流し、ゲートで止まるか、記録から出どころを何分でたどれるか、戻し手順が実際に回るかを見る。正常な書類だけで通した検証は、止まる仕組みを一度も動かしていないのと同じです。

合格条件も、あらかじめ言葉にしておきます。「誤りがゼロだったこと」を条件に置くと、検証は失敗するか、条件を緩めて通すかのどちらかに落ち着きます。置くべきは「誤りが業務に届かなかったこと」、そして「届いた場合に何分で気づき、何分で戻せたか」。この二つなら、次の工程へ広げるかどうかを数字で判断できます。

WindyFloは実行のレイヤーを担う立場ですが、設計の前提として重視しているのはこの三点です。承認を挟む位置を業務側で決められること、実行の一つひとつに記録が残ること、そして止める操作を日本語の管理画面から業務チーム自身が行えること。実行できることと、実行を任せてよいことは、最後まで別の問題です。

冒頭のメモに戻ります。「精度は何パーセント出ますか」への私の答えは、いつも同じです。その数字より先に、誤りが発注に届く前に止まるかどうかを、一緒に確かめましょう。自社の一工程でその確認を試したい段階であれば、WindyFloのPoC相談から、対象工程の選び方の相談として始められます。

よくある質問

出典

• ［1次］総務省・経済産業省「AI事業者ガイドライン（第1.2版）概要」（令和8年3月31日公表）— 共通の指針における公平性（AIに単独で判断させるだけでなく、適切なタイミングで人間の判断を介在させる利用の検討）、透明性（検証可能性の確保）、アカウンタビリティ（トレーサビリティの確保、関係する情報を文書化して一定期間保管し参照可能な状態とすること）、AI開発者に関する事項の検証可能性の確保（事後検証のための作業記録の保存）、AI利用者に関する事項（AIの出力について精度及びリスクの程度を理解し、様々なリスク要因を確認した上で利用する）、およびリスクベースアプローチによる自主的取組の支援という位置づけの根拠: https://www.meti.go.jp/shingikai/mono_info_service/ai_shakai_jisso/pdf/20260331_2.pdf
• ［1次］米国立標準技術研究所（NIST）「Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile」（NIST AI 600-1、2024年7月公表）— confabulation の定義と生成モデルの設計に由来する現象であること（2.2）、出力に付随する論理・出典が人の過信を招くこと（2.2）、自動化バイアス（2.7）、出力に含まれる出典・引用の検証（MS-2.5-003）、人や他システムがAIの判断を覆した事例の監視・文書化と評価（MS-4.2-004）、意図した用途と異なる挙動を示すシステムの停止・切り離しの仕組みと基準の定期見直し（MANAGE 2.4）の根拠: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf
• 本稿の判断軸・確認ゲートの置き方・記録項目・戻し経路に関する記述は、ハマダラボ（HAMADA LABS Japan）による導入支援の一次観察にもとづく設計方針であり、特定企業の実在事例ではありません。