Goose reviewを試したら、チェック定義ファイルまで診断対象に入っていた

はじめに

対象読者は、AIエージェントCLI「Goose」でローカルコードレビューを自動化したいエンジニア向けです。

Pull Requestのレビュー待ちで手が止まる時間を減らしたくて、Block社が開発し現在はLinux Foundation傘下のAgentic AI Foundation（AAIF）が管理するAIエージェントCLI「Goose」に搭載された goose review コマンドを試しました。ローカルの差分をAIに投げてレビューさせるだけのコマンドだと思っていたら、カスタムチェックの仕組みを試している途中で、意図していないファイルまでレビュー対象に含まれる挙動に気づきました。

TL;DR

• goose review はワーキングツリーの差分（または指定した差分範囲）をAIエージェントに渡し、バグ・セキュリティ・パフォーマンス・スタイルの4観点でレビューさせるコマンドです
• .agents/checks/*.md に独自のレビュー観点（チェック）を配置すると、goose review がそれを自動発見して並列実行します
• チェック定義ファイルの name フロントマターはファイル名と厳密一致していないとエラーになります（実際に検証済み）
• チェック定義ファイル自体が git status 上は未追跡の新規ファイルのため、そのままレビュー対象の差分に含まれてしまいます
• OpenAI の gpt-5-mini で実際にレビューを実行したところ、埋め込んだバグ（+ を - に書き換えたコード）を high severityで正しく検出しました

Gooseとは

Gooseは、Linux Foundation傘下のAgentic AI Foundation（AAIF）が管理するオープンソースのAIエージェントCLIです。Rustで実装されており、GitHub上で52.6kスター・6.0kフォークを獲得しています（2026年8月時点、公式リポジトリで確認）。ライセンスはApache 2.0です。

goose review は2026年6月にリリースされたv1.37.0で追加された機能で、リリースノートによると、モデル切り替え用の /model コマンドやエージェント自己評価用の /goal コマンドと同時に投入されました。今回の検証で実際にインストールしたバージョンは1.45.0で、goose review サブコマンドはこの間に機能拡張が続いています。

インストールと基本動作の確認

公式のインストールスクリプトでLinux環境にセットアップしました。

curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh -o goose-install.sh
CONFIGURE=false GOOSE_BIN_DIR=/tmp/goose-bin bash goose-install.sh

CONFIGURE=false を付けているのは、インストール直後に走る対話式のプロバイダー設定（goose configure）をスキップするためです。インストール後にバージョンとサブコマンド一覧を確認します。

$ /tmp/goose-bin/goose --version
1.45.0

$ /tmp/goose-bin/goose --help
...
  review        Review the current diff using goose
...

goose review --help を見ると、レビュー範囲の指定・モデル指定・チェックのフィルタリングなど、CI組み込みを意識したオプションが揃っています。

Usage: goose review [OPTIONS] [RANGE]

Arguments:
  [RANGE]  Diff range to review (e.g. "main...HEAD"). Defaults to the working tree vs HEAD

Options:
      --model <MODEL>            Default model used for the main review agent
      --dry-run                  Print the assembled review prompt and discovered checks instead of running the review
  -c, --check-filter <NAME>...   Only run checks whose `name` matches one of these
      --severity <LEVEL>         Minimum severity to display [default: medium]

--dry-run でプロンプトの中身を確認する

APIキーを消費せずに動作を確認できる --dry-run から試しました。検証用に小さなGitリポジトリを作り、意図的なバグを埋め込んだ差分を用意します。

mkdir goose-test && cd goose-test && git init -q
git config user.email [e-mail] && git config user.name test
echo "function add(a, b) { return a + b }" > sample.js
git add sample.js && git commit -q -m "init"
echo "function add(a, b) { return a - b }  // bug: should be +" > sample.js

goose review --dry-run

出力の冒頭には goose review: no checks or REVIEW.md rules discovered と表示され、続けてレビュー用のシステムプロンプトが丸ごと出力されました。プロンプトには「サイレントエラーパス」「境界値エラー」「並行処理のハザード」「リソースのライフサイクル」など、レビュー観点がかなり具体的に列挙されています。単純な「バグを探して」ではなく、チェックリスト形式でモデルに渡している設計です。

カスタムチェックを配置してみる

goose review の特徴は、.agents/checks/*.md に独自のレビュー観点を配置すると自動的に発見して並列実行してくれる点です。試しにセキュリティ観点のチェックを追加しました。

mkdir -p .agents/checks
cat > .agents/checks/security.md << 'EOF'
---
name: security-check
model: gpt-4
---
Look for security issues such as hardcoded secrets, SQL injection, or unsafe eval usage.
EOF

goose review --dry-run

ここで最初のエラーに遭遇しました。

Error: check /tmp/goose-test/.agents/checks/security.md: name 'security-check' must match filename 'security'

フロントマターの name: security-check とファイル名 security.md が一致していないため弾かれています。ファイル名を security-check.md にリネームすると通りました。

mv .agents/checks/security.md .agents/checks/security-check.md
goose review --dry-run

発見: チェック定義ファイル自体が診断対象に入る

リネーム後の --dry-run 出力を確認していて気づいたのが、組み立てられた差分（diff）に sample.js だけでなく .agents/checks/security-check.md 自体も含まれていたことです。

diff --git a/sample.js b/sample.js
index 78f6787..f6e4899 100644
--- a/sample.js
+++ b/sample.js
@@ -1 +1 @@
-function add(a, b) { return a + b }
+function add(a, b) { return a - b }  // bug: should be +
diff --git a/.agents/checks/security-check.md b/.agents/checks/security-check.md
new file mode 100644
--- /dev/null
+++ b/.agents/checks/security-check.md
@@ -0,0 +1,5 @@
+---
+name: security-check
+model: gpt-4
+---
+Look for security issues such as hardcoded secrets, SQL injection, or unsafe eval usage.

goose review はデフォルトで「ワーキングツリー vs HEAD」の差分をレビュー対象にします。チェック定義ファイルはGit管理下に置いたばかりの未追跡ファイルなので、この差分に自然に含まれてしまう、という理屈です。実際にレビューを実行すると、.agents/checks/security-check.md 自体に対しても指摘が生成されました（後述）。

CIパイプラインに組み込む場合、.agents/checks/ を先にコミットしておかない構成だと、レビュー対象PRの差分に「チェック定義ファイルの新規追加」というノイズが混ざる可能性があります。-f, --files <FILE>... オプションでレビュー対象を絞り込めるので、CI組み込み時はこのオプションで明示的にソースコードのパスだけを指定するのが安全そうです。

実際にレビューを実行する

検証環境に OPENAI_API_KEY が設定されていたため、gpt-5-mini を指定して実際にレビューを走らせました。

goose review --provider openai --model gpt-5-mini

goose review: discovered 1 check(s):
  - security-check (scope: <root>)
goose review: check 'security-check' completed: 0 finding(s)
goose review: main pass on 'sample.js' completed: 1 finding(s)
goose review: main pass on '.agents/checks/security-check.md' completed: 3 finding(s)
{"severity":"high","path":"sample.js","line_start":1,"line_end":1,"summary":"The add function was changed to return a - b (subtraction) instead of performing addition, so callers expecting a sum will receive incorrect results. Fix by replacing '-' with '+' (e.g. `return a + b;`). Add unit tests for add() to catch regressions and consider validating input types if needed.","check":"main"}
{"severity":"medium","path":".agents/checks/security-check.md","line_start":3,"line_end":3,"summary":"The file hardcodes a specific model name (`model: gpt-4`) which couples this check to a particular model availability and billing tier. In environments without access to that model (CI runners, forks, community contributors) this will fail or be unusable. Make the model configurable (e.g. read from environment or a global config) or omit the model field so the runner can select an appropriate default.","check":"main"}
goose review: orchestrator emitted 2 finding(s) from 1 check(s) (main: ran, 4 finding(s); 2 hidden below severity=Medium)

意図的に埋め込んだ a - b のバグは severity: "high" で正確に検出されました。加えて、チェック定義ファイル自体に対しても「model: gpt-4 をハードコードするとCIランナーやフォーク先で使えなくなる」という、これはこれで的を射た指摘が返ってきています。severityが medium 以下の指摘は既定で非表示（--severity medium がデフォルト）になっているため、出力全体を見るには --severity low を付ける必要があります。

処理の流れ

--dry-run の出力とログを突き合わせると、goose review の処理は次のような流れになっています。

--no-orchestrate を付けると、この並列サブプロセス方式ではなく単一プロンプト内でモデルに delegate を呼ばせる旧方式にフォールバックする、とヘルプに記載があります。今回はデフォルトのオーケストレーター方式のみ検証しました。

著者視点の一次所見

実際に手を動かして一番印象的だったのは、name バリデーションのエラーメッセージが具体的だったことと、その後に踏んだ「チェック定義ファイルが差分に混入する」という挙動の組み合わせです。エラーメッセージだけを読んで「ファイル名を直せば通る」と対応すると、直した瞬間にそのファイル自体がレビュー対象になるという副作用に気づきにくい構造になっています。CIに組み込む前に、必ず一度ローカルの git status と --dry-run の差分表示を見比べておくべきだと感じました。

また、severityのデフォルトが medium 以上のみ表示という設計は、Amp CLIの review --instructions 等と互換性を持たせる意図（ヘルプに "Mirrors amp review --instructions" と明記）があり、既存のレビューツールのラッパーからの移行を意識した設計であることがうかがえます。

おわりに

goose review は、チェック定義をMarkdownで書いて並列実行できる設計自体はシンプルで扱いやすい一方、ワーキングツリーの差分をそのままレビュー対象にするデフォルト挙動には注意が必要でした。CIに組み込む際は -f, --files でレビュー対象を明示的に絞り込み、チェック定義ファイルは事前にコミットしておくか .gitignore に触れないパスへ切り出すのが安全です。

• 公式リポジトリ: https://github.com/aaif-goose/goose
• v1.37.0 リリースノート: https://github.com/aaif-goose/goose/releases/tag/v1.37.0

関連記事

• LlamaIndex Workflowsで並行実行、実測すると本当に半分の時間だった
• gooseに繋いだ自前モデル、1Mコンテキストが128kに切り詰められた話
• Pydantic AI V2を動かしたら、V1との破壊的変更はこの4つだけだった