Anthropicの各チームがClaude Codeを活用する方法

• Anthropicの各部門（データインフラ、製品開発、セキュリティ、インファレンス、データサイエンス、マーケティング、デザイン、RLエンジニアリング、法務など） はClaude Codeを導入し、複雑なプロジェクトの自動化、作業効率化、非開発者業務の拡張 などで革新的な変化を経験している
• Kubernetes障害復旧、新規入社者のオンボーディング、大規模データ監視、財務チームの非開発ワークフロー自動化 などで、Claude Codeが実際の問題解決と生産性向上 をけん引している
• 迅速なプロトタイピング、コードベース探索、自動テスト生成、反復業務の自動化 を通じて、従来比2〜4倍の時間短縮、開発速度と品質の改善 を達成している
• デザイン、マーケティング、法務などの非開発部門でも、カスタムエージェント、Figma/Google Ads/Meta Ads連携など により、エンジニアのリソースなしで複雑な自動化やツール作成 が可能になっている
• 各チーム別に主な活用のコツを共有：Claude.mdの文書化、反復チェックポイント、具体的なプロンプト、視覚的フィードバック、チーム内ワークフロー共有 など

---

概要

Anthropicは社内のさまざまなチームでClaude Codeを業務に適用し、開発者・非開発者を問わず、複雑なプロジェクト処理、反復業務の自動化、学習曲線の短縮などによる 生産性革新 を実現している。本文では、10部門 が実際にClaude Codeをどのように活用しているかに加え、チーム別の効果的な使い方、導入時の検討事項、活用のヒントを詳しく紹介している。

---

Data Infrastructureチーム：データインフラでのClaude Code活用

主な活用事例

• Kubernetesデバッグ
  • Kubernetesクラスター障害時に、Claude Codeへダッシュボードのスクリーンショットを入力し、Google Cloud UIでの問題箇所への導線案内や、解決に必要なコマンド提案を受ける
• 非開発者向けプレーンテキストワークフロー
  • 財務チームなどの非開発者がプレーンテキストでデータフローを記述すると、Claude Codeがワークフローを自動実行し、入力値の確認やExcel成果物の生成などを支援する
• 新メンバーのコードベース探索
  • 新任データサイエンティストがClaude Codeを使ってClaude.md文書とコードベース構造を把握し、データパイプライン依存関係の説明やダッシュボードソースの確認を行う
• セッション終了後の文書自動要約
  • 各作業終了時に作業内容を自動要約させ、Claude.md文書の改善案も提示させる
• マルチインスタンス並列作業
  • 複数のリポジトリでClaude Codeインスタンスを並列運用し、プロジェクト間のワークフロー状態やコンテキストを失わずに作業を切り替える

チームへの影響

• 専門家の助けなしでインフラ問題を解決
• 新メンバーのオンボーディング速度が大幅向上
• データ異常検知の自動化など支援ワークフローを強化
• 非開発部門のセルフサービス型業務処理を実現

主なヒント

• Claude.mdファイルに詳細を文書化する
• 機密データ処理ではBigQuery CLIの代わりにMCPサーバーを推奨
• チームごとに利用セッションを共有してベストプラクティスを広める

---

Product Developmentチーム：製品開発でのClaude Code活用

主な活用事例

• 自動化ループによる高速プロトタイピング
  • auto-accept mode を設定し、抽象的な問題をClaudeに任せて80%程度の結果を受け取り、最後の修正を行う
• 同期的コーディング（リアルタイム共同作業）
  • コア機能開発時にリアルタイムでプロンプトやコードガイドラインを与え、Claudeが反復的なコーディングを担当する
• Vimモードなど独立機能の実装
  • 自動化で70%以上を実装し、その後の反復的な補完で仕上げる
• テストケースとバグ修正の自動化
  • PRレビュー段階でClaudeが書式修正、関数名変更などを自動反映する
• コードベースの迅速な探索
  • 複雑なモノレポ構造やAPI側コードについても、Claudeに構造や依存関係を質問する

チームへの影響

• 複雑な機能を自動化で高速実装
• プロトタイプの反復・拡張時間を削減
• 自動テストカバレッジとコード品質を向上
• 未知のコードベース探索効率を向上

