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

by takuya kikuchi

Slide 1

Slide 1 text

「現場で活躍するAIエージェント」を実現するチームと開発プロセス株式会社Algomatic ネオセールスカンパニーCTO 菊池琢弥 2025-07-18 AOAI Dev Day 2025

Slide 2

Slide 2 text

© 2024 Algomatic Inc. フィンテックスタートアップにおいて開発リードやVPoEとしての開発組織構築を担当したほか、モバイルオーダープラットフォームを⼿がけるShowcase GigではVPoTとして技術領域全般を管掌。2023年、Algomaticにカンパニー CTOとして参画し、2025年に営業AIエージェント「アポドリ」をリリース。ソフトウェア開発、設計、ドット絵が好き。⾼専出⾝です。 Algomatic ネオセールスカンパニーCTO 菊池琢弥 / Takuya Kikuchi 2 © 2024 Algomatic Inc.

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

⼈の代わりに営業活動を⾏う「AIエージェント」 7 従来アポドリ営業！営業！お願い！

Slide 8

Slide 8 text

SaaSではない「営業リスト」を渡すだけでアポが取れる 8 お客様アポドリ ①ターゲット企業の選定企業名、URLなど ②セットアップ/ アプローチ準備公開情報からキーマン特定と1to1⽂章⽣成など ③アプローチ実⾏/ 商談創出メール/問い合わせフォーム/SNS/⼿紙/.. ④商談実施リストを渡すだけで待ってるだけ商談の申込み

Slide 9

Slide 9 text

たくさんのタスクをこなしながら、アポを取る 9 リスト提供企業情報収集企業名や住所、URL情報からWeb‧独⾃DBを探索し、収集収集したデータの加⼯や評価担当者収集企業の役員‧従業員の情報をWeb‧独⾃DBを探索し、収集収集したデータの加⼯や評価 1to1⽂章⽣成企業情報、担当者情報を元に、ターゲットリストに最適なオリジナルの1to1メッセージを作成、評価アプローチ実⾏メール/問い合わせフォーム/SNS/⼿紙などのあらゆるチャネルからアプローチを実施データ分析どういった内容、業界、役職、部署へのアプローチが効果的であったか分析し提⽰アプローチ先情報収集連絡先、問い合わせフォームをWeb‧独⾃DBを探索し、収集収集したデータの加⼯や評価

Slide 10

Slide 10 text

多くの反響をいただきました 10

Slide 11

Slide 11 text

本題 11

Slide 12

Slide 12 text

「現場で活躍する」 AIエージェント 12

Slide 13

Slide 13 text

…の前に 13

Slide 14

Slide 14 text

「現場で活躍しない」 AIエージェント、AIツール 14

Slide 15

Slide 15 text

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Slide 18

Slide 18 text

「現場で活躍する」 AIエージェント 18

Slide 19

Slide 19 text

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Slide 26

Slide 26 text

「信じて任せられる」AIエージェントどう作る？ 26

Slide 27

Slide 27 text

Slide 28

Slide 28 text

「信じて任せられる」AIエージェントアポドリのつくりかた 28

Slide 29

Slide 29 text

アポドリのつくりかた ① 領域は狭く、深く ② まず⼈間がやってみる ③ ドメインエキスパートが開発する 29

Slide 30

Slide 30 text

アポドリのつくりかた ① 領域は狭く、深く ② まず⼈間がやってみる ③ ドメインエキスパートが開発する 30

Slide 31

Slide 31 text

領域は狭く、深く ● つい「なんでもできる」ものを作りたくなりがちだが... ○ 「広く浅くなんでもできる」は「何もできない」と同じ ● 「ここを任せられたら嬉しいな」という範囲ギリギリの狭さを深く作り込む ○ 領域が狭いことで性能が上げやすい ○ 「任せても安⼼」なレベルまで性能を⾼めることが必須 ○ 領域が狭すぎても「わざわざ使うの⾯倒くさい」となる ○ バランスが⼤事 31

Slide 32

Slide 32 text

Slide 33

Slide 33 text

アポドリのつくりかた ① 領域は狭く、深く ② まず⼈間がやってみる ③ ドメインエキスパートが開発する 33

Slide 34

Slide 34 text

まず⼈間がやってみる ● 「AIによる⾃動化を⾒据えた業務フロー」を構築する ● それをまず、開発者⾃⾝がやってみる ● そして、AIツールを作って⾃⾝を楽にしてみるワークフローの解像度を開発者が⾼めつつ、AIで解く難易度を肌で知る実際にやってみると... ● 「案外普通にできるじゃん」 ● 「いや、これができないんかい」 ○ それぞれある ○ この肌感覚を持っていない⼈間が開発したエージェントは「それっぽいけどなんか違う」ものになりがち 34

Slide 35

Slide 35 text

© 2025 Algomatic Inc. まず⼈間がやってみる ● 最初からツールは実装してみたものの、⽣成失敗や低品質で使えないものが多数であり、半分以上⼿動で実施することになった ● 正直もうちょっといけると思っていたので悲しかったが、⼿動作業は⾮常に学びは多かった ● 企業HPの多様さ、記載内容の濃淡など...営業活動で扱う「⾮構造化データ」のおそろしさを⽬の当たりにする 35 アプローチ計画 1to1⽂章⽣成アプローチ先情報収集アプローチ実⾏

Slide 36

Slide 36 text

