Claude Code × 受託開発・SIer｜マルチプロジェクトCLAUDE.md管理と品質標準化の実践

受託開発・SIerの開発現場には、自社プロダクト開発とは構造的に異なる難しさがあります。案件Aは React + TypeScript、案件Bは Java + Spring Boot、案件Cは PHP + Laravel——技術スタックが案件ごとに異なり、エンジニアは週の半分で案件Aを進め、残りの半分で案件Bに切り替える。この環境でClaude Codeを導入すると、案件間のコンテキストが混在して品質が不安定になるリスクがあります。

本記事では、受託開発・SIerがClaude Codeを複数案件で安全かつ効果的に運用するための実践手法を解説します。マルチプロジェクトCLAUDE.md管理のアーキテクチャ、NDA準拠のセキュリティ設計、テンプレート自動生成による立ち上げ加速、そして案件横断での品質標準化の仕組みまで踏み込みます。

受託開発の構造的課題 — 「文脈の切り替え」がすべてを遅くする

受託開発の最大の非効率は、コードを書く時間ではなく「文脈を切り替える時間」にある。

自社プロダクト開発であれば、技術スタック、コーディング規約、ドメイン知識はすべて1つです。しかし受託開発では、案件ごとに以下がすべて異なります。

要素	案件A	案件B	案件C
フレームワーク	Next.js	Spring Boot	Laravel
言語	TypeScript	Java	PHP
DB	PostgreSQL	Oracle	MySQL
コーディング規約	ESLint + Prettier	Checkstyle	PHP-CS-Fixer
テストFW	Vitest	JUnit 5	PHPUnit
デプロイ先	Vercel	AWS ECS	さくらVPS

エンジニアが案件Aから案件Bに切り替えるとき、頭の中のコンテキストを入れ替えるのに30分〜1時間かかります。1日に2回切り替えると、1〜2時間が「何も生産しない切り替え時間」に消えます。

品質のばらつき

同じSIer内でも、案件の品質はアサインされたエンジニアのスキルに大きく依存します。シニアエンジニアがリードする案件と、ジュニアエンジニア中心の案件では、コード品質に2倍以上の差が出ることも珍しくありません。

ナレッジの蒸発

案件が終了すると、そのプロジェクトの知見はチームから失われます。半年後に類似案件が来ても、前回の知見を活かせない。「前にも同じことやったのに、また一から調べている」という状況が繰り返されます。

顧客ごとの情報隔離

NDA（秘密保持契約）により、案件Aの情報を案件Bの作業中に参照してはならないケースがあります。Claude Codeに複数案件のコードを混在させることは、NDA違反のリスクを生みます。

マルチプロジェクトCLAUDE.md管理アーキテクチャ

受託開発でClaude Codeを効果的に運用するための鍵は、CLAUDE.mdを「ベースレイヤー」と「案件レイヤー」の2層構造で管理することです。

ベースレイヤー: 全案件共通のCLAUDE.md

社内の開発標準をベースレイヤーのCLAUDE.mdとして定義し、全プロジェクトのテンプレートに含めます。

# CLAUDE.md（ベースレイヤー — 全案件共通）

## セキュリティ基準（全案件必須）
- APIキー・DB接続情報をコード内にハードコードしない
- .envファイルは.gitignoreに含める
- SQLインジェクション対策としてプリペアドステートメントを使用する
- XSS対策として出力時のエスケープを徹底する

## コミットルール（全案件共通）
- Conventional Commits 形式: feat: / fix: / refactor: / test: / chore:
- コミットメッセージは日本語で記述する
- 1コミット1機能の原則

## ドキュメント基準（全案件共通）
- 関数・クラスにはJSDoc/Javadoc/PHPDocを付与する
- README.mdに環境構築手順を記載する
- API仕様書はOpenAPI形式で管理する

## 禁止事項（全案件共通）
- console.log / System.out.println を本番コードに残さない
- TODO/FIXMEコメントを放置したままPRを出さない

案件レイヤー: 案件固有のCLAUDE.md

各案件のリポジトリに配置するCLAUDE.mdには、案件固有の技術スタック・顧客要件・禁止事項を記載します。

# CLAUDE.md（案件レイヤー — 案件A固有）

## 顧客要件
- IE11対応不要（Chrome最新版のみ対応）
- アクセシビリティ: WCAG 2.1 AA準拠
- 使用禁止ライブラリ: moment.js（dayjsを使用すること）

## 技術スタック
- Next.js 15 App Router + TypeScript 5.x
- Prisma + PostgreSQL 16
- Tailwind CSS v4 + shadcn/ui
- Vitest + Testing Library + Playwright（E2E）

## ディレクトリ構成
- src/app/ — ルーティング
- src/features/ — 機能モジュール
- src/shared/ — 共有コンポーネント

