企業に加わる Agent には、パソコンと入館証が必要だ

AI で生成した概念イラストです。パソコンは実行環境、入館証は業務へのアクセスを表します。

新しい社員を迎えるとき、会社はまず二つのものを用意します。

一つはパソコンです。ファイルを開き、ソフトウェアを動かして仕事を進めます。もう一つはアカウントと権限です。社内システムやプロジェクト文書、CRM に入り、自分の担当範囲でデータを参照・更新できるようにします。

パソコンがあってもアカウントがなければ、仕事はなかなか始められません。アカウントがあっても作業環境が整っていなければ、できないことが残ります。

Agent が企業で働くときも、同じ二つの条件に向き合います。

タスクを実行する環境と、業務システムに正当にアクセスする仕組みが必要です。 前者を担うのがサンドボックス。後者に取り組むのが、OpenConnector のような接続・認可ゲートウェイです。

この二つの基盤が、Agent の能力を実際の仕事に結び付けます。

質問に答えるところから、仕事を引き受けるところへ

企業で価値のある仕事は、複数のシステムにまたがります。

明日の顧客との打ち合わせを Agent に準備してもらうとします。カレンダーで参加者を確認し、最近のメールを読み、CRM から商談の経緯をまとめ、議題を会議用文書に書き込みます。

理解力や判断力に加えて、システムへのアクセスが必要です。どこを調べ、誰のアカウントを使い、何を読めて、どこに結果を保存できるかを明確にしなければなりません。

顧客ステータスの更新や招待メールの送信まで任せるなら、必要な権限も変わります。顧客情報を読めることと商談を変更できること、メールを読めることと会社を代表して送れることは、それぞれ別です。

Agent のデータ保護を扱った記事では、十分な業務の文脈が判断の質を支えると述べました。次に考えるべきは、その情報と操作能力を企業がどう渡すかです。

人はアカウントや役割、権限を通じてシステムを使います。Agent にも明確なアクセス境界が必要です。

サンドボックスは Agent の仕事用パソコン

人がパソコン上でソフトウェアを動かすように、Agent にも実行環境が要ります。

コードの実行、表計算ファイルの処理、ファイル生成、ブラウザー操作。サンドボックスは、こうした処理が触れられるファイル、プロセス、ネットワークを制限します。隔離の範囲は実装と設定によって異なります。Anthropic の技術解説では、Agent の実行におけるファイルシステムとネットワークの隔離を説明しています。

会社がパソコンを支給するのと似ています。道具を渡し、その端末での作業範囲も定めます。

ただし、ソフトウェアを動かせる端末が、そのまま会計システムの利用権限を持つわけではありません。コードを実行できるサンドボックスも、CRM や社内システムへの正当なアクセス権を自動では得られません。

サンドボックスが答えるのは、どこで実行し、その環境で何が許されるかです。

業務システムへのアクセスには、もう一つの基盤が必要になります。

ゲートウェイは入館証を支えるアクセス制御

入館証は身元を示し、入退室管理システムが通れる扉を決めます。企業ソフトウェアのアカウントや役割、認可も似た仕組みです。

接続・認可ゲートウェイは、その一部を Agent のために担います。アプリとの接続や認証情報を管理し、呼び出し権限を確認して、許可された操作を対象システムに送ります。

アプリにつながったところから、継続運用の課題が始まります。

• 誰のアカウントで、誰の代理として実行するのか。
• 何を読めて、どの更新操作が許されるのか。
• 外部サービスの認証情報をどこで保護し、更新するのか。
• 失敗した呼び出しの原因や記録を追えるか。
• タスクの終了や担当変更に合わせてアクセスを取り消せるか。

すべてのアプリのキーを Agent の環境へ直接置くと、こうした管理がスクリプト、設定、デプロイ先に散らばります。モデルや実行環境を変えるたびに、同じ整理を繰り返しかねません。

ゲートウェイは接続と認可をまとめて扱う境界を作ります。Agent は許可されたインターフェースを使い、外部サービスの元の認証情報はゲートウェイが管理します。操作は実行時に検査されます。

「読み取りだけにしてください」は指示に書けます。「この呼び出しには書き込み権限がない」はシステムで強制する必要があります。 その制約が、実際の操作を少しずつ委ねる土台になります。

二つの境界が、別々の場所を守る

サンドボックスとゲートウェイは組み合わせて使えます。

ゲートウェイ経由の呼び出しを示す概念図です。各層の制約対象は異なり、実際の能力は構成と設定によります。

基盤	入社時のたとえ	主な役割
サンドボックス	仕事用パソコン	コード実行やファイル処理を行う環境
接続・認可ゲートウェイ	入館証の背後のアクセス制御	利用できるアカウントと業務操作の制限

プログラムはサンドボックス内にとどまったまま、許可された通信先へリクエストを送れます。顧客レコードを削除できる認証情報を持っていても、サンドボックス自身は、その削除が担当業務として妥当かを判断しません。

