Slide 1

Slide 1 text

Built Our Own Background Agent at LayerX 2026-07-23 AI DevEx Conference 2026 @izumin5210 / @itkq

Slide 2

Slide 2 text

whoami @izumin5210 LayerX バクラク事業部 (2022-09 -) Platform Engineering 部 Enabling チーム / Dev Infrastructure チーム Staff Software Engineer バックエンドや Web フロントエンドが専門 ISUCON14 4位 好きな GitHub org は github.com/vercel-labs © LayerX Inc.

Slide 3

Slide 3 text

whoami @itkq バクラク事業部 ソフトウェアエンジニア (2023-02 -) Platform Engineering 部 SRE チーム テックリード Amazon ECS / AWS Lambda を軸としたサービスインフラや Deploy / Terraform pipeline を主に担当 好きな設定言語は Jsonnet © LayerX Inc.

Slide 4

Slide 4 text

LayerX とバクラク

Slide 5

Slide 5 text

LayerX とバクラク 「すべての経済活動を、デジタル化する。」をミッションに、複合的な事業を通して日本の社会課題を 解決し、AI の力で人々の創造力がより発揮される未来をつくります。 © LayerX Inc.

Slide 6

Slide 6 text

© LayerX Inc. 6

Slide 7

Slide 7 text

LayerX とバクラク 「バクラク」のアーキテクチャ概要 AWS Cloud がメイン コンテナ・サーバーレス構成を積極 的に取り入れ、運用コストを最適化 GraphQL Gateway + Connect RPC Microservices monorepo © LayerX Inc. https://speakerdeck.com/layerx/bakuraku-engineering-team-deck

Slide 8

Slide 8 text

本題

Slide 9

Slide 9 text

Ramp Builders Blog の影響 © LayerX Inc. https://builders.ramp.com/post/why-we-built-our-background-agent 9

Slide 10

Slide 10 text

今日話すこと:Background Agent から Agent 基盤へ 01 | Background Coding Agent が欲しい PC を閉じても Coding Agent を並列・安全に動かすには? 02 | Coding Agent 用の「環境」を模索 既製品の検証から自作の道へ 03 | 抽象がもう一段進む Coding はタスクの 1 つ、環境はパラメータの 1 つだった 04 | Agent 基盤のその先 作った基盤で、業務自動化を広げる © LayerX Inc.

Slide 11

Slide 11 text

01 | Background Coding Agent が欲しい

Slide 12

Slide 12 text

01 | Background Coding Agent が欲しい Agentic AI 時代の開発 Coding Agent (Claude Code, Codex, ...) と開発するのが当たり前になった 人間がコードを書く時間より、Agent がコードを書く時間のほうが長い すると、今までなかった「困り」が生まれてくる © LayerX Inc. 12

Slide 13

Slide 13 text

01 | Background Coding Agent が欲しい 困り① PC を閉じると Agent が止まる 夜間も、移動中も、コードを書いていてほしい スリープしてもエージェントには動き続けていてほしい 24時間以上動くエージェントへの対応 © LayerX Inc. 13

Slide 14

Slide 14 text

01 | Background Coding Agent が欲しい 困り② セキュリティ PdM などより多くの人が Agent でコードを書くようになる ローカルマシンに強い権限・秘密情報が集まる プロンプトインジェクションによる流出懸念 サプライチェーンリスク 依存パッケージ経由の悪意あるコードが「開発者の手元」で実行される時代 Agent が自律的にコマンドを実行するなら、実行環境を隔離したい (とはいえローカルマシンがガッチガチなのはちょっと…) © LayerX Inc. 14

Slide 15

Slide 15 text

01 | Background Coding Agent が欲しい 困り③ リソース不足 git worktree による並列開発が当たり前になった 動作環境も並列すると → ローカルの CPU / メモリが足りない 並列化で顕在化した、AI 時代ならではの問題 © LayerX Inc. 15

Slide 16

Slide 16 text

