Upgrade to Pro — share decks privately, control downloads, hide ads and more …

AIと共生する開発者プラットフォーム:バクラクのモノレポ×マイクロサービス基盤

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers.

 AIと共生する開発者プラットフォーム:バクラクのモノレポ×マイクロサービス基盤

AIと共生する開発者プラットフォーム:バクラクのモノレポ×マイクロサービス基盤
SRE NEXT2026
https://sre-next.dev/2026/schedule/#slot076

Avatar for sakajunquality

sakajunquality

July 12, 2026

More Decks by sakajunquality

Other Decks in Technology

Transcript

  1. © LayerX Inc. 2026/7/10 SRE NEXT Jun Sakata, @sakajunquality /

    バクラクSRE AIと共⽣する開発者プラットフォーム: バクラクのモノレポ×マイクロサービス基盤
  2. © LayerX Inc. 2 • 株式会社 LayerX • バクラク事業部 SREマネージャー

    • SREしつつ社内プロダクトをつくってます • 2026年1⽉⼊社 (チームで⼀番歴が浅い) • AWSは久しぶり • Google Developers Expert, Cloud • 趣味は料理 坂⽥ 純 @sakajunquality
  3. 3 © LayerX Inc. 「すべての経済活動を、デジタル化する。」をミッションに、複合的な事業を通して⽇本の社会 課題を解決し、AIの⼒で⼈々の創造⼒がより発揮される未来をつくります。 事業紹介 バクラク事業 バックオフィス向け AIエージェントサービスを提供

    Fintech事業 資産運⽤サービス 「ALTERNA(オルタナ)」を提供 Ai Workforce事業 エンタープライズ向け AIプラットフォームを提供 Security事業 AIエージェントによる ⾃律的なペネトレーションテストを提供
  4. 4 © LayerX Inc. 「バクラク」シリーズラインナップ ‧年会費無料で何枚でも発⾏可 ‧カード利⽤制限で統制を実現 ‧決済額に応じたキャッシュ バック 法⼈カードの発⾏‧管理

    ‧直感的UIで従業員の負担を軽減 ‧Slack連携で打刻や⾃動リマインド可能 ‧わかりやすい残業 / 休暇管理レポート 勤怠管理 ‧帳票の⼀括作成も個別作成も⾃由⾃在 ‧帳票の作成‧稟議‧送付‧保存を⼀本化 ‧レイアウトや項⽬のカスタマイズも可能 請求書発⾏ ‧スキャナ保存データも直接取込  ‧AI-OCRが⾃動読取&データ化 ‧[取引先][取引⽇][取引⾦額]での検索 ‧計算前後の業務を⼀気通貫で⾃動化 ‧異常値を⾃動で検知、⾒落としを防⽌ ‧過去履歴〜未来予約までデータを 正確に管理 給与 ‧AIが請求書を5秒でデータ化 ‧仕訳 / 振込データを⾃動作成 ‧電帳法‧インボイス制度にも対応 ‧AI活⽤の消込機能で⼊⾦消込をラクに ‧取引先リマインド/未⼊⾦督促を半⾃動化 ‧売上仕訳‧⼊⾦仕訳も柔軟に作成 ‧AIが⾒積書‧請求書を5秒でデータ ‧スマホからも申請‧承認OK ‧柔軟な通知設定‧承認の催促機能 ‧AIが領収書を5秒でデータ化 ‧スマホアプリとSlack連携あり ‧領収書の重複申請などミス防⽌機能
  5. © LayerX Inc. 8 • コードベースを1つのレポジトリ(GitHub)に集約している • もともとはPolyrepo(プロダクトごとFE/BE/infra)、現在はほとんどがMonorepo集合 • インフラは別のMonorepo

    Monorepo バクラクのエコシステム App Monorepo Infra Monorepo service definition Frontend Code Schema Docs Infra Code Infra Resources Backend Codes Tools
  6. © LayerX Inc. 9 • かなりコード⽣成(AIではなくロジックで)をしている (アプリケーションもインフラも) • サービス定義をマスターとしてインフラ(terraform等)を⽣成 •

    CI/CD (e.g. GitHub Actions) も⽣成 Service Generation バクラクのエコシステム サービス定義 インフラ, CICD アプリケーション モニタリング Go yaml terraform TypeScript
  7. © LayerX Inc. 10 • Enabling, Dev Infra, SREの3チームでPlatform Engineering部

    • すべてのバクラク製品の開発と運⽤を⽀える • 領域の明確な区切りはなく適度にコラボレーション Team バクラクのエコシステム 全バクラクプロダクトと開発チーム Enabling Team アプリケーションよりのエコシステム Dev Infra Team リモート開発環境 SRE Team インフラよりのエコシステム
  8. © LayerX Inc. 11 Engineers SREs 200+ Services 80+ 4

    Scale バクラクのエコシステム
  9. © LayerX Inc. 14 • デプロイ1つとっても多くのSaaSやツールを利⽤ ◦ GitHub, AWS, Datadog,

    Langfuse, Temporal, Google Cloud … ◦ LLM/AIエージェント利⽤によりツールも増えてる • ナレッジも分散 ◦ Makefile, Notion, GitHub, Slack etc… 1. 情報の分散 開発者認知負荷
  10. © LayerX Inc. 15 • SaaSやクラウドが必ずしもバクラクのエコシステムやモノレポにフィットしていない ◦ 例) GitHubとモノレポ (次のページで)

    • ⽣成(コードや設定)の仕組み ◦ サービスの⽴ち上げ、環境変数/シークレット etc • デプロイの⽅法 → どれも⼀般的な仕組みを使ってたとしても、トリガーや実⾏⽅法は会社により違う 2. 独⾃エコシステム(モノレポ) 開発者認知負荷
  11. © LayerX Inc. 16 • 例えばGitHub Actions ◦ Pull Request

    が多いとその分、履歴が流れ続ける ◦ バクラク規模だと常に流れつづけ⾒つけにくい ◦ 検索性も悪い • Releaseなども同様 モノレポとGitHubの相性いいとは⾔えない 開発者認知負荷 2024年のCTOの資料より
  12. © LayerX Inc. 18 よくある困り 開発者認知負荷  ⾃分の mergeしたCIは? 

    ビルド 終わった?  ログはどこを ⾒る?  このPRは デプロイされた?
  13. © LayerX Inc. 19 • 昨今、AIエージェントを通じて開発を⾏うのは当たり前 • 各クラウド/SaaS CLIやMCPがあるものの⾃⼒で探索させると、遅いし不安定 •

    ⼈間に認知負荷が⾼いものはAIエージェントにも⾼い(トークンの消費) • モデルが賢くなりつつもtool callは少ないほうがいい AIエージェントにとっても同じ問題 開発者認知負荷
  14. © LayerX Inc. 21 Internal Developer Platform • i.e. Platform

    Engineering • 例としては Backstage • バクラクは “Service Console” を内製化 • ⼈間/AIエージェント向けのPortal (Catalog)で終わることなく、AIエージェントがタスクを完結させ るPlatformを⽬指している Service Console
  15. © LayerX Inc. 22 • ⽣成AIで開発コストが下がったためだけではない ◦ (フロントエンドだけに限って⾔えばそうとも⾔える; SREs フロントエンド苦⼿)

    • 既製品を使ったとしても開発と運⽤は腰を据える必要がある • 汎⽤的なものではなく、バクラクに特化したデータモデリングを持ちたかった • 既存のインフラの仕組みやサービス定義の活⽤ • Cookpadでの同様の事例: hako-console • AIエージェント向けの独⾃拡張 なぜ内製化するのか Service Console
  16. © LayerX Inc. 24 ⼈間、AIエージェントどちらにもメタ情報とイベントを「翻訳」して集める Philosophy Service Console サービスの情報 サービスの状態

    バクラクエコシステムのデータモデル 利⽤しているSaaS、クラウドの情報‧イベントを正規化 ⼈間の開発者 WebUI AIエージェント MCP
  17. © LayerX Inc. 25 サービス定義をマスターとして各種イベントを正規化 具体的にどう作られているか Service Console サービス定義 Pull

    Request, GitHub Actions ServiceConsole ECS, Lambda etc… 情報のsync イベントのingest 必要に応じてdescribe
  18. © LayerX Inc. 28 • プロダクトやサービスのカタログ ◦ オーナーシップなどのmeta情報 ◦ サービスの状態、操作

    • 主要クラウドリソース • デプロイ、定期リリース • GitHubやLinearとの連携 • Cost確認 • etc. ほかにもこんなことも Service Console
  19. © LayerX Inc. 30 • 全プロダクト同時の定期リリースを⾏っている ◦ 変更しすぎてお客様に運⽤負担を強いないように ◦ お客様への案内やサポートなどもこれに合わせて⾏っている

    ◦ Feature Flags による制御や独⽴したリリースもある • 依存関係: マイクロサービス間、GraphQL Gateway, FE/BE • チーム横断の進⾏管理 • プロダクトチームごとにルールや⼿順が分散 • プロダクトやサービスが増加につれ、時間や負荷が⾼まっている 定期リリース バクラクのリリース
  20. © LayerX Inc. 31 • もともとSlackのスレッドで対応してい たものをService Console上に実装 • まずは可視化するところからスタート

    • 開発者体験改善もしないが劣化もしない 定期リリース改善 - 1 バクラクのリリース
  21. © LayerX Inc. 32 • 定性的なアウトカムとしては進⾏するSREが全体感の把握、 • 各フェーズのSWEが⾃分の担当がすぐに分かるように ◦ before:

    ⻑いSlack スレッドを遡っていた • 定量的には1回あたり数時間短縮(ことも) ◦ (まだトラブルで遅くなることもある) • とはいえ⾃動化していくポイントが⾒えて来る • ボトルネックも分析できるように 定期リリース改善 - 2 バクラクのリリース
  22. © LayerX Inc. 33 • もともとチームごとに持っていた(Slack botやNotion)リリース ⼿順の吸収 ◦ ⼊社が浅いメンバーもリリース担当することもある

    • Service Consoleが持ってるサービス情報との統合 → リリースフローを脱属⼈化 定期リリース改善 - 3 バクラクのリリース
  23. © LayerX Inc. 37 1. 利便性 社内への展開 • ⽇々の開発が便利になるツール ◦

    e.g. GitHub Actions finder (モノレポでCIを⽣成しているとかなりの数になる) • 草の根 ◦ チームやPlatformメンバー ◦ エンジニア共有会で時間もらって紹介したり ◦ リリースノートでアップで • 当たり前だが便利だと思うと使ってくれる
  24. © LayerX Inc. 38 e.g. GitHub Actions search 社内への展開 (再掲)

    モノレポはActions探すの⼤変になりがち
  25. © LayerX Inc. 39 • 先程の定期リリースのプロセスを乗せる = リリース⽇に必ず使う ◦ どんなに便利でも忙しいと使ってもらえない

    • ⽌めてしまうとビジネスインパクトもあるので緊張感 • できるだけフィードバックをもらい、できるだけ毎回体験を向上 2. 使わざるを得ない場⾯ 社内への展開
  26. © LayerX Inc. 41 • 開発者のメンタルモデルを変えずに使えるように ◦ 開発者がよく使う他のツールに揃える e.g. コマンドパレット、ダークモード

    ◦ 短縮URLと CMD+k だけ覚えてもらう • 定性のヒアリング ◦ よく使ってくれてるユーザーに使い始めたきっかけやモチベーションを聞いてみたり ◦ 逆に使ってくれない⼈に解決していない課題を確認したり • 定量的での利⽤実態の把握(今後!) ◦ Web/MCP共に利⽤ログを取り始めた こまかなところ 社内への展開
  27. © LayerX Inc. 42 • ⼈に聞く前に、まず⾒る場所ができた • ツールは増えてるけど、覚えることが減った • ここも⾃動化できない?

    • ここが使いづらい (ネガティブなことも使ってくれている証拠!) • セキュリティ情報も乗せたい! • とりあえずService Consoleに連携するか 反響 社内への展開
  28. © LayerX Inc. 45 • 基本的にはAIエージェントでほぼ100%開発している ◦ アーキテクチャやスキーマはかなり⾒ている • 課題解決のためなにを作るかアタリをつけるものの、アイディアを形にしながら洗練

    ◦ 作りすぎない、ちゃんと消す ◦ c.f. 機能を作るな。楽して作るな。 • サステナブルな開発のためにデザインや検証のSkillなども 1. Service Console ⾃体の開発 AIエージェントとの共⽣
  29. © LayerX Inc. 49 • ツールの選定よりもモデリングが⼤事 • ⼈間もAIも適切なコンテキストで認知負荷を下げる • 開発コストは下がったが何を作るとよいのか?

    • AIエージェントをつくるのも⼤事だけど、AIエージェントが使う道具も同じくらい⼤事 • 利⽤されてるAIにあったインターフェイス (MCPが必ずしも最適ではない) Starting IDP? Takeaways
  30. © LayerX Inc. 50 “My job is to write loops.”

    - Boris Cherny → Ours might be to build the ground they run on. Build tools for agents — and build them with agents! Takeaways AIエージェントによる プロダクトの開発 (For) AIエージェントと プラットフォームの開発 (With)
  31. © LayerX Inc. 52 We are hiring! LayerX Open Door

    事業部‧テーマ別にカジュアル⾯談を公開しています。 アカウント登録は⼀切不要です! ‧メンバーと話してみたい ‧質問したいことがある ‧選考に進むか悩んでいる などなど、お気軽にお申し込みください。 Bakuraku Engineering Team Deck バクラクが挑んでいる課題、エンジニアリング組織の技術ス タックや開発カルチャーについて紹介しています。 AI を活⽤した「爆速開発」の裏側や、具体的な選考フロー‧ト ライアル⼊社の内容についても掲載しています。 バクラク エンジニア Deck