VS Code でエージェントを「料理」する — Liam Hampton (Microsoft) が示す 3 種エージェントの使い分けと awesome-copilot エコシステム (AI Engineer Europe 2026)

AI Engineer Europe 2026 (London) / 約 17 分

リアム・ハンプトン / Liam Hampton · 04:24 「VS Code を AI エージェントの単一の入口 (single entry point) にする。 third-party、 background、 local、 remote ── 全部ここから。開発者がどこに座ってるかを理解して、認知負荷をどこまで下げられるかを設計してる」

AI Engineer Europe 2026 (London、 2026/04 開催) 単独セッション、約 17 分。講師は Liam Hampton (Microsoft Developer Relations、 GitHub Copilot と VS Code を担当)。「エージェントがチャット窓、 CLI、ターミナル、他社エディタなどあらゆる場所から飛び出してくる時代」に対し、 VS Code を単一の制御面に据える戦略を 1 codebase × 3 同時稼働エージェントの demo で示す。講演中盤で公開された awesome-copilot OSS リポジトリは、ユーザー側の skill / instructions / prompts / hooks / MCP servers を集約する actionable 資源として提示される。

Liam Hampton の AI Engineer Europe 2026 講演は、「Tejas Kumar (IBM) が問題定義した harness の認知負荷」を、 Microsoft 製品サイドからどう吸収するかという positioning talk になっている。講演冒頭で Liam は前のセッション (Tejas の harness 講演) を引いて「エージェントがあちこちから出てくる、 cognitive load の話は absolutely correct」と認めたうえで、「だからこそ VS Code を入口に一本化する」という提案を組み立てる。 Microsoft が Marlene Mhangami の Playwright MCP 講演と同じ AI Engineer Europe 2026 ステージに 2 人の DevRel エンジニアを送り込み、「14 倍急増する commit」「Cursor / Windsurf 等との単一入口競争」という 2 軸を抑えに来ている事実が、 Microsoft の AI 戦略の輪郭を示す。

MEMEX 編集視点で重要なのは、これが Microsoft の宣伝枠でありながらも 「3 種類のエージェントを ROI 観点で使い分ける」 という業界横断の概念フレームを提示している点。 GitHub Copilot 専用の話に見えて、 Liam 自身が「これは Copilot 以外の AI agent にも全部 applicable」と複数回明言する。つまり Anthropic Claude Code、 Cursor、 Windsurf 等を使う開発者にとっても、「local / background / cloud をどう仕分けるか」の思考整理として読める。

ROI 不安と「one-shot 信仰」への現場反論

Liam が冒頭で整理する業界の構造的問題:

「one-shot で素晴らしいアプリが作れる」という developer 側の幻想 ── 講演で Liam は「私は今でもこう信じている開発者と話す、 absolutely not the case」と明言
経営側からの ROI 問い詰め ── 「これだけ AI infrastructure と tooling に投資して、 productivity boost はどこに?」という質問の頻発
Token 支出への警戒 ── Liam が引用するのは LinkedIn 経由で前日 viral になった「海賊風プロンプトリポジトリ」 ── chatbot に海賊風に喋らせると token 消費が減るという観察が viral 化

この前提整理は Intercom が 9 ヶ月で 2x 達成や PFF の 2 ヶ月 25x deploy といった実証例と表裏。「実証側」が数字を出している一方で、「未到達側」では one-shot 信仰と ROI 不安が共存している。 Liam の提案はその gap を「3 種エージェントの使い分け + 単一入口」で埋める設計論。

3 種類のエージェント ── 関与度合いで仕分ける

講演の概念的中核。 Liam はエージェントを「開発者がどれだけ hands-on で関わりたいか」で 3 段階に分類する:

