自社サーバーで動く AI:LLM を社内システムに組み込む方法と、それを誰が作るのか

できる。会社は、サポートチケット、文書、社内ツールに AI を使いながら、そのデータを自社のサーバーの外に出さずにおける。大規模言語モデル（LLM）は、チャットアシスタントの裏で動いている種類の AI だ。こうしたモデルの一部はダウンロードして、会社が管理するサーバー、つまり自社の建物や自社のクラウドアカウントで動かし、社員がすでに使っているシステムにつなぐことができる。

モデルは仕事のうちの小さいほうの部分だ。システムが日々の運用にたどり着くかどうかを決めるのは、業務の選び方、正しい答えを書き表した説明、そして答えを確認し、ローンチ後にシステムを運用する、名前の決まった担当者である。この記事の最後の部分では、構築を申し出る会社をどう見極めるかを示す。

「自社サーバーで動く AI」とは、実際には何を意味するのか

「自社サーバーで動く AI」とは、モデルがあなたの会社の管理するハードウェアの上で動き、社外の AI 企業にテキストが一切送られないことを意味する。チケット、文書、質問は、あなたのシステムからモデルへ行って戻ってくるだけで、あなたのネットワークやクラウドアカウントの外に出ることはない。

これが可能なのは、オープンウェイトモデルがあるからだ。オープンウェイトモデルとは、開発元がモデルのファイルを公開しているモデルのことで、誰でもそれをダウンロードし、そのライセンスのもとでモデルを動かせる。ブラウザで使う AI サービスは仕組みが違う。あなたのテキストはプロバイダーのサーバーへ送られ、そこで処理される。

データを内側にとどめることは、モデルだけの話ではない。システムは、ログ、文書の検索インデックス、テストに使う例、そして人が答えを確認する画面も持っている。そのどれもがあなたのデータのコピーを抱えていて、どれもあなたのサーバーの上にとどめる必要がある。

社内システムのどの業務を LLM に任せられるのか

LLM が役に立つのは、今は人がテキストを読み、そのうえで何かを記入し、振り分け、書いている場面だ。社内の典型的な業務:

• 届いた文書を読む。フォーム、請求書、契約書、通知が、それを必要とするシステムのフィールドになる
• サポートチケットの振り分け。人がチケットを開く前に、トピック、緊急度、担当チームが設定される
• 返信の下書き。モデルが下書きを書き、サポート担当者が手を入れて送信する
• 社内文書をもとに社員の質問に答える。方針、マニュアル、過去のチケットを使い、答えごとに出典へのリンクを付ける。よく「プライベートな ChatGPT」と呼ばれるのがこれだ
• 長い資料の要約。メールのやり取り、通話メモ、案件ファイルを、次に引き継ぐ人のためにまとめる
• 文書をリストと照らし合わせて確認する。契約書に必要な条項がそろっているか、申請に必要な書類がすべてそろっているか

LLM に向かない仕事もある。それはプロジェクトが始まる前に知っておいたほうがよい:

• すでに厳密に決まっている計算やルール。普通のコードのほうが速く、しかも毎回同じ答えを出す
• 正しい答えがどういうものか、誰も言えない業務。それがなければ、モデルが機能しているかどうかを誰も判断できない
• 法的・金銭的な重みを持つ、人についての最終決定を、人が判断せずに下すこと。たとえば顧客を断ること
• 取り消せず、しかも誰も確認しない操作。たとえば送金

どんな業務にも使える簡単な判定がある。今は人がテキストを読んでこなしていて、正しい結果を書き出すことができ、誤った結果を害が出る前に捕まえられるなら、その業務は LLM に向いている。

データを自社サーバーの外に出せない。それでも AI は使えるのか

使える。選ぶのはモデルをどこで動かすかであり、よくある三つの方式のうち、データを自社の管理するサーバーにとどめられるのは二つだけだ:

• 自社サーバーで動くオープンウェイトモデル。モデルは、自社の建物やデータセンターにあるハードウェアの上で動く。得られるもの ― テキストはネットワークの外に一切出ず、社外の AI 企業がそれを受け取ることもない。手放すもの ― グラフィックスプロセッサー（GPU）を積んだサーバーを買う必要がある。モデルを実用的な速度で動かすにはこれが要る。そして、あなたのチームかパートナーがそれを動かし続ける。選ぶべきとき ― 規制、顧客との契約、あるいは自社の方針が、社外でのあらゆる処理を禁じている場合
• 自社のクラウドアカウントで動くオープンウェイトモデル。同じ種類のモデルが、クラウドプロバイダーから借りたサーバーの上で、あなたのアカウントの中、あなたが選んだリージョンで動く。得られるもの ― 買うべきハードウェアがないこと、あとから増やせるキャパシティ、そしてアカウントの中にとどまるデータ。手放すもの ― 建物とハードウェアはクラウドプロバイダーが運用し、モデルの運用は引き続き自分で行う。選ぶべきとき ― 会社がすでにそのクラウドで自社のシステムを動かしていて、社内のルールがそれを認めている場合
• モデルプロバイダーのサービス。AI 企業が動かすモデルに、直接、あるいはあなたのクラウドプロバイダーを通じて、契約のもとでテキストを送る。得られるもの ― 最も早い立ち上がり、プロバイダー自身のモデル、そして運用するサーバーがないこと。手放すもの ― データは実際にあなたのサーバーの外に出て、保存、保管場所、レビューについてはプロバイダーの条件に従う。選ぶべきとき ― すでに公開されている文書のように、契約のもとでデータを外に出してよい場合。データが本当に外に出せないなら、この選択肢は検討の対象外だ

一つの会社が複数の方式を併用することもできる。公開済みの文書はプロバイダーのサービスに送り、顧客の記録は自社で動かすモデルにとどめる、といった形だ。その場合、データの種類ごとに行き先を決めるルールを文書にし、確実に守らせなければならない。閉じた境界の中で LLM を動かすことについての、このブログの以前の記事が、これらの選択肢をより詳しく比較している。

自分で動かせるモデルで十分かどうかは、公開ランキングから持ってくるのではなく、あなた自身の文書とチケットで測る。社内の業務の多くは範囲が狭い。一種類のフォームを読む、決まったチームの一覧にチケットを振り分ける、といったものだ。そして、実際の仕事から取った例でテストすれば、その問いに答えが出る。

オープンウェイトモデルのライセンスはさまざまなので、選んだモデルのライセンスは誰かが読むべきだ。Alibaba が2025年に公開した Qwen3 のモデルと、OpenAI の gpt-oss のモデルは、Apache 2.0 ライセンスで公開されている。一方、その後の Qwen3.8 リリースで最大のオープンモデルには、独自の Qwen3.8-Max ライセンスが付いている。Meta の Llama 3.3 には Meta 独自のコミュニティライセンスが付いており、Meta の許容利用ポリシーに従うことを含む条件が加わる。

LLM を自社の社内システムに組み込むにはどうすればよいのか

LLM はあなたのシステムに取って代わるものではない。システムとシステムの間に入り、ある場所からテキストを読み、結果を別の場所に置く。社内システムに組み込むとは、四つの素朴な問いに答えることだ:

• テキストはどこから来るのか。ヘルプデスク、共有メールボックス、文書の保管場所、データベース
• 結果はどこへ行くのか。社員がすでに使っているフィールドや画面に、受け入れるか変えるかを選べる提案として入る。わざわざ開くのを覚えておかなければならない新しいツールに入るのではない
• 何に触れてよいのか。その業務に必要なデータと操作だけだ。チケットを振り分けるモデルに、返金や顧客アカウントへのアクセスは要らない
• どうやって止めるのか。作業を手作業のやり方に戻すスイッチを一つ、システムの担当者の手元に置く

一つのシステムの一つの業務から始める。最初は、モデルが提案し、人が決める。モデルが自分で動くことを許されるのは、実際の仕事で正しい結果を出し続けている部分だけであり、手作業のやり方はフォールバックとして残しておく。

今その仕事をしている人たちが、システムの形を決めるべきだ。どの文書が難しいか、どの答えが間違っているか、どこでのミスがお金につながるかを知っているのは彼らである。最初の数か月に答えを確認するのも彼らだ。だから、彼らの時間は計画に組み込んでおくべきである。

誰かを雇う前に、会社は何を決めておかなければならないのか

