OpenCodeは、2026年に最も注目を集めているオープンソースのAIコーディングエージェントの一つです。「モデル非依存、ターミナル優先」という設計哲学を掲げており、開発者はClaudeだけでなく、GPT、Gemini、ローカルモデルなどを自由に、あるいは組み合わせて利用できます。Claude Codeと同様にターミナル上で動作しますが、プロバイダーをプラグイン可能な設定項目として抽象化し、ユーザーが基盤モデルを自由に選択できるという異なるアプローチをとっています。
多くの読者から「OpenCodeはOpenAI互換モードで呼び出しているように見えるが、Anthropicのネイティブ形式をサポートしているのか？APIYIのようなサードパーティのAPI中継サービスを利用する場合、どのように設定するのが最適か？」という具体的な質問をいただきました。
本記事では、英語の公式ドキュメントとソースコードに基づき、OpenCodeとは何か、Claude Codeとの決定的な違い、そしてAPIYI（apiyi.com）API中継サービスへの接続方法（OpenAI互換およびAnthropicネイティブ呼び出しの両方）を詳しく解説します。読み終える頃には、すぐに設定を開始できるようになっているはずです。
OpenCodeプロジェクト紹介：オープンソースAIコーディングエージェントの核心
OpenCodeはSSTチーム（Serverless Stackフレームワークの作者）によって保守されており、リポジトリは github.com/sst/opencode で、MITライセンスで公開されています。執筆時点でGitHubのスター数は15万を超え、850人以上のコミュニティ貢献者を抱える、現在最も活発なオープンソースのコーディングエージェントプロジェクトの一つです。ターゲットユーザーは明確で、ターミナル内でコーディングタスクの大部分を完結させたい、かつ特定のモデルベンダーに縛られたくない中上級開発者です。
OpenCodeのアーキテクチャ設計と動作モード
OpenCodeはクライアント/サーバーアーキテクチャを採用しており、エージェントのコアロジックをローカルのサービスプロセスで実行し、TUI（ターミナルUI）を数あるフロントエンドの一つとして位置づけています。これは、同一のエージェントインスタンスをターミナル、デスクトップアプリ、IDEプラグイン、さらにはモバイル端末から同時にアクセスできることを意味しており、将来的なマルチデバイス連携の可能性を大きく広げています。
Tabキーで即座に切り替え可能な2つのエージェントモードが組み込まれています。
buildモード：デフォルトですべてのツール権限（読み取り、書き込み、コマンド実行）が許可されており、実際の開発タスクに適しています。planモード：読み取り専用モード。コード分析、設計、提案のみを行い、ファイルは一切変更しません。
| 項目 | OpenCodeの設計ポイント | 開発者にとっての価値 |
|---|---|---|
| アーキテクチャ | クライアント/サーバー分離 | マルチデバイス連携、リモート制御 |
| モデル層 | プラグイン可能なプロバイダー | 75種類以上のモデルを自由に切り替え |
| インタフェース | TUI / デスクトップアプリ / IDEプラグイン | UIに縛られない |
| 権限層 | build / plan のデュアルモード | 安全性と効率の両立 |
| デプロイ | ローカル優先、リモート接続対応 | ローカル環境でのデータ保持 |
🎯 設定のヒント：OpenCodeでClaude、GPT、Gemini、DeepSeekなどの多様なモデルを利用したい場合、各サービスでアカウントを作成し、複数のAPIキーを管理するのは手間です。APIYI（apiyi.com）API中継サービスに接続すれば、一つのトークンで主要モデルを網羅的に利用できます。
OpenCodeの核心的な能力
その能力の境界線は、従来のIDEプラグインよりもはるかに広大です。ターミナルで自然言語を入力するだけで、OpenCodeはコードベース全体を解釈し、機能の追加、既存ロジックの修正、テストの実行、さらにはファイル横断的なリファクタリングまで行います。plan モードは事前のレビューに使用し、エージェントが実装案を出力した後に、開発者が確認してから build モードに切り替えて実装を適用するといった使い方が可能です。
また、非対話モード opencode run "your prompt" もサポートしており、シェルスクリプトに直接組み込んでCI/CD、バッチリファクタリング、定期タスクなどの自動化シナリオに活用できます。この能力はClaude Codeの初期にはなかったもので、OpenCodeがエンジニアリング現場で頻繁に選ばれる理由の一つです。
特筆すべき点として、OpenCodeはデフォルトで models.dev という公開データベースからモデルリストを取得・照合します。そのため、上流のプロバイダーが新しいモデルをリリースしても、OpenCodeは迅速にそれを認識できます。API中継サービスを介して接続する場合、ローカルに保持されているモデルマッピングとAPIYIのモデルリストを一致させることで、「設定にはモデルIDを書いたのに、実際の呼び出しで拒否される」といったトラブルを回避できます。
OpenCode と Claude Code の核心的な違い
OpenCode を「Claude Code のオープンソース版」と捉える人が多いですが、両者の本質的な立ち位置は異なります。Claude Code は Anthropic が自社モデルのために最適化した公式ツールであるのに対し、OpenCode はマルチモデルエコシステムを前提とした中立的なフレームワークです。
モデルのサポート範囲とコスト管理
Claude Code は Anthropic の自社モデル（Sonnet、Opus、Haiku シリーズ）のみを呼び出せるため、すべてのタスクが Anthropic の料金体系に従います。一方、OpenCode は OpenAI、Anthropic、Google Vertex、Bedrock、Groq、Azure、OpenRouter、さらには Ollama や LM Studio といったローカル推論バックエンドを含む 75 以上のプロバイダーをサポートしています。
実際のワークフローにおいて、この柔軟性は非常に強力です。ドキュメント生成やコミットメッセージの作成、変数名の変更といった軽いタスクは安価な小型モデルに任せ、複雑なリファクタリングやアーキテクチャの検討には Claude Sonnet や Opus を使うことで、全体のコストを通常 40〜60% 削減できます。
ワークフローと権限モデルの違い
Claude Code はデフォルトで保守的なアプローチをとっており、ファイルの書き込みやコマンド実行の前に確認を求めます。初心者には優しいですが、作業のリズムが中断されることもあります。OpenCode は透明性を重視しており、コードは完全にオープンソースで安全チームによる監査が可能です。権限は build/plan の切り替えによって明示的に管理されるため、自動化やスクリプト化との相性が抜群です。
| 比較項目 | OpenCode | Claude Code |
|---|---|---|
| オープンソース | MIT ライセンス、監査可能 | クローズドソース、バイナリのみ |
| モデル範囲 | 75+ プロバイダー、ローカル対応 | Anthropic 公式モデルのみ |
| カスタムエンドポイント | baseURL を任意に変更可能 | ANTHROPIC_BASE_URL で変更 |
| インターフェース | TUI / デスクトップアプリ / IDE プラグイン | ターミナル中心 |
| 権限ポリシー | build / plan で明示的に切り替え | デフォルトで確認を要求 |
| 成熟度 | 進化が速く、一部調整中 | 非常に洗練された体験 |
| 適した用途 | マルチモデル混在、ローカル、カスタマイズ | Claude 一本での開発 |
🎯 選択のアドバイス: Claude をメインにしつつ、たまに GPT や Gemini を補完として使いたい場合は、OpenCode で APIYI (apiyi.com) を経由して複数のモデルを設定し、同じトークンで切り替えるのがおすすめです。日常的なメイン開発は Claude Code で行い、複雑なタスクのクロスチェックが必要な時だけ OpenCode に切り替えるという運用が効率的です。
OpenCode はどのような人に向いているか
OpenCode は、設定ドキュメントを読む手間を惜しまず、コストに敏感で、一つのツールチェーンで複数のモデルを横断的に使いたい、あるいは会社の方針でモデルの監査が必要な開発者に最適です。もし「Claude をすぐに使い始めたい」というだけであれば、Claude Code の方がスムーズな選択肢となるでしょう。
OpenCode を APIYI 中継サービスに接続する2つのモード
読者が最も気になっている「OpenCode は OpenAI 互換モードを使うべきか、Anthropic ネイティブ形式を使うべきか」という点についてですが、答えは両方サポートされており、opencode.json でどのようにプロバイダーを設定するかによって決まります。
モード1：OpenAI 互換モード（最も汎用的）
これは OpenCode のドキュメントで推奨されている方法であり、サードパーティの中継サービスに接続する最も安全なルートです。内部的には Vercel AI SDK の @ai-sdk/openai-compatible パッケージを使用し、OpenAI Chat Completions プロトコルに準拠したあらゆるエンドポイントを OpenCode プロバイダーとしてラップします。APIYI の OpenAI 互換エンドポイントは api.apiyi.com/v1 であり、GPT、Claude、Gemini、DeepSeek など数十種類のモデルを OpenAI 形式に統一して呼び出せます。
利点は汎用性が高いことで、ほぼすべてのモデルを一つのプロバイダーで管理できます。代償として、Anthropic 独自の機能（extended thinking やネイティブの tool use ブロックなど）はプロトコル変換を経るため、ごく一部の挙動が Anthropic 公式エンドポイントとわずかに異なる場合があります。
モード2：Anthropic ネイティブモード（Claude 利用時に推奨）
OpenCode の組み込み anthropic プロバイダーは @ai-sdk/anthropic パッケージを使用しており、リクエストパスは /v1/messages、リクエストボディ形式は Anthropic 公式ドキュメントで定義された Messages API です。この形式は content blocks、tool_use ブロック、extended thinking といった Claude 特有の機能をサポートしており、Claude Code と完全に同じプロトコルを使用します。
provider.anthropic.options.baseURL を APIYI の https://api.apiyi.com に向けるだけで、OpenCode は Anthropic ネイティブ形式でリクエストを送信し、APIYI 中継サービスがそれを上流の Claude に転送します。つまり、OpenCode 上で Claude Code とほぼ同等の Claude 呼び出し体験が得られます。
| モード | 内部パッケージ | APIYI Base URL | 適した用途 | プロトコル忠実度 |
|---|---|---|---|---|
| OpenAI 互換 | @ai-sdk/openai-compatible |
https://api.apiyi.com/v1 |
マルチモデル混在 | 標準 OpenAI |
| Anthropic ネイティブ | @ai-sdk/anthropic |
https://api.apiyi.com |
Claude 全シリーズ | 公式と一致 |
🎯 設定のアドバイス: 日常的な利用には、デュアルモードの併用をおすすめします。同一の
opencode.jsonにanthropicプロバイダーとopenai-compatibleプロバイダーの両方を設定し、前者を Claude 用に、後者を GPT/Gemini/DeepSeek 用に使用します。両方のプロバイダーで APIYI (apiyi.com) の同じトークンを共有できるため、APIキーを重複して管理する必要はありません。
3ステップで完了！OpenCode と APIYI 中継サービスの接続設定
最小限の構成で動作させるための手順を解説します。この手順通りに進めれば、通常5分以内に設定が完了します。
ステップ1：OpenCode クライアントのインストール
公式が提供している2つの主要なインストール方法のうち、環境に合わせていずれかを選択してください。
# 方法 A：npm によるグローバルインストール（Node.js ユーザー向け）
npm install -g opencode-ai@latest
# 方法 B：ワンライナーによるインストール（macOS / Linux 向け）
curl -fsSL https://opencode.ai/install | bash
インストール完了後、opencode --version を実行して正しくインストールされたか確認してください。Windows ユーザーは Scoop または WSL を介して利用可能です。npm でのインストールが失敗する場合は、Node.js のバージョンが古い可能性があるため、18+ または 20+ へのアップデートを推奨します。
ステップ2：APIYI 管理画面で APIキー を取得
APIYI の管理画面にログインし、トークン管理ページ api.apiyi.com/token で新しいトークンを作成します。名前は OpenCode とすることをおすすめします。また、対応するグループを選択してください（Claude を呼び出す場合は、そのグループに Claude シリーズのモデルが含まれていることを確認してください）。生成された sk-xxx から始まる文字列をコピーし、次のステップで使用します。
🎯 トークン管理のヒント：APIYI (apiyi.com) に登録後は、クライアントごとに個別のトークンを作成することをおすすめします（例：ClaudeCode 用、OpenCode 用、Cursor 用など）。こうすることで、特定のクライアントで異常なリクエストが発生した場合でも、そのトークンを無効化するだけで済み、他のクライアントには影響を与えません。
ステップ3：opencode.json 設定ファイルの編集
OpenCode はプロジェクトルートにある opencode.json を優先的に読み込みます。見つからない場合はユーザー設定ファイル ~/.config/opencode/opencode.json を読み込みます。以下に、Anthropic ネイティブモードと OpenAI 互換モードを共存させる設定例を示します。
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"anthropic": {
"options": {
"baseURL": "https://api.apiyi.com",
"apiKey": "{env:APIYI_KEY}"
}
},
"apiyi-openai": {
"npm": "@ai-sdk/openai-compatible",
"name": "APIYI OpenAI 互換",
"options": {
"baseURL": "https://api.apiyi.com/v1",
"apiKey": "{env:APIYI_KEY}"
},
"models": {
"gpt-4o": { "name": "GPT-4o" },
"claude-sonnet-4-6": { "name": "Claude Sonnet 4.6" },
"gemini-2.5-pro": { "name": "Gemini 2.5 Pro" }
}
}
}
}
次に、APIキー を環境変数に設定します。
# macOS / Linux
echo 'export APIYI_KEY="sk-APIYI管理画面で取得したトークン"' >> ~/.zshrc
source ~/.zshrc
# Windows PowerShell
$env:APIYI_KEY = "sk-APIYI管理画面で取得したトークン"
OpenCode を起動したら、スラッシュコマンド /models を使用してモデルを選択します。Claude シリーズは anthropic プロバイダーを、その他のモデルは apiyi-openai プロバイダーを使用することをおすすめします。
🎯 base URL のルール：Anthropic ネイティブモードでは
/v1を付けないでください（SDK が自動的に/v1/messagesを追加するため）。一方、OpenAI 互換モードでは必ず/v1を付ける必要があります。このルールは APIYI (apiyi.com) が Claude Code のドキュメントで案内している指針と完全に一致しています。「ネイティブは付けない、互換は付ける」と覚えておきましょう。
設定時によくあるエラーとトラブルシューティング
| エラーメッセージ | 考えられる原因 | 対処法 |
|---|---|---|
Route /api/messages not found |
baseURL に /v1 が含まれている |
/v1 サフィックスを削除する |
Required provider.anthropic.models |
カスタム baseURL 設定で models フィールドが不足 | 利用可能なモデル ID を明示的に記述する |
401 Unauthorized |
トークンが無効、またはグループにモデルが含まれていない | APIYI トークンを再生成する |
model not found |
モデル ID が APIYI 管理画面と一致していない | APIYI のモデル一覧で正しい ID を確認する |
| リクエストタイムアウト | ネットワークの不安定さ、または上位側の制限 | APIYI のノードを切り替えるか、再試行する |
🎯 トラブルシューティングのヒント：エラーが発生した際は、まず
curl https://api.apiyi.com/v1/models -H "Authorization: Bearer $APIYI_KEY"を実行し、トークンとネットワークの接続性を確認してください。この手順で90%の問題を30秒以内に特定できます。opencode.jsonを何度も修正するよりも効率的です。リストが正常に返ってくる場合は、OpenCode の設定層に問題がある可能性が高いです。
OpenCode と APIYI 中継サービスの実践的な活用シーン
設定が完了したら、次はワークフローの最適化です。よく使われる実践的な活用方法を紹介します。
シーン1：plan モードによる副作用のないコードレビュー
plan モード（Tab キーで切り替え）に切り替え、「/このリポジトリの認証フローを解説して」と入力すると、OpenCode はコードをスキャンして分析レポートを出力します。ファイルへの書き込みは一切行われません。新しいメンバーのオンボーディングや、セキュリティレビュー、レガシーコードの構造整理に最適です。
シーン2：build モードによるエンドツーエンドの開発タスク
方針が固まったら build モードに切り替え、「認証ミドルウェアを JWT ベースの実装に変更し、単体テストを追加して」といったタスクを依頼します。OpenCode は関連ファイルを読み込み、修正し、テストを実行し、失敗した場合は原因を分析して反復修正を行います。Git のクリーンなブランチで実行し、いつでもロールバックできるようにしておくことを推奨します。
シーン3：マルチモデル連携とコスト管理
OpenCode のプロバイダー抽象化機能を活用し、タスクごとに最適なモデルを割り当てることができます。
- ドキュメント作成やコミットメッセージ生成：
apiyi-openaiのgpt-4o-miniを使用（コストを最小化）。 - 複雑なリファクタリングやコードレビュー：
anthropicプロバイダーのclaude-sonnet-4-6や Opus シリーズを使用。 - 多言語対応や視覚情報を含むタスク：
apiyi-openaiのgemini-2.5-proを使用。
🎯 コストに関するヒント：APIYI (apiyi.com) を経由した呼び出しは、すべて実際のトークン使用量に基づいた従量課金制であり、最低利用料金はありません。まずは低価格モデルでフローを構築し、効果を確認してから高機能モデルへ切り替えることで、予算を効率的に運用できます。
シーン4：非対話モードによる CI/CD への組み込み
OpenCode の opencode run コマンドを使用すると、プロンプトをシェルから直接渡すことができ、出力結果を stdout で取得できます。これにより、GitHub Actions、GitLab CI、または定期実行タスクへの組み込みが可能です。例えば、毎週自動的にリポジトリ構造のレビューを行ったり、PR マージ前にチェンジログの草案を自動生成したりできます。
よくある質問 FAQ
Q1：OpenCode は本当に Anthropic ネイティブの /v1/messages プロトコルをサポートしていますか？
はい、サポートしています。OpenCode に組み込まれている anthropic プロバイダーは @ai-sdk/anthropic パッケージを使用しており、リクエストパスは Anthropic 公式の /v1/messages、リクエストボディも公式の Messages API 形式となっており、Claude Code と同じプロトコルを採用しています。baseURL を APIYI (apiyi.com) に向けるだけで、OpenCode で Claude Code とほぼ同等の体験が得られます。
Q2：OpenAI 互換モードのみを使用した場合、Claude のどのような機能が失われますか？
OpenAI 互換モードでは、Anthropic 独自の tool_use ブロック、extended thinking、キャッシュ制御ヘッダーなどの機能がプロトコル層で適応されます。機能自体は使用可能ですが、レスポンス形式が変換されるため、一部の細かい挙動（Thinkingトークンの課金や特定の停止理由など）がネイティブモードと若干異なる場合があります。Claude をメインで開発に使用する場合は、ネイティブモードでの利用を推奨します。
Q3：OpenCode の設定ファイルは ${env:VAR} と {env:VAR} のどちらをサポートしていますか？
最新バージョンでは {env:VAR} 構文に統一されています（旧バージョンでは ${env:VAR} が使用されていました）。もし OpenCode で apiKey is undefined と表示される場合は、${env:APIYI_KEY} と記述していないか確認し、現在の仕様である {env:APIYI_KEY} に修正してください。
Q4：OpenCode 標準の /connect コマンドで直接 APIYI に接続できますか？
可能です。/connect を実行して "Other" を選択し、プロバイダーID（apiyi-openai など）を入力して APIYI トークンを貼り付けると、OpenCode が自動的に opencode.json に書き込みます。ただし、/connect はデフォルトで OpenAI 互換パスを通るため、Anthropic ネイティブモードを使用したい場合は、手動で provider.anthropic.options.baseURL を編集することをお勧めします。
Q5：Claude Code と OpenCode で APIYI の同じトークンを共有できますか？
全く問題ありません。むしろ強く推奨します。APIYI (apiyi.com) のトークンはクライアントに依存しないため、同じ sk-xxx トークンを Claude Code（ANTHROPIC_BASE_URL 経由）、OpenCode（opencode.json 経由）、Cursor、Continue など複数のクライアントで同時に使用できます。バックエンドの請求は、呼び出し元ごとにまとめて確認可能です。
Q6：OpenCode の plan / build モードと、Claude Code の権限確認は同じものですか？
設計目標は似ていますが、実装パスは異なります。Claude Code は逐次確認型で、ファイル書き込みやコマンド実行のたびに確認ダイアログが表示されます。一方、OpenCode はモード切り替え型で、plan モードでは書き込み権限が根本的に無効化され、build モードではデフォルトで許可されます。OpenCode の方式は自動化シナリオに適しており、Claude Code はステップごとに制御が必要なシナリオに適しています。
Q7：APIYI API中継サービス経由で Claude を呼び出すと、公式直結より遅延しますか？
APIYI (apiyi.com) は国内の複数の主要ノードに入口を配置しており、Claude、GPT、Gemini などの主要な上流モデルに対してリンク最適化を行っています。国内ユーザーが体感する最初のバイトまでの遅延（TTFB）は、公式エンドポイントへの直結よりも大幅に短縮されることが一般的です。具体的な数値は、ご自身のネットワーク環境で curl -w "%{time_starttransfer}" を使用して比較測定してみてください。
まとめ：OpenCode + APIYI のベストプラクティス
OpenCode の真の価値は「モデルの選択権」を開発者の手に取り戻すことにあり、APIYI のような API中継サービスはその柔軟性を実現するための強力な基盤となります。両者を組み合わせることで、開発者はターミナルで Claude Code に近い体験を享受しつつ、必要に応じて GPT、Gemini、DeepSeek などのモデルに切り替えてクロス検証を行うことができます。ワークフロー全体で管理すべきなのは、OpenCode の設定ファイルと APIYI トークン一つだけです。
冒頭の問いに戻りますが、OpenCode は OpenAI 互換モードと Anthropic ネイティブ形式の両方をサポートしており、これらは排他的ではありません。長期的に利用される場合は、opencode.json に両方のプロバイダーを共存させることをお勧めします。Claude はネイティブパスを使用して全機能を保持し、その他のモデルは互換パスを使用して汎用性を最大化するのが賢い使い方です。
🎯 最終アドバイス：OpenCode を試してみようと考えているなら、まずは APIYI (apiyi.com) に登録してトークンを作成し、本記事の手順に従って両方のモードを有効にするのが最も効率的です。1週間もすれば、「一つのトークンですべてのモデルを駆動する」というスタイルなしではいられなくなるはずです。モデルごとにアカウントや残高を管理する手間から解放されましょう。
— APIYI 技術チーム | AIコーディングエージェントのエコシステムを継続的に追跡中。その他のチュートリアルは APIYI (apiyi.com) ヘルプセンターへ。
