Claude Code の Projects はどこで区切るか——使い続けて見えたトークンの行き先

会話を続けるか、作り直すか

前回の記事で Claude Code の Projects を使い始めてから数日がたち、使っているうちに一つ気になることが出てきました。同じリポジトリ群を使うなら、次の A 案と B 案のどちらがよいのか、という点です。

• A 案: プロジェクトの会話を、ずっと続けて使う
• B 案: どこかで作り直したり、コンテキストのコンパクションを気にしたりする

私の使い方では、作業はスレッドごとに別のコンテキストで進むので、プロジェクト本体の会話はそれほど汚れないと感じていました。そのため、同じプロジェクトでまったく違う作業もさせていて、困ったことはありません。ただ、それはトークンを湯水のように溶かしているだけかもしれない、とも思いました。

先に結論を書きます。公式ドキュメントには、次のように書かれています¹。

Scope the project to one stream of work you’ll keep adding to, such as everything it takes to keep one API under its latency target.

You don’t manage context windows in a project. Threads compact automatically, and the conversation works from recent messages, recent threads, and project memory rather than its full history, so it keeps going for as long as the project runs.

• 訳（1文目）: プロジェクトは、作業を足し続けていく1本の仕事の流れの単位で区切る。たとえば、1つの API をレイテンシの目標内に保つための作業すべて。
• 訳（2文目以降）: プロジェクトでは、コンテキストウィンドウを管理しなくてよい。スレッドは自動でコンパクションされ、会話は全履歴ではなく、直近のメッセージ、直近のスレッド、プロジェクトメモリーをもとに進むので、プロジェクトが続く限り会話も続けられる。

つまり、A 案で問題ないというのが公式の立場です。私の4プロジェクトの使用量を見ると、プロジェクト本体の会話（コーディネーター）が使った割合は0.1〜5.4%でした。消費の大半は、長く続いた一部のスレッドに集まっていました。気にするべきなのは、本体の会話の長さよりも、スレッドの長さのほうです。

公式が想定する管理の単位

公式ドキュメントは、プロジェクトとは何か、どんなときに作るかを次のように書いています¹。

A project is one ongoing conversation where Claude coordinates a stream of related work for you.

A project is worth creating when the work has a goal that outlasts one session and keeps producing tasks.

• 訳（1文目）: プロジェクトは、Claude が関連する仕事の流れをまとめて受け持つ、1本の続いていく会話である。
• 訳（2文目）: プロジェクトを作る価値があるのは、1セッションより長く続き、次々に作業を生むゴールがあるときである。

この記事では、この2文を「プロジェクトを作るかどうか」の基準として使います。公式が向いている仕事として挙げている4つの例は、次のとおりです¹。

反対に、プロジェクト以外のほうが合う例も挙がっています¹。

One task that fits in a session: “Fix the flaky login test.” Start a cloud session yourself.

One task that repeats on a schedule with no conversation around it: “Post a dependency report every Monday.” Create a routine on its own.

• 訳（1文目）: 1セッションに収まる1つの作業（例:「不安定なログインテストを直す」）は、自分でクラウドセッションを始める。
• 訳（2文目）: 会話を伴わず、決まった予定で繰り返す1つの作業（例:「毎週月曜に依存関係のレポートを投稿する」）は、ルーチンを単体で作る。

この記事では、単発の作業と、会話の要らない定時の繰り返しは、プロジェクトの外に置くものとして扱います。

冒頭で引いた1文目（作業を足し続けていく1本の仕事の流れで区切る）は、新規作成のダイアログに出てくる指針です¹。私はここから、分ける軸はリポジトリの束ではなく目的だ、と読みました。同じリポジトリを使う2つの目的は、2つのプロジェクトになりえます。

長く続けたときのコンテキスト

冒頭で引いた2文目（コンテキストウィンドウを管理しなくてよい）には、続きがあります¹。

Put anything that must never be dropped in project memory. If one thread outgrows its context, it shows Claude ran out of context on this turn.

If the message says the thread continues in a fresh session, it carries on by itself; otherwise ask Claude in the project conversation to start a new thread for the remaining work

• 訳（1段落目）: 決して落としてはいけないことは、プロジェクトメモリーに入れる。1本のスレッドがコンテキストを超えると、「Claude ran out of context on this turn」と表示される。
• 訳（2段落目、エラーの対処表より）: メッセージに、スレッドが新しいセッションで続くとあれば、スレッドはそのまま続く。そうでなければ、プロジェクトの会話で Claude に、残りの作業のための新しいスレッドを始めるよう頼む。

