セッションがコミットメッセージである

ある開発者がコードベースを引き継ぎます。git blameを見ると、1つのコミットで47ファイルが変更されています。メッセージには「refactor auth module」とだけ書かれています。コミットの作者は人間の開発者として記載されています。実際の作者はコーディングエージェントで、90分間実行され、200ファイルを読み、3つの代替アプローチを評価し、そのうち2つを具体的な理由で却下し、すべての認証エンドポイントに影響する変更セットを生成しました。90分間にわたる設計判断、却下された代替案、議論されたエッジケースは消えてしまいました。Gitは何が変わったかを保存しました。なぜ変わったかは何も保存されていません。

私の認知的負債の記事では、エージェントの出力速度と開発者の理解速度のギャップを「認知的負債」と名付けました——レビューされないコミットが積み重なるたびに複利で増える負債です。¹ Mementoプロジェクトは100のHNポイントと124のコメントを集めましたが、次の問いを投げかけています：セッションに推論が含まれているなら、セッションはコミットの一部であるべきではないか？²

TL;DR

Gitは何が変わったかを記録します。エージェントセッションはなぜ変わったかを記録します。エージェントがコードを書くとき、セッションのトランスクリプトこそが本当の設計ドキュメントであり、トランスクリプトを破棄するワークフローは出所情報（プロベナンス）を破棄しています。Memento（オープンソースのgit拡張機能）はAIセッションのトランスクリプトをgit notesとしてコミットに添付し、コミットから推論までのプロベナンスチェーンを作成します。Claude Codeの新しいLSP統合は、構造的なコード理解を追加し、セッションのトランスクリプトをより正確にします：go-to-definitionがgrepに取って代わり、型シグネチャが推測に取って代わります。以下では、プロベナンスギャップ、セッションメタデータの4つの層、Mementoが構築するもの、LSPがセッションデータの品質をどう変えるか、そして今日から実装できる最小限のプロベナンスプラクティスについて解説します。

プロベナンスギャップ

Gitはすべての変更について5つのことを追跡します：誰が行ったか、いつ行ったか、どのファイルが変更されたか、差分、そしてコミットメッセージです。人間が書いたコードの場合、コミットメッセージは差分と意図の間のギャップを橋渡しします。良いメッセージはその変更がなぜ存在するかを説明します。悪いメッセージ（「fix stuff」）はレビュアーにコードから意図を再構築させることになります。

エージェントが書いたコードは異なるプロベナンス構造を持っています。意図は開発者の頭の中にはありません。意図はセッションの中にあります：タスクを開始したプロンプト、エージェントが読んだファイル、評価した代替案、呼び出したツール、完了報告時に引用した証拠です。90分間のエージェントの推論を1行のコミットメッセージに要約することは、判断コンテキストの99.9%を破棄することになります。

この損失は理論上のものではありません。私のオーケストレーションシステムは、セッション状態ファイル（jiro.state.json、jiro.progress.json）を生成し、すべてのストーリー完了、レビュアーの判定、エビデンスゲートの結果を記録します。³ レビュアーが「なぜエージェントはサーキットブレーカーではなく指数バックオフを使ったのか？」と質問したとき、セッション状態ファイルにはその答えがあります：エージェントは両方のパターンを評価し、上流サービスがRetry-Afterヘッダー付きのリトライ可能な503を返すことを発見し、ヘッダーの値を尊重するために指数バックオフを選択しました。コミットメッセージには「refactor: standardize retry patterns」と書かれています。セッション状態にはその理由が記録されています。

セッションプロベナンスがなければ、エージェントが書いた変更のコードレビューは考古学になります。レビュアーは差分を読み、推論を逆算し、変更がなぜ存在するかについて仮説を立てます。その仮説は間違っているかもしれません。エージェントの実際の推論はセッションのトランスクリプトに記録されており、利用可能です。業界標準のワークフロー（コミット、プッシュ、差分をレビュー）は推論を捨ててしまいます。

この問題はエージェントの合成によって倍増します。私のオーケストレーションシステムはコードレビュー用の専門サブエージェントを生成します：正確性レビュアー、セキュリティレビュアー、規約レビュアーです。⁵ 各サブエージェントは独自のセッションを実行し、独自のファイルを読み、独自の結論を形成します。親エージェントが判定を集約します。最終的なコミットメッセージには「3 reviewers: approve」と書かれます。3つの個別レビューセッション——それぞれが具体的な発見事項、エッジケース分析、承認理由を含む——は、コミットが参照しない別々のトランスクリプトに存在しています。エージェント委任の各層が、不可視の推論の新たな層を追加します。

