Enterprise AIでAIに任せる判断と人が持つ判断を分ける¶

対象 / ポイント

対象: 組織でAI活用を広げたいが、責任分界、承認、現場定着で詰まりたくない推進担当者。

ポイント:

AI導入がPoCで止まる主因は、精度不足より責任分界の曖昧さにある。
「AIに決定を任せる」は誤りで、AIは組織が先に決めた方針を実行しているにすぎない。
責任分界表は全社規程ではなく、1業務単位で作り、業務フローに接続する。

問い合わせ分類のAIが高い精度を出した。会議では評価された。だが本番化の直前で、法務、セキュリティ、業務責任者の質問が並ぶ。

「誤分類したとき、誰が責任を持つのか」「AIの推奨を現場がそのまま使った場合、承認済みと見なすのか」「ログを誰が見るのか」

精度は問題になっていない。止めているのは、責任の所在だ。

この記事の問いは1つ。Enterprise AIで、AIに任せる判断と人が持つ判断をどう分ければ、PoCから本番へ進めるのか。

先に結論を置く。本番化で決めるべきは、AIの能力上限ではない。 AIが出してよい判断、人が承認する判断、組織が責任を持つ判断の境界である。そしてその境界は、ドキュメントではなく業務フローに接続して初めて効く。

「AIに任せる」を3段階に分解する¶

この節が答える問い

「AIに任せる」と言うとき、何を任せているのか。

AIに任せる範囲は、候補、推奨、決定の3段階に分けると事故が減る。同じAIでも、段階が変わると責任が変わるからだ。

問い合わせ分類で考える。

問い合わせ文を読んでカテゴリ候補を3つ出す。これは候補生成。
候補の中から最も近いカテゴリを1つ推す。これは推奨。
顧客対応フローを自動で分岐させる。これは決定。

段階	AIの役割	人・組織が持つこと	事故時の論点
候補生成	選択肢と根拠を並べる	どの候補を採るか選ぶ	見落としを許容できるか
推奨	1案を優先表示する	推奨を承認または却下する	現場が盲信しない設計か
決定	承認済み方針を後続処理へ実行する	方針と停止条件を先に決める	誤作動を止められるか

ここで見落とされやすい点がある。「決定」の段で動いているのは、AIの判断ではない。組織が事前に決めた方針を、AIが速く実行しているだけだ。「AIに決定を任せる」という言い方は、この事実を隠してしまう。

OpenAIのThe State of Enterprise AI 2025は、企業のAI利用がチャットの単発質問から、構造化された反復処理（Custom GPTsやProjects）へ移っていることを示す¹。利用が個人の下書きから組織の処理に近づくほど、AIの出力は1人の作業物ではなく、業務フローの一部になる。その時点で、責任分界は機能要件になる。

PoCの合格条件を精度だけにしない¶

この節が答える問い

PoCで精度だけを見ると、なぜ本番で止まるのか。

PoCの合格条件を精度に寄せすぎると、本番移行で止まる。分類精度が十分でも、例外処理、承認、監査、差し戻しの線がなければ運用に入らないからだ。

現場は便利さを見る。管理部門は失敗時の説明責任を見る。同じPoCを見て、見ているものが違う。この差を埋めないまま「精度が高いので本番へ」と進めると、止まる場所がPoCから本番直前へずれるだけになる。

McKinseyのThe State of AI 2025は、AI利用自体は調査対象の88%に広がる一方、全社規模で展開できた組織は約3分の1にとどまり、残る約3分の2はパイロット段階を超えられていないと整理する²。つまりボトルネックはモデルの精度ではなく、仕事の流れを作り替えられるかにある。

PoCの合格条件には、精度に加えて次の4点を入れる。

AIの出力を誰が確認するか
どの条件で人間に戻すか
誤りを見つけたとき誰が修正するか
ログを誰が、どの周期で見るか

精度は入口にすぎない。責任分界のない精度は、本番では説明にならない。

責任分界表は小さく作り、業務フローに接続する¶

この節が答える問い

責任分界表は、どこに置けば機能するのか。

責任分界表は、最初から全社規程にしない。1業務、1出力、1承認者で作る。問い合わせ分類なら、AIの出力を「カテゴリ候補、根拠、例外フラグ」に絞り、人間はカテゴリを承認し、組織は承認後に進む業務フローを定義する。これだけで議論は具体化する。

