【インフラ設計×Claude #3】同じ問いなのに、AIの結論が正反対になった ― Claudeと進めた設計の手戻り記録
はじめに
前回までのおさらい
第1回では、IPAの非機能要求グレード238項目を、72項目の非機能要件に整理した話を書きました。第2回では、そこから構成方針書とADRを、「今守ること」と「なぜそうしたか」に分けて設計した流れを書きました。
【インフラ設計×Claude #1】非機能要件をClaudeと策定する
【インフラ設計×Claude #2】その設計、「なぜ」を残していますか？ ― 構成方針書とADRの分け方
最終回の今回は、同じ論点を2つのツールに聞いたら結論が正反対になった話を中心に、Claudeをどう使い分けたか、レビューで見つかった抜けを書きます。
- 第1回：非機能要件をClaudeと策定する
- 第2回：その設計、「なぜ」を残していますか？ ― 構成方針書とADRの分け方
- 第3回（本記事）：同じ問いなのに、AIの結論が正反対になった ― Claudeと進めた設計の手戻り記録
設計ドキュメントの作成にAIを使いたい方に向けて、失敗談を中心に書きます。顧客を特定できる情報は伏せ、案件固有の内容は一般化しています。
うまくいかなかったこと
同じ論点を2つのツールに聞いたら、結論が正反対になった
設計の判断を確かめるため、同じ論点を2つのツールに聞きました。論点は、証明書を作成できるリージョンです。一方は「国内のリージョンでも作成できる」と答え、もう一方は「特定の海外リージョンでしか作成できない」と答えました。結論が正反対になったのです。
調べてみると、原因は、前提の違いでした。ロードバランサーで使う証明書は、ロードバランサーと同じリージョンで作成します。一方、CDNで使う証明書は、公式ドキュメントで確認すると、特定の海外リージョンで作成する必要がありました。どちらのサービスの話なのかという前提が、回答ごとにそろっていなかったのです。
同じ問いでも、前提が違えば、結論は反転します。この件以降は、結論が割れたら「どちらが正しいか」ではなく、「どの前提が違ったか」に戻ることにしました。事実と重み付けを分けて出させると、前提の違いが見つけやすくなります。
学び①：AIの回答は「前提」によって回答が変わることを理解する。その前提が自分が意図しているものかを自身で確認する。
AIの回答は、言い過ぎることがある
別のクラウドへ移行する場合の懸念を、AIに洗い出させました。すると、実際より厳しい評価が、多く含まれていました。たとえば、移行元のサービスと同じ名前の機能が、移行先で見つからないという理由だけで、「移行先には相当する機能がない」と判断していました。公式ドキュメントで確認すると、名前が違うだけで同じ機能が提供されていたり、複数のサービスの組み合わせで実現できたりしました。この経験から、AIが「ない」「できない」と答えたときは、「本当ですか？」と問い返すようになりました。
移行の懸念に限らず、構成の検討でも、同じことが起きました。クラウドのあるサービスを使えば、ある機能が実現できる、とAIは当初説明しました。しかし、公式ドキュメントを確認すると、実現できないことが分かった、ということが、何度かありました。
学び②：AIが「できる」、もしくは「できない」と答えたときは、「本当ですか？」と問い返し、自身も公式の資料で確認する。
Claudeの使い方
役割分担：Claude DesktopとClaude Code
タスクの種類で、使うClaudeを分けました。要件定義や、Microsoft Office（ExcelやPower Point）を使うタスクは、Claude Desktopで行いました。gitを直接操作するタスクは、Claude Codeで行いました。Claude Codeは、ブランチの作成、コミット、PRの作成といったgit操作を、直接実行できるためです。
| 使ったもの | やったこと |
|---|---|
| Claude Desktop | 要件定義、Excelを使うタスク |
| Claude Code | gitを直接操作するタスク（ブランチ、コミット、PR） |
作業の分け方と、頼み方
- 分割単位：1項目につき1ファイル。リポジトリ全体では「1ブランチ＝1PR＝1つの意味合い」にする。粒度を小さくすると、レビューする人が「何を見ればいいか」で迷わない。
- 整合性チェック：構成方針書と非機能要件の食い違いの洗い出しを、Claudeに頼んだ。
- 文体のルール：1文を30〜50字にする、硬い言い回しを日常語にする、などのルールを、設定ファイルに書いた。人が毎回指示しなくても、書き方がそろう。
構成方針書とADRを組にして、1項目1PRで作成し、レビューは、PRのコメントで進めました。
まとめ
経験から学んだ教訓
- AIの回答は「前提」によって回答が変わることを理解する。その前提が自分が意図しているものかを自身で確認する。
- AIの「できる」「できない」は、自分自身で公式の資料で再確認する。
- AIを利用することで格段に開発のスピードが上がったが、最終的な責任は人間にあるため、AIを過信せず自身でも事実を再確認する。
今後の展望
シリーズでお伝えしてきた、非機能要件と構成方針書をもとに、AIがどこまで忠実に実装してくれるのかを確認したいです。きっと要件定義や設計とは異なる課題が現れるはずです。
この連載が、設計ドキュメントをAIと一緒に作ろうとしている方の、参考になれば嬉しいです。
