Claude Codeは「分ける」より
「混ざらない設計」が大事

なぜ「境界」を設計するのか

AIエージェントの運用でつまずくとき、原因はプロンプト単体よりも作業場の切り方にあることが多い。同じように頼んでいるのに成果が安定しない、前回の続きから始めたら意図した文脈がない、複数の作業が混ざって判断がぶれる——これらは成果物の境界と会話の目的境界がずれているサインだ。

Claude Code はその構造が特に分かりやすい。セッション、ディレクトリ、CLAUDE.md、サブエージェント、worktree などを使って、作業の前提や担当範囲を見える形にしやすい。これはコードに限らず、文章・調査・資料づくりでも同じだ。

ここで整理したいのは、成果物の境界（人に見せる・共有する・あとで直す単位）と、目的の境界（1回の会話で一貫して追える作業意図）だ。リベシティ投稿、講座資料、家計分析、Webアプリのように成果物ごとに分ける方法もある。一方で、同じ大きなプロジェクトの中で役割分担できているなら、無理に細かく分けなくてもよい。大事なのは「分けること」ではなく「混ざらないこと」だ。

1つの作業場に集約する運用もある

長期的に同じテーマを育てたい場合は、1つの大きな作業場に情報を集約するメリットがある。過去の文脈を活かせるし、毎回同じ説明をしなくてよい。複数の作業が同じゴールへ向かっているなら、全体像も保ちやすい。

たとえば、事業全体、コミュニティ運営、継続的な学習ログ、長く育てるWebサービスのようなものは、毎回ゼロから会話を作り直すより、1つの作業場に知識を積み上げたほうが扱いやすいことがある。

ただし、何でも混ぜると逆に混乱する。まとめる運用では、サブエージェントに「人事部」「マーケティング部」「プログラミング部」のような役割を持たせたり、統括ディレクター役に全体の依頼を渡したりするなど、内部の構造が重要になる。作業ルール、担当範囲、判断基準を CLAUDE.md などに残しておくと、毎回の説明も減らせる。

つまり、1つにまとめる運用は「全部を雑に同じ場所へ入れる」ことではない。大きな作業場の中に、役割分担と引き継ぎの道筋を作る運用だ。

迷ったら、1成果物=1フォルダを目安にする

分ける運用は、特に初心者が迷子になりにくい。迷ったら、人に見せる・共有する・あとで直す単位を1フォルダに閉じるくらいを目安にするとよい。リベシティ投稿1本、講座資料1本、家計分析1本、Webアプリ1本、調査レポート1本——こうした短期の成果物は、それぞれ独立した葉フォルダにすると扱いやすい。

このとき重要なのは、共通メモを厚くしすぎないことだ。プロフィール、文体、禁止事項のように全テーマで使うものは薄く置く。一方で、家計相談の前提、講座資料の対象者、記事の主張、アプリの仕様は成果物ごとのメモに閉じる。関係ない前提をAIへ渡しすぎないためだ。

また、目的が変わったら、セッションを分けるか、引き継ぎを作る。「投稿Aと講座Bをまとめて整えて」よりも、「投稿Aの構成」「講座Bの導入」のように分けたほうが、ファイルの置き場所も明確になる。失敗しても影響範囲が小さいので、ブログ記事、調査メモ、小さなWebアプリ、検証用コードなどに向いている。

ただし、同じ大きなプロジェクト内で役割分担できているなら、無理に分けなくてもよい。分ける運用は正解というより、迷子にならないための手段の1つだ。

ディレクトリ構成と命名の例

分ける運用で迷ったら、トップレベルを 用途分類で固定し、その下を成果物の葉フォルダで増やす。分類を増やし始めると今度は人間が迷うので、まずは writing/・research/・life/・apps/・sandbox/ くらいから始める。

~/workspace/
├── writing/
│   ├── libecity-ai-agent-post/
│   │   ├── CLAUDE.md          ← 読者・文体・主張
│   │   ├── outline.md
│   │   └── draft.md
│   └── seminar-money-basics/
│       ├── CLAUDE.md
│       ├── slides-outline.md
│       └── handout.md
├── research/
│   └── ai-agent-session-study/
│       ├── CLAUDE.md
│       ├── questions.md
│       └── findings.md
├── life/
│   └── household-review-2026/
│       ├── CLAUDE.md
│       ├── expenses.csv
│       └── notes.md
├── apps/
│   ├── billing-admin/
│   │   ├── CLAUDE.md
│   │   ├── .claude/
│   │   │   ├── settings.json
│   │   │   ├── rules/
│   │   │   │   ├── testing.md
│   │   │   │   └── security.md
│   │   │   └── skills/
│   │   │       └── release/
│   │   │           └── SKILL.md
│   │   ├── src/
│   │   └── tests/
│   └── mobile-auth-poc/
└── sandbox/
    └── throwaway-2026-04-30/
        ├── NOTES.md
        └── tmp/

