Claude CodeのMCPとフック｜役割の違いと安全な使い分け

Claude Codeで外部接続と自動処理を設計するとき、MCPとフックを同じ「便利な拡張」として扱うと判断を誤ります。公式ドキュメントでは、MCPはModel Context Protocolを通じてClaude Codeを外部ツール、データベース、APIへ接続する仕組みとして説明されています。一方、フックはClaude Codeのライフサイクル上の特定イベントで、ユーザー定義の処理を自動実行する仕組みです。

MCPは「Claude Codeが何にアクセスできるか」を広げます。フックは「いつ、どの条件で、どの処理を必ず走らせるか」を決めます。GitHub、Issue Tracker、監視サービス、社内DBのような外部情報をClaude Codeから扱いたいならMCPが中心になります。編集後にformatterを走らせる、危険なBashコマンドを止める、権限要求の発生を通知する、といった決定的な処理はフックの領域です。

迷いが生まれるのは、どちらも自動化に見えるからです。MCPツールを呼べば外部システムで操作が起こり、フックも条件に合えば自動で動きます。それでも安全設計では、接続面と制御面を分けます。外部接続の権限、認証、取得できるデータ範囲はMCP側で考え、実行前後の検査、ブロック、通知、監査はフック側で考える。この分離ができると、Claude Codeの導入は「何でもつなぐ」から「意図した境界の中で動かす」へ変わります。

MCPは、AIアプリケーションが外部システムに接続するためのオープンな標準です。Claude Codeの公式ドキュメントでは、MCPサーバーによってClaude Codeがツール、データベース、APIへアクセスできるようになると説明されています。ユーザーが監視画面やIssue Trackerの内容を手で貼り付ける代わりに、Claude Codeが接続済みのシステムを直接読んだり、必要な操作をしたりできるようにする発想です。

Claude Code側のMCP設定には、リモートHTTP、SSE、ローカルstdio、WebSocketなどの接続方式があります。公式ドキュメントでは、クラウド系サービスへ接続する場合はHTTPサーバーが推奨され、SSEは非推奨とされています。ローカルstdioサーバーはローカルプロセスとして動き、プロジェクトルートを示す環境変数も扱えます。接続方式の選択は便利さだけでなく、認証情報の置き場所、実行されるプロセス、ネットワーク境界に直結します。

MCPのスコープも安全設計の一部です。localスコープは現在のプロジェクトだけに読み込まれ、個人用の設定に向きます。projectスコープはプロジェクトルートの.mcp.jsonで共有でき、チーム利用に向きます。userスコープは複数プロジェクトで使えますが、個人環境の影響範囲が広がります。管理設定では組織単位でMCP構成を配布できます。どのスコープを選んだかは、誰のClaude Codeに同じ接続が現れるかを左右します。

共有できるからprojectスコープを選ぶ、では不十分です。チーム全員のClaude Codeに同じ外部接続を持たせるなら、接続先の信頼性、権限、トークンの扱い、レビュー手順を先に決める必要があります。公式ドキュメントも、外部コンテンツを取得するサーバーはプロンプトインジェクションリスクを持つため、信頼できるか確認してから接続するよう促しています。

フックは、Claude Codeの動作中に発生するイベントへ処理を結びつける仕組みです。設定ファイル内でイベントを選び、matcherで対象を絞り、command、http、mcp_tool、prompt、agentなどのハンドラを実行します。たとえばPreToolUseはツール実行前、PermissionRequestは権限判断の場面、PostToolUseはツール実行後、UserPromptSubmitはユーザーのプロンプト送信時に動きます。

この特徴は、LLMに「毎回忘れずに実行して」と頼むのとは違います。フックは条件に合えば決定的に走ります。編集後にformatを実行する、特定ファイルへのWriteを止める、権限要求時に通知する、会話開始時に追加コンテキストを入れる、といった処理は、モデルの判断よりも設定に寄せたほうが安定します。Claude Codeの基本的な使い方を押さえた後にフックを設計すると、プロンプトで頑張る部分と設定で固定する部分を分けやすくなります。

代表的なイベントを見ると、PreToolUseは実行前に検査でき、条件によってツール実行を止められます。PostToolUseは実行後に動くため、結果の検査や整形には向きますが、実行済みの操作は取り消せません。UserPromptSubmitはプロンプト処理前に動き、入力のブロックや追加コンテキスト付与に使えます。Notificationは通知系の副作用に向き、PermissionRequestは権限判断を扱う場面に向きます。

ブロックを期待するなら、どのイベントが実行前に来るのかを確認しなければなりません。公式ドキュメントでは、コマンドフックのexit 2がブロッキングエラーとして扱われ、PreToolUseではツール呼び出しを止める一方、PostToolUseではツールはすでに実行済みです。HTTPフックの場合は、非2xxステータスだけではブロックできず、2xxレスポンスのJSONで明示的なdecisionを返す必要があります。