種別	関与度	適した task	実装場所
Local agent	100% hands-on、 human-in-the-loop	Test 作成、 weeds に潜る作業	VS Code 内、ローカル機 (Claude / Copilot / 自前 LLM 含む)
Background agent	50% (やりとり半分、任せる半分)	フロントエンド UI 等、中規模で時間のかかる作業	GitHub Copilot CLI、 git worktree 上の隔離フォルダ
Cloud agent	ほぼ hands-off	ドキュメント生成、 OSS 化、 README 作成	GitHub Actions 上、ネットワーク firewall 内

Liam 自身の使い分け宣言: 「test は自分で見たいから local、 front-end UI は arduous で時間食うから background に任せる、ドキュメントは hate するから cloud に丸投げ」。 ROI の正体は「人間が見るべき部分に時間を集中させる」こと、という整理。これは Ali Abdaal の Claude Code 入門での「自分が嫌いな業務から AI に渡せ」という business creator 視点と通底する。

Git Worktree が background agent を可能にする

Liam が demo で前提として説明するのが Git Worktree 。「ブランチが workspace 内のサブディレクトリにマップされたもの、自分のコードのチョップ (chop) に独自ブランチが紐づく」と平易に説明する。

Background agent は worktree 上で動くため、メインの作業ディレクトリを上書きせずに UI の生成を並行できる。これは Anthropic Applied AI チームの long-running agent 設計での「fresh context window で毎回 starts」「永続 artifact を真の記憶として使う」という思想と同じ方向性を、 Microsoft / GitHub 側が worktree という低レイヤ Git 機能で実装している形。「 git clone より軽量、 docker より統合容易」という中間解として位置づけられる。

Autopilot mode ── 「危険な便利」を意識的に使う

GitHub Copilot CLI の background agent には現在 preview 状態の Autopilot mode がある。 Liam の率直な紹介: 「great, wonderful, can be very dangerous。本番で abuse するなよ」。

Demo での運用例は示唆的で、 Liam は autopilot を有効にしつつも「plan は autopilot で進めろ、ただし pull request を作る前に必ず停止して、ローカル test 方法を教えろ」という instructions を入れる。つまり 「自律性 100% は避けて、 critical な分岐点で human-in-the-loop に戻す」 という設計。これは Pedro Rodrigues (Supabase) の skill 3 原則での「opinionated になれ」と同じく、 agent の autonomy を設計者が意識的に制約する思想と通底する。

Demo ── 1 codebase × 3 同時稼働エージェント

講演の核心 demo は、同じ Python CRUD アプリ (Product Store) に 3 種の問題を 3 種のエージェントで同時並行で解決する流れ:

Background agent (Copilot CLI + autopilot) ── GitHub Issue #25 を読んでフロントエンド UI を git worktree 上で構築。「pull request を作る前に停止しろ」と instructions、ローカル test のため
Cloud agent ── 「このリポジトリを OSS-friendly にして、 README + contribution guidelines を追加しろ」と丸投げ。 GitHub Actions 上で実行される
Local agent ── VS Code 下部の chat picker で local + Claude Opus 4.6 (発言内では「Claudio plus four six」、 medium reasoning) を選択。 custom agent 「Test 書き手」が事前定義されているのを使って unit test を生成。 test が走った後、「エラーハンドリングが汚い、ついでに直せ」と to-and-fro

Liam の重要なメタ視点: 「これは speed up していない動画、全部このスピードで動いた」。 1 名の開発者が 3 種のエージェントを同時にオーケストレーションし、それぞれの完了状況を VS Code 上で確認しながら次の作業に進む。「1 つのコードベース、 3 つの問題、 3 つの別エージェントが同時に解決」が、 cognitive load を実用的に抑えながら multi-agent 並列を実現する 1 つの prescription として提示される。

最後のセクションで Liam は worktree ディレクトリに切り替えてフロントエンド UI を実際に起動。 port conflict が出て少し慌てつつも、元の地味な CRUD から見栄えのする product demo へと変わった画面を見せる。この「目に見える成果」の demo は Microsoft のマーケティング技術として効いているが、一方で 「multi-agent 並列の operational reality はこうやって port を踏むことから始まる」 という現場の生っぽさも残っている点が、単純な vendor pitch から外れている。

