生成AIの業務利用が急速に広がる一方で、情報漏えいや不適切な出力といったリスクへの対応に悩み、「使いたいが怖い」「使わせたいがルールが決められない」というジレンマを抱える組織は少なくありません。こうした課題に対し、AIを安全に使うための枠組みとして注目されているのが「ガードレール設計」です。

「ガードレール設計とは何か」「何を守り、何を許容するのか」「現場の生産性を落とさずに安全性を担保するために必ず押さえるべき要素は何か」

本記事では、こうした要素を具体的に示した上で、情シスが主導すべきポリシー策定やツール選定、運用ルールの整備といった実務上の役割についても整理します。

なぜ今「ガードレール設計」なのか──AIを“安全に使わせる”ための枠組み

生成AIの業務利用が広がる中、情報システム担当者は矛盾する二つの要請の板挟みとなりがちです。

一つは、現場が生産性につなげられるよう反発や混乱を防ぎながら、導入を進めなければならないという課題です。もう一つは、情報漏洩やハルシネーション、シャドーAIなどのリスクへ徹底的に対策しなければならないという課題です。

この板挟みを解消するための考え方が、「ガードレール設計」です。

【関連記事】

シャドーAIとは？生成AIの業務利用によるリスクについて解説

「導入期」は終わった──生成AI利用の4大リスク

まず押さえておきたいのは、生成AIの業務利用がすでに“試す段階”を過ぎているという現実です。『令和7年版情報通信白書』（総務省）によると、日本で生成AIサービスを「使っている（過去使ったことがある）」と回答した人は2024年度で26.7％と、2023年度（9.1％）の約3倍に急増しており、2026年現在、この割合はさらに拡大していると見られます。

引用元：『令和7年版情報通信白書』（総務省）

生成AIの利用が当たり前になったことで、リスクは“起きるかもしれない懸念”ではなく、“実際に起きている問題”になっています。その代表例は、大きく4種類に分けられます。

1.情報漏えいリスク：社員が顧客情報や未公開の社内情報を対策なく、生成AIに渡してしまうケースです。

2.幻覚（ハルシネーション）リスク：AIによるもっともらしい嘘のリスクです。存在しない法律の条文、架空の統計、事実と異なる仕様──これらを確認せずに使用すれば、誤情報が組織の意思決定に紛れ込みます。

3.シャドーAIリスク：利用禁止の指示が出ても、個人アカウントでこっそり使うことを防ぐことは困難です。組織として管理できていないAI利用が広がれば、インシデント発生時の対応も困難になります。

4.ガバナンス不全リスク：「誰が・いつ・何のためにAIを使ったか」が記録されていなければ、問題発生時に原因を追跡できません。部門ごとにバラバラな利用が進めば、組織のIT統制は大きく崩れます。

これらのリスクの対策として、まず取られる手段が、AI利用ガイドラインの策定です。「機密情報を入力しないこと」「出力は必ず人間が確認すること」──こうした注意事項を文書にまとめ、社員に周知する。この対応は最低限必要なものですが、現実には十分に周知することは難しく、逐一確認する余裕がない組織も多いため、リスク管理として不十分になる場合がほとんどです。

ガードレール設計とは何か──運用ではなく、構造で安全を担保する

生成AIのガードレール設計とは、道路のガードレールのように、社員が安全な利用範囲から逸脱しそうになったときに止める仕組みを「運用ではなく構造で用意する」アプローチのことです。

ガードレールは、運転時に意識されることはなく、いざというときに大きな事故を防ぐ仕組みです。AIのガードレール設計も、同じ思想に基づきます。

社員がAIを使うこと自体は認めた上で、組織の方針から逸脱しそうになったとき──機密情報が入力されそうなとき、問題のある出力が生まれたとき、許可されていないツールが使われようとしたとき──に、それを止めたり、検知したり、記録したりする仕組みを設けておく。

「この出力は安全か」「誰が何を使ったか」といった問いに対して、人の注意力や運用ルールではなく、構造として対策するのが、ガードレール設計の本質です。

【関連記事】

生成AIのリスク、リスクマネジメントのポイント

