MCPゲートウェイ MCPass の設計と実装 エンタープライズで AI を「運用できる」状態にする

DataOps Night10での登壇資料です
https://finatext.connpass.com/event/386359/

NotebookLM
https://notebooklm.google.com/notebook/68499c31-8ba2-4811-8e27-a16e9366772e

#dataopsnight

Transcript

1. © 2015 - 2026 Nowcast Inc. DataOps Night10 MCPゲートウェイ MCPass の設計と実装 エンタープライズで AI を「運⽤できる」状態にする 株式会社ナウキャスト Data AI Solutions domain リードエンジニア 六⾞ 光貴  X: @mt_musyu 2026-04-06 1
2. © 2015 - 2026 Nowcast Inc. Agenda 2 01 自己紹介・ナウキャスト紹介 02 エンタープライズMCPの運用課題 03 MCPassアーキテクチャ 04 Observability & Tool Registry 05 DEMO: Claude Code × MCPass × Snowflake 06 まとめ・残課題・今後
3. © 2015 - 2026 Nowcast Inc. 01 ⾃⼰紹介‧ナウキャスト紹介 3
4. © 2015 - 2026 Nowcast Inc. ⾃⼰紹介 六⾞ 光貴 むぐるま ∕ リードデータエンジニア 4 株式会社ナウキャスト リードデータエンジニア データプラットフォームエンジニア 社内データ基盤エンハンス‧顧客向けデータ基盤構築⽀援 webエンジニア出⾝ ⼭とスキーが好き @mt_musyu
5. © 2015 - 2026 Nowcast Inc. Finatextホールディングスについて フィンテックソリューションを提供するFinatextグループの会社です 全グループの従業員は385名。福利厚生や、給与水準は全グループ共通です。 親会社 事業概要 代表者 金融サービスの開発・運営 (4419) データ&AIのプロダクトとソリューション リテール向けオンライン証券会社 少額短期保険会社 木下あかね 辻中仁士 小林紀子 ベトナムの開発チームの統括 Thai Lam 小山宏人 レンディングビジネス 大澤和明
6. © 2015 - 2026 Nowcast Inc. Finatextホールディングスについて Fintech SHIFT 責任者 木下 あかね、売上 13億円 金融サービスの戦略策定から開発・運用 まで一貫支援し、顧客企業と共に優れた ユーザー体験を創出する。 Finatextグループはドメイン制を採用し、6つの事業ドメインが存在 Insurtech 責任者 河端 一寛、売上 15億円 デジタル保険システム「Inspire」と少額 短期保険会社の運営を通じて、保険の顧 客体験を根本から変革する。 Brokerage 責任者 小林紀子、売上 25億円 証券ビジネスプラットフォーム「BaaS」 で、パートナー企業と革新的な証券サー ビスを提供する。 Credit 責任者 大澤 和明、売上 4.6億円 クレジット業務基幹システム「Crest」を 提供し、事業者の新規参入や業務刷新を 容易にする。 Data Service 責任者 辻中 仁士、売上 13億円 「データの商社」として多様なオルタナ ティブデータを提供し、あらゆる企業や 機関の意思決定を支援する。 Data AI Solution 責任者 片山燎平、売上 5億円 データ基盤構築からAI活用まで一気通 貫で支援し、顧客と共にデータドリブンな ビジネスを創出する。 フィンテックシフト 金融インフラストラクチャ ビッグデータ解析 ドメイン一覧 • 資産運用、証券、保険などグループの強みを活かした案件を進めつつ、約4割の売上は非金融から。 • データ基盤と生成AIを軸に幅広い業界にサービスを展開
7. © 2015 - 2026 Nowcast Inc. FinatextホールディングスのAI戦略 Finatext グループ 経済統計‧⾦融データを扱うテクノロジーカンパニー。セキュリティと監査への要求⽔準が⾼い。 AI+ ⾏動規範 2026年2⽉、グループ⾏動規範に「AI+」を追加。全社員が AI を活⽤する前提で動く組織へ。 全社 AI エージェント活⽤ エンジニアだけでなく⾮エンジニアも含め AI エージェントを⽇常業務で活⽤。 MCPass の出発点 「⾮エンジニアが安全に使える基盤」という要件が MCPass 開発の直接の動機。 7
8. © 2015 - 2026 Nowcast Inc. 02 エンタープライズMCPの運⽤課題 8
9. © 2015 - 2026 Nowcast Inc. MCPとは？ https://modelcontextprotocol.io/docs/getting-started/intro Model Context Protocol（MCP）は、AIアシスタントと外部システムを安全に接続するための標準規格です。Anthropic社 が策定し、Linux Foundation で標準化が進められています。 AIと業務システムを安全につなぐためのオープン標準プロトコル （Anthropic 策定‧Linux Foundation で標準化）
10. © 2015 - 2026 Nowcast Inc. エンタープライズMCPの課題 MCPをエンタープライズで運⽤する際に直⾯する4つのリスク 10 🔑 認証情報の漏洩 各端末に散在するAPIキー‧トークンが流出するリスク。 GitHubへの誤アップロード、スクリーンショットへの映 り込みなど。 ⚡ 不正な操作の実⾏ AIが意図しない削除‧更新‧送信を⾏う可能性。⼈間の確 認なしに重要なデータが変更されるリスク。 📤 機密データの流出 AIが外部サービスにデータを送信してしまうリスク。顧客 情報や社内機密が意図せず外部に漏れる可能性。 🔍 追跡不能 問題が起きても「誰が何をしたか」分からない。監査対応 やインシデント調査が困難に。
11. © 2015 - 2026 Nowcast Inc. MCPass エンタープライズにおける MCP運用の課題を解決するプロダクトを作りました
12. © 2015 - 2026 Nowcast Inc. MCPassとは？ 12 MCPass は、AI クライアントと MCP サーバー群の間に配置される 単⼀の統制されたエントリーポイント です。 詳細はこちらのtechblogを参照ください
13. © 2015 - 2026 Nowcast Inc. 03 MCPassアーキテクチャ 13
14. © 2015 - 2026 Nowcast Inc. MCPassの全体アーキテクチャ 14 課題 MCPass の担当コンポーネント セキュリティ・ID 境界 Auth Layer（Cognito + Interceptor Lambda） 可観測性・説明責任 Observability / Audit Layer コスト・Tool Discovery Tool Registry & Catalog 認証情報のライフサイク ル管理 Credential Broker（外部サービスへの認証 情報を一元管理する仕組み。)
15. © 2015 - 2026 Nowcast Inc. 認証認可3層アーキテクチャの全体像 「誰が‧何に‧どんな権限で」アクセスするかを3層で管理。AI エージェントが直接クレデンシャルを持つ「Confused Deputy」問題を構造的に排 除する。 Layer 1 ユーザー認証 AWS Cognito + IdP フェデレーション（Entra ID / Google / Okta / SAML） Layer 2 ゲートウェイ内認可 Interceptor Lambda。JWT 検証 → RBAC チェック → Credential 復号‧注⼊（REQUEST） 未許可ツールを 除去（RESPONSE）。 Layer 3 外部サービス認証 outbound_auth_type: shared / user_delegation / oauth_3lo / oauth_2lo の4⽅式 外部サービスの認証⽅式に合わせて選択できる。 15 クライアントが自分より高い権限を持っているプログラム （代理）を利用することで、本来できないはずの操作を実行 できてしまう問題 今回のケースだとAIエージェントが人間の権限をそのまま 代理して、強い権限で操作してしまうことを指す
16. © 2015 - 2026 Nowcast Inc. Layer 1 ― ユーザー認証（AI クライアント → MCPass） 16 Cursor‧Claude Desktop などの MCP クライアントが MCPass に接続する際の認証フロー。 AWS Cognito + IdP フェデレーションで JWT を発⾏し、⾮エンジニアもブラウザだけで認証できる。 ① ユーザーが MCP クライアントを起動 → MCPass にアクセス要求 MCPass の認証エンドポイントにアクセス。認証が必要な場合は Device Authorization Request を発⾏する。 ② MCPass が Cognito の Device Flow エンドポイントへリダイレクト Cognito が verification_uri と device_code を返却。ユーザーはブラウザで URL を開いてログイン操作を⾏う。 ③ ユーザーがブラウザで IdP 認証（Entra ID / Google / Okta / SAML） 各企業の IdP で認証。シングルサインオン済みであれば追加操作は不要。 ④ Cognito が JWT を発⾏ → MCP クライアントが以降のリクエストに使⽤ JWT には sub（ユーザーID）‧テナント情報が含まれる。Layer 2 の Interceptor Lambda がこの JWT を検証して RBAC を実⾏する。
17. © 2015 - 2026 Nowcast Inc. Layer 2 ― Interceptor Lambda の処理フロー すべての MCP リクエスト‧レスポンスがここを通る。Lambda を選んだのはリクエスト単位のステートレス処理とテナント間分離が容易なため。 REQUEST フェーズ ① JWT 解析（Cognito 公開鍵で検証） ② RBAC 判定（Aurora でユーザー権限を照合） ③ Credential 解決（Aurora + KMS で復号） ④ ヘッダー注⼊（バックエンド MCP に転送） RESPONSE フェーズ ⑤ 未許可ツールを tools/list から除去 → ユーザーは⾃分が使えるツールのみ認識 Confused Deputy 対策 ゲートウェイが認証情報を⼀元管理することで AI エージェントが直接クレ デンシャルを持つ問題を構造的に排除。 Prompt Injection 対策 ゲートウェイ実⾏境界 + ポリシー検証で AI への不正命令注⼊による権限昇格 を防⽌する⼆重境界を実現。 17
18. © 2015 - 2026 Nowcast Inc. Layer 3 ― 外部サービス認証（MCP サーバー → 外部サービス） 18 MCP サーバーが外部サービスを呼び出す際の認証。outbound_auth_type を接続先ごとに設定し、 Interceptor Lambda がリクエストごとに認証情報を復号‧注⼊する。Confused Deputy 問題を構造的に排除する。 shared ― チーム共有 API キー Backlog‧Notion など、チーム共有キーで動く SaaS 向け。 user_delegation ― ユーザー固有 API キー Jira など、ユーザーごとに登録した静的キーを使⽤。ユーザーが MCPass の設定画⾯でキーを登録する。 oauth_3lo ― ユーザー同意 OAuth（3-legged） Snowflake‧Atlassian 向け。ユーザー権限の委任範囲を最⼩化し、「AI がユーザーと同等のアクセス権を持つ」状 態を防ぐ。 oauth_2lo ― サービスアカウント OAuth（2-legged） Client Credentials / JWT Bearer。ユーザー介在なしで動くバッチ‧⾃動化エージェント向け。
19. © 2015 - 2026 Nowcast Inc. 04 Observability & Tool Registry 19
20. © 2015 - 2026 Nowcast Inc. 監査ログに記録する5つの要素 規制対応‧セキュリティインシデント調査‧コスト帰属の3⽤途をカバー。特に①②の組み合わせで「⼈の委任によるエージェントの⾏動」を追跡 できることが⽇本の監査要件への対応で重要。 要素 記録内容 ① 誰が委任したか ユーザー ID + sub claim（JWT から抽出） ② 何のエージェントが エージェント ID + ワークフロー名 ③ どのツールをどのパラ メータで ツール ID + MCP サーバー名 + リクエスト主要 フィールド（機密値はマスク） ④ 結果は ステータス + エラー詳細（失敗時） ⑤ いつ タイムスタンプ 20
21. © 2015 - 2026 Nowcast Inc. Tool Registry & Catalog ツールごとにメタデータを管理し、ワークフロー単位でグループ化することで Tool Overload 問題を解決。 ツールメタデータ owner ツールオーナー（チーム / 担当者） status active / deprecated / preview scope 必要な権限スコープ allowedConsumers 利⽤可能なエージェント / ユーザーグループ 21
22. © 2015 - 2026 Nowcast Inc. 05 🎬 DEMO：Claude Code × MCPass × Snowflake 設計の話はここまで。実際に動かしてみる。 22
23. © 2015 - 2026 Nowcast Inc. DEMOシナリオ Claude Code から MCPass 経由で Snowflake にアクセスするライブデモ。「普通の MCP と何が違うか」を裏側のログで確認しながら進める。特に Step 3 が今⽇⼀番⾒てほしいポイント。 ステップ 内容 設定確認 .mcp.json で MCPass を MCP サーバーとして登録済みの状態を確認 Step 1 Claude Code から⾃然⾔語で Snowflake に問い合わせ Step 2 MCPass 内部の動き（JWT 検証‧RBAC チェック‧ヘッダー注⼊）をログで確認 Step 3 ⭐ 権限外ツールを呼ぼうとする → MCPass が 403 で弾く。Claude Code にはそのツールが⾒えていない Step 4 MCPass ダッシュボードで「誰が‧何のエージェントで‧どのツールを‧いつ」をリアルタイム確認 23
24. © 2015 - 2026 Nowcast Inc. MCPass MCP設定例 エンドユーザーが⾏う設定はたったこれだけ。.mcp.json に mcpass を登録し、初回接続でOAuth Device Flow認証（ブラウザでSSOログイン）。 以降はJWTが⾃動付与 { "mcpServers": { "mcpass": { "url": "https://hogehoge/mcp", "type": "http", "oauth": { "clientId": "xxxxxxxxxxxxxxxxxx", "callbackPort": 1234 } } } } ✓ 初回のみブラウザで SSO ログイン（OAuth Device Flow） ✓ 以降はトークン⾃動付与。ユーザーは⾃然⾔語でツールを呼ぶだけ ✓ Snowflake の認証情報‧ツールフィルタリング‧監査ログはすべて MCPass が⾃動処理 24
25. © 2015 - 2026 Nowcast Inc. 06 まとめ‧残課題‧今後 25
26. © 2015 - 2026 Nowcast Inc. MCPassでできるようになったこと 冒頭で挙げた運⽤課題のうち 6 つを解決。エンドユーザーがMCPassの認証だけ済ませば、その後はさまざまはサービスにアクセスできるように なったことが実運⽤上の最⼤の成果。 カテゴリ 課題 MCPass での対処 認証‧認可 ユーザー認証‧ID 境界 Cognito + Interceptor Lambda（RBAC） 認証‧認可 認証情報の散在 Credential Broker 認証‧認可 外部サービス認証 shared / user_delegation / oauth_3lo / oauth_2lo の4⽅式 セキュリティ プロンプトインジェクション ゲートウェイ実⾏境界 + ポリシー検証（⼆重境界） 運⽤‧統制 可観測性‧監査証跡 CloudWatch Logs → Aurora ETL 運⽤‧統制 ツール過多‧Discovery 崩壊 Tool Registry + ワークフロー単位グループ化 26
27. © 2015 - 2026 Nowcast Inc. 残課題‧今後の開発テーマ 作ってみてわかった次の課題。⽇本特有の監査‧稟議要件に関しても取り組んでいく Prompt Injection本格対策 Read 取得コンテンツが Egress に直結する経路の禁⽌。 AI 経由アクセスの経路別 ACL ⼈の直接操作とエージェント経由では異なる権限を適⽤すべき。 MCP 時代の DLP AI が扱うデータの機密区分に応じた動的フィルタリング。 サプライチェーンリスク管理 外部 MCP サーバーの署名検証‧バージョン管理。 ⽇本特有の監査‧稟議要件（最重要） 監査証跡管理 / 多段階承認フロー / 閉域ネットワーク。 27
28. © 2015 - 2026 Nowcast Inc. We’re hiring! ナウキャストではデータ系職種・エンジニアを絶賛採用募集中です データエンジニア・データサイエンティスト・アナリティクスエンジニア・データプラットフォームエンジニア, バックエンド エンジニア, etc カジュアル面談応募フォームよりお申込みください。 https://forms.gle/r69LwG3cLAjiGvY66 ナウキャストについて詳しく知りたい方は Nowcast Career Nowcast Career
29. © 2015 - 2026 Nowcast Inc.
30. © 2015 - 2026 Nowcast Inc. Appendix: エンタープライズにおけるMCPの課題を解決する既存ソリューションを検証 内製ありきではなく、主要ソリューションを実機検証。判断基準：「マルチテナント対応‧外部 IdP 連携‧承認ワークフロー」の3要件同時充⾜。 ソリューション 結果 理由 Lunar.dev MCPX ✗ マルチテナント未対応 Docker MCP Gateway ✗ 外部 IdP 連携が限定的 Azure APIM △ MCP プロトコルネイティブではない Amazon Bedrock AgentCore △ 最有⼒候補 → 2 つの構造的な壁に突き当たった（次スライド） → AgentCore で進めたが 2 つの構造的な壁に突き当たり内製判断へ 30
31. © 2015 - 2026 Nowcast Inc. Appendix: 壁1 ― AgentCoreの認証‧認可は柔軟性が⾜りない 3 つの制約が重なり、100 ユーザー規模では実⽤にならないとわかった。 Cedar Policy Engine の制約 JWT claims しか参照できず DB ベース RBAC 不可。ロールを DB で動的管理できない。 Token Vault の上限 50 件上限‧増枠不可。100 ユーザー × 3 MCP サーバー = 300 Providers 必要なのに根本的に⾜りない。 OAuth 3LO で PAR（Pushed Authorization Request）が強制 Snowflake‧Atlassian は PAR ⾮対応のため実機検証で接続不可。→ Aurora + KMS で認証情報を⾃前管理する⽅針に転換。 31
32. © 2015 - 2026 Nowcast Inc. Appendix: 壁2 ― 可観測性とTool Discoveryを制御できない コストと設計の 2 つの問題が重なった。 CloudWatch Logs Insights スキャン課⾦ 50,000 件/⽇で $458/⽉。ユーザーが増えるほど爆発し、マルチテナント分離も CloudWatch 上では実現できない。 全ツール露出‧権限外ツール除外不可 MCP サーバーの全ツールがクライアントに露出し、権限外ツールを除外する機構がない。AI が 100 本のツールを並べられて混乱する「Tool Overload」が解消できない。 → 監査ログ基盤 と Tool Registry を⾃前実装する判断をした 32