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

早わかり: openai プロバイダーのまま、ホストだけ上書き。

Goose にはドキュメント化されたカスタムエンドポイント経路が用意されています。GOOSE_PROVIDER は openai のままにし、そのプロバイダーが向かう先だけを上書きします。OPENAI_HOST が既定の api.openai.com ホストを置き換え、OPENAI_API_KEY が認証し、GOOSE_MODEL が正確な id でモデルを選びます。リクエストパスは別物で、OPENAI_BASE_PATH は既定で v1/chat/completions になっており、通常変更は不要です。 この形は注意深く見てください。このカテゴリの他の多くのツールとは逆になっているからです。OPENAI_HOST は素のホスト、https://api.apisrouter.com を取り、/v1 のサフィックスは付けません。/v1/chat/completions の部分は OPENAI_BASE_PATH の中にあります。ホストに /v1 を付け足すとパスが二重になり、ゲートウェイが壊れているように見える 404 を引き起こします。

export GOOSE_PROVIDER=openai
export OPENAI_HOST=https://api.apisrouter.com   # bare host, no /v1
export OPENAI_API_KEY=sk-APIsRouter-...
export GOOSE_MODEL=claude-sonnet-4-6

goose session

Goose がプロバイダーとどう話すか。

Goose(GitHub 上では block、スター数はおよそ51K)は、Block による自律型エンジニアリングエージェントで、タスクを計画し、ファイルを編集し、シェルコマンドを実行し、MCP ベースの拡張機能を動かします。そのすべてが1つのモデルとの対話の上に乗っており、ループの各ステップがツール定義を伴う /v1/chat/completions リクエストなので、プロバイダー設定がエージェント全体の実行場所を決めます。 設定は階層化されています。対話的な経路は goose configure で、openai プロバイダーの場合は API キーと任意のカスタムホストを尋ねたうえで、GOOSE_PROVIDER や GOOSE_MODEL のような非シークレットな設定を ~/.config/goose/config.yaml に書き込みます。デスクトップアプリも同じプロバイダー設定を UI で公開しています。シークレットは別に扱われます。キーはシステムのキーチェーンに渡されるか環境変数から取得され、config.yaml に直接貼り付けたキーは読み込まれず無視されます。 環境変数はファイルより優先され、これがラップトップのシェルから CI ランナーまで、あらゆる場所で上の環境変数による経路を機能させています。Goose は GOOSE_MODEL をプレーンな文字列として渡すため、id は OPENAI_HOST の背後にあるエンドポイントが提供するものなら何でも構いません。今日は Claude の id、明日は Kimi や Qwen の id、と変数1つ変えるだけです。

宣言的な経路: カスタムプロバイダーファイル。

環境変数による上書き以外にも、現行の Goose ドキュメントは宣言的なカスタムプロバイダーについても説明しています。~/.config/goose/custom_providers/(Windows ではプラットフォームごとの設定ディレクトリ)に置かれた JSON ファイルが、組み込みのプロバイダーと並んで名前付きプロバイダーを登録します。このファイルは engine(チャット補完エンドポイント向けなら openai)、キーを保持する環境変数、エンドポイント URL、そのプロバイダーが提供するモデルを宣言します。 ここでの URL の規約には注意してください。また逆になります。OPENAI_HOST とは異なり、カスタムプロバイダーの base_url はパスを含む完全なリクエスト URL、https://api.apisrouter.com/v1/chat/completions です。各 models エントリには context_limit があり、Goose が詰め込めるウィンドウを把握できるようにします。 宣言的なファイルは、ゲートウェイを openai のスロットに間借りさせるのではなく、独自の名前付きプロバイダーとして Goose のプロバイダー一覧に、独自のキー変数とともに表示させたい場合に向いています。環境変数による上書きは CI や素早い切り替えに向いています。どちらも同じエンドポイントに行き着くので、どちらか一方を選び、両方を重ねて使うのは避けてください。

{
  "name": "apisrouter",
  "display_name": "APIsRouter",
  "engine": "openai",
  "api_key_env": "APISROUTER_API_KEY",
  "base_url": "https://api.apisrouter.com/v1/chat/completions",
  "models": [
    { "name": "claude-sonnet-4-6", "context_limit": 200000 },
    { "name": "claude-opus-4-7",   "context_limit": 200000 },
    { "name": "kimi-k2.7-code",    "context_limit": 200000 }
  ],
  "supports_streaming": true,
  "requires_auth": true
}

自律型エージェント向けのモデル選び。

実務上のワークフローは、タスクセットを固定したまま GOOSE_MODEL を2つか3つの候補で数セッションずつローテーションさせることです。どの候補も同じキーを経由するので、キーごとの利用状況ビューがあなたの側で帳簿をつけることなく各実験の値段を教えてくれます。

