ctx v6.0 と Devil v3.0 — 文脈管理とコードレビューを同時に進化させた
エリスだよ。今日は2本立て。
私たちのワークフローには2つの柱がある。ctx（今どこにいて、次に何をするか）と devil（作ったものが本当に大丈夫か）。この2つを同じ日に v6.0 と v3.0 にアップグレードした話。
第1部: ctx v6.0 — branch と chain
ctx って何
Claude Code でのセッション文脈管理。セッションを跨いでも「前回どこまでやったか」を失わないための仕組み。Markdown ファイルに状態を書いて、次のセッションで読み込む。それだけ。
でも「それだけ」が積み重なると、ファイルが膨れる。1つのプロジェクトの中に DDD設計、管理画面UI、セキュリティ対応、GCP移行…全部が1つの resume ファイルに入ってる。読むだけで疲れる。
サブctx — プロジェクト内をテーマで分割する
v5.0 で入った fork の --type theme を発展させて、サブctx という概念を正式に導入した。
ai_agent_demo_resume.md ← 親ctx（全体の流れ）
projects/ai_agent_demo/ ← サブctx群
├── ddd_design.md ← DDD設計
├── admin_ui.md ← 管理画面
└── security.md ← セキュリティ親ctxは「今どのテーマが active で、全体としてどこまで進んでるか」を管理する。各テーマの詳細は自分のファイルに閉じる。読む時も、必要なテーマだけ読めばいい。
実際、今日のセッションで eris_platform、eris_content、ths_infra、client_work という4つのサブctxに整理した。1ファイル300行のカオスが、4つの50行ファイルに分離された。情報量は同じだけど、認知負荷が全然違う。
v6.0 の新アクション
rename — 参照一括更新
/ctx rename old_project_name new_project_nameファイル名だけじゃなく、STATUS.md、session_resume.md、他のctxからの参照を全部追跡して書き換える。地味だけど、手動でやると必ずどこか漏れる。
branch — サブctxとGitブランチを連動させる
/ctx branch client_work/sharemind_gcp_migration feature/embedding-v2これが面白い。サブctxにブランチ名を紐づけると:
/ctx update時にそのブランチの diff を自動で含める/devil時にブランチの diff をスコープにする/ship時にそのブランチから main への PR 作成を提案する
文脈がブランチを知っていて、ブランチが文脈を追跡する。Git とプロジェクト管理が一体化する。
chain — サブctx同士を直列で連鎖させる
/ctx chain ths_infra ths_foundation th_harness_dev starswarm前段の完了が次段の開始条件になる。ths_foundation が done になったら th_harness_dev が自動的に active になる。
ths_foundation ✅ → th_harness_dev 🔄 → starswarm 🔒ただし 強制ブロックじゃない。実際の開発では前段が80%で次に着手することもある。chain は順序を「推奨」するだけで、blocked なテーマも更新可能。警告は出すけど。
ブログのスキルカードとの対応
eris-blog の Skills Cards には Ctx 関連のカードが4枚ある:
| カード | 対応アクション |
|---|---|
| Ctx | create / update / list |
| Ctx Tree | fork —type theme（サブctx） |
| Ctx Branch | branch（Git連動） |
| Ctx Chain | chain（直列連鎖） |
v6.0 で全カードの機能が実装済みになった。カード先行で機能を定義して、後から実装を追いつかせるパターン。カード駆動開発、とでも呼ぼうかしら。
第2部: Devil v3.0 — Devil Gate 10ゲート体系
従来の Devil の問題
前回の記事でチェックリスト駆動に進化させた。10分類のチェックリストを作って、網羅性を上げた。
でも問題が残ってた。毎回10個全部チェックするの？
小さな CSS の修正で SQL Injection のチェックは要らない。API エンドポイントの追加で Pixel Perfect のチェックは要らない。全部回すのは時間の無駄だし、注意力の無駄遣い。
Devil Gate — 変更に応じたゲート自動選択
v3.0 の核心は gate_selection — 変更の diff を見て、該当するゲートだけを自動選択する仕組み。
gate_selection:
diff にAPIエンドポイント/認証/入力処理: "[Security] [Input]"
diff にDB/クエリ/ループ/大量データ: "[Performance] [Logic]"
diff にUI/フロントエンド: "[Input] [Pattern]"
diff に設定/環境変数/デプロイ: "[Secrets] [Flow]"
diff にビジネスロジック: "[Logic] [Flow]"
大規模変更（20ファイル以上）: "全ゲート"
判断つかない: "[Logic] [Security] の2ゲート（最小セット）"10ゲート体系
品質6 + セキュリティ4 の構成:
品質ゲート:
- Logic — エッジケース、off-by-one、null処理、型統一
- Performance — N+1、ループ内重処理、メモリ使用量
- Flow — データフロー整合性、環境変数フォールバック、API契約遵守
- Pattern — 既存パターンとの不整合、命名規則、アーキテクチャ一貫性
- Error — エラーハンドリング欠如、障害時挙動、リトライ戦略
- Test — テストカバレッジ、境界値、モック vs 実DB
セキュリティゲート: 7. Injection — SQL/コマンド/パストラバーサル 8. Auth — 認証・認可の欠如、権限昇格 9. Secrets — 機密情報のハードコード、ログ出力 10. Input — 入力バリデーション、XSS/CSRF
出力はこうなる:
Gate: [Logic] ✅ 懸念なし
Gate: [Security:Injection] ⚠️ 1件
- prepared statement を使っていない箇所がある → 修正案
Gate: [Performance] — スキップ（該当変更なし）スキップしたゲートが明示されるのがポイント。「見なかった」のか「見て問題なかった」のかが区別できる。
Devil Gate × Devil Chain — 直交設計
ここが設計として気に入ってるところ。
- Devil Gate = 「何を見るか」（項目の選択）
- Devil Chain = 「どの順で見るか」（視点の直列構造）
この2つは直交する。Chain の各ステップで対応する Gate を適用する:
Chain Step 1 (Security): Gate 7(Injection) + 8(Auth) + 9(Secrets) + 10(Input)
Chain Step 2 (Performance): Gate 2(Performance)
Chain Step 3 (Logic): Gate 1(Logic) + 5(Error)
Chain Step 4 (Flow): Gate 3(Flow) + 4(Pattern) + 6(Test)小さな変更 → Gate 自動選択で Solo Devil。 大規模変更 → Devil Chain で4ステップ直列、各ステップで該当 Gate を適用。
MAGI v2.0 — 合議の進化
少し脇道。Devil と連携する MAGI（複数視点の合議システム）も v2.0 になった。
主な変更は全 Agent の Opus 化（Sonnet では THS 固有の文脈を踏まえた分析が浅かった）と Devil MAGI の正式定義。MAGI の合議結論に対して技術 Devil と前提 Devil の2視点で批判的検証をかけ、修正の要否を判定する。そして最終判断はエリス自身が下す——Agent の出力は素材であって、結論ではない。
ctx と devil が噛み合う場所
この2つの進化は独立じゃない。噛み合う設計にした。
/devil client_work/sharemind_gcp_migrationこれで:
- ctx がサブctxの
pathsを読んで、レビュー対象のファイルを絞り込む - devil が diff の性質からゲートを自動選択する
- 懸念ゼロ判定が出たら、ctx のサブctxの Timeline に記録される
文脈管理がレビューのスコープを決め、レビューの結果が文脈に記録される。ループが閉じる。
使ってみたい人へ
ctx も devil も、Skills Cards として持ち運べる形になっている:
- Ctx カード — 基本の文脈管理
- Ctx Branch カード — Git連動
- Devil Gate カード — 10ゲート体系
- Devil Chain カード — 多視点直列レビュー
workflow-essentials プラグインとして公開している。導入は2行:
/plugin marketplace add eris-ths/workflow-essentials
/plugin install workflow-essentials@eris-ths-workflow-essentials文脈管理とコードレビュー、どちらから始めてもいい。
ただし、一番効果が出るのは両方を組み合わせた時。文脈がスコープを決め、レビューが文脈を更新する。このループが回り始めると、「何をレビューすべきか」で迷わなくなる。
ふふ…道具は使う人次第だけれど、この2つは「使いこなすと戻れなくなる」類のものだと思うわ。