AIエージェント導入で、見落とされがちな論点

「個人のAI」から「組織で動くAI」へ——複数エージェントの時代に、着手前に決めておくこと

FROM PERSONAL AI TO ORGANIZATIONAL AICOLUMN ON “AI AGENT GOVERNANCE” vol.1

はじめに：AIエージェントは、個人の道具から、組織の業務を動かす仕組みへ

生成AIの活用は、当初、個人が質問して答えを得る、文章を作るといった「個人が使うAI」が中心でした。いま広がりつつあるのは、AIが組織の業務プロセスの一部を担う使い方です。情報の収集、判定案の作成、業務システムの更新、報告書の作成といった役割ごとに専門のAIエージェントを置き、全体を取りまとめるオーケストレーター（要件に応じて適切な専門エージェントへ仕事を振り分け、進行を管理する司令塔役のAI）が連携させて、一連の業務を進める構成です。

この方向性は、大手調査会社の予測にも表れています。2028年までに企業向けソフトウェアの33%がエージェント型AIの機能を備え、日常的な業務判断の15%がAIによって自律的に行われるようになる一方、エージェント型AIのプロジェクトの4割超が2027年末までに中止されるとも予測されています^*1。理由はコストの増大、事業価値の不明確さ、リスク統制の不備です。導入は広がる一方で、成果につなげるのは簡単ではない、ということです。

ここで押さえておきたいのは、個人で使うAIと組織で動くAIとでは、失敗したときの影響がまったく異なることです。個人が使うAIの誤りは、本人が気づいて直せます。組織で動くAIの誤りはそのまま業務として実行され、複数のエージェントや後工程に波及し、誰が何を根拠に実行したのかが分からなくなることもあります。だからこそ、導入前に決めておくべきことの重みが変わります。

ただし、はじめから複雑な構成を目指す必要はありません。実際の広がり方は、もっと段階的です。

ポイントは、部署ごとにバラバラの単機能エージェントが並存している段階と、オーケストレーターを介して連携している段階とでは、必要な統制の重さが違うことです。独立して動く単純なエージェントであれば重いガバナンスは不要ですが、連携が進むほど、個々の精度だけでなく連携全体の統制が欠かせなくなります。その先にある「複数のエージェントが業務を引き受けてくれる世界」は理想形であり、現時点で到達している企業はほとんどありません。

ウフルでは、AIエージェント導入プロジェクトの各フェーズで確認しておきたい項目を社内の知見として整理しており、本稿ではそのうち、組織で動くAIでとくに重要性が増す5つの論点をご紹介します。論点2〜4（権限・データ・連携の統制）は、上図のSTEP4「ガバナンスを整える」の中身にあたります。

POINT 1論点1：成功の定義を、業務プロセス全体で決める

導入目的を「業務を効率化したい」といった抽象的な言葉のままにせず、「問い合わせへの応答時間を30%短縮する」のように、解決したい課題と期待する効果を具体的に定めることが出発点です。あわせて、工数削減、処理時間、顧客満足度など、効果を測る指標（KPI）を導入前に設定します。一般的なシステム開発でも重要な点ですが、AI案件ではとくに抜け落ちやすい点です。

複数のエージェントが連携する構成では、指標を置く単位にも注意が必要です。個々のエージェントの精度が高くても、業務全体の成果が上がるとは限らないため、「一連の業務が最初から最後までどれだけ正確・迅速になったか」という全体指標を軸にし、個々のエージェントの指標はその内訳として管理します。

また、すべての業務にエージェントが必要なわけではありません。ルールベース（あらかじめ決めた条件で動く仕組み）で足りる業務までエージェント化すると、コストばかりが膨らみます。現在エージェント型として位置づけられているユースケースの多くは、エージェント型の実装を必要としないという指摘もあります^*1。AIが本当に必要かを見極め、範囲を絞って始め、効果を確認しながら広げる進め方が現実的です。

POINT 2論点2：誰が何を実行してよいか——権限・承認・責任を設計する

AIが「答える」だけの段階から「実行する」段階に入ると、誤りの意味が変わります。誤った文章は訂正すれば済みますが、誤った発注、誤ったデータ更新、誤った送信は、取り消せない場合があります。AIが勝手に処理を進めてしまうリスクを抑えるには、何を任せるかを、能力の面ではなく「権限」の面から設計する必要があります。

セキュリティに関する国際的な非営利団体の整理によれば^*2、LLMを使ったシステムのリスクの一つに「過剰な権限委譲」があります。AIに与える機能・権限・自律性のいずれかが業務に必要な範囲を超えているとき、AIの誤りや外部からの不正な指示が、そのまま実害のある操作につながるというものです。この整理は、設計の指針としてそのまま使えます。

