AIコンテキスト・エンジニアリング：なぜプロンプトだけでは不十分なのか
2年前、誰もがプロンプト・エンジニアリングについて語っていました。
コードを書いたり、専門家のように振る舞わせたりするためのプロンプトが共有されていました。考え方はシンプルでした。「より良いプロンプトは、より良い結果をもたらす」というものです。
しかし、実際のAI製品を構築しているエンジニアたちは、ある真実に気づきました。プロンプトはパズルのほんの一部に過ぎないということです。
Claude、Cursor、GitHub Copilotのような現代のAIツールは、単一のプロンプトに依存していません。それらはコンテキスト・エンジニアリング（Context Engineering）を活用しています。
プロンプト・エンジニアリングはこう問いかけます： 「モデルに何を尋ねるべきか？」
コンテキスト・エンジニアリングはこう問いかけます： 「モデルが適切に回答するために、どのような情報が必要か？」
開発者を思い浮かべてみてください。「アプリが壊れています」と言うだけでは、彼らは助けられません。多くの質問を投げ返されることでしょう。
もしエラーログ、スタックトレース、最近のデプロイ情報を提供すれば、彼らはすぐに修正できます。彼らが賢くなったわけではありません。あなたがより良いコンテキストを与えたのです。
AIもこれと同じ仕組みで動いています。
AIにSQLクエリを依頼した場合、推測で答えるかもしれません。しかし、テーブル名、カラムの型、特定のルールを伝えれば、回答は正確になります。プロンプトはシンプルなままでしたが、コンテキストが変わったのです。
本番環境のAIシステムでは、モデルはユーザーのテキスト以上のものを受け取っています。多くの場合、以下のような情報が含まれます：
- システム指示 (System instructions)
- 会話履歴 (Conversation history)
- データベースのレコード (Database records)
- プロジェクトファイル (Project files)
- ツールの出力 (Tool outputs)
AIコーディングアシスタントがあなたの話している内容を理解できるのは、開いているファイルやフォルダ構造を見ているからです。あなたはわずか4単語を入力しただけかもしれませんが、モデルは数千トークンものデータを受け取っています。
プロンプトの言い回しを微調整するために何時間も費やすのはやめましょう。代わりに、こう自問してみてください。「モデルに足りていない情報は何か？」
「魔法の」プロンプトを探すよりも、より優れたドキュメント、APIスキーマ、あるいはビジネスルールを提供することの方が効果的です。
コンテキスト・エンジニアリングとは、適切なタイミングで適切なデータをモデルに与えることなのです。
パート2では、以下について扱います：
- コンテキストウィンドウとトークン
- なぜコンテキストが多いことが常に良いとは限らないのか
- AIにおけるメモリの仕組み
優れたAIシステムは、単にあなたが入力する言葉だけでなく、舞台裏にあるデータに依存しているのです。
Optional learning community: https://t.me/GyaanSetuAi