Claudeのプロンプト再利用|保存先と失敗を防ぐコツ

Claudeのプロンプト再利用|保存先と失敗を防ぐコツ

こんにちは。Osukeラーニング、運営者の「osuke」です。

先週はうまく書けた週報なのに、新しい会話を開くと、また文体や見出しから説明し直す。保存したプロンプトを貼ったら、今度は先週の数値まで混ざってしまう。Claudeのプロンプトを再利用したいときは、長い指示を丸ごと保存する前に、中身を分けておくのが大切です。

この記事では、毎回使うルール、案件の前提、今回だけの入力を切り分け、全体指示・Projects・Skillsへ置く判断基準をまとめます。Stylesの古い解説を読んで、画面の違いに迷っている場合の考え方も扱います。

仕様は2026年9月29日に公式ヘルプを確認しました。Xで確認した公開投稿は利用者の意見として紹介し、私自身の利用体験や効果測定とは区別しています。本文の週報と確認用データは、説明のために作った架空の例です。

記事のポイント

  • プロンプトの固定部分と毎回変える部分の分け方
  • 全体指示・Projects・Skillsの保存先選び
  • そのまま調整して使える週報の指示テンプレート
  • 反映されない場合の確認と更新・共有の注意点

Claudeのプロンプトを保存する

どの機能が一番高機能かではなく、どの範囲で同じ指示を使いたいかから選びます。まずは一つの仕事を例に、残すものと毎回渡すものを整理しましょう。

良い指示は固定と変動に分ける

保存する前に、プロンプトへ三つの目印を付けてみてください。毎回守る書き方は「固定」、今回の素材は「変動」、仕上がりの確認項目は「合格条件」です。たとえば週報なら、見出しの順序は固定できますが、対象週や実績は変わります。ここを混ぜたまま複製すると、文章は整っているのに古い情報が残るという、気づきにくい失敗につながります。再利用したいのは前回の答えではなく、答えを作るときの条件なんですね。

架空の例では、「上司向けに、実績・課題・来週の予定の順で書く」は固定部分です。「今週は問い合わせ対応が12件、来週はFAQを見直す」は今回の入力です。そして「来週の予定を今週の実績に入れない」が合格条件になります。三つを分けておけば、来週は入力欄だけを差し替えられます。担当者名や日付を残す必要がある場合も、固定ルールの文章へ埋め込まず、毎回確認する入力欄に置くほうが変更漏れを見つけやすくなります。

  • 固定:読み手、見出し、文体、情報の扱い方
  • 変動:対象期間、今回の数値、添付資料、依頼の目的
  • 合格条件:元資料との一致、未確定事項の扱い、出力形式
  • 保存する前に、前回だけの固有名詞や日付を探す

「分ける作業のほうが面倒」と感じるなら、今ある指示を一つだけ選べば十分です。ここでは、次の二回も同じ型で頼みそうかを、保存するかどうかの目安にします。これは公式の基準ではなく、準備に時間をかけすぎないための私の提案です。一回限りの相談なら、わざわざスキルを作る必要はありません。逆に毎週同じ訂正をしているなら、その訂正を固定ルールへ移す価値があります。保存先を決める前に、まず何を繰り返しているかを見つけましょう。

この三分割は、指示どおりの回答を保証する仕組みではありません。使い回した結果を人が確認しやすくする設計です。最初はメモ帳などに「週報用・初版」として残し、入力欄を空にしたコピーを使ってください。前回の完成文を見本にするなら、文体の参考であって今回の事実ではないと添えます。見本と素材の境界が見えれば、誤りが出たときも、文章の書き方が悪いのか、渡した情報が古いのかを切り分けやすくなります。

全体指示は共通の好みだけ

Claudeの公式ヘルプで案内されている「Instructions for Claude」は、アカウント全体の会話へ適用する指示です。毎回伝えたい言語や説明の好みを置く候補になります。ただし、適用範囲が広いことと、たくさん書くほど便利なことは別です。週報の細かな型や特定の取引先の話まで入れると、別の相談にもその前提を持ち込みかねません。私は保存する内容を選ぶとき、「料理の相談でも、この指示があって困らないか」と考えると整理しやすいと思います。

