コンテキストエンジニアリングとは？AIエージェントの判断を支える実践ガイド

デモではうまく動くAIエージェントが、実際の業務ではタスクから逸れてしまうことがあります。そんなときは指示を増やす前に、モデルに何が渡っているかを確認してください。コンテキストエンジニアリングでは、各ステップで渡す情報を、指示、ツール、取得した事実、メモリ、履歴という5つの入力から設計します。次に正しく行動するための根拠をそろえつつ、無関係な情報を持ち越さないことが狙いです。

コンテキストエンジニアリングとは？

コンテキストエンジニアリングとは、モデルが次の判断を下すときに、何を参照できる状態にするかを設計することです。 書き込んだ指示だけでなく、選べるツール、ツールが返す根拠、読み込むメモリ、残しておく会話までが対象になります。

モデルのコンテキストウィンドウは、リクエストを処理するための作業領域です。トークンは、モデルが処理するテキストなどのコンテンツの単位を指します。システムのどこかに保存した文書は、利用できる情報ではあります。ただし、その内容が実際にコンテキストに入るのは、アプリケーションやエージェントが読み込んだときです。

この違いを押さえると、本番環境でよくある失敗の理由が見えてきます。エージェントが正しいポリシーにアクセスできても、判断する時点で最新のポリシーがモデルに届いていなければ、古い会話をもとに回答してしまいます。反対に、すべてのポリシーを読み込めば、関係のない例外や古い版まで混ざりかねません。

Anthropicは2025年9月29日のエンジニアリング記事で、この作業を**「LLMの推論時に、最適なトークン（情報）の集合を選び、維持すること」**と説明しています。指示を書くことと、実行中に渡す情報全体を管理することを区別しているのです。Anthropicによるコンテキストエンジニアリングの解説。

LangChainは2025年7月2日の記事で、**「エージェントが処理を進める各段階で、ちょうど必要な情報をコンテキストウィンドウに満たすこと」**と表現しています。作業は、書き出す、選ぶ、圧縮する、分離する、に整理されています。有用な状態を保存し、関連する情報を取得し、残す情報を短くまとめ、独立した調査を切り分けるという考え方です。LangChainによるコンテキストエンジニアリングの解説。

実務で変わるのは、設計の対象です。単独のプロンプトなら、内容を固定したまま使えることもあります。しかし、エージェントが次に送るリクエストは、ファイルを読む、ツールの結果を受け取る、サブタスクを終える、以前の仮定が誤りだと分かる、といったたびに変わります。タスクの途中でも、その都度リクエストを組み立てる方針が必要です。

ドキュメントの確認日：2026年10月13日。 以下のツールの挙動は、この時点のAnthropicとOpenAIのドキュメントで確認しています。後半の具体例は設計を説明するためのもので、本番環境のベンチマークではありません。

コンテキストエンジニアリングとプロンプトエンジニアリングの違い

プロンプトエンジニアリングは指示を改善し、コンテキストエンジニアリングは指示を含むリクエスト全体を改善します。 どちらも必要です。

コーディングエージェントなら、「サインアップを直して」という指示を、「サインアップを再試行するとウェルカムメールが重複送信される原因を調べ、最小限の修正と回帰テストを提案して」に変えるのがプロンプトエンジニアリングです。その修正を提案する前に、サインアップ関連のどのファイル、再試行ログ、プロジェクトのルール、これまでの調査結果を渡すかを決めるのがコンテキストエンジニアリングです。

指示がどれほど明快でも、別の環境のログを読み込んでいては埋め合わせになりません。ログの抜粋を慎重に選んでも、求める作業が原因調査なのか、編集なのか、デプロイなのかを指示していなければ不十分です。

大切なスキルは、情報の境界を決めること

情報ごとに、いつコンテキストに入れ、いつ外してよいかを決めます。長く使うプロジェクトのルール、一時的なタスクの状態、加工前の根拠資料では、保持すべき期間が違います。

コーディング規約は、継続して読み込む指示に置きます。「再試行の分岐はまだテストしていない」という情報は、現在のタスクの引き継ぎに残します。プロバイダーのレスポンス全体は、アクセスできる根拠ファイルに保存し、判断に関係するフィールドを必要なときに読み込みます。

検索拡張生成、つまりRAGが全体の一部にすぎないのも、このためです。RAGはモデルの判断を支える資料を取得します。それでも、指示、ツール、保持する履歴、そして取得結果のうち何を渡すかは、別途選ばなければなりません。

