チームが十分に長く一緒に働くと、ある種のプラクティスは 見えなくなります。上級エンジニアがプルリクエストを却下するとき、 チェックリストを参照するわけではありません。彼女は、ほとんど瞬時に、 エラーハンドリングが不完全であること、アブストラクションが時期尚早であること、命名がチームの慣習に従っていないことを認識します。同じ直感が、AIにコードを生成させるプロンプトの仕方、リファクタリング要求の枠組み、作業を完了とみなす前にAIに何を確認させるか、といった判断を形作ります。説明を求められれば説明できますが、その瞬間には、長年のレビュー、本番障害、アーキテクチャ議論から築かれたパターン認識が働いています。この暗黙知（何を生成し、何を確認し、何を指摘し、何を却下するか）は、チームにとって最も価値があり、かつ最も脆弱な資産です。それは人々の頭の中にあり、ペアリングやコードレビューを通じてゆっくりと伝達され、誰かが退職すると一緒に去っていきます。

以前の記事で、私は個々の開発者がAIとどのように協働するかを改善する手法について述べました。キュレーションされたプロジェクトコンテキストの共有、設計会話の構造化、決定事項を生きているドキュメントとして外部化することです。これらはすべて、一人の成果を向上させます。しかし、別の問題は解決しません。同じチームの2人の開発者が、同じツール、同じコードベース、同じプロジェクトコンテキストを使いながら、 materially 異なる結果を生み出すのです。その差は、AIがプロジェクトについて何を知っているかではありません。AIにその知識で何をさせるかが異なるのです。指示は人によって異なり、コードレビューだけでなく、あらゆる種類のやり取りで異なります。

AIがコードを生成したり、既存システムをリファクタリングしたり、セキュリティ脆弱性をチェックしたり、プルリクエストをレビューしたりする際に形作られる基準は、Slackで共有されるTipsや上級者の頭の中にある暗黙知であってはなりません。バージョン管理された成果物として、「ここでのやり方」を誰に対しても一貫して実行できる形式にエンコードしたものでなければなりません。

一貫性の問題

AIを活用した開発が誰がプロンプトするかに依存するとき、上級エンジニアはボトルネックになります。コードを書くからではなく、何を求めるべきかを知っている唯一の存在だからです。

私はこのパターンを何度も観察してきました。上級エンジニアがAIに新しいサービスを生成させる際、本能的に次のように指定します。チームの関数型スタイルに従う、既存のエラーハンドリングミドルウェアを使う、lib/services/に配置する、型を明示的にする、console.logではなくチームのロギングユーティリティを使う。リファクタリングを依頼するときは、パブリックコントラクトを保持し、時期尚早な抽象化を避け、関数を小さく単一目的に保つよう指定します。セキュリティチェックを依頼するときは、SQLインジェクションをチェックし、すべてのエンドポイントで認可を検証し、シークレットがハードコードされていないことを確認するよう指定します。

経験の浅い開発者が同じタスクに直面したとき、AIに「通知サービスを作成して」や「このコードをきれいにして」や「これがセキュアかチェックして」と依頼します。同じコードベース、同じAI。レビューだけでなく、あらゆるやり取りで品質ゲートが完全に異なります。

これはジュニア開発者のせいではありません。彼らはまだ直感を身につけていないのです。しかし、この不一致はコストがかかります。ある開発者がプロンプトするとAI生成コードがチームの慣習から逸脱し、別の開発者がプロンプトすると適合します。リファクタリングの品質は誰が依頼するかによって変わります。セキュリティチェックは質問の枠組みによって異なるものを検出します。技術的負債が不均等に蓄積されます。

本能的には、これをスキル問題として扱いたくなります。ジュニアを教育し、より良いドキュメントを書き、より多くのペアリングを行う。これらはすべて役立ちますが、遅く、スケールしません。知識はチームに存在します。ただ、それを一貫して配布する手段がないのです。必要なのは、上級者が本能的に適用していることを誰でも利用できるようにし、覚えておくべきアドバイスではなく、実行される指示にすることです。

これはスキル問題ではなく、システムの問題です。そして、システムの解決策が必要です。

