Anthropicコードの90%はClaude Codeが書いている——社員80%が毎日使う「antfooding」を全部解剖した

Last updated at 2026-05-16Posted at 2026-05-16

Anthropic社内では、エンジニアの80%以上が毎日Claude Codeを使っている。コードの90%はClaude Codeが書いている。これは公式ブログとPodcastで本人たちが言っている数字だ。

この記事は、Claude Codeを3ヶ月以上使ってきた人向けに「作っている当事者と、それを毎日使い倒している社員たち」がどう運用しているかを、8チーム横断で全部まとめた。

読み終わるころには「俺の使い方はまだL3だな」「明日から真似できる手は3つだな」が見える。

この記事でわかること

Anthropic社内のClaude Code採用度の実数値（"antfooding"）
8チーム別の具体的なユースケースと、削減できた時間の数字
Boris Cherny（Head of Claude Code）と Cat Wu（PM）がPodcastで明かした内部テクニック8つ
一般ユーザーが今日から真似できる3つの手、と真似ると詰む3つのパターン

対象読者

Claude Codeを3ヶ月以上使っていて、次にどこを目指せばいいかわからない人
サブエージェント・スキル・Hooksまでは触ったが、まだ業務フローに組み込めていない人
「Anthropic社員と同じ場所に立ちたい」と思っている人

1. 数字で見るantfooding——80%が毎日、コードの90%
2. Claude Code team自身——1機能20プロトタイプを2日で
3. Security Engineering——10-15分のスキャンが3倍速
4. Data Infrastructure——K8sダウンを20分で復旧した実話
5. Inference / Growth Marketing——80%減と広告生成のhours→minutes
6. Boris と Cat が明かした内部テクニック8つ
7. 一般ユーザーが今日真似できる3つ
8. 真似ると詰む3パターン
9. まとめ——今日からやる3手

1. 数字で見るantfooding——80%が毎日、コードの90%

このセクションでは、Anthropic内部のClaude Code採用度を数字で示す。

「antfooding」はAnthropic社員（自分たちを"ants"と呼んでいる）によるdogfoodingの愛称だ。彼らは自分で作ったツールを自分の現場で毎日叩いている。Cat Wu（Claude Code PM）はPodcastで「フィードバックチャネルに5分に1回投稿が来る」と話している。これは規模感を表す象徴的な数字だ。

公開ソースから拾える数字をまとめる。

採用度:

指標	数値	出典
社内エンジニアの利用率	80%以上が毎日	Pragmatic Engineer
Anthropicコードの執筆比率	90%がClaude Code製	Boris Cherny
Day1での利用率	20%	Every Podcast
Day5での利用率	50%	Every Podcast

生産性:

指標	数値
内部リリース数	1日60-100本（npmパッケージ）
エンジニア1人あたりPR数	1日5本（夏のピーク時）
1機能あたりのプロトタイプ数	20+本を2日で
エンジニア倍増時のPR throughput	67%向上（通常は減るのに逆方向）

最後の数字が一番効く。普通、エンジニアを倍に増やすとオンボーディングコストでPR数は一時的に落ちる。Anthropicは逆に伸びた。Claude Code自身が新人のオンボーディングを巻き取ったからだ。

💡 Tips: 「PR throughputがエンジニア倍増で67%向上」は他社の事例として真似しづらいが、「Claude Code自身を新人オンボーディング装置にする」という発想は明日から真似できる。後の章で具体的に書く。

ここからチーム別の使い方を見ていく。

2. Claude Code team自身——1機能20プロトタイプを2日で

このセクションでは、Claude Codeを作っている当事者チームの使い方を見る。

Boris Cherny（オリジナルプロトタイプの作者、Head of Claude Code）はPodcastで自分のワークフローを話している。要点はこうだ。

auto-accept modeで「とりあえず動くもの」を量産する

# clean git state からスタートして auto-accept で走らせる
git status  # 全部キレイになってる前提
claude --auto-accept "todo listのプロトタイプを20通り作って"

auto-acceptでClaudeに自走させ、80%完成した時点で見る。気に入らなければEscapeを2回押して直前の状態に戻し、別の角度でやり直す。Borisの言葉で言えば「最もシンプルなものを構築して全システムを触れる。失敗箇所を確認して、Escapeで戻してやり直す」。

これで1機能あたり20+本のプロトタイプを2日で作る。todo list機能を出すまでに20+の試作版を回したと公開している。

