Arcadeで代理の権限が膨らむ原因と対策｜誰の資格で動かすか

「AIエージェントに社内のメールや顧客管理を触らせたいと現場から言われたが、誰のアカウントで動かせばよいのか決められない」「試しに管理者のアカウントでつないだら、エージェントが誰の代わりに何をしたのか、記録を見ても分からなかった」——エージェントの試行が本番に近づいた会社の情報システム部門から、こうした声が増えています。背景には、エージェントが文章を書くだけでなく、社員の代わりにメールを送り、顧客の記録を書き換える場面が現実になったことがあります。こうした「代理の操作」の認証だけを扱う製品に、海外では資金が集まり始めました。米国の Arcade は2026年6月に6,000万ドルのシリーズAを発表しています。とはいえ、製品を入れれば権限の問題が片づくわけではありません。本当は、エージェントに誰の資格を貸し、どこまで貸すかを人が決めて、はじめて委任の仕組みが安全側に働きます。この記事では、2026年10月時点の公式情報をもとに、代理の権限が膨らむ原因と、Arcade のような仕組みを入れるときに情シスが決めることを整理します。

Arcadeは何をする製品か

Arcade は、AIエージェントと、エージェントが触れる業務システムの間に入る「実行の層」を提供する製品です。公式サイトでは、エージェントが Gmail や Slack、Notion、Salesforce などの外部のサービスを操作するための道具（ツール）を用意し、その呼び出しのたびに認証と権限の確認を行う仕組みとして説明されています。公式サイトには8,000以上の、権限を意識した道具がそろっていると書かれており、自社で作った道具や MCP サーバーを持ち込むこともできます（2026年10月時点）。

この製品の芯にあるのは、エージェントを「利用者として」動かすという考え方です。公式ドキュメントによれば、Arcade は OAuth 2.0、APIキー、利用者ごとのトークンといった、外部のサービスにつなぐための資格情報を扱います。ある道具を使うのに必要な許可がまだ無ければ、Arcade が利用者本人に許可を求め、サービスの提供元との間で OAuth の手続きを取り持ちます。つまり、、エージェントに鍵を配るのではなく、頼んだ本人がその都度、自分の権限の一部を貸す形です。

一方で、この製品はエージェントそのものを作る道具ではありません。エージェントの組み立ては LangChain などの開発の枠組みや、各社のエージェント作成の基盤で行い、外部のサービスに触れる部分だけを Arcade に任せる、という分担になります。社員がエージェントを作って配る基盤の選び方は同じ便の Dust の記事に、作られたエージェントを見張る話は Zenity の記事に譲り、この記事では「誰の資格で動かすか」に絞ります。

作っている会社と、国内でまだ知られていない理由

Arcade を提供するのは、米国カリフォルニア州サウスサンフランシスコに拠点を置く会社です。公式ブログによれば、2025年3月に1,200万ドルのシード資金を、2026年6月12日に6,000万ドルのシリーズAを調達しました。シリーズAは米国の投資会社が主導し、モルガン・スタンレーとウィプロが戦略的に出資しています。公式サイトでは、開発チームの出身として認証の専門企業の Okta などの名前を挙げ、MCP の道具の認可に関する仕様づくりに関わってきたとも説明しています。

それでも国内での知名度は高くありません。日本語で検索しても、まとまった解説はほとんど見当たらないのが2026年10月時点の状況です。理由として考えられるのは3つです。1つ目に、公式サイトとドキュメントが英語だけで、日本語の画面や窓口は確認できません。2つ目に、主な利用者がエージェントを組み立てる開発者で、情シスや業務部門の目に触れる製品紹介の場に出てきにくいことです。

3つ目に、日本ではまだエージェントを本番の業務システムにつなぐ段階の会社が少なく、「誰の資格で動かすか」が切実な問題として表に出ていないことです。ただ、エージェントにメールの送信や顧客の記録の更新を任せ始めると、この問題は必ず出てきます。製品を採るかどうかとは別に、代理の権限という考え方そのものは、先に理解しておく価値があります。

「誰の資格で動いたか」が問われる場面が増えた

エージェントが社内の文書を読んで答えるだけなら、権限の問題は「読ませてよい範囲」で済みます。ところが、エージェントが社員の代わりにメールを送る、カレンダーに予定を入れる、顧客管理の項目を書き換える、といった操作をするようになると、問われるのはその操作が誰の権限で行われたのかです。

