OpenCode 2.0 vs Claude Code：移行判断

「インストールできる」と「移行できる」は別の判断です

OpenCode 2.0の公式ドキュメントは、現在の資料がベータ版向けであり、データ消失、機能不具合、APIや設定の変更が起こり得ると明記しています。さらに、OpenCode 1のopencodeとOpenCode 2.0のopencode2は別の実行ファイルとして併用できます。これは主力環境を壊さずに試せるという利点ですが、同時に「まだ完成版の置き換えではない」ことも示しています。

OpenCode 2.0の公式スタートガイドでは、現時点のベータ版に対して@nextパッケージを使う手順が案内されています。Homebrewによるベータ版の導入は利用できないとされているため、普段のMac環境にそのまま追加する前に、専用ユーザー、別ディレクトリ、または隔離したMac環境を用意する方が安全です。(opencode.ai)

移行目的は、次の3つに分けてください。

• モデルを替えたい：Claude以外のモデルやローカルモデルを試したい。
• ツールの固定を避けたい：複数の提供元、BYOK、自社ゲートウェイを使いたい。
• 代理作業の流れ全体を替えたい：計画、編集、シェル実行、子エージェント、復旧まで置き換えたい。

最初の目的ならOpenCode 2.0を試す価値があります。しかし3つ目まで求める場合は、初回生成の品質ではなく、失敗後にどれだけ短時間で安全な状態へ戻せるかを検証しなければなりません。

固定料金の安心感とBYOKの柔軟性は同じではありません

Claude Codeは、Anthropic ConsoleのAPI利用、ClaudeのProまたはMaxプラン、企業向け基盤など複数の認証経路に対応しています。ClaudeのProおよびMaxでは、Web上のClaudeとClaude Codeの利用量が同じ制限に加算されるため、開発作業以外の利用も含めて上限を管理する必要があります。公式の利用条件では、料金と利用量が別管理になるAPI利用についても説明されています。(Anthropic公式のClaude Code利用条件)

OpenCode 2.0は、公式資料上、複数のLLM提供元、カスタムエンドポイント、環境変数による認証、ローカルモデルを組み合わせる設計です。/connectで登録した認証情報はOpenCodeのサービス側データベースに保存されるため、「オープンソースのクライアントだからキー管理も完全にローカル」と考えるのは危険です。提供元ごとの保存場所、削除方法、接続方式を確認してください。(OpenCode 2.0の提供元設定)

費用比較では、モデルの単価だけを並べてはいけません。同じコードベースで同じ課題を実行し、入力回数、再試行、手動修正、ロールバック、API利用量を記録します。OpenCode 2.0が安いモデルを選べても、失敗した変更を人間が戻す時間が増えれば、プロジェクト全体の費用は下がらないからです。

固定プランとAPI利用は別の商品として扱われるため、個人開発者は「月額契約に含まれる範囲」と「追加API費用」を分けて記録してください。利用量の確認方法とAPI請求の扱いは、Anthropic公式のAPI請求説明で確認できます。

失敗後の復旧を比べると、移行の本当の差が見えます

終端AIエージェントの比較では、最初に正しいコードを出したかより、複数ファイルの変更が失敗した後に復旧できるかが重要です。検証用リポジトリでは、次のような課題を同じ条件で実施します。

1. Swiftまたは別の主要言語で、複数ファイルにまたがる小さな機能を指定します。
2. 変更前にgit switch -c agent-trialとgit statusを実行し、作業状態を保存します。
3. 計画だけを求め、どのファイルを読むか、どのコマンドを実行するかを記録します。
4. 編集、依存関係の確認、テスト、差分確認を順に許可します。
5. 一部のテストを意図的に失敗させ、エージェントが原因を追跡できるか確認します。
6. git diffで不要な変更を判定し、必要なら変更を戻して同じ課題を再実行します。
7. 最後にXcodeでビルド、シミュレーター起動、署名設定の確認を行います。

