世界を動かす技術を、日本語で。

AIがコードを書く場合、セッションはコミットの一部にすべきか?

2026年3月2日原文(github.com)

概要

  • git-memento はAIセッションの履歴を Gitノート としてコミットに保存する拡張機能
  • 複数AIプロバイダ(Codex, Claude等)に 柔軟対応
  • Markdown形式 で人間が読みやすいノートを生成
  • ノートの 共有・同期・監査 機能を標準搭載
  • GitHub Actions との連携やCIゲートもサポート

git-memento概要

  • AIコーディングセッションの記録 をGitコミットに紐付けるGit拡張
  • 通常のGitフロー(-mやエディタ利用)でコミット作成
  • AIセッショントレース をGitノートとしてコミットに添付
  • プロバイダ拡張性 を重視(Codex優先、Claude等も対応予定)
  • ノートは Markdown で保存、人間が読みやすい形
  • ノートは 複数セッション・複数プロバイダ 混在可能

基本コマンド

  • リポジトリごとに初期設定
    • git memento init
    • git memento init codex
    • git memento init claude
    • 設定は.git/configmemento.*に保存
  • コミットにAIセッションを添付
    • git memento commit <session-id> -m "通常のコミットメッセージ"
    • -mは複数回指定可能、順にgit commitへ転送
    • -m省略時はエディタ起動
  • コミット修正(amend)にも対応
    • git memento amend -m "修正件名"
    • git memento amend <new-session-id> -m "修正件名" -m "修正文"
    • セッションID未指定時は前回HEADのノートを引き継ぐ
    • セッションID指定時は既存ノートに新セッションを追加
  • ノート共有
    • git memento share-notes
    • git memento share-notes upstream
    • refs/notes/*をリモートにpush、fetch設定も自動化
  • ブランチとノートの同時push
    • git memento push
    • git memento push upstream
  • ノートの安全な同期・マージ
    • git memento notes-sync
    • git memento notes-sync upstream --strategy union
    • バックアップ作成、リモートノート取得、ローカル統合、再push
  • ノートの自動引き継ぎ設定(rebaseやamend時)
    • git memento notes-rewrite-setup
    • .git/configにrewrite設定追加
  • 範囲指定でノートを新コミットに集約
    • git memento notes-carry --onto <new-commit> --from-range <base>..<head>
  • ノート監査・メタデータ検証
    • git memento audit --range main..HEAD
    • --strictで構造不備をエラー扱い
  • リポジトリ診断
    • git memento doctor
    • git memento doctor upstream --format json
  • ヘルプ・バージョン表示
    • git memento help
    • git memento --version

プロバイダ設定

  • 環境変数やinitでプロバイダ・コマンドパス等を指定
    • 例: MEMENTO_AI_PROVIDER=claude
  • サポート環境変数例
    • MEMENTO_AI_PROVIDER(デフォルト: codex)
    • MEMENTO_CODEX_BIN(デフォルト: codex)
    • MEMENTO_CODEX_GET_ARGS(デフォルト: sessions get {id} --json)
    • MEMENTO_CLAUDE_BIN(デフォルト: claude)
  • 未設定時はgit memento init実行を促すエラー表示
  • セッションID未検出時はCodex等から候補一覧を表示

ビルド・インストール

  • .NET SDK 10 とNativeAOT対応ツールチェーンが必要
  • プラットフォームごとのビルド例
    • macOS: dotnet publish ... -r osx-arm64 -p:PublishAot=true
    • Linux: dotnet publish ... -r linux-x64 -p:PublishAot=true
    • Windows: dotnet publish ... -r win-x64 -p:PublishAot=true
  • Gitツールとしてローカルインストール
    • 実行ファイルをPATH上に配置し、git-memento名で利用
  • カールインストール
    • curl -fsSL https://raw.githubusercontent.com/mandel-macaque/memento/main/install.sh | sh

GitHub Actions・CI連携

  • Marketplace Action として再利用可能
  • 2モード
    • comment:ノートをコミットコメントとして投稿
    • gate:CIゲートとしてノート監査を実行
  • 主要入力
    • github-tokenmodenotes-fetch-refspecmax-comment-lengthaudit-range
  • インストーラアクションも用意
  • 使用例は.github/workflows配下にサンプルあり

ノート仕様と運用

  • ノートはgit notes add -f -m "<markdown>" <commit-hash>で保存
  • 複数セッションは明示的な区切りタグで管理
    • <!-- git-memento-sessions:v1 -->
  • 旧バージョンノートはamend時に自動アップグレード
  • 会話Markdownはユーザー名・プロバイダ名でラベル付与
  • デバッグ用にSerilogログ出力(DEBUGビルド時)

まとめ

  • git-memento はAI活用開発を記録・監査・共有するための 現代的Git拡張
  • チーム開発やCI/CDとの親和性が高く、 AIコーディングの透明性・再現性 向上に最適

Hackerたちの意見

なんでそうなるの?エージェントセッションは雑然とした中間出力であって、最終製品の一部にすべきアーティファクトじゃないよ。コード変更の「理由」が重要なら、エージェントにきちんとしたコミットメッセージやドキュメントファイルを書かせればいいんじゃないかな。

でも、それだとトークンと時間がもっとかかるよね。生のログを保存しておけば、後で必要なときにいつでも使えるし。フルログがあれば、後でいろんな質問ができるからね。

それってdiffログと何が違うの?

事後分析やバグハンティング -- どの論理部分が特定の問題の原因だったのかを特定すること。

私の場合、エージェントをリポジトリに設定してるんだ。リポジトリのテキストがエージェントの記憶を構成してる。リポジトリに変更を加えるには、エージェントの承認が必要なんだよ。リポジトリ同士もメッセージを送り合って、計画や変更を調整したり、機能リクエストを出したりして、そのリポジトリエージェントが管理してる。だから、エージェントの意味的に圧縮された記憶をリポジトリの一部として保持してるし、元のトランスクリプトも残してる。よく整合性を失うから、ユーザーが提出したプロンプトを全部見直すことで、仕様やストーリー、要件を再調整できるんだ。

完全に同意する。最近まで、コミットメッセージはLLMに書かせてたんだけど、プランファイルのバージョン管理の方が良いアーティファクトだって分かった。エージェントの決定や自分の推論をノイズなしで保存できるからね。今のワークフローは、まず詳細なプランを書いて、その後、エージェントがエラーを見つけたらプランを更新する標準的な実装→レビューのループを回す感じ。最終的なプラン文書は、ただのトランスクリプトじゃなくて、将来の反復にとって本当に役立つものになるんだ。

セッションやプロンプトの要約は、最低限それであるべきだと思う。例えば、研究系の質問は含めるべきじゃないけど、その質問に対する回答を読んだ後にユーザーが書いたプロンプトや、研究中に出てきたリンクや参考文献の要約は含めるべきだと思う。プロンプトは特に研究ベースのものなら要約すべきだけど、コード生成のプロンプトはそのまま保存するべきだと思う。再現性は大事だし、完璧な再現性は望ましくないけど、雰囲気コーディングは非常に理解しにくくてレビューも難しいから、その点を補う何かが必要だよね。セッションの要約があまりにも曖昧だと、悪いプロンプトや仮定がドキュメント化されていない場合に、改善や反復が難しくなる。

俺のGoogle検索履歴はコミットに含めるべき?その質問には「いいえ」と答えるよ。

例えを探してたけど、これはいい例だね。ノイズと信号の比率がすごく悪い気がする。すべての「思考」をひとつひとつ選別しなきゃいけない。もし自分の思考の流れを記録できたとして、それをコミットに加える?絶対に無理だね。理由や仮定、考慮した代替案の要約なら、もちろんそれは素晴らしいメッセージになるよ。

そのコミットに関して行ったGoogle検索が、必ずしもそのコミットに関連しているわけじゃないかもしれないよ。全く関係ない情報だったり、公開すべきじゃない敏感な情報かもしれないし。

セッションをアーカイブすると、AIが行ったすべてのGoogle検索履歴(クエリと出力)も自動的にアーカイブされるから、プロジェクトに関連してることが多いよ。

一週間前にそのアイデアを提案したんだ:https://news.ycombinator.com/item?id=47096202。ただ、「プロンプト」って言葉を使ったら、ユーザーからそれは古いって指摘された。「セッション」の方が今はいいみたい。聞いた反対意見は、(1) AIに対する単一の入力(つまり、単一のセッションやプロンプト)がないから、そんなプロジェクトは生成できない、(2) 人間とAIのやり取りはコンパイラと作業するのとはちょっと違う(ソースコード -> オブジェクトコードのループ) - それは二人のエンジニアの会話みたいなものだよ[1]。前者の場合はソースコードをアーティファクトにして「プロジェクト」として扱えるけど、後者の場合はそれができないし、(3) たとえできたとしても、結果のアーティファクトはノイズが多くて複雑すぎて、プロジェクトの一部として保存する価値はあまりないと思う。でも、今は生成されたプロジェクトのShow HNがたくさん投稿されていて、生成されたリポジトリと生成されたREADMEしかないことが多いんだ。これらを処理するためのもっと良い方法が必要だよ。古いスタイルのShow HNとして扱うのは、今はシステムをノイズで圧倒してるから[2]。これらのプロジェクトを排除したくはないんだ。なぜなら、(1) その中には良いものもあるし、(2) もっと多くの人が物を作って共有できるのは悪くないし、(3) 未来に逆らうのは愚かだし、(4) そもそも排除する明確な方法もないから。でも、現状はあまり良くない。今のところ、これらのプロジェクトはあまり面白くないからね。もっと面白くするためのサポートが必要だと思う。だから、コミュニティのみんな、どうすればいいと思う?[1] このポイントはseldrigeから来たもので、https://news.ycombinator.com/item?id=47096903とhttps://news.ycombinator.com/item?id=47108653で言及されてる。YoumuChanも同じようなことを言ってるよ:https://news.ycombinator.com/item?id=47213296。比喩は違うけど、問題(信号/ノイズ比)は同じだね。[2] Show HNは死んでるの?いや、溺れてるだけだよ - https://news.ycombinator.com/item?id=47045804 - 2026年2月(422コメント)

Hacker Newsで議論の続きを見る