より強力なパフォーマンスのための複雑なプロンプトのチェーン化

While these tips apply broadly to all Claude models, you can find prompting tips specific to extended thinking models here.

複雑なタスクを扱う際、単一のプロンプトですべてを処理しようとすると、Claudeが時々ボールを落とすことがあります。思考の連鎖（Chain of Thought、CoT）プロンプトは素晴らしいですが、タスクに深い思考を必要とする複数の異なるステップがある場合はどうでしょうか？

そこで登場するのがプロンプトチェーン化です：複雑なタスクを小さく管理しやすいサブタスクに分解します。

なぜプロンプトをチェーン化するのか？

正確性：各サブタスクにClaudeの完全な注意が向けられ、エラーが減少します。
明確性：シンプルなサブタスクは、より明確な指示と出力につながります。
追跡可能性：プロンプトチェーンの問題を簡単に特定して修正できます。

プロンプトをチェーン化するタイミング

研究の統合、文書分析、反復的なコンテンツ作成など、複数のステップを含むタスクにプロンプトチェーン化を使用します。タスクに複数の変換、引用、または指示が含まれる場合、チェーン化によってClaudeがステップを落としたり誤って処理したりするのを防ぎます。

覚えておくこと： チェーンの各リンクにClaudeの完全な注意が向けられます！

デバッグのヒント：Claudeがステップを見落としたり、パフォーマンスが低下したりした場合は、そのステップを独立したプロンプトに分離します。これにより、タスク全体をやり直すことなく、問題のあるステップを微調整できます。

プロンプトのチェーン化方法

サブタスクの特定：タスクを個別の連続したステップに分解します。
明確な受け渡しのためのXML構造化：XMLタグを使用してプロンプト間で出力を受け渡します。
単一タスクの目標設定：各サブタスクは単一の明確な目的を持つべきです。
反復：Claudeのパフォーマンスに基づいてサブタスクを改良します。

チェーン化されたワークフローの例：

複数ステップの分析：以下の法務およびビジネスの例を参照。
コンテンツ作成パイプライン：研究 → アウトライン → 下書き → 編集 → フォーマット。
データ処理：抽出 → 変換 → 分析 → 可視化。
意思決定：情報収集 → オプション列挙 → 各分析 → 推奨。
検証ループ：コンテンツ生成 → レビュー → 改良 → 再レビュー。

最適化のヒント：独立したサブタスク（複数の文書の分析など）がある場合は、速度向上のために別々のプロンプトを作成して並行実行します。

高度な使用法：自己修正チェーン

Claudeに自身の作業をレビューさせるようにプロンプトをチェーン化できます！これは特に重要なタスクでエラーを捕捉し、出力を改良します。

プロンプト1

役割	内容
User	この医学研究論文を要約してください。 <paper>{{RESEARCH_PAPER}}</paper> 方法論、結果、臨床的意義に焦点を当ててください。
Assistant {{SUMMARY}}	方法論：2型糖尿病患者500名を対象とした二重盲検RCT。グループA（n=250）は新規GLP-1/GIPデュアルアゴニストを投与；グループB（n=250）は標準的なGLP-1アゴニストを投与。24週間の試験、主要評価項目：HbA1c低下。結果： - グループA：平均HbA1c低下1.8% - グループB：平均HbA1c低下1.1% - グループAの68%対グループBの52%がHbA1c <7%を達成 - グループA：平均体重減少5.2kg - グループB：平均体重減少3.1kg 安全性：類似の有害事象プロファイル、治療に起因する重篤な事象なし。臨床的意義：デュアルアゴニストは標準療法と比較して、血糖コントロールと体重減少で優れた効果を示す。特に肥満糖尿病患者にとってゲームチェンジャーとなる可能性がある。

役割

内容

User

この医学研究論文を要約してください。

<paper>{{RESEARCH_PAPER}}</paper>

方法論、結果、臨床的意義に焦点を当ててください。

Assistant
{{SUMMARY}}

方法論：2型糖尿病患者500名を対象とした二重盲検RCT。グループA（n=250）は新規GLP-1/GIPデュアルアゴニストを投与；グループB（n=250）は標準的なGLP-1アゴニストを投与。24週間の試験、主要評価項目：HbA1c低下。

結果：
- グループA：平均HbA1c低下1.8%
- グループB：平均HbA1c低下1.1%
- グループAの68%対グループBの52%がHbA1c <7%を達成
- グループA：平均体重減少5.2kg
- グループB：平均体重減少3.1kg

安全性：類似の有害事象プロファイル、治療に起因する重篤な事象なし。

臨床的意義：デュアルアゴニストは標準療法と比較して、血糖コントロールと体重減少で優れた効果を示す。特に肥満糖尿病患者にとってゲームチェンジャーとなる可能性がある。

プロンプト2

