本記事では、AWS re:Invent 2025 のセッション『Mastering agentic prompt engineering』に参加し、私が学んだ内容をもとにポイントをまとめました。

本記事はセッションを聴講し内容を整理・要約したものです。
聴き取り不備に起因した誤認や、当方の知識不足に起因した誤りが含まれている可能性があります。
あらかじめご了承ください。

１．セッションの概要

このセッションは、プロンプトエンジニアリングの手法に関する体系的な説明と、プロンプトを作成するうえでのベストプラクティスや具体的なテクニックを解説する内容でした。
また、解説の大半は特定のサービスに依存しない構成となっていたため、AI を利用する幅広い人に参考となるものでした。

なお、講師（スピーカー）が今回のセッションの中で最も重要な内容は、 「AI にプロンプトを与える際にプロジェクトの本質を説明する情報を与えること」 と説明していましたので、該当箇所はぜひ読んでいただければと思います。

セッションタイトル
『Mastering agentic prompt engineering [REPEAT] (DVT335-R)』
セッション説明

Dive into the art of prompt engineering and discover how to harness the full potential of Amazon Q Developer, AWS's cutting-edge generative AI service. Learn techniques to craft compelling prompts that yield remarkable software development task execution and maximize the value of your agentic AI development experience.

（翻訳）
プロンプトエンジニアリングの技術を深く掘り下げ、AWS の最先端生成 AI サービスである Amazon Q Developer の可能性を最大限に引き出す方法を探求します。
ソフトウェア開発タスクを高い精度で実行させるための効果的なプロンプト作成手法を学び、エージェント型 AI 開発体験の価値を最大化しましょう。

セッションの形式 : Chalk talk
レベル : 300 – Advanced

２．セッションのポイント

本セッションでは次の大きく4つのポイントについて説明がありました。

プロンプトエンジニアリングとは何か
プロンプトエンジニアリングの基礎となる考え方
プロンプト作成のベストプラクティス
プロンプト構築における高度なテクニック

３．各ポイントの説明・要約

1. プロンプトエンジニアリングとは何か

一般にプロンプトエンジニアリングとは、「生成AIから望ましい出力を得るためのプロンプトを作成する技術」を指す。

プロンプトエンジニアリングを行う上で最も重要、かつ意識すべき点は「ゴミを入れればゴミが出る」（“Garbage in, garbage out”）という考え方である。

つまり、「AI に提供する情報の質がそのまま出力の質に直結する」ということである。

入力情報の質を高めるには、コンテキストと制約を明確にすることが重要である。

AI は確率的に動くので確実なものはないが、適切な入力情報を与えることで結果の一貫性を高めることができ、期待に近い回答を得やすくなる。

2. プロンプトエンジニアリングの基礎となる考え方

プロンプトエンジニアリングの主要構成要素は次の3点である。

生成内容を明確に指示する
AI に「"何を" "なぜ" やらせるのか」を指示する。

具体的には、"何をしてほしいのか"という明確な指示を背景情報と入力データの形式・ポイントを合わせてAIに与える。

例えば、「WEBアプリケーションで言語はTypeScript（フロントエンド） + Java（バックエンド）で構成されている」といった背景情報を与え、「このようなテストを作成してほしい」といった指示を定義し、「インプットとなるsteeringファイルを指定する」といったものである。
出力の「形」と「制約」を指定する
精度と再現性を高めるための改善の実施
- ステップバイステップの推論指示
  Chain of Thought などを利用してステップバイステップの推論指示をする。
- 繰り返しの改善
  多くの場合、一度で完璧なプロンプトにはならない。そのため、何度も改善を重ねる必要がある。

3. プロンプト作成のベストプラクティス

プロンプト作成のベストプラクティスには次のようなものがある。
なお、毎回全てを使う必要はなく、状況や内容に応じて使い分ければよい。

ロール（役割）の指定
LLM は多様なドメインのあらゆるデータで学習している。
よって、一貫性が必要な時には LLM の役割を特定の領域に絞り込むほうが良い。

たとえば、
・「あなたは経験豊富な Java 開発者です。このプログラムを解析してください」
・「あなたは PostgreSQL の専門家です。このテーブルの Create table 文を作成してください」

このような指定をすることで、LLM が扱う概念空間を絞ることができ、結果的にノイズを減らすことが期待できる。
イメージとしては、LLM の概念空間は何百万という次元を持つベクトル空間である。特定のトピックに関連する内容は空間のある一角に集まり、別のトピックは別の位置に集まる。
もしプロンプトに複数のテーマを混在させると、LLM の位置づけがその中間に移動してしまい、最良の領域からずれてしまうことがある。
だからこそ、スコープを絞ることが重要なのである。
タスクに必要な情報だけに限定すれば、モデルはその局所的な領域で最も適切な回答を返してくれるようになる。
コンテキスト
LLM は私たちのプライベートなデータではなく幅広いデータで学習されている。
そのため、LLM に特定のタスクを行わせたい場合、コンテキストを与える必要がある。
たとえば、自身のプロジェクトのコードや情報を渡すなど、そこで何をしようとしているのかを明確に説明する、ということである。

