Code w/ Claudeで発表されたことすべて

• Anthropicの開発者カンファレンス: オンラインとオフラインで実施され、オフラインイベントは サンフランシスコ 5/6、ロンドン 5/19、東京 6/10 に開催。サンフランシスコ会場では 19本のセッション 動画が公開された
• Claudeは より長い作業の実行、長期メモリ、より多くのツール利用、より良い検証 の方向へ進化中
• 中核的な変化は、開発者が自前で作っていた 反復実行、ツール選択、検証、メモリ、コンテキスト管理 がClaudeの製品とプラットフォームの中に取り込まれつつあること
• 製品や組織の差別化は、モデルをどう呼び出すかよりも、モデルに どのツール、データ、権限、コンテキスト を開放するかへと移っている
• コードを書くこと自体よりも 検証、セキュリティ、権限管理、可観測性、評価体系、組織運営 が新たなボトルネックとして大きくなっている
• 今後重要になる領域は カスタムツール、信頼できるメモリ、評価、セキュリティ境界、コンテキストエンジニアリング(context engineering)、エージェント作業環境(agent experience) である

セッション 1 - キーノート

• Claude Code と Claude Platform を開発者にとってよりうまく機能させる製品改善に焦点が当てられた
• ほとんどのユーザーはClaude APIやターミナルを直接使うのではなく、開発者が作った製品の中でClaudeを利用している
• Claude Platform API利用量 は前年と比べてほぼ 17倍 増加した
• Claude Codeの平均的な開発者は 週あたり20時間 Claudeを実行している
• Claude Codeの 5時間利用上限 がPro、Max、Team、seat-based Enterprise plansで 2倍 に拡大された
• Claude Opus API上限 も大幅に引き上げられた
• SpaceXのColossus Oneデータセンター の容量を活用し、個人開発者や小規模チームにより多くの計算資源を提供しようとしている
• Opus 4.7 はAmp、Rakuten、Intuitでコーディングエージェントの性能、計画品質、実際のエンジニアリング作業の解決率を高めた
• 今後のClaudeは より良い判断力、より大きなコンテキストとメモリ、複数エージェントの協調 に向かって進む

セッション 2 - What's new in Claude Code

• Claude Codeの新機能は 開発者の使いやすさ と 自律性の強化 という2つの軸でまとめられる
• Remote Control はターミナルで開始したセッションをWebやモバイルで引き継げるようにする
• Full screen terminal UI は仮想スクロールバックを使い、ちらつきのないレンダリングとクリック可能なツール呼び出し画面を提供する
• Claude Code GUIは複数セッションをピン留め、フィルタリング、グループ化、分割画面で管理できるように変わった
• plan view、diff view、files viewでは行単位のコメントを残し、Claudeが後でまとめて処理できる
• Auto Mode はツール呼び出しが破壊的か、プロンプトインジェクションのように見えるかを分類したうえで、安全なら権限確認なしで実行する
• ワークツリー(worktree) は複数のClaudeセッションがそれぞれ隔離されたブランチとファイルのコピー上で並列作業できるようにする
• 自動メモリ(auto memory) はClaudeがプロジェクト別の memory.md と関連ファイルを管理し、ビルドコマンド、デバッグの手がかり、プロジェクトの好みを次のセッションでも再利用する
• Routines と /loop はcron、GitHub webhook、APIトリガーでClaude Codeセッションを自動実行させる

セッション 3 - Memory and dreaming for self-learning agents

