AI製品36件の規約を徹底解剖：録音・画像・コードはどこまで学習されるのか

「会議の録音をAIにアップロードしていいか？」という問いに対し、即答できるエンジニアはどれほどいるだろうか。多くの現場では「なんとなく大丈夫そう」「ChatGPTの法人版だから安心」といった、根拠なき楽観論が支配している。しかし、今回36件のAI製品の規約を詳細に調査した結果、その実態は極めて断片的かつ製品ごとにバラバラな「規約のパッチワーク」であることが浮き彫りになった。我々エンジニアは、コードのデバッグには執念を燃やす一方で、自らの業務データを預けるプラットフォームの規約という『仕様書』を、驚くほど読み飛ばしているのではないだろうか。

調査対象となった36製品のうち、入力データの形式（録音、画像、PDF、コードなど）ごとに明確な記述があるのはわずか14件に過ぎない。残りの22件は、形式による区別を明記しておらず、文字情報と同じ扱いとみなすのが妥当だ。ここで重要なのは、空欄が「使わない」を意味するのではなく、「何も規定していない」というリスクの空白地帯であるという点だ。例えば、Geminiは個人版とWorkspace版でデータの扱いが明確に逆転している。個人版では音声や画面共有を学習に利用する可能性がある一方、Workspace版ではアップロードしたファイルは学習に使われない。この「エディションによる逆転現象」を理解せずに、個人の感覚で業務データを投入することは、セキュリティ上のデッドロックを自ら引き起こす行為に等しい。

さらに深刻なのは、メタデータやフィードバックの扱いだ。特に「いいね（👍）」ボタンを押すという何気ないUI操作が、製品によっては「フィードバックとして保存され、学習に利用される」というトリガーになっている。Claudeのようにオプトアウトしていてもフィードバックは学習に使われるケースや、Geminiのように履歴をオフにしても最長72時間は保存されるケースなど、製品ごとの挙動はまさにスパゲッティコードのように複雑怪奇だ。我々が「便利だから」と安易にクリックしているそのボタンが、実は機密情報の漏洩経路になっている可能性を、常に疑うべきである。

録音、写真、PDF、コード。これらのデータ形式は、AIにとって単なる「入力」ではない。製品によって、これらは「学習の糧」にもなれば「保護されるべき機密」にもなる。調査結果から見えてきたのは、特定の形式を明言する企業は全形式を網羅的に記述する傾向があるという事実だ。例えばGeminiは、音声・画像・ファイル・いいねの4形式すべてについて詳細な規約を設けている。一方で、多くの製品は形式ごとの区別を曖昧にしており、これが現場での誤解を招く最大の要因となっている。

以下の表は、個人版と法人版でデータの扱いが明確に異なる代表的な例である。この差異を無視して「このAIは安全だ」と断じることは、技術者としてあまりに無責任と言わざるを得ない。

また、コードの扱いについても注意が必要だ。Cursorのようにコードベースやプロンプトを名指しで管理する製品もあれば、GitHub Copilotのように入力・出力・関連コンテキストまでをスコープに含める製品もある。開発者が「コードを貼り付けただけだから大丈夫」と考えるのは危険だ。そのコードがAIのモデル改善に利用され、将来的に他者の生成結果として断片的に出力されるリスクを、我々は常に考慮しなければならない。特に、APIキーや環境変数が含まれたコードを誤って送信してしまった場合、それは単なるヒューマンエラーではなく、規約という名の『仕様』によって正当化された情報漏洩へと発展する。

結局のところ、製品名だけで安全性を語ることは不可能だ。エディション、設定、そしてフィードバックの有無という変数が複雑に絡み合い、その時々の規約によって挙動が定義される。我々エンジニアが明日から取るべき対策は、製品のブランド名を信じることではなく、利用する各製品の「最新の規約」を、少なくともデータ形式の観点から再確認することだ。そして、もし規約が曖昧な製品であれば、それは「使わない」のではなく「いつ使われても文句が言えない」状態であると認識し、機密情報を入力しないという『防衛的プログラミング』の精神を、AI利用においても徹底すべきである。

ここまで規約の細部を掘り下げてきたが、最後に我々エンジニア自身に突きつけたい問いがある。それは「AIの進化という不可逆な流れの中で、我々はどこまでリスクを許容し、どこからを『越えてはならない一線』とするのか」という点だ。規約を読み込むことは、確かに重要だ。しかし、規約は常に更新され、ベンダーの都合で書き換えられる。規約を読んだからといって、技術的な安全性が担保されるわけではない。真のセキュリティとは、規約の解釈に依存するのではなく、データそのものを匿名化・マスキングし、AIに渡す前に「汚染」を取り除くという、エンジニアリングによる物理的な防御にあるのではないだろうか。

DX Suiteのように、学習前に氏名や電話番号をマスキングする機能を備えた製品がある一方で、多くの製品はユーザーの良心に委ねている。我々は、AIを「魔法の箱」として扱うのをやめ、入力データがどのようにモデルの重みを更新し、それがどのように他者の出力に影響を与える可能性があるのかという、AIのライフサイクル全体を俯瞰する視点を持つ必要がある。深夜の障害対応でログをAIに投げ込む際、そのログに顧客の個人情報や秘密鍵が含まれていないか、一瞬でも立ち止まって考える。その「一瞬の躊躇」こそが、現代のエンジニアに求められる最も高度なスキルセットかもしれない。

最後に、読者諸氏に実践的な処方箋を提示したい。まず、現在業務で利用しているAI製品のリストを作成し、それぞれの「法人版/有料版」への切り替えを検討すること。次に、フィードバック機能（👍/👎）が学習に与える影響を各製品のヘルプで確認し、必要であれば組織全体でフィードバックを無効化する設定を徹底すること。そして何より、AIを「信頼できる同僚」ではなく「規約という不確実なルールで動く外部サービス」として扱い、機密情報の取り扱いには常にゼロトラストの精神を適用することだ。AIの利便性を享受しながら、同時に自らのキャリアと組織の資産を守り抜く。この矛盾する二つの命題を両立させることこそが、これからの時代を生き抜くエンジニアの責務ではないだろうか。あなたは、今日入力したそのデータが、明日どこで誰の回答として出力されても後悔しないと言い切れるだろうか。