はじめに
プラットフォーム開発本部 第4開発部の中尾です。
直近は、AI/LLMを活用したプラットフォームエンジニアリングによって、DMMポイントクラブを開発しているグループの生産性を向上する取り組みを進めています。
2026年6月10日、Anthropic 主催の開発者イベント Code w/ Claude Tokyo に参加してきました。
※この記事は、当日のセッション要約ではありません。一参加者として会場で何を感じ、どう考えを巡らせたかを残したものです。記憶が熱いうちに、自分の思考を整理しておきたくて書いています。
イベントについて
Code w/ Claude は、Anthropic が世界各地で開く開発者向けイベントです。サンフランシスコ、ロンドンに続く 3 都市目で、東京開催は今回が初めてだったそうです。Claudeに関するアップデートは主に3つの分野で発表がありました。
| トラック | 内容 |
|---|---|
| Research | モデルの能力と伸び方、選び方 |
| Claude Platform | 本番で動くエージェントの設計・運用 |
| Claude Code | 長期タスクやマルチリポジトリなど実務寄りの話題 |
今回のイベントで私が聴講したのは下記の9セッションです。Anthropic の Research と Platform、楽天・サイバーエージェント・メルカリ・NRI といった国内企業の組織変革の事例、そして Canva の大規模プロダクト事例を中心に回りました。
- Opening keynote - Anthropic
- Memory and dreaming - Anthropic
- Inside Canva AI - Canva
- AI-assisted から AI-delegated へ - サイバーエージェント
- Autonomy × empowerment - 楽天
- Running an AI-native engineering org - Anthropic
- business-task benchmarks - NRI
- The capability curve - Anthropic Research
- human-on-the-loop - メルカリ
結局、何を AI に任せるのか
先に、一日を通して残った結論を書きます。
会場にいる間、ずっと頭を離れなかった問いがあります。「結局、何を AI に任せるのか」です。
参加前の私は、もっと手前の話を想定していました。新しいモデルは何ができるのか。Claude Code をどう使いこなすか。他社はどうしているのかが知れたら良い、という温度感でした。
ところが会場で次々と見せられたのは、その先でした。先進的に取り組む企業はもう「どの AI を使うか」では話していません。「組織として何を AI に任せ、その成果をどう資産にするか」を語っていました。投資の軸が、ツール選定から委任の設計へ移っている。これが、一日を通じた一番大きな実感です。
そして、どの企業も最初から正解を持っていたわけではありませんでした。AI の進化を追ううちに「重要なもの」が移り変わり、各社の発表はその気づきの跡として聞こえました。以下、私がどうこの結論にたどり着いたかを、順を追って書きます。
提供する側と使う側が、別々の入り口から同じ方を向いていた
最初に感じたのは、立っている場所の違いでした。
AI を提供する Anthropic と、AI を使う事業会社。両者のフォーカスは明確に違います。Anthropic は、使う側が面倒に感じる設定やセキュリティ、監査を肩代わりするサービスを広げていました。一方の利用企業は、表現も対象も違うのに、どこも「AI をどう上手く動かすか」に集中していました。
不思議だったのは、入り口が違うのに行き先が重なって見えたことです。提供する側と使う側が、別々の方向から同じ課題ににじり寄っている。そんな感覚が、セッションを聞くほど強まっていきました。
そしてその「同じ課題」が、さっきの問い、つまり委任の設計でした。気づけば私は、各社の発表を「この会社は何を、どこまで AI に任せようとしているのか」という目で聞くようになっていました。
いちばん刺さったのは「業務を評価している」という一言だった（NRI）
委任の話で最初に腑に落ちたのは、NRI のセッションです。正直に言うと、この日いちばん刺さりました。
認定リセラーとして 100 件以上の実装を重ねた経験から、登壇者はこう言い切りました。
我々はモデルを評価しているのではない。業務を評価している。
出典: NRI「How NRI picks models with business-task benchmarks」（Code w/ Claude Tokyo, 2026）のスライドを筆者撮影。公式ページは末尾の参考リンクを参照。
聞いた瞬間、自分の中で順番が入れ替わりました。私はずっと「どのモデルが優れているか」を気にしていました。でも本当に問うべきは「自分たちの業務に、どのモデルが合うか」だったのです。
Claude が NRI のベンチマークで勝ち続けた理由も、納得感がありました。「日本語が上手い」からではありません。1000 行を超えるような大量の業務指示を一度に汲み取り、最後まで破綻なくやり切る。幾重もの条件を取りこぼさず読み解き、例外と前提を切り分け、長い手順を一貫してやり切る。この三つが揃って初めて、業務を任せられる。エンタープライズで効くのはここなのだ、と腹落ちしました。「指示の数が増えても破綻しない」ことが Claude を選んだ理由だ、と説明されていました。
出典: NRI「How NRI picks models with business-task benchmarks」（Code w/ Claude Tokyo, 2026）のスライドを筆者撮影。
eval（AI に業務タスクを与え、出力を採点する評価データ）の運用も具体的でした。本番のトラフィックに合った eval を作る。新しいモデルが満点を取るようになった eval は、もう何も測れていないので作り直す。そして新しいモデルが出るたびに測り直す。eval は一度作って終わりではなく、回し続けるもの。この姿勢が強く残りました。
ここで私は、委任には順番があると気づきました。任せるには、まず評価できる状態が必要です。評価するには、業務を言語化しないといけない。「何を任せるか」の前に「何を言語化し、どう測るか」がある。セッションの終盤ではこう語られていました。
どこまでモデルに任せられるかというのを測るためには、業務を言語化する、評価できるような形にする、っていうのを、繰り返していくしかない。
この出発点こそ、いちばんの収穫でした。
大規模 AI プロダクト運用で重要になるのは評価とコスト設計（Canva）
評価とコストの話でもう一つ手応えをくれたのは、Canva のセッションです。この日唯一、数千万ユーザー規模で AI プロダクトを動かしている事例でした。
刺さったのは、競争優位の源泉が E2E の評価だと言い切ったことです。印象的だったのは、次の言葉です。
今日編み出された賢いハーネスは、明日にはデッドコード（無用なコード）になる。
モデルが進化するたびに、制御の作りも一から組み直す。一方で評価の資産は残り続ける。だから評価に投資する。使い捨てになるものと、積み上がるものを切り分けていた点が鮮やかでした。
コスト管理の話も具体的でした。価値があったのは三つ。ターンごとに予算の上限を設けること。外れ値のターンがコストの大半を食うからです。タスクに応じてモデルを賢く振り分けること。複雑なら Opus、単純な編集なら Sonnet に回します。そして実コストを社内に見える形で出し、計測に投資する文化を作ること。コスト削減とターンへの影響の関係を見ながら、ちょうどよい落としどころを探る、という進め方でした。
出典: Canva「Inside Canva AI」（Code w/ Claude Tokyo, 2026）のスライドを筆者撮影。
こうした大規模運用の知見は、インターネット上にあまり出てきません。聞きながら「ここだけでも来た甲斐があった」と素直に思いました。
全自動化ではなく、人がどこで止めるかの設計だった（メルカリ・サイバーエージェント）
AI-native と聞くと、全工程の自動化を思い浮かべていました。国内事例を聞いて、その思い込みが崩れました。むしろ逆で、人がどこで止めるかをあらかじめ設計に組み込んでいたのです。
メルカリのセッションでは、社内プロジェクト「Project Double」の歩みが紹介されました。2025 年 7 月に 1 人で発足し、Agent Spec 駆動開発（ASDD）を社内標準として提案。そこから SDLC 全体へ広げ、2026 年現在は 20 人規模で開発体制ごと作り直しているそうです。
途中の自問が、いちばん誠実に響きました。
Claude Code に Plan Mode が実装された今、内製で ASDD に投資し続ける意味はあるのか？
ある標準に投資した瞬間、その標準は陳腐化する。このジレンマを、隠さず壇上で口にしていたのが良かったです。メルカリの答えは、完全自動化ではなく協業の設計でした。自律できる業務は human-on-the-loop で任せ、判断が要る領域は human-in-the-loop で人と AI が協業する。人の頭の中でしか起きない判断は人が持つ。この線引きが、自社の言葉で語られていました。
ここで私は、自分の仕事に引き寄せて考えました。Coding Agent や仕様駆動の開発が進むと、ボトルネックは実装から上流へ移ります。これは AI が進化すれば、どの組織もいずれぶつかる変化です。そのとき、どこに人の手を残すか。自分の現場ではどう線を引くだろうか。そんなことを考えながら聞いていました。
出典: メルカリ「Toward human-on-the-loop」（Code w/ Claude Tokyo, 2026）のスライドを筆者撮影。
出典: メルカリ「Toward human-on-the-loop」（Code w/ Claude Tokyo, 2026）のスライドを筆者撮影。
同じ「人と AI の境界」を、もっと仕組みの話に落としていたのがサイバーエージェントのセッションです。なかでも Context Engineering の実践例が具体的でした。
常に読み込ませる前提は最小限にとどめる。設計原則やアーキテクチャといった共通ルールはルールファイルに置き、複数のエージェントから参照させる。個別の知識は Skills や Subagent に切り出し、外部の情報は MCP 経由で必要なときだけ取りに行かせる。常時適用するルールは絞り、関連ファイルが文脈に入ったときだけ発火させる。こうして「prompt の上手い個人」に頼るのではなく「同じ文脈が選ばれる仕組み」を組織の標準にしていました。context は有限資源で、足すほどかえって精度が落ちる、という割り切りが明快でした。
出典: サイバーエージェント「From "AI-assisted" to "AI-delegated"」（Code w/ Claude Tokyo, 2026）のスライドを筆者撮影。
聞きながら、これは DMM社内での運用にもそのまま通じる話だと思いました。誰か一人の prompt 力に依存している限り、AI の力はその人の範囲に閉じる。文脈を組織の資産にして初めて、組織として効いてくる。一番持ち帰りたいセッションの一つになりました。
任せた成果を「資産」として積み上げる発想（楽天・Anthropic）
委任の話は、最後に「資産」という言葉に収束していきました。
楽天のセッションは、聞いている間は正直、抽象的に感じました。肝心なところは企業秘密なのかもしれません。それでも持ち帰りの四点ははっきりしていました。コストと完了率を併せて見るタスクセットで評価すること。真の天井はモデルではなくワークフローの再設計にある、と見極めること。メモリを使って、リリースごとの改善を企業の資産として複利で積み上げること。そして残った制約を自省すること。前提として、エージェントの価値は「自律化（どこまで自律的に動けるか）」と「エンパワーメント（どこまで広い業務で使えるか）」の二軸でスケールする、という見立てが置かれていました。
出典: 楽天「Autonomy × empowerment」（Code w/ Claude Tokyo, 2026）のスライドを筆者撮影。
真の天井の話では、こう言い切られていました。
モデルの限界を決めるのは、主にワークフローの設計であって、モデルのインテリジェンス（知能）ではない。
なかでも「コストと完了率の二軸」と「メモリの複利」は、他社にない切り口として残りました。任せて終わりではなく、任せた成果をメモリとして積み上げ、エージェントを企業の資産に変えていく。楽天はこれを「AI-nization」と呼んでいました。
この「資産化」を、AI を作る側の自己運用として裏づけていたのが Anthropic のセッションです。AI を本格的に取り入れると、計画の進め方、コードの所有者、コードレビュー、チーム構成、知識共有といった旧来のプロセスが静かに壊れるといいます。減らしたのは「コードの前にまず設計ドキュメント」という儀式。逆に倍賭けしたのが検証の自動化でした。
ドキュメントはもう信頼できる拠り所ではない。コードこそが拠り所だ。
定着の判断基準も明快でした。6 か月で、オンボーディングの高速化、PR 往復の短縮、Claude を使ったコミットの定着が見られなければ、定着していないと見なす。月曜の一手として「いちばんノイズの多いワークフローを一つ選び、それが今も必要かを問う」という提案も具体的でした。エンジニアリングの高くついた時代の名残なら、たぶんもう不要だ、と。
出典: Anthropic「Running an AI-native engineering org」（Code w/ Claude Tokyo, 2026）のスライドを筆者撮影。
AI を作る組織が、自らのプロセスを資産として組み替えている。その姿が印象に残りました。
会場で感じた空気
開発者や EM、事業会社の技術部門に所属する方など、さまざまな立場の参加者が集まっていました。国内企業の事例セッションは満席に近く、質疑も活発でした。
面白かったのは、参加者の関心の向き先です。Anthropic の技術やツールの使い方そのものより、「みんな AI をどう使っているのか」への関心が強そうでした。実際、ワークショップより発表会場のほうに人が集まっていた印象です。会場の空気は、「AI を触ってみよう」から「うちでどう標準化するか」へ移っていました。同じ問いを抱えた人が、これだけ集まっている。それを肌で感じられただけでも、現地に来た意味がありました。
さいごに ── では、前線に立つ者として何から始めるか
最後に、ソフトウェアエンジニアとしてAI活用の最前線をみてきて、考えたことを書きます。
正直なところ、いま私ひとりにできることは限られています。組織を作り変える話は、誰が語るかも大事です。実践の裏づけがあって初めて言葉に説得力が乗る。私はまだ、それを言い切れるほどの実績を積めていません。ここに書いたことも、すでに本気で取り組んでいる人たちの知見を、私なりに咀嚼したものにすぎません。
それでも、何もしない理由にはならないと思っています。
多くの登壇者が時間を割いていたのは、派手な自動化ではありませんでした。業務の言語化、評価、メモリ、文脈設計といった「任せる前の足場づくり」です。であれば、自分の一歩目もそこからでいい。まずは自分の担当業務の範囲で、前提にしている知識や判断基準を、少しずつエージェントが扱える形に言語化することから始めてみます。あわせて、自部署で業務の言語化や評価の仕組みがどこまでできているかの現状を見極めたいと思っています。
皆さんの組織では、いま最初に決めるべきことは何でしょうか。何を測り、何を覚えさせるか。人と AI の境界をどこに引くか。そして、何を任せて資産にしていくか。この記事が、その問いを考えるきっかけになれば嬉しいです。
最後まで読んでいただき、ありがとうございました。
