誰もがより良いプロンプトを書けるようになっています。ですが、より良いコンテキストを構築できている人は多くありません。
そこにギャップがあります。プロンプトエンジニアリングはAIを検索ボックスのように扱います――完璧なクエリを作れば、完璧な答えが返ってくる。コンテキストエンジニアリングはAIを新しいチームメンバーのように扱います――適切なドキュメント、適切なアクセス、そして実際に仕事がどう進むのかを理解させるのです。アンドレイ・カラパティ が言うように、最もホットな新しいプログラミング言語は英語です――しかしプログラムではない。プログラムを取り囲むコンテキストこそが本体です。
私はこの6か月、Presidioで、AIネイティブなワークフローを構築してきました。そこで私はPrincipal Solutions Architectです。チャットボットでもありません。デモでもありません。Claude Codeのエージェントが実際のプリセールス業務を回す、本番システムです――クライアント調査、提案作成、会議の分析、案件の追跡。以前はそれが、誰かの頭の中と、何十ものブラウザタブに収まっていたような仕事です。
AIを本当に役立つものにするために、私が学んだことはこちらです。
Prompts Are Requests. Skills Are Frameworks.
まず全員が犯す最初の間違い：ドメイン知識をプロンプトに詰め込みすぎることです。「あなたはエンタープライズ営業の専門家です。案件を分析するときは、次の47の要因を考慮してください…」
これはすぐに破綻します。プロンプトは一時的です――会話が終われば消えてしまう。ドメイン知識はセッションをまたいで持続する必要があり、バージョン管理され、何がうまくいくかを学ぶにつれて進化しなければなりません。
うまくいくパターンは：スキルファイル――Claude Codeのプラグインアーキテクチャが、再利用可能なドメイン知識と呼ぶものです。指示ではなく、意思決定のためのフレームワークをエンコードしたMarkdownドキュメント。スキルは「この案件を分析して」ではありません。スキルとは、あなたのチームが実際に使っている5つのゲートによる適格性（クオリフィケーション）フレームワークで、意思決定基準、レッドフラグ、終了条件といった要素を含む構造化Markdownとして書かれています。AIはそれを読み、適用します。フレームワークは一度更新すれば、以後のすべてのセッションで新しいバージョンが使われます。
.claude/skills/
├── qualification-framework.md # 判断のためのゲート（基準付き）
├── pricing-strategy.md # マージンのルール、割引の権限
├── sow-review-rubric.md # 評価チェックリスト
└── competitive-positioning.md # 競合ごとの差別化ポイント
スキルは再利用できます。プロンプトは使い捨てです。この違いは、どんなプロンプト技法よりも重要です。
Context-as-Code: Version Control Your AI's Brain
私のシステムでは、クライアントとのあらゆる契約対応（エンゲージメント）に、アカウントごとに1つのMarkdownファイルがあります。これは、そのアカウントにおけるAIの作業用メモリ（ワーキングメモリ）です。連絡先、スコープの判断、会議履歴、アクションアイテム、競合インテリジェンス――1ファイルで、gitでバージョン管理します。
なぜMarkdownなのか？3つの理由：
-
grepで検索できる。 エージェントが、すべてのアカウントにまたがって特定のテクノロジーに言及している箇所を見つける必要があるとき、
grep -r "Kubernetes" clients/が即座に効きます。これをベクトルデータベースでやってみてください。 - 差分がきれいに出る。 gitは、AIがそのアカウントを理解する上で何が変わったのかを正確に示します。誰がいつ更新したのか、なぜそうしたのか。
- トークン効率が高い。 構造化Markdownはコンテキストウィンドウでうまく圧縮されます。200行のコンテキストファイルがあれば、RAGの取得レイテンシなしで、そのアカウントを扱うのに必要なものがエージェントに揃います。
アンチパターンは、AIのメモリをブラックボックスとして扱うことです――検査できない埋め込み、差分比較できないベクトルストア、バージョン管理できないコンテキスト。あなたがAIの知識をgit blameできないなら、それをコントロールできていないということです。
One God-Agent Is a Trap
私は最初、何でもできる1つのエージェントで始めました。すべてにおいて、それは中途半端でした。
解決策はドメインの専門化です。4つのエージェントに分け、それぞれ明確な役割を持たせました。1つはディスカバリーと適格性確認を担当し、1つは技術設計と提案作成を担当し、1つは案件運用と価格設定を担当し、1つはワークスペースのメンテナンスを担当します。各エージェントには独自のツール、独自のコンテキスト、そして別のエージェントに作業を渡すための明確な引き継ぎ（ハンドオフ）プロトコルがあります。
これは実際のチームの動き方をそのまま真似ています。営業エンジニアは契約書の赤入れ（レッドライン）をしません。ディールデスクはアーキテクチャを設計しません。専門化は単なる精度のためだけではありません――それはコストのためでもあります。同じファイルのクリーンアップを行うのに、Haikuで動くメンテナンスエージェントはOpusエージェントより95%安く済みます。
AIで最も簡単に節約できるのは、タスクの複雑さに応じたモデルルーティングです：
| タスクの種類 | モデル | 理由 |
|---|---|---|
| ファイルの整理、バリデーション | Haiku | 構造化されていて予測可能 |
| 調査、要約 | Sonnet | 推論が良く、速い |
| 戦略、複雑な文章作成 | Opus | 深い推論が必要 |
Mistakes Must Become Infrastructure
あらゆる本番のAIシステムには、あなたが予測できない失敗パターンがあります。問題は、その失敗がシステムに学習させるのか、それともただあなたをイライラさせるだけなのかです。
私のアプローチ：エージェントが、あなたが修正しなければならないミスをしたら、そのたびにシステム設定ファイルの中で、番号付きのルールにします。メモとして頭に残すのでもありません。プロンプトを少し直すのでもありません。恒久的でバージョン管理されたルールとして、今後のすべてのセッションが起動時に読み込みます。
6か月後には、そうしたルールが39個になりました。例：
- 「.gitignore内のステートファイルはマージ中に黙って消えることがある――安全なフォールバック値にデフォルトする」
- 「会議でクライアントが言った内容を推測で補完しない――議事録からの引用だけを使うか、前提としてフラグを立てる」
- 「契約のリバート（元に戻す）では、毎回同じエラーがRPCで発生する――リトライしない。回復不能だ」
これらはプロンプトエンジニアリングではありません。コードとしてエンコードされた、組織のナレッジ（制度的記憶）です。再学習やファインチューニングなしで、失敗するたびにシステムは賢くなっていきます。そしてモデルに「覚えていてもらう」ことには期待しません。
Don't Dump Everything Into Context
AIシステムにおける最大のパフォーマンス低下要因は、モデルではありません。コンテキストの汚染です。すべての知識を毎回すべてのセッションに読み込むと、出力品質が落ち、トークンを浪費します。
うまくいくパターン：モジュール式のコンテキスト読み込み。私のシステムには14個のスキル、56個のコマンド、そして多数のアカウント用のコンテキストファイルがあります。しかし、ある特定のセッションで読み込むのは、関連する部分だけです――特定のクライアントのコンテキスト、特定のワークフロースキル、特定のエージェントの役割。それ以外は、必要になるまでディスクに置いておきます。
コードのimportと同じだと思ってください。あなたはコードベースのすべてのモジュールからimport *することはしないはずです。AIのコンテキストでも同じことをしないでください。
これは、コンテキストファイルが変更履歴（チャンジログ）ではなく、最新の状態である必要があることも意味します。3か月分の過去のメモが蓄積されていくと、それはノイズになります。150行の素早くスキャンできる分量で、「システムが今何をしているのか」を書いてください。変更履歴は別の場所に置きましょう。
The Stack That Actually Works
これを複数のエンタープライズ案件で構築したあとで、AIネイティブなワークフローを作る人に私が勧めたいアーキテクチャは次の通りです：
- 構造化されたコンテキストファイル（markdown、gitで管理）を、ドメイン知識のためのベクトルデータベースより優先する
- スキル（永続的なフレームワーク）を、プロンプト（使い捨ての指示）より優先してドメインの専門性を持たせる
- 引き継ぎ（ハンドオフ）プロトコルを備えた専門化されたエージェントを、1つの汎用エージェントより使う
- コストを意識したモデルルーティング――タスクの複雑さに応じてモデルの能力を合わせる
- エラーからルールへ変換するパイプライン――失敗のたびに、恒久的なシステム改善になるようにする
これらのどれも、フレームワークを必要としません。LangChain も、LlamaIndex も、オーケストレーション層も不要です。必要なのはマークダウンファイル、CLI、そして優れたエンジニアリング規律だけです。AIが推論を行い、あなたがアーキテクチャを設計します。
AIネイティブなワークフローを構築するためのツールは、すでに今日存在します。ボトルネックはモデルの能力ではなく、コンテキストのアーキテクチャです。AIの知識をコードのように扱い始めてください。つまり、構造化し、バージョン管理し、レビューし、そして意図的に読み込むのです。これはチャットボットとシステムの違いです。
