Slide 1

Slide 1 text

AIと共に進化するモノタロウ 1 AI駆動開発 Conference Autumn 2025 © 2025 MonotaRO Co., Ltd. All Rights Reserved. 常務執行役・CTO 普川泰如 AI駆動開発チームリーダー 市原功太郎 OSLプロダクト開発 PM 山本華名美 株式会社MonotaRO

Slide 2

Slide 2 text

生成AIの隆盛をどう見ているか 2 ● インターネットの登場に比肩する変革をもたらす ● 流行や一過性のものではなく、不可逆な変更である 認識 対応方針 AIを理解し、活用できる組織へ変化する

Slide 3

Slide 3 text

お話しする 2つ のテーマ 1 どのようにAI駆動開発の組織への展開をすすめたか AIによる不可逆な変化と組織のチェンジマネジメント 2 実践から見えた学びと次の一手 置き換えが鍵!飛躍的な生産性向上のための要点

Slide 4

Slide 4 text

アジェンダ 1. どのようにAI駆動開発を組織へ展開したか 2. 現場から!AI実践事例 3. 実践から見えた学びと次の一手

Slide 5

Slide 5 text

自己紹介 5 名前  市原 功太郎 役職  CTO-Offce AI駆動開発チームリーダー 新卒入社してからずっとこの会社 GitHub CopilotやCline、Cursor、Devinの導入を 企てた人

Slide 6

Slide 6 text

コンテキスト 当社:モノタロウについて 6

Slide 7

Slide 7 text

モノタロウの事業 BtoB を対象に、 自ら間接資材の在庫を持ち、 自らオンラインで売るEC企業 商品採用、物流、SCM、マーケティン グ、データサイエンス、IT など多くの業務とシステムを 自社開発、自社運用もしている フルスタック EC カンパニー 7

Slide 8

Slide 8 text

お客様の「時間価値を高める」ために、中小企業・大企業 それぞれのニーズに合わせたサービスを提供       大企業向け 独自の購買管理システム/システム連携 提供しているサービス       中小企業向け ECサイト(monotaro.com) 8

Slide 9

Slide 9 text

モノタロウの事業 ※2024年(単体)の実績 9

Slide 10

Slide 10 text

モノタロウのシステムとエンジニア組織 コアシステムエンジニアリング (CSE)部門 Mission 業務例 ビジネスの成長を 支えるITの提供 顧客体験向上の ための継続開発 大企業ビジネスの 成長加速 より良い仕事環境 の提供 価値提供の 基盤開発 ● 内製基幹システムの導入、開発、運用 ● 倉庫管理システム/インフラの構築、運用 ● 会計システムの開発、運用 ● ECサイト機能の開発、運用 ● マーケティング基盤の開発、運用 ● 大企業連携システムの開発、運用 ● オフィスインフラの構築、保守運用 ● オフィス系サービスの導入、運用 ● ITサポート ● セキュリティ統括 ● サーバインフラの構築、運用 ● データ基盤の構築、運用 ● システム開発/保守基盤の構築、運用 ● DevOps/Webセキュリティ ECシステムエンジニアリング (ECSE)部門 エンタープライズビジネス エンジニアリング(EBE)部門 コーポレートエンジニアリング (CE)部門 プラットフォームエンジニア リング(PE)部門 部門 10

Slide 11

Slide 11 text

