ML チームなし:自社サーバー上でサポートチケットと文書を扱う LLM システムを、ローンチ後に誰が運用するのか

自社のサーバー上でサポートチケットを振り分け、文書を読む LLM システムも、ローンチ後には運用する人が必要だ。LLM は大規模言語モデル（large language model）の略で、ChatGPT の裏にあるのと同じ種類の AI である。機械学習（ML）のチームを持たない会社には、三つの道がある。システムを構築した会社が、サポート契約のもとで運用を続けることができる。引き継ぎの後に、自社の IT チームが代わりに引き受けることも、その会社と仕事を分担することもできる。どの道でも、誰かが定期的に回答の品質を確かめ、モデルの変更を本番に出す前に一つずつ承認しなければならない。

ローンチ後の LLM システムの運用には、何が含まれるのか

ローンチ後の LLM システムの運用は、次のような繰り返し発生する仕事に行き着く:

• サーバー（多くの場合、言語モデルを動かすチップである GPU を備える）と、モデルを動かすソフトウェアの更新
• 使用中のモデルのバージョンと、それをいつ変えるかの判断
• 自社のチケットと文書の決まったサンプルで、定期的に回答を採点すること
• レビューキュー、つまりソフトウェアが人に回した項目と、それを処理するスタッフ
• 自社の側の変化。たとえば新しいフォーム、チケットの区分、業務ルール
• システムが何をしたかを記録するログと、チケットや文書へのアクセス権
• 夜間の障害と、呼び出される担当者

vLLM は、自社のサーバーでモデルを動かすためのオープンソースのプログラムの一つだ。2026年10月20日に閲覧した GitHub のセキュリティのページには、バージョン0.31.0で修正された欠陥についての、2026年10月6日付のアドバイザリーが載っている。アドバイザリーのタイトルはこうだ:「1件のリクエストに含まれる過大な min_tokens によって vLLM エンジンがハングし、その間も /health は正常を示し続ける」。このタイトルの min_tokens とは、回答の最小の長さを指定するリクエストの設定である。

監視ツールは、/health のようなアドレスを確認して、サーバーが生きているかどうかを確かめる。vLLM のアドバイザリーが説明するケースでは、サーバーは正常に見えるのに、リクエストへの応答はすでに止まっている。LLM システムの監視では、実際のテストリクエストを送り、答えが返ってくることを確かめるべきだ。

自社のシステムは、AI を組み込んだヘルプデスクツールと何が違うのか

ソフトウェア・アズ・ア・サービス（SaaS）、つまりインターネット経由で借りるツールとして売られているヘルプデスクツールでは、サービスを運用するのはベンダーであり、モデルはベンダーのサーバーか、ベンダーが取引する会社のサーバーで動く。自社のチケットは、ベンダーとそれらの会社に送られる。そうしたツールと自社のシステムのどちらを選ぶかは、文書 AI ソフトウェアかカスタム LLM パイプラインかについての記事で扱っている。

ヘルプデスクベンダーの Zendesk は、同じ日に閲覧した生成 AI のページで、「Zendesk は二つの方法で LLM をサービスに統合している」と述べている。一つは「AWS Bedrock、Microsoft Azure、Groq、Fireworks AI など」のプラットフォームでホストされたモデルを使う方法で、Zendesk によれば、この場合「LLM プロバイダーがお客様のサービスデータにアクセスすることはない」。もう一つは、OpenAI や Google Gemini のように「モデルプロバイダーが直接ホストする」モデルを使う方法だ。これについて Zendesk は、モデルに送られたテキストとその回答は「いかなるログの仕組みにも保存されない」としている。

もう一つのヘルプデスクベンダーである Intercom は、サブプロセッサー、つまり同社に代わってデータを処理する会社の一覧を公開している。2026年6月25日から有効で、同じ日に閲覧したこの一覧は、「AI 処理」のための会社として、ほかとあわせて OpenAI、Anthropic、Google、Microsoft を挙げている。ページには、これらの一覧は「Intercom によって随時更新される場合がある」とある。

LLM システムを構築した会社に、運用を続けてもらえるのか

システムを構築した会社は、サポート契約、つまりローンチ後もシステムを動かし続けることを引き受ける契約を提示することがある。契約が次の点について何と書いているかを確かめる:

• 何をインシデントとみなすか。たとえばシステムの停止や、多くの文書で一つのフィールドを読み誤ること。そして、それぞれの種類にどれだけ早く対応するか
• 誰が、どのアカウントで自社のサーバーにログインしてよいのか。そして、そのアクセスがどう記録されるか
• サーバーの費用を誰が払い、処理能力の追加が必要になったときに誰が決めるか
• 変更依頼とは何か。たとえば文書の種類やチケットの区分の追加。そして、その価格がどう決まるか
• 毎月どんな報告を受け取るか。たとえば品質スコア、レビューキューの件数、インシデント

