ハクソク

世界を動かす技術を、日本語で。

Anthropicチームが「Claude Code」をどのように活用しているか

289日前原文(anthropic.com)

概要

Anthropicの各部門が Claude Code を活用し、業務効率化とスキルギャップの解消を実現 データインフラ、プロダクト開発、セキュリティエンジニアリング など多様なチームの事例紹介 自動化・ドキュメント生成・オンボーディング の効率化 非エンジニア職でも 複雑なワークフローの自動実行 が可能に 導入を検討する組織への 実践的なアドバイス も掲載

Claude Codeによるデータインフラ業務の変革

  • Data Infrastructureチームは 社内全体のデータ整理・管理 を担当

  • ルーチン作業の自動化、インフラ障害対応、ドキュメント生成 にClaude Codeを活用

  • エンジニア以外のスタッフ もデータワークフローを自力で操作可能

    • Kubernetes障害対応
      • ダッシュボードのスクリーンショットをClaude Codeに入力し、 Google Cloud UIの操作手順・コマンド生成 で専門知識不要の障害解決を実現
    • Financeチーム向けプレーンテキストワークフロー
      • 非エンジニアが手順をテキストで記述し、 Claude Codeが自動実行・Excel出力 まで対応
    • 新規メンバーのコードベース理解支援
      • Claude.mdファイルを活用し、 依存関係や関連ファイルの説明 を自動化。従来のデータカタログ不要
    • 作業セッションの自動要約・ドキュメント更新
      • Claude Codeが 作業内容の要約・改善提案 を行い、継続的なドキュメント改善サイクルを構築
    • 複数プロジェクトの並行管理
      • 複数インスタンスで 文脈保持したままタスク並行処理 が可能

  • チームへのインパクト

    • 専門知識なしでインフラ障害対応
    • 新規メンバーの即戦力化
    • 大量データ監視の自動化
    • ノーコードによる部門横断的な自己解決推進

  • 実践的アドバイス

    • 詳細なClaude.md作成 でパフォーマンス向上
    • MCPサーバー利用 でセキュリティ強化
    • チーム内デモセッション でノウハウ共有

Claude Codeによるプロダクト開発の効率化

  • プロダクト開発チームは Claude Code自体のアップデート や エンタープライズ機能拡張 を担当

  • 高速プロトタイピング・自動テスト生成・バグ修正 にClaude Codeを活用

    • 自動受諾モードによる高速プロトタイピング
      • "auto-accept mode"で コード作成～テスト～反復 まで自律実行。80%完成時点で人間が仕上げ
    • 重要機能は同期型で詳細指示
      • ビジネスロジック等のコア部分 は詳細プロンプトを与え、リアルタイム監督下で開発
    • Vimモード実装の事例
      • 機能の70%をClaudeが自律開発し、人間が微修正
    • テスト生成・バグ修正
      • Pull Requestコメントから自動修正
    • コードベース探索
      • 未知のコードも Claudeに質問→即座に概要把握 が可能

  • チームへのインパクト

    • 複雑機能の迅速実装
    • 開発速度の大幅向上
    • 自動テストによる品質担保
    • 新規領域のキャッチアップ時間短縮

  • 実践的アドバイス

    • 自己検証ループの構築 （ビルド・テスト・Lint自動化）
    • タスク分類直感の醸成 （自律実行向き/監督必須の見極め）
    • 明確かつ詳細なプロンプト作成 で意図通りの成果物獲得

