第三部：証拠の法廷（WORM＋監査ログ＋提出手順）

※本作はフィクション（Faust風の戯曲体）です。実在名を含みますが創作であり、特定の案件・訴訟・個別法務助言を目的としません。

――『青の契約（Der blaue Vertrag）』続篇

配役追加

• 裁判長クラウディウス：雲上法廷の裁判長。「提出せよ」と言うだけで世界が固まる。

• 書記官アズール：記録の人。提出物の“来歴”を問う。

• 検察官ミスティカ：疑いの槍。「改ざんできたのでは？」を執拗に刺す。

• 弁護人エコー：反響の人。「証拠の穴」を探す。

• 封緘官ワーム：WORMの司祭。封印と期限を司る。

• 証拠物件Ｅ（イー）：一つの“コンテナ”。沈黙の箱。

序幕　「法廷の扉――“提出せよ”の一語」

（舞台：雲でできた大階段。正面に巨大な扉。扉の上に刻まれている――EVIDENCE。）

書記官アズールここは証拠の法廷。言い分は後だ。まず、提出せよ。提出物には三つが要る――不変（immutability）、来歴（audit trail）、手順（procedure）。

（扉が開く。裁判長クラウディウス、白い雲のような法衣。）

裁判長クラウディウス争点は単純だ。「その文書は、改ざんされたか」「そのログは、信用できるか」――提出せよ。封緘と監査の双方を。

（山崎行政書士事務所の一団――山崎、春野、黒江、桐谷、そしてゲーテ――が進み出る。背後には水無月。顔色が青い。）

水無月……先生。相手は言ってます。「あなたが消した」「あなたが書き換えた」って。僕は、どうしたら……。

ゲーテ証拠は言葉より冷たい。だが冷たいものほど、争いに耐える。――我々は冷たい箱を持ってきた。

（封緘官ワームが、沈黙の箱を指差す。箱には「WORM」と刻まれ、鎖ではなく“設定”が巻き付いている。）

（幕）

第一場　「封緘官ワーム――時間で縫う針」

（舞台：箱の前。封緘官ワームが砂時計を掲げる。）

封緘官ワーム封緘とは、鍵ではない。封緘とは、時間だ。この箱は“書けるが、書き換えられぬ”。“読めるが、消せぬ”。――少なくとも、定めた期間は。

（黒江が前に出て、箱の仕様を淡々と述べる。）

黒江Azure Blob Storage のイミュータブル（Immutable）ストレージ。時間ベースの保持（Time-based retention policy）を設定したコンテナでは、クライアントは作成と読み取りはできるが、変更・削除ができない。保持期間が終わった後は削除できるが、上書きはできない。

弁護人エコー（すかさず）保持？ なら“保持を短く”すればいい。あるいは“保持を消す”こともできるのでは？

封緘官ワーム――それゆえに、“鍵”ではなく“儀式”がある。保持には unlocked と locked がある。unlocked は試験のため、短縮も延長も削除もできる。だが locked は違う。削除はできぬ。短縮はできぬ。延長だけが許される。

ゲーテつまり裁判長。我々が提出する箱は、“いつでも形を変えられる箱”ではない。“変えられない箱”だ。

裁判長クラウディウスよかろう。だが次の問いだ。「本当に locked なのか」「いつ locked したのか」――提出せよ、“封緘した事実”そのものを。

（幕）

第二場　「監査ログの書記――封緘は“証拠を残す行為”である」

（舞台：薄暗い書記室。ログの書記が羽根ペンではなく、光るイベントを刻む。）

ログの書記封緘には、封緘の痕跡が残る。イミュータブルのコンテナには、保持ポリシー監査ログがある。誰が、何を、いつ、どの保持期間で――それが刻まれる。

（桐谷が一枚の提出物を掲げる。そこにはコマンド種別、ユーザーID、タイムスタンプ、保持期間が並ぶ。）

桐谷公式の仕様上、時間ベース保持を有効にしたコンテナは policy audit log を提供します。locked の保持ポリシーでは、監査ログに（最大）複数の保持コマンドが記録され、ユーザーID・コマンド種別・タイムスタンプ・保持期間が含まれる。監査ログは保持ポリシーのライフタイムにわたって保持される、とされています。

