はじめに

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の役割を振る	ルーティングの基準を明文化する
暗黙知を本人が抱え込む	ドキュメントに判断基準を持たせる