閉域ローカルLLMの運用手順書。モデル更新・脆弱性対応・監査ログ・バックアップを四半期で回す

閉域に置いたローカルLLMは、構築した日が最も安全で、放置した分だけ弱くなります。インターネットにつながないサーバーには、脆弱性の修正版も新しいモデルも、人が持ち込まない限り入ってきません。「社内に閉じているから安心」と運用を省くと、半年後には既知の脆弱性を抱えたまま稼働するサーバーと、更新を知らない担当者だけが残ります。閉域環境の構成そのものは『生成AIをオフラインで使う2026』で、閉域でも残るリスクは『ローカルLLMは本当に安全か』で扱いました。本記事はその先、「動かし続ける手順」に絞ります。

対象は、情報システム部門の担当者と、運用を引き受けるベンダーの両方です。日次から年次までの運用カレンダーを置き、モデル更新・脆弱性対応・監査ログ・バックアップ・障害対応・担当交代の6つの手順を、そのまま手順書に転記できる粒度で書きます。工数の目安は『導入したローカルLLM、誰が維持するのか』で整理した平常月1〜2人日、更新やCVE対応が重なる月3〜5人日の範囲で組んでいます。

この記事の要点

• 閉域ローカルLLMの運用は、日次の死活確認と週次のログ確認を土台に、四半期のモデル更新・脆弱性対応・復旧訓練・権限棚卸しを回す形に落とすと、平常月1〜2人日の範囲で収まります
• モデル更新は「候補選定→オンライン側で取得とハッシュ照合→持ち込み台帳→評価シートで旧モデルと比較→切り替え→切り戻し準備」の6段階で、旧モデルを最低1世代残します
• 閉域では脆弱性情報も修正版も自動では届かないため、「誰が・どの情報源を・どの頻度で見るか」と「検証環境で当ててから本番へ」を手順に固定します
• 監査ログは記録項目・保存期間・閲覧者を表で決め、月次で「残っているか」「読める人が増えていないか」を点検します。入出力の本文は原則残しません
• バックアップはモデル・設定・RAG索引・ログ・ユーザーDBの5点を世代管理し、年1回は実際に復旧して手順書の通りに戻るかを確かめます

運用手順書がないと何が起きるか

閉域ローカルLLMが止まる原因は、機材の故障よりも運用の空白です。典型的な経路は3つあります。

1つ目は更新停止です。構築時に外部業者が持ち込んだモデルと推論エンジンのまま、誰も更新しない状態が続きます。公表された脆弱性の多くには修正版がありますが、閉域ではその修正版を人が運ばない限り当たりません。『ローカルLLMは本当に安全か』で整理したとおり、放置された推論サーバーは「既知の脆弱性を抱えたまま社内に置かれたサーバー」になります。

2つ目は担当者交代です。構築を主導した担当者が異動や退職で抜けると、持ち込みの手順、管理者パスワードの所在、RAG索引の作り直し方が分からなくなります。手順書がないと、残った人は「触らない」を選び、システムは静かに塩漬けになります。

3つ目は障害時の判断不能です。応答が遅くなった、誤回答が増えた、ディスクが逼迫した、というときに一次切り分けの手順がないと、再起動を繰り返すか業者に電話するしかありません。閉域では外部からのリモート支援も制限されるため、社内で一次対応できる手順が要ります。

運用手順書は、この3つの空白を埋める文書です。分量は多くなくて構いません。「いつ・誰が・何を・どの手順で」が埋まっていれば、担当者が代わっても同じ品質で回ります。

運用カレンダーの全体表（日次・週次・月次・四半期・年次）

まず全体を1枚の表にします。各作業の詳細は後述の手順1〜6で説明します。所要時間は『導入したローカルLLM、誰が維持するのか』の工数目安（定常で月0.5〜1人日、更新で1回0.5〜2人日、脆弱性対応で1回0.5〜1人日）の範囲で置いています。

