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

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

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

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

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

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

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

個人用と共有担当の違い

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

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

ChatGPT Businessの席料金

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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、別の仕事から隔離した実行場所をサンドボックスと呼びます。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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