プロンプト／コンテキスト／PI──AIに「何を渡すか」の3つの設計はどう違うのか

AIに「何を渡すか」の設計には3つある。プロンプトエンジニアリング（指示文の最適化）とコンテキストエンジニアリング（文脈の総体の動的設計）は技術実装の地平にあり、後者が前者を内包する。PI Injection（事業の文脈の注入）はそれらとは別の地平＝事業実装の現場にあり、技術2層とは内包関係になく並び立つ。

「AIに何を渡すか」をめぐって、近年3つの設計概念が語られる。プロンプトエンジニアリング、コンテキストエンジニアリング、そしてAX for Revenueが提示するPI Injectionである。これらは現場でしばしば混同される。3段階のレベルアップとして並べられたり、PIを「最上位の概念」として描かれたりする。

しかし、その整理は構造を取り違えている。本記事は3つの設計を1枚の地図として体系化し、それぞれが立つ地平の違いを明示する。

3つの設計の全体地図

まず全体像を提示する。

技術実装の地平には2つの設計がある。プロンプトエンジニアリング（指示文そのものの最適化）と、コンテキストエンジニアリング（指示文を含む文脈の総体を動的に設計する技術）である。両者の関係は「静的な指示文の最適化」から「文脈総体の動的設計」への発展であり、後者が前者を内包する。コンテキストエンジニアリングはプロンプトエンジニアリングを次の段階へ拡張したものとして位置付けられる。

一方、事業実装の地平にはPI Injectionがある。AIが学習データから得られない事業固有の文脈──現場の暗黙知や非連続な発想──をAIに注ぎ込む設計思想である。これは技術2層の延長線上にはない。同じ「AIに何を渡すか」という問いを扱いながらも、立っている現場そのものが異なる。

つまり、3つの設計は「①→②→③とレベルアップする3段階」ではない。技術の地平に①②の段階関係があり、その隣に③が別の地平として立つ。「2層＋別の地平」という構造が、3つの正しい関係である。

①プロンプトエンジニアリング（技術の地平・基礎層）

プロンプトエンジニアリングは、大規模言語モデルに与える指示文を工夫し、望む出力を引き出す技術である。役割設定、例示の提示、段階的推論の指定、出力フォーマットの規定など、静的な指示文の最適化を中心とする。

学術的には2024〜2025年にかけて41種類の技法が体系化されており、Chain-of-Thought、Few-shot、Self-Consistency、Tree-of-Thoughtsなどがその代表例である（Indian Institute of Technology Patna / Stanford University / Amazon AI, 2025）。感情刺激を付与するEmotionPromptの研究では、Instruction Inductionタスクで相対8.00%、BIG-Benchで115%の性能向上が報告されている（Microsoft Research, 2023）。

この層の主役は「指示文そのものをどう書くか」である。詳細はプロンプトエンジニアリングを参照されたい。

②コンテキストエンジニアリング（技術の地平・発展層）

コンテキストエンジニアリングは、Andrej Karpathyが2025年に命名しAnthropicらが継承した概念で、コンテキストウィンドウに「何を・いつ・どの形式で・どれだけ」渡すかを動的・体系的に設計する技術である。

①が静的な指示文の最適化であったのに対し、②は指示文を含む文脈の総体を扱う。検索拡張生成における外部情報の選定、過去のやり取りの取捨選択、ツール呼び出しの結果の組み込み方、トークン制約下での情報優先順位付けなど、設計の対象が大きく広がる。

重要なのは、②が①を内包することである。コンテキストエンジニアリングの内部に、プロンプトの最適化という工程が含まれる。両者は技術の地平の内側で「基礎層」と「発展層」の関係にあり、後者が前者を次の段階へ拡張した位置に立つ。詳細はコンテキストエンジニアリングを参照されたい。

③PI Injection（事業の地平・別の地平）

PI Injectionは、AIが学習できる範囲の外側にある事業固有の知性──Primal Intelligence、略してPI──をAIに注ぎ込む設計思想である。PIは2つの要素で構成される。論理的に導出できない内発的な飛躍であるCrazy Intelligenceと、まだ言語化されていない現場の情報であるField Intelligenceである（麻生要一『AI収益進化論』第4章）。

①②が「技術実装の現場で、AIに渡すコンテキストをどう最適化するか」という問いを扱うのに対し、③は「事業実装の現場で、自社の事業固有の文脈をAIにどう注ぎ込み、まだ存在しない売上の作り方を発見するか」という問いを扱う。

両者の現場は異なる。技術の現場では、エンジニアが汎用的に有効なコンテキストの設計手法を磨く。事業の現場では、経営者と事業責任者が自社の現場に降りて、見過ごされてきたCrazyとFieldを選び取り、AIに注ぎ込む。書籍は「AI Mutationの核心は、経営者自身が現場に降りて、Crazy と Field を選び取り、AI に注ぎ込む作業」と整理する（麻生要一『AI収益進化論』第6-7章）。

③は概念的に①②を「内包する」のでも、「上位互換」でもない。別の地平で完結する別の設計である。詳細はPI Injectionを参照されたい。

なぜ「3段階」ではなく「2層＋別の地平」なのか

3つを単純な階段として描く整理がしばしば見られる。プロンプトエンジニアリングを初歩、コンテキストエンジニアリングを中級、PI Injectionを上級、という具合に。

この整理は構造を取り違えている。

①と②の関係は、たしかに技術の地平の内側における段階関係である。文脈の総体を扱う②は、指示文だけを扱う①を内包し、次の発展段階に位置する。ここまでは段階関係として整理してよい。