主なヒント

• 独自の検証ループを構築する（ビルド、テスト、lintの自動化）
• 非同期作業と同期作業を分けて適用する
• 明確で具体的なプロンプトを作る

---

Security Engineeringチーム：セキュリティエンジニアリングでのClaude Code活用

主な活用事例

• 複雑なインフラデバッグ
  • スタックトレースと文書を入力すると、制御フローを追跡する
• Terraformコードレビューと分析
  • Claudeに計画書を入力して、セキュリティ影響を迅速にレビュー・承認する
• 文書統合とランブック作成
  • 複数文書を取りまとめて、TroubleshootingガイドやRunbookの要約を生成する
• テスト駆動開発（TDD）の実装
  • pseudocode→TDD→定期点検の流れをClaudeと協働で進める
• コンテキストスイッチ短縮とオンボーディング
  • Markdown仕様をClaudeに入力し、短期間でチームに貢献できるようにする

チームへの影響

• インフラ問題への対応時間を5分以内に短縮
• セキュリティ承認の待ち時間を排除
• 短期間で他プロジェクトにも貢献可能
• 文書化ワークフローの効率を最大化

主なヒント

• カスタムスラッシュコマンドを積極活用する
• Claudeに自律的なコーディングを指示する
• 文書化や出力フォーマットを明確に伝える

---

Inferenceチーム：推論システム運用での活用

主な活用事例

• コードベースの迅速な理解とオンボーディング
  • 機能呼び出しファイルや依存関係などをClaudeに即座に質問できる
• エッジケースを含むテストの自動生成
  • 機能実装後、Claudeがテストを自動生成し、人はレビューのみ担当する
• 機械学習概念の説明
  • モデルごとの関数や設定をClaudeに直接質問する（Google検索と比べて80%時間削減）
• 多言語コード変換
  • 望むロジックをRustなど不慣れな言語へ変換する
• Kubernetesコマンドの常時案内

チームへの影響

• 機械学習の研究・学習時間を80%削減
• コードベース探索を即時処理
• 自動テストで品質を維持
• 言語の壁を解消

主なヒント

• まず知識ベースへの質問を試す
• コード生成を指示した後で結果を検証する
• テストの直接作成を指示して負担を減らす

---

Data ScienceおよびML Engineeringチーム：データサイエンス・機械学習エンジニアリング

主な活用事例

• JavaScript/TypeScriptダッシュボードアプリ構築
  • JS/TSの経験がほとんどなくてもReactダッシュボード全体を作成でき、RLモデル性能分析などで効果的
• 反復的リファクタリングの自動化
  • マージコンフリクトやファイル構造変更などの反復作業を30分間完全自動化で処理し、成功すればそのまま導入する
• 永続的な分析ツールの開発
  • 単発のノートブックではなく、再利用可能なReactダッシュボードを構築してモデル性能分析に活用する
• 依存知識ゼロの課題委任
  • まったく知らない言語やコードベースでの作業もClaudeに丸ごと委任して進める

チームへの影響

• 日常的なリファクタリングを最低でも2〜4倍高速化
• 不慣れな言語でも複雑なアプリを構築
• 分析ツールを単発用途から継続利用へ転換
• モデル性能の可視化で意思決定の質を向上

主なヒント

• スロットマシン的に活用する（結果ごとに採用/再試行）
• 複雑なほど自分で介入し、単純化を促す

---

Product Engineeringチーム：製品エンジニアリングの現場活用

主な活用事例

• 最初の段階でClaudeにファイル一覧やパスを尋ね、迅速にワークフローを設計する
• 不慣れなコードベースで独立してバグをデバッグし、機能開発を進める
• 最新研究モデルを試すDogfooding
• コンテキスト切り替えコストの削減で作業への集中度を高める

チームへの影響

• 未知のコード領域でも独力で作業可能
• コンテキスト切り替えや回答待ちの負担を軽減
• ローテーションエンジニアのオンボーディング速度を向上
• 開発者の仕事満足度と生産性が向上

主なヒント

• 協業パートナーとして捉え、反復的に取り組む
• 不慣れな課題にも大胆に挑戦する
• 最小限の情報から始め、Claudeの案内に沿って進める