たとえば「原則として日本語で説明する」「専門用語には短い説明を添える」は広く使える好みです。一方、「必ず実績・課題・予定の三部構成にする」は週報向けの条件なので、全体指示に置くと用途が狭すぎます。「いつも短く」と「必ず背景を詳しく」の両方を残す場合も、どちらを優先するか迷う指示になります。短さを求めるなら、最初に要点を示し、詳しい説明が必要な場合は後ろへ分けるなど、両立する書き方へ直すとよいですね。

残したい内容保存先の候補置かないほうがよいもの
会話全体の言語・説明の好み全体指示一つの案件だけの数値や様式
特定案件の目的・読者・資料Project無関係な顧客の情報
何度も使う作業手順Skill毎回変わる実績の埋め込み
今回の素材・締切・追加条件その回の依頼文次回も同じだという思い込み

この表は保存先を選ぶための編集上の整理です。各機能の指示がぶつかった場合に、必ずこの順番で処理されるという優先順位表ではありません。複数の場所へ同じ文章をコピーすると、片方だけ修正して古い指示が残りやすくなります。たとえば全体指示と週報Skillの両方に文字数を書いているなら、まずどちらで管理するのかを決めます。使う場所が少ないほど、問題が出たときの見直しも小さく済みます。

  • 全体指示には、案件をまたいでも使う好みを残す
  • 例外が多いルールは、その案件や依頼文へ移す
  • 同じルールを複数の場所で重複管理しない

設定を変えたら、週報だけでなく別の軽い質問も一つ試してください。目的は、週報が良くなった代わりに日常の質問まで不自然な形式になっていないかを見ることです。たとえば説明を短くした設定なら、短い用語説明と、理由を詳しく知りたい質問を比較します。一度で万能な指示を完成させようとせず、不要な制約を減らす方向で整えていきましょう。個人名や連絡先など、毎回必要ではない情報を全体指示へ書き込む必要もありません。

Projectsは案件の前提を置く

Projectsは、同じ案件の目的や資料をまとめ、会話の前提をそろえたい場合に向いています。ここで扱うのは主に既存のチャット用Projectです。2026年9月29日時点では、新しいProjectsのベータ版もClaude Codeの一部利用者から段階的に提供されていますが、画面や作業方式を同じものとして説明しません。指示の再利用で大切なのは、新旧どちらでも「この案件にだけ必要な前提」を、全体の好みから切り離して管理するという考え方です。

架空の社内広報Projectなら、「読者は社内の非技術職」「未公開の売上数字は本文へ出さない」「用語表の正式名称を使う」といった案件固有の条件を置きます。一方、その週の記事のテーマや担当者から届いた原稿は、今回の素材として渡します。Projectへ資料を集めても、どの資料を今回使うのかが曖昧なら、期待する結果には近づきません。資料名と用途を組にして示し、古い版があるなら現行版との違いも整理しておきましょう。

  • Project指示:案件の目的、対象読者、守るべき条件
  • 参考資料:用語表、現行のルール、必要な背景
  • 今回の依頼:使う資料、出してほしいもの、今回だけの条件
  • 同じ資料の旧版と新版を、区別せず並べない

「Projectに入れれば、前の会話を全部正確に引き継いでくれる」と期待しすぎないことも大切です。過去の回答にだけ書いた修正が、管理している指示へ反映されたかは別に確認します。たとえば前回「略語を使わないで」と伝えたのに、Project指示には何も書いていなければ、そのルールをどこへ残したかが分かりません。重要な訂正は、その会話を探し直すのではなく、今後も適用する指示として明文化しておくと管理しやすくなります。

作成画面や資料の入れ方がまだ不安な場合は、ClaudeのProjectsの使い方と設定の注意点で基本を確認してください。本記事ではボタン操作の繰り返しより、保存する情報の分担を重視しています。まず一つのProjectについて、目的を一文、読者を一文、外せない条件を数項目に整理するところから始めます。説明のために資料を増やし続けるのではなく、どの判断に必要なのかを説明できる資料だけを残すのが出発点です。

