Built Our Own Background Agent at LayerX #aidevex_findy

Transcript

1. Built Our Own Background Agent at LayerX 2026-07-23 AI DevEx Conference 2026 @izumin5210 / @itkq
2. whoami @izumin5210 LayerX バクラク事業部 (2022-09 -) Platform Engineering 部 Enabling チーム / Dev Infrastructure チーム Staff Software Engineer バックエンドや Web フロントエンドが専門 ISUCON14 4位 好きな GitHub org は github.com/vercel-labs © LayerX Inc.
3. whoami @itkq バクラク事業部 ソフトウェアエンジニア (2023-02 -) Platform Engineering 部 SRE チーム テックリード Amazon ECS / AWS Lambda を軸としたサービスインフラや Deploy / Terraform pipeline を主に担当 好きな設定言語は Jsonnet © LayerX Inc.
4. LayerX とバクラク
5. LayerX とバクラク 「すべての経済活動を、デジタル化する。」をミッションに、複合的な事業を通して日本の社会課題を 解決し、AI の力で人々の創造力がより発揮される未来をつくります。 © LayerX Inc.
6. © LayerX Inc. 6
7. LayerX とバクラク 「バクラク」のアーキテクチャ概要 AWS Cloud がメイン コンテナ・サーバーレス構成を積極 的に取り入れ、運用コストを最適化 GraphQL Gateway + Connect RPC Microservices monorepo © LayerX Inc. https://speakerdeck.com/layerx/bakuraku-engineering-team-deck
8. 本題
9. Ramp Builders Blog の影響 © LayerX Inc. https://builders.ramp.com/post/why-we-built-our-background-agent 9
10. 今日話すこと：Background Agent から Agent 基盤へ 01 | Background Coding Agent が欲しい PC を閉じても Coding Agent を並列・安全に動かすには？ 02 | Coding Agent 用の「環境」を模索 既製品の検証から自作の道へ 03 | 抽象がもう一段進む Coding はタスクの 1 つ、環境はパラメータの 1 つだった 04 | Agent 基盤のその先 作った基盤で、業務自動化を広げる © LayerX Inc.
11. 01 | Background Coding Agent が欲しい
12. 01 | Background Coding Agent が欲しい Agentic AI 時代の開発 Coding Agent (Claude Code, Codex, ...) と開発するのが当たり前になった 人間がコードを書く時間より、Agent がコードを書く時間のほうが長い すると、今までなかった「困り」が生まれてくる © LayerX Inc. 12
13. 01 | Background Coding Agent が欲しい 困り① PC を閉じると Agent が止まる 夜間も、移動中も、コードを書いていてほしい スリープしてもエージェントには動き続けていてほしい 24時間以上動くエージェントへの対応 © LayerX Inc. 13
14. 01 | Background Coding Agent が欲しい 困り② セキュリティ PdM などより多くの人が Agent でコードを書くようになる ローカルマシンに強い権限・秘密情報が集まる プロンプトインジェクションによる流出懸念 サプライチェーンリスク 依存パッケージ経由の悪意あるコードが「開発者の手元」で実行される時代 Agent が自律的にコマンドを実行するなら、実行環境を隔離したい （とはいえローカルマシンがガッチガチなのはちょっと…） © LayerX Inc. 14
15. 01 | Background Coding Agent が欲しい 困り③ リソース不足 git worktree による並列開発が当たり前になった 動作環境も並列すると → ローカルの CPU / メモリが足りない 並列化で顕在化した、AI 時代ならではの問題 © LayerX Inc. 15
16. 01 | Background Coding Agent が欲しい 困り④ 環境構築・再現性 開発環境ブートストラップのコストと再現性の問題 バクラクでは開発者も増え続けている aqua, mise, Nix など取り入れているが基本的には自由 「手元で動かない」は人間にも Agent にも等しくコスト © LayerX Inc. 16
17. 01 | Background Coding Agent が欲しい 困り⑤ AI 料金モデル サブスク「使い放題」の持続性懸念 Fable などフロンティアモデルの制限 Claude Agent SDK からは Max subscription の利用が制限される* 機密性の高い情報はサブスクリプションでは扱いにくい Enterprise plan API 従量課金への向き合い コスト管理・トークン最適化を自前でやる必要がある © LayerX Inc. * https://support.claude.com/en/articles/15036540-use-the-claude-agent-sdk-with-your-claude-plan 17
18. 01 | Background Coding Agent が欲しい 素直に解くと「リモートで動く Coding Agent」 PC から切り離す 閉じても動く 管理されたクラウド上の実行環境 セキュリティ リソース 再現性 LLM Gateway の統合 開発者の PC プロンプト リモート実行環境 🤖 Coding Agent • Keep running コスト管理 本当にやりたいことは別にあった © LayerX Inc. 18
19. 01 | Background Coding Agent が欲しい 当時から持っていたビジョン 「プロンプトを投げたら Agent が立ち上がり、自律的にタスクを遂行する」 「リモートで動く」は手段でしかない やりたいのは、Coding Agent を HTTP API で呼べる ようにすること HTTP API で起動できる → イベントドリブンに起動できる © LayerX Inc. 19
20. 01 | Background Coding Agent が欲しい 「単なるコーディング」の先 Linear や Notion の issue を勝手に取って開発させる 問い合わせの初動調査・対応の自動化 複数人のコラボレーション Lv1: Pull Request Preview の共有 → Lv2: Agent session の共有 「人間の操作」を起点にしない開発フローが作れるようになる © LayerX Inc. 20
21. 01 | Background Coding Agent が欲しい まず、既存製品を試した Devin Claude Code Action Codex Cloud 結局、このビジョンの土台にはできなかった © LayerX Inc. 21
22. 01 | Background Coding Agent が欲しい 足りなかったこと① 環境のお守り 開発環境のメンテナンスが大変 基本は monorepo だが、そうなっていないリポジトリもある リポジトリ側の変化に常に足並みを揃える必要があり、専用環境のメンテが 追いつかない © LayerX Inc. 22
23. 01 | Background Coding Agent が欲しい 足りなかったこと② 今までの Claude / Codex が使えない 製品組み込みの Agent がブラックボックス 社内に蓄積した skills などの資産が使えないことも 「決められた Agent しか使えない」は進化を阻む 開発者それぞれの試行錯誤による多様性は大事 (行動指針 Bet AI) © LayerX Inc. 23
24. 01 | Background Coding Agent が欲しい 足りなかったこと③ 過渡期のロックイン モデルも市場も、あらゆるものが過渡期 特定のモデルプロバイダ・特定製品へのロックインはリスクになりうる 今日のベストが半年後のベストである保証がない 年払いは怖い © LayerX Inc. 24
25. 01 | Background Coding Agent が欲しい 01 結論：欲しかったのは Agent より「環境」 与えられているべきは 環境 と デフォルトの Agent 環境さえあれば、手元の Coding Agent を ssh で繋いで作業させることもできる Claude Code / Codex / VS Code、どれも ssh 越しに使える 権限・秘密情報はリモート側に置いたまま、手元は繋ぐだけ 環境の上で好きなものを動かせる → 個人のチャレンジを妨げない © LayerX Inc. 25
26. 02 | Coding Agent 用の「環境」を模索
27. 02 | Coding Agent 用の「環境」を模索 環境を探す旅 v0 Codespaces devcontainer ベースで手軽に始めた ✘ Preview が実質的に使えない © LayerX Inc. → v1 Modal Sandbox 高速起動と Preview 機構が揃った Sandbox。 API で Agent を起動可能に ✘ VPC 外・gVisor 制約・24h 制限 → v1.5 Amazon EKS Managed Kubernetes 基盤へ。エコシステムを 活かしつつ、内製 Agent 基盤の土台に ✔ 環境を自分たちで掌握 27
28. 02 | Coding Agent 用の「環境」を模索 ― GitHub Codespaces 編 v0 ― GitHub Codespaces github.com を使っていればもっともお手軽 ベースは devcontainer devcontainer 自体は一般的な仕組み ここでの整備は後段でも資産になり、無駄にならない © LayerX Inc. 28
29. 02 | Coding Agent 用の「環境」を模索 ― GitHub Codespaces 編 GitHub Codespaces の壁：Preview が使えない Preview は当初から必須要件で考えていたが、 使い始めてから問題が発覚 認証つき URL は払い出せるが、CORS の Preflight Request が認証を通れない app と api が分かれている構成では Preview が実質使えない* → 撤退 © LayerX Inc. 🌐 Browser GET ✔ app-xxx.github.dev OPTIONS api-xxx.github.dev ✘ → 認証にリダイレクト ⚠ preflight が通らない * https://github.com/orgs/community/discussions/15351 29
30. 02 | Coding Agent 用の「環境」を模索 ― Modal Sandbox v1 ― Modal Sandbox Ramp の事例に影響を受け試した Sandbox の起動が高速 20 GB 近いイメージも十数秒で上がってくる Preview に必要な機構もある (Tunnel) © LayerX Inc. 30
31. 02 | Coding Agent 用の「環境」を模索 ― Modal Sandbox v1 の構成 Next.js でプロトタイプを実装 (Haro) Modal 内に hono の server を置き、外の Next.js から呼ぶ Temporal による Workflow 管理 WebUI HTTP Slack Next.js API Haro API 相当の単一の入口 Temporal Cloud agent turn / workspace lifecycle を管理 Modal Sandbox hono server + Claude Agent SDK の agent loop © LayerX Inc. 31
32. 02 | Coding Agent 用の「環境」を模索 ― Modal Sandbox ② PR 作成 (ツール実行許可) © LayerX Inc.① Slack で依頼 → Workspace 起動・Agent が仕事 32
33. 02 | Coding Agent 用の「環境」を模索 ― Modal Sandbox © LayerX Inc. Workspace Web UI。状態確認や Workspace 操作・Preview リンク 33
34. 02 | Coding Agent 用の「環境」を模索 ― Modal Sandbox ざっくりとした Temporal の説明 Durable な (耐久性のある) Workflow Engine OSS / Cloud 状態は Server 側に保持される Worker はステートレスで、中断しても History をリプレイして再開位置を確定 副作用を "Activity" として閉じ込め、Retry / Timeout / Heartbeat などを活用し失敗に対処 Temporal Server polling Worker Event History Task Queue タスクを実行 事実の記録 © LayerX Inc. タスクの配信列 結果を Server に返す 簡略化した Temporal アーキテクチャ 34
35. 02 | Coding Agent 用の「環境」を模索 ― Modal Sandbox v1 の設計判断① Temporal による Durable Execution Agent turn や Workspace lifecycle の管理に利用 long-running な Agent と環境の ライフサイクル管理に、Durable Execution の仕組みは実質必須 Temporal workflow の実行例 (workspace lifecycle) © LayerX Inc. [PR] Durable Execution について Software Design 2026年5月号 で詳しく解説しています 35
36. 02 | Coding Agent 用の「環境」を模索 ― Modal Sandbox v1 の設計判断② SDK は薄く持つ プロトタイプとして Claude Agent SDK を採用 ただしコード上は AI SDK の UIMessage に変換し、Agent SDK 依存部分を抽象化 来たるべき Codex 対応 (= harness の複数化) に備えるため © LayerX Inc. 36
37. 02 | Coding Agent 用の「環境」を模索 ― Modal Sandbox Modal Sandbox の壁 データ・通信を国内・VPC に閉じられない Coding 前提では許容できていたが、機密度の高いデータソースにもアクセスしたい モチベーションが生じた gVisor-based 由来の制約が強い sudo できない、など。動かせないものが出てくる Sandbox は最長 24h suspend/resume は可能だが、1日以上動き続ける Agent が作れない © LayerX Inc. 37
38. 02 | Coding Agent 用の「環境」を模索 ― EKS v1.5 ― Amazon EKS (Managed Kubernetes Service) v1 の壁 国内・VPC に閉じたい gVisor 由来の制約 24h 制限 © LayerX Inc. EKS では AWS 上に閉じられる 素の Docker / DinD が使える 自作の CRD で lifecycle を決められる 38
39. 02 | Coding Agent 用の「環境」を模索 ― EKS EC2 でも ECS でもなく EKS を選択した理由 EC2: workspace が「多数・短命」なワークロード 1 台 1 workspace の懸念 (コスト・起動速度) 相乗りするなら隔離・集約・配置の管理が必要 環境の作り直しも AMI よりコンテナビルドのほうが速い (devcontainer 資産の活用) ECS: Fargate の制約 ＋ on EC2 でも残る実装コスト イメージキャッシュが効かず pull が遅い privileged 不可で DinD が動かせない on EC2 を選んでも lifecycle 管理 (reconcile) は枠組みごと実装が必要 © LayerX Inc. 39
40. 02 | Coding Agent 用の「環境」を模索 ― EKS v1.5 の構成 WebUI HTTP API CLI Slack Haro API 「プロンプト → 環境 + Agent」の単一の入口 Temporal Cloud Amazon EKS agent turn を管理 Workspace CRD Pod lifecycle を管理 workspace Pod devcontainer / DinD Gateway API Preview URL © LayerX Inc. Twingate Connector Zero Trust Network Access 40
41. 02 | Coding Agent 用の「環境」を模索 ― EKS Workspace CRD Workspace リソースを apply すると Pod 作成 lifecycle (起動・停止・再開・TTL) は custom operator が reconcile k8s の流儀に乗ることで、 周辺エコシステムをそのまま使える Temporal (agent) との役割分担 © LayerX Inc. 41
42. 02 | Coding Agent 用の「環境」を模索 ― EKS 素の Docker が使えると、うれしい devcontainer をそのままビルドして動かせる ミドルウェア群も workspace 内で docker compose up するだけ ローカルと同じメンタルモデル 既存の環境整備の資産がそのまま活きる 「Haro 専用の環境」をメンテしたくないという当初からの方針 © LayerX Inc. 42
43. 02 | Coding Agent 用の「環境」を模索 ― EKS Gateway API を活用した Preview workspace 内の port ごとに Preview URL を払い出す {app}--{ws_name}.haro-domain operator が Workspace ごとに HTTPRoute を自動生成 L7 の port 振り分けは envoy sidecar が hostname で解決 © LayerX Inc. Browser https://api--fix-bug.haro-domain Envoy Gateway ext-auth で認証 HTTPRoute → Service envoy の listen port へ転送するだけ workspace Pod 内 envoy sidecar Host ヘッダ (virtual_host) で転送先 port を解決 App 127.0.0.1:{containerPort} 43
44. 02 | Coding Agent 用の「環境」を模索 ― EKS 02 総括：環境を模索した結果 提供物は 環境 + デフォルトの Agent に タスク依頼 → PR 作成 → Preview 確認 まで回せるようになった 次を作ろうとしたとき、抽象がもう一段進む © LayerX Inc. 44
45. 03 | 抽象がもう一段進む
46. 03 | 抽象がもう一段進む 「単なるコーディング」の先 仕事は「開発 (コードを書く)」だけではない 例: 問い合わせの調査・修正 Notion / Slack / ログから関連情報を集め、原因を調査 必要ならコードを直すところまで © LayerX Inc. 46
47. 03 | 抽象がもう一段進む 例: 問い合わせ調査・修正 ⚡ 問い合わせ / アラート イベントを起点に起動 調査 Agent 環境不要 Notion Slack ログ … 「コード修正が必要」と判明 Coding Agent 環境 + harness 起動 Pull Request © LayerX Inc. 問い合わせ調査 Agent が読むのは Notion / Slack / ログ リポジトリも devcontainer も要らない 必要なのは system prompt と tools 結果は Coding Agent に連携したい 47
48. 03 | 抽象がもう一段進む 環境は必須ではない 「コードの読み書き」は タスクの1種類でしかない Agent に渡すツールの1つ 「環境が必要」は Agent のパラメータの1つでしかない 「コードの読み書き」等の環境が必要なツールがなければ、 環境は必須ではない むしろないならない方がレイテンシは小さくできてお得 開発以外のタスクも扱えて、環境が必須でない Agent も扱えるように…… © LayerX Inc. 48
49. 03 | 抽象がもう一段進む v2 の全体像 WebUI HTTP API CLI Slack Haro API プロンプト → Agent を起動する単一の入口 Temporal (Durable Execution) ToolLoopAgent HarnessAgent 環境なし。system prompt + tools Amazon EKS 環境あり。harness × sandbox 環境が要るときだけ Workspace CRD → Pod © LayerX Inc. 49
50. 03 | 抽象がもう一段進む 再確認 — "Agent" とは 実装レベルで見ると、Agent は薄い model + system prompt + tools を loop で回すだけ Anthropic — "Agents … are typically just LLMs using tools based on environmental feedback in a loop" "Subagent" "skill" も、突き詰めれば tool の一種 Subagent — 別の Agent を実行し、結果を返す tool skill — description が tool の description として agent に渡され、呼び出しに応じて本文が返る tool © LayerX Inc. https://www.anthropic.com/engineering/building-effective-agents 50
51. 03 | 抽象がもう一段進む 通常 Agent の例: AI SDK の ToolLoopAgent 3 要素 (model / system prompt / tools) を 渡し、tool のループを回すだけの 薄いクラス © LayerX Inc. 51
52. 03 | 抽象がもう一段進む 再確認 — "Harness" とは 広義では Agent = Model + Harness — Harness = モデル以外の実行系全体 • LangChain — "A harness is every piece of code, configuration, and execution logic that isn't the model itself." • Martin Fowler / B. Böckeler — "'harness' has emerged as a shorthand to mean everything in an AI agent except the model itself." • Databricks — "the software infrastructure that wraps around a LLM and enables it to act on tasks." • Microsoft — "scaffolding that turns a language model into an agent that can actually do things." • (狭義) Hugging Face — "the execution layer inside the agent: it calls the model, handles its tool calls, decides when to stop." © LayerX Inc. https://www.langchain.com/blog/the-anatomy-of-an-agent-harness / https://martinfowler.com/articles/harness-engineering.html / https://www.databricks.com/blog/ai-harness / https://learn.microsoft.com/en-us/agent-framework/agents/harness https://huggingface.co/blog/agent-glossary 52
53. 03 | 抽象がもう一段進む HarnessAgent prompt, tools を渡せるのは同じ harness — 外部 agent runtime を挿し 込むアダプタ (e.g. Claude Code, Codex) sandbox — runtime の実行環境 © LayerX Inc. AI SDK v7: github.com/vercel/ai/tree/ai@7.0.34/architecture 53
54. 03 | 抽象がもう一段進む HarnessAgent の中身 Temporal Worker Temporal Workflow agent.generate() HarnessAgent host process Amazon EKS ① sandbox provider が apply Workspace CRD Workspace Pod ② operator が reconcile Claude Code harness runtime (bridge) © LayerX Inc. は呼び出し元で動く sandbox provider が Workspace CRD を apply → operator が Pod を作る HarnessAgent が bridge port 越しに Pod 内の Claude Code を駆動 AI が環境を操作するには Coding Agent を中で動かすのが楽 HarnessAgent 54
55. 03 | 抽象がもう一段進む 統一 interface — Agent と UIMessage ToolLoopAgent も HarnessAgent も同じ interface Temporal Workflow からは 環境の有無に関係なく透過的 に扱える © LayerX Inc. 55
56. 03 | 抽象がもう一段進む Custom Agent Agent はパラメータでの組み合わせ system prompt / tools 呼べる Subagent 環境の要否 誰でも作れる 開発者以外にも開かれた仕組みへ © LayerX Inc.
57. 03 | 抽象がもう一段進む Remote MCP 社内リソース (Notion / Slack / Google Workspace / GitHub / Snowflake / Datadog / …) に アクセスできる共有 tool 群 これを前述の Custom Agent に与えられるようにすることで、 あらゆる種類の業務に接続できる LayerX 社内には全社員向けの Agent プラットフォーム・MCP 基盤が存在 ツールを使う Agent を使う 文化が全社にある © LayerX Inc. * https://note.layerx.co.jp/n/ne3678df21488 57
58. 03 | 抽象がもう一段進む Lead Agent → Subagent 定義した Agent は他 Agent が Subagent として呼び出せる e.g. Lead Agent がタスクを分解 → Subagent へ委譲 特定タスクに特化した Subagent を Lead Agent が呼び分けることで、多 様なタスクに対応できる © LayerX Inc. 問い合わせ対応 Agent タスクを分解して Subagent へ委譲 ログ確認 ToolLoopAgent (env-less) 仕様確認 ToolLoopAgent (env-less) コード検索 HarnessAgent (w/ workspace) 58
59. 03 | 抽象がもう一段進む Subagent の実装 — tool と child workflow Subagent は tool として実装 されている Claude Code / Claude Agent SDK — "Claude invokes subagents through the Agent tool" vercel/eve — "lowers every subagent visible to the current agent into a model-visible tool" Haro でも同じ設計。tool から Temporal の child workflow をキックする Agent の lifecycle と workflow が 1:1 Durable Execution の性質 (resume / signal / timeout) を relay © LayerX Inc. https://code.claude.com/docs/en/agent-sdk/subagents, https://eve.dev/docs/subagents 59
60. 03 | 抽象がもう一段進む Haro v2 の全景 — 改めて WebUI Slack Haro API プロンプト → Agent を起動する単一の入口 Temporal (Durable Execution) ToolLoopAgent env-less Amazon EKS Remote MCP HarnessAgent w/ workspace 環境が要るときだけ Notion Slack GitHub Snowflake … Workspace CRD → Pod © LayerX Inc. 60
61. 04 | Agent 基盤 のその先
62. Agent 基盤 のその先 Agent as API 「AI Agent」と言うと賢そう・強そうに聞こえる 抽象度を上げると、プロンプトを input にして output を返す API と解釈できる HTTP API なら cURL で呼べる し、それができるなら 任意のイベントと接続できる はず © LayerX Inc. 62
63. Agent 基盤 のその先 Ambient Agent チャット起点ではなく、イベント (メール受信、フォーム送信、…) を トリガーに自律的に起動し、 タスクを完了する AI エージェント Agent が自律的にイベントを拾って自律的に仕事をしてほしい Agent が API 的に呼び出せたり任意のイベントに接続したりして、 とにかく勝手に仕事をしてくれる… そういう基盤となっていきたい © LayerX Inc. https://comemo.nikkei.com/n/n76970e72afde 63
64. Agent 基盤 のその先 Haro v2 — 起動口が広がる WebUI Slack HTTP API Webhook cron Mail Haro API プロンプト → Agent を起動する単一の入口 Temporal (Durable Execution) ToolLoopAgent env-less Amazon EKS Remote MCP HarnessAgent w/ workspace 環境が要るときだけ Notion Slack GitHub Snowflake … Workspace CRD → Pod © LayerX Inc. 64
65. Agent 基盤 のその先 Marketplace — Agent を組織資産に 作った Custom Agent を 社内で共有・配布 できるようにする 個々人に閉じていた「Agent による自動化」を 型として全社に広げる みんなの活用レベルの底上げ 利用状況をプラットフォーム側で捉えられる → 改善ループの起点 © LayerX Inc. 65
66. Agent 基盤 のその先 Platform も Close the loop Platform 上で動作する Agent の実績・失敗・feedback を回収 Custom Agent や共通 tool の改善に還す 「使えば使うほど賢くなる Agent」を簡単に作れる Platform に © LayerX Inc. 66
67. まとめ
68. まとめ できた Agent 基盤 Lead Agent → Subagent 構成で解決できる問題の幅を広げる 責務ごとに Agent を分けて連携し、複雑なタスクを分解できる k8s Workspace の中で環境つき Agent を動かす CRD で workspace を作り、k8s の reconcile / routing の仕組みを活用できる workspace 内で agent runtime を動かすことで、coding agent の進化への適応と柔軟な Agent 設計を両立 Remote MCP で組織横断のツール群にアクセス 環境の有無に依らず、どの Agent からも同じ社内リソースへ繋がる © LayerX Inc. 68
69. まとめ Agent 基盤の広がり Custom Agent × Marketplace で個人の自動化を組織の資産に パラメータで誰でも Agent を定義し、Marketplace で全社に配布 Ambient Agent の実現 - 任意のイベントから Agent を起動 cURL / Webhook / cron / mail など、event driven に射程を広げる Platform も Close the loop で使われるほど賢くなる基盤へ 利用状況を Platform 側で捉え、Custom Agent や共通 tool の改善に還す © LayerX Inc. 69
70. まとめ Lessons Learned / これからの Platform 試行錯誤で 理解・解像度 を上げ、アーキテクチャもプロダクトも進化する リモート Coding Agent → リモート開発環境 → Agent 基盤 と、作るものの抽象度も上がっていった AI Agent Platform も、Software Engineering の延長線 AI が絡む難しい問題であっても、それを支える基盤には Software Engineering で立ち向かうことができる 問題を解きほぐしていった結果、最終的に Kubernetes や Temporal workflow で解ける問題に落としていけた 自己進化する Platform 使われるほど賢くなる — Close the loop の思想を基盤そのものに組み込む © LayerX Inc. 70