なぜ企業AIにHuman-in-the-Loopガバナンスが必要なのか

「人が確認するから大丈夫」では不十分

AIガバナンスについて、「最後は人が確認します」という説明をよく聞きます。

しかし、それだけではほとんど何も分かりません。

• 誰が確認するのか。
• どの工程で確認するのか。
• 何の情報を見るのか。
• AIの結果を否定できるのか。
• 否定すると追加作業が大量に発生しないか。
• 短時間で大量に承認するよう求められていないか。
• 上書き理由を残すのか。
• 回答しなかった場合はどうなるのか。
• 難しい案件は誰へエスカレーションするのか。

これらが決まっていなければ、人は業務の中に存在していても、実質的なコントロールを持っていない可能性があります。

NISTのAI Risk Management Frameworkでも、人とAIの構成における役割・責任を明確に区別し、人による監督プロセスを定義・評価・記録することの重要性が示されています。

Human-in-the-Loopは「承認ボタン」ではなく業務設計

意味のある人による確認には、少なくとも次の要素が必要です。

権限がある。

承認、否決、上書き、エスカレーションが実際にできる。

必要な情報がある。

判断に必要な証拠や業務コンテキストを確認できる。

判断できる時間と能力がある。

数百件を何も見ずに承認する状態にならない。

人の判断によって次の業務が変わる。

承認してもしなくても同じ処理が実行されるなら、本当のHuman-in-the-Loopとは言いにくいでしょう。

実効性のある関与には、権限、判断材料、適切な専門性、十分な時間と対応能力、そして結果を変えられる力が必要です。

簡単な例

AIがサプライヤー書類を確認し、「必要な情報は揃っているようです」と出したとします。

弱い設計では、

1. AI結果
2. 緑色の承認ボタン
3. 社員がクリック
4. 次工程

だけかもしれません。

より良い設計では、

• 元の書類。
• 抽出情報。
• 該当する社内基準。
• AIの推奨結果。
• 注意が必要な項目。

を確認でき、

• 承認
• 否決
• 修正依頼
• エスカレーション

を選択できます。

必要に応じて理由も記録します。

これは単に人を追加するのではなく、意思決定ポイントを設計することです。

すべてのAIに人の承認が必要なわけではない

人とAIの関係には複数の形があります。

• 人がすべて判断する。
• AIが処理し、人が明示的に承認する。
• AIが一定範囲で自動処理し、人が監視する。
• 人の確認をほとんど必要としない技術処理。

NISTも、人とAIの構成は完全手動から自律型まで幅があり、一部のAIシステムでは人の監督が必ずしも必要ではない一方、明示的な人の監督が必要なシステムもあるとしています。

だから目標は、「すべてのAIに人を入れること」ではありません。

「どこで人の判断・責任・介入が本当に価値を持つのか」を見つけることです。

AIの影響度によって監督レベルを変える

比較的影響の小さい支援

例えば、

• 社内メール下書き、
• 議事録要約、
• 文章修正、
• アイデア整理。

利用者自身が通常業務の中で確認するため、別の承認ワークフローは不要な場合があります。

業務支援

例えば、

• 書類から情報抽出、
• サービス依頼分類、
• 調達例外の要約。

業務によって、検証や一部レビューを組み合わせます。

意思決定支援

例えば、

• サプライヤー案件の追加確認要否を推奨する。
• 通常とは異なる請求書を検知する。
• 案件振り分けを推奨する。

ここでは、明確な担当者による確認が必要になる場合があります。

より重大な判断

• 財務、
• 契約、
• 安全、
• 雇用、
• 重要顧客対応

などへ大きな影響を与える判断では、企業ルールや法令等も踏まえ、より強い管理が必要になる可能性があります。

これは法的なリスク区分ではありません。

重要なのは、影響が大きくなるほど、AIに任せる権限と人による管理を慎重に設計するという考え方です。

図1：影響度と人による監督

ポイントは、すべてに同じHuman-in-the-Loopを入れないことです。

人には実際の決定権が必要

例えばAIが、「このサプライヤー申請を否決することを推奨します」と出したとします。