分類の意味はシンプルだ。writing/ は投稿・記事・講座資料、research/ は調査記録、life/ は家計・暮らし・学習ログ、apps/ はアプリやサイト、sandbox/ は破棄前提の実験。Claude Code はコード以外のフォルダでも問題なく動くので、文章や調査を無理にコードリポジトリに押し込む必要はない。

命名の目安

セッション名は、後から見て「何の会話だったか」が分かる名前にする。Claude Code なら -n や /rename で付けられる。ChatGPT や Claude でも会話タイトルを整えておくと再開が楽になる。main、temp、test2 のような曖昧な名前は避ける。

会話・セッションの区切り方

セッションは、短く分けるほどよいわけではない。文脈は増えるほど便利になる一方で、無関係な情報が混在するほどAIの判断はぼやける。迷いやすい人は、ライフサイクルを「調査→構成→作成→確認」に分けると、各フェーズの目的が見えやすくなる。

特に、目的が変わったと感じたら、そこで一度立ち止まる。投稿なら「論点出し」から「本文作成」へ、講座資料なら「対象者整理」から「スライド作成」へ、開発なら「仕様化」から「実装」へ進むタイミングだ。新しいセッションに移るか、続けるなら引き継ぎメモを作る。どちらでもよいが、次に何をしている会話なのかを見える状態にしておく。

コマンドと並列作業の使い分け

Claude Code のセッション操作コマンド

並列開発は worktree 付きマルチセッションで

開発で複数の修正を同時に試すなら、第一選択は worktree 付きマルチセッションだ。Claude Code は --worktree と Git worktree の両方を前提にしており、デスクトップ版も各並列セッションを独自の Git worktree に置く。

# worktree を切って新しいセッションを開始する
git worktree add ../billing-admin-auth-fix -b fix/auth-fix
cd ../billing-admin-auth-fix
claude -n billing-auth-fix

.env など Git で追跡されないファイルは .worktreeinclude でコピーできる。

# .worktreeinclude
.env
.env.local
config/secrets.json

※ .worktreeinclude などの細部の設定はバージョンによって挙動・名称が変わる可能性がある。使う前に公式ドキュメントで現行仕様を確認してほしい。

AI運用アンチパターン集

ここまでの原則を、実際によく起きる失敗に落とすとこうなる。名前を付けておくと、「いまキッチンシンクになってるね」のようにチームやコミュニティでも共有しやすい。

共通メモのテンプレートと移行計画

共通メモに書くべきなのは毎回再説明したくない事実だ。誰に向けた成果物か、何を大事にするか、使ってよい材料、避けたい表現、確認方法。Claude Code ではこれを CLAUDE.md に置ける。通常チャットでも、会話の最初に同じ情報を短く貼るだけで効く。

非エンジニア向け：最小メモ

# Outcome
- リベシティ向けの投稿を1本作る
- 読者: AI活用に興味はあるが、開発経験はない人
- 完成条件: 3分で読めて、今日から1つ試せる

# Tone
- 専門用語は使いすぎない
- 断定しすぎず、実体験ベースで書く
- 煽りよりも、落ち着いた実践知を優先する

# Materials
- 自分の体験メモ
- 参考記事URL
- 投稿したい結論

# Check
- 読者が最初に何をすればよいか分かるか
- 具体例が1つ以上あるか
- 個人情報や未確認情報が混ざっていないか

開発向け：最小実用版 CLAUDE.md

# Project overview
- Outcome: billing-admin web app
- Primary user: internal ops team
- Definition of done: lint green, affected tests green, PR-ready diff

# Tech stack
- TypeScript 5 / Node.js 22 / Next.js 15
- PostgreSQL + Prisma
- Vitest / Playwright

# Important directories
- src/app/        routes
- src/features/   domain features
- src/shared/     shared UI and utilities
- tests/          integration and e2e tests

# Common commands
- Install: pnpm install
- Dev: pnpm dev
- Typecheck: pnpm typecheck
- Lint: pnpm lint
- Test: pnpm test
- Build: pnpm build

# Rules
- Prefer existing patterns in src/features before adding abstractions.
- Do not edit generated files under src/generated/.
- Before finishing, run typecheck + affected tests + lint.
- Keep changes PR-sized. If scope grows, stop and propose a split.

# Compact Instructions
- Preserve changed files, failing tests, pending TODOs.
- Never drop required env vars or review comments to address.

散らかった環境からの移行フェーズ

一度に全部直そうとしない。まずは混ざって困っている場所を見つける。設定の作り込みは、その後でいい。

個人運用とコミュニティ運用の違い

個人運用とコミュニティ・チーム運用の差は、共有すべきものをどこに置くかに集約される。リベシティ内で誰かと一緒に投稿、講座、イベント、ツールを作るなら、AIへの頼み方も共有知識として扱ったほうがいい。

日々の運用チェックリスト