2026年のスクレイピング運用は、「ツール呼び出し（Tool calling）」の前提が変わりつつあります。MCP（Model Context Protocol）により、LLMが外部ツールやデータ源へつながる方法が標準化され、ノーコード自動化（n8n / Zapier など）と組み合わせた運用設計が現実的になってきました。一方で、スクレイピングは規約・負荷・セキュリティの論点が多く、設計を誤るとすぐに破綻します。この記事では「MCP×ノーコード×LLM」で、壊れにくい実務フローの作り方を整理します。 MCP（Model Context Protocol）は、LLMアプリ（ホスト）と外部システム（サーバ）をつなぐための標準的な枠組みです。重要なのは「LLMにツールを持たせる」こと自体ではなく、ツール・データ・定型手順を“発見可能な形”で公開し、同じ作法で接続できる点にあります。Anthropic公式ドキュメントでも、MCPをUSB-Cの比喩で説明し、モデルと各種データ源/ツールの接続標準として位置づけています。 実務での要点 公式ドキュメントによると、MCPは「AIモデルをさまざまなデータソースやツールに接続するための標準的な方法」を提供する、という趣旨で説明されています。
MCPで何が変わる
MCPの基本要素
MCPを運用設計で扱うときは、次の3要素を分けて考えると判断が速くなります。
| 要素 | 役割 | スクレイピング運用での例 |
|---|---|---|
| Tools | LLMが呼び出す操作（関数） | 「対象URLを取得」「抽出して正規化」「差分比較」「アラート送信」 |
| Resources | 参照するデータ（読み取り中心） | 抽出対象のDOM例、抽出ルール、過去の失敗ログ、サイト別注意点 |
| Prompts | 定型の指示テンプレ | 「抽出ルールを更新」「失敗原因を分類」「影響範囲を要約」 |
なお、n8nはMCPを扱うためのノードとして、MCPクライアント/サーバ側の機能をドキュメントで案内しています。たとえばMCP Server Triggerは、n8nをMCPサーバとして公開し、外部のMCPクライアントからn8nのツール/ワークフローを呼べる入口になります。
運用が変わる理由
従来の「スクレイピング運用」は、コード（クローラー）と運用（監視・通知・例外処理）が密結合になりがちでした。MCPとノーコード基盤を組み合わせると、次のように分業できます。
- LLM：意思決定、失敗の分類、修正案の提案、要約
- ノーコード（n8n / Zapier）：定常ジョブ、リトライ、通知、ログ収集、台帳更新
- スクレイピング実行基盤：HTTP取得/ブラウザ自動化、プロキシ、レート制御
設計上の結論
LLMは「直接スクレイピングする主体」ではなく、スクレイピング運用を“回す主体”として置くほうが、安全性と再現性が上がります。
ノーコード連携の型
実務での代表的なアーキテクチャを3つに整理します。どれも「LLMに権限を渡しすぎない」ことが共通の設計思想です。
型A: LLMは判断役
スクレイピングは定期ジョブで回し、LLMは失敗時の判断（原因分類、担当者への説明、修正案の提示）だけ担当します。
- メリット：権限設計が簡単、事故りにくい
- 向くケース：価格監視、在庫監視、定型ページの定点観測
型B: LLMがツール選択
LLMがMCP経由で「どの取得手段（HTTP/ブラウザ）を選ぶか」「どの抽出ルールを使うか」を選びます。実行はn8n等に委譲します。
- メリット：サイト差分に強い、例外対応の自動化が進む
- 注意：ツールの権限と入力バリデーションが必須
型C: LLMが運用を修復
失敗ログやDOM差分をリソースとして与え、LLMが抽出ルールの更新案（セレクタ候補や正規表現）を作り、レビュー後に反映します。
注意：LLMが生成した修正を自動適用すると、誤抽出（静かに壊れる）リスクが上がります。最低限「サンプルでの検証」「差分の可視化」「承認フロー」を入れてください。
実務フロー設計
ここからが本題です。MCP対応で設計すべき運用フローを「作る順番」で並べます。
1. データ契約を決める
最初に「出力の形」を固定します。スクレイピングは取得よりも、正規化と差分比較で失敗しがちです。
- 項目名（例：price、currency、availability）
- 型（数値/文字列/真偽値/日時）
- 欠損時の扱い（null許容、前回値の継承可否）
- 同一性キー（商品ID、URL正規化など）
2. 取得手段を二段構え
HTTP取得だけで足りるページと、ブラウザ実行が必要なページを分けます。ブラウザ実行はコスト/負荷/ブロックのリスクが上がるため、常用しない設計が現実的です。
おすすめ
- 通常：HTTP（高速・安価）
- 失敗時のみ：Playwright等のブラウザ自動化（重いが強い）
3. 監視は3点に絞る
監視項目を増やすほどアラートが増えて運用が破綻します。まずは次の3点に絞ると回ります。
- 成功率（URL単位/サイト単位）
- 抽出品質（必須項目欠損率、型エラー率）
- 変化量（価格などの急変検知、異常スパイク）
4. LLMへの入力を制限
LLMにDOM全文やログ全文を渡すと、コスト増だけでなく情報漏えい面でも不利です。MCPの「Resources」や「Prompts」を使う場合も、必要最小限に整形した断片を渡す運用が堅いです。
n8nでの実装例
n8nはMCPクライアントとして外部MCPサーバを呼ぶだけでなく、MCPサーバとして自分のワークフローを外部AIエージェントから呼び出せる導線があります。用途に応じて使い分けます。
| やりたいこと | 向く機能 | ポイント |
|---|---|---|
| 外部MCPツールを使う | MCP Client系 | LLMが呼ぶツールを限定し、入力を検証する |
| 自分の処理をMCP化 | MCP Server Trigger | 公開範囲（内部/外部）と認証を最初に決める |
Zapier連携の要点
ZapierはMCPサーバとして、AIアシスタントからZapier上の多数のアクションを呼べる導線を整備しています。ノーコードで「実行環境（Zap）」を持ち、MCP経由でツールとして公開する、という発想です。
運用視点の要点
- 最初は「読み取り系」アクション中心にする
- 書き込み系（登録/削除）は承認ステップを挟む
- スクレイピング結果の格納先（Sheets/DB/CRM）を先に決める
スクレイピングの注意
MCPで“つながる”ほど、やってはいけないことも増えます。特にスクレイピングは、規約・技術・セキュリティの3点セットで設計してください。
規約とrobots.txt
サイトの利用規約やrobots.txtは、技術的に回避できる/できないとは別に、運用上のリスク判断に直結します。チーム運用では、対象サイトごとに「許容/要申請/禁止」を台帳化しておくとブレません。
負荷とレート制御
運用で一番揉めるのは「落ちる」「遅い」よりも「相手に迷惑をかける」です。URL数が増えるほど、固定間隔のクロールは破綻しやすいので、ドメイン単位の同時実行数・待ち時間・リトライ間隔を管理します。
アンチボット対策
Playwrightなどのブラウザ自動化は有効ですが、検知回避だけを目的化すると運用が不安定になります。まずは取得経路の簡素化（HTTPで取れるならHTTP）、次に必要最小限のブラウザ実行、という順番が堅実です。
セキュリティ設計
MCPは便利ですが、ツール連携が増えるほど「プロンプトインジェクション」「権限の連鎖」「ツールの差し替え」などの攻撃面が広がります。実際にMCPサーバに関する脆弱性の報道もあり、ツールの公開範囲や権限管理は必須です。
注意：LLMに「ファイルシステム操作」「任意URL取得」「シェル実行」などを同時に与えると、単体では安全でも組み合わせで危険になります。MCPのツール設計は、権限を小さく分け、できるだけ読み取り中心に寄せてください。
MCPツール定義例
最後に、スクレイピング運用で使いやすい「ツール定義」の粒度感を示します。ポイントは、LLMに“自由回答”させず、入力と出力を構造化して運用に載せることです。
{
"name": "scrape_product_page",
"description": "商品ページから価格と在庫を抽出して正規化して返す",
"input_schema": {
"type": "object",
"properties": {
"url": { "type": "string", "description": "対象URL" },
"strategy": { "type": "string", "enum": ["http", "browser"], "description": "取得方式" },
"timeout_ms": { "type": "integer", "minimum": 1000, "maximum": 60000 }
},
"required": ["url", "strategy"]
},
"output_schema": {
"type": "object",
"properties": {
"ok": { "type": "boolean" },
"price": { "type": ["number", "null"] },
"currency": { "type": ["string", "null"] },
"availability": { "type": ["string", "null"] },
"observed_at": { "type": "string" },
"raw_evidence": { "type": "object" }
},
"required": ["ok", "observed_at"]
}
}設計のコツ
- strategyで「普段はhttp、失敗時のみbrowser」を誘導する
- raw_evidenceは最小限（根拠テキストやセレクタ一致結果など）にする
- observed_atは必ず持たせ、差分検知の前提にする
スクレイピングを運用しませんか？
MCP×ノーコード×LLMで、壊れにくいスクレイピング運用を設計できます。要件整理から監視・権限設計まで、運用前提でご相談ください。
まとめ
- MCPは「LLMと外部ツール/データの接続標準」で、スクレイピング運用を分業しやすくします
- LLMは実行者ではなく、判断・分類・修復提案の役に寄せると安全です
- ノーコード基盤は定常運用（監視/通知/台帳）に強く、MCPでツール化すると拡張しやすいです
- 権限設計と入力バリデーション、承認フローがないと事故が起きます
運用を成功させる近道は、「何でも自動化」ではなく、壊れたときに戻せる仕組みを先に作ることです。MCP対応は、そのための設計の選択肢を増やしてくれます。
参考資料