役割	内容
User	研究論文要約へのフィードバックを提供するのが課題です。以下は医学研究論文の要約です： <summary> {{SUMMARY}} </summary> 以下が研究論文です： <paper> {{RESEARCH_PAPER}} </paper> この要約の正確性、明確性、完全性をA-Fの段階で評価してください。
Assistant {{FEEDBACK}}	1. 正確性：A - 主要な統計を正確に報告：HbA1c低下、体重減少。 - 安全性プロファイルと重篤な有害事象がないことを正確に記載。 - 「ゲームチェンジャー」という主張は、有意に良好な結果により正当化される。 2. 明確性：A- - 簡潔で構造化された明確なセクション。 - 文脈を示す比較的な言語（例：「第1四半期から3%上昇」）の適切な使用。 - 軽微な問題：「RCT」「GLP-1」「GIP」などの頭字語が定義されていない。初出時のスペルアウトを検討。 3. 完全性：B+ - 要求された領域をすべてカバー：方法論、結果、臨床的意義。 - 不足：グループのベースライン特性（適切にマッチングされていたか？）。 - 不足：二次評価項目（血圧、脂質など）。 - 検討事項：長期的な意義または更なる研究の必要性。全体として、要約は正確で明確であり、研究を素早く把握するための重要な洞察を提供している。A+に引き上げるには、頭字語を定義し、グループのベースライン統計に言及し、二次的な結果を記載し、長期研究の必要性に簡単に触れること。

役割

内容

User

研究論文要約へのフィードバックを提供するのが課題です。以下は医学研究論文の要約です：
<summary>
{{SUMMARY}}
</summary>

以下が研究論文です：
<paper>
{{RESEARCH_PAPER}}
</paper>

この要約の正確性、明確性、完全性をA-Fの段階で評価してください。

Assistant
{{FEEDBACK}}

1. 正確性：A
- 主要な統計を正確に報告：HbA1c低下、体重減少。
- 安全性プロファイルと重篤な有害事象がないことを正確に記載。
- 「ゲームチェンジャー」という主張は、有意に良好な結果により正当化される。

2. 明確性：A-
- 簡潔で構造化された明確なセクション。
- 文脈を示す比較的な言語（例：「第1四半期から3%上昇」）の適切な使用。
- 軽微な問題：「RCT」「GLP-1」「GIP」などの頭字語が定義されていない。初出時のスペルアウトを検討。

3. 完全性：B+
- 要求された領域をすべてカバー：方法論、結果、臨床的意義。
- 不足：グループのベースライン特性（適切にマッチングされていたか？）。
- 不足：二次評価項目（血圧、脂質など）。
- 検討事項：長期的な意義または更なる研究の必要性。

全体として、要約は正確で明確であり、研究を素早く把握するための重要な洞察を提供している。A+に引き上げるには、頭字語を定義し、グループのベースライン統計に言及し、二次的な結果を記載し、長期研究の必要性に簡単に触れること。

プロンプト3

役割	内容
User	フィードバックに基づいて論文要約を改善するのが課題です。以下は医学研究論文の第一稿です： <summary> {{SUMMARY}} </summary> 以下が研究論文です： <paper> {{RESEARCH_PAPER}} </paper> 以下がフィードバックです： <feedback> {{FEEDBACK}} </feedback> フィードバックに基づいて要約を更新してください。
Assistant	方法論：2型糖尿病患者500名を対象とした二重盲検ランダム化比較試験（RCT）。グループA（n=250）は新規グルカゴン様ペプチド-1/グルコース依存性インスリン分泌促進ポリペプチド（GLP-1/GIP）デュアルアゴニストを投与；グループB（n=250）は標準的なGLP-1アゴニストを投与。24週間の試験の主要評価項目はHbA1c低下。グループは年齢、BMI、ベースラインHbA1cでよくマッチングされていた。結果： - グループA：平均HbA1c低下1.8% - グループB：平均HbA1c低下1.1% - グループAの68%対グループBの52%がHbA1c <7%を達成 - グループA：平均体重減少5.2kg - グループB：平均体重減少3.1kg 二次評価項目では、両グループで血圧と脂質プロファイルの改善が見られ、グループAでわずかに良好な結果を示した。安全性：いずれの治療にも起因する重篤な事象はなく、類似の有害事象プロファイルを示した。臨床的意義：GLP-1/GIPデュアルアゴニストは、標準的なGLP-1療法と比較して、血糖コントロールと体重減少で優れた効果を示す。これらの結果は、特に肥満糖尿病患者にとって重要な進歩となる可能性を示唆している。ただし、持続的な有効性と安全性を確認し、心血管アウトカムへの潜在的な利点を調査するために、より長期的な研究が必要である。

役割

内容

User

フィードバックに基づいて論文要約を改善するのが課題です。以下は医学研究論文の第一稿です：
<summary>
{{SUMMARY}}
</summary>

以下が研究論文です：
<paper>
{{RESEARCH_PAPER}}
</paper>

以下がフィードバックです：
<feedback>
{{FEEDBACK}}
</feedback>

フィードバックに基づいて要約を更新してください。

Assistant

方法論：2型糖尿病患者500名を対象とした二重盲検ランダム化比較試験（RCT）。グループA（n=250）は新規グルカゴン様ペプチド-1/グルコース依存性インスリン分泌促進ポリペプチド（GLP-1/GIP）デュアルアゴニストを投与；グループB（n=250）は標準的なGLP-1アゴニストを投与。24週間の試験の主要評価項目はHbA1c低下。グループは年齢、BMI、ベースラインHbA1cでよくマッチングされていた。

結果：
- グループA：平均HbA1c低下1.8%
- グループB：平均HbA1c低下1.1%
- グループAの68%対グループBの52%がHbA1c <7%を達成
- グループA：平均体重減少5.2kg
- グループB：平均体重減少3.1kg

