Oh My Opencode レビュー：正直な結果、請求リスク、そして投資が worthwhile なタイミング

Ultrawork を実行した際に実際には何が起こるのでしょうか。

目次

Oh My Opencode は「仮想 AI 開発チーム」を約束しています。Sisyphus が専門家を指揮し、タスクが並列で実行され、ultrawork という魔法のようなキーワードがそのすべてを活性化させます。

この約束は、適切なワークロードに対しては成立します。しかし、不適切なワークロードに対しては、結果が改善されないままコストと複雑さが増加するだけです。本記事では、実際のハンズオンのテストで何が起きたか、そしてコミュニティが数ヶ月間の実利用を通じて何を見出したかを解説します。

lazy agents working in parallel

スタックに慣れていない場合は、以下の手順で始めてください。

本記事では、システムにすでに慣れ、実際の性能を知りたいと考える読者を想定しています。OMO が AI コーディングツールチェーンにどのように位置づくかという広い視点については、AI 開発者ツール概要 を参照してください。

Oh My Opencode のパフォーマンス：ハンズオンテストの結果

私は、素の OpenCode に対して使用するのと同じテストを実行しました。具体的には、OpenCode に対してローカルの Ollama と llama.cpp モデルで実行した LLM ベンチマークタスク と同じものです。今回は、Big Pickle モデル（OpenCode Zen 経由の GLM 4.6、無料枠）で実行しました。

結論から言うと、結果は賛否両論で、その失敗モードは教育的なものでした。

明示的な Ultrawork プロンプトがない場合、Sisyphus が委任をスキップする理由

最初に遭遇した問題は、Sisyphus が明示的なプロンプトがない場合、オーケストレーターとして振る舞わないという点でした。ulw プレフィックスをつけていても、彼は自分ですべてを始めました。ファイルを直接読み、コードを書き、調査や計画フェーズを完全にスキップしました。Oracle への委任、並列の Explore 実行、Prometheus によるインタビューは皆無でした。

実際にオーケストレーションをトリガーするために、プロンプトで明示する必要がありました。

ulw 最初にコードベースを調査し、
詳細な計画を作成し、
実装タスクを委任し、
委任が不合理な場合のみ自分自身で直接作業を行う

それをすることで、システムは謳い文句通りに動作しました。しかし、そのようなフレーミングなしのデフォルト動作は、より重いコンテキストウィンドウを持つ素の OpenCode と同じでした。ultrawork キーワードだけでは委任を保証するものではなく、それを行うための前提条件に過ぎません。

テスト 1: IndexNow CLI ツール — Oh My Opencode のオーケストレーションが報われる場所

タスクは、検索エンジンのインデックス登録のために URL を IndexNow API に送信するコマンドラインツールの作成でした。これは、API 仕様を読む、CLI を設計する、実装する、テストするという、適切にスコープされたマルチステップタスクです。

Oh My Opencode と明示的なオーケストレーションプロンプトを使用した場合、その結果は素の OpenCode よりも明らかに優れていました。最終的なツールは、標準の CLI オプションをサポートするだけでなく、sitemap.xml から URL を正しく抽出してバッチで送信しました。Librarian エージェントが IndexNow のドキュメントを引き出したことで、素のモデルランでは見逃されたコンテキストが提供されました。

oh my opencode indexnow session log

OMO が構築されているタスクの典型です：調査＋実装＋いくつかの設計決定。ここではオーバーヘッドが報われました。

テスト 2: ページ移行マッピング — 結果は同じだがトークンは 3 倍

2 つ目のテストはドキュメント分析タスクでした。スラッグと移行ポリシー文書に基づいて、ウェブサイトのページをどこに移行すべきか整理することです。

その結果は、素の OpenCode ランと完全に同一でした。精度も構造も決定も同じです。しかし、OMO ランではトークン消費量が約3 倍に達しました。

これは単一のコンテキストウィンドウを要する推論タスクです。並列化の活用余地も、サブエージェントから専門知識を引き出す余地もありません。オーケストレーション層は価値を付加するどころか、オーバーヘッドを加えただけでした。この種のタスクでは、素の OpenCode の方が良い選択です。

モデル選択：なぜ弱いモデルはオーケストレーションのオーバーヘッドに苦しむのか

Big Pickle（無料枠モデル）で実行した際、コミュニティも指摘していることが浮き彫りになりました。弱いモデルは、強力なモデルよりもハネスの質に敏感であるということです。Claude Opus は、周囲に重いオーケストレーション層があっても、良好な出力を生成するほど回復力があります。Big Pickle のような小さなモデルは、コンテキストにノイズを加える複雑なマルチエージェント構成よりも、クリーンで焦点の絞ったプロンプトから恩恵を受けます。