AIエージェントのコンテキストを整える主な方法

失敗したステップで、無関係なコンテキストを最も多く生んでいる箇所から手を付けます。 すべての仕組みを一度に導入する必要はありません。大量のログを扱うデバッグエージェントと、プロジェクトの制約を何度も忘れるアシスタントとでは、最初に直すべきところが違います。

履歴の圧縮では、話題だけでなく判断の経緯を残す

AnthropicのコーディングエージェントであるClaude Codeには、コンテキストの使用状況を調べる/contextと、会話を短くまとめる/compactがあります。自動管理では古いツール出力を消し、それでも必要なら会話を要約します。ドキュメントには、会話の前半にあった詳細な指示が失われる場合があると明記されています。Claude Codeのコンテキスト管理。

圧縮するときは、何を残すかを明確にします。ウェルカムメールの調査なら、/compact Preserve the current goal, change boundaries, relevant file paths, observed evidence, failed hypotheses, and the next unresolved question.と指示します。これは、そのタスクで重視する情報を指定したコマンドであり、すべての詳細が残るという保証ではありません。

作業を続ける前に、要約の中で確認済みの事実、推測、未確認事項が区別されているかを確かめます。「メールの再試行を調査した」だけでは、話題を示しているにすぎません。「プロバイダーが受け付けたことは確認済み。ローカル側の確認処理はまだ調べる必要がある」なら、次の行動につながる状態を表せます。

圧縮では情報が失われます。元の根拠資料にはアクセスできるようにしておき、継続して守るルールはプロジェクトの指示に置きます。そうすれば、後のステップで必要になった詳細を取り戻せます。

次の判断に必要な根拠を、その都度取得する

次の疑問に答える情報源を取得し、それだけでは足りないときに検索範囲を広げます。Anthropicのエンジニアリング記事では、軽量な参照情報を保持し、必要になったときにツールで情報を読み込む方法として説明されています。必要なタイミングで読み込むコンテキスト。

Claude Codeでは、ファイル読み込みツールやシェルツールでこの流れを実現できます。再試行ハンドラーを探し、そのハンドラーと呼び出し元を読み、対応するエラーの流れを確認するように依頼します。専用のGrepツールが有効なら、ファイル全体ではなく、ファイルパス、一致箇所の内容、件数を返せます。Claude Codeのツールリファレンス。

自作のエージェントなら、情報源を参照するための識別子、関連箇所の抜粋、適用範囲を特定できるメタデータを返します。環境、レコードの識別情報、バージョン、適用日などです。周辺の内容は、後のツール呼び出しで開けるようにします。

情報取得では、関連する根拠を取りこぼすことがあります。検索範囲を広げるルールも用意してください。絞り込んだ検索で何も見つからなければ、その事実は存在しないと結論付ける前に、範囲やクエリを変えます。抜粋だけでは例外の適用を判断できない場合は、前後の節も読み込みます。

ツールの結果は、会話に入れる前に絞り込む

次の判断に必要な結果を返し、省いた詳細を取り戻せる手段も添えます。Anthropicは、出力の多いツールに対し、フィルタリング、ページ分割、範囲指定、切り詰めを勧めています。短縮した場合は、役に立つ案内も必要です。Anthropicのツール設計ガイド。

Claude Codeでは、成功したシェルコマンドの出力が大きい場合に、この方法を具体的に実装しています。インラインで表示できる上限を超えると、保存先のファイルパスとプレビューを渡し、必要に応じてエージェントがファイルを検索したり読んだりできるようにします。ドキュメント上、失敗したコマンドの扱いは異なります。切り詰められたエラーなら必ず、元の内容を読めるファイルパスが付くとは限りません。シェル出力の扱い。

サインアップを調べるエージェントに役立つログは、対象のイベント、その直前の操作、エラー、元の記録の場所を含むものです。正常なリクエストの繰り返しは、ログファイルに残しておけます。エラーコードとイベントの識別情報は、正確なまま保持してください。「何かがタイムアウトした」といった説明に置き換えると、修正を決める手がかりまで消してしまうかもしれません。

機械的に切り詰めると、決定的な例外を落とすことがあります。省略したことが分かるようにし、追加のクエリやファイルへの参照を示します。矛盾する根拠を削る前に、繰り返される不要な情報を削ってください。

履歴を引き継がないサブエージェントに、独立した調査を任せる

