現場のAIと社内文書のAIを、どこで分けるか。Cor.の設計判断

こんにちは、Cor.株式会社の寺田です。

現場のAIと、社内文書のAIを、どこで分けるか。ローカルAIの相談では、この二つがひとまとめに語られることがあります。

一つは、カメラやセンサーの近くで動くAIです。もう一つは、社内文書や業務データを扱うローカルLLMです。

どちらも外部のクラウドへの送信を抑える構成を選べます。それだけで同じ環境にまとめてよいとは限りません。Cor.株式会社では、何につながり、何を扱い、問題が起きたらどこまで影響するのかを別々に見ています。

重視する条件

現場のAIでは、入力を受け取ってから判断を返すまでの時間と、通信が途切れたときの動作を見ます。機械を動かす用途では、異常のときに安全側へ移れることも欠かせません。止まらないことだけが正解ではありません。

現場で一緒に見るのは、止まらないこと（可用性）、遅れないこと（リアルタイム性）、危ないときに安全に止まれることです。

社内文書を扱うAIでは、誰がどの文書を参照できるのかが大きな論点です。担当が変わったときに権限を外せるか。外した権限が検索や回答にも反映されるか。必要な操作をあとから確認できるか。

現場のAIにも権限の管理は要ります。社内のLLMにも、応答の時間と安定した稼働は要ります。設計で特に気をつける場所が違います。

信頼境界

同じクラスタであることが、危険かどうかの結論にはなりません。機材が別であることも、安全であることの証明にはなりません。

同じ基盤の上でも、ネットワークの分離や認証・認可、ワークロードの隔離で境界は設計できます。NISTのゼロトラストは物理的な場所やネットワーク上の位置だけで信頼しない考え方です。

現場の機材を単一のクラスタに無条件で参加させると、境界が曖昧になります。共通のアクセス権や認証情報、管理の経路を理由の確認なしに共有すると、影響の範囲が広がります。現場に置かれた機材が社内文書に近いところまで届いてしまうかもしれません。

構成図の上では、小さな線一本の違いです。運用では、大きな違いになります。

数字のまとめ方

台数や速度の数字を足すと、資料の見栄えはします。Cor.株式会社では、別の用途で動いている機材を一つのシステムの台数には足しません。条件の違う測定値も一つにまとめません。何を測った数字なのかが分かる形にします。これは自社の集計のルールです。ほかの人の意図はここには書きません。

境界が曖昧だと、次が説明できなくなります。このエッジ機が止まったとき、社内LLMのどの利用に影響するのか。この機材のアカウントを止めたら、どこまで止まるのか。

いまの方針

Cor.株式会社がいま選んでいるのは、次の分け方です。方針であって、分けてあるから安全だという意味ではありません。

• フィジカル推論のエッジはエッジ専用として設計する
• 社内ローカルLLMの本線のクラスタには載せない
• 対外的な説明でも、本線の構成や性能の話にエッジ機を混ぜない
• 両者のあいだでデータを渡すときは、渡す内容と経路を個別に決める

エッジで出た結果を、業務側で使いたいという要望はあります。そのときも「同じクラスタにいるから自由に読める」にはしません。

説明用の例

現場の検査結果を、社内の業務で使いたい場合を考えます。これは説明のための構成例です。Cor.株式会社の実装済みの機能でも、顧客の事例でもありません。

検査IDと時刻と判定結果だけで業務が進むなら、映像の全体や、現場の端末への自由な接続は、渡さなくてよいかもしれません。画像が必要な用途なら、その必要性と、扱う範囲を先に確認します。

「同じ社内にあるから読める」にはしません。「この用途に必要だから、この内容だけ渡す」にします。利用を止めたあとに接続が拒否されるか、片方の停止がもう片方へどう影響するかは、構成ごとに確認する項目です。この記事は、その確認が終わったとは書いていません。

シミュレーションで見たこと

Cor.株式会社では、スイカ割りのような身体を使うタスクを題材に、フィジカル推論の検証をしています。現時点ではシミュレーションでの検証です。この検証環境も社内文書を扱う環境とは切り離す方針です。

実験でも、情報の扱いを曖昧にはしません。シミュレーションで確認できたことを、実機の安全性や性能の証明にはしません。実機での安全性と性能は、別に確認が要ります。ここは未確認です。

性能と運用

速度は大事です。必要な時間内に答えが返らなければ、業務には使えません。推論性能はCor.株式会社が研究開発で力を入れているところです。速さは環境と用途で大きく変わります。

速度だけでは業務に使えるかは決まりません。速く答えられても、見てはいけない文書が出る、利用を止められない、障害のときの対応が決まっていない、という状態では困ります。

目指しているのは、性能の要件を満たすことに加えて、安全に運用できる構成まで一緒に確かめることです。あらゆる環境で安全に運用できる、という保証ではありません。

誰が、どこまで、いつまで使えるかを説明できること。境界、権限、失効、安全性まで含めて設計することです。

ローカルに置けば、自動的に安全になるわけではありません。既存の設備を起点に、ローカルで処理する範囲と、業務に合う構成を考えます。

責任の範囲

クラウドも共同責任モデルです。アクセス権限やデータの管理は、もともと利用者側の責任として残ります。分担の中身はサービスの形態によって違います。参照したのはAWSが公開している説明の一例です。

ローカルにすると、そこに基盤の物理的な管理や運用まで加わります。自社で引く線がそのぶん増えます。その線を一本ずつ説明できる状態にしておくこと。Cor.株式会社ではそこを大事にしています。

審査の状態

Cor.株式会社ではISMSを運用しています。2026年10月に、ISO/IEC 27001の第2段階審査を終えました。認証登録は、2026年12月ごろの見込みです。審査の状態と、個々のシステムで何を検証できたかは、分けて伝えます。

つなぐ範囲

現場のAIと社内文書のAIを分けるのは、つなぐことをやめるためではありません。必要なところだけを、理由のある形でつなぐためです。

誰が、何を、いつまで使えるのか。接続を止めたらどうなるのか。問題が起きたとき、どこまで影響するのか。この説明を、構成図だけでなく、設定と確認の結果までつなげる方針です。確認の結果がまだ無い項目は、あるようには書きません。

社内文書と現場のデータをAIで扱いたいものの、接続の範囲を決められていない方は、対象の業務と、いまの構成の概要からご相談ください。最初のご相談に、機密文書や認証情報を送る必要はありません。

参考資料

• NIST SP 800-207: Zero Trust Architecture - ネットワーク上の位置を、暗黙の信頼にしない考え方（2026年10月29日に概要を確認）
• AWS: Shared Responsibility Model - クラウドの責任分担の一例。分担はサービスの形態で違う（2026年10月29日に確認）
• Cor.株式会社: セキュリティ - ISMSを運用していること、2026年10月にISO/IEC 27001の第2段階審査を終えたこと、2026年12月ごろの認証登録を見込んでいること