Cloud agent の仕組みと安全装置

Liam が Q&A 想定で先回り説明するのが cloud agent の中身。「GitHub Actions の中で走る、 isolated environment で safe」。

拡張 context は MCP server 経由 ── GitHub MCP server と Playwright MCP server を組み合わせて、ドキュメント生成 + screenshot 取得 + 自動 front-end test まで実装できる
ネットワーク firewall でホワイトリスト制限 ── エージェントが任意のサイトに通信するのを抑止
Main ブランチへの直接 push 不可 ── PR 経由のみ、安全装置が built-in

この設計は Intercom が Claude Code 全社展開で hundreds の laptop に internal cloud plugin を push out したようなエンタープライズ deployment の現実と接続する。 Intercom は自前で deployment 機構を作ったが、 GitHub Copilot cloud agent は同じ問題を「GitHub Actions × MCP × firewall」の 3 点セットで packaged 解にしている。「自分で build するか、 Microsoft の packaged を使うか」の選択肢を提示する位置取り。

VS Code 内の chat customization 制御面

Demo の後半で Liam が画面で示すのが、 VS Code の GitHub Copilot chat pane の歯車アイコンから開ける「単一ユーザー space の制御面」。ここで一覧 + 編集できる項目:

Agents ── 自分が書いた custom test agent + built-in の ask / explore / plan
Skills ── 「PR コメント対応」「PR 作成」等の組み込み skill、 jump in して編集可能
Instructions ── 全 session で適用される指示
Prompts ── プロンプトファイル、 skill 起動用も可
Hooks ── event-driven 自動化
MCP servers ── 接続済みの全 MCP servers が一覧

重要な政治的観察: 同モーダルには Claude (Anthropic) の plugins / hooks / instructions / skills も表示される。 Liam の言葉で「VS Code と GitHub Copilot に restrict されない」。 Microsoft が VS Code を自社 AI のロックイン装置にせず、 Claude や他社 AI tool もここから設定できる stance を取っている。これは Cursor / Windsurf 等の「独自エディタ」競合に対し、「VS Code は中立 platform」という positioning を強める動き。

awesome-copilot OSS リポジトリ ── アクションアブルな共有資源

講演中盤で Liam が紹介する awesome-copilot リポジトリ (aka.ms/awesome-copilot)。これが Microsoft 戦略の中で最も興味深い動き ── 「GitHub Copilot の skill / instructions / hooks を community で集めて OSS で配る」。

Liam の発言の重要部分: 「これは Copilot を direct したものだが、 absolutely not just for Copilot。 massage して他の AI tooling 用にも使える。我々はコミュニティが Microsoft Things と GitHub Things 以外も使っているのを知っている」。つまり Microsoft 自身が自社製品縛りを公式に外している。これは Pedro Rodrigues (Supabase) の Skill や Anthropic 公式の Skills 思想と整合し、「skill / instructions は中立 asset」という業界共通認識への合流を Microsoft が選んだ証拠。

さらに awesome-copilot 自身が MCP server としても encapsulate されている。 workflow から MCP 経由で skill を取りに行ける、という meta な構造。これは Stephen Chin (Neo4j) の context graph や Lawrence Jones の AI SRE で見られる「すべてが MCP 経由で agent から見える化される」という業界トレンドの 1 piece。

着眼点

(1) 「VS Code = 単一入口」戦略の競争構図

Liam が締めで明言する「Visual Studio Code is a single entry point for AI agents」は、 Microsoft の AI tooling 戦略の中核 thesis。 Cursor、 Windsurf、 Zed、 JetBrains AI Assistant 等が並ぶ AI エディタ競争に対し、「VS Code を 1st-party + 3rd-party + background + local + remote の全 agent の唯一の制御面にする」という positioning。 Anthropic Claude のプラグインも同モーダルから設定できる stance は、「Microsoft 製品ロックインじゃなくて中立 platform」という主張を補強する。これは Anthropic と Microsoft の $30B Azure コンピュート提携と表裏で、 Microsoft が Claude を Azure に乗せると同時に、 VS Code にも乗せる二重戦略。

