2022 年から、私は LLM を実際のプロダクトのワークフローに組み込んできました。その一部が社内向けのテキスト要約・AI application プラットフォームで、OpenAI API、Ollama、ローカルモデル、batch processing を統合し、制御しやすく運用しやすい model usage を重視しています。

社内システムの詳細は公開に適さないため、この記事は詳細なケーススタディではありません。要約パイプラインを設計・運用するときに私が使っている原則とトレードオフをまとめたものです。記事中の API の挙動は執筆時点（2026 年 10 月）の公式ドキュメントで確認していますが、実際に使う前には最新のドキュメントを確認してください。

要約は API を呼ぶだけでは終わらない

要約のデモはすぐに作れます。テキストをプロンプトに入れて「要約して」と頼めば、数分で結果が出ます。本当の仕事はデモの後から始まります。

  • 入力の長さは一定ではなく、モデルの context length を超えるテキストもある。
  • 一度に大量の件数を処理すると、rate limit、タイムアウト、部分的な失敗に直面する。
  • 下流のシステムは固定フォーマットを必要とするが、モデルの出力は毎回同じ形とは限らない。
  • コスト、レイテンシ、データの機密性によって、どのモデルに送るべきかが変わる。
  • モデルやプロンプトを変えた後、品質が上がったのか下がったのかを把握する必要がある。

そのため私は、要約を 1 回の API 呼び出しではなく、データ処理のパイプラインとして設計しています。

パイプラインの分解

処理は、それぞれ観測でき、個別に再実行できるステージに分けています。

  1. 前処理：書式のノイズ、重複した内容、モデルに送る必要のないフィールドを取り除きます。環境の外に出すべきでないデータもこの段階で扱います。入力がきれいなほど、トークン使用量も出力品質も管理しやすくなります。
  2. 分割：まずトークン数を見積もり、モデルが扱える長さを超える場合は段落や意味の区切りで分割します。重要な箇所が途中で切れないよう、必要に応じて少し重複させます。
  3. モデル呼び出し：短いテキストはそのまま要約します。長いテキストは map-reduce 方式で、各チャンクを要約してから、それらをまとめて最終的な要約にします。各呼び出しの入力が管理できる範囲に収まり、失敗しても該当チャンクだけを再実行すれば済みます。
  4. 検証：出力フォーマット、必須フィールド、長さ、明らかな誤りを確認し、通らないものは失敗として記録するかリトライに回します。
  5. 出力：使用したモデル、プロンプトのバージョン、処理状態と一緒に結果を保存し、後から追跡・比較できるようにします。

ローカルモデルでは context length に特に注意が必要です。Ollama のデフォルトの context length は VRAM の容量によって決まり、OLLAMA_CONTEXT_LENGTH で変更でき、実際の割り当ては ollama ps の CONTEXT 列で確認できます（Context length 公式ドキュメント）。この設定を確認しないと、長いテキストがモデルに最後まで読まれない可能性があります。Ollama のインストール、コマンド、環境変数は Ollama コマンドと設定 にまとめています。

下流につなぐための structured output

要約を他のシステムで使う場合は、モデルに JSON で出力させ、schema でフィールドを制約します。

  • OpenAI の Structured Outputs は、strict モードで指定した JSON Schema に沿った出力を返します。JSON mode は有効な JSON であることしか保証せず、schema への準拠は保証しません。モデルの拒否（refusal）や、出力トークンの上限に達して不完全になった応答は別途処理する必要があります。
  • Ollama は format パラメータで JSON schema をサポートし、OpenAI 互換 API では response_format を使います。公式ドキュメントは、schema をプロンプトにも含め、temperature を 0 にすると結果が安定しやすいとしています（Structured outputs 公式ドキュメント）。

schema が保証するのは「形」だけで、内容の正しさではありません。フォーマットの検証を通っても、要点が抜けていたり、原文にない内容が含まれていたりすることはあります。

クラウド API とローカルモデルの選び方

Gemma 4 12B についての記事（繁体字中国語）で書いたように、ローカルモデルの価値はクラウドモデルを置き換えることではなく、デプロイ可能な中間の選択肢を補うことにあります。要約パイプラインでモデルを選ぶときも、これが基本的な考え方です。

  • クラウド API は、高い理解力、長いコンテキスト、複雑な指示が必要なタスクに向いており、GPU やランタイムを自分で保守する必要もありません。
  • ローカルモデル は別の問題を解決します。プライベートな環境で動かせるか、データを自分の環境に留められるか、推論コストとレイテンシを管理できるか、といった点です。

