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

2025-07-25 設計ナイト2025の登壇資料です。

Transcript

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

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

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

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

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

6. 事前知識

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

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

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

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

11. 事前知識2: AIエージェントの分類 
 AIエージェントといっても、大きく分けて二種類あります 
 
 • 自律型エージェント 
 • Agentic Workflow 
 ←こっちの話をします
12. 事前知識3: 「気がついたらAIエージェントになっていた」プロダクト紹介 

13. 事前知識3: 「気がついたらAIエージェントになっていた」プロダクト紹介 
 ⼈の代わりに営業活動を⾏う「AIエージェント」 従 来 ア ポ ド リ 営業！ 営業！ お願い！
14. 事前知識3: 「気がついたらAIエージェントになっていた」プロダクト紹介 
 リスト 提供 企業情報収集 企業名や住所、URL情報からWeb‧独⾃DBを探索し、収集 収集したデータの加⼯や評価 担当者収集 企業の役員‧従業員の情報をWeb‧独⾃DBを探索し、収集 収集したデータの加⼯や評価 1to1⽂章⽣成 企業情報、担当者情報を元に、ターゲットリストに最適なオリ ジナルの1to1メッセージを作成、評価 アプローチ実⾏ メール/問い合わせフォーム/SNS/⼿紙などのあらゆるチャネル からアプローチを実施 データ分析 どういった内容、業界、役職、部署へのアプローチが効果的で あったか分析し提⽰ アプローチ先 情報収集 連絡先、問い合わせフォームをWeb‧独⾃DBを探索し、収集 収集したデータの加⼯や評価
15. 「気がついたら」ってどういうことなの 
 1. 営業領域で何か事業やろう！
 2. アウトバウンド営業を支援する仮説思いつく
 3. 仮説実証のために営業代行をやろう！
 4. 仮説はともかく、AIフル活用して営業代行で成果だそう！
 5. 仕組みつくれた、成果でた！
 6. 複数の顧客が「利用したい」といってくれている！この仕組み、そのまま売れるので は？
 7. 営業AIエージェント「アポドリ」としてリリース！

16. 本題

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

18. 計画モジュール アポドリのコンテキストマップ（現在の姿／一部抜粋） 
 企業情報収集機能 テンプレ作成機能 1to1文面生成機能 アプローチ実行機能 計画機能 戦略モジュール 収集モジュール 送信モジュール U U U U D D D D
19. アポドリのワークフロー（再掲） 
 リスト 提供 企業情報収集 企業名や住所、URL情報からWeb‧独⾃DBを探索し、収集 収集したデータの加⼯や評価 担当者収集 企業の役員‧従業員の情報をWeb‧独⾃DBを探索し、収集 収集したデータの加⼯や評価 1to1⽂章⽣成 企業情報、担当者情報を元に、ターゲットリストに最適なオリ ジナルの1to1メッセージを作成、評価 アプローチ実⾏ メール/問い合わせフォーム/SNS/⼿紙などのあらゆるチャネル からアプローチを実施 データ分析 どういった内容、業界、役職、部署へのアプローチが効果的で あったか分析し提⽰ アプローチ先 情報収集 連絡先、問い合わせフォームをWeb‧独⾃DBを探索し、収集 収集したデータの加⼯や評価
20. 営業代行開始〜アポドリになるまで 

21. 営業代行のはじまり 
 アウトバウンド営業代行をやろう！
 AIを活用して、人間では実行不可能な行動量と品質 を担保しよう！
 アプローチ先の1社1社にあわせた1to1の文章を送ろう！
 アプローチしたい 企業リスト
22. 営業代行のはじまり 
 システム 無
 アプローチしたい 企業リスト インプット 業務フロー 企業リストから連絡先を収集 アプローチ文面のテンプレ作り 企業ごとの1to1文面をつくる アプローチ計画 アプローチ実行
23. 最低限のシステム実装 
 何を作るべきか、何を作らざるべきか
 あるもの
 • 営業ドメインエキスパート
 • 粗いワークフロー
 
 → 人間がどう頑張っても無理な部分 だけシステムとして実装する
 　 システム化できない部分は自分たちで手動オペレーション 
 　 PoC段階なので作り込むことは避けたい。CLIツールとスプシで戦う 

24. 最低限のシステム実装 
 システム アプローチしたい 企業リスト インプット 業務フロー 企業リストから連絡先を収集 アプローチ文面のテンプレ作り 企業ごとの1to1文面をつくる アプローチ計画 アプローチ実行
25. 最低限のシステム実装 
 システム アプローチしたい 企業リスト インプット 業務フロー 企業リストから連絡先を収集 アプローチ文面のテンプレ作り 企業ごとの1to1文面をつくる アプローチ計画 アプローチ実行 1000件規模の企業の 連絡先を収集して スプシに入力 ↓ 人間には無理
26. 最低限のシステム実装 
 システム アプローチしたい 企業リスト インプット 業務フロー 企業リストから連絡先を収集 アプローチ文面のテンプレ作り 企業ごとの1to1文面をつくる アプローチ計画 アプローチ実行 連絡先収集ツール
