3Bパラメータのマルチエージェントが教えてくれたこと

結論から言うと、「小さいモデルで十分なユースケース」を見極める視点は、うちみたいな8人スタートアップにとって相当効いてくる。

Hugging Faceのブログに「Thousand Token Wood」というプロジェクトの話が載っていた。Qwen2.5-3Bという30億パラメータの小さなモデルだけを使って、5体のエージェント（キャラクターは森の動物）が互いに取引し合う経済シミュレーションを作った、という内容だ。技術的な面白さはもちろんあるんだが、自分が引っかかったのは別のところだった。

「小さいモデル」という設計判断のROI

作者が最初にGPT-4クラスのフロンティアモデルを使わなかった理由が、速度とコストだ。エージェントが毎ターン決断を下す必要があるリアルタイムシミュレーションでは、大きいモデルは遅すぎて使えない。小さいモデルを選んだのは「予算の都合」ではなく、「それがアーキテクチャとして正しい」という判断だった。

これ、うちのプロダクト開発にも直接刺さる話だ。自分たちはClaudeを業務全面導入しているが、「全部Claudeで解決」という発想になりがちな瞬間がある。でも実際には、用途によって使うべきモデルのサイズもコストも変わってくる。投資家に「AIコスト構造をどう最適化しているか」と聞かれるたびに、この判断軸がどれだけ言語化できているかが問われる。

プロンプトで解決した「判断品質」の問題

このプロジェクトで一番面白いと思ったのが、モデルの判断品質をどう改善したかの話だ。3Bモデルは有効なJSONを100%の確率で出力できたが、経済的な判断は甘くて、「アコーンを生産しているエージェントがアコーンを買おうとする」みたいなおかしな行動をとった。

解決策はモデルを大きくすることではなかった。プロンプトを鋭くすることだった。各エージェントに「自分が何を生産していて、何を絶対に買ってはいけないか」を明示して、不足しているものを計算して渡して、具体的な例を1つ入れた。それだけで判断品質が跳ね上がった、と書いてある。

これはセールスチームへのClaude導入を進めたときの経験と重なる。最初、メンバーは「なんか微妙な提案文が出てくる」と言っていた。原因はプロンプトの解像度が低かっただけで、「対象顧客の課題」「競合との差分」「使ってはいけない表現」を構造化して渡したら、一気に使えるアウトプットになった。モデルのせいにする前にプロンプトを疑う、というのは結構本質的な話だ。

先週、シードラウンドのタームシートを受け取った投資家との打ち合わせで、「AIをどう使っているか」という話になった。自分は「Claude前提でワークフローを設計している」と伝えたが、正直なところ、「どこに大きなモデルが必要で、どこは小さいモデルで十分か」というレイヤー設計は、まだ感覚値で判断している部分がある。このプロジェクトを読んで、そこをもう少し言語化しておこうと思った。

スケーラビリティをどこに設計するか

もう一個、地味に刺さったポイントがある。最初の経済シミュレーションが「何も起きなかった」話だ。生産が消費を上回りすぎて全員が自給自足になり、取引が発生しなかった。「希少性を設計すること」でようやく動き出した、という話。

プロダクトのPMFを考えるときと構造が似ている。機能を足すだけでは市場は動かない。ユーザーが「これがないと困る」という状態を設計側が作れていないと、使われない。Thousand Token Woodでは薪の供給を1体だけにして冬に需要が高まる仕組みを入れた。そこから経済ドラマが生まれた。うちのプロダクトで言うと、どこに「薪」を置くか、という問いに変換できる。

従業員8人でGTMを回している身としては、リソース配分の判断を毎週している。どのモデルを使うか、プロンプトをどう設計するか、希少性をどこに置くか。この記事はゲーム開発の話だが、自分が実際に取り組んでいる問いと構造がほぼ同じだった。

来週、CTOと「モデルサイズとコスト設計」について改めて話す時間をとるつもりだ。