Apify MCP Serverの使い方——数千のスクレイパーをAIの道具にする前に決める2つ

AIエージェントに「このサイトの情報を取ってきて」と頼んで、素直に取ってこられなかった経験はありませんか？

だいたい、途中でログインを求められるか、JavaScriptで描かれていて空っぽが返ってくる。

この壁を、スクレイパーを自分で書かずに越えるための道具が Apify MCP Server です。

MITライセンス、TypeScript製。やっていることは一言で言えます。Apify Storeに並んでいる出来合いのスクレイパーを、AIの道具として使えるようにする。

ただ、使い始めるときに決めることが2つあって、ここを飛ばすと後から効いてくるんですよね。

本記事で答えるのは「Apify MCP Server の使い方として、接続方式とツール構成をどう決めるか」という問いです。私は、この2つを先に決めておくべきだと考えています。

Apify MCP Serverの使い方は、接続の形から始まる

まず入口から。繋ぎ方が2つあります。

ホスト版は https://mcp.apify.com に繋ぐ形です。Streamable HTTPで、OAuthに対応しているので、Claude.aiやVS CodeのようなクライアントからはURLを入れるだけで繋がります。トークンをヘッダで渡す形（Authorization: Bearer <APIFY_TOKEN>）でも動きます。

ローカル版は stdio で立てる形。

npx @apify/actors-mcp-server

こちらは APIFY_TOKEN を環境変数で渡します。Claude for Desktopのようなローカルのクライアントと組むならこちら。

古い情報を見て /sse を付けている人がいるかもしれませんが、そのエンドポイントは削除されています。設定から /sse を落として、Streamable HTTPへ移すよう案内が出ています。

決める1: ホスト版とローカル版は、機能が同じではない

ここが1つめ。

普通、こういう選択は「手元で動かすか、預けるか」の好みの話で終わります。今回は違いました。

READMEにはっきり書かれています。ホスト版は、ローカルのstdioでは使えない最新機能に対応していると。名指しされているのは、Actorの結果に対する出力スキーマの推論です。

もう1つ、後から効いてくる差があります。

レンタルActorは、ホスト版でしか使えません。ローカルのstdioで動かした場合、使えるのは既に手元のツールセットに入っているActorだけです。Apify Storeの中を探し回って好きなものを呼ぶ、という使い方はホスト版が前提になっている。

いや、ローカルのほうが安全そうだから、と思いますよね。

私も最初はそう考えました。ただ、この道具のいちばんの価値はその場で必要なスクレイパーを見つけて使うところにあるので、そこを削るとかなり別物になります。

なので、選び方はこうなりました。動的に探させたいならホスト版。使うActorが最初から決まっているならローカル版でも足りる。

決める2: tools を指定した瞬間、既定のツールは消える

2つめが、いちばん引っかかりやすいところ。

何も指定しないと、サーバーは4つを読み込みます。actors、docs、それと apify/rag-web-browser と apify/web-fetch という2つのActorです。

ここで tools を指定して絞り込もうとすると——

https://mcp.apify.com?tools=actors,docs

指定した瞬間、既定のツールは含まれなくなります。足すのではなく、置き換えです。

READMEの書き方も明確で、「tools パラメータが指定された場合、リストされたツールやカテゴリだけが有効になり、既定のツールは1つも含まれない」。

これを知らずに tools=storage とだけ書くと、Actorを探す手段ごと消えるわけです。

ローカル版でも同じで、渡し方はこう。

npx @apify/actors-mcp-server --tools actors,docs,apify/rag-web-browser

逆に、この挙動は絞り込みたいときには気持ちいいです。使うActorが1つに決まっているなら、tools=apify/my-actor だけ書けば、探索も汎用の呼び出しも載らない最小構成になります。

AIに渡す道具は少ないほど迷わない。だから、うちはこの形を好んで使っています。

データは call-actor の返事には入っていない

使い始めて最初につまずくのが、たぶんここ。

Actorを呼ぶ流れはこうなっています。

• search-actors で探す

• fetch-actor-details で入力スキーマを見る

• call-actor で実行する

• get-dataset-items で結果を取り出す

ところが、call-actor の応答に取ってきたデータは入っていません。返ってくるのは実行のメタデータ、ストレージのID、それと summary と nextStep です。

データ本体は、nextStep に従って get-dataset-items を datasetId 付きで呼ぶと取れる。

このツールは自動で差し込まれる仕組みになっていて、call-actor かActorのツール、あるいは get-actor-run が載っている構成なら、次の4つが勝手に付いてきます。

• get-actor-run（実行の詳細を見る）

• get-dataset-items（結果を取り出す）

• get-key-value-store-record（保存された値を読む）

• abort-actor-run（走っている実行を止める）

個人的には、この自動注入がいちばん親切なところだと思います。手で並べる必要がないので。

つまり、2段構えなのは仕様です。1回のツール呼び出しで全部返ってくると思っていると、空の返事を見て壊れたと勘違いします。

理由も納得できるもので、スクレイピングの結果は大きくなりがちだからです。リソースの応答も256KBまではそのまま返り、それを超えるとダウンロードURLに切り替わる作りになっています。

256KBというのは、テキストにして日本語で8万字くらい。1回のスクレイピングで軽く超えます。

知っておくと迷わない、切り詰めの仕様

もう1つ、地味に効く話を書いておきます。

Actorの説明文は500文字で切られます（MAX_DESCRIPTION_LENGTH）。enumの選択肢も、全部合わせて2000文字が上限です（ACTOR_ENUM_MAX_LENGTH）。

これはバグではなくLimitationsとして明記されている挙動で、理由は察しがつきます。AIに渡す道具の説明が長すぎると、それだけで文脈を食うから。

ただ、副作用として入力の選択肢が多いActorは、説明が途中で切れた状態でAIに渡ります。思ったパラメータを使ってくれないときは、まずここを疑うと早いです。

対策は単純で、fetch-actor-details を先に呼ばせて、必要なパラメータを自分で確認してから指示に書く。うちはそうしています。

Apify MCP Serverを、5分だけ試す

Apifyのアカウントを持っているなら、いま使っているMCPクライアントの設定に、Apify MCP Server の接続先としてこの1行を足してください。

https://mcp.apify.com?tools=actors,docs

Actorを探す機能とドキュメントを引く機能だけの、いちばん小さい構成です。実行のツールは載っていないので、何も実行されません。

その状態で、AIに「このデータを取れるActorを探して」とだけ聞いてみる。

返ってきた候補が現実的なら、その次に実行のツールを足せばいい。探索と実行を分けて試すのが、この道具のいちばん安全な入口でした。

▶ 関連記事: OpenWork の使い方——スキルとMCPを1箇所に置いて、どのAIからでも同じものを呼ぶ

オープンソースのAIツールを実際に動かして確かめた記録と、選ぶときの判断基準をまとめた資料を用意しています。

👉 オープンソース研究所6大特典を受け取る

#MCP #Apify #OSS #AIエージェント #スクレイピング #TypeScript #ClaudeCode #自動化 #データ収集 #生成AI #オープンソース #API