二次評価項目では、両グループで血圧と脂質プロファイルの改善が見られ、グループAでわずかに良好な結果を示した。

安全性：いずれの治療にも起因する重篤な事象はなく、類似の有害事象プロファイルを示した。

臨床的意義：GLP-1/GIPデュアルアゴニストは、標準的なGLP-1療法と比較して、血糖コントロールと体重減少で優れた効果を示す。これらの結果は、特に肥満糖尿病患者にとって重要な進歩となる可能性を示唆している。ただし、持続的な有効性と安全性を確認し、心血管アウトカムへの潜在的な利点を調査するために、より長期的な研究が必要である。

例

Claudeが電子メール下書きで提案された変更を提供する指示を見落としていることに注意してください。

役割	内容
User	あなたは当社の最高法務責任者です。このSaaS契約書をデータプライバシー、SLA、責任制限に焦点を当ててリスクを確認してください。 <contract> {{CONTRACT}} </contract> その後、懸念事項と提案する変更点についてベンダーへのメールを下書きしてください。
Assistant	SaaS契約書を確認した結果、以下の懸念事項を特定しました： 1. データプライバシー（第7条）： - 問題：ベンダーは「サービス改善」のためにクライアントデータを広く使用する権利を持つ。 - リスク：不正なデータ共有や収益化につながる可能性。 2. SLA（第5条）： - 問題：99.5%の稼働時間保証は業界標準を下回る。 - リスク：過度のダウンタイムが当社の業務に影響を与える可能性。 3. 責任（第9条）： - 問題：上限が3ヶ月分の料金に設定。 - リスク：データ漏洩やサービス障害に対して不十分。メール下書き： {{VENDOR}}様 SaaS契約書を確認した結果、以下の懸念事項があります： 1. データプライバシー：当社のデータは直接のサービス提供にのみ使用されることを要求します。第7条を修正してください。 2. SLA：99.5%の稼働時間は不十分です。明確に定義されたペナルティを伴う99.99%が必要です。第5条を改訂してください。 3. 責任：現在の3ヶ月分の料金という上限は不十分です。12ヶ月分の料金を上限とし、データ漏洩や故意の不正行為については上限なしを提案します。潜在的なパートナーシップを重視しており、これらの変更が成功への基盤を築くと考えています。改訂版の契約書をお送りください。敬具 {{CLO_NAME}}

役割

内容

User

あなたは当社の最高法務責任者です。このSaaS契約書をデータプライバシー、SLA、責任制限に焦点を当ててリスクを確認してください。

<contract>
{{CONTRACT}}
</contract>

その後、懸念事項と提案する変更点についてベンダーへのメールを下書きしてください。

Assistant

SaaS契約書を確認した結果、以下の懸念事項を特定しました：

1. データプライバシー（第7条）：
- 問題：ベンダーは「サービス改善」のためにクライアントデータを広く使用する権利を持つ。
- リスク：不正なデータ共有や収益化につながる可能性。

2. SLA（第5条）：
- 問題：99.5%の稼働時間保証は業界標準を下回る。
- リスク：過度のダウンタイムが当社の業務に影響を与える可能性。

3. 責任（第9条）：
- 問題：上限が3ヶ月分の料金に設定。
- リスク：データ漏洩やサービス障害に対して不十分。

メール下書き：

{{VENDOR}}様

SaaS契約書を確認した結果、以下の懸念事項があります：

1. データプライバシー：当社のデータは直接のサービス提供にのみ使用されることを要求します。第7条を修正してください。

2. SLA：99.5%の稼働時間は不十分です。明確に定義されたペナルティを伴う99.99%が必要です。第5条を改訂してください。

3. 責任：現在の3ヶ月分の料金という上限は不十分です。12ヶ月分の料金を上限とし、データ漏洩や故意の不正行為については上限なしを提案します。

潜在的なパートナーシップを重視しており、これらの変更が成功への基盤を築くと考えています。改訂版の契約書をお送りください。

敬具
{{CLO_NAME}}

プロンプト1

役割	内容
User	あなたは当社の最高法務責任者です。このSaaS契約書をデータプライバシー、SLA、責任制限に焦点を当ててリスクを確認してください。 <contract> {{CONTRACT}} </contract> 結果を<risks>タグ内に出力してください。
Assistant {{CONCERNS}}	1. データプライバシー（第7条）： - 問題：ベンダーは「サービス改善」のためにクライアントデータを広く使用する権利を持つ。 - リスク：クライアントデータの不正な共有や収益化につながる可能性。 - 影響：クライアントの信頼の喪失、規制上の罰金（GDPR、CCPA）。 2. SLA（第5条）： - 問題：99.5%の稼働時間保証は業界標準（通常99.99%）を下回る。 - リスク：99.99%の52.6分に対し、年間最大43.8時間のダウンタイム。 - 影響：業務の中断、収益損失、クライアントの不満。 3. 責任（第9条）： - 問題：責任上限が3ヶ月分の料金に設定。 - リスク：データ漏洩、IP盗難、または長期的なサービス障害に対して不十分。 - 影響：集団訴訟や規制上の罰金など、上限を大きく超える可能性のある損害に対する補償が不十分。

