はじめに
AIへ複雑な仕事を一度に依頼すると、前提が抜けたり、途中から目的がずれたり、もっともらしい誤りが混ざったりします。
たとえば、技術記事を作るときに「資料を調べて、構成を考えて、本文を書いて、事実確認もして」と一度に頼むと、どの工程で間違えたのか分かりにくくなります。
そこで使えるのが、複雑な仕事を複数のAI呼び出しに分ける プロンプトチェイニング（Prompt Chaining） です。
この記事では、プロンプトチェイニングの意味、Chain-of-Thoughtとの違い、実務で使える分割例、Amazon Bedrockでの最小実装、関連する15のプロンプト手法を整理します。
この記事でわかること
- プロンプトチェイニングと、単なる再質問の違い
- Chain-of-Thought、反復改善、タスク分解との使い分け
- チャットで手軽に試せる4回の最短例
- 記事作成を5段階へ分ける実践テンプレート
- 前の出力を次の入力へ安全に渡す方法
- Amazon BedrockのConverse APIで処理をつなぐPython例
- AWS Certified AI Practitionerで確認したいプロンプト技法
先に結論
プロンプトチェイニングは、次のように 前の出力を次の工程へ明示的に渡す方法 です。
重要なのは、チャットを何回も送ること自体ではありません。
- 各工程の目的を1つに絞る
- 前工程の出力を、次工程の入力として渡す
- 工程ごとに出力形式と合格条件を決める
- 誤りを見つけたら、次へ進む前に直す
- 最終判断は人が行う
この形にすると、途中成果物を確認できるため、一度の長い依頼よりも方向修正しやすくなります。ただし、品質が自動的に保証されるわけではありません。前工程の誤りをそのまま渡すと、後工程へ連鎖します。
前提
- 対象読者: 生成AIを文章作成、調査、開発補助へ使っている人
- 確認日: 2026-08-13
- 扱う範囲: テキスト生成を中心としたプロンプト設計と簡単なAPI実装
- 扱わない範囲: 特定モデルの性能比較、料金比較、AIエージェントの自律実行設計
- 注意: 生成結果はモデル、設定、入力、実行時期によって変わります。公開情報や業務成果物は、人による確認が必要です
用語の短い説明
| 用語 | 短い説明 |
|---|---|
| LLM | Large Language Modelの略。大量のテキストを学習し、文章の生成や要約などを行うモデル |
| プロンプト | LLMへ渡す指示、背景、入力データ、出力条件の総称 |
| プロンプトエンジニアリング | 目的に合う回答を得やすくするため、プロンプトを設計・改善する取り組み |
| プロンプトチェイニング | 複雑な仕事を複数のLLM呼び出しに分け、前段の出力を後段の入力へ渡す方法 |
| ハルシネーション | AIが、事実ではない内容をもっともらしく生成する現象 |
| RAG | Retrieval-Augmented Generationの略。関連資料を検索し、その内容を根拠として回答させる構成 |
プロンプトチェイニングとは
AWS Prescriptive Guidanceでは、プロンプトチェイニングを、複雑なタスクを一連のステップへ分解し、各ステップで前の出力を処理または発展させるワークフローとして説明しています。
この流れは、チャットで人が1工程ずつ進めても、APIから複数回のLLM呼び出しを自動でつないでも作れます。最初はチャットで中間出力を確認し、工程が安定してからAPIで自動化すると、失敗原因を切り分けやすくなります。
向いているのは、次のような仕事です。
- 調査、要約、比較、提案を順番に行う
- 要件整理、設計、コード生成、テスト、説明を分ける
- 長い文書から事実を抽出し、構成を作り、文章へ変換する
- 中間結果へ人の承認や外部の検証処理を入れる
- 各工程の出力を記録し、あとから確認できるようにする
一方、単純な翻訳や短い要約まで細かく分けると、呼び出し回数、待ち時間、料金が増えるだけの場合があります。
似ている用語との違い
| 用語 | 何を分けるか | 典型例 |
|---|---|---|
| プロンプトチェイニング | LLMの呼び出しを複数工程へ分ける | 要件整理 → 構成 → 本文 → レビュー |
| Chain-of-Thought | 1回の処理で、複数の論点や段階を考慮させる | 前提、比較基準、結論の順に検討させる |
| 反復型プロンプティング | 同じ成果物へ修正指示を重ねる | 文章を短くする → 表現を柔らかくする |
| タスク分解 | 大きな仕事を小さく分ける考え方全般 | 調査、設計、実装、検証へ分ける |
| AIワークフロー | LLM以外のAPI、分岐、承認、保存も含む処理全体 | 検索 → LLM → 人の承認 → DB保存 |
| AIエージェント | 状況に応じて、AIが次の行動やツールを選ぶ仕組み | 必要な資料を検索し、APIを呼び、回答する |
実務では「内部の思考過程をすべて見せて」と依頼するより、成果物として必要な 前提、判断基準、確認事項、根拠 を出力させるほうが検証しやすくなります。
一度の長い依頼と何が違うのか
一度に依頼する例
添付資料を調べ、初心者向けの記事構成を考え、
本文を書き、AWSの公式情報で事実確認し、読みやすく修正してください。
短く依頼できますが、次の問題が起きやすくなります。
- 調査結果が見えず、根拠を確認しにくい
- 構成がずれていても、長い本文が先に作られる
- 事実確認と文章修正が混ざる
- どの指示が反映されなかったのか分かりにくい
工程を分ける例
| 工程 | AIへ任せること | 人が確認すること |
|---|---|---|
| 1. 情報整理 | 事実、推測、未確認事項を分ける | 根拠が一次情報か |
| 2. 構成作成 | 読者の疑問順に見出しを作る | 記事の目的とずれていないか |
| 3. 本文作成 | 承認した構成の範囲だけを書く | 説明と具体例が対応しているか |
| 4. レビュー | 不自然な表現、重複、抜けを指摘する | 指摘が妥当か |
| 5. 最終確認 | 修正版と確認表を出す | 仕様、コード、リンクを実際に確認する |
まずはチャット4回で試す
自動化する前に、同じチャットで以下の4回に分けて試すと、プロンプトチェイニングの効果をつかみやすくなります。
1回目: 情報を整理する
次の資料から、確認できる事実、意見、未確認事項を分けてください。
まだ記事本文は書かないでください。
<SOURCE>
ここに資料を貼る
</SOURCE>
2回目: 構成だけ作る
今の整理結果を使い、初心者向けの記事構成を作ってください。
見出しは8個以内にし、各見出しの要点を2つまで書いてください。
まだ本文は書かないでください。
3回目: 確認した構成から書く
今の構成に沿って本文を書いてください。
専門用語は初出時に短く説明し、抽象的な説明の後に具体例を入れてください。
元資料にない事実は追加せず、不明点は「要確認」と残してください。
4回目: 書き換える前にレビューする
今の本文をレビューしてください。
確認項目:
- 事実と意見が混ざっていないか
- 初心者にとって説明が飛んでいないか
- 同じ内容を繰り返していないか
- 公開前に確認すべき仕様やリンクが残っていないか
まず問題点と修正案だけを表で出し、本文は書き換えないでください。
ポイントは、4回目でいきなり本文を書き換えさせないことです。レビュー結果を人が確認し、採用する指摘だけを次の依頼で反映します。
チャットの履歴が長くなると、古い前提や不要な出力まで影響することがあります。次の工程には、確認済みの事実、制約、構成など、必要な情報だけを渡してください。
記事作成で使える5段階の実践例
題材を「SES現場の報告方法」とした例です。各工程の出力を確認してから、次へ進みます。
1. 事実と論点を整理する
<!-- 最初の工程では、本文を書かせず材料だけを整理する -->
## 役割
あなたは、技術記事の編集者です。
## 目的
SES現場の報告方法について、記事の材料を整理します。
## 入力
ここに取材メモや参考資料を貼ります。
## 制約
- 入力に書かれた事実と、推測を分けてください。
- 情報がない項目は「未確認」としてください。
- まだ記事本文は書かないでください。
## 出力形式
1. 読者の困りごと
2. 確認できた事実
3. 推測または意見
4. 不足している情報
5. 記事に入れる候補
この工程の目的は、文章をきれいにすることではなく、使ってよい材料を見分けることです。
2. 構成だけを作る
<!-- 前工程の確認済み出力だけを渡す -->
## 入力
以下は確認済みの材料です。
<STEP1_OUTPUT>
ここに1回目の出力を貼ります。
</STEP1_OUTPUT>
## 依頼
初心者が「なぜ必要か」「どう報告するか」「何を避けるか」の順に
理解できる記事構成を作ってください。
## 制約
- 見出しは8個以内にしてください。
- 各見出しに、扱う要点を2つまで付けてください。
- まだ本文は書かないでください。
構成段階で方向が違えば、本文を作る前に直せます。
3. 承認した構成から本文を書く
<!-- 構成を固定し、勝手な見出し追加を防ぐ -->
## 入力
以下の構成は確認済みです。
<APPROVED_OUTLINE>
ここに承認した構成を貼ります。
</APPROVED_OUTLINE>
## 依頼
構成に沿って記事本文を書いてください。
## 条件
- IT用語は初出時に短く説明してください。
- 抽象的な説明のあとに、現場で使える例文を入れてください。
- 入力にない事実を追加しないでください。
- 不明点は「要確認」と残してください。
4. 執筆者とは別の視点でレビューする
<!-- 修正前に、問題点と修正理由を可視化する -->
## 役割
あなたは、記事を書いた人とは別のレビュアーです。
## 確認項目
- 事実と意見が混ざっていないか
- 初心者に説明の飛躍がないか
- 同じ内容を繰り返していないか
- 読者を責める表現がないか
- 公開前に確認すべき情報が残っていないか
## 出力形式
| 重要度 | 対象箇所 | 問題 | 修正案 |
| --- | --- | --- | --- |
本文はまだ書き換えず、指摘だけを出してください。
5. 採用する指摘だけを反映する
<!-- 人が採用すると決めた指摘だけを反映する -->
## 入力
- 元の本文: <ARTICLE>...</ARTICLE>
- 採用する指摘: <APPROVED_REVIEW>...</APPROVED_REVIEW>
## 依頼
採用する指摘だけを本文へ反映してください。
## 出力
1. 修正後の本文
2. 変更点の一覧
3. 最終確認が必要な事実とリンク
AIのレビュー結果をすべて採用する必要はありません。修正理由を確認し、人が採用する指摘を選びます。
工程間で渡す情報を固定する
プロンプトチェイニングでは、前の回答を丸ごと貼り続けると、不要な説明まで増えていきます。工程間では、次のような「受け渡し用データ」に絞ると扱いやすくなります。
# 次工程で必要な情報だけを残す
goal: "SES現場の報告方法を初心者向けに説明する"
audience: "SES案件へ初めて参画するエンジニア"
confirmed_facts:
- "事実、推測、未確認事項を分けて報告する"
- "次の報告時刻を伝える"
open_questions:
- "現場固有のエスカレーション先"
constraints:
- "顧客名や案件名を出さない"
- "未確認事項を断定しない"
approved_outline:
- "報告を早くする理由"
- "報告テンプレート"
- "NG例と改善例"
出力形式を固定すると、次工程がどの情報を使うか分かりやすくなり、プログラムからも扱いやすくなります。
15のプロンプト手法を使い分ける
プロンプトに関する呼び方は、資料や提供会社によって分類が異なることがあります。次の表は、実務での使い分けを目的に整理したものです。
| 手法 | 使い方 | 向いている場面 |
|---|---|---|
| 1. Zero-shot | 例を示さず依頼する | 単純な要約、翻訳、分類 |
| 2. One-shot／Single-shot | 完成例を1つ示す | 出力形式をそろえる |
| 3. Few-shot | 入力と望ましい出力の例を複数示す | 文体、分類基準、書式を安定させる |
| 4. Chain-of-Thought | 複数の論点を段階的に扱わせる | 比較、計算、原因整理 |
| 5. Prompt Chaining | 複数回の呼び出しを工程としてつなぐ | 調査、構成、作成、レビュー |
| 6. Iterative Prompting | 同じ成果物へ修正を重ねる | 短文化、トーン調整、表現改善 |
| 7. Role Prompting | AIの役割や視点を指定する | 編集者、レビュアー、設計者の視点 |
| 8. Context Prompting | 背景、対象者、前提を渡す | 社内文書、顧客向け説明 |
| 9. Instruction Prompting | 作業、条件、出力形式を明確にする | ほぼすべての業務依頼 |
| 10. Negative Prompting | 避ける内容と代替方針を示す | 禁止表現、除外条件、安全対策 |
| 11. Prompt Template | 差し替えて使えるひな型にする | 定型メール、レビュー、記事作成 |
| 12. Critique／Self-review | 出力の問題点をAIに点検させる | 下書きレビュー、抜け漏れ確認 |
| 13. Socratic／Interview | AIから不足情報を質問させる | 要件が固まっていない相談 |
| 14. Grounding／RAG型 | 指定資料や検索結果を根拠にさせる | 社内FAQ、仕様確認、根拠付き回答 |
| 15. Meta-prompting | 依頼文そのものをAIに改善させる | プロンプトの作り方が分からないとき |
最初に覚えるなら5つでよい
最初から15種類を暗記する必要はありません。まずは次の5つを使い分けると、日常業務へ取り入れやすくなります。
| 目的 | 使う手法 |
|---|---|
| 依頼を明確にする | Instruction Prompting |
| 背景を渡す | Context Prompting |
| 完成例を見せる | One-shotまたはFew-shot |
| 複雑な仕事を分ける | Prompt Chaining |
| 出力を点検する | Critique／Self-review |
Amazon Bedrockでプロンプトチェイニングを試す
ここからは、Amazon BedrockのConverse APIを使い、情報整理、構成作成、本文作成、レビューを順番に呼び出す概念例です。
Converse APIは、対応モデルへ共通形式の messages を送るためのAPIです。呼び出しには bedrock:InvokeModel 権限が必要です。
前提条件
- AWS認証情報を、環境変数やAWS CLIのプロファイルなどで設定済み
- 利用するリージョンで、対象モデルまたは推論プロファイルを利用可能
- Python 3とBoto3を利用可能
- 実行回数に応じて推論料金と待ち時間が増えることを理解している
# Boto3を仮想環境へインストールする
python3 -m pip install boto3
# 利用可能なモデルIDまたは推論プロファイルIDへ置き換える
export BEDROCK_MODEL_ID='your-model-or-inference-profile-id'
# 必要に応じて利用リージョンを変更する
export AWS_REGION='ap-northeast-1'
Pythonサンプル
import os
from pathlib import Path
import boto3
# モデルIDをコードへ直接書かず、環境ごとに切り替えられるようにする
MODEL_ID = os.environ["BEDROCK_MODEL_ID"]
REGION = os.getenv("AWS_REGION", "ap-northeast-1")
client = boto3.client("bedrock-runtime", region_name=REGION)
def converse(prompt: str) -> str:
"""Converse APIを1回呼び、テキスト部分を連結して返す。"""
response = client.converse(
modelId=MODEL_ID,
messages=[
{
"role": "user",
"content": [{"text": prompt}],
}
],
inferenceConfig={
# 出力を必要以上に長くしない
"maxTokens": 1200,
# 事実整理を重視し、出力の揺れを抑える
"temperature": 0.2,
},
)
# 対応モデルによって複数のcontent blockが返る場合に備える
blocks = response["output"]["message"]["content"]
return "\n".join(block["text"] for block in blocks if "text" in block)
theme = "プロンプトチェイニングを初心者向けに説明する"
# 1回目: 記事本文ではなく、必要な論点だけを整理する
facts = converse(
f"""
テーマ: {theme}
まず、記事に必要な論点、確認すべき事実、未確認事項を分けてください。
まだ構成や本文は作らないでください。
"""
)
# 2回目: 1回目の出力を明示的に次の入力へ渡す
outline = converse(
f"""
以下は前工程で整理した材料です。
<MATERIALS>
{facts}
</MATERIALS>
初心者向けの記事構成を作ってください。
見出しと、各見出しで説明する要点だけを出してください。
"""
)
# 3回目: 承認済みとみなした構成の範囲で本文を作る
draft = converse(
f"""
以下の構成に沿って記事本文を書いてください。
<OUTLINE>
{outline}
</OUTLINE>
専門用語は初出時に説明し、具体例を入れてください。
構成にない事実を推測で追加しないでください。
"""
)
# 4回目: 元の指示と本文を渡し、別工程としてレビューする
review = converse(
f"""
テーマ: {theme}
以下の本文をレビューしてください。
<ARTICLE>
{draft}
</ARTICLE>
事実と意見の混同、説明の飛躍、重複、未確認事項を表で指摘してください。
本文の書き換えは行わないでください。
"""
)
# 中間成果物を残し、どの工程で問題が入ったか確認できるようにする
Path("01_facts.md").write_text(facts, encoding="utf-8")
Path("02_outline.md").write_text(outline, encoding="utf-8")
Path("03_draft.md").write_text(draft, encoding="utf-8")
Path("04_review.md").write_text(review, encoding="utf-8")
print("4つの中間成果物を保存しました。")
# 4回のモデル呼び出しを実行する
python3 prompt_chain.py
# 中間成果物が作成されたことを確認する
ls -1 0*.md
期待するファイルは次の4つです。
01_facts.md
02_outline.md
03_draft.md
04_review.md
このコードは、プロンプトチェイニングの流れを示す最小の概念例です。実務では、APIエラー時の再試行、タイムアウト、ログ、入力サイズ、料金上限、モデルごとの差、機密情報の除外、各工程の出力検証を追加してください。
失敗しやすい5つのパターン
1. 前工程の誤りを確認せず次へ渡す
チェーンの後半が丁寧でも、最初に抽出した事実が間違っていれば、完成品も間違います。
対策は、重要な工程の間に確認を入れることです。
情報整理 → 人が確認 → 構成作成 → 人が確認 → 本文作成
2. 前の会話を覚えている前提で依頼する
APIを別々に呼び出す場合、前の入力や出力は自動的に次の呼び出しへ渡りません。必要な情報を messages に含めるか、前の出力を次のプロンプトへ明示的に入れます。
3. 出力形式を決めない
自由文のまま工程をつなぐと、次の処理で必要な項目を取り出しにくくなります。表、JSON、YAML、固定見出しなど、目的に合う形式を決めます。
4. 分割しすぎる
短い要約を10工程へ分けても、品質向上より料金と待ち時間の増加が大きくなる可能性があります。工程を分けるのは、次のどれかに当てはまるときです。
- 途中で人が判断する
- 工程ごとに異なる評価基準がある
- 外部検索やコード実行を挟む
- 中間成果物を保存したい
- 一度の依頼では長すぎる
5. AIの自己レビューだけで公開する
同じモデルにレビューさせても、同じ思い込みを見落とすことがあります。公式資料、テスト結果、実機、別の検証処理、人のレビューを組み合わせます。
AWS Certified AI Practitionerでの整理
AWS Certified AI Practitioner（AIF-C01）の試験ガイドでは、プロンプトエンジニアリングの例として、次の項目が挙げられています。
- context、instruction、negative prompts
- chain-of-thought
- zero-shot、single-shot、few-shot
- prompt templates
- specificity and concision、guardrails、prompt versioning
一方、プロンプトチェイニングは、AWS Prescriptive Guidanceのエージェント型AIワークフローとして説明されています。
試験対策では用語だけで決めず、問題文が 1回のプロンプト内の技法 を聞いているのか、複数回のLLM呼び出しをつなぐワークフロー を聞いているのかを確認すると整理しやすくなります。
試験範囲や出題内容は更新される可能性があります。受験前は、最新のAWS公式試験ガイドを確認してください。
実務で使う前のチェックリスト
- 1工程につき、主な目的が1つになっている
- 前工程から次工程へ渡す項目を決めている
- 事実、推測、未確認事項を分けている
- 出力形式と合格条件を決めている
- 重要な工程の間に人の確認を入れている
- 失敗時に、どの工程から再開するか決めている
- 顧客情報、個人情報、認証情報を入力していない
- 料金、入力サイズ、待ち時間を確認している
- 公式資料、テスト、実機で最終確認している
- プロンプトと確認結果を再利用できる形で残している
参考・確認先
- Workflow for prompt chaining - AWS Prescriptive Guidance
- Content Domain 3: Applications of Foundation Models - AWS Certified AI Practitioner
- Prompt engineering concepts - Amazon Bedrock
- Converse - Boto3 documentation
- 仕様確認日: 2026-08-13
関連記事
まとめ
- プロンプトチェイニングは、複雑な仕事を複数のLLM呼び出しへ分け、前の出力を次の入力へ渡す方法
- Chain-of-Thoughtは1回の処理内で論点を段階的に扱う考え方で、複数回の呼び出しをつなぐプロンプトチェイニングとは分けて考える
- 情報整理、構成、本文、レビュー、最終確認へ分けると、途中で方向修正しやすい
- 前工程の誤りも連鎖するため、出力形式、合格条件、人の確認が必要
- 小さな仕事は一度で依頼し、確認点が多い仕事だけを分割する
おわりに
生成AIを実務で使うときは、良いプロンプトを1つ作るだけでなく、どこで確認し、どの情報を次へ渡すかまで設計すると扱いやすくなります。
Wealthy Designでは、Webシステム開発、クラウド活用、AIを使った業務改善に取り組んでいます。
会社の取り組みは、会社サイトにまとめています。
https://wealthy-design.com/