oh-my-openagent（略称 OmO） は、コーディングエージェントを本気で使う人が必ずぶつかる「配線（ハーネス）を毎回自作する」問題を、丸ごと肩代わりしようとするプロジェクトだ。Claude Code を開き、次に OpenAI Codex を試し、OSS の OpenCode も気になって入れ、さらに Kimi や GLM といったモデルも使い分けたくなる。ところが各ツールごとにワークフロー・フック・ツール群・サブエージェントの定義を手で組み直すことになり、「賢いモデル」を手に入れたはずが、その周りの配線を作る仕事に時間を溶かしてしまう——OmO はそこを埋める。

作者は韓国の開発者 code-yeongyu（Yeongyu Kim）。名前は oh-my-zsh をもじったもので、実際このリポジトリは oh-my-opencode から oh-my-openagent へと改名された経緯を持つ。2026年7月時点でGitHubスターは6.5万を超え、TypeScriptで書かれた実運用志向の「エージェントハーネス」として急速に注目を集めている。

まずは、OmO を実際に導入した第三者の使用レビュー動画を見てほしい。何が起きるツールなのかは、文章より先に画面で見たほうが早い。

OmO（旧 oh-my-opencode）を実際に動かした第三者の使用レビュー。1コマンドで複数エージェントが並列に走り出す様子が確認できる。出典：YouTube — Oh My OpenCode Is Actually Insane（公式動画ではなく第三者によるレビュー）

30秒で分かる oh-my-openagent（OmO）

  • ・何者か：OpenCode / OpenAI Codex の上に載る「エージェントハーネス」。ハーネス（足回り）を作り置きしてくれる。
  • ・何ができる：ultrawork（ulw）1コマンドで、計画→コードベース探索→並列サブエージェントへ委任→検証まで自動で回す。
  • ・強み：Sisyphus らの「規律エージェント」による分業、多モデル自動ルーティング、LSP精密編集、AST-grep検索、tmux可視化。
  • ・2つの顔：Ultimate Edition（OpenCode向けフル機能）と Light Edition＝lazycodex（Codex向け配布）。中身のエンジンは共通。
  • ・注意：ライセンスは fair-code（SUL-1.0）で商用制限あり。テレメトリは既定ON。この2点は導入前に必ず確認。

この記事では、OmO を「結局それは何ができ／何を解決し／何を代替するのか」という当サイトの3つの問いに沿って、公式リポジトリの README（日本語版 README.ja.md を含む）をベースに整理する。派手な宣伝文句ではなく、設計の骨格と、導入前に知っておくべき現実的な注意点まで降りていく。

oh-my-openagent（OmO）とは——「ハーネス問題」を肩代わりする基盤

結論から言えば、OmO は「賢いモデルの隣にある、地味だが重要な配線」を作り置きしたパッケージだ。

AIコーディングの世界では2026年、「ハーネス問題（The Harness Problem）」という言葉が語られ始めた。モデルの性能はベンチマーク上どんどん上がるのに、実際の生産性はハーネス——つまりモデルを取り囲むランタイム（コンテキスト供給・ツール・メモリ・権限・サンドボックス・ループ制御）——の質で頭打ちになる、という指摘だ。当サイトでも ハーネスエンジニアリングの実装パターン でこのテーマを扱ってきた。

OmO の立ち位置は明快で、「そのハーネスはもう我々が作った（We did the work）」というものだ。Claude Code・Codex・OpenCode・各種OSSモデルを個別に整える代わりに、複数モデルのルーティング、並列サブエージェント、フック、ツール、プロジェクトルールの読み込みまでをあらかじめ組み立てた状態で配布する。

oh-my-openagent（OmO）のプレビュー画面
OmO の公式プレビュー。単一のコマンドから、複数の役割を持つエージェントが協調して動く。出典：code-yeongyu/oh-my-openagent

重要なのは、OmO が「新しいコーディングエージェント」そのものではない点だ。OmO は既存のエージェントCLIの上に載るプラグイン／ハーネス層であり、単体では動かない。Ultimate Edition は OpenCode のプラグインとして、Light Edition は OpenAI Codex の配布物として機能する。土台となるCLIを置き換えるのではなく、その上に「チームで開発する作法」を注入するイメージだ。

OmO を一言で言うなら「oh-my-zsh の発想を、コーディングエージェントに持ち込んだもの」。zshに設定・プラグイン・テーマを作り置きするのが oh-my-zsh なら、エージェントに規律・ツール・並列オーケストレーションを作り置きするのが oh-my-openagent だ。