役割

内容

User

あなたは当社の最高法務責任者です。このSaaS契約書をデータプライバシー、SLA、責任制限に焦点を当ててリスクを確認してください。

<contract>
{{CONTRACT}}
</contract>

結果を<risks>タグ内に出力してください。

Assistant
{{CONCERNS}}

1. データプライバシー（第7条）：
- 問題：ベンダーは「サービス改善」のためにクライアントデータを広く使用する権利を持つ。
- リスク：クライアントデータの不正な共有や収益化につながる可能性。
- 影響：クライアントの信頼の喪失、規制上の罰金（GDPR、CCPA）。

2. SLA（第5条）：
- 問題：99.5%の稼働時間保証は業界標準（通常99.99%）を下回る。
- リスク：99.99%の52.6分に対し、年間最大43.8時間のダウンタイム。
- 影響：業務の中断、収益損失、クライアントの不満。

3. 責任（第9条）：
- 問題：責任上限が3ヶ月分の料金に設定。
- リスク：データ漏洩、IP盗難、または長期的なサービス障害に対して不十分。
- 影響：集団訴訟や規制上の罰金など、上限を大きく超える可能性のある損害に対する補償が不十分。

プロンプト2

役割	内容
User	以下の懸念事項を概説し、変更を提案するSaaSプロダクトベンダー向けのメールを下書きしてください。以下が懸念事項です： <concerns> {{CONCERNS}} </concerns>
Assistant {{EMAIL}}	{{VENDOR}}様提案されたSaaS契約書の詳細な確認の結果、当社の法務チームは進行前に対処が必要な以下の重要な懸念事項を特定しました： 1. データプライバシー（第7条）： - 現状：「サービス改善」のためのクライアントデータの広範な使用権。 - 懸念：不正なデータ共有や収益化の可能性。 - 提案する変更：データ使用を直接のサービス提供に限定。改善、分析、マーケティングのための使用はオプトイン式、取り消し可能、匿名化必須とする。 2. SLA（第5条）： - 現状：99.5%の稼働時間保証。 - 懸念：年間最大43.8時間のダウンタイムによる業務中断のリスク。 - 提案する変更：段階的なサービスクレジットを伴う99.99%の稼働時間。例：<99.99%で10%クレジット、<99.9%で25%、<99.5%で50%。 3. 責任（第9条）： - 現状：3ヶ月分の料金を上限。 - 懸念：データ漏洩、IP盗難、長期的な停止に対して著しく不十分。 - 提案する変更：一般的な責任は12ヶ月分の料金を上限。データ漏洩、故意の不正行為、IP侵害については上限なし。これらの変更は当社にとって譲れない条件です。これらは業界標準およびデータセキュリティ、業務の卓越性、受託者責任への当社のコミットメントに沿うものです。潜在的なパートナーシップの価値を認識しており、これらの対応が強固な基盤を築くことになります。貴社の法務チームにこれらの変更を確認し、組み込んでいただけますようお願いいたします。相互理解と合意を確実にするため、さらなる協議にも喜んで応じます。敬具 {{CLO_NAME}}

役割

内容

User

以下の懸念事項を概説し、変更を提案するSaaSプロダクトベンダー向けのメールを下書きしてください。以下が懸念事項です：
<concerns>
{{CONCERNS}}
</concerns>

Assistant
{{EMAIL}}

{{VENDOR}}様

提案されたSaaS契約書の詳細な確認の結果、当社の法務チームは進行前に対処が必要な以下の重要な懸念事項を特定しました：

1. データプライバシー（第7条）：
- 現状：「サービス改善」のためのクライアントデータの広範な使用権。
- 懸念：不正なデータ共有や収益化の可能性。
- 提案する変更：データ使用を直接のサービス提供に限定。改善、分析、マーケティングのための使用はオプトイン式、取り消し可能、匿名化必須とする。

2. SLA（第5条）：
- 現状：99.5%の稼働時間保証。
- 懸念：年間最大43.8時間のダウンタイムによる業務中断のリスク。
- 提案する変更：段階的なサービスクレジットを伴う99.99%の稼働時間。例：<99.99%で10%クレジット、<99.9%で25%、<99.5%で50%。

3. 責任（第9条）：
- 現状：3ヶ月分の料金を上限。
- 懸念：データ漏洩、IP盗難、長期的な停止に対して著しく不十分。
- 提案する変更：一般的な責任は12ヶ月分の料金を上限。データ漏洩、故意の不正行為、IP侵害については上限なし。

これらの変更は当社にとって譲れない条件です。これらは業界標準およびデータセキュリティ、業務の卓越性、受託者責任への当社のコミットメントに沿うものです。潜在的なパートナーシップの価値を認識しており、これらの対応が強固な基盤を築くことになります。

貴社の法務チームにこれらの変更を確認し、組み込んでいただけますようお願いいたします。相互理解と合意を確実にするため、さらなる協議にも喜んで応じます。

敬具
{{CLO_NAME}}

プロンプト3

