Oh My Opencode QuickStart for OpenCode:インストール、設定、実行

Oh My Opencode をインストールして、より高速にリリースしましょう。

目次

Oh My Opencode は、OpenCode をマルチエージェントコーディングハネスへと変えます。オーケストレーターは、並行して実行される専門エージェントに作業を委任します。

oh my opencode agents with laptops and gpu

必要となる最短のメンタルモデル:プラグインをインストールし、フルパワーのマルチエージェント実行が必要な時にキーワード ultrawork(または ulw)を使用する。

このクイックスタートでは、インストールと初日の設定をカバーします。準備が整ったら、以下を参照してください:

より広範な AI コーディングツールチェーンについては、AI 開発者ツール概要 を参照してください。OpenCode の代わりに、サンドボックス化されブラウザ対応の代替案を好む場合は、OpenHands が、エージェント型コーディングに対して異なるアーキテクチャのアプローチを採用しています。

Oh My Opencode が存在する理由

OpenCode は、ターミナル UI として動作し、スクリプティングや自動化のための非対話型 CLI 実行を処理するオープンソースの AI コーディングエージェントです。

Oh My Opencode はその限界をさらに押し上げます。これは「Sisyphus」エージェントを中心に構築された完全なオーケストレーション層、複数の専門家の協力、そして tighter なツール統合を追加します。その結果、通常なら複数のプロンプトを監視する必要があるような複雑なエンジニアリングタスクが、単一のワークフローで計画、委任、検証されるシステムが生まれます。

以下の 2 つの概念は頻繁に登場するため、他の何よりも先に押さえておいてください:

  • Ultrawork モード:キーワードでトリガーされるワークフロー切り替え。プロンプトに ultrawork または ulw を追加することで、並列背景実行、LSP 統合、コンテキスト管理、自動タスク分解が有効になります。単なるスタイル選択ではありません。
  • 専門エージェント:アーキテクチャ用の @oracle や、調査・ドキュメント用の @librarian などの名前付きロールです。明示的に呼び出すことも、オーケストレーターが自動的にルーティングさせることもできます。

この記事では、Oh My Opencodeoh-my-opencodeOh My OpenCode を互換に使用していますが、これらはすべて OpenCode エコシステム内の同じプラグインを指します。

前提条件と用語

まず、OpenCode のインストールと動作確認が必要です。インストール、設定、起動方法については、当社の OpenCode クイックスタート を参照してください。

デフォルトでは、引数なしで実行すると opencode がターミナル UI を起動し、非対話型実行には opencode run ... も使用できます。

Oh My Opencode には、少なくとも 1 つのプロバイダーの設定が必要です。OpenCode は、認証情報、環境変数、またはプロジェクトの .env からプロバイダーを読み込みます。それを整える最速の方法は以下の通りです:

opencode auth login
opencode auth list

認証情報は ~/.local/share/opencode/auth.json に保存されます。

事前に知っておくべき命名の癖があります:アップストリームの GitHub リポジトリは現在 oh-my-openagent(以前は oh-my-opencode)としてブランドされていますが、設定内のプラグインおよびパッケージ名は依然として oh-my-opencode です。コミュニティの投稿では両方の名前が飛び交っていますが、同じものです。

インストールのクイックスタート

複数のルート(CLI インストーラー、マニュアルリポジトリのクローン、または「エージェントにインストールさせる」)があります。 正しい選択は、再現可能なインストーラーフローを望むか、完全な手動制御を望むかによって異なります。

Bun がインストールされている場合、bunx は Bun の npx に相当するもので、個別のグローバルインストールステップなしに npm パッケージを素早く実行するように設計されています。

Linux への bunx のインストールについては こちら を参照してください:

curl -fsSL https://bun.com/install | bash

OpenCode を使用した自動インストール

