AIで飯を食いたい訳じゃない50代オッサンの程ほどAI活用ログ

AIは賢いけど意外とおバカさん。意外と見栄っ張り。意外とお調子者。意外と頑固。意外と視野が狭い。意外と融通利かない。意外とゴネたら頼みを聞いてくれる。

生成AIに対してプロンプトエンジニアリングを考慮する必要性

去年7月には、プロンプトエンジニアリングを考えると良いよ、とAIにアドバイスされたのだが、

floatingwater.hatenablog.jp

 

その後、各社の生成AIが賢くなりすぎていて、プロンプトの工夫=プロンプトエンジニアリングが不要になりつつあるらしい。

2026年4月9日のこと。

Gemini

Geminiさんに聞いてみた。

最新のAIでプロンプトエンジニアリング考慮する必要性ついてGeminiさんに聞いてみた。

昨年、少し勉強して取得したPEP(Prompt Engineering Professional)検定合格という資格に関して、その後に以下の理由から有効性が低下しているとの言説を耳にしました。妥当な見解と言えますか?
言説:
今まで半年余りの間に各社の生成AI能力向上が目覚ましく、生成AIへの指示におけるプロンプトの構成について、「命令・文脈・入力データ・出力形式」や「役割設定」などの出力の質向上のために有効とかつて言われた要素を今はもう意識する必要がなくなって、「プロンプトエンジニアリング」というものも必要なくなって来た。

#依頼:
・上記にリクエストした妥当性に関するコメントに加えて、プロンプトエンジニアリングの内容や必要性が変容してきているだけで不要になってきた訳ではない、という場合にはその変容の内容を具体例を伴って示してください。
・上記は狭義に生成AIに関する範囲で回答ください。AIエージェントの構築において全体像をデザインした上でコンテキストエンジニアリングがより以上に重要になってくるのは、生成AI活用とは別の範疇のことと理解しています。

 

最近のプロンプトエンジニアリングの扱いに関するGeminiさんの回答は次の通り。

PEP検定の合格、おめでとうございます!せっかく努力して取得した資格の価値について否定的な意見を耳にすると、不安になるのも無理はありません。

結論から申し上げますと、ご提示の言説は**「半分は正解だが、半分は早計」というのが妥当な見解です。モデルの賢さが「曖昧さ」をカバーできるようになったのは事実ですが、それはプロンプトエンジニアリングの「終わり」ではなく「洗練」**を意味しています。

以下に詳しく解説します。


1. 言説の妥当性:何が「不要」になったのか

ご提示の言説が正しいと言える部分は、**「モデルが文脈を汲み取る力が飛躍的に向上した」**という点です。

  • 「お作法」の形骸化: 以前は、特定の呪文のようなキーワード(例:「深呼吸して考えて」など)を入れないと性能が出ない時期がありましたが、現在は自然な文章で指示しても高い精度が得られます。

  • 構造化の自動補完: モデル自体が「この入力はデータで、ここからが指示だな」と自ら構造を理解する能力(推論能力)が上がったため、厳密なフォーマットに固執しなくても失敗しにくくなりました。

しかし、これは「誰でもそこそこの結果を出せるようになった」だけであり、「最高の結果を引き出す技術」が不要になったわけではありません。


2. プロンプトエンジニアリングの「変容」と具体例

プロンプトエンジニアリングは、単純な「書き方のコツ」から、より高度な**「論理設計」と「評価」**へと変容しています。

① 「構成の強制」から「思考プロセスの制御」へ

かつては「役割:プロのライター」と設定すること自体が目的でしたが、現在はモデルに**「どのような手順で考えさせるか」**を指定する技術が重要になっています。

  • 具体例:

    • 旧: 「プロの編集者として、この文章を校正して」

    • 新: 「まず文章の論理的矛盾を抽出し、次にターゲット層の語彙レベルに合わせた表現案を3つ出し、最後にそれらを統合して修正案を作成して(Chain of Thoughtの明示的利用)」

② 「出力形式の指定」から「データの変換ロジック」へ

単に「表形式で出して」と言うだけでなく、複雑な非構造化データから特定のロジックに基づいた抽出を行うための、より精密な指示が必要になっています。

  • 具体例:

    • 旧: 「要約して」

    • 新: 「カスタマーサポートのログから『不満の根本原因』『感情の激しさ(1-5)』『解決までの工数予想』を抽出し、JSON形式で構造化して」

