AI駆動時代のソフトウェアエンジニアリング【第3回】明日から使える——CLAUDE.mdとAI分析プロンプトの実装

全3回シリーズ｜読了目安：12分

第1回でフレームワークの骨格を、第2回でWorking Backwardsと探索の余白を解説した。第3回では、このフレームワークを実際に動くファイルとプロンプトに落とし込む。そして最後に、この記事シリーズ自体が何であったかを振り返る。

Claude CodeのCLAUDE.mdで実装する

Claude Codeには CLAUDE.md というファイルがある。セッション開始時に自動的に読み込まれ、プロジェクトのルール・慣習・アーキテクチャをAIに伝える仕組みだ。

このフレームワークは、CLAUDE.mdとして以下の構造で実装する。

/
├── CLAUDE.md                        # 共通基盤（全プロファイル共通）
├── .claude/profiles/
│   ├── PROFILE_A.md                 # 小規模・高速型
│   ├── PROFILE_B.md                 # 大規模システム型
│   ├── PROFILE_C.md                 # セキュリティ厳格型
│   └── PROFILE_D.md                 # ミッションクリティカル型
└── apps/<app-name>/CLAUDE.md        # 各アプリがプロファイルを指定

ルートCLAUDE.md：共通基盤

ルートのCLAUDE.mdには、プロファイルを問わず全てに適用するルールだけを置く。ポイントは短く保つこと。Claude Codeのコンテキストウィンドウは有限だ。

含めるもの：プロジェクト構造の説明、コマンド一覧、コミットメッセージ規約、非交渉のルール（Beyoncéルール、テストピラミッド、「左への移動」）、設計判断ワークフロー、Working Backwardsの原則、探索の余白の推奨。

含めないもの：リンター・フォーマッターのルール（CI側で強制する）、プロファイル固有のルール（各プロファイルファイルに委譲）、長い説明文。

プロファイルA：速度が正義

プロファイルAの核心は「速度 > 完璧さ」。

# プロファイルA：小規模・高速型

## 最優先事項: 速度
- コードレビュー: AI一次のみ。人間はアーキテクチャ変更時のみ
- テストカバレッジ: 60%（低め許容）
- YAGNI原則を厳守。今必要ないものは作らない

特に重要なのは昇格基準をあらかじめ明記しておくこと。プロファイルAで始めたシステムが成長した時に「いつプロファイルBに上げるか」を判断できなければ、いつまでも低いテストカバレッジで大きなシステムを運用することになる。

プロファイルC：安全性が全てに優先する

プロファイルCの設計思想は多層防御。AIは防御の一層であり、最終層ではない。

# プロファイルC：セキュリティ厳格型

## AIの役割（意図的に制限）

### AIに任せること
- 既知の脆弱性パターン（OWASP Top 10等）の自動検出
- 依存ライブラリのCVE監視

### AIに任せないこと
- 新種の攻撃ベクトルの発見 → 人間が壁打ちで拡張
- 認証・暗号化の設計判断 → 人間が設計、AIはレビュー補助のみ

プロファイルCで特に際立つのは脅威モデリングのワークフローだ。STRIDE分析で脅威を列挙した後に、AIとの壁打ちで「この設計の攻撃経路で見落としているものを5つ挙げて」と拡張する。人間の分析力とAIの網羅性を組み合わせる好例だ。

プロファイルD：変更しないことが正しい判断であり得る

プロファイルDは最も保守的であり、最も独特だ。

# プロファイルD：ミッションクリティカル型

## このプロファイルの特殊性
- 変更の正当性の立証責任は変更者側にある
- 「動いているものを触るな」は正当な判断であり得る
- PRは200行以下を強く推奨
- 金曜午後〜月曜午前はデプロイ禁止

他のプロファイルが「良いコードを素早く書く」ことを支援するのに対し、プロファイルDは「変更しない勇気」を制度化する。インフラやデータベースのように、壊れたら全てが止まるシステムでは、「何もしない」が最善の判断である場面が実際にある。

カナリアリリースも1%刻みから始め、各段階で最低1時間のモニタリングを挟む。ステージングで24時間の安定稼働を確認してから本番に進む。慎重さが速度に勝る世界だ。

AI分析レポート生成プロンプトの設計

フレームワークの第3層（人材育成環境）を動かすには、壁打ちログを分析するプロンプトが必要だ。4段階で設計した。

プロンプト1：単回分析（即時フィードバック）

壁打ち1セッション分のログを入力すると、5次元のスコア（1〜5）、改善提案（最大3つ）、強み（最大2つ）をJSON形式で返す。

ここで最も重要なのはプライバシーの指示だ。

【絶対遵守】
出力に以下を含めてはならない:
- 壁打ちで使われた具体的な質問文
- プロジェクト名、技術名、チーム名、個人名
- 特定のコード片やエラーメッセージ

所見は抽象化して記述する。
  ×「Reactのstate管理について構造的な問いを立てた」
  ○「フレームワークの状態管理について層別分解した問いを立てた」

この指示により、AI分析レポートから生ログの具体的な内容を復元することが不可能になる。

プロンプト2：四半期分析（パターン認識）

複数セッションのスコア時系列を入力し、成長の軌跡とパターンを可視化する。v2ではここに目標との整合性チェックを追加した。

「推奨アクション」の生成時に、単にスコアの弱点を埋めるのではなく、個人が申告したキャリア目標と対照して、目標達成に最も貢献する次元の強化を優先する。

プロンプト3：チーム集計（マネージャー向け）

匿名化された四半期レポートを集計し、チーム全体の5次元プロフィール、思考スタイルの多様性、プロファイルギャップを分析する。個人の特定は不可能な形で出力される。