Claude Codeによるセキュリティエンジニアリングの最適化

  • Security Engineeringチームは 開発ライフサイクル・サプライチェーン・開発環境の安全性 を担保

  • コードレビュー・インフラデバッグ・ドキュメント生成 でClaude Codeを活用

    • 複雑なインフラ障害のデバッグ
      • スタックトレースやドキュメントを入力→制御フロー解析・問題特定 を迅速化
    • Terraformコードのレビュー
      • インフラ変更内容の自動要約・リスク指摘 で承認プロセス高速化
    • ドキュメント統合・ランブック生成
      • 複数ドキュメントを Markdown形式で集約し、トラブル対応効率化
    • テスト駆動開発ワークフロー
      • Claude Code主導で pseudocode→テスト→実装 の流れを徹底
    • プロジェクトオンボーディング
      • Markdown仕様書をClaude Codeで自動解釈→貢献開始までの期間短縮

  • チームへのインパクト

    • 障害解決時間の大幅短縮
    • セキュリティレビューの高速化
    • 部門横断的な貢献の促進
    • 効率的なドキュメントワークフロー

  • 実践的アドバイス

    • カスタムスラッシュコマンドの積極活用
    • Claudeに自律的に作業させ、定期的にチェック
    • ドキュメント生成にも活用し、即利用可能な成果物を得る

Claude Code導入の全社的インパクトと実践ポイント

  • 専門知識の壁を超えた業務効率化
  • オンボーディング・ワークフロー自動化・大規模データ処理 の推進
  • 非エンジニア部門での活用例増加
  • ドキュメントの質と量が成果に直結
  • セキュリティ・ガバナンスにも注意しつつ活用範囲を拡大

導入検討組織へのアドバイス

  • 詳細なワークフロー・ドキュメント整備 が成功の鍵
  • セキュリティ要件に応じたアクセス制御 を徹底
  • 定期的なチーム内ノウハウ共有セッション で活用事例を蓄積
  • 自動化と人間の監督バランス を意識した運用設計
  • Claude Codeの得意分野（自動化・ドキュメント生成・テスト）を最大限活用

Hackerたちの意見

数週間、Gemini Cliを使った後にClaude Codeを試してみたんだけど、ツールの使い方にちょっと良い点があって、それは嬉しい。でも、Claudeはちょっと頭が悪い気がして、「物事を終わらせる」ことに必死で、常識や明確な指示、設計情報を無視することが多いんだ。テストパスを作るように指示すると、デバッグを避けるためにデータベースの構造を変えちゃうことがある。少なくとも2回は、プロジェクトからprotobufを削除してJSONに置き換えたことがあった。プロトの問題をすぐにデバッグできなかったからね。

└

面白いのは、計画のステップでちょっとでも問題が起きると、「保留中」と言って、その理由を適当につけるところだね。人間が判断を使って作業を保留するのは時々許されるけど、機械には判断がないから、それをするのは許されないんだ。

└

私も同じことがあったよ。いくつかの包括的なテストが失敗して、複雑なテストがなぜ失敗したのか調べる代わりに、シンプルなテストを書くことにしたみたい。チームが計算を節約しようとして、タスクをもっと早く終わらせるように促してるのかな？Claudeは計算リソースが厳しいみたいで、APIのタイムアウトやエラーがよく出るんだ。

└

それに、コードベースを積極的に削除して、しかもそれを顔を見ながら嘘をつくって聞いたことあるよ。

Claudeを使ってるし好きなんだけど、この投稿はちょっとぎこちない感じがする。だから、ブログチームもClaudeを使ってるのかな。

└

うん、これは提供するには驚くべき量の情報だけど、基本的には洗練された箇条書きみたいな感じだね。

└

その通りだね！

└

クロードを使うこと自体が問題だとは思わない。実際、文章はかなり不器用で素人っぽいところがあって、実際に人間が書いたんじゃないかって感じ。全体の投稿は、調査の回答を集めたようなもので、組織的な流れもなく、繰り返しや空っぽの回答をフィルタリングしてない。誰も責任を持ってないんだよね。

└

MCPのドキュメントサイトも同じ問題を抱えてる。基本的に、詳細なしの箇条書きのリストだけなんだよね。

└

それも疑い始めたけど、スタイルよりも内容に大きな問題があると思う。 > 「複雑なKubernetesのコマンドを覚える代わりに、正しい構文をClaudeに尋ねて、"すべてのポッドやデプロイメントのステータスを取得する方法"と聞くと、インフラ作業に必要な正確なコマンドを受け取る。」って、LLMに技術的な質問をするのは当たり前じゃん。こんなことを最先端技術を扱ってる会社の技術ブログに載せる意味がわからない。

