Claude Code開発ツール導入事例 — 実装方式は各社でどう違うか

開発者ツール企業はClaudeをどう組み込んでいるか

GitLab・Sourcegraph・Sentry・CircleCI・Semgrepは、いずれも自社の開発者向けプロダクトにClaudeを組み込み、Anthropicの事例ページで実績を公開しています。ただし採用の入り口は一様ではありません。

Claude Platform(API)を直接呼ぶ企業(GitLab・Sourcegraph)や、Amazon Bedrock経由で呼ぶ企業(Semgrep)があります。エージェント基盤ごとAnthropicに任せるClaude Managed Agentsを選んだ企業も、自前のエージェントをClaude Agent SDKで組み立てた企業もあります。この違いは「どこまで自分たちでインフラを作るか」という判断の結果です。

もう一つ、事例を並べると見えてくる軸があります。Claudeの出力が正しいかを、誰がどこで確かめているかです。5社の実装を順に見たうえで、実装方式と検証の置き場所の2軸で、自社に近い事例を探せる形にします。

GitLab Duo:モデル評価チームが支える複数のAI機能

GitLabはDevSecOpsプラットフォーム「Duo」で、コード生成・対話チャット・計画の要約・脆弱性の説明と修復といった複数のAI機能を提供しています。同社はモデル評価チームを社内に置き、新しいベンダーやモデルのバージョンが出るたびに評価し直す体制を取っています。

Group Manager of ProductのTaylor McCaslin氏は「ソフトウェア開発ライフサイクル全体にAIのユースケースを抱えているため、ユースケースごとに最適なモデルを選べるアプローチが必要」と説明しています。GitLabはClaude 3モデルファミリーを採用し、長いコンテキストウィンドウを活かした文脈理解の深いコード生成を評価しました。

内部ワークフロー全体で25〜50%の生産性向上を報告し、AI機能の開発期間は年単位から週単位に縮まりました。人材面の話も載っています。Principal EngineerのJessie Young氏は、機械学習の経歴がない従来型のソフトウェアエンジニア数十人がAI機能の開発に加われたのは、Anthropicの開発者向けツールとドキュメントが取っつきやすかったからだと述べています。

SourcegraphはCodyでモデルの使い分けをどう設計したか

コード検索ツールを提供するSourcegraphは、AIコーディングアシスタント「Cody」の初期リリースから、Claudeを大規模言語モデルの選択肢に加えていました。2024年にはClaude 3モデルファミリー(Haiku・Sonnet・Opus)を全プランで使えるようにしています。

無料プランのデフォルトはClaude Sonnet、Pro・Enterprise向けには長文脈での再現精度に優れたOpus、低遅延が必要な場面ではHaikuという役割分担です。CTOのBeyang Liu氏は「Claudeはユーザーの非公開コードベースの文脈を取り込んで正確に答えることに長けている」と評価しています。

数字は2つあります。Sonnetを無料プランの既定にしてから、コードの挿入率は約75%増えました。ユーザーがCodyの提案から取り込むコードがほぼ2倍になった形で、応答速度は旧モデルのClaude 2.1の2倍です。デフォルトを切り替えたあとの1か月で、Proユーザーの約55%が既定モデルを新しいClaude 3系に変えたとも書かれています。

今後の計画は、システム監視のメトリクスなど新しい文脈の取り込みです。Claude 3の全モデルが持つ200Kのコンテキストウィンドウを使い、Haikuで信頼できるコード変更の生成を目指すと述べています。

SentryはManaged Agentsで何を自動化したか

ソフトウェア監視プラットフォームのSentryは、AIデバッグエージェント「Seer」でエラーの根本原因分析(RCA)にClaudeを使っていました。ただし原因を診断するだけでは開発者の手間は減りません。診断から修正、プルリクエスト作成までを自動化する必要がありました。エラートラッキングSaaSをMCPで繋ぐ実例はRollbar MCPサーバーでエラーの一次調査を任せるにまとめています。

診断を受け取った開発者には、コードベースに移って実装を計画し、コードを書き、プルリクエストを開く作業が残っていました。Sentryはこの受け渡しで時間と勢いが失われていると見ています。コーディングエージェントを動かすには、サンドボックスもライフサイクル管理もエージェント実行基盤も要ります。デバッグが本業のチームにとっては大きな寄り道です。

