「Claude Code を全社で買ったが、使う人と使わない人で生産性に 5 倍の差が出ている」——CTO・VPoE クラスのリーダーから、ここ数ヶ月でこの相談が頻繁に上がっています。背景には、Spotify が Claude Code をベースに社内開発エージェント基盤を構築し、エンジニアリング工数を 90% 削減、月 650 件以上の AI 生成コード変更をデプロイしている事例があります。
汎用ツールをそのまま渡すだけでは、組織のスキル差・運用文化差をそのまま増幅してしまいます。Spotify のようにエンジニアリング全体の生産性を底上げするには、自社の文脈に合わせた「開発エージェント基盤」を内製化する必要があります。本記事では、その構築ステップを 4 段階に整理し、受託で支援するときの提案フレームを共有します。
なぜ「Claude Code を配るだけ」では足りないか
汎用 AI コーディングツールを社内に配布したときに、必ず起きる 3 つの問題があります。
- コーディング規約が反映されない：プロジェクトごとの命名規則・テスト方針・PR テンプレートを毎回プロンプトに書く手間が発生
- コード資産を活用できない：社内のライブラリ・テンプレート・過去 PR の知見を AI が知らない
- 品質ゲートが脆い：AI 生成コードがレビューを素通りし、技術的負債を量産する
私たちが Claude Code 運用コスト最適化ガイド で書いたように、「ツール導入」と「成果が出る運用」の間には大きな谷があります。Spotify はこの谷を、自社基盤を内製することで埋めました。
4 レイヤーで設計する社内開発エージェント基盤
レイヤー 1: コンテキスト供給層
開発エージェントが「自社のコード資産」を理解できるようにする層です。
- モノレポ / 主要リポジトリの埋め込みインデックス（pgvector / Vespa など）
- CLAUDE.md の集中管理（プロジェクトテンプレート + リポジトリ別オーバーライド）
- 過去 PR・設計ドキュメントの取り込み（Notion / Confluence / GitHub Wiki）
ここで重要なのは、「全部入れる」のではなく「品質の高いものだけ入れる」ことです。古い設計書や非推奨のコードまで埋め込むと、AI が古い解を引いてくる原因になります。
レイヤー 2: ツール / MCP 層
エージェントが叩ける社内ツールを MCP サーバーとして整備します。
- CI / デプロイ：GitHub Actions / CircleCI の状態取得・再実行
- チケット管理：Jira / Linear / Backlog のチケット読み書き
- モニタリング：Datadog / Sentry のクエリ実行
- データベース：開発 DB への読み取り専用クエリ実行
私たちが 自社 MCP サーバー群の構築実務ガイド で書いた手順と地続きです。重要なのは、エンジニア個人ではなくチームでツールセットを共有することです。
レイヤー 3: 品質ゲート層
AI 生成コードが本番に到達するまでの関門を設計します。Spotify の事例では、自動 PR 生成 → 人間レビュー → CI → デプロイの各段階で、AI 生成コードを識別して扱いを変えています。
| ゲート | チェック内容 | 対応 |
|---|---|---|
| Pre-commit | 命名・整形・型 | 自動修正 |
| CI（lint / test） | 既存テストパス | 失敗時は AI に再生成依頼 |
| 人間レビュー | 設計妥当性 | 必須レビュアー 1 名以上 |
| デプロイ | カナリア + 監視 | 異常検知で自動ロールバック |
「AI が書いたから品質が高い」ではなく、「AI が書いたからこそ、人間が書いたとき以上に厳しくチェックする」が現代の標準です。
レイヤー 4: 観測 / 学習層
エージェントの利用状況・成功率・コストを観測し、基盤改善にフィードバックする層です。
- 利用ログ（誰が・どのプロジェクトで・どのタスクを・どれくらい）
- 成功率（提案コードが PR にマージされた割合）
- コスト（プロジェクト別・チーム別・タスク種別）
Langfuse を使った AI 開発の観測ガイド で書いたパターンを、社内開発エージェントにも適用できます。観測がないと、3 か月後に「結局何が良くなったか分からない」状態に陥ります。
構築ステップ（受託で支援する標準プロセス）
弊社が CTO/VPoE 向けに提案している標準ステップは次の 4 段階です。
ステップ 1: ベースラインアセスメント（2〜3 週間）
- 現状の AI 利用状況をヒアリング・ログから測定
- ボトルネック工程の特定（コードレビュー / テスト / デプロイ）
- 改善余地の定量化（時間削減・品質向上の見込み）
ここでデータを取らないと、後で「効果あった？」が答えられません。
ステップ 2: パイロット基盤構築（6〜10 週間）
- 1〜2 チームを対象に、レイヤー 1〜2 の最小実装
- 既存リポジトリ 2〜3 本にコンテキスト供給を適用
- 主要 MCP サーバーを 3〜5 本セットアップ
ステップ 3: 品質ゲート + 観測（4〜6 週間）
- レイヤー 3〜4 を追加
- AI 生成コードの識別・追跡基盤
- 週次レビュー会の運用設計
ステップ 4: 横展開と内製化（継続）
- 全エンジニアリングチームへの展開
- 社内オーナーへのナレッジ移管
- 半年ごとのプラットフォーム更新
受託案件としての規模感
| 案件の型 | 期間 | 単価帯 |
|---|---|---|
| アセスメント + 提案書 | 3〜4 週間 | 100〜200 万円 |
| パイロット基盤構築 | 8〜12 週間 | 800〜1,500 万円 |
| 全社展開支援（半年） | 6 ヶ月 | 1,800〜3,500 万円 |
| 運用伴走（月額） | 月額 | 80〜200 万円 |
「全社展開支援 + 月額運用伴走」のセットが、いま最も成立しやすい構成です。
まとめ — 開発エージェント基盤は「組織能力」になる
Spotify の 90% 削減は、Claude Code を買ったからではなく、自社文脈に合わせて基盤化したから実現しました。同じことを国内の中堅以上のエンジニアリング組織でやろうとすると、コア人材の時間を半年以上拘束する必要があります。
弊社では、社内開発エージェント基盤のアセスメント・パイロット構築・全社展開支援を提供しています。「Claude Code を配ったが効果が出ない」「自社用の AI 開発基盤を作りたい」という相談は、お問い合わせフォーム からお気軽にどうぞ。
