claude pptx

とある日、Claude APIを使ってPowerPointを自動生成する機能を開発していたところ、たった1回の生成で約$10.4のAPI費用が発生していることに気づきました。

利用していたのは、Anthropic公式のpptx SkillとClaude Opus。生成された資料の品質は悪くなかったものの、この費用ではサービスとして継続的に提供するには厳しい状態です。

原因を調査してみると、問題は資料を生成する処理そのものではなく、生成したスライドを画像として確認する処理にありました。

最終的にはClaude Managed Agentsを採用し、資料を作るAIと、画像を確認するAIの役割を分けることで、1回あたりの費用を約$0.98まで削減できました。

今回は、実際のAPI使用量をもとに、原因の特定から改善までの過程を紹介します。

※金額はすべて米ドルでのAPI費用です。改善後の数値は開発環境での検証結果であり、本番反映前の2026年11月6日時点のものです。

1. PowerPointを1回生成するだけで$10.4

当社の開発するサービスでは、Claude APIとAnthropic公式Skillを使い、ユーザーの指示からPowerPoint（pptx）やWord（docx）を生成しています。

当初はMessages APIのコード実行機能と、公式のpptx Skillを組み合わせていました。

あるとき本番環境の利用料金を確認すると、PowerPointの生成1回で以下の費用が発生していました。

項目 API費用
通常の入力 $0.0001
キャッシュ書き込み $9.52
キャッシュ読み出し $0.44
出力 $0.41
合計 約$10.4

金額はAnthropicの管理画面で確認した請求額です。

注目したのは、費用の約9割がキャッシュ書き込みに集中していたこと。通常の入力はほぼゼロなのに、キャッシュ書き込みだけで$9.52。どう考えても不自然です。

そこで実際のサービスに近い検証用プロンプトを用意し、同じ構成で再現テストを行った結果、キャッシュ書き込みは約149万トークン、生成1回の費用は$9.96となり、問題を再現できました。

2. 原因は「スライドの画像確認」だった

公式Skillには生成後の目視確認がある

Anthropic公式のpptx Skillには、作成したスライドを画像に変換し、レイアウトに問題がないか確認する「Visual QA」という工程があります。

例えば、文字がスライドからはみ出していないか、表が崩れていないか、図形と文字が重なっていないか、といった確認です。

これは必要な工程です。PowerPointはファイルとして正しく生成できても、人間が開いてみるとレイアウトが崩れていることがあるためです。

しかし今回の構成では、この画像確認に予想外のコストが発生していました。

画像が大量のテキストトークンになっていた

調査した実行では、1467×825ピクセルのJPEG画像を6枚開いていました。

このとき、コード実行経由で返された画像のbase64データが、非常に大きなテキストとして処理されていました。

1枚あたりのデータ量は約4.2万〜13.9万文字。計測すると、base64の文字数に対して約0.9〜1.0倍のトークン数が発生していました。

6枚の合計は約65.8万文字です。

さらに、今回の構成ではcontext editingによって古いツール結果が削除され、プロンプトキャッシュの一部が無効化・再作成されていました。

その結果、再現テストのキャッシュ書き込みは約149万トークンに達していました。

項目 再現テスト
キャッシュ書き込み 1,490,384トークン
キャッシュ書き込み費用 $9.31
キャッシュ読み出し 389,456トークン
出力 18,073トークン
合計費用 $9.96

なお、これはClaudeの画像認識全般でbase64の文字数分が課金されるという意味ではありません。通常の画像入力は画像用のトークンとして処理されます。

今回問題になったのは、Messages APIのコード実行で画像を開いた際、そのデータが大きなテキストとして扱われていた経路です。

調査中の実行では、画像を開かなかった回の費用が$0.6〜$0.8程度だったのに対し、画像を開いた回は$3〜$10程度になっていました。

これで、改善すべき場所が明確になりました。

3. 最初に試したのはモデル変更と画像の縮小

いきなり構成を変更するのではなく、まずは既存のMessages APIを使ったまま改善できないか検証しました。

モデルと思考量の変更

最初に、使用モデルをClaude Opus 5からOpus 5.5へ変更し、思考量をhighからmediumへ変更しました。

画像を開く処理はそのままです。