エンジニアリングのチャレンジ 事業成長に貢献するため、 アーキテクチャの再構築とシステムのモダナイズに挑む 現在の課題       取組方針 システム・業務の長年の変化に伴う複雑性 20年間の安定した成長に伴い、組織とシステムも拡 大。そのため、新たな取り組みに対する調整コストが 増加している状況。 また、サービスが高度化し、独自の発展を遂げている ことにより、システムの複雑性が増している。 変更容易性の低下 システムが複雑になるにつれて、経営戦略や戦術への 迅速な対応が難しくなっている。 注力すべきサービスの進化に十分なリソースを割り当 てることが困難な状況。 方針:分割統治 大きな問題を小さな部分問題に分割し、それぞれを個別に解決する「分割 統治」戦略を採用。これにより、システムの複雑性を制御可能な範囲に抑 え、事業のさらなるスケールにも貢献する。 方法:ドメインモデリングと イベントドリブンアーキテクチャの導入 システムをビジネスドメインごとに分割し、各ドメイン間の連携をイベ ント駆動で行うアーキテクチャを採用。これにより、システムの変更容 易性を高め、ビジネスの変化に迅速に対応できる基盤を構築する。 11

Slide 12

Slide 12 text

お話しする 2つ のテーマ 1 どのようにAI駆動開発の組織への展開をすすめたか AIによる不可逆な変化と組織のチェンジマネジメント 2 実践から見えた学びと次の一手 置き換えが鍵!飛躍的な生産性向上のための要点

Slide 13

Slide 13 text

どのようにAI駆動開発を組織へ 展開したか 大きく導入、あとから検証 13

Slide 14

Slide 14 text

春の登壇時(2025.05)からの状況変化 ● Devin : 160名 → 340名 ○ 継続利用する! ● Cursor : 40名 → 220名 ○ 標準に昇格! ● Cline: 100名 → 40名 ○ 縮小! ● 新たなツール検証 ○ Claude Code, Codex → 20名 ○ Windsurf → 50名で実験、要件に合わず中断 14

Slide 15

Slide 15 text

AI駆動開発の取り組み 2023年: 黎明期 GitHub Copilotの展開 2024年: 模索期 AIによる モダナイゼーションプロ ジェクト 2025年1月: ツール展開 AI駆動開発チーム始動 2025年8月 取り組み結果を経て 方針のUpdate 15

Slide 16

Slide 16 text

AIツール活用度をどのように上げるか 人数 AI駆動開発への熱意 → ツールの活用度合い キャズム ● ツールの活用度合いはAI駆動開発への熱意の分布とだいたい同じになる ● ツールが展開しても、使いこなしている人が一部なので組織として大きな効果がう まれない

Slide 17

Slide 17 text

人数 キャズム 17 我々が ”超えたキャズム” と “超えられていないキャズム” ● 「AIツールの展開」についてはうまくいったが、生産性の向上を起こすような「AIによる プロセスの変容」まで繋げられているのは一部のメンバー ● 要するに「AIによる開発プロセスの変容」はまだキャズムを越えることができていない ! AI駆動開発に情熱がある メンバー “熱量” を “文化” へ AI駆動開発への熱意

Slide 18

Slide 18 text

18 AI駆動開発を浸透させるための仕組み

Slide 19

Slide 19 text

19 AI駆動開発を浸透させるための仕組み

Slide 20

Slide 20 text

AI駆動開発チームのミッション モデルとツールの進化の恩恵を最大化するべく①組織にAI駆動開発ツー ルを展開し、②AI駆動開発の浸透をすすめ開発生産性を向上させる 展開 1 2 AI駆動開発の浸透

Slide 21

Slide 21 text

21 浸透させるための仕組み—DOJO

Slide 22

Slide 22 text

浸透のための仕組み—DOJO AI駆動開発 DOJO • 当社の組織学習機関 DOJO にAIについての学習プログラムを追加 • 直近事例: – Cursorの入門ハンズオン(2h)を実施 • 初心者ターゲット、70名程度が参加 • 帯制度 – AI駆動開発で求めるケイパビリティを定義して能力を認証する – 現在、入門レベル(黄帯)のスキル標準を作成中 22

Slide 23

Slide 23 text

23 浸透させるための仕組み—トレンドラボ

Slide 24

Slide 24 text

浸透のための仕組み—トレンドラボ AI駆動開発トレンドラボ • 定期開催している社内勉強会 • ① AIに関する情報アップデート / LT • ② チーム別座談会 – 「課題・ツール・成果」を共有し、面白い取り組みが横展開される。 共感・関心から、AI活用事例をボトムアップに広げるための取り組み 24

