ローカル推論APIを社内で使う前に。認証・許可リスト・端末退役の設計

こんにちは、Cor.株式会社の寺田です。今日は少し地味な話です。社内でローカルAIを動かすなら、先に決めておきたい話です。

手元で使う前提

ローカルで推論を動かすツールの多くは、まず手元のマシンで使うことを前提にしています。

たとえばOllamaの公式ドキュメントには、localhost上のローカルAPIは認証を必要としない、と書かれています。また、既定ではローカル（127.0.0.1）で待ち受け、設定で待ち受け先を変えられる、とも書かれています。

これは欠陥というより、設計の前提です。手元で使うぶんには、その前提で足ります。問題が起きるのは、この前提のまま社内ネットワークに広げたときです。

ローカルのAPIを呼ぶことと、処理の全体が手元で完結することは、同じではありません。選ぶモデルによっては、外部へ出る経路を使う構成もあります。選んだモデルと、外向きの通信も確認します。

社内という語

社内向けに推論サーバーを立てると、ほかの端末から使えるように待ち受けを広げます。ファイアウォールで、どの端末から届いてよいかを決めます。ここまでは、普通の手順です。

気をつけたいのは、そのあとです。

試しに開けた待ち受けがそのまま残る。一時的に足した許可先がそのまま残る。もう使っていない端末の許可が、台帳から消えたのにファイアウォールには残る。

認証のないAPIでは、「届く」ことがほぼ「使える」ことを意味します。だから、意図しない端末から届きうる状態が残ること自体が、リスクになります。「社内だけ」という言葉は、実際の許可設定が伴って初めて意味を持ちます。

許可リストで分かること

許可リストで分かるのは、通信を通してよい相手です。それだけで、誰が何の業務に使ってよいかまで決まるわけではありません。複数の利用者が使う場合は、前段の認証、利用者やサービスごとの権限、失効したときの動作も、別に設計する項目です。これは、Cor.株式会社がそれらの実装を終えたという報告ではありません。

脆弱性対応と許可設定

脆弱性対応と、許可設定の管理は、どちらか一方で済むものではありません。更新情報を追うことに加え、どの端末が、どの用途で、いつまで接続してよいかを、継続して確認します。

脆弱性の情報（CVE）は、ある日まとめて出てきます。許可設定のずれは、毎日少しずつ積もります。後者は、手順がないと気づきにくいです。どちらも、手順の中に置きます。

受け入れの順番

新しい端末に推論APIを使わせるときは、この順番にしています。これは、Cor.株式会社が受け入れで置いている順番です。

1. 台帳に端末を登録する（用途・担当・利用期限）
2. 端末側の基本設定を確認する
3. ファイアウォールの許可先に追加する
4. 届くことを確認し、確認日を台帳に残す

台帳が先、許可があと、という順番です。許可だけ先に入ると、「誰の何のための許可か」があとから追えなくなります。

退役の順番

端末を外すときは、逆向きにします。

1. ファイアウォールの許可先から削除する
2. 届かなくなったことを確認する
3. 端末側の資格情報や設定を片付ける
4. 台帳を「退役」に更新し、日付を残す。行は消さず、履歴として残す

許可を先に消します。台帳だけを更新して許可が残る。これが起きやすいずれです。

侵害が疑われるときは、上の退役の手順とは別です。隔離と、資格情報の失効を先にします。通常の廃止の順番で、疑わしい端末を扱いません。

確認する項目

個別の事例ではなく、ほかの会社でも使える形にまとめておきます。ここに測定値は載せていません。失効が反映されるまでの時間は、要件として決めます。測った値があるときだけ、その値を書きます。

• 推論APIの待ち受け先を、意図した範囲に限定しているか
• 検証用に広げた待ち受けを、検証後に戻しているか
• ファイアウォールの許可先一覧と、端末台帳が一致しているか
• 許可先ごとに、用途・担当・期限が台帳にあるか
• 退役時に「許可削除、到達しないことの確認、台帳更新」の順で処理しているか
• 許可先一覧と台帳の突き合わせを、定期的に（たとえば月次で）やっているか
• 誰が、いつ、どの許可を足し引きしたかの記録が残っているか
• 認証のないAPIを外に出す必要がある場合、前段に認証やアクセス制御を置く設計になっているか
• 許可した端末から届くことだけでなく、許可していない端末から拒否されるか
• 失効のあと、拒否されるか
• サービスを止めたとき、どう振る舞うか
• 選んだモデルと、外向きの通信が、想定した範囲か

このリストが回っていれば、ずれに気づきやすくなります。すべてのずれが見つかる、という意味ではありません。

一緒に見ている範囲

Cor.株式会社は、既存の設備を起点に、ローカルで処理する範囲を一緒に見ています。ISMSの運用の中で、構成の選定と、権限・失効・ログの設計を一緒にやります。ISMSは、2026年10月にISO/IEC 27001の第2段階審査を終え、2026年12月ごろの認証登録を見込んでいます。

今回の許可リストの話は、その「失効」と「ログ」の話です。推論の性能だけでなく、どの端末がいつまで届いてよいかを説明できることも、運用の条件です。性能の要件を、ここで否定しているわけではありません。

説明できる範囲

認証が無いと聞くと、不安になるかもしれません。それは、ツールの前提を知ったというだけのことです。前提が分かれば、守る範囲も見えます。

誰の端末が、いつから、いつまで届いてよいのか。それを台帳と許可設定の両方で説明できること。Cor.株式会社が残したいのは、そこです。許可リストだけでは、利用者の権限までは決まりません。

参考資料

• Ollama Docs: Authentication - localhostのローカルAPI（ポート11434）は認証を必要としない、という記述（2026年10月27日に確認）
• Ollama Docs: FAQ - 「How can I expose Ollama on my network?」の項。既定では127.0.0.1のポート11434で待ち受け、環境変数 OLLAMA_HOST で待ち受け先を変えられる、という記述（2026年10月27日に確認）
• Cor.株式会社: セキュリティ - ISMSを運用していること、2026年10月にISO/IEC 27001の第2段階審査を終え、2026年12月ごろの認証登録を見込んでいること