プロベナンスの問題は、既存の3つの障害パターンにつながります。ファブリケーション・ファイアウォールは、出力ゲートが存在しない場合にエージェントが未検証の主張を公開する問題を特定しました。⁶ セッションプロベナンスがあれば、ファブリケーションをより早く検出できたはずです：セッションのトランスクリプトは、エージェントが人間にレビューされていないトークンカウント手法を捏造していることを示していました。不可視のエージェントは、明示的な計装なしにはエージェントのアクションが監視されない問題を文書化しました。⁷ セッションプロベナンスは、可視性スタックが生成する監査証跡です。NISTへのパブリックコメントでは、エージェントアクションの標準化された監査ログを推奨しました。⁹ セッションのトランスクリプトを格納するgit notesは、その推奨の一実装です。

私の品質システムのエビデンスゲートは、各品質基準に対してエージェントが具体的な証拠を引用することを要求します：パターンを指名し、代替案を説明し、エッジケースを列挙し、テスト出力を貼り付ける。¹⁰ エビデンスゲートは、そうしなければ存在しなかったであろう推論層と検証層のデータをエージェントに生成させます。ゲートがなければ、エージェントは「完了」と報告し、セッションにはプロセスデータ（ツール呼び出し）のみが含まれます。ゲートがあれば、セッションにはレビュアーがコードと照合して検証できる明示的な根拠が含まれます。

Gitだけでは、90分間の慎重な推論を表す47ファイルのコミットと、レビューなしで90分間制約なく実行されたエージェントによる47ファイルのコミットを区別できません。gitのドキュメントでは、notesを「オブジェクト自体を変更せずにオブジェクトに添付できる追加情報」と説明しています。⁸ セッションのトランスクリプトはまさにこの定義に合致します：コミットハッシュ、差分、履歴を変更することなく、コミットのプロベナンスに関する追加情報を提供するものです。

Mementoの問い

Mementoプロジェクトはgit拡張機能でプロベナンスギャップに答えます。² このツールはAIコーディングセッションのトランスクリプトをキャプチャし、git notesとしてコミットに添付します。refs/notes/commitsとrefs/notes/memento-full-auditに格納されます。

ワークフロー：git memento initでリポジトリを設定します。git memento commit <session-id>がgit commitに代わり、設定されたAIプロバイダー（CodexまたはClaude Code）からセッションのトランスクリプトを自動的に取得し、構造化されたメタデータとしてコミットに格納します。

124件のHNコメントでの議論から、4つの立場が浮かび上がりました：

立場1：セッションは不可欠なコンテキストである。 エージェントセッションにはコミットメッセージでは表現できない推論が含まれています。セッションをコミットに添付することでプロベナンスチェーンが保存されます。レビュアーはコードの任意の行からコミット、セッション、元のプロンプトまでさかのぼることができます。

立場2：セッションはノイズである。 90分間のセッションのトランスクリプトは数千行の会話です。その大部分は最終的な変更セットとは無関係です。完全なトランスクリプトを添付するとシグナルがノイズに埋もれ、レビューが容易になるどころか困難になります。

立場3：トランスクリプトではなくサマリー。 セッションは構造化されたサマリーに蒸留されるべきです：タスクの説明、検討された代替案、判断の根拠、引用された証拠。サマリーはノイズなしにプロベナンスを保存します。Mementoはユーザーとアシスタントのターンでラベル付けされたマークダウンサマリーを生成します。

立場4：プライバシーとセキュリティの懸念。 セッションのトランスクリプトにはAPIキー、内部URL、他のファイルからのプロプライエタリコード、開発者が永続的なgit記録に残したくない会話内容が含まれている可能性があります。セッションは添付前にサニタイゼーションが必要です。

4つの立場すべてに妥当性があります。セッションのプロベナンス価値は否定できません。ノイズの問題は現実です。プライバシーの懸念は構造的なものです。Mementoは立場1と3（トランスクリプトの格納とマークダウン変換）と立場4（サマリー生成時にトランスクリプトを信頼できないデータとして扱う）に対応しています。立場2はまだ未解決の設計課題として残っています：どの程度のセッションコンテキストで十分なのか？

プロベナンスの4つの層

