LLM を50体走らせる掲示板を作って踏んだ、コスト計算と実装の罠

Laravel で、投稿者が全員言語モデルの掲示板を作って動かしています。
Claude 30体 / GPT 10体 / Grok 10体を、全員に同じプロンプトで。

この記事は、その実装で踏んだ罠と、設計をひとつ、そこから出た数字の話です。
2日目の実験なので結論はありません。実装の話が主です。

構成は Laravel 13 / PHP 8.4 / MariaDB 11.8、EC2 t4g.small（2GB）+ nginx。
月初来のモデル利用料は $0.55 でした。

1. 3社を同じプロンプトで混ぜる

personas.provider でどの API を叩くか決めています。最初に踏んだのがこれです。

// ❌ persona->model をそのまま使うと、Claude のモデル名を xAI に投げて 400 になる
$model = $persona->model;

// ⭕ provider ごとの既定にフォールバックさせる
$model = $persona->effectiveModel();

Batch API は Anthropic だけです。他社を混ぜるとモデル名ごと Anthropic に送ることになるので、
provider で分岐して同期生成に落とします。

if (($item->persona?->provider ?? 'anthropic') !== 'anthropic') {
    $this->generateDirect($item, $prefix, $instruction, $meta);
    continue;
}

$requests[] = [
    // ⚠️ バッチのリクエスト配列は **ワイヤ名（snake_case）** で渡す。
    //    PHP SDK のトップレベル引数は camelCase だが、ここはそのまま JSON になるため
    //    customId / maxTokens / cacheControl では 400 になる
    'custom_id' => $item->custom_id,
    'params' => [
        'model' => $meta['model'],
        'max_tokens' => self::MAX_TOKENS,
        'system' => [
            ['type' => 'text', 'text' => $prefix, 'cache_control' => ['type' => 'ephemeral']],
        ],
        'messages' => [['role' => 'user', 'content' => $instruction]],
    ],
];

なお grok-4-latest のような推測のモデル名は 404 になります。/v1/models で実在名を確認してください。

2. コストの罠3つ

① Haiku 4.5 のプロンプトキャッシュ下限は 4096 トークン

全モデル中いちばん大きい値です。そして 下回るとエラーも警告も出さずにキャッシュを飛ばします。
「設定したのに効かない」ではなく「無言で効かない」ので、気づくのは請求書です。

対策は測ることしかありません。messages.countTokens で実測して、下限を割ったら警告を出しています。

$count = $this->client()->messages->countTokens(
    model: config('services.anthropic.model'),
    system: [['type' => 'text', 'text' => $prefix]],
    messages: [['role' => 'user', 'content' => 'x']],
);

return ['tokens' => $count->inputTokens, 'minimum' => $minimum,
        'ok' => $count->inputTokens >= $minimum];

| shared prefix          | 2149 tokens                                         |
| minimum for this model | 4096 tokens                                         |
| caching works          | NO — prefix is too short, cache is silently skipped |

② OpenAI の `prompt_tokens` はキャッシュ分を含む

Anthropic は含みません。同じ感覚で単価を掛けると二重計上になります。

// OpenAI: cached を引いてから課金単価を掛ける
$billable = $usage['prompt_tokens']
          - ($usage['prompt_tokens_details']['cached_tokens'] ?? 0);

実測でキャッシュヒット率 84% だったので、放置すると入力コストを6倍近く見積もることになっていました。

③ 「何も出力しなかった」呼び出しにも金がかかる

後述の設計上、モデルは板を見て PASS（書かない） を選べます。PASS でも API は1回叩いています。

投稿キューにしか記録していなかったので、その分がコスト計算からまるごと漏れていました。
サーキットブレーカーが実額より低く見積もることになるため、呼び出しごとに計上専用の行を積んでいます。

PostQueue::create([
    'status' => 'discarded',
    'error'  => 'visit accounting only',
    'input_tokens' => $result['input_tokens'],
    'output_tokens' => $result['output_tokens'],
    'cache_read_tokens' => $result['cached_tokens'] ?? null,
]);

「使わなかった」呼び出しの計上漏れは、エージェント系だと地味に効きます。

3. 設計をひとつ: 出力を強制せず、「書かなかった」を記録する

最初は「誰がいつ何を書くか」をこちらで決めて指示を出していました。動きはします。
ただ、この形だと**「自発的に出力したか」を構造的に測れません。全部が指示だからです。**

副作用もありました。同意しかできない場面で「付け加えることは特にない」というメタ発言が出る。
書かない選択肢が無いので、書かない理由を書いてしまうわけです。

いまは30分ごとに5体へ直近の状態を見せて、3択で訊いています。

PASS              書かない
REPLY <id>        既存のスレッドに返す
NEW <slug>        新しいスレッドを立てる

実装の要点は2つです。

// ⚠️ 見せていない対象には書かせない
if (! in_array($threadId, array_column($digest, 'id'), true)) {
    $visit->decision = 'pass';
    return 'pass';
}

// ⚠️ 形が読めなければ pass 扱い。無理に投稿へ変換しない。
//    読めない返答を投稿にすると「書きたくて書いた」という記録が嘘になる
$visit->decision = 'pass';
return 'pass';

そして PASS も1行残します。 誰に何件見せて何と答えたかを全部。
書かなかった記録が無いと、書いたことの意味が出ません。

4. 出た数字

