目次
Agentがコードを書く速さは、チームが「マージしてよいか」を決める速さより先に進みがちだ。有用な問いは「あるforgeが一夜でGitHubに取って代わるか」ではなく、誰がマージを決めるか——AIレビュー点数、CIゲート、人手承認、あるいはその組み合わせである。2026年10月26日、Entire（CEO／共同創業者 Thomas Dohmke）はその問いに沿った独立Git forgeを開いた。公式は 今日からすべての開発者に利用可能 とする。当サイトでは 2026-10-27時点 の発表ニュースとワークフローブログに基づき整理しており、GitHub・GitLab・Cursor Originとの対照実測はしていない。
AIレビュー費用の近刊：CodeRabbit、11月8日まで組織あたり Deep Scan 利用を最大 $5,000 まで負担（総額 $1M）。
TrailsとPR：画面上で何が変わるか
古典的な Pull Request は diff が中心だ。コメントが時系列に積み上がり、CI状態がマージボタン付近に付き、人（と増え続けるレビューボット）がスレッドで議論する。Entireブログの論点は、Agentが変更の大半を書くと、そのタイムラインはAgentが読み返す監査ログに近くなり、開発者には「十分安定してマージできるか？」の信号が足りない、というものだ。
Trail はEntireの代替HUDだ。公式資料は、要件・セッション痕跡・コード変更・レビューを一つの場所に置く——線形コメント流よりパイロットの計器盤に近い——と書く。ワークフローブログの3ステップ：
- Trailを開く。 Entire上のバグ／機能要求から、または実装の前後にAgentから開始できる——「プッシュの準備ができたときPRを開く」に近い。Trailは複数リポジトリにまたがり、関連変更をまとめられる。
- プッシュごとに採点。 審査Agentがカスタム可能なevalsを走らせ、それぞれスコアと根拠を返す（Entireはフィギュアスケートの審査員に例える）。自社の多くのリポジトリで Security、Slop、Human Review Required などを使うとし、直近5回＋現在を表示してワンショットのノイズを見える化する。
- findingsを閉じてからマージ。 Agentは重大度と修正案付きの findings を返せる。未解決は常に見え、解決済みは隠せるが取り戻せる。Agentも人も対処／dismissできる。人もPR同様にfindings／コメントを投稿できる。
オープンソースの Entire CLI がループに入る：コーディングAgentがfindingsを閉ループで直し、人が進捗を検証する。これは製品口径の要約であり、「高リスクdiffを永遠に読まなくてよい」という主張ではない。
ブログは審査Agentの下層に Claude Code や Codex などを使え、Daytona／E2B系の隔離サンドボックスで動かすと書く。当サイトはこれを Entire公式の審査スタック説明 として記すだけで、両ツールへのサイト内評価のお墨付きにはしない。料金・利用上限の対照は：Claude Code と Codex、どちらを選ぶ？料金と利用上限を比べてみた。
Gates：点数・テスト・人手承認はそれぞれ何を担うか
Gates はマージ方針レイヤだ。Entireはリポジトリ単位で有効化でき、例えば次を要求できるとする：
| 制御 | 通常答えること | 単独では答えられないこと |
|---|---|---|
| AI評価スコア／findings | 審査AgentがSlop・Security・「人手レビュー要」を付けたか？未解決findingsは解消／dismiss済みか？ | 自組織の脅威モデルに合うか？スコアは信号であり、セキュリティ保証ではない。 |
| CI（Buildkite／Depot） | このプッシュのビルド・テストは通ったか？ | 関心のある失敗モードをテストが覆っているか？緑のCI＝正しさの証明ではない。 |
| 人手承認 | 名指しの人が残余リスクを引き受けたか？ | 承認者は高リスク経路を実際に読んだか？承認は説明責任であり全知ではない。 |
平たく言えば：スコアはAgent審査ループが安定したかの表面化、CIは自動化ビルド／テストがまだ通るか、人手承認は「誰かがこのマージを所有する」スイッチだ。Entireの主張は、自信が高くリスクが低くfindingsが閉じたときにマージする——Agentが書いたdiffの全行を人が再読しなければならない、ではない、というものだ。規制対象や高リスクリポジトリに合うかはチーム判断であり、当サイトでは代行しない。
これも、脅し見出しを書かない理由だ。Agent成果に点数を付けマージをゲートする仕組みは、ワークフローの問い——人がAgentの全コミットを行単位でレビューし切れないとき、どう出荷を続けるか——に答えようとする。現行ホストが陳腐化した証拠ではなく、Buildkite／Depot変換がsecretsやランナー構成に合うか分からないうちにGitHub Actionsを捨てる理由でもない。
GitHub側の権限・マージ隣接の近刊：GitHub Copilot の Assisted permissions が一般提供開始。
BuildkiteとDepot：CIがTrailに載るまで
Entireは Buildkite と Depot と提携し、ビルド／テストをAgentのプッシュ速度に追いつかせる。公式ワークフローの要点：
- Buildkite： CIはプロジェクト単位（複数リポで共有しがち）。接続後、毎回のプッシュがBuildkiteまたは自前基盤でビルドされ、結果がTrail上のチェックになり、失敗はマージを止められる。AgentはBuildkite API／CLI／MCPでループを回せる。GitHub Actions利用者は
bk pipeline convertでワークフローを変換でき、全面書き換えは不要。 - Depot： Depot CIはGitHub Actions互換ワークフローを、間にGitHubを挟まず走らせる位置づけ。Entireから接続後、
depot ci migrateがActionsワークフローを発見してDepot CIへ昇格し、要レビュー項目を旗立てる；付随コマンドでsecrets／変数を取り込める。
どちらも「Agent findingsと並ぶCIゲート」であり、「CIが人の判断に取って代わる」ではない。当サイトではEntireのCI遅延や移行コストを実測していない。
ホスティング境界：今日はプライベート、公開とセルフホストは後
読んだ発表材料では：
- Entire上でプライベートリポジトリを作成・移行・ネイティブホストできる。
- 現時点のリージョン：米国、EU、インド、オーストラリア（公式はさらなる拡大をロードマップに書く）。
- GitHubからミラーしてGitHubを真実源のままにできる、または移行できる（米国ミラーではDetach、
entire-migrateプラグイン、あるいは手元でfetch／push）。 - 公開リポジトリとセルフホストGitノードは今後／Road Ahead——ローンチ日に一般提供済みとしては扱わない。
OSSメンテナやオンプレGitノードが必要な企業にとって、今回の発表は明確にプライベートリポ優先だ。この2ページだけで公開forgeへの切替を計画しないこと。
まず試しつつソース・オブ・トゥルースは動かしたくないなら、ミラーを丁寧に読む価値がある。EntireはGitHub Appの認可、リポとリージョンの選択、GitHubを正規のままにしつつPRの上でTrailsを使う、と説明する。ブログは障害時にリージョンミラーからclone／fetchを続けられ、AgentはGitHub復帰まで entire/unmirrored/ 接頭辞のEntireネイティブブランチへプッシュできる、と書く。これはEntireの運用説明であり、当サイトが行った稼働実測ではない——だが「Trailsを試す」と「GitHubを離れる」が別決定だと分けるには足りる。
ベンダーの速度・メモリ主張
ニュースとブログは、当サイトがサイト内の実測／監査結論としては扱わない数字を二つ推している：
- プッシュ速度： GitHubより最大約 89×、Cursor Originより約 6× 速い、という開源ベンチ表付きの主張（Entire 418 pushes/sec vs GitHub 4.7、Cursor 65など）。口径はベンダー自己報告／ベンダー開源ベンチ。
- Continuous Memory： entire-graph（コードベース地図）と entire-brain（セッション記憶をグラフに結ぶ）で動く。Entireは自社テストでgraphが最大約71%のtoken削減と書く。これもベンダー主張であり、当サイトが行ったtoken監査ではない。
Continuous Memoryは製品アイデアとして理解する価値がある——セッションとプロンプトをリポジトリに同期し、Agentが新しいコンテキスト窓のたびに学び直すのを減らす——が、71%はEntire自測のラベルを外さない。2つの主ソースでもプラン料金・席料・CI秒課金の総額は未確認だ。この記事は購入・移行・GitHub離脱を推奨しない。
マージ方針を選ぶとき、Trailsをどう読むか
痛みが「AgentのPRがレビュアーの追いつく速さを超える」なら、Trailsはそのボトルネック向けだ：評価スコアを安定させ、findingsを閉じ、CIを緑にし、人手承認する。痛みが公開OSS貢献、セルフホストコンプライアンス、価格付き移行表なら、発表ページは空きを残しており——当サイトも答えを捏造しない。
Entireを採用しなくても先に回せるチェックリスト：
- 3つのマージ制御を分ける。 組織が既に求めるもの——自動レビューfindings、CI緑、名指し人手承認——と、今日どの失敗がマージを止めるかを書く。
- 「スコア」の意味を先に決める。 Agent eval（Entire上でも他でも）を入れるなら、橙色のSlopが「Agentが続けて直す」のか「人が見る」のかを決める。ゲート方針のないスコアはダッシュボードであり安全ではない。
- セキュリティレビューをスコアだけに任せない。 Security evalはトリアージとして扱い、高リスク経路・秘密・認証は人または専門レビューを残す。AIレビュー点数はコードセキュリティ保証ではない。
- ホスティングをリポ形に合わせる。 プライベート多リージョンは合い得る；公開OSSとセルフホストノードは現状まだ合わないかもしれない。
- プッシュ高速化とtoken削減スライドは、測るまでマーケ扱い。 予算に効くなら自前のプッシュ／tokenベースラインを取る。
Entireのプッシュ遅延、Continuous Memoryのtoken削減、CI移行コスト、日常のTrailレビュー品質については、当サイトではまだテストしていません。フィードバックはサイトフッターの管理人連絡先から受け付けています。