Claudeに「スクレイパーを堅牢にして」と依頼したところ、200行のそれらしいコードが生成された。リトライロジック、ログ設定、ページネーション処理——すべて揃っている。だが、すべてがゴミだった。リトライロジックはコードベースと異なるパターンを使い、ログ設定はグローバルで他のモジュールを破壊し、ページネーションには最大ページ数の制限がなく無限ループの罠が仕込まれていた。コードはプロフェッショナルに見えた。軽いレビューなら通っただろう。しかし、それは理解ではなく推測に基づいて作られたものだった。本記事では、この問題を解決する「自己対話」パターンについて解説します。
この記事のポイント
- AIに「いきなりコードを書かせる」と、推測に基づいた問題のあるコードが生成される
- 4つのペルソナ（Peter/Neo/Gary/Reba）に役割分担させることで品質が向上
- 「計画→批評→実装→検証」の順序を強制することで盲点を排除
- チームスキルとして実装され、
/teamコマンドで利用可能
「とりあえずコード」の問題点
AIに計画なしでコードを書かせると、3つの問題が発生します。
1. 推測で書く: コードベースの文脈がないため、AIはパターンを発明します。既存のコードにauth.sanitize()関数があっても、それを知らないAIは独自のサニタイズ処理を実装してしまいます。同じ機能が複数箇所に散らばり、保守性が低下します。
2. 自己確認バイアス: 単一の視点で考えるため、盲点が生まれます。フォーマット検証を実装しても、ブルートフォース攻撃への対策は見落とすかもしれません。批判者がいなければ、最初のアイデアがそのまま実装されます。
3. 即座に出荷: 最初に思いついたアプローチが即座にコードになります。後から問題に気づいても、すでに悪いアプローチにコミットしてしまっている。手戻りは高くつきます。
問題に気づく頃には、すでに時間とエネルギーを浪費しています。では、どうすればいいのでしょうか。
4つのペルソナによる自己対話
この手法では、Claudeに4つの異なるペルソナを演じさせます。それぞれが異なる役割を持ち、コードが書かれる前に徹底的な議論を行います。
Peter（プランナー）: 実装アプローチを設計し、潜在的なリスクを特定します。「このアプローチでいきましょう：メールフォーマットを検証し、パスワード強度をチェックし、DBに入れる前に入力をサニタイズして…」
Neo（批評家）: 悪魔の代弁者として仮定に挑戦します。「レート制限はどうする？フォーマットはチェックしているけど、ブルートフォース攻撃は防げていない。それに、既存のauthモジュールにはsanitize()関数があるのに、なぜ車輪の再発明を？」
Gary（ビルダー）: 計画が批評を生き延びた後にのみ、コードを書きます。批評によって洗練された戦略に基づいて実装します。
Reba（QA）: デプロイ前にすべてをレビューし、計画段階で見落とされた問題を発見します。
実際の対話例
ログインフォームに入力検証を追加するタスクを例にとります。
私: 「ログインフォームに入力検証を追加して」
Peter (プランナー): 「アプローチを提案します：メールフォーマットの検証、
パスワード強度のチェック、DB投入前の入力サニタイズ...」
Neo (批評家): 「レート制限は？フォーマットチェックはしているけど、
ブルートフォース攻撃は防げていない。それに、既存のauthモジュールに
sanitize()関数があるのに、なぜ再発明する？」
Peter: 「指摘ありがとう。修正プラン：auth.sanitize()を再利用、
ルートレベルでレート制限を追加、その後フォーマット検証...」
計画が批評を生き延びて初めて、Gary（ビルダー）がコードを書きます。そしてReba（QA）がマージ前にレビューします。
計画 → 批評 → 実装 → 検証——この順序が重要です。
なぜこの手法が機能するのか
これは魔法ではありません。構造化された思考プロセスです。
複数の視点を持つことで、単一のAIが持つ盲点を排除できます。Peterが見落としたことをNeoが指摘し、Garyの実装をRebaが検証する。各ペルソナは同じコンテキスト内で動作するため、リアルタイムで中断や挑戦が可能です。
仮定を明示的にすることで、コーディング前に問題を発見できます。「sanitize()を実装する」という暗黙の仮定が、「既存のauth.sanitize()を使う」という明示的な決定に変わります。高コストな手戻りを防げます。
このパターンは、DevinやCursorのエージェントモードでも採用されつつあります。構造が実行に先行する——これが現代のAI活用のベストプラクティスです。
実践してみよう
この手法は「Team Skills」としてGitHubで公開されています。
# インストール
curl -sL https://raw.githubusercontent.com/HakAl/team_skills/main/install.sh | bash
使い方は簡単です。Claude Codeのセッションで以下のように入力します。
/team "ログインフォームに入力検証を追加"
このコマンドにより、4つのペルソナ間の自動ハンドオフがトリガーされます。計画フェーズが完了するまでコードは書かれず、批評が終わるまで実装に移らず、QAが完了するまでマージされません。
手動で行う場合は、以下のようなプロンプトを使用できます。
あなたは4つのペルソナを演じます：
- Peter（プランナー）：アプローチを設計
- Neo（批評家）：仮定に挑戦
- Gary（ビルダー）：承認された計画に基づいてコード実装
- Reba（QA）：最終レビュー
まずPeterとして計画を提示し、Neoの批評を受けてください。
計画が承認されるまでコードは書かないでください。
知っておくと便利なTips
-
批評を歓迎する姿勢: Neoの批評は敵対ではなく協力です。批評によって計画が洗練され、最終的なコード品質が向上します。批評が多いほど、最終成果物は堅牢になります。
-
コンテキストの共有: 4つのペルソナは別々のエージェントではなく、同じコンテキスト内で動作します。これにより、Peterの計画をNeoが即座に参照でき、議論がスムーズに進みます。
-
段階的な導入: 最初からすべてのタスクに適用する必要はありません。重要な機能や複雑な変更から始めて、徐々に適用範囲を広げていくとよいでしょう。
-
既存コードの参照: Neoが「既存の関数を使え」と指摘できるよう、プロンプトにコードベースの情報を含めることが重要です。CLAUDE.mdファイルとの併用が効果的です。
まとめ
「とりあえずコードを書かせる」アプローチは、一見効率的に見えて、実は高コストな手戻りを生みます。4つのペルソナによる自己対話は、この問題を構造的に解決します。
計画、批評、実装、検証——この順序を守ることで、AIは推測ではなく理解に基づいたコードを生成します。Team Skillsを使えば、このワークフローを簡単に導入できます。重要な変更を行う前に、まずClaudeに自分自身と議論させてみてください。
📎 元記事: https://dev.to/theskillsteam/why-i-make-claude-argue-with-itself-before-writing-code-4m5g
コメント