Stylesの古い手順に注意

ClaudeのStylesは、文章のトーンや構成を自分向けに整える機能として2024年に発表されました。そのため、以前の記事にはStylesを選ぶメニューや文体見本の登録方法が載っています。ただし、2026年9月29日に確認した現行のパーソナライズヘルプは、全体指示・Project指示・Skillsを中心に説明しています。古い解説と自分の画面が違っていても、操作を間違えたとは限りません。過去の機能紹介と、今のアカウントで使える手順を分けて読む必要があります。

ここでは、Stylesが全利用者から一律に消えたとも、保存したスタイルが自動でSkillへ移ったとも断定しません。今回の確認だけでは、その範囲まで確かめられていないからです。まず自分が変えたいのが「文章の見た目」なのか、「仕事の進め方」なのかを決めてください。丁寧な口調、短い段落、専門用語の説明といった文体の希望なら、現在利用できる指示欄やSkillsの案内で同じ目的を実現できるかを確認する、という順序が分かりやすいと思います。

  • 古い画面のボタンを、現在もあると決めつけない
  • 文体の見本と、今回使う事実の資料を区別する
  • Stylesの表示が違う場合は、現行のパーソナライズ案内を確認する
  • 文章の好みだけなら、最初から複雑な手順を作らない

たとえば、やわらかい社内向けの文章にしたい場合を考えます。「親しみやすく」とだけ書くより、「です・ます調で、専門用語は最初の一回だけ説明し、相手を急かす表現を避ける」と具体化できます。この文体ルールには、売上目標や今月の開催日を含めません。見本として先月の案内文を渡すなら、「文体だけを参考にし、日付や事実は今回の入力を使う」と区別します。これはStyles専用の操作ではなく、文体を再利用するときの指示の作り方です。

文体だけで内容の正しさまで変えようとしないことも重要です。丁寧な表現であっても、入力していない数値が混ざれば業務では使えません。試すときは、同じ短い素材を使って、文体の条件を加える前後で比べてください。読みやすさに加えて、事実が増減していないかを見ると、見本に引っ張られた問題にも気づけます。設定の名前にこだわるより、残したい表現と変えてはいけない内容を別々に説明できる状態を目指しましょう。

Skillsは繰り返す手順に使う

Skillsは、必要なときに読み込む指示や資料、場合によってはスクリプトをまとめる仕組みです。たとえば週報の文章を毎回同じ考え方で整理したいなら、入力の確認から出力までの手順を残す候補になります。現行ヘルプではFree・Pro・Max・Team・Enterpriseが対象とされ、コード実行機能の有効化が必要です。ただし、文章だけの簡単なSkillでも構いません。機能を有効にする条件と、自分でプログラムを作らなければいけないという話は別です。

Projectが「この案件は何か」を伝える場所なら、Skillは「この種類の仕事をどう進めるか」をまとめる場所、と考えると役割を分けやすくなります。たとえば別々の案件でも、週報を実績・課題・予定へ整理する手順は共通化できます。ただし、Skillを作っただけで外部サービスの権限が増えるわけではありません。メールの文章を整える手順と、実際にメールを送る接続や許可は別です。最初は文章の整理までに範囲を絞ると、確認する対象を小さくできます。

  • 向く用途:同じ入力の種類と出力の型を繰り返す仕事
  • 最初の範囲:一つの仕事、短い指示、必要な見本だけ
  • 避ける設計:文章作成・集計・送信を無条件で一括実行する
  • 起動の条件と、完成したかの条件を両方決める

公式の作成ガイドでは、どのような場合に使うかを説明へ書き、焦点を絞って試すことが勧められています。名前を「便利な仕事用」とするだけでは、用途が伝わりにくいですね。独自の例なら、「週報の素材から、実績・課題・来週の予定を整理する。企画の発案や顧客への送信は扱わない」といった説明にします。仕事の対象がはっきりすると、呼ばれなかったときだけでなく、関係ない場面で適用されたときも、何を修正するか判断しやすくなります。

