Caliber: AI コーディングエージェントの設定ファイルをコードの変化に追随させる
Continuously sync your AI setups with one command. Codebase tailor suited agent skills, MCPs and config files for Claude Code, Cursor, and Codex.
ひと目でわかる
- これは何？
- CLAUDE.md や .cursor/rules を手書きで維持する代わりに、リポジトリを解析して生成し、コミットのたびに更新する CLI。仕組みと制約、採用判断の境界を整理する。
- 誰に向いている？
- 採用すべきなのは、Claude Code と Cursor を併用するチーム、あるいはエージェント設定ファイルが属人化して陳腐化しているリポジトリだ。逆に、CLAUDE.md を 1 ファイルだけ手で管理していて複数エージェントを併用していない場合、あるいは Node.js 20 を導入できない環境では、得られるものが設定ファイルの生成だけになり、pre-commit フックと同期ループという主要な価値を失う。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 52 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
手書きの CLAUDE.md が壊れる瞬間
このツールが狙う問題は、リポジトリの構造とエージェントに渡す文脈ファイルのずれだ。README は冒頭で「Hand-written CLAUDE.md files go stale the moment you refactor」と述べ、症状として存在しないパスへの言及、新しい依存関係の見落とし、古いアーキテクチャに基づく助言を挙げている。つまり対象は、エージェントの出力品質そのものではなく、エージェントに渡す前提情報の鮮度である。
想定利用者は、複数のエージェントを併用しているチームだ。README が生成対象として列挙するのは Claude Code、Cursor、OpenAI Codex、OpenCode、GitHub Copilot の 5 つで、それぞれ CLAUDE.md、.cursor/rules/*.mdc、AGENTS.md、.github/copilot-instructions.md といった別々のファイルを要求する。同じプロジェクト知識を 5 種類の形式に書き分ける作業を、リポジトリ解析から一度に生成して揃える、というのが出発点になっている。個人が 1 つのエージェントだけを使っている場合、この重複の問題自体が存在しない。
bootstrap は何をせず、何をエージェントに渡すか
導入は 2 段階に分かれている。Node.js 20 以上が必要で、最初のコマンドは次のとおり。
npx @rely-ai/caliber bootstrap
README によれば bootstrap 自体は約 2 秒で完了し、この段階では LLM 呼び出しもコード送信も行わない。ここで行われるのは、エージェントに /setup-caliber というスキルを渡すことだ。実際の解析と生成は、ターミナルで起動した Claude Code または Cursor の CLI セッション内で /setup-caliber を打ち込んだときに走る。
Claude Code や Cursor を使わない場合は caliber init を使う。こちらは CLI ウィザード形式で、Anthropic、OpenAI、MiniMax、Vertex AI のいずれかのキーを持ち込む形になる。生成に使うのは利用者自身のサブスクリプションか API キーで、Caliber 側がコードを見ることはないと README は説明している。
この分担には設計上の意図がある。解析タスクをエージェント側に寄せることで、モデルの選択と課金を利用者側に残している。裏返せば、エージェント側のセッションが正常に動かない環境では生成が成立しない。
スコアは LLM を使わずファイルシステムと突き合わせる
caliber score は決定的な採点だと README は明言している。LLM も API 呼び出しも使わず、設定ファイルの記述を実際のプロジェクトのファイルシステムと照合する。具体的には、参照されているパスが実在するか、コードブロックが含まれているか、前回のコミット以降に設定のドリフトが起きていないかを確認する。
配点は FILES & SETUP 25 点、QUALITY 25 点、GROUNDING 20 点、ACCURACY 15 点、FRESHNESS 10 点、BONUS 5 点の 100 点満点で、README の Before/After では 35 点（Grade D）から 94 点（Grade A）への変化が示されている。ブランチ単位の比較もできる。
caliber score --compare main
採点が決定的である点は実務上大きい。CI に組み込めば、設定ファイルの変更がスコアを下げたかどうかをモデルの非決定性なしに判定できる。ただしこの数字は設定ファイルの記述とリポジトリの一致度を測っているだけであり、エージェントが生成するコードの正しさを測るものではない。README のバッジにある 94/100 も、この自己申告の指標である。
監査、提案、レビュー、バックアップ、取り消し
書き込みの順序はコードレビューに似せてある。score で読み取り専用の監査を行い、propose で差分として提示し、accept、チャットでの修正、拒否をそれぞれ選べる。書き込みの前には元ファイルが .caliber/backups/ に退避され、caliber undo で元の状態に戻せる。
注目に値するのは、既存設定が 95 点以上の場合の分岐だ。README によれば、この場合は全面再生成をスキップし、失敗している特定のチェックに対してだけ修正を当てる。生成物を丸ごと入れ替えるのではなく差分を小さく保つ設計で、既存の書き込みを尊重する姿勢が表れている。
ただしこの分岐は、スコアが高いほど Caliber の出力が変わることを意味する。95 点未満なら生成ロジック、95 点以上なら修正ロジックと、同じコマンドでも中身が別物になる。導入時のスコアを把握しておかないと、期待した動作と実際の動作がずれる。
refresh ループと pre-commit フック
生成後は同期のループに入る。コードが変化し、新しい依存が入り、ファイル名が変わり、アーキテクチャが変わると、caliber refresh が設定を追随させる。README の図では、この refresh がコミットのたびに自動で走るとされている。pre-commit フックがその実行主体だ。
生成物はプラットフォームごとに分かれる。Claude Code 向けには CLAUDE.md、CALIBER_LEARNINGS.md、.claude/skills/*/SKILL.md、.mcp.json、.claude/settings.json。Cursor 向けには .cursor/rules/*.mdc、.cursor/skills/*/SKILL.md、.cursor/mcp.json。Codex 向けには AGENTS.md と .agents/skills/*/SKILL.md。OpenCode 向けには AGENTS.md と .opencode/skills/*/SKILL.md。GitHub Copilot 向けには .github/copilot-instructions.md。Codex と OpenCode を同時に対象にした場合、AGENTS.md は共有される。
スキルの形式は OpenSkills（agentskills.io）と README が参照している。MCP サーバー設定は自動検出されるという記述があるが、検出の対象範囲や優先順位についての説明は README には見当たらない。ここは導入前に自分のリポジトリで何が検出されるかを確認するしかない。
Windows と Git Bash という現実的な制約
README の Windows 向け注記は、このツールの弱点を正直に開示している。第一に、IDE のチャットウィンドウからではなくターミナルから実行する必要がある。第二に、pre-commit フックと自動同期スクリプトがシェル構文を使うため、Git Bash の利用が推奨される。PowerShell しか使わない場合、フックが警告なしにスキップされる可能性があると明記されている。
これは同期ループという主要機能に直結する。フックが黙って動かなければ、設定ファイルは生成時点で止まり、まさに Caliber が解こうとしている陳腐化がそのまま起きる。CI で caliber score を回していれば検知できるが、フック単体に頼る運用は Windows では成立しにくい。
もう 1 つの制約は同時実行だ。複数のターミナルから Caliber を同時に走らせると状態が競合し、プロバイダ検出が予期しない結果になると README は警告している。加えて Cursor Agent CLI を入れる場合、macOS/Linux 向けの curl | bash ではなく公式ダウンロードページから取得し、agent login で認証する手順が示されている。
手書き運用、あるいは自前スクリプトとの違い
比較対象として素直なのは、CLAUDE.md を手で書き続ける運用だ。この場合、更新のタイミングは人間が決め、内容の正確さも人間が担保する。コストはレビュー時に集中し、ツールへの依存はゼロで、Windows でもシェル構文の問題は起きない。差が出るのは対象エージェントが増えたときで、5 種類のファイルを手で同期させるのは現実的でなくなる。
もう 1 つの選択肢は、自前のスクリプトでファイル一覧や依存関係を抽出してテンプレートに流し込む方法だ。この場合は出力の形式を完全に制御できるが、採点、差分提示、バックアップ、undo といった周辺は自分で作ることになる。Caliber の差分はスコアの内訳と結びついて提示される点が違いで、どのチェックが失敗しているかが変更の根拠として示される。
どちらが優れているかは、エージェントの数と、設定ファイルの変更をレビューする文化があるかで決まる。1 エージェント、1 ファイルなら手書きのほうが軽い。
ライセンスと更新頻度から見る維持コスト
ライセンスは MIT で、リポジトリはアーカイブされていない。npm パッケージ名は @rely-ai/caliber。MIT なので改変と再配布は許容されるが、これは法的助言ではない。生成物を社外に配布する場合や、社内のコンプライアンス基準がある場合は、自組織の判断が必要になる。
更新の頻度は高い。提供されたリリース情報では v1.53.3、v1.53.4、v1.53.5 がいずれも 2026-07-26 に公開されており、同日に複数回のパッチが出ている。活発である一方、npx で都度取得する運用だと、実行するたびに異なるバージョンが走る可能性がある。CI に組み込むならバージョンを固定したほうが再現性は上がる。
維持コストとして見落としやすいのは、生成された設定ファイル自体がリポジトリの成果物になる点だ。refresh が書き換えるたびに差分が出るので、レビュー対象が増える。pre-commit フックが自動で書き換える運用では、コミットに設定変更が混ざることを許容するか、別コミットに分けるかをチームで決めておく必要がある。
編集部の結論
採用すべきなのは、Claude Code と Cursor を併用するチーム、あるいはエージェント設定ファイルが属人化して陳腐化しているリポジトリだ。逆に、CLAUDE.md を 1 ファイルだけ手で管理していて複数エージェントを併用していない場合、あるいは Node.js 20 を導入できない環境では、得られるものが設定ファイルの生成だけになり、pre-commit フックと同期ループという主要な価値を失う。導入前に確認すべきは 3 点ある。第一に、リポジトリの既存設定が caliber score で何点になるか。README には 95 以上なら全面再生成をスキップして失敗チェックだけを修正すると書かれているため、点数次第で挙動が変わる。第二に、Git Bash が使えるか。Windows では PowerShell のみの場合フックが警告なくスキップされ得ると README が明記している。第三に、refresh が書き換えるファイルの差分をレビューする運用が回るか。生成物はコミット対象のファイルなので、差分を読まずに通すなら手書き設定と変わらない品質になる。
コミュニティノート