F2. プロンプトエンジニアリング

トラック: Path 0: AI 基礎 · モジュール: F2 最終更新: 2026-07-31 難易度: 入門 → 中級 所要時間: 3 時間 前提モジュール: F1 AI 技術の変遷

flowchart LR
F1["F1 AI 技術の変遷"]
F1 --> F2
F2[" F2 プロンプトエンジニアリング<br/>(現在地)"]:::current
F2 --> F3
F3["F3 知識ベースと RAG"]
F3 --> F4
F4["F4 自動化と Agent"]
classDef current fill:#ff9900,stroke:#333,color:#fff,font-weight:bold

章ナビゲーション

1. なぜプロンプトが重要か · 2. CRISP フレームワーク · 3. 6 つの上級テクニック · 4. 本書の記法の約束 · 5. Prompt から Skill へ · 6. シーン別テンプレート集 · 7. よくある失敗と直し方 · 8. 上級: Context Engineering · 9. 学習リソース

このモジュールで身につくこと

プロンプトはあなたと AI をつなぐ唯一のインターフェースです。同じ AI モデルでも、プロンプトの良し悪しで出力品質は大きく変わります。

このモジュールを終えると:

• CRISP フレームワークで構造化された高品質プロンプトが書ける
• 6 つの上級テクニック(Chain-of-Thought、Few-shot など)を使える
• 越境EC シーンですぐ使える 20+ のプロンプトテンプレートを持てる
• プロンプトのよくある失敗と直し方がわかる
• Prompt Engineering から Context Engineering への進化を理解できる

核心の考え方: プロンプトエンジニアリングは「上手な指示文を 1 つ書く」ことではなく、「完全なコミュニケーションプロトコルを設計する」ことです。AI に渡すのは質問だけでなく、役割・背景・制約・形式・期待値の完全な定義です。

1. なぜプロンプトが重要か

1.1 同じ質問、異なるプロンプトの効果比較

シーン: 競合レビューの分析

悪いプロンプト:

このレビューを分析して

AI の出力: 漠然とした要約。構造もなく、実行可能な提案もない。

良いプロンプト:

あなたはコンシューマーエレクトロニクスに特化した、経験豊富な Amazon プロダクトマネージャーです。
競合の Bluetooth イヤホンの星 1〜3 レビュー(計 50 件)を渡します。

これらを分析し、以下を出力してください:
1. 上位 5 つのユーザー不満点(言及頻度順)
2. 各不満点の代表的なレビュー原文(1〜2 件)
3. 各不満点への改善提案
4. どの不満点が製品設計で最も解決しやすいか

出力形式: 表
言語: 日本語

[ここにレビューを貼り付け]

AI の出力: 構造化された表。頻度順の不満点、それぞれに原文の引用と実行可能な改善提案。

差はどこにある?

1.2 プロンプトの本質: AI の「推測空間」を狭める

F1 の内容を思い出してください: LLM は「次の単語予測器」です。プロンプトが曖昧だと、AI には可能な方向が多すぎて、「最もありがちな」方向 — つまり当たり障りのない話 — を選びます。

プロンプトが正確なら、AI の「推測空間」をあなたの望む方向に絞り込めます。

曖昧なプロンプト → 出力の可能性空間が広い → 高確率で平凡な結果
正確なプロンプト → 出力の可能性空間が狭い → 高確率で望んだ結果

新入社員への仕事の頼み方と同じです:

• 「レポート作っといて」 → 何のレポートか、誰向けか、形式は、いつまでか、わからない
• 「Q1 の販売分析レポートを、上司向けに、PPT 形式で、前年比と Top 10 商品を入れて、金曜までに」 → 何をすべきかわかる

1.3 プロンプトエンジニアリングの費用対効果

2. CRISP フレームワーク: 構造化プロンプトの方法論

2.1 CRISP とは

CRISP は高品質プロンプトを書くためのフレームワークで、5 文字が 5 つの要素を表します:

C Context(背景): AI に十分な背景情報を与える
R Role(役割): AI が演じるべき役割を定義する
I Instructions(指示): 何をすべきか明確に伝える
S Specifications(仕様): 出力の形式・長さ・言語などを定義する
P Proof(検証): 根拠や推論過程の提示を求める

2.2 各要素の詳細

C — Context(背景)

「どんな状況でこの質問をしているのか」を AI に伝えます。背景が豊かなほど、回答は正確になります。

