4人目のSREはAgent Ai WorkforceにおけるSRE Agent化計画 LayerX Ai Workforce事業部 SRE 谷村 祐樹 2026/06/30 

自己紹介 

谷村 祐樹( tanimu / @tanimuyk ) © LayerX Inc. About Me LayerX Ai Workforce事業部でSREやってます！ これまでのキャリア インフラエンジニア → SRE / スクラムマスター → コンサルタント → SRE 趣味 野球観戦（正捕手のトレードで今シーズンは達観し た目で...） 育児しながらの投資エージェント作り 3 

アジェンダ © LayerX Inc. アジェンダ Ai WorkforceのSREチームについて 4人目のSREをAgentに AgentへのSREオンボーディング 成果 まとめ これから 4 

Ai WorkforceのSREチームについて 

© LayerX Inc. 事業紹介 6 

© LayerX Inc. Ai WorkforceチームのSREの責務 参考: Ai Workforce SREチームの責務（LayerX / Zenn） 7 

SREは、信頼性と運用をエンジニアリングで改善する “運用で見えた問題を、人の頑張りではなく、仕組み・自動化・設計で減らしていく。 ” Google SREでは、toilを各SREの時間の50%未満に抑え、少なくとも50%を将来のtoil削減やサービス改善につながるエンジニアリングに 使う。 < 50%: Toil 本番サービス運用に紐づく、手作業・反復・自動化可能・リアク ティブな仕事。放置するとSREの時間を埋め尽くす。 >= 50%: Engineering 将来のtoilを減らす、または信頼性・性能・利用効率・サービス 機能を改善するプロジェクトワーク。 では、Ai WorkforceチームのSREには、仕組みで減らしたいtoilはどれぐらいあったのか？？ © LayerX Inc. SREとは何をする人か SRE Book: Introduction / Eliminating Toil 8 

3人チームのSREに110件/月の依頼が流れ込んでいた 2026年3月にSREへの依頼を棚卸しすると、大小あわせて110件あることが分かりました。 110件 1か月にSREへ来ていた依頼 SREに持ち込まれていた依頼カテゴリ 件数 PRレビュー依頼 21 インフラ相談・質問 18 リリース調整・情報共有ほか 18 PIM承認・権限付与 16 環境構築・テナント設定 15 データ取得・加工・削除 13 インシデント・障害対応 9 合計 110 © LayerX Inc. 2026年3月の現実 9 

小さな対応でも、割り込みとして積み上がる 1件の対応は小さく見えますが、前後の切り替えまで入れると、大きな割り込みになります。これが複数発生する と、エンジニアリングに費やす時間がさらに削られていきます。 +5分 問い合わせの文脈を読む 20分 調べて回答する +10分 元のタスクに戻り、集中し直す 110件 1か月の依頼（toil） × 35分 5分 + 20分 + 10分（軽い例） = 約64時間 1か月あたり 3人 × 20日 × 8h ＝ 480時間 の稼働のうち、約13%がこの割り込みに費やされると計算できる。 （超ざっくり です） © LayerX Inc. toilによる割り込み時間 10 

このまま人で受け続けても、楽にはならない 自動化によってtoilを潰していくことはできるが、進化し続けるプロダクトに追いつくのは至難の業。人が「やらな い」という選択肢を選びました。 人で対応する場合の選択肢 手順を自動化する 個別作業は減る。でも「これは何をすべきか」を受けて判断 する入口は残る。 がんばって速く返す 短期的には効くけど、深い設計や仕組み化の時間を削ってし まう。 対応できる人を増やす 採用とオンボーディングには時間がかかるし、相談の流れ先 が増えるだけになりやすい。 そこで考えたこと SRE業務をAgentにオンボーディングできないか？ 人を増やす前に、SREがいつもやっている一次調査、回答、知識化 を、チームメイトを一人迎えるのと同じようにAgentへ渡すことに チャレンジしました。 © LayerX Inc. 人を増やすだけでは解けない 11 

4人目のSREをAgentに 

そこで、4人目のSREとしてオテスキーを迎えた © LayerX Inc. 4人目のSRE、オテスキー 選手紹介 Ai Workforce SREチームに現れた、4人目の SRE。仕事を少しずつ教えて育てている、期待の 助っ人 Slackに住み、雑多な質問や仕様相談から障害の 初動まで、これまでSREに直接来ていた一次受け を引き取る Datadog・ソースコード・設計ドキュメントを読 み、一次調査まで返す できることを一つずつ増やすほど、SREの手が離 れていく 13 

