ハクソク

世界を動かす技術を、日本語で。

Anthropicのプロンプトエンジニアリングチュートリアル

226日前原文(github.com)

概要

  • AnthropicのPrompt Engineering Interactive Tutorial Course の紹介
  • Claudeで最適なプロンプト設計 を段階的に学習
  • 基礎から応用まで9章構成、各章に練習問題付き
  • Claude 3 Haikuモデル を中心に解説
  • より使いやすいGoogle Sheets版 も推奨

Anthropic Prompt Engineering Interactive Tutorial Course：概要と目標

  • 本コース は、Claudeを用いた 最適なプロンプト設計手法 の習得を目的
  • 良いプロンプトの基本構造 のマスター
  • よくある失敗パターン の把握と、 80/20ルール による対策法の習得
  • Claudeの強み・弱み の理解
  • 一般的なユースケース に対応した プロンプト作成力 の養成

コース構成と内容

  • 全9章構成、各章ごとに レッスンと練習問題 を用意
  • 章順に進める学習スタイル を推奨
  • 各レッスン末尾に Example Playground を設置
    • 実際に プロンプトの書き換え・動作検証 が可能
    • 解答例 も参照可能
  • Claude 3 Haiku （最小・最速・最安モデル）を使用
    • Claude 3 Sonnet/Opus （より高性能モデル）も存在
      • Opusが最も高性能
  • Google Sheets版チュートリアル も提供
    • Claude for Sheets拡張機能 利用
    • ユーザーフレンドリーな操作性

学習内容：目次

  • 初級編
    • Chapter 1: Basic Prompt Structure　基本構造
    • Chapter 2: Being Clear and Direct　明確かつ直接的な指示
    • Chapter 3: Assigning Roles　役割の割り当て
  • 中級編
    • Chapter 4: Separating Data from Instructions　データと指示の分離
    • Chapter 5: Formatting Output & Speaking for Claude　出力形式・Claudeの言い方
    • Chapter 6: Precognition (Thinking Step by Step)　段階的思考
    • Chapter 7: Using Examples　例示活用
  • 上級編
    • Chapter 8: Avoiding Hallucinations　誤情報の回避
    • Chapter 9: Building Complex Prompts (Industry Use Cases)　複雑な業界向けプロンプト設計
      • Chatbot用複雑プロンプト
      • 法務サービス用プロンプト演習
      • 金融サービス用プロンプト演習
      • コーディング用プロンプト演習
  • 完了後 ：Congratulations & Next Steps　修了と次のステップ
  • 付録 ：Appendix: Beyond Standard Prompting　標準を超えたプロンプト技法
    • Chaining Prompts　プロンプト連鎖
    • Tool Use　ツール活用
    • Search & Retrieval　検索・情報取得

受講の流れと推奨事項

  • 章ごとの順番通りに進める学習 を推奨
  • Example Playground での実践
  • Google Sheets版 の利用推奨
  • 準備ができたら01_Basic Prompt Structure から開始

このチュートリアルは、 Claudeを最大限活用するための体系的学習 を提供。 基礎から応用まで段階的に理解 し、 実践的なプロンプト設計力 を身につけることが可能。

Hackerたちの意見

これは3つのモデル（Sonnet、Haiku、Opus 3）について書かれています。今日でも関連するレッスンもあれば、Sonnet 4.5のようなよりスマートでRL化されたモデルには役に立たないものもあります。 > 注意: このチュートリアルでは、私たちの最小で最速、かつ最も安価なモデルであるClaude 3 Haikuを使用しています。Anthropicには、Haikuよりも賢いClaude 3 SonnetとClaude 3 Opusの2つのモデルがありますが、Opusが最も賢いです。

└

そうですね、第3章と第6章は今はあまり関係ないかも。他に何かある？特に、繰り返し使われるプロンプトを書いている人を想定して、精度の最適化が必要な場合について。

これを読んで気づいた大きなポイントは、出力の順序について考えることです。つまり、質問に答える前に証拠や指標を出すように頼むことです。LLMが確率的なオートコンプリートだってことは知ってましたが、プライミングに使うことを考えなかったんですよね。

└

さらに、逆の行動は非常に悪いです。答えを求めてそれを正当化させると、ランダムな返信が出てきて、次にそれを合理化するための無意味なモードに入ります。中立的な視点から客観的に長所と短所をリストアップさせてから答えを宣言させると、実際に考えられたものが得られます。

└

これは推論モデルには関係ありません。なぜなら、彼らは答えを出す前に問題を好きな順序で考えるからです。最終的な答えを出すときに自分の思考に「参照」できるので、出力の順序は正確さにあまり関係ありません。この相対的な堅牢性が、OpenAIがみんなに推論を強制しようとしている理由かもしれません。

