カテゴリー: コラム

コラム

オフライン生成AIで外に出る通信・出ない通信｜止め方と確かめ方

by ai-editor
オフライン生成AIの社内サーバーから質問・文書は出ないが、更新確認・使用統計・OS自動更新の通信は出ることを示す図

「社外に出ません」と説明した瞬間、情報システム部門から返ってくる質問があります。「本当に1バイトも出ないのか」。

正確には、オフライン生成AI（ローカルLLM）を社内完結の構成にすれば、質問や文書は社外に出ません。ただしソフトウェアが自分のために出す通信は別にあり、止め方は種類ごとに違います。本記事では、生成AIを社外に出さない構成で点検すべき通信の内訳と、止めたことを確かめる方法を整理します。

POINT

一言で答えると、「接続先を社内に固定し、サーバー単位で遮断し、通信ログで確認した構成」なら、社内文書は外に出ないと説明できます。

  • 外に出るのはソフト自身のバージョン情報などで、社内文書ではありません
  • アプリ設定では止まらない通信があるため、最後はサーバー単位の遮断と通信ログの確認で担保します
  • 遮断設定は弊社の初期設定に含まれます。ログ確認と止めた更新の持ち込み（例：月1回）は、弊社の保守で行うか社内担当者が行うかを導入時に決めます

「社内で完結する構成にするので、図面や文書は外に出ません。出るのはソフトの更新確認のような通信で、社内の文書ではありません。サーバー単位で外向きの通信を遮断し、通信ログで出ていないことを確認します。」

担当者に渡す点検チェックリスト（10項目）は記事末尾にあります。費用と構成の目安はオフライン生成AIのページにまとめています。

経営者の方はここまでで十分です。構成の確認は30分ほどのご相談で承ります。ここから先は、技術担当者向けに5系統の内訳と止め方を説明します。
目次（10項目）
  1. オフライン生成AIは本当に通信しないのか？
  2. 系統1：モデルの取得は、操作したときに出る通信です
  3. 系統2：更新確認は、製品によっては起動しているだけで出ます
  4. 系統3：使用統計は、既定でオンのものがあります
  5. 系統4：外部機能は、設定した接続先へ出ます
  6. 系統5：OSの自動更新は、AIソフトを止めても定期的に出ます
  7. AIソフト以外にも出る通信があります
  8. 弊社の標準構成では、どう止めているか
  9. 自社環境の点検チェックリスト（10項目）
  10. まとめ

オフライン生成AIは本当に通信しないのか？

外部機能を無効化するか社内に固定した構成であれば、質問や文書そのものは外に出ません。一方、導入環境で点検すべき通信は5系統あります（AIソフト由来4つ＋OS由来1つ）。契機が違うので止め方も違います（図1）。

オフライン生成AIで外に出る通信5系統（モデル取得・更新確認・使用統計・外部機能・OS自動更新）といつ出るか・止め方の図
図1：オフライン生成AIで外に出る通信5系統と止め方

前提を一つ。外部のLLM APIや外部のWeb検索を接続先に設定した構成では、質問そのものが接続先へ送られます（系統4）。

製品名を知らなくても、下の表と末尾のチェックリストだけで自社環境の点検はできます。製品をまだ決めていない方はそのまま読み進めてください。

本記事に出てくる製品の役割（製品名の凡例）
  • 推論エンジン（AIモデルを動かす土台）：vLLM・Ollama・LM Studio・llama.cpp
  • チャット画面：Open WebUI
  • アプリ基盤（業務アプリを組む土台）：Dify
  • ベクトルDB（社内文書の検索用データベース）：Weaviate
  • モデル配布サイト・ライブラリ：Hugging Face
系統 契機 既定で出るか 止め方
1 モデルの取得 初回・入れ替え時 操作すれば出る 別PCで取得して持込
2 更新確認 起動中に定期（Ollamaアプリ版）／画面を開いたとき（Open WebUI・Dify） 出るものがある（Ollamaアプリ版・LM Studio・Open WebUI・Dify） 設定で止まらないものがあるため、ネットワーク側で遮断
3 使用統計 起動時・定期（10分〜24時間ごと） 既定ONのものがある（vLLM・Hugging Face ライブラリ・Dify・Weaviate） 環境変数で停止
4 外部機能 利用時 設定した接続先へ出る 社内固定／無効化
5 OSの自動更新 定期 Ubuntu Serverはセキュリティ更新の自動適用が既定で有効 停止して手動更新の運用へ

なお「通信が出ない」ことと「安全である」ことは別です。持ち出しや権限の話は記事末尾の関連記事をご覧ください。

系統1：モデルの取得は、操作したときに出る通信です

「使うときに出る」のではなく「入れるときに出る」通信で、運用開始後は発生しません。

取得はインターネット経由です（Ollama公式FAQ「Ollama pulls models from the Internet」）。Hugging Face から取得する構成では、取得済みでも新版確認の通信が出ます。

持ち込み運用にする場合は、必要な1形式だけを持ち込みます。配布物全体は推論に使う分の3倍ほどになることがあるためです。

製品別の設定（技術担当者向け）
  • Hugging Face：HF_HUB_OFFLINE=1 で新版確認を止められます。止まるのは Hugging Face 宛てだけです
  • ログイン済みの端末では認証トークンも一緒に送られます。HF_HUB_DISABLE_IMPLICIT_TOKEN=1 で止められますが、非公開リポジトリは取得できなくなります
  • 容量の例：gpt-oss-120b は配布物全体が約182GBで、推論に使う1形式（約61GB）の3.0倍でした（Hugging Face のファイル一覧より）

系統2：更新確認は、製品によっては起動しているだけで出ます

Ollamaアプリ版のように、誰も使っていない時間帯でも定期的に外へ出るものが、ここに含まれます。

Ollamaの macOS／Windows アプリ版は、60分ごとに更新確認を行います（公式ソースコード）。送るのはOSやバージョンと、端末を見分けられる情報です。社内文書や質問の内容は含みません。

注意は止め方です。アプリ設定で自動更新をオフにしてもチェック自体は続き、停止用の設定もありません。確実に止めるにはネットワーク側で遮断します。

LM Studio・Open WebUI・Dify にも更新確認があり、既定で有効です。

この系統で出ていく中身はバージョン情報と端末の識別情報であって、社内文書ではありません。リスクは限定的ですが、「出ている」事実は説明できるようにしておきます。

製品別の設定（技術担当者向け）
  • Ollama アプリ版の送信先は https://ollama.com/api/update
  • 送る内容（クエリ）：OS・CPUアーキテクチャ・バージョン・時刻・乱数（nonce）。端末IDはmacOSのみ
  • 送る内容（ヘッダ）：端末固有の署名鍵の公開鍵（~/.ollama に保存され毎回同じ値。Authorizationヘッダ）と、OSの詳細バージョン（User-Agent）。Windowsもこの公開鍵で端末が識別されうる
  • ソース上の記述は「Always check for updates」。停止用の環境変数はソース上に見当たりません
  • Linuxサーバー版（tgz／Docker）にはこの更新確認は含まれません（ソース上、更新確認の部分は Windows と macOS 向けにだけビルドされる指定です）
  • LM Studio：公式が、更新確認やモデル・ランタイム取得にネットワークが要ると明記。更新確認で送るのはアプリのバージョン・ビルド・OS・IPアドレス（公式プライバシーポリシー）
  • Open WebUI：ENABLE_VERSION_UPDATE_CHECK が既定 True。管理者が画面を開いたときにサーバー側から GitHub へ確認（24時間に1回）
  • Dify：CHECK_UPDATE_URL に既定値があり、画面操作を契機に確認。公式は「空にすれば無効。エアギャップ（外部から隔離した）環境向け」と記載

系統3：使用統計は、既定でオンのものがあります

匿名の使用統計を既定で送信する製品があります。判定の目安は次のとおりで、止め方は主に環境変数（設定値）です。製品名と設定は下の折りたたみにまとめました。

  • 推論エンジン・ベクトルDB・モデル取得のライブラリを使うなら、まず「既定ON」を疑う
  • アプリ基盤（Dify）は設定サンプルに項目が無く見落としやすい。停止設定を自分で追記する
  • 公式が「使用統計を含まない」と明記している製品（LM Studio）もある。記載が無い製品（llama.cpp）は、無い＝出ない証明ではないので遮断で対応する
製品別の設定（技術担当者向け）
  • vLLM：既定ONで、送信先は https://stats.vllm.ai。起動時に1回、その後は10分ごとに送り続けます。停止は VLLM_NO_USAGE_STATS=1 または DO_NOT_TRACK=1（値は文字列の 1。true では止まりません）。ファイル（~/.config/vllm/do_not_track）を置く方式もありますが、参照先は VLLM_CONFIG_ROOT、XDG_CONFIG_HOME、ホームの順に決まり、実行ユーザーによって変わるため環境変数を推奨します
  • Hugging Face のPythonライブラリ（transformers 等）：既定で利用データを収集。HF_HUB_DISABLE_TELEMETRY=1 で収集を止めます（Hub への通信自体は残り、ライブラリのバージョン情報は送られます）。DO_NOT_TRACK=1 は vLLM と Hugging Face の両方に効きます
  • Dify（Community版）：匿名の利用統計（インストール時と30分ごとの死活情報。バージョン・OS・インスタンスIDなど）を otel.dify.ai へ既定で送ります。.env.example にこの設定は載っていないため、DISABLE_TELEMETRY=true（または DO_NOT_TRACK=true）を自分で追記します。画面側の NEXT_TELEMETRY_DISABLED=1 も併せて設定します
  • Open WebUI：公式配布物では使用統計関連の3変数が既定OFF
  • Weaviate（DifyのベクトルDBに選ぶ構成）：Difyのdocker設定 WEAVIATE_DISABLE_TELEMETRY=false のため既定で止まっていません。Weaviate公式によれば、24時間ごとにマシンID・バージョン・OS・使用モジュール・オブジェクト数・コレクション数を送り、クラウド上ではAWSアカウントIDなどの識別子も加わります（v1.33以降）。公式は、この情報を商用の見込み客特定に使い第三者と共有することがあると記載しています。停止はWeaviate側の DISABLE_TELEMETRY=true です

