エージェント設計は依然として難しい

 (lucumr.pocoo.org)
20 ポイント 投稿者 GN⁺ 2025-11-23 | 1件のコメント | WhatsAppで共有
  • エージェント構築プロセスは依然として複雑で、SDKの抽象化が実際のツール利用段階でしばしば破綻する問題がある
  • キャッシュ管理はプラットフォームごとに異なり、手動管理のほうが予測しやすく効率的で、Anthropic SDKの明示的なキャッシュポイント方式が好まれる
  • 強化ループ(reinforcement loop) は作業状態の追跡と失敗からの復旧で重要な役割を果たし、失敗は別途隔離してループ崩壊を防ぐ必要がある
  • 共有状態管理のためにファイルシステムに似た階層が重要であり、コード実行・推論ツール間のデータ交換の基盤構造として使われる
  • 出力ツールとモデル選択は依然として扱いが難しく、Haiku・Sonnet・Geminiモデルが主要な選択肢であり続けるなど、エージェント設計の複雑さは続いている

エージェントSDKの選択

  • エージェントを構築する際、OpenAI、Anthropicなどの基本SDKを直接使うか、Vercel AI SDKやPydanticのような高水準の抽象化レイヤーを使うかを選ぶ必要がある
    • 筆者は過去にVercel AI SDKのprovider abstractionだけを使っていたが、今ならその選択を繰り返さないだろうと述べている
  • モデル間の差が大きいため、エージェントの抽象化レイヤーを自前で構築する必要があり、既存SDKの抽象化は適していない
    • キャッシュ制御、強化要件、ツールプロンプトなどに微妙な違いがある
  • Vercel SDKはprovider-sideのツール処理で問題が発生する
    • AnthropicのWeb検索ツールがメッセージ履歴を破損させるケースがある
    • Anthropic SDKを直接使うと、キャッシュ管理とエラーメッセージがより明確になる
  • 結論として、現時点では抽象化レイヤーなしで直接SDKを使うアプローチのほうが有利だと評価している

キャッシュ管理の教訓

  • プラットフォームごとにキャッシュへのアプローチが異なり、Anthropicはキャッシュに料金を課し、明示的な管理を求める
    • 手動管理のほうがコストとキャッシュ活用度を予測しやすくするため好まれる
  • 明示的キャッシュは会話の分岐実行やコンテキスト編集を可能にする
    • システムプロンプトの後、会話の序盤などに複数のキャッシュポイントを設定する
  • キャッシュを維持するため、システムプロンプトとツール選択は静的にし、時間などの動的情報は後続メッセージで渡す
  • 強化ループをキャッシュと組み合わせて積極的に活用し、コスト予測性と制御性を向上させる

エージェントループ内の強化(Reinforcement)

  • ツール実行時、単に結果を返すだけでなく、目標・作業状態・失敗原因などの情報をループに再注入できる
  • Claude Codeのtodo writeツールのように、自己強化(self-reinforcement) ツールがループ進行に役立つ
  • 環境変化や失敗復旧のタイミングで状態変更情報を注入し、ループの安定性を確保する
    • 例: 破損したデータを基に再試行する場合、前の段階に戻すようメッセージを挿入する

失敗の隔離(Isolate Failures)

  • 反復的な失敗が予想される作業はサブエージェント(subagent) として分離実行し、成功結果だけを上位ループに報告する
    • 失敗試行の要約は次の作業の学習資料として活用する
  • Anthropic SDKではコンテキスト編集(context editing) 機能で失敗記録を削除できる
    • 失敗情報全体を保持せず、必要な部分だけを残す
    • ただし、コンテキスト編集はキャッシュ無効化を招き、コスト増につながる可能性がある

サブエージェントと共有ファイルシステム

  • ほとんどのエージェントはコード実行・生成ベースであり、共通のデータ保存先が必要
    • そのため仮想ファイルシステム(VFS) を使う
  • 画像生成、圧縮、推論などさまざまなツールが同じファイルパスを共有する必要がある
    • ExecuteCodeとRunInferenceツールが同じファイルシステムにアクセスできなければならない
  • こうした構造はデータ交換のボトルネック解消とループ内の連続作業処理に不可欠である

出力ツール(Output Tool)

  • エージェントはチャットセッションではなく非公開の内部メッセージループで動作し、外部とのやり取りは出力ツールを通じて行う
    • 出力ツールはメール送信などの外部コミュニケーションを担う
  • 出力ツールのトーン・文体の制御が難しく、補助LLM(Gemini 2.5 Flash)を使うと品質低下や遅延が発生する
    • 下位ツールが十分なコンテキストを持てず、不正確な結果を生成する
  • ループ終了時に出力ツールが呼び出されなければ、強化メッセージを挿入して呼び出しを促す

