ローカルLLMはオンプレミスだけではありません。完全閉域から、クラウドの専有・閉域構成まで。扱う情報区分と求められる統制水準から逆算して配置を決め、PoCで終わらせず本番カットオーバーと運用引き継ぎまでお引き受けします。
機密情報を外に出さずに生成AIを使える環境を構築します。完全閉域のオンプレミスから、AWS・Google Cloud・Azureの閉域構成まで、扱う情報区分から逆算して配置を決め、権限制御・DLP・監査証跡の設計、本番カットオーバーと運用引き継ぎまで一社で担います。
機密情報を理由に、生成AIが止まっている：図面・顧客情報・ソースコードを外部に送れないという一点で、全社の活用が「禁止」のまま動いていない。
オンプレか、クラウドかの二択で止まる：オンプレは調達も運用も重い。クラウドは外部送信になる。その中間に選択肢があることが検討に入っていない。
PoCは動いたが、本番に出せない：権限・監査ログ・障害時の対応が決まっておらず、誰が運用を持つのかも未定のまま止まっている。
「使えない」で止めず、 本番で回る構成まで設計します。
セキュリティ要件から、構成を逆算する：先に機材を決めると、後から統制が足せずに作り直しになります。扱う情報区分と求められる統制水準を確定させてから配置を選びます。脆弱性診断とAIガバナンス構築を本業に持つチームなので、統制の設計と実装が同じ窓口で完結します。認証・権限・監査ログは、動いてから足すのではなく最初から層として組み込みます。
完全閉域からクラウド閉域まで、同じ設計思想で組める：インターネットに繋がない完全閉域のオンプレミス、社内LAN完結の構成、クラウドのGPU専有、VPCエンドポイント経由のマネージドLLM。閉域度は5段階の連続で、要件次第では中間の段のほうが早く安全に立ちます。部門ごとに段を変える構成も、後から段を移す前提の設計も取れます。
PoCで終わらせず、本番カットオーバーと運用引き継ぎまで：検証で動くことと、本番で使い続けられることは別です。可用性・バックアップ・障害時の切り戻しを設計し、リハーサルで実演したうえでカットオーバーします。移行判定を通らなければ日程を優先せず延期します。並走運用で貴社の担当者に一次対応を移し、手順書一式をお渡しして運用を移管するところまでが範囲です。
情報区分の整理と配置モデルの選定：扱う情報と求められる統制水準を整理し、閉域度5段階のどこに置くかを決めます。
ハードウェア・クラウド構成の設計：利用人数と応答速度の要件から機材を選定し、見積比較と調達までご支援します。
ローカルLLM実行環境の構築：推論エンジンの構築、用途に合うオープンウェイトモデルの選定と量子化まで行います。
社内RAG・ナレッジ検索の構築：社内文書を検索できる形にし、回答の根拠となる参照元を提示できる状態にします。
権限制御・認証統合：SSOと部署別のロール設計を行い、文書ごとの参照権限を検索結果にも反映します。
監査証跡・ログ設計：プロンプト・出力・参照文書を紐づけて保全し、監査に提出できる形式まで整えます。
DLP・入出力フィルタリングの導入：機微情報の入力を検知・遮断し、出力側の確認が必要な用途を切り分けます。
統制設計と責任分解：利用ルールと運用規程を整え、誰が何を持つのかを責任分解表として確定させます。
本番カットオーバー支援：移行手順と切り戻しをリハーサルで実演し、判定を経て本番稼働に切り替えます。
運用引き継ぎ・継続支援：並走運用で貴社に運用を移し、その後はモデル更新への追従など必要な範囲で支援します。
進め方 1. お問い合わせ：気になっている点をお知らせください。ご相談は無料です。
進め方 2. ヒアリング：扱う情報、利用したい業務、既存の設備とクラウド契約を伺います。
進め方 3. 構成のご提案：配置モデルと統制水準の選択肢を、費用と併せて比較できる形でお出しします。
進め方 4. PoC構築：実データに近い題材で、応答の質と速度を実測します。
進め方 5. 本番カットオーバー：移行リハーサルで切り戻しまで実演し、判定を経て本番に切り替えます。
進め方 6. 運用引き継ぎ：並走運用で一次対応を移し、手順書一式をお渡しして運用を移管します。
扱う情報区分によります。外部送信が契約や規程で禁じられているなら完全閉域のオンプレミス、機密だが調達を待てないならクラウドのGPU専有、というように決めます。閉域度は5段階の連続で、部門ごとに違う段を選ぶ構成もよく取ります。まず情報区分を整理するところからご一緒します。
学習に使われないことが契約で担保でき、リージョンを固定でき、暗号鍵を自社で持てる。この3点が満たせて、かつVPCエンドポイント経由でインターネットを通らない経路を組めるなら、広義のローカルLLMとして候補に入ります。オンプレミスと同等の統制が取れるかを要件ごとに確認したうえでご提案します。
閉域で動かすなら、Llama・Qwen・DeepSeek・Kimi・GLM・MistralといったオープンウェイトモデルとGoogleのGemma、OpenAIのgpt-oss、日本語特化のELYZA・PLaMo・Swallow・Sarashinaが候補です。用途とGPUメモリの制約、日本語の扱い、必要な応答速度を実データで比較して決めます。モデルは入れ替えられる前提で構築するため、後から新しいモデルに移行できます。
これらは重みが公開されていないため、自社設備には置けません。使う場合はAmazon Bedrock・Google Vertex AI・Microsoft Foundry・Azure OpenAI Serviceといった事業者の閉域経路を通す形になり、配置モデルではL3〜L5に相当します。同じGoogleでもGemma、同じOpenAIでもgpt-ossはオープンウェイトなので完全閉域で動きます。扱う情報区分で両者を振り分ける構成もよく取ります。
扱いたいモデルの規模と同時利用者数で決まります。1〜10名の検証ならデスクサイド機で足り、部門展開ならGPUワークステーション、全社本番で冗長構成まで取るならGPUサーバ、という目安です。過剰投資を避けるため、検証機で実測してから本番構成を決める進め方をおすすめしています。
使えることが多いです。GPUの有無と容量、電源・冷却の条件を確認したうえで、追加投資を抑えられる構成をご提案します。既存のSSOや文書管理システムとの連携も設計に含めます。
誰がいつ何を入力し、どの文書を参照して、どんな出力が返ったかを紐づけて保全できます。保管先と保持期間は構築時に確定し、監査やセキュリティチェックシートに提出できる形式まで用意します。最高水準では改ざん検知つきの保管にも対応します。
PoCに1〜2ヶ月、本番設計に1〜2ヶ月、移行リハーサルに2〜4週間が目安です。ハードウェアを新規調達する場合は、その調達期間が加わります。調達を待てない場合は、クラウドのGPUで先に立ち上げて後からオンプレミスへ移す進め方も取れます。
そうなることを到達点に置いています。並走運用の期間に貴社の担当者が一次対応を行い、当社が後ろに付きます。実際の対応に合わせて手順書を直したうえで運用を移管し、以降はモデル更新への追従など必要な範囲だけの契約に縮小できます。
株式会社世良（Sera, Inc.）／ お問い合わせ: info@sera-inc.co.jp