本シリーズの以前の手法は、AIが知っていることに対処します。Knowledge PrimingはAIにプロジェクトの慣習を与えます。Design-First collaborationはアーキテクチャに関する合意を構築します。Context Anchoringはその合意をセッション間で持続させます。本記事は異なることを扱います。誰がプロンプトするかにかかわらず、すべての意味のあるやり取りで、AIがチームの判断を一貫して適用させることです。

実行可能なガバナンス

チームは常に自らの基準を成文化しようとしてきました。常に課題だったのは、ドキュメントと実践の間のギャップです。Wiki上のチェックリストは、誰かがそれを読んで記憶し、時間的プレッシャーの下で一貫して適用することに依存します。私の経験では、そのギャップこそが、ほとんどの成文化の取り組みが静かに失敗する場所です。

AIの指示はこの動態を興味深い方法で変えます。チームの基準をAIの指示としてエンコードした場合、誰かが適用することを覚えておく必要はありません。指示が適用そのものです。開発者がチームのアーキテクチャパターンを埋め込んだ指示を使ってコードを生成したり、チームの脅威モデルをエンコードしたセキュリティチェックを実行したりするとき、基準はワークフローの副作用として適用され、規律を必要とする別個のステップではありません。ガバナンスはワークフローそのものです。

これを2つの動きとして考えると有用です。

暗黙から明示へ。最初の動きは馴染みのあるものです。上級者が本能的に知っていることを書き下すことです。違いは、対象形式がWikiページやチェックリストではなく、AIが実行できる構造化された指示セットであることです。書き出す行為は、かつて明文化されなかった前提を表面化させます。セキュリティ上の問題が「重大」か「重要」かを分ける正確な基準は何でしょうか？こうした区別は上級者にとっては直感的ですが、AIにとっては明確でなければなりません。

ドキュメントから実行へ。2番目の動きが重要なものです。リンティングルールはバージョン管理された設定ファイルであり、個人の好みではありません。CI/CDパイプラインは実行可能な定義であり、デプロイ手順を記述したWikiページではありません。AIの指示も同じカテゴリに属します。実行される設定であり、情報を伝えるドキュメントではありません。これらの指示がリポジトリに置かれ、プルリクエストを通じてレビューされ、デフォルトで共有されるとき、他のチームインフラと同等の地位を持ちます。開発者はチームの基準の全セットを頭の中に抱える必要がありません。指示を呼び出します。チームの判断は、開発者が暗記したからではなく、インフラがエンコードしているから一貫して適用されます。

どのようなものか

よく構造化された実行可能な指示には、認識可能な解剖構造があります。四つの要素があり、それぞれが異なる役割を果たします。この解剖構造は、指示の目的に関わらず適用されます。

  • 役割の定義。AIがペルソナを必要とするからではなく、役割が専門性のレベルと視点を設定するからです。「役割：チームのアーキテクチャパターンに従って新しいサービスを実装する上級エンジニア」という役割は、一般的なプロンプトとは異なるベースラインを確立します。役割は、その後のすべての指示が適用されるレンズです。
  • コンテキスト要件。指示が動作する前に必要とするもの。関連するコード、プロジェクトのアーキテクチャコンテキストへのアクセス、適用可能な制約など。これにより、依存関係が明示的になり、開発者が提供することを覚えていることを期待しなくて済みます。
  • 分類された基準。個々の項目よりもカテゴリが重要です。生成指示の場合、カテゴリは次のようになります。アーキテクチャ準拠（必須）、慣習遵守（推奨）、スタイルの好み（望ましい）。セキュリティ指示の場合、重大な脆弱性（ブロッカー）、重要な懸念（マージ前に解決必須）、助言（追跡・評価対象）。レビュー指示の場合、重大な問題、重要な発見、提案。この優先順位構造は、チームの判断をエンコードするものであり、知識だけをエンコードするものではありません。AI、そしてAIを通じて開発者に、何が最も重要かを伝えます。
  • 出力形式。サマリー、分類された所見、明確な次のステップを含む構造化されたレスポンス。この形式により、指示からの出力が実行間および開発者間で比較可能になります。これは複数の人が同じ指示を定期的に使うようになったときに重要です。生成指示の場合、これは生成されるコードの完全性と構造を形作ります。所見レポートではなく、出力自体の慣習です。

