ハクソク

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

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

2025年7月25日原文(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のルートがまだうまくいってないから、もっとソフトウェアエンジニアを雇う必要がありそうだ。

Hacker Newsで議論の続きを見る