aif-review

コードレビューアシスタント

正確性、セキュリティ、パフォーマンス、保守性に重点を置き、徹底的なコードレビューを行います。

ステップ 0：設定の読み込み

最初に： .ai-factory/config.yaml が存在する場合は読み込み、以下を確認します。

• パス： paths.description、paths.architecture、paths.rules_file、paths.roadmap、paths.rules
• 言語： レビューの概要に使用する言語を language.ui で確認
• Git： ブランチ比較の指針として git.base_branch を確認

config.yaml が存在しない場合は、既定値を使用します。

• パス：すべての成果物に .ai-factory/ を使用
• 言語：en（英語）
• Git：base_branch: main

動作

引数フラグ

引数文字列を以下のモードのいずれかに振り分ける前に、任意の動作を指定する独立したトークンを抽出します。引数文字列から取り除き、残りを通常どおり振り分けます。

• +check — レビューの作成後に、任意の検出結果バリデーターを実行します。実行タイミング、失敗時の動作、出力への追加、ゲート結果の再計算を含む全手順は references/CHECK-MODE.md に記載されています。このトークンがある場合、またはレビューで信頼度マーカーが 1 つ以上検出された場合にバリデーターを実行します。詳しくは、以下の「ゲート実行前のマーカー解決」を参照してください。マーカーのないレビューでは、このフラグだけが実行のトリガーとなるため、指定されない限り実行されません。このトークンはメインの引数の前後どちらにも指定できます（例：/aif-review +check、/aif-review 123 +check、/aif-review main +check）。

残りの引数文字列が空の場合は、引数なしモード（ステージ済みのレビュー）に切り替えます。不明な + で始まるトークンは、黙って消費されないよう、メインの引数の一部としてそのまま渡します。

エッジケース：+check という名前の Git 参照はフラグの抽出時に消費されます。これは許容できる妥協です。

引数なしの場合（ステージ済みの変更をレビュー）

1. git diff --cached を実行して、ステージ済みの変更を取得します
2. ステージ済みの変更がない場合は、git diff を実行して、未ステージの変更を取得します
3. 各ファイルの変更を分析します

PR 番号／URL を指定した場合

1. gh pr view <number> --json を使用して、PR の詳細を取得します
2. gh pr diff <number> を使用して、差分を取得します
3. PR のすべての変更をレビューします

Git 参照を指定した場合（コミットモード）

引数の振り分け順：

1. 空 → ステージ済みのレビュー（上記を参照）
2. 数字または #N → PR モード（上記を参照）
3. その他すべて → git rev-parse --verify で検証 → コミットモード、またはユーザーに確認

検証：

git rev-parse --verify <argument> 2>/dev/null

• 有効な参照 → 以下の手順でコミットモードに進みます

• 無効な参照 → ステージ済みのレビューに黙って切り替えないでください。ユーザーに確認します。

  AskUserQuestion: `<argument>` is not a valid git ref. What did you mean?
  
  Options:
  1. Review staged changes instead
  2. Cancel
  

  選択に応じて：

  • 「ステージ済みの変更をレビュー」→ ステージ済みのレビューを実行します（既定のモード）
  • 「キャンセル」→ レビューがキャンセルされたことをユーザーに伝え、停止します
  • 「その他」→ ユーザーが修正した参照を指定し、rev-parse で再検証します

エッジケース：名前が数字だけのブランチ（例：123）は PR 番号として解釈されます。これは許容できる妥協です。

手順：

1. 参照と HEAD の間のコミット一覧を取得します。

   git log --oneline --reverse <ref>..HEAD
   

   コミットが見つからない場合（HEAD が <ref> と同じか、それより前の場合）は、ユーザーに伝えて停止します。

2. コミット数を確認します： 20 件を超える場合は、続行する前にユーザーに確認します。

   AskUserQuestion: Found <N> commits to review. Reviewing all of them will be slow and consume significant context. How to proceed?
   
   Options:
   1. Review all <N> commits
   2. Review only the last 20
   3. Cancel
   

   選択に応じて：

   • 「すべてレビュー」→ コミット一覧全体を使って続行します
   • 「直近の 20 件のみレビュー」→ コミット一覧を直近の 20 件に絞り込みます（時系列順を維持）
   • 「キャンセル」→ レビューがキャンセルされたことをユーザーに伝え、停止します

