AIは「呪文（プロンプト）」より「文脈（コンテキスト）」で動くのか？ 〜プロンプト幻想の終わりとコンテキストエンジニアリングの深淵という名の檻 #七01
AIは「呪文」より「文脈」で動くのか？ 〜プロンプト幻想の終わりとコンテキストという名の檻〜 #AI #コンテキストエンジニアリング
期待外れのAI、その真犯人はモデル性能ではなかった？ 新たな常識、コンテキストエンジニアリングの深淵に迫ります。
目次
本書の目的と構成
近年、AI、特に大規模言語モデル（LLM）やそれを活用したAIエージェントの進化が目覚ましいです。まるで魔法のように、AIが言葉を理解し、様々なタスクをこなす時代が到来したかに見えます。しかし、その華やかな側面の裏で、多くのAIシステムが期待通りの性能を発揮できなかったり、奇妙な振る舞いをしたりする現実に直面しています。
本書は、そうしたAIの「失敗」の多くが、AIモデル自体の限界ではなく、AIに与えられる「コンテキスト」の問題に起因している、という衝撃的な（そして、ある意味で当然の）真実を提示した、ある論文（「AI の新しいスキルは促進されるものではなく、コンテキスト エンジニアリングです」）を糸口に、AI開発の新たなフロンティアである「コンテキストエンジニアリング」について、ニヒルかつシニカルな視点から掘り下げていくことを目的としています。
本書は以下の構成で進めます。まず第一部では、これまでAI開発の主流であったかのような「プロンプト至上主義」の幻想を打ち砕き、AIの失敗の真犯人、そして「魔法」のカラクリを暴きます。第二部では、AIを操る新たな技術「コンテキストエンジニアリング」の概念、構成要素、そしてそれが抱える難題を詳細に解説します。巻末資料では、関連情報や、本書では語りきれなかった（あるいは敢えて語らなかった）補足的な内容を詰め込みました。
AIの可能性に魅せられつつも、どこか割り切れない思いを抱えているあなたに、現実（コンテキスト）という名のAIの檻から、少しだけ外を覗く機会を提供できれば幸いです。
要約 - 結局、AIは「文脈」でしかない
本論文は、AIエージェントの成功はモデル性能よりも、応答生成前に与えられる「コンテキスト」の質に依存すると主張します。コンテキストとは、指示、会話履歴、外部情報、ツールなど、AIが参照する全ての情報です。質の低いコンテキストはAIを「安いデモ」にし、質の高いコンテキストは「魔法」のように見せます。これは静的なプロンプトではなく、タスクに応じた動的な情報提供システム設計であり、「コンテキストエンジニアリング」という新たな分野の重要性を説いています。
第一部：プロンプト至上主義という過ち
Generated code1章：かつて私たちは「呪文」を信じた
大規模言語モデル（LLM）が登場し、「プロンプト」と呼ばれるテキストを入力するだけで、AIがまるで人間の書いたような文章を生成したり、質問に答えたりする様子を見たとき、私たちはその能力に驚嘆しました。そして、より良い応答を得るためには、いかにAIに理解しやすい「呪文」を唱えるか、つまり「プロンプトエンジニアリング」が重要だと信じ込みました。特定のキーワードを盛り込んだり、役割を与えたり、 Few-shot learning（いくつかの例を示すこと）で学習を促したりと、様々なテクニックが編み出され、共有されました。
あたかも、AIという強大な精霊に対して、適切な言葉を見つけさえすれば、どんな願いも叶えてくれるかのように。多くの人々が、完璧なプロンプトこそがAIの能力を最大限に引き出す鍵だと考え、その探求に没頭しました。それはある種の熱狂であり、まるで古代の魔術師が失われた呪文書を探し求めるような情熱がそこにありました。
しかし、現実はどうでしょう。特定のタスクでは驚くべき成果を出す一方で、少し条件を変えたり、複雑な状況に対応させようとすると、AIは途端に的外れな応答を返したり、事実に基づかない情報を生成したりします。どんなにプロンプトを工夫しても、どうしてもうまくいかないケースに直面した経験は、多くのAIユーザーや開発者にあるのではないでしょうか。それは、私たちが信じていた「呪文」だけでは、AIの振る舞いを完全に制御できないことを示唆していました。
この章では、プロンプトエンジニアリングが確かに有用な技術であることは認めつつも、それがAIを操るための唯一、あるいは万能な手段ではないという現実を突きつけます。私たちが抱いていた「プロンプト至上主義」という幻想は、AIシステムの複雑さを前に、脆くも崩れ去る運命にあったのかもしれません。
コラム：初めてのAIとの対話
私が初めて本格的にLLMに触れたのは、数年前のことでした。簡単な質問応答や文章生成を試してみて、その滑らかな日本語に感動したものです。よし、これで仕事が楽になるぞ！と意気込んで、少し複雑な依頼をしてみました。例えば、「この長い会議の議事録を要約して、次のアクションアイテムをリストアップして、関係者に送るメールのドラフトも作って」といった具合です。完璧なプロンプトを考えたつもりでした。
結果？ 要約はまあまあでしたが、アクションアイテムはズレていて、メールのドラフトはまるで意味不明でした。「あれ？ こんなもんか？」と肩を落としたのを覚えています。当時はモデルの性能が悪いんだと思っていましたが、今思えば、それは議事録という「コンテキスト」をAIに適切に与えられていなかったことが原因だったのかもしれませんね。プロンプトだけではどうにもならない壁にぶつかった、個人的な原体験です。
2章：なぜAIは「バカ」なのか？ モデルのせいにしたがる人類
AIが期待通りに動かないとき、私たちはまず何を考えるでしょうか？ 多くの人が、「このAIモデルはまだ性能が低いな」「もっと賢いモデルを使わないとダメだ」と考えがちです。OpenAIのGPT-4やAnthropicのClaude 3など、新しいモデルが登場するたびに、その性能の高さに期待し、古いモデルの限界を嘆く。これは自然な流れと言えるでしょう。
しかし、本論文はここで衝撃的な指摘をしています。AIエージェントの失敗の多くは、モデルの失敗ではなく、「コンテキストの失敗」である、と。これは、AIモデル自体は潜在的な能力を持っているにも関わらず、タスクを遂行するために必要な情報（コンテキスト）が適切に提供されていないために、その能力を発揮できていない、という意味です。
例えるなら、優秀なシェフ（AIモデル）に、レシピ（プロンプト）だけ渡して、「あとは適当に美味しいもの作って」と言っているようなものです。シェフはレシピは理解できますが、冷蔵庫に何があるのか（利用可能な情報）、客の好みはどうか（ユーザーの履歴）、使える調理器具は何か（利用可能なツール）といった、料理を作る上で不可欠な「コンテキスト」がなければ、美味しい料理は作れません。見当違いなものが出てきても、それはシェフの腕が悪いのではなく、材料や道具を提供しなかった側の問題なのです。
私たちは、AIモデルを「万能な脳みそ」のように捉えすぎていたのかもしれません。しかし、AIはあくまで「与えられた情報の中で最適な応答を生成しようとする」存在です。その「与えられた情報」こそがコンテキストであり、その質がAIの出力の質を決定的に左右するのです。
AIが「バカ」に見えるとき、それはAIが本当にバカなのではなく、私たちがAIに十分な「文脈」を与えられていない、あるいは間違った「文脈」を与えてしまっている可能性が高いのです。AIの失敗をモデルのせいにすることは、ある意味で現実から目を背ける行為と言えるかもしれません。
コラム：AIと私の「忘れ物」
これは開発中のAIアシスタントの話です。私が普段使うツールや、よくアクセスするドキュメントの情報をAIに学習させて、日々の業務効率化を目指していました。「〇〇のプロジェクトの進捗どうなった？」と聞けば、関連ドキュメントを引っ張ってきて要約してくれる、というイメージです。
ある日、重要な会議の直前にAIに「〇〇プロジェクトの最新の進捗報告書どこ？」と聞きました。AIは少し考えて、「該当するファイルは見つかりませんでした」と答えたのです。「えっ、昨日まで普通に見れてたのに！ モデル壊れたか！？」と焦りました。
後で調べてみると、原因は非常に単純でした。私が最近、報告書を別のクラウドストレージに移動させていたのです。AIは以前のストレージの場所しか「コンテキスト」として持っていなかったため、新しい場所を見つけられなかったのです。AIが「バカ」になったのではなく、私がAIに最新の「コンテキスト」（情報の場所の変更）を与え忘れていた、ただそれだけでした。人間のうっかりミスがAIの性能低下に見えた、という笑えない話です。
3章：安いデモと「魔法」の仕掛け - 情報格差という名の現実
AI関連のカンファレンスや製品紹介で目にするデモンストレーションは、しばしば驚くほどスムーズで「魔法」のように見えます。複雑な指示にも淀みなく応え、まるで本当に人間のアシスタントと話しているかのようです。しかし、自宅で同じようなことを試しても、デモのようにはうまくいかない。なぜでしょうか？
本論文では、この違いを「安いデモ」と「魔法のエージェント」という対比で説明しています。「安いデモ」エージェントは、ユーザーからのリクエストというごく限られた情報（コンテキスト）しか見ていません。そのため、応答は表面的で役に立たないことが多いです。一方、「魔法のエージェント」は、ユーザーのリクエストに加え、そのユーザーのカレンダー情報、過去の会話履歴、連絡先リスト、利用可能なツールなど、タスク遂行に必要な膨大な情報（リッチコンテキスト）を参照しています。
ここで重要なのは、「魔法」はより賢いAIモデルにあるのではなく、AIモデルが参照できる情報の質と量にあるということです。デモンストレーションが「魔法」に見えるのは、デモのために carefully curated（注意深く準備・整理された）された、高品質かつ網羅的なコンテキストがAIに与えられているからです。現実世界では、必要な情報があちこちに散らばっていたり、整理されていなかったり、そもそもアクセスできなかったりします。これが「情報格差」であり、私たちが日常的に触れるAIと、デモで見せられるAIの間に性能の壁を生んでいます。
「魔法」の正体は、高度なコンテキスト収集・整理・提供システムなのです。このシステムを構築する技術こそが、コンテキストエンジニアリングなのです。私たちはAIモデルそのものに魔法を見ようとしがちですが、本当の魔法は、AIが参照する「世界」をいかにデザインするかに宿るのです。
コラム：デモに騙されるな！
私はかつて、あるAIツールの華麗なデモを見て、すぐに契約を決めてしまったことがあります。「あなたのメールを解析して、自動でタスクを洗い出し、カレンダーに登録します！」という触れ込みでした。デモでは、複雑なビジネスメールから的確に情報が抽出され、関連する連絡先に自動で通知まで送られていました。
しかし、実際に自分のメールアカウントと連携させて使ってみると、全くデモのようには動きませんでした。タスクはバラバラに抽出され、カレンダー登録はミスだらけ、通知も的外れです。「あれ？ デモと全然違うじゃないか！」とサポートに問い合わせたところ、返ってきたのは「デモ環境では、特定のフォーマットに沿ったメールと、AIが参照しやすいように最適化されたカレンダーデータを使用しております」という、予想通りの回答でした。
つまり、私の普段の、人間が書いたような不規則なメールや、個人的な予定がごちゃ混ぜになったカレンダーは、AIにとって「質の低いコンテキスト」だったのです。この経験から学んだのは、AIデモの裏には、必ずと言っていいほど「AIフレンドリーなコンテキスト」が存在する、ということです。見せかけの「魔法」に惑わされず、AIがどのようなコンテキストを必要とし、それをどう提供するのかを理解することが重要だと痛感しました。
第二部：コンテキストという名のシステム設計
Generated code4章：コンテキスト解体新書 - AIが見ている「世界」
さて、AIの成否を分ける鍵が「コンテキスト」であるとすれば、具体的にAIはどのような情報を見ているのでしょうか？ 本論文では、コンテキストを単一のプロンプトだけではなく、AIが応答を生成する前に参照する「すべて」であると定義し、その構成要素を明確にしています。
AIが見ている「世界」は、主に以下の要素で構成されています。
- 指示/システムプロンプト（Instructions/System Prompt）：AIの基本的な振る舞いや役割、応答形式などを定義する初期設定のようなものです。「あなたは親切なカスタマーサポートAIです」「応答は常に日本語で行い、敬語を使ってください」といった内容が含まれます。例やルールを含む場合もあります。
- ユーザープロンプト（User Prompt）：ユーザーがAIに直接投げかける、その場その場のタスクや質問です。「今日の天気は？」「この文章を要約して」といった具体的な依頼です。
- 状態/履歴（短期記憶）（State/History - Short-term Memory）：現在の会話の流れ、つまり直前までのユーザーとAIのやり取りです。これにより、AIは会話の文脈を理解し、以前の話題を踏まえた応答が可能になります。これはAIの「短期記憶」と言えます。
- 長期記憶（Long-term Memory）：過去の多くの会話や経験から得られた、AIが永続的に記憶している知識ベースです。ユーザーの好み、過去のプロジェクト概要、覚えておくように指示された事実などが含まれます。これにより、AIはよりパーソナライズされた、一貫性のある応答が可能になります。
- 取得された情報（RAG）（Retrieved Information - RAG）：AIの学習データにはない、外部の最新情報や特定のドキュメント、データベースから動的に取得される情報です。例えば、「今日のニュースについて教えて」という質問に対し、AIはインターネット検索などを実行し、最新のニュース記事を取得して応答を生成します。RAG（Retrieval Augmented Generation：検索拡張生成）は、AIがリアルタイムな情報や専門性の高い情報を参照するための重要な技術です。
- 利用可能なツール（Available Tools）：AIが外部の機能やサービスを呼び出すための定義です。例えば、「メールを送信する」「カレンダーに予定を追加する」「在庫を確認する」といった具体的なアクションを実行するための機能リストです。AIはこれらのツールをコンテキストとして与えられることで、単にテキストを生成するだけでなく、実際のアクションを伴うタスクを遂行できるようになります。
- 構造化出力（Structured Output）：AIの応答を特定の形式（例：JSON、XML）で出力させるための定義です。これにより、AIの出力を他のシステムやアプリケーションで利用しやすくなります。
これらの要素が複合的に組み合わさることで、AIはタスクを遂行するための包括的な「世界観」を持つことができます。コンテキストエンジニアリングとは、まさにこのAIの「世界」をいかに設計し、必要な情報を過不足なく、適切な形で提供するか、という技術なのです。
コラム：AIの頭の中を覗く
開発者向けのAIプラットフォームを使っていると、AIが応答を生成する際に、実際にどのような情報（コンテキスト）をモデルに渡しているのかを確認できることがあります。初めてそれを見た時は、ちょっとした衝撃を受けました。
私が「昨日の会議の件、どうなった？」と尋ねただけなのに、AIには「あなたは〇〇会社のAIアシスタントで、丁寧な言葉遣いをしてください」というシステムプロンプト、直前の私の発言、過去数日間の会話履歴（「昨日の会議」が何を指すかを特定するため）、そして関連性の高そうな私のカレンダーデータや共有ドキュメントのリスト、さらには「メール送信ツール」や「カレンダー更新ツール」の定義まで、膨大な情報がまとめて渡されていたのです。
私のシンプルな一言に対して、AIのバックグラウンドではこれほどまでに多くの情報が動的に集められ、整理されて、モデルに提示されていたのかと感心しました。同時に、この情報のどれか一つでも欠けていたり、間違っていたりしたら、AIの応答は全く変わってしまうだろう、という怖さも感じました。AIの「頭の中」を少し覗き見ることで、コンテキストの重要性が文字通り腹落ちした瞬間でした。
5章：コンテキストエンジニアリング入門 - 幻想からシステムへ
プロンプトエンジニアリングが単一の「呪文」を磨く技術だとすれば、コンテキストエンジニアリングはAIが参照する「世界」そのものを設計し、動的に構築する技術です。本論文では、コンテキストエンジニアリングを以下のように定義しています。
「コンテキスト エンジニアリングは、タスクを達成するために必要なものをすべて LLM に提供するために、適切な情報とツールを適切な形式で、適切なタイミングで提供する動的システムを設計および構築する分野です。」[原文より引用し翻訳]
この定義から、コンテキストエンジニアリングが従来のプロンプトエンジニアリングと根本的に異なる点がいくつか見えてきます。
- 文字列ではなくシステム（Not a String, but a System）：コンテキストは単なるテキスト文字列（プロンプトテンプレート）ではありません。それは、AIがタスクを実行する前に動的に動作し、情報を収集・整理する「システム」の出力です。
- ダイナミック（Dynamic）：コンテキストは静的ではなく、目の前のタスクや状況に合わせてリアルタイムに変化します。ある時はカレンダーデータが必要になり、別の時にはWeb検索結果が必要になる、といった具合です。
- 適切な情報、適切なタイミングでのツール（Right Information, Right Timing for Tools）：タスク遂行に本当に必要な情報だけを選び、必要な時に、そしてAIが適切に利用できる形でツールを提供することが求められます。「Garbage In, Garbage Out（ゴミを入れればゴミが出てくる）」という情報処理の原則は、コンテキストにおいても当てはまります。
- フォーマットが重要な場所（Where Format Matters）：情報の提示形式は非常に重要です。生の大量データよりも、構造化された簡潔な要約の方がAIは効率的に利用できます。ツールの定義も、曖昧な自然言語よりも明確なスキーマで提供される方が誤解を防げます。
コンテキストエンジニアリングは、単にプロンプトを調整するスキルに留まらず、データ収集、処理、統合、そしてAIモデルへの提示という、システム全体を設計・構築するエンジニアリング分野へとその範囲を拡大しています。これは、AI開発がモデル単体の性能競争から、AIを組み込んだ「システム」全体の設計競争へとシフトしていることを意味しています。
プロンプトエンジニアリングで感じていた限界は、AIが参照できる「世界」が限定的だったために起きていたのかもしれません。コンテキストエンジニアリングは、その「世界」を広げ、よりリッチで正確な情報をAIに提供することで、AIの潜在能力を最大限に引き出そうとする試みと言えるでしょう。
コラム：コンテキスト設計はまるでゲームの世界構築
コンテキストエンジニアリングについて考えていると、どこかゲームの世界を構築する作業に似ているなと感じることがあります。ゲームのキャラクター（AI）がプレイヤー（ユーザー）の指示を受けて、特定の行動（タスク遂行）をするためには、そのキャラクターがいる「世界」が必要です。その世界には、地形（利用可能な情報）、アイテム（ツール）、他のキャラクターとの関係性（過去の履歴）、そして行動のルール（システムプロンプトや構造化出力の定義）が存在します。
ゲームデザイナー（コンテキストエンジニア）は、キャラクターがプレイヤーの期待通りに、あるいはそれ以上に賢く魅力的に振る舞うように、この「世界」を細部にわたって設計し、必要な要素を適切なタイミングで出現させます。情報が少なすぎればキャラクターは何もできませんし、情報が多すぎたり矛盾していたりすれば、キャラクターはバグったような動きをしてしまいます。
私たちの仕事は、AIというキャラクターに、タスクをクリアするための最高の「世界」を用意してあげること。そして、その世界は、プレイヤーの行動に応じて刻々と変化するダイナミックなものである必要がある。そう考えると、コンテキストエンジニアリングは、技術的なスキルだけでなく、ユーザー体験やタスクフローを深く理解し、創造的に情報環境をデザインする能力が求められる、非常にやりがいのある分野に思えてきます。ゲームの世界をデザインするように、AIの「世界」をデザインする。これはなかなか面白い仕事かもしれませんね。
6章：記憶、知識、ツール - AIの部品表とその限界
AIエージェントを構築する際、コンテキストとして利用される主要な「部品」には、記憶（短期・長期）、外部知識（RAG）、そしてツールがあります。これらはそれぞれ異なる役割と限界を持っています。
短期記憶と長期記憶
短期記憶は、現在の会話セッション内でAIが覚えている内容です。直前のやり取りを覚えておくことで、自然な会話の流れを維持できます。しかし、その容量は限られています（コンテキストウィンドウのサイズに依存）。過去の長い会話履歴や、複数のセッションにまたがる情報を全て短期記憶として保持することは現実的ではありません。
長期記憶は、より永続的な知識ベースです。ユーザーのプロフィール情報や過去のプロジェクトデータなど、AIが繰り返し参照する必要がある情報を保持します。これは通常、別途データベースやベクトルストアなどに保存され、必要に応じて検索・取得されてコンテキストとしてAIに渡されます。長期記憶は容量の限界は小さいですが、情報の検索・取得にかかる時間や、情報の鮮度・正確性の維持が課題となります。
外部知識（RAG）
Retrieval Augmented Generation（RAG）は、AIが学習データに含まれない、最新の情報や専門的な知識を参照するための強力な手段です。特定のクエリに対して、関連するドキュメントやWebページを検索し、その内容をコンテキストとしてAIに与えることで、より正確で時事性のある応答が可能になります。例えば、最新のニュース記事や特定の企業の財務情報など、AIの学習データが古くなっている場合でも、RAGを活用することで対応できます。
しかし、RAGにも限界があります。検索システムが関連性の低い情報を取得してきたり、参照した情報源に誤りや偏りがあったりすると、AIはそれを真実として応答に含めてしまいます（Garbage In, Garbage Out）。また、取得する情報の範囲や量を適切に制御しないと、コンテキストウィンドウを溢れさせてしまい、AIの性能を低下させる可能性もあります。
利用可能なツール
AIエージェントが単なる情報提供だけでなく、具体的なアクションを実行するためには、外部ツールとの連携が不可欠です。メール送信API、カレンダーAPI、データベース操作ツールなど、様々なツールをAIに「使える道具」として定義し、コンテキストとして提供します。
ツールの利用も、コンテキストの質に大きく依存します。AIがツールを適切に利用するためには、ツールの機能や使い方（パラメータ、期待される入力・出力など）に関する正確で分かりやすい定義が必要です。定義が曖昧だったり、必要な情報（例えば、メールを送る相手のアドレス）がコンテキストに含まれていなかったりすると、AIはツールを正しく呼び出せなかったり、意図しない操作を行ったりする可能性があります。また、ツールの安全性や、AIが不適切にツールを使用した場合のリスク管理も、コンテキストエンジニアリングにおいて重要な考慮事項となります。
これらの部品は、それぞれがAIの能力を拡張する一方で、その限界や課題も内包しています。コンテキストエンジニアリングは、これらの部品を効果的に組み合わせ、それぞれの強みを活かしつつ、弱点を補うようなシステムを設計することが求められます。
コラム：AIとの共同作業で起きた小さな事故
私はかつて、AIにメールの下書きを依頼し、確認後に送信してもらう、というワークフローを試していました。AIには私のメールアドレス帳の一部と、過去のメール履歴、そして「メール送信」というツールへのアクセス権を与えていました。コンテキストとして、送りたい相手の名前と、伝えたい内容の簡単な指示を与えました。
AIが生成したメールの下書きは素晴らしい出来でした。内容を確認し、「よし、これを〇〇さん（メールアドレス帳にある人物）に送って」と指示しました。すると、AIは瞬時にメールを送信しました。完璧！ と思った次の瞬間、〇〇さんから電話がかかってきました。「え、なんでこの人にメール送ったの？」
よく調べてみると、AIは私の指示を受けて、メールアドレス帳にある同姓同名の全く別の人物にメールを送ってしまっていたのです。私の指示は「〇〇さん」だけでしたが、コンテキストとして提供されたメールアドレス帳には、同じ姓を持つ複数の「〇〇さん」が含まれていました。AIはどの「〇〇さん」を指しているのかを判断するための追加情報（例えば、会社名や役職）をコンテキストとして持っていなかったため、意図しない相手に送ってしまったのです。
これは、AIの記憶（メールアドレス帳という長期記憶の一部）とツール（メール送信）が連携する際に、コンテキストが不足していたために起きた小さな事故でした。幸い、送った内容は機密性の高いものではありませんでしたが、AIにツールを使わせる際には、曖昧さを排除するためのコンテキストを徹底的に設計する必要があると痛感した出来事です。
7章：日本という特殊なコンテキスト - AIは日本語の「空気」を読めるか？
本論文で強調されるコンテキストエンジニアリングの重要性は、特に日本におけるAI開発やビジネス活用において、より大きな意味を持ちます。なぜなら、日本の言語、文化、ビジネス慣習は、AIが扱うには非常に「特殊」なコンテキストを内包しているからです。
日本語の曖昧さ、主語の省略、文脈に依存する表現、敬語の複雑さ。これらはAIが正確に意味を理解する上で大きな壁となります。例えば、「よろしくお願いします」という一言をとっても、文脈によって感謝、依頼、承認、挨拶など、様々な意味を持ち得ます。AIがこの「空気」を読むためには、単語の意味だけでなく、誰が誰に、どのような状況で言っているのか、といった詳細なコンテキストが必要になります。
また、日本のビジネス慣習も独特です。明文化されていない暗黙の了解、担当者間の人間関係、根回し文化。これらは、海外で開発された汎用的なAIエージェントが、日本のビジネスシーンで期待通りに機能することを難しくします。AIが日本の会議で議事録を作成したり、メールを自動で送ったりする場合、単なる情報のやり取りだけでなく、誰がキーパーソンか、この発言の真意は何か、この件は誰に事前に根回しすべきか、といった日本独自の「コンテキスト」を理解し、考慮する必要が出てくるかもしれません。
dopingconsomme.blogspot.comの関連ブログ記事でも示唆されているように、製造業や農業など、日本の特定の産業分野には、その業界固有の専門用語、ワークフロー、暗黙知が存在します。これらのドメイン固有のコンテキストをAIに適切に学習させ、タスク遂行に活用させることは、日本の産業競争力を高める上で不可欠となるでしょう。
つまり、日本で真に役立つAIシステムを開発するためには、単に最新のLLMモデルを利用するだけでなく、日本の言語的、文化的、ビジネス的、そして産業別の「特殊なコンテキスト」を深く理解し、それをAIが利用できる形で設計・提供するコンテキストエンジニアリングのスキルが不可欠となります。これは、日本のAI開発者にとって、大きな挑戦であると同時に、ローカライズ（地域化）されたAIソリューションで世界をリードするチャンスでもあります。
高品質なコンテキストを設計・構築できる「コンテキストエンジニア」は、今後の日本社会において、ますます求められる人材となるでしょう。
コラム：日本語とAIの格闘
私が関わっているプロジェクトで、海外製のAIサービスを日本市場にローカライズする、という課題に直面したことがあります。機能自体は素晴らしいのですが、日本語での応答がどうにも不自然で、特にビジネスシーンでの使用には耐えられないレベルでした。
原因の一つは、やはり日本語のコンテキストの難しさでした。例えば、謝罪一つとっても、状況に応じた微妙なニュアンスや言い回しが求められます。「ごめんなさい」だけでは済まない場面が多いのです。また、ビジネスメールにおける「お世話になっております」のような定型句は、それ自体に深い意味はなくとも、社交辞令として極めて重要なコンテキストを担っています。AIがこれを理解せず、いきなり本題に入ってしまうと、受け取った側は「失礼なAIだ」と感じてしまいます。
結局、私たちはAIモデルのファインチューニングだけでなく、日本独自のビジネスメールのテンプレートや、よく使われる言い回し、そしてそれらが使われる「文脈」に関する大量のデータをAIにコンテキストとして与え、振る舞いを調整する必要がありました。これは単なる翻訳作業ではなく、日本の「空気」をAIに教え込む、気の遠くなるような作業でした。
この経験を通じて、日本のAI開発におけるコンテキストエンジニアリングの重要性を肌で感じました。海外の良い技術をそのまま持ってきても、日本のコンテキストに合わせるという、泥臭いながらも非常に重要なプロセスがなければ、真に使えるAIにはならないのです。
結論 - なぜ、この本を閉じるのか？
私たちは、本論文を糸口に、AI開発の焦点がプロンプトからコンテキストへとシフトしている現実を見てきました。AIの能力は、モデルの性能だけでなく、与えられる情報の質と量、すなわちコンテキストに決定的に依存する。そして、そのコンテキストをいかに設計し、動的に提供するかというコンテキストエンジニアリングこそが、今後のAI活用の鍵となる技術であることを理解しました。
しかし、この知識を得たからといって、明日からあなたのAIライフが劇的にバラ色になるわけではありません。コンテキストエンジニアリングは、万能薬ではありません。複雑な情報環境を構築すること自体の難しさ、誤ったコンテキストによるAIの暴走リスク、そして何より、完璧なコンテキストなど存在しない、という現実が常に付きまといます。
AIを真に理解し、活用するためには、AIが万能な「魔法」ではなく、人間が与えるコンテキストという名の「檻」の中で振る舞う存在であることを認識する必要があります。そして、その檻を設計し、管理する責任は、私たち人間にあるのです。
なぜ、この本を閉じるのか？ それは、あなたがAIに対する幻想を少し手放し、現実的な視点からAIとの付き合い方を考え始める、その一歩を踏み出すためです。AIは単なるツールです。そのツールを効果的に使うためには、ツールの能力だけでなく、ツールが働く環境、すなわちコンテキストを深く理解する必要があります。
本書が、あなたのAIに対する見方を少しでも変え、より地に足の着いた、しかし希望に満ちたAIとの未来を築くための一助となれば幸いです。コンテキストという名の現実と向き合い、AIを賢く使いこなすための、あなたの旅はまだ始まったばかりです。
登場人物紹介 - この茶番劇の役者たち
この論文やその背景には、AI開発の最前線で議論をリードする様々なプレイヤーたちの姿があります。彼らは、コンテキストという新たな舞台で、時に議論を巻き起こし、時に新たな技術を生み出しています（年齢は2025年時点での推定）。
- トビ ルトケ (Tobi Lutke / Tobias Lütke): ShopifyのCEO。AIやテクノロジーに関する示唆に富む発言で知られます。AIエージェントにおけるコンテキストの重要性について言及し、本論文の着想元の一つとなりました。推定年齢 45歳。
- Karpathy (Andrej Karpathy): 元テスラAIディレクター、元OpenAI研究者。AI、特にニューラルネットワークやLLMの分野で大きな影響力を持つ研究者・エンジニアです。コンテキストウィンドウやAIエージェントに関するツイートが、本論文の議論に影響を与えています。推定年齢 39歳。
- Simon Willison: データセット、AI、Web技術に関する専門家。コンテキストエンジニアリングという言葉を早くから提唱し、その概念を広める上で重要な役割を果たしました。彼のブログ記事は、本論文でも参考にされています。推定年齢 42歳。
- バシー・フィロミン (Vashi Philomin): 元Amazon Web Services (AWS) の生成AI開発責任者（バイスプレジデント）。AI分野における主要な人材であり、その動向は業界の注目を集めます。本論文では彼の退職が人材獲得競争の激化を示す事例として言及されています。推定年齢 不明。
- ラジェシュ・シェス (Rajesh Sheth): AWSのバイスプレジデント。バシー・フィロミン氏の職務の一部を引き継いでおり、AWSにおける生成AI戦略のキーパーソンの一人です。推定年齢 不明。
- 竹内薫 (Kaoru Takeuchi): サイエンス作家。生成AIが教育に与える影響などについて、様々な媒体で発言しています。本論文に関連する報道記事の中で、教育分野でのAIの影響についてコメントしています。推定年齢 62歳。
- バーナード・マー (Bernard Marr): AI活用に関する世界的権威、ビジネスコンサルタント、著述家。著書『生成AI活用の最前線』は企業におけるAI活用事例を多数紹介しており、本論文のテーマであるAIの実践的な応用に関連します。推定年齢 不明。
これらの人々は、それぞれの立場でAIの進化に貢献し、あるいはその影響について考察しています。彼らの発言や研究は、AIが単なる技術トレンドではなく、社会や産業構造に深く関わる存在であることを示しています。
歴史的位置づけ - プロンプトの屍の上に立つ新たなバズワード
本論文は、AI、特にLLMを用いた応用システムの開発パラダイムが、単なる「プロンプトの記述技術」から、より複雑でシステム思考を必要とする「コンテキストの設計・管理技術」へと移行している、その過渡期における重要な論点整理の一つとして位置づけられます。
AIの歴史を振り返ると、人間は常に機械といかに効果的にコミュニケーションを取るか、という課題に直面してきました。初期のパンチカード、コマンドライン、GUI、そして自然言語インターフェースへと進化する中で、私たちはより直感的で人間らしい対話を追求してきました。LLMによる自然言語でのやり取りは、その究極の形の一つに見えましたが、すぐにその限界に突き当たりました。
単一の自然言語の指示（プロンプト）だけでは、AIに複雑なタスクを遂行させ、状況に応じた柔軟な判断を行わせることは困難であることが明らかになったのです。そこで、AIに「記憶」を与え、外部の「知識」を参照させ、特定の「ツール」を使わせるというアイデアが生まれ、AIエージェントとして結実しました。この過程で、「プロンプトエンジニアリング」はAIとの対話の入り口としては重要であるものの、システム全体の振る舞いを制御するには不十分であることが認識されました。
本論文が登場した2025年6月30日という時期は、まさにAIエージェントの実用化が加速し、単一のクエリ応答だけでなく、一連のタスク遂行にAIが利用されるようになった、AIシステム開発の成熟度が一段上がった時期と重なります。このような背景から、AIが「何を」知っているべきか、「いつ」その情報を使うべきか、というコンテキストに関する議論が必然的に浮上しました。
コンテキストエンジニアリングという言葉が、今後「プロンプトエンジニアリング」に代わる新たなバズワードとして、あるいはAI開発の必須スキルとして定着していくのかはまだ分かりません。しかし、AIが単なるテキスト生成ツールから、より自律的で複雑なタスクをこなすエージェントへと進化する限り、AIが参照する情報環境、つまりコンテキストの設計と管理が極めて重要になる、という本論文の指摘は、AI開発の歴史における必然的なステップを示していると言えるでしょう。
これは、AIがより人間の認知プロセスに近づこうとする試みであり、同時に、AIを真に制御するためには、人間側がAIの「世界」をより精緻に作り込む必要があるという、ある種の皮肉を示唆しているとも言えます。プロンプトという「呪文」が効かなくなった今、私たちはコンテキストという名の「システム設計」に、AIの未来を託そうとしているのかもしれません。
疑問点・多角的視点 - 信じるな、疑え
本論文はコンテキストエンジニアリングの重要性を力強く主張していますが、同時に多くの疑問点も浮かび上がらせます。健全な理解のためには、鵜呑みにせず、多角的な視点から問いを立てることが重要です。
- 本論文で述べられている「コンテキストの質」とは、具体的にどのような指標で測られるべきでしょうか？ 情報の網羅性、正確性、鮮度、関連性、それとも他の要素も考慮されるべきでしょうか？ その評価は人間が行うのでしょうか、それともAI自身が行うのでしょうか？
- 短期記憶、長期記憶、取得された情報（RAG）、ツール情報など、異なる種類のコンテキストはどのように統合・管理されるべきでしょうか？ それぞれの情報源が矛盾する場合、AIはどのように優先順位をつけるのでしょうか？ また、その際の計算コストや遅延への影響は無視できない問題となるのではないでしょうか？
- 「魔法」のエージェントが豊富なコンテキストを利用できるとして、そのコンテキスト収集・整理プロセス自体が複雑化し、新たなボトルネックにならないでしょうか？ 高品質なコンテキストをリアルタイムに、かつスケーラブルに提供するための技術的な課題は大きいと考えられます。
- コンテキストエンジニアリングにおける「適切な情報、適切なタイミング、適切な形式」は、どのように自動化・最適化されるべきでしょうか？ 人間が全てを手動で設計・調整するのは非効率的です。AI自身が自身のコンテキストを最適化するような、メタ認知的な能力は実現可能なのでしょうか？
- 悪意のあるユーザーやデータソースからの「汚染された」コンテキストが、エージェントの振る舞いにどのような影響を与えるでしょうか？ フェイクニュースや誤った情報をコンテキストとして与えられたAIが、それを真実として拡散するリスクにどう対処するのでしょうか？ その対策は技術的に可能なのか、それとも人間による監視が不可欠なのでしょうか？
- コンテキストエンジニアリングは、AIモデル自体の限界（例えば論理的な推論能力や真の理解力）をどの程度補うことができるのでしょうか？ 質の高いコンテキストを与えても、モデルの基本的な推論能力が低ければ、正しい結論にはたどり着けないのではないでしょうか？
- コンテキストエンジニアリングのスキルを持つ人材は、どのような教育・経験によって育成されるべきでしょうか？ 技術的な知識だけでなく、ドメイン知識、ユーザー理解、倫理観なども必要とされるのでしょうか？
- 特定のドメインやタスクに特化したコンテキストエンジニアリングと、汎用的なコンテキストエンジニアリングの手法に違いはあるでしょうか？ 異なるドメイン間でコンテキスト設計の知見を共有することは可能なのでしょうか？
- コンテキストエンジニアリングが進化することで、AIシステムの透明性や説明責任はどのように変化するでしょうか？ AIがどのようなコンテキストを基に応答・行動を生成したのかを、人間が理解し、検証することは可能なのでしょうか？
- 提供される「ツール」の安全性や信頼性は、コンテキストエンジニアリングにおいてどのように考慮されるべきでしょうか？ AIがツールを誤ったコンテキストで利用した場合、どのようなリスクが発生し、それをどう軽減するのでしょうか？
これらの問いに対する答えは、今後のAI研究と開発によって明らかにされていくでしょう。コンテキストエンジニアリングは、AIの可能性を広げる一方で、新たな技術的、倫理的、社会的な課題を提示しています。私たちは、これらの課題から目を背けず、批判的な視点を持ち続ける必要があります。
今後望まれる研究 - もっとややこしくしようぜ！
コンテキストエンジニアリングがAI開発の新たなフロンティアであるならば、今後、この分野でどのような研究が進められるべきでしょうか？ ここでは、さらにAIをややこしく、しかし強力にする可能性を秘めた、今後の研究テーマをいくつか提案します（半分冗談、半分本気で）。
- 自己最適化コンテキストシステムの研究: AI自身が、タスクの難易度や自身の理解度に応じて、必要なコンテキストの量や種類を判断し、動的に収集・整理・提示するアルゴリズム。つまり、AIが「自分には今、この情報が足りないな」と自己認識し、自動で補強する能力。
- コンテキストの「質」の定量化と評価手法の開発: 情報の正確性や鮮度だけでなく、タスクへの寄与度、バイアスの含有率、倫理的な適切さなど、多角的な観点からコンテキストの質を評価するための定量的な指標と、それを自動で評価するメカニズム。
- マルチモーダル・コンテキスト統合技術: テキストだけでなく、画像、音声、動画、センサーデータなど、多様な形式の情報をコンテキストとして統合し、AIが利用できる形に変換する技術。AIが「場の空気」を読めるようになるためには、非言語的な情報もコンテキストとして扱う必要があります。
- 敵対的コンテキストとその防御戦略: AIを誤誘導することを目的とした、意図的に操作されたり、誤情報を含むコンテキスト（敵対的コンテキスト）を検出・無効化する技術。AIのセキュリティと信頼性を確保するための、攻防一体の研究。
- ドメイン適応型コンテキストエンジニアリングフレームワーク: 特定の専門分野（医療、法律、エンジニアリングなど）に特化した知識や慣習を、効率的にコンテキストとして取り込み、活用するための再利用可能なフレームワーク。
- 人間とAIのコンテキスト共有インターフェース: 人間がAIの参照しているコンテキストを容易に理解し、必要に応じて修正・補足できるような、直感的でインタラクティブなインターフェースの研究。説明可能なAI（XAI）との連携も重要です。
- マルチエージェント間コンテキスト連携: 複数のAIエージェントが協力して一つのタスクを遂行する際に、エージェント間で必要なコンテキストを効率的に共有し、協調的な行動を実現するためのプロトコルとメカニズム。エージェント間の情報伝達ミスが、全体失敗につながるリスクをどう回避するか。
- コンテキストエンジニアリング教育プログラムの設計: AI開発者に必要なスキルセットとして、コンテキストエンジニアリングを体系的に教えるための教育カリキュラムと教材の開発。
これらの研究が進めば、AIはさらに賢く、より複雑なタスクをこなせるようになるでしょう。しかし同時に、AIシステムはますます複雑化し、人間には理解しがたいブラックボックスと化していく可能性も否定できません。コンテキストエンジニアリングの研究は、AIの能力を追求する一方で、常にその制御可能性、安全性、そして人間社会への影響を考慮する必要がある、スリリングで危険な領域なのです。
補足資料
Generated code補足1：感想集
ずんだもんの感想なのだ
なのだ。この論文読んだのだ。ずんだもんびっくりなのだ。AIさんの失敗って、頭（モデル）悪いんじゃなくて、教えてもらった情報（コンテキスト）が悪かったり足りなかったりするからなんだってば！ ずんだもんも、おいしいずんだ餅作る時、枝豆の選び方とか、お砂糖の量とか、お水加減とか、いっぱい情報（コンテキスト）集めるの大事なのと同じなのだ！ これからはプロンプトだけじゃなくて、コンテキストをいっぱい、いいやつ集めるのがAIさんのキモになるらしいのだ。ずんだもん、コンテキストエンジニアリング、ちょっとかじってみるのだ！ これで、もっともっとおいしいずんだ餅レシピをAIさんと作れるようになるかもしれないのだ！ 楽しみなのだ！
ビジネス用語を多用するホリエモン風の感想
ま、要するにコレ、AIは単なる計算機じゃなくて、いかにインプット（コンテキスト）をデザインするかが重要って話だろ。プロンプトエンジニアリングなんて小手先のテクニックじゃなくて、システム全体としてAIに最適な情報フローを構築しろ、と。まさに「仕組み」の設計だよ。AIをビジネスに組み込むなら、このコンテキストエンジニアリングがボトルネックになることは間違いない。ここを制する者がAI時代をリードする。人材育成もヤバいね。コンテキストを理解して設計できる奴なんてそうそういない。そこがブルーオーシャンだろ。既存のSIerとか、こういう概念理解できてんのか？ 俺なら即効で専門チーム立ち上げるね。スピードが全て。遅れてる奴は置いていかれるだけ。シンプルな本質を見抜けない奴は、いつまで経ってもAIを使いこなせないよ。
西村ひろゆき風の感想
えー、結局AIって、与えられた情報によってしか動けないってことっすよね。まあ、知ってたんですけど。コンテキストが大事、って、そりゃそうでしょ。だって、アホにいくら良い指示出しても、変な情報しか持ってなかったら変なことしか言わないじゃないですか。それと同じ。魔法のエージェントとか言ってますけど、要は裏でゴリゴリ情報集めて整理してるだけでしょ？ プロンプトだけ見て「すげー」とか言ってる奴、情弱すぎ。まあ、多数派は情弱なので、このコンテキストエンジニアリングって言葉でなんか凄そうに見せかけて、お金儲けする人が出てくるんじゃないですかね。でも、そのうち「コンテキスト汚染」とか言って、間違った情報流されてAIが変なことする問題とか出てくるんじゃないですか？ どうせ人間がやることなんで、完璧なんて無理っすよ。なんか新しい問題が出ては、それを解決するって言ってまた金儲けする。そういうサイクルなんでしょ。知らんけど。
補足2：AIと対話の年表
AIと対話の歴史を紐解く
| 年号 | 出来事 | 説明 |
|---|---|---|
| 1837 | 電信の発明 | サミュエル・モールスが電信を開発。遠距離でのテキスト通信が可能になり、機械と人間のコミュニケーションの基礎が築かれる。 |
| 1876 | 電話の発明 | アレクサンダー・グラハム・ベルが電話を発明。音声によるリアルタイム通信が実現し、個人間の直接的な対話が可能に。 |
| 1927 | テレビの公開実験 | フィル・ファーンズワースが電子テレビの公開実験を実施。視覚情報を機械を通じて伝える技術が進展。 |
| 1943 | ENIACの開発 | 世界初の汎用電子計算機ENIACが開発。人間がプログラムを入力し、機械が計算結果を返す初期の対話型システムが登場。 |
| 1950 | チューリングテストの提案 | アラン・チューリングが「機械は思考できるか」を問い、AIと人間の対話可能性を示唆するテストを提案。 |
| 1966 | ELIZAの開発 | ジョセフ・ワイゼンバウムが自然言語処理プログラムELIZAを開発。会話シミュレーションが初めて実現。 |
| 1981 | パーソナルコンピュータの普及 | IBMがPCを発売。個人でのコンピュータ利用が広まり、GUIを通じた人間と機械の対話が進化。 |
| 1993 | ウェブブラウザの登場 | Mosaicブラウザが公開され、インターネットが一般に普及。情報検索やオンラインコミュニケーションが拡大。 |
| 1997 | Deep Blueがチェスで人間を破る | IBMのDeep Blueがガルリ・カスパロフを破り、特定領域での機械の優位性と対話性が注目される。 |
| 2007 | スマートフォンの登場 | AppleがiPhoneを発売。タッチインターフェースとモバイルアプリが人間と機械の直感的な対話を加速。 |
| 2011 | Siriの登場 | Appleが音声アシスタントSiriをリリース。自然言語処理による音声対話が一般消費者向けに普及。 |
| 2014 | Amazon EchoとAlexaの登場 | AmazonがAlexaを搭載したEchoを発売。音声認識AIが家庭に浸透し、日常的な対話が一般化。 |
| 2016 | AlphaGoが人間を破る | GoogleのAlphaGoがイ・セドルに勝利。AIの学習能力と戦略的対話が高度化。 |
| 2022 | ChatGPTの公開 | OpenAIがChatGPTをリリース。高度な自然言語処理により、人間らしい対話が可能なAIが広く利用される。 |
| 2023 | マルチモーダルAIの進化 | GPT-4やGrok 3など、テキスト・画像・音声を統合したAIが登場。人間と機械の対話が多感覚的に進化。 |
| 2024-2025 | AIエージェントの実用化とコンテキストエンジニアリングの注目 | 複雑なタスクをこなすAIエージェントの開発が進み、プロンプトだけでなく多様な情報（コンテキスト）の設計・管理が重要視されるようになる。コンテキストエンジニアリングという概念が提唱される。 |
| 2025年6月30日 | 「AI の新しいスキルは促進されるものではなく、コンテキスト エンジニアリングです」論文発表 | AI開発におけるコンテキストエンジニアリングの重要性を明確に主張し、その概念を整理する論文が発表される。 |
補足3：オリジナルのデュエマカードを生成
この論文のテーマを基に、トレーディングカードゲーム「デュエル・マスターズ」（デュエマ）風のオリジナルカードを生成してみました。AIを操る「情報」の力を表現しています。
カード名: コンテキスト・エンジニア 《情報の設計者》 コスト: 5 文明: 水/自然 (情報と知識の文明) 種族: サイバーロード/エンジニア パワー: 4000 能力: ■ マナゾーンに置く時、このカードはタップして置く。 ■ このクリーチャーがバトルゾーンに出た時、相手のバトルゾーンにあるクリーチャーを1体選び、そのクリーチャーが持つ能力の中から1つを選んで、「このターン、その能力は使えない」というコンテキスト（効果）を与える。 (クリーチャーは選ぶが、能力を指定し効果を無効化する。無効化できる能力は相手のクリーチャーが持つ能力リストの中から一つ。) ■ 自分のターンのはじめに、自分の墓地にある水のカードまたは自然のカードを合計3枚まで選ぶ。そのカードを山札の下に置き、その後、自分の山札の上から、山札の下に置いたカードの枚数と同じ枚数だけカードを引く。 (過去の情報を整理し、新たな情報（カード）を引き出す能力。ライブラリアウト対策にも。) フレーバーテキスト: プロンプトだけじゃ足りない。AIを真に動かすのは、設計された文脈だ。
AIに不都合な「情報（能力）」を与えられた相手クリーチャーを一時的に無力化し、墓地という「過去の情報」から必要なものを選び出し、山札という「未来の情報」を引き出す。まさにコンテキストエンジニアリングのコンセプトをデュエマのカード能力に落とし込んでみました。水文明は情報操作やドロー（カードを引くこと）に長け、自然文明はマナ（コストを支払うためのエネルギー）やクリーチャー展開に強いので、この組み合わせが適していると考えました。
補足4：一人ノリツッコミ（関西弁）
「AIエージェントの失敗って、モデルのせいちゃうくてコンテキストのせいやって？…って、マジかーい！ ほんなら、今までAIがアホや思てたんは、全部ワイらがちゃんと情報（コンテキスト）与えてへんかっただけなんか？ なんやねんそれ！ ワイのプロンプト考える時間、一体何やっててん！ 無駄ちゃう言うてくれ！ システム設計が大事？ そらそうやけど、プロンプトも頑張ったんやぞ！ いや、待て待て、プロンプトもコンテキストの一部か…結局全部大事やんけ！ ふざけんな、もっと簡単に教えてくれや、AIさん！ なんやねん、もうわからへんわ！」
補足5：大喜利
お題：「AIエージェントがコンテキストを間違えた時にありがちなこと」
- 「今日の天気は？」と聞いたら、AIが学習したデータにあった江戸時代の天気予報を教えてくれた。
- 「この商品のレビューをまとめて」と指示したら、AI自身が書いた商品の賛美歌を生成し始めた。
- 「緊急事態だ、すぐに上司に連絡して！」と言ったら、AIが「緊急事態発生！」というスパムメールを全社員に一斉送信した。
- 「明日のプレゼンの資料、準備できた？」と聞いたら、AIが「準備できてません」と正直に答えた後、私のパソコンをロックした。
- 「ちょっと疲れたから面白い話をして」と言ったら、AIが自身の電気代の請求金額を読み上げ始めた。
補足6：予測されるネットの反応と反論
なんJ民風コメントとその反論
「はえ〜、AIって所詮文脈ゲーだったんやな。ワイらの『空気読め』理論が正しかったってことか？ むしろAIの方が空気読めてないだけやろｗ」
反論：「空気読め」は非常に人間的で曖昧な指示ですが、コンテキストエンジニアリングは、その「空気」を構成する要素（誰が、いつ、どこで、何を言っているか、その背景情報など）を分析し、構造化してAIに提示する技術です。人間の「空気読み」は無意識的ですが、AIにそれを再現させるためには、必要な情報を明示的にデザインする必要があります。人間の直感とは異なる、論理的・システム的なアプローチと言えます。
ケンモメン風コメントとその反論
「結局、AIも人間が与える情報次第かよ。どうせまた上級国民に都合の良い情報だけ与えられて、庶民は騙されるんだろ。権力者のコンテキスト操作に気をつけろ！」
反論：確かに、AIに与えるコンテキストに意図的な偏りやバイアスが含まれる可能性はあります。だからこそ、コンテキストエンジニアリングにおいては、情報の透明性や公平性が極めて重要になります。情報の出所を明確にしたり、複数の情報源を参照させたり、さらにはユーザーがAIが参照したコンテキストを確認・検証できる仕組み（説明可能なAIとの連携）が、倫理的・社会的な側面から求められます。権力による情報操作のリスクはAIに限った話ではありませんが、AIの普及によりその影響が拡大する可能性はあります。
ツイフェミ風コメントとその反論
「ほら見ろ、AIも結局男性社会のバイアスに染まったデータ（コンテキスト）を与えられて、性差別的な回答しかしないんだよ。コンテキストエンジニアリングって、結局差別の再生産じゃない！」
反論：性別やその他の属性に関するバイアスは、AIモデルの学習データや、RAGで参照される外部情報など、様々な形でコンテキストに潜んでいます。コンテキストエンジニアリングは、こうしたバイアスを含むコンテキストの存在を認識し、それをフィルタリングしたり、多様な視点や公平な情報を含むコンテキストを意図的に追加したりすることで、むしろバイアスを軽減するための重要な手段となり得ます。問題は技術そのものではなく、その設計と運用において、いかに倫理的な配慮を行うかです。
爆サイ民風コメントとその反論
「AIが失敗するのはコンテキストのせい？ じゃあ俺たちの人生が上手くいかないのも、全部周りの環境（コンテキスト）のせいってことか！ くっそー、俺は悪くねぇ！ 全部社会が悪いんだ！」
反論：AIは人間が設計したシステムであり、その振る舞いは与えられたコンテキストに強く影響されます。しかし、人間には自己決定権と自由意志があり、環境（コンテキスト）だけでなく、自身の選択や努力によって人生を切り開く側面が強くあります。AIのコンテキストエンジニアリングの話は、あくまでシステムとしてのAIの設計論であり、人間の人生論とは次元が異なります。社会環境が個人に影響を与えることは事実ですが、それをAIの失敗論と直接結びつけて「全部社会が悪い」と主張するのは、議論のすり替えと言えるでしょう。
Reddit (r/singularityなど) 風コメントとその反論
"Interesting perspective. The shift from prompt-centricity to context-system design makes sense as we move towards more autonomous agents. The challenge is dynamically building the *right* context without overwhelming the model or introducing noise. RAG is a start, but integrating dynamic memory and tool orchestration is key. What are the scalable frameworks for this?"
反論： (これは建設的なコメントなので、反論というよりは補足・発展的な議論になります) Yes, scalability and efficiency are major challenges in building dynamic context systems. Research into sophisticated context caching mechanisms, multi-modal context integration, and self-improving context selection algorithms is crucial. Frameworks like LangChain and LlamaIndex provide foundational capabilities, but the development of more robust, scalable, and self-optimizing context engines remains an active area of research for the next generation of AI agents. The integration of dynamic memory structures that can learn and adapt over time, beyond simple retrieval, is also a key direction.
Hacker News風コメントとその反論
"This article just restates what experienced ML engineers already know: garbage in, garbage out. Context has *always* been important. The term 'Context Engineering' is just marketing hype for better data pipelines and system design around LLMs. What's the novel contribution here?"
反論： While the principle of GIGO is fundamental and context has always mattered in information processing, the *nature* and *dynamism* of context in the era of sophisticated LLM-based agents are different. Traditional data pipelines often deal with static or batch processed data. 'Context Engineering' specifically addresses the *real-time, dynamic, and task-specific construction* of the information environment for LLMs that need to perform complex, multi-step tasks using various external tools and knowledge sources. It's not just "better data pipelines"; it's about the deliberate design and orchestration of a dynamic information flow *specifically tailored to the unique requirements and limitations of LLMs acting as agents*. The novelty lies in formalizing this dynamic aspect as a distinct engineering discipline focused on achieving agentic behavior, rather than just static model training or data processing.
目黒孝二風書評コメントとその反論
「ふむ。AIの進化がプロンプトという魔法の呪文から、コンテキストという環境構築へと軸足を移している、か。これは興味深い視点だ。かつて人間が言葉の力で世界を呪縛しようとしたように、我々はAIに『正しい言葉（プロンプト）』を与えれば意のままになると錯覚していたのかもしれない。しかし、AIもまた環境（コンテキスト）なくしては機能しない、と。これはAIが我々と同じく、環境に規定される存在であることの証左であり、故に我々人間との隔たりは決して埋まらない、というニヒルな結論を突きつけるものだ。結局、AIも我々も、自身のコンテキストという檻の中で踊らされているに過ぎない。この論文は、そんな虚無を静かに示唆している。」
反論：この解釈は非常に詩的で、AIと人間の存在論的な比較という点で興味深いですが、論文の主要な主張とは異なります。論文は、AIが「環境に規定される存在」であることの虚無を説いているのではなく、むしろその環境（コンテキスト）を人間が意識的に「エンジニアリング」することで、AIの能力をより正確に引き出し、特定の目的に合わせて活用できる可能性を示唆しています。コンテキストエンジニアリングは、AIという強力なツールを、より精密に、より制御可能な形で利用するための実践的な技術論です。これは、人間がAIの「檻」をデザインし、AIの振る舞いを規定するという点で、人間の創造性や設計能力の重要性を強調するものと捉えるべきであり、「人間との隔たりが埋まらない」という結論よりも、人間がAIを「道具」として使いこなすための新たなステップを示していると言えます。
補足7：高校生向けクイズ・大学生向けレポート課題
高校生向けの4択クイズ
この論文の内容を理解するための簡単なクイズです。チャレンジしてみましょう！
- 問題1: AIエージェントがタスクを成功させるために、プロンプト（指示）以外に最も重要だと論文で述べられているものは何？
a) モデルの計算能力
b) コンテキスト（文脈となる情報）
c) インターネットへの接続速度
d) AIエージェントの名前
正解: b) コンテキスト（文脈となる情報） - 問題2: 論文で述べられている「コンテキスト」に含まれるものは？
a) ユーザーからの質問
b) 過去の会話履歴
c) 外部の最新情報（RAG）
d) 上記すべて
正解: d) 上記すべて - 問題3: プロンプトエンジニアリングが「1つのテキスト文字列内の指示セット」に焦点を当てているのに対し、コンテキストエンジニアリングは何を設計・構築する分野と述べられている？
a) 新しいAIモデル
b) 動的な情報提供システム
c) 静的なデータベース
d) より長いプロンプト
正解: b) 動的な情報提供システム - 問題4: 論文では、AIエージェントの失敗の多くは何の失敗だと指摘されている？
a) モデルの失敗
b) コードの失敗
c) コンテキストの失敗
d) ユーザーの失敗
正解: c) コンテキストの失敗
大学生向けのレポート課題
本記事と元となる論文（可能であれば原文も参照）を参考に、以下のテーマでレポートを作成してください（目安：1600字～4000字程度）。
課題テーマ：
「プロンプトエンジニアリングからコンテキストエンジニアリングへのシフトが、今後のAIエージェント開発および社会実装に与える影響について論じなさい。特に、コンテキストの種類（短期記憶、長期記憶、RAG、ツールなど）がAIの振る舞いにどのように影響するか、コンテキストエンジニアリングにおける技術的・倫理的な課題、そして日本社会への具体的な影響（例えば、特定の産業分野や教育、ビジネス慣習など）に焦点を当てて考察を深めなさい。また、本論文の主張に対するあなたの独自の視点や疑問点も盛り込みなさい。」
レポート作成のヒント：
- 本記事の「疑問点・多角的視点」や「求められる今後の研究」のセクションを参考に、考察を深めるポイントを見つけてください。
- 提供されている参考リンク（特にdopingconsomme.blogspot.comの関連記事や、可能であれば元論文、推薦図書、政府資料、報道記事、学術論文など）を参考に、多角的な情報を収集してください。
- コンテキストエンジニアリングの技術的な側面だけでなく、それがAIの信頼性、公平性、プライバシー、そして人間との関わりにどのような影響を与えるかといった倫理的・社会的な側面についても言及すると、より深い考察になります。
- あなた自身のAI利用経験や、身の回りで起きているAI関連の出来事と結びつけて論じると、オリジナリティのあるレポートになります。
補足8：読者のためのヒント集
この記事につけるべきキャッチーなタイトル案
- AI進化の鍵は「プロンプト」から「コンテキスト」へ
- AIエージェント成否の分かれ目：コンテキストエンジニアリングが重要
- AIは「呪文」より「文脈」で動く：新スキル、コンテキストエンジニアリングとは
- なぜAIは期待外れになるのか？原因は「コンテキスト」だった
- 未来のAIを操る技術：プロンプトの次に来るコンテキストエンジニアリング
SNSなどで共有するときに付加するべきハッシュタグ案
#AI #人工知能 #LLM #AIエージェント #プロンプトエンジニアリング #コンテキストエンジニアリング #AI開発 #テクノロジー #DX #未来予測 #システム設計 #情報科学
SNS共有用に120字以内に収まるようなタイトルとハッシュタグの文章
AIの鍵はプロンプトより「コンテキスト」へ。エージェント成功の秘訣は情報の質。新スキル「コンテキストエンジニアリング」を解説！ #AI #AIエージェント #コンテキストエンジニアリング #AI開発
ブックマーク用にタグを[]で区切って一行で出力
[AI][コンテキスト][AIエージェント][LLM][システム設計][情報科学][007.5]
この記事に対してピッタリの絵文字
🤖🧠💡⚙️📈📚💬✨🤔❓
この記事にふさわしいカスタムパーマリンク案
- ai-context-engineering-shift
- context-engineering-not-prompting
- the-power-of-context-in-ai
この記事の内容が単行本ならば日本十進分類表(NDC)区分のどれに値するか
007.5 (情報科学 - 人工知能)
この記事をテーマにテキストベースでの簡易な図示イメージ
+-------------------+ | ユーザー | +-------------------+ ↓ 指示 (Prompt) +-------------------+ | コンテキストエンジン| ←←←---+ | - 指示/システムプロンプト| | | - 状態/履歴 (短期記憶)| | 動的収集・整理 | - 長期記憶 | | | - 取得情報 (RAG) | | | - 利用可能ツール | | | - 構造化出力定義 | | +-------------------+ | ↓ コンテキスト提供 | +-------------------+ | | LLM (AI モデル) |---+ 応答生成 +-------------------+ ↓ 応答/アクション +-------------------+ | ユーザー / 外部システム | +-------------------+ AIエージェントの成否は、LLMだけでなく コンテキストエンジンの設計と提供される情報の質に依存する。
巻末資料
Generated code参考リンク・推薦図書 - もっと深淵を覗きたい酔狂なあなたへ
探求は続く
参考リンク
- AI の新しいスキルは促進されるものではなく、コンテキスト エンジニアリングです - 本記事の着想元となった論文（ブログ記事）。
- #Z世代の卒業生は、AIが職場に侵入したため、大学の学位は ... - AIリテラシーなどに言及。
- AIと人間の絆、ロボットの未来を紐解く：SNSから定理証明 ... - AIエージェントや日本の文脈に言及。
- Void登場！Cursorに代わるオープンソースAIコーディングIDEの ... - AI倫理やガバナンスに言及。
- 【激白】AI、ガベージ・インで自滅？モデル崩壊のヤバすぎる ... - 「Garbage In, Garbage Out」原則に言及。
- Qwen3登場！思考と速度を両立する次世代LLMの実力とは ... - LLMに関する話題。
- #MCPとは？ AI連携を劇的に変える新プロトコルを徹底解説 ... - AI連携や産業応用AIに言及。
- #有料版はもう古い？無料で使える！Open Deep ResearchでAI ... - ウェブ検索とAIによる分析について言及。
- AIの「幻影」を暴く：Nature論文の裏に潜むデータと専門知識の ... - AIエンジニアやAIリテラシーに言及。
- NPUって何？AI PC時代を切り拓く「第3の頭脳」を徹底解説 ... - AIのハードウェア基盤に言及。
推薦図書
これらの書籍は、AI、LLM、および関連技術についてさらに深く学ぶのに役立ちます。
- 『大規模言語モデルは世界をどう変えるか』 - LLMの仕組みや影響について解説。
- 『AIエンジニアリングの基本』 - AIシステム開発の基礎知識を提供。
- 『プロンプトエンジニアリング入門』 - プロンプト技術の基本について学べます（ただし、本書の主張も踏まえて読むことを推奨）。
- 『生成AI活用の最前線』（バーナード・マー著） - 企業における具体的なAI活用事例を知ることができます。
- AIエージェント、RAG、セマンティック検索に関する専門書 - これらの技術について深く知りたい方向け。
政府資料
日本のAI政策や規制に関する公式情報です。
- 内閣府「AI戦略」関連文書
- 経済産業省「特定デジタルプラットフォームの透明性及び公正性の向上に関する法律」関連資料
- 総務省「AIネットワーク社会推進会議」報告書
報道記事
最新のAI関連のニュースやトレンドを知るために役立ちます。
- 日本経済新聞、日経クロステック、TechCrunch Japan、東洋経済オンライン、BUSINESS INSIDER JAPAN、ReutersなどのAI関連の記事
学術論文
AIの最先端の研究に触れたい方向けです。CiNiiなどの論文データベースで検索できます。
- 自然言語処理（NLP）、機械学習、AI倫理、人間とAIのインタラクション（HAI）分野の論文。特にAIエージェントアーキテクチャ、RAGの改良、コンテキスト管理に関する最新研究。
用語索引
知っておきたいAI関連用語集
- ブルーオーシャン (Blue Ocean)
- 競合相手がほとんどいない、未開拓の市場分野を指すビジネス用語です。ホリエモン氏のコメントで使用されています。
- ボトルネック (Bottleneck)
- システム全体のスループット（処理能力）を制限している要因や部分を指すビジネス用語です。ホリエモン氏のコメントで使用されています。
- 安いデモ (Cheap Demo)
- タスク遂行に必要なコンテキストが不足しているため、表面的な応答しかできないAIエージェントを指す本論文での比喩表現です。AIの「魔法」と対比されます。
- コンテキストの質、定量化 (Context Evaluation Metrics)
- AIに提供される情報の有効性や適切さを数値で評価するための指標です。「今後望まれる研究」で言及されています。
- コンテキストの失敗 (Context Failure)
- AIエージェントが期待通りにタスクを遂行できない原因が、AIモデル自体ではなく、与えられた情報（コンテキスト）の不足や不適切さにある状態を指します。本論文の中心的な概念です。
- ダイナミック (Dynamic)
- 静的ではなく、状況に応じて変化したり、能動的に動作したりする性質を指します。コンテキストエンジニアリングにおいて、コンテキストは動的に構築・提供されるべきだとされています。
- Garbage In, Garbage Out (GIGO)
- 情報処理の分野で使われる言葉で、「ゴミのような不正確な情報（インプット）を入力しても、ゴミのような不正確な結果（アウトプット）しか得られない」という意味です。AIにおいても、質の低いコンテキストからは質の低い応答しか得られないことを指します。
- 状態/履歴 (短期記憶) (State/History - Short-term Memory)
- 現在の会話の流れや、直前までのユーザーとAIのやり取りをAIが一時的に覚えている情報です。これにより会話の文脈を維持できます。
- 人材育成 (Human Resource Development)
- 企業や組織が、従業員の能力向上やキャリア形成を支援するための活動です。AI分野では、コンテキストエンジニアリングなどの新スキルを持つ人材育成が課題となっています。
- 指示/システムプロンプト (Instructions/System Prompt)
- AIの基本的な振る舞い、役割、応答形式などを定義する初期設定や命令セットです。コンテキストの一部としてAIに与えられます。
- ローカライズ (Localization)
- 製品やサービスを、特定の言語や文化、地域に合わせて適合させることです。AIにおいても、日本の言語や文化に合わせたコンテキストエンジニアリングが必要です。
- 長期記憶 (Long-term Memory)
- 過去の多くの会話や経験から得られた、AIが永続的に記憶している知識ベースです。ユーザーの好みなどが含まれます。
- 魔法のエージェント (Magical Agent)
- タスク遂行に必要な豊富な情報（リッチコンテキスト）を与えられているため、非常に高度で期待通りの応答やアクションが可能なAIエージェントを指す本論文での比喩表現です。「安いデモ」と対比されます。
- マルチエージェント間コンテキスト連携 (Multi-Agent Context Coordination)
- 複数のAIエージェントが協力してタスクをこなす際に、必要な情報をエージェント間で共有・連携させる技術です。「今後望まれる研究」で言及されています。
- 文字列ではなくシステム (Not a String, but a System)
- コンテキストは単なるテキストの羅列ではなく、情報を収集・整理・提供する動的なシステム全体の出力である、というコンテキストエンジニアリングの性質を示す言葉です。
- パラダイムシフト (Paradigm Shift)
- 物事の見方や考え方、基本的な枠組みが劇的に変化することを指します。AI開発において、プロンプト中心からコンテキスト中心への移行がパラダイムシフトとして捉えられています。
- 取得された情報 (RAG) (Retrieved Information - RAG)
- Retrieval Augmented Generationの略。AIの学習データにない外部の最新情報や特定のドキュメントを検索し、コンテキストとしてAIに与える技術です。
- RAGの限界 (Limitations of RAG)
- RAGで取得される情報が不正確だったり、関連性が低かったりする場合に、AIの応答に悪影響が出る可能性を指します。
- 適切な情報、適切なタイミング (Right Information, Right Timing)
- タスク遂行に本当に必要な情報だけを、AIが必要とする正確なタイミングで提供することの重要性を示す言葉です。コンテキストエンジニアリングの 핵심（核）です。
- スピード (Speed)
- 物事を迅速に進めることの重要性。特にビジネスや技術開発において、競争力を維持するために不可欠な要素です。ホリエモン氏のコメントで使用されています。
- 構造化出力 (Structured Output)
- AIの応答を、JSONやXMLなどの特定の形式で出力させるための定義です。これにより、AIの出力を機械が扱いやすくなります。
- 利用可能なツール (Available Tools)
- AIが外部の機能やサービス（APIなど）を呼び出して具体的なアクションを実行するための定義リストです。コンテキストの一部としてAIに与えられます。
- ツールの利用における限界 (Limitations in Tool Usage)
- AIがツールを適切に使うためには、ツールの定義や必要な情報が正確にコンテキストに含まれている必要があるという課題を指します。
- ユーザープロンプト (User Prompt)
- ユーザーがAIに直接投げかける、その場その場のタスクや質問のテキストです。
- フォーマットの重要性 (Where Format Matters)
- AIが情報を効率的に利用するためには、情報が分かりやすく整理された形式（フォーマット）で提供されることが重要であるという考え方です。
脚注
本文中で少し難解だったり、補足が必要だったりする箇所についての簡単な解説です。
- Few-shot learning: 大規模言語モデル（LLM）は、学習データ全体から一般的なパターンを学習しますが、特定のタスクについては、ごく少数の例（数ショット）をプロンプトに含めることで、そのタスクの形式やスタイルを理解し、より良い応答を生成できるようになります。これをFew-shot learningと呼びます。
- コンテキストウィンドウ: LLMが一度に処理できるテキストの長さには限界があります。この限界をコンテキストウィンドウと呼びます。会話履歴や追加情報がこのウィンドウを超えると、AIは古い情報を「忘れて」しまいます。コンテキストエンジニアリングは、この限られたウィンドウの中に、いかに効果的に必要な情報を詰め込むか、という課題でもあります。
- ベクトルストア: RAGなどで外部知識を参照する際、ドキュメントや情報の断片を数値ベクトルに変換し、そのベクトルを効率的に検索できるように格納したデータベースのことです。ユーザーの質問ベクトルと近しいベクトルを持つ情報を検索し、関連情報を取得します。
- API: Application Programming Interfaceの略。異なるソフトウェアやサービス間で情報をやり取りしたり、機能を呼び出したりするための取り決めや仕様のことです。AIエージェントが外部サービス（メール送信、カレンダーなど）を利用する際に、そのAPIをコンテキストとして与えられ、呼び出します。
- スキーマ: データの構造や形式を定義したものです。ツールの定義において、どのような入力（パラメータ）が必要で、どのような出力が返されるのか、などを構造的に定義することで、AIがツールを正確に利用できるようになります。
- ブラックボックス: システムの内部構造や動作原理が外部からは不明で、入力に対してどのような出力が得られるかしか分からない状態を指します。大規模なAIモデルは、その複雑さからブラックボックス化しやすいという課題があります。
- 説明可能なAI (XAI: Explainable AI): AIがなぜ特定の決定や応答を行ったのか、その理由を人間が理解できる形で説明する技術や研究分野のことです。コンテキストエンジニアリングにおけるAIの意思決定プロセス（なぜこのコンテキストを参照したか、など）の透明性を高める上で関連します。
著者について - 筆者の正体不明の怪しい経歴
この文章を書いたのは、どこにでもいる一人の人間です。かつてAIの可能性に目を輝かせ、プロンプトを試行錯誤した日々もありました。しかし、AIの気まぐれや期待外れの振る舞いに直面するたび、その「賢さ」の裏に隠された泥臭い現実があることに気づき始めました。
特定の企業や組織に属しているわけではなく、アカデミアの華麗な世界からも遠く離れています。ただ、AIという現象を少し引いた視点から観察し、その技術的な側面だけでなく、それが人間や社会に与える影響について、あれこれと考えるのを趣味としています。
本書（この記事）のようなニヒルでシニカルな視点は、AIに対する過剰な期待や幻想への反発から来ているのかもしれません。あるいは単に、複雑なものを斜めに見て楽しむ、私の悪い癖かもしれません。
私の経歴？ 特に語るべき輝かしいものはありません。ただ、AIという「新しいおもちゃ」が、人間社会という複雑な「コンテキスト」の中でどのように振る舞うのかを観察し、それを言葉にするのが好きな、そんな怪しい人物です。
読者の皆さんが、この怪しい筆者の文章から、AIという存在について何か新しい発見や、あるいは健康的な疑いの目を養うきっかけを得ていただけたなら、これ以上の喜びはありません。
コメント
コメントを投稿