障害対応でAIにログを貼る前に。急いでいても守りたい3つの境界

日曜の22時41分。予約システムで、決済後の受付メールが一部の利用者へ届いていないと連絡が入った。

担当者から届いたメッセージは短い。

明朝の受付開始までに、原因だけでも分かりますか？

本番ログを開くと、同じエラーが何十行も続いていた。原因は見えない。そこでAIの入力欄を開き、「次のログから原因を考えて」と書く。80行ほど選択し、貼り付ける直前まで進んだ。

画面には、エラー名だけでなく、利用者のメールアドレス、予約番号、社内用URLが並んでいる。途中には外部サービスへ送った認証用の文字列まで見えた。

早く戻さなければならない。ここで手を止めたら調査が遅れ、自分が障害対応に慣れていないと思われそうだ。担当者を起こして利用可否を聞くのも気まずい。「原因調査だけだから」と、そのまま送る理由を作りたくなる。

一方で、送信ボタンを押したあとに取り消せるのかは分からない。AIから答えが返っても、顧客の情報をどこへ渡したか説明できない。その想像で、指が止まった😨

障害対応では、速さが必要だ。ただし、急いでいる時ほど、ログを丸ごと渡すのではなく、質問、入力データ、送信先の3つを分けて確認する。 この3つが決まれば、AIを使わずに止まるのではなく、情報を守りながら調査へ戻れる。

ログを丸ごと貼りたくなるのは、怠けたいからではない

ログには、発生時刻、処理の順番、エラー、利用者の状態がまとまっている。AIへ渡せば、自分では見落とした共通点を短時間で見つけられそうに見える。

焦りは「多く渡すほど早い」に変わりやすい

障害が起きると、頭の中に二つの時計が動き始める。利用者が困っている時間と、相手から返事を待たれている時間だ。

原因がまだ分からない時ほど、状況を短く説明するのが難しい。それなら、ログを全部渡してAIに整理してもらう方が早い。自分で必要な行を選ぶと、重要なものを落とす気もする。

さらに、外部のフリーランスとして入っていると、「まず確認させてください」と言うことに弱さを感じることがある。一人で原因まで出せば頼られる。質問すれば作業を止める人に見える。そんな気持ちが、相談せずに送る行動へつながる。

でも、ログはエラーだけの記録ではない。メールアドレス、氏名、会員番号、IPアドレス、社内のホスト名、URLの引数、認証情報などが混ざることがある。個別には意味が薄く見えても、組み合わせると利用者や顧客環境をたどれる場合もある。

個人情報保護委員会は、事業者が個人情報を含む内容を生成AIへ入力する時、決めた利用目的に必要な範囲かを確認するよう注意を促している。本人の同意なく個人データを入力する場合には、サービス提供者が応答以外の目的で扱わないか、機械学習へ利用しないかなども確認する必要があるとしている。

ここで大事なのは、「個人情報だけ消せば何でも送ってよい」という意味ではないことだ。顧客との契約で外部サービスへの入力が禁じられている情報、未公開のコード、認証情報、障害の事実そのものが秘密情報に当たることもある。

法律上の確認、契約上の約束、サービスの設定は別々に見る。どれか一つを満たしただけで、送信可とは決まらない。

送信前に、3つの境界を順番に見る

80行のログを前にして「安全か」を一度に判断するのは重い。そこで、質問、入力データ、送信先の順に分ける🔍

1. 質問の境界: AIに何を判断してほしいのか、一文にする

最初に決めるのは、AIへ渡す情報ではなく、聞きたいことだ。

今回の目的は「この障害を直して」では広すぎる。ログ全体、コード、設定、顧客情報まで必要に見えてしまう。実際に知りたいことを一文へ縮める。

メール送信処理が再試行された時だけ、受付済みの予約が未送信扱いへ戻る原因候補を知りたい。

ここまで言えれば、必要なのは再試行の前後、状態変更、エラー種別だと分かる。メールアドレスや実際の予約番号は、原因候補を考えるために要らない。

まだ質問を絞れないなら、実データを渡す前に、公開情報だけで「この種類の障害を切り分ける観点を出して」と尋ねる方法もある。観点が出たら、元のログは手元の許可された場所で照合する。

質問を先に狭めると、渡すデータも狭くなる。 これは確認を増やす手間ではなく、調査の入口を作る作業だ。

2. 入力データの境界: 原本ではなく、調査用のコピーを作る

次に、本番ログをそのまま編集せず、調査用のコピーを作る。原本は権限のある保管場所に残し、コピーから不要な情報を削る。

• 氏名、メールアドレス、住所、電話番号は削除する
• 会員IDや予約番号は、関係を追う必要があれば[USER_A]や[RESERVATION_1]へ置き換える
• 社内URL、ホスト名、顧客名、案件名は一般名へ置き換える
• Cookie、セッショントークン、APIキー、署名、認証ヘッダーは行ごと外す
• 正確な時刻が不要なら、処理開始から0秒、30秒後のように相対時間へ変える
• 同じエラーの繰り返しは、件数だけ残して代表行へ減らす

一部を伏せても、前後の情報から誰か分かるなら十分ではない。ここでの置き換えを、法的な意味での「匿名加工が済んだ」と安易に呼ばない方がよい。あくまで、質問に不要な情報を減らした調査用コピーだ。

認証情報が本番ログへ出ていた場合は、AIへ送らなければ終わりでもない。元のログを見られる人や保存期間を確認し、決められた手順で失効や再発行を判断する。見つけた秘密を伏せ字にして調査を続ける前に、秘密が記録された事実を扱う必要がある。

