挨拶
こんにちは！
ブルーモ証券のRailsエンジニアの浜口です（社内では、はまちゃんと呼ばれています）。
突然なんですが、最近の生成AIは本当にすごいですよね。🤖
すでに仕事の実装において、かなりの範囲をカバーできる精度になってきていると感じています。
ただし、やっぱり使用する際のコストが気になってしまう。。。🤔と思ったので、
今回は、なんとかtoken使用量を減らす方法が無いか探るべく、
普段使っているClaude Codeに対して検証を行ってみたので、検証結果を共有していきたいと思います！✊
検証設計
検証方法
自前で用意したコード解析ツールを用いてRubyコードを解析し、「関数の型情報」および「関数の呼び出し元リスト」を含む解析情報ファイルを作成します。
その後、作成した解析情報を実装前に生成AIへ「渡す」パターンと「渡さない（通常）」パターンの2通りで実装を依頼し、token使用量にどれくらい差が出るのかを検証していきます。
期待するポジティブな結果としては、
「生成AIのコード探索効率が良くなり、実装完了までのToken使用量が減る」事を期待しています。
対象コード
-
Ruby製の電卓アプリ（プロダクトコードだと検証には重かったため、今回は自前のコードで検証しています。）
-
およそ1,500行ほどのRubyコードで書かれています。
↓こんな感じのアプリになります。
解析情報
Rubyコードから以下の情報を抽出：
- 関数一覧
- 型情報
- 呼び出し関係
↓こんな感じのデータになりました。ところどころ解析できていない型は、手作業で修正してから使います。
比較条件
以下の条件で比較検証を行います：
- 同一プロンプト
- 同一モデル（Claude Sonnet 4.6）
- Prompt Cachingあり/なしの2パターンで比較
- トークン使用量の計測はccusageで行っています
検証結果(Prompt Cachingあり)
1. 軽微な実装(1~2行変更する程度)
| 条件 | 実装完了までの消費トークン |
|---|---|
| 解析あり | 122,784 |
| 解析なし | 169,122 |
→ 解析ありの方が 約46,000 token少ない
2. 中規模程度の実装(2つの関数を修正する程度)
| 条件 | 実装完了までの消費トークン |
|---|---|
| 解析あり | 220,882 |
| 解析なし | 141,676 |
→ 解析ありが 約79,000 token多い
3. 大規模な実装(コードの約半分を書き換える程度)
| 条件 | 実装完了までの消費トークン |
|---|---|
| 解析あり | 1,330,605 |
| 解析なし | 950,500 |
→ 解析ありの方が 約380,000 token多い
Prompt Cachingありだと、ほぼ「解析なし」が有利な結果になりました。
ではPrompt Cachingなしだと、どうなるか見ていきたいと思います👀
検証結果(Prompt Cachingなし)
1. 軽微な実装(1~2行変更する程度)
| 条件 | 実装完了までの消費トークン |
|---|---|
| 解析あり | 116,190 |
| 解析なし | 381,794 |
→ 解析ありの方が 約265,000 token少ない
2. 中規模程度の実装(2つの関数を修正する程度)
| 条件 | 実装完了までの消費トークン |
|---|---|
| 解析あり | 158,564 |
| 解析なし | 776,341 |
→ 解析ありの方が 約617,000 token少ない
3. 大規模な実装(コードの約半分を書き換える程度)
| 条件 | 実装完了までの消費トークン |
|---|---|
| 解析あり | 902,248 |
| 解析なし | 809,736 |
→ 解析ありの方が 約92,000 token多い
Prompt Cachingなしの場合、「解析あり」が有利なケースも出てきています👀
結果まとめ
改めて結果をまとめると以下になります。
Prompt Cachingあり
| 実装規模 | 解析あり | 解析なし | 差分 (あり−なし) | 有利 |
|---|---|---|---|---|
| 軽微 | 122,784 | 169,122 | 約-46,000 | 解析あり |
| 中規模 | 220,882 | 141,676 | 約+79,000 | 解析なし |
| 大規模 | 1,330,605 | 950,500 | 約+380,000 | 解析なし |
Prompt Cachingなし
| 実装規模 | 解析あり | 解析なし | 差分 (あり−なし) | 有利 |
|---|---|---|---|---|
| 軽微 | 116,190 | 381,794 | 約-265,000 | 解析あり |
| 中規模 | 158,564 | 776,341 | 約-617,000 | 解析あり |
| 大規模 | 902,248 | 809,736 | 約+92,000 | 解析なし |
総じてみると、
- 解析情報を渡した方が良いケース
- 生成AIが初めて or 覚えてない領域で作業を行う時
- 解析情報を渡さない方が良いケース
- Cache等によって、解析情報に近しい情報を、既に生成AIが把握している時
- ほとんどのコードを読まないと行けない時
と言った結果になりました。👀
今後の検証について
今回の結果を踏まえて、以下の検証を次に試してみたいと考えています。
プロダクト開発の規模で使えそうな解析ツールを試してみる
プロダクト開発の規模で使えそうな解析ツールとして、
「Serena」や「Cocoindex」を試してみたいと思いました。
特に「生成AIが初めて触る or 覚えてない領域」の作業では、token消費量が著しく多くなる為、
Cocoindexで予めコードをIndexしておいてから作業を開始する事が出来れば、
大幅にtoken消費量が抑えられる可能性があります。
また、解析情報に関しては渡さない方が良いケースも存在する事が解ったので、
より細やかなユースケースに対応出来るかも、見ていきながら検証したいと考えています👀
コードベースごとにtoken消費量が違うのかを検証する
コード解析ツールを用いなくても、
- 責務が細かく分割されている
- コード上で責務が明確に表現されている
様なコードベースであれば、
「生成AIが初めて触る or 覚えてない領域」の作業においても、見るべきコードが限定され、
それほどtokenが消費されない可能性もあると考えています。
この辺りは、ブルーモ社内のコードベースごとにtoken消費量を計測出来れば、
面白い結果が見えてくるのかなと思いました👀
おわりに
今回は小さいコードベースでの検証かつ、検証回数もまだまだ少ないため、
今後さらに深めていく必要がありますが、
AI時代においても、
人が工夫できる余地はまだまだあることが見えてきて、
個人的にはとても楽しい結果となりました。
引き続き検証を進めながら、
より良い形でAIと付き合っていけるよう改善していきたいと思います！✊
We are Hiring!
ブルーモ証券ではエンジニアを積極的に募集しております！
少しでも興味を持っていただけた方はお気軽に下記の採用ページからご連絡ください！
ブルーモ証券株式会社のプロダクトチームブログです。「資産運用に自信を。」をミッションに、ポートフォリオをコピーして簡単に米国株・ETFで資産運用できるアプリ＂ブルーモ＂を提供しています。 各種エンジニア・デザイナー・PdMポジションを積極採用中です！ bloomo.co.jp/careers
Discussion