gpt-researcher を、カスタムの OpenAI 互換エンドポイントで動かす。

早わかり: .env の5行。

gpt-researcher のカスタムエンドポイントの経路としてドキュメント化されているのは環境変数です。OPENAI_BASE_URL を https://api.apisrouter.com/v1 に設定し、OPENAI_API_KEY にゲートウェイのキーを設定し、3つのモデルスロットに openai: プロバイダープレフィックスを付けて割り当ててください。プレフィックスが gpt-researcher にどのクライアントを使うか伝え、コロンの後ろの文字列がそのままエンドポイントに渡されるため、ゲートウェイが提供する id なら何でも有効です。Claude や Gemini の id も含まれます。 これは docs.gptr.dev でカスタムの OpenAI 互換エンドポイント向けにドキュメント化されている設定であり、pip パッケージ、Web アプリ、マルチエージェントのフローのいずれでも同一に機能します。すべてが同じ設定を解決するからです。

OPENAI_BASE_URL=https://api.apisrouter.com/v1
OPENAI_API_KEY=sk-APIsRouter-...
FAST_LLM=openai:claude-haiku-4-5-20251001
SMART_LLM=openai:claude-sonnet-4-6
STRATEGIC_LLM=openai:gpt-5.5

gpt-researcher が、3つのスロットにトークンをどう使うか。

gpt-researcher(GitHub 上では assafelovic、スター数はおよそ28K)は、クエリをリサーチ済みで引用付きのレポートに変換します。リサーチの問いを計画し、リトリーバーを通じて Web 検索を展開し、ソースをスクレイピングして要約し、その後長文のレポートを書きます。このフレームワークは、そのパイプラインを1つではなく3つの設定可能なモデルスロットに分割しています。 FAST_LLM は、主にスクレイピングしたページの要約という、量が多く低リスクな作業を処理します。SMART_LLM は最終レポートを含む重い執筆を行います。STRATEGIC_LLM は計画を担当し、リサーチの問いを生成し、アプローチを決定します。初期状態では、これらはデフォルトで OpenAI のモデル(執筆時点でそれぞれ gpt-4o-mini、gpt-4.1、o4-mini)になっており、これこそが単一の OPENAI_BASE_URL の上書きがこれほど効果的な理由です。3つのスロットすべてが OpenAI 形状のクライアントを使うため、1つのベース URL がパイプライン全体を動かします。 各スロットが独自の provider:model 文字列を取るため、スロットはベンダーを共有する必要がありません。1回の実行が、速い Claude モデルで要約し、より強力な Claude や GPT モデルで執筆し、推論ティアのモデルで計画する、ということが、すべて同じエンドポイントとキーを通じて可能です。単一ベンダーのキーでこの組み合わせを実現するには3つのアカウントが必要になりますが、ゲートウェイの裏では .env の3行で済みます。

フルセットアップ: .env と Python API。

作業ディレクトリに .env ファイルを作成する(あるいはシェルで環境変数を export する)だけで、通常どおり gpt-researcher を実行できます。pip パッケージと Web アプリの両方が同じ環境変数を読み込みます。Python API はエンドポイント固有のコードを一切必要とせず、それこそが重要な点です。ルーティングは設定であり、エンドポイントが OpenAI のものであってもゲートウェイのものであっても、リサーチのコードは同一のままです。 隣接する2つの設定が重要です。Web の取得はリトリーバー(デフォルトは Tavily)を通じて行われ、独自のキー(TAVILY_API_KEY)を持ちます。その認証情報は LLM エンドポイントとは独立しており、ライブな Web リサーチには依然として必要です。そしてエンベディングはデフォルトで openai:text-embedding-3-small であり、エンベディングの呼び出しも同じ OpenAI 形状のクライアント設定に従うことを意味します。OPENAI_BASE_URL の先にあるエンドポイントがそのエンベディングモデルを提供しない場合は、EMBEDDING を提供するプロバイダーに明示的に設定してください(ドキュメントは OpenAI 互換のエンベディングエンドポイント向けに custom: プレフィックスを使い、Ollama のようなローカルの選択肢もサポートされています)。

import asyncio
from gpt_researcher import GPTResearcher

async def main():
    researcher = GPTResearcher(
        query="State of small modular reactors in 2026",
        report_type="research_report",
    )
    await researcher.conduct_research()
    report = await researcher.write_report()
    print(report)

asyncio.run(main())  # routing comes entirely from .env

スロットごとにモデルを選ぶ。

upstream のデフォルトは正しい形をエンコードしています。ボリューム向けの小さなモデル、執筆向けの強いモデル、計画向けの推論モデル。したがってその形を保ち、1つのモデルに平坦化するのではなくスロットをアップグレードしてください。1つのエンドポイントの裏では、2人の執筆者の A/B は実行ごとに .env を1行変えるだけであり、キーごとの利用ログが各レポート構成が実際にいくらかかったかを教えてくれます。

