コース内容
トピック0:イントロダクション
なぜAIを学ぶ必要があるのか?全社員がAIを使うことを常識化することで、売上や給与の向上がどのくらい見込めるか?を説明します。
0/62
(※準備中)トピック2:効果的な質問の仕方とは?〜AIを活かすプロンプトの作り方〜
AIを活用する上で最も重要なのがプロンプトの作り方です。プロンプト次第でAIは嘘をつく(ハルシネーション)ことも、思い通りの出力をしないことも多々あります。現在AIを上手に仕事に活用している人たちは、ずばりプロンプトの作り方が上手な人たちです。AIを活かすプロンプトの作り方をこのトピックで徹底的に学びましょう。
東光ブロズAI活用レクチャー

L03:プロンプト設計 応用(例示・条件分岐・採点基準)

本レッスンでは、「ブレる出力」をプロンプト設計で抑え、さらに検証まで織り込むための応用技術を扱います。
「例示(Few-shot)」「ロール(役割)」「不足情報のヒアリング(質問)」「条件分岐」「採点基準(ルーブリック)」を組み合わせ、
属人化しやすい依頼を再現性のある運用に変換します。

このページの使い方

1レッスン=1LP(1ページ)です。上から順に当日の時間割に沿って進めてください。
各項目の冒頭に EC事業部文房具カフェ事業部・準備室 の実施時間を併記しています。


このレッスンの狙い(到達状態)

  • 例示あり/なしで出力差を比較し、改善点を言語化できる
  • ロール(役割)設定あり/なしで出力差を比較し、改善点を言語化できる
  • 不足情報の質問(ヒアリング)を組み込んだプロンプトを作成し、確認→実行の流れを設計できる
  • 条件分岐(if/then)を使い、例外やケース別の出力を安定させられる
  • 採点基準(ルーブリック)を作り、出力をレビューしやすい形にできる
  • EC/文房具カフェ/準備室で、部内共有したい「プロンプト術」を最低1つ作り、考え方をシェアできる

受講ルール(共通)

  • 実データ禁止:実際の顧客情報、実注文情報、実契約条件、未公開企画の具体情報などは入力しない(このページのダミーのみ使用)
  • “そのまま貼る”禁止:生成AIの出力を未検証のまま対外文面・決裁資料に貼らない(訓練は「設計→比較→改善→検証」の練習)
  • 迷ったら止める:入力に不安がある場合は匿名化・抽象化・要点化を優先し、それでも不安なら相談観点(情報管理/契約取引/権利IP/対外表現)で質問に回す
  • 相互レビュー2件以上:前日までの他者成果物に2件以上コメントする(レビュー観点は本ページのテンプレを使用)

今日の成果物(提出物:最小セット)

  1. 比較ログ①:例示あり/なし(同一タスクで2プロンプト+出力差+改善点)
  2. 比較ログ②:ロールあり/なし(同一タスクで2プロンプト+出力差+改善点)
  3. ヒアリング内蔵プロンプト(1本):不足情報があれば質問→揃ったら実行
  4. 条件分岐プロンプト(1本):ケース別(例外含む)に出力を分ける
  5. 採点基準(ルーブリック):自部門で使える評価軸(5〜7項目)
  6. 部内共有用「プロンプト術」:最低1つ(テンプレ化・再利用前提)
  7. 質問・所感(投稿):質問1つ以上+気づき

プロンプト設計 応用:結論(何がブレを抑えるか)

1) 例示(Few-shot):欲しい出力を見せる

  • 「こんな感じ」を文章で説明するより、例を見せる方が強い
  • 例示は「内容」よりも構造(見出し・粒度・トーン・禁止事項)を示すのが効く
  • 例示は1つでも効くが、できれば「良い例+悪い例(NG例)」が強い

2) ロール(役割):判断軸を固定する

  • 「あなたは〇〇の専門家」=優先順位判断基準が揃いやすい
  • ロールは盛りすぎない(職種・責務・制約を短く)