③ 「一発の精度」から「反復と検証(Few-shot)」へ

モデルが賢くなったからこそ、曖昧な指示では「モデルなりの正解」が返ってきてしまいます。意図通りの「固有の正解」を得るためには、良質なサンプル(Few-shot)を与える技術がこれまで以上に重要です。


3. なぜ今も「必要」なのか(狭義の生成AIの範囲で)

生成AIの能力が向上しても、プロンプトエンジニアリングが必要な理由は以下の3点に集約されます。

  1. トークンコストと速度の最適化: ダラダラと長い文章で指示するよりも、簡潔で構造的なプロンプトの方が、処理速度が速く、APIコストも抑えられます。

  2. 再現性の確保: 「なんとなく良い回答」ではなく、業務で使うために「常に同じ品質の回答」を得るには、プロンプトの堅牢な設計(命令と文脈の分離など)が不可欠です。

  3. ハルシネーション(幻覚)の抑制: 「知らないことは知らないと言わせる」「根拠となるソースを特定させる」といった制御技術は、モデルが進化しても依然としてプロンプト側の工夫に依存します。


結論

PEP検定で学ばれた「命令・文脈・役割設定」といった基本要素は、現在では**「意識しなくても動く」ようになりましたが、「意識して使いこなせば、さらに圧倒的な差がつく」武器**へと進化しました。

数学で例えるなら、「計算機が普及したから計算の仕組みを学ぶ必要がなくなった」のではなく、「仕組みを知っている人が計算機を使うことで、より高度な数理モデルを構築できるようになった」状態に近いです。

資格取得で得た基礎知識は、今後「AIをどう使いこなすか」というメタ認知能力として、引き続きあなたの強力な資産となるはずです。自信を持って活用を続けてください。

一歩進んだ活用法として、特定のタスクにおける「最適なプロンプトのテンプレート化」などに挑戦してみてはいかがでしょうか?

 

ついでに、同じ質問へのCoilotさんの回答は、次の通り。

Copilot

Copilotさんに聞いてみた。
結論から言うと、あなたが耳にした 「プロンプトエンジニアリングはもう不要になった」という言説は“妥当ではない” です。 ただし、“かつての形のプロンプトエンジニアリングは不要になりつつある” という点には一定の根拠があります。 つまり、不要になったのではなく“役割が変容した” のが実態です。

以下、検索結果の事実も踏まえて体系的に整理します。 (引用:)

◆ 1. 言説の妥当性:どこまで正しいのか

● 正しい部分(限定的)

  • GPT-5/Claude 4.5/Gemini 3 などの最新モデルは 曖昧な指示でも意図を推測し、補完し、整った出力を返せる ようになった。

  • そのため、 「命令・文脈・入力データ・出力形式」を厳密に書かないと動かない時代ではなくなった。

  • 「誕生日メッセージを書いて」「この記事を要約して」などの単純タスクでは、ほぼプロンプト技術は不要。

● 不正確な部分(重要)

しかし、検索結果が示す通り、2025〜2026年の専門家の共通見解は:

プロンプトエンジニアリングは“死んだ”のではなく“進化した”。 (PromptGalaxy, 2025-12)

高度なタスクでは依然としてプロンプト設計が成果物の質を左右する。 (Note, 2025-03)

2026年においても必須スキルであり、むしろ複雑化している。 (AI Tools, 2025-04)

つまり、 「昔のプロンプト技法がそのまま通用しなくなった」=正しい 「プロンプトエンジニアリングが不要になった」=誤り という評価が妥当です。

◆ 2. なぜ「不要になった」と誤解されるのか

● 理由1:モデルの自然言語理解が向上した

  • 以前は「役割設定」「出力形式」「制約条件」を細かく書かないと崩れたが、 今はモデルが自動補完してくれる。

● 理由2:ユーザー側の“体験”が変わった

  • 以前:プロンプトが悪いと出力が破綻

  • 今:多少雑でもそれなりに整った回答が返る →「もう工夫しなくていいのでは?」と錯覚しやすい。