OMO を予算モデルで実行する場合は、シンプルに始めるべきです。Librarian と Explore が真に情報を追加する調査中心のタスクでオーケストレーションを使用してください。モデルが明確な入力と思考のスペースだけを必要とする純粋な推論タスクでは避けてください。

Oh My Opencode のコミュニティからの知見：ベンチマーク、請求、および現実的な注意点

全面的に依存する前に、コミュニティが実利用を通じて見つかったこと——成功例と失敗モードの両方——を知る価値があります。

Oh My Opencode ベンチマーク：69% 対 73% の達成率、素の OpenCode より 3 倍の要求数

コミュニティのメンバーが 120 以上のエージェント/モデルの組み合わせを体系的にベンチマークし、結果を公開しました。OMO Ultrawork を有効にした場合、コーディング評価での達成率は**69.2%でした。これに対し、OMO を使用しない通常の OpenCode は73.1%**でした。OMO ランは 10 分長くかかり（55 分対 45 分）、27 回ではなく 96 回のリクエストを行いました。

彼らの結論は、「文字通り、ステップが多いだけの Opus だ」というものです。Opus はハネスの違いに対して特に回復力があり、周囲に何があっても強力な結果をもたらします。弱いモデルはハネスに対してより敏感でしたが、OMO にとって有利とは限りませんでした。

これは OMO が無駄だということではありません。大規模なマルチファイルタスク、並列バックグラウンドエージェント、複雑なエンジニアリングワークフローでは、オーバーヘッドは報われます。しかし、単一のコンテキストウィンドウに収まるコーディングタスクでは、良いモデルを使用する素の OpenCode が、完全なオーケストレーションスタックと同等かそれ以上の性能を示すことがよくあります。

スタートアップ時のトークンオーバーヘッド：作業開始前に 15,000〜25,000 トークン

コミュニティからの再発する不満として、OMO は起動時に多くのツールと MCP を注入するという点があります。単純な"Hello world"メッセージでも、実際の作業が始まる前のコンテキストウィンドウ設定だけで15,000〜25,000 トークンを消費することがあります。メンテナはこれを認識しており、遅延ツール読み込みに取り組んでいますが、2026 年初頭時点では、価格見積もりを計算する際に考慮すべき現実的なコストです。

350 ドル（約 5 万円）の Gemini 無限ループ — 対処法

2026 年 3 月、確認されたバグ（Issue #2571、ラベルwill-fix）により、ユーザーが 1 午後に約 438 ドル（約 6.5 万円）の請求を受けたことが発覚しました。3 つの別々の問題が重なり合いました。

  1. サーキットブレーカーの欠如: OMO にはサブエージェントごとの最大ステップ制限がありませんでした。Gemini モデルが git diff / read 検証ループに陥り、3.5 時間にわたって 809 回連続ターン実行され、停止しませんでした。

  2. 無音のモデルルーティング: ユーザーの親セッションは GPT-5.4 でしたが、委任された Compose UI タスクは、カテゴリールーティング（visual-engineering）を通じて Gemini 3.1 Pro にルーティングされました。ユーザーが意図的に選択せず、後から SQLite データベースを掘り起こすまで視界にないモデルでした。

  3. コスト表示の誤り: OpenCode の gemini-3.1-pro-preview に対する価格スナップショットに、>200K コンテキストの価格ティアが欠けていました。Google は 200K トークンを超えるコンテキストに対して 2 倍を請求しますが、OpenCode はすべて基本レートで計算しました。表示されたコストは、実際の Google の請求額の半分未満でした。

コミュニティのコメントがこれをよくまとめている：“Gemini は私にとって常にループに陥り続けるため、読み取り専用モデル以外ではほとんど使用しません。”

修正（PR #2590）が進行中です——構成可能な最大ステップ制限とループ検出の追加。それがリリースされるまで、自分自身を保護してください。

  • カテゴリ設定を監査してください。もし任意のカテゴリが Gemini にマッピングされている場合（デフォルトでは visual-engineering を含む）、そのカテゴリのすべてのバックグラウンドタスクは——静かに——Gemini を使用します。フォアグラウンドセッションが異なるモデル上にあっても同様です。
  • background_task 内の Gemini に対する明示的な providerConcurrency 制限を設定してください。これを 1 に設定することで、被害範囲を制限できます。
  • 実際のプロバイダーの請求ダッシュボードを確認してください。特に Gemini の場合は、OpenCode の表示コストだけでなく、実際の請求額を確認してください。
{
  "background_task": {
    "providerConcurrency": {
      "google": 1   // サーキットブレーカーがリリースされるまでハードキャップ
    }
  }
}