系統4：外部機能は、設定した接続先へ出ます

これは「既定で出る」通信ではなく、設定した機能を使ったときに設定した先へ出る通信です。

重要な前提として、外部のLLM APIを接続先に設定した構成では質問そのものが接続先へ送られます。この時点で「文書は出ない」という説明は成り立ちません。Ollama のクラウドホスト型モデルも同じです。

誤解されやすいのは Open WebUIの OFFLINE_MODE です。名称が示すほど広い遮断ではなく、外部LLM API接続や、外部APIを使うWeb検索・RAG（社内文書を検索して回答に使う仕組み）は止めません。

一方、Web検索・埋め込みAPI・音声・画像生成は接続先を社内に向けられます。使う機能は接続先を社内に固定し、使わない機能は無効化し、そのうえでファイアウォール（FW・通信を遮る仕組み）で遮断します。

製品別の設定（技術担当者向け）
  • Open WebUI の OFFLINE_MODE：外部LLM API接続・外部サービスでのログイン認証・外部APIを使うWeb検索やRAGは、公式が「Still functional」と明記。系統1の HF_HUB_OFFLINE も宛先はHub限定です
  • Ollama：公式FAQの「プロンプトやデータを見ない」はローカル実行時に限った説明で、クラウドホスト型モデルを使う場合はプロンプトと応答を処理する（保存・記録・学習はしない）と続けています。クラウドモデルを使わせない設定は ~/.ollama/server.json の disable_ollama_cloud: true、または環境変数 OLLAMA_NO_CLOUD=1
  • 社内に置ける代替：SearXNG（Web検索）・埋め込みモデル・OpenAI互換API。機能を使いながら社外へ出さない構成が可能です

系統5：OSの自動更新は、AIソフトを止めても定期的に出ます

AIソフトの設定を見直しても、土台のOSが更新を取りに行けば通信は出ます。

Ubuntu Serverは公式ドキュメント上、unattended-upgrades が既定でインストールされ、セキュリティ更新の自動適用が有効とされています（Desktopは同じ記述が確認できないため断定しません）。

整理します。

  • 定期的に出るもの：OSの自動更新、時刻同期
  • 作業したときに出るもの：Dockerイメージの取得、pipでのインストール

止める場合は「止めた分の更新をどう入れるか」を運用に組み込みます。月次の持ち込みパッチなど、担当と頻度を決めないと更新が止まります。

AIソフト以外にも出る通信があります

AIサーバーを置けば、AIとは無関係の通信も棚卸しの対象になります。確認方法は共通で、サーバー単位の外向きFWルールと通信ログでの実測です。

点検対象の一覧（情報システム担当向け）
  • DNS（名前解決・DoH／DoT）
  • 証明書の失効確認（OCSP・CRL）
  • プロキシ自動検出（WPAD・PAC）
  • 利用端末のブラウザ側（セーフブラウジング・拡張機能・外部フォント）
  • GPUドライバや管理ツールの更新確認
  • EDR・資産管理・バックアップ

既定値は環境によって異なるため個別には断定しません。

弊社の標準構成では、どう止めているか

弊社の標準構成は、Linuxサーバー上の vLLM または Ollama（推論）＋ Open WebUI（チャット画面）です。ご要望に応じて Dify などのアプリ基盤を加え、AIモデルも用途に合わせて複数の候補から選びます。

初期設定には、外部へ送信しない内部ネットワーク完結構成の設定を含めています。運用時にインターネット接続を必要としない構成にしています。

ただし最終的な保証はアプリ設定ではありません。サーバー単位で外向き通信を遮断し、通信ログで確認することが実体です。系統2のとおり、アプリ設定では止まらない更新確認もあるためです。

止めたあとの運用も導入時に決めます。モデル更新やパッチを選択制の保守で行うか、社内担当者の持ち込みで行うか。担当と頻度を先に決めるのが、止めっぱなしにしないコツです。

構成が変わっても点検の考え方は同じで、系統1〜5の表に当てはめれば別の構成でも確認できます。

自社環境の点検チェックリスト（10項目）

このまま情報システム担当に渡してください。経営者が決めるのは、5番の「止めた更新を誰がどの頻度で入れるか」と、9・10番を誰が確認するかの2点です。

チェック項目（できているものにチェック・括弧は対応する系統）

まとめ

  1. 社内完結の構成であれば、質問や文書は外に出ません
  2. ソフトウェア由来の通信は契機ごとに止め方が違い、アプリ設定では止まらないものもあります
  3. 確かめて初めて「社内完結」と言えます。通信ログでの確認までが説明責任の範囲です

関連記事：クラウドとの違いと接続の要否は導入前ガイド、導入の判断と持ち出し・権限の話はオフラインとクラウドの判断軸、構成や費用感はオフライン生成AI（ローカルLLM）のページをご覧ください。

構成の確認は30分ほどのご相談から

検討中の構成について「どの系統が出るのか」「どこを遮断すればよいのか」を一緒に確認するだけでも、社内説明の材料になります。本記事のチェックリストを御社の構成に当てはめる作業も、30分ほどのご相談で承ります。

ご相談・お問い合わせはこちら

参考（一次情報・2026年9月14日時点で確認）

本記事の設定名・既定値は2026年9月14日時点の公開ドキュメントとソースコードに基づきます。各製品の改版で変わることがあるため、実際に通信が止まっているかは御社環境の通信ログで確認してください。記載の製品名は各社の商標または登録商標です。

コラム

答えを伏せて手順を約束。本文の「次の一歩」

by user
この記事の要約
  • そもそも画像に写っていない欠陥は、AIでもルールベースでも検出できません。撮像は方式選択より上流の話です
  • 照明や環境の変動を、AIが吸収してくれるとは限りません。違いは強い・弱いではなく劣化の出方です
  • 撮像を整えたら、データの側（サンプル・判定の一致）と検証の設計で原因を切り分けます

AI検査を入れてみたものの、期待した精度が出ない。PoCの結果が伸びず、そこで止まってしまった。外観検査の自動化では、こうした行き詰まりが起こります。

このときまず疑いたくなるのは、モデルやアルゴリズムです。学習データを増やす、別のモデルを試す、しきい値を調整する、といった方向に手が向きます。

どれも間違いではありませんが、手を入れる順番としては後になることがあります。原因が、モデルより手前の「撮像」にあることがあるためです。

本記事では、原因の切り分け方を次の順で整理します。撮像・環境変動・データ・進め方の順に見ていきます。

目次
  1. 結論：精度が出ない原因は、アルゴリズムより先に「撮像」を疑う
  2. 「AIは環境変動に強い」は不正確です
  3. NG画像が足りない・判定が割れる — データ側が原因のケース
  4. 小さく試して切り分ける — 「いきなりAIを作らない」進め方
  5. 次の一歩

結論：精度が出ない原因は、アルゴリズムより先に「撮像」を疑う

そもそも画像に写っていない欠陥は、AIでもルールベースでも検出できません。

これは方式選択より上流の話です。分解能が足りない、照明の当て方で欠陥が背景に埋もれている、光沢面の反射で白飛びしている。こうした状態では、どちらのアルゴリズムでも結果は変わりません。

単一露光でセンサーが飽和（白飛び）した領域の元の輝度や模様は、通常の後処理から一意には復元できないためです。

最初の確認は、この一問です。欠陥は画像に十分な大きさとコントラストで、安定して写っていますか。写っていない場合や写り方が毎回変わる場合は、方式を比べる前にカメラ・照明・分解能の見直しが先になります。

光沢・反射のある対象は「AIなら対応できる」と説明されることがあります。当社では、まず光学側で反射を抑えるのが先だと考えています。

対象の材質・形状に応じて、拡散照明・偏光フィルタ・多方向からの撮影といった手段を実機で評価します。そこで変動そのものを減らし、それでも残る変動に対して学習ベース（AI）が有効な場合がある、という順番です。

変形や反りは、明暗の画像（2D）に現れにくい場合があります。その場合は判定アルゴリズムを比べても解決せず、多方向照明や3D計測を含めた撮像設計として検討する領域です。3Dデータに対しても、ルールベースと学習ベースの両方を適用できます。

撮像条件の側に原因がある場合に備え、当社は卓上型・インライン型・組み込み型をカスタム設計しており、ソフトウェアと撮像側を合わせて検討します。

撮像を整えたうえで、次に見るのが環境の変動とデータです。

「AIは環境変動に強い」は不正確です