## 案件固有の命名規則
- コンポーネント: PascalCase（例: UserProfileCard）
- API ルート: kebab-case（例: /api/user-profiles）
- DB テーブル: snake_case（例: user_profiles）

この2層構造により、新しいエンジニアが案件にアサインされたとき、ベースレイヤーで社内標準を、案件レイヤーで案件固有のルールを同時に把握できます。

NDA準拠のセキュリティ設計 — 案件間のデータ隔離

受託開発でClaude Codeを導入する際の最大のセキュリティリスクは、案件間のデータ混在です。

顧客Aのソースコードがコンテキストに残った状態で、顧客Bの案件作業を行えば、意図せず情報が混在するリスクがあります。以下の対策を講じてください。

対策1: 顧客への開示と書面承認

Claude Codeの利用について、以下の情報を顧客に書面で開示し、承認を得ます。

開示項目	内容
送信データの範囲	ソースコード、設定ファイル、コメント
送信先	Anthropic API または AWS Bedrock
データ保持	Anthropic: 利用規約に基づく / Bedrock: トレーニング不使用
トレーニング利用	APIプラン: オプトアウト可 / Bedrock: 不使用

対策2: Bedrock経由の構成（セキュリティ要件が厳しい案件）

NDA要件が特に厳しい案件（金融、医療、官公庁等）では、AWS Bedrock経由の構成を採用します。VPCエンドポイント経由でアクセスすることで、データ経路を制御できます。

# 案件ごとのAWS Profile設定例
# ~/.aws/config

[profile client-a-dev]
region = ap-northeast-1
role_arn = arn:aws:iam::123456789012:role/bedrock-dev

[profile client-b-dev]
region = ap-northeast-1
role_arn = arn:aws:iam::987654321098:role/bedrock-dev

対策3: 案件ディレクトリの物理的分離

開発マシン上で案件ごとにディレクトリを分離し、direnvで環境変数を自動切り替えます。

# ~/projects/client-a/.envrc
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_PROFILE=client-a-dev
export CLAUDE_PROJECT=client-a

# ~/projects/client-b/.envrc
export CLAUDE_CODE_USE_BEDROCK=1
export AWS_PROFILE=client-b-dev
export CLAUDE_PROJECT=client-b

案件ディレクトリにcdした瞬間に環境変数が切り替わるため、エンジニアが接続先を意識せずに案件ごとの環境分離を実現できます。

対策4: 承認取得テンプレートの整備

顧客への説明・承認取得のプロセスを標準化するため、社内テンプレートを整備します。

# AI開発支援ツール利用に関するご説明（テンプレート）

## 利用ツール
- Claude Code（Anthropic社提供の開発支援CLI）

## 利用目的
- コードの品質チェック、テスト自動生成、ドキュメント整備

## データの取扱い
- 送信されるデータ: [具体的な範囲を記載]
- 送信先: [Anthropic API / AWS Bedrock]
- トレーニング利用: [オプトアウト済み / Bedrock利用のため不使用]

## 安全管理措置
- [具体的な対策を記載]

## ご確認事項
上記内容について、ご承認いただける場合は下記にご署名をお願いいたします。

テンプレート自動生成 — 案件立ち上げを半日に短縮する

新規案件のキックオフから実装開始まで1〜2日かかっていたセットアップ作業を、Claude Codeで半日に短縮する。

Before: 従来の案件立ち上げ

1. プロジェクト構成をゼロから作成（半日）
2. CI/CD設定ファイルの作成（2〜3時間）
3. 共通コンポーネント（認証、エラーハンドリング、ロギング）の配置（半日）
4. 開発環境のドキュメント作成（2〜3時間）
5. CLAUDE.md作成（1時間）

合計: 約1.5〜2営業日

After: Claude Codeによる案件立ち上げ

1. ベースレイヤーCLAUDE.md + 案件固有CLAUDE.mdを作成（30分）
2. Claude Codeに「この案件のプロジェクト構成を生成して」と指示（1時間）
3. 生成された構成をレビュー・調整（1時間）
4. 開発環境ドキュメントの自動生成（30分）

合計: 約3時間（半日）

社内テンプレートの蓄積

案件ごとに生成したプロジェクト構成を、社内のテンプレートリポジトリにフィードバックします。

templates/
├── nextjs-typescript/
│   ├── CLAUDE.md.template    # 案件レイヤーの穴埋めテンプレート
│   ├── project-scaffold/     # ディレクトリ構成のひな型
│   └── ci-cd/                # CI/CD設定のひな型
├── spring-boot-java/
│   ├── CLAUDE.md.template
│   ├── project-scaffold/
│   └── ci-cd/
└── laravel-php/
    ├── CLAUDE.md.template
    ├── project-scaffold/
    └── ci-cd/

