SaaSのAPIキーをAIエージェントに渡さない｜スコープ付きトークンという設計

AIエージェントに業務ツールを使わせる最短の方法は、SaaSのAPIキーをプロンプトやMCP設定に貼ることです。動きはします。しかしそのキーは、「そのキーでできること全部」を許す常時オファーとして、エージェントのランタイムに置かれ続けます。API連携を本番で回すなら、この既定を反転させる必要があります。

生のAPIキーが抱える構造的な問題

既定が「全部できる」：APIキーそのものには、操作の範囲も、承認の概念もありません。読み取りも書き込みも、キーがある限り区別なく通ります。
漏れやすい場所に置かれる：プロンプト、ローカルのMCP設定、ログ、会話履歴。キーが通る経路が増えるほど、残留・漏えいの面が広がります。
プロンプトインジェクションに弱い：モデルが外部入力に誘導されたとき、キーがその場にあれば、キーの持つ全権限がそのまま攻撃の射程になります。
失効が全か無か：1つのキーを複数エージェントで共有していると、1件の漏えいで全員分を作り直すことになります。

スコープ付きトークンは既定を反転させる

解決策は、生のキーを渡すのをやめることです。APIキーは既定が「全部できる」、スコープ付きトークンは既定が「許可したものだけできる」。ワーカーごとに、触れてよいツール・アカウント・操作の種類を絞ったトークンを1つ発行し、生のSaaS認証情報はサーバー側に暗号化して保管します。エージェントはそのトークンでMCPサーバーに接続し、ロールが許可したツールだけを呼び出します。

スコープ付きトークンで得られるもの

最小権限：ワーカーは業務に必要なツールと操作だけに到達できます。見えないツールは呼び出せません。
面の縮小：生のSaaSキーがプロンプトやローカル設定に一切現れないため、漏えいの経路が減ります。
外科的な失効：あるワーカーのトークンが漏れても、そのワーカーだけを失効でき、他のワーカーやSaaS本体のキーはそのままです。
承認とルーティングを載せられる：トークンに紐づくポリシーで、書き込みを承認制にしたり、正しいアカウントへ振り分けたりできます。

MCP時代の「API連携」の作法

MCPで多くのSaaSがエージェントから叩けるようになったいま、問われているのは「つなげるか」ではなく「どの権限で通すか」です。 freeeやSmartHR、KING OF TIME、CRM、広告アカウント——どれも生のキーを渡す代わりに、スコープ付きトークン越しに、読み取りは自由・書き込みは承認制で通す。これがAPI連携の既定であるべきです。

Grantryでの実現方法

Grantryは、AIエージェントと業務ツールの間に入る権限レイヤーです。各SaaSのAPIキー・OAuthグラント・トークンをサーバー側に集約して保管し、ワーカーにはスコープ付きトークンを1つだけ発行します。許可したツールだけがエージェントに見え、書き込みは承認ゲート越しに実行され、全コールが監査ログに残ります。 Claude CodeやCodexなどのMCPクライアントを、そのワーカートークンでGrantryに向けるだけです。

よくある質問

AIエージェントにSaaSのAPIキーを直接渡すと何が危険ですか？

プロンプトやローカルのMCP設定に置いたAPIキーは、そのキーでできる操作すべてを許す常時オファーになります。プロンプトインジェクションやログ・履歴への残留で漏れれば、キーが持つ全権限が第三者に渡ります。キー自体には操作の範囲や承認の概念がありません。

スコープ付きトークンとAPIキーは何が違うのですか？

APIキーは既定が「全部できる」です。スコープ付きトークンは既定が「許可したものだけできる」です。ワーカーごとに、触れてよいツール・アカウント・操作の種類を絞ったトークンを発行し、生のSaaS認証情報はサーバー側に留めます。

APIキーを渡さずに、AIエージェントから複数のSaaSを操作できますか？

できます。各SaaSの認証情報をサーバー側に集約して保管し、エージェントにはスコープ付きの権限トークンを1つだけ渡します。エージェントはそのトークンでGrantryのようなMCPサーバーに接続し、ロールが許可したツールだけを呼び出します。