LinkT&B 編集部
業務AIをクラウドと社内のどちらで動かすかは、扱う情報、必要な応答時間、利用人数、保守体制から決めます。社内設置でも権限管理は必要で、クラウドでも契約や設定によって情報の扱いは異なります。
この記事の内容
業務へAIを取り入れるとき、外部のクラウドサービスを使うか、社内の環境で動かすかが検討されます。しかし、先に実行場所を一つへ決めると、扱いたい情報や必要な処理に合わない構成になることがあります。公開資料の整理と、非公開の設計資料の分析では、条件が違うからです。
処理先の検討では、入力する情報、必要な品質、許可された取扱範囲、運用の負担を合わせて見ます。本記事では、情報の分類から候補の比較、試行での評価、障害時の扱いまで、業務AIの実行環境を選ぶ考え方を整理します。
実行環境を比較するための入力条件
| 項目 | 確認すること | 判断に使うもの |
|---|---|---|
| 情報 | 個人情報・設計資料・公開資料 | 外部送信できる範囲 |
| 負荷 | 同時利用者と文書の量 | 待てる時間と繁忙時の処理 |
| 運用 | 更新・障害・バックアップ | 担当者と年間費用 |
まず、入力する情報の範囲を決める
AIへ渡すのは、質問文だけとは限りません。添付文書、検索する社内資料、会話の履歴、処理の途中で取得する情報も含まれます。公開された情報、社内で共有する情報、限定した担当者だけが扱う情報、送信してはいけない情報を分け、どの範囲で利用できるかを定めます。
例えば、公開済みの製品説明から紹介文を作る作業と、未公開の図面から設計上の課題を調べる作業では、同じ処理先を選べるとは限りません。社内文書の要約でも、添付に顧客情報や認証情報が混ざっている場合は、表題だけで区分を決めないようにします。
情報の取扱範囲が分からない入力は、推測で外部へ送らず、確認する流れを用意します。利用者の注意だけに頼るのではなく、選択できる処理先や添付の扱いを、会社の方針とシステム側の条件へ対応させることが重要です。
実行場所と、業務の条件を対応させる
クラウド、社内サーバー、管理された外部環境には、それぞれ運用条件があります。どこなら扱えるかは、所在地や機器の所有者だけでは決まりません。契約、データの保存や利用、アクセス権限、管理者の関与、接続方法などを確認し、対象の情報に適合する候補を選びます。
| 候補 | 検討する場面 | 比較する条件 |
|---|---|---|
| 社内の実行環境 | 社内で扱う必要がある情報 | 権限、保守、処理能力、外部通信 |
| 管理された外部環境 | 許可した委託先での処理 | 契約、隔離、管理者アクセス、監査 |
| 外部クラウドサービス | 利用方針に適合する情報・処理 | 保存・利用条件、権限、品質、費用 |
| 処理を見合わせる | 条件を満たす候補がない入力 | 不足条件と、再開までの確認事項 |
この表は選定のための分類です。特定の環境が安全である、当社がすべての構成を提供済みであるという意味ではありません。使うソフト、モデル、接続先、設定の組み合わせで、対象業務に必要な条件を検証します。
社内で動かす場合にも、管理が必要
ローカル実行なら、入力の処理を社内に置く構成を検討できます。ただし、端末やサーバーの利用者、ログの保存先、バックアップ、更新、外部通信が管理されていなければ、社内に置いたという事実だけで取扱いが適切とは言えません。文書を閲覧できる人と、AIでその文書を検索できる人の権限も揃えます。
品質と速度を、実際の仕事で評価する
モデルの名称や機器の性能表だけでは、業務で使えるかを判断できません。要約、翻訳、文書検索、コードの支援など、対象の仕事を絞り、入力の長さ、文書の形式、同時利用、応答を待てる時間を決めます。利用者が結果を確認する時間も評価へ含めます。
例えば、社内文書への質問に答える用途なら、答えの読みやすさだけでなく、正しい文書を参照したか、根拠を示せるか、資料にないことを断定していないかを見ます。権限のない文書から情報が出ないことも、品質とは別の必須条件として確認します。
試行では、代表的な正常ケースだけでなく、情報が足りない質問、古い資料と新しい資料が混在する場合、長い文書、取得できない文書も試します。正しい答えが出た例だけを実績としてまとめず、失敗した条件と、人の確認が必要な範囲を残します。
評価用の質問には、期待する回答と参照すべき資料を用意します。言い回しの好みだけで比較せず、必要な情報が含まれるか、資料の版が正しいか、分からない点を分からないと返すかを見ます。結果の修正にかかった時間を測ると、生成から確認までの業務全体を比較できます。
障害時に、未許可の処理先へ移さない
社内の環境が混雑した、外部サービスが応答しない、時間切れになったときに、別の環境へ自動で送る設計は注意が必要です。性能上は便利でも、元の入力を扱える権限が別の環境にあるとは限りません。代替先を使う場合も、情報の区分と許可条件を維持します。
条件を満たす候補がなければ、待機や処理停止を選べる構成にします。利用者へ、処理できなかった理由と次に必要な確認を示します。接続できたこと、処理を開始したこと、回答が得られたことを分け、失敗や未検証の結果を正常終了として扱わないようにします。
また、入力や添付、許可範囲を変更した場合は、処理先の判定を見直します。一度の確認を、別の入力や後日の操作まで無制限に適用しないことが重要です。再試行で二重に送信されないか、処理履歴で確認できるようにします。
途中で文書検索や別のシステムとの接続を行う構成では、最初の質問が公開情報でも、取得した文書が社内情報になる可能性があります。入力時の分類だけで処理先を固定せず、途中で扱う情報の範囲を設計に含めます。新しい接続先や機能を追加する際にも、同じ取扱条件を点検します。
ログ・保存・確認者を設計する
業務で使うには、どの入力区分を、どの環境で、どの版のモデルが処理したかを追える情報が必要です。一方、監査のために入力本文をすべて保存すると、その保存先に新しい機密情報が集まります。目的に必要な履歴と、本文を残す範囲・期間を分けて決めます。
AIの出力は、社内の判断や対外的な説明へ使う前に、人が根拠と内容を確認する運用を定めます。金額、固有名詞、技術仕様、契約条件など、誤りの影響が大きい項目は特に確認が必要です。誰が確認し、修正し、最終利用を決めるかを、業務の流れへ組み込みます。
NISTの生成AIリスク管理資料は、生成AIについて、誤った内容の生成、データプライバシー、情報セキュリティなどのリスクを整理しています。実行場所の選定に加え、対象用途での評価と継続した管理が必要だと考えるための参考になります。参考：NIST Generative Artificial Intelligence Profile。
費用は、回答一件の料金だけで比べない
外部サービスでは、利用量、契約、データ連携、運用の費用を確認します。社内環境では、機器、電力、更新、保守、管理担当者の作業を含めます。モデルの更新や資料の再登録が必要になったときの負担も、継続利用の費用として考えます。
さらに、生成した回答を確認・修正する時間を加えます。応答が速くても、誤りや根拠不足の確認に時間がかかるなら、業務全体では短縮につながらないことがあります。同じ仕事を同じ評価条件で試し、品質、所要時間、管理負担を並べて比較します。
小さな試行で確認したい項目
- 対象業務、利用者、入力・添付・参照資料の情報区分
- 使える処理先と、それぞれの取扱条件・アクセス権限
- 正確さ、根拠、待ち時間、人の確認に関する評価基準
- 失敗時の停止・再試行、ログ、保存期間、更新・保守の担当
試行は、取扱いを確認した情報と限定した用途から始めます。画面が表示できる状態、試験入力で動いた状態、実際の業務で確認できた状態を分けて記録します。未検証の接続先や機能を、利用できる前提で展開しないようにします。
運用を始めた後は、モデル、設定、参照資料、接続先の変更を管理します。更新で応答や検索結果が変わる場合があるため、代表的な評価を再実施し、確認した版を残します。導入時のデモだけで評価を終えず、業務で使える条件を維持する担当と見直しのタイミングを決めます。
まとめ：情報と業務条件から、処理先を選ぶ
業務AIの実行環境は、入力する情報と、必要な品質・運用条件から選びます。社内か外部かという場所だけで判断せず、権限、保存、障害時の動作、人の確認までつなげて評価すると、会社として利用できる範囲を具体的に定められます。
技術支援のご案内
LinkT&Bでは、業務で扱う情報とタスクを整理し、AIの実行環境やシステム連携の構成を検討するご相談を承っています。詳しくはIT・AIソリューション事業、個別相談はお問い合わせをご覧ください。
関連記事
ローカルLLM・業務AI導入支援の相談
社内で扱う情報と対象業務を確認し、AIの構成、検証方法、導入後の運用を提案します。現在お使いの環境からご相談いただけます。