AIのコンテキストウィンドウ管理は魔法ではありません。アーキテクチャです。

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

では、この点を明確にしましょう。AIアーキテクチャにおいてコンテキスト（セッション）がどこに存在するかを理解することは、実はものすごく重要です。ブログで「ものすごく」なんて言うくらいですから、その重要性がお分かりいただけるでしょう。ええ、本気です。

独自のLLM搭載アプリをOpenAI APIで構築しているなら、ChatGPTを使っているわけではありません。やり取りしている相手はモデル、それも素のモデルです。単にGPT-4を呼び出しているだけで、アプリがChatGPTのように動作すると思っているなら、すでに方向を誤っています。

ChatGPTはモデルではなく、ランタイムです。

これはよく誤解されますが、OpenAIのブランディングもその一因です。「ChatGPT」で得られる体験、つまり記憶、口調、コンテキスト、6つ前の質問で話した内容を自然に追跡し、突然「海洋植物学の博士号を持っている」と幻覚を起こしたりしない仕組みは、魔法ではありません。アーキテクチャによるものです。そして、APIを呼び出すだけで、そのアーキテクチャが自動的に付いてくるわけではありません。

The ChatGPT appは、複数のレイヤーで構成されたマネージド型のエクスペリエンスです。以下の要素を統合しています。

• プロンプトエンジニアリング
• コンテキスト管理
• 永続メモリ
• Guardrailsとフォールバック
• 要約、切り詰め、制御ロジック

APIでは、これらの機能はデフォルトでは一切提供されません。

When you call GPT-4（ほかのモデルでも同様です）を直接呼び出す場合、ステートレス形式で未加工のメッセージ列を渡し、処理中にコンテキストウィンドウがあふれたり分断されたりしないことを期待するしかありません。これは何も設定されていないモデルであり、デジタル執事ではありません。

コンテキストウィンドウの管理は自分で行う必要があります。

ChatGPTでは、推論サーバーがコンテキストウィンドウ全体を管理します。入力した内容は記憶され（記憶されなくなるまでは）、何が関連しているかは、ほぼアプリに任せておけます。さらに、その上にメモリシステムが重ねられており、どの情報を再びコンテキストに渡すかはOpenAIが目立たない形で選別しています。

APIを使用する場合は、利用者自身が推論サーバーの役割を担います。つまり、次のことが必要です。

• メッセージスタックを構築するのはお客さまです。
• 何を含めるかを決めます。
• トークン予算を管理します。
• 切り詰めや要約によって、一貫性が失われることがあります。

そして、設定を誤ると（初めのうちは誰もが経験することですが）、セッションの途中でモデルがユーザー名を忘れたり、入力していないデータを捏造し始めたりした場合、その責任は設定した側にあります。

メモリは機能ではありません。インフラストラクチャです。

ChatGPTにはメモリがあります。しかし、APIにはありません。自分で構築しない限りは。APIはステートレスであり、コンテキスト、メモリ、フローはすべて利用者側で管理します。一方、ChatGPTアプリでは、OpenAIがそのすべてを管理します。これらの機能があらかじめ組み込まれています。

ChatGPTの「メモリ」は、単にプロンプトにメモを付け加えたものではありません。セッションをまたいでユーザーに関する情報、好み、目標、制約を保存し、適切なタイミングでコンテキストに応じてプロンプトに挿入するシステムです。アプリに同様の仕組みを実装するには、以下が必要です。

• データストア
• メモリエントリのスキーマ
• 何をいつ含めるかを決定する制御ロジック
• トークン数の肥大化を防ぐ方法

つまり、インフラストラクチャです。

多くの自社開発AIアプリが不安定に感じられるのは、このためです。LLMをシステム内のツールとしてではなく、チャットボットとして扱っているからです。その結果、会話の流れが途切れ、同じプロンプトを繰り返し入力することになり、不可解な機能低下が生じ、ユーザーの不満につながります。

では、何が問題なのでしょうか？

APIを基盤として構築する以上、意図しているかどうかにかかわらず、インフラストラクチャも構築することになります。また、ユーザーがChatGPTのような体験を期待しているなら、次の要件に対応する必要があります。

• 永続メモリ
• スマートなコンテキスト圧縮
• ターン単位の状態管理
• Guardrails、フォールバック、インジェクションロジック

しかし、これはほんの始まりにすぎません。エンタープライズグレードのアプリケーションデリバリースタック上に構築しているのであれば――もちろん、そうですよね？ 本当に？――プラットフォームのほかの機能も、しっかりと力を発揮する必要があります。

ここで、アプリケーションデリバリーチームとセキュリティチームの出番です。

アプリケーションデリバリ：もはやHTMLやJSONを配信するだけではありません

AIネイティブアプリはステートフルで、チャットを中心に動作し、多くの場合リアルタイム性が求められます。つまり、次のような対応が必要です。

• セッションアフィニティが再び重要になっています。2009年当時のようにセッショントークンを管理しない限り、ステートレスなバックエンド間で会話の状態をシャーディングすることはできません。
• レイテンシはUXの致命傷です。 静的ページを配信するのではなく、複数ターンのインタラクションをストリーミングしています。ロードバランサーとエッジロジックには、低レイテンシの対話フローを優先する仕組みが必要です。
• トークンコスト＝帯域幅＋コンピューティング＋費用。今こそ効率的な配信が重要です。ペイロードサイズはネットワーク上の問題にとどまらず、課金にも直結します。

これは単なるパンフレットサイトではなく、常に変化するインターフェースです。手前にCDNを置くだけで済むものではありません。

セキュリティ：プロンプトを管理できなければ、リスクを負うことになる

LLMはプロンプトを通じてプログラム可能です。つまり、今やプロンプトが攻撃対象領域となっています。

• インジェクション攻撃は現実の脅威であり、すでに発生しています。入力のサニタイズが不十分だと、ユーザーがその場でAIを再プログラムできてしまいます。
• プロンプト操作により、機密性の高いメモリ情報が漏えいしたり、ワークフローが妨害されたり、意図が偽装されたりする可能性があります。
• モデル出力は、ポリシー適用とオブザーバビリティで保護しなければ、外部に流出したり、操作されたり、汚染されたりする可能性があります。

セキュリティ制御も進化させる必要があります：

• 必要なのは、AIトラフィックを理解するWAFです。不正なJSONをブロックするだけでは不十分です。ペイロード構造だけでなく、命令セットにも保護対策が必要です。
• 特に規制対象の環境では、LLMの意思決定に関する監査証跡が必要です。
• 必要なのは、レート制限と不正利用対策です。API呼び出しだけでなく、プロンプトの複雑化やコストの急増にも対応する必要があります。

しかも、これはユーザーレコードをコンテキストウィンドウに挿入することで生じる「データガバナンスの悪夢」にすら触れていません。

エージェント型AIが制御不能になる前に、今こそ適切なスタックを構築しましょう。

要するに、ChatGPTは完成度の高い製品である一方、OpenAI APIは素材のままのツールです。この2つを混同すると、システム基盤が破綻しかねません。

賢明に構築しましょう。拡大を続けるAIポートフォリオを支える、エンタープライズグレードのアプリケーションデリバリおよびセキュリティスタックを構築してください。AIエージェントの構築を始め、意欲的にエージェント型アーキテクチャを採用する段階になれば、その重要性はさらに高まります。エンドユーザー向けAIアプリケーションにおけるコンテキストドリフトやハルシネーションが問題だとお考えなら、エージェント型AIがビジネス向けおよび運用向けAIアプリケーションに何をもたらすかを目の当たりにするまでお待ちください。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事