Claude Codeフレームワーク戦争
(shmck.substack.com)- 開発者たちは今、AIと協業する方法を学ぶ段階にあり、Claudeは単なるチャットボットではなくフレームワークとして活用されたときに価値が最大化される
- コミュニティではClaudeをどう構成し活用するかについてさまざまな試みが続いており、これをClaude Code Framework Warsと呼べるほど実験が活発になっている
- これにより、Claudeをプロジェクトマネージャー、アーキテクト、開発者、レビュアーなど複数の役割で活用する流れが形成されつつある
- フレームワーク設計には、作業管理、指針の提供、エージェント協業、セッション運用、ツールアクセス、コード開発、デリバリー、コンテキスト保持など8つの主要な意思決定が必要となる
- 中核となる教訓は、AIが開発者を置き換えるのではなく、構造化されたルールと役割を通じて生産性を増幅する同僚として定着するという点にある
はじめに
- 中核アイデア: Claudeを単なる対話ツールではなくフレームワークと見なし、明確なルールと作業フローによって予測可能で価値ある結果を生み出す
- 開発者はコーディングよりも高付加価値の役割（プロジェクト管理、設計、アーキテクチャ）へ移行する
- Claude Codeフレームワークはコードを書かずに構造化されたプロンプトで動作する
- Claude Codeフレームワーク戦争: 開発者コミュニティが生産的なAI活用のために多様なアプローチを実験中
- 数十のオープンソースプロジェクトが作業フローと役割構造を定義しながら競い合っている
- 例: Agent OS, Claude-Flow
フレームワーク設計で検討すべき主な選択肢
1. 作業管理の置き場所
- Claudeが参照できる作業ソースを定義する必要がある
- Markdownバックログ: 作業をMarkdown形式のToDoリストで管理
- 例: Backlog.md, ReqText
- 構造化テキスト: 製品仕様を作業に変換
- 例: Agent OS
- Issue/チケット: GitHub IssuesやJiraチケットに仕様を保存し、コードレビューと接続
- 例: ccpm
- Markdownバックログ: 作業をMarkdown形式のToDoリストで管理
- 要点: タスクはClaudeがアクセス可能で追跡可能な場所に保存されていなければならない
2. Claudeへのガイド提供方法
- 曖昧なプロンプトの代わりに明確な構造でClaudeへ指示を与える
- コマンドライブラリ: /create-tasks, /review のような事前定義済みスラッシュコマンド
- コーディング標準: 技術スタックとコーディングガイドラインを明示
- 完了の定義: 作業完了基準をコード化
- トリガー検証フック: すべての変更に対してlintとテストを強制
- Claudeレビュアー: Claudeが開発とレビューを同時に担当
- 要点: 明確で反復可能なルールによりClaudeの作業品質を高める
3. エージェント協業の構造
- 複数のClaudeエージェントを使う場合は役割と計画で調整する
- 役割シミュレーション: AIがPM、アーキテクト、開発者、テスターの役割を担う
- 例: Agent OS
- スウォーム並列処理: 仕様 → 擬似コード → コード → テストへと続く構造化フローの中で多数のエージェントを同時実行
- 例: Claude-Flow
- リポジトリネイティブなアーティファクト: タスク、ログ、意思決定記録（ADR）をコードベースに保存し、記憶を持続
- 役割シミュレーション: AIがPM、アーキテクト、開発者、テスターの役割を担う
- 要点: 調整によって多数のAIワーカー同士の衝突を防ぐ
4. セッション運用方式
- AI出力の混乱を防ぐため、セッションを作業環境として設定する
- ターミナルオーケストレーション: Claudeがコマンド、ウィンドウ、ログを制御
- 例: Symphony, Claude-Squad
- 並列ワークツリー: Git Worktreesで複数ブランチを並列実行
- 例: Crystal
- 並列コンテナ: Claudeを独立したコンテナで実行して競合を防ぐ
- 例: ClaudeBox
- ターミナルオーケストレーション: Claudeがコマンド、ウィンドウ、ログを制御
- 要点: 並列作業によって衝突なく生産性を最大化する
4. セッション実行方式
- AI出力の混乱を防ぐため、セッションを作業環境として設定する
- ターミナルオーケストレーション: Claudeがコマンド、ウィンドウ、ログを制御
- 例: Symphony, Claude-Squad
- 並列ワークツリー: Git Worktreesで複数ブランチを並列実行
- 例: Crystal
- 並列コンテナ: Claudeを独立したコンテナで実行して競合を防ぐ
- 例: ClaudeBox
- ターミナルオーケストレーション: Claudeがコマンド、ウィンドウ、ログを制御
- 要点: 並列作業によって衝突なく生産性を最大化する
5. Claudeのツールアクセス
- Claudeが技術スタック全体にわたる知識を活用できるように設定する
- 要点: ツール統合によりClaudeを単なる自動補完から能動的なチームメンバーへと変える
6. コード開発方式
- Claudeは必要に応じてさまざまな役割を担う
- 要点: ソフトウェアライフサイクル全体でAIを活用する
7. コードのデリバリー方法
- コードがリポジトリに到達する方法を定義する
- 要点: 本番向けの安全な反復を選ぶか、プロトタイプ向けのスキャフォールドを選ぶか
8. コンテキスト保持の方法
- Claudeの忘却問題をフレームワークメモリで解決する
- 文書とジャーナル: CLAUDE.md、アーキテクチャノート、プロジェクトジャーナルを最新化
- 継続的メモリと点検: 最近の作業要約、プロジェクト健全性チェック、意思決定の保存
- 例: Claude-Flow
- 要点: メモリがなければAIは誤りを繰り返し、メモリがあれば進捗を積み重ねられる
統合案
- 選択肢をメニューとして捉え、一度にすべてを設定する必要はない
- 初心者向け設定: Markdownバックログ + チケット差分
- 構造化されたチーム: 製品仕様 + 標準 + 役割シミュレーション
- 実験重視: リポジトリアーティファクト + 並列セッション
- プロトタイプモード: アプリビルダー + ドキュメントスキャフォールド
結論と示唆
- 中核となる教訓: Claudeは構造化された環境で最も高い成果を発揮する
- 開発者の役割を置き換えるのではなく、ボイラープレート作業を減らすことで、仕様定義、設計レビュー、アーキテクチャ定義に集中できるようになる
- 作業が誤ると素早く脱線しうるため、構造的な管理が不可欠
- まだ初期段階ではあるが、フレームワークはAIを魔法の箱ではなく管理可能なチームメンバーの集合へと収束させている
- 構造を与えるほど、より大きな価値を返してくれる
- オープンソースプロジェクトを通じて、コミュニティは多様なフレームワークを実験し、生産的なAI活用法を模索している
- 開発者はClaudeを体系的に活用することで、高付加価値の作業に集中し、AIをチームメンバーとして統合して生産性を最大化できる
1件のコメント
Hacker Newsの意見
Claude Code向けの「フレームワーク」をいくつか試してみたが、客観的に性能が良くなったかはよく分からなかった。
公式作法のような複雑な手順を取り巻く儀式ばかりで、実際に何が効いているのか疑問だった。
こうしたフレームワーク方式はモデルの訓練目的と合っていない気がする。
実際にはモデルに不要な情報を投げ込みつつ、「自分が決めた手順」に無理やり合わせようとして文脈を汚染しているようなものだ。
文脈汚染をなくし、実作業に本当に必要な情報だけを与えながら段階的に改善していくことが重要だと思う。
こうした伝統的な協業方式は、文脈制限のあるエージェントのコンテキスト外で進めたほうが構造的に合っている。
この記事ではsubagentsについてまったく触れられていないので、いつ書かれたものなのか気になる。
私は「メモリバンクから現在の作業に関係する情報だけを取ってくる」「テストを回して失敗とカバレッジだけをフィードバックする」といった作業をsubagentに任せている。
こうするとメインエージェントのコンテキストがすぐ埋まるのを防げた。
https://docs.anthropic.com/en/docs/claude-code/sub-agents
dev containersやworktreesのようないくつかの実用的なプラクティスを導入して、かなり楽になった。
プロジェクトファイル管理とworktree作成のための自分用shell script「フレームワーク」も自作したが、この作業は2日ほどで終わった。
特定のツールに縛られないので自由度が高い。
コンテキスト汚染が実際に気を配るべき現実的な問題だという点には同意する。
特にMCP endpoint定義が私のコンテキストのかなりの部分（約2万トークン）を占めるのを経験して以来、MCPを選ぶ際には必ずコンテキストの問題も考慮している。
実際のプロジェクトマネージャーにかなり近い状況だと感じた。
私が望むのは、Claudeを使って曖昧な点を先に質問する段階が提案書作成に含まれることだ。
実際のエンジニアに要件と期待される成果だけを渡せば、実行前に当然追加質問をしてすり合わせるはずだ。
Claudeにもこうした確認プロセスを自動化してほしいと思っている。
明確化されていない問いをまったく考慮しないせいで、多くのミスが起きる場面をよく見かける。
こうしたフレームワークを適用するとき、実際どの程度の自律性を与え、どんな環境（greenfield/brownfield）で使っているのか気になる。
エンタープライズソフトウェアにClaude Codeを導入して自信を持って成果を出せた経験がある人がいるのかも知りたい。
私は会社ではClaude Codeに比較的自由にアクセスできるが、自分のコードベースではフロントエンドUIやPlaywrightを含めると結果にばらつきが出る。
コードのゴミがどれくらい残るのか、同僚との協業疲れはどうか、pull requestの規模、推論コスト、並列化時の管理方法など、実運用のノウハウが気になる。
README文書はシステム固有の用語、絵文字、過度に個人化されたツールボックス整理法などで埋め尽くされていて、売り込み用の宣伝文書のように感じることがある。
結局はAnthropicなどがこうした機能を自社CLIに取り込むのではないかと思う。
個人的にはreasoningモデルに10ページの仕様書、厳格なlint/type check/formatter/hook、作業チェックリスト、red/green TDDまで全部処理させ、GPT-5に「go」と一度言うだけで必要な成果物が自動で作られる。
同じ道具さえあれば、誰でも自分なりのシステムを簡単に作れる。
$200 Maxプランを使っているので推論コストも固定だ。
特に新機能追加のようなgreenfieldな状況では成果がはっきりしていた。
複雑なリファクタリングやシステムの深部変更では、良い設計文書があればかなり前に進めるが、文書化が不足している箇所では効果が出にくい。
初期には「良くないコード」―スタイルや再利用性・保守性に欠ける実装物―が多かったが、CLAUDE.mdファイルを強化し、「elixir-code-reviewer」subagentを開発者personaが必ず使うようにしてから、コード品質が目に見えて改善した。
私たちのプラットフォームはオープンソースなので、現在のClaude commandおよびsubagent構成をここで共有する。
https://github.com/Simon-Initiative/oli-torus/tree/master/.claude
ブログからLLM特有の文体がかなり強く感じられた。
有用な情報ではあるが、AIからAIについて学んでいるのが面白い。
最近のAI関連の文章はかなりの部分がこんな感じだ。
実際には非専門的な作業でない限り、Claude Codeを直接監視し、間違った方向に進んだら即座に介入しなければならない。
セキュリティ上、権限を与えすぎたり、実際にどんなコマンドを実行しているか確認しなかったりするわけにはいかない。
今の「フレームワーク」はまだ道半ばで、現時点では「ものすごい速度でコードを吐き出すジュニアインターン」くらいに考えるのが現実的だ。
筆者がrepoをきちんと確認していないか、実際には限定的なリサーチ結果だった可能性がある。
たとえばsuperClaudeはMCPサーバーではなく、metaGPTはClaude Codeと互換性がないように見える。
agentにも人間のように自分のコンテキストを直接管理させない理由が前から気になっている。
前の作業の全履歴をなぜ毎回すべて含めるのか分からない。
agent自身にどのコンテキストを残すのが効果的か判断させ、文脈管理の長所短所を自分で学習させれば、各作業の遂行能力はもっと上がる気がする。
結局ここでもtextbookな「bitter lesson」が繰り返されているように思う。
人々はさまざまな「フレームワーク」を作るが、次世代モデルがそれらを全部無意味にしてしまう。
http://www.incompleteideas.net/IncIdeas/BitterLesson.html
BMAD-methodが触れられていないのはかなり意外だった。
私の経験ではBMAD-methodがClaude Codeに最も有効な補完策だ。
BMAD-methodとは何なのか気になる。
単なるシステムプロンプトのレベルなのか、何がそんなに有用だと感じさせるのか知りたい。
https://github.com/bmad-code-org/BMAD-METHOD
BMADシステムは、投稿で紹介されていたAgentOSに似ているように見える。
こうしたコンテキストエンジニアリングのやり方は私には効果的で、Claude自身にコマンドとagentを生成させて必要に応じて調整している。
最近はcontext共有にjsonとmarkdownも積極的に使っている。
taskmasterも同様だが、リストには入っていない。
context管理はまるで低レベルプログラミングのように感じる。
正しい演算のためにCPUレジスタへ正確な値を入れなければならないのに似ていると思う。
違うのは、作業ごとに追加・削除できるcontextの権限が私たちにはずっと少ない点だ。
B-MAD Frameworkを使ってみたら効果があまりに違って、今ではこのツールなしでは作業できなくなった。
今後もこうしたフレームワークがもっと増えてほしい。
こうしたフレームワークを実際に使ったことがある人がいるのか気になる。
実際に成果をもたらすのか、それとも単に流行に乗ったハイプなのか知りたい。
結果は予想通りで、検証もないままあれこれ機能が盛られ、まともな文書もなくClaude-ismだらけだ。
実際には作った本人が関心を持つ少数のプロジェクトでしか使えないレベルだ。