前回の投稿「AIコーディング：「Vibe Coding」からプロフェッショナルへ」では、AIオーケストレーターへの道のりで「コンテキスト管理」をベストプラクティス#6として紹介しました。しかし、あれは概要に過ぎませんでした。
今回はこのテーマを深掘りします。すぐに使える具体的なフレームワークを共有し、コンテキスト・エンジニアリング——AIの「集合知」を構築する技術——を本当にマスターできるようにします。
コンテキスト・エンジニアリングは、単にAIに情報を与えるだけではありません。AIが常に最適な情報を 、最適なタイミングで受け取り、タスクを最も効果的に完了できる環境を体系的に構築するアプローチです。毎回AIに一から説明するのではなく、AIが自動的に「何を」「どのプロセスで」「どの基準で」行うべきかを理解する仕組みを作るのです。
これこそが「AIと一緒に流れに乗る」ことと「AIをオーケストレーションする」ことの違い——VibeコーダーとAIオーケストレーターの違いです。
このフレームワークはすべてのプロジェクトに万能ではありませんが、私自身がいくつかのサイドプロジェクトで検証し、実際に業務自動化ツールの開発や社内AIコミュニティでの共有を通じて効果を確認済みです。人間がやれば20人日未満の小規模プロジェクトや、エージェントがテストスイートで自動化できる環境には特に有効です。また、所属部署であるTBV（Techbase VietNam）においてもセミナーを開催し、実務での活用可能性を探る取り組みを進めています。
同じような興味を持つ方は、ぜひ続きをご覧ください。
Vibeコーディングとコンテキスト・エンジニアリング
私の週末プロジェクトの一つは、Confluence Data Center用のMCPサーバー（11ツール）を構築することでした。AIコーディング能力を試すにはちょうど良い規模です。
「Vibeコーディング」だった頃
短期間で試行しました。Claudeを開いて、
私:「Claude、Confluence DC用のMCPサーバーを11ツールで作りたい」
Claude:「具体的にその11ツールは何ですか？」
私:「えーと、createPage、getPage...うーん、思い出すね...」
結果は散々：5日経っても11ツール中4ツールしか完成せず、技術的負債だらけ、毎日AIへの説明に何時間も費やし、ストレスは急上昇、信頼感は急落。
「コンテキスト・エンジニアリング」で立て直し
失望しつつも諦めず、再挑戦。今度は急いでコーディングせず、最初の2時間をAIのコンテキスト基盤を構築するドキュメントシステム構築に費やしました：
docs/
├── 00_context/ # AIの長期記憶
│ ├── requirements.md # ビジネス目標、成功基準
│ ├── implementation-guide.md # 技術アーキテクチャ、パターン
│ └── reference.md # 追加参考資料
├── 01_plan/ # プロジェクト管理
│ └── project-roadmap.md # タイムライン、現状、スプリント
└── 02_implement/ # スプリント実行
├── sprint-1.md # タスク詳細
├── sprint-2.md # 日々の進捗
└── sprint-3.md # 受け入れ基準そして新しいセッションはこう始まりました：
私:「MCPサーバープロジェクトを始めます。まずdocs/の全ドキュメントを読んでコンテキストを理解してください」
Claude:「すべて読み、明確に理解しました。project-roadmap.mdによるとSprint 1から開始ですね。implementation-guide.mdに基づき、単一APIクライアントモデルを使います...始めましょうか？」
3日で全11ツールをプロダクション品質で完成しました。このツールは現在、日常業務でのJira・Confluenceタスクの自動化に活用されています。
この魔法の正体はプロセス、Vibeコーダーが忘れがちなものです。
次に、すぐ使えるフレームワークの全内容を紹介します。
コンテキスト・エンジニアリングの3ステップ
諦めないでください。
始め方は意外とシンプル。3ステップです：
ステップ1：AIの長期記憶を構築
全部自分でやらなくてOK！AI自身にコンテキストを作らせましょう。
requirements.mdを作成：AIにプロダクトマネージャー役をさせ、要件をブレスト。詳細な要件を作成します。参考：AIで要件定義を最適化する：曖昧さから詳細へ- 残りのドキュメントを完成：
requirements.mdができたら、インターネット検索AIに渡し、アーキテクチャやコーディングパターンなど技術文書を素早く作成してもらいましょう。
ステップ2：AIのルールを設定
ここでAIに「行動規範」を与えます。プロジェクトにベースルールファイル（CLAUDE.mdやclinerules.md）を作成。
このファイルには、起動ワークフロー（セッション開始時にAIがやるべきこと）、タスクライフサイクル（タスクの流れ）、品質ゲート（完了条件）、ドキュメントルールなどを定義します。AIが混乱したインターンではなく、規律あるエンジニアとして振る舞うための「ハンドブック」です。
ルールセットのイメージ：
CLAUDE.mdやclinerules.mdに貼り付けて使える詳細内容：
### Startup Workflow (Each Session)
1. Check the project setup.
2. **Read `docs/01_plan/project-roadmap.md`** - To understand the project status and current focus.
3. **Reference context documents** - `requirements.md`, `implementation-guide.md` as needed.
### Task Management Process
Task Lifecycle:
1. Identify task: From the current sprint or user request.
2. Focus mode: Work on one task at a time, do not jump around.
3. Implement feature: Code implementation with proper error handling.
4. Test Suite Update: MANDATORY - Update the test suite for every new feature.
5. Quality validation: All tests must PASS before marking a task as complete.
6. Update progress: Update the sprint document only when ALL TESTS PASS.
7. Commit clean: Use a clear commit message following conventions.
8. Update status: Update the sprint document and `project-roadmap.md`.
Quality Gates:
- Code compiles: The build must succeed.
- Test Suite: All automated tests (connection + functional) must PASS.
- No regressions: Existing functionality must not be broken.
- No token leaks: Do not commit sensitive data.
- Documentation: Update docs with test results.
Test Requirements:
- Every new feature requires corresponding tests.
- Tests must PASS before a sprint task can be completed.
- The test suite must be maintained and updated consistently.
### Role of Document Groups
**`00_context/` - Technical Foundation (DO NOT EDIT WITHOUT EXPLICIT APPROVAL)**:
- `requirements.md`: Business requirements, project scope, success criteria.
- `implementation-guide.md`: Technical architecture, code patterns, API client structure.
- `confluence-tools-reference.md`: Complete tool-to-API endpoint mapping reference.
**`01_plan/` - Project Management**:
- `project-roadmap.md`: Project timeline, current status, sprint progress, next actions.
**`02_implement/` - Sprint Execution (UPDATED DAILY)**:
- `sprint-X-*.md`: Detailed task breakdown, acceptance criteria, daily progress tracking.
### Documentation Rules
Update Rules:
project-roadmap.md: Update for major progress, phase completion, current status.
sprint_*.md: Update for daily progress, task completion.
00_context/: Never update without explicit approval (requirements, architecture, API specs).
Maintenance Principles:
- AVOID DUPLICATION: Link instead of repeating information.
- KEEP CONCISE: Overview docs stay short, details go in specific docs.
- SINGLE SOURCE OF TRUTH: Each piece of information lives in one place.
- CROSS-REFERENCE: Use links to connect related information.
- STATUS FIRST: Always show the current status clearly.
Writing Style:
- Concise and actionable.
- Use status indicators: Not Started, In Progress, Completed, Blocked.
- Include time estimates and actual time spent.
- Link related documents instead of duplicating content.
Document Flow: `project-roadmap.md` → `sprint_*.md` → specific details.
Never put detailed task lists in overview documents.ステップ3：ステップ3はありません
あとはエージェントにこう伝えるだけ：
「やるべきことは分かっているよね」
AIがロードマップを読み、次のタスクを特定し、定めたプロセス通りに実装を始めます。
まとめ
以上、3ステップ（実質2ステップ）ですが、効果は絶大です。
このフレームワークは万能ではありません。小規模でテストスイートが明確なプロジェクト、初期コンテキスト構築に時間を割ける場合に特に有効です。
しかし、うまく機能すれば本当に効果的です。
さまざまなサイドプロジェクトで得られた結果は一貫しています：AIが迷子にならず、コード品質は安定し、何よりコントロールを失うストレスがありません。
これこそがVibeコーダーとAIオーケストレーターの違いです。
Vibeコーダーはプロンプトを投げて祈る。AIオーケストレーターはAIが効果的に動けるエコシステムを作る。
前回の投稿から流れに乗るだけのAIコーディングから、規律あるプロセスへと進んできた方は、コンテキスト・エンジニアリングが最後のピースです。理論的なベストプラクティスを、具体的で再現可能なワークフローに変えます。
これで、AIと「流れに乗る」だけでなく、本当に「オーケストレーション」できるツールが揃いました。
社内AIコミュニティやTBVでのセミナーを通じて共有した際の好評を受け、現在このフレームワークをより大規模なプロジェクトに適用できるよう継続的に改善中です。次のサイドプロジェクト、頑張ってください！
