Anthropic 社内チームの Claude Code 活用 — マーケから法務まで、全部門が「自分で自動化」する時代
Anthropic 公式記事: How Anthropic teams use Claude Code 再現記事: Claude Code で広告バナー200本を15分で作る手順 紹介ポスト: commte
はじめに
Anthropic が「自社のチームが Claude Code をどう使っているか」を公式ブログで公開した。注目すべきは、エンジニアリングチームだけでなく、マーケティング、法務、データサイエンス、デザインといった非技術部門が、コードを1行も書かずに高度な自動化を実現している点。
特にマーケティングチームの事例は、ツイートでも「えぐい広告手法」として話題になり、実際に再現して15分で広告バナー200本を生成した記事も登場した。
マーケティングチーム — たった1人で10倍の成果
チーム構成
驚くべきことに、Anthropic のグロースマーケティングチームはエンジニアがゼロの1人チーム。担当の Austin Rau 氏は、元々ターミナルの開き方すら知らなかったという。
それが、非技術者向けガイドを見てから1週間で、Figma プラグインと広告コピー生成ワークフローの両方を構築した。
4つの自動化事例
1. Google Ads の広告コピー生成（2時間 → 15分）
数百件の既存広告 CSV を Claude Code に読み込ませ、パフォーマンスの低い広告を自動特定。改善案をサブエージェント方式で生成する。
サブエージェント設計のポイント:
| エージェント | 専門 | 制約 |
|---|---|---|
| headline-writer | 見出し生成 | 30文字以内 |
| description-writer | 説明文生成 | 90文字以内 |
1つのプロンプトで全部やらせるのではなく、タスクごとに専門エージェントを分けることで、文字数制約を守りつつ品質を維持する。
2. Figma プラグインでバナー一括生成（数時間 → 0.5秒）
Claude Code で自作した Figma プラグインが、テンプレートのテキストノードを CSV データで自動差し替え。最大100パターンのバナーを一括生成する。
手作業でのコピペが数時間かかっていたものが、ボタン1つで0.5秒に。
なぜ SVG 直接生成ではなく Figma プラグインなのか
「AI にバナーの SVG を直接生成させればいいのでは？」という疑問が浮かぶかもしれない。しかし、LLM による SVG 直接生成にはいくつかの本質的な弱点がある。
LLM が SVG を直接生成する場合の問題:
- テキスト・フォントの崩れ: フォント定義の欠落、日本語フォントの制御困難、閲覧環境依存の文字化け
- レイアウトの不安定さ: LLM には座標・寸法・変換の空間認識が本質的に不足しており、要素の位置ずれや不均等なスケーリングが頻発する
- ブランド一貫性の欠如: 色（特にグラデーション）、ストローク、影の表現がパターンごとにバラつく
- 編集の困難さ: パスが結合されレイヤー構造がない SVG は、後からの修正が困難
Figma テンプレート + プラグイン方式の優位性:
| 観点 | SVG 直接生成 | Figma テンプレート + プラグイン |
|---|---|---|
| レイアウト精度 | 毎回ずれる可能性 | テンプレート固定で100%一致 |
| フォント | 環境依存で崩れる | Figma がフォント管理を担保 |
| ブランド一貫性 | パターンごとにバラつく | デザインシステムで統一済み |
| バリエーション品質 | パターンごとに不均一 | テキストだけ差し替えるので均一 |
| デザイナー連携 | SVG ファイルを別途共有 | Figma 上でリアルタイムに確認・修正 |
| 出力形式 | SVG のみ | PNG, JPG, PDF, SVG 何でも可 |
核心は「AI が得意なこと」と「苦手なこと」の分離。 テンプレートのビジュアル部分はデザイナーが作り、大量のテキストバリエーション生成だけを AI に任せる。だから200パターンでも品質が崩れない。三菱UFJ銀行の講演でも「SVG は現時点で精度が低く、画像処理の方が有効」と指摘されており、LLM がベクター形式の空間的整合性を扱うのが本質的に不得意であることは業界共通の認識になりつつある。
3. Meta Ads MCP サーバー
Meta Ads API を MCP サーバーとして統合し、Claude Desktop から直接キャンペーンのパフォーマンスデータにアクセス。毎日のダッシュボード確認とログイン作業を不要にした。
4. 自己改善メモリシステム
過去の仮説と A/B テスト結果を記録するメモリフレームワークを構築。新しい広告バリエーション生成時に過去の実験結果を参照し、反復的に学習するシステムを実現。
具体的にどう動くのか
技術的に高度なことをしているわけではない。要するに**「過去に試した広告とその結果を記録したファイルを、次の広告生成時に Claude に渡す」**という仕組み。実験ノートを取って次回に活かす、という当たり前のことをファイルとして体系化している。
ログファイルに記録する内容:
- 実験の仮説（何を検証しようとしたか）
- 使用したバリエーション（どんなコピーを試したか）
- 配信日・オーディエンスセグメント
- 結果（CTR、CV率など）
- 結論（何が効いて何が効かなかったか）
実験ログファイルのイメージ:
| |
次のラウンドでの Claude への指示:
過去の広告実験ログ（experiments.md）を読んで、
これまでの成功・失敗パターンを踏まえた上で、
新しい見出しを20本生成して。
過去に失敗したアプローチは避けて、成功したパターンを発展させて。
なぜ「自己改善」と呼べるのか:
| 方式 | 過去の実験結果の扱い |
|---|---|
| 人間だけ | 記憶頼り。数十回分の結果を正確に比較するのは困難 |
| メモリシステム | 全実験の結果がファイルに蓄積。Claude が毎回全履歴を参照して傾向を分析 |
回を重ねるほど「何が効くか」のデータが蓄積され、生成精度が上がっていく。また、バリエーションと実験IDを紐付けることで、A/Bテストの結果を個別のコピーに正確に帰属させ、ノイズの混入を防いでいる。
実装のコツ
「いきなりコードを書かない。まず全体のワークフローを設計してから Claude Code に渡す。」
- API でアクセスできる反復作業を特定する
- タスクをサブエージェントに分割する
- Claude.ai でワークフロー構造を設計してから、コード生成に進む
サブエージェントの具体的な作り方
ステップ1: エージェントファイルを作成
.claude/agents/ ディレクトリにマークダウンファイルを置く。YAML フロントマターでメタデータを定義し、本文にそのエージェントの専門ルールを記述する。
.claude/agents/headline-writer.md
| |
.claude/agents/description-writer.md
| |
ステップ2: Claude Code で自然言語で指示する
Claude Code の対話画面で、以下のように指示するだけでサブエージェントが呼び出される:
Claude Codeの広告コピーを、headline-writerとdescription-writerの
サブエージェントを使って各20本ずつ生成してCSVに出力して
Claude Code が .claude/agents/ 内のエージェント定義を自動認識し、2つのサブエージェントを並列実行して CSV を生成する。
なぜ1つのプロンプトではなくサブエージェントに分けるのか
| 方式 | 品質 | 文字数制約 | デバッグ |
|---|---|---|---|
| 1つのプロンプトで全部 | 低下しやすい | 守れないことがある | 問題箇所の特定が困難 |
| タスク別サブエージェント | 安定する | 各エージェントが制約に集中 | エージェント単位で修正可能 |
各エージェントが自分の制約だけに集中できるため、文字数制限を守りつつ品質が安定する。また、見出しの品質が悪ければ headline-writer.md だけを修正すればよく、デバッグも容易になる。
他の部門はどう使っているか
Anthropic 公式記事では、マーケ以外の7部門の活用事例も公開されている。
インフラチーム — 新人オンボーディング
コードベース全体を Claude Code に読み込ませ、データパイプラインの依存関係やダッシュボードの上流データソースを説明させる。従来のデータカタログツールの代替になっている。
プロダクトエンジニアリング — バグ修正の起点
Claude Code を「最初に相談する場所」として活用。バグ修正や機能追加に関連するファイルを自動特定し、手動でのコンテキスト収集を排除。
プロダクトデザイン — テスト自動化と React 開発
デザイナーが包括的なテストを作成し、GitHub Actions で PR コメントを自動化。データサイエンティストが TypeScript に精通していなくても可視化ツールを構築できるようになった。Vim キーバインディングも最小限のレビューで構築。
セキュリティエンジニアリング — 3倍速の問題解決
スタックトレース分析とテスト駆動開発により、問題解決速度が3倍に。「設計 → 不安定なコード → 諦める」というワークフローが、「信頼できるテスト可能なコード」に変わった。Rust のような不慣れな言語のテストも翻訳して生成。
推論チーム — リサーチ時間 80% 削減
複数のドキュメントソースを Claude に取り込み、モデル固有の関数を説明させる。調査時間が約1時間から10〜20分に短縮（80%削減）。トラブルシューティング用のマークダウン Runbook も自動作成。
データインフラ — 障害対応 20分短縮
本番障害時にダッシュボードのスクリーンショットを Claude に渡し、Kubernetes の Pod スケジューリング問題を診断。Google Cloud の UI をガイドして IP アドレス枯渇を特定。システム障害中の20分を節約。
法務チーム — 非開発者がプロトタイプ構築
社内メンバーを適切な弁護士に接続する「電話ツリー」システムのプロトタイプを、法務チームのメンバー自身が構築。非開発者がカスタムソリューションを作る事例。
共通パターン — 全部門に見られる5つの原則
| 原則 | 説明 |
|---|---|
| コード生成器ではなく「思考パートナー」 | Claude を単なるコード出力マシンとしてではなく、問題を一緒に考える相手として扱う |
| ラピッドプロトタイピング | アイデアの検証を素早く行い、ダメなら捨てて別のアプローチを試す |
| 職種の壁を越える | デザイナー、データサイエンティスト、マーケターが技術的な問題を自力で解決 |
| サブエージェント分割 | 複雑なタスクを専門エージェントに分割して品質を維持 |
| 自動化対象の見極め | コーディング能力ではなく「何を自動化すべきか」を判断する能力が重要 |
再現してみた — 15分で広告バナー200本
izanami.dev の記事では、Anthropic マーケチームの手法を実際に再現している。
手順と所要時間
| ステップ | 内容 | 時間 |
|---|---|---|
| 1 | .claude/agents/ にサブエージェント（headline-writer, description-writer）を作成 | 2分 |
| 2 | Claude Code に CSV 出力を指示 | 3分 |
| 3 | Figma プラグインを Claude Code で構築（manifest.json, ui.html, code.js） | 5分 |
| 4 | HTML テンプレート作成 → Figma に送信 | 3分 |
| 5 | プラグイン起動 → CSV アップロード → バナー一括生成 | 1分 |
| 合計 | 約15分 |
コードは1行も手書きしていない。すべて Claude Code が生成。
評価 — Anthropic がやっていることの本質
自社が最強のユースケースになっている
Anthropic は「AI ツールを売る会社」であると同時に、自社が最も過激なユーザーでもある。全部門が Claude Code を日常業務に組み込み、その結果をフィードバックして製品を改善するサイクルが回っている。これは「ドッグフーディング」の最も効果的な形態。
「非エンジニアが自動化する」の実証
最もインパクトがあるのは、エンジニアがゼロのマーケティングチームや法務チームが、自分でツールを作っている点。これは「AI がコーディングを民主化する」という主張の、最も説得力のある実例になっている。
サブエージェント設計の実用性を証明
1つの万能プロンプトで全部やらせるのではなく、タスクごとに専門エージェントを分割する設計パターンが、実務レベルで品質向上に効くことを示した。
懸念点
- 再現性の問題: Anthropic 社内だからこそ Claude Code の最新機能にアクセスでき、社内サポートもある。一般企業で同じレベルの成果が出るかは未知数
- プロモーション的側面: 自社製品の活用事例を自社が発信している以上、成功事例にバイアスがかかる可能性はある
- スキルの属人化: 「コードを書かなくていい」とはいえ、ワークフロー設計能力は必要。その能力をチーム全体に展開できるかは別の課題
総合評価
それでも、「AI ツールメーカーが自社の全部門で使い倒し、非技術者でも15分で200本のバナーを作れることを実証した」という事実は大きい。プロンプトの書き方だけでなく、サブエージェント設計、MCP 連携、メモリシステムまで含めた実践的なコンテキストエンジニアリングの好例として、参考にする価値は十分にある。