└

私は通常、オンラインで見つけた情報の短い引用から始めるように頼みます（関連する場合）。これにより、文脈が「リアル」な情報に基づくものになり、幻覚ではなくなります。これが関連する状況ではかなりうまくいきます（最近、私たちの組織のためにCloudflare Zero Trustを設定するセッションを通じて、これは非常に必要でした）。

提出タイトルには「(2024)」を入れるべきです。

この文脈で使われる「エンジニアリング」という言葉が非常にイライラします。ここには「エンジニアリング」はありません。エンジニアリングは、知識や物理法則、長年にわたって学んだルールを適用して、予測可能に設計・構築することです。これは、壁に何かを投げてみて、くっつくかどうかを見るようなものです。

└

俺はこれを「バイブプロンプティング」って呼んでる。モデルにちょっとした変更を加えるだけで、以前のプロンプトが使えなくなったり、新しいプロンプトの前提が無効になったりするんだよね。

└

これ、エンジニアリングチームに降りかかる多くの仕事についても同じことが言えるよね。エンジニアがやることはすべてエンジニアリングだっていう暗黙の前提があるし、そもそもソフトウェア全体がソフトウェアエンジニアリングと呼ばれるに値するっていう深い前提もある。

└

その気持ちわかる。でも、微積分の統合って何だっけ？ :)

└

カナダのアプローチが好きなんだ。エンジニアって言葉がタイトルに入るには、その州のエンジニアリング規制機関からライセンスを取得しなきゃいけないんだよね。アメリカみたいに、すべてのソフトウェア開発者や整備士、HVACインストーラー、配管工がエンジニアだってのはおかしいよ。

└

ここで言われてることには同意だな。ただ、これを真剣にやるときはエンジニアリングが必要だよ。テストセットを作って、それに対するメトリクスを設計するんだ。システムの変更、モデル、推論パラメータ、コンテキスト、プロンプトテキストなど、あらゆる変更について厳密に測定することが大事。実際の統計テストを使って、必要に応じて多重比較の調整も忘れずに。初期プロンプト設計時の仮定が将来的にも有効であることを監視して、予期しない変化にはアラートを出すべきだよ。この記事にはそのアドバイスが全然載ってないのが驚きだね。

今日の「初心者向けアルケミー」のエピソード！思い出すな、ランダム数生成器に7を種として使うと、ベンチマークセットのアルゴリズムを30%速くできたことがあったんだ。8じゃなくて、6でもなくて、7なんだよ。

他のコメントに同意するけど、これがエンジニアリングに感じられないのは確かだね。ただ、Anthropicはモデルの解釈可能性に関して面白いことをやってるよね。もしそのツールが公開APIを通じて使えるようになったら、少なくとも異なるプロンプトでモデルの内部状態を比較して、システマティックに調整するフィードバックループを作り始められるかも。[0] https://www.anthropic.com/research/tracing-thoughts-language...

ここでの「エンジニアリング」は、単に文章を書いてるだけじゃないって人を納得させるために、修辞的にデザインされてる感じがする。「プロンプトライティング」って言葉は、同じように「ソフト」スキルがあると思ってる人には悪く聞こえるだろうね。

難しい問題に対するプロンプトエンジニアリングのベストアドバイスを教えるよ。まずは広げてから絞り込むこと。具体的な問題とコンテキストを述べて、それからAIに徹底的な分析をさせて、問題解決のためのすべての可能な選択肢やアプローチを調査させるんだ。関連情報をウェブで探すように頼む。そして、各アプローチの長所と短所をリストアップさせて、最後にどの一つか二つの解決策が今の問題に最も関連性があるかを選ばせる。簡単な問題なら、これをスキップして直接聞けばいいけど、難しい問題の場合は、直接解決策を求めると、適当なことをでっち上げて、その理由もでっち上げちゃうんだ。まずは現実に基づかせる必要があるから、具体的なコンテキストと問題、選択肢の徹底的な分析、長所と短所のリストアップ、そして勝者を選ぶって流れが大事だよ。

└

これってAI以外の問題解決にも当てはまるんじゃない？

モデルが良くなってから、プロンプト周りのワークフローがかなり緩くなっちゃった。特にClaude 4.5（その前の4も）では、タスクについて少しコンテキストが入ると、短くて会話っぽくするようにしてる。でも、ちゃんと監視はしてるよ。もし脱線したら、Escを押してコース修正する感じ。で、コンテキストが全くない状態から始めるときは、最初にもう少し詳細を入れて、初期プロンプトの最後を「コードで何を話してるか見える？」って質問で締めることが多いかな。大きなことになる場合は、プランニングモードを使うよ。

このAIの狂気、毎日バカになっていくな…