個人開発している動画管理アプリの次の機能を考えるために、異なる視点を持つ10のAIチームへ同じ課題を渡し、企画、批評、改善を進めるローカルツール Concept Arena を作りました。推論には、さくらのAI Engineを使っています。月3,000リクエストの無償枠を、単発のチャットではなく、複数のAI企画チームによる発案・比較・改善のループに使う実験です。
当初は、予選と決勝で1位を決めれば良い企画が残ると考えていました。しかし実際には、独自性の強い案が最後の工程で消え、10チームが同じ答えへ寄ったり、順位を付けても10案を読む負担はあまり減りませんでした。試行を重ねるうちに、必要だったのは勝者を決める大会よりも、異なる方向を残して人間が選び直せる候補整理の工程だと分かりました。
この記事では、試行錯誤の中で仕組みがどう変わり、最終的に個人開発アプリの機能実装へどうつながったかを振り返ります。うまくいかなかった変更などもそのまま扱います。
この記事は、「さくらのAI Engine」3,000リクエスト使い切りチャレンジへの参加記事です。
作ったもの
Concept Arenaは、同じ課題へ複数のAIチームが企画を提出し、比較・改善するNode.js / TypeScript製のローカルツールです。課題には、個人開発しているローカル動画プレーヤー Reel Video Player の新機能企画を使いました。課題は別のものにも差し替えられるようにしています。
| 項目 | 内容 |
|---|---|
| 実装 | Node.js / TypeScript |
| 推論 | さくらのAI Engine（OpenAI互換Chat Completions API） |
| 主に使ったモデル |
gpt-oss-120b、preview/Kimi-K2.6
|
| 保存 | JSON / Markdownの追記型成果物 |
| 操作 | CLIを正本にしたローカルGUI |
各チームへ渡したReelの現状
新機能を考えさせる前に、全チームへ同じ製品資料を渡しました。要点は次のとおりです。
- Macにあるローカル動画をライブラリ化し、お気に入り、プレイリスト、タグ、検索、再生位置を管理できる
- MP4やMOVだけでなく、MKV、WebM、AVIなども再生できる
- 動画ごとに、オンデバイスの文字起こし、翻訳、要約、手動メモ、画面キャプチャを扱う
Video Notesがある - iPhone版はMacとローカル接続し、動画を保存してオフライン再生できる
- クラウド同期や開発者運営サーバーは使わず、Mac App Storeのサンドボックスと既存のプライバシー方針を守る
- 一括エクスポートや自動チャプター生成など、過去に検討して見送った案も共有する
実際の入力は、製品概要、既存機能、技術・配布上の制約、見送り済み案の4資料です。各提案には、どの資料を根拠にしたかも残させました。これにより、存在しない機能を前提にする提案は減りました。一方、製品資料を詳しくするほど、全チームが同じ既存機能へ注目しやすくなる面もありました。
1チームは、次の6リクエストを基本にしています。
- Scout A: 利用者の不満から改善案を考える
- Scout B: 現在の強みを伸ばす方向から考える
- Scout C: 前提を一つ疑い、意外な方向から考える
- Mapper: 3案を比較して2方向へ整理する
- Challenger: 反対意見を出す
- Architect: 材料を1つの提出案へ統合する
Scout 3名は、同じ課題と製品資料を受け取りますが、互いの案は見ません。Mapperが初めて3案をまとめて読みます。
各工程のプロンプト、生応答、検証後のJSONは別々に保存します。フォーマットエラーや通信エラーなど、途中で失敗した場合は、未完了の工程から再開します。
保存単位は、以下の形です。
teams/<run-id>/
├── plan.json # 入力のハッシュ、モデル、最大件数
├── scout-a/ # request.json、生応答、検証済み応答
├── scout-b/
├── scout-c/
├── mapper/
├── challenger/
├── architect/
├── proposal.json # 検証済みの提出案
├── usage.json # 実際に送信した件数
└── revision-context.json # 改訂時だけ。改訂元と渡した材料
チームが提案を作るTeamRunと、複数案を比べる工程は分けています。比較方法は2つあります。Arenaは少数案を匿名で批評・反論する詳細比較です。PortfolioSelectionは10案全体を横断し、各案を複数の観点で評価しながら、似た案の統合、総合順位では落ちる案の救済、2案の組み合わせを検討して4〜5方向へ整理します。前者は必要な案を深く読むため、後者は候補全体の偏りを見ながら、人間が読む数を減らすために使います。
どちらも元のproposal.jsonは書き換えません。批評や人間コメントを受けた改訂版は、新しいTeamRunとして保存します。この形にしたことで、「最新案」だけでなく、どの比較とコメントで何が変わったかを後から追えるようになりました。
入力から生成・比較・改訂を経て、判断材料を保存するまでの基盤の全体像は次のとおりです。
4チームから始め、10チームの大会へ広げた
最初は、最小構成・高頻度利用者向け・成長重視・変化球の4チームで始めました。後から視点を10へ増やし、5チームずつの予選から各組の上位2案を選び、4案の決勝でAI審査の1位を実装候補にする流れを作りました。
匿名化、提示順の入れ替え、批評と反論、共通の評価軸など、審査の公平さには気を配りました。しかし、似た案が複数勝ち残り、予選落ちの案にも使える部品があり、最終的には人間が全体を読み直していました。
ここから、試行錯誤を繰り返しながら基盤修正を進めました。
AIにチーム視点を重視させる
初期の5チーム分について、Mapperが残した2方向と、Architectが採用した案を比べました。
| Run | Mapperが残した2方向 | Architectの採用 |
|---|---|---|
| 1 | 一括エクスポート / 自動フォルダ監視 | 一括エクスポート |
| 2 | 動的スマートプレイリスト / 速度プリセット | 速度プリセット |
| 3 | シーンブックマーク / クロスデバイス同期 | シーンブックマーク |
| 4 | 動画クリップ書き出し / タイムスタンプブックマーク | タイムスタンプブックマーク |
| 5 | チャプターマーカー / 音声指紋による重複検出 | チャプターマーカー |
5件とも、太字にした独自性のある案はMapperまで残っていました。最後のArchitectが、より小さく実装しやすい方を選んでいます。
最初に試したのは、Architectへ「チームの視点を薄めないでください」と1文足すことでした。結果は変わりませんでした。原因は姿勢ではなく、生成側へ見せていた評価文言にありました。
当時のFeasibilityは、次の表現でした。
個人開発として段階的に実装・保守できるか
AI審査用の配点は生成側へ見せていませんが、この文言自体は見せています。Architectはそれを生成目標として読み、「開発コストとリスクが低い」案を選んでいました。
そこで、次のように変更しました。
最初の一歩が具体的に示されているか。案の規模が小さく実装しやすいこと自体は加点しない
次の4案では、提案本文から開発コストの低さを価値として売り込む表現がゼロになりました。
課題文を書きすぎないようにする
次に、Concept Arenaを別のテーマにも使えるか確かめるため、「月3,000リクエストの無償枠をどう使うか」という課題を、同じ10チームで試しました。各チームの視点も分けています。
最初の実行では、10案すべてが「毎日生成し、成果を蓄積し、本人が後で読む情報収集」になりました。批評の内容までほぼ同じで、「1日100件を本当に消化できるのか」と指摘しています。
原因を調べると、課題文に置いた次の条件が、解き方をほぼ決めていました。
- 途中で止めても成果が残る
- 1回だけ試して終わる企画は対象外
これらを同時に満たすと、少しずつ反復して何かを貯める形がほぼ唯一の解になります。チームの視点より、課題文の制限を強くしすぎました。
成立条件を「有料なら割に合わないが、無料なら成立すること」の1つへ戻し、同じ10視点で回し直しました。
| 条件を3つ足した課題 | 条件を1つに戻した課題 | |
|---|---|---|
| 案の傾向 | 10/10が「毎日貯める」 | 校正・配信・評価・学習・変換へ分散 |
| 一度きり利用チーム（蓄積を前提にしない） | 毎日100枚のカードを生成（自分の制約に違反） | 1リクエストで完結する案 |
| 成長チーム | AI開発日誌 | 連載コンテンツと配信 |
同じ10視点で課題文だけを変えたこの比較では、課題文を短くしたときに案の分布が動きました。モデルの違いによる案の分布は、今回比較していません。
ただし、緩めればよいわけでもありません。緩い課題では、普通のチャット画面でもできる校正や短文生成が増えました。手段を指定しすぎず、「APIだから成立する状態」を成立条件として書く必要があります。人が画面の前にいなくても動く、同じ入力を複数回流して分布を見られる、手元のデータへ機械的に適用できる、といった性質です。
人間のコメントを渡して改善させる
大会の結果を受けて、人間のコメントを使って各チームを改訂する経路を作りました。プロンプトの先頭には「人間の判定をAI批評より優先してください」と書いています。
それでも最初の改訂では、4チームすべてが具体的なAI批評だけを直し、人間のコメントをほぼ無視しました。
| 人間コメントの書き方 | 元案を捨てるほど変更したチーム |
|---|---|
| 「この中ならA。消去法に近い」 | 0/4 |
| 1チームだけ案の内容を名指し | 1/4（変わったのは名指しされたチームだけ） |
| 全チームへ個別に内容を指摘 | 2/4 |
AI批評は「ディスクI/Oが増える」のように、具体的でした。一方、人間コメントは優先度が高くても、何を変えるかが分かりません。効いたのは「重要です」という宣言ではなく、短くても対象が分かる書き方でした。
そこで、人間は1つのファイルへコメントを書き、ホストが各チームに該当部分だけを配るようにしました。毎回詳細な仕様を書く必要はありません。「この案の同期頻度が心配」「Bの方向は残したい」程度でも、対象が分かれば改訂できます。
順位付け大会をやめる
大会を作った目的の一つは、10案すべてを読む負担を減らすことでした。ところが、批評もAI審査も提案を1件ずつ見ます。「10案のうち3案がほぼ同じ」とは誰も言いません。
基盤の汎用性確認に使った4チームの別課題では、人間が重複を指摘して全チームへ戻すと、他チームの行き先を知らないまま同じコメントへ反応するので、修正案も揃ってしまいました。
そこで、勝者を1つ選ぶ代わりに、各案を複数の観点で評価し、重複や組み合わせも考慮して4〜5方向へ整理する工程を作りました。
- 利用者価値で残す案
- 独創性で残す案
- 製品との相性で残す案
- 総合順位では落ちるが救済する案
- 2案を組み合わせると強くなる組
- 最後に4〜5方向へ整理する統合役
試してみると、10案から次の4方向が詳細確認へ残りました。
- シーク中の発言テキストプレビュー
- Video Notesの横断検索
- 発言単位のキーボード移動
- 複数動画の区間をつなぐTrail / Clips
比較方法を変えた後も、一度の結果で終わらせず、AI判定と人間コメントを次の10案へ戻しました。案だけでなく、収束や重複の原因になった課題文・評価文言・比較方式も直しています。
この繰り返しで蓄積した案を、最後に実装候補へ絞りました。
最終実装候補を決める
基盤を直しながら何度も実行したため、Reel関連だけでも途中案が大量に残りました。完成系だけでなく、Scout案、Mapperが見送った案、改訂案などを収集すると255案が集まりました。
255案をそのままプロンプトへ入れると、長いだけでなく過去の多数派へ引っ張られます。そこで、基盤側のプログラムが、10チームそれぞれに参考となる10案を選びました。選択に使うのは、そのチームの視点と制約、前回の提案、人間の共通コメントとチーム別コメントです。
10案の内訳は、現在の案と文字列上の共通点が多い6案と、別の系統から選ぶ4案です。前者は今の着想を深める材料、後者は別方向との組み合わせを考える材料として渡します。選択はランダムではなく、同じ入力なら同じ結果になるローカル処理です。勝敗、点数、提出チーム名、見送り理由は、選択にも発想材料にも使いません。
ここまではAPIリクエストを使いません。さくらのAI Engineは、選ばれた10案に加えて、前回案、人間コメント、保存済みのAI批評や順位を読み、実際の提案を改訂するところから担当します。
Mac側の案は、横断検索、区間ループ、連続再生、キーボード移動などへ分かれました。一方、共通要件として渡したiPhone側はVideo Notesの持ち出しへ複数案が寄りました。カタログで単純な言い換えは減らせましたが、共通要件から生まれる収束までは消えませんでした。
実装前には、候補を次の3方向へ分けました。
- iPhone: プレイリスト／お気に入りの閲覧と、プレイリスト単位の一括ダウンロード
- iPhone: text-only・read-onlyのVideo Notes持ち出し
- Mac: 既存の「次に再生」領域を置き換える時間ナビゲーションを、チャプター／波形／マーカーの技術と配置から検討
AIは実装詳細までを見ているわけではないので、100％そのままでは実装できません。既存コードへ照合し、MacとiPhoneで完結する範囲へ分け直したのは人間です。その後、次の2バージョンとして実装しました。
※ 実装にはさくらのAI Engineは使用していません。
Reel Video Player 1.4.0（Mac）
- 動画内の字幕・音声トラック切替と、外部字幕（
.srt/.ass/.ssa/.vtt）の読み込み - 再生、シーク、音量、速度、フレーム送りのキーボード操作
- 埋め込みチャプターの一覧と、自分で追加・編集できるチャプター。リストとサムネイルを切り替え可能
- 音量の波形を重ねたシークバー（設定でオフ可能）
- インスペクタの「次に再生」をチャプター表示へ置換。前後移動と連続再生は維持
企画時の「時間ナビゲーション」は、自動生成チャプターをいきなり作るのではなく、動画に元からあるチャプター、自分で付けるチャプター、音量波形を組み合わせる形になりました。同じリリースには、字幕・音声トラックとキーボード操作も入れています。Reel 1.4.0はリリースビルド、テスト、動作確認を終え、Mac App Storeの審査も通過しました。
Reel Remote 1.1.0（iPhone）
- Macのプレイリスト／お気に入りを開き、件数・概算容量・除外数を確認してから一括保存
- Macの要約・文字起こし・メモと、自分で付けたチャプターをread-onlyで持ち出し。オフラインで読み、時刻から再生位置へ移動
- 端末内の動画をMac別・フォルダ別に階層表示し、検索
iPhone側も実装とリリースビルドを終え、App Storeの審査を通過しました。Video Notesは新しい生成・編集機能へ広げず、企画時に決めたread-onlyの範囲を維持しました。動画が既に端末内にあれば、ノートだけを更新するために動画本体を再ダウンロードしません。
リクエストの内訳
| 用途 | リクエスト数 |
|---|---|
| チーム内の企画生成・改訂 | 682 |
| 大会の批評・反論・審査 | 341 |
| 候補整理（PortfolioSelection） | 35 |
| 合計 | 1,058 |
おわりに
3,000リクエストを使えると聞いたとき、最初に考えたのは「AIをたくさん並べれば、面白い案が勝手に残るのではないか」ということでした。案はたくさん出ましたが、幅広い案を消さず、似た案をまとめ、人間が読める数へ減らし、既存コードへつなぐには、そのための工程を設計して基盤に実装する必要がありました。
本当は、課題を与えれば、人が途中で選ばなくても最終案まで進む仕組みができればよかったのですが、今回は重複や偏りの判断に人間の確認が必要で、完全自動化には届きませんでした。
Concept Arenaの前には、さくらのAI Engineに小さなゲームの企画・実装・改善を担わせる別実験も行いました。そちらは累計1,372リクエストを使いましたが、受け入れ条件を厳しくするとゲームらしさを失い、緩めると退化した実装を通すという問題を解き切れず、打ち切りました。それでも、ゲーム実験もConcept Arenaも、それぞれ3,000件を使い切るところまでは行きませんでした。個人開発で複数の仮説を実際に試すには、かなり余裕のある枠だと感じました。