検察官ミスティカ“最大複数”？都合のいい範囲だけ見せているのでは？

桐谷都合は、ログにない。ログは、都合の外側にある。

ゲーテ（低く）封緘官が封じたのは文書ではない。封緘官が封じたのは、改ざんの余地だ。そして書記が封じたのは、言い逃れだ。

（裁判長、頷く。）

裁判長クラウディウス封緘は示された。だが――文書そのものが“どのように触れられたか”。読み出し、書き込み、削除の試み。それを示せ。“誰が触れたか”は、別の層のログにいるはずだ。

（幕）

第三場　「三つの来歴――StorageRead／Write／Delete、そして外側の活動」

（舞台：鏡の回廊。三つの鏡が立つ。鏡面に刻まれた文字――StorageRead、StorageWrite、StorageDelete。）

黒江来歴には層がある。資源の“内側”で起きた操作は resource logs。資源の“外側”――作成・更新・権限変更などは Activity log。

（春野が、震える手で問いかける。）

春野じゃあ……“削除したのは誰か”は、どこに？

黒江Blob サービスの resource logs には、カテゴリとして StorageRead / StorageWrite / StorageDelete がある。これらは Log Analytics では StorageBlobLogs テーブルとして扱われる。ただし、resource logs は自動で保存されない。診断設定（Diagnostic settings）で、どのカテゴリをどこへ送るかを決めて初めて“残る”。

弁護人エコーつまり、設定していなければ“都合よく何も残らない”のでは？

ゲーテその通りだ。だから第二部で、我々は“迷宮”を作った。例外を制度にしたのと同じく、ログも制度にした。

桐谷加えて重要なのは、診断設定でストレージへアーカイブする場合、監視対象と同じストレージに送れない、という制約があることです（再帰ログを避けるため）。だから我々は、ログ用の別ストレージ（証跡保管庫）を設けました。

（裁判長が手を上げる。）

裁判長クラウディウスよい。では“外側”――Activity log を示せ。資源が作られ、権限が変わり、ポリシーが触れられた痕跡。それは外側の天候だ。

（幕）

第四場　「Activity log――雲の外から見た操作」

（舞台：高空。雲の上に、さらに雲。そこに“AzureActivity”と書かれた巻物。）

書記官アズールActivity log は、サブスクリプションレベルの出来事。“資源の外側から見える操作”の記録。そして問題は――消えることだ。

桐谷Activity log は既定で 90 日保持、とされます。長期保管が必要なら Log Analytics やストレージ等へ送ります。また、Log Analytics へ送った Activity log データは AzureActivity テーブルに格納される、とされています。

検察官ミスティカLog Analytics？そこから出力した“ファイル”は、改ざんできるのでは？

ゲーテだから――ここで第一場の箱が生きる。“抽出物”もまた証拠だ。ならば抽出物を、封緘せねばならない。

（黒江、頷く。）

黒江Activity log をストレージへ送ると、イベントが発生した時点でコンテナが作成され、一定の命名規則で JSON が保存される（例：insights-activity-logs/.../PT1H.json）と説明されています。我々はその保存先（ログ保管庫）側にも、必要な保持と統制を用意しました。

（封緘官ワームが再び現れ、箱を叩く。）

封緘官ワーム“ログを取る”だけでは足りぬ。“ログを封じる”のだ。封じたログは、提出物になる。

（幕）

第五場　「提出手順――証拠は“箱”ではなく“作法”で立つ」

（舞台：法廷中央に、もう一つ小さな箱。箱には「PACKAGE」とある。）

裁判長クラウディウスでは最後の問い。提出とは何か。――証拠は、どうやって“ここに届いた”のか。来歴を語れ。作法を示せ。

（山崎が、厚い綴りを差し出す。表紙には「提出手順（標準）」とある。）

山崎我々の提出手順は、五つの段階です。（彼は条文のように読み上げる。）

1. 保全宣言：対象を確定し、封緘棚（証拠用コンテナ）へ移す

2. 封緘設定：時間ベース保持を設定し、試験後速やかに locked へ（長期の unlocked は推奨されない、とされる）