判断	AIがしてよいこと	人が持つこと	組織が決めること
カテゴリ分類	候補と根拠を出す	最終カテゴリを承認する	分類体系と例外ラベル
優先度付け	緊急度候補を示す	顧客影響を加味して決める	SLAとエスカレーション基準
回答案作成	下書きと参照元を出す	外部送信を承認する	禁止表現とレビュー権限
改善提案	パターンを抽出する	採用可否を判断する	予算、担当、期限

この表の価値は、責任を押し付け合わないことにある。 AIは判断材料を速く出す。人間は文脈と例外を引き受ける。組織は、承認された判断がどの業務に接続されるかを決める。

ただし、この表は作って終わりではない。最も多い失敗は、責任分界表をPoCの審査資料として一度書き、本番フローに反映しないことだ。表が承認会議の場で消費され、実装には接続されない。これでは、ガバナンスの体裁だけが残る。

NIST AI RMFは、AIリスク管理を Govern、Map、Measure、Manage の4機能で整理する³。責任分界表は、このうち誰が何を担うかを整理する Map と、統制の所在を定める Govern を業務単位に落とす道具になる。重要なのは、その整理を文書のままにせず、後続の業務フローに埋め込むことだ。表の各行が、実際の承認ボタンやルーティング条件と対応している状態を作る。

人間の承認を「最後に見る人」にしない¶

この節が答える問い

人間が承認するなら安全、という設計はなぜ弱いのか。

人間が見るから安全、という設計は弱い。承認者が毎回AIの出力を最初から読み直すなら、AI導入で下がるコストは小さい。逆に、ほぼ読まずに通すなら、人間の承認は形式だけになる。どちらに転んでも、人間を最後に置いただけでは安全にならない。

必要なのは、人間が見るべき差分をAI側が整理する設計だ。通常ケースはカテゴリ候補と根拠を出し、判断が割れそうなケースだけ例外フラグと不足情報を添える。人間はすべてを再分類するのではなく、例外と境界ケースに注意を集中する。

1件の入力がどう流れるかを、動きとして書くとこうなる。

入力が届く → AIが候補と根拠と例外フラグを出す → ルーターが例外フラグを見る → フラグが立てば差分を添えて人間へ回す → 人間が承認または却下する → 承認結果が後続フローへ接続される

この流れを最小のルーティング規則に落とすと、たとえば次のようになる。

def route(ai_output):
    if ai_output.exception_flag or ai_output.confidence < 0.8:
        return to_human(ai_output, show=["候補", "根拠", "不足情報"])
    return to_pipeline(ai_output, log=True)

この設計では、AIの仕事は判断を奪うことではない。人間の注意を、事故が起きやすい場所へ寄せることだ。

OECDのAI原則は、文脈に応じた人間の主体性と監督、説明責任を重視している⁴。これを現場に落とすなら、人間を最後の飾りに置かない。人間が判断すべき場所を、業務フローの中で明示する。

まとめ: AI判断は小さく、責任は接続して明確にする¶

Enterprise AIの本番化で先に決めるべきなのは、AIの能力上限ではない。 AIが出してよい判断、人が承認する判断、組織が責任を持つ判断の境界である。

最初の責任分界は、この3行で足りる。

AIは候補、根拠、例外フラグを出す。
人間は外部影響、顧客影響、法的影響を含む判断を承認する。
組織は承認権限、ログ確認、差し戻し、改善責任を定義する。

この線引きがあると、PoCの評価が変わる。単に「精度が高いか」ではなく、「どの判断までなら安全に任せられるか」を見られる。その問いに答えられ、かつ答えを業務フローに接続できるPoCだけが、本番へ進める。

「AIに決定を任せる」は、正確には「組織が決めた方針をAIに実行させる」だ。だから本番化で問われるのは、AIをどこまで信じるかではない。方針を誰が書き、どこに接続し、誰が止められるようにするか、である。

AIが賢くなるほど、人間の責任は消えるのではない。位置が変わる。その位置を設計し、業務フローに接続できる組織だけが、Enterprise AIを業務の中に残せる。

Enterprise AIでAIに任せる判断と人が持つ判断を分ける¶

「AIに任せる」を3段階に分解する¶

PoCの合格条件を精度だけにしない¶

責任分界表は小さく作り、業務フローに接続する¶

人間の承認を「最後に見る人」にしない¶

まとめ: AI判断は小さく、責任は接続して明確にする¶

関連記事¶