エージェントエンジニアリング：新たな分野

エージェントを構築した経験のある方なら、「自分のマシンでは動く」けれど「本番では動かない」というギャップがいかに大きいかをご存じでしょう。従来のソフトウェアは入力がおおむね既知で出力を定義できることを前提としていますが、エージェントはそのどちらも与えてくれません。ユーザーは文字通り何でも言えますし、可能な振る舞いの空間は広大です。だからこそエージェントは強力であり、同時に予期せぬ方向に逸れる可能性もあるのです。

過去3年間、私たちは何千ものチームがこの現実に苦闘する様子を見てきました。Clay、Vanta、LinkedIn、Cloudflareといった企業のように、信頼性の高いシステムを本番環境に提供することに成功したチームは、従来のソフトウェアの手順書に従うのではなく、新しい分野であるエージェントエンジニアリングを開拓しています。

エージェントエンジニアリングとは何でしょうか？それは、非決定論的なLLMシステムを反復的なプロセスを通じて信頼性の高い本番体験へと洗練させる手法です。そのサイクルは、構築、テスト、出荷、観察、改善、そして繰り返しです。ここで重要なのは、出荷が最終目標ではないということです。出荷は、新たな知見を得てエージェントを改善するための手段にすぎません。このサイクルを速く回せば回すほど、エージェントは信頼性を増します。

エージェントエンジニアリングは、3つのスキルセットを組み合わせた新しい分野だと私たちは考えています。プロダクト思考はスコープを定義しエージェントの振る舞いを形成します。これには、エージェントの動作を駆動するプロンプトの作成（多くの場合数百から数千行）、エージェントが再現すべき「ジョブ」の深い理解、そしてそのジョブが意図通りに実行されているかを評価する評価指標の定義が含まれます。エンジニアリングは、エージェントを本番対応にするインフラを構築します。具体的には、エージェントが使用するツールの作成、ストリーミングや割り込み処理を含むUI/UXの開発、耐久性のある実行やヒューマンインザループの一時停止、メモリ管理を扱う堅牢なランタイムの構築などです。データサイエンスは、時間の経過とともにエージェントのパフォーマンスを測定し改善します。これには、評価システム（評価セット、A/Bテスト、モニタリングなど）の構築、使用パターンやエラー分析（エージェントは従来のソフトウェアよりもユーザーの利用範囲が広いため）が含まれます。

実際のチームでは、エージェントエンジニアリングは新しい職種としてではなく、既存のチームが非決定論的なシステムを構築する際に引き受ける一連の責任として現れます。ソフトウェアエンジニアやMLエンジニアはプロンプトを作成しツールを構築し、エージェントが特定のツールを呼び出した理由をトレースし、基盤モデルを改善します。プラットフォームエンジニアは耐久性のある実行やヒューマンインザループワークフローを処理するエージェントインフラを構築します。プロダクトマネージャーはプロンプトを作成し、エージェントのスコープを定義し、正しい問題を解決しているかを確認します。データサイエンティストはエージェントの信頼性を測定し、改善の機会を特定します。これらのチームは迅速な反復を受け入れ、ソフトウェアエンジニアがエラーをトレースしてPMに引き渡しプロンプトを微調整したり、PMがスコープの問題を特定してエンジニアに新しいツールを要求したりします。それぞれが、エージェントを堅牢にする本当の作業は、本番の振る舞いを観察し、そこから学んだことに基づいて体系的に改善するこのサイクルの中で行われることを認識しています。

なぜ今エージェントエンジニアリングが必要なのでしょうか？2つの根本的な変化がそれを必要としています。第一に、LLMは複雑で多段階のワークフローを処理できるほど強力になりました。Clayはエージェントを使って見込み客の調査からパーソナライズされたアウトリーチ、CRMの更新まですべてを処理しています。LinkedInはエージェントを使って膨大な人材プールをスキャンし、候補者をランク付けして最適なマッチを即座に提示しています。私たちは、エージェントが本番で意味のあるビジネス価値を提供する閾値を越え始めています。第二に、その強力さには本当の予測不可能性が伴います。単純なLLMアプリは非決定論的であっても、比較的行動が制限されています。エージェントは違います。複数のステップにわたって推論し、ツールを呼び出し、コンテキストに基づいて適応します。エージェントを有用にするのと同じ特性が、従来のソフトウェアとは異なる振る舞いを引き起こします。具体的には、すべての入力がエッジケースとなる、従来の方法でデバッグできない、「動作している」が二値ではない、といったことです。

実践において、成功しているエンジニアリングチームは次のような開発リズムに従っています。エージェントの基盤を構築し、想定できるシナリオに基づいてテストし、実際の振る舞いを見るために出荷し、すべてのインタラクションをトレースし、本番データで評価を実行し、失敗のパターンを特定したらプロンプトやツール定義を修正し、それを繰り返します。各サイクルは、ユーザーがどのようにエージェントと対話しているか、そして自分のコンテキストで信頼性が実際に何を意味するかについて、新たな教訓をもたらします。

信頼性の高いエージェントを出荷しているチームに共通するのは、ローンチ前にエージェントを完璧にしようとするのをやめ、本番環境を主要な教師として扱っていることです。すべての決定をトレースし、大規模に評価し、四半期単位ではなく日単位で改善を出荷しています。エージェントエンジニアリングが出現しているのは、チャンスがそれを要求しているからです。エージェントは今や、以前は人間の判断を必要としていたワークフローを処理できますが、それは信頼できるほど信頼性を高められる場合に限ります。近道はなく、体系的な反復作業があるだけです。問題は、エージェントエンジニアリングが標準的なプラクティスになるかどうかではありません。あなたのチームがそれを採用してエージェントの可能性を引き出すのがどれだけ早いかです。