Claude Codeのサブエージェントは、別のコンテキストウィンドウで範囲を限定した調査を行い、結果を返せます。非フォーク型のサブエージェントは、自身の定義と渡されたタスクをもとに新しく開始します。一方、会話のフォークは親の履歴を引き継ぎます。どちらも開始後の作業は分離されますが、過去の会話を含まないコンテキストで始められるのは前者です。サブエージェントとフォーク。

たとえば、「メールの再試行経路を調べてください。ファイルは編集せず、関連するパス、重複配信の根拠、別の説明の可能性、次に確認すべき点を返してください」と依頼します。親の会話を知っていると考えず、担当するエージェントに必要な制約も渡します。

返してもらう内容は、調査結果、根拠への参照、不確かな点に絞り、そのまま使える量に収めます。読んだものをすべて返すなら、膨らんだ履歴をメインの会話に移すだけです。

作業を任せたエージェントも、独自にリクエストを送り、使用量を消費します。依頼内容に、親側ですでに確定した判断が含まれていないと、同じ作業を繰り返すこともあります。調査を切り離せて、途中の出力を残す必要がない場合に活用してください。密接に関係する推論は、まとめて扱います。設定の詳細はClaude Codeのサブエージェントで解説しています。

メモリファイルの役割は、小さく安定させる

CLAUDE.mdはプロジェクトの指示ファイルであり、終わった会話をすべて貼り付ける場所ではありません。Claude Codeには、学んだ内容を記録する自動メモリもあります。ドキュメントでは、どちらも強制力のある設定とは区別されています。メモリファイルに禁止事項を書いても、その操作を技術的に実行不能にできるわけではありません。Claude Codeのメモリ。

小規模なプロダクトチームなら、リポジトリ固有のルール、実際に使うビルドとテストのコマンド、変更してよい範囲、詳しい資料への参照を、継続して使うファイルにまとめます。一時的な調査状況は、別のタスクメモに残します。ファイル構成についてはCLAUDE.mdでチームの知識を共有する方法を参照してください。

見落としやすい点もあります。長い文書をCLAUDE.mdにインポートすると、その内容も読み込まれます。文章を別ファイルに分けてインポートすれば整理はしやすくなりますが、使用中のコンテキストが減るとは限りません。リポジトリの一部でだけ必要な指示には、ドキュメントにあるパス単位のルールを検討してください。繰り返し使うワークフローについては、Claude Codeのスキルは通常、まず説明だけを公開し、呼び出されたときに指示の全文を読み込みます。メモリのインポートと適用範囲を限定したルール、スキルの読み込み。

永続ファイルには、有用な知識と同じように、古い前提も残ります。解決済みの障害や置き換えられたコマンドは削除してください。変わり得る事実には、情報源やリビジョンを記録します。セッション、作業中のコンテキスト、永続ストレージの違いを詳しく知りたい場合は、エージェントのメモリの仕組みを参照してください。

Claude Agent SDKとCodexでは、どう実践するか

ここまでの仕組みは具体的なツールに備わっています。ただし、根拠の選択とタスクの切り分けは、アプリケーション側の仕事です。 ワークフローが取得し忘れた業務上の事実を、自動コンテキスト管理が判断してくれるわけではありません。

Claude Agent SDK：アプリケーションにエージェントの実行ループを組み込む

Claude Agent SDKは、Claude Codeを支えるツール、エージェントの実行ループ、コンテキスト管理を、PythonやTypeScriptのアプリケーションで利用できるようにします。自分たちが運用するプロダクトや自動化の仕組みに、エージェントを組み込む場合に使います。Agent SDKの概要。

SDKは、コンテキストウィンドウの上限が近づくと古い履歴を自動的に圧縮し、compact_boundaryというシステムイベントを発行します。このイベントをタスクの結果とともに記録すれば、要約後に現れる失敗を特定しやすくなります。SDKの非フォーク型サブエージェントは、途中の作業を自身の会話内に保持し、最後のメッセージを返します。SDKのエージェントループ、SDKのサブエージェント。

プロジェクトの指示をどう読み込むかも、明確にしてください。現在のquery()のデフォルト設定では、ユーザーとプロジェクトの設定ソースが有効です。TypeScriptでsettingSources、Pythonでsetting_sourcesを指定する場合、プロジェクトのCLAUDE.mdが必要ならprojectを含めます。空の配列を渡すと読み込まれません。この挙動を制御するのは設定ソースであり、システムプロンプトのプリセットにclaude_codeを選ぶことではありません。SDKでの指示の読み込み。