そこで選んだのがClaude Managed Agentsでした(セッション・ハーネス・サンドボックス分離の考え方はManaged Agentsの設計思想で詳しく扱っています)。Seerがソースコードとテレメトリから根本原因を組み立て、診断をManaged Agents上のClaudeエージェントに渡します。エージェントが解決策を計画してコードを変更し、プルリクエストを作ります。開発者の仕事は、修正を書くことからレビューすることへ移りました。

Senior Director of EngineeringのIndragie Karunaratne氏は「数か月ではなく数週間で初期統合を構築できた」と述べています。この初期統合はエンジニア1人で出荷され、運用面でも独自のエージェント基盤を保守する負担がなくなったそうです。現在は年間100万件超のRCAを処理し、月60万件超のプルリクエストにほぼ即時のレビューを提供する規模に広がりました。

同社はもともとVertex AI経由でClaudeを使っていました。Vertex AI経由なら外部に出すデータを最小にでき、顧客のデータレジデンシーを保ったまま、新しいサブプロセッサーを増やさずに済むという判断です。Managed Agents採用の背景には、すでにClaude Codeを使っていた顧客から、Sentryのデバッグ能力とClaudeのコーディング能力をつなぐ体験を求める声もありました。

CircleCIのChunk:Agent SDKによる自律エージェントと社内導入の両立

CI/CDプラットフォームのCircleCIは、自律型AIエージェント「Chunk」をClaude Agent SDKで構築しています。CircleCIが解こうとしたのは、テストの最適化・ビルド修正・パイプライン改善が機能開発の陰でバックログに積み上がる問題です。AIでコードが速く書かれるほど、保守が追いつかなくなるという見立てもあります。

Chunkに自然言語のタスクを渡すと、検証済みのプルリクエストが返ります。流れは次のとおりです。

手順

Chunkがタスクをプルリクエストにするまで

1. 1

   環境を再現する

   顧客がCI設定に書いたビルド環境を、そのままサンドボックスとして立ち上げます。Claudeは必要な依存関係とツールに触れられます。

2. 2

   文脈を渡す

   ビルド失敗ならログを、テストなら過去の実行結果を、Claudeにコンテキストとして渡します。

3. 3

   修正を生成して検証する

   Claudeが修正案を作り、CircleCIのパイプラインが検証します。失敗すればClaudeが再挑戦します。

4. 4

   緑のPRを返す

   顧客に届くのは、すでにパイプラインが通ったプルリクエストです。テスト・リンター・静的解析の基準を満たした証拠をCIが担います。

Principal EngineerのMichael Webster氏は「Agent SDKがなければChunkは作れなかった」と述べています。3年前なら言語・フレームワーク・ツールチェーンごとの個別対応が膨大で成り立たなかった、というのが理由です。選定の決め手は、Agent SDKの扱いやすさとドキュメントでした。MCPで既存の開発ツールにつなげた点も挙がっています。

開発体制は8人のエンジニアで、動くプロトタイプまで数日、本番投入できる水準まで数週間でした。タスクの起動は3通りあり、フレーキーテストを直す定期実行・失敗したビルドを直すユーザー操作・Chunkのチャットへの自由な依頼です。

稼働後の数字も載っています。Chunkのタスクの5分の4超が、失敗が起きた時点で自動的に起動します。タスクが完成したプルリクエストになる割合は、公開以降2倍超になりました。ある大企業の顧客では、分析時間が14時間から18分に縮んでいます。

Chunkとは別に、社内エンジニアリングチームでもClaude Codeが使われています。エンジニアの90%が利用し、日次利用は本格導入の開始から9倍に増えています。プロンプトキャッシュ効率は90%を超え、文脈が使い回されています(Prompt Cachingを理解するで仕組みを解説しています)。

社内では、コードの問題を拾い、下流のSQL依存を分析し、クエリ最適化を指摘してインパクトの要約を作るPRレビューシステムも作られました。数四半期かかる規模の作業が数週間で済んだといいます。テスト対象を差分だけに絞る「Smarter Testing」を使う顧客では、テスト実行時間が平均75%、最大97%縮みます。プロダクト向けのエージェントと、開発者自身の日常業務の効率化を同時に進めています。5社の事例ページのうち、社内利用まで載っているのはCircleCIだけです。

Semgrepは誤検知の削減にClaudeをどう使っているか

