zcf (Zero-Config Code Flow): Claude Code と Codex の初期設定を CLI にまとめる
Zero-Config Code Flow for Claude code & Codex
ひと目でわかる
- これは何？
- Claude Code と Codex の導入時に散らばる設定作業を、対話メニューとサブコマンドに集約する TypeScript 製 CLI。何を自動化し、どこで手動に戻るのかを README の記述範囲で整理する。
- 誰に向いている？
- すでに Claude Code か Codex を日常的に使い、プロジェクトごとにワークフローやプロバイダ設定を手で置いている人には、npx zcf i の一発でその作業が畳まれる点が効く。逆に、社内で設定ファイルの内容をレビューしてから配りたい場合や、書き込まれるファイルの差分を把握せずに実行したくない場合は、いきなり npx zcf i を打たず、まず npx zcf u でワークフロー更新のみを試し、生成物を git diff で確認してから範囲を広げるのが順当だ。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 16 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
zcf が埋めようとしているのはモデルの性能差ではなく設定の段差
Claude Code や Codex を使い始めるとき、本体のインストールそのものは数分で終わる。時間を食うのはその後で、プロジェクトごとに置くワークフロー用のファイル、API キーや中継サービスのエンドポイント、MCP サーバーの登録といった周辺の設定が、それぞれ別の場所と別の書式で管理される。zcf はこの周辺設定をひとつの CLI に寄せる。README の説明では「Zero-config, one-click setup for Claude Code & Codex with bilingual support, intelligent agent system and personalized AI assistant」とあり、対象は Claude Code と Codex の利用者、とくに複数プロジェクトで同じ初期設定を繰り返している開発者になる。設定そのものを発明するツールではなく、既存の設定作業を対話メニューとサブコマンドに置き換えるツールだと読める。
npx zcf の対話メニューとサブコマンドの二段構え
README が推奨として挙げるのは引数なしの npx zcf で、対話メニューが開き、必要な項目を選ぶ形式になる。定型作業をスクリプトに落としたい場合はサブコマンドを使う。npx zcf i は「Full initialization: install + workflows + API/CCR + MCP」と説明され、インストール、ワークフロー、API または CCR の設定、MCP の設定をまとめて実行する。npx zcf u はワークフローの更新のみを行う。言語は npx zcf --lang zh-CN のように切り替えられ、README では中国語を例にしている。つまり zcf の操作面は、初回に全部入れる i と、その後ワークフローだけ差し替える u という二つの粒度に分かれている。日常的に叩くのは u のほうになる。
非対話モードとプロバイダプリセット
CI やセットアップスクリプトに組み込む場合、対話メニューは邪魔になる。README は非対話の例として npx zcf i -s -p 302ai -k "sk-xxx" を示している。-s が非対話を意味し、-p でプロバイダのプリセットを選び、-k で API キーを渡す形だ。ここで重要なのは、プリセット名がプロバイダごとに定義されている点である。README のスポンサー欄には AICodeMirror、Z.ai、code0.ai、Claude API、PatewayAI、302.AI、PackyCode、APIKEY.FUN といった中継・API サービスが並んでおり、302ai はそのうちの一つとして -p の値に現れる。自分の契約先がプリセットに無い場合、対話メニュー側で手入力するか、生成された設定ファイルを後から書き換えることになる。どのプリセットが存在するかの全量は README には列挙されていない。
設定はどこに書かれるのか、README からは読み切れない
zcf は Claude Code と Codex の設定を扱う以上、ホームディレクトリ配下の設定ファイルやプロジェクト内のファイルに書き込みを行うはずだが、README には書き込み先のパスも、生成されるファイルの一覧も載っていない。詳細は https://zcf.ufomiao.com/ のドキュメントに委ねられている。これは採用判断のうえで実務的な障害になる。設定ファイルの内容をレビューしてからチームに配りたい場合、何がどこに書かれるかを先に知る必要があり、その情報は README だけでは得られない。リポジトリの src 配下や CHANGELOG.md を読むか、使い捨ての環境で一度実行して差分を取るのが確実である。README の記述から確認できる範囲では、zcf は「設定を代行する」ツールであって「設定を可視化する」ツールではない。
向かないケース: 設定を統制したい組織と、単一プロジェクトの利用者
zcf が効くのは、複数のプロジェクトで同じ初期設定を繰り返している場合か、プロバイダを切り替えながら試している場合だ。逆に向かないのは二つある。一つは、設定ファイルの内容を統制し、レビュー済みのものだけを配布している組織。zcf の i は複数の領域をまとめて書き換えるため、差分の単位が粗い。もう一つは、単一のプロジェクトで一度だけ Claude Code を設定すれば終わる利用者で、この場合は手で数ファイルを置くほうが速く、zcf の更新追従コストを負う理由が薄い。また README には zcf 自身が書き込む設定のバックアップやロールバックに関する記述が見当たらない。既存の設定がある状態で i を実行したときに何が起きるかは、実行前に確認しておくべき項目になる。
比較対象としての Claude Code 標準の設定と手動運用
zcf を使わない場合、Claude Code と Codex の設定は各ツールの標準の仕組みに従って手で行う。プロバイダを変えるたびに環境変数や設定ファイルを編集し、MCP サーバーを追加するたびに該当のコマンドを打ち、ワークフロー用ファイルはプロジェクトへコピーする。この方法の利点は、何が変更されたかが常に自分の編集履歴として残る点にある。zcf との違いは抽象度ではなく、変更の単位である。手動運用は一ファイルずつの変更、zcf は i という単位での一括変更になる。中継サービス各社が提供する専用のセットアップ手順も同種の作業を自動化するが、それらは自社サービスへの接続に閉じている。zcf はプロバイダ選択を -p の引数として外に出し、複数の接続先を同じ操作で扱えるようにしている点が構造上の差になる。
MIT ライセンスと更新頻度から見る保守コスト
ライセンスは MIT で、フォークして社内用に改変することも、生成される設定を自組織向けに固定することも、ライセンス上は可能である。ただし MIT は無保証であり、生成された設定が期待どおり動くかの責任は利用側にある。保守の観点では、リポジトリの最終 push は 2026-08-31 で、同日に zcf@3.7.3 がリリースされている。直前は 2026-08-04 の 3.7.2、2026-07-20 の 3.7.1 と、おおむね数週間から一か月の間隔で版が上がっている。追従コストを見積もるなら、この頻度で npx zcf u を回し直す前提を置くことになる。npx 経由で毎回最新を取得する運用は、逆に言えばバージョンを固定しない限り実行ごとに挙動が変わりうるということで、再現性が必要な場面ではバージョンを明示して呼び出すほうが安全だ。
編集部の結論
すでに Claude Code か Codex を日常的に使い、プロジェクトごとにワークフローやプロバイダ設定を手で置いている人には、npx zcf i の一発でその作業が畳まれる点が効く。逆に、社内で設定ファイルの内容をレビューしてから配りたい場合や、書き込まれるファイルの差分を把握せずに実行したくない場合は、いきなり npx zcf i を打たず、まず npx zcf u でワークフロー更新のみを試し、生成物を git diff で確認してから範囲を広げるのが順当だ。採用前に確認すべきは、自分の環境で ~/.claude 配下に何が書かれるか、そして README が例示する -p 302ai 以外のプロバイダプリセットが自分の契約先をカバーしているかである。
コミュニティノート