01 | Background Coding Agent が欲しい 困り④ 環境構築・再現性 開発環境ブートストラップのコストと再現性の問題 バクラクでは開発者も増え続けている aqua, mise, Nix など取り入れているが基本的には自由 「手元で動かない」は人間にも Agent にも等しくコスト © LayerX Inc. 16

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

01 | Background Coding Agent が欲しい 素直に解くと「リモートで動く Coding Agent」 PC から切り離す 閉じても動く 管理されたクラウド上の実行環境 セキュリティ リソース 再現性 LLM Gateway の統合 開発者の PC プロンプト リモート実行環境 🤖 Coding Agent ● Keep running コスト管理 本当にやりたいことは別にあった © LayerX Inc. 18

Slide 19

Slide 19 text

01 | Background Coding Agent が欲しい 当時から持っていたビジョン 「プロンプトを投げたら Agent が立ち上がり、自律的にタスクを遂行する」 「リモートで動く」は手段でしかない やりたいのは、Coding Agent を HTTP API で呼べる ようにすること HTTP API で起動できる → イベントドリブンに起動できる © LayerX Inc. 19

Slide 20

Slide 20 text

01 | Background Coding Agent が欲しい 「単なるコーディング」の先 Linear や Notion の issue を勝手に取って開発させる 問い合わせの初動調査・対応の自動化 複数人のコラボレーション Lv1: Pull Request Preview の共有 → Lv2: Agent session の共有 「人間の操作」を起点にしない開発フローが作れるようになる © LayerX Inc. 20

Slide 21

Slide 21 text

01 | Background Coding Agent が欲しい まず、既存製品を試した Devin Claude Code Action Codex Cloud 結局、このビジョンの土台にはできなかった © LayerX Inc. 21

Slide 22

Slide 22 text

01 | Background Coding Agent が欲しい 足りなかったこと① 環境のお守り 開発環境のメンテナンスが大変 基本は monorepo だが、そうなっていないリポジトリもある リポジトリ側の変化に常に足並みを揃える必要があり、専用環境のメンテが 追いつかない © LayerX Inc. 22

Slide 23

Slide 23 text

01 | Background Coding Agent が欲しい 足りなかったこと② 今までの Claude / Codex が使えない 製品組み込みの Agent がブラックボックス 社内に蓄積した skills などの資産が使えないことも 「決められた Agent しか使えない」は進化を阻む 開発者それぞれの試行錯誤による多様性は大事 (行動指針 Bet AI) © LayerX Inc. 23

Slide 24

Slide 24 text

01 | Background Coding Agent が欲しい 足りなかったこと③ 過渡期のロックイン モデルも市場も、あらゆるものが過渡期 特定のモデルプロバイダ・特定製品へのロックインはリスクになりうる 今日のベストが半年後のベストである保証がない 年払いは怖い © LayerX Inc. 24

Slide 25

Slide 25 text

01 | Background Coding Agent が欲しい 01 結論:欲しかったのは Agent より「環境」 与えられているべきは 環境 と デフォルトの Agent 環境さえあれば、手元の Coding Agent を ssh で繋いで作業させることもできる Claude Code / Codex / VS Code、どれも ssh 越しに使える 権限・秘密情報はリモート側に置いたまま、手元は繋ぐだけ 環境の上で好きなものを動かせる → 個人のチャレンジを妨げない © LayerX Inc. 25

Slide 26

Slide 26 text

02 | Coding Agent 用の「環境」を模索

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

02 | Coding Agent 用の「環境」を模索 ― GitHub Codespaces 編 v0 ― GitHub Codespaces github.com を使っていればもっともお手軽 ベースは devcontainer devcontainer 自体は一般的な仕組み ここでの整備は後段でも資産になり、無駄にならない © LayerX Inc. 28

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

02 | Coding Agent 用の「環境」を模索 ― Modal Sandbox v1 ― Modal Sandbox Ramp の事例に影響を受け試した Sandbox の起動が高速 20 GB 近いイメージも十数秒で上がってくる Preview に必要な機構もある (Tunnel) © LayerX Inc. 30

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

02 | Coding Agent 用の「環境」を模索 ― Modal Sandbox ② PR 作成 (ツール実行許可) © LayerX Inc.① Slack で依頼 → Workspace 起動・Agent が仕事 32