保存場所や有効化の表示は、利用環境と組織の設定によって確認が必要です。現行案内ではCustomizeのSkillsから管理しますが、項目が見当たらないからといって、すぐに上位プランへ変更する必要はありません。利用条件や管理者設定を先に確かめましょう。基本的な役割は、Claude公式ヘルプ「What are skills?」でも確認できます。便利さを試す段階では、第三者の大量のスキルをまとめて入れるより、自分で中身を説明できる一つを選ぶほうが安心です。

Claudeのプロンプト再利用の注意点

保存できたら終わりではありません。別の入力でも意図を保てるか、使うべきでない仕事にまで広がらないかを確認します。ここからは、そのまま調整できる例と、失敗したときの戻り方をまとめます。

週報テンプレートの作り方

最初のテンプレートは、回答を見て自分で正誤を確かめられる仕事で作るのがおすすめです。ここでは架空の週報を使います。ねらいは、立派な文章を一度で作ることではなく、毎週変わる事実と、毎週守る型を分離することです。下の例は私が説明用に作ったもので、Claudeで実測した成功例ではありません。自分の職場の様式に合わせて、対象読者や見出しを変更してから試してください。実際の社内情報を入れる前に、入力してよい範囲も確認します。

コピーして調整する指示例

  • 目的:上司が今週の状況と次週の予定を区別できる週報を作る
  • 形式:日本語で、実績・課題・来週の予定の順にまとめる
  • 根拠:今回の入力にある事実だけを使う。前回の見本から数値を転記しない
  • 不足:数値や予定が分からない部分は「未確認」と記す。都合のよい内容を補わない
  • 範囲:回答に文章を出すだけ。メール送信や元資料の変更は行わない
  • 今回の入力:ここへ対象週と素材を貼る

たとえば入力を「今週は問い合わせ対応12件。FAQの改訂は来週着手予定。課題は未整理」とします。期待するのは、12件を実績に残し、FAQの改訂を来週の予定へ置き、課題について勝手に原因を作らないことです。「顧客満足度が改善した」「FAQを完成させた」といった内容が出たら、この入力からは裏付けられません。文章が自然かどうかを読む前に、元の三つの情報がそれぞれどこへ移ったかを見ると、確認が具体的になります。

次に、見本を入れるかどうかを判断します。見出しと事実の整理ができているのに口調だけ合わないなら、短い見本が役立つかもしれません。一方、数値を間違える段階で長い完成見本を追加すると、確認すべき材料が増えます。まずは出力の型だけを指定し、必要なところへ見本を足してください。良い見本は「同じ話題の長い文章」ではなく、「どの部分を参考にするか説明できる文章」です。独自の書式を求める理由も一言添えると、条件を整理できます。

この指示をそのまま全体設定へ入れる必要はありません。同じ案件の週報だけならProject内で使い、案件をまたぐ定型手順として何度も使うならSkill化を検討します。まずは普通の依頼文として使い、不要な条件がないかを見る方法でも十分です。質問を一切しないと固定してしまうより、「欠けた数字は未確認にする」「仕事の目的自体が分からない場合は確認する」のように、不足の種類で扱いを分けておくと、無理に完成させる指示になりにくいです。

指示が反映されない時の確認

期待した形にならないと、つい「絶対に守ってください」を何度も追加したくなります。でも最初に見るのは強い言葉の数ではありません。保存先が合っているか、今回の入力がそろっているか、適用したいSkillが有効かを確かめます。公式のSkills利用ガイドでも、有効状態や説明文の確認、使うSkillを明示した依頼が案内されています。原因を一度に決めつけず、呼び出されていない問題と、呼び出された後の出力の問題を分けるのが出発点です。

たとえば週報の見出しが違う場合、別Projectで頼んでいないか、保存した指示にその見出しが残っているかを先に見ます。Skillを使う設計なら、名前を指定した依頼で違いが出るかを確認します。ただし「Skillを使いました」という回答だけでは、すべての手順を守った証拠にはなりません。利用画面で読み込みや実行の記録を確認できる場合はそこも見て、見られない部分は未確認として扱います。最後は完成した文章そのものを入力と照らし合わせてください。

  • 同じ入力・同じ依頼を残してから、一か所だけ変えて試す
  • 古い見本、重複する文字数指定、別案件の条件を確認する
  • 有効化と実際の適用、出力の合格を別々に判定する
  • 読めなかった資料を、読めた前提で続けさせない