ここで重要な注意点は、「多ければ良い」というわけではない、という点である。
コンテキストが少なすぎると、LLM は利用者が何をしたいのか推測しなければならなくなる。
一方で、コンテキストを与えすぎると、LLM にとって「どの情報が関連しているのか」を特定するのが非常に難しくなり、生成の精度が落ちる。
また、トークンが増えるのでコストの無駄にもなる。
タスク
タスクとは、何をしたいのかという「やりたいこと」を定義する部分のことである。つまり「AI に何をしてほしいのか」をはっきり示す部分がタスクである。
タスクはできるだけ具体的にする必要がある。
そしてこれをコンテキストで補強する。
つまり、コンテキストはタスクそのものではなく、タスクを正確かつ環境に適合させるための補助情報である。
出力形式
出力形式も制御することができる。
例えば、「コードとしてチャットに出力して」と指示し、ファイルを直接変更させずにコードを出させつつ、このコードが何をしているのか、その利点や欠点などを説明させる、といった使い方もできる。

4. プロンプトを構築する際の高度なテクニック

プロンプトを作る際のテクニックは以下の通り。

Chain of Thought（思考の連鎖）
Chain of Thought とは「モデルに自身の思考過程を説明させる」ことである。
通常は「ステップバイステップで考えて」や「根拠を説明して」などのトリガーで行わせることができる。
この手法は AI の応答の仕方に変化をもたらす。
複雑なシナリオでは、「答える前に考えてほしい」「理由を説明せよ」と指示することで、AI は実行するステップを順に検討するようになる。仮に、途中で矛盾や問題があれば応答前に AI が自身で検出・修正することが期待できる。
新しいセッションへの切り替え
意図して新しいセッションへ切り替えることもテクニックのひとつである。
コンテキストには「チャット履歴」も含まれる。そのため、会話の途中で主題・テーマを変えると、それまでのやり取りが応答に影響し、意図した回答を得られない可能性がある。
つまり、プロンプトの主題を変えたい場合は新しいセッションを開始し、前の会話が結果に影響しないようすべきである。

また、AI とのやり取りをしばらく繰り返すとループに入り、回答も正しくなくなることがある。
この場合も新しいセッションに切り替えるべきである。
メタプログラム
モデル自身に対して
- 「業務要件について十分な情報があるか？」
- 「スケール、予算、タイムラインについてどんな仮定を置いているか？」
- 「このユースケースに対して関連する AWS サービスはすべて考慮されているか？」
といった問いを投げ、これらを検討させたうえで提案を行わせる方法がある。

特に設計のような様々な観点で過不足なく、かつ矛盾のない定義を行うことが必要な場面では有効である。
プロンプトにこうした問いかけの例を含めることで、より慎重な提案が得られる。
AIにプロンプトを作らせる
プロンプト自体も AI に作成させる、というテクニックがある。

たとえば、コードレビューをしたい場合、「このプロジェクトを徹底的にレビューするプロンプトを作って」と頼み、それを Markdown 形式で出力させることができる。
時には、自身では思いつかなかったチェック観点が含まれていることもある。

ただしここで重要なのは、人間がレビューすべきということである。
AI が生成した条件すべてを盛り込むと過剰設計（オーバーエンジニアリング）につながることがある。“できるだけ良いもの” を求めて条件を増やすと、その分コードが複雑で重くなってしまうからである。
プロジェクトの本質を説明する情報を AI に与える
AI に既存のプロジェクトに関する生成を指示する時は、「プロジェクトの本質を説明する情報」を AI に与えるべきである。
なぜなら、この情報を与えなかった場合、どんなツールを使っても AI はプロジェクト全体を正しく探索しないからである。
このプロンプトの本質を説明する情報とは、Kiro の steeringファイルであり、Amazon Q Developer の READ MEファイル、そのほか、使用技術やコーディング規約、ベストプラクティスといったものである。

裏側でインデックスが作られていたとしても、
多くの場合それは RAG ベースである。つまり、プロンプトに基づいて検索して、コードの塊を引っ張ってくるだけである。
一方で、steeringファイルがあることで Kiro はプロジェクトの構造が分かるので、必要なファイルを探すことができる。
さらにプロジェクト情報によって、
「このプロジェクトは何を目指しているのか」
「全体のゴールは何か」を
を理解することができる。
よって、話が逸れることなく一貫性のある生成が期待できる。

4. さいごに

今回は、私が参加した AWS re:Invent 2025 のセッション『Mastering agentic prompt engineering』で学んだことを紹介しました。

我々が求める情報や生成してほしいものを AI から得るためには、プロンプトエンジニアリングの正しい手法と概念を理解しておくことが不可欠です。
プロンプトエンジニアリングの基礎となる手法と主要構成要素を正しく理解し、AI に与えることで、意図した一貫性のある生成が期待できます。

加えて、AI にプロジェクトの本質を説明する情報を与えることで、AI は局所的な生成ではなくプロジェクトを理解したうえで生成を行えるようになることが期待できます。
今後はプロンプトエンジニアリングの手法の継続的な高度化、工夫に加えて、いかに適切な「プロジェクトの本質を説明する情報」を作成することができるか、という点が意図する生成の精度に関わる重要なポイントと感じました。