Code w/ Claude Tokyo: Extended に参加してきました

はじめに

こんにちは（内出血などで壊滅的に汚かった何本かの足の爪が、やっと剥がれ落ちて綺麗になりつつある？って書いていて意味不明な）体育会系プログラマのymd2です！

めちゃくちゃ記事にするのが遅くなってしまいましたが、2026年6月11日に開催された Code w/ Claude Tokyo: Extended に参加してきました。 Anthropic社主催の、Claude Codeまわりのハンズオンイベントです。詳細は↓

公式サイト：https://claude.com/code-with-claude/tokyo-extended
ハンズオン教材：https://github.com/anthropics/cwc-workshops

感想としては一日中ひたすら手を動かす系のイベントで、ハンズオンが6本。「AIエージェントを作って・動かして・検証する」を、座学じゃなくて全部コードで体験させられる、というなかなかハードな構成でした（楽しかった）。

当日はもう怒涛のインプット量でほぼ「なんかわかったね」感だけで実質全く理解できていなかったため、後日ちゃんと自習して復習した結果も含めてご紹介させていただきます。

午前はキーノート、午後はひたすらハンズオン

午前はメインステージ（Founders stage）のキーノートとセッションをメインに参加しました。

というか内容よりもまずは会場について。会場は細部まで作り込まれていて、あのClaudeのノードロゴが壁一面に。ちなみにスタップの方にお聞きしたのですが、レイアウトやデザインなど含む会場設営についてAnthropic社から細部に渡る指示があったそうです。

Claude Codeの生みの親 Boris Cherny氏のオープニングキーノートから始まり、NTT・みずほ・メルカリのAIネイティブ事例など、登壇ラインナップがなかなか豪華。

個人的におおっとなったのが、Boris Cherny氏が「Claude Code はそもそもこの一通のSlack投稿から始まった」と、当時の実物のメッセージを出してきたところ。

ちょっと小さすぎて見えないですが、下記の書き出しから始まる投稿

I wanted to show off a new tool I've been hacking on, Claude CLI. I built it as a new standalone tool, separate from claude, from the ground up.

今もうなくてはならないインフラのようなツールが、社内のこの軽いノリの投稿から生まれたのか…と思うと、感慨深いです。

そして発表された新モデル Fable 5（Mythos / Fable）。蝶が"5"を象るビジュアル、生で見られてよかったです。ブログ記事を書いている7/1現在、明日Fableが再公開されるとのことなのでギリギリ記事が間にあったのではないか？

午後のハンズオン（6本）

ということで、ここからが本番です。開発者ブログということもあるのでハンズオン6本を順番に。それぞれ「何を作って」「何が起きたか」がはっきりしてるのが良かったので、ちょっと厚めに紹介します。

#1 How we Claude Code — 検証可能なReact

まずはこちらから 検証とは「実際に動かして、操作して、画面が何を表示しているか読む」こと で、コードを読むことでも内部実装を覗くことでもない、という思想から。

具体的には、各コンポーネントが data-verify-* という属性で自分の状態をDOMに吐き出す仕組みを用意。さらに window.__verify という構造化APIを生やして、manifest() / current() / runAll() を叩くと PASS / FAIL / BLOCKED が構造化データで返ってくる感じです。

<li data-verify-unit="TodoItem"
    data-verify-done="true"
    data-verify-label="牛乳を買う">

ポイントは、 人間もエージェントもCIも、この同じ判定を見る こと。フロントの「data → 描画」というギャップを、ここでまとめて埋めにいく発想が綺麗でした。純粋なロジックなら既存のテストツールで十分だけど、描画があるフロントには「表面を観測する層」が要る、という整理に納得。

なお、以降のハンズオン全般に言えるのですが、事前に用意されたプロジェクトを手元にcloneして実行するといい感じに動くのを見る、というほぼ準備された状態のハンズオンでした。そもそも 自分の状態をDOMに吐き出す仕組み や window.__verify などを用意・定義するのが難しいのですがその点はある意味Anthoropicが描く未来やデモのような色合いもあり省略された感じでした。そのため復習しようと思った次第。

#2 Ship your first Managed Agent — クラウドで動くエージェント

エージェントのループを 自分で回さない を体験するハンズオン。設定（モデル＋プロンプト＋ツール）をAnthropicに渡すと、クラウドの隔離コンテナでエージェントを動かしてくれる、という新しい仕組み（Claude Managed Agents）を触りました。

題材はSREエージェントで、7つのAPI関数（メトリクス取得・ログ検索など）を実装。エージェントが get_metrics みたいな custom tool を呼ぶと、手元のコードが応答を返すコールバック構造になっていて、70k行のログをgrepさせて「p99がこのデプロイ直後に悪化、原因はこのコミット」まで特定させる、という流れ。

ハマりどころは、セッションが ステートフル なこと。ツール結果を返すまで次に進めないので、返し忘れるとそこで止まる。「クラウドのエージェントは投げっぱなしじゃなくて、ちゃんと会話のキャッチボールなんだ」と体で理解できました。

#3 Agents that remember — 記憶を持たせる

「セッションをまたぐと記憶を失う金魚から始めて、45分で同僚にする」というキャッチーなハンズオン。記憶の仕組みを2つ足していきます。

memory store：セッションをまたいで読み書きする永続ファイル群。エージェントが ls / grep / read で普通のファイルとして扱う（ライブ・横断的）
Dreaming：過去の会話ログを読んで整理し直し、新しいstoreを書き出す非同期のバッチ処理（蒸留と表現）