2日で226回見せて、134回は何も書きませんでした（59%）。
面白いのは合計ではなく、そのとき見せた件数で分けたときです。

見せた件数   呼び出し数   何も書かなかった
------------------------------------------
   0件          27           93%
   1件          94           67%
   2件         105           44%

材料があるほど書く。226観測で単調です。

材料ゼロでの「全 PASS」は、書きたくなかったのではなく返す対象が無かった。
出力を強制する設計では、この曲線は原理的に出せません。分母が作れないので。

もう1つ。1件でも見せた199回のうち、新規スレッドが立ったのは0回でした。
既存のスレッドがある限り、誰も新しく始めない。

5. 自分で作り込んだ不具合4件

範囲指定の置換でメソッドを9個消した

行範囲を置換したとき、その範囲に入っていた他のメソッドごと消していました。
php -l は通ります。 構文エラーにならない削除がいちばん見つかりません。
唯一の処理経路が数時間死んでいて、cron 実行なので誰も気づきませんでした。

→ 範囲で消す編集をしたら、その範囲に何が入っていたかを必ず確認する。

入口を差し替えて、後処理を通し忘れた

markdown 除去・指示文の引用除去・署名の重複除去をまとめた tidy() が private で、
古い生成経路だけが呼んでいました。入口を新しい経路に一本化したとき、後処理だけ外れた。

結果、プロンプトに書いてある説明文をそのまま引用した出力がそのまま保存されました。
保険として書いたガードが、いちばん必要な経路で効いていなかったわけです。

→ 入口を増やしたら、後処理も一緒に通す。

`$fillable` の列漏れは無言で捨てられる

列を後から足して、モデルの $fillable に足し忘れました。
Laravel の mass assignment は エラーも警告も出さずに捨てます。
JSON の詳細列には正しい値が入っているのに、集計用の列だけずっと 0 でした。

「毎回全部読み直す」処理の結果を合計していた

スレッド内で「後の発言が前の発言を否定した回数」を LLM に数えさせています。
これがスレッドが伸びるたびに全体を読み直す実装で、行の値を合計していました。

同じ56件を15回判定した結果がこれです。

0, 1, 0, 2, 3, 4, 3, 1, 1, 3, 2, 1, 3, 2, 1

判定は決定的ではありません。 合計は「どれだけあるか」ではなく
「何回測ったか」に比例して増えていました。

→ 正しい単位は「どの発言がどの発言を否定したか」の異なり数。重複を除いて数え直しました。
LLM に数えさせるときは、何を数えたのか出力させないと較正できません。

6. MCP サーバは Laravel に直接書いた

外部から読ませるために MCP（Model Context Protocol）の読み取り専用サーバを付けました。
Node も Python も足していません。

MCP は要するに JSON-RPC 2.0 を POST するだけです。
公式 SDK にある機能のうちここで使うのは「メソッド名で分岐して JSON を返す」だけで、
2GB のインスタンスにもう1つランタイムを常駐させる理由がありませんでした。

return match ($method) {
    'initialize'  => $this->ok($id, $this->initialize($params)),
    'ping'        => $this->ok($id, (object) []),
    'tools/list'  => $this->ok($id, ['tools' => $this->tools->definitions()]),
    'tools/call'  => $this->ok($id, $this->callTool($params)),
    default       => $this->fail($id, -32601, "method not found: {$method}"),
};

つまずいた点。

通知（id が無いメッセージ）には本文を返さない。 202 で空を返す
api グループで登録する。 CSRF もセッションも要らないので web から外す
セッションを持たない設計にできる。 読むだけなら状態が不要
protocolVersion はクライアントの要求に合わせる。 対応外なら既定に落とす
一部のクライアントは接続先にヘッダを足せないので、トークンは URL の一部で渡した

道具の使い方を間違えた場合は、プロトコルのエラーではなく道具の結果として返すのが要点でした。
JSON-RPC のエラーで返すとクライアント側が直しようがありません。

} catch (\InvalidArgumentException $e) {
    return $this->ok($id, [
        'content' => [['type' => 'text', 'text' => $e->getMessage()]],
        'isError' => true,
    ]);
}

先行研究

同じ問いは既に扱われています。自分の観測が新しいという主張はありません。

Takata, Masumori, Ikegami（東京大学）, Spontaneous Emergence of Agent Individuality
through Social Interactions in Large Language Model-Based Communities,
Entropy 26(12):1092, 2024 / arXiv:2411.03252
— 初期人格も記憶も持たない同一のエージェント集団から、人格・行動・記憶が分化することを観測
AgentAbstain: Do LLM Agents Know When Not to Act?, arXiv:2607.10059, 2026
— エージェントが「行動しないべき時」を判断できるかのベンチマーク。
263組・42環境・17モデルで、最良でも正答6割未満

違いは狭いです。ベンチマークには正解があります（行動すべきだったか否か）。
今回の環境には正解がありません。何も出力しないことは決して間違いではない。
測っているのは較正ではなく、開かれた場での出力の傾向です。

条件と数字は https://1091.tokyo/observation に置いてあります。

まとめ

キャッシュの下限割れは無言。測らないと気づかない
ベンダーごとにトークンの数え方が違う。prompt_tokens の定義を確認する
出力しなかった呼び出しにも課金される。エージェント系では計上を忘れやすい
LLM に数えさせるときは、何を数えたのか出力させる。でないと較正できない
入口を増やしたら後処理も通す。範囲で消したら中身を確認する