モデル新版リリース時にコードを削除する

ここが本当に効く考え方だ。

「Claude 4.0にアップグレードしたとき、system promptの半分を削除した」（Boris）。

新モデルはより少ない指示でうまく動く。だから古いモデル向けの「Xをするときは必ずYしてからZしろ」みたいなガードレールは外せる。コードを足すんじゃなく、コードを引き算するのがClaude Code team自身のリリース作業だ。

「on distribution」の技術スタック

Claude Code本体の技術選定は、Claudeが訓練データで一番触ってる領域に寄せている。

領域	採用技術	理由
言語	TypeScript	Claudeが最も得意
UI	React + Ink	ターミナル向けReact
レイアウト	Yoga	Metaのレイアウトエンジン
ビルド	Bun	速度優先
配布	npm	摩擦なし

これは個人のClaude Code活用にも刺さる思想だ。自分のプロジェクトの技術スタックがClaudeの得意分野からズレているほど、生成品質は落ちる。

3. Security Engineering——10-15分のスキャンが3倍速

このセクションでは、セキュリティチームの実運用と削減数字を見る。

公式ブログ "How Anthropic teams use Claude Code" によると、セキュリティチームのワークフローはこうだ。

design doc を書く
Claude Codeに pseudocode を書かせる
そこから test-driven development で実装に落とす
インシデント発生時は stack trace をそのまま食わせる

定量データは記事に明記されている：

"Problems that typically take 10-15 minutes of manual scanning now resolve 3x as quickly"

10-15分の手動スキャン作業が 3分の1（実質3-5分） に短縮されている。

TDD駆動の実装フロー（社員パターン）

社員が使っているフローを CLAUDE.md に落とすとこうなる。

CLAUDE.md

# Security Engineering Workflow

## 実装フロー
1. design doc を `docs/design/` に書く
2. Claude Code に pseudocode を生成させる: `/skill pseudocode docs/design/xxx.md`
3. pseudocode をレビューしてOKなら、それをもとにテストを先に書かせる
4. テストが赤いことを確認 → 実装させる → 緑になったらコミット

## インシデント対応
- stack trace を直接貼り付ける
- スクリーンショットがある場合はそれも食わせる（ダッシュボードのスクショ等）
- 「このスタックトレースの原因仮説を3つ、可能性順に挙げて」と聞く

この CLAUDE.md の書き方はAnthropic社員が共通して言っている：ドキュメントが整っているチームほどClaude Codeが効く。逆に何も書いてないと、Claudeはあらゆる選択肢を探索しはじめて時間を食う。

Anthropic社員でも、ドキュメントが薄い領域では Claude Code の精度が落ちる、と公式ブログに書かれている。「とりあえず叩けば動く」と思って CLAUDE.md を整備しないと、自分が同じ罠を踏む。

4. Data Infrastructure——K8sダウンを20分で復旧した実話

このセクションでは、本番障害対応で実際に起きた具体ケースを見る。

公式ブログに、Data Infrastructure チームのK8sクラスタダウン事例が載っている。これが一番リアルだ。

状況

本番のKubernetesクラスタが新しいPodをscheduleしなくなった
何が原因かパッと見でわからない
担当エンジニアはGoogle Cloud UIをそこまで深く触っていない

やったこと

Google Cloudのダッシュボードのスクリーンショットを撮る
それをそのままClaude Codeに食わせる
Claudeが「次にこのメニューを開いて」と指示
メニューを開いた画面のスクショを撮って再度食わせる
これを繰り返してPod IPアドレス枯渇を発見
ClaudeがGCPで新しいIPプールを作るための exact commands を提供

結果：本来かかるはずだった調査時間から 約20分を節約。

何が効いたか

これは「スクショ → 推論 → 次の手」のループを Claude Code が回している。ペアプロでベテランSREが横に立っているのと同じ。自分のチームで再現するなら、こうなる:

# 障害時のスクショ食わせフロー
# 1. 障害ダッシュボードのスクショを撮る
screencapture -i /tmp/incident-1.png

# 2. Claude Code に丸投げ
claude "/tmp/incident-1.png を見て、症状の仮説を3つ出して、
次に確認すべきメニューと、見るべき数値を教えて"

# 3. 指示通りに次の画面を撮る → ループ

