はじめに
「AIにスライドを作らせると、すぐトークンを使い切る…」と感じたことはありませんか?
この記事では、なぜPowerPoint作成はトークンを消費しやすいのかと、その対策を整理します。
結論
PowerPoint作成でトークンが増えるのは、次の3つが重なるからです。
- LLMが文章だけでなく、書式・構造まで出力・読み込みする
- 修正の往復やエージェントの自己修正ループで、何度も同じ情報を処理する
- 日本語は英語よりトークンを使いやすい
そもそもトークンとは
- LLMが文章を処理する最小単位
- 料金も、一度に読める量の上限(コンテキスト長)もトークン数で決まる
- 入力トークンだけでなく出力トークンも課金対象(一般に出力のほうが単価が高い)
- 会話履歴やシステム指示も入力トークンに含まれる
消費が増える理由
1. pptxの実体は重いXML
.pptxは、実はXMLファイルをZIPにまとめたものです。
スライド1枚分のXMLだけでも非常に長く、読み書きのたびにコンテキストを圧迫します。デッキ全体を扱うと、消費量がすぐ膨れ上がります。
LLMにXMLを直接書かせる方法は、トークン効率が悪いだけでなく、LLMが一貫して正しく書き続けるのも難しいと指摘されています。
2. 修正のたびに消費する
次のような微調整のたびにトークンを使います。
- 「フォントを小さくして」
- 「余白を広げて」
- 「この図を右に寄せて」
さらに会話が長くなるほど、毎回の入力に過去のやり取りが含まれるため、1回あたりの入力も増えていきます。
3. エージェントの自己修正ループ
Claude Codeのような自律型エージェントに任せると、裏側で次のループを何度も回します。
思考(Thought) → 行動(Action) → 観察(Observation) → 思考 → ...
スクリプトのエラー修正や、ファイルの再読み込みも発生します。人間が気付かないところで、トークンが積み上がります。
4. 日本語は割高
同じ内容でも、日本語は英語の約1.5倍(場合によってはそれ以上)のトークンを使うとされています。
「文字数は少ないのに、思ったより枠を食う」現象の原因です。
消費の構造まとめ
| 原因 | 何が起きるか | 増えるトークン |
|---|---|---|
| XML構造が重い | スライドの書式データまで読み書き | 入力・出力 |
| 修正の往復 | 微調整のたびに再生成 | 出力+履歴ぶんの入力 |
| エージェントのループ | 自己修正・再読み込み | 入力・出力 |
| 日本語 | 同じ内容でもトークン数が増える | 入力・出力 |
対策
ポイント:「LLMは中身、描画はコード」に分ける
LLMには内容を構造化データ(JSON)で出させ、実際のpptx生成はpython-pptxなどのライブラリに任せます。
[LLM] 内容をJSONで出力
↓
[Python] python-pptxでテンプレートに流し込む
↓
[pptx完成]
JSONのイメージです。
{
"slides": [
{
"layout": 1,
"placeholders": {
"0": "タイトル",
"1": "本文の箇条書き"
}
}
]
}
LLMが選ぶのはレイアウト番号と、各プレースホルダーに入れる文字だけです。書式のXMLを出力しないので、出力トークンを大きく減らせます。
その他のコツ
- 雛形(テンプレート)ベースにする:ゼロからデザインさせない
- 1枚ずつ処理する:デッキ全体を一度に読み込ませない
- 文字数の上限を指定する:日本語は長文やはみ出しが起きやすい
- 指示を曖昧にしない:やり直しの回数を減らす
- デザインはAIに任せすぎない:手作業で作ったスライドを再現するスクリプトにする
まとめ
- PowerPoint作成はトークンを食う作業になりやすい
- 原因は「XMLの重さ」「修正の往復」「エージェントのループ」「日本語」
- 対策は、LLMに内容(JSON)だけ作らせ、描画はpython-pptx+テンプレートで行うこと