OpenCode

OpenCode は、ターミナルを主なインターフェースとするオープンソースのエンドツーエンドな AI コーディングエージェントであり、開発者がローカル環境でコードを書き、エラーを修正し、コードを理解するのを支援する。Jimmy Song のオンラインハンドブック『智能体构建指南』の一章は、これを AI プログラミングにおける重要なオープンソースプロジェクトの 1 つと位置づけ、Claude Code のようなクローズドソースのコーディングアシスタントに対する重要なオープンソースの代替として紹介している。

プロジェクト自身の README は、これを単に「the open source AI coding agent」（オープンソースの AI コーディングエージェント）と紹介している。macOS、Linux、Windows にわたって、インストールスクリプトまたは多様なパッケージマネージャーでインストールでき、macOS、Windows、Linux 向けにベータ版とされるデスクトップアプリケーションとしても提供されている。README は、名前に「opencode」を使う関連コミュニティプロジェクトに対し、OpenCode チームが作成したものではなく、チームとも無関係であることを明記するよう求めている。

同章の説明によれば、このプロジェクトの設計目標は、従来の AI コーディングアシスタントの「ユーザーが尋ね、プラットフォームが答える」というパターンを超えることにある。同章はそうしたアシスタントを、プロジェクトレベルのコンテキストを欠き、開発ワークフローにうまく組み込めず、単一のモデルプロバイダーに縛られ、不透明に動作するため他のツールと組み合わせにくいと批判している。これに対して OpenCode は、セッションとコンテキストを保持し、複数の LLM とシステムツールを統合し、拡張可能な実行チャネルを公開する、長時間稼働するエージェントシステムとして位置づけられている。特定のベンダーに縛られないため、開発者はランタイムとコンテキストを完全に制御でき、同章はこれをプライバシーと監査可能性の点で優れていると述べている。

機能

ハンドブックの同章は、OpenCode の主な機能として次のものを挙げている。応答性の高いネイティブのターミナルユーザーインターフェース（TUI）、Models.dev を通じたクラウドまたはローカルの 75 以上のモデルプロバイダーのサポート（OpenAI、Anthropic、Google のモデルやローカルモデルをいずれも選択可能）、モデルがコード構造をよりよく理解できるようにする Language Server Protocol との統合、そして協働とデバッグのための共有機能付きの並列セッションである。

同章はアーキテクチャを 3 層で説明している。ターミナル操作層（TUI と CLI）は、開発者をブラウザや IDE に切り替えさせず、ターミナルにとどまらせる。エージェントランタイムは、セッションのコンテキスト、モデルへの適応、ツールの組み合わせ、権限制御を維持し、ユーザーの意図を解析し、モデルとツールを呼び出し、出力を監査する。Plan エージェントと Build エージェントの役割分担が置かれているのはこの層である。拡張ツール層は、ローカルファイルシステムへのアクセス、LSP ベースのコード解析、Model Context Protocol サーバーのような外部ツールチェーンを扱い、これによってエージェントはテキストを生成するだけでなく行動できるようになる。

README は組み込みのエージェントを具体的に説明している。2 つは Tab キーで切り替える。デフォルトの build は開発作業のためのフルアクセスのエージェントであり、plan は分析とコード探索のための読み取り専用のエージェントで、デフォルトでファイル編集を拒否し、bash コマンドを実行する前に許可を求め、見慣れないコードベースの探索や変更の計画に推奨されている。3 つ目の general サブエージェントは複雑な検索や複数ステップのタスクを扱う。これは内部的に使われるほか、メッセージに @general と書くことで呼び出せる。

同章によれば、実際の利用では、Plan エージェントは理解と計画を安全に担い、コードを直接変更しない一方、Build エージェントがレビューや確認を経たうえで実際の変更を行う。ほかのモデルやエージェントは、分析や外部ツールの呼び出しといった補助的な役割を担うことができる。典型的なワークフローでは、エージェントがまず計画を出力し、人間がそれをレビューし、そのうえで初めて変更が実行され、テストとレビューを経て納品に至る。

導入と日常的な利用

OpenCode のドキュメントは、これをターミナルベースのインターフェース、デスクトップアプリ、または IDE 拡張機能として利用できるオープンソースの AI コーディングエージェントとして紹介している。ターミナルで使うには、モダンなターミナルエミュレーターと、使用する LLM プロバイダーの API キーが必要である。インストールは、インストールスクリプト、または npm、Bun、pnpm、Yarn、Homebrew、Arch Linux の pacman と paru、Chocolatey、Scoop、Mise、Docker で行い、Windows で最良の体験を得るには Windows Subsystem for Linux が推奨されている。どの LLM プロバイダーも API キーを設定すれば利用できる。初めて使う人に対してドキュメントは OpenCode Zen を案内しており、これを OpenCode チームがテストし検証したモデルの厳選リストと説明している。OpenCode Zen には /connect コマンドで接続する。プロジェクト内で /init を実行すると、OpenCode がプロジェクトを分析し、プロジェクトのルートに AGENTS.md ファイルを作成する。

ドキュメントが機能追加のために提案するワークフローは、まず計画することである。Tab キーで切り替える Plan モードでは、OpenCode が変更を加える機能が無効になり、代わりにその機能をどのように実装するかを提案させる。ユーザーは計画を反復して練り上げ、画像をターミナルにドラッグしてプロンプトに追加することもでき、その後 Tab で Build モードに戻して変更を行わせる。ドキュメントは、エージェントに十分な詳細を与え、チームのジュニア開発者に話しかけるように接するよう助言している。より単純な変更であれば、計画をレビューせずに直接依頼できる。@ キーでプロジェクト内のファイルをあいまい検索し、プロンプトで参照できる。/undo はエージェントの変更を元に戻し、元のメッセージを復元してプロンプトを調整して再試行できるようにするもので、繰り返し実行できる。/redo はその変更を再適用する。/share は現在の会話へのリンクをチーム向けに作成する。会話はデフォルトでは共有されない。