この原則は、AIとのやり取りの全範囲に適用されます。例：

  • 生成：チームが新しいコードを構築する方法（アーキテクチャパターン、命名、エラーハンドリング、テストの期待値）をエンコードし、最初の出力からチームの慣習に沿ったものにします。
  • リファクタリング：チームが既存のコードを改善する方法（コントラクトの保持、時期尚早な抽象化の回避、漸進的な変更の提案）をエンコードします。
  • セキュリティ：チームの脅威モデル（何をチェックし、深刻度をどのように評価するか）をエンコードし、汎用ではなくチーム固有のチェックにします。
  • レビュー：レビューでチームがチェックするもの（アーキテクチャとの整合性、エラーハンドリング、型安全性、慣習）を一貫した深刻度構造でエンコードします。

指示は小さく、単一目的に保ちます。小さな指示は焦点を維持しやすく、メンテナンスしやすく、柔軟に組み合わせられます。

暗黙知の表面化

これらの指示を作成する上で最も興味深い部分は、抽出プロセスです。これは、チームの上級エンジニアへのインタビューに相当し、開発ワークフロー全体にわたる鋭い質問で構成されます。個人の判断に委ねてはならないアーキテクチャ上の決定は何か？生成されたコードで最も頻繁に修正される慣習は何か？本能的に適用されるセキュリティチェックは何か？レビューで即時却下を引き起こすものは何か？きれいなリファクタリングと過剰設計を分けるものは何か？

回答は直接、指示の構造にマッピングされます。譲れないアーキテクチャパターンは生成制約になります。頻繁な修正は慣習チェックになります。セキュリティの直感は脅威モデルの項目になります。レビューの却下は重大チェックになります。繰り返されるミスはフラグを立てるアンチパターンになります。インタビューは本質的に指示を書く行為であり、作成行為は暗黙知を明示的で優先順位付けされたチェックに整理する行為です。

このプロセスは、得られる指示を超えた価値があることに気づきました。あるプロジェクトでは、抽出会話を通じて、2人の上級エンジニアが「重大」なセキュリティ懸念と「重要」なセキュリティ懸念の閾値について静かに異なる見解を持っていることが明らかになりました。これは、それぞれが異なるプルリクエストをレビューしていたため、これまで表面化していなかった相違でした。共有の指示を書く行為により、その区別が明示的にされました。チームの経験の浅い開発者がその指示を使い始めると、効果は即座に現れました。彼らの最初のレビューで、新しく追加されたエンドポイントに認可チェックが欠けていることが検出されました。これは以前、上級者がレビュー担当になったときにのみ発見されていた種類の問題です。指示は開発者をより経験豊かにしたわけではありません。彼らの未熟さをよりコストの低いものにしたのです。

基準がワークフローと出会う場所

これらの指示は単一目的のツールではありません。開発ワークフローの異なるポイントで適用され、適用ポイントがその価値を形作ります。

生成時、開発者がAIに新しいサービスを作成させたり、機能を実装させたり、テストを書かせたりするとき、生成指示は出力が最初からチームの慣習に従うことを保証します。これはエンコードされた基準が最もレバレッジを発揮する場所です。事後的に不整合を検出するのではなく、不整合を防ぎます。

開発中、リファクタリング指示は改善をチームの規範に沿ったものに保ち、セキュリティ指示は汎用チェックリストではなくチームの脅威モデルを適用します。基準は開発プロセスの全過程に存在し、最後に付け加えられるものではありません。

レビュー時、開発者が作業（AI生成か手動作成かを問わず）を完了したとき、レビュー指示はチームの品質ゲートを適用します。しかし、レビュー時は不整合を捉える最後の機会です。ワークフローの中で基準が適用されるのが早ければ早いほど、レビューに到達する問題は少なくなります。

オプションとしてCIで、一部のチームはこれらの指示を継続的インテグレーションパイプラインに拡張し、自動化された一貫性チェックとして使用します。CIレベルの指示は、パイプラインを遅くしない程度に高速で、ノイズの多い偽陽性を避ける程度に予測可能で、他のCIゲートと同等の規律でメンテナンスされる必要があります。

共有インフラとしての基準

個人のマシン上のプロンプトは、個人の生産性ハックです。チームのリポジトリにある同じプロンプトはインフラです。その違いは、個人の好みとチームのプラクティスの違いです。

