マネージドなエージェントフレームワークはコントロールとスピードを交換するものであり、その取引はそれが価値を失う日までは価値がある。Amazon Bedrock Agentsはあなたに代わってreason-actループを実行してくれる。計画を立て、どのツールを呼ぶかを決め、それを呼び出し、結果をモデルに戻し、タスクが完了するまでそれを繰り返す。それはあなたが書かずに済む本物の仕事だ。問題は時間を節約できるかどうかではない。それが隠している部分が、あなたが見えなくなっても構わない部分かどうかだ。

正直な見方をすれば、「自前で作る」と「フレームワークを使う」は成熟度の階段ではない。それは、ループのどれだけをコントロールし、どれだけをメンテナンスするかのトレードオフだ。どちらがより本格的に聞こえるかではなく、アプリケーションが実際にどれだけのコントロールを必要とするかで選ぶべきだ。

マネージドループが実際にやってくれること

エージェントループは見た目以上にコードの塊だ。会話の状態機械を維持し、モデルの出力からツール呼び出しリクエストをパースし、それをディスパッチし、不正な呼び出しやタイムアウトを処理し、結果を正しいフォーマットで戻し、タスクがいつ完了したかを判断し、行き詰まったモデルが永遠にループしないように停止条件を強制する。Bedrock Agentsはこれらすべてを引き受ける。OpenAPIスキーマかLambdaでツールを定義し、検索用にナレッジベースをアタッチし、指示を設定すれば、サービスがオーケストレーションを駆動する。

質問に答え、いくつかの明確に定義されたツールを呼び、ナレッジベースから取り出すという標準的な形であれば、これは膨大な量の、差別化要因にならない配管作業を飛ばせるということだ。あなたのエージェントが一般的なケースに当てはまるなら、フレームワークが正しい選択であることは明白だ。

フレームワークがあなたを支配し始める場所

マネージドループのコストは、ループこそがあなたの最も難しい要件が宿る場所であり、そこに手を伸ばせないということだ。

  • カスタムな制御フロー。フレームワークがモデル化していない条件分岐、タスク途中での人間による承認ゲート、「まずツールAを試し、ある種の失敗をした場合のみBにフォールバックする」といったものが必要なら、あなたは抽象化と戦うことになる。手間を省いてくれていたループが、今度は必要な振る舞いとあなたの間に立ちはだかるものになる。
  • コンテキストとトークンのコントロール。各モデル呼び出しに何が入るかを完全にはコントロールできない。履歴を積極的に切り詰めたり、取得したコンテキストを正確な位置に注入したり、ステップごとのトークン予算を管理したりする必要があるとき、マネージドループの選択はあなたが変更するものではなく、受け入れて生きるものだ。
  • 推論への可観測性。エージェントがなぜあるツールを選んだのかをデバッグするには、正確なプロンプト、正確なツールの出力、正確な次の判断を見る必要がある。中間ステップを隠すフレームワークは、デバッグ可能なシステムを推測ゲームに変えてしまう。
  • レイテンシとコストのチューニング。安いステップは小さなモデルに、難しいステップはフロンティアモデルにルーティングすること、積極的にキャッシュすること、ステップごとの出力量に上限を設けること。これらはすべてループの内側に存在する。ループに触れられなければ、これらをチューニングすることはできない。

脱出ハッチのテスト

どんなエージェントフレームワークにもコミットする前に、一つのテストを行う。脱出ハッチを見つけることだ。フレームワーク全体を放棄せずに、それを必要とする1つのステップだけ低レイヤーに降りることができるか。優れた抽象化なら、1つのツール呼び出しをオーバーライドしたり、生のプロンプトを検査したり、残りはフレームワークに任せつつループの1ステップだけを手書きしたりできる。悪い抽象化はオール・オア・ナッシングで、フレームワークが対応していない最初の要件が完全な書き直しを強いる。

正直な答えが「必要なことをするにはフレームワークを完全に離れなければならない」なら、そのフレームワークはあなたの手間を省いていない。書き直しを最も不便なタイミングに先送りしているだけだ。それを1日目に知っておくほうが、インシデントの最中に知るよりずっといい。

実際に使える判断基準

  • Bedrock Agentsを使うのは、エージェントが標準的なreason-act-retrieveの形をしていて、ツールが明確に定義されていて、オーケストレーションコードを所有するよりも出荷を優先したい場合だ。ほとんどのライン・オブ・ビジネス系エージェントはまさにこれに当てはまる。
  • 自前のループを書くのは、制御フロー、コンテキスト管理、ステップごとのモデルルーティング、深い可観測性が「あれば嬉しい」ではなく中核的な要件である場合だ。ループがあなたのプロダクトなら、ループを所有すべきだ。
  • いずれの場合も、境界は外側に保つ。認可と最小権限は、誰がループを所有していようと、エージェントの推論の内側に属するべきではない。今月初めに一般提供が始まったAmazon Bedrock AgentCoreのPolicyは、エージェントのコードの外にあるルールに照らして各エージェントからツールへの呼び出しを評価する。つまり、ガードレールを書き直すことなくフレームワークを変更できるということだ。

結論

Bedrock Agentsはエージェントループを実行するという、本物で面倒な仕事を取り除いてくれる。一般的なケースであればそれは正しい取引だ。あなたの最も難しい要件、カスタムな制御フロー、精密なコンテキストコントロール、深い可観測性、ステップごとのチューニングがループの内側に宿った瞬間、それはあなたを支配し始める。まず脱出ハッチを見つけることで判断する。誰がループを実行していても選択が可逆であるように、認可は外側に保つこと。

次に読む

本番環境でエージェントを運用するプラットフォームとインフラの視点については、クラウドのフィールドノートがercan.cloudにあり、ハブはercanermis.comにある。