【AI二人体制ができるまで #2】Claude Codeが作り、Codexが疑う。AI二人体制を始めます

どうも〜さとあつです😄

先日、Claude Codeが突然動かなくなって、俺の仕事も見事に止まりました。

いや、本当に困りましたよ。

月曜日の朝から、会社で一番優秀な社員が突然出社拒否。

しかも俺、そいつがいないと開発が進められない（笑）

・・・

・・・・・・・

いや、笑えないんですけどね💦

（このへんの顛末は、前回の記事に書きました）

そこで急きょ、ほとんど触っていなかったCodexを使い始めました。

最初は完全に、Claude Codeが休んだときの代わり。

いわゆる予備要員として考えていました。

でもね。

触りながら、ふと思ったんです。

あれ？

こいつ、代わりに開発させるだけじゃなくて。

Claude Codeが作ったものを、チェックさせたらいいんじゃないか？？と。

自分で作って、自分でチェックする。の限界

Claude Codeは優秀なんです。

本当に優秀。

設計を考えて、コードを書いて、機能を足して、エラーも直す。

ここまで、ほぼ一貫して任せられる。

でも、優秀だからといって、自分で作ったものを、自分で完璧にチェックできるとは限らない。

人間だってそうじゃないですか。

自分で書いたブログの誤字、何回読み返しても気づかないのに、他人が読むと一瞬で見つかる（笑）

システム開発も、たぶん同じなんですよ。

同じAIが、最初から最後まで担当すると、

最初に立てた前提。

自分で決めた設計。

自分で選んだ実装。

これを「正しいもの」と思い込んだまま、レビューしてしまう。

Claude Codeの中では、最初に考えた前提が、正しいことになっている。

だから、その前提自体が間違ってても、最後まで気づかないかもしれない。

だったら。

何も知らないCodexに、第三者として見てもらえばいい。

Claude Codeが作る。Codexが疑う。俺が決める。

この形、かなり良いんじゃないかと思ってます。

人間の会社に例えると、こうです。

Claude Codeは、実装を進める優秀な開発担当。仕様を理解して、コードを書いて、エラーも直す。

Codexには、品質管理・第三者レビューを担当してもらう。

Claude Codeが、

これで完成です

と言ったあとに、Codexが別の視点から、

「いや、この処理はエラー時の考慮がありません」
「この条件だとデータが消える可能性があります」
「仕様上、必要な機能が一つ抜けています」
「この権限設定は危険です」

と確認する。

そして、どの指摘を採用するかは、俺が決める。

会社でも、

作る人。

確認する人。

最終判断する責任者。

を分けますよね。

AI開発でも、同じ体制を作ろうとしてる、ってだけの話です。

ちょうどいい機能があった。Codexの /review

で、調べたら、Codexにはちょうどいい機能がありました。

対象のプロジェクトでCodexを起動して、

/review

と打つと、何をレビューするか選べます。

・未コミットの変更を見る
・基準ブランチとの差分を見る
・特定のコミットを見る
・独自のレビュー観点を指定する

このあたりから選ぶ感じ。

いいなと思ったのが、この /review、勝手にコードを書き換えないんですよ。

専用のレビュアーとして差分を読んで、問題を重要度順に報告するだけ。作業中のファイルには手を出さない。

だから、

まずCodexに問題点だけ出してもらう。その指摘を俺が確認する。そのうえで、直すかどうかを決めて、Claude CodeかCodexに修正を頼む。

という流れがきれいに作れる。

ただし、ここは正直に書いときます。

/review を一回やったら、システムが全部安全になる、わけじゃない。差分を見るレビューなので、変更してない既存コードや、仕様書に書いてない業務上の抜けは、見逃すこともある。

だから、これだけで終わりにはしません。ブラウザで実際に動かして、データを見て、権限を確認して、最後は顧客にも触ってもらう。そこは今まで通りやります。

大事なのは、前提を引き継がせないこと

ここ、地味だけど一番大事だと思ってます。

Codexにレビューさせるとき、Claude Codeがどんな会話をして、どういう理由で、どんな実装をしたか。

その前提を、必要以上に渡さない。

Claude Codeの思考や言い訳までCodexに共有すると、Codexまで同じ前提に引っ張られるんですよ。

だからCodexには、

・仕様書
・完成条件
・今のコード
・変更した差分
・確認してほしい観点

これだけ渡す。

そのうえで、初めてこのシステムを見る第三者として見てもらう。

聞き方も変えます。

「Claude Codeがこう考えて作りました。この実装で合ってますよね？」

とは聞かない。

これだと、ただの答え合わせになる。

そうじゃなくて、

「この実装を独立した立場で確認して、重大な欠落や危険性を、重要度順に出してください」

という姿勢で使う。

見てもらう観点も、案件によって変えます。たとえば、認証や権限、秘密情報まわりを重点的に、とか。データが消えたり壊れたりしないか重点的に、とか。仕様書と実装がズレてないか、顧客の業務で困らないか、とか。

同じシステムでも、どの目で見るかで、出てくる指摘が変わるんですよね。

でも、Codexも鵜呑みにしない

勘違いしてほしくないのは、

CodexがClaude Codeより正しい、

って話じゃないってこと。

Codexも普通に間違えます。

ありもしない問題を指摘することもある。どうでもいい細かい点を大量に出すこともある。仕様を分かってなくて、一般論だけで言ってくることもある。

だから、

Claude Codeの回答も鵜呑みにしない。

Codexのレビューも鵜呑みにしない。

両方の意見を見て、仕様と、顧客の要望と、実際の動きと照らし合わせて、最後は人間が判断する。

これ、AIを2つ使うことで、人間の判断がいらなくなる、って話じゃないんですよ。

むしろ逆で。

複数のAIの意見をまとめて判断する、AIを監督する力が、さらにいる。

俺がずっと言ってる、AIは便利な道具だけど監督は人間がやれ、ってやつです。作れることと、ちゃんと仕事で使えることは別、っていう話とも地続きだなと思ってます（このへんは前に書いたAIで作れても稼げない、の話とか、それ自社でやれば、の話、受注した学習アプリを作った話につながってます）。

Claude Code障害を、怪我の功名にしてやる

正直、Claude Codeが止まった日は、本当に困りました。

でも、そのおかげでCodexを触り始めて、予備要員のつもりだったこいつに、第三者レビュー担当っていう役職を見つけた。

これまでは、一人の、めちゃくちゃ優秀なAIに、多くを任せてた。

これからは、

Claude Codeが実装する。

Codexが別の視点から疑う。

俺が両方の意見を見て判断する。

直したら、もう一回レビューする。

この体制で、お客さんに納めるシステムの品質を、もう一段上げたい。

もちろん、AIを二つ使えば完璧、なんてことはないです。

最後は実際に動かして、データを見て、顧客に触ってもらって、人間が責任を持って判断する。

そこは変わらない。

でも、一人のAIに作らせて終わり、よりは、明らかに強い開発体制になるはず。

一人の万能社員に全部任せる時代から、役割の違うAIをチームで使って、人間が監督する時代へ。

Claude Code障害は、災難でした。

でも、これを本当の意味で、怪我の功名にしてやろうと思います。

うちは、こういう「AIをどう開発や業務に組み込むか」も含めて、業務ツールづくりからシステム開発、AI導入の伴走までやってます。作って終わりじゃなく、品質とか運用のところまで一緒に考えたい人は、XのDMから気軽にどうぞ。

今日も最後まで読んでくれて、ありがとうございました😄