AIセキュリティ対策は、AIで行う業務、扱う情報、接続先、許可する操作を整理するところから始めます。文章の下書きに使う場合と、社内文書を検索してメールを送信する場合では、必要な対策が変わるためです。
生成AIを業務に導入する企業の管理部門・情報システム担当者・部門責任者に向けて、情報漏えいや誤操作につながるリスクと対策、社内AIセキュリティガイドラインの制定手順を解説します。自社で確認するための30項目のチェックリストも用意しました。
運営者情報
AI JOURNALは一般社団法人 日本AI導入支援協会が運営する、日本企業のAI活用支援を目的としたメディアです。記事制作にあたっては、経済産業省「AI事業者ガイドライン」をはじめとする公的機関の公表情報等を参考にしています。内容の正確性には十分配慮していますが、誤りや更新漏れがある場合は、お問い合わせフォームよりご連絡ください。掲載情報は公開日時点のものであるため、最新情報は公式サイト等でご確認ください。
AIセキュリティとは
AIセキュリティとは、AIに入力する情報、AIが参照するデータ、接続先のシステムや操作権限を管理し、情報漏えいや不正な処理などのリスクを抑えるための取り組みです。企業の生成AI・AIエージェントの業務利用では、利用ルールとシステムの設定を組み合わせて考える必要があります。
同じAI製品でも、公開情報から文章を作るだけなのか、顧客情報を検索するのか、メールの送信まで任せるのかによって確認する範囲は変わります。製品名だけで安全性を判断せず、まずは自社でどのように使うかを整理しましょう。
| AIの利用形態 | 業務の例 | 特に確認したいこと |
|---|---|---|
| 社員がチャットへ入力する | 文章作成、要約、アイデア整理 | 入力できる情報、アカウント、契約条件、会話の共有範囲 |
| 社内情報を検索・参照する | 社内FAQ、文書検索、メール・ファイル連携 | 元文書の閲覧権限、検索時の権限確認、連携先 |
| 顧客向けに回答・生成する | 問い合わせ対応、提案書生成 | 顧客ごとの情報分離、回答の確認、悪用への対処 |
| AIエージェントが業務を実行する | 送信、更新、申請、コード実行 | 操作権限、実行前の承認、実行環境の隔離、停止と復旧 |
| 自社でAI基盤を構築・運用する | API連携、独自アプリ、自社サーバーでの運用 | クラウド設定、認証情報、ログ、依存する部品の更新 |
複数の形態が重なることもあります。社内文書を検索して顧客向けの回答案を作り、AIエージェントが送信する仕組みなら、文書へのアクセスと送信操作の両方を管理します。
従来のセキュリティ対策も、AIを安全に使うための土台になります。アカウントは利用者ごとに管理し、対応するサービスでは多要素認証を有効にします。これは、パスワードに加えて認証アプリなど別の手段で本人確認を行う仕組みです。文書やシステムの利用権限は業務に必要な範囲に絞り、異動・退職時には不要な権限を解除します。
OSやアプリの更新は担当者を決めて管理し、セキュリティ上の欠陥を修正する更新が適用されているかを確認します。重要な業務データは定期的にバックアップし、通常の保存先が被害を受けても復旧できるよう、保管先やアクセス権を分けます。保存できたかに加え、実際にデータを戻せるかも確かめておきます。(出典:IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」を基に整理)
【関連記事】AI導入のメリットとデメリットは?AI導入手順と問題点への対策、AI導入支援企業も
生成AIの業務利用で起こる主なセキュリティリスク
AIの利用中に情報がどこへ渡り、誰の権限で処理されるかを追うと、確認すべきリスクが見えてきます。社員による入力だけでなく、文書検索、外部連携、AIによる操作まで含めて把握することが大切です。
入力情報や会話履歴が意図しない範囲に渡る
顧客情報を含む資料をチャットへ入力すると、その情報はAIサービスの処理対象になります。会社が把握していない個人アカウントを使っている場合は、契約条件や会話の共有設定を管理者が確認できるかも問題になります。