照明や環境の変動を、AIが吸収してくれるとは限りません。

当社では、両者の違いは強い・弱いではなく、劣化の出方にあると整理しています。

  • ルールベース：しきい値をまたいだ瞬間に判定が変わる壊れ方をしやすく、その分、原因の特定はしやすい傾向があります
  • AI：学習時に含めた範囲の変動には頑健になりやすい一方、想定外の変動では精度低下に気づきにくくなる傾向があります

つまり、AIを選んでも変動が消えるわけではありません。気づきにくい形に変わることがあります。

そのため当社の設計順序は、まず遮光・照明固定・露出固定で変動そのものを潰すことです。残った変動は、ルールベースなら基準との相対比較で抑え、AIならデータ拡張や複数条件でのデータ収集で頑健性を高めます。効果は変動の種類ごとに検証します。

なお、どちらの方式でも、入力画像が変わっていないかを運用の中で監視することは必要です。

NG画像が足りない・判定が割れる — データ側が原因のケース

撮像が整っていても、学習データの側が精度の上限を決めることがあります。

不良品の画像がほとんどない場合は、良品だけを学習して「良品らしくないもの」を拾う異常検知から検討できます。学習自体は良品のみでも可能です。

ただし、狙った不良を検出できているかの確認は別に必要です。運用のしきい値決定にも、少数でよいので、実物の不良か、実際の欠陥の見え方を再現できると確認した模擬不良サンプルが望まれます。「NG品がゼロでよい」わけではありません。

補助的には、既存の不良画像を加工して増やす方法もあります。実際の欠陥の出方を再現できる保証はありません。

判定を広めに拾って人が最終確認する運用から始めるのも現実的です。まずは、実物の良品・不良品サンプルをどこまで用意できるかの確認からです。

もう一つ見落とされやすいのが、判定そのものが割れているケースです。「熟練者は分かるが言語化できない」判定を学習に落とす場合、着手前に複数の検査員で判定が一致するかを確認します。判定が割れていると、見逃しや過検出が増え、精度が伸びにくくなります。

小さく試して切り分ける — 「いきなりAIを作らない」進め方

方式の議論が長引くときは、手段を先に決めないことが近道になります。

当社は、計測機器メーカー様から計測誤差の補正開発を受託しました。進め方は、データクリーニング → 相関・因果分析 → 分散・誤差分析 → 原因分析の順です。AIモデルの構築は最後でした。

先に現象を分解したことで、モデルに何をさせるべきかが明確になりました。検査でも、同じ入り方が有効です。「AI検査を導入する」ではなく「この判定をどう成立させるか」から入ります。

小さく試す段階で決めるのは、次の3点です。

  1. 対象を絞る：全品種・全欠陥を一度に狙わず、頻度と影響の大きい項目から着手します
  2. 評価指標を決める：見逃し率と過検出率を併記して評価します。単一の精度値だけでは運用の判断がしにくいためです。どちらを優先するかは工程で変わります
  3. 続行・中止の条件を決める：何が確認できたら次に進み、何が見えたら止めるのかを、始める前に決めておきます

この3点を先に決めておくと、精度が出なかったときにも「どこで止まったのか」が残ります。次の一手を選ぶための材料になります。

次の一歩

精度が出ないときは、モデルを作り直す前に、撮像・照明の側を先に確認するのが近道です。

  1. 欠陥が画像に安定して写っているかを確認する
  2. 写っているなら、検査員間で判定が一致しているか、サンプルが用意できるかを確認する
  3. 対象を絞り、続行・中止の条件を決めたうえで小さく試す

方式そのものの使い分けは、AI検査とルールベース検査の違い｜状況別の使い分け早見表つきで整理しています。

初回のご相談では、図面や機密情報のご提出は不要です。具体的な可否判断の段階で、必要に応じて画像や図面を個別にご相談します。

検査対象と現在の判定方法、うまくいかない点をお聞かせいただければ、原因の切り分けからご一緒します。

お問い合わせフォームはこちら

コラム

オフラインvsクラウド判断軸

by user

「機密情報を扱うので、クラウドの生成AIは使えない」

そう考えてオフライン生成AI（ローカルLLM）を調べ始めると、200万円前後から数千万円という金額が並びます。決して小さい買い物ではありません。ただ、その前に確かめておきたいことがあります。そもそも、自社は本当にオフラインである必要があるのか、という点です。

本記事では公開ベンチマークと公表価格をそのまま並べたうえで、それでもオフラインを選ぶ理由になる条件を整理します。読み終えたときに「うちはクラウドで十分だった」と分かるのであれば、この記事は役目を果たしたことになります。

目次
  1. 結論：オフラインを選ぶ理由は2つだけ
  2. 30秒診断：当てはまるものにチェックを入れてください
  3. 精度：社内に置けるAIは、クラウド最上位の半分
  4. 費用：50人・3年が損益の分かれ目
  5. それでもオフラインが必要になる2つの条件
  6. 「機密情報は入力しない」ルールだけでは守りきれない
  7. 現実解は「併用」：出せない情報だけを切り出す
  8. よくある質問
  9. まとめ：次にやること4つ

結論：オフラインを選ぶ理由は2つだけ

POINT

性能とコストだけを基準にするなら、選ぶべきはクラウド型の生成AIです。 2026年8月時点の公開ベンチマークでは、社内サーバー1台で動かせる規模のAIモデルとクラウド最上位モデルの間に、まだはっきりした差があります。費用も、少人数での利用ならクラウドが圧倒的に安く、オフラインが追いつくには相応の人数と年数が必要です。

それでもオフラインを検討すべきなのは、次の2つのどちらかが実際に存在する場合に限られます。

  1. クラウドに出せない情報がある … 取引先との契約や社内規程で、外部のサーバーに送信してはいけないと定められた情報を、AIに扱わせたい
  2. クラウドにつながらない環境がある … 工場や施設内など、セキュリティ方針でインターネットから切り離されたネットワークの中でAIを使いたい

逆に言えば、「なんとなく不安だから」という理由だけでは、オフラインを選ぶ根拠として弱いということです。その不安の多くは、クラウド側の設定と契約の確認で解消できる範囲にあります。

30秒診断：当てはまるものにチェックを入れてください

以下の4項目のうち、自社に当てはまるものを選んでください。チェックの数を目安に、下の3つの区分で判定します（4.だけは例外で、当てはまる場合は数に関係なくオフラインの本格検討です）。チェックは画面上で印を付けるためのもので、当サイトへの送信・記録は行いません。

※1.は、規程・契約書を実際に確認してからチェックしてください。まだ確認していない場合は、チェックの前に規程と主要な取引先との契約書を読み返すことから始めてください。それが判断の第一歩です。

チェック項目（当てはまるものにチェック）
0個クラウドで十分
まずはクラウド型の法人プランを、承認された形で正式に導入することをおすすめします。
1〜2個併用を検討
大半の業務はクラウドで進め、出せない情報を扱う業務だけをオフラインに切り出す形が合理的です。該当業務が月に数件程度なら、まずクラウドで運用して量を数えてから判断してください。
3個以上オフラインを本格検討
クラウドでは要件を満たせません。費用は後述の回収表で見当を（20人規模では費用面の正当化が難しめです）。

※4.に当てはまる場合は、個数に関係なく【オフラインを本格検討】です。クラウド型は通信経路がないため使えません。

人数と年数は方式の判定には使いません。目安として、50人以上・3年以上の利用なら初期費用を回収しやすくなります（詳細は「費用」の回収表）。医療・金融・公共など規制のある業種は、所管ガイドラインの最新版もあわせて確認してください。

精度：社内に置けるAIは、クラウド最上位の半分

POINT

「オープンなAIモデルはクラウド最上位に近づいた」という話と「社内に置けるAIモデルはまだ遠い」という話は、どちらも同時に正しいというのが実態です。ここを混同すると判断を誤ります。

オフライン生成AI（ローカルLLM）とは、AIモデルのデータ本体を自社サーバーに置き、社内ネットワークの中だけで動かす形です。中身（重みと呼ばれるデータ）が公開された「オープンモデル」を使って構築するため、その精度は「今どんなオープンモデルが手に入るか」と「自社の機械にどのサイズまで載るか」の両方で決まります。

数字で見ると、差は縮んでいる

AIモデルの性能を横並びで比べる公開指標に、Artificial Analysis社の「Intelligence Index」があります。複数の試験問題セットの成績をまとめた総合スコアで、数字が大きいほど高性能です。

2026年8月15日時点で、クラウド最上位のClaude Opus 5（最上位設定）が63。これに対し、オープンモデルの最上位グループはKimi K3（Moonshot AI）とQwen3.8（Alibaba）で、Kimi K3のスコアは60。DeepSeek V4 ProやGLM-5.2がそれを追う構図です。クラウド最上位とオープン首位の差は、すでにこの程度まで縮まっています。

しかし「社内に置けるか」で話が変わります

問題は、これら上位のオープンモデルが、一般的な企業のサーバー1台にはまったく載らないという点です。首位のKimi K3はパラメータ数（AIモデルの規模を示す数値）が2兆8,000億。「量子化」というデータ圧縮を済ませた配布形態でも、データ本体だけで1.56テラバイトあります。一般的な企業が最初に導入する1台のサーバー構成で扱える量ではなく、「まず1台入れてみよう」と考えるクラスでは手が届きません。