役割	内容
User	メールをレビューしフィードバックを提供するのが課題です。以下がメールです： <email> {{EMAIL}} </email> トーン、明確性、プロフェッショナリズムについてフィードバックを提供してください。
Assistant	1. トーン： - 対立的にならずにプロフェッショナルかつ断固とした態度。 - 「譲れない条件」という表現は強いが、問題の重要性を考えると正当。 - 協調的な言葉遣い（「価値を認識」「喜んで協議」）が断固とした態度とバランスを取り、建設的なトーンを維持。 2. 明確性： - 優れた構造化：各問題について現状、懸念、提案する変更を記載。 - 技術用語（「EBITDA」「段階的なサービスクレジット」など）はB2B SaaSの文脈で適切。 - アクションアイテムが明確：ベンダーの法務チームが確認し変更を組み込む。 3. プロフェッショナリズム： - 当社の要求だけでなく、相互利益と業界標準に焦点を当てている。 - より広い責任（データセキュリティ、業務の卓越性、受託者責任）に言及し、議論を高次元に引き上げている。 - さらなる協議を提案し、問題の理解と解決へのコミットメントを示している。全体として、メールは断固とした態度と協調性の適切なバランスを取っている。懸念事項を明確に表現し、具体的な解決策を提案し、プロフェッショナルでパートナーシップ重視のトーンを維持している。修正は不要；送信可能。

役割

内容

User

メールをレビューしフィードバックを提供するのが課題です。以下がメールです：
<email>
{{EMAIL}}
</email>

トーン、明確性、プロフェッショナリズムについてフィードバックを提供してください。

Assistant

1. トーン：
- 対立的にならずにプロフェッショナルかつ断固とした態度。
- 「譲れない条件」という表現は強いが、問題の重要性を考えると正当。
- 協調的な言葉遣い（「価値を認識」「喜んで協議」）が断固とした態度とバランスを取り、建設的なトーンを維持。

2. 明確性：
- 優れた構造化：各問題について現状、懸念、提案する変更を記載。
- 技術用語（「EBITDA」「段階的なサービスクレジット」など）はB2B SaaSの文脈で適切。
- アクションアイテムが明確：ベンダーの法務チームが確認し変更を組み込む。

3. プロフェッショナリズム：
- 当社の要求だけでなく、相互利益と業界標準に焦点を当てている。
- より広い責任（データセキュリティ、業務の卓越性、受託者責任）に言及し、議論を高次元に引き上げている。
- さらなる協議を提案し、問題の理解と解決へのコミットメントを示している。

全体として、メールは断固とした態度と協調性の適切なバランスを取っている。懸念事項を明確に表現し、具体的な解決策を提案し、プロフェッショナルでパートナーシップ重視のトーンを維持している。修正は不要；送信可能。

プロンプト1

役割	内容
User	シニアソリューションアーキテクトとして、新しいエンタープライズSaaS製品のこのマルチテナンシー戦略をレビューし分析してください。 <strategy> {{STRATEGY}} </strategy> スケーラビリティ、セキュリティ、コスト効率に焦点を当ててください。
Assistant {{ANALYSIS}}	1. スケーラビリティ： + テナントごとのデータベースシャーディングにより競合を減少し、高成長をサポート。 + マイクロサービスによりコンポーネントの独立したスケーリングが可能。 - 共有アプリケーションサーバーが極端な負荷でボトルネックとなる可能性。 - アプリケーション層のオートスケーリングやロードバランシングについての言及なし。 2. セキュリティ： + シャーディングによるテナントデータの分離がデータ漏洩を軽減。 + 短期有効期限とリフレッシュトークンを持つJWTは業界のベストプラクティス。 - 暗号化（保存時、転送時）や鍵管理についての言及なし。 - IAM戦略にロール、権限、RBACの詳細が欠如。 3. コスト効率： + 共有アプリケーションサーバーがアイドルリソースのコストを削減。 + 非頻繁タスクのサーバーレス関数がコストを最適化。 - スケール時に最適化されたマルチテナントDBと比較してテナントごとのDBがコスト増加の可能性。 - コスト削減のためのリザーブドインスタンスやスポットインスタンスについての議論なし。

役割

内容

User

シニアソリューションアーキテクトとして、新しいエンタープライズSaaS製品のこのマルチテナンシー戦略をレビューし分析してください。

<strategy>
{{STRATEGY}}
</strategy>

スケーラビリティ、セキュリティ、コスト効率に焦点を当ててください。

Assistant
{{ANALYSIS}}

1. スケーラビリティ：
+ テナントごとのデータベースシャーディングにより競合を減少し、高成長をサポート。
+ マイクロサービスによりコンポーネントの独立したスケーリングが可能。
- 共有アプリケーションサーバーが極端な負荷でボトルネックとなる可能性。
- アプリケーション層のオートスケーリングやロードバランシングについての言及なし。

2. セキュリティ：
+ シャーディングによるテナントデータの分離がデータ漏洩を軽減。
+ 短期有効期限とリフレッシュトークンを持つJWTは業界のベストプラクティス。
- 暗号化（保存時、転送時）や鍵管理についての言及なし。
- IAM戦略にロール、権限、RBACの詳細が欠如。

3. コスト効率：
+ 共有アプリケーションサーバーがアイドルリソースのコストを削減。
+ 非頻繁タスクのサーバーレス関数がコストを最適化。
- スケール時に最適化されたマルチテナントDBと比較してテナントごとのDBがコスト増加の可能性。
- コスト削減のためのリザーブドインスタンスやスポットインスタンスについての議論なし。