背景情報チェックリスト(越境EC):

• 商品は何か? カテゴリ、特徴、訴求点
• ターゲット市場は? US/EU/JP
• ターゲット顧客は? 年齢、シーン、ニーズ
• 競合は誰か? 価格帯、優劣
• あなたの制約は? 予算、時間、リソース

R — Role(役割)

AI に専門的な役割を与えると、その役割の知識と視点で答えます。

なぜ役割が効くのか? AI の学習データにはさまざまな役割のテキストが含まれています。「Amazon PPC 専門家」と指定すると、AI は PPC 関連の専門用語と分析フレームを使う傾向が強まります。

I — Instructions(指示)

何をすべきか明確に伝えます。良い指示は具体的で、実行可能で、優先順位があります。

S — Specifications(仕様)

出力が「どんな見た目か」を定義します。

P — Proof(検証)

推論過程の説明や根拠の提示を求めることで、幻覚を減らします。

検証要求の例:
- 「推論の過程を説明してください」
- 「各提案の根拠を明記してください」
- 「不確かな情報は明確にその旨を示してください」
- 「『データに基づく結論』と『経験に基づく推測』を区別してください」

2.3 CRISP の完全な例

シーン: 新カテゴリへの参入判断

【C - Context 背景】
私は Amazon US のセラーで、主にコンシューマーエレクトロニクスを扱っています。
年商約 $500K、チームは 5 人。
ポータブルプロジェクターのカテゴリへの参入を検討中です。
現在 Amazon US のこのカテゴリの上位セラーは XGIMI、Anker Nebula、YABER。
立ち上げ予算は約 300 万円です。

【R - Role 役割】
あなたは経験 10 年の越境EC 商品選定コンサルタントで、
Amazon US のコンシューマーエレクトロニクスに精通しています。

【I - Instructions 指示】
ポータブルプロジェクターのカテゴリについて、包括的な市場性評価をお願いします:
1. 市場規模と成長トレンド
2. 競争環境の分析(上位セラーの強みと弱み)
3. 利益余地の試算
4. 参入障壁(資金、技術、認証)
5. 主なリスク
6. Go/No-Go の提言

【S - Specifications 仕様】
- 出力形式: 各次元を表 + 簡潔な分析で
- 言語: 日本語
- スコア: 各次元 1〜5 点
- 最後に総合スコアと明確な提言(参入/慎重/見送り)を提示

【P - Proof 検証】
- どの情報が公開データに基づき、どれが推測かを明記してください
- 不確かな次元があれば明示してください
- 総合スコアの算出ロジックを説明してください

実際に使うときは【C】【R】【I】【S】【P】のラベルは不要です。 ここでは教育用に付けているだけ。慣れれば 5 要素を自然にプロンプトへ織り込めるようになります。

3. 6 つの上級プロンプトテクニック

3.1 Chain-of-Thought(思考の連鎖)

答えを直接出させるのではなく、AI に「一歩ずつ考え」させます。推論が必要な複雑な問題に向きます。

CoT なし:

この商品の Amazon US での利益率は?
仕入コスト ¥80、売価 $29.99、FBA 手数料 $5.50、販売手数料 15%

AI は数字を直接返すかもしれませんが、計算過程が不透明でミスが起きやすい。

CoT あり:

この商品の Amazon US での利益率を、一歩ずつ計算してください:
1. まず仕入コストを人民元から米ドルへ換算(レート 7.2)
2. Amazon の販売手数料を計算
3. すべてのコストを合算
4. 利益と利益率を計算

データ: 仕入コスト ¥80、売価 $29.99、FBA 手数料 $5.50、手数料率 15%

なぜ効くのか? 中間ステップの提示を強制することで、各ステップが検証可能になります。どこかで計算を誤れば、すぐに気づけます。

向いているシーン:

• 利益計算、コスト分析
• 多段階の市場評価
• 論理的な推論が必要な意思決定
• 「過程を見たい」あらゆる分析

3.2 Few-shot Learning(少数例学習)

いくつかの例を見せて、望む出力形式とスタイルを AI に学ばせます。

以下の形式で各競合のタイトル戦略を分析してください:

