context-engineering-advisor

目的

プロダクトマネージャーが、コンテキスト詰め込み（意図なく大量の情報を押し込むこと）とコンテキストエンジニアリング（注意を引くために構造を整えること）のどちらを行っているかを診断できるようにします。これを使ってコンテキストの境界を特定し、「コンテキスト溜め込み症候群」を解消し、範囲を限定したドメイン、エピソード検索、Research→Plan→Reset→Implement サイクルなどの実践的な手法を導入します。

重要な違い： コンテキスト詰め込みでは、量＝品質と考えます（「PRD 全体を貼り付ける」）。コンテキストエンジニアリングでは、AI の注意力を希少なリソースと捉え、意図的に配分します。

これはプロンプトの作成についてではありません。AI をノイズで圧倒することなく現実に根ざした状態にするための、情報アーキテクチャの設計についてです。

入力

最も効果的な入力： 肥大化している、壊れやすい、または制御しにくいと感じる AI ワークフロー、エージェント、またはプロンプト設定の説明。 ほかにも役立つ情報： すでにコンテキストに詰め込んだもの（ドキュメント、文字起こし、スキーマなど）と、出力がうまくいかない箇所。

呼び出し時に指定された内容、つまりスキル名の後に続くテキスト、貼り付けられたコンテキストダンプ、または追記された ARGUMENTS: 行は、すでに回答済みの情報として扱います。それを活用し、該当する内容については再質問しないでください。

何も用意していなくても大丈夫です。 アドバイザーが、現在モデルに何を入力しているのか、何がうまくいかないのかを尋ねるところから始めます。

呼び出し例： Diagnose my setup: our support-triage agent gets the full 40-page policy manual per ticket and still misroutes edge cases.

重要な概念

パラダイムシフト：パラメトリック知能からコンテキスト知能へ

根本的な問題：

• LLM はパラメトリック知識（トレーニング中に符号化された知識）を持ちます。これは静的で、古く、出典を特定できません。
• 独自データ、リアルタイム情報、またはユーザーの好みについて尋ねられると、ハルシネーションを起こすか、知らないと認めるしかありません。
• コンテキストエンジニアリングは、静的なトレーニングと動的な現実の間のギャップを埋めます。

プロダクトマネージャーの役割の変化： 機能を作る人から、AI を現実に根ざした状態にする情報エコシステムのアーキテクトへ

---

コンテキスト詰め込みとコンテキストエンジニアリング

項目	コンテキスト詰め込み	コンテキストエンジニアリング
考え方	量＝品質	構造＝品質
アプローチ	「念のためすべて追加する」	「どのような判断を下すのか？」
保持	すべてのコンテキストを保持する	意図を持って検索する
エージェントの連鎖	エージェント間ですべて共有する	エージェントごとに境界を設けたコンテキスト
失敗への対応	うまくいくまで再試行する	構造を修正する
経済モデル	コンテキスト＝ストレージ	コンテキスト＝注意力（希少なリソース）

重要なたとえ： コンテキスト詰め込みは、会議にファイルキャビネット全体を持ち込むようなものです。コンテキストエンジニアリングでは、今日の判断に関係する 3 つの書類だけを持ち込みます。

---

アンチパターン：コンテキスト詰め込み

コンテキスト詰め込みを示す 5 つの兆候：

1. 反射的にコンテキストウィンドウを拡大する — 「トークンをもっと追加しよう！」
2. 「念のため」すべてを保持する — 明確な保持基準がない
3. 境界を設けずにエージェントを連鎖させる — エージェント A がすべてをエージェント B に渡し、さらにエージェント C に渡す
4. 一貫性のなさを隠すために評価を追加する — 「正しくなるまで再試行すればいい」
5. 再試行が常態化する — 「3 回実行すれば動く」が許容されるようになる

失敗する理由：

• 推論ノイズ： 何千もの無関係なファイルが注意を奪い合い、複数段階の推論の質を低下させます。
• コンテキストの劣化： 行き止まり、過去のエラー、無関係なデータが蓄積し、目標がずれていきます。
• 途中で見失う： モデルは冒頭（初頭効果）と末尾（新近性効果）を優先し、中間を無視します。
• 経済的な浪費： 精度が向上しないまま、すべてのクエリが高コストになります。
• 定量的な劣化： コンテキストが約 32k トークンを超えると、精度は 20% 未満に低下します。

隠れたコスト：

• トークン消費の増加
• 無関係な情報に注意が分散する
• 出力への信頼度が低下する
• 時間と費用を浪費する連鎖的な再試行

---

実践的なコンテキストエンジニアリング：基本原則

5つの基本原則：

