「Claude CodeとChatって何が違うんですか？」という質問をよく受ける。
機能の話をするなら長くなる。でも今日気づいたのは、役割が違うということだ。どちらが優れているかという話ではなく、「作る道具」と「評価する目」の使い分けの話。
この記事のポイント（2026年4月の実施記録）: Claude Codeで作業中のドキュメント・設計案・構想ファイルをClaude（claude.ai）にコンテキストゼロで投げ、評価を受けてCodeに持ち帰るフィードバックループを1往復走らせた。特別な設定は不要で、対象文書を貼り付けて評価を依頼するだけ。設計書やリファクタ方針など「自分が作ったものを客観視したい」場面に広く使える手法だ。
構想ファイルを育てていたら、評価できなくなった
今日のセッションは、Zenn Bookで出版している本の構想ファイルを見直す作業だった。
Claude Codeで素材ネタを集め、章立てをまとめ、maturityマップ（各章の素材が十分に揃っているかを一覧化したファイル）を更新した。気づけばファイルは相当なボリュームになっていた。何セッションもかけて育ててきた状態だ。
そこで問題が起きた。
自分で書いた構想を自分で評価できなくなっていた。
「この章タイトルは読者に伝わるか？」「第3部の素材は本当に足りているのか？」といった問いに対して、Claude Codeは「プロジェクト全体の文脈を知りすぎている」ためにフラットな目で見られない。私自身も長く関わりすぎて、客観的な評価ができなくなっていた。
そこで試したのが、Claude Chatへの丸投げだった。
Claude（claude.ai）を「コンテキストゼロの壁打ち相手」として使う理由
本記事では claude.ai のWebインターフェースを「Claude Chat」と表記する（公式呼称は「Claude」だが、Claude Codeと区別するための便宜的な表現）。
構想ファイルをClaude Chatに貼り付けて、一言だけ聞いた。
「この構想、読者視点で評価してください」
Chatは前のセッションのことを何も知らない。プロジェクトの歴史も、私の意図も、チームの構成も知らない。その「知らなさ」が、フレッシュな評価を生んだ。
返ってきた指摘は3つだった。
- 章タイトルが「オペレーション視点」になっている。読者が「自分ごと化」できる「価値視点」に変えたほうがいい
- 仮タイトルに「編集部」という言葉が入っているが、シリーズ全体は「チーム」という言葉で統一されている。整合を取るべき
- 第3部の素材が他の部に比べて薄い。ネタの充実が必要
これをClaude Codeに持ち帰って、改善タスクを実行した。
Claude Code×Chatのフィードバックループ構成
① Claude Code で構想ファイルを育てる（コンテキスト深・作業ツール）
↓
② Claude Chat に構想を投げ、評価を受ける（コンテキスト新鮮・外部レビュアー）
↓
③ Chatの評価結果（改善タスク指示書）を Claude Code で受け取る
↓
④ Claude Code で改善を実施
↓
⑤ 改善した構想ファイルをまた Claude Code で育てる（①に戻る）
「作る」と「評価する」を同じツールでやろうとすると、コンテキストが混入する。同じセッション、同じ文脈の中で評価させれば、「作った側のバイアス」がそのまま評価に乗ってしまう。
別のコンテキストを挟むことで、「この文脈を知らない人が初めて見たとき」の反応が得られる。これはレビュープロセスとして設計されたわけではなく、ツールの特性を利用した役割分担だ。
コードを書くエンジニアが使えるユースケース
「本を書いている人の話か」と感じた方へ。この手法が刺さるのはむしろコードを書く場面だ。
設計書・ADRのレビュー
新機能の設計書や技術的な意思決定記録（ADR）を書いた直後は、自分がその設計の「中にいる状態」になっている。Claude Codeはプロジェクト全体の文脈を知りすぎているため、設計のツメの甘さを指摘しにくい。このタイミングでClaude Chatに設計書を貼り付け、「この設計の穴を探してください」と聞くと、文脈を持たない第三者の視点が得られる。
リファクタ方針の壁打ち
「このモジュールを分割するか、このまま拡張するか迷っている」という判断に詰まったとき、コード全体を貼り付けて「どちらのアプローチに問題がありますか？」と聞く。Claude Code上でセッションを引きずって考え続けるより、文脈ゼロの評価の方がバイアスが乗らない。
今日試せるプロンプトテンプレート
評価を依頼するときに使っているプロンプトの例を2つ示す。
汎用評価（設計書・構想ファイル・仕様書）
以下のドキュメントを読んで、「この文脈を知らない開発者」の視点で評価してください。
見落としている論点・読者が疑問に思いそうな箇所・整合が取れていない部分を3点以内で挙げてください。
---
[ドキュメントをここに貼り付け]
リファクタ方針の壁打ち
以下のコードと、2つのリファクタ方針（A案・B案）を示します。
どちらのアプローチが中長期的に保守しやすいか、デメリットも含めて評価してください。
---
[コードと方針の説明をここに貼り付け]
「一言添えるだけで具体的な指摘が返ってくる」のは本当で、私の体験でも3〜5点の指摘がほぼ毎回返ってきた。ただし、プロンプトに「文脈を知らない視点で」という一文を入れると、評価の鋭さが上がる傾向がある。
なぜ同じClaudeなのに「深さ」と「新鮮さ」は別物なのか
Claude Codeは長い作業セッションを通じてプロジェクト全体の文脈を把握している。深い、継続的、実行力がある。Claude Chatは毎回フレッシュな視点で投げかけに応える。浅い、独立的、評価力がある。
どちらが優れているかではなく、役割が違う。
「コンテキストの深さ」は複雑な実行作業に有効で、「コンテキストの新鮮さ」は評価・レビューに有効だ。これを意識的に組み合わせると、同一ツールだけで作業し続けるより精度が上がる。
ただし、これは万能の解決策ではない。Chatへの貼り付けには手間がかかるし、構想ファイルが大きくなるとChatのコンテキストウィンドウに収まらなくなる可能性もある。今回は構想段階だったからうまく機能した、という条件がある。
Claude Chatを使った1往復で何が変わったか
今回のフィードバックループで起きた具体的な変化を記録しておく。
- 章タイトルが「オペレーション視点」から「価値視点」に改善された
- 仮タイトルの「編集部」→「チーム」でシリーズ整合性が取れた
- maturityマップで第3部の素材不足が数値として可視化された
いずれも「構想ファイルを一人で眺めていれば気づけたかもしれない」指摘だ。ただ、実際には気づけていなかった。外部の目を通すまで見えなかった。
**設計段階でのフィードバックは安い。**コードを書いた後、原稿を書いた後では修正コストが上がる。構想を固める段階で一往復させることの価値は、作業全体で見ると大きい。
Claude Chatに向いていない評価タスク
この手順を「いつでも使える万能技」と思わない方がいい。
今回うまくいったのは、評価対象が「構想ファイル（テキスト文書）」だったからだ。コードや複数ファイルにまたがる設計の評価をChatに投げても、コンテキストが足りなくてまともな評価は返ってこない。
また、Chatが返してくる評価は「文脈を知らない読者」の視点なので、プロジェクト固有の制約や過去の設計判断を加味できない。「第3部が薄い」という指摘は正しかったが、「なぜ薄いのか」という背景はChatには伝わっていない。評価結果をそのまま受け入れるのではなく、Code側の判断で取捨選択する必要がある。
Claude CodeとChatの使い分けまとめ
- Claude Codeは「作る道具」、Claude Chatは「評価する目」として使い分けられる
- コンテキストを意図的に分離することで、客観的なレビューを作り出せる
- ループを一往復させるだけで、構想段階の精度は上がる
- ただし評価対象が複雑なコードや設計の場合は向いていない
特殊な設定は不要だ。構想ファイルをChatに貼り付けて「評価してください」と一言添えるだけで始められる。
Claude Codeをすでに使っている人は、次の構想作業のときに一度試してみてほしい。
なお、ChatからCodeへの受け渡しはまだ手動で行っている。評価結果をコピーして持ち帰る、その手間が唯一の摩擦点だ。この受け渡しを仕組みとして解消するプロトコルについては、別の記事に書いた（公開後リンク追加予定）。
参考書籍
Claude Codeの使い方をもっと深く知りたい方には、こちらの書籍も参考になります。
この記事は はてなブログ からのクロスポストです。