はじめに：また消えた、あの判断の理由
先週 Claude Code と何度も試行錯誤して書いた認証ロジックがある。今日になってバグが出た。コードを読み返しても、「なぜこのアーキテクチャにしたか」がまったく思い出せない。セッションを閉じた瞬間に、すべての文脈が消えていた。
この感覚に覚えがある方は多いはずだ。AI との対話はターミナルやチャット画面の中で完結し、commit message には「fix: auth logic」とだけ書かれ、どんな試行錯誤を経てその実装に至ったかは記録されない。Git は「何が変わったか」を保存する。でも「なぜそう変えたか」はどこにも残らない。
この問題を正面から解こうとしているのが、元 GitHub CEO の Thomas Dohmke が 2026 年 2 月に立ち上げた Entire だ。シードラウンドは $60M / $300M バリュエーション。Felicis がリードし、Datadog 創業者の Olivier Pomel と Y Combinator の Garry Tan が個人投資家として参加している。Felicis は「developer tools 史上最大のシード」と評した規模感だ。
その第一弾プロダクトが Checkpoints——MIT ライセンスのオープンソース CLI で、Claude Code をはじめとする AI エージェントセッションを Git commit ごとに自動キャプチャする。
Dohmke が言い当てた問題の本質
Entire の創業ブログで、Dohmke はこう書いている。
> Issues were designed for human planning and tracking, not as structured, machine-readable units of work. Git repositories were never extended to version everything developers build with in the AI era.
意訳すると、「Issue は人間の計画追跡のために設計された。Git は AI 時代に開発者が使う『すべて』をバージョン管理するように拡張されてこなかった」ということだ。
Git は人間がコードを書く時代の産物で、AI が大量のコードを生成し、一人の開発者が複数の AI セッションを並行させる時代には対応していない。AI エージェントの推論、プロンプト、棄却された設計案、トークン消費——これらは現在どこにも保存されない。Dohmke の言葉を借りると、「massive volumes of code are being generated faster than any human could reasonably understand」という状況が生まれており、その背後の 意思決定ログ が完全に失われている。
公式 News ページでは自動車産業の比喩も使っている。「伝統的なクラフト生産をムービングアセンブリラインに置き換えたように、ソフトウェア開発も AI 時代に合わせた production system の変革が必要」という主張だ。Checkpoints はその変革の最初の一手として位置づけられている。
Checkpoints の仕組み：Git に追加される audit log
インストールと有効化
インストールは 1 コマンドだ。
curl -fsSL https://entire.io/install.sh | bashプロジェクトディレクトリで有効化する。
entire enableこれで Git hook が登録される。以後、commit するたびに AI エージェントとの会話コンテキストが自動でキャプチャされる。
何を、どこに保存するか
キャプチャされるのは、AI との会話トランスクリプト・プロンプト・編集ファイル一覧・トークン使用量・ツール呼び出しと推論の記録だ。
保存先は通常の作業ブランチではなく、entire/checkpoints/v1 という専用ブランチ。commit するたびに append-only で書き込まれ、コードの変更は通常のブランチに残しつつ、AI セッションの文脈だけが別ブランチに蓄積される。
各 commit には 12 文字の Checkpoint ID が commit message の trailer として追加される。git log --show-trailers で確認でき、entire.io のダッシュボードへのリンクキーになる。
Rewind でセッションを巻き戻す
entire rewind は、過去の Checkpoint まで作業状態を戻せる機能だ。「ここで方針を変えたのはなぜだったか」を当時のやり取りから確認したり、途中の分岐点から別の方向を試したりできる。Restore modes は「ログのみ復元」「commit を detached state で checkout」「ブランチを完全に巻き戻す」の 3 種類があり、コードを失わずにセッション文脈だけを取り出すことも可能だ。
2026 年 6 月時点で対応しているのは Claude Code、Gemini CLI、Cursor、GitHub Copilot CLI、OpenCode、FactoryAI。実務で使われている主要ツールは網羅している。
個人開発者にとっての使い道
「あの時の判断」を即座に呼び戻す
個人で AI コーディングを使い込むと、コンテキスト切り替えのコストが増える。1 週間前に書いた認証ロジックのバグを今日修正するとき、「なぜこの実装にしたか」が思い出せないまま闇雲にデバッグする、というシチュエーションだ。
Checkpoints があれば、git log で気になる commit を見つけ、その Checkpoint ID をダッシュボードで開けばいい。当時の Claude との会話、採用した設計案、棄却した設計案が一覧で確認できる。「あの試行錯誤」を再現する必要がなくなる。
ポートフォリオと技術発信の素材になる
「AI と一緒にこういうものを作りました」という発信をするとき、会話履歴があると格段に深い記事が書ける。「ここで Claude にこう問いかけた、この提案は採用しなかった理由はこれ」という流れが、単なる完成品の紹介より読み手に刺さる。
筆者もこのブログで Claude Code 主体の制作プロセスを断片的に記録してきたが（Dynamic Workflows 記事や AgentCore 記事でも一部触れている）、Checkpoints があれば「この記事は何回の AI セッションで完成したか」「途中で方針転換した瞬間はどこか」がコミット単位で追跡できる。
学習履歴として積み上げる
新しいフレームワークを AI と一緒に学ぶとき、Claude や Cursor との対話そのものが教材になる。3 ヶ月後に同じ問題で詰まったとき、「当時の自分はどう乗り越えたか」を Checkpoint から読み返せる。メモに頼らない、コードに紐づいた学習ログだ。
フリーランスの納品物として使う
フリーランス開発者にとって「何をやったか」の説明は、納品物の一部だ。Checkpoint ID 付きの commit 履歴を顧客と共有すれば、「AI でこの部分をこう実装した」「ここは手で書いた」が明確になる。AI 時代の透明性として、顧客の信頼につながりやすい。
チームで使うと何が変わるか
個人活用と異なり、チームでは「複数人が AI を使ってコードを書く」「PR レビューや知識共有のフローに Checkpoints をどう組み込むか」という視点が要る。
PR レビューで「なぜこの実装か」が一目でわかる
AI が書いたコードの PR は、コードが綺麗でも「なぜこの設計にしたか」が読み取りにくいことがある。コミットの trailer に Checkpoint ID が付いていれば、レビュアーはそれをクリックするだけで、作者が AI にどう問題を説明したか・どう推論したか・採用/棄却された案・触ったファイルの全体像を確認できる。
「これ、なぜこういう判断にしたんですか？」というレビューコメントの多くが、Checkpoint を見れば自己解決する。PR レビューのラウンドトリップが減るだけで、チームの速度は変わる。
チーム内 Stack Overflow として機能する
「あの問題、A さんが先月解いてたよね、どうやったんだっけ」という場面は、どのチームにも存在する。チームで entire.io の dashboard を共有すれば、Slack で 12 文字の Checkpoint ID を貼るだけで、A さんの当時の試行錯誤が全員から見える。ドキュメントを書くより低コストで、コードに紐づいたナレッジが共有される。
マルチエージェント協調の audit trail
Dynamic Workflows 記事で扱ったように、Claude Code の動的ワークフローでは 1 つのリクエストが複数の subagent に分解されて並列実行される。各 subagent が何を判断したかを、コードレベルだけで追いきるのは難しい。
Entire の公式 Vision ページには「Semantic Reasoning Layer」という将来ロードマップが示されており、agent-to-agent コラボレーションの記録も明示されている。現時点では先取り的だが、マルチエージェント協調の audit trail としての活用は、Dohmke のビジョン上の次の一手だ。
採用面接の補助ツールとして
「AI と協働できるか」を採用基準に入れたい組織が増えている。コーディング課題の提出物に Checkpoint ID 付きの commit があれば、「どこで詰まり、どう乗り越えたか」が読める。コード単体では見えない「思考過程」の評価が可能になる。
コンプライアンス・監査ログとして
金融・医療など規制業界では「AI が判断に関わった部分を後で追えるか」が監査要件になりつつある。AgentCore 記事で触れたように、エンタープライズでは Identity / Policy / Observability の組み合わせで AI の動作を記録する必要がある。Checkpoints は Git レイヤーでその役目を補完する。
既存ツールとの位置関係
GitHub / GitLab との関係
Entire は GitHub の代替ではない。Git を共通基盤として残しつつ、AI 時代に欠けていた「reasoning の version 管理」を追加する位置取りだ。Dohmke 自身が GitHub 出身なので、GitHub を壊すのではなく「Git の上に乗る agent context layer」として設計されている。
Cursor / Continue.dev との比較
Cursor にはチームでの context 共有機能があるが、Cursor の中で完結する。Entire は agent agnostic で、Claude Code、Cursor、Gemini CLI、Copilot CLI、OpenCode、FactoryAI のどれにも対応する。エンタープライズで複数 AI ツールが並行する場合の統合 audit layer として価値を発揮する。
OpenTelemetry との補完関係
OTel 記事で扱った観測スタックは、Claude Code セッション単位のテレメトリを扱う。Entire は Git commit 単位の context を扱う。「AI が何を消費したか（OTel）」と「AI が何を考えて何を書いたか（Entire）」の二軸で補完関係にある。
三層スタックとして組み立てる
Agent View 記事で扱った複数セッション管理、AgentCore 記事で扱った本番運用基盤と合わせると、一つのスタックが見えてくる。開発時は Claude Code + Entire Checkpoints で session と decision context を Git に永続化し、本番運用は AWS Bedrock AgentCore、観測は OpenTelemetry というセッション単位のテレメトリで補う。
Entire の公式 Vision ページが掲げる 3 層——Version Control for Agents、Semantic Reasoning Layer、AI-Native Software Development Lifecycle——は、このスタック全体の設計思想と重なる。
HTML vs Markdown 記事で扱った「AI 生成成果物の配布フォーマット」と対比すると、Entire は「AI 生成プロセスの記録フォーマット」の話だ。両者を組み合わせると、AI 時代のドキュメンテーション全体像が見えてくる。
注意点と運用上の落とし穴
プライバシーリスクを事前に見積もる
AI に投げたプロンプトに API キーや個人情報が含まれることがある。Checkpoints は append-only でこれらを保存するため、誤って機密情報を含むプロンプトを送った場合の取り消しが難しい。チームで導入する前に、プロジェクトごとに「プロンプトに含まれうる情報の種類」を整理しておく。pre-commit hook でのシークレットスキャン、または entire.io 側の redaction 機能の有無を確認することを勧める。
git push --all の誤 push に注意
entire/checkpoints/v1 は同じリポジトリ内の別ブランチに存在する。git push --all を習慣的に使っている場合、AI 会話履歴が意図せず社外公開リポジトリに push される可能性がある。チームの Git workflow で git push --all を使っているなら、.git/config で checkpoint ブランチのリモート追跡を除外する設定を入れておくのが安全だ。
branch の肥大化を計画する
entire/checkpoints/v1 は append-only なので、長期運用で肥大化する。Git LFS との組み合わせや retention policy の検討が必要になるタイミングが来る。初期段階から「6 ヶ月ごとにアーカイブする」といった運用ルールを決めておくと後が楽だ。
早期段階のプロダクトとして扱う
2026 年 2 月の発表から 4 ヶ月。Checkpoints は公開済みで実用できるが、Entire が目指す「プラットフォーム」としての全機能は 2026 年後半に予告されている。dashboard の有料化タイミング、self-hosted の有無、ロードマップの変化については継続的に公式情報を確認する。$60M のシードと Dohmke のキャリアからリスクは低い方だが、preview 段階のプロダクトとして運用設計に余裕を持たせておく。
チームのルールを CONTRIBUTING.md に書く
チームで使うなら「commit には Checkpoint ID を付ける」「dashboard のアクセス権は誰が持つか」「checkpoint ブランチの push 設定はどうするか」を CONTRIBUTING.md か CLAUDE.md に明記する。ルールがないまま広まると、後から整理するコストが高くなる。
entire enable の 1 コマンドから始める
Checkpoints の価値は、使い始めるまでのコストが限りなく低い点にある。OSS で無料、curl でインストールして entire enable を打つだけだ。Git hook が登録されれば、以降は何もしなくても commit のたびに AI セッションのコンテキストが蓄積されていく。
dashboard を開いて初めて「あの時の Claude との会話」が出てきたとき、「こういうことが消えていたのか」と気づく。Claude Code を使っているなら、今日のプロジェクトで試してほしい。
curl -fsSL https://entire.io/install.sh | bash
entire enableEntire のビジョン全体は、まだ始まったばかりだ。Checkpoints はその層1であり、2026 年後半に予告されているプラットフォーム launch で何が開放されるかは未知数だ。ただ、「AI が書いたコードの意思決定が消える問題」は今この瞬間から発生しており、その解決を後回しにする理由はない。
コメント