社員が、「これは違うと思う」と判断したにもかかわらず、AIの結果を止められないのであれば、その社員は本当に監督しているとは言いにくいでしょう。

業務では、

• 誰が承認できるか。
• 誰が否決できるか。
• 誰がAI結果を上書きできるか。
• 誰がエスカレーションできるか。
• 誰がルールを変更できるか。
• 最終的な業務結果の責任者は誰か。

を明確にします。

FluyentaのGoverned AI Control Planeでは、AIによる分析・推奨と、重要な意思決定を分離し、重要判断を人によるゲートの後に置く設計を説明しています。

判断権限を明確にする

これは説明用です。

実際の権限は各企業の規程と業務内容に合わせて決める必要があります。

人に必要なのはAIの答えだけではない

レビュー画面に、AI推奨：承認だけが表示されても、正しく判断するのは難しいでしょう。

必要に応じて、

• 元データ。
• 抽出された情報。
• 適用される社内基準。
• AIが検知した問題。
• これまでの処理履歴。
• 承認後に起きるアクション。

などを確認できる必要があります。

重要なのは、AI内部の隠れた思考過程を表示することではありません。

業務判断に必要な証拠を見せることです。

「94%の確信度」は説明ではない

例えば、AI Confidence: 94%と表示されたとします。

94%なら承認してよいのでしょうか。

必ずしもそうではありません。

その数字が、

• 何を意味するのか。
• 実際に確率として校正されているのか。
• この業務に適用できるのか。
• その閾値をどのように決めたのか。

が分からなければ、数値が人へ不必要な安心感を与える可能性があります。

重要な業務では、数字を見ることではなく、判断に必要な情報を確認することが必要です。

「AIを信じすぎる」問題

人を配置しても別の問題があります。

AIが多くの場合正しければ、社員が次第にAIの結果を確認しなくなる可能性があります。

承認ボタンが作業化します。

NISTも、人とAIの組み合わせによって認知バイアスが生じたり増幅されたりする可能性があり、人がAI出力へ異議を唱えられる能力や環境が重要だと指摘しています。

だから、「社員が確認した」だけでは十分ではありません。

本当に確認できる設計になっているかを見る必要があります。

形式的な承認になっている兆候

次のような状態では、人の判断ゲートの設計を見直す必要があります。

• ほぼすべての案件を数秒で承認している。
• 重要な根拠資料を確認しにくい。
• 異議を唱えるために過度な手間がかかる。
• 「AIはたいてい正しい」と考え、確認しなくなる。
• 画面が一つの回答へ視覚的に誘導している。
• 担当者がモデルの役割を理解していない。
• 上書きが避けられたり、抑制されたりしている。

人の判断ゲートは、根拠のある異議を示せるように設計する必要があります。

Override（上書き）は失敗ではない

AIと違う判断を人がしたからといって、必ずしもAI導入が失敗しているわけではありません。

例えば、

• AIが持っていない追加情報がある。
• 特殊案件である。
• 社内ルールが変わった。
• AIが誤った。
• 企業として人に裁量を残している。

という可能性があります。

そこで、AI推奨：X人の判断：Y理由：Zを記録できるようにします。

NISTのPlaybookでも、AI出力に対する人のoverrideや、エラー・苦情・判断活動などを記録・測定することが、人による監督を評価する上で有用な方法として示されています。

図2：意味のあるHuman Gate

これは、AI → 人がOK → 完了よりもはるかに意味のある管理です。

エスカレーションもHuman-in-the-Loopの一部

担当者が判断できない場合もあります。

それは問題ではありません。

例えば、

1. AIが不確実な案件を検知。
2. 一次担当者が確認。
3. 判断困難。
4. 専門担当者・管理者へエスカレーション。
5. 判断記録。

というルートを設計できます。

Human-in-the-Loopとは、一人の社員が何でも決めなければならないという意味ではありません。

誰にレビューさせるか

すべてを「AI確認担当」という同じ人へ送る必要はありません。

技術判断

技術担当

支払例外

経理

契約関連

適切な商務・法務担当

取引先登録

調達・指定審査担当

重大例外

権限を持つ管理者

というように、判断内容に合った専門性が必要です。

