AIの精度が上がらない本当の理由 — コンテキスト設計という考え方
ChatGPTやClaudeへの指示を何度工夫しても、望んだ回答が返ってこない——そんな経験を持つビジネスパーソンは多い。「プロンプトの書き方が悪いのかもしれない」と思い、教材を読み漁る。それでも精度は上がらない。
問題は、プロンプトの書き方ではない。AIに渡す「情報の設計」にある。
Teslaの元AIディレクターでOpenAIの共同創業者でもあるAndrej Karpathyは2025年に「コンテキストエンジニアリング」という概念を広め、「業務レベルのLLMアプリでは、コンテキストウィンドウに正しい情報を正確に詰め込む技術こそが核心だ」と述べた。プロンプトの巧みさより、AIに何を渡すかの設計が成果を決める。
この記事では、コンテキストエンジニアリングとは何か、なぜプロンプト設計だけでは限界があるのか、そして実務でどう実践するかを解説する。
プロンプト設計が限界を迎えた理由
「このメールの返信文を書いて」という依頼は、AIにとって難しくない。単純な1回の指示で完結するタスクであれば、プロンプトの書き方を工夫するだけで十分だ。
問題が起きるのは、複数のステップや継続的なやり取りが必要な場面だ。「先月の議事録を踏まえた上で、このクライアントとの次回提案資料を作成して」という依頼を考えてみる。この依頼に答えるためには、AIは議事録の内容、クライアントの業種・課題、自社のサービス範囲、提案の方向性といった大量の「文脈」を必要とする。
これらをプロンプトに直接書き込もうとすると、指示が数千文字の壁文章になる。管理が難しく、更新のたびに書き直す必要があり、チームで共有するのも手間がかかる。
さらに、技術的な限界もある。「lost-in-the-middle問題」と呼ばれる現象で、AIはコンテキストウィンドウの先頭と末尾にある情報は正確に処理するが、中間に埋もれた情報は見落としやすくなる。情報をただ詰め込むだけでは逆効果になることもある。
プロンプトの書き方を極めても精度が上がらないのは、設計すべき対象が違うからだ。
コンテキストエンジニアリングとは何か
Karpathyはこう表現している。「LLMをCPUだと思えば、コンテキストウィンドウはRAMだ。エンジニアの仕事は、そのRAMに次のタスクに必要なコードとデータを正しくロードすることにある」
コンテキストエンジニアリングとは、AIが答えを出すために必要な情報の全体設計のことだ。単発のプロンプトを磨くのではなく、AIが参照できる知識・履歴・ルール・ツールの構造を設計する。
Gartnerは2025年7月に「コンテキストエンジニアリングが台頭し、プロンプトエンジニアリングは後退する」と宣言した。Shopify CEOのTobi Lütkeも同年、同様の考えを広めた。現場でAIを実際に使っているエンジニアや事業責任者の間で、この考え方が急速に普及している。
プロンプト設計との根本的な違いは、「一回の指示を磨く」のではなく「AIが持続的に参照できる情報環境を設計する」という点だ。
プロンプト設計とコンテキスト設計の3つの違い
| 比較軸 | プロンプト設計 | コンテキスト設計 |
|---|---|---|
| 対象 | 1回の指示文 | 情報全体の構造 |
| 変更頻度 | 毎回書き直す | 一度設計すれば使い回せる |
| 適した用途 | 単発タスク | 継続的・複合的な業務 |
プロンプトを磨くことは間違いではない。単純なタスクには今も有効だ。しかしAIエージェントや複雑な業務自動化の設計になると、個別のプロンプト改善では限界がある。
Lat91では現在、10体のAIエージェントチームを構築・運用している。その設計で最も時間をかけたのは、各エージェントへの指示文（プロンプト）ではなかった。各エージェントが参照できる社内ナレッジ、前のタスクの結果、使えるツールの一覧——これらを構造的に渡す「コンテキストの設計」に最も手間がかかり、ここの精度がエージェント全体の出力品質を決定した。
コンテキスト設計の5つの要素
AIに渡す「コンテキスト」は、5つの要素に分解できる。
図1: コンテキストを構成する5要素
① システム指示はAIの役割・制約・行動規範を定義する土台。「あなたは〇〇専門のアドバイザーです」のような固定的なルール群だ。
② 知識・ドキュメントはAIが参照する社内文書、製品仕様書、過去の事例集。RAGという技術によって、必要なものだけをタイミングよく注入する。
③ 会話履歴・記憶は過去のやり取りや中間成果物。長い対話では全履歴を渡すとコスト・精度の問題が生じるため、「何をどこまで覚えさせるか」の設計が必要だ。
④ ツール結果はAIがツールを呼び出した結果（検索結果、計算結果、API応答）を文脈として渡すもの。Claude CodeのMCP機能はここに相当する。
⑤ 状態・変数は現在の日時、ユーザー情報、タスクの進捗状況。業務の「今の文脈」をAIに渡す動的な情報だ。
企業での実践事例
Shopifyの取り組み（カナダ）
Shopify CEOのTobi Lütkeは、社内AIの開発方針をCHAOSドキュメントと呼ばれる指針で定義しており、その核心はコンテキスト設計にある。顧客の注文履歴・行動データ・問い合わせ経緯を構造化してAIに渡すことで、サポートエージェントの回答精度を大幅に向上させた。プロンプトを洗練させるのではなく、「AIが参照できる顧客コンテキストの質を上げること」に投資した点が重要だ。
金融機関の事例（米国）
融資審査AIを構築した際、プロンプトを何度改善しても誤判定率が下がらない問題が続いた。調査の結果、審査基準の最新バージョンが毎月更新されているにもかかわらず、古い基準がAIに渡り続けていたことが原因だった。コンテキスト管理システムを導入し、「AIが参照するドキュメントが常に最新版である」ことを保証する仕組みを整えたことで、誤判定率が37%低下した（出典: Neo4J Blog, 2025）。
Lat91での経験
私たちが10体のエージェントチームを構築した際、初期段階では各エージェントがバラバラな情報を参照し、整合性の取れない出力を頻繁に生成していた。解決策はプロンプトの改善ではなかった。エージェント間で共有する「共通知識ベース」と「タスクの引き継ぎ情報の構造」を定義し、各エージェントが同じ文脈を参照できるようにした。この設計変更以降、出力の整合性問題はほぼ解消された。
月曜から始める3ステップ
難しく考える必要はない。今週から試せる具体的な手順を紹介する。
ステップ1: 今のプロンプトを5要素で棚卸しする
今使っているAIへの指示を書き出し、5要素（システム指示・知識・履歴・ツール・状態）のどれに相当するかを分類する。「この指示はなぜここにあるのか」を問うだけで、渡すべき情報の構造が見えてくる。所要時間は30分ほどだ。
ステップ2: 社内ドキュメントをAIが読める形に整理する
AIに参照させたい社内情報（製品仕様、業務手順、FAQ）をテキスト化し、検索できる状態にする。ツールは不要で、まずはMarkdownファイルを1つ作るだけでいい。これがRAGの最初のステップだ。
ステップ3: タスクの「引き継ぎ情報」を設計する
AI同士、あるいはセッション間でどんな情報を渡し続けるかを明文化する。「前回のやり取りで決まった3点」を毎回冒頭に渡すだけで、精度は大きく変わる。これは今日からでもできる。
よくある誤解への回答
「コンテキストエンジニアリングは技術者だけのスキルでは？」
これは誤解だ。コンテキスト設計の本質は「AIに正しい文脈を渡すこと」であり、情報整理と知識管理の問題だ。システムの構築は技術者が担うとしても、何を渡すかの設計は業務担当者が最もよく知っている。営業担当者は「顧客コンテキストをAIにどう渡すか」を設計でき、経理担当者は「仕訳ルールの最新版をどう更新するか」を考えられる。
「プロンプト設計を学ぶ意味がなくなるのか？」
そうではない。Gartnerが指摘するのも「排除」ではなく「自動化が進む」ということだ。個人の日常利用や迅速なプロトタイプでは、プロンプトの工夫が直接的な成果につながる。コンテキスト設計が優先されるのは、組織・チームで継続的に使うAIシステムを構築するときだ。どちらか一方という話ではない。
まとめ
- プロンプトを磨くことには限界がある。複雑・継続的な業務では「AIに何を渡すか」の設計が成果を決める
- コンテキストエンジニアリングとは、AIが参照する情報全体（指示・知識・履歴・ツール・状態）を設計する営みだ
- Gartnerが「プロンプトエンジニアリングに代わる」と宣言した本質は、AIの利用が「個人の一時的な利用」から「組織の継続的なシステム」に進化したことにある
- 始め方は簡単。今使っているプロンプトを5要素で棚卸しし、社内ドキュメントをテキスト化し、引き継ぎ情報を設計する
プロンプトを磨くより、AIに正しい文脈を渡す仕組みを作る。この発想の転換が、業務でのAI活用を次のステージに引き上げる。
Lat91では、AIエージェントの設計から社内業務の自動化まで、コンテキスト設計を含む一気通貫の支援をしています。
「自社のAI活用をどう高度化すればいいかわからない」という方は、まずは無料相談からお気軽にどうぞ。