LayerX エンジニアブログ

LayerX の エンジニアブログです。

実践！gpt-5-mini推論レイテンシ改善: パラメータ調整とプロンプトエンジニアリングによる爆速回答

実践！gpt-5-mini推論レイテンシ改善：パラメータ調整とプロンプトエンジニアリングによる爆速回答

こんにちは、LayerXのバクラク事業部 AI BPOチームでエンジニアをしているikehara (@ikehara_dev)です。

この記事は LayerX Tech Advent Calendar 2025 19日目の記事です。

本記事では、推論（Reasoning）モデルgpt-5-miniを本番投入した際の事例を紹介します。 当初は推論レイテンシが想定上限に達し、運用が厳しい状態でした。そこから「推論パラメータ調整」と「プロンプトエンジニアリング」を行い、精度を落とさずにレイテンシを改善した方法を、試行錯誤の過程を交えて解説します。

TL;DR

  • gpt-5-mini を本番投入したらレイテンシが厳しくなったため、推論パラメータとプロンプトを見直した
  • reasoning_effort をmedium→low にするだけで40%高速化（15.4秒→9.2秒）
  • プロンプトは 「手順(How)は任せる」「観点(What)は握る」でさらに30%高速化（9.2秒→6.5秒）

AI BPOでは何をしているの？

AI BPOで開発している「バクラク受領代行」では、紙のスキャン、URLからのダウンロード、電子メール経由など様々な経路の請求書を取得します。その後はAI-OCRにより入力補完まで自動で行うことで、書類の受領から仕訳データの作成までのプロセスを丸ごと無くすことができます。

comemo.nikkei.com

請求書受領BPOにおける課題

中でも「電子メール」経由の受領は、BPOにおいて難易度が高い領域です。

お客様から届く紙の請求書や、URLから定期的にダウンロードする形式の場合は、基本的に請求書に関連するものがほとんどです。一方、電子メールに関しては、「お知らせ」「イベント通知」「営業メール」といった多種多様なメールが大量に含まれます。

さらに、長いスレッド形式のメールから「本当にこれが請求書送付の連絡か？」を文脈から読み解く必要があり、人間のオペレーターが目視確認する場合、精神的な負荷も高く、見落としのリスクもつきまといます。

そこで、LLMによる「請求書取得/スキップメール判定」機能の開発を行いました。

請求書受領BPOにおける課題

BPO業務における電子メール受領の課題

機能概要と直面した課題

主な機能は以下の通りです。

  • メール判定: 「請求書取得」か「スキップ」かを判定する
  • URLソート: メール本文内のURLを抽出し、重要度順（請求書に関連するもの）にする
  • Confidence（確信度スコア）評価：Human in the Loopが必要かどうかを判定する

本番運用開始直後、ログを見るとLLMのレスポンスが返ってくるまでに 長いものでは想定タイムアウト（50秒）を超えていました。ローカル検証では長くても30秒程度だったためバッファ込みで見積もっていましたが、本番ではそれを超えるケースも多く観測され、レイテンシが課題となっていました。

モデル選定

そもそも、なぜ今回 gpt-5-mini を採用したのか。最初は「推論（Reasoning）モデルが新しく出たので試してみたい」という技術的な興味からスタートしました。実際に使ってみると、オペレーションで即実用可能なほど回答精度が高いことが分かり、正式採用を決めました。

もちろん、コストや速度面で有利なモデルとして gpt-4o-mini も検証しましたが、以下の理由から今回は採用しませんでした。

gpt-4o-mini の課題:

  • 特に「対象外メールのスキップ判定」の精度が低い。
  • 明らかに対象外のメールでも「スキップ」と判定せず、無理やり処理しようとする。
  • スキップ判定が出たとしてもConfidenceが低く、Human in the Loopが必要な割合が高すぎて実運用に耐えられない。

この結果から、「実用レベルの精度を出すには gpt-5-mini がより適している」という結論に至りました。

本記事における計測条件

