こんにちは、Algomatic ネオセールスカンパニーCTOのきくちです。
AIエージェント、話題ですね。これまではPoCやR&Dレベルと思われていたAIエージェントですが、いよいよ本格的にサービスが提供されてきました。わたしたちが提供する「アポドリ」もその1つであり、すでに「プロダクションレディな品質」が求められています。
本記事では、わたしたちがアポドリという「営業AIエージェント」サービスを開発・運用する中で「プロダクションレディなAIエージェント」とするために取り組んだ工夫や、「もっとこうしたいんだよね」という伸びしろ部分も交え、実例をご紹介します。この記事によって、AIエージェント開発についてイメージを持てない方にも、AIエージェント開発の醍醐味や面白さが少しでも伝われば幸いです。
まずは「価値を生めるか」が大事
そもそもの話として、プロダクションレディ以前にAIエージェント開発の第一の難しさは、明確に「価値を生めるか」にあります。そこにおいては「プロンプトエンジニアリング」、「ドメイン知識」、「ソフトウェアエンジニアリング」の3要素が重要になります。こちらについては本記事ではなく、 なぜ、Difyなのか にて詳しく解説しているので、そちらをご覧ください。
価値は生めることがわかったら: 「プロダクションレディ」なAIエージェントをつくるために
ここからが本題です。価値検証のフェーズをクリアしたら、次に取り組むべきはAIエージェントを「プロダクションレディ」、つまり実際のサービス運用環境に耐え得るものにすることです。
そもそもプロダクションレディとは
「プロダクションレディ」とは、本番環境で安定して動作し、信頼性が十分に確保された状態と考えます。これを実現するためには、スケーラビリティを考慮したシステム構成、サービス間連携のリトライ戦略などのエラー発生を前提とした設計に加え、迅速かつ安全なデリバリー体制の整備や、監視・アラート設定といった運用環境整備も欠かせません。また、わたしは上記の内容に加えて、「変化に耐えうるソフトウェア設計」も重要な要素と捉えています。
今回は、これらの要素の中から、特にアポドリで重要であった「スケーラビリティの考慮、リトライ戦略」と、「変化に対応しやすい設計」を取り上げます。
1. アポドリを「スケーラブルで信頼性が高いシステム」にする
まずアポドリは、PoCの開始当初からは考えられないほど多くの業務を行うことになりました。
たとえば、1日に数千社の企業情報調査を行うことも珍しくありません。そして1社の調査を行うためには数十のツール起動を伴うため、結果的に1日数万回のツール呼び出しを行うこととなり、まる1日稼働し続けることもあります。エージェントの実行ジョブが長時間化するにつれ、徐々にいくつかの問題が顕在化してきます。1つ目は「エラー対応」、もう1つは「実行時間長すぎ問題」です。
極端な例ですが、24時間かかるジョブが、20時間経過時点でエラーにより全て失敗になってしまうのは避けたいですよね。そして、「24時間かかるとしても、そんなに待てない」というビジネス上の要求も当然出てきます。
それらに対応するためわたしたちは、
- 巨大な一連のジョブを複数の子タスクに分割し、
- タスク単位でリトライ可能にする
- タスク単位で並列実行を可能にする
このような仕組みを実装・構築しました。こうすることで、タスク実行中にエラーが発生したとしてもタスク単位でリトライ可能になるため影響は小さくできます。そして、任意の並列数で並列実行できるようになったことで、「急いでいる時はたくさん動かして急ぐ」ことが可能になりました。つまり、いわゆるスケールアウトできるようになったわけです。
ただし、これらの仕組み自体はContainer App Job（Azure上のコンテナジョブ実行環境）と、簡易的な分散ロック機構のみからなる、非常にシンプルなものです。並列実行数も人間によるパラメータ設定が必要という、のびしろだらけの状態です。目下、「処理完了希望時間」や「LLMのレートリミット」を考慮した自動スケーリングなどは優先的に取り組みたい課題です。おすすめのミドルウェアなどあれば、ぜひ教えてください！
2. アポドリを「変化に柔軟に対応できる設計」にする
次に、ソフトウェア設計の話をします。アポドリが大事にしたのは「チームとして変化に強い」こと、「アジリティ」、あとは「メリハリ」です。
アポドリはmonorepo構成
まずアポドリのリポジトリ構成の話ですが、TypeScript + pnpmでのmonorepo構成となっています。monorepoとした理由は以下の2点です。
- 様々な種類のツールを実装していくことが見えていたので、それらを明確に分離できるようしたかった
- とはいえ、複数リポジトリに分かれることは避けたかった
リポジトリが分かれることで、チームメンバーそれぞれに「得意なリポジトリ」「あんまり知らないリポジトリ」が生まれ、心理障壁が存在してしまうことは避けたいものです。どのパッケージ、機能でもメンバーみんな苦手意識なく触れることは、チームとして変化に強くなり、必要な機能を最速で実装できるチームであるために大事なポイントです。
パッケージごとに設計・実装方針を変える
こちらは「メリハリ」に係る部分です。価値検証過程の機能や、「とりあえず動けばいい」ものはベタ書きのトランザクションスクリプトを良しとし、一方で、仕様の複雑化が見えているものはオブジェクト指向アプローチでボトムアップの設計・実装を徹底しています。この実装方針は、パッケージごとに決定されています。
より具体的には、アポドリにおけるアプローチシーケンス決定（「誰に」「どの頻度で」「いつ」「どの文面を送るか」を決定するモノ）は、はじめから堅牢な設計で実装しています。この部分は今後「ああしたい」「こうしたい」といった要望が発生することは明白であったので、後の拡張や修正が容易であることを重視しています。一方で、試験的に実装する機能は「いったん動かして価値検証する」ことが大事なので、新パッケージにシンプルに実装します。試験的に実装した機能がだんだん育っていく気配を感じた場合は、中身を作り直しましょう。パッケージ同士の境界とインターフェースだけ正しく定義できていれば、中身の作り替えは比較的安全に行うことができます。
「プロダクションレディ」にするためには
プロダクションレディなAIエージェント開発には、わたしたちソフトウェアエンジニアがこれまで培ってきた技術や知識、経験が不可欠です。
AIエージェントはもう、単なるR&Dではありません。価値を生めることは実証されています。価値を生めるサービスに求められるのは、AIエージェントをスケールさせ、進化させ続けるソフトウェアエンジニアリングです。
SaaSとは異なる点はなんだろうか
ただし、SaaSとAIエージェント開発の違いを感じる点があります。
アポドリの開発、運用をしていて感じるところなのですが、「AIエージェントサービス」は、従来のSaaSとは 顧客要望の形が本質的に異なるな、と感じています。なぜでしょうか。
SaaSは「いかに使いやすく」するかが焦点になります。それゆえ、「このツールが使いやすいか」は顧客ひとりひとりにおいて異なり多様であります。取捨選択に迷うことがありますよね。一方でAIエージェントは「いかに成果を得やすく」するかが焦点になります。「成果を得やすく」するための改善に個人差は少ないように感じます。
この「あるべき姿」に向かって改善を続けていくAIエージェントの開発過程、非常に面白いです。
一緒にAIエージェントアーキテクチャを探究しませんか
ここまで読んでいただきありがとうございました。「面白そうだな〜」と思ったエンジニアの方、「こいつは何もわかっちゃいない、俺がもっといい感じにしてやる」と感じたアーキテクトの方などなど、ぜひお話ししましょう！
