株式会社ホコサキ

Agent-ReachでAIエージェントにSNS・動画・GitHubの情報を渡す

天京祐輔
天京祐輔
Agent-ReachでAIエージェントにSNS・動画・GitHubの情報を渡す

AIエージェントにWeb検索ツールを持たせると、TavilyやSerpAPIで事足りる場面は多い。ただ「Redditのスレッドで実際に何が議論されているか」「GitHubのIssueに寄せられたユーザーの生の声」「YouTubeの字幕テキスト」を取りたいとなった途端、壁にぶつかる。公式APIは申請が必要だったり、コストがかかったり、そもそも欲しいデータが返ってこなかったりする。

そのギャップを埋めるOSSが Panniantong/Agent-Reach だ。Twitter/X・Reddit・YouTube・GitHub・Bilibili・XiaoHongShuといったプラットフォームの構造化データを、APIキーなしでエージェントから呼び出せるCLIツールとして機能する。何を取れて何を取れないかを整理した上で、LangChain・Claude・OpenAI Agents SDKへの組み込みをコードレベルで示す。採用判断に必要なリスクも正直に書く。

Tavilyが返すものと、Agent-Reachが返すもの

TavilyやSerpAPIが返すのは、本質的には「Webインデックス上のスニペットとURL」だ。検索クエリに対して関連ページのタイトル・抜粋・URLが返ってくる。RAGパイプラインや一般的なリサーチタスクには十分機能する。

ただし、プラットフォーム固有の構造化コンテンツは別の話になる。Redditのスレッドは検索インデックスに載っていても、コメントツリーの全文・アップボート数・返信の入れ子構造はスニペットには含まれない。YouTubeの字幕テキストはページのHTMLに埋め込まれているが、通常の検索結果からは取れない。GitHubのIssueやDiscussionも同様で、インデックスに表示されるのはタイトルと冒頭の数行だけだ。

Agent-Reachはこの「プラットフォーム固有の構造化データ」を取りに行く層として設計されている。内部では twitter-cli・rdt-cli・yt-dlp・gh CLI・Jina Reader といった既存OSSを束ね、プラットフォームごとの専用バックエンドをCLIコマンドとして統一インターフェースで呼び出せるオーケストレーション層として機能する。

対応プラットフォームと取得できるデータの種別は以下の通りだ。

プラットフォーム取得できるデータ
Twitter/Xツイート本文・タイムライン・検索結果
Redditスレッド全文・コメントツリー・検索結果
YouTube字幕テキスト・動画メタデータ・検索結果
GitHubリポジトリ・Issue・PR・Discussion（公開）
Bilibili動画メタデータ・字幕・検索結果
XiaoHongShuノート本文・コメント・検索結果
Web全般任意URLのページ全文（Jina Reader経由）

TavilyとAgent-Reachは競合ではなく、取れるデータの層が違う。「検索インデックス上の情報」と「プラットフォーム内の構造化コンテンツ」を別物として認識しておくことが、使い分けの出発点になる。

「APIキー不要」の裏側にある仕組みとリスク

「APIキー不要・ゼロコスト」という謳い文句の裏側には、各プラットフォームの認証壁をどう越えるかという問題がある。Agent-Reachの答えは、既存OSSのスクレイピング的アプローチとCookie認証の組み合わせだ。

プラットフォームごとに必要な設定レベルは3層に分かれる。

設定レベル主なプラットフォーム補足
設定不要Web全般・YouTube・RSS・GitHub（公開リポジトリ）Jina Reader・yt-dlpが後端。インストール直後から使える
Cookie必要Twitter/X・Reddit・XiaoHongShu各バックエンドOSS（twitter-cli・rdt-cli等）のドキュメントに従って設定
プロキシが必要な場合ありReddit・Bilibili（サーバー運用時）サーバーIPがブロックされる場合のみ。ローカルPCでは不要とされている

YouTubeの字幕取得やGitHubの公開リポジトリ読み取りは設定不要で動く。一方、Twitterの検索やRedditのスレッド取得はCookie認証が前提になる。Redditは匿名アクセスのAPIが全面封鎖されており、公式APIは人工審査が必要なため、Cookie認証が現実的な回避策になっている。Cookie設定の具体的な手順はバックエンドOSSごとに異なるため、使用するOSS（twitter-cli・rdt-cli等）のREADMEを参照してほしい。