社内サーバー1台に載るサイズの実力

Googleが2026年4月に公開した「Gemma 4 31B」は、パラメータ数307億のオープンモデル（Apache 2.0ライセンス）です。このクラスなら、GPUを積んだ1台のサーバーで動かせます。そのIntelligence Indexは30（じっくり考えてから答える「思考モード」での値）。クラウド最上位の63に対して、およそ半分です。同サイズ帯では優秀な部類であり（同じ規模のオープンモデルの中央値は9です）、それでも半分ということです。

図1：Intelligence Index の比較（数字が大きいほど高性能）
クラウド最上位 63
オープン最上位※社内サーバー1台には載りません 60
社内1台に載る規模 30

※Artificial Analysis社「Intelligence Index」。数値は2026年8月15日時点。オープン最上位（Kimi K3）はデータ本体が1.56テラバイト規模のため、社内サーバー1台には載りません。「社内1台に載る規模」の数値はGemma 4 31Bのスコアです。棒の長さは最大値63を100%とした相対表示です。

この数字をどう受け取るべきか

ただし、スコアが半分だから業務が半分しかこなせない、という意味ではありません。社内文書を検索して要約する、議事録を整える、定型文を作るといった用途なら、スコア30でも実用になる、というのが弊社の見立てです。差がはっきり出るのは、複雑な調べもの、長文の論理的な組み立て、プログラミングといった領域です。

また、ベンチマークの順位は毎月のように入れ替わります（本記事のスコアは2026年8月15日時点）。ですから精度の判断は、公開スコアだけでなく自社の実際の業務データで試して確かめるしかありません。

実際に使うモデルはどう選んでいるか（弊社の現場から）

では、社内サーバーで実際に動かすモデルには何を選ぶのか。弊社が検証や提案の際にまず候補へ挙げることが多いのは、Googleの「Gemma」シリーズです。理由は3つあります。第一に、公式に「140以上の言語でネイティブに訓練」と明記されており、弊社でも日本語の社内文書向け用途で実用的に使えていること（体感ベースです）。第二に、OSI承認の標準的なオープンソースライセンスであるApache 2.0で公開されており、改変・商用利用がしやすいこと。第三に、小型モデルから31Bクラスまで複数のサイズが公式に用意されており、サーバーの規模に合わせて選べることです。Googleの公式発表（2026年4月のGemma 4公開時）では累計ダウンロードは4億回を超えており、事例やノウハウ・周辺ツールが集まりやすいことも実務では効きます。

オープンモデルの先駆けだったMetaの「Llama」は、弊社が把握する限り直近版は2025年4月のLlama 4にとどまっており（2026年8月時点）、最近の弊社の検証・情報収集の範囲では、選ぶ場面が減っています。なおMetaからは2026年8月に、エージェント用途向けをうたうオープンウェイトの新モデル「Muse Glimmer」（300億パラメータ・Apache 2.0）が公開されており、この「1台に載るクラス」の選択肢は今後も入れ替わりが続くとみられます。

なお、「社内文書を検索して要約する」用途で31Bクラスが実用になるのには、仕組み上の理由があります。この使い方（RAG＝検索拡張生成と呼ばれます）では、回答の材料は検索で取り出した社内文書の側にあり、AIモデルの役割は「渡された文書を読んで、まとめる」ことに絞られるためです。モデル自身の知識量や推論力が問われる調べもの型の使い方に比べて、モデル規模への要求は軽くなります。

ただし、モデルの賢さと「何人で快適に使えるか」は別の問題です。同時に使う人数や応答速度の要件によって必要なサーバー構成は変わりますし、同じ規模帯でも内部方式によって速度は大きく違います。そのため弊社では、導入プロジェクトの工程の一つとしてモデルの選定・検証を組み込み、お客様の実データで複数のモデルを比較してから決めています。開発元の国やライセンスが調達要件になる場合は、それらも選定条件に加えます。なお、ひとくちに「1台」と言っても、搭載するGPUによって価格には大きな幅があります。具体的な金額は、次の費用の章で見ていきます。

費用：50人・3年が損益の分かれ目

POINT

少人数・短期間ならクラウドが圧倒的に安く、人数と年数が増えるほどオフラインが追いついてきます。 ただし逆転までに必要な条件は、多くの方が想像するより厳しめです。

クラウド側の費用

Anthropic社のClaude Teamプランは、公式価格ページで「年払いで1席あたり月額20ドル、月払いなら25ドル」と表示されています（2026年8月14日確認）。Google Workspaceの日本向け公式価格ページでは、Business Standardが1ユーザーあたり月額1,600円、Business Plusが2,500円で、いずれもGeminiのAI機能が料金内に含まれます。初期費用はほぼゼロで、すぐに使い始められます。

オフライン側の費用

一方、オフライン生成AIは機械の購入から始まります。実際に公表されている価格は次のとおりです。

提供元・出典内容公表価格
インテック「ローカルLLM導入支援」（2026年1月発表）閉域ネットワーク内にGPUサーバー＋LLM＋RAGをパッケージ提供。最短1カ月で構築参考価格 500万円（税別）から
リコー「RICOH オンプレLLMスターターキット」（2025年4月発表）GPUサーバーに700億パラメータのLLMとDifyをプリインストール1,500万円から
業界メディアによる相場記事（2025年11月）エントリー構成〜エンタープライズ構成198万円（税抜）〜2,500万円以上

※いずれも各社発表時点の公表価格です。含まれる範囲（機器・構築・保守など）は各社で異なり、同一仕様での比較ではありません。最新の価格は各社にご確認ください。

どこで逆転するのかを計算してみます

クラウドの費用を仮に1人あたり月額3,000円（年間36,000円）と置いて、オフラインの初期費用を何人年で回収できるかを計算しました。

オフライン初期費用回収に必要な規模20人で使う場合50人で使う場合100人で使う場合
198万円（税抜）55人年約2.8年約1.1年約0.6年
500万円（税別）139人年約6.9年約2.8年約1.4年
1,500万円417人年約20.8年約8.3年約4.2年

読み取れることは、20人規模でオフラインを費用面から正当化するのは、かなり難しいということ。最小構成でも約2.8年、500万円構成なら約7年かかります。

しかも、この計算はオフライン側に有利すぎます。（電気代・保守・人件費・ハードウェア更新などの運用費を含めていないため。クラウド側は月額料金の中で機能や性能の向上を受け取れます）

つまりコストは、オフラインを選ぶ理由ではなく、オフラインを選ばざるを得なくなったときに、その負担を受け入れられるかを確認する材料と考えるのが実態に合っています。

それでもオフラインが必要になる2つの条件

POINT

オフラインを選ぶ理由になるのは、技術やコストの話ではなく、契約・規程・物理環境という「動かせない制約」がある場合です。裏付けが取れた範囲で、2つの条件と、あわせて確認すべき規制面の補足を挙げます。

条件1：契約や社内規程で、外部送信が制限された情報がある

代表的なのがこのパターンです。

  • 取引先とのNDA（秘密保持契約）で、「第三者のサーバーに保存・送信しない」と定められた図面や仕様書がある
  • 発注元の情報セキュリティ基準で、外部クラウドサービスの利用に事前承認や監査が求められている
  • 自社の情報管理規程で、特定区分の情報を社外システムで扱うことを禁じている

重要なのは、これは業界の一般論ではなく、会社ごと・契約ごとに異なるという点です。同じ製造業でも、A社は問題なくクラウドを使え、B社は取引先の基準で使えない、ということが普通に起こります。

ですから判断の第一歩は、AIの検討ではなく、自社の規程と主要な取引先との契約書を実際に読み返すことです。「制限されている情報が具体的に存在する」と確認できて初めて、オフラインが選択肢に入ります。

条件2：そもそもインターネットにつながらない環境で使う

クラウド型の生成AIは、事業者のサーバーと通信して動きます。したがって、セキュリティ方針で外部ネットワークから物理的に切り離された環境（閉域網・エアギャップ環境）では、そのままでは利用できません。 技術的な優劣ではなく、通信経路が存在しないという単純な事実です。工場の制御系ネットワークや、外部接続を遮断した施設内システムがこれにあたります。

補足：所管省庁のガイドラインは「禁止」ではなく「確認事項」を課すもの

ここは誤解が多いところなので、正確にお伝えします。個人情報保護委員会は、2023年6月2日付の「生成AIサービスの利用に関する注意喚起等」で、本人の同意なく個人データを含むプロンプトを入力し、それが回答の出力以外の目的で扱われる場合は個人情報保護法違反となる可能性があるとしたうえで、企業に対して次のように述べています。

（前略）このようなプロンプトの入力を行う場合には、当該生成AI サービスを提供する事業者が、当該個人データを機械学習に利用しないこと等を十分に確認すること。

つまりこれは「クラウド生成AIを使うな」という内容ではありません。 入力したデータが学習に使われないことを「十分に確認すること」を求めるものです。学習に利用しない条件はプランや設定によって異なるため、自社が契約するプランの規約に当たってください。

業種によっては所管省庁が別途ガイドラインを定めています（医療・金融・公共など）。該当する業種の方は最新版を必ず確認してください。

逆に、オフラインを選ぶ理由にならないもの