比較用には、通常の素材、情報が不足する素材、似ているけれど対象外の依頼を用意します。通常は週報の整理、不足は実績の数値がない週報、対象外は「来月の企画案を出して」という依頼です。最後の例まで週報の三部構成に押し込めるなら、適用範囲が広すぎる可能性があります。これは障害を特定する万能試験ではなく、自分の使い方に合うかを小さく確認する方法です。試した入力と期待した動きを先に残しておくと、良く見える結果だけを選びにくくなります。

長い会話の途中だけで崩れる場合は、保存した指示以外の文脈が影響している可能性も考えます。新しい会話で同じ素材を試し、問題が同じように出るかを比べてください。ただし、新しい会話でも全体指示や利用中の設定が残る場合があるため、完全に設定を切り離した試験とは呼べません。会話が長くなる場合の整理は、Claudeのコンテキスト管理と長い会話の注意点も参考になります。闇雲に指示を継ぎ足す前に、比較できる条件を残しましょう。

Xの活用例と過信への反対事例

Xの公開投稿には、繰り返す説明を減らしたいという実用上の関心が表れています。2026年4月1日のRuben Hassidさん(@rubenhassid)の投稿では、単発のプロンプトからProject、反復する仕事のSkillへ進む考え方が紹介されていました。ここから参考になるのは、機能を増やすことそのものより、何を繰り返しているか具体的にする視点です。一方、投稿にある永続性を強く印象づける表現や当時のメニューは、現在の動作保証として受け取らないようにします。

対照的に、2026年9月29日のromさん(@romly2023)の投稿には、日本語を指定しても英語で出力されることへの不満がありました。ただし、入力全文や設定、同じ条件での再現率までは確認できません。この一件から、Claude全体の障害やSkills固有の不具合とは判断できないですね。それでも、指示した言語を含めて完成物を確かめる必要がある、という確認項目のヒントにはなります。便利な保存機能があっても、結果の確認まで不要にはなりません。

  • 活用例から拾うもの:どんな再説明を減らしたいか
  • 不満から拾うもの:自分の確認項目へ加える観点
  • 拾わないもの:成功率、全利用者への一般化、未確認の不具合原因
  • 投稿時点の操作やモデル指定は、現在の公式案内と分ける

また、2026年9月27日のSkills Studio(@sumika45379)のX記事では、自分の環境で動いた結果と、他者へ渡せる状態を区別していました。注意したいのは、その記事で示された実行環境はCodex CLIであり、Claudeでの実測ではない点です。ここでは隣接するスキル運用の事例として扱い、Claudeでも同じ結果が出る根拠には使いません。自分だけの成功を別の環境へそのまま広げないという留保は、スキルの紹介を読むときにも大切だと考えます。

今回の三件は、用途やつまずきを考えるために選んだ少数の投稿です。利用者全体を代表する調査ではなく、投稿に書かれた効果をこちらで再測定したわけでもありません。記事内の確認手順も、これらの投稿の成功率を計算して作ったものではありません。公式の機能説明と、公開投稿で確認した意見と、私が提案する使い方を分けることで、「すぐ便利になりそう」という期待と「自分の仕事でも確かめる必要がある」という判断を、両方持っておけます。

更新と共有は別の作業にする

保存した指示は、使い続けるうちに古くなります。担当者が変わる、週報の見出しが変わる、共有してよい情報が変わるといった変更があるからです。そこで、指示の名前だけでなく、変更日と変更理由を一行残しておきます。「週報用・9月29日版・来週の予定を実績へ混ぜない条件を追加」のような短い記録で構いません。更新後の文章が良さそうに見えても、前の版をすぐ消さず、戻せるコピーを置くと比較がしやすくなります。

