門守KADOMORI

Pre-PR Evidence CLI

AI が書いた変更を、
人間が承認責任を負える
Pull Request に。

Kadomori（門守）は、PR 作成前に「機械で確認できたこと」「人間が判断すべきこと」「レビュアーに明示すべきこと」を整理し、確認証跡として残す CLI です。解析はローカルで完結し、デフォルトで外部にコードを送りません。マージに人間の承認が必要なチームのための、門番のような道具です。

導入手順を見る 仕組みを見る

実際の PR（35ファイル / +1174 / −201）に対して init → check → explain → split-plan → pr create --dry-run を実行した実録デモです。下の実物サンプルと同じ PR を使っています。

実際の PR に対する report.md / handoff.md の実物サンプルを見る →

壱 ── コンセプト

コードを書く速さは AI が変えた。
承認する責任は、人間に残ったまま。

大量の書類が積まれた皿と、一人の読み手が乗った皿が釣り合わない天秤の墨絵
AI は PR を大量に生む。確認の重さは、人間の側に積み上がる。

AI コーディングツールは、PR を速く・大量に生成できるようになりました。一方で、承認とレビューの責任は、組織構造・コンプライアンス・賠償責任の観点から、依然として人間にあります。

この非対称は、AI モデルがどれだけ進化しても消えません。「人間が確認した」という社会的・法的要件が残る限り、AI の普及率に正比例して人間側の確認負担は拡大します。

Kadomori は、この構造的な負担を Pre-PR レイヤーで吸収する装置です。PR を出す前に、確認すべき点を抜け漏れなく整理し、人間が承認責任を負うための確認証跡と handoff として出力します。

Kadomori がやらないこと

  • コードレビューの代替
  • マージ可否・セキュリティ安全性の断定
  • 著者やレビュアーに代わる「確認済み」の表明
  • コードの自動修正・自動 commit・自動 push
  • PR への自動コメント・PR の自動分割

Kadomori はレビューの総量を増やす道具ではありません。人間レビューが必要そうな場所・必要性レベル・理由の候補を提示し、既存のレビュー体制に渡す材料を減らさずに整理します。

弐 ── 何が違うのか

“Asking an AI not to screw up isn’t verifiable.”

── AI に「ミスをするな」と頼んでも、それが守られたかは検証できない。

「プロンプトで注意させれば十分では?」「PR 後の AI レビューツールと何が違う?」──よくいただく二つの問いに答えます。鍵は、検証可能性とレイヤーの違いです。

プロンプトで頼むのとの違い確認が検証できる形かどうか

コーディングエージェントや、訓練したレビューエージェントに「ミスをするな」と指示することはできます。ただし、個々の変更でその指示が守られたかを確認する手段がありません。

Kadomori はデフォルトでルールベースかつ決定論的。同じ diff には毎回同じ出力を返し、小〜中規模の diff なら 1 秒未満、すべてローカルで完結します。ポリシーは個人のプロンプトの中ではなく kadomori.toml にあり、バージョン管理してチームで共有・レビューできます。

「Kadomori のほうが正確」という主張ではありません。主張するのは、何を確認したかが検証できる形で残る、という一点だけです。

post-PR AI レビュアーとの関係レイヤーが違うので、積み重なる

CodeRabbit・GitHub Copilot Code Review・Cursor Bugbot・Greptile などは、PR 作成後の diff をレビューしてレビュアー側を助けるツールです。Kadomori は PR が存在する前に、著者側で論点と証跡を整えます。

競合ではなく、積み重なるレイヤーです。post-PR レビューツールを使っているチームは、その手前に Kadomori をそのまま置けます。

参 ── 誰が、どう楽になるのか

著者・レビュアー・組織。
三者の「確認の重さ」をそれぞれ軽くする。

Kadomori の採用主体は、人間の承認プロセスを必須とする開発組織です。その中で日々 PR を書き、読み、責任を負う三者の負担に効きます。

AUTHOR

PR 著者

いままで
自分が完全には書いていないコードを自分の言葉で説明するコスト。見落としの恐怖。公開 PR で指摘されるダメージ。
Kadomori 後
PR 前に kadomori check が AI slop 候補・目的外変更・PR 粒度を列挙。handoff が「著者が責任を持って確認すること」を Author Checklist として提示し、説明の材料が先に揃う。

REVIEWER

レビュアー・テックリード・EM

いままで
AI 生成 PR を読み解くコスト。何をどこまで見るべきかの判断負荷。大きすぎる PR、混ざった変更。
Kadomori 後
Review Map が変更を machine-verified / context-needed / human-required に分類。「人間の目が要る場所と理由の候補」「判断してほしい論点」が PR と一緒に届く。

ORGANIZATION

組織

いままで
AI 生成コードに対するガバナンスと監査証跡の不在。「誰が何を確認したのか」が残らない。
Kadomori 後
report.json と Run History に「PR 前に何を確認したか」が事実として蓄積。Evidence Report で期間集計を CSV / JSON 出力。コードを外部 LLM に直接送信しない ACP 限定設計。

肆 ── 仕組み

PR を出す前に、
変更を一度チェックに通すだけ。

Review Map — 確認負担を三色に分類する

変更されたファイルを「人間の確認がどれだけ要るか」で分類し、レビューの視線を集中させます。