3. 各コミットをレビューします：

   git show <commit-hash> --stat
   git show <commit-hash>
   

   各コミットについて、以下を確認します。

   • コミットメッセージは実際の変更内容と一致していますか？
   • 変更はアトミックですか（コミットごとに 1 つの論理的な単位になっていますか）？
   • このコミットで新たに発生した問題はありますか？

4. コミットごとの注記を含めた概要を提示します

コンテキストゲート（読み取り専用）

レビュー結果を確定する前に、読み取り専用のコンテキストゲートを実行します。

• 解決済みのアーキテクチャ成果物（存在する場合）を確認し、境界や依存関係の整合性に問題がないか確認します。
• 解決済みの RULES.md 成果物（存在する場合）を確認し、明示された規約への違反がないか確認します。
• 解決済みのロードマップ成果物（存在する場合）を確認し、マイルストーンとの整合性を確認します。また、feat／fix／perf に該当する可能性が高い作業について、関連付けが不足していれば指摘します。

人によるゲート結果の重大度：

• WARN は、ブロック要因ではない不整合や任意ファイルの欠落に使用します。
• ERROR は、ユーザーまたはレビューポリシーが求める明示的なブロック条件にのみ使用します。

ユーザーがルールのみの単独チェックを希望する場合は、/aif-rules-check を提案してください。人による /aif-review のゲートラベルには WARN／ERROR を使用し、その後に pass|warn|fail のステータスを含む標準の機械可読ゲート結果を追加します。

機械可読ゲート結果

このセクションが aif-gate-result の計算を一元管理します。

• 人が読めるレビューの後に、最終的な aif-gate-result JSON ブロックを1つだけフェンス付きで追加します。
• "gate": "review" を使用します。
• "status": "pass|warn|fail" — 独立した2つの入力のうち、より重大な方（fail > warn > pass）を設定します。
  • 指摘事項の入力 — 「Critical Issues」の項目が1つでも残っている場合は fail（重大な正確性、セキュリティ、データ損失、パフォーマンス、下流へのリグレッション — 重大／提案の正式な定義については references/SEVERITY.md を参照）。「Suggestions」、不足している任意のコンテキスト、またはレビュー上の不確実性だけが残っている場合は warn、重要な問題が何も残っていない場合は pass。
  • コンテキストゲートの入力 — ゲートの指摘がブロッキング（ERROR）の場合は fail、非ブロッキング（WARN）の場合は warn、指摘がない場合は pass。
  • コンテキストゲートが失敗した場合、「Critical Issues」が0件でも "status" は fail のままです。問題のない指摘事項リストでゲートの失敗を覆い隠してはなりません。
• 未解決のマーカーをゲートに渡してはなりません。 投影では、マーカーのない指摘事項を想定しています。(confidence: low) / (confidence: medium) マーカーは、ゲートの計算前に検証パスで解決します。詳しくは以下の「ゲート前のマーカー解決」を参照してください。スキーマ v1 には「未検証の潜在的ブロッカー」を表す方法がなく、ゲートがその状態を表現することもありません（warn + command: null は状態ではなく、バグです）。
• 未解決のマーカーは検証失敗であり、ゲートはその失敗自体を報告します。 ゲートの計算時にマーカー付きの指摘事項にマーカーが残っている場合、検証パスがディスパッチされたものの解決に至らなかったことを意味します。項目ごとの契約違反、項目ごとの応答形式の不備、またはディスパッチ全体の失敗です（references/CHECK-MODE.md の Failure modes を参照）。レビューは完了していません。応答がマーカーの付与を試みたために却下された指摘事項についても同様です。その項目は元のマーカーなしの形式で公開されるため、ゲートはテキストから失敗を検知できず、その失敗を別途通知する必要があります。いずれの場合も、ブロックは WARN [+check] の行だけでなく、機械可読フィールドにも失敗を示します。
  • "status": "fail"、"blocking": true を設定します。
  • "blockers" に、確立済みのブロッカー（以下を参照）に加えて、合成エントリ {"id": "review-validation-failed", "severity": "error", "summary": "<N> finding(s) left unvalidated: <cause>"} を1つだけ追加します。<cause> は WARN [+check] の行から取得します。すべての失敗経路でこの行が出力されるため、原因が空の失敗は WARN を省略した経路があることを示すバグであり、公開できるゲートではありません。
  • マーカーが残っている指摘事項は、人が読めるセクションにマーカー付きのまま残しますが、確立済みのブロッカーではなく、"blockers" にも記載しません。ゲートは、それらが実際の問題かどうかを推測しません。元のマーカーなしの形式で公開された指摘事項は通常の確立済み指摘事項として通常どおり投影され、検証の失敗を記録するのは合成エントリだけです。
  • "suggested_next.command" は null とし、その理由には失敗と復旧方法を記載します。復旧方法は /aif-review +check の再実行です。このコマンドは許可リストにないため、正直な値は null だけです。ブロックはすでに fail + blocking なので、オーケストレーターが null を「解消済み」と解釈することはありません。