ルールとカスタム指示

OpenCode 自身のドキュメントは、プロジェクト固有の指示がどのようにモデルに届くかを説明している。それは AGENTS.md ファイルを通じてであり、その内容は LLM のコンテキストに含められる。ドキュメントはこれを Cursor のルールになぞらえている。/init コマンドはリポジトリ内の重要なファイルを走査し、コードベースから答えが得られない場合にはいくつかの的を絞った質問をすることがあり、簡潔なプロジェクト固有のガイダンスを含む AGENTS.md を作成または更新する。その内容は、ビルド・リント・テストのコマンド、ファイル名からは分からないアーキテクチャと構造、プロジェクトの規約とセットアップ上の癖、そして Cursor や Copilot のルールのような既存の指示ソースへの参照である。既存のファイルは置き換えられるのではなくその場で改善され、ドキュメントはプロジェクトの AGENTS.md を Git にコミットすることを推奨している。

ルールは 2 か所に置ける。プロジェクトのルートにある AGENTS.md はそのディレクトリまたはサブディレクトリで作業するときに適用され、グローバルな ~/.config/opencode/AGENTS.md はすべての OpenCode セッションにわたって適用される。後者はコミットも共有もされないため、個人的なルールに推奨されている。Claude Code から移行するユーザーのために、OpenCode は Claude Code の規約にフォールバックする。AGENTS.md がない場合はプロジェクトの CLAUDE.md、OpenCode のグローバルファイルがない場合は ~/.claude/CLAUDE.md、そして ~/.claude/skills/ 以下のスキルであり、これらのフォールバックはそれぞれ環境変数で無効にできる。起動時には、まず現在のディレクトリから上位へたどってローカルのファイルを探し、次にグローバルファイル、次に Claude Code のファイルを探す。各カテゴリで最初に見つかったものが採用されるため、両方がある場合は CLAUDE.md より AGENTS.md が使われる。

追加の指示ファイルは opencode.json の instructions フィールドに列挙でき、glob パターンやリモート URL（5 秒のタイムアウトで取得される）も指定できる。これらはすべて AGENTS.md ファイルと結合される。OpenCode は AGENTS.md 内に書かれたファイル参照を自動的には解析しない。ドキュメントは代わりに instructions フィールドを使うか、参照先のファイルをタスクで必要になったときだけ読み込むようエージェントに伝える明示的な指示を AGENTS.md に書くことを推奨している。モノレポについては、glob パターンによる方法の方が手動の指示より保守しやすいとしている。

アーキテクチャがモデルを固定しないため、同章は 3 つのモデル戦略を説明している。クラウドモデル、プライベートで低コストな推論のためにローカルの推論フレームワークで動かすローカルモデル、そしてタスクをその必要に応じてモデルに振り分けるハイブリッドである。また、OpenCode チームがコーディング向けに検証したモデルのリストである OpenCode Zen も公開していることに触れている。さらに同章は、よくある誤解だとするものを訂正している。OpenCode は「無料のモデルを提供する」わけではなく、そのアーキテクチャによって、コミュニティ製、ローカル、低コスト、または無料のモデルを持ち込み、複数のモデルサービスにまたがって組み合わせられるため、有料の API を持たない開発者でもコーディング作業の大半をこなせる、というのである。

採用とエコシステム

ハンドブックの同章は、Oh My OpenCode を OpenCode を中心に構築されたユーザーレベルの規約層として説明している。その主張は、OpenCode は規約の集まりではなくランタイムであり、大規模なプロジェクトやチームでは、合意された振る舞いやエンジニアリングの道筋がなければエージェントの振る舞いが予測しにくくなる、というものである。Oh My OpenCode は OpenCode を置き換えるものではなく、うまく機能する使い方を標準化するものだとされる。具体的には、Plan エージェントや Build エージェントといったエージェントの役割がどのように協働するかを定義し、より一貫した出力のためにプロンプトの構造と制約を標準化し、組み合わせ可能なワークフローのテンプレートと戦略を提供し、プロジェクトの知識が時間とともに蓄積されるよう AGENTS.md のようなコンテキストファイルの構造を取り決める。同章はこれを、エージェントの利用を移植可能・監査可能にし、チームに適したものにする「開発者規約層」と呼び、その設計の方向性は一度に完璧を目指すのではなく漸進的なものだと述べている。すなわち、現状を見積もり、段階的に探って提案し、制御された変更を行い、フィードバックから次の一歩を調整するというものである。

実際のプロジェクトで OpenCode を使うための同章自身のエンジニアリング上の助言は次のとおりである。エージェントがプロジェクト知識の明確な境界を持てるよう、プロジェクトのルートに AGENTS.md のようなエージェントのコンテキストファイルを定義すること。タスクごとに振り分け、素早い応答や小さな補完は小規模なローカルモデルや軽量なクラウドモデルに、複雑な推論はより強力なモデルに送ること。Plan エージェントは閲覧と提案のみを行い、変更を行うのは Build エージェントだけとし、重要な変更には明示的な確認と記録を必須とする、計画してから実行するパターンを採用すること。そして、コード検索、テストフレームワーク、CI/CD システムなどの外部ツールを MCP または同等の拡張機構を通じて接続し、自動化のループを閉じることである。これらはハンドブックの著者による推奨事項であり、ツールの文書化された挙動ではない。