💡 Tips: 「Claudeにスクショ食わせる」は文字ベースの会話で表現できない情報を一発で渡す手段として効く。本番障害ではダッシュボードの数値、グラフの傾き、UIの状態が全部一発で伝わる。これは盲点になりやすい。

5. Inference / Growth Marketing——80%減と広告生成のhours→minutes

このセクションでは、エンジニアじゃない領域も含めた使い方を見る。

Inference Team——1時間のGoogle検索が10-20分に

Inferenceチーム（モデル推論の最適化を担うエンジニア）の使い方は、ドキュメント検索とクロス言語テストだ。

公式ブログから直接の数字：

"What normally requires an hour of Google searching now takes 10-20 minutes"

1時間のGoogle検索が10-20分に短縮（80%減）。CUDA・Triton・PyTorch内部実装などのドキュメントを横断して読むタイプの仕事は、Claude Codeが最も効く領域だ。

Growth Marketing——サブエージェント2体で広告を hours→minutes

ここが個人的に一番おもしろい。エンジニアじゃないチームがサブエージェントを並列で回している。

ワークフロー：

既存広告のCSVを食わせる（数百本、パフォーマンス指標つき）
サブエージェント1: underperforming な広告を識別
サブエージェント2: 文字数制限を守った新規バリエーションを生成
数百本の新規広告が数分で出来上がる

これを実現するための subagent 設定の最小例はこう書ける。

.claude/agents/ad-analyzer.yaml

name: ad-analyzer
description: 既存広告のCSVから underperforming を識別する
tools:
  - Read
  - Bash
prompt: |
  CSVには各行に広告本文・インプレッション・CTR・CVRが入っている。
  CTRが平均の80%未満かつインプレッション100以上の行を抽出し、
  低パフォーマンスの理由仮説を1行で添える。

.claude/agents/ad-generator.yaml

name: ad-generator
description: 低パフォーマンス広告から新規バリエーションを生成
tools:
  - Read
  - Write
prompt: |
  ad-analyzerが出した underperforming のリストを受け取り、
  各広告につき新規バリエーションを5本、文字数30字以内で生成する。
  訴求軸を変える（機能訴求/価格訴求/感情訴求）。

エンジニアがいなくても回る。Borisがインタビューで「データサイエンティスト（ターミナル未経験）が独力でClaude Codeを習得した」と言っているのはこの文脈だ。

6. Boris と Cat が明かした内部テクニック8つ

このセクションでは、PodcastとBlog記事から拾った具体的なテクニックを8つ並べる。

① Plan Modeは「新モデルほど不要」になる

複雑なタスクで計画合意を取るためのPlan Modeだが、Borisは「Sonnet 4.5以降では2000トークン分のプランを削除できる」と話している。モデルが賢くなるほどPlan Modeの必要性は下がる。

② bash mode（`!`）で複数ターミナルを行き来しない

Borisが「複数ターミナル間の行き来が面倒で思いついた」と語った機能。Claude Code内でそのままシェルコマンドが叩ける。

# Claude Code セッション内で
!ls -la
!git status
!npm test

③ Escape×2で巻き戻し

失敗した実装をEscape2回で直前の状態に戻す。これがあるから「auto-acceptで自走させても安心」になる。

④ スラッシュコマンドはAnthropic全PRで使う

コマンド	用途
`/commit`	コミットメッセージ自動化
`/feature dev`	仕様→計画→TODO化
`/code review`	全PRで適用

/code review はAnthropic全社で標準化されているらしい。

⑤ サブエージェント10個並列（大規模マイグレ時）

Cat Wu によると、大規模マイグレーション時は10個のサブエージェントを同時起動して役割分担する。フロントエンド担当・バックエンド担当・テスト担当に分ける。鍵は "uncorrelated context windows" ——別々のコンテキストを持たせて異なる視点を得る。

⑥ Danの「監査役 vs 個人寄り」議論エージェント

これがおもしろい。社員のDanは、クレジットカードの月次精算をするために2体のエージェントを立てた：

監査役エージェント: 「これは本当に経費か？」と疑う
個人寄りエージェント: 「これは経費だと主張する」

2体を議論させて、決着がついたものだけ実際の精算に進む。コード以外の意思決定でも使える発想だ。

⑦ settings.jsonをコード化して権限プロンプトを消す

毎回のpermissionプロンプトを撲滅するために、社員は settings.json を整備している。

~/.claude/settings.json

