MCP対応を謳うツールを見つけたら、機能一覧より先に「書き込み系のツールが何本あるか」を数えた方がいい。これが今回の結論です。読み取りしか生えていないMCPは、調査を自動化できても運用を自動化できません。人間がUIを開く作業がそこに残り続けます。
実際に採用を検討した1つのツールの調査記録を通して、この評価軸に行き着くまでを書きます。主役はツールではなく「read/writeを数える」という判断基準の方です。
キーワード選定が専門語に寄るという課題
発端はSEOツールの話でした。SNSとブログの運用を自動化するシステムを回している中で、キーワード選定が専門語に寄りすぎるという課題を抱えていました。発注側が実際に検索する一般語へ広げたい。でも判断材料になる検索ボリュームの実数が無く、推測で書いている状態でした。
ボリュームの実数が取れるツールを繋げば解決するはず。そう考えて候補を探し、OSSのSEOツール「OpenSEO」に行き当たりました。
OpenSEOを見つけて、設計まで一気に描いた
OpenSEOはSemrush / AhrefsのOSS代替を掲げるツールです。MITライセンスで、GitHubの every-app/open-seo で公開されています。
調べるほど、うちの構成に噛み合っているように見えました。
- リポジトリに
wrangler.jsoncとalchemy.run.tsがあり、公式のセルフホスト手段はDocker（ローカル用）とCloudflare（チーム・複数端末用）の2択。公式手順にはCloudflareの無料プランで動くと明記されています pnpm deploy:selfhost一発で、D1・KV・R2・Worker・Cloudflare Accessのログインゲートまでプロビジョニングされる- Docker版は
AUTH_MODE=local_noauth（認証チェック無し・単独管理ユーザー）なのでローカル専用。常時稼働させるならCloudflare一択 - データ取得はDataForSEOへの従量課金。最低デポジット$50で、残高に有効期限なし、月々の最低消費もなし。残高が尽きてもAPIが
40200エラーを返すだけで、事故で課金が膨らむ構造ではない - 登録時の無料トライアル$1で、キーワード検索ボリュームの取得が16,000回以上できる
- 注意点として、R2の有効化には無料枠の範囲でもCloudflare側に支払い方法の登録が必要
料金の桁感も掴めました。SERP取得は標準キューで$0.0006/件、優先キューで$0.0012/件、ライブで$0.002/件。キューの選び方だけで請求が3倍以上変わります。入金額ボーナスもあり、SERP単価は1,000件あたり$0.60が、$100入金で$0.06、$500入金で$0.03まで下がります。年$50程度で収まりそうだと試算しました（これは自社の想定規模からの見積もりで、実測ではありません）。
ここまで分かった時点で、設計を一気に描きました。単価の安いボリューム・CPC照会は日次のリサーチ工程へ、単価の重いSERP・競合・被リンクは月次の診断工程へ、という単価による工程分離。CPCを商用意図の代理指標にする使い道も見えていました。専門語はボリュームが小さいだけでなくCPCもほぼ付かないはずで、CPCで足切りすれば「読まれるが問い合わせに繋がらない記事」を機械的に除外できる、という見立てです。
毎日1本記事を出す運用では、2〜3ヶ月で自記事同士のカニバリが起きます。カニバリは「順位が上がらない」という形でしか現れず、閲覧数中心の計測では検知できません。順位データを月次で取る仕組みは、その意味でも欲しいものでした。
MCPのツール一覧を数えたら、月次の設計が崩れた
問題は操作です。GUIで設定できるほどSEOに詳しくないので、「繋げたらエージェントが設定まで代行してくれるのか」が採用の条件でした。そこでMCPとして公開されているツールの一覧を確認しました。
OpenSEO公式：MCPで公開されているツール一覧Give Claude, Cursor, or any MCP client real SEO tools: keyword research, live SERPs, backlinks, rank tracking, and Search Console data via one MCP server.openseo.so
公開ツールは9本。内訳はこうです。
- キーワード系4本: キーワードリサーチ（ボリューム・難易度・CPC）／SERP取得／キーワード保存／ランクトラッカーのデータ取得（読むだけ）
- 競合系3本: ドメイン概要／ドメインのランクキーワード／被リンク概要
- Search Console系2本: パフォーマンス／URL検査。読み取り専用でクレジットを消費せず、Google Cloudプロジェクトの作成もOAuth認証情報の用意も不要
書き込みは「キーワードを保存」の1本だけ。残り8本はすべて読み取りです。プロジェクトの作成、Search Consoleプロパティの接続、ランクトラッカーの作成（読むのはできる）、サイト監査の実行、AI可視性やPrompt Explorerの分析機能は、MCPからはできません。
痛かったのは自分の判断ミスです。機能ページの一覧を見た段階で、私はAI可視性の機能を優先度4位に推し、月次側に置く前提で設計まで語っていました。その直後にMCPのツール一覧を確認したら、AI可視性とサイト監査はそもそもMCPツールとして公開されていませんでした。Webアプリ側の機能です。機能ページの一覧とMCPのツール一覧は別物。当たり前ですが、踏み抜くまで気づきませんでした。
月次でエージェントに回させる前提で立てた計画は、確認した瞬間に崩れました。完全無人化はできず、プロジェクト設定やトラッカー作成のためにUIを人間が開く作業が残ります。「MCP対応」と「エージェントに任せられる」は、別の話だったわけです。
ブラウザ自動操作で埋める案を3つの理由で却下した
反射的に「足りない部分はブラウザ自動操作で埋めればいい」と考えました。エージェントにブラウザを渡して、UIの設定作業を代行させる案です。これは3つの理由で却下しました。
- OAuth認証はどのみち人間がやる。 Search Console接続のような認証フローを自動化に含めるべきではなく、ここを自動化しても人間の関与は消えない
- 無人実行のスケジュールから呼べない。 ブラウザ操作は自分のマシンが起動している前提になり、定時実行の基盤に乗らない
- 成否の検証がスクリーンショット頼りになる。 「通知が真実であること」を土台にしてきた運用思想と噛み合わない。APIの応答なら成否を機械判定できるが、画面の見た目では「できたように見える」を排除できない
ブラウザ自動操作は「人間がやることをそのまま速くする」手段としては便利ですが、無人運用の部品としては検証可能性が足りない、というのがうちの判断です。
足りないMCPツールは、自分で生やせばいい
却下した代わりの結論が「自分で書く」です。MITライセンスでソースが手元にある以上、足りないMCPツールは自分で生やせます。プロジェクト作成もトラッカー作成も機能自体は実装済みで、MCPの口が生えていないだけでした。
楽観だけではありません。対象は公開APIではなくNext.jsアプリの内部エンドポイントなので、upstreamの更新で黙って壊れる可能性があります。ただし同一リポジトリ内なので、壊れた瞬間に原因コードが目の前にあります。追従は手動の git pull → pnpm deploy:selfhost なので、寝ている間に勝手に壊れる事故も起きません。フォークに変更を抱え続けると追従コストを払い続けるので、汎用的に書いてupstreamにPRを出す方が最終的に楽だと考えています（マージされる見込みは推測です）。
自前のMCPサーバーに公開系のツールを実装した経験からも、この方向は現実的だと判断しました。
自作MCPサーバーに「投稿し過ぎない」制限を実装した記録｜制限はプロンプトではなくサーバーに置くAIエージェントに投稿ツールを渡すと放っておくと公開し過ぎます。その制限をプロンプトではなく自作MCPサーバー側（Cloudflare WorkersのKV）に置いた実装記録。単純なカウントではなくreserve→commit/releaseの二段階にした理由と、失敗時に枠を戻す設計まで解説します。www.tentspace.net
補足を2つ。まず、OpenSEOにはMCPとは別にAgent Skillsが9本用意されています（プロジェクト設定／SEOコーチ／SEO監査／キーワードリサーチ／キーワードクラスタリング／競合ランドスケープ／競合分析／リンクプロスペクティング／ローカルSEO）。npx skills add every-app/open-seo --skill '*' --agent claude-code でスラッシュコマンドとして入ります（公式のスキル一覧）。SEOの知識が無いことは、実は障壁になりません。GUI側に残る作業は「接続ボタンを押す」だけでSEOの判断を含まず、判断が要る部分はスキルが担当するからです。
もう1つはコストガードです。DataForSEOのキーを握ったエージェントは、悪意ゼロでもループで残高を溶かせます。キーを渡す前に支出上限を設定してください。DataForSEOはリクエスト失敗時の即時返金と、未使用分の30日返金ポリシーがあります（公式ヘルプ）が、成功したリクエストの浪費は返ってきません。
なお、Cloudflare Accessでゲートした自前WorkerへスケジュールからMCP接続できるかは未検証です。ここは導入前に確認が必要な点として残っています。
評価軸として残ったのは「writeを数える」
一連の調査で残ったのは、汎用の判断基準が1つです。
MCP対応を謳うツールを検討するときは、機能一覧ではなく、MCPとして公開されている書き込み（write）ツールの本数を数える。read専用に近いMCPは「調査の自動化」はできても「運用の自動化」はできず、人間の手作業が残る場所を最初から固定します。逆にwriteが揃っていれば、エージェントに委ねられる範囲は一気に広がります。
数えるのは数分で終わります。私はそれをせずに機能一覧から設計を描き、確認した瞬間に崩れました。最初に数えていれば、自動化の設計は最初から変わっていたはずです。
そしてもう1つ。writeが足りなくても、OSSなら自分で塞げます。read/writeの比率は「採用可否」だけでなく「採用するなら何を自分で書くか」の見積もりにも使えます。
ちなみにこの記事自体、チャットでの検討をそのまま発注書に起こす仕組みから生まれています。仕組みに興味があればこちらもどうぞ。
チャットの雑談を翌日ブログにする仕組み｜「発注書」方式とDialogue導入の実装記録チャットで生まれた知見を翌日のブログ記事に変える導線を作った実装記録。要約ではなく「発注書」を書かせる理由、体験談や数値を原文のまま運ぶ節構成、冒頭だけ会話にするDialogueコンポーネントの運用ルールまで、実際に動かしている構成を解説します。www.tentspace.net