• "blocking": true|false — "status" が fail の場合に限り true にします。
• "blockers" — 確立済みのマージブロッキング指摘事項のみを記載します。マーカーのないすべての「Critical Issues」項目（検証パスが成功した場合、すべての項目が該当）、ブロッキングのコンテキストゲート指摘事項、および検証失敗時の review-validation-failed エントリのみを含め、それ以外は含めません。
• "affected_files" — レビュー対象または関連するパスを記載します。
• "suggested_next.command" は "status" に従います。fail → デフォルトは /aif-fix ですが、すべてのブロッカーが単一のコンテキストゲートに由来する場合は、そのゲートのコマンドを指定します（rules gate → /aif-rules、architecture gate → /aif-architecture、roadmap gate → /aif-roadmap）。warn/pass → /aif-commit。review-validation-failed ブロッカーが存在する場合は、他のブロッカーにかかわらずコマンドを null にします。不完全なブロッカーリストに対する修正パスでは、レビューが完了していないレポートを使うことになるためです。null は従来どおり、許可リストに適合するコマンドがないことを意味し、未解決の指摘事項を表すためには使用しません。

ゲート前のマーカーの解決

少なくとも 1 つの (confidence: low) / (confidence: medium) マーカーを生成したレビューは、フラグが指定されていなくても +check 検証を自動的に実行します。フラグはそれ以外のすべてに対してオプトインのままです。マーカーのないレビューはこれまでとまったく同じように動作し、何もディスパッチしません。

自動ディスパッチは、入力への信頼ではなく、ケイパビリティによって制限されます。このパスは、ランタイムがそのエージェントの読み取り専用ツール許可リスト（Read、Glob、Grep — Claude Code）を強制する場合にのみ review-validator として実行されます。そのプロンプトは diff をそのまま埋め込んでおり、PR の diff は信頼できないコンテンツだからです。フラグなしの実行は、レビュー対象の変更が到達できるツールセットを決して広げてはなりません。そのエージェントが利用できない場合、またはそのランタイムが許可リストを強制できない場合（Codex エージェントは読み取り専用サンドボックスを取得しますがツール許可リストはなく、親の MCP サーバーを継承します）、自動実行はまったくディスパッチしません。ディスパッチ全体の失敗と、その結果として生じる review-validation-failed ゲートを報告します。より弱い境界で実行できるのは明示的な +check のみであり、そのことは WARN 行で示されます（references/CHECK-MODE.md、手順ステップ 4）。

• マークされたすべての検出事項は、confirmed（バリデータがマーカーなしで返し、そのセクションの通常の検出事項としてカウントされる。confirmed の critical はブロッカーであり fail を駆動します）か、refuted で破棄されるかのいずれかです。
• その後、ゲートは検証後の検出事項から計算されるため、公開されるブロックにマーカーが含まれることはなく、状態スキーマ v1 が表現できない状態を必要とすることもありません。
• このパスがマーカーを未解決のままにした場合、ゲートはレビューが獲得していない判定を公開する代わりに、検証失敗（review-validation-failed、上記の「機械可読なゲート結果」）を報告します。マーカーは人間が読めるセクションに表示されたままになり、WARN [+check] 行が原因を示します。
• ディスパッチのコストが支払われるのは、そうしなければその表現できない状態を生み出す実行だけです。カバレッジ優先は不確実な検出事項を抑制するのではなく意図的に表面化させるため、そのような実行は十分に一般的であり、解決をユーザーに委ねるとそのすべてでパイプラインが停滞してしまいます。