この記事では、冒頭の2文目とこの続きを合わせて、仕組みを次の2つに分けて読みます。

• スレッドは自動でコンパクションされます。1本のスレッドが文脈を使い切ったときは、新しいセッションで続きを引き継ぐか、新しいスレッドを立てます
• プロジェクト本体の会話は、全履歴ではなく、最近のメッセージ、最近のスレッド、プロジェクトメモリーから動きます。そのため、プロジェクトが続く限り会話も続けられます

裏返すと、メモリーに書いていない昔の会話は、本体からはいずれ見えなくなります。引用の1段落目が、消えては困ることをプロジェクトメモリーに入れるよう求めているのは、そのためだと読めます。

図の番号は、プロジェクト本体の会話が読むものと、読まなくなるものです。

1. 最近のメッセージ
2. 最近のスレッド。各スレッドは自分の会話を自分でコンパクションしながら続きます
3. プロジェクトメモリー
4. 古い履歴。メモリーに書かれていなければ、本体からはいずれ見えなくなります

スレッドをまたいで残る文脈について、公式は次のように書いています¹。

Project memory, project instructions, and the project’s repositories, files, and environment carry context across threads. You set each one once.

• 訳: プロジェクトメモリー、プロジェクトインストラクション、プロジェクトのリポジトリ・ファイル・環境が、スレッドをまたいで文脈を運ぶ。どれも一度設定すればよい。

公式の説明をもとに、この記事で扱う3つの置き場所を表にまとめます。

2つのメモの置き分けについては、次の1文があります¹。

Each cloud thread still reads those CLAUDE.md files from its clone when it starts, so put instructions about a repository in its CLAUDE.md and notes about the project in project memory.

• 訳: 各クラウドスレッドは、始まるときに複製したリポジトリの CLAUDE.md を読む。だから、リポジトリについての指示はその CLAUDE.md に、プロジェクトについてのメモはプロジェクトメモリーに置く。

この区別は、あとで出てくる「作り直すときの手間」に効いてきます。

4つのプロジェクトの使用量

ここからは私のアカウントの数字です。プロジェクト設定の Usage 画面には、スレッドごととコーディネーターのトークン数、その割合、キャッシュの内訳が出ます。2026年10月17日に、手元の4プロジェクトの画面を記録しました。記事には割合だけを載せ、プロジェクトの中身は役割だけを書きます。

コーディネーターの割合は6%未満

4つとも、コーディネーターの割合は0.1〜5.4%でした。一番高いのはスレッドが1本しかない B で、作業量が少ないぶん、本体の会話の固定費が目立っています。スレッドが9本ある A でも1.4%です。本体の会話がスレッドの報告を読んで次を決める分は、全体から見ると小さい、というのが今回の数字です。

代わりに目立つのは、最も大きいスレッド1本の割合です。スレッドが1本の B が95%なのは構造上そうなるとして、A でも39%、D では68%を1本が占めていました。D の68%は、前回の記事を書いたスレッドです。下書き、画像の生成、レビューの往復を1本のスレッドで続けたので、その分が積み上がっています。上位2本で見ると、C は87%、D は97%でした。

トークンの98%はキャッシュの読み取り

もう一つ目立つのは、トークンの中身です。4プロジェクトを合計すると、トークン数の97.9%がキャッシュの読み取りで、出力は0.3%しかありませんでした。

キャッシュの仕組みは、公式ドキュメントに次のように書かれています²。

Without caching, the API would reprocess your full history on every turn. With caching, it reuses what it already processed, bills the re-read at the cached token rate, and fully processes only what changed.

• 訳: キャッシュがなければ、API は毎ターン、履歴全体を処理し直す。キャッシュがあれば、すでに処理した分を使い回し、読み直した分をキャッシュの単価で課金し、変わった分だけを最後まで処理する。

この記事では、ここから次のように読みました。毎ターン会話全体が送り直され、変わっていない先頭部分はキャッシュから読まれます。処理し直す分は減りますが、読み直した量はキャッシュの読み取りとしてトークン数に数えられます。そのため、会話が長いスレッドほど1ターンごとに読み直す量が増えていき、最大のスレッドに消費が集まっていた理由もここにあると考えています。

ただし、トークン数の割合がそのまま負担の割合ではありません。API の料金表には、次の注記があります³。

Cache hits and refreshes on Claude Opus 5.5 and Claude Sonnet 5.5 are priced at 0.05x the base input price.

• 訳: Claude Opus 5.5 と Claude Sonnet 5.5 のキャッシュヒットとリフレッシュは、基本の入力単価の0.05倍で課金される。

