MCPで業務ツールをつなぐ
AIエージェント実装の設計パターン
MCP（Model Context Protocol）とツール設計で、社内ツール連携と自動化を安全に回すための実装パターンをまとめます。Netsujoが自社運用で得た知見をもとに、導入検討から実装初期までのITエンジニア向けに整理しました。
AIエージェントを「触ってみた」段階から「業務で常用する」段階へ進めるとき、最初の壁になるのが外部システムとの接続です。チャット相手として優秀でも、GA4のレポートを取得し、Strapiの記事データを書き換え、Google Docsに資料を生成する、といった実作業はAgent単体ではできません。ここを埋める標準化された選択肢の1つがMCPです（function calling直結や独自API連携でも実現はできます）。本稿では、MCPで何が解決でき、ツールをどう設計し、権限とサンドボックスをどう切り、どこでつまずくか、そして段階的にどう導入するかを実装目線で扱います。
この記事の要点
- ▸MCPは、AIエージェントと外部ツール・データソースをつなぐ共通プロトコルです。連携の追加・差し替えが、プロンプト改変ではなくサーバ設定で完結します。
- ▸ツール設計は「動詞1つの粒度で切る」「スキーマと説明をAgentの一次資料にする」「戻り値は構造化し失敗を握りつぶさない」の3原則が軸になります。
- ▸権限は最小権限と、読み取り・書き込みの分離が原則です。読み取りは自動、不可逆な書き込みには人間の承認を挟み、読み取り専用から段階的に広げます。
— 01
MCPは何を解決するか
MCPは、AIエージェントと外部ツール・データソースをつなぐための共通プロトコルです。Agentが「GA4の先週のセッション数を取得する」「Notionの議事録を読む」といった操作を、統一された形式の「ツール呼び出し」として実行できるようにします。
MCPがない世界では、外部連携のたびに個別のグルーコードを書き、Agentのプロンプトにツールの使い方を埋め込み、結果のパースもその都度実装することになります。連携先が増えるほどこの実装が散らばり、保守が破綻します。MCPは、ツールの定義（名前・入力スキーマ・説明）とその実行をサーバ側に分離し、Agentからは規格化された一覧として見えるようにします。連携先の差し替えやツールの追加が、プロンプト改変ではなくサーバ設定で完結する点が実務上の利点です。
Netsujoでは、Claude Codeを実行基盤として複数のMCPサーバを併用しています。具体的には、Google Search Console、GA4、Google Workspace、Notion、デザイン連携のPencil、セッションをまたぐ記憶のMemory、本番サイト計測のChrome DevToolsなどです。一例として、週次のGA4レポートは、データ取得からGoogle Docsへの生成、Discordへの投稿までを一連のツール呼び出しでつなげています（社内事例）。
ただし、MCPは万能の接着剤ではありません。連携先のAPIが提供しない操作はMCP経由でも当然できません。MCPは「APIでできることをAgentから扱いやすくする」層であって、APIの限界そのものは超えません。
— 02
ツール設計の3原則
MCPサーバで公開するツールの設計品質が、そのままAgentの動作の安定性を決めます。次の3つを軸にすると、失敗時の原因切り分けと実行の再現性が高まります。
動詞1つの粒度で切る
ツールは「動詞1つ」の粒度で切ります。update_blog_postのように1つの明確な操作へ対応させ、manage_contentのような多目的ツールは避けます。1ツール1責務にすると、入力スキーマが単純になり、失敗時の原因切り分けも容易になります。
スキーマと説明をAgentの一次資料にする
入力スキーマと説明文を、Agentの一次資料として書きます。Agentはツールのdescriptionと各引数の説明を読んで使い方を判断します。必須・任意の区別、列挙可能な値、単位、上限値などをスキーマに落とし込むほど、実行は安定します。
戻り値は構造化し、失敗を握りつぶさない
戻り値は構造化し、失敗を握りつぶしません。成功時は機械可読な構造で返し、失敗時はエラー種別と原因をテキストで返します。
ツール定義の例（fetch_ga4_report）
{
"name": "fetch_ga4_report",
"description": "GA4から指定期間のセッション数・ユーザー数を取得する。期間は最大90日。",
"inputSchema": {
"type": "object",
"properties": {
"propertyId": { "type": "string", "description": "許可リスト内のproperty IDのみ受理" },
"startDate": { "type": "string", "description": "YYYY-MM-DD形式" },
"endDate": { "type": "string", "description": "YYYY-MM-DD形式。startDateから最大90日" },
"metrics": { "type": "array", "items": { "enum": ["sessions", "totalUsers", "screenPageViews"] } }
},
"required": ["propertyId", "startDate", "endDate", "metrics"]
}
}descriptionに上限値や受理条件を書き、requiredで必須引数を明示するほど、Agentの呼び出しは安定します。
— 03
権限とサンドボックス
原則は「最小権限」と「読み取りと書き込みの分離」です。MCPサーバへ渡す認証情報のスコープを絞ります。GA4なら読み取り専用、Search Consoleなら対象サイトのみ、といった具合に、Agentが触れる範囲をサービスアカウントやトークンのスコープで物理的に制限します。
破壊的操作を分離します。データ取得や下書き生成はAgentに任せても、本番反映・公開・送金といった不可逆な操作には人間の承認を挟みます。読み取りは自動、書き込みは段階承認、という線引きを最初に決めておくと、後から事故が起きにくくなります。
以下は社内ポリシーを表す疑似コードで、accessやrequireApprovalはMCP標準の設定項目ではありません。権限の切り方をイメージするための例として示します。
{
"servers": {
"gsc": { "access": "read-only", "scope": ["sc-domain:example.com"] },
"ga4": { "access": "read-only", "scope": ["properties/123456789"] },
"workspace-docs": { "access": "read-write", "requireApproval": false },
"cms-publish": { "access": "write", "requireApproval": true },
"payments": { "access": "deny" }
}
}— 04
つまずきやすい失敗パターン
MCPでの連携は、設計よりも運用の細部でつまずきます。事前に把握しておくと回避しやすい代表的なパターンを挙げます。
トークンの失効と再発行忘れ
OAuthアクセストークンなど期限付きの認証情報は、切れると連携が静かに止まります（APIキーやサービスアカウント鍵は実装により挙動が異なります）。認証情報を環境変数へ集約し、失効・ローテーションに備える仕組みを用意します。
存在しない機能への期待
Agentは説明文から「できそう」と判断して呼び出しますが、連携先APIにその操作がなければ失敗します。descriptionに「できないこと」も明記します。
戻り値の沈黙
失敗を空の結果で返すと、Agentは成功したものとして次へ進みます。エラーは必ずエラーとして返します。
権限の過剰付与
最初は読み取り専用で動かし、必要が確認できた操作だけ書き込み権限を足していく順序が安全です。
承認フローの曖昧さ
不可逆操作は明示指示でのみ動かす運用へ統一します。
— 05
MCPと自作スクリプトの使い分け
判断の軸は「Agentが対話の中で動的に呼ぶ必要があるか」です。Agentがタスクの文脈に応じて呼び分ける操作はMCPが向きます。毎週決まった時刻に必ず実行する定型バッチは、スケジュール実行のスクリプトが適します。判断が要らない定型処理は、Agentを通さないほうが速く、安く、壊れにくくなります。
— 06
段階的導入ロードマップ
一度に全部を自動化しようとせず、握り続ける範囲を明確にしながら段階的に広げると、自動化の拡大と統制を両立できます。
第1段階：読み取り専用の単一連携
書き込みを伴わない1つのデータソースをMCPで接続し、集計や下書き生成をさせます。
第2段階：書き込みの段階承認
下書きの生成までをAgentに任せ、本番反映に人間の承認を挟みます。
第3段階：複数Agentとの共用と監査
誰が何を実行したかの記録と、第三者による成果物のチェックを仕組みに組み込みます。
各段階で「人間が握り続ける範囲」を明確にしておくと、自動化の拡大と統制を両立できます。Netsujoの運用全体の考え方はAIエージェントで会社を回すに、Claude Codeを使った開発の流れはClaude Code仕様駆動開発にまとめています。
— 07
よくある質問（FAQ）
Q. MCPは必ず導入すべきですか。
連携が1つか2つで定型バッチで足りるなら、無理に導入する必要はありません。MCPが効くのは、Agentが対話の中で複数の外部ツールを動的に呼び分ける場面です。
Q. Agentに本番環境を触らせても安全ですか。
読み取りは比較的安全に任せられますが、本番反映・公開・送金などの不可逆な操作には人間の承認を挟むことを推奨します。
Q. 社内の非公開情報を外部AIに送る不安があります。
外部送信をデフォルトでブロックして例外のみ許可する設計が有効です。
Q. 自作の社内ツールもMCP化できますか。
社内APIがあれば、それをラップするMCPサーバを実装してAgentから扱えます。
Q. 導入の効果はどれくらい見込めますか。
削減率のような数値は環境や対象業務に強く依存するため、一般化した断定は避けます。まず読み取り専用の小さな連携で効果を実測してから広げる進め方を推奨します。
まとめ
MCP（Model Context Protocol）は、AIエージェントと外部ツール・データソースをつなぐ共通プロトコルです。ツールの定義と実行をサーバ側に分離することで、連携の追加・差し替えがプロンプト改変ではなくサーバ設定で完結します。
ツール設計は「動詞1つの粒度で切る」「スキーマと説明をAgentの一次資料にする」「戻り値は構造化し失敗を握りつぶさない」の3原則が軸です。権限は最小権限と読み書きの分離を原則とし、不可逆な操作には人間の承認を挟みます。
つまずきは設計よりも運用の細部に出ます。トークン失効・存在しない機能への期待・戻り値の沈黙・権限の過剰付与・承認フローの曖昧さに備えておくと回避しやすくなります。導入は読み取り専用の単一連携から始め、段階承認、複数Agentとの共用と監査へと広げる進め方が現実的です。
この記事の著者
この記事が向いている方
AIエージェントを業務に常用したいITエンジニア
MCPでの社内ツール連携・自動化を検討している方
権限設計やサンドボックスの切り方に悩んでいる方
— 壁打ち相談
読者のよくある相談
記事を読んだ後に「自分の状況だとどう判断すべきか」を整理するための壁打ち相談を受け付けています。下記のような相談例が当てはまる方は、お気軽にご連絡ください。
Q. 自社の業務でMCPを使うべきか判断したい
連携の数と、Agentが対話の中で動的に呼び分ける必要があるかを基準に、MCPと定型バッチスクリプトの使い分けを貴社の業務を題材に整理します。
Q. 権限と承認フローをどう設計するか
最小権限・読み書き分離・不可逆操作の承認といった線引きを、サービスアカウントやトークンのスコープに落とし込む進め方をご相談ください。
上記いずれかが該当する場合、初回30分の壁打ち相談で論点整理に対応します。記事に書ききれない個別事情を踏まえた判断材料が必要な段階こそ、壁打ちが活きやすいフェーズです。
関連するサービス
AIエージェント開発｜Netsujo
無料相談を申し込む
MCPでの社内ツール連携やAIエージェント実装に関するご相談を受け付けています。要件が固まっていない構想段階からでも構いません。