OpenCode でプロンプトを実行することで、OmO が自動的にインストールされます。

  • OpenCode、または CursorAI、CloudeCode を起動する
  • このプロンプトをコピー&ペーストして実行する(インストールの詳細はここを参照:https://github.com/code-yeongyu/oh-my-openagent)
Install and configure oh-my-opencode by following the instructions here:
https://raw.githubusercontent.com/code-yeongyu/oh-my-openagent/refs/heads/dev/docs/guide/installation.md

これにより、保有している LLM サブスクリプションに関するいくつかの質問がされ、Oh My Opencode が OpenCode プラグインに登録されます。

手動パス:bunx または npx で Oh My Opencode インストーラーを実行する

プロバイダーについて質問し、自動的に「最適」な構成を生成するインタラクティブインストーラーと、自動化やエージェント用の非対話モードがあります。

インタラクティブインストール:

bunx oh-my-opencode install
# npm ツールを好む場合はこちら
npx oh-my-opencode install

非対話インストール(プロビジョニングスクリプト、CI イメージ、または「エージェントインストール」に有用):

bunx oh-my-opencode install --no-tui \
  --claude=<yes|no|max20> \
  --openai=<yes|no> \
  --gemini=<yes|no> \
  --copilot=<yes|no>

インストーラーが具体的に何を行うか:

  • OpenCode 設定にプラグインを登録
  • プロバイダーの可用性とフォールバックルールを使用してモデル割り当てを生成
  • OpenCode 設定ファイルの横に oh-my-opencode 設定を書き込み

手動パス:リポジトリをクローンしてインストールスクリプトを実行

「人間による」手動フローもあります:リポジトリをクローンし、依存関係をインストールしてから、OpenCode 設定場所を検出し、バックアップを作成し、設定をマージするインストールスクリプトを実行します。

git clone https://github.com/code-yeongyu/oh-my-opencode.git ~/.oh-my-opencode
cd ~/.oh-my-opencode
npm install
npm run install

スクリプトが自動的に OpenCode 設定を見つけられない場合は、インストーラーを再実行する前に、設定パスの環境変数を明示的に設定してください。

クイック検証チェックリスト

インストール後、以下の 3 つを検証します:

  • Oh My Opencode 設定ファイルが認識される場所に存在すること
  • 専門エージェントを呼び出せること
  • ultrawork キーワードのトリガーが期待通りに動作すること

コピー用の例:

# プラグイン設定ファイルを表示する(セットアップに一致する場所を試す)
cat .opencode/oh-my-opencode.json
cat ~/.config/opencode/oh-my-opencode.json

# クイックエージェントテスト
opencode run "Use @oracle to analyse the architecture of the current project"

# クイック ultrawork トリガーテスト
opencode run "ulw list all configuration files in this project"

これら 3 つすべてが通れば、単にインストールされただけでなく、本格的に準備完了です。

設定とチューニング

設定の場所と優先順位

Oh My Opencode は、プロジェクトレベルの設定がユーザーレベルの設定に優先される優先順位で設定ファイルを検索します。ドキュメント化された検索順は以下の通りです:

  • .opencode/oh-my-opencode.json(プロジェクトレベル、最高優先度)
  • ~/.config/opencode/oh-my-opencode.json(macOS および Linux のユーザーレベル)
  • %APPDATA%\opencode\oh-my-opencode.json(Windows のユーザーレベル)

OpenCode 自体も複数の設定ソースをサポートし、それらを置き換えるのではなくマージします。キーが競合する場合のみ、後続のソースが先ほどのソースを上書きします。これは、通常は安定したグローバルベースラインと、リポジトリごとのオーバーライドを望むため重要です。

JSONC による健全な設定のサポート

OpenCode と Oh My Opencode はどちらも JSONC をサポートしています。つまり、設定ファイルにコメントや尾付きカンマを保持していても解析が破綻しません。特定の制限やモデルが選択された理由をドキュメント化する際に特に役立ちます。

“ultrawork” キーワードとその機能

ultrawork(または ulw)は、最も頻繁に使用するモード切り替えです。 タスク説明に組み込むと、システムは背景並列実行、LSP 統合、コンテキスト管理、自動タスク分解を有効にします。これはモデルへのヒントではなく、実行全体の構造を変えるハードトリガーです。

並列性と背景タスク

Oh My Opencode は、sisyphus.max_concurrent_tasks を介して背景実行の並列性制御を公開しています。

ここで高い並列性を追求しないでください。各プロバイダープランには上限があります(例えば、Claude Max20 は最大 3 つの並列タスクまで)し、それを超えると不安定な完了やデバッグの難しいタイムアウトが発生します。保守的に始め、クリーンな実行後にのみ増やしてください。

最小限の並列性設定は以下のようになります:

{
  "sisyphus": {
    "enabled": true,
    "max_concurrent_tasks": 2,
    "task_timeout": 300
  }
}

並列数 2 は、ほとんどのプランにとって安全な出発点です。

エージェントごと・カテゴリごとのモデルルーティング

Oh My Opencode は、異なるタスクが異なるモデルから利益を得るという考えに基づいて構築されており、設定は以下のことをサポートします:

  • エージェントごとのモデル選択、バリエーション、プロンプト拡張
  • 「クイック」作業と「深掘り」作業のためのカテゴリベースのルーティング
  • 好むプロバイダーが利用できない場合のフォールバックモデル

専門エージェントの詳細解説では、なぜ特定のエージェントを間違えたモデルファミリーに切り替えてはいけないか、完全なフォールバックチェーン、セルフホスティング設定でのモデルの安全なオーバーライド方法など、モデルルーティングシステムの詳細を網羅しています。

モデル解決は層状になっています:明示的なオーバーライドが優先され、次にプロバイダーのフォールバック、そしてシステムデフォルトです。フォールバックチェーンはネイティブプロバイダーから始まり、他に利用できない場合でも GitHub Copilot などの代替手段にまで降りる可能性があります。つまり、設定の誤ったエージェントが静かに失敗することは少なく、単に弱いモデルを使用するだけです。

調整可能な実用的なスタート用設定(JSONC 推奨):

{
  "$schema": "https://raw.githubusercontent.com/code-yeongyu/oh-my-opencode/master/assets/oh-my-opencode.schema.json",

  // プロバイダー制限に信頼を置くまで、並列性を保守的に保つ
  "sisyphus": {
    "enabled": true,
    "max_concurrent_tasks": 2,
    "task_timeout": 300
  },

  // エージェントのチューニング
  "agents": {
    "oracle": {
      "enabled": true,
      "model": "openai/gpt-5.2",
      "variant": "high",
      "temperature": 0.7,
      "prompt_append": "Provide concise tradeoffs and a clear recommendation"
    },
    "librarian": {
      "enabled": true,
      "model": "google/gemini-3.1-pro"
    }
  },

  // 高速クエリと深い作業のためのカテゴリルーティング
  "categories": {
    "quick": { "model": "opencode/gpt-5-nano" },
    "visual-engineering": { "model": "google/gemini-3.1-pro" }
  }
}

$schema フィールドは保持する価値があります。これにより、ほとんどのエディタで自動補完が有効になり、設定が破損した状態で実行を無駄にする前にエージェント名のタイプミスを検出できます。

MCP 統合とフック

Oh My Opencode は、サーバーコマンド、引数、環境変数を定義する設定ブロックを介して MCP(Model Context Protocol)サーバーをサポートしています。

実際には、より簡単な方法は、opencode mcp コマンドグループを使用して OpenCode の管理下で直接 MCP を管理することです。これにより、設定ファイルを直接触れることなく、追加、リスト表示、OAuth 認証を処理できます。

コピー可能なワークフロー例

以下の 2 つの例は、あえて「実際のリポジトリ」の形にしています:オーケストレーションのトリガー方法、専門エージェントの狙い方、結果の検証性を保つ方法を示しています。

例:Oracle とリポジトリマップを用いたアーキテクチャレビュー

新しいコードベースに参加するか、サービスを継承し、アーキテクチャの迅速で実行可能なビューが必要な場合に使用します。Oracle は読み取り専用の専門エージェントであり、変更を加えることはできず、アドバイスのみ提供します。

プロジェクトのルートから実行します:

opencode

OpenCode は、引数なしで起動するとデフォルトでターミナル UI を起動します。

次に、Oracle にアーキテクチャ分析と具体的なリファクタリングまたはモジュラ化計画を生成するように依頼します:

Use @oracle to analyse the architecture of this repository.
Identify the key bounded contexts, major dependency edges, and the highest risk components.
End with a refactoring plan that can be executed in small PRs.

ログ出力やスクリプティングの場合、TUI を完全にスキップして opencode run を使用します:

opencode run "Use @oracle to analyse the architecture of this repository and propose a staged refactor plan"

opencode run はプロンプトを直接渡して完了時に終了します。CI ステップや自動化パイプラインにまさに必要な動作です。

例:ultrawork オーケストレーションを用いたフル機能実装

複数のファイルや層に触れる機能が必要、または背景タスクと専門エージェントを自動的に有効にしたい場合に使用します。

ultrawork プロンプトから始めます:

opencode run "ultrawork implement a new /health endpoint with readiness and liveness checks, add tests, update documentation, and verify it runs locally"

ultrawork キーワードは、設定されたすべての専門エージェント、背景タスクの並列性、より深いツールを一度に有効にします。計画、実装、テストに別々のプロンプトは不要です。

ultrawork を使用する場合でも、専門家の挙動を明示的に誘導できます。例えば、まずアーキテクチャ設計を強制できるかもしれません:

opencode run "ultrawork ask @oracle to design the endpoint contract and dependencies first, then implement with minimal changes and add tests"

ultrawork@oracle のような明示的なエージェント言及を組み合わせるのがSweetスポットです:完全なオーケストレーションを得られる一方で、どの専門家が重要な設計決定を処理するかを制御できます。

大規模な ultrawork タスクで正しいことを1つ:並列性をプロバイダーの制限内に保ってください。2 から始め、いくつかのタスクをクリーンに実行し、増やすかどうかを決定します。プランの上限を超えて押しても速くならず、むしろ信頼性が低下します。

トラブルシューティングとベストプラクティス

Ultrawork キーワードがトリガーされない

ulw または ultrawork が無視されている場合、プラグインの読み込みとバージョン互換性をチェックするシグナルとして扱ってください。少なくとも 1 つ、キーワード検出が期待された ultrawork モードプロンプトを注入しないというレグレッションが報告されており、調査では専用のキーワード検出フックが原因を指しています。

実際には、最も速い修正方法は以下の通りです:

  • プラグインが登録されており、設定ファイルが存在することを確認する(前述の検証チェックリストを参照)
  • キーワード検出がレグレッションしたバージョンを使用している場合は、OpenCode またはプラグインをアップグレードする

インストールスクリプトが OpenCode 設定を見つけられない

OpenCode がインストールされていることを確認し(opencode --version)、その後インストーラーを再実行する前に明示的な設定パスの環境変数を設定してください。

背景タスクが多すぎたり、スロットリングの問題が発生する

レート制限、タイムアウト、不安定な完了に遭遇した場合、修正は常に同じです:並列性を減らし、再実行します。プロバイダーがすでにスロットリングしている状況で高い並列性を追いかけるのは、負ける戦いです。

ultrawork を使用すべきでない場合

Ultrawork は強力ですが、無料ではありません。並列エージェントのすべてがトークンを消費し、レート制限にカウントされます。大規模なリファクタリング、フルスタック機能開発、複雑な多段階タスクに予約してください。小さな単一ファイル編集や簡単な質問には、通常のプロンプトの方が速く安価です。

確実な経験則:

  • 小さな編集と straightforward な質問には通常のプロンプトを使用
  • システムにリポジトリ全体で分解、委任、実行、検証をさせる場合のみ ultrawork を使用

プロバイダー規約に関するコンプライアンスノート

このエコシステムに関する一部のコミュニティ議論は、特にサードパーティの OAuth と互換性レイヤー围绕して、プロバイダーの制限と利用規約に触れています。これらは現実の制約です。大規模な自動化または並列ワークフローを実行する前に、プロバイダーの規約をレビューし、動作する統合が許可されていると想定しないでください。


さらに深く知りたいですか?専門エージェントの詳細解説 では、各エージェントの役割、モデル要件、セルフホスティングオプションについて説明しています。正直なパフォーマンスデータとコミュニティが報告する請求リスクについては、Oh My Opencode 体験談記事 を参照してください。