本番にたどり着かなかった AI パイロット:データと運用に欠けていたもの

パイロットはうまくいった。人の手で選んだ文書のセットで、モデルはフィールドを抜き出し、チケットを振り分け、それを求めた人たちを納得させた。数か月たったいまも、それはサンドボックスでサンプルデータを相手に動いており、実際のキューで有効にするには何が必要なのか、誰にも言えない。

その溝は、モデルを取り替えても埋まらない。デモが答えるのは、モデルが文書を読めるかどうかだ。本番が問うのは、スキャンされた文書も、転送されたスレッドも、モデルが読み違える文書も含めて、すべての文書に何が起きるかであり、しかもそれは、パイロットが使ったサービスに渡すことがそもそも許されていなかったかもしれないデータの上で問われる。

デモはモデルが読めることを示し、本番はすべての文書について問う

2015年、Google の Sculley らは、実世界の機械学習システムのうち機械学習のコードが占めるのはごく一部にすぎず、それを取り巻く必要なインフラは広大で複雑だと書いた。言語モデルのパイプラインも同じ形をしており、その小さな部分だけで作られたパイロットには、本番で動かすための周囲が何もない。

パイロットにあったものと、本番のキューに必要なものを並べると、欠けている仕事は一つのリストになる:

• 評価:パイロットは誰かが気に入った数件の例、本番はフィールドごとに合格ラインを合意したラベル付きセット
• データ:パイロットはエクスポート、サンプル、ホスティング型の API、本番はあなたのインフラの外に出してはならないライブのソース
• 入力:パイロットはきれいな PDF、本番はスキャン、メールのスレッド、添付ファイル、予告なく変わるテンプレート
• 出力:パイロットは人が読んだテキスト、本番は別のシステムが取り込み、信頼しなければならないレコード
• 運用:パイロットは一度に一人のユーザー、本番はピーク時の量、モデルサーバーの停止、ローンチ後の担当者

モデルに手をつける前に受け入れセットを作る

最初に欠けている成果物は、実際の文書と、それぞれが出すべき答えを揃えたラベル付きセットである。これがなければ、プロンプトやモデルを変えるたびに、その日たまたま出力を読んだ人が良し悪しを判断することになり、パイロットは一度も書き出されたことのない関門を通過できない。

Google の Rules of Machine Learning（機械学習のルール）は、モデルより先に計測を置く。Rule #2 は「まず指標を設計し、実装する」である。抽出やチケットの振り分けでは、指標は文書全体に対する一つのスコアではない:

• 文書は実際のトラフィックから、月末、休日、変わった形式を使う送り手を含むだけの長さの期間にわたって集める
• ラベル付けは、いまその仕事をしている人に任せる。セットの一部では二人が独立にラベルを付け、両者の食い違いはノイズではなく仕様の穴として扱う
• フィールドごとに別々に採点する。誤った日付は、正しい名前と平均しても相殺されないからだ
• 合格ラインはフィールドごと、文書の種類ごとに書き、どのフィールドを自動化してよく、どのフィールドを必ず人に回すかを明示する
• 同じセットで現在の手作業のプロセスも測る。モデルを完璧さとではなく、実際のベースラインと比べるためだ
• セットの一部は、プロンプトを調整する人の目に触れないように取り置く。最終スコアが、プロンプトを合わせ込んだ例で測られないようにするためだ

境界の外に出せないデータは、ベンダーだけでなくアーキテクチャを変える

パイロットがホスティング型のモデルの上で、サンプル、合成データ、あるいは誰かが手作業で確認して使用を認めた文書を使って作られ、しかも実データを外部のプロバイダーに渡してはならない場合、パイロットの結果は引き継げない。内側のモデルは別のモデルかもしれないし、同じオープンウェイトモデルでも量子化やサービングの設定が異なるかもしれない。いずれにしても、その品質は受け入れセットで測り直さなければならない。

内側に持ち込むべき部品として真っ先に思い浮かぶのはモデルだ。だがそれだけではない。言語モデルのパイプラインは、モデルの呼び出し以外にも多くの場所へデータをコピーするからだ:

• 推論サーバーとモデルの重み。どちらもバージョンを固定する
• 埋め込みとベクトルインデックス。文書から導かれたものであり、文書と同じように保護しなければならない
• ログに残るプロンプト、出力、トレース。記録されたプロンプトには、その元になった文書が含まれるからだ
• 受け入れセット、アノテーションツール、レビューキュー
• 監視とエラートラッキング。ホスティング型のサービスとして動かすと、データの外部コピーになる

ログを制限区域の外に出さなければならない場面では、マスキングが役に立つ。Microsoft で始まったオープンソースのフレームワーク Presidio は、テキスト中の個人データを検出して匿名化する。そのドキュメントは、検出が自動で行われるため、機微な情報をすべて見つけられる保証はないと述べている。マスキングは露出を狭めるが、データを内側にとどめることの代わりにはならない。

入力は地味な半分:スキャン、スレッド、添付ファイル

パイロットが受け取るのは文書である。本番が受け取るのは、送り手が作ってくるものすべてだ。モデルを呼び出す前に、パイプラインはそれを、元の位置を指し示せるテキストに変えなければならない:

• スキャンや写真は OCR を通る。数字や表の列での OCR の誤りは、迷いのないテキストとしてモデルに届く
• メールやチケットのスレッドには、引用された返信、署名、免責文が含まれる。だから最新のメッセージを履歴から切り分けなければならない
• 中身は添付ファイルにあることが多く、形式ごとに専用の抽出経路が要る
• すべてのチャンクが出典 ― ファイル、ページ、オフセット ― を保持し、抽出された各フィールドを元の箇所までたどれるようにする
• 転送された通知やメールで再オープンされたチケットのような重複は、二つのレコードになる前に検出する

長い入力には、それ固有の注意が要る。2024年に TACL に掲載された Lost in the Middle で、Liu らは、検証したモデルについて、関連する情報が入力コンテキストの先頭か末尾にあるときに性能が最も高くなることが多く、長いコンテキストの中ほどにあるときには大きく低下することを示した。長い文書をセクションごとに分割し、すべてのチャンクに出典を保持させるほうが、モデルがコンテキスト全体を均等に読むと想定するより安全な既定の選択である。どちらがあなたの文書に当てはまるかは、受け入れセットが示す。

構造化出力には、スキーマ、バリデータ、そして誤った答えの行き場が要る

制約付きデコーディングは、モデルの出力をスキーマに合致する JSON に制限する。vLLM は structured outputs として、llama.cpp は grammar によってこれをサポートしている。これが決めるのはレコードの形であり ― バックエンドがサポートするスキーマ機能の範囲内で、かつ生成がトークン上限で打ち切られない限りにおいて ― 中身の正しさではない。形式として正しいレコードでも、誤った日付を含みうる。

正しさは、モデルの後で、業務がすでに信頼しているコードによって確かめる:

• 型と形式のチェック:日付、通貨、そして ISIN のようなチェックディジット付きの識別子
• フィールド間のルール。たとえば期間の終了日は開始日より前にはなりえない
• 既知の銘柄や顧客など、会社がすでに管理している参照データとの照合
• 原文との整合性:抽出された各値は、正規化する前の形で、それが引用する箇所に現れていなければならない

モデル自身の確信度は、関門としては弱い。2023年に公開された OpenAI の GPT-4 Technical Report は、多肢選択式のベンチマークにおいて、事前学習済みモデルは高度にキャリブレーションされていたが、事後学習によってキャリブレーションが低下したことを示している。モデルが自己申告する確信度やトークン確率は、受け入れセットに照らして検証すべきシグナルであって、無条件に信頼してよいしきい値ではない。

どれか一つでもチェックに通らなかったレコードは、下流のシステムではなくレビューキューへ行く。このキューはそれ自体が一つのプロダクトである。担当者、レビュアーの工数で見積もったキャパシティ計画、各フィールドの隣に表示される出典の箇所、そして受け入れセットへ還流する修正が要る。

チケットと文書は、モデルにとって信頼できない入力である

サポートチケットは社外の誰かが書いたテキストであり、文書には送り手が意図的に仕込んだ指示が含まれていることがある。OWASP Top 10 for LLM Applications 2025 は、プロンプトインジェクションを第1位に挙げている。そこには間接インジェクション、つまりウェブサイトやファイルなど、モデルが処理する外部コンテンツの中に指示が含まれて届くケースも含まれる。

