顧客名を消した見積書ならAIへ入れてよいのか。公開済みの施工事例なら自由に使えるのか。どちらも、資料名や公開の有無だけでは決まりません。含まれる情報、利用目的、入力先の契約・設定を組み合わせて判断します。
まず、公開範囲と機密性を分け、そのうえで個人情報や契約上の制約が重なっていないかを見ます。必要な部分だけを取り出しても、入力先の条件が合わなければ送信は保留です。この記事では、工務店の面談メモを架空例にして、この判断を説明します。分類表や記録方法は編集部の運用提案で、法令上の分類や公式様式ではありません。
ハウスメーカーで展示場の面談メモを本部へ集める場合
展示場や支店の面談メモを本部でまとめてAIに渡す会社では、04章の集計例のように期間と分母を拠点ごとに添え、置換後もどの拠点の記録かを追えるようにします。拠点名と少ない件数の組合せで顧客を推測できないかも確かめます。
07章の判断記録は、入力した部署と承認した部署を分けて残します。
公開範囲と、誰の情報かを重ねて見る
「公開情報・社内情報・社外秘」と「顧客情報」は、同じ基準で分けた区分ではありません。前者は公開範囲や機密性、後者は誰に関する情報かを表しています。公開済みの記事に施主の個人情報が含まれることも、社外秘の原価表に取引先担当者の氏名が入ることもあります。
実務では、次の表で基本の扱いを選び、個人情報と契約上の制約を重ねて判断すると混同を減らせます。
横にスワイプして、右側の列を確認できます
| 公開範囲・機密性 | 工務店での例 | 入力前に考えること |
|---|---|---|
| 公開情報 | 自社サイトの文章、公開求人票、公開済み施工事例 | 現在も公開されているか。写真・文章の権利や利用条件は合うか |
| 社内情報 | 一般的な手順案、会議の議題、社内用の文章案 | 社外へ出ると何が困るか。目的に必要な部分だけにできるか |
| 社外秘 | 原価、値引き限度、協力会社の単価、未公開の経営計画 | 取引上の影響と契約を踏まえ、その用途を扱える環境か |
この区分に加えて、顧客、社員、応募者、取引先担当者などの個人情報があるかを見ます。氏名や連絡先だけでなく、住所、顔、経歴、家族構成、敷地や相談の特徴との組み合わせも関係します。法人そのものの情報と、そこで働く個人の情報も同じではありません。
個人情報保護委員会の通則ガイドラインでは、公開情報や評価情報も個人情報に含まれ得ること、他の情報と容易に照合して個人を識別できる場合も対象になることが説明されています。
氏名を顧客Aへ替えても、自社の台帳と容易に照合できるなら、個人情報として扱います。対応表を別の場所に置くことは管理上の工夫になりますが、それだけで個人情報でなくなるわけではありません。本記事の削除・置換は、法令上の仮名加工情報・匿名加工情報を作る手順ではありません。
また、氏名を含まなくても原価や交渉条件は機密です。複数の性質を含む資料には、それぞれの制約を適用します。「一番厳しそうな分類名を一つ付けた」だけで、残りの条件を見なくてよいわけではありません。
入力範囲は、AIに頼む仕事から決める
資料を開いたら、先に「何を得たいか」を一文にします。問い合わせ返信の構成なら氏名や住所は不要です。見積もりの工事項目を読みやすくするだけなら、原価や値引き限度を含むファイル全体は必要ありません。
そのうえで、含まれる項目について、人物や案件を特定できるか、外部へ出ると誰にどんな不利益があるか、契約や素材の利用条件に制約があるかを見ます。入力先を決める前にここまで分けると、全文を貼り付けた後で削除する運用を避けられます。
例えば、限定公開の共有資料は、インターネットで開けるから公開情報とは限りません。担当者が個人的に投稿した写真も、会社として自由に再利用できる素材かは別の問題です。公開を取りやめた施工事例や、掲載停止の希望が届いている写真も、過去に公開していたという理由だけで使い続けない扱いが必要です。
一般的な質問を考えるだけなら、実資料を使わずに済む場合もあります。文章構成は架空の条件で作り、社内で確認済みの氏名や案件条件を後から人が戻す方が、入力範囲を決めやすくなります。
架空例:面談メモから次回の質問を作る
ここでは架空の青葉住建が、住宅相談の案件Aについて、次回面談の確認事項を整理する設定を使います。会社、家族、案件、入力文はすべて説明用で、実在の顧客情報ではありません。
元のメモには、夫婦の氏名、住所、勤務先、子どもの年齢、土地の所在地、予算、資金援助予定、希望する間取りがあります。目的は一般的な確認質問を作ることであり、融資や成約可能性の判定ではありません。
横にスワイプして、右側の列を確認できます
| 元メモの項目 | 今回の目的に残す内容 | 外す内容・留意点 |
|---|---|---|
| 氏名、現住所、勤務先 | 今回は不要 | 削除する |
| 土地の詳細所在地 | 敷地条件を次回確かめる必要があること | 地番を外す。所在地を消す際に積雪や法規の条件を推測で足さない |
| 子どもの氏名・年齢 | 子育てに関係する暮らし方の希望 | 必要なら世帯条件へ一般化し、具体的な年齢を外す |
| 予算 | 資金計画で何を確かめるか | 質問の構成だけなら金額も予算帯も入力しない |
| 親からの資金援助予定 | 資金の準備時期を確認する質問を作ること | 誰からの援助かは外す。援助予定だけから準備時期が未定とは判断しない。原記録では援助予定の情報を失わない |
| 希望する間取り | 家事動線と在宅勤務場所を重視すること | 目的に不要な珍しい特徴を外す |
| 自社の値引き可能額 | 今回は不要 | 顧客情報を消しても社外秘なので入力しない |
架空の入力文
架空の住宅相談の例です。子育て世帯が家事動線と在宅勤務場所を重視しています。資金の準備時期と要望の優先順位を確認する質問を作りたいです。次回面談で確認する質問を、資金計画、暮らし方、敷地条件、意思決定に分けて挙げてください。入力にない家族事情や敷地条件を加えず、提案や審査結果ではなく質問として書いてください。
ここで架空と書けるのは、もともと説明用に作った設定だからです。実在の面談メモを加工しただけなら、入力文へ「架空」と付けても取扱条件は変わりません。実データ由来であることを社内で把握し、加工後の内容と入力先の条件で判断します。
特徴を減らすほど、AIが使える個別条件も減ります。この例で得られるのは一般的な質問の下書きであり、具体的な敷地への提案ではありません。案件へ戻して使う段階で、担当者が元の相談内容と照らし合わせます。
削除・置換・集計では、残る課題が違う
削除は不要な項目を外す方法、置換は必要な関係や条件を粗く表す方法です。いずれも、加工しただけで分類や機密性が自動的に下がるわけではありません。
横にスワイプして、右側の列を確認できます
| 方法 | 向いている作業 | 加工後に見ること |
|---|---|---|
| 削除 | 氏名や連絡先を使わない文章整理 | 署名、添付、呼称などに残っていないか |
| 置換 | 顧客A、協力会社Bなどの関係を残す整理 | 珍しい条件の組み合わせや対応表から特定できないか |
| 集計 | 複数案件の傾向を検討する | 少数の区分から個別案件を推測できないか。機密の経営情報ではないか |
| 抽出・分割 | 必要な段落や項目だけを整える | 条件や留保を落として意味を変えていないか |
| 実データを使わない架空例 | 文案の型や研修教材を作る | 実案件の固有条件をそのまま再現していないか |
架空の集計例:期間と分母を一緒に渡す
直近3か月の失注案件20件について、主な失注理由を各案件一つに分け、除外案件なしで集計したとします。そのうち予算超過が7件なら、割合は7件÷20件×100=35%です。これは計算方法を示す架空例で、実績値ではありません。
AIへ渡す際も、期間、対象の失注案件数、数え方、除外条件を一緒にします。理由を複数選択する集計や、理由不明の案件を除く集計では意味が変わります。数字だけを35%と渡しても、何の割合かは伝わりません。
氏名を含まない集計にも、受注状況や採算などの機密性は残り得ます。人数や案件数が少ない区分では、他の情報との組み合わせで個別案件が分かる場合もあります。
ファイルを添付する場合は、本文以外も対象です。ファイル名、シート名、コメント、変更履歴、ヘッダー、図面のタイトル欄、写真の表札などに、削除したつもりの情報が残ることがあります。対応表や原文を同じAIの会話へ追加すれば、置換で減らした情報を再び渡すことになります。
サービスの契約・設定と照らして入力を決める
加工後のデータを見直したら、実際に使うアカウント、プラン、機能の条件と合わせます。製品名、有料か無料か、法人契約かだけで入力可否は決まりません。
横にスワイプして、右側の列を確認できます
| 判断する条件 | 確かめる内容 |
|---|---|
| 利用目的と必要性 | 自社が定めた利用目的の範囲に入り、その情報を渡す必要があるか |
| 応答生成以外への利用 | 学習やサービス改善などに何が使われる契約・設定か |
| 保存と削除 | 入力、添付、出力、ログの保持期間と削除の範囲 |
| 閲覧・共有 | 管理者や利用者の権限、公開リンク、外部連携の送信先 |
| 契約と外部提供 | 秘密保持、委託・第三者提供・外国への提供等の検討が必要な取扱いか |
| 出力の用途 | 社内下書きか、顧客対応・公開・自動送信まで行うか |
個人情報保護委員会の生成AIに関する注意喚起は、利用目的に必要な範囲を確認するよう求めています。また、本人同意なく個人データを入力し、応答出力以外に使われる場合は法に違反する可能性があるため、機械学習に利用しないこと等の確認を挙げています。これは、すべての顧客情報の入力を一律に禁止する説明ではありません。
本記事では、個人情報や社外秘を含む入力について、目的・契約・設定を責任者が判断できるまで保留する運用を提案します。学習しない設定だけで許可せず、保存や共有などの条件も合わせます。個別の適法性を判断できない点は、実際のデータと契約を示して専門家や所管窓口へ相談する事項です。
会社で承認する際は、サービス名だけでなく、使える用途と情報の範囲、設定、判断者、確認日を残します。承認済みの環境でも、面談の論点整理から顧客の成約可能性の判定へ目的を変えるなら、出力の影響も含めて判断し直します。
IPAの中小企業の情報セキュリティ対策ガイドラインは、経営者の指針と実践の手順を段階的に整えるための資料です。本記事の表を公式様式と考えず、自社の情報管理や契約に合わせて使います。
出力にないはずの事情が戻ったら、推測を疑う
適切に入力できても、出力が正しいとは限りません。次は、先ほどの架空入力に対する誤りを説明するための出力例です。実際のモデルを試した結果ではありません。
資金面への不安が強いので、低予算のプランを先に提示しましょう。郊外では車2台が必要です。親からの援助額を確認し、借入可能額を提示してください。
入力には、不安の強さ、郊外という立地、必要な車の台数、援助者は書かれていません。元の社内メモに親からの援助予定があったとしても、この出力が正しく復元した証拠にはなりません。AIが補った内容と、人が別に把握している情報を分けて扱います。
修正するなら、次のように確認質問へ戻せます。
自己資金を確定できる時期と、月々の負担に対する希望を確認する。駐車台数は生活状況と敷地条件に合わせて尋ねる。借入額や制度の適用は断定せず、金融機関や関係資料で確認する事項として分ける。
出力を案件へ戻す担当者は、AIへ渡した内容と原記録の両方を見ます。文章の短縮で予算の条件や時点が落ちていないか、工期や性能、契約上の約束が増えていないかも対象です。顧客へ送る前には、宛名、金額、期日、約束の範囲を人が確かめます。自動送信や自動公開は、社内下書きとは別の用途として設計する必要があります。
判断を残し、条件が変わったら見直す
一件の入力判断は、利用目的、元資料の管理番号、含まれる情報、加工内容、入力先と設定、出力の用途、判断者と日付を一組にして残します。台帳へ顧客の相談本文を丸ごと複製する必要はありません。原資料は権限を管理した場所に置き、判断の根拠をたどれる参照を残します。
例えば案件Aなら、「次回面談の質問案を作るため、氏名・詳細所在地等を除き、条件を一般化。確認済みの契約・設定の環境で社内下書きに限定」と記します。条件付きで認めた場合は、対象者、期限、追加加工、出力先を具体的にします。公開情報だけの定型作業は、承認した手順をまとめて管理するなど、情報の性質に応じて記録の細かさを変えられます。
誤って送信した場合は、追加操作や共有を止め、使用サービス、日時、送った情報の範囲、共有状況を責任者へ報告します。「忘れてください」と追加入力して処理済みにしたり、担当者だけで履歴を消して終わらせたりしません。責任者が影響範囲と証拠の保全、削除依頼等の対応、法令上の報告・本人通知の要否を判断します。
運用の見直しは、同じ保留理由が続くときや、契約・主要機能・外部連携を変えるときに行います。差戻しが増えた場合も、確認が機能し始めたのか、分類が分かりにくいのかを理由から見ます。利用件数や受注の増減だけでAIの効果を断定せず、実際に直した内容や情報管理上の課題を、次のルールへ反映します。
参考にした公式資料
記入例・計算例は編集上の例です。制度の受付状況や仕様は変わるため、実行前にリンク先の最新情報をご確認ください。