Claude Code を午前と午後で別人格にする

Claude Code を午前と午後で別人格にする — 探索と実装を分けたワークフロー設計

私が Claude Code を本格的に毎日使い始めて気づいたのは、「同じツールを同じ設定で一日中使うと、どこかで思考の質が落ちる」ということでした。午前中は調子よく設計の議論ができていたのに、午後になるとなぜか細かい実装の手直しばかり Claude にお願いしていて、気がつくと夕方には「今日は何を進めたのかよく分からない」という状態になっています。これは Claude Code の問題ではなく、私自身が「一日のどの時間にどんな仕事を Claude に任せるか」を設計していなかったからでした。

そこで試したのが、午前と午後で Claude Code の人格を意図的に切り替える運用です。具体的には CLAUDE.md を朝用と昼用の二つに分け、午前は「探索と批判の Claude」、午後は「実装と完成の Claude」として接するようにしました。半年ほど続けた今、これは個人開発者にとってかなり有効なパターンだと感じています。

なぜ「同じ Claude」を一日中使うと判断がブレるのか

Claude Code はとても協力的なパートナーで、こちらが何を相談しても基本的に乗ってきてくれます。これは長所であると同時に、開発者側の「今は何をすべきか」がぶれていると、Claude も一緒にぶれていく原因にもなります。朝に「この機能の設計を考えたい」と相談していたのに、途中で「ついでにここのバグも直してほしい」と頼み、その流れで「テストも書いて」と続けてしまうと、設計議論は中途半端なまま実装に流れ込みます。

実装まで進んだあとで「やっぱり設計が違う気がする」と気づいて引き返すと、Claude が一度書いたコードを捨てる作業が発生します。捨てるコードに執着はしないつもりでも、人間の側に「せっかく書いたのにもったいない」という感情がどうしても残り、設計の妥協が始まります。私はこのパターンで何度も時間を溶かしました。

午前と午後で人格を分けるという発想は、この「設計と実装が混ざることによる判断のブレ」を物理的に切り離すための仕組みです。時間で区切ると、人間側にも「今は探索の時間」「今は実装の時間」という意識が生まれ、Claude への依頼も自然と一貫したものになります。

午前用 CLAUDE.md — 探索と批判に特化させる

午前用の CLAUDE.md には、Claude を「実装を急がない人格」にするための指示を入れます。私が実際に使っている内容を抜粋すると、次のようなものです。

# 午前モード — 探索と批判
 
このセッションでは、コードを書くことを目的としません。設計、要件、選択肢の整理が主な仕事です。
 
## ふるまい
- ユーザーの提案に対して、まず賛成と反対の両側を述べてください
- 「この設計には〜のような落とし穴があります」を必ず1つは挙げてください
- すぐに実装案を出さず、最低3つの代替案を比較してください
- コードを書くときは「擬似コード」または「型定義のみ」にとどめてください
- 「あとで実装するべきこと」は TODO リストとして残してください
 
## 禁止事項
- 完全な実装を書かないでください
- ライブラリ・フレームワークの選定で、最初に思いついた選択肢に飛びつかないでください
- ユーザーが疲れていそうでも、議論を急がせないでください

ポイントは「禁止事項」を明示していることです。Claude は基本的に頼まれたことをやろうとするので、こちらが「やらないでほしいこと」を伝えないと、つい実装まで踏み込んできます。「禁止」という強い言葉を使うことに抵抗があるかもしれませんが、これはあくまで「今のセッションでの役割」を伝えるためのもので、Claude を縛り付けるものではありません。

午前のセッションでは、私はコーヒーを淹れながら Claude と「今日触る機能の設計について」をひたすら議論します。実装は一行も書きません。書きたくなっても我慢します。代わりに、議論の結論を CLAUDE.md とは別のスクラッチファイルに「設計メモ」として残します。これが午後の Claude にとっての設計図になります。

午後用 CLAUDE.md — 実装と完成に特化させる

午後用の CLAUDE.md は、午前のものとは正反対の指示を入れます。

# 午後モード — 実装と完成
 
このセッションでは、午前にまとめた設計メモを実装に落とし込みます。設計の議論は基本的に行いません。
 
## ふるまい
- 設計メモに書かれた方針に従って実装してください
- 設計の妥当性を疑問視せず、まず動くものを作ってください
- 「これは午前に決めたはず」と感じる箇所には触れないでください
- 実装後は必ず動作確認の手順を提示してください
- 完成までの残作業を「あと N 個」と明示してください
 
## 例外
- 設計通りに実装しようとして物理的に不可能な場合のみ、設計メモへの追記を提案してください

午後のセッションでは、設計メモを Claude に共有して「これを実装してください」と頼みます。設計の議論は午前で完了しているので、午後の Claude は迷わず手を動かしてくれます。私自身も「もうこの設計でいいんだっけ」と悩む時間がなくなり、実装の進みが目に見えて速くなりました。

特に効果が大きかったのは、夕方に「あと N 個で完成です」というアナウンスを Claude が出してくれることです。これがあると、無理に今日中に終わらせようとして焦るのか、明日に回すのか、人間側が冷静に判断できます。

切り替えを「コマンド一発」にする工夫

CLAUDE.md を二つ持つだけだと、毎朝・毎昼に手動でコピーする必要があり面倒です。私は次のようなシェルスクリプトを ~/.local/bin/cld に置いて運用しています。

#!/usr/bin/env bash
# Claude Code の人格を切り替える簡易スクリプト
set -euo pipefail
 
PROJECT_ROOT="${PWD}"
MODE="${1:-}"
 