ここからの検証データは、信頼性を担保するため以下の条件で計測を行いました。

  • 対象データ: 検証用に作成したメールデータ（請求書、明細書、利用規約、お問い合わせ、LPページのリンクが含まれる）
  • 試行回数: 各パターンにつき10回リクエストを実行
  • 評価指標:
    • Latency: 10回の平均(Avg)、最小(Min)、最大(Max)
    • Accuracy: 10回中、期待通りの判定が返ってきた割合

推論モデルのパラメータ調整

高速化のためにまず着手したのは、プロンプトの修正ではなく、gpt-5-mini から導入された新しいパラメータの調整です。 

ドキュメントを確認すると、 reasoning_effort や verbosity といった、これまでのモデルにはなかった制御パラメータが追加されていました。

GPT-5 New Params and Tools

Azure OpenAI 環境において検証した結果、当時は verbosity は操作できませんでしたが、 reasoning_effort は明確に挙動が変わることが確認できたため、ここのチューニングに絞りました。

reasoning_effort の調整

このパラメータには minimal, low, medium, high といった設定値が存在します。最初に機能リリースした時は、パラメータを明示的に指定していなかったのですが、当時のAzure OpenAI における reasoning_effort のデフォルト値は medium に設定されているようでした。

推論レベルを下げることで回答速度が改善するだろうという仮定のもと、現在の Azure 環境で確実に動作し、かつ最も高速な設定として low を試してみました。

// Go SDKでのリクエストイメージ
options := azopenai.ChatCompletionsOptions{
	...
    // デフォルトの "medium"は遅いため、明示的に "low" を指定
    ReasoningEffort: azopenai.ReasoningEffortValueLow, 
    ...
}

このパラメータ変更だけで、劇的な変化が起きました。

設定 平均レイテンシ (Avg) 最小 (Min) 最大 (Max) 精度
Default (Medium) 15,358ms 11,851ms 20,407ms 100%
Low 9,181ms 7,039ms 10,524ms 100%
  • 平均値の改善: 15秒台から9秒台へと、約40%の高速化を実現しました。
  • 最大（Max）の安定化: 最大レイテンシが 20秒→10秒へと半減しました。

これにより、想定タイムアウトに対して十分な速度を実現できるようになりました。

プロンプトエンジニアリング

パラメータ調整で大きな成果が出ましたが、プロンプトの見直しにより、さらに高速化できるのではないかと思い、追加で検証を行いました。

いくつかの仮説を立ててテストを行ってみたところ、パラメータ調整ほどのインパクトはありませんでしたが、reasoning_effort: low を指定した時からさらに約30%程度、速度を改善することができました。

※ 以降の検証では、reasoning_effort: low の結果をベース（Base）に比較していきます。

検証A: 推論処理で重そうな「ソート指示」を消してみる

今回の要件には「URLを重要度順にソートする」という処理が含まれていました。

「ソート指示」を消して単純なリスト出力にし、後処理でソートすれば速くなるのでは？と考えました。

## 制約
...
入力された全URLを必ず出力に含める（欠落厳禁）
各URLを正確に保持する（改変禁止）
scoreの降順でソートする // この指示を削除して検証
...
設定 Avg Min Max 精度
Base (ソート指示あり) 9,181ms 7,039ms 10,524ms 100%
ソート指示なし 9,515ms 8,393ms 10,650ms 100%
  • 結果: 速度に有意な差なし（誤差の範囲）。
  • 考察: 体感として、LLMに処理させずに、プログラムで後処理するのが良いかと思いましたが、追加の負荷はほとんどなかった

指示を消しても速度が変わらないため、「それならLLMにやらせた方が実装コストが浮いて得」 と判断し、ソート指示は維持しました。

検証B: 推論手順の「指定」vs「おまかせ」

次に、AIへの指示の推論手順の指定方法を変える実験を行いました。

従来のLLM（GPT-4等）では、Chain of Thought（CoT）として思考ステップを人間が定義するのが定石でしたが、推論モデルでもそれが有効かを確認しました。

  • Base（推論手順指定）: 「1.件名を見る → 2.本文を見る」など推論手順を明示。
  • 推論手順おまかせ: 推論手順は削除し、「評価観点（判断基準）」のみを定義。
