oh-my-claudecode入門 — Claude Codeのマルチエージェント・オーケストレーション

はじめに

Claude Code は強力な CLI エージェントだが、単体運用には構造的な限界がある。

• 1エージェント構成: 設計・実装・テスト・レビューをすべて同一コンテキストで処理するため、役割の分担が難しい
• context の肥大化: 長いセッションでは context window を圧迫し、応答品質が低下する
• モデル固定: タスクの複雑度に関係なく同一モデルを使い続けるため、単純なタスクにも高コストのモデルを消費する

これらは Claude Code 自体の欠陥というより、単一エージェントアーキテクチャの構造的な制約だ。解決策の一つがマルチエージェント構成だが、自前で組むとオーケストレーション層の設計・実装コストが大きい。

oh-my-claudecode は Claude Code のプラグインとして動作するマルチエージェント・オーケストレーション基盤で、この課題に対するひとつの解答を提示している。

注記: 本記事の情報は2026年4月時点のものであり、各リポジトリの機能・数値は変動する可能性がある。最新の情報は各リポジトリの README を参照してほしい。

oh-my-claudecodeとは

oh-my-claudecode（以下 OMC）は、Claude Code にマルチエージェント・オーケストレーション機能を追加するプラットフォームだ。Claude Agent SDK（@anthropic-ai/claude-agent-sdk）上に構築され、TypeScript で実装されている。

2026年1月の公開から約3ヶ月で Stars ~2.8万（2026年4月13日時点）に達しており、開発速度・コミュニティ成長ともに活発なプロジェクトだ。

設計思想は「ゼロ設定原則」だ。Claude Code ユーザーであれば最小限の学習コストで導入でき、既存のワークフローを壊さずにマルチエージェント構成へ移行できる。

なお、本記事では導入・使い方・アーキテクチャに焦点を当てる。同じ作者による姉妹プロジェクト oh-my-codex との設計判断の違いに関心がある場合は、oh-my-codex 入門 および oh-my-claudecode vs oh-my-codex を参照してほしい。

アーキテクチャ

OMC は Claude Code が提供する拡張機構を4層で活用する。コードベースは約474本の TypeScript ソースファイルとほぼ同数のテストファイルから構成されており、主要機能のほとんどがテストで網羅されている。

この上に、モデルルーティングエンジン・エージェントレジストリ・Team パイプラインといったコアコンポーネントが構築されている。特にフック層が重要で、Claude Code のライフサイクルイベントをインターセプトすることで、モデル選択の自動化やタスク継続の強制といった機能を実現している。

MCP ツールサーバーは Claude Agent SDK の createSdkMcpServer でインプロセスサーバーとして動作し、サブエージェントに LSP（hover, goto_definition, find_references, diagnostics 等）・AST パターン検索（@ast-grep/napi ベース）・Python REPL などのツール群を提供する。ツールはカテゴリ単位で無効化できる（OMC_DISABLE_TOOLS=lsp,python-repl 等）。

エージェントとモデルルーティング

OMC の中核的な特徴は、特化エージェントの静的レジストリとスマートモデルルーティングの組み合わせだ。「どのエージェントで考えるか」と「どのモデルで計算するか」の両方をツール側が自動決定する。

特化エージェントと4レーン構成

OMC のエージェントは agents/ ディレクトリの Markdown プロンプトと src/agents/definitions.ts の TypeScript 定義で構成され、v4.11.5 時点で19種が4つのレーンに分類されている。

• Build/Analysis レーン: explore（コード探索）、analyst（技術分析）、planner（計画立案）、architect（設計）、debugger（バグ調査）、executor（実装）、verifier（検証）、tracer（トレース）の8種。開発サイクルの主体となるレーンだ
• Review レーン: security-reviewer（セキュリティ）、code-reviewer（品質）の2種
• Domain Specialists レーン: test-engineer、designer、writer、qa-tester、scientist、git-master、code-simplifier、document-specialist の8種。領域特化の専門エージェント群
• Coordination レーン: critic（批判的レビュー）の1種

各エージェントのプロンプトは loadAgentPrompt() で動的にロードされ、全エージェントに品質保証指針（skininthegamebros-guidance）が自動付加される。この指針には最小限のコメント・完了前の検証義務・隣接バグの報告義務などが含まれており、エージェント間で品質基準を統一する仕組みだ。

スマートモデルルーティング

ルーティングエンジン（src/features/model-routing/）は、プロンプトの内容から3種の信号を抽出してモデル tier を決定する。

• レキシカル信号: ワード数、ファイルパス数、キーワード（architecture / debugging / simple）、質問の深度（why / how / what）
• 構造信号: サブタスク数（箇条書きから推定）、クロスファイル依存、影響範囲（local / module / system-wide）
• コンテキスト信号: 過去の失敗回数、会話ターン数、エージェントチェーンの深さ

LOW    → Haiku（低コスト・高速）
MEDIUM → Sonnet（バランス型）
HIGH   → Opus（高精度）

