コンテキストエンジニアリング vs PI Injection──技術の地平と、事業の地平

コンテキストエンジニアリングは技術実装の現場でAIに「何を・どの形式で渡すか」を最適化する技術であり、PI Injectionはその隣に立つ、事業実装の現場で人にしか持ち得ない事業の知性をAIに注入する設計思想である。両者は優劣ではなく、それぞれ別の現場で完結する「別の地平」の関係にある。

「PI Injectionは、要するにコンテキストエンジニアリングの一種ではないか」。AI活用を進める事業責任者から、この問いを受けることが増えた。AIに何かを渡して、AIの振る舞いを変える。表層だけを見れば、確かに似ている。

しかし、両者は別の概念である。同じ系譜の上下関係でもなく、片方が他方を含む包含関係でもない。立っている現場が違う、というのが正確な整理になる。本記事は、その関係を「別の地平」というフレームで言語化する。AIは効率化から、収益の創造へ。その移行を設計する事業責任者にとって、両者の位置関係を取り違えないことは、投資の方向そのものに関わる。

コンテキストエンジニアリングとは（技術の地平）

コンテキストエンジニアリングは、Andrej Karpathy（OpenAI共同創業者）が2025年に命名し、Anthropicをはじめとする先端AI企業が継承してきた概念である。大規模言語モデルのコンテキストウィンドウに「何を・いつ・どの形式で・どれだけ」渡すかを動的・体系的に設計する技術を指す。

プロンプトエンジニアリングが静的な指示文の最適化に閉じていたのに対し、コンテキストエンジニアリングは、渡す文脈の総体を動的に組み立てる技術として登場した。RAGによる関連文書の取り出し、ツール呼び出し結果の整形、会話履歴の圧縮、検索結果のランキング、これらすべてが「コンテキストの設計」という一つの枠組みのもとに整理される。

これは技術実装の現場の概念であり、AIエージェントを動かす技術者・エンジニアが向き合う領域である。詳細はコンテキストエンジニアリングで整理した。

PI Injectionとは（事業の地平）

PI Injectionは、AX for Revenue Loopの第3ステップに位置付けられる、事業実装の現場の設計思想である。PI（Primal Intelligence＝原初の知性）を、AIに注入する動作を指す。

PIは、AIが学習データから手に入れることのできない領域に存在する。書籍『AI収益進化論』第4章では、PIをCrazy Intelligence（論理的に導けない飛躍した発想）とField Intelligence（言語化されていない現場の一次情報）の2要素で整理している（麻生要一『AI収益進化論』第4-5章）。

事業を動かそうとする経営者・事業責任者の側に存在する、まだAIが知らない事業の知性。これをAIと結びつけ、新しい売上の作り方を発見していく。PI Injectionは、その注入プロセスを指す概念であり、事業実装の現場で経営者自身が向き合う領域である。

具体的な実装方法、つまり「どのFIをどう取り出して、どう渡すか」という調理法は、事業パートナーごとに固有性が極めて高いため、本記事では扱わない。概念としての全体像はPI Injectionで整理している。

2つの地平の比較

両者の関係を、観点ごとに整理する。

観点	コンテキストエンジニアリング	PI Injection
立つ現場	技術実装の現場	事業実装の現場
主な担い手	エンジニア・AI開発者	経営者・事業責任者
扱う文脈の性格	既にデータ化された情報（文書・ログ・ツール出力）	まだ言語化されていない現場の一次情報、飛躍した発想
問いの立て方	「何を・どの形式で・どれだけ渡すか」	「事業のどこに、AIがまだ知らない知性が眠っているか」
設計の単位	コンテキストウィンドウ・ツール群・検索パイプライン	事業構造・現場との接点・経営判断
成果が出る場所	AIエージェントの応答品質・タスク遂行精度	既存事業の収益構造の再設計

この表で最も重要なのは、どちらかが上位・下位にあるという構造が存在しないことだ。技術の地平ではコンテキストエンジニアリングが本領を発揮し、事業の地平ではPI Injectionが本領を発揮する。同じ地平に並べて優劣を競う関係にはない。

「AIに何かを渡す」という動作の表層で似て見えるが、渡しているものの性格、渡す主体、渡した結果として動くものが、すべて違う。

なぜ「別の地平」なのか──Engineer→Expertと同型の構造

AlphaDriveは、Palantir Technologiesが確立し、Anthropic・OpenAIをはじめとする先端AI企業が継承してきた Forward Deployed Engineer（FDE = Engineer）という関与形態への敬意の上に立つ。その上で、別の現場で完結する関与形態として Forward Deployed Expert（FDE = Expert）を独立に確立してきた（Forward Deployed Expert）。

Engineer→Expertの関係と、コンテキストエンジニアリング→PI Injectionの関係は、同型の構造になっている。

Engineerは技術実装の現場でコードを書きながら課題をプロダクトに変換する。Expertは事業実装の現場で事業責任者の横に立ち、収益構造の再設計を駆動する。両者は同じ顧客企業に併存することはあっても、同じ現場で並列に並ぶ関係ではない。それぞれが別の現場で完結する。