...
/* ↓削除する↓ */
## 推論手順
1. メール件名を確認
2. 本文で各URLの前後の文脈を確認
3. URLのパス構造を分析
...
/* ↑削除する↑ */

## 評価の観点
1. メール本文での言及
2. URLパターン

## スコアリングガイドライン
両方が示唆 → 高スコア
片方のみ → 中スコア
無関係 → 低スコア
...
設定 Avg Min Max 精度
Base (手順指定) 9,181ms 7,039ms 10,524ms 100%
推論手順おまかせ 6,540ms 4,960ms 8,250ms 100%
  • 結果: 手順を任せたほうが2.5秒速い（約30%の改善）。
  • 考察: gpt-5-miniのような推論モデルの場合、人間が細かく思考パスを指定するよりも、モデルの自律的な思考に任せた方が短時間で解にたどり着けることが分かりました。

検証C: 評価観点の「指定」vs 「おまかせ」（不採用）

検証Bからさらに一歩進んで「評価観点（判断基準）」もAIに任せる実験を行いました。

  • 評価観点おまかせ: 推論手順に加えて、評価観点（判断基準）を削除（タスクの説明と制約のみ）
...
/* ↓削除する↓ */
## 評価の観点
1. メール本文での言及
2. URLパターン

## スコアリングガイドライン
両方が示唆 → 高スコア
片方のみ → 中スコア
無関係 → 低スコア
/* ↑削除する↑ */
...
設定 Avg Min Max 精度
Base (手順指定) 9,181ms 7,039ms 10,524ms 100%
推論手順おまかせ 6,540ms 4,960ms 8,250ms 100%
推論手順＆評価観点おまかせ 5,446ms 4,744ms 7,111ms 60%
  • 結果: 最速だが、品質が崩壊した。
  • 考察: 平均5.4秒で最速の結果が出ましたが、精度は60%まで低下。スキップ判定が出てもConfidenceが低いものが多く、使い物になりませんでした。

推論モデルにおけるプロンプトの最適解

以上の検証から、推論モデルにおけるプロンプトの最適解が見えてきました。

  1. 手順（How）は任せていい: 推論モデルは自律的に最適なパスを見つけられる。プロンプトで明示的に指定するよりも推論時間が短縮される。
  2. ゴール（What）は任せてはいけない: 評価観点まで任せると、基準がブレて品質が下がる。

最終的に、「推論手順はおまかせ、評価観点は指定する」という 検証B のプロンプトを採用しました。

まとめ

今回の取り組みのポイントは以下の通りです。

  1. 推論モデルのパラメータ reasoning_effort を適切に設定
    • デフォルト設定（Medium）は意外と重い処理を行います。タスクの難易度に合わせて low を指定するだけで、精度を落とさずに平均速度を40%向上させ、最大レイテンシを半減させることができました。
  2. プロンプトは推論「手順」ではなく「観点」を握る
    • 推論手順をガチガチに指定するよりも、評価観点だけを明確にして手順をAIに委ねる方が、推論モデルの特性を活かして高速かつ高精度に処理できることが分かりました。逆に、評価観点まで丸投げすると品質が破綻します。

この構成により、回答速度が課題となっていた処理が、精度を維持したまま安定して回るようになりました。

最後に: なぜ「AI BPO」の開発がエンジニアにとって最高に面白いのか

AI BPOチームでは 「内部のBPOオペレーターが利用するツール」 も開発しています。ユーザーはすぐ隣にいる同僚たちです。今回のような事業成長を見据えて最新モデル/尖ったAI機能を即座に検証・投入するという動きが取れるのは、私たちが取り組んでいる 「AI BPO事業」 ならではだと思います。

リリースした瞬間にフィードバックが秒速で返ってくるので改善ループがとにかく速く回り、さらにオペレーターによるHuman in the Loopがあるため、オペレーションでカバーしながら攻められる。そんな大胆な動きができるのがとても魅力的です。

弊社は現在積極的に採用を行なっています。この記事を読んでAIを活用した大胆でチャレンジングな機能を開発してみたいと思った方、興味を持った方はぜひお話ししましょう！

jobs.layerx.co.jp