コントロールではなく、コンテキスト

コントロールではなく、コンテキスト

エージェントのプロンプトに含まれるすべてのルールは、バグとして始まりました。

誰かが問題のある動作を見て、ルールを書き、先に進みました。別の人が同じことをしました。三番目の人がある火曜日にモデルが一度奇妙なことをしたので「Xは絶対にしない」を追加しました。誰も何も削除しませんでした。

半年後、エージェントは実際のタスクについて考えるよりも、コンテキストウィンドウの大部分をルールブックのナビゲートに費やしています。

これがコントロール思考です。そして、これはチームがAIエージェントを構築するときに犯す最大のデザインミスの一つだと思います。

より大きなパターンを明らかにする小さな例

私たちは、スケジュールされたタスクによってトリガーされたエージェントが、実行内から新しいスケジュールされたタスクを作成し続けるという問題に遭遇しました。無限再帰ですが、実世界の副作用を伴います。

対応の方法は二つあります。

コントロール型スタイル： 禁止する。スケジュールがスケジュールを作成できないようにコードを書く。プロンプトルールを追加：「スケジュール内でスケジュールを作成しない。」リリースする。

コンテキスト型スタイル： 実際に何が起きているかをエージェントに伝える。

あなたは太平洋標準時午前3時にスケジュールされたタスクによってトリガーされました。スケジュールID：sched_29x8f。スケジュールされた実行は、ユーザーが元々承認した定義されたスコープを持つ独立した実行です。新しいスケジュールされたタスクを作成することで、そのスコープが元の承認を超えて拡張されます。

最初のアプローチは一つの動作をパッチします。二番目はエージェントに状況のモデルを与えます。

これにより、近隣の質問についても推論できます：午前3時に通知を送るべきか？ユーザーが明示的に要求していないフォローアッププロセスを作成すべきか？元の実行のスコープを超えるものを変更すべきか？

ルールは不要です。エージェントが自分で解決しました。

多くのチームは、実際にはコンテキストが必要なときにコントロールに頼ります。

同じ区別がプロンプト内にも現れる

これはシステムレベルの施行だけの話ではありません。コンテキスト対コントロールの区別はプロンプト内にも存在します。

コンテキスト型プロンプティング： ほぼ事実、最小限の意見：

スケジュールされたタスクによって実行されています。 北京時間午前3時にトリガー。 タスクID：sched_29x8f。 ユーザーは特定のスコープのためにこの実行を承認しました。

コントロール型プロンプティング： 意見的、規範的：

スケジュールの作成を避ける。 ツールXでユーザーに通知すべき。 Zでない限りYは絶対にしない。

時には規範的な指示が有用です。しかし非常に多くの場合、それらは欠落した事実を補っています。そしてそのように補い始めると、それが習慣になります。

プロンプトが官僚主義になる方法

これがより深い失敗モードです。

チームが問題を見つけてルールを追加します。次に別のルール。さらに別のルール。それぞれがローカルな問題をパッチしますが、一緒になるとプロキシで満たされたシステムを作ります。

ベゾスは2016年の株主書簡でこのパターンを説明しました：良いプロセスはあなたが顧客に奉仕できるように奉仕します。しかし注意しないと、プロセス自体が目的になります。

それがエージェントシステムで起こっていることです。

ルールは目的ではありません。ルールはあなたが望む結果のプロキシです。そしてプロキシは積み重なります。一つがさらなるルールを必要とするエッジケースを生み出します。やがてエージェントは、誰もが完全には覚えていない歴史的な理由で追加された、蓄積された指示の層を通じて推論しています。

人間の組織では、これは官僚主義になります。エージェントシステムでは、瘢痕組織で満ちた巨大なプロンプトになります。

事実は老いる。意見は腐る。

「この実行は午前3時にスケジュールされたタスクによってトリガーされた」という事実は安定しています。それを読むモデルに関係なく真実であり続けます：Claude、GPT、Gemini、来四半期に出るものでも。

「サブスケジュールの作成を避けるべき」という記述は脆弱です。解釈に依存します。ある状況では助けになり、別の状況では静かに失敗する可能性があります。

モデルを切り替えると、プロンプト内のすべての意見が潜在的な地雷になります。新しいモデルは異なる推論傾向を持ち、慎重に調整した「避ける」が全く異なることを意味する可能性があります。

しかし、環境、権限、スコープ、制約に関する根拠のある事実は、モデルやエッジケースにわたって一般化する傾向があります。だからこそ事実はより良い構築材料です。

モデルの癖トラップ

これがコントロール問題の最も陰湿なバージョンかもしれません：チームは常にモデルの一時的な欠陥を永続的なシステム構造に変換します。

モデルがある狭いケースで悪く振る舞います。チームはガードレールを追加します：プロンプトパッチ、コードチェック、一つの特定の失敗モードを止めるためだけに存在する奇妙な分岐。

そのパッチは、癖が持続するという賭けです。ほとんど持続しません。

三ヶ月後、モデルが変わります。元の動作が消えます。しかしパッチは残ります。誰も削除したくありません、なぜならそこに理由があったかもしれないから。

これがシステムプロンプトがレガシーコードになる方法です。

抽象的に述べると危険を簡単に認識できます。しかし実際には、プロンプトでSonnetの現在の推論傾向をパッチし続けることは、変装した同じパターンです。

安定したシステム動作を文書化することは価値があります。モデルの推論傾向をパッチすることはトレッドミルです。 モデルはパッチを維持できるよりも速くあなたの下で変化します。

良いテストケース：権限拒否

ツール診断で区別を明確に見ることができます。エージェントが権限エラーに遭遇したとき：

コントロール型：

TOKENが見つかりません。修正するには「zero permissions request gmail.send」を実行してください。

直接的ですが、エージェントは何も学びません。次に異なる権限エラーに遭遇したとき、行き詰まります。

コンテキスト型：

process.env.GMAIL_TOKEN → 存在する zero connectors inspect gmail → 接続済み zero permissions inspect gmail.send → 拒否

オプション：

1. gmail.sendのユーザー承認をリクエスト
2. 既に承認されたパスが存在する場合はそれを使用

エージェントはトークンが存在し、コネクターが機能し、特定の権限が拒否されていることを知りました。システムの状態を理解し、ルール作成者が予測しなかった新しい状況について推論できます。

ヒューリスティック

私がいつも戻ってくることがこれです：

プロンプトで「しない」「避ける」「絶対にしない」を書こうとしているとき。止まってください。尋ねてください：このルールはどんな事実を補っているのか？

通常、欠落した事実があります。エージェントはどんな環境にいるか、ユーザーが何を承認したか、どのアクションが不可逆か、このランが通常のチャット対話とどう違うかを理解していません。

その事実を書き留める。ルールを削除する。

時には制約がまだ欲しい場合があります、特に破壊的なアクション、金の動き、安全境界の周囲。ハードコントロールはまだ重要です。

しかし多くのプロンプトルールは真の境界ではありません。それらは欠落した理解の補償です。そしてそれらは積み重なって腐ります。

目標

目標はチェックリストを暗記するエージェントではありません。

目標は、明確な境界内で良い決定を下すのに十分なほど自分の状況を理解するエージェントです。

一つの哲学はルールを積み重ねることで動作を制御します。もう一つは世界を読みやすくすることで動作を改善します。

最初は官僚主義に向かう傾向があります。二番目は理解に向かう傾向があります。

コンテキストを構築する。瘢痕組織を削除する。考えることができるエージェントをリリースする。