ローレンス・ジョーンズ / Lawrence Jones · 16:23 「File systems are exceptionally good agent context。 MCP を被せるよりも、 Computer Use エージェントを使うよりも、 全部 download して filesystem として渡すほうが圧倒的に効果的やった」
Lawrence Jones の AI Engineer Europe 2026 講演は、 production agent を本気で運用してる企業が直面する 「AI システムを人間が debug できなくなる問題」 への現場側の答え。 Incident.io の AI SRE 製品 Incident.io が 1.5-2 年かけて build してる Site Reliability Engineering の自動化製品。 incident response の一部から始まって、 production investigations の完全自動化を目標にしている。 1 回の investigation で hundreds-thousands の prompts が走る複雑系で、 logs / metrics / traces / 過去 incident data を cross-reference してコードベースまで踏み込む。 顧客は Netflix、 Etsy、 Skyscanner など は、 1 回の investigation で hundreds-thousands の prompts と多段 agent が連動する複雑系。 これを 「production が動いている間に評価し、 改善する」 ための内部ツール設計が、 本講演の中身。
MEMEX 編集視点で重要なのは、 これが Laurie Voss (Arize) の Ship Real Agents での 「eval architecture」 議論を、 1 つの製品チームが 1.5 年かけて構築した実装例 として完成させていること。 そして Hugo Santos × Madison Faulkner の CI/CD is Dead での 「agent 並列実行」 議論が、 backtest 分析という別側面で具現化している。
Eval は AI unit test ── でも production eval は壊れる
Lawrence の整理: 「Eval は AI unit test や。 prompt を取って、 input 与えて、 output 出して、 grading criteria で pass / fail を決める」。 Incident.io では YAML ファイルとして Go の prompt 隣接に置く。 prompt 変更前に 「これが本当に意図通り動くか」 を proven にする仕組み。
早い段階で作ったのが 「production から eval を盗む」 ボタン。 AI 挙動が おかしくなった瞬間に、 そのケースを download して eval suite に追加できる。 ただし問題発覚: 「production eval は良い eval ではない」。 ideal な unit test は focused で 「これを試したい」 が明確やのに、 production case は incident report 全部 (megabytes 級の YAML) を持ち込んでしまう。 結果、 coding agent が context limit を即 overflow して eval suite を扱えなくなる。
解: eval-tool CLI — agent が eval suite を 「test cases 一覧」 「特定 case の編集」 「追加」 「置換」 のような API で操作できる小さなツール。 これと runbook (= skill) を組み合わせると、 coding agent に prompt の問題を投げるだけで自動的に: (1) 失敗 eval を追加 → (2) prompt を修正 → (3) eval pass まで反復 → (4) 既存 eval が壊れてないか full suite 再走 → (5) prompt を consolidate (肥大化防止)、 という TDD red-green サイクルを agent が自走する。 これは Pedro Rodrigues (Supabase) の skill 設計 3 原則 での 「opinionated workflow を skill に encode せよ」 の現場実装。
UI をダウンロードできる filesystem に変える ── 最大の unlock
講演で最も重要な insight がこれ。 Incident.io の 1 つの chatbot interaction の背後には 10 + agents、 50 + prompts、 数百 tool calls が並ぶ。 investigations 系はさらに巨大で、 1 つの調査が 100s-1000s の prompts に展開される。 これを debug するための trace UI Incident.io が内部で構築した、 hundreds-thousands の prompts と tool calls を人間が辿るための UI。 各 prompt の input / output、 tool call の連鎖、 sub-agent の hierarchy を可視化する。 ただし complexity が agent 並みになると、 人間がこの UI を辿る時間が現実的に確保できなくなり、 agent 自体に debug を任せる必要性が出てきた を最初は人間用に作ったが、 規模が agent サイズになると人間の時間が物理的に足りなくなる。
Anthropic が Claude Code 出した時、 「agent が filesystem + bash tool に異常に強い」 ことが明らかになった。 Lawrence のチームの判断: 「じゃあ全 UI 情報を filesystem として download できるようにしよう」。 trace、 prompts、 tool calls、 sub-agent hierarchy、 全部 markdown / text として 1 つの sandbox 化された Claude Code に渡す。 すると agent は self-documenting な構造を辿って、 codebase まで cross-reference して、 「ここの prompt を こう直せ」 まで提案できる。
「MCP 被せるより、 Computer Use 使うより、 半分も効果が出なかった」 と Lawrence は言い切る。 filesystem こそが 2026 年現在で agent に渡せる最強の context。 これは Barry Zhang × Mahesh Murag (Anthropic) の skills = フォルダの思想 と完全に一致する現場知見。 「ASCII で表現できるなら、 trace でも UI でも、 agent に届く」。
Backtest pipeline ── 数千 investigation を並列分析
3 つ目の軸が backtest 分析パイプライン。 Incident.io は数百顧客アカウントで毎日数千の investigation を回す。 「accuracy 86%」 という数字は出るが、 上がった / 下がった理由が分からないと改善できない。
解: 「Scrapbook」 という repo で構造化分析パイプラインを構築。 Claude Code で実行され、 markdown playbook が agent の手順を規定する。 重要設計:
- 25 sub-agents 並列起動 ── 各 investigation を個別に分析、 「失敗の種類」 「改善できる点」 を出す
- Cohort clustering 段階 ── meta level で 「同じ種類の失敗」 をクラスタリング、 1 顧客アカウント全体の傾向を整理
- 段階的にファイルとして保存 ── どこで止まっても resume 可能
- Codebase 統合 ── 問題発見時に 「コードのこの部分を こう直せ」 まで agent が提案、 そのままその session で実装 + eval red-green で検証
これは Hugo Santos × Madison Faulkner の CI/CD is Dead での 「agent 並列実行が PR を serialize する CI を壊す」 という議論の、 evaluation 側での具体例。 25 agents が並列で 1 顧客分の analysis を作り、 cohort 段階で集約する構造は、 microservices-with-agents の典型。
編集所見 ── 「内部ツールこそ AI 化せよ」
この講演を MEMEX で取り上げる視点は 3 つ。
(1) Production agent 運用の reference 実装。 Incident.io は 1.5-2 年かけて 「AI SRE をスケールさせる方法」 を実証してきた最も成熟した例の一つ。 eval-tool CLI、 filesystem-as-context、 backtest pipeline の 3 点セットは、 同様の複雑性に直面する全 AI 製品チームのテンプレートになる。
(2) AI セキュリティ防御側の最前線。 「Fighting AI with AI」 のタイトルは、 incident response という domain の特性 — つまり攻撃 / 失敗を AI で検知し、 AI で対応する — を端的に示す。 これは Anthropic Project Glasswing での 「LLM がサイバー脆弱性を悪用できる」 警告と表裏一体。 attacker 側の AI 化が進む 2026 年、 defender 側の AI 化が同等速度で進まないと均衡が崩れる。 Incident.io はその defender 側の最前線。
(3) 内部ツール = 第二プロダクト、 という組織論的シフト。 「内部ツールを agent ready に書き換える」 は単なる効率化やなく、 開発組織の architecture そのものの再定義。 これは Mike Spitz (PFF) の post-engineer engineering org や Brian Scanlan (Intercom) の 9 ヶ月 2x と通底する、 「organize your environment for agents」 という思想の現場具現化。
動画の構成
- (00:00) 自己紹介 ── Incident.io の AI SRE 製品の規模感
- (01:30) 「good / bad report の区別」 が人間には tractable やない理由
- (03:30) 既知の構成要素 (prompts / evals / scorecards / traces / datasets / back tests)
- (04:00) Eval = AI unit tests、 YAML 構造、 production からの 「steal an eval」
- (06:40) Production eval が壊れる理由 ── context overflow
- (07:30) Eval-tool CLI + runbook = agent が prompt を自走改修
- (09:00) ChatBot の真の複雑性 ── 10 + agents、 多階層 sub-agents
- (11:00) UI を filesystem に変換する unlock の話
- (12:30) 「Filesystem こそ agent に最強の context」
- (13:00) Backtest analysis の問題 ── 「86% accuracy」 では改善できない
- (13:30) Scrapbook ── 25 sub-agents 並列 + cohort clustering pipeline
- (15:00) PR を agent が自動 propose する flow
- (16:00) 締め ── 「Internal tools こそ AI 化せよ」
- (17:00) Incident.io is hiring