Goose + JoinGonka Gateway: プロバイダーとキーをキーリングで管理

ステップ 1：Goose をインストールする。プロジェクトのドキュメントにある CLI の公式インストール方法：

# macOS and Linux: the script puts the binary in ~/.local/bin
curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | CONFIGURE=false bash

# macOS, Homebrew
brew install block-goose-cli

CONFIGURE=false 変数は、スクリプトがインストール直後に起動する goose configure ウィザードを無効にします：プロバイダーはインストーラーが設定します。~/.local/bin ディレクトリが PATH にない場合、スクリプトがその旨を通知します。Windows 用には同じリポジトリに download_cli.ps1 スクリプトがあり、デスクトップアプリはドキュメントページからダウンロードできます。デスクトップアプリと CLI は同じ設定を読み込むため、以下はすべて両方に適用されます。確認は goose --version です。

ステップ 2：キーを取得する。gate.joingonka.ai/register で登録し、アドレスを確認して、「API-キー」セクションで jg- プレフィックス付きのキーを作成してください。1 つのキーと 1 つの残高が、ネットワークのすべてのモデルで有効です。

ステップ 3：インストーラーを実行する。

npx @joingonka/setup --tool goose

インストーラーはキーを尋ねます（シェル履歴に残らないよう、コマンドライン引数では渡されません）。そして以下を実行します：

• ゲートウェイのアドレスとネットワークの 3 つのモデル（実際のコンテキストウィンドウ付き）を含むプロバイダーファイル custom_providers/custom_joingonka.json を、権限 600 で作成します。custom_joingonka と CUSTOM_JOINGONKA_API_KEY という名前は、Goose が「JoinGonka」という名前から自動的に導出するものと同じなので、ウィザードで入力したキーは適切な場所に保存されます；
• JoinGonka をデフォルトプロバイダーとして、モデル DeepSeek V4 Flash で設定します。ただし、プロバイダーがまだ選択されていないか、私たちのものが選択されていてモデルが空またはネットワークから消えている場合のみです。他の選択は変更せず、試用するためのコマンドを表示します：goose session --provider custom_joingonka --model …；
• Goose のシークレットストレージが確実にファイルベースの場合のみ、キーを secrets.yaml に保存します。そうでない場合は、残り 1 ステップであることを直接伝えます。詳細はキーに関するセクションにあります；
• 変更されたファイルのバックアップを作成し、最後にゲートウェイへライブリクエストを送信して、キー、アドレス、モデルをすぐに検証します。

インストーラーは設定ディレクトリを Goose 本体と同じ方法で見つけます：Linux と macOS では ~/.config/goose、Windows では %APPDATA%\Block\goose\config、GOOSE_PATH_ROOT が設定されている場合は <root>/config。別のモデルは --model フラグで指定し、省略形 deepseek、glm、minimax が使えます。明示的に指定されたモデルは常に書き込まれます。プロンプトなしモードでは環境変数からキーを取得します：

JOINGONKA_API_KEY=jg-your-key npx @joingonka/setup --tool goose --model glm --non-interactive

インストーラーが行うすべてのことは、手動で行うことも可能です。プロバイダーは個別のJSONファイル ~/.config/goose/custom_providers/custom_joingonka.json です。ファイル名は name フィールドと一致させる必要があります：

{
  "name": "custom_joingonka",
  "engine": "openai",
  "display_name": "JoinGonka",
  "description": "JoinGonka Gateway — Gonka AI inference (OpenAI-compatible)",
  "api_key_env": "CUSTOM_JOINGONKA_API_KEY",
  "base_url": "https://gate.joingonka.ai/v1/chat/completions",
  "models": [
    { "name": "deepseek-ai/DeepSeek-V4-Flash-0731", "context_limit": 380000 },
    { "name": "zai-org/GLM-5.3-Flash", "context_limit": 390000 },
    { "name": "MiniMaxAI/MiniMax-M2.7", "context_limit": 200000 }
  ],
  "supports_streaming": true,
  "requires_auth": true
}

Gooseのモデル設定には、レスポンスの個別上限という概念はありません。そのようなモデルの場合、リクエスト内に制限は一切送信されません（リクエストログで確認済み）。ストリーミングモードでは、ゲートウェイがモデル固有の上限に基づいてレスポンスを制限します（DeepSeek V4 Flashは32,768トークン、GLM-5.3 FlashとMiniMax M2.7は8,192トークン）。このためにグローバル変数 GOOSE_MAX_TOKENS を設定する必要はありません。これはすべてのプロバイダーに共通で適用されます。