実行ループが高機能でも、業務領域に応じた情報取得の方針は必要です。サポートエージェントなら、対応中の顧客をどう特定するか、どのポリシーが適用されるか、行動前にどの根拠をそろえるかを、引き続き定義しなければなりません。

Codex：リポジトリの指示と、進行中の会話を分ける

OpenAIのCodexは、作業を始める前にAGENTS.mdの指示を読みます。共通のガイダンスに、リポジトリのルートから作業ディレクトリに向かって見つかるプロジェクトファイルを組み合わせます。後から読み込む指示が優先され、各ディレクトリではAGENTS.override.mdが優先されます。Codexのプロジェクト指示。

この階層を使い、全体に共通するビルドのルールはルートに、専門的なルールは対象の作業に近い場所に置きます。Codex CLIには、現在のチャットを要約する/compactと、指示ファイルのひな型を作る/initもあります。生成されたひな型を正式な指示として扱う前に、リポジトリの実態に合っているか確認してください。Codexのコマンド。

リポジトリの指示ファイルには、進行中のタスクが自動で記録されるわけではありません。現在の目的、確認済みの調査結果、残っている作業、根拠の保存場所は、別に保存します。再起動や圧縮の後は、調査の全履歴を再び渡さなくても、次のリクエストからタスクの状態を参照できるようにします。

コンテキストエンジニアリングの実践例：膨らんだ情報を整理する

判断に必要な情報のつながりを保ちながら、その周辺にある不要な情報を削ります。 ここでは、サインアップの再試行後にウェルカムメールが重複送信される問題を、コーディングエージェントが調べる仮想例を考えます。以下のファイル名や根拠は設計を示すためのもので、実稼働システムで得た結果ではありません。

最初に渡された情報は膨大です。開発ハンドブックの全文、リポジトリから広範囲に取り出した内容、無関係なサービスのログ、それまでのデバッグの全会話、関係のない管理業務用のツールまで含まれています。しかし、実際のタスクはもっと限定されています。重複送信に至る経路を見つけ、最小限の変更を提案し、回帰テストを特定することです。スキーマの変更は対象外です。

1. 1

   現在のタスクと、継続して守る制約を残す

   会話履歴の中で競合している依頼を、現在の目的と受け入れ基準に置き換えます。スキーマを変更しないという制約は、見える場所に残します。この作業に必要なリポジトリ操作用のツールを使えるようにし、無関係な管理ツールの定義は今回の実行に含めません。変わりにくいリポジトリの規約は適切なプロジェクト指示ファイルに移し、一時的な観察結果はタスクメモに残します。ハンドブック全体を自動読み込みのインポートに入れないようにします。

2. 2

   大量のファイルを、根拠の所在が分かる一覧に置き換える

   signup-handler.ts、welcome-job.ts、再試行のテスト、関連するログファイルへの参照を残します。これらの名前は説明用の例です。次の疑問に答えるために必要になったらハンドラーやワーカーを読み、必要に応じて依存先も調べます。一覧は根拠にたどり着くためのものであり、内容を読む代わりにはなりません。

3. 3

   失敗の前後に絞って、ツールの結果を取得する

   対象のサインアップイベントと、その再試行の流れを取得します。仮に、プロバイダーが受け付けた後、ローカル側の確認処理が欠け、次の試行がキューに入ったことが記録されているとします。この順序、イベントの識別情報、元の記録の場所を残します。無関係な成功リクエストは、元のログに残しておきます。2回目の試行で実際に配信されたかどうかは、未確定のまま扱います。

4. 4

   範囲を限定した調査を切り離す

   非フォーク型の作業エージェントに、重複送信を防ぐ処理の実装箇所を探してもらいます。タスクの範囲と関連するパスを渡し、該当箇所と根拠を返すよう依頼します。検索が不完全だった場合には、その旨も明示してもらいます。メインのエージェントには調査結果を返し、途中で探索のために読んだ内容は持ち込みません。

5. 5

   調査を圧縮し、作業を再開できる引き継ぎを作る

   現在の目的、分かっている根拠、否定された説明、未解決の疑問、次の行動を残します。再試行がキューに入ったことと、重複配信が確認されたことは、明確に区別します。元の会話は保存し、詳細が必要になったときにエージェントが推測せず確認できるようにします。