頻度	作業	担当	所要時間の目安	対応する手順
日次	死活確認（応答テスト1回）、アラートの確認、ディスク・GPUメモリの使用率確認	一次対応者	数分	手順5
週次	利用ログの確認（不適切な使われ方、失敗の連続）、ユーザーの追加・削除の反映	一次対応者	30分〜1時間	手順3
月次	脆弱性情報の確認、バックアップの成功確認、管理操作ログの点検、ログの保存期間超過分の削除	二次対応者	半日	手順2・3・4
四半期	モデル更新の検討と実施、推論エンジン・UIの定期更新、復旧訓練（簡易）、権限の棚卸し	二次対応者＋AI推進担当	1〜3人日	手順1・2・4・6
年次	復旧訓練（完全）、手順書の全面見直し、保守契約と撤退基準の再確認、ライセンスの再確認	情シス責任者	1〜2人日	手順4・6
随時	脆弱性公表時の臨時更新、障害対応、担当交代の引き継ぎ	一次・二次対応者	1回0.5〜数人日	手順2・5・6

一次対応者と二次対応者を分けるのは、兼務一人への丸投げを避けるためです。一次対応者は日次・週次の定型作業と障害の一次切り分けを担い、二次対応者は更新・復旧・権限棚卸しのような判断を伴う作業を担います。小規模な会社で二人を立てられない場合は、二次対応をベンダー保守に委ねる分担が現実的です（後述の分担表を参照）。

手順1. モデル更新（四半期に検討し、切り戻しを残して切り替える）

オープンモデルは3〜6ヶ月で世代交代が起きます。更新は義務ではありませんが、「更新するかどうかを四半期に一度判断する」ことを手順に固定しないと、判断の機会そのものが消えます。更新の6段階は次のとおりです。

段階	作業	成果物
1. 候補選定	現行モデルと同じ用途・同じサイズ帯で、新しい世代の候補を1〜2つ挙げる。ライセンス（商用可否、再配布条件）をこの時点で確認する	候補一覧（モデル名、配布元、ライセンス、ファイル形式）
2. オンライン側で取得とハッシュ照合	閉域と同じ環境を再現したオンライン側の作業端末で取得し、配布元の公開ハッシュ値と照合する	ハッシュ値の記録
3. 持ち込み台帳への記録	何を、いつ、誰が、どのハッシュ値で、どのライセンスのもとで持ち込むかを台帳に書く	持ち込み台帳の1行
4. 評価シートで旧モデルと比較	導入時に作った評価セットを新旧両方に通し、精度・速度の4軸で比較する。合否ラインを下回る軸が1つでもあれば更新しない	比較結果（新旧の数値と判定）
5. 切り替え	利用の少ない時間帯に切り替え、代表的な業務の入力で動作を確認する。利用者には変更日と変更点を事前に告知する	切り替え記録、告知文
6. 切り戻し準備	旧モデルのファイルと設定を最低1世代残し、「旧モデルに戻す手順」を手順書に書いておく。切り替え後2週間は旧モデルを消さない	切り戻し手順、保持世代の一覧

段階4の評価は省略しがちですが、ここを飛ばすと「新しいモデルにしたら特定の業務で精度が落ちた」という苦情が利用者側から出て、信頼を失います。評価セットと採点の手順は『ローカルLLM PoCの評価シート』で作ったものをそのまま使います。導入時に評価セットを作っていない場合は、更新の前に作ります。

持ち込みの物理的な手順（オンライン側で固める、ハッシュを再照合する、媒体を消去する）は『生成AIをオフラインで使う2026』の持ち込み手順と同じです。モデルだけでなく、埋め込みモデルを更新する場合はRAG索引の再作成が要るため、索引の再作成時間と切り替え中の検索停止を別途計画します。

手順2. 推論エンジン・UIの脆弱性対応（閉域に情報を届ける経路を決める）

閉域で最も見落とされるのが、脆弱性情報の入手経路です。オンラインのサーバーなら自動更新や通知で気づけますが、閉域のサーバーは何も教えてくれません。手順として決めるのは次の4点です。

• 情報源: 使っている推論エンジン（Ollama、vLLM、llama.cppなど）とチャットUI（Open WebUIなど）、OSについて、公式のリリース情報と脆弱性情報をどこで見るかを列挙します。確認はオンライン側の作業端末で行います
• 頻度と担当: 月次の定期確認を二次対応者が行い、重大な脆弱性が公表されたときは臨時で確認します。臨時の起点は「社内のセキュリティ担当からの連絡」または「月次確認で見つけた」のどちらかに限定し、個人の気づきに依存しないようにします
• 適用判断の基準: 「認証なしで到達できる経路から悪用できる」「閉域内の利用者が悪用できる」「情報の読み出しにつながる」のいずれかに該当すれば、次の月次を待たずに適用します。それ以外は四半期の定期更新に含めます
• 適用手順: 検証環境（または本番と同じ構成のコンテナイメージ）で修正版を当てて動作を確認し、本番に適用し、更新後に待ち受けアドレスと認証の設定が初期値に戻っていないことを再確認します