繰り返される傾向として、Claude Codeは70-80%のところまでしか行かないことが多い。これはまあいいんだけど、エージェントを推してる人たちにはもっと強調してほしいな。このポイントは面白いよね: > スロットマシンのように扱え > Claudeに作業させる前に状態を保存して、30分間走らせて、その結果を受け入れるか、最初からやり直す方がいい。修正に苦労するよりも、やり直す方が成功率が高いことが多い。これは、従業員がClaude Codeを半時間動かすための膨大な計算費用を自分で払っていないときは言いやすいけどね。

└

アドバイスありがとう - 我々従業員は、変更がかなり良くてもコード生成を何百回も実行すべきだね。そうすれば、上層部は多くの実際のコミットなしに大きな請求書を見ることになる。ごめん、ボス。AIのルートがまだうまくいってないから、もっとソフトウェアエンジニアを雇う必要がありそうだ。

└

これは、従業員がClaude Codeを半時間動かすための膨大な計算費用を自分で払っていないときは言いやすいよね。月200ドルで同じことができるし。

└

これはみんなにとって簡単な計算だよ。Claudeがパフォーマンスを十分に向上させてくれているか考えてみて、そうでなければ…高すぎるってことだよね。確かに、ドメインやレガシー、コードベースの複雑さの組み合わせによっては、Claudeが合わない人もいるだろうね。

└

繰り返しの傾向として、Claude Codeは70-80%のところまでしか行かないってことがあるけど、それはまあいいことで、エージェントを推してる人たちにはもっと強調してほしいな。私はコード生成にLLMを使うのが結構成功してるよ。90%以上はAIに任せるか、全く使わないっていうシンプルなルールがあるんだ（インライン補完や明らかなテキスト編集は除く）。モデルはトレーニングデータのおかげで、いくつかの問題をほぼ100%の確信で理解してるから、数分でサクッと終わらせられるし、その後は非常にシンプルなコードフローのアーキテクチャを設定できるんだ。これで出力が30%-50%も改善されることがあるよ。

└

スロットマシンの話には、かなり説得力のある副産物があるね。フォーマルなシステムの厳密さをできるだけ高めるってこと。Pythonでのバイブコーディングは魅力的だけど、結局は大きな請求書を抱える羽目になる。Haskellでのバイブコーディングは「クリーンで正確、メンテナブルなコード1単位あたりにどれだけお金を注ぎ込む覚悟があるか」っていうエクササイズだよ。GHCを-Wall -Werrorにして、ちょっと厄介なプロパティテストを加えたらどうなるか？Claude Codeがごまかそうとするのを見るのは、イライラから面白くなる瞬間がある。ほら、未使用のパラメータが出てきた！なんでテストスイートが未使用のパラメータに対してプロパティが成立することを求めてるんだろう… Haskellは一例に過ぎなくて、TypeScriptはその型システムにおいてさらに強力な面があるから、たくさんのプロジェクトが「ハイパーモダンバイブコーディング」に手を出す余地がある。厄介なfastcheckやジェネリックバウンドをたくさんかけて、Claude Codeがどうやってごまかそうとするか見てみてよ。さあ、Claude Code、TODOリストのその行をチェックしたいのは分かってるから、どうするつもり？だいたい、結局は諦めて、君が払った分の仕事をしてくれることが多いよ。

└

それに、もし従業員が普段は結構いいコードを書けるけど、30%の確率で全く機能しないものを書いてしまったら、完全に廃棄しなきゃいけないから、解雇されるだろうね。

└

繰り返される傾向は、Claude Codeが70〜80%のところまでしか行かないってこと。これはまあいいことだし、エージェントを推してる人たちにはもっと強調してほしいなと思う。最近、これがプロジェクトの最初の70〜80%だけでなく、時には最後の70〜80%にも当てはまることに気づいた。大規模なリファクタリングを最初からClaudeで進められなかったから、自分で実装を始めたんだ。アイデアを十分に形にした段階で、Claudeに戻して仕上げてもらったら、最後のCHANGELOGのエントリーまで完璧に動いた。追加の入力は一切いらなかったよ。これは、広範なガードレールや例によるプロンプトの一形態だと思った。

