Rosarium

AI適用判断 / AI設計 / principle

AI適用可否と委任レベルの設計

生み出したい価値と業務変化から、AI・人間・既存システムの役割を逆算する。誤りの影響や検証可能性を踏まえ、AIを使わない選択も含む最小の委任範囲を決める。

最終更新：

更新履歴

  1. 改訂

    価値・リスク・検証可能性・権限・復旧から、必要な最小の委任範囲を選ぶ観点を整理した

  2. 公開

foundations

読む目的： AI導入・責任・評価

目次
  1. AI適用可否と委任レベルの設計
  2. はじめに
  3. AI技術ではなく、価値から始める
  4. AIを使うか、任せるか
  5. 点数を付ける前に、禁止条件を見る
  6. 確認できる仕事ほど任せやすい
  7. 説明できる範囲だけを委任する
  8. 権限と自動化を分ける
  9. 委任レベルは固定ではない
  10. 具体例
  11. 検証・修正・復旧まで含めて委任を比較する
  12. まとめ
  13. 参考資料

AI適用可否と委任レベルの設計

種別：設計原則 / ガバナンス設計 適用対象：生成AI、AIエージェント、業務自動化 対象工程：企画 / 設計 / 承認 / 運用

はじめに

AIに質問することと、AIに仕事を任せることは違う。

旅行先の候補を聞くだけなら、間違っていても人間が読み捨てられる。しかし、AIが出張を予約したり、顧客へメールを送ったりすれば、出力は現実の結果を生む。

したがって、AIの利用可否は「賢いかどうか」だけでは決められない。

見るべきなのは、次のような点である。

  • 間違えたときの影響
  • 人間が正しさを確認できるか
  • 実行後に取り消せるか
  • 必要な情報が揃っているか
  • AIへどこまで権限を渡すか

AI技術ではなく、価値から始める

AI適用を考えるとき、「RAGを導入したい」「AIエージェントを作りたい」から始めると、技術の使い道を後から探すことになる。

先に決めるのは、誰にどのような価値を生み出し、仕事や判断をどう変えたいかである。

価値
  ↓
実現したい業務変化
  ↓
業務・システム設計
  ↓
AI・人間・既存システムの役割分担
  ↓
必要なAI技術
  ↓
安全性・責任境界
  ↓
評価・運用・改善
  ↓
再設計

この順序では、AIを使わないことも正式な設計結果になる。定型的な処理ならルールや既存システム、画面や業務手順の変更だけで価値を実現できる場合がある。

AIを採用する場合も、モデルの能力ではなく、価値へ必要な最小の役割を選ぶ。自然言語の解釈、候補の探索、根拠の収集、下書きの生成など、確率的な処理が効果を持つ範囲へ限定する。

顧客問い合わせQAの例

悪い出発点は「RAGを導入する」である。良い出発点は、次の業務変化である。

  • 顧客が自分で解決できる問い合わせを増やす
  • 人間は専門判断が必要な問い合わせへ集中する
  • 自己解決できないとき、適切な担当者へ必要な情報とともに引き継ぐ

ここから、自己解決できる質問と専門判断が必要な質問を分け、既存システムにある根拠を特定する。その後で、自然言語の入口、RAG検索、回答根拠、追加質問、Human in the Loop、有人対応への移管を設計する。

導入後は、誤回答や有人対応の結果を、参照資料、分類、検索条件、回答範囲、移管条件の改善へ戻す。評価はモデルの正答率だけでなく、自己解決率、専門担当者へ届く問い合わせの質、回答時間、誤案内の影響まで見る。

この設計順序についての思考の変化は、DXを学んで、「価値」という言葉が気になるようになったにまとめている。

AIを使うか、任せるか

AI利用には段階がある。

段階AIの役割例
L0AIを使わない通常のプログラムや人間だけで処理する
L1情報を整理する選択肢、要約、調査結果を出す
L2下書きを作るメール案、コード案、回答案を作る
L3人間承認後に実行する人間が確認した内容だけ送信・登録する
L4限られた範囲で自動実行する金額や対象を限定して処理する
L5広い範囲を自律実行する状況を判断しながら複数工程を進める

多くの業務で、最初からL4やL5を目指す必要はない。

L1やL2でも、人間の調査時間や下書き時間を減らせる。価値が出る最小の段階から始める方が安全である。

点数を付ける前に、禁止条件を見る

AI適用を点数表だけで決めると、重大な問題が平均点に埋もれる。

たとえば、品質、費用、速度の評価が高くても、法律上人間の判断が必要な仕事なら、自動実行はできない。