スレッドがすべて Opus 5.5 で動いたと仮定し、この単価で4プロジェクトを換算すると、キャッシュ読み取りの割合は49%まで下がり、キャッシュ書き込みが37%、出力が14%になりました。プランの利用枠がこの比率で減るかどうかは公開されていないので、ここは API の単価を物差しに使った推定です。書き込みは1時間のキャッシュとして換算していて、5分のキャッシュが混ざっていれば書き込みの割合はもう少し下がります。

トークンを溶かしているのはどこか

公式ドキュメントは、プロジェクトで利用枠を使うものを3つ挙げています¹。

Running threads: each is a full session, and several can run at once.

The conversation: Claude uses tokens of its own reading what threads report and deciding what to do next.

Threads watching a pull request: an idle thread wakes up and uses your plan again when CI fails or a review comment arrives on its pull request.

• 訳（1つ目）: 動いているスレッド。1本ずつが完全なセッションで、何本も同時に動ける。
• 訳（2つ目）: 会話。Claude は、スレッドの報告を読んで次に何をするか決めるのに、自分のトークンを使う。
• 訳（3つ目）: PR を見張っているスレッド。止まっていたスレッドが、CI の失敗やレビューコメントで起き、また利用枠を使う。

今回の数字を当てはめると、2つ目の会話の分は、4プロジェクトで0.1〜5.4%でした。止まっているときについては、次の1文があります¹。

A project with no running threads, no watched pull requests, and no new messages doesn’t use your plan while it sits idle, and neither does an archived project.

• 訳: 動いているスレッドも、見張っている PR も、新しいメッセージもないプロジェクトは、止まっている間は利用枠を使わない。アーカイブしたプロジェクトも同じ。

この記事では、ここから、会話をずっと続けていること自体はコストにならない、と読みます。

一方で、公式が使用量を減らす方法の最初に挙げているのが、長く止まっていたスレッドの再開です¹。

A follow-up routed to a thread that has been idle longer than the cache lifetime, an hour on Pro and Max within your plan’s limits, re-reads that thread’s whole conversation before doing anything. For new work, asking Claude to start a fresh thread can use less than reviving a large old one.

• 訳: キャッシュの有効期間（Pro と Max のプラン内では1時間）より長く止まっていたスレッドに続きが回されると、そのスレッドは何かする前に会話全体を読み直す。新しい作業なら、古い大きなスレッドを起こすより、新しいスレッドを始めるよう頼んだほうが少なく済むことがある。

この記事では、これを「新しい作業は新しいスレッドで始める」という運用の根拠にします。

ほかに効くのは、モデルとエフォートの設定です¹。

A new project runs every thread on Opus at high effort, which draws on your plan fastest

• 訳: 新しいプロジェクトは、すべてのスレッドを Opus の high エフォートで動かす。これは利用枠を最も速く使う設定である。

ただし、2026年10月17日に私のプロジェクトの設定を開くと、スレッドのエフォート（Thread effort）の既定は Medium と表示されていました。本体の会話のエフォート（Coordinator effort）の既定は Low です。ドキュメントと画面がずれている可能性があるので、プロジェクトを作ったら一度この画面で確かめておくと確実です。

場所は、プロジェクトの設定（Project settings）の General にある Models の欄です。軽い作業が多いプロジェクトなら、ここでスレッドのモデルやエフォートを下げられます。

私の使い方に当てはめると、同じプロジェクトでまったく違う作業をさせても、本体の会話の割合は小さいままでした。トークンを溶かしていたのは、何日も続けた一部のスレッドのほうです。目的の違う作業を別のプロジェクトへ分けるより、作業が変わったら新しいスレッドで始めるほうが効きそうです。

ゴールを終えたら切り替えるか

公式ドキュメントには、ゴールを達成したらプロジェクトを作り直す、という記述はありません。ゴールとアーカイブについては、次のように書かれています¹。

Without a goal, Claude works from the tasks you send, and you can add a goal later in Project settings > General.

Archive: hides the project from the sidebar and archives its threads, which stops any thread that was running or watching a pull request. (…) To bring the project back, open it from the Projects page and click Unarchive.

• 訳（1文目）: ゴールがなければ、Claude は送られた作業をもとに動く。ゴールは後から Project settings > General で足せる。
• 訳（2文目）: アーカイブすると、プロジェクトはサイドバーから消え、スレッドもアーカイブされ、動いていたスレッドや PR を見張っていたスレッドは止まる。戻すときは Projects ページから開いて Unarchive を押す。