(2) 3 段階エージェント分類の業界横断的な価値

Local / Background / Cloud の 3 段分類は GitHub Copilot 限定の話に見えて、実は agent の 関与度合いを ROI 観点で整理する universal な mental model。 Claude Code も同じ構造を持つ (terminal の対話モード = local、 Claude Code on PR via GitHub Actions = cloud、 sub-agent 並列 = background)。 PFF の post-engineer 組織や Spotify の Honk V2 でも、結局は「どこまで人間が関与するか」で agent 配置を変えている。 Liam の 3 段分類は、これを開発者個人レベルの 1 日の使い分け方として言語化した形になる。

(3) Token economics への民衆的工夫の象徴

Liam が引用する「海賊風プロンプト」リポジトリの LinkedIn viral 化は、 token 経済がユーザー側の bottom-up 工夫の対象になり始めた象徴。これは Claude の利用量 80 倍急増や Azure $30B コンピュート枠といった infrastructure 側の話と裏返しの現象。開発者は token 制約を「与えられた予算」として受け入れ、創造的な回避手法を生み出し始めた。これは AI 経済が成熟した証拠でもあり、同時に Microsoft のような vendor が awesome-copilot のような共有 OSS で best practices を集約する正当性も生む。

動画の構成

(00:00) 自己紹介、 GitHub Copilot + VS Code 利用者の手挙げ確認
(00:30) Tejas Kumar の harness 認知負荷話を引用、「absolutely correct」
(01:15) ROI 問い詰めと one-shot 信仰、 token 支出への警戒
(01:40) LinkedIn 経由の「海賊風プロンプト」 viral 引用
(02:20) 3 種類のエージェント ── local / background / cloud 紹介
(03:00) Git Worktree の解説、手挙げ確認
(04:00) 各エージェントの ROI 別の使い分け方
(04:40) 「VS Code = single entry point」 thesis
(05:30) Demo 開始 ── Python CRUD アプリの紹介
(05:50) Issue #25 を CLI background agent + autopilot に投入
(06:45) Cloud agent に OSS 化 + README 生成を依頼
(07:40) Local agent (Claude Opus 4.6 medium reasoning) + custom test agent で unit test 生成
(08:30) エラーハンドリング修正の to-and-fro
(09:15) 3 agent の完了確認、 PR 拡張で background agent の結果を視認
(10:20) git worktree 経由でフロントエンドを起動、 port conflict 解決
(11:30) Cloud agent の中身解説 ── GitHub Actions、 MCP、 firewall、 main ブランチ保護
(12:30) Copilot 以外にも applicable、 custom agents / instructions / prompt files / skills / agents.md
(13:20) VS Code 内 chat customization モーダルの実演 ── Claude 等の 3rd-party もここから
(14:50) awesome-copilot OSS リポジトリ (aka.ms/awesome-copilot) と MCP server 公開
(16:00) 締め: 「VS Code は AI agent の single entry point」

出典

「Cooking with Agents in VS Code」 ── Liam Hampton, Microsoft (AI Engineer Europe 2026, London)
awesome-copilot OSS リポジトリ (aka.ms/awesome-copilot)
GitHub Copilot 公式
Visual Studio Code 公式

リアム・ハンプトン

Liam Hampton

Microsoft Developer Relations / GitHub Copilot + VS Code 担当

VS Code でエージェントを 「料理」 する — Liam Hampton (Microsoft) が示す 3 種エージェントの使い分けと awesome-copilot エコシステム (AI Engineer Europe 2026)

ROI 不安と 「one-shot 信仰」 への現場反論