試してから書くAI・開発ツールの実機検証

検証済 ・ 生成AI

AI4体に企画を壁打ちさせてみた:合議と直列リレーの記録

この記事について

ChatGPT・Gemini・Grok・Claudeの4体に壁打ちさせた記録。並列合議と直列リレーを実際に回し、意見の束ね方と『どこで止めるか』を検証しました。

対象読者: 自分の企画やアイデアを複数の生成AIに壁打ちさせたい個人開発者

4体のロボットが1枚の企画書を囲み、それぞれの意見が線となって書類上で合流し、電球(アイデア)へ向かう様子。複数の生成AIで壁打ちする記事のイメージ

ChatGPTとGeminiとClaudeに、同じ質問をしていいとこ取りをする。生成AIを複数使う人なら一度は思いつく壁打ちです。

複数のAIに投げる手間が面倒だったので試していませんでしたが、自分のブログの方針を決めるのに使ってみたくて、今回は2つの方法で実施しました

先に結論を書きます。「複数AIに意見を出させると議論が深まる」で止めると本質を外します。重要だったのは「どう束ねるか」と「どこで止めるか」で、そこは私が決めるところです。 この記事は、自分の企画を複数AIで壁打ちしたい個人開発者に向けて、手順と実際のログ、実施する際のつまずきをそのまま残すものです。

既存の「複数AI壁打ち」記事に足りないもの

日本語の記事を探すと、大きく2つに固まっていました。ひとつは「壁打ちならChatGPT、検索ならGemini、仕上げはClaude」という使い分けガイド。もうひとつは複数エージェントに投票や議論をさせる「LLMオーケストレーション」のような、枠組み寄りの解説です。

前者は「1つのAIとの壁打ち」が中心で、後者はフレームワークの話になりがちです。「自分の具体的な案を、複数AIに実際に壁打ちさせ、その生ログと束ね方、そして止め時まで見せる」記事は、ほとんど見当たりませんでした。そこを埋めるのが今回の狙いです。

何をどう試したか

題材は、このブログ「試してから書く」自身の「次の3ヶ月の一手」。公開済みのブログなので機密がなく、題材にしやすいという理由です。

4体(ChatGPT・Gemini・Grok・Claude)の条件は、比較が成り立つようにそろえました。

  • 全部Web版・一時(シークレット)チャット・新規セッション。過去の記憶やパーソナライズを引かない白紙状態にする
  • モデルは各社の高推論・単一モデルで統一(ChatGPTは「高」、Geminiは3.1 Pro+強化版思考、Grokはエキスパート)。Grokの「Heavy=専門家チーム」は内部で複数エージェントを動かすモードなので、複数AIを比べる今回の趣旨を濁す。使わない
  • 投げるプロンプトは同一。読者像を「絞る/広げる」どちらか明言させる欄を入れ、意見が割れるようにした

そのうえで2つのつなぎ方を両方試しました。

  • 並列→統合:ChatGPT・Gemini・Claudeに同じプロンプトを独立に投げ、3つの回答を突き合わせる
  • 直列リレー:ChatGPT→Gemini→Grokの順で、前のAIの回答を次のAIに「批評して改善させる」。各ハンドオフの中継プロンプト作成と統合は、司会役のClaudeが担当

直列リレーで大事だったのは、次のAIに渡すときに「元の質問」ではなく「前の回答を批評・改善して」という中継プロンプトに差し替えることです。ここを差し替えないと、ただ同じ質問を繰り返すだけになります。

並列(合議)と直列リレーのフロー図。並列は同じプロンプトを3つのAIへ独立に投げて統合し、決定は人間が行う。直列リレーはChatGPT→Gemini→Grokと前の回答を批評・改善で渡し、上積みは大・大・中・小と逓減して最後は人間が打ち切る。

並列に聞くと、土台は一致し、着手点で割れた

まず並列。3体の回答は、驚くほど同じ土台に着地しました。

  • 診断:「試してから書く」という検証の軸は強いが、「誰の何を助けるサイトか」が弱くブレている
  • 読者像:全員「絞る」。絞り先まで一致して「AIツールを実務・個人開発に導入したい個人開発者」
  • やめること:全員「今はガジェットや一般層への横展開を広げない」

独立に投げた3体が同じ結論に来たので、ここは信頼していい部分だと判断できました。実際、自分でも「一番ブレさせてはいけないのはここだ」と納得できます。

割れたのは「で、最初に何をやるか」だけでした。ChatGPTは「同じ評価軸で連載する看板シリーズを作れ」、Geminiは「自作のネタ収集ツールの裏側を公開して差別化しろ」という飛び道具、Claudeは「まずポジショニングを一文で言語化しろ、それが決まらないと題材も選べない」と、質問の前提そのものを問い直しました。

つまり並列は「論点と選択肢」は出してくれますが、「決定」はしてくれません。3つの案を眺めて、どれを採るかは自分で決めるしかない。これは以前Claude Design System Promptを試したときに「6案がモデルを変えても似た3系統へ収束し、最後の差は自分の取捨選択で付いた」と感じたのと同じ構図でした。

直列リレーは改善が続いたが、やがて頭打ちになった

次に直列リレー。ここが今回の一番おもしろい部分です。1手ごとの「実質的な上積み」を追うと、こうなりました。

遷移実質的な上積み
1→2ChatGPT → Gemini大:汎用的な案を、自作ツールという強み軸で作り替え
2→3Gemini → Grok大:前段が抱えた矛盾(後述)を解消して収束
4→ ChatGPT(2巡目)中〜大:3本の記事を「役割の違う実験」に設計し直した
5→ Gemini(2巡目)小:微修正2点のみ、残りは整形と自己申告

大→大→中〜大→小、ときれいに逓減しました。