3) 不足情報ヒアリング:質問を組み込む

  • 「必要情報が足りないときは質問してから進める」を明記する
  • 質問数は最大3つなど上限を決め、作業が止まらないようにする

4) 条件分岐:ケース別に出力を分ける

  • 「もしAなら…/もしBなら…」を先に固定するとブレが減る
  • 例外(エスカレーション・保留・確認)を分岐として書くと運用が回る

5) 採点基準(ルーブリック):検証しやすくする

  • 「良い/悪い」を感覚にせず、評価軸で揃える
  • 点数化は任意(小テストはしない)。相互レビューはルーブリックに沿って行う

応用テンプレ(コピペ用)

A) 例示+ロール+ルーブリック(統合テンプレ)

【L03 統合テンプレ:例示+ロール+採点基準】

前提(安全):
- 教育訓練用のダミー。実在の個人・企業・契約条件・未公開情報は含めません。
- 個人情報/契約条件/未公開情報/認証情報を推測・補完しないでください。

ロール(役割):
- あなたは(例:EC運営の業務改善担当/対外文面の品質管理担当/企画書レビュー担当)です。
- 優先順位:安全・炎上回避 > 事実と推測の分離 > 分かりやすさ > 速度

目的:
- (例:一次返信文を、丁寧で誤解がなく、次アクションが明確な形に整える)

入力(ダミー/要点):
- 状況:
- 制約:
- 不明点:

出力形式:
- ①成果物(指定形式)
- ②セルフチェック(ルーブリックに沿って○×)
- ③不足情報があれば質問(最大3つ)

例示(良い例/悪い例):
- 良い例:〈ここに出力の形だけを示す〉
- 悪い例:〈断定/煽り/不足/長すぎ等のNGを示す〉

採点基準(ルーブリック):
- 各項目をA(良い)/B(概ねOK)/C(要改善)で自己評価し、その理由を1行で書く
- 項目は5〜7個に限定

B) 不足情報ヒアリング内蔵(質問→揃ったら実行)

【L03 ヒアリング内蔵テンプレ】

前提(安全):
- 教育訓練用のダミー。実在情報は含めない。推測で補完しない。

目的:
- (例:手順書を新人でも回せる形にする)

進め方:
1) まず、作業に必要な不足情報を質問してください(最大3つ)
2) 私が回答したら、その回答を前提に成果物を作成してください
3) それでも不明が残る場合は「不明」と明記し、断定しないでください

出力形式:
- ①成果物
- ②前提(確定情報/不明情報の分離)
- ③注意点(リスク・例外)
- ④次の確認事項(あれば)

C) 条件分岐テンプレ(if/then)

【L03 条件分岐テンプレ】

前提(安全):
- 教育訓練用のダミー。実在情報なし。推測で補完しない。

目的:
- (例:問い合わせ対応をカテゴリ別に標準化する)

条件分岐(例):
- もし「配送遅延」なら:Aパターン
- もし「初期不良」なら:Bパターン
- もし「返品希望」なら:Cパターン
- もし情報不足なら:質問(最大3つ)→回答待ち
- もし規約/権利/契約に触れそうなら:要相談(相談観点を示す)

出力形式:
- 表形式(列:ケース/一次対応文/確認事項/注意点/次アクション)

本日の流れ(タイムライン)

目次(クリックで移動)

  1. 出席・当日選択カリキュラムの内容確認
  2. 時間差相互評価(2件以上コメント)
  3. 休憩
  4. 受領レビュー確認・改善方針メモ
  5. L03 レクチャー本編(講師説明・質疑込み)
  6. 昼休憩
  7. 個人演習①:例示/ロール比較(2本)
  8. 休憩
  9. 個人演習②:ヒアリング+条件分岐+ルーブリック+共有術
  10. 休憩
  11. 復習:提出物の整形(共有できる形に)
  12. 質問・コメント・感想の提出(投稿)