Claude CodeはCLIから会話の継続やセッション再開を行う機能を備えています。会話の継続、作業ディレクトリの追加、許可ツール、拒否ツール、プランモードなどの操作は、Claude Code公式CLIリファレンスで確認できます。

OpenCode 2.0にも、読み取り中心のplanエージェント、開発向けのbuildエージェント、子エージェントの仕組みがあります。ただしベータ版では構成やAPIが変わり得るため、単発のデモではなく、同じ課題を複数回実行して人工的な介入回数とロールバック回数を記録する必要があります。

ここで見るべき指標は、次の5項目です。

• 初回の計画が実行可能だったか。
• ファイル間の変更漏れが何回発生したか。
• 人間が途中でコマンドや編集を引き継いだ回数。
• 失敗後に変更前の状態へ戻せたか。
• Xcodeのビルドとテストまで完了したか。

公式ベンチマークや短い画面録画だけでは、この復旧コストは判断できません。NodeMini側の同一タスク実測がない場合、安定性や生成品質を断定せず、読者自身のコードベースで記録する必要があります。

権限設定は移行前に作り直す必要があります

OpenCode 2.0では、V2設定でpermissionsという順序付き配列を使います。旧形式のpermission、bash、taskはV2の記述として使わないよう公式資料で案内されており、V1からの移行ではbashからshell、taskからsubagent、writeやpatchからeditへの変更が関係します。詳しくはOpenCode 2.0の権限仕様と移行資料を確認してください。

たとえば、検証用プロジェクトでは次のように、読み取りは許可しても環境変数と外部ディレクトリ、公開操作は止める設計から始めます。

{
  "$schema": "https://opencode.ai/config.json",
  "permissions": [
    { "action": "read", "resource": "*", "effect": "allow" },
    { "action": "read", "resource": "*.env*", "effect": "ask" },
    { "action": "edit", "resource": "*", "effect": "ask" },
    { "action": "shell", "resource": "git status *", "effect": "allow" },
    { "action": "shell", "resource": "git push *", "effect": "deny" },
    { "action": "external_directory", "resource": "*", "effect": "deny" }
  ]
}

$ opencode2
permission required: shell
resource: git push origin main
action: deny

個人プロジェクトの最低基準は、.env、秘密鍵、証明書、配布用プロファイルを読み取り対象から外し、git push、削除、外部ディレクトリへのアクセスを毎回確認することです。チームリポジトリでは、さらに共有設定をリポジトリへ置き、個人の自動承認を前提にしない運用が必要です。

Claude Codeでも許可ツールと拒否ツールを指定でき、確認を省略する設定があります。ただし主力リポジトリや秘密情報を含む環境で安易に使うべきではありません。コードやプロンプトがクラウド上のモデルへ送信される点も共通しており、クライアントがオープンソースかどうかだけでデータ経路は判断できません。

FAQ：移行前に確認したい4つの判断

OpenCode 2.0はClaude Codeの完全な代替になりますか？

現時点では、安定案件の完全な代替として扱うべきではありません。OpenCode 2.0はベータ版で、設定、プラグイン、サーバーAPIが変更される可能性があります。複数モデルを使いたい開発者は、まず小規模な検証用リポジトリで並行運用し、復旧とXcodeビルドまで確認してください。

OpenCodeとClaude Codeはどちらが費用を管理しやすいですか？

定額プランの範囲内で作業量を予測したい場合はClaude Codeが管理しやすい傾向があります。OpenCode 2.0は接続先を自由に選べますが、提供元ごとの従量課金、APIキー、利用上限を別々に管理する必要があります。安さではなく、同じ課題の総作業時間と請求額で比較してください。

OpenCodeはMac上でXcodeと連携できますか？

macOSのターミナルからOpenCode 2.0を実行し、同じプロジェクトをXcodeで開く運用は可能です。ただし、AIエージェントが担当するコード編集と、Xcodeが担当する署名、シミュレーター、アーカイブ、配布設定は別の工程です。ターミナルで動いたことだけをもってiOSアプリの納品完了とは判断できません。