• Memory はMCP、Claude Code、Agent SDK、Skillsに続く次の基本要素として扱われた
• Claude Managed Agents のメモリは ファイルシステムのように構成 され、ClaudeがBashとGrepで直接整理・更新する
• Opus 4.7 は何を保存するか、ファイルをどう分けるか、メモリ構造をどう維持するかをより的確に判断する
• 複数のエージェントが同じメモリストアを読み書きできるよう、読み取り専用の組織メモリ と 読み書き可能な作業メモリ を分けられる
• 何百ものエージェントが同時にメモリを変更しても上書きしないよう、コンテンツハッシュベースの楽観的同時実行制御 を使う
• 変更履歴、作成主体、セッション、時点 を残し、企業環境で監査可能なメモリとして管理する
• Dreaming は最近のエージェントセッションとトランスクリプトを非同期に分析し、繰り返されるミス、成功パターン、重複メモリ、古いメモリを見つけて整理する
• Harvey は Dreaming を法務ベンチマークに適用し、ある法務シナリオの タスク完了率を6倍 に高めた
• SREデモでは、複数のエージェントが個別には見落としていた60秒の再試行パターンを Dreaming が見つけてメモリに反映した
• 目標は、今日のエージェント作業が明日のエージェントを自動的により良くする 継続学習の構造 である

セッション 4 - Caching, harnesses, and advisors: Building on Claude at GitHub scale

• GitHub Copilot規模では プロンプトキャッシング がコストとレイテンシを下げる中核手段になる
• 目標キャッシュヒット率は 94-96% で、70%水準 はプロンプト組み立てやキャッシュ設計に問題がある兆候とみなす
• システムプロンプトとツール一覧の前半は、可能な限り静的に保つべき
• UUID、時点、動的ツールロードが前半に入るとキャッシュが壊れやすい
• 複数モデルをまたぐ ハーネス(harness) でも、Opus呼び出しが以前のキャッシュを再利用できるようキャッシュ親和性を保つ必要がある
• GitHubは新モデルを オフラインベンチマーク、内部利用、A/Bテスト、オンライン評価(eval)、リリース後最適化 の順で回している
• Advisor戦略 は安価な実行モデルが大半の仕事を担い、重要な判断が必要なときだけOpusをアドバイザーとして呼ぶ構造である
• モデル自体よりも プロンプト、ツール、キャッシュ、モデル選択、評価、オンラインフィードバック を束ねた運用レイヤーが品質とコストを左右する

セッション 5 - The expanding toolkit

• 昨年は自前で作っていた 補助コード が、今ではモデルとAPIの中に含まれつつある
• ツール利用では 手動ルーター や リトライデコレータ の価値が下がっている
• Claudeが自らツールを見つけ、失敗したツール呼び出しを見て復旧し、その後再び呼び出せる
• ツール案内には入力だけでなく 出力スキーマ も書いておくほうがよい
• 出力構造を事前に分かっていれば、Claudeは不要な往復呼び出しなしで結果をより活用できる
• Claude Codeの 事前/事後ツールフック(hook) は特定の呼び出しを防いだり、結果を自動記録して分析したりするのに使える
• 100万トークンのコンテキスト、サーバー側圧縮、コンテキスト編集 により、長時間作業のコンテキスト管理が単純になる
• 古いスクリーンショット、検索結果、ファイル読み取り結果は定期的に削除しても、それらが生んだ判断は維持できる
• Opus 4.7 は最大 1440p まで、元の解像度のスクリーンショットから 1:1ピクセル座標 を返し、画面自動化における座標補正の負担を減らす
• モデルの限界を補うコードの寿命は短く、Claudeが見られない ツール、データ、認証、ドメインコンテキスト をつなぐコードが長く残る

セッション 6 - How to get to production faster with Claude Managed Agents

• Claude Managed Agents は、長時間実行される本番運用エージェントに必要な コンテキスト管理、認証情報管理、セキュリティ、アクセス制御、人によるレビュー、可観測性 をプラットフォームとしてまとめたもの
• 基本構成は agent configuration、environment、session
• session events では、ユーザーイベント、エージェントイベント、セッションイベント、区間イベントを確認できる
• Console は設定、環境、実行全体のトレース（trace）、ボトルネック、推奨アクション を1画面に集約
• outcomes は、あらかじめ定めた終了条件と採点基準を満たすまで Claude に反復させる機能
• 複数エージェントのオーケストレーション、メモリ、Dreaming も高度な機能としてあわせて扱われる
• ダッシュボードのデモでは、agent が並列化、fast mode、プロンプト最適化を見つけ、レンダリング時間を約37秒から10秒に短縮
• 本番運用エージェントには、モデル呼び出しのループだけでなく トレース、ボトルネック分析、権限、検証 もあわせて備わっている必要がある