最後の再確認は重要です。推論エンジンやUIの更新で設定ファイルが上書きされ、待ち受けが全インターフェースに戻る、認証が無効になる、といった事故は実際に起きます。Ollamaの既定設定と公表済み脆弱性の実例は『ローカルLLMは本当に安全か』と『導入したローカルLLM、誰が維持するのか』に整理してあり、修正版の適用という運用を回していれば防げるものが大半です。vLLMを使う場合は、APIキー認証の保護範囲が一部のエンドポイントに限られることが公式ドキュメントに明記されているため、更新のたびにリバースプロキシ側の認証が生きていることも確認します。

確認項目	更新前	更新後
待ち受けアドレス	127.0.0.1または社内LANの特定IPに限定されている	同じ値のまま（0.0.0.0に戻っていない）
認証	リバースプロキシの認証が有効	認証なしで推論APIに到達できない
外部到達性	社外から到達できない	同じ
モデルと設定	現行モデル・設定を記録	同じモデル・設定で応答する
動作確認	代表的な入力3〜5件の出力を記録	同じ入力で同等の出力が返る

手順3. 監査ログの月次点検（残っているか、読める人が増えていないか）

ログの設計（記録項目・保存期間・閲覧者・匿名化）は『ローカルLLMは本当に安全か』の表で決めました。運用手順書に書くのは、その設計が守られているかを月次で確かめる手順です。

• 残っているか: 利用ログ、管理操作ログ、アクセスログ、文書の取り込み履歴が、設計どおりの項目で記録されているかを確認します。ディスク逼迫でログが止まっている、ログローテーションの設定が消えている、といった事故はここで見つけます
• 読める人が増えていないか: ログの閲覧権限を持つアカウントの一覧を出し、設計時に決めた閲覧者と一致するかを確認します。退職者のアカウントや、障害対応で一時的に付与した権限が残っていないかを見ます
• 保存期間を超えた分が消えているか: 利用ログとアクセスログは1年、管理操作ログは3年、入出力の本文を保存している場合は30〜90日という設計の目安に対して、超過分が削除されているかを確認します。消し忘れは、ログ自体が漏洩源になる経路です
• 異常がないか: 認証失敗の連続、深夜の大量利用、特定ユーザーによる文書の大量取り込みなど、週次の確認で拾い切れなかった傾向を月単位で見ます

月次点検の結果は、点検日・点検者・結果・対処を1行で記録します。監査で「ログを見ていたか」と問われたときの根拠になります。入出力の本文を原則残さない設計にしておくと、点検者が全社の入力内容を読める状態を避けられ、点検の心理的な負担も下がります。

手順4. バックアップと復旧（5点を世代管理し、年1回は実際に戻す）

バックアップの対象は5点です。モデルファイルだけを取っていても、設定とRAG索引がなければ復旧できません。

対象	内容	取得頻度	保持世代	復旧の優先度
モデルファイル	現行モデルと旧1世代、埋め込みモデル	更新時	2世代	高
設定	推論エンジン・UI・リバースプロキシの設定、環境変数、認証連携の設定	変更時と月次	3世代	最高（最初に戻す）
RAG索引と元文書の一覧	索引データ、取り込んだ文書の一覧と区分	週次	4世代	中（再作成もできる）
ログ	利用・管理操作・アクセス・取り込み履歴	日次	保存期間に準じる	中
ユーザーDB	UIのアカウント、グループ、権限	日次	7世代	高

保存先は、推論サーバーと同じ筐体に置かないことが最低条件です。閉域内の別のサーバーかNAS、または暗号化した外付け媒体に置き、媒体は施錠された場所に保管します。バックアップの暗号化鍵の所在は、手順6の引き継ぎ項目に含めます。

復旧訓練は、四半期に簡易版、年1回に完全版を行います。簡易版は「設定ファイルを別の場所に戻して差分がないことを確認する」程度で構いません。完全版は、空のサーバー（または検証用の環境）に5点を戻し、利用者と同じ経路でログインして、代表的な入力に応答するところまで確かめます。完全版の所要時間を記録しておくと、障害時に「何時間で戻るか」を経営層に答えられます。

