AIエージェント導入で最初に設計すべきは「AI」ではない――企業AIが「回答」から「実行」へ進むほど、Identityと権限設計が重要になる

生成AIの企業導入は、次のフェーズに入りつつあります。

これまで企業がAIに求めてきたのは、文章を書く、情報を検索する、資料を要約するといった「支援」が中心でした。しかし現在は、AI AgentがCRMを参照し、社内システムを操作し、メールを送り、場合によっては決済まで実行する世界が現実になり始めています。

OpenAIは2026年8月12日に公表したEnterprise AIの分析で、この変化を「assistanceからexecutionへ」と表現しています。AI利用上位10%の企業では、一般的な企業と比較して1ユーザー当たりの出力トークンが8.3倍に達しており、同社はその背景として、AIを企業コンテキストやツール、再利用可能なワークフローへ接続する動きが進んでいることを挙げています。

つまり、企業AIの競争軸は、「AIを使えるか」から、「AIに仕事を任せられるか」へ移り始めています。

しかし、ここには見落とされやすい問題があります。

AIが仕事を「実行」するのであれば、企業はAIにも、人間の社員と同じように、「あなたは誰で、何をしてよいのか」を定義しなければならないということです。

ChatbotとAI Agentの決定的な違い

例えば、営業担当者向けAIを考えてみます。

従来型のAIなら、「この顧客について教えて」という質問に対して、CRMや社内資料を検索し、回答を生成します。ここで主に問題になるのは、AIが何を「見てよいか」です。

一方、AI Agentになると話が変わります。

「来週商談する顧客を調べて、提案の仮説を作っておいて」という指示から、CRMを検索する、過去の商談履歴を読む、企業情報を調査する、提案仮説を作る、営業資料を生成する、CRMへ記録する、担当者へ通知するといった複数の処理を自律的に実行できるようになります。

ここでは、何を見てよいかだけでは足りません。

何を変更してよいか。誰に送ってよいか。どのシステムを操作してよいか。どこまで自律的に判断してよいか。

を決める必要があります。

AI Securityの論点が、Data AccessからAction Permissionへ広がるわけです。

「AIに権限を与える」という新しい設計問題

この問題は、すでに大手AIプラットフォームの設計にも表れています。

AnthropicとGoogle CloudがProduction環境のAgent運用について紹介しているアーキテクチャでは、AgentごとにIdentityを持たせ、Cloud IAMを使ってAgent単位・ユーザー単位でPolicyを適用し、さらにTool CallごとにGuardrailを設定する考え方が示されています。また、Agentが何を実行したかを追跡できるよう、TraceやAudit EventをObservability基盤へ送る仕組みも紹介されています。

Google Cloudも2026年5月5日に発表したAgent Gatewayについて、User-to-Agent、Agent-to-Agent、Agent-to-Toolの通信を統制するための仕組みとして位置づけています。

これは非常に重要な変化です。

従来のEnterprise ITでは、User → Systemという関係を中心にIdentityと権限を設計してきました。

しかしAgentic Enterpriseでは、User → Agent → Agent → Tool → Systemという関係が生まれます。

そのため、「このAPIを誰が呼んだのか」という問いに対して、「ユーザーAです」だけでは説明できなくなります。

実際には、ユーザーAから仕事を委任されたAgent Bが、Agent Cを経由してTool Dを実行したというケースが出てくるからです。

決済業界が先にこの問題へ動き始めた

この変化が分かりやすく表れているのがCommerceです。

2026年9月10日、Visa、Mastercard、Ant Internationalは、AI Agentによる取引について、Agentを識別・検証するための共通Trust Framework構築に向けた取り組みを発表しました。

理由はシンプルです。

AIが商品を「おすすめする」だけなら、従来のChatbotでも対応できます。しかし、商品を選ぶ、店舗とやり取りする、配送先を入力する、支払いを実行するところまでAIが担当するなら、「このAgentは、本当にこのユーザーから購入を委任されているのか」を確認しなければなりません。

AI Agentが普及するほど、Identityは人間だけのものではなくなります。

AI Agent導入では「自律度」を一律にしない

ここからはELYSAIの考え方です。

企業がAgentic AIを導入するとき、「どのモデルを使うか」から議論を始めるケースは少なくありません。GPTか、Claudeか、Geminiか。もちろんモデル選定は必要です。

しかし本番導入では、それより先に決めるべきことがあります。

AIにどこまで任せるのか。

です。

私たちは、業務ごとにAIの自律度を少なくとも次の4段階で考えることが有効だと考えています。

Level 1 — Suggest

AIは提案だけを行う。例えばメール文面を作るが、送信するのは人間です。

Level 2 — Prepare

AIが実行直前まで準備する。CRMへの入力内容を作成するが、保存前に人間が確認します。

Level 3 — Execute with Exception

通常処理はAIが実行し、一定条件だけ人間へEscalationします。例えば10万円以下の処理はAgentが実行し、それ以上は承認を要求する設計です。

Level 4 — Autonomous

定義された範囲ではAIが自律的に判断・実行します。人間は個々の処理ではなく、Policyと結果を監視します。

重要なのは、Level 4を目指すことではありません。 業務リスクに応じて、適切なLevelを選ぶことです。

