← ブログ一覧へ

「そのAIのセキュリティは大丈夫か？」の壁を越える

投稿者 Nana Tokiwa
「そのAIのセキュリティは大丈夫か？」の壁を越える

サマリー

  • 生成AI利用率は55%超まで伸びた一方、本番運用まで進む企業は3割程度
  • 壁の正体は技術ではなく「説明できるリスク管理」の不在
  • 越え方は「リスク分類 → データフロー設計 → 制度整備」の3ステップ
  • 厳格な大企業は「外部アカウント自体がNG」。閉域＋自社ユーザー基盤で対応
  • セキュリティレビューで確認すべき5点を、設計・実装構築で満たす

生成AIの利用率は確実に広がっています。総務省の令和7年版情報通信白書では何らかの業務で生成AIを利用している企業の割合は55.2%に達しました。一方で、全社的な生成AI導入（本番運用）は20〜35%にとどまるとの推定もあります。

「試す会社」は半分を超えたのに「回す会社」はまだ3割程度。このギャップのど真ん中にはセキュリティとガバナンスの壁があります。

壁の正体は「技術」ではなく「説明責任」

「セキュリティは大丈夫か？」という問いは実は技術の質問ではありません。「リスクを説明できる人と仕組みが社内にいるか」という組織の質問です。 セキュリティ部門や情シスがAI導入を止めるのはAIを否定したいからではなく「インシデントが起きた時に答えられる状態」を作れないからです。リスクを定量化できず、責任を取れる体制がないまま稟議を通すことはリスクが高すぎて誰にもできません。

この壁を構成しているのはおおよそ4つの不安です。

  • 情報漏えい：機密情報・個人情報が外部LLMに送られる。顧客データ、未公開の設計・財務情報、ソースコードが学習やログに残る
  • 誤出力：ハルシネーション（AIの誤った回答）が社内外へ拡散する。誤った回答を根拠に意思決定する、公開文章に不正確な記述が混入する
  • 規制・コンプライアンス：法規制やガイドラインへの適合が確認できない。個人情報保護法、秘密保持契約、AI事業者ガイドラインなどの要求事項
  • シャドーAI：従業員が把握されないまま外部ツールを利用する。承認プロセスを経ずに機密情報が外部サービスへ持ち出される

実例：厳格な大企業は「アカウント登録した時点でアウト」

実際の案件でセキュリティに厳しい日本の大企業からこう言われたケースがあります。

「外部のAIサービスを扱う会社にアカウントを登録した時点でデータが外に出てしまうので許可できない。」

外部AIサービスのアカウントを社員に「持たせる」ことはその瞬間からいつでも機密データを投入できる経路を開くことになります。入力されたデータがベンダーのログや学習に使われる可能性も契約だけで完全には排除できません。 ポリシーやガイドラインの説明をいくら重ねても拒否されるのはこの判断が「技術の話」ではなく「どこまで信用を外部に預けるか」という信頼境界の話だからです。この大企業の線引きはリスク管理としては合理的です。

こうした企業では外部AIサービスの利用は「申請して通過しないとアカウントは使えない」という申請制になっています。そして、その申請がそもそも通らない——外部サービスの申請NGな企業が実はかなり多いのが現状です。クラウド型AIの安全性をいくら説明しても、申請プロセスそのものが通らない以上その方向では前に進めません。

この場合クラウド型AIの安全性を説得する方向では壁は越えられません。実際に選ばれたのが閉域（クローズドな社内環境）で、会社が管理できるユーザー基盤を自前で構築するアプローチでした。 外部ベンダーのアカウントを一切発行せず、認証・認可・ユーザー管理・監査ログのすべてを自社内に閉じます。社員がAIを使うときの「アカウント」が、最初から会社の管理下にある構成です。

  • 外部アカウントを発行しない：従業員のID・認証がすべて自社のユーザー基盤に閉じる
  • データが社外に出る経路を構造的にゼロにする：外部に接続しない閉域でLLMを実行する（オンプレ／プライベート環境）
  • 監査が最初から機能する：誰が・いつ・何を入力したかが、最初から自社のログとして残る

「認証の境界線をどこに置くか」 これがセキュリティが厳しい企業にとっての本丸です。この大企業の判断基準は明確でした。「自社が管理しているAWSの中で管理するならOK。Google認証（外部ID基盤）はNG」という線引きです。 クラウドそのものがダメなのではなく、認証・ユーザー管理を自社の管理下に置けるかどうかが判断の分かれ目になっていました。

つまり「自社のAWSアカウントの中で自社のID基盤から認証して動かすAI」なら許容範囲に入る、ということです。外部ベンダーのID管理に依存せず、アカウントの発行・停止・監査をすべて自社が握れる構成なら、セキュリティ部門は「大丈夫」と言えます。 外部ベンダーにID管理を預けるのではなく自社で持つことで「セキュリティかAIか」の二者択一は実は存在しないことがわかります。LLMは自社管理の環境でも動きます。データ保全とAI活用は、技術ではなく「組み合わせの設計」の問題なのです。

セキュリティレビューで確認すべき5点

弊社はこの5点を「後から設定するオプション」ではなく前提として自社プロダクトに設計・実装し構築しています。

1.データの保存場所：業務データは原則ローカルか。外部送信の条件は誰が決めるか

2.テナント境界：部門・顧客・事業単位で記憶が分離されるか

3.実行の隔離と停止：危険な操作はサンドボックスで実行されるか。きちんと止められるか、破棄できるか

4.認証・ID管理：既存SSOと統合できるか。退職時の権限剥奪は既存フローで足りるか

5.監査：誰がいつ何をしたか、説明可能な形で記録が残るか

セキュリティ部門を「止める人」から「設計する人」へ

一番大事だと言えるのはセキュリティ部門の役割を変えることです。「使わせないための審査」を任せるのではなく、「安全に使うための設計」を任せると彼らはAI導入の最強の味方になります。

経営層の役割は「セキュリティは大丈夫か？」という問いに「大丈夫」と答えるための体制に投資することです。セキュリティとガバナンスはコストではなくAIを本番運用するための前提投資だと位置づけましょう。 AI導入、活用やAI事業の新規立ち上げでセキュリティの壁を越えられないお悩みがある企業の方は課題の整理やセキュリティの壁をどう乗り越えたら良いかをご相談できる弊社の30分無料相談をぜひ活用ください。ご相談だけでもOKです。

まとめ

  • 壁の正体は「説明できるリスク管理」の不在。技術の問題にすり替えない。
  • セキュリティをゲートからレールへ。止める人を設計する人に変えると壁は越えるべき対象から「走るための基盤」に変わる。
  • 最も厳格な企業は「閉域＋自社ユーザー基盤」外部アカウントを発行しない設計なら、説得ではなく構造で壁を越えられる。

出典リスト（記事末尾用）

  1. 総務省『令和7年版 情報通信白書』第2節「企業におけるAI利用の現状」https://www.soumu.go.jp/johotsusintokei/whitepaper/ja/r07/html/nd112220.html
  2. AI Japan Index「生成AI企業導入率ダッシュボード2026」https://ai-japan-index.com/genai-adoption-dashboard/
XLinkedIn