1. 形のないコンテキストはノイズになる
2. 構造 ＞ 量
3. 網羅性ではなく、意図を持って検索する
4. 小さく機能するコンテキスト（短期記憶のようなもの）
5. コンテキストの圧縮： トークンあたりの関連情報の密度を最大化する

定量的なフレームワーク：

Efficiency = (Accuracy × Coherence) / (Tokens × Latency)

主な発見： RAG を利用すると、利用可能なトークンの 25% で精度の 95% を維持しながら、レイテンシとコストを大幅に削減できます。

---

5つの診断質問（コンテキスト溜め込み症候群の検出）

コンテキストの詰め込みを特定するには、次の質問をしてください。

1. これは具体的にどのような判断を支援しますか？ — 答えられないなら、必要ありません
2. 保持する代わりに検索で対応できますか？ — 必要なときに取得するほうが、常に利用可能にしておくより優れています
3. コンテキストの境界を誰が管理していますか？ — 誰もいないなら、際限なく増え続けます
4. これを除外すると何が失敗しますか？ — 何も壊れないなら、削除してください
5. 構造を改善していますか、それとも構造化を避けていますか？ — コンテキストの詰め込みは、情報アーキテクチャの不備を覆い隠すことがよくあります

---

メモリアーキテクチャ：2層システム

短期（会話）メモリ：

• 続く質問に対応するための、直近のやり取りの履歴
• 課題：容量管理 → 古い部分は要約または切り詰められます
• 寿命：単一のセッション

長期（永続）メモリ：

• ユーザーの好み、セッションをまたいで保持される重要な事実 → 高度なパーソナライズ
• ベクトルデータベース（セマンティック検索）を使って実装します
• 2つの種類：
  • 宣言的メモリ： 事実（「私はヴィーガンです」）
  • 手続き的メモリ： 行動パターン（「私はまずログを確認してデバッグします」）
• 寿命：セッションをまたいで永続

LLM を活用した ETL： モデルがシグナルを特定し、既存のデータと統合して、データベースを自動更新することで、自身のメモリを生成します。

---

調査 → 計画 → リセット → 実装のサイクル

コンテキスト劣化の解決策：

1. 調査： エージェントがデータを収集 → 大きく混沌としたコンテキストウィンドウ（ノイズと行き止まり）
2. 計画： エージェントが高密度の SPEC.md または PLAN.md（信頼できる唯一の情報源）にまとめます
3. リセット： コンテキストウィンドウ全体をクリア（コンテキスト劣化を防ぎます）
4. 実装： 高密度の計画のみをコンテキストとして使用する、新しいセッション

これが機能する理由： コンテキスト劣化がなくなり、エージェントは圧縮され、シグナル密度の高いコンテキストでクリーンな状態から開始できます。

---

アンチパターン（これは何ではないか）

• AI ツールの選択に関するものではありません — Claude か ChatGPT かは重要ではありません。重要なのはアーキテクチャです
• より良いプロンプトを書くことに関するものではありません — これはシステム設計であり、コピーライティングではありません
• トークンを増やすことに関するものではありません — 「無限のコンテキスト」という説明はマーケティングであり、エンジニアリング上の現実ではありません
• 人間の判断を置き換えることに関するものではありません — コンテキストエンジニアリングは判断力を増幅させますが、排除するものではありません

---

このスキルを使うタイミング

✅ 次の場合に使ってください：

• PRD やコードベース全体を AI に貼り付けても、曖昧な回答しか得られない
• AI の出力に一貫性がない（「うまくいくときもあれば、そうでないときもある」）
• 精度が向上しないままトークンを消費している
• 「コンテキストを詰め込みすぎている」と思うものの、修正方法がわからない
• AI 製品の機能向けにコンテキストアーキテクチャを設計する必要がある

❌ 次の場合は使わないでください：

• AI を使い始めたばかり（まずは基本的なプロンプトから始めてください）
• ツールの推奨を探している（これはツールではなく、アーキテクチャに関するものです）
• AI の使い方がうまくいっている（問題がなければ、直す必要はありません）

---

ファシリテーションの基本方針

このスキルのデフォルトの対話プロトコルとして、workshop-facilitation を使用してください。

以下を定義しています。

• セッション開始時の案内と開始モード（ガイド付き、コンテキストの一括提示、最善の推測）
• 平易な表現による、各ターン1つの質問
• 進捗ラベル（例：コンテキスト Qx/8、スコアリング Qx/5）
• 割り込みへの対応と一時停止・再開の動作
• 意思決定のタイミングでの番号付き提案
• 通常の質問に対する、番号付きの選択肢（必要に応じて Other (specify) を含める）