これだけで、1回あたりの費用は$2.88〜$3.01程度まで低下しました。

大幅な改善ではありますが、まだ画像確認のコストが残っています。

全スライドを小さな画像1枚にまとめる

次に試したのは、スライドを個別に開くのではなく、全ページを縮小して1枚の画像に並べる方法です。

10ページ分を幅1200pxの画像にまとめ、1枚だけ確認するようにプロンプトで指示しました。この方法では、検証用プロンプトでの費用が$1.05と$1.30になりました。

ただし、問題もありました。

10ページを1枚にまとめると、1ページあたりの幅は約380pxしかありません。全体のレイアウト崩れは見つけられても、表の狭い列で単語の途中に改行が入るような細かい問題を検出できません。実際に生成した資料には、2回ともこの種の崩れが残っていました。

画像を小さくすれば安くなる。しかし、その分だけ品質確認の精度が落ちる。

このトレードオフを解消する方法が必要でした。

4. Claude Managed Agentsで「作るAI」と「確認するAI」を分ける

image

最終的に採用したのが、Claude Managed Agentsを使ったマルチエージェント構成です。

Claude Managed Agentsは、Anthropicが提供するエージェント実行基盤です。サンドボックスでのファイル操作やコード実行、複数エージェントへの作業分担を行えます。

今回の構成では、役割を次のように分けました。

メインエージェント：Claude Opus 5.5

資料の生成と修正を担当します。PowerPointを作成してPDF・画像に変換し、サブエージェントへレイアウト確認を依頼します。問題が報告されたら資料を修正します。

重要なのは、メインエージェント自身は画像を開かないことです。

サブエージェント：Claude Haiku 5.5

画像の確認だけを担当します。各スライドを開き、文字のはみ出し、重なり、読めなくなるような改行を検出し、メインエージェントに報告します。実際の資料修正は行いません。

処理の流れは以下のとおりです。

Opus 5.5（資料を生成） → Haiku 5.5（画像を確認） → Opus 5.5（必要な箇所を修正） → 完成

なぜこの構成で安くなるのか

理由は大きく2つあります。

1つ目は、画像のトークン数が大幅に減ったこと。

今回のManaged Agents環境では、元の大きさの画像を開いても、1枚あたり約2,000トークンで計上されました。Messages APIのコード実行経由で、1枚あたり数万〜十数万トークンになっていたときとは大きな違いです。

2つ目は、画像確認を安価なHaikuに任せたこと。

複雑な資料の作成と修正はOpusに任せ、画像確認のように対象を限定した作業はHaikuに任せます。改善後の計測では、サブエージェントの費用は生成1回あたり約$0.008でした。

資料の品質を維持するために画像確認を省くのではなく、画像確認の実行方法そのものを変えたことがポイントです。

5. 画像確認の回数にも上限を設定した

もう1つ工夫したのが、サブエージェントに確認を依頼する回数です。

最初の上限を設定していなかった時、10ページのPowerPoint生成で確認と修正を約10回繰り返し、費用が$1.66、所要時間が493秒になりました。

品質は良好でしたが、必要以上の確認を繰り返しているように見えます。そこで、確認依頼の上限を変えて比較しました。

確認依頼の上限 API費用 結果
上限なし $1.66 崩れなし、ただし確認が多い
最大2回 $0.66 一部の改行崩れが残る
最大4回 $0.63〜$0.85 3回とも大きな崩れなし

最大4回の設定では、3回の検証すべてで品質に問題がないと判断しました。実際には、問題が解消した時点で確認を終了します。

さらに以下の運用ルールを加えています。

  • 1回目は全ページを確認する
  • 2回目以降は修正したページだけを確認する
  • 読めなくなるような問題に絞って報告する
  • 最大4回を超える場合は、プログラム側から仕上げを指示する

上限の変更だけでなく、確認対象や報告条件も調整しています。そのため、費用の違いを上限回数だけの効果と見ることはできません。

それでも、AIに何度も品質確認をさせる処理では、終了条件を明確にすることが重要だとわかりました。

6. 最終結果：$10.4から約$0.98へ

開発環境で実際のサービス用プロンプトを使い、Managed AgentsによるPowerPoint生成を3回実行しました。