Slide 33

Slide 33 text

02 | Coding Agent 用の「環境」を模索 ― Modal Sandbox © LayerX Inc. Workspace Web UI。状態確認や Workspace 操作・Preview リンク 33

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

02 | Coding Agent 用の「環境」を模索 ― Modal Sandbox v1 の設計判断② SDK は薄く持つ プロトタイプとして Claude Agent SDK を採用 ただしコード上は AI SDK の UIMessage に変換し、Agent SDK 依存部分を抽象化 来たるべき Codex 対応 (= harness の複数化) に備えるため © LayerX Inc. 36

Slide 37

Slide 37 text

02 | Coding Agent 用の「環境」を模索 ― Modal Sandbox Modal Sandbox の壁 データ・通信を国内・VPC に閉じられない Coding 前提では許容できていたが、機密度の高いデータソースにもアクセスしたい モチベーションが生じた gVisor-based 由来の制約が強い sudo できない、など。動かせないものが出てくる Sandbox は最長 24h suspend/resume は可能だが、1日以上動き続ける Agent が作れない © LayerX Inc. 37

Slide 38

Slide 38 text

02 | Coding Agent 用の「環境」を模索 ― EKS v1.5 ― Amazon EKS (Managed Kubernetes Service) v1 の壁 国内・VPC に閉じたい gVisor 由来の制約 24h 制限 © LayerX Inc. EKS では AWS 上に閉じられる 素の Docker / DinD が使える 自作の CRD で lifecycle を決められる 38

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

02 | Coding Agent 用の「環境」を模索 ― EKS Workspace CRD Workspace リソースを apply すると Pod 作成 lifecycle (起動・停止・再開・TTL) は custom operator が reconcile k8s の流儀に乗ることで、 周辺エコシステムをそのまま使える Temporal (agent) との役割分担 © LayerX Inc. 41

Slide 42

Slide 42 text

02 | Coding Agent 用の「環境」を模索 ― EKS 素の Docker が使えると、うれしい devcontainer をそのままビルドして動かせる ミドルウェア群も workspace 内で docker compose up するだけ ローカルと同じメンタルモデル 既存の環境整備の資産がそのまま活きる 「Haro 専用の環境」をメンテしたくないという当初からの方針 © LayerX Inc. 42

Slide 43

Slide 43 text

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

Slide 44

Slide 44 text

02 | Coding Agent 用の「環境」を模索 ― EKS 02 総括:環境を模索した結果 提供物は 環境 + デフォルトの Agent に タスク依頼 → PR 作成 → Preview 確認 まで回せるようになった 次を作ろうとしたとき、抽象がもう一段進む © LayerX Inc. 44

Slide 45

Slide 45 text

03 | 抽象がもう一段進む

Slide 46

Slide 46 text

03 | 抽象がもう一段進む 「単なるコーディング」の先 仕事は「開発 (コードを書く)」だけではない 例: 問い合わせの調査・修正 Notion / Slack / ログから関連情報を集め、原因を調査 必要ならコードを直すところまで © LayerX Inc. 46

Slide 47

Slide 47 text

03 | 抽象がもう一段進む 例: 問い合わせ調査・修正 ⚡ 問い合わせ / アラート イベントを起点に起動 調査 Agent 環境不要 Notion Slack ログ … 「コード修正が必要」と判明 Coding Agent 環境 + harness 起動 Pull Request © LayerX Inc. 問い合わせ調査 Agent が読むのは Notion / Slack / ログ リポジトリも devcontainer も要らない 必要なのは system prompt と tools 結果は Coding Agent に連携したい 47

Slide 48

Slide 48 text

03 | 抽象がもう一段進む 環境は必須ではない 「コードの読み書き」は タスクの1種類でしかない Agent に渡すツールの1つ 「環境が必要」は Agent のパラメータの1つでしかない 「コードの読み書き」等の環境が必要なツールがなければ、 環境は必須ではない むしろないならない方がレイテンシは小さくできてお得 開発以外のタスクも扱えて、環境が必須でない Agent も扱えるように…… © LayerX Inc. 48

