全社に広がるMCPサーバーを、 どう安全に管理するか MCPass開発の舞台裏

Postman API Night Tokyo 2026 Summer
https://postman.connpass.com/event/401277/

での登壇資料です

複数チーム・複数プロダクトでMCPサーバーの導入が進む中、アクセス制御や監査ログが伴わない「野良MCPサーバー」が野放しになるリスクが顕在化しました。本セッションでは、この課題感からMCPサーバー管理プラットフォーム「MCPass」を作るに至った経緯と、現場でどう使われ改善が回っているかの生の声をお話しします。

Transcript

1. Postman API Night Tokyo 2026 Summer 全社に広がる MCPサーバーを、 どう安全に管理するか MCPass開発の舞台裏 2026/08/28 株式会社ナウキャスト 取締役 CDO 六車 光貴 © 2015 - 2026 Nowcast Inc. 1
2. 自己紹介 六車 光貴（むぐるま こうき） 株式会社ナウキャスト 今日話すこと 取締役 CDO / MCPass 開発リード 2023 年に株式会社ナウキャストにジョインし、データエン ジニアとしてプロダクト開発やクライアントのデータ基盤構 築をリード 2026 年 6 月、取締役 CDO に就任 同年から、Finatext グループ横断の MCP ゲートウェイ MCPass の開発をリード。グループ内で使うと同時に、社 外にも提供中 • なぜゲートウェイを通すことにしたのか（経 緯） • MCPass の機能と、利用者・管理者から見 た使い方 • MCP サーバーを束ねるゲートウェイと、 3 層の認証認可 • 社内 300 人弱がどう使っているか（現場） • 次に解決する課題: Lethal Trifecta グループ内で使うと同時に、社外に も提供中 https://finatext.com/mcpass/ © 2015 - 2026 Nowcast Inc. 2
3. 1. 全社員が MCP を使えるようにするために きっかけは AI+ と vibe working 2026 年 2 月、Finatext グループは「AI+」を行動規範に加え、エン ジニア以外も AI で仕事をする vibe working を掲げた。背景はこの 2 本に書いてある そのまま配ると、こうなる A チーム B チーム データチーム Cursor に Slack MCP Claude Desktop に Google Drive MCP 自作の Snowflake MCP Finatextグループの AI戦略を 完全解説（ note） https://note.com/fozzhey/n/nc7b68 1faabf6 各チームが正しく動いた結果: API キーは各自の PC ／ 権限は本人のフル権限 ／ ログは どこにも無い 大企業の AI活用はなぜ難しい のか？（ note） https://note.com/110_110_110/n/n 1b53de990def これが「野良 MCP」。配る前に分かっていたので、先に基盤を作った 全社員が AI で仕事をする → AI に業務システムを触らせるには MCP が要る → では、設定を 460 名余りにそのまま配ったら？ 配る前に、基盤を作る © 2015 - 2026 Nowcast Inc. 3
4. 1. 全社員が MCP を使えるようにするために 本人の権限をそのまま AI に渡すと何が起きるか 例 1: 進捗会議のアジェンダを作って 例 2: カレンダー招待のゼロクリック攻撃 • 「最近の社内ドキュメントから議題を整理して」と AI に頼む • AI は自分のドライブにあった 1on1 メモまで読みに行く • 招待の説明欄に悪意ある指示を埋め込む（ Miggo Security、 2026-01） • アジェンダに「来月から A さんが家庭の事情で退職予定」が混入 • 被害者が Gemini に「今日の予定は？」と聞いた瞬間に発動 • Google Drive はビジネスにとっての .env • 非公開の会議情報が外部へ流出、予定の改ざん・削除 • AI に渡した権限が、そのまま攻撃に使われる どちらも、本人が見られるものはAI も全部見られる状態。API キーをそのままエージェントに渡しているのと同じ AI に渡す権限を、誰がどこで絞るか © 2015 - 2026 Nowcast Inc. 4
5. 2. なぜ MCPass を作ったのか 選択肢は 3 つ。配らない、そのまま配る、ゲートウェイを通す ① 配らない 却下 ② そのまま配る 却下 ③ ゲートウェイを通す 採用 • AI はチャットの相手のまま。社内の文書・デー タ・チケットに触れない • 各自が API キーを取得して設定ファイルに貼 る • 接続口を 1 つにして、認証・権限・監査をそこ に集める • 「AI で仕事をする」にならず、vibe working が 成り立たない • 使う人の大半は非エンジニア。キーの管理も 最小権限も個人任せになる • 利用者はクライアントを選んで設定を貼るだけ • 管理者は「誰に何を使わせるか」だけ決める • 3 枚目の状態に戻る: キー散在・フル権限・ロ グ無し 決めたこと 「使っていい」状態を先に作ってから配る。統制は利用者の運用に頼らず、製品側に持たせる © 2015 - 2026 Nowcast Inc. 5
6. 2. なぜ MCPass を作ったのか ゲートウェイに求めたこと : 見える・守れる・残る・止められる 見える 守れる 残る 止められる • 誰がどの MCP を使っているか • API キーを端末に置かない • 誰が・いつ・何を実行したか • 送ってはいけない本文を止める • 無許可の MCP を可視化できる か • 本人の権限をそのまま AI に渡さ ない • ツール定義の変更（rug pull） • 暴走した呼び出しを抑える • 脆弱性が出たとき影響範囲が分 かるか • ツール単位で許可・拒否できる • インシデント時に攻撃の連鎖を 追える • 問題のある MCP を即座に止め る → カタログ・利用状況 → 一括認証・ツール粒度の権限 → 監査ログ → DLP・Rate Limit・無効化 API ゲートウェイで解いてきた問題と同じ形。ID 境界・最小権限・監査を MCP でも 1 箇所に集める © 2015 - 2026 Nowcast Inc. 6
7. 3. MCPass の機能 MCPass の機能: 接続・アクセス制御・監査・実行時防御 接続・カタログ アクセス制御 監査・証跡 実行時防御 • MCP カタログ: 使える MCP を一覧・ 検索、提供元やホスティングなどのメ タデータ • ツール粒度の RBAC: 既定は全拒 否。Read と Write を分けて許可 • 全ツール呼び出しを監査ログに記録: 誰が・いつ・どのゲートウェイで・どの ツールを • DLP: 引数・応答の本文検査、遮断 ／マスク • 一括認証: 認証情報はゲートウェイ が集中管理。利用者は MCPass に 1 回ログインするだけ • Managed MCP（Slack / Google / GitHub / Snowflake …）と Vendor 公式リモート MCP、合わせて 20 種 超 • ロール設計と一括割当。1 人に複数 ロール • IdP 連携（Entra ID / Okta / Google）、IP 制限、タグによる分類 • Coming Soon: IdP グループ → ロール自動マッピング、申請・承認フ ロー • 期間・ユーザー・ゲートウェイで検 索、ダウンロード • ダッシュボード: 利用状況とランキン グを俯瞰 • Rate Limit: ロール単位の呼び出し 上限 • Coming Soon: 登録 MCP の脆弱 性スキャン、プロンプトインジェクショ ン検知、OpenAPI 定義からの MCP 自動生成 すべての利用がここを通る : ① カタログ ② 単一接続と一括認証 ③ ツール単位の権限制御 ④ 監査ログ © 2015 - 2026 Nowcast Inc. 7
8. 3. MCPass の機能 利用者と管理者から見た MCPass 利用者 1 管理者 1 接続 「AI クライアント接続」画面で自分のクライアントを選び、生成された JSON かコマンドを貼る 登録 Recipe か URL から MCP をカタログに登録し、ゲートウェイに載せ る 2 初回だけブラウザが開き、組織の SSO でログイン。以降は自動更新 2 ロール（ツール粒度）を定義し、ユーザーや IdP グループへ一括付与 ログイン 3 使う 権限 自分のロールで許可されたツールだけが見える。 Google は「有効 化」ボタンで専用アカウント発行、 Slack は Bot を招待 AI クライアント接続 MCP カタログ 3 運用 監査ログとダッシュボードで確認。止めたい MCP は disabled にする だけ MCP ロール（ツール単位の許可） © 2015 - 2026 Nowcast Inc. 監査ログ 8
9. 3. MCPass の機能 ｜ デモ デモ: 管理コンソールを実際に見る（モックサイト） MCP サーバー 1 2 3 4 5 カタログに並ぶ MCP と、提供元・ホスティング・リスクレベルなどのメタデータ。Recipe から 登録する導線 ゲートウェイ MCP をゲートウェイに載せる。汎用ツール用 / PM ツール用のように用途で切った例 MCP ロール ツール単位の許可リスト（Read / Write を分ける）。ユーザーへの一括付与 AI クライアント接続 クライアントを選ぶだけで接続設定 JSON / コマンドが生成される。トークンの手コピーが無い ここでブラウザに切り替え（モックモード、ダミーデータ） 見どころ 監査ログ / ダッシュボード 誰が・いつ・どのツールを呼んだか。引数や結果は残していないことも見せる • ロールで見えるツールが変わる • 接続はクライアントを選んで設定を貼るだけ © 2015 - 2026 Nowcast Inc. 9
10. 4. どう作ったか ｜ 軸 1 軸 1: MCP サーバーを束ねるゲートウェイ ゲートウェイ Claude Desktop / Cowork Claude Code Managed 束ね方 Google Drive / Docs / Sheets MCP Managed • カタログ → ゲートウェイに載せる → 1 つの tools/list GitHub MCP Managed Slack MCP Cursor 単一の接続口 {tenant}.gateway.{domain} tools/list を 1 つに集約 {server}___{tool} の名前空間 • 利用者は接続先を意識しない（MCP of MCPs） 誰に何を見せるか Snowflake MCP Managed 社内データ MCP 内部 / 外部 • ロール（ツール粒度の許可リスト）で tools/list が人ごとに変わる • 既定は全拒否。dangerous は既定 off ゲートウェイは用途ごとに切れる（汎用ツール用 / PM ツール用のように） MCP の種類 MCPass 自体が 1 つの MCP サーバーとして振る舞うので、既存の AI クライアントはそのまま 繋がる。統制はこの 1 点に集約する © 2015 - 2026 Nowcast Inc. • Managed: Recipe から登録、MCPass が ホスト • 外部: URL 登録 ／ 内部: Docker イメー ジをデプロイ 10
11. 4. どう作ったか ｜ 軸 2 軸 2: 認証認可を 3 層に分ける Layer 1 ユーザー認証 Layer 2 ゲートウェイ内の認可 Layer 3 外部サービス認証 AI クライアント → MCPass（誰が来たか） 誰がどのツールを呼べるか MCPass → 各サービス（何で呼ぶか） • 管理者が AI クライアントを「MCP クライアント」とし て登録 → Client ID。ゲートウェイに紐付けたもの だけ受け付ける • ロール = ツール粒度の許可リスト。既定は全拒否、 1 人に複数ロール可、IdP グループから付与 • Credential Broker が接続先ごとの方式を吸収: 共 有キー / 個人キー / OAuth 3LO・2LO / Slack Bot / Google SA • MCP Authorization spec どおり: well-known （RFC 9728 / 8414）→ ブラウザで OAuth → MCPass の認証基盤 → 組織の IdP（Entra ID / Google / Okta / SAML） • 呼べないツールは tools/list に出ない。tools/call は毎回 control plane に認可判定を問い合わせる • テナントの IP 許可リスト。ロール変更・緊急停止は 次のリクエストで即効く • 資格情報は暗号化して MCPass が保管。端末や 設定ファイルに置かない • 利用者の認証トークンを下流に渡さない（パスス ルー禁止）。詳細は 14 枚目 • gateway が毎リクエスト JWT を完全検証 （JWKS・iss・exp・token_use・client_id）。initialize も例外なし 認証・認可・資格情報を分けて扱う。利用者の認証トークンは © 2015 - 2026 Nowcast Inc. MCP サーバーに届かない 11
12. 4. どう作ったか 実装: data plane（通信）と control plane（判定）を分ける DATA PLANE — 通信本文を扱う AI クライアント Cursor / Claude Code / Claude Apps / Copilot CLI / Snowflake CoWork エッジ ゲートウェイ（ステートレスなプロセス） テナント別のゲートウェイ URL トークン検証 / tools/list 集約 / routing / DLP・Rate Limit / 認証ヘッダ注入 / 監査報告 認可判定 / 完了報告の受付 / カタログ / ロール 外部 MCP（HTTP + 資格情報） 署名付きの内部 API 経由のみ（DB 直結なし） CONTROL PLANE — 判定と記録を持つ 管理 API MCPass がホストする MCP （Managed / 内部） データベース 鍵管理 認証基盤 テナント分離、監査ログの正本 資格情報の暗号化 テナント毎に IdP とフェデレーション ① 本文は control plane に渡さない ② 判定は毎回、同期で問い合わせる DLP・Rate Limit の判定は gateway 内で完結。「該当 した」事実だけ報告 ポリシーを配布してローカル判定はしない。緊急停止 は次のリクエストで効く © 2015 - 2026 Nowcast Inc. ③ 上流への到達は data plane だけ control plane は上流を直接呼ばない。data plane は 可搬性を担保する予定（顧客ネットワーク内にも置ける 形に） 12
13. 4. どう作ったか 1 回の tools/call で何が起きるか ① JWT 検証 ② 認可判定 ③ 統制 上り ④ upstream 実行 ⑤ 統制 下り ⑥ 結果を報告 gateway control plane RBAC・IP・資格情報 ・routing を判定し 監査を確定 → allowed gateway DLP / Rate Limit 遮断・マスク gateway 認証ヘッダ注入 401 は利用時更新 gateway 応答をマスク／遮断 control plane 結果・所要時間・統制の 該当を記録 橙 = gateway（data plane） 青 = control plane この順序の理由 ポリシーを gateway に配布しない • 認可判定と監査の記録が終わるまで、上流には接続しない。監査に 無い呼び出しは存在しない • 緊急停止・ロール変更が次のリクエストで効く • 止められるのは実行前だけ。応答側の遮断は開示を防ぐが、実行済 みの操作は戻せない • gateway 側にキャッシュや失効の仕組みが要らない • 上流 MCP の往復に比べれば、問い合わせ 1 回の増分は小さい © 2015 - 2026 Nowcast Inc. 13
14. 4. どう作ったか 外部サービス認証 : 利用者のトークンは渡さず、接続先ごとの資格情報に差 し替える 接続先ごとに認証方式が違う。ゲートウェイが吸収する 資格情報は「許可されたツール呼び出し」にだけ付く 組織共通の API キー Backlog / Notion 等 user_delegation 利用者個人の API キー・PAT Kibela / Backlog / GitHub oauth_3lo 利用者本人の OAuth 同意 Snowflake / Atlassian shared • 利用可否は「そのツール呼び出しが許可されたか」に従属。 gateway には短命のアウトバウンド用ヘッダしか渡らない • OAuth 3LO は本人と同じ範囲を全部渡す。4 枚目の事故はこれ。方 式の選択自体が設計判断 トークンパススルーはしない（ OWASP でも非推奨） • 利用者の認証トークンと、API を呼ぶための資格情報は別物 oauth_2lo client credentials マシン間連携 slack_app 利用者ごとの Slack Bot Slack google_sa 利用者ごとのサービスアカウント Google Workspace • 例: 「業務リポに Issue を立てて」→ Entra のトークンは GitHub に届 かない。利用者が登録した最小スコープの PAT（対象 repo・issues:write・期限付き）を MCPass が注入して実行 • 漏れても短命・最小権限。依頼者は監査ログに残る © 2015 - 2026 Nowcast Inc. 14
15. 4. どう作ったか AI には AI 用の身分証を持たせる : Google と Slack Google Workspace: 1 ユーザー = 1 サービスアカウント Slack: 1 ユーザー = 1 Bot • 「発行」ボタン 1 つで自分専用の SA。表示されたメールアドレスをDrive の共有 設定に貼るだけ • 利用者ごとに Slack App（Bot）を作成・インストール。トークンは暗号化保管し自 動更新 • 共有したものしか AI に見えない → Google の認可に乗る。監査ログも人とAI が分離 • Bot を招待したチャンネルだけがAI の視界。呼び出しは Bot 名義で Slack 側に も記録 • 発行者 SA と実行者 SA を分離、WIF の委任チェーンで鍵レス・短命トークン • 剥奪は Bot を削除するだけ Zenn: AIに会社のGoogleアカウントを渡して いませんか Zenn: AI に Slack の DM まで読ませていま せんか https://zenn.dev/finatext/articles/mcp-gateway-go ogle-sa https://zenn.dev/finatext/articles/mcp-gateway-sla ck-app 共通点 : 見える範囲の制御を MCPass で作らず、サービス側の共有設定（ Drive の共有・チャンネル招待）に任せる © 2015 - 2026 Nowcast Inc. 15
16. 4. どう作ったか 統制ルール : 通信本文の検査と、呼び出し回数の上限 DLP Rate Limit 見せるツールを絞る • 引数と応答の本文を正規表現で検査し、遮断 / マスク / 記録のみを選ぶ • ロールごとに呼び出し回数の上限を決める • ロールで呼べるツールだけを tools/list に出す • 暴走したエージェントを止め、外部 API の クォータを守る • 危険なツールは既定でオフ • 例: マイナンバーや電話番号を含む送信を止 める 管理画面でルールを作り、ロールに適用すると効く 止められるのは実行前だけ。応答側の遮断は開示を防ぐ © 2015 - 2026 Nowcast Inc. 16
17. 4. どう作ったか 監査ログ : 1 回の呼び出しを 1 行で。引数と結果は残さない 残すもの 残さないもの 順序 誰が・どのクライアントで・どのゲートウェイの・どの ツールを・許可されたか・どう終わったか ツールの引数、結果、エラー本文、資格情報 認可の判定を記録してから上流を呼ぶ。監査に無い 呼び出しは存在しない © 2015 - 2026 Nowcast Inc. 17
18. 5. 現場でどう使われているか 社内ユーザー 300 人弱、週 5 万リクエスト 300人弱 約6割 約5万 登録ユーザー 週間アクティブ率 リクエスト / 週 社員の 6 割超 登録者のうち毎週使う人 MCP 別リクエストの構成比（過去 7 日） よく呼ばれるツールは「読む」系 約 1/3 Slack 約 10% Google Sheets GitHub 約 5% Google Drive 約 5% Kibela 約 5% • Slack のスレッド返信・チャンネル履歴を読む • スプレッドシートを読む（Google Sheets） • ノート検索（Kibela）、ファイル検索（Google Drive） © 2015 - 2026 Nowcast Inc. 18
19. 5. 現場でどう使われているか 何に使われているか（例） 議事録・会議 案件・顧客管理 開発・ PM • 顧客ごとの議事録を AI に読ませて提案準備 • 案件管理スプレッドシートを AI から更新 • 要件定義とチケットの突き合わせ • 部門の議事録から Next Action を抽出 • CRM の商談情報を、権限を絞って参照 • 顧客との UAT 指摘を Slack スレッドで管理 データ分析 バックオフィス 定型化 • Snowflake に自然言語で集計を依頼 • HR の入社オンボーディング • 手順を Skill にして繰り返し実行 • スプレッドシートを読み込んで報告書に • 契約管理シートの更新と変更履歴 • Slack Bot が週次サマリを投稿 © 2015 - 2026 Nowcast Inc. 19
20. 5. 現場でどう使われているか ｜ デモ デモ: Claude Code から MCPass に接続し、ロールで使えるツールが変わ るのを見る 手順 • 接続画面で Claude Code を選ぶ → 生成された claude mcp add コマンドをコピー • ターミナルで実行 → /mcp で Authenticate → ブラ ウザで組織の SSO • ツール一覧を見る: ロール A では Slack の読み取 り系だけ • 管理画面でロール B を付与 → /mcp で再接続 → 書き込み系のツールが増える • ツールを 1 回呼ぶ → 監査ログに「誰が・どのクライ アントで・どのツールを」が 1 行残る 接続画面で Claude Code を選ぶと、コマンドがそのまま生成される（モック画面） © 2015 - 2026 Nowcast Inc. 20
21. 6. 次に解決する課題 次の課題 : Lethal Trifecta ① 非公開データへのアクセス ② 信頼できないコンテンツへの露出 ③ 外部へ送信する手段 絞れている 止められない 細くしている • ツール粒度の RBAC • AI 専用の身分証（SA / Bot）— 共有されたものしか 見えない カレンダー攻撃では: 会議情報 • Slack のスレッドも Drive の docx もツール結果と してモデルに入る • tools/list に危険ツールを出さない • 下り相の遮断は開示の防止であって行為の防止で はない • 上流への到達を data plane に限定 • 上り相の DLP で送信本文を遮断・マスク カレンダー攻撃では: Gemini の操作 カレンダー攻撃では: 招待の説明欄 Simon Willison, “The lethal trifecta for AI agents”（2025-06）。3 つが同時に揃うと、プロンプトインジェクションで情報が抜かれる 次の一手 : taint（汚染追跡） 並行して ① を絞る • セッション中に一度でも機密データを取得したら、そのセッションでは外部送信系のツールを使わせ ない。DLP では止めにくい ② 経由の持ち出しを塞ぐ • Drive のラベル（機密度・業務ドメイン）を条件に、同じ MCP を見える範囲の違うツールとして登録 • 難所: セッションを張り直すと汚染状態が消える。どこまでの完全性を求めるかを実装前に決める • プロンプトインジェクション検知は補助。主な防御は権限の 構造で作る © 2015 - 2026 Nowcast Inc. 21
22. まとめ まとめ 1 AI には AI 用の身分証を持たせる 2 認可・監査・資格情報の解決はゲートウェイ 1 箇所に 3 DLP・Rate Limit は通信本文を持つ gateway で執行する 本人のトークンを渡さない。Google は SA、Slack は Bot。共有されたものしか見えない 判定と記録を通らない呼び出しは無い。緊急停止は次のリクエストで効く 判定材料を control plane に渡さない。data plane を顧客側に置く道も残る © 2015 - 2026 Nowcast Inc. 22
23. 参考 参考リンク MCPass 全体構成（Zenn） https://zenn.dev/finatext/articles/mcp-gateway-nowcast Google Workspace 連携認証: AI 専用のサービスアカウント（ Zenn） https://zenn.dev/finatext/articles/mcp-gateway-google-sa AI に Slack の DM まで読ませていませんか（ Zenn） https://zenn.dev/finatext/articles/mcp-gateway-slack-app MCP ゲートウェイ MCPass の設計と実装（DataOps Night10） https://speakerdeck.com/mtpooh/mcpass-intro-dataopsnight10 MCPass 製品ページ https://finatext.com/mcpass © 2015 - 2026 Nowcast Inc. 23
24. お知らせ 9 月のイベント : AGNTCon+MCPCon Japan と Snowflake World Tour Tokyo AGNTCon + MCPCon Japan にブース出展 Snowflake World Tour Tokyo 2026 に 3 名が登壇 2026-09-10（木）〜 11（金）｜ベルサール渋谷ガーデン｜The Linux Foundation 主 催 2026-09-11（金）｜グランドプリンスホテル新高輪｜参加無料・要事前申込 • ブースで MCPass と AI エージェント「Finstage Cowork」を紹介 • 参加登録は有料（事前購入）。ぜひブースにお立ち寄りください https://nowcast.co.jp/news/20260820 • 13:20 Snowflake Well-Architected Framework で実現する実践的なデータマネ ジメント • 15:05 仕様書も SQL もログも全部コンテキスト : Cortex Agent で作るデータ QA エージェント • 15:50 Semantic View は「作るもの」から「育てるもの」へ https://nowcast.co.jp/news/20260806 © 2015 - 2026 Nowcast Inc. 24
25. 採用 ナウキャストで MCPass を一緒に作りませんか : カジュアル面談募集中 募集中のポジション カジュアル面談はこちら データエンジニア ／ AI フルサイクルエンジニア ／ ほか各職 種 Finatext グループ共通の窓口（HERP） プロダクト開発 ソリューション • MCPass、Finstage Cowork などの自社プロ ダクト • クライアントのデータ基盤構築と AI 活用の支 援 • 金融グループ 460 名の現場が最初のユー ザー • 顧客折衝から実装・運用まで自分で回す https://herp.careers/v1/finatexthd/vZWzSlI_B-qk エンジニア組織のインタビュー記事 https://finatext.com/recruit/finalog/interview _nowcast_engineer このあとの懇親会で、気軽に声をかけてください！ https://finatext.com/mcpass/ © 2015 - 2026 Nowcast Inc. 25