NSA、CISAなどが2025年に共同公開したAIデータセキュリティの手引きも、AIで使うデータを開発から運用まで守り、出所を追える状態にし、信頼できる基盤を使うことを勧めている。対象は組織的なAIシステムだが、日々のAI利用でも「どこから取ったデータを、どこへ渡したか」を残す考え方は使える。

元ログは証拠として守り、AIへ渡すのは質問に必要な最小限のコピーにする。

3. 送信先の境界: サービス名ではなく、今使う契約と設定を見る

最後に、送信先を確認する。同じ名前のAIサービスでも、個人向け画面、法人向け契約、API、接続した外部ツールでは、データの扱いが違う場合がある。

最低限、次を確認する。

• 顧客や所属先が利用を認めたサービスとアカウントか
• 入力内容が学習へ使われるか、選択できるか
• 入力と出力が何日保存され、誰が見られるか
• ファイル添付、会話履歴、外部連携に別の保存条件がないか
• 削除方法と、問題が起きた時の連絡先が分かるか

たとえばOpenAIのAPI向けデータ管理文書では、APIへ送ったデータは明示的に共有へ同意しない限りモデル改善に使わない一方、標準の不正利用監視ログには入力や出力が含まれる場合があり、原則として最長30日保存される。法令上必要な場合などは、より長く保存されることもある。機能ごとの保存状態や、外部サービスへ送ったデータの扱いも同じではない。

これは特定サービスが危険だという話ではない。「学習に使われない」と「保存されない」は同じではなく、サービス名だけで判断できないという例だ。利用規約や設定は変わるため、以前読んだ説明ではなく、実際に使う契約と機能を確認する。

総務省・経済産業省の「AI事業者ガイドライン第1.2版」も、AIの利用者を含む関係者へ、プライバシー保護、セキュリティ確保、透明性、説明できる状態を共通の指針として示している。難しい管理表を最初から作らなくても、送信前に「誰の許可で、何を、どの条件の場所へ渡すか」を言える状態にはしておきたい。

情報を減らしても、原因調査は進められる

日曜の障害では、AIへ渡す内容を12行まで減らした。実際のメールアドレスと予約番号は置き換え、認証情報と社内URLは削除した。残したのは、状態が変わった順番、再試行回数、エラーコード、処理間隔だけだった。

AIからは、メール送信の失敗後に予約状態まで巻き戻している可能性と、再試行処理が同じ受付を二重に更新している可能性が返ってきた。

AIの答えは、原本へ戻るための仮説にする

ここで答えをそのまま担当者へ送らない。元のログを許可された環境で確認すると、再試行のたびに「未送信」へ戻す処理が動いていた。コードを見ると、送信失敗時の更新範囲が広く、受付状態まで戻していた。

修正後は、同じ予約に対して送信を再試行するテストを追加し、元の障害条件を再現した。受付状態を保ったままメールだけ再送されることを確認した。AIが原因を確定したのではない。必要な情報だけで候補を出し、原本、コード、テストで確かめた。

担当者には、次のように報告した。

再送失敗時に、メールの状態だけでなく受付状態まで戻していたことが原因でした。修正と再現テストは完了しています。調査では顧客情報を外部へ入力せず、置き換えた処理順だけを承認済みのAI環境で確認しました。ログに認証用の文字列が記録されていたため、そちらは別途失効と再発行を進めます。

認証情報の件まで伝えるのは怖かった。自分の調査で見つけた以上、黙って修正だけ終えたくもなる。余計な心配を増やし、任せにくい人と思われそうだからだ。

それでも、障害時の初報で事実と推測を分ける方法に沿って、起きた事実、対応済み、未完了を分けると報告しやすくなった。問題を一人で抱え込まず、相手が次の判断を選べる形へ戻せた🙂

AIへ渡さない判断と、問題を関係者へ伝える判断は両立する。 秘密情報を守るために黙るのではなく、許可された経路で必要な人へ早く共有する。

次の障害に備えて、平時に5行だけ決める

障害の最中に、サービスの規約、顧客との契約、ログの項目を一から調べるのは難しい。平時に、案件ごとに次の5行を残しておく。

• 利用可: AIを使ってよい作業と、承認済みのサービス・アカウント
• 入力不可: 個人情報、顧客固有情報、認証情報、本番データなどの具体例
• 置き換え: 調査用コピーを誰が、どこで作るか
• 確認: AIの仮説を原本、コード、テストのどれで確かめるか
• 連絡: 判断に迷った時と、秘密情報を見つけた時の連絡先

AIを使う案件で先に決めたい3つの確認を契約前に置き、この5行を実際の障害対応へ落とすとつながりやすい。AIの完了報告を3つの証拠で確認する方法も、修正後の報告に使える。

日曜の夜、最初に欲しかったのは、すぐ返せる正解だった。実際に助けになったのは、送信前に一度止まり、質問を一文へ絞ったことだった。そこから不要な情報を外し、送信先を確認し、AIの答えを仮説として原本へ戻れた。

次に本番ログをAIへ貼りたくなったら、利用を全部諦めなくていい。送信前に、質問、入力データ、送信先の3つを声に出して確認する。答えられない境界があれば、実データは送らず、公開情報や作り物の例で観点だけを聞く。

速い障害対応とは、すべてを急いで外へ出すことではない。守る情報を決めたうえで、原因へ近づくことだ。

参考にした情報

• 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等について」（2023年6月2日公開、2026年8月9日確認）
• 総務省・経済産業省「AI事業者ガイドライン（第1.2版）」（2026年3月31日公開、2026年4月1日最終更新、2026年8月9日確認）
• NSAほか「AI Data Security: Best Practices for Securing Data Used to Train & Operate AI Systems」（2025年5月22日公開、2026年8月9日確認）
• OpenAI「Data controls in the OpenAI platform」（2026年8月9日確認）