プロンプト2

役割	内容
User	このマルチテナンシー戦略の分析に基づいて、エンジニアリングリーダーシップ向けの戦略レビュー文書を作成してください。 <strategy> {{STRATEGY}} </strategy> <analysis> {{ANALYSIS}} </analysis> エグゼクティブサマリー、詳細な分析、推奨事項を含めてください。
Assistant {{STRATEGY_DOC}}	# マルチテナンシー戦略レビュー：SaaSエンタープライズ製品 ## エグゼクティブサマリー提案された戦略はスケーラビリティとセキュリティの原則において堅実な基盤を示していますが、実装の詳細にギャップがあります。データ分離とコンポーネントレベルのスケーリングで優れていますが、アプリケーション層のロバストなスケーリングと高度なセキュリティ対策が不足しています。コスト最適化は存在しますが、大規模なスケールで躓く可能性があります。的を絞った強化により、この戦略は効果的に当社のエンタープライズSaaSの野心をサポートできます。 ## 詳細分析 ### 1. スケーラビリティ：B+ 強み： - テナントごとのデータベースシャーディングは優れている。クエリレイテンシーを最小化し、高いデータ成長をサポートし、テナントごとのシームレスなスケーリングを可能にする。 - マイクロサービスアーキテクチャにより、多様なエンタープライズワークロードを処理するために個々のコンポーネントを需要に応じてスケーリングできる。弱み： - 共有アプリケーションサーバーがボトルネックとなるリスク。テナント数とトラフィックが増加すると、すべてのテナントのパフォーマンスが低下する可能性。 - アプリケーション層のオートスケーリングとロードバランシングの欠如は重大な見落とし。これらは過剰なプロビジョニングなしにトラフィックスパイクを処理するために不可欠。 ### 2. セキュリティ：B- 強み： - シャード化されたデータベースが強力なテナントデータ分離を提供し、テナント間のデータ漏洩や不正アクセスのリスクを軽減。 - 短期有効期限とリフレッシュトークンを持つJWTはOWASPのベストプラクティスに沿っており、トークンの脆弱性ウィンドウを削減。弱み： - 保存時や転送時（TLS 1.3）のデータ暗号化への言及なし。これはエンタープライズデータには譲れない。 - 鍵管理戦略が欠如。暗号化キー、JWTシークレット、DBクレデンシャルをどのように管理しローテーションするのか？ - IAMが深さを欠く。明確に定義されたロールを持つRBAC、きめ細かい権限のための属性ベースアクセス制御（ABAC）、エンタープライズアイデンティティプロバイダー（SAML、OIDC）との統合が必要。 ### 3. コスト効率：B 強み： - 共有アプリケーションサーバーが定常状態のトラフィックのアイドルキャパシティコストを削減。 - 非頻繁タスク（レポートなど）のサーバーレスはスマート；これらのリソースが使用される時のみ支払い。弱み： - テナントごとのデータベースは、ロバストなデータパーティショニングを持つ適切に設計されたマルチテナントデータベースと比較して、スケール時にコスト効率が悪い可能性。 - 予測可能なワークロードのためのリザーブドインスタンスや耐障害性のあるタスクのためのスポットインスタンスなどのコスト削減対策への言及なし。 - アプリケーション層のオートスケーリングの欠如が過剰なプロビジョニングにつながり、コストを増加させる可能性。 ## 推奨事項 1. アプリケーション層の回復力：Kubernetesまたはクラウドネイティブサービス（EKS、GKE）でオートスケーリングを実装。静的アセット用のCDNを伴う可用性ゾーン間でのデプロイ。 2. セキュリティ強化： a. 保存時（AES-256）および転送時（TLS 1.3）のデータ暗号化。 b. 鍵管理にマネージドKMS（AWS KMS、GCP KMS）を使用。 c. エンタープライズSSOのためのRBAC、ABAC、SAML/OIDCでIAMを強化。 3. コスト最適化： a. スケール時のシャーディングvs.カラムナーマルチテナントDB（Snowflakeなど）を評価。 b. アプリケーションサーバーにリザーブドインスタンス、非重要ワークロードにスポットインスタンスを使用。 c. 過剰なプロビジョニングを避けるためのプロアクティブなモニタリングと適切なサイジングを実装。 4. 実証実験（PoC）：完全な実装前に、高スケールシミュレーションを伴うPoCを実施： a. コストとパフォーマンスについてシャード化DBvs.最適化されたマルチテナントDBをテスト。 b. シミュレートされたエンタープライズレベルのトラフィックスパイクでアプリケーション層をストレステスト。 c. データ分離とアクセス制御に焦点を当てたサードパーティセキュリティ監査を実施。これらの強化により、当社のマルチテナンシー戦略はエンタープライズグレードとなります：スケーラブル、セキュア、コスト効率的。PoCは当社の設計選択を検証し、エンタープライズクライアントに信頼を与えます。

役割

内容

User

このマルチテナンシー戦略の分析に基づいて、エンジニアリングリーダーシップ向けの戦略レビュー文書を作成してください。

<strategy>
{{STRATEGY}}
</strategy>

<analysis>
{{ANALYSIS}}
</analysis>

エグゼクティブサマリー、詳細な分析、推奨事項を含めてください。

Assistant
{{STRATEGY_DOC}}