Gooseはプロバイダーファイルを厳密なJSONパーサーで読み取るため、コメントや末尾のカンマがあるとリストからプロバイダーが消えてしまいます。ウィザード（goose configure → Custom Providers）で作成することもできますが、ウィザードはコンテキストウィンドウの値を尋ねてこないため、手動で追記する必要があります。

デフォルトのプロバイダーとモデルは ~/.config/goose/config.yaml に保存されます。Goose自身は以下のように記録します：

active_provider: custom_joingonka
providers:
  custom_joingonka:
    enabled: true
    model: deepseek-ai/DeepSeek-V4-Flash-0731
    configured: true

古いレイアウトであるファイルルートのフラットな GOOSE_PROVIDER および GOOSE_MODEL キーも機能します。Gooseは設定保存時に自動的に新しい形式へ変換します（goose configure 実行後など）。インストーラーは空のファイルに対してはこのフラットなキーを書き込み、どのバージョンでも認識されるようにしています。環境変数はファイルよりも優先されます。シェルで設定されている場合、config.yaml の選択は反映されず、インストーラーがその旨を警告します。

Goose のプロバイダーファイルにはシークレット名 CUSTOM_JOINGONKA_API_KEY しかありません。値は次の順番で探されます: 同名の環境変数、次にシステムのシークレットストア（keyring、macOS では Keychain）、次に設定ファイルの隣にある secrets.yaml。シークレットがファイルに書き込まれるのは Goose のストアがファイルベースの場合で、そこでは平文のまま、パーミッション 600 で保存されます。なお config.yaml 内で Goose がキーを探すことは一切ありません（ドキュメント）。

ストアがファイルベースになるのは、keyring が無効化されている場合 — 任意の値を持つ環境変数 GOOSE_DISABLE_KEYRING、または config.yaml 内の GOOSE_DISABLE_KEYRING: true という行 — あるいは利用できない場合です: グラフィカルセッションのないサーバー、コンテナ、CI など。後者の場合、Goose はログに「Keyring unavailable. Using file storage for secrets.」と出力し、自動的にファイルへ切り替わります — まさにコンテナで見たとおりです。インストーラーは keyring に書き込むことができず、またあなたに代わって無効化することもありません。そうすると Goose が既に保存されているシークレットを見られなくなるからです。そこから以下のシナリオが導かれます:

残りのステップ。 goose configure を実行し、ウィザードの質問に答えてください — 私たちの実行では次のようになりました:

• What would you like to configure? → Configure Providers;
• Which model provider should we use? → JoinGonka（私たちの環境では先頭にありました）;
• Would you like to set CUSTOM_JOINGONKA_API_KEY? (optional) → Yes、続いて Enter value for CUSTOM_JOINGONKA_API_KEY でキーを貼り付け — 文字の代わりに四角が表示されます。キーはすぐに保存されます;
• Would you like to configure advanced settings? → No;
• Select a model — リストは Goose がゲートウェイから取得します: MiniMaxAI/MiniMax-M2.7、deepseek-ai/DeepSeek-V4-Flash-0731、zai-org/GLM-5.3-Flash。カーソルは最初の行にあります — インストーラーが選んだモデルを維持するには、矢印キーで DeepSeek V4 Flash を選択してください。テストリクエストの後、ウィザードは「Configuration saved successfully」という行で終了します。

Goose Desktop ではパスは次のとおりです: Settings → Models → Configure providers → JoinGonka → キー → Submit。手入力でキーを貼り付けたくない場合は、環境変数に入れて同じシェルからウィザードを起動してください: Goose は「CUSTOM_JOINGONKA_API_KEY is set via environment variable」と表示し、値を保存するか尋ねてきます:

read -s CUSTOM_JOINGONKA_API_KEY && export CUSTOM_JOINGONKA_API_KEY
goose configure

また、保存せずに一度だけキーを渡すこともできます: CUSTOM_JOINGONKA_API_KEY=jg-your-key goose session、PowerShell では $env:CUSTOM_JOINGONKA_API_KEY = "jg-your-key"; goose session。環境変数は保存済みの値より優先されますが、シェルを閉じるまでしか有効ではありません。