たとえば、営業の担当者がエージェントに「先週の商談相手にお礼のメールを送って」と頼んだとします。人が自分で送れば、送信者も記録もその担当者です。エージェントが共有のアカウントで送れば、送信者はそのアカウントになり、相手から見ても、社内の記録から見ても、誰が頼んだのかが分かりません。問題が起きたあとに「エージェントが勝手にやった」とは説明できません。

監査の場面でも同じです。顧客の記録が書き換えられたとき、それが担当者の判断だったのか、エージェントの誤りだったのか、別の社員がエージェントを通じて行ったのかを切り分けられなければ、再発の防ぎようがありません。Arcade が公式ブログで、記録を「どのエージェントが、誰の代わりに、どの資源に」の形で残すと説明しているのは、この切り分けのためです。

課題：代理の権限が膨らむと起きる3つのこと

代理の権限が膨らむと、表に出る問題は大きく3つの形をとります。どれも、エージェントが便利に動いている間は気づきにくく、事故や監査で初めて見つかる点が共通しています。

エージェントが、頼んだ本人より広い範囲で動く

新入社員が頼んだ作業でも、エージェントが管理者の権限で動いていれば、新入社員が本来見られない顧客の記録や、他部署の共有フォルダまで手が届きます。本人は悪意なく頼んでいても、エージェントが関係のない記録を読んで要約に混ぜたり、書き換えてはいけない項目を更新したりすると、その結果は本人の権限を超えた操作として残ります。

誰の操作だったかが、記録から分からない

共有のアカウントやサービス用のアカウントで動かすと、外部のサービス側の記録には、そのアカウントの名前しか残りません。エージェントの側に会話の記録があっても、サービス側の記録と結びつけられなければ、どの社員の依頼だったのかをたどるのに手間がかかります。

辞めた社員・異動した社員の許可が残る

本人の権限を委任する方式でも、委任の許可（トークン）が残り続ければ、退職や異動のあとにエージェントが古い権限で動けてしまうおそれがあります。人事の手続きで社内のアカウントは止めても、外部のサービスに出した許可が別に残っている、という形です。

原因の全体像：代理の権限は4か所で膨らむ

3つの課題をさかのぼると、原因は4つの場所に分けられます。共有アカウントで動かしていること、スコープ（許可の範囲）を広く取りすぎていること、トークンの置き場が決まっていないこと、取り消しの仕組みがないことです。Arcade のような委任の仕組みで変わるものと、仕組みを替えても人が決めなければならないものを分けて見ると、導入の判断がしやすくなります。

原因	膨らみ方	委任の仕組みで変わること	情シスが決めること
共有アカウント	全員がいちばん強い人の権限を使う	頼んだ本人の権限で動く	共有アカウントを残す例外の範囲
広すぎるスコープ	とりあえず全部許して後で絞らない	道具ごとに必要なスコープを求める	部署ごとの上限と、許さない道具
トークンの置き場	エージェントの設定や記録に鍵が混ざる	保管庫に置き、モデルに渡さない	保管庫を誰のどこの環境に置くか
取り消しの欠如	退職・異動のあとも許可が残る	道具の付与と取り消しを1か所で管理	人事の手続きと取り消しの結びつけ方

表の右端の列が空いたままだと、委任の仕組みを入れても権限は膨らみます。製品の比較より先に、この列を埋められるかどうかを社内で確かめておくことをおすすめします。以下、4つの原因を順に見ていきます。

共有アカウントは、いちばん強い人の権限を全員に配る

共有アカウントでエージェントを動かすのは、試作の段階ではいちばん手早い方法です。外部のサービスにアカウントを1つ作り、強めの権限を付けて、エージェントに渡せば動きます。問題は、その手早さのまま本番に入ってしまうことです。共有アカウントの権限は、エージェントを使う全員の仕事をこなせるように、いちばん広い仕事に合わせて設定されがちです。

Arcade の公式サイトは、この点について、各操作を「利用者とエージェントの両方に許された範囲」に限ると説明しています。利用者が持っていない権限は、エージェントにも使わせないという考え方です。公式ブログでも、エージェントには利用者が持つ権限だけを、いま行っている操作の分だけ渡し、常に開いている権限を置かない、と書かれています。

ただし、すべての処理を本人の権限に寄せられるとは限りません。夜間に全社の記録を集計する処理のように、特定の人の依頼ではない仕事もあります。こうした処理まで無理に個人の権限で動かすと、担当者が休んだ日に止まります。共有アカウントを残す例外を、処理の名前で一覧にしておくことが、委任への切り替えを現実的にします。強い権限を持つアカウントの運用そのものは、特権IDの管理を扱った記事に譲ります。

