さくらのAI Engine × Copilot CLI（BYOK）で作業環境を構築 + ブレスト評価
はじめに
このページは、さくらインターネットが主催する 「さくらのAI Engine 記事投稿キャンペーン」 向けに、私が 個人作業環境を整え、企画を選定するまで の記録です。
キャンペーンでは、OpenAI・Anthropic 互換の API 基盤 さくらのAI Engine を活用し、アプリ開発や検証、ちょっとした遊び心のある企画を記事にすることが目的です。月間 3,000 リクエストの無料枠があり、課金なしで手軽に始められます。
GitHub Copilot CLI を BYOK（Bring Your Own Key） 設定でさくらのAI Engine に接続し、企画活動用リポジトリを構築しました。その環境を使って、既存のキャンペーン投稿 を分析し、30 の企画案をブレスト、5 名の AI 審査員に採点してもらいました。
本記事では、セットアップ手順とハマったポイント、そして企画選定のプロセスと結果をまとめます。
なぜ Copilot CLI + さくらのAI Engine なのか
普段から Copilot CLI を利用しているので、既存のワークフローを崩さずに さくらのAI Engine を組み込みたくなりました。BYOK 設定にすれば、Copilot CLI から直接さくらのAI Engine のモデルを呼び出せるので、ツールの切り替えなしに企画活動に集中できます。
キャンペーン期間中は、小規模アプリ開発 と 記事執筆 を同時に進めることが想定されます。そのため、作業ログの一元管理や記事化タスクの自動起票を 定型化 したかったため対応しました。
用意した環境
OS・ツール
- OS: Windows
- Python: 3.12（uv 管理）
- GitHub Copilot CLI（BYOK 設定）
- AI: さくらのAI Engine（
preview/Kimi-K2.7-Code）
リポジトリ構成
ルートには 基盤ファイル のみを置き、実作業成果物は work/、ドキュメント・記事原稿は docs/ に分離しています。
C:\data\quiita\
├── .copilot/ # Copilot CLI セッションデータ
├── .github/ # Copilot エージェント構成・スキル
│ └── skills/ # 自作スキル
├── docs/ # ドキュメント・記事原稿
│ └── notes/ # 作業レポート
├── figure/ # 画像・図
├── work/ # 実作業ディレクトリ
この構成により、記事化したい内容は docs/notes/ に集約 しました。
Copilot CLI の BYOK 設定
Copilot CLI を起動する際、以下の環境変数を設定しています。
$env:COPILOT_PROVIDER_BASE_URL = "https://api.ai.sakura.ad.jp/v1"
$env:COPILOT_PROVIDER_TYPE = "openai"
$env:COPILOT_PROVIDER_API_KEY = "<my-token>"
$env:COPILOT_MODEL = "preview/Kimi-K2.7-Code"
COPILOT_MODEL は実際に試した中で、コーディング用途でそこそこパフォーマンスがある preview/Kimi-K2.7-Code を採用しました。他のモデルは呼び出し制限が厳しかったり、機能面で不足がありました。ただセッションが長引くと応答が不安定になったり中国語が出現することはありました。
基本ドキュメントとスキル
ドキュメント
-
docs/ワークスペース概要.md：キャンペーンの企画趣旨や無償枠についてのまとめ -
docs/環境構築.md：AI 導入までの手順メモ -
.github/copilot-instructions.md：Copilot 共通指針（日本語報告、配置ルール、機密情報非送信など）
スキル
- gitc-ommit-rules：コミットメッセージの形式とルールを定義。特にコミット前の API キー・個人情報チェックを重視しています。
-
article-report：作業内容を
docs/notes/にレポート化し、記事化タスクを TODO として起票する仕組みです。
スキル化することで、同じ作業を繰り返す際の手順が安定し、キャンペーン活動中も一定の品質を保てるようになりました。
ハマったこと：並列 subagent でレートリミットに到達
環境構築中に skill-creator でスキル評価を行おうと、8 個ほどの subagent を同時に起動しました。結果として、1 分間で 100 リクエスト超が瞬時に消費され、以下のような rate limit エラーが発生しました。
Failed to get response from the AI model; retried 5 times (total retry wait time: 387.22 seconds)
Last error: 429 rate limit exceeded
月間 3,000 リクエストの無料枠はあるものの、並列実行のコストが想像以上に高いことが判明しました。
対策
この事態を受け、 .github/copilot-instructions.md に 以下の注意事項 を追記しました。
重要：月間 3,000 リクエストの制限があるため、トークン数よりも API リクエスト数 を最小化すること。安易な並列処理や大量の単純リクエストは 禁止 です。
具体的な対策は次の通りです。
- subagent の並列実行は避ける
- 直接検証できる箇所は自分で手作業する
- 単純な grep・ファイル操作はツールで完結させる
- スキル評価は最小構成で実施する
これにより作業速度はやや低下しましたが、リクエストを無駄に消費せずに継続できています。
リクエスト消費の実情
環境構築〜スキル整備まで
環境構築から基本スキル作成までで、実際に消費したリクエストは約 270〜300リクエストでした。内訳としては：
- 通常の対話・ファイル作成・軽微な修正：約 100〜150リクエスト
- 並列 subagent 評価の失敗：100リクエスト以上
後者がなければ、もっと少ないリクエストで済んでいたことがわかります。並列実行の魅力はありますが、無償枠を意識する場合は慎重に使う必要があります。ある程度定型化できていればそもそもすべてをAI使う必要もありません。今回は3000リクエスト消費するという趣旨からすべてAIを活用しました。
企画選定まで
本企画選定で消費したリクエストは約80リクエストでした。内訳は以下のようなイメージです。
- 既存152記事の取得・分析：数リクエスト
- 30案のブレインストーミング：数リクエスト
- 5名の審査員への採点依頼：約60〜70リクエスト
- スコア集計・レポート作成：数リクエスト
3,000リクエストの中で環境構築から企画選定に~400リクエストしか使わなかったため、残りのリクエストは本実装に回せます。
企画選定：152件の既存投稿を分析する （※実際の起票数はこの時点で137件だったため一部対象外の記事も含んでしまっています）
「さくらのAI Engine」の無料枠は月3,000リクエスト。この制限の中で「どう使い倒すか」を記事にするキャンペーンに参加しようと思ったとき、最初にぶつかるのが「何を書くか」の問題です。
「AIに小説を書かせる」「AIにコードレビューさせる」「AIにゲームを遊ばせる」。思いつく企画はいくつもありますが、Qiitaで検索するとすでに似たような記事が山ほどある。そこで私は、既存のキャンペーン投稿152件を分析し、30の企画案をブレストして、5名のAI審査員に採点してもらうことにしました。
なぜAI審査員を使ったのか
企画選定は、一人でやると自分の好みに引っ張られがちです。特に「これ面白そう！」と思った案が、実は既存記事と被っていたり、実装が重すぎたりするのを客観的に見るのは難しいです。
そこで、複数の視点を持ったAI審査員を並列で動かし、各企画を採点してもらうことにしました。審査員それぞれに異なる評価軸を与えることで、盲点を減らし、自分だけでは気づけなかった落とし穴を発見できました。
例えば、「AIずんだもんに毎朝起こしてもらう」という企画は、自分にとっては面白く感じました。しかし実現可能性審査員からは「音声合成の無償枠は月50回なので、3,000回の音声生成は不可能」という指摘が入り、即座に落選となりました。こうした制約条件を客観的に洗い出せたのは、多角的な審査の大きなメリットでした。
152件の既存投稿を分析する
まず、自分が思いついた企画が既存記事と被っていないか調べる必要があります。キャンペーンページはクライアントサイドレンダリングだったため、静的HTMLからは記事一覧が取得できませんでした。そこで、Qiita APIを使ってタグ さくらのAI の記事を取得しました。
https://qiita.com/api/v2/tags/さくらのAI/items?per_page=100&page=1
https://qiita.com/api/v2/tags/さくらのAI/items?per_page=100&page=2
結果、152件の記事が見つかりました。取得したデータはタイトル、いいね数、ストック数、タグ、ユーザー、URL、投稿日時を含み、CSV的な集計がしやすい形で保存しました。
いいね数トップ10
| 順位 | タイトル | いいね | ストック |
|---|---|---|---|
| 1 | さくらのAI Engine「3,000リクエスト無料」を使い倒す ― 1回に11万トークン詰め込んでAIにWeb情報を丸飲みさせてみた | 19 | 5 |
| 2 | さくらのAI Engineに書いてもらったコードで、さくらのAI Engineの「ずんだもん」に毎朝私は起こしてもらう | 13 | 3 |
| 3 | さくらのAI Engine無料枠でgpt-oss-120bを使う ― Anthropic SDKはauth_token=必須の罠 | 11 | 5 |
| 4 | Kimi-K2.6、Qwen3.6、gemma-4、勝つのはどれだ！無料オープンLLM対決！ | 11 | 1 |
| 5 | さくらのAI Engineのモデルに人狼をやらせて比較してみた | 10 | 1 |
| 6 | 【毎日自動更新】さくらのAI Engine 3,000リクエスト使い切りチャレンジ いいねランキング！ | 9 | 0 |
| 7 | さくらのAI Engineで自作MCPサーバー×LangGraphエージェントを構築した話 | 8 | 0 |
| 8 | さくらのAIと話したかっただけなのに。。。人生初APIで、会話履歴をJSON保存し始めたセキュリティエンジニアの話 | 7 | 1 |
| 9 | AIエージェントを自作して、やっと「ループエンジニアリング」の意味がわかった | 6 | 3 |
| 10 | Sphinxドキュメントを読んで答えてくれる：さくらのAI Engineで実現するAIチャットボット | 6 | 3 |
上位記事を見ると、大きく分けて2つのパターンがあります。
パターンA：驚きの数字や規模で勝負
- 1回に11万トークン詰め込む
- 3,000リクエスト使い切りチャレンジ
- 複数モデルの対決
パターンB：独自の切り口やキャラクターで勝負
- ずんだもん
- 人生初APIの体験記
- ループエンジニアリング
つまり、「数字がでかい」か「他にない切り口がある」かのどちらかが必要です。両方を満たせれば最高ですが、少なくともどちらかは押さえた企画にする必要があります。
既存記事のカテゴリ分類
152件のタイトルとタグを見て、以下の7カテゴリに集約しました。
1. ゲーム・エンタメ系
人狼、将棋、TRPG、恋愛シミュレーション、クイズなど。特に「AI人狼」は10いいねを超える高評価記事があり、このジャンルは読者の関心が高いことがわかります。ただし、強者が既にいるため差別化が鍵です。
2. 創作系
小説、漫画、絵画、ずんだもん。「さくらAIで転生小説を書いてみる」シリーズは複数回続いている人気企画です。長編創作は読者を引き込みますが、同時に競争も激しいです。
3. 開発支援系
コードレビュー、ペアプロ、テスト生成、MCPサーバー、LangGraphエージェント。技術的な深みがあり、エンジニア読者には刺さりやすいジャンルです。ただし、Claude CodeやCursorを絡めた記事が多く、差別化が必要です。
4. ベンチマーク・実験系
モデル対決、プロンプト最適化、大容量プロンプト。数値で語れるため説得力がありますが、shibacorgi氏やtorifukukaiou氏のような強力な投稿者が既にいます。
5. マルチモーダル系
画像認識、音声合成、3Dモデル。まだ件数は少ないものの、torifukukaiou氏のずんだもん記事が強く、音声系は月50回のTTS上限がネックになります。
6. ビジネス・実用系
FAQ Bot、SNS運用、翻訳要約、カスタマーサポート。業務活用の視点で読者を獲得できますが、PoCの説得力を出すにはデータが必要です。
7. 初心者向け体験記系
初めてのAPI、人生初のAI活用、初学者チャレンジ。ファーストステップ賞の対象になりやすく、共感を得やすいジャンルです。
この分析から、ゲーム・創作・ベンチマーク系は競争が激しく、マルチモーダル・社会シミュレーション系はまだ空白地帯があると判断しました。
30企画のブレインストーミング
既存記事の傾向を踏まえ、7カテゴリで30案を作りました。すべての企画に「3,000リクエストをどう消費するか」を明確に設定しています。
ゲーム・エンタメ系（#1〜#7）
- AIマーダーミステリー：3,000リクエストで何回事件を解決できるか
- AI人狼：3,000リクエスト対戦ログ
- AIダンジョン：無限に広がる3,000階ダンジョン
- AI TRPGマスター：3,000リクエストで長編キャンペーン
- AIクイズ王：3,000問連続出題チャレンジ
- AI創作：3,000リクエストで長編小説を完結させる
- AI恋愛シミュレーション：3,000通の返信で攻略する
開発支援・自動化系（#8〜#12）
- 1ファイル1リクエストのAIコードレビューBot
- AIペアプロ：3,000回ペアプロしてみた
- AIテスト生成工場：3,000本のテストを自動生成
- ドキュメント自動翻訳・要約：3,000ページ翻訳
- エラーログ診断AI：3,000件のエラーを解析
AIエージェント・自動化系（#13〜#17）
- マルチAIエージェント会議室：3,000回議論させて結論を導く
- AI日記生成：3,000日分の日記を書かせた
- AIニュース要約Bot：3,000記事を要約
- AIソーシャルメディア運用：3,000投稿を自動生成
- AI顧客対応Bot：3,000通の問い合わせ対応PoC
ベンチマーク・実験系（#18〜#20）
- モデル対決：3,000リクエストで全モデルベンチマーク
- 大容量プロンプト実験：1回11万トークンを超えて
- プロンプト最適化実験：3,000通のプロンプトをA/Bテスト
マルチモーダル系（#21〜#24）
- 画像認識×LLM：3,000枚の画像を分析
- AIずんだもん：毎朝3,000回起こしてもらう
- AI音声Podcast生成：3,000回の会話でラジオ番組を作る
- AI読み上げ図書館：3,000ページを朗読
教育・初心者向け系（#25〜#28）
- 「初めてのAPI」3,000リクエスト使い切りログ
- ノーコードで作る「3,000回話せるAIチャットボット」
- 小学生でも作れる「3,000問AIクイズアプリ」
- お母さんのための「3,000回おしゃべりAI」
実験・社会シミュレーション系（#29〜#30）
- AI街づくりシミュレーション：3,000人の住民が住む都市
- AI神託：3,000回おみくじを引く
この中で特に重要なのは、「3,000」という数字をカウントしやすい単位に落とし込むことです。1階＝1リクエスト、1人＝1リクエスト、1日＝1リクエスト、1問＝1リクエスト……。こうした設計が、記事のキャッチーさと使い倒し感の両方を演出します。
5名のAI審査員による多角レビュー
30案を一人で評価するのは視点が偏るため、5名の専門審査員サブエージェントを並列で起動しました。それぞれに以下の審査軸を与え、各企画を1〜10点で採点してもらい、短評と改善提案を出力してもらいました。
審査員と審査軸
| 審査員 | 審査軸 | 重み |
|---|---|---|
| 使い倒し賞審査員 | 「さくらのAI Engine」をいかに使い倒しているか | 0.25 |
| エンゲージメント審査員 | いいね・ストックを集めやすいか | 0.25 |
| 独創性審査員 | 既存152記事との差別化 | 0.20 |
| 実現可能性審査員 | 無償枠内で1〜2週間で完走できるか | 0.15 |
| ファーストステップ賞審査員 | 初心者が再現しやすいか | 0.15 |
重み付けの理由は、キャンペーンの「使い倒したで賞」と読者反応を最重視しつつ、差別化と実現性、初心者向けのバランスも考慮するためです。
総合スコアの計算式
総合スコア = 使い倒し×0.25
+ エンゲージメント×0.25
+ 独創性×0.20
+ 実現可能性×0.15
+ ファーストステップ×0.15
審査員への指示のポイント
各審査員には、以下のような共通指示を与えました。
- 30案すべてに1〜10点のスコアをつける
- 各案に短評と改善提案を書く
- 既存152記事との重複リスクを考慮する
- 音声合成などのAPI制約を考慮する
- 3,000リクエスト以内で完走できるかを意識する
審査員ごとに出力形式を指定しましたが、実際には少しばらつきが出たため、後でPythonスクリプトを使ってスコアを抽出・正規化しました。
スコアの集計
審査員の出力はMarkdownファイルで、形式がそれぞれ異なっていました。
- 使い倒し賞：
## N. 企画名→- **点数：8** - ファーストステップ賞：テーブル形式
| N | 企画名 | 点数 | ... | - エンゲージメント賞：
### N. 企画名→- **点数：8 / 10** - 独創性賞：
### N. 企画名→- **点数：8点** - 実現可能性賞：テーブル形式
| # | 企画名 | 点数 | ... |
そこで、正規表現を使って各ファイルからスコアを抽出するPythonスクリプトを作成しました。
このスクリプトで30案×5審査員＝150個のスコアを一括抽出し、総合スコアを計算しました。
審査結果：Top 5
30案の総合スコアを集計した結果、以下の5案が選ばれました。
| 順位 | # | 企画名 | 使い倒し | ファースト | エンゲージ | 独創性 | 実現性 | 総合スコア |
|---|---|---|---|---|---|---|---|---|
| 1 | 29 | AI街づくりシミュレーション「3,000人の住民が住む都市」 | 8 | 3 | 8 | 8 | 5 | 6.80 |
| 2 | 1 | AIマーダーミステリー「3,000リクエストで何回事件を解決できる？」 | 8 | 4 | 8 | 6 | 6 | 6.70 |
| 3 | 3 | AIダンジョン「無限に広がる3,000階ダンジョン」 | 7 | 6 | 6 | 6 | 8 | 6.55 |
| 4 | 14 | AI日記生成「3,000日分の日記を書かせた」 | 6 | 6 | 6 | 6 | 8 | 6.30 |
| 5 | 21 | 画像認識×LLM「3,000枚の画像を分析」 | 7 | 5 | 7 | 5 | 6 | 6.15 |
1位：AI街づくりシミュレーション「3,000人の住民が住む都市」
3,000人のAI住民にそれぞれ個性・職業・人間関係を持たせ、日々の行動ログを生成。人口動態、経済、事件、幸福度などをシミュレートします。
審査員コメントの要点
- 使い倒し賞審査員（8点）：「3,000人の住民生成は壮大で、使い切り感と独自性が高い」
- 独創性審査員（8点）：「3000人のAI住民による社会シミュレーションは既存記事と大きく差別化できる。技術的な深みとエンタメ性の両方がある」
- エンゲージメント審査員（8点）：「『シムシティ×AI』の独創性が高く、住民の行動ログや社会現象の発生は読者を引き込む」
課題と改善提案
ファーストステップ賞審査員からは「3,000人分の個性生成と行動ログの設計は重い」との指摘がありました。実現可能性審査員も「行動ログの一貫性と可視化が重い」と減点しています。
そこで、最初は住民を50〜100人の小さな町に縮小し、1日分の行動ログだけを可視化するミニマム版から始めるのが良さそうです。都市指標（犯罪率・幸福度・人口動態）をグラフ化し、社会シミュレーションの法則性を分析することで、技術的な深みと読者の興味を両立できます。
狙い
「使い倒したで賞」と「独創性」の両方を高く満たしており、可視化の余地も大きいため、記事化しやすい企画です。
2位：AIマーダーミステリー「3,000リクエストで何回事件を解決できる？」
AIが犯人・手口・証拠・NPC証言を自動生成し、プレイヤーが推理して事件を解決。3,000リクエストで何回事件を解決できるかをチャレンジします。
審査員コメントの要点
- 使い倒し賞審査員（8点）：「1プレイあたりの消費を明示し、3,000回まで到達する過程が物語になる。人狼と比べてマーダーミステリーは既存記事が少なく、推理要素も読者の興味を引く」
- エンゲージメント審査員（8点）：「既存152記事にはない『推理ゲーム×回数チャレンジ』で、タイトルの数字もキャッチー。プレイログや勝率グラフを出しやすく、読者の『結果が気になる』心理を刺激する」
課題と改善提案
ファーストステップ賞審査員からは「シナリオ・NPC・証拠の生成と推理判定を同時に組み立てるため、初心者が再現するには構成が複雑すぎる」との指摘がありました。
改善案として、証拠と推理フォーマットを固定テンプレート化し、AIは演出と判定のみ担当する方式にします。さらに、各NPCに「信念」「嘘つき確率」「証拠との整合性」パラメータを設計し、それらが推理の勝率に与える影響を可視化すると、技術的な読み応えが出ます。
狙い
エンゲージメントが非常に高く、バズりやすいタイトルです。「マーダーミステリー」というジャンル自体が既存記事ではあまり見られないため、差別化にも有利です。
3位：AIダンジョン「無限に広がる3,000階ダンジョン」
1階＝1リクエストで、AIが次々と階層を生成するローグライクダンジョン。3,000階到達を目指し、ボス・ドロップ・到達不能階層の法則性を分析します。
審査員コメントの要点
- 実現可能性審査員（8点）：「1階＝1リクエストの設計はシンプルで実行しやすい。状態管理と階層データの永続化さえ決めれば3,000階完走は現実的」
- 使い倒し賞審査員（7点）：「『1階＝1リクエスト』という数字の分かりやすさが強い。既存でダンジョン系は少なく、到達階層やドロップアイテムの可視化で記事が映える」
課題と改善提案
エンゲージメント審査員からは「既存の『ゲーム×AI』記事が多く、目新しさは中程度」との指摘がありました。そこで、ボス階やレアドロップの出現確率、パーティ編成のメタ分析を追加し、到達階層ごとの統計（死亡率・ドロップ率）を可視化すると読み応えが出ます。
狙い
「1階＝1リクエスト」という明快さが強く、短期間で完走しやすいのが魅力です。ローグライクファンにも刺さりやすく、ランキング形式で読者参加型にもできます。
4位：AI日記生成「3,000日分の日記を書かせた」
架空人物に3,000日分の日記を書かせ、感情スコア推移・使用単語の変化・人生イベントの検出などを時系列分析します。
審査員コメントの要点
- 実現可能性審査員（8点）：「プロンプト1つで大量生成でき、3,000日分の時系列分析（感情推移・単語変化）も簡単に可視化できる」
- ファーストステップ賞審査員（6点）：「プロンプトが単純で、初心者にも実装しやすい」
- エンゲージメント審査員（6点）：「『架空人物の成長』を追うという物語性があり、SNSシェアされやすい」
課題と改善提案
使い倒し賞審査員からは「3,000日分の連続生成は規模感があるが、単調になりやすく記事の起伏が弱い」との指摘がありました。
年表形式で重要イベントをマークし、ワードクラウドで使用単語の変化を可視化すると、記事に起伏が出ます。また、架空人物ではなく「AIが観測する仮想社会」を設定し、社会的トピックの変遷も分析すると、ファーストステップ賞にも技術的な深みも両立できます。
狙い
実装が最も軽く、初心者向けに再現しやすい。ファーストステップ賞を狙いつつ、時系列分析で技術的な見せ場も作れます。
5位：画像認識×LLM「3,000枚の画像を分析」
Vision対応のLLMを使い、3,000枚の画像を分類・OCR・要約・比較分析する。マルチモーダル性能を定量的に検証します。
審査員コメントの要点
- 使い倒し賞審査員（7点）：「Vision対応でマルチモーダル。3,000枚の分析は規模感があり、分類やOCRの実用評価として強い」
- エンゲージメント審査員（7点）：「Vision対応モデルの検証記事はまだ少なく、3,000枚というスケールも目を引く。画像付きの分析結果は視覚的に強い」
課題と改善提案
独創性審査員からは「マルチモーダル画像分析はtorifukukaiou氏ですでに実施済み」との指摘がありました。また、実現可能性審査員も「画像収集・保存・API送信のパイプライン構築が工数を食う」と減点しています。
公開画像データセット（CIFAR-10、Unsplash等）を使い、画像カテゴリ別の認識精度ヒートマップと、特に失敗した事例をまとめた「LLM Visionの落とし穴」を強調すると差別化できます。人手ラベルとの比較で正解率を定量化し、モデル間のVision性能差を示すことも有効です。
狙い
マルチモーダルは技術的な注目度が高く、画像付きの分析結果は記事に迫力があります。既存記事との差別化を意識すれば、強い記事になります。
意外と落ちた企画たち
上位に入らなかった企画の中には、一見魅力的な案もありました。主な落ちた理由は以下の通りです。
| 企画 | 総合スコア | 落ちた理由 |
|---|---|---|
| AI人狼「3,000リクエスト対戦ログ」 | 4.05 | 既存の高評価「AI人狼」記事と被る |
| AI創作「3,000リクエストで長編小説を完結させる」 | 4.05 | 既存の「さくらAIで転生小説」シリーズと被る |
| AIずんだもん「毎朝3,000回起こしてもらう」 | 3.05 | 既存記事と強く被り、TTSの50回上限に抵触 |
| 大容量プロンプト実験「1回11万トークンを超えて」 | 3.65 | 既存の高評価記事とほぼ同じコンセプト |
| マルチAIエージェント会議室 | 3.90 | 既存の「AIに議論させた」記事と酷似 |
| モデル対決「3,000リクエストで全モデルベンチマーク」 | 4.55 | 既存のモデル対決記事が複数あり、差別化が弱い |
共通する教訓：「面白いこと」をやるだけではなく、「既存にはない切り口」か「規模・指標・可視化で差別化できるか」が重要です。特に、すでに強い投稿者がいるジャンルで同じことをやろうとすると、読者の注目を集めるのは難しくなります。
この企画選定で学んだこと
1. 「3,000」の数え方を設計する
「3,000回AIに話しかける」だけでは、読者に「使い倒した感」を伝えにくいです。「1階＝1リクエスト」「1人＝1リクエスト」「1日＝1リクエスト」など、カウントしやすい単位に落とし込むと、記事のタイトルにもなり、進捗の可視化にも繋がります。
2. 既存記事との重複は最初に潰す
Qiita APIで152件を取得し、タイトルやタグで傾向を把握してから企画を立てました。「人狼」「ずんだもん」「11万トークン」などは、すでに強い記事があるため、無理に挑むのは避けるべきです。
とはいえ、これらの人気ジャンルを完全に避ける必要はありません。例えば「AIマーダーミステリー」はゲーム系に属しつつも、人狼とは異なる切り口なので高評価になりました。重要なのは、同じジャンルでも異なる軸を持つことです。
3. 多角的な審査員を使うと客観性が上がる
一人で採点すると、自分の好みに引っ張られます。5名のサブエージェントにそれぞれ違う軸を持たせることで、盲点に気づけました。特に「音声合成の上限」は、実現可能性審査員が指摘して初めて重視しました。
審査員の数を増やせば増やすほど客観性は上がりますが、コストも増えます。今回は5名がちょうど良いバランスで、各企画について3〜5文の短評と改善提案を得ることができました。
4. 可視化が記事力を左右する
Top 5の企画はどれも、グラフや図で結果を示しやすいという共通点があります。AI街づくりの都市指標、AIマーダーミステリーの解決率グラフ、AIダンジョンの到達階層分布、AI日記の感情推移、画像認識の精度ヒートマップ……。数値とビジュアルの両方で語れる企画は、Qiita読者にとって読みやすく、ストックされやすいです。
企画選定のフレームワークとして使う
この手法は、さくらのAI Engineのキャンペーンだけでなく、他のQiitaキャンペーンや技術記事の企画選定にも応用できます。フレームワークとしてまとめると以下のようになります。
Step 1：既存記事を収集する
- キャンペーンタグや関連タグでQiita APIを検索
- タイトル、いいね数、ストック数、タグを取得
- カテゴリ別に集計し、人気テーマと空白地帯を把握
Step 2：制約条件を整理する
- 無料枠のリクエスト数
- APIの機能制限（音声合成の回数上限など）
- 自分の実装可能期間
Step 3：企画案をブレストする
- 10〜30案程度をカテゴリ別に出す
- 各案に「リクエスト消費設計」を明確に設定
- 「数字の数え方」を意識する
Step 4：多角的に審査する
- 使い倒し、エンゲージメント、独創性、実現性、ファーストステップなど、複数の軸で審査員を用意
- 各審査員にスコアと短評・改善提案を出力させる
Step 5：スコアを集計してTopを選ぶ
- 重み付けした総合スコアでランキング化
- カテゴリバランスや既存記事との重複も加味して最終選定
今後の予定
ここまでAIにブレストをさせてみたものの実のところ正直ピンとくるものがなかったため何か自分で考えて3000リクエスト消費を目指します。残りあと２日。。。
最終的に選んだ作業記録は、また別の記事で共有する予定です。
まとめ
- さくらのAI Engineを Copilot CLI（BYOK）で使うことで、既存ワークフローを崩さずに個人作業環境を構築できた
- 並列 subagent はリクエストを急激に消費するため、無償枠運用では節約が必須
- 既存152件を分析し、重複リスクを事前に把握した
- 30案をブレストし、5名のAI審査員で多角的に評価した
- 総合スコアでTop 5を選出。1位は「AI街づくりシミュレーション」
- 企画選定の消費は約80リクエストに抑えられた
- 重要なのは「数字の数え方」「既存との差別化」「可視化のしやすさ」