SRE Agent（オテスキー）のアーキテクチャ Slackを人とAgentの窓口にして、AWS AgentCoreを起動します。AgentはDatadog・Notion・S3上のソースコードを横断 して調べ、結果をSlackのスレッドに返します。外部通信はプロキシでFQDN許可リスト制御。 © LayerX Inc. アーキテクチャ全体像 14 

SRE Agentで意識した3つのこと とにかくすぐに効果を出すために、小さく作ること・回答を信頼できること・実際に使われることの3つを優 先しました。 01 小さく作り、運用を軽く する 02 回答の信頼性を上げる 03 使われるUXにする © LayerX Inc. 作る上で意識したこと 15 

小さく作り、運用を軽くする 

AWS Managedサービスを利用して小さく組む マネージドサービスを組み合わせて小さく組み、SRE固有の作りは tool と prompt だけ に集中させています。 © LayerX Inc. 01 小さく作り、運用を軽くする Strands Agents SDK 思考・tool呼び出しを SDKに集約 AgentCore / Serverless 実行基盤はマネージド。 呼ばれた時だけ動く 状態管理もマネージド Memory・DynamoDB・ Secrets Manager 17 

まず「調査」から任せ、信頼を積んで広げる 将来的には問題修正の実行まで任せていくことを前提として、最初の一歩は調査に絞り、安全に信頼を積み上 げます。 © LayerX Inc. 01 小さく作り、運用を軽くする まずは調査まで — 一次回答は返す。修復や変更は、まだ人間の判断に置く 危険操作はさせない — 書き込み系のtoolはそもそも渡さない。Datadog MCPも多数の toolから必要な toolset だけに絞って開く 観測して、精度を上げる — Datadog Agent Observabilityでtool call・失敗・latencyを 追い、回答の精度を確認して改善につなげる 18 

回答の信頼性を上げる 

テレメトリとソースコードを突き合わせて、精度の高い情報を提供する Datadogで症状だけ見ても、コードだけ読んでも原因特定は不十分になる可能性が高く、同じAgentの中で突き合わせ ることで精度の高い調査結果を出すことができる。 テレメトリ(Datadog) アラート・ログ・メトリクス・trace・エラーから、症状と stacktraceを把握する ＋ ソースコード 実装・処理フロー・インフラ構成・設定・依存関係を把握 する → Report 症状と実装を突き合わせ、人間が次に判断できる粒度 で、仮説と確認ポイントを返す © LayerX Inc. 02 回答の信頼性を上げる 20 

コードをAgentの手元に置いて、すぐ辿れるようにする 毎回GitHub APIを叩くと遅いうえ、rate limit にも当たる可能性があります。ソースコードを定期的にS3に置き、 microVMが起動時に手元へ一括syncすることですぐ調査に入ることができます。 © LayerX Inc. 02 回答の信頼性を上げる 21 

調査の型は、system prompt × Skill で教える 「どう調べるか」の方針は system prompt、 「調査の手順・型」は Skill で教える。2つを重ねて、人と同じ 型で調査できるようにします。 ① system prompt ― 探索の方針（抜粋） × ② Skill ― 調査の手順（抜粋） © LayerX Inc. 02 回答の信頼性を上げる 参考: Agent Skills（Claude Docs） 22 

継続的にAgentの回答を評価し改善を続ける Agentが出した回答を、Datadog Agent Observability の trace と Evaluations機能 で評価し、ズレた箇所を特定して prompt と toolset へ返す。一度きりでなく、継続的に回します。 Agent Observabilityで1実行のtrace・tool call・出力を辿る © LayerX Inc. 02 回答の信頼性を上げる ① 評価してズレを特定 traceとEvaluations機能で、ズレた箇所を見つける Agent span ▸ iteration ▸ LLM＋tool を辿り、どのtool callでズ レたか（検索不足／誤ったtool選択／根拠の取り違え）を特定 ② 改善する promptとtoolsetを直す 繰 り 返 す 参考: Datadog Agent Observability Agentの評価（LayerX / Zenn） 23 

使われるUXにする 