同じリストのうち三つの項目は、文書パイプラインの設計ルールに置き換えられる:

• プロンプトインジェクション（Prompt injection）:すべての文書とチケットを信頼できないコンテンツとして明示し、送り手が編集できないテンプレートの中で指示から切り離す
• 不適切な出力処理（Improper output handling）:モデルの出力は、どのシステムもそれに基づいて動作する前に、ユーザーからの入力と同じように検証する
• 過剰なエージェンシー（Excessive agency）:パイプラインにはタスクに必要な最小限の権限だけを与える。チケットを読むモデルが、アカウントを閉じたり支払いを送ったりできないようにするためだ

OWASP は、プロンプトインジェクションを確実に防ぐ方法が存在するかどうかは不明だとも述べている。重みを担うのはプロンプトの言い回しではなく、出力のチェックと権限の制限である。

モデル、プロンプト、パーサを一つのバージョンとして固定する

パイプラインの振る舞いは、それぞれ独立に変わるいくつもの成果物の組み合わせで決まる。それらを一つのリリースとして扱い、そのリリースが生み出すすべてのレコードにその識別子を保存する:

• チェックサムで特定したモデルの重みと、その量子化方式、推論サーバーのバージョン
• プロンプトテンプレート、出力スキーマ、デコーディングのパラメータ
• OCR エンジン、チャンク分割のルール、バリデータ
• そのリリースの採点に使った受け入れセットのバージョン

固定しても、出力が同一になるわけではない。Thinking Machines Lab は2025年9月、推論サーバーが温度 0 でも同じプロンプトに対して異なる補完を返しうることを示した。リクエストの結果が、同じバッチにほかのリクエストがいくつ入っているかに左右されるからだ。同じ記事は、バッチ不変（batch-invariant）なカーネルを使えば、速度と引き換えにこれを取り除けることも示している。サーバーがそうしたカーネルを使っていない限り、再現性とは、同一のテキストを期待することではなく、リリースごとに受け入れセットを再実行してスコアを比べることを意味する。

運用:キャパシティ、キュー、そしてモデルサーバーが止まったとき

キャパシティは文書数ではなくトークンで計画する。入力長と出力長の分布を実際のトラフィックで測ること。長い添付ファイル一つが短いチケット多数と同じだけのコストになりうるうえ、生成時間は出力の長さとともに伸びるからだ。

サービングシステムは、アクセラレータを遊ばせないためにリクエストをバッチにまとめる。SOSP 2023 で発表された vLLM の論文で、Kwon らは、アテンションの key-value キャッシュをページングすることで、評価対象としたシステムと比べ、同程度のレイテンシでスループットが2〜4倍に向上したと報告した。バッチを大きくするとスループットは上がるが、個々のリクエストのレイテンシも上がる。バックオフィスのキューはそれを吸収できるが、対話的なステップは吸収できない。だから両者を分ける:

• サポート担当者が結果を待っているチケットのトリアージのような、対話的な作業。専用のキャパシティとレイテンシ目標を持たせる
• 夜間の抽出などのバッチ作業。ピークを吸収でき、一時停止もできるキューに載せる
• 取り込みとモデルサーバーのあいだのバックプレッシャー:上限付きのキューと同時実行数の上限により、文書の急増はサーバーを過負荷にする代わりに、待たされるか、リトライを促すシグナルとともに拒否される
• 文書をキーにした冪等な処理。クラッシュ後のリトライが二つ目のレコードを作らないようにする
• モデルサーバーが使えないときの、手作業のプロセスへのフォールバック。作業は消えずに、人の手を待つ

パイプラインの有効化を元に戻せるものにしているのは、フォールバックである。いま存在する手作業のプロセスは下支えとして残り、パイプラインはそれをある日を境に置き換えるのではなく、フィールドごとに仕事を引き取っていく。

サーバーだけでなく、答えを監視する

サーバーのダッシュボードが教えてくれるのは、パイプラインが答えたかどうかだ。答えが正しかったかどうかは教えてくれないし、新しいテンプレートで劣化したモデルもレイテンシは変わらない。抽出やチケットのパイプラインの監視は、その両方を対象にする:

• フィールドごと、文書の種類ごと、リリースごとの、レビューキューに回る率とレビュアーによる修正
• 自動処理されたレコードから定期的にサンプルを取り、人が受け入れ基準に照らして再確認する
• 入力のドリフト:新しい送り手、新しいテンプレート、言語の構成比、文書の長さ
• ルール別のバリデータの失敗。精度指標が動く前に、新しい形式を明らかにすることがある
• 文書の種類ごとのトークン、アクセラレータ時間、キューの滞留時間を、各段階のレイテンシと並べて

2024年7月に公開された NIST の Generative AI Profile（生成 AI プロファイル、NIST AI 600-1）は、この仕事を AI Risk Management Framework（AI リスクマネジメントフレームワーク）の四つの機能、すなわち統治（govern）、マッピング（map）、測定（measure）、管理（manage）のもとに整理している。名称よりも重要なのはその帰結である。ローンチ後の計測は、名前が付き人員が割り当てられた活動であって、パイロットチームが手の空いたときにやるものではない。

フィールドごと、文書の種類ごとに展開する:シャドー、アシスト、そして自動化

ある日を境にすべてに対してパイプラインを有効にすると、あらゆるリスクが一つの出来事に結びつく。段階的なロールアウトは、それらを切り離しておく:

• シャドー:パイプラインは本番トラフィックを処理するがどこにも書き込まず、そのレコードを人が作ったものと比べる
• アシスト:パイプラインが事前入力し、人がすべてのレコードを確認し、修正はフィールドごとに数える
• フィールドごと、文書の種類ごとの自動化。本番トラフィックで合格ラインを保てている範囲に限って行い、それ以外は引き続きレビューする
• 文書の種類ごとにアシストモードへ戻すスイッチ。監視している率が上限を超えたとき、運用の担当者が別途の承認なしに使う

文書をうまく読めるのに本番にたどり着かないパイロットは、読むことに失敗したのではない。合格すべき受け入れセットも、使うことを許されたデータ経路も、誤った答えの行き場も、ローンチの翌日を引き受ける担当者も、一度も与えられなかったのである。

これを本番に届ける会社は、あなたが望むモデルより先に、あなたの文書を求める

この記事の背景にある問い、つまり誰が LLM パイプラインをあなた自身のインフラの内側に置き、実際に本番に届けられるのかには、ベンダー一覧がなくても使える見分け方がある。この仕事をしている会社は、モデルを推薦する前に、受け入れと運用について尋ねる:

• 質の悪いものも含めて、実際の文書とチケットのサンプルを、あなたの環境の中で、あるいはあなたのデータ契約のもとで確認させてほしいと求め、それらを今の手作業のプロセスがどう扱っているかを尋ねる
• どんなチューニングよりも先に、あなたの側の人と一緒に、フィールドごとの合格ラインを持つ受け入れセットを作ることを提案する
• 重みやインデックスから、ログ、トレース、評価データ、レビューツール、監視まで、データがコピーされるすべての場所を列挙し、そのそれぞれが内側にとどまることを示す
• バリデータ、レビューキュー、手作業の処理へのフォールバックを、モデルと同じ設計文書に書く
• モデル、プロンプト、スキーマ、パーサをまとめて固定するリリースと、フィールドごとにシャドーから自動化へ進むロールアウトを持ち込む
• ローンチ後に誰がパイプラインを運用し、誰がサンプルをレビューし、モデルサーバーが止まったとき誰が呼ばれるかを名指しする

どの項目も、最初の打ち合わせで尋ねることができる。曖昧な答えが返ってきたなら、パイロットに欠けている仕事は、まだスコープが定められていないということだ。

だから最初の問いは、境界の内側でどのモデルを動かすかではない。どの文書のどのフィールドなら自動化を受け入れるのか、それを何に照らして測るのか、そして検証に通らなかったレコードを誰が引き取るのか、である。

上の要約で述べた本番のインテグレーション以外に amBrain が公に裏付けられること:amBrain は2019年からソフトウェアを作ってきた。働き方は三つの形態がある。フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニアだ。