ハクソク

世界を動かす技術を、日本語で。

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

329日前原文(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が人間が解決するのに必要な情報なしで問題を解決することを期待している。

└

はい・いいえの質問をすると、50%の確率で嘘が返ってくるよ。

└

モデルにこの質問をすることで、結構いい結果が出てるよ。モデルに不安なことについて質問させたり、アプリケーションで既に使われているコードパターンの例をテンプレートとして求めるように言ってる。

└

データサイエンティストのコスプレをしてる人たちは評価を求めないんだよね。だから、偽のCレベルプロジェクトでは評価がほとんど見られなかった。人に「皇帝は裸だ」って言ってもお金にはならないから。実際に製品を使ってお金を稼いでる人たちは、評価があるよ。

強力で信頼性のあるAIエージェントを構築することは、魔法のプロンプトやモデルのアップデートを見つけることから、よりコンテキストのエンジニアリングや、適切な情報とツールを、適切な形式で、適切なタイミングで提供することにシフトしています。うん、これは納得できる。 > しかし、「適切な」形式や「適切な」タイミングが本質的に、そして場合によっては必然的に、未定義であるなら、まだ「魔法」の解決策を求めていることにならない？「適切な」情報の定義が「言語モデルから十分に正確な答えを得るための情報」であるなら、プロンプトエンジニアリングとは根本的に何も違わないように思える。これらは非決定的な機械だから、プロンプトで「試してみる」ということと根本的に区別できる信頼できるヒューリスティックが見当たらない。

└

最先端の理論的フレームワークでは、通常、これを二つの異なる探索と発見のフェーズに分ける。最初のフェーズは探索的で、気象拡散装置を利用することを最もよく概念化できる。容易に識別できるマーカー材料、通常はさまざまな糞便が比喩的に高速度で導入される。発見のフェーズは、探索フェーズの拡散パターンを分析することとして概念化される。これら二つのフェーズはそれぞれ、「やってみる」と「見つける」と要約できる。

└

それは魔法のような考え方だね。「プロンプト」でも「コンテキスト」エンジニアリングでも、非決定的な空間で「ハマる」ものを見つけるための同じような試行錯誤なんだ。

└

「正しい」フォーマットと「正しい」タイミングが本質的に、いや、もしかしたら必然的に、定義されていないなら、結局「魔法の」解決策を求めていることにならない？今のところ、AIを正しく使う方法についてのアドバイスの問題点そのものだよね。結局、シャーマンがドラム叩いてるみたいなもんだ :-)

└

それはオーバーフィッティングって呼ばれてるもので、要するにプロンプトエンジニアリングのことだよ。

最近考えていた思考実験の一つは、タスクを定義するために必要な最小限のコンテキスト（LLM、人間、またはそれ以外）についてだった。ソフトウェアの世界では、人間中心のデザインという全くの専門分野があって、タスクのニュアンスを明らかにすることを目指している。素晴らしいデザイナーと一緒に働いたことがあって、彼らはソフトウェア開発にとって非常に価値がある。彼らはジャーニーマップやユーザーストーリーを作成し、要件を集め、豊富なデザインドキュメントを生み出す。私は、そのコンテキストなしで大規模なプロジェクトを成功裏に構築することはできないと思う。たくさんのAIデモを見てきたけど、「TODOアプリを作って」と促して、それが十分なコンテキストだと見なして、出力がニーズに合致していると主張するのはおかしい。適切なコンテキストがなければ、出力が正しいかどうか判断できない。

マジックプロンプトを見つけることは「プロンプトエンジニアリング」じゃなくて、ずっと「コンテキストエンジニアリング」だったんだよね。たくさんの「AIの偽専門家」がそう売り込んでたけど、実際にはよくわかってなかった。RAGは今年発明されたわけじゃないし、埋め込みやベクトルDBA、グラフDBAみたいなエソテリックな知識を使った適切なツールがもっと一般的になってきてる。大手企業がツールを改善して、もっといろんなものが利用できるようになってる。

かなり早い段階からOpenAIのAPIを使い始めたスタートアップにいたんだけど（もう2年近く前かな？）。昔は、素晴らしい結果を得るためにコンテキストをとても控えめに使わなきゃいけなかったから、良いコンテキストを作ることにすごく集中してた。インデックス作成と情報検索がほぼ私たちのコアの焦点だったんだ。今でも、大きなウィンドウがあっても、これが真実だと思う。ほとんどの企業にとっての「堀」は実際にはデータ、データのインデックス作成、データの検索なんだ。データを持っていて、それを使う方法を知っている企業が勝つよ。私のアナロジーはこうだ：> LLMはただのオーブン、幻想的なオーブン。でも、良い製品を作るためには、良い材料を適切な比率で選び、丁寧に準備することが依然として必要なんだ。焼きボタンを押したら、最後にプレゼンテーションやデコレーションで仕上げる必要がある。

この前提が明らかだと思ってたんだけど？質問する時にLLMに関連するコンテンツだけを提供すればいいって、記事やベン図が必要なの？

└

「質問する時にLLMに関連するコンテンツ」って、去年のRAGみたいなもんだよ。今のLLMシステムがどれだけ進化してるか見れば、もっと色々あるってわかるよ。一例を挙げると、Microsoftが今日VS Code Copilot Chatをオープンソースにしたんだ（MITライセンス）。そのプロンプトは、ツールが有効かどうかに基づいて、さまざまなツールの指示とともに動的に組み立てられてるんだよ。https://github.com/microsoft/vscode-copilot-chat/blob/v0.29.... それに、オートコンプリートの情報も豊富に含まれてるしね。https://github.com/microsoft/vscode-copilot-chat/blob/v0.29.... 提供される情報は以下の通りで、参考になる提案をするのに役立つよ：- recently_viewed_code_snippets: 開発者が最近見たコードスニペットで、現在のタスクに関連するコンテキストや例を提供するかもしれない。古いものから新しいものまでリストされてて、編集の差分履歴を理解するための行番号が#|の形式で付いてる。これらは開発者の変更には全く関係ないかもしれない。- current_file_content: 開発者が現在作業しているファイルの内容で、コードの広いコンテキストを提供する。行番号は#|の形式で、編集の差分履歴を理解するのに役立つ。- edit_diff_history: コードに加えられた変更の記録で、コードの進化や開発者の意図を理解するのに役立つ。これらの変更は古いものから最新のものまでリストされてる。古い編集の差分履歴が開発者の変更には全く関係ないこともある。- area_around_code_to_edit: 編集する部分の周りのコードのコンテキスト。- cursor position marked as ${CURSOR_TAG}: 開発者のカーソルが現在どこにあるかを示してて、どの部分のコードに注目してるかを理解するのに重要だよ。

人々が同じ古いことに対して新しい概念を次々と作り出してる気がする。まるで火の周りでドラムを叩きながら踊って、シャーマニックな呪文を叫んでるみたいだね :-)

体験的に言うと、Claudeとちょっと話してから理解を深めて、その後タスクをお願いする方が、いきなり頼むよりもずっと良い結果が出ることが多いんだ。リクエストする前に数分間やり取りすることが多いかな。なんか、ChatGPTやGeminiだとこれがうまくいかない気がする。もしかしたら、o3の使いすぎかな？レイテンシーが会話の雰囲気を壊しちゃうことがあるんだよね。