EP.14 で手元にモデルを立てる話をしました。そこで「社内で共有するなら認証は別途」と書いた宿題を、この回で回収します。
1台で自分だけが使う状態から、何人かで使う状態へ移るとき、そのまま公開すると事故ります。何を足す必要があるかを整理します。
1. そのまま公開すると何が起きるか
手元で動かす仕組みは、自分だけが使う前提で作られています。そのまま社内に開けると、いくつかの前提が崩れます。
| 前提 | 崩れると |
|---|---|
| 使うのは自分だけ | 誰が使ったか分からない |
| 同時に1つしか処理しない | 同時実行で詰まる、または落ちる |
| 変な入力は来ない | 想定外の入力で止まる |
| 費用がかからない | 電力と機器の占有が増える |
| 記録は要らない | 問題が起きても追えない |
2行目が最初に問題になります。同時に複数の要求が来ると、順番待ちが発生します。上限を設けていないと、待ちが積み上がってメモリを使い果たします（パフォーマンスチューニング実践 EP.07 で扱った話と同じ構造です）。
「社内ネットワークだから」という理由で認証を省くのは危うい。無線経由で外から届くことがありますし、誰が使ったか分からない状態は、機微な情報を扱う仕組みでは避けるべきです。
2. 前段に層を置く
対処の基本は、元の仕組みを改修せず、前段に層を置くことです。 を使うと、認証・暗号化・・記録をまとめて扱えます。
| 層 | 担当 | 改修の要否 |
|---|---|---|
| 前段の層 | 認証・暗号化・流量制限・記録 | 設定だけ |
| 元の仕組み | 推論そのもの | 改修不要 |
この形にすると、元の仕組みを差し替えても前段はそのまま使えます。モデルを変えても、別のソフトに移行しても、認証の仕組みを作り直す必要がありません。
# 流量の上限を定義する（1つのIPあたり毎秒2回まで）limit_req_zone $binary_remote_addr zone=llm:10m rate=2r/s;
# 同時接続数の上限limit_conn_zone $binary_remote_addr zone=llmconn:10m;
server { listen 443 ssl; server_name llm.internal.example.com;
ssl_certificate /etc/ssl/certs/internal.crt; ssl_certificate_key /etc/ssl/private/internal.key;
# 誰が使ったかを残す access_log /var/log/nginx/llm_access.log combined;
location / { # 認証（社内の仕組みに合わせて置き換える） auth_basic "internal only"; auth_basic_user_file /etc/nginx/.htpasswd;
# 流量と同時接続の上限 limit_req zone=llm burst=5 nodelay; limit_conn llmconn 2;
# 生成は時間がかかるので、待ち時間を長めに取る proxy_read_timeout 300s; proxy_buffering off; # 逐次出力を止めない
proxy_pass http://127.0.0.1:11434; proxy_set_header X-Forwarded-For $remote_addr; }}`proxy_buffering off` が実務的な要点です。生成結果を逐次返す構成では、前段がまとめて溜めてしまうと出力が一気に来ることになり、使い勝手が大きく落ちます。
認証方式は社内の仕組みに合わせてください。上の例は最も単純な形です。既に が入っているなら、そちらに寄せるほうが管理が楽になります（エンジニアの引き継ぎ術 EP.02 参照）。
3. 上限を必ず設ける
認証と同じくらい重要なのが上限です。設けていないと、1つの誤った処理が全体を止めます。
- 同時実行数 — 機器が処理できる数に合わせる。超えたら待たせる
- 1リクエストあたりの入力長 — 極端に長い入力を弾く
- 1リクエストあたりの出力長 — 終わらない生成を防ぐ
- 利用者あたりの頻度 — 誤ってループさせたときの被害を限定
- 全体の待ち行列の長さ — 超えたら断る（待たせ続けない）
最下行が抜けやすい。待たせ続けるより、断るほうが親切です。10分待たされて結果が返るくらいなら、すぐ「いま混んでいます」と返すほうが、利用者は別の手段を取れます。
手元の機器は資源が限られています。全部の要求に応えようとすると、全員が遅くなります。断る条件を決めておくほうが、結果として使える仕組みになります。
4. 記録を残す
── 誰が・いつ・何をしたか ── を残します。障害の調査だけでなく、適切に使われていることを示すためにも必要です。
| 記録する項目 | 用途 |
|---|---|
| 誰が | 利用状況の把握。問題時の連絡先 |
| いつ | 時系列の追跡 |
| どれくらい時間がかかったか | 性能の傾向を見る |
| 入力・出力の長さ | 内容は残さず、量だけ |
| エラーの有無 | 問題の検知 |
4行目が判断のいる箇所です。入力内容そのものを残すかどうか。残せば調査には有用ですが、機微な情報が記録に蓄積します。手元で動かす動機が「外に出さないため」なら、記録に残すのも慎重に判断してください。
実務的には、長さや件数などの量だけを残し、内容は残さないという選択が多くなります。それでも傾向は掴めますし、記録自体が新たなリスクになりません。
5. 誰がどれだけ使っているかを見る
運用が始まったら、利用状況を定期的に見ます。想定と実態はずれます。
#!/usr/bin/env bashLOG="${1:-/var/log/nginx/llm_access.log}"
echo "=== 利用者別のリクエスト数（上位10）==="awk '{print $1}' "$LOG" | sort | uniq -c | sort -rn | head -10
echoecho "=== 時間帯別の分布 ==="awk -F'[:[]' '{print $3"時"}' "$LOG" | sort | uniq -c | sort -k2
echoecho "=== 上限に当たった回数（429）==="awk '$9 == 503 || $9 == 429 {n++} END {print n+0 " 件"}' "$LOG"3番目の上限に当たった回数が重要な指標です。多いなら、上限が厳しすぎるか、機器の能力が足りていない。ゼロなら、上限が機能する場面がまだ来ていないということです。
時間帯の分布も見てください。特定の時間に集中しているなら、その時間だけ厳しくなります。処理の重い用途を別の時間に回してもらう、といった調整の材料になります。
6. どこまで作り込むか
最後に線引きです。社内向けの仕組みを作り込みすぎると、維持が負担になります。
| 対象 | 必要性 | 備考 |
|---|---|---|
| 認証 | 必須 | 省略しない |
| 上限（同時実行・入出力長） | 必須 | 無いと全体が止まる |
| 通信の暗号化 | 必須 | 社内でも |
| 基本的な記録 | 必須 | 量だけでよい |
| 利用者ごとの細かい権限 | 場合による | 人数が少なければ不要 |
| 専用の管理画面 | 不要なことが多い | 記録の集計で足りる |
上4つは必須ですが、下2つは規模しだいです。数人で使う仕組みに管理画面を作ると、作る手間と維持の手間のほうが大きくなります。
そして、利用が増えて手元の機器で足りなくなったら、構成そのものを見直すという判断もあります。EP.17 で扱った複数台の構成や、用途によっては外部のサービスとの併用も選択肢に入ります。
1人用の前提（同時実行なし・記録不要）は、共有した瞬間に崩れます。対処は前段に層を置くこと（元の仕組みは改修しない）。認証・上限・暗号化・記録の4つは必須で、特に上限が無いと1つの誤りが全体を止めます。記録は内容ではなく量を残す。そして待たせ続けるより断るほうが、結果として使える仕組みになります。
この記事の感想を教えてください
あなたの 1 クリックで、本当にこの記事は更新されます。「もっと詳しく」「続編希望」が一定数集まった記事は、 ふくふくが 実際に内容を拡充したり続編記事を公開 します。 送信したリアクションはお使いのブラウザに記録され、再カウントされません。