まず、越えてはいけない条件を確認する。

  • 法律や契約で人間承認が必要
  • AIへ渡せない機密情報が必要
  • 正しさを確認する方法がない
  • 間違えると人命や重大な権利へ影響する
  • 実行を取り消せず、損害が大きい
  • 誰が責任を持つか決まっていない

このような条件がある場合、AIを完全に使えないとは限らない。しかし、下書きや情報整理までに留める必要がある。

確認できる仕事ほど任せやすい

AIが得意そうに見えるかより、出力を確認できるかが重要である。

コード生成では、コンパイル、テスト、静的解析、レビューによって確認できる。文章の要約でも、原文と比べられる。

一方、正解を知る人が誰もおらず、結果が数年後にしか分からない判断は、確認が難しい。

確認方法には次のようなものがある。

  • 決められた形式になっているか機械で調べる
  • 原文や根拠と照らし合わせる
  • テストを実行する
  • 別の担当者が確認する
  • 少数の利用者だけで試す

「最後は人が見る」では不十分である。人が何を見れば正しいと判断できるのかまで決める。

説明できる範囲だけを委任する

委任には、根拠を確認でき、採用理由を説明し、誤りへ対応できることが必要です。条件を満たせなければ、回答・判断・実行から候補提示・検索・整理へ役割を戻します。停止すべき条件は第4章　AIに任せない条件を、先に決めるで整理しています。

権限と自動化を分ける

AIが処理できることと、処理してよいことは別である。

メール文を作れるからといって、全顧客へ送信する権限まで与える必要はない。データを検索できるからといって、削除権限も必要とは限らない。

自動化する場合は、範囲を狭くする。

  • 読み取りだけ許可する
  • 一件あたりの金額に上限を付ける
  • 対象者や対象システムを限定する
  • 一日の実行回数を制限する
  • 重要操作は人間承認後に実行する

AIの能力を上げることより、権限を必要最小限に保つことの方が安全性へ直接効く。

委任レベルは固定ではない

同じ仕事でも、条件によって任せられる範囲は変わる。

たとえば社内QAでは、根拠文書が整備され、回答と引用を確認できる領域ならL2で使いやすい。文書が古く、例外が担当者の頭の中にしかない領域では、L1に留めた方がよい。

運用を続ける中で、次のような変化があれば委任レベルを見直す。

  • モデルやプロンプトを変更した
  • 規程や文書が変わった
  • 新しい利用者や用途へ広げた
  • 誤回答や事故が増えた
  • 人間確認が形だけになった

問題が起きたときに、機能全体を止める以外にも、L4からL3へ戻す、L3からL2へ戻すという縮小ができるようにする。

具体例

社内文書の質問

AIが回答案と引用を示し、利用者が原文を確認するならL1〜L2で始められる。

回答をそのまま正式見解として扱うなら、文書の版管理、回答範囲、責任部門が必要になる。

コード修正

AIが修正案を作り、自動テストと人間レビューを通してから取り込むならL2〜L3である。

AIが本番環境へ直接反映するなら、影響が大きくなるため、権限、段階公開、切り戻しまで必要になる。

顧客への返金

返金条件を整理するだけならL1、返金案を作るならL2、人間承認後に実行するならL3である。

AIが自動で返金するなら、金額上限、対象条件、監視、停止方法が必要になる。

検証・修正・復旧まで含めて委任を比較する

AIにできるかだけでなく、任せた後を含めても価値があるかを判断します。委任判断では、少なくとも次を確認します。

判断軸確認すること
価値誰のどの成果が改善するか。既存の方法で達成できないか
リスクと可逆性誤りが何へ影響し、どこまで取り消せるか
検証可能性と確認負荷根拠を確認し、採否を決められるか。その作業を担えるか
実行権限許可する対象・操作・上限と、人間承認が必要な条件は何か
修正・復旧問題時に誰が止め、どの範囲を戻せるか

確認負荷は委任範囲を決める一条件です。費用だけを理由に高影響の処理の承認を省きません。必要な確認が成立しない場合は範囲を縮めるか、AIを使わない選択をします。作業量と待ち時間を含む効率の評価方法は第2章　AI導入は効率化とは限らないで扱っています。

運用後の見直しはAI導入を業務へ定着させるへ接続します。

まとめ

AIの利用可否は、導入するか、導入しないかの二択ではない。

AIへ何を考えさせ、何を作らせ、どこから先を実行させるかを段階で決める。

高い委任レベルほど優れているわけではない。必要な価値が得られる最小の委任レベルを選ぶ方が、費用、責任、安全性を管理しやすい。

参考資料