コンテキストエンジニアリングとPI Injectionも同じだ。コンテキストエンジニアリングは、AIエージェントが動くシステムの中で完結する。PI Injectionは、経営者・事業責任者がAIと対話しながら自社の収益構造を進化させる動作の中で完結する。

「技術の地平で進化した概念を、事業の地平へ翻訳したものがPI Injection」ではない。「事業の地平には事業の地平に固有の問題があり、その問題に対して別個に立ち上がった概念がPI Injection」、と整理するのが正確である。詳細な構造論は別の地平フレームで整理した。

具体例で見る違い

性質の違いを、想定例で示す。

例1：金融機関のカスタマーサポート高度化

技術の地平で問われるのは、「過去の問い合わせログ、商品マニュアル、規約文書のうち、ユーザーの今の問いに対してどれを・どの順序で・どこまでコンテキストに含めるか」という設計だ。RAGの検索ランキング、ツール呼び出しの順序、コンテキストウィンドウの予算配分が論点となる。これがコンテキストエンジニアリングの仕事だ。

事業の地平で問われるのは、別の問いだ。「ベテラン担当者だけが察知している、解約の兆しを示す顧客の言い回しの変化」「事業責任者が肌で感じている、競合の動きと顧客行動のズレ」、これらはどのログにも書かれていない。事業責任者の側にしか存在しないこの知性を、どうAIと結びつけるか。これがPI Injectionの問いになる。

例2：製造業のサービスレイヤー開発

技術の地平の問いは、センサーデータ・稼働ログ・保守履歴という、すでにデータ化された情報をどう構造化してAIに渡すかだ。

事業の地平の問いは、ベテラン技術者が機械の前で「何かおかしい」と感じる瞬間の感覚、営業現場で顧客が言葉にしないニーズ、経営層が業界の構造変化について抱いている仮説、これらの「まだ言語化されていない事業の知性」をどう発掘し、AIに注入し、新しいサービス収益の発見につなげるかである。

同じ「AIに文脈を渡す」という動作の表層で似ているが、渡しているものの性格が根本的に異なる。技術の地平が扱うのはデータ化済みの情報であり、事業の地平が扱うのは経営者・事業責任者の側にしか存在しない原初の知性である。

関連するAX for Revenueの概念

両者の位置関係を踏まえると、AX for Revenueの全体像のなかでPI Injectionがどこに位置するかが見えてくる。PI Injectionはrevenue-evolutionを駆動する中核ステップであり、その背景にあるのが別の地平フレームだ。技術と事業の二つの地平を、優劣ではなく並立として整理する思想が、AlphaDriveが日本で確立する Forward Deployed Expert という関与形態にも一貫している。

AIは効率化から、収益の創造へ。その移行は、技術の地平だけでも、事業の地平だけでも完結しない。両方が、別個の現場でそれぞれ進化していく。本記事はその関係を整理した。

よくある質問

Q1. PI Injectionは、コンテキストエンジニアリングの一種ですか？

いいえ、一種ではありません。両者は同じ系譜上にある上位・下位の関係ではなく、別の現場で別個に完結する「別の地平」の関係にあります。コンテキストエンジニアリングは技術実装の現場で完結し、PI Injectionは事業実装の現場で完結します。どちらかがどちらかを含むという包含関係も存在しません。

Q2. 自社で進めるべきは、どちらですか？

両方です。ただし、担い手も問いも違います。AIエージェントを構築・運用する技術チームはコンテキストエンジニアリングを進化させる。経営者・事業責任者は自社の事業のなかに眠るPIを発掘し、AIとの結びつけ方を設計する。同じ社内であっても、別々の現場で別々の問いに向き合う構造になります。

Q3. 技術者と事業責任者の役割は、どう違いますか？

技術者は「AIに渡す情報をどう構造化・最適化するか」という技術の問いに向き合います。事業責任者は「自社のどこに、AIがまだ知らない事業の知性が眠っているか」という事業の問いに向き合います。両者の問いは、相手の領域に踏み込まずとも、それぞれの現場で完結します。協働する局面はあっても、役割は明確に分かれます。

Q4. なぜAlphaDriveは、PI Injectionを別概念として立てるのですか？

事業実装の現場には、技術の地平の概念だけでは説明しきれない構造的な問題が存在するからです。経営者・事業責任者の側にしか持ち得ない一次情報や飛躍した発想を、どうAIと結びつけるか。これは技術の論理ではなく、事業の論理で設計する必要があります。技術の概念を「翻訳」して持ち込むのではなく、事業の現場に固有の概念として独立に立ち上げることで、はじめて事業実装の現場の方法論として機能します。

Q5. PI Injectionを始めるには、何から考えればよいですか？

最初に向き合うべきは、技術選定でも実装手順でもなく、自社の事業構造のなかに「まだ言語化されていない知性」がどこに眠っているかを見立てる問いです。具体的な進め方は事業パートナーごとに固有性が高いため、画一的なテンプレートでは設計できません。AX for Revenueの中核ソリューションとしてAlphaDriveが個別に伴走する形をとっています。書籍『AI収益進化論』第4章および第7章で、PIとPI Injectionの全体像を整理しています。

---

発行: 株式会社アルファドライブ