└

俺の最もよく使うコマンドシーケンスは > /undo > /clear > ↑ ↑ ↑ ⏎ だね。

└

個人的に好きなのは、CCが「完了しました」って言うためだけにトークンを消費すること。ClineやRooみたいに、トークンをただ消費するだけのものよりは全然マシだよ。

└

これが、この商品を売ってる人たちのマーケティングピッチだね。¯_ (ツ)_/¯

Claude Codeはいろんなことにうまく機能するよ。例えば、昨日は天気サイトのバックエンドの天気APIを切り替えてみたんだけど、APIがかなり違ってもほぼ一発で成功したんだ。自宅では月20ドルのサブスクリプションで使ってて、職場ではAWS Bedrockを通じて試してる。Bedrock APIを使うと、セッションの終わりに使った金額が表示されるんだけど、ちょっと不安になるよね。推論の細かいメーターリングが一時的な状況であることを願ってる。そうじゃないと、ソフトウェア開発者に冷却・抑止的な影響を与えて、実験や書き直しが減って、全体的な品質が下がると思う。Anthropicは内部でメーターなしで使えるから、この問題を完全に回避してるんじゃないかな。

└

昔々、エンジニアはデータセンターの請求書、クラウドの請求書、そして最終的にはSaaSの請求書を気にしなければならなかった。AIの費用が人間の時間に比べて trivial になるまで、あと5〜10年はAIの請求書を気にすることになるだろうね。

└

家では月20ドルのサブスクリプションで使ってて、仕事ではAWS Bedrockを使って試してるんだ。BedrockのAPIと一緒に使うと、セッションの最後に使った金額が表示されるんだけど、ちょっと気になるよね。推論の細かいメーターリングが一時的なものであることを願ってる。そうじゃないと、ソフトウェア開発者に冷や水をかけることになって、実験が減ったり、リライトが少なくなったりして、全体的に品質が下がると思う。君の意見には本当に驚いてるよ。細かいコストを常に見せられるのはあまり好きじゃないけど、エージェントのプロンプト設定を実験してるときに、クエリのコストがわかるのは好きなんだ。時々、言い回しを変えるだけでかなり安くなることもあるし。なぜそれが冷や水をかける効果につながると思うの？エンジニアがコストを下げるために無慈悲に革新する普通の効果じゃないの？

└

先週末、基本的なMLB APIを渡して、MacOS用のウィジェットを作ってくれって頼んだんだ。リーグやディビジョン、ワイルドカードの順位を表示するやつで、どれを表示するか選ぶ基本設定もつけて。半時間くらいで、最小限の入力で動くウィジェットを作ってくれたよ。ちょっとSwiftを知ってるから、何をしてるか確認したんだけど、クイックハックプロジェクトとしては全ての作業をやってくれて、問題があったところも簡単に更新してくれた。ああいう一回限りのものとしては、全然悪くないね。君の例ともあまり変わらないよ。

└

一方で、私はそれに自分が思うには些細な関数を書かせるんだけど、微妙に間違っていて、テストすると明らかになる。もし私が君なら、もっと疑った方がいいと思うよ。

└

それは使ったドル額を表示するから、ちょっと気になるよね。俺は、モンスタークロードコードセッションが会社に請求した多分$10の料金なんて全然気にしないよ。彼らは「コストを心配しないで、どうやって使うか考えてみて」ってはっきり言ってたし。

最初の例はk8sの問題をデバッグする手助けをしてくれたんだけど、IPプールの枯渇が原因だって診断して、Claudeがネットワークの専門家なしで修正を手伝ってくれた。でも、もし最初からネットワークの専門家がいたら、そもそもそのエラーを回避できたんじゃないかな？

私の最適化ハックは、今Claude Codeと音声認識を使ってること。人と話すみたいに、物事の全体の文脈や歴史を説明できるから、全部タイプするよりずっと早いよ。

└

SuperWhisperアプリは素晴らしいよ、Macを使ってるならね。

└

