1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

【イベントレポ】Code with Claude Tokyo 2026 で学んだAIエージェント開発の最前線

1
Posted at

2026年6月11日、東京・Fairmont TokyoでAnthropicが主催する開発者イベント「Code with Claude Tokyo 2026」が開催されました。

セッション・ハンズオン・デモブース・Anthropicチームとの1on1オフィスアワーと盛りだくさんな内容でしたが、この記事では技術的に特に印象に残った内容をまとめていきます。

今日の結論を3行で先にお伝えすると:

  1. 仕事は「コードを書くこと」から「AIがうまく働ける条件を整えること」へ移った
  2. エージェントは"作る"段階から"運用する"段階へ。実行基盤・記憶・評価・セキュリティの部品が揃った
  3. AIエージェント投資の前に、業務コンテキストとデータ基盤の整備が成否を分ける

Session 1: How we Claude Code — 長時間稼働エージェントと働く3つの技法

Anthropicのエンジニア、Jason Schwartz氏による講演です。割り勘アプリ開発を題材に、Claude Codeをより効果的に使う3つのテクニックを紹介してくれました。

① 曖昧さの除去 — コードを書かせる前にインタビューさせる

プロンプトの違いが最初の1時間を大きく左右します。

プロンプト 結果
「割り勘アプリを作って」 仕様不足。エージェントが勝手に方向を決め、1時間気づけない
「このアプリを人に使われるものにしたい。ターゲットも含めてブレストを手伝って」 コードを書く前にエッジケース・想定ユーザ・未知事項が洗い出される

AskUserQuestionツールを使って、エージェント自身に仕様の曖昧さをインタビューさせるのが効果的です。

② 計画書はMarkdownではなくHTMLで書かせる

"HTML plans are easier to read — and capture more of the model's thinking"

Markdownだと箇条書きになりがちで、優先度・フロー・構造が見えにくい。HTMLで出させると人間のレビュー精度が上がります。

「レビューしない計画は計画ではない」 という言葉が印象的でした。

③ 検証の組み込み — "Verification is not just testing"

  • Build for it from the start(作りながら検証を考える)
  • Modularize by verifiability(独立に検証できる単位でコードを分ける)
  • Verify across the stack(unit / integration / visual / behavioral)

デモでは14件のテストが全部パスしているのに、UIが壊れているという衝撃的な状況を見せてくれました。テストは「誰かが書いた範囲」しか守らない。エージェントはグリーンを信じて出荷してしまいます。

解決策: 検証コントラクト

  • コンポーネントが状態をDOMに刻印(data-verify-*属性)→ 描画結果が機械可読になる
  • Claudeにverify spec(fixtures+invariants)を書かせる
  • ハーネスが毎回同じ方法でルールを自動チェック

"The work is no longer writing the code. The work is setting up the conditions in which the code gets written well."

Session 2: Claude Managed Agents — 本番エージェントのインフラが揃った

「本番投入を10〜15倍速くする」と銘打った新サービスです。タスク・ツール・ガードレールを定義すれば、残りはAnthropicが運用してくれます。

従来との比較

方法 自分で管理するもの Anthropicが管理するもの
Messages API エージェントループ・ツール実行・状態管理・認証・監視すべて トークン入出力のみ
Agent SDK ホスティング・スケール・状態管理・認証・監視 ループ・キャッシュ・ツール実行・リトライ
Managed Agents(NEW) タスク+エージェント設定+カスタムツール(MCP / Skills)だけ 実行基盤・状態管理・認証・Vault・スケール・監視すべて

3つの基本リソース

/v1/agents       → 人格と能力。モデル・システムプロンプト・ツール。バージョン管理され不変。
/v1/environments → 実行環境。コンテナ設定・ネットワーク制限。一度作れば使い回し。
/v1/sessions     → Agent×Environmentで対話を起動。イベントをストリーム受信、いつでも再開。

"The brain left the box" — アーキテクチャの革新

従来は「頭脳(ループ)」と「手(ツール実行)」が同じコンテナに同居していました。Managed Agentsはこれを分離しています。

BEFORE: セッション毎に1コンテナ
[Agent loop + ツール実行(同居)]
→ クラッシュすると全部消える。スケールも非効率。

NOW: 分離(DECOUPLED)
[THE BRAIN: Agent loop(Anthropic管理)] ⇄ [THE HANDS: サンドボックス(オンデマンド起動)]
→ 1サービスで数千セッション。ツールが必要な時だけ隔離コンテナが立ち上がる。

セッションはイベント駆動で、user.messageを送るとagent.messageagent.tool_useがSSEストリームで返ってきます。状態機械で管理され、会話はクラウドに永続化されます。

