セキュリティ/権限/ログ：業務データを扱うときの注意点｜AI業務ソフトが“止まる前”に決めておきたいこと

1.はじめに

AIを業務ソフトに組み込もうとすると、意外なところで話が止まります。
それは「精度」ではなく、「セキュリティ」です。

PoC（検証）の段階では、試しに動けば満足してしまいがちです。ところが本番になると、急に現実が追いかけてきます。社内の人たちが気にするのは、「AIが賢いかどうか」よりも、「その仕組みが安全かどうか」です。

• 誰が、どのデータを見られるのか
• AIが参照した資料は何か
• どんな入力がされ、どんな出力が出たのか
• 万一間違ったとき、原因を追えるのか
• そもそも、社外にデータが漏れないのか

こういった問いに、答えられる必要があります。

この記事では、AI業務ソフト開発で必ず出てくる「セキュリティ／権限／ログ」の考え方を、現場で揉めやすいポイントを中心に、読み物として分かりやすく整理します。

2. 「セキュリティ」は“技術”よりも“設計”で決まる

セキュリティというと、暗号化やWAFやゼロトラスト…といった難しい言葉が並びがちです。
もちろん技術も大事ですが、業務ソフトで一番重要なのは「設計」です。

言い換えると、どのデータを、誰が、どの目的で扱えるようにするのか。
これを決めない限り、技術は選べません。

AI機能が絡むと、余計にややこしくなります。たとえば、社内ナレッジ検索（RAG）を作る場合、単に検索できれば便利な反面、「検索できる＝見られる」という状態になってしまうと、情報漏えいのリスクになります。問い合わせの自動分類でも、メール本文が機密情報を含むことは珍しくありません。

だからこそ、セキュリティは後付けではなく、最初に枠組みとして考えるのが安全です。

3. 権限設計でつまずくのは「AIが横断検索する」から

業務ソフトの権限管理は、実は従来でも難しいテーマです。
AIが入ると何が変わるかというと、横断検索が当たり前になることです。

従来の業務システムは「担当者は担当のデータだけ見る」「部署は部署の範囲だけ見る」という分け方がしやすい。ところがRAGや類似案件提案のような機能は、複数の資料や案件を横断して候補を出します。そのとき、候補に見えてはいけないものが混ざったらアウトです。

ここで大切なのは、「AIに渡す前に、そもそも見せてよい範囲に絞る」という発想です。
AIの前に、権限でフィルタする。これはとても重要です。

たとえば、次のような設計になります。

• 部署ごとに見える資料の範囲を分ける
• 特定の顧客案件は担当者・管理者だけ見える
• 人事・給与・契約など機密カテゴリは対象外にする
• 閲覧はできないが存在は見えるといった曖昧な状態は避ける

もちろん会社の事情によって例外は出ますが、基本は「見せないものは最初から検索対象にしない」ほうが運用が簡単で、事故も減ります。

4. ログは「監視のため」ではなく「後から説明できるため」にある

ログというと、監視や不正検知のイメージが強いかもしれません。
でも業務ソフトで重要なのは、どちらかというと「説明責任」です。

業務の現場では、こういうことが起きます。

「この判断、なんでこうなったんだっけ？」
「誰がいつ変更した？」
「AIが出した候補、根拠は何？」
「その返信文、何をもとに作ったの？」

このときログがないと、原因を追えません。原因が追えないと、現場は怖くて使わなくなります。つまりログは、AIの誤りを責めるためではなく、安心して運用するための保険です。

AI業務ソフトの場合、とくに残しておきたいのは「AIが何を見て、何を返したか」という流れです。RAGなら参照元の資料、問い合わせ分類なら根拠となった文、OCRなら抽出結果と修正履歴。こういった履歴が残るだけで、現場の心理的ハードルが下がります。

5. 事故が起きるのは「データ」と「人」の境目

セキュリティ事故は、悪意のある攻撃だけで起きるわけではありません。むしろ多いのは、日常の運用の中で起きる小さなズレです。

たとえば、こんなケースです。

PoCで使っていたテストデータのつもりが、いつの間にか本番データが混ざっていた。
権限の設定が甘く、別部署の資料が検索結果に出てしまった。
AIが生成した文章をそのまま送ってしまい、機密情報が混ざっていた。
退職者のアカウントが残っていて、アクセスできる状態だった。

これらは高度な攻撃ではなく、「運用の穴」から起きます。だからこそ、技術的な防御だけでなく、運用の設計が重要になります。

誰が、何を、どこまでやるか
たとえば「AIの出力は必ず人が確認してから送る」「重要データの閲覧は必ずログが残る」「例外が起きたらこの手順で切り戻す」など、ルールとして決めておくと事故が減ります。

6.本番で求められるのは「安心して使える仕組み」

AI業務ソフトは、便利になればなるほど、社内で使う人が増えます。使う人が増えるほど、権限も例外も増えます。結果として、最初は小さな仕組みだったはずが、いつの間にか会社の重要インフラになります。

そのとき必要なのは、最初から完璧なセキュリティではなく、
「会社の運用に合わせて安全に育てられる」ことです。

だから、最初の段階で無理に網羅しなくても構いません。ただし、最低限「この仕組みはどう安全を担保するのか」という方針だけは、PoCの時点で持っておくと本番化がスムーズになります。

7. スクラッチ開発が向く理由：権限とログは“会社ごとに違う”から

業務データの扱いは、会社ごとのルールや事情が色濃く出ます。

• 部署構成が違う
• 顧客案件の扱いが違う
• 監査や内部統制のレベルが違う
• 既存システムとの連携構成が違う

この違いがある以上、権限やログの正解も会社ごとに変わります。
汎用ツールだけで吸収しきれない部分が出るのは自然なことです。

スクラッチ開発の強みは、まさにここです。AI機能を入れつつ、会社の運用に合わせて「誰が何を見られるか」「何を残すか」「例外時にどう戻すか」を設計できます。

セキュリティは足し算ではなく整合性なので、業務ソフト全体を見て組み込めるほうが事故を減らしやすいのです。

8. まとめ：セキュリティ・権限・ログは「使うため」にある

AI業務ソフト開発で、セキュリティはブレーキではありません。
むしろ、現場が安心して使うための土台です。

• 権限は、AIが横断検索するからこそ最初に設計が必要
• ログは、監視よりも「説明できる安心感」が目的
• 事故は運用の境目で起きるので、ルールと仕組みが大事
• 会社ごとの事情に合わせて設計できると、定着が進む

AIを業務に入れるなら、便利さと同じくらい、「安心して使える形」を意識することで、PoC止まりを避けて本番運用に進めます。

9. 次の一歩

「どのデータを扱うか」から一緒に整理できます

セキュリティ設計は、いきなり技術の話から入ると難しく感じます。
まずは「どの業務で」「どのデータを扱い」「誰が使うか」から整理すると、
やるべきことが見えてきます。

• 権限設計（部署・役職・案件単位）
• ログ設計（何を残すと安心か）
• AI出力の扱い（確認・承認フロー）
• 既存システム連携時の注意点

こうした論点を、PoC→本番まで見据えてまとめ、業務に合った安全なAI業務ソフトとして設計をご提案します。お気軽にご相談ください。