復旧手順は、バックアップの手順とは別に書きます。「どの順番で戻すか（設定→モデル→ユーザーDB→RAG索引→ログ）」「戻した後に確認する項目」「戻らなかったときの連絡先」の3点があれば、担当者が代わっても実行できます。

手順5. 障害対応の一次切り分け（4つの症状で分岐する）

閉域では外部からのリモート支援に制約があるため、社内の一次対応者が最初の切り分けをできる手順が要ります。症状を4つに分け、それぞれ「最初に見るもの」と「一次対応者がやってよいこと」「二次対応者に渡す条件」を決めます。

症状	最初に見るもの	一次対応者がやってよいこと	二次対応者に渡す条件
応答がない	サービスの稼働状態、リバースプロキシの稼働、ディスク使用率	サービスの再起動（1回まで）、ディスクの一時ファイル削除	再起動で戻らない、GPUやメモリのエラーがログにある
応答が遅い	同時利用者数、GPUメモリ使用率、長文入力の有無	利用者への「混雑中」の告知、長文入力の分割依頼	利用者が少ないのに遅い、更新直後から遅い
誤回答が増えた	直近の変更（モデル更新、RAG文書の取り込み、プロンプトの変更）	直近に取り込んだ文書の確認、変更の記録を二次対応者に送る	モデル更新後なら切り戻し判断、取り込み文書が原因なら索引の修正
ディスクが逼迫	ログの肥大、古いモデルの残存、バックアップの一時ファイル	保存期間を超えたログの削除、保持世代を超えた旧モデルの削除	削除しても逼迫が続く、原因が特定できない

一次対応者の裁量を「再起動1回まで」「削除は保存期間・保持世代を超えた分だけ」のように数で区切っておくと、善意の対応が証拠の消失や設定の破壊につながるのを防げます。障害の記録は、発生日時・症状・一次対応・二次対応・原因・再発防止の6項目で残し、四半期の点検で振り返ります。

手順6. 担当交代と引き継ぎ（手順書・台帳・鍵・権限の4点）

担当交代は、運用が止まる最大の契機です。引き継ぎの対象を4点に固定し、交代の1か月前から着手します。

• 手順書: 本記事の手順1〜5に対応する社内版の手順書と、その最終更新日。更新されていない手順書は、引き継ぎ前に後任と一緒に1回実行して直します
• 台帳: 持ち込み台帳（モデル・パッケージ・ライセンス・ハッシュ値）、構成台帳（機材・OS・エンジン・UIのバージョン）、変更履歴、障害記録、月次点検の記録
• 鍵と所在: 管理者アカウントの所在、バックアップの暗号化鍵、リバースプロキシのTLS証明書と期限、物理媒体の保管場所と施錠の鍵。パスワードそのものは手順書に書かず、社内のパスワード管理の仕組みで引き継ぎます
• 権限の棚卸し: 前任者の管理者権限を交代日に無効化し、後任に付与する。障害対応で一時的に付与した権限が残っていないかも同時に確認する

引き継ぎの完了は、後任が「日次の死活確認」「バックアップからの設定復旧（簡易版）」「モデルの切り戻し」の3つを、前任者の立ち会いなしに実行できた時点とします。文書を渡しただけでは引き継ぎになりません。

内製・ベンダー保守・運用委託での分担表

手順1〜6を誰が持つかは、会社の体制で変わります。『導入したローカルLLM、誰が維持するのか』で整理した内製・ベンダー保守・マネージド寄せの3パターンに対応させると、次のようになります。

手順	内製（情シスあり）	ベンダー保守契約	運用委託・マネージド
1. モデル更新	二次対応者が実施、評価は業務担当者	ベンダーが持ち込みと切り替え、評価セットの採点は自社	ベンダーが実施、更新の可否判断だけ自社
2. 脆弱性対応	二次対応者が月次確認と適用	ベンダーが情報確認と適用、適用後の設定再確認は自社でも行う	ベンダーが実施、報告を受ける
3. 監査ログ点検	一次対応者が週次、二次対応者が月次	自社（ログの閲覧者を社外に広げない）	自社（同上）。ログの保全だけベンダー
4. バックアップと復旧	二次対応者が設計と訓練	ベンダーが取得と復旧、年次の完全訓練は立ち会い	ベンダーが実施、復旧時間の報告を受ける
5. 障害の一次切り分け	一次対応者	自社の一次対応者が切り分け、二次をベンダーに渡す	自社は症状の報告まで
6. 担当交代	自社	自社とベンダーの窓口の両方	ベンダー側の担当交代時に台帳と鍵の所在を再確認