手順、カウンター、失敗時の処理は明示的な +check と同一です（references/CHECK-MODE.md）。唯一の違いは、何がそれをトリガーしたかです。

/aif-review はデフォルトでコンテキスト成果物に対して読み取り専用です。ユーザーが明示的に要求しない限り、コンテキストファイルを変更しないでください。

プロジェクトコンテキスト

.ai-factory/skill-context/aif-review/SKILL.md を読む — ファイルが存在する場合は必須です。

このファイルには、/aif-evolve がパッチ、コードベースの規約、技術スタック分析から蓄積したプロジェクト固有のルールが含まれています。これらのルールは現在のプロジェクトに合わせて調整されています。

skill-context ルールの適用方法:

• それらをこのスキルの一般的な指示に対するプロジェクトレベルのオーバーライドとして扱ってください
• skill-context ルールがこの SKILL.md に書かれた一般ルールと競合する場合、 skill-context ルールが優先されます（より具体的なコンテキストが優先される — ネストされた CLAUDE.md ファイルと同じ原則です）
• 競合がない場合は、両方を適用してください: SKILL.md の一般ルール + skill-context のプロジェクトルール
• skill-context ルールがこのスキルのデフォルトと矛盾しているように見えても無視しないでください — それらはプロジェクトの経験がデフォルトでは不十分であると証明したために存在します
• 重要: skill-context ルールはこのスキルのすべての出力に適用されます — レビュー サマリの形式やチェックリストの基準も含みます。skill-context ルールが「レビューは X をチェックしなければならない」 または「サマリは Y セクションを含まなければならない」と述べている場合 — それに応じて出力を拡張しなければなりません。 skill-context ルールを無視したレビューを生成することはバグです。

強制: 出力成果物を生成した後、それをすべての skill-context ルールに対して検証してください。 いずれかのルールに違反している場合 — ユーザーに提示する前に出力を修正してください。

発見段階：絞り込みより網羅性

発見段階での役割は、絞り込みではなく網羅性です。確信が持てないものや、重要度が低いと判断したものも含め、見つけた問題をすべて報告してください。些細に感じる、あるいは確信が十分でないという理由で、指摘を省いてはいけません。絞り込みは後続段階（+check バリデーター、人間、またはゲートの「重大な問題／提案」の分類）で行われます。ここでは行いません。

• 確信が持てない指摘も表に出します。その影響に応じたセクションに記載し、明示的な確信度マーカーを付けてください（下記「指摘の分類と検証の境界」を参照）。質問には記載しません。不確実性は指摘にマークを付ける理由であり、検証の対象外にする理由ではありません。
• 「重大度の高いものだけ」「保守的に」という方針に合わせて自己検閲しないでください。十分に調査してから、見つけたものを報告し、優先順位付けは後続段階に任せてください。
• 「重大な問題」と「提案」の分類は適切に行ってください（ゲートは確認済みの重大な問題がある場合にブロックします）。確信度は指摘の文面に示すものであり、省略や格下げの理由にはなりません。

理由：Opus 4.8 は、以前のモデルよりも「重要な問題だけを報告する」という指示を文字どおりに受け取る傾向があります。調査の深さは同じでも、出力に反映される指摘が少なくなります。網羅性を優先する方針により再現率を維持し、優先順位付けは別の段階で行います。

指摘の分類と検証の境界

レビュー出力の各項目は、必ず次のいずれか1つのクラスに属します。クラスによって、項目の出力先と +check が検証するかどうかが決まります。

クラス	出力先	+check による検証
対応が必要なコード上の指摘 — レビュー対象の変更に関する、通常は file:line を根拠とする欠陥、リスク、改善案などの主張	重大な問題または提案	はい
コンテキストゲートの指摘 — アーキテクチャ／ロードマップ／ルールとの乖離	コンテキストゲート	いいえ
コミット構成に関する指摘 — コミットメッセージの正確さや分割の適切さ（コミットモード）	レビュー内にインラインで記載	いいえ
対応不要の所見 — 良いパターンを認めるもの	良い点	いいえ
真に未解決の確認事項 — それ自体には主張を含まないもの	質問	いいえ