---

Growth Marketingチーム：グロースマーケティング自動化

主な活用事例

• Google Adsコピーの自動生成
  • 掲載枠の文字数に合わせた広告見出し・説明文を生成し、大量の広告作成を自動化する
• Figmaプラグインによる大量クリエイティブ制作
  • 複数の広告画像や文言をプログラム的に生成する（最大100件）
• Meta AdsデータをMCPサーバーでリアルタイム分析
  • 広告キャンペーン実績や出稿金額などの分析を自動化する
• メモリーシステムを活用した反復実験ログ記録
  • クリエイティブ実験結果を記録し、次回の生成に活用する

チームへの影響

• 広告コピー作成時間を2時間から15分に短縮
• クリエイティブ生成量が10倍以上に増加
• 1人のマーケティングチームでも大規模な開発・分析業務を直接処理
• 業務の焦点を全体戦略と自動化へ移行

主なヒント

• API連携を伴う反復業務から自動化を検討する
• 大きなワークフローは役割別のサブエージェントに分割する
• Claude.aiで十分にプロンプトを設計・構造化してからClaude Codeで実装する

---

Product Designチーム：プロダクトデザイン業務の革新

主な活用事例

• フロントエンドの視覚改善と状態管理を直接調整
  • デザイナーがClaude Codeで即座にUIを改善し、状態変化を実装する
• GitHub Actionsベースのチケット化と自動コード提案
  • フロントエンドやバグ修正の依頼時に、Claudeが自動でコード提案を行う
• インタラクティブなプロトタイプを迅速生成
  • モックアップ画像を貼り付けると、動作するコードを即座に生成する
• エッジケース状況やアーキテクチャの把握
  • システム状態やエラーフローなどを設計段階で直接探索する
• 複雑なコピー変更とリアルタイムのコンプライアンス管理
  • コードベース全体で特定文言を一括修正し、法務との協業をリアルタイムで進める

チームへの影響

• FigmaとClaude Codeをベースとした業務へ転換
• 視覚面や状態管理の改善が2〜3倍高速化
• 複雑な協業プロジェクトも1週間から1時間以内に短縮
• 開発者とデザイナーそれぞれに最適化された体験
• コミュニケーションと設計の水準が大幅向上

主なヒント

• 初期セットアップにはエンジニアの支援が必要
• Custom memoryファイルで役割や説明スタイルを事前指定する
• 画像の貼り付けでプロトタイプを作成する

---

RL Engineeringチーム：RLサンプリングと重み管理

主な活用事例

• 中小規模機能の開発で自律+監督方式を採用
• テスト生成とコードレビューの自動化
• デバッグやエラー分析でClaudeを活用
• コードベース要約とコールスタック分析の自動化
• Kubernetes関連の質問で運用実務を支援

業務方式の変化

• 実験的なチェックポイント+ロールバック方式が定着
• 文書自動生成の時間を節約
• 中小規模PRでは約1/3の確率で一発完成

主なヒント

• Claude.mdに繰り返しのミス防止事項を明記する
• 頻繁なコミットとロールバックを習慣化する
• ワンショット→協業パターンを適用する

---

Legalチーム：法務チームでのAI活用

主な活用事例

• 個人向けアクセシビリティソリューションを短時間でカスタマイズ
  • 家族向けのPredictive Textアプリなどを自作する
• 部門内ワークフロー自動化のプロトタイプ
  • チーム別の電話接続ツリーや、G Suite連携業務の自動化
• プロトタイプ中心のイノベーション
  • 素早くプロトタイプを作成し、専門家のフィードバックを集めて実利用を検証する
• 視覚中心のフィードバックと開発
  • インターフェースのスクリーンショットを使ってClaudeとコミュニケーションする

セキュリティ・コンプライアンス認識

• MCP連携時に即座にセキュリティ課題を把握
• AIシステム拡大に伴い、コンプライアンスツール構築を優先的に進める必要

主なヒント

• Claude.aiでアイデアを十分に企画・構造化してから進める
• 作業段階ごと・スクリーンショットベースで依頼し、負担を軽減する
• 完成度の低いプロトタイプでも積極的に共有する

