プロンプトエンジニアリング ── 再現性ある指示設計── 構造化・few-shot・思考の連鎖と、評価で崩れを防ぐ

01プロンプトとは何か ── 「指示文」を厳密に定義する

プロンプト（prompt、＝AI に渡す指示文）とは、大規模言語モデル（＝大量の文章で学習した AI）に与える入力テキストを指します。「この文章を要約して」「以下の条件で見出しを 3 案出して」といった一文から、役割・前提・制約・出力形式まで細かく指定した数百語の文章まで、どれもプロンプトです。

まず一つ押さえておきたい。AI は「正しさ」を計算しているのではなく、「次に来そうな言葉のもっともらしさ」を計算している。だから、指示がわずかに違うだけで出力は変わります。同じ意図でも、書き方が曖昧なら答えも曖昧に、書き方が具体的なら答えも具体的に返る。プロンプトエンジニアリングは、この性質を逆手に取り、出力を望む方向へ寄せる作業です。

製薬の現場に置き換えると、これは資材の下書き、症例要約、規制文書の読み解き、社内 FAQ の起案など、日々の文章仕事のすべてに関わってきます。頼み方が人によってばらつくと、担当者が代わるたびに品質もぶれます。手順として言葉にしておけば、チームの誰が回しても一定の質を保てます。

02指示の構造化 ── 曖昧さを削る四つの部品

良いプロンプトは、行き当たりばったりの一文ではなく、部品の組み合わせでできています。実務でまず効くのは、次の四つを明示的に分けて書くことです。

この四つを分けて書くだけで、出力の安定度は目に見えて上がります。なかでも 文脈（Context）の渡し忘れが、製薬では最大の事故源です。承認外の効能を書かせないためには、「使ってよい効能はこれだけ」という枠を、指示のたびに文脈として渡す。枠がなければ、AI は自由に「盛って」しまいます。

03few-shot の使い方 ── 手本を数例見せて型を移す

few-shot prompting（＝数例の手本を先に見せてから本題を頼む方法）は、最も費用対効果の高い技法の一つです。言葉で細かく指示する代わりに、「入力 → 望ましい出力」の組を 2〜5 例ならべて見せ、最後に本番の入力を置く。AI はその型を読み取り、同じ調子で答えを返します。

この手法が効くことは、GPT-3 を発表した Brown ら（2020）が大規模に確かめました。手本を一つも与えない zero-shot（＝手本ゼロ）、一つだけの one-shot、数例の few-shot を比べると、多くの課題で手本を増やすほど精度が上がる。学習をやり直さなくても、プロンプトに例を入れるだけで振る舞いを変えられる ── これが few-shot の核心です。

実務での使いどころは、次のような場面です。

• 出力の体裁を揃えたいとき ── 見出しのトーン、語尾、文字数感を、言葉で説明するより手本を見せたほうが正確に伝わります。
• 判断基準を型で示したいとき ── 「この表現は OK / この表現は NG」という組を数例見せると、境界線が言葉より鮮明に伝わります。
• 専門用語の扱いを固定したいとき ── 社内で決めた訳語や言い回しを、例として先に見せておくと揺れが減ります。

ただし手本の選び方には注意がいります。手本に偏りがあると、その偏りごと真似します。誇張気味の例を混ぜれば誇張した出力を、古い言い回しを混ぜれば古い出力を返す。few-shot は「見せた通りに寄る」技法です。だから、手本そのものが承認内容や規範に沿っているかを、先に人が確かめておく必要があります。

04Chain-of-Thought（思考の連鎖）── 過程を書かせて精度を上げる

Chain-of-Thought prompting（CoT、＝思考の連鎖。答えだけでなく途中の考えも書かせる方法）は、Wei ら（2022）が提唱した技法です。計算問題や論理問題で、「答えを出して」ではなく「順を追って考えてから答えて」と頼むと、正答率が上がることを示しました。人間が途中式を書くと計算ミスが減るのと似ています。

関連して Kojima ら（2022）は、「順を追って考えましょう」の一文を添えるだけでも、手本なしで推論の質が上がる場合があると報告しました。CoT は、複雑な判断を一息に出させるのではなく、途中の根拠を言葉にさせて飛躍を防ぐ手法だと理解してください。

製薬の実務では、CoT は次のように役立ちます。

• 規制チェックの根拠を残す ── 「この表現が誇大にあたるかを、条文と照らして順に説明してから結論を出して」と頼むと、判断過程が記録され、人が検証しやすくなります。
• 要約の抜け漏れを減らす ── 長い文書を要約させるとき、「まず論点を列挙し、次に重要度を判断し、最後に要約する」と段階を切ると、重要点の取りこぼしが減ります。

05出力の評価 ── 「良さそう」を測れる基準に変える

