監査ログ管理

AI開発発注の失敗図鑑｜セキュリティ・個人情報を後回しにするリスク

2026年5月25日15分で読める

QUICK CHECK

本文を読みながら、自社で進めるべきか、相談前に何を整理するかを確認できます。

GXO COLUMN

AI開発

AI開発では、まず精度や機能に関心が向き、セキュリティや個人情報の扱いが後回しになりやすい。しかし、AIは社内文書、顧客情報、業務データなど、扱う情報の範囲が広い。後回しにすると、本番直前で「このデータは外部に出してよいのか」「ログはどこに残るのか」といった問いが噴出し、設計のやり直しになる。

本記事では、セキュリティや個人情報を後回しにするリスクを発注者の視点で整理し、発注前に確認すべき項目と開発会社への質問を示す。専門的な情報セキュリティの知識は不要である。発注者として「どの情報が、どこに、どう残るのか」を確認できれば十分である。セキュリティは精度や機能の後に足すものではなく、最初の設計に含める論点として扱う。後回しにするほど、本番直前の手戻りは大きくなる。

結論：AIに渡す情報の保存先、学習利用、ログ、契約を先に確認する

AI開発でセキュリティを後回しにすると、本番直前にデータの扱いで設計を戻すことになる。GXOが発注前に確認するのは、個人情報・機密情報の区分、外部サービスへの送信可否、データ保存先、学習利用の有無、操作ログ、契約上の責任分界である。

情報を公開情報、社内限定、機密性の高い情報に分ける
入力データが保存される場所、運用主体、準拠法を確認する
学習利用しない条件、ログ保存期間、漏えい時の対応を契約で見る

「安全です」という説明だけでは足りない。データがどこに残り、誰が検証できるかまで具体化する必要がある。

MANUFACTURING DX

Excel限界から受発注システムへ、同規模の概算は？

中小製造業の概算費用・導入期間・役割分担マトリクスをその場で確認。要件整理テンプレも無料提供します。

製造業DXの概算を見る

なぜ後回しになりやすいのか

セキュリティや個人情報の検討が後回しになるのは、次のような理由による。

PoCやデモの段階では、サンプルデータで動かすため問題が見えにくい
「まず動くものを」と進めるうちに、データの扱いの議論が先送りされる
セキュリティは精度や機能に比べて、効果が見えにくい
どの情報が機密・個人情報にあたるか、社内で整理されていない

後回しにした結果、本番でいざ実データを使う段階になって、扱ってよい範囲やデータの保存先が問題になり、計画が止まる。

発注前に確認しておきたいセキュリティの論点

国や地域の名前で「ここは不可」と判断するのではなく、次の観点で確認するのが実務的である。どこの事業者かではなく、データがどう扱われるかで判断する。

データ保存先：入力したデータや生成物が、どこに保存されるか
運用主体：そのデータを誰が管理・運用するか
準拠法：契約やデータの扱いが、どの国の法律に基づくか
監査可能性：データの扱いやログを、後から確認・検証できるか
学習利用の有無：入力したデータが、外部のモデル学習に使われないか

これらが曖昧なまま発注すると、個人情報保護や社内規程との整合を、本番直前に検証し直すことになる。

FREE DOWNLOAD

AI導入チェックリスト（PoC 失敗要因 10項目）

情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。

30分で相談するチェックリストをDL

後回しにした場合に表面化する問題

横にスクロールして確認できます

論点	後回しにすると起きること	発注前に確認すること
個人情報	扱ってよい範囲が本番で問題化	どのデータが個人情報か整理する
機密情報	社外に出してよいか判断できない	機密区分と取り扱いルールを決める
データ保存先	保存場所が社内規程と不整合	保存先・運用主体・準拠法を確認
ログ	誰が何を見たか追えない	ログの取得範囲と保存期間を決める
権限	見せてよい範囲が曖昧	データ・機能ごとの権限を整理
学習利用	入力が外部学習に使われる懸念	学習に使わない契約条件を確認
監査・契約	検証も責任も追えない	監査可能性と契約条項を確認

これらは発注前に方針を決めておけば、本番直前の手戻りを避けられる。

機密度に応じてデータの扱いを分ける