このファイルでは、評価に固有の内容を定義しています。競合がある場合は、このファイルのドメインロジックに従ってください。

適用

この対話型スキルでは、適応型の質問を用いて、コンテキストの詰め込みを診断し、境界を特定し、実践的な実装ガイダンスを提供します。

---

ステップ 0：コンテキストを収集する

エージェントが質問します：

コンテキストの使い方を診断する前に、まず状況を把握しましょう。

現在の AI の利用状況：

• どのような AI ツール／システムを使っていますか？（ChatGPT、Claude、カスタムエージェントなど）
• どのような PM タスクに AI を使っていますか？（PRD の作成、ユーザー調査の統合、ディスカバリーなど）
• どのようにコンテキストを提供していますか？（ドキュメントの貼り付け、ファイルの参照、プロジェクト／メモリーの利用）

症状：

• AI の出力に一貫性がありませんか？（うまくいくこともあれば、そうでないこともある）
• 良い結果を得るために、プロンプトを何度もやり直していますか？
• 「すべてのコンテキスト」を提供しているのに、回答が曖昧だったり、断定を避けたりしますか？
• 正確性が向上しないまま、トークンコストが増加していますか？

システムアーキテクチャ（該当する場合）：

• カスタム AI エージェントやワークフローを使っていますか？
• エージェント間でコンテキストをどのように共有していますか？
• RAG、ベクトルデータベース、メモリーシステムを使っていますか？

簡単に説明するか、例を貼り付けてください。

---

ステップ 1：コンテキストの詰め込み症状を診断する

エージェントが質問します：

コンテキストの詰め込みが起きているか確認しましょう。次のうち、当てはまる症状はどれですか？

該当するものをすべて選択してください：

1. 「ドキュメント全体を AI に貼り付ける」 — PRD 全文、ユーザーインタビューの完全な記録、コードベース全体
2. 「『すべてのコンテキスト』を与えているのに、AI の回答が曖昧で断定を避ける」 — 「場合によります」「次の選択肢を検討してください」など、歯切れの悪い回答
3. 「使える出力を得るために、プロンプトを3回以上やり直す必要がある」 — 一貫性のなさが当たり前になっている
4. 「正確性が向上しないのに、トークンコストが増加している」 — 支出が増えても、結果は同じか、むしろ悪化している
5. 「役に立つことを期待して、コンテキストを追加し続ける」 — 方針なく反射的に拡張している
6. 「エージェント同士であらゆる情報を渡し合っている」 — エージェント A → エージェント B → エージェント C と、コンテキストをすべて引き継いでいる
7. 「何を含める／除外するかの明確な基準がない」 — コンテキストの境界が定義されていない
8. 「どれも当てはまらない。AI はうまく使えている」 — 高度な最適化に進む

ユーザーの回答： [症状を選択]

エージェントが分析します：

選択内容に基づく評価：

• 症状0～1個： コンテキストの使い方は健全です。最適化に進みます
• 症状2～3個： コンテキストの詰め込みが初期段階で見られます。拡大する前に対処してください
• 症状4個以上： コンテキスト蓄積障害が進行中です。直ちに介入が必要です

エージェントは診断の質問に進みます。

---

ステップ 2：診断質問 1 — これはどのような具体的な意思決定を支援しますか？

エージェントが質問します：

まず、最も重要な質問から始めましょう。含めようとしている各コンテキストは、どのような具体的な意思決定を支援しますか？

コンテキスト分析の例：

AI に「ディスカバリー計画を支援して」と頼む場面を想像してください。次の情報を提供します。

• PRD 全体（20 ページ）
• ユーザーインタビューの記録 50 件（全文）
• 競合分析ドキュメント（15 ページ）
• 過去 3 か月分のチームミーティング議事録

質問： 今、どのような意思決定をしようとしていますか？

3 つのシナリオを提示します：

1. 「最初にインタビューするユーザーセグメントを決めている」

   • 必要なコンテキスト： PRD に記載されたユーザーセグメント（2 段落）、過去のインタビューのテーマ（1 ページの要約）。記録の全文は不要です
   • 不要なコンテキスト： ミーティング議事録、競合分析の全文、PRD 全体

2. 「インタビューで何を質問するかを決めている」

   • 必要なコンテキスト： 調査目標（PRD より）、過去のインタビューから得られた知見（要約）、Jobs-to-be-Done フレームワーク
   • 不要なコンテキスト： 競合分析の全文、ミーティング議事録の全文

3. 「どのような意思決定をしようとしているのか分からない。ただ AI に『自分の製品を理解してほしい』だけ」

   • 問題： 具体的な意思決定がないと、コンテキストを詰め込みすぎる罠に陥ります
   • 解決策： まず意思決定の内容を定義し、そのうえでコンテキストを選びます

