# 会社の仕事をAIエージェントに任せるには 構成図で選ぶ作り方とチーム運用

- 媒体: 知能圏（CHINOUKEN）
- 公開日: 2026-10-06
- カテゴリー: エージェント・ソフトウェア
- タグ: AIエージェント、企業導入、アーキテクチャ、dots、AWS、チーム運用
- 想定読了時間: 約18分
- 調査基準日: 2026年10月6日
- 出典: 63件（末尾の「参照リンク」に番号順で記載）
- ページ: https://www.chinouken.com/articles/enterprise-agent-architecture
- このMarkdown: https://www.chinouken.com/articles/enterprise-agent-architecture.md
- 利用条件: 引用する場合は出典として「知能圏（chinouken.com）」と該当ページのURLを明記してください。本文の再配布は行わず、要約や引用の範囲で使ってください。

調査や資料作成を個人用エージェントへ任せるOpenAIのdotsから、部署で共有するエージェント、業務フローに組み込むAI、自社のPCやクラウドで動かす方式まで。6つの導入パターンを構成図で比べます。社員の利用権限とAIの実行権限を分け、AWSでブラウザー操作を制限する具体案、米国企業の導入例、Businessの料金を整理しました。情報は2026年10月6日時点です。

![会社の仕事をAIへ。依頼の入口と作業場所は別に選ぶ。SlackやTeamsの依頼を専用PCまたはクラウドへ渡す構成](https://www.chinouken.com/images/articles/enterprise-agent-architecture/hero.png)

## 6つの導入パターンから構成を選ぶ

経理担当者が「期限を過ぎた未入金を調べて、営業担当への確認文を作って」と頼む場面を考えます。通常は担当者が会計システムと顧客情報を行き来し、入金済みなら対象から外し、状況が不明なら確認先を調べます。AIエージェントは、操作の結果に応じて次に使う道具を選ぶソフトウェアです。この例では、入金状況の確認から営業担当へ送る文面の下書きまで進めます。

企業向けのアーキテクチャは、その仕組みをどこへ置き、何につなぐかという構成です。一人の下書き作成なら一式を備えた製品で始められます。経理部の共通業務にするなら、依頼を受け付ける社員を限定し、途中で止まった仕事も記録します。誤送信を防ぐには、AIの権限を請求情報の閲覧と下書きまでに絞り、送信や更新を人の承認後に動く別の処理へ渡す設計が考えられます。

どこから使い始め、どこまで自社で管理するかによって、6つの導入パターンに整理しました。たとえば「共有窓口から自社クラウドの業務フローを呼ぶ」と組み合わせられます。OpenAIのdotsは、調査や資料作成を個人で頼める完成品のサービスです。dotsで使う一体のエージェントをdotと呼び、図の「完成品」の例にしています。APIはプログラムから別の機能を呼び出す窓口です。そのうち判断と会話の継続を提供者が管理するものを、ここでは管理型APIと呼びます。

![完成品を使う、共有窓口を作る、業務フローへAIを挟む、専用PCを使う、判断の継続をAPIへ任せる、クラウド部品から自社で組む、という6構成の比較図](https://www.chinouken.com/images/articles/enterprise-agent-architecture/architecture-map.png)

*導入の起点を示す概略図です。共有窓口の裏で業務フローを動かすなど、複数の構成を組み合わせられます。*

| 導入の起点 | 向く仕事 | 自社が決める主な部分 |
| --- | --- | --- |
| 完成品を使う（dotsなど） | 担当者の調査、資料、下書き | 接続アカウント、任せる範囲、成果の確認 |
| 社員の共有窓口を作る | 社内問い合わせ、部署の共通担当 | 利用対象者、参照資料、本人ごとの操作権限 |
| 業務フローへAIを挟む | 申請、分類、照合、承認付きの更新 | 固定する手順、AIへ任せる判断、例外の戻し先 |
| 専用PCを作業担当にする | 既存のデスクトップアプリ、社内ファイル | 端末、画面操作、同時実行、障害復旧 |
| 判断の継続をAPIへ任せる | 独自サービスでの長い調査や作業 | 受付、業務の道具、承認、正式な処理記録 |
| クラウド部品から自社で組む | 独自の権限、通信、復旧要件がある業務 | コード、保存状態、実行環境、監視の組み合わせ |

一人の担当者が自分の調査や下書きに使うなら完成品を試し、複数の社員が依頼するなら共有窓口を選びます。順序を固定できる仕事は業務フローを中心にし、APIで操作できない工程にブラウザーや専用PCを追加します。独自コードが必要なら、判断と会話の管理をAPI提供者へ任せるか、自社のクラウド部品で持つかを決めます。

## dotsを個人用に導入する場合の料金と範囲

完成品から小さく始める具体例が、OpenAIが2026年9月29日に発表したdotsです。一人が持つエージェントをdotと呼び、GPT-6 Astraと専用のクラウドコンピューター・ブラウザーで動きます。クラウドの仕事は本人のPCを閉じても継続でき、日時を指定した実行も可能です。

手元のファイルやアプリを使わせたい場合は、本人のPCも接続できます。この経路ではChatGPTアプリを通してPCを使うため、そのPCをオンラインに保ち、アプリを開いておく必要があります。

### 個人用と共有担当の違い

組織向けの専門dotは、個人用dotとは別にOpenAIが対象企業へ試験提供する、共有業務向けの仕組みです。

| 利用経路 | 誰が依頼できるか | 2026年10月6日時点の条件 |
| --- | --- | --- |
| 個人用dotへのSlack接続 | そのdotを持つ本人 | 他の参加者の発言は文脈として読めても、全員から新しい仕事を受ける共有窓口にはならない |
| 個人用dotへのTeams接続 | そのdotを持つ本人 | 招待制アルファ |
| 組織向けの専門dot | 公開案内では具体的な依頼者の範囲を確認できない | 個人用の契約に含まれると見積もらない |

そのdotを持つ本人がSlackの会話へdotを招待しても、他の社員が新しい仕事を依頼できるようにはなりません。

### ChatGPT Businessの席料金

ChatGPT Businessは旧ChatGPT Teamの名称です。一人へ割り当てるライセンスを「席」と呼び、StandardとPremiumを同じワークスペースで混在させられます。

| Businessの席 | 月払い | 年払いの月額換算 | dotsの対象 |
| --- | --- | --- | --- |
| Standard | 1人25米ドル | 1人20米ドル | 現行の個人用dotの対象外 |
| Premium | 1人125米ドル | 1人100米ドル | 割り当てられた本人の最初のdotを含む。Standardの5倍の利用枠 |

最低二席なので、Standard一席とPremium一席なら、月払いは月150米ドル、年払いは月額換算120米ドルです。米ドルの表示価格を合算した金額で、税・地域価格は購入画面で確認します。Business Premiumへのdots提供は段階的で、購入と利用開始が同時とは限りません。

Premium一席を買っても、Standardの社員全員が個人用dotを使えるわけではありません。追加のdotや作業量の拡張は将来予定で、確認した案内には価格がありません。BusinessにOpenAI API利用料は含まれません。

## チームで使う入口と権限を決める

共有運用では、「エージェントを作れる人」「仕事を頼める人」「業務システムで操作できる範囲」を分けます。Slackのチャンネルへ参加できても、経理データを読んだり、支払いを承認したりする権限まで与える必要はありません。

![依頼する社員の本人確認と所属部署の確認を行い、本人に許可された接続と、承認を伴う業務専用アカウントの接続を分ける図](https://www.chinouken.com/images/articles/enterprise-agent-architecture/team-access.png)

*本人の資料検索と、部門の承認済み処理では、実行に使う権限を分けられます。共有受付は依頼者を確定し、結果を誰へ返すかも制限します。*

### 共有窓口を備えるサービス

| サービスと役割 | 社員への届け方 | 権限設計で見る点 |
| --- | --- | --- |
| Microsoft Copilot Studio／業務エージェントの作成 | TeamsやMicrosoft 365へ公開 | 道具の接続を作成者の認証で動かすか、利用者本人の認証で動かすか |
| Google Gemini Enterprise／社内AIの入口 | 社員向けWeb画面から自作エージェントも利用 | 自作部分の実行基盤は別途必要。利用者の情報と下流システムの認可を接続 |
| Glean Agents／社内情報を使う共有エージェント | 社内ライブラリーやSlackへ公開 | 使う権限と編集・公開権限を分離。Slackでは返答の公開範囲も選択 |
| Salesforce Agentforce／顧客管理業務のエージェント | Salesforceの業務画面や接客経路へ組み込み | 実行用ユーザー、レコードの閲覧範囲、許可する操作を限定 |
| ServiceNow AI Agents／社内の申請・対応業務 | ServiceNowの業務フローへ組み込み | AI Agent Orchestratorで役割を分担し、AI Control Towerで管理対象を把握 |

Microsoft 365中心の社内業務、Salesforce中心の顧客対応、ServiceNow中心の申請業務なら、既存の入口と権限を引き継げる範囲から検討できます。

共有時に見落としやすいのは返答の見える範囲です。Gleanは、Web画面や本人だけに見えるSlack応答では利用者本人の資料権限を使います。一方、チャンネル全員へ見せる設定では、組織内で広く閲覧可能な資料や対象チャンネルの発言などを参照します。個人の秘密資料を取得して、そのまま共有チャンネルへ返す構成にはしません。

自社でSlack・Teamsの受付を作る場合も、署名やログインを検証して依頼者と部署を確定し、業務ごとに利用可否を判定します。AIが出力した社員名は本人確認の代わりにしません。受付側のプログラムは、本人向けの結果を依頼者本人へ返し、共有チャンネルには参加者全員へ開示できる情報だけを返します。業務専用アカウントによる処理結果にも、この公開範囲の判定を適用します。

## 業務フローにAIを挟む構成

申請の受付、承認、台帳への登録など順序が決まる仕事は、業務フローを中心に組めます。その途中で、問い合わせの分類や資料の読み取りだけをAIへ任せます。AIに次の操作を選ばせる範囲も設定でき、予想外の入力は業務担当者の確認待ちへ戻せます。

基本の接続は「受付 → AIで調査・分類 → 人の承認 → 決めた操作で更新 → 結果記録」です。すべての工程をAIが自由に選ぶ必要はありません。

| サービス | AIと業務をつなぐ方法 | チーム運用で確認する条件 |
| --- | --- | --- |
| Dify | 画面で処理を組み、Human Inputという人の入力待ちを挿入 | 公開アプリの利用制限と、作成者の編集権限を別に設定。利用する版ごとの認証・権限機能を確認 |
| n8n | 業務アプリの接続とAIの道具をワークフローで接続 | 送信などの道具ごとに、人の承認を要求。SlackやTeamsへ承認依頼を送れる |
| Workato Agent Studio | エージェントが、レシピと呼ぶ既存の自動化手順を実行 | Slack・Teamsから利用。共通接続か、依頼者本人の認証かを選ぶ |
| Zapier | アプリ連携の手順とAI処理を接続 | Team・Enterpriseの共有権限と接続アカウントを確認。AgentsからAI by Zapierへの移行案内あり |
| UiPath Maestro | AI、画面操作ロボット、人の作業を一つの業務へ配置 | 人の承認はAction Centerへ、画面操作はRobotへ渡して完了を待つ |

たとえばn8nの承認機能では、AIが送信ツールを選んでも、人が宛先と入力値を確認するまで実行を止められます。Workatoでも、利用者本人の認証を使う接続を設定できます。導入時は「承認してください」という指示文に加えて、道具を実行する側が承認前の呼び出しを拒否する設定を選びます。

## 専用PCを作業担当にする構成

古いWindowsアプリや社内の共有フォルダーを扱うなら、専用PCや仮想デスクトップを作業場所にできます。この構成では、クラウドのAIモデルが次の操作を判断します。PC上の実行ソフトであるCodex（OpenAI）やClaude Code（Anthropic）が指示を受け、ファイルやコマンドを扱い、画面操作ツールを呼び出します。クリックと入力を実行するのは、その画面操作ツールです。

共有受付とPC上のエージェントの間には、自社で書く「起動プログラム」を置きます。このプログラムが依頼を取り出し、Codex SDK／Claude Agent SDKという開発用部品を使って、Codex／Claude Codeを起動・継続します。起動プログラムとエージェントは別のプログラムです。

![共有受付から自社製の起動プログラムが依頼を取り出し、PC上のCodexやClaude Codeを起動して画面操作ツールで業務アプリを動かす図](https://www.chinouken.com/images/articles/enterprise-agent-architecture/pc-worker.png)

*自社実装の配置例です。PC上の起動プログラムがエージェントを呼び出し、エージェントはクラウドのモデルへ作業の状況を送り、操作の指示を受け取ります。端末の起動・更新・復旧は自社が管理します。*

| 部品 | 担当すること |
| --- | --- |
| 共有受付と作業記録 | 依頼者を確認し、仕事を順番待ちへ入れ、受付済み・実行中・承認待ちを保存 |
| 自社製の起動プログラム | 依頼を取得し、SDKでエージェントを起動。同じデスクトップの同時操作を防ぐ |
| PC上のCodex／Claude Code | クラウドのモデルから操作の指示を受け、ファイル・コマンド・画面操作ツールを使う |
| 画面操作ツールと業務用アカウント | クリック・入力を実行し、アクセスできるアプリとデータを限定 |

図は独自実装の構成例です。PCの更新、故障、画面ロック、ログイン切れへの対応は自社に残ります。多要素認証は人へ引き継ぎ、業務用端末へ個人のブラウザー履歴や認証情報を混在させない運用にします。

なお、SlackからOpenAIのクラウド開発環境Codex Cloudへ作業を委任する公式連携は、この自社PC方式とは別経路です。Claude CodeのRemote Controlは、Claude Codeの利用者が手元で開始したセッションを遠隔操作する機能です。どちらも、導入しただけで部署共通のPC操作受付が完成するわけではありません。

## 判断をAPIへ任せる構成と自社で組む構成

独自の共有窓口を作る場合、判断と会話の状態を誰が管理するかを選びます。管理型APIでは、AIが判断を繰り返す処理と会話の状態を提供者へ任せます。OpenAIのAgents APIやAnthropicのClaude Managed Agentsがその例です。自社で組む方式では、その処理と状態管理を自社コードとクラウド部品で実装します。

![提供者が判断と会話を管理するAPI方式と、自社コードで判断と状態を組むクラウド方式の比較図](https://www.chinouken.com/images/articles/enterprise-agent-architecture/managed-custom.png)

*上段では判断の継続をAPI提供者へ任せます。下段では自社コードをクラウドの実行基盤へ配置します。どちらも業務の承認と完了記録を自社で構成します。*

| 作り方 | 提供者へ任せる範囲 | 自社に残る部分 |
| --- | --- | --- |
| OpenAI Agents API | モデルと道具の反復、会話・文脈の管理、エージェント実行の復旧 | 受付、業務ツール、実行環境の選択、承認、業務の完了記録 |
| Claude Managed Agents | 会話の継続と実行を管理するAPI。自社管理の実行環境も選択可能 | 自社の業務接続、利用者の権限、承認と結果の照合 |
| 自社コード＋実行サービス | クラウド側の計算資源や保存サービス | 判断の組み方、道具、途中再開、権限をコードと設定で実装 |

Agents APIでは、作業の実行環境を自社のPCやクラウド上のコンテナーに置けます。図の「業務の道具・実行環境」に当たり、そこへ指示を受けてコマンドやファイル処理を行うプログラムを導入します。自社側からOpenAIへ外向きに接続して指示と結果を交換するので、社内PCの受信用ポートを外部へ公開せずに構成できます。環境の起動・停止とファイル保存は自社が管理します。

確認時点でAgents APIはパブリックベータ、Claude Managed Agentsもベータです。OpenAI Agents APIは会話などの状態をOpenAI側に保持し、同社のZero Data Retention（入力・出力の保持を制限する設定）の対象外です。顧客データの保存地域を指定できるのは米国のみで、日本国内保存は選べません。実行環境を自社へ置いても、この保存条件は変わりません。

Claude Managed Agentsも会話履歴や出力をAnthropic側に保持し、Anthropicが提供するZero Data Retentionの対象外です。処理地域や外部ツールの保存条件は、各社の案内で別に確認します。

### 自社で組む場合のクラウド部品

自社実装では、判断処理をコードで作る枠組みと、配置先のクラウドを選びます。LangChain社のLangGraphは、AIの判断と決められた手順を混ぜ、状態保存や人への確認を組み込む部品です。LangSmithは、その実行追跡・評価・配置を助けます。社員用の画面や接続先の権限は別途構成します。

自社実装は「受付」「判断」「状態保存」「実行環境」「業務接続」の5役割で比べると整理できます。開発用の部品集をSDK、別の仕事から隔離した実行場所をサンドボックスと呼びます。

| 基盤 | 受付・判断 | 状態保存・実行環境 | 業務接続で自社が決めること |
| --- | --- | --- | --- |
| Cloudflare | Workersで受付、Agents SDKで判断処理 | Durable Objectsで状態、Workflowsで中断・再開、Sandboxでコード実行 | 外部サービスの認証と、呼べる操作の限定 |
| Vercel | Chat SDKでチャット連携、AI SDKで判断処理 | `Workflow SDK`で承認待ち・再開、Sandboxで隔離実行 | 接続先、承認条件、書き込み権限 |
| AWS | API Gatewayなどで受付、AgentCore Runtimeで自社エージェントを実行 | Step Functionsで進行、DynamoDBで記録、AgentCore Browserで画面操作 | Gateway・Identityと業務側の権限を接続 |
| Google Cloud | ADKという開発部品で実装し、Gemini Enterpriseへ登録可能 | Gemini Enterprise Agent PlatformのAgent Runtimeなど | 利用者の認可、接続先、モデルへ渡す情報 |
| Microsoft Azure | Foundry Agent Serviceへ自社コードを配置し、Teamsなどへ配布 | 実行・会話管理と監視をサービスで提供 | Entraによる本人確認、道具、仮想ネットワークの対応範囲 |

社員が使うGemini Enterpriseの画面と、コードを動かすAgent Runtimeは別の役割です。AzureのFoundryにも、設定だけで作る方式と自社コードを置く方式があり、上表は後者を指します。

## AWSでブラウザーと送信権限を分ける

AWSでは、エージェントのプログラムとブラウザーを別々に動かせます。AgentCore Runtimeはプログラムの実行場所、AgentCore Browserは隔離されたブラウザーです。Runtimeの代わりに、コンテナーという実行単位で自社プログラムを動かすECS/Fargateを使い、AgentCore Browserへ接続する構成も選べます。

以下は、未入金確認を想定した筆者の構成案です。AgentCore Browserで自社用のブラウザーを作成し、通信と操作記録を設定します。AIは閲覧用の業務アカウントで調査し、送信に必要な認証情報は別の実行プログラムだけが持ちます。

AWSが提供するのは、実行基盤や進行管理などの部品です。依頼の検証、承認画面、承認内容の照合、送信処理は自社で実装します。

![AWSの進行管理から閲覧用のエージェントとブラウザーを呼び、自社で実装する承認・照合処理を通して別の実行権限で送信する構成図](https://www.chinouken.com/images/articles/enterprise-agent-architecture/aws-permissions.png)

*AWSの提供部品に、自社製の承認画面・照合・送信処理を組み合わせる設計案です。閲覧側へ送信の認証情報を渡さず、承認内容を保存してから別の実行役を呼びます。ネットワークの配置は次の図で示します。*

| 配置する部品 | この構成での役割 |
| --- | --- |
| API Gateway＋Lambda | Slack・Teamsの依頼を検証し、依頼者と部署を確定 |
| Step Functions＋DynamoDB | 進行と承認内容を保存。標準タイプのワークフローの待機機能で承認後に再開 |
| AgentCore Runtime＋Browser | 調査と下書き。請求システムには閲覧専用アカウントで接続 |
| 承認画面 | 経理責任者の本人確認と承認権限を検査し、宛先・文面・請求番号を固定 |
| AgentCore GatewayのPolicy＋送信用Lambda | 呼び出し権限と保存済みの承認内容を検査し、別アカウントで送信 |

AIが`approved: true`と返しても送信許可にはしません。送信用プログラムが、保存された承認者、宛先、文面、有効期限と今回の操作を照合します。変更があれば承認を取り直します。調査側には、送信用の認証情報を取得する権限や、承認規則を変更する権限を与えません。

GatewayのPolicyが検査するのは、Gatewayを通る道具の呼び出しです。ブラウザーが送信権限付きでログインしていれば、直接ボタンを押す経路が残ります。閲覧専用アカウントを用意できないシステムでは、まず下書きまでを自動化し、送信は人が別の画面で行う構成が候補になります。

### ブラウザーをどこへ置くか

| 選択肢 | 任せられる部分 | 自社に残る部分 |
| --- | --- | --- |
| AgentCore Browser | ブラウザーの隔離・セッション、記録や人への引き継ぎの機能 | 業務アカウント、通信先、保存記録の権限と保持期間 |
| Fargateなどでブラウザーも自社運用 | コンテナーの実行基盤 | ブラウザー更新、起動・終了、接続、記録、障害対応 |
| Browserbase＋Stagehand | Browserbaseの遠隔ブラウザーを、操作用部品Stagehandから利用 | 業務承認、アカウント分離、外部サービスへ渡すデータの条件 |

AWSが公開するブラウザー操作の参照実装では、依頼を一時保存する待ち行列サービスSQSを使い、Fargate上の操作プログラムからAgentCore Browserへ接続します。「ブラウザーをコンテナーで動かす」以外に、「操作プログラムだけ自社で動かし、ブラウザーを借りる」構成があるわけです。これはAWSの参照実装で、後述する顧客の本番事例とは区別します。

## AWSの通信制限と停止項目を整理する

ブラウザーの隔離と、通信先の制限は別の設定です。自社用の仮想ネットワークであるVPCへRuntimeとBrowserをそれぞれ接続し、許可した経路だけを使わせます。次の図は、外部サイトへの経路とAWSサービスへの経路を分けた構成案です。

![AWS管理のRuntimeとBrowserを個別に自社VPCへ接続し、外部サイトへの通信検査とAWSサービスへの専用接続を分けた図](https://www.chinouken.com/images/articles/enterprise-agent-architecture/aws-network.png)

*筆者の構成案です。AWS管理の実行環境を、ENIと呼ぶ自社VPC内のネットワーク接続口につなぎます。外向きの経路はNetwork Firewallを必ず通すよう設定します。図は主な通信先を示し、実際にはDNSなども含めて経路と規則を確認します。*

| 守る対象 | 設定する場所 | 残る注意点 |
| --- | --- | --- |
| 外部への通信 | VPCの経路をNetwork Firewallなどへ集約し、宛先を制限 | NATは外へ出る経路。単独ではドメインを制限しない |
| ブラウザーの移動先 | Chromeの管理ポリシーでURLを許可・禁止 | プロキシ設定だけで全通信の経由を保証しない。許可サイトへの情報流出も考慮 |
| AWSの操作 | IAMという権限管理で、各実行役の操作を限定 | 同じFargateタスク内に置いたコンテナーを、独立した権限境界とみなさない |
| 業務システムの操作 | 接続先で閲覧用と送信用のアカウントを分離 | AWS側の最小権限だけでは、ログイン先の管理者権限は弱くならない |
| 道具の実行 | PolicyエンジンをENFORCE（違反を拒否）にし、その中の個別規則をACTIVE（有効）にする | LOG_ONLYは記録だけで拒否しない。AIに制限を解除する管理権限を渡さない |
| 記録と停止 | 作業・承認・送信結果を照合。ブラウザー記録を有効化し、保存サービスS3へ格納 | 新規受付停止、実行停止、ブラウザー終了、業務ログインの取り消しを用意 |

VPC内の構成にしても、画面や文書を外部のAIモデルへ送れば、その情報は外へ出ます。モデルの処理地域、保存条件、記録の閲覧権限も別に決めます。外部のWebページや受信文書には、AIを誤操作へ誘導する指示が混ざる恐れがあります。それを業務命令として扱わず、誤って従っても送信や更新を実行できないよう、権限を制限します。

## 米国の本番事例から何を借りるか

公表資料から学べるのは、どの工程をAIへ渡し、既存の業務システムや人をどこへ残したかです。次の3例は提供者・導入企業の公表内容で、筆者による性能検証ではありません。

| 企業と業務 | 公表されている構成・運用 | 自社へ移せる設計上の手掛かり |
| --- | --- | --- |
| Cox Automotive／車両整備 | 見積もり支援のFleetMateをAgentCoreで運用。Runtime、Memory、Identity、Observabilityで実行・記憶・認証・監視を分担 | 部門ごとに作り直す前に、実行・認証・監視を共通化 |
| Nash／物流の運行対応 | Agents APIを本番の長い業務に利用し、物流の道具と実行環境は自社で保持。製品では提案・確認付き・自動実行の範囲を設定 | 判断の継続を外部へ任せても、配送の操作権限は自社で管理 |
| Ramp／経理・購買 | Accounting Agentで仕訳候補・確認・会計システムへの同期を支援。購買調査のエージェントは調査結果を人の承認工程へ渡す | 調査、承認、正式な登録を分離し、低リスクの操作から自動化 |

Coxの事例資料は、見積もりの所要時間を従来の8〜48時間から30分へ短縮したと報告しています。ただし、整備代金の支払いまで自律化したという実績ではありません。Nashも認証情報や通信経路の詳細は公表しておらず、AWSの構成案をその内部構成と同一視はできません。

Rampでは、経費の自動承認は設定したワークフローに依存します。一方、購買のセキュリティ・法務などの調査エージェント自身は購買を承認せず、調査結果を人の承認工程へ渡します。同じ会社でも、調査と支出の決定では任せる範囲を変えています。

## 承認と二重送信の防止を模擬処理で試す

未入金確認へ導入するなら、閲覧と下書きから始め、次に承認付きの送信を足す順を勧めます。先ほどのAWS構成でも必要になる承認内容の固定と再実行制御を、外部サービスへ接続しない模擬処理で試します。「承認後に文面を変えたら送信を止められるか」「送信先の受理直後に停止しても、再開時に二重登録しないか」の2点です。

筆者は、期限超過・未入金の合成請求データ2件、計20万円を固定入力にして、承認・送信・再実行の制御を検証しました。依頼全体には作業番号を、個々の送信には操作番号を付けます。模擬した送信先は、同じ操作番号の再送には新しい登録を作らず、初回の登録結果を返す設計です。

試したのは、承認内容の固定と、同じ操作番号による重複防止の処理だけです。AgentCore、ブラウザー操作、AWSの権限設定、Slack・Teamsとの実接続は検証していません。

| 操作手順 | 観測結果 |
| --- | --- |
| 承認なしで実行／承認済みの文面を書き換えて実行 | どちらも送信を停止 |
| 模擬した送信先が受理した直後に処理を停止し、同じ操作番号で1回再実行 | 初回と再実行の計2回の送信要求に対し、送信先の登録は1件 |

この模擬処理では、承認後の文面変更を止め、再実行時も送信先の登録を1件に保てました。実運用で送信先が重複登録を防げず、実行結果も照合できない場合は、この再開方法を使えません。ブラウザーで「押せたか分からない」状態になったら、再クリックせず人へ戻します。

構成を選んだら、まず一つの業務について「誰が依頼できるか」「どのアカウントで動くか」「どこで承認を待つか」「失敗時に誰が再開するか」を埋めます。その条件を既存製品で満たせる範囲を購入し、足りない接続と実行だけを追加するのが、筆者の勧める始め方です。

## 参照リンク

1. [OpenAI: dotsの動作と利用条件](https://learn.chatgpt.com/docs/dots)
2. [OpenAI: dotsと組織向け専門dotsの発表](https://openai.com/index/introducing-dots/)
3. [OpenAI: 個人用dotの対象プラン・最初の一体・段階提供](https://help.openai.com/en/articles/20001530-getting-started-with-your-dot)
4. [OpenAI: dotsの権限と企業向けの管理](https://learn.chatgpt.com/docs/enterprise/dots-admin-guide)
5. [OpenAI: dotsのSlackとTeams接続](https://learn.chatgpt.com/docs/dots/channels)
6. [OpenAI: dotsの継続処理と定期実行の条件](https://learn.chatgpt.com/docs/dots/tasks-and-memory)
7. [OpenAI: Businessの料金とStandard／Premium席](https://help.openai.com/en/articles/8801848)
8. [OpenAI: Codexをプログラムから使うSDK](https://learn.chatgpt.com/docs/codex-sdk)
9. [OpenAI: SlackからCodex Cloudへ仕事を委任](https://learn.chatgpt.com/docs/third-party/slack)
10. [OpenAI: Agents APIの機能とデータ条件](https://developers.openai.com/api/docs/guides/agents-api/overview)
11. [OpenAI: Agents APIの構成と実行環境](https://developers.openai.com/api/docs/guides/agents-api/architecture)
12. [OpenAI: 自社管理のサンドボックス接続](https://developers.openai.com/api/docs/guides/agents-api/environments/self-hosted)
13. [Anthropic: Claude CodeのRemote Control](https://code.claude.com/docs/en/remote-control)
14. [Anthropic: Claude Agent SDKのホスティング構成](https://platform.claude.com/cookbook/claude-agent-sdk-07-hosting-the-agent)
15. [Anthropic: Claude Managed Agentsの提供範囲](https://platform.claude.com/docs/en/managed-agents/overview)
16. [Cloudflare: Thinkの実行ループと会話管理](https://developers.cloudflare.com/agents/harnesses/think/)
17. [Cloudflare: AgentsとWorkflowsの組み合わせ](https://developers.cloudflare.com/agents/concepts/workflows/)
18. [Cloudflare: Sandboxと状態の保存](https://developers.cloudflare.com/agents/tools/sandbox/)
19. [Vercel: エージェントを構成する製品群](https://vercel.com/blog/agent-stack)
20. [Vercel: Chat SDKとWorkflow SDKの承認待ち](https://vercel.com/kb/guide/human-in-the-loop-with-chat-sdk-and-workflow-sdk)
21. [Vercel: 隔離したLinux実行環境](https://vercel.com/docs/sandbox)
22. [AWS: RuntimeのセッションとmicroVM](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-how-it-works.html)
23. [Microsoft: Copilot StudioからTeamsへの公開](https://learn.microsoft.com/en-us/microsoft-copilot-studio/publication-add-bot-to-microsoft-teams)
24. [Microsoft: Teamsと業務システムをつなぐ構成例](https://learn.microsoft.com/en-us/power-platform/architecture/solution-ideas/agent-ticket-and-refund)
25. [Slack: イベントへの応答と再送](https://api.slack.com/events-api)
26. [AWS: Cox Automotiveの本番導入と試行の区別](https://aws.amazon.com/solutions/case-studies/cox-auto-case-study/)
27. [OpenAI: Nashの物流業務でのAgents API利用](https://openai.com/index/introducing-the-agents-api/)
28. [Nash: 物流の道具・承認・自動化範囲](https://www.nash.ai/agent)
29. [Ramp: 経理工程への組み込みと利用企業の説明](https://ramp.com/blog/accounting-agent-launch)
30. [Ramp: 経費の承認推奨と自動承認の設定](https://support.ramp.com/use-policy-agent-for-approvals/)
31. [Ramp: 購買調査と人の承認の分離](https://support.ramp.com/getting-started-with-ramp-procurement-policies/)
32. [AWS: 隔離ブラウザーの構成とセッション記録](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/browser-tool.html)
33. [AWS: FargateとBrowserを組み合わせたQA参照実装](https://aws.amazon.com/blogs/machine-learning/accelerating-software-delivery-with-agentic-qa-automation-using-amazon-nova-act/)
34. [AWS: Fargateのタスク間とタスク内の隔離範囲](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/fargate-security-considerations.html)
35. [AWS: Gatewayを通るツールの権限規則](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy-understanding-cedar.html)
36. [AWS: エンジンと個別規則の強制・記録モード](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy-test-a-policy.html)
37. [AWS: 規則の強制を変更できる管理権限](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/policy-enforcement-modes.html)
38. [AWS: RuntimeとBrowserのVPC接続と通信経路](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/agentcore-vpc.html)
39. [AWS: Network FirewallとDNSによる通信先制限](https://aws.amazon.com/blogs/machine-learning/control-which-domains-your-ai-agents-can-access/)
40. [AWS: Chrome管理ポリシーによるブラウザーの制限](https://aws.amazon.com/blogs/machine-learning/control-where-your-ai-agents-can-browse-with-chrome-enterprise-policies-on-amazon-bedrock-agentcore/)
41. [AWS: プロキシ設定とネットワーク強制の違い](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/browser-proxies.html)
42. [AWS: Standard Workflowの承認待ちと再開](https://docs.aws.amazon.com/step-functions/latest/dg/connect-to-resource.html)
43. [AWS: Runtimeの認証情報と権限設計](https://docs.aws.amazon.com/bedrock-agentcore/latest/devguide/runtime-security-best-practices.html)
44. [Microsoft: Copilot Studioの利用者認証と作成者の接続](https://learn.microsoft.com/en-us/microsoft-copilot-studio/configure-enduser-authentication)
45. [Google Cloud: Gemini Enterprise Agent Platformへの拡張](https://cloud.google.com/blog/products/ai-machine-learning/introducing-gemini-enterprise-agent-platform)
46. [Google Cloud: 自作エージェントを社員向け画面へ登録](https://docs.cloud.google.com/gemini/enterprise/docs/register-and-manage-an-adk-agent)
47. [Google Cloud: 現行Agent Runtimeの実行基盤](https://docs.cloud.google.com/gemini-enterprise-agent-platform/build/runtime)
48. [Glean: 共有・編集権限とSlackでの参照範囲](https://docs.glean.com/agents/concepts/sharing-permissions)
49. [Glean: 共有エージェントの動作と道具](https://docs.glean.com/agents/how-agents-work)
50. [Salesforce: Agentforceの実行権限と責任分担](https://architect.salesforce.com/docs/architect/well-architected/guide/agentic-enterprise-trust.html)
51. [ServiceNow: AI Agent OrchestratorとAI Control Tower](https://newsroom.servicenow.com/press-releases/details/2026/ServiceNow-expands-AI-Control-Tower-to-discover-observe-govern-secure-and-measure-AI-deployed-across-any-system-in-the-enterprise/)
52. [Dify: 人の確認で中断・再開するノード](https://dify.ai/blog/the-human-input-node-bringing-human-judgment-into-automated-workflows)
53. [Dify: 企業版のアプリ権限と実行環境](https://ee.dify.ai/releases/)
54. [n8n: AIの道具ごとの実行前承認](https://docs.n8n.io/build/integrate-ai/ai-examples/human-in-the-loop-for-tools)
55. [Workato: チャット受付・業務手順・本人の認証](https://docs.workato.com/en/agentic/agent-studio.html)
56. [Zapier: Team・Enterpriseでのエージェント共有](https://help.zapier.com/hc/en-us/articles/39268320740749-Give-other-Zapier-users-access-to-your-agent)
57. [Zapier: 所有者の変更とAI by Zapierへの移行案内](https://help.zapier.com/hc/en-us/articles/39268342354957-Change-ownership-of-an-agent)
58. [UiPath: AI・画面操作・人の承認の組み合わせ](https://docs.uipath.com/maestro/automation-cloud/latest/user-guide/tasks)
59. [LangChain: 判断と定型処理・状態保存・人の確認](https://docs.langchain.com/oss/python/langgraph/overview)
60. [Microsoft: Foundryの管理型と自社コード型の実行](https://learn.microsoft.com/en-us/azure/foundry/agents/overview)
61. [Microsoft: Foundryの仮想ネットワークと道具の制約](https://learn.microsoft.com/en-us/azure/foundry/agents/concepts/networking-options)
62. [Browserbase: 遠隔ブラウザーとStagehandの役割](https://www.browserbase.com/browsers)
63. [OpenAI: Data controls in the OpenAI platform — application state, ZDR, data residency](https://developers.openai.com/api/docs/guides/your-data)

2026年10月6日時点の公式資料を確認しています。仕様は更新される可能性があります。

---

© 知能圏 https://www.chinouken.com/articles/enterprise-agent-architecture