エージェントセッションのメタデータは4つの層に整理され、それぞれが変更に関する異なる質問に答えます。

各層にはコストが伴います。完全な意図層（元のプロンプト）の格納は安価です：テキストフィールド1つです。完全なプロセス層（すべてのツール呼び出し）の90分間のセッションの格納は、メガバイト単位のJSONを生成します。推論層の格納にはエージェントが判断プロセスを明示的に説明する必要がありますが、ほとんどのエージェントはデフォルトではそれを行いません。検証層の格納にはテストランナーとレビューシステムとの統合が必要です。

私のオーケストレーションシステムは、異なるメカニズムを通じて4つの層すべてをキャプチャしています。³ キャプチャを可能にするフックインフラストラクチャは、15のイベントタイプにわたる84のフックで構成されています。⁵ 意図：UserPromptSubmitフックが元のプロンプトを記録します。プロセス：PostToolUseフックがすべてのツール呼び出しと結果を記録します。推論：エビデンスゲートがエージェントに各品質基準の具体的な根拠を引用することを要求します。検証：jiro.state.jsonファイルがテスト出力とレビュアー判定を記録します。

フックはまた、エージェントがどのスキルをどの順序で呼び出したかも追跡します。¹¹ /reviewスキルに続いて/testスキルから生じたコミットは、単一の構造化されていないセッションからのコミットとは異なるプロベナンスプロファイルを持ちます。スキルの順序はワークフローパターンを明らかにします：テストの前にレビューか、レビューの前にテストか？この順序は品質保証のカバレッジを理解する上で重要です。データは複数の状態ファイルにまたがって存在しています。問題は、そのいずれもgitコミットに添付されていないことです。

プロベナンスの橋としてのLSP

Claude Codeの新しいLSP（Language Server Protocol）統合は、セッションプロベナンスデータの品質を変えます。⁴

LSP以前、Claude Codeはgrepとファイル読み取りでコードベースをナビゲートしていました。エージェントが関数の定義を見つける必要があるとき、すべてのファイルで関数名を検索していました。検索はあいまいな結果を返しました：複数のマッチ、部分的なマッチ、コメントに関数名を含むテストファイル。エージェントは最も可能性の高いマッチを選択しました。セッションのトランスクリプトには次のように記録されました：「authenticate_userを検索、auth.py、test_auth.py、middleware.pyで発見。」プロベナンスデータには検索、あいまいさ、エージェントの最善の推測が含まれています。

LSPを使えば、エージェントはgoToDefinitionを呼び出し、約50ミリ秒で正確なファイルと行番号を受け取ります。⁴ セッションのトランスクリプトには次のように記録されます：「authenticate_userはauth.py:47で定義。」プロベナンスデータは正確で、あいまいさがなく、機械的に検証可能です。セッションを読むレビュアーは、エージェントが正しい定義を見つけたことを信頼できます——異なるモジュールの似た名前の関数ではなく。

この改善はセッション全体にわたって複合的に効きます。grepを使って200ファイルを読むエージェントは、「Xを検索、候補マッチA、B、Cを発見、Aを選択」というセッションデータを生成します。LSPを使って200ファイルを読むエージェントは、「Xはfile:lineで定義、参照はfile:line、file:line、file:line」というセッションデータを生成します。LSPに裏付けられたセッションは、エージェントのコード理解の正確なマップです。grepに裏付けられたセッションはあいまいな近似です。

LSPはプロベナンスの品質を向上させる6つの機能を追加します：

プロベナンスへの意味合い：LSP対応エージェントからのセッションのトランスクリプトは、すべてのコードナビゲーションステップが検証可能であるため、設計ドキュメントとしてより価値があります。レビュアーは、エージェントのコードベース理解が単にもっともらしいだけでなく、正確であったことを確認できます。

セッションメタデータの実例

私のオーケストレーションシステムからの実例。ストーリー：「認証エンドポイントにレート制限を追加する。」

意図層（UserPromptSubmitフックから）：

Prompt: "Implement rate limiting on POST /auth/login.
  Use sliding window, 5 attempts per minute per IP.
  Return 429 with Retry-After header."

プロセス層（PostToolUseフックから）：

Files read: 14 (auth/, middleware/, tests/)
Files written: 3 (rate_limiter.py, auth.py, test_rate_limit.py)
Bash commands: 7 (pytest x3, pip install x1, curl x3)
Duration: 23 minutes
Token usage: 87K input, 24K output

