【要約】社内MCPゲートウェイを自作した話──OSSのMCPサーバにGoogle認証・監査ログ・クエリ制御を後付けする [Zenn_Python] | Summary by TechDistill
> Source: Zenn_Python
Execute Primary Source
// Problem
社内でClaude Codeの活用を推進する組織が、OSSのMCPサーバをそのまま全社展開しようとした際に、管理上の重大なリスクに直面した。具体的には、以下の問題が発生する。
- ・シークレットの散在: DB接続情報やAPIキーが各個人のPCに保存され、管理不能になる。
- ・監査ログの欠如: 誰がいつ、どのようなクエリで、何行のデータを取得したか追跡できない。
- ・LLMによる制御不能な挙動: LLMが意図せず全件取得を行い、トークン爆発や精度低下を招くリスクがある。
// Approach
開発者は、OSSのMCPサーバを一切改変せず、前段に薄いプロキシ層を挟むことでセキュリティと統制を強化するアプローチを採用した。構成はnginx、認証、プロキシ、OSS MCPの分離構造である。
- ・認証の多層化: Google OAuth 2.1を用い、MySQLはJWT中継、BigQueryはya29トークン横取り、SalesforceはSSO連携と、接続先に応じた認証方式を実装した。
- ・仮想ツールの導入: 大容量データ取得時に、結果をサーバーに保存し署名付きURLを返す
query_to_fileをプロキシ側で後付けした。 - ・クエリガードの実装: プロキシ層でSOQL等のクエリを解析し、自動的にLIMIT句を付与する制御を行った。
// Result
このゲートウェイ構成により、社内メンバーは安全かつ統制された環境でMCPを利用可能となった。導入によって得られた成果は以下の通りである。
- ・セキュリティ向上: 個人PCからDB接続情報を完全に排除し、シークレット管理をサーバ側に集約した。
- ・高度な監査性: JSON Lines形式で、実行ユーザー、SQL、取得行数を含む詳細なログを永続化した。
- ・リソース保護:
query_to_fileにより、LLMのコンテキスト爆発を防ぎつつ、大容量データの安全な受け渡しを実現した。
Senior Engineer Insight
> OSSを「ラップする」設計思想は、メンテナンス性とセキュリティのバランスにおいて極めて合理的だ。特に、LLMの非決定的な挙動（全件取得など）をプロキシ側で強制的に制御するアプローチは、実運用における必須要件と言える。U+2028問題のような、本番データ特有のパースエラーへの対処も、現場の泥臭い経験が反映されている。ただし、プロキシが単一障害点（SPOF）となるため、大規模展開時には高可用性の設計が不可欠となるだろう。