ai-hedge-fund を、カスタムの OpenAI 互換ベース URL で動かす。

早わかり: OPENAI_API_BASE とキー1つ。

ai-hedge-fund の OpenAI プロバイダーは ChatOpenAI(model=model_name, api_key=api_key, base_url=base_url) としてインスタンス化され、その base_url は src/llm/models.py の os.getenv("OPENAI_API_BASE") から取得されます。つまり上書きは .env の2行だけで済みます。OPENAI_API_BASE を https://api.apisrouter.com/v1 に向け、OPENAI_API_KEY にゲートウェイのキーを設定してください。OpenAI プロバイダー経由で動くすべてのモデルが、これでゲートウェイにリクエストを送るようになります。 変数名は注意深く確認してください。これは OPENAI_API_BASE という LangChain 時代の命名規則であり、OPENAI_BASE_URL ではありません。間違った方をエクスポートしても静かに無視され、リクエストは api.openai.com に送られ続けます。これが、この設定が動かないように見える最も多い原因です。

OPENAI_API_BASE=https://api.apisrouter.com/v1
OPENAI_API_KEY=sk-APIsRouter-...
FINANCIAL_DATASETS_API_KEY=...   # market data, unrelated to the LLM endpoint

ai-hedge-fund が、モデルとプロバイダーをどう選ぶか。

ai-hedge-fund(GitHub 上では virattt、スター数はおよそ62K)は、ファンドをエージェントの委員会としてシミュレートします。著名な投資家をモデルにしたアナリストのペルソナに加え、バリュエーション・センチメント・ファンダメンタルズ・テクニカルの各エージェントが、リスクマネージャーとポートフォリオマネージャーに情報を送り込み、最終的なシグナルを生成します。これらはすべて、実行ごとに1つのモデル選択を共有するため、1回の実行が、そのモデルの決定をすべてのエージェント・すべての銘柄にわたって乗算します。 モデル選択には2つの経路があります。対話的には、--model フラグなしで poetry run python src/main.py --ticker AAPL,MSFT,NVDA を実行すると questionary のピッカーが開きます。スクリプトでは、--model フラグがモデル名を受け取りますが、リポジトリのモデルレジストリに存在する名前だけが有効です。find_model_by_name() が src/llm/api_models.json の中でその文字列を検索し、各レジストリエントリは display_name・model_name・provider を持ちます。検索が失敗しても、CLI はプロバイダーを推測しません。対話的なピッカーにフォールバックします。これは自動化にとって重要です。未知の id は、スクリプト実行をキーボード入力待ちの状態にしてしまうからです。 provider フィールドこそが、ルーティングを決めるものです。OpenAI と記されたエントリは ChatOpenAI を経由し、OPENAI_API_BASE に従います。Anthropic と記されたエントリは ChatAnthropic と ANTHROPIC_API_KEY を経由し、あなたのベース URL を完全に迂回します。これがゲートウェイのルーティングにとっての重要な洞察です。provider の列がクライアントを、したがってエンドポイントを選ぶのであって、実際にそのモデルを作ったのが誰かとは無関係です。

フルセットアップ: .env と、ゲートウェイの各モデルに対応するレジストリエントリ。

レジストリにすでに OpenAI プロバイダーの下でリストされているモデルについては、.env の上書きだけで十分です。モデル文字列はそのままエンドポイントに渡されます。 Claude・DeepSeek・Qwen の id を同じキーでゲートウェイ経由で動かすには、src/llm/api_models.json にエントリを追加し、カタログの id を model_name に、そして重要なことに provider を "OpenAI" にします。provider がクライアントを選ぶため、OpenAI と記されたエントリは、そのモデル自体は OpenAI 製でなくても、ChatOpenAI とあなたの OPENAI_API_BASE を経由します。そのエントリは対話的なピッカーにも現れ、スクリプトでは --model 経由で解決されます。これはあなたのクローン内での3行の JSON 編集であり、コード変更ではありません。そしてこれは、レジストリがすでに使っているドキュメント記載済みの形です。 対比として、プロバイダーネイティブなエントリのことも覚えておいてください。Anthropic と記されたレジストリモデルを選ぶと、ANTHROPIC_API_KEY を探しに行き、Anthropic のエンドポイントに直接向かいます。すべてを1つのゲートウェイキーでまかないたいのであれば、モデルは OpenAI と記されたエントリ経由で動かし、ベンダーごとのキーは一切設定しないままにしておけます。

{
  "display_name": "Claude Sonnet 4.6 (gateway)",
  "model_name": "claude-sonnet-4-6",
  "provider": "OpenAI"
},
{
  "display_name": "DeepSeek V4 Pro (gateway)",
  "model_name": "deepseek-v4-pro",
  "provider": "OpenAI"
}

エージェント委員会のためのモデル選び。

レジストリによってすべての候補が1つのフラグの裏でアドレス可能になるため、誠実な評価とは経験的なものです。同じ銘柄と日付を2つか3つのモデルに通し、シグナルと支出を比較してください。キーごとの利用状況ビューが各スイープの価格を教えてくれるため、モデル選びは議論ではなく測定になります。