セキュリティを理由にすべてを一律に厳しくすると、使い勝手が下がり、結局AIが活用されない。現実的なのは、情報の機密度に応じて扱いを分けることである。たとえば、次のような区分が考えられる。

公開してよい情報：すでに社外に公開している内容。外部サービスでも比較的扱いやすい。
社内に閉じたい情報：社外秘の業務情報。保存先や学習利用の条件を確認したうえで使う。
特に機密性の高い情報：個人情報や、漏えい時の影響が大きい情報。扱う場合は、保存先・権限・ログ・契約を慎重に設計する。

この区分を最初に決めておくと、「どの業務から、どのデータで始めるか」を判断しやすい。機密度の低い業務から導入し、扱いに慣れてから機密性の高い領域へ広げる進め方は、リスクを抑えながら効果を出すうえで有効である。

また、判断の軸を「どこの国の事業者か」に置くと、本質を見誤ることがある。重要なのは、データがどこに保存され、誰が運用し、どの法律に基づき、後から検証できるかである。同じ事業者でも、契約や設定によってデータの扱いは変わる。発注前に、これらを具体的な条件として確認しておくと、本番直前の手戻りや、社内規程との不整合を避けられる。セキュリティは「導入後に足す」ものではなく、最初の設計に含めるものとして扱いたい。

発注前に確認すべき項目

AIに渡すデータのうち、個人情報・機密情報にあたるものを整理したか
それぞれのデータを外部のサービスに送ってよいか、社内ルールを確認したか
入力データや生成物の保存先・運用主体・準拠法を確認したか
入力データが外部のモデル学習に使われない条件か確認したか
誰が何を操作・閲覧したかのログを残す要件を入れたか
データ・機能ごとの閲覧/操作権限を整理したか
データの扱いを後から検証できる（監査可能性）か確認したか
情報漏えい時の責任分界や対応を、契約で確認する予定があるか

開発会社に確認する質問

横にスクロールして確認できます

質問	確認したいこと
入力したデータはどこに保存されますか	データ保存先と運用主体
入力データは外部のモデル学習に使われますか	学習利用の有無
操作・閲覧のログはどこまで残せますか	監査可能性
データや機能の権限はどう設計しますか	アクセス制御
個人情報の扱いは契約でどう定めますか	契約上の責任
データの扱いを後から検証できますか	監査・説明責任

「安全です」という言葉だけでなく、保存先・学習利用・ログ・契約という具体で答えられるかを確認したい。発注時のチェック観点はAI開発の発注チェックリストとAI-SBOMも参考になる。

GXOに相談する前に整理するとよい情報

AIに使わせたいデータの種類と、その中の個人情報・機密情報
社内のデータ取り扱いルール（持ち出し、保存先などの規程）
業界・取引先から求められるセキュリティ要件があるか
ログや監査に関する社内の決まり（内部統制など）
すでに使っている、または検討しているAIサービスがあれば、その内容

扱う情報と社内ルールが見えると、「どこまで外部サービスを使い、どこを社内に閉じるか」を現実的に設計できる。

これらが整理されていなくても相談は可能である。扱うデータの中で「特に守りたい情報」が見えていれば、その機密度に合わせて、使い方とデータの扱いを一緒に設計できる。

参考にした外部観点

AI開発のセキュリティでは、個人情報、機密情報、ログ、権限、契約を具体的に確認する必要がある。個人情報保護委員会のFAQは個人情報の取り扱いを確認する入口になり、OWASP Top 10 for Large Language Model ApplicationsはLLMアプリケーションのセキュリティリスクを整理している。

発注前には、個人情報を含むデータ10件、ログ保存30日以上、3ヶ月ごとの権限棚卸し、1年分の監査対応、漏えい時の連絡期限を契約で確認したい。

GXOの見解

セキュリティニュースは読むだけでは価値がなく、自社資産、影響判定、対応期限、経営報告に変換して初めて防御力になる。

GXOは単発診断よりも、月次の棚卸し、優先順位付け、証跡管理、改善実行までを運用化すべきだと見る。

GXOは、脆弱性診断、インシデント対応、月次運用、開発保守の改善まで接続できる形で支援します。

実務判断のポイント

この記事は、経営者、CIO、情シス、セキュリティ担当、開発責任者向けです。脆弱性管理、外部公開資産棚卸し、月次セキュリティ運用、インシデント対応を自社で進めるか、外部の専門家と整理するかを判断する材料として使えます。

