AIにおける新しいスキルはプロンプト作成ではなく、コンテキストエンジニアリングです

2025年7月1日原文(philschmid.de)

概要

Context Engineering はAI分野で注目される新しい概念
Prompt Engineering からより広範な文脈設計へと進化
AIエージェントの成否は 文脈の質 に大きく依存
文脈は単なるプロンプトではなく、複数の情報源の統合体
適切な情報・ツール を適時提供する設計が鍵

Context Engineeringとは何か

Context Engineering は、AIエージェントに最適な文脈を設計・提供する技術
Tobi Lutkeは「タスクをLLMで解けるよう、全ての文脈を与える技術」と定義
エージェントの成功要因はモデル精度ではなく、 文脈の質
多くの失敗はモデル由来ではなく、 文脈設計の失敗

文脈（Context）の定義拡張

文脈は単なる プロンプト ではなく、モデルが応答生成前に参照する全情報
- Instructions / System Prompt ：会話開始時のルールや例示
- User Prompt ：ユーザーからの直近の質問や依頼
- State / History（短期記憶） ：直前までの会話履歴
- Long-Term Memory（長期記憶） ：ユーザーの好みや過去のプロジェクト要約等、持続的知識
- Retrieved Information（RAG） ：外部データベースやAPIから取得した最新情報
- Available Tools ：利用可能な関数やツール（例：check_inventory, send_email）
- Structured Output ：応答フォーマット（例：JSON）

文脈設計の重要性

AIエージェントの価値 はコードやフレームワークよりも、文脈設計に依存
安価なデモと「魔法のような」プロダクトの差は 文脈の質
- デモレベル：ユーザーの依頼のみ参照、出力が機械的
- 優れたエージェント：カレンダー情報、過去のメール、連絡先、利用可能ツール等を統合
適切な文脈提供により、 自然で有益な応答 が可能

Context Engineeringの実践

Prompt Engineering は単一テキストの工夫に留まる
Context Engineering は、動的に情報・ツールを統合するシステム設計
- システムとしての文脈 ：静的なテンプレートではなく、LLM呼び出し前に構築される動的文脈
- 動的生成 ：リクエスト毎に必要な情報・ツールを選択
- 適切な情報・形式 ：冗長なデータではなく、要点をまとめて明確な形式で提示
「Garbage In, Garbage Out」を防ぐため、 必要な知識と機能を適切なタイミングで提供

まとめ

強力かつ信頼性の高いAIエージェント構築は、「魔法のプロンプト」やモデル更新ではなく Context Engineering が要
ビジネスケースの理解、出力定義、必要情報の構造化が成功の鍵
LLMがタスクを達成できるよう、 最適な文脈設計 が求められる

参考資料

Tobi Lutke tweet
Karpathy tweet
The rise of "context engineering"
Own your context window
context engineering by Simon Willison
Context Engineering for Agents

Hackerたちの意見

結論として、強力で信頼性のあるAIエージェントを構築することは、魔法のプロンプトやモデルのアップデートを見つけることから、よりコンテキストのエンジニアリングや、適切な情報とツールを、適切な形式で、適切なタイミングで提供することにシフトしています。これは、ビジネスのユースケースを理解し、出力を定義し、LLMが「タスクを達成できるように」必要な情報を構造化するという、横断的な課題です。実際、人間にも当てはまります。提供するコンテキスト（つまり、適切なタイミングでの正しい情報）が多ければ多いほど、タスクを解決するのに役立ちます。

└

そうだね… UXやプロダクトの人たちにモックアップ、要件、受け入れ基準、サンプルの入力と出力、なぜこの機能が重要なのか、などを常に頼んでる。私たちがあなたの脳をスキャンして本当に欲しいものを理解できるようになるまで、実際に何を作りたいのかを説明する必要があるし、ただの雰囲気に頼るわけにはいかないよね。

└

「もっと」コンテキストじゃなくて、「より良い」コンテキストだよ。（X-Y問題の例みたいにね。）

└

機械学習の側面を人間と表面的に比較するこのバナールなトレンドは好きじゃない。全然洞察を与えないし、ほとんど正確じゃないから。

└

基本的には、環境の制約の中で押すべきボタンを見つけること。結果が非決定的なだけで、（ソフトウェア）エンジニアリングとあまり変わらないよ。

ちょっと前にこのことについて書いたよ: https://simonwillison.net/2025/Jun/27/context-engineering/ ドリュー・ブロイニグは、このテーマについて素晴らしい記事を書いてるんだ。偶然にも「コンテキストエンジニアリング」という流行語が出てきた時期と重なってるけど、実際にはそのミームとは関係ないよ。「長いコンテキストが失敗する理由」 - https://www.dbreunig.com/2025/06/22/how-contexts-fail-and-ho... では、長いコンテキストが問題を引き起こすさまざまな方法について話してる（「コンテキストロット」とも呼ばれる）。「コンテキストを修正する方法」 - https://www.dbreunig.com/2025/06/26/how-to-fix-your-context.... では、ツールのロードアウト、コンテキストの隔離、コンテキストの剪定、コンテキストの要約、コンテキストのオフロードなど、これらの問題を回避するためのテクニックに名前を付けてるよ。

└

ドリュー・ブロイニグの投稿は必読だよ。自分のエージェントを書くためだけでなく、今エージェントコーディングを使う際にも重要だ。これらの制限や振る舞いは、しばらく私たちと共にあるだろう。

└

これらの問題は、学術界では現在のLLMのアーティファクトと見なされている。すでに、LLMが同時に数百万の異なるツールを使えるようにする研究が進んでいて、安定した長いコンテキストも実現されつつある。これにより、異なるプロバイダーとインターフェースを取る以外のほとんどのユースケースでは、エージェントの数が一つに減る可能性が高い。現在のLLMに基づいて将来のエージェントシステムを構築しようとしている人は、LangChainの運命に直面することになるだろう - GPT-3用に作られたものが、GPT-3.5によって時代遅れになる。

└

まず、人間のアーティストに自転車に乗ったペリカンを描いてもらう。次に、それを「コンテキスト」として提供する。そして、モデルにプロンプトを与える。はい、できた！

└

誰が最初のロジックコアを開発して、コンテキストエンジニアを自動化するんだろう。

└

「1ヶ月のスキル」って、他の多くのものと同じように、その後は存在しなくなるんだろうね。

確かに、私の経験と一致してる。モデルにコンテキストを提供する際に使うヒューリスティックの一つは、「これは人間がこのタスクを解決するのに十分な情報か？」ってこと。過去にいくつかのテキスト2SQL製品を作った時、モデルが失敗した時に、実際のデータアナリストが「そうそう、それはもう使ってない古いテーブルだよ。正しいテーブルは...」って返事することが多かったのが興味深かった。つまり、モデルは実際の人間のアナリストが適切なコンテキストなしに犯すような間違いをしていたってことだ。このリストに欠けているのは「評価」だね！大規模なAIプロジェクトが評価なしで進められるのを見て驚いてる。評価はAIプロジェクトにとって、従来のエンジニアリングプロジェクトのテストスイートよりも重要だよ。大きな評価セットは必要ないけど、自分の問題領域を適切にカバーするものがあればいい。評価なしでは、基本的に「推測」しているだけで、問題に対して反復しているわけじゃないし、各推測が前のものより改善されているわけでもない。編集: 明確にするために、私は自分自身にこの質問をする。しばしば、私たちはLLMが人間が解決するのに必要な情報なしで問題を解決することを期待している。

Hacker Newsで議論の続きを見る

ハクソク