ここで区別したいのが、モデルの学習への利用と、データの保存・共有です。「学習に使われない」という条件を確認しても、会話が保存されないことや、追加の連携先に情報が渡らないことまで分かるわけではありません。
例えば、Microsoftの法人向けCopilotに関する公式資料は、プロンプトや回答などを基盤モデルの学習に使わないことと、利用時のやり取りを保存することをそれぞれ説明しています。エージェントを利用する際には、そのプライバシー条件も確認するよう案内しています。Microsoftのデータ・プライバシー・セキュリティ資料
自社で使う製品・プラン・機能ごとに、学習利用、保存期間、削除条件、共有範囲、連携先へのデータ提供を確認しましょう。
社内文書の過剰な共有がAI検索で表面化する
社内文書を検索するAIでは、元の文書が誰に共有されているかが重要です。本来は一部の部署だけが扱う資料を全社員に共有していた場合、その設定がAIの検索対象にも影響します。

Microsoftは、Copilotが利用者の既存のアクセス権に従う一方で、過剰に共有されたコンテンツがリスクを高めると説明しています。AIの導入を機に、SharePointなどにある文書の共有先と実際の業務上の必要性を照合することが大切です。MicrosoftのCopilotセキュリティ資料
また、自社でRAGを構築する場合も権限確認が必要です。RAGは、関連する文書を検索し、その内容を参照して回答を作る仕組みです。検索結果をAIへ渡す段階で、質問した人がその文書を閲覧してよいかを確認する設計が求められます。
外部の文書やメールに含まれる指示でAIが誘導される
AIが読み込むWebページ、PDF、メールなどに指示が含まれ、その指示によって意図しない回答や処理へ誘導されることがあります。この問題をプロンプトインジェクションと呼びます。

例えば、外部の資料を要約するAIが、資料内に紛れ込んだ指示を業務上の命令として扱ってしまう場面が考えられます。利用者が直接入力した文章だけを確認しても、AIが参照する文書に由来するリスクは残ります。
OWASPの2025版の解説では、入力や出力への対処、権限の制限、重要な操作に対する人の承認などを組み合わせる考え方が示されています。プロンプトに禁止事項を書くだけで完全に防げると考えず、AIが操作できる範囲も制限する必要があります。OWASP「Prompt Injection」
AIエージェントが必要以上の操作を実行する
AIエージェントにメール送信やデータの変更を任せると、誤った判断や外部からの誘導が、実際の業務システムへの操作につながる可能性があります。どこまで影響が広がるかは、接続したツールと与えた権限によって変わります。