「作り置き」の価値は、時間の節約だけではない。ハーネスを自作すると、フックやツールの設定は書いた本人の頭の中にしか残らず、チームで共有しづらい。役割・ツール・ループ制御が最初から1つのパッケージにまとまっていれば、「どう配線したか」ではなく「何を作るか」に集中できる。設定の再現性が上がり、環境差による「自分の手元では動くのに」も減る——これは個人の速度というより、複数の開発者やマシンをまたいだ再現性の話だ。

もっとも、その恩恵と引き換えに、内部で何が起きているかがブラックボックス化しやすい側面もある。便利な作り置きに乗るほど、「いま裏で何本のエージェントが、どのモデルで、いくらのトークンを使って動いているか」が見えにくくなる。OmO は tmux 可視化やログでそこを補うが、使いこなすうえでは、便利さに乗りつつも裏側の挙動を折に触れて確認する姿勢が欠かせない。この記事でライセンスとコストを機能と同じ比重で扱うのも、同じ理由からだ。

3つの疑問に答える——OmOは何ができ、何を解決し、何を代替するのか

当サイトの読者がツール記事に求めるのは、突き詰めれば3つの問いへの答えだ。OmO について、順に答える。

問い oh-my-openagent（OmO）の答え
① 何ができる？ ultrawork（ulw）1コマンドで、専門エージェントのチームが計画・探索・並列委任・検証を協調して行い、タスクを完了まで駆動する。LSPによるIDE級の精密編集、25言語対応のAST-grep検索、tmuxでの進捗可視化を伴う。
② 何を解決する？ 「ハーネス問題」。Claude Code・Codex・OpenCode・各種モデルを使い分けるたびに、ワークフロー・フック・ツールを手で組み直す重さを、作り置きの配線で肩代わりする。
③ 何を代替する？ 土台のCLI（OpenCode / Codex）は代替せず、その上に載る。素の Claude Code / Cursor / 単体 Codex に、多モデルルーティングと並列エージェントを足して拡張する位置づけ。

ポイントは③だ。OmO は Claude Code や Codex を「捨てさせる」ツールではない。むしろそれらの上に載り、単一モデル・単一エージェントでは届かない「チーム開発の density（密度）」を足す。だからこそ、既に何かのエージェントCLIを日常的に使っている人ほど、OmO の恩恵を受けやすい。

逆に言えば、コーディングエージェントをまだ日常的に使っていない人がいきなり OmO を入れても、恩恵は薄い。まず OpenCode か Codex を使い込み、「配線を毎回組み直すのが面倒だ」と感じ始めた人が、OmO の想定ユーザーだ。

中核は「規律エージェント」の分業——Sisyphusが束ねるチーム

OmO の設計思想が最もよく表れているのが、Discipline Agents（規律エージェント） と呼ばれる役割分担だ。1つの万能エージェントに全部やらせるのではなく、役割を分けて、それぞれに向いたモデルを割り当てる。

READMEが挙げる主要な役割は次の通りだ（モデル名は2026年7月時点のREADME記載であり、利用時点の対応は公式ドキュメントを参照）。

OmOの主な規律エージェント

  • ・Sisyphus（シーシュポス）：オーケストレーター。全体を束ね、誰に何を任せるかを決める司令塔。
  • ・Hephaestus（ヘファイストス）：自律的な深い実装を担う「鍛冶の神」。重い実装タスクを黙々と進める。
  • ・Prometheus（プロメテウス）：計画・インタビューモード。着手前に要件を詰めるプランナー。
  • ・Oracle（オラクル）：アーキテクチャ設計とデバッグの相談役。
  • ・Librarian（司書）：ドキュメント・コード検索の専門家。文脈を集めてくる。

この分業がなぜ効くのか。答えは、当サイトが ループエンジニアリング でも繰り返し書いてきた「作り手と検証役を分ける」という原則にある。同じエージェントに実装と検証を両方やらせると、自分が生んだバグの盲点のまま自分の仕事を甘く採点してしまう。役割を物理的に分け、司令塔（Sisyphus）が並列に走らせて突き合わせることで、その自己採点バイアスを断つ。

下の図は、ultrawork を叩いたときに OmO 内部で何が起きるかを単純化したものだ。