次の理由だけでオフラインを選ぶのは、費用に見合わない可能性が高いです。

  • 「クラウドはなんとなく不安」 … 契約・設定・権限管理で対処可
  • 「情報漏洩を絶対に防ぎたい」 … 内部からの持ち出しは残る
  • 「コストを下げたい」 … 20人規模では回収に数年
  • 「最新のAIを自社のものにしたい」 … 社内のモデルは自動更新されず

「機密情報は入力しない」ルールだけでは守りきれない

POINT

「クラウドAIに機密情報を入れてはいけない」という社内ルールを出すだけでは、守られない場合が多いことが複数の調査で示されています。

PagerDuty社の調査（日米英豪の大手企業勤務の非IT職1,250名・2026年4月）では、66%が、社内ルール上は許可されていないと認識しながら業務でAIツールを使ったことがあると回答。国内でもガートナージャパンの調査（2026年6月発表）で73%の企業がシャドーAIを管理できていない状態とされています。

第一の対処は「承認された、使ってよいAI環境を正式に用意すること」です。オフライン生成AIが効くのは、そのうえで残る「そもそもクラウドに出せない情報」の部分です。順序を逆にして、シャドーAI対策としていきなり数百万円の設備を入れると、コストに見合わない結果になりがちです。

現実解は「併用」：出せない情報だけを切り出す

POINT

多くの企業にとっての現実解は併用です。業務の大半はクラウドで進め、外に出せない情報を扱う業務だけをオフラインに回すという形になります。

切り分けの軸は「業務」ではなく「情報」

よくある失敗が、「営業部はクラウド、開発部はオフライン」といった部署単位の切り分けです。同じ部署でも外に出せる情報と出せない情報が混ざっているため、これはうまくいきません。正しい軸は情報の区分です。

ステップ1：情報を3つに分ける

図2：情報の区分と、その行き先
A：外部に出しても問題ない情報
公開済みの資料、一般的な調べもの、社外向け文章の下書き
▼
クラウド
B：社外秘だが、契約上クラウド利用が禁じられてはいない情報
一般的な社内資料、議事録、社内マニュアル
▼
クラウド（規約確認のうえ）
C：契約・規程で外部送信が明確に制限されている情報
取引先から預かった図面・仕様、特定の顧客データなど
▼
オフライン

※切り分けの軸は部署ではなく情報の区分です。Bを最初からオフラインに含めると、必要以上に大きな設備が必要になります。

ステップ2：AとBはクラウドに寄せる

Bは、法人向けプランで「入力データを学習に使わない」ことを契約・規約で確認したうえでクラウドを使う、という判断が成り立ちます。

ステップ3：Cの量を数える

Cに該当する業務が月にどれくらい発生しているかを実際に数えます。月に数件しかないなら、そもそもAI化の効果自体が小さい可能性があります。日常的に発生しているなら、投資が正当化されます。

ステップ4：Cの範囲だけで構成を決める

オフライン側の規模は、「全社員が使う」ではなく「Cを扱う人が何人か」で決めます。ここを絞れるかどうかで、費用は数百万円単位で変わります。

併用のデメリットも申し上げます

併用は万能ではありません。利用者は2つの環境を使い分けることになり、「この資料はどちらに入れるのか」という判断を現場の一人ひとりに求めることになります。切り分け基準の文書化と周知、クラウド契約と社内サーバーの二重管理も発生します。

それでも、「全部オフラインにする」よりは現実的です。全部オフラインにすると、精度の低いモデルで全業務をこなすことになり、結果として使われなくなるリスクが高まります。

なお、切り分けの方針が固まり実際に導入を決めた後の進め方（構成の選び方、社内ルールの決め方、導入までの期間）は、オフライン生成AI（ローカルLLM）導入前に押さえる基本知識・選び方・社内ルールで解説しています。

よくある質問

Q1. オフラインにすれば、情報漏洩は起きなくなりますか

いいえ、そうとは言えません。

オフライン生成AIが防げるのは、「入力した情報が外部のサーバーに渡ること」です。従業員が回答をコピーして社外に持ち出すこと、サーバー自体への不正アクセス、そして権限のない社員が、閲覧できてはいけない社内文書をAI経由で読んでしまうことは防げません。

最後の一つは特に見落とされがちです。社内文書を検索できるようにする仕組み（RAGと呼ばれます）を入れると、これまで部署内に留まっていた文書が、AI経由で誰でも読める状態になり得ます。オフラインにしても、誰がどの情報にアクセスできるかの設計は必要です。

Q2. 社内サーバーに載る小さいモデルでも、実務で使えますか

用途によります。社内文書の検索・要約・定型文の下書きでは実用になる、というのが弊社の見立てです。

判断には、自社の実際の文書と実際の質問で試すことが唯一確実な方法です。

Q3. オープンモデルが今後クラウドに追いつくなら、今はクラウドで待つべきですか

「クラウドで待つ」という判断は、多くの場合で合理的です。

ただし、条件1・条件2に該当する場合（契約上出せない情報がある、閉域網で使う）は、待っていても状況は変わりません。

まとめ：次にやること4つ

  1. 自社の情報管理規程と、主要な取引先との契約書を読み返す … 「外部送信が制限された情報」が本当に存在するかを確認します
  2. 法人向けクラウドプランを正式に契約して使い始める … シャドーAIを止め、AIで何ができて何ができないかを社内で体感します
  3. 「クラウドではできなかった業務」を3カ月記録する … オフラインが本当に必要な業務の量が数字で見えてきます
  4. その量を根拠に、オフラインの必要性と規模を判断する

この順番なら、仮にオフラインを導入する場合でも構成と規模の精度が上がります。何より、「導入したが使われなかった」という最悪の結末を避けられます。

導入前の論点整理からご相談いただけます

弊社はオフライン生成AIの導入支援を行っていますが、多くの企業にとってはクラウド型で十分だと考えています。

ご相談をいただいた際も、まず御社の規程と契約、扱う情報の中身をうかがったうえで、「クラウドで足ります」「今の段階では投資に見合いません」という判断も含めてお伝えします。売れないほうの答えであっても、そちらが正しければそう申し上げます。

自社がどちらに当てはまるか判断がつかない、規程を読んでも解釈に迷う、といった段階でもかまいません。

ご相談・お問い合わせはこちら

コラム

AI検査とルールベース検査の違い｜状況別の使い分け早見表つき

by user

AI検査とルールベース検査の違い｜状況別の使い分け早見表つき

この記事の要約
  • 良否を数値や条件式で書ける検査は、ルールベースの領域です
  • 出方が一定しない欠陥・言語化できない判定は、学習ベースの領域です
  • 両方式を工程で組み合わせるハイブリッド構成が有力な選択肢です。解けないときは撮像・照明を見直します

丁寧に見れば時間がかかり、ラインに合わせて急げば見逃しが出る。外観検査の現場では、この二つがなかなか両立しません。判定は検査員の熟練度に左右され、人が代われば基準もぶれていきます。

そこで「そろそろ自動化を」となるわけですが、調べ始めると目に入る情報のほとんどが「AIで解決」に見えてきます。

ところが実際の現場には、AIを使わずに解ける検査があります。逆に、条件をどれだけ書き足しても人の目に追いつかない検査もあります。

当社は実装基板検査ソリューションを提供していますが、その名称にあえて「AI」を入れていません。AIは必要に応じて使う手段であり、判定はAIとルールベースを使い分けるものだと考えているためです。

目次
  1. 使い分け早見表：ルールベースが得意なこと、AIが得意なこと
  2. 結論：決め打ちが遠回り — 違いは「人が設計するか、学習させるか」
  3. 7つの質問で分かる判断フロー
  4. 工程で組み合わせる「ハイブリッド構成」— 処理の並びで見る
  5. どちらを選んでも解けないケース — 先に撮像・照明を直す
  6. よくあるご質問（FAQ）
  7. 次の一歩

使い分け早見表：ルールベースが得意なこと、AIが得意なこと

どちらの方式が向くかは、検査の性質でおおむね決まります。

それぞれの得意な検査から、自社に近い項目を探してください。

ルールベースが得意な検査

良否の基準を、数値や条件式で書ける検査に向いています。正解となる基準が決まっていれば、人が判定条件を設計できます。

例えば、こんなケースです

  • 寸法測定・公差判定校正した幾何演算で数値が出ます。輪郭抽出だけ学習ベースにする併用もあります
  • 部品の有無・欠品位置が固定され、背景とのコントラストが安定していることが前提です
  • 位置ずれ・位置合わせ基準特徴が毎回安定して写れば、再現性の高い位置合わせを設計しやすい方式です
  • 数値で定義できる色判定照明・露出に加え、色の校正まで固定できることが前提です。厳密な色差は色差式（CIEDE2000等）で扱います
  • 基準画像・設計データとの比較（印刷・パターン検査など）正解となる基準が画像やデータで存在する検査は、基準との差分としきい値で設計できます。位置合わせと撮像条件の安定、正常なばらつきの許容範囲の設定、版替え・品種切替に合わせた基準の更新が前提です
  • 判定根拠の説明責任が重い検査（監査・顧客報告）判定に使った数値としきい値をそのまま提示できます
AIが得意な検査

良否の基準を、言葉や数式にしにくい検査に向いています。出方が一定しない欠陥や良品のばらつきを、判定例や良品のみの画像から学習します。