このアプローチに伴うリスクは3つある。安定性のリスクは避けられない。各プラットフォームがHTML構造やAPIエンドポイントを変更すれば、バックエンドのOSSが動かなくなる。yt-dlpはYouTubeの仕様変更に追従し続けているが、それでも一時的な断絶は起きる。本番環境でこれが発生した場合、修正は上流OSSのメンテナーに依存する。

利用規約のリスクも明示しておく必要がある。スクレイピング的アプローチはほぼすべてのプラットフォームのToSで制限されている。個人のプロトタイピングや社内ツールでの利用と、商用サービスへの組み込みでは、リスクの重さが大きく異なる。法務確認なしに本番サービスへ組み込むのは避けた方がいい。

メンテナンス依存のリスクは、Agent-Reach自体がまだ新しいOSSであることから来る。バックエンドとして使われている各OSSのメンテナンス状況に引きずられる構造になっており、たとえばXiaoHongShu向けのxhs-cliは2026年3月以降更新が止まっているとREADMEに記載されている。採用前にバックエンドOSSの活動状況を確認しておくことを勧める。

「ゼロコスト」が意味するのは金銭的コストがゼロということであって、運用コストやリスクがゼロではない。

インストールとセットアップ

agent-reach install を実行すると各バックエンドOSSが自動でセットアップされ、その後 agent-reach doctor を走らせると各プラットフォームへの接続を実際に探索して結果を一覧表示してくれる。壊れているバックエンドには修復の処方も出力されるので、何か動かない時の起点として便利だ。

# Agent-Reach本体をインストール
pip install agent-reach

# バックエンドOSSをセットアップ
agent-reach install

# 環境診断で動作確認
agent-reach doctor

Cookie設定が必要なプラットフォーム（Twitter/X・Reddit・XiaoHongShu）については、Agent-Reach本体に統一的な設定コマンドがあるわけではなく、各バックエンドOSS（twitter-cli・rdt-cli・OpenCLI等）のドキュメントに従う形になる。たとえばTwitterはtwitter-cliかOpenCLIのどちらかを使い、それぞれのCookie設定手順を踏む。agent-reach doctor --channel twitter で設定後の動作確認ができる。

ローカルPC上での開発であれば、ブラウザ拡張でNetscape形式のcookies.txtをエクスポートするのが手軽だ。サーバー上で動かす場合はプロキシの設定も必要になることがある。

LangChain・Claude・OpenAI Agents SDKへの組み込み

Agent-ReachのCLIコマンドは subprocess で呼び出す薄いラッパーとして実装するのが基本パターンだ。CLIが標準出力にテキストを返すので、それをそのままLLMに渡せる。

LangChain Toolとして使う

Reddit検索とYouTube字幕取得の2つをLangChain Toolとしてラップする例を示す。

import subprocess
from langchain.tools import Tool

def search_reddit(query: str) -> str:
    """Redditでクエリを検索し、スレッドの内容を返す"""
    result = subprocess.run(
        ["agent-reach", "search-reddit", query],
        capture_output=True,
        text=True,
        timeout=30
    )
    return result.stdout if result.returncode == 0 else f"Error: {result.stderr}"

def get_youtube_transcript(url: str) -> str:
    """YouTube動画のURLから字幕テキストを取得する"""
    result = subprocess.run(
        ["agent-reach", "read", url],
        capture_output=True,
        text=True,
        timeout=60
    )
    return result.stdout if result.returncode == 0 else f"Error: {result.stderr}"

reddit_tool = Tool(
    name="search_reddit",
    func=search_reddit,
    description="Redditのスレッドを検索する。技術的な議論やユーザーの生の声を取得したい時に使う。"
)

youtube_tool = Tool(
    name="get_youtube_transcript",
    func=get_youtube_transcript,
    description="YouTubeのURLから字幕テキストを取得する。動画の内容をテキストとして処理したい時に使う。"
)

Timeoutの設定は重要で、特にYouTube字幕取得はyt-dlpの処理に時間がかかることがある。本番環境では非同期処理への切り替えも検討したい。

ClaudeとOpenAI Agents SDKへの組み込み

Claudeのtool_use形式への組み込みパターンを示す。ツール定義のスキーマとハンドラーを用意するだけで、CLIの標準出力をそのままtool_resultとして返せるので、ラッパーは薄く保てる。

