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

複雑なタスクを扱う際、単一のプロンプトですべてを処理しようとすると、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. 明確性： - 各問題について現状、懸念、提案する変更という優れた構造化。 - B2B SaaSの文脈で適切な技術用語（「EBITDA」「段階的なサービスクレジット」）。 - アクション項目が明確：ベンダーの法務チームが確認し変更を組み込む。 3. プロフェッショナリズム： - 当社の要求だけでなく、相互の利益と業界標準に焦点を当てる。 - より広い責任（データセキュリティ、業務の卓越性、受託者責任）に言及し、議論を高度化。 - さらなる協議を提案し、問題の理解と解決へのコミットメントを示す。全体として、電子メールは断固とした態度と協調性の適切なバランスを取っています。懸念事項を明確に表明し、具体的な解決策を提案し、プロフェッショナルでパートナーシップ重視のトーンを維持しています。修正は不要で、送信可能です。

役割

内容

User

電子メールを確認してフィードバックを提供する任務です。以下が電子メールです：
<email>
{{EMAIL}}
</email>

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

Assistant

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

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

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. RBAC、ABAC、エンタープライズSSOのためのSAML/OIDCでIAMを強化。 3. コスト最適化： a. スケール時のシャーディングと比較して列指向マルチテナントDB（Snowflakeなど）を評価。 b. アプリケーションサーバーにリザーブドインスタンス、非重要ワークロードにスポットインスタンスを使用。 c. 過剰なプロビジョニングを避けるためのプロアクティブなモニタリングと適切なサイジングを実装。 4. 実証実験（PoC）：完全な実装前に、高スケールシミュレーションで実証実験を実施： a. コストとパフォーマンスについてシャード化DBと最適化されたマルチテナントDBをテスト。 b. シミュレートされたエンタープライズレベルのトラフィックスパイクでアプリケーション層をストレステスト。 c. データ分離とアクセス制御に焦点を当てたサードパーティのセキュリティ監査を実施。これらの強化により、当社のマルチテナンシー戦略はエンタープライズグレードとなります：スケーラブル、セキュア、コスト効率的。実証実験により当社の設計選択を検証し、エンタープライズクライアントに信頼を与えます。

役割

内容

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. RBAC、ABAC、エンタープライズSSOのためのSAML/OIDCでIAMを強化。

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

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

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

プロンプト3

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

役割

内容

User

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

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

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

Assistant

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

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

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

全体として、文書は明確性とエンタープライズの整合性で優れています。実行可能性は強いですが、「次のステップ」セクションを追加することで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プロンプティングチュートリアル

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

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

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

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

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

例