公開後：ログ・監視・事故対応

公開前チェックリストに全部印が付いても、それで終わりではありません。穴は後から見つかり、部品は後から汚染され、鍵は後から漏れます。公開後に必要なのは、「何かが起きたと気づける記録」と「気づいたときに迷わない手順」の2つです。この章では、OWASP A09とNISTの事故対応の枠組みを、個人開発の規模に合わせて噛み砕き、最後に「事故対応の1枚」を作ります。経理の事故報告書と、ほとんど同じ構造です。

公開して終わりではない：A09 セキュリティログとアラートの不備

OWASP Top 10:2025のA09は、2021年版の「セキュリティログと監視の不備」から名前を変え、「アラート」を強調しました。記録するだけでなく、記録が行動を促さなければ意味がない、という趣旨です。原典が挙げる不備の例は、「ログイン成功のみを記録し、失敗を記録していない」、警告やエラーのログが「生成されない、あるいは不適切で不明確である」、そして「個人識別情報（PII）や健康情報（PHI）などの記録すべきでない機密情報がログに含まれている」です。

論文では64件（5.40%）、28.50%のアプリに1件以上ありました。AIは「動く機能」に集中し、「あとで何が起きたか分かるようにする」ことを言われなければやりません。第4章の「暗黙のセキュリティ規則の欠落」の典型です。さらにVeracodeの2025年の報告では、AIが書いたコードはログインジェクション（CWE-117。ログに偽の行を混ぜ込まれる不備）を88%のケースで防げていませんでした。ログは「作らせる」だけでなく「正しく作らせる」必要があります。

経理に置き換えれば、ログは仕訳帳と承認履歴です。誰が、いつ、どの伝票を起票し、誰が承認したか。それが残っていなければ、不正があっても照合で見つけられず、見つけても原因を追えません。

最低限のログ：誰が、いつ、何をしたか

完璧な監視は要りません。しかし、次の3つが残っていないと、事故が起きたときに「影響範囲」が永遠に分かりません。

• 認証の出来事。ログインの成功と失敗（誰が、いつ、どこから）、ログアウト、パスワード変更。失敗を残すのは、総当たりの兆候を見るためです。
• 権限の拒否。「他人のデータへのアクセスを拒否した」記録。第10章で作った守りが働いた痕跡であり、誰かが試している兆候でもあります。
• データの変更。作成、更新、削除。ミニ銀行なら、振込と残高の変更はすべて。「誰が、いつ、どのIDを、何から何へ」。管理者の操作と設定の変更も含めます。

そして、残してはいけないものがあります。パスワード、APIキー、セッションの識別子、クレジットカード番号、そして必要以上の個人情報です。OWASPの原典が機密情報の混入を不備として挙げているとおり、ログは「漏れたときに第二の事故になる」場所です。メールアドレスを残すなら一部を伏せる、本文ではなく「変更があった」事実だけを残す、という設計にします。

異常の兆候：何を見ればよいか

毎日ログを読む必要はありません。月次で残高を照合するように、週に一度、次の4つを見ます。

• ログイン失敗の急増。同じアカウント、または多数のアカウントへの連続した失敗は、パスワードの総当たりか、漏れたパスワードの一覧を使った試行の兆候です。
• 見覚えのないデータの変更。自分が触っていない時間帯の変更、テスト用アカウント以外からの管理者操作。経理の「起票者も承認者も身に覚えのない伝票」です。
• 急なアクセス増。公開直後でもないのに要求数が跳ね上がったら、自動化された探索か、第16章の部品経由の何かです。
• 費用の急増。ホスティングやデータベース、AIのAPIの利用額が急に増えたら、鍵が漏れて他人に使われているか、LLM10 Unbounded Consumption（無制限な利用）の状態です。各サービスの利用額の通知（アラート）を、必ず設定しておきます。VercelのSpend Managementのように、設定額に達したら通知し、公開を自動で止めるところまでできる仕組みもあります。

事故対応の基本手順：NIST SP 800-61 Rev.3

事故対応の標準的な枠組みは、米国NISTの SP 800-61「Incident Response Recommendations and Considerations for Cybersecurity Risk Management」です。長く使われた Rev.2（2012年）は、準備、検知と分析、封じ込め・根絶・復旧、事後活動という4段階の円環でした。2025年4月の Rev.3 は構成を変え、NISTサイバーセキュリティフレームワーク（CSF 2.0）の6つの機能に沿って整理しています。

Rev.3 が構成を変えた理由は、「事故は稀で、数日で終わる」という前提が崩れたからです。NISTは、事故は頻繁に起き、復旧に数週間から数か月かかることがあり、教訓は復旧を待たずに共有すべきだとしています。個人開発でも、対応しながら記録を残します。

個人開発の規模での手順

1. 気づいたら、まず時刻を書く。何を、どこで、どう気づいたか。ここから記録を始めます。
2. 止血する。漏れた可能性のある鍵をすべて再発行し、古い鍵を無効化します（第9章）。自分のアカウントのパスワードを変え、二要素認証を確かめます。被害が広がりそうなら、公開を一時停止します（Vercelならプロジェクトの一時停止（Pause）か、「メンテナンス中」の表示だけの版への差し替え）。止めることで失うものより、動かし続けて失うもののほうが大きいのが普通です。
3. 影響範囲を特定する。ログから、いつからいつまで、誰のデータが、どう触られたかを割り出します。「分からない」なら「分からない」と記録します。ここで監査用のテーブルが効きます。
4. 報告する。次の節の法令と、社内のルールに従います。
5. 復旧する。原因を塞ぎ、第10章と第11章の確認を再実行してから再開します。バックアップから戻す場合は、戻した時点のデータが汚染されていないかを見ます。
6. 振り返る。何が起き、なぜ気づけたか（気づけなかったか）、何を変えるか。公開前チェックリストに項目を足します。

日本の法令：個人情報の漏えい報告

他人の個人情報を扱うアプリで漏えいが起きた場合、個人情報保護法は、個人情報保護委員会への報告と本人への通知を義務づけています（2022年4月施行の改正）。委員会のページによれば、報告が義務となるのは次のいずれかです。

• 要配慮個人情報（病歴、健康診断の結果など）を含む漏えい、またはそのおそれ
• 不正に利用されると財産的な被害が生じうるもの（クレジットカード番号、送金や決済ができるサービスのログイン情報など）の漏えい、またはそのおそれ
• 不正の目的をもって行われた行為による漏えい、またはそのおそれ（外部からの攻撃も、内部の持ち出しも含む）
• 1,000人を超える個人データの漏えい、またはそのおそれ

期限は、速報が発覚からおおむね3〜5日以内、確報が30日以内（不正の目的によるおそれがある場合は60日以内）です。報告は委員会の「漏えい等報告フォーム」から行います。期限が短いので、起きてから調べ始めると間に合いません。ミニ銀行のような「ログイン情報と残高を扱うアプリ」は、2つ目の条件に該当しうることを覚えておいてください。

個人の開発者であっても、事業として個人情報のデータベースを扱っていれば「個人情報取扱事業者」に当たります。学習用のアプリが該当するかは場合によりますが、該当しない場合でも同じ手順で動くのが安全です。そして、会社の情報を少しでも扱っているなら、社内の情報セキュリティ担当へ即座に報告します。自分で判断して抱え込まないこと。法令の前に、情報セキュリティ規程の問題です。