Claude を活用した翻訳ツールから学んだ、AI 呼び出しのコストルーティング

チーム向けに、日本語の仕様書、顧客向け資料、アーキテクチャ図を必要なときに英訳できるツールが必要だった。Excel、Word、drawio。答えは明らかに Claude だったが、もっと明らかな問題があった ― 業務ドキュメントを API に流すと、トークン課金がすぐに膨らむ。

最初のリリースを経て、向き合うべき技術課題は2つで、そのうち1つの判断が両方を解決することになった。

フォーマット保持の課題

Claude に生のテキストを投げて、戻り値をそのまま貼り付けるわけにはいかない。Excel には数式がある。Word にはスタイル、表、見出しがある。drawio には図形の位置や接続線がある。翻訳でそれらが壊れれば、出力されたドキュメントは使い物にならない。

対策はフォーマットごとに専用パーサ。各形式の構造を辿り、人間が読むテキストだけを抽出し、まとめて Claude に送る。返ってきた訳文を、元のセル / ラン / 図形にマッピングし直して再構築。構造はラウンドトリップで保たれ、変わるのはテキストだけ。

コストの課題

もう一方は、純粋にお金の問題だ。安易な解決は「全部安いモデルにする」こと。誠実な解決は、「すべてのチャンクが同じモデルを必要としているわけではない」と認めること。

コストをルーティングの判断にした。すべてのチャンクは以下を通る:

1. まずキャッシュ照合 ― キーは正規化された原文と対象言語。業務ドキュメントには繰り返し出現する文字列(セクション見出しや定型句)が多く、同じ文字列を二度 Claude に送ることはない。
2. モデルの階層的選択 ― 短く低複雑度の文字列は安価なモデルへ。専門用語や複合的な文脈を含むものは上位モデルへ。

ドキュメントごとの手動チューニングなし。ルーターが判断する。

結局重要だったもの

興味深いのは、どちらの課題がより難しかったか、ということだ。コスト問題が大変だと予想していたが、設計時間を最も食ったのはフォーマット保持の方だった。特に drawio ― deflate された XML を base64 でラップした形式で、図形の位置と接続線のラベル両方を翻訳する必要があるが、変えていいのはラベルだけ。

同種のものを作るなら、ひとつだけアドバイス:キャッシュとモデルルーターは、最初の翻訳呼び出しを書く前に設計しておく。本番に入ってからコスト規律を後付けするのは、思っているより難しい。