Human-in-the-loopは「全部確認すること」ではない

AI Agentの議論では、「最終的に人間が確認すれば安全」という説明をよく見かけます。しかし、これは本番運用では成立しないことがあります。

Agentが1日に10件処理するなら、人間が確認できます。1万件になればどうでしょうか。すべてを確認するのであれば、AIによる自動化のメリットそのものが小さくなります。

だからHuman-in-the-loopは、Human checks everythingではなく、Human handles exceptionsへ設計を変える必要があります。

例えば、通常処理はAgentが実行、Policy違反はBlock、信頼度が低い場合はHuman Review、高額処理はApproval、異常行動はStop & Escalateという構造です。

AIを導入するというより、AIと人間の責任境界を設計すると考えたほうが実態に近いでしょう。

AI Agentには「社員証」が必要になる

企業ITには、すでに人間向けの仕組みがあります。社員にはIdentityがあり、Roleがあり、Access Permissionがあり、操作Logがあります。退職すればAccessを停止します。

しかしAI Agentについては、まだ「共通API Keyで全部のシステムへアクセスしている」「どのAgentが操作したのか分からない」「ユーザー本人の権限をそのままAgentへ渡している」といった実装も起こり得ます。

PoCなら動きます。しかし、本番運用では危険です。

Agentic Enterpriseでは、Agent Identity、Agent Permission、Delegation、Audit Trail、Revocationといった仕組みが、通常のEnterprise Architectureの一部になっていくでしょう。

言い換えれば、AI Agentにも「社員証」が必要になるということです。

AIXでは「AI導入」より先に仕事を再設計する

ここでAI Transformation（AIX）の話につながります。

AIXを「社内にAIツールを増やすこと」と定義してしまうと、ChatGPTを導入する、RAGを作る、Agentを作るというTechnology Projectになってしまいます。

しかしAIが実行主体になるなら、本当に設計すべきなのはTechnologyだけではありません。

例えば経理業務なら、人間が担当する判断、AIへ委任する作業、AIがアクセスできるデータ、AIが実行できるAction、Human Approvalが必要な条件、失敗時のRollback、監査Log、成果を測るKPIまで含めて業務を再設計する必要があります。

これはシステム開発というより、Operating Model Designに近い仕事です。

なぜFDEが必要になるのか

この領域でFDE（Forward Deployed Engineering）が重要になる理由も、ここにあります。

Agentic AIは、会議室で要件定義して完成するものではありません。実際の業務へ入れて初めて、「この判断は人間に残したほうがいい」「このデータにはAgentをアクセスさせられない」「ここで例外処理が発生する」「現場ではこのフローを使っていない」といった事実が見えてきます。

だから、要件定義 → 開発 → 納品だけではなく、現場理解 → 委任設計 → 実装 → 利用 → 観測 → 再設計というループが必要になります。

OpenAI自身も、Enterprise AIの制約はモデル性能だけではなく、Workflow Redesign、System Integration、Change Managementなどにあると説明しています。

FDEの価値は、単に「顧客の近くにいるエンジニア」ではありません。

BusinessとEngineeringの間で、このループを回し続けること。

ここにあります。

AI時代の企業競争力は「モデル」だけでは決まらない

これからAIモデルはさらに進化します。そして優れたモデルは、多くの企業が利用できるようになります。

Google CloudはすでにGemini Enterpriseを、Agentの開発・Orchestration・Governanceまで扱うプラットフォームへ拡張しています。GitHubのCoding Agentも、Issueを渡すとバックグラウンドで作業し、Pull Requestとして結果を返す方向へ進んでいます。

つまり「AIが実行できること」自体は急速にCommodity化していきます。

そのとき企業間の差になるのは、どの仕事をAIへ任せるか。どの権限を与えるか。どこに人間を残すか。どう安全に実行させるか。そして、その仕組みをどれだけ速く改善できるか。ではないでしょうか。

AI Transformationとは、AIを導入することではありません。

人間だけで仕事をしていた会社を、人とAIが一緒に仕事をする会社へ作り変えること。

Agentic AIが「回答」から「実行」へ進むほど、この違いは大きくなります。

そしてこれから企業がAI Agentを導入するとき、最初に考えるべき問いは、「どのAIを使うか？」ではなく、「このAIに、何を任せてよいのか？」になるはずです。

---

ELYSAI Insight

ELYSAI株式会社では、AIXをAIツール導入ではなく、人・AI・業務プロセス・システムの役割を再設計する取り組みとして捉えています。

FDEが現場に入り、BusinessとEngineeringをつなぎながら、小さく実装し、実際の利用から学び、改善する。

AIX × FDE × Engineering。

Agentic AI時代には、「AIを作る力」だけではなく、AIに安全に仕事を任せられる企業を設計する力が、より重要になると考えています。

参考情報

• OpenAI — How enterprises put AI to work（2026年8月12日）
• OpenAI — AI-native company workflows（2026年9月1日）
• Anthropic / Google Cloud — Production AgentのMonitoring・Securityに関する解説
• Google Cloud — Agent Gateway（2026年5月5日）
• Google Cloud — Gemini Enterprise Agent Platform（2026年4月22日）
• Reuters — AI Agent向け決済Trust Frameworkに関する報道（2026年9月10日）