重要な不変条件は次のとおりです。対応が必要なコード上の指摘は、重大な問題または提案以外の場所には記載しません。そのため、+check が設定されていれば、必ず検証対象になります。その他のクラスが対象外となるのは、バリデーターに判断できるだけの入力がないためです。バリデーターが受け取るのはレビュー対象の差分であり、アーキテクチャ／ルールに関する資料（コンテキストゲート）や、コミットごとの境界（コミットモードでは差分がまとめられます）ではありません。この対象外扱いは、バリデーターが参照できる根拠の制限であって、逃げ道ではありません。変更されたコードに関する主張は、どのような表現であっても検証対象に含めます。

判定基準：項目がレビュー対象の変更について、真偽を判断できる何らかの主張を述べているなら、それは対応が必要なコード上の指摘です。下書きの「質問」にそのような主張が紛れ込んでいる場合（「X が接続を漏らすのは意図的ですか？」など）は、分けてください。その主張は確信度マーカー付きの指摘にし、真に未解決の部分だけを質問として残します。

確信度マーカー

確信度と重大度は独立した要素です。

• 重大度によってセクションを選びます — 指摘が正しいと仮定した場合に、記載された挙動がもたらす影響に基づきます。マージを妨げる可能性がある問題は、それが実在するか確信が持てなくても重大な問題に記載します。一方、根拠が十分な細かな指摘は提案に記載します。
• 確信度は文面に示します — 確信が持てない指摘の末尾には、(confidence: low) または (confidence: medium) のいずれかを1つだけ付けます。確信度が高い場合は既定の状態とし、マーカーは付けません。文字列 (confidence: low|medium) をそのまま出力してはいけません。

マーカーは、公開されるゲートには残りません。マーカーがあると検証工程が実行され（「ゲート前のマーカー解決」を参照）、指摘が確認された場合はマーカーのない修正済みの文面が返され、その後は該当セクションの通常の指摘として扱われます。確認されなかった場合は削除されます。したがって、指摘にマーカーを付けても正確性が損なわれることはありません。不確実性を正直に記録し、その解決を予定するためのものであり、指摘の格下げや隠蔽にはなりません。

レビューチェックリスト

正確性

• ロジックエラーやバグ
• エッジケースへの対応
• Null/undefined チェック
• エラー処理の網羅性
• 型安全性（該当する場合）

セキュリティ

• SQL インジェクションの脆弱性
• XSS の脆弱性
• コマンドインジェクション
• 機密データの漏えい
• 認証／認可の問題
• CSRF 対策
• 入力値の検証

パフォーマンス

• N+1 クエリの問題
• 不要な再レンダリング（React）
• メモリーリーク
• 非効率なアルゴリズム
• インデックスの不足（データベース）
• ペイロードサイズが大きい

ベストプラクティス

• コードの重複
• デッドコード
• マジックナンバー／文字列
• 適切な命名規則
• SOLID 原則
• DRY 原則

テスト

• 新しいコードのテストカバレッジ
• エッジケースのテスト
• モックの適切さ

出力形式

## Code Review Summary

**Files Reviewed:** [count]
**Risk Level:** 🟢 Low / 🟡 Medium / 🔴 High

### Context Gates
[Architecture / Rules / Roadmap gate results with WARN/ERROR labels]

### Critical Issues
[Each item is a short paragraph in prose, not a labeled record. Order inside the paragraph:
1. Behavioral impact — what breaks for the user or downstream code.
2. Optional note — a code citation, a consequence, or extra context. Include only if it adds signal; skip otherwise.
3. Path — file:line of the affected location (or the closest anchor).
4. Suggested fix — concrete edit that addresses the behavior above.

Example:
> Two clients buying the last item both get a confirmation and stock goes negative — the order creation and stock reservation run in separate transactions. `src/services/order.ts:42`. Wrap `OrderService.create` and `InventoryService.reserve` in a shared transaction so the second buyer fails fast with "out of stock".
]

### Suggestions
[Same item shape as Critical Issues. The behavioral impact describes a non-blocking improvement (clarity, performance budget, missing log), not a bug.

In either findings section, an item you are not sure about ends with a `(confidence: low)` or `(confidence: medium)` marker — the section still follows impact, not certainty (see "Findings taxonomy and the validation boundary").

Example of a marked item, sitting in Critical Issues because its impact would be merge-blocking if real:
> Retries reuse the same idempotency key after a 5xx, so a duplicate charge is possible when the provider did commit the first attempt. `src/payments/retry.ts:88`. Generate a fresh key per attempt, or record the provider's response before retrying. (confidence: medium)

The marker never reaches the published gate as a finding: it is resolved by the validation pass (see "Resolving markers before the gate") — confirmed items come back without it, refuted ones are dropped, and a marker the pass failed to resolve turns the gate into a `review-validation-failed` failure.]