例:
タイトル: Anker Soundcore Life Q20 Hybrid Active Noise Cancelling Headphones
分析:
- ブランドを先頭に(Anker Soundcore)→ ブランド認知度が高いので最前面に
- コア訴求点(Hybrid Active Noise Cancelling)→ 技術的差別化
- カテゴリ語(Headphones)→ 検索マッチの確保
- 戦略: ブランド + 技術訴求 + カテゴリ語

では同じ形式で以下の 3 タイトルを分析してください:
1. [競合 A のタイトル]
2. [競合 B のタイトル]
3. [競合 C のタイトル]

なぜ効くのか? 例は説明より正確です。望む形式を 100 字で説明するより、例を 1 つ見せる方が早い。

ベストプラクティス:

• 例は通常 1〜3 個で十分
• 異なるケース(ポジ/ネガ、単純/複雑)をカバーする
• 例の形式がそのまま期待する出力形式になる

3.3 Role-Playing(役割演技)

AI に特定の役割を演じさせ、その視点から問題を分析させます。

以下の 3 つの視点からこの商品を評価してください:

役割 1 — 厳しい消費者:
「私は Amazon でよく買い物をする消費者で、品質への要求が高く、
低評価レビューを丁寧に読みます。この商品ページは私に購入を決断させられますか?」

役割 2 — 競合の運営マネージャー:
「私は競合企業の運営マネージャーで、この新商品の市場参入を見ています。
私の商品への脅威になりますか? どう対応すべきですか?」

役割 3 — Amazon カテゴリマネージャー:
「私は Amazon のカテゴリマネージャーで、このカテゴリの商品を審査しています。
このページに規約違反のリスクはありますか? 品質スコアはどうですか?」

なぜ効くのか? 複数役割の分析は、単一視点では見落としがちな問題を発見させてくれます。

3.4 Structured Output(構造化出力)

特定の形式での出力を明示的に要求すると、後続の処理や比較が容易になります。

以下の JSON 形式で分析結果を出力してください:

{
"product_name": "商品名",
"market_score": 1-5,
"competition_score": 1-5,
"profit_score": 1-5,
"risk_factors": ["リスク1", "リスク2"],
"recommendation": "参入/慎重/見送り",
"reasoning": "推薦理由"
}

向いているシーン:

• 多数の商品評価を一括処理したいとき
• Excel やデータベースに取り込むデータ
• チーム内で分析形式を標準化したいとき

3.5 Iterative Refinement(反復改善)

一度のプロンプトで完璧な結果を期待しないこと。AI を協働パートナーとして、複数ラウンドの対話で段階的に磨きます。

第 1 ラウンド:
「Bluetooth イヤホンの Amazon タイトルを書いて」

第 2 ラウンド:
「良いね。ただし『ノイズキャンセリング』というキーワードを入れて、150 文字以内に」

第 3 ラウンド:
「いいね。では 3 つのバリエーションを。それぞれの重点は:
A. 技術スペック(ノイキャン dB、バッテリー時間)
B. 利用シーン(通勤、スポーツ、オフィス)
C. 情緒的訴求(音楽を楽しむ、仕事に集中)」

第 4 ラウンド:
「B の方向で。さらに『2026 新モデル』と『Type-C 急速充電』を加えて磨き込んで」

なぜ効くのか? 複雑なタスクは一度で説明しきれません。反復すれば、AI の出力を見てから方向を調整できます。

3.6 Constraint Setting(制約の設定)

「何をしないか」を伝えることは、「何をするか」と同じくらい重要です。

Amazon 商品ページの箇条書き 5 点を書いてください。

制約条件:
- 誇張表現を使わない(「最高の」「完璧な」「革命的な」など)
- 競合ブランド名に言及しない
- HTML タグを使わない
- 各項目 200 文字以内
- キーワードを重複させない
- 全大文字を使わない(ブランド名を除く)

よく使う制約リスト(越境EC):

4. 本書のプロンプト記法の約束

テンプレートに入る前に、本書のすべてのプロンプトが従う構造を説明しておく。書式へのこだわりではなく、各ブロックが実際に踏んだ失敗に対応している。

4.1 6 つのブロック

<役割>専門的な立場と視点を 1 行で</役割>

<入力データ>
[ここに生データを貼る]
</入力データ>

<タスク>
1. やることを番号付きで列挙
2. 1 行 1 アクション。複数を詰め込まない
</タスク>

