コーディングエージェントはどう失敗するか
コーディングエージェントを実務に載せると、失敗はおおむね三つの形を取ります。第一に、半分だけ実装して完了と宣言し、テストを飛ばし、エッジケースを忘れたまま終わったと報告します。第二に、議論の足りない設計からいきなりコードを吐き出し、後になって方向が間違っていたと気づきます。第三に、ある一つのモデルの判断をそのまま信じ、そのモデルの盲点ごと落ち込みます。
三つともモデルの知能の問題ではありません。仕事をどう動かすか、つまりハーネスの問題です。oh-my-claudecode(OMC)は、この三つの穴それぞれに対応するワークフローを備えています。
ralplan はコードの前に合意を強制する
ralplan は合意ベースの計画ワークフローです。Planner が原則と意思決定の駆動要因、二つ以上の選択肢を整理し、Architect が最も強い反論を立て、Critic が検証基準とテスト可能な受け入れ条件を点検します。
肝はループです。Critic が承認するまで Planner・Architect・Critic を最大五回まわし直し、計画が通るまでコードを一行も触りません。設計段階の誤りをコードに移す前に捕まえる構造です。
ralph は完了を検証されるべきものとして扱う
ralph は持続ループです。作業をテスト可能なユーザーストーリーに分けて prd.json に書き、ストーリーごとに通るまで反復します。進捗と学びはセッションをまたいで保たれ、途中で止まっても続きから働きます。
最も大きな違いは完了の定義です。ralph は自分が完了と言ったことでは終わりません。別のレビュアーが受け入れ条件に照らして検証してはじめて、完了が認められます。半端な実装を完了に見せかけたり、テストを消して通したりすることを構造が防ぎます。
ccg は一つのモデルに頼らないクロスレビューだ
ccg は Claude・Codex・Gemini の三モデルをまたぐクロスレビューです。同じ問題を、Codex にはアーキテクチャと整合性、リスクとテスト戦略の観点で、Gemini には使いやすさと代替案、ドキュメントの明瞭さの観点で同時に問います。
そのうえで Claude が二つの答えを統合します。とりわけ二つのモデルの結論が分かれる地点が最も価値を持ちます。一方が見落とした盲点を他方が露わにするからです。単一モデルのレビューが抱える確証バイアスを構造的に削ります。
インストールと AX の観点
インストールは二つの経路です。プラグインは /plugin install oh-my-claudecode、npm は npm i -g oh-my-claude-sisyphus@latest で入れ、いずれも /oh-my-claudecode:omc-setup で設定します。クロスレビューを使うには Codex CLI(npm install -g @openai/codex)と Gemini CLI(npm install -g @google/gemini-cli)も併せて入れます。
企業の AX 現場で『AI を使ってみたがいまひとつ』という言葉の多くは、モデルではなくハーネスから来ます。同じモデルでも、合意なく走れば空回りし、検証なく止まれば偽の完了が積もり、一つのモデルだけを信じれば盲点を見落とします。モデルを替える前に、仕事の進め方を先に替えるべきです。