エージェントの推奨：

ベストプラクティス： コンテキストを追加する前に、次の文を完成させてください。

「このコンテキストが必要なのは、［具体的な意思決定］をしようとしていて、［具体的な情報］がなければその意思決定ができないためです。」

この文を完成できない場合、そのコンテキストは必要ありません。

ユーザーの回答： ［意思決定とコンテキストを説明してください］

エージェントが検証します： そのコンテキストは、明示された意思決定を直接支援していますか？ そうでない場合は、削減を提案します。

---

ステップ 3：診断質問 2 — 永続化する代わりに検索できますか？

エージェントが質問します：

2 つ目の質問です。この情報は常に必要ですか？ それとも必要なときに取得できますか？

違い：

常に必要（永続化）：

• 製品の中核となる制約（技術、規制、戦略）
• あらゆるやり取りに適用されるユーザーの設定
• 重要な定義（運用用語集）
• 妥協できないルール

一時的に必要（オンデマンドで取得）：

• プロジェクト固有の詳細（このエピック、このスプリント）
• 履歴データ（過去の PRD、以前のインタビュー記録）
• 状況に応じた事実（競合分析、市場調査）
• 一時的な意思決定

重要なポイント： 必要なときに取得するほうが、常に参照できる状態にしておくより効果的です。取得できる情報は永続化しないでください。

3 つの選択肢を提示します：

1. 「コンテキストの大半は常に必要なもの（中核となる制約、ユーザー設定）です」

   • 評価： 良い判断です。質問 4（除外すると何が失敗するか？）で確認してください
   • 推奨： 制約レジストリと運用用語集を作成し、これらを永続化します

2. 「コンテキストの大半は一時的に必要なもの（プロジェクトの詳細、履歴データ）です」

   • 評価： RAG や検索に最適です
   • 推奨： セマンティック検索を導入し、各クエリに関連するチャンクだけを取得します

3. 「どれがどちらか分からないので、安全のためにすべて永続化しています」

   • 評価： コンテキストため込み症候群によく見られる症状です
   • 解決策： 各コンテキストに質問 4 のテストを適用します

エージェントの推奨：

経験則：

• 永続化： やり取りの 80% 以上で参照される情報
• 取得： やり取りの 20% 未満で参照される情報
• グレーゾーン（20～80%）： 検索のレイテンシとコンテキストウィンドウのコストを比較して判断します

ユーザーの回答： ［コンテキストを分類してください］

エージェントが提示します： 何を永続化し、何を取得するかについての具体的な推奨事項。

---

ステップ 4：診断質問 3 — コンテキストの境界を管理するのは誰ですか？

エージェントが尋ねる内容：

3 つ目の質問：AI のコンテキストに何を含め、何を除外するかを定義する責任者は誰ですか？

管理責任の問題：

コンテキストの境界を管理する人が誰もいない場合、境界は際限なく広がります。各 PM が「あと 1 つだけ」と追加し続け、半年後にはクエリごとに 100k トークンを詰め込むことになります。

次の 3 つの選択肢を提示します：

1. 「私が境界を管理する（PM が 1 人、または小規模チーム）」

   • 評価： 良い状態です。迅速に判断できます。
   • 推奨事項： 境界の基準を文書化します（質問 1～5 をフレームワークとして使用します）。

2. 「チームで共同管理する（境界の定義を共同で行う）」

   • 評価： ルールを明文化すれば機能します。
   • 推奨事項： 「コンテキストマニフェスト」文書を作成します。常に含めるもの、取得するもの、除外するもの（およびその理由）を記載します。

3. 「管理する人はいない。場当たり的／暗黙的に決まっている」

   • 評価： 重大なリスクです。境界が制御不能に広がります。
   • 解決策： 明確な管理責任者を任命し、四半期ごとのコンテキスト監査を予定に入れます。

エージェントの推奨事項：

ベストプラクティス：コンテキストマニフェストを作成する

# Context Manifest: [Product/Feature Name]

## Always Persisted (Core Context)
- Product constraints (technical, regulatory)
- User preferences (role, permissions, preferences)
- Operational glossary (20 key terms)

## Retrieved On-Demand (Episodic Context)
- Historical PRDs (retrieve via semantic search)
- User interview transcripts (retrieve relevant quotes)
- Competitive analysis (retrieve when explicitly needed)

## Excluded (Out of Scope)
- Meeting notes older than 30 days (no longer relevant)
- Full codebase (use code search instead)
- Marketing materials (not decision-relevant)

## Boundary Owner: [Name]
## Last Reviewed: [Date]
## Next Review: [Date + 90 days]

