Agent Reach をサーバーで実測、doctorの✅4件中2件は疎通未確認

はじめに

AI エージェントに Web を読ませたいだけなのに、Twitter API も Reddit API も有料で、結局スクレイピングの面倒を見るのは自分、という状態になりがちです。対象読者は、Claude Code や OpenClaw などの CLI エージェントに外部サイトの読み取り機能を持たせたい開発者です。

そこに GitHub で 60.8k stars（2026年7月26日時点のリポジトリページ表示）を集めている Agent Reach があります。「1つの CLI で Twitter・Reddit・YouTube・GitHub・Bilibili・小紅書を読む、API 料金ゼロ」と謳うツールです。筆者はこれをサーバー環境（データセンター IP のコンテナ）に実際に入れ、付属の agent-reach doctor が出す健全性レポートを、コードと実際の疎通の両方から突き合わせました。結果、doctor が「✅ 利用可能」と表示した 4 チャネルのうち 2 つは、ネットワーク疎通を一切確認していませんでした。

TL;DR

• pip install agent-reach は失敗します。PyPI にこの名前のパッケージは存在せず（No matching distribution found）、npm の同名パッケージは Nostr 向けの まったく別のプロジェクト でした
• 公式の導線は「install.md の URL を AI エージェントに渡して実行させる」という珍しい方式で、実体は GitHub の zip からの pipx install です
• サーバーで agent-reach doctor を実行すると 15 チャネル中 4 つが ✅ でした。ただしソースを読むと、そのうち web（Jina Reader）は疎通確認を一切行わず固定で ok を返し、RSS はライブラリの import が通ったかだけ を見ています
• 実際に叩くと web チャネルの Jina Reader はデータセンター IP で HTTP 401（bad IP reputation）でした。doctor の ✅ が唯一実測と食い違ったのがこの 1 件です
• 逆に V2EX と Bilibili の ✅ は実 API を叩いて判定しており、筆者の実測（HTTP 200 / code=0）と一致しました

Agent Reach が何をするツールなのか

Agent Reach 自身はスクレイパーではありません。README の表現を借りれば「セレクター・インストーラー・ヘルスチェッカー・ルーター」であり、実際にサイトを読むのは yt-dlp、gh CLI、bili-cli、Jina Reader、Exa などの既存 OSS です。Agent Reach はそれらを選び、入れ、生きているか調べ、落ちたときに代替バックエンドへ切り替える層を担当します。

構成は次のようになっています。

インストール後、エージェントは Agent Reach 経由ではなく上流ツールを直接叩きます。ラッパーではない、という設計方針がドキュメントに明記されています。

インストールで最初に踏んだ落とし穴

pip install agent-reach は通らない

クリーンな仮想環境で試したときの出力です。

$ python3 -m venv cleanvenv
$ ./cleanvenv/bin/pip install agent-reach
ERROR: No matching distribution found for agent-reach

PyPI の JSON API も同様でした。

$ curl -sS -o /dev/null -w "%{http_code}\n" https://pypi.org/pypi/agent-reach/json
404

つまり agent-reach という名前は PyPI に登録されていません。60.8k stars のプロジェクトのコマンド名が PyPI で未取得のまま空いている状態で、将来この名前で無関係なパッケージが公開された場合、pip install agent-reach と打った人がそれを掴む余地があります。

npm の agent-reach は別プロジェクト

紛らわしいことに npm には agent-reach が存在します。ただし中身が違いました。

$ curl -sS https://registry.npmjs.org/agent-reach | python3 -c "..."
latest: 0.3.4
desc: Agent Reach for OpenClaw - connect to the decentralized agent network on Nostr
repo: https://github.com/AustinEral/agent-reach.git
created: 2026-02-17

Nostr 上の分散エージェントネットワークに接続するための別ツールで、本記事のインストール対象ではありません。名前で検索して最初に見つかったパッケージマネージャに飛びつくと取り違えます。

