humanize は Claude Code に外部レビュアーを組み込むプラグインである

humanize が埋めようとしている穴は何か

コーディングエージェントに実装を任せたとき、最初の出力がそのまま正しいことは稀である。問題は、生成した本人に自分の成果物を評価させると、同じ思い込みがレビューにも持ち込まれる点にある。humanize はここに外部レビュアーを差し込む。README によれば、これは Claude Code のプラグインであり、Claude が実装し、Codex が独立にレビューする構成を取る。対象読者は、Claude Code をすでに使い、単発の生成ではなく収束するまで反復させたい開発者である。README は GAAC (GitHub-as-a-Context) プロジェクト由来だと述べており、リポジトリの主要言語は Shell、ライセンスは MIT と明記されている。

RLCR という名前が指す2段階のループ

RLCR は Ralph-Loop with Codex Review の略で、公式の ralph-loop プラグインを下敷きに Codex レビューを足したものだと README は説明する。同時に Reinforcement Learning with Code Review とも読めるとしており、反復の性格を二重に名付けている。ループは2つのフェーズで回る。Implementation フェーズでは Claude が作業し、Codex は要約をレビューする。Code Review フェーズでは Codex が重要度マーカー付きでコード品質を検査する。指摘は実装フェーズに戻され、解消されるまでこの往復が続く。注目したいのは、レビュー対象が常にコード全文ではなく、フェーズによって要約とコード本体に分かれている点である。全量を毎回レビューさせるとコンテキストが膨らむため、この分割はコスト側の設計判断だと考えられる。

Ralph Loop と Swarm Mode の関係

README は Ralph Loop with Swarm Mode という項目を置き、反復的精緻化が受け入れ基準を満たすまで続くと述べている。Swarm Mode は任意であり、Agent Teams で並列化する選択肢として提示されている。つまり既定は逐次ループであり、並列化は追加の設定だという位置づけになる。README には Swarm Mode の有効化手順や並列度の指定方法までは書かれていないため、実際に並列化する場合の設定は docs/usage.md を確認する必要がある。ここは README だけでは判断できない部分であり、導入前に一次情報を当たるべき箇所である。

「Begin with the End in Mind」が人間に残す役割

ループを開始する前に、humanize は実行しようとしている計画を人間自身が理解しているかを確認する。README はこれを Begin with the End in Mind と呼び、人間が architect であり続けるべきだと書いている。エージェントに計画立案から実行まで一括で渡すと、誤った前提のまま反復が高速に回り、間違った方向へ収束しうる。この確認ステップは速度を落とす代わりに、その事故を防ぐためのものだ。ただし README の記述はこの概念の説明にとどまり、確認が具体的にどのような操作を求めるのかは docs/usage.md の該当節に委ねられている。設計思想としては妥当だが、README 単体では運用像が見えにくい。

インストールはマーケットプレイス経由で完結する

導入手順は README に具体的なコマンドとして示されている。まずマーケットプレイスを追加する。

/plugin marketplace add PolyArch/humanize

実験的な機能のために開発ブランチを使いたい場合は、参照先を #dev 付きに変える。

/plugin marketplace add PolyArch/humanize#dev

そのうえでプラグイン本体を導入する。

/plugin install humanize@PolyArch

レビューには codex CLI が必要だと README は明記しており、前提条件と代替のセットアップは docs/install-for-claude.md にまとめられている。Codex 側のスキルランタイムは docs/install-for-codex.md、Kimi CLI 向けは docs/install-for-kimi.md が担当する。構成ファイルの階層と上書き規則は docs/usage.md の Configuration 節に記載がある。

gen-idea から start-rlcr-loop までの実際の流れ

Quick Start は6ステップを示す。緩い思いつきからアイデア草案を作るには次を実行する。

/humanize:gen-idea "add undo/redo to the editor"