import anthropic
import subprocess

client = anthropic.Anthropic()

# Claudeのtool定義
tools = [
    {
        "name": "search_reddit",
        "description": "Redditのスレッドを検索し、コメントを含む構造化コンテンツを返す",
        "input_schema": {
            "type": "object",
            "properties": {
                "query": {"type": "string", "description": "検索クエリ"}
            },
            "required": ["query"]
        }
    }
]

def handle_tool_call(tool_name: str, tool_input: dict) -> str:
    if tool_name == "search_reddit":
        result = subprocess.run(
            ["agent-reach", "search-reddit", tool_input["query"]],
            capture_output=True, text=True, timeout=30
        )
        return result.stdout

# エージェントループ
messages = [{"role": "user", "content": "LangChainのメモリ管理についてRedditの議論を調べて"}]

response = client.messages.create(
    model="claude-opus-4",  # 実際に使用するモデル名に合わせて変更する
    max_tokens=4096,
    tools=tools,
    messages=messages
)

# tool_useブロックへの応答
if response.stop_reason == "tool_use":
    for block in response.content:
        if block.type == "tool_use":
            tool_result = handle_tool_call(block.name, block.input)
            # tool_resultをmessagesに追加して再度呼び出す

OpenAIのfunction calling形式も構造は同じで、tools パラメータに {"type": "function", "function": {...}} の形式でスキーマを渡し、finish_reason == "tool_calls" の時にハンドラーを呼ぶ。どちらの形式も、CLIの標準出力をそのままtool_resultとして返せばよい。

実務での使いどころと採用判断

Agent-Reachが力を発揮するのは、「Webインデックスには載っているが、構造化コンテンツとして取れない」情報を扱うユースケースだ。

競合調査では、GitHub IssueとRedditの組み合わせが効く。ライバルOSSのIssueから「どんなバグが報告されているか」「どの機能リクエストが多いか」を取得し、Redditのスレッドで「実際のユーザーがどう評価しているか」を補完する。公式ドキュメントには載らない生の声が取れる点が価値になる。ただしGitHubはgh CLIの認証設定が必要で、プライベートリポジトリへのアクセスには別途設定が要る。

SNSモニタリングでは、TwitterとXiaoHongShuを組み合わせて自社プロダクトや業界キーワードの言及を収集できる。特にXiaoHongShuは中国市場向けプロダクトの評判調査で有効で、公式APIが存在しないプラットフォームへのアクセス手段として機能する。ただしCookie認証が必要なため、Cookieの有効期限切れによる断絶には注意が必要だ。前述のxhs-cliの更新停止も踏まえ、このユースケースはプロトタイピング用途に留めるのが現実的だろう。

コンテンツリサーチでは、YouTubeとRedditの組み合わせが扱いやすい。特定テーマの動画字幕を一括取得してLLMに要約させたり、Redditの議論から「読者が実際に知りたいこと」を抽出してコンテンツ企画に活かすパターンだ。YouTubeの字幕取得はyt-dlpが安定しており、設定不要で動く点も扱いやすい。

採用判断で軸になるのは、用途と安定性の要件だ。社内ツール・プロトタイピング・個人開発には向いている。一方で、外部公開サービスへの組み込みは利用規約リスクの法務確認が必要になる。SLAが求められる用途には、バックエンドOSSの更新停止やプラットフォーム仕様変更による断絶を許容できないケースが多い。公式APIが存在するプラットフォームでは、コストと安定性のトレードオフを比較した上で選択するのが筋だ。

Agent-ReachはTavilyやSerpAPIの代替ではなく補完だ。「まずTavilyで関連URLを取得し、その中のRedditスレッドやYouTube動画のURLをAgent-Reachで深掘りする」というパイプライン設計が、両者の特性を活かした使い方になる。Web検索で広く網を張り、プラットフォーム固有のデータで深く掘る。この2層構造を意識すると、エージェントの情報収集能力は大きく広がる。

株式会社ホコサキは山口県宇部を拠点に、AIエージェントの業務実装やLangChain・Claude APIを使ったシステム開発を手がけています。Agent-Reachのような新しいOSSの評価・導入支援も対応しています。詳しくはサービス紹介ページをご覧ください。