しかし、②と③の関係は段階関係ではない。両者は別の現場で完結する別の地平にある。技術実装の現場で②を極めても、事業実装の現場における③に自動的に到達するわけではない。逆も同じで、③の設計思想を持っていても、②の技術的な設計知が自動で得られるわけではない。立っている現場が違うからである。

AlphaDriveはこの構造を「別の地平フレーム」として整理している。技術実装の地平が切り拓いてきた①②への敬意を保ちながら、その隣に事業実装の地平を独立した別の地平として立てる構造論である。詳細は別の地平フレームを参照されたい。

この「地平の違い」を見落とすと、PI Injectionを②の上位互換と誤認したり、逆に技術側の設計知だけで事業の文脈設計まで届くと誤算したりする失敗が起きる。3つを正しく地図化するための核は、技術2層の段階関係と、事業1層の別地平性を、混同せず区別することにある。

実務でどう使い分けるか

3つの設計はそれぞれ別の現場で機能する。優劣ではなく、役割分担である。

技術実装の現場では、①②が主役になる。プロダクトに組み込まれるAI機能の精度を上げたいとき、エージェントが扱うツールや情報源を設計したいとき、トークン制約下での出力品質を高めたいときは、コンテキストエンジニアリングが扱う対象になる。その内部で個別のプロンプトを磨くのが①の仕事である。担い手はエンジニア、AIプロダクトの設計者、技術リーダーである。

事業実装の現場では、③が主役になる。AIを既存業務に入れたが売上の作り方そのものが変わらない、効率化の延長線では伸びない、という壁に当たったとき、扱うのは事業の文脈の側である。自社の現場にしか存在しないField Intelligence、業界の常識からの逸脱を引き起こすCrazy Intelligence──これらをAIに注ぎ込む設計が問われる。担い手は経営者、事業責任者、AXアーキテクトである。

つまり、3つの設計はどれが上というものではなく、それぞれの現場で完結する。経営者が①②の技法をすべて自分で書けるようになる必要はない。エンジニアが③の事業文脈の選定を一人で担う必要もない。役割が違い、地平が違うからこそ、それぞれの現場の担い手が連携することで全体が機能する。

AI Transformationが「AIで売上を作り変える」段階まで到達するためには、技術の地平で①②を整え、事業の地平で③を回す──両方の現場が並走する設計が必要である。AIは効率化から、収益の創造へ。3つの設計を正しく地図化することは、その出発点になる。

よくある質問

Q1. 3つは順番に学ぶべきものですか？

技術の地平の内側にいる方──エンジニア・AIプロダクト設計者──にとっては、①プロンプトエンジニアリングを基礎として身につけたうえで、②コンテキストエンジニアリングへ発展させる順序が自然です。①は②に内包されるため、段階的な習熟が成立します。

しかし、③PI Injectionは①②の次の段階としては位置付けられません。立っている地平が異なるため、技術2層を極めれば自動的に③へ到達するわけではありません。事業実装の現場に立つ経営者・事業責任者は、③を独立した設計領域として扱う必要があります。

Q2. PI Injectionは3つの中で一番高度なものですか？

高度さの順位ではなく、地平が異なる、という整理が正確です。

①②は技術実装の現場で力を発揮する設計、③は事業実装の現場で力を発揮する設計です。それぞれの現場で完結し、相互に上下の関係にはありません。「PIが最上位」「コンテキストエンジニアリングが上級」といった階段状の整理は、構造を取り違えています。

Q3. コンテキストエンジニアリングとPI Injectionの違いは何ですか？

両者はどちらも「AIに渡す文脈を設計する」という形をとりますが、扱う文脈の性格と立っている地平が異なります。

コンテキストエンジニアリングが扱うのは技術的に最適化可能な文脈の総体──情報源の選定、過去履歴の取捨選択、ツール出力の組み込み方など──です。担い手はエンジニアで、現場は技術実装の側です。

PI Injectionが扱うのは事業固有の文脈──現場でしか得られないField Intelligenceや、業界常識から逸脱するCrazy Intelligence──です。担い手は経営者・事業責任者で、現場は事業実装の側です。両者は別の地平で並び立つ設計です。

Q4. 技術者と事業責任者で関わる層が違うのですか？

主に関わる層は異なります。エンジニアは技術の地平にある①②を主戦場とし、経営者・事業責任者は事業の地平にある③を主戦場とします。

ただし、これは完全な分業ではありません。事業責任者が①②の概念を理解しておくことは、技術側との対話の質を上げます。エンジニアが③の存在を理解しておくことは、事業側からの依頼の意図を取り違えないために役立ちます。3つの全体地図を共有することが、両者の連携の前提になります。

Q5. 3つ全部やる必要がありますか？

何を目指すかによります。

技術実装の現場でAIプロダクトの品質を上げることが目的なら、①②の習熟が中心になります。事業の収益構造そのものを変えたいなら、③が必須になります。

AX for Revenueの方法論が目指すのは後者──AIで既存の収益構造を再設計することです。そのためには③の設計思想が中核に置かれ、技術の地平の①②はそれを支える基盤として連携します。

関連するAX for Revenueの概念

3つの設計の全体地図と、各設計の詳細は以下を参照してください。

• プロンプトエンジニアリング｜①プロンプトエンジニアリングの詳細
• コンテキストエンジニアリング｜②コンテキストエンジニアリングの詳細
• PI Injection｜③PI Injectionの詳細
• 別の地平フレーム｜「2層＋別の地平」を支える構造論
• /blog/ai-transformation-for-revenue｜AX for Revenueの実装ハブ
• /book｜書籍『AI収益進化論』（思想の原典）

---

発行：株式会社アルファドライブ 編集：AX for Revenue Institute 編集部