面白かったのは2巡目の入り口です。私は「2巡目はどうせ堂々巡りだろう」と予想していました。ところが2巡目1手目のChatGPTは、3本の深掘り記事を「既知需要型・新規発見型・一般層への橋渡し型」という別々の仮説の検証として設計するという、今回全体で一番の改善を出してきました。単に「使いそうなツールを3つ」ではなく、記事そのものを「どの切り口が刺さるか」を測る実験にする、という発想です。

一方で、2巡目2手目のGeminiは「実行に移すべき完成度」と自己判定し、追加は指標の事前登録など2点だけ。AI自身が「もう十分」と言い始めました

分かったこと1:「AIが止まらない」のはプロンプトのせい

「複数AIで回すと延々と直し続けて収拾がつかない」という話をよく聞きます。今回それが起きなかった一番の理由は、中継プロンプトに「実質的な改善余地がなければ”完成”と宣言してよい、無理に作り替えるな」と明記したことでした。

逆に言うと、多くの壁打ちループが空回りするのは、毎回「改善して」と命じているからです。改善しろと言われれば、AIは何かを変えます。止まる余地を与えれば、AIは止まると言える。空回りは、AIの性質というより、こちらの指示設計の産物でした。

分かったこと2:司会が案件を分かっているほど収束する

直列リレーが収束した背景には、司会役のClaudeが各ハンドオフで「本当の弱点」を名指しして次のAIに渡していたことがあります。たとえばGeminiの案は「読者の反応を見て深掘り対象を決める」仕組みでしたが、その提案自身が「認知ゼロ・記事数少」と認めている以上、初期に反応データは存在しません。この矛盾を司会が指摘し、次のGrokが「反応を待たずに先に3本書く」へ直しました。

もし司会が何も指摘せず「はい次」と渡すだけだったら、後のAIが前の良い部分を上書きして劣化する(ドリフトする)公算が高かったはずです。人間どうしの会議でも、案件を理解した進行役がいるほうが議論はまとまる——それがAIの壁打ちでもそのまま効きました。

分かったこと3:並列と直列は役割が違う

  • 並列は、独立した視点を並べて「合意できる土台」と「割れる論点」を洗い出すのに向く。ただし決定はしてくれない
  • 直列リレーは、1つの案を積み上げて磨くのに向く。ただし司会が弱いとドリフトし、放っておくと(止める許可がないと)空回りする

「意見の幅がほしい」なら並列、「1つの案を仕上げたい」なら直列、と使い分けるのが素直でした。

分かったこと4:止め時を決めるのは、やはり人間

逓減カーブがはっきり出て、2手続けてAIが「完成」と言った時点で、私は6手目(Grokの2巡目)を回しませんでした。上積みがほぼゼロだと予測できたからです。AIに「もう1周する?」と聞けば、レビュー役は何かしら”改善点”をひねり出します。だから「もう十分か」を判断できるのは、コストと成果を天秤にかける人間だけでした。

ただし注意もあります。私は最初、3手目(1巡目の完成形)を「もう十分」と思いました。でも4手目で一番の改善が出た。「見た目が完成している」ことと「本当に頭打ち」は別で、早すぎる打ち切りは良い案を取りこぼします。止め時は「変化が減ってきて、次の上積みが労力に見合わないと予測できたとき」でした。

結局、私はどうしたか

この壁打ちの結論を、このブログの実際の次の一手として採用します。要点はこうです。

  • 読者は属性ではなく状況で絞る=「宣伝ではなく実測で導入判断したい人」。これなら将来ガジェットや一般層へ無理なく広げられる
  • シード深掘り3本を「検証ポートフォリオ」として先に書く(既知需要型/新規発見型/一般層への橋渡し型)。反応を待たずに書き、3本で「どの切り口が刺さるか」を測る
  • 検証日・バージョン・環境を各記事で可視化し、鮮度を管理する
  • 8週間後に、PVだけでなく保存・回遊・登録なども見て方針を見直す
  • 未検証のツールを通常記事として出さない(看板を守る)

そして、この記事自体がその実践の第一歩です。「複数AI壁打ちをやってみた」という新規発見型の検証記事を、実ログ付きで出す——ポートフォリオの1本目として、ちょうど当てはまりました。

向いている人・向いていない人

向いているのは、正解が一つに定まらない意思決定(企画の方向性、設計の選択、ポジショニングなど)を抱えていて、複数の視点と「割れる論点の洗い出し」がほしい人です。手を動かして中継プロンプトを差し替える手間を許容できるなら、直列リレーで1案を磨くのも効きます。

向いていないのは、単一AIで十分な軽い相談や、事実が一つに決まる質問です。壁打ちの手間に見合いません。また、機密を含む案は避けてください。今回は公開済みのブログを題材にしたので問題ありませんでしたが、未公開の事業計画などを各社のチャットに貼るのは別の判断が要ります。

制約も正直に書いておきます。今回はリレーの順番を1通りしか試しておらず、順番を変えれば結果は変わり得ます。モデルやモードの差もそろえきれていません。そして繰り返しになりますが、司会・執筆がClaudeで、参加者にもClaudeがいるため、評価は完全に中立ではありません

まとめ

複数AIの壁打ちは、「意見が増える」こと自体より、束ね方(並列か直列か)と、止め時の判断で価値が決まりました。空回りはプロンプト設計で止められ、収束には案件を理解した司会が効き、最後の打ち切りは人間の仕事——というのが、4体を実際に回して残った結論です。

次は、今回手作業でやった壁打ちをAPIで1画面にまとめ、実際にいくらかかるかまで計測する版を試す予定です。契約しているサブスクとAPIの課金は別物で、ここも個人開発者がつまずきやすいところなので、そのとき改めて書きます。

参考情報源