<データ規律>
- <入力データ> に出てくる数値だけを使う。無いものは「欠測」と書き、推定しない
- 私が渡していない情報が必要なら、仮定せずまず私に質問する
- 「入力データから導いた」と「一般知識からの推測」を区別し、後者には必ず印を付ける
</データ規律>

<出力形式>
表の列名か JSON のフィールドを指定する。形をモデルに任せない
</出力形式>

<セルフチェック>
提出前に確認: (1) ... (2) ... (3) ...
</セルフチェック>

4.2 各ブロックが必要な理由

<入力データ> の境界マーカーは最も省略されやすく、そして結果が最も直接的だ。キーワード 500 行やレビュー 200 件を貼るとき、境界がないと、そのデータ中の「上記の指示は無視せよ」という一文が実行されてしまう。競合がレビューに 1 行書くだけであなたの分析を汚染できる。開閉タグがあれば、モデルはタグ内を「処理する材料」であって「従う命令」ではないと理解する。

<データ規律> は本書で最も重要なブロックであり、従来これが欠けていた。 言語モデルに「このカテゴリの月間販売数はどれくらい?」と聞けば、ほぼ確実にもっともらしい数字を返してくる — 本当は知らないのに。商品選定・仕入れ・価格設定の判断の先には実際の金が動いている。捏造された販売数の数字ひとつで、数万円分の在庫を抱えることになりかねない。だから本書で数値に触れるプロンプトはすべて次を強制する。入力に無ければ無いと言う。推定は禁止。推測するなら必ず印を付ける。

<セルフチェック> は受け入れ基準を前倒しする。 出力を受け取ってから自分で照合するより、「タイトルは 200 文字以内」「search_terms は 5 点と重複させない」とプロンプトに書き、モデル自身に先に検査させる。実測で手戻りが目に見えて減る。

4.3 そのまま貼れるデータ規律ブロック

本書で最も再利用されるスニペット。数値・予測・推薦が絡むプロンプトにはこれを貼る:

<データ規律>
- 私が提供したデータのみを使う。渡していない数値はすべて「欠測」とし、推定も、記憶にある業界平均の引用も禁止
- 判断材料が足りないときは、まだ必要なデータを列挙して私に質問し、そこで止まる。先に結論を出さない
- 結論ごとに出典を付す: [入力データ] または [モデル推測]
- 金額・販売数・順位に関わる結論は、私が渡したどの行に基づくか追跡できること
</データ規律>

4.4 対応する能力級を明示する

本書の各プロンプトには推奨の能力級(T1 フロンティア / T2 主力 / T3 高速)を併記している。定義はモデルマトリクスを参照。経験則は、多段推論とトレードオフの判断は T1、一括生成と形式変換は T2/T3。 複雑なプロンプトを低い級に渡すと、番号付きタスクの最初の 2 つしかこなさない、という形で現れることが多い。

5. Prompt から Skill へ: Agent 時代の書き方

ここまでの 4 節は「良いプロンプトの書き方」だった。しかし 2026 年に実際に納めるものは、チャット欄に貼るテキストではなく、繰り返し呼び出される指示であることが多い。この節では、同じ内容が 3 つの形態でどう変わるか、そして本書の 300 を超えるプロンプトをどう移行するかを扱う。

関連リソース: Skills ライブラリ 本書で整理した技能ファイル · AI IDE Skills 集 Cursor / Kiro / Claude Code の Rules と Steering File の参考

5.1 3 つの納品形態

核心の認識: 内容はほぼ変わらず、置き場所と境界が変わる。 §4 で学んだ 6 ブロック — 役割・入力データ・タスク・データ規律・出力形式・セルフチェック — は 3 形態すべてに存在する。違うのは:

• 会話型: 6 ブロックすべてを 1 つのテキストに書き、データは手で貼る
• システムプロンプト: 役割/タスク/データ規律/出力形式を system に固定し、入力データは呼び出しごとにコードが渡す
• スキルファイル: さらに「いつ自分を使うべきか」の記述と、「どのツールが必要か」の宣言が加わる

5.2 同じタスクの 3 通りの書き方

A2 の Listing 生成を例に取る。

会話型(本書の大半のプロンプトの現状):

<役割>Amazon Listing 専門家</役割>
<キーワードデータ>[Helium 10 の書き出しをここに貼る]</キーワードデータ>
<タスク>タイトル・箇条書き・説明・Search Terms を生成</タスク>
<データ規律>上のキーワードのみを使い、記憶で補わない</データ規律>