MCPとフックの設計で最初に見るべきものは、できることの多さではありません。Claude Codeがどの外部システムに触れ、どの時点で人間の判断を求め、どの処理は自動で止めるのかです。AI駆動開発では、AIに任せる範囲が広がるほど、接続権限と検証責任を曖昧にしないことが重要になります。AI駆動開発の考え方でも、AIの出力を人間と仕組みで検証する設計が前提になります。

MCP側では、接続先ごとに読み取りだけで足りるのか、書き込みや更新まで必要なのかを分けます。Issueを読むだけの接続と、PRを作成する接続と、データベースを更新できる接続は同じ危険度ではありません。公式ドキュメントには、MCPツール側で明示的なユーザー承認を毎回要求するメタデータも示されています。重要な操作ほど人間の確認を残す設計にすると、運用後の説明責任を保てます。

フック側では、検査したい対象を具体的にします。Bash全体を広く止めるのか、git pushやrmのような特定操作だけを見るのか、EditとWriteだけにformatを掛けるのかで、開発体験は大きく変わります。厳しすぎるフックは作業を止め、緩すぎるフックは期待した統制になりません。matcherやif条件を使い、最初は小さく始めて、ログと実行結果を見ながら調整するのが現実的です。

外部データを読むだけなら、MCPのスコープと認証を最小にする。実行前に止めたい操作は、PreToolUseやPermissionRequestで扱う。実行後の整形や検査は、PostToolUseで副作用を限定する。通知や監査は、NotificationやPostToolUseに寄せて失敗時の扱いを決める。こうした切り分けがあると、便利な自動化を増やしても、どこで止めるべきかを説明できます。

MCPとフックは排他的な選択肢ではありません。公式ドキュメント上も、フックのハンドラにはmcp_tool型があり、接続済みMCPサーバーのツールをフックから呼べます。ただし、ここで責務を重ねすぎると設計が読めなくなります。MCPで外部システムを操作し、その呼び出しをフックがさらに自動化する場合、失敗時の扱い、権限確認、ログの所在を先に決める必要があります。

たとえば、Claude Codeがファイル編集後にPostToolUseでローカルlintを走らせるだけなら、フック単体で足ります。編集内容に応じて外部のチケットへコメントするなら、MCPでIssue Trackerへ接続し、フックは通知や監査の発火点として使います。DBや本番系APIに関わるなら、MCPツール自体の権限を絞り、PreToolUseで危険な引数を検査し、必要に応じて明示的承認を残します。

組み合わせの判断軸は、「外につなぐ必要があるか」と「実行前に止める必要があるか」です。外につなぐ必要がなければMCPを増やさない。止める必要があるなら、実行後のフックに期待しない。この二つを守るだけでも、設計の見通しはかなり良くなります。

個人のClaude Code設定では便利でも、チームに配ると性質が変わります。projectスコープのMCPやプロジェクト設定のフックは、リポジトリを通じて共有できます。これは再現性を高める一方で、誤った設定も広がります。特に、外部サービスの認証、社内データの読み取り、コマンド実行を伴うフックは、コードレビューと同じ粒度で見る対象です。

導入初期は、MCPを読み取り中心、フックを観測と軽い検査中心に置くと始めやすくなります。通知、format、lint、保護ファイルの検査のように、失敗時の影響が説明しやすいものから着手します。その後、承認フロー、ブロック条件、外部書き込みを段階的に増やす。実際の開発フローに合う統制を増やし、効果は導入後の記録から評価します。

CotomuのAI駆動開発支援では、公開LP上で研修30万円、導入パッケージ50万円から、技術顧問15万円/月、初回60分相談無料として、Claude CodeやCodexなどの活用設計を扱っています。特定ツールの公式パートナーや認定は示していません。生産性や品質向上も保証しません。MCPとフックの設計は、組織の権限管理、レビュー文化、扱うデータの性質に合わせて調整する領域です。

Claude CodeのMCPとフックを安全に使い分ける結論は単純です。MCPは外部ツールやデータへ接続するために使い、フックはClaude Codeの実行タイミングに合わせた自動処理と制御に使います。外部接続の権限をMCPで広げたうえで、実行前の検査、通知、監査、ブロックをフックで補うと、便利さと統制を同じ設計図の中で扱えます。

境界は、MCPでつないだ先の権限と、フックで止められるタイミングを説明できる範囲まで具体化します。Claude Codeには外部接続を広げる仕組みも、自動処理を固定する仕組みも用意されています。だからこそ、先に境界を決める。外へつなぐ責任と、自動で動かす責任を分けたチームほど、Claude Codeを日常の開発に組み込みやすくなります。