1) 出席・当日選択カリキュラムの内容確認

【実施時間】

対象 時間
EC事業部 08:30–09:10
文房具カフェ事業部/準備室 10:00–10:40

この時間にやること

  1. 今日の成果物(比較ログ2本+ヒアリング+条件分岐+ルーブリック+共有術)を確認
  2. 下の「ダミータスク一覧」から、今日の比較実験に使うタスクを1つ選ぶ
  3. 自分の注意点(安全・断定回避・対外トーン)を1行で書く

セルフ棚卸し(コピペ用)

【L03 セルフ棚卸し】
1) 今日の比較実験に使うタスク(ID):
- 

2) 自分の現場で「出力がブレる原因」になりがちな要素(2つ):
- 
- 

3) 今日の自分の目標(1行):
- 

2) 時間差相互評価(前日までの他者成果物に2件以上コメント)

【実施時間】

対象 時間
EC事業部 09:10–10:00
文房具カフェ事業部/準備室 10:40–11:30

レビュー観点(固定:L03)

  1. 例示が「内容」ではなく構造(粒度・見出し・トーン)を示せているか
  2. ロールが適切か(盛りすぎず、判断軸が固定されているか)
  3. 不足情報の質問があるか(最大3つなど上限があるか)
  4. 条件分岐があるか(例外・保留・要相談が分岐として書けているか)
  5. ルーブリックがあるか(評価軸が5〜7個で、レビューしやすいか)

コメントテンプレ(コピペ用)

【L03 相互レビューコメント】
対象:(相手の成果物タイトル/日付など)

1) 良い点(1つ):
-

2) 例示(Few-shot)は効いてる?
- 効いている/弱い/無い
- 改善案(例示は構造中心に):

3) ロール(役割)は適切?
- 適切/盛りすぎ/弱い/無い
- 改善案:

4) ヒアリング(質問)はある?
- ある(最大___問)/無い
- 改善案(不足情報の優先順位):

5) 条件分岐はある?
- ある/無い
- 改善案(例外・保留・要相談の分岐):

6) ルーブリックはある?
- ある(___項目)/無い
- 改善案(5〜7項目に絞る):

7) 次に試すと良い「一手」(1つ):
- 

3) 休憩

【実施時間】

対象 時間
EC事業部 10:00–10:15
文房具カフェ事業部/準備室 11:30–11:45

休憩:学習作業なし


4) 自分への受領レビュー確認・改善方針メモ(講師レビュー含む)

【実施時間】

対象 時間
EC事業部 10:15–10:45
文房具カフェ事業部/準備室 11:45–12:15

改善方針メモ(コピペ用)

【L03 改善方針メモ】
受領した指摘の要点(最大3つ):
1)
2)
3)

直す理由(ブレ/検証しにくい/再利用しにくい 等):
-

直し方(どの要素を足す?):
- 例示:
- ロール:
- ヒアリング:
- 条件分岐:
- ルーブリック:

今日の自分の最優先ルール(1行):
- 

5) 当日選択カリキュラム実施:L03レクチャー本編(講師説明・質疑込み)

【実施時間】

対象 時間
EC事業部 10:45–12:00
文房具カフェ事業部/準備室 12:15–13:30

ここからが「読む/聞く」パート

講師の口頭説明・質疑応答を挟みながら進めます。
午後の演習は「例示比較」「ロール比較」「ヒアリング+条件分岐」「ルーブリック」「部内共有術」です。

5-1. なぜ出力がブレるのか(要点)

  • LLMは確率的に生成するため、曖昧な依頼ほど解釈の自由度が大きくなりブレる
  • ブレは「悪」ではないが、業務運用では再現性が必要
  • 再現性は、例示・ロール・条件分岐・採点基準で設計できる

5-2. 例示の作り方(コツ)

  • 例示は「正解の内容」よりも「構造」を示す(見出し・粒度・禁止事項・トーン)
  • 例示が長くなる場合は「短い良い例」を1つだけ入れる
  • 可能ならNG例も1つ(断定・煽り・情報不足など)

