oh-my-gemini 完全解説 -- Gemini CLIをマルチエージェントで自動化する最速フレームワーク

こんにちは、コードを書かないAIエンジニア@もるふぉです。

10年以上Railsを書いてきましたが、今はClaude Codeに書いてもらってます。

今回はGemini CLI向けのマルチエージェントフレームワーク「oh-my-gemini」を解説します。

Gemini CLIに「まず調査してから設計して、それから実装してね」って言っても、いきなりコードを書き始めますよね。

しかも昨日の続きをやろうとすると、前日の文脈を全部忘れている。

「またゼロから説明するのか...」って疲弊した経験、ありませんか。

そのストレスをまるごと解決するのが「oh-my-gemini」です。

Gemini CLI向けのマルチエージェントオーケストレーションフレームワークで、oh-my-claudecodeにインスパイアされたフック駆動設計が面白い。

フックで物理的にワークフローを強制する、セッションをまたいでもコンテキストを保持する、テストが通るまで自動でリトライし続ける。

日本語での解説記事がまだほとんどない今、アーキテクチャからインストール、実際の使い方まで一気に整理しました。

oh-my-geminiとは -- oh-my-claudecodeのGemini CLI版が登場

GitHub - richardcb/oh-my-gemini: Multi-agent orchestration for Gemini CLI. Zero learning curve. · GitHub

github.com

oh-my-geminiは、Gemini CLI向けのマルチエージェントオーケストレーションフレームワークです。

ひとことで言えば「Gemini CLIに構造化されたワークフローを持ち込むツール」ですね。

素のGemini CLIだとプロンプトで全部やりくりする必要がありますが、oh-my-geminiを入れると、タスクの調査・設計・実装・検証を専門エージェントに分業させることができます。

oh-my-claudecodeとの関係 -- 同じ「フック駆動」の設計思想

oh-my-geminiはoh-my-claudecodeにインスパイアされたプロジェクトです。

oh-my-claudecodeがClaude Code Hooksを使って多数の専門エージェントを構成しているのに対し、oh-my-geminiはGemini CLI Hooksを使って4つのエージェントを構成しています。

共通しているのは「フック駆動」という設計思想です。

「LLMに『このツールは使うな』とプロンプトで言っても守ってくれない問題」、イライラしませんか。

oh-my-geminiもoh-my-claudecodeも、プロンプトでお願いするのではなく、フックで物理的に制御するというアプローチを取っています。

「やるなと言うのではなく、できなくする」。

この発想、エンジニアとしてはめちゃくちゃ腹落ちします。

Claude Codeユーザーとして、Gemini CLI側にも同等の設計思想を持つフレームワークが出てきたのは注目に値しますね。

oh-my-claudecodeについてはこちらをご覧ください

Claude Codeをマルチエージェント化するoh-my-claudecode(OMC)の機能解説 | AimanaVo

aimanavo.com

oh-my-geminiが解決する2つの課題

想像してみてください。

oh-my-geminiが解決するのは、多くのGemini CLIユーザーが日々感じているであろう2つの課題です。

課題1: プロンプト指示だけではワークフローが守られない

LLMに「まず調査してから設計して、それから実装してね」と言っても、いきなりコードを書き始めることがあります。

フェーズをスキップしたり、調査フェーズなのにファイルを書き換えたり。

oh-my-geminiは7種類のフックで「調査モードではファイル書き込みツールを使えなくする」といった制約を物理的に強制します。

課題2: セッションをまたいだコンテキスト管理ができない

「昨日の続きをやって」と言っても、LLMは昨日のセッションの文脈を覚えていません。

oh-my-geminiのConductorシステムは、プロジェクト知識・フィーチャー仕様・実行計画を構造化ファイルとして永続化し、セッション開始時に自動で読み込みます。

この2つの課題を「フック強制 + Conductor」で解決するのが、oh-my-geminiの設計の核です。

具体的にどう動くのか、アーキテクチャを見ていきましょう。

oh-my-geminiのアーキテクチャ -- 4エージェントと7フックでGemini CLIをマルチエージェント化

oh-my-geminiの全体像は「4つの特化型エージェント」「7種類のフック」「Conductorによるコンテキスト管理」の3要素で構成されています。

4つの特化型エージェント（Orchestrator / Researcher / Architect / Executor）

oh-my-geminiが採用するのは、4つのエージェントによるマルチエージェント構成です。

ここが面白いところなんですが、「フックで強制」という部分に注目してください。

ResearcherやArchitectが勝手にコードを書き換えることは、フックレベルでブロックされています。

プロンプトで「書くな」と言うのではなく、そもそもツールが使えない状態にする。

自分もClaude Codeでサブエージェントへの役割分担は重要だと感じていますが、oh-my-geminiはそれをフレームワークレベルで強制しているのが面白いですね。

oh-my-claudecodeの多エージェント構成と比べると、4エージェントはかなりシンプルです。

ただ、Orchestrator / Researcher / Architect / Executorという分業は実務的に十分なバランスだと思います。

7種類のフック -- ワークフローを「強制」する仕組み

