エンタープライズの接続を“規格化”する新星
Fronteggが、SaaS製品とAIエージェントを安全につなぐMCPサーバー『AgentLink』を打ち出したという文脈が浮上しています。
エージェント連携を前提にした企業グレードのプロトコル実装という位置づけで、ID基盤に強いFronteggらしい一手です。
編集部での検索では、現時点で大々的な公式プレスは確認できませんでした。
ただしMCPとエージェント連携の潮流は各社で着実に進行しており、Fronteggのドメインと強く整合する動きです。続報の公開やドキュメント整備が入り次第、当記事もアップデートします。
AgentLinkのねらいと全体像
企業が求める“安全な橋渡し”
『AgentLink』の狙いは「AIエージェント←→SaaS」接続の標準化とガバナンスにあります。
モデル・コンテキスト・プロトコル（MCP）を介して、AI側がツール（APIやデータソース）を適切なスコープで呼び出し、最小権限で業務機能にアクセスできるようにする発想です。
想定される主な特徴
- OIDC/OAuth2連携：FronteggのCIAM基盤と連動し、エージェントに対してきめ細かなスコープと有効期限を持つトークンを払い出し
- ポリシーエンジン：テナント／ユーザー属性（ABAC）やロール（RBAC）により、どのツールをいつ・誰が・どの条件で使えるかを制御
- 監査・可視化：すべてのツール呼び出しとコンテキストを監査証跡として保存し、OpenTelemetryベースの可観測性にも対応
- セキュア・シークレット管理：APIキーや接続情報をボルト管理し、エージェントには表示せず委任実行
- MCPツール定義の集中管理：JSON Schemaでツール仕様を統一し、各エージェント（ChatGPT／Claude／Geminiなど）から一貫した接続を実現
ポイントは、単なるゲートウェイではなくアイデンティティと権限の中核に据えていること。
「誰の代理で」「どの範囲まで」「どのデータに」アクセスできるのかを、監査可能な形で明示します。
MCPのいま：なぜ企業は待っていたのか
MCPは、エージェントが外部のデータや機能へアクセスするためのオープンな共通規格です。
昨年から各種プラットフォーム／SDKが整い、2025年はWindowsへの組み込み発表などで実務の地盤が固まってきました（Microsoft Build 2025の動向を解説する技術記事参照：GMO Developers）。
“We highlight OAuth-based authentication as an important measure for protecting user credentials and explain how Logto can help your product serve as both an MCP server and an identity provider.”
つまり、アイデンティティ基盤×MCPは企業導入の王道です。
Fronteggの強み（CIAM）とMCPサーバーの組み合わせは、まさに要請に応える形だといえます。
アーキテクチャとセキュリティ設計
コア構成（イメージ）
- MCP Gateway：エージェントからのMCPセッションを終端し、定義済みツールを公開
- Identity Bridge：FronteggのOIDC/OAuth2と連携し、エージェント・サービスアカウントに必要最小限のスコープを付与
- Policy Engine：テナント、ロール、属性、時間帯、ネットワーク境界で実行を許可／拒否
- Secrets Vault：APIキーや接続文字列を保護。委任実行でキーを露出させない
- Audit & Observability：全呼び出しを追跡。OpenTelemetry対応でトレースを外部SIEMに連携
運用面ではレート制限、IP許可リスト、ステップアップ認証などの安全策がカギ。
モデル側のプロンプトインジェクション対策として、パラメータのバリデーションやツール出力の検疫も取り入れるべきです（技術解説：Zenn: MCPとAIエージェントが対決）。
はじめてのセットアップ手順
前提
- Fronteggテナント（CIAM）を準備し、対象SaaSのユーザー／ロール設計を整理
- MCP対応クライアント（例：ChatGPT、Claude、Gemini等のエージェント環境）
手順（概要）
- ツール定義：呼び出したいSaaS APIをJSON Schemaで記述し、入力／出力／エラーを明確化
- スコープ設計：読み取り専用、更新系、管理系など粒度の細かい権限を分離
- テナント・マッピング：SaaSのテナントや環境（本番／検証）を明示的に切替できるよう命名規則を統一
- サービスアカウント発行：エージェント接続用のクライアントID/シークレットを作成し、必要なスコープのみ付与
- MCP接続テスト：クライアント側からMCPサーバーURIを登録し、ツール探索→スキーマ検証→最小タスク実行で検証
- 監査・アラート：呼び出しログをダッシュボードで可視化し、逸脱動作にアラートを設定
はじめは読み取り専用のユースケースから。
監査項目やレートの上限が確認できたら、段階的に更新系を解放するのが安全です。
現場で効くユースケース
- CS・サポートの自動回答：CRM／チケシス読み取りをスコープ限定で解放し、エージェントが回答ドラフトを生成
- 営業支援：見込み客データを参照して提案書を下書き。承認フロー通過後にCRMへ自動登録
- IT運用：インシデントの定型エスカレーションやステータス変更を委任実行
- Agent-to-Agent連携：社内エージェントと外部エージェントのA2Aでワークフローを分担（解説：AITC）
いずれも「人の最終承認」を入れるだけでリスクは大きく抑えられます。
AgentLinkは承認待ちキューや実行結果の監査証跡作成を標準化しやすい構造が想定されます。
他社動向との比較視点
SalesforceはAgentforce 3で、エージェントの可視化やMCP連携の強化を掲げています（参考：クラウド Watch／ZDNET Japan）。
一方AgentLinkは、「既存SaaS×複数エージェント」を横断で統制する汎用MCP中枢としての立ち位置が想定されます。
- 縦型（CRMなど特定SaaSに深く組み込む）vs 横型（複数SaaS・複数エージェントを束ねる）
- アプリ内エージェント中心 vs 全社ハブとしてのMCPサーバー
どちらが正しいというより、利用領域と責任分界で住み分けるのが現実的です。
アイデンティティ強者のFronteggが横断ハブに踏み出す意義は小さくありません。
リスク、制約、ベストプラクティス
- データ漏えい抑止：出力フィルタ、PIIマスキング、転送先ドメイン制限、外部書き出しのデフォルト拒否
- プロンプトインジェクション対策：ツール引数のスキーマ検証、システムガードレール、ツール実行のオフスレッド隔離
- 権限肥大化の回避：スコープ分割と短命トークン、承認付き昇格（step-up）
- ガバナンス：全呼び出しの監査証跡とアラート、定期レビュー、ペネトレーションテスト
- 導入順序：読み取り→限定更新→自動更新の順に段階解放。常にロールバック手段を保持
導入の要は「最小権限×監査可能性」。
MCPは標準化の恩恵が大きく、そこにFronteggのID強みが噛み合うと運用負荷が一気に軽くなります。
さらに学ぶ
- Logto: What you need to have in place for AI Agent and MCP Integration
- GMO Developers: WindowsでのMCPサポート動向
- Qiita: MCP実装の徹底解説
- Zenn: MCPとAIエージェントの安全設計
- クラウド Watch: Agentforce 3 国内提供
MCP導入の是非を判断する観点は、こちらの整理も参考になります。
自社要件に照らし、段階導入で成熟度を高めましょう。
まとめ：SaaSとAIの“安全な握手”へ
AgentLinkは、ばらばらだったエージェント接続を「標準プロトコル×IDガバナンス」で束ねる構想です。
企業が求めるのは、速さだけでなく、観測可能で巻き戻せる安全性。そこにMCPとFronteggの相性の良さが光ります。
まずは読み取り系から小さく始め、承認付きの限定更新へ。
監査・可視化を効かせながら、エージェントの生産性を最大化していく。“安全な握手”を土台に、SaaSとAIの統合は次の段階へ進みます。
コメント