Slackに常駐することで、いつでも話しかけられるようにする 新しいポータルを作るのではなく、全社員が日常利用しているSlackをホームグラウンドとしました。 「SREに聞く」前 に、まずオテスキーに聞く。 利用者 @オテスキー このエラー、どこを見ればよさそう？ オテスキー Datadogログと関連コードを確認します。まず該当時間帯 のtraceを見ます。 オテスキー 原因候補は workflow 実行時の retry 周辺です。関連ファイ ルは ... © LayerX Inc. 03 使われるUXにする 25 

アラートから、自分で動き出す 人から聞かれて回答するリアクティブなUXだけでなく、人が気づく前にプロアクティブに動けるよう、アラート通知から 直接起動できるようにしました。 1. Datadog Monitorが検知し、Agentをメンションする ▶ 2. SRE AgentがDatadog MCPで一次調査する © LayerX Inc. 03 使われるUXにする 26 

成果 

SREに来ていた依頼は、110件から40件まで減った オテスキーの活躍により、当初の依頼件数を半数以下まで削減することができた。 2026年3月 110件 SREへの依頼 / 月（稼働の約13%） → 2026年6月 40件 / 月（約5%） 人手で数をさばくのではなく、Agentに武器を持たせ、改善ループを回してさらに減らしていくことも可能と考えている。 © LayerX Inc. 成果：toilが半分以下に 28 

Slackに置いたことで、調査結果が共有資産になった Slack上で一次調査できるようになると、SREだけでなく開発・FDE/CS・非Devメンバーにも使われ始めました。 （2026年6月だけで108回呼び出されている） 🐱 SWE / QA 🐶 FDE / CS 一次調査のために置いたAgentが、チーム全員が後から使える調査ログの置き場にもなりました。 © LayerX Inc. 成果：調査がチームの資産に 「Datadogとコードを横断した原因候補を、調査のいち ばん最初に出してくれる。動き出しが一気に速くなっ た」 「Agentに調べさせたSlackのthreadをそのまま共有で きる。質問から回答までの文脈ごと渡せるのが助かる」 29 

まとめ 

オテスキーに教えたこと オテスキーへのオンボーディングで工夫した点はこの3点です。 01 小さく作り、運用を軽くす る 02 回答の信頼性を上げる 03 使われるUXにする © LayerX Inc. まとめ：意識した3つ マネージドな部品で小さく組 む まず調査に閉じて、安全に信 頼を積む テレメトリ×コードを突き合 わせる 調査の型は system prompt × Skill で教える 回答を継続的に評価・改善す るループを回す Slackに常駐して、その場で 即応する アラートから自分で動き出す 31 

2人目のAgentをインターンメンバーが作ってくれました！ 拡張しやすい基盤のため、2人目はすぐでした。インシデントの重大度（SEV）を判定する incident-agent を、同じ基 盤に載せています。 みなさんもぜひ、新しいチームメンバーとしてAgentを迎え入れてみてください！！！ © LayerX Inc. 横展開：2人目のAgent 1人目 オテスキー 雑多な質問・障害の一次調査を引き受け、Datadog × コードで 原因候補を返す。 2人目 incident-agent Slackのインシデント報告から重大度を分類。分類結果 × 過去 インシデント履歴で判定する。 参考: incident-agent 実装ブログ 32 

これから 

SREは「運用する人」から「Agentを育てる人」へ SREの目的は、サービスの信頼性を上げ続けること。それを阻むtoilを仕組みで削るのは欠かせない手段で、いまはその実行を人から Agentへ移せます。人がボトルネックにならず、信頼性を上げ続ける——そこにBetしていきたいと思います！ © LayerX Inc. SREはプラットフォーマーへ 34 

Developers Summit 2026 Summerに登壇します！ 「AIプロダクトの本番変更をどう判断するか：怖いリリースを今日出せる変更に変えるSREの実践」という テーマでお話をさせていただきます！(7/17(Fri) 16:10–16:40) © LayerX Inc. 告知：Developers Summit 2026 Summer 参考: Developers Summit 2026 Summer セッション詳細 35 

一緒にわいわいする仲間を募集してます！！！ 少しでも気になったら、まずは話を聞きに来てください！ Ai Workforce Hiring Deck Open Door カジュアル面談はこちらから © LayerX Inc. We Are Hiring 36 

ご清聴ありがとうございました！