なぜプロンプトエンジニアリングだけでは足りないのか

2026.08.17
2026.10.16

1. 「AIへの上手な頼み方」だけでは、もう不十分な段階に入っている

数年前「プロンプトエンジニアリング」という言葉が流行した。AIに上手に指示を出す技術のことである。この技術が無駄になったわけではない。

2026年のいまも、直接プロンプトを打ち込むやり方は依然として有効な場面が多い。しかし、プロンプトの巧拙だけに投資を集中させても、業務システムとしての信頼性は積み上がらない。むしろ、プロンプトを「都度の工夫」から「仕組みとして設計・記録・検証できるもの」へ位置づけ直す必要がある。理由を、AI利用を捉えるための4つの視点で説明したい。

2. AI利用を捉える4つの視点（本稿独自の実務モデル）

あらかじめお断りしておきたいのは、以下の4分類は業界で標準化された公式のフレームワークではなく、本稿が実務整理のために独自に提示する4つの視点だという点である。AI開発の現場でも、階層の区切り方や呼び方には論者による幅がある。たとえば、ソフトウェアエンジニアAddy Osmani氏は「ハーネス」を「モデル以外のすべて」と広く定義し、その中にシステムプロンプトやコンテキスト方針を含めて説明している（Addy Osmani, Agent Harness Engineering）。

つまり、コンテキストを独立した層として切り出す考え方は、氏の議論では前提とされていない。以下の整理は、GxP実務での説明のしやすさを優先した便宜的なものと理解していただきたい。

プロンプト（個別の作業指示）
「この逸脱に似た事例を探して」と、その都度お願いする。
コンテキスト（判断材料の資料一式）
SOP・過去の逸脱記録・バッチ記録・製品履歴を、毎回同じ形で渡すよう決めておく。
ハーネス（安全装置と作業環境）
検索してよい範囲、必ず付ける出典、してはいけないこと、止まる条件を、環境の側で強制する。
ループ（自動的に開始・反復する仕組み）
逸脱番号の発行を合図に、AIが自分で動き出す。

上下関係ではなく、業務に応じて「どこまで設計するか」を選ぶものである。記録・検証・停止という統制の考え方は、理屈のうえではどの層に対しても適用しうる。プロンプトの内容を記録し、コンテキストの与え方を検証し、必要なら処理を止めることも、原理的には可能である。

ただし実務上、それを人手の運用ではなく仕組みとして強制し、繰り返し再現できる形にできるのは、多くの場合ハーネス以降の層である。層3以降で初めて、統制が「お願いベース」から「環境による強制」に変わる、という理解のほうが正確である。

3. プロンプトの限界と、できることの整理

属人的である。Aさんの指示は的確で、Bさんの指示は雑、ということが起きる。担当者が変われば品質も変わる。

査察官に「担当者の腕次第です」とは説明できない。プロンプトの文章そのものを、後から機械的に「上手だったか」と判定する標準化された手段は一般に存在しない。ただし、これは「検証が一切不可能」という意味ではない。

プロンプトを含むAIシステム全体は、あらかじめ定義したユースケース、受入基準、テストデータセット、繰り返し試行、リグレッションテストによって評価することができる。実際、Anthropic社は、定義した入力と成功基準、複数回の試行、grader、実行記録を組み合わせるエージェント評価の手法を公開している（Anthropic, Demystifying evals for AI agents）。したがって正確には「プロンプトの文章単体を機械的に採点する仕組みは一般化されていないが、システム全体としての評価・検証は可能であり、その体系化こそが課題である」という整理になる。

プロンプトはそれ自体では技術的な強制力を持たない。プロンプトは要するに「お願い」である。「機密情報は入力しないでね」と頼んでも、入力しようと思えばできてしまう。入力できないようにする、あるいは特定の操作を技術的に禁止するのは、ハーネス（層3）が担うべき仕事であり、プロンプトはハードなセキュリティ制御の代替にはならない。

4. 現場からも同じ方向性の議論が出ている

2026年6月、コーディングエージェント開発者のPeter Steinberger氏がX（旧Twitter）に投稿し、「もはやコーディングエージェントにプロンプトを与えるべきではない。エージェントにプロンプトを与えるループを設計すべきである」という趣旨を述べた（Peter Steinberger, X投稿）。この発言はコーディングエージェントの運用について述べたものであり、GxP業務全般を対象にした主張ではない点に注意が必要である。

