- Anthropicが提供するプロンプトエンジニアリングのチュートリアルで、Claudeモデルに最適化されたプロンプト作成法をインタラクティブに段階別で案内
- ユーザーは良いプロンプトの構造や失敗事例、そして効率的な改善手法を自ら練習して身につけられる
- 各章に実習例と解説が含まれており、実戦に近い体験を提供
- 初級から上級までの9章と付録で構成され、実際にプロンプト作成と問題解決の能力を養える
- このチュートリアルはGoogle Sheets版も提供されており、アクセシビリティと活用度を高めている
Anthropicのプロンプトエンジニアリング インタラクティブチュートリアル
- AIモデルであるClaudeに最適化されたプロンプト設計の知識を提供するオープンソース学習資料
- OpenAIベースのチャットボット学習フローに似ているが、Claudeモデルの特長と限界の理解、そして実践練習中心の構成により、他のチュートリアルと比べて実務への適用可能性と実用性に優れている
- とりわけ実際にプロンプト作成と結果の実験を並行して進められるため、初心者エンジニアに大きな利点がある
コース紹介と目標
- このチュートリアルはClaude内で最適なプロンプトを設計し活用する方法を段階的に案内する
- コース完了時にユーザーは以下を習得できる
- 効果的なプロンプト構造の理解
- 代表的な失敗パターンの認識と優先的な改善法（80/20の法則）
- Claudeモデルの強みと弱みの把握
- 多くの一般業務に適用できるプロンプト構築能力
コース構成とコンテンツ
- 9章（初級〜上級）と発展的な付録で構成されている
- 各章では理論説明と実践演習をあわせて提供
- 各パートの最後には"Example Playground"でプロンプトを直接入力し、応答の変化を実験できる場が用意されている
- すべての例に対して解説キーが含まれている
- チュートリアルの基本モデルは最も軽量で高速かつ低コストなClaude 3 Haikuで、必要に応じてより高性能なSonnetおよびOpusにも言及されている
- Google Sheets拡張版としても活用でき、学習へのアクセス性が高い
カリキュラム目次
- 初級
- Chapter 1: 基本的なプロンプト構造
- Chapter 2: 明確で直接的な指示の書き方
- Chapter 3: 役割を与える
- 中級
- Chapter 4: データと指示の分離
- Chapter 5: 出力フォーマットの指定とClaude向けの対話化
- Chapter 6: 事前思考（段階的な思考の導出）
- Chapter 7: 例の活用法
- 上級
- Chapter 8: **ハルシネーション（Hallucination）**の防止
- Chapter 9: 複雑なプロンプトの構築（業界別事例）
- 例: チャットボット、法務サービス、金融サービス、コーディングなど、さまざまな業務別の実践適用課題を扱う
- 付録
- 標準的なプロンプトを超える方法
- プロンプトチェイニング、ツール利用、検索/検索結果の統合などの発展技術
活用ガイド
- チュートリアルは各章を必ず順番どおりに進めることが推奨される
- 実践中心の演習と段階別の解説により、初心者エンジニアでも実際に使えるプロンプト設計力を自然に身につけられる
- すべてのプロダクト名およびモデル名は原文どおりに表記され、英語ベースの業務環境でもそのまま活用できる
追加の特徴とオープンソース情報
- Github上で19,400件以上のStarsと1,900件のForkを記録中
- 主な開発言語はJupyter Notebookで、一部Pythonコードも含まれる
- 別途配布パッケージはなく、すべての資料はオープンソースとして自由に参照できる
1件のコメント
Hacker Newsの意見
この文脈で「engineering」という言葉が使われるのはとても気に障る。本物のエンジニアリングとは思えない。エンジニアリングとは、長年蓄積された知識や物理法則、規則などに基づいて予測可能な形で設計し作ることだが、今やっているのは結果が出るまで手当たり次第に試しているだけにすぎない
どんな単語にも複数の意味があると思う。「prompt engineering」における「engineering」は、「social engineering」におけるそれに近いが少し違うニュアンスだ。例えば Google の engineering の定義 の2番目は「策略を用いて目的を達成する行為」だし、Merriam-Webster の3番目の定義や、collins dictionary、yourdictionary などを見ても、「巧妙な操作、計画を立てること」のような非技術的な意味がはっきり存在している。単語として確立された副次的意味だ
俺はシリアルを食べながらシリアル箱のスペックを確認している。毎朝そうしているし、バスに乗るエンジニアリングスキルも使っている。なぜなら俺は prompt engineering で生計を立てている人間だからだ。最近はあまりにも多くの言葉が本来の意味を失っていっている気がして、自分だけがイラついているわけではないと分かって少し安心した
私はカナダのやり方、つまりエンジニアという肩書きを使うには各州の技術者規制機関から免許を受けなければならない制度のほうがずっと好ましいと思っている。アメリカでは、あらゆるソフトウェア開発者、整備士、HVAC 設置業者、配管工までエンジニアと呼ぶのは行き過ぎだと感じる
この論争は実際、多くの「engineering チーム」がやっている仕事にもそのまま当てはまると思う。エンジニアがやればその仕事はすなわちエンジニアリングだ、という暗黙の前提があり、さらに言えばソフトウェア自体がソフトウェアエンジニアリングと呼ぶに値するのかという深い前提もある
「Engineering」という言葉は、人々に単なる文章書きではないという印象を与えるためのレトリックだと思う。正直、「prompt writing」と言うと何となく軽く見られそうだし、「soft」skill という言葉を嫌う人にはなおさら居心地が悪いだろう
今日の「初心者向け錬金術」エピソードみたいだ。ベンチマークセットでランダムシードに 7 を与えたらアルゴリズム速度が 30% 上がったという話を思い出す。8 でも 6 でもなく 7 だった
この記事を読んでいて、自分にとって重要な気づきは、出力順序をどうするか考えることだった。例えば、回答する前に証拠やインジケーターを先に抽出するよう求めることだ。LLM が確率的オートコンプリートだということは分かっていたが、こういう形でのプライミングは考えたことがなかった
このやり方は reasoning モデルには当てはまらないかもしれない。reasoning モデルは答えを出す前に望ましいやり方で思考過程をたどるので、出力順序が精度に与える影響は小さい。これがたぶん OpenAI が reasoning を強制しようとしている理由なのではないかと思う
私は普通、オンラインで見つけたソースの短い引用をまず抽出してくれと頼む（関連がある場合）。そうすると情報の信頼性をある程度補える。最近、うちの組織で Cloudflare Zero Trust を構築したときにとても必要だったやり方だ
逆に先に答えを出させてから根拠を求めると、モデルは適当な答えを出してそれをもっともらしく正当化する「でたらめモード」に入る。むしろ客観的に長所と短所を先に挙げさせ、その後で結論を出させたほうが、はるかに慎重に答えてくれる
この投稿のタイトルには「(2024)」を入れたほうがいいと思う
難しい問題に対する自分なりの最高の prompt engineering のコツは「広げてから絞る」ことだ。具体的には、まず問題と状況を明確に提示し、AI に取りうるすべての選択肢とアプローチを分析・探索させて情報を最大限広げる。そのうえで各方法の長所と短所を列挙し、最も適切な解決策を選ばせる。簡単な問題ならこうしたことを全部省いていきなり尋ねても答えは出るが、難しい問題で最初から答えだけを求めると、もっともらしく作り話をしてしまうので、必ず現実的な根拠から始める必要がある。だから、具体的な文脈 - 選択肢分析 - pros & cons - 最終選択という流れが必要だ
タイトルに 2024 を追加すべきという意見
私たちは、自分たちが直接やっていた仕事を AI に教え、さらにその仕事を AI にうまくやらせる方法を学んでいるのだと思う。もしこの技術がアメリカ全体の経済に支えられなければ、まるで熱気球のように浮かび上がったあと一気にしぼんでしまうかもしれない
他のコメントと同様、これが正統派のエンジニアリングのようには感じられない。ただ、Anthropic がモデル解釈可能性の分野でかなり面白い研究をしてきたとは思う。もし そのツール が public API として公開されれば、プロンプトに応じたモデル内部状態の差を比較できるようになり、より体系的なチューニングのためのフィードバックループが作れるかもしれない
このチュートリアルは3つのモデル（Sonnet、Haiku、Opus 3）のために書かれている。今日でも通用する教訓はいくつかあるが、より賢い RL モデル（Sonnet 4.5 など）にはそれほど重要でない内容もある。参考までに言うと、Claude 3 Haiku は最も小さく高速で安価なモデルで、Sonnet と Opus はより知的で、Opus が最も優れている