MCP Gatewayのログで分かること、分からないこと

はじめに

こんにちは！株式会社SOARIGでエンジニアをしているあおいです。

MCP Gatewayを導入すると、社内のAI利用は記録されるようになります。誰が、いつ、どのサーバーのどのツールを使ったか。統制という意味では、これで完結します。

ただ、運用していると、そのログでは答えられない質問が出てきます。

「で、実際どんなことに使われてるの？」

これに答えるには、Gatewayとは別の場所に情報が要ります。今回はその話を書きます。

対象読者

• MCP Gatewayの導入を検討していて、その後の運用まで見ておきたい方。

Gatewayのログで、どこまで見えるか

まず、Gatewayが記録できるものを整理します。

• 誰が使ったか
• いつ使ったか
• どのMCPサーバーの、どのツールを呼んだか
• MCP経由でどの文書・リソースにアクセスしたか
• 成功したか、失敗したか

うちの場合、ContextForgeの権限はプロジェクト単位で切っています。この単位は組織の実態に合わせて決められるので、たとえば部署ごとに分ければ「営業部からこのサーバーへのアクセスが多い」といった集計もできます。

監査としては十分です。「先月この人事系のツールに触ったのは誰か」には答えられるし、アクセスの偏りも見える。

「何に使われているか」は分からない

ただ、そこまでです。

「営業部からのアクセスが多い」は分かる。どの文書が引かれたかも分かる。でも、営業部の人たちがそれを使って何をしようとしていたのかは分かりません。

• 顧客情報を調べていたのか
• 提案書のネタを探していたのか
• 同じことを何度も調べていて、そもそも探しづらいのか

ここが分からないと、次の打ち手が決まりません。「アクセスが多い＝うまくいっている」なのか「探しものが見つからなくて何度も叩いている」なのかで、やることは正反対になります。

そして経営層から聞かれるのは、たいてい後者側の質問です。「AIを入れて、結局どの業務が楽になったの？」というやつですね。

会話は、エージェントを持っている側に残る

なぜGatewayからは分からないのか。

Gatewayに届くのは、「どのツールを、どんな引数で呼ぶか」という形に変換された後のリクエストだからです。ユーザーが何と入力したかは、その手前で処理されています。

その手前にいるのが、AIエージェントです。ユーザーの入力を受け取り、どのツールを使うか判断し、Gatewayに投げる。会話の中身を持っているのは、この層だけです。

ここで分かれ道があります。

エージェントに既存のAIツールを使う場合、会話はそのサービス側に残ります。Gatewayを通った記録は手元に来ますが、何を聞かれたかは手元に来ません。

自社でエージェントとUIを用意する場合、会話は自社側に残ります。分析に使えるのは、こちらの場合だけです。

部署タグ × 内容の分析

会話が手元にあると、何ができるか。

うちのUIには、ユーザーにタグを付ける仕組みがあります。部署、拠点、雇用形態、役割、プロジェクト単位など、切り口は自由に決められます。

とはいえ、最初は部署だけでも十分だと思っています。部署タグを付けて、その部署の質問に多く含まれている単語を、多い順に並べてみる。 これだけで、かなり見えます。

• 営業部で何のキーワードが多いか
• 特定の部署だけ、同じ言葉が繰り返し出ていないか
• 想定していなかった使われ方をしている部署はないか

「営業部からのアクセスが多い」で止まっていたものが、「営業部は主にこの領域で使っている」まで解像度が上がります。ここまで来ると、次にどのシステムを繋ぐべきかも見えてきます。

Gatewayが持っているのはどのツールが叩かれたか、エージェントが持っているのは何を聞かれたか。この2つが揃うと、利用状況の分析ができるようになります。

監査ログは、中身を持ちません

ここで、ログの設計について補足しておきます。

うちは監査ログと会話ログを、そもそも別のものとして扱っています。

監査ログは「誰が・いつ・どのツールを使ったか」という操作の記録だけを保持します。引数の中身は入りません。機密情報を含まないので、長期間残せます。

会話ログは中身を含むので、別のデータセットで管理し、短い期間だけ保持します。保持しない選択もとれます。

分析に使うのは後者です。中身を含むデータを長く抱え込まずに、必要な期間だけ分析に回す。監査のための記録は長く、中身は短く、という分け方をしています。

「ログを取る」と言うと社内から抵抗が出ることがありますが、この2つを分けて説明すると、話が通りやすくなります。

既存のツールとの使い分け

最後に、全員を自社UIに寄せる必要はない、という話をしておきます。

エンジニアは使い慣れたAIツールから直接Gatewayに繋げばいいと思います。開発中のツールを変えさせても効率が落ちるだけですし、統制という意味ではそれで何の問題もありません。Gatewayを通る以上、権限も監査ログも同じように効きます。

うちも実際、両方動いています。エンジニアはエディタに入れたAIから直接、それ以外のメンバーは自社のUI経由で。同じGatewayに、性格の違う経路がぶら下がっている状態です。

そして、利用状況を知りたいのはたいてい後者のほうなんですよね。エンジニアは放っておいても使いこなしますが、そうでない部署が「配っただけ」になっていないかは、見えないと分かりません。

整理すると、こうなります。

• 統制は、どの経路にも効きます。 Gatewayを通る限り同じです
• 利用状況の分析は、自社でエージェントを持っている経路から取れます

なので、まずGatewayで土台を作って、非エンジニア部門に広げる段階でUIを足す、という順番でも大丈夫です。最初から全部揃える必要はありません。

ちなみに、既存のAIツールを使ったまま、なんとかログを取れないかも並行して考えています。まだ答えは出ていないのですが、何か形になったらブログに書きます。

全社展開が進むと、たいてい「で、効果はどうなの」と聞かれる時が来ます。そのときに数字で答えられると、次の話がだいぶ早くなります。

---

micotoでは、MCP Gatewayの導入・運用に加えて、専用のAIエージェントとUIの提供も行っています。「使われているかどうかまで見たい」という場合はご相談ください。