「AI に社内のデータを渡していいのか」。この一言で AI 導入が止まっている会社は、当社が相談を受ける範囲では珍しくありません。情シスは「学習に使われるかもしれない」と言い、経理は「取引先の名前が入っている」と言い、人事は「給与が入っている」と言う。誰も間違っていない。ただ、誰が・どの項目を・どの条件なら渡してよいかを決める場がないので、答えが「当面は様子見」になる。PoC（試験導入）はダミーデータで動いたのに、本番データを入れる段階で1年止まる、という相談もあります。
この記事は、FDE（Forward Deployed Engineer）が顧客の中に入って AI を本番稼働させるとき、着任前から最初の2週間で決めるデータの扱いだけを扱います。学習利用・保存場所と保持・権限・ログ・分類・削除の6項目を、各ベンダーの公式ページで確認できた事実、個人情報保護法と個人情報保護委員会の注意喚起、AI 事業者ガイドラインに沿って整理し、SaaS API 直結・クラウド事業者経由・自社環境内の3構成を比べます。受け入れ側の体制の記事の「情シスが着任前に出す3つの一覧」に6項目をどう接続するかも書きます。
「AI にデータを渡していいか」は二択ではなく6項目を決める作業。①学習に使われないか ②保存地域と保持期間 ③誰がどのデータを渡せるか ④ログの残し方 ⑤個人情報・機密の分類 ⑥退役時の削除。①②④は公式ページで確認できる事実、③⑤⑥は社内で決める判断。主要5社の商用サービスは既定で学習に使わないが、不正利用監視のログ保持（30日等）は別枠で残る。構成は3つで、経理・人事の月次データなら多くの場合クラウド事業者経由で処理地域と保持を固定すれば足りる。
この記事の要約
「AI にデータを渡していいのか」で止まる会社で起きていること
止まっている会社の共通点は、判断の単位が「AI を使うか使わないか」になっていることです。この粒度で議論すると、慎重な人が1人いれば止まります。当社が伴走してきた経理 AX・kintone・案件管理システムの刷新・Claude 導入の案件でも、最初の相談で「情シスが止めている」と言われることがある。ところが情シスに直接聞くと、止めているのではなく「何を確認すればよいか分からないので、判断できない」と言います。
判断できない理由は、AI ベンダーの規約が英語で長く、製品ごとに違うからです。同じ Claude でも、個人向けアプリ、法人向けプラン、API、AWS 経由では、学習利用・保持期間・保存地域の扱いが異なる。「AI に渡していいか」という問いには一般解がなく、どの製品を、どの経路で、どの設定で使うかを決めて初めて答えが出ます。なお、この記事で言う「外に出さない」は、自社のサーバーに閉じ込めることではなく、モデルの学習に使われず、処理地域と保持期間を自社の契約で決められ、アクセスの記録が自社の管理下にある状態を指します。
もう1つの共通点は、データの話が最後に出てくることです。PoC で止まる会社の記事で「後出しの権限・監査要件」を本番に乗らない原因に挙げました。データの扱いも同じで、PoC が動いた後に「本番データは外に出せない」と分かると、構成を組み直すことになる。失敗パターンの記事の⑥「本番データを使わず検証」と⑦「権限・監査を後回し」は、原因をたどるとこの記事の6項目が着任前に決まっていなかったことに行き着きます。
最初に決める6項目——誰が決め、決まっていないと何が起きるか
6項目を表にします。「誰が決めるか」が空欄のまま情シスに丸投げされると、情シスは判断者ではないので止まる。「根拠」が公式ページではなく営業資料だと、監査で使えない。
| # | 決めること | 決める人 | 根拠の取り方 | 決まっていないと起きること |
|---|---|---|---|---|
| ① | 入力したデータがモデルの学習に使われないか | 情シス（確認） | ベンダーの公式ページ（利用規約・プライバシーセンター）を保存する | 噂で全面禁止になる。逆に個人向けプランを業務で使う |
| ② | データがどの国・地域で処理・保存され、何日残るか | 情シス（確認）、経営（許容範囲の判断） | 公式ページの処理地域・保持期間・不正利用監視の項 | 「海外に出せない」と「クラウドだから同じ」が平行線になる |
| ③ | 誰が、どのデータを AI に渡してよいか | 業務部門長（項目）、情シス（権限の実装） | 既存の権限表と、この記事の⑤の分類 | 全員が全部渡せるか、誰も何も渡せないかのどちらかになる |
| ④ | AI への入出力の記録をどこに何日残すか | 情シス、監査対応の担当（経理・内部監査） | ベンダー側の管理者ログの仕様と自社側の記録の設計 | 「誰が何を入れたか」が追えず、事故時に範囲を特定できない |
| ⑤ | 個人情報・要配慮個人情報・機密（原価・給与・取引条件）の分類と、どこまで渡すか | 業務部門長、法務・総務 | 個人情報保護法の定義と社内の情報区分規程 | 取引先名や従業員名が機密扱いされない。または全部機密扱いで何も渡せない |
| ⑥ | やめるとき、ベンダー側と自社側のデータをどう消すか | 情シス、経営（契約） | 公式ページの削除・退会時の扱いと契約書 | 解約後もベンダー側にデータが残る。自社側の中間ファイルが残る |
①②④は公式ページを読めば事実として書けます。判断ではなく確認の作業で、FDE が着任前に情シスと一緒に済ませられる。③⑤⑥は社内の判断です。AI の知識は要らず、既存の権限表と情報区分の規程と、それを決める人が要る。この分け方をするだけで「情シスが止めている」状態は解消することが多い。情シスは①②④を確認し、③⑤⑥を業務部門と経営に返せばよいからです。
公式ページと法令で確認できる事実——5社の規約、個人情報保護法、注意喚起
Anthropic・OpenAI・Microsoft・Google・AWS の公式ページ
2026年9月5日時点で各社の公式ページで確認できた範囲だけを書きます。規約は改定されるので、実際に決めるときは同じページを開き直し、確認日と一緒に保存してください。
| ①学習に使われるか | ②保持・処理地域 | ④不正利用監視のログと止め方 | |
|---|---|---|---|
| Anthropic（Claude API・法人向けプラン） | 既定では商用製品（Claude for Work、API 等）の入出力を学習に使わない。利用者が評価ボタン等で明示的にフィードバックを送った場合は例外 | API は既定で受信・生成から30日以内に入出力を削除。ゼロデータ保持契約等の別途合意があればそれに従う。フィードバック送信分は最長5年、規約違反分は最長2年 | ゼロデータ保持は別契約。対象製品は個別の案内ページで確認する |
| OpenAI（API） | API に送ったデータは明示的に共有を選ばない限り学習に使わない | 不正利用監視のログを最長30日保持。保存地域は米国・欧州・日本・シンガポール等から選べ、2026年3月5日以降公開のモデルでは地域指定に10%の上乗せ料金 | ゼロデータ保持（ZDR）は対象エンドポイントが限定され、OpenAI の事前承認と追加要件の受諾が必要 |
| Microsoft（Azure OpenAI／Foundry） | 入出力は OpenAI にも他の顧客にも渡らず、基盤モデルの学習に使われない | 顧客が指定した地理内で処理。Global／DataZone と付く配置種別を選ぶと処理地域が広がる。保存データは AES-256 で暗号化、顧客管理鍵も選べる | 検知時はプロンプトが人の確認のため同じ地理内に保存される。申請して承認されると止められ、設定値（ContentLogging=false）で確認できる |
| Google Cloud（Vertex AI。現在の名称は Gemini Enterprise Agent Platform） | 事前の許可・指示なく顧客データをモデルの学習・微調整に使わない。GA 前のモデルも同じ | 入出力の記録は既定で無効。会話状態を保持する API は既定で保存が有効なので、ゼロデータ保持にするなら明示的に無効にする。Google 検索グラウンディングを使うと記録が最長3日残り、止められない | 不正利用監視のためのプロンプト記録は、対象の場合に例外申請できる |
| AWS（Amazon Bedrock） | モデル提供元は AWS 上の配置用アカウントにアクセスできず、顧客のプロンプトと応答を見られない | 保持は「none（保持しない）」「default」「aws_review」等のモードから選ぶ。一部のモデル（Claude Fable 5・5.1）は AWS による人の確認が利用条件で、入出力が AWS の境界内に最長30日保持される。提供元には渡らない | 組織のポリシー（SCP）で「none 以外を禁止」と強制できる。保持が要るモデルはその設定下では利用不可になる |
読み取れることは3つです。第一に、主要5社とも、商用の API・法人向けサービスでは既定で学習に使わないと公表している。「AI に入れると学習される」は、主に個人向けアプリの初期設定の話です。第二に、学習利用とは別に、不正利用の監視のためのログ保持がある。30日という数字が複数社で出てくるのはこのためで、「学習に使わない」だけ読んで「保持しない」と書くと監査で突かれます。第三に、同じモデルでも経路で条件が変わる。Claude を Anthropic から直接使う場合と Bedrock 経由では、保持の条件と人の確認の有無が違い、モデルの世代でも変わる。ベンダー名ではなく、製品・経路・モデル・設定の4つで記録します。Google の検索グラウンディングのように、付加機能を有効にするとログの条件が変わるものもあるので、④のログ設計には付加機能の有無も書き込む。
個人情報保護法と個人情報保護委員会の注意喚起
ここに書くのは条文と公表資料の整理で、個別の事情で扱いは変わります。運用に落とす前に顧問弁護士か個人情報保護に詳しい専門家に確認してください。
個人情報保護委員会は2023年6月2日に「生成AIサービスの利用に関する注意喚起等」を公表しています。個人情報取扱事業者向けの注意点は2つ。①個人情報を含むプロンプトの入力は、特定された利用目的を達成するために必要な範囲内であることを十分に確認する。②本人の同意なく個人データを含むプロンプトを入力し、応答結果の出力以外の目的で取り扱われる場合は法の規定に違反する可能性があるため、サービス提供事業者が当該個人データを機械学習に利用しないこと等を十分に確認する。前の表の①列は、この「十分に確認」を公式ページで行った結果にあたります。
条文で押さえるのは、当社の整理では5つ。利用目的による制限（第18条）、利用する必要がなくなった個人データを遅滞なく消去するよう努めること（第22条）、安全管理措置（第23条）、委託先の監督（第25条）、そして外国にある第三者への提供の制限（第28条）。第27条第5項第1号には、利用目的の達成に必要な範囲内で個人データの取扱いを委託することに伴って提供される場合、提供先は第三者に該当しない旨が定められています。AI ベンダーへの入力がこの「委託」にあたるかは契約とサービスの設計で変わるため、断定しません。ただ、6項目の②が第28条に、④⑥が第22条・第23条に、③が第25条の監督の設計に対応する。6項目を決めることが、そのまま法対応の材料になるように項目を選んでいます。
総務省・経済産業省の「AI事業者ガイドライン」は2026年3月31日に第1.2版が公表されています。AI 利用者向けの項目には、個人情報を不適切に入力しないこと（U-4）、機密情報等を不適切に入力しないこと（U-5）、AI 提供者から提供された文書を適切に保管・活用し、サービス規約を遵守すること（U-7）が挙げられている。「不適切に」の中身を自社で定義したものが③と⑤です。ガイドラインは何が不適切かを決めてくれないので、社内で決めるしかない。
構成パターン3つ——SaaS API 直結・クラウド事業者経由・自社環境内
6項目を決めた後、それを満たす構成を選びます。SaaS API 直結（A）、クラウド事業者経由（B）、自社環境内（C）。どれが正しいかではなく、6項目の答えでどれが最短かが決まる。
| A. SaaS API 直結 | B. クラウド事業者経由 | C. 自社環境内 | |
|---|---|---|---|
| 経路 | 自社システムから Anthropic・OpenAI 等の API を直接呼ぶ | Azure・AWS・Google Cloud 上でモデルを呼ぶ（Azure OpenAI、Bedrock、Vertex AI 等） | 自社のサーバーや契約したデータセンターで公開されたモデルを動かす |
| ①学習利用 | 商用 API は既定で学習に使わない（各社公式） | モデル提供元にデータが渡らない構成（Azure・AWS の公式記述） | 外部に出ないので該当しない |
| ②処理地域・保持 | 保持は30日等の既定。処理地域の指定は提供元で選べる範囲が異なる | 処理地域を契約地域に固定できる。保持モードを選べる（AWS）、監視ログの停止を申請できる（Azure・Google） | すべて自社で決める。決めないと何も残らない、または全部残る |
| ④ログ | 自社側で入出力の記録を設計する必要がある | クラウドの既存の監査ログ（操作履歴）に乗せられる | 自社で全部作る |
| 向くデータ | 個人情報・機密を含まないか匿名化した業務データ。社外向け文書の下書き等 | 経理・人事・取引先を含む月次の業務データ | 契約上・規制上、外部処理が認められないデータ |
| 注意点 | 付加機能で条件が変わる | 配置種別（Global 等）で処理地域が広がる。モデルごとに保持の条件が違う | モデルの精度・更新・GPU の費用・運用要員がすべて自社持ち |
当社の判断基準を書きます。従業員100〜300人の中堅企業で、対象が経理の月次・人事の手続き・案件管理のような社内業務データなら、当社の目安では B で足りる場合が多い。②の処理地域と保持を契約で固定でき、④のログを既存のクラウドの操作履歴に乗せられ、モデル提供元にデータが渡らないことを公式ページで示せるからです。A は最新モデルが早く使えますが、個人情報や取引条件を含むデータを渡すには③⑤の分類が厳密でないと使いにくい。C は規制や契約で外部処理が認められない場合か、量と機密度が費用に見合う場合に限られる。「セキュリティが心配だからオンプレミス」と最初から決めるのは、6項目を決めずに構成だけ決めている状態で、費用と精度の両方で不利になります。
B を選んでも、AI に渡す前の段階で③⑤の分類が要ることは変わりません。当社が伴走した一例では、経理データを AI に渡す際に「取引先名は渡す、担当者の個人名は渡さない、銀行口座は渡さない」という項目単位の線引きを、経理責任者と情シスで決めてから試作に入りました。経理の月次を FDE 方式で本番化する記事で書いた「入力→判断→出力」の分解の「入力」に、この線引きが入ります。
FDE 方式での進め方——情シスの3つの一覧に「データの扱い」を足す
受け入れ側の体制の記事で、情シスが FDE の着任前に出す3つの一覧を書きました。データの持ち主、権限、監査要件です。この記事の6項目は、この3つの一覧に「AI に渡すときの条件」の列を足す形で接続します。新しい書類を作らず既存の一覧に列を足すのは、着任1週間の記事の Day3 で書いたとおり、一覧が分散すると更新されなくなるからです。
| 情シスが出す一覧（既存） | 足す列 | 対応する項目 | 誰が埋めるか |
|---|---|---|---|
| データの持ち主（どのマスタを誰が直せるか） | AI に渡してよい項目、渡さない項目、匿名化して渡す項目 | ③⑤ | 業務部門長が項目を決め、情シスが実装する |
| 権限（誰が何を見られるか） | AI を使える人の範囲。AI 経由で見られる範囲が既存の権限を超えないこと | ③ | 情シス。既存の権限表の写しでよい |
| 監査要件（誰がいつ何をしたかの記録） | AI への入力と出力の記録をどこに何日残すか、ベンダー側のログとの役割分担 | ④ | 情シスと、監査対応の担当（経理・内部監査） |
| （新規）ベンダー確認記録 | 製品・経路・モデル・設定ごとの①②④の確認日と該当ページ | ①②④⑥ | FDE と情シスで着任前に作り、変更のたびに更新 |
着任前に決めるのは、上3行の「足す列」の初期値と4行目の確認記録です。完璧でなくてよく、「分からない」と書いた行は週次で決める論点にする。データの扱いだけ特別な会議体は作りません。
着任後の最初の2週間で FDE がやることは3つです。1つ目は、本番データの1か月分から⑤に沿って渡さない項目を落とし、匿名化する項目を置き換えた「試作用の本番データ」を作ること。ダミーでは表記ゆれや例外が出ないからで、[失敗パターンの記事]({FAIL})の⑥と同じ理由です。2つ目は、④のログを動くものと同時に入れること。後から足すと画面より下を組み直すことになる。3つ目は、⑥の削除手順を試作の段階で1回試すこと。退役時に初めて消し方を調べる会社は、消せずに残します。
経営が決めるのは②の許容範囲と⑥の契約条件です。「海外で処理されてよいか」は情シスが決められない。国内処理に固定すると費用や選べるモデルが変わることがあるので、その差を FDE と情シスが数字で出し、経営が週次で決める。
経理データ・人事データでの具体例
6項目を経理と人事のデータに当てはめます。項目単位の線引きの例として読んでください。
経理の月次（仕訳・請求・入金消込）
AI に渡す候補は、請求書の画像、入金明細、仕訳の候補、取引先マスタです。⑤の分類では、取引先名と金額は「機密だが渡す」、担当者の個人名とメールアドレスは「渡さない、または置き換える」、銀行口座番号は「渡さない」が当社の目安です。口座番号は仕訳を切るのに要らない。要らないものは渡さない、が原則になる。②は処理地域を固定した B 構成にし、保持を既定の30日で許容するかゼロ保持を申請するかを経営が決める。④は、AI が作った仕訳候補と承認した人・日時を、会計ソフト側の承認履歴と AI 側の入出力記録の両方に残す。片方だけだと「何を根拠に候補を出したか」か「誰が承認したか」のどちらかが残らない。
⑥は経理では見落とされやすい。AI に渡した請求書の画像やテキストが試作の途中で共有フォルダに残り、本番後も残り続ける。当社は試作の終了時と本番移行時の2回、中間ファイルの削除を手順に入れています。残すべき記録と残してはいけない中間ファイルの区別は、経理の月次の記事の「承認履歴と変更の記録を最初から入れる」の節と合わせて読んでください。
人事（入退社手続き・勤怠・評価）
人事データは経理より⑤の分類が厳しくなります。個人情報保護法第2条第3項で定義される要配慮個人情報（病歴等）が含まれうるため、当社は健康診断の結果や休職の理由を「渡さない」に分類します。給与と評価は「機密。渡すなら本人が特定できない形」。入退社手続きの書類のチェックや就業規則に関する社内質問への一次回答のように、個人が特定されない業務から入るのが当社の順番です。③は、人事データを AI に渡せる人を人事部門の数人に限定し、AI 経由で他部門が見られないことを既存の権限表で確認する。AI を入れた結果として権限が広がってはいけない。
④のログが効くのは、AI の出力を評価に使う場面です。AI 事業者ガイドラインの U-7 には、AI の出力を特定の個人の評価の参考にする場合、本人に通知し、人間による合理的な判断のもとで説明責任を果たす趣旨の項目があります。評価に使わないなら、使わないことを③の範囲で決める。使うなら通知と説明の手順を④と一緒に設計する。データの漏えいの経路そのものは、AI エージェントが企業データを漏らす5つの経路に別途整理しています。
まとめ
「AI にデータを渡していいのか」は、渡す・渡さないの二択ではなく6項目を決める作業です。①学習に使われないか ②保存地域と保持期間 ③誰がどのデータを渡せるか ④ログの残し方 ⑤個人情報・機密の分類 ⑥退役時の削除。①②④は公式ページで確認できる事実で、主要5社とも商用サービスでは既定で学習に使わない旨を公表している。ただし不正利用の監視のためのログ保持は別枠にあり、経路とモデルの世代で条件が変わる。③⑤⑥は社内の判断で、既存の権限表と情報区分と、それを決める人が要る。
FDE 方式では、6項目を着任前に情シスの3つの一覧へ列として足し、分からない行は週次の論点にします。構成は6項目の答えで決まり、中堅企業の経理・人事のデータなら多くの場合はクラウド事業者経由で足りる。データの扱いを最後に決める会社は本番の手前で止まり、最初に決める会社は試作の初日から本番の形をしたデータで動かせます。決めるのは AI の専門家ではなく、データの持ち主です。
FDE を募集しています（会計FDE／FDE・業務システム）
経理の月次をAIで本番まで持っていく「会計FDE」（会計士・経理責任者・管理部門経験者）と、要件が固まる前に動くものを出して本番まで運ぶ「FDE（業務システム）」（ITコンサル・PM/PL・情シス出身者）を正社員で募集しています。応募でなくても構いません。まず30分の「キャリア相談」から。採用のお問い合わせフォームに「キャリア相談希望」と書いて送ってください。
データを外に出さずに AI を本番で使う構成を、情シスと一緒に決めます
学習利用・保存地域・保持期間・権限・ログ・削除の6項目を貴社の既存の権限表と情報区分に沿って着任前に整理し、3つの構成のどれで進めるかを費用と精度の両面から比較します。経理 AX・kintone・案件管理システム刷新・Claude 導入で本番稼働まで伴走した経験をもとに、経理・人事データの線引きからログ設計、退役時の削除手順までご相談いただけます。