レビュー件数にも限界がある

AIが1日に2万件処理する業務で、「すべて人が承認する」と決めても、現実には難しい場合があります。

担当者が疲弊し、ほとんど見ずに承認するようになれば、Human-in-the-Loopは形骸化します。

そのため、業務によっては、

• ルールによる検証。
• 低リスク案件の通常処理。
• 例外のみ人へ。
• 一定割合のサンプリング。
• 高影響案件は必須承認。

などを組み合わせる方が合理的です。

運用できないHuman-in-the-Loopは、良いガバナンスではありません。

レビュー方式の考え方

これは各社共通の必須ルールではなく、設計を考えるための例です。

すべてのエラーを人で補わない

同じ書類をAIが毎回間違える場合、「もう一人確認者を増やそう」だけでは根本解決になりません。

なぜ失敗しているのかを調べます。

• 入力品質。
• モデル選択。
• プロンプト。
• 不足コンテキスト。
• 不明確な業務ルール。
• そもそもAIに向いていない処理。

などが原因かもしれません。

Human-in-the-Loopは、悪いAIシステムを永久に人が補修する仕組みではありません。

人が自動化を止められることも重要

必要に応じて、

• 一時停止。
• 否決。
• キャンセル。
• 上書き。
• エスカレーション。
• 手動処理への切り替え。

を可能にします。

NISTのAI RMFでも、導入後の監視に加えてappeal、override、incident response、recovery、change managementなどを含む仕組みが挙げられています。

人は、AIを見るだけではなく、必要な場面では介入できることが重要です。

人が回答しなかったらどうするか

Human-in-the-Loopで見落とされやすい部分です。

承認依頼を送った。

しかし担当者が回答しない。

そのまま1週間止まる。

では業務として不十分です。

例えば、

• リマインド。
• 再割当。
• 上長へエスカレーション。
• タイムアウト。
• 手動処理へ。
• 案件停止。

などを事前に設計します。

この点でも、メールで「確認お願いします」と送るだけより、ワークフローに組み込む方が管理しやすくなります。

AIと人の判断を一つの履歴として残す

半年後に、「なぜこの判断をしたのですか？」と聞かれたとき、必要に応じて、

• 入力データ。
• AI処理。
• AI推奨。
• 業務ルール。
• 担当者。
• 人の判断。
• Override。
• エスカレーション。
• 理由。
• システム操作。
• 日時。

を確認できると、企業として説明しやすくなります。

FluyentaのGovernance & SecurityではRBACと監査履歴を、Governed AI Control PlaneではAI処理と重要判断のログ・Human Gateを重視しています。

図3：判断履歴

を確認できます。

「人が承認したから会社に責任はない」にはならない

危険な考え方があります。

AIが推奨する。

人が承認する。

問題が起きる。

企業側が、「人間が承認したので、AIの問題ではない」と言う。

これは適切なガバナンスとは言いにくいでしょう。

企業は、

• AIの選択、
• ワークフロー、
• レビュー画面、
• 担当者配置、
• 権限、
• 業務ルール、
• 運用方法

を設計しています。

NIST AI RMFでも、AIリスクの開発・導入に関する意思決定について経営層の責任が明記されています。

Reviewerは、組織の責任をすべて引き受けるための存在ではありません。

レビュー担当者には教育が必要

レビュー担当者は、

• AIが何をしているか。
• 何をしていないか。
• どんな限界があるか。
• 何を確認するべきか。
• いつOverrideするか。
• いつエスカレーションするか。
• 自分の承認によって何が起きるか。

を理解する必要があります。

NISTでも、AIリスク管理に関する人材教育や、人とAIの利用・監督における役割分担の明確化が示されています。

専門知識を持つ社員だからといって、自動的に良いAI監督者になるわけではありません。

UI/UXもガバナンスの一部

例えば、

画面A

AI推奨：承認大きな緑色ボタン：承認小さな文字：否決

画面B

AI推奨：承認確認資料：

• 書類A
• 項目B
• 規程C

選択肢：

• 承認
• 修正依頼
• 否決
• エスカレーション

同じAIでも、人の判断の質は画面設計によって変わる可能性があります。