セキュリティスキャンツールのSemgrepは、Amazon Bedrock経由でClaudeを呼び出し(BedrockのClaude料金で直接APIとの違いを整理しています)、セキュリティアラートのノイズ削減に取り組んでいます。Staff EngineerのBence Nagy氏は「セキュリティツールは大量のアラートを生成することで知られている。これは業界全体の問題」と課題を説明しています。

最初の手応えは、password=REPLACE_PASSWORD_HERE のような無害なプレースホルダーと、本当に漏えいしたパスワードをAIが見分けられるかという試験でした。従来のツールは両方を脆弱性として報告します。見分けられると分かったことで、同社はAIをプラットフォーム全体に広げる方向を探り始めました。

Claudeの用途は誤検知の判定だけではありません。事例ページには、Claudeを含む複数のモデルで動かす次の6機能が挙がっています。

数値面では、検出結果の20%を「無視して安全」と自信を持ってラベル付けし、ユーザーの同意率は92%、セキュリティ研究者の同意率は96%です。誤検知の識別精度は、GPT-4oを使っていた前のバージョンより16%高く、コンポーネントのタグ付けは17%上回りました。

見逃せないのは評価の方法です。同社は事前に分類済みの検出結果を数千件集めた評価セットで、モデルごとの精度を測っています。Claudeは、タスク別の評価すべてで上位3位に入った点が特徴だったそうです。Nagy氏はClaude 3.7 Sonnetについて、自動生成されたファイルの脆弱性に気づき、出力ファイルを直接直さず生成元を直すよう勧めた点を挙げました。

評価では、モデルの設定に関する意外な発見もありました。「考えるためのトークン」を増やしたところ、Claudeが慎重になりすぎて、セキュリティ上の判断が保守的に傾いたといいます。この知見を受けて、セキュリティ用途ではClaudeのパラメーターを調整しています。

同社はさらに、AIコーディングアシスタントが生成したコードをその場で脆弱性スキャンできるオープンソースのMCPサーバーを公開しています。Semgrepの解析エンジンは高速で、結果の根拠が追え、ソースコードを直接見る方式です。そのためLLMがツールとして呼び出しやすいと説明しています。

5社の実装方式を並べると何が分かれるか

実装方式の選択は、どこまで自前でインフラを持つかで分かれます。GitLabとSourcegraphはClaude Platformを直接呼び出し、SemgrepはAmazon Bedrock経由で呼び出します。いずれも機能ごとのモデル選びと評価を自社の仕事として持っています。Sentryはエージェント実行基盤の構築を避けるためにManaged Agentsを選びました。CircleCIは、Agent SDKで自社の検証パイプラインにつなぐ独自のエージェントを組み立てています。

出力の検証をどこに置いているか

実装方式とは別に、Claudeの出力が正しいかを確かめる場所も、5社で違います。

まとめ

検証の置き場所は4種類

• 評価チームがモデル側を見る(GitLab)

  主体は専任の評価チーム、タイミングは新しいベンダーやモデルのバージョンが出た時点、対象はユースケースごとのモデルの適性です。

• 評価セットで精度を測る(Semgrep)

  主体は評価セットとユーザー・セキュリティ研究者、タイミングはモデルを選ぶ段階、対象は検出結果の分類やタグ付けの精度です。

• CIが修正を検証する(CircleCI)

  主体は顧客のCIパイプライン、タイミングはPRを返す前、対象はテスト・リンター・静的解析の基準を満たすかどうかです。

• 人がレビューする(Sentry)

  主体は開発者、タイミングはエージェントがPRを作ったあと、対象は修正の中身です。

Sourcegraphは、検証を使う側に開いた形です。Opus・Sonnet・Haikuを全プランで選べるようにし、ユーザーが既定モデルを変えた割合(Proの約55%)を公開し、提案をコードに挿入した割合の増加をコード品質向上の指標としています。

自社の状況に近いのはどの事例か

エージェント基盤をどこまで自前で持つかを考えるときは、SDKの基礎から見ると判断しやすくなります。Claude Agent SDK入門にPython・TypeScriptでの最小構成があります。

まとめ

実装方式を選ぶときは、出力を検証する仕組みが自社にすでにあるか(CIのパイプライン、評価データ、レビューの体制)を先に見ると、近い事例を絞り込めます。検証の仕組みが薄いなら、GitLabやSemgrepのように評価の体制から作る道もあります。