監査ログの利用

組織内のすべてのAPIリクエストは365日間記録されます。誰が、何を、いつ、どこから、どのアプリケーションで行ったかがわかります。何が起きたかを知りたいときに最初に見るべき場所です。

執筆: Didit サポート · 更新日: 2026年8月19日

#記録される内容

1234

1. メンバー、パス、メソッド、日付でフィルターし、「誰がこれを変更したか」に答えます。
2. MethodとStatusを見れば、読み取りと実際に反映された変更を区別できます。
3. その呼び出しを行ったメンバーです。
4. 発信元です。ログを証拠に変える情報です。

組織内でDiditプラットフォームに対して行われたすべてのリクエストが、何によって行われたかを問わず記録されます。各エントリには次の情報が含まれます。

ログは365日間保持された後、自動的に削除されます。

#実際にどう使うか

これが適切なツールとなる4つの状況です。

• 「このワークフローを誰が変更したか」 昨日と挙動が違うフローは、通常その裏に編集があり、ログが実行者を教えてくれます。
• インシデントの調査。 何が、誰によって、どのアドレスから、どの順序でアクセスされたかを正確に追跡します。
• 連携のデバッグ。 自社のコードが実際に行ったリクエストを確認できます。想定しているものではなく、実際に行われたもの（4xxになったものも含めて）です。
• アクセス制御の証跡。 検証データへのアクセスが記録・確認可能であることを監査担当者に示せます。

#フィルタリング

ユーザー、エンドポイント、期間でフィルターし、長い一覧を絞り込めます。何か特定の事象を調査する場合は、タイムスタンプを起点に周辺を確認していってください。1件のリクエストが単独で起きることは稀で、その直前直後の呼び出しが状況を物語ることがほとんどです。

#APIキーによるリクエストは人物ではなくアプリケーションに紐づけられる

APIキーによるリクエストには紐づけるべき人物がいないため、アプリケーションに対して表示されます。これは誠実な表現です。プラットフォームは、どのサービスやエンジニアがその呼び出しを行ったのかを実際には把握していません。

実務上の帰結として、複数のサービスで1つのキーを共有していると、インシデントの調査が大幅に難しくなります。帰属先を明確にしたい場合は、利用者ごとに独自のアプリケーションとキーを用意してください。

#ログに含まれるものと含まれないもの

ログは活動を記録します。誰が何を、いつ、どこから呼び出し、どのステータスが返ってきたかです。これはメタデータの証跡であり、検証データのコピーではありません。

これらのエントリに顧客の個人データが含まれるかどうか（データ保護のレビューでよく出てくる質問です）を知る必要がある場合は、ヘルプページから推測するのではなく、Diditの担当窓口から回答を得て記録してください。まさに、自社のDPIAで証跡として求められる類いの記述です。

#誰が見られるか

監査ログへのアクセスはロールに従います。Compliance Officerには含まれますが、Readerには広範なアクセス権はありません。オーナーはカスタムロールに付与できます。チームメンバーの招待とロールの設定をご覧ください。

チームメンバーを削除しても、ログ上の履歴は削除されません。それがこの仕組みの意義です。編集できる証跡は証跡とは言えません。

#エクスポートやレポートも記録される

セッションのPDFやCSVエクスポートの生成もAPI呼び出しであるため、誰が行ったかとともにここに記録されます。検証エビデンスへのアクセスが管理されており、誰でも見られるわけではないことを示す必要がある場合に有用です。検証レポートのダウンロードをご覧ください。

#365日を超える保持が必要な場合

保持期間は365日で固定されています。自社の義務がそれより長い場合は、必要な分を定期的にエクスポートして自社のシステムに保管してください。セッションのエビデンスを自社で保持する場合と同じ考え方です。必要な期間を決めるのは自社のコンプライアンス上の判断であり、思い込みで設計しないでください。