6. 6

   残した情報から、次のリクエストを組み立てる

   タスク、継続して守るルール、関連するハンドラーの抜粋、絞り込んだイベントの流れ、作業エージェントの調査結果を読み込みます。次に行うのは、確認処理と重複防止の経路を調べ、回帰テストを提案することです。そのために必要なら、根拠を追加で読み込みます。習慣的にアーカイブ全体を添え直さないようにします。

この結果、タスクメモは次のようにまとめられます。

目的： サインアップの再試行後にウェルカムメールが重複送信される理由を説明し、回帰テストを伴う最小限の修正を提案します。
制約： スキーマの変更は対象外です。
根拠： 選んだログの流れには、プロバイダーによる受け付け、ローカル側の確認処理の欠落、次の試行がキューに入ったことが記録されています。イベントへの参照と元のログの場所を保持します。
未確認事項： キューに入った再試行で実際に配信されたか、重複送信を防ぐ処理がどこで適用されるかは、まだ分かっていません。
次の確認： 参照先のハンドラーとワーカーで、確認処理と重複防止の経路を調べます。

この仮想のメモでは、不確かな点を明示したままにしています。モデルが原因を判断するときには、根拠となる抜粋も一緒に渡します。

ここで減ったのは、コンテキストに含める情報の量と種類です。トークン数が減ったと実証したわけではありません。正確なトークン数は、実際のリクエストとトークナイザーによって変わります。支出の削減や完了率の向上を確かめるには、測定が必要です。この例が示しているのは、何を取り除き、何を残すかという設計です。

引き継ぎに使えるコンテキストエンジニアリングのテンプレート

タスクメモには次の項目を設け、実行中に得た実際の根拠を記入します。

• 目的と完了条件： 現在の依頼と、何をもって完了とするかを記します。
• 制約： 次のステップでも守るべき作業の範囲や条件を記します。
• 確認済みの事実： 各調査結果に、情報源の場所と、関連するリビジョンまたは適用範囲を添えます。
• 不確かな点： 推測にとどまること、矛盾していること、まだ調べていないことを記します。
• 次の行動： 次に確認する内容と、その根拠を取得できる場所を記します。

調査結果が変わったら、メモも更新します。古い記述を直さず、新しく思い付いたことを追記し続けると、小さなファイルの中に同じ問題を再現することになります。

数字で見る：コンテキストの大きさとコストは分けて確認する

最適化すべきなのは、受け入れ基準を満たす結果を得るためのコストです。 リクエストを短くすること自体を目標にしないでください。メインの会話が小さくなっても、作業エージェントの呼び出し、情報取得、失敗した試行が増えている場合があります。

ドキュメントにある2つの指示量の目安を比べると、単位が重要だと分かります。Codexでは、プロジェクト文書を合わせたデフォルトの上限は32 KiB、つまり32 × 1,024 = 32,768 bytesです。これはバイト数の上限であり、トークン数の上限ではありません。Claude Codeは、各CLAUDE.mdを200行未満に収めることを推奨しています。こちらは書き方の指針であり、コンテキストウィンドウの厳密な上限ではありません。どちらの数字からも、コストの削減額は予測できません。Codexの指示量の上限、Claude Codeの記述ガイド。

本番のワークフローでは、メインエージェント、作業エージェント、圧縮、情報取得、再試行にかかったコストを記録し、次のように計算します。

受け入れ基準を満たしたタスク当たりのコスト = 全試行にかかったワークフローの総コスト ÷ 受け入れ基準を満たしたタスク数。

月次予算を考えるなら、モデルの使用料金に、ツール、情報取得、ストレージ、ホスティングの料金を加えます。コンテキストエンジニアリングに一律の月額料金はありません。実際のワークロードと適用されるプロバイダーの料金が分からなければ、根拠のあるドル建ての削減額も示せません。

キャッシュがあると、比較はさらに複雑になります。OpenAIのプロンプトキャッシュは、リクエストとして組み立てられた入力の先頭部分が一致すると、それを再利用します。圧縮でその先頭部分が変われば、リクエストは短くなっても、キャッシュの再利用は減ることがあります。再利用する指示はできるだけ安定させ、変更前後の総コストを比べてください。キャッシュヒット率が下がっただけで、最適化に失敗したとは判断できません。OpenAIのプロンプトキャッシュ。

先頭部分の変更が原因の問題と、不要な内容が原因の問題を切り分けるには、GPT-6のプロンプトキャッシュ診断を参照してください。キャッシュは繰り返し入力する内容の処理を安くしますが、その情報がタスクに必要かどうかまでは判断しません。