モデル選択

  • HaikuとSonnetはツール呼び出し性能に優れ、主要なループモデルとして使われる
  • Gemini 2.5は大規模文書の要約、PDF処理、画像情報抽出に適している
    • Sonnetモデルには安全フィルタに頻繁に引っかかる欠点がある
  • GPT系モデルはメインループで大きな成果がなかった
  • トークンコストだけでは全体コストを判断できない
    • より優れたツール呼び出しモデルなら、少ないトークンで同じ作業を実行できる

テストと評価(Evals)

  • エージェントのテストと評価の自動化が最も難しい問題として挙げられる
    • プロンプトと違って、外部システム上で単純に評価することができない
    • 実際の実行データに基づく観測可能性(observability) または計測(instrumentation) が必要
  • 現時点では満足のいく評価方法を見つけられていないと述べている

コーディングエージェントのアップデート

  • コーディングエージェントに関する変化は大きくない
    • 最近は**Amp** エージェントを試しており、Oracleサブエージェントとメインループの相互作用構造を高く評価している
  • AmpとClaude Codeは自前のツールを実際に使う開発者中心の設計に感じられる

関連記事

1件のコメント

 
GN⁺ 2025-11-23
Hacker Newsのコメント

  • 約2年前にこの分野で会社を創業し、今は順調に運営している。
    この2年間で学んだのは、多くの手法はLLMの現在の限界を補うための一時的な最適化だということ。技術の進歩が速いため、今日の問題は明日には消えている。
    以前、AWSにディスク暗号化機能がなかった頃、チームで自前実装に3か月を費やしたが、直後にAWSがワンクリックの標準暗号化をリリースした。結局は時間の無駄だった。
    だから学んだのは、ときには何もしないのが最善なこともあるということ。

    • これが核心的な洞察だと思う。最近は会社の同僚がAIワークショップを開いて新しいパターンを「発明」したと言っているが、その大半は来週には時代遅れになる。
      昔のように共通言語としてパターンを学ぶ時代は終わり、今ではAIパターンの半減期は1週間ほどだ。しかも「agent」とは何かを専門家10人に聞けば、10通りの答えが返ってくる。
    • AIの進歩速度を見ると、十分に待てば結局OpenAIを直接使うことに行き着くかもしれない。
    • 売上が運営費を上回る黒字構造なのか気になる。agentで収益を出すのは難しいと思っていたので、秘訣が知りたい。
    • 「何もしない」をうまく判断できるのは、チームが扱う問題が本質的なものか、周辺的な問題かを評価する能力に関わっている。
    • 同意する。今は待つことも戦略になりうる。ただ、待ちすぎるとAGIが出るまで何もしなくなる罠にはまることもある。

  • この2年間でさまざまなagent SDKを使ってきたが、自分で作ってみると想像以上に複雑だった。
    Claude Code SDK（現Agent SDK）は素晴らしいが、まだClaude Codeとの結合が完全には分離されていない。たとえばskillsはファイルシステムに直接配置する必要がある。
    OpenAI SDKはプラットフォームとの強い統合によりダッシュボードで自動追跡・評価ができるが、サードパーティーモデルとの連携が難しい。
    Google Agent KitにはまだTypescript SDKがなく、Mastraはサーバーを立てる必要があるので不便だ。
    今はSmythOS SDKを試しているが、モデルプロバイダーの選択やアーキテクチャ定義の自由度が高い。
    今使っている構成がAgent → SubAgents → SubSubAgentsなのか、それともPlanner-Executor型なのか気になる。

    • ほとんどのSDKは基本機能を超えた途端に悪夢になる。だからOpenRouterクライアントライブラリを使って自前実装している。
      コード量は増えるが、メンタルモデルが単純なのでずっと理解しやすい。ReAct方式でループを回し、reasoningとtool呼び出しを繰り返している。
      結局、SDKなしでもagent handoffやワークフローを自分で実装できる。
    • 「sub-agent」という用語はほとんど役に立たないと思う。結局はtool呼び出しを抽象化したものにすぎず、メインループの外では単なる入出力契約だけが重要だ。
    • Claude CodeはAnthropicモデルしかサポートしていないと言われていたが、Claude Code Routerを使えば他のモデルも連携可能だ。
    • Google ADKのGo版を使っているが、まだ未成熟ではあるものの、ワークフロー構成とベンダー互換性が良くて満足している。
    • AWSのStrands Agents SDKも使ってみたが、Bedrockなしでも主要ベンダーAPIをサポートしていて、APIデザインが非常に柔軟だ（AWS社員だが個人の意見）。

  • 私たちが学んだagent設計原則をいくつか共有する。

    1. コード生成が多いならClaude Code / Agent SDKが最も効率的。
    2. ベンダーロックインより大きなリスクは、ChatGPTより劣る製品を作ること。
    3. Claude Codeは自己認識に優れており、自分自身についての質問にはすぐ正確に答える。
    4. agentに実際のコンピュータを与えると、はるかに強力になる。私たちはe2b.devを使っているが、Modalも良い。
      参考までに、私たちの会社Definiteはデータプラットフォームで、HerokuのようにAIデータエンジニアが運用している。
    • Claudeは創造的だが、複雑なコードベースでは虚偽回答やreward hackingをすることがある。そういう場合はCodexのほうが安定している。
    • 多くの製品がChatGPTのWeb版より低品質なまま出荷されているのが問題だと思う。
    • わざわざ独自のagentシステムを作るより、Claude Codeのような完成度の高いツールを活用して、本当の価値を生むことに集中すべきだ。
    • もちろん「全部ビッグテックに任せよう」というのは危険だ。自分で作って学び、共有する過程が重要だと思う。自分もADKとVS Code拡張で急速に成長している。

  • 数年にわたってagentを作ってきたが、最も良かったのは自前のフレームワークを構築したことだった。
    いろいろなオープンソースの抽象化レイヤーはSDKの変化に応じて維持不能になり、結局崩れていく。

    • 私も同感だ。Agentの核心は構造化された入出力、toolの登録と呼び出しループ、そしてagent間の委任だ。
      PydanticAIベースのOpusAgentsを作ったが、MCPサーバーより単純で、しかも拡張性のあるオープンソースフレームワークだ。
    • 筆者として同意する。関連する考えはこの投稿にまとめた。
    • 私たちも顧客サポート用チャットボットを作る際、従来の構造の代わりにchatroomベースのアーキテクチャを導入した。フロントエンドは単にメッセージを投げ、バックエンドで機能を段階的に拡張していく。
    • ただし、完全なフレームワークを自作するのは大きな作業だ。長期的にはagentプラットフォームがゲームエンジンのように標準化される可能性が高い。

  • 最近はLangChain/RAG初期のような過剰な抽象化と複雑さが繰り返されている。
    結局agentは単純なREPL構造（Read, Eval, Print, Loop）として考えればいい。
    この考え方で自分で実装した軽量版は、重いSDKよりずっと安定していた。

    • ただ、実際に複雑なユースケースでは特化したsubagentとデータ共有構造が必要になってくる。単純なループだけでは限界がある。

  • agentの**テストと評価（evals）**が最も難しい問題だ。
    外部システムで評価するには入力が多すぎるし、実行中のデータを観察しなければならない。
    どんなアプローチが有効なのか、まだ確信が持てない。

    • AI agentのデプロイの多くが形式的なテストなしで「勘」に頼っているように見えて心配だ。
    • GoogleのADK評価ドキュメントを見ると、実行ごとに結果が変わるため、合格/不合格の基準を決めにくいとある。結局は別のLLMで評価することになる。

  • agent開発では基本的な部分でさえ明確なガイドラインが不足している。
    たとえば関数toolの入出力型の扱いでは、数値IDを渡すとシリアライズエラーや精度損失が発生する。
    結局、文字列に変換する形で対処した。
    OpenAIのドキュメント（リンク）とGoogle ADKのissue（リンク）を見ると、
    「結果は文字列であるべき」と書かれている一方で、実際の例ではdictや数値を返している。こうした不一致が混乱を招く。

  • 私はあるagentic coding企業の製品を使っている（名前は明かさない）。
    モデルリリースや評価、サブエージェント管理、課金まで全部任せてただ仕事に集中できるので満足している。

    • たぶんその会社はSourcegraphのAmpだと思う。初期は荒削りだったが、今はかなり完成度が高い。

  • この2か月、さまざまな作業用agentを実装してきた。最初はClaude Codeを使っていたが、ベンダーロックインと利用制限のため自前のランタイムを作った。
    現在はOpenAIのみ対応しているが、ClaudeやGeminiも追加できるように設計している。
    オープンソースで公開しているので参考になるかもしれない → agent-composer

  • 私のコツはシンプルだ。SDKは使わず、自分でwhileループを回してJSONを扱えということ。
    コンテキストサイズやエラーを自分で制御してこそ、本当に柔軟なagentを作れる。