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

ビジネスを駆動するアーキテクチャへ ~AI-Agentという新しいアクター

Avatar for MonotaRO MonotaRO PRO
November 20, 2025
740

ビジネスを駆動するアーキテクチャへ ~AI-Agentという新しいアクター

2025.11.21 アーキテクチャConference 2025

Avatar for MonotaRO

MonotaRO PRO

November 20, 2025
Tweet

More Decks by MonotaRO

Transcript

  1. 2 本日お話しすること • MonotaROと基幹システム • これまでの軌跡 • 何を変えたいのか • AI-Agentという新しいアクター

    • 組織とアーキテクチャの再編成 • 混沌とチャレンジ • これからのモノタロウ
  2. 21 ここまでの成果 • 逆コンウェイ戦略に則った組織変更 • 新たなドメイン仮説: 在庫ドメイン • EDA+ES+CQRS の

    PoC → 本番投入 • 在庫状況管理の中核テーブル更新をイベント化 • 基幹システム全体のToBeモデルを描く • ドメイン分割の仮説を刷新
  3. 26 モノタロウが変えたい3つのこと : 開発手法 (技術) オンプレ + 全部盛り巨大DB + テーブル駆動設計

    + スクリプト的実装 クラウドシフト + ドメイン別DB + スキーマ駆動開発 + 業務に則したデータ型 変えていきたい 重要なのは概念設計 あらゆる粒度で 関心事の分離・カプセル化 DOJO エンジニア育成プログラム 実践を通じた学び MDI*エコシステム MonotaROの開発者がプラット フォームの機能にアクセスする際 のインターフェース * MonotaRO Developer Interface
  4. 36 「とりあえずMVP」の結果、思うこと 目指すべきは、利用部門による利用部門のための自働化 • AI-Agent開発、フィードバック反映、評価、配置まで利用部門で完結 • それって Agentic Autonomous Platform

    的なもの? • (非常に野心的だが) モノタロウはこの世界線を目指したい ◦ となると、やはりマニュアルは重要  過剰品質なんじゃ? • 「なんでも解ける汎用Agent」は非現実的だろう。 • 業務ごとにAgentを開発する必要。 • 業務あたりの改善効果はそう大きくない。 • 業務ごとにエンジニアを投入してはROIが...  ➡ プラットフォーム化が必要
  5. そもそも 「業務」は 無数の アレコレ で構成されている • 業務例 「〇〇という商品の在庫配置を、東西で70:30にする」 ◦ 倉庫の場所を確保

    ◦ 輸送を手配 ◦ サプライヤに相談 ◦ 自動発注設定を見直し … 37 「とりあえずMVP」の結果、思うこと
  6. 38 「とりあえずMVP」の結果、思うこと マニュアルに書かれているのはこの「アレコレ」 • アレコレ is 何 ◦ 目的を達成するための手順、システムの使い方、連絡方法... ◦

    システムの使い方ではなく、スプシでのアレコレかも? ◦ さらには「誰々に聞く」とか、念のため、とか... e.g. 倉庫の場所を確保 : ① A画面で〇〇の数量を確認する ② B画面で直近の出荷状況を確認する ③ AからBを減じた値をC画面の△△に登録する ④ 登録結果をC画面で確認したら、××部門の担当者にメンションする
  7. 41 必要なのは IT化 だった󰷻 業務の複雑性をシステムに隠ぺい → それはスペシャリストの仕事 • エンジニアが知識を蓄え、トレーニングにより得たケイパビリティ ◦

    要するにビジネスアナリシス ◦ つまりIT化のスペシャリストの仕事 • 利用部門の方々は、業務のスペシャリストであっても、 IT化のスペシャリストではない
  8. 42 必要なのは IT化 だった󰷻 󰷻IT化のマニュアルが必要ということ?󰷻 • 手順を抽象化し「宣言的に業務を行う」を言い換えると ◦ 業務の目的を達成するための手順を再構築 するということ

    (煩雑なアレコレ → シュッとさせる) ▪ これまではIT化のスペシャリストがやってきた これからはAI-Agentがやる...のか? ◦ マニュアルとして必要なのは、 与えられた目的を構成する要素(状態)に分解し、その状態に至る 必要な情報, 操作, パラメータを決める手順? (少なくとも画面の操作方法やスプシの値コピペ手順ではなさそう)
  9. 43 必要なのは IT化 だった󰷻 ヒトは意思決定する • 実現したいこととパラメータを決め、その理由を探求する ◦ 在庫の東西配置を変えたい。変更後の東西比率を示す。 ◦

    理由は、関東で需要が高まっており、配送費を抑えるため。 Agentは実現する • 目的を状態(場所確保、輸送手配...)に分解し、操作とパラメータを決定 • ツールを組み合わせて状態を実現し、総合する能力が必要 󰷻どうすればこの世界線に到達できるのか󰷻
  10. 46 基幹システムとして必要なこと 所定の業務ルールに従って自動的にI/P/Oするシステム • 基幹システム: Systems of Activities (SoA) ◦

    プロセスに沿って粛々と I/P/O する ◦ 情報(R)と操作(CUD)、およびその仕様を適切に公開 ◦ (権限のある)誰もが容易に使える状況に https://gihyo.jp/book/2024/978-4-297-14010-6
  11. 47 基幹システムとして必要なこと SoA の振る舞いを監視・変更するシステム • 業務システム: Systems of Controls (SoC)

    ◦ SoAへの指示・介入を目的とする ▪ パラメータを変更したり、新たなルールを設定する ◦ SoAが公開する情報と操作の仕様に精通して、 プロセス(=業務)を構築する
  12. 49 基幹システムとして必要なこと 受注No.xxxx は キャンセル 受注No.xxxx の 出荷状況 は? 優先倉庫の

    パラ メータ変える 当日出荷締め切 り前倒し 新しい プロセスを 定義 業務プロセスA 業務プロセスB 業務プロセスC 業務機能群 (ドメイン群)
  13. 50 基幹システムとして必要なこと AI-Agentによる業務の代行・自働化を実現するには • 十分にプリミティブな機能(インタフェース)が公開されている(SoA) • SoAの機能を組み合わせて ワークフロー を定義できる(SoC) •

    業務目的を構成する状態 に適したワークフローを選定する(Agent) いずれは AI-Agent が、未定義の業務目的に対して 自らワークフローを定義することも期待する。(きっと当社DS部門が)
  14. 受注No.xxxx は キャンセル 受注No.xxxx の 出荷状況 は? 当日出荷締め切 り前倒し 新しい

    プロセスを 定義 業務プロセスA 業務プロセスB 業務プロセスC 業務機能群 (ドメイン群) 51 基幹システムとAI-Agentの関係 優先倉庫の パラ メータ変える
  15. 56 モダナイゼーションのこれから 見えてきたもの: 技術 ← p.26 • 開発手法は部分的に刷新された ◦ DOJO,

    MDIなどの取り組みにより変わりつつある • DDD+EDA+ES+CQRSの本番投入 ◦ 後に続く案件もある ◦ ドメイングループごとの取り組みも始まった
  16. 57 モダナイゼーションのこれから 見えてきたもの: 人 ← p.27-28 • 個人の行動変容を支援する仕組み ◦ DOJOコンテンツによる学びをフォローアップする場

    ◦ 部門ごとチームごとの勉強会をつなぐHUBとして期待 • 文化醸成のアプローチが見えてきた...? ◦ 正直わからん ◦ 地道に続けることでしか成し得ないと思ってる
  17. 58 モダナイゼーションのこれから 見えてきたもの: アーキテクチャと組織 • AI-Agentという新しいアクターへの対応 ◦ 突き詰めれば使われる側である既存アプリケーションの整備が重要 ◦ RPAやBrowser-useで画面に依存するのは急場しのぎか

    • 目指すべきアーキテクチャの姿が明確に ◦ 目的に沿ったレイヤリング (SoA,SoC + Agent) ◦ きっと開発メンバのケイパビリティも異なるはず • 組織の姿も ◦ 必要なケイパビリティをチームに凝集し、適度な結合度を目指す