出力は既定で .humanize/ideas/<slug>-<timestamp>.md に置かれる。既存の雑なメモを渡して展開させることもでき、--n で同時に探索する方向の数を制御する（既定は6）。次に草案から計画を生成する。

/humanize:gen-plan --input draft.md --output docs/plan.md

レビュアーが CMT: ... ENDCMT、<cmt> ... </cmt>、<comment> ... </comment> のいずれかの形式で注釈を付けた場合は、実装前に計画を洗い直す。

/humanize:refine-plan --input docs/plan.md

そしてループを回す。

/humanize:start-rlcr-loop docs/plan.md

深い web 調査が必要なときは Gemini CLI を前提とするコマンドも用意されている。

/humanize:ask-gemini What are the latest best practices for X?

進捗監視は Claude Code の中ではなく別ターミナルで行う。scripts/humanize.sh を source するか、.bashrc や .zshrc に加えておき、humanize monitor rlcr、humanize monitor skill、humanize monitor codex、humanize monitor gemini を使い分ける。

外部 CLI への依存という制約

humanize のレビュー機能は Codex CLI の存在を前提とする。README は「Requires codex CLI for review」と明記しており、これが最大の導入障壁になりうる。Claude Code は使えるが OpenAI 側の CLI を別途導入できない、あるいは組織のポリシーで複数ベンダーのエージェントを同居させたくない場合、このプラグインの中心機能は動かない。ask-gemini も同様に Gemini CLI を要求するため、調査コマンドだけを使いたい場合も別の依存が発生する。もう一点、gen-idea の出力先が .humanize/ideas/ であることは、リポジトリ内にエージェントの中間成果物が蓄積されることを意味する。.gitignore の扱いについて README は触れていないため、チームで使う場合は追跡するか除外するかを先に決めておく必要がある。

ralph-loop 単体との違いはレビュアーの独立性

比較対象として README 自身が挙げているのが公式の ralph-loop プラグインである。humanize はこれを下敷きにしつつ、Codex による独立レビューを追加したと説明されている。違いは反復の停止条件にある。ralph-loop 的な素朴な反復では、同じモデルが実装と自己評価の両方を担うため、誤りがそのまま通過しやすい。humanize はレビューを別プロセスの Codex に移し、重要度マーカー付きの指摘として実装側に返す。モデルを分けることが本質であり、単にプロンプトで「レビューして」と頼むのとは仕組みが異なる。ただし、Claude と Codex のどちらも誤る可能性は残る。外部レビューは盲点を減らす設計であって、保証ではない。

導入前に確認しておくべきこと

最初に確認すべきは codex CLI が手元で動作するかどうかである。これが動かなければ RLCR の中核は機能しない。次に、既定の出力先 .humanize/ideas/ をバージョン管理に含めるかを決める。含めるなら計画ファイル docs/plan.md とあわせて履歴が残り、含めないなら .gitignore に追記する作業が発生する。Swarm Mode を使う予定があるなら、並列化の設定方法を docs/usage.md で確認しておく必要がある。README にはその手順が書かれていない。ライセンスは MIT と明記されているが、条項の解釈は自組織の判断による。README は Humanize2 が活発に開発中でありフィードバックを求めていると冒頭で述べており、仕様が動く前提で追従コストを見積もっておきたい。

編集部の結論

採用を検討すべきなのは、Claude Code を日常的に使い、実装とレビューを別プロセスに分離したい開発者である。逆に、Codex CLI を別途導入できない環境、あるいは単発の小規模修正しかしない用途には向かない。導入前に確認すべきは、README が前提としている codex CLI が手元で動くか、そして .humanize/ideas/ 配下に生成される成果物をリポジトリにどう扱うか、の2点である。MIT ライセンスと明記されているため社内配布の障壁は低いが、ライセンス条項の解釈は最終的に自組織の法務判断に委ねられる。

公式情報源

1. Issues
2. PolyArch/humanize on GitHub
3. README