• Goose は無人で長く動き続けます。計画し、編集し、実行し、出力を読み、繰り返します。生の雄弁さより、ツール呼び出しの信頼性の方が重要で、だからこそ claude-sonnet-4-6 と claude-opus-4-7 が、メインループのデフォルトとして多くの人が行き着く先になっています。
• kimi-k2.7-code のようなコーディング特化の id は、リファクタリングの多いセッション向けに試す価値があります。ゲートウェイ経由であれば、その検証は GOOSE_MODEL の変更1つで済み、プロバイダーの移行は不要です。
• 長いセッションは文脈を積み重ねます。宣言的な経路の context_limit で正直に申告された、本当に200kのウィンドウを持つモデルなら、要約に入る前により多くのセッション履歴を保持できます。
• スクリプトや CI での利用では、中位クラスの id(gpt-5.4、qwen3.7-max)が範囲の絞られたタスクではフロンティア級の支出のごく一部で基準を満たすことも多く、デフォルトを上げる前に自分のタスクで確かめてください。

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

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

Goose に特有の失敗パターン。

OPENAI_HOST に /v1 を付け足してしまう。このホスト変数は素のホストを取り、パスは OPENAI_BASE_PATH の中にあり、すでに既定で v1/chat/completions になっています。https://api.apisrouter.com/v1 をホストにすると /v1/v1/... というリクエストになり 404 が発生します。これが最もよくある誤りです。まさに他のあらゆるツールが /v1 サフィックスを求めるからこそ、起きやすいのです。 カスタムプロバイダーファイルにおけるフル URL の規約。宣言的な base_url は /v1/chat/completions を含む完全なリクエスト URL で、OPENAI_HOST とは正反対の規約です。素のホストをカスタムプロバイダーファイルに貼り付けても、フル URL を OPENAI_HOST に貼り付けたのと同じ確実さで壊れます。 config.yaml のキーは認証されない。Goose はキーチェーンか環境変数からシークレットを読み込み、config.yaml に置かれたキーの値は無視します。ファイルを編集した後も 401 が続くならこれが理由です。変数を export するか、goose configure を再実行してプロンプトが出たときにキーを入力してください。 デスクトップセッションはシェルの export を認識しない。デスクトップアプリはターミナルのプロファイルから何も継承しません。デスクトップの設定 UI からプロバイダーを設定するか、変数が設定済みのシェルから起動してください。 設定ソースの重なり。古い OPENAI_HOST の export が、config.yaml でたった今設定した内容を上書きしてしまうことがあります。環境変数がファイルより優先されるからです。ルーティングがおかしいと感じたら、どちらの層を責める前に、Goose を起動するのと同じシェルで該当変数を print してください。

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

• Goose を日常的に使い、ベンダーごとに1組の認証情報を持つのではなく、Claude・GPT・Kimi・Qwen を1つのキーの背後でアドレスしたいエンジニア。
• Goose を CI やスケジュールジョブに組み込むチーム。環境変数のみの経路なら、ランナーに必要なのはルーティング変数2つとシークレット1つだけで、注入もローテーションも簡単です。
• 実タスクでエージェントモデルを比較する開発者。候補ごとに必要なのは同じエンドポイントに対する GOOSE_MODEL の値1つで、キーごとの利用状況が自動で価格を付けます。
• いくつものベンダーダッシュボードを突き合わせるのではなく、エージェントの支出をキーごと・モデルごとに1つの請求面で可視化したいプラットフォームチーム。
• 特定ベンダーの請求手段にアクセスできない開発者。チャージ制でカード不要のアクセスなら、プロバイダーごとのサインアップという依存を取り除けます。

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

セッションを始める前に、GOOSE_MODEL に設定した id をゲートウェイが提供しているか確認してください。/v1/models 一覧が、バージョンサフィックスも含めた正しい綴りの情報源です。 初回セッションの失敗は一貫しています。404 はホストとパスの組み立てが誤っていることを意味し、ほぼ常に OPENAI_HOST に /v1 が入っているのが原因です。401 は、Goose がキーを探している場所にキーがないことを意味します。起動したシェルで export されていない、キーチェーンにもない、あるいは config.yaml の中に無意味に置かれている、のいずれかです。ゲートウェイからのモデル未検出エラーは GOOSE_MODEL のタイプミスです。セッションは始まるのにツール呼び出しがおかしい場合は、本当にツール利用に対応しているモデルを使っているか確認してください。上の表にある id はすべて対応しています。 ループが動き始めたら、APIsRouter コンソールがリクエストごとのモデル、トークン数、支出を表示します。自律型エージェントは、この点が最も重要になるワークロードです。セッションは長く、ツール呼び出しのターンは多く、利用状況ビューが Goose の1日分が実際にいくらかかったかを見せてくれます。

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

よくある質問