Slide 49

Slide 49 text

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

Slide 50

Slide 50 text

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

Slide 51

Slide 51 text

03 | 抽象がもう一段進む 通常 Agent の例: AI SDK の ToolLoopAgent 3 要素 (model / system prompt / tools) を 渡し、tool のループを回すだけの 薄いクラス © LayerX Inc. 51

Slide 52

Slide 52 text

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

Slide 53

Slide 53 text

03 | 抽象がもう一段進む HarnessAgent prompt, tools を渡せるのは同じ harness — 外部 agent runtime を挿し 込むアダプタ (e.g. Claude Code, Codex) sandbox — runtime の実行環境 © LayerX Inc. AI SDK v7: github.com/vercel/ai/tree/[email protected]/architecture 53

Slide 54

Slide 54 text

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

Slide 55

Slide 55 text

03 | 抽象がもう一段進む 統一 interface — Agent と UIMessage ToolLoopAgent も HarnessAgent も同じ interface Temporal Workflow からは 環境の有無に関係なく透過的 に扱える © LayerX Inc. 55

Slide 56

Slide 56 text

03 | 抽象がもう一段進む Custom Agent Agent はパラメータでの組み合わせ system prompt / tools 呼べる Subagent 環境の要否 誰でも作れる 開発者以外にも開かれた仕組みへ © LayerX Inc.

Slide 57

Slide 57 text

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

Slide 58

Slide 58 text

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

Slide 59

Slide 59 text

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

Slide 60

Slide 60 text

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

Slide 61

Slide 61 text

04 | Agent 基盤 のその先

Slide 62

Slide 62 text

Agent 基盤 のその先 Agent as API 「AI Agent」と言うと賢そう・強そうに聞こえる 抽象度を上げると、プロンプトを input にして output を返す API と解釈できる HTTP API なら cURL で呼べる し、それができるなら 任意のイベントと接続できる はず © LayerX Inc. 62

Slide 63

Slide 63 text

Agent 基盤 のその先 Ambient Agent チャット起点ではなく、イベント (メール受信、フォーム送信、…) を トリガーに自律的に起動し、 タスクを完了する AI エージェント Agent が自律的にイベントを拾って自律的に仕事をしてほしい Agent が API 的に呼び出せたり任意のイベントに接続したりして、 とにかく勝手に仕事をしてくれる… そういう基盤となっていきたい © LayerX Inc. https://comemo.nikkei.com/n/n76970e72afde 63

Slide 64

Slide 64 text

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

Slide 65

Slide 65 text

Agent 基盤 のその先 Marketplace — Agent を組織資産に 作った Custom Agent を 社内で共有・配布 できるようにする 個々人に閉じていた「Agent による自動化」を 型として全社に広げる みんなの活用レベルの底上げ 利用状況をプラットフォーム側で捉えられる → 改善ループの起点 © LayerX Inc. 65

Slide 66

Slide 66 text

Agent 基盤 のその先 Platform も Close the loop Platform 上で動作する Agent の実績・失敗・feedback を回収 Custom Agent や共通 tool の改善に還す 「使えば使うほど賢くなる Agent」を簡単に作れる Platform に © LayerX Inc. 66

Slide 67

Slide 67 text

まとめ

Slide 68

Slide 68 text

まとめ できた 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

Slide 69

Slide 69 text

まとめ 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

Slide 70

Slide 70 text

まとめ Lessons Learned / これからの Platform 試行錯誤で 理解・解像度 を上げ、アーキテクチャもプロダクトも進化する リモート Coding Agent → リモート開発環境 → Agent 基盤 と、作るものの抽象度も上がっていった AI Agent Platform も、Software Engineering の延長線 AI が絡む難しい問題であっても、それを支える基盤には Software Engineering で立ち向かうことができる 問題を解きほぐしていった結果、最終的に Kubernetes や Temporal workflow で解ける問題に落としていけた 自己進化する Platform 使われるほど賢くなる — Close the loop の思想を基盤そのものに組み込む © LayerX Inc. 70

Slide 71

Slide 71 text

No content