この記事では、ゴールは後から設定画面で足したり書き換えたりできるもの、使い終わったプロジェクトはアーカイブしておき、必要なら戻せるもの、として扱います。アーカイブしたプロジェクトが利用枠を使わないことは、前の節で引いたとおりです。

公式が想定する単位から考えると、切り替えの目安は会話の長さではなく、目的が変わったかどうかです。ここからは推測になりますが、次のどれかが変わるなら新しいプロジェクトにし、終わったほうはアーカイブするのが筋だと考えています。

• 全スレッドに配りたいインストラクションが変わる
• 毎回複製したいリポジトリの組み合わせが変わる
• メモリーに残っている決めごとが、次の仕事では邪魔になる

逆に、同じリポジトリ群で同じような種類の仕事を続けるなら、ゴールの1行を書き換えて同じプロジェクトを使い続けても、仕組み上の不都合は見当たりません。メモリーに積み上がった決めごとや落とし穴を、次の仕事でもそのまま使えます。

注意点として、公式は制約として次のように書いています¹。

A thread belongs to the one project that started it. You can’t move or copy a thread to another project, or move it out to stand alone. (…) You can’t merge two projects into one.

• 訳: スレッドは、それを始めた1つのプロジェクトに属する。スレッドを別のプロジェクトへ移したりコピーしたり、単独に切り出したりはできない。2つのプロジェクトを1つにまとめることもできない。

プロジェクトメモリーもプロジェクトごとなので、新しいプロジェクトに移るときは、残したい決めごとを持ち出す必要があります。

初期設定の手間を減らす

新しいプロジェクトを作るたびに設定画面を一つずつ埋めるのは手間です。公式ドキュメントから、手間を減らせるポイントをピックアップしました¹。

Most GitHub setup happens once, not per project.

Only the name is required, so you can create the project first and fill in the rest as the work takes shape.

Add it to the project, in the New project dialog, in Project settings > Environment, or by asking Claude in the conversation to add it to the project.

Continue as project creates a new project named after the session and opens it. Claude reads the session and posts Setup recommendations in the conversation for you to confirm.

Post Setup recommendations drawn from your recent cloud sessions: repositories to add, routines to create, and threads it could start.

• 訳（1文目）: GitHub の設定のほとんどは、プロジェクトごとではなく一度きりである。
• 訳（2文目）: 必須なのは名前だけなので、先にプロジェクトを作り、残りは仕事の形が見えてから埋めればよい。
• 訳（3文目）: リポジトリは、新規作成のダイアログ、Project settings > Environment、または会話の中で Claude に頼んで、プロジェクトに足せる。
• 訳（4文目）: Continue as project は、そのセッションの名前で新しいプロジェクトを作って開く。Claude がセッションを読み、確認用の設定案（Setup recommendations）を会話に出す。
• 訳（5文目、初めてのプロジェクトの場合）: 最近のクラウドセッションをもとに、足すリポジトリ、作るルーチン、始められるスレッドの設定案を出す。

この記事では、この5つを、作り直すときに手で埋める量を減らすポイントとして使います。

一番効くのは、ルールを置く場所を選ぶことだと考えています。前に引いたとおり、リポジトリの CLAUDE.md とスキルは、そのリポジトリを足したプロジェクトのどのスレッドにも付いてきます。プロジェクトインストラクションにはそのプロジェクト固有の短い指示だけを書き、リポジトリについてのルールは CLAUDE.md に寄せておけば、作り直すときに書き写す量が減ります。前回の記事でスレッドが迷わず動けたのも、記事の書き方や公開前のチェックをリポジトリの中に書いてあったからでした。

なお、2026年10月17日の時点で、プロジェクトの設定を複製する機能やテンプレートは、公式ドキュメントに見当たりませんでした。

区切るのは目的、気にするのはスレッドの長さ

調べた結果をまとめます。

• 公式の管理単位は、足し続ける1本の仕事の流れ。リポジトリの束ではなく、目的で分ける
• 本体の会話は最近のメッセージ、スレッド、メモリーから動くので、長く続けても支障なし。残したいことはメモリーへ
• 私の4プロジェクトでは、本体の会話の割合は0.1〜5.4%。消費の大半は長く続いたスレッドで、トークン数の98%はキャッシュの読み取りだった
• 1時間以上止まったスレッドを起こすより、新しい作業は新しいスレッドで始める
• ゴールを終えたら、目的が変わるときだけ新しいプロジェクトに移り、終わったほうはアーカイブする

私の運用は、今のところこのまま続けます。変えるのは、終わったスレッドに別の作業を頼まず、新しいスレッドで始めることです。次は、その運用で最大のスレッドの割合がどこまで下がるかを測ってみます。

参考文献