• 1回の実行は、多くの評決です。すべてのアナリストペルソナが、銘柄ごとに同じ開示資料と価格データをもとに推論するため、モデル選択はエージェント数×銘柄数だけ乗算されます。フロンティア級の推論 id(claude-opus-4-7、gpt-5.5)は、それに応じて乗算されたトークン代と引き換えに、すべての評決の質を引き上げます。
• claude-sonnet-4-6 は理にかなったデフォルトです。長いファンダメンタルズの文脈にわたってもペルソナの推論が一貫性を保つだけの強さがあり、十数のエージェントと銘柄バスケットに展開する実行向けの価格設定になっています。
• deepseek-v4-pro と qwen3.7-max は、広範なスイープでベンチマークする価値があります。実行あたりの価格差が、バックテストの全日付にわたって積み重なるからです。
• 何を選ぶにせよ、それを固定してください。変動するモデルの異なるスナップショットから得られるシグナルは、バックテストの期間をまたいで比較できません。正確な id を使い、モデル文字列を乱数シードのように結果の横に記録してください。

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

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

ai-hedge-fund に特有の失敗パターン。

間違った環境変数。このリポジトリは OPENAI_API_BASE を読み込みます。他のツールが使う変数である OPENAI_BASE_URL は参照されず、それを設定しても、上書きが壊れていると思い込ませる以外に何も起きません。リクエストがまだ api.openai.com に届いている場合は、何よりもまず変数名を確認してください。 未登録の id を --model に渡す。find_model_by_name() は api_models.json 内のエントリしか知りません。登録されていないカタログ id を渡すと、CLI は not-found メッセージを表示し、対話的なピッカーに落ちます。これは cron ジョブや CI 実行では、エラー終了ではなく静かなハングを意味します。先に id を登録しておけば、スクリプト実行は決定的にそれを解決します。 provider が記されたエントリがゲートウェイを迂回する。provider が Anthropic・Google・DeepSeek のレジストリモデルを選ぶと、そのベンダーのネイティブなクライアントとキーを経由します。実行がゲートウェイの利用ログに現れると思っていたのに現れない場合、選んだモデルの provider 列がその説明です。 LLM のエラーを装ったデータエラー。価格とファンダメンタルズのデータは、FINANCIAL_DATASETS_API_KEY で設定される金融データ API から来ており、これは完全に別のサービスです。データキーが欠けている、あるいは枯渇していると、LLM 呼び出しの前や合間に実行が失敗し、トレースバックはモデルの問題のように読めてしまいます。この2つの認証情報は独立して失敗するため、独立してデバッグしてください。 自動化の中の対話的プロンプト。すべてが設定されていても、--model フラグを忘れるとピッカーが開きます。無人実行では、常に登録済みの id を指定して --model を渡してください。

ゲートウェイ経由で ai-hedge-fund を使うのは誰か。

• 銘柄と日付範囲をスイープするバックテスターで、銘柄ごと・日付ごとのエージェント委員会がトークン支出を支配的なコストにし、キーごとの利用状況が自然な台帳になる人。
• モデルの評決を比較する研究者。同じ実行を2つのモデル id で行うのはフラグの変更で済み、モデル間のシグナルの不一致それ自体が興味深いデータです。
• 新しいエージェントでリポジトリを拡張するビルダーで、いくつペルソナを追加しようとも、その下に1つのエンドポイントと1つのキーがあってほしい人。
• 最もクリーンなルーティング経路が OpenAI 形状であるリポジトリの中で、Claude や DeepSeek の推論を使いたい開発者で、プロバイダーエントリごとにベンダーキーを維持したくない人。
• 特定ベンダーの請求手段にアクセスできない開発者。チャージ制でカード不要のアクセスなら、プロバイダーごとのサインアップという依存を取り除けます。

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

実行を開始する前に、登録した id をゲートウェイが提供していることを確認してください。レジストリの model_name 文字列は、提供されている id と正確に一致していなければなりません。 初回実行の失敗のはしご: 401 は、poetry が実際に起動した環境で OPENAI_API_KEY がゲートウェイのキーになっていないことを意味します。ゲートウェイからの model-not-found エラーは、レジストリエントリの model_name が /v1/models に対してタイプミスしていることを意味します。入力待ちで止まる実行は、--model の文字列がレジストリから漏れていたことを意味します。ベンダーキーのエラー(Anthropic、Google)は、選択したエントリの provider が OpenAI ではないことを意味します。そして、モデルの出力が何も出る前のデータ形状のトレースバックは、LLM の経路ではなく FINANCIAL_DATASETS_API_KEY を指しています。 実行が完了すると、APIsRouter コンソールがリクエストごとのモデル、トークン数、支出を表示します。委員会の実行は、アナリスト・リスク・ポートフォリオの各段階にまたがる数十回の呼び出しであり、利用状況ビューこそが、それをスイープに拡張する前に、1つの決定が実際にいくらかかるのかを確認する方法です。

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

よくある質問