一方、アプリ呼び出しをゲートウェイ経由にしても、ダウンロードしたファイルやローカルのスクリプト、一時生成物の管理は残ります。それらには適切な実行環境が必要です。

コードやファイルを扱い、複数システムで操作する Agent では、両方の境界が特に大切になります。

企業運用には、ID 管理、タスクの調整、承認、結果の検証も必要です。API だけで完結する仕事なら、独立したサンドボックスが不要な場合もあります。このたとえが示すのは、実行能力と、付与された業務アクセスという二つの基礎です。

接続基盤を長期的に見る理由

デモでは、一度の成功した呼び出しで可能性が伝わります。継続利用では、役割やアカウントが異なる複数の Agent が、同じシステムを安定して使えるかが問われます。

今日の顧客資料担当が明日は別のモデルになり、次に注文担当の Agent が加わるかもしれません。CRM、文書、メールなどの業務システムと、接続・認可の保守はその先も続きます。

Agent ごとに個別実装すれば、API 対応、認証情報の保管、トークン更新、操作制限、障害調査を繰り返します。再利用できる接続基盤があれば、新しい Agent は既存の接続を活用し、役割に合う権限を受け取れます。開発者は業務フローに時間を使え、企業はアクセスルールをそろえやすくなります。

Agent が実務を引き受けるほど、接続と認可は継続的な需要になります。

開発者には共同で取り組む価値のある技術基盤、企業には早期に設計すべき境界です。Agent 産業を見る投資家にとっても、検討に値する分野でしょう。長期的な価値は、接続の重複作業を減らせるか、複数の仕事で再利用できるか、保守と権限管理を継続できるかにあります。

OpenConnector が担うもの

OpenConnector は OOMOL が開発・保守するオープンソースの接続ゲートウェイです。アプリ接続と認証情報を管理し、SDK、CLI、MCP、HTTP から操作を呼び出せます。

Agent や信頼できるバックエンドが操作と接続を選び、ゲートウェイが呼び出し用の認証情報と操作ポリシーを検査します。その後、対象アカウントの認証情報で外部サービスを呼び、結果を返します。

開発者は操作定義、入力項目、必要なスコープを確認し、自社運用環境で許可・拒否する操作を設定できます。機密情報をマスクした実行記録は調査にも使えます。公開ランタイムと操作定義、対応する操作のローカル実行コードを通じて、呼び出し経路を確認・拡張できます。詳しくは OpenConnector ドキュメントをご覧ください。

ゲートウェイのポリシーは、元のアプリのアカウント権限やスコープと合わせて適用されます。閲覧可能な顧客レコードは元システムの設定にも左右され、メール送信には業務上の承認が必要な場合もあります。企業全体の ID 管理や承認との連携が必要です。

まず業務を試すなら OOMOL のホスティング、ゲートウェイや認証情報を自ら管理するなら OpenConnector のセルフホストを選べます。導入方法の比較も参考になります。

共に育てる価値がある基盤

アプリ連携には継続的な保守が伴います。認可方式、パラメーター、エラー、利用制限はサービスごとに異なります。API は変わり、トークンは期限を迎え、社内システムも増えていきます。

その多くは共同で役立てられる仕事です。ページネーションの修正は他の利用者にも届きます。必要なスコープの明記は、次の開発者の調査を減らします。実行コードを公開すれば、確認や改善を経て別の環境でも使えます。

各社が繰り返す接続作業を、エコシステム全体が使える能力として蓄積する。 それがオープンなゲートウェイの意義です。

モデルや Agent が変わっても、公開されたインターフェースと実装を通じて接続を利用し続けられます。自分で管理したいチームには、読めるコードと導入手順が残ります。

オープンソースは検査、修正、共同保守の機会を作ります。安全性にはコードレビュー、正しい設定、運用が欠かせず、外部 API の利用条件も引き続き適用されます。共同開発の価値は、その具体的な仕事を積み重ね、再利用するところにあります。

次の「デジタル同僚」を迎えるために

新しい同僚を迎えるつもりで、Agent に問いかけてみましょう。どこで働くのか。どのシステムを使えるのか。何を読み、何を変えられるのか。

その答えをシステム上で実現できれば、より価値のある仕事を段階的に任せられます。

OpenConnector をこの基盤の一部に育てたいと考えています。日常使うアプリから、必要な操作の追加、認可の不具合修正、パラメーター定義の改善、導入時の報告などに参加できます。

OOMOL 公式サイトで製品と接続方法をご確認ください。まず業務で試すなら、OOMOL Console で一つのアプリを接続し、範囲を明確にした読み取り操作から始めてください。

企業で働く Agent には、仕事をする場所と、適切な権限で入れる入口が必要です。私たちはその入口から、コミュニティと共に作っていきます。