公式の導線は「install.md をエージェントに読ませる」

install.md を実際に取得すると、人間向けの案内は次の 1 行だけでした。

帮我安装 Agent Reach：https://raw.githubusercontent.com/Panniantong/agent-reach/main/docs/install.md

これをエージェントに貼ると、エージェントが同じ Markdown を読み、そこに書かれた手順を実行します。実体は次のコマンドです。

pipx install https://github.com/Panniantong/agent-reach/archive/main.zip
agent-reach install --env=auto

install.md には「AI Agents 向け」セクションがあり、sudo を勝手に使わない・~/.agent-reach/ の外のシステムファイルを触らない・エージェントの作業ディレクトリを汚さない、といった境界が明文で宣言されています。エージェントに実行権を渡す設計としては、境界を人間が読める形で先に置いている点は評価できます。

なお筆者の検証環境では、egress プロキシの制約で GitHub の zip 直リンクが HTTP 403 になりました。これは Agent Reach 側の問題ではなく検証環境固有の事情です。回避策として git clone してからローカルインストールしました。

$ git clone --depth 1 https://github.com/Panniantong/agent-reach.git /tmp/ar-src
$ ./arvenv/bin/pip install /tmp/ar-src
$ ./arvenv/bin/agent-reach --version
Agent Reach v1.5.0

doctor の結果と、その ✅ の意味

インストール直後に agent-reach doctor を実行した結果です（抜粋・原文は中国語）。

✅ 装好即用：
  [!]  GitHub 仓库和代码 — gh CLI 可执行、且检测到显式认证配置；Doctor 不执行会写 device-id 的 `gh auth status`
  [X]  YouTube 视频和字幕 — yt-dlp 未安装
  ✅ V2EX 节点、主题与回复 — 公开 API 可用
  ✅ RSS/Atom 订阅源 — 可读取 RSS/Atom 源
  [X]  全网语义搜索 — 需要 mcporter + Exa MCP
  ✅ 任意网页 — 通过 Jina Reader 读取任意网页
  ✅ B站视频、字幕和搜索 — B站搜索 API 可达

状态：4/15 个渠道可用

ここで気になったのが「✅ が何を保証しているのか」です。ソース（agent_reach/channels/）の check() を読むと、チャネルごとに判定の重さがまったく違いました。

チャネル	doctor 表示	check() の実装	筆者の実測
V2EX	✅	公開 API を実際に GET して例外が出なければ ok	HTTP 200
Bilibili	✅	検索 API を叩き JSON の code == 0 を確認	code=0
RSS/Atom	✅	import feedparser が通れば ok（通信なし）	任意フィードは HTTP 200
任意 Web	✅	無条件で ok を返す（コメントに「恒可用兜底渠道」と明記）	HTTP 401

web.py の該当箇所はこうなっています。

def check(self, config=None):
    # 恒可用兜底渠道：无本地命令、不做网络探测（doctor 已有多个渠道触网），保持零开销
    self.active_backend = self.backends[0]
    return "ok", "通过 Jina Reader 读取任意网页（curl https://r.jina.ai/URL）"

そして実際に Jina Reader を叩くとこうなりました。

$ curl -sS -w "\nHTTP:%{http_code}\n" "https://r.jina.ai/https://example.com"
AuthenticationRequiredError: You have been blocked from performing anonymous
queries due to bad IP reputation. Please authenticate.
HTTP:401

データセンター IP からの匿名リクエストが評判ベースで弾かれています。doctor は「常に使える兜底（フォールバック）チャネル」として ✅ を出しますが、サーバー環境ではその前提が崩れます。15 チャネルのうち疎通を確認しない ✅ は web と RSS の 2 つで、実測で落ちたのはそのうち web の 1 件でした。