スコープは「とりあえず広く」で膨らむ

OAuth のスコープは、利用者が他者に「自分の代わりにここまでやってよい」と認める範囲です。Arcade の公式ドキュメントでも、スコープを「利用者が誰か（この場合はAIエージェント）に、自分の代わりに行うことを認めたもの」と説明しています。そして、道具ごとに必要なスコープが決まっています。公式の例では、Gmail でメールを送る道具には、Gmail の送信のスコープが要ります。

膨らむのは、開発の途中で「あとで要るかもしれない」とスコープを広めに取るときです。メールの下書きを作るだけのエージェントに送信の許可まで渡す、予定を見るだけのエージェントに予定の削除まで渡す、といった形です。一度広く許可すると、利用者は同じ画面を二度と見ないため、広いまま残ります。

道具ごとに必要な許可を求める仕組みは、この膨らみを抑える方向に働きます。必要になったときに初めて許可を求めるので、使わない道具の許可は最初から出ません。それでも、どの道具をどの部署に使わせるかは製品が決めてくれません。送信・削除・共有の設定変更のような道具は、部署ごとに使わせるかどうかを情シスが先に決めておく必要があります。

トークンの置き場が、エージェントの中にあると漏れ方が変わる

OAuth で許可を得ると、エージェントは外部のサービスに入るためのトークンを受け取ります。このトークンをどこに置くかで、漏れたときの被害が変わります。エージェントの設定ファイルや会話の記録の中にトークンが紛れ込んでいると、記録を見られる人や、記録を読み込んだ別の処理にまで鍵が渡ってしまいます。

Arcade の公式ブログでは、トークンを利用者ごとに暗号化した保管庫に置き、言語モデルはトークンに触れない設計だと説明しています。保管庫は Arcade のクラウドにも、自社の環境の中にも置けるとされています。モデルが鍵を持たなければ、外部の文章に紛れた指示でモデルが操られても、鍵そのものを書き出させることはできません。外部の指示による乗っ取りの全体像は、外部の指示による乗っ取りの対策を扱った記事に譲ります。

ここで情シスが決めるのは、保管庫をどの事業者の、どの国の環境に置くかです。製品のクラウドに置けば運用は軽くなりますが、社員の外部サービスの鍵を社外の事業者に預けることになります。自社のクラウドに置けば預け先の問題は消えますが、保管庫の運用と障害の対応を自社で持つことになります。どちらを選ぶかは、扱うサービスの重さで決めます。

取り消しの仕組みがないと、許可は退職後も残る

4つ目の原因は、出した許可を取り消す手順がないことです。社員が退職すると、人事の手続きにしたがって社内のアカウントは止まります。ところが、外部のサービスに対してエージェント用に出した委任の許可は、別の場所で管理されていることが多く、止めた社内のアカウントと連動しない場合があります。

Arcade の公式サイトでは、中央の管理画面で道具の付与・取り消し・版の管理ができると説明されています。また、公式ブログでは Okta や Entra などの既存の認証基盤の上に載る形を示しています。一方で、利用者ごとのトークンを、退職や異動のときにどう失効させるかの具体的な手順は、2026年10月時点の公式の公開資料からは確かめられませんでした。

このため、導入を検討するときは、人事の手続きから委任の取り消しまでが1本につながるかを、提供元への質問と試用で確かめることをおすすめします。認証基盤でアカウントを止めたときに委任も止まるのか、別に操作が要るのか、要るなら誰がいつ行うのかを、手順書の形で決めておきます。

対策の軸：本人の権限を委任し、交わりで絞る

ここまでの原因に対する対策の軸は、2つにまとめられます。1つは、エージェントを共有アカウントではなく頼んだ本人の権限で動かすこと。もう1つは、本人の権限のうち、そのエージェントに許した範囲だけを使わせることです。Arcade が公式サイトで、各操作を利用者とエージェントの両方に許された範囲に限ると説明しているのは、この2つを重ねた形です。

この「交わり」の考え方は、製品を使わなくても設計の基準になります。部長が頼めば部長の権限まで、新入社員が頼めば新入社員の権限まで。そのうえで、議事録を作るエージェントには予定の読み取りとメールの下書きまで、のようにエージェントの役割ごとに上限を決め、本人の権限と重なる部分だけを使わせます。

