仕事でClaudeを使っているなら、プロジェクト機能を活用している人も多いと思う。カスタムインストラクションにコンテキストを詰め込んで、ナレッジに資料を蓄積して、自然な会話で成果を出すスタイルだ。
私もそうやって本業のSalesforce案件を管理している。案件ごとにClaudeのプロジェクトを用意して、設計方針やシステムの状態を共有しながら進める。一問一答ではなく、文脈を積み上げていく使い方だ。
ただ先日、その設計が崩れた瞬間があった。
スライドが古い仕様で作られていた
クロージングに向けたプレゼン資料を作っていたときのことだ。「この部分、スライドにまとめて」とClaudeに依頼したら、出てきた内容が微妙にズレていた。
以前は検討していた仕様だったが、途中で方針が変わっていたはず。Claudeはその変更を知らないまま、古い情報でスライドを作っていた。
何往復かやり取りして、ようやく気づいた。「引継ぎ書を更新していなかった」というシンプルな話だった。
プロジェクトを作っただけでは、情報は更新されない
当たり前のことだけど、改めて実感させられた。
Claudeのプロジェクト機能は、情報を置いておける箱のようなものだ。カスタムインストラクションは設計の方針を伝える場所。ナレッジは資料を蓄積できる場所。ただし、会話の中で変化した情報はそこに自動では反映されない。
スレッドが続いているあいだは、Claudeはその会話の中で最新の状態を把握できている。でも、スレッドを切り替えたとき、引継ぎ書がなければ新しいスレッドは古い情報からスタートする。
今回の私はまさにこれだった。「プロジェクトを作ってある」という安心感があって、引継ぎ書の更新をさぼっていた。
Claudeに過去のやり取りを確認させ、自分で更新してもらった
最初は自分でスレッドを遡って確認しようとした。でも長くて面倒だった。
そこで試したのが「過去のやり取りを確認して、引継ぎ書の内容を最新の状態にしてほしい」という依頼だ。
これがあっさり解決した。Claudeは過去のスレッドを遡って、仕様が変わったタイミングを見つけ、引継ぎ書の該当箇所を更新してくれた。私は出力を確認して「これで合ってる」と返すだけだった。
自分が整理する手間が要らなかった点が、思っていたより楽だった。
引継ぎ書の更新は、設計の一部だった
「プロジェクト設計をしている」と思っていたけれど、それは設計の半分に過ぎなかったのだと今は思う。
もう半分は「情報の鮮度を維持する仕組み」だ。カスタムインストラクションは変わらない方針を置く場所で、引継ぎ書はリアルタイムで変化する状況を追いかける場所。この2つが機能してはじめて、Claudeとの協業が安定する。
引継ぎ書を更新するタイミングは、難しく考えなくていいと思っている。「大きな決定があったとき」と「スレッドを切り替えるとき」——この2つを守るだけで、今回みたいなズレはほぼ防げる。
更新を忘れても、Claudeに「過去のやり取りを確認して更新して」と頼めばいい。自分で全部管理しなくていいのも、AI協業の設計のひとつだと思う。
よくある質問
Q. 引継ぎ書はどんな形式で作るのが良いですか？
Markdownのテキストファイルで十分です。「このプロジェクトの現在の状態」がひとめで把握できれば形式は問わない。現在の仕様・決定済みの方針・変更の経緯——この3つが入っていれば機能します。
Q. Claudeに引継ぎ書を更新させるとき、どう依頼するの？
「このスレッドの過去のやり取りを確認して、引継ぎ書を最新の状態にしてほしい」と伝えるだけです。出力を確認して、内容が合っていれば保存する。私は会話が一区切りついたタイミングでこれをやるようにしています。
Q. ナレッジに資料を入れておけば引継ぎ書は不要ですか？
ナレッジは固定された資料の置き場で、進行中のプロジェクトの「今の状態」を追いかけるのには向いていません。引継ぎ書は動的な状態管理のためのもので、役割が違います。両方あると安心です。