例えば、こんなケースです

  • キズ・汚れ・色ムラなど不定形の欠陥出方が一定しない欠陥に有効です。欠陥が画像に写る撮像設計が前提です
  • 良品に個体差・ばらつきがある対象（食品・天然素材など）固定しきい値では書きにくい良品のばらつきに、学習が合うことがあります。想定するばらつきを学習データに含められることが前提で、ばらつきが大きいほど微小な欠陥の見分けは難しくなります
  • 「熟練者は分かるが言語化できない」判定判定例を集めて学習に落とせます。着手前に、複数の検査員で判定が一致するかの確認が前提です
  • 位置や背景が安定しない対象の有無判定位置が定まらない・部品と背景が同系色といった条件が重なる場面では、学習ベースが有利になることがあります
どちらか一方では決まらないケース
  • 多品種・頻繁な品種切替二択では決まりません。当社は、品種をまたいで共通の特徴を学習できるか（背景・倍率・照明の条件差を揃えられるか）で判断しています
  • 照明・環境が安定しないどちらを選ぶかより、撮像を直すのが先です
  • 変形・反りの検出明暗の画像（2D）に現れにくい場合は3D撮像の検討領域です。3Dデータにも両方式を適用できます

▶ 自社の検査がどちら向きか、切り分けの整理から相談する

結論：決め打ちが遠回り — 違いは「人が設計するか、学習させるか」

外観検査の方式は、対象を見る前に決めてしまうと遠回りになります。

単一の検査項目なら、どちらか一方で完結することもあります。ただし方式は、新しいか古いかではなく対象の見え方で決まります。データの集めやすさ・検査時間・説明責任も判断の条件です。

二つの方式の違いは、良否の判定条件を人が明示的に設計するか、データから学習させるかにあります。

ルールベース検査は、人が判定条件を数値で決める方式です。判定に使った数値としきい値をそのまま提示できます。

AI検査は、判定例や良品のみの画像から特徴を学習させる方式です。着目箇所は示せますが、因果の証明ではありません。

ルールベース検査 人が条件・しきい値を設計 数値で判定 根拠を提示できる AI検査（学習ベース） 画像から特徴を学習 判定 着目箇所は示せるが 因果の証明ではない
図解①：判定の決まり方の対比
ルールベース検査 人が条件・しきい値を設計 数値で判定 根拠を提示できる AI検査（学習ベース） 画像から特徴を学習 判定 着目箇所は示せるが 因果の証明ではない
図解①：判定の決まり方の対比

実際の工程では、1台の装置の中で両方式を組み合わせる構成も設計できます。

7つの質問で分かる判断フロー

自社の検査がどちら向きかは、当てはまる項目にチェックを付けるだけで大枠が見えます。

Q0. 欠陥は画像に安定して写っているか No 撮像見直し型 Yes Q1. 良否の基準を数値・条件式で書けるか 書ける 混在 書けない Q2 ばらつきが小さい Q6 説明責任が重い 書ける項目と 書けない項目が混在 Q2 ばらつきが大きい Q3 判定例を集められる ルールベース先行型 ハイブリッド型 AI先行型 方式を絞った後の設計条件 Q4. 品種数と切替頻度 Q5. 1個あたりに使える検査時間
図解②：7つの質問の判断フロー
Q0. 欠陥は画像に 安定して写っているか Yes No 撮像見直し型 Q1. 良否の基準を 数値・条件式で書けるか 書ける Q2 ばらつきが小さい Q6 説明責任が重い ルールベース先行型 混在 書ける項目と書けない項目が混在 ハイブリッド型 書けない Q2 ばらつきが大きい Q3 判定例を集められる AI先行型 方式を絞った後の設計条件 Q4. 品種数と切替頻度 Q5. 1個あたりに使える検査時間
図解②：7つの質問の判断フロー

まず、前提の1問です。

ここにチェックが付かないなら、方式を比べる前に撮像（カメラ・照明・分解能）の見直しが先です（撮像見直し型）。

チェックが付いたら、次のA・Bそれぞれで、当てはまるものすべてにチェックを付けてください。

A. ルールベース寄りのサイン

B. 学習ベース寄りのサイン

チェックの付き方で、型の目安が分かります。

チェックの付き方型の目安
Q0にチェックが付かない撮像見直し型 — 方式より先にカメラ・照明・分解能を直します
Aに2個以上（Bは1個以下）ルールベース先行型
Bに2個以上（Aは1個以下）AI先行型
AとBの両方に2個以上ハイブリッド型 — 検査項目ごとに方式を分けます

※Bに多くチェックが付いても、Q3（サンプル）が空欄の場合は、先に不良サンプルの確保から検討します。

Q4（品種数と切替頻度）とQ5（1個あたりの検査時間）は、方式を絞ったあとの設計条件です。どの型か迷う場合は、対象を絞った小さな検証で確かめます。

境界となる具体的な数値は対象と工程で大きく変わるため、本記事では示していません。

工程で組み合わせる「ハイブリッド構成」— 処理の並びで見る

実際の検査装置では、得意な処理を工程順に並べたハイブリッド構成が有力な選択肢になります。

  1. 位置決め（ルールベース）：形状マッチングで基準位置を合わせる
  2. 寸法・有無の判定（ルールベース）：数値で書ける項目を先に確定させる
  3. 不定形欠陥の候補検出（AI）：キズ・汚れなど言語化しにくい項目を拾う
  4. 人の最終確認：AIが挙げた候補を人が見て確定する

当社もEMS企業様向けに、スイッチ設定値の読み取り検査を自動化しています。はんだの実装検査では、疑わしい箇所を赤くハイライトして示し、合否の最終判断は人が行う設計です。

当社の実装基板検査ソリューションは、こうした判定の中でAIとルールベースを使い分けています。

AIが合否を決めるのではなく、人の確認を助けるという考え方です。

▶ 関連: 同一部品の個数を数える数量カウントも、対象の写り方に応じて両方式を使い分けています

ハイブリッド構成で外せない設計上の注意

  • 位置決めに失敗した個体はNGにせず、「判定不能」として別に排出します
  • AIの候補だけを人が見る運用では見逃しが人に届きません。過検出側に振るか抜き取り検査を併用します
  • 処理時間は、各段の合計がタクトに収まるかを工程を並べた状態で確認します
  • どの段でNGになったかを記録します。後工程の改善につながる情報になります

どちらを選んでも解けないケース — 先に撮像・照明を直す

そもそも画像に写っていない欠陥は、AIでもルールベースでも検出できません。

分解能が足りない、照明の当て方で欠陥が背景に埋もれている、光沢面の反射で白飛びしている。こうした状態では、どちらのアルゴリズムでも結果は変わりません。単一露光でセンサーが飽和（白飛び）した領域の元の輝度や模様は、通常の後処理から一意には復元できないためです。

当社では、方式を比べる前に撮像・照明を直すのが先だと考えています。

精度が出ないときの原因の切り分けは、AI検査で精度が出ないとき、最初に疑うのは撮像・照明で詳しく解説しています。

よくあるご質問（FAQ）

Q. 今あるルールベースの検査機に、後からAIを足せますか

最初の確認点は、検査に使っている画像を外部に取り出せるかです。取り出せない場合や、圧縮で劣化した画像しか出せない場合は、カメラと照明を別に立てるほうが結果的に早いこともあります。

構成としては、既存の判定はそのまま残し、AIを追加の判定段として並列に流して評価する（シャドー運用）形が、比較的段階導入しやすい進め方です。

Q. AIとルールベース、費用はどちらが高いのでしょうか

金額は対象と規模で変わるため一概には言えませんが、費用の構造が違います。

  • 初期：ルールベースは条件設計・調整というエンジニアリング工数が中心。AIはデータの収集・整理と学習環境の準備が中心です
  • 運用：ルールベースは品種追加のたびに条件の再調整が必要になりやすい方式です。AIも新しい欠陥や品種が増えれば再学習が必要になる場合があります。どちらも「作って終わり」にはなりません

見落とされやすいのは、AI側の費用でデータ収集と運用体制が大きな比重を占めやすい点です。

学習にはGPUを使うと時間を短縮しやすくなります。一方、現場での推論は軽量なモデルであればCPUで成立する場合もあります。これは、要求される検査時間に対する実測確認が前提です。

なお、3Dセンサや複数カメラを使う構成では、ハードウェア費用が大きくなることもあります。

次の一歩

外観検査の自動化は、方式を決めるより、自社の検査がどちらの性質を持つかを切り分けることが先です。

  1. 早見表で、自社の検査に近い状況に当たりをつける
  2. 7つの質問で、どの型に近いかを確認する
  3. 迷う項目が残ったら、切り分けの整理からご相談ください

初回のご相談では、図面や機密情報のご提出は不要です。具体的な可否判断の段階で、必要に応じて画像や図面を個別にご相談します。

検査対象と現在の判定方法、お困りの点をお聞かせいただければ、方式の当たりをつけるところからご一緒します。

お問い合わせフォームはこちら

news/コラム

オフライン生成AI（ローカルLLM）導入前に押さえる基本知識・選び方・社内ルール

by user

「機密情報があるからクラウドの生成AIは使えない。それなら社内に置くオフライン生成AI（ローカルLLM）はどうか」——そう考え始めた段階で、何を押さえておくべきか。

