- 年に社内AIツール基盤をMCPサーバーの集合として立ち上げ、2年運用して分かったのは「状態を持たない決定論的なツールはプラグイン側に寄せるほうが運用が楽」という身も蓋もない結論だった。今回はMCP単独からプラグイン同梱ハイブリッドへ移行した際の判断基準を共有する。
前提として、MCPとプラグインは競合ではなく補完関係だ。MCPサーバーは長命プロセスで外部システムとの接続状態を保持するのが得意（Jira、Snowflake、社内認証プロキシ等）。一方プラグインはコマンド・hook・エージェント・スキルをリポジトリ単位でバンドルでき、配布と更新が軽い。問題は「どっちでも書けるツール」の扱い。
弊社の線引きは3つの軸で決めている。第一に状態性。認証トークンやセッションを数分持ちたいならMCP。一回のコマンドで完結するならプラグインのスラッシュコマンド+Bash allow-list。第二に更新頻度。週次以上で挙動を変えるならプラグイン（git pullで即反映）、四半期に一度の安定ツールならMCPに据え置き。第三にチーム所有権。プロジェクトチームが触るならプラグインとして`.claude/`に同梱、プラットフォームチーム管理ならMCP。
移行の具体例として、社内の`jira-search`ツールはMCPに残した。OAuth更新と検索キャッシュを持つので状態性が強い。一方`changelog-draft`と`code-review-checklist`はプラグイン側に移した。どちらもgit履歴を読むだけの純粋関数で、リポジトリごとに微調整したい性質があった。結果、MCPサーバーの数は17から9に半減し、残ったものは「外部接続を持つ」ものだけになった。運用負荷が明確に下がった。
ハイブリッド運用のコツはプラグインの`.claude-plugin/plugin.json`で`mcpServers`を宣言し、プラグインと一緒にMCP依存も配布すること。これで「このプラグインを有効にすればMCP接続情報も揃う」という一体感が出る。ユーザー側の`settings.json`にMCPエンドポイントを書かせる運用は、鍵のローテーション時に全員が詰まるので避けたい。
判断に迷ったら、まずプラグイン側で試作し、状態保持の必要性が見えた段階でMCPに引き上げる順序を推奨する。逆よりも手戻りが少ない。移行は半年プロジェクトとして計画したほうが現実的だ。