セッション 7 - A conversation with Dario Amodei & Daniela Amodei

• Anthropic は、想定を上回る 利用量と売上の成長 により計算資源が不足している
• 追加の計算容量 を確保し、開発者とユーザーにより多く提供しようとしている
• 開発者は Claude の中核的なユーザーであり、AI が経済全体へ広がっていく様子を最初に示す集団として位置づけられている
• Claude Code の次の変化は、個人の生産性 から チームと組織の生産性 への移行
• コードを書く速度が速くなるほど、セキュリティ、検証、信頼性、保守性 が新たなボトルネックになる
• モデル能力が急速に変化することで、数カ月前には不可能だった製品が突然可能になる
• API 市場は今後も重要
• これからの Claude は、1人の作業を支援する水準を超えて、組織全体にわたる複数人と複数エージェントの仕事 を拡大する方向へ進む

セッション 8 - Live coding session with Boris Cherny and Jarred Sumner

• Bun の Robobun は GitHub issue を自動で再現し、テストを含む PR を作成する
• 以前のバージョンでは失敗し、修正ブランチでは通る条件 を PR 提出の基準にしている
• CLAUDE.md は、ビルドコマンド、テストコマンド、テストの場所、過去の失敗パターン、フォルダ構造、CI ログの読み方を含む、エージェント運用ドキュメントになる
• CodeRabbit、Claude Code Review、Robobun を併用し、スタイル、CLAUDE.md 準拠、diff 外の境界条件レビューを自動化する
• Claude Code と Opus 4.7 は、目標、測定方法、検証の反復 が明確なとき、性能を段階的に引き上げる作業に向いている
• ボトルネックは コード記述 から 計画と検証 へ移る
• agent が作成した PR は、必ずマージすべき成果物ではなく、レビュー可能な提案として扱える
• agent PR が増えても、人間のマージ基準は下がらず、むしろ上がる可能性がある

セッション 9 - Building with Claude Managed Agents and Asana AI teammates

• Asana の AI teammates は、企業内で実際の同僚のように働くエージェントを目指している
• エージェントは actor となり、承認、ワークフロー、複数段階の業務を人とともに処理する
• 多くの企業におけるエージェント利用は、まだ1人が結果を受け取り次の人へ渡す単一ユーザーフローにとどまっている
• Asana は、複数人が同じエージェントと相互作用し、知識とメモリが蓄積される共同作業フローを志向している
• Asana work graph は、目標、ポートフォリオ、プロジェクト、タスク、承認、過去の意思決定をつなぎ、エージェントのコンテキストとして使われる
• AI teammate は、共有設定、ロールベースアクセス制御、監査可能性 を備え、人間の同僚のようにシステムへ入る
• Claude Managed Agents は、キャンペーン企画書の作成 や HTML ランディングページのモック生成 といった複数段階の作業を処理する
• Asana は人向けインターフェース、企業コンテキスト、セキュリティ、監査可能性に注力し、Claude Managed Agents は検証の反復、採点器、outcomes、複数エージェント実行を担う
• 21個以上 の事前構築済み AI teammates が、PMO、マーケティング、IT、HR、R&D 業務向けに提供される
• フィードバックはエージェントのメモリに残り、次のユーザーが同じミスを繰り返さないようにする

セッション 10 - Running an AI-native engineering org