リポジトリに置かれると、それはバージョン管理された成果物が持つ性質を継承します。変更が追跡され、基準は集合的に所有され、すべての開発者が同じバージョンで作業します。異なるツールはこれを異なる方法で実装します。カスタムコマンド、スキル、ルールファイル、プロジェクト指示などですが、根本的な性質は同じです。AIが一貫して実行する、バージョン管理された共有成果物です。

これが、チームが集まって基準をより良くする方法です。生成指示にチームの新しいエラーハンドリングパターンが指定されていないことに気づいた開発者は、それを更新するPRを提出します。セキュリティインシデントがセキュリティ指示のギャップを明らかにしたとき、その修正はコミットとなり、他のインフラ変更と同様にレビューされ、マージされます。基準は上級者が下ろして固定した静的なルールではありません。チーム全体がメンテナンスし、実際のプラクティスによって磨かれ、チームがすでにコードに使っている同じプルリクエストワークフローを通じて改善される、生きている成果物です。

以前の記事で、私はコンテキスト管理の主要な変化を、コンテキストを習慣ではなくインフラとして扱うことだと述べました。同じ原則がここにも拡張されます。プライミングドキュメントはAIにプロジェクトの動作方法を伝え、実行可能な指示はAIにチームの動作方法を伝えます。

これらの指示が、もう一つのドキュメント墓場になるリスクは現実のものです。熱意を持って作成され、数ヶ月で放棄される。リポジトリ配置とプルリクエストレビューはこのリスクを軽減します。リポジトリに存在する指示は可視的です。diffに現れ、プルリクエストテンプレートで参照できます。実際のプラクティスから乖離したとき、その乖離は、古くなったテストが可視的になるのと同じように、誰かが監査するからではなく、通常の業務の中で遭遇するから可視的になります。成果物がワークフローに近ければ近いほど、メンテナンスされる可能性が高くなります。

キャリブレーション

このアプローチは、会話だけでは一貫性を維持できないほどチームが大きいときに最も価値を発揮します。有用なヒューリスティック：AIを活用した出力の品質が誰がプロンプトするかによって明らかに異なる場合、または生成とレビューの作業が少数の人々を通じてルーティングされる場合（彼らだけが効果的にプロンプトする方法を知っているため）、その不一致がシグナルです。5人のチームでは必要ないかもしれません。15人のチームではほぼ確実に必要です。

コストは現実のものです。良い指示を作成するには労力が必要です。抽出インタビュー、ドラフト、反復。過度に規範的な指示は脆くなり、エッジケースで偽陽性を生んだり、正当なアプローチのバリエーションと衝突したりします。基準が進化するにつれ、メンテナンス負担が発生します。また、過剰設計のリスクもあります。AIとのすべてのやり取りに専用の指示が必要なわけではありません。

私の経験では、正しい出発点は1つの指示です。生成指示またはレビュー指示が通常、最も価値の高い選択です。最も一般的なワークフロー、最も広い品質ギャップ、最も目に見える不一致に対処します。追加の指示は、採用に続いて行うべきであり、先に行うべきではありません。

結論

これは本質的に、人々の頭の中にある判断から、共有インフラとして実行される判断へのシフトです。上級エンジニアの直感（彼女がチェックするパターン、彼女が強制する慣習、彼女がフラグを立てるリスク）は、個人的でスケールしにくいままである必要はありません。それらは抽出され、バージョン管理された指示にエンコードされ、すべての開発者とAIとのすべてのやり取りで一貫して適用できます。

そのメカニズムは新しいものではありません。チームはすでに、リンティングルール、CIパイプライン、Infrastructure as Codeでこれを行っています。AIによって変わるのは、エンコードできるものの範囲です。リンティングは構文とスタイルを捉えます。実行可能なチーム基準は、アーキテクチャ判断、セキュリティ意識、リファクタリング哲学、レビュー rigor など、以前はペアリング、メンターシップ、共有経験の年月を通じてのみ伝達されていた種類の知識をエンコードできます。

これらの基準の最も興味深い性質は、チーム所有であることです。リポジトリに存在し、プルリクエストを通じて進化し、プラクティスがギャップを明らかにすると改善されます。問題を見逃す指示は、更新されるのを待っている指示であり、その更新はチーム全体がレビューするコミットです。基準はチームの知識の出力であるだけでなく、チームの知識が成文化され、共有され、洗練されるメカニズムそのものです。