分担表で見落とされやすいのは手順3です。ベンダー保守に出していても、ログの閲覧者を社外に広げると、ログ自体が漏洩経路になります。ログの点検は自社に残し、ベンダーには保全（消えないようにする）だけを委ねる形が原則です。保守契約の費用は、構築費の10〜15%／年、月額数万〜数十万円が目安で、契約範囲に手順1〜6のどれが含まれるかを契約書で明文化します。

運用手順書のテンプレート（目次と記載項目）

社内版の手順書は、次の目次で作ると本記事と対応します。各章に「最終更新日」と「最終実行日」を持たせ、四半期点検で両方を更新します。

章	記載項目
0. 構成と連絡先	機材・OS・推論エンジン・UI・リバースプロキシのバージョン、構成図、一次・二次対応者と保守ベンダーの連絡先、撤退基準
1. 運用カレンダー	日次〜年次の作業、担当、所要時間（本記事の全体表を自社の体制に合わせて書き直す）
2. モデル更新	6段階の手順、評価セットの所在、切り戻し手順、保持世代
3. 脆弱性対応	情報源の一覧、確認頻度と担当、適用判断の基準、検証→本番の手順、更新後の設定再確認表
4. 監査ログ	ログ設計表（記録項目・保存期間・閲覧者）、月次点検の手順と記録様式
5. バックアップと復旧	5点の対象と頻度・保持世代、保存先と鍵の所在、復旧の順番と確認項目、訓練の記録
6. 障害対応	4症状の切り分け表、一次対応者の裁量の範囲、障害記録の様式
7. 担当交代	引き継ぎ4点の一覧、完了条件
付録	持ち込み台帳、構成台帳、変更履歴、月次点検記録、障害記録

手順書は印刷しても使えるようにします。閉域の障害時には、手順書を置いたサーバー自体が止まっていることがあるためです。

四半期点検チェックリスト

四半期に一度、二次対応者と情シス責任者で次の項目を確認します。空欄が残る項目が、次の四半期の弱点です。

• モデル更新の判断: 現行モデルを続けるか更新するかを判断し、記録した
• 評価セット: 更新の有無にかかわらず、評価セットが現行の業務を反映しているかを確認した
• 脆弱性対応: 月次確認が3回とも実施され、適用すべき修正版が残っていない
• 設定の再確認: 待ち受けアドレス・認証・外部到達性が設計どおりである
• ログの点検: 月次点検が3回とも記録されており、閲覧者の一覧が設計と一致する
• ログの削除: 保存期間を超えたログが削除されている
• バックアップ: 5点すべてが取得され、保持世代が守られ、保存先が推論サーバーと分かれている
• 復旧訓練: 簡易版を実施し、所要時間を記録した（年次は完全版）
• 障害記録: 四半期中の障害を振り返り、再発防止が手順書に反映された
• 権限の棚卸し: 管理者権限とログ閲覧権限の保有者を確認し、不要な権限を無効化した
• 鍵と証明書: TLS証明書の期限、バックアップの暗号化鍵の所在を確認した
• 手順書: 各章の最終更新日と最終実行日を更新した
• 撤退基準: 撤退基準に照らして継続の判断をした

まとめ

• 閉域ローカルLLMは、構築した日が最も安全で、運用の空白の分だけ弱くなります。更新停止・担当者交代・障害時の判断不能の3つが、止まる典型的な経路です
• 運用は日次の死活確認と週次のログ確認を土台に、月次の脆弱性確認とバックアップ確認、四半期のモデル更新・定期更新・復旧訓練・権限棚卸しを回す形にすると、平常月1〜2人日の範囲に収まります
• モデル更新は6段階で、評価シートによる新旧比較と、旧モデルを1世代残す切り戻し準備を省きません。脆弱性対応は情報源・頻度・担当・適用基準を固定し、更新後に待ち受けと認証の設定を再確認します
• 監査ログは「残っているか」「読める人が増えていないか」「超過分が消えているか」を月次で点検し、入出力の本文は原則残しません。バックアップは5点を世代管理し、年1回は実際に復旧します
• 手順1〜6を内製・ベンダー保守・運用委託のどこが持つかを分担表で決め、ログの点検だけは自社に残します。担当交代は手順書・台帳・鍵・権限の4点を引き継ぎ、後任が3つの作業を一人で実行できた時点で完了とします