この投稿を受けて、ソフトウェアエンジニアのAddy Osmani氏が自身のブログ記事「Loop Engineering」で議論を整理し、Anthropic社のClaude Code責任者Boris Cherny氏の「もはやClaudeに直接指示は出していない。指示を出すのはループのほうで、自分の仕事はループを書くことだ」という趣旨の発言と合わせて紹介した（Addy Osmani, Loop Engineering）。Osmani氏自身は、この記事の中で「ループを組んでもよいが、エージェントに直接プロンプトを与えることも依然として有効であり、バランスの問題だ」と明記しており、プロンプト入力そのものを不要と主張しているわけではない。頼み方だけを磨くのではなく、頼む仕組みも合わせて作れ、という意味だと理解するのが妥当である。

5. 誤解のないように　消えるのではなく、位置づけが変わる

プロンプトが無意味になるわけではない。個人の技量だけに依存する運用から、システムとして記録・管理される運用へ、位置づけが移るのである。その記録の粒度は、業務のリスクに応じて設計すべきものであり、分野によって求められる水準が異なる。

GxP業務では、第12回で示したAI利用記録の例のように、プロンプトの全文を毎回保存するのではなく、どのテンプレートの第何版を使ったかを基本の記録単位とし、リスクが高い業務については、実行時に展開された実際のプロンプト、渡したコンテキスト、使用したモデルのバージョンと設定、出力結果、そして人によるレビュー結果までを合わせて残す、というリスクベースの設計が現実的である。なお、分野によって記録の要求水準は異なる。たとえば医薬品のGxP領域とは別の枠組みだが、EUの医療技術評価に関する調整グループ（HTACG）が2026年7月に採択した「共同臨床評価（JCA）用ドシエ作成におけるAI利用に関する一般原則」は、AIツールの名称・バージョン・開発者・利用目的の記録に加え「使用した全てのプロンプトを記録し、要求があれば提示できるようにすること」を明記している（European Commission, General principles on the use of AI in the preparation of the JCA dossier）。

これはGMPの要求ではなく、EUの医療技術評価という別の規制文脈における原則である点を明確にしておきたい。GxP領域にそのまま適用されるものではないが「プロンプトを記録対象とする」という発想が他の規制領域で明文化されている例として参考になる。また、層1・層2にあたる作業が無用になるわけでもない。

渡す資料を仕組みとして固定すれば、再現性は確かに上がる。要は、担当者の技量に品質を委ねている領域を、設計で置き換えられる領域へ順に移していく、ということである。現行のGxP関連ガイドラインの状況も踏まえておく必要がある。

EU GMP附属書11（コンピュータ化システム）は、コンピュータ化システム全般に対し、意図した用途とリスクに応じたバリデーションを求める現行GMPガイドラインである（European Commission, EU GMP Annex 11: Computerised Systems）。これに対し、AI固有の要求を定めるものとして新設が検討されている附属書22（人工知能）があるが、これは2026年8月時点で最終化されていない協議用ドラフトであり、しかも適用範囲を静的で決定論的な出力を持つAI/機械学習モデルに限定し、生成AIおよび大規模言語モデル（LLM）は明示的に対象外としている（European Commission, Draft Annex 22: Artificial Intelligence）。したがって、生成AIを用いたプロンプト運用を検討する際に、附属書22を現行の拘束力ある要求として引用することはできない。

あくまで将来の規制方向を示す参考情報として扱うべきである。GxPに置き換えれば、話はそれほど複雑ではない。「口頭指示が上手な人」を育てるだけでなく、指図書と受入基準を整備し、それを裏づける記録を残す。

ただし生成AIは確率的に出力が変動するシステムであり、同じ指図書を与えても毎回同じ結果になるとは限らない。したがって、指図書と受入基準を整備するだけで完結するのではなく、継続的なモニタリングとレビューによって、システムが意図した範囲で機能し続けていることを確認し続ける必要がある。これは、私たちが数十年やってきた「文書と記録による統制」の考え方を、確率的なシステムに合わせて拡張する作業だといえる。