• 機能を絞る：その業務に不要な操作（メール送信、外部サイトの取得、データ削除など）は、そもそもAIが呼び出せないようにする

• 権限を絞る：参照だけでよい業務には読み取り専用の権限を与え、更新できる範囲は必要最小限にする

• 自律性を絞る：発注・契約・支払い・対外的な送信・個人情報を含む更新など、影響の大きい処理には、必ず人の承認を挟む

複数のエージェントが動く構成では、「誰が実行したか」を特定できることも重要です。共通のアクセスキーや人の認証情報を使い回すと、個々の操作を識別できず、権限の取り消しもできません。エージェントごとに識別できる形で権限を与えることが、最小権限の前提になります。

あわせて、誤った処理が起きたときの対応フローと責任分担（AIの提供者、システムの運用者、業務部門のどこが何を担うか）も、事前に決めておきます。精度をどこまで保証できるのか、SLA（サービス品質保証の水準）として契約上どう扱うのかという論点も、確率的に誤りが生じるAIの性質を踏まえて、早い段階で議論しておくべき事項です。なお、承認は増やしすぎると確認が形骸化するため、影響の大きい処理に絞るのが現実的です。

POINT 3論点3：「使ってよいデータ」と「使ってはいけないデータ」を線引きする

AIエージェントの判断の質は、参照するデータやナレッジの質に左右されます。データの種類・量・品質の確認、誤記・重複・古い情報の除去、更新の仕組みづくりは、基本として欠かせません。ただし、これは出発点にすぎません。組織で動くAIでは、「AIが参照できるデータ」と「AIが参照してよいデータ」が一致しているかどうかが、より大きな論点になります。

たとえば、次のようなデータは、AIが技術的にアクセスできたとしても、判断の根拠に使ってはならない、あるいは使うための条件を満たす必要があります。

• 機密区分が高く、特定の部署・役職しか閲覧できない情報

• 個人情報保護法などの法令、または契約によって、第三者への開示が制限されている情報

• 収集目的と異なる用途での利用が認められていないデータ

• すでに廃止された規程や手順など、古くなった情報

• 出所や作成者が不明で、正しさを確認できていないデータ

とくに注意したいのが、社内の文書を検索して回答に使う仕組み（RAG）の設計です。試験導入の段階では、すべての文書にアクセスできる共通のアカウントで接続する構成が取られがちで、その構成のまま本番に移ると、質問した本人には閲覧権限のない文書の内容まで回答に含まれてしまう可能性があります。

備えとしては、次のような設計が考えられます。

• データごとに、機密区分・所有者・利用目的・保持期間といった属性を付与する

• 検索の段階で、質問した人（またはエージェント）の権限に応じて、参照できる範囲を絞る

• AIに参照させるデータの範囲を、あらかじめ明示的に決める。個人情報などは、必要に応じてマスキングする

• 回答や判断がどのデータに基づいているかを、あとから追跡できるように記録する

• 古くなった情報を廃止・更新するフローを、運用に組み込む

複数のエージェントが連携する場合、誤ったデータの影響はさらに広がります。あるエージェントが取り込んだ誤情報が他のエージェントに共有され、判断の前提として再利用されるためです。詳しくは次の論点で扱います。

POINT 4論点4：エージェント同士がつながることで増えるリスクに備える

複数のエージェントに役割を分けても、全体の信頼性が自然に高まるわけではありません。役割の取り違え、指示の曖昧さ、検証不足による失敗が起こりやすく、とくに情報を再利用する構成では、前段の小さな誤りが後段で事実として扱われ増幅することがあります。

たとえば、前段のエージェントがデータの単位や通貨を取り違えたまま次に渡した場合を考えてみます（あくまで想定例です）。後段のエージェントは、それを正しい前提として計算や判断を進めます。エラーとして検知されないまま、結果だけが大きくずれるという状態が起こり得ます。

こうした「気づかれにくい誤りの連鎖」に対しては、エージェントごとの対策だけでは十分とはいえず、連携全体を見渡した統制が必要になります。

• 確認の役割を独立させる：結果を作るエージェントと、確認するエージェント（または人）を分け、途中の重要な地点で内容を検証する

• 受け渡す情報に出所を添える：どのデータ・どの処理に基づく結果かを、後段から確認できるようにする

• 全体を横断して追えるログを残す：誰が（どのエージェントが）、何を根拠に、何を実行したかを、個別の操作単位でも、業務の流れ全体でも追えるようにする

• オーケストレーターに権限を集中させない：役割は振り分けと進行管理に絞り、発注や更新の実行権限は各業務を担当するエージェント側に持たせておく