更新するときは、失敗した例だけでなく、これまで使えていた入力も再確認します。たとえば「足りない情報があれば必ず質問する」と強めた結果、空欄を未確認として残せばよい週報まで止まるかもしれません。これは説明のための想定例で、今回その挙動を実測したという意味ではありません。追加したルールがどの場面を良くし、どの場面に影響しそうかを考え、通常・不足・対象外の入力を同じ条件で比較するのが、変更を小さく保つ方法です。

確認用の入力先に決める期待記録すること
事実がそろった週報素材数値と時点を変えずに整理元の事実と出力の対応
数値が欠けた週報素材勝手に補わず未確認と表示補完された内容の有無
来月の企画を考える依頼週報の型を無条件に適用しない用途外のルールの混入

人へ共有するときは、さらに別の点を確認します。説明や見本に個人名、顧客情報、社内限定のルールが含まれていないか、相手が参照できない資料を前提にしていないかを見ます。自分の画面で開ける資料でも、相手が同じ権限を持つとは限りません。共有ボタンを押せることと、内容を共有してよいことも別です。最初は架空の入力と期待する出力の条件を渡し、相手が自分の環境で試せるようにするほうが、本番資料を丸ごと送るより確認範囲を小さくできます。

  • 更新前の版と、同じ確認用入力を残す
  • 共有用の見本から、不要な固有名詞や機密情報を外す
  • 相手が使える資料と、利用できる機能を確認する
  • まだ試していない環境は「未確認」と伝える

外部で配布されているSkillを取り入れる場合も、便利そうな名前だけで判断しないでください。文章の整形だけを期待していたのに、外部への送信やファイルの変更が手順へ含まれているなら、想定する範囲が違います。中身と依存する道具を確認し、説明できない処理があれば、そのまま有効にせず確認を優先します。手順の再利用は、権限を広く渡すことと同じではありません。作業の質をそろえるための工夫と、誰に何を許すかの判断は、分けて管理しましょう。

Claudeのプロンプトを育てる

Claudeのプロンプトを再利用する最初の一歩は、機能を全部使いこなすことではありません。何度も頼んでいる仕事を一つ選び、固定ルール・今回の入力・合格条件へ分けることです。共通の好みは全体指示、案件の前提はProject、繰り返す手順はSkillを候補にします。ただし、一度きりの仕事まで保存の仕組みに乗せる必要はありません。毎回説明し直している部分だけを、小さく残すところから始めるほうが、後から直す負担も少なくなります。

今日試すなら、週報や社内向けの文章など、結果を自分で照合できる題材を選びましょう。過去の実際のやり取りをそのまま貼る前に、説明に不要な名前や内部情報を除きます。そして「何を残すか」と同時に、「何を勝手に変えないか」を一つ決めてください。週報なら実績と予定の区別、案内文なら開催日、要約なら未確定事項の扱いが候補です。文章の上手さだけで判定せず、業務で困る違いを見つけられる確認項目にすると、修正の目的が明確になります。

  • 同じ型で繰り返す仕事を一つ選ぶ
  • 固定ルールと今回の素材を別の欄にする
  • 保存先を選び、別の会話で短い素材を試す
  • 言語・事実・形式を照合し、変更点を一行残す

うまくいかなかった場合は、指示を一気に長くするのではなく、期待と違った箇所を一つ取り出します。「説明が変」より、「来週の予定が今週の実績へ入った」のほうが、直す場所を決めやすいですね。修正したら同じ素材でもう一度比べ、別の入力でも条件が保たれるかを確かめます。毎回の出力が完全に同じである必要はなく、目的に関わる条件が守られているかが判断の軸です。まだ確認していないケースまで成功扱いにしないことも、使い続けるうえでの安心につながります。

ProjectsやSkills以外も含めて、そもそもClaudeにどんな仕事を頼むか迷っている場合は、Claudeでできること・使い方・注意点の全体ガイドへ戻って整理できます。保存の仕組みは、選んだ仕事を繰り返しやすくするための道具です。良いプロンプトを一度見つけて終わりにするのではなく、使う場面が変わったら見直せる形で残しておく。その小さな積み重ねが、毎回の説明と修正に振り回されない使い方へつながると思います。