注意したいのは、本人の権限が広い人ほど、エージェントも広く動けることです。役員や管理者がエージェントを使うときは、交わりを取っても範囲が大きく残ります。強い権限を持つ人のエージェントほど、役割ごとの上限を狭く置くのが、委任の方式での基本的な守り方です。権限を段階的に広げる運用の設計は、エージェントの任務の範囲を設計する記事で扱っています。

本番の前に、利用者の照合を自社に切り替える

委任の方式には、もう1つ見落とされやすい点があります。許可の手続きを始めた人と、許可の画面で承認した人が、本当に同じ人かという照合です。Arcade の公式ドキュメントでは、これを「利用者の照合」と呼び、なりすましを防ぐための確認として説明しています。

公式ドキュメントによれば、新しいアカウントでは Arcade の既定の照合が有効になっており、利用者は Arcade のアカウントにサインインして許可を出します。ただし、既定の照合は試作や個人の利用に向けたものとされ、ほかの人に使わせる前に、自社の仕組みで照合する方式に切り替えるよう案内されています。

同じく、Arcade が既定で用意している OAuth の接続先の設定は、開発や単一の組織での利用向けとされ、多人数で使う本番では、自社で登録した OAuth の接続先の設定と、自社の照合を組み合わせるよう求められています。試作で動いたからといって既定の設定のまま全社に広げると、照合の仕組みが試作の水準のまま残ります。本番に出す条件に、照合の切り替えを入れておくことが、情シスの関所になります。

取り消せない操作の前に人の承認を挟む

本人の権限で、狭いスコープで動かしても、エージェントの判断が誤ることはあります。下書きの誤りなら直せますが、送ったメール、消した記録、実行した支払いは戻せません。そこで、取り消せない操作の直前に、人の承認を挟むのが基本です。Arcade の公式サイトでは、道具の呼び出しの前と後に独自の方針を差し込む仕組みと、破壊的な呼び出しを実行前に見つけるための評価の仕組みが案内されています。

承認を挟む操作の決め方は、次の順で進めると漏れが少なくなります。

承認が多すぎると、利用者は内容を見ずに承認するようになります。取り消せない操作に絞って承認を置き、それ以外は記録で後から確かめる、という分け方が長続きします。

記録は「誰の代わりに・どのエージェントが・何に」で残す

委任の方式に切り替える大きな利点は、記録の粒度が上がることです。Arcade の公式サイトでは、操作ごとに1件の記録を残し、エージェント・利用者・相手のシステムを特定できるとしています。この記録は、社内のログ分析の基盤へ送れるとされています。公式サイトでは SOC 2 への準拠と、SSO・役割ごとの権限・監査ログが標準で含まれることも示されています（2026年10月時点）。

ただ、記録は残すだけでは役に立ちません。決めておきたいのは、誰が、どの周期で、どの記録を読むかです。すべての操作を毎日読むのは無理なので、取り消せない操作、普段と違う時間帯の操作、件数が急に増えた操作のように、読む対象を絞ります。

エージェント側の会話の記録と、外部サービス側の操作の記録をどう突き合わせるかも決めておきます。エージェントが何を頼まれて、どう考えて、どの道具を呼んだのかと、その結果サービス側で何が起きたのかがつながって初めて、誤りの原因が依頼にあるのか、エージェントの判断にあるのかを切り分けられます。記録の突き合わせや異常の候補の抽出はAIに任せてもかまいませんが、問題かどうかの判断は人が行います。

置き場所・ライセンス・費用の増え方

Arcade は提供の形を選べます。公式サイトでは、Arcade のクラウドのほか、自社のクラウド環境、オンプレミス、外部とつながらない閉域の環境、それらの組み合わせに置けると説明されています。公式ブログでは、自社のクラウドとして AWS・Azure・GCP が挙げられています。外部のサービスの鍵を社外に預けたくない会社にとっては、自社の環境に置けるかどうかが最初の分かれ目になります。

ライセンスについては、公式GitHubで公開されている、MCP サーバーと道具を作るための Python のフレームワークがMITライセンスで、スターは約1,100です（2026年10月時点）。ただし、このリポジトリから読み取れるのはフレームワークの条件だけで、認証や実行を担う中心の部分や管理画面の利用条件は別です。無償で試せる部分と、契約が要る部分の境目は、提供元の利用規約と見積もりで確かめる必要があります。

