AI開発発注の失敗図鑑｜ハルシネーション前提の人間確認（HITL）・責任分界を設計しない失敗

生成AIは、事実と異なる内容を、もっともらしい文章で出力することがある。いわゆるハルシネーション（幻覚）である。問題は、間違いが起きること自体ではなく、間違いが起きる前提で確認や承認のフローを設計していないことにある。「AIが出したから正しいだろう」と確認を省くと、誤った情報がそのまま顧客や社外に出て、業務上・法的なリスクにつながる。

本記事では、ハルシネーションを前提にした人間の確認（HITL：Human-in-the-Loop）と、誤った出力が問題を起こしたときの責任分界を設計せずに発注する失敗を、発注者の視点で整理する。AIの精度を上げる技術論ではなく、「間違うことを前提に、誰がどこで確認し、何かあったとき誰が責任を持つか」という運用と契約の論点を扱う。これは、第6回で扱った権限の話や、第10回で扱ったデータの話とは別の軸であり、出力の正しさそのものと、誤出力が出たときの責任を設計する話である。

結論：AIは間違う前提で、確認フローと責任分界を発注範囲に入れる

生成AIの発注で見落とされやすいのは、ハルシネーションをゼロにする設計ではなく、間違いが起きても被害を出さない確認の仕組みである。GXOが設計時に重視するのは、出力の用途ごとのリスク分類、人間が確認する箇所（HITL）、確認の記録、そして誤出力が外に出たときの責任分界である。

• 出力を「下書き用」と「そのまま外に出る」で分け、後者には必ず人の確認を挟む
• 誰が・何を・いつ確認・承認したかの記録を残し、後から追えるようにする
• 誤った出力が問題を起こしたときの責任（AI・運用者・開発会社・利用者）を発注前に整理する
• 「精度100%」を前提にせず、間違いが混じる前提で業務フローを組む

確認と責任を設計しないままAIを業務に組み込むと、便利さより先に、誤情報が外に出たときの被害が大きくなる。確認フローまで含めた設計は、AIエージェント導入の相談やAIエージェント開発の発注の段階で詰めておきたい論点である。

ハルシネーションは「なくす」より「前提にする」

ハルシネーションは完全には消せない

生成AIは、学習した情報から確率的に文章を作る仕組みのため、事実と異なる内容を自信ありげに出力することがある。検索を組み合わせる、社内文書を参照させる（RAG）、確認用のルールを足すといった工夫で頻度は下げられるが、ゼロにはできないと考えるのが現実的である。「精度を上げれば確認は要らなくなる」という前提に立つと、確認フローの設計が抜け落ちる。

間違いが「もっともらしい」から危ない

ハルシネーションの厄介さは、間違いが明らかな誤りに見えないことにある。それらしい数値、存在しない出典、実際とは違う制度の説明が、自然な文章で出てくる。読み手が内容に詳しくないと、誤りに気づけない。だからこそ、出力を使う場面ごとに「誰が、どの観点で確認するか」を決めておく必要がある。

「AIが言ったから」は責任の所在を曖昧にする

誤った出力をそのまま使い、後で問題になったとき、「AIが出したものだから」という説明は通らない。最終的に情報を使い、外に出したのは人や組織である。AIを使ったかどうかにかかわらず、出した内容の責任は出した側にある。この前提を曖昧にしたまま発注すると、トラブル時に社内でも対外的にも説明できなくなる。

HITL（人間の確認）を設計しないと、何が起きるか

確認の仕組みを設計せずにAIを業務に組み込むと、次のような問題が静かに進む。

• 誤った回答や数値が、確認されないまま顧客・社外に出る
• 「AIが出したから正しい」と過信し、人の確認が形骸化する
• 逆に、すべてを人が二重チェックして、AI導入の効率化効果が消える
• 誤りが見つかっても、どこで・誰が確認すべきだったかが決まっておらず、再発する
• 問題が起きたとき、AI・運用者・開発会社・利用者の責任範囲が曖昧で対応が混乱する

過信も過剰チェックも、どちらも「どこで人が確認するか」を設計していないことから起きる。確認を「全部やる」でも「全部省く」でもなく、リスクに応じて確認の強さを変える設計が要る。

用途ごとに確認の強さを変える

AIの出力すべてに同じ確認を求めると、効率化の意味が薄れる。逆に、すべてを確認なしで使うとリスクが高い。出力の用途と影響度に応じて、確認の強さを変えるのが基本である。