まず、Gooseが実際にどのような設定を認識しているかを確認しましょう：

goose info -v

「goose Configuration」ブロックには、GOOSE_PROVIDER: custom_joingonkaとモデルIDを含むGOOSE_MODELの行があるはずです。次に、対話セッションなしの単発実行です。空のディレクトリに明らかなバグを含むファイルを置き、それを見つけるよう依頼します。

goose run --no-session -t "Read calc.py and tell me in one sentence whether it has a bug."

--no-sessionフラグは実行を履歴に保存しません。ヘッダーには● new session · custom_joingonka deepseek-ai/DeepSeek-V4-Flash-0731のような行が表示され、続いてツール呼び出し——cat calc.pyコマンドを伴う▸ shell——そして見つかったバグを含む回答が表示されます。1回の実行で別のモデルを指定するには--modelを使います：zai-org/GLM-5.3-FlashまたはMiniMaxAI/MiniMax-M2.7。2026年9月23日の私たちの実行では、ネットワーク上の3つのモデルすべてが「リクエスト → ツール → 結果 → 回答」のサイクルを通過しました。Goose CLIはデフォルトでモデルの推論を非表示にします——ターミナルに出力する場合は、GOOSE_CLI_SHOW_THINKING=1変数で表示できます。ゲートウェイ側では、リクエストは管理画面で確認できます：「使用状況」セクション、「モデル別」と「キー別」の内訳です。

何か問題が発生した場合、診断は通常メッセージから直接読み取れます：

エージェントのトークン消費はチャットとは異なります。Gooseの標準構成では、モデルに18種類の組み込みツールが提供されるため、今回の実行では質問の前にすでに約4,600の入力トークンが消費されていました。「ファイルを読み込んでエラーを探す」というタスクには2〜3ステップと10,000〜15,000トークンが必要で、そのほとんどが入力分です。さらに、Gooseはセッション名を決めるために短いリクエストを自動で行います。不要な拡張機能は goose configure → Toggle Extensions でオフにすることが、入力トークンを削減する最も簡単な方法です。

JoinGonka Gateway を経由する場合、トークン料金は入力が $0.0069（100万トークンあたり）、出力が $0.021（100万トークンあたり）です。この価格はネットワーク内の全モデル共通で、このページにはライブソースから反映されています。

右列の概算は2026年9月時点の価格に基づいています。比較として、Gooseでモデルを利用する際の支払い方法は以下の通りです：

正確な利用状況と残高は、ダッシュボードの「利用状況（Usage）」および「請求（Billing）」セクションで確認できます。なぜデフォルトが DeepSeek V4 Flash なのか（ネットワーク内で最大の回答容量を持つため）については、モデル解説 を参照してください。

確認モード。 デフォルトではGooseは auto モードで動作します — 完全に自律的で、何も尋ねずにファイルを編集・削除し、コマンドを実行し、拡張機能を使用します。自分のプロジェクトでは便利ですが、他人のコードではモードを厳格化することをお勧めします：

# inside a session
/mode smart_approve

# permanently, as a line in config.yaml
GOOSE_MODE: smart_approve

これはGoose自体の機能であり、モデルプロバイダーには依存しません。

モデルの切り替え。 セッション内では — IDを伴う /model コマンド、例えば /model zai-org/GLM-5.3-Flash；1回の実行では — goose run と goose session の --model フラグ；恒久的には — goose configure または config.yaml の model 行です。プロバイダーはそのまま変わりません。推論するGLM-5.3 Flashは複雑なロジックに適していますが、回答の上限は8192トークンで、その一部は推論に使われます — 詳細はモデルレビューをご覧ください。

無人実行。 goose run はスクリプトやCIに適しています：-q フラグは出力にモデルの回答のみを残し、--output-format json は解析用の結果を返します。--max-turns（エージェントが人間の介入なしに行うターン数）と --max-tool-repetitions（同じ引数で同じツールを連続して呼び出せる回数）の制限がループを防ぎます。

プライバシー。 Gooseの匿名使用統計はデフォルトで無効です（GOOSE_TELEMETRY_ENABLED）。ゲートウェイはプロンプトや回答の内容を保存しません — 統計には消費の集計のみが残ります。