• FAST_LLM は最も頻繁に発火します。スクレイピングされたすべてのソースが要約されるからです。速い id(claude-haiku-4-5-20251001、deepseek-v4-flash)は、ソースの多いレポートが要約コストに支配されるのを防ぎます。要約は読者ではなく執筆者に渡されるため、ここでの品質低下は限定的です。
• SMART_LLM は、ユーザーが実際に読むレポートを書きます。長い出力、持続的な構造、引用の規律。ここが claude-sonnet-4-6 や gpt-5.5 がその支出に値する場所であり、品質を落とすとすぐに現れる場所です。
• STRATEGIC_LLM は、実行が始まる前に、その形を決めます。悪いリサーチの問いは、どれだけ執筆者が優秀でも悪いレポートを生みます。推論に強いモデルは、呼び出し回数は少なくても、ここでは高いレバレッジを持ちます。
• gemini-3.1-pro-preview のような長文脈対応 id は、要約の蓄積された大きな文脈にわたって執筆者が作業する detailed_report の実行で、SMART スロットとしてテストする価値があります。

従量課金 · 公式価格より安い

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

gpt-researcher に特有の失敗パターン。

プロバイダープレフィックスを落とす。スロットの形式は provider:model であり、プレフィックスがクライアントを選びます。SMART_LLM=claude-sonnet-4-6 のように openai: なしで設定しても、Claude の id をあなたのベース URL 経由でルーティングすることにはならず、gpt-researcher はその文字列を別のプロバイダーとして解釈しようとします。カスタムエンドポイントのすべてのモデルは openai: プレフィックスを保たなければなりません。ここでの "openai" はベンダーではなくプロトコルを指しているからです。 上書きに静かに追従するエンベディング。デフォルトの EMBEDDING は OpenAI 形状のモデルなので、OPENAI_BASE_URL がゲートウェイを指すようになると、エンベディングのリクエストもそこに向かいます。ゲートウェイがそのエンベディング id を提供していない場合、リサーチの実行は最初のチャット呼び出しではなくソース処理の最中に失敗し、間違ったスロットをデバッグさせる原因になります。EMBEDDING を明示的に設定すれば、この症状は消えます。 リトリーバーの失敗をエンドポイントのせいにする。TAVILY_API_KEY が欠けている、あるいは枯渇していると検索フェーズが壊れ、結果として現れる空のソースエラーは、表面的には LLM の失敗のように見えます。リトリーバーは別のキーを持つ別のサービスなので、個別に確認してください。 実行間で古びた環境。.env ファイルは作業ディレクトリから読み込まれます。あるディレクトリから Web アプリを、別のディレクトリから Python API を実行すると、2つの異なる設定が生まれ、「アプリでは動くのにスクリプトでは動かない」は、ほとんどの場合これが原因です。 トークン上限の設定は、モデルの能力とは別物です。gpt-researcher は、控えめなデフォルトを持つ独自のスロットごとのトークン上限(FAST_TOKEN_LIMIT、SMART_TOKEN_LIMIT、関連設定)を持っています。SMART_LLM を長文脈対応モデルに向けても、それだけではその上限は引き上がりません。より長い生成を望むなら、意図的にチューニングしてください。

ゲートウェイ経由で gpt-researcher を使うのは誰か。

• 定期的なレポート(市場スキャン、文献レビュー、競合ブリーフ)を生成するチームで、3つのモデルスロットにわたる実行ごとのコストの可視性が、単一ベンダーとの関係より重要な場合。
• 執筆モデルを比較する研究者。FAST と STRATEGIC を固定したまま SMART を Claude・GPT・DeepSeek の id の間で入れ替えるのは、3つのベンダーアカウントではなく3回の .env 編集です。
• gpt-researcher を製品に組み込むビルダーで、環境ごとに1つのゲートウェイキーが、デプロイパイプラインの中の一束のベンダーシークレットを置き換える場合。
• gpt-researcher の標準的な OpenAI 形状の設定に手を触れずに、Claude や Gemini にレポート執筆をさせたいユーザー。
• 特定ベンダーの請求手段にアクセスできない開発者。チャージ制でカード不要のアクセスなら、プロバイダーごとのサインアップという依存を取り除けます。

エンドポイントを検証し、最初のレポートをデバッグする。

まずゲートウェイのモデルを一覧してください。各スロットの openai: の後ろの文字列は、バージョンのサフィックスも含めて、提供されている id と正確に一致していなければなりません。 初回実行の失敗はきれいに分類できます。401 は、プロセスが実際に見ている環境に OPENAI_API_KEY が存在しないことを意味します。.env ファイルは作業ディレクトリから読み込まれるため、そのファイルがある場所から実行するか、変数をグローバルに export してください。model-not-found エラーは、タイプミスのあるスロットを示します。計画時ではなくソース処理中の失敗は、チャットのスロットではなくエンベディングかリトリーバーを指しています。LLM の設定に触れる前に EMBEDDING と TAVILY_API_KEY を確認してください。 完全なリサーチの実行は、3つのスロットすべてにまたがる数十件のリクエストのバーストなので、完了したら APIsRouter コンソールのリクエストごとのビューが、実トークンと実支出で FAST/SMART/STRATEGIC の内訳を見る最も早い方法であり、その役割にふさわしくない消費をしているスロットを見つける方法でもあります。

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY" | head -50

よくある質問