物理エアギャップのKubernetesでLLMを動かすと決めた後に残るのは、「モデル重み・コンテナ・RAG資材を、誰が、どの媒体で持ち込み、何を検証して本番へ昇格させるか」という変更管理の問いです。この記事は、更新作業そのものの段取りではなく、搬入物の来歴（どこから来た何物か）をどう証明し、承認ゲートをどこに置き、問題時にどこまで戻すかという設計判断を、RFPに書ける粒度で整理します。
完全閉域のLLM基盤で行き詰まるのは、「どうやって運ぶか」ではなく「運んできたものを本番に上げてよいと、誰がどの根拠で言うか」の部分に論点が移ると考えられます。外部接続がない環境では、レジストリの署名検証も、脆弱性データベースの参照も、ライセンス条項の再確認も、すべて誰かが事前に持ち込んだ材料の上でしか行えません。搬入経路が決まっていても、搬入物の素性を確かめる手続きが決まっていなければ、保守窓のたびに判断がその場の合議になります。
本記事は、閉域ネットワークのAIモデルはどう更新するのかで扱っている「持ち込みメディアで運び、検証機で確かめ、旧版に戻せるようにする」という運用手順の全体像を前提として、その上に重ねる変更管理とセキュリティガバナンスの設計だけを扱います。手順の流れ自体を知りたい場合は先に上記の記事をご覧ください。ここでは、署名とSBOMによる来歴検証、承認ゲートの置き方、段階昇格と切戻しの境界という、手続きを監査可能にするための論点に絞ります。
閉域化の議論は「推論時にデータが外へ出ないこと」に集まりがちですが、運用が始まると負荷がかかるのは別の場所です。基盤コンテナに脆弱性修正が出ても、年に数回の保守窓まで適用できない。新しい埋め込みモデルを試したくても、索引の作り直しまで含めた搬入計画がない。結果として、未修正の状態が続く日数と、モデル世代の遅れが同時に積み上がっていきます。
Nsight VIEW（当社の応用仮説）：閉域化の成否は、推論時の通信遮断そのものより、更新物の来歴と切戻しを「日常運用」にできるかで決まると考えています。モデルは交換可能な部品として扱い、会社側に残すべき資産は知識索引・評価セット・判断ログの側に置く。この整理ができていると、モデル世代が変わっても運用設計を作り直さずに済む可能性が高まると考えられます。ただしこれは当社の設計方針であり、個別の環境での妥当性は検証が前提です。
搬入設計をRFPや運用規程に落とすとき、決めるべき項目は「搬入単位」「来歴検証」「承認ゲート」「昇格段階」「切戻し境界」の五つに整理できると考えます。それぞれが決まっていないと何が起きるかを並べると、優先順位が見えやすくなります。
| 論点 | 決める内容 | 決めていない場合に起きうること |
|---|---|---|
| 搬入単位 | モデル重み／推論コンテナ／埋め込みモデル／RAG原文・索引／評価セットを、それぞれ別版として管理し、検証済みの組み合わせを記録する | 埋め込みモデルだけ更新して既存索引と整合しなくなる、どの組み合わせが本番構成か追えなくなる |
| 来歴検証 | ハッシュ・署名・SBOMの提出を必須にし、検証鍵の配布経路を媒体とは分ける | 「ベンダーからもらったファイル」以上の根拠がないまま本番へ入り、監査で説明できない |
| 承認ゲート | 検疫通過・検証合格・本番昇格のそれぞれに、承認者と記録様式を割り当てる | 保守窓の当日に判断者が不在で止まる、もしくは誰の承認もないまま反映される |
| 昇格段階 | ステージング → 検証クラスタ → 本番の段数と、各段の合格条件 | 検証環境を飛ばした反映が常態化し、失敗が業務停止に直結する |
| 切戻し境界 | どこまで戻すか（コンテナのみ／モデル込み／索引込み）と、旧版の保持世代・起動確認の頻度 | 戻したつもりが索引だけ新版のままで、整合しない状態が残る |
モデル重み、推論コンテナ、埋め込みモデル、RAGの原文と索引、評価セット。これらは更新の理由も頻度も一致しません。脆弱性修正はコンテナ側の都合で来ますし、知識の追加はRAG側の都合で来ます。ひとまとめの「システム更新」として扱うと、コンテナの小さな修正のために全体の再検証が要る設計になってしまいます。別版で管理し、検証済みの組み合わせだけを一覧にする形のほうが、保守窓あたりの作業量を抑えられると考えられます。
FACT（一次情報）：NVIDIAは、エアギャップ環境での推論マイクロサービス導入について、インターネット接続のある環境であらかじめ資産（コンテナイメージやモデル）を取得・準備し、隔離環境ではその事前配置済み資産をAPIキーなしで実行する、という二段階の手順を示しています（NVIDIA NIM for LLMs — Air-Gap Deployment）。
FACT（一次情報）：Microsoftは、Azure Local の disconnected operations において、更新をオフラインでの適用、あるいは段階的なワークフローとして実施する方式を案内しています（Microsoft Learn — Disconnected operations for Azure Local）。いずれも2026-09-21時点で確認した内容であり、製品バージョンにより手順は変わり得ます。
この二つに共通するのは、「隔離側で何かを取りに行く」設計を最初から諦め、接続側での準備工程を正式な作業として切り出している点だと読めます。Nsightとしては、この二段構成を製品固有の制約ではなく、閉域AI基盤に共通する設計パターンとして扱うのが妥当だと考えています。ベンダー製品を使わない自前構成でも、接続側に「資産準備環境」を正式に持つかどうかで、保守窓の再現性が変わってくると考えられます。
接続側で作る成果物は、単体のファイル群ではなく、素性を自分で語れるバンドルにしておくと隔離側の検証が機械的になります。構成の一例を示します。
ここで意図的に「入れないもの」も決めておく必要があります。APIキー、接続側の認証情報、社内の秘密情報を含む設定ファイルは同梱しない。搬入バンドルは検疫端末や複数の担当者の手を経る前提の物体であり、そこに秘密情報を載せると、経路上のすべての場所が秘密情報の管理対象になってしまうためです。
署名を付けても、検証に使う鍵が同じ媒体に入っていれば、来歴の証明としては弱くなります。検証鍵（公開鍵）は、搬入媒体とは別の経路——たとえば基盤構築時の初期設定や、別の承認手続きを経た配布——で隔離側の鍵ストアに登録しておき、その鍵の更新自体を管理対象の変更として扱う形が考えられます。鍵の有効期限と更新手順を決めていないと、数年後の保守窓で検証が通らなくなる可能性があります。
媒体規程で可搬記憶媒体の持込が禁止されている工場では、搬入経路そのものが最初の設計対象になります。選択肢として考えられるのは、規程で認められた管理媒体を保守窓に限って例外承認のうえで使う方式、検疫専用端末を介した管理下の受け渡しにする方式、データダイオード等の片方向転送装置を正式な経路として設ける方式などです。どれを選ぶかは技術的な優劣というより、自社の媒体規程・輸出管理・監査要件の側で決まる事柄だと考えられます。
どの方式を採る場合でも、移送の事実を後から追える記録は必要になると考えます。記録項目としては、媒体の識別番号、払出と返却の日時、取扱者、搬入バンドルの版番号とハッシュ、マルウェア検査の実施結果、検疫端末での処理結果、といったものが挙げられます。重要なのは項目数より、搬入バンドルのハッシュが台帳と隔離側の記録の両方に現れ、突合できることだと考えられます。
保守窓では、障害調査のためにログを持ち出したいという要望が同時に出てきます。ここで同じ媒体・同じ手続きで双方向のやり取りを許すと、閉域の統制が更新のたびに緩む方向に働きます。持ち出しは別の申請・別の承認・別の媒体として分離し、持ち出す対象の範囲（業務データを含むか、含む場合の匿名化やマスキングの要否）を先に確定しておく設計が扱いやすいと考えます。持ち出し対象に業務データや個人情報が含まれるかどうかの判断は、人が確定する領域です。
防衛関連を含む領域では、モデル重みやソフトウェアの移動そのものが輸出管理上の検討対象になりうる場合があります。また、モデルや学習データのライセンス条項が、社内利用の範囲・再配布・派生物の扱いについて条件を課していることもあります。これらは署名検証やSBOM照合では判定できず、条項の解釈という人間の判断が要る領域です。搬入設計の手順書には、技術検証の前段に「輸出管理・ライセンス条項の確認者」を置いておくことをおすすめします。
隔離側に入った搬入バンドルは、いきなり検証クラスタへ載せるのではなく、検証ゲートを一段挟む設計が考えられます。ゲートの役割は「このバンドルを、私設レジストリとモデルストアに登録してよいか」を機械的に判定することです。判定を人の目視に頼ると、保守窓の時間圧力の中で省略されやすくなります。
| 確認項目 | 確認する内容 | 不合格時の扱い |
|---|---|---|
| 完全性 | CHECKSUMS.txt と実ファイルのハッシュが一致するか | 媒体劣化や転送失敗の可能性。再搬入とし、当日の投入は行わない |
| 真正性 | 事前登録済みの検証鍵で署名を検証できるか、署名主体が想定した組織か | 登録を止め、来歴を調達・ベンダー窓口へ差し戻す |
| 構成の把握 | SBOM に記載の構成部品と、実際のイメージ内容が整合するか | 差異の理由が説明できるまで保留とする |
| 既知脆弱性 | 隔離側に持ち込んだ脆弱性情報と SBOM を突合し、未対応項目を一覧化 | 重大度と業務影響を踏まえ、昇格の可否を承認者が判断 |
| マルウェア検査 | 検疫端末と隔離側の双方で検査を実施し、結果を記録 | 検出時は媒体ごと隔離し、インシデント手順へ引き継ぐ |
| 秘密情報の非同梱 | 認証情報や接続側の設定が混入していないか | 混入が判明した場合は該当資格情報の失効手続きへ |
SBOMを持ち込んでも、照合先となる脆弱性情報が隔離側で古いままでは、判定の価値が下がります。見落とされやすいのは、この照合用データベースを誰が、どの頻度で、どの経路で更新するかという点です。搬入バンドルの一部として脆弱性情報の版も同送し、その版番号を判定結果と一緒に記録しておくと、「いつ時点の情報で判定したか」が後から説明できるようになると考えられます。
検証ゲートを通ったバンドルは、まず本番とは分離したステージングのレジストリ／モデルストアへ登録し、そこから検証クラスタが参照する構成が考えられます。本番のレジストリに直接登録してしまうと、検証中のイメージを本番ノードが誤って取得しうる経路が残ります。レジストリの分離は、運用ミスの経路を物理的に減らす意味を持ちうると考えます。
段階昇格は「段数を増やせば手厚い」というものではなく、保守窓の時間と検証に割ける人員から逆算して決める事柄だと考えます。物理エアギャップのKubernetes環境では、ステージング（登録と起動確認）、検証クラスタ（評価セットによる回帰確認）、本番（限定範囲での稼働確認を経た全面反映）という三段が、保守窓に収まる現実的な構成として検討しやすいと考えられます。前掲のとおり、更新を段階的なワークフローとして扱う方式は製品側の案内にも見られます。
「動いたから次へ」ではなく、段ごとに合格条件を文章にしておくと、判断が当日の空気に左右されにくくなります。ステージングなら署名検証と起動確認、検証クラスタなら評価セットでの回帰結果と応答時間、本番なら限定範囲での一定時間の稼働と業務オーナーの確認、といった具合です。評価セットは自社の重要な対象を代表するものを事前に固めておく必要があり、これは搬入設計とは別に準備が要る部分です。
切り戻しで最も曖昧になりやすいのが、どこまで戻すかです。推論コンテナだけ戻すのか、モデル重みも戻すのか、RAGの索引まで戻すのか。埋め込みモデルを更新して索引を作り直した後に、モデルだけ旧版へ戻すと、索引と整合しない構成が残る可能性があります。切戻しは単体の操作ではなく「検証済みの組み合わせへ戻す」操作として定義し、戻し先の組み合わせを昇格時点で記録しておく設計が考えられます。
旧版のイメージと重みを保管していても、実際に起動できる状態かどうかは別問題です。ノード構成やドライバ、鍵の有効期限が変われば、旧版が起動しない可能性があります。保持世代数そのものより、旧版の起動確認を定期的に行い、戻せる状態を維持していることを記録に残すほうが実務上の意味が大きいと考えられます。切戻しの所要時間も、実演して測るまでは見積もりに留まります。
更新前後で挙動が変わること自体への備えは、モデルのバージョン移行でも別の角度から整理しています。
搬入設計をRFPに落とす段階で詰まりやすいのが、承認者の定義です。技術的な検証結果は自動化できても、「この結果をもって本番へ上げてよい」と決める行為は人に残ります。承認の型としては、搬入の実施に対する二者承認（実施者と立会者）、検証結果に対する検証担当の合否署名、業務影響に対する業務オーナーの回帰評価確認、という三種類を分けて設計する形が考えられます。
監査ログを隔離側のクラスタ内だけに置くと、その環境の障害や不正操作の影響を受けうる位置に証跡が置かれることになります。保守窓の終了時に、証跡一式を改ざん検知が可能な形で外部の保管先へ写す手続きを、更新作業の最終ステップとして定義しておく方法が考えられます。どこまで外に出せるかは媒体規程と情報区分によって変わるため、ここも規程側との擦り合わせが前提になります。
本記事で扱った工程のうち、以下は自動化の対象外として手順書に明記しておくことをおすすめします。ツールは材料を揃えられますが、決裁の主体にはなりません。
社内とベンダー保守の分担をどう引くかについては、情シス専任なしのオンプレAI運用で日常運用側の観点から整理しています。
搬入設計をベンダー選定に反映するなら、成果物ごとの提供条件を要件として書き下すのが実務的だと考えます。具体的には、署名の有無と署名主体、SBOMの提供形式、検証鍵の配布経路、オフライン導入手順の提供範囲、旧版の提供期間と入手方法、切り戻し手順の文書化、といった項目です。あわせて、搬入・検疫・承認・昇格・切戻しのそれぞれを自社とベンダーのどちらが担うかを表で確定させると、保守窓での役割が曖昧になりにくくなります。
搬入設計の妥当性は、新版が動くことでは確かめられません。旧版から新版へ昇格し、そこから旧版へ戻すところまでを一連で実演し、次の四点を測ることをおすすめします。
投資判断の比較軸としては、GPUや基盤の購入費だけでなく、更新1回あたりの工数、停止時間、再検証にかかる時間、そして未修正の脆弱性が残る日数を、現状の運用と並べて見る方法が考えられます。搬入設計に手間をかけることで1回あたりの工数が増える一方、保守窓ごとの判断コストと差し戻しが減る可能性があり、どちらが大きいかは自社の更新頻度に依存します。数値は自社の実績値で埋める必要があり、一般的な削減率を当てはめられる性質のものではないと考えます。
技術的な難所というより、設計時に決め落としやすい箇所として、次のような点が挙げられます。
最初に手を付けやすいのは、現在の構成に含まれる成果物の棚卸しだと考えます。いま本番で動いているモデル重み、推論コンテナ、埋め込みモデル、RAGの索引について、それぞれの版番号と入手経路を書き出す。ここで「どこから来たか分からない成果物」が見つかることが、搬入設計を始める実際の出発点になりうると考えられます。
次に、次回の保守窓を想定して、責任分界表の下書きを作ります。搬入・検疫・検証・承認・昇格・切戻しの六工程に対して、自社の誰とベンダーの誰が担うかを埋める。埋まらない欄が、決めるべき論点として残ります。ここまでを紙一枚にできれば、RFPの要件欄に落とす材料は揃ってくると考えます。
そのうえで、署名検証とSBOM突合をどこまで機械的に行うか、証跡をどこへ保全するかを設計します。閉域という制約の中では、どの方式が自社の媒体規程と監査要件に収まるかを、現物と現場を見ながら確かめる必要があります。工場データ基盤のように社内で完結するデータとAIの土台を前提に、運用設計まで含めて伴走する導入コンサルティングという進め方もあります。
Nsightは、閉域で動くAIを「導入して終わり」ではなく「更新しながら動かし続ける」対象として捉え、搬入・検証・切戻しの責任分界から設計することを重視しています。モデルは交換可能な部品として扱い、評価セットと判断ログを会社側に残す——この方針が自社の実態に合うかどうかは、現行運用の棚卸しから確かめていくのが現実的だと考えています。
設計次第で閉域内でも実施しうると考えられます。署名検証は検証鍵（公開鍵）が隔離側にあれば成立するため、鍵は搬入媒体と同送せず、別経路で事前配布して隔離側の鍵ストアに登録しておく設計が前提になります。SBOMも成果物に同梱して搬入すれば、隔離側で構成部品の突合や既知脆弱性の照合が可能です。ただし脆弱性情報そのものは日々更新されるため、照合用データベースを何日おきに、どの経路で更新するかを別途決めておく必要があると考えます。
媒体規程で可搬記憶媒体が禁止されている場合、選択肢としては、規程で認められた管理媒体を保守窓に限って例外承認で使う、検疫専用端末を介した管理下の受け渡しにする、データダイオード等の片方向転送装置を経路として正式に設ける、といった形が考えられます。どれを選ぶかは自社の媒体規程・輸出管理・監査要件によって変わり、技術的な可否よりも規程側の解釈が先に来ます。規程の解釈と例外承認は人が確定する領域であり、AIやベンダー手順が代替できる部分ではないと考えます。
個別に版を持たせたうえで、搬入単位としての組み合わせを別途記録する形が扱いやすいと考えます。モデル重み、推論コンテナ、埋め込みモデル、RAGの原文と索引、評価セットは、更新の理由も頻度も一致しないためです。ただし埋め込みモデルを更新すると既存の索引と整合しなくなる場合があるため、どの組み合わせが検証済みかを一覧で持ち、本番に上げてよい組み合わせを明示しておくことが有効だと考えられます。
一律の正解はなく、保守窓の間隔と保管容量から逆算して自社で決める事柄だと考えます。考え方としては、直前の安定版に加えて、監査や原因調査で参照する可能性のある期間分を残す、という二層で決める方法があります。重要なのは世代数そのものより、旧版が「置いてある」ではなく「起動確認済みで戻せる状態にある」ことを定期的に確かめる運用にしておくことだと考えられます。切り戻しの所要時間は、実演して測るまで見積もりに留まります。
成果物ごとに、署名の有無と署名主体、SBOMの提供形式、検証鍵の配布経路、オフライン導入手順の提供範囲、切り戻し手順と旧版の提供期間を明記させる形が考えられます。あわせて、搬入作業・検疫・承認・本番昇格・切り戻し判断のそれぞれを自社とベンダーのどちらが担うかを表で確定させると、保守窓での役割が曖昧になりにくくなります。契約上の責任範囲の解釈は法務と調達が確定する領域です。
満たせるとは限らないと考えます。ベンダーが公開するオフライン導入手順は、あくまで製品を隔離環境で動かすための技術手順であり、自社の媒体持込規程、輸出管理上の取り扱い、モデルやデータセットのライセンス条件までを保証するものではないためです。技術手順を土台に、自社規程側の要求を重ねた手順書へ書き換える作業が別途必要になると考えられます。この重ね合わせの可否判断は、情報システム・法務・輸出管理の担当者が確定する領域です。
現在のネットワーク区分、更新頻度、持込媒体規程を共有いただければ、搬入・検証・切戻しの責任分界表から設計します。まずは現行構成の棚卸しと、次回保守窓の想定を見せていただくところから始めませんか。
閉域LLMの搬入設計について相談する