• AI-native エンジニアリング組織 では、コード作成のスループットが最も高価なボトルネックではなくなる
• 検証、レビュー、セキュリティ、保守、職種横断の調整 が新たなボトルネックとして大きくなる
• 6カ月のロードマップや全作業前の設計文書よりも、適切なタイミングで計画し素早くプロトタイプを作る流れが Claude Code チームに合っている
• 技術的な議論は、長いホワイトボード討論より 複数の実装 PR を作って実際の影響と API の形を比較する方向へ変わる
• コード生成が容易になったぶん、テスト、自動化、より早い検証がさらに重要になる
• 「誰がこのコードを書いたか」よりも、回帰の原因、専門家の回答が必要かどうか、コンテキスト確保の目的を見分けることのほうが重要になる
• Claude Code チームは、スタイル、lint、PR フィードバック、一部バグ修正とテスト追加を Claude に任せている
• 法務レビュー、セキュリティに敏感なコード、信頼境界、プロダクト感覚 は引き続き人間の専門家が見る
• 採用では単純なスループットより、プロダクト感覚のある創造的なビルダー と 深いシステム専門性 をより重視する
• 成功指標は、オンボーディング時間の短縮、PR サイクルの短縮、Claude の支援を受けたコミットの増加 で見られる

セッション 11 - Building AI-native: Inside the stacks powering Cognition, Gamma, and Harvey

• Gamma は、ツール呼び出しとエージェントのオーケストレーション改善を素早く製品に反映し、エージェントベースの編集フローを強化している
• Gamma は MCP connector を統合機能としてだけでなく、顧客流入と業務フローへの入り口として活用している
• Cognition は、モデルがコード編集、ファイルシステム利用、長時間実行計画をよりうまくこなせるようになったことで、自前の計画・メモリシステムの一部を縮小している
• Harvey は、foundation model、推論モデル、コーディングエージェントの変曲点ごとに製品構造を再設計している
• Harvey の現在のプラットフォーム能力は、agent-native な構造でなければ得にくかった
• AI-native 製品は、6〜12カ月以内に既存構造が古くなりうることを前提にすべき
• 記録、可観測性、再生、評価 は、急速な構造変化に対応するための必須の仕組みになる
• 法務のようなセンシティブな分野では、公開データ、非公開データ、メモリ、エージェントフローの間に堅牢なデータ境界が必要
• 特定モデルの限界に合わせた構造より、次の能力ジャンプを素早く吸収できる構造が重要になる

セッション 12 - Architecting for model step-changes: A fireside with Vercel's Guillermo Rauch

• Vercel はエージェント型インフラを中核的な方向性と見ている
• クラウドは自律的に復旧し、最適化し、設定を変更するインフラへと拡張できる
• AI Gateway はトークン向けの CDN のようなものとして扱われる
• 複数のプロバイダーとモデルを扱い、ルーティング、障害対応、コスト制御を担うレイヤーになる
• Opus トークン は使用量の比重より支出の比重のほうがはるかに大きく、高知能モデルを製品に組み込む際はコスト構造を明確に見る必要がある
• Opus 4.5 導入後、V0 は以前のモデルを補正していた文法チェック、自動修正、一部の処理手順を簡略化できた
• モデル能力の飛躍は、新機能の追加だけでなく既存の補正コードを削除する変化にもつながる
• V0 で Opus の利用を拡大した後、製品クレジット支出が 2 倍に増えた
• 今後は CLI と UI ベースの開発だけでなく、非同期で人の監督が少ないエージェントがさらに拡大する可能性がある

セッション 13 - The thinking lever

• テスト時点演算(test-time compute) は、Claude が推論中により多くのトークンと時間を使って難しい問題を解く軸である
• 同じ Opus 4.7 でも、low、high、max の effort によって交通シミュレーションの品質が大きく変わる
• より多くの時間とトークンを使うほど、グラフィック、交通の流れ、車両の動きがより現実的に変わる
• Claude が使うトークンは、思考トークン、ツール呼び出しトークン、テキストトークンに分かれる
• 思考トークンは内部推論、ツール呼び出しトークンは外部世界との相互作用、テキストトークンはユーザーとのコミュニケーションに使われる
• effort は時間、コスト、品質のバランスを表す調整レバーである
• Task Budgets は、Claude が特定の作業で使えるトークン、時間、コストの上限を設けられるようにする
• 適応的思考(adaptive thinking) は、Claude が必要な瞬間に考え、ツールを使い、ユーザーに答える順序を自由に選べるようにする
• coding と agentic use case では extra high がよいデフォルト値として扱われる
• 単純な大量分類や抽出には小さなモデルが有利で、知能が必要な作業をすばやく終わらせるには大きなモデルの低い effort のほうが向いている場合がある