{
  "permissions": {
    "allow": [
      "Bash(npm test)",
      "Bash(npm run lint)",
      "Bash(git status)",
      "Bash(git diff*)",
      "Bash(git log*)",
      "Read(./**)",
      "Edit(./src/**)"
    ],
    "deny": [
      "Bash(rm -rf*)",
      "Read(.env*)",
      "Edit(.env*)"
    ]
  }
}

Borisが「毎回のパーミッションプロンプト回避が重要」と強調している。これは個人開発でも即真似できる。

⑧ Stop Hooksでテスト失敗時に自動継続

ターン完了後に走るStop Hookで、テストが赤いと自動継続させる。

~/.claude/settings.json

{
  "hooks": {
    "Stop": [
      {
        "matcher": "",
        "hooks": [
          {
            "type": "command",
            "command": "npm test --silent || echo 'TESTS_FAILING:continue'"
          }
        ]
      }
    ]
  }
}

「テストが緑になるまで継続」を決定論的に制御できる。プロンプトで「テスト緑にして」と頼むよりHookで強制した方が安定する。

7. 一般ユーザーが今日真似できる3つ

このセクションでは、社員のやり方から「個人で今日真似できる」要素だけ抜き出す。

① `CLAUDE.md` を「新人オンボーディング用」に書く

社員が共通して言っているのは「ドキュメントが整っているチームほどClaude Codeが効く」。自分のプロジェクト用の CLAUDE.md を「新人エンジニアが読むつもりで」書き直す。

書くべきこと：

このプロジェクトで使う技術スタック
ディレクトリ構成と各ディレクトリの責務
ローカル開発の起動コマンド
テストの走らせ方
デプロイ手順
「絶対やってはいけないこと」リスト

② `settings.json` の `permissions.allow` を埋める

社員の生産性が高い理由のひとつは、permissionプロンプトに毎回手が止まっていないこと。よく使うコマンドは即allow listに入れる。

③ 障害対応にスクショ食わせを取り入れる

文字で説明しづらい状況（ダッシュボード、グラフ、UI状態）は、まずスクショを撮って食わせる。Data Infrastructureチームが実証した方法だ。

# よく使うエイリアスにしておく
alias incident="screencapture -i /tmp/incident-$(date +%H%M%S).png"

8. 真似ると詰む3パターン

このセクションでは、社員のやり方をそのまま個人で真似ると詰むケースを書く。ここを書かない記事は信用しない方がいい。

① サブエージェント10個並列は個人では破綻する

Anthropic社員が10個並列を回せるのは、コードベースが整っていてテストカバレッジが高いから。個人プロジェクトでテストが薄い状態で10並列をやると、それぞれが衝突する変更を加えて収拾がつかなくなる。まず2-3並列から、テストが赤くなったら止まる仕組みを入れてから増やす。

② Anthropicの "on distribution" 思想は自分の既存スタックでは効かない

「TypeScript + React + Bun が一番効く」という話は、新規プロジェクトをこれから作る人向け。既存プロジェクトがPython + Djangoなら、それを捨ててTSに乗り換えても割に合わない。自分のスタック内で CLAUDE.md を厚くする方が現実的。

③ 「コードの90%がClaude Code製」を真に受けて全部任せると壊れる

Boris が「90%」と言っているのは、社員が常時レビューしている前提の数字。/code review を全PRに通して、人が最終承認している。自分の運用で /code review 抜きで90%自動生成にすると、コードベースが2週間で破綻する。

「Anthropic社員と同じやり方」を目指すのはいいが、彼らはレビュー文化・テスト文化・ドキュメント文化が全部整った環境でやっている。自分の環境がそうじゃないなら、まず環境を整える方が先。

9. まとめ——今日からやる3手

今日（15分）

CLAUDE.md を「新人オンボーディング用」に書き直す（既存があっても上書き）
~/.claude/settings.json の permissions.allow を埋める
alias incident="screencapture -i /tmp/incident-$(date +%H%M%S).png" を ~/.zshrc に追記

今週

/code review を自分の全PRで叩く運用にする
サブエージェントを2体作って役割分担を試す（Growth Marketingパターン）
Stop Hookでテスト失敗時の自動継続を入れる

今月

auto-accept モードで「20プロトタイプを2日で」のClaude Code team方式を1回試す
障害対応にスクショ食わせフローを組み込む
社員80%が毎日使う水準に自分のフローを寄せる

参考ソース:

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up