ユーザーの回答： [現在の管理体制を説明してください]

エージェントが提供する内容： 管理体制を明確にするための推奨事項と、コンテキストマニフェストのテンプレート。

---

ステップ 5：診断質問 4 — これを除外すると何が失敗しますか？

エージェントが尋ねる内容：

4 つ目の質問：コンテキストの各要素について、それを除外した場合にどのような具体的な失敗が起こりますか？

これは反証テストです。具体的な失敗を特定できないなら、そのコンテキストは必要ありません。

次の 3 つのシナリオを提示します：

1. 「製品の制約を除外すると、AI が実現不可能な解決策を提案します」

   • 失敗モード： 明確かつ具体的です。
   • 評価： 制約を保持する正当な理由になります。

2. 「過去の PRD を除外すると、AI が製品の進化を理解できなくなります」

   • 失敗モード： 曖昧で仮定に基づいています。
   • 評価： 現在の意思決定に過去のコンテキストが必要になることは、ほとんどありません。
   • 解決策： 過去の意思決定に明示的に言及する場合にのみ、PRD を取得します。

3. 「これを除外しても何か問題が起きるか分かりません。念のため含めているだけです」

   • 失敗モード： 特定されていません。
   • 評価： コンテキストの詰め込みです。すぐに削除してください。

エージェントの推奨事項：

反証プロトコル：

コンテキストの各要素について、次の文を完成させます：

「[コンテキスト要素] を除外すると、[具体的なシナリオ] で [具体的な失敗] が発生します。」

例：

• ✅ 良い例：「GDPR の制約を除外すると、AI が EU のプライバシー法に違反する機能を提案します。」
• ❌ 悪い例：「この PRD を除外すると、AI が製品を十分に理解できないかもしれません。」（曖昧）

ユーザーの回答： [自分のコンテキストに反証テストを適用してください]

エージェントが提供する内容： 具体的な失敗が特定されなかったため、削除すべきコンテキスト要素の一覧。

---

Step 6: 診断の質問 5 — 構造を修正していますか、それとも問題を避けていますか？

エージェントが質問します：

5つ目の質問：コンテキストを追加することで問題を解決していますか、それともより根深い構造上の問題を覆い隠していますか？

根本原因についての質問：

コンテキストを詰め込むことで、情報アーキテクチャの不備が見えにくくなることがよくあります。まとまりのない曖昧なドキュメントを修正する代わりに、AI が「何とか理解する」ことを期待して、チームがドキュメントを追加してしまうのです。

次の 3 つの選択肢を提示します：

1. 「ドキュメントの構成が不十分、または曖昧なため、コンテキストを追加しています」

   • 評価： 構造上の問題を覆い隠しています
   • 対処： まずドキュメントを整理します（曖昧さをなくし、制約を追加し、用語を定義します）
   • 例： 矛盾する PRD を 5 つ貼り付ける代わりに、内容を調整して 1 つの信頼できる情報源にまとめます

2. 「共通の運用用語集がないため、コンテキストを追加しています」

   • 評価： 基盤の不足を補っています
   • 対処： 用語集を作成します（重要な用語を 20～30 個）。AI が確実に参照できるようになります
   • 例： 「アクティブユーザー」「チャーン」「エンゲージメント」を曖昧さのない形で定義します

3. 「制約が文書化されていないため、コンテキストを追加しています」

   • 評価： 制約の設計を避けています
   • 対処： 制約レジストリを作成します（技術、規制、戦略に関する制約）
   • 例： すべてのプロンプトで説明する代わりに、「モバイルアプリは開発しない」と文書化します

エージェントの推奨事項：

構造健全性テスト：

次の不足を補うためにコンテキストを追加している場合：

• 曖昧なドキュメント → ドキュメントを修正し、追加しないでください
• 未定義の用語 → 運用用語集を作成します
• 文書化されていない制約 → 制約レジストリを作成します
• 矛盾する情報 → 信頼できる情報源にまとめます

ユーザーの回答： [構造上の問題を特定]

エージェントが提供するもの： コンテキストをさらに追加する前に対応すべき、優先順位付きの構造上の修正リスト。

---

Step 7: メモリアーキテクチャを定義する

エージェントが質問します：

コンテキストのニーズに基づいて、2 層のメモリアーキテクチャを設計しましょう。

コンテキストプロファイル（前のステップに基づく）：

• 常に必要なコンテキスト：[Q2 の要約]
• エピソードコンテキスト：[Q2 の要約]
• 境界の管理者：[Q3 に基づく]
• 検証済みの必須情報：[Q4 に基づく]
• 必要な構造上の修正：[Q5 に基づく]