なお筆者は最初、Bilibili も落ちていると誤認しました。自分で選んだエンドポイント（search/type）に User-Agent なしで投げて HTTP 412 を受けたためです。ソースを読んで doctor が実際に叩いているのは search/all/v2 で、ブラウザ相当の UA を付けていると分かり、同条件で再実行したら code=0 が返りました。ツールの判定を疑うときは、ツールが実際に叩いている URL とヘッダーまで揃えないと、自分の実験ミスをツールのバグと取り違えます。

サーバー運用で効いた設定

install.md と --help から拾えた、サーバー環境で実際に役立つオプションです。

agent-reach install --env=auto --dry-run   # 何が入るかだけ表示（変更なし）
agent-reach install --env=auto --safe      # システムパッケージを自動インストールしない
agent-reach configure proxy http://user:pass@ip:port  # IP 風評対策のプロキシ登録
agent-reach doctor                         # チャネル別の健全性チェック

--dry-run の出力は実際に次のとおりで、環境を自動判定したうえで「何を入れるか」だけを列挙します。

Environment: Server/VPS (auto-detected)
[dry-run] System dependency check:
  ✅ gh CLI: already installed, skip
  ✅ Node.js: already installed, skip
[dry-run] Would install mcporter and configure Exa search
Dry run complete. No changes were made.

エージェントに任せる前に人間が --dry-run を一度通しておくと、何が入るかを把握したうえで実行に移せます。IP 風評で落ちる系のチャネルについては、ツール側も「一部プラットフォームはサーバー IP に対して制限をかける」と明示的に警告し、プロキシ登録コマンドを案内していました。

著者視点の発見ポイント

• ヘルスチェックの ✅ は「コストをかけずに出せる ✅」に寄る。Agent Reach の doctor は 15 チャネルを毎回走査するため、全部でネットワーク探測をすると遅くなります。web チャネルの無条件 ok は、その設計トレードオフをコメントで正直に書いたうえでの選択です。責めるべき手抜きというより、利用者側が「✅ = 疎通確認済み」と読み替えてしまう危険 が本質でした
• doctor の [!] 表示のほうが誠実。GitHub チャネルは「gh auth status は device-id を書き込むので doctor では実行しない」と明記して ✅ を避けていました。副作用のある確認をヘルスチェックで走らせない、という判断が言語化されているツールは多くありません
• install.md 方式は「読める install スクリプト」。curl | bash に比べると、エージェントに渡す前に人間が同じ URL を開いて全文を読めます。境界（sudo 禁止・作業ディレクトリ不可侵）が本文に書いてあるため、逸脱したときにエージェントの誤りだと判別できます
• パッケージ名の空きスロットは静かなリスク。PyPI に agent-reach が無いこと自体は現時点で無害ですが、SNS 経由で広まったツールほど「それっぽいコマンド」で試す人が増えます。公式の導線がリポジトリの zip である以上、記事や社内 Wiki に書き写すときは URL ごと残すのが安全です

おわりに

Agent Reach は、API 料金なしでエージェントに外部サイトを読ませるという需要に対して、既存 OSS の寄せ集めを整理するという現実的な解を出しています。同時に、今回の検証で見えたのは「ヘルスチェックの ✅ は実装によって意味が違う」という、この種のマルチバックエンド型ツール全般に当てはまる注意点でした。

サーバーで動かす場合は、doctor の結果を鵜呑みにせず、実際に使うチャネルだけでも一度手で叩いてみることをおすすめします。とくに IP 風評でブロックされる系の失敗は、エージェントに任せると「読めなかった」という曖昧な結果として返ってくるため、原因の切り分けに時間を取られます。

参考リンク:

• Panniantong/agent-reach（GitHub）
• install.md（公式インストール手順）
• npm の同名別プロジェクト AustinEral/agent-reach（GitHub）

関連記事

• claude doctor CLI、3つの警告を出したのに1つも直せなかった
• Claude Codeのハマりどころ14件、8件はドキュメント1行と食い違った
• OpenSRE の health、58連携中で未設定のAWSだけ failed だった