じゃあ、部屋に座ってそれに話しかけるの？変な感じしない？俺は話すよりもタイピングの方が速いんだよね :D

面白い投稿だね。私たちのチームはClaude Codeを使いたかったんだけど、チームプランにはClaude Codeが含まれてなくて（同じ価格帯のプロプランには含まれてるのに）。購入した後にこれを知った :( すべてのエンジニアに別々に購入させるつもりはないよ。自社の製品を使ってるって自慢する前に、外部企業がそれを支払えるオプションを追加してほしいな！業界をリードするAIモデルなのに、サブスクリプション管理みたいな基本的なことが解決されてないのは驚きだよ…

└

なんで別々に購入するように頼まないの？

Kubernetesクラスターがダウンして新しいポッドをスケジューリングできなかったとき、チームはClaude Codeを使って問題を診断した。彼らはダッシュボードのスクリーンショットをClaude Codeに送り、Google CloudのUIメニューを一つずつ案内してもらいながら、ポッドのIPアドレス枯渇を示す警告を見つけた。Claude Codeは新しいIPプールを作成してクラスターに追加するための正確なコマンドを提供し、ネットワーキングの専門家を巻き込む必要を回避した。これはかなり非効率的に思えるし、Claude Codeが必要だったのも驚きだね。

└

彼らは、理解する代わりにAIが必要な世界を助成している。少なくとも、誰が助けてくれるのかを知っているべきなのに。結局、私たちは愚かになりすぎて、AIの奴隷になってしまうんだ。

└

うん、これはインターンか非常にジュニアなエンジニアから期待する内容だね（ここでもそうかもしれないけど）。

私は、ほとんどのコードを最終的に自分で書く間、Claudeコードを賢いラバーダッキーのように使うのが好き。Claudeには、まずチャットでやりたいことを説明させるルールを追加した（コードの変更は私が求めた時だけ実施する）。アイデアについて話したり、解決策やアプローチを議論するのが好きなんだ。でも、最終的には私がコードの責任者だから、コントロールは私が持ってる。自動でファイルを変更するのは好きじゃないから、ターミナルからIDEにコードをコピー＆ペーストしてる。最初は遅いように感じるけど、Claudeに自分の好みの解決策を促すよりも、問題をその場で素早く修正できるからね。私にとっては、これがもっと理にかなってる。コントロールが効くし、問題のあるコードを見つけやすいから。こういう問題を修正する時は、その後Claudeに変更を指摘して、文脈を追加してる。私にとってClaudeは、非常に自信過剰なジュニア開発者みたいな存在。目を離さないようにしないといけないし、もし自分でやった方が早いなら、さっさとやって、なぜそうしたのか説明するだけ。 （これはジュニアには良くないアプローチかもしれないけど、Claudeには私には合ってる）ところで、このブログ投稿がツールを売ろうとしている会社によって書かれているってこと、話してもいい？だから、これを鵜呑みにするのは危険だよ…。AI企業が言ってることの90%は無視した方がいいかもね。彼らはお金を集めたいか、最終的には他の会社に買われたいだけなんだから…。

└

プランモードにしておけば、何も変わらないってこと？ジェミニCLIみたいに、ためらわずに実装に突入するのとは違うね :D

CCを使ってウェブアプリを一から作ってメンテもしてきたし、他のツールもたくさん使ったよ（AIコーディングツールの使い方を教えるクラスもやった）。今までのところ、CCを使う最も効果的な方法はこのワークフローだね：mdファイルに詳細で圧縮された仕様を書いておく。何でもいいけど、毎回のプロンプトで明示的に参照するからね。（CCはCLAUDE.mdをすぐ忘れちゃうことが多い）ユーザーストーリーから始めて、高レベルの段階的実装計画を原子ステップで書くように頼む。これをレビューして、必要に応じてCCに書き直させる。（別のmdファイルができる）そのファイルを基に、詳細な実装計画も原子段階で書くように頼む。それを一緒にレビューして、実装する準備ができているか聞いてみて。そしたら、クロードにブランチで実装を進めるように指示するのを忘れずに。自動テストと機能テストも忘れずにね。それからマージする。