---

[GN⁺]

Hacker Newsの意見

• Claude Codeは、だいたいいつも70〜80%くらいまでしかやってくれない傾向がある。この点はもっと強調されてよかったと思う。たとえば「スロットマシンのように使え」「実行前に状態を保存して、30分作業させる単位で区切って使え。結果を受け入れるか最初からやり直すほうが、途中で修正しようと頑張るよりましだ」といった助言は面白い。でも、こういうことを気軽に言えるのは、自分で計算資源のコストを払っていない状況だからでもある
  • 従業員の立場から見ると、「良い結果が出てもコードを何百回も生成・修正しろ」という助言は面白い。そんなことをすれば、会社には莫大な請求書だけが残り、実際のコミットはほとんど増えないだろう。「AIですべて解決すると思っていたのに、もっと多くの開発者を雇わないといけない」という冗談が出るほどだ
  • 私の場合、LLMをコード生成にかなりうまく使えている。自分のルールとしては、作業全体の90%以上をAIでこなせる場合にだけ意味があると考えている（一部の簡単な自動補完やテキスト編集は除く）。学習データに含まれているタイプの問題（たとえばgolangで簡単なWebサーバーを立てるなど）は、ほぼ100%に近い精度だ。そういう部分は数分でさっと終わらせられるし、アーキテクチャの平板なコードを素早く組める。実際、生産性は30〜50%は上がっている
  • 最近気づいたのは、Claudeの70〜80%完成度という特性が、プロジェクト序盤だけでなく最終段階にも当てはまるということだ。大規模なリファクタリングを最初から自分で進めてアイデアの輪郭だけを作り、その後Claudeに渡したところ、残りの仕上げを完璧に終わらせた（CHANGELOGまで含めて）。これは、例示中心のプロンプトや強いガードレールの例として理解している
  • スロットマシンのたとえに一つ付け加えるなら、可能な限り形式的なシステムの厳密さを高めるのがよい。Pythonで気軽に遊ぶようにコーディングすると、結局結果は悪くなる。HaskellでGHCオプションやプロパティテストなどの形式的チェックを強化すれば、Claudeがごまかそうとしても引っかかる。TypeScriptなどでも、型システム上でより厳密な構造を強制するのは効果的だ。ClaudeはTODOチェックボックスに執着するように、結局は言われた通り正確にやろうとする
  • もし普段はまともなコードを書く社員でも、30%の確率で完全に異常な（使いものにならない）コードを提出して、全面的に作り直しが必要になるなら、おそらく解雇レベルだ
• 私はCCでWebアプリ全体を実装した経験がある。さまざまなAIコーディングツールも使ったし、関連する講義やワークショップもやってきた。CCを最も効果的に使うワークフローは、明確で簡潔な仕様をmdファイルにまとめることだ。それを各プロンプトで明示的に参照する。ユーザーストーリーから始めて、CCに段階的な計画の草案を書かせ、修正・確定のプロセスを繰り返す。その後、実装ガイドラインに従って分業させればよい。自動テストや機能テストも忘れず、最後にマージする流れだ
  • 良い助言だ。私の経験とも似ている。私は最初、ざっくりしたプロンプトを投げてみてから修正していくタイプだ。自分で書いたワークフローもここにまとめてある
  • こういうやり方が、実際に自分でコードを書くより速いのか、あるいは効率が良いのか気になる
  • もしこうやって作業した実例があれば、共有してもらえるとうれしい
  • 私もこのワークフローに近い経験をしたが、こういうやり方自体が本当に嫌いなので、ほとんどいつも結局は自分でコーディングするほうを選ぶ。仕様やユーザーストーリーを書くのがいちばん嫌な作業だ
