クイックダウンロード
プロンプト エンジニアリングにより単一の応答が改善されますが、エージェントのパフォーマンスは、実行コンテキストが時間の経過とともにどのようにキャプチャ、再生、および制約されるかによって決まります。
-
プロンプトは生成の瞬間に動作しますが、エージェントはシーケンス全体で実行され、すべての決定は蓄積された状態に依存します。
-
コンテキストが拡大するにつれて、コスト、レイテンシー、信頼性は、実行中にどのような事前情報が再取得、キャッシュ、または無効化されるかによって決まります。
-
永続的な意思決定コンテキストがないと、エージェントは失敗を繰り返し、制約を失い、ワークフローが拡張されるにつれて一貫性のない動作をします。
ここ数年、企業はプロンプトに熱中し、そのデザインを中心に役割が生まれ、ツールやテンプレートのエコシステムもすぐにそれに追随しました。この注力により、チームは周囲のシステムを変更することなく、アウトプットを迅速に改善できたため、初期段階では成果が得られました。しかし、時が経つにつれて、その成果は停滞しました。
プロンプトエンジニアリングは生成時点でのみ機能するため、プロンプトは平坦化しました。プロンプトはモデルがその瞬間にどのように応答するかを形作りますが、状態を永続化したり、実行を制御したり、以前に何が起こったかを記録したりすることはありません。プロンプトが再利用可能なパターンに安定するにつれて、タスクが単一のインタラクションを超えて拡張されると、それ以上の反復処理はシステムの動作に影響を与えなくなりました。
エージェントベースのアーキテクチャでは、これらの制限がすぐに明らかになります。
テキストから実行状態へ
システムが単一ターンのインタラクションを超えると、コンテキストはもはやオプションではなくなります。コンテキストは、意思決定を積み重ねるメカニズムとなります。
プロンプトエンジニアリングは、各応答を独立した生成問題として扱える場合に機能します。例えば、チャットインターフェースはコンテキストを限定的で一時的なやり取りに圧縮します。以前のターンは次の応答に影響を与えますが、永続的な実行状態として扱われることはありません。
エージェント システムは継続性を導入することでその前提を排除します。 すべての決定は、すでに起こったことに依存するエージェントは単一の応答を生成するのではなく、時間の経過とともに一連の意思決定を実行します。各意思決定は、過去のアクションの蓄積された記録に基づいて行われます。各サイクルは状態（システム全体から収集された入力、実行されたアクション、呼び出されたツール、返された観察結果、遭遇した障害、そして許可された承認）を追加します。蓄積された状態は、次の意思決定、そしてさらに次の意思決定の条件となります。コンテキストは単調に増加し、各ステップで再処理する必要があります。
これにより、次のような構造的な効果が生じます。
- コストの大部分は、文脈を読み直すことから生じます。 各ステップにおいて、モデルはそれ以前に発生したすべての情報を読み取る必要があります。履歴が大きくなるにつれて、それを再読み込みするコストは、次のアクションを生成するコストよりも高くなります。
- 小さなコンテキストの変更はすべてを遅くします。 キャッシュされた計算は、以前のコンテキストが同じである場合にのみ役立ちます。コンテキストが変化すると、モデルは最初から再計算するため、実行が続くにつれて応答時間が長くなります。
- 初期の決定は強化されない限り消え去ります。 状態が蓄積されるにつれて、当初の目標と制約は新しい情報と競合します。それらが継続されなければ、影響力を失います。
- 失敗を消去すると間違いは繰り返されます。 失敗した試行を削除すると、失敗した理由も削除されます。同様の状況が発生した場合、システムには何をすべきでないかの記録が残っていません。
これらの動作は特定のモデルやベンダーに依存するものではありません。これは、Transformerベースのシステムが複数ステップの実行中に増大するコンテキストを処理する方法に由来します。より強力なモデルはミスが少なくなりますが、それでも蓄積された状態を再読み込みして推論する必要があります。
エージェントが複数のステップにわたって動作すると、システムの動作は単一の応答の品質ではなく、決定間でどのような情報が引き継がれるかによって左右されるようになります。
実行中のコンテキストエンジニアリングの仕組み
コンテキストエンジニアリングは、新しい名前で呼ばれるプロンプト最適化ではありません。エージェントの実行中に、実行状態がどのように組み立てられ、再生され、制約されるかに関係します。実際的な問題は単純明快です。各ステップでどれだけの以前の状態が再取り込みされるか、どの部分が安定を維持するか、そしてどの変更がシステムに以前のすべてのものを再計算させるか、といったことです。
エージェントシステムでは、実行時コストの大部分は、新しい出力を生成することではなく、以前のコンテキストを取り込むことに起因します。キャッシュの再利用は、安定したプレフィックス、決定論的なシリアル化、そして追加専用の履歴に依存します。コンテキストの以前の部分が変更されると（タイムスタンプの更新、キーの順序変更、あるいは以前のアクションの書き換えなど）、キャッシュされたセグメントは無効化されます。モデルはプレフィックス全体を再処理する必要があり、レイテンシとコストの両方が増加します。これらの影響は軽微なものではなく、実行時間が長くなるにつれて、本番環境のトレースで確認できます。
制御問題も同様のパターンに従います。エージェントがより広いツール面にアクセスできるようになると、明示的に制約されない限り、行動選択の信頼性は低下します。モデルが数十、数百のツールから自由に選択できるようにすると、無効または非効率的な行動が発生する可能性が高まります。実行中にツールを動的に追加または削除すると、以前のステップの意味が変わり、キャッシュされたコンテキストが無効になるため、問題がさらに複雑になります。特定の時点で利用可能な行動を制約することで（以前の状態を書き換えることなく）、モデルは一貫した実行履歴に基づいて推論を行うため、より安定した動作が得られます。
これらの懸念はインターフェース層ではほとんど現れません。コンテキストがトークンごとに構築され、段階的に再生される実行パスで表面化します。そのため、システムの実際の動作ではなく、プロンプト、UX、モデルの機能に重点を置いた議論では、これらの懸念が見落とされがちです。
企業における自動化の失敗の理由
エンタープライズ IT 運用により、実行ギャップが可視化されます。
可観測性プラットフォームは状況を表面化し、自動化プラットフォームはアクションを実行しますが、この2つを結びつける仕組みはほとんどありません。十分な状況コンテキストがないままシグナルが到着し、自動化は、アクションが適切か、リスクがあるか、あるいは冗長であるかを説明するような、より広範な状態を可視化することなく実行されます。人間のオペレーターは、システム間のコンテキストをつなぎ合わせ、類似のインシデントを思い出し、実行時に判断を下すことで、この状況を補っています。
その判断はほとんど保存されません。ほとんどの企業システムは、どのようなアクションが実行されたかは記録しますが、なぜ実行されたのかは記録しません。
インシデントがエスカレーションされたこと、サービスが再開されたこと、割引が承認されたことは記録されますが、それらの選択に至った条件、トレードオフ、例外事項は記録されません。その理由はチケット、Slackのスレッド、エスカレーションコールに一時的に記録されますが、実行が完了すると消えてしまいます。
こうした履歴がなければ、自動化は過去の決定に基づいて構築できません。それぞれのアクションは単発的なものとして扱われ、過去の類似事例とは切り離されてしまいます。将来の行動を導くための前例が蓄積されていないのです。
エージェントがこの環境で苦労するのは、人間がそれを補うのと同じ理由です。システムには、意思決定がどのように行われたかに関する永続的な記録がありません。
欠けている記録システムとしてのコンテキストグラフ
意思決定メモリが存在しないことで、システム内の何らかのレイヤーがコンテキストがアクションにどのように変換されたかをキャプチャする必要があるという明確な要件が生じます。
エージェントを実行パスに直接配置するシステムは、この要件をデフォルトで満たしています。意思決定時に、実行に関わるすべての領域を把握できます。どのシステムからどの入力が取得されたか、どのポリシーが評価されたか、どこで例外が適用されたか、誰が逸脱を承認したか、そして最終的にどのようなアクションが取られたかなどです。これらは事後的に推測されるものではなく、コミット時に既に存在します。
実行トレースが永続化されると、ほとんどの企業に欠けているもの、つまり、クエリ可能な意思決定の系統記録が生成されます。最終状態だけでなく、そこに至るまでの条件と判断のシーケンスも記録されます。
時間が経つにつれて、これらの記録は蓄積され、 コンテキストグラフこれはモデルの内部的な推論や思考の連鎖ではありません。ビジネスにおいて既に重要なエンティティ（アカウント、インシデント、ポリシー、承認者、エージェント実行など）を、それらを結びつける意思決定を通じて結び付ける外部構造です。グラフは、各ケースで何が起こったか、そしてそれがどのような制約の下で起こったかを捉えています。
この構造こそが、自律性を増幅させる鍵です。この構造がなければ、システムは孤立した意思決定を繰り返してしまいます。しかし、この構造があれば、過去の意思決定は、失われた前例ではなく、アクセス可能な文脈となります。
コンテキストが持続すると何が変わるか
これらの制約を総合すると、モデル能力の急速な向上にもかかわらず、エンタープライズAIの進歩が鈍化している理由が説明できます。システムが孤立したインタラクションから持続的な実行へと移行するにつれて、制約要因は生成品質から、実行状態が時間の経過とともにどのように処理されるかへと移行します。
プロンプトエンジニアリングは、インタラクションが作業単位であったため、インタラクションを改善しました。エージェントシステムはその単位を変化させます。意思決定は複合的に作用し、コンテキストが蓄積され、過去の行動が次に何が可能かを形作ります。このような状況において、パフォーマンス、コスト、信頼性は、どのような情報が引き継がれるか、それがどの程度一貫して再現されるか、そして過去の意思決定が実行後に消えることなくコンテキストとしてアクセス可能かどうかに依存します。
ここでコンテキストエンジニアリングが決定的な役割を果たす。プロンプトの洗練としてではなく、実行上の問題として、つまりエージェントがステップを跨いで動作する際に、状態がどのように捕捉され、制約され、再利用され、監査されるかという問題としてである。コンテキストを一時的なものとして扱うシステムは、一般化に苦労する。一方、意思決定のコンテキストを永続化するシステムは、先例を蓄積し始める。
この区別によって、自動化が脆弱なままになるか、それとも適応的になるかが決まります。また、実験と実稼働の境界も示されます。エージェントベースのシステムがより長期的なワークフローを担うようになると、重要になるプラットフォームは、単独で最適な応答を生成するプラットフォームではなく、以前の行動の背後にある理由を保持し、適用するプラットフォームになります。
エンタープライズAIが停滞しているのは、モデルの改善が止まったからではありません。実行が課題となっているからです。
Edwin AI を使用して、ITOps 自動化によってチームをリアクティブからプロアクティブにシフトする方法をご覧ください。
LogicMonitorでEdwin AIのコンテンツ戦略を率いるMargo Poda氏。エンタープライズテクノロジーとAIスタートアップの両方での経験を持つ彼女は、複雑なトピックを明確かつ関連性が高く、読む価値のあるものにすることに注力しています。特に、似たようなコンテンツが溢れている分野において、その重要性は増しています。彼女はAIを誇大宣伝するためではなく、AIが実際に何ができるのかを人々に理解してもらうためにここにいます。
免責事項: このブログで述べられている見解は著者の見解であり、LogicMonitor またはその関連会社の見解を必ずしも反映するものではありません。
© LogicMonitor 2026 | 無断複写・転載を禁じます。 | ここで言及されているすべての商標、商号、サービス マーク、およびロゴは、それぞれの会社に帰属します。
