かつて「プロンプトエンジニアリング」とは、大規模言語モデルから良い結果を引き出すための技術に私たちが与えた名前でした。初期の頃はそれで十分でした。ほとんどの人がワンショットのやり取りを使っており、主なレバーは本当に言葉遣いのように感じられました。より明確に質問し、例を加え、フォーマットを制約すれば、モデルはより良く振る舞いました。
しかし、そのフレームワークは今や実際の問題に対して小さすぎます。
AIシステムが本番環境で失敗するとき、問題は通常、モデルがシステムプロンプトにもう一つ巧みな文を必要としていたことではありません。問題は、モデルが適切な情報を見ていなかった、無関係な情報を見すぎていた、適切な情報を間違ったフォーマットで見ていた、あるいは一つのステップから次のステップへ適切な状態を引き継げなかったことです。言い換えれば、問題はプロンプトだけではありませんでした。問題はコンテキストパイプライン全体でした。
だからこそコンテキストエンジニアリングという用語が広まりました。この言葉は2025年半ばにAIの主流な議論に登場し、Tobi LütkeとAndrej Karpathyが「プロンプトエンジニアリング」は信頼性の高いLLMシステムを構築するための実際の作業を過小評価していると主張しました。[1] しかし、その根底にある規律は名前よりも古いものです。RAG、ツール呼び出し、メモリシステム、要約、評価ループを構築したことがあれば、すでにコンテキストエンジニアリングの一部を行っています。変わったのは、仕事全体を表す名前がついにできたということです。
最もシンプルな図で表すなら、コンテキストエンジニアリングは外の世界とモデルのワーキングメモリの間にある層です。
flowchart TD\n U[\"ユーザーリクエスト\"] --> CE[\"コンテキストエンジン\"]\n\n I[\"指示とポリシー\"] --> CE\n R[\"取得した知識\"] --> CE\n M[\"メモリと保存された状態\"] --> CE\n T[\"ツール定義と結果\"] --> CE\n H[\"最近の会話履歴\"] --> CE\n\n CE --> W[\"モデルのコンテキストウィンドウ\"]\n W --> L[\"LLMが推論し行動する\"]\n L --> O[\"回答またはツール呼び出し\"]\n O --> S[\"新しいメモリ、ログ、状態\"]\n S --> CEこれがゲームの全てです。
モデルは推論エンジンです。コンテキストエンジンは、モデルが何を推論するかを決定します。
この用語が共感を呼ぶ理由の一つは、それまで別々に進化していたいくつかのスレッドを結びつけているからです。
Retrieval-Augmented Generation（RAG）は、モデルが推論時に外部知識にアクセスする必要があることを教えてくれました。[2] ReActは、モデルがツールを呼び出し、結果を観察し、そこから継続できるとき、推論と行動がより良く機能することを教えてくれました。[3] メモリ研究は、長期間動作するアシスタントには、無限のトランスクリプト蓄積ではなく、インデックス作成、取得、読み取り戦略が必要であることを教えてくれました。[4] 長いコンテキストの評価は、単純により多くのトークンをモデルに詰め込むことは、より良いワーキングメモリを与えることと同じではないことを示しました。[5][6][7]
このように見ると、コンテキストエンジニアリングはこれらのアイデアの代替ではありません。それらの上にある傘です。
その傘が重要なのは、現代のAIシステムがもはや孤立したプロンプトではないからです。それらは、次のステップのために一時的なコンテキストウィンドウに指示、ドキュメント、構造化データ、ツール出力、および以前の状態を組み立てる動的なシステムです。LangChainはこれをうまく表現しており、コンテキストエンジニアリングを、LLMがタスクをもっともらしく完了できるように、適切な情報とツールを適切なフォーマットで提供する作業と定義しています。[8]
「もっともらしく完了する」というフレーズは多くの意味を持っています。それが正しいテストです。
エージェントが失敗した場合、最初の質問は「プロンプトをどうすればより賢くできるか？」であってはなりません。
最初の質問は「モデルが成功するために必要なものを実際に与えたか？」であるべきです。
プロンプトエンジニアリングはまだ重要です。ただ、より大きな規律のサブセットになりました。
| プロンプトエンジニアリング | コンテキストエンジニアリング |
|---|---|
| より良い指示を書く | 完全な情報環境を構築する |
| 単一のリクエストに集中する | マルチステップシステムに集中する |
| 主に静的 | 動的でステートフル |
| 言葉遣いを最適化する | 選択、構造、メモリ、ツールを最適化する |
| 単一のモデル呼び出しを改善する | ループ全体を改善する |
この違いは、エージェントを構築した瞬間に明らかになります。
エンタープライズソフトウェアのサポートエージェントを構築しているとします。ユーザーが「なぜAPIリクエストがタイムアウトしているのですか？」と尋ねます。
プロンプトの観点だけで考えると、言葉遣いを改善するかもしれません：
これらは良い改善です。しかし十分ではありません。
実際のシステムの質問はより難しいです：
それがコンテキストエンジニアリングです。
プロンプトはその中の一つの項目に過ぎません。
実際には、コンテキストには推論時にモデルが見るすべてのものが含まれます。目に見えるプロンプトだけではありません。[8][9]
通常、それは以下を意味します：
これが「コンテキストウィンドウを埋める」というフレーズが非常に重要になった理由です。コンテキストウィンドウは単にテキストが入る場所ではありません。それはモデルの一時的なワーキングメモリです。そこに入るすべてのものが注意を競い合います。
そして競争がキーワードです。
余分なトークンは単なる追加情報ではありません。それはまた追加の気晴らしでもあります。
現在のAI市場で最も一般的な誤解の一つは、より大きなコンテキストウィンドウがコンテキストエンジニアリングをあまり重要でなくしたというものです。
研究は逆の方向を示しています。
「Lost in the Middle」は、モデルが長いコンテキストを不均一に使用することが多く、関連情報が最初または最後の近くに現れるときにパフォーマンスが良く、重要な情報が中間にあるときにパフォーマンスが悪いことを示しました。[5] Databricksの長いコンテキストRAG研究では、より多くの取得ドキュメントを追加することは助けになる場合があるが、64kトークン以上で強いパフォーマンスを維持した最先端モデルはごく少数であることがわかりました。[6] Chromaの「Context Rot」レポートはさらに踏み込んでいます：入力長が増加するにつれて、特に曖昧さと気晴らしが導入されると、単純なタスクでさえ信頼性が低下します。[7]
これは多くのチームが苦労して学ぶ部分です。
より大きなウィンドウは選択の必要性を排除しません。最初は悪い選択のコストを見えにくくし、後でより痛みを伴うものにします。
長いプロンプトは少なくとも4つの異なる方法で失敗する可能性があります：
これがコンテキストエンジニアリングがトークンを最大化することではない理由です。それはコンテキストウィンドウ内のシグナル密度を最大化することです。
ここで最近の最良のアイデアの一つが登場します。
Jason Liuは、古典的なチャンクベースのRAGの次のステップは、「最も類似したパッセージ」だけを考えることをやめ、検索空間の形状について考え始めることだと主張しました。[10] 彼のフレームワークは、多くのチームがすでに移行しているプログレッションをマッピングしているため、特に有用です：
最初の3つは取得されるものの改善です。
4番目はより興味深いです。それはエージェントがコーパス自体について学ぶことを改善します。
ファセットはモデルに周辺視野のようなものを与えます。上位のいくつかのチャンクだけを返す代わりに、システムは集約されたメタデータも返すことができます：
これが重要なのは、類似性検索が最も重要なものではなく、最も一致しやすいものに偏っているからです。[10] 取得システムは、よく文書化された解決済みのインシデントを過剰に表示し、まだ開いているスパースなインシデントを過小表示するかもしれません。法的検索は署名済みの契約を過剰に表示し、実際に注意が必要な未署名のものを隠すかもしれません。ファセットはエージェントが「何が一致したか」だけでなく「近くに他に何が存在するか」を見るのに役立ちます。
これは大きな概念的転換です。
RAGは主に取得についてでした。
コンテキストエンジニアリングはますますナビゲーションについてになっています。
コンテキストエンジニアリングを具体的にする最も簡単な方法は、それが実際に行う仕事に分解することです。
最初の仕事は、ウィンドウに入る価値があるものを決定することです。
これには取得、ランキング、フィルタリング、ソースの選択、鮮度チェックが含まれます。明らかに聞こえますが、ここで多くの品質が勝ち負けします。BRIGHTのようなベンチマークは、現実的な取得が表面的な意味的マッチングが示唆するよりもはるかに難しいことを示しています。[11] 取得品質が弱い場合、どれだけ下流のプロンプトを磨いても結果を完全に救うことはできません。
選択は単に「関連するチャンクを見つける」ことではありません。それは：
良いシステムはしばしばナイーブなシステムよりも少なく取得しますが、より意図的に取得します。
2番目の仕事は、選択されたコンテキストをどのように表現するかを決定することです。
同じ情報でも、フォーマットによって役立つか役立たないかが変わります。Anthropicのツール使用ガイダンスはこれについて明確です：ツールの説明とインターフェースはモデルの動作を強く形成します。[9] 長いコンテキストのプロンプトガイダンスは、XMLタグ付け、ソースラベリング、明確に分離されたドキュメントセクションについて同様の推奨をしています。[12]
実際には、構造とは：
短くてよくラベル付けされた結果は、巨大なJSONブロブよりも優れたパフォーマンスを発揮することが多いです。
3番目の仕事は、重要なものを破壊せずにコンテキストを削減することです。
ここで多くのエージェントシステムが大幅に良くなるか悪くなるかが決まります。
圧縮とは：
OpenAIのプロンプトキャッシングドキュメントは、プロンプトの順序が経済的にも認知的にも重要であることを示しています：キャッシュヒットは正確なプレフィックスの再利用に依存するため、静的な共有プレフィックスを前に置くと安くて速くなります。[13] OpenAIの新しいResponses APIのコンパクション作業は、長期間実行されるエージェント履歴を、ウィンドウが満杯になる前により少ないトークンの表現に圧縮されるべきものとして扱うことで、同じアイデアをさらに推し進めています。[14]
圧縮はオプションではありません。唯一の質問は、意図的に行うか、コンテキストウィンドウが自然に劣化するままにするかです。
4番目の仕事は、現在のターンを超えて何を持続させるかを決定することです。
ここで多くのチームが同じ間違いを犯します：メモリとトランスクリプト保持を混同します。
しかし良いメモリは「すべてを永遠に保持する」ことではありません。LongMemEvalは長期メモリを3段階の問題としてフレーム化しています：インデックス作成、取得、読み取り。[4] それが正しい考え方です。メモリシステムは、完全な過去でモデルを溺れさせるのではなく、適切な瞬間に適切な以前の事実を回復するのに役立つべきです。
これは有用な区別につながります：
すべてがワーキングメモリに留まると、モデルは気が散ります。すべてが押し出されると、モデルは継続性を失います。
コンテキストエンジニアリングは、各層に何が属するかを決定します。
5番目の仕事は、ツールをモデルにとって読みやすくすることです。
これは規律の過小評価されている部分です。ツールサーフェスは単なるソフトウェアAPI設計ではありません。それはまたコンテキスト設計でもあります。
モデルは以下を理解する必要があります：
これがツールの説明が非常に重要な理由です。[9] Jason Liuのツール結果への強調が重要な理由でもあります。[10] ツールの出力は単に現在のクエリに答えるだけではありません。それはエージェントに次のクエリについてどう考えるかを教えます。
ツールサーフェスがMCPのようなプロトコルを通じて標準化されると、これはさらに重要になります。MCPはツール、リソース、プロンプトをLLMアプリケーションに接続しやすくしますが、どの情報を表示すべきか、どのようにフィルタリングすべきか、次のモデル呼び出しにどれだけ注入すべきかを決定しません。[15] プロトコルは配管です。コンテキストエンジニアリングは依然として技術です。
6番目の仕事は、コンテキストを共有しないタイミングを決定することです。
これはデモと本番エージェントの最大の違いの一つです。
時には正しい答えは、より大きな共有プロンプトではありません。それは分離されたスコープを持つ複数の小さなプロンプトです。
Anthropicのマルチエージェント研究システムは強力な例です。[16] そのサブエージェントは別々のコンテキストウィンドウで並行して実行され、すべての中間詳細で互いを汚染することなく問題の異なるブランチを探索するのに役立ちます。LangChainは「分離」という同様のパターンを説明しています：エージェントの信頼性を向上させる最良の方法は、コンテキストを蓄積するのではなく分割することです。[17]
これが重要なのは、共有コンテキストに隠れたコストがあるからです。それはパス依存性を生み出します。一つの悪いブランチが次のステップ、そのまた次のステップに影響を与える可能性があります。
分離は爆発半径を制限する方法です。
2025年、コンテキストエンジニアリングは主に人々がすでに感じていた問題の有用な名前でした。2026年には、アーキテクチャとして固まり始めています。
最初の大きな変化は、ビルダーが持続的な状態を生のコンテキストウィンドウの外に移動させていることです。Anthropicのコンテキスト編集とメモリツールは、ワーキングウィンドウでライブに留まるものとセッション間で持続すべきものを明示的に分離しています。[18] OpenAIの2026年1月のパーソナライゼーションに関するクックブックは、異なる形で同じ動きをしています：各実行にわたって持続し、各実行の開始時にワーキングメモリに意図的に注入される構造化された状態オブジェクト。[19] OpenAIのResponses APIはネイティブコンパクションでこれをさらに一歩進め、長期間実行されるエージェントループがすべてのチームがカスタム要約サブシステムを構築する必要がないようにしています。[14]
AnthropicのManaged Agentsは、基礎となるパターンを異常に明示的にしています：セッションはモデルのコンテキストウィンドウではありません。[20] それは重要な2026年のアイデアです。ウィンドウは一時的なワーキングメモリです。セッションログは持続的なオブジェクトです。ハーネスは、その持続的なコンテキストを次のモデル呼び出しにスライス、コンパクト、再水和する方法を決定します。
2番目の変化は、取得がよりジャストインタイムでよりインターフェースネイティブになっていることです。すべての可能性のある関連トークンを前もって読み込む代わりに、チームはエージェントにすでに操作方法を知っている取得サーフェスを与えています。MintlifyのChromaFsは良い例です：ドキュメント取得のためにフルサンドボックスを起動する代わりに、`ls`、`cat`、`grep`でナビゲート可能な仮想ファイルシステムとしてドキュメントを提示し、p90セッション作成を約46秒から約100ミリ秒に削減しています。[21] TursoのAgentFSは同じ直感を一般的なエージェント実行に向けて推し進めています：ポータブルな単一ファイルストレージと組み込み監査を持つコピーオンライトファイルシステム抽象化。[22]
3番目の変化は、コンテキストグラフが単なる比喩ではなく実装の方向性になっていることです。Foundation Capitalのテーゼがこの用語を可視化しましたが、より強い主張はアーキテクチャ的です：エージェントが実行パスに座るとき、最終出力を発するだけでなく、決定トレースを持続的なアーティファクトとしてキャプチャできます。[26][27] GraphitiやZepのようなオープンソースシステムは、有効性ウィンドウ、出所エピソード、セマンティクス、キーワード、グラフ構造にわたるハイブリッド取得を持つ時間的コンテキストグラフとしてこれを運用化しています。[23] TrustGraphは、コンテキストをバージョン管理されたアーティファクトとして扱うことで関連するアプローチを取っています：オントロジー、グラフ構造、埋め込み、出所、取得ポリシーをビルド出力のように昇格またはロールバックできるポータブルな「コンテキストコア」にバンドルしています。[24][25]
4番目の変化は、コンテキストエンジニアリングがプラットフォームブログだけでなく、実際のソフトウェア実践で可視化されていることです。2026年のMSRペーパーは、コンテキストエンジニアリングをオープンソースソフトウェアで研究し、466のリポジトリを調査し、`AGENTS.md`のようなAIコンテキストファイルが広まっているが、まだ安定したコンテンツ構造がないことを発見しました。[28] これは理論から運用アーティファクトへの移行を示すため重要です。コンテキストはもはや実行時に推論されるだけのものではありません。ソフトウェアライフサイクルの一部として作成、バージョン管理、レビュー、マイニングされています。
2026年のメンタルモデルを一枚の図で表すと、次のようになります：
flowchart LR\n E[\"セッションログ / イベント\"] --> A[\"コンテキストアセンブラー\"]\n F[\"ファイル、ドキュメント、ツール\"] --> A\n G[\"コンテキストグラフ / メモリ\"] --> A\n P[\"ポリシーとAGENTS.md\"] --> A\n\n A --> W[\"ワーキングコンテキストウィンドウ\"]\n W --> X[\"エージェントアクション\"]\n\n X --> E\n X --> Gこれは「プロンプト + ベクター検索」とは全く異なるアーキテクチャです。
この会話が混乱する理由の一つは、人々がコンテキストエンジニアリングとコンテキストグラフを同じ意味で使うからです。それらは同じではありません。
コンテキストエンジニアリングはより広い規律です。次のコンテキストウィンドウに何を入れるか、何を除外するか、何を圧縮するか、何をオンデマンドで取得するかを決定する作業です。
コンテキストグラフは、その大きなシステム内の一つの可能な長期メモリ基盤です。
この区別が重要なのは、すべての有用なエージェントがコンテキストグラフを必要とするわけではないからです。主に静的なコンテンツに対するドキュメントアシスタントは、良い取得、ツール設計、コンパクションが必要かもしれませんが、グラフは必要ないかもしれません。コーディングエージェントは、リポジトリ指示、持続的なセッションログ、ファイルシステム抽象化で驚くほど遠くまで行けるかもしれません。[20][21][22][28]
コンテキストグラフは、問題が4つの特性を持つときに説得力を持ちます：
これが私の見解では、コンテキストグラフの最良の定義が「AIのためのグラフデータベース」ではない理由です。それは先例の持続的な表現です。
これが決定トレースが非常に重要な理由でもあります。Foundation Capitalのフレームワークはここで有用です：ルールはエージェントに一般的に何が起こるべきかを伝えます；決定トレースは、実際の制約と実際の例外の下で、特定のケースで何が起こったかを伝えます。[26] これらのトレースがエンティティと時間にわたってリンクされると、一般的なメモリよりもはるかに価値のあるものが得られます。検索可能な判断が得られます。
今日真剣なコンテキストエンジニアリングスタックを構築するなら、グラフから始めません。インターフェースと昇格ルールから始めます。
すべてのアクション、ツール結果、観察、重要な中間アーティファクトは、追記専用のセッションログまたはイベントストアに記録されるべきです。これが回復可能なコンテキストオブジェクトです。[14][20]
アクティブなコンテキストウィンドウを真実のソースと混同しないでください。
ウィンドウは推論のためです。セッションは回復、リプレイ、デバッグ、選択的再水和のためです。
アセンブラーは明示的に以下を管理すべきです：
これはモデルが今何を見るかを決定する層です。観察可能で、テスト可能で、変更が安価であるべきです。[18][19][14]
まずモデルに軽量なハンドルを与えます：ファイルパス、オブジェクトID、URL、クエリテンプレート、チケットID、インシデントID。そして必要なときだけ詳細を引き出させます。[9][18][21]
ここでファイルシステム、MCPツール、検索API、構造化クエリが巨大なtop-Kダンプよりも価値があります。
すべてがメモリになるべきではありません。
4つのクラスのアーティファクトを昇格させます：
それ以外はすべて、昇格に値することが証明されるまでセッションログに留まるべきです。
これは多くのチームが逆にする部分です。
グラフはグラフ形式の生のトランスクリプトであってはなりません。それはセッションの上とリアルタイムアセンブリの下に座るキュレートされた層であるべきです：
昇格ステップをスキップすると、グラフはダンプ場になります。昇格を正しく行うと、グラフは組織が実際にどのように推論するかのメモリになります。[23][26]
2026年において、最も有望なアイデアの一つはコンテキストをバージョン管理されたアーティファクトとして扱うことです。ソフトウェアプロジェクトでは、これは`AGENTS.md`やその他のリポジトリ固有のコンテキストファイルとして現れます。[28] グラフネイティブシステムでは、コンテキストコアとして現れます：オントロジー、グラフ構造、埋め込み、出所、取得ポリシーのポータブルバンドル。[24][25]
これが重要なのは、コンテキストの変更がコードの変更と同じ運用規律を必要とするからです：
コンテキストがアーティファクトになると、ガバナンス可能になります。
両方が必要です：
それらは同じものではありません。
私が知りたいのは：
これらの質問に答えられない場合、まだ暗闇の中でプロンプトをデバッグしています。
自分のシステムがどこに立っているかを評価しようとしているなら、この成熟度モデルは抽象的な定義よりも有用です。
システムプロンプト、ユーザーメッセージ、そしておそらくいくつかの例があります。
これは狭いタスクに対して驚くほどうまく機能することがあります。タスクが新鮮な知識、永続性、またはツールを必要とするとすぐに壊れます。
実行時にドキュメントを追加します。
多くのチームがここで止まります。また、多くのチームがナイーブなチャンキング、ランキング、コンテキストブロートの限界を見始める場所でもあります。
履歴、ツール結果、メモリ、フォーマットを意図的に管理するようになります。
これはシステムがもはや単なるプロンプトプラス取得ではなく、複数の形式のコンテキストを動的に組み立てているため、「コンテキストエンジニアリング」が有用な用語になる最初のレベルです。
システムはタスクに基づいてコンテキストの構築方法を変えます。
以下を行うかもしれません：
この時点で、コンテキスト構築はアプリケーションのコアロジックの一部です。
システムはコンテキストをファーストクラスのエンジニアリングサーフェスとして扱います。
以下を持っています：
これが最強の本番システムが向かっている場所です。
規律全体をチェックリストに絞り込むとしたら、次のようになります：
これは何も華やかではありません。だからこそ重要なのです。
プロンプトエンジニアリングはショートカットのように聞こえたから人気になりました。
コンテキストエンジニアリングは実際の作業を説明しているから重要です。
AIの重心が移動しています。
フロンティアの質問はかつて：モデルはどれほど賢いか？でした。
応用の質問はますます：モデルは行動しなければならない前に何を見ることができるか？になっています。
それは異なるエンジニアリング問題です。単一のプロンプトよりもシステム設計について。言葉遣いよりも情報フローについて。ワンショットの出力品質よりも、エージェントが時間をかけて信頼性を維持できるかどうかについて。
これがコンテキストエンジニアリングが規律として成長し続ける理由です。モデルが良くなるほど、残りの失敗はコンテキストの失敗のように見えます。欠けている状態。間違ったツール。悪い取得。膨れ上がった履歴。貧弱なフォーマット。矛盾する証拠。弱いメモリ。無制限のループ。
皮肉なのは、これがAIシステムを古典的なソフトウェアに似ていないのではなく、より似ているように感じさせることです。私たちはパイプライン、インターフェース、状態機械、メモリ階層、キャッシュ、観察可能性層の構築に戻っています。新しいのは、これらすべての部分が確率的推論エンジンのサービスに存在するようになったことです。
名前は新しいかもしれません。方向性は新しくありません。
信頼性の高いAIシステムは、コンテキストをファーストクラスのプロダクトサーフェスとして扱うチームによって構築されます。
それ以外の人は、モデルが不安定だと言い続けるでしょう。
参考文献：
[1] Simon Willison. (2025, June 27). Context engineering.
[2] Lewis, P. et al. (2020). Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks.
[3] Yao, S. et al. (2023). ReAct: Synergizing Reasoning and Acting in Language Models.
[4] Wu, D. et al. (2025). LongMemEval: Benchmarking Chat Assistants on Long-Term Interactive Memory.
[5] Liu, N. F. et al. (2023). Lost in the Middle: How Language Models Use Long Contexts.
[6] Leng, Q. et al. (2024). Long Context RAG Performance of Large Language Models.
[8] LangChain. (2025, June 23). The rise of \"context engineering\".
[9] Anthropic. How to implement tool use.
[10] Jason Liu. (2025, August 27). Beyond Chunks: Why Context Engineering is the Future of RAG.
[12] Anthropic. Long context prompting tips.
[15] Model Context Protocol. What is the Model Context Protocol (MCP)?
[16] Anthropic. (2025, June 13). How we built our multi-agent research system.
[17] LangChain. (2025, July 2). Context Engineering.
[18] Anthropic. (2025, September 29). Managing context on the Claude Developer Platform.
[20] Anthropic. Scaling Managed Agents: Decoupling the brain from the hands.
[21] Mintlify. (2026, March 24). How we built a virtual filesystem for our Assistant.
[22] Turso. AgentFS.
[23] Zep. Graphiti: Build Real-Time Knowledge Graphs for AI Agents.
[24] TrustGraph. The context development platform.
[25] TrustGraph. Working with Context Cores.
[26] Gupta, J., and Garg, A. (2025, December 22). AI's trillion-dollar opportunity: Context graphs.
[27] Garg, A. (2026, January 16). Why context graphs are the missing layer for AI.
", "source_hash": "sha256:352e42d5b8ff71176c26e2e3f9853217033b811bae4f0beaef2cc91e2401caa9", "model": "claude-sonnet-4-6", "generated_at": "2026-04-23T20:56:33.630704+00:00" }