クラウド環境で障害対応をしているエンジニアや、SRE（サイト信頼性エンジニアリング。システムの信頼性を工学的に保つ役割）としてポストモーテム（障害の振り返り文書）を書く立場の方に向けた内容です。障害の記録を「エンジニアの実績証明」として公開する動きが海外の開発コミュニティで広がっています。ただしこれをそのまま自社の運用にあてはめると、思わぬところでつまずくケースがあります。
海外の開発者コミュニティでは、本番環境で何が壊れ、なぜ壊れ、どう直したかを赤裸々に書く「Transparent Post-Mortem（透明性のある事後検証）」が、技術力を示す手段として推奨されています。ビジュアルな証拠、つまり実行時のターミナルログやシステム構成図、ベンチマーク結果のスクリーンショットを添えることで、記事の信頼性が上がるという考え方です。これは個人のブログや技術発信としては有効な手法です。ただし組織の運用チームがこの発想をそのまま持ち込むと、公開範囲の設計を誤るリスクがあります。
何が起きるか：ポストモーテムの「証拠」が漏洩経路になる
障害対応のドキュメントには、原因調査の過程で集めたログやスクリーンショットが大量に含まれます。
ターミナルの実行結果をそのまま貼り付けると、内部ホスト名やIPアドレス、環境変数の一部が写り込むことがあります。
システム構成図も同様です。VPC（仮想プライベートクラウド。クラウド上に構築する論理的に分離されたネットワーク領域）の構成や、サブネット設計、ロードバランサーの配置まで詳細に描くと、攻撃者にとっての「地図」を渡す結果になりかねません。
影響範囲は公開先によって変わります。社内のConfluenceやNotionで完結していれば問題は小さいですが、Qiitaやdev.to、GitHub Issuesのような外部公開の場に同じ資料を転用すると、機密情報の露出範囲が一気に広がります。
なぜ起きるか：段階的に原因を分解する
原因1：ドキュメントの「作成目的」が途中で変わる
最初は社内共有用に書いたポストモーテムを、後から技術ブログ用に転用するケースがあります。
作成時点では「社内向けだから多少生々しくてもいい」という前提で書いているため、機密情報のマスキング（伏字処理）をする習慣がありません。
原因2：スクリーンショットは目視チェックが漏れやすい
テキストログはgrepやスクリプトでキーワード検索して伏字にできますが、画像は人間の目視確認に頼るしかありません。
ターミナルの背景に別ウィンドウが写り込んでいたり、ブラウザのタブに社内システムのURLが見えていたりするミスは、実際の障害対応の現場でも起きやすいポイントです。
原因3：ベンチマークデータに顧客固有の情報が混ざる
「Before/Afterのレイテンシ比較」を示すために本番のモニタリングツール（Datadog、New Relic、CloudWatchなど）のダッシュボードをそのままキャプチャすると、顧客名やテナントIDがラベルに含まれていることがあります。
マルチテナント構成のSaaSでは特に起きやすい落とし穴です。
自分のプロジェクトが該当するか確認する方法
まず、社内のポストモーテムがどこに保存され、誰が公開判断をしているかを確認してください。
以下の観点でチェックすると、リスクの有無が見えてきます。
- ポストモーテムのテンプレートに「公開可否」の欄があるか（ない場合は全件非公開扱いになっているか確認）
- Slackやターミナルのスクリーンショットを貼る際に、社内のガイドラインでマスキングルールが定義されているか
- クラウドの監視ダッシュボード（CloudWatch、Grafanaなど）のスクリーンショットを外部共有した実績があるか、過去のブログ記事やスライドを棚卸しする
- IAM（Identity and Access Management。クラウド上のアクセス権限管理）のロール名やARN（Amazon Resource Name）がログに含まれていないか、直近3件のポストモーテムを見直す
実際に確認する際は、過去に公開したブログ記事やスライドの画像を一枚ずつ拡大して見返すことをおすすめします。
意外と、通知バーやブラウザの別タブに機密情報が写っていることがあります。
対策の手順
公開前レビューのプロセスを、以下の手順で組み込むと再現性が高くなります。
# ログファイルからよくある機密パターンを事前チェックする例
grep -E "(10\.[0-9]+\.[0-9]+\.[0-9]+|arn:aws:|@[a-zA-Z0-9.-]+\.internal)" postmortem_draft.mdこのようなgrepチェックをCI（継続的インテグレーション）のパイプラインに組み込み、社外公開用ドキュメントのマージ前に自動実行する運用も有効です。
手順としては次の流れになります。
- 社内向けドラフトと社外公開用ドラフトをファイルとして分離する（同一ファイルを直接編集しない）
- IPアドレス・ARN・内部ドメインなどをプレースホルダー（例:
10.x.x.x、arn:aws:xxxx）に置換する - スクリーンショットは加工前に必ず人間がフルスクリーンで再確認し、通知欄・別タブ・URLバーを個別にチェックする
- 監視ダッシュボードは本番のライブ画面ではなく、ダミーデータまたはステージング環境で再現したキャプチャを使う
- 公開前に、障害対応に関わっていないメンバーがレビュアーとして目視確認する（当事者だけのチェックは見落としが残りやすい）
コスト面でも触れておきたい点があります。
ステージング環境でダミーの障害シナリオを再現し、キャプチャを撮り直すには追加の作業時間がかかります。
ただし情報漏洩によるインシデント対応や信頼回復にかかるコストと比べれば、事前のスクリーンショット撮り直しにかかる工数は小さいコストです。
まとめ
障害対応の過程を公開すること自体は、技術力を示す手段として海外のコミュニティでも評価されています。
ただしクラウド環境の運用ドキュメントには、IPアドレスやARN、監視ダッシュボードの顧客情報など、公開に適さない要素が紛れ込みやすい構造があります。
まずは自社のポストモーテムのテンプレートに「公開可否」の欄があるかを確認し、なければ追加してみてください。
次に、直近で公開した技術記事やスライドの画像を一枚ずつ見直し、写り込みがないか棚卸しすることから始めるのが現実的な一歩です。