あるグロースマーケティング・コンサルタントは、Model Context Protocol (MCP) サーバーを構築することで、14個ものブラウザタブと果てしないスプレッドシートからデータを抽出するために午後を丸ごと費やす日々を終わらせました。このサーバーにより、AIアシスタントが Google Ads、Meta、GA4、Search Console からデータを取得し、それに基づいたアクションを実行できるようになりました。現在では、手動での指示なしに月次レポートの作成、監査の実行、最適化の適用が行われており、マーケターはデータの整理ではなく、戦略に集中できるようになっています。
なぜこの転換が重要だったのか
有料検索、ソーシャル、アナリティクス・プラットフォームのレポート作成は、かつては手作業による一連の工程（各ダッシュボードを開き、数値をスプレッドシートにコピーし、不一致を調整してからインサイトを書き出す）でした。この作業は貴重な時間を奪い、ヒューマンエラーを招く原因となっていました。MCPは、AIに各プラットフォームのネイティブなクエリ言語やAPIへの直接的なアクセス権を与えることでワークフローを一変させ、「数値を教えて」という指示を「数値を取ってきて」に変えたのです。
技術的な基盤
MCPは、LLMを活用したアシスタントが推論プロセスの一環として外部ツールを呼び出せるようにするプロトコルです。実際、このコンサルタントは、各プラットフォームの生のクエリ言語（Google Ads → GAQL）と、Meta、GA4、Search Console の標準的な REST エンドポイントを公開する小さなウェブサービスを構築しました。AIはクエリを構築してサーバーに送信し、構造化された結果を受け取ります。さらに、書き込み操作（write-operations）を実行した後に、検証のための読み取り（verification reads）を行うことも可能です。
効果を発揮した3つの設計上の選択
- 薄いラッパー（thin wrappers）ではなく、ネイティブなクエリ言語を公開する – 最初の試みでは、データニーズごとに個別の関数（例：
get_campaigns）を記述していました。しかし、新しいレポートの切り口が増えるたびにコードベースが膨れ上がってしまいました。GAQL を直接公開することで、単一のエンドポイントを通じて AI が必要なあらゆるクエリをドラフトできるようになりました。アシスタントによる GAQL の構成はコンサルタントの手動スクリプトを凌駕し、同じパターンが他のプラットフォームでも有効でした。 - すべての書き込みを読み取りで検証する – API は、変更が反映されていない場合でも成功フラグを返すことがよくあります。現在のサーバーは、書き込みのたびにデータを読み戻します。期待される値が見つからない場合は、失敗をログに記録し、ユーザーに通知します。このガードレールにより、パフォーマンスデータを損なう可能性のあるサイレントエラーを防いでいます。
- Markdown のエラーログを維持する – すべてのバグ、入力ミス、誤解されたルールは
learned-errors.mdに記録されます。AI は各セッションの開始時にこのファイルを読み込み、何を繰り返してはいけないかを自ら学習します。
時間を浪費した3つの落とし穴
- ツールとインポート間の名前の衝突 – 関数名がインポートしたモジュールと同じ名前であったため、実行時にサーバーがクラッシュしました。各インポートに個別のエイリアスを付与することで、この衝突を解消しました。
- ホットリロードの軽視 – MCP サーバーは起動時に一度だけコードを読み込んでいました。そのため、コードベースを変更してもクライアントプロセス全体を再起動するまで変更が反映されず、動いていないコードのデバッグに何時間も費やすことになりました。編集のたびに完全な再起動ワークフローを追加することで、この問題は解決しました。
- 依存関係の不足 – 仮想環境に存在しないインポートが紛れ込んでいたため、起動時にサーバーが停止しました。現在は、再起動前に事前チェック（pre-flight checks）を行い、必要なすべてのパッケージをインストールして検証することで、問題を早期に発見しています。
まとめ
ささやかな MCP サーバーであっても、労力の大きいレポート作成の儀式を、自動化された監査可能なワークフローへと変えることができます。ただし、それには規律あるコーディング慣行と、小規模なサービスを維持する意欲が必要です。セットアップに時間を投資するマーケターは、スプレッドシート作業の苦行を、戦略的な分析へと置き換えることができるのです。