結果は以下のとおりです。

実行 API費用
1回目 $0.93
2回目 $0.98
3回目 $1.02
平均 約$0.98

本番環境で確認した変更前の約$10.4と比べると、約90.6%の費用削減です。

この比較にはモデルと思考量の変更も含まれています。また、変更前は本番環境、変更後は開発環境での計測です。Managed Agents単独による削減率ではありません。

何に費用がかかるようになったのか

改善後のPowerPoint生成3回の平均内訳です。

項目 API費用
メインエージェント：キャッシュ書き込み $0.27
メインエージェント：キャッシュ読み出し $0.15
メインエージェント：出力 $0.54
サブエージェント合計 $0.008
セッション実行時間 $0.007
合計 約$0.98

端数や通常入力分は丸めています。

改善前はキャッシュ書き込みが費用の大半を占めていましたが、改善後はメインエージェントの出力が最大の費用項目になりました。

画像を確認するサブエージェントの費用は全体の1%未満です。

同じプロンプトで比較すると？

より条件をそろえるため、検証用プロンプトでもMessages APIの改善版とManaged Agentsを比較しました。

形式 Messages API改善版 Managed Agents
pptx（10枚） $1.05 / $1.30 $0.63〜$0.85
docx（7〜8ページ） 平均$0.94 平均$0.83

pptxはMessages API側2回、Managed Agents側3回、docxはそれぞれ3回の計測です。

pptxではManaged Agentsのほうが安く、生成した資料にも目立つ崩れがありませんでした。

docxでも費用が下がり、Messages API側で発生していた目次のページ番号のずれなどが、Managed Agents側の3回では見られませんでした。

また、参考PDFを添付したPowerPoint生成では、Messages API改善版が$1.95、Managed Agentsが$0.73でした。ただし、こちらは各1回の比較です。

xlsxは別の方法で改善

Excel（xlsx）についても同様に調査しました。

xlsxでは、指示していない画像確認が発生し、生成1回で$4.38かかったケースがありました。ただし、Excelは表や数式をプログラムで検証できるため、pptxとは異なる方法を採用しました。

画像を開かないようプロンプトで指示した結果、3回の平均は$0.86になりました。資料の種類によって、必要な品質確認の方法を分けることも重要そうです。

7. 導入時の注意点

今回の方法には、いくつか注意点もあります。

Managed Agentsはベータ版です。 API仕様が変更される可能性があるため、本番導入時は変更への追従を考える必要があります。

トークンとは別にセッション実行時間の料金があります。 検証時点では1時間あたり$0.08で、今回の生成では$0.002〜$0.007程度でした。

生成速度が速くなるわけではありません。 検証用プロンプトでは、pptxはMessages API改善版の225〜236秒に対してManaged Agentsが215〜304秒、docxでは157〜242秒に対して262〜353秒でした。

セッションのデータ管理も必要です。 Managed Agentsはサーバー側にセッション状態や生成物を保持します。本番環境では、必要な生成物を取得したうえで、生成終了後にセッションを削除する運用を予定しています。Files APIで別途アップロードしたファイルなどは個別に管理する必要があります。

最後に、今回の検証は各条件で数回程度の計測です。資料のページ数や複雑さ、プロンプトによって結果は変動します。本番環境での改善効果については、反映後に改めて確認する予定です。

まとめ：AIの費用はモデルだけで決まらない

今回の取り組みでは、PowerPoint生成のAPI費用を約$10.4から約$0.98まで下げることができました。

最初はモデルの費用が高いのだと考えていましたが、実際に大きな影響を与えていたのは、画像を確認する際のデータの扱われ方でした。モデルを安いものに変更するだけでなく、何をどのモデルに任せるか、どのツールで処理するか、どこまで確認を繰り返すかを見直したことが効果につながりました。

特に、PowerPointやWordのように生成後のレイアウト確認が重要になる処理では、「作るAI」と「確認するAI」を分ける設計は有効な選択肢だと考えられます。

Claude APIでファイル生成を実装していて想定以上の費用が発生している場合は、モデルや出力トークンだけでなく、ツール実行結果とキャッシュ書き込みの内訳を確認してみることをおすすめします。

参考資料