AIエージェントを支える設計

by takuya kikuchi

Slide 1

Slide 1 text

AIエージェント開発を支える設計   2025-07-25 設計ナイト2025    株式会社Algomatic   ネオセールスカンパニーCTO 菊池琢弥 

Slide 2

Slide 2 text

自己紹介  菊池琢弥 / Takuya Kikuchi   株式会社Algomatic ネオセールスカンパニーCTO     生成AI界隈からきました  生成AI領域で複数事業展開するスタートアップで   営業領域事業の技術責任者をやっています。   高専卒、2012年からソフトウェアエンジニアです。     ドット絵を描いて暮らしたい  

Slide 3

Slide 3 text

今日のテーマ   「気がついたらAIエージェントになっていた」プロダクト開発の話をします   その開発過程を振り返りながら、ソフトウェア設計の変遷を解説します  

Slide 4

Slide 4 text

今日のねらい   「AI領域は縁遠くて...」  「AIエージェント？プロンプトこねこねするだけじゃないの？」 

Slide 5

Slide 5 text

今日のねらい   「AI領域は縁遠くて...」  「AIエージェント？プロンプトこねこねするだけじゃないの？」  　↓  「AIエージェント開発たのしそうだね！」     となってくれたら嬉しいです 

Slide 6

Slide 6 text

事前知識 

Slide 7

Slide 7 text

事前知識1: LLMによって広がった「システム」の世界   ● LLM登場以前:   ○ 「プロセス」や「ルール」がシステム化対象   ■ e.g. メールの送信元アドレスに応じてメールを振り分ける     ● LLM登場後:   ○ 人間の「思考」もシステム化の対象となった   ■ e.g. メールの内容（クレーム or 要望 or その他）に応じてメールを振り分ける＝メールの内容を解釈する思考  

Slide 8

Slide 8 text

事前知識2: AIエージェントの分類   AIエージェントといっても、大きく分けて二種類あります     ● 自律型エージェント   ● Agentic Workflow  

Slide 9

Slide 9 text

自律型エージェント   知覚→判断→行動を自律的に回し、目的を達成するシステム。  みんな大好きClaudeCode、Cursor、GitHub Copilot Agent などはこちら  高い柔軟性を持つ一方で、結果の予測可能性が低い。    向いている業務   自由度が高い業務  試行錯誤が可能な業務  AIの誤った出力がクリティカルな問題にならない 

Slide 10

Slide 10 text

Agentic Workflow   あらかじめ設計されたワークフローを順に実行し、目的を達成する  柔軟性は低い一方で、品質を保ちやすい。      向いている業務   作業手順が決まっている業務  ミスが許されない業務 

Slide 11

Slide 11 text

事前知識2: AIエージェントの分類   AIエージェントといっても、大きく分けて二種類あります     ● 自律型エージェント   ● Agentic Workflow   ←こっちの話をします

Slide 12

Slide 12 text

事前知識3: 「気がついたらAIエージェントになっていた」プロダクト紹介  

Slide 13

Slide 13 text

事前知識3: 「気がついたらAIエージェントになっていた」プロダクト紹介   ⼈の代わりに営業活動を⾏う「AIエージェント」従来アポドリ営業！営業！お願い！

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

「気がついたら」ってどういうことなの   1. 営業領域で何か事業やろう！  2. アウトバウンド営業を支援する仮説思いつく  3. 仮説実証のために営業代行をやろう！  4. 仮説はともかく、AIフル活用して営業代行で成果だそう！  5. 仕組みつくれた、成果でた！  6. 複数の顧客が「利用したい」といってくれている！この仕組み、そのまま売れるのでは？  7. 営業AIエージェント「アポドリ」としてリリース！ 

Slide 16

Slide 16 text

本題 

Slide 17

Slide 17 text

今日のテーマ（再掲）   「気がついたらAIエージェントになっていた」プロダクト開発の話をします   その開発過程を振り返りながら、ソフトウェア設計の変遷を解説します     

Slide 18

Slide 18 text

計画モジュールアポドリのコンテキストマップ（現在の姿／一部抜粋）   企業情報収集機能テンプレ作成機能 1to1文面生成機能アプローチ実行機能計画機能戦略モジュール収集モジュール送信モジュール U U U U D D D D

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

営業代行開始〜アポドリになるまで  

Slide 21

Slide 21 text

営業代行のはじまり   アウトバウンド営業代行をやろう！  AIを活用して、人間では実行不可能な行動量と品質を担保しよう！  アプローチ先の1社1社にあわせた1to1の文章を送ろう！  アプローチしたい企業リスト

Slide 22

Slide 22 text

営業代行のはじまり   システム無  アプローチしたい企業リストインプット業務フロー企業リストから連絡先を収集アプローチ文面のテンプレ作り企業ごとの1to1文面をつくるアプローチ計画アプローチ実行

Slide 23

Slide 23 text

最低限のシステム実装   何を作るべきか、何を作らざるべきか  あるもの  ● 営業ドメインエキスパート  ● 粗いワークフロー    → 人間がどう頑張っても無理な部分だけシステムとして実装する  　システム化できない部分は自分たちで手動オペレーション   　 PoC段階なので作り込むことは避けたい。CLIツールとスプシで戦う  

Slide 24

Slide 24 text

最低限のシステム実装   システムアプローチしたい企業リストインプット業務フロー企業リストから連絡先を収集アプローチ文面のテンプレ作り企業ごとの1to1文面をつくるアプローチ計画アプローチ実行

Slide 25

Slide 25 text

最低限のシステム実装   システムアプローチしたい企業リストインプット業務フロー企業リストから連絡先を収集アプローチ文面のテンプレ作り企業ごとの1to1文面をつくるアプローチ計画アプローチ実行 1000件規模の企業の連絡先を収集してスプシに入力 ↓ 人間には無理

Slide 26

Slide 26 text

最低限のシステム実装   システムアプローチしたい企業リストインプット業務フロー企業リストから連絡先を収集アプローチ文面のテンプレ作り企業ごとの1to1文面をつくるアプローチ計画アプローチ実行連絡先収集ツール

Slide 27

Slide 27 text

最低限のシステム実装   システムアプローチしたい企業リストインプット業務フロー企業リストから連絡先を収集アプローチ文面のテンプレ作り企業ごとの1to1文面をつくるアプローチ計画アプローチ実行連絡先収集ツール営業メールのテンプレート作成いろんなノウハウが必要 ↓ 作業負荷は高いが、数が少ないので人間でもできる

Slide 28

Slide 28 text

最低限のシステム実装   システムアプローチしたい企業リストインプット業務フロー企業リストから連絡先を収集アプローチ文面のテンプレ作り企業ごとの1to1文面をつくるアプローチ計画アプローチ実行連絡先収集ツールテンプレをつくる人間

Slide 29

Slide 29 text

最低限のシステム実装   システムアプローチしたい企業リストインプット業務フロー企業リストから連絡先を収集アプローチ文面のテンプレ作り企業ごとの1to1文面をつくるアプローチ計画アプローチ実行連絡先収集ツールテンプレをつくる人間いつ、どの企業に、どの文面を送るか ↓ 頭はこんがらがるが、なんとかなる

Slide 30

Slide 30 text

最低限のシステム実装   システムアプローチしたい企業リストインプット業務フロー企業リストから連絡先を収集アプローチ文面のテンプレ作り企業ごとの1to1文面をつくるアプローチ計画アプローチ実行連絡先収集ツールテンプレをつくる人間アプローチ計画をする人間

Slide 31

Slide 31 text

最低限のシステム実装   システムアプローチしたい企業リストインプット業務フロー企業リストから連絡先を収集アプローチ文面のテンプレ作り企業ごとの1to1文面をつくるアプローチ計画アプローチ実行連絡先収集ツールテンプレをつくる人間アプローチ計画をする人間アプローチ先企業の特徴を踏まえて、 1社1社個別の文面を作成し、テンプレに埋め込む ↓ 1000件の作文はさすがに無理

