Cindy：Claude Code と Codex を一つのローカルエージェントに束ねるオープンソースクライアント

概要：複数のコーディングエージェントを束ねるローカルクライアント

Cindy（makecindy/cindy）は、「Consider it done」を掲げるオープンソースの AI エージェントクライアントです。Claude Code や Codex など別々のコーディングエージェントを行き来する代わりに、複数のハーネス（エージェントの実行基盤）、モデル、ツールを一つのエージェントにまとめます。エージェントは利用者自身のマシン上で動き、実際のファイルとログイン済みのアプリを使って仕事を進めます。ライセンスは Apache-2.0 で、pnpm のモノレポ構成です。Electron 製のデスクトップアプリ、Expo / React Native 製のモバイルアプリ、認証・デバイス連携・エージェント編成・モデルプロバイダーなどの共有パッケージを含みます。

最初に押さえるべき点があります。このリポジトリが含むのはクライアントだけです。README には、バックエンドサービスは別リポジトリにあり、このモノレポには含まれないと明記されています。ここでいう「オープンソース」はクライアントのソースコードを指し、クラウドサービス全体ではありません。

中核アーキテクチャ：ハーネス・モデル・ツールの分離

README の記述から読み取れる設計の要点は、三つを切り離していることです。 一つ目はハーネスです。最初に対応するのは Claude Code と Codex で、今後さらに追加し、独自のネイティブハーネスも開発中とされています。apps/*-bin ディレクトリには、デスクトップアプリに同梱するツールのバイナリが置かれます。claude-code、codex、ripgrep は pnpm install の際にプラットフォームごとにダウンロードされます。Android の platform-tools は、Windows 向けのパッケージング前に、バージョンを固定し sha256 を検証して取得します。つまり Cindy はコーディングエージェントを一から作り直すのではなく、既存のエージェント CLI を差し替え可能な実行エンジンとして同梱し、制御しているのです。

二つ目はモデルです。モデルとハーネスは自由に組み合わせられ、タスクの途中で切り替えることもできます。モデルの用意の仕方は四通りあります。公式の Cindy サービスにサインインして使う（利用量は透明に差し引かれる）。すでに契約している Claude Code / Codex の Coding Plan を認可し、二重の請求なしに Cindy で使い続ける。自分の API キーを接続する。ローカルモデルを使う。 三つ目は、エンジンをまたいで連続する作業環境です。ワークスペース、メモリ、スキル、ツールは、ハーネスやモデルを切り替えても保たれます。ここは設計の中で最も価値があり、同時に最も難しい部分です。エージェントごとにコンテキスト、ツール呼び出しの形式、スキル記述の約束事が異なるため、エンジンを替えても状態を失わないようにするには、独自の抽象化層が必要になります。

マルチエージェント協調：計画、並列実行、相互レビュー

README によると、一つのタスクを、異なるハーネスとモデルの組み合わせのエージェントが分担して、計画、並列実行、レビューまで進めることができます。これは近年のマルチエージェント開発でよく見られる手法と一致します。あるモデルがタスクを分解し、複数の実行者が重ならない範囲で並行して作業し、別系統のモデルが独立にレビューします。同じモデルが自分の成果をレビューするときの盲点を減らせます。Cindy はこの流れを製品機能として提供し、利用者が手作業でスクリプトをつなぐ必要をなくします。

コード作業だけでなく、ブラウザ、コンピューター、スマートフォンの操作も可能で、IM（インスタントメッセージ）やスケジュールから仕事を受け取れます。狙いは、コーディング支援にとどまらない常駐型の汎用ワークエージェントだと考えられます。

「自分で形づくる」層：メモリ、スキル、自動化、MCP、プラグイン

拡張性は「Yours to shape」という言葉でまとめられています。メモリは、一度訂正すればその後はハーネスをまたいで共有されます。スキルは、仕事の進め方を一度教えればどこでも再利用できます（チームへの配布機能は開発中）。自動化は、定期的な作業が自分でスケジュールされ、実行され、結果を報告します。

MCP は、社内ツールや業務システムをエージェントの手の届く範囲につなぎます。プラグインは、オープンなマーケットプレイスで共有する構想で、これも準備中です。現時点では SkillHub か手動でインストールします。そしてソースコード自体は、監査、フォーク、拡張、貢献が可能です。

利用モードとセットアップ

ログイン画面には二つのモードがあります。Cindy のクラウドアカウントを使うホスト型サービスと、アカウント不要でローカルのエージェントを動かす「Skip Sign-In」です。後者ではアプリ上の表示が「未サインイン」となり、サーバー側に依存する機能は使えません。クライアントは既定で公式のクラウドサービスに接続します。

エンドポイントのマニフェストは config/endpoint.json と config/endpoint.global.json にあり、デスクトップの自動更新も公式 CDN から配信されます。開発時は pnpm restart:desktop:remote --region=cn または --region=global で、自分の Cindy アカウントに対して動作確認できます。必要な環境は Node.js 22.x、pnpm 10.x（v11 は未対応）、Git LFS です。Linux 向けには、Ubuntu、Arch Linux、Omarchy のインストールガイドが用意されています。

性能とコスト：公開ベンチマークはまだない

この点は正直に述べる必要があります。README にはベンチマークの数値がなく、レイテンシ、成功率、コストの比較も示されていません。したがって、Claude Code や Codex を単独で使う場合と比べて、どれだけ速く、どれだけ正確かは、この資料からは判断できません。

確かなのはコスト構造です。既存の Coding Plan を認可すれば二重請求は発生せず、公式サービスなら利用量に応じて差し引かれ、自分のキーやローカルモデルならその費用は利用者が負担します。複数エージェントによる並列レビューはトークン消費を増やします。これはこの種の設計に共通するトレードオフで、実際の数字は運用して測る必要があります。

影響、限界、今後

開発者にとっての価値は、エージェントツール間でコンテキストを持ち運ぶ手間が減ることと、レビューの工程が仕組みとして組み込まれることです。企業にとっては、Apache-2.0 のクライアント、監査できるソース、実ファイルを使うローカル実行という点が魅力になります。ただし、データの経路は選ぶモデルの提供元や、公式クラウドを使うかどうかで変わります。

限界も明確です。第一に、バックエンドは公開されておらず、ホスト型サービスの挙動は監査できません。第二に、実ファイル、ログイン済みアプリ、スマートフォンを操作できるエージェントは権限の範囲が非常に広く、プロンプトインジェクションや誤操作のリスクを利用者自身が評価し、隔離する必要があります。第三に、Claude Code や Codex といった上流 CLI への依存があるため、上流のインターフェースやライセンス条件の変更が Cindy に直接影響します。第四に、ネイティブハーネス、チーム向けスキル配布、プラグインのマーケットプレイスはいずれも準備中で、ロードマップは未達成です。今後の注目点は、ネイティブハーネスのリリース、対応ハーネスの拡大、第三者による独立した評価、そしてセキュリティモデルの文書化です。