# マルチテナンシー戦略レビュー：SaaSエンタープライズ製品

## エグゼクティブサマリー
提案された戦略はスケーラビリティとセキュリティの原則において堅実な基盤を示していますが、実装の詳細にギャップがあります。データ分離とコンポーネントレベルのスケーリングで優れていますが、アプリケーション層のロバストなスケーリングと高度なセキュリティ対策が不足しています。コスト最適化は存在しますが、大規模なスケールで躓く可能性があります。的を絞った強化により、この戦略は効果的に当社のエンタープライズSaaSの野心をサポートできます。

## 詳細分析

### 1. スケーラビリティ：B+

強み：
- テナントごとのデータベースシャーディングは優れている。クエリレイテンシーを最小化し、高いデータ成長をサポートし、テナントごとのシームレスなスケーリングを可能にする。
- マイクロサービスアーキテクチャにより、多様なエンタープライズワークロードを処理するために個々のコンポーネントを需要に応じてスケーリングできる。

弱み：
- 共有アプリケーションサーバーがボトルネックとなるリスク。テナント数とトラフィックが増加すると、すべてのテナントのパフォーマンスが低下する可能性。
- アプリケーション層のオートスケーリングとロードバランシングの欠如は重大な見落とし。これらは過剰なプロビジョニングなしにトラフィックスパイクを処理するために不可欠。

### 2. セキュリティ：B-

強み：
- シャード化されたデータベースが強力なテナントデータ分離を提供し、テナント間のデータ漏洩や不正アクセスのリスクを軽減。
- 短期有効期限とリフレッシュトークンを持つJWTはOWASPのベストプラクティスに沿っており、トークンの脆弱性ウィンドウを削減。

弱み：
- 保存時や転送時（TLS 1.3）のデータ暗号化への言及なし。これはエンタープライズデータには譲れない。
- 鍵管理戦略が欠如。暗号化キー、JWTシークレット、DBクレデンシャルをどのように管理しローテーションするのか？
- IAMが深さを欠く。明確に定義されたロールを持つRBAC、きめ細かい権限のための属性ベースアクセス制御（ABAC）、エンタープライズアイデンティティプロバイダー（SAML、OIDC）との統合が必要。

### 3. コスト効率：B

強み：
- 共有アプリケーションサーバーが定常状態のトラフィックのアイドルキャパシティコストを削減。
- 非頻繁タスク（レポートなど）のサーバーレスはスマート；これらのリソースが使用される時のみ支払い。

弱み：
- テナントごとのデータベースは、ロバストなデータパーティショニングを持つ適切に設計されたマルチテナントデータベースと比較して、スケール時にコスト効率が悪い可能性。
- 予測可能なワークロードのためのリザーブドインスタンスや耐障害性のあるタスクのためのスポットインスタンスなどのコスト削減対策への言及なし。
- アプリケーション層のオートスケーリングの欠如が過剰なプロビジョニングにつながり、コストを増加させる可能性。

## 推奨事項

1. アプリケーション層の回復力：Kubernetesまたはクラウドネイティブサービス（EKS、GKE）でオートスケーリングを実装。静的アセット用のCDNを伴う可用性ゾーン間でのデプロイ。

2. セキュリティ強化：
a. 保存時（AES-256）および転送時（TLS 1.3）のデータ暗号化。
b. 鍵管理にマネージドKMS（AWS KMS、GCP KMS）を使用。
c. エンタープライズSSOのためのRBAC、ABAC、SAML/OIDCでIAMを強化。

3. コスト最適化：
a. スケール時のシャーディングvs.カラムナーマルチテナントDB（Snowflakeなど）を評価。
b. アプリケーションサーバーにリザーブドインスタンス、非重要ワークロードにスポットインスタンスを使用。
c. 過剰なプロビジョニングを避けるためのプロアクティブなモニタリングと適切なサイジングを実装。

4. 実証実験（PoC）：完全な実装前に、高スケールシミュレーションを伴うPoCを実施：
a. コストとパフォーマンスについてシャード化DBvs.最適化されたマルチテナントDBをテスト。
b. シミュレートされたエンタープライズレベルのトラフィックスパイクでアプリケーション層をストレステスト。
c. データ分離とアクセス制御に焦点を当てたサードパーティセキュリティ監査を実施。

これらの強化により、当社のマルチテナンシー戦略はエンタープライズグレードとなります：スケーラブル、セキュア、コスト効率的。PoCは当社の設計選択を検証し、エンタープライズクライアントに信頼を与えます。

プロンプト3

