あなたは Claude Code のセッション開始から 40 分が経っています。何を決めたのか見失ってしまいました。
Claude は、すでに読んだファイルを読み直しています。いま作っているものが正しいのか分からず、確信を失ったのがいつなのかも分かりません。
これは Claude の問題ではありません。構造の問題です。だから私は FRAME を作りました。
FRAME とは
FRAME は、Claude Code に演じさせる役割と、そこで止めるためのゲートを与える一連の Markdown ファイルです。インストールは数ファイルをコピーするだけで完了します。設定も不要、ランタイムも不要、依存関係もありません。/frame load sw-development を実行すると、Claude Code は「いま Requirements Engineer（要件定義エンジニア）になった」ことを理解し、あなたが何を作るのか確認するまで一切前に進みません。
中核となる仕組みは「カートリッジ」です。カートリッジは、特定の種類の作業に対するフェーズ、役割、ゲートを定義します。エンジンはカートリッジを読み取り、それに応じてセッションを実行します。すべてのゲートでコントロールを維持してください。あなたの y なしに何も進みません。
以上です。あとは Markdown です。
同じタスク、2 回の実行
これは正直にテストしたかったので、同じバグ修正を 2 回実行しました。1 回は素の Claude Code、もう 1 回は FRAME の sw-development カートリッジです。同じプロンプト、同じコードベース、同じ開始ブランチ。
バグ: NOTEBOOKLM_DAILY_LIMIT が非数値の値、または 0 に設定されていると _get_daily_limit() がクラッシュします。修正してテストを追加してください。
素の Claude Code は関数を読み、修正を書き、テストを書き、コミットしました。約 1 分。質問は一切なし。修正は正しかったです。
FRAME は最初に質問から始めました。ブランチ名は？ 厳しい制約は？ 指示文に書かれた内容以外に、受け入れ基準はある？ 明示的に対象外にするものは？ そのうえで、1 つのファイルにも触れる前に SHAPE ブロックを出力しました:
Goal : Fix _get_daily_limit() crash - non-numeric or zero env var
Stack : Python 3.9+, pytest
Branch : fix/frame-daily-limit-validation
Constraints: none
Acceptance : - Non-numeric → returns 50, no exception
- Zero → returns 50, no exception
- Negative → returns 50, no exception
- Valid numeric → still works correctly
- At least one test per bad-input case
Out of scope: all other functions, no refactoring, no interface changes
あなたはこれを確認するか、押し返します。そうした後で初めてコードを書き始めます。
数分後、修正が反映されました。素の CC と同等の正確さです。ですが、その後 QA エンジニアがパスを実行しました。つまり、すべての受け入れ基準をテストに対応づけ、抜けがないかを確認したのです。そこで 1 つ指摘が出ました。空白のみの文字列（" "）がカバーされていない、と。元のブリーフにはなかった 4 つ目のテストです。
素の CC は、勘によってエッジケースを見つけました。FRAME は、プロセスによって見つけました。
正直な言い方
FRAME は、より良いコードを生み出したわけではありません。コードがやるべきことについての、ドキュメント化された契約を生み出したのです。何かを書き始める前に合意し、書いた後に検証します。
やるべきことが明確で、閉じたバグ修正のように「これをどうしたいか」がはっきり分かっている場合、素の Claude Code は打ち負かしにくいです。1 分 vs 10 分は、実際に大きな違いです。
FRAME が価値を発揮するのは、「done（完了）とは何か？」が着手前には自明でないときです。セッションが単なるタスクではなく、意思決定になっているとき。まだ作っていない選択に依存しているものをいまから作ろうとしていて、BUILD の途中で「間違ったものを作っていた」と気づきたくないとき。
10 分はオーバーヘッドではありません。作る前に、何を作るのかを合意するための作業です。正しいタスクなら、その 10 分間はセッション内でもっとも価値のある 10 分です。
その「正しいタスク」とは、要件が曖昧な機能。6 か月触っていないコードベース。見つけたすべての項目についてステークホルダーに説明が必要な監査。作成した計画が、作成時に同席していなかった誰かとの会話を乗り越えて生き残らなければならないプロジェクト計画。
そうしたセッションでは、FRAME が生成するドキュメントは副産物ではありません。目的そのものです。SHAPE アーカイブは、コードが書かれる前に合意された内容を記録します。フェーズごとのアーカイブは、各ゲートで決めたことを記録します。最終出力は、現場にいなかった誰かに渡して、その人が「何が起きて、なぜそうなったのか」を正確に再構成できるものになります。素の Claude Code は出力を出します。FRAME は出力と記録を出します。
仕組み
セッションには 5 つのフェーズがあります。SHAPE、BREAKDOWN、DESIGN、BUILD、CHECK。
SHAPE は、Requirements Engineer がゴール、スタック、制約、スコープを抽出するフェーズです。コードには一切触れません。出力は PROJECT.md で、他のことが起きる前にこれをあなたが確認します。
BREAKDOWN は、Orchestrator がゴールを作業ユニットに変換するフェーズです。1 つのコンテキストウィンドウ内で完了できるほど小さくし、依存関係で順序付けします。初めてユニット一覧が表示されたとき、なぜ FRAME がうまく機能するのかが分かりました。ゴールというレベルで圧倒されるように見えていたプロジェクトが、明確なスコープを持った「5 つのことのリスト」に、順番つきで変わるのです。Tur-Tur 効果——遠目には途方もなく大きく見えるものが、近づくと普通の手順にほどけるようなものです。
DESIGN は、Architect がユニット一覧を計画に落とし込むフェーズです。インターフェース、依存関係、順序付けの意思決定を行います。まだ何も作りません。開発者がファイルに触れる前に、実装の選択を明示的にしておくことが目的です。
BUILD は、ユニットを 1 つずつ実行します。ユニット間のゲートがあることで、状態を失わずに /clear でコンテキストをクリアできます。FRAME は止まる前に、すべてをファイルに書き込みます。
CHECK は、Code Reviewer と QA Engineer のパスを実行します。ここで受け入れ基準のテーブルが登場し、それが実際のテストカバレッジにマッピングされます。ギャップは本番ではなく、ここで露出します。
カートリッジは単なる Markdown です。Claude Code が従っているすべての指示を読めます。編集もできます。cartridge-creator カートリッジを使えば、1 時間で自分のカートリッジも作れます。
SPARC、claude-flow などと比べて何が違うのか
それらのツールは強力です。複数エージェントによるオーケストレーション、並列実行、XML で構造化されたプラン、そして完全なエコシステムを備えたフレームワークが欲しいなら、それらを使ってください。そういうために作られています。
FRAME はあえてもっと小さくしています。複数エージェントの複雑さはありません。ツール導入のオーバーヘッドもありません。XML もありません。エンジン全体は 1 つの Markdown ファイルです。設計原則は次のとおりです。インストーラが必要になる時点で、すでに複雑すぎる。
フレームワークが欲しいなら SPARC や claude-flow を使ってください。インフラなしで構造が欲しいなら、これがあなたのためのものです。
入手する
git clone https://github.com/SeriousByDesign/frame.git
cd frame
bash install.sh
次に、任意の Claude Code セッションで:
/frame load sw-development
FRAME はドメインに依存しません。エンジンは同じままで、カートリッジが作業の種類を定義します。最初に利用可能なのは sw-development、code-audit、blog-writing、linkedin-profile、project-planner、cartridge-creator です。どれも検証済みのワークフローなので、そのまま使うことも、変更することもできます。cartridge-creator で自分のカートリッジを作りましょう。
v0.3.0 ではさらに 4 つ追加されました。codebase-analysis（既存のコードベースから構造化されたドキュメントレポートを作成）、findings-to-tasks（監査の指摘を実行可能なタスクへ変換）、skill-creation（新しい Claude Code のスキルを設計し検証）、そして document-and-commit（FRAME の外で行われたコード変更をドキュメント化してコミットします）。
どこにあるか
これはv0.3.0です。実際のセッションで検証済み――ソフトウェア開発、コード監査、ブログ執筆、LinkedInプロフィール作成、カートリッジの作成、プロジェクト計画。主要な設計上の判断はすべて確定しています。
まだ終わっていません。実際の仕事で動かしてみたい人、壊れたときにイシューを上げてくれる人、どこに引っかかり（摩擦）があるのかを教えてくれる人を探しています。もしそれがあなたなら、このリポジトリはgithub.com/SeriousByDesign/frameです。試してみたいだけ？もちろん歓迎です。皆がそうです。
壊してみてください。それがv0.3.0の目的です。