ガードレール設計は何でできているのか──「入力・出力・権限」の3層で考える

ガードレール設計の考え方を押さえたところで、具体的な設計手法に話を進めましょう。

ガードレールが機能するためには、AIの利用プロセスを「入力（AIに何を渡すか）」「出力（AIの回答をどう扱うか）」「権限とログ（誰が何を使ったか）」の三つの層に分けて、それぞれに対策を設ける必要があります。

それぞれの層を順に見ていきましょう。

第1層：入力制御──AIに入れてよい情報を定義する

入力制御とは、社員がAIに与える情報の範囲を定め、機密情報の流出を構造的に防ぐ仕組みです。

ガードレール設計の思想に基づけば、まず目指すべきは「社員が判断しなくても、機密情報がAIに渡らない状態」です。その中心となるのが、技術的な仕組みによる自動制御です。

具体的には、DLP（Data Loss Prevention）ツールとの連携による入力内容の自動スキャン、個人情報や機密キーワードの自動マスキング、禁止語・禁止パターンの検知とブロックといった手段が挙げられます。これらを組み合わせることで、社員が意識しなくても、一定の範囲の機密情報はAIに到達する前に遮断される状態を作ります。

ただし、現実には技術的フィルタだけで完全に防ぐことは難しいという点も押さえておく必要があります。文脈によって機密かどうかが変わる情報、フィルタをすり抜ける言い回し、新しい種類の機密情報──こうした「構造の隙間」は常に存在します。

この隙間を補完するために必要になるのが、情報区分に基づく判断基準の整備です。「公開可」「社内限定」「部門限定」「機密」のように情報の機密区分を統一し、どの区分までAIに入力してよいかを明示しておく。技術で自動的に防げない領域について、社員が迷わず判断できる基準を用意するということです。

もう一つ、ツールの管理も構造的な対策として有効です。承認済みAIツールのリストを整備し、利用可能なツールそのものを絞ることで、シャドーAI化を防ぎます。どのツールが社内のどのデータにアクセスできるかまで含めて整理しておくことが理想です。

第2層：出力検査──リスクの高い出力が業務に流れない仕組みを作る

出力検査とは、AIが生成した内容を社外や次の業務工程に流す前に、リスクのある出力を検知・遮断する仕組みです。

この層でもまず考えるべきは、構造として防げる部分を最大化することです。

技術的に対応可能な領域として、例えば以下のような自動チェックの仕組みが挙げられます。

• NGワード・禁止表現の自動検知（差別的表現、未確認の断定表現、社内の機密用語が出力に含まれていないか）
• 出力に含まれるURLや出典の存在チェック
• フォーマットの自動検証（所定のテンプレートからの逸脱がないか）

これらを業務フローに組み込むことで、明らかに問題のある出力は人間の目に触れる前に弾くことができます。

ただし、出力検査には入力制御と異なる難しさがあります。それは、AIの出力が「正しいかどうか」──事実との整合性や文脈上の適切さ──を機械的に判定することには限界があるという点です。ハルシネーションの本質的な問題は、出力が「もっともらしく見える」ことにあり、これを自動で完全に検知する技術は現時点では確立されていません。

したがって出力検査では、自動チェックで防げない領域に対して、人間による確認工程をどこに・どの程度設けるかの設計が重要になります。

設計の基本は、用途に応じて確認の厳しさに濃淡をつけることです。例えば、以下のようなレベル設定を考えてみてください。

• 社内メモや個人の作業補助：自動チェックを通過した時点で利用者自身の確認に委ねる
• 顧客向け文書や対外公開情報：自動チェックに加えて人間による承認工程を設ける
• 意思決定資料やコード変更といった高リスク用途：担当者のレビューを挟む

ここで重要なのは、人間の確認工程も可能な限り構造化しておくことです。「確認してください」という曖昧な指示ではなく、確認すべき観点（事実の裏取り、数値の整合性、表現の適切さなど）をチェックリストとして明示し、業務フローに組み込みましょう。

第3層：権限・ログ管理──逸脱を許さない構造と、追跡可能な記録を整える