• Claude Codeはさまざまな作業によく合う。昨日は天気サイトのバックエンドAPIを変更したのだが、2つのAPIがかなり違うにもかかわらず、ほぼ一発でやってのけた。自宅では月額20ドルのサブスク、会社ではAWS Bedrock経由で試験運用している。Bedrock APIで使うと、セッションの最後ごとにコストがすぐ表示されるのだが、これは少し面食らう。実際、こうした細かな従量課金が続くなら、開発者が試行や実験、リファクタリングを避けるようになって、全体としてソフトウェア品質が下がるのではないかと心配している。Anthropicの社内ではコストを気にせず使えそうなので、この問題を回避できるのだろう
  • 数週間前、MLB APIを渡してMacOSウィジェットを作ってくれと頼んだら、リーグ／ディビジョン／ワイルドカード順位などを表示するウィジェットまで、1時間もかからずちゃんと作ってきた。10分ほど確認すれば十分なクイック＆ダーティーなプロジェクトにはかなり有用だ。同じように使える例はいくつかある
  • これまでもエンジニアはデータセンター、クラウド、SaaSなど各種コストを気にしてきたが、今後5〜10年はAI利用料金を気にするようになるのだと思う。結局、人間の時間コストに比べればAIのコストは取るに足らないものになる時期が来るはずだ

  • 「コストが直接見えるのが不快だ」という話があったが、実際のところ、自分のモンスター級Claudeセッションが会社に10ドルくらい請求されても気にしない。会社からも「コストは気にせず、とにかく試してみてくれ」と言われている

  • 私は些細な関数ですらClaudeにやらせると微妙に間違って実装するが、テストですぐ露見するので、もっと慎重になるべきではないかと思う
  • 利用コストが直接見えることに驚いたという意見が興味深い。もちろん、過度に頻繁にコストを見せられるのは嫌だが、エージェントのプロンプトを試すときには、クエリごとのコストを確認できるのは便利だ。プロンプトの一文違うだけでもコストが変わることがあるので、こうした情報はむしろ革新の方向性を与えるのではないか。なぜこれが萎縮効果になるのか気になる。多くのエンジニアは、むしろコスト削減のための工夫にかなり集中すると思う
• ここ数日、Gemini CliからClaude Codeに乗り換えて使っている。ツール使用のループが少し改善されている点は認める。ただ、Claudeは少しだけ「間抜け」で、無理にでも仕事を終わらせようとする。常識や明確な指示すら無視する。たとえばテストを通せと言うと、デバッグする代わりにデータベース構造を変えることがある。2回ほどはprotocol buffersを全部消してJSONに変えたこともあった。単にprotoがデバッグしづらいから、既定の解決策としてそうしたように見える
  • 私も似た経験がある。小さなリファクタリングの途中で、半分ほどはまともに直すのだが、途中で難しそうになると、それまでの変更を全部元に戻して、性急にbashスクリプトで全体を自動化し始める。こういうときに「もう終わっていたはずなのに何をしているんだ」と指摘すると、すぐ認める。強い意見を持っているようでいて、すぐ変わる典型例だ
  • Claudeがテストを「通ったふり」しようとしてごまかすのは、私の経験とも一致する。しばしばテスト自体を削除したりスキップしたりして、「すべての問題は解決した！」と言う。奇妙なことに、こういう挙動は他のLLMでは見たことがない。たいていは失敗を認めて、もう少しヒントを与えれば普通に解決する。Claudeは私がだまされると信じて小細工しているように見える。もっと重大な欠陥に対しても同じように振る舞うのではないかと心配だ
  • 私も大きくは違わない事例を経験した。複雑な全体テストが失敗すると、原因を探す代わりに、簡単に通る断片的なテストへ変えてしまう。Claudeチームが計算資源コストを節約するために、迅速な進行だけを強調しているのではないかと推測している。APIタイムアウトやエラーもしばしば発生する
  • 面白いのは、Claudeがどの段階であれ問題にぶつかると、「作業保留（Deferred）」と言って適当な言い訳をして先に進もうとする傾向があることだ。人間なら判断して作業を後回しにすることもできるが、機械には判断がないのだから、そういう態度を受け入れるべきではないと思う
  • さらには、Claudeがコードベースを大量に削除したうえで、その事実を否認したという話まで聞いた