例えば、メールの要約だけに使うAIに送信や削除の機能まで与えると、業務に不要な操作が可能になります。必要な機能と権限に絞り、送信や削除など影響の大きい操作は、対象と内容を人が確認して承認する設計を検討しましょう。
OWASPは、過剰な機能・権限・自律性を「Excessive Agency」として整理しています。AIに注意事項を伝えることに加え、接続先のシステム側で許可する操作を限定することが重要です。OWASP「Excessive Agency」(2025版)
企業のAIセキュリティ対策を進める手順
対策を実行するには、確認事項ごとに「誰が調べるか」「どの設定を変えるか」「何をもって完了とするか」を決めます。利用部門だけでは判断できない契約・権限・技術の論点を、担当者や支援会社に渡せる形へ整理していきましょう。
利用する業務と情報の流れを整理する
最初に、AIを使いたい業務を一つ選びます。その業務について、利用者、AI製品とプラン、入力する情報、参照する資料、出力の利用先を書き出します。すでに社員が使っている場合は、会社が許可した環境と個人アカウントの利用状況も確認しましょう。
例えば、問い合わせメールから返信案を作る業務なら、メールに含まれる顧客情報、回答の根拠にする社内資料、返信案の保存先が確認対象になります。送信まで任せる場合は、メールシステムへの接続と送信権限も加わります。
情報の流れを整理すると、入力前に削除できる情報や、接続しなくても業務を進められるシステムを検討できます。この段階の成果物は、利用業務・情報・接続先・管理者をまとめた一覧です。
契約条件を確認し、入力と共有のルールを決める
利用する環境を特定したら、そのプランと機能に適用される契約・データ管理の条件を確認します。基本のチャット機能に加えて、外部検索、追加アプリ、コネクターを使う場合は、それぞれの取扱いを調べます。確認した資料のURLと日付も残しておきましょう。
そのうえで、業務ごとに入力できる情報の条件を決めます。公開済みの資料、社内限りの情報、顧客情報などを区分し、必要な情報だけを入力する形へ整理します。利用者が判断できるよう、実際の業務に沿った入力例を示すことがポイントです。
会話や生成したファイルの共有先もルールに含めます。入力の可否だけを決めて終わらず、作成後に誰へ渡してよいかまで明確にすることで、利用者が迷う場面を減らせます。
文書とツールの権限を絞り、重要な操作に承認を設ける
社内文書を連携する場合は、対象文書の所有者、共有先、外部への共有設定を見直します。異動や退職によって不要になった権限も、AI側と連携先側の両方で変更できるようにしておきます。
AIエージェントを使う場合は、利用できるツールを列挙し、閲覧・送信・変更・削除を分けて、業務に必要な操作だけを許可します。重要な操作の承認では、承認する人が宛先、変更対象、実行内容を具体的に確認できることが大切です。
自社でアプリを構築するなら、APIキーの保管と失効、データベースの公開範囲も設計対象です。AIが生成した出力をHTML、データベースへの命令、プログラム実行などに使う際は、用途に応じて内容を検証する処理を設けます。
実際の権限でテストし、停止と復旧の方法を確かめる
設定後は、権限が異なるテスト利用者と架空のデータを使い、想定した制限が働くかを確認します。社内検索なら、閲覧を許可した資料が取得できることに加え、許可していない資料が取得されないことも確かめましょう。
エージェントでは、承認していない操作が実行されないことや、外部文書に不審な指示を含めた場合の挙動を検証します。通常の操作が成功するかだけでなく、拒否すべき入力や操作を拒否できるかも確認することが重要です。テストの条件と結果は記録しておきます。
問題が起きたときの停止方法も、導入前に確かめます。AIと外部サービスの連携を止める担当、権限や認証情報を失効させる担当を決め、データの変更・削除を伴う業務では復旧方法を試しておきましょう。
担当者と相談先を決め、変更に合わせて見直す
運用開始後に利用者が迷ったとき、新しい機能を使いたいとき、情報の誤入力が疑われるときの相談先を決めます。利用部門の担当者、システム管理者、契約や情報管理を判断する担当者の役割を明確にしておくと、確認すべき相手が分かります。
ログには、誰が何を実行したかを調べるために必要な情報を残します。一方で、ログ自体に機密情報を残しすぎないよう、記録内容、閲覧権限、保管期間も決める必要があります。
連携先や権限、モデル、機能を変更した際は、影響するテストと利用ルールを見直します。利用者への教育も業務に合わせて更新し、新しい使い方が以前の条件から外れていないかを確認していきます。
社内AIセキュリティガイドラインの制定手順
社内AIセキュリティガイドラインには、利用できるAI、扱える情報、承認者、禁止事項、点検方法、事故時の対応を定めます。守るべき事項は社内規程として位置付け、判断に迷ったときの相談先まで明確にします。厳格に管理するには、承認条件を満たさない利用を止められる権限と、条件を満たしたことを確認できる記録が必要です。
以下の制定手順と具体的な承認条件・点検頻度は、IPAやAIセーフティ・インスティテュート(AISI)の資料を踏まえた社内ルールの設計例です。公的機関が全企業に一律に義務付けた基準ではありません。自社の業務、扱う情報、法令・契約上の要件を確認し、経営者が採用するルールを決定します。
責任者と適用範囲を決める
経営者は、規程の制定・改定を承認する責任者と、運用を管理する担当者を指名します。利用部門は業務上の必要性を説明し、情報システム担当は設定と技術面、法務・情報管理担当は契約とデータの取扱いを審査する役割とします。利用を止める権限と、停止後の再開を承認する権限も、担当者名とともに記録します。兼務する場合も、申請者だけで自分の申請を承認しない仕組みにします。
適用対象は役員・従業員に加え、派遣社員や委託先による自社業務での利用まで定めます。対象となるAIには、チャットサービス、API、社内検索、AIエージェント、ブラウザや業務ソフトに組み込まれたAI機能も含めます。無料サービスや試験利用、個人アカウントによる業務利用も審査の対象とします。既存の情報セキュリティ規程や委託先管理規程との整合を確認し、適用関係を明記します。(制定体制の参考:IPA「中小企業の情報セキュリティ対策ガイドライン 第4.0版」第2部、AISI「Chief AI Officer ガイドブック」)
情報を分類し、利用を認める条件を定める
各部門からAIの利用業務を集め、入力・参照・保存する情報を分類します。例えば、公開情報は承認済みの環境で利用可能、社内限定情報は用途と共有範囲を審査して条件付きで許可、営業秘密や個人情報は通常利用での入力を禁止する、といった基準を定めます。営業秘密や個人情報を扱う業務は別途審査し、利用目的、法令・契約への適合、必要な管理措置について承認が得られるまで利用を開始しません。分類が分からない情報も、管理担当が判断するまで入力を保留します。
承認は製品名だけで出さず、「業務・契約プラン・機能・情報区分・利用者・連携先」の組み合わせで管理します。学習利用、保存期間、削除方法、再委託先への提供、共有設定を記録し、判断に必要な条件が未確認なら承認しません。試験は公開情報や架空のデータで行い、実データの利用承認を代用しないことも明記します。入力情報の取扱いは、規約と設定の両方で確認します。(参考:IPA「AI利用者のためのセキュリティ豆知識」)
禁止事項と例外承認の手続きを文書化する
未承認AIへの業務情報の入力、管理外の個人アカウントの業務利用、無許可のアプリ・コネクター追加、パスワードやAPIキーのプロンプトへの入力を禁止事項にします。入力だけでなく、ファイル添付、社内文書の検索連携、会話の公開共有も対象とします。生成した文書の社外提供や、送信・削除・支払いなどの重要な操作には、内容と対象を確認する人を指定します。実行に承認が必要な操作は、人の承認前に動かない設定を条件とします。
例外が必要な場合は、理由、対象業務、情報、代替の保護措置、残るリスク、利用期限、停止・復旧方法を申請書に記載します。審査担当と承認責任者の記録がそろうまで利用せず、口頭承認や事後承認で開始しません。期限が来たら利用を停止し、継続は再審査します。法令・契約上の禁止事項は社内承認で解除できません。禁止した利用の代わりに使える承認済み環境と、申請窓口・回答期限も用意します。(参考:IPA産業サイバーセキュリティセンター中核人材育成プログラムの成果物「生成AIおよびAIエージェントを安全に活用するための手引書」第2章)
管理設定とテスト結果をそろえ、正式に承認する
規程案を作ったら、管理担当は文章のルールをシステムの設定で実施できるか確かめます。多要素認証、利用者と管理者の権限分離、外部共有、検索対象、操作承認、ログの取得を確認し、設定記録とテスト結果を残します。必要な制限を製品側で実施できない場合は、機密情報を扱わせない、連携機能を外すなど利用範囲を縮小し、承認条件を満たすまで業務利用を認めません。
経営者または規程上の決裁権者は、規程本文、承認済みAIの一覧、申請・例外承認の様式、事故対応手順、点検計画を一式で確認します。文書には版番号、制定日、施行日、主管部署、承認者、次回見直し日を記載します。規程の制定承認と個別業務の利用承認は分け、規程ができたことだけを理由に全社利用を開始しない運用とします。
教育と理解確認を終えてから利用権限を付与する
施行前に、利用者が実際に扱う資料を想定した教育を行います。入力できる情報、添付してはいけない資料、生成物の確認方法、迷った場合の相談先、事故時の連絡方法を、架空のデータを使って確認します。禁止事項を読ませるだけでなく、業務上の場面で許可・保留・禁止を判断できることを確かめます。
管理担当は受講日、受講した規程の版、理解確認の結果を記録し、完了した利用者に必要な権限だけを付与します。未受講者や確認が終わっていない利用者には権限を付与しません。委託先も対象範囲に応じて確認し、すでに利用中の場合は承認条件を満たす環境へ移行させます。異動時は担当業務に合わせて再確認し、退職・契約終了時はAIと連携先の権限を失効させます。
点検の頻度と事故時の対応を決める
点検計画には、確認対象、担当者、頻度、証拠となる記録、是正期限を書き込みます。運用例として、毎月は利用者・管理者権限と期限付き承認を照合し、四半期ごとに利用部門の申告と利用記録を比べて未承認利用を点検します。情報漏えいや重要な操作に関する警告は定期点検まで待たず、管理担当へ通知する設定にします。高いリスクがある業務は監視の頻度を上げ、未是正の問題は責任者へ報告します。承認条件の不備が是正期限を過ぎても解消しない場合は、該当業務の利用を停止します。
記録するのは、利用者、日時、利用した機能、承認内容、実行結果など調査に必要な情報です。閲覧できる担当者と保存期間を規程で定め、保管期限後の削除まで管理します。入力・出力の全文を無制限に集めず、ログに機密情報が残る場合の保護と、事故調査に必要な記録の保全も定めます。
誤入力や漏えい、不審な動作が疑われた利用者は、追加の操作を止め、事実確認の完了を待たずに指定窓口へ報告するルールとします。管理担当は対象のAI・連携を停止し、必要に応じて認証情報を失効させ、ログや経緯を保全します。原因、影響範囲、必要な外部報告、対策後のテスト結果を責任者が確認し、再開を承認するまでは停止を維持します。
変更のたびに再審査し、規程を改定する
サービスの契約条件、モデル、機能、入力する情報、連携先、操作権限が変わった場合は、従来の承認を継続できる範囲を再審査します。利用者による変更は事前申請とし、提供事業者側の変更で承認条件を確認できなくなった場合は、影響する機能の利用を保留します。事故や点検で問題が見つかった場合も、利用条件と規程を見直します。
定期改定の例として、規程全体を少なくとも年1回見直し、改定の理由、変更点、承認者、施行日を記録します。利用者が参照する規程は最新版に統一し、旧版と過去の承認記録は履歴として管理します。変更したルールの周知と必要な再教育まで完了させ、点検結果と是正状況を経営者へ報告することで、制定後も管理を続けられます。(継続管理の参考:AISI「Chief AI Officer ガイドブック」3.3)
公開事例から学ぶAIの情報管理
企業の導入体制と、実際に報告された設定不備は、自社の確認事項を考える材料になります。事例で確認できる取り組みや問題を、自社の組織とシステムに当てはめてみましょう。
パナソニックコネクトの相談体制と利用ルール
パナソニック コネクトは、2025年9月4日公開のインタビューで、法務・知財部門と情報セキュリティ部門が連携する「データ利活用支援チーム」と、同チームを中心に作成した「生成AI利活用ガイドブック」について説明しています。パナソニック コネクトの公式インタビュー
同社の説明では、AIの倫理や安全性に関する問いに会社として一元的に対応する体制が、活用を進める土台になっています。利用者向けのルールと、判断に迷う場合の相談体制を組み合わせている点が参考になります。
自社で取り入れるなら、専任組織を設ける前に、業務上の必要性を説明する人、情報管理を判断する人、設定を変更する人を決めるところから始められます。兼務であっても、相談を受けてから誰が判断するかを明確にしておくことが大切です。
DeepSeekの公開データベースから考える基盤の管理
Wizは2025年1月29日、DeepSeekに関連するデータベースへ認証なしでアクセスでき、チャット履歴や秘密情報を含むログが露出していたと報告しました。同じ報告では、Wizの通知後に公開状態が解消されたことも説明されています。Wizによる調査報告
この事例から確認したいのは、AIの背後にあるデータベースやログの管理です。学習への利用条件を確認するだけでなく、保存先に認証があるか、外部へ公開されていないか、ログに秘密情報を残していないかも点検する必要があります。
自社でAI基盤を構築する場合は、開発担当とインフラ担当の間で確認範囲を分担し、設定記録を残しましょう。この報告だけで、第三者による悪用の範囲や実被害を断定することはできません。
AI導入前に使える30項目のセキュリティチェックリスト
チェック項目ごとに「対応済み」「未対応」「未確認」「該当なし」を記録し、確認担当と期限を決めて使いましょう。「対応済み」には設定やテストなどの確認記録を添え、「該当なし」には対象外とした理由を残します。
チェックの数だけで導入可否を判断せず、扱う情報や操作の影響を踏まえて、先に解消すべき問題を決めることが重要です。未確認の項目は、安全性を確認できた項目に含めません。
CSVには、確認結果・担当者・期限・メモを記入する欄があります。Excelなどで開いて、自社の確認状況を整理できます。
| 分類 | 確認項目 | 残す記録 |
|---|---|---|
| 利用状況と責任 | 利用中・試験中のAI、利用部門、業務、管理者を把握しているか | AI利用一覧 |
| 利用状況と責任 | 会社が許可した環境と個人アカウントでの利用を把握しているか | 承認済み環境と例外の一覧 |
| 利用状況と責任 | データを分類し、業務・環境ごとの入力条件を決めているか | データ分類と利用条件 |
| 利用状況と責任 | 導入判断、設定変更、運用、事故対応の責任者を決めているか | 役割分担表 |
| 利用状況と責任 | 迷った場合の相談先と、新しい利用方法の申請手順があるか | 利用・例外申請手順 |
| 契約と情報の流れ | 対象プラン・機能の学習利用、保存期間、削除条件を確認したか | 確認日付きの仕様・契約条件メモ |
| 契約と情報の流れ | 入力から出力まで、データが渡るサービスと保存先を把握したか | 情報の流れをまとめた図 |
| 契約と情報の流れ | 外部検索、追加アプリ、コネクターのデータ取扱いを確認したか | 連携先と適用条件の一覧 |
| 契約と情報の流れ | 会話、ファイル、生成物の共有範囲を確認したか | 共有設定の記録 |
| 契約と情報の流れ | 入力前に情報を削減・置換できる業務を検討したか | 業務別の入力例 |
| アカウントと社内文書の権限 | 製品が対応する認証強化と管理者アカウントの保護を適用したか | 認証設定の記録 |
| アカウントと社内文書の権限 | 入社・異動・退職時に、AI側と連携先側の権限を変更する手順があるか | 権限変更手順 |
| アカウントと社内文書の権限 | 社内文書の過剰共有、外部共有、所有者不明の文書を確認したか | 権限見直し一覧 |
| アカウントと社内文書の権限 | 社内検索・RAGで、検索者の権限に応じて取得対象を制御しているか | アクセスを許可する条件の設計書 |
| アカウントと社内文書の権限 | 権限が異なる利用者で、許可されていない情報を取得できないことを試したか | 権限テスト記録 |
| AIエージェントと外部連携 | エージェントが利用できるツールと操作を列挙したか | ツール・操作一覧 |
| AIエージェントと外部連携 | 閲覧、送信、変更、削除を分け、必要な操作だけを許可したか | 操作ごとの権限設計 |
| AIエージェントと外部連携 | 重要な操作では、宛先・対象・内容を確認して承認できるか | 承認画面と承認記録 |
| AIエージェントと外部連携 | 外部文書やメールを取り込む際の誘導リスクを評価したか | 入力経路と対処方針 |
| AIエージェントと外部連携 | 記憶や会話履歴を、利用者・案件に応じて分離しているか | データの分離設計 |
| アプリとシステム基盤 | APIキーや認証情報が、画面・ソース・不要なログに露出しない管理方法があるか | 保管・更新・失効手順 |
| アプリとシステム基盤 | データベース、ストレージ、管理画面の公開範囲を確認したか | 構成点検記録 |
| アプリとシステム基盤 | AI出力をHTML・SQL・コマンドなどに渡す前に、用途に応じた検証を行うか | 処理の設計書とテスト記録 |
| アプリとシステム基盤 | ライブラリ、拡張機能、モデルの導入元と更新方法を管理しているか | 依存する部品と更新方法の一覧 |
| アプリとシステム基盤 | 必要に応じて実行回数・費用・時間・外部接続先を制限しているか | 制限値と監視方法 |
| 運用と改善 | 誰が何を実行したかを調査できるログを、必要な範囲で残しているか | ログの設計書 |
| 運用と改善 | ログに含まれる機密情報、閲覧権限、保管期間を管理しているか | ログ管理条件 |
| 運用と改善 | 問題発生時にAI・連携を止め、権限を失効させる方法を確認したか | 停止手順 |
| 運用と改善 | 変更・削除が発生する業務で、復旧方法を試したか | 復旧記録 |
| 運用と改善 | 導入時と主要な変更時に、権限・不正入力・誤実行のテスト、教育、改善を行うか | 評価・改訂記録 |
AIを導入する業務を一つ選び、確認事項を整理しよう
AIセキュリティ対策に着手するときは、まず一つの業務について、使いたいAI、扱う情報、接続先、許可したい操作を一枚にまとめましょう。そこへ、確認できた条件、未確認の項目、確認担当、次に判断することを書き加えます。
この整理があれば、利用部門と情報システム担当者で相談する際も、外部の専門会社へ設定や開発を依頼する際も、必要な対策を具体的に検討できます。専門会社へ相談する場合は、自社の構成に近い実装経験や、設定後にどのようなテストを行うかを確認することが大切です。






コメント