ハンズオン: SREエージェントを実際に構築

「深夜2時、決済のp99レイテンシが10倍に跳ねた」というシナリオで、agent.pyの7つの関数を順番に実装するだけで障害調査エージェントが完成しました。完成後は「レイテンシ急騰の原因は?」という問いに対して、クラウドサンドボックスで7万行のログをgrepし、メトリクスとデプロイを突き合わせて問題のコミットを特定してくれました。

Session 3: Agents that remember — Memory Store と Dreaming

セッションは使い捨て(記憶喪失)が前提でしたが、記憶の「保持」と「整理」が独立した部品として登場しました。

Memory Store

ファイルシステム型の永続ストア。セッションにリソースとしてマウントすると、エージェントが読み書きして記憶を持てます。2つのセッションに同じストアをマウントすれば記憶を共有できます。何を覚えるかはprompt欄で制御します。

Dreaming(非同期記憶整理)

過去の会話履歴とストアを読み、蒸留した記憶を新しいストアへ書き出す非同期バッチ処理です。人間の睡眠中の記憶整理と同じ発想。

運用フロー:

  1. ストアを作りエージェントに装着
  2. 週次でDreamingを回す
  3. 出力ストアを次のセッションに差し替え

Consoleで「エージェントが何を覚えたか」を人間が確認・比較できる点もガバナンス面で重要です。

本番化のための部品群(すべてBeta)

機能 説明
Subagents エージェントが他のエージェントを起動・指揮
Memory コンテナにマウントされる永続メモリ
Outcomes rubricで採点し自動で反復改善
Vaults ユーザ毎の認証情報を安全に管理
MCP servers リモートツールサーバーを接続
Webhooks セッション状態変化を通知(ポーリング不要)
Permission policies always_askで人間の承認を必須化

セキュリティ面で印象に残ったこと

Vault: APIキー・OAuthトークンはVaultに保管され、コンテナ内には入りません。通信が外へ出る瞬間にAnthropicのプロキシが注入する設計なので、エージェント自身も鍵を読めない = プロンプトインジェクションで漏れない。

サンドボックス実行: ツールはセッション毎の隔離コンテナで実行。Agent loopとも分離されており、コード実行の影響範囲が閉じます。

デモブースの「ハードゲート」: 自律エージェントが「スクリーンショットを実際に読むまでテストを合格にできない」制約付きで数時間自走していました。エージェントの自己申告を信用せず、検証を機械的に強制する設計はリスク管理の考え方と合致します。

野良パッケージへの注意: サードパーティ製パッケージはサプライチェーン攻撃の入口です。インストール前にスキャンするSDK/ツールの導入を推奨、とのオフィスアワーでのアドバイスも印象に残りました。

Session 4 & 5: ビジネス活用から見えた共通の結論

Tsukumo Labsの講演と、30日間・878セッション・コード0行というClaude Code活用事例の講演から共通して見えた結論です。

大企業AIプロジェクトの失敗率は80〜95%(MIT・RAND調査)。

失敗の核心は業務コンテキストの欠如です。

「AIエージェントに投資する前に、データ基盤に投資せよ」

特に印象的だったのが「ボトルネックは思考時間ではなく、材料集めの時間だった」という言葉。BigQueryだけでは「CV+20%」という数字しか出てこないが、SlackとGA4を組み合わせると「特定セグメントに効いている。その顧客は事前にコンテンツAを読み、Slackでも課題Bの認識が共有されていた」という文脈と因果が結びつく。

エージェントが力を発揮する3条件:

  • パイプライン自動化
  • メタデータ管理
  • データ品質監視

また、エージェント開発の評価についても重要な示唆がありました。PoCを始めるときは、まず評価データと合格基準を作る。「動いた」ではなく「合格した」で進める。

まとめ

セッション キーワード
How we Claude Code 曖昧さ除去・HTMLプラン・検証コントラクト
Managed Agents brain/hands分離・3リソース・イベント駆動
Memory & Dreaming 永続ストア・非同期記憶整理
Security Vault・サンドボックス・ハードゲート
ビジネス活用 データ基盤・Eval・業務コンテキスト

ワークショップ資料は github.com/anthropics/cwc-workshops で全公開されています。Python 3.10+とAnthropicのAPIキーがあれば追体験できます。


Managed Agentsはまだβですが、SREエージェントなどの実務ユースケースには十分使えそうな印象でした。特にVaultとサンドボックス実行の設計は、セキュリティを重視する現場でも安心して導入できる基盤だと感じています。次はManaged Agentsのハンズオンを自分でも試してみたいと思います!

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?