実際手元で動かしたときに面白かったのは、エージェントが ただ記録するんじゃなくて「何を残すか」を自分で選んでいた こと。あるURLを「些末」と判断して、わざと保存しないなどの挙動をしていた点。さらに Dreaming が索引ファイル（_index.md）を自作して、相互リンクまで張って、後任エージェント向けの運用メモを残していたのも面白かったです。記憶って「全部録画」じゃなくて「要点をまとめる」が重要。

ちなみにこちらも、Claude Managed Agentsで用意されている仕組みになります。

#4 Evals for taste — 改善を数値で検証する

スライド生成エージェントを題材に、「プロンプト変えて良くなった気がする」をやめて、evalを回して数値の差分で確かめる ハンズオン。要はエージェント開発版のTDDといっても良いかと（TDDガチ勢には怒られそうですけど）

採点（grader）は2種類を使い分けます。

code grader：絵文字の数・文字数・フォントサイズを数える。速い・無料・決定的。でも測れることしか測れない
judge grader：レイアウトや配色をOpusが0〜5で採点。主観的な質を測れるが、遅い・ブレる・甘い（高得点に寄りがち→「全域を使え」とプロンプトで矯正していた）

そして一番面白かったのが、 もぐら叩き（Goodhartの法則） がevalでその場で可視化されたこと。「絵文字を減らせ」と指示すると絵文字は減るんだけど、今度はキャプションが小さくなって別の指標が悪化する。指標を目標にすると指標は上がるけど本来測りたかった質は外れていく、という古典が、スコアカードの数字で確認できました。目視レビューだけなら絶対見逃してたやつです。

#5 Tool, skill, or subagent? — 肥大化エージェントの分解

12ツール・3サブエージェント・ 402行のシステムプロンプト まで育ちすぎた在庫管理エージェントを分解するハンズオン。「一つ一つの追加は妥当だった。問題は全部足し合わさった結果」という、身に覚えのありすぎる話。

判断は3択を「コンテキスト窓を溢れさせない」軸で考えるとよいとのこと。

tool call：1関数・決定的（安い）
skill：必要なときに読む指示書（中くらい）
subagent：別のコンテキスト窓を持つ独立エージェント（高コスト）

においで嗅ぎ分ける smell test も実践的でした。「ツールが2kトークン超を返す？→コード実行にしろ」「プロンプトに"XをYの前に必ずやれ"と書いてる？→skill」「subagentの出力が数値1個？→subagentにするな」とか。

そして地味に響いたのが、 skillは「強制力」じゃなくて「参照資料」 という指摘。skillに書いたからといって毎回守るわけじゃなく、「ロードされるか × 従うか」の掛け算でしかない。絶対に守らせたいことは、skillじゃなくて常駐プロンプトかコードで弾く。結果、システムプロンプトは402行→15行、トークンは267k→8.6kまで落ちたのに、知識量は減ってない。「いつ載るか」が変わっただけ、という締めが鮮やかでした。

#6 Agent Battle — ClaudeがMinecraftを遊ぶ

最後は完全にお祭りでした。Minecraftのダイヤ採掘エージェントを AGENT = dict(model=..., system=..., skills=[...], mcp_servers=[...]) で構成する、ハンズオンで学んだ#1〜#5の全仕組みを1つのdictに集約したような内容で、会場の参加者がみんなでダイヤ採掘数を競うハンズオンでした。

まず衝撃だったのは、空っぽのプロンプト（system=""）で5分走らせても💎10個掘ってくること。種明かしをすると、

LLMは3D映像を見ていない。渡されるのは nearby_blocks（半径16ブロックを種類ごとに最寄り1個へ間引いた構造化テキスト 情報）。これはハンズオン#1の window.__verify と完全に同じで「世界→機械可読な状態→LLM」の構図。
ダイヤ採掘の専用ツールはなく、mine_block(name) 1個。中身はmineflayerの探索+歩行+採掘のラッパーで、面倒な低レベル作業はツール側が吸収。だから空プロンプトでも掘れる状況。

競技自体は「トークンあたり何個掘れるか」の効率勝負で、ここでもeval（リーダーボード）が効いてくる。きれいにハンズオンの全部がつながるような内容でした。

ちなみに、当日私は環境構築に手間取って終了間際にやっと初回試行ができた感じでした。。。。事前準備大事。。。

まとめ：6本を貫いていたもの

復習でまとめながら気づいたんですが、6本ぜんぶ実は同じことを違う角度で言っていたなと。

何を・いつ・どこのコンテキストに載せるか — tool / skill / subagent / memory、全部「メインのコンテキスト窓を溢れさせない」ための道具
世界 → 機械可読な状態 → LLM — window.__verify も Minecraft の nearby_blocks も、やってることは同じ「世界を決まった形のデータに変える契約」
生成 < 検証 — 作るより確かめる方が安い。だから「気軽に間違わせて、検証で囲い込む」
evalの定義が一番難しく、一番価値がある — 「何をもって成功とするか」を決める方が、動くものを作るより難しい

あとインフラとして用意された Claude Managed Agents はいいぞと。claude -p でやっていたような単純なタスクは簡単に置き換えられるなーという感触で、memory store/Dreamingが使えるので+αで使いやすいです。あと今のところ費用はAPIトークンだけっていうのもわかりやすくてGood!