Citadel: Claude CodeとCodexの作業を状態付きで運用する層

v1.3.5を固定する導入経路

CitadelはClaude CodeとOpenAI Codexの間に置く、オープンソースの運用レイヤーです。リクエストの振り分け、セッションをまたぐプロジェクト状態、並行作業の調整、リポジトリの保護フック、検証結果と引き継ぎを扱います。READMEが示す前提はNode.js 22以上、対象となるgitリポジトリ、対応するエージェントです。

Codexでは`codex plugin marketplace add SethGammon/Citadel --ref v1.3.5`に続けて`codex plugin add citadel@citadel-local`を実行します。Claude Codeでは`claude plugin marketplace add SethGammon/Citadel@v1.3.5 --scope local`とローカルスコープのインストールを使います。浮動するmainを安定版として扱わない点が、この導入手順の要所です。

採用前の記録ではsethgammon-citadel-deep-analysisのリリース、実行環境、入力、出力を固定します。画面やREADMEの印象ではなく、コマンドの終了コード、生成されたファイル、ネットワーク接続、エラー時の復帰を確認します。正常系だけでなく、設定値を欠かせた場合、権限を持たない場合、途中でプロセスを止めた場合も試します。観察結果は人が読めるメモと機械的なログの両方に残し、次の更新で同じ手順を再実行できる形にします。

導入を決める前に、sethgammon-citadel-deep-analysisが触れる範囲を一覧化します。読み取りだけか、ファイル変更や外部接続も行うかを分け、許可した範囲を越えた記録がないかを確認します。依存するランタイムと補助サービスの版を保存し、更新前後で差分を比較します。失敗したときに残るログの場所、利用者が元の状態へ戻す方法、削除や無効化の手順が説明できなければ、本番の対象には広げません。

この確認では、sethgammon-citadel-deep-analysisにない機能を推測で補いません。READMEに記載された入口から小さな入力を与え、期待する応答と実際の応答を比べます。未記載の挙動は未確認として残し、数値や互換性を一般化しません。

/doが選ぶ作業の境界

通常の入口は`/do review README.md`や`/do generate tests for the changed files`のように、目的を文章で渡す形式です。既知のコマンドは、対象の`package.json`に空でない対応スクリプトがある場合に解決されます。自然言語のpreviewは候補を示すだけで、実行可能状態にはなりません。

明示的な`/do --route /test-gen -- ...`も用意されていますが、導入済みであることや承認境界を飛ばす仕組みではありません。焦点を絞ったワークフロー、再開用の`/do next`、キャンペーン、Fleetという段階があり、短い修正なら元のエージェントの操作だけで足りるというREADMEの自己評価も判断材料です。

中断後に戻るためのリポジトリ状態

Citadelの運用ループは、ルーティング、実行と検証、記録、再開です。結果、ハンドオフ、次のアクションは対象リポジトリに置かれ、リポジトリを作業の基準点として扱います。Needs Youは承認、競合、不足する証拠を明示して停止し、Resumeは次の作業を新しいセッションへ渡します。

クロスリポジトリの記憶は必須ではありません。READMEではNode.js 22.13以上で`citadel memory enable`を実行した場合、完了キャンペーンや発見をユーザー側のSQLiteに保存できると説明しています。そのデータベースをCitadelが自動でcommit、push、転送するとはしていません。

安全機構は権限の代わりにならない

インストール時のadoption planは対象の状態を取り、apply時にその状態が変わっていれば`TARGET_DRIFT`として拒否します。手動の高信頼手順では、リリースのtar.gz、manifest、sha256を同じ場所に置き、二つの公開値を照合してから展開します。planは対象リポジトリの外へ保存する必要があります。

READMEは、Citadelがエージェント自身の権限で動作し、コードレビュー、ブランチ保護、プロジェクト固有のチェックを置き換えないと明記しています。つまり、保護フックがあることだけで危険な変更を許可してよいとは言えません。承認と差分の確認は既存の責任者に残ります。

エネルギー評価を失敗も含めて読む

READMEは性能や費用を都合よく一つの数字で示していません。初期測定では36セル中27対24、固定集計でGPUエネルギー9.9%減に見えましたが、対照側の60秒タイムアウトが見かけを作っていました。該当ペアを除くとCitadel側はGPUエネルギー3.5%、モデル化GPU費用5.4%増となり、v1の節約主張は撤回されています。

後続の常時7Bプロファイルでも、36中24の検証率に対してエスカレーション後のGPUエネルギーは15.7%増でした。代表fixtureでは両方とも36中6、誤合格ゼロでしたが、7.1%減は20%ゲート未達で失敗扱いです。採用判断では、便利そうな機能と測定上の負荷を分けて読みます。

向くチームと最初の確認点

複数エージェント、長い変更、作業中断、ブランチ分離を日常的に扱うチームなら、状態と引き継ぎの形式化が役立つ可能性があります。反対に、単発のREADME修正や小さな一回限りの編集では、追加のフックと状態管理が負担になります。`CLAUDE.md`や`AGENTS.md`を置き換える製品でもありません。

試すなら、空ではないテストスクリプトを持つ検証用リポジトリでv1.3.5を固定し、`/do preview`が非実行になること、`/do review README.md`のreceipt、Needs Youで止まる条件、`citadel doctor --target . --json`の出力を保存します。採用の根拠はエネルギー削減ではなく、自分たちの変更で状態復旧と承認が再現できるかに置くべきです。

確認用のリポジトリでは、変更前のgit status、Citadelが生成したplan、apply後の差分を同じ時系列で保存します。`/do preview`でselectedとcommandがnullになること、実行を伴う依頼では対象スクリプトの結果がreceiptに記録されることを分けて見ます。ブランチを切り替えてから再開し、Resumeが古い作業を誤って指さないかも試験対象です。

編集部の結論

Citadelは、複数セッションや並行ブランチをまたぐエージェント作業に向く一方、単発編集には重い可能性があります。導入前にv1.3.5を固定し、実リポジトリでplan、apply、doctorの記録とNeeds You境界を確認してください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes