“使っていい情報／ダメな情報”の線引き──持ち込み禁止リスト（プロジェクト導入現場版）

AI活用で一番事故りやすいのは、出力の質ではなく「入力（持ち込み）」です。
プロジェクト導入の現場は、提案書・見積・契約・WBS・課題管理・障害報告など、社外秘・機微情報の塊です。ここで線引きが曖昧だと、便利になる前にリスクが勝ちます。

この回の目的は、導入現場で迷わないための 持ち込み禁止リスト を作ること。
「AIを使う／使わない」ではなく、“安全に使える形にして使う” ための基準です。

結論：迷ったら「入れない」。代わりに“抽象化”して使う

AIに渡したいのは固有名詞や原文ではなく、構造（論点・条件・判断軸・手順）です。
具体を守りながら、構造だけ借りる。これが導入プロジェクトで最も安定します。

• NG：顧客名／案件名／金額／契約条件／提案書原文／設計書原文

• OK：匿名化した前提、数値はレンジ、要点箇条書き、役割名で置換、テンプレ化

持ち込み禁止リスト（導入現場で特に危ない順）

1）顧客・案件が特定できる情報

• 顧客名、案件名、プロダクト名、拠点名、担当者名

• 画面名・帳票名・コード体系など、組み合わせで特定できる断片
  ポイント：「匿名化しても、文脈でバレる」ことが多い領域です。

2）提案書・見積・契約に関する情報

• 見積金額、単価、原価、利益率、条件（支払・検収・責任分界）

• RFP回答、提案書の差別化ポイント、競合情報
  理由：価格・条件は信用と競争力の中枢。漏れたときの損害が大きい。

3）WBS・体制・計画（人とコストが透ける）

• 体制表（役割・人数・稼働率）、要員計画、スケジュールの詳細

• リスク、炎上兆候、課題の深刻度が分かる情報
  注意：WBSそのものより「誰がいつ何をするか」が機微になります。

4）設計書・障害・運用の原文

• 要件定義書、基本設計、詳細設計、IF仕様、障害報告、ログ

• セキュリティ設計、権限、ネットワーク、内部URL
  理由：原文は再利用・流用の扱いも絡み、事故が複合化します。

5）個人情報・認証情報（ゼロトレランス）

• 氏名、メール、電話、社員番号、顔写真、音声

• パスワード、APIキー、トークン、秘密鍵、Cookie
  原則：1文字でも入れない。スクショにも写り込みます。

“入れていい形”に変換する：導入現場の抽象化テンプレ

置換ルール（最低限）

• 固有名詞 → 「顧客A／業務部門B／意思決定者」

• 金額・単価 → レンジ化（例：数百万〜、人月単価は非開示）

• 原文 → 要点箇条書き（最大7点）

• WBS → タスク構造だけ（週次日付・要員・稼働は落とす）

例1：提案書レビューをAIに手伝わせたい

NG：提案書原文、顧客名、競合名、見積金額まで貼る
OK：次の形に落とす

• 目的：提案の説得力を上げたい（読み手＝意思決定者）

• 前提：顧客課題（抽象化した事実）

• 制約：競合・金額・固有名詞は出さない

• 依頼：弱い論点、想定反論、補強すべき根拠を列挙して

例2：WBSの叩き台を作りたい

NG：顧客名＋稼働率＋日付入りWBS
OK：タスク構造だけ渡す

• スコープ：導入（要件→設計→開発→テスト→移行→教育→運用引継ぎ）

• 制約：期間は「短期／標準／長期」の3パターンで

• 出力：WBS階層（工程→タスク→成果物）と、抜けがちな論点

コピペ用：導入現場の安全プロンプト（入力点検）

以下はプロジェクト情報を抽象化したものです（固有名詞・金額・契約条件は含めない）。
もし「案件特定」「見積/契約」「WBS体制」「設計/運用原文」「個人情報/認証情報」
に触れそうな箇所があれば、
1)危険ポイント
2)安全な言い換え案
3)追加で確認すべき質問（抽象化したまま聞ける形）
を出してください。

よくある事故（導入現場あるある）

1. “参考”のつもりで見積表を貼る（単価・条件が最も危険）

2. WBSに人名・稼働率が残っている（体制が透ける）

3. 障害報告・ログを貼ってしまう（情報量が多く、漏れ方が深い）

まとめ：AI活用は「入力の線引き」で勝負が決まる

導入プロジェクトでAIを安全に使うには、出力テクニックの前に「持ち込み禁止」を決める方が先です。
迷ったら入れない。抽象化して構造だけ渡す。これだけで事故率は大きく下がります。

次回は、AIの出力を「事実／推測／未確認」に分けて扱う、検証の型をまとめます。

※本記事は一般的な情報提供です。最終判断は所属組織の規程・契約条件・セキュリティ方針を優先してください。

次に読む：

シリーズ：仕事で使えるAI活用

はじめての方へ