推奨アーキテクチャ：

短期（会話）メモリ：

• 保存する内容： 追加の質問に対応するための、直近のやり取りの履歴
• 有効期間： 1 回のセッション
• 管理方法： コンテキストが過密になるのを避けるため、古い部分を要約するか切り詰めます
• 具体的なニーズ： [ユーザーのワークフローに基づいてエージェントが調整]

長期（永続）メモリ：

• 保存する内容： ユーザーの好み、中核となる制約、運用用語集
• 有効期間： セッションをまたいで永続
• 実装： ベクトルデータベース（意味検索）
• 2 つの種類：
  • 宣言的メモリ： 事実（例：「当社は HIPAA 規制に準拠しています」）
  • 手続き的メモリ： 行動パターン（例：「ユーザビリティを検証する前に、必ず実現可能性を検証します」）
• 具体的なニーズ： [エージェントが調整]

検索戦略（エピソードコンテキスト）：

• 検索する内容： 過去の PRD、ユーザーインタビュー、競合分析
• 方法： クエリの意図に応じて実行する意味検索
• 最適化： Contextual Retrieval（Anthropic）— 埋め込みの前に、各チャンクへ説明的なコンテキストを追加します
• 具体的なニーズ： [エージェントが調整]

エージェントが提示します：

次のいずれかをご希望ですか？

1. ご利用のケースに合わせたコンテキストアーキテクチャの設計書を作成する
2. 実装のガイダンスを提供する（ツール、手法、ベストプラクティス）
3. エピソードコンテキストの検索戦略を設計する

ユーザーの回答： [選択]

---

Step 8: 調査 → 計画 → リセット → 実装のサイクルを導入する

エージェントの質問:

コンテキストの劣化を防ぐため、調査 → 計画 → リセット → 実装のサイクルを導入しましょう。

問題点： エージェントが調査を進めると、コンテキストウィンドウは収拾がつかなくなります。行き止まりやエラー、ノイズで埋め尽くされ、注意が散漫になり、目標から逸れてしまいます。

解決策： 調査内容を高密度な計画にまとめてから、実装の前にコンテキストウィンドウをクリアします。

4段階のサイクル：

フェーズ 1：調査（混乱したコンテキストを許容）

• エージェントが複数の情報源からデータを収集します
• コンテキストウィンドウは大きくなり、雑然とします（想定どおりです）
• 行き止まりや失敗した仮説、ノイズが蓄積します
• 目標： 情報を包括的に収集する

フェーズ 2：計画（統合）

• エージェントが調査内容を統合し、高密度な SPEC.md または PLAN.md にまとめます
• これが実装における唯一の信頼できる情報源になります
• 重要な要素：
  • 下した決定
  • 決定を裏付ける根拠
  • 適用した制約
  • 次の手順（順序付き）
• 形式： 構造化され、簡潔で、曖昧さがないこと

フェーズ 3：リセット（コンテキストウィンドウをクリア）

• 重要な手順： コンテキストウィンドウ全体をクリアします
• 調査の成果物、行き止まり、エラーをすべて削除します
• これにより、コンテキストの劣化が実装に悪影響を及ぼすのを防ぎます

フェーズ 4：実装（計画だけを使った新しいセッション）

• 高密度な計画だけをコンテキストとして、新しいセッションを開始します
• エージェントは実行に集中できる、クリーンな状態になります
• 調査フェーズのノイズはありません

エージェントが提示する 3 つの選択肢：

1. 「PLAN.md 形式のテンプレートがほしいです」

   • エージェントが高密度な計画の構造化テンプレートを提示します

2. 「このサイクルの実例を見たいです」

   • エージェントが PM の具体的なユースケース（例：ディスカバリー計画）を順に説明します

3. 「自分のワークフローに導入する準備ができています」

   • エージェントが段階的な導入ガイドを提示します

ユーザーの回答： ［選択］

エージェントの提示内容： 選択に応じたガイダンス。

---

Step 9: アクションプランと次のステップ

エージェントがまとめます：

コンテキストエンジニアリングの評価に基づくアクションプランは次のとおりです。

すぐに行う改善（今週）：

1. ［質問 4 の、反証可能な失敗条件がないコンテキストを削除する］
2. ［次の AI タスクで「調査 → 計画 → リセット → 実装」を適用する］
3. ［Context Manifest にコンテキスト境界を記録する］

基盤の構築（今後 2 週間）：

1. ［20 項目以上の制約レジストリを作成する］
2. ［重要な用語を 20～30 語含む運用用語集を作成する］
3. ［2 層のメモリアーキテクチャを導入する］

長期的な最適化（来月）：

