最近、企業システムの現場で「ローカルLLM（大規模言語モデル）」を自社サーバーで稼働させたいというニーズが急増しています。クラウドAPIにデータを送りたくない、コストを固定化したい、といった理由からですが、ここで多くのCTOやプロジェクトマネージャーが見落としている重大なリスクがあります。
それは、「LLMがサーバーのリソースを食いつぶし、他の重要業務システムまで道連れにダウンさせる」というシナリオです。
もし、提供するAIサービスが、リソース枯渇によって顧客の業務を止めてしまったら、それが「想定外の事故」として済まされるでしょうか。
この問題はもはや技術論だけでは語れません。本記事では、Dockerのコンテナ制限機能（cgroupsなど）を、単なるエンジニアリングのツールとしてではなく、企業の法的責任（善管注意義務）を果たし、SLA（サービスレベル合意）を守るための「経営的な防波堤」として再定義して解説します。
なお、本記事は技術的な観点からリスク管理を論じるものであり、法的な助言そのものではありません。具体的な契約実務については、必ず法務担当者や弁護士と相談してください。
1. 予見可能な「AI起因のシステムダウン」と法的責任の境界線
AIシステム、特にLLM（大規模言語モデル）は、推論処理が実行された瞬間にメモリ消費量が急激にスパイクする特性を持っています。これはシステム設計において前提とすべき事実です。
ローカルLLMのリソース枯渇リスクと業務妨害
一般的なWebアプリケーションと異なり、LLMの推論プロセスは入力されるプロンプトの長さや内容によって、計算量とメモリ使用量が大きく変動します。
例えば、Llamaシリーズの70Bクラスのような大規模モデルや、最新のLlamaの最新モデルのように膨大なコンテキスト（数百万トークン規模）を処理可能なモデルを動かす場合を想像してください。いくら量子化技術でモデルサイズを軽量化していても、複雑な推論時には数十GBのVRAMやシステムメモリを一瞬で占有する可能性があります。最近ではLlamaモデルのような軽量なSLM（小規模言語モデル）も登場していますが、業務で高精度な回答を求める場合、依然としてリソース集約的なモデルが必要となるケースは少なくありません。
もし、このAIコンテナがデータベースや基幹システムと同じ物理サーバー上で、何のリソース制限もなく稼働していたらどうなるでしょうか。
AIへのリクエストが集中した瞬間、サーバー全体のメモリが枯渇し、OSがフリーズするか、重要なプロセスが強制終了（OOM Kill）させられます。結果として、AIとは無関係な受発注システムやメールサーバーまで停止してしまいます。
これは単なるバグではなく、構造的な欠陥による重大な障害と言えます。
システム運用における『善管注意義務』の再定義
ここで法的なキーワード「善管注意義務（善良なる管理者の注意義務）」が登場します。委任契約や準委任契約において、受託者は専門家として通常期待されるレベルの注意を払って業務を行う義務があります。
LLMのリソース変動が激しいことは、技術的に広く知られています。つまり、「リソース枯渇によるシステムダウン」は予見可能な事象なのです。
予見可能であるにもかかわらず、適切な隔離措置（Dockerによるリソース制限など）を講じずにシステムをダウンさせた場合、それは「不可抗力」ではなく「過失」、つまり善管注意義務違反とみなされるリスクが高まります。
『技術的限界』は免責事由になり得るか？
「AIは最新技術だから不安定なのは仕方ない」という言い訳は、B2Bの商用サービスでは通用しにくくなっています。
もちろん、AIの回答精度（ハルシネーションなど）については免責されることが多いですが、システムの可用性（動いているかどうか）については、従来のITシステムと同様の堅牢性が求められます。
技術的な限界を理由に免責を主張するためには、「当時の技術水準で可能な限りの回避措置を講じていたこと」を証明しなければなりません。その「回避措置」の筆頭が、これから解説するDockerによるコンテナ制限です。
2. 技術的防波堤としてのDockerコンテナ制限機能
Dockerには、コンテナが使用できるCPUやメモリの上限を設定する機能が標準で備わっています。これをエンジニアは「パフォーマンスチューニング」のために使いがちですが、経営視点では「リスクの封じ込め（Containment）」として捉えるべきです。
cgroupsによるリソース隔離の法的な意味合い
Dockerの実体は、Linuxカーネルの機能であるcgroups（control groups）とnamespacesを用いたプロセスの隔離です。特に最新のLinuxディストリビューションで標準化が進むcgroups v2では、メモリやCPUだけでなく、I/Oリソースの制御もより厳格に行えるようになっています。
法的なアナロジーで言えば、これは「防火壁（ファイアウォール）」です。ある部屋（コンテナ）で火事（リソース暴走）が起きても、隣の部屋や建物全体（ホストOSや他システム）には延焼させないという構造的な保証です。
例えば、docker-compose.ymlで以下のように設定することは、技術的な設定であると同時に、「システム全体を守る意思表示」でもあります。
services:
llm-engine:
image: my-local-llm:latest
deploy:
resources:
limits:
cpus: '4.0' # CPUを4コア分に制限
memory: 16G # メモリ上限を16GBに制限
reservations:
memory: 8G # 最低8GBは確保（枯渇防止）
この設定があれば、仮にLLMが暴走して32GBのメモリを要求しても、16GBの時点でDockerが強制的にそのコンテナだけを停止（OOM Kill）またはスロットリングします。ホストOSは守られ、他のサービスは稼働し続けます。
OOM Killer発動時の挙動とデータ保全義務
メモリ制限を超えた場合、LinuxカーネルのOOM Killer（Out Of Memory Killer）が発動し、プロセスを強制終了させます。
ここで重要なのは、「どのプロセスが終了させられるか」をコントロールすることです。Dockerの--oom-kill-disableフラグや--oom-score-adj設定を適切に行うことで、「データベースのような重要プロセスは絶対に守り、AIの推論プロセスは最悪の場合犠牲にする」という優先順位付けが可能です。
これは、「データ保全義務」を果たすための技術的な実装と言えます。AIの回答生成が一度失敗するのと、顧客のトランザクションデータが破損・消失するのとでは、損害の性質が全く異なります。システムがクラッシュする際も、被害を最小限に抑えるように設計する（Fail Safe）のがシステム設計者の責務です。
CPUシェア設定による『公平な利用』の担保
メモリだけでなく、CPUリソースの奪い合いも問題になります。AIがCPUを100%占有してしまうと、SSHでのログインすらできなくなり、管理者が復旧作業を行えなくなる可能性があります。
Dockerの--cpu-shares（相対的な重み付け）や--cpuset-cpus（使用するコアの固定）を設定することで、管理用プロセスや他の重要サービスのためのCPU時間を確保できます。
これは、SLAにおける「管理アクセスの可用性」を担保する措置となります。どんなに高負荷な状況でも、管理者がシステムに入って制御できる状態を維持することは、運用上の安全配慮義務の一部と言えるでしょう。
負荷分散アーキテクチャとSLAの整合性を考える
技術的にリソース制限をかけても、アクセスが集中すれば「サービスが応答しない」状態にはなります。ここで重要になるのが、技術的なアーキテクチャと、顧客と結ぶSLA（契約）の整合性です。
レプリカ数とスループット制限の契約的根拠
Docker SwarmやKubernetesを使えば、LLMのコンテナを複数並列（レプリカ）で動かし、ロードバランサーで負荷分散できます。
しかし、ハードウェアリソース（特にGPU）には物理的な限界があります。無限にスケールできるわけではありません。
契約書やSLAには、この「物理的な上限」を明記する必要があります。例えば、「同時リクエスト数 ○件までは秒間○トークンの生成速度を目標とする」といった規定です。
技術的には、プロキシサーバー（NginxやEnvoy）やAPIゲートウェイでレートリミット（Rate Limiting）を設定し、契約上限を超えたリクエストには即座に429 Too Many Requestsを返す設計にします。
これは「サービス拒否」ではなく、「合意されたサービスレベルを維持するための防衛措置」です。これを実装せずにリクエストを受け続け、全ユーザーの応答速度が低下することこそが、SLA違反のリスクを高めます。
『ベストエフォート』を具体化するKubernetes/Swarm設定
多くのAIサービスは「ベストエフォート（最大限努力するが保証はしない）」という条項を入れたがります。しかし、単に「ベストエフォートです」と書くだけでは、紛争時に脆弱になります。
技術的に「ベストエフォート」を表現するには、KubernetesのQoS（Quality of Service）クラスの概念が役立ちます。
- Guaranteed: リソースを完全に確保・保証する（データベースなど）
- Burstable: 基本量は確保するが、余裕があれば上限まで使える（一般的なWebサーバー）
- BestEffort: リソースが余っている時だけ使える（優先度の低いバッチ処理や実験的なAIタスク）
SLAにおいて「AI機能はシステムリソースの余剰範囲内で提供される」と定義し、実際にKubernetes上でBestEffortクラスとしてデプロイしていれば、パフォーマンス低下に対する免責の論拠となります。
また、Kubernetesのエコシステムは進化が速く、APIの廃止や仕様変更が頻繁に行われます。最新の安定版（Stableチャネル）を使用し続けることはセキュリティ上必須ですが、アップデート作業に伴う計画停止や仕様変更リスクも「ベストエフォート」の範囲に含めるか、SLA上のメンテナンス窓口として定義しておく必要があります。
法的リスクを最小化する免責条項の書き方と技術的裏付け
法務担当者と連携し、以下のような条項を検討する際の技術的裏付けを提供しましょう。
- 条項例: 「当社は、本AIサービスの利用が急激に増大し、当社の定めるシステムリソースの上限を超えた場合、一時的に利用を制限または停止することがあります。」
- 技術的裏付け: Kubernetesの
ResourceQuota設定、またはロードバランサーのlimit_req設定値。
技術設定値（Config）と契約条項（Contract）が乖離していると、そこが訴訟リスクの火種になります。実務においては、必ずdocker-compose.ymlやKubernetesマニフェストの設定値と利用規約の免責事項を並べてレビューすることが推奨されます。
4. インシデント発生時の説明責任を果たす運用体制
万が一、システム障害が発生し、顧客から損害賠償を請求されるような事態になった場合、企業はどう身を守ればよいでしょうか？ 鍵となるのは「説明責任（Accountability）」と「証跡（Audit Trail）」です。
設定ファイル（IaC）による『適切な措置』の立証
「適切に管理していた」と口で言うだけでは不十分です。客観的な証拠が必要です。
ここでInfrastructure as Code (IaC)が強力な武器になります。Docker ComposeファイルやKubernetesのマニフェストファイルをGitなどのバージョン管理システムで管理していれば、「障害発生時の設定はどうなっていたか」「いつ、誰が、なぜ設定を変更したか」を完全に追跡できます。
「我々は事故発生の3ヶ月前に、LLMのリソース消費増加を予測し、メモリ制限を16GBから32GBに引き上げる措置を講じていました。その記録がこのGitコミットログです」
このように主張できれば、善管注意義務を果たしていたことの強力な証明になります。コードは嘘をつきません。
リソース監視ログの保存と法的証拠能力
PrometheusやGrafanaを用いたモニタリングは、障害対応のためだけでなく、事後検証のためにも必須です。
特に、「コンテナが落ちた瞬間のリソース使用状況」のログは重要です。もしログがなければ、顧客は「御社のシステムのバグで落ちた」と主張するでしょう。しかし、ログがあれば「お客様のリクエストが想定（契約）の10倍の負荷を一瞬でかけたため、安全装置（リソース制限）が作動して停止しました」と反証できます。
ログの保存期間（リテンションポリシー）も、契約上の責任期間に合わせて設計する必要があります。
定期的な負荷テストとリスク評価の記録義務
システム導入時だけでなく、定期的に負荷テスト（Load Testing）を行い、その結果をレポートとして残しておくことも重要です。k6やLocustなどのツールを用いて、想定される最大負荷をかけた際の挙動を記録します。
「リソース制限機能が正しく動作し、高負荷時でも他のシステムに影響を与えないこと」を確認したテスト結果があれば、それは企業がリスク管理を怠っていなかったことの証明書になります。
5. 経営判断としての「リソース制限」導入チェックリスト
最後に、技術者だけでなく経営層や法務担当者が明日から取り組めるアクションリストをまとめました。技術的な設定値を、経営判断として承認するプロセスを構築してください。
法務・技術部門間の合意形成フロー
- リスクシナリオの共有: 技術部門は「最悪の場合、何が起きるか（全停止、データ消失など）」を専門用語を使わずに法務・経営層に説明したか？
- SLAと設定値の照合: 契約書の「可用性保証」と、Docker/Kubernetesの「リソース制限値」に矛盾はないか？（例：99.9%稼働を保証しているのに、リソースがギリギリではないか）
- 免責条項の具体化: 「技術的な理由による停止」の定義に、リソース超過による制限（Throttling）が含まれているか？
リスク受容レベルの決定プロセス
- コスト対リスクの判断: メモリを倍増させるハードウェア投資コストと、システムダウンによる賠償リスクを天秤にかけたか？
- 「捨てる機能」の合意: リソース枯渇時に、どの機能を優先して停止するか（Degradation）の優先順位は経営判断として合意されているか？
専門家（弁護士・アーキテクト）への相談タイミング
- サービスリリース前: 利用規約作成時に、アーキテクトを同席させて技術的裏付けを確認する。
- 大規模アップデート時: より大きなモデル（例：7Bから70Bへ）に切り替える際、リソース設計とSLAへの影響を再評価する。
Dockerのたった数行の設定（limitやreservation）が、企業の存続に関わる法的リスクを左右することがあります。
技術はビジネスを守るための武器であり、盾です。エンジニア任せにせず、経営と法務が一体となって「技術法務」の観点からAIシステムを見直してみてください。
より具体的なアーキテクチャ設計や、SLAに基づいた基盤構築については、最新のクラウドインフラ構築のトレンドを踏まえつつ、継続的に知見をアップデートしていくことが重要です。
コメント