費用は金額ではなく増え方で見ておきます。委任の仕組みの費用は、使う利用者の数、エージェントが道具を呼ぶ回数、つなぐ外部サービスの数、自社の環境に置く場合の運用の手間のどれに比例するかで、全社に広げたときの姿が大きく変わります。試用の段階で、1人のエージェントが1日に何回道具を呼ぶかを数えておくと、全社に広げたときの見積もりの前提が作れます。

委任でやってはいけない形と、人が決める工程

委任の仕組みを入れても、次の形が残っていると権限は膨らみます。導入の前後で、社内の設計に当てはまるものがないかを確かめてください。

• 試作で使った管理者のアカウントを、本番のエージェントにもそのまま残している
• あとで使うかもしれないと、送信・削除・共有の設定変更のスコープを最初から許している
• 既定の照合と既定の OAuth の接続先の設定のまま、社外の利用者や全社員に広げている
• トークンの保管庫の置き場を決めずに、製品の初期設定に任せている
• 退職・異動のときに、委任の許可を止める担当者と手順が決まっていない
• 記録は残しているが、誰も読む周期を決めていない

AIに任せてよい工程と、人が決める工程も分けておきます。エージェントに任せてよいのは、許された範囲の中での下書き・検索・読み取り・集計です。記録から普段と違う操作の候補を挙げる作業も任せられます。

人が決めて持つのは、どの道具をどの部署に使わせるか、役割ごとの上限、取り消せない操作の承認、委任の取り消しです。エージェントに自分の権限を広げる判断をさせたり、承認を自分で省く判断をさせたりしないことが前提になります。MCP の接続そのものの確認項目は、MCP で外部とつなぐ前の確認項目の記事を、鍵を渡す前の確認項目は、AIエージェントに鍵を渡す前に決めることの記事を参照してください。

よくある質問

Q. 委任の方式にすれば、共有アカウントは全部やめられますか

やめられない処理もあります。夜間の集計や全社の定期処理のように、特定の人の依頼ではない仕事は、専用のアカウントで動かすほうが安定します。大事なのは、例外として残す処理を名前で一覧にし、その権限を処理に必要な最小限にとどめることです。

Q. Arcade を使わずに、同じ考え方を実現できますか

考え方そのものは、自社の開発でも実現できます。各サービスの OAuth で本人の許可を取り、トークンを保管庫に置き、道具ごとにスコープを絞り、記録を残せば同じ形になります。ただし、つなぐサービスが増えるほど、許可の手続きと鍵の更新の仕組みを自社で持つ手間が増えます。その手間と、外部の製品に鍵を預ける判断を比べて決めます。

Q. 日本語の業務で使えますか

2026年10月時点で、Arcade の公式サイト・ドキュメントは英語で、日本語の画面や窓口は確認できませんでした。つなぐ先の外部サービス自体は日本語で使われているものが多いため、エージェントが扱う中身は日本語でも、設定と運用の資料は英語で読むことになります。導入するなら、英語の資料を読める担当者を決めておく必要があります。

Q. 社員が自分でエージェントを作る場合も、この考え方は要りますか

むしろ、社員が作る場合ほど要ります。作る人が増えるほど、試作のつもりの強い権限が本番に残りやすくなるからです。社員が作るエージェントの配り方は Dust の記事で、作られたエージェントを見つけて見張る話は Zenity の記事で扱っています。

まとめ

Arcade は、AIエージェントが外部のサービスを使うときに、共有アカウントではなく頼んだ本人の権限を委任して動かすための基盤です。2026年10月時点で日本語の解説はほとんどありませんが、エージェントに社員の代わりの操作を任せる会社が増えるほど、「誰の資格で動いたか」を説明できる仕組みは避けて通れなくなります。代理の権限は、共有アカウント・広すぎるスコープ・トークンの置き場・取り消しの欠如の4か所で膨らみます。委任の仕組みはこのうち多くを技術で抑えますが、例外として残す共有アカウント、部署ごとの上限、照合の切り替え、取り消せない操作の承認、退職時の取り消し、記録を読む人は、どれも人が決めて持つものです。まずは、いまエージェントが使っているアカウントを書き出し、誰の権限で動いているかを1行ずつ確かめるところから始めてみてください。

• 製品の機能・提供形態・ライセンス・資金調達の内容は、Arcade の公式サイト、公式ドキュメント、公式ブログ、公式GitHubを2026年10月15日に確かめた範囲に基づきます。仕様や条件は変わることがあるため、導入前に最新の原文を確かめてください
• 委任の許可の失効・取り消しの具体的な手順は、公開資料で確かめられなかったため、提供元への確認事項として書いています

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。