テンプレートの蓄積は、組織としてのClaude Code活用の成熟度を示す指標です。案件を重ねるごとにテンプレートが洗練され、立ち上げがさらに短縮されます。

納品ドキュメントの品質標準化

受託案件の納品品質は、コードだけでなくドキュメントに大きく依存する。Claude Codeで「ドキュメントをコードと同時に更新する」運用を実現します。

自動生成できるドキュメント

ドキュメント	生成方法	精度
API仕様書（OpenAPI）	コードのルーティング定義から生成	高（構造は正確、説明文は要レビュー）
テスト仕様書	テストコードからテスト項目・期待結果を出力	高
DB定義書	マイグレーションファイルから生成	高
画面遷移一覧	ルーティング定義から生成	中（動的遷移は手動補完が必要）
運用手順書	CI/CD設定から手動手順を逆生成	中（環境固有の設定は手動追記）
設計書	コードから逆引き	低（たたき台として利用）

CLAUDE.mdへのドキュメント生成指示

# CLAUDE.md（ドキュメント生成ルール）

## 納品ドキュメント
- API仕様書はOpenAPI 3.1形式で docs/api/ に出力する
- テスト仕様書は docs/test/ にMarkdown形式で出力する
- DB定義書は docs/database/ にテーブル定義をMarkdownテーブル形式で出力する
- 各ドキュメントの最終更新日をフッターに含める

## ドキュメント更新タイミング
- APIエンドポイントの追加・変更時にAPI仕様書を更新する
- テストの追加・変更時にテスト仕様書を更新する
- マイグレーション実行時にDB定義書を更新する

ドキュメントの更新タイミングをCLAUDE.mdで定義しておけば、Claude Codeが実装と同時にドキュメントを更新する習慣が定着します。

案件横断の品質標準化 — エンジニアのスキル差を吸収する

CLAUDE.mdのベースレイヤーが整備されていれば、ジュニアエンジニアの出力品質がシニアエンジニアの基準に近づきます。

品質の底上げメカニズム

1. コーディング規約の自動適用: CLAUDE.mdに定義された規約に沿ったコードが生成されるため、規約を知らないエンジニアでも準拠コードが書ける
2. テストの自動生成: テストを書く習慣がないエンジニアでも、Claude Codeが自動生成したテストをレビューすることでテスト文化が根付く
3. ドキュメントの自動生成: ドキュメントを書かないエンジニアでも、Claude Codeが自動生成したドキュメントを微修正するだけで済む

シニアエンジニアの役割変化

Claude Codeの導入により、シニアエンジニアの役割は「コードを書く」から「CLAUDE.mdを設計し、レビューの質を高める」にシフトします。

• Before: シニアエンジニアが実装とレビューの両方を担当（ボトルネック）
• After: シニアエンジニアはCLAUDE.md設計 + アーキテクチャ判断 + レビューに集中。実装はジュニア + Claude Code

この構造は、「シニアの生産性を10倍にする」のではなく、「チーム全体の品質の底を引き上げる」効果があります。

社内展開のロードマップ

フェーズ1（1か月）: パイロット案件で検証

社内プロジェクトまたはセキュリティ要件が緩い案件で試行。ベースレイヤーCLAUDE.mdの初期版を作成し、テンプレートの原型を構築します。

フェーズ2（2〜3か月）: 顧客承認プロセスの確立

顧客への説明資料テンプレートの整備、承認取得フローの標準化、セキュリティ部門との合意形成を進めます。

フェーズ3（4〜6か月）: 新規案件への展開

新規案件からClaude Codeを標準ツールとして導入。既存案件への適用はリニューアルや大規模改修のタイミングに合わせます。

フェーズ4（7か月目以降）: テンプレートの成熟と横展開

テンプレートリポジトリの充実、ベースレイヤーCLAUDE.mdの改善、社内勉強会での知見共有を継続します。

まとめ — CLAUDE.mdの2層管理が受託開発の生産性を構造的に変える

受託開発・SIerにおけるClaude Code活用の本質は、案件ごとのコンテキストをCLAUDE.mdで明文化し、エンジニアのスキル差や案件の切り替えコストを構造的に吸収することにあります。ベースレイヤーで社内標準を、案件レイヤーで顧客固有のルールを管理する2層構造が、複数案件を並行する開発体制でのClaude Code活用の鍵です。

最初のステップは、社内で最も標準化されたプロジェクトのCLAUDE.mdを1つ作成し、それをベースレイヤーの原型にすることです。

Claude Codeの全体像は Claude Code完全ガイド を、CLAUDE.mdの書き方は CLAUDE.md作成ガイド を参照してください。