27. 最低限のシステム実装 
 システム アプローチしたい 企業リスト インプット 業務フロー 企業リストから連絡先を収集 アプローチ文面のテンプレ作り 企業ごとの1to1文面をつくる アプローチ計画 アプローチ実行 連絡先収集ツール 営業メールの テンプレート作成 いろんなノウハウが必要 ↓ 作業負荷は高いが、 数が少ないので人間でもできる
28. 最低限のシステム実装 
 システム アプローチしたい 企業リスト インプット 業務フロー 企業リストから連絡先を収集 アプローチ文面のテンプレ作り 企業ごとの1to1文面をつくる アプローチ計画 アプローチ実行 連絡先収集ツール テンプレをつくる人間
29. 最低限のシステム実装 
 システム アプローチしたい 企業リスト インプット 業務フロー 企業リストから連絡先を収集 アプローチ文面のテンプレ作り 企業ごとの1to1文面をつくる アプローチ計画 アプローチ実行 連絡先収集ツール テンプレをつくる人間 いつ、どの企業に、 どの文面を送るか ↓ 頭はこんがらがるが、 なんとかなる
30. 最低限のシステム実装 
 システム アプローチしたい 企業リスト インプット 業務フロー 企業リストから連絡先を収集 アプローチ文面のテンプレ作り 企業ごとの1to1文面をつくる アプローチ計画 アプローチ実行 連絡先収集ツール テンプレをつくる人間 アプローチ計画をする人間
31. 最低限のシステム実装 
 システム アプローチしたい 企業リスト インプット 業務フロー 企業リストから連絡先を収集 アプローチ文面のテンプレ作り 企業ごとの1to1文面をつくる アプローチ計画 アプローチ実行 連絡先収集ツール テンプレをつくる人間 アプローチ計画をする人間 アプローチ先企業の特徴を 踏まえて、 1社1社個別の 文面を作成し、テンプレに埋 め込む ↓ 1000件の作文は さすがに無理
32. 最低限のシステム実装 
 システム アプローチしたい 企業リスト インプット 業務フロー 企業リストから連絡先を収集 アプローチ文面のテンプレ作り 企業ごとの1to1文面をつくる アプローチ計画 アプローチ実行 連絡先収集ツール テンプレをつくる人間 アプローチ計画をする人間 1to1文面をつくるツール
33. 最低限のシステム実装 
 システム アプローチしたい 企業リスト インプット 業務フロー 企業リストから連絡先を収集 アプローチ文面のテンプレ作り 企業ごとの1to1文面をつくる アプローチ計画 アプローチ実行 連絡先収集ツール テンプレをつくる人間 アプローチ計画をする人間 1to1文面をつくるツール メール送信など GASや手動でなんとかなる
34. 最低限のシステム実装 
 システム アプローチしたい 企業リスト インプット 業務フロー 企業リストから連絡先を収集 アプローチ文面のテンプレ作り 企業ごとの1to1文面をつくる アプローチ計画 アプローチ実行 連絡先収集ツール テンプレをつくる人間 アプローチ計画をする人間 1to1文面をつくるツール アプローチを実行する人間
35. 最低限のシステム実装 
 CLIツール + スプシによる手運用。大部分の作業がシステム化されていない状態 
 設計という概念の存在しない世界 
 あるのは、トランザクションスクリプト とスプシと人間
 連絡先収集ツール テンプレをつくる人間 アプローチ計画をする人間 1to1文面をつくるツール アプローチを実行する人間 集約スプシ
36. ほどなく「アプローチ計画」が混みいってくる 
 営業代行の案件数が2つに増える
 「アプローチ計画をする人間」がパンクし、システム化を余儀なくされる
 業務フロー 企業リストから連絡先を収集 アプローチ文面のテンプレ作り 企業ごとの1to1文面をつくる アプローチ計画 アプローチ実行 わけわからな くなってきまし た
37. ほどなく「アプローチ計画」が混みいってくる 
 営業代行の案件数が2つに増える
 「アプローチ計画をする人間」がパンクし、システム化を余儀なくされる
 
 →「気合いの入ったスプシ」 で凌ぐ
 業務フロー 企業リストから連絡先を収集 アプローチ文面のテンプレ作り 企業ごとの1to1文面をつくる アプローチ計画 アプローチ実行
38. ほどなく「アプローチ計画」が混みいってくる 
 スプレッドシートが複雑化しただけ で事なきを得る
 連絡先収集ツール テンプレをつくる人間 アプローチ計画をする人間 1to1文面をつくるツール アプローチを実行する人間 集約スプシ Ver2 計画表シート
39. ほどなく「アプローチ計画」が混みいってくる 
 …が、気合いの入ったスプシ も1ヶ月程度で限界 を迎え、いよいよシステム化
 豆知識: スプシのセル数上限は1000万セル
 集約スプシ Ver2 計画表シート もう無理です
