導入：AIに「社内規約」をそのまま渡してはいけない理由
「GitHub CopilotやCursorを全社導入し、@workspaceコマンドやエージェント機能でリポジトリ全体の情報を参照させているはずなのに、上がってくるプルリクエスト（PR）の品質が安定しない」
最近、開発現場において、こうした課題が顕在化するケースが増えています。本来、生産性を爆発的に高めるためにAIを導入したはずが、逆に「AIが書いたそれっぽいけれど微妙に規約違反なコード」を修正する手間、いわゆる「AI負債」が増えてしまっているのです。
ツール側は急速に進化しており、最新のGitHub CopilotやCursorでは、エージェント機能による自律的なタスク実行や、MCP（Model Context Protocol） を介した外部ツール連携まで可能になっています。それなのに、なぜ「自社の流儀」だけは頑なに守ってくれないのでしょうか。
原因はツールの性能不足ではありません。もっと根本的な設計ミス、つまり「人間用のドキュメント」をそのままAIに理解させようとしていることにあります。対話AIの設計においても、ユーザー（この場合はAI）の特性を無視した入力は、意図しない出力を招く最大の要因となります。
「人間向けの規約」はAIにとってノイズだらけ
私たちは普段、行間を読み、暗黙の了解を補完しながらドキュメントを読みます。「可読性を重視すること」や「将来の拡張性を考慮した設計にすること」といった抽象的な指示でも、経験豊富なエンジニアなら文脈（コンテキスト）を理解して、そのチームにおける正解を導き出せるでしょう。
しかし、LLM（大規模言語モデル）は違います。NLU（自然言語理解）の観点から見ると、彼らは行間を読むのではなく、確率的にトークンを繋げているに過ぎません。
人間向けに書かれた数万字のコーディング規約WikiやPDFへのリンクを、チャットのコンテキストとして渡しても、それはAIにとって「ノイズの塊」でしかないのです。どれだけ高性能なモデルを使おうと、入力される情報がAIにとって解釈しづらい構造であれば、出力の精度は上がりません。
レビュー工数が増大する「AI負債」の正体
必要なのは、AIが解釈可能な形式に変換された「構造化されたコンテキスト」です。チャットボットの対話フローを設計する際、ユーザーの発話パターンを分析して適切な導線を用意するように、AIコーディングアシスタントに対しても適切な情報構造を提供しなければなりません。
GitHub Copilotの最新機能やCursorのエージェントモードを真に使いこなす鍵は、単にプロンプトを工夫することだけではありません。MCPやカスタム命令（Rules/Skills）を活用し、AIが参照する情報そのものを、AIが消化しやすい形に「翻訳」してあげる必要があります。
この記事では、チーム開発においてAIコーディングツールのポテンシャルを最大限に引き出しつつ、ガバナンスを効かせるための「コンテキストエンジニアリング」について、技術的な裏付けとともに解説します。単なるツールの設定方法ではなく、これからのエンジニアリング組織に求められる新しい「規約管理」のあり方を論理的に紐解いていきましょう。
1. 規約の「二重管理」を恐れず、AI専用の「システムプロンプト」を定義せよ
エンジニアの多くは、DRY原則（Don't Repeat Yourself）が染み付いており、情報の二重管理を極端に嫌う傾向があります。「コーディング規約はConfluenceにあるのだから、AIもそれを参照すべきだ」と考えがちです。
しかし、人間用の規約とAI用のインストラクション（システムプロンプト）は、明確に分けるべきです。
人間用ドキュメント vs AI用インストラクション
人間用の規約は、しばしば「教育的」な側面を持ちます。「なぜそのルールが必要なのか」という背景や、「過去の経緯」が語られることも多いでしょう。これはメンバーの育成には重要ですが、LLMにとってはコンテキストウィンドウ（入力可能な情報量）を圧迫するだけの無駄な情報になりかねません。
AIに必要なのは、「背景」ではなく「制約」と「構造」です。
例えば、Cursorの .cursorrules やGitHub Copilotにおけるリポジトリ固有のインストラクション（.github/copilot-instructions.md 等）を設定する際、自然言語で長々と説明文を書くよりも、AIが処理しやすい形式に落とし込む方が遥かに精度が高まります。特に主要ツールでは、リポジトリ内に配置した設定ファイルを読み込ませる運用が標準になりつつあり、これによりチーム全体で統一されたAIの挙動を実現できます。
自然言語よりも構造化データ（Markdown/JSON）を好む
AIへの指示は可能な限り構造化することが推奨されます。これは対話AIのプロンプトエンジニアリングでも、コーディング支援AIでも同様です。
特にClaudeの最新モデルや開発ツールでは、単なるテキスト指示だけでなく、「Skills（スキル）」機能や「LSP（Language Server Protocol）」と連携した高度なコード理解が進んでいます。最新のAIモデルは、曖昧な自然言語よりも、定義されたツール定義や構造化された設定ファイルを解釈することに長けています。
したがって、プロンプトも「読み物」ではなく「設定ファイル」として記述するアプローチが、多くのLLMにおいて共通して有効です。
悪い例（自然言語のみ）：
変数名はキャメルケースにしてください。あと、Reactのコンポーネントは関数コンポーネントを使って、Hooksを積極的に利用すること。定数は別ファイルに切り出してください。
良い例（Markdown/構造化）：
# Coding Standards
## Naming Convention
- Variables: `camelCase`
- Components: `PascalCase`
- Constants: `UPPER_SNAKE_CASE`
## React Best Practices
- Use Functional Components only
- Prefer Hooks (`useEffect`, `useState`, `useMemo`)
- Avoid Class Components
## File Structure
- Constants must be imported from `@/constants`
このように箇条書きやMarkdownの見出し構造を使うことで、LLMのアテンション機構が「どこが重要な指示か」を認識しやすくなります。場合によってはJSON形式でルールを記述し、「このスキーマに従って思考せよ」と指示するのも有効です。
「規約を二重に管理するのは面倒だ」と思われるかもしれません。しかし、人間用の規約をメンテナンスする頻度と、AIの挙動を調整する頻度は異なります。AI用のインストラクションは、いわば「システム設定ファイル」です。Wikiを更新するのではなく、リポジトリ内の設定ファイルを更新し、バージョン管理システムで履歴を残す運用に変えることで、チーム全体の生産性は確実に向上します。
2. 禁止事項（Don't）ではなく、推奨パターン（Do & Example）で語らせる
「〜してはいけない」という禁止事項ばかりが並んだ規約は、AIにとっても処理が難しいものです。
NLU（自然言語理解）の技術的な特性として、LLMは否定命令の処理が苦手な傾向にあります。「赤いリンゴを想像しないでください」と言われると、どうしても赤いリンゴのイメージが浮かんでしまうように、LLMも否定された単語に関連する概念を活性化させてしまうことがあるのです。
否定命令はAIのハルシネーションを誘発する
「varを使わないでください」「any型を使わないでください」と指示しても、文脈によってはうっかり使ってしまうことがあります。これは、プロンプト内にvarやanyという単語が存在することで、そのトークンの生成確率がわずかに上がってしまうためとも言われています。
より効果的なのは、「禁止」ではなく「推奨」で上書きすることです。
×
varを使わない○ 変数宣言には必ず
constまたはletを使用する×
any型を使わない○ 未確定な型には
unknownを使用し、型ガードを実装する
このように肯定形で指示を出すことで、AIは「何をすべきか」を明確に理解し、迷いなくコードを生成できるようになります。
「Few-shot」こそが最強の規約定義
さらに強力なのが、具体例を与える「Few-shot Prompting」です。高度なLLMにおいても、指示単体（Zero-shot）で意図が伝わりにくい場合、3〜5つの具体例を提示することで出力精度が劇的に向上することが、多くの検証で明らかになっています。
一般的に、100行の言語説明よりも、少数の「理想的なコード例（Good Pattern）」と「悪いコード例（Bad Pattern）」を見せる方が、AIの出力品質は安定します。プロンプトエンジニアリングの観点から言えば、これに「なぜそうするのか」という思考プロセス（Chain-of-Thought）を組み合わせることで、さらに意図通りの挙動を引き出しやすくなります。
特にチーム独自のアーキテクチャや、特殊なライブラリの使い方は、言葉で説明するのが難しいものです。そこで、チーム内で「これが模範解答だ」と合意のとれたコードスニペットをプロンプト（あるいは.cursorrules等の設定ファイル）に含めてしまいましょう。
## Example: API Fetching
// Bad Pattern
useEffect(() => {
fetch('/api/data').then(res => res.json()).then(setData);
}, []);
// Good Pattern (Use Custom Hook)
const { data, error } = useSWR('/api/data', fetcher);
このように「Bad」と「Good」を対比させることで、AIは「何がダメで、どうすれば良いのか」という変換ロジックをコンテキストから学習します。これこそが、チームの暗黙知をAIに伝承させる最も効率的な方法と言えます。
3. プロンプトを「静的な文書」ではなく「バージョン管理されるコード」として扱う
AIへの指示（プロンプト）は、一度書いたら終わりの「静的な文書」ではありません。LLMのアップデートやプロジェクトの進行に合わせて、実験と改善のサイクルを回しながら継続的にチューニングされるべき「コード」です。
Gitで管理されるべき「チームの共通言語」
多くのチームで、プロンプトや設定ファイルが個人のローカル環境に散らばっていたり、チャットツールで共有されて流れてしまったりしています。これでは、チーム全体での品質標準化は困難です。
AIエディタの設定ファイル（.cursorrules）や、GitHub Copilotのカスタム指示ファイル（.github/copilot-instructions.md）は、必ずソースコードと同じリポジトリに含め、Gitでバージョン管理することが推奨されます。これらの設定ファイルは、チーム開発における「共通言語」として機能します。
これにより、以下のような開発フローが可能になります。
- 誰かがAI生成コードの不備を見つける（例：テストコードのモック手法が古い、特定のライブラリの使用方法が非推奨など）。
- その修正指示をリポジトリ内のAI設定ファイルに追記し、プルリクエストを作成する。
- チームでコードレビューと同様にプロンプトの変更内容を議論し、マージする。
- チーム全員のAIアシスタントが、即座に新しいルールを学習し、足並みの揃ったコーディング支援を開始する。
まさに「PromptOps」とも呼べる運用です。規約の変更がコードレビューを通じて行われ、それが即座に開発ツールに反映される。このサイクルを回せるかどうかが、AI活用チームの強さを決定づけます。
プロンプトの変更履歴と生成結果の相関を追う
プロンプトをGit管理することのもう一つのメリットは、変更の影響を追跡できることです。「先週のプロンプト変更以降、特定のバグが増えた気がする」といった場合でも、Diff（差分）を見れば原因を特定しやすくなります。
対話AI開発の現場でも同様ですが、使用するモデルが頻繁にアップデートされる環境下では、モデルの挙動変化に合わせてプロンプトを調整する必要があります。そのため、チーム開発において「プロンプトの変更履歴」は重要な資産になります。
どのような指示を追加した時に、AIの挙動がどう変わったか。A/Bテストのように変更履歴と生成結果の相関を分析し、ナレッジを蓄積していくことこそが、競争力の源泉となります。
4. 「グローバル規約」と「プロジェクト固有ルール」のレイヤー構造を設計する
LLMのコンテキストウィンドウは拡大していますが、それでも無限ではありません。また、無関係な情報を大量に入力すると、重要な指示が埋もれてしまう「Lost in the Middle」現象も発生します。
全社のコーディング規約、セキュリティガイドライン、プロジェクト固有のルール、使用しているライブラリのドキュメントなど、これら全てを一度にAIに読ませるのは得策ではありません。対話フローの設計において、ユーザーの状況に応じた適切な選択肢を提示するように、AIへの情報提供も整理する必要があります。
全社統一ルールが現場の足を引っ張る時
例えば、全社的には「Java」がメインでも、あるマイクロサービスだけは「Go」で書かれていると仮定します。この場合、Javaの詳細な規約をGoのプロジェクトで読み込ませるのは無駄どころか有害です。Javaの慣習（冗長なクラス名など）がGoのコードに混入するリスクすらあります。
効果的なのは、規約をレイヤー構造で管理することです。
- Global Level (全社共通): セキュリティ基準、著作権ヘッダー、命名の基本原則など、言語やプロジェクトに依存しない最小限のルール。
- Project Level (リポジトリ単位): 使用言語、フレームワーク、アーキテクチャパターン、ディレクトリ構造。
- Directory/File Level (局所的): 特定のモジュール内だけのルール（例：テストフォルダ内だけの特例）。
トークン制限を考慮した情報の優先順位付け
Cursorなどのツールでは、プロジェクトルートに置いた設定ファイルだけでなく、ディレクトリごとの設定も可能です。AIが現在開いているファイルや作業中のディレクトリに応じて、最も関連性の高いルールだけがコンテキストに含まれるよう設計することが重要です。
「情報は多ければ多いほど良い」のではなく、「必要な時に必要な情報だけを渡す」。これがコンテキストエンジニアリングの要諦です。どの情報がどのレイヤーに属すべきか、情報のアーキテクチャを論理的に設計する視点が求められます。
5. 自動リファクタリングを前提とした「事後チェック」の仕組みを作る
ここまでプロンプトによる制御について解説してきましたが、最後に重要な点をお伝えします。AIに100%の規約遵守を求めるべきではありません。
LLMは確率的なモデルであり、どれだけ巧みなプロンプトを組んでも、一定の確率で指示を無視したり、幻覚（ハルシネーション）を見たりします。そこに完璧を求めてプロンプト調整に何時間も費やすのは、非効率です。対話AIにおけるフォールバック設計（AIが理解できなかった場合の安全網）と同様に、コーディングAIにもセーフティネットを用意することが実用的です。
生成時に100%を求めない割り切り
AIの役割は「設計思想の理解」や「ボイラープレートの生成」「ロジックの構築」といった、クリエイティブで高次なタスクに集中させるべきです。一方で、インデントのズレ、末尾のセミコロン、import順序といった機械的なルールは、AIに守らせようと努力するより、既存のLinterやFormatterに任せる方が確実で高速です。
Linter/FormatterとAI生成の役割分担
理想的なワークフローは以下の通りです。
- AI (Generate): コンテキストを理解し、80〜90%完成したコードを生成する（ロジックや構造は正しい）。
- Linter/Formatter (Fix): 保存時やコミット時に、細かいスタイル違反を自動修正する。
- Human (Review): AIが見落とした設計上の欠陥や、ビジネスロジックの誤りをレビューする。
「AIが規約を守らない」と判断する前に、その規約がPrettierやESLintで自動修正できるものかどうかを確認してください。もし自動化できるなら、それはAIに意識させる必要のないルールです。AIには、ツールでは検出できない「コードの意図」や「可読性の本質」に注力させ、業務要件とAIの自然な挙動のバランスを取ることが重要です。
まとめ：テックリードの新しい仕事は「コンテキストエンジニアリング」だ
AIコーディングツールの導入は、単に「開発スピードが上がる」というレベルの話ではありません。それは、チームがこれまで培ってきた「規約」や「暗黙知」を、どのように形式知化し、システムに組み込むかという組織能力の再定義を迫るものです。
これからの開発組織において、最も重要なスキルの一つが「コンテキストエンジニアリング」になります。
- 人間用のドキュメントを、AIが理解可能なインストラクションに翻訳する力。
- チームの「良し悪し」の基準を、具体的なFew-shotとして抽出する力。
- それらをバージョン管理し、実験と改善のサイクルを回しながらチーム全体で育てていく運用設計力。
これらは、コードを書く能力以上に、チームの生産性を左右する変数となります。
もし、「AIを導入したけれど、思ったほど効果が出ていない」「規約違反のコードが増えて困っている」という課題があるなら、それはツールのせいではなく、コンテキストの設計不足かもしれません。
AIの特性を論理的に理解し、適切なコンテキストを設計することで、AIは強力なパートナーとして機能するはずです。
コメント