- git-memento は、AIが生成したコードセッションを Gitコミットに自動記録 する拡張ツールで、各コミットに対応するAIの会話履歴を git notes として保存する
- コミット時にAIセッションIDを指定すると、要約は
refs/notes/commits、完全な会話は refs/notes/memento-full-audit に分けて保存され、追跡性とプライバシー を同時に確保できる
- Codex や Claude など多様なAIプロバイダーをサポートし、要約生成時には ユーザー定義スキル を適用してコミットノートの品質を制御できる
- GitHub Actions と統合され、コミットノートの自動コメント化、CIゲート検証、マージ時のノート自動引き継ぎ（merge-carry） 機能を提供する
- Windows/Mac/Linux対応。AIコード生成の透明性を高め、協業環境で AIの貢献履歴の監査（audit）可能性 を確保するツール
git-memento 概要
git-memento は AIコーディングセッションをコミット単位で記録 するGit拡張ツール
- コミット時にAIセッションの会話内容を整理して Markdownノート として保存
- 各コミットにAIセッションの 出所と会話コンテキスト を残し、コード生成プロセスを追跡可能にする
- デフォルトで Codex をサポートし、Claude など他のAIモデルも設定可能
- MITライセンスで公開されており、NativeAOTベースの単一実行ファイル として配布される
主なコマンドと機能
git memento init でリポジトリごとの設定を初期化し、AIプロバイダー情報を .git/config に保存git memento commit コマンドでコミットと同時にセッションノートを追加
--summary-skill オプションを使うと、要約版と完全セッションを分けて保存- 要約版は
refs/notes/commits、完全ログは refs/notes/memento-full-audit に記録
git memento amend は既存コミットに新しいセッションを追加または修正できるgit memento audit はコミット範囲内でノート欠落の有無とメタデータの有効性を検査git memento doctor は設定、ノート参照、リモート同期状態を点検
ノート管理と同期
git memento share-notes でリモートリポジトリ（origin など）へノートをプッシュgit memento notes-sync はリモートノートを安全にマージし、バックアップを作成
refs/notes/commits と refs/notes/memento-full-audit の両方を同期
git memento notes-carry はリベースやスカッシュ後にノートを新しいコミットへ引き継ぐgit memento notes-rewrite-setup は自動ノート引き継ぎ設定を有効化
GitHub Actions 統合
- リポジトリには 再利用可能なGitHub Action が含まれている
mode: comment — コミットノートを読み取り 自動コメントを作成mode: gate — CI段階でノート欠落の有無を検査 し、失敗時はビルドをブロックmode: merge-carry — PRマージ時にノートをマージコミットへ引き継ぐ
- 各モードは
action.yml で定義され、マーケットプレイス登録用アーティファクト（dist/note-comment-renderer.js）を含む
ignore-notes ラベルが付いたPRはゲート検査をスキップし、「Notes ignored」コメントを残す
ノート形式とバージョン管理
- ノートは
git notes add -f -m "" 形式で保存
- 複数セッション対応のため、バージョンタグ（``）と区切り記号を使用
- ユーザーメッセージはGitユーザー名、AI応答はプロバイダー名でラベル付けされる
- 既存の単一セッションノートは必要に応じて自動アップグレードされ、互換性を維持する
4件のコメント
プライベートなプロジェクトではセッションをエクスポートしてコミットし、パブリックなものは要約ファイルがどうしても必要だと判断した場合に限ってコミットしています。
やはり個人情報もありますし……ツールごとに違いますが、セッションごとに10MBを軽く超えるので……そのまま上げるのはちょっと気が引けるんですよね。
でも、私たちはディスクがかつてないほど安い時代に生きているのですから！
Hacker Newsの意見
私はAIと一緒にコードを書くとき、project.md ファイルから始めます
そこに欲しい結果を説明し、AIにその内容をもとに plan.md を書かせます
その後、plan.md を何度も修正し、望む計画が完成したら、詳細な todoリスト を作って plan.md の末尾に貼り付けます
完全に満足したら、AIに todo を実行するよう指示し、もう質問せず最後まで進めさせます
最後に project.md と plan.md、そしてコード全体をコミットします
こうすると plan.md が一種の 再現可能なアーティファクト になり、後でもっと進化したモデルがそれをもとに修正したりバグを見つけたりできます
design は機能単位で書き、未解決の問いを明示します
plan は
plan/[feature]/phase-N-[description].mdという構成で管理し、ビルドや実行の限界にぶつかったら中断しますdebug 段階ではあり得る原因の仮説を立て、ロギング/トレーシング で検証したうえで修正します
このやり方で新規プロジェクトでもレガシーでもほぼ100%の成功率でした
欠点は markdown ファイルが増えすぎることですが、過去の記録が将来の変更に役立つので、まだ自動化していません
GitHub spec-kit を参考にするとよさそうです
モデルに市場調査や提案レビューをさせて反復していると、モデル自身が理解できる言語で プロンプト設計 をするようになります
最近 XMLがClaudeの動作に影響する と知り、GuardRails の構造を見直しています
紹介記事リンク
plan が完成したら「context.md」を作り、あとで誤った計画を巻き戻すときの参考にします
まだ実際に使う機会はありませんでしたが、概念としては有用です
ただ、こうしたファイルをどこに置くべきか曖昧なので、まだリポジトリには含めていません
こうした 作業ごとの md ファイルをどこに保存 しているのか気になります
私の考えでは、これは「すべての行をコミットすべきか？」と同じ問題です
結局のところ核心は 誰のための記録なのか です
ほとんどのセッションにはノイズが多く、誤った試行や不要な情報がたくさん含まれます
重要なのはセッションの成果物であって、その過程自体ではありません
ただし初期の spec や最初のプロンプトには価値があります。それを要約してコミットメッセージや markdown ファイルに残すのがよいでしょう
過去のセッションを学習コンテキストにして現在の作業を引き継がせることができます
とくにモデルの限界を理解し、コードがユーザーの意図から外れた箇所を見つけるのに役立つ可能性があります
結局のところ、すべての 人間の入力を記録 することがオープンソースモデルの発展に重要だと思います
初期条件やノイズを含めても同じ結果が出るべきです
そうでなければ将来のコード保守は 意図を推測するゲーム になってしまいます
関連記事
1週間前に似たアイデアを提案しました（リンク）
ただ反対意見も多く、AIプロジェクトは単一の入力から生成されるのではなく対話的な過程なので、ソースコードのようなアーティファクトにしにくい という点です
それでも Show HN に投稿される生成プロジェクトが多すぎて、ノイズが深刻 な状況です
完全に排除することはできませんが、現状のままでは興味が薄れます
コミュニティがこの問題をどう扱うべきか考えています
research.md と plan.md をコミットし、アーキテクチャと機能の 生きた辞書 として使っています
機能名をファイル名の接頭辞に付けて、Claude が関連設計をすばやく呼び出せるようにしています
参考ブログ
以前なら面白かったプロジェクトが、今ではあまりにも簡単に作れてしまいます
長いセッションログを読ませることが解決策ではありません。要約力と企画力 のほうが重要になります
vibe coding の本当の価値は 試行と失敗の過程 を見ることにあります
単に成果物だけを出すより、制作過程と解説 があるほうが面白いです
なので [Show HN] とは別に [Creations] のようなカテゴリがあればいいと思います
例: 単純なチェスエンジンは [Creations]、1kで作ったチェスエンジンは [Show HN]
PerfBoard と Lerc がその例です
セッションは 中間成果物 にすぎず、最終成果物に含める必要はありません
コード変更の理由が重要なら、コミットメッセージや文書 に整理するべきです
コミット時点では未来の読者がどんな質問をするか分かりません
だから私はセッションを保存しておき、後で 質問ベースで要約を生成 する方法を好みます
Git AI はこうしたアプローチを使っています
最近のエンジニアは作業スピードが速すぎて、1週間もするとどうしてそうしたのか思い出せないことがよくあります
研究型のプロンプトは要約し、コード生成型のプロンプトはそのまま保存するのがよいでしょう
そうすれば 再現性とレビュー可能性 が確保できます
計画がエラー修正の過程まで反映するので、次の反復に役立つ文書になります
各リポジトリが互いにメッセージをやり取りしながら機能要求を管理します
元の対話と 意味圧縮された記憶 を一緒に保存して、仕様と要件を再配置します
セッションログの大半は ノイズ です
間違った試行と巻き戻しの連続であり、コミットの横に置くのはブラウザ履歴を保存するようなものです
重要なのは 意図と制約条件 を含んだコミットメッセージです
AIがコードを書いたとしても、核心は会話そのものではなく なぜそのように依頼したのか です
結局のところ問題はセッション保存ではなく、コミットメッセージをおろそかにする習慣 なのかもしれません
私はAIを使うとしても 伝統的な設計手順 を維持します
要件 → ユースケース → クラス設計 → 制約条件の定義 → AIの実行
こうすれば人間の アーキテクチャ判断力 を保ちながら、AIは反復実装を加速できます
セッションログの代わりにこうした UML/制約文書をコミットに含めれば、意図と文脈 を明確に残せます
2026年の開発者はこうした 品位ある協業構造 を守るべきだと思います
これはコミットを squashするかどうか の問題に似ています
squash を好むなら結果だけが重要で、過程は残しません
そうでなければ旅路そのものを記録します
AIセッションも同じで、思考過程のデバッグ には有用ですが、きれいな履歴を好む人はわざわざ見ません
セッションはリポジトリ外で別途管理するのが現実的です
Mercurial や Fossil はこうした機能がより優れていると聞きました
vibe-coding ではコードそのものより プロンプトが思考の痕跡 を示します
git に入れるかどうかは別として、アクセスできるようにしておく価値はあります
その場合、リアルタイムの過程を見る必要はありません
ですが完全にAIが書いたコードなら、プロンプトの公開 は必要です
私もセッションを抽出してみました
多少の情報損失リスクはありますが、可読性とアクセス性 はずっと良くなります
少なくともセッションの 要約されたプロンプト は保存すべきだと思います
AIコードレビューは人間ほど厳密ではなく、意図はプロンプトにしか含まれていません
そうしないと同じミスを繰り返すことになります
コードレビューの価値は学習と改善にありますが、AIは学習しないので プロンプト記録 がその役割を代替すべきです
また プロンプト能力の評価 やジュニア教育にも必要です
私たちはキーストロークやメニュークリック、デバッグの試行のようなものをコミットには含めません
すべての会話を保存すると ノイズが多すぎます
代わりに意図や前提が含まれた文書程度を残すのが現実的です
「Google検索履歴をコミットに含めるべきか？」という質問と同じです — もちろん違うと思います
代わりに 理由、前提、代替案の要約 だけ残すのがよいでしょう
同じように、モデルが些細な問題で迷ったログも不要です
> 「Googleの検索履歴をコミットに含めるべきか？」という質問と同じこと — もちろん違うと思う
このコメント、いいですね