セッション 14 - How Datadog built a universal machine tool for Claude Code

• Datadog エンジニアの約 90% が本番コードに AI コーディングツールを使っている
• そのうち 少なくとも 2/3 は Claude Code を使っている
• AI コーディングツールの利用範囲は、個別関数、テスト、接着コードからシステム単位の作業へと広がっている
• ボトルネックはコード作成から、フィードバックの反復と本番検証へ移っている
• Helix 実験では、Claude Code が Kafka に似たストリーミングサービスを数日で作ることができた
• 本番環境に持ち込むには、shadowing、検証の階段、システムマイレージが必要である
• Tempor は、エージェントが即興でツールを作るのではなく、状態、遷移、効果、不変条件を盛り込んだ設計図をまず作るようにする
• 遷移表、ポリシー文、型付き効果、検証器、プロパティテスト が、エージェントの作ったソフトウェアを検査可能にする
• agent に自由を与えるには、本番システムの不変条件と検証手順を機械可読にする必要がある

セッション 15 - Building with Claude on Google Cloud

• Google Cloud で Claude Code を設定する最も簡単な方法として、Application Default Credentials ベースの設定ウィザードが使われる
• 設定ウィザードは project、region、利用可能な model を検出して固定できる
• Google Cloud で Claude model を使うと、トークンベース課金、provisioned throughput、API key ローテーション負担の軽減、project ポリシーの適用、project 内でのデータ保持、regional/global endpoint を活用できる
• デモは、PM、UI/UX designer、software engineer、security engineer、data/growth marketer という 5 つの役割が 1 つのフィードバックアプリを最後まで作る流れで進む
• PM は手描きの wireframe を Claude Code に入れてすばやくプロトタイプを作る
• UI/UX 段階では、plan mode で Claude に実装前の計画を先に出させる
• Google Cloud developer knowledge API と MCP server は、最新ドキュメントとアーキテクチャ案内を Claude Code に接続する
• Google Cloud Skills は、Cloud Run API デプロイ、Cloud Run と Firestore の接続のような個別ブロックの実装を助けるために使われる
• sub-agent を使って API、収集パイプライン、ダッシュボード実装を並列で進める
• security review prompt は OWASP の問題や service account 権限を確認し、見つかった問題を修正したうえで Cloud Run にデプロイする

セッション 16 - Getting more out of the Claude Platform

• 本番向けエージェント最適化の優先順位は プロンプトキャッシュ、コンテキストエンジニアリング(context engineering)、Advisor 戦略である
• プロンプトキャッシュ は入力トークンコストを減らし、最初のトークンまでの時間を短縮し、キャッシュ済みトークンの利用上限負担を下げる
• キャッシュヒット率は 90%台 が目標として扱われる
• 先頭部分のプロンプト安定性、ツール定義の位置、動的値の挿入位置がいずれもキャッシュに影響する
• ツール検索ツール(tool search tool) は、必要なツール定義だけを適時に読み込んでコンテキストを節約する
• すべてのツールを最初から入れると、コンテキストとキャッシュの両方に負担が大きくなる
• プログラマティックなツール呼び出し(programmatic tool calling) は、多数のツール結果をそのまま入れず必要な断片だけを選んでコンテキストに入れる
• 圧縮(compaction) は古い会話とツール結果を縮めて、長い作業を継続できるようにする
• Advisor 戦略 は、Sonnet や Haiku が大半の作業を行い、重要な判断が必要なときだけ Opus をアドバイザーとして呼び出す
• 重要なのはモデルをより多く呼ぶことではなく、どのようなコンテキスト、ツール、キャッシュ構造でモデルを働かせるかを設計することである

