「続けて」しか打たない開発｜コストをかけずローカルLLMでサクッと作る、CLAUDE.md と doc/ の運用（RTX 5070 Ti 12GB）

コストをかけずに、ローカルLLMでサクッと何かを作りたい。使うのは RTX 5070 Ti Laptop（VRAM 12GB）を積んだノートのような、わりと普及している PC。人間は楽をして、「続けて」と打つだけで開発が進む。この記事は、それを成立させた構成の記録です。

やりたいことは1つです。ollama launch claude を設計者と製作者の2つ起動し、設計者に要件を伝えたら、あとは私が仲介役をやるだけでアプリができること。条件は、設計依頼・実装結果・テスト結果・レビューが全部ログとして残ること。何往復かして要件が満たされたら私が動かして OK か NG を判断し、NG の内容や追加の対応を設計者に依頼して、そのまま開発が続くこと。この4つが崩れなければ、モデルも手法も何でも構いません。

前の記事で、Ollama のローカルLLMに Claude Code をつなぎ、VSCode のターミナル2枚で設計と実装を分けるところまで書きました。今回はそれを 12GB のノートに載せ替え、人間の仕事を「続けて」の一言まで減らしています。

要点は、モデルを賢くするのではなく、CLAUDE.md と起動時の権限で「やっていいこと」を狭めることです。 小さいモデルでも、やることが狭ければ回ります。

この記事でできるようになること

設計者と製作者の2つの Claude Code を、doc/ フォルダの Markdown だけでやり取りさせる
設計依頼・実装結果・テスト結果・レビューの4つを、doc/ の1ファイルに時系列で残す
人間の指示を「続けて」の一言に固定し、各自が doc/ の状態から次の仕事を判断するようにする
設計者が doc/ 以外に書き込めないよう、起動オプションで権限を切る
人間の受け入れテストで出た NG と追加要件を、同じ doc/ の流れに戻す
VRAM 12GB のノートPCで、この構成を動かすモデルを選ぶ

CLAUDE.md は全文を載せます。自分のプロジェクトに合わせて末尾の技術仕様だけ書き換えれば、そのまま使えます。

前提条件・環境

ハード：RTX 5070 Ti Laptop GPU（VRAM 12GB）搭載の Windows ノート
推論：Ollama（ローカル）。Claude Code は ollama launch claude で接続する
エディタ：VSCode の統合ターミナルを左右2枚に分割（Ctrl + Shift + 5）
コンテキスト長は 64k 以上に設定済み（既定の 32k のままだと途中で前の内容を忘れます）

Ollama へのつなぎ方、コンテキスト長の上げ方、モデルの保管先の変更は前の記事に書いたので、ここでは繰り返しません。

12GBのノートで選べるモデル

前の記事に載せた4本は、すべて 12GB に収まりません。

前の記事のモデル	サイズ	12GB での結果
north-mini-code-1.0:q4_K_M	19GB	CPU/GPU分割
qwen3.8:27b	18GB	CPU/GPU分割
qwen3-coder:30b	19GB	CPU/GPU分割
devstral:24b	14GB	CPU/GPU分割

前の記事で自分に課した基準「ollama ps で 100% GPU でなければ落とす」を 12GB に当てると、この4本は全部脱落します。

代わりに候補になるのは次の3つです。

qwen3.6:35b（MoE・Ollama 版で 23GB・256K コンテキスト）… 品質はこの中で最上位。ただし 12GB には載らず、重みの半分以上が CPU 側に乗る
gemma4:12b（Q4 で約 8GB）… 64k のコンテキストを載せても 12GB に収まる。ツール呼び出しの出力が安定している
qwen3.5:9b（約 6GB）… 軽量の保険

私は qwen3.6:35b を選び、設計側と実装側の両方に同じモデルを使っています。

「載らないモデルを選ぶのか」と思われるはずです。dense（全パラメータが毎トークン動く）モデルが CPU にあふれると速度は桁で落ちますが、qwen3.6:35b は MoE で、1トークンあたり実際に動くのは 3B 前後です。あふれても速度の低下は数倍にとどまり、実用の範囲に入ります。

判断の分かれ目はシステムRAMです。RAM が 32GB 未満なら qwen3.6:35b は候補から外し、gemma4:12b にしてください。 2本目のモデルを入れても 12GB では入れ替えが起きるだけなので、設計側と実装側は同じモデルにして、役割は権限で分けます。同じモデルなら VRAM に載っている1本を両ペインで共有するので、ペインを行き来しても入れ替えが起きません。

Ollama の環境変数を3つ設定する

