AIと共生する開発者プラットフォーム:バクラクのモノレポ×マイクロサービス基盤
by
sakajunquality
×
Copy
Open
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
Slide 1
Slide 1 text
© LayerX Inc. 2026/7/10 SRE NEXT Jun Sakata, @sakajunquality / バクラクSRE AIと共⽣する開発者プラットフォーム: バクラクのモノレポ×マイクロサービス基盤
Slide 2
Slide 2 text
© LayerX Inc. 2 ● 株式会社 LayerX ● バクラク事業部 SREマネージャー ● SREしつつ社内プロダクトをつくってます ● 2026年1⽉⼊社 (チームで⼀番歴が浅い) ● AWSは久しぶり ● Google Developers Expert, Cloud ● 趣味は料理 坂⽥ 純 @sakajunquality
Slide 3
Slide 3 text
3 © LayerX Inc. 「すべての経済活動を、デジタル化する。」をミッションに、複合的な事業を通して⽇本の社会 課題を解決し、AIの⼒で⼈々の創造⼒がより発揮される未来をつくります。 事業紹介 バクラク事業 バックオフィス向け AIエージェントサービスを提供 Fintech事業 資産運⽤サービス 「ALTERNA(オルタナ)」を提供 Ai Workforce事業 エンタープライズ向け AIプラットフォームを提供 Security事業 AIエージェントによる ⾃律的なペネトレーションテストを提供
Slide 4
Slide 4 text
4 © LayerX Inc. 「バクラク」シリーズラインナップ ‧年会費無料で何枚でも発⾏可 ‧カード利⽤制限で統制を実現 ‧決済額に応じたキャッシュ バック 法⼈カードの発⾏‧管理 ‧直感的UIで従業員の負担を軽減 ‧Slack連携で打刻や⾃動リマインド可能 ‧わかりやすい残業 / 休暇管理レポート 勤怠管理 ‧帳票の⼀括作成も個別作成も⾃由⾃在 ‧帳票の作成‧稟議‧送付‧保存を⼀本化 ‧レイアウトや項⽬のカスタマイズも可能 請求書発⾏ ‧スキャナ保存データも直接取込 ‧AI-OCRが⾃動読取&データ化 ‧[取引先][取引⽇][取引⾦額]での検索 ‧計算前後の業務を⼀気通貫で⾃動化 ‧異常値を⾃動で検知、⾒落としを防⽌ ‧過去履歴〜未来予約までデータを 正確に管理 給与 ‧AIが請求書を5秒でデータ化 ‧仕訳 / 振込データを⾃動作成 ‧電帳法‧インボイス制度にも対応 ‧AI活⽤の消込機能で⼊⾦消込をラクに ‧取引先リマインド/未⼊⾦督促を半⾃動化 ‧売上仕訳‧⼊⾦仕訳も柔軟に作成 ‧AIが⾒積書‧請求書を5秒でデータ ‧スマホからも申請‧承認OK ‧柔軟な通知設定‧承認の催促機能 ‧AIが領収書を5秒でデータ化 ‧スマホアプリとSlack連携あり ‧領収書の重複申請などミス防⽌機能
Slide 5
Slide 5 text
⽬次 Agenda ● バクラクの開発エコシステム ● 課題と内製化について ● AIエージェントとの共⽣
Slide 6
Slide 6 text
バクラクのエコシステム Monorepo x Microservice
Slide 7
Slide 7 text
© LayerX Inc. 7 Architecture ● バクラクの中に複数プロダクトを展開 ● プロダクト展開がさらに加速中! ● AWS上にマイクロサービス構成 バクラクのエコシステム
Slide 8
Slide 8 text
© 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
Slide 9
Slide 9 text
© LayerX Inc. 9 ● かなりコード⽣成(AIではなくロジックで)をしている (アプリケーションもインフラも) ● サービス定義をマスターとしてインフラ(terraform等)を⽣成 ● CI/CD (e.g. GitHub Actions) も⽣成 Service Generation バクラクのエコシステム サービス定義 インフラ, CICD アプリケーション モニタリング Go yaml terraform TypeScript
Slide 10
Slide 10 text
© LayerX Inc. 10 ● Enabling, Dev Infra, SREの3チームでPlatform Engineering部 ● すべてのバクラク製品の開発と運⽤を⽀える ● 領域の明確な区切りはなく適度にコラボレーション Team バクラクのエコシステム 全バクラクプロダクトと開発チーム Enabling Team アプリケーションよりのエコシステム Dev Infra Team リモート開発環境 SRE Team インフラよりのエコシステム
Slide 11
Slide 11 text
© LayerX Inc. 11 Engineers SREs 200+ Services 80+ 4 Scale バクラクのエコシステム
Slide 12
Slide 12 text
認知負荷 The problem: Cognitive Load
Slide 13
Slide 13 text
© LayerX Inc. 13 1. 情報の分散 2. 独⾃エコシステム(モノレポ) 3. 複雑な定期リリース 課題: 開発者の認知負荷
Slide 14
Slide 14 text
© LayerX Inc. 14 ● デプロイ1つとっても多くのSaaSやツールを利⽤ ○ GitHub, AWS, Datadog, Langfuse, Temporal, Google Cloud … ○ LLM/AIエージェント利⽤によりツールも増えてる ● ナレッジも分散 ○ Makefile, Notion, GitHub, Slack etc… 1. 情報の分散 開発者認知負荷
Slide 15
Slide 15 text
© LayerX Inc. 15 ● SaaSやクラウドが必ずしもバクラクのエコシステムやモノレポにフィットしていない ○ 例) GitHubとモノレポ (次のページで) ● ⽣成(コードや設定)の仕組み ○ サービスの⽴ち上げ、環境変数/シークレット etc ● デプロイの⽅法 → どれも⼀般的な仕組みを使ってたとしても、トリガーや実⾏⽅法は会社により違う 2. 独⾃エコシステム(モノレポ) 開発者認知負荷
Slide 16
Slide 16 text
© LayerX Inc. 16 ● 例えばGitHub Actions ○ Pull Request が多いとその分、履歴が流れ続ける ○ バクラク規模だと常に流れつづけ⾒つけにくい ○ 検索性も悪い ● Releaseなども同様 モノレポとGitHubの相性いいとは⾔えない 開発者認知負荷 2024年のCTOの資料より
Slide 17
Slide 17 text
© LayerX Inc. 17 3. 複雑な定期リリース これについては次のセクションで後述 開発者認知負荷
Slide 18
Slide 18 text
© LayerX Inc. 18 よくある困り 開発者認知負荷 ⾃分の mergeしたCIは? ビルド 終わった? ログはどこを ⾒る? このPRは デプロイされた?
Slide 19
Slide 19 text
© LayerX Inc. 19 ● 昨今、AIエージェントを通じて開発を⾏うのは当たり前 ● 各クラウド/SaaS CLIやMCPがあるものの⾃⼒で探索させると、遅いし不安定 ● ⼈間に認知負荷が⾼いものはAIエージェントにも⾼い(トークンの消費) ● モデルが賢くなりつつもtool callは少ないほうがいい AIエージェントにとっても同じ問題 開発者認知負荷
Slide 20
Slide 20 text
Service Console The Internal Developer Platform for Bakuraku
Slide 21
Slide 21 text
© LayerX Inc. 21 Internal Developer Platform ● i.e. Platform Engineering ● 例としては Backstage ● バクラクは “Service Console” を内製化 ● ⼈間/AIエージェント向けのPortal (Catalog)で終わることなく、AIエージェントがタスクを完結させ るPlatformを⽬指している Service Console
Slide 22
Slide 22 text
© LayerX Inc. 22 ● ⽣成AIで開発コストが下がったためだけではない ○ (フロントエンドだけに限って⾔えばそうとも⾔える; SREs フロントエンド苦⼿) ● 既製品を使ったとしても開発と運⽤は腰を据える必要がある ● 汎⽤的なものではなく、バクラクに特化したデータモデリングを持ちたかった ● 既存のインフラの仕組みやサービス定義の活⽤ ● Cookpadでの同様の事例: hako-console ● AIエージェント向けの独⾃拡張 なぜ内製化するのか Service Console
Slide 23
Slide 23 text
© LayerX Inc. 23 Service Console
Slide 24
Slide 24 text
© LayerX Inc. 24 ⼈間、AIエージェントどちらにもメタ情報とイベントを「翻訳」して集める Philosophy Service Console サービスの情報 サービスの状態 バクラクエコシステムのデータモデル 利⽤しているSaaS、クラウドの情報‧イベントを正規化 ⼈間の開発者 WebUI AIエージェント MCP
Slide 25
Slide 25 text
© LayerX Inc. 25 サービス定義をマスターとして各種イベントを正規化 具体的にどう作られているか Service Console サービス定義 Pull Request, GitHub Actions ServiceConsole ECS, Lambda etc… 情報のsync イベントのingest 必要に応じてdescribe
Slide 26
Slide 26 text
© LayerX Inc. 26 “Service”や “Pull Request” の切り⼝で情報が得られる Service Console
Slide 27
Slide 27 text
© LayerX Inc. 27 AIエージェントでも同様に情報にアクセス Service Console
Slide 28
Slide 28 text
© LayerX Inc. 28 ● プロダクトやサービスのカタログ ○ オーナーシップなどのmeta情報 ○ サービスの状態、操作 ● 主要クラウドリソース ● デプロイ、定期リリース ● GitHubやLinearとの連携 ● Cost確認 ● etc. ほかにもこんなことも Service Console
Slide 29
Slide 29 text
バクラクのリリース Service Console での課題解決事例
Slide 30
Slide 30 text
© LayerX Inc. 30 ● 全プロダクト同時の定期リリースを⾏っている ○ 変更しすぎてお客様に運⽤負担を強いないように ○ お客様への案内やサポートなどもこれに合わせて⾏っている ○ Feature Flags による制御や独⽴したリリースもある ● 依存関係: マイクロサービス間、GraphQL Gateway, FE/BE ● チーム横断の進⾏管理 ● プロダクトチームごとにルールや⼿順が分散 ● プロダクトやサービスが増加につれ、時間や負荷が⾼まっている 定期リリース バクラクのリリース
Slide 31
Slide 31 text
© LayerX Inc. 31 ● もともとSlackのスレッドで対応してい たものをService Console上に実装 ● まずは可視化するところからスタート ● 開発者体験改善もしないが劣化もしない 定期リリース改善 - 1 バクラクのリリース
Slide 32
Slide 32 text
© LayerX Inc. 32 ● 定性的なアウトカムとしては進⾏するSREが全体感の把握、 ● 各フェーズのSWEが⾃分の担当がすぐに分かるように ○ before: ⻑いSlack スレッドを遡っていた ● 定量的には1回あたり数時間短縮(ことも) ○ (まだトラブルで遅くなることもある) ● とはいえ⾃動化していくポイントが⾒えて来る ● ボトルネックも分析できるように 定期リリース改善 - 2 バクラクのリリース
Slide 33
Slide 33 text
© LayerX Inc. 33 ● もともとチームごとに持っていた(Slack botやNotion)リリース ⼿順の吸収 ○ ⼊社が浅いメンバーもリリース担当することもある ● Service Consoleが持ってるサービス情報との統合 → リリースフローを脱属⼈化 定期リリース改善 - 3 バクラクのリリース
Slide 34
Slide 34 text
© LayerX Inc. 34 ● ⼈間によるデプロイと進⾏→AIエージェントによる⾃動進⾏ ● 依存関係によるデプロイ順番の制御 ● ⼈間が本当にトラブルが起きたときだけ ● etc. 定期リリース改善 - 今後 バクラクのリリース
Slide 35
Slide 35 text
社内への展開 The Internal Developer Platform for Bakuraku
Slide 36
Slide 36 text
© LayerX Inc. 36 普及 1. 利便性で訴求しつつ 2. 使わざるを得ない場⾯を作る 3. 社内の流⾏りに乗っかる 社内への展開
Slide 37
Slide 37 text
© LayerX Inc. 37 1. 利便性 社内への展開 ● ⽇々の開発が便利になるツール ○ e.g. GitHub Actions finder (モノレポでCIを⽣成しているとかなりの数になる) ● 草の根 ○ チームやPlatformメンバー ○ エンジニア共有会で時間もらって紹介したり ○ リリースノートでアップで ● 当たり前だが便利だと思うと使ってくれる
Slide 38
Slide 38 text
© LayerX Inc. 38 e.g. GitHub Actions search 社内への展開 (再掲) モノレポはActions探すの⼤変になりがち
Slide 39
Slide 39 text
© LayerX Inc. 39 ● 先程の定期リリースのプロセスを乗せる = リリース⽇に必ず使う ○ どんなに便利でも忙しいと使ってもらえない ● ⽌めてしまうとビジネスインパクトもあるので緊張感 ● できるだけフィードバックをもらい、できるだけ毎回体験を向上 2. 使わざるを得ない場⾯ 社内への展開
Slide 40
Slide 40 text
© LayerX Inc. 40 ● 社員が広く使うAIエージェント(Shepherd) に連携 ● 専⽤CLIもつくったが、広く使われてる⽅を優先 3. 社内の流⾏りに乗っかる 社内への展開
Slide 41
Slide 41 text
© LayerX Inc. 41 ● 開発者のメンタルモデルを変えずに使えるように ○ 開発者がよく使う他のツールに揃える e.g. コマンドパレット、ダークモード ○ 短縮URLと CMD+k だけ覚えてもらう ● 定性のヒアリング ○ よく使ってくれてるユーザーに使い始めたきっかけやモチベーションを聞いてみたり ○ 逆に使ってくれない⼈に解決していない課題を確認したり ● 定量的での利⽤実態の把握(今後!) ○ Web/MCP共に利⽤ログを取り始めた こまかなところ 社内への展開
Slide 42
Slide 42 text
© LayerX Inc. 42 ● ⼈に聞く前に、まず⾒る場所ができた ● ツールは増えてるけど、覚えることが減った ● ここも⾃動化できない? ● ここが使いづらい (ネガティブなことも使ってくれている証拠!) ● セキュリティ情報も乗せたい! ● とりあえずService Consoleに連携するか 反響 社内への展開
Slide 43
Slide 43 text
AIエージェントとの共⽣ Enhance developers’ productivity through AI Agents
Slide 44
Slide 44 text
© LayerX Inc. 44 1. Service Console ⾃体の開発 2. ServiceConsoleでのAIエージェントをEnabling AIエージェントとの共⽣ AIエージェントとの共⽣
Slide 45
Slide 45 text
© LayerX Inc. 45 ● 基本的にはAIエージェントでほぼ100%開発している ○ アーキテクチャやスキーマはかなり⾒ている ● 課題解決のためなにを作るかアタリをつけるものの、アイディアを形にしながら洗練 ○ 作りすぎない、ちゃんと消す ○ c.f. 機能を作るな。楽して作るな。 ● サステナブルな開発のためにデザインや検証のSkillなども 1. Service Console ⾃体の開発 AIエージェントとの共⽣
Slide 46
Slide 46 text
© LayerX Inc. 46 ● AIエージェントがgenericに各クラウド、SaaSにリクエストするのではなく意図を持って⾏う ● より効率的にAIエージェントがバクラクエコシステムを理解できるように 2. AIエージェントをEnabling AIエージェントとの共⽣ AIエージェント GitHub Datadog AWS Google Cloud something AIエージェント GitHub Datadog AWS Google Cloud something Service Console
Slide 47
Slide 47 text
© LayerX Inc. 47 さらなる共⽣にむけて ● 現状AI向けに提供しているツールはRead Only中⼼ ● 読んで終わりではなく、実⾏し、その結果がまた戻ってきて次につながるように ○ (権限管理や監査等安全性を⾼めつつ) ● Human in the loop → Human on the loop AIエージェントとの共⽣
Slide 48
Slide 48 text
Takeaways まとめ
Slide 49
Slide 49 text
© LayerX Inc. 49 ● ツールの選定よりもモデリングが⼤事 ● ⼈間もAIも適切なコンテキストで認知負荷を下げる ● 開発コストは下がったが何を作るとよいのか? ● AIエージェントをつくるのも⼤事だけど、AIエージェントが使う道具も同じくらい⼤事 ● 利⽤されてるAIにあったインターフェイス (MCPが必ずしも最適ではない) Starting IDP? Takeaways
Slide 50
Slide 50 text
© 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)
Slide 51
Slide 51 text
開発者プラットフォームは⼈もAIもユーザー AIエージェントが開発者を置き換えるのではなく、 AIエージェントを通じて開発者をアウトカムにつなげるプラットフォームへ
Slide 52
Slide 52 text
© LayerX Inc. 52 We are hiring! LayerX Open Door 事業部‧テーマ別にカジュアル⾯談を公開しています。 アカウント登録は⼀切不要です! ‧メンバーと話してみたい ‧質問したいことがある ‧選考に進むか悩んでいる などなど、お気軽にお申し込みください。 Bakuraku Engineering Team Deck バクラクが挑んでいる課題、エンジニアリング組織の技術ス タックや開発カルチャーについて紹介しています。 AI を活⽤した「爆速開発」の裏側や、具体的な選考フロー‧ト ライアル⼊社の内容についても掲載しています。 バクラク エンジニア Deck