事例研究 · データとガバナンス
本番データを扱うエージェントをアナリストに——ただし鍵は渡さずに。
あるデータチームは、ウェアハウスや社内 API に対するセルフサービスの AI エージェントを望んだが、アナリスト全員のノート PC が本番の認証情報を抱える事態は望まなかった。onemcp ポータルは認証をホスト側に留め、アクセスを中央で管理した。
- 業種
- データと分析
- チーム
- アナリスト約 25 名＋データ基盤チーム 4 名
- 技術スタック
- Snowflake · dbt · Postgres · 社内メトリクス API · GitHub
# 概要
- アナリストのマシンに本番の認証情報が存在しない
- アクセス制御の中央拠点はポータル 1 つ
- 新しいツールはノート PC ごとではなく中央で追加
本稿は一般的な onemcp 導入に基づく例示的なシナリオである。登場するチームは複合的な創作であり、実在の顧客ではない。数値は実測値ではなく代表的な目安である。
背景
約二十五名のアナリストから成るデータチームは、日々の作業——クエリの作成、メトリクス定義の追跡、パイプラインの健全性の確認——に AI エージェントを使いたいと考えていた。必要なツール——Snowflake、dbt、社内メトリクス API、いくつかの Postgres レプリカ——には、いずれも利用可能な MCP サーバーが存在した。
障壁はエージェントそのものにあったためしがない。障壁は、セキュリティが毎度発する問いにあった。*認証情報はどこに存在するのか。*
課題
分かりやすい道は、MCP サーバーを各アナリストに渡し、自ら認証させることだった。セキュリティはこれを承認しなかったし、その慎重さは正しかった。
- 認証情報が拡散する。 二十数名のアナリストが各自のマシンにウェアハウスと API の認証情報を抱えることは、秘密が漏れうる場所が二十数か所あるということであり、しかもきれいに更新する手立てがない。
- アクセスが全か無かである。 サーバーを一つ渡すことは、そのトークンが行えることすべてを渡すに等しく、誰が何を持つかの可視性はほとんどない。
- ガバナンスが規模に耐えない。 ノート PC ごとにアクセスを審査・失効させる作業は、誰も担いたがらない工程であった。
アプローチ
データ基盤チームは、アナリストと本番システムの境界として、単一の onemcp ポータルを運用した。
- 認証情報はホスト側に留まる。 各上流はポータル内で一度だけ認証される。ネイティブな上流の OAuth とトークンはそこに存在し——アナリストのマシンにも、リポジトリにも決して置かれない。アナリストのエージェントが接続する先はポータルであって、データベースそのものではない。
- アクセスは中央で管理される。 どのサーバーを、誰に対して利用可能とするかは、一か所で決まる。新しいツールの導入はポータルの変更であり、アクセスの失効も誰かの設定に触れる必要がない。
- カタログはコンテキスト内で軽く保たれる。 Code Mode を通じて、ポータルはあらゆるツールスキーマではなく
search、describe、executeのみを公開する。そのためエージェントはタスクに必要なツールだけを取得し、アナリストのコンテキストは分析そのものに向けられる。
成果
- ノート PC に本番の認証情報が残らない。 秘密はポータルに存在する。アナリストの離任やマシンの紛失は、もはや認証情報更新の緊急事態ではない。
- 統治は一か所で。 セキュリティはアクセスをポータルで審査・管理し、二十五の個別設定を渡り歩くことはない。
- 乱立なきセルフサービス。 アナリストは各自のエージェントを得た。基盤チームは単一かつ監査可能な管理点を保ち——次のツールの追加も、中央での一度の変更で済む。
本当の転機はエージェントそのものではなく、それに「よし」と言えるようになったことだ。アクセスはポータルに存在するため、セキュリティが確認すべき対象は三十台のノート PC ではなく一か所で済んだ。