プロンプトエンジニアリング
複雑なプロンプトをチェーンして、より強力なパフォーマンスを実現する
プロンプトエンジニアリング
複雑なプロンプトをチェーンして、より強力なパフォーマンスを実現する
複雑なタスクに取り組む際、1つのプロンプトですべてを処理しようとすると、Claudeが時々ボールを落とすことがあります。思考の連鎖（CoT）プロンプティングは素晴らしいですが、タスクに深い思考を必要とする明確な複数のステップがある場合はどうでしょうか？
プロンプトチェーンの登場です：複雑なタスクを、管理しやすい小さなサブタスクに分割します。
プロンプトをチェーンする理由
- 正確性：各サブタスクにClaudeの注意が集中し、エラーが減少します。
- 明確性：シンプルなサブタスクは、明確な指示とアウトプットを意味します。
- トレーサビリティ：プロンプトチェーンの問題を簡単に特定して修正できます。
プロンプトをチェーンするタイミング
研究の統合、ドキュメント分析、反復的なコンテンツ作成など、複数のステップを含むタスクにプロンプトチェーンを使用します。タスクに複数の変換、引用、または指示が含まれている場合、チェーンを使用すると、Claudeがステップを落としたり、誤って処理したりするのを防ぐことができます。
覚えておいてください： チェーンの各リンクにClaudeの注意が集中します！
デバッグのヒント：Claudeがステップを見逃したり、パフォーマンスが悪かったりする場合は、そのステップを独自のプロンプトで分離します。これにより、タスク全体をやり直すことなく、問題のあるステップを微調整できます。
プロンプトをチェーンする方法
- サブタスクを特定する：タスクを明確で順次的なステップに分割します。
- 明確な引き渡しのためにXMLで構造化する：XMLタグを使用して、プロンプト間でアウトプットを渡します。
- 単一タスクの目標を持つ：各サブタスクには、明確な単一の目的が必要です。
- 反復する：Claudeのパフォーマンスに基づいてサブタスクを改良します。
チェーンワークフローの例：
- 多段階分析：以下の法務と業務の例を参照してください。
- コンテンツ作成パイプライン：リサーチ → アウトライン → ドラフト → 編集 → フォーマット。
- データ処理：抽出 → 変換 → 分析 → 可視化。
- 意思決定：情報収集 → オプションのリスト化 → 各オプションの分析 → 推奨。
- 検証ループ：コンテンツ生成 → レビュー → 改良 → 再レビュー。
最適化のヒント：独立したサブタスク（複数のドキュメントの分析など）がある場合は、別々のプロンプトを作成し、スピードアップのために並行して実行します。
上級者向け：自己修正チェーン
Claudeに自身の作業をレビューさせるためにプロンプトをチェーンすることができます！これにより、特に重要なタスクでエラーを発見し、アウトプットを改良できます。
プロンプト1
| 役割 | 内容 |
|---|---|
| ユーザー | この医学研究論文を要約してください。 <paper>{{RESEARCH_PAPER}}</paper> 方法論、結果、臨床的意義に焦点を当ててください。 |
| Assistant {{SUMMARY}} | 方法論：500人の2型糖尿病患者を対象とした二重盲検RCT。グループA（n=250）は新規GLP-1/GIPデュアルアゴニストを、グループB（n=250）は標準的なGLP-1アゴニストを投与。24週間の試験で、主要評価項目はHbA1cの低下。 結果： - グループA：平均HbA1c低下1.8％ - グループB：平均HbA1c低下1.1％ - グループAの68％vsグループBの52％がHbA1c <7％を達成 - グループA：平均体重減少5.2kg - グループB：平均体重減少3.1kg 安全性：有害事象プロファイルは同様で、治療に起因する重篤な事象はなし。 臨床的意義：デュアルアゴニストは、標準治療と比較して、優れた血糖コントロールと体重減少を示した。特に肥満の糖尿病患者にとって、ゲームチェンジャーになる可能性がある。 |
プロンプト2
| 役割 | 内容 |
|---|---|
| ユーザー | 研究論文の要約にフィードバックを提供するのがあなたのタスクです。ここに医学研究論文の要約があります： <summary> {{SUMMARY}} </summary> ここに研究論文があります： <paper> {{RESEARCH_PAPER}} </paper> この要約の正確性、明確性、完全性をA〜Fの評価尺度でレビューしてください。 |
| Assistant {{FEEDBACK}} | 1. 正確性：A - HbA1c低下、体重減少などの主要統計を正しく報告。 - 安全性プロファイルと重篤な有害事象がないことを正確に指摘。 - 「ゲームチェンジャー」という主張は、有意に良好な結果によって正当化される。 2. 明確性：A- - 簡潔で構造化され、明確なセクションがある。 - 文脈のために比較言語（例：「Q1から3％増加」）を適切に使用。 - 軽微な問題：「RCT」、「GLP-1」、「GIP」などの頭字語が定義されていない。最初の使用時にスペルアウトすることを検討。 3. 完全性：B+ - 要求されたすべての領域（方法論、結果、臨床的意義）をカバー。 - 不足：グループのベースライン特性（適切にマッチングされていたか？）。 - 不足：二次評価項目（血圧、脂質など）の記載がない。 - 検討事項：長期的な意義や更なる研究の必要性。 全体的に、要約は正確で明確であり、研究を素早く理解するための重要な洞察を提供している。A+にするには、頭字語を定義し、グループのベースライン統計を記載し、二次的アウトカムに言及し、長期研究の必要性に簡単に触れる。 |
プロンプト3
| 役割 | 内容 |
|---|---|
| ユーザー | フィードバックに基づいて論文要約を改善するのがあなたのタスクです。ここに医学研究論文の最初のドラフトがあります： <summary> {{SUMMARY}} </summary> ここに研究論文があります： <paper> {{RESEARCH_PAPER}} </paper> ここにフィードバックがあります： <feedback> {{FEEDBACK}} </feedback> フィードバックに基づいて要約を更新してください。 |
| Assistant | 方法論：500人の2型糖尿病患者を対象とした二重盲検無作為化比較試験（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％vsグループBの52％がHbA1c <7％を達成 - グループA：平均体重減少5.2kg - グループB：平均体重減少3.1kg 二次評価項目では、両グループで血圧と脂質プロファイルの改善が見られ、グループAでわずかに良好な結果が示された。 安全性：いずれの治療にも起因しない重篤な事象はなく、有害事象プロファイルは同様であった。 臨床的意義：GLP-1/GIPデュアルアゴニストは、標準的なGLP-1療法と比較して、優れた血糖コントロールと体重減少を示した。これらの結果は、特に肥満の糖尿病患者にとって、大きな進歩となる可能性を示唆している。ただし、持続的な有効性と安全性を確認するため、また心血管系アウトカムへの潜在的な利点を調査するためには、より長期的な研究が必要である。 |
例
Claudeは、メールドラフトで提案された変更を提供するという指示を見逃していることに注意してください。
| 役割 | 内容 |
|---|---|
| ユーザー | あなたは当社の最高法務責任者です。この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
| 役割 | 内容 |
|---|---|
| ユーザー | あなたは当社の最高法務責任者です。この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ヶ月分の料金に設定されている。 - リスク：データ漏洩、知的財産の盗難、長期的なサービス障害の可能性に対して不十分。 - 影響：集団訴訟や規制上の罰金など、上限をはるかに超える可能性のある損害に対する補償が不十分。 |
プロンプト2
| 役割 | 内容 |
|---|---|
| ユーザー | 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ヶ月分の料金に上限。 - 懸念事項：データ漏洩、知的財産の盗難、長期的な停止に対して著しく不十分。 - 変更提案：一般的な責任については12ヶ月分の料金。データ漏洩、故意の不正行為、知的財産侵害については上限なし。 これらの変更は当社にとって譲れないものです。業界標準と、データセキュリティ、運用の卓越性、受託者責任へのコミットメントに沿ったものです。当社はパートナーシップの可能性を重視しており、これらに対処することで強固な基盤が築けると考えています。 貴社の法務チームにこれらの変更を検討し、組み込んでいただくようお願いいたします。相互理解と合意を確実にするために、さらに議論させていただければ幸いです。 敬具 {{CLO_NAME}} |
プロンプト3
| 役割 | 内容 |
|---|---|
| ユーザー | メールをレビューしてフィードバックを提供するのがあなたのタスクです。メールは以下の通りです： <email> {{EMAIL}} </email> トーン、明確性、プロフェッショナリズムについてフィードバックを提供してください。 |
| Assistant | 1. トーン： - 対立的ではなく、専門的かつ自信を持ったトーン。 - 「譲れない」という言葉の使用は強いが、問題の重要性を考えると正当化される。 - 「当社は重視しています」「喜んで議論させていただきます」などの協調的な言葉遣いが、強い語調のバランスを取り、建設的なトーンを維持している。 2. 明確性： - 優れた構成：各問題について現状、懸念事項、変更提案が明確。 - 「EBITDA」、「段階的サービスクレジット」などの専門用語は、B2B SaaSの文脈では適切。 - アクションアイテムは明確：ベンダーの法務チームが変更を検討し、組み込む。 3. プロフェッショナリズム： - 当社の要求だけでなく、相互の利益と業界標準に焦点を当てている。 - データセキュリティ、運用の卓越性、受託者責任などの幅広い責任に言及し、議論のレベルを上げている。 - さらなる議論を提案し、問題を理解し解決するためのコミットメントを示している。 全体的に、このメールは自信と協調性のバランスを適切に取っています。懸念事項を明確に述べ、具体的な解決策を提案し、専門的でパートナーシップ重視のトーンを維持しています。修正の必要はなく、送信を進めてください。 |
プロンプト1
| 役割 | 内容 |
|---|---|
| ユーザー | シニアソリューションアーキテクトとして、新しいエンタープライズSaaS製品のこのマルチテナンシー戦略をレビューし、分析してください。 <strategy> {{STRATEGY}} </strategy> スケーラビリティ、セキュリティ、コスト効率に焦点を当ててください。 |
| Assistant {{ANALYSIS}} | 1. スケーラビリティ： + テナントごとのデータベースシャーディングにより、競合が減少し、高い成長をサポート。 + マイクロサービスにより、コンポーネントの独立したスケーリングが可能。 - 共有アプリケーションサーバーは、極端な負荷の下でボトルネックになる可能性がある。 - アプリケーション層のオートスケーリングやロードバランシングについての言及がない。 2. セキュリティ： + シャーディングによるテナントデータの分離により、データ漏洩のリスクを軽減。 + 短い有効期限とリフレッシュトークンを持つJWTは業界のベストプラクティス。 - 暗号化（保存時、転送時）やキー管理についての言及がない。 - IAM戦略では、ロール、権限、RBACについての詳細が不足している。 3. コスト効率： + 共有アプリケーションサーバーにより、アイドルリソースのコストを削減。 + 頻度の低いタスクにサーバーレス関数を使用し、コストを最適化。 - テナントごとのDBは、最適化されたマルチテナントDBと比較して、大規模になるとコストが増加する可能性がある。 - コスト削減のための予約インスタンスやスポットインスタンスについての議論がない。 |
プロンプト2
| 役割 | 内容 |
|---|---|
| ユーザー | マルチテナンシー戦略の以下の分析に基づいて、エンジニアリングリーダーシップ向けの戦略レビュードキュメントを作成してください。 <strategy> {{STRATEGY}} </strategy> <analysis> {{ANALYSIS}} </analysis> エグゼクティブサマリー、詳細な分析、推奨事項を含めてください。 |
| Assistant {{STRATEGY_DOC}} | # SaaSエンタープライズ製品のマルチテナンシー戦略レビュー ## エグゼクティブサマリー 提案された戦略は、スケーラビリティとセキュリティの原則に関して堅実な基盤を示しているが、実装の詳細に欠けている部分がある。データの分離とコンポーネントレベルのスケーリングに優れているが、堅牢なアプリケーション層のスケーリングと高度なセキュリティ対策が不足している。コストの最適化は存在するが、大規模になると不十分になる可能性がある。ターゲットを絞った強化により、この戦略はエンタープライズSaaSの野望を効果的にサポートできる。 ## 詳細な分析 ### 1. スケーラビリティ：B+ 長所： - テナントごとのデータベースシャーディングは優れている。クエリの遅延を最小限に抑え、高いデータ成長をサポートし、シームレスなテナントごとのスケーリングを容易にする。 - マイクロサービスアーキテクチャにより、多様なエンタープライズワークロードを処理するために不可欠な、需要に基づいた個々のコンポーネントのスケーリングが可能になる。 短所： - 共有アプリケーションサーバーは、ボトルネックになるリスクがある。テナント数とトラフィックの増加に伴い、これらはすべてのテナントのパフォーマンスを低下させる可能性がある。 - アプリケーション層のオートスケーリングとロードバランシングの欠如は重大な見落としである。これらは、オーバープロビジョニングなしでトラフィックの急増を処理するために不可欠である。 ### 2. セキュリティ：B- 長所： - シャーディングされたデータベースは、強力なテナントデータの分離を提供し、テナント間のデータ漏洩や不正アクセスのリスクを軽減する。 - 短い有効期限とリフレッシュトークンを持つJWTは、OWASPのベストプラクティスに沿っており、トークンの脆弱性の期間を短縮する。 短所： - 保存時および転送時（TLS 1.3）のデータ暗号化についての言及がない。これはエンタープライズデータにとって譲れない条件である。 - キー管理戦略が欠落している。暗号化キー、JWTシークレット、DBクレデンシャルはどのように管理され、ローテーションされるのか？ - IAMの深さが不足している。細かい権限制御（ABAC）のための明確に定義されたロールを持つRBACと、エンタープライズIDプロバイダー（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. 大規模な場合のシャーディングとの比較で、カラムナーのマルチテナントDB（Snowflakeなど）を評価する。 b. アプリケーションサーバーには予約インスタンス、重要でないワークロードにはスポットインスタンスを使用する。 c. オーバープロビジョニングを避けるために、プロアクティブなモニタリングとライトサイジングを実装する。 4. 概念実証（PoC）：本格的な実装の前に、高スケールのシミュレーションでPoCを実施する。 a. コストとパフォーマンスについて、シャーディングされたDBと最適化されたマルチテナントDBをテストする。 b. エンタープライズレベルのトラフィックスパイクをシミュレートして、アプリケーション層のストレステストを行う。 c. データの分離とアクセス制御に重点を置いて、サードパーティのセキュリティ監査を実施する。 これらの強化により、マルチテナンシー戦略はエンタープライズグレードになる：スケーラブル、セキュア、コスト効率の高いものになる。PoCにより設計の選択を検証し、エンタープライズクライアントに自信を与えることができる。 |
プロンプト3
| 役割 | 内容 |
|---|---|
| ユーザー | この戦略レビュードキュメントを明確性、実行可能性、エンタープライズの優先事項との整合性の観点で評価してください。 <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+に引き上げることができる。技術的な深さと明確な説明により、技術系と非技術系の両方のリーダーシップにとって非常に効果的なものとなっている。素晴らしい出来栄えです！ |