役割	内容
User	この戦略レビュー文書を明確性、実行可能性、エンタープライズの優先事項との整合性について評価してください。 <priorities> {{PRIORITIES}} </priorities> <strategy_doc> {{STRATEGY_DOC}} </strategy_doc>
Assistant	1. 明確性：A + エグゼクティブサマリー、詳細分析、推奨事項による明確な構造。 + 分析は強み/弱みの素早い把握のための採点システム（B+、B-）を使用。 + 技術用語（RBAC、ABAC、TLS）は非技術的なリーダーシップのために説明または文脈化。 + 視覚的な補助（箇条書き、インデント）が読みやすさを向上。 2. 実行可能性：A- + 推奨事項が具体的で技術的（「Kubernetesでオートスケーリングを実装」など）。 + 明確な目的を持つPoCプランがロードマップを提供。 + 不足：各推奨事項のタイムライン、リソース要件、またはチーム割り当て。 + 検討：即時のアクション、役割、高レベルのタイムラインを含む「次のステップ」セクションの追加。 3. エンタープライズ整合性：A+ + エンタープライズの優先事項に直接対応： - スケーラビリティ：エンタープライズレベルのトラフィックスパイクの処理について議論。 - セキュリティ：データ分離、暗号化、エンタープライズIAMに焦点。 - コスト：エンタープライズFinOps（リザーブドインスタンス、適切なサイジング）に沿った戦略。 + 「高スケールシミュレーション」とセキュリティ監査を伴うPoCはエンタープライズグレードの品質へのコミットメントを示す。 + 言語がエンタープライズの懸念と共鳴：「受け入れられないリスク」「エンタープライズグレード」「信頼を与える」。全体として、文書は明確性とエンタープライズ整合性で優れている。実行可能性は強いが、「次のステップ」セクションを追加することでA+に引き上げることができる。技術的な深さと明確な説明の組み合わせにより、技術的および非技術的なリーダーシップの両方に非常に効果的。素晴らしい仕事！

役割

内容

User

この戦略レビュー文書を明確性、実行可能性、エンタープライズの優先事項との整合性について評価してください。

<priorities>
{{PRIORITIES}}
</priorities>

<strategy_doc>
{{STRATEGY_DOC}}
</strategy_doc>

Assistant

1. 明確性：A
+ エグゼクティブサマリー、詳細分析、推奨事項による明確な構造。
+ 分析は強み/弱みの素早い把握のための採点システム（B+、B-）を使用。
+ 技術用語（RBAC、ABAC、TLS）は非技術的なリーダーシップのために説明または文脈化。
+ 視覚的な補助（箇条書き、インデント）が読みやすさを向上。

2. 実行可能性：A-
+ 推奨事項が具体的で技術的（「Kubernetesでオートスケーリングを実装」など）。
+ 明確な目的を持つPoCプランがロードマップを提供。
+ 不足：各推奨事項のタイムライン、リソース要件、またはチーム割り当て。
+ 検討：即時のアクション、役割、高レベルのタイムラインを含む「次のステップ」セクションの追加。

3. エンタープライズ整合性：A+
+ エンタープライズの優先事項に直接対応：
- スケーラビリティ：エンタープライズレベルのトラフィックスパイクの処理について議論。
- セキュリティ：データ分離、暗号化、エンタープライズIAMに焦点。
- コスト：エンタープライズFinOps（リザーブドインスタンス、適切なサイジング）に沿った戦略。
+ 「高スケールシミュレーション」とセキュリティ監査を伴うPoCはエンタープライズグレードの品質へのコミットメントを示す。
+ 言語がエンタープライズの懸念と共鳴：「受け入れられないリスク」「エンタープライズグレード」「信頼を与える」。

全体として、文書は明確性とエンタープライズ整合性で優れている。実行可能性は強いが、「次のステップ」セクションを追加することでA+に引き上げることができる。技術的な深さと明確な説明の組み合わせにより、技術的および非技術的なリーダーシップの両方に非常に効果的。素晴らしい仕事！

プロンプトライブラリ

様々なタスクやユースケースのための厳選されたプロンプトで着想を得ましょう。

GitHubプロンプティングチュートリアル

当社のドキュメントにあるプロンプトエンジニアリングの概念をカバーする例が豊富なチュートリアル。

Google Sheetsプロンプティングチュートリアル

インタラクティブなスプレッドシートを通じた、当社のプロンプトエンジニアリングチュートリアルの軽量版。

Was this page helpful?

Claudeの応答の事前入力長文コンテキストのヒント

On this page

はじめる

Claudeについて

エージェントとツール

Claudeで開発

管理

テストと評価

リソース

法務センター

より強力なパフォーマンスのための複雑なプロンプトのチェーン化

なぜプロンプトをチェーン化するのか？

プロンプトをチェーン化するタイミング

プロンプトのチェーン化方法

チェーン化されたワークフローの例：

高度な使用法：自己修正チェーン

プロンプト1

プロンプト2

プロンプト3

例

プロンプト1

プロンプト2

プロンプト3

プロンプト1

プロンプト2

プロンプト3

プロンプトライブラリ

GitHubプロンプティングチュートリアル

Google Sheetsプロンプティングチュートリアル

はじめる

Claudeについて

エージェントとツール

Claudeで開発

管理

テストと評価

リソース

法務センター

​なぜプロンプトをチェーン化するのか？

​プロンプトをチェーン化するタイミング

​プロンプトのチェーン化方法

​チェーン化されたワークフローの例：

​高度な使用法：自己修正チェーン

プロンプト1

プロンプト2

プロンプト3

​例

プロンプト1

プロンプト2

プロンプト3

プロンプト1

プロンプト2

プロンプト3

プロンプトライブラリ

GitHubプロンプティングチュートリアル

Google Sheetsプロンプティングチュートリアル

なぜプロンプトをチェーン化するのか？

プロンプトをチェーン化するタイミング

プロンプトのチェーン化方法

チェーン化されたワークフローの例：

高度な使用法：自己修正チェーン

例