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

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

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

TL;DR

Gitは何が変わったか（WHAT）を記録します。エージェントセッションはなぜ（WHY）を記録します。エージェントがコードを書くとき、セッションの記録こそが本当の設計ドキュメントであり、記録を破棄するすべてのワークフローは出自情報を破棄しています。Memento（オープンソースのgit拡張）は、AIセッションの記録をgit notesとしてコミットに添付し、コミットから推論までの出自チェーンを作成します。Claude Codeの新しいLSP統合は、セッション記録をより正確にする構造的なコード理解を追加します：grepの代わりにgo-to-definitionを使い、推測の代わりに型シグネチャを使います。以下では、出自ギャップ、セッションメタデータの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つの個別レビューセッション——それぞれが具体的な発見、エッジケース分析、承認理由を含む——は、コミットが参照しない別々の記録に存在します。エージェント委譲の各レイヤーが、見えない推論のレイヤーをもう1つ追加するのです。

出自の問題は、既存の3つの障害パターンと繋がっています。捏造ファイアウォールは、出力ゲートが存在しないとき、エージェントが未検証の主張を公開する方法を特定しました。⁶ セッションの出自情報があれば、捏造をより早く発見できたでしょう：セッション記録は、人間がレビューしていないトークンカウント手法をエージェントが捏造していることを示していました。見えないエージェントは、明示的な計装なしにはエージェントの行動が監視されないことを文書化しました。⁷ セッションの出自情報は、可視化スタックが生成する監査証跡です。NISTへのパブリックコメントでは、エージェントの行動に対する標準化された監査ログを推奨しました。⁹ セッション記録を保存するgit notesは、その推奨の1つの実装です。

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

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

Mementoの問い

Mementoプロジェクトは、git拡張で出自ギャップに答えます。² このツールはAIコーディングセッションの記録をキャプチャし、refs/notes/commitsとrefs/notes/memento-full-auditにgit notesとしてコミットに添付します。

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

124件のコメントが付いたHNの議論では、4つの立場が浮上しました：

立場1：セッションは不可欠なコンテキストである。 エージェントセッションにはコミットメッセージでは伝えられない推論が含まれています。セッションをコミットに添付することで出自チェーンが保たれます。レビュアーは任意のコード行をコミット、セッション、元のプロンプトまで遡って追跡できます。

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

立場3：記録全体ではなく要約を。 セッションは構造化された要約に凝縮されるべきです：タスクの説明、検討された代替案、判断の根拠、引用されたエビデンス。要約はノイズなしに出自を保持します。Mementoはユーザーとアシスタントのターンでラベル付けされたMarkdown要約を生成します。

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

4つの立場すべてにメリットがあります。セッションの出自価値は否定できません。ノイズの問題は現実です。プライバシーの懸念は構造的なものです。Mementoは立場1と3（Markdown変換による記録保存）および立場4（要約生成のために記録を信頼できないデータとして扱う）に対応しています。立場2は未解決の設計上の問題として残っています：どれだけのセッションコンテキストがあれば十分か？

補完的なツールが同じ問題に対して異なるアプローチを取っています。claude-replayはClaude Codeのセッション記録をビデオのようなプレイバックに変換し、レビュアーが静的な記録を読むのではなく、エージェントの作業がステップバイステップで展開する様子を見られるようにします。¹² Mementoが「何を保存すべきか？」に答えるのに対し、claude-replayは「どうレビューすべきか？」に答えます。2つのツールは出自ワークフローの異なる部分に対応しています：Mementoはデータを保存し（ストレージ）、claude-replayはデータを理解可能にします（プレゼンテーション）。両プロジェクトが同じ月に独立して出現したという事実は、この論点を裏付けています：実務者は出自ギャップを感じており、それを埋めるツールを構築しているのです。

出自の4つのレイヤー

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

各レイヤーにはコストがかかります。完全なIntentレイヤー（元のプロンプト）の保存は安価です：テキストフィールド1つです。完全なProcessレイヤー（すべてのツール呼び出し）を90分のセッションで保存すると、メガバイト単位のJSONが生成されます。Reasoningレイヤーの保存には、エージェントが判断プロセスを明示的に記述する必要がありますが、ほとんどのエージェントはデフォルトでそれを行いません。Verificationレイヤーの保存には、テストランナーとレビューシステムとの統合が必要です。

