【gaipack Dojo】 Claude Managed Agents で登壇準備を自動化し、運用コストを実測してみた📖

gaipack 本部 AIDD 技術部の宮本です！新卒の配属後研修「gaipack Dojo」で、社内で毎朝行っている技術共有「gaipack Live」の登壇準備を自動化する仕組みを開発しています。この記事では、開発中のシステムの構成と、実機で 1 回動かして実測した運用コストの内訳を共有します。

---

登壇準備の負担を Managed Agents に肩代わりさせたい

社内では毎朝 10 時に技術情報を共有する場「gaipack Live」を設けています。ただ、登壇者は日常の案件作業で多忙な中、「探す・試す・まとめる」を短期間でこなす必要があります。この手間の重さが登壇者不足の要因のひとつになっていると聞きました。実際に今回の準備でも、資料をまとめるまでにかなりの時間を使いました。

そこで、最新の技術情報を収集して検証し、報告レポートと登壇資料までを自動で用意する仕組みを Managed Agents で作ることにしました。

提供する 2 つの機能

システムの機能は 2 つに分かれています。

1 つ目は日次リリースノートの自動生成です。毎朝 Managed Agents が指定した技術サイトを自動で巡回し、各リリースについて前回から何が変わったのか、具体的に何に使えるのかを要約します。加えて、そのリリースが実際に使えるかどうかをエージェント自身が検証して判断します。出力は朝の短い時間で読み切れる分量のレポート記事で、リリースが何件あっても 1 日あたり最大 5 件までを対象にしています。

2 つ目は登壇用のスライドと発表原稿の作成です。Web UI 上で生成済みの記事を複数選択してフォームへ進み、登壇者名・発表日・個別の要望を入力して送信すると、スライドと発表原稿が一括で生成されます。記事 1 件につきスライド 1 つではなく、記事を読んだ登壇者が「今日話したいもの」をいくつか選んでまとめて発表する形を想定しています。

単にリリース内容を集めて並べるのではなく、実際に使えるかどうかの検証まで組み込んでいる点が、このシステムの特徴だと考えています。

技術スタックと現在の進捗

使用しているのは Claude Code と、Claude Platform on AWS 上で動く Anthropic の Managed Agents です。配属前の研修で AWS については学んでいましたが、Managed Agents を使った開発は今回が初めてです。プログラミング経験は大学時代に Python と JavaScript の基礎を学習した程度で、自分が主体となって実務プロダクトを開発するのもほぼ初めてになります。先輩方にアドバイスをいただきながら進めています。

現在主に担当しているバックエンドの進捗は次のとおりです。

共通基盤の実装と記事の自動生成という最小限の範囲までは動く状態になりました。そこで、実際にエージェントを動かしてどんな記事ができるのか、コストがどれくらいかかるのかを確認しました。

実機で 1 回動かしたときの実行コスト

記事 5 件分の検証と記事作成を 1 回実行したときの実測コストは $15.53（約 2,300 円）でした。実行時間は 28 分です。この金額に AWS の実行環境の利用料は含まれていないため、1 回あたりの実費はもう少し上がる見込みです。

平日に毎日実行すると仮定すると、月間の運用コストは約 $465、日本円で月 7 万円規模という計算になります。研修プロジェクトとして動かしている段階でこの水準なので、実用に乗せるにはコストの作り方から見直す必要があると考えています。

コストの内訳を分解してわかったこと

内訳を確認したところ、費用の大部分が入力側で発生していました。

キャッシュ読み出しだけで全体の 67% を占めています。AI エージェントは自律的に動作する中で記憶を長期保存できないため、モデルとのやり取りが 1 往復発生するたびに、それまでの会話履歴とコマンドの実行結果を全量読み直す構造になっています。今回の実行ではモデルとの往復が 123 回発生し、キャッシュ読み出しのトークン数は約 2,000 万トークンに達しました。

つまり、料金を決めているのは実行時間ではなく「往復回数 × 文脈サイズ」でした。往復回数が増えている理由は自分の実装にあります。生成される記事が 0 件になる事態を避けるため、リリースを 1 件ずつ書き出す安全策を取っており、その分だけ往復が増えています。なお、10 時の共有までに成果物が揃わない事態を避けるため、エージェントは最大 60 分で終了する仕様にしています。

トークン数をどう抑えればコストを削減できるか、手法は現在模索中です。

出力記事の中身に見つかった改善点

コストとは別に、生成された記事の内容にも課題がありました。現状のプロンプトでは出力の主題が「AI がどう検証したか」というプロセスに寄ってしまい、読者が最も知りたい「今回のリリースで何が変わったのか」「何に代替できるのか」が一目でわかりません。

対策としてまず、エージェントへの指示プロンプトの改善に取り組みます。無駄な試行錯誤を減らせれば往復回数も減るため、記事の内容とコストの両方を同時に改善できると見込んでいます。

今後の進め方

3 段階で進める計画です。

1. 毎朝の自動実行: 現在はスケジュール設定をしておらず、手動で実行しないとリリースノートが生成されません。まずは毎朝自動でノートが生成され、閲覧できる状態を確実に作ります
2. スライド自動作成: スライドとスピーカーノートの自動生成を接続し、登壇準備の自動化として一通り成立する状態にします
3. 運用最適化: 画面デザインのブラッシュアップと、実行件数・プロンプトの調節によるコスト最適化を進めます

まとめ

初めて AI エージェントを実機で動かして得た学びは、コストの効き方が事前の想像と違っていたことです。実行時間の長さではなく、往復のたびに全文脈を読み直す構造そのものが費用を押し上げていました。エージェントの実装方針を決めるときは、機能の作りやすさと同時に往復回数の設計を見る必要があると感じています。

このあたりの勘所を組織として持てるかどうかは、AI エージェントを実運用に乗せられるかの分かれ目になりそうです。KDDIアイレットでは、AI プラットフォームの導入から自走できる開発体制づくりまでを支援しています（AI プラットフォームの導入事例、AIDD インハウス）。

お気軽に KDDIアイレットへお問い合わせください！