信号の処理はルールエンジンとスコアラーの二段構成だ（rules.ts, scorer.ts）。ルールエンジンは優先度付きで評価し（ユーザー明示指定 → エージェント固有ルール → タスクベースルール → デフォルト MEDIUM の順）、スコアラーは重み付きスコアで独立に判定する。両者の判定が2段階以上乖離した場合は、信頼度を引き下げつつ高い方の tier を採用する設計で、under-provisioning（能力不足のモデルへの割り当て）を回避する。

README では30〜50%のトークンコスト削減を謳っているが、リポジトリ内に計測データはなく、理論的な推定値とみられる。ルーティングロジック自体は精緻に実装されており、定型作業の多いプロジェクトで特に効果が期待できる。

エンタープライズ環境向けには forceInherit モードがあり、Bedrock/Vertex AI 環境やカスタム API ゲートウェイを自動検出して全エージェントが親モデルを継承する（詳細は後述）。

スキルとワークフロー

スキルはスラッシュコマンド形式でユーザーが呼び出す操作単位で、v4.11.5 時点で37種が skills/ ディレクトリに定義されている。各スキルは SKILL.md にプロンプトと動作仕様を記述する形式で、フックシステムと密に連携している。

代表的なスキル

/learner は特徴的なスキルで、セッション中に得られたデバッグパターンや解決手法を .omc/skills/ にスキルファイルとして保存する。保存対象は「Google 検索では見つからない知見」「そのコードベース固有の知識」「デバッグに労力を要した解決手法」の3条件をすべて満たすものに絞られており、プロジェクト固有の暗黙知の蓄積に特化した設計だ。

フックとマジックキーワード

フックシステム（src/hooks/）は OMC の動作基盤で、Stop・PreToolUse・PostToolUse・UserPromptSubmit・PreCompact といったライフサイクルイベントにインターセプトして機能を注入する。v4.11.5 時点で約50のモジュールが内蔵されており、autopilot・ralph・ultrawork・team-pipeline・keyword-detector・learner などの主要機能がフックとして実装されている。

フックの動作は環境変数で制御できる。

DISABLE_OMC=true              # OMC 全体を無効化
OMC_SKIP_HOOKS=keyword-detector,ralph  # 特定フックをスキップ

マジックキーワード機能（src/features/magic-keywords.ts）は、プロンプト中の特定ワードを検出して対応モードを自動起動する。代表的なキーワードを以下に示す（各カテゴリに複数のエイリアスが定義されている）。

検出は多言語対応（日本語・韓国語・中国語・ベトナム語）で、コードブロック内のキーワードは除外される。

ワークフロー: 要件定義 → 実行

スキルは段階的に組み合わせて使うのが OMC の典型的なパターンだ。

ステップ1 — 要件の明確化: /deep-interview

タスクの曖昧な部分を対話的に洗い出し、PRD（要件定義書）を自動生成する。

/deep-interview "認証機能のリファクタリング"

ステップ2 — 実行: /team または /ralph

要件が明確になったら、タスクの性質に応じて実行モードを選ぶ。

# 複数エージェントを並列で起動（executor を3並列）
/team 3:executor "APIエンドポイントの実装"

# 単一エージェントが完了まで verify→fix を繰り返す
/ralph "認証ミドルウェアの修正"

/team は内部で team-plan → team-prd のフェーズを自動実行するため、ユーザーが意識するステップは要件定義と実行の2段階になる。

ステップ3 — 自律実行: /autopilot

上記の流れを自動化した5段階ワークフロー（展開→計画→実行→QA→検証）。人手の介入を最小化したい場合に使う。

/autopilot "テストカバレッジの向上"

Team パイプライン

/team コマンドが起動する Team パイプラインは、OMC のマルチエージェント協調の中核だ（src/team/ に多数の TypeScript ファイルで実装）。

team-verify で問題が検出されれば team-fix に戻るフィードバックループが内蔵されており、/ralph との組み合わせで完了まで永続実行できる。

tmux セッション管理（tmux-session.ts）により、Claude Code だけでなく Codex CLI や Gemini CLI のワーカーを同一 Team 内で起動できる。

# Codex CLI ワーカーを2つ起動して協調
/team 2:codex "テストカバレッジの向上"

セッション名は omc-team-{teamName}-{workerName} で管理され、分割ペインでリアルタイムに状態を確認できる。ただし Codex / Gemini CLI が別途インストールされている必要がある。

可観測性と運用

HUD（ヘッドアップディスプレイ）

マルチエージェントのオーケストレーション状態をリアルタイムでターミナル上に表示する（src/hud/）。コンテキスト使用率・現在のモデル・累積トークン消費量・稼働中のモード（autopilot / ralph / ultrawork 等）・進行中タスクの一覧が一目で確認できる。

通知連携

セッションイベント（開始、終了、アイドル、ask-user-question 等）を外部プラットフォームに転送できる（src/notifications/）。

• Discord: Webhook および Bot API
• Telegram: Bot token + chat ID
• Slack: Webhook および Socket Mode Bot API
• 汎用 Webhook: カスタムエンドポイント

長時間稼働するバッチ処理や夜間実行のタスクで、完了・エラーを通知として受け取る用途に向く。

OpenClaw 統合

セッション中のイベントを OpenClaw ゲートウェイに自動転送する機能もある（src/openclaw/）。session-start / session-end / stop / keyword-detector / ask-user-question / pre-tool-use / post-tool-use の各フックに対応しており、チーム運用時のエージェント行動ログの記録・分析基盤として機能する。

エンタープライズ対応: Bedrock / Vertex AI

OMC は AWS Bedrock と Google Vertex AI の環境を自動検出し、forceInherit モードに切り替わる（src/config/models.ts）。

# 主な検出条件（いずれかが true の場合）
CLAUDE_CODE_USE_BEDROCK=1
CLAUDE_CODE_USE_VERTEX=1
# または: Bedrock ARN 形式、vertex_ai/ プレフィックス、カスタム ANTHROPIC_BASE_URL

forceInherit モードでは、モデルルーティングを無効化して全エージェントが親モデルを継承する。API ゲートウェイ経由で Claude を利用しているエンタープライズ環境でも、OMC のエージェント機能が正しく動作するよう設計されている。

モデルは tier ごとに環境変数で上書きできる。

OMC_MODEL_HIGH=claude-opus-4-6
OMC_MODEL_MEDIUM=claude-sonnet-4-6
OMC_MODEL_LOW=claude-haiku-4-5

導入手順

マーケットプレイス経由（推奨）

# プラグインの追加
/plugin marketplace add https://github.com/Yeachan-Heo/oh-my-claudecode

# 初期設定
/setup

Claude Code のプラグイン機構をそのまま使うため、既存環境との競合リスクが低い。

npm 経由

# グローバルインストール
npm i -g oh-my-claude-sisyphus@latest

# 初期設定
omc setup

npm パッケージ名が oh-my-claude-sisyphus であることに注意。CI 環境やコンテナ内での利用にはこちらが適している。Node.js 20.0.0 以上が必要。

最新の導入手順は 公式 README を参照してほしい。

向いているケース / 向かないケース

向いているケース

• 大規模なタスクやリファクタリング: Team パイプラインで計画→実行→検証の流れを構造化できる
• 複数の役割を同時に回したい場合: 特化エージェントを並列で協調させ、実装・レビュー・テストを同時進行できる
• コスト最適化が重要なプロジェクト: モデルルーティングにより、単純タスクに Haiku、複雑なタスクに Opus を自動割り当て
• エンタープライズ環境: Bedrock / Vertex AI の自動検出と forceInherit モードで、API ゲートウェイ経由の運用にも対応
• 長時間稼働するタスク: Ralph モードと継続強制により、完了まで停止せず実行を持続

向かないケース

• 単発の小さなタスク: 「このバグを直して」程度なら Claude Code を直接使ったほうが早い
• Claude Code 自体に不慣れな段階: OMC は Claude Code の上位レイヤーなので、まず Claude Code 単体での運用に慣れてから導入すべきだ
• 厳密なコスト管理が必要な場合: マルチエージェント構成は並列実行分のトークン消費が増える。ルーティングによる最適化はあるが、単体運用より総コストが上がるケースもある

まとめ

oh-my-claudecode は、Claude Code の「単一エージェントの限界」に対して、フック・MCP・スキルという Claude Code の拡張機構を多層的に活用したアーキテクチャで取り組むプロジェクトだ。

特に際立つのはモデルルーティングの設計で、レキシカル・構造・コンテキストの3種信号にルールエンジンとスコアラーのハイブリッド評価を組み合わせ、タスクの複雑度に応じたモデル選択を自動化する。「どのエージェントで考えるか」と「どのモデルで計算するか」の両方をツール側に委ねられる点は、手動管理のコストが気になるチームにとっての大きな価値になる。

Team パイプラインは plan→prd→exec→verify→fix の5段階構成で、tmux を介して Codex / Gemini CLI との協調実行にも対応している。/deep-interview → /team または /ralph → /autopilot の流れは、要件定義から自律実行まで一貫したワークフローとして機能する。

設計思想の違いや OMX との比較に関心がある場合は、oh-my-claudecode vs oh-my-codex を参照してほしい。

注記（再掲）: 本記事の数値・機能は2026年4月時点の情報に基づく。最新の状況は oh-my-claudecode の README で確認してほしい。

参考リンク

• oh-my-claudecode（GitHub） — 本記事の主題。Claude Code 向けマルチエージェント・オーケストレーション基盤
• oh-my-codex 入門（Qiita） — 姉妹プロジェクト。Codex CLI 向け拡張レイヤーの入門記事
• oh-my-claudecode vs oh-my-codex（Qiita） — 同一作者が異なる設計判断をした理由の分析記事
• oh-my-codex（GitHub） — 姉妹プロジェクトのリポジトリ
• ast-grep（GitHub） — OMC の MCP ツールサーバーが利用する AST パターン検索エンジン
• Claude Agent SDK（npm） — OMC の基盤となる Claude Code 向けエージェント SDK