human-required
人間の判断が必要。セキュリティ・課金・DB スキーマなど、承認責任者が理由付きで確認すべき変更。
context-needed
背景確認が必要。コードだけでは判断できず、仕様や経緯の突き合わせが要る変更。
machine-verified
機械的に確認しやすい。人間が深追いしなくてよい変更を明示し、視線を節約する。

解析モード — 何を根拠に候補を出したかを常に明示

レポート先頭に解析モードを表示します。どのシグナル層で候補が出たかを誤読させないためのメタ情報であり、レビュー完了や安全性を示すものではありません。三層は累積的に働きます。

層内容
Default rulesLLM なし / 1 秒未満 API key なしで動く低ノイズな入口。組み込みの path / diff ルールのみで候補を提示。
Team policyLLM なし / 1 秒未満 kadomori.toml の責任ルールや、CODEOWNERS・PR template・framework convention から取り込んだ policy seed による、チーム固有の責任境界。
ACP LLM任意 / 数十秒 Kadomori 独自の LLM API ではなく、審査済みのユーザー管理エージェント（Cursor CLI、Claude Code など）を ACP 経由で利用。失敗時は rule / policy 層へ自動フォールバック。

Responsibility Handoff — 責任の受け渡しを、文書にする

handoff.md は PR description の完成文ではありません。PR を出す前に著者が責任を持って確認し、レビュアーと責任者へ引き継ぐための確認メモです。

「著者が PR 前に確認すること」は常に未チェックの Author Checklist として出力されます。チェックを入れるのは道具ではなく、責任を負う人間です。

  • .kadomori/report.md人間が読む詳細レポート実物を見る →
  • .kadomori/report.json監査・機械処理用の事実データ
  • .kadomori/handoff.md著者→レビュアー→責任者への引き継ぎ文書実物を見る →

サンプルは架空の例ではなく、Kadomori 開発リポジトリの実際の PR に対して kadomori check が生成した出力です。

朱印の押された文書を一方の手からもう一方の手へ渡す墨絵
確認した事実に印を残し、次の責任者へ渡す。

伍 ── 安心設計

解析はローカルで完結。
コードを外部の LLM に送らない。

Kadomori は組織のセキュリティ審査を前提に設計されています。「コードはどこに送られるのか」への答えは、デフォルトでは「どこにも送られない」です。

デフォルトで外部通信なし

API key 不要。組み込みルールだけで完全動作し、解析はすべて手元のマシンで完結します。ネットワークが遮断された環境でも kadomori check は動きます。

LLM は任意、審査済みエージェント経由のみ

Kadomori 自身は LLM API を持ちません。AI 補助を使う場合も、組織が既に審査したエージェント（ACP）経由に限定。失敗時はルールベースへ自動フォールバックします。

証跡はすべて手元に残る

レポートも実行履歴も、リポジトリ内の .kadomori/ に書かれるだけ。GitHub 操作は gh CLI 経由で token を保持せず、診断ログにも secret 値を出力しません。

陸 ── 導入手順

バイナリひとつ。
Rust ツールチェーンも API key も不要。

前提は三つだけ。対象が Git repository であること、base branch（例: main）に対して commit 済みの差分があること、そして kadomori pr create まで使う場合は GitHub CLI（gh）が認証済みであること。

1INSTALL

インストール

公開 Releases からインストーラを実行します。OS / アーキテクチャに合うバイナリと .sha256 を取得し、チェックサム検証後に配置します。

curl -fsSL https://github.com/kinopeee/kadomori-releases/releases/latest/download/install.sh | sh
Invoke-WebRequest -Uri https://github.com/kinopeee/kadomori-releases/releases/latest/download/install.ps1 -OutFile "$env:TEMP\kadomori-install.ps1"
powershell -ExecutionPolicy Bypass -File "$env:TEMP\kadomori-install.ps1"
Remove-Item "$env:TEMP\kadomori-install.ps1" -Force

企業向けに、インストーラ自体のチェックサムを検証してから実行する手順も用意しています（README「installer 自体も検証する」参照）。

2INIT

プロジェクトで初期化し、環境を診断する

init --auto-seed は CODEOWNERS や framework convention を自動検出し、リポジトリ固有の seed ルールを取り込みます。doctor は Git・base branch・gh 認証などを read-only で確認します。

cd your-project
kadomori init --auto-seed
kadomori doctor
3CHECK

PR を出す前に、変更を門に通す

LLM なしで動作し、レポートと handoff を生成します。小〜中規模の diff なら 1 秒未満で完了します。

# goal（PR の目的）を明示して解析。目的外変更の検出に使われる
kadomori check --goal "ログイン画面のバリデーション修正" --no-llm

# branch 名と commit からの推定も可能
kadomori check --infer-goal --no-llm

Cursor / Claude Code / Codex / Devin などのエージェントからは、同梱の agent skill（/kadomori-check）で同じチェックを呼び出せます。

4HANDOFF

確認証跡を引き継ぎ、Draft PR を作る

handoff を確認し、Author Checklist に自分の手でチェックを入れてから、gh CLI 経由で Draft PR を作成します。

kadomori evidence handoff --goal "ログイン画面のバリデーション修正" --no-llm
kadomori pr create --draft --title "fix: ログインバリデーション修正"

Kadomori は blocking しません。hook / skill / CI と組み合わせても、push や PR 作成を止めない設計です。git pre-push・Cursor hook・GitHub Actions のテンプレートを同梱しています。

門を立てるのは、一行のコマンドから。

まずは手元のブランチで kadomori check --no-llm。API key なし、外部送信なしで、次の PR の確認証跡が残ります。