An audit log for a shared coding agent（共有コーディングエージェントの監査ログ）とは、リクエストごとに1行、承認ごとに1行で記録される追記専用（append-only）の記録であり、マシンのオーナーが保持し、エクスポートできるものです。事後的に、誰がエージェントに何を依頼し、誰がそれを許可し、実際に何が実行され、どれだけのコストがかかったのかを明らかにします。エージェントをオーナー自身しか使わないのであれば、ランタイム自身のトランスクリプトだけで十分です。しかし、2人目のユーザーがリクエストを送信できるようになった瞬間から、それでは足りなくなります。
この記事では、読み手が必要とする順序でフィールドを整理し、ログから除外すべき情報についても解説します。
リクエスト行
すべてのリクエストは、終端状態（terminal state）に達した時点で正確に1行のログを生成します。
承認行
承認は「判断」であり、実行ログとは読み手や用途が異なるため、独自の行として記録されます。
リクエスト行と承認行。承認されたプッシュは琥珀色、期限切れになった削除は赤色で表示。
ログに含めてはならない情報
- シークレット情報。 認証情報の承認ログにはキーそのものではなく、キーにアクセスがあったことのみを記録します。
- ファイル内容。 diff はパスと行数のみとします。実際の変更内容はリポジトリ側に存在し、そこではリポジトリ自体のアクセス制御が適用されます。
- コマンドの完全な出力。 失敗原因の特定には末尾（tail）の出力だけで十分です。ログ全体にはあらゆる情報が含まれ得るためです。
- 他のルームの情報。 各ルームのログはそのルーム内にスコープされます。オーナーはルーム横断で閲覧できますが、メンバーは自身が属するルームのみ閲覧できます。
フィールド設計だけでなく特性も重要
追記専用（Append-only）。 オーナーを含め、誰もログを編集できません。訂正は新しい行として記録されます。
オーナー保持。 処理を実行したマシンの持ち主（オーナー）が記録を保持し、エクスポートできます。リクエスト者はルーム内で自分自身のログ行を確認できます。
Revoke 時も完全性を担保。 権限付与やマシンの登録を取り消すと（Revoke）、キュー内の処理はキャンセルされ、実行中の処理は完了まで進められます。そのため、「何かが実行されたのに監視を停止してしまった」という空白がログに生じることはありません。
オーナーのアクションも記録。 オーナー自身のエージェントに対する操作には承認は不要ですが、そのリクエストも同様にログに記録されます。部外者の操作しか記録しないログは、リスクの半分しか記録していないのと同じです。
ログの読み取り方
頻出する3つの疑問に対して、上記のフィールドがあれば1つのフィルタリング操作で回答を得られます。
- 「誰がそれをプッシュしたのか？」 承認行を rule = push で絞り込み、依頼者と判断者を確認します。
- 「なぜこのリクエストは1時間もかかったのか？」 作成時刻と開始時刻を比較します。大抵は承認待ち時間が原因です。
- 「今月エージェントを貸し出した分のコストはいくらか？」 依頼者がオーナー以外になっているリクエスト行の使用量を合算します。
よくある質問
ルームのタイムラインが監査ログになるのですか？ タイムラインは、1回の実行に関する詳細で人間が読みやすい記録です。監査ログは、複数の実行を横断したイベントごとの1行要約であり、フィルタリングやエクスポートを目的として設計されています。muti はその両方を保持します。監査ログは daemon がアップロードする同一のイベントから生成されます。詳細は daemon がアップロードするもの を参照してください。
ログはどのくらいの期間保持されますか？ リクエスト行と承認行は、ルームが存在する限り保持されます。ルームを削除しても論理削除されるだけで、オーナー向けの記録は残ります。
リクエスト者は他の人のログ行を見ることができますか？ そのルーム内の全員のリクエストが含まれるルームのタイムラインは閲覧できます。エクスポート権限はオーナーにあります。
オーナーのリクエストも承認されないとログに記録されませんか？ いいえ。オーナーによる実行は承認なしでログに記録され、rule = owner と記録されます。
ログがあるからこそ、「後からいつでも取り消せる」という約束が形骸化しません。エージェントにルームを作成すれば、この監査ログが標準で付いてきます。
公開日