【BtoB企業向け】Context Engineeringの基本：再利用可能な作業パターンとサブエージェントを「先に作る」DX戦略

生成AIの導入が「検証」から「実務実装」のフェーズへ移行する中、BtoB企業が直面しているのは「AIが期待通りの精度を出さない」「業務フローに組み込めない」という壁である。この課題を解決する鍵が、AIに与える背景情報や処理環境を最適化する「Context Engineering（コンテキストエンジニアリング）」だ。

本記事では、単なるプロンプトの記述に留まらず、企業のデータ資産をAIが理解可能な「文脈」へと変換し、再利用可能な作業パターンとして定義する具体的な手法を解説する。

1. Context Engineeringの本質とBtoB企業が優先すべき理由

プログラミングにおけるContext（文脈）とは、特定の処理が実行される際の環境や状態を指す。例えば、Go言語のcontextパッケージは、APIリクエストのキャンセルやタイムアウトを制御し、システム全体の整合性を保つために不可欠である（出典：Go Packages – context）。

これをAI実務に適用したContext Engineeringは、LLM（大規模言語モデル）に対し、「誰が」「何の目的で」「どのデータを使用して」タスクを実行するかを、動的かつ構造的に提供する技術である。

1-1. なぜ「プロンプト」だけでは不十分なのか

BtoBの業務は、複雑な商習慣、顧客ごとの個別契約、SFA/CRMに蓄積された構造化データなど、極めて高い専門性を要する。単発のプロンプトでは、これらの膨大な「暗黙知」を網羅できず、結果としてハルシネーション（もっともらしい嘘）を誘発する。

Context Engineeringでは、以下の3層で文脈を管理する。

• データコンテキスト：SalesforceやBigQueryに格納された生データ。
• セマンティックコンテキスト：データの意味（「解約」の定義や「商談フェーズ」の進行条件など）。
• オペレーショナルコンテキスト：特定の部署で受け継がれている「作業の手順書」や「過去の成功パターン」。

これらを「先に作る」ことで、AIは初めて実務に耐えうる精度を発揮する。例えば、広告運用の自動化においては、単に「バナーを作れ」と命じるのではなく、過去のCAPI（コンバージョンAPI）経由のデータをBigQueryで解析した結果をコンテキストとして与える必要がある。

関連記事：広告×AIの真価を引き出す。CAPIとBigQueryで構築する「自動最適化」データアーキテクチャ

2. 再利用可能な「作業パターン」を設計する5ステップ

Context Engineeringの核心は、属人化している業務を「再利用可能なパターン」としてモジュール化することにある。

ステップ1：業務プロセスの最小単位（アトム）への分解

「見積書作成」という大きなタスクを、「商品マスタの参照」「顧客情報の取得」「単価計算」「承認フローの回付」といった最小単位に分解する。これにより、各工程で必要なコンテキストを特定できる。

ステップ2：メタデータの付与と構造化

分解したタスクに対し、AIが処理しやすいようJSONやMarkdown形式でメタデータを定義する。

例：{ "task_type": "pricing_analysis", "input_source": "Salesforce_PriceBook", "output_format": "Table" }

ステップ3：SaaS公式APIを用いたリアルタイム連携

コンテキストは常に最新でなければならない。例えば、freee会計のデータを活用する場合、公式のAPIドキュメントに基づき、認可（OAuth 2.0）を経て正しいエンドポイントからデータを取得する設計が必要だ。

【公式URL】freee API Reference

ステップ4：プロンプトへの「動的注入」

取得したデータをそのままプロンプトに流し込むと、トークン制限（Context Window）に抵触する。そのため、RAG（検索拡張生成）やベクトルデータベース（Pinecone等）を用いて、関連性の高いコンテキストのみを抽出・注入する仕組みを構築する。

ステップ5：評価とフィードバックループの構築

AIの回答精度を定量的（正解率やトークンコスト効率）に測定し、作業パターンを継続的にブラッシュアップする。

