「現場で活躍するAIエージェント」を実現するチームと開発プロセス

AOAI Dev Day 2025 での登壇資料です。

Transcript

1. 「現場で活躍するAIエージェント」 を実現するチームと開発プロセス 株式会社Algomatic ネオセールスカンパニーCTO 菊池琢弥 2025-07-18 AOAI Dev Day 2025
2. © 2024 Algomatic Inc. フィンテックスタートアップにおいて開発リー ドやVPoEとしての開発組織構築を担当したほ か、モバイルオーダープラットフォームを⼿が けるShowcase GigではVPoTとして技術領域全 般を管掌。2023年、Algomaticにカンパニー CTOとして参画し、2025年に営業AIエージェン ト「アポドリ」をリリース。 ソフトウェア開発、設計、ドット絵が好き。 ⾼専出⾝です。 Algomatic ネオセールスカンパニーCTO 菊池 琢弥 / Takuya Kikuchi 2 © 2024 Algomatic Inc.
3. © 2025 Algomatic Inc. 運営サービス（⼀部） 3
4. © 2025 Algomatic Inc. 運営サービス（⼀部） 4
5. © 2025 Algomatic Inc. 運営サービス（⼀部） 5
7. ⼈の代わりに営業活動を⾏う「AIエージェント」 7 従 来 ア ポ ド リ 営業！ 営業！ お願い！
8. SaaSではない 「営業リスト」を渡すだけでアポが取れる 8 お 客 様 ア ポ ド リ ①ターゲット 企業の選定 企業名、URLなど ②セットアップ/ アプローチ準備 公開情報からキーマ ン特定と1to1⽂章⽣ 成など ③アプローチ実⾏/ 商談創出 メール/問い合わせ フォーム/SNS/⼿紙/.. ④商談実施 リストを 渡すだけで 待ってるだけ 商談の申込み
9. たくさんのタスクをこなしながら、アポを取る 9 リスト 提供 企業情報収集 企業名や住所、URL情報からWeb‧独⾃DBを探索し、収集 収集したデータの加⼯や評価 担当者収集 企業の役員‧従業員の情報をWeb‧独⾃DBを探索し、収集 収集したデータの加⼯や評価 1to1⽂章⽣成 企業情報、担当者情報を元に、ターゲットリストに最適なオリ ジナルの1to1メッセージを作成、評価 アプローチ実⾏ メール/問い合わせフォーム/SNS/⼿紙などのあらゆるチャネル からアプローチを実施 データ分析 どういった内容、業界、役職、部署へのアプローチが効果的で あったか分析し提⽰ アプローチ先 情報収集 連絡先、問い合わせフォームをWeb‧独⾃DBを探索し、収集 収集したデータの加⼯や評価
10. 多くの反響をいただきました 10
11. 本題 11
12. 「現場で活躍する」 AIエージェント 12
13. …の前に 13
14. 「現場で活躍しない」 AIエージェント、AIツール 14
15. © 2025 Algomatic Inc. 逆に「現場で活躍しないAIエージェント‧ツール」を考えてみる 15 「使うのが⾯倒臭い」
16. © 2025 Algomatic Inc. 逆に「現場で活躍しないAIエージェント‧ツール」を考えてみる 16 「使うのが⾯倒臭い」 「使ったけど結果が微妙」
17. © 2025 Algomatic Inc. 逆に「現場で活躍しないAIエージェント‧ツール」を考えてみる 17 「使うのが⾯倒臭い」 「使ったけど結果が微妙」 「⾃分でやったほうが早くない？」
18. 「現場で活躍する」 AIエージェント 18
19. © 2025 Algomatic Inc. 「現場で活躍するAIエージェント」を考えてみる 19 「信じて任せられる」
20. © 2025 Algomatic Inc. 「現場で活躍するAIエージェント」を考えてみる 20 「信じて任せられる」 アウトプット品質に満⾜
21. © 2025 Algomatic Inc. 「現場で活躍するAIエージェント」を考えてみる 21 「信じて任せられる」 細かい指⽰が不要 アウトプット品質に満⾜
22. © 2025 Algomatic Inc. 「現場で活躍するAIエージェント」を考えてみる 22 「信じて任せられる」 細かい指⽰が不要 アウトプット品質に満⾜ ⾃分でやらないで良い
23. © 2025 Algomatic Inc. 「現場で活躍しないAIエージェント‧ツール」を思い出す 23 「使うのが⾯倒臭い」 「使ったけど結果が微妙」 「⾃分でやったほうが早くない？」
24. © 2025 Algomatic Inc. 「現場で活躍しないAIエージェント‧ツール」を思い出す 24 「使うのが⾯倒臭い」←任せられればOK 「使ったけど結果が微妙」←信じてもらえればOK 「⾃分でやったほうが早くない？」←信じて任せられればOK
25. © 2025 Algomatic Inc. 「現場で活躍しないAIエージェント‧ツール」を思い出す 25 「使うのが⾯倒臭い」 「使ったけど結果が微妙」 「⾃分でやったほうが早くない？」 信じて任せられるならば 使ってもらえる！活躍できる！
26. 「信じて任せられる」AIエージェント どう作る？ 26
28. 「信じて任せられる」AIエージェント アポドリのつくりかた 28
29. アポドリのつくりかた ① 領域は狭く、深く ② まず⼈間がやってみる ③ ドメインエキスパートが開発する 29
30. アポドリのつくりかた ① 領域は狭く、深く ② まず⼈間がやってみる ③ ドメインエキスパートが開発する 30
31. 領域は狭く、深く • つい「なんでもできる」ものを作りたくなりがちだが... ◦ 「広く浅くなんでもできる」は「何もできない」と同じ • 「ここを任せられたら嬉しいな」という範囲ギリギリの狭さを深く 作り込む ◦ 領域が狭いことで性能が上げやすい ◦ 「任せても安⼼」なレベルまで性能を⾼めることが必須 ◦ 領域が狭すぎても「わざわざ使うの⾯倒くさい」となる ◦ バランスが⼤事 31
32. © 2025 Algomatic Inc. 領域は狭く、深く 32 • アポドリは「アポ取り」しかしない • 商談アドバイスもしない、議事録もとらない、商談前の企業調査もやってくれない • ただし、アポ取りに必要な業務は全部やる、やりきる 「ミスなく⾼品質にアポ取り活動できます」  → 任せたくなる
33. アポドリのつくりかた ① 領域は狭く、深く ② まず⼈間がやってみる ③ ドメインエキスパートが開発する 33
34. まず⼈間がやってみる • 「AIによる⾃動化を⾒据えた業務フロー」を構築する • それをまず、開発者⾃⾝がやってみる • そして、AIツールを作って⾃⾝を楽にしてみる ワークフローの解像度を開発者が⾼めつつ、AIで解く難易度を肌で知る 実際にやってみると... • 「案外普通にできるじゃん」 • 「いや、これができないんかい」 ◦ それぞれある ◦ この肌感覚を持っていない⼈間が開発したエージェントは 「それっぽいけどなんか違う」ものになりがち 34
35. © 2025 Algomatic Inc. まず⼈間がやってみる • 最初からツールは実装してみたものの、⽣成失敗や低品質で使えないものが多数であ り、半分以上⼿動で実施することになった • 正直もうちょっといけると思っていたので悲しかったが、⼿動作業は⾮常に学びは多 かった • 企業HPの多様さ、記載内容の濃淡など...営業活動で扱う「⾮構造化データ」の おそろしさを⽬の当たりにする 35 アプローチ計画 1to1⽂章⽣成 アプローチ先 情報収集 アプローチ実⾏
36. © 2025 Algomatic Inc. まず⼈間がやってみる 36 • ⼈間が1つ1つのアウトプットの良し悪しを判 断することになる • すると、ワークフローのステップごとの 観点、落とし⽳、エラーパターンがわかって くる • その知⾒を踏まえてステップごとの品質保証 →「なぜ品質が⾼いのか？」を説明できる → 信じて任せられる 1to1⽂章⽣成 アプローチ先 情報収集 同名別企業 会社名変更 グループ企業 HPなし、SNSのみ ⽂章薄っぺらい 数値嘘つきがち 「てにをは」
37. アポドリのつくりかた ① 領域は狭く、深く ② まず⼈間がやってみる ③ ドメインエキスパートが開発する 37
38. ドメインエキスパートが開発する 38 • AIエージェントは「便利ツール」ではない。「ドメインエキスパート」の 分⾝ ◦ ドメインエキスパートは何を考え、どう判断し、どんなアウトプッ トをよしとするのか？ ◦ これを⾼いレベルで再現することが必須 ◦ 伝⾔ゲームは厳しい、エキスパートが直接開発するのがいい
39. © 2025 Algomatic Inc. ドメインエキスパートが開発する 39 ⾔語化 1. エンジニアが開発
40. © 2025 Algomatic Inc. ドメインエキスパートが開発する ⾔語化 1. エンジニアが開発 2. エンジニアと ドメインエキスパートが 共同開発
41. © 2025 Algomatic Inc. ドメインエキスパートが開発する 41 ⾔語化 1. エンジニアが開発 2. エンジニアと ドメインエキスパートが 共同開発 3. ドメインエキスパートが開発
42. © 2025 Algomatic Inc. ドメインエキスパートが開発する 42 • ドメインエキスパート → Difyでワークフロー開発 • エンジニア → ドメインエキスパートの後⽅⽀援 ◦ Difyの安定稼働 ◦ ⼤量ワークフロー実⾏を⽀える基盤 ◦ ワークフローにおいて必要な各種機能の実装 ドメインエキスパート⾃⾝が納得する品質 →信じて任せられる
43. アポドリのつくりかた ① 領域は狭く、深く ② まず⼈間がやってみる ③ ドメインエキスパートが開発する 43
44. ⼤事なのは 44
45. エンジニアとドメインエキスパートの 「限りなく泥臭い」共創 45
46. そんな共創を⽀えた システムアーキテクチャの変遷 5段階 46
47. 初期アーキテクチャ 開発初期に必要な要件は... • 変化に柔軟であること • 「⽬の前の技術不確実性」以外を無視できること ◦ 質の⾼い1to1⽂章は⽣成できるのか？ ◦ ⾼品質な情報収集は⼈間のチェックなしに可能なのか？ ◦ … 47
48. 48 1. 最も柔軟かつシンプルな最初期 開発者のローカルPCで開発 →デプロイ不要  待ち時間なし  インフラ整備不要
49. 49 2. ドメインエキスパートとの共創開始 Difyを建てました
50. 50 2. ドメインエキスパートとの共創開始 CLIツールからDifyを呼び出す 仕組みをつくりました
51. 51 3. エンジニア以外もオペレーション可能に さすがにローカルPCが⾟く なってきたので Webアプリケーション化 ただし、 なるべく作りたくない
52. 52 3. エンジニア以外もオペレーション可能に GUI: スプシとSlack
53. 53 3. エンジニア以外もオペレーション可能に 実⾏環境: Azure Functions / Container App Jobs
54. 54 3. エンジニア以外もオペレーション可能に DB: CosmosDB for NoSQL スキーマレスよい AIエージェント開発との相性🙆
55. 55 4. データ基盤、誕⽣ CosmosDBで集計はさすがに キツイので、データ基盤構築 ただし、 なるべく作りたくない
56. 56 4. データ基盤、誕⽣ Mirrored CosmosDB機能: ETL不要でCosmosDB→DWH にミラーリングを実現 （なおプレビュー機能です）
57. 57 5. ついにUIを実装 Slackやスプレッドシートを 可能な限り排し、 社内⽤UIを実装
58. 58 5. ついにUIを実装 • スプシ（GAS）のメンテ ナンス苦 • ヒューマンエラー防⽌ ◦ LLMより⼈間のほう が間違える ◦ 「間違えようがない 仕組み」としてのUI
59. 初期アーキテクチャ（再掲） 開発初期に必要な要件は... • 変化に柔軟であること • 「⽬の前の技術不確実性」以外を無視できること ◦ 質の⾼い1to1⽂章は⽣成できるのか？ ◦ ⾼品質な情報収集は⼈間のチェックなしに可能なのか？ ◦ … 59
60. 直近のアーキテクチャ 初期と⽐較し、事業状況とともに要求は変化 • ワークフローの変化は落ち着いてくる • ガバナンスとスケーラビリティが重要になる ◦ リリース管理、データ管理 ◦ ヒューマンエラーを防ぐ仕組み 60
61. まとめ 61
62. 「現場で活躍するAIエージェント」のつくりかた • 「信じて任せられる」ものを作ろう • そのためには... ◦ 性能を⾼め切れる「狭い領域」選定 ◦ ⼈がまずやる。解像度を⾼める ◦ ドメインエキスパートが開発に参加 する 62
63. 「現場で活躍するAIエージェント」のつくりかた • システムアーキテクチャはどうあるべき？ ◦ 「技術不確実性」とまず向き合う ▪ 「できるかわからない。でも出来たら すごいよね」という課題は何か？ ◦ 事業フェーズに合わせた設計をしよう 63
64. 64 事業‧開発知⾒の発信 サービス⼀覧 採⽤情報 • エンジニア • デザイナー • 新規/既存 事業開発 • マーケター • ドメインエキスパート • etc • 営業AIエージェント • 採⽤AIエージェント • デザインAIエージェント • ゲーム翻訳 • コンサルティング‧受託 開発 • etc 事業開発 開発‧テックブログ