入力と出力の対策を整えても、「誰が何をしたか」を把握できなければ、問題が起きたときに原因を追跡できません。権限管理とログ収集は、第1層・第2層を支える土台であり、シャドーAIとガバナンス不全リスクへの直接的な対策です。

この層は、3層の中で最も「構造的な対策」の性格が強い領域です。権限設定やログ収集は、仕組みとしてシステムに組み込むものであり、社員の判断や注意に依存しません。

権限管理では、全社員に同一の利用範囲を与えるのではなく、部門・役割・業務内容に応じて利用レベルをシステム上で分けることが基本です。

• 一般社員：文章要約・アイデア整理など低リスク用途
• 情シス・開発部門：API連携や社内データ利用を条件付きで許可
• 経営層・管理職：対外公開や意思決定用途でAIを利用する場合は、追加承認を要件とする

「必要なことだけを、必要な範囲で許可する」という最小権限の原則がここでも適用されます。重要なのは、この権限設定がシステム側で強制されることです。「このツールにはアクセスできない」「この機能は使えない」という制約が技術的に実装されていれば、社員がルールを知らなくても逸脱は起きません。

3層はバラバラでは機能しない──ポリシー・技術・運用の三位一体

ここまで3つの層を個別に見てきましたが、各層の中でも繰り返し現れた構造があります。それは、技術的な仕組みを主軸に据えつつ、技術だけではカバーしきれない領域をポリシーと運用で補完するという設計思想です。

技術とは、入力フィルタ、出力チェック、権限設定、ログ監視などの仕組みのこと。それに対し、ポリシー（何を守り、何を許容するかの方針）と運用（承認フロー、ログレビュー、ルールの見直しサイクル）を組み込み、実態に合わせて技術を適用し続けるところまで含めて「ガードレール設計」といえるのです。

情シスが「最小構成」から始めるガードレール設計──段階導入の実務ロードマップ

ガードレール設計を入力制御・出力検査・権限とログ管理の3層に分解しました。

しかし、そのすべてを完璧に設計する準備をしていては、生成AIの普及スピードやシャドーAIのリスクが高まる昨今にはそぐいません。重要なのは、完璧な設計を目指すことではなく、最小限の構成でまず動かし、利用実態を見ながら段階的に整備していくことです。

そこで、情シスが現実的に着手できるロードマップを三つのフェーズで見ていきましょう。

フェーズ1：まず「ツール」と「台帳」を押さえる（導入初期）

最初に取り組むべきは、利用可能なAIツールの定義と、台帳による利用状況の可視化です。前述の3層すべてを同時に立ち上げる必要はありません。まずはツールを限定し、その上で、誰が何を使っているかを把握できる状態を作ることが、最小構成の出発点になります。

承認済みツールリストの策定

まずは、組織として利用を認めるAIツールの一覧を作成します。

その際、データの保存・学習ポリシーが明示されているか、企業向けプランで管理機能が提供されているか、利用ログが取得可能か、など具体的な選定基準もドキュメント化しておきましょう。基準が明文化されていれば、現場から「このツールは使えないのか」と問い合わせがあったときにも、根拠をもって回答できます。

入力ルールの最低ラインの設定

次に、入力に関する最低限のルールを定めます。フェーズ1の段階では、すべての情報区分を細かく定義する必要はありません。まずは「入力してはならない情報」のうち、最もリスクの高い群を明確にします。

具体的には、個人情報（氏名・住所・マイナンバーなど）、顧客から預かった非公開情報、未発表の経営情報──これらをAIツールに入力しないことを、全社共通のルールとして定めます。

利用台帳による可視化

続いて、利用状況を把握するための台帳を整備します。高度なログ基盤をいきなり構築する必要はありません。最初の段階では、どの部門がどのAIツールを使っているか、どのような用途で利用しているかを一覧化できれば十分です。

この台帳は、次のフェーズでログ収集の設計に進む際の基礎情報になります。同時に、現場でどのような使い方が広がっているかを情シスが把握すること自体が、シャドーAIの抑止につながります。

フェーズ2：出力検査と権限設計を段階的に積み上げる（運用安定期）

