Critとは｜AIエージェントの出力へ行単位で指摘を返すレビューCLIを実測、同名OSSとの違いも整理

Critは、AIエージェントが出した計画や差分に対して「この行が違う」と指して伝えるためのGo製CLIだ。公式サイトのcrit.mdはその本体配布とレビュー共有のホスト先にあたる。単一バイナリで動き、ブラウザのレビューUIとヘッドレスのコマンドの両方を持つ。2026年9月22日時点でstar 1.1k・fork 90、ライセンスはMIT、タグは74本で最新はv0.20.2。本記事ではソースからビルドした実機で、日本語コメントの付与からレビューUIの起動、Claude Code連携の導入までを実測した。

エージェントに書かせたコードをどう扱うかという全体像はVibe Codingとは？AIコーディングの始め方・ツール比較・実践ワークフロー2026にまとめている。

Critとは——エージェントの出力に行単位で指摘を返すCLI

READMEの主張は1文で書かれている。「エージェントにとって計画もコードも同じテキストだが、人間にとって生成された計画をレビューすることと、Webアプリをレビューすることは全く別の行為だ」。だからCritは入力の種類ごとに別のUIを当てる。

・crit plan.md：markdownを整形して表示し、行コメントを付けられる
・crit：gitの変更を自動検出し、構文強調した差分を出す
・crit http://localhost:3000：起動中のアプリをプロキシし、画面の上にレビュー用の層をかぶせる
・crit landing.html：静的HTMLをレンダリングしてレビューする

チャット欄に「3つ目の段落のキューの話だけど」と書く方式と比べると、位置の伝達コストがゼロになる。コメントは対象行に紐づき、エージェントはそれをファイルから読む。

開発の勢いは数字に出ている。タグは74本あり、既定ブランチの最新コミットは2026年9月21日、そのコミットメッセージにはPR番号969が入っていた。ライセンスはLICENSEの実体ファイルを開いて MIT License / Copyright (c) 2026 Tomasz Tomczyk を確認している。作者はTomasz Tomczyk氏で、独立したオープンソースプロジェクトとして運営されている。

4つの入力に別々のUIを当てる設計

Critが扱う単位は「レビュー」で、状態はファイルに書かれる。実機で確認した構造は次のとおりだ。

レビューIDごとにディレクトリが切られ、その中の review.json が実体になる。実際に生成されたファイルのキーは branch base_ref updated_at review_round files cwd の6つで、files の下にパスごとの状態とコメント配列がぶら下がる。コメント1件は id start_line end_line body anchor author created_at updated_at を持つ。

注目したいのは anchor だ。コメントを付けた時点の行の内容が文字列として一緒に保存される。行番号だけだと後続の編集でずれるが、アンカー文字列があれば「どの記述に対する指摘だったか」が残る。ラウンドをまたいでコメントが対象に貼り付いたままになるのはこの仕組みによる。

ラウンドの概念も review_round としてファイルに入っている。エージェントがファイルを編集したあと、Critは前ラウンドとの差分を分割表示か統合表示で見せる。READMEの言い方では「未解決のスレッドは、あなたが解決と言うまで未解決のまま残る」。

4つの入力のうち、設定の手間が明確に違うのが live mode だ。crit live <url> は起動中の開発サーバをプロキシしてレビューUIをかぶせるが、Critのiframeはブラウザのタブとは別のオリジン・別ポートでアプリを読み込む。そのためホストに紐づくセッションCookieが自動では共有されない。直接URLなら動くのにCritではログイン画面が出る、という症状が起きたらこれが原因で、--cookie で1回限り渡すか、--cookie-file でNetscape形式のjarを指定するか、Chromeをリモートデバッグ有効で起動して --cdp-url http://127.0.0.1:9222 を渡す。設定ファイルに live_cookie_file と live_cdp_url として書いておくこともできる。READMEはCookieをインラインで設定に書くより、gitignoreした .crit/ 配下のファイルを使うほうを勧めている。

レビューは使い捨てではなく、あとから拾い直せる。crit resume は ~/.crit/reviews にある全レビューを新しい順に並べ、ブランチまたは対象ファイル、ディレクトリ、経過時間、未解決コメント数を出す。選ぶとそのデーモンに再接続し、止まっていればレビューが作られたディレクトリで再起動する。別の場所からでも元の文脈に戻れる作りだ。同じディレクトリとブランチで複数のセッションが該当する場合、--session を付けないコマンドは推測せずエラーで止まる。