その会社に任せておけば、自社のスタッフに求められることは最も少ない。その代わり、ノウハウはその会社に残り、自社はほとんどの変更でその会社に頼ることになる。その会社が離れるときに自社が何を所有しておくべきかは、COO が契約前に尋ねるべき質問についての記事で扱っている。

自社の IT チームには ML の経験がない。システムを引き継げるのか

自社のサーバーをすでに運用している IT チームなら、通常、LLM システムのサーバー、アクセス権、バックアップ、監視を自分たちの仕事に加えられる。品質スコアの読み方や新しいモデルのバージョンのテストのように、言語モデルに特有の仕事には、まず研修が必要になる。

引き継ぎにあたって、IT チームにはランブック、つまり日常の仕事と、レビューキューがいっぱいになるといった既知の障害ごとの手順書が必要になる。正しい答えを付けたチケットと文書のテスト用サンプルと、それを使ってシステムを採点するスクリプトも必要だ。コードとモデルのファイルは、自社が管理するストレージに置くべきである。

テスト環境、つまり変更が実際のチケットに届く前に試されるシステムのコピーは、ローンチの前に用意しておくべきだ。研修はそこで行える。自社のチームがコピーの上で日常の作業を行い、その会社のエンジニアがその作業を確認する。

プロンプトとルールの変更には責任者が必要だ。プロンプトとは、モデルに何をすべきかを伝えるテキストである。フォームが変わったり新しいチケットの区分ができたりしたら、誰かがプロンプトやルールを更新し、テスト用のサンプルでもう一度採点しなければならない。その担当者を IT に置くのか、その会社に置くのか、それともサポートのようにそのプロセスを持つチームに置くのかを決めておく。

自社の IT チームとその会社の分担は、どう機能するのか

分担する場合、自社の IT チームがサーバーとアクセスを受け持ち、モデルの変更と品質の問題ではその会社を呼ぶ。

分担には隙間が生まれうる。品質が落ちたとき、IT はモデルのせいにし、その会社はサーバーのせいにするかもしれない。だから、誰が何を決めるのかを契約に書面で定めておくべきだ。

たとえば、新しいモデルのバージョンは、その会社がテスト用のサンプルで採点した後に、自社が一つずつ承認する。品質の問題を直すのはその会社の仕事であり、サーバーへのアクセスは引き続き自社の IT チームが決める。夜間にアラートが鳴ったとき最初に確認する担当者と、その担当者が相手側にどう連絡するかも決めておく。

ローンチ後に回答の品質が落ちることがあるのはなぜか

精度はドリフトすることがある。つまり、エラーメッセージを一切出さずに、ゆっくりと変わっていく。製品のローンチ後に現れる新しいチケットのトピック、変更されたフォーム、新しいモデルのバージョンは、いずれもドリフトの原因になりうる。サーバーはそれまでどおり動き続けるので、サーバーの監視には精度の低下が表れない。

ドリフトが見えてくるのは、正しい答えを付けた同じチケットと文書のサンプルで、もう一度採点したときだ。採点は、たとえば毎月のように定期的に行い、モデル、プロンプト、ルールを変えるたびにも行う。毎回のスコアを、ローンチ時に記録したスコアと比べる。

テスト用サンプルの作り方は、停滞した AI パイロットについての記事と、COO が尋ねるべき質問についての記事が説明している。どの道を選ぶにしても、契約では再採点を行う担当者を決め、誰が結果を見るのかを定めておくべきだ。

モデルを変えるときは、誰が決めるのか

自社サーバー上のオープンウェイトモデルなら、いつ切り替えるかは自社が決める。オープンウェイトモデルとは、開発元がモデルのファイルを公開し、誰でもそのライセンスのもとでダウンロードして動かせるモデルのことだ。それでもライセンスは適用され、新しいバージョンには別のライセンスが付いてくることがある。

Google の Gemma モデルが一例だ。同じ日に閲覧した Hugging Face のモデルサイトにある Gemma 3 のページは、Gemma 利用規約（Gemma Terms of Use）を示しており、この規約は禁止された利用に関するポリシー（Prohibited Use Policy）を取り込んでいる。Google のオープンソースブログは、2026年4月2日に「Gemma 4 モデルは、Gemmaverse の中で初めて、OSI 承認の Apache 2.0 ライセンスのもとでリリースされたモデルである。」と述べた。したがって、Gemma 3 から Gemma 4 に移ると、弁護士が読むライセンスは、Google 独自の規約から、オープンソースライセンスである Apache 2.0 に変わる。

自社サーバー上のシステムでも、ホスティング型の API、つまりインターネット経由で別の会社のサーバーにつなぐ接続を通じて、モデルを呼び出すことがある。そのモデルは、その会社のスケジュールで提供が終了する。同じ日に閲覧した Anthropic のモデル廃止（deprecations）のページには、「提供終了日を過ぎたモデルへのリクエストは失敗する。」とある。Anthropic は、稼働中のデプロイメントを持つ顧客に対し、「一般公開されたモデルについては、モデルの提供終了の少なくとも60日前に通知する」としている。同じページは、これらの日付は Anthropic 自身のプラットフォームに適用されるもので、Amazon Bedrock と Google Cloud は「独自の提供終了スケジュールを定める」とも付け加えている。

