「あなたはプロのマーケターです」「あなたは優秀な営業担当者です」。こうした「役割付与」プロンプトを今でも使っているなら、2022〜2023年の知識を使い続けていることになる。ハッシンラボの2026年調査では、最新モデルにおいて役割付与の効果は限定的で、出力を歪めるケースまで報告されている。
それでも、ChatGPTへの期待が外れる問題は役割付与のせいではない。根本的な問題は、AIを「検索エンジン」のように使っていることだ。キーワードを打ち込む感覚でAIに指示を出している限り、期待通りの回答は返ってこない。
この記事では、2026年現在の実務で機能するプロンプト設計の考え方と、具体的な10の原則を紹介する。「プロンプトの書き方を工夫する」という発想から、「AIが判断するために必要な文脈を設計する」という発想への転換が、今まさに求められている。
なぜAIへの期待が外れるのか — 検索エンジンとして使う罠
「メール書いて」「議事録まとめて」という指示だけを入力して、修正に追われた経験はないだろうか。これは、AIが無能なのではなく、指示が不完全だからだ。
Googleの検索と根本的に違う点がある。Googleは「メール」と打てば過去の検索履歴や文脈から補完してくれる。AIは違う。毎回ゼロから判断する。「メール書いて」という指示を受けたAIには、相手が誰か、件名は何か、文体は丁寧か簡潔か、何行以内か。これらが何もわからない状態だ。わからないなら、AIは補完するしかない。その補完が期待と外れたとき、「AIは使えない」という評価になる。
SQ Magazineの2026年調査によれば、適切なプロンプト設計により40%のコスト削減と3倍の生産性向上を達成した企業がある一方、同じツールを使って「効果がなかった」と評価した企業との差は、指示の設計にあった。
2026年の新常識 — 役割付与からコンテキスト設計へ
業界では2026年から「プロンプトエンジニアリング」という呼び方が「コンテキストエンジニアリング」に置き換わりつつある。IBMは同年の公式ガイドでこの転換を明示し、SDG Groupは企業コンサルティングの現場でこのフレームを採用している。
違いを一言で言えば、「プロンプトエンジニアリング」は入力文を工夫することで、「コンテキストエンジニアリング」はAIが毎回の推論で参照する情報全体を設計することだ。システムプロンプト、ユーザー入力、参照文書、会話履歴、ツール定義—これらすべての「文脈の束」を設計する行為がコンテキストエンジニアリングだ。
個人がプロンプトを毎回手で書き直す時代は終わりつつある。チームで共有できるプロンプトライブラリと、業務フローに組み込まれた文脈設計の仕組みが、AI活用の成否を分けるようになっている。
図1: プロンプト設計の潮流変化。個人のテクニックから組織の仕組みへ
AIに使える仕事をさせる10の原則
以下の10原則は、IBM、SDG Group、各種研究の知見と、Lat91が自社の10体のAIエージェントシステムを構築・運用する中で確認したことをまとめたものだ。
原則1：目的を一文で書く。「〜を書いて」ではなく「〜の目的で〜を書いて」に変える。「社内向けに新機能のメールを書いて」より「エンジニア以外のメンバー全員が理解できるよう、新機能のメリットを3点で伝える社内メールを書いて」の方が、はるかに使える回答が出る。
原則2：対象読者を明示する。「専門家向け」「AIを知らない50代経営者向け」では、出力の抽象度がまったく変わる。読者の属性（職種、知識レベル、何を知りたいか）を具体的に書く。
原則3：出力形式を指定する。「箇条書きで3点」「200文字以内で」「表形式で比較して」のように、形式と分量を指定する。形式が曖昧なままでは、何度やり直しても同じ問題が繰り返される。
原則4：Chain-of-Thought（CoT）を使う。複雑な判断や計算を伴う場合、「ステップバイステップで考えてください」の一行を加える。adaline.aiの2025年研究では、この一行だけで算数の正答率が17.7%から40.7%に向上し、推論ベンチマークで30〜50%の改善が確認されている。
原則5：例を1〜3件見せる（Few-Shot）。「こういう形式で書いてほしい」という例を事前に見せる。社内で使っているメールのトーン、提案書のフォーマット—これをそのまま見せるだけで、出力が社内スタイルに近づく。
原則6：制約を書く。「〜は含めないで」「〜という表現は避けて」「専門用語は使わないで」のように、してはいけないことを明示する。AIは制約がなければ、考えられる選択肢を広く出そうとする。
原則7：背景情報を渡す。自社の事業内容、プロジェクトの経緯、過去のやり取りの要旨—AIはこれを知らなければ一般論しか出せない。必要な文脈を「Background:」として渡す癖をつける。
原則8：Chain of Draft（CoD）でトークンを節約する。2025年に登場したCoD（Chain of Draft）は、CoTと同精度を保ちながらトークン消費を大幅に削減する手法だ。「まず箇条書きで下書きを作り、その後で文章化して」という指示がCoD的な発想に近い。API利用コストが気になる場合に有効だ。
原則9：出力の評価基準を伝える。「読んだ人が行動したくなるかどうかで評価するので、そのつもりで書いて」「後任が読んで迷わない手順書を書いて」のように、成功の定義を伝える。AIは評価基準を知ると、それに向けて最適化する。
原則10：ライブラリ化して共有する。効果的なプロンプトを個人のメモで終わらせない。Notionやドライブに「プロンプトライブラリ」を作り、チームで更新し続ける。これが個人スキルを組織の資産に変える唯一の方法だ。
ビフォー・アフターで見る効果の差
実際の効果を確認するために、日本の業務現場でよくある例を見てみる。
商談後のフォローメール作成の例:
Before（検索エンジン的な使い方）：「フォローメールを書いて」
→ AIが出すのは汎用的な「本日はお時間をいただきありがとうございました」メールで、即使えない。
After（コンテキスト設計）：「今日の商談の状況：製造業・従業員80名の購買担当者との初回面談。先方の課題：受注管理のExcel手作業が月40時間かかっている。Lat91のサービスへの関心：高め。次のアクション：来週デモ実施予定。この文脈で、先方が『会ってよかった』と感じるフォローメールを、200文字以内で書いて」
→ そのまま送れるレベルのメールが出てくる確率が劇的に上がる。
この差は、プロンプトの「うまさ」ではない。AIに渡す文脈の量と質の差だ。
チームでプロンプトライブラリを作る3ステップ
個人が効果的なプロンプトを持っていても、退職した瞬間にノウハウが消える。組織としてのAI活用能力を高めるには、ライブラリ化が不可欠だ。
ステップ1は「業務別に分類する」こと。営業メール、議事録まとめ、提案書の骨子作成、競合調査—業務ごとにフォルダを作る。ステップ2は「テンプレートとサンプル出力をセットで保存する」こと。プロンプトだけでは再現性が低い。「こういう指示を入れると、こういう出力が出た」という実例をセットにする。ステップ3は「月1回改善セッションを設ける」こと。使ってみてうまくいかなかったプロンプトを持ち寄り、チームで改善する。これをやっているかどうかが、AI活用の成熟度を分ける。
「モデルが賢くなれば、プロンプトは不要になる」への答え
この反論は一部正しい。2023〜2024年に有効だったテクニックの多くは、2026年の高性能モデルでは効果が薄れている。役割付与がその典型だ。
しかし、コンテキスト設計の重要性は逆に高まっている。モデルが賢くなるほど、「何を見せるか」の設計がより重要になる。どれほど賢いモデルでも、見ていない文脈で推論することはできない。業務の背景、対象読者の属性、成功の定義—これらをAIに渡す仕組みは、モデルの進化では代替できない。
変わるのは個別テクニックで、変わらないのは「文脈を設計する」という本質的な行為だ。
まとめ
- 役割付与（「あなたはプロです」）は2026年時点で効果が限定的。最新モデルでは逆効果になるケースも
- 業界の潮流は「プロンプトエンジニアリング」から「コンテキストエンジニアリング」へ移行している
- 適切な文脈設計により40%のコスト削減・3倍の生産性向上が実現できる（SQ Magazine 2026）
- 10の原則の核心は「AIに必要な文脈をすべて渡す」こと。検索エンジン的な使い方からの脱却
- チームで効果を出すには、個人のノウハウをプロンプトライブラリとして組織資産に変える仕組みが不可欠
月曜日からすぐできることを一つ挙げるなら、「出力に困ったとき、次の情報を追記してみる」だ。目的・対象読者・出力形式・制約・背景情報—この5項目を意識してプロンプトを書くだけで、使える回答の割合が変わる。
Lat91では、AIエージェントの設計と社内AI活用の仕組み化を支援しています。
「どこから始めればいいかわからない」「チームへの展開方法を相談したい」という方は、まず無料相談からお気軽にどうぞ。