記録の基盤/ The Log

現在 163 種類です。一覧は共有の定数ファイル 1 本が唯一の置き場で、日本語の表示名も同じファイルに同数そろえてあります。片方だけ増えると自動テストが落ちるので、名前だけ増えて表示名が無い、という状態になりません。

名前は {対象}.{動作} の形で付けています（file.upload_initiated、member.role_change、share_link.revoke など）。新しい操作を実装するときは、先に定数へ追記してから実装する順序を規律にしています。逆順にすると、名前の綴りがコードのあちこちに散った状態で固まってしまうためです。

列は 13 です。「いつ・誰が・何を・何に対して」を固定の列で持ち、操作ごとに違う中身だけを 1 つの自由項目にまとめています。

接続元の IP と端末情報の置き場

IP アドレスと端末の情報（ブラウザの種類など）は専用の列を持っていません。自由項目のなかに入っています。操作の 163 種すべてに付くものではなく、付ける意味があるのは一部（アップロードやサインインなど）だからです。

絞り込みを速くするための索引

索引は月ごとの子テーブルに 5 本ずつ張っています。うち 3 本は「値が入っている行だけ」を対象にした部分的な索引で、空の行がほとんどを占める列（Box や対象の種類）でも索引が小さく保たれます。

• Box と時刻 — Box のアクティビティの主経路
• 操作者と時刻 — 「この人の操作だけ」の絞り込み
• 操作の名前と時刻 — 「差し替えだけ」「削除だけ」
• 対象の種類と識別子と時刻 — 「このファイルに起きたこと」
• 時刻のみ — 新しい順の一覧（既定の表示）

10 万行を投入した状態で実行計画を固定する自動テストを持っています。守っているのは「索引が並び順を供給し、先頭のページで打ち切れること」と「テーブル全体の走査が現れないこと」です。実行計画そのものを 1 つに固定するのではなく、許容できる索引の集合でアサートしています（絞り込みの有無でデータベースがどちらを選んでも正しいため）。

「誰が」の欄は、ログインした利用者だけではありません。アカウントを持たない相手の操作や、システムが自動で行った操作も同じテーブルに残るため、種類を 6 つに分けています。

この 6 通りの「どの欄が埋まるか」は、データベースの制約として4 分岐で強制しています。たとえば共有リンク経由の行に利用者の識別子が入っていたら、その行は書き込みの時点で拒否されます。行為者の種類と識別子の組み合わせが崩れた行は、後から見つけても直せない（更新できない）ため、入る前に止めています。

データベースには「誰がどの行に何をしてよいか」を規則として書く仕組みがあります。記録のテーブルでは、追加と参照の規則だけを書き、更新と削除の規則を書いていません。次の図は、その結果として何が通り何が止まるかを示したものです。

自分の依頼を「成功」に偽装できないようにする

CSV の取り出し依頼を記録する台帳のテーブルには、もう 1 段の防御を入れています。利用者が追加できる列を限定し、状態・出力先・件数・完了時刻といった列は追加の対象から外してあります。外さないと、「状態は成功、出力先は退避済みの月のファイル」という行を自分で追加し、それに対してダウンロード用の URL を発行させる、という経路が成立してしまいます。

さらに URL を発行する側でも、出力先の文字列がその依頼の専用の場所を指しているかを毎回確かめています。1 段目（列の限定）を越えられても、2 段目で止まります。

記録のテーブルは、見た目は 1 本ですが、内部では月ごとの子テーブルに分かれています。書き込みも読み出しも窓口は親テーブル 1 つで、どの子に振り分けるかはデータベースが決めます。

記録は「業務処理のついでに書く」ものなので、書き方を揃えておかないと、実装のたびに少しずつ違う形が混ざります。次の 3 つを規律として固定しています。

自由項目に個人情報を入れない

操作ごとに違う中身は自由項目（JSON）に入りますが、ここに何を入れるかは操作ごとに精査しています。とくにメールアドレスの実値は、原則として入れません。たとえば共有リンクの受取人や、ファイルリクエストの提出者のアドレスは、記録には残さず、表示が必要になった時点で発行元のテーブルから引き直し、伏せ字にしてから返す形にしてあります。記録に入れてしまうと、後から伏せることも消すこともできなくなるためです。

例外として、接続元の IP と端末情報は自由項目に入ります。これは調査に必要な情報で、参照できるのはシステム管理者だけ、取り出すには理由の入力が要る、という形で扱いを制限しています。