【AIとの距離感】プロンプトを「設計」と呼ぶようになるまで｜プロンプトエンジニアリング

前の記事を読んでいるとより理解しやすくなっています。
はじめての方は先にこちらをどうぞ。

✍️ ただの「お願い」だと思っていた

Claude・Gemini・GPTに何かを頼むとき、最初は「お願いする文章」くらいの感覚でした。丁寧に頼めば丁寧に返ってくる、というくらいの理解です。

「AIイラストの考え方」というシリーズで日々プロンプトを書いていて、だんだん「これは設計だ」という感覚に変わってきました。今回はその感覚を、あらためて言葉にしてみます。

🎯 プロンプトエンジニアリングとは何か

プロンプトエンジニアリングは、AIから望む出力を得るために、指示文（プロンプト)を工夫する技術です。つまり、AIに何をどう伝えれば、意図した通りの結果が返ってくるかを設計する営みのことです。

「エンジニアリング」という言葉がついているのが最初は大げさに感じましたが、実際にやっていることは「試して、直して、また試す」という地道な作業の積み重ねです。プログラミングでバグを直す感覚に近いのかもしれません。

🔢 Zero-ShotとFew-Shot

プロンプトの工夫の仕方には、いくつかの型があります。その代表がZero-ShotとFew-Shotです。

Zero-Shotは、例を示さずに、いきなり質問や指示だけを出す方法です。つまり、「こういうことをやって」とだけ伝えて、AIに任せる形のことです。

Few-Shotは、いくつかの例を先に示してから、本番の質問をする方法です。一言でいうと、「こういう感じでお願いします」という見本を渡してから頼む、ということです。

たとえば文章の要約を頼むとき、Zero-Shotなら「この文章を要約して」と伝えるだけ。Few-Shotなら、いくつかの文章と要約例のペアを見せてから、新しい文章の要約を頼みます。

自分がイラストのプロンプトを書くときも、うまくいかないときは無意識にFew-Shot的なことをやっていました。「こういうテイストで」と過去にうまくいった例を貼り付けたりする。名前を知らないままやっていたことに、後から名前がついた感じです。

🧭 設計、と呼ぶようになった理由

なぜ「お願い」から「設計」に感覚が変わったのか、あらためて考えてみました。

「お願い」は、一度伝えて終わりのイメージです。でも実際にプロンプトを書いていると、狙った結果が出るまで何度も調整することがほとんどです。文の順番を変える、具体例を足す、条件を絞る。これを繰り返す過程は、「お願いする」というより「組み立てる」に近い感覚でした。

Claudeに文章の相談をするときも、Geminiで調べものをするときも、GPTで壁打ちをするときも、うまくいくときは大体「最初の指示をどう作るか」に時間をかけています。

🌊 今は、また少し形が変わってきているらしい

ここまで書いておいて言うのもなんですが、調べていたら「プロンプトエンジニアリング」という言葉自体、少しずつ役割を終えつつあるという話が出てきました。

AIモデルの性能が上がって、多少ざっくりした指示でも精度の高い答えが返ってくるようになってきた。代わりに注目されているのが、コンテキストエンジニアリングという考え方です。つまり、「どう質問するか」だけでなく、「AIが答えるために必要な情報や環境を、そもそもどう整えておくか」まで含めて設計する、というより広い視点のことです。

自分が「AIイラストの考え方」でやっているプロンプト作りも、振り返るとキャラクターのリファレンスシートを用意したり、過去の生成結果を参照させたりと、「質問の言い方」より「渡す材料の設計」に重心が移ってきている気がします。名前が変わっただけで、実はやっていることの延長線上にあるのかもしれません。

🔗 毎日使っているAIとのつながり

「AIイラストの考え方」を書きながら、プロンプトの精度をずっと試行錯誤してきました。この連載を通して、その試行錯誤が「プロンプトエンジニアリング」という名前のついた営みだったと知りました。

自分がやってきたことに、後から名前と理論がついてくる。この感覚は、シリーズを書いていて何度か経験しています。今回はさらに、その名前自体が移り変わっていく現場を見ている感じもしました。

ま、いっか。

あとがき

ここまで読んでくださり、ありがとうございます。

プロンプトエンジニアリングについての記事ですが、今後はコンテキストエンジニアリングの方が大事になってくるのかもしれない？

一つ学んだと思ったら、もうすでに先にいっているw

よければご活用ください〜

「フォロー」や「スキ」をしていただけると励みになります！
今後ともよろしくお願いします！