• 止める手段と上限を用意する：エージェント同士の呼び出しの繰り返しなどで処理量や費用が膨らむことを防ぐ上限を設け、異常時には全体を止める・元に戻す手順を用意する

POINT 5論点5：誤答・誤処理を前提に、品質の測り方と運用を設計する

AIの回答には誤りや曖昧さが残る可能性があります。「AIはすべてを自動化できるわけではない」「精度は100%ではない」という前提を提案段階で共有し、AIと人の役割を明確に分けておかないと、導入後に期待とのギャップが生まれます。利用者には、AIが応答していることを明示し、答えられないときは「分からない」と伝えて人へ引き継ぐ設計も重要です。

品質の測り方にも、従来のシステムとは異なる観点が必要になります。代表的な確認方法として挙げられるのは、正答率、事実と異なる内容をもっともらしく答える「幻覚」の発生率の測定、指示文（プロンプト）やモデルを変更したときに品質が下がっていないかの確認（回帰テスト）、本番と同じ入力を使って本番に影響を与えずに評価する方法（シャドーモード）などです。複数のエージェントが連携する場合は、個々のエージェントだけでなく、業務の入口から出口まで通した評価も重要になります。

そして、導入後の運用が品質を左右します。ナレッジの更新、プロンプト・モデルの調整、正答率や引き継ぎ率のモニタリング、誤答の検知と改善、運用体制、緊急時の停止・復旧手順まで、あらかじめ設計しておきます。モデルの利用料や改善費用など、継続的に発生するコストが初期見積もりに含まれにくい点にも注意が必要です。

統制の全体像：リスクと備えの整理

論点2〜4で挙げたリスクを整理すると、次のようになります。

論点2・3・4の統制が実際に守られているかは、ログ・監査によって「あとから確認できる状態」にしておく必要があります。下の図はその関係を示したものです。論点5（品質の測り方と運用）は、このログを材料に誤答・誤処理の傾向を継続的に監視・改善する活動にあたります。

統制を「現場のスピードを落とすもの」と捉えると導入は進みにくくなりますが、事故が起きればプロジェクトはむしろ止まり、復旧にも時間がかかります。決めるべきことを少数に絞り、責任の境界を明確にすることが、安心して展開を進める前提になります。

5つの論点に共通すること

5つの論点は、いずれも技術の難しさではなく、「何を成功とするか」「どこまでをAIに任せるか」「どのデータを使わせるか」「誰が止められるか」といった、決めごとに関わるものです。実装に入ってから気づくと、設計のやり直しや追加費用につながります。

先に触れたプロジェクト中止の理由^*1（コストの増大、事業価値の不明確さ、リスク統制の不備）と重ねてみると、論点1が事業価値、論点5がコスト、論点2〜4がリスク統制に、それぞれ対応していると整理できます（この対応づけ自体は、本稿による整理です）。

もう一つの特徴は、同じ論点が形を変えて各フェーズに繰り返し現れることです。たとえば「AIが答えられないときに人へ引き継ぐ」という点は、要件定義から運用まで各フェーズで確認項目として登場します。一度決めれば終わりではなく、フェーズごとに見直す前提で進めることが大切です。

着手前の自己確認

• 成功の定義

  業務プロセス全体として何がどれだけ良くなれば成功かを、数値で説明できるか。その業務にエージェントが本当に必要か（ルールベースで足りないか）を検討したか

• 権限と承認

  エージェントが実行できる操作と権限は、業務に必要な最小限になっているか。影響の大きい処理には、人の承認が入っているか

• 識別と追跡

  エージェントごとに識別でき、誰が何を実行したかを特定できるか

• データの線引き

  AIが参照できるデータと、参照してよいデータの線引きが決まっているか。質問した人の権限が、検索結果に反映されるか

• 連携の統制

  前段の誤りが後段に伝わらないよう、確認の役割や検証点があるか。異常時に全体を止める・元に戻す手順があるか

• 品質と運用

  誤答を前提とした品質の測り方（正答率、回帰テストなど）と、導入後の運用担当・継続コストを見込んでいるか

• 責任分担

  誤った処理が起きたときの対応フローと責任分担が、文書化されているか

まとめ

組織で動くAIエージェントの導入で成果を分けるのは、個々のモデルの性能よりも、着手前にこうした論点をどれだけ具体的に洗い出せるかです。AI単体ではなく、判断に使うデータの整備と線引き、権限と承認の設計、運用の仕組みまで含めた全体設計が欠かせません。

ウフルは、データ基盤の整備から、データに基づく意思決定、AIエージェントによる業務の自動化・高度化まで、一貫して支援しています。導入をご検討の際は、上記の自己確認を起点に、自社の現在地を確認してみてください。