Slide 25

Slide 25 text

現場のAI活用推進の仕掛け作り • 各種のAI駆動開発ツール(Devin/Cursor/Claude Code ect) • API Key発行管理(OpenAI/Anthropic/Gemini) • GitHubのOrganization Secretに各種のAPI Keyを設定 – OpenAI, Gemini, Anthropic, Devin – 活用例) PRをフックにコードレビュー、ドキュメント更新等 • チャットツール(Gemini, ChatGPT, LibreChat,MonoChat(Slack)) → 仕事の要求に応じて柔軟に組み立てられる 25

Slide 26

Slide 26 text

[事例] 社内の問い合わせに答える 大企業向けサービスのお問い合わせ対応 • 現場の悩みを現場で解決した事例 – 必要十分なエンジニアリング+LLM – スピーディなアイディア→実装 • 詳細は次スライドから! 26

Slide 27

Slide 27 text

現場から!AI実践事例 システム問合せ対応の迅速化 27

Slide 28

Slide 28 text

自己紹介 28 名前  山本 華名美 部署  エンタープライズ ビジネス エンジニアリング部門     OSLソリューショングループ 役職  プロジェクトマネージャー(何でも屋さん)  ※OSL…法人向け集中購買サービスの      ONE SOURCE Lite のこと      (このあと何度も出ます) 新卒入社してからずっとこの会社 AIは別に詳しくない

Slide 29

Slide 29 text

問い合わせ業務を 改善してこうなった   29

Slide 30

Slide 30 text

30 【前提】問い合わせ対応業務  ユーザー ? 営業チーム ①お問い合わせ ②システム関係の場合 転送 私のいる OSL開発チーム ③調査して回答 ④整理して回答

Slide 31

Slide 31 text

31 【前提】問い合わせ対応業務  ユーザー ? 営業チーム ①お問い合わせ ②システム関係の場合 転送 私のいる OSL開発チーム ③調査して回答 ④整理して回答 ここ!

Slide 32

Slide 32 text

営業チームからこういう問い合わせが来たとします (Slackでやりとりしてます) 32 AI活用実例

Slide 33

Slide 33 text

特定の絵文字をリアクションで押しますと・・・ 33 AI活用実例

Slide 34

Slide 34 text

ツールによる自動投稿 が30秒程度で来る 34 AI活用実例

Slide 35

Slide 35 text

 元の問い合わせ→ ↓一部拡大 35 AI活用実例

Slide 36

Slide 36 text

前回の対応を真似すれば いいので、 調査から回答までがスムーズ 36 AI活用実例

Slide 37

Slide 37 text

仕組み   37

Slide 38

Slide 38 text

38 仕組み概要図

Slide 39

Slide 39 text

39 仕組み概要図 SpreadSheetに全部詰め込んである 入力をベクトル化 → GASでシートから最も近いembeddingを探す → 該当行の情報を表示する のような簡易RAGモック (回答生成は人間の仕事)

Slide 40

Slide 40 text

対応記録シートが前からあった

Slide 41

Slide 41 text

Slackの情報をZapierで自動入力

Slide 42

Slide 42 text

対応終わったら人間が記録(これも 自動化したい)

Slide 43

Slide 43 text

簡易RAGのためにあらかじめ出し ておいた質問要約とベクトル

Slide 44

Slide 44 text

● 新たな問い合わせの文章をOpenAI APIに送信し、 ○ まず、いい感じに1文に要約する ○ 次に、その要約文のベクトル(embedding)を取得する ● 過去の全問合せのそれぞれの要約とそのベクトルはあらかじめ取得してあり、 シートに記録してあるので、それぞれとのコサイン類似度を計算する ● さらに、新たな問い合わせの文章と過去の文章のキーワード一致率を、簡易的 な2-gramで比較する ● コサイン類似度 * 0.8 + キーワード一致率 * 0.2 の値が大きい順に並べ、類似 率が0.5以上の事例を最大5件、Slackに投稿する。 44 GASでやっている処理