5-3. ロールの作り方(コツ)

  • ロール=職種+責務+優先順位(短く)
  • 「何を守るか」を明記(安全・断定回避・対外トーンなど)

5-4. ヒアリングの組み込み方(コツ)

  • 質問は最大3つ(優先順位が高い順)
  • 回答がない場合の扱い(保留/不明と明記/一般論で出す)を決める

5-5. 条件分岐の書き方(コツ)

  • よくあるケース分類を先に書く(A/B/C)
  • 例外(要相談、保留、確認待ち)も分岐にする

5-6. ルーブリックの作り方(コツ)

  • 5〜7項目に絞る(多いと運用できない)
  • 「断定回避」「事実/推測分離」「次アクション明確」「トーン」「抜け漏れ」など
  • 点数化は任意。A/B/C評価でもよい(相互レビューの軸が揃えばOK)

6) 昼休憩

【実施時間】

対象 時間
EC事業部 12:00–13:00
文房具カフェ事業部/準備室 13:30–14:30

昼休憩:学習作業なし


ダミータスク一覧(今日の比較実験に使う)

以下から1つ選び、例示比較/ロール比較/ヒアリング+条件分岐に使ってください(すべてダミー)。

【EC向け】

  • EC-T01(易):商品説明文の改善(ダミー商品:特徴3つ+注意書きあり)
  • EC-T02(中):一次返信文(配送遅延:追跡はあるが詳細不明。断定せず確認を促す)
  • EC-T03(難):在庫過多カテゴリの改善案(値引き最小・回転改善。提案は表でメリデメ比較)

【文房具カフェ向け】

  • CF-T01(易):SNS投稿文(季節限定ドリンク。炎上回避・誇大表現回避)
  • CF-T02(中):メニュー改善案(原価率を上げない/回転を落とさない制約つき)
  • CF-T03(難):クレーム一次対応(提供遅延+不快体験。事実確認・謝罪・再発防止の言い方)

【準備室向け】

  • PR-T01(易):企画書の目次構成(ターゲット/価値/導線/収益の章立て)
  • PR-T02(中):告知LPの構成改善(固有名詞は伏せる。注意書き・導線を明確に)
  • PR-T03(難):提案書の骨子(権利・未公開に配慮。前提分離+リスク/ToDo整理)

7) 個人演習①:例示あり/なし・ロールあり/なし(比較2本)

【実施時間】

対象 時間
EC事業部 13:00–14:30
文房具カフェ事業部/準備室 14:30–16:00

演習①のやり方

  1. 選んだタスクIDで、まず「ベース(例示なし/ロールなし)」プロンプトを作って実行する
  2. 同じタスクで、例示ありにしたプロンプトを作って実行し、差分を比較する(比較ログ①)
  3. 同じタスクで、ロールありにしたプロンプトを作って実行し、差分を比較する(比較ログ②)
  4. 差分を「何が改善されたか/何が悪化したか」を言語化する

比較ログ(2本分:コピペ用)

【L03 比較ログ①:例示あり/なし】

タスクID:
- 

A(例示なし)プロンプト:
- 

Aの出力(要約で可):
- 

B(例示あり)プロンプト:
- (良い例/悪い例は“構造”中心に)

Bの出力(要約で可):
- 

差分(良くなった点):
- 
差分(悪くなった/注意点):
- 

次の改善(1手):
- 


【L03 比較ログ②:ロールあり/なし】

タスクID:
- 

A(ロールなし)プロンプト:
- 

Aの出力(要約で可):
- 

B(ロールあり)プロンプト:
- (職種+責務+優先順位を短く)

Bの出力(要約で可):
- 

差分(良くなった点):
- 
差分(悪くなった/注意点):
- 

次の改善(1手):
- 

8) 休憩

【実施時間】

対象 時間
EC事業部 14:30–14:45
文房具カフェ事業部/準備室 16:00–16:15

