コンテキストエンジニアリングからコンテキスト・ガバナンスへAIに「何を渡すか」から、「誰がどう渡してよいか」へ

AI活用の主戦場は、うまいプロンプトを書くことから、AIが参照する情報環境そのものを設計することへ移りつつある。本稿はその潮流を「コンテキストエンジニアリング」として概観したうえで、その先に必ず現れる「コンテキスト・ガバナンス」へと議論を進める。鍵は三点――圧縮とは見えにくい権限移譲であること、警戒すべきは漏えいより汚染であること、そして分離は効率と追跡可能性の二つに同時に奉仕すること。派手な神プロンプトより、壊れにくい情報の配管を。それが、AIエージェントを長く安定して動かすための思想である。

目次
序 ― プロンプトから、渡す情報そのものへ　　　3
第1章 コンテキストエンジニアリングとは何か　　5
第2章 四つの手法 ― 書き込み・選択・圧縮・分離　6
第3章 「全部渡せばよい」という誤解　　　　　　7
第4章 コンテキストからガバナンスへ　　　　　　8
第5章 四手法に潜む統治上の失敗モード　　　　　9
第6章 漏えいより汚染 ― egress と ingress　　　　10
第7章 分離の二重の意味 ― 効率と追跡可能性　　　11
第8章 三段の梯子と、非対称な移行コスト　　　　12
補章 統治を実装に落とす ― 決定点と最小の記録　13
結び ― 神プロンプトより、壊れにくい配管を　　14

序 ― プロンプトから、渡す情報そのものへ

生成AIの使いこなしといえば、長らく「プロンプトをどう書くか」が中心だった。AIへの指示文を工夫し、役割を与え、手順を分解し、良い例と悪い例を添える。これは今も有効な技術であり、なくなることはない。しかし、AIの使い方が「一問一答」から「複数ステップの作業をまるごと任せる」形へと重心を移すにつれ、プロンプトだけでは品質が安定しなくなる領域が急速に広がってきた。

その背景にあるのが、AIエージェントや検索拡張生成（RAG）の普及である。会話履歴が積み上がり、外部データが差し込まれ、ツールの実行結果が返ってくる。AIが一度の応答で参照する情報は、もはや一本の指示文ではなく、複数の出所を持つ情報の束になった。この束を何で構成し、何を残し、何を捨て、どの順で渡すか――これを設計する営みが、いつしか「コンテキストエンジニアリング」と呼ばれるようになった。

この呼称の変化は、単なる言い換えではない。設計の対象が「一文」から「情報環境の全体」へと拡張したことを意味している。プロンプトが料理でいう調味料の使い方だとすれば、コンテキストエンジニアリングは、まな板と冷蔵庫と動線を含む厨房そのものの設計に近い。腕のよい料理人でも、散らかった厨房では実力を出せない。

なぜ今この話が要るのか。モデルが賢くなるほど、人はより長く、より複雑な作業を任せたくなる。任せる範囲が広がれば、AIが参照する情報の量と種類は指数的にふくれあがり、その管理は個人の記憶や勘の外に出る。皮肉なことに、モデルの進歩そのものが、渡す情報を設計せよという圧力を強めているのだ。能力の向上は、コンテキスト設計の必要を減らすどころか、むしろ増やしている。

本稿の主張は単純である。コンテキストエンジニアリングは、AI時代の情報整理術というより、運用設計そのものだということ。そして実運用では、その設計は「何を渡すか」だけでは完結せず、「誰に・いつ・どの根拠で・どの版を・どの工程に渡すか」という統治の問題に必然的に接続する。この最後の一段こそが、AIエージェントを安定稼働させる際の本当の勝負どころになる。

あらかじめ、本稿で用いる語を一文で定めておこう。コンテキスト・ガバナンスとは、AIに渡される情報について、その出所・鮮度・権限・版・根拠・監査可能性を管理する設計のことである。この六つの観点を背骨として、以下、見取り図を順に描いていく。