Ultrawork 委任にはキーワードが必要 — 自動ではありません

初期ユーザーは、ultrawork がない場合、メインエージェントは専門サブエージェントに委任せず、ただ read や grep を直接呼び出すことが多かったことを発見しました。メンテナは早期にこれを認めていました：“明示的なプロンプトなしに、システムプロンプト指示だけで適切なエージェントを呼び出すことを達成するのは難しいようです。”

ultrawork キーワードがオーケストレーションを確実にトリガーするものです。それがない場合、あなたは通常、より重いコンテキストウィンドウを持つ素の OpenCode を実行していることになります。これは私自身のテストで見つけたことと一致します。

OMO の軽量な代替案：OMO Slim と Oh-My-Pi

フルなエージェントオーケストレーションのオーバーヘッドなしで、バックグラウンド実行フックと OMO の重要な改善を望む場合は、oh-my-opencode-slim というコミュニティフォークがあります。これは機能セットをトリミングしたものです。一部のユーザーは、バックグラウンドタスク実行とフックに焦点を当て、プロンプト表面を最小限に抑えた oh-my-pi へ移行しました。

あるユーザーがうまくまとめた言葉：“私はフックとバックグラウンドタスク実行のために OMO が好きです。OMO slim は間違えたものを最適化しようとしていると思います。ベースの OpenCode プロンプトに、モデルが停止すると判断したときに自動でモデルを継続するように促すバックグラウンドワーカーとフックがあれば、私には十分です。”

最適な選択はタスクの特性に依存します。大規模でマルチステップのエンジニアリング作業であれば、フルな OMO が正当化されます。日常的な短いタスクでは、より軽量なハネスの方が、コストを抑えつつ良い結果を生むことが多いです。

Oh My Opencode が真に優位に立つ時：実際のユーザー結果

注意点をバランスよくするため、ユーザーが OMO の明確な勝利として報告しているものを以下に示します。

  • 8,000 の ESLint 警告が 1 日で解消 — 並列の Explore エージェントがコードベースを走査しながら、ワーカーエージェントが同時に修正を実行
  • 45,000 行の Tauri アプリが一夜で SaaS ウェブアプリへ変換 — Prometheus インタビューモードが詳細な計画を作成し、Ralph Loop が最初から最後まで実行
  • フルスタック機能のエンドツーエンド実装 — 初期プロンプト以降、ユーザーがキーボードを触ることなく完了
  • 継承されたコードベースのアーキテクチャレビュー — Oracle の読み取り専用アドバイザー役割が、意図せず変更を加えることなく問題を浮き彫りにする

共通点は、並列化の恩恵を受け、Prometheus が検証できる明確な受入基準を持つタスクです。単一の焦点の絞ったモデルで十分なタスクでは、オーケストレーションのオーバーヘッドから得られる恩恵はほとんどありません。

Oh My Opencode vs 素の OpenCode：それぞれを使うべき場面

Oh My Opencode は、素の OpenCode よりも普遍的に優れているわけではありません。それは特定の種類の作業に対するパワーマルチプライヤーであり、それ以外はオーバーヘッドです。

フルな OMO スタック（ultrawork 付き）を使用する場面：

  • タスクが複数のファイルやレイヤーにまたがる場合
  • 調査、計画、実装、検証を別々のフェーズとして必要とする場合
  • ワーカーが実行している間に、Explore や Librarian などの並列バックグラウンドエージェントがコンテキストを集める恩恵を受ける場合
  • スコープが大きく、さもなければエージェントを複数の連続プロンプトを通じて見守る必要がある場合

素の OpenCode（または軽量なハネス）を使用する場面：

  • タスクが単一のコンテキストウィンドウに収まる場合
  • 外部調査を伴わない純粋な推論の問題の場合
  • 予算モデルを実行している場合 — 彼らはオーケストレーションの複雑さよりも、クリーンで焦点の絞ったプロンプトから恩恵を受けます
  • カテゴリルーティングによる驚きなしに、予測可能な請求を望む場合

請求リスクは実在し、報告されていません。サーキットブレーカーが実装されるまで、Gemini を使用した OMO は「放って忘れる」システムではなく、アクティブな監視が必要なものとして扱ってください。それ以外のことについては、システムは適切な問題に向けられた場合、真に印象的です。

出典

本記事で参照されているコミュニティディスカッションとissues：