3. 来歴採取：StorageBlobLogs（Read/Write/Delete）と AzureActivity を収集対象期間で抽出

4. パッケージ化：抽出結果＋対象ファイル＋メタデータ（ハッシュ、抽出クエリ、期間、担当者）を manifest としてまとめる

5. 封緘保管：パッケージ一式を証拠用コンテナへ保存し、以後の変更・削除を禁止

弁護人エコーハッシュ？ manifest？それはAzureの機能ではない。人間の細工だ。

ゲーテその通り。だから作法なのだ。“機能”は正しさを助けるが、“手順”は正しさを証明する。

検察官ミスティカでは、ログが“追加され続ける”場合は？ログは日々増える。封緘があるなら追加できぬのでは？

（封緘官ワームが、砂時計を揺らす。）

封緘官ワームWORMの中で“追記”する道がある。容器により、追記を許す設定がある。

黒江コンテナレベルWORMでは、allowProtectedAppendWrites を有効にすると、append blob へ新しいブロックを追記し続けられる（既存ブロックは変更・削除できない）とされています。また AllowProtectedAppendWritesAll は、追加で block blob への追記相当を可能にする旨が説明されています（Data Lake Storage API の append/flush などを用いる、とされる）。ただし、これらの追記保護設定は unlocked の間は変更できるが、locked にすると変更できない、とされています。

裁判長クラウディウスよろしい。“増える証拠”にも道がある。だが覚えよ。道があるほど、人は悪路を選ぶ。ゆえに――例外と同じく、追記も統制せよ。

（幕）

終幕　「判決――証拠は沈黙し、沈黙が勝つ」

（法廷。提出物が並ぶ。箱、ログ、手順書、監査ログ。裁判長が立つ。）

裁判長クラウディウス本件、証拠能力を認める。理由は三つ。不変の設計、来歴の提示、作法の整合。

（弁護人エコー、肩を落とす。検察官ミスティカも、槍を下ろす。）

水無月（息を吐く）……先生。言葉で戦うつもりでした。でも勝ったのは、沈黙でしたね。

ゲーテ沈黙は、設計されたときにだけ強い。設計なき沈黙は、ただの空白だ。

（封緘官ワームが、最後に砂時計を裏返す。）

封緘官ワーム証拠は、いつか失効する。だから期限を見よ。失効の前に、見直しをせよ。――封緘は永遠ではなく、責任の形だ。

（ログの書記の刻む音だけが残る。）

（終）

舞台裏メモ：この「証拠の法廷」を現実の設計に落とす要点

物語の“作法”を、Azureの概念として整理するとこうなります。

1) 証拠棚（WORM）を作るときの中核

• 時間ベース保持は、指定期間、変更・削除を不可にし、期間後は削除できるが上書きはできない。

• 保持期間は 1 日〜 146,000 日（400年）。

• locked にすると削除不可・短縮不可・延長のみ（unlocked は試験用途）。長く unlocked を使うのは推奨されない旨の注意がある。

• locked の時間ベース保持では 保持ポリシー監査ログ（ユーザーID、コマンド種別、タイムスタンプ、保持期間など）が提供され、保持のライフタイムにわたり保持される、とされる。

2) “増えるログ”をWORMと両立させる

• allowProtectedAppendWrites で append blob に追記し続けられる（既存は変更・削除不可）。

• AllowProtectedAppendWritesAll は block blob への追記相当を可能にする説明がある（Data Lake Storage API の利用等）。

• これらの追記設定は locked 後に変更できない。

3) 監査ログ（誰が触れたか）を残す

• Blob の resource logs には StorageRead/StorageWrite/StorageDelete があり、Log Analytics では StorageBlobLogs。

• resource logs は、診断設定でルーティングして初めて保存・検索できる。

• ストレージ監視の診断設定は“同じストレージ”へ送れない（再帰ログ回避）。

4) 外側の来歴（Activity log）も併せて押さえる

• Activity log は別ストアに自動収集され、長期保管は Log Analytics / Storage / Event Hubs 等へ送る。

• Log Analytics では AzureActivity テーブルに格納される。

• ストレージへ送ると、コンテナが作られ、一定命名規則でファイルが保存される。