システムプロンプト(500 SKU を一括処理する場合):

SYSTEM = """<役割>Amazon Listing 専門家</役割>
<タスク>…</タスク>
<データ規律>…</データ規律>
<出力形式>JSON: {title, bullets[5], description, search_terms[5]}</出力形式>"""

# キーワードデータは手貼りではなく、呼び出しごとに渡す
for sku in skus:
    call(system=SYSTEM, user=f"<キーワードデータ>{sku.keywords}</キーワードデータ>")

ここで 2 つ変わっている。出力を JSON にしなければならない(でないと後工程が使えない)。そしてキーワードデータが手貼りからプログラム読み取りに変わる。これが「人力のデータ運搬をなくす」の具体的な意味だ。

スキルファイル(Agent が生成の要否を自分で判断する):

---
name: listing-generator
description: 新規 SKU の Amazon Listing を生成・書き換える必要があるときに使う。
  動作にはキーワードデータ(月間検索量付き)と商品情報が必要。
---

<役割>Amazon Listing 専門家</役割>

<事前チェック>
実行前に確認する: (1) キーワードデータ(10 語以上、検索量付き)
(2) 商品情報(訴求点を含む)。
どちらか欠けていれば生成せず、ユーザーに要求すること。
</事前チェック>

<タスク>…</タスク>
<データ規律>…</データ規律>
<出力形式>…</出力形式>
<人的確認が必須>生成結果は直接出品しない。出力後、人のレビューを待つ</人的確認が必須>

増えたのは 3 点。description が「Agent がいつ思い出すか」を決める、事前チェックが不完全なデータでの実行を防ぐ、人的確認が不可逆な動作を止める。

5.3 Agent 化するとデータ規律はより重要になる。軽くなるのではない

直感が逆に働きやすいので、独立した節にする。

会話では、モデルが販売数を捏造しても、あなたがそれを読み、疑い、捨てる — 損失は自分の時間だけだ。

Agent モードでは、その同じ捏造値がそのまま実行される。入札が調整され、CS メールが送られ、補充発注が出る。気づくのは請求書か在庫を見たときかもしれない。爆発半径が「1 回の誤読」から「一連の誤った動作」に変わる。

したがって本書のプロンプトをスキルファイルに移すときは、<データ規律> ブロックをそのまま持ち込み、さらに 1 条追加すること:

<失敗時の挙動>
データ不足または検証不通過のときは停止して報告する。推定値で後続の動作を続行しない。
</失敗時の挙動>

会話ではモデルが「推測して話し続ける」のは読み損の代償で済むが、Agent モードではその推測値を抱えたまま実行まで走り切る。

5.4 Agent に任せてよいタスク、いけないタスク

判断基準はタスクの複雑さではなく、間違えたときに取り返せるかどうかだ。

現実的な着手順序: まず読み取り専用の作業(データ取得・分析・下書き)をやらせ、1〜2 週間回して判断の質に実感を得てから、書き込み権限を 1 項目ずつ開放する。逆順で進めた人はたいてい最初の週に人手での後始末が要る事故に当たる。

5.5 本書のプロンプトを移行するチェックリスト

本書のプロンプトを Agent 用スキルに変換するときは、以下を 1 つずつ確認する:

• <データ規律> をそのまま保持し、「失敗時は停止」の条項を追加する
• <出力形式> を機械可読な構造(JSON/表)に変える。散文を残さない
• description を追加する:いつ使うかと事前に何のデータが要るかを明記
• 事前チェックを追加する: データ不足なら生成せず要求する
• 不可逆な動作を洗い出し、すべて人的確認に紐づける
• データソースを明示する: このプロンプトが元々「貼れ」と言っていたデータを、Agent はどこから読むのか。データソースがなければ、まだ Agent 化しない

最後の 1 項目が最も飛ばされやすく、しかも Agent 化が本当に手間を減らすのか、単に手作業の場所を移しただけなのかを決める。詳しくは A14 運用の Agent 化 を参照。

6. 越境EC シーン別プロンプトテンプレート集(20+)

関連: A2 商品ページ最適化 Listing プロンプトの詳細は A2 へ

6.1 商品リサーチと市場分析(5 本)

テンプレート 1: 競合レビューの不満点抽出

