生成AI研修
Part 6: AI × 開発 応用

Chapter 36: チーム開発での AI 運用

ガイドライン策定・ナレッジ共有・組織展開

36.1 AI 活用ガイドラインの策定

AI ツールをチームに導入する際、ガイドラインがないと使い方にバラつきが生まれ、品質が不均一になるリスクがあります。ガイドラインは禁止事項の羅列ではなく、「AI を正しく使うための指針」として位置づけます。

ガイドラインの構成要素

# AI 活用ガイドライン v1.0

## 推奨する使い方
- ボイラープレートコードの生成
- テストケースの網羅的な生成
- コードレビューの補助(AI レビュー後に人間がダブルチェック)
- ドキュメントの初稿作成
- バグ原因の調査補助

## 注意が必要な使い方
- 複雑なビジネスロジック: AI の出力を必ず人間が検証する
- セキュリティ関連コード: セキュリティ専門家が最終確認する
- 外部 API の呼び出し: 料金・レート制限を確認してから使う

## 禁止事項
- 機密情報(APIキー・個人情報・未公開製品情報)を AI に入力しない
- AI が生成したコードを理解せずにコミットしない
- 本番 DB への直接操作を AI に委ねない

## AI 生成コードのコミットルール
- コメントに `# AI-assisted` を付けることは不要(品質が保たれていれば起源は問わない)
- AI が生成した危険なコードをそのまま使った場合は作成者の責任

ガイドラインの更新プロセス

ガイドラインは生きたドキュメントです。月1回のレトロスペクティブで以下を確認します:

  1. ガイドラインを守れなかったケースはあったか
  2. 新しい AI ツール・機能によって更新が必要な箇所はないか
  3. チームからの改善提案はあるか

36.2 ナレッジ共有の仕組み

チームで AI を使うと、メンバーそれぞれが「うまくいったプロンプト」「ハマりポイント」を発見します。これを組織の資産として蓄積する仕組みが必要です。

プロジェクト CLAUDE.md の共有

プロジェクトルートの CLAUDE.md は git で管理し、チーム全員が恩恵を受けます:

project/
├── CLAUDE.md          # チーム共有の AI コンテキスト(git 管理)
├── .claude/
│   ├── settings.json  # チーム共有設定(git 管理)
│   ├── settings.local.json  # 個人設定(.gitignore)
│   ├── agents/        # チーム共有エージェント定義
│   └── skills/        # チーム共有スキル定義
└── docs/
    └── knowledges/
        ├── architecture.md  # 設計意図・背景
        ├── gotchas.md       # ハマりポイント
        └── conventions.md   # プロジェクト規約

ナレッジ蓄積のワークフロー

効果的なナレッジの書き方

良いナレッジ記録の例:

## Prisma の `findMany` は N+1 問題を引き起こしやすい

**現象**: User 一覧を取得して各 User の Post を参照すると、
Post のクエリが User の数だけ発行される。

**原因**: Prisma はデフォルトで遅延ロードしない。
明示的に `include` しないと別クエリになる。

**解決策**:
```typescript
// ❌ 問題のある書き方
const users = await prisma.user.findMany();
for (const user of users) {
  const posts = await prisma.post.findMany({ where: { userId: user.id } });
}

// ✅ 正しい書き方
const users = await prisma.user.findMany({
  include: { posts: true }
});
```

**発見者**: @yamada | 2024-03-15

36.3 セキュリティポリシー

AI ツールの導入に伴うセキュリティリスクは事前に把握しておく必要があります。

リスクと対策

リスク具体例対策
機密情報の漏洩APIキーをプロンプトに貼る.env ファイルを .claudeignore に追加
AI 依存による脆弱性セキュリティコードを無検証で使用セキュリティ関連コードは必ずレビュー
プロンプトインジェクション外部入力をそのままプロンプトに渡す入力値のサニタイズを徹底
過剰な権限付与AI に本番 DB への write 権限を与える最小権限の原則を適用

.claudeignore の設定

