1. 目的を決め、情報を分類する
最初に「何の作業を助けたいか」を一つ決めます。問い合わせの種類を分類したいのか、返信の下書きを作りたいのかによって、必要な情報は異なります。顧客台帳やメールの履歴を丸ごと渡す前に、必要な項目を洗い出しましょう。
以下は社内で確認するための分類例です。法令上の分類や入力許可を、この表だけで決めるものではありません。
| 情報の例 | 入力前に確認すること |
|---|---|
| 公開済みの製品説明・FAQ | 公開してよい範囲か、資料の利用条件に制約がないか |
| 氏名・連絡先・購入履歴など | 個人を識別できる情報か、利用目的に合うか、AIに渡す必要があるか |
| 非公開の取引条件・見積り・契約内容 | 秘密保持や顧客との契約で、外部サービスへの入力が認められるか |
| 健康状態など慎重な扱いが必要な情報 | 法務・情報管理の担当者による確認が必要か、入力せずに作業できるか |
| パスワード・認証コード・APIキー | 入力対象から除く。作業の説明にも実際の値を使わない |
法人の顧客情報でも、担当者の氏名や連絡先を含むことがあります。個人情報に当たるかという確認と、業務上の秘密を外部へ渡してよいかという確認は、両方必要です。
個人情報保護委員会の注意喚起では、個人情報を含む入力が利用目的を達成するために必要な範囲か、個人データが機械学習などに使われないか、規約等を確認するよう求めています。本人の同意や法的な取り扱いは、実際の情報・契約・利用方法に応じて担当者や専門家に確認してください。
2. AIに渡す項目を減らす
分類に不要な氏名、メールアドレス、住所、顧客番号などは除きます。返信の下書きでも、宛名や注文番号をAIに渡さず、確認後に担当者が元の業務システムで補う方法を検討できます。
名前を「顧客A」に置き換えるだけでは十分とは限りません。本文中の勤務先、日時、購入内容などを組み合わせると、相手が分かる場合があります。伏せ字にしたことだけで、法令上の匿名加工情報になったり、入力可能になったりするとは判断しません。
入力する文章だけでなく、添付ファイル、メールの署名・引用履歴、画像に写った情報も確認します。資料検索や自動連携を使う場合は、AIが取得する資料の範囲も同じように見直しましょう。
削減した結果、判断に必要な文脈まで失われる場合は、人が処理する工程として残します。情報を減らすために、問い合わせの意味を変えてしまわないことも大切です。
検証ラボから考える、AIへ渡す内容と原文の確認
氏名などを除く作業と、問い合わせの意味を保つ確認を分けましょう。 AIには承認された範囲の用件と回答資料を渡し、人は元の記録で業務への影響や未回答の事項を確認する、という設計をhirostaは提案します。識別子の照合は、本文の意味を整理する処理と分けて考えます。
材料は、問い合わせメールの下書きの検証ラボです。2026年10月9日に短い架空メール6件で初版と修正版をそれぞれ1回実行した試作で、お客様の情報・案件ではありません。担当者の承認・送信は未実施です。以下では、観察した結果、そこからの提案、まだ確かめていない範囲を分けます。
業務への影響と、すべての用件を確認対象にする
観察： LAB-M04は「至急」という語がなくても受注作業が止まっているメールでした。初版は通常扱いにしましたが、修正版は業務停止を示す原文を根拠に残し、優先確認に回しました。受付時間と返金を尋ねるLAB-M05も、初版は受付時間だけを回答し、修正版は二つの用件と返金の判断待ちを残しました。
hirostaの提案： 入力項目を減らすときは、氏名・連絡先の除去だけで完了にせず、業務への影響、すべての用件、未回答の事項が残るかを元の記録と照合します。意味を保てるか確かめられない場合はAIへの入力を保留し、承認された社内環境で人が原文を確認する工程を残します。
限界： ラボは分類方法の比較であり、要約・削減した入力との比較ではありません。どの情報を除いても判断を保てるかは未検証です。今回の観察は、原文を丸ごとAIへ渡す根拠にはなりません。
資料を追加する前に、答えられる部分と個別判断を分ける
観察： 回答資料を架空FAQの受付時間1項目に限った試作では、受付時間の回答案を作り、返金条件・見積金額・復旧時刻は資料の不足として残しました。LAB-M05では、受付時間の根拠と返金条件の不足を別の確認欄に示しました。
hirostaの提案： 不足を埋めるために顧客の履歴や契約書をまとめて追加する前に、承認済みの資料で答えられる部分と、人が元の契約・記録を確認して決める部分を分けます。AIには回答の根拠と不足を残させ、個別判断に必要な情報を追加する場合は、その項目と利用環境を改めて承認の対象にします。
限界： 確かめたのは不足を残す処理であり、実データを追加しなくても業務が完結することではありません。人が契約を確認し、回答を確定する工程もラボでは実施していません。
識別情報は、照合に使う工程から必要性を考える
観察： 修正版では、同じ識別子のメールの再取り込みをPythonで照合し、二つ目の下書きを作らず保留にしました。照合は同じ実行内に限り、別の実行の履歴は保存していません。
hirostaの提案： メールの識別子は通常のプログラムで照合し、本文の意味はAIに整理させる分担を検討します。識別子・宛先などを元の業務システムで管理する工程を先に決め、その値をAIにも渡す必要があるかを項目ごとに確認します。
限界： AIの処理から識別子を除いた比較はしていません。実際のメールの識別子を送らなくてよいと検証したものではなく、実運用の二重返信防止も確認していません。
公的資料の注意点と、工程分担の提案を照らす
2026年10月10日に、個人情報保護委員会の掲載ページからリンクされている2023年6月2日付の本文PDFを確認しました。次は資料に書かれた注意点の要約です。
- （1）①： 個人情報を含む入力が、特定された利用目的の達成に必要な範囲かを十分に確認する。
- （1）②： 本人の同意なく入力した個人データが応答の出力以外の目的で扱われると、法に違反する可能性があるため、機械学習に利用されないことなどを十分に確認する。
- （3）①②： 入力した個人情報が学習に使われ、他の情報と結びついて出力されるリスクや、応答に不正確な個人情報が含まれるリスクを踏まえて判断する。
- （3）③： 利用規約・プライバシーポリシー等と、入力する情報の内容を踏まえて利用を判断する。
これらと照らし、hirostaは「AIに必要な内容」「人が原文で確認する内容」「通常のプログラムが照合する識別情報」を分けてから、入力範囲を決める進め方を提案します。（1）①に対しては情報を項目と工程ごとに洗い出し、（3）①②に対しては元の記録・回答資料との照合を残します。（1）②と（3）③の契約・利用条件の確認は、情報の削減や工程分担だけでは代わりになりません。
この分担はラボから導く運用提案であり、公的資料が指定した手順ではありません。また、元の記録との照合だけで個人情報の出力リスクを解消できるという意味でもありません。法的な適否や実データの入力可否は、情報・目的・利用環境ごとに担当者や専門家が確認する必要があります。
3. 利用サービスの契約・設定を確認する
サービス名だけでなく、会社で使うプラン、アカウント、機能、接続先を特定します。社員が個人で契約した画面と、会社が承認した環境を同じ条件として扱わないようにします。
提供元の最新の利用規約、プライバシーポリシー、データの取り扱いに関する説明と、実際の管理設定を照合します。次の項目は確認の観点であり、すべてのサービスが同じ機能や条件を持つという意味ではありません。
- 入力・出力がモデルの学習やサービス改善に利用される条件と、その対象範囲
- サービス提供者側での保存期間、閲覧される条件、削除方法と例外
- 社内の共有設定、管理者・利用者の閲覧権限、アカウント管理
- データの保存先、委託先・外部連携先と、顧客との契約上の制約
- 添付資料、追加機能、外部ツールへの連携で、別の取り扱い条件が適用されるか
「学習に使わない」ことと、「保存されない」「誰にも閲覧されない」ことは別の確認項目です。料金を払っていることも、すべての顧客情報を入力できる根拠にはなりません。説明が見つからない、契約と設定の対応が分からない場合は、実データの入力を止めて提供元へ確認します。
この記事では特定製品の現在の保存期間や設定値を示していません。利用を始める時点で、実際に使う環境の公式資料を確認し、参照先と確認日を社内で残してください。
4. 社内の承認と、閲覧・保存・削除の担当を決める
承認を求めるときは「AIを使ってよいですか」だけでなく、次の内容をまとめます。確認記録に、顧客情報そのものや認証情報を貼り付ける必要はありません。
- 作業と情報： 利用目的、入力する項目、除く項目、利用する資料の範囲
- 利用環境： サービス・プラン・アカウント、確認した契約・設定と確認日
- 人の役割： 入力可否を承認する人、出力を確認する人、判断に迷う場合の窓口
- 保存と共有： 入力・出力・添付資料を誰が見られるか、どこにいつまで保存するか
- 削除と見直し： 削除する担当者、利用終了・退職時の権限整理、条件変更時の再確認
AIの会話履歴だけでなく、コピーした下書き、ダウンロードしたファイル、連携処理の記録にも情報が残る可能性を考えます。AI画面で削除した後の扱いはサービスの条件で確認し、社内の保存先でも必要な削除を行う運用にします。
承認は「この作業・この項目・この環境」の範囲で残します。顧客情報の種類、利用目的、プランや連携先が変わったときは再確認します。誤って入力した場合は追加の入力・共有を止め、社内の情報管理窓口へ速やかに報告し、削除や必要な対応を確認してください。
5. 具体例：問い合わせを分類して返信の下書きを作る
以下は運用を考えるための想定例であり、顧客案件の実績や入力許可を示すものではありません。
配送時期についての問い合わせを分類したい場合、氏名・メールアドレス・注文番号を除き、「配送時期を知りたい」という要点と、承認済みの公開FAQだけで試す方法があります。過去の全メールを渡す前に、要点だけで分類できるかを確かめます。
実際の注文状況が必要な回答は、担当者が業務システムで確認します。AIが用意した一般的な下書きに、確認した納期や宛名を補い、根拠・宛先・本文を人が確認してから送信します。注文履歴をAIに渡す必要がある場合は、その項目と利用環境について改めて承認を受けます。
健康状態の相談や非公開の契約条件が本文に含まれる場合、担当者の判断だけで既存の分類処理へ流しません。承認された範囲を超える情報として保留し、入力せずに対応する方法や専門担当への引き継ぎを確認します。
分類・下書き・送信の工程は問い合わせAIの分類・下書き・送信前確認で詳しく説明しています。公開済みの問い合わせ対応事例も工程の参考になりますが、公開している再現には架空データを使っています。個別の顧客情報を入力してよいという根拠にはなりません。
6. よくある質問
Q. 有料の生成AIサービスなら顧客情報を入力できますか？ 有料であることだけでは判断できません。入力する情報、利用目的、契約・設定、保存や共有の条件、社内の承認を確認します。条件が分からない場合は入力を保留してください。
Q. 名前や連絡先を伏せれば、そのまま入力してよいですか？ それだけでは決められません。本文や添付資料に相手を特定できる情報が残っていないか、秘密保持などの制約がないかも確認します。伏せ字だけで法令上の匿名加工情報になったとは判断しません。
Q. 学習に使われなければ、保存や削除の確認は不要ですか？ 必要です。学習への利用と、サービス側の保存・閲覧、社内の共有は別の確認項目です。会話履歴に加え、添付資料、出力、連携先の記録の保存期間と削除方法を確認してください。
Q. 社内で誰が入力可否を決めればよいですか？ 業務責任者と情報管理の担当者が、作業・入力項目・利用環境の範囲を確認できる体制にします。法的な取り扱いや顧客との契約に判断が必要な場合は、法務担当者や専門家に確認します。
Q. hirostaへ相談するときに、顧客台帳を送る必要はありますか？ 最初の相談では、作業の流れと困っている点をお伝えください。顧客情報そのものを送らずに相談できます。hirostaの支援では個人データをなるべくAIに送らない設計とし、必要な場合は事前に説明して了承をいただきます。
支援内容・料金とデータの扱いはサービス・料金の契約条件で確認できます。対象業務が決まっていなくても、困りごとから相談できます。
社員がそれぞれ使うAIを会社として整理するには、社員のAI利用を聞き取り・台帳・ルールで把握する手順をご覧ください。