コンテキストエンジニアリングのベストプラクティス：どこから変えるか

トレースにコンテキストが原因の失敗が見えたら、それを解消する最小限の変更を選びます。 トレースとは、リクエスト、ツール呼び出し、結果の一連の記録です。各判断の直前に、モデルが何を見ていたかも含まれます。

開発者は、誤った行動の直前のステップを調べてください。根拠が足りないなら、情報取得を直します。根拠が繰り返し出力される情報に埋もれているなら、ツールの結果を絞ります。過去の議論が現在のタスクより優先されているなら、タスクの状態と引き継ぎを修正します。切り離せる調査がメインの会話を埋めているなら、その調査を分離します。

運用担当者は、受け入れ可能な結果を定義し、代表的な失敗例を評価用に保存します。同じタスクで、完了時の品質、裏付けのない主張、再試行、遅延、総コストを比べてください。結果を解釈できるように、コンテキストに関する方針は一度に1つずつ変更します。既存のトレースを使って、オフライン評価のケースを設計します。

製品の導入を検討する人は、回答の背後にあるコンテキストとツールの結果を確認できるか、要約後も情報源への参照が残るか、継続して使う指示を制御できるかを確かめてください。何が読み込まれるのか見えない「メモリ」機能では、問題の原因を調べにくくなります。

短く、範囲の限られたワークフローがすでに安定して動いているなら、仕組みを増やすのは待ってください。 必要なのはメモリサービスや作業エージェントのネットワークではなく、より明確な指示や、分かりやすいツールのエラーかもしれません。原因が権限設定の誤り、アプリケーションロジックの不具合、参照データの欠如にあるなら、その原因を直接直します。コンテキストの整理だけでは解決できません。

コンテキストエンジニアリングは、どこまで期待できるか

コンテキストウィンドウの拡大、メモリの追加、エージェントの増員は、使える能力を増やします。ただし、判断が良くなった証拠ではありません。 問うべきなのは、このワークフローで、必要な情報を次のステップに運ぶ助けになるかどうかです。

「全部プロンプトに入れる」なら選別は不要ですが、競合する情報も持ち込むことになります。「全部要約する」ことで重要な例外まで消えるなら、選別しすぎです。「サブエージェントに任せる」が有効なのは、重要な判断を失わずにタスクを切り離せる場合だけです。

最も高くつく誤りは、短いリクエストと、妥当性を検証したシステムを混同することです。誤ったポリシーから安く回答するエージェントも、誤っていることに変わりはありません。良いコンテキストの方針は、回答を検証しやすくするはずです。適用するルールが見え、判断を支える根拠に情報源があり、残っている不確かさが明示されている状態を目指します。

エージェントがタスクから逸れるときのよくある質問

デモでは動くのに本番で失敗するエージェントは、コンテキストエンジニアリングで直せますか？

根拠の不足、古い指示、過剰なツール出力、タスクの状態の喪失には対処できます。まず、失敗したリクエストを確認してください。ツールの不具合、アプリケーションロジックの誤り、モデルの能力を超えるタスクには、それぞれ別の対応が必要です。代表的なタスクで受け入れ基準を満たせたかをもとに、変更を評価します。

始めるにはベクトルデータベースやマルチエージェントのフレームワークが必要ですか？

必要ありません。明確なプロジェクトの指示、対象を絞ったファイルや文書の取得、範囲を限定したツールの結果、タスクの引き継ぎから始めます。関連資料を見つけるために必要になったら意味検索を追加し、独立した調査を別のコンテキストで行う利点があるなら、サブエージェントを加えます。

情報を削りすぎたかどうかは、どう判断しますか？

次の判断に必要なルール、根拠、適用範囲、重要な例外が残っているかを確認します。削った事実をエージェントが推測しなければならないなら、コンテキストを絞りすぎています。参照し直せる情報源を残し、抜粋だけでは疑問が解消しない場合は、読む範囲を広げてください。

週明けにまず取り組むこと： すでにある失敗した実行を取り上げ、最初に誤った行動をした直前のリクエストを調べます。内容を、継続して守る指示、進行中のタスクの状態、今必要な根拠、保存先に残しておける情報に分けます。それに応じた最小限の変更を加え、同じ評価ケースで結果とワークフローの総コストを比べてください。

役に立つエージェントの開発と運用について、実践的なガイドを受け取るには、ニュースレターに登録してください。