LLM テキスト要約パイプラインの設計とトレードオフ：OpenAI API、Ollama、ローカルモデル

Mon, 26 Oct 2026 00:00:00 +0800

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

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

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

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

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

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

パイプラインの分解

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

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

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

下流につなぐための structured output

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

AI on Clarence｜Backend・AI・DevOps・Infrastructure

LLM テキスト要約パイプラインの設計とトレードオフ：OpenAI API、Ollama、ローカルモデル

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

パイプラインの分解

下流につなぐための structured output