AIへ同意させるためのUIではなく、人が判断するためのUIが必要です。

Human-in-the-Loopが機能しているか測る

「承認ステップを追加した」だけで安心するべきではありません。

例えば、

• Override率。
• Override理由。
• 確認時間。
• エスカレーション率。
• 差し戻し率。
• 承認後に見つかったエラー。
• 担当者ごとの判断差。
• 未処理案件。

などを見ることができます。

ただし数字だけでは判断できません。

例えば、Override 0%はAIが完璧なのかもしれません。

人が何も見ていないだけかもしれません。

Override 30%はAIが悪いのかもしれません。

難しい案件をAIが一次推奨し、人が正常に判断しているだけかもしれません。

必ず業務コンテキストと一緒に考えます。

図4：ガバナンスの改善ループ

人による監督は、AIを永久に確認し続けるためではなく、業務全体を改善するためにも使えます。

AIのConfidence Scoreをどう扱うか

AI結果にスコアをつけ、低いものだけ人へ送るという方法もあります。

しかし、

• そのスコアが何を意味するか。
• 実際に校正されているか。
• 対象業務で妥当か。

を検証する必要があります。

AIが出した数字を、そのまま企業の承認基準にするべきとは限りません。

AI・ルール・人・システムを使い分ける

人に何でも確認させることも、AIに何でも任せることも、最適とは限りません。

AI AgentではHuman Gateをどこに置くか

AI Agentが、

• データ検索、
• レコード作成、
• メール送信、
• API実行、
• システム更新

まで行える場合は、さらに重要になります。

例えば、

1. Agentがサプライヤー案件を分析
2. 取引停止を推奨
3. 管理者が確認
4. 承認？
5. Yes → システム操作
6. No → 別ルート

という設計と、

1. Agentが取引停止を実行
2. 後から管理者へ通知

では、人の権限が大きく異なります。

どちらが正しいかは用途によります。

重要なのは、AIがアクションを実行する前後のどこに人を配置するかを意図的に決めることです。

Human-in-the-LoopとHuman-on-the-Loop

Human-in-the-Loop人の判断がなければ特定処理が次へ進まない。

AI → 人 → ActionHuman-on-the-LoopAIは定義された範囲で動き、人は監視し、必要な場合に介入する。

AI運用 → Monitoring → Intervention大量・低影響の処理にすべて明示承認を入れるより、Human-on-the-Loopの方が適切な場合もあります。

一方、重要判断ではHuman-in-the-Loopの方が適切なことがあります。

日本におけるAIガバナンス

経済産業省が公開している最新のAI事業者ガイドライン第1.2版は2026年3月31日に取りまとめられており、チェックリストやワークシートなどの活用資料も公開されています。

本記事のワークフロー設計が、そのままガイドライン上の義務という意味ではありません。

重要なのは、AIガバナンスが技術部門だけのテーマではなく、組織・経営・業務責任を含むテーマになっていることです。

NIST AI RMFは任意の枠組みです。日本のガイドラインは組織での取り組みの参照資料であり、認証や本記事の構成図を採用する義務を示すものではありません。共同公表資料は総務省でも確認できます。

実務例：調達例外

例えばPOと請求書が一致しないとします。

調達業務を説明するための例です。金額や基準はAxtonの社内規程、顧客案件、性能の目標値を示すものではありません。

1. 差異検知

   • PO：80万円
   • 請求：92万円

2. AI支援

   AIが関連資料を要約。

3. 業務ルール

   差額が企業設定基準を超過。

   人の確認を要求。

4. 担当者確認

   • PO。
   • 請求書。
   • 検収情報。
   • AI要約。
   • 差異。
   • 関連規程。

   を確認します。

5. 担当者判断

   • 例外承認。
   • 請求否決。
   • 追加説明依頼。
   • エスカレーション。

6. ワークフロー実行

   人の承認結果に応じて次処理。

7. 履歴

   AI支援、証拠、判断、理由、システム操作を案件履歴として残す。

これが実務上意味のあるHuman Gateです。

低リスクの情報抽出ならどうか

一方、

• 会社名。
• 日付。
• 管理番号。