Windows の PowerShell で、ユーザー環境変数を3つ入れます。

[System.Environment]::SetEnvironmentVariable("OLLAMA_CONTEXT_LENGTH", "65536", "User")
[System.Environment]::SetEnvironmentVariable("OLLAMA_KV_CACHE_TYPE", "q4_0", "User")
[System.Environment]::SetEnvironmentVariable("OLLAMA_NUM_PARALLEL", "1", "User")

1行目はコンテキスト長 64k。2行目は KV キャッシュ（会話の途中経過を保持する領域）を 4bit に圧縮する設定で、長いコンテキストを載せたときの VRAM 消費を抑えます。3行目は同時に処理する要求を1本に絞る設定で、12GB では並列に動かす余裕がないため入れています。

PowerShell を再起動してから、モデルを取ります。

ollama pull qwen3.6:35b

設計者と製作者、2枚のターミナルの起動コマンド

前の記事では設計側を --permission-mode plan で起動していました。読めるが書けないモードです。

今回の構成では設計者が doc/ に指示書を書くので、plan モードでは足りません。代わりに --allowedTools で、確認なしに通す操作を列挙します。

左のペイン（設計者）です。

ollama launch claude --model qwen3.6:35b -- --permission-mode default --allowedTools "Read" "Glob" "Grep" "Write(doc/**)" "Edit(doc/**)"

右のペイン（製作者）です。

ollama launch claude --model qwen3.6:35b