© 2025 Algomatic Inc. まず⼈間がやってみる 36 ● ⼈間が1つ1つのアウトプットの良し悪しを判断することになる ● すると、ワークフローのステップごとの観点、落とし⽳、エラーパターンがわかってくる ● その知⾒を踏まえてステップごとの品質保証 →「なぜ品質が⾼いのか？」を説明できる → 信じて任せられる 1to1⽂章⽣成アプローチ先情報収集同名別企業会社名変更グループ企業 HPなし、SNSのみ⽂章薄っぺらい数値嘘つきがち「てにをは」

Slide 37

Slide 37 text

アポドリのつくりかた ① 領域は狭く、深く ② まず⼈間がやってみる ③ ドメインエキスパートが開発する 37

Slide 38

Slide 38 text

ドメインエキスパートが開発する 38 ● AIエージェントは「便利ツール」ではない。「ドメインエキスパート」の分⾝ ○ ドメインエキスパートは何を考え、どう判断し、どんなアウトプットをよしとするのか？ ○ これを⾼いレベルで再現することが必須 ○ 伝⾔ゲームは厳しい、エキスパートが直接開発するのがいい

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

アポドリのつくりかた ① 領域は狭く、深く ② まず⼈間がやってみる ③ ドメインエキスパートが開発する 43

Slide 44

Slide 44 text

⼤事なのは 44

Slide 45

Slide 45 text

エンジニアとドメインエキスパートの「限りなく泥臭い」共創 45

Slide 46

Slide 46 text

そんな共創を⽀えたシステムアーキテクチャの変遷 5段階 46

Slide 47

Slide 47 text

初期アーキテクチャ開発初期に必要な要件は... ● 変化に柔軟であること ● 「⽬の前の技術不確実性」以外を無視できること ○ 質の⾼い1to1⽂章は⽣成できるのか？ ○ ⾼品質な情報収集は⼈間のチェックなしに可能なのか？ ○ … 47

Slide 48

Slide 48 text

48 1. 最も柔軟かつシンプルな最初期開発者のローカルPCで開発 →デプロイ不要待ち時間なしインフラ整備不要

Slide 49

Slide 49 text

49 2. ドメインエキスパートとの共創開始 Difyを建てました

Slide 50

Slide 50 text

50 2. ドメインエキスパートとの共創開始 CLIツールからDifyを呼び出す仕組みをつくりました

Slide 51

Slide 51 text

51 3. エンジニア以外もオペレーション可能にさすがにローカルPCが⾟くなってきたので Webアプリケーション化ただし、なるべく作りたくない

Slide 52

Slide 52 text

52 3. エンジニア以外もオペレーション可能に GUI: スプシとSlack

Slide 53

Slide 53 text

53 3. エンジニア以外もオペレーション可能に実⾏環境: Azure Functions / Container App Jobs

Slide 54

Slide 54 text

54 3. エンジニア以外もオペレーション可能に DB: CosmosDB for NoSQL スキーマレスよい AIエージェント開発との相性🙆

Slide 55

Slide 55 text

55 4. データ基盤、誕⽣ CosmosDBで集計はさすがにキツイので、データ基盤構築ただし、なるべく作りたくない

Slide 56

Slide 56 text

56 4. データ基盤、誕⽣ Mirrored CosmosDB機能: ETL不要でCosmosDB→DWH にミラーリングを実現（なおプレビュー機能です）

Slide 57

Slide 57 text

57 5. ついにUIを実装 Slackやスプレッドシートを可能な限り排し、社内⽤UIを実装

Slide 58

Slide 58 text

58 5. ついにUIを実装 ● スプシ（GAS）のメンテナンス苦 ● ヒューマンエラー防⽌ ○ LLMより⼈間のほうが間違える ○ 「間違えようがない仕組み」としてのUI

Slide 59

Slide 59 text

初期アーキテクチャ（再掲）開発初期に必要な要件は... ● 変化に柔軟であること ● 「⽬の前の技術不確実性」以外を無視できること ○ 質の⾼い1to1⽂章は⽣成できるのか？ ○ ⾼品質な情報収集は⼈間のチェックなしに可能なのか？ ○ … 59

Slide 60

Slide 60 text

直近のアーキテクチャ初期と⽐較し、事業状況とともに要求は変化 ● ワークフローの変化は落ち着いてくる ● ガバナンスとスケーラビリティが重要になる ○ リリース管理、データ管理 ○ ヒューマンエラーを防ぐ仕組み 60

Slide 61

Slide 61 text

まとめ 61

Slide 62

Slide 62 text

「現場で活躍するAIエージェント」のつくりかた ● 「信じて任せられる」ものを作ろう ● そのためには... ○ 性能を⾼め切れる「狭い領域」選定 ○ ⼈がまずやる。解像度を⾼める ○ ドメインエキスパートが開発に参加する 62

Slide 63

Slide 63 text

「現場で活躍するAIエージェント」のつくりかた ● システムアーキテクチャはどうあるべき？ ○ 「技術不確実性」とまず向き合う ■ 「できるかわからない。でも出来たらすごいよね」という課題は何か？ ○ 事業フェーズに合わせた設計をしよう 63

Slide 64

Slide 64 text

64 事業‧開発知⾒の発信サービス⼀覧採⽤情報 ● エンジニア ● デザイナー ● 新規/既存事業開発 ● マーケター ● ドメインエキスパート ● etc ● 営業AIエージェント ● 採⽤AIエージェント ● デザインAIエージェント ● ゲーム翻訳 ● コンサルティング‧受託開発 ● etc 事業開発開発‧テックブログ