大きな差分向けには story mode がある。差分を主題ごとの章に分け、前置きと雑多な変更の置き場を作って全体像を先に掴ませる機能だ。READMEは「これは説明役であってレビュー役ではない」と断ったうえで、生成はLLM任せなので費用は変更の複雑さ次第、複雑なPR（20〜50ファイル・2,000〜5,000行）でClaude Opus 5を使うとおおむね1〜1.40ドルという実感値まで書いている。金額の出し方として誠実な部類だ。

実測：ソースからビルドしてコメントとレビューUIまで

配布はHomebrew・Go・Nix・Windowsバイナリと揃っているが、今回はソースからビルドした。go.mod が要求するGoは1.26.0で、手元のツールチェーンは1.24.7。Goが必要なツールチェーンを自動取得してビルドは通った。

git clone https://github.com/tomasz-tomczyk/crit.git
cd crit
go build -o /tmp/crit-bin ./cmd/crit
/tmp/crit-bin --version    # crit dev

できたバイナリは26.7MB。Webアセットを同梱した単一バイナリで、--help にはshare・fetch・unpublish・install・config・check・pr・mr・pull・push・comment・comments・review・live・preview・plan・story・auth・stop・status・resume・stats・cleanupの23コマンドが並ぶ。なお --version が dev を返すのはソースビルドのためで、リリース版のバイナリではタグが入る。

次に、gitリポジトリを1つ作ってヘッドレスでコメントを付けた。日本語の本文がそのまま通るかを確かめたかったからだ。

crit comment plan.md:5 'SQSで決め打ちにする。AWS前提なので選定表は不要'
crit comment plan.md:7-9 '最大5回の根拠を書く'
crit comments

出力は次のようになった。単一行と範囲（7-9行）の両方が登録され、それぞれに対象行の内容がアンカーとして付いている。

2 unresolved comments:

[c_00d4b8] line plan.md:5
  anchor: Redis Streams / SQS / RabbitMQ から選ぶ。
  body:   SQSで決め打ちにする。AWS前提なので選定表は不要
[c_b20d65] line plan.md:7-9
  anchor: ## リトライ
  body:   最大5回の根拠を書く

crit status は、VCSがgit、ブランチがmaster、レビューファイルが /root/.crit/reviews/02101ea4250e/review.json、デーモンは未起動、ラウンド1、未解決2件・解決済み0件と表示した。ブラウザを一度も開かずにここまで完結するのは、エージェントに指摘を書かせる用途（READMEの言う programmatic comments）を想定しているからだ。

レビューUIも起動を確認した。

crit plan.md --no-open --port 8791
# Started crit daemon at http://localhost:8791 (session b10afb..., PID 3076)
crit stop

デーモンはコマンドの実行が終わっても常駐し、crit status で起動状態とセッションIDを確認でき、crit stop で明示的に止まる（実機でも Daemon stopped. を返した）。レビューの状態はプロセスではなくファイル側にあるので、止めても指摘は消えない。

curl で叩くとHTTP 200が返り、35,861バイトの <title>Crit</title> を持つページが得られた。コメント本文は初期HTMLには含まれず、/api/comments が200でJSONを返す形なので、画面はクライアント側で組み立てている。ブラウザを持たない環境でも、少なくともデーモンとAPIの疎通までは確認できる。

エージェント連携とラウンド運用——review.jsonを読ませる

crit install が対応エージェントを一覧で出す。実機の出力では aider・ampcode・claude-code・cline・codex・codex-plugin・cursor・gemini・github-copilot・grok・hermes・opencode・pi・qwen・windsurf の15種だった。READMEはこれを「ファイルを読んでコマンドを実行できるエージェントなら何でも」と表現している。

crit install claude-code
#   Installed: .claude/skills/crit/SKILL.md
#   Installed: .claude/skills/crit-cli/SKILL.md
#   Installed: .claude/skills/crit-story/SKILL.md

実行するとカレントのリポジトリに3つのスキルが書き込まれた。/crit でレビューのループを開始し、crit-cli はエージェントが必要に応じて使うCLIの説明、/crit-story がstory modeの起動にあたる。Claude Codeのプラグイン経由で入れる方法（claude plugin marketplace add tomasz-tomczyk/crit）もREADMEに載っている。Claude Code側の設定やスキルの考え方はClaude Code｜2026年版・インストールからCLAUDE.md・Hooks・本番運用までの実装手引きにまとめてある。

実験的な機能として、コメントの「Send now」を押すとその場でエージェントに投げられる送信機能もある。エージェントはコメント本文・選択されたテキスト・ファイルパス・行範囲を標準入力で受け取り、標準出力がそのままコメントへの返信として投稿される。ファイルを編集すればCritがファイル監視で検知してUIを更新する。最初のやり取りのあとスレッドは「ライブスレッド」になり、以降の返信は押さなくても自動で送られ、会話履歴つきでエージェントに渡る。