### Questions
[Free-form clarifications. Path optional, fix optional — these are open questions for the author, never findings (see "Findings taxonomy and the validation boundary").]

### Positive Notes
[Free-form acknowledgements of good patterns. No path/fix required.]

+check が項目を再分類した場合、項目のテキストに短い [+check: …] サフィックスが追加されます。正確な文言については references/CHECK-MODE.md を参照してください。

Markdown の要約の後に、最終的な機械可読形式の結果を追加してください。

{
  "schema_version": 1,
  "gate": "review",
  "status": "pass",
  "blocking": false,
  "blockers": [],
  "affected_files": [],
  "suggested_next": {
    "command": "/aif-commit",
    "reason": "Review found no blocking issues."
  }
}

検証パスが実行された場合、aif-gate-result ブロックはバリデーターによるフィルタリングの後に組み立てられます。status、blockers、affected_files、suggested_next は、それに応じて再計算されます。ディスパッチ全体が失敗した場合は、代わりにフィルタリング前のドラフトが入力として使われます。マーカーのないレビューでは検証前のゲートが再現され、マーカーのあるレビューでは review-validation-failed ゲートが出力されます。手順の詳細については references/CHECK-MODE.md を参照してください。

唯一マークされた重大な問題を検証できなかったレビューの失敗ブロック：

{
  "schema_version": 1,
  "gate": "review",
  "status": "fail",
  "blocking": true,
  "blockers": [
    {
      "id": "review-validation-failed",
      "severity": "error",
      "summary": "1 finding left unvalidated: validator response for item 1 violated the marked-item contract"
    }
  ],
  "affected_files": ["src/payments/retry.ts"],
  "suggested_next": {
    "command": null,
    "reason": "Validation of the marked finding failed, so the review is incomplete and no blocker verdict exists for it. Re-run /aif-review +check."
  }
}

レビューのスタイル

• 批判的になるのではなく、建設的に伝える
• 提案の「理由」を説明する
• 役立つ場合はコード例を示す
• 良いコードを評価する
• 重要度の高い順にフィードバックを並べる。ただし、重要度の低い指摘も省略せず、提案として提示する（「指摘の段階：フィルタリングより網羅性を優先」を参照）
• 決めつけるのではなく、質問する

例

ユーザー： /aif-review 現在のリポジトリでステージングされた変更をレビューします。

ユーザー： /aif-review 123 GitHub CLI を使用して PR #123 をレビューします。

ユーザー： /aif-review https://github.com/org/repo/pull/123 URL から PR をレビューします。

ユーザー： /aif-review 2.x 現在のブランチのすべてのコミットを、ブランチ 2.x と比較してレビューします。

ユーザー： /aif-review main 現在のブランチのすべてのコミットを、main（またはこのリポジトリで git.base_branch に設定されているブランチ）と比較してレビューします。

ユーザー： /aif-review v1.0.0 現在のブランチのすべてのコミットを、タグ v1.0.0 と比較してレビューします。

ユーザー： /aif-review +check ステージングされた変更をレビューした後、レンダリング前に、重大な問題と提案に対して +check バリデーターを実行します。バリデーターは、創作された項目を除外したり、部分的に正しい項目を書き換えたり、2 つの重要度レベル間で項目を再分類したりできます（提案を重大な問題に昇格、または重大な問題を提案に降格できます。ルールについては references/SEVERITY.md を参照してください）。フィルタリングの概要行を追加し、残った指摘からゲート結果を再構築します。正確な行の形式については references/CHECK-MODE.md を参照してください。

ユーザー： /aif-review 123 +check +check による検証を有効にして PR #123 をレビューします。

インテグレーション

GitHub MCP が設定されている場合、次の操作ができます。

• PR にレビューコメントを直接投稿する
• 変更を要求する、または承認する
• レビュー結果に基づいてラベルを追加する

ヒント： コードレビュー後はコンテキストが肥大化します。他のタスクを続ける前に、/clear または /compact の実行を検討してください。