oh-my-geminiの核心は、7種類のフックによるワークフロー制御です。

特に重要なのはtool-filterとphase-gateの2つです。

tool-filterは、たとえばResearcherモードのときにファイル書き込み系のツールをフィルタリングして、物理的に使えなくします。

つまり「プロンプトで縛る」のではなく「APIレベルで封鎖する」わけです。

これが地味にすごくて、どんなに優秀な指示を書いても言い訳をしてスキップするLLMに対して、物理的に「できない」状態を作ることができます。

phase-gateは、フェーズ遷移時に成果物の存在を検証し、スキップを防止します。

調査が終わっていないのに実装に進もうとすると、フックが「待って、成果物がないよ」と止めてくれるわけです。

after-toolの自動検証も実用的で、コード変更後に自動でtypecheckやlintを走らせて、問題があればすぐにフィードバックします。

設定はJSONで行います。

{
  "phaseGates": { "enabled": true },
  "autoVerification": {
    "enabled": true,
    "typecheck": true,
    "lint": true
  },
  "security": { "gitCheckpoints": true },
  "ralph": {
    "enabled": true,
    "maxRetries": 5,
    "stuckThreshold": 3
  },
  "modes": {
    "enabled": true,
    "default": "implement"
  }
}

security.gitCheckpointsをtrueにすると、before-toolフックでコード変更前にgitチェックポイントを自動作成してくれます。

万が一AIが暴走してもgit resetで戻せるのは安心感がありますね。

Conductorシステム -- 3層構造のコンテキスト管理

Conductorは、oh-my-geminiのコンテキスト管理を担うシステムです。

「昨日の続きをやって」と毎回一から説明しなくて済む仕組み、と考えるとイメージが掴みやすいです。

3層構造でプロジェクトの知識を管理します。

Claude CodeのCLAUDE.mdに近い発想ですが、Conductorはより構造化されています。

/omg:setupコマンドで初期化すると、これらのファイルが生成されます。

詳細なディレクトリ構造については、公式ドキュメントを参照してください。

以降はセッションをまたいでも、session-startフックがConductorの状態を自動で読み込むので、毎回同じ説明を繰り返す必要がありません。

oh-my-geminiのREADMEでは、Conductorの導入で29%の高速化と17%のトークン削減が得られると紹介されています。

コンテキストを構造化して必要な情報だけを注入する設計なので、トークン削減は納得できる数値です。

ただし、product.mdやworkflow.mdのメンテナンスコストとのバランスは意識しておく必要がありますね。

プロジェクトの初期段階でしっかり書いておけば、その後のセッション効率は確実に上がるはずです。

全体像が把握できたところで、実際のインストール手順に進みましょう。

oh-my-geminiのインストールと初期セットアップ

前提条件

oh-my-geminiを使うには、以下が必要です。

• Gemini CLI v0.31.0以上 -- Extensions機能とHooks機能が必要なため
• Node.js -- oh-my-geminiのフックスクリプトがNode.jsで動作するため

Gemini CLIがまだ入っていない場合は、先にインストールしてください。

npm install -g @google/gemini-cli

バージョンの確認は以下で行えます。

gemini --version

v0.31.0未満の場合はアップデートが必要です。

gemini extensions installでインストール

2コマンドで完了します。

gemini extensions install https://github.com/richardcb/oh-my-gemini

インストールが完了したら、プロジェクトのディレクトリに移動して初期セットアップを実行します。

/omg:setup

これでConductor用のディレクトリとファイルが生成されます。

生成されるファイルの具体的な構造は、公式ドキュメントを参照してください。

/omg:setupで生成されたファイルを自分のプロジェクトに合わせて編集しておくと、Conductorが適切なコンテキストを注入してくれるようになります。

「えっ、これだけ？」と思いますよね。

そうです、これだけです。

あとはキーワードを使ってエージェントを呼び出すだけで、フレームワークが全部やってくれます。

oh-my-geminiのマジックキーワード -- Gemini CLIエージェントの実践的な操作フロー

マジックキーワード一覧

oh-my-geminiでは、プロンプトの先頭にキーワードを付けるだけでエージェントモードを切り替えられます。

@researcherのようにメンション形式でも使えるのは直感的で良いですね。

キーワードなしの場合はimplementモードがデフォルトなので、普段の使い勝手は素のGemini CLIと変わりません。

開発フローの実例 -- 機能追加を一気通貫で

たとえば「ユーザー認証APIを追加する」というタスクを、oh-my-geminiで一気通貫で進める場合の流れを見てみましょう。

Step 1: 調査

research: 既存の認証周りのコードとライブラリを調査して

Researcherモードが起動し、コードの読み取りとWeb検索でプロジェクトの現状を調査します。

このとき、ファイルの書き換えはフックでブロックされているので安心です。

Step 2: 設計

plan: JWT認証APIのフィーチャー仕様と実装計画を書いて

調査結果を踏まえて、Conductorのspec.mdとplan.mdが生成されます。

Step 3: 実装

implement: plan.mdに従ってJWT認証APIを実装して

Executorモードでフルアクセスが有効になり、plan.mdに沿って実装が進みます。