Slide 32

Slide 32 text

最低限のシステム実装   システムアプローチしたい企業リストインプット業務フロー企業リストから連絡先を収集アプローチ文面のテンプレ作り企業ごとの1to1文面をつくるアプローチ計画アプローチ実行連絡先収集ツールテンプレをつくる人間アプローチ計画をする人間 1to1文面をつくるツール

Slide 33

Slide 33 text

最低限のシステム実装   システムアプローチしたい企業リストインプット業務フロー企業リストから連絡先を収集アプローチ文面のテンプレ作り企業ごとの1to1文面をつくるアプローチ計画アプローチ実行連絡先収集ツールテンプレをつくる人間アプローチ計画をする人間 1to1文面をつくるツールメール送信など GASや手動でなんとかなる

Slide 34

Slide 34 text

最低限のシステム実装   システムアプローチしたい企業リストインプット業務フロー企業リストから連絡先を収集アプローチ文面のテンプレ作り企業ごとの1to1文面をつくるアプローチ計画アプローチ実行連絡先収集ツールテンプレをつくる人間アプローチ計画をする人間 1to1文面をつくるツールアプローチを実行する人間

Slide 35

Slide 35 text

最低限のシステム実装   CLIツール + スプシによる手運用。大部分の作業がシステム化されていない状態   設計という概念の存在しない世界   あるのは、トランザクションスクリプトとスプシと人間  連絡先収集ツールテンプレをつくる人間アプローチ計画をする人間 1to1文面をつくるツールアプローチを実行する人間集約スプシ

Slide 36

Slide 36 text

ほどなく「アプローチ計画」が混みいってくる   営業代行の案件数が2つに増える  「アプローチ計画をする人間」がパンクし、システム化を余儀なくされる  業務フロー企業リストから連絡先を収集アプローチ文面のテンプレ作り企業ごとの1to1文面をつくるアプローチ計画アプローチ実行わけわからなくなってきました

Slide 37

Slide 37 text

ほどなく「アプローチ計画」が混みいってくる   営業代行の案件数が2つに増える  「アプローチ計画をする人間」がパンクし、システム化を余儀なくされる    →「気合いの入ったスプシ」で凌ぐ  業務フロー企業リストから連絡先を収集アプローチ文面のテンプレ作り企業ごとの1to1文面をつくるアプローチ計画アプローチ実行

Slide 38

Slide 38 text

ほどなく「アプローチ計画」が混みいってくる   スプレッドシートが複雑化しただけで事なきを得る  連絡先収集ツールテンプレをつくる人間アプローチ計画をする人間 1to1文面をつくるツールアプローチを実行する人間集約スプシ Ver2 計画表シート

Slide 39

Slide 39 text

ほどなく「アプローチ計画」が混みいってくる   …が、気合いの入ったスプシも1ヶ月程度で限界を迎え、いよいよシステム化  豆知識: スプシのセル数上限は1000万セル  集約スプシ Ver2 計画表シートもう無理です

Slide 40

Slide 40 text

「計画」モジュールの誕生   ● スプシチャレンジにより「計画」業務の複雑さは肌身に染みていた  ● また、より複雑な発展をしていくことも自明だった  →トランザクションスクリプトでは無理     →　既存機能とは分離した別モジュールに、クリーンアーキテクチャで実装  

Slide 41

Slide 41 text

「計画」モジュールの誕生   連絡先収集ツールテンプレをつくる人間 1to1文面をつくるツールアプローチを実行する人間集約スプシ Ver2 計画モジュールその他モジュール計画モジュール

Slide 42

Slide 42 text

業務フローの複雑化   インプットとして企業URLを受領できないケースが増えてくる  業務フロー企業リストから連絡先を収集アプローチ文面のテンプレ作り企業ごとの1to1文面をつくるアプローチ計画アプローチ実行

