TL;DR: さくらのAI Engineの「3,000リクエスト使い切りチャレンジ」向けの企画探しに、多AI発散ブレストツールを自作して3回回した。2回連続で「生成AI利用の教科書」のような予定調和な案しか出ず、お題と評価条件を変えて初めて質的に違う案が上位に来た。最終的に「複数のさくらのAIモデルが合議制で異世界転生小説を毎日書き続け、消費したリクエスト数がそのまま物語の進行度になる」企画に決定した。パイプライン自体はまだ未実装で、本記事は「設計を決めるまで」の記録のようだ。
なぜアイディア出し自体をAIに任せたか
Qiita公式イベント「OpenAI・Anthropic互換APIを無料で使おう！さくらのAI Engine 3,000リクエスト使い切りチャレンジ」に参加するにあたり、「使い倒したで賞」を狙いたいと考えた。3,000リクエストを使い切るには、それなりに「バカげた、でも技術的に意味のある」企画が必要だった。
自分一人で考えても、既存の成功事例の延長線上に思考が引きずられてしまうだろう。そこで、発散ブレストからファクトチェック、構造化評価までを自動化した新規ツールを組み、最大14体のAIモデルを同時に参加者として回す仕組みを作った。
- 発散ブレスト: 全参加者がお題に対してアイディアを出す（複数ターン、前のアイディアの改良も可）
- ファクトチェック: 別の参加者が各案の実現可能性や前提の誤りを指摘する
- 構造化評価: 評価者が実現度・業務効率化度・新規性の3軸で採点し、上位案を決める
「1つのモデルに聞く」のではなく「モデル同士に批判させる」構造にしたのは、単一モデルの出力は平均化されがちで、異種モデル同士の相互批判でこそ、自分の盲点に当たる領域を機械的に広げられるのではないだろうか、と考えたからだった。
定量データ: 3回のブレスト結果
| ラウンド | お題 | 生成アイディア数 | ファクトチェック指摘率 | 評価完走率 |
|---|---|---|---|---|
| Round 1 | 中小企業の業務効率化・マーケティング自動化 | 114件 | 21.9%（25/114） | 6/8参加者 |
| Round 2 | 一般消費者向け（画像入力なし） | 120件 | 41.7%（50/120） | 6/8参加者 |
| Round 3 | 娯楽・遊び・学び（構造の多様性も明示的に要求） | 120件 | 32.5%（39/120） | 7/8参加者 |
Round 1・2の上位案は、ほぼ全て同じ構造だった。
テキストを1つ入力 → 複数モデルが役割分担して変換 → 整形されたテキストを出力
「現場の愚痴をSNS投稿に変換するアプリ」「断りにくい依頼への返信文を生成するアプリ」といった具合だった。どれも便利ではあるが、いわゆる「生成AI利用の教科書」の1ページ目に載っていそうな、予定調和な結果のように見える。
Round 3では、お題を「日常の悩み解決」から「娯楽・対戦・討論」に変え、さらに「単なる処理分担でなく、複数モデルの個性の違いを体験の核心に使う」構造の多様性を明示的に要求した。ここで初めて質的に違う案が上位に来た。最上位案（6/6評価者が一致）は「複数のAIモデルがリアルタイムで議論しながらゲームマスターを務めるTRPG」だった。1体のAIに任せず、世界観担当・ルール裁定担当・語り担当が「それはルール違反だ」「いや面白いから通そう」と議論しながら進行を決める設計で、この案が最終的な企画の核になった。
詰まった点・誤算（5つ）
-
複数AIブレストは、制約を変えないと同じ構造に収束する。
参加モデルを増やせば自然に多様化すると思っていたが、「良いアイディアの条件」に出力構造の多様性を明示的に含めるまで、案は同じパターンに収束し続けた。モデルの数より、問いと評価軸の設計の方が効いていたようだ。 -
Plamo（さくらのAI Engineの有料枠モデル）が4戦4敗だった。
3回のブレスト全てで、ほぼ同一の待ち時間（約900秒）の後に応答を返さず失敗した。reasoning_effortやmax_tokensを疑って最小構成（プロンプト最小・パラメータ省略）で再検証したが改善せず、原因は未特定のまま採用を見送った。3回ともタイムアウト秒数がほぼ一致しているところを見ると、何かの固定的な上限にぶつかっているのかもしれない。 -
「対象プラットフォームは画像非対応」という前提が途中で覆った。
Round 2のお題設計では画像入力を前提から外していたが、モデル一覧をAPIで直接確認したところ、画像対応（Vision-Language）モデルが実在した。ドキュメントの記憶ではなく、APIに直接聞くのが正解だったのかもしれない。 -
存在を知っていたモデル（Kimi K3）が、手元のコードには登録されていなかった。
モデル名を知っていることと、正しい識別子で呼び出せることは別のようだ。APIのモデル一覧を確認して初めて、正しいモデル識別子が判明した。 -
CLIツール経由で参加させた2ベンダー、計4体が、3回とも同一パターンで全滅した。
Claude Code CLIとCodex CLI経由の4体（各ベンダー2体ずつ）が、3回とも同じ失敗理由で応答を返さなかった。再現性はあるが、原因はまだ解明できていない。14体を同時に並列実行する負荷が関係しているのかもしれないが、まだ確かめられていない。
最終的にたどり着いた企画
Round 3のTRPG案を発展させ、最終的に次の企画に決めた。
複数のさくらのAIモデルが合議制で異世界転生小説を毎日書き続け、消費したリクエスト数がそのまま物語の進行度として可視化される。
TRPG案の「AI同士の議論そのものが見える面白さ」を保ちつつ、プレイヤー不要の完全自動運転にした形とも言える。ポイントは、「3,000リクエストを使い切ること」を単なる制約ではなく物語の演出装置にした点にある。リクエスト消費量がそのまま進行度ゲージになるので、「使い切る」ことが企画の目的そのものと一致する。
スタッフ構成
| 役割 | 担当モデル | 稼働頻度 |
|---|---|---|
| 世界観・情緒担当 | llm-jp（さくらのAI Engine、無料枠） | 毎日 |
| ルール裁定・整合性担当 | gemma-4-31B-it（さくらのAI Engine、無料枠） | 毎日 |
| 語り口・盛り上げ担当（最終筆者） | Kimi-K2.6（さくらのAI Engine、無料枠） | 毎日 |
| ツッコミ・討論担当 | gpt-oss-120b / Qwen3.6-35B-A3B（さくらのAI Engine、無料枠） | 毎日 |
| 外部評論家役 | GLM-5.2（ai&、ゲスト出演） | 定期的 |
| 編集長・最終監修役 | Kimi K3（ai&、ゲスト出演） | 不定期（実績3戦3敗のため失敗時は自動スキップ） |
| コーディング担当 | Kimi-K2.7-Code（さくらのAI Engine）、エージェント型コーディングCLI経由 | パイプライン実装時 |
中核4役はさくらのAI Engineの無料枠モデルで毎日稼働させ、「使い倒す」印象を主役に据える。ai&の2体はあくまでゲスト出演で、議会に外部の異物を持ち込む役どころに留めたい。Kimi K3は過去の検証で実績が不安定なため、失敗時は自動スキップして議事に穴を開けない設計にする。コーディング担当は、パイプライン自体の実装を、さくらのAI Engineのコード特化モデルにエージェント型コーディングツール経由で任せる計画である（過去の別プロジェクトで実績のある手法の転用）。
既存資産の再利用と、そこで見つかった未解決課題
土台には、過去に作った「AI討議を動画化するパイプライン」を再利用する計画だった。調査の結果、2つの未解決課題が見つかった。
- キャラクターを本格的に動かす仕組みが未実装だった。 Live2Dによる本格アニメ化は別途検討済みだったが、システム依存関係（ビルドに管理者権限が必要なパッケージ）の問題でブロックされたまま止まっていた。
- 説明画像を動画に挿入する機能がそもそも存在しなかった。 既存のレンダラーはテキストと発言者名だけを描画する仕組みで、画像合成の機構は一切なかった。
本格対応は後回しにし、まず簡易な代替案で動くものを先に作る方針に切り替えた。キャラクターの動きは音量連動の簡易な口パク（口の開閉2〜3枚を音量に応じて切り替え）で代用し、説明画像はAI画像生成で毎話1枚の挿絵を作る。完璧な映像より、毎日確実に回るパイプラインを優先したかった。
まだ決まっていないこと / 次にやること
正直に書くと、この記事の時点でAI議会小説のパイプライン自体はまだ実装しておらず、決まったのは企画・役割分担・失敗時のスキップ方針・既存資産の再利用範囲までだった。運用結果もまだ出ていない。
文脈圧縮については、その後の検討で方針が決まったようだ。過去の議事録を検索できる既存のRAGインデックスツールがあり、これを流用する形で「直近数話はそのまま渡す」＋「その回の具体的な提案内容をクエリにしたRAG検索を、整合性チェックの直前に追加する」という2段階の検索フローに落ち着いた。ただし実際に動かして検証できていない、という点は変わっていない。
いきなり目標の10万文字・本番の日次カデンスで作るのではなく、まず3万文字程度の規模でパイプラインの仕組みそのものを検証する方針にした。次にやることは、テーマ・登場人物・物語の方向性を決める企画会議（本記事の主人公が明治維新後の徳川慶喜の家に転生する設定は、あくまで検討時の一例であり、実際の題材は完全に架空の異世界にする可能性が高い）で、その後で最小構成（AI議会での討議→保存、Webページや音声・映像は後回し）から実装を始めたい。少数意見をどこまで物語に残すか、モデル障害時に議論の公平性をどう扱うかは、まだ答えが出ていないのかもしれない。実装と日次運用、3,000リクエストへ到達するまでの観察は続編で報告したい。
複数AIに企画を考えさせるときの決定テーブル
同じように「複数AIに企画を考えさせたい」人向けに、今回の経験からの対処法をまとめる。
| シナリオ | おすすめの進め方 | 避けたい進め方 |
|---|---|---|
| 早く1案に絞りたい | 少数モデルで発散し、評価条件を先に固定する | 参加者だけ増やして総当たり評価する |
| 「教科書的」な案を避けたい | 禁止する構造と、求める構造の多様性をお題に明記する | 「面白い案を出して」だけで任せる |
| コスト・時間を抑えたい | モデル一覧と最小リクエストで先に疎通確認する | 本番ブレストで初めて全モデルを呼ぶ |
| 最初から尖った案が欲しい | 悩み解決より、対戦・討論・制約・失敗をお題に入れる | 便利さと実現可能性だけを高く評価する |
| モデルの違いを活かしたい | 出力分担ではなく、対立や交渉が成果物に残る設計にする | 同じ指示で並列生成し、最後に多数決だけ取る |
| 長期運用したい | タイムアウト・自動スキップ・文脈圧縮を最初から設計対象にする | 全モデルが毎回成功する前提で組む |