誰かがあなたのために AI システムを作る前に、七つの問いに書面で答えておく。どれもエンジニアリングの素養は要らない。そして、答えの一つひとつが、作るべきものを変える:

• どの業務を、どのシステムで行うのか。一つの業務を一文で言う。たとえば「ヘルプデスクに届いたチケットを、チームと緊急度で振り分ける」
• 正しい結果とはどういうものか。正しい答えの付いた実際の例を集める。答えを書くのは、今その仕事をしている人たちだ
• モデルはどのデータを見るのか、そしてそのデータはどこへ行ってよいのか。法務、リスク、データ保護の責任者に、データの種類ごとにこれを書き出してもらう
• 量はどれくらいで、いつなのか。1日あたりの文書やチケットの数と、最も忙しい時間帯
• 誰が答えを確認するのか。最初は、すべての答えを人が確認する。それが誰で、週に何時間かかるのかを明記する
• AI が使えないときはどうなるのか。作業は失われずに人の手に戻り、処理を待つ
• ローンチ後は誰が運用し、あなたは何を所有するのか。自社のチームか、サポート契約のもとでの作り手か。そして最後に、コード、例、ドキュメント

この七つの問いへの書面の答えが、あなたのブリーフになる。三つの作り手に渡せば、比べられる三つの提案が返ってくる。それがなければ、チャット画面のデモを三つ見せられるだけだ。

私たちの AI パイロットはデモでは動くが、本番にたどり着かなかった。誰の手を借りれば完成させられるのか

デモが答えるのは一つの問いだけだ。モデルは良い例でその業務をこなせるのか、という問いである。日々の運用では、さらに四つの問いが加わる。止まってしまうパイロットは、たいていそれらを飛ばしている:

• 何をもって正しいとするのか。合意した答えの付いた実際の例のセットと、システムが満たすべき合格ライン
• そのデータはそこに置いてよいのか。外部の AI サービスの上に作ったパイロットは、自社サーバーにとどめなければならないデータへ、そのまま移せるわけではない。自分で動かすモデルは、あらためてテストする必要がある
• 誤った答えはどこへ行くのか。別のシステムに使われる前に、人がそれを見て直せる場所へ
• 誰が担当するのか。システムを運用し、その答えを見守り、止まったときに呼ばれる、名前の決まった人またはチーム

止まったパイロットを完成させるとは、たいてい、より良いモデルを買うことではなく、モデルの周りにこの四つを作ることを意味する。本番にたどり着かなかった AI パイロットについての、このブログの以前の記事が、それぞれをより詳しく説明している。

止まったパイロットを引き継ぐ作り手は、誰であれ、あなたから三つのものを必要とする。パイロットの例、パイロットがうまく扱えなかった文書、そしてシステムを担当することになる人の名前だ。そのどれも求めない作り手は、新しいデモを作るつもりでいる。

自社サーバーで LLM を動かすには、いくらかかるのか

この記事では価格は示さない。「自社サーバーで動く AI システム」と一口に言っても、規模が何倍も違うプロジェクトが含まれる。上の七つの問いへのあなたの答えを誰も聞かないうちに出てきた数字は、営業の数字であって、見積もりではない。

役に立つのは、コストの種類を知っておくことだ。その多くは、あなたがコントロールできる判断に左右されるからである:

• ハードウェアまたはクラウドのキャパシティ。買うか借りるかした GPU 搭載サーバーで、平均的な時間帯ではなく、最も忙しい時間帯に合わせた規模にする
• あなたのシステムとの接続。モデルが読み込む、あるいは書き込むシステムは、一つひとつが別々の作業であり、それぞれに権限と記録がある
• 社内の人の時間。最初の数か月に、例を集め、正しい答えを書き、モデルの答えを確認する社員
• 誤った答えの修正。システムが動いている限り、毎週、誰かの時間がかかる
• 運用。セキュリティ更新、サーバーだけでなく答えの監視、そして止まったときに呼ばれる人
• モデルの入れ替え。新しいモデルは、古いモデルと入れ替える前にあなたの例でテストされ、変更のたびにそのテストが繰り返される

