OpenCode プロバイダー：モデル、キー、設定を確認する7項目

OpenCode プロバイダー を検索する人は、対応サービス、外部プロバイダーの追加、OpenAI 互換エンドポイント、またはプロバイダーは表示されるのにモデルがない理由を知りたい場合があります。価格、モデル ID、認証方式は変わるため、固定のサービス一覧より判断手順のほうが長く使えます。

公式の Providers ドキュメントには Credentials、Config、OpenCode の Zen、OpenCode の Go、プロバイダーのディレクトリがまとまっています。本ページでは、その情報を使う順番として、層を確認し、最小の接続を選び、モデル ID を検証し、書き込み操作の前に証拠を残す流れを示します。

プロバイダーはモデルサービスへの経路です。モデルはそのサービスが公開する具体的な能力で、認証情報はリクエストが許可されていることを示します。3つを一つの設定として扱うと、正しいキーで間違ったモデル ID は直せず、モデルが表示されても認証が有効とは限りません。

設定のスコープは4つ目の論点です。プロジェクトの設定では動いてもグローバル設定では動かないことがあり、管理された設定が編集内容を上書きすることもあります。ファイル、スコープ、プロバイダー名、モデル ID、確認日を記録し、ローカルパスを含む設定全体は共有しないでください。

実用的な経路は4つです。OpenCode の Go と OpenCode の Zen はそれぞれ料金やモデルの前提を持つ公式サービスです。第三者のホスト型プロバイダーは、チームの請求、地域制御、既存のモデルカタログを使う場合に向きます。OpenAI 互換またはローカルのエンドポイントは柔軟ですが、URL、モデル検出、ランタイム、診断を自分で確認する範囲が増えます。

ディレクトリの名前だけで選ばないでください。月額の予測性、従量制の管理、データの場所、オフライン、品質、遅延、既存の運用サービスのどれが優先かを先に決めます。モデル一覧が不安定で、OpenCode の実行環境からエンドポイントを検証できないなら、安さだけでは十分な理由になりません。

公式の設定形式では、カスタムプロバイダーを provider の下に置きます。npm アダプター、オプション、認証変数、モデルの定義はサービスごとに異なります。提供元の公式ドキュメントを先に読み、理解したフィールドだけを使い、エンドポイントとアダプターを選んだ理由を記録してください。

秘密値はリポジトリの外で管理します。OAuth、環境変数、プラットフォームの認証情報ストアを使い、実際の API キーを opencode.json、スクリーンショット、シェル履歴、共有セッションに貼らないでください。ログに出た場合は、続行前にキーをローテーションします。

テスト時はプロバイダーを1つずつ追加します。変更を小さくすると schema の問題、サービス障害、ロールバックを分けられます。新しいブロックを削除し、既知のモデルに戻して、既知のリクエストを再実行します。

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "my-provider": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "provider-demo",
      "options": { "baseURL": "https://api.provider.test/v1" },
      "models": { "model-id": { "name": "Model name" } }
    }
  }
}

Provider の設定は、OpenCode が実際のモデルを見つけて小さなリクエストを完了して初めて終わります。現在の公式ドキュメントで ID と認証方法を確認し、/models で選択できるモデルを見ます。複数のモデルがある場合は、コンテキスト、ツール、遅延、費用が作業に合う1つから始めます。

最初のリクエストは読み取り専用で比較しやすいものにします。小さなローカルファイルの説明を求めるか、コマンドを実行せず次の検証手順だけを聞きます。応答、ツール、時間、使用モデルを記録し、その後で編集や外部への書き込みを試します。

1. スコープを確認グローバル、プロジェクト、カスタムパス、管理設定を区別します。
2. キーを保護OAuth、環境変数、プロバイダーのストアを使います。
3. Provider を確認ID、アダプター、エンドポイント、公式手順を照合します。
4. モデルを確認表示名ではなく正確なモデル ID を使います。
5. モデルを一覧セレクターまたは公式の `/models` 手順を使います。
6. 読み取りでテスト小さなプロンプトを送り、予想結果と比較します。
7. 戻し方を記録有効な設定、結果、最小の撤回手順を残します。

認証、検出、モデル、通信を分けると、プロバイダーのエラーを直しやすくなります。401 や OAuth のループは認証情報や scope、Provider が表示されない場合は設定スコープや schema、モデルがない場合はカタログや ID、検出後のタイムアウトはネットワーク、プロキシ、地域、サービス状態を疑います。

1回のテストで変更する変数は1つにします。公式手順でエンドポイントを確認し、OpenCode が読むファイルを確認し、モデルを一覧し、最後にプロンプトを試します。1つの障害を調べるために Provider を増やすと、一覧とログが読みにくくなります。

予測可能なサブスクリプションと枠が必要なら OpenCode の Go、選択されたカタログと従量制なら Zen が候補になります。請求、コンプライアンス、地域、特定モデルが重要ならホスト型の第三者プロバイダー、オフラインや互換ゲートウェイが必要でランタイムを自分で管理できるならローカル/ OpenAI 互換エンドポイントが向きます。これは適合性の判断であり、永久的なランキングではありません。

Provider はプライバシーの前提も変えます。CLI はローカルでも、リクエストは選んだモデルサービスへ送られることがあります。ポリシーを読み、秘密や不要な顧客データを送らず、本番でないリポジトリで初回検証を行います。Models、JSONC、Ollama、Go vs Zen の各ガイドが隣接テーマを扱うため、このページでは重複させずにリンクします。

広い OpenCode プロバイダー の検索に対する有用な答えは、固定の勝者一覧ではなく再現可能な接続です。ディレクトリ、モデル、価格、制限、ログイン方法は変わるため、設定日に公式ページを再確認して日付を残します。