GXOが重視するのは、話題性の高さよりも「自社の業務、データ、権限、予算、運用責任にどう影響するか」です。AI開発発注の失敗図鑑｜セキュリティ・個人情報を後回しにするリスクに関する検討では、担当者だけで判断を閉じず、経営、現場、情シス、外部パートナーの役割を早い段階で分けることが重要です。

放置した場合と整備した場合の違い

横にスクロールして確認できます

観点	放置した場合	整備した場合
業務影響	属人的な判断が増え、対応の優先順位がぶれやすい	影響範囲、期限、責任者を決めて進められる
投資判断	ツール導入や外注費だけが先行し、効果測定が曖昧になる	売上、工数削減、リスク低減の指標にひも付けられる
現場運用	例外処理や承認フローが残り、定着しにくい	権限、ログ、教育、改善サイクルまで設計できる
経営報告	問題が発生してから説明資料を作ることになる	月次で状況、課題、次の打ち手を説明できる

導入・改善前のチェックリスト

対象業務、対象部門、対象データを明文化しているか
現在の課題を、売上機会、原価、工数、リスクのいずれかに分解しているか
既存システム、SaaS、Excel、手作業の依存関係を棚卸ししているか
例外処理、承認、差し戻し、監査証跡まで確認しているか
社内で判断できる範囲と外部支援が必要な範囲を分けているか
初期費用だけでなく、保守、運用、教育、改善費用を見積もっているか
成功指標を、問い合わせ数、商談数、削減時間、停止リスクなどで定義しているか
実装後の責任者、更新頻度、レビュー会議の持ち方を決めているか
セキュリティ、法務、個人情報、契約条件の確認ポイントを洗い出しているか
既存の問い合わせ、商談、障害、運用ログから優先順位を決めているか
経営判断に必要な資料を1枚で説明できる状態にしているか
次の90日で検証する範囲と、やらない範囲を明確にしているか

GXOの見解

セキュリティニュースは読むだけでは価値がなく、自社資産、影響判定、対応期限、経営報告に変換して初めて防御力になる。

GXOは単発診断よりも、月次の棚卸し、優先順位付け、証跡管理、改善実行までを運用化すべきだと見る。

自社だけで整理が難しい場合、GXOは脆弱性診断、インシデント対応、月次運用、開発保守の改善まで接続できる。最初から大規模な発注を前提にせず、現状整理や診断から必要な範囲を確認できます。

実行までの進め方

現在の業務、データ、ツール、担当者を棚卸しする
売上拡大、工数削減、リスク低減のどれに効くテーマかを決める
初期対応、90日以内の改善、半年以上の投資を分ける
必要な社内体制、外部支援、予算、セキュリティ確認を整理する
小さく検証し、効果測定後に本番化や横展開を判断する

よくある質問

Q1. 外部の生成AIサービスを使うのは避けるべきですか

避けるべきとは限らない。重要なのは、入力データの保存先、学習利用の有無、契約条件を確認し、扱う情報の機密度に見合った使い方をすることである。機密度の低い業務から使い始める設計も有効である。

Q2. 個人情報を扱うAIは作れませんか

適切な設計と契約があれば扱える。どのデータが個人情報にあたるかを整理し、保存先・権限・ログ・契約を設計することが前提になる。後回しにせず、発注前から論点に含めることが重要である。

Q3. セキュリティを優先すると、精度や利便性が下がりませんか

トレードオフはあるが、機密度に応じてデータの扱いを分ければ、利便性を保ちながらリスクを抑えられる。すべてを一律に厳しくするのではなく、情報ごとに設計するのが現実的である。

Q4. 社内規程にAIの利用ルールがない場合、どうすればよいですか

ルールがないまま使い始めると、後から「この使い方はよかったのか」と問題になりやすい。完璧な規程を作る必要はないが、扱ってよいデータの範囲、外部サービスに入力してよい情報、ログの扱いといった最低限の方針を、導入とあわせて決めておくとよい。方針があると、現場も安心して活用でき、判断のばらつきも減る。規程の整備とAIの導入は、どちらかを待つのではなく並行して進めると現実的である。導入で見えた論点を規程に反映していくと、実態に合ったルールになりやすい。