Slide 43

Slide 43 text

業務フローの複雑化   インプットとして企業URLを受領できないケースが増えてくる  →「企業HP特定」という業務が追加     業務フロー企業リストから連絡先を収集アプローチ文面のテンプレ作り企業ごとの1to1文面をつくるアプローチ計画アプローチ実行企業名からHP特定 New!

Slide 44

Slide 44 text

業務フローの複雑化   インプットとして企業URLを受領できないケースが増えてくる  →「企業HP特定」という業務が追加     すると、企業HP特定の精度が問題になってくる  業務フロー企業リストから連絡先を収集アプローチ文面のテンプレ作り企業ごとの1to1文面をつくるアプローチ計画アプローチ実行企業名からHP特定 New!

Slide 45

Slide 45 text

業務フローの複雑化   インプットとして企業URLを受領できないケースが増えてくる  →「企業HP特定」という業務が追加     すると、企業HP特定の精度が問題になってくる  →人間による「目検チェック」業務追加     追加された業務実現のための機能実装   業務フロー企業リストから連絡先を収集アプローチ文面のテンプレ作り企業ごとの1to1文面をつくるアプローチ計画アプローチ実行企業名からHP特定 New! 収集結果を目検 New!

Slide 46

Slide 46 text

業務フローの複雑化   新規機能を「収集モジュール」として切り出して実装  企業情報収集ツール New! テンプレをつくる人間 1to1文面をつくるツールアプローチを実行する人間集約スプシ Ver2 計画モジュールその他モジュール計画モジュール目検スプシ New! 収集モジュール

Slide 47

Slide 47 text

その先  「送信」や「戦略」などがシステム化され、モジュールとして追加されていく  企業情報収集ツール New! テンプレをつくるツール 1to1文面をつくるツールアプローチ実行ツール集約スプシ Ver2 計画モジュール戦略モジュール計画モジュール目検スプシ収集モジュール送信モジュール

Slide 48

Slide 48 text

計画モジュールスプシを排した現在の姿   企業情報収集機能テンプレ作成機能 1to1文面生成機能アプローチ実行機能計画機能戦略モジュール収集モジュール送信モジュール U U U U D D D D

Slide 49

Slide 49 text

考えていたこと  

Slide 50

Slide 50 text

モジュール分割の意思決定根拠は？   大前提：「自身がドメインエキスパート」状態  オペレーションを自分自身で実行してきたことで業務理解が進む      ● わからない（＝業務理解が浅い状態）  → わからないうちは「その他」モジュールに突っ込んでおく    ● おなじ名前だが、持つべき属性が異なるモデルが存在  → 分割する    ● まとめた方が業務がシンプルになるもの  → まとめる 

Slide 51

Slide 51 text

モジュールごとの設計方針   ● モジュールごとに設計パターンを選定  ○ トランザクションスクリプト  ○ クリーンアーキテクチャ    ● どう選ぶか？  ○ モジュール（サブドメイン）のカテゴリーを見極める※   ■ 補完: 競争優位を生まない　  ■ 一般: 外部サービスで代替可能  ■ 中核: 競争優位の源泉  ※ドメイン駆動設計をはじめよう 1章「事業活動を分析する」より

Slide 52

Slide 52 text

モジュールごとの設計方針   ● モジュールごとに設計パターンを選定  ○ トランザクションスクリプト  ○ クリーンアーキテクチャ    ● どう選ぶか？  ○ モジュール（サブドメイン）のカテゴリーを見極める※   ■ 補完: 競争優位を生まない　→トランザクションスクリプト   ■ 一般: 外部サービスで代替可能 →トランザクションスクリプト   ■ 中核: 競争優位の源泉  ※ドメイン駆動設計をはじめよう 1章「事業活動を分析する」より

Slide 53

Slide 53 text

