なぜ Anthropic は
開発が異常に速いのか
Anthropic の異常な開発速度を生んでいるのは、Claude Code というツール単体ではありません。背後にある組織のかたちは、次の 4 つの組み合わせです。
- 仕様書(PRD: Product Requirements Document)を作らず、プロトタイプで合意する文化
- エンジニア 1 人に最大 $1,000 / 日の AI 予算と auto-accept の範囲設計を渡す統治
- Boris Cherny 氏に代表される 100 並列のエージェント運用
- PM・デザイナー・法務までが自分で PR(Pull Request:コード変更の提案単位)を出す、職能の溶け合い
本記事ではこれらを、Anthropic 公式・Sequoia AI Ascent・Lenny's Newsletter・Every・Latent Space などの一次資料から具体的に解き明かしていきます。
01.結論:Anthropic の速度は『PRD を捨て、エンジニアに大きな権限を渡し、エージェントを並列で動かす』組織から生まれる
Anthropic は、ChatGPT で知られる OpenAI と並ぶ生成 AI の最大手で、対話 AI「Claude」と、ターミナル上で動くコーディング向け AI「Claude Code」を主力にしています。2026 年に入って、そのリリース速度は他の AI 企業と桁が違うようになりました。Paweł Huryn 氏が Product Compass で集計した数字によれば、2026 年 2 月 3 日から 3 月 24 日までの約 50 日間で、Claude / Claude Code / API などのプロダクト群全体で 74 件の新機能・更新リリースがカウントされています。1 日あたり約 1.5 リリースが、止まらずに続いた計算です。ARR(Annual Recurring Revenue:年換算したサブスク収入の合計)は 2024 年 1 月時点の約 $87M(8,700 万ドル ≒ 130 億円)から、2026 年 4 月には $30B(300 億ドル ≒ 4.5 兆円)に到達しています。
本記事の中核となる観察は、Anthropic の速度を作っているのは 「Claude Code を使っているから」ではなく、Claude Code を最大限に使い切れる組織のかたちだ、という点です。同じツールを与えられても、PRD を中心に動くプロセス重視の組織では、ここまでの速度は出ません。本記事では、組織のかたちを次の 3 つの軸で分解します。
- 並列エージェントの実際の動かし方:1 人が 100 個のエージェントをどう束ねて指揮するのか、何が「人間の仕事」として残るのか
- エンジニア・PM・デザイナーの権限と振る舞い:エンジニアはどこまで自律実行に任せるのか、PM は仕様書を書くのではなく何をするのか、デザイナーはどこまで自分でコードを出すのか
- antfooding と PRD レス文化:社員 =「アリ」が自社プロダクトを毎日激しく使い、フィードバックが 5 分に 1 件届く運用
02.数字の量感:約50日で74リリース、ARRは$87Mから$30Bへ
まず、Anthropic が出している数字の桁を整理します。出典はすべて一次情報・主要技術メディアの取材です。
約50日で74リリース、Claude Codeは3か月で一般公開
| Anthropic の指標 | 数字 | 出典・補足 |
|---|---|---|
| 約50日間でのリリース数(2026年2/3〜3/24) | 74件 | Paweł Huryn / Product Compass。Claude Code・Cowork・Dispatch・API 全体 |
| ARR の推移 | $87M(2024.01)→ $30B(2026.04) | VentureBeat『Anthropic says it hit a $30 billion revenue run rate』 |
| Claude Code の研究プレビュー → 一般公開 | 2025.02 研究プレビュー → 2025.05 一般公開(GA)まで 3 か月 | Anthropic 公式 changelog |
| Claude Code の ARR | $1B(2025.11)→ $2.5B(2026 初頭) | Anthropic『Claude Code reaches $1B milestone』、MindStudio 集計 |
Claude Code は 2025 年 2 月の研究プレビューから 5 月の一般公開(GA: General Availability、正式に一般ユーザー向けに提供される段階)まで、わずか 3 か月でした。一般公開後の伸びはさらに急で、2025 年 11 月には $1B ARR に到達、2026 年初頭には $2.5B ARR に達しています。Anthropic の CEO Dario Amodei 氏は 「自社の予測を 8 倍上回る成長」と表現しました。
社内での Claude 利用率は日次業務の 59%
Anthropic の公開資料 「How AI Is Transforming Work at Anthropic」によれば、2025 年 8 月に調査した同社のエンジニア・研究者 132 名の Claude 利用率は次の通りです。
| 指標 | 2025年8月調査 | 前年比較 |
|---|---|---|
| エンジニア・研究者の日次業務に占める Claude 利用の割合 | 59% | 前年は 28%(1 年で約 2 倍) |
| 自己申告の生産性向上 | +50% | 前年は +20% |
| 1 エンジニアあたりのマージ PR 数 | +67% | Claude Code 導入時の社内観測値 |
この数字は、Anthropic が自社の中で Claude を最も激しく使っている組織であることを物語っています。調査対象のエンジニア・研究者が単に Claude を「使っている」のではなく、業務時間の過半を Claude と一緒に進めている状態です。これが antfooding の量的な裏付けになります。
社員数・採用密度・モデル利用も速度の前提になる
Anthropic の速度を読むときは、社員数の伸びと採用できる人材の密度も切り分ける必要があります。Anthropic は詳細な社員数を継続公開していませんが、公開推計を集約した MakerStations は、同社が 2023 年初頭の約 240 人から 2025 年 12 月の約 2,300 人へ、3 年弱で約 10 倍に拡大したと整理しています。2026 年初頭の社員数は、推計方法によって 2,946〜5,000 人程度の幅があります。
報酬面でも、Levels.fyi の自己申告データでは、Anthropic のソフトウェアエンジニア報酬は Senior Software Engineer で年 $563K、Lead Software Engineer で年 $785K、全職種の中央値で年 $420K とされています。これは、同社が高年収で経験豊富なエンジニアを採用している可能性が高いことを示す指標です。
さらに、社内でどのモデルをどれだけ使っているかは公式に細かく公開されていません。ただし、Claude Code のモデル設定ドキュメントでは、Max / Team Premium の既定モデルが Opus 4.7 とされ、API / Enterprise の従量課金でも Opus 4.7 への既定変更が案内されています。加えて、Pragmatic Engineer は、Anthropic と OpenAI の社員には LLM(Large Language Model:大規模言語モデル)利用上限がないと報じています。したがって、Anthropic の速度は Claude Code の導入だけでなく、最高クラスのモデルを大きく使える環境と、採用競争力の高い組織条件も含めて読む必要があります。
Mike Krieger『Claudeのコードの90%はAIが書いている』
90% of Claude's code is now written by AI, completely transforming how we build products, with bottlenecks shifting from engineering (writing code) to decision-making (what to build) and merge queues (getting code into production).和訳:Claude のコードの 90% は今や AI が書いている。プロダクトの作り方は完全に変わってしまった。ボトルネックはエンジニアリング(コードを書くこと)から、意思決定(何を作るか)とマージキュー(コードを本番に乗せること)に移っている。
Mike Krieger 氏(Anthropic CPO、Inference by Sequoia インタビュー)
Mike Krieger 氏は Instagram の共同創業者として知られる人物で、現在は Anthropic の CPO(Chief Product Officer:最高プロダクト責任者)を務めています。「Claude のコードの 90% は AI が書いている」「ボトルネックはエンジニアリングから意思決定とマージキューに移った」という発言は、本記事の中心命題の 1 つです。
03.Antfooding:社員=アリが自社プロダクトを最も激しく使う
Anthropic の組織速度を支える最大のしくみが、社内で antfooding(アントフーディング)と呼ばれる強烈なドッグフーディング文化です。Anthropic の技術系社員は社内で 「ant(アリ)」と呼ばれ、自社プロダクトの最も激しいユーザーとして位置づけられています。
Anthropic の社内用語で、一般的なドッグフーディング(dogfooding:自社プロダクトを社員が使うこと)の Anthropic 版です。技術系社員 =「アリ(ant)」が、自社プロダクトの最も激しいユーザーになる体制を指します。普通のドッグフーディングと異なるのは、次の 3 点です。
- 導入速度:Day 1 で 20%、Day 5 で 50%、現在 70〜80% の浸透
- フィードバック密度:専用 Slack チャンネルに数分に 1 件のメッセージ
- 機能横断:エンジニアだけでなく PM・デザイナー・法務・マーケまで含む
Carlos Perez『Antfooding: How Anthropic builds products without PRDs』、Every Podcast『How to Use Claude Code Like the People Who Built It』で詳しく整理されています。
厳密な社内組織図は公開されていませんが、Anthropic 公式の 「Introducing Anthropic Labs」と 「How Anthropic teams use Claude Code」からは、Claude Code 周辺の動き方が見えてきます。Labs が実験的なプロダクトを立ち上げ、Product 組織と CTO 配下のインフラ・推論領域が近い距離でスケールさせ、Claude Code チームは社内の各職能から短いフィードバックループを受ける構造です。
公開記事から読み取れる範囲を図式化したものです。公式な組織図ではなく、Claude Code を中心にしたフィードバックの流れを示しています。
Day 1 で 20%、Day 5 で 50%、現在 70〜80% の浸透速度
Claude Code が社内向けに最初のドッグフーディング版をリリースしたのは 2024 年 11 月でした。Every Podcast『How to Use Claude Code Like the People Who Built It』での Cat Wu 氏・Boris Cherny 氏のインタビューによれば、その浸透速度は次の通りです。
| 時期 | 社内利用率 | 備考 |
|---|---|---|
| Day 1(2024.11 初公開日) | エンジニアリング部門の約 20% | 強制ではなく口コミだけで広がった |
| Day 5 | 約 50% | Slack で体験談が広がる |
| 一般公開直後(2025.05) | 60% 超 | Max プランでの一般公開と同時 |
| 現在(2026.04 時点) | 技術系社員の 70〜80% が毎日使用 | Latent Space・Every・Pragmatic Engineer の独立取材で一致 |
この数字の意味は、単に「使われている」ではなく、自社プロダクトの最も厳しい批判者がエンジニア自身である状態が組織全体に再生産されていることです。Anthropic の Claude Code チームは、社員が日常で見つけたバグやストレスを 数分以内にキャッチアップできる距離に立っています。プロダクトと最も厳しいユーザーが、廊下を挟んだ 5 メートルしか離れていない、と言い換えてもよい状況です。
5 分に 1 件のフィードバック、prototypes over PRDs
Anthropic の Claude Code チームには 専用のフィードバック Slack チャンネルがあり、そこには 「約 5 分に 1 件」のメッセージが届くと、Cat Wu 氏は Lenny's Newsletter『How Anthropic's product team moves faster than anyone else』で語っています。
The team has an unfair advantage: They watch hundreds of engineers use Claude Code every day just by walking around the office. They get feedback every 5 minutes.和訳:このチームには不公平な優位がある。オフィスを歩き回るだけで、何百人ものエンジニアが日常的に Claude Code を使う様子を観察できる。フィードバックは 5 分に 1 件届く。
Cat Wu 氏(Anthropic、Every Podcast 経由)
Anthropic の合言葉は 「prototypes over PRDs」です。何かを作るときに、まず仕様書を書いて合意するのではなく、プロトタイプを作って ants(社員)に投げ、5 分以内に反応を受ける運用です。反応が良ければそのまま社外にリリースされ、悪ければ即座に作り直されます。PRD(仕様書:Product Requirements Document)は、ほとんど書かれません。
この運用が成立する前提は、次の 3 つです。
- プロトタイプを書くコストが極小であること(Claude Code 自身で書ける)
- ants が即座に反応できる文化と Slack チャンネルがあること
- 失敗したプロトタイプを書き直すコストが心理的にも実装的にも低いこと
「PRD を書くより、プロトタイプを書く方が安い」状態を組織内で作れているかどうかが、ここでの分水嶺になります。
Growth Marketing も Legal も Design も commit する
antfooding の最も組織横断的な側面は、非エンジニア職種も Claude Code を使って自分で実装・コミットしている点です。Anthropic 公式『How Anthropic teams use Claude Code』では、データ基盤・プロダクトエンジニアリング・セキュリティ・推論・成長マーケティング・プロダクトデザイン・RL エンジニアリング・法務の各チームごとに、Claude Code の使い方が紹介されています。各職種の振る舞いの詳細は後ろの章で改めて分解しますが、ここでは数字だけ示します。
| チーム | Claude Code の使い方 | 効果 |
|---|---|---|
| Growth Marketing | 数百種類の広告クリエイティブを数分で生成 | A/B テストの母集団規模が一桁変わる |
| Legal(法務) | アクセシビリティ対応ツールを内製。エンジニアの手を借りない | 従来は外注かエンジニア依頼が必要だった |
| Product Design | Figma → コード変換、デザインシステム検証のスクリプト化 | デザイナーが PR を出す |
| RL Engineering | 学習ジョブの統括、評価結果の可視化 | 実験速度が上がる |
| Data Infra | Airflow DAG、データパイプラインの定型コードを自動化 | 繰り返し作業が劇的に圧縮される |
| Security | 監査ログ解析、IaC 規約チェッカー | 監査の頻度を上げられる |
| Inference | テストハーネスの拡張、ベンチマーク自動化 | モデル評価のサイクルが短縮される |
04.並列エージェントを 1 人がどう束ねるか
Anthropic の組織速度の中核は、1 人のエンジニアが数十〜数百のエージェントを同時に動かす運用です。これは技術的な話というより、「1 人の人間に何を任せ、何をエージェントに任せるか」という組織設計の話です。
Boris Cherny の 100 並列:5〜10 セッションで合計約 100 エージェント
Claude Code の創設者である Boris Cherny 氏は、2026 年 5 月 4 日の Sequoia AI Ascent の壇上で、「自分のコードは 100% Claude Code が書いており、常時 100 個のエージェントを同時に動かしている」と発言しました。原文は次の通りです。
100% of my code is written by Claude Code. I run around 100 agents at one time, in five to 10 sessions, each containing multiple agents. Usually, every night, I have like a few thousand that are doing kind of deeper work.和訳:自分のコードは 100% Claude Code が書いている。常時 100 個ほどのエージェントを動かしており、5〜10 のセッションに分けて、各セッション内で複数のエージェントが並列に走っている。たいてい毎晩、寝ている間にも数千個のエージェントがより深い作業をこなしている。
Boris Cherny 氏(Anthropic、Claude Code 創設者、Sequoia AI Ascent 2026年5月4日)
この発言から読み取れる、彼の運用構成は次の通りです。
- セッション数:常時 5〜10 セッションを並走させる(1 セッション = 1 つの Claude Code 端末)
- 1 セッションあたりのエージェント数:各セッション内で複数エージェントが並列に走る
- 合計の同時並列度:概ね 100 エージェント
- 夜間バッチ:寝ている間に数千個のエージェントが「より深い作業(deeper work)」をこなす
- 監督端末:主にスマートフォン。Plan の承認だけが人間の仕事になっている
ここで重要なのは、彼の発言が 「特殊な個人事例」ではなく、Anthropic 内では『再現可能な水準』として扱われていることです。Mike Krieger 氏の「90% AI 生成」発言とも整合します。経営層自身がこのレベルでエージェントを動かしていることは、組織全体のエージェント運用の天井を引き上げます。
1 セッション = 1 役割:実装/調査/テスト/ドキュメントの分業
100 並列を 1 人で束ねるには、エージェントごとに 役割を切り分けて配置することが不可欠です。Boris Cherny 氏らのインタビュー、および Claude Code の Agent Teams 公式ドキュメントから読み取れる典型的な構成は、次のとおりです。
| セッションの役割 | やらせていること | 人間が見るタイミング |
|---|---|---|
| 実装リード | メインの変更を書く。複数ファイルを跨ぐ実装をまとめる | Plan の承認時/PR が立った時 |
| 調査担当 | 新しい API のドキュメントを読む、似た過去 PR を探す、依存ライブラリの挙動を確認する | 結果が要約として上がってきた時 |
| テスト担当 | テストの追加・修正・回帰評価の追加 | テストが緑になった時 |
| ドキュメント担当 | README・CHANGELOG・docstring の更新 | PR レビュー時の補助情報として |
| レビュー補助 | 他セッションが書いた PR を別エージェントが先にチェック | 気になる指摘だけ人が見る |
この分業の効果は、人間が 「全てのエージェントを常時見張る」必要をなくすことです。各エージェントは自分の役割の範囲で動き、結果だけが要約として人間に上がってきます。人間の認知容量を「監視」ではなく「決定」に振り直すための仕組みです。
スマートフォンで承認する:Plan の判断だけが人間の仕事
Business Insider / Yahoo Tech は、Boris Cherny 氏が Sequoia Capital のインタビューでスマートフォン上の Claude アプリを示し、複数の Code セッションを管理していると報じています。この運用の背景には、Claude Code の Plan モードがあります。Plan モードは、エージェントが実装に入る前に「何をどう作るか」を提示し、人間が承認・差し戻しを判断する段階を必ず挟みます。
運用としては、次のようになります。
- 各セッションが Plan を上げてきたら、人間はスマートフォンで内容を確認する
- Plan が妥当なら「OK」、ズレていれば差し戻して指示を補強する
- 実装フェーズに入ったエージェントは、テスト・CI が緑になるまで自走する
- 結果(PR)は別セッションのレビュー補助が先にチェックし、人間は気になった部分だけ見る
この運用が成立するのは、Plan モード + テスト + CI + サンドボックス + レビュー補助エージェントを組み合わせて、人間が「実装を見張らない」運用に振っているからです。auto-accept run(人間レビュー無しでエージェントが自律実行する運用)が許される範囲が、組織として明示的に切られています。
夜間に数千エージェント:本人発言で確認できる範囲
日中の 100 並列に加えて、Boris Cherny 氏は夜間にも大規模にエージェントを走らせていると語っています。根拠は Sequoia Capital『Anthropic's Boris Cherny: Why Coding Is Solved, and What Comes Next』での本人発言です。前節で引用した通り、同氏は「たいてい毎晩、数千個ほどがより深い作業をしている」と説明しています。
ここで確認できるのは、夜間に数千規模のエージェントが動いているという本人発言までです。どの作業が何件 PR 化されるのか、どの範囲が人間レビューなしで進むのかは、この発言だけでは断定できません。一方で、Latent Space『Claude Code: Anthropic's CLI Agent』での Boris Cherny 氏らの発言によれば、Claude Code の Vim モードは、その大部分が auto-accept run(クリーンな git 状態から、人間レビュー無しでエージェントが自律実行する運用)で生成されたとされています。夜間運用を読むときも、auto-accept と検証層がセットで語られている点を外すべきではありません。
05.エンジニアにどれだけの権限を渡しているか
Anthropic の速度の前提にあるのが、エンジニア 1 人に対する大きな権限委譲です。同社は、コードを書く工程だけでなく、「コードを動かすまでの承認プロセス」も徹底的に短くしています。
auto-accept と eval ハーネスで承認待ちを減らす
Anthropic 公式の 「How Anthropic teams use Claude Code」では、Product Design チームが Claude Code にコードを書かせ、テストを実行させ、継続的に反復させる自律ループを組んでいることが紹介されています。ここで確認できるのは、少なくとも auto-accept mode や自律実行を使い、テストを回しながら承認待ちを減らしているという点です。
もう 1 つの前提が eval ハーネス(あらかじめ用意した入力例に対する AI モデルの出力を、期待値と自動で照合する仕組み。コードの単体テストの AI 版だと考えるとイメージしやすい)です。Anthropic の 「Demystifying evals for AI agents」では、Claude Code が社内外のフィードバックから始まり、その後 concision、file edits、over-engineering といった領域の eval を追加して改善判断に使ったと説明されています。つまり、承認待ちを減らす運用は、テスト・CI・eval・人間レビューを組み合わせた検証層とセットで成立しています。
この節は、Anthropic の運用をそのまま推奨するものではありません。公開情報から確認できるのは、Claude Code を使った自律ループ、テスト実行、eval への投資です。人間レビューを省略する範囲は、サンドボックス、CI、eval、ロールバック、責任者の明確化が揃って初めて検討できる運用です。検証層が薄い状態で auto-accept の範囲だけを広げると、品質事故やセキュリティ事故につながります。
auto-accept run:人間レビュー無しで自律実行してよい範囲
Claude Code には、エージェントが 人間のレビューを介さずに自律実行してよい範囲を明示する運用があります。これが auto-accept run と呼ばれる運用です。
| auto-accept で許される範囲 | auto-accept から外す範囲 | 判断基準 |
|---|---|---|
| タイポ修正、import 整理、フォーマット | DB スキーマ変更、認証回り、決済 | クリーンな git state から始められるか |
| テスト追加、テスト修正 | 本番環境への影響が直結する変更 | 影響範囲を CI/eval が検出できるか |
| ドキュメント・コメントの更新 | 新しい外部依存の追加 | テスト・型・lint で機械的に検証できるか |
| 既存パターンの内側でのリファクタ | アーキテクチャに影響する変更 | 失敗時に巻き戻せるか |
Vim モードの大部分が auto-accept run で生まれたという前述の例は、「検証の仕組みへの先行投資が十分に厚ければ、生成は自律に振ってよい」という運用判断の象徴です。検証が薄い組織で同じ運用をすると事故になります。先にテスト・CI・eval ハーネスを厚くしてから、auto-accept の範囲を広げる順番が大切です。
個人の AI 予算は $1,000 / 日まで許容される
Latent Space『Claude Code: Anthropic's CLI Agent』での Boris Cherny 氏・Cat Wu 氏の発言によれば、Anthropic 社内における Claude Code の平均利用は 1 ユーザーあたり $6 / 日、移行作業などの重作業時には $1,000 / 日に達するエンジニアもいます。これは 「エンジニア 1 人月で数百〜数千ドル相当の AI 予算」を、組織として正面から認めていることを意味します。
Anthropic は、「エンジニアの判断で $1,000 / 日まで使ってよい。重要なのは LOC や PR 数ではなく、その金額に対してマージされた価値の大きさだ」という姿勢を取っています。コストを縛るのではなく、コスト ÷ 価値で見る設計です。
新しいプロダクトは『社内に出してみる』で立ち上がる
新しいプロダクトの立ち上げ方も、伝統的な「企画 → 仕様 → 設計 → 実装 → β → GA」の直列フローではありません。Anthropic では、エンジニアが 「これ作ってみた」と社内 Slack に投げるところから始まることが多いと、Cat Wu 氏は語っています。社内で 5〜10 人が触ってみて、反応が良ければ自然と人が集まり、悪ければ静かに消えます。
この方式が機能する前提は、「失敗しても咎められない」「成功すれば製品化が即決まる」という意思決定の軽さです。経営層がこの動きを止めない、むしろ自分たちも同じやり方で何か試している姿勢が、文化として共有されています。
06.PM・デザイナー・法務の実際の振る舞い
Anthropic の特徴で他社と最も異なるのが、非エンジニア職種が「自分でコードを書いてリリースする」運用が標準化していることです。これは「PM や法務にも Claude Code を配ろう」というレベルの話ではなく、役割の境界そのものを引き直していると読むほうが正確です。
PM は仕様書を書かない:プロトタイプで合意を取りに行く
Anthropic の PM の振る舞いを最も象徴しているのが、Claude Code の PM である Cat Wu 氏の語り口です。彼女は Lenny's Newsletter および Every Podcast で、自身の仕事の多くを次のように説明しています。
- 仕様書(PRD)はほぼ書かない。書くとしても短いメモ程度
- 代わりに、Claude Code 自身を使って 動くプロトタイプを 1〜2 日で作る
- そのプロトタイプを社員(ants)に触ってもらい、Slack の反応を集める
- 反応の量と質を「数字」として扱い、リリース判断の根拠にする
- 本格的なドキュメントは、リリースしてから後で書く
この運用は、「PM が技術もコードも理解している」前提でないと回りません。Anthropic では、PM 自身が Claude Code を毎日使い、エンジニアと同じ語彙でプロダクトを語れることが要求されます。「PM はエンジニアの上司ではなく、エンジニアと並走する翻訳者」という関係性に近いものです。
デザイナーは Figma で止まらず、PR を出す
Anthropic のデザイナーは、伝統的な「Figma(業界標準の UI デザイナー向けクラウドツール)でモックを作って、エンジニアに渡す」ところで止まりません。公式ブログ『How Anthropic teams use Claude Code』には、デザイナー自身が次のような作業をしている例が挙げられています。
- Figma で作ったモックを、Claude Code に渡して そのまま実装に変換する
- デザインシステムのコンポーネントが仕様通りに使われているか、検証スクリプトを 自分で書く
- 細かい挙動の調整(ホバー時のアニメーション、A11y 属性など)は、自分で PR を出して直す
- 新しいパターンの提案は、Figma だけでなく 動くプロトタイプ込みでレビュー依頼する
この変化の帰結は、「デザイナーとエンジニアの間の往復が消える」ことです。デザイナーが直接 PR を出せれば、デザイン仕様の伝達ミスによるエンジニアの手戻りコストが激減します。デザイナーは「絵を描く人」から「動くものを出す人」へ変わります。
法務は自分でアクセシビリティ対応ツールを内製する
最も象徴的な例が、Anthropic の Legal(法務)チームがアクセシビリティ対応ツールを自分で内製した事例です。公式ブログに明記されています。
- 従来、こういうツールは外注するか、エンジニアチームに依頼する必要があった
- Anthropic の法務メンバーは、Claude Code に要件を渡して、自分で動くツールを作った
- エンジニアチームに依頼を出していない(エンジニアの工数を消費していない)
- 結果として、法務チームのアクセシビリティ対応の自由度と速度が大きく上がった
ここで起きているのは、「専門外の領域でも、要件を言語化できれば自分で動くものが作れる」という職能の溶け合いです。法務が「コードを書ける人」になるのではなく、「要件を言語化できる人なら誰でもプロダクト開発に参加できる」に組織のかたちが変わっています。
Growth Marketing は数百種の広告を 1 人で生成する
Growth Marketing の使い方も、同じ方向のシフトを表しています。従来の運用では、広告クリエイティブを 100 種類試そうとすると、デザイナーとコピーライターの工数が大量に必要でした。Anthropic の Growth Marketing は、Claude Code を使って 数百種類の広告バリエーションを 1 人で数分のうちに生成します。
効果は単純で、A/B テストの母集団規模が一桁変わります。10 種類でテストするのと 300 種類でテストするのとでは、勝ちパターンを発見する速度がまったく違います。Growth Marketing のチームは、「広告を作るチーム」から「広告を試して勝ち筋を発見するチーム」へと役割が変わっています。
ここで起きている職能の溶け合いは、Anthropic が AI モデル提供企業であることの帰結でもあります。自社のモデルが社員の生産性をそのまま上げる構造のため、「Claude が使えれば、職能の壁を超えてプロダクトに貢献できる」体験が、PM・デザイナー・法務・マーケに広く行き渡っています。
07.Mike Krieger『ボトルネックはマージの速度に移った』
ここまでの組織のかたちを踏まえて、Mike Krieger 氏(Anthropic CPO、ex-Instagram 共同創業者)の発言を改めて読み直すと、意味が立体的になります。Inference by Sequoia インタビュー『Building AI Products From the Bottom Up』での発言です。
Krieger 氏の整理によれば、「ボトルネックは『書く能力』から『意思決定速度』と『マージの速度』へ移った」。書く側はもう十分速い。組織のスループットを決めるのは、次の 2 点になりました。
- 意思決定速度:何を作るかをどれだけ速く決められるか。PRD を捨てて prototypes で合意する Anthropic の運用は、ここに直接効きます
- マージの速度:生成されたコードをどれだけ速くマージできるか。テスト・CI・eval ハーネスへの先行投資が、ここに直接効きます
08.verification(検証)が新しいボトルネックになった
Claude Code が十分に速くなった結果、組織のスループットを決めるのは 「生成されたコードをどれだけ速く・正しく検証できるか」に移りました。
Agoda レポート:AI で個人は速くなったが、組織は速くなっていない
この構造を具体的な数字で示したのが、旅行 OTA 大手 Agoda が 2025 年に公開した 『AI Developer Report 2025』です。東南アジア・インドの開発者を対象とした大規模調査として、AI ツール導入後に開発組織で何が起きているかを定量化しています。コードレビュープロセス変更の 57% は、同じ Agoda の ガバナンス続報で公表された数字です。
| 指標 | Agoda レポートの数字 | 意味 |
|---|---|---|
| AI 生成コードを毎回レビューする開発者 | 67% | 人間の検証は依然として必須工程 |
| AI 出力を再加工してからマージする開発者 | 70% | そのままマージできるコードは少数 |
| AI 導入を機にコードレビュープロセスを変更した開発者出典:Agoda ガバナンス続報 | 57% | 従来のレビュー設計では追いつかない |
| AI 出力の不安定さを最大の障壁に挙げた開発者 | 79% | 品質が組織速度を決める |
この数字が示しているのは、個人の生産性は確かに上がるが、レビュー・検証・統合の負荷がそのまま組織側に積み上がるという構造です。同じ観察は、AWS Enterprise Strategy ブログ『Your AI Coding Assistants Will Overwhelm Your Delivery Pipeline』でも整理されており、「コード生成は爆速化したが、デリバリーパイプライン側があふれている」という同じ構図が報告されています。
本当のボトルネックは、次の 3 点に整理できます。
- テスト・CI・lint の充実度
- 人間のレビューキャパシティ
- eval(評価)ハーネスの整備
すなわち verification(検証)に投資できているかが、本当の制限になっていた、という整理です。
Anthropic の verification 投資の中身
| verification 層 | Anthropic 側の投資 | 現れているところ |
|---|---|---|
| テスト・CI・lint | Claude Code 自身がテスト生成・修正を担う/lint を CI で機械的に強制 | PR ごとの自動回帰 |
| eval ハーネス(評価基盤) | モデル × タスクの広範な eval スイート/PR ごとに回帰評価 | リリース判断の根拠 |
| 人間の最終判断 | アーキテクチャレビュー+セキュリティ/DB 関連は手で読む | コアな意思決定のみを人が見る |
| サンドボックス隔離 | Safe YOLO Mode、Docker 公式テンプレート | 破壊的操作は捨てられる環境で |
| 対話的検証 | Plan モードでの差し戻し、prototypes over PRDs | 実装に入る前に差し戻せる |
エージェントに対して権限プロンプトをスキップさせ、「破壊的な操作も含めて全自動で実行させる」モード(YOLO = You Only Live Once)です。Claude Code の --dangerously-skip-permissions オプションが代表例で、前提として、エージェントが触れる範囲が サンドボックス(Docker microVM、devcontainer、ephemeral worktree など)で隔離されていることが必要です。Anthropic 公式は「Safe YOLO Mode」として、安全な隔離環境内での YOLO 運用を推奨しています。詳細は Docker × Anthropic の共同記事を参照してください。
verification の発想は、「人間が全行をレビューする」を捨てる代わりに、「人間がレビューすべき範囲を絞り込む」方向に進化しました。プロンプト設計と評価設計の関係は プロンプト・ベストプラクティスでも整理しています。Peter Steinberger 氏の「I ship code I don't read」は、この検証への先行投資があって初めて成立する運用でした。組織レベルでも同じ前提条件が必要になります。
09.Dogfooding Flywheel:製品と社内ツールが同一であること
Anthropic がリリースするモデル(Claude)と、Anthropic の社内エンジニアが毎日使うモデルは 同一のものです。これは「製品改善 = 自分たちの生産性向上」「自分たちの生産性向上 = 製品改善」という 二重のフライホイールを生みます。モデルを 1% 改善すれば、社員 1 人あたりのコード生成も 1% 速くなり、それが翌週のリリースに反映され、また社員に戻ってきます。このループは AI モデル提供企業にしか回りにくいのが本質です。
antfooding が成立する前提も、ここにあります。社員が「自社がリリースするモデル」を毎日使っているため、フィードバックがそのままプロダクト開発の優先順位に直結します。社員 1 人の不満は、世界中のユーザー 100 万人の不満を先取りしている可能性が高く、これは 「ドッグフーディング一般」とは桁の違う情報密度です。
対照的に、AI を 使う側の企業(Notion、Linear、その他多くの SaaS)では、このループは構造的に回りません。プロダクト改善のための AI 性能向上は、ベンダー(Anthropic / OpenAI)のリリースサイクルに上限を決められるからです。Anthropic の組織速度は、彼らが AI モデル提供企業であることに大きく依存しています。
なぜ OpenAI は開発が異常に速いのか
OpenAI 側の Codex 17 人・7 週間スプリント、DRI モデル、Harness Engineering(3 人で 5 か月・100 万行・1,500 PR・手書きゼロ)を整理しています。
Peter Steinberger 氏のAI駆動開発手法
1 か月で個人コミット 6,600 件、1 日約 5 億トークンを使うエンジニアの AI 駆動開発手法を整理しています。
10.まとめ
本記事を通じて見えてきた Anthropic の速度は、「Claude Code というツール」だけでは説明できません。背後には、antfooding、PRD なしのプロトタイプ駆動、エンジニアへの大きな権限委譲($1,000 / 日まで許容される AI 予算・auto-accept run の範囲設計)、PM・デザイナー・法務までが自分で PR を出す職能の溶け合い、そして製品と社内ツールが同一である dogfooding flywheel、という前提条件が積み重なっています。
Mike Krieger 氏の 「ボトルネックは『書く能力』から『意思決定速度』と『マージの速度』へ移った」という発言は、個別の開発手法ではなく、Anthropic の組織構造全体を示す言葉として読む必要があります。Claude Code が書く速度を押し上げた結果、人間側に残る仕事は、何を作るかを決め、どこまで任せるかを決め、どの変更を本番へ通すかを決めることに移っています。
AI エージェント時代の開発組織を Cryptul と整理しませんか
AI エージェントの導入状況、開発プロセス、検証体制、権限設計を棚卸しし、組織に合わせた移行ロードマップを整理します。