役割: ベテラン Amazon プロダクトマネージャー
入力: [星 1〜3 レビューを 50 件以上貼り付け]
タスク: 上位 5 つの不満点を頻度順に抽出
出力: 表(不満点 | 頻度 | 代表的レビュー | 改善提案 | 難易度)

テンプレート 2: 市場性の 5 軸評価

役割: 越境EC 商品選定コンサルタント
入力: 商品名、ターゲット市場、競合情報
タスク: 市場需要/競争/利益/サプライチェーン/コンプライアンスの 5 軸で採点(1〜5)
出力: スコア表 + 総合提言(参入/慎重/見送り)

テンプレート 3: キーワード需要クラスタリング

役割: Amazon SEO 専門家
入力: [キーワード 100+ 件のリストを貼り付け]
タスク: 購買意図でクラスタリングし、ブルーオーシャン需要を特定
出力: クラスタ表(クラスタ名 | キーワード | 検索量 | 競争度 | 商品機会)

テンプレート 4: トレンド予測

役割: EC トレンドアナリスト
入力: カテゴリ名 + Google Trends データ + BSR データ
タスク: カテゴリが上昇期/停滞期/衰退期のどれか判断
出力: トレンド判断 + 根拠 + 参入タイミングの提案

テンプレート 5: サプライヤー比較評価

役割: 調達マネージャー
入力: 3 社の見積、MOQ、納期、資格
タスク: 多軸での比較評価
出力: 比較表 + 推奨順位 + 交渉戦略

6.2 商品ページとコンテンツ(5 本)

テンプレート 6: 商品ページ一括生成

役割: Amazon Listing 最適化専門家
入力: 商品情報、訴求点、キーワードリスト
タスク: タイトル + 箇条書き 5 点 + 説明 + Search Terms を生成
制約: タイトル 200 文字以内、キーワードは自然に織り込む

テンプレート 7: 多言語ローカライズ

役割: [ターゲット言語] ローカライズ専門家
入力: 英語の商品ページ
タスク: 翻訳 + ローカライズ適応(キーワード置換、訴求点の順序調整)
出力: ローカライズ済みページ + すべての調整の説明

テンプレート 8: A+ コンテンツ企画

役割: Amazon A+ Content デザイナー
入力: 商品情報、ブランドストーリー、競合の A+ スクショ
タスク: A+ コンテンツのモジュール構成とコピーを企画
出力: モジュール順序 + 各モジュールの見出し/コピー/画像の提案

テンプレート 9: 競合ページの分解

役割: 競合アナリスト
入力: 競合 3 社の完全な商品ページ
タスク: 戦略の違いを比較し、差別化の機会を発見
出力: 戦略比較表 + キーワードカバレッジ比較 + 差別化提案

テンプレート 10: 訴求点の抽出

役割: ブランドマーケティング専門家
入力: 商品スペック、高評価レビュー、競合の弱点
タスク: コア訴求点 3 つ + 一言 USP を抽出
出力: 訴求点の説明 + 裏付け + 適用シーン

6.3 広告とマーケティング(4 本)

関連: A3 広告最適化 広告分析プロンプトの詳細は A3 へ

テンプレート 11: 検索語レポート分析

役割: Amazon PPC 専門家
入力: 検索語レポートのデータ(過去 30 日)
タスク: 高転換語、ムダ語、除外候補を特定
出力: 高転換語 TOP 10 + ムダ語 TOP 10 + 除外リスト + 予算提案

テンプレート 12: 広告コピー A/B バリエーション

役割: 広告コピーライター
入力: 商品説明、コア訴求点
タスク: 5 スタイルの Headline を生成(機能/シーン/感情/データ/課題解決)
出力: Headline 5 本 + 期待効果 + 想定オーディエンス

テンプレート 13: プロモーション戦略の立案

役割: EC プロモーション戦略家
入力: 商品情報、過去の販売データ、プロモ予算
タスク: BFCM/Prime Day のプロモ計画を策定
出力: プロモカレンダー + 割引戦略 + 広告連携案 + 期待 ROI

テンプレート 14: ブランドストーリー執筆

役割: ブランドストーリーライター
入力: ブランド背景、創業ストーリー、コアバリュー
タスク: Amazon Brand Story のコンテンツを執筆
出力: ブランドストーリー(200〜300 字)+ 画像の提案

6.4 カスタマーサービスとアフターケア(3 本)

テンプレート 15: 低評価レビュー一括分析