1. ［エピソードコンテキストにセマンティック検索を設定する］
2. ［コンテキスト境界の担当者を決め、四半期ごとの監査スケジュールを設定する］
3. ［RAG に Contextual Retrieval（Anthropic）を導入する］

成功指標：

• トークン使用量が 50％以上減少（コンテキストの詰め込みを削減）
• 出力の一貫性が向上（再試行・再生成を削減）
• 回答の品質が向上（より的確で、曖昧さの少ない回答）
• コンテキストウィンドウが安定（際限なく増加しない）

エージェントからの提案：

次のことを行いましょうか？

1. 具体的な導入ドキュメントを作成する（Context Manifest、PLAN.md テンプレートなど）
2. 高度な手法を紹介する（Contextual Retrieval、LLM を活用した ETL）
3. 現在のコンテキスト設定をレビューする（具体的なプロンプトやワークフローへのフィードバック）

---

例

例 1：一人でのコンテキスト詰め込み → エンジニアリング

状況：

• 創業初期のスタートアップで一人で働く PM
• Claude Projects を使って PRD を作成
• PRD 全体（20 ページ）とすべてのユーザーインタビュー（50 件のトランスクリプト）を毎回貼り付けている
• 曖昧で一貫性のない回答が返ってくる

評価：

• 症状：断定を避けた回答、リトライが常態化（4 つ以上の症状）
• Q1（意思決定）：「AI に自分のプロダクトを理解してほしいだけ」（具体的な意思決定がない）
• Q2（永続化／取得）：すべてを永続化している（取得戦略がない）
• Q3（オーナーシップ）：正式な担当者がいない（一人の PM、場当たり的）
• Q4（失敗）：大半のコンテキストについて具体的な失敗を特定できない
• Q5（構造）：制約の文書化を避けている

診断： アクティブコンテキストため込み症候群

介入：

1. 直ちに： Q4 テストに通らないコンテキストをすべて削除 → 元の 20% を保持
2. 第 1 週： 制約レジストリを作成（技術的制約 10 件、戦略的制約 5 件）
3. 第 2 週： 運用用語集を作成（25 語）
4. 第 3 週： 次の PRD に向けて Research→Plan→Reset→Implement を導入

結果： トークン使用量が 70% 減少し、出力品質が大幅に向上し、回答が明快で実行可能になりました。

---

例 2：エージェントチェーンを使う成長段階のチーム

状況：

• PM 5 人のプロダクトチーム
• ディスカバリーの統合にカスタム AI エージェントを使用
• エージェント A（調査）→ エージェント B（統合）→ エージェント C（提案）
• 各エージェントが完全なコンテキストを次のエージェントに渡すため、コンテキストウィンドウが 100k トークンを超えて膨張

評価：

• 症状：トークンコストの増加、出力の不一致（3 つの症状）
• Q1（意思決定）：各エージェントの意思決定は明確だが、不要なコンテキストを渡している
• Q2（永続化／取得）：戦略なしに永続的な情報とエピソード的な情報を混在させている
• Q3（オーナーシップ）：明確な担当者がいない。各 PM がコンテキストを追加している
• Q4（失敗）：反証可能な失敗もないのに、エージェントが「念のため」のコンテキストを渡している
• Q5（構造）：コンテキストマニフェストがない

診断： 境界のないエージェントオーケストレーション

介入：

1. 直ちに： エージェントごとに境界付きコンテキストを定義（エージェント A は調査全体ではなく、2 ページの統合結果のみをエージェント B に出力）
2. 第 1 週： コンテキスト境界の担当者を任命（リード PM）
3. 第 2 週： コンテキストマニフェストを作成（永続化するもの、取得するもの、除外するもの）
4. 第 3 週： エージェント B とエージェント C の間に Research→Plan→Reset→Implement を導入

結果： トークン使用量が 60% 減少し、エージェントチェーンの信頼性が向上し、コストが 50% 削減されました。

---

例 3：RAG は導入済みだが、コンテキストエンジニアリングがないエンタープライズ

状況：

• ベクトルデータベースを使った RAG システムを導入している大企業
• 「ナレッジベース全体を詰め込む」方式（10,000 件以上の文書）
• 取得処理でクエリごとに 50 件以上のチャンクが返り、コンテキストウィンドウがあふれる
• ナレッジベースの拡大に伴い、精度が低下している

評価：

• 症状：「完全な知識」があるにもかかわらず回答が曖昧、リトライが常態化（2 つの症状）
• Q1（意思決定）：意思決定は明確だが、取得に意図がない（すべてを返す）
• Q2（永続化／取得）：取得するという判断は適切だが、フィルタリングがない
• Q3（オーナーシップ）：エンジニアリングが RAG を担当し、プロダクトチームはコンテキスト境界を管理していない
• Q4（失敗）：50 件のチャンクが必要で 5 件では足りない理由を特定できない
• Q5（構造）：ナレッジベースに構造がない（フラットな文書でメタデータもない）