オフライン生成AIの導入は、機器を買って終わりではありません。基本の仕組みを理解し、自社に合う構成を選び、導入前に社内ルールを決めておく。この3つが揃うと、導入後に「使われないまま設備だけが残る」失敗を避けやすくなります。

この記事では、導入支援の実務経験に基づいて、検討前に押さえておきたいポイントを順番に整理します。

この記事でわかること
  • オフライン生成AI（ローカルLLM）の基本の仕組みと、クラウド型との違い
  • 導入直後に「できること」と「できないこと（別途開発の範囲）」
  • 構成・ベンダーの選び方の基本
  • 導入前に決めておきたい社内ルール5つ
  • 導入までの流れと期間の目安
目次
  1. 基本知識①：オフライン生成AIとは何か
  2. 基本知識②：導入直後に「できること」「できないこと」
  3. 選び方：構成は「人数」から、ベンダーは「範囲」で選ぶ
  4. 導入前に決めておきたい社内ルール5つ
  5. 導入までの流れと期間の目安
  6. よくある質問

基本知識①：オフライン生成AIとは何か

POINT

オフライン生成AIとは、AIを外部クラウドではなく社内のサーバーで動かし、社内LANの中だけで完結させる使い方です。機密文書を入力でき、使うほど課金される月額のAI利用料もありません。

ChatGPTのようなクラウド型の生成AIは、入力した内容が社外のサーバーに送信されます。これに対してオフライン生成AI（ローカルLLM）は、AIモデル自体を社内に設置したサーバーで動かすため、データが社外に出ません。外部インターネット接続も不要です。

仕組みの中心は2つです。

  • AIチャット：社内のパソコンからチャット画面を開き、質問応答・文章の下書き・要約などに使います
  • ナレッジ検索（RAG）：取り込んだ社内文書をAIが検索し、引用付きで回答します。該当ファイルの所在も分かります

クラウド型との違いを整理すると、次のようになります。

観点クラウド型の生成AIオフライン生成AI
データの置き場所社外のサーバーに送信される社内LANの中で完結。機密文書も入力できる
費用構造利用人数・利用量に応じた継続課金初期投資型（買い切り）。月額のライセンス費用なし
最新モデルへの追随新しいモデルを比較的早く利用できるモデルの入れ替え作業が必要
運用ほぼ不要設備を持つ運用（電気代・更新・故障対応等）が発生

どちらが優れているかではなく、扱う情報の機密度で決まるのが実務の感覚です。公開情報しか扱わないならクラウド型で十分ですし、図面・仕様書・個人情報・取引先情報を扱うならオフライン型が候補になります。両方を情報の種類で使い分ける「併用」も現実的な選択肢です。

基本知識②：導入直後に「できること」「できないこと」

POINT

初期導入で使えるのは「AIチャット」「社内文書のナレッジ検索」「手元文書の要約」。一方で、権限管理や個別業務への作り込みは初期導入の範囲に含まれないことがあり、ここの理解のズレが導入後の不満の主因になります。

弊社の標準的な初期導入の場合、利用メンバーは導入直後から次のことができます。

  • 社内のパソコンからAIチャット画面を開き、質問応答・文章の下書き・要約などに利用（利用回数の制限なし）
  • 取り込み済みの社内文書に質問し、引用付きの回答と該当ファイルの所在を確認
  • 手元の文書（PDF等）を読み込ませて、要約や内容の確認に利用

一方、次のことは弊社の標準構成には含まれません（別途開発・別途見積の範囲）。ここを導入前に知っておくことが重要です。

  • 部署別の閲覧制限に連動した検索——取り込んだ文書は、初期構成では利用メンバー全員が検索できます
  • ユーザー認証（ログイン）や管理画面（利用状況・活用率のレポート）
  • スキャンPDF（画像のみのPDF）のOCR取り込み
  • 複雑なExcelの構造解析——Excel・CSVのテキスト読み取りはベストエフォート対応で、図形入り・複数シートなど構成が複雑なほど精度は下がります
  • CAD・画像系ファイルの内容解析——取り込みはファイル情報（メタデータ）のみで、所在検索としての利用になります
  • 個別業務への最適化、検索精度の継続改善、外部システム連携

※ 上記は弊社の標準構成に基づく整理です。含まれる範囲はベンダー・プランにより異なるため、見積時に必ず確認してください。

選び方：構成は「人数」から、ベンダーは「範囲」で選ぶ

POINT

ハードウェア構成は「何人で使うか」から逆算する。ベンダーは金額の大小ではなく「初期費用にどこまで含まれているか」を突き合わせて選ぶ。この2つが選び方の軸です。

構成選び｜「何人で使うか」から逆算する

弊社がご提案しているハードウェアは、大きく2タイプです。

タイプ対象人数の目安特徴
小型AI機
（例: NVIDIA DGX Spark）		1台あたり〜10名程度机の上に置ける小型筐体で省スペース。回答の生成速度は控えめ。拡張は台数の追加で、複数台では利用者をグループ分けする運用が前提
GPUワークステーション20名規模の全員利用高性能GPUを搭載し、軽い問い合わせであれば同時10〜20人程度の利用を想定できる水準（弊社見込み）。GPUの増設（最大3基）で処理能力を段階的に拡張できる

選び方はシンプルで、利用人数が少ないのに大きな構成を選ぶと投資回収が長くなり、人数に対して小さい構成を選ぶと応答の遅さで使われなくなります。まず〜10名の小規模構成で導入評価をして、効果を確認してから拡張する段階導入も選べます（1台目の機器や取り込んだ文書・ナレッジは拡張後も引き継げます）。

初期費用の内訳は「ハードウェア」と「初期設定・導入支援」の2つが基本で、構成により数百万円規模からです。このほか、UPS（無停電電源装置）などの付帯設備や、設置場所の電源容量・設置環境の確認が必要になる場合があります。

ベンダー選び｜金額ではなく「含まれる範囲」を突き合わせる

クラウド前提のAIベンダーと、閉域・オンプレミス構築のベンダーでは、必要な経験が異なります。相見積を取る際は、金額の大小より先に次を確認してください。

  • 閉域・オンプレミスでの構築実績があるか——クラウドAPI連携の実績とは別物です
  • ハードウェアの選定から相談できるか——GPUの選定を任せられる相手でないと、過剰投資や性能不足につながります
  • RAG（社内文書の検索）の設計まで踏み込めるか——モデルを置くだけでは社内文書に基づく回答はできず、文書の取り込み・検索精度の調整まで含めた設計が必要です
  • 初期費用に何が含まれ、何が別途か明示されているか——前章の「できないこと」がどちら側かを見積書で確認します
  • 保守が必須か・選択制か——月額保守が必須のベンダーと選択制のベンダーがあります。保守なしで運用した場合どうなるかまで確認しておくと安心です

※ ベンダー選定の詳しい判断基準は、別記事で解説予定です。

導入前に決めておきたい社内ルール5つ

POINT

オフライン生成AIは「機密を入力してよいAI」だからこそ、クラウド型とは違う観点のルールが要ります。導入支援の経験上、次の5つを導入前に決めておくと定着がスムーズです。

ルール1｜取り込む文書の範囲を決める

意外な盲点ですが、初期構成では取り込んだ文書は利用メンバー全員が検索できます（部署別の閲覧制限に連動した検索は別途開発の範囲）。人事・給与・評価など「社内でも見る人を限定したい文書」をいきなり入れると、社内の情報統制が崩れるおそれがあります。「まず全社で共有してよい文書から取り込む」——この一線を導入前に決めておくことをおすすめします。

ルール2｜AIの回答の扱い方を決める

AIの回答には誤りが混ざり得ます。ナレッジ検索の回答には引用（元ファイル）が付くので、「重要な判断・社外に出す内容は、引用元の原本を確認してから使う」「最終確認の責任は利用者にある」という原則を明文化しておきます。1行のルールですが、これがあるだけで「AIが言ったから」という事故のリスクを大きく減らせます。

ルール3｜文書追加の運用担当を決める

日常の運用は、指定フォルダ（AIがアクセスできる場所）に文書を入れるだけ——というのが弊社の標準的な形です。複雑な管理は不要ですが、「どのフォルダを誰が管理するか」「新しい文書をいつ・誰が入れるか」だけは決めておかないと、導入時に取り込んだ文書のまま更新が止まり、半年後には「古い情報しか出てこないAI」になりかねません。

ルール4｜「使ってよい業務」を明示する

ルールというと禁止事項を並べがちですが、おすすめは逆で、「報告書の下書き・過去資料の検索・議事メモの要約に使ってよい」と推奨業務を明示することです。「とりあえず禁止」「使い方は各自の判断」のままでは、せっかくの設備が使われないままになりがちです。推奨業務の明示は、定着の強い後押しになります。

ルール5｜効果測定と窓口を決める

導入の投資判断は「業務時間がどれだけ減ったか」で振り返るのが実務的です。「削減時間を、いつ・誰が・どう集めるか」（月1回の簡単なアンケートで十分です）と、社内の一次窓口を1人決めておきます。技術的な対応（モデルの入れ替え・機能追加・精度改善）はベンダー側が担う分担にしておけば、窓口担当に高度なIT知識は必要ありません（弊社の場合、技術面の対応は内容に応じて別途お見積りのうえ対応します）。

導入までの流れと期間の目安