休憩:学習作業なし


9) 個人演習②:不足情報ヒアリング+条件分岐+ルーブリック+部内共有術

【実施時間】

対象 時間
EC事業部 14:45–15:45
文房具カフェ事業部/準備室 16:15–17:15

演習②-1:ヒアリング内蔵プロンプト(1本)

選んだタスクを対象に、まず質問(最大3つ)→回答後に作成、の流れを組み込みます。

演習②-2:条件分岐プロンプト(1本)

ケース分類(A/B/C)+例外(情報不足/要相談)を分岐として書き、表で出力させます。

演習②-3:採点基準(ルーブリック)を作る(5〜7項目)

自部門でレビューしやすい評価軸を作ります(点数化は任意。A/B/CでもOK)。

演習②-4:部内共有用「プロンプト術」1つを作る

今日の学び(例示/ロール/ヒアリング/条件分岐/ルーブリック)のうち、部内で共有したい“使える型”を最低1つ作り、テンプレ化します。

提出用フォーマット(コピペ用)

【L03 提出物(演習②)】

(1) ヒアリング内蔵プロンプト(最終):
- 

(2) 条件分岐プロンプト(最終):
- 

(3) ルーブリック(5〜7項目):
- 1)
- 2)
- 3)
- 4)
- 5)
- (必要なら6,7)

(4) 部内共有用「プロンプト術」(テンプレ):
- テンプレ名:
- 使う場面(誰が何に使う):
- プロンプト本文:
- 変数(差し替え項目):
- 注意点(安全/断定回避/対外トーン):
- 使い方(3ステップ):

10) 休憩

【実施時間】

対象 時間
EC事業部 15:45–16:00
文房具カフェ事業部/準備室 17:15–17:30

休憩:学習作業なし


11) 復習:提出物の整形(共有できる形に)

【実施時間】

対象 時間
EC事業部 16:00–16:30
文房具カフェ事業部/準備室 17:30–18:00

最終チェック(コピペ用)

【L03 最終チェック】
- 比較ログ①(例示あり/なし)が完成:差分が言語化できている
- 比較ログ②(ロールあり/なし)が完成:差分が言語化できている
- ヒアリング内蔵プロンプトがある(質問は最大3つ、回答後に作成する流れ)
- 条件分岐プロンプトがある(A/B/C+例外:情報不足/要相談)
- ルーブリックが5〜7項目で作れている(レビューしやすい)
- 部内共有用「プロンプト術」がテンプレ化できている(変数が明確)
- 実データを使っていない(ダミーのみ)

12) 講師への質問・コメント・感想の提出(指定スレッド)

【実施時間】

対象 時間
EC事業部 16:30–17:00
文房具カフェ事業部/準備室 18:00–18:30

提出先(参考)

EC事業部・文房具カフェ事業部:ChatWork の指定スレッド/準備室:Slack の指定スレッド

提出テンプレ(コピペ用)

【L03 提出(本人レポート)】

1) 今日の学習内容(要約:3行)
-
-
-

2) 例示あり/なしで、最も差が出たポイント(1つ)
- 
理由:
- 

3) ロールあり/なしで、最も差が出たポイント(1つ)
-
理由:
-

4) ヒアリング(質問)で「先に聞くべきだ」と分かった項目(1つ)
-
理由:
-

5) 自分のルーブリック(5〜7項目)のうち、最重要だと思う項目(1つ)
-
理由:
-

6) 部内共有用「プロンプト術」テンプレ名
- 

7) 質問(最低1つ)
- 

(参考)このレッスンで特に守ること(まとめ)

  • 例示・ロールで「判断軸」と「出力構造」を固定する
  • 不足情報は質問(最大3つ)として先に回収し、断定を避ける
  • 条件分岐で例外(保留・要相談)を運用に織り込む
  • ルーブリックで検証しやすくし、相互レビューで学び合う

ページ先頭へ戻る

上部へスクロール