初級・導入直後
基本操作と CLAUDE.md を定着させたい
選ぶ根拠
基盤を先に安定させると、追加ツールが必要な課題とプロンプト・設定の課題を切り分けられる。
前提スキル
- ターミナルの基本操作
- Git の基本操作
避ける条件
- TDD やレビュー手順をすぐに統一する必要がある
- すでに複数エージェント運用が主要課題になっている
COMPARE / DECISION RUN
ウィザードで第一候補を絞り、前提・避ける条件・出典を同じ判断ログで確認。数値の事実と編集部の定性評価を混ぜずに読み進められます。
2 REPORTS · 4 TOOLS · VERIFIED 2026-07-28
$/compare --decide --with-evidence
01requirements.captureREADY
02candidate.rank4 TOOLS
03constraints.verifyDATED
✓decision trace available
選定ウィザード・編集部ルール
編集部評価・評価日:
基本操作と CLAUDE.md を定着させたい
選ぶ根拠
基盤を先に安定させると、追加ツールが必要な課題とプロンプト・設定の課題を切り分けられる。
前提スキル
避ける条件
基本操作は定着し、開発プロセスを揃えたい
選ぶ根拠
設計、TDD、体系的デバッグ、レビューを同じ流れに揃え、実装前後の手戻りを減らす課題に直接対応する。
前提スキル
避ける条件
マルチエージェント運用とチーム開発を設計したい
選ぶ根拠
並列実行が主目的なら、実行パイプラインを中心に据える OMC を第一候補にしやすい。統制と共有ハーネスが主目的なら ECC へ切り替える。
前提スキル
避ける条件
OMC小さな実行単位や単一チームで、タスク協調を主目的にする
ECC複数チームや複数ハーネスで、共通の運用面を揃える
OMC実行パイプラインとエージェント協調を中心に統制する
ECCrules、hooks、skills を含む共有ハーネスを中心に統制する
OMC並列オーケストレーション自体が導入理由
ECC並列性は包括的なハーネス機能の一部として扱う
OMC実行経路と plugin / CLI の更新管理に範囲を絞る
ECC広い機能面の選別、競合確認、共有設定の保守を引き受ける
事実スナップショット
バージョンと件数は別スナップショットです。各カードの「出典と取得日」で確認できます。
content/synced/changelog/2026-07-claude-code-2.1.220.mdcontent/synced/changelog/2026-07-superpowers-6.2.0.mddocs/content-verification-sp.mddocs/content-verification-sp.mddocs/content-verification-sp.mdcontent/synced/changelog/2026-07-omc-4.15.7.mddocs/content-verification-omc.mddocs/content-verification-omc.mdcontent/synced/changelog/2026-07-ecc-2.1.0.mdcontent/synced/changelog/2026-07-ecc-2.1.0.mdcontent/synced/changelog/2026-07-ecc-2.1.0.mdcontent/synced/changelog/2026-07-ecc-2.1.0.mddocs/content-verification-ecc.md出典のないトークン比率は撤去しました
ツール追加による消費量は、課題、モデル、権限、並列数、再試行条件で変わります。 共通条件の実測がリポジトリにないため、相対値や順位は掲載していません。
編集部の定性チェック
評価日:
CLI、plugin、hooks、設定ファイルの追加範囲を確認する。導入経路が増えるほど、更新と撤去の手順も増える。
同じ課題・モデル・権限・試行回数で比較し、実トークン数と完了までの手戻りを計測する。
権限、hooks の競合、設定の所有者、更新前検証、ロールバック責任者を決める。
判定基準: 金額やトークン数ではなく、導入経路、実行時の追加処理、設定競合、 撤去可能性を確認するための編集部チェックです。性能ベンチマークではありません。
点数や網羅率ではなく、各ツールがどの領域を設計の中心に置くかを分類しています。
評価日:
| 評価領域 | Claude Code | Superpowers | OMC | ECC |
|---|---|---|---|---|
| 基盤操作 | 中心 | 補完 | 補完 | 補完 |
| 開発規律 | 対応 | 中心 | 補完 | 対応 |
| 並列オーケストレーション | 対応 | 補完 | 中心 | 対応 |
| 共有ハーネス・統制 | 対応 | 非主眼 | 対応 | 中心 |
| セキュリティ運用 | 対応 | 非主眼 | 対応 | 中心 |
判定基準: catalog の説明・代表機能と同期済み機能カタログを読み、中心、対応、補完、 非主眼のいずれかに分類。
限界: 「非主眼」は非対応を意味しません。実行性能、品質、費用の優劣を測る評価でもありません。
「対応・一部対応・非対応」は、同期済み機能カタログを基にした定性判定です。 実行性能や品質のスコアではなく、「専用機能があるか」「基盤機能で代替するか」で分類しています。
評価日:
比較中
結論: 基盤操作を優先するか、開発規律を揃えるか
ファイルの作成、編集、リファクタリング
Grep/Glob/Read によるコードベース検索
コミット、ブランチ操作、PR作成
ターミナルベースのチャットインターフェース
独自のエージェント定義ファイルによる機能拡張
複数エージェントの並列起動と協調
エージェントチームの構築とタスク管理
autopilot / ultrawork 等の自律実行モード
テスト駆動開発のワークフロー強制
自動コードレビューと品質チェック
セキュリティ脆弱性のスキャンと修正提案
実装計画の自動策定とタスク分解
外部ツール・APIとの連携
ツール実行前後のカスタムフック
再利用可能なスキル定義と実行
プロジェクト間での設定同期
現在のボトルネックは何か
この図は全体像の補助です。最終判断は上部のウィザードで回答してください。
Claude Code
基盤の習熟と最小保守を優先
Superpowers
TDD・設計・レビューの規律を優先
oh-my-claudecode
小さな単位で並列オーケストレーションを優先
Everything Claude Code
複数チームの統制・共有ハーネスを優先