「AI エージェントが書く速度に、人間のレビューが追いつかない」——そんな悩みを抱える開発チームが増えています。Claude Code、Codex、GitHub Copilot などが生成したコードは lint と test を通過しても、意味的な重複、アーキテクチャドリフト、テストと実装の同時書き換えといった「AI slop（低品質 AI 生成コード）」の問題を静かに抱え込みがちです。PR がオープンされてから気付いても、レビュー負荷はすでに人間側に転嫁されています。
こうした課題に対して、pre-commit / husky / lefthook などの古典的な Git hook や、CodeRabbit / Qodo Merge などの PR レビュー系 SaaS ではゲートを掛ける位置が異なります。前者はコミット時点にスクリプトを実行するだけで意思決定は行わず、後者は PR がオープンされた「あと」のレビュー支援に留まります。「AI が生成したコードを、そもそも PR として立ち上げる前に検証したい」というニーズには、これらのツールでは狙いにくいのが実情です。
その隙間を埋める新しいアプローチとして登場したのが、GitHub リポジトリ kunchenguid/no-mistakes です。ローカルの Git リモートとして振る舞う「プロキシ」の位置に立ち、git push された瞬間に AI エージェントを駆動して 9 ステップの検証パイプラインを走らせ、すべてグリーンになった場合のみ本来のリモート（origin など）へ転送し、クリーンな PR を自動オープンする——これが no-mistakes の基本コンセプトです。
本記事では、no-mistakes の仕組み・エントリポイント・対応エージェント・類似 OSS / SaaS との違いを、公式ドキュメントと README をベースに整理します。動作検証は行わず、あくまでドキュメントを一次ソースとしてまとめています。自プロジェクトへの採用可否を判断するための「意思決定材料」として活用してください。
なお、本記事執筆時点（2026-07-03）のリポジトリ属性は archived=false（アーカイブされていない）、fork=false（フォークではなくオリジナルリポジトリ）、disabled=false であることを、gh api /repos/kunchenguid/no-mistakes の応答値で確認しています。メンテナンスが継続されている前提で読み進めてください。
no-mistakes とは何か
no-mistakes は、AI エージェントが生成したコードを リモートへ push する前に検証・修正するローカル git プロキシとして動作する OSS です。公式ドキュメントは https://kunchenguid.github.io/no-mistakes/ で公開されており、README の冒頭には次の一文が掲げられています。
no-mistakesputs a local git proxy in front of your real remote. Push tono-mistakesinstead oforigin, and it spins up a disposable worktree, runs an AI-driven validation pipeline, forwards the branch to the configured push target only after every check passes, and opens a clean PR automatically.
出典: README（github.com/kunchenguid/no-mistakes）
タグラインは "Kill all the slop. Raise clean PR."（AI slop を弾き、クリーンな PR だけを立ち上げる）です。「AI slop」とは lint / test は通っても意味的に低品質な AI 生成コードを指す 2026 年時点の課題語で、no-mistakes はこの問題への local gate（ローカルゲート） アプローチとして位置付けられます。
AI slop への対抗としての位置付け
古典的な Git hook（husky / lefthook / pre-commit）はユーザ定義スクリプトを実行するだけで、AI エージェントによる意思決定は伴いません。一方、CodeRabbit や Qodo Merge のような AI コードレビューツールは、PR がオープンされたあとに動作する「post-push 型」です。no-mistakes はこの両者の隙間、すなわち 「pre-push（push 直前）」かつ「AI エージェント駆動」 の位置にゲートを配置します。「PR がオープンされる時点ですでにクリーンである」ことを保証しにいくのが特徴です。
基本情報
本記事執筆時点（2026-07-03）の gh api /repos/kunchenguid/no-mistakes から取得した基本情報は次の通りです。
項目 | 値 |
|---|---|
リポジトリ | |
言語 | Go |
ライセンス | MIT |
スター数 | 5,001 |
フォーク数 | 291 |
アーカイブ状況 | archived=false（アーカイブされていない） |
フォークかどうか | fork=false（オリジナルリポジトリ） |
最終 push | 2026-07-03（記事作成日と同日 = 直近アクティブ） |
公開ドキュメント |
5,001 スターというサイズは、後述の Qodo Merge（約 11,000 スター）と比べれば小さいものの、Trending・SNS で言及される段階に達しており、archived=false かつ最終 push が記事作成日と同日という点でメンテナンス状況は健全と判断できます。
3 つのエントリポイント：Git 経由・TUI・エージェントスキル
no-mistakes は「どこから起動するか」に応じた 3 つのエントリポイントを README で明示しており、既存の Git ワークフローに段階的に組み込めるよう設計されています。
git push no-mistakes — 明示的な Git 経由
もっとも Git の作法に馴染む入り方は、ブランチをコミットしたうえで no-mistakes という Git リモートに push する経路です。
git push no-mistakes
出典: README（github.com/kunchenguid/no-mistakes）
no-mistakes は本来のリモート（origin 等）の手前に立つプロキシとして初期化されているため、この 1 コマンドで検証パイプラインが起動します。すべてのチェックが通ったあと、実際の push 先（GitHub / GitLab / Bitbucket / Azure DevOps）へブランチが転送され、PR / MR が自動オープンされます。
TUI（no-mistakes / no-mistakes -y） — 未コミット状態からのウィザード
no-mistakes コマンドを引数なしで実行すると、TUI（Terminal UI）が起動します。README によれば、未コミットの変更を含む作業ディレクトリからも起動でき、ブランチ作成・コミット・push までのステップをウィザード形式で案内します。-y を付ければ確認プロンプトをスキップした自動モードにもなります。
Git 経由よりも「AI エージェントに任せて楽をしたい」ユースケースに寄せた入口です。
エージェントスキル（/no-mistakes） — AI エージェント側から起動
もっとも新しい入口が、AI エージェント（Claude Code など）に登録される /no-mistakes スキルです。エージェントに対して /no-mistakes <task> と指示するだけで、タスク実行の後段にゲート適用まで一貫させることができます。裸の /no-mistakes を渡した場合は、既に手元にあるコミットに対してゲートだけを掛ける動作となります。
スキルは内部的に no-mistakes axi（非対話の TOON 形式インターフェース）を駆動しており、TUI と同じ承認フロー（後述）をエージェント側から扱えるよう設計されています。
検証パイプラインの 9 ステップの仕組み
no-mistakes の中核は、disposable worktree（使い捨てワークツリー） 上で走る 9 ステップの固定パイプラインです。順序自体は変更できませんが、各ステップで実行するコマンドは設定ファイルで差し替え可能という原則が公式ドキュメントで明示されています。詳細は The Gate Model を参照してください。
パイプライン全体像
README に掲載されているパイプラインの順序は次の通りです。
intent → rebase → review → test → document → lint → push → pr → ci
出典: The Gate Model（kunchenguid.github.io/no-mistakes/concepts/gate-model/）
「push」がパイプラインの中盤に置かれている点に注目してください。この時点までのゲートを通過してはじめて、本来のリモート（origin 等）へブランチが到達します。以降の pr / ci は、PR オープンと CI 監視までを同一のオーケストレーションに含めるためのステップです。
各ステップの役割
公式ドキュメントの記述を要約すると、各ステップは次のような役割を担います。
# | ステップ | 主な役割 |
|---|---|---|
1 | intent | ブランチの目的（コミット群が達成しようとしている intent）をエージェントに把握させる |
2 | rebase | ベースブランチとの差分を最小化し、不要な merge コミットを除去する |
3 | review | AI エージェントによるコード変更のレビュー（AI slop の検出） |
4 | test | 既存テストの実行と、修正に応じたテスト追加要否の判定 |
5 | document | 変更に対応するドキュメント（README / コメント等）の更新要否を判定 |
6 | lint | フォーマッタ・静的解析の実行 |
7 | push | ここまでの検証を通過したブランチを本来のリモートへ転送 |
8 | pr | PR / MR を自動オープン |
9 | ci | オープンした PR の CI 実行を監視し、失敗時は auto-fix ループに戻す |
Lint や test を最終ステップではなく中盤に置き、その後に document を挟むのは「AI がテストと実装だけを整合させて済ませる（＝仕様変更の意図がドキュメント化されない）」ケースを防ぐ設計と読み取れます。CI との棲み分けとしては、no-mistakes は「CI 監視まで含む pre-push の傘」を提供し、CI そのものを置き換えるものではないと理解するのが実態に近いでしょう。
disposable worktree による Non-blocking 実行
公式ドキュメントによれば、各 pipeline run は ~/.no-mistakes/worktrees/ 配下に作成された detached worktree で実行されます。rebase / test / 自動修正コミットの適用といった破壊的な操作はすべてこの隔離環境で行われ、run 終了後に worktree は破棄される仕組みです。
- 手元の作業ディレクトリ・インデックスには一切触れない
- run 中も別ブランチでの作業を継続できる（README でも
Non-blockingとして明記） - 失敗しても手元のリポジトリが「中途半端な rebase 状態」に陥らない
この Non-blocking 実装は、AI エージェントに数分〜数十分レベルの検証を任せるユースケースで特に効きます。CI が回っている間に別作業へ移りたい、というエンジニアの動きを止めない点は、後述の CodeRabbit / Qodo Merge との比較でも構造的な差別化点になっています。
findings の 3 分類と承認フロー
各ステップは pass するか、あるいは finding（検出事項） を返して停止します。公式ドキュメントでは finding は次の 3 分類で扱われると説明されています。
分類 | 挙動 |
|---|---|
| エージェントが自動修正を試み、設定された最大回数まで再チェックのループを回す |
| ユーザーに承認・修正・スキップ・中断のいずれかを求める |
| 情報通知のみ。ブロックしない |
出典: The Gate Model（kunchenguid.github.io/no-mistakes/concepts/gate-model/）
TUI では、ask-user に分類された finding に対して以下の 4 択が提示されます。
- approve（承認）: そのまま次のステップへ進む
- fix（修正）: エージェントに追加の修正を指示する
- skip（スキップ）: そのステップの結果を採用しないまま次へ進む
- abort（中断）: run 全体を中断する
「機械的に安全な修正は自動で、コードの意図に触れる判断はユーザーへ escalate する」という設計思想が読み取れます。README のバレットにある Human stays in charge はこの分担を指しており、「AI に丸投げして事故を起こさない」ためのブレーキとして機能します。
対応エージェントとエージェント非依存性
no-mistakes の大きな特徴のひとつが、エージェント非依存（Agent-agnostic） な設計です。README では次のエージェントが対応先として列挙されています。
claude（Anthropic Claude Code）codex（OpenAI Codex）rovodevopencodepicopilot（GitHub Copilot）acp:<target>viaacpx（Agent Client Protocol 経由の任意エージェント）
出典: README（github.com/kunchenguid/no-mistakes）
いま自チームで採用しているエージェントが将来別プロダクトに置き換わっても、no-mistakes 側の設定を差し替えるだけでパイプラインを維持できるという意味で、特定ベンダーへのロックインを避けやすい構成になっています。エンタープライズで数年単位の運用を見込む場合、この抽象化レイヤーの存在は採用判断の重要材料になります。
/no-mistakes スキルと no-mistakes axi の関係
先述のエージェントスキル /no-mistakes は、内部的に no-mistakes axi（非対話 TOON インターフェース）を呼び出します。axi は TUI と同じ承認フローを、エージェントから機械的に扱えるよう構造化したコマンドで、TUI での approve / fix / skip / abort をエージェントの応答として返せる形にマッピングしたものです。
つまり、TUI・Git 経由・エージェントスキルという 3 経路のいずれから起動しても、承認モデルは同一の抽象で表現されるということです。導入後にチームでの使い方を切り替える際、学習コストを積み増しにくい設計と言えます。
インストールと前提条件
導入手順は公式の Installation で 4 経路が案内されています。本節はいずれも公式ガイドからの引用で、動作検証は行っていません。実行前に必ず公式ドキュメントの最新版を確認してください。
導入経路
プラットフォーム | コマンド |
|---|---|
macOS / Linux |
|
Windows (PowerShell) |
|
Go install |
|
ソースビルド |
|
出典: Installation guide（kunchenguid.github.io/no-mistakes/start-here/installation/）
バイナリは ~/.no-mistakes/bin に配置されます。
前提条件
- 必須:
gitと、対応エージェントバイナリ（claude/codex/rovodev/opencode/pi/copilot/acpxのいずれか 1 つ以上） - オプション:
gh（GitHub 向け PR 自動オープン）glab（GitLab 向け MR 自動オープン）- Bitbucket API token（環境変数
NO_MISTAKES_BITBUCKET_EMAILと token） az+azure-devops拡張（Azure DevOps）
- 事前検証:
no-mistakes doctorコマンドで、エージェントとホスティングプロバイダの導入状況を機械的に確認できる
Quick Start（https://kunchenguid.github.io/no-mistakes/start-here/quick-start/）では初期化から push までの流れが次のように示されています。
$ no-mistakes init # ゲート初期化（gate remote / 内部リポジトリ / /no-mistakes skill をセットアップ）
$ git checkout my-branch
# ...作業...
$ git push no-mistakes # パイプライン開始
$ no-mistakes # TUI で run を確認・承認
出典: Quick Start（kunchenguid.github.io/no-mistakes/start-here/quick-start/）
自分がフォークにコントリビュートする形態（親リポジトリを origin に維持したい場合）では、no-mistakes init --fork-url <fork-url> オプションで push 先を明示できる点も Quick Start に記載されています。
類似 OSS / SaaS との違い
no-mistakes を評価する際、比較対象になりやすい OSS / SaaS を 3 系統に整理して差分をまとめます。
Qodo Merge（旧 PR-Agent）との違い — post-push vs pre-push
OSS の AI コードレビューエージェント Qodo Merge（旧称 PR-Agent、GitHub 上で約 11,000 スター）は、PR がオープンされたあとにリポジトリへコメントを投稿する形式でレビュー・要約・改善提案を行います。既存の GitHub / GitLab の PR フローに乗せやすく、レビュー特化として洗練されている一方、「PR が open される前に止める」という発想は含まれていません。
no-mistakes は逆に、push を pipeline で足止めし、rebase / test / doc / lint / PR オープン / CI 監視までを 1 つのオーケストレーションに詰め込みます。「AI レビュー特化 vs 包括的な pre-push オーケストレーション」という違いだと整理できます。両者は排他ではなく、no-mistakes のパイプラインが立ち上げた PR に対して Qodo Merge の追加レビューを走らせる、といった組み合わせも成立します。
CodeRabbit との違い — SaaS 中心 vs 完全ローカル git proxy
CodeRabbit は SaaS 中心の AI コードレビュープラットフォームで、IDE 拡張（Cursor / VS Code / Windsurf）と CLI から staged / unstaged コミットに対する inline review を提供します。プランに応じてサーバ側でコードを解析するモデルです。
no-mistakes は 完全ローカルの git proxy として動作し、upstream にコードを到達させる前段でゲートを掛けます。社内コードの外部送信を制限したい環境や、AI エージェント自体をセルフホストしたい環境では、この「完全ローカル」の性質が採用判断の決め手になり得ます。
古典的な Git hook フレームワークとの違い — 意思決定 vs スクリプト実行
husky / lefthook / pre-commit などの古典的 Git hook フレームワークは、ユーザ定義スクリプトを Git の hook ポイントで実行する仕組みを提供します。AI 駆動の意思決定は含まず、スクリプト実行の便利ラッパーです。
no-mistakes は同じ「push 前に止める」というカテゴリに属しつつも、AI エージェントによる findings 分類（auto-fix / ask-user / no-op） と、ユーザー承認モデル（approve / fix / skip / abort）を組み合わせた「意思決定を伴うパイプライン」を提供します。既存の hook を置き換えるものではなく、lefthook などで軽量なフォーマッタチェックを行いつつ、no-mistakes で AI 駆動の検証を担わせるという住み分けも設計上可能です。
採用判断のポイント
no-mistakes を自プロジェクトで PoC すべきかを判断する際の材料を、公式ドキュメントの記述に沿って整理します。
メンテナンス状況が健全
本記事執筆時点で 5,001 スター・フォーク 291・MIT ライセンス・最終 push が 2026-07-03（記事作成日と同日）と、直近まで活発に更新されています。archived=false / fork=false / disabled=false であり、後方互換性が破壊的に切れるリスクは相対的に低い状態です。
エージェント非依存で長期採用に耐えやすい
claude / codex / rovodev / opencode / pi / copilot / acp:<target> に対応しており、エージェント側の変更に追従しやすい設計です。数年スパンでの内製ワークフロー標準化を検討している場合、この抽象化レイヤーの価値は大きくなります。
パイプラインが固定 = 予測可能性が高い
intent → rebase → review → test → document → lint → push → pr → ci の 9 ステップ順序は変更できません。順序を自由に組み替えられる CI と比べると裁量は狭いですが、その分「毎回同じ順序でゲートが掛かる」ため、レビューの再現性が高まります。CI との棲み分けをはっきりさせておくと運用が安定します。
PoC 時の注意点
公式ガイドは、初期化前に no-mistakes doctor を実行してエージェント・ホスティングプロバイダの準備状況を確認するよう推奨しています。フォークへの貢献を想定する場合は no-mistakes init --fork-url <fork-url> を用いて親リポジトリを origin に維持できます。ライセンスや情報管理ポリシー上、AI エージェントに送るデータを制御する必要がある場合、対応エージェントのうち自チームで許容できるものが 1 つ以上あることを最初に確認してください。
導入是非は各チームのワークフローと AI 活用方針に依存するため、本記事では「判断材料」を提示するにとどめます。少なくとも「PR がオープンされる前段」を強化したいというペインを持つチームにとって、no-mistakes は現時点で選択肢として比較検討する価値のあるカテゴリの OSS だと言えます。
まとめ
no-mistakes は、AI 生成コードのレビュー負荷が増えるなかで、push 前のローカルゲートという新しい位置にオーケストレーションを立てる OSS です。既存の pre-commit hook や PR レビュー SaaS では埋めにくかった、「PR がオープンされる時点ですでにクリーンである」という状態を目指す設計になっています。
要点をあらためて整理すると、次の 4 点が意思決定材料になります。
git push no-mistakes/ TUI / エージェントスキル（/no-mistakes）の 3 経路で既存ワークフローに組み込めるintent → rebase → review → test → document → lint → push → pr → ciの 9 ステップは disposable worktree で走り、手元の作業を止めない- finding は
auto-fix/ask-user/no-opに分類され、意思決定はユーザーに残る（Human stays in charge） - エージェント非依存の設計により、特定ベンダーへのロックインを避けやすい
自プロジェクトでの PoC 判断や具体的な導入手順については、公式ドキュメントの Introduction と Quick Start を続けて確認するのがスムーズです。設計思想の背景まで踏み込みたい場合は The Gate Model を参照してください。