セッション 17 - Evaluating and improving Replit Agent at scale

• Replit Agent のユーザーは、framework や test を指定せず、自然言語だけで動作するアプリを期待する
• 一般的なコーディングベンチマークのように、パッチがテストを通過したかだけでは Replit Agent の品質を測りにくい
• 評価では、アプリがユーザーの要求どおりに動作するかを見る必要がある
• Replit は オフライン評価 と オンライン評価 を併用している
• オフライン評価は新しい agent release 前の関門となり、オンライン評価は実際の利用後にすばやく対応するために使われる
• VibeBench は 20 個の実際の PRD を入力として空のリポジトリからアプリを作り、自動評価器がブラウザでアプリをテストする公開ベンチマークである
• ほとんどのモデルは、自分が作ったコードをさらに拡張するときのほうが苦手である
• 機能の間にテストと検証段階を置くことで、不安定な基盤の上に積み上げ続けることを減らせる
• Telescope は、本番実行トレースを意味ベースで束ねてロングテール障害を見つけ、問題を分類し、agent が PR を作成し、VibeBench または A/B テストで検証する内部システムである
• 評価は最後のリリース確認表ではなく、エージェントを日々改善する エンジン になる

セッション 18 - The capability curve

• Claude Code のユーザーは、昨年よりも大きな信頼を持って、より速くデプロイしている
• 発表中の参加者投票では、多くの参加者が Claude によって10倍、5倍、2倍の速度向上を実感していると回答した
• SWE-bench Verified では、Sonnet 3.7 は約 62%、Opus 4.7 は 87% を記録した
• Opus 4.7 は、Sonnet 3.7 が失敗していた難しい PR を成功させられる可能性が 3倍以上高くなった
• 同じプロンプトで Claude.ai を再現するデモでは、以前のモデルは一般的なチャット UI とエラーを出した一方、Opus 4.7 は Claude の色、API レスポンス、チャット履歴、インライングラフィック、dark mode を実装した
• 改善された領域は 計画、エラー復旧、長時間の実行中に注意を維持すること である
• 新しいモデルはまず計画を立て、失敗すると戻ってやり直し、長いコンテキストでもシステムプロンプトと目標をよりうまく維持する
• 実際の改善を見るには、製品に近い分布の評価を作る必要がある
• モデルが良くなるほど既存の評価は簡単に飽和するため、評価も継続して難しくしていく必要がある
• 新しい frontier model が出たら、既存の補正手順とプロンプトをあらためて減らせないか試してみる必要がある

セッション 19 - Giving coding agents their own computers: How Cursor built cloud agents

• Cursor は、ボトルネックはモデルの知能よりも、人がモデルに十分なツール、コンテキスト、大きな目標を与えられていない点にあると見ている
• 人間の開発者をオンボーディングするように、エージェントにもコンピューター、開発環境、ドキュメントを与えるべきである
• Cursor の onboarding agent はリポジトリを探索し、アプリの実行方法、サービス、環境変数、権限を把握する
• AnyDev CLI は、エージェントがサービスを起動し、準備完了を待ち、状態を確認し、テストアカウントの作成やログインまで処理できるよう支援するツールである
• エージェント向け開発環境が良くなるほど、開発者はより多くの cloud agent を実行し、より大きな作業を任せるようになる
• 自律性の基本原則は、エージェントに目、ツール、良いコンテキストを与えることである
• エージェントは人間のように、アプリの状態、他のエージェントとの会話、サービスの状態を見られる必要がある
• Cursor は computer use を、コーディングに続く重要な基本要素と見なしている
• Claude 4.7 は、agent が自ら end-to-end デモを録画して機能を検証し、人間がコードレビュー前に結果を素早く理解できるようにする
• Cursor は agent experience を別個の設計対象と見ており、エージェントが煩わしい、壊れている、または混乱するフローに遭遇した場合は work on the factory イシューとして残すようにしている
• 最終目標は、人間が A から D まで手で導くことではなく、A から Z まで解決できるシステムを作ることである