graph TD U["開発者：ultrawork タスク"] --> S["Sisyphus
オーケストレーター"] S --> P["Prometheus
計画・要件詰め"] P --> S S --> L["Librarian
コード・文脈収集"] S --> H1["Hephaestus #1
実装（並列）"] S --> H2["Hephaestus #2
実装（並列）"] S --> O["Oracle
設計・デバッグ相談"] H1 --> V["検証・突き合わせ"] H2 --> V O --> V V -->|"未完なら再委任"| S V -->|"完了"| DONE["ORCHESTRATION COMPLETE"]

図の肝は、右下の「未完なら再委任」の戻り線だ。OmO は Ralph Loop と呼ばれる自己参照ループを備え、検証を通るまで実装→検証を回し続ける（この「止まらないループ」をどう安全に設計するかは ループエンジニアリング を参照）。単発で走らせて結果を丸ごと受け取るのではなく、タスクが本当に通るまで自走する点が、素のCLIとの最大の違いだ。

規律エージェントには、オリジナルのキャラクター設定まで用意されている。単なる比喩ではなく、役割の性格をチームで共有するための工夫だ。

OmOのオーケストレーター Sisyphus のキャラクター OmOの実装担当 Hephaestus のキャラクター
左：司令塔 Sisyphus／右：実装担当 Hephaestus。役割ごとに性格づけされている。出典：code-yeongyu/oh-my-openagent

さらに OmO は、単なるプロンプトの束ではなく、実装レベルの道具立ても厚い。

・Hash-Anchored Edits：行に LINE#ID のハッシュを付けて編集対象を検証し、「行がずれて別の場所を書き換える」事故を防ぐ
・LSP統合：言語サーバ経由でIDE級の診断・ナビゲーション・リファクタリングを行う
・AST-grep：25言語に対応した構文パターン検索・書き換え
・Comment Checker：AIが生成しがちな冗長コメントの残骸を除去
・Rules Injection：AGENTS.md などプロジェクトルールを自動でコンテキストへ読み込む

この分業を「目で見える」ものにしているのが Team Mode（チームモード）と tmux 可視化だ。リード1人＋最大8人の並列メンバーがそれぞれ何をしているか、ターミナルを分割してリアルタイムに表示する。エージェントが増えるほど「今どのメンバーがどこで詰まっているか」が分からなくなるのが並列実行の弱点だが、OmO は tmux ペインへ進捗を流すことで、その不透明さを緩和している。並列で走らせながらも、人間が「観察者」として全体を俯瞰できる設計だ。

多モデル・ルーティングの発想は、当サイトで解説した cascadeflow（小型モデルで投機実行し、品質が足りなければ大型へ昇格）や、LangGraph のグラフによる分岐・ループとも地続きだ。OmO はそれらの制御を「作り置きのチーム」として梱包した、と捉えると位置づけが分かりやすい。役割ごとに最適なモデルを割り当てる発想——司令塔には推論の強いモデル、単純作業には安価で速いモデル——は、単一モデルに全部を任せるより、品質とコストのバランスを取りやすい。ここが「多モデルを1つのハーネスで束ねる」ことの実利だ。

Ultimate と Light（lazycodex）——OpenCodeとCodex、2つのエディション

OmO を語るうえで避けて通れないのが、2つのエディションの違いだ。これを混同すると導入で迷う。

観点Ultimate EditionLight Edition（= lazycodex）
土台のCLIOpenCodeOpenAI Codex
形態OpenCode のフル機能プラグインCodex への配布物（薄い導入層）
規律エージェント11エージェント・54以上のライフサイクルフック8つの中核コンポーネント
導入コマンドbunx oh-my-openagent installnpx lazycodex-ai install
AST-grep / 内蔵MCPあり（Exa・Context7・Grep.app 等）中核機能に絞る
向いている人OpenCodeで最大限を引き出したいCodexに最短で harness を足したい

つまり、エンジンは同じOmOで、入口（どのCLIに載せるか）が違うだけだ。OpenCode を使うなら Ultimate、Codex を使うなら Light = lazycodex を選ぶ。lazycodex は「OmO を Codex に一発で入れる」ことに特化した配布パッケージで、その詳しい使い方（$ulw-plan / $start-work などのコマンド体系や、LazyVim になぞらえた設計思想）は別記事の lazycodex 解説 で扱う。

迷ったときの選び方はシンプルだ。すでに OpenCode 派なら oh-my-openagent（Ultimate）／Codex 派なら lazycodex（Light）。両方入れることもできる（--platform=both）が、まずは自分の主戦場のCLIに合わせて一方から始めるのが素直だ。

導入と実行——bunx / ultrawork と、知っておくべき設定

ここからは、実際に触るときの手順を公式READMEから引く。読者が自分の手で確認できる「実行できる手順」に絞る。

Ultimate Edition（OpenCode向け）の導入は、bunx 一発だ。

# Ultimate Edition（OpenCode）
bunx oh-my-openagent install

# 旧名でも導入できる（後方互換）
bunx oh-my-opencode install

# 両エディションをまとめて入れる
bunx oh-my-openagent install --platform=both

Light Edition は Codex 向けに、npx lazycodex-ai で入れる。TUIを使わない完全自動セットアップも用意されている。

# Light Edition（Codex）
npx lazycodex-ai install

# 非対話（自動承認）で入れる
npx lazycodex-ai install --no-tui --codex-autonomous

導入後は、主役のコマンド ultrawork（エイリアス ulw）を叩くだけで、規律エージェントのチームが動き出す。

# タスクを渡して自走させる
ultrawork "認証フローを end-to-end で実装して、テストが通るまで直して"

# 短縮エイリアス
ulw "このバグを再現し、原因を特定して回帰テストごと直して"

ここで、導入前に必ず押さえておくべき設定が2つある。ひとつはテレメトリだ。OmO は既定で匿名の利用統計（PostHog）を送信する。プライバシーを重視するなら、環境変数か設定ファイルで無効化しておく。

// .opencode/oh-my-openagent.jsonc（設定例）
{
  "team_mode": {
    "enabled": true,
    "max_parallel_members": 4,
    "tmux_visualization": true
  },
  "telemetry": false
}

環境変数でも止められる。OMO_DISABLE_POSTHOG=1（本体）、OMO_CODEX_DISABLE_POSTHOG=1（Codex側の Light）を設定すればよい。

もうひとつが Team Mode（チームモード）だ。リード1人＋最大8人の並列メンバーで走らせ、tmux でリアルタイムに進捗を可視化できる。max_parallel_members の値がそのまま並列度になるが、並列度を上げるほどトークン消費も比例して増える。ここは「速さ」と「請求額」のトレードオフを意識して決めるべき数字だ。

並列度＝コスト、を忘れない

  • ・max_parallel_members を上げるほど同時に走るエージェントが増え、トークン消費（＝課金）も並列度に比例して膨らむ。
  • ・OmO は「止まるまで回る」Ralph Loop を持つため、上限設定を怠ると想定外の請求につながりうる。まず小さい並列度で挙動を掴むこと。
  • ・GitHubの説明文自体が OmO を「for tokenmaxxers（トークンを惜しまない人向け）」と表現している。裏を返せば、コストに敏感な現場では設定でしっかり絞る前提のツールだ。

oh-my-openagent が向く現場・向かない現場——導入判断の軸

機能が豊富なツールほど、「自分が使うべきか」の線引きが難しくなる。OmO は強力だが万能ではない。導入判断の軸を、正直に整理しておく。

まず、OmO が明確に向いている現場はこうだ。すでに OpenCode か Codex を日常的に使っていて、「毎回ワークフローを組み直すのが面倒」「単一エージェントでは大きめのリファクタが途中で崩れる」と感じている——そういう人には、作り置きのチームと多モデルルーティングが素直に効く。大規模・複雑なコードベースで、探索と実装と検証を並列に走らせたい場面ほど、density（密度）の高さが生きる。

一方で、向かない現場もはっきりしている。下の3つに当てはまるなら、OmO はオーバースペックだ。

・コーディングエージェント自体が初めて：まず素の Claude Code や Codex を使い込むほうが学びが多い。ハーネスの価値は「自作の面倒さ」を知って初めて分かる
・トークンコストを厳しく管理したい：並列エージェント＋自走ループは強力な分、消費も大きい。予算が硬直的な現場では設定で絞る前提が要る
・商用プロダクトに組み込みたい：後述するライセンス（fair-code）の制限に抵触しうる。ここは機能以前の判断軸になる

もうひとつ、判断を助ける観点として「素のCLIとの差分は何か」を押さえておくとよい。OmO が足すのは、突き詰めれば「役割分担」「多モデル・ルーティング」「検証が通るまでの自走」「AST-grep・LSPなどの精密な道具立て」の4点だ。この4点のうち2つ以上に価値を感じるなら、oh-my-openagent を試す価値は十分にある。逆に「1つのモデルに、1つのタスクを、その都度渡せれば十分」という使い方なら、ハーネスの厚みはむしろ邪魔になりうる。

導入判断のチェックリスト

  • ・YESが多いほど向く：OpenCode/Codexを日常的に使う／大規模コードベースを触る／並列で探索と実装を回したい／多モデルを使い分けたい。
  • ・NOなら見送りも選択肢：エージェント自体が初めて／トークン予算が硬直的／商用組み込みを予定している。
  • ・迷ったら：まず小さい並列度で1タスクだけ ultrawork を回し、素のCLIとの体感差を測ってから本格導入を判断する。

ライセンスは「fair-code」——OSSと呼べない一線と、商用利用の注意

最後に、OmO を紹介するうえで最も誠実に伝えるべき点を書く。OmO は、一般的な意味での「OSS（オープンソース）」ではない。

ライセンスは Sustainable Use License（SUL-1.0）。これは「fair-code」と呼ばれる系統で、n8n などが採用しているのと同じ発想だ。ソースコードは公開され、閲覧・改変・自己利用はできるが、OSI（Open Source Initiative）が承認する意味でのオープンソースではない。

導入前に必ず LICENSE.md を確認

  • ・できること：個人利用、社内の内部業務での利用、非商用での再配布（無償かつ非商用が条件）。
  • ・制限されること：OmO を組み込んだ有償サービスの提供など、商用目的の利用・再配布。
  • ・結論：「GitHubで公開されている＝自由に商用利用してよい」ではない。商用で使う可能性があるなら、必ず最新の LICENSE.md を読み、必要なら作者に確認すること。

当サイトは「AI関連OSSの日本語解説」を掲げているが、OmO については正確を期して「ソースコード公開（fair-code、商用制限あり）」と表現する。この一線を曖昧にして「OSSだから何でも自由」と伝えるのは、読者に不利益をもたらす。ライセンスは、機能と同じくらい重要な「仕様」だ。

実務的には、次の手順で確認するのが安全だ。まず GitHub リポジトリの LICENSE.md を開き、Sustainable Use License の全文に目を通す。次に、自分の用途が「個人・社内の内部業務」か「外部提供を伴う商用」かを切り分ける。前者なら基本的に問題ないが、後者の可能性が少しでもあるなら、作者が案内している商用ライセンスの窓口や CLA（Contributor License Agreement）の記述を確認し、必要に応じて問い合わせる。ここを飛ばして「動いたから使い続ける」と、あとから利用条件の逸脱に気づく——という事故が最も避けたいパターンだ。

fair-code は「悪」ではない。作者が持続的に開発を続けるための、正当な選択肢のひとつだ。重要なのは善悪の判断ではなく、利用者が自分のユースケース（個人か、社内か、商用提供か）を照らして、ライセンス条項を事前に確認するという当たり前の手続きである。

なお、READMEに登場するモデル名（Opus 4.7 / GPT-5.5 / Kimi K2.6 / GLM-5.1 など）や星の数といった数値は、いずれも2026年7月時点の記載・実測に基づく。モデルの対応状況やライセンス条項は更新されうるため、導入時点の一次情報（公式リポジトリ・公式サイト）で確認してほしい。

まとめ——oh-my-openagent は「ハーネス自作の時代」を終わらせるか

oh-my-openagent（OmO）は、AIコーディングの主戦場が「モデル選び」から「ハーネス設計」へ移ったことを、最もはっきり体現したプロジェクトのひとつだ。

この記事のまとめ

  • ・OmO は OpenCode / Codex の上に載るエージェントハーネス。ultrawork 1コマンドで、規律エージェントのチームが計画・並列実装・検証まで自走する。
  • ・中核は Sisyphus（司令塔）らの役割分担と多モデル・ルーティング。作り手と検証役を分ける原則を、作り置きのチームとして梱包している。
  • ・入口は2つ。OpenCode派は oh-my-openagent（Ultimate）、Codex派は lazycodex（Light）。エンジンは共通。
  • ・注意点は2つ。ライセンスは fair-code（SUL-1.0）で商用制限あり、テレメトリは既定ON。導入前に必ず確認する。

「賢いモデルさえあれば十分」という時代は、静かに終わりつつある。モデルの周りをどう配線するか——それを自作するか、OmO のような作り置きに乗るか。少なくとも「配線こそが生産性を決める」という認識は、もう一部の先鋭的な開発者だけのものではなくなった。OmO は、その現実を ultrawork という1コマンドの体験に落とし込んで見せた点で、いま触っておく価値のあるプロジェクトだ。ただし——ライセンス（fair-code・商用制限）とコスト（並列度に比例するトークン消費）という2つの「仕様」を、機能と同じ目線で確認したうえで、である。

参照ソース

・code-yeongyu/oh-my-openagent（GitHub・SUL-1.0）
・oh-my-openagent 公式日本語README（README.ja.md）
・OmO 公式サイト（omo.dev）
・The Harness Problem（背景概念）
・Oh My OpenCode Is Actually Insane（第三者レビュー動画・YouTube）
・code-yeongyu/lazycodex（Codex向け配布・関連リポジトリ）