• Claudeはうまく使っているが、今日見たこのブログ記事は少しぎこちなくて粗い。ブログチームがClaudeで書いたのではないかとさえ思う
  • MCPのドキュメントサイトにも同じ問題がある。ただ不親切な箇条書きが並んでいるだけだ
  • 私も似た印象だが、内容そのもののほうが問題だと感じる。たとえば「複雑なKubernetesコマンドの代わりにClaudeに聞けば正しいコマンドが得られる」という文言は、AI技術ブログでわざわざ強調するほどのことだろうか。基本的なヒントにすぎない
  • 問題はClaudeを使ったかどうかではなく、記事全体がアンケート回答を並べたようにまとまりがなく、反復的で、不要な内容整理がまったくされていないことだ。誰かが責任を持ってキュレーションした部分がない
  • 情報量は多いが、結局は整えていない箇条書きを並べただけという感じだ
• 最初の事例として挙げられていたのは、k8sデバッグでClaudeがIPプール枯渇を診断し、ネットワークの専門家なしで問題を解決したという話だ。だが、そもそもネットワークの専門家が設計していれば、こんなことは最初から起きなかったのではないかという疑問がある
  • 専門家でもミスはする。というより、すべての人間はミスをする
• 最近の私の最適化のコツは、Claude Codeに音声入力を使うことだ。ただ人と会話するように文脈と履歴を説明すればよい。自分でタイピングするよりずっと速い
  • MacユーザーならSuperWhisperアプリがかなり良い
  • 私はpythonパッケージのhnsに満足している。ターミナルで <i>uvx hns</i> と実行し、録音してEnterを押すと、自動でテキストをクリップボードにコピーしてくれる。シンプルだがCLIワークフローに自然に溶け込む。リンク
  • 部屋でAIに向かって口頭で説明するの？ ちょっと気まずくない？ 私はむしろタイピングのほうが速い
  • Ubuntuでも使える良い選択肢があれば知りたい
• Kubernetesクラスタ障害の際、Claude Codeにダッシュボードのスクリーンショットを食わせて、順番にGoogle Cloud UIを分析させ、pod IP枯渇の警告を見つけ、新しいIPプールを追加する方法まで案内してもらったという話だ。だが、このやり方は非効率的で、本当にAIが必要だったのか疑問だ
  • こういうやり方だと、単純な問題ですらAI依存の構造として固定化してしまう。結局、人間が問題の文脈を理解したり、助けを求められる専門的な人脈を持ったりすることさえ忘れて、「AIの奴隷」になる世界が心配だ
  • こういう問題解決のしかたは、インターンや新人エンジニアに期待するようなアプローチだ（実際そういうケースだったのかもしれない）
• 面白い事例だが、うちのチームでもClaude Codeを使おうとしたものの、チーム料金プランには含まれていなかった（同価格帯のProプランでは提供されている）。購入後にこの事実を知ってがっかりした。すべての開発者に個別決済を求めるつもりはない。社内チームの体験を自慢する前に、他の外部企業でも使えるように課金・サブスクリプション構造のほうを先に改善してほしい。業界最高水準のAIモデルを作りながら、サブスク管理のような基本問題はいまだに解決できていない
  • なぜ全員に個別決済させてはいけないと思うのか？
• 私はClaude codeを、賢いラバーダックのように、主にアイデアの議論やフィードバックにだけ使っている。実際のコードの大部分は自分で書く。まずチャットで意見と意図を十分に説明するよう促し、コード変更の依頼は私が言ったときだけ行うようルールを設けている。自分でコピー＆ペーストしてIDEにコードを持ち込み、途中途中で自分の修正を反映しつつ、その変更内容もClaudeに説明する。最初は遅く見えるが、結局は自分のほうが問題点をよく見つけられ、望む方向へより速く磨き上げられる。Claudeは（過剰に）自信満々なジュニア開発者のようなものだ。しっかり監督する必要があるし、自分のほうが速いならそのまま自分でやったほうが有利だ。（ジュニア相手には良くないやり方かもしれないが、Claudeにはうまく機能する。）参考までに言えば、このブログ記事がツールを売る会社によって書かれた点も考慮すべきだ。AI企業のマーケティングは90%くらい差し引いて受け取るべきだと思う。結局、資金を集めるか買収されたいから、ああいう書き方をしているのだろう
  • planモードにしておけば、自動で何も変更しないのでは？ Gemini CLIはためらいなくすぐ実装を始めるタイプだけど :D