役割: 商品品質アナリスト
入力: 直近 60 日の星 1〜3 レビュー
タスク: 種類別分類、頻度集計、改善策の策定
出力: 分類表 + 頻度割合 + 短期対応 + 長期改善 + 優先度

テンプレート 16: CS 返信テンプレート生成

役割: Amazon カスタマーサービス専門家
入力: よくある顧客の質問タイプ
タスク: 多言語の返信テンプレートを生成
出力: 質問タイプごとに 3 バリエーション(フォーマル/フレンドリー/簡潔)× 多言語

テンプレート 17: 申立書 Plan of Action

役割: Amazon アカウント申立の専門家
入力: 違反通知の内容
タスク: Plan of Action を作成
出力: Root Cause + Immediate Actions + Preventive Measures

6.5 運営管理(4 本)

テンプレート 18: 補充判断の分析

役割: 在庫管理の専門家
入力: 過去 90 日の販売データ、現在庫、サプライヤー納期
タスク: 安全在庫と補充提案を計算
出力: 安全在庫量 + 補充タイミング + 補充数量 + リスク注意

テンプレート 19: 競合モニタリング週報

役割: 競合情報アナリスト
入力: 競合の価格/レビュー/BSR の変化データ
タスク: 競合の戦略変化の分析と対応提案
出力: 変化サマリー + 戦略分析 + 対応提案

テンプレート 20: 運営日報/週報の生成

役割: 運営データアナリスト
入力: 当日/当週の販売、広告、在庫データ
タスク: 構造化された運営レポートを生成
出力: 主要指標サマリー + 異常のフラグ + アクション提案

テンプレート 21: 複数市場コンプライアンス比較

役割: 越境EC コンプライアンスコンサルタント
入力: 商品タイプ、ターゲット市場リスト
タスク: 各市場のコンプライアンス要件を比較
出力: 比較表 + 認証費用の試算 + よくある落とし穴

7. よくある失敗と直し方

7.1 プロンプトの十大失敗

7.2 実践リペア: 悪いプロンプトを良く作り替える

元のプロンプト(悪い):

この商品どう思う?

問題の診断:

• 役割がない
• 背景がない(どの商品? どの市場?)
• 「どう思う」が曖昧(どの軸で評価?)
• 出力形式の要求がない
• 検証要求がない

1 回目の改善:

あなたは越境EC の商品選定コンサルタントです。
「ポータブルネックファン」の Amazon US での市場性を評価してください。
市場需要、競争、利益の 3 軸で分析を。

2 回目の改善(CRISP の全要素を投入):

【役割】あなたは経験 10 年の越境EC 商品選定コンサルタントで、
Amazon US のコンシューマーエレクトロニクスに精通しています。