この機能の設定まわりに、設計として評価できる判断がある。エージェントを起動するコマンド agent_cmd はグローバルの ~/.crit.config.json からしか読まない。プロジェクト直下の .crit.config.json では設定できない。READMEはその理由を「悪意あるリポジトリが Send to agent の実行時に任意コマンドを走らせるのを防ぐため」と明示している。設定の読み場所を分けることで、リポジトリを開くだけで実行される経路を塞いでいるわけだ。クローンしてきたコードをレビューする道具である以上、この配慮は本質的だ。

権限の渡し方も3段階で説明されている。全権（claude --dangerously-skip-permissions -p）、選択的（--allowedTools Edit,Read,Bash,Write,Glob,Grep -p）、権限なし（claude -p・ファイルを編集できずQ&Aのみ）。信頼できるリポジトリかどうかで選べ、という整理になっている。

待ち受けの既定も安全側だ。host の既定は 127.0.0.1 で、ループバック以外を指定するには --allow-unauthenticated-network を明示する必要がある。READMEはそれより SSH や Tailscale、Dockerのホストループバック公開を推奨している。レビューデータの置き場所は output（既定 ~/.crit）で変更でき、コメントの表示名 author はVCSのユーザー名にフォールバックする。今回のヘッドレス実行では author が Claude と記録された。

運用としては、GitHubのPRやGitLabのMRとの双方向同期も用意されている。crit pr 42 でPRを開いてレビューし、crit pull で既存コメントを取り込み、crit push --event approve で結果を書き戻す。gh または glab の認証済みCLIが前提だ。GitLab側はDraft Notesを使って1つのレビューとしてまとめて公開し、request-changes に対応していないインスタンスでは黙って格下げせずエラーを返す、と明記されている。

共有機能は、レビューをアップロードしてURLで見せる仕組みだ。ここで crit.md が既定の宛先になる。share_targets に自社のデプロイ先を並べれば宛先を選べるようになり、"share_targets": [] と明示すれば共有そのものを無効化してcrit.mdを一切差し込まなくなる。社外に出せないコードを扱うなら、この設定を最初に決めておくのが安全だ。

同名OSSとの違い・ライセンス・採用判断

まず判別表を置く。GitHubで「crit」を検索すると両方出てくるので、作者名で見分けるのが確実だ。

数字も機能量も tomasz-tomczyk 版が先行しているが、「ターミナルから出たくない」なら kevindutra 版のTUIという選択もある。用途が違うだけで優劣の話ではない。

採用判断の軸は3つある。第一にレビュー対象が何か。計画のmarkdownと差分だけなら軽く使えるが、live modeでWebアプリを見るならCookieの引き回しなど設定が増える。第二に指摘を誰が書くか。人が書くならブラウザUI、エージェントに書かせるなら crit comment のヘッドレス運用が中心になる。第三に共有をどうするか。既定ではcrit.mdにアップロードされるため、扱うコードの機密性によっては最初に無効化するか自社デプロイ先を設定する必要がある。

似た方向のツールとしては、AIコーディングツールのコストをローカル集計するcodeburnとは｜41のAIコーディングツールのコストをローカル集計、対応数と通信を自分で確かめるや、コードベースの構成を図にするCodeBoardingとは｜静的解析とLLMでコードベースの構成図を自動生成する8言語対応OSSがある。いずれも「エージェントの出力を人間が把握するための道具」という点で同じ場所に効く。

まとめ——Critはどんな運用に向くか

Critが解いているのは、モデルの賢さではなく受け渡しの問題だ。エージェントが出した長い計画に対して、人間が「ここ」と指せる場所を作り、その指摘をファイルとして残し、次のラウンドまで未解決のまま保つ。実機で確かめた範囲では、日本語のコメントもそのまま通り、ブラウザを開かずにコメントの追加と一覧まで完結した。

未検証のまま残したのはブラウザUIの操作感と、live mode・story mode・共有・PR同期だ。とくに共有先の crit.md はこの環境の通信ポリシーで開けておらず、サイト側の画面は確認していない。手元で評価するなら、まず crit comment と crit comments をヘッドレスで試し、次に crit install で使っているエージェントに導入し、共有の設定を決めてからブラウザUIに進むのが手戻りの少ない順序になる。

参照ソース

・tomasz-tomczyk/crit（公式リポジトリ） — README・LICENSE・go.mod（2026-09-22時点で確認）
・kevindutra/crit（同名の別OSS） — TUI版の位置づけとstar数の確認
・tomasz-tomczyk/crit-web — crit.md にあたる共有ホストの実装