取り組みの背景:なぜコンテキスト・エンジニアリングが「上級スキル」なのか
Antigravity を使いこなすうえで、最も差がつくスキルがあるとすれば、それはコンテキスト・エンジニアリングです。プロンプトの書き方を覚えることは誰でもできます。しかし、複数万行に及ぶコードベースで、AIが常に正確な文脈を持ち、適切な判断を下し続けるための「環境設計」は、別次元の技術が必要です。
対象読者は次のような方です。
- Antigravity を日常的に使い、基本操作は習得済みの開発者
- チームや企業での Antigravity 導入を検討・推進しているテックリード
- 10万行超のコードベースで AI 精度が低下する問題に直面している方
- Antigravity のコンテキスト上限に悩み、効率的な設計を模索している方
コンテキスト・エンジニアリングを本質から理解することで、Antigravity があなたのプロジェクトに対して「初めてコードを見た外部委託エンジニア」ではなく、「プロジェクトの全歴史を知る上級エンジニア」として振る舞えるようになります。
入門的な概念はコンテキストエンジニアリング入門:AIを「自分専用パートナー」に育てる考え方で解説していますので、まずそちらをご確認ください。
第1章:コンテキスト設計の三層アーキテクチャ
1-1. なぜ「三層」なのか
多くの開発者が AGENTS.md に「プロジェクトの概要と守るべきルール」を羅列しておしまいにしています。これは初歩的なアプローチです。上級のコンテキスト設計では、情報を三つの層に分けて管理します。
Layer 1 — プロジェクト知性層(Project Intelligence Layer)
プロジェクト全体を通じて変わらない「DNA」を定義する層です。アーキテクチャの哲学、技術スタックの選定理由、禁止事項とその理由、ドメイン固有の用語定義などが含まれます。
Layer 2 — 動的コンテキスト層(Dynamic Context Layer)
タスクや作業フェーズに応じて切り替わる情報の層です。現在スプリントの目標、作業中のモジュールの依存関係、一時的なフラグや回避策などが含まれます。
Layer 3 — セッション知性層(Session Intelligence Layer)
現在のセッションでのみ有効な文脈です。直前の変更内容、議論の結論、エラーの原因と対処法などが含まれます。
この三層を意識して設計することで、AIに「適切な粒度で適切なタイミングに適切な情報を与える」ことが可能になります。
1-2. Layer 1:AGENTS.md の高度な設計パターン
AGENTS.md は単なる「ルール文書」ではなく、AIにプロジェクトの思考様式を伝える知性の媒体として設計すべきです。
以下は、実際のプロダクション環境で効果を発揮した高度な AGENTS.md の構造例です。
# Project Intelligence — [プロジェクト名]
## Architecture Philosophy
このプロジェクトは「Hexagonal Architecture(Ports & Adapters)」を採用している。
**理由**: ビジネスロジックをインフラ実装から分離し、テスト可能性と移植性を最大化するため。
### 意思決定の優先順位
1. 既存パターンに従う(新しいパターンを発明するより一貫性を優先)
2. TypeScript の型安全性を妥協しない(`as unknown as` は原則禁止)
3. エラーは必ず `Result<T, E>` 型で返す(例外スローは UI 層のみ許可)
## Domain Vocabulary(ドメイン用語定義)
- **Listing**: 物件情報の単位。`Property` と混同しないこと(Property は法的所有権の概念)
- **Offer**: ユーザーが送信した購入意向。`Bid` とは異なる(Bid はオークション型のみ)
- **Escrow**: 第三者保管状態。必ず法務チェック済みのワークフローを経ること
## What NOT to Do
- [ ] ビジネスロジックを `src/infrastructure/` に書かない
- [ ] `console.log` を本番コードに残さない(必ず `logger.info()` を使う)
- [ ] Stripe の price ID をハードコードしない(必ず `config/pricing.ts` 経由)
- [ ] DB アクセスを UI コンポーネントから直接行わない
## Uncertainty Protocol
不明点がある場合の対応順序:
1. `src/docs/decisions/` の ADR(Architecture Decision Records)を参照
2. 既存の類似実装パターンを踏襲
3. 上記で判断できない場合、実装前に必ず確認を求めるポイントは「何をするか」だけでなく「なぜそうするか」と「不確かな時どうするか」を明示することです。理由が書かれていないルールは、AIが文脈を理解できずに機械的に守るだけになります。
1-3. Layer 2:動的コンテキストの注入パターン
大規模プロジェクトでは、スプリントやモジュールごとに作業文脈が変わります。毎回 AGENTS.md を書き換えるのは非効率です。代わりに、動的コンテキスト注入の仕組みを整備します。
# scripts/inject-context.sh
#!/bin/bash
# 現在の作業コンテキストをセッション開始時に注入するスクリプト
SPRINT_FILE=".antigravity/current-sprint.md"
MODULE_FILE=".antigravity/current-module.md"
if [ -f "$SPRINT_FILE" ]; then
echo "## 📍 Current Sprint Context"
cat "$SPRINT_FILE"
echo ""
fi
if [ -f "$MODULE_FILE" ]; then
echo "## 🔧 Active Module Context"
cat "$MODULE_FILE"
echo ""
fi
echo "## ⚠️ Active Workarounds"
cat ".antigravity/workarounds.md" 2>/dev/null || echo "(現在なし)"このスクリプトで生成したコンテキストを、セッション冒頭の最初のメッセージとして送信することで、AIは即座に「今何の作業をしているか」を把握できます。
第2章:Knowledge Items の階層化と最適化
2-1. Knowledge Items の設計原則
Antigravity の Knowledge Items(ナレッジアイテム)は、単純にファイルを追加するだけでは効果が薄くなります。情報の密度と検索性を最適化する設計が必要です。
上級の Knowledge Items 設計では、以下の三原則を守ります。
原則1:一つのナレッジアイテムは一つのトピックに集中する
「API仕様とデータベーススキーマと認証フローをまとめた総合ドキュメント」は避けます。代わりに、api-spec.md、db-schema.md、auth-flow.md として分割します。AIのコンテキスト検索は、文書が短く焦点が絞られているほど精度が上がります。
原則2:ナレッジアイテムにも「なぜ」を書く
# 認証フロー — Why This Design
## 現在の実装
JWT + Refresh Token のローテーション方式を採用。
## なぜ Session Cookie を使わないのか
- Cloudflare Workers 環境での SameSite 制約
- CDN エッジでのセッション同期コストの問題
- この決定は 2025-11 のインシデント #143 を受けて変更済み
## 今後の変更予定
2026-Q3 に Passkey 対応を追加予定(design-doc/passkey-migration.md 参照)原則3:定期的なガベージコレクション
古くなったナレッジアイテムは AIを混乱させます。3ヶ月に一度、全ナレッジアイテムをレビューし、廃止済みの情報には明示的に「非推奨」マークを付けるか削除します。
2-2. 大規模コードベースでの Knowledge Items 優先度設定
10万行超のコードベースでは、全てをナレッジアイテムに追加することはできません。優先度は次の基準で決定します。
最優先(必ず追加):
- システムの「接合部」となるインターフェース定義(API契約、イベントスキーマ)
- 変更が他に波及する中核的なデータモデル
- 誤解しやすいビジネスルールとその例外処理
- 過去に重大バグを引き起こした箇所のコンテキスト
中優先(重要モジュールに追加):
- 複雑な状態管理のフロー図
- 外部サービスとの連携仕様
- テスト戦略と境界条件の説明
低優先(基本的には追加しない):
- 自己説明的なユーティリティ関数
- 標準的なCRUD実装
- サードパーティライブラリの使い方(公式ドキュメントへのリンクで十分)
2-3. コンテキスト圧縮テクニック
Antigravity のコンテキストウィンドウには上限があります。大規模プロジェクトでは、コンテキスト圧縮が重要なスキルになります。
# ❌ 冗長な書き方(コンテキストを無駄に消費)
ユーザーが商品をカートに追加する際は、まず在庫データベースをチェックし、
在庫がある場合はカートテーブルに追加し、在庫がない場合はエラーを返します。
また、プレミアム会員の場合は最大10個まで追加でき、通常会員は5個までです。
さらにセール期間中は数量制限が変わることがあり...
# ✅ 圧縮された書き方(同じ情報をコンパクトに)
カート追加ロジック:
- 在庫チェック → カート追加 or StockError
- 数量上限: Premium=10 / Standard=5 / セール中は config/sale-limits.ts 参照
- 実装: src/domain/cart/CartService.ts の `addItem()` メソッド情報量を減らすのではなく、情報密度を高めるのがコンテキスト圧縮の本質です。
第3章:スコープ制御と精度向上の実践技法
3-1. コンテキストスコープの意図的な制御
Antigravity が大量のファイルを参照すると、むしろ精度が落ちることがあります。これは**コンテキスト過負荷(Context Overload)**と呼ばれる現象で、AIが全ての情報を等価に扱おうとして本質的な情報が埋もれてしまうためです。
上級テクニックとして、スコープ制御プロンプトを活用します。
以下のファイルのみを参照して作業してください:
- src/features/checkout/CheckoutFlow.tsx
- src/domain/order/OrderService.ts
- src/api/payment/route.ts
他のファイルは参照しないでください。これらのファイル内で完結しない場合は、
インターフェースや型定義のみ確認し、実装の詳細には入らないでください。
このようなスコープ指定により、AIの注意を必要な箇所に集中させることができます。
3-2. タスク分解による精度向上
複雑なタスクをAIに一度に依頼すると精度が下がります。上級のコンテキスト・エンジニアリングでは、タスクを意図的に分解してAIに提示します。
# ❌ 精度が低い依頼の例
「決済フローを全部リファクタリングして、エラーハンドリングも改善して、
テストも追加して、型安全性も高めてください」
# ✅ 精度が高い依頼の例(段階的タスク分解)
Phase 1(型安全性):
「まず CheckoutService.ts の型定義のみを確認し、`any` 型が使われている箇所を
リストアップしてください。修正はまだしないでください」
Phase 2(リファクタリング):
「先ほどリストアップした箇所を、Result<T, E> 型に変換してください。
他のファイルへの影響は最小限にしてください」
Phase 3(テスト):
「変更した関数のユニットテストを追加してください。
エッジケースは AGENTS.md の Uncertainty Protocol に従って判断してください」
3-3. フィードバックループの設計
AIの精度を長期的に向上させるには、フィードバックループの仕組みを AGENTS.md に組み込みます。
## AI Interaction Patterns — What Worked
### 効果的だったプロンプトパターン
1. 「〜のみを修正し、他には手を加えないでください」
→ スコープを明確にすることで副作用が減少
2. 「修正前に変更内容の要約を出力してください」
→ 予期しない変更を事前にキャッチできる
3. 「既存のテストが通ることを確認してから提示してください」
→ 回帰バグを防止
### 避けるべきパターン
- 「ベストプラクティスで実装してください」(判断基準が曖昧)
- 「パフォーマンスを改善してください」(測定基準がない)
- 「全体的にきれいにしてください」(スコープが不明確)このドキュメントをチームで継続的に更新することで、AIとのインタラクション品質が組織的に向上します。
第4章:チーム開発での「コンテキスト汚染」防止
4-1. コンテキスト汚染とは何か
チーム開発で Antigravity を使う際に最大の落とし穴がコンテキスト汚染です。これは、あるメンバーのセッションで蓄積されたコンテキスト(特に誤った前提や一時的な回避策)が、チーム共有のコンテキスト設計に混入することで発生します。
具体的な症状:
- 別のメンバーが同じ機能を全く違うアーキテクチャで実装する
- AGENTS.md に矛盾するルールが蓄積される
- 一時的な回避策が永続的なルールとして定着する
4-2. コンテキスト統一フレームワーク
チームでのコンテキスト品質を維持するには、以下のフレームワークを導入します。
Context Review Process(週次):
## Weekly Context Review Agenda
1. AGENTS.md の変更差分確認(git diff main -- AGENTS.md)
2. 先週追加された Knowledge Items のレビュー
3. 「今週 AI に修正させた一時的な回避策」の共有
4. 永続化すべきパターン vs 削除すべき一時情報の仕分け
5. 来週の作業コンテキストの事前設計Context Ownership の明確化:
AGENTS.md の編集権限:
- Layer 1(アーキテクチャ哲学): テックリードのみ
- Layer 2(動的コンテキスト): 担当モジュールのオーナー
- Layer 3(一時的な注記): 全メンバー(PRレビューで確認)
4-3. AGENTS.md のバージョン管理戦略
AGENTS.md を git で管理することは基本ですが、上級チームではさらに踏み込んだ管理を行います。
# AGENTS.md 変更時の必須チェックリスト(git hook として設定)
#!/bin/bash
# .git/hooks/pre-commit
if git diff --cached --name-only | grep -q "AGENTS-md"; then
echo "⚠️ AGENTS.md が変更されています"
echo "変更前に以下を確認してください:"
echo " 1. 変更はチームで合意済みですか?"
echo " 2. 既存のルールと矛盾していませんか?"
echo " 3. 理由(Why)は記述しましたか?"
read -p "続行する場合は 'yes' を入力してください: " confirm
if [ "$confirm" != "yes" ]; then
exit 1
fi
fi第5章:Planning Mode との連携による大規模設計
Antigravity の Planning Mode は、コンテキスト・エンジニアリングと組み合わせることで真の力を発揮します。詳細はAntigravity Planning Mode — 大規模プロジェクトの AI 駆動設計戦略で解説していますが、ここでは上級の連携パターンを紹介します。
5-1. 「コンテキスト事前ロード」パターン
Planning Mode に入る前に、関連するコンテキストを意図的にロードします。
[Planning Mode 開始前のコンテキスト事前ロード]
これから [機能名] の設計を行います。Planning Mode に入る前に、
以下のコンテキストを確認してください:
1. AGENTS.md の「Architecture Philosophy」セクション
2. src/domain/[関連ドメイン]/README.md
3. 過去の関連決定: docs/decisions/ADR-[番号].md
これらを踏まえた上で Planning Mode に切り替えてください。
目標: 既存アーキテクチャに自然に統合される設計を優先すること
5-2. 設計決定のコンテキスト化
Planning Mode で生まれた設計決定を、その場でコンテキストに変換します。
# ADR-042: 検索機能のリアルタイム化
## 決定
WebSocket ではなく Server-Sent Events (SSE) を採用
## 理由(Antigravity Planning Mode で検討)
- WebSocket: Cloudflare Workers でのサポートが限定的
- SSE: 一方向ストリームで要件を満たし、インフラコストが低い
## Antigravity への指示
このファイルを参照する際は:
- 検索の「リアルタイム」実装は必ず SSE を使うこと
- WebSocket の提案は却下済みであることを前提とすること第6章:実装パターンと実際のコード例
6-1. コンテキスト検証スクリプト
コンテキスト設計の品質を自動検証するスクリプトです。
#!/usr/bin/env python3
"""
scripts/validate-context.py
AGENTS.md と Knowledge Items の品質を検証するスクリプト
"""
import re
import sys
from pathlib import Path
def validate_agents_md(filepath: Path) -> list[str]:
"""AGENTS.md の品質チェック"""
errors = []
content = filepath.read_text(encoding='utf-8')
# 必須セクションのチェック
required_sections = [
"## Architecture Philosophy",
"## What NOT to Do",
"## Uncertainty Protocol",
]
for section in required_sections:
if section not in content:
errors.append(f"Missing required section: {section}")
# ルールに「なぜ」が欠けているかチェック
rules = re.findall(r'- \[ \] (.+)', content)
for rule in rules:
if len(rule) < 20: # 短すぎるルールは理由が省略されている可能性
errors.append(f"Rule may be missing context: '{rule}'")
# 非推奨マークなしの古い日付参照をチェック
old_dates = re.findall(r'202[34]-\d{2}', content)
if old_dates:
errors.append(f"Old date references found (consider updating): {old_dates}")
return errors
def validate_knowledge_items(directory: Path) -> list[str]:
"""Knowledge Items のディレクトリ構造チェック"""
errors = []
md_files = list(directory.glob("**/*.md"))
for filepath in md_files:
content = filepath.read_text(encoding='utf-8')
word_count = len(content.split())
# 単一ファイルが大きすぎる場合
if word_count > 2000:
errors.append(
f"{filepath.name}: {word_count} words — consider splitting into smaller files"
)
# 「なぜ」のセクションが欠けている場合
if "## Why" not in content and "## なぜ" not in content and word_count > 300:
errors.append(f"{filepath.name}: Missing 'Why' section")
return errors
if __name__ == "__main__":
errors = []
agents_path = Path("AGENTS-md")
if agents_path.exists():
errors.extend(validate_agents_md(agents_path))
knowledge_dir = Path(".antigravity/knowledge")
if knowledge_dir.exists():
errors.extend(validate_knowledge_items(knowledge_dir))
if errors:
print("❌ Context validation failed:")
for error in errors:
print(f" - {error}")
sys.exit(1)
else:
print("✅ Context validation passed")実行結果の例:
$ python3 scripts/validate-context.py
✅ Context validation passed
# または
❌ Context validation failed:
- Missing required section: ## Uncertainty Protocol
- auth-flow.md: 3247 words — consider splitting into smaller files
6-2. コンテキスト品質ダッシュボード
チームでコンテキスト品質を可視化するための簡易スクリプトです。
#!/bin/bash
# scripts/context-dashboard.sh
echo "=== Antigravity Context Quality Dashboard ==="
echo ""
# AGENTS.md の統計
echo "📋 AGENTS.md Stats:"
AGENTS_WORDS=$(wc -w < AGENTS.md)
AGENTS_RULES=$(grep -c "- \[ \]" AGENTS.md || echo 0)
echo " - Word count: $AGENTS_WORDS"
echo " - Defined rules: $AGENTS_RULES"
echo ""
# Knowledge Items の統計
echo "📚 Knowledge Items:"
TOTAL_FILES=$(find .antigravity/knowledge -name "*.md" 2>/dev/null | wc -l)
TOTAL_WORDS=$(find .antigravity/knowledge -name "*.md" 2>/dev/null -exec wc -w {} + | tail -1 | awk '{print $1}')
echo " - Total files: $TOTAL_FILES"
echo " - Total words: $TOTAL_WORDS"
echo ""
# 最終更新日
echo "🕐 Last Context Updates:"
git log --oneline --since="7 days ago" -- AGENTS.md .antigravity/ 2>/dev/null | head -5
echo ""
echo "=== Dashboard Complete ==="まとめ
Antigravity のコンテキスト・エンジニアリングを上級レベルで実践するための要点をまとめます。
コンテキストは「三層アーキテクチャ(プロジェクト知性層・動的コンテキスト層・セッション知性層)」で設計することで、情報の管理と更新が格段に容易になります。AGENTS.md は単なるルール文書ではなく、「なぜ」を含んだプロジェクトの知性の媒体として設計すべきです。Knowledge Items は量より密度と焦点を意識し、定期的なガベージコレクションで鮮度を保ちます。
チーム開発では「コンテキスト汚染」を防ぐための組織的なフレームワーク(週次レビュー・オーナーシップ制・バージョン管理戦略)が不可欠です。そして、コンテキスト過負荷を避けるためのスコープ制御と、タスク分解による段階的な依頼が精度向上の鍵です。
これらの技法を組み合わせることで、Antigravity はあなたのプロジェクトに対して「初めてコードを見た外部エンジニア」ではなく、「全ての文脈を理解した上級エンジニア」として機能するようになります。コンテキスト・エンジニアリングは一度設定して終わりではなく、プロジェクトとともに育てていく継続的な実践です。
基礎から体系的に学びたい方には、プロジェクトナレッジの設計・整理手法もあわせてご覧ください。
さらにコンテキスト設計の理論的背景と実践例を深く