回答から実行へのシフト
ここ数年、私たちのほとんどは、言語モデルをとてもよく読んだ同僚のように捉えてきました。質問します。答えが返ってきます。次に何が起こるかはあなた次第です。そのやり方は静かに置き換えられつつあります。今面白いのは、モデルに「正しいことを言わせる」ことではありません。「本当の道具」を使い、何手にもわたって、しかも最初の計画が現実に触れた瞬間にたいてい崩れるようなごちゃごちゃした環境の中で「正しいことをする」仕組みを作ることです。
これがエージェント型エンジニアリングが目指すものです。モデルが単に文章を生成するだけでなく、行動し、結果を見て、目標に到達するまで次に何をするかを決めるようなシステムを設計し、構築し、運用するための規律です。モデルは依然として中心にありますが、今ではそれはより大きな機械の中の一要素であり、実際の難しさの大半はその周囲のあらゆるものにあります。
シフトが重要なのは、必要なスキルが違うからです。プロンプトを書く技術は、巧みな言い回しを報酬として与えます。エージェント型エンジニアリングは、ソフトウェアを信頼できるものにしてきた従来からの要素を報酬として与えます。つまり、明確なインターフェース、優れた観測性（オブザーバビリティ）、失敗への筋の通った対応、そして出荷したものと学んだことの間の密なループです。唯一、本当に新しい要素は、その中心に座する予測不能な成分です。
エージェントとは実際には何か
「エージェント」という言葉は、ほぼ何にでも当てはめられてしまうので、正確に捉える価値があります。エージェントとは、固定の台本に従うのではなく、自分が観測する内容に基づいて繰り返し行動を選ぶことで目標を追うシステムです。決定的な特徴は知能ではなくループです。サーモスタットはルールに従います。エージェントは決めるのです。
自律性（オートノミー）を「ある／ない」ではなく「スペクトラム」として捉えると役に立ちます。端のほうには、メールを分類するだけの単一モデル呼び出しがあります。もう少し先に進むと、複数の呼び出しを固定順でつなぐワークフローがあり、これは役に立ちますが、それでも台本どおりです。さらに先では、モデルがどのツールをいつ呼ぶかを選び、作業が終わったと判断するまで続けます。最果てでは、システム自身がサブゴールを設定し、自分のメモリを管理し、何時間も動き続けます。今日のほとんどのプロダクションシステムはその中間のどこかに位置しており、たいていそれが正しい場所です。なぜなら、完全自律性こそが本当に問題が必要とするもの、ということは稀だからです。
このスペクトラム上で自分のシステムがどこに位置するかを早い段階で決めるのは、最も明確化をもたらす行為の一つです。モデルの判断にどれくらい寄りかかれるのか、どれくらいの構造を強制する必要があるのか、そしてリスクがどこに集中しそうかが分かります。
エージェントのループ
フレームワーク名やマーケティングを取り払うと、ほとんどのエージェントは同じループを回しています。自分の状況に関する文脈を集め、何をすべきかについて考え、行動し、何が起きたかを観測します。そして、いま得た学びを使って、目標に到達するか、諦めるまで同じことを繰り返します。
このループを一巡するたびに、それは意思決定の節目であり、意思決定の節目こそが、物事がうまくいく／うまくいかないの分かれ目です。良いエージェントループとは、最も巧いプロンプトを持つものではありません。各段階が、健全な選択をするのに十分なだけの情報を持っていて、それ以上は持たないものです。モデルに起きたことすべての履歴を丸ごと渡すと、筋が切れます。多すぎてもダメで、少なすぎてもダメで、モデルは盲目に行動します。どのターンでモデルに何を見せるかを決めることにこそ、職人技の多くが詰まっています。
また、このループは、エージェントを作ると普通のソフトウェアと「とても違って感じる」理由も説明します。普通のコードなら、あらゆる経路を考え抜けます。ここではモデルが、あなたが想像もしなかった経路を選ぶことができます。あなたが計画していないやり方でエラーから回復することもできます。3手先くらいまではそれっぽく見える方向にふらっと向かい、その後崩れ去ることもあります。あなたは経路そのものを書いていません。あなたは、あり得る経路の空間を形作っていて、良い経路が見つけやすい状態にしようとしています。
エージェントの構造
エージェントを、各々が一つの仕事をする小さな部品の集合として捉えると分かりやすくなります。理由づけと言語を供給するモデルがあります。ツールがあります。これはシステムが世界に作用し、そこから読み返すためのものです。メモリと文脈があります。これは関連情報を各意思決定に持ち込みます。そして、それらすべての周囲にあるオーケストレーションがあり、ループを回し、制限を課し、いつ止めるかを決めます。
これらをいくつか作ってみると、際立ってくるのは、難しい作業のほとんどがモデルそのものに関することではない、という点です。モデルは基本的に固定の選択です。1つ選んで、プロンプトを与えて、次に進みます。エンジニアリングの労力は、それを取り巻く部品に向かいます。良いツール、良い文脈の扱い、良いオーケストレーションがあって初めて、1回きりで動くデモと、ずっと稼働させ続けられるシステムが分かれます。プロンプト文の言い回しにこだわり、それ以外をないがしろにするチームは、火曜に見栄えよく動くものを作りますが、金曜には壊れている傾向があります。
ツールと文脈が本当の表面
ループが骨格だとすると、ツールと文脈は、実際にエンジニアリングが起きる場所です。
ツールはモデルの手です。エージェントがデータベースを読み取る方法、メッセージを送る方法、クエリを実行する方法、ファイルを移動する方法です。あなたのツールの品質が、エージェントができることに対する上限を決めます。さらに、ツール設計自体がそれ自体でクラフト（職人技）になることが分かります。良いツールは、1つの明確なことをするだけです。名前と説明があり、モデルに「いつそれを取りに行くべきか」を正確に伝えます。入力を検査し、行動しやすい形で結果を返します。説明が曖昧で、何をするツールなのかが分からないツールは、ツールがまったくないよりも悪いです。モデルは自信満々に不正確にそれを使ってしまうからです。能力のある新しい同僚に対してインターフェース設計で払うであろう注意と同程度の注意が、ツールにも必要です。なぜなら、だいたい同じ状況だからです。
文脈はもう半分です。モデルが知っているのは、自分の目の前に置かれたものだけなので、毎ターン、あなたは静かな問いに答えています。「今、うまく選ぶために、モデルは何を見ている必要があるのか？」ここから「コンテキストエンジニアリング」という言葉が生まれ、この分野の中心課題の1つになりました。素朴なアプローチは、ウィンドウにもっと詰め込む、もっと履歴を入れる、もっとドキュメントを入れる、もっと指示を入れる、というものです。これはスケールしません。
