ハクソク

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

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

47日前原文(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/configのmemento.*に保存
  • コミットに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-token、mode、notes-fetch-refspec、max-comment-length、audit-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コメント）
└
提案された変更についてのメーリングリストの議論にリンクしているコミットがたくさんあるから、LLMセッションのアーカイブみたいなものがあればいいかもね。
└
残念ながら、Codexはセッション全体をマークダウン形式でエクスポートできないみたい。そうじゃなければ、みんなにそれをShow HNに含めるように勧めたいんだけど。今やエンジニアリングプロセスの一部になってるのに、エクスポートがこんなに難しいのはおかしいよね。バイブコーディングアプリには反対じゃないけど、面白いのはそのバイブコーディングセッションや、途中の失敗を見れることなんだよね。彼らが問題空間を探るのを見ながら学べるから。
└
> 結果として得られるアーティファクトは、あまりにも騒がしくて複雑すぎて、プロジェクトの一部として保存してもあまり価値がないだろう。これが私にとっての大きな障害なんだ。でも、要約を保存することには価値があるかもしれない。基本的には、会議のメモを取って重要なポイントをまとめるのと同じことだね。
└
なんで通常の投票システムはここで機能しないんだろう？新しいShow HNが多すぎて、良いものが埋もれちゃうのかな？
└
現在の考えは、ボリス・タネスの形式化されたClaudeコードでのコーディング方法に基づいてる。最終的にClaudeにコードの変更を実装させるとき、研究とplan.mdファイルをそのままコミットするんだ。これがアーキテクチャや追加された機能の生きた辞書になる。ボリスの方法からのほんの少しの違いは、すべての研究とplan.mdファイル名の先頭に機能の名前を付けること。以前の設計文書をClaudeに読ませることで、関連するアーキテクチャをすぐにコンテキストに読み込めるんだ。関連性があると思う部分を取り出して、Claudeにその設計文書を基に研究させるように指示するよ。[1] https://boristane.com/blog/how-i-use-claude-code/
└
あなたが言ってるノイズについてだけど、mementoがgitの「ノート」機能を使うのは、そのノイズを抑えるためのいい方法かもしれないね。あんまり価値がないかもしれないけど、少なくともユーザーが関係ないと判断したときに簡単にフィルタリングできる別の場所に置けるから。リンク先のリポジトリのREADMEによると、> 「コミットを実行して、クリーンなMarkdownの会話を新しいコミットのgitノートとして保存します。」だから、通常のコミット履歴には影響しないみたい。gitはノートを特別に保存するからね（https://git-scm.com/docs/git-notes）。実際、GitHubはそれを表示すらしないらしいよ、最近見たブログ記事によると（2年前の）。他のgitインターフェース（magitや他のフォージ）についてはわからないけど、git logは確実に無視できるよ（https://git-scm.com/docs/git-log#Documentation/git-log.txt--...）。保存されたアーティファクトが必ずしも価値があるわけじゃないけど、もっと単純な解決策（コミットメッセージやトラッキングファイルのディレクトリに保存すること）とは違って、普通のワークフローの邪魔にはならないかもしれないね、少しリポジトリが膨らむかもしれないけど。
└
> 現状は良くないよ。今のところ、これらのプロジェクトはあまり面白くないから。もっと面白くするための何かサポートが必要だと思う。個人的には、面白くないのは文脈が足りないからじゃなくて、「これには努力と思考が必要だった」という基準が変わったからだと思う。だから、2年前に面白いと考えたものを作るのがずっと簡単になった。もしHNの読者に追加のコミット履歴や「セッションのトランスクリプト」を見てもらって、それが面白いかどうかを判断させるなら、ノイズが多すぎて失敗してるよ。選別する価値があるノイズが多すぎるからね。プロジェクトが価値を持つためには、エレベーターピッチは「バイブコーディングされたものX」とはまったく違う必要があると思う。
└
1. コメント - 完全自動のHNコメントやアカウントは禁止 - 誰もが読む理由が思いつかないし、他の人に読ませる必要もない。 2. GAIを使った投稿には、タイトルにテキストタグを付けることを求める。例えば「Show HN GAI」みたいな感じで - これは良い第一歩で、主に読者が監視できる。1点目は完全自動の投票リングを防ぐために重要だと思う。2点目は後で別の処理の準備のため - これらの投稿については人間が書いた説明を求めることができるかも？複雑な自動要件は実行可能ではないと思うから、シンプルに保つべきだね。それに、ショーポストだけで十分かどうかも気になる。AIを使って巨大で迷走した記事を書くブログスパム投稿を結構見かけてるから。
└
> では、コミュニティの皆さん、私たちは何をすべきでしょうか？私の診断では、以前の摩擦（プロジェクトを作るための努力）が低努力のプロジェクトをフィルタリングし、コミュニティが処理できる提出数を維持していたと思います。摩擦が大幅に減少した今、低努力のコンテンツが増えて、コミュニティの処理能力を超えてしまった（これが本当の問題です）。だから、2つの選択肢があります：摩擦を増やすか、処理能力を増やすか。処理能力を増やす選択肢はあまり魅力的ではないと思います。タグやカテゴリーを追加して異なるニッチやキューを作ることができますが、最も人気のあるタグはやっぱり圧倒されるでしょうが、ニッチなものは繁栄するでしょう。それは悪くないと思うけど、サイトの哲学に反すると思うから、興味を持たないだろうな。だから、私が提案したいのは、もっと厳しい提出プロセスを作ることです。 - 週に1回だけShow HNを提出できるようにする。 - すぐに全員に見えないようにレビューキューに入れる。 - レビュアーとして資格のあるユーザー（アカウントが少なくとも1年経っているとか、Show HNに少なくとも1回投稿したことがある人）がフィードバックを提供する（コメントとして）ボランティアできて、提出を承認できるようにする。 - N人に承認されたら、投稿される。 - 提出者が必要な承認を得られなかった場合、フィードバックを確認して、次の週に再提出できる。 高努力のプロジェクトはスムーズに通過するはず。十分な努力がされていないプロジェクトやShow HNのガイドラインに従っていないプロジェクト（例えば、アカウントが制限されている場合）は、もっと磨きをかけて再挑戦する機会が与えられる。レビュアーの要件についての注意点：多くの良いコメントは、ほとんど投稿しない古いアカウントを持つ人から来ることが多いので、karmaが100未満のこともある。私の解釈では、こういう人たちは経験が豊富だけど、特に意味のある貢献があるときだけコメントするんだ。だから、アカウントの年齢に要件を設けて（自作自演から自分を承認するのを難しくするため）、karmaには柔軟に対応することを提案するよ。
明らかにそうだね。少なくともセッション内のプロンプトがなくても、簡単な自動化されたプロンプトの抽出は必要だよ。AIが生成したコードは、人間が作ったコードほど慎重にレビューされることは明らかにないし、意図や仮定はプロンプトに依存して、AI生成のコメントに限られた程度でしか文書化されない。そうじゃないと、バグを修正する時に、最初の問題を引き起こした同じプロンプトや仮定を使って、ゼロからやり直すリスクがある。コードレビューが時間をかける価値がある理由の多くは、人々が改善するのを学べるからで、将来のミスを防げるからなんだ。コードレビューは基本的な問題を超えて「正確性」についてではなく、微妙な論理エラーは一般的に見つけるのが難しいからね。それはテスト（あるいは、残念ながらデプロイ時の驚き）でカバーされる。今のところ、AIには学習がないから、コードレビューの価値が大きく減ってしまう。でも、将来のミスを防ぐことが目的なら、コードに至るプロンプトについての情報があれば、レビュー過程に少しでも価値が戻るんじゃないかな。編集：ビジネスの観点からも、優秀なプロンプターやAIユーザーを選別する必要があるよね。セッションがどうだったかの証拠がないと、それは難しい。あと、ジュニアにバイブコーディングを改善させるには、彼らのセッションについて何も見えないとどうやって教えるの？
└
> 明らかにそうだよね。でも、これが明らかだとは全然思わない。キーストロークのログをコミット履歴の一部にすることはないし、メニュー項目の選択もコミット履歴に含めない。デバッグ中に行う20回の試行もコミット履歴には入れない（まあ、そうする人もいるかもしれないけど、僕の知ってるほとんどの人は、コミットする前に同じファイルを何度も書き直したり、中間コミットをリベースしたりして、もっと有用な論理的なコミットにまとめたりしてる）。検索履歴もコミット履歴には入れないし、プロジェクトについて2人の開発者が話し合った内容もコミット履歴には含めない。こういったことの中には、コミット履歴やその横に保存しておくと役立つこともあるかもしれない。例えば、特定のコミットの意図や前提条件についてのドキュメントがあると、将来的にかなり価値があるけど、プロジェクト内の2人の開発者のすべての議論をコミット履歴に含めるのは、ノイズが多すぎてほとんど得るものがないと思う。AIのプロンプトやセッションも同じような感じだね。
個人的には、これは逆張りの意見かもしれないけど、そうは思わないな。これは、例えば、書いたすべての行や関数がコミットになるべきかという問題と同じだと思う。こういう細かさについては、結局、誰のためにこれらのセッションを残すべきかを考えなきゃいけない。未来のエンジニアやLLMがそれにアクセスする必要がある理由は少ないと思うよ。多分、ノイズや間違った実装、無駄な情報がたくさん含まれてるだろうから。セッションの成果が重要だと思う。最初の仕様や「最初のプロンプト」（これは経験上、通常はもっと大きくて80%くらいまで進めようとするもの）を保存する方が価値があると思う。そして、もしかしたらその仕様についてのLLMの要約や、セッション内での仕様の変更、構築したものの要約が製品の一部かもしれない。でも…それはコミットメッセージにするべき？それともMarkdownファイルに？Notionとかに入れるのもありかも。
└
LLMセッションのトランスクリプトをコミットの一部にするのは面白いアイデアだけど、正直言って、git blameを使って誰かを探してるときに「あなたは絶対に正しい！それはfooじゃなくてbarです」みたいな八ページのスラップを読みたくないな（しかも各コミットごとに！）。解決策はいつも通りで、コミットメッセージは、なぜそのコミットをしたのかを簡潔に明確に伝える場所だよ。初期のトランスクリプトをdocs/ディレクトリかどこかにコミットするのはいいアイデアだと思う。多分、サイドプロジェクトでこれを始めるつもり。
└
> 例えば、書いたすべての行や関数がコミットになるべきかという問題と同じだと思う。うーん、それは間違った比較じゃないかな？もっと有用な比較は、あなたが作ったすべてのノートや試した行き止まりがコミットの一部になるべきかってことかも。
└
最初のN個のプロンプトは、保存する価値のあるものに対する良い／実用的なヒューリスティックだね（Nが1でもそれ以上でも）。
└
これは、科学研究で既に広がりを見せている中心的な問題で、もし同じことが基盤となるコードに埋め込まれることを許されると、未来は暗いと思う。再現性の危機[1]。初期条件を考慮しても、「ノイズ」を考慮しても、LLMは同じ出力に到達するのだろうか。それは、数学の問題が解法を示す必要があるのと同じ理由で、そうあるべきだと思う。科学論文では、方法や擬似コードが必要で、限界も明記しなければならない。似たようなガードレールがないと、将来のコードのメンテナンスや拡張は「自分で選ぶ冒険」になってしまう。LLMの意図や条件を推測しなければならないから。[1] https://www.ipr.northwestern.edu/news/2024/an-existential-cr...
└
バイブコーディングの現実を無視してるよ。誰かがただプロンプトを出して、コードを読まず、結果をほとんどテストしないなら、そのプロンプトは貴重な洞察になるかもしれない。でも、どちらかを応援してるわけじゃなくて、ただ言ってるだけ。
└
僕にとっては、選択肢を残すことが大事なんだ。ファイルの最新の変更から30日以内に `resume {session_id}` を実行できるなら、そのストーリーの糸を進め続ける可能性が高いし、選ぶことにしたときの摩擦を取り除けるからね。
└
すべてを保存するべきではないと思う - ノイズが多すぎるから。でも、セッションが面白いのは、まさに会話の後半部分、詳細の修正があって、実際の、より正確な要件が明確になるところなんだよね。
└
特別な場所で働いていて、透明性が重要な場合には、監査に一定の価値があるかもしれないけど、誰がそんなの全部読むの？それに、コミッターが何か企んでたら、トランスクリプトがコードに対応してるかどうかもわからないし。
└
人間が読むには騒がしくて複雑だけど、このセッション情報は主に未来のAIが読むためのもので、タスクの追加入力として使われるんだ。LLMに過去のセッションを全部取り込ませて、現在のセッションのコンテキストとして使うことができる。つまり、現在のセッションをずっと長い前のセッションの延長として扱う感じ。さらに、未来のモデルは現在のモデルの限界を「理解」できるかもしれなくて、生成されたコードがユーザーの意図からどこで逸脱したかを特定するために、過去のセッション情報を使えるかもしれない。それはコード生成に役立つか、可能性のある「ホットスポット」に焦点を当てた効率的な分析になるかもしれない。とにかく、未来のモデルのために人間の入力をすべてキャッチする時期が来てると思う。特にオープンソースモデルの開発においては、企業がすでにこの種のデータをたくさん持っているのは確かだから。
└
> これらのセッションを保存することの利益は誰にあるの？将来のエンジニアやLLMがそれにアクセスする必要がある理由はほとんどないと思う。 それには反対だな。レガシーコードに取り組むとき、私の最大の問題の一つは「なぜこうなっているのか？」という質問なんだ。開発者はドキュメントを嫌がるし、Jiraはプログラミング中に決定されたことが更新されてないことが多いから、時には「wait(500)」や「n = n - 1」がなぜあるのかを推測しなきゃいけない。もしAIで書かれていて会話の履歴が利用できるなら、「このコードはなぜここにあるの？」とAIに聞けるから、将来的にそのコードに触れるときに大幅に時間と頭痛を節約できるんだ。
概念的には、これはコミットをスクワッシュすべきかどうかの問題に非常に似てる。要するに、同じ質問だと思う。もしコミットをスクワッシュすべきだと思うなら、最終的なコード変更にしか興味がないってこと。開発者がそこに至るまでの歴史は捨ててしまってもいい。逆に、スクワッシュすべきじゃないと思うなら、開発者が最終的なコード変更に至るまでの道のりを振り返りたいってこと。どちらのアプローチも異なる理由で有効だけど、どのチームでも長く激しい議論の元になるよね。AIセッションの履歴をコードと一緒に保持することはデバッグに役立つかもしれない（コードのデバッグよりも思考過程のデバッグが多いけど）けど、「スクワッシュを好む」開発者は通常、変更の履歴よりも既存のコードを見て軌道修正することを好むから、コミットを見ない人がAIセッションを見始める理由はないよね。それを踏まえると、AIの記憶はリポジトリの履歴とは別に保存・管理できるし、選んだLLMにとってもっとアクセスしやすい方法でできるから、多分必要ないと思う。
└
これは正しいアナロジーだと思うよ、このスレッドの他のひどいものとは対照的に。確かに、コミットメッセージを見ることは珍しいけど、場合によっては非常に価値がある。雰囲気コーディングでは、理由についてのドキュメントが全くないリスクがあるけど（AIのコメントやテストは無意味になることもある）、プロンプトは少なくとも理由や動機について何かを明らかにするよね。これがgitに必要かどうかは副次的な問題だけど、これを利用できることにはメリットがある。
└
私は一般的にスクワッシュ派だけど、クリーンでバイセクタブルなリポジトリ履歴を求める気持ちから来ている。もしgit（やgitフォージ）が原子的なマージコミットを見せてくれて、内部の歴史や反復、もしかしたらLLMセッションのようなものをスムーズに展開できるなら、それはいいと思う。で、確かに私の理解では、mercurialやfossilは実際にgitよりもこれを多くやってるけど、実際にそれを使ったプロジェクトには関わったことがないからコメントできない。
└
これは、ソフトウェアがまだ人間によって作られ、AIをツールとして使っている場合にのみ機能する。そういう場合、AIの使い方はエディタのマクロやテスト駆動開発に似ている。リアルタイムでそのプロセスを見る必要はない。ただ、ソフトウェアが全く人間によって作られていない場合は、どうなるかはあまり明確ではない。その場合、プロンプトを見たいと思う。
これについて考えて、履歴やチャットをプロジェクトフォルダに持ってくるためのClaudeコード拡張も作ったんだけど、役に立ったことは一度もないよ。コードや簡潔なドキュメントから意図が明確でないなら、そのコードはダメだし、磨き直す必要がある。意図を持って書かれた良いコードは、LLM（大規模言語モデル）で瞬時に解釈できる。開発者やLLMをドラフトの迷路に送り込むのは、認知やコンテキストの無駄遣いだよ。
AIを使ってコードを書くときは、まずプロジェクトの内容を説明するproject.mdファイルを作るんだ。それから、そのproject.mdから変更内容を説明するplan.mdファイルを作るように頼む（もしゼロからなら何を作るかも）。そのplan.mdをAIと一緒に何度もやり直して、理想の形にする。満足したら、plan.mdから詳細なtodoリストを作るように頼んで、それをplan.mdの最後に付け加える。完全に満足したら、plan.mdの最後にtodoリストを実行するように指示して、他には何もしないで、質問もせずに完了するまで作業させる。それからproject.mdとplan.mdをコードと一緒にコミットするんだ。だから、plan.mdを正しくするためのやり取りはログには残らないけど、マージやスクワッシュの前の中間コミットに似てる。plan.mdは、AIや他のエンジニアが何が起こったかを理解し、プロセスを繰り返すためのアーティファクトだよ。これをやる主な理由は、モデルが1年後にもっと良くなったときに、project.mdと既存のコードに基づいてplan.mdを修正するように頼めるから。自分のミスを見つけてくれるかもしれないしね。
└
>そのplan.mdをAIと一緒に何度もやり直して、理想の形にする。 どのツールやインターフェースを使ってるの？ Opencode/claude code？Gas town？
└
この素晴らしいアイデア、いただきます！シェアしてくれてありがとう！
└
仕様駆動型のアプローチみたいだね。これを見てみるといいよ。https://github.com/github/spec-kit
└
私も似たようなことをやってるけど、最初に仕様のmdファイルを繰り返し確認するのが結構うまくいってる。すべてのステップが詳細で明確で、mdファイルがマスタープランにリンクされていると、かなりスムーズに進むんだ。Claudeのコードは小さな増分でしかうまく動かないから、コンテキストスイッチがあると混乱して余計なことを考えちゃう。だから、増分で作業することで、クリーンなセッションをコミットしやすくしてる。コンテキストをクリアする前に、仕様から次のプロンプトをもらうように頼んでるんだ。どこかで必ず横道にそれるけど、いい構造があると自分でもクリーンなレビューがしやすくて、捨てなきゃいけない2時間のセッションを避けられる。各ステップで間違ってるところだけを調整するのがすごく楽なんだよね。意外とうまくいくよ。
└
私も似たようなことをやってるけど、デザイン、プラン、デバッグの3つのドキュメントタイプを使ってる。デザインはあなたのプロジェクト.mdファイルに似てるけど、機能リクエストごとに分けてる。オープンな質問や未知のことを明示的にアウトラインするように頼んでるよ。デザインドキュメント（つまり design/[feature].md）が十分に繰り返されたら、プランドキュメントに移る。プランドキュメントは `plan/[feature]/phase-N-[description].md` みたいに構成されてる。ここからエージェントはプランが「完了」するまで繰り返し作業して、ビルドやインストール、実行の制限にぶつかると止まる。そうなったら、新しいデザインやプランファイルに戻るか、デバッグフローに入る。プランのプロンプトと似たように、デバッグは現在の実装をレビューして、何が間違っているかのN-M仮説をアウトラインするように指示する。これらの仮説をレビューして、時には繰り返して、一つずつ対処していく。デバッグフローに関しての重要なポイントは、手動デバッグと同じように、仮説を確認するためにエージェントにログやトレースを記録させる方が、直接修正に進むよりも良いことが多い。こういう方法を使うことで、グリーンフィールドでもレガシープロジェクトでも100%の成功率を得られたよ。注意点として、時間が経つにつれてマークダウンファイルの数が膨大になるのが主な不満だけど、まだ自動化する必要は感じてない。時々、これらの歴史的なプランやデバッグファイルが将来の変更に役立つこともあるからね。
└
私も似たようなことをやってるけど、ClaudeにCodexを毎ステップでレビューさせてフィードバックを返してもらってる（その逆も日によってあるけど）。
自動でセッションを共有できたら最高なんだけど、個人情報や秘密はしっかり隠したセッションを共有したいな。エージェントラッパーに「セッション共有」機能を追加して、innerHTMLを取得してCloudflareにアップロードするようにしたんだ。これで、プロジェクトを最初から最後までどうやって作ったかをシェアできる。例えば、https://github.com/kzahel/PearSync/blob/main/sessions/sessio... みたいにね。興味がある人がエージェントとのやり取りを見れるのは価値があると思う。生のJSONLを共有するのは多分無駄だし、絶対パスが多すぎて意図せずに情報を共有するリスクがあるからね。https://github.com/peteromallet/dataclaw?tab=readme-ov-file#... ってプロジェクトは、PIIや秘密を取り除こうとしてるのを見たけど、今は全てのセッションを共有する気にはなれないな。どんな秘密が入ってるか分からないから。
いいえ、AIが人間を置き換えるように設定されている場合、そのプロンプトスキルやアプローチだけが、他の灰色の大衆と差別化する唯一の要素だから。