3. 自律サブエージェント構築のための主要ツール比較

実務では、一つの巨大なAIを作るのではなく、特定のタスクに特化した「サブエージェント」を複数連携させる「Multi-Agentシステム」が主流となっている。以下に、BtoB DXで中核となるプラットフォームを比較する。

これらのツールを組み合わせる際、最大の障壁となるのが「データの分断」である。例えば、会計データと営業データの不整合は、AIの判断を誤らせる致命的な要因となる。

関連記事：【図解】SFA・CRM・MA・Webの違いを解説。高額ツールに依存しない『データ連携の全体設計図』

4. 【実務解説】具体的なコンテキスト構築手順とコード例

ここでは、Salesforceの商談データ（Opportunity）を抽出し、AIが「ネクストアクション」を提案するためのコンテキストを構築する手順を示す。

手順1：認証とデータ取得

Python等の言語を用い、SalesforceのREST APIを介してデータを取得する。

【公式URL】Salesforce REST API開発者ガイド

手順2：コンテキストのフィルタリング

直近30日間の活動履歴、商談金額、競合他社情報に絞り込み、情報を凝縮する。全データを送ると、Claude 3.5 SonnetやGPT-4oといったモデルのトークン消費を早めるだけでなく、指示の焦点がぼける原因となる。

手順3：サブエージェントへの役割付与

以下のような役割定義（System Prompt）を作成し、再利用可能なパターンとして保存する。

あなたはBtoBセールスの戦略アナリストです。与えられたOpportunityデータから「成約を阻害しているリスク因子」を3つ特定し、明日までに営業担当者が取るべき行動をステップバイステップで提示してください。

バックオフィス業務においても、同様の設計が必要だ。経理の自動化では、SaaS間のデータ不整合をどう解消するかがコンテキストの質を左右する。

関連記事：freee会計導入マニュアル｜旧ソフト移行ガイド

5. 実務で直面するエラーとトラブルシューティング

Context Engineeringを実装する上で、必ず遭遇する問題とその解決策を挙げる。

5-1. コンテキストウィンドウの超過（429 Error等）

現象：大量のドキュメントを読み込ませようとして、API側から拒否される、または回答が途切れる。

解決策：

テキストのチャンク分割： 文書を1000〜2000文字程度の意味のある単位に分割する。

要約の階層化： 下位エージェントに各チャンクを要約させ、上位エージェントがその要約を統合する「MapReduce」方式を採用する。

5-2. ハルシネーション（情報の捏造）

現象：存在しない商品名や、過去の無効な規約をベースに回答する。

解決策：

Grounding（根拠付け）： プロンプトに「必ず提供されたコンテキストのみを参照し、知識がない場合は『不明』と答えなさい」という制約を追加する。

メタデータの付与： データの最終更新日をコンテキストに含め、AIが「情報の鮮度」を判断できるようにする。

5-3. APIレートリミットの制限

現象：短時間に大量のリクエストを送り、SaaS側から一時的にブロックされる。

解決策：

指数バックオフの実装： エラー発生時に待機時間を指数関数的に増やしながら再試行する。

キャッシュの活用： 頻繁に参照するコンテキスト（規約、マスタ情報等）はRedis等にキャッシュし、APIコールを最小化する。

まとめ：コンテキストこそが企業の独自資産となる

Context Engineeringは、単なるツールの使いこなしではない。自社の業務をいかに構造化し、AIが理解可能な「共通言語」として整理できるかという、極めて高度なビジネス設計力が問われる領域である。

再利用可能な作業パターンを先に作り、それをサブエージェントが自律的に実行する。このアーキテクチャこそが、労働力不足と業務の複雑化に悩むBtoB企業が、真のDXを実現するための唯一の道である。

なお、各種アプリのすべての機能を使用するには、Gemini アプリ アクティビティを有効にする必要があります。