before-toolフックでgitチェックポイントが作成され、after-toolフックで自動的にlintとtypecheckが走ります。

Step 4: 仕上げ（必要に応じて）

ralph: 全テストが通るまで修正を続けて

テストが通らない場合は、Ralphモードで自動リトライさせることもできます。

Claude Codeの/agentやサブエージェントに近い体験ですが、oh-my-geminiはキーワードベースなのでよりシンプルですね。

明示的にモードを切り替えるので、「今どのエージェントが動いているか」が常に分かるのも良い点です。

ここで一番気になるのが、最後のRalphモードではないでしょうか。

「本当にテストが通るまでやり続けてくれるの？」という疑問、次で詳しく見ていきます。

oh-my-geminiのRalphモード -- 「諦めないAI」でGemini CLIの自動リトライを実現

これ、正直に言うと最初に見たとき鳥肌が立ちました。

Ralphモードは、oh-my-geminiの中でも特にユニークな機能です。

名前の由来はともかく、やっていることは明快で「タスクが成功するまで自動でリトライし続ける」仕組みです。

ralph: 全TypeScriptエラーを修正して

このように指示すると、ralph-retryフックが以下の流れで動作します。

1. Executorがコードを修正
2. after-toolフックで自動検証（typecheck / lint）
3. エラーがあればralph-retryフックが検出し、自動リトライ
4. 成功するか、最大リトライ回数に達するまで繰り返し

つまり「修正→検証→再修正」のループをフレームワークが自動でやってくれるわけです。

今まで「エラーが出たらまたプロンプトを送って、直ったらまたテストして...」を手動でやっていた方、これで解放されます。

設定のmaxRetriesでリトライ上限を制御でき、stuckThresholdで「同じエラーが連続した場合はユーザーにエスカレートする」という安全弁も用意されています。

{
  "ralph": {
    "enabled": true,
    "maxRetries": 5,
    "stuckThreshold": 3
  }
}

stuckThreshold: 3は「同じエラーパターンが3回続いたらユーザーに聞く」という意味です。

無限ループで暴走するリスクを抑える設計になっていますね。

自分はテスト駆動でAIを制御する手法を普段から使っていますが、Ralphモードはまさに「テストが通るまでやり直せ」をフレームワークレベルで実装しているものです。

これは親和性が高い。

ただし注意点として、Ralphモードはトークン消費が多くなります。

リトライのたびにコンテキストが積み上がるので、maxRetriesは控えめに設定しておくのが実用的です。

まずは3〜5回あたりから始めて、プロジェクトの規模に応じて調整するのが良いでしょう。

oh-my-gemini vs oh-my-claudecode -- Gemini CLIとClaude Codeどちらを使うべきか

機能対比表

oh-my-geminiとoh-my-claudecodeの主要機能を比較してみましょう。

設計哲学の違いが面白いですね。

oh-my-claudecodeは多数のエージェントで「やるべきことを細かく専門分化」するアプローチ。

oh-my-geminiは4個のエージェントで「シンプルだけど実務で十分な分業」を実現するアプローチです。

どちらが優れているというわけではなく、いわば「大人数の専門チーム vs 少数精鋭チーム」のような違いですね。

使い分けの判断基準

結論から言うと、普段使っているCLIに合わせて選べばOKです。

Gemini CLIをメインで使っていて、「プロンプトだけだとワークフローが安定しない」「セッションをまたぐとコンテキストが消える」と感じているなら、oh-my-geminiは迷わず入れていいと思います。

4エージェント構成はシンプルですが、実務では十分な分業ができます。

逆にClaude Codeがメインなら、oh-my-claudecodeのほうが自然ですね。

「両方使っている」という人も多いのではないでしょうか。

自分もClaude Codeをメインに、Gemini CLIをサブとして使うデュアル運用をしています。

その場合は、それぞれにoh-my-claudecodeとoh-my-geminiを入れておくのが理想です。

どちらか一方に絞る必要はありません。

Gemini CLIを少しでも使っているなら、oh-my-geminiを入れて損はないです。

まとめ -- oh-my-geminiは「Gemini CLIを実務レベルに引き上げる」フレームワーク

oh-my-geminiの価値を3つにまとめます。

1. フック駆動の強制力 -- プロンプトでお願いするのではなく、フックで物理的にワークフローを制御する
2. Conductorによるコンテキスト管理 -- セッションをまたいでもプロジェクトの文脈が保持される（READMEでは29%高速化・17%トークン削減と紹介）
3. Ralphモードの永続リトライ -- テストが通るまで自動で修正を続ける「諦めないAI」

日本語での解説記事がまだほとんどない今、Gemini CLIユーザーにとってはキャッチアップのチャンスです。

「試してみよう」と思ったなら、今がそのタイミングです。

インストールはこの2コマンドだけ、5分もあれば完了します。

gemini extensions install https://github.com/richardcb/oh-my-gemini
/omg:setup

Gemini CLIを実務で使いこなしたいなら、oh-my-geminiは間違いなくチェックしておくべきフレームワークです。

GitHub: https://github.com/richardcb/oh-my-gemini