AI開発では、まず精度や機能に関心が向き、セキュリティや個人情報の扱いが後回しになりやすい。しかし、AIは社内文書、顧客情報、業務データなど、扱う情報の範囲が広い。後回しにすると、本番直前で「このデータは外部に出してよいのか」「ログはどこに残るのか」といった問いが噴出し、設計のやり直しになる。
本記事では、セキュリティや個人情報を後回しにするリスクを発注者の視点で整理し、発注前に確認すべき項目と開発会社への質問を示す。専門的な情報セキュリティの知識は不要である。発注者として「どの情報が、どこに、どう残るのか」を確認できれば十分である。セキュリティは精度や機能の後に足すものではなく、最初の設計に含める論点として扱う。後回しにするほど、本番直前の手戻りは大きくなる。
結論：AIに渡す情報の保存先、学習利用、ログ、契約を先に確認する
AI開発でセキュリティを後回しにすると、本番直前にデータの扱いで設計を戻すことになる。GXOが発注前に確認するのは、個人情報・機密情報の区分、外部サービスへの送信可否、データ保存先、学習利用の有無、操作ログ、契約上の責任分界である。
- 情報を公開情報、社内限定、機密性の高い情報に分ける
- 入力データが保存される場所、運用主体、準拠法を確認する
- 学習利用しない条件、ログ保存期間、漏えい時の対応を契約で見る
「安全です」という説明だけでは足りない。データがどこに残り、誰が検証できるかまで具体化する必要がある。
OUTCOME BLUEPRINT
AI/DX投資の前に、成果KPIと発注条件を整理しませんか？
補助金、SaaS選定、開発見積、PoCの前に、業務要件・費用レンジ・RFP・合格条件を成果起点で整理します。
なぜ後回しになりやすいのか
セキュリティや個人情報の検討が後回しになるのは、次のような理由による。
- PoCやデモの段階では、サンプルデータで動かすため問題が見えにくい
- 「まず動くものを」と進めるうちに、データの扱いの議論が先送りされる
- セキュリティは精度や機能に比べて、効果が見えにくい
- どの情報が機密・個人情報にあたるか、社内で整理されていない
後回しにした結果、本番でいざ実データを使う段階になって、扱ってよい範囲やデータの保存先が問題になり、計画が止まる。
発注前に確認しておきたいセキュリティの論点
国や地域の名前で「ここは不可」と判断するのではなく、次の観点で確認するのが実務的である。どこの事業者かではなく、データがどう扱われるかで判断する。
- データ保存先：入力したデータや生成物が、どこに保存されるか
- 運用主体：そのデータを誰が管理・運用するか
- 準拠法：契約やデータの扱いが、どの国の法律に基づくか
- 監査可能性：データの扱いやログを、後から確認・検証できるか
- 学習利用の有無：入力したデータが、外部のモデル学習に使われないか
これらが曖昧なまま発注すると、個人情報保護や社内規程との整合を、本番直前に検証し直すことになる。
FREE DOWNLOAD
AI/RAG導入後のKPIと改善運用、先に設計しませんか？
PoCで終わらせず、利用率・精度・削減工数・改善バックログまでOutcomeOpsで回す設計を確認できます。
後回しにした場合に表面化する問題
| 論点 | 後回しにすると起きること | 発注前に確認すること |
|---|---|---|
| 個人情報 | 扱ってよい範囲が本番で問題化 | どのデータが個人情報か整理する |
| 機密情報 | 社外に出してよいか判断できない | 機密区分と取り扱いルールを決める |
| データ保存先 | 保存場所が社内規程と不整合 | 保存先・運用主体・準拠法を確認 |
| ログ | 誰が何を見たか追えない | ログの取得範囲と保存期間を決める |
| 権限 | 見せてよい範囲が曖昧 | データ・機能ごとの権限を整理 |
| 学習利用 | 入力が外部学習に使われる懸念 | 学習に使わない契約条件を確認 |
| 監査・契約 | 検証も責任も追えない | 監査可能性と契約条項を確認 |
これらは発注前に方針を決めておけば、本番直前の手戻りを避けられる。
機密度に応じてデータの扱いを分ける
セキュリティを理由にすべてを一律に厳しくすると、使い勝手が下がり、結局AIが活用されない。現実的なのは、情報の機密度に応じて扱いを分けることである。たとえば、次のような区分が考えられる。
- 公開してよい情報：すでに社外に公開している内容。外部サービスでも比較的扱いやすい。
- 社内に閉じたい情報：社外秘の業務情報。保存先や学習利用の条件を確認したうえで使う。
- 特に機密性の高い情報：個人情報や、漏えい時の影響が大きい情報。扱う場合は、保存先・権限・ログ・契約を慎重に設計する。
この区分を最初に決めておくと、「どの業務から、どのデータで始めるか」を判断しやすい。機密度の低い業務から導入し、扱いに慣れてから機密性の高い領域へ広げる進め方は、リスクを抑えながら効果を出すうえで有効である。
また、判断の軸を「どこの国の事業者か」に置くと、本質を見誤ることがある。重要なのは、データがどこに保存され、誰が運用し、どの法律に基づき、後から検証できるかである。同じ事業者でも、契約や設定によってデータの扱いは変わる。発注前に、これらを具体的な条件として確認しておくと、本番直前の手戻りや、社内規程との不整合を避けられる。セキュリティは「導入後に足す」ものではなく、最初の設計に含めるものとして扱いたい。
発注前に確認すべき項目
- AIに渡すデータのうち、個人情報・機密情報にあたるものを整理したか
- それぞれのデータを外部のサービスに送ってよいか、社内ルールを確認したか
- 入力データや生成物の保存先・運用主体・準拠法を確認したか
- 入力データが外部のモデル学習に使われない条件か確認したか
- 誰が何を操作・閲覧したかのログを残す要件を入れたか
- データ・機能ごとの閲覧/操作権限を整理したか
- データの扱いを後から検証できる（監査可能性）か確認したか
- 情報漏えい時の責任分界や対応を、契約で確認する予定があるか
開発会社に確認する質問
| 質問 | 確認したいこと |
|---|---|
| 入力したデータはどこに保存されますか | データ保存先と運用主体 |
| 入力データは外部のモデル学習に使われますか | 学習利用の有無 |
| 操作・閲覧のログはどこまで残せますか | 監査可能性 |
| データや機能の権限はどう設計しますか | アクセス制御 |
| 個人情報の扱いは契約でどう定めますか | 契約上の責任 |
| データの扱いを後から検証できますか | 監査・説明責任 |
「安全です」という言葉だけでなく、保存先・学習利用・ログ・契約という具体で答えられるかを確認したい。発注時のチェック観点はAI開発の発注チェックリストとAI-SBOMも参考になる。
GXOに相談する前に整理するとよい情報
- AIに使わせたいデータの種類と、その中の個人情報・機密情報
- 社内のデータ取り扱いルール（持ち出し、保存先などの規程）
- 業界・取引先から求められるセキュリティ要件があるか
- ログや監査に関する社内の決まり（内部統制など）
- すでに使っている、または検討しているAIサービスがあれば、その内容
扱う情報と社内ルールが見えると、「どこまで外部サービスを使い、どこを社内に閉じるか」を現実的に設計できる。
これらが整理されていなくても相談は可能である。扱うデータの中で「特に守りたい情報」が見えていれば、その機密度に合わせて、使い方とデータの扱いを一緒に設計できる。
参考にした外部観点
AI開発のセキュリティでは、個人情報、機密情報、ログ、権限、契約を具体的に確認する必要がある。個人情報保護委員会のFAQは個人情報の取り扱いを確認する入口になり、OWASP Top 10 for Large Language Model ApplicationsはLLMアプリケーションのセキュリティリスクを整理している。
発注前には、個人情報を含むデータ10件、ログ保存30日以上、3ヶ月ごとの権限棚卸し、1年分の監査対応、漏えい時の連絡期限を契約で確認したい。
関連記事
よくある質問
Q1. 外部の生成AIサービスを使うのは避けるべきですか
避けるべきとは限らない。重要なのは、入力データの保存先、学習利用の有無、契約条件を確認し、扱う情報の機密度に見合った使い方をすることである。機密度の低い業務から使い始める設計も有効である。
Q2. 個人情報を扱うAIは作れませんか
適切な設計と契約があれば扱える。どのデータが個人情報にあたるかを整理し、保存先・権限・ログ・契約を設計することが前提になる。後回しにせず、発注前から論点に含めることが重要である。
Q3. セキュリティを優先すると、精度や利便性が下がりませんか
トレードオフはあるが、機密度に応じてデータの扱いを分ければ、利便性を保ちながらリスクを抑えられる。すべてを一律に厳しくするのではなく、情報ごとに設計するのが現実的である。
Q4. 社内規程にAIの利用ルールがない場合、どうすればよいですか
ルールがないまま使い始めると、後から「この使い方はよかったのか」と問題になりやすい。完璧な規程を作る必要はないが、扱ってよいデータの範囲、外部サービスに入力してよい情報、ログの扱いといった最低限の方針を、導入とあわせて決めておくとよい。方針があると、現場も安心して活用でき、判断のばらつきも減る。規程の整備とAIの導入は、どちらかを待つのではなく並行して進めると現実的である。導入で見えた論点を規程に反映していくと、実態に合ったルールになりやすい。
セキュリティと個人情報の扱いを、発注前に設計しませんか
GXOでは、個人情報・機密情報の区分、データ保存先、学習利用の有無、ログ、権限、契約条項を確認し、後戻りしにくいAI開発を設計します。
※ 初回相談では、営業資料の説明よりも現状整理とリスク確認を優先します。