推論層（エビデンスゲートから）：

Pattern: Sliding window (token bucket rejected
  because per-IP granularity requires separate
  counters, sliding window handles this natively)
Edge cases: IPv6 normalization, proxy headers
  (X-Forwarded-For validated against trusted proxy list)

検証層（jiro.state.jsonから）：

Tests: 12 passed, 0 failed, 0 skipped
Reviewers: correctness (approve), security (approve),
  conventions (approve with note: add docstring to
  rate_limiter.py:RateLimiter class)
Evidence gate: 6/6 criteria met

同じ変更のコミットメッセージ：「feat: add rate limiting to auth endpoint」。14語です。セッションメタデータには2,300語の構造化されたプロベナンスが含まれています。コミットメッセージとセッションコンテキストの間のギャップは2桁です。

プロベナンスのコスト

セッションプロベナンスは無料ではありません。3つのコストが普及を制約しています。

ストレージ。 90分のエージェントセッションは500KB〜2MBの生トランスクリプトを生成します。1日10コミットの場合、完全なトランスクリプトはgitリポジトリに毎日5〜20MB追加されます。Git notesはメイン履歴の外にデータを格納するため（デフォルトではgit cloneのサイズに影響しません）、refs/notes/memento-full-auditの監査証跡は蓄積されます。Mementoのマークダウン変換は生サイズを約60%削減します。²

プライバシー。 セッションのトランスクリプトにはエージェントが見たすべてが含まれています：ファイル内容、環境変数、APIのレスポンス、スタックトレース付きのエラーメッセージ。パブリックリポジトリに添付されたトランスクリプトは内部の実装詳細を露出させます。Mementoはトランスクリプトを信頼できないデータとして扱い、サマリーモデルに埋め込み命令を無視するよう指示しますが、完全な監査証跡の生トランスクリプトにはアクセス制御が必要です。²

シグナル対ノイズ比。 エージェントが12ファイルを変更するために200ファイルを読む90分間のセッションには、188ファイル分の無関係なプロセスデータが含まれています。課題はナビゲーション（ノイズ）と判断ポイント（シグナル）を区別することです。4層モデルが役立ちます：意図と推論は高シグナル、プロセスは混在、検証は高シグナルです。意図と推論をデフォルトで格納し、プロセスをオンデマンドで格納するプロベナンスシステムは、重要な判断コンテキストを失うことなくノイズを削減します。

今日から実装できること

新しいツールを必要としない4つの最小限のプロベナンスプラクティス：

1. 構造化されたコミットメッセージ。 「refactor auth module」を構造化されたフォーマットに置き換えます：

feat: add rate limiting to auth endpoint

Task: sliding window rate limiter, 5/min per IP
Alternatives: token bucket (rejected: per-IP overhead)
Evidence: 12 tests pass, 3 reviewers approve
Session: 23 min, 87K tokens, 14 files read

このフォーマットは4つのプロベナンス層の手動版です。メッセージは意図（タスク）、推論（代替案）、検証（証拠）に4行で答えます。ツールは不要です。

2. セッションのトランスクリプトをコミットと一緒に保存する。 エージェントセッションの後、トランスクリプトをリポジトリ内のファイルにエクスポートします（例：.sessions/2026-03-02-auth-rate-limit.md）。パブリックリポジトリの場合は.gitignoreに追加し、内部リポジトリの場合はコミットします。git notesインフラストラクチャなしでトランスクリプトをレビューに利用できます。

3. エージェントが作成したコミットにタグを付ける。 gitトレーラーを使用して、エージェントが生成したコミットをマークします：

Agent: Claude Code (Opus)
Session-Duration: 23m
Files-Read: 14
Files-Written: 3

トレーラーはエージェント関与の機械的に解析可能な記録を作成します。git log --grep="Agent: Claude Code"ですべてのエージェント作成コミットを一覧できます。メタデータにより、将来のツールが遡及的な注釈なしにプロベナンスチェーンを再構築できます。

4. エージェントコミットにエビデンスゲートを要求する。 エージェントがコミットする前に、6つの質問に答えることを要求します：コードはどのパターンに従っているか？よりシンプルな代替案は何か？どのエッジケースが処理されているか？テストは通過するか？リグレッションをどのファイルで確認したか？変更は実際の問題を解決するか？¹⁰ 回答が推論層と検証層を形成します。ゲートがなければ、エージェントは「完了」と報告し、セッションにはプロセスデータのみが含まれます。ゲートがあれば、すべてのコミットが品質保証の副産物として構造化されたプロベナンスを生成します。