Claude CodeのプロジェクトをOpenCodeへ移す際の注意点は何ですか？

設定、権限、MCP接続、環境変数、モデル指定を分離して移行してください。OpenCode 2.0では旧バージョンと権限キーが異なるため、設定ファイルをコピーするだけでは安全な移行になりません。APIキーをコミットせず、読み取り、編集、シェル、外部ディレクトリを個別に再検証することが重要です。

MacでのXcode運用は「併用」が前提になります

OpenCode 2.0とClaude Codeは、macOSのターミナル、Git、プロジェクトファイルを扱う作業には使えます。しかし、Xcodeプロジェクトではコード生成以外に、依存関係の解決、証明書、署名、シミュレーター、アーカイブ、配布先の確認が残ります。

そのため、Mac開発者の実務では次の分担が現実的です。

• AIエージェント：コード探索、編集、テストコマンド、差分整理。
• Xcode：プロジェクト設定、署名、シミュレーター、アーカイブ。
• 開発者：秘密情報、依存関係の追加、最終差分、実機またはシミュレーターの確認。

Macを常時使えない場合は、遠隔Mac環境の選び方を確認し、検証用の環境と本番用の開発機を分ける方法があります。特に、OpenCode 2.0の隔離試行、権限設定、Xcodeビルド確認を一台の主力Macへ集中させない方が、ベータ版の変更による影響を抑えやすくなります。NodeMiniのMac環境を使う場合も、ツールの優劣を前提にせず、利用するリポジトリ、接続先、署名情報、作業終了後の削除手順を先に定めてください。

一週間の二重運用で正式移行の条件を決めます

移行を判断する週は、OpenCode 2.0とClaude Codeに同じ課題を渡し、次の記録を残します。

1. 同じコミットからブランチを作成します。
2. 同じ指示文と受け入れ条件を使います。
3. 使用モデル、API経路、利用量を記録します。
4. 人間による修正、拒否、再試行を記録します。
5. git diff、テスト、Xcodeビルドの結果を保存します。
6. 問題が出た場合のロールバック時間を測ります。
7. 最終日に費用、設定変更、権限警告、納品可否を比較します。

判断条件は次のように固定すると、印象に引きずられません。

• OpenCode 2.0を試す：複数モデル、BYOK、ローカルモデルが必須で、検証用リポジトリを分離できる場合。
• Claude Codeを継続する：主力案件の納期、復旧手順、チームの統一運用を優先する場合。
• 二重運用を続ける：OpenCode 2.0でモデル選択の自由は得られたものの、修正回数、設定保守、請求確認が増えた場合。
• 段階的に移行する：一週間の検証で主要タスク、ロールバック、権限確認、Xcodeビルドが連続して通り、費用の説明もできる場合。

現在の構成がClaude Codeの利用制限、モデル固定、追加API費用、単一提供元への依存によって苦しくなっているなら、OpenCode 2.0を試す理由はあります。ただし、ベータ版の設定変更、複数APIの請求管理、権限ルールの再設計、Xcode納品前の手動確認という負担も増えます。

そのため、Mac開発者が取るべき結論は「全量移行」ではなく、まず一週間の二重運用です。常時使えるMacを用意できない場合は、Mac上で終端AIエージェントを導入する際の環境確認を参照し、隔離したNodeMiniのMac環境で試行、ロールバック、Xcodeビルドまで記録してから、主力リポジトリを動かすか決めるのが安全です。

現在の環境をそのまま使う場合、ベータ版の設定を主力Macへ混在させること、複数APIの請求を一つの予算として扱うこと、権限を自動承認に寄せすぎることが主な弱点になります。短期の検証、臨時の開発環境、複数モデルの比較にはNodeMiniのレンタルMacが適していますが、長期の高負荷運用や物理デバイス接続が必要な開発では、自社管理のMacの方が適しています。