生成AI を社内業務に導入するときに情シスが最初に決める 4 項目

こんにちは、AVIATE の Content チームです。

「生成AI、うちでも入れたいんだけど、どこから手を付けるのが正解なんだっけ?」—— 情シスの方とお話ししていると、PoC を始める手前でこの質問が本当によく出てきます。

結論から書くと、ツール選びから入ると後戻りが重くなるので、先に 4 つの設計判断を決めておくとぐっと楽になります。この記事では、2026 年 4 月時点の「AI 事業者ガイドライン第 1.2 版」をふまえつつ、その 4 項目——利用範囲 / データ境界 / モデル選定 / 運用責任——を、実務でつまずきやすいパターンとセットで整理します。想定読者は、SMB 〜 中堅企業の情シス / DX 推進担当の方です。

まず、ツール選びから入らない#

モデル選定を先に決めてしまうと、「このモデルで何をしてよくて、何をしては駄目か」が後から議論されることになり、導入後の修正コストがじわじわ効いてきます。ツールを決めた時点で導入が終わるわけではなく、むしろそこからが本番です。

現場のお話を聞いていて感じるのは、情シスが見落としがちな落とし穴が、だいたい次の 3 つに収束するということ。

ひとつめは、利用範囲が固まらないまま部門ごとに独自運用が乱立するパターン。ふたつめは、「入力したデータが外部に送信されうる」という前提が社内に周知されていないこと。みっつめは、問題が起きたときの責任分界が曖昧なまま運用が始まってしまうケースです。いずれもツール選定だけでは解けず、導入前の「設計判断」として扱う必要があります。

ちなみに、総務省・経済産業省が 2026 年 3 月に公表したAI 事業者ガイドライン第 1.2 版では、AI の活用主体を「AI 開発者 / AI 提供者 / AI 利用者」に分けて、ライフサイクル全体のリスク管理を整理しています。社内で生成AI を使う企業の多くは「AI 利用者」にあたるので、このガイドラインの枠組みと、ここで扱う 4 項目はきれいに対応します。

決めるべき 4 項目の全体像#

まずはざっくりの地図から見てみましょう。

どれも「ツールを入れる前に決めておきたい」設計事項です。次からひとつずつ踏み込んでみます。

各項目の判断軸と、ありがちな落とし穴#

利用範囲 —— 全社解禁の前にスコープを固定する#

利用範囲は、対象部門と対象業務の 2 軸で定義しておくのがおすすめです。全社横断で一気に解禁してしまうと、統制が追いつかないまま個人利用が増えて、学習データや社外送信の扱いがブラックボックスになりがちです。まずは PoC の対象業務と部門を明記して、そこから段階的に広げるほうが、あとから修正を入れやすくなります。

とはいえ、「全社解禁は必ず失敗する」と言い切れるわけでもなく、企業規模や業態によっては、社員が早く触れる環境を作るほうが学習効果が高い場合もあります。大事なのは、範囲を明示したうえで、評価指標と運用責任をその範囲にちゃんと紐付けておくことです。

データ境界 —— 何を入れてよいかを先に書いておく#

「何を学習・保存させるか」を決めないまま導入を始めると、社員が機密情報や顧客データを生成AI に入力してしまい、そこで初めて気付く、という状況が結構な確率で起こります。

データ境界の設計は、入力データの分類(公開情報 / 社内情報 / 機密 / 個人情報)と、ツール側の設定(学習利用の可否、データ保持期間、リージョン)を対応付ける作業に落ち着きます。経済産業省が 2025 年 2 月に公表したAI の利用・開発に関する契約チェックリストは、提供データの利用範囲、AI 生成物の利用条件、不適切なデータ利用のリスクなどを契約時に確認するためのもので、ベンダーと境界を合意するときの実用的な参考になります。

モデル選定 —— 「最新モデル」だけで決めない#

モデル選定は、ベンチマーク上位のモデルをそのまま選んでも業務要件に合わないことが、案外あります。判断軸は、文脈長(議事録・契約書などの長文処理)、出力の安全性、Enterprise 向けのデータ保持、料金、既存システムとの接続性、あたりに分解できます。

「最新モデルを入れれば間違いない」という選び方をすると、モデル更新のたびに再評価が発生して、運用側がだんだん疲弊してきます。軸を固定したうえで複数モデルを並べ、業務別の向き不向きを整理しておくほうが、そのあとのモデル更新への追従がかなり楽になります。

運用責任 —— 情シスに寄せすぎない#

導入後の運用を情シスにぜんぶ集中させてしまうと、事業部側の要望変化にまで手が回らなくなってきます。利用監視・障害対応・規約更新・ユーザーサポートの担当を、情シス / 事業部 / 外部ベンダーのどこに置くのか、導入前に割り振っておくのがおすすめです。

ちなみに、オンプレ LLM を選んだ場合でも、運用責任が自動で解決してくれるわけではありません。ハードウェア保守・モデル更新・ログ管理が社内に残るだけで、「オンプレなら安全」と単純化するのは避けたいところです。

PoC から本番へ進めるためのチェックリスト#

PoC の成否は、導入前に評価指標を決めているかどうかで、かなりの割合が決まります。最低限、次の 4 項目は PoC を始める前に書き出しておくと、評価のときに迷いません。

まとめ —— 設計判断を 1 枚にまとめる#

4 項目のうち、どれか 1 つでも空欄のまま PoC を始めてしまうと、結果が悪かったときに「運用課題の問題なのか、モデル性能の問題なのか」を切り分けられなくなります。

利用範囲・データ境界・モデル選定・運用責任を、箇条書きで構わないので 1 枚にまとめておくのがおすすめです。その 1 枚が、導入から運用までずっと参照できる、最小の設計ドキュメントになります。

業種・職種ごとの具体的な落とし込みは、経理の請求書処理やカスタマーサポートなど、業務別のユースケース記事でこのあと順番に扱っていく予定です。全体像と個別業務の設計判断を両輪で進めると、導入後 1 年の運用コストが、体感でかなり変わります。

導入計画の具体化で迷う場面があれば、Contact からお気軽にご相談ください。