プロンプトを工夫すると出力は良くなります。しかし「良くなった気がする」では、仕事には使えません。プロンプトエンジニアリングの後半は、出力を客観的に評価する仕組みづくりです。感覚ではなく、あらかじめ決めた物差しで測る。

評価の軸は、少なくとも次の三つに分けて考えると整理できます。

大切なのは、評価を作る人と、プロンプトを書く人を分けることです。書いた本人が「良い」と判断すると、どうしても自分に甘くなります。別の担当、別の観点で評価する ── この切り分けが、品質の水増しを防ぎます。人手の評価に加えて、少数の代表例に「期待する答え」を用意し、プロンプトを変えるたびにそこへ照らす。これも有効です。

06回帰テスト ── プロンプトを「壊れたら気づける」状態に保つ

プロンプトは一度うまく書けても、それで安泰ではありません。文面を少し直したとき、使う AI のバージョンが上がったとき、以前は正しく出ていた出力が静かに崩れることがあります。これを人手で毎回すべて確かめるのは、現実的ではありません。だから 回帰テスト（＝以前通っていた挙動が今も通るかを繰り返し確認する仕組み）を用意します。

やり方の骨格はシンプルです。

• 代表的な入力と、期待する出力の組を数十件そろえる ── 過去に問題が起きた例、境界が微妙な例を優先して集めます。
• プロンプトや AI を変えるたびに、その組を一括で流す ── 期待どおりか、逸脱していないかを自動で照合します。
• ずれたら止める ── 一件でも規範に触れる出力が出たら、その変更は公開前に差し戻します。

製薬では特に、「誇大にあたる表現を出さないか」「承認外の効能を書かないか」を確かめるテスト例を、意図して集めておくことが効きます。危ない入力をわざと投げ、AI が踏みとどまるかを見る。コードの世界で言う「壊れやすい箇所ほど厚くテストする」考え方と同じです。次回（第 4 回）で扱うテスト生成の話とも、まっすぐつながります。

07よくある落とし穴 ── 現場で繰り返される失敗

プロンプト設計でつまずく点は、だいたい決まっています。先に知っておくと避けられます。

• 一度に欲張る ── 「要約して、見出しも作って、ついでに校正して」と詰め込むと、どれも中途半端になります。タスクは分けて呼ぶ。
• 前提を渡し忘れる ── 承認された効能や対象読者を書かずに頼むと、AI が空白を勝手に埋めます。文脈は毎回明示する。
• 手本の偏りをそのまま移す ── few-shot の例が誇張的・古い表現だと、出力もそうなります。手本は先に人が点検する。
• 過程の説明を根拠と勘違いする ── CoT の「考えの過程」は説明であって証明ではありません。結論は独立に検証する。
• 一度動いたら二度と見ない ── AI の更新や小さな修正で出力は崩れます。回帰テストで継続的に見張る。
• プロンプトに機密や個人情報を直書きする ── 症例や社内限りの情報の扱いは、社内規程と契約条件に従う。安易に貼らない。

これらはどれも、技術というより設計の規律の問題です。頼み方を言葉にし、前提を明示し、評価を切り分け、テストで守る。派手な小技より、この地味な規律が品質を支えます。

08本サイトの他の章との接続

プロンプト設計は、本サイトの他の章と次のように繋がります。読み合わせると、点が線になります。

• AI Programming 第 4 回 ── AI と書くテスト ── 本回の「回帰テスト」を、コードのテスト生成と TDD の文脈へ広げます。プロンプトを守る発想の続きです。
• AI Marketing 第 5 回 ── 生成コンテンツと審査 ── few-shot や CoT で作った下書きを、資材審査という "出口" でどう受け止めるか。設計と審査の接点です。
• 広告規制 第 1 回 ── 薬機法 §66〜68 ── 評価軸の「規範適合」の土台。誇大・未承認・情報提供の線引きの原典です。
• 資材審査シリーズ ── AI 製の草案を最後に受け止める審査の実務。人による最終判断の作法を扱います。

プロンプトエンジニアリングは、魔法の呪文を探す作業ではありません。指示を四つの部品に分け、必要なら手本を見せ、複雑な判断は過程を書かせる ── どれも「曖昧さを削り、飛躍を防ぐ」ための地味な工夫です。そのうえで出力を、感覚ではなく決めた物差しで評価し、回帰テストで守り続ける。ここまでやって初めて、プロンプトは「たまたま良かった一発」から「誰が回しても同じ結果が出る仕組み」に変わります。

製薬の現場では、この再現性がそのまま安全性につながります。AI が速く書けても、薬機法は緩みません ── 誇大は 66 条、未承認は 68 条、情報提供は 68 条の 2。問われるのは「誰が書いたか」ではなく「何が書かれているか」です。プロンプトを設計として言語化し、評価とテストで囲うこと。それが、生成 AI を規制の内側で使いこなすための、いちばん確かな足場になります。次回は、この「テストで守る」発想を、AI と一緒に書くテストと TDD の話へ進めます。