ハクソク

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

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

2025年10月12日原文(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インストーラー、配管工がエンジニアだってのはおかしいよ。

Hacker Newsで議論の続きを見る