AIエージェントが変える開発組織のEnabling #開発生産性con_findy

2025年7月3日に開催された「開発生産性カンファレンス 2025」で、LayerX バクラク事業 CTO 中川（@yyoshiki41）が発表した資料です。

Transcript

1. © LayerX Inc. AIエージェントが変える開発組織のEnabling Yoshiki Nakagawa / バクラク事業 CTO 開発⽣産性カンファレンス2025 / 2025.07.03
2. © LayerX Inc. 2 @yyoshiki41 株式会社 LayerX 執⾏役員 バクラク事業 CTO 株式会社エウレカにて、インフラエンジニアとして国内 最⼤のマッチングアプリを運営。フリーランスとして、 ⾳声配信アプリ、⾦融サービス、産学連携プロジェクト などを経験。2020年株式会社LayerX⼊社。 中川 佳希 / ナカガワ ヨシキ ⾃⼰紹介
3. © LayerX Inc. 3 ⼊社から ⾃⼰紹介 2020/06 株式会社LayerX ⼊社 2020/07 LayerX Invoice（現バクラク）開発開始 1⾏⽬のコードから書き始める 2021/01 LayerX Invoice サービス公開 2021/06 プロダクト TechLead ドメイン理解と開発 2022/07 プロダクト横断の開発組織 Enabling Team プロダクト数の増加を⽀える 2024/01 バクラク事業 CTO 事業, 技術, 組織の視点でみる
4. バクラク事業について
5. 5 © LayerX Inc. 「すべての経済活動を、デジタル化する。」をミッションに AI SaaS と AI DX の事業を展開 事業紹介 バクラク事業 企業活動のインフラとなる業務を 効率化するクラウドサービス Fintech事業 ソフトウェアを駆使したアセットマネジ メント‧証券事業を合弁会社にて展開 AI‧LLM事業 社内のナレッジやノウハウをデータ ベース化するAIプラットフォーム AI SaaSドメイン AI DXドメイン
6. 6 © LayerX Inc. AIを10年に⼀度のパラダイムシフトと捉えこの未来にBetする AI Coding Meetup #2 開催⾵景
7. 7 © LayerX Inc. バックオフィスから全社の⽣産性を⾼める バクラクは、稟議、経費精算、法⼈カード、請求 書受取、請求書発⾏、勤怠管理などの業務を効 率化するクラウドサービスです。 AIを組み込むことで、⼿⼊⼒や紙の管理などの業 務から解放し、従業員⼀⼈ひとりがコア業務に 集中できる新しい働き⽅を創造します。
8. 8 © LayerX Inc. 導⼊実績 ※⼀部企業様を抜粋して掲載しています ※1東京証券取引所 グロース市場に上場している企業を対象にした数値（2024年12⽉末時点） ※2東京証券取引所 グロース市場に2024年に新規上場した企業を対象にした数値（2024年12⽉末時点） 東証グロース市場 上場企業の5社に1社が導⼊※1 2024年に新規にグロース上場した企業の20%※2が活⽤
9. 9 © LayerX Inc. ラインナップ ‧AIが請求書を５秒でデータ化 ‧仕訳 / 振込データを⾃動作成 ‧電帳法‧インボイス制度にも対応 債務管理（⽀出管理） ‧年会費無料で何枚でも発⾏可 ‧カード利⽤制限で統制を実現 ‧通常1%以上の還元 法⼈カードの発⾏‧管理 ‧AI活⽤の消込機能で⼊⾦消込をラクに ‧取引先へリマインド/未⼊⾦督促を半⾃動化 ‧売上仕訳‧⼊⾦仕訳も柔軟に作成 債権管理（⼊⾦管理） ‧AIが⾒積書‧請求書を５秒でデータ ‧スマホからも申請‧承認OK ‧柔軟な通知設定‧承認の催促機能 稟議‧⽀払申請 ‧直感的UIで従業員の負担を軽減 ‧Slack連携で打刻や⾃動リマインド可能 ‧わかりやすい残業 / 休暇管理レポート 勤怠管理 ‧AIが領収書を5秒でデータ化 ‧スマホアプリとSlack連携あり ‧領収書の重複申請などミス防⽌機能 経費精算 ‧帳票の⼀括作成も個別作成も⾃由⾃在 ‧帳票の作成‧稟議‧送付‧保存を⼀本化 ‧レイアウトや項⽬のカスタマイズも可能 請求書発⾏ ‧スキャナ保存データも直接取込  ‧AI-OCRが⾃動読取＆データ化 ‧[取引先][取引⽇][取引⾦額]での検索 帳票保存‧ストレージ 25年3⽉ 提供開始 25年1⽉ 提供開始
10. ⽬次 Agenda • The Agentic Era • バクラクにおける Enabling • 認知負荷理論 • AI Coding 時代の Enabling
11. The Agentic Era
12. 12 © LayerX Inc. The Agentic Era 2021/06 GitHub Copilot テクニカルプレビュー公開 OpenAI との共同開発 (GPT-3 後継のCodex) 2022/06 GitHub Copilot 正式リリース コード補完 2022/11 ChatGPT リリース (GPT-3.5) 2023/03 Cursor（Anysphere）登場 ルールとコード⽣成 2024/12 Devin（Cognition）リリース リモート環境 Agents 2025/05 Claude Code（Anthropic）GA リリース Terminal Agents
13. 13 © LayerX Inc. AI Coding は、⼈のアシスト（近傍のコードからの補完）から⾃律的にコードを書く Agent へと変化してきた ⼈間が「スクラッチでコードを書く」時代は終わりを迎え、少なくともコーディングは全く 別の仕事になった ただ、それはエンジニアの仕事がなくなった事を意味しない！ （少なくとも現⾏ツールの延⻑線上で、エンジニアなしとなるには⼤きな隔たりがある） 2025年は Agent 元年
14. 14 © LayerX Inc. “チャット形式で LLM と反復的なやり取りを⾏い、コードの完成を⽬指すプログラミング” Steve Yegge が提唱 ChatGPT に端を発した LLM との対話形式から、 現在では主要なプログラミングスタイルとして普及。 IMO: Sourcegraph など⼀部でしか使われていない⾔葉だが、Vibe Coding ではなく現実の 業務を反映していると感じる。 Chat-oriented programming (CHOP)
15. 15 © LayerX Inc. 破壊的な技術に対して、拒否反応や悲観でない、 組織の在り⽅や⼿法をアンラーニングする必要がある（もしくはそのタイミングである） The future isn’t human(junior) vs AI — it’s human(junior) with AI. ref. Mastering AI at FAANG: A Roadmap from Junior to Senior Engineer ※ このブログではジュニアに焦点を当たっているが、より広義のエンジニアに当てはまる vs AI ではなく、with AI
16. 16 © LayerX Inc. エージェントを ”⾃律的にタスクを遂⾏し⽬的を達成するシステム” と定義すると、 ⼈間が判断し⾏っている多様なユースケースを⾃動化出来る可能性を⽰している AI エージェントはデジタルな労働⼒ スケール 同じパフォーマンスで 24/7 稼働、季節性などにも依存しない 柔軟性 固定やルールベースでカバーできない、より動的な動きが可能 機械的な動作 定められた⼿順や⽂字通り「機械的」な動作を実⾏し、ルーチン業 務の処理も可能
17. 17 © LayerX Inc. AI エージェントで開発⽣産性は上がっているか？ Writing is easy, reading is hard 素朴な⾔葉だが、同じ感覚の⼈が多いはず ボトルネックが単にコーディングだったのであれば、解消に向かっている ただし、⽣成されるコードの品質は課題として残る
18. 18 © LayerX Inc. AI エージェントで開発⽣産性は上がっているか？ （実装フェーズにおいて）部分的に Yes. ただ全体パイプラインにおいては、実装のみでは価値がなくデリバリ〜カスタマーサクセス を達成してアウトカムに繋がる。（全体パイプライン上での出⼒を測る必要性、単純なプル リクエストによるコード変更やリリース回数で測れない事を意味する。）
19. 19 © LayerX Inc. SaaS では、従業員⼀⼈当たりARR（年間定期収益）が⽣産性指標や健全性の把握に使われ る事がある。（ARR 1,500万円がシミュレーションの値に⽤いられる。AI 活⽤の業務浸透で 今後基準値が上がっていくと予測される。） 注釈：現実にはディストリビューションに要する時間があるため、Recurring Revenue ⾃体 は遅効的な数値 AI エージェントで開発⽣産性は上がっているか？
20. 20 © LayerX Inc. AI エージェントで開発⽣産性は上がっているか？ 全体最適の観点で、「何を作り、提供するか？」や「成⻑可能な品質をどう保証するか？」 が別の課題として残る（現状では⼤きくは変わっていない点）
21. バクラクにおける Enabling
22. 22 © LayerX Inc. 1. Stream-aligned team 特定ビジネスドメインにおいて、⼀連のフロー（機能を開発‧リリース‧運⽤）を担当する 2. Enabling team Stream-aligned team とコラボレート、開発の障害を取り除き、システムや組織に必要な機 能の発⾒やその技術の伝搬を担う 3. Complicated Subsystem team 専⾨知識を要するシステムの開発や運⽤に携わる 4. Platform team デリバリを加速するための社内サービス （X-as-a-Service） を提供するよう振る舞う Four fundamental topologies (Team Topologies)
23. 23 © LayerX Inc. Stream-aligned team がよりビジネスドメインに集中できる環境をつくる 1. 決められた期間内で共同での作業を⾏う (Collaboration) 2. 「サービス」として開発、提供して、他のチームが利⽤する (X-as-a-Service) 3. 新しい仕組みを可能にし、それを伝搬する (Facilitating) ▪ Stream-aligned team ▪ Enabling team ▪ Complicated Subsystem team ▪ Platform team https://teamtopologies.com/key-concepts ３ core interaction modes (Team Topologies)
24. 24 © LayerX Inc. 認知負荷理論（Cognitive Load Theory） ⼈間の認知能⼒には限界があり、情報処理の効率性を⾼めるために認知負荷を管理、デザイ ンするための理論 ⼈が能動的に学習を⾏いながら、成功を導くために効果的などのようなサポートが⾏えるか 教育⼼理学から始まったもの Team Topologies の背景にある認知負荷理論
25. 25 © LayerX Inc. ⼈間の認知プロセスのモデリング • ⻑期的な記憶 ◦ ⻑期間にわたって情報を保存するスペース、容量に制限がないと考えられている ◦ 定着したものは無意識的に利⽤される • ワーキングメモリ ◦ ⼈間の認知活動中に、情報の保持と処理が同時に⾏われるスペース ◦ ⻑期的な記憶の容量と異なり、有限で貴重なリソース ◦ この限られた容量を効率的に使⽤するかが学習において重要とされる • 認知負荷 ◦ 情報を処理する際にワーキングメモリを消費する負荷 ◦ ３種類に分類される 認知モデル
26. 26 © LayerX Inc. 1. 課題”内”在性負荷（intrinsic cognitive load） a. 学習対象そのものの複雑さ（要素の困難度により⽣じる負荷）であり、変化させ ることが出来ない 2. 課題”外”在性負荷（extraneous cognitive load） a. 学習対象とは直接関係のない認知負荷でワーキングメモリの容量を消費する要因 となるため、最⼩化すべき 3. 学習促進負荷（germane cognitive load） a. ⻑期記憶の知識構築に役⽴つ認知負荷で、⽣産的な意味を持ち、よりワーキング メモリのリソースを割く事が求められる b. ワーキングメモリから課題内在性負荷と課題外在性負荷を引き、残された容量が 割り当てられる最⼤値と仮定される 3つの認知負荷
27. 27 © LayerX Inc. 1. 課題内在性負荷：送⾦に関わるシステムの仕様を理解する 2. 課題外在性負荷：まず認証の仕組み、次にサーバー起動⽅法を検討、イベントは... 3. 学習促進負荷： 送⾦システムを構築する事を⽬指す 3つの認知負荷の例
28. 28 © LayerX Inc. Stream-aligned team が開発に集中できる環境をつくる Enabling Team では課題外在性負荷を最⼩化して取り除き、 開発者のワーキングメモリがドメイン内での開発に最⼤限充てられることを⽬指してきた
29. 29 © LayerX Inc. Enabling Team としての取り組み 1. Code Generation a. 新しいサービスに必要となる⾜回りのコードを⽣成する i. スキーマからのコード⽣成 ii. 認可も宣⾔的に記述するのみで実現される 2. System Foundation a. すぐに利⽤可能なシステム的な基盤を提供する i. Gateway が、Front-end からの Single entry point となる ii. イベント処理基盤も宣⾔的な定義からルーティングや制御が可能 3. Developer Experience a. 開発者環境のアプリケーション起動、デバッグを容易にする ビジネスドメインの拡⼤を実現するバクラクシリーズでのモノレポ開発 - Developers Summit 2024 -
30. AI Coding において考えるべき認知負荷
31. 31 © LayerX Inc. チャットインターフェイスから誰でもコーディングを始められるが、 ⾃然⾔語の指⽰から期待通りのコード出⼒をえて理解するには、能⼒‧技能が求められる。 AI は簡単に課題外在性負荷を増幅させる。開発者⾃⾝でステップや出⼒をデザインしないと ワーキングメモリを簡単にオーバーしてしまう。 Chat-oriented programming (CHOP)
32. 32 © LayerX Inc. ワーキングメモリをオーバーしている状態では、学習対象に脳のリソースを割けない この状態では複雑な事を理解することが困難であり、また能動的に処理するための動機付け （モチベーション）が失われることも起きる ワーキングメモリから溢れた状態
33. 33 © LayerX Inc. 課題外在性負荷を最⼩化する意識は、個⼈開発者レベルにおいても重要度が増している。 e.g) AI に暗黙的な仕様が隠された状態ではないか、データ表現には決められたスキーマを与 えているか、既存の振る舞いまで壊していないか 👉 AI Coding でシェアされているナレッジは、課題外在性負荷の最⼩化の理に適っている。 • まずプランを⽴てさせる（タスクをチャンクする） • 「振る舞いの変更」と「構造の変更」を分離して⾏う • テストから始めてガードレールを敷く（アサーションは⼈が確認する） AI Coding Meetup #2 を開催しました #aicoding AI のイネーブルメント
34. 34 © LayerX Inc. 課題外在性負荷には⽬的に関係しない複雑性以外に、ストレスやマルチタスク等も含まれる ⼈の脳はコンピュータのように複数のCPUに情報を分散させ、”並列” 処理するような機能 は備わっておらず、逐次でしか情報を処理できない。マルチタスクでこなせているように感 じても、実際は複数のジョブを細分化して⼊れ⼦にし、“並列的” に処理しているに過ぎない （コンテキストスイッチは常に起きている）。 👉 AI Coding は簡単に実装並列数を上げれるが、開発者に深い思考（Deep Thinking）を要 するタスクや学習とは相性が悪い。 本質的なタスク以外でワーキングメモリが溢れる可能性がある。 学習を妨げ、課題外在性負荷を上げるアンチパターンもある
35. AI Coding における Enabling
36. 36 © LayerX Inc. 「システムをデザイン出来て、それを指⽰にして伝える能⼒」 => Prompt Engineering 「AI が指⽰通りに動ける環境や背景を整えること」 => Context Engineering 「⽣成されたコードをレビューして、品質をより引き上げる技術」 => Reviewer Skills Chat-oriented programming (CHOP) に求められる能⼒や技能
37. 37 © LayerX Inc. Prompt という⼊⼒情報のみではなく、より広く⽂脈‧前提条件やその順序と量まで設計対 象に含む Context Engineering へ 新たに Enabling が必要なエンジニアリング領域 The rise of "context engineering" image from Dex Horthy on X. Context Engineering
38. 38 © LayerX Inc. 複雑性が⾼いプロジェクトでは、AI がよく落とし⽳にはまる • プロンプトを何回変えても求めてる期待に答えてくれない • 指⽰の達成のために、既存の振る舞いを壊し始める 開発者が AI を落とし⽳から救うには、プロンプトに限らず⽂脈を補う Context Engineering が必要。 開発者と AI の双⽅が利⽤可能な背景情報、⽂脈を整えて提供する Pitfalls（落とし⽳）
39. 39 © LayerX Inc. 開発ドキュメントとコードベースを同じ場所で管理する 問題：Design Docs などの開発系ドキュメントが Notion にあり、AI Coding ツールにナレッ ジとして与えるのが難しい 解決⽅法：ドキュメントとコードベースを同じ場所（= Git レポジトリ）で管理 👉 Design Docs はある機能や仕組みを実装するための設計情報、チーム内外でコンセンサ スを取るためにも⽤いる。だれの何の問題を解決するのか、アーキテクチャやサービスのイ ンターフェイス、データモデルはどう定義するか、など具体的な実装指針を記したもの。 Design Docs は実装⽅式が変わるたびに可能な限り更新し、最新の状態を維持することが望 ましい。現在 300 ファイル以上。
40. 40 © LayerX Inc. Notion to Markdown の実装 1. Notion API 経由でページを⼀括取得 2. Notion 固有の Block 構造を Markdown に変換 3. docs/ 配下にコミットする
41. 41 © LayerX Inc. 過去の Pull Request を参考に定型化した開発⼿順、AI ルール 1. ⼿順が複数あるが、定型化出来る開発を選ぶ 2. 過去の Pull Request をピックアップ 3. LLM にコード変更から、Markdown ドキュメントを⽣成
42. 42 © LayerX Inc. PRD（製品要求仕様書）を整形する（MCP） 1. Notion に会話ログ含め、議論をまとめずに書き起こす 2. 仕様が固まったら、Notion MCP で吸い出す 3. LLM に、マークダウン形式でまとめてもらう 4. Git にコミット 5. 以降、変更があれば Git 内で修正を⾏う 6. 実装時には、PRD.md を参照させる
43. 43 © LayerX Inc. 検索ツール（Chrome 拡張） 開発者⾃⾝の学習を⽀える為の検索ツール 1. コード検索 2. 外部仕様検索 3. データベース、ログ検索 AI 系ツールは量も多く、流れも早いため、 （開発者以外も含め）マインドシェアをできるだけ奪わず、 ⽇常的に使ってもらえるものを提供する。 コードと ドキュメント を横串で検索 使った履歴 リクエストログを ⾃然⾔語で説明 してくれるアプリ
44. 44 © LayerX Inc. 検索ツール（Chrome 拡張） 開発者⾃⾝の学習を⽀える為の検索ツール インストラクションデザイン 学習者の認知負荷を考慮、効果的な学習を促すための設計のこと • ⼀度に情報を与えすぎず、必要なときにリーチできる • 開発者⾃⾝のために最適な学習を⽀える
45. Summary
46. 46 © LayerX Inc. 開発チームと AI、双⽅の Enabling が求められる時代に LLM や AI Coding は⽇々進歩しているが、⼈の処理能⼒、ワーキングメモリには限界がある Enabling としては課題外在性負荷を取り除くために出来ること、 また開発者個⼈では AI による課題外在性負荷を⽣み出さない注意深さも必要 Enabling の対象は広がった
47. Fin
48. AIカンファレンス「Bet AI Day」2025年8⽉1⽇(⾦)@ONLINE なぜ今「Bet AI」なのか。CTO, CPO, VPoEたちが語るAI戦略と技術のリアル。 ご登録はこちらから https://layerx.co.jp/events/2025/bet-ai-day
49. オンライン配信 https://layerx.co.jp/events/2025/bet-ai-day AIカンファレンス「Bet AI Day」カウントダウンイベント 7⼈ x 7⽇間！ 49⼈のLTでAI知⾒を⼤公開！ ご興味がある⽅は下記にご登録ください。 後⽇詳細情報をお届けします。