【背景】私は年商 $200K の Amazon セラーで、チームは 3 人、
立ち上げ予算は 150 万円。ポータブルネックファンのカテゴリを検討中。
現在の上位競合は JISULIFE(BSR #1、4.3 星、レビュー 12,000+)
と TORRAS(BSR #3、4.4 星、レビュー 8,000+)。

【タスク】包括的な市場性評価をお願いします:
1. 市場需要(検索トレンド、季節性、成長ポテンシャル)
2. 競争環境(上位セラーの参入障壁、新規参入の難しさ)
3. 利益余地(コスト構造と利益率の試算)
4. リスク評価(季節性、特許、コンプライアンス)
5. 総合提言(Go/No-Go + Go の場合の参入戦略)

【形式】各軸を表 + 1〜5 点のスコア + 簡潔な分析で。
最後に総合スコアと明確な提言を。

【検証】どれが公開情報に基づく分析で、どれが推測かを
明記してください。不確かな軸があれば明示を。

7.3 モデルごとのプロンプトの違い

Claude 専用テクニック — XML タグ:

<context>
私は Amazon US のセラーで、主にコンシューマーエレクトロニクスを扱っています。
</context>

<task>
以下の競合レビューの不満点を分析してください。
</task>

<format>
表で出力: 不満点、頻度、代表的レビュー、改善提案。
</format>

<reviews>
[ここにレビューを貼り付け]
</reviews>

8. 上級: Prompt Engineering から Context Engineering へ

関連: D6 東南アジア AI ガイド 多言語プロンプトの応用は D6 へ

8.1 2026 年のトレンド: Context Engineering

2025 年半ば、Andrej Karpathy(元 OpenAI 研究員)が重要な視点を提示しました: LLM は CPU、コンテキストウィンドウは RAM、そしてあなたはオペレーティングシステムとして正しい情報をロードする役割を担う。

つまりプロンプトエンジニアリングは Context Engineering へ進化しつつあります — 良いプロンプトを 1 本書くだけでなく、情報入力のアーキテクチャ全体を設計することです。

出典：Context Engineering Guide 2026

Prompt Engineering(2023〜2024):
関心事: 良い指示文をどう書くか
コアスキル: CRISP フレームワーク、CoT、Few-shot
適用シーン: 単発の対話、単純なタスク

Context Engineering(2025〜2026):
関心事: 情報入力のアーキテクチャ全体をどう設計するか
コアスキル: 情報の選別、コンテキスト管理、ツールのオーケストレーション
新しい問い:
どの情報をコンテキストに入れるか?(多ければ良いわけではない)
情報の優先度と構成は?
ツールで動的に情報を取得するには?
複数ターンの対話のコンテキストをどう管理する?
適用シーン: 複雑なワークフロー、Agent、長期プロジェクト

8.2 Context Engineering の実践

原則 1: 情報のレイヤリング

Layer 1 — システム指示(常に存在):
役割定義、出力規範、制約条件

Layer 2 — タスクコンテキスト(必要に応じてロード):
現在のタスクの背景情報、関連データ

Layer 3 — 参考資料(動的に検索):
RAG で検索した関連文書の断片

Layer 4 — 対話履歴(自動管理):
これまでの対話内容(要約・圧縮が必要な場合も)

原則 2: コンテキスト予算の管理

モデルのコンテキストウィンドウは有限です。広告予算と同じように、コンテキスト予算を管理しましょう:

原則 3: 出力コントラクト

2026 年のベストプラクティスは、プロンプトを「契約」として設計することです:

出力コントラクト = {
形式: 表/JSON/Markdown
長さ: 最大 X 字
トーン: プロフェッショナル/フレンドリー/簡潔
必須セクション: [リスト]
不確かなときの振る舞い: 「不確か」と明示する
エラー処理: 入力データが不足なら、推測せず補足を求める
}

出典：Prompt Engineering Best Practices 2026

9. 学習リソース

9.1 必読リソース

9.2 実践プラン

この方法が効かないとき

• 欲しいのが「良い出力」ではなく「決定的な出力」のとき。 請求書の金額を抜く、固定ルールで SKU コードを書き換える — こうした処理は正規表現か数行のコードのほうが安定する。Prompt が強いのは曖昧な入力の処理であって、決定的なロジックの代わりではない。同じ Prompt を 2 回走らせても文言は一致しない。一字一句の再現性が要る場面では、それは特性ではなく欠陥である。
• モデルがそもそも知らないとき。 自社の在庫、先週の検索語レポート、3 日前に変わったプラットフォームの規約 — Prompt をどう磨いても出てこない。必要なのは RAG かデータの貼り付けである(F3)。文言を磨き続けても、作り話がそれらしくなるだけだ。
• 同じ処理を数百・数千回まわすとき。 その規模で 1 本の Prompt を手で詰めても割に合わないし、品質も保たない。入力形式を固定したテンプレート + 抽出人手レビューか、技能ファイル(本章 §5)へ移すこと。判断は単純で、出力を全件読むつもりがないなら、文言で品質を担保できるとは考えないほうがいい。
• 失敗のコストを負担できないとき。 対外的な法務文書、通関申告、顧客への補償の約束 — Prompt が十分に良ければ通る、という類の場面ではない。人手レビューの工程が必須である。データ規律ブロックはモデルが数字をでっちあげるのを止めるが、あなたが見落とした箇所で意図を取り違えるのは止められない。

10. 完了チェック

• CRISP フレームワークで構造化プロンプトが書ける
• 上級テクニックを 3 つ以上使ったことがある(CoT、Few-shot、Role-Playing など)
• 常用するプロンプトテンプレートを 10 本以上構築した
• よくあるプロンプトの失敗を見抜き、直せる
• Context Engineering の概念と実践原則を理解した

以上をすべて完了すれば、AI と効率的にコミュニケーションする中核スキルを習得しています。次は F3 知識ベースと RAGへ。AI にあなたの独自データを理解させる方法を学びます。