コストのかかり方は、プロバイダーのサービスとは異なる。プロバイダーは、モデルが読み書きするテキストの量に応じて課金する。自社で所有するサーバーや月単位で借りるサーバーは、忙しくても暇でもほぼ同じ費用がかかる。だから、どちらの方式が安くつくかは、仕事の量で決まる。

スコープは、コストのうちあなたが最も直接コントロールできる部分だ。一つの業務、一つのシステム、一つのチーム。これが、システムを広げる価値があるかどうかを示せる、最小の最初のバージョンである。

会社自身のインフラの内側で動く AI システムは誰が作るのか、そしてその相手をどう見極めればよいのか

会社が「自社サーバーで AI を動かしたい」と言うと、四種類のサプライヤーが名乗りを上げる:

• ソフトウェアベンダー。社員向けのチャットアシスタントのように、インストールして使う既製の AI 製品を売る。汎用のアシスタントにはよく合うが、業務が自社のシステムやルールに左右される場合には合いにくい
• クラウドプロバイダーとそのパートナー。モデルをマネージドサービスとして販売し（その場合、テキストはあなたのアカウントの外に出る）、自社のクラウドアカウントの中でオープンウェイトモデルを動かすためのツールも提供する。それらをつなぐ手助けを提供するところもある
• エンジニアリング企業。モデルとあなたのシステムの間の接続を、あなたの仕様どおりに作る。そのうちどこまでがあなたのものになるかは、契約で決まる
• 自社のチーム。最初のバージョンのために、外部のエンジニアを加えることもある

何よりも先に、どのサプライヤーにも次の証拠を求めること:

• クライアントのインフラの内側で本番に導入した AI システム。クライアントが認める場合は、そのクライアントの名前も添えて
• そのシステムが何をするのかを一文で。そして、今それを運用しているのは誰か
• モデルが誤った答えを出したとき、そのシステムで何が起きるか
• 用意された例ではなく、実際の文書やチケットを使ったウォークスルー
• 作業中にデータがどこへ行ったのか。ログやテスト用のコピーを含め、何かがクライアントのサーバーの外に出たかどうか
• 何を引き渡すのか。コード、例、設定、ドキュメント。そして、手元に残すものがあるかどうか

そのうえで、サプライヤーがあなたに何を尋ねるかに耳を傾ける。これを作ったことがある会社は、見積もりの前に次のことを尋ねる:

• どの業務を、どのシステムで行うのか。そして今それをしているのは誰か
• モデルがどのデータを見るのか、そしてそのデータについて社内のルールが何を認めているか
• 正しい答えの付いた実際の例があるかどうか、そして誰がさらに書けるか
• 誰が答えを確認するのか、そしてローンチから1年後に誰がシステムを担当するのか

amBrain は言語モデルを本番に導入したことがあるのか

上で挙げたサプライヤーの種類のうち、amBrain はエンジニアリング企業にあたる。

amBrain が言語モデルに関する自社の仕事について公に言えることは、次がすべてである:私たちは、あるクライアントの FinTech の境界の内側で、LLM インテグレーションを本番に導入した。ブローカーと取引所からの非構造化の通知 ― コーポレートアクション、銘柄の変更、証拠金の変更 ― を抽出・正規化し、トレーディングシステムが取り込む構造化レコードにするものである。

クライアントの名前は挙げない。そのプロジェクトでモデルがどこで動いたかは開示せず、そのプロジェクトについての数字も示さない。この記事はそのプロジェクトの事例紹介ではない。計画と選択の方法を説明するものであり、amBrain が、サポートチケットのシステム、社員向けアシスタント、あるいは上で挙げた通知の抽出以外の社内 AI システムを作ったと主張するものではない。

そのインテグレーション以外について:amBrain は2019年からソフトウェアを作ってきた。働き方は三つの形態がある。フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニアだ。顧客は、プロダクトとコードの完全な所有権を保持する。ただし、私たちの再利用可能なコンポーネントは除く。

まだ始めたばかりなら、役に立つ次の一歩はベンダー探しではない。この記事の七つの問いへの答えを書いた、一枚の紙だ。話をするすべての作り手に、私たちであれ他の誰であれ、同じ一枚を渡せば、それぞれの提案を一行ずつ比べられる。