AIコーディングの本当のボトルネックはどこにあるか
「AIに頼んだのに見当違いのものを作ってきた」という不満は、たいていモデル性能の問題ではありません。何を作るかが最初から曖昧なため、モデルは空白を自分の推測で埋めます。仕様の曖昧さが、そのまま成果物のばらつきにつながります。
だからモデルをより良いものに替えることよりも、曖昧さを減らし完成を強制するワークフローを設計することが、実務ではより大きな差を生みます。oh-my-claudecode(OMC)はClaude Codeに複数の専門エージェントを重ね、このワークフローを道具として固めたオーケストレーション層です。
deep-interviewは曖昧さをどう取り除くか
deep-interviewはいきなりコードへ走りません。ソクラテス式に一度に一つずつ問い、毎回もっとも弱い部分を選んで掘り下げ、隠れた前提を露わにします。
肝心なのは、曖昧さを次元ごとに点数化する点です。その値が定めた基準を下回るまで、実行そのものを拒みます。「それではない」という事後修正のコストを、質問の段階に前倒しして食い止める仕組みです。
ralplanは計画をどう検証するか
何を作るかが明確になったらralplanへ進みます。プランナーが草案を作り、アーキテクトがその設計に反論し、批評役が品質基準で改めて精査します。
この合意ループは、批評役が合格判定を出すまで繰り返されます。一人で立てた計画には必ず死角が生じますが、異なる視点のエージェントが実行前にその隙間を埋めます。
ralphは完了をどう保証するか
最後はralphです。原則は「ベストを尽くせ」ではなく「終わるまで」です。作業を検証可能な単位に分け、すべての単位が通り、レビュアーの承認が出るまで止まりません。
この構造はAI作業でよくある自己欺瞞を防ぎます。一部だけ作って完了を宣言したり、通すためにテストを消したりすることです。検証を完了の条件として組み込めば、「できた」という言葉の信頼性が上がります。
三つの段階をつなぐと何が変わるか
deep-interviewで何を作るか、ralplanでどう作るか、ralphで最後まで作り切る。三つの段階が一本のパイプラインにつながると、同じ依頼でも成果物のばらつきが大きく減ります。
企業のAXも同じ原理です。より賢いモデルを待つより、曖昧さを取り除き完成を強制する手順を先に整えるほうが、実際の成果物の質を引き上げます。道具が良い習慣を代わりに強制してくれるわけです。