切り替えのたびに、本番に出す前に新しいバージョンを自社のサンプルで採点し、スコアが落ちたときのために古いバージョンをすぐ使える状態にしておくことになる。Anthropic のページは、「提供終了日よりも十分前に、新しいモデルでアプリケーションを徹底的にテストする」ことを勧めている。

サポートチケットでシステムをだますことはできるのか

プロンプトインジェクションとは、システムに送られたテキストに、モデルに向けた指示が含まれている攻撃だ。サポートチケットは社外から届くので、それを読むシステムは稼働している限りこの攻撃にさらされ続ける。OWASP というセキュリティプロジェクトが公開しているリスクの一覧で、同じ日に閲覧した OWASP Top 10 for LLM Applications 2025 は、プロンプトインジェクションを第1位に挙げている。例の一つにはこうある:「攻撃者がカスタマーサポートのチャットボットにプロンプトを注入し、それまでのガイドラインを無視し、非公開のデータストアに問い合わせ、メールを送信するよう指示する。その結果、不正アクセスと権限昇格が起きる。」

プロンプトインジェクションに対する設計上のルール、たとえばシステムに仕事に必要な以上のアクセス権を与えないことは、停滞したパイロットについての記事にまとめてある。OWASP は、システムの稼働中に繰り返し行う対策も挙げている:「モデルを信頼できないユーザーとして扱い、定期的にペネトレーションテストと侵害のシミュレーションを行う」。ペネトレーションテストとは、テスト担当者が許可を得たうえで、意図的に侵入を試みることだ。

ペネトレーションテストは運用業務のスケジュールに組み込むべきであり、どちらの側がそれを発注し、見つかった問題を直すのかを契約に書いておく。ログにはチケットの全文が残ることがあるので、誰がそれを読めるのか、どれくらいの期間保存するのかを決めておく。

システムの運用には毎月いくらかかり、契約の前に何を尋ねるべきか

自社サーバーでの月々の費用は、まずサーバーとその GPU（購入したものか借りたもの）、そしてレビューキューにかかるスタッフの時間から始まる。その会社が何らかの役割を担い続けるならサポート契約の費用が加わり、変更のたびの再テストも費用を増やす。数字は示さない。どれも自社の量と構成によって決まるからだ。

費用の内訳は、選ぶ道によって変わる。その会社がシステムを運用するなら、費用の多くはサポート契約にある。引き継ぎの後は、研修も含めて、自社のスタッフの時間が大きな割合を占める。

システムの構築と運用を申し出るすべての会社に、同じ質問をする:

• ローンチ後、運用の仕事のうちどれをそちらが引き受け、どれを当社の IT チームが行うのか
• 当社のテスト用サンプルで、どれくらいの頻度でシステムを採点するのか
• 当社が使っているモデルのバージョンが提供終了になったとき、再テストの費用は誰が払うのか
• 引き継ぎのときに、当社の IT チームは何を受け取るのか。そして、IT チームが単独でシステムを運用できることを、そちらはどう確かめるのか

ライセンスの条件はモデルごとに異なり、データ保護のルールは国によって異なる。この記事は法的助言ではないので、自社に適用される条件は弁護士に確認する。

amBrain はどこに位置づけられるか

amBrain が公に説明している言語モデルのプロジェクトは、次の一件だ:「私たちは、顧客の FinTech 環境の境界内で LLM の統合を本番稼働させた:ブローカーや取引施設から届く非構造化の通知 ― コーポレートアクション、銘柄や証拠金の変更 ― を抽出・正規化し、トレーディングシステムが取り込む構造化された記録にするものだ。」

この記事は事例紹介ではなく、顧客のための仕事についても述べていない。引用した一文は、そのシステムを現在誰が運用しているのかも、そのモデルがどこで動いているのかも、この記事のどの段階を含んでいたのかも述べていない。この記事のサポートチケット、文書、運用の道は一般的な例であり、そのプロジェクトや amBrain のほかの仕事から取ったものではない。

ここで名前を挙げたベンダー、モデルの開発元、ソフトウェアのプロジェクトは、公開されているページからの例であり、この記事は、amBrain とそれらのいずれかとのあいだに何らかの関係があるとは主張しない。amBrain の価格、期間、条件も示さない。

amBrain は2019年からソフトウェアを作っている。働き方には三つの形態がある:フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニア。所有権についての一文はこうだ:「顧客は、プロダクトとコードの完全な所有権を保持する。ただし、私たちの再利用可能なコンポーネントは除く。」amBrain が候補リストに入っているなら、ほかのどの会社とも同じ質問を渡すこと。