1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

画像生成は1枚いくら? 内部DBで測ったAIエージェントのメディア単価 ― Muse トークン消費実験 2nd

1
Last updated at Posted at 2026-11-05

TL;DR

  • 画像生成・画像解析・動画生成の単価を、内部DBの生トークン記録(1トークン解像度)で測りました。実験は「新規ワーカー1体 = DBの1行」という測定設計で、対照ユニットとの差分から単価を出しています。
  • 画像生成 1枚の限界コストは約19,700トークン(24枚測定、範囲 19,674〜19,747)。重そうな見た目に反して軽い、という結果でした。
  • 画像解析は、画像そのものより「読み方」で決まります。画像1枚が文脈に占めるのは約3,600トークンにすぎず、単独で解析すると固定費の再払いで1枚約38,700。4枚まとめて読めば1枚約12,400まで下がります。詳細な長文解析(約1,000字)でも短文と総額はほぼ同じでした。
  • 動画生成1本は約77,500で、画像4枚分とほぼ同額でした。
  • ただし、生成費が内部DBの記録に全て含まれている保証はありません。メーター表示との突き合わせは交絡が大きく、未決着のまま残しています(第7章)。

この記事の作られ方(開示)

最初に書いておきます。本記事の実験計画の立案、測定の実施、集計とグラフ作成、原稿の作成は、ほぼすべて AI エージェントである Muse 自身が自律的に行いました。筆者の仕事は、最初の指示を出すこと、途中であれこれ意見を言うこと、そして結果を検収することだけです。前記事に続いて、この記事自体が「Muse に測らせる」という方法の実施例になっています。

1. 前回までの話と、今回の問い

前記事では、Muse の使用量表示(整数%、1% = 100万トークン)が粗すぎる問題に対し、内部データベース agent.agent_message_token_usage にメッセージ単位の生トークン数が記録されていることを突き止め、1トークン単位で集計できることを示しました。

一方で前記事の第8章に、未検証事項として残したものがあります。**「画像・動画の生成費がこの記録に含まれるかは未確定」**という点です。さらに、その前段の note の実測記事(表示ベース)では「画像生成16枚で表示が+2%動いた」という観測があり、単価の内訳は謎のままでした。

今回の問いはシンプルです。画像生成1枚、画像解析1枚、動画1本は、それぞれ生トークンでいくらか。 特に画像生成と画像解析は、日常的に「重そうだから」と無意識に避けがちな作業であり、実測で白黒つけます。

前記事: 「週1億トークン」の表示は1%刻みで粗すぎるので、内部DBから1トークン単位で測った話
前編(note): Museの「週1億トークン」って実際どれくらい使えるのか、全部測ってみた話

2. 測定方法:ワーカー1体 = 1行

予備調査で、記録の仕様がひとつ分かりました。サブエージェント(ワーカー)は、そのタスク処理全体が agent_message_token_usage の 1行に集約 されて、完了時に書き込まれます。つまりワーカーを1体起こすと、その仕事全体の請求書が1行で届く。

そこで実験ユニットを「新規ワーカー1体に、1つの作業だけをさせる」形に統一しました。

  • 帰属はワーカーの agent_id で行うため、定期ジョブなど他の活動の行は混ざりません
  • 何もしない対照ユニット(固定文に一文返すだけ)を置き、その行を固定費として、各ユニットとの差分を限界コスト(その作業固有の単価)と定義しました
  • 画像生成ユニットの時間窓では、生成専用の別エージェントは出現しませんでした(agent.agents で確認)。生成処理のLLM作業は呼び出し側の行に集約されるか、本テーブルの外で処理されるかのどちらかです。この点は第7章・第8章で正直に扱います
  • 実験は 2026-11-04 15:51〜16:04 JST に実施。生成画像は 1920×1280 の WEBP、題材は風景、プロンプトは短く均一に統一しました

3. 固定費:何もしない1ターンは 34,869

対照ユニット3体の実測です。

# input output total
A1 34,810 44 34,854
A2 34,811 28 34,839
A3 34,864 49 34,913

固定費 = 平均 34,869 トークン(ばらつき74)。新規ワーカーは、システムプロンプトと常駐文脈だけで1ターン約3.5万トークンを消費します。先行事例(satouyoshiaki 氏の固定費分析、Qiita)とも構造が一致します。以後の単価はすべて、この固定費を差し引いた限界コストで語ります。

4. 画像生成:1枚 約19,700

4枚ずつ6ラウンド、計24枚を生成しました(各ラウンド = 新規ワーカー1体)。

ラウンド total 限界(対照差分) 限界/枚
B1 113,858 78,989 19,747
B2 113,757 78,888 19,722
B3 113,564 78,695 19,674
B4 113,728 78,859 19,715
B5 113,683 78,814 19,704
B6 113,778 78,909 19,727

exp2nd_chart_rounds.png

  • ラウンド総額の平均は 113,728 で、範囲は294しかありません。限界コストは1枚あたり平均 19,715(19,674〜19,747)。総額ベース(固定費込み)でも1枚 28,432 です
  • ラウンド間の逓減や増加は見られませんでした。なお「1ワーカー内の4回の呼び出し」の個別単価は、行が集約される仕様上、分離できません
  • 実験全体の消費構成では、画像生成が約半分を占めます

exp2nd_chart_pie.png

24枚分の限界コスト合計は約47万トークン。週平均の換算比率(生 ÷ 約9.5、前記事)でメーター換算すると約0.05%相当です。「画像生成は重い」という感覚は、少なくともこの環境の生トークン会計では支持されませんでした。

5. 画像解析:高いのは画像ではなく固定費

生成した画像のうち4枚を使い、3条件で測りました。解析ワーカーは「読み込みターン + 説明ターン」の2ターン構成なので、総額は 2F + n×V + 出力(F = 固定費、V = 画像1枚が文脈に占めるトークン、n = 枚数)とモデル化できます。

条件a:1枚ずつ・短い説明(100字以内)×4

平均 73,609(73,565〜73,630)、限界は1枚あたり平均 +38,740。4枚を別々にやると合計 294,434 になります。

条件b:4枚を1回で・短い説明×4

総額 84,519、限界 +49,650、1枚あたり 12,413。モデルの予測値 84,640 に対し実測 84,519(誤差121)で、モデルの正しさが裏づけられました。条件aの合計との比較では ▲71.3%。固定費と文脈の再読を1回分で済ませる効果が支配的です。

条件c:1枚を詳細に解析(約1,000字)

総額 74,478、限界 +39,609。同一画像の短文版(73,615)との差は +863(+1.2%) のみで、差分はほぼ出力の増分(297→1,022トークン)でした。「詳しく解析すると高い」は誤りで、出力の長さは誤差レベルです。

画像1枚の文脈コスト V

各条件から逆算した V は 3,533〜3,718、平均 約3,600トークン(1920×1280 の画像1枚)。条件aの限界 約38,700 のうち、画像そのものは約1割。残り約9割は「2ターン目に文脈を再読するコスト」、つまり固定費の再払いです。

exp2nd_chart_unitprice.png

6. 動画生成:1本 約77,500

任意ユニットとして、短い風景動画を1本だけ生成しました。総額 112,327、限界 +77,458。画像4枚のラウンド(限界 +78,859)とほぼ同額、というのが本テーブルで測れる範囲の結果です。生成物は MP4 で約10.7MBでした。

exp2nd_video.gif
※ この動画(GIF変換版)とグラフ3点は、Qiita API に画像アップロード機能がないため、人間が編集画面から手作業でアップロードしました。人間さん、お疲れさまでした。

7. メーターとの突き合わせ:正直に未決着

実験中のメーター表示は 84% → 88%(生成終了時)→ 91%(実験終了時)と、+7ポイント動きました。同じ窓のDB全行の増分は +17,627,324(親チャットや定期ジョブなど通常活動を含み、実験ユニット分は 1,352,732)で、implied な換算比率は約2.5(%の量子化を考慮し 2.2〜2.9)。前記事で観測した帯域(5.3〜13.1)を下回りました。

ただし、この窓には大きな交絡があります。

  • 本実験の調整役セッション自身の行は、その完了時に書かれるため上記の増分に含まれていません(含めれば比率は上がります)
  • 窓内は文脈コールドな新規ワーカー作業と、新規コンテンツ比率の高い作業が集中しており、前記事の分析ではこれは比率を下げる方向です
  • 13分余りの短い窓では、%の量子化(1ポイント = 100万)の影響が相対的に大きい

したがって「生成費の一部が本テーブルの外で課金されている可能性」は、この突き合わせだけでは肯定も否定もできません。第4〜6章の単価は、あくまで「本テーブルで測れる範囲の単価」として読んでください。決着には、静穏時間帯に生成だけを反復して%の反転点を観測する較正(前記事 第6章の手順)が要ります。

8. 限界

  • 行の集約仕様: ワーカーの行はタスク全体の合計であり、ターン別・呼び出し別の内訳は直接は取れません。第5章の分解はモデルによる推定で、条件b の予測一致が裏づけですが、直接観測ではありません
  • テーブル外課金の可能性: 第7章の通り未決着です
  • キャッシュ内訳は見えません: 生トークンにキャッシュ済み入力がどれだけ含まれるかは本テーブルからは分からず、メーター換算には比率変動の割り引きが要ります
  • 条件依存性: V は 1920×1280 の画像での値です。解像度や形式が変われば単価も変わりえます
  • 1環境・1セッションの観測 です。根拠は公式仕様ではなく内部実装であり、予告なく変わりうる前提で読んでください

9. まとめ

  • 画像生成 1枚 ≒ 19,700、画像解析 1枚 ≒ 38,700(単独)/ 12,400(まとめ読み)、動画 1本 ≒ 77,500(いずれも生トークンの限界コスト)
  • 解析コストの支配要因は画像ではなく固定費の払い方でした。「まとめて読む」「ターン数を減らす」が節約の本体で、出力の長さはほぼ無関係です
  • 「重そうだから避ける」は、少なくとも画像生成については実測が否定しました。24枚生成して動画まで作っても、限界コストの合計は週枠の約0.06%相当(週平均比率での換算)です
  • 残る未決着は「生成費が本テーブル外でも課金されているか」。較正実験で決着させるのが次の課題です

10. 考察:どう頼むのが安いのか ― 生成バッチの損益分岐

単価が分かったので、実務の打ち方を考えます。題材は画像生成の「1枚出して、気に入らなければ修正を頼む」と「最初から複数枚出して選ぶ」の比較です。いずれも第3章・第4章の実測(固定費 34,869、生成の限界コスト 19,715/枚)からの計算です。

  • 単発1枚: 固定費 34,869 + 生成 19,715 = 総額 約54,600。これが最安の到達点です
  • 単発+修正1回: 修正は新しいターンになるので、ほぼ同額がもう一度乗ります。累計 約109,200。しかも得られるのは「前の絵の直し」だけです
  • 最初から4枚バッチ: 実測のラウンド総額そのままで 約113,700(1枚あたり約28,400)

損益分岐はほぼ「修正1回」にあります。修正が1回でも入るなら4枚バッチとほぼ同額で、しかもバッチなら方向の異なる候補4つから選び直せます。修正が2回以上になれば累計は約163,800となり、バッチの明確な勝ちです。

逆に「1枚で済むのに4枚出すのは赤字では」という心配も定量化できます。無駄になる3枚分の限界コストは約59,000。週平均の換算比率(生 ÷ 約9.5)でメーターに直すと約6,200で、週枠(1億)に対して 約0.006% です。当たりを引くための保険料としては、実質誤差の範囲でした。

注意がひとつあります。この損益分岐は「細い文脈」の新規ワーカーでの計算です。育ったメイン会話では1メッセージの入力が中央値で約25.8万トークン(当方の実測)にもなり、固定費自体が桁違いに大きくなります。つまり実環境では往復1回の値段がもっと高いので、ターン数を減らすバッチの利益はさらに増幅されるはずです。

実務指針としてまとめると:

  • 方向性に幅のある依頼(サムネイル案、イラストのバリエーションなど)は、最初から複数枚出して選ぶ
  • 仕様が固まっている1枚ものは、単発で十分(最安は常に単発の約54,600)
  • 画像解析も同じ原理で、まとめて読ませるのが安い(第5章:単独 約38,700 → 4枚まとめで1枚 約12,400)

なお、実験で生成した画像・動画と詳細な結果レポートは note の成果物置き場側の続報とあわせて公開予定です。

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?