第5位．APIキーなどを使った「ダイレクト接続」

　最もシンプルなのが、AIエージェントから利用するツールに直接接続する「Direct Connection」だ。APIキーやサービスIDなど、従来から使われている認証手段を使ってAIエージェントがツールにアクセスするようにする。

　例えば、AIエージェントが外部ツールから情報を取得し、その情報とユーザーから入力されたプロンプトを大規模言語モデル（LLM）で処理して回答を返す、といった構成だ。生成AIやRAG（検索拡張生成）の初期から使われてきた方式で、既存の接続方法をそのまま流用できるため、実装が容易であるというメリットがある。

　一方、ミラー氏によると弱点もあるという。ツールにアクセスするときに使うのはAIエージェント側の資格情報であり、ツール側からは、その背後で操作を依頼したユーザーが誰なのか分からない。

　例えば、ある従業員がAIエージェントに「社内システムから顧客情報を調べて」と依頼しても、ツール側から見えるのはAIエージェントからのアクセスだけだ。その従業員自身に顧客情報を閲覧する権限があるのかどうかを、ツール側で判断できない。

　こうした理由から、初期の生成AI活用では、全従業員が閲覧できる情報や公開情報など、誰がアクセスしても問題になりにくいデータに対象を限定する方法が取られていたとミラー氏は説明する。

第4位．OAuthで「どのユーザーか」を識別する

　第4位は、直接接続の仕組みに認証プロトコル「OAuth」（Open Authorization）を追加する方式だ。

　GitHubやJira、Slackなど、多くのサービスはOAuthの認証に対応している。AIエージェントがツールに接続しようとすると、ツール側がユーザーの認証を求める。認証が完了するとアクセストークンが発行され、AIエージェントはそのトークンを使ってツールを操作する。

　第5位との違いは、「どのユーザーの権限でアクセスしているか」を識別できることだ。標準化されたOAuthの仕組みを利用できるため、ユーザー認証を一から独自実装する必要もない。

　ただし、別の問題が生じるとミラー氏は指摘する。ツール側から見ると、AIエージェントは認証されたユーザーとして操作している。つまり「ユーザーが操作しているのか、AIエージェントがそのユーザーの代わりに操作しているのか」を区別できない。

　ミラー氏はこの状態を「impersonation」（なりすまし）と表現する。ユーザーは識別できるようになった一方で、「どのAIエージェントが、何の目的で操作しているのか」というAIエージェント側の情報が見えないからだ。

　もう1つの問題が、アクセストークンの有効期間だ。設定によっては長期間有効なトークンをAIエージェント側で保持することになる。トークンが盗まれれば、その有効期間中は第三者に悪用される可能性がある。

第3位．MCPでツールごとの違いを吸収する

　第3位は、AIエージェントとツールの間にMCPを導入する方式だ。

　第4位では、AIエージェントがGitHubやJira、Slackなど、それぞれのツールと直接やりとりする。そのためAIエージェント側は、各ツールの接続方法や仕様を個別に理解する必要がある。

　ツールが1つだけなら大きな問題にならなくても、接続先が10個、20個と増えれば、AIエージェント側で扱わなければならない個別仕様も増えていく。

　そこで間に置くのがMCPだ。MCPをAIエージェントとツールの間の「抽象化レイヤー」として利用することで、AIエージェント側は個々のツールの詳細を直接理解する必要がなくなる。

　AIエージェントはMCPとのやりとりを理解し、MCP側が各ツールとの接続を担う。接続先のツールが増えても、AIエージェント側の実装をツールごとに作り込む必要を減らせるため、拡張性や開発効率を高めやすい。

　ただし、この段階では主に「接続方法をどう共通化するか」が改善されている。ユーザーに代わってAIエージェントが操作するという認証上の問題そのものを解消するには、さらに別の仕組みが必要になる。

第2位．「誰」と「どのAIエージェント」の両方を認証

　ユーザーだけでなく、AIエージェント自身も認証する方法だ。

　ミラー氏はここで、「Token Exchange」（トークン交換）と「On-behalf-of」、つまり代理実行の考え方を紹介する。

　ユーザーはAIエージェントに対して「自分の代わりに、この作業を実行してよい」と権限を委任する。AIエージェントも認証されるため、システム側では「誰が依頼したのか」と「どのAIエージェントが実行したのか」の両方を識別できる。

　第4位のOAuth方式では、AIエージェントがユーザーとして振る舞うため、ツール側からAIエージェントの存在が見えにくかった。

　第2位の方式では、「営業部のAさんがAIエージェントXに依頼し、ツールYのデータを取得した」といった関係を把握しやすくなる。単に「AさんがツールYを利用した」という記録だけが残る状態とは異なる。

　これによって、AIエージェントへの権限委任を明確にし、「誰が」「どのAIエージェントを使って」「どの処理をしたのか」を追跡しやすくなる。ミラー氏は、ユーザーとAIエージェント双方を認識できることで、システムの可観測性や透明性を高められると評価する。

　企業で多数のAIエージェントを利用するようになれば、「ユーザーに権限があるか」だけでは管理が不十分になる可能性がある。「そのAIエージェントに、その処理を任せてよいのか」という観点も必要になるためだ。

第1位．長期トークンをVaultに閉じ込める

　最もセキュリティを高めた構成としてミラー氏が紹介するのが、Vaultを利用する方式だ。

　第4位の方式では、ユーザーのアクセストークンを取得し、それを一定期間保持する場合があるとミラー氏は紹介した。しかし、長期間有効な資格情報がAIエージェントやMCPの実行環境に保存されていれば、漏えいした際のリスクも大きくなる。

　そこでミラー氏が提案するのが、長期間保持する必要があるトークンを、資格情報を安全に管理するVaultに保管する方法だ。AIエージェントやMCPが実際にツールへアクセスするときには、Vaultから短期間だけ有効な資格情報を発行する。

　ポイントは、AIエージェントが日常的に利用する環境に長期資格情報を置かないことだ。

　仮に短寿命の資格情報が攻撃者に奪われて再利用されたとしても、有効期限が短ければ、悪用できる時間を限定できる。長期トークン自体はVaultで集中管理し、必要なときだけ短寿命の資格情報を払い出すことで、資格情報の漏えいによる影響を抑えやすくなる。

「つながるか」だけでなく「誰の権限で動くか」を考える

　5つの方式を並べると、AIエージェントとツールの接続設計で考えるべき対象が段階的に増えていることが分かる。

　ダイレクト接続では、「AIエージェントがツールに接続できるか」が中心だった。OAuthを追加すると「誰の権限で接続しているのか」を識別できるようになり、MCPではツールとの接続方法を共通化できる。

　さらにトークン交換と代理実行を導入すると、「誰が、どのAIエージェントに処理を委任したのか」まで識別できる。Vaultを加えれば、認証に使う資格情報そのものをどこに置き、どのくらいの期間有効にするかまで管理対象になる。

　企業でAIエージェントの利用が広がれば、単にAPIやMCPで業務システムと「つながる」だけでは十分とは言えない。ユーザーとAIエージェントをそれぞれどう認証するのか、どこまで権限を委任するのか、資格情報をどう保護するのか――。AIエージェントを本格的に業務へ組み込むほど、こうした接続設計が重要になりそうだ。

本稿は、IBM Technologyが2026年8月16日に公開した動画「5 Ways to Connect AI Agents to Tools: From APIs to MCP」を基に作成しました。