現場のAI利用実態を台帳やヒアリングから把握し、リスクの高い用途を特定します。前述の通り、対外公開コンテンツの作成、意思決定資料への活用、顧客対応文書の生成などは、出力の誤りが組織的な影響に直結する高リスク用途です。

これらの用途については、人による確認・承認を挟むフローを設計します。一方、社内向けの作業補助やアイデア整理など、影響範囲が限定される用途については、自己確認で完結させる運用を維持します。

この線引きを明確にすることが、「全部に承認をかけて現場が止まる」失敗パターンを避けるポイントです。

権限の段階設計

権限管理も、このフェーズで具体化します。フェーズ1では全社一律のルールで運用していた部分を、部門・役割に応じた利用レベルに分けていきます。

まず読み取り系の用途（検索、要約、翻訳など）を広く許可し、書き込み系の用途（対外発信、データ更新、コード生成など）は段階的に権限を広げていく──この順序を守ることで、リスクを抑えながら利用範囲を拡大できます。

ログ収集の仕組み化

フェーズ1では手動管理だった部分を、このフェーズでは仕組みとして整備します。企業向けのAIツールであれば、管理コンソールから利用ログを取得できるものが増えています。誰が・いつ・どのツールを利用したかを自動的に記録できる状態をつくりましょう。

まずは利用頻度・利用ツール・利用部門の傾向を把握できるレベルから始め、必要に応じて記録の粒度を上げていくのが現実的です。

フェーズ3：定期的な見直しと全体最適化（継続改善期）

ガードレール設計は、一度作って終わりではありません。AIツールの進化、組織の利用実態の変化、新たなリスクの出現に応じて、定期的に見直す必要があります。

ルールと実態のギャップを定期点検する

フェーズ1～2で整備したルールが、半年後も現場の実態に合っているとは限りません。新しいAIツールが登場すればツールリストの更新が必要になり、業務でのAI活用が深まれば入力ルールの見直しも求められます。

定期点検の頻度としては、四半期に一度の見直しが一つの目安です。点検の際には、ログデータから利用傾向の変化を確認し、現場へのヒアリングでルールと実態のズレを把握します。ガードレール設計が形骸化する最大の原因は、「つくったときの状況」を前提にしたルールが更新されないまま残り続けることです。

インシデント対応手順の整備

ガードレールを設けても、それを超える事態は起こり得ます。予想外のインシデントが発生したときの対応手順を、あらかじめ定めておく必要があります。

具体的には、インシデント発生時の報告ルート、初動対応の手順（利用停止・影響範囲の特定）、関係部門（法務・広報・経営層）への連携フロー、再発防止策の策定プロセスを整理します。AIが関与したインシデントは原因の切り分けが複雑になりやすいため、フェーズ2で整備するログ収集によって「何が起きたか」を追跡可能な証跡が残っていることが、対応の速度と精度を左右します。

ガードレール設計の成熟度を段階的に引き上げる

3つのフェーズを通じて強調したいのは、ガードレール設計は「完成形」を一度に目指すものではないということです。

情シスに求められるのは、「完璧なルールを最初からつくること」ではなく、「小さく始めて、実態に合わせて育てていく設計力」です。AIの利用が広がり続ける限り、ガードレールもまた進化し続ける必要があります。その継続的な改善を主導できるのは、組織全体のIT環境を見渡せる情シスをおいてほかにありません。

ガードレール設計は、AI活用を現場に定着させるための手段と考えよう

何を守り、何を許容するかを先に決め、入力・出力・権限とログの3層で守る仕組みをサイクルを回して強固にしていく──それが、「ガードレール設計」の本質です。

完璧な統制を最初から目指す必要はありません。ツールの棚卸しから始め、最小構成を実装し、実態に合わせて更新していく。その積み重ねが、現場の生産性を守りながら組織全体のAIリスクを許容可能な範囲に収める体制につながります。

こうした体制作りにおいて、情シスは「安全な活用を成立させる設計者」としての役割を期待されます。その役割を果たすためにも、本記事のロードマップをぜひ活用してください。