をAIが定型フォームから抽出するとします。

抽出結果を既存データと自動検証し、すべて一致した場合でも、毎回人に承認させる必要があるでしょうか。

ケースによっては、AI抽出自動検証問題なしなら継続不一致・不確実だけ人への方が合理的です。

これが、Human-in-the-Loopを「AIがあるから付ける」のではなく、リスクと不確実性に合わせて設計するという考え方です。

Human Gateを設計するためのチェックリスト

実務上の設計を考えるための項目であり、法令適合性を保証するチェックリストではありません。

判断

人は具体的に何を判断するのか。

影響

誤った場合に何が起こるのか。

担当者

誰が適切な専門知識を持つか。

権限

結果を止めたり変えたりできるか。

証拠

何を確認する必要があるか。

AIの役割

推奨か、抽出か、分類か、実行か。

選択肢

否決、修正、エスカレーションが可能か。

理由

判断理由を残す必要があるか。

タイムアウト

回答がない場合どうするか。

エスカレーション

難しい案件は誰へ送るか。

作業量

現実的にレビューできる件数か。

監査

何を残すか。

改善

Overrideやエラーをどう改善へ使うか。

これは、「承認ボタンを置く」よりもはるかに有用な設計方法です。

Human-in-the-Loopでよくある失敗

AIが実行した後に人へ確認させる

これは承認ではなく、場合によっては事後監視です。

証拠を十分に見せない

スコアだけでは意味のある判断が難しくなります。

AIと異なる判断をしにくくする

Overrideが大変だと人はAIへ従いやすくなります。

全案件を人へ送る

大量レビューで形骸化する可能性があります。

専門性のない人へ送る

その案件を判断できる人が必要です。

すべてのAIを高リスク扱いする

不要な業務負荷になります。

人を「責任回避」のために置く

企業側のガバナンス責任は残ります。

人も間違える

人は自動的に正しいわけではありません。

• 疲労。
• 認知バイアス。
• 判断のばらつき。
• AIへの過度な依存。
• 情報の見落とし。

などがあります。

NISTも、人とAIの組み合わせそのものによって判断結果やバイアスが変わる可能性を指摘しています。

だから良いガバナンスは、AIは危険、人なら安全という考え方ではありません。

AI、ルール、システム、人、それぞれの弱点を他の仕組みで補うという設計です。

Axton Group × Fluyentaで考えるHuman-in-the-Loop

Axton Group LTD JapanはFluyentaとの提携を通じて、AIモデルそのものだけではなく、

• AIは何をするのか。
• その次にどんな判断があるのか。
• 影響はどの程度か。
• 責任者は誰か。
• どこまでAIへ権限を与えるか。
• 人はどこで介入するか。
• AIと人が異なる判断をしたらどうするか。
• 何を履歴として残すか。

という業務設計から考えます。

Axtonは、日本側での業務理解、関係者との調整、プロセス整理を担います。

Fluyentaは、ワークフロー、システム連携、RBAC、監査、AI統合などを活用し、自動処理と人による意思決定を一つの管理されたプロセスとして扱う技術を提供します。

FluyentaのProcess Orchestrationでは、人のタスク・承認と自動処理を組み合わせることを明示しており、Governed AI Control Planeでは重要判断にHuman Gateを置き、AIと人の処理履歴を記録する構造を説明しています。

目的は「承認ボタンを増やすこと」ではない

最後に最も重要なことがあります。

良い企業AIガバナンスは、承認ボタンが何個あるかでは評価できません。

• AIはAIが得意な仕事をする。
• 明確なルールはシステムが強制する。
• 判断が必要な場所では人が判断する。
• 権限をシステム側で制限する。
• 不確実なものはエスカレーションする。
• 履歴を残す。
• 実際の運用結果から改善する。

これが重要です。

重要な案件では、必ず人が確認する設計が適切な場合があります。

例外だけ人へ回す方がよい場合もあります。

通常の利用者確認だけで十分なAIもあります。

人の介入がほとんど価値を持たない処理もあります。

どこに人を置くべきかを判断できること。

それがHuman-in-the-Loopガバナンスの本質です。