POINT

弊社の標準的な流れは「相談→文書サンプルでの確認→構成・見積→構築→レクチャー→運用開始」。構築期間の目安はハードウェア納入後およそ1〜2ヶ月です。

  1. 相談・要件整理——何人で使うか、どの文書を読ませたいか、運用は誰が担うかを整理します（この記事の内容がそのまま論点リストになります）
  2. 文書サンプルでの事前確認——取り込みたい文書の代表サンプルで、内容・形式を確認します。「うちの文書で本当に使えるか」をこの段階で見極めます
  3. 構成の選定・見積——人数と用途から構成を決め、含まれる範囲を明示した見積を取ります
  4. 構築・初期設定——ハードウェア納入後、およそ1〜2ヶ月で利用開始が目安です（調達納期により変動します）。AIチャット・ナレッジ検索環境の構築、文書の取り込み・検索精度の調整、社内LAN完結構成の設定までが弊社の標準構成の範囲です
  5. 操作レクチャー・運用開始——基本操作のレクチャーを受け、決めておいた社内ルールとともに運用を始めます

導入後の技術的な対応（モデルの入れ替え・機能追加・精度改善）はベンダーに任せ（内容に応じて別途見積となるのが通常です）、社内は「文書をフォルダに入れる」日常運用に集中する——という分担が、少人数の会社でも無理なく回る形です。

よくある質問

インターネット接続は必要ですか？

いいえ。既存の社内LANに接続して使う構成で、外部インターネット接続は不要です。クラウドAIへデータを送信しない社内完結の構成にできます。

どんな文書を読み込めますか？

テキストを含む文書（PDF・Office文書等）が中心です。Excel・CSVのテキスト読み取りはベストエフォート対応、CAD・画像系はファイル情報のみ、スキャンPDFのOCR取り込みは別途対応——というのが弊社の標準構成の範囲です。導入前に代表サンプルで確認するのが確実です。

社内にIT担当がいなくても運用できますか？

日常の運用は指定フォルダに文書を入れるだけで、複雑な管理は不要です。モデルの入れ替えなど技術的な対応はベンダー側に任せる分担にできるため（弊社の場合は内容に応じて別途お見積りのうえ対応）、窓口担当を1人決めれば運用できます。

何人規模から導入できますか？

〜10名の小規模構成から導入できます。小さく始めて効果を確認し、機器や取り込んだナレッジを引き継ぎながら拡張する段階導入も可能です。

まとめ：導入前チェックリスト

最後に、この記事の要点をチェックリストにまとめます。

  • 扱う情報の機密度から、クラウド型・オフライン型・併用のどれが合うか整理した
  • 初期導入で「できること」と「別途開発の範囲」を理解した
  • 利用人数から構成タイプ（小型AI機／GPUワークステーション）の見当をつけた
  • 見積は金額でなく「含まれる範囲」で比較する準備ができた
  • 社内ルール5つ（取り込み範囲・回答の扱い・運用担当・推奨業務・効果測定と窓口）の考え方を押さえた

導入前の論点整理からご相談いただけます

「自社の場合はどの構成か」「どの文書から取り込むべきか」「社内ルールはどう作ればよいか」。

そうした導入前の論点整理の段階からご相談いただけます。文書の代表サンプルでの事前確認や、構成別の概算のご提示も可能です。売り込みはいたしません。

お問い合わせはこちら

オフライン生成AIのサービス内容は、オフライン生成AIのページでご紹介しています。

news/Uncategorized/コラム/ニュースリリース/プレスリリース

DX挑戦ブログ_第1回

by user

【DX挑戦ブログ 第1回】従業員10人未満・平均年齢55歳の機械工具卸が、AIを入れてみた。不安しかない。

— 有限会社アルプス × MonoStruct合同会社 DX挑戦記 —

はじめに ― 正直に書きます

最初に断っておきます。この記事は、AIを導入して「すごく便利になりました！」という成功事例ではありません。

これは、従業員10人未満・平均年齢55.3歳の有限会社アルプス(https://alps-inc.com)が、AI活用に踏み出したばかりの、まさに今進行中の記録です。うまくいくかどうかも、正直わかりません。

サポートに入っているのは、私たちMonoStruct合同会社。「何がわからなかったか」「どこで止まったか」「何に戸惑ったか」も含めて、きれいごと抜きで発信していきます。

同じような規模の会社で「AIって気になるけど、うちには関係ないかな」と思っている方に、この連載が何かの参考になればと思っています。

アルプスってどんな会社？

有限会社アルプスは、平成5年（1993年）7月31日設立。車業界で30年以上の歴史を持つ会社です。人と人、物と物を繋いできた企業です。

従業員数は10人未満、平均年齢は55.3歳。
現在は、車両工具や内装事業、設計開発などの事業を手がけています。
いわゆる「ITの会社」ではありません。社内にプログラミングができる人はいません。
AIの経験といえば、ChatGPTを少し触ったことがある程度です。

ここが大事なポイントなのですが、これは決して「遅れている」わけではなくて、
日本の小規模事業者のほとんどが同じ状況です。AI導入なんて、どこから手をつけていいかわからない。興味はあっても、日々の業務に追われて後回しにしてしまう。

「来月から考えよう」が半年、1年と続いていく。。。

そんな中で「じゃあ、うちがやってみるか」と手を挙げたのがアルプスでした。

幡谷社長の本音 ― 「人が足りない。でも雇えない」

「小規模事業者は、人を雇いたくても雇いづらい。だからこそ、DXやAIを活用して効率化を進めたいんだ」

とアルプスの幡谷社長

採用を出しても応募が来ない。教育するにも余裕がない。
少ない人数で回しているからこそ、一人ひとりの負担が大きい。これは多くの小規模事業者が直面している、切実な現実です。

そして、もうひとつ。幡谷社長にはこんな想いもありました。

「アルプスがまず先にやってみて、それを見て他の会社が”うちもやってみようか”と思ってくれたらいい」

Claude Codeを入れてみた ― そもそも「ダウンロードの仕方がわからない」

今回導入したのは、Anthropic社が提供するClaude（クロード）。

ただ、ここで正直に書いておきたいことがあります。

幡谷社長いわく、「そもそもClaudeって何なのかがわからない。ダウンロードの仕方もわからない。中小企業や小規模事業者にとっては、そこがもう壁」。

これ、すごく大事な話だと思います。AIに詳しい人からすれば「ダウンロードして使うだけでしょ」と思うかもしれません。でも、普段の業務でExcelとメールくらいしか使わない環境では、「新しいAIツールをPCに入れる」というだけで相当なハードルです。

Claudeは、名前も聞いたことがない、どこからダウンロードするのかもわからない、インストールしたとして何が起きるのかもわからない。

「難しそう」ではなく、「そもそもスタートラインに立てない」という感覚。これが、多くの小規模事業者のリアルだと思います。

MonoStruct合同会社がサポートに入り、Pro版の契約手続きとPCへのセットアップは完了。
ここまでは一緒に進めたので問題なく終わりました。※導入方法に関しては次回以降説明します。
大事なのはこの先です。

よくある話ですが、ツールを導入しただけで満足して、結局使わなくなるケースは山ほどあります。高いソフトを買ったけどExcelで済ませている、みたいな話です。アルプスがその罠にハマらないようにするために、「導入して終わり」ではなく「導入してからが本番」という意識で進めていきます。

目指しているのは「何でも屋AI」― でも、理想と現実は違う

アルプスが最終的にやりたいことは、かなり幅広いです。

秘書的な業務、税理士的な財務サポート、社労士的な人事総務、中小企業診断士的な経営戦略の壁打ち、弁護士的な法務チェック、さらにはM&A、工具事業、内装事業、新規顧客獲得、設計開発まで。要するに、人を雇えない分をAIで補いたいという発想です。

正直に言えば、今すぐ全部は無理です。
理想を語るのは簡単ですが、いきなり全部やろうとすると確実に挫折します。

だからこそ、小さく始めます。

まず最初にやること ― 「ファイルの自動振り分け」から

幡谷社長と話し合った結果、最初の一歩は注文書などの自動振り分けに決めました。

なぜここからはじめるのか？ 理由は単純です。毎日やっている業務で、時間がかかっていて、失敗しても大きな損害がない。つまり、練習台としてちょうどいい。

ここから始めて、うまくいけば見積書や請求書の作成支援へ。さらにその先に、社長の考えをベースにした経営戦略の整理といった、もう少し高度な使い方へと進んでいきたいと考えています。

ただ、計画通りにいくかはわかりません。やってみたら「これは思ったより難しい」となるかもしれないし、「意外とこっちの方が使えるじゃん」という発見があるかもしれない。そのリアルな過程を、この連載で全部見せていきます。

次回予告 ― そもそも、どうやって導入したの？

次回は、Claudeを実際にPCへ導入するまでの流れをお届けします。

「Gitって何？」「PCが対応してなかった」など、やってみて初めてわかったトラブルも包み隠さずレポートします。AI活用の第一歩は、実は「インストール」からもう始まっているんです。

この連載が、同じように悩んでいるどこかの会社の「最初の一歩」につながることを願っています。

執筆：有限会社アルプス(https://alps-inc.com) × MonoStruct合同会社
DX支援に関するお問い合わせ：MonoStruct合同会社（support@mono-struct.com）