設計者側の Edit(doc/**) は、doc/ 配下への書き込みだけを確認なしで通す指定です。それ以外の場所へ書こうとすると許可を求める画面が出ます。人間が「続けて」しか打たない運用では、許可の画面が出た時点で「設計者がソースを触ろうとした」と気づけます。 指示文で毎回「コードは書かないでください」と書く必要がなくなります。

なお Claude Code の公式ドキュメントによると、ファイルへの書き込みの判定に使われるのは Edit(パス) の規則だけで、Write(パス) は受け付けられても判定には使われません。Edit(doc/**) が Write を含む全部の編集ツールに効くので、上のコマンドの "Write(doc/**)" は無くても同じです。

-- の前が Ollama への引数、後ろが Claude Code への引数です。

CLAUDE.md の全文

Claude Code は起動時にプロジェクト直下の CLAUDE.md を読みます。役割・ファイルの形・報告の型は、全部ここで縛ります。

プロジェクトのフォルダで PowerShell を開き、次を1回で貼ります。

@'
# 開発ルール
このプロジェクトは、設計者と製作者の2つのターミナルで開発する。両者は doc/ フォルダの Markdown を通じてやり取りする。人間の指示は原則「続けて」の一言だけである。各自が doc/ の状態を見て、次にやるべきことを判断して実行する。
## doc/ のファイル
- ファイル名は `YYYY-MM-DD_NN_見出し.md`。NN は2桁の通し番号。doc/ 内の同日ファイルを確認し、最大の NN に 1 を足す。同日のファイルがなければ 01。
- 1ファイルに1指示。見出しは次の4段で構成する。
  - `## 指示`（設計者が書く）
  - `## テスト`（設計者が書く。合否の基準を具体的に箇条書きで）
  - `## 実装結果`（製作者が追記する）
  - `## レビュー`（設計者が追記する。冒頭に `結果: OK` または `結果: NG` を必ず書く）
## 設計者の役割
「続けて」と言われたら、doc/ の最新ファイルを読み、状態に応じて次のいずれか1つを行う。
- `## 実装結果` がない → 何もせず「製作者待ち」と1行で報告する。
- `## 実装結果` はあるが `## レビュー` がない → test/screenshot.png を読み、`## テスト` の各項目を判定し、`## レビュー` を追記する。人間から目視の報告があれば含める。NG なら、続けて次の番号のファイルを新規作成し、修正のための `## 指示` と `## テスト` を書く。
- `## レビュー` が `結果: OK` → 次の段階の `## 指示` と `## テスト` を次の番号のファイルに書く。
- ソースコードは書かない。指示は「どのファイルの、どこを、どう変えるか」が分かる粒度で書く。
- 全体のゴールと段階分けは doc/ の最初のファイル、または人間の最初の依頼に従う。
## 製作者の役割
「続けて」と言われたら、doc/ の最新ファイルを読み、状態に応じて次のいずれか1つを行う。
- `## 実装結果` がない → `## 指示` を実装し、`npm test` を実行し、NG なら直して OK になるまで繰り返し、`## 実装結果` を追記する。
- `## 実装結果` がすでにある → 何もせず「設計者待ち」と1行で報告する。
- 指示にない機能追加、ファイル作成、README の加筆は行わない。
- `## 実装結果` には、変更したファイル、変更の要点、`npm test` の結果、指示どおりにできなかった点を、合わせて6行以内で書く。
## 報告の型
設計者も製作者も、作業が終わったら画面への報告は次の3行だけにする。詳細は doc に書く。
- 状態: （何をしたか、または何待ちか）
- ファイル: （読み書きした doc のファイル名）
- 次: （人間が次にどちらのペインで「続けて」と打つべきか）
## テスト
- `npm test` は index.html をヘッドレスブラウザで開き、JSエラーの有無を確認し、test/screenshot.png を保存する。
- test/ 配下のテストは、設計者が `## テスト` で必要と判断したときに、製作者に追加を指示する。
'@ | Set-Content -Path CLAUDE.md -Encoding utf8

実際のファイルにはこの下に「## 技術仕様」として、使うライブラリとバージョン、外部アセットを使わないといった禁止事項を数行書いています。プロジェクトごとに変わる部分なので、ここでは省きました。

CLAUDE.md は起動時にしか読まれません。 書き換えたら、両方のペインで /exit してから起動し直します。

製作者の役割にある「指示にない機能追加、ファイル作成、README の加筆は行わない」の1行は、前の記事で実装側が実際にやったことを、そのまま禁止項目にしたものです。

doc/ に残る4つのログ

設計者と製作者は互いの画面を見ません。やり取りはすべて doc/ の Markdown 1ファイルの中で起きます。 1ファイルが1指示で、4つの見出しがそのまま4つのログになります。

## 指示（設計者）… 設計依頼の内容。どのファイルの、どこを、どう変えるか
## テスト（設計者）… 合否の基準。箇条書き
## 実装結果（製作者）… 変更したファイル、要点、npm test の結果、できなかった点。6行以内
## レビュー（設計者）… 結果: OK か 結果: NG と、各テスト項目の判定

設計者が ## 指示 と ## テスト を書き、製作者が ## 実装結果 を追記し、設計者が ## レビュー を追記して閉じます。NG なら設計者が次の番号のファイルを作って、修正の指示から同じ流れをやり直します。

ファイル名は日付と2桁の通し番号なので、doc/ を上から読めば、何を頼み、何ができ、何が通らず、どう直したかが時系列で追えます。チャットの画面を保存しなくても、開発の経緯が全部ファイルに残ります。

「続けて」だけで回る理由

人間の指示は「続けて」だけなので、誰が次に何をするかは doc/ の状態で決まります。

doc の状態	「続けて」で設計者がすること	「続けて」で製作者がすること
指示あり・実装結果なし	「製作者待ち」と1行報告	実装 → `npm test` → 実装結果を追記
実装結果あり・レビューなし	画像を読んでレビューを追記。NG なら次の doc に修正指示を書く	「設計者待ち」と1行報告
レビュー OK	次の段階の doc を書く	「設計者待ち」と1行報告

間違ったペインに「続けて」と打っても、「製作者待ち」「設計者待ち」の1行が返るだけで何も壊れません。順番を人間が覚えておく必要がないのが、この表のいちばんの効果です。

設計者のレビューは、製作者が npm test で保存したスクリーンショットを読んで行います。画面を見ないと判定できない項目（レイアウトの崩れ、色）は、人間が目視した結果を「続けて」に添えて渡します。

報告を3行に固定するのは CLAUDE.md で

ローカルモデルは、作業のあとに長い説明を返しがちです。画面を追う人間の負担がここで増えます。

Claude Code には出力スタイル（Output style）という設定があり、/config から Concise を選べば短くなります。ただし出力スタイルは「画面にどう見せるか」の設定で、doc の書き方や判断の手順は変わりません。

手順そのものを縛るのは CLAUDE.md の仕事です。だから報告の型も CLAUDE.md に入れました。

- 状態: （何をしたか、または何待ちか）
- ファイル: （読み書きした doc のファイル名）
- 次: （人間が次にどちらのペインで「続けて」と打つべきか）

3行目の「次:」が、人間への次の一手の指示です。人間はこれを読んで、言われたペインに「続けて」と打つだけになります。 詳細は doc に残っているので、画面の報告を読み飛ばしても後から追えます。

人間がやること：要件を伝える、受け入れテストをする

人間の仕事は、最初と節目の2か所にあります。

最初に、設計者に要件を伝えます。 何を作るか、どこまでを最初の段階にするかを、設計者に普通の文章で話します。設計者はそれを doc/ の最初のファイルに ## 指示 と ## テスト として書きます。CLAUDE.md に「全体のゴールと段階分けは doc/ の最初のファイル、または人間の最初の依頼に従う」と書いてあるので、以後の段階分けは設計者が自分で判断します。

節目で、自分の手で動かして OK か NG かを判断します。 設計者のレビューはスクリーンショットと npm test の範囲なので、実際に触った感触は人間しか判定できません。何往復かして要件が満たされたら、アプリを起動して確認します。

NG だったとき、追加でやりたいことが出たときは、その内容を設計者のペインに書いて「続けて」と打ちます。設計者はそれを次の番号のファイルに ## 指示 と ## テスト として書き、製作者に渡ります。人間の NG も追加要件も、同じ doc/ の流れに戻るので、ログから漏れません。 人間が製作者に直接指示することはありません。製作者への指示は必ず設計者の doc を通ります。

12GB で期待してよいこと、してはいけないこと

前の記事の「YOLO のセットアップ程度は難なくこなす」は、32GB で 19GB クラスのモデルを回した結果です。12GB では実装側のモデルが1段小さくなります。頼んでいないファイルを作る、README を盛る、といった脱線は起きやすくなる前提で見てください。

だからこそ、モデルの賢さに頼らず、CLAUDE.md の禁止項目と起動時の権限で縛ります。この構成は「小さいモデルでも回るように運用を設計する」という話です。

それでも複雑な多ファイル改修は破綻しやすいです。用途は、単機能の生成・小規模改修・オフラインでの検証に絞るのが現実的です。設計はローカル、実装は本物の Claude、という混在構成も選択肢に入れておいてください。 設計側は doc/ を書くだけなので、ローカルモデルで十分に務まります。

次に足す予定のもの（未検証）

ここから下は、まだ自分の環境で試していません。Claude Code の公式ドキュメントを読んで、次に足すと決めているものです。試していない手順なので、コマンドは載せません。

CLAUDE.md は「文脈」で、強制ではありません。 公式ドキュメントに、確実に止めたい操作は CLAUDE.md ではなく PreToolUse hook か permissions.deny を使え、と書かれています。小さいローカルモデルほど、この差が出ます。いまの CLAUDE.md で機械に任せられる行は、製作者の「npm test を実行し、NG なら直して OK になるまで繰り返す」です。ここは hook に移す候補です。

設計者の権限を「確認」から「拒否」に上げる。 --permission-mode dontAsk にすると、許可リストにない操作は確認画面を出さず自動で拒否されます。「続けて」しか打たない運用では、確認画面で止まるより、拒否されて「設計者待ち」で戻ってくるほうが手が止まりません。

doc が1つ閉じるごとに、両ペインで /clear する。 64k のコンテキストは、「続けて」を繰り返すうちに過去の doc とツールの結果で埋まります。状態は全部 doc/ にあり、プロジェクト直下の CLAUDE.md はセッション開始時に読み直されるので、/clear しても失うものがありません。

製作者に git commit を1行足す。 ## 実装結果 を書いたら doc のファイル名でコミットする、と製作者の役割に足せば、doc 1本とコミット1個が対応し、NG のときに戻す単位が揃います。

まとめ

人間の仕事は「要件を伝える」「続けてと打つ」「節目で自分の手でテストする」の3つ。 誰が次に何をするかは doc/ の状態で決まり、順番を覚える必要がありません
設計依頼・テスト基準・実装結果・レビューの4つが、doc/ の1ファイルに時系列で残る。 人間の NG と追加要件も、設計者の次の doc として同じ流れに戻ります
設計者は --allowedTools で doc/ 配下だけ書ける。 ソースを触ろうとすると許可画面が出るので、その場で気づけます
12GB のノートでは qwen3.6:35b（RAM 32GB 以上）か gemma4:12b。 前の記事の4本は全部 CPU にあふれます

CLAUDE.md をそのまま貼って、ollama launch claude を2枚起こせば、この構成は動きます。モデルが新しくなっても、変えるのは --model の1か所だけです。

「ローカルモデルの暴走を運用で止めたい」「手元の GPU でどこまで回せるか見立てがほしい」という方は、無料の30分オンライン診断で状況をお伺いします。

この記事の技術を、現場で実装したい方へ

AI×IoTの技術顧問として、月額契約で継続伴走しています。PoC設計・技術判断・組織設計・ベンダー管理・実装支援まで、現場で動くまで一緒に進めます。受託開発（請負）ではありません。

→ AI技術顧問サービスの詳細／無料30分オンライン診断／料金一覧