学習目標:
- コード生成タスクにおけるプロンプトのベストプラクティスを習得する
- 文書作成と要約のための効果的な戦略を学ぶ
- データ分析と抽出のためのプロンプトテクニックを理解する
プロンプトの基本構造、Few-shot、CoT、デバッグ方法について学んできました。これらは汎用的なスキルです。しかし、タスクの種類によって独自の特性と落とし穴があり、それぞれに適した戦略が求められます。
コード生成では、入力・出力・エッジケースを明確にする必要があります。文書作成では、対象読者とトーンを定義する必要があります。データ抽出では、欠損値の処理と形式の一貫性を保つ必要があります。このレッスンでは、3つの一般的なタスクタイプに対する具体的なテクニックを説明します。1
コード生成は、AIの最も一般的な使い方の1つです。重要なポイントはシンプルです:要件を明確に書けば、AIは実際に使えるコードを書くことができます。1
優れたコード生成プロンプトには以下を含めるべきです:1
❌ 曖昧なプロンプト:
AIは推測するしかありません:どんなデータ?どう処理する?
✅ 明確なプロンプト:
このプロンプトは、入力、出力、エッジケース、コードスタイルを明確に定義しているため、AIは最初の試行で使用可能なコードを書くことができます。
これには研究の裏付けがあります: "prompts with explicit specifications reduced the need for back-and-forth refinements by 68%"1 — 詳細を明記すれば、すぐに使えるコードが得られる可能性が大幅に高まります。
プラクティス1: 入出力データ構造を明確に書く
「データを処理する」と言わないでください。「入力は List[Dict[str, Any]]、出力は Dict[str, int]」と言ってください。
プラクティス2: 例でエッジケースを明確にする
プラクティス3: コードスタイルを指定する
プラクティス4: やってほしくないことを言う
AIにコードレビューを依頼する場合、レビュー観点を明示的に指定します:
レビュー観点を指定すれば、AIは重要でない詳細に時間を浪費しません。
文書作成は多岐にわたります:技術文書、議事録、記事要約、レポート生成など。
❌ 曖昧なプロンプト:
✅ 明確なプロンプト:
このプロンプトは、対象読者(フロントエンドエンジニア)、目的(クイックスタート)、構造(4つのパート)、トーン(実用的)を明確に定義しています。
プラクティス1: 読者の背景を明確に書く
プラクティス2: 構造テンプレートを提供する
プラクティス3: 詳細レベルをコントロールする
データ分析には、テキストから構造化情報を抽出すること、分類、フィルタリング、カウントが含まれます。
信頼性の高いデータ抽出プロンプトは、4つのことを事前に明記します:
❌ 曖昧なプロンプト:
✅ 明確なプロンプト:
例は、完全なケースと欠損ケースの両方をカバーしているため、AIは何かを見つけられないときに、でっち上げるのではなくnullを出力することを理解します — この自信を持って事実を捏造する習慣はハルシネーションと呼ばれます。
プラクティス1: 各フィールドの許可値を明確に書く
プラクティス2: Few-shotで形式を標準化する
構造化データを抽出する場合、2-3個の例は文章による説明よりも効果的です(レッスン3のFew-shotテクニック)。
プラクティス3: エッジケースの処理方法を言う
プラクティス4: データ検証を追加する
どのようなタスクであっても、これまでのレッスンで学んだ一般原則は依然として有効です:
このレッスンのタスク固有の戦略は、これらの一般原則の上に重ねられるターゲットを絞った最適化です:
異なるタスクには異なるプロンプト戦略が必要です:
これらの戦略は、これまでのレッスンで学んだ一般的なスキル(4つの要素、Few-shot、CoT、デバッグ)の上に構築されています — 特定のタスクタイプ向けの最適化です。実際には、目の前のタスクに合った組み合わせを選んでください。
コース全体のまとめ
プロンプトエンジニアリング基礎の6つのレッスンすべてを修了しました:
これで完全なツールボックスが手に入りました。次のステップは実践です:自分の仕事から実際のタスクを選び、これらのテクニックを適用し、何が起こるかを観察し、改善を続けてください。プロンプトエンジニアリングは実践によって磨かれるスキルです — コースワークはここで終わりますが、実際の学習は実際に使い始めたときに始まります。
Prompt Engineering for Code Generation — https://graphite.com/guides/better-prompts-ai-code ↩ ↩2 ↩3 ↩4
タスクA: 二分探索を実装するPython関数をAIに生成させる タスクB: 技術ホワイトペーパーを経営陣向けの2ページレポートにAIに要約させる タスクC: 顧客メールのバッチから顧客名、問題タイプ、緊急度をAIに抽出させる
各タスクについて、以下に答えてください:
シナリオオプション:
シナリオ1: コードレビューアシスタント
シナリオ2: 学習ノート生成器
シナリオ3: 顧客フィードバックアナライザー
要件: プロンプトには次を含める必要があります:
ユーザーデータを処理するPython関数を書いてください次の要件でPython 3.10関数を書いてください:
動作:- 入力: 辞書のリスト、各辞書には name (str)、age (int)、email (str) を含む- 出力: age < 18 のユーザーを削除し、残りのユーザーのemailを返す(重複排除)
要件:- 型ヒントを含める- 欠損フィールドを処理する(辞書にageまたはemailがない場合、そのユーザーをスキップ)- Python標準ライブラリのみを使用- 使用方法を説明するdocstringを含める
例:入力: [{"name": "Alice", "age": 20, "email": "a@example.com"}, {"name": "Bob", "age": 15, "email": "b@example.com"}, {"name": "Charlie", "age": 25, "email": "a@example.com"}]出力: ["a@example.com"]次の特殊ケースを処理してください:- 空のリスト入力 → 空のリストを返す- None値 → スキップする- 重複値 → 最初の出現を保持するコードスタイル要件:- 型ヒントを使用する- docstringを含める(Googleスタイル)- 過度なコメントを避ける(自明なコードを説明しない)- 可読性を優先し、パフォーマンスは二の次禁止事項:- グローバル変数を使用しない- 外部依存関係を使用しない(標準ライブラリのみ)- テストコードを書かない(main関数のみ)以下のPythonコードをレビューしてください。重点項目:
1. 正確性: ロジックエラー、エッジケース処理2. パフォーマンス: 時間計算量分析、潜在的なボトルネック3. セキュリティ: SQLインジェクション、XSS、入力検証
コードスタイルや命名についてはコメント不要(すでにlintチェック済み)。
見つかった各問題について、以下を記述してください:- 場所(行番号またはコードスニペット)- 問題タイプ(バグ / パフォーマンス / セキュリティ)- 具体的な影響(どのような条件で壊れるか)- 修正案
コード:[コードを貼り付け]この技術文書を要約してくださいあなたは技術ライターで、複雑な技術文書を誰でも理解できる要約に変換することが得意です。
タスク: 以下のAPI文書を、フロントエンドエンジニア向けのクイックスタートガイドとして要約してください。
対象読者: JavaScriptは知っているが、このAPIを使ったことがないフロントエンドエンジニア。
出力形式:1. このAPIが何をするかを1文で説明2. 最もよく使われる3つの機能(各機能について:目的 + コード例)3. 1つの完全な使用シナリオ例4. よくある間違いと修正方法(2-3個)
トーン: 直接的で実用的、マーケティング用語は不要。
長さ: 800語以内。
元の文書:[文書を貼り付け]対象読者:- 役割: プロダクトマネージャー- 技術レベル: コーディングはしないが、基本的なソフトウェアアーキテクチャの概念は理解している- 読む目的: このアプローチを採用するかどうかを決定する次のように整理してください:
## 背景なぜこのアプローチが必要か(1段落)
## オプション比較| オプション | メリット | デメリット | コスト ||-----------|---------|----------|-------|| ... | ... | ... | ... |
## 推奨事項どのオプションを選ぶべきか、その理由(2-3段落)
## リスクこのアプローチの主なリスクと対処方法(リスト)詳細レベル:- 各ポイントを1-2文で説明し、展開しない- 実装の詳細はスキップし、ビジネスへの影響のみをカバー- 具体的なコードや技術用語を引用しないあなたはプロジェクトアシスタントで、会議の録音や議事録から重要なポイントを抽出することが得意です。
タスク: 以下の議事録から会議メモを作成してください。
出力構造:1. 会議情報 - 日付: YYYY-MM-DD - 参加者: [リスト] - トピック: [1文]
2. 議論(優先順に並べる) 各項目について: - 問題の陳述(1文) - 議論のポイント(2-3個) - 決定事項(明確な結論;未決定の場合は「保留中」と書く)
3. アクションアイテム 各項目について: - タスクの説明(動詞で始まり、実行可能) - 担当者 - 期限
制約:- 明確な結論がある議論のみを記録し、雑談はスキップする- すべてのアクションアイテムは確認可能でなければならない(明確な成果物がある)- 合計500語以内
議事録:[議事録を貼り付け]この求人情報から重要な情報を抽出してください求人情報から次のフィールドを抽出し、JSONで出力してください。
フィールド定義:- position (string): 職種名- location (string): 勤務地(市 + 区、ある場合)- experience (string): 必要な経験(元の表現を保持、例:「3-5年」、「不問」)- salary (string): 給与範囲(単位を保持、例:「月給20-30万円」、「応相談」)- company (string): 会社名
欠損値の処理:- フィールドが元のテキストにない場合、nullを出力- 欠落情報を推測または推論しない
例1:入力: Javaエンジニア急募、深圳南山区、3年以上の経験、月給25-35万円、XX Tech出力:{ "position": "Javaエンジニア", "location": "深圳、南山区", "experience": "3年以上", "salary": "月給25-35万円", "company": "XX Tech"}
例2:入力: フロントエンドデベロッパー、リモート、給与応相談出力:{ "position": "フロントエンドデベロッパー", "location": "リモート", "experience": null, "salary": "応相談", "company": null}
次を処理してください:[求人情報を貼り付け]フィールド: sentiment許可値: 「positive」/「negative」/「neutral」のいずれか1つ出力禁止: good、upbeat、favorableなどの他の単語特殊ケース:- 混合センチメントを含む文章(「良い製品だが、高すぎる」) → 「neutral」に分類- 純粋な質問(「これはどう動作しますか?」) → 「neutral」に分類- テキストが短すぎる(3語未満) → nullを出力検証ルール:- salaryフィールドには数値を含む必要がある- experienceがnullでない場合、「年」または「不問」を含む必要がある- locationは空文字列にできない — 値またはnull
抽出されたデータが検証ルールに失敗した場合、無効なデータではなくエラーメッセージを返してください。