よくある質問

Q. 閉域のローカルLLMは、どのくらいの頻度で更新すればよいですか？

推論エンジンとチャットUIは四半期の定期更新を基本にし、重大な脆弱性が公表されたときは臨時で適用します。モデルは3〜6ヶ月で世代交代が起きるため、四半期に一度「更新するかどうか」を判断します。更新は義務ではありませんが、判断の機会を固定しないと、判断そのものが消えて塩漬けになります。判断の根拠は、導入時に作った評価セットで新旧を比較した結果です。

Q. インターネットにつながないのに、脆弱性情報はどう入手するのですか？

オンライン側の作業端末で、使っている推論エンジン・UI・OSの公式リリース情報と脆弱性情報を月次で確認します。確認する情報源の一覧と担当者を手順書に書き、個人の気づきに依存しない形にします。修正版は、モデルと同じ持ち込み手順（オンライン側で取得、ハッシュ照合、持ち込み台帳への記録）で閉域内に運び、検証環境で当ててから本番に適用します。

Q. モデルを更新したら精度が落ちました。どうすればよいですか？

旧モデルに切り戻します。そのために、切り替え後も旧モデルのファイルと設定を最低1世代、2週間は残しておきます。切り戻した後、評価セットで新旧を比較し直し、どの業務のどの入力で落ちたかを特定します。更新前に評価セットで比較していれば防げる事態なので、次回からは評価を省かない手順にします。

Q. 監査ログには何をどれだけ残せばよいですか？

利用ログ（利用者ID、日時、モデル、入出力の文字数、参照した文書ID）とアクセスログは1年、管理操作ログは3年が目安です。入出力の本文は原則残さず、残す必要がある業務だけ30〜90日の期間を決めて分離します。設計は『ローカルLLMは本当に安全か』の表を使い、運用では月次に「残っているか」「閲覧者が増えていないか」「超過分が消えているか」を点検します。

Q. バックアップは何を取ればよいですか？

モデルファイル、設定、RAG索引と元文書の一覧、ログ、ユーザーDBの5点です。モデルだけを取っていても、設定とRAG索引がなければ復旧できません。保存先は推論サーバーと同じ筐体に置かず、閉域内の別サーバーか暗号化した外付け媒体にします。四半期に簡易版、年1回に完全版の復旧訓練を行い、復旧にかかる時間を記録しておきます。

Q. 情シスが一人しかいません。運用を回せますか？

一次対応（日次・週次の定型作業と障害の一次切り分け）を社内の一人が担い、二次対応（更新・復旧・権限棚卸し）をベンダー保守契約に委ねる分担なら回せます。ただしログの点検は社外に広げず自社に残します。保守契約の範囲に手順1〜6のどれが含まれるかを契約書で明文化し、担当者が休んだ日や辞めた月にシステムが止まらない形にします。構築前に運用体制を決める考え方は『導入したローカルLLM、誰が維持するのか』で扱っています。

主な参考資料: OWASP Top 10 for LLM Applications、vLLM公式ドキュメント「API Key Authentication Limitations」、SentinelLABS・Censys「Silent Brothers」、Wiz「Probllama（CVE-2024-37032）」

TodoONadaでは、閉域ローカルLLMの構成設計から、本記事の手順1〜6を自社の体制に合わせた運用手順書に落とす作業、ベンダー保守としての二次対応までを支援しています。構築前に「置けるか」と「誰が回すか」を確かめる入口として、DGX SparkやMacを貴社オフィスに設置して2週間で判定する社内設置の実現性検証（30万円〜・税別・機材貸出料込み）を用意しています。「今の運用で何が抜けているか」の点検だけのご相談も歓迎します。

---

この記事に関連するサービス

TodoONada株式会社では、機密データを外部に出さないローカルLLMの導入支援を行っています。

• ローカルLLM導入支援 — GPUサーバーでの本格構成。モデル選定からRAG構築・運用まで
• Macで始める社内専用AI導入支援 — Mac 1台から始める社内専用AI。PoCから部門導入まで対応
• ローカルLLM 社内設置の実現性検証（機材貸出） — 機材を買う前に、DGX SparkやMacを貴社オフィスに2週間設置して「置けるか」を判定。機材のみの短期貸出も対応

導入・開発のご相談はお問い合わせからお気軽にどうぞ。検討段階のご相談も歓迎です。