2025/12/03 0:39
Context plumbing
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
概要：
AI インターフェースは「Do What I Mean」システムへと進化し、ユーザーの意図とコンテキストを直接把握することで、人が望むこととシステムが提供するものとのギャップを縮小しています。企業は現在、管理フリクションを削減する AI を重視しており、元の意図に最も近いものが競争優位となります。この目標を達成するには、背景知識・ツールドキュメント・対話履歴・共有ファイル・セッション状態など豊富なコンテキストが不可欠であり、要求時に情報を移動できるダイナミックなコンテキストエンジニアリングパイプラインが必要です。
従来の Web 2.0 CRUD アプリや単純な HTTP 動詞は、AI の会話フローには合わなくなっています。LangChain などの最新フレームワークはコンテキストを動的に配管することに焦点を当てていますが、著者は 2 年間かけて Cloudflare ベースのプラットフォームを構築し、エンティティとエージェント間でコンテキストがスムーズに流れるようにしています。
将来を見据えると、AI は常時稼働するデバイスや組み込み型エージェントに依存してユーザー近くでコンテキストをキャプチャし、瞬時の意図実現と貴重なトレーニングデータ生成を可能にします。継続的かつ低遅延の配管パイプラインは、ダイナミックコンテキストを効率的に移動させるよう進化します。ユーザーにとってはより自然で手間のない対話が実現し、企業にとっては高速かつ正確なサービスが競争優位を生み出します。業界は静的 CRUD アーキテクチャからリアルタイム・コンテキスト認識型システムへ移行しており、AI エージェントのためのデータ収集・保存・活用方法を再構築しています。
本文
数週間前からコードに没頭し、いわゆる「コンテキスト・プラミング」に取り組んでいます。
実際にはAIシステムを構築しており、その体験がここにあります。詳しく説明します。
目的
ざっくり言えば、AIインターフェースは「意図」と「コンテキスト」についてです。
- 意図 はユーザーのゴール――大きいものでも小さいものでも、明示的か暗黙的かを問わずです。
- コンピューターにとってAIは意図を理解し、人間らしく応答することができる新しい能力です。
ユーザーが「カメラを買いたい」と入力したり、キーレーダーを指差して「20分後に電話がある」と声に出さずに言ったり、雲除去というボタンを押したりすると、AIはそれを実行します。
企業がこれに関心を持つのは、意図に近いコンピューターほど勝てるからです。
例えばスマートフォンはデスクトップを置き換えました：電話では何かを見ると直接タッチでき、デスクトップではポインタ経由で意図が伝わり、脳にはそれが自然に感じられません。
同じことがユーザーインターフェース全般にも当てはまります。メニューからコマンドを選ぶ、ウェブページをナビゲートして休暇を計画する、HVAC制御パネルの操作方法を覚える――これらすべてが官僚主義です。自分で手順を把握することは、意図と結果の間に管理的負担を生みます。
AI企業としては、その負担を取り除くために、ユーザーの意図が湧き上がる瞬間・場所に常駐すればよいのです。電話をポケットから取り出したり、無意識の意図を言葉に変える手間さえも不要にします。意図の起点に最も近づくことで競合他社を圧倒できます。
これがAI搭載のメガネ・リュックタグ・マイク・ボディランゲージ読み取りカメラなどのデバイスへの推進理由です。
インターフェースの未来は 「私が意味することを実行」 だと考えるのは、AIによって可能になる新機能だけでなく、全く別の注意経済的必然性があるからです。
コンテキスト
AIが意図をうまく扱う鍵はコンテキストにあります。
-
大規模言語モデルは膨大な学習データから世界知識を保持しています。
-
ユーザーの意図を受け取り、ツール呼び出しで目標へ向かってヒルクライミングするAIエージェントは、プロンプトに有用なコンテキストが含まれていると遥かに優れた性能を発揮します。
- WikipediaやGoogleなどから得られる類似状況の背景知識
- エージェントが使用するツールのドキュメント
- ユーザー自身のコンテキスト：過去の行動、時刻など
- ユーザーとAIが共有する暗黙知・共通前提（何をすべきかという仮定）
- 「ホワイトボード」的な共有ドキュメント
- エージェント自身のセッションコンテキスト：このタスクは大目標のサブタスクか、以前にうまくいったことがあるかなど
これが コンテキストエンジニアリング（LangChainブログで紹介）を生み出し、LLMが適切な情報とツールを正しいフォーマットで受け取ってタスクを遂行できるようにする動的システム構築を可能にしています。
コンテキストへのアクセスは、大手AI企業の挙動も説明します。
ユーザー意図に最適に答えるには、ユーザーのコンテキストが存在する場所に居座らねばなりません。だからリュックタグに常時オンのカメラを付ける方が、必要なときだけ起動するカメラより好ましいですし、メールアーカイブ内に住むAIエージェントは、そうでないものより効果的です。（推論時のコンテキストは記録されれば貴重なトレーニングデータにもなる）
パイプライン？
コンテキストエンジニアリングの概念から欠けている点は、コンテキストが動的であること――変化し、タイムリーであるという事実です。
ユーザー活動、環境変化、新メール・編集済みドキュメント・天気情報・ツール更新など、さまざまな場所からコンテキストは湧き上がります。このコンテキストは常にAIが走る場所ではなく、AIはできるだけユーザー意図の瞬間近くで動作します。
したがってエージェントをうまく動かす仕事とは、必要な場所へコンテキストを移動させることです。つまりデータベース間で情報を継続的にコピーするプロセスです。
AIエージェントは意図回答のたびにコンテキストを検索したくないでしょう――遅いからです。迅速に行動するには先回りして、可能なコンテキストをその源から目的へ流すパイプを構築します。
帯域幅やサイクルを浪費せず、データが古くならないように継続的に背景でこれを実現するのが、コンテキストソースとシンクの配管です。
Web 2.0時代の定番アーキテクチャは「CRUD」アプリでした。ウェブアプリはデータベースを包む形でエンティティや操作（作成・読み取り・更新・削除）を提供し、HTTP動詞に対応します。
ユーザー体験もそれに合わせており、ユーザープロフィールページや写真ページ、ストリームやフィードとしてインデックスされたダイナミックページが存在しました。こうしたアプリは分解可能で、技術とユーザーの理解が一致していました。
AIシステムでは、利用者が直感的に「どんなコンテキストが使えるか」を把握できる必要があります。コンテキストフローの配管は単なる技術的実現や効率だけでなく、ユーザー期待と合致しなければなりません。
抽象化してしまう点もありますが、私はここ2年間試みてきたプラットフォームを構築しています――今度こそうまく動いています。
Cloudflare上で、さまざまなエンティティとAIエージェント（サブエージェントを含む）が必要に応じて走る場所へコンテキストが流れ、全体が絡み合っても混乱せず、まるで正しく配管されたように機能しています。
詳細についてはまだ語れませんが、そのことをメモとして残しておきました。