AI Agent Tool のためのバックエンドアーキテクチャを考える #encraft

Transcript

1. AI Agent Tool のための バックエンドアーキテクチャを考える 2025-12-23 Encraft #22 @izumin5210
2. @izumin5210 © LayerX Inc. whoami LayerX バクラク事業部 (2022-09 -) Platform Engineering 部 Enabling チーム Staff Software Engineer バックエンドや Web フロントエンドが専門です AI は初心者 ISUCON14 4位 好きな AI SDK v6 の API は .toModelOutput()
3. 今日の話のスコープ © LayerX Inc. LLM / Agent を プロダクトに組み込む とき Backend は 何を単位に能力を提供するか 3
4. 変化の出発点 Before 利用主体が 人間・決定論コード After 利用主体が Agent Agent は 考えながらタスクを進める主体 © LayerX Inc. 4
5. 従来の AI 機能のバックエンドアーキテクチャ上の位置づけ © LayerX Inc. AI はリクエストツリーの 「葉」 に 単機能な complicated subsystem 呼び出し元がすべて決める AI は 制御フローを持っていなかった 5
6. AI Agent 機能のバックエンドアーキテクチャ上の位置づけ © LayerX Inc. AI が 制御フローに入ってくる 実行時に 分岐・再計画 ツリーの葉ではなく 根 / 節 に 6
7. AI Agent 機能のバックエンドアーキテクチャを考える © LayerX Inc. 7
8. Tool "a contract between deterministic systems and non-deterministic agents" "agents have different ways of perceiving the potential actions they can take" Tool = Agent に開放する、ユースケース・目的に合わせた操作 © LayerX Inc. Anthropic, 2025, https://www.anthropic.com/engineering/writing-tools-for-agents 8
9. Tool 設計と API 設計の違い 従来の API 設計 for Backend/Frontend 開発者・システム向け に書く Agent 向け Tool 設計 エージェントのため に設計する © LayerX Inc. メモリ豊富なシステムが相手 呼び出し側が手続きを組み立てる Limited context を持つ主体が相手 Agent がタスクを組み立てる Anthropic, 2025, https://www.anthropic.com/engineering/writing-tools-for-agents 9
10. シンプルなケース：単一ドメインのタスク © LayerX Inc. 単一ドメインの 意味あるタスク として Tool を呼ぶ 10
11. 複数ドメインにまたがる場合 © LayerX Inc. 複数集約・複数操作を 束ねたタスク Agent からは 1 回の Tool 呼び出し 内部では複数ステップが走る 11
12. 実装パターン © LayerX Inc. 2つのリソースを2つのツールで操作するような Agent 12
13. 1つのユースケースなら tool にまとめる © LayerX Inc. リソース指向な API とは違い、tool はユースケースごとに作る ユースケースとして1つなら、 tool は1つにしたほうが AI からすると使いやすい 13
14. 内部的には usecase 層が存在する（概念的にあるいは実際に） © LayerX Inc. 概念的には複数のドメインにまたがった操作する usecase 層が存在するイメージ 14
15. Agent を外に置く © LayerX Inc. バックエンドに利用している言語で AI 周りのエコシステムが不十分な場合、Agent 周り を別サービスに分けることも選択肢になる 15
16. Agent Tool 向けのユースケース指向 API を提供する © LayerX Inc. 「どの処理のかたまりでユースケースを構成するか」は Backend 側で持つほうが自然 かもしれない 16
17. 複数プロダクトにまたがる場合 © LayerX Inc. 複数のプロダクトにまたがるタスク 17
18. 複数プロダクトで1ユースケース © LayerX Inc. プロダクトが1つのときと同じく、ユースケースとして1つなら tool は1つに 18
19. ユースケースの集約層 - Backend for Agents 的なレイヤ © LayerX Inc. ユースケースを複数の Agent から利用するケースなどで、集約レイヤを設ける？ BFF(Backend for Frontend) に対して、Agent 向けの API 提供層… BFA(Backend for Agents)？ 19
20. 設計の分割軸 Tool の粒度：ユースケース単位で作る © LayerX Inc. リソース単位ではなく、ユースケース単位 サービスをまたぐ場合も同様 20
21. 設計の分割軸 Agent の配置：Backend 内か外か © LayerX Inc. Backend 言語の AI エコシステムの充実度 AI 周りの複雑さ・開発者の分離 21
22. 設計の分割軸 追加レイヤ：BFA（Backend for Agents） © LayerX Inc. 複雑な Agent / 複数 Agent から利用するケース Tool 向け API のレイヤを別途設ける 22
23. 設計は一つに定まらない 設計が1つに定まることはない（多分） © LayerX Inc. LLM / AI Agent は偏在しうる 多様な大きさのタスクで利用される 1つのリソースしか触れないかもしれないし、プロダクトをまたぐかもしれない タスクの規模にフィットした設計を選択していく 23
24. Agent が偏在する世界の設計 Agent は 特別な一箇所に閉じない © LayerX Inc. 小さな Agent 〜 大きな Agentic workflow どの規模のタスクにも Agent は登場しうる 多様なエンジニアが触る 24
25. Agent 遍在を前提にした基盤・概念 Tool 定義 Agent に何を 開放するか Durable Execution Human-in-the-loop を含む 処理の定義 および確実な実行 ... and more 必要なもの、準備していくものはまだまだたくさん！ © LayerX Inc. 25