私のオーケストレーションシステムは、異なるメカニズムを通じて4つのレイヤーすべてをキャプチャします。³ キャプチャを可能にするフックインフラストラクチャは、15種類のイベントタイプにまたがる84のフックで構成されています。⁵ Intent：UserPromptSubmitフックが元のプロンプトを記録します。Process：PostToolUseフックがすべてのツール呼び出しと結果を記録します。Reasoning：エビデンスゲートが各品質基準に対して具体的な根拠を引用することをエージェントに要求します。Verification：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対応エージェントからのセッション記録は、すべてのコードナビゲーションステップが検証可能であるため、設計ドキュメントとしてより価値があります。レビュアーは、エージェントのコードベース理解が単にもっともらしいだけでなく、正しかったことを確認できます。

code-review-graphプロジェクトは、構造的理解をさらに推し進めます：セッションをまたいで存続する永続的なコードグラフで、各呼び出しでコードベースを再理解するトークンコストを削減します。¹³ LSPがセッション内で構造的クエリを提供するのに対し、永続的グラフはセッション間で構造的メモリを提供します。出自にとっての示唆は、将来のエージェントはセッション記録だけでなく、判断を生み出した構造的理解も引き継ぐということです。グラフは出自データのもう1つのレイヤーになります：「エージェントはauthenticate_userをauth.py:47で見つけた」だけでなく、「エージェントのコードグラフにはすでに呼び出し階層が含まれていたため、ナビゲーションをスキップして直接実装に向かった」ということです。エージェントの事前知識が判断に影響を与え、その事前知識は出自チェーンに含まれるべきものです。

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

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

Intentレイヤー（UserPromptSubmitフックから）：

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

Processレイヤー（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

Reasoningレイヤー（エビデンスゲートから）：

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)

Verificationレイヤー（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のMarkdown変換により、生のサイズは約60%削減されます。²

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

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

今日から実践できること

新しいツールを必要としない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つの出自レイヤーの手動バージョンです。メッセージはintent（タスク）、reasoning（代替案）、verification（エビデンス）に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つの質問に答えることを要求します：コードはどのパターンに従っているか？よりシンプルな代替案は何か？どのエッジケースが処理されているか？テストはパスしているか？リグレッションを確認したファイルはどれか？変更は実際の問題を解決しているか？¹⁰ 回答がReasoningレイヤーとVerificationレイヤーを形成します。ゲートがなければ、エージェントは「完了」と報告し、セッションにはProcessデータのみが含まれます。ゲートがあれば、すべてのコミットが品質保証の副産物として構造化された出自情報を生成します。

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

重要なポイント

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

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

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

FAQ

セッションの出自情報とは何ですか？ セッションの出自情報とは、コーディングセッション中のAIエージェントの推論プロセスの記録です：元のタスク、読んだファイル、評価した代替案、下した判断、生成したエビデンス。セッション記録は、コミットメッセージや差分では伝えられない「なぜ」をキャプチャします。

Mementoとは何ですか？ Mementoは、AIコーディングセッションの記録をキャプチャし、git notesとしてコミットに添付するオープンソースのgit拡張です。CodexとClaude Codeをサポートし、Markdown要約を生成し、PR統合用のGitHub Actionを提供します。²

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

セッション記録はgitにコミットすべきですか？ 答えはリポジトリのプライバシー要件によります。内部リポジトリの場合、記録のコミットは出自を保持します。パブリックリポジトリの場合、git notes（デフォルトではclone時に転送されない）やコミット参照付きの別ストレージがより安全なアプローチです。²

セッション出自情報にはどれくらいのストレージが必要ですか？ 典型的な30分のエージェントセッションは200KB〜800KBの生の記録を生成します。Git notesはメインオブジェクトデータベースの外にデータを保存するため、デフォルトではgit cloneのサイズは変わりません。MementoのMarkdown変換により、生のサイズは約60%削減されます。1日10〜20のエージェントセッションを実行するチームの場合、毎日2〜10MBの出自データを見込んでください——セッションあたり中解像度のスクリーンショット1枚程度に相当します。²

エージェントの可観測性とセッション出自情報の関係は？ エージェントの可観測性は、エージェントがリアルタイムで何をしているかを監視します：リソース消費、ポリシー準拠、ランタイム動作です。⁷ セッションの出自情報は、エージェントが何を判断し、なぜそうしたかを事後的に記録します。可観測性は「エージェントは今正しく動作しているか？」に答えます。出自情報は「先週の火曜日にエージェントはなぜこの選択をしたか？」に答えます。2つのシステムは補完し合います：可観測性はリアルタイムで問題を検出し、出自情報は事後にそれを説明します。

出典