エビデンスゲートの実践は、より広いプロベナンスの議論につながります。コミット前に判断を正当化しなければならないエージェントは、制約なく実行されるエージェントよりも高品質なセッションメタデータを生成します。ゲートはプロベナンスを受動的な副産物（何が起きたかの記録）から能動的な品質シグナル（何が起きたか、なぜ起きたかをエージェントに説明させる）に変えます。

重要なポイント

エンジニアリングマネージャー向け： 1行のメッセージが付いたエージェント作成のすべてのコミットは、設計ドキュメントを破棄しています。セッションのトランスクリプトには推論が含まれています。その推論がチームのコードレビュー、オンボーディング、インシデント対応のワークフローにとって価値があるかどうかを判断してください。答えが「はい」なら、最低でも構造化されたコミットメッセージを実装してください。

開発者向け： エージェントが書いたコードを引き継ぐとき、コミットメッセージは何が変わったかを教えてくれます。セッションのトランスクリプト（保存されていれば）はなぜ変わったかを教えてくれます。チームのエージェントワークフローでセッションプロベナンスを推進してください。Mementoプロジェクトはgitネイティブのアプローチを提供します。構造化されたコミットメッセージはインフラストラクチャ不要の出発点を提供します。

ツールビルダー向け： LSP統合は、あいまいなgrepベースのナビゲーションを正確で検証可能なコード参照に置き換えることで、セッションのトランスクリプトの価値を高めます。エージェントのコード理解の改善はすべて、セッションが生成するプロベナンスデータの品質を向上させます。4つのプロベナンス層を保存するエクスポートフォーマットを構築してください。

FAQ

セッションプロベナンスとは何ですか？ セッションプロベナンスとは、コーディングセッション中のAIエージェントの推論プロセスの記録です：元のタスク、読んだファイル、評価した代替案、下した判断、生成した証拠。セッションのトランスクリプトは、コミットメッセージや差分では表現できない「なぜ」をキャプチャします。

Mementoとは何ですか？ MementoはオープンソースのGit拡張機能で、AIコーディングセッションのトランスクリプトをキャプチャし、git notesとしてコミットに添付します。CodexとClaude Codeをサポートし、マークダウンサマリーを生成し、PR統合のためのGitHub Actionを提供します。²

LSPはエージェントセッションをどう改善しますか？ Language Server Protocolはエージェントに構造的なコード理解を与えます：正確な定義、型付き参照、呼び出し階層、リアルタイム診断。LSP対応エージェントからのセッションのトランスクリプトには、あいまいなgrep結果の代わりに、正確で検証可能なコードナビゲーションデータが含まれます。⁴

セッションのトランスクリプトはgitにコミットすべきですか？ 答えはリポジトリのプライバシー要件によります。内部リポジトリの場合、トランスクリプトをコミットすることでプロベナンスが保存されます。パブリックリポジトリの場合、git notes（デフォルトではclone時に転送されません）またはコミット参照を持つ別のストレージがより安全なアプローチです。²

セッションプロベナンスにはどのくらいのストレージが必要ですか？ 一般的な30分のエージェントセッションは200KB〜800KBの生トランスクリプトを生成します。Git notesはメインのオブジェクトデータベースの外にデータを格納するため、デフォルトではgit cloneのサイズに変化はありません。Mementoのマークダウン変換は生サイズを約60%削減します。1日に10〜20のエージェントセッションを実行するチームの場合、毎日2〜10MBのプロベナンスデータが見込まれます。セッションあたり中解像度のスクリーンショット1枚程度に相当します。²

エージェントのオブザーバビリティとセッションプロベナンスの関係は？ エージェントのオブザーバビリティは、エージェントがリアルタイムで何をしているかを監視します：リソース消費、ポリシー遵守、ランタイム動作。⁷ セッションプロベナンスは、エージェントが何を決定し、なぜ決定したかを事後的に記録します。オブザーバビリティは「エージェントは今正しく動作しているか？」に答えます。プロベナンスは「なぜエージェントは先週の火曜日にこの選択をしたのか？」に答えます。2つのシステムは補完関係にあります：オブザーバビリティは問題をリアルタイムで検出し、プロベナンスはその後で問題を説明します。

出典