はじめに
AI駆動開発に関する記事は、もう出尽くした感があります。「仕様を書く」「AIに実装させる」「出力を人間がレビューする」「最終責任は人間が持つ」——どれも正しいですし、よくまとまった記事がいくつもあります。
なので、この記事ではその話はしません。
ここで書くのは、その一歩先の話です。個人がAIをうまく使えるようになった後、チームでそれを回そうとした瞬間に出てくる壁と、それをどう仕組みとして解決したかの記録です。
先に結論を言います。AIの使いこなしは、個人技のままだと組織で形骸化します。 ガードレールを個人のメモではなく「組織の制度」に昇華させないと、人数分のブレが積み上がるだけでした。
個人の CLAUDE.md は、3人目で破綻する
最初はうまくいっていました。
AIが同じミスをするたびに、学習内容をメモへ記録する。たとえば「try-except の中が print 一行で握り潰されていた」といった失敗を記録して、次から参照させる。よく知られたアプローチ（CLAUDE.md や lessons.md の運用）ですし、個人で回す分には完璧に機能していました。
問題が起きたのは、これをチームに展開したときです。
- Aさんのメモと、Bさんのメモの内容が食い違う
- 「うちのやり方」が人によって異なるため、AIの出力も人によってブレる
- レビューのたびに「それ、前にAさんと決めたルールと逆だよ」という空中戦が起きる
個人のメモは、書いた本人の「頭の中の文脈」とセットでしか機能しません。暗黙知のままAIに渡しているため、本人がいないと再現できないのです。こうした蓄積は個人の資産にはなっても、組織の資産にはなりませんでした。
ここで気づきました。やるべきは「メモを共有すること」ではありません。判断基準そのものを、誰が読んでも同じ解釈になる形に書き出すことでした。
失敗を、メモから「MUST NOT 表」へ
そこで、散文でメモを取るのをやめました。代わりに、判断を**表（マトリクス）**にしました。
| MUST NOT (やってはいけないこと) | Why (なぜか) |
|---|---|
| 確認なしに実装を始める | 計画を事前にレビューできないため |
| 例外を握り潰す | 障害が「なかったこと」になるため |
| 秘匿情報をログに出す | 情報漏洩に直結するため |
散文のメモと「表」の決定的な違いは、解釈の余地です。「エラーハンドリングは丁寧に」という指示は人によってブレますが、「例外を握り潰さない」なら誰が読んでも、AIに渡しても、同じ意味になります。
そして一番効果があったのが、禁止の理由（Why）を必ず1行添えることでした。理由が明記されていると、ルールは単なる「お説教」ではなく「過去の痛みの記録」になります。新メンバーもAIも「なぜ踏んではいけないか」の本質が分かるため、形骸化しません。
ルール群の冒頭には、絶対に譲らない「Non-Negotiables（絶対死守ルール）」を数個だけ置きました。ここを増やしすぎると誰も守らなくなります。譲れない線は、少ないからこそ機能します。
こうして、AIの失敗は個人のメモからチームの制度になりました。誰が依頼しても、AIは同じガードレールの中を走ってくれます。
「コードを読む力」を、属人化させない
AI駆動開発の鉄則に「すべてを鵜呑みに（全承認）するな、出力を読め」があります。これには完全に同意します。ですが、チームでこれを実践すると次の問題にぶつかります。
「コードを読める人（目利き）」が一人だと、その人がチームのボトルネックになるのです。
レビューの目利きが属人化すると、結局はシニアエンジニアがすべてのプルリクエスト（PR）を精査することになり、AIで開発を高速化した意味が相殺されます。「読む力」を個人スキルのままにしておくと、組織のスケールスピードは上がりません。
そのため、「読むこと」も仕組みに組み込みました。リスクの高い変更に対しては、2軸でレビューを行う制度にしています。
- 軸A：アーキテクチャ観点 — レイヤーの境界・依存方向・設計の健全性
- 軸B：コード観点 — バグ・パフォーマンス・セキュリティ
この2つを独立して走らせ、最後に人間が両方の結果を統合して「進める / 直す / 止める」を判定します。重要なのは、最終判定そのものはAIに委ねないことです。AIはあくまで観点を洗い出す役割であり、決断するのは人間です。
ポイントは、どの変更に対してこのレビューを必須にするかを、リスク基準の表で機械的に決めている点です。「セキュリティ領域に触れる」「複数モジュールをまたぐ」といった条件に合致すれば、レビュー軸が自動的に必須化されます。「レビューすべきかどうか」を毎回人間が迷うこと自体を、制度によって排除しました。
「誰がどのAIに振るか」も、明文化した
私たちは、役割の異なるAIを使い分けています。「タスクを分析・計画・統合する側（オーケストレーター）」と、「定義済みのスコープを愚直に実装する側（実行係）」です。
最初は、その場の雰囲気で使い分けていました。しかしそれだと、人によって「これはどっちに振るべき？」という迷いが生じます。そのため、ルーティングの方針も文章化しました。
セキュリティに触れる / 複数モジュール / アーキテクチャ判断 → 計画側が直接担当
明確なAC（受入基準） + 単一スコープ → 実行係に委譲可
それ以外 → タスクを分割して再評価
特に徹底したのは、「セキュリティ・認証・秘匿情報の扱いは、絶対に実行係に委譲しない」と明記したことです。開発が速くなるからといって何でも丸投げすると、本来人間が慎重に判断すべきポイントを素通りさせてしまいます。「委譲していい領域」と「してはいけない領域」の境界線を、最初に定義しておくことが肝要です。
文脈で発動する知識——「思い出せ」を仕組みにする
すべてのルールを常時AIに読ませようとすると、情報量が多すぎてAIも人間も埋もれてしまいます。そこで、ルールを「文脈に応じて発動する知識」として切り出しました。
「セキュリティの話になったら、この入力検証の方針を必ず参照する」「DB変更のときは、マイグレーションのこの手順を踏む」——こうした “その場面でこそ思い出すべきこと” を、トリガーごとに分けて定義しておきます。常時適用する基本ルールと、文脈依存の知識を分離することで、どちらも形骸化せずに機能するようになります。
これは、個人運用の lessons.md の正当進化系だと思っています。失敗を一箇所のメモに乱雑に溜めるのではなく、「いつ、どのタイミングで思い出すべきか」というトリガーとセットで保存するのです。
で、何が変わったか
「個人の生産性が上がった」という話は、他の記事に譲ります。これを組織で運用し始めたことで、以下のような変化が起きました。
- 新メンバーのオンボーディングが圧倒的に高速化しました。 「うちのやり方」がドキュメントとしてシステム化されているため、暗黙知の伝達を待つ無駄な時間が消えました。
- レビューのブレが激減しました。 判定基準がテーブル化されているため、誰がレビューを担当しても同じラインでストップをかけられます。
- AIが本当の意味で “チームの一員” になりました。 個人の好みに振り回されることなく、組織が定義したルールの枠組みを正確に走ってくれます。
一番の収穫は、判断基準が「誰かの頭の中」から「コードのように保守できるドキュメント」になったことです。これまで棚卸ししたことのなかった「自分たちが何を、どういう基準で判断していたのか」を、初めてすべて言語化することができました。
おわりに——同じ壁に直面している人へ
もしあなたが、「個人ではAIをうまく使いこなせているのに、チームに広げた途端に開発が空中分解し始めた」と感じているなら、その原因はAIの性能でもメンバーのスキルでもないかもしれません。判断基準が、まだ誰かの頭の中に眠っているだけではないでしょうか。
AIを導入して一番変わったのは、実装スピードでも、人間の役割分担でもありませんでした。
「自分たちが何を、どういう基準で判断していたのか」——それを初めて、頭の外へ吐き出して明文化したことです。
AIに正しく動いてもらうために言語化したルールは、巡り巡って、人間のチームを一番強くしてくれました。
| 個人運用 | 組織運用 |
|---|---|
lessons.md に失敗を溜める |
「MUST NOT 表」に昇華させる |
| コードを読める人が（属人的に）読む | 読むことを「2軸のレビュー制度」にする |
| その場の気分でAIの役割を振る | ルーティングの基準を明文化する |
| 暗黙知を本人が抱え込む | ドキュメントに判断基準を持たせる |