実際には、どちらか一方だけには頼りません。両方を同じパイプラインに接続できるようにしておくのがよい方法です。Ollama は OpenAI 互換の API を提供しており（ローカルのデフォルトは http://localhost:11434/v1/）、同じクライアントコードでも base URL とモデル名を変えるだけで切り替えられます（OpenAI compatibility 公式ドキュメント）。ただし、互換であっても完全に同じではありません。たとえば context length は OpenAI 互換 API からは設定できないため、切り替える前にそれぞれテストが必要です。

選ぶときは、データの機密性、必要な品質、許容できるレイテンシ、全体のコスト、そして量子化したモデルが実際のハードウェアでどう動くかを見ます。ベンチマークは参考にすぎず、最終的には自分のデータでテストするしかありません。

Batch、リトライ、コスト管理

Batch processing

即時の結果が必要ない処理には batch processing を使います。OpenAI の Batch API は JSONL ファイルでリクエストを送り、24 時間以内に完了し、同期呼び出しより 50% 安く、独立した rate limit を持ちます。出力の順序は入力と一致するとは限らないため、各リクエストの custom_id で結果を突き合わせる必要があります。失敗したリクエストや期限切れのリクエストは別の error file に出力されるので、別途処理します。

ローカルモデルにはこのようなマネージドの batch サービスがないため、処理のペースは自分で制御します。同時実行数を制限し、GPU メモリやサービスを使い切らないようにします。

リトライ

リトライにはルールが必要で、無限に再送してはいけません。OpenAI の rate limits ガイド では次のように推奨しています。

  • Retry-After があればそれに従って待ち、なければ jitter 付きの exponential backoff を使う。
  • リトライ回数と合計の待ち時間に上限を設ける。
  • 失敗したリクエストも 1 分あたりの制限にカウントされるため、連続して再送すると回復がかえって遅れる。
  • 公式 SDK は一部のエラーを自動でリトライするため、独自にリトライを実装する場合は二重にカウントしないようにする。
  • クォータや請求に関するエラーはリトライしない。

さらに私は、リトライはチャンク単位または 1 件単位で行い、すでに成功した部分を識別できるようにしておく、という原則を加えています。バッチ全体をやり直さずに済むようにするためです。

コスト管理

コストの大部分は設計の段階で決まります。

  • 前処理で不要な内容を削り、入力トークンを減らす。
  • max_tokens は想定する出力の長さに近い値にする。OpenAI は rate limit の計算に max_tokens と推定リクエストトークン数の大きい方を使うため、大きすぎる値は枠を無駄にする。
  • 急がない処理は Batch API かローカルモデルに回す。
  • 呼び出しごとのモデルとトークン使用量を記録し、コストがどこにかかっているかを把握する。

出力品質の検証

要約の品質は自動化だけでは判断しにくいため、2 つの層に分けています。

  • 自動チェック：schema を通るか、必須フィールドがあるか、長さは妥当か、拒否や途中で切れた出力がないか。これらは必須条件で、満たさないものは下流に送りません。
  • 人によるスポットチェック：定期的にサンプルを抜き出して原文と要約を比べ、要点の抜け、意味の歪み、原文にない内容がないかを確認します。モデルやプロンプトを変える前後で同じサンプルを比較すると、変更が本当に効果があったかがわかります。

OpenAI のドキュメントも、structured output が保証するのはフォーマットだけであり、内容が要件を満たしているかは評価（evaluation）を別に用意して確認すべきだとしています。スポットチェックのサンプルと結果は残しておけば、次にモデルを変えるときにそのまま再利用できます。

学んだこと

  • 先にパイプラインを設計し、それからモデルを選ぶ。 前処理、分割、検証、リトライが整っていれば、モデルの切り替えコストは大きく下がります。
  • クラウドとローカルは二者択一ではない。 両方を同じパイプラインに接続し、データ、品質、コストに応じて処理の種類ごとに振り分けます。
  • フォーマットが正しくても内容が正しいとは限らない。 schema の検証はフォーマットの誤りは防げても、要点の抜けは防げません。人によるスポットチェックは省けません。
  • 一度で正しくするより、追跡できることのほうが重要。 モデル、プロンプトのバージョン、トークン使用量、処理状態を残しておけば、問題が起きたときにどこから調べればよいかがわかります。