SRE NEXT 2026 登壇してきました 〜バクラク開発者プラットフォーム大公開〜
バクラクで SRE マネージャーをしている坂田 (@sakajunquality)です。先日SRE NEXT 2026で登壇させていただきました。発表では入社以来取り組んでいる内製の開発者プラットフォーム “Service Console” について、 SRE としてのAIエージェントとの向き合い方をテーマにお話させていただきました。今回は登壇内容についての解説と時間の都合で話しきれなかった部分を補足したいと思います。
登壇内容について
スライドはこちら
タイムリーにNoteでもインタビューしていただきました。
前提: バクラクのエコシステム
まずバクラクのアーキテクチャやモノレポのエコシステムについて簡単に解説をしました。簡単に言うと200以上のマイクロサービスをモノレポで管理し AWS 上で動かしています。最近は「AI にコンテキストを渡しやすいから」という理由でモノレポにする会社も増えている印象ですが、弊社では2022年ごろからモノレポでの開発に移行しています。
このモノレポについては、より詳細の記事があるのであわせてご覧ください。
インフラのモノレポについてはこちらも参照ください。
課題は認知負荷
開発課題の１つとして認知負荷はよく上がると思います。そのなかでも本セッションではまず1) 情報の分断、2)独自エコシステム、3) 定期リリースを挙げさせていただきました。
まず情報の分断ですがモノレポかどうかはさておき、１つのコードをリリースするまで多くのツールを使うことがかなり増えているのではないでしょうか。コードは GitHub、CI/CD は CodeBuild、監視は Datadog など。さらに LLM や AI エージェントを提供するにあたり Langfuse や Temporal など新しいものも増えています。また各種ナレッジについてもAIが読み書きしやすいからと GitHub においたり、Slack に書き溜めたり、気づくと分散することもあります。
次に独自のエコシステムですが、弊社のモノレポをベースに課題紹介しています。
2026 年現在でも、SaaS やクラウドの多くはモノレポをデファクトとして設計されていません。このあたりは 2024 年の弊社 CTO のスライドもあわせてご覧ください 。例えば GitHub Actions に 200 以上のサービスが載っていると、共通ライブラリへの 1 コミットで影響するサービス全部のビルドとテストが走り、ワークフローの履歴が濁流のように流れていきます。入社したての人が「自分のジョブを見よう」と思っても、全然たどり着けない。検索性にも難があり、結局 Actions のファイル名を調べて URL 直打ちする、みたいなことになります。
モノレポでなかったとしても、身近な例だと環境変数やシークレットの追加方法、デプロイ方法など質問は一般的に多くあります。「自分の周りの CI はどうなってるんだっけ」「デプロイ後のログはどこに出るんだっけ」という疑問は、日々の開発の中であるのではないでしょうか。
人間に認知負荷が高いものは、AIにも認知負荷が高い
そしてこれは AI エージェントも同じです。AI エージェントで開発するのは当たり前になり、その先のデプロイやモニタリングまで任せる流れも来ています。AWS にも Datadog にも MCP や CLI があって、それ自体は良いのですが、汎用ツールをジェネリックに叩かせると、賢いモデルでも大量の探索とツールコールが必要になります。
「人間にとって認知負荷が高いものは、AI にとっても認知負荷が高い」。これが今回の発表のテーマの１つです。
Service Console: 内製のInternal Developer Platform
そこで作っているのが「Service Console」という内製の Internal Developer Platform (IDP) です。Internal Developer "Portal"と "Platform" の違いとしては、Portal は情報を見て(read)終わり、Platform はそこからサービスを立ち上げたり何かしらのwriteアクションまでできる、という整理をしています。後の話につながりますが人やAIが見て終わりの Portal ではなくそこから次に繋がる Platform を目指しています。スライドとは順番が変わりますが、バクラクの開発エコシステムのコンテキストを正しくモデリングして、人間・AIエージェントに提供することを思想にしています。
仕組み
仕組みは意外とシンプルです。扱う情報は二種類あります。
一つはサービスのスタティックな情報。サービス名、言語、オーナーなどで、GitHub 上のサービス定義をパースして Service Console のデータベースに取り込みます。もう一つはダイナミックな情報で、デプロイ、ビルド、エラーなどのイベントです。 GitHub の Webhook や ECS などのイベントから取り込みます。イベントドリブンに情報を処理しつつ、必要に応じて最新のリソース状態を直接取りにいくこともできます。例えば最新のECSタスクの状況を見に行くなど。
すべてをつくったわけではなく Webhook はすでに仕組みがありこちらを活用しています。
こうして整備した情報を、人間向けには Web UI で、AI 向けには MCP で提供しています。ジェネリックな MCP や API では何度もツールコールしないと取れなかった「このサービスは今どうなっているのか」「このプルリクエストはどの環境までデプロイされているのか」といった情報が目的に合わせてとれます。
MCPにすることで社内で広く使われているエージェント基盤との統合もしています。
なぜ内製したのか
生成 AI で開発コストが下がったから！
半分冗談で半分本当です（フロントエンドに関しては本当にそう）。私を含め周囲にはフロントエンドが苦手な SRE が多く(偏見かもしれません)、生成 AI で UI が作れるようになったのは大きいです。ただ、開発コストが下がっても運用コストが下がるわけではないので、それだけでは内製の理由になりません。
Backstage のような既製品を採用しても、自社向けカスタマイズを重ねれば開発・アップデートの運用を保証する必要があるのは同じで、内製との差は実はそんなに大きくないと考えています。むしろバクラクにはサービス定義や Service Generation などのエコシステムがすでにあるので、それに特化したデータモデルで作り、既存の仕組みを活用できる内製の方が合理的でした。Cookpadでのhako-console の事例を経験したメンバーがいた事も内製の後押しになってます。今後 AI エージェント向けに拡張していくうえで自前の方が自社に合わせてつくれるというのもあります。
事例: バクラクの定期リリース
Service Console の活用事例として、定期リリースの話をしました。
バクラクの大部分のプロダクトは月2回の定期リリースです。「少なくない?」と思われるかもしれませんが、お客様に日常業務で使っていただくプロダクトなので、大きな変更を予告なく出すと運用の負荷になります。サポートやヘルプの体制もあわせて構築しています。もちろん緊急のものは hotfix をしますし、feature flags の制御もしています。
このリリースが複雑なのはマイクロサービス間の依存関係です。gRPC のスキーマ互換なども考慮しつつ、サービスとチームごとに決まったフェーズでデプロイしていく必要があります。
以前はこれを Slack の一つのスレッドで進行していて、リプライが 100 件を超え、今どのフェーズで誰が何を待っているのか非常につかみにくい状態でした。そこでまず依存関係のグラフ可視化から始め、現在は Service Console 上で全体の進捗フェーズと、今誰のアクションが求められているかが見えるようになっています。
アウトカムとしては、進行役を務める SRE が全体を俯瞰できるようになったこと、各エンジニアが自分の担当をすぐ把握できるようになったことです。定量的にも数時間早く終わることも...(ただまだまだ伸びることもあるし) ひとまずフェーズごとの開始・終了時刻が残るのでボトルネックの分析や自動化ポイントの検討につながっています。
チームごとに属人化していたデプロイ手順も、Slack ボットのリマインドや手順・ナレッジの集約によって、入社歴の浅いメンバーでもリリース担当できるようになりました。現状はまだ人間が進行していますが、今後は進行自体を自動化して、依存関係の解決や順序制御も任せて、「人間が呼ばれるのはトラブルのときだけ」という状態を目指しています。
社内への浸透
次に社内へどう浸透していったかの話です。ありがたいことにここはそんなに苦労していません笑。(みんな新しいものには飛びついてくれるカルチャーで助かります。) そのうえで工夫したことを２つほど。
１つ目は利便性です。みんなが属人的に持っているスクリプトや設定を集合知としてService Consoleに実装しました。何度か GitHub Actions の話をしていますが、GitHub Actions の検索機能もこの１つです。fuzzy に特定のワークフローにたどり着けます。
こういったものを含めエンジニアの小さな困りを解消しつつ、エンジニア全体に同期で共有したりしてました。
２つ目はプロセスへの組み込みです。定期リリースがまさにそれで、リリース日には必ず Service Console を使うことになります(落ちたらリリースが止まるという緊張感があります)。確実に使われる場を作ったうえで、フィードバックも貰いに行ってました。
ただ「フィードバックありますか?」と聞くと「いい感じです」で終わりがちなので、ヒアリングの設計はもう少し工夫が必要です。余談ですが以前 Anthropic 社のイベントで Claude Code をつくった Boris Cherny 氏とお話する機会があり、Claude Codeの話を聞いたのですが、逆にあまり使っていないユーザーに話を聞きに行ったそうです。
AIとの共生
さて本題です。Service Console と AI の関係には二つの側面があります。「AI で Service Console を作る」ことと、「AI に Service Console を使ってもらう」ことです。当たり前の話に感じかもしれないですが、生成AIを使った開発はかなりこなれてきた上で、生成AIでなにを作るかが結構大事かなと思っています。
AIでService Consoleを作る
Service Console は Claude Code や Codex などの開発 AI エージェントで、ほぼ 100% AI で開発しています。スキーマやデザインコンポーネントを AI が扱いやすいように整えたうえで、基本的に全部作らせています。
これまで「形にする」こと自体のコストが高かったのですが、そこが下がったことで、まず作って当たりをつけて課題に向き合い、違ったら躊躇なく捨てる、という進め方ができるようになりました。無駄なものを作ってしまうこと、「課題を解決するのはこれじゃないよね」となることは実際よくあります。一方で機能が増えると検証が大変になるので、デザインシステムの統一や E2E での検証など、サステナブルに開発し続けられる仕組みも合わせて整えています。
AIにService Consoleを使ってもらう
もう一つが、Service Console を通じて AI エージェント(とそれを使う開発者)をイネーブリングする話です。コンテキストがない AI エージェントは、AWS・Datadog・GitHub の API や MCP や CLI をジェネリックに呼び回ることになります(スライドでは矢印だらけの図にしました)。そうではなく、バクラクのインフラとリポジトリのコンテキストを持った Service Console を経由することで、より少ないトークンで目的に到達できます。
まとめ: ループが回るためのハーネスを整備する
開発者プラットフォームを構成するツールは世の中にたくさんありますが、選定においては機能の有無よりも「自社のドメインを適切にモデリングできるか」が大事だと考えています。人間に対しても AI に対しても、ドメインへの適切なコンテキストを作って認知負荷を下げる。生成 AI で開発コストは劇的に下がりましたが、だからこそ「その IDP でどんな課題を解決したいのか」はよく考えた方がいいと思います。
AI エージェントを作るのが流行っていますが、AI エージェントが使う道具を作ることも同じくらい大事です。(余談ですが登壇ではできるだけ AI/AI AgentのEngineering の単語を使わずに説明をしてました。)
プロダクト開発で AI エージェントがループを回すのだとしたら、SRE や基盤・プラットフォームの人間がやることは、そのループが回るためのツールとハーネスの整備なのではないか、と思っています。
開発者プラットフォームはこれまで人向けのものでしたが、これからは人も使うし AI も使う。両者に同じようにコンテキストを整備していく、というのが今回一番伝えたかったことです。
Service Console も現状 AI 向けのツールは Read 系に限定しています。取得した情報をもとに次のアクションをするのは人間、という状態です。今後は Write のアクションを追加しよりAIエージェントが自走していける世界を作っていきたいと思います。
登壇を終えて
まずは Ask the Speaker や会場でお声がけありがとうございました。
正直 Service Console でできることがありすぎ内容を圧縮するのに苦労しました。(最初 AI で資料を作ったものの全部捨てて結局ゼロから全部作り直しました)
Service Console 自体はセキュリティやコストなどどんどん機能が増えています。登壇には間に合わなかったのですが、利用者の統計や利用ログも整ってきています。またどこかで、開発者の体験をどう変えていったか、データを添えてお話できればと思います。
最近利用状況がより定量的に可視化できるようになりました。
おわりに
SRE NEXT 2026 に Logo スポンサーとして協賛し、メンバー3名が登壇します #srenext - LayerX エンジニアブログ にもある通り弊社から３名公募での登壇させていただきました。３つとも違った側面で弊社の事例がお伝えできたのではないかと思います。
LayerXではSREを積極的に採用しております。OpenDoorやカジュアル面談も積極的に行っています。
興味のある方はぜひこちらからお話しましょう！
原文を表示
バクラクで SRE マネージャーをしている坂田 (@sakajunquality)です。先日SRE NEXT 2026で登壇させていただきました。発表では入社以来取り組んでいる内製の開発者プラットフォーム “Service Console” について、 SRE としてのAIエージェントとの向き合い方をテーマにお話させていただきました。今回は登壇内容についての解説と時間の都合で話しきれなかった部分を補足したいと思います。
登壇内容について
スライドはこちら
タイムリーにNoteでもインタビューしていただきました。
前提: バクラクのエコシステム
まずバクラクのアーキテクチャやモノレポのエコシステムについて簡単に解説をしました。簡単に言うと200以上のマイクロサービスをモノレポで管理し AWS 上で動かしています。最近は「AI にコンテキストを渡しやすいから」という理由でモノレポにする会社も増えている印象ですが、弊社では2022年ごろからモノレポでの開発に移行しています。
このモノレポについては、より詳細の記事があるのであわせてご覧ください。
インフラのモノレポについてはこちらも参照ください。
課題は認知負荷
開発課題の１つとして認知負荷はよく上がると思います。そのなかでも本セッションではまず1) 情報の分断、2)独自エコシステム、3) 定期リリースを挙げさせていただきました。
まず情報の分断ですがモノレポかどうかはさておき、１つのコードをリリースするまで多くのツールを使うことがかなり増えているのではないでしょうか。コードは GitHub、CI/CD は CodeBuild、監視は Datadog など。さらに LLM や AI エージェントを提供するにあたり Langfuse や Temporal など新しいものも増えています。また各種ナレッジについてもAIが読み書きしやすいからと GitHub においたり、Slack に書き溜めたり、気づくと分散することもあります。
次に独自のエコシステムですが、弊社のモノレポをベースに課題紹介しています。
2026 年現在でも、SaaS やクラウドの多くはモノレポをデファクトとして設計されていません。このあたりは 2024 年の弊社 CTO のスライドもあわせてご覧ください 。例えば GitHub Actions に 200 以上のサービスが載っていると、共通ライブラリへの 1 コミットで影響するサービス全部のビルドとテストが走り、ワークフローの履歴が濁流のように流れていきます。入社したての人が「自分のジョブを見よう」と思っても、全然たどり着けない。検索性にも難があり、結局 Actions のファイル名を調べて URL 直打ちする、みたいなことになります。
モノレポでなかったとしても、身近な例だと環境変数やシークレットの追加方法、デプロイ方法など質問は一般的に多くあります。「自分の周りの CI はどうなってるんだっけ」「デプロイ後のログはどこに出るんだっけ」という疑問は、日々の開発の中であるのではないでしょうか。
人間に認知負荷が高いものは、AIにも認知負荷が高い
そしてこれは AI エージェントも同じです。AI エージェントで開発するのは当たり前になり、その先のデプロイやモニタリングまで任せる流れも来ています。AWS にも Datadog にも MCP や CLI があって、それ自体は良いのですが、汎用ツールをジェネリックに叩かせると、賢いモデルでも大量の探索とツールコールが必要になります。
「人間にとって認知負荷が高いものは、AI にとっても認知負荷が高い」。これが今回の発表のテーマの１つです。
Service Console: 内製のInternal Developer Platform
そこで作っているのが「Service Console」という内製の Internal Developer Platform (IDP) です。Internal Developer "Portal"と "Platform" の違いとしては、Portal は情報を見て(read)終わり、Platform はそこからサービスを立ち上げたり何かしらのwriteアクションまでできる、という整理をしています。後の話につながりますが人やAIが見て終わりの Portal ではなくそこから次に繋がる Platform を目指しています。スライドとは順番が変わりますが、バクラクの開発エコシステムのコンテキストを正しくモデリングして、人間・AIエージェントに提供することを思想にしています。
仕組み
仕組みは意外とシンプルです。扱う情報は二種類あります。
一つはサービスのスタティックな情報。サービス名、言語、オーナーなどで、GitHub 上のサービス定義をパースして Service Console のデータベースに取り込みます。もう一つはダイナミックな情報で、デプロイ、ビルド、エラーなどのイベントです。 GitHub の Webhook や ECS などのイベントから取り込みます。イベントドリブンに情報を処理しつつ、必要に応じて最新のリソース状態を直接取りにいくこともできます。例えば最新のECSタスクの状況を見に行くなど。
すべてをつくったわけではなく Webhook はすでに仕組みがありこちらを活用しています。
こうして整備した情報を、人間向けには Web UI で、AI 向けには MCP で提供しています。ジェネリックな MCP や API では何度もツールコールしないと取れなかった「このサービスは今どうなっているのか」「このプルリクエストはどの環境までデプロイされているのか」といった情報が目的に合わせてとれます。
MCPにすることで社内で広く使われているエージェント基盤との統合もしています。
なぜ内製したのか
生成 AI で開発コストが下がったから！
半分冗談で半分本当です（フロントエンドに関しては本当にそう）。私を含め周囲にはフロントエンドが苦手な SRE が多く(偏見かもしれません)、生成 AI で UI が作れるようになったのは大きいです。ただ、開発コストが下がっても運用コストが下がるわけではないので、それだけでは内製の理由になりません。
Backstage のような既製品を採用しても、自社向けカスタマイズを重ねれば開発・アップデートの運用を保証する必要があるのは同じで、内製との差は実はそんなに大きくないと考えています。むしろバクラクにはサービス定義や Service Generation などのエコシステムがすでにあるので、それに特化したデータモデルで作り、既存の仕組みを活用できる内製の方が合理的でした。Cookpadでのhako-console の事例を経験したメンバーがいた事も内製の後押しになってます。今後 AI エージェント向けに拡張していくうえで自前の方が自社に合わせてつくれるというのもあります。
事例: バクラクの定期リリース
Service Console の活用事例として、定期リリースの話をしました。
バクラクの大部分のプロダクトは月2回の定期リリースです。「少なくない?」と思われるかもしれませんが、お客様に日常業務で使っていただくプロダクトなので、大きな変更を予告なく出すと運用の負荷になります。サポートやヘルプの体制もあわせて構築しています。もちろん緊急のものは hotfix をしますし、feature flags の制御もしています。
このリリースが複雑なのはマイクロサービス間の依存関係です。gRPC のスキーマ互換なども考慮しつつ、サービスとチームごとに決まったフェーズでデプロイしていく必要があります。
以前はこれを Slack の一つのスレッドで進行していて、リプライが 100 件を超え、今どのフェーズで誰が何を待っているのか非常につかみにくい状態でした。そこでまず依存関係のグラフ可視化から始め、現在は Service Console 上で全体の進捗フェーズと、今誰のアクションが求められているかが見えるようになっています。
アウトカムとしては、進行役を務める SRE が全体を俯瞰できるようになったこと、各エンジニアが自分の担当をすぐ把握できるようになったことです。定量的にも数時間早く終わることも...(ただまだまだ伸びることもあるし) ひとまずフェーズごとの開始・終了時刻が残るのでボトルネックの分析や自動化ポイントの検討につながっています。
チームごとに属人化していたデプロイ手順も、Slack ボットのリマインドや手順・ナレッジの集約によって、入社歴の浅いメンバーでもリリース担当できるようになりました。現状はまだ人間が進行していますが、今後は進行自体を自動化して、依存関係の解決や順序制御も任せて、「人間が呼ばれるのはトラブルのときだけ」という状態を目指しています。
社内への浸透
次に社内へどう浸透していったかの話です。ありがたいことにここはそんなに苦労していません笑。(みんな新しいものには飛びついてくれるカルチャーで助かります。) そのうえで工夫したことを２つほど。
１つ目は利便性です。みんなが属人的に持っているスクリプトや設定を集合知としてService Consoleに実装しました。何度か GitHub Actions の話をしていますが、GitHub Actions の検索機能もこの１つです。fuzzy に特定のワークフローにたどり着けます。
こういったものを含めエンジニアの小さな困りを解消しつつ、エンジニア全体に同期で共有したりしてました。
２つ目はプロセスへの組み込みです。定期リリースがまさにそれで、リリース日には必ず Service Console を使うことになります(落ちたらリリースが止まるという緊張感があります)。確実に使われる場を作ったうえで、フィードバックも貰いに行ってました。
ただ「フィードバックありますか?」と聞くと「いい感じです」で終わりがちなので、ヒアリングの設計はもう少し工夫が必要です。余談ですが以前 Anthropic 社のイベントで Claude Code をつくった Boris Cherny 氏とお話する機会があり、Claude Codeの話を聞いたのですが、逆にあまり使っていないユーザーに話を聞きに行ったそうです。
AIとの共生
さて本題です。Service Console と AI の関係には二つの側面があります。「AI で Service Console を作る」ことと、「AI に Service Console を使ってもらう」ことです。当たり前の話に感じかもしれないですが、生成AIを使った開発はかなりこなれてきた上で、生成AIでなにを作るかが結構大事かなと思っています。
AIでService Consoleを作る
Service Console は Claude Code や Codex などの開発 AI エージェントで、ほぼ 100% AI で開発しています。スキーマやデザインコンポーネントを AI が扱いやすいように整えたうえで、基本的に全部作らせています。
これまで「形にする」こと自体のコストが高かったのですが、そこが下がったことで、まず作って当たりをつけて課題に向き合い、違ったら躊躇なく捨てる、という進め方ができるようになりました。無駄なものを作ってしまうこと、「課題を解決するのはこれじゃないよね」となることは実際よくあります。一方で機能が増えると検証が大変になるので、デザインシステムの統一や E2E での検証など、サステナブルに開発し続けられる仕組みも合わせて整えています。
AIにService Consoleを使ってもらう
もう一つが、Service Console を通じて AI エージェント(とそれを使う開発者)をイネーブリングする話です。コンテキストがない AI エージェントは、AWS・Datadog・GitHub の API や MCP や CLI をジェネリックに呼び回ることになります(スライドでは矢印だらけの図にしました)。そうではなく、バクラクのインフラとリポジトリのコンテキストを持った Service Console を経由することで、より少ないトークンで目的に到達できます。
まとめ: ループが回るためのハーネスを整備する
開発者プラットフォームを構成するツールは世の中にたくさんありますが、選定においては機能の有無よりも「自社のドメインを適切にモデリングできるか」が大事だと考えています。人間に対しても AI に対しても、ドメインへの適切なコンテキストを作って認知負荷を下げる。生成 AI で開発コストは劇的に下がりましたが、だからこそ「その IDP でどんな課題を解決したいのか」はよく考えた方がいいと思います。
AI エージェントを作るのが流行っていますが、AI エージェントが使う道具を作ることも同じくらい大事です。(余談ですが登壇ではできるだけ AI/AI AgentのEngineering の単語を使わずに説明をしてました。)
プロダクト開発で AI エージェントがループを回すのだとしたら、SRE や基盤・プラットフォームの人間がやることは、そのループが回るためのツールとハーネスの整備なのではないか、と思っています。
開発者プラットフォームはこれまで人向けのものでしたが、これからは人も使うし AI も使う。両者に同じようにコンテキストを整備していく、というのが今回一番伝えたかったことです。
Service Console も現状 AI 向けのツールは Read 系に限定しています。取得した情報をもとに次のアクションをするのは人間、という状態です。今後は Write のアクションを追加しよりAIエージェントが自走していける世界を作っていきたいと思います。
登壇を終えて
まずは Ask the Speaker や会場でお声がけありがとうございました。
正直 Service Console でできることがありすぎ内容を圧縮するのに苦労しました。(最初 AI で資料を作ったものの全部捨てて結局ゼロから全部作り直しました)
Service Console 自体はセキュリティやコストなどどんどん機能が増えています。登壇には間に合わなかったのですが、利用者の統計や利用ログも整ってきています。またどこかで、開発者の体験をどう変えていったか、データを添えてお話できればと思います。
最近利用状況がより定量的に可視化できるようになりました。
おわりに
SRE NEXT 2026 に Logo スポンサーとして協賛し、メンバー3名が登壇します #srenext - LayerX エンジニアブログ にもある通り弊社から３名公募での登壇させていただきました。３つとも違った側面で弊社の事例がお伝えできたのではないかと思います。
LayerXではSREを積極的に採用しております。OpenDoorやカジュアル面談も積極的に行っています。
興味のある方はぜひこちらからお話しましょう！
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み