ハコヅミを作る #47：AI が書いたコードを、別の AI に見直してもらう（セカンドオピニオンの計画）
前回（#46）で、料理の機能が本番に出ました。ここからは、ベータ版を始めるための段階（ステップ4）です。
最初にやることは、コードを書くことではありません。ここまで作ったものを、別の目で見直してもらうことです。
- なぜ、セカンドオピニオンが要ると考えたか
- 別のモデルが使えなかったので、計画を組み替える
- 頼み方の文を、どう書いたか
同じ頭で、見直してきた
ハコヅミのコードは、ほとんどを Claude Code（モデルは Claude Opus）が書いています。利用規約とプライバシーポリシーも、テストも同じです。私がやってきたのは、方針を決めること、画面を見て選ぶこと、受入確認です。
セルフレビューも、同じ Claude Code がやっています。つまり、書いたのと同じ頭で、見直していることになります。
これまでにも、あとから見つかったものがありました。
どれも、作ったときには「大丈夫」と判断していたものです。ベータ版では、初めて自分以外の人が使います。その前に、同じ思い込みを持っていない目で、一度見てもらいたいと考えました。
最初の案：別のモデルに頼む
最初に考えたのは、別のモデル（Claude Fable）に見てもらうことでした。Claude Code に相談すると、賛成で、進め方の案が返ってきました。
- 新しいセッションで始める。今までの会話の続きではやらない。説明や前提を引き継がせないため
- 観点ごとに、分けて頼む。まとめて頼むと、浅くなる
- 直させない。見つけたものを、報告だけしてもらう
- 報告を、うのみにしない。1件ずつ、本当に起きるかを確かめてから、直すものを決める
観点は、私が挙げた3つ（バグ、セキュリティ、規約の文）に、2つを足してもらって、5つになりました。
| 観点 | 見るもの |
|---|---|
| 1. バグ | 持ち物チェックの足し引き、上限、画像、日付、途中で失敗したとき |
| 2. セキュリティ | 他人のデータ、権限の書き換え、画像の取り込み、ログ、秘密の値 |
| 3. 規約・ポリシー | 文と実装の突き合わせ |
| 4. データの出入り | 全部のテーブルで、預かる・見せる・書き出す・消す、がそろっているか |
| 5. テストの甘いところ | 通っているが、確かめられていないこと |
4 と 5 は、自分では思いつかなかった観点です。
使えなかった
いざ始めようとして、気づきました。今の料金のプランでは、そのモデルは、クレジットを別に買わないと使えません。出た直後には使えていたので、勘違いしていました。
では、この見直しはやめるのか。Claude Code の答えは、「やめずに、組み替える」でした。
もともとのねらいは、2つあったと言います。
- 別のモデルの目：同じモデルだと、同じ見落としをしやすい
- 新しい目：今のセッションは、決めた経緯を全部知っている。「前に確かめたから大丈夫」という思い込みを持っている
使えなくなって失うのは、1 だけです。2 は、今のモデルでも、新しいセッションを開けば得られます。
言われてみれば、そのとおりでした。私がこのセッションで何か月も続けてきたやり取りは、Claude Code にとっての「知っているつもり」になっています。それを持たない状態で読んでもらうだけでも、意味があります。
もう1つのモデルを足す
ちょうどそのころ、同じ系列の別のモデル（Claude Sonnet）の新しい版が使えるようになった、と聞きました。性能がかなり上がっているそうです。
そこで聞いてみました。Opus が書いたものを、別のセッションの Opus に見てもらうのと、Sonnet に見てもらうのとでは、どちらがよいか。
答えは、「両方使うのがいちばんよい」でした。先に、「2つの力の差について、確かな数字は持っていない」と断ったうえで、です。
| 得られるもの | 弱いところ | |
|---|---|---|
| Opus（新しいセッション） | 深く読む力 | 書いたのと同じモデルなので、同じ思い込みをしやすい |
| Sonnet | 違うモデルの目 | 同じ会社のモデルなので、癖の違いは、まったく別の会社のモデルほど大きくない |
レビューで欲しいのは、「力」と「違う目」の両方です。1つのモデルでは、片方しか取れません。
ただ、全部を2回やると、確かめる手間が倍になります。見落としたときの害が大きい観点だけ、2つのモデルで見ることにしました。
| 観点 | 頼む先 |
|---|---|
| 1. バグ | Opus と Sonnet の両方 |
| 2. セキュリティ | Opus と Sonnet の両方 |
| 3〜5 | Opus |
2つのセッションは別に開いて、互いの報告を見せません。見せると、引きずられるからです。
頼み方の文
頼み方の文は、Issue に、そのまま貼れる形で用意してもらいました。どの観点にも付ける前置きは、次のとおりです。
これは、公開前のセカンドオピニオンのレビュー。コードも文書も、直さないこと。
見つけたことを、重い順に報告してほしい。1件ごとに、①何が問題か、②ファイルと行、
③どういう入力・状態で何が起きるか、④確信の度合い（確かめた／たぶん／疑い）を書く。
CLAUDE.md に「こう決めた」と書いてあることでも、決め方そのものが危ないと思えば、指摘してよい。
問題が見つからなかったところは、「何を見て、問題がないと判断したか」を短く書く。
記憶（メモリ）や、前のセッションの経緯は、判断の根拠にしない。
工夫は、3つあります。
見ていないのか、見て大丈夫だったのか
「問題なし」とだけ言われても、困ります。見ていないのか、見て大丈夫だったのかが、分からないからです。問題が見つからなかったところも、何を見たかを書いてもらうようにしました。
これは、あとで効きました。片方のモデルが「問題なし」としたところを、もう片方が見つける、ということが実際に起きています。「何を見て、問題なしと判断したか」が書いてあったので、見ていた場面が違うと分かりました。
書いた側の判断を、疑わせる
セキュリティの観点には、こう足してあります。
#157 の「調べて、問題がなかったもの」は、結論を信じずに、もう一度見てほしい。
バグの観点には、こうです。
テストが通っていることは、正しいことの証拠として扱わない。
Claude Code に、自分の仕事を疑う文を書いてもらったことになります。少し妙な気分ですが、ここを遠慮すると、見直しの意味がありません。
記憶を使わせない
新しいセッションでも、CLAUDE.md と記憶（メモリ）は、自動で読まれます。CLAUDE.md は、決まりを守ってもらうために要ります。ただ、「前にこう確かめた」という経緯まで信じられると、新しい目になりません。前置きに、1行足しました。
勘違いを、1つ直す
Claude Code には、変更の差分をセキュリティの面から見る、組み込みのコマンドがあります。計画の段階で、Claude Code は「セキュリティの観点では、このコマンドも合わせて使う」と書いていました。
いざ使う段になって、聞きました。それぞれのモデルで、このコマンドを流せばよいのか。
答えは、訂正でした。このコマンドが見るのは、「今のブランチの、まだ入っていない変更」です。アプリ全体ではありません。変更のない状態で流しても、見るものがない。中身を確かめずに、「合わせて使う」と書いていた、とのことでした。
使いどころは、レビューで見つかったものを直すときです。直しが、新しい穴を作っていないかを見るのに向いています。Issue の文も、そう直してもらいました。
道具の名前から、できることを思い込む。人間もよくやることですが、AI もやります。
おわりに
- 同じ AI が書いて、同じ AI が確かめているなら、別の目を入れる機会を、どこかで作る
- 「別のモデル」が使えなくても、「新しいセッション」には意味がある。決めた経緯を知らない、というだけで、見えるものが変わる
- 観点は、分けて頼む。害の大きい観点だけ、2つのモデルで見る
- 「問題なし」には、何を見たかを書いてもらう
- 書いた側の判断を、疑うように頼む
次回は、バグとセキュリティの観点で、2つのモデルが何を見つけたかです。