Sally-Ann Delucia / サリーアン・デルシア · 14:00 「エージェントはプロンプトのせいで失敗するのではない、 コンテキストのせいで失敗する。 初期はプロンプトエンジニアリングがすべてだった、 でも今はコンテキストエンジニアリングや」
Sally-Ann は Arize の Head of Product、 元データサイエンティスト。 「PM だが Part-time AI Engineer でもある」 と自己紹介。 自社プロダクトを使って自社プロダクトを構築するという循環で 「Alex を Alex で作る」 過程で発見した、 コンテキスト管理の実装パターンを 失敗を含めて率直に共有 するセッション。
動画の核心は 「Naive Truncation → Summarization → Smart Truncation + Memory」 という 3 段階の試行錯誤。 そして 「Sub-agents で重い仕事をオフロード」 という追加パターン。 これは Anthropic Claude Code 内部の戦略と 独立に発見された同じ戦略であることが、 動画内の Claude Code リーク (2026 年初頭の話) で発覚した、 という業界エピソードも含む。
MEMEX 視点で重要なのは、 これが Karpathy の 「context engineering」 概念の 本番運用版 であること。 Karpathy が 2025 年中頃に X で 「context engineering > prompt engineering」 と提唱したのを、 Sally-Ann が 1 年後 (2026 年) に 「我々もまさにそう経験した」 と本番事例で補強する。
着眼点
「Alex を Alex で作る」 で陥った悪循環 (03:45 - 04:45)
Sally-Ann のチームの設計判断: 「自社のアプリケーション構築を助けるエージェントが作れたら、 ユーザーも欲しがる」。 そこで Alex を Alex で作る。 でも悪循環に。
- Alex が trace + span データで実行 → span が膨張 → コンテキスト上限 → Alex が失敗 → span にその失敗データ追加 → 再実行 → さらに失敗 → ...
- 「データを分析するシステムが、 そのデータに制約されてしまう」 (04:30)
- これでは Alex は永遠に成功しない
この発見が、 「コンテキスト管理は エンジニアリング問題ではなく、 プロダクト / UX 問題」 という Sally-Ann の核心主張に繋がる。 「エージェントが正しいデータ・コンテキストを持たなければ、 悪い回答を出す。 悪い回答を出すなら、 誰もプロダクトを使わない」 (03:30)。
3 つの失敗 — Truncation、 Summarization、 そして... (05:00 - 07:50)
Arize の試行錯誤の率直な記録:
試行 1: Naive Truncation (5:15)。 「context blob の最初の 100 文字だけ取って、 後は捨てる」。 単純な質問では機能した、 でもフォローアップ質問で完全に壊れる。 「『最も多い入力は?』 → 回答 → 『B についてもう少し教えて』 → Alex は何の話か分からない」 (05:45)。 過剰トランケーションが推論を破壊する。
試行 2: Summarization (06:17)。 「LLMs は要約が得意、 全コンテキストを要約してから渡せばいい」。 でも一貫性が低すぎる。 「何が重要かのコントロールがない、 LLM に任せきり」 (06:30)。 失敗。
試行 3: Smart Truncation + Memory (07:03)。 これが採用された戦略:
- Head 100 文字 + Tail 100 文字 を保持 (最初と最後)
- 中間 を切り取って memory store に保存
- Alex が必要と判断すれば、 memory から取り出せる
- 「Context decides what the model sees、 Memory decides what survives」 (07:49)
Sally-Ann の評価: 「数ヶ月触ってない、 機能してる」。 シンプルな実装だが、 「Alex に必要に応じて memory にアクセスする裁量」 を持たせる設計が決定的。
Long Session Evals — 長い会話での失敗を検出する (08:00 - 08:50)
重要な周辺機構。 「ユーザーはチャットを再開しない傾向がある — Claude も Cursor も、 全部 1 つのチャットでやる」。 そして 「会話が長くなると、 失敗が遅く出てくる」 (08:20)。 Sally-Ann の発見: Alex は会話の後半で記憶を失う、 でもユーザーが報告するまで気づかなかった。
解決策: Long Session Evals。 「10 ターン読み込ませて、 11 ターン目をテストする」。 これにより、 「長い会話での記憶喪失」 がテスタブルなバグになる。 自動テストの一部として組み込み可能。 「ユーザーが報告するまで待つ必要がない」 (08:40)。
Sub-agents — 「全コンテキストを 1 つに置かない」 (09:00 - 10:30)
Alex の最終的アーキテクチャ。 「重い仕事は別エージェントにオフロード」。
具体例: Search タスク。 「Alex が Arize のデータを検索する。 1 trace に数百 span、 複数 query、 中間推論。 全部 main 会話に居る必要はない」 (09:30)。
アーキテクチャ:
- Main agent: 軽量、 チャット + コンテキストのみ
- Sub-agent: heavy data を保持、 検索・処理を担当
- Main → Sub に delegate、 結果だけ pass back
- 必要に応じて memory store からも取得可能
これは Anthropic の Skills (Barry Zhang × Mahesh Murag) のアーキテクチャと並列。 「全部を 1 つに詰め込まず、 専門化された下位ユニットに分割する」 という業界の収束パターン。
Claude Code リーク事件 — 同じ戦略を独立発見 (12:57)
動画内の業界エピソード。 「Claude Code のコードが (2026 年初頭に) リークして、 皆が読めた。 我々は秘密が見られると期待した、 でも結果は 同じトランケーション + 圧縮戦略を使ってた」 (13:00)。 「自分たちの実装が業界トップと独立に同じ景色に到達した」 ことの (やや残念な) 確認。
これは、 Hinton/Sejnowski、 Karpathy、 Boris の独立した同概念到達と同じ構造的現象。 業界全体が 「現実の制約」 (= LLM のコンテキストウィンドウ + 推論能力) から、 同じ解決策に収束してる。
「Context engineering > prompt engineering」 (00:55 - 02:30)
動画の冒頭で Sally-Ann が引く Karpathy の 2025 年の X 投稿。 「プロンプトエンジニアリングよりコンテキストエンジニアリング」。
Sally-Ann の独自の定式化: 「最良のコンテキスト戦略は、 エージェントが必要なものを覚えて、 不要なものを忘れる戦略」 (02:30)。 「『何文字までならフィットするか』 ではなく、 『戦略的に何を見せるか』」 (02:00)。 これは Karpathy の概念を、 Product Manager 視点で運用化したフレーミング。
関連記事
- Granola: 一発で決めようとするな — 同じ Code Summit、 内製トレーシングツール
- Trigger.dev: 耐久性のあるエージェント — 同じ Code Summit、 状態管理の別側面
- Karpathy: Software 3.0 — 「context engineering」 概念の起源
- Anthropic Skills — Sub-agent と並列のパターン
- Raindrop Agent Observability — Arize の競合 (?) 観測性プラットフォーム
重要な引用
- 「エージェントはプロンプトのせいで失敗するのではない、 コンテキストのせいで失敗する」 (14:00)
- 「最良のコンテキスト戦略は、 エージェントが必要なものを覚えて、 不要なものを忘れる戦略」 (02:30)
- 「コンテキスト管理はエンジニアリング問題ではなく、 プロダクト / UX 問題」 (03:30)
- 「データを分析するシステムが、 そのデータに制約されてしまう」 (04:30、 悪循環の核心)
- 「Context decides what the model sees、 Memory decides what survives」 (07:49)
- 「Long Session Evals — 10 ターン読み込んで 11 ターン目をテスト、 バグがテスタブルになる」 (08:30)
- 「Claude Code がリークした時、 我々は秘密を期待した、 でも結局同じトランケーション + 圧縮戦略だった」 (13:00)
- 「Summarization が機能しないのが意外だった、 一貫性のコントロールがない」 (06:30)
出典
Hierarchical Memory — AI Engineer 公式 (YouTube)
関連リソース:
用語集
- Arize
- AI 観測性プラットフォーム会社。 LLM アプリケーションのトレース、 評価、 デバッグツールを提供。 Arize Phoenix (OSS 観測性ライブラリ) と Arize Alex (AI エージェントハーネス) を開発。 Raindrop と並ぶ、 AI 観測性スペースの主要プレイヤー。
- Arize Alex
- Arize の AI エージェントハーネス。 自社の観測性プラットフォーム上で動く、 40+ スキル、 プロンプト最適化、 データ生成、 注釈などのワークフローを持つ。 Arize 自身が 「Alex を Alex で作る」 という再帰的開発で構築。
- Context Engineering (コンテキストエンジニアリング)
- Karpathy が 2025 年中頃に X で提唱した概念。 「プロンプトエンジニアリング」 (1 つの指示文を最適化) よりも、 「モデルに何を見せるかを戦略的に選ぶ」 ことが重要、 という業界全体の認識転換。 Sally-Ann の定式化: 「エージェントが必要なものを覚えて、 不要なものを忘れる戦略」。
- Smart Truncation + Memory
- Arize の Alex で採用された、 コンテキスト管理戦略。 (1) 会話の Head 100 文字 + Tail 100 文字を保持、 (2) 中間を切り取って memory store に保存、 (3) エージェント自身が必要に応じて memory から取り出す。 シンプルだが、 「エージェントに裁量を持たせる」 ことが決定的。
- Long Session Evals
- Arize 内で導入されたテスト手法。 「10 ターン読み込んで 11 ターン目をテスト」。 「長い会話で記憶を失う」 という出力を、 ユーザー報告を待つことなく自動テストできる仕組み。 LLM プロダクトの QA における新標準パターン。
- Sub-agent (サブエージェント)
- 「重い仕事を別エージェントにオフロード」 する設計パターン。 Main agent は軽量チャット、 Sub-agent は heavy data 検索・処理を担当。 結果のみ Main に返す。 Anthropic の Skills、 Claude Code、 Cursor などでも採用される業界の収束パターン。