プロンプト4：バイアス監査（四半期実施）

AI分析モデル自体の公平性を検証する。全メンバーのスコアを性別・国籍・年齢・入社年数で分割し、統計的に有意な差がないかを確認する。

重要なのは「差がある」=「問題がある」ではないこと。入社年数とスコアの相関は合理的だ。しかし性別とスコアの相関があれば、それはモデルのバイアスを疑うべき警告サインだ。

データフロー全体像

壁打ちの生ログ（本人 + AIのみ）
  ↓ プロンプト1
単回分析スコア（本人のみ）
  ↓ 四半期蓄積
  ↓ プロンプト2
四半期レポート（本人 → メンター → マネージャー）
  ↓ 匿名化
  ↓ プロンプト3
チーム傾向（マネージャー）
  ↓ 属性タグ付け
  ↓ プロンプト4
バイアス監査（監査担当者）

各段階で抽象度が上がり、生ログの内容は決して上位層に漏れない。 これがプライバシーアーキテクチャの技術的な実装だ。

導入ロードマップ：やりすぎないことが最重要

ここまで読んで「これ全部を一度にやるのは無理だ」と感じたとしたら、正しい反応だ。本フレームワーク自身が過剰な先行投資を戒めている。

フェーズ	期間	やること	やらないこと
Phase 1	1〜2週間	モノリポ+トランクベース+AI一次レビュー。プロファイルAで運用開始	プロファイルB/C/Dの導入、評価制度の変更
Phase 2	2〜4週間	テスト自動化、プロファイルB/C/D段階導入	壁打ちログ分析の仕組みづくり
Phase 3	継続的	壁打ちログ基盤+6次元評価+プライバシーアーキテクチャ	全てを一度に完成させようとすること
Phase 4	継続的	ハッカソン壁打ちデー、クロスプロファイルペア壁打ち	探索の「義務化」

PMF前なら、Phase 1だけで十分だ。 モノリポとトランクベース開発を入れ、AI一次レビューを回す。それだけで開発の基盤は劇的に改善する。

Phase 4の「探索文化の醸成」は最後に来るが、Phase 1の時点から「探索を歓迎する」というメッセージは発信し始める。制度は後から作ればいい。空気は最初から作る。

この記事自体が壁打ちの実例である

ここまで3回にわたって、AIとの壁打ちからフレームワークが生まれた過程を追ってきた。最後に、このプロセス自体を振り返りたい。

問いの連鎖が生んだもの

最初の問いは「AI駆動開発で本書の3部4部は変わるのでは？」という素朴なものだった。そこから7回の問いの連鎖を経て、3層＋2軸の包括的フレームワークが完成した。

重要なのは、AIが全てを設計したわけではないということだ。

AIは毎回、論理的で整合性のある回答を返してきた。しかし、その回答の中に埋め込まれた暗黙の前提を発見し、より優れた構造に導いたのは、問いを投げる側の人間だった。

AIが「人間が単独で担う」と言った時に「壁打ちで拡張できる」と修正した
AIが「評価に使わない」と安全策を取った時に「最重要評価項目にすべき」と覆した
AIが「意志で倫理を守る」と言った時に「構造で破れなくする」と再設計させた

問いの質が、回答の質を決める。 まさにこのフレームワーク自身が説く原理だ。

壁打ちの3つのパターン

このセッションから抽出された壁打ちパターンは、フレームワークの「壁打ちパターン集」としてガイドライン化した。

論理的階段パターン。 AI回答の結論を受け取った後、「この結論を前提として、さらに深い問いは何か」と自問する。前回の到達点が次の出発点になり、問いが一本の階段を形成する。

前提の顕在化パターン。 「この回答が暗黙に前提としていることは何か」「その前提を外したらどうなるか」と問う。AIは自分の回答の前提を自覚しにくい。それを顕在化させるのは問い手の仕事だ。

悪魔の代弁者パターン。 「この案を選ぶべきでない最も強力な反論を3つ構築して」とAIに求める。自分の選択に対する最高の反論者としてAIを使う。

壁打ちで生まれないもの

しかし同時に、壁打ちでは生まれなかったものもある。

Working Backwardsの視点は、壁打ちの中からではなく、フレームワークの設計結果に対する自己批判から生まれた。探索の余白という発想は、合理的なフレームワーク全体を俯瞰して「何が足りないか」を問うことから生まれた。

壁打ちは思考を拡張するが、思考のフレーム自体を問い直す力は、壁打ちの外側にある。 フレームワーク自身が「本フレームワーク自体も壁打ちの対象である」と結論に書いているのは、この認識があるからだ。

結び：問い続けること

「ソフトウェアエンジニアリングとは時間で積分したプログラミングである」
  — Titus Winters, Google

AI時代のソフトウェアエンジニアリングとは、
「人間とAIが協働して問いの質を磨き続ける営み」であり、
同時に「問いの質では測れないものを、問いの外側で育む営み」である。

685ページの名著は、AIとの壁打ちを通じて、実行可能なフレームワークに変わった。そのフレームワーク自身が「四半期ごとに自身をAIと壁打ちせよ」と言っている。

つまり、このフレームワークに「完成」はない。問い続ける限り、進化し続ける。

それこそが、AI駆動時代のソフトウェアエンジニアリングの本質だと思う。

このシリーズの内容自体が、「AIとの壁打ちでフレームワークを作り上げた実例」です。あなたのプロジェクトでも、まずは1つ問いを投げてみてください。「この設計の最大の弱点は何か？」——そこから全てが始まります。