管理者が最も安心しやすいのは、スクリプトが正常に実行され、テストメールも問題なく送信された瞬間かもしれません。しかし、プログラムが実行できるという事実は、構文と接続がおおむね正常であることを示すにすぎません。管理者は、大量送信、データ変更、個人情報の処理が行われる前にエラーを検知できるか、そして実行を停止する権限を持つ担当者がいるかを確認する必要があります。
担当者が生成 AI に Python スクリプトを書かせることは可能ですが、プロンプトに要件が明確に記載されていなければ、出力が自社の情報セキュリティルールに適合するとは限りません。本番稼働前には、少なくとも標準化されたルール、検証可能なテスト記録、明確な承認担当者が必要です。このうち一つでも欠けていれば、担当者が要件を一文書き漏らしただけで、エラーがそのまま本番プロセスに入り込む可能性があります。
スクリプトが正常に実行されても、すぐに本番稼働できないのはなぜか？
美珍香が2026年4月25日にマーケティングメールを送信した際、自動マーケティングツールの設定ミスにより、同じ送信バッチの受信者同士に互いのメールアドレスが表示されました。iThomeの報道によると、従業員は生成 AI に SendGrid 用の Python スクリプトを作成させましたが、プロンプトにはブラインドカーボンコピー（blind carbon copy、BCC）を使用するよう明記されておらず、事前テストでもアクティビティログ（activity log）を確認していませんでした。このインシデントでは95,364人の会員が影響を受け、メールアドレスが漏えいしました。
報道では、直接的な原因はユーザーによるプロンプトの不備とテスト時の見落としだったとされています。しかし、企業が改善策を「次回からプロンプトを明確に書く」ことだけにとどめれば、プロセスの安全性は、担当者がその場ですべてのルールを思い出せるかどうかに左右され続けます。人員の入れ替わりやプロセスの変更があり、生成 AI の出力も毎回同じとは限りません。そのため企業は、必須の確認事項を標準プロセスに組み込み、実行のたびに個人の記憶へ依存しない仕組みを整える必要があります。
この原則は、メール以外の業務にも当てはまります。AI が生成したスクリプトで顧客データを一括更新したり、調達品目をインポートしたり、カスタマーサポートのリストを整理したり、品質管理記録を変更したりする場合、エラーの影響範囲は、スクリプトがアクセスできるデータ量と、一度に処理する件数によって決まります。まずチームは、「一括実行するもの」「個人情報にアクセスするもの」「データを変更するもの」に該当するスクリプトをすべて洗い出し、本番稼働前の必須審査対象に含める必要があります。
本番稼働を承認するには、事前にどのような証跡を確認すべきか？
審査担当者は、AI が生成したコードを読むだけでは不十分です。受信者が適切に分離されているか、テスト時のデータやバージョンが本番環境と一致しているかといった点は、設定や実行結果に隠れている可能性があるためです。承認チェックリストには、少なくとも以下の項目を含めることを推奨します。
- 宛先欄と分離方法：To、CC、BCC の用途を一つずつ確認し、各受信者に自分以外のメールアドレスが表示されないことを検証します。バッチ送信を行う場合は、各バッチのグループ分けと受信者の分離方法も確認します。
- 少量テストの結果：管理可能なテスト用メールアドレスを使って実際に送信し、送信者、受信者、件名、添付ファイル、バウンスメールの処理をそれぞれ確認します。API が成功を返したというだけで、メールの内容や各フィールドが正しいと判断してはいけません。
- アクティビティログ：サービスが実際に受け取ったパラメータ、各呼び出しで処理された受信者、異常メッセージが無視されていないかを確認します。審査担当者がログから実行状況を再現できない場合、そのログは承認の根拠として適切ではありません。
- スクリプトと設定のバージョン：テストに合格したコードと環境変数（environment variable）を照合し、本番で実行されるバージョンと一致していることを確認します。テストではバージョン A を使用したにもかかわらず、本番ではバージョン B が実行されるといった事態を防ぐためです。
- 停止方法と対応手順：誰が処理を中止できるのか、エラーを発見した際に誰へ連絡するのか、記録をどのように保存するのかを事前に定めます。美珍香は設定上の問題を確認した後、送信を中止し、スクリプトを修正して、影響を受けた人々へ通知しました。企業が対応手順を事前に策定する際には、こうした措置も参考になります。
チームは、検証可能な審査証跡を残す必要があり、コミュニケーションツール上で「確認済み」と返信するだけでは不十分です。チェックリストをタスクチケットや変更履歴に添付し、テスト日時、スクリプトのバージョン、ログの保存場所、承認者の氏名と併せて保存できます。情報が不足している場合、承認者は追加提出を求め、一括実行へ進ませないようにする必要があります。
どのようなスクリプトは、必ず停止して担当者の確認を待つべきか？
人による確認は、まだ完成していないすべてのコードを対象にする必要はありません。ただし、スクリプトが復旧困難な結果や外部から見える結果を生じさせようとしている場合は、処理を停止すべきです。まず、次の三つの条件を確認します。一度に大量のデータを処理し、一つのエラーによる影響が拡大する可能性があるか。個人情報や機密情報にアクセスするか。顧客へメールを送信する、または本番システムへ書き込むか。このいずれかに該当する場合は、指定された担当者による承認を推奨します。個人情報の処理と大量の外部送信を同時に伴う場合は、二者による確認を採用し、業務プロセス責任者と IT または情報セキュリティ担当者が、内容と技術設定をそれぞれ確認する方法もあります。
EgentWrX のワークフロー（workflow）では、「次の担当者へ引き継ぐ前に人による承認を必要とする」と設定できます。AI Agent がスクリプトや前工程の作業を完了すると、プロセスがいったん停止し、担当者の承認後に次のステップへ進みます。また企業は、BCC、受信者の分離、テスト送信、アクティビティログの確認、一括送信の直接実行禁止といった標準手順を、スキルやタスク指示としてまとめることもできます。従業員が独自に作成したスキルを全社展開するには、管理者が管理画面の審査キューを通じて事前に承認する必要があります。
ただし、承認担当者は単に「承認」ボタンを押すだけであってはなりません。誰がどのフィールドを確認するのか、どのような証跡を許容するのか、どのような場合に差し戻すのか、代理担当者がどう引き継ぐのかを、プロセスの中で明確に定める必要があります。美珍香がインシデント後に、送信前に少なくとも2人の従業員が確認する仕組みを追加したことからも、二者による確認が具体的な改善策になり得ると分かります。導入チームは、まず既存の一括メール送信プロセスを一つ選び、上記のチェックリストと承認担当者をワークフローに組み込んだうえで少量テストを実施し、その後に本番実行を許可するかどうかを判断できます。
よくある質問
AI が生成したスクリプトは、毎回2人で確認する必要がありますか？
毎回2人で確認する必要はありません。ただし、大量送信を行うもの、個人情報にアクセスするもの、本番データを変更するものについては、指定された担当者による承認を推奨します。個人情報の処理と大量の外部送信を同時に伴う場合は、プロセス責任者と IT または情報セキュリティ担当者がそれぞれ確認します。
スクリプトの承認担当者には、誰が適していますか？
承認担当者には、業務内容と技術設定を判断できる能力が必要です。業務プロセス責任者は、送信対象、内容、実行タイミングを確認し、IT または情報セキュリティ担当者は、フィールド、バージョン、権限、アクティビティログを照合します。また、代理担当者も事前に指定しておく必要があります。
テストメールの送信に成功すれば、本番送信してもよいですか？
それだけでは不十分です。テスト担当者は、実際の宛先欄、ほかの受信者が表示されないこと、アクティビティログ、スクリプトのバージョンも確認し、テスト環境と本番環境の設定が一致していることを確かめる必要があります。API が成功を返したことだけを見て承認してはいけません。
プロンプトを明確に書けば、標準チェックリストの代わりになりますか？
いいえ。担当者はプロンプトで AI にルールの順守を求めることができますが、要件を書き漏らす可能性は残り、AI の出力にも検証が必要です。企業は、BCC、受信者の分離、少量テスト、アクティビティログの確認を共通スキルやタスク指示に組み込み、承認担当者が証跡を確認する仕組みを整えるべきです。
参考資料
- 管理者のAIプロンプト設定ミスにより、美珍香で約10万人の会員情報が漏えい — iThomeが2026年10月5日に、インシデントの経緯、影響範囲、その後の改善策を報じています。