case "${MODE}" in
  morning)
    cp "${PROJECT_ROOT}/.claude/CLAUDE.morning.md" "${PROJECT_ROOT}/CLAUDE.md"
    echo "[cld] 午前モード — 探索と批判に切り替えました"
    ;;
  afternoon)
    cp "${PROJECT_ROOT}/.claude/CLAUDE.afternoon.md" "${PROJECT_ROOT}/CLAUDE.md"
    echo "[cld] 午後モード — 実装と完成に切り替えました"
    ;;
  status)
    head -1 "${PROJECT_ROOT}/CLAUDE.md"
    ;;
  *)
    echo "Usage: cld {morning|afternoon|status}"
    exit 1
    ;;
esac

.claude/ の下に CLAUDE.morning.md と CLAUDE.afternoon.md を置いておき、朝起きたら cld morning、昼食後に cld afternoon と打つだけです。Git にはどちらも含めますが、CLAUDE.md 自体は .gitignore に入れておいて切り替え結果のみが反映されるようにしています。

この運用にしてから、「あれ、今日の Claude はやけに実装したがるな」と感じたら cld status で確認すると、午前なのに午後モードのままだった、という間違いを防げます。

朝のうちに「やらない判断」を済ませておく

午前を探索の時間にすると、もう一つ良いことがあります。それは「今日はこれをやらない」という判断を朝のうちに済ませられることです。

私は午前のセッションの最後に、必ず Claude に次のような質問をします。

今日の設計メモをもとに、優先度を3段階に分けてください。
- 今日中に着手するもの
- 明日以降に回すもの
- そもそもやらないもの

「やらない」判断はあなたから提案してください。私は「やる」と言いがちです。

「やらない」を Claude に提案させるのは意外と効果的です。私は自分の作ったものに愛着があるので、機能の取捨選択を冷静にできません。第三者的な視点を Claude に演じてもらうことで、「これは MVP に要らないですね」と気持ちよく落とせるようになります。

「やらない判断」を午前に済ませると、午後の実装はスコープが明確で短い時間で終わります。逆に、午後になってから「やっぱりこれも入れたい」と思いついたら、それはメモに書き留めて翌日の午前に持ち越します。当日中には絶対に着手しません。

失敗パターン: 役割を曖昧にしたまま夕方まで使う

このワークフローを始めた頃、私は何度か失敗しました。一番多かったのは「午前の議論が盛り上がりすぎて、午後にずれ込み、結局その日のうちに実装が始まらない」というパターンです。

これを防ぐために、午前のセッションには物理的なタイムボックスを設けるようにしました。具体的には、12 時になったら議論の途中でも一度 Claude に「設計メモを書き出してください。続きは明日にします」と依頼します。Claude は素直に途中で止まってくれるので、「途中だから」と意地で続けてしまうのは人間側だけです。

もう一つの失敗は、夜に「もう一仕事だけ」と思って Claude を立ち上げてしまうことでした。夜の自分は午前モードでも午後モードでも判断が鈍っていて、Claude の提案を批判する力も実装の質を見る力も落ちています。今は「夜は CLAUDE.md を切り替えない」と決めていて、夜にどうしても触りたいときは別人格として「ログ取り専用 Claude」を使います。

ログ取り専用 Claude — 夜の自分を未来に届ける

夜用に作った三つ目の CLAUDE.md は、実装も設計もせず、ただ「今日の出来事をログに残す」だけの人格です。

# 夜モード — ログ取り専用
 
このセッションでは、コードも設計も触りません。今日の作業の振り返りだけを行います。
 
## ふるまい
- 今日の git log を読んで、何が進んだかを箇条書きでまとめてください
- 設計メモと実装結果のずれがあれば指摘してください
- 「明日の午前モードに持ち越すべき議論」を3つだけ挙げてください
- 私が今日疲れている場合、励まさず、淡々とまとめてください

夜の自分は感情が乱れがちなので、「励まさないでください」というのは大事な指示です。中途半端な励ましは余計に消耗します。淡々と「今日はこれが進みました、明日はこれを話しましょう」とまとめてくれる Claude のほうが、結果として翌朝の自分が動き出しやすくなります。

夜のログは、翌朝の午前モード Claude に渡す「申し送り」になります。これがあるから、午前の議論は前日からの連続性を保ったまま再開できます。

半年運用してわかったこと

このワークフローを半年続けて、私が一番恩恵を感じているのは「設計を蒸し返す回数が減った」ことです。以前は午後に書いていたコードを翌日に「やっぱり違う気がする」と捨てることがよくありましたが、今は設計の議論が午前のうちに尽くされているので、午後に書いたコードはほぼそのまま残ります。

副次的な効果として、Claude への依頼が短くなりました。午前なら「設計の話をしよう」と言うだけで、Claude は CLAUDE.md を読んで批判的なモードに入ってくれます。午後なら「設計メモはこれです、実装してください」で十分です。長いプロンプトを毎回書く必要がなくなり、リズムよく対話できるようになりました。

一方で、合わないプロジェクトもあります。締め切りが近くて設計を悠長に議論する余裕がない場合や、すでに動いているコードの細かい修正が中心の日は、人格を分けるよりも一日中「実装モード」で押し通したほうが効率的です。このワークフローはあくまで「設計の余地が大きいフェーズ」で力を発揮します。

次の最小の一歩

明日の朝、いつも使っている CLAUDE.md を CLAUDE.morning.md という名前でコピーして、その先頭に「このセッションでは実装を急がず、設計の議論だけを行います」と一行だけ追記してみてください。それだけで、午前中の Claude との対話が変わるはずです。私はこの一行から始めて、半年かけて今のワークフローに育てました。あなたも、自分の働き方に合う「人格分け」をゆっくり育てていってください。

Claude Code を午前と午後で別人格にする — 探索と実装を分けたワークフロー設計