モジュールごとの設計方針   ● モジュールごとに設計パターンを選定  ○ トランザクションスクリプト  ○ クリーンアーキテクチャ    ● どう選ぶか？  ○ モジュール（サブドメイン）のカテゴリーを見極める※  ■ 補完: 競争優位を生まない　→トランザクションスクリプト  ■ 一般: 外部サービスで代替可能 →トランザクションスクリプト  ■ 中核: 競争優位の源泉 →？   ※ドメイン駆動設計をはじめよう 1章「事業活動を分析する」より

Slide 54

Slide 54 text

「中核」サブドメインの設計   ● もれなく「変更容易性」が重要   ● これまでの業務システムであれば、  クリーンアーキテクチャなど「変更容易性を担保する」設計が必須になる   

Slide 55

Slide 55 text

「中核」サブドメインの設計   ● もれなく「変更容易性」が重要   ● これまでの業務システムであれば、  クリーンアーキテクチャなど「変更容易性を担保する」設計が必須になる    ● AIエージェントの場合、中核サブドメインの設計パターンも２種類存在   ○ このサブドメインで表現するのは「ルール」か「思考」か 

Slide 56

Slide 56 text

「中核」サブドメインの設計   ルール（これまでの業務システムと同様）   → 複雑な業務ロジックを安全に実装可能な設計  　クリーンアーキテクチャなど    思考  → 開発主体をエンジニアからドメインエキスパートに委譲する  　外部のワークフローツールなどを活用し、  　「ドメインエキスパートが機能実装できる仕組み」とする  　モジュールの実装は、ドメインエキスパートが実装した機能の  　呼び出しを行うトランザクションスクリプト 

Slide 57

Slide 57 text

「アポドリ」の具体例   ● 「計画」サブドメイン（中核サブドメイン）   ○ いつ、どの宛先に、どの文面を送るか？  ○ 複雑なルールに従ったアプローチ計画  →クリーンアーキテクチャ     ● 「戦略」サブドメイン（中核サブドメイン）   ○ アプローチテンプレ文面および1to1カスタマイズ文面の生成  ○ ドメインエキスパートが実装できるようにする  →ノーコードツールに詳細を委譲。モジュールとしてはツール呼び出しするだけのトランザクションスクリプト  

Slide 58

Slide 58 text

ふりかえり  

Slide 59

Slide 59 text

いまの設計はどうか   ● 現在の設計（コンテキストマップ）は比較的早い時期から（頭の中には）できていたし、大きなブレもない  ● 初期から「そこそこ良い設計」が見えていた    ● なぜそれができたか？  ○ 自分たちでオペレーションを回している  →自分がドメインエキスパートである   →筋のいい設計がしやすい     ○ 機能追加時に「関心の分離」と「サブドメインの複雑さ」を意識する 

Slide 60

Slide 60 text

AIエージェントとこれまでの業務システム   違いをあげるとすると...  ● システムの目指す目的の違い   ○ 業務システム→ルール、プロセスをいかに変更可能性高く保つか  ○ AIエージェント→「成果」をいかに得るか  ■ その過程のルール、プロセスは業務システム以上にコロコロ変わる  ■ システム同士の連携をより柔軟に変更したい 

Slide 61

Slide 61 text

AIエージェントとこれまでの業務システム   ● まだまだAIエージェントならではの設計ベストプラクティスはわかってない、知見が広まってない     ● 「結局これまでのシステムと同じ」かもしれない   ● あるいは、違ったプラクティスがあるかも     「AIエージェントのソフトウェア設計」に、   　より多くのエンジニアが取り組んでくれると嬉しいなあ  

Slide 62

Slide 62 text

まとめ  ● AIエージェント「アポドリ」の開発過程をふりかえりました   ○ 自分がドメインエキスパートとしてシステムを構築するのは結構楽しい   ○ プロダクション品質のサービスを作り、高品質を保ちながら開発とデリバリーを続けるにはソフトウェア設計が大事     ● みんなAIエージェントつくろう、たのしいよ  

Slide 63

Slide 63 text

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

Slide 64

Slide 64 text

一句  AIと  スプシでつくる   エージェント  