40. 「計画」モジュールの誕生 
 • スプシチャレンジにより「計画」業務の複雑さ は肌身に染みていた
 • また、より複雑な発展をしていくことも自明だった
 →トランザクションスクリプトでは無理 
 
 →　既存機能とは分離した別モジュールに、クリーンアーキテクチャで実装 

41. 「計画」モジュールの誕生 
 連絡先収集ツール テンプレをつくる人間 1to1文面をつくるツール アプローチを実行する人間 集約スプシ Ver2 計画モジュール その他モジュール 計画モジュール
42. 業務フローの複雑化 
 インプットとして企業URLを受領できないケースが増 えてくる
 業務フロー 企業リストから連絡先を収集 アプローチ文面のテンプレ作り 企業ごとの1to1文面をつくる アプローチ計画 アプローチ実行
43. 業務フローの複雑化 
 インプットとして企業URLを受領できないケースが増 えてくる
 →「企業HP特定」という業務が追加 
 
 業務フロー 企業リストから連絡先を収集 アプローチ文面のテンプレ作り 企業ごとの1to1文面をつくる アプローチ計画 アプローチ実行 企業名からHP特定 New!
44. 業務フローの複雑化 
 インプットとして企業URLを受領できないケースが増 えてくる
 →「企業HP特定」という業務が追加 
 
 すると、企業HP特定の精度 が問題になってくる
 業務フロー 企業リストから連絡先を収集 アプローチ文面のテンプレ作り 企業ごとの1to1文面をつくる アプローチ計画 アプローチ実行 企業名からHP特定 New!
45. 業務フローの複雑化 
 インプットとして企業URLを受領できないケースが増 えてくる
 →「企業HP特定」という業務が追加 
 
 すると、企業HP特定の精度が問題になってくる
 →人間による「目検チェック」業務追加 
 
 追加された業務実現のための機能実装 
 業務フロー 企業リストから連絡先を収集 アプローチ文面のテンプレ作り 企業ごとの1to1文面をつくる アプローチ計画 アプローチ実行 企業名からHP特定 New! 収集結果を目検 New!
46. 業務フローの複雑化 
 新規機能を「収集モジュール」として切り出して実装
 企業情報収集ツール New! テンプレをつくる人間 1to1文面をつくるツール アプローチを実行する人間 集約スプシ Ver2 計画モジュール その他モジュール 計画モジュール 目検スプシ New! 収集モジュール
47. その先
 「送信」や「戦略」などがシステム化され、モジュールとして追加されていく
 企業情報収集ツール New! テンプレをつくるツール 1to1文面をつくるツール アプローチ実行ツール 集約スプシ Ver2 計画モジュール 戦略モジュール 計画モジュール 目検スプシ 収集モジュール 送信モジュール
48. 計画モジュール スプシを排した現在の姿 
 企業情報収集機能 テンプレ作成機能 1to1文面生成機能 アプローチ実行機能 計画機能 戦略モジュール 収集モジュール 送信モジュール U U U U D D D D
49. 考えていたこと 

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

51. モジュールごとの設計方針 
 • モジュールごとに設計パターンを選定
 ◦ トランザクションスクリプト
 ◦ クリーンアーキテクチャ
 
 • どう選ぶか？
 ◦ モジュール（サブドメイン）のカテゴリーを見極める※ 
 ▪ 補完: 競争優位を生まない　
 ▪ 一般: 外部サービスで代替可能
 ▪ 中核: 競争優位の源泉
 ※ドメイン駆動設計をはじめよう 1章「事業活動を分析する」より
52. モジュールごとの設計方針 
 • モジュールごとに設計パターンを選定
 ◦ トランザクションスクリプト
 ◦ クリーンアーキテクチャ
 
 • どう選ぶか？
 ◦ モジュール（サブドメイン）のカテゴリーを見極める※ 
 ▪ 補完: 競争優位を生まない　→トランザクションスクリプト 
 ▪ 一般: 外部サービスで代替可能 →トランザクションスクリプト 
 ▪ 中核: 競争優位の源泉
 ※ドメイン駆動設計をはじめよう 1章「事業活動を分析する」より
53. モジュールごとの設計方針 
 • モジュールごとに設計パターンを選定
 ◦ トランザクションスクリプト
 ◦ クリーンアーキテクチャ
 
 • どう選ぶか？
 ◦ モジュール（サブドメイン）のカテゴリーを見極める※
 ▪ 補完: 競争優位を生まない　→トランザクションスクリプト
 ▪ 一般: 外部サービスで代替可能 →トランザクションスクリプト
 ▪ 中核: 競争優位の源泉 →？ 
 ※ドメイン駆動設計をはじめよう 1章「事業活動を分析する」より
54. 「中核」サブドメインの設計 
 • もれなく「変更容易性」が重要 
 • これまでの業務システムであれば、
 クリーンアーキテクチャなど「変更容易性を担保する」設計が必須 になる
 

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

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

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

58. ふりかえり 

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

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

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

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

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