「ちょっとだけなら…」と思って、会社や案件のコードをChatGPTに貼っていませんか？
「エラー修正の相談に、ログごと貼った」「仕様書の一部を貼って要約させた」——これ、やり方を間違えると情報漏えいと契約違反（NDA）の地雷になりやすい行動です。
結論から言うと、AIを安全に使う鍵は“技術”より運用です。
①許可を取る → ②入力ルールを決める → ③匿名化・最小化する → ④検証する → ⑤記録を残す。この型さえ作れば、AIは副業でも強い味方になります。
※重要：本記事は一般情報です。NDA・就業規則・委託契約・セキュリティ規程によって結論が変わります。最終判断は契約書・社内規程・クライアント指示に従い、必要に応じて法務/専門家に確認してください。
- 一番危ないのは会社/案件の「非公開コード」「ログ」「仕様」をそのままAIに貼ること
- 「学習に使われない設定」でもNDA違反になり得る（契約は別問題）
- 個人向けChatGPTは、設定で学習利用（モデル改善）をオフにできる
- OpenAIのAPIや、ChatGPT Team/Enterpriseなどのビジネス向けは原則として学習に使われない（デフォルト）
- 守りの型は入力禁止リスト＋匿名化＋最小再現（MRE）＋検証＋ログ
なぜ「会社のコードをAIに貼る」のが危ないのか
危ない理由1：AIへの入力は「第三者提供」になり得る
ChatGPTなどの生成AIは、会社/クライアントから見れば基本的に外部サービスです。NDAや基本契約に「第三者への開示禁止」「再委託禁止」などが入っている場合、AIへの入力が契約違反になり得ます。
ツールの設定（学習オフ）とは別次元の話なので、まず契約を起点に考える必要があります。
危ない理由2：「学習されない」＝「漏えいしない」ではない
たとえ学習利用をオフにできても、次の事故は残ります。
- プロンプト履歴の誤共有（画面共有/スクショ/共同作業）
- ログにキーや内部URLが混ざっていた
- 社内ルール違反（許可なく外部ツールを使った）
つまり、事故の大半は運用のミスで起きます。
危ない理由3：「シャドーIT」になりやすい
会社が把握・承認していないツールを業務に持ち込む行為は、一般にシャドーITと呼ばれます。シャドーITは利便性が高い一方で、IT部門の監視や統制が効かず、リスクが増えるとされます。
（例：個人アカウントのクラウド、未承認の外部サービスに業務データを入れる等）
危ない理由4：コードには「著作権」と「営業秘密」が混ざる
プログラムは著作物になり得ますし、設計・ロジック・ノウハウは営業秘密（非公開の価値ある情報）になり得ます。
AIに貼る行為は、便利さの裏で権利・秘密の塊を外に出す行為になりがちです。
まず確認：あなたが守るべきルールは「3階建て」
安全運用を作るとき、見るべきルールは次の順番です（ここを間違えると事故ります）。
- ①社内ルール：就業規則、情報セキュリティ規程、生成AIガイドライン
- ②契約：NDA、基本契約、業務委託契約、発注書の特約（AI禁止など）
- ③ツール規約：ChatGPT/他AIのデータ保持・学習利用・共有範囲
多くの人が③（ツール設定）だけ見て安心しがちですが、事故るのは①②です。
特にNDAには「外部AI入力禁止」「国外移転禁止」「再委託禁止」などが入り得ます。まずはここを確認してください。
ChatGPTの学習利用オプトアウト：最低限ここは押さえる
個人向けChatGPT：設定で「モデル改善」をオフにできる
ChatGPTは設定（Data Controls）で「モデル改善」相当の項目をオフにできます。オフにすると、新しい会話がモデル改善（学習）に使われない扱いになります。
ただし重要：これを設定しても、会社/クライアントの契約で「外部AIに入力禁止」ならアウトです。設定はリスク低減であって許可ではありません。
ChatGPT Team/Enterpriseなど「ビジネス向け」はデフォルトで学習利用されない
OpenAIは、ビジネス向け（ChatGPT Team/EnterpriseやAPIなど）について、原則として組織のデータを学習に使わない（デフォルト）という扱いを案内しています。会社で導入されている場合は、個人アカウントよりも承認済みの業務用プランを使うほうが説明しやすく、安全側になりやすいです。
OpenAI API：原則、送信データは学習に使われない（オプトイン除く）
OpenAIは、APIに送ったデータについて「明示的にオプトインしない限り、学習に使用しない」と説明しています。
だからといって無条件に安全という意味ではありませんが、“社内でAI活用を通す”ときには「個人チャットより、業務用の枠組みで統制しやすい」ケースがあります。
安全にAIを使う「仕組み化」5ステップ（全体像）
まずは流れを固定します。ここをテンプレ化するだけで、事故率が下がります。
【安全運用フロー（仕組み化）】
①許可を取る（社内/契約/クライアント）
↓ ②入力ルールを決める（入力禁止リスト）
↓ ③匿名化・最小化する（要件メモ／最小再現MRE）
↓ ④検証する（テスト／レビュー／変更1点）
↓ ⑤記録を残す（許可ログ／検証ログ／作業メモ） ステップ1：AI利用の「許可」を文章で取る（口頭は弱い）
会社員副業でも受託でも、まずはAI利用の可否を明確にします。理想は契約書・発注書・NDAの特約に落とすこと。最低でもチャットやメールで記録を残します。
クライアントに確認する質問例（コピペOK）
生成AIの利用可否について確認させてください。
【利用目的】
一般的な改善提案、テストケース案、ドキュメント整形、デバッグ方針の整理
【入力方針】
機密情報・個人情報・非公開コードは入力しません
匿名化・最小化（最小再現コード/MRE、抽象化メモ）した情報のみを入力します
【運用】
出力は人間がレビューし、テストで検証してから採用します
必要に応じて作業ログを提出可能です
上記の範囲でAI利用は可能でしょうか？
NGの場合、禁止範囲（例：AI自体不可／コード入力のみ不可／社内ツールのみ不可等）もご指定ください。
ステップ2：入力禁止リストを作る（迷ったら禁止）
副業での事故はだいたいここから起きます。迷うなら、まず禁止にしてください。
- 非公開のソースコード（会社のリポジトリ、クライアント案件、社内ツール）
- 認証情報（APIキー、トークン、Cookie、秘密鍵、証明書、パスワード）
- 顧客情報/個人情報（氏名、メール、住所、ID、注文履歴など）
- 内部URL/管理画面情報（管理画面URL、IP、構成図、脆弱性情報）
- 未公開仕様（要件定義、契約条件、単価、取引先名、提案資料）
- ログの生貼り（パス、内部ドメイン、キーが混ざりやすい）
ステップ3：匿名化メモ＋最小再現（MRE）で相談する
安全にAIの力を借りるコツは、会社コードそのものを貼らずに、抽象化した情報と再現できる最小例に変換することです。
- 社名・商品名 → A社 / X
- 担当者名 → Y氏
- テーブル名/内部API → 役割だけ説明（「注文テーブル」「認証API」など）
- 再現コード → ダミーデータで再現できる最小の例
「最小再現（MRE）」に落とすと、AIへの入力も短くなり、修正の当たりも良くなり、何より漏えいリスクが大幅に下がります。
ステップ4：AIの回答は「採用前の検証」を必須にする
副業で信用が落ちるのは「AIの提案をそのまま入れて壊す」パターンです。これをルール化してください。
- 変更は1点ずつ（同時に複数を触らない）
- 最低限のテスト（正常/空/異常）
- レビュー観点：入力検証、権限、ログ、例外処理
- 依存関係の固定（lockfile / バージョン指定）
ステップ5：証拠を残す（あなたを守るログ）
トラブルのときに効くのは「言った/言わない」ではなく記録です。
- クライアントのAI利用許可（チャット/メール/契約の該当箇所）
- AIに入れた情報の概要（匿名化したことが分かるメモ）
- 検証した証拠（テスト結果、レビュー記録、差分）
具体例：会社員副業で「うっかり漏えい」を防ぐ変換手順
状況：副業の受託案件で、エラーが出ていて納期が迫っている。つい、スタックトレースと該当ファイルを丸ごとChatGPTに貼りたくなる。
やりがち（NG）：
エラー全文＋実コード＋環境変数をそのまま貼る（内部URL、キー、顧客IDが混ざる）
安全な手順（OK寄り）：
- ①ログをマスク（キー、内部URL、パス、ID、社名を削除）
- ②実コードを貼らず、同じ構造の最小再現を作る（ダミー関数・ダミーデータ）
- ③「期待する挙動」「入力条件」「再現手順」を文章で渡す
- ④出力は採用前にテストし、差分と結果をログに残す
この変換ができるようになると、AIの便利さを残しつつ、事故確率を現実的に下げられます。
著作権の落とし穴：AI生成コードでも「コピペ事故」は起きる
「AIが書いたから著作権は関係ない」と思われがちですが、実務では逆です。
一番の事故は、既存コード（会社コード/OSS/他社コード）を混ぜた状態で納品し、権利関係が崩れることです。
事故パターン1：会社のコードを貼って作らせ、形を変えて副業に転用
これは著作権以前に、社内規程・契約違反の可能性が高いです。副業の収益よりも失うものが大きくなりがちなので、最初からルールで禁止しておくのが安全です。
事故パターン2：AI提案コードに、OSS由来の断片が混ざる
生成AIの出力が既存コードに似る可能性はゼロではありません。対策としては、次が現実的です。
- 重要部分は自分の言葉で書き直す（設計・命名・構造で独自性を作る）
- 依存ライブラリのライセンス確認（納品条件に合うか）
- コアロジックはレビュー＆テスト（品質と責任はあなた側）
よくある失敗3選と回避策
失敗1：エラーログを丸ごと貼ってしまい、トークンが混ざっていた
起きること：APIキーや内部URLが露出する。クライアント案件だと即アウトになり得る。
回避策：ログはマスクしてから。そもそも最小再現（MRE）で相談する。
失敗2：「学習オフ設定だからOK」と思い、NDA条項を読まずに入力した
起きること：ツール設定は関係なく、契約でアウトの可能性。
回避策：AI利用可否を事前に確認し、許可範囲を文章で残す。
失敗3：AIの提案をそのままマージして脆弱性を作った
起きること：入力検証不足、権限漏れ、ログ漏えいなど。副業で信用が落ちる。
回避策：採用前にテスト＋レビュー（セキュリティ観点）を必須化。変更は1点ずつ。
すぐできるチェックリスト：AI活用で事故らない最低ライン
- 社内規程・就業規則・クライアント契約でAI利用が禁止されていない
- NDAに「外部AI入力禁止」「第三者提供」「再委託」「国外移転」等の制限がないか確認した
- 会社でChatGPT Team/EnterpriseやAPIなどの業務用があるなら、そちらを優先する
- 入力禁止情報（非公開コード/鍵/個人情報/内部URL/未公開仕様）をリスト化した
- 相談は匿名化メモ＋最小再現（MRE）で行い、会社コードを貼らない
- AIの提案は必ずテスト・レビューしてから採用する
- 許可/やり取り/検証結果のログを残す
まとめ
会社や案件のコードをAIに貼るのは、情報漏えい・契約違反・著作権トラブルの入口になりやすい行動です。安全に使うには、ツールの設定だけでなく、社内ルールと契約を起点に運用を設計する必要があります。
今日からできる現実解は、入力禁止リストを作り、許可→匿名化→最小再現→検証→記録の型で回すこと。これだけで「便利さ」は残しつつ、事故確率を大きく下げられます。
次にやること（3ステップ）
- ステップ1：社内規程/NDA/契約書を開き、「AI入力禁止」「第三者提供」「再委託」「国外移転」などの条項を確認する
- ステップ2：入力禁止リストを作り、ログ・エラー相談は“匿名化メモ＋最小再現（MRE）”に切り替える
- ステップ3：クライアントにAI利用範囲を文章で確認し、検証（テスト）と記録（ログ保存）をルール化する
