本記事は、公開リポジトリと筆者自身のハンズオン体験に基づきます。
2026年6月11日、Anthropic の招待制イベント「Code with Claude: Extended — Tokyo」に参加しました（会場：Fairmont Tokyo）。
個人的な収穫は、「作るAI」と「検証するAI」をセットで触れたことでした。エージェントに仕事を任せる仕組みと、任せた仕事が壊れていないかを機械で確かめる設計。弊社（Elcamy）の運用保守・AIエージェント開発の実務にそのまま重なるテーマだったので、その目線で書きます。
会場は Founders / Builders / Workshops の3トラックが同時進行していて、私は Workshops メインで参加しました。登壇を聞くだけでなく、参加者が各自のPCでリポジトリを動かしながら学ぶ形式です。セッションは英語が中心で、見渡した印象では海外からの参加者が半数を超えていて、東京開催ながらグローバルなイベントに近い空気でした。
ワークショップは2日で8本ありました。本記事では、2本を紹介します。
ハンズオン教材はすべて公開リポジトリ anthropics/cwc-workshops にまとまっています。
- rightmodel/ — LLM評価スイートをモデル・推論パラメータ横断で回し、コスト効率のよい構成を探す
- agent-decomposition/ — 400行プロンプトの在庫管理エージェントを、スキル + コード実行 + callable_agents に分解する
- how-we-claude-code/ — AIと製品を作る3フェーズ（仕様化 → デザイン探索 → 実行時に検証できるReactアプリ）※参加
- ship-your-first-managed-agent/ —
agent.pyの7関数を埋めて、SREインシデント調査エージェントを動かす ※参加 - agent-battle/ — 45分でエージェント構成（プロンプト・スキル・MCP・モデル）を組み、ゲームボットの成績を競う
- agents-that-remember/ — セッションをまたいで記憶を失うエージェントに、メモリの仕組みを一段ずつ足していく
- eval-driven-agent-development/ — PPTX生成エージェントを評価スイートで採点しながら6段階改良する
- production-ready-agent/ — マルチエージェントのM&Aリサーチチームをチャット UI 付きで動かす
「エージェントに手を動かさせる話」と「動かした結果を確かめる話」を1日でセットにしたくて、太字の2本を選びました。
セッション1：Ship Your First Managed Agent
何をやったか
お題
深夜2時、PagerDutyが鳴る。checkout の p99 レイテンシが平常の10倍。あなたはいつもの手順を踏む——ダッシュボードを開く、ログをgrepする、デプロイ履歴を遡る、推測する、確認する、また繰り返す。40分後、ようやく見つける。誰かが N+1 クエリを仕込んでいた。
システムの運用保守で障害の一報が来たとき、最初の30分でやることです。ログを時間帯で絞り、直近のデプロイを並べ、両者を突き合わせる。この「40分」を肩代わりするエージェントを、自分の手で組み立てます。
題材は架空のECスタックのインシデント・ダッシュボード（Streamlit製）です。Metrics / Logs / Deploys の各画面は最初から動きますが、右側の「SREエージェント」のチャット欄だけがオフラインになっていて、これをオンラインにするのがゴールです。なお「深夜2時」はオンコール担当が叩き起こされるという設定で、教材のモックデータには UTC 表記のタイムスタンプ（後述の 14:32 UTC など）が使われています。
編集したのは ship-your-first-managed-agent/agent.py にある 7つの関数だけです。多くは Claude Managed Agents API の呼び出し1回ずつ——手元データで答える handle_tool はローカル実行（API呼び出しなし）、会話ループの stream_reply は送受信が複数回——で、合計しても約34行に収まります。中身を平たい言葉で並べるとこうなります。
- エージェントの人格を作る（モデル・指示・使える道具を決める）
- エージェントが動くクラウドの作業部屋を用意する
- 巨大なログをクラウドに預ける（作業部屋にマウントするため）
- 人格・部屋・ログを束ねて、1回の調査セッションを開く
- 質問を送り、エージェントから道具の要求が来たら答えを返す会話ループ
get_metricsなどの道具要求に、手元のデータから答える- 使い終わったセッションを片付ける（クラウド資源は実コストなので）
実装後、エージェントに指示。
「checkout の p99 が 14:32 UTC ごろ増えた。原因見つけて。」
エージェントは追加の指示なしで調査の段取りを組み、
- 自分のクラウドサンドボックスの中で
bashを起動し、約7万行（筆者の環境では約14.8MB）のログを grep して怪しい時間帯を絞り込み - こちら側のローカルツール（デプロイ履歴・差分の取得）を往復で呼び出し
- タイムスタンプを突き合わせて、原因コミットを特定しました
筆者が実行した際に返された回答の要旨は、次の通りです。
コミット
a3f9c21（14:31:18 UTC デプロイ、「order summary builder のリファクタ」）が、典型的な N+1 クエリを再混入させた。1本のバッチクエリが、注文ごとのループに置き換わっていた。p99 は直後の1分で約80msから約4秒へ跳ね上がり、DBプールの枯渇とともに悪化を続けた。修正は、このコミットを revert（取り消し）すること。
印象に残ったこと
Managed Agent の体験で、7万行のログは会話のコンテキストに流し込まれず、サンドボックス側の grep で完結します。それでいて、こちら側のローカルツールにも往復で問い合わせてきます。この「クラウドで自走しつつ、手元の道具も使う」という両面を自分で実装せずに済む点が、自前のエージェントループとの違いだと理解しました。
もう1つは回答の形式です。「デプロイ前は per-order のクエリ行がゼロ、デプロイ後に出現する」「WARN db_pool high utilization active=48/50 が出ている」と、ログのどの行が証拠かまで添えられていました。私が普段の障害対応で報告書に書くのと同じ形——時刻、証拠ログ、原因コミット、復旧手段——が指示なしで揃って返ってきました。ここは想像していた以上でした。
自社でどう活かすか
顧客システムの障害対応で時間を溶かすのは、ほぼ毎回「ログを追って原因の変更を特定する」工程です。今回エージェントがやったこと——ログを時間帯で絞り、デプロイ履歴と突き合わせ、証拠行つきで原因コミットを報告する——は、この工程と同型でした。模擬障害（架空のEC障害を再現した教材）とはいえ、現場利用のイメージが具体化したので、まずは社内の検証環境で、実際の障害ログを使って同じ構成を試すつもりです。導入判断で見るべきは精度よりも、報告に証拠ログが添えられているか——人間がそのまま裏取りできる形か——だと考えています。
セッション2：How We Claude Code
何をやったか
こちらは、AIと一緒に製品を作る流れを3つのフェーズで辿るワークショップです。アイデアを質問で深掘りして仕様にし（Phase 1）、4つのデザイン案をHTMLで起こして見比べ（Phase 2）、最後に「AIが実行時に検証できる」Reactアプリへ落とします（Phase 3）。
phase-3-verify では、各UI部品が自分の状態を画面（DOM）に機械可読な形で出力し、満たすべき条件をあらかじめ宣言しておきます。すると人間・AIエージェント・CIが同じ「検査」を使って、動いているアプリの正しさを確かめられます。
部品の状態表示をわざと1行消してみました。すると検査が一斉に赤くなり、「件数の合計が合わない」「部品Aと部品Bの申告が食い違う」と、どこが壊れたかを名指しで指摘してきました。
印象に残ったこと
壊した本人の私より先に、壊れた場所をアプリが知っている。テストの考え方としては知っているはずのことですが、「実行中のアプリ自身が自分の状態を申告する」形で動くところを見ると、理解の解像度が一段上がりました。これは教材を読むだけでなく、1行消して赤くなるところまで手を動かす価値があります。
もう1つ、この教材には必ず失敗する検査が1つ仕込まれています。「いつも全部グリーンの検査は信用できない」。鳴るか分からない火災報知器に意味はない、という思想が作りに焼き込まれていました。セッション1で見た「エージェントに仕事を任せる」方向と、ここで見た「任せた結果を機械で確かめる」方向は、別々のワークショップですが明らかに対になっています。
自社でどう活かすか
顧客向けにエージェントやアプリを開発・納品する立場としては、こちらのほうが直近の実務に効きます。納品したアプリの改修をAIに任せる場面は今後確実に増えますが、その際「壊していないか」を機械で確かめられる土台——状態を機械可読に出すUIと、必ず失敗する検査を含む検査群——があるかどうかで、任せられる範囲が大きく変わります。これは納品物の設計段階から仕込む話なので、次の案件のフロントエンド設計に取り入れたいと考えています。
まず試すならこれ
このイベントの最大の価値は、教材がすべて公開されていて、参加していない人も同じ体験ができることです。「面白かった」で終わらせず、目的別に試し方を案内しておきます。
Managed Agents に興味がある人
ship-your-first-managed-agent/ から始めるのがおすすめです。README に沿って依存関係を入れ、APIキーを設定して Streamlit を起動します。編集するのは agent.py の7関数だけで、所要時間は30〜60分です。ドキュメントを読んだだけの状態と触った後では、理解の質が変わります。
Claude Code 流の開発プロセスを知りたい人 how-we-claude-code/ を Phase 1 からどうぞ。特に phase-3-verify は、AIに改修を任せる時代の検証設計がコードで読めます。動かしたら、部品の状態表示を1行消して検査が赤くなるところまで試してみてください。
時間がない人 clone して agent_complete.py（完成版）だけ読むのでも、Managed Agents API の全体像は掴めます。各ワークショップの README を追うだけでも設計意図は分かります。
本記事では実装の詳細は省きましたが、リポジトリを開きながら読むと内容を追いやすいはずです。