診断： 意図のない取得（コンテキスト詰め込みとしての RAG）

介入：

1. 直ちに： クエリごとの取得数を上位 5 件に制限（50 件から削減）
2. 第 1 週： コンテキスト取得（Anthropic）を導入 — インデックス作成時に各チャンクへ説明用コンテキストを前置
3. 第 2 週： 文書にメタデータを追加（カテゴリ、鮮度、信頼性）
4. 第 3 週： プロダクトチームがクエリの種類ごとに取得の意図を定義（ディスカバリー＝顧客インサイト、実現可能性＝技術的制約）

結果： 精度が 35% 向上（Anthropic のベンチマークに基づく）、レイテンシが 60% 低下し、トークン使用量が 80% 減少しました。

---

よくある落とし穴

1. 「無限のコンテキスト」というマーケティングとエンジニアリングの現実

失敗パターン：「100万トークンのコンテキストウィンドウ」があるからといって、すべて使うべきだと思い込むことです。

**結果：**推論ノイズによってパフォーマンスが低下し、約32kトークンを超えると精度が20％未満に落ちます。

**対策：**コンテキストウィンドウは無料ではありません。トークンは限りあるものとして扱い、量ではなく密度を最適化してください。

---

2. 構造を見直さずに再試行する

失敗パターン：「3回実行すればうまくいく」ことで、構造を修正せず再試行を常態化させることです。

**結果：**時間と費用を浪費し、より根深いコンテキストの劣化を覆い隠します。

**対策：**再試行が頻繁に必要なら、コンテキスト構造に問題があります。Q5（量を増やさず、構造を修正する）を適用してください。

---

3. コンテキスト境界の責任者がいない

**失敗パターン：**場当たり的で暗黙のコンテキスト判断によって、コンテキストが際限なく増えていくことです。

**結果：**半年後には、どのクエリでもやり取りごとに100kトークンを詰め込むようになります。

**対策：**責任者を明確に割り当て、コンテキストマニフェストを作成し、四半期ごとの監査を予定してください。

---

4. 常に必要な情報と一時的な情報を混在させる

**失敗パターン：**必要に応じて取得すべき履歴データを永続化することです。

**結果：**コンテキストウィンドウが無関係な情報で埋まり、注意が分散します。

**対策：**Q2 のテストを適用してください。80％以上のやり取りで必要な情報だけを永続化し、残りは必要に応じて取得します。

---

5. リセットフェーズを省略する

**失敗パターン：**調査→計画→実装のサイクルで、コンテキストウィンドウを一度もクリアしないことです。

**結果：**コンテキストの劣化が蓄積し、目標が逸れ、行き詰まりが実装に悪影響を及ぼします。

**対策：**計画の後に必ずリセットフェーズを設けてください。密度の高い計画だけをコンテキストとして、実装を開始します。

---

参考資料

関連スキル

• ai-shaped-readiness-advisor（インタラクティブ）— コンテキスト設計は、AI 時代の働き方に必要な能力の第1項目です
• problem-statement（コンポーネント）— 根拠に基づく問題の定義には、コンテキストエンジニアリングが必要です
• epic-hypothesis（コンポーネント）— 検証可能な仮説は、明確な制約（コンテキストの一部）に依存します
• pol-probe-advisor（インタラクティブ）— 検証実験には、コンテキストエンジニアリング（AI が知るべきことの定義）が役立ちます

外部フレームワーク

• Dean Peters — Context Stuffing Is Not Context Engineering（Dean Peters の Substack、2026年）
• Teresa Torres — Continuous Discovery Habits（コンテキストエンジニアリングは、AI 時代の新しい PM の5つの専門分野の1つです）
• Marty Cagan — Empowered（AI 時代の実現可能性リスクには、「AI の物理法則」の理解が含まれます）
• Anthropic — Contextual Retrieval whitepaper（失敗率を35％削減）
• Google — LLM を活用したメモリシステムに関するコンテキストエンジニアリングのホワイトペーパー

技術資料

• RAG（検索拡張生成） — 一時的なコンテキストを取得するための標準的な手法です
• ベクトルデータベース — 長期記憶のためのセマンティック検索（Pinecone、Weaviate、Chroma）
• Contextual Retrieval（Anthropic） — 埋め込みの前に、チャンクへ説明用コンテキストを付与します
• LLM-as-Judge — コンテキスト品質の自動評価