OpenCode
OpenCode 技術概要 — オープンソースAIターミナルコーディングアシスタントの全容
目次
- はじめに
- アーキテクチャ概要
- インストールとセットアップ
- コア機能
- 対応LLMプロバイダー
- ツールシステム
- セッション管理と会話履歴
- 設定とカスタマイズ
- TUI(ターミナルユーザーインターフェース)設計
- MCPサーバーサポート
- 類似ツールとの比較
- 実践的な使用例とワークフロー
- コントリビューションと開発
- ベストプラクティス
1. はじめに
1.1 OpenCodeとは何か
OpenCodeは、Go言語で構築されたオープンソースのAI駆動ターミナルコーディングアシスタントである。開発者がターミナル環境から直接AIの支援を受けながらコーディング作業を行うことを可能にする、インタラクティブなTUI(Terminal User Interface)アプリケーションだ。
現代のソフトウェア開発において、AIアシスタントの活用は急速に普及している。GitHub Copilot、Cursor、Claude Codeなど、さまざまなAIコーディングツールが登場し、開発者の生産性向上に寄与している。OpenCodeは、これらの商用ツールに対するオープンソースの代替手段として位置づけられ、ターミナルを主な作業環境とする開発者に最適化された体験を提供する。
1.2 プロジェクトの歴史と現状
OpenCodeはopencode-ai組織によって開発が開始された。プロジェクトはGitHub上で公開され、活発なコミュニティの支持を得た。2025年9月18日にリポジトリはアーカイブされ、読み取り専用の状態となった。開発は、オリジナルの開発者とCharmチームによってCrushという新しいプロジェクト名で継続されている。
Charmチームは、Bubble Tea、Lip Gloss、Glamourなど、Go言語によるターミナルUI構築のためのライブラリ群で知られる組織であり、OpenCodeのTUIフレームワークの基盤を提供した実績がある。この移行は、プロジェクトがより大きなエコシステムの一部として発展していくことを示している。
1.3 なぜOpenCodeが重要か
OpenCodeが開発者コミュニティにおいて注目を集める理由は複数ある。
オープンソースの透明性: 商用ツールとは異なり、コードベースが完全に公開されており、セキュリティ監査やカスタマイズが可能である。企業のセキュリティポリシーに合わせた検証や、特定のニーズに合わせた改変が行える。
マルチプロバイダー対応: 単一のAIプロバイダーにロックインされることなく、OpenAI、Anthropic、Google、Groq、AWS Bedrock、Azure OpenAIなど、複数のLLMプロバイダーを切り替えて使用できる。これにより、コスト最適化やモデル特性に応じた使い分けが実現する。
ターミナルネイティブ体験: SSH接続先のリモートサーバーや、GUIを持たないヘッドレス環境でも完全に動作する。DevOps エンジニアやSREなど、ターミナルを主な作業環境とする職種にとって特に有用である。
拡張性: MCP(Model Context Protocol)サーバーサポートやLSP(Language Server Protocol)統合により、既存の開発ツールチェインとシームレスに連携できる。
1.4 本記事の構成
本記事では、OpenCodeの技術的側面を包括的に解説する。アーキテクチャの設計思想から始まり、インストール手順、コア機能の詳細、対応プロバイダー、ツールシステム、設定方法、TUI設計、MCP統合、類似ツールとの比較、実践的なワークフロー、そしてコントリビューション方法まで、約30ページ(A4換算)にわたって詳述する。
読者として、ターミナル環境での開発に馴染みがあり、AIコーディングアシスタントの導入を検討している中級~上級のソフトウェアエンジニアを想定している。
2. アーキテクチャ概要
2.1 技術スタックの全体像
OpenCodeは、Go言語(バージョン1.24.0)を基盤として構築されている。Goを選択した理由は、シングルバイナリへのコンパイル、クロスプラットフォーム対応、高い並行処理性能、そしてCharmチームが提供するTUIライブラリエコシステムの充実にある。
主要な技術スタックは以下の通りである。
+-------------------------------------------+
| OpenCode Application |
+-------------------------------------------+
| TUI Layer (Bubble Tea + Lip Gloss) |
| - チャットビュー |
| - エディタ |
| - セッション管理 |
| - ファイルトラッカー |
+-------------------------------------------+
| Agent Layer |
| - LLMプロバイダー統合 |
| - ツール実行エンジン |
| - コンテキスト管理 |
+-------------------------------------------+
| Tool Layer |
| - ファイル操作 (glob, grep, edit, write) |
| - シェル実行 (bash) |
| - コード解析 (LSP, diagnostics) |
| - 外部連携 (fetch, sourcegraph) |
+-------------------------------------------+
| Storage Layer (SQLite) |
| - セッションデータ |
| - 会話履歴 |
| - マイグレーション (Goose) |
+-------------------------------------------+
| Integration Layer |
| - MCP サーバー |
| - LSP サーバー |
| - 外部エディタ |
+-------------------------------------------+
2.2 Go言語による実装の利点
OpenCodeがGoで実装されていることには、多くの技術的利点がある。
シングルバイナリ配布: Goはクロスコンパイルによって、依存関係のない単一の実行可能ファイルを生成する。これにより、Node.jsやPythonのようなランタイムのインストールが不要となり、配布とデプロイメントが大幅に簡素化される。
並行処理モデル: Goのgoroutineとchannelを活用することで、AIプロバイダーへのAPI呼び出し、ツール実行、TUI描画を効率的に並行処理できる。特にストリーミングレスポンスの処理において、この並行処理モデルが威力を発揮する。
型安全性: 静的型付け言語であるGoは、大規模なコードベースにおけるリファクタリングの安全性を担保する。AIプロバイダーのSDK統合においても、コンパイル時にインターフェースの整合性が検証される。
クロスプラットフォーム: Linux、macOS、Windowsの各環境向けにネイティブバイナリを生成できる。
2.3 主要な依存ライブラリ
OpenCodeのgo.modファイルから、主要な依存関係を分析する。
AI/LLMプロバイダーSDK
| ライブラリ | バージョン | 用途 |
|---|---|---|
anthropic-sdk-go | v1.4.0 | Anthropic Claude API統合 |
openai-go | v0.1.0-beta.2 | OpenAI GPT API統合 |
google.golang.org/genai | v1.3.0 | Google Gemini API統合 |
mcp-go | v0.17.0 | Model Context Protocol統合 |
TUI/CLI フレームワーク
| ライブラリ | バージョン | 用途 |
|---|---|---|
bubbletea | v1.3.5 | TUIフレームワーク |
cobra | v1.9.1 | CLIコマンド管理 |
glamour | - | Markdownレンダリング |
lipgloss | - | ターミナルスタイリング |
インフラストラクチャ
| ライブラリ | バージョン | 用途 |
|---|---|---|
go-sqlite3 | v0.25.0 | SQLiteデータベース |
goose | - | データベースマイグレーション |
chroma/v2 | - | コードシンタックスハイライト |
go-diff / udiff | - | 差分計算・表示 |
doublestar | - | ファイルパターンマッチング |
2.4 内部パッケージ構成
OpenCodeの内部パッケージは、責務に基づいて明確に分離されている。
internal/
├── tui/ # TUIレイヤー
│ ├── components/ # UIコンポーネント
│ ├── layout/ # レイアウト管理
│ ├── page/ # ページ定義
│ ├── styles/ # スタイル定義
│ ├── theme/ # テーマ管理
│ ├── util/ # ユーティリティ
│ └── tui.go # TUIエントリポイント
├── tool/ # ツールシステム
├── agent/ # AIエージェントロジック
├── session/ # セッション管理
├── provider/ # LLMプロバイダー統合
├── config/ # 設定管理
├── db/ # データベースアクセス
└── lsp/ # LSP統合
この構成により、各レイヤーの独立性が保たれ、新しいプロバイダーやツールの追加が容易になっている。
2.5 データフロー
OpenCodeにおける典型的なデータフローを以下に示す。
- ユーザー入力: TUIエディタからユーザーがプロンプトを入力
- コンテキスト構築: セッション履歴、ファイルコンテキスト、システムプロンプトの組み立て
- LLM呼び出し: 選択されたプロバイダーのAPIにリクエストを送信
- ストリーミング受信: レスポンスをストリーミングで受信し、リアルタイムにTUIへ描画
- ツール呼び出し: LLMがツール使用を要求した場合、対応するツールを実行
- 結果フィードバック: ツール実行結果をLLMに返送し、追加の応答を生成
- 永続化: 会話内容をSQLiteデータベースに保存
このサイクルは、LLMがツール呼び出しを要求しなくなるまで繰り返される。これはReAct(Reasoning and Acting)パターンの実装であり、LLMが「考え、行動し、観察する」というループを通じてタスクを遂行する。
3. インストールとセットアップ
3.1 システム要件
OpenCodeを実行するための最小要件は以下の通りである。
- OS: Linux、macOS、またはWindows(WSL推奨)
- ターミナル: 256色以上をサポートするモダンなターミナルエミュレータ
- ネットワーク: LLMプロバイダーへのAPI通信のためのインターネット接続
- API キー: 使用するLLMプロバイダーの有効なAPIキー
なお、ローカルモデル(Ollama経由)を使用する場合、LLMプロバイダーへのインターネット接続は不要だが、モデルのダウンロードに初回のみ接続が必要である。
3.2 インストール方法
OpenCodeは4つの主要なインストール方法を提供している。
シェルスクリプトによるインストール
最も簡単な方法は、公式のインストールスクリプトを使用することである。
curl -fsSL https://raw.githubusercontent.com/opencode-ai/opencode/refs/heads/main/install | bash
このスクリプトは、実行環境のOS・アーキテクチャを自動検出し、適切なバイナリをダウンロード・配置する。特定バージョンをインストールする場合は、環境変数を指定できる。
Homebrew(macOS/Linux)
macOSまたはLinuxでHomebrewを使用している場合は、専用のtapからインストールできる。
brew install opencode-ai/tap/opencode
Homebrewを使用する利点は、brew upgradeによる簡便なアップデート管理である。
AUR(Arch Linux)
Arch Linuxユーザーは、AUR(Arch User Repository)からインストールできる。
# yay を使用する場合
yay -S opencode-ai-bin
# paru を使用する場合
paru -S opencode-ai-bin
Go パッケージマネージャ
Go開発環境が既にセットアップされている場合は、go installで直接インストールできる。
go install github.com/opencode-ai/opencode@latest
この方法では、ソースコードからコンパイルされるため、$GOPATH/binにバイナリが配置される。
3.3 初期設定
APIキーの設定
OpenCodeを使用するには、少なくとも1つのLLMプロバイダーのAPIキーが必要である。環境変数として設定する方法が最も一般的だ。
# Anthropic Claude を使用する場合
export ANTHROPIC_API_KEY="sk-ant-api03-..."
# OpenAI GPT を使用する場合
export OPENAI_API_KEY="sk-..."
# Google Gemini を使用する場合
export GEMINI_API_KEY="AIza..."
# Groq を使用する場合
export GROQ_API_KEY="gsk_..."
これらの環境変数は、シェルの設定ファイル(.bashrc、.zshrc等)に追記することで永続化できる。
設定ファイルの作成
OpenCodeは設定ファイルを以下の優先順位で検索する。
./.opencode.json— プロジェクトローカル設定(最優先)$XDG_CONFIG_HOME/opencode/.opencode.json— ユーザー設定$HOME/.opencode.json— ホームディレクトリ設定
基本的な設定ファイルの例を示す。
{
"providers": {
"anthropic": {
"apiKey": "env:ANTHROPIC_API_KEY",
"enabled": true
},
"openai": {
"apiKey": "env:OPENAI_API_KEY",
"enabled": true
}
},
"agents": {
"coder": {
"model": "claude-sonnet-4-20250514",
"maxTokens": 16000
},
"task": {
"model": "gpt-4.1-mini",
"maxTokens": 8000
}
},
"shell": {
"path": "/bin/zsh",
"args": ["-l"]
}
}
3.4 初回起動と動作確認
インストールとAPIキーの設定が完了したら、以下のコマンドでOpenCodeを起動する。
opencode
正常に起動すると、Bubble Teaベースのインタラクティブなターミナルインターフェースが表示される。チャット画面にカーソルが配置され、AIとの対話を開始できる。
動作確認として、以下のような簡単なプロンプトを試すとよい。
Hello, can you tell me what programming language you think is best for web development?
レスポンスが正常に表示されれば、セットアップは完了である。
3.5 デバッグモード
問題が発生した場合は、デバッグモードで起動することで詳細なログを確認できる。
opencode -d
デバッグモードでは、API通信の詳細、ツール実行のログ、内部状態の変遷がログファイルに記録される。ログはTUI内の専用画面(Ctrl+L)で確認可能である。
4. コア機能
4.1 AIチャット
OpenCodeの中核機能は、ターミナル内でのAIチャットである。ユーザーはテキストプロンプトを入力し、選択されたLLMモデルからのレスポンスをリアルタイムのストリーミングで受信する。
チャット機能の特徴は以下の通りである。
ストリーミングレスポンス: LLMからの応答は、トークン単位でリアルタイムに表示される。長い応答を待つ必要がなく、生成されるテキストの方向性を早期に確認できる。
Markdownレンダリング: Glamourライブラリによって、AIの応答はMarkdown形式で整形表示される。コードブロックはシンタックスハイライト付きで表示され、表やリストも適切にフォーマットされる。
コンテキスト認識: 同一セッション内の過去の会話が自動的にコンテキストとして含められる。これにより、一連の開発作業を通じた継続的な対話が可能になる。
モデル切り替え: Ctrl+Oショートカットで、セッション中にLLMモデルを動的に切り替えることができる。たとえば、簡単な質問にはGPT-4o-miniを使い、複雑なアーキテクチャ設計にはClaude Opusを使うといった使い分けが可能だ。
4.2 コード編集
OpenCodeは、AIによるコード編集を強力にサポートする。ファイルの読み取り、編集、新規作成を、自然言語の指示に基づいて実行できる。
ファイル閲覧(view): 指定されたファイルの内容を読み取り、AIのコンテキストに含める。行番号範囲の指定による部分的な閲覧も可能である。
ファイル編集(edit / patch): 既存ファイルの特定箇所を修正する。差分(diff)形式で変更内容が表示され、ユーザーに確認を求める。
ファイル書き込み(write): 新しいファイルを作成する。AIが生成したコードを指定されたパスに書き込む。
パッチ適用(patch): より複雑な変更に対して、パッチ形式での編集が可能。複数箇所の変更を一度に適用できる。
4.3 ファイル管理
ファイル管理機能により、プロジェクトのファイル構造を効率的に把握・操作できる。
グロブ検索(glob): ワイルドカードパターンを使用してファイルを検索する。doublestarライブラリにより、**/*.goのような再帰的パターンもサポートされる。
テキスト検索(grep): ファイル内容のテキスト検索を実行する。正規表現パターンによる高度な検索が可能である。
ディレクトリ一覧(ls): ディレクトリ構造を表示し、プロジェクトの全体像を把握する。
ファイル変更追跡: セッション中に変更されたファイルを追跡し、視覚化する。これにより、AIとの対話で行われた変更の全体像を確認できる。
4.4 ターミナルコマンド実行
OpenCodeは、ターミナルコマンド(bashツール)の実行機能を備えている。AIが必要と判断した場合、シェルコマンドを実行し、その結果をコンテキストに取り込む。
ユーザー: このプロジェクトのテストを実行して、失敗しているテストがあれば修正してください。
AI: まず、テストを実行して状況を確認します。
[bash] go test ./...
この機能は、以下のようなシナリオで特に有用である。
- ビルドとテストの実行
- gitコマンドによるバージョン管理操作
- パッケージのインストールと依存関係の管理
- システム情報の収集
- スクリプトの実行
シェルの設定(パスと引数)は設定ファイルでカスタマイズ可能であり、zsh、bash、fishなど、ユーザーの好みのシェルを使用できる。
4.5 Vim風エディタ
OpenCodeには、Vim風のキーバインドを持つ内蔵テキストエディタが搭載されている。プロンプトの入力時にVimのモーダル編集が利用可能で、効率的なテキスト入力ができる。
さらに、Ctrl+Eショートカットにより、システムの外部エディタ($EDITOR環境変数で指定)を起動して、より複雑なプロンプトの編集が可能である。これにより、長いプロンプトや複雑な指示を、使い慣れたエディタで作成してからOpenCodeに送信できる。
4.6 URL取得
fetchツールにより、外部URLのコンテンツを取得してAIのコンテキストに含めることができる。ドキュメントの参照、APIレスポンスの確認、Webページの内容に基づいた作業指示など、多様な用途に対応する。
4.7 エージェントツール
agentツールは、複雑なタスクをサブタスクに委任するための機能である。メインのAIエージェントが、特定の調査や操作を別のエージェントインスタンスに委任し、結果を統合する。これにより、大規模なタスクを効率的に処理できる。
4.8 非インタラクティブモード
OpenCodeは、TUIを使用しない非インタラクティブモードも提供している。スクリプトやCI/CDパイプラインとの統合に適している。
# 単発のプロンプト実行
opencode -p "Explain the architecture of this project"
# JSON形式での出力
opencode -p "List all TODO comments in the codebase" -f json
# サイレントモード(スピナー非表示)
opencode -p "Fix the linting errors in main.go" -q
5. 対応LLMプロバイダー
5.1 プロバイダー一覧
OpenCodeは、業界で主要なLLMプロバイダーを幅広くサポートしている。これにより、ユーザーは用途やコストに応じて最適なモデルを選択できる。
Anthropic
Anthropicは、Claude シリーズのモデルを提供するプロバイダーである。OpenCodeでは以下のモデルがサポートされている。
| モデル | 特徴 | 推奨用途 |
|---|---|---|
| Claude 4 Opus | 最高性能、深い推論能力 | 複雑なアーキテクチャ設計、困難なバグ修正 |
| Claude 4 Sonnet | 高性能と速度のバランス | 日常的なコーディング作業全般 |
| Claude 3.7 Sonnet | 拡張思考対応 | 段階的な推論が必要なタスク |
| Claude 3.5 Sonnet | コスト効率の高い高性能モデル | 一般的なコーディング支援 |
| Claude 3 Haiku | 高速・低コスト | 簡単な質問、軽量タスク |
OpenAI
| モデル | 特徴 | 推奨用途 |
|---|---|---|
| GPT-4.1 | 最新フラッグシップ | 高品質なコード生成 |
| GPT-4.1 Mini | コスト効率版 | 日常的な開発タスク |
| GPT-4.1 Nano | 超高速・低コスト | 簡単な補完、フォーマット |
| GPT-4.5 Preview | 次世代プレビュー | 実験的な使用 |
| GPT-4o | マルチモーダル対応 | 画像を含むタスク |
| O1 / O3 シリーズ | 高度な推論能力 | 数学的推論、複雑なロジック |
| モデル | 特徴 | 推奨用途 |
|---|---|---|
| Gemini 2.5 Pro | 最新大規模モデル | 大規模コードベースの分析 |
| Gemini 2.5 Flash | 高速版 | レスポンス重視のタスク |
| Gemini 2.0 Flash | 前世代高速版 | 一般的な開発支援 |
GitHub Copilot
OpenCodeはGitHub Copilot経由でのモデル利用もサポートしている。GitHubの認証トークンを使用してアクセスし、Copilotのサブスクリプションに含まれるモデルを利用できる。
| モデル | プロバイダー |
|---|---|
| GPT-3.5 Turbo | OpenAI |
| GPT-4 / GPT-4o | OpenAI |
| Claude 3.5/3.7 Sonnet | Anthropic |
| O1 / O3 / O4 Mini | OpenAI |
| Gemini 2.5 Pro |
AWS Bedrock
Amazon Web Servicesの Bedrock サービスを通じて、以下のモデルにアクセスできる。
- Claude 3.7 Sonnet
AWSの認証情報(AWS_ACCESS_KEY_ID、AWS_SECRET_ACCESS_KEY、AWS_REGION)を使用して認証する。
Groq
高速推論プラットフォームGroqを通じて、オープンソースモデルを高速に利用できる。
| モデル | 特徴 |
|---|---|
| Llama 4 Maverick / Scout | Meta の最新モデル |
| QWEN QWQ-32b | 中国製高性能モデル |
| Deepseek R1 Distill | 推論特化モデル |
Azure OpenAI
Azure経由でOpenAIモデルにアクセスする。企業環境でのコンプライアンス要件を満たすために利用されることが多い。
OpenRouter
OpenRouterは、複数のAIプロバイダーへの統一アクセスを提供するプロキシサービスである。OpenCode上でOpenRouterを設定することで、単一のAPIキーで多数のモデルにアクセスできる。
5.2 プロバイダーの設定方法
各プロバイダーの設定は、設定ファイルのprovidersセクションで行う。
{
"providers": {
"anthropic": {
"apiKey": "env:ANTHROPIC_API_KEY",
"enabled": true
},
"openai": {
"apiKey": "env:OPENAI_API_KEY",
"enabled": true
},
"google": {
"apiKey": "env:GEMINI_API_KEY",
"enabled": true
},
"groq": {
"apiKey": "env:GROQ_API_KEY",
"enabled": true
},
"bedrock": {
"enabled": true
},
"azure": {
"apiKey": "env:AZURE_OPENAI_API_KEY",
"enabled": true
},
"copilot": {
"enabled": true
}
}
}
"env:VARIABLE_NAME"構文を使用すると、APIキーを環境変数から安全に読み込むことができる。これにより、設定ファイルに平文のAPIキーを記述する必要がなくなり、セキュリティが向上する。
5.3 エージェント設定とモデル選択
OpenCodeでは、異なるタスクタイプに対して異なるモデルを割り当てることができる。agents設定セクションで、各エージェントタイプに使用するモデルとパラメータを指定する。
{
"agents": {
"coder": {
"model": "claude-sonnet-4-20250514",
"maxTokens": 16000
},
"task": {
"model": "gpt-4.1-mini",
"maxTokens": 8000
}
}
}
- coder: メインのコーディングアシスタントとして使用されるモデル。コード生成、編集、レビューなどの主要タスクを担当する。
- task: サブタスクの実行に使用される軽量モデル。
agentツールを通じて委任されるタスクに使用される。
この分離により、コスト効率の最適化が可能になる。重要な作業には高性能モデルを使用し、補助的なタスクにはコスト効率の良いモデルを割り当てることで、API費用を抑制できる。
6. ツールシステム
6.1 ツールシステムの概要
OpenCodeのツールシステムは、AIアシスタントが開発環境と直接やりとりするための仕組みである。LLMが自然言語による推論を行い、必要に応じてツールを呼び出すことで、コードの読み書き、コマンド実行、ファイル検索といった実際のアクションを実行する。
このツールシステムは、いわゆる「Function Calling」パターンに基づいている。LLMプロバイダーのAPIが返すツール呼び出しリクエストをOpenCodeが解釈し、対応するツール実装を実行する。結果はLLMにフィードバックされ、次のアクションの判断に使用される。
6.2 ファイル操作ツール
glob — ファイルパターン検索
globツールは、ワイルドカードパターンを使用してファイルシステム内のファイルを検索する。プロジェクト内の特定の種類のファイルを見つけるために使用される。
パターン例:
- **/*.go — すべてのGoファイル
- src/**/*.ts — src配下のすべてのTypeScriptファイル
- *.md — カレントディレクトリのMarkdownファイル
- **/test_*.py — すべてのPythonテストファイル
doublestarライブラリを使用しているため、標準のglob構文に加えて**による再帰的なディレクトリマッチングがサポートされている。
grep — テキスト検索
grepツールは、ファイル内容のテキスト検索を実行する。正規表現パターンによる高度な検索が可能であり、コードベース内の特定のパターンや定義を素早く発見するのに役立つ。
ls — ディレクトリ一覧
lsツールは、ディレクトリの内容を一覧表示する。プロジェクト構造の把握や、特定のディレクトリ内のファイルの確認に使用される。
view — ファイル閲覧
viewツールは、指定されたファイルの内容を読み取る。行番号の範囲を指定して部分的に読み取ることも可能であり、大きなファイルの特定の部分だけを効率的に確認できる。
write — ファイル書き込み
writeツールは、新しいファイルを作成するか、既存のファイルの内容を完全に置き換える。AIが生成したコードや設定ファイルをディスクに書き込むために使用される。
edit — ファイル編集
editツールは、既存ファイルの特定の部分を修正する。差分ベースの編集アプローチを採用しており、変更前後の内容が明確に示される。go-diffおよびudiffライブラリが差分の計算と表示に使用されている。
patch — パッチ適用
patchツールは、より複雑な編集操作を実行するためのツールである。複数のファイルにまたがる変更や、一つのファイル内の複数箇所の変更を効率的に適用できる。
6.3 システム統合ツール
bash — コマンド実行
bashツールは、シェルコマンドを実行し、その出力を取得する。OpenCodeのツールシステムの中でも最も強力で汎用的なツールの一つである。
設定ファイルのshellセクションで、使用するシェルとその引数を指定できる。
{
"shell": {
"path": "/bin/zsh",
"args": ["-l"]
}
}
セキュリティ上の注意として、bashツールはシステム上で任意のコマンドを実行できるため、信頼できるLLMモデルのみで使用すべきである。
fetch — URL取得
fetchツールは、指定されたURLからコンテンツを取得する。ドキュメントの参照、API仕様の確認、外部リソースの内容取得などに使用される。
6.4 コードインテリジェンスツール
diagnostics — コード診断
diagnosticsツールは、LSP(Language Server Protocol)統合を通じてコード診断情報を取得する。コンパイルエラー、警告、lint結果などの情報をAIのコンテキストに含めることで、問題の特定と修正を支援する。
Sourcegraph コード検索
Sourcegraphとの統合により、大規模なコードベースやモノレポ環境での高度なコード検索が可能になる。関数定義、参照、実装パターンの検索に特に有用である。
6.5 高度なツール
agent — サブタスク委任
agentツールは、メインのAIエージェントから独立したサブエージェントにタスクを委任する機能を提供する。これにより、以下のようなワークフローが実現する。
- メインエージェントが複雑なタスクを分析
- サブタスクを特定し、
agentツールを呼び出し - サブエージェントが独立したコンテキストでタスクを実行
- 結果がメインエージェントに返却され、統合される
taskエージェントには、メインのcoderエージェントとは異なるモデルを設定できるため、コスト効率の最適化が可能である。
6.6 ツールの実行フロー
ツールの実行フローは以下のようになる。
1. LLM がツール呼び出しリクエストを生成
↓
2. OpenCode がリクエストを解析し、対応するツールを特定
↓
3. ツールのパラメータをバリデーション
↓
4. ツールを実行(ファイル操作、コマンド実行等)
↓
5. 実行結果を構造化されたレスポンスとして返却
↓
6. レスポンスをLLMのコンテキストに追加
↓
7. LLM が結果を分析し、次のアクションを決定
↓
8. 必要に応じて 1 に戻る
このループは、タスクが完了するかユーザーが介入するまで継続される。
7. セッション管理と会話履歴
7.1 セッションの概念
OpenCodeにおける「セッション」は、一連の対話をグループ化する単位である。各セッションは独立したコンテキストを持ち、会話履歴、使用されたファイル、実行されたコマンドなどの情報を保持する。
セッション管理は、長期にわたる開発プロジェクトにおいて特に重要である。機能開発、バグ修正、リファクタリングなど、異なるタスクごとにセッションを分けることで、コンテキストの混乱を防ぎ、必要な時に過去の対話を参照できる。
7.2 SQLiteによるデータ永続化
OpenCodeは、SQLiteデータベースを使用してセッションデータと会話履歴を永続化する。SQLiteを選択した理由は以下の通りである。
- サーバーレス: 別途データベースサーバーを起動する必要がない
- シングルファイル: データベース全体が単一のファイルに格納される
- トランザクション対応: ACIDトランザクションによるデータの整合性保証
- 高速読み取り: 会話履歴の読み取りが高速
- 移植性: データベースファイルを他のマシンにコピーして移行可能
データベースのマイグレーションにはGooseライブラリが使用されており、スキーマの変更がバージョン管理されている。
7.3 セッションの操作
新規セッション作成
Ctrl+Nショートカットで新しいセッションを作成できる。新規セッションは空のコンテキストで開始され、以前のセッションとは独立している。
セッション切り替え
Ctrl+Aショートカットでセッション一覧ダイアログが表示され、過去のセッションに切り替えることができる。
セッション内の操作
セッション内では、以下の操作が可能である。
- メッセージの送信と応答の受信
- ファイルの閲覧・編集・作成(ツール経由)
- コマンドの実行(ツール経由)
- モデルの切り替え
7.4 自動コンパクト機能
OpenCodeの自動コンパクト(Auto Compact)機能は、コンテキストウィンドウの管理において重要な役割を果たす。
動作原理:
- 会話のトークン使用量を継続的に監視
- 使用量がモデルのコンテキストウィンドウの95%に達すると、自動コンパクトがトリガーされる
- これまでの会話内容が要約され、重要な情報が抽出される
- 要約を含む新しいセッションが自動的に作成される
- ユーザーは新しいセッションで作業を継続できる
{
"autoCompact": true
}
7.5 ファイル変更追跡
セッション中に行われたファイルの変更は自動的に追跡される。変更追跡は以下の情報を記録する。
- 変更されたファイルのパス
- 変更の種類(作成、編集、削除)
- 変更のタイムスタンプ
- 変更を要求したプロンプト
8. 設定とカスタマイズ
8.1 設定ファイルの形式
OpenCodeの設定ファイルはJSON形式で記述される。設定ファイルは以下の優先順位で検索される。
./.opencode.json— プロジェクトレベルの設定(最優先)$XDG_CONFIG_HOME/opencode/.opencode.json— ユーザーレベルの設定$HOME/.opencode.json— グローバル設定
8.2 設定項目の詳細
プロバイダー設定
{
"providers": {
"anthropic": {
"apiKey": "env:ANTHROPIC_API_KEY",
"enabled": true
},
"openai": {
"apiKey": "env:OPENAI_API_KEY",
"enabled": false
}
}
}
エージェント設定
{
"agents": {
"coder": {
"model": "claude-sonnet-4-20250514",
"maxTokens": 16000
},
"task": {
"model": "gpt-4.1-mini",
"maxTokens": 8000
}
}
}
シェル設定
{
"shell": {
"path": "/bin/zsh",
"args": ["-l"]
}
}
MCP サーバー設定
{
"mcpServers": {
"memory": {
"type": "stdio",
"command": "npx",
"args": ["@modelcontextprotocol/server-memory"],
"env": {}
},
"filesystem": {
"type": "stdio",
"command": "npx",
"args": ["@modelcontextprotocol/server-filesystem", "/path/to/directory"],
"env": {}
}
}
}
LSP 設定
{
"lsp": {
"go": {
"command": "gopls",
"args": ["serve"],
"enabled": true
},
"typescript": {
"command": "typescript-language-server",
"args": ["--stdio"],
"enabled": true
}
}
}
8.3 環境変数
| 環境変数 | 説明 |
|---|---|
ANTHROPIC_API_KEY | Anthropic API キー |
OPENAI_API_KEY | OpenAI API キー |
GEMINI_API_KEY | Google Gemini API キー |
GROQ_API_KEY | Groq API キー |
GITHUB_TOKEN | GitHub Copilot トークン |
AWS_ACCESS_KEY_ID | AWS アクセスキー |
AWS_SECRET_ACCESS_KEY | AWS シークレットキー |
AWS_REGION | AWS リージョン |
AZURE_OPENAI_API_KEY | Azure OpenAI API キー |
EDITOR | 外部エディタのパス |
8.4 カスタムコマンド
ユーザーレベルのコマンド
~/.config/opencode/commands/ディレクトリにMarkdownファイルを配置する。
<!-- ~/.config/opencode/commands/review.md -->
Please review the following code for:
1. Security vulnerabilities
2. Performance issues
3. Code style violations
4. Potential bugs
Focus on file: $FILE
このコマンドは、user:reviewとして呼び出すことができる。
プロジェクトレベルのコマンド
<PROJECT>/.opencode/commands/ディレクトリにMarkdownファイルを配置する。project:deploy-checkのように呼び出す。
カスタムコマンドは、Ctrl+Kショートカットで表示されるコマンドパレットからアクセスできる。
9. TUI(ターミナルユーザーインターフェース)設計
9.1 Bubble Teaフレームワーク
OpenCodeのTUIは、CharmチームのBubble Teaフレームワーク上に構築されている。Bubble Teaは、Elm Architecture(The Elm Architecture, TEA)に基づくGo言語向けのTUIフレームワークである。
Elm Architectureの基本概念は以下の3要素から構成される。
- Model: アプリケーションの状態を表現するデータ構造
- Update: メッセージに基づいて状態を更新する関数
- View: 現在の状態をターミナル出力に変換する関数
// Bubble Tea の基本パターン
type model struct {
messages []Message
input textinput.Model
}
func (m model) Update(msg tea.Msg) (tea.Model, tea.Cmd) {
switch msg := msg.(type) {
case tea.KeyMsg:
// キー入力の処理
case StreamMsg:
// ストリーミングレスポンスの処理
}
return m, nil
}
func (m model) View() string {
return renderChat(m.messages) + renderEditor(m.input)
}
9.2 UI コンポーネント構成
+---------------------------------------------------+
| ヘッダー: モデル名 / セッション情報 |
+---------------------------------------------------+
| |
| チャットビュー |
| - ユーザーメッセージ |
| - AI レスポンス(Markdown レンダリング) |
| - ツール呼び出し結果 |
| - ファイル変更通知 |
| |
+---------------------------------------------------+
| エディタ(Vim風キーバインド) |
| > プロンプト入力エリア |
+---------------------------------------------------+
| ステータスバー: キーバインド / トークン使用量 |
+---------------------------------------------------+
9.3 Lip Glossによるスタイリング
Lip Glossは、ターミナルにおけるCSSのようなスタイリングシステムを提供するライブラリである。
var messageStyle = lipgloss.NewStyle().
Foreground(lipgloss.Color("#FFFFFF")).
Background(lipgloss.Color("#333333")).
Padding(1, 2).
MarginBottom(1)
9.4 キーバインド
グローバルキーバインド
| キー | 機能 |
|---|---|
Ctrl+C | アプリケーション終了 |
Ctrl+? | ヘルプ表示 |
Ctrl+L | ログビュー |
Ctrl+A | セッション切り替え |
Ctrl+K | コマンドパレット |
Ctrl+O | モデル選択 |
チャットキーバインド
| キー | 機能 |
|---|---|
Ctrl+N | 新規セッション |
Ctrl+X | 生成キャンセル |
i | エディタにフォーカス |
エディタキーバインド
| キー | 機能 |
|---|---|
Ctrl+S | プロンプト送信 |
Ctrl+E | 外部エディタ起動 |
10. MCPサーバーサポート
10.1 MCPとは
MCP(Model Context Protocol)は、AIモデルが外部のツールやデータソースと標準化された方法で通信するためのプロトコルである。Anthropicが主導して策定したこの規格は、AIアシスタントの拡張性を大幅に向上させる。
MCPの基本概念は以下の通りである。
- ホスト: AIアシスタント(この場合はOpenCode)
- サーバー: ツールやデータを提供する外部プロセス
- ツール: サーバーが公開する操作可能な機能
- リソース: サーバーが提供するデータソース
- プロンプト: サーバーが提供するプロンプトテンプレート
10.2 OpenCodeにおけるMCP統合
OpenCodeは、mcp-goライブラリ(v0.17.0)を使用してMCPクライアント機能を実装している。
stdio接続
{
"mcpServers": {
"memory": {
"type": "stdio",
"command": "npx",
"args": ["@modelcontextprotocol/server-memory"],
"env": {}
}
}
}
SSE接続
Server-Sent Events(SSE)を通じたHTTPベースの通信。リモートのMCPサーバーに接続する際に使用される。
10.3 主要なMCPサーバー例
- Memory サーバー: AIの長期記憶を実現
- Filesystem サーバー: ファイルシステムアクセスを提供
- GitHub サーバー: Issue、Pull Request、リポジトリ情報にアクセス
- データベースサーバー: スキーマの閲覧やクエリの実行
10.4 MCPの利点と活用シナリオ
- 社内ツール統合: デプロイメントシステム、モニタリングツール、チケット管理システムとの連携
- クラウドサービス操作: AWS、GCP、Azureなどのクラウドリソースの管理
- データベース操作: スキーマの確認、クエリの実行、マイグレーションの管理
- ドキュメント参照: 社内ドキュメントやナレッジベースの検索
- CI/CD統合: ビルドパイプラインの状態確認、デプロイメント操作
11. 類似ツールとの比較
11.1 Claude Code
| 項目 | OpenCode | Claude Code |
|---|---|---|
| 開発元 | オープンソースコミュニティ | Anthropic |
| ライセンス | オープンソース | プロプライエタリ |
| 対応LLM | 複数プロバイダー | Claude のみ |
| 実装言語 | Go | TypeScript/Node.js |
| TUI | Bubble Tea ベース | 独自実装 |
| MCP対応 | あり | あり |
11.2 Aider
| 項目 | OpenCode | Aider |
|---|---|---|
| 実装言語 | Go | Python |
| 対応LLM | 複数プロバイダー | 複数プロバイダー |
| インターフェース | TUI(Bubble Tea) | CLI(readline) |
| Git統合 | 基本的なコマンド実行 | 深い統合(自動コミット) |
| MCP対応 | あり | なし |
| リポジトリマップ | なし | あり(tree-sitter) |
11.3 Cursor
| 項目 | OpenCode | Cursor |
|---|---|---|
| 種類 | ターミナルツール | GUI エディタ |
| ベース | 独自TUI | VS Code フォーク |
| 料金 | 無料(API費用のみ) | 月額サブスクリプション |
| リモート利用 | SSH で完全動作 | リモート接続必要 |
11.4 Codex CLI (OpenAI)
| 項目 | OpenCode | Codex CLI |
|---|---|---|
| 対応LLM | 複数プロバイダー | OpenAI のみ |
| 実装言語 | Go | TypeScript/Node.js |
| MCP対応 | あり | 限定的 |
| サンドボックス | なし | あり |
11.5 比較まとめ
- プロバイダーの柔軟性が重要: OpenCode
- Anthropicエコシステムに集中: Claude Code
- Git統合の深さが重要: Aider
- GUI エディタが好み: Cursor
- OpenAIモデル中心: Codex CLI
12. 実践的な使用例とワークフロー
12.1 新規プロジェクトのセットアップ
ユーザー: Go言語でRESTful APIサーバーを作成したい。
AI: プロジェクト構成を作成します。
[bash] mkdir -p myapi/{cmd/server,internal/{handler,model,repository},migrations}
[write] go.mod, main.go, handler, model, repository を作成
[write] docker-compose.yml, Dockerfile を作成
12.2 バグの調査と修正
ユーザー: APIのレスポンスタイムが遅い。原因を調査して修正してほしい。
AI: [grep] エンドポイントの実装を検索
[view] handler, repository を閲覧
問題を特定: N+1クエリが発生
[edit] JOINを使用したクエリに修正
[bash] go test ./internal/repository/... -v
12.3 コードレビュー支援
ユーザー: 最新のコミットのコードレビューをしてください。
AI: [bash] git diff HEAD~1
[view] 変更されたファイルを閲覧
セキュリティ問題とパフォーマンス問題を報告
[edit] 修正を提案・実装
12.4 CI/CDパイプラインでの活用
# コードの自動レビュー
opencode -p "Review the changes in this PR for security issues" -f json -q
# テスト失敗の自動分析
opencode -p "Analyze why the tests are failing: $(go test ./... 2>&1)" -q
# CHANGELOG の自動生成
opencode -p "Generate a CHANGELOG entry based on recent commits" -q
13. コントリビューションと開発
13.1 プロジェクト構造
opencode/
├── cmd/ # メインのエントリポイント
│ └── opencode/ # CLIアプリケーション
├── internal/ # 内部パッケージ
│ ├── agent/ # AIエージェントロジック
│ ├── config/ # 設定管理
│ ├── db/ # データベースアクセス
│ ├── lsp/ # LSP統合
│ ├── provider/ # LLMプロバイダー
│ ├── session/ # セッション管理
│ ├── tool/ # ツールシステム
│ └── tui/ # TUIレイヤー
├── go.mod # Go モジュール定義
├── go.sum # 依存関係チェックサム
├── install # インストールスクリプト
├── LICENSE # ライセンスファイル
└── README.md # プロジェクト説明
13.2 開発環境のセットアップ
git clone https://github.com/opencode-ai/opencode.git
cd opencode
go mod download
go build -o opencode ./cmd/opencode
go test ./...
13.3 コントリビューションガイドライン
- Issue の作成: バグ報告や機能提案は、まずIssueとして作成する
- フォークとブランチ: リポジトリをフォークし、機能ブランチを作成する
- コードスタイル: Go の標準コードスタイル(
gofmt、golint)に従う - テスト: 新機能にはテストを追加する
- Pull Request: 変更内容を明確に説明したPRを作成する
13.4 Crushプロジェクトへの移行
OpenCodeの開発はCrushプロジェクトとして継続されている。新しいコントリビューションは、Crushプロジェクトに対して行うことが推奨される。
14. ベストプラクティス
14.1 効率的なプロンプト設計
悪い例: このコードを良くして
良い例: internal/handler/user.go の CreateUser 関数のエラーハンドリングを
改善してください。データベースエラーは500、バリデーションエラーは400を
返すようにし、エラーメッセージはJSON形式で返してください。
14.2 セッション管理のベストプラクティス
- タスクごとにセッションを分ける
- セッション名を分かりやすくする
- 自動コンパクトを有効にする
- 定期的に新しいセッションを開始する
14.3 セキュリティのベストプラクティス
- APIキーは環境変数で管理する
env:構文を使用する.opencode.jsonのgitignore- bashツールの実行内容を確認する
14.4 コスト最適化
- タスクに応じたモデル選択
- エージェント分離を活用する
- 不要なコンテキストを避ける
- 非インタラクティブモードの活用
- ローカルモデルの検討
14.5 トラブルシューティング
- 接続エラー: APIキーの確認、
opencode -dでデバッグログを確認 - レスポンスが遅い: モデルの切り替え、ネットワーク接続の確認
- ツール実行エラー: シェルパスの確認、権限の確認
- TUI表示の乱れ: ターミナルサイズの調整、256色サポートの確認
15. まとめ
15.1 OpenCodeの価値
- オープンソースの透明性: コードベースの完全な公開による信頼性とカスタマイズ性
- マルチプロバイダー対応: ベンダーロックインの回避と柔軟なモデル選択
- ターミナルネイティブ体験: リモート環境やヘッドレス環境での完全動作
- 拡張性: MCP/LSP統合による既存ツールチェインとのシームレスな連携
- 効率的な設計: Go言語によるシングルバイナリ配布と高い並行処理性能
15.2 今後の展望
OpenCodeの開発はCrushプロジェクトとして継続されており、Charmチームのエコシステムとの統合がさらに進むことが期待される。ターミナルベースのAIアシスタントは、DevOps、SRE、バックエンド開発など、ターミナルを主な作業環境とする多くの開発者にとって不可欠なツールとなりつつある。
15.3 参考リソース
- OpenCode GitHub リポジトリ(アーカイブ): https://github.com/opencode-ai/opencode
- Charm チーム: https://charm.sh/
- Bubble Tea: https://github.com/charmbracelet/bubbletea
- MCP 仕様: https://modelcontextprotocol.io/
- Crush プロジェクト: Charmチームの最新リリースを確認
本記事は2026年4月時点の情報に基づいて記述されています。OpenCodeリポジトリは2025年9月にアーカイブされ、開発はCrushプロジェクトとして継続されています。最新の情報については、Crushプロジェクトの公式リソースをご参照ください。