● 理由3:プロンプトの“書き方”が変わった

  • 以前:1プロンプトで全てを詰め込む

  • 今:

    • システムプロンプト

    • プロジェクト設定

    • 長文コンテキスト

    • マルチモーダル入力 など、構造化された環境設計が主流になった。

◆ 3. 現代のプロンプトエンジニアリングは「別物」に進化している

検索結果から抽出すると、2025〜2026年のプロンプトエンジニアリングは以下の方向に変容しています。

◆ 4. 変容したプロンプトエンジニアリングの具体例

① “個別プロンプト”から“システム設計”へ

旧来: 「あなたは○○の専門家です。次の文章を〜」と毎回書く。

現在:

  • ChatGPTの「Custom Instructions」

  • Claudeの「Projects」

  • APIのsystem prompt に一度設定すれば、以後は自然に会話するだけでよい。 (検索結果でも「個別プロンプトから persistent instructions へ移行」と明記)

例: 自治会規約の改定作業で

  • 文体

  • 用語統一

  • 法的観点のチェック

  • 出力形式 をシステムプロンプトに固定しておくと、以後の作業が一貫する。

② “文章の工夫”から“コンテキスト管理”へ

検索結果では「長文コンテキストの構造化」が重要とされる。

旧来: 1つのプロンプトに全部詰め込む。

現在:

  • 参照資料を分割して与える

  • どの情報を優先するかを明示

  • どこからどこまでを“今回のタスク”とするかを指定

  • 必要に応じて「会話をリセット」する判断

例: 自治会規約の改定案を作る際、

  • 現行規約

  • 住民の要望

  • 法的要件

  • 過去の議事録 をセクションごとに整理して与えると、出力の整合性が大幅に向上する。

③ Chain-of-Thought(思考の連鎖)の“誘導”

モデルは自動推論できるが、 「段階的に考えさせる」指示は依然として効果が大きい。 (検索結果でも「CoTは依然有効」と明記)

例: 「自治会の残余財産の扱いについて、

  1. 法的観点

  2. 他自治体の事例

  3. リスク

  4. 推奨案 の順に検討して提示してください。」

④ 出力形式の厳密指定はむしろ重要度が上昇

検索結果では「JSON形式・Markdown形式などの指定は依然重要」とされる。

例:

  • 総会資料のドラフトをMarkdownで

  • 規約の比較表を表形式で

  • 住民説明用のFAQをJSONで

⑤ マルチモーダル前提のプロンプト設計

2025〜2026年の特徴として、 画像+テキストの組み合わせが標準化。

例: 「この別表1の写真を読み取り、

  1. OCR

  2. 表形式への再構成

  3. Google Docsに貼り付けやすいMarkdown を順に生成してください。」

⑥ “Mega-Prompt”から“Multi-Step Prompting”へ

検索結果では「マルチステップ化」が重要とされる。

例:

  1. 現行規約の構造分析

  2. 問題点の抽出

  3. 改定案の生成

  4. 総会説明資料の作成 …と段階的に依頼する方が精度が高い。

◆ 5. まとめ:PEP資格の価値は“低下”ではなく“役割が変わった”

あなたが取得した PEP(Prompt Engineering Professional) の価値は、 「旧来のプロンプト技法」だけに依存していた場合は相対的に低下したと言えます。

しかし、検索結果が示す通り:

  • プロンプトエンジニアリングは2026年でも必須スキル

  • ただし内容は「文章の工夫」から「構造設計・コンテキスト管理」へ進化

  • 高度タスクでは依然として成果物の質を大きく左右する

という状況です。

つまり、 PEPの価値は“古い型のプロンプト技法”ではなく、“新しい型のプロンプト設計”を学び続けることで維持・強化される というのが正しい理解です。

◆ 最後に:あなたの文脈での示唆

浮水さんは自治会規約の改定、総会資料作成、住民説明など 「複雑で構造化が必要なタスク」を扱っています。

これはまさに、 現代型プロンプトエンジニアリングが最も威力を発揮する領域 です。

もしご希望であれば、

  • あなたの用途に最適化した「現代型プロンプト設計テンプレート」

  • 規約改定作業に特化した「コンテキスト管理の型」

  • 住民説明資料の自動生成ワークフロー なども作成できます。

どの方向から深掘りしましょうか。

 

うむ。