45日制限：Discordの監査ログをエクスポートしてサーバーを守る方法

Q: Discordの監査ログはどこで確認できますか

ロールにVIEW_AUDIT_LOG権限があれば、Discordクライアントのサーバー設定 → 監査ログです。開発者は GET /guilds/{guild.id}/audit-logs エンドポイントからプログラムでも取れます。

Discordの監査ログがタイマー付きでロックされたアーカイブに書き出されるアイソメ図

Discordの監査ログは、BANから権限変更まで、サーバー上の管理・モデレーション操作をすべて残す記録で、自動的に45日間保持されます。閲覧にはVIEW_AUDIT_LOG権限が必要で、メッセージ本文やチャット履歴は一切残らず、行われた操作とその実行者だけが記録されます。期限が切れたエントリは消えます。Discordの画面から手動で消去することも、保持期間を延ばすこともできません。

TL;DR: - 監査ログの保持は45日だけなので、それより長い記録が必要ならサーバーオーナーは定期的にデータをエクスポートする必要がある。 - 閲覧にはVIEW_AUDIT_LOG権限が要り、管理者権限を渡さなくても信頼できるロールに割り当てられる。 - 操作の種類、モデレーター、時刻で絞り込むと、調査中に関係する出来事へすぐたどり着ける。 - ログが残すのは誰が何を変え、どんな理由を付けたかであり、メッセージ本文やチャット履歴は決して残らない。 - 自動ツールと適切なアクセス制御を組み合わせると、インシデント後に監査ログを見返すだけではない、先回りの防御層になる。

Discordの監査ログに記録される内容
監査ログの確認方法と閲覧権限の締め方
監査ログのフィルターと検索
Discord APIで監査ログを取得する
保持期間とエクスポートと取り消せないこと
サーバーセキュリティのための監査ログ運用
ログだけでは足りない理由
監査ログが事後にしか残せないことへの予防層
出典
よくある質問

Discordの監査ログに記録される内容

Discordの監査ログのエントリはどれも同じ構造です。インシデントのあとに何が起きたかを組み立て直すとき、各フィールドを知っていると時間が節約できます。

user_id: 操作を実行した人
action_type: 操作の種類（BAN、キック、ロール更新など）
target_id: 影響を受けた相手または対象
changes: 変わった具体的な変更前/変更後の値
reason: 任意のテキスト説明。モデレーターが入力するか、Botが X-Audit-Log-Reason ヘッダーで渡す
timestamp: エントリのスノーフレークIDに埋め込まれており、正確な順序が分かる

よく見る操作の種類には、メンバーのキックとBAN、ロールの作成や編集、チャンネルの作成・更新・削除、チャンネルの権限上書きの変更、ウェブフックの変更があります。reason フィールドは、人が思っている以上に重要です。BANやキックを実行するBotはここを自動で埋められるので、人間のモデレーターが理由を書き忘れても、きちんと設定されたモデレーションBotなら痕跡が残ります。

監査ログのドキュメントがはっきり書いていることが1つあります。メッセージ本文は決して記録されません。誰かがメッセージを削除した場合、ログに残るのは削除が起きたことと、誰が実行したかだけであり、本文は残りません。

監査ログの確認方法と閲覧権限の締め方

クライアントで監査ログを見る手順は、場所を知っていれば3クリックです。

サーバー設定を開く。
左サイドバーの監査ログをクリックする。
スクロールするか、操作の種類とメンバーで絞り込んで結果を狭める。

権限の関門はVIEW_AUDIT_LOGで、他のDiscord権限と同じ場所で管理します。サーバー設定 → ロール → ロールを選択 → 権限です。既定ではAdministratorを持っていると自動で付与されますが、単独の権限として下位のロールに割り当てることもできます。モデレーターに監査ログは見せたいが、管理者権限までは渡したくない場合に使います。

この分離は、多くのサーバーオーナーが思っている以上に重要です。監査ログは見られるが、チャンネル構成やサーバー設定には触れられないモデレーターなら、何が起きたかの全体像は得られて、そのアカウントが乗っ取られても被害を出す余地は小さくなります。

ヒント: VIEW_AUDIT_LOGだけを有効にした専用の「ログ確認係」ロールを作ってください。通報対応はするが広い管理者権限は要らない信頼できるスタッフに割り当てます。誰の手も止めずに、攻撃面だけを小さくできます。

誰かにこの権限を渡す前に、短いチェックリストを回してください。そのロールに不要な上位権限が付いていないか確認する、Administratorの上に誤って積み重ねていないか確かめる、誰が持っているかを文書化して四半期ごとに見直せるようにする。

監査ログのフィルターと検索

監査ログの画面では、操作の種類とモデレーターで絞り込めます。両方を組み合わせると、特定のインシデントを追っているときに結果がすぐ狭まります。

何が起きたかは分かるが誰がやったか分からないときは、操作の種類で絞る（すべてのBAN、すべてのチャンネル削除、すべてのロール編集）。
特定のアカウントを疑ってその活動履歴全体が欲しいときは、モデレーター（user_id）で絞る。
複数の操作が短い間隔で起きたときは、各エントリに埋め込まれた時刻で順序を組み立て直す。

典型的な流れです。チャンネルが消えて、誰も責任を認めない。ログを「チャンネルの削除」で絞り、その時刻を当時のDiscordのアクティビティ履歴と照合し、user_id をスタッフ名簿と突き合わせる。削除の直前に権限が変わっていれば、それも残っています。権限上書きのエントリにある changes 配列は、どの権限が false から true にひっくり返ったかを正確に列挙するので、権限昇格の案件ではたいていこれが決定的な証拠になります。クライアントでは既定で新しい順なので、直近のインシデントはスクロールせずにすぐ上に出ます。

