公式の MCP サーバーで出来ない事が多い
目次
一時期少し熱が冷めていたのですが、最近また色んな業務を自動化したいという欲求が出てきました。
以前、以下のような小さな自動化を行いました。
MCP で業務効率化: Backlog の issue から、要対応のものだけを抜き出して Slack 通知する – もばらぶん
この時に使ったのは、Backlog と Slack の MCP サーバーで、いずれも公式のものです。
ただ、実装中に「公式 MCP サーバーだと出来ない事って結構あるな」という事に気がつきました。
公式 MCP サーバーだと出来なかった事
Slack: ボット権限での処理
Slack の公式 MCP サーバーは認証・認可に OAuth 2 を使っていて、ツールの呼び出しはそのユーザーの権限で行われます。投稿の場合は以下のようなイメージです。
メッセージの末尾には以下のような表示が付くため Slack アプリ経由（今回は “Automation with Bloque” という内部向けアプリを作って使っています）での投稿だと分かるようにはなっています。
ただ、あくまでユーザー権限での投稿のため、それに対して返信をしたりするとそのユーザー（今回は私）宛にメンションが飛びます。
それが望みの動作であれば別に構いません。ただ、MCP サーバーを使った処理の中には、個人に紐付く処理というよりはプロジェクト全体に関わる処理というのも多いはずです。冒頭に紹介したブログ記事でやっている事は、各メンバー毎の要対応チケットを抜き出して通知するというもので、私個人の権限でやるべき事ではありません。
と、前置きが長くなりましたが、そうしたときにはボットユーザー権限で処理したいところです。
X: 投稿処理
X にも公式 MCP サーバーがあります。
MCP servers for the X API and X developer docs – X
ドキュメントが若干分かりにくいのですが、出来る事一覧としては以下の通りです。
Article の下書きと投稿は出来るのですが、通常の投稿は出来ません。
なお、（X MCP は使わず）X API であれば通常の投稿も出来ます。
その他
以前、以下のような記事を書いたのですが、出来ない事が多すぎる事にすぐ気づいて、現時点では業務では使っていません。
Google Workspace MCP サーバーを使う＆解説 – もばらぶエンジニアブログ
そのうちの一部は Google の問題と言うよりは MCP 自体の問題ではありますが（以下を参照）、Google で出来る事ももっとある気がします。
現状の MCP では大きなファイルを扱えない – もばらぶエンジニアブログ
また、freee MCP は freee の API をラップしただけですが、API で出来ない事が結構あって、なかなか辛いところです。本題ではないので深入りしませんが。
どうすれば良いか
非公式 MCP サーバーを使う
本ブログのタイトルを読んだ時点で想像が付くとは思いますが、公式 MCP サーバーで出来ない事でも非公式の OSS MCP サーバーで出来る場合も多いです。
MCP 経由で Slack のボットユーザー権限で処理を行いたい場合は、以下の MCP サーバーが使えます。
MCP 経由で X 投稿を行いたい場合も、非公式 MCP サーバーで出来ます。非公式の X MCP サーバーはいくつかあるのですが、そのうちの1つをフォークして以下に公開しています。
API はあるけど MCP サーバーが無ければ自分で作る
世の中の大半の MCP サーバーは API をラップしただけのものです。使いたい機能の MCP サーバーが無いけど API はある場合は、MCP サーバーを自分で作れば良いです。と言っても自分でプログラムを書く必要は無く、AI に依頼するだけです。
なぜ MCP に拘るのか
技術者が自分でやる作業なら API/CLI を直接使えば良い
わざわざ MCP に拘らなくても、API や CLI があるならそれを直接使えば良いという意見もあると思います。API であれば OpenAPI 仕様などを、CLI であればコマンド名をそれぞれ AI に教えるだけで、大抵は望みの処理が出来ます。
技術者が自分自身の作業を行う場合は確かにそうだと思います。ただし、MCP を使った方が良い場面もあるので、この後いくつか紹介します。
非技術者が行う業務の場合は MCP サーバーを設定して渡した方が良い
会社の X アカウントの投稿は、技術者ではなくて広報やマーケティングなどの部署が担当することが多いと思います。そうした部署の非技術者（仮に広報担当）が他のシステムと連動させて X 投稿を自動化したいと思ったときにどうすれば良いでしょうか。
技術担当が X Developer Portal でアプリを作成し、OAuth 関連のトークンを広報担当に渡して、「後は AI に聞けば分かるよ」と伝えるのでしょうか。その状態から目的のことを達成できる広報担当も存在するとは思いますが、数は少ないはずです。
そうではなく、広報担当の PC 上の Claude なり ChatGPT に技術担当が MCP サーバーの設定をしてあげれば、そこから先は広報担当で AI を使った業務を進められるはずです。
という感じの弊社内での事例を会社ブログの方に書きましたので、興味のある方はご覧ください。
宣伝: なお、非技術者の人数が多い場合には、MCP サーバーの設定を個別に行うのは大変です。弊社で開発している Bloque のような MCP ゲートウェイ上で MCP サーバーを設定した方が圧倒的に楽です。
Bloque – All Your MCPs, Centrally Managed.
API の全ての機能を使わせたくない場合、MCP のツール単位で制御する
OAuth を使っていたりユーザー毎の API キーを発行できる場合は、基本的にはそのユーザーが出来る事が API 経由でも出来るようになります。
挙動が決まっているプログラムから API を呼び出す場合はあまり問題になりませんが、AI だとそうもいきません。例えばお客様とのやり取りに使っている Backlog の API に AI からアクセスさせた場合、機密情報を勝手に Backlog に書き込んでしまうという事も十分あり得ます。
MCP であれば、特定の MCP ツールのみを許可するという設定が出来るものが多いです。具体的には、Claude Code, Claude Desktop, Codex CLI, Codex Desktop 辺りは設定できます。ChatGPT アプリはプランによって違うようです（細かくは調べていません）。
なお、MCP ゲートウェイであればその辺りを細かく一元管理出来るものが多いです。
宣伝: Bloque でもツール毎に有効化・無効化を設定できます。
まとめ
SaaS ベンダーなどが出している公式 MCP サーバーは便利なものも多いですが、出来ない事が結構多い MCP サーバーも珍しくありません。そうしたときには、非公式 MCP サーバーを使う、あるいは自分で MCP サーバーを作ってしまうというのも選択肢です。
なぜそこまでして MCP サーバーを使うのかという意見もあるかと思いますが、
- 非技術者が AI を使った業務を行いたい
- AI がアクセスする機能を制限したい
等の場合には、MCP サーバーを使った方が簡単です。また、MCP サーバーを単体で使うのではなく、MCP ゲートウェイを使うというのも管理面で良い方法です。
コメントを残す