本投稿は TECOTEC Advent Calendar 2025 の24日目の記事です。
こんにちは、証券フロンティア事業部の吉澤です。 普段は Python を用いた開発や、保守・運用業務を担当しています。
今回、LLM（大規模言語モデル）の API を利用し、プロンプトエンジニアリングを含むシステムの構築・実装を行いました。 本記事ではその経験をもとに、システムに AI を組み込む際に気を付けた点と、今振り返って「もっと気を付けるべきだった」と感じた点について紹介します。
動機は翻訳タスク
今回は、バッチ処理で文章を日本語から英語へ翻訳することを目的として LLM の API を利用しました。 当初は Google Translation API を用いた翻訳を検討していましたが、 最終的には LLM に翻訳させる形を選択しました。
理由としては、主に以下の2点です。
- 機械翻訳は表現に違和感があるときがある
- コスト面でのメリットがあった
LLM を使うことで、従来の機械翻訳よりもリーダブルな翻訳が得られるのではないか、と思いました。
また、実際に使ったことがある人は分かると思いますが、 LLM の API の利用料金は意外と安く、用途とモデル選定次第で十分現実的なコストに収まります。
例えば、今回私は Amazon の「Nova Pro」というモデルを翻訳用途に使ったのですが、1億文字を翻訳させる場合、
Google Translation API を使った場合、 約30万円($20/100 万文字)
モデル「Nova Pro」を使った場合 約2万円(input:$0.0008/1000 tokens, output:$0.0032/1000 tokens)
上記のように、翻訳品質の向上が期待できるうえに、コスト面でも大きなメリットがありました。
メリットだけではなかった
機械翻訳ではなく LLM を用いて翻訳処理を実装することで、前述したようなメリットは得られましたが、 想像していた以上に苦労した点や、事前に考慮しておくべきだった点もありました。
そこで次の章からは、実際に開発を行う中で直面した課題や、振り返って「こうしておけばよかった」と感じた点を、備忘録として整理していきたいと思います。
精度のテストおよび評価
ある程度分かっていたことですが、 今回、文章の翻訳を LLM に任せるにあたり生成された翻訳文の評価や品質保証をどのように行うかという点が想像以上に難しかったです。
LLM の出力は確率的であり、同じ入力であっても常に同じ結果が返ってくるとは限りません。
そのため、翻訳結果の品質をどのように評価し、品質を保証するかが悩ましいポイントでした。
結局、今回私が行った対応としては以下です。
原文と翻訳文にインデックスを付与し、 LLM の出力の原文⇔翻訳文の整合性の保証
JSON形式で出力させることにより、システム側でのパースや後続処理を安定させる
上記を満たすようにプロンプトを変えつつ精度を見る
今回は逐一翻訳品質を厳密に数値評価するアプローチは諦め、最低限の保証に留める対応を取りました。
なお、今回使用したモデルは Amazon の「Nova Pro」ですが、 上記の 1・2 を満たすだけでも、 実用上問題のないレベルの翻訳文を生成してくれていました。 そのため、LLM の出力評価については、自分のスキル面等の制約もあり厳密な評価を行うところまでは踏み込みませんでした。(何かいい方法があればこっそり教えてください)
今後、より高い精度保証が求められるケースの場合、または運用コストとの兼ね合いで必要な場合は、 LLM-as-a-judgeのようなアプローチを採用することも検討の余地があると感じました。
参考 zenn.dev
レート制限への考慮
LLM の API を使ったテキスト生成では、「精度」や「プロンプト設計」に意識が向きがちですが、 外部 API を利用する以上、レート制限への考慮も必要不可欠です。
私が外部 API を使った経験が疎かったのもありますが、実装を進めるうえでレート制限がボトルネックで処理速度の遅さに悩むことになりました。
今回の処理はバッチで大量の文章を翻訳するという性質上、 単純に「並列処理で処理速度を上げる」という実装をすると、すぐにレート制限に引っかかってしまいます。一方で、1リクエストあたりの文字数を増やしすぎると、レスポンスが遅くなったりと別の問題が発生してしまいました。
この経験から感じたのは、 LLM のモデル選定やコスト見積もりを行う際には、モデルの性能やトークン単価(コスト)だけでなく、応答速度、レート制限などの要素も考慮する必要があると思いました。
特に LLM は、モデルごとに応答速度やレート制限の仕様が大きく異なり、 実際どのくらいのスループットになるかはドキュメントを読むだけでは分からない部分も多いと感じました。
今回は結果的に、文字数や並列数の調整で対応できましたが、 このようなパラメータ調整だけで解決できるかどうかは、実際に試してみないと分からない部分が大きいと感じました。
そのため、モデルを選定する際は、システムの要件（処理量、許容処理時間、コストなど）を踏まえつつ、 PoC を行いながらモデルを選定していくことが重要だなと感じました。
モデル変更を前提とした見積もりの必要性
今回の実装では最終的にモデル変更を行うことはありませんでしたが、 振り返ってみると、業務やクライアントワークでシステムに LLM を利用するケースを想定すると、 「モデル変更によるコスト増加をどう説明するか」 という点も事前に考慮しておく必要があると感じました。
前述の通り、LLM の出力は確率的であり、 生成物の品質についても明確な数値指標を用いて評価することが難しいケースが多いです。 そのため、「より高性能なモデルに変更することで精度が向上する」 という説明はできても、それを定量的に示すことは簡単ではありません。
一方で、性能の高いモデルに変更すればトークン単価(コスト)が上がり、 精度向上という効果を数値で示せないまま、 コスト増加だけが明確になる、という状況に陥りやすいと感じました。
そのため、LLM を用いたシステムの見積もり段階では、 「将来的にモデルを変更する可能性がある」ことを前提に、 ある程度のコスト増加を許容した設計・見積もりをしておくことが重要だと思いました。
後から精度向上を目的としてモデル変更を検討するよりも、 初期段階でその選択肢を織り込んでおくほうが意思決定者への説明や意思決定がしやすくなると感じました。
まとめ
最近の AI ツールや LLM の性能向上は目覚ましく、 「何でもできるんじゃないか」と感じてしまう場面も増えてきました。 一方で、実際にシステムへ組み込もうとしてみると、 出力の評価やコスト、レート制限、運用時の調整等、 信頼性や保守性の観点からも、人が考慮すべき点はまだまだ多いと感じました。
技術力不足な面もあったと思いますが、 今回、LLM を組み込んだ実用的なシステムを設計から実装、運用まで一通り経験する中で、 事前に十分考慮しきれていなかった点や、「こうしておけばよかった」と感じる部分がありました。 その反省を踏まえ、本記事ではこれらを整理して紹介しました。
今後、一般的なアプローチとして LLM をシステムに組み込む機会は増えていくと思います。
本記事の内容が少しでもこれから LLM を扱う方たちの参考になれば幸いです。
テコテックの採用活動について
テコテックでは新卒採用、中途採用共に積極的に募集をしています。
採用サイトにて会社の雰囲気や福利厚生、募集内容をご確認いただけます。
ご興味を持っていただけましたら是非ご覧ください。
tecotec.co.jp
