AI コーディングツールのデータ管理：
導入前に確認すべき質問リスト
まずデータを 3 分類（ソース、シークレット、顧客データ）し、そのうえで契約に書くべき 5 つの質問をベンダーに投げます。自分で検証できるのはそのうち 2 点だけで、残りは書面の条項に依存します。口頭の約束は監査で根拠になりません。
先に決める 4 つの数字
まずデータを分ける
ソースそのもの、コード内のシークレットや認証情報、コードが抱えている顧客データ —— 感度も対処も別物です。
契約に書くべき項目
どこに置かれるか、どれだけ保持されるか、学習に使われるか、誰が読めるか、事故時にいつ知らされるか。欠けた分だけ監査で空白になります。
自分で検証できること
リクエストが実際にどのエンドポイントへ届くか（クライアント設定かパケットキャプチャ）と、通信が終端まで TLS か。それ以外は条項頼みです。
書面の根拠
法務や監査に見せられるのは文書だけです。営業の口頭説明やコミュニティの伝聞は根拠になりません。
AI コーディングの管理は一般的な SaaS と違う
一般的な SaaS では業務データを預けますが、AI コーディングで送るのはソースそのもので、ファイルやディレクトリ構造ごとということも珍しくありません。厄介なのは、ソースが他のものを一緒に連れていく点です。ハードコードされた鍵、接続文字列、テストに使った実顧客データ、社内のホスト名。これらがコンテキストと一緒に外へ出れば、露出は「コードを見られた」だけでは済みません。ですから最初にやるべきはベンダーへの質問ではなく、自社リポジトリに何が入っているかの把握です。
購入前に固めるべき 5 点
① データがどの法域に置かれ、越境するのか。② リクエストとレスポンスがどれだけ保持され、停止できるのか。③ モデルの学習や評価に使われるのか。④ ベンダー内部の誰が、どんな条件で読めるのか。⑤ 事故が起きたとき、どれだけ早く、誰に通知されるのか。5 点とも書面で入手してください。利用規約でもデータ処理付属書（DPA）でも契約書でも構いませんが、法務に渡せる文書である必要があります。口頭のみの回答は空白と同じ扱いにします。
3 段階、順番を逆にしない
まず内側：接続予定のリポジトリを走査し、ハードコードされた鍵、実顧客データ、社内ホスト名を取り除きます。この効果はどのベンダーを選ぶかに依存せず、鎖の中で唯一完全に自社で制御できる部分です。
次に外側：上の 5 つの質問を候補ベンダーに送り、書面での回答を求めます。並行して、検証できる 2 点 —— 実際の到達先エンドポイントと通信が終端まで暗号化されているか —— を自分で確かめます。
最後に文書化：保持期間、学習用途、通知期限を契約または DPA に書き込みます。「通常は行いません」程度の表現しか得られない場合は、「行う」前提でリスクを評価してください。
自分で検証できること vs 条項頼みのこと
自分で検証できる
① クライアント設定のエンドポイントがどこを向いているか（環境変数・設定ファイル・パケットキャプチャで分かります）。② 通信が終端まで TLS か。③ レスポンスで返るモデルが依頼したものと一致するか。④ 課金の基準が usage と合うか。いずれも技術的事実で、一度試せば決着します。
条項頼み
① データが物理的にどの法域にあるか。② 実際の保持期間と満了時の削除方法。③ 学習や評価のデータセットに入るか。④ 内部のアクセス権限がどう分割されているか。⑤ どこに再委託されているか。いずれもクライアント側からは観測できません。測ろうとせず、契約上の論点として扱ってください。
ベンダー直接調達 vs 再販・ゲートウェイ経由
ベンダーのサービスを直接購入
条項の連鎖が最短で相手方が明確です。法人プランでは DPA、監査ログ、保持設定が用意されることが多い。代償は参入条件（地域・席数・契約最低額）と、決済・請求書の形式が自社の経理要件に合わない可能性です。
再販事業者または自前ゲートウェイ経由
参入と決済の問題は解けますが、経路が 1 段増えます。リクエストが第三者を通るため、評価軸は「その層が何をして、何を保持し、どこに明記されているか」になります。再販事業者は上流の公式チャネルではなく、上流に代わって条項を約束することもできません。上流の利用規約は引き続き適用されます。
答えられる形に質問を書き換える
「安全ですか」ではなく、はい／いいえで答えられ、契約に書ける形で聞きます。「リクエスト本文とレスポンス本文は何日保持されますか」「保持期間中、どの役割がアクセスできますか」「いかなる形であれモデルの学習や評価に使いますか」「データはどの法域に置かれますか」「セキュリティ事故の通知期限は何時間ですか」。回答は日付とともに保管します。後で説明が変わっても、比較の基準が残ります。
QCode では（確認できることだけ）
当社は複数モデルの API を再販するプラットフォームです。リクエストは最終的に Anthropic、OpenAI、Google などの公式 API が処理します。当社は自社モデルを開発しておらず、お客様のリクエストで学習も行いません。課金の根拠はレスポンスの usage で、請求は 1 件ずつ突き合わせ可能です。サイト内 /enterprise のセキュリティ説明には、ユーザーのコード・会話内容・業務データを保存せず、リクエストは上流 API へ透過的に転送し、途中でデータをキャッシュしないと明記しています（料金ページの「キャッシュの恩恵」は上流モデル公式の prompt キャッシュ課金割引を指し、当社の保存とは無関係です）。これは書面であり、法務に提示できます。当社はいずれの上流の公式チャネルでもなく、上流に代わって条項を約束することもできません —— 各社の利用規約は引き続きお客様に適用されます。保持期間やアクセス制御の具体は当社の利用規約に従います。法人調達で書面が必要な場合は商務のやり取りで併せてご相談ください。
よくある質問
AI コーディングツールを使うと、ソースは学習に使われますか？
通る経路と、そこに紐づく条項によります。テストで答えが出る種類の問いではないため、経路上のすべての当事者から書面を取ってください。当社に関して言えば、自社モデルを開発しておらず、お客様のリクエストで学習も行いません。上流各社の方針は各社の公式規約が優先します。
リクエストが想定どおりのエンドポイントに届いているか確認するには？
クライアント設定のエンドポイント変数を確認し、必要ならパケットを一度取ります。これは自分で決着できる数少ない事実の 1 つです。返ってきたモデル名にリクエストになかった接頭辞やプロバイダ名が付いていれば、途中に書き換え層があり、確認する価値があります。
最初にやるべきことは何ですか？
接続予定のリポジトリを走査し、ハードコードされた鍵・実顧客データ・社内ホスト名を除去することです。ベンダー選定に依存せず効果があり、鎖の中で唯一完全に自社の制御下にある工程です。
ベンダーが「データは保存しません」と言えば十分ですか？
不十分です。保持日数、満了時の処理、適用範囲を明記した書面の条項を取得してください。口頭の約束は監査で根拠になりませんし、「通常は行いません」といった表現は「行う」前提でリスク評価すべきです。
再販事業者は上流に代わってコンプライアンスを約束できますか？
できません。再販事業者が約束できるのは自層が何をして何を保持するかだけです。上流の利用規約はエンドユーザーに適用され続けます。「上流の認可を得て代わりに約束できる」という主張には、その根拠となる文書を求めてください。
チームで形骸化させないには？
具体的に 3 つ。① CI にシークレットスキャンを入れ、新たなハードコード認証情報が入らないようにする。② 人ごと・パイプラインごとに個別の API キーを配り、事故時に出所を追えるようにする。③ 保持期間と通知期限をメールではなく調達契約に書き込む。
情報源
本ページは購入側の質問リストであり、各ベンダーの具体的な数値は再掲しません。保持・学習用途・アクセス制御は各社の利用規約とデータ処理付属書が優先し、変更されます。QCode 自身に関する記述（再販という位置づけ、自社モデルなし、課金の根拠）は当社の利用規約と料金ページに基づきます（2026-09-02 確認）。
関連記事
その AI API 中継は使う価値があるか
4 つの自己検証：倍率換算、キャッシュ命中、model の返り値、usage の突合。
チームで AI コーディング API を買う
プール型クォータ、並列上限、サブキーによる使用量の割り当て。
MCP のセキュリティとサンドボックス
エージェントにツールを開放するときの権限境界と分離。
本ページは購入側の自己点検フレームであり、法的助言ではなく、いかなるベンダーの条項を代表するものでもありません。実際の判断は各当事者の書面条項、所在地の法令、および貴社法務の意見に従ってください。