「そのまま外に出るか」「間違うと影響が大きいか」を基準に、確認の強さを段階的に決めると、効率と安全のバランスを取りやすい。影響度の高い出力ほど、人の確認を必須にし、確認した記録を残す設計にしておきたい。

なぜ確認フローと責任分界が後回しになりがちか

デモでは「正しく答える様子」しか見えない

AIのデモは、うまく答える場面を見せることが多い。間違える場面や、間違えたときにどう確認・修正するかは、デモには出てこない。その印象に引っ張られると、「間違いが混じる前提」での確認設計が議論から抜け落ちる。

精度の話に寄りすぎる

「精度を何％にするか」という議論は分かりやすいが、精度をいくら上げても誤りはゼロにならない。精度向上だけを目標にして、「残った誤りをどこで止めるか」という確認フローを設計しないと、結局は誤った出力が外に出る。精度と確認は、どちらかではなく両方を設計する対象である。

責任分界は契約・運用の話で、技術の議論に埋もれる

誰が出力を確認し、誤りが問題を起こしたとき誰が責任を持つかは、技術ではなく運用と契約の論点である。技術仕様の議論に集中すると、この責任の整理が後回しになる。責任分界が曖昧なまま運用に入ると、トラブル時に社内・開発会社・利用者の間で対応が定まらない。責任の整理は、第6回のAIエージェントに権限を渡す前の落とし穴で扱った操作の責任分界とも地続きの論点である。

運用者がいないと、確認も改善も止まる

確認フローを作っても、それを回す運用者がいなければ形骸化する。誤りの傾向を見て確認の観点を更新する人がいないと、同じ間違いが繰り返される。運用体制については第9回の運用者不在で精度が劣化する問題でも扱った論点が重なる。

責任分界をどう整理するか

誤った出力が問題を起こしたとき、責任の所在を後から決めようとすると揉める。発注前に、関係者ごとの役割と責任の範囲を整理しておきたい。

重要なのは、「AIが出したから責任はAI（や開発会社）にある」とはならない点である。多くの場合、出力を確認して外に出す判断をするのは自社側であり、その判断に責任が伴う。開発会社の責任は「確認の仕組みやログが仕様どおり実装・提供されているか」が中心になることが多い。この切り分けを発注前に契約や合意の形で整理しておくと、トラブル時の対応が定まりやすい。具体的な責任範囲や免責は契約条件にも関わるため、必要に応じて法務の確認も得たい。

確認と責任を設計したフローの型

確認フローは、難しい仕組みでなくてよい。出力が外に出る前に「人が止められる場所」を作ることが本質である。たとえば次のような型がある。

1. 出力にラベルを付ける：その出力が「下書き用」か「そのまま外に出る」かを、生成の時点で分かるようにする。用途で確認の強さを切り替えやすくなる。
2. 影響度の高い出力に確認を挟む：顧客向け文書や、数値・出典を含む対外文書には、担当者の確認・承認を必須にする。確認なしでは外に出せない作りにする。
3. 確認の記録を残す：誰が・いつ・どの出力を確認・承認したかをログに残す。後から「なぜこの内容を出したか」を説明できるようにする。
4. 誤りを改善に回す：見つかった誤りの傾向を記録し、確認の観点やAI側の参照情報を更新する。同じ間違いを繰り返さない仕組みにする。

この型を、出力の用途ごとに当てはめていくと、過信も過剰チェックも避けやすい。すべてを人が二重確認するのではなく、影響度の高い出力に確認を集中させることで、効率化の効果を保ちながらリスクを下げられる。確認フローまで含めて設計する点は、AIエージェント導入の相談やAIエージェント開発の発注前検討でも軸になる。

発注前に確認すべきこと（チェックリスト）

• AIの出力を「下書き用」と「そのまま外に出る」に分けて整理したか
• そのまま外に出る出力・影響度の高い出力に、人の確認を挟む方針を決めたか
• 確認する人と、確認の観点（事実・数値・出典など）を決めたか
• 誰が・いつ・何を確認・承認したかの記録を残す要件を入れたか
• 誤った出力が外に出たときの責任分界（AI・運用者・開発会社・利用者）を整理したか
• 「精度100%」を前提にせず、誤りが混じる前提で業務フローを組んだか
• 誤りの傾向を確認フローやAI側に反映する運用を想定したか
• 契約・法務・医療・金融など、特に確認が重要な用途を切り分けたか

開発会社に確認する質問

「精度が高いので確認は不要」と説明する会社よりも、間違いが混じる前提で確認と記録の設計を具体的に示せる会社のほうが望ましい。

GXOに相談する前に整理しておくとよい情報

• AIに任せたい業務と、その出力が最終的にどこに出るか（社内・顧客・社外）
• その出力のうち、間違うと影響が大きいものはどれか
• いまの業務で、誰が内容を確認・承認しているか
• 確認や承認に関する社内ルール（決裁・監査・内部統制など）
• 契約・法務・医療・金融など、誤りが許されにくい用途があるか

出力の行き先と「間違うと困る場面」が整理されていると、「どこに人の確認を挟み、責任をどう分けるか」を現実的に設計できる。これらが整理されていなくても相談は可能で、外に出る出力が一つでも見えていれば、そこを起点に確認フローと責任分界を一緒に検討できる。AIの導入可否そのものを見極めたい段階では、AI導入可否のアセスメントから整理する進め方もある。

補足：実務上の注意点

確認フローを設計するうえで、実務上つまずきやすい点をいくつか補足する。

第一に、確認を「全部人がやる」設計にすると、AI導入の効率化効果が消える。確認は影響度の高い出力に絞り、低い出力は使う人の判断に任せる、というメリハリが要る。すべてを二重確認する運用は長続きせず、いずれ形骸化する。

第二に、確認する人が内容に詳しくないと、ハルシネーションを見抜けない。数値や出典、専門的な内容を含む出力は、その分野の知識を持つ人が確認する設計にしておきたい。確認者を「誰でもよい」としないことが重要である。

第三に、責任分界は技術ではなく合意と契約の話である。「AIが間違えたときに誰が責任を負うか」は、開発会社との契約条件や社内ルールで明文化しておくと、トラブル時の対応が定まる。免責や責任範囲は契約条件に関わるため、必要に応じて法務の確認を得たい。契約面の論点は、システム開発の稟議・ROI整理とあわせて社内合意を作っておくと進めやすい。

第四に、確認フローは一度作って終わりではない。誤りの傾向は業務や情報の変化で変わる。確認の観点を定期的に見直す運用がないと、新しいタイプの誤りを止められなくなる。確認と改善を回す運用者を決めておくことが前提になる。

なお、業務に組み込んだAIエージェントが自動で操作まで行う場合は、出力の確認に加えて操作の権限と停止条件も設計が要る。その論点はAIエージェント導入やAIエージェント開発の発注の段階で、確認フローとあわせて詰めておきたい。

関連記事

• ［特集トップ］AI開発発注の失敗図鑑
• 第6回 AIエージェントに権限を渡す前の落とし穴
• 第9回 運用者不在で精度が劣化する問題
• 第15回 規制・ガイドライン準拠を確認せず炎上する失敗

よくある質問

Q1. ハルシネーションは技術で完全になくせないのですか

現時点では、検索の組み合わせや社内文書の参照、確認用ルールの追加などで頻度は下げられるが、ゼロにはできないと考えるのが現実的である。だからこそ「なくす」前提ではなく「間違いが混じる前提」で、どこで人が確認して止めるかを設計することが重要になる。

Q2. すべての出力を人が確認すると、AI導入の意味がなくなりませんか

そのとおりで、すべてを二重確認する設計は効率化の効果を消してしまう。確認は、顧客や社外にそのまま出る出力や、間違うと影響が大きい出力に絞るのが現実的である。影響度の低い出力は使う人の判断に任せ、確認の負担をメリハリよく配分したい。

Q3. AIが間違えた場合、責任は開発会社にあるのですか

多くの場合、出力を確認して外に出す判断をするのは自社側であり、その判断には自社の責任が伴う。開発会社の責任は、確認の仕組みやログが仕様どおり実装・提供されているかが中心になることが多い。責任の切り分けは発注前に契約や合意の形で整理しておくと、トラブル時に対応が定まる。

Q4. 確認する人は誰でもよいのですか

内容によって変わる。数値・出典・専門的な内容を含む出力は、その分野の知識を持つ人が確認しないと、もっともらしい誤りを見抜けない。確認者を「誰でもよい」とせず、出力の種類ごとに必要な知識を持つ人を確認役に割り当てる設計にしておきたい。

発注前チェックリスト（全30項目・無料）：本連載の30類型を1枚で点検できるチェックリストを無料ダウンロードできます。発注前の社内確認・稟議の添付資料にご利用ください。

GXOでは、ハルシネーションを前提にした人間の確認（HITL）、確認の記録、誤出力時の責任分界を整理し、間違いが混じっても業務や法的なリスクにつながりにくいAI活用の設計を支援する。まずは無料相談で、出力の行き先と「間違うと困る場面」の整理から一緒に始めたい。