Slide 45

Slide 45 text

● 新たな問い合わせの文章をOpenAI APIに送信し、 ○ まず、いい感じに1文に要約する ○ 次に、その要約文のベクトル(embedding)を取得する ● 過去の全問合せのそれぞれの要約とそのベクトルはあらかじめ取得してあり、 シートに記録してあるので、それぞれとのコサイン類似度を計算する ● さらに、新たな問い合わせの文章と過去の文章のキーワード一致率を、簡易的 な2-gramで比較する ● コサイン類似度 * 0.8 + キーワード一致率 * 0.2 の値が大きい順に並べ、類似 率が0.5以上の事例を最大5件、Slackに投稿する。 45 GASでやっている処理 👇なぜ要約を挟むのか?

Slide 46

Slide 46 text

46 プロンプト紹介 function _getQuerySummaryFromOpenAI(queryText) { const payload = { model: SEISEI_DEPLOYMENT_NAME, messages: [ { role: "system", // プロンプト content: `以下の問い合わせ文を何に関する内容か一目で分かるように、 1文で要約してください。 ですます調の丁寧な日本語で、要約のみを出力してください(承知しました。といった応答が不要という事です)。 顧客コードや品番などの自動採番されていそうな数値と、具体的な年月や日付は要約に含めないでください。 問合せ元の主体を指す企業名や部署名は要約に含めないでください。 問い合わせ文の中にエラーメッセージを発見した場合は、それを要約文にそのまま記載してください(※それは 1文に数えません)。 なお、B2B、M.com、OSLとは、当社がお客様に提供する WEBサービス名です。` }, { role: "user", content: queryText } // この文章に対して(新たな問い合わせ文) ], temperature: 0.3, // 創造性低め max_tokens: 80, // 短文でお願い top_p: 1 // 核サンプリング無効 };

Slide 47

Slide 47 text

● 新たな問い合わせの文章をOpenAI APIに送信し、 ○ まず、いい感じに1文に要約する ○ 次に、その要約文のベクトル(embedding)を取得する ● 過去の全問合せのそれぞれの要約とそのベクトルはあらかじめ取得してあり、 シートに記録してあるので、それぞれとのコサイン類似度を計算する ● さらに、新たな問い合わせの文章と過去の文章のキーワード一致率を、簡易的 な2-gramで比較する ● コサイン類似度 * 0.8 + キーワード一致率 * 0.2 の値が大きい順に並べ、類似 率が0.5以上の事例を最大5件、Slackに投稿する。 47 GASでやっている処理  👇なんの効果が?

Slide 48

Slide 48 text

評価点   48

Slide 49

Slide 49 text

最後の回答生成は人間の責務にしたことで、AIの長所だけを活かせ ている ● ハルシネーションリスクが無い ○ 「似てる質問を探す」という得意分野をお願いする ○ 「見つかった」=「回答実績がある」が確定しているので 安心 ● 情報ソース自体が見える ○ 人間が最終検討することができる 49 良いところ

Slide 50

Slide 50 text

● 無知なりに偶然作ったものが簡易RAGモックだった(←かっこいい) ● GASだから導入コスト激安 ○ 1日で作れた ○ 記録シートのあるチームなら簡単に展開できる ○ 導入にあたり追加予算不要 ● 誰でも問い合わせ対応できるようになった(大体真似すればいいので) ● 当番の気が楽になって負荷軽減 ● 導入時に自チーム以外と調整が不要→改善サイクルさっさと回せる 50 この改善やってよかったこと

Slide 51

Slide 51 text

● バージョン管理してないから改修をDevinやCursorに一任できない ○ GASなので一工夫必要→めんどい… ● 問い合わせ履歴記録シートのないチームには展開できない ● 今は過去対応履歴が300行しかないので短時間で済んでいるが、増え てくるとパフォーマンスに問題がある ● 調査と回答生成は人間の仕事なのでそこは重いまま(気軽な導入とト レードオフだけど) ● 今の実装で正確な検索ができているのか客観的指標がない 51 まだ改善すべきところ

Slide 52

Slide 52 text

52 AIと人間のいい関係!

Slide 53

Slide 53 text

技術的な面白さ ● スプレッドシートでベクトル検索 ● LLMと相談してGAS開発 ボトムアップが生まれる環境づくり ● 必要なものを最小限で実現 ● LLMにアクセス可能な環境 ● 現場で必要なものを、みずから作った 53 ポイント

Slide 54

Slide 54 text

お話しする 2つ のテーマ 1 どのようにAI駆動開発の組織への展開をすすめたか AIによる不可逆な変化と組織のチェンジマネジメント 2 実践から見えた学びと次の一手 置き換えが鍵!飛躍的な生産性向上のための要点

Slide 55

Slide 55 text

実践から見えた学びと次の一手 置き換えが鍵!飛躍的な生産性向上のための要点 55

Slide 56

Slide 56 text

普川泰如 (ふかわ たいすけ) 株式会社 MonotaRO CTO taipuka0 慶応義塾大学環境情報学部卒業、 SIer企業を経て2009年にオイシックス・ラ・大地 に入社、2016年同システム副本部長。 2019年にモノタロウに参画。 2021年1月に ECシステムエンジニアリング部門長、 2022年4月に執行役CTO/VPoEに就任。 顧 客体験の向上をアジリティ高く行うべくシステム全体のモダナイゼーションと組織作 りを推進中。 趣 味 ランニング マラソン PB3時間48分 トレラン  高尾山、奥多摩周辺の山が多い キャンプ  なぜか焚き火台3台所有、ほぼ焚き火をしている 56 自己紹介

Slide 57

Slide 57 text

57 AIによる支援か?置き換えか? 分類 概要 代表ツール 効果 主な課題 支援型 Instruction Driven [同期作業] 人間が主導、AIが補助 GitHub Copilot Cursor, Windsurf Claude Code 開発者スキルが高い ほど効果的。タスク単 位の効率化。 成果は個人依存、浸 透に時間。 組織の底上げはスキ ルアップ必須 置き換え型 Issue Driven [非同期作業] AIが主導、人間は監督 Devin, Claude Code Action プロセス全体を自動化 し、スループット大幅 向上。 コンテキスト整備・品 質ガードレールが必 要。 組織の開発プロセスを 変える必要がある 置き換え型まで行くと生産性の効果が大きく出ている

Slide 58

Slide 58 text

58 CursorやClineでは意外と生産性は伸びてない … ? ● Devin と比較して Cursor や Cline はPR数に対しての影響はあまりない ● 「人間を支援する」よりも「人間を置き換える」ツールのほうが効果的 Cline, Cursor 導入開始

Slide 59

Slide 59 text

59 Devin は着実に生産性に貢献している ● 7月時点でPull Requests (マージ済み) の 15% は Devin が作成 ● また Devin のPRは過去と比較しても純増していそう

Slide 60

Slide 60 text

60 [事例A]ある基幹システム移行PJでのDevin活用 Devin 人間 プロダクト毎に分解すると、特定の プロダクトでのDevinの割合が特に増 えていることがわかった

Slide 61

Slide 61 text

61 [事例A]ある基幹システム移行PJでのDevin活用 以下のサイクルで バグ調査と修正をAIに置き換え実現 1. テストで新旧差分を検出 2. Devinに丸投げ 3. Devinが原因調査 4. Devinが修正→PR 5. Devinがレビュー対応 6. マージ

Slide 62

Slide 62 text

[事例B] AIに業務を代替させる コンテナ基盤グループのDevin事例 • 利用者がSlackでフォーム入力 (ネームスペース追加や変更) • → WorkflowからDevinを呼び出し – Devin: Terraform/Kubernetes変更 → CI/CD → 自動修正 → PR作成 – 人間: レビューとマージだけ (→ 適用はCDが実施) • 難易度の高い依頼のみ人間対応 • 良い点 – 依頼の半数以上をDevinが自動で処理 – 専門的な知識がなくても、やりたいことをDevin(LLM)が補完 62

Slide 63

Slide 63 text

[事例22] AIに業務を代替させる: コンテナ実行基盤 IaC の例 Slack Workflow -> Devin -> PR作成 -> CI/CD -> Devinが修正 人間はPRレビュー & マージすればOK ユーザーが入力したフォーム 情報で依頼文書作成 人間を介さず、いきなり Devinを呼び出す DevinがKubernetes 設定を 作成 CI/CD結果も確認してくれる

Slide 64

Slide 64 text

IaC + Devin は相性がいい • TerraformやKubenetesの設定変更は定型的、反復的、宣言的 – LLMによる修正・複製の精度が高い • CIが整備されているので、問題があればDevinが自動で修正まで辿り着ける • DevinはSlack対応しているので、WorkflowやSlack Appで @Devin でOK このチームでは、半数以上のインフラ依頼がDevin + IaCで処理されている! 64

Slide 65

Slide 65 text

プロセス変容の段階のイメージ ● まずは Cursor/Cline のようなツールを使って試行錯誤しつつ AIに任せられるプロセスを徐々に増やしていく ● プロセスがある程度増えた段階で、プロセスをどう変えたらDevinに完全に任せられる かを再度考えなおし、必要な環境を整備する 1 2 段階的移行

Slide 66

Slide 66 text

まずはSDLCのすべてのフェーズでAIの活用度を着実にあげていく チームA チームB チームC 計画 設計 実装 テスト デプロイ 運用 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% 70% チームA チームB チームC 計画 設計 実装 テスト デプロイ 運用 30% 40% 10% 40% 10% 30% 10% 70% 60% 20% 20% 30% 60% 50% 30% 40% 20% 40% Before After

Slide 67

Slide 67 text

まずはSDLCのすべてのフェーズでAIの活用度を着実にあげていく 計画 設計 実装 テスト デプロイ 運用 ● まずは Cursor/Cline のようなツールを使って試行錯誤しつつ AIに任せられるプロセスを徐々に増やしていく ● プロセスがある程度増えた段階で、プロセスをどう変えたらどうエージェントに完全に 任せられるかを再度考えなおし、必要な環境を整備する 30% 60% 70% 30% 40% 20%

Slide 68

Slide 68 text

まとめ 68

Slide 69

Slide 69 text

人数 変革への熱意 キャズム 69/23 “熱量” を “文化” に昇華する仕組みは継続 ● ツールを使ってAIに任せられるプロセスを増やすのは、組織全体ですすめていく ● “熱量” を “文化” へ昇華させる “仕組み” を継続させる AI駆動開発に情熱がある メンバー 1 価値探索プログラムと エバンジェリスト制度 2 AIトレンドラボ 3 AI駆動開発ツールDOJO “熱量” を “文化” へ 4 SDLCでの評価と可視化

Slide 70

Slide 70 text

まとめ 1 どのようにAI駆動開発を組織へ展開したか モノタロウは 個人の “熱量” をどのように “文化” に昇華させたか 2 実践から見えた学びと次の一手 AIの使い所と開発プロセス変容の必要性 → 3つの仕組みを実施 ● 価値探索プログラムとエバンジェリスト制度 ● AIトレンドラボ ● DOJO → 「支援するAI」より「置き換えるAI」が効果的 → 「ツール浸透」の先に「プロセス変容」という新たなキャズムがある → 次の一手として、開発プロセス(SDLC)全体のAIによる置き換えを実施

Slide 71

Slide 71 text

71 © 2020 MonotaRO Co., Ltd. All Rights Reserved.