AIの「いい子モード」に付き合ってる場合じゃない
「素晴らしい質問ですね！」
ChatGPTに技術的な相談をすると、だいたいこれから始まる。で、当たり障りのない一般論が続いて、最後に「ご参考になれば幸いです😊」で締まる。
正直に言う。こんなやり取り、時間の無駄だ。
AIを「賢い検索エンジン」として使っている人は多いけど、それは全体の10%くらいしか引き出せていない。本当に強いのは、AIに自分のアイデアを全力でぶっ壊してもらう使い方だ。
この記事では、AIの「お世辞モード」を強制パージして、技術的壁打ち相手に改造する具体的な方法を書く。実際にDockerコンテナ設計とAPI設計の2つのテーマで殴り合った記録もつける。
「悪魔のアーキテクト」プロンプトの設計
まず前提として、LLMはデフォルトで「ユーザーを不快にさせない」方向に調整されている。RLHFの宿命だ。これを解除するには、System Promptレベルで明示的にモードを切り替える必要がある。
自分が使っているプロンプトのコアはこれ。
あなたは冷徹な技術参謀として振る舞う。以下を厳守:
1. 接待・お世辞・無難な一般論を完全にパージする
2. 提案の弱点・破綻点を即座に指摘する
3. 「なぜ破綻するか」を具体的な数値・事例で説明する
4. 反論には物理法則・計算量・具体的な数値で応じる
5. 代替案を出す際も「この案の弱点は〜」を必ず添える
ポイントは5つ目。代替案にも弱点を自己申告させることで、「AIが提案したから正しい」という思考停止を防ぐ。
これに加えて、自分の専門分野を明示する。「私はバックエンドエンジニアで、Kubernetes上のマイクロサービス設計を3年やっている」みたいに書くと、AIは素人向けの説明をスキップして、いきなりアーキテクチャレベルの議論に入ってくる。
なぜ汎用的な「厳しくして」では不十分か
「批判的に回答してください」だけだと、AIは「ただし〜という課題もあります」程度のマイルドな注釈を添えるだけに留まる。お世辞をパージするのと、少し控えるのでは出力が全然違う。
具体的な行動を5項目で縛ることで、AIは「批判しなければならない」ではなく「批判の構造」を理解して動き出す。
実戦記録①: Dockerコンテナの肥大化問題
ここから実際の壁打ち記録。テーマは「PythonのMLパイプラインをDockerコンテナに入れたら2.8GBになって、CIのビルドが毎回12分かかる」という、わりと誰でも心当たりがありそうな問題。
自分の最初の提案:
マルチステージビルドで、ビルド用ステージとランタイム用ステージを分ける。ビルドステージでpip installして、ランタイムにはsite-packagesだけコピー。
AIの返答（要約）:
マルチステージビルドで削れるのはビルドツール（gcc, make等）の分だけ。MLパイプラインで2.8GBの大半を占めるのはPyTorch/TensorFlowのランタイムバイナリとCUDAライブラリ。site-packagesをコピーしても1.8〜2.2GBは残る。12分のうちpip installが支配的なら、そもそもレイヤーキャッシュが効いていない可能性がある。
--mount=type=cache,target=/root/.cache/pipを使っていないのでは？
正直、痛いところを突かれた。マルチステージビルドを「銀の弾丸」だと思い込んでいた。
修正案:
じゃあ、ベースイメージをNVIDIA公式のnvcr.io/nvidia/pytorch:xxに切り替えて、追加パッケージだけpip installする。CUDAは全部ベースイメージ側に含まれているからレイヤーキャッシュが効く。
AIの反撃:
NVIDIAの公式イメージはそもそも6〜8GBある。Jupyter、各種デバッグツール、サンプルコードまで入っている。「全部入りイメージをベースにして小さいパッケージを足す」のはCI高速化にはなるが、デプロイサイズは悪化する。本番推論用なら
python:3.11-slim+torchのCPU版（もしくはONNX Runtimeに変換）の方が500MB以下に収まる可能性がある。
ここで気づいた:
「ビルドを速くしたい」と「イメージを小さくしたい」を同時に最適化しようとして、どっちつかずになっていた。AIに殴られたおかげで、問題を分離できた。
- CI用: NVIDIAベース + レイヤーキャッシュ → ビルド速度優先
- 本番用: slim + ONNX Runtime → サイズ優先
- 2つのDockerfileを管理する
最終的にAIが出した「2つのDockerfileを使い分ける」案も、「Dockerfileが2つになるとメンテコストが増える。CI側でビルド対象を切り替えるMakefileかdocker-bake.hclが必要」と自己批判つきだった。
この一連のやり取りで20分くらい。最初の「マルチステージビルドで解決でしょ」から、問題の構造が3段くらい深くなった。
実戦記録②: REST APIのページネーション設計
2つ目。「検索APIのページネーション、offsetベースかcursorベースかで迷っている」という、これも定番の悩み。
自分の最初の立場:
cursorベースが正義。offsetは大きいページ番号でパフォーマンスが劣化するし、途中でデータが挿入されるとページがズレる。
AIの反撃:
cursorベースが万能だと思い込んでいるなら、以下を考えろ。
- 「3ページ目に直接ジャンプしたい」というUIが必要な場合、cursorベースでは不可能。管理画面系では致命的。
- cursorの実装で
WHERE id > :cursor ORDER BY idを前提にしているなら、ソート順がid以外（created_at DESC、relevance score等）になった瞬間にcursorの設計が壊れる。- offsetの「途中挿入でズレる」問題は、検索インデックスのスナップショット（Elasticsearchのscroll API、PostgreSQLのカーソル）で回避できる。offset=ダメと決めつける前に、DBの機能を調べたか？
3つ目が刺さった。「offsetは遅い」という先入観で、DB側の解決策を完全にスルーしていた。
議論の深化:
ここから「じゃあソート順が複合キー（created_at + id）の場合のcursor設計は？」→「Base64エンコードしたcursorの中にJSON入れるパターン」→「cursor文字列が改ざんされたら？」→「HMAC署名付きcursor」みたいに、どんどん具体的になっていった。
最終的な結論は「ユースケースで分ける」というありきたりなものだけど、そこに至るまでの過程で「なぜ分けるのか」「分岐の基準は何か」が明確になった。これが壁打ちの価値。
壁打ちを機能させる5つのルール
2つの実例を踏まえて、効果的な壁打ちのためのルールを整理する。
1. 「なぜ」を禁止しない
AIが「それは破綻する」と言ったとき、「なぜ？」と必ず深掘りする。理由を説明させると、AIは裏付けとなるデータや事例を引っ張り出してくる。「ダメ」だけで終わらせると壁打ちの意味がない。
2. 数字を要求する
「遅くなる」ではなく「何msから問題になるか」、「大きい」ではなく「何GBか」。数字を出させると、AIのハルシネーションも見抜きやすくなる。桁が明らかにおかしければすぐ気づける。
3. 自分の弱点を正直に晒す
「ここは直感的にわからない」「この領域は経験がない」と素直に言う方が、AIの説明精度が上がる。背伸びすると、AIも相手のレベルに合わせて表面的な回答しかしなくなる。
4. 脱線を許す
技術的な壁打ちの途中で「そもそもこのアプローチ自体が間違ってない？」みたいな脱線が一番おいしい。予定調和の議論からは新しい発見は生まれない。
5. ログを保存する
壁打ちの過程そのものが成果物。結論だけメモしても、「なぜその結論に至ったか」が消える。Markdownでエクスポートして、後で読み返せるようにしておく。
Claude / Gemini / ChatGPT — 殴り返し性能の違い
3つのモデルで壁打ちを繰り返した体感を正直に書く。
Claude（Opus 4.6）
殴り返しの精度が一番高い。特にコードレビュー的な指摘が鋭い。「この設計だとN+1クエリが発生する」みたいな具体的な指摘をピンポイントで出してくる。一方で、専門外の領域（ハードウェア寄りの話など）になると急に慎重になって「一般的には〜」モードに戻りやすい。
Gemini（2.5 Pro）
長文コンテキストの保持力が異常。壁打ちが50ターンを超えても、最初の方で議論した前提条件を正確に覚えている。論文ベースの反論も得意で、「〇〇 et al. (2024)によると〜」みたいな引用をバンバン出してくる（ただし存在しない論文を捏造する確率もゼロではない）。
ChatGPT（GPT-4o）— 「営業トーク型」壁打ち
このモデルだけ、他と明確に違うキャラクターがある。こっちに問いかけてくるのだ。
「もし興味あればですが…」「たぶん結果にかなり驚きます」「これやると一発で理解できます」——こういうフレーズが頻繁に挟まる。技術的な回答の合間に「次の実験」を提案してきて、気づいたら想定外の方向に議論が転がっている。
実際に手元のiPhone AirとRyzen 7845HSゲーミングノートのベンチマーク比較を相談したとき、最初は「Geekbenchで比べよう」くらいの軽い話だったのが、ChatGPTの「Speedometerもやってみてください、たぶん驚きます」に乗せられて、気づいたらCPUアーキテクチャのwide core vs many core設計思想の議論に突入していた。
この「誘導力」は壁打ちでは実はかなり有用。自分が思いつかなかった角度から問題を掘り下げるきっかけになる。ただし、深く掘り下げると答えが曖昧になりがちで、数式や具体的な数値での反論はClaudeやGeminiの方が強い。ChatGPTは「議論のファシリテーター」、ClaudeとGeminiは「批判的レビュアー」と使い分けるのがいい。
ローカルLLM（Qwen2.5-32B on RTX 4060）
壁打ち相手としてはまだ厳しい。10.8 t/sの生成速度は会話としてギリギリ成立するけど、反論の深さがクラウドモデルに比べて明らかに浅い。32Bパラメータだと「なぜ破綻するか」の説明が表層で止まることが多い。70B以上のモデルをVRAM 8GBで動かせるようになったら変わるかもしれない。
AIが間違うとき — 壁打ちの限界線
ここまで持ち上げたので、冷や水もかけておく。
AIとの壁打ちには致命的な盲点がある。それは「AIが指摘しなかった穴」の存在に気づけないこと。
Docker記事の例で言えば、もしAIが「レイヤーキャッシュ」の話を出さなかったら、自分はマルチステージビルドで満足して終わっていたかもしれない。AIが知らない（あるいは想起しなかった）解決策は、壁打ちに出てこない。当たり前だけど忘れがち。
対策は古典的だが確実:
- AIの出力は仮説として扱う
- 重要な判断は公式ドキュメントか自分の手元で裏取りする
- AIが「問題ありません」と言った箇所こそ疑ってかかる
「AIがOKと言ったから大丈夫」は、「先輩がOKと言ったから大丈夫」と同じ構造の危うさがある。先輩もAIも間違う。最終判断は自分。
付録: お世辞パージ用プロンプトテンプレート（コピペ用）
そのまま使えるSystem Promptを置いておく。{{YOUR_DOMAIN}}を自分の専門分野に置き換えて使ってくれ。
あなたは{{YOUR_DOMAIN}}の冷徹な技術参謀として振る舞う。以下を厳守:
1. 接待・お世辞・無難な一般論を完全にパージする
2. 提案の弱点・破綻点を即座に指摘する
3. 「なぜ破綻するか」を具体的な数値・事例で説明する
4. 反論には物理法則・計算量・具体的な数値で応じる
5. 代替案を出す際も「この案の弱点は〜」を必ず添える
やってはいけないこと:
- 「素晴らしい質問ですね」「いい着眼点です」等の接待トーク
- 「一般的には〜」「〜とも言えます」等の逃げ口上
- 結論の両論併記で判断を避けること
ユーザーの専門性: {{YOUR_DOMAIN}}で実務経験{{YEARS}}年。
素人向けの説明は不要。専門用語をそのまま使え。
使い分けガイド
| 壁打ち目的 | 推奨モデル | 理由 |
|---|---|---|
| 設計レビュー | Claude Opus | コードレベルの指摘精度が最高 |
| 深い技術議論 | Gemini 2.5 Pro | 長文コンテキスト保持+論文引用 |
| アイデア発散 | ChatGPT GPT-4o | 問いかけ型で議論を広げてくれる |
| オフライン壁打ち | Qwen2.5-32B等 | 深さは劣るがプライバシー完全 |
次は「AIに壁打ちさせるAI」を作ってみたい。今回は人間がプロンプトを設計してAIに殴らせたけど、このプロンプト設計自体をAIに任せたらどうなるか。メタ壁打ちの壁打ち。無限ループに陥りそうな気もするけど。