Discord APIで監査ログを取得する

独自のダッシュボードやエクスポート用スクリプトを作る人向けのエンドポイントは GET /guilds/{guild.id}/audit-logs で、クライアント表示と同じVIEW_AUDIT_LOG権限が必要です。

user_id: 特定のモデレーターまたはBotに結果を限定する
action_type: 単一の操作の種類で絞る（Discordのドキュメントで定義された数値enum）
before / after: エントリIDでページ送りする。before は新しい順、after は古い順
limit: 1リクエストあたりの取得件数。1から100の範囲

discordkitのAPIリファレンスはこれらのパラメータを直接書いており、定期取得をスクリプト化するならブックマークしておく価値があります。JavaScriptで書くなら、discord.jsのガイドが fetchAuditLogs のようなライブラリメソッドを扱っています。このエンドポイントを包んでページ送りまでやってくれます。reason フィールドを埋めるBotは、ボディのパラメータではなく X-Audit-Log-Reason リクエストヘッダーで渡します。初めて組み込む人がよくつまずく点です。

保持期間とエクスポートと取り消せないこと

Discordは監査エントリを45日間保持し、この期間を延ばしたり、ログを手動で消去したりできる設定、コマンド、有料プランはありません。古くなったエントリは完全に削除されます。

エントリは45日後に自動で期限切れになり、管理者が介入する余地はない。
Discordから取り寄せるユーザーのデータのパッケージには、そのユーザーに紐づく監査操作がおおよそ90日分含まれることがある。サーバー側の窓より長いが、その1アカウントが関与した操作だけが対象になる。
コミュニティとしてより長い組織的な記録が必要なら、APIエクスポートを定期実行し、改ざんが分かる場所に保管する。誰でも編集できるテキストチャンネルや共有スプレッドシートだけに置かない。

45日の窓は動かない期限だと考えてください。大規模なコミュニティを運営している、あるいはコンプライアンス上の意味がある案件を扱っているなら、必要になってからではなく、必要になる前にエクスポートの習慣を作ってください。紛争が起きてから、6週間ではなく6か月分の履歴が欲しくなるのを待ってはいけません。

サーバーセキュリティのための監査ログ運用

監査ログの良い運用は5つの習慣に収まります。たいていのサーバーは、そのうち1つか2つしかやっていません。

VIEW_AUDIT_LOGをロールベースのアクセス制御で絞り、スタッフの入れ替わりのたびにそのアクセスを入れ替える。権限を持ったまま辞めたモデレーターは、静かなリスクです。
45日を超える記録が必要なら、ログを定期的にエクスポートする。 APIで週次または月次に取得し、安全なアーカイブ保管に置けば、コンプライアンスと紛争解決の大半は足ります。
BANや権限変更が短い窓で急に続いたときなど、異常な急増のアラートしきい値を設ける。 監査ログ監視に関するCISAのガイダンスが、まさにこの理由で文書化された監視プロセスを勧めています。
ログを先回りのモデレーションツールと組み合わせる。 Better AntispamのようなBotはレイドやスパムの波をリアルタイムで止められるので、そもそも調査が必要になるエントリが減ります。
監査ログの所見を対処手順につなぐ短いインシデント手順書を書く。 進行中のレイドで、その場の即興に頼らないようにします。

ヒント: ログ運用のベストプラクティスでは一般に、壊れてから誰も見ていなかった受動的な記録として扱うのではなく、RBACと自動アラートでログを集約して守ることを求めます。

ログだけでは足りない理由

監査ログが答えるのは「何が起きたか」ですが、答えるのは事後です。本当の限界はそこにあります。鑑識の道具であって予防の道具ではなく、どれだけ丁寧にログを見直しても、進行中のレイドは止まりません。監査ログをセキュリティ戦略の全部だと考え、何かが壊れてからだけ確認しているサーバーを私は見てきました。空き巣のあとに防犯カメラを見返して、それを防犯システムと呼ぶようなものです。

より良い構えは3つを重ねます。機密性の高いログを見られる人をRBACで絞ること、価値ある記録が45日で消えないよう定期エクスポートすること、そしてログエントリが生まれる前に動く先回りのツールです。見ておく価値のあるパターンが1つあります。普段の時間帯以外に、1人のモデレーターアカウントからロール変更やBANが急に固まる場合、乗っ取られたログインを示していることが多く、資格情報のリセットを走らせるきっかけになるのは運ではなく、ログでそのパターンを捉えることです。

— Adam

監査ログが事後にしか残せないことへの予防層

監査ログを読むと、すでに起きたことが分かります。悪い理由でログを読む回数を減らすために作られているBotもあります。スパムの波、レイド、不審な権限操作を、被害のあとではなくリアルタイムで捉えます。

始まったスパムや詐欺の波を自動で止め、レイドの試みのあいだチャンネルをロックしたりアカウントを黙らせたりし、異常な権限変更に印を付けて、乗っ取られたモデレーターアカウントが誰もログを見る前に静かに被害を出すのを防ぎます。何かがすり抜けても、自動のチャンネル掃除が事後処理をするので、何百件ものメッセージを手で消す必要はありません。どれも監査ログの代わりではなく、並んで動くものです。そもそも調査が必要なインシデントが減ります。ログだけがサーバーと混乱のあいだに立っている状態に疲れたなら、Better Antispamを見て、コミュニティ向けの先回りの守りがどんな形になるか確認してください。