# .claudeignore
.env
.env.*
*.pem
*.key
secrets/
credentials/
**/private/**

API キーの管理

# ❌ 危険: プロンプトに直接貼る
claude -p "AWS_SECRET_KEY=AKIAXXXX で S3 にアクセスして"

# ✅ 安全: 環境変数経由
export AWS_SECRET_KEY=$(aws configure get aws_secret_access_key)
claude -p "AWS_SECRET_KEY 環境変数を使って S3 にアクセスして"

36.4 コード品質の維持

AI を使うと生成速度が上がる分、品質管理の重要性が増します。コードが大量に生成される環境では、品質ゲートと人間レビューの組み合わせが不可欠です。

AI 生成コードのレビュー観点

AI が特に苦手とするポイントを重点的にチェックします:

観点AI の傾向レビューのポイント
エラーハンドリング楽観的な実装になりがちcatch の中身が空でないか
競合状態単一スレッドを前提にしがち並行アクセスの考慮があるか
エッジケースハッピーパスに偏りがちnull・空配列・境界値の処理
パフォーマンス動くが遅い実装N+1・不必要なループがないか
セキュリティ素朴な実装入力検証・エスケープ処理

PR レビューの役割分担


36.5 オンボーディングへの活用

新メンバーのオンボーディング期間を AI で短縮できます。従来1〜2週間かかっていたキャッチアップが、AI サポートにより3〜5日程度になるケースもあります。

オンボーディング支援の仕組み

コードベース探索のサポート:

新メンバーへの初日ガイド:

1. プロジェクトをクローンして Claude Code を起動
2. 「このプロジェクトの全体構成を説明して」と聞く
3. 「認証フローはどこに実装されている?」と聞く
4. 「このプロジェクトで気を付けるべきポイントは?」と聞く

オンボーディング用スキルの作成:

<!-- .claude/skills/onboarding.md -->
---
name: オンボーディングガイド
command: onboarding
description: 新メンバー向けプロジェクト案内
---

このプロジェクトに初めて参加したメンバーを案内してください。

1. プロジェクトの目的と主要機能を説明する
2. 主要なディレクトリ構成と各フォルダの役割を説明する
3. ローカル環境構築手順(CLAUDE.md または README を参照)
4. よくある質問と回答(docs/knowledges/gotchas.md から抜粋)
5. 最初に触るべきファイルと Issue を提案する

メンタリングとしての AI

新メンバーが書いたコードに AI がやさしくフィードバックする仕組み:

新メンバーへのメッセージ:

「コードを書いたら、まず Claude Code に
 『このコードを上級エンジニアの視点でレビューして、
   改善点を優しく教えて』と頼んでみてください。
 人間のレビュアーへの PR を出す前の自己チェックとして活用できます。」

36.6 組織への展開戦略

個人・チームでの成功を組織全体に拡大する際の戦略です。

展開のロードマップ

展開時の抵抗への対処

抵抗のタイプ背景対処法
「AI に仕事を奪われる」雇用への不安AI は補助ツール。創造的な仕事に集中できる
「AI のコードは信頼できない」品質への懸念品質ゲートと人間レビューの仕組みを見せる
「使い方が難しそう」スキル不足への不安ハンズオン研修とメンター制度を設ける
「セキュリティが心配」情報漏洩への懸念セキュリティポリシーと技術的対策を説明する

AI チャンピオン制度

各チームに「AI チャンピオン」を1名指名します。

AI チャンピオンの役割:

  • チーム内の AI 活用のベストプラクティスを収集・共有する
  • 月1回、他チームのチャンピオンと事例を共有するミーティングに参加する
  • 新しい AI ツール・機能をチームに紹介する
  • チームメンバーの困りごとをサポートする

TODO: あとで実際のスクリーンショットに置き換え - AI チャンピオン向けダッシュボード(チームの AI 利用状況・ROI を可視化)

KPI の設定例

KPI測定方法目標
AI ツール利用率週次アクティブユーザー数チームの 80% 以上
PR レビュー時間GitHub Analytics従来比 50% 削減
バグ混入率本番バグ件数 / リリース数従来比 30% 削減
オンボーディング期間初PR マージまでの日数従来比 40% 短縮
開発者満足度四半期アンケートNPS +20 以上

On this page