AI製品の出荷：失敗したスタートアップからの実践的教訓

人工知能の急速に進化する状況において、誇大広告が実用的な応用を上回ることが多い中、フィル・カルサドは、彼が失敗したAIスタートアップOutropyからの厳しくも洞察に満ちた事後分析を提供します。最近のInfoQカンファレンスで、SoundCloudでのマイクロサービスの先駆者として知られるベテランソフトウェアエンジニアであるカルサドは、生成AI製品を話題性だけでなく実際に「出荷」することの現実について率直な教訓を共有しました。彼の核となるメッセージは、AI開発を成功させる鍵は、未来的なビジョンを追い求めることではなく、確立されたソフトウェア工学の原則を厳密に適用することにある、というものです。

カルサドはまず自身の偏見を認めました。それは、分散システムやマイクロサービスを中心に30年間ソフトウェアを構築してきた経験と、「物事を成し遂げる」反復的なアジャイル開発への強い傾倒です。この視点が、彼がAIについて抱く見方を形成していると彼は認め、AIもこれらの基本的な実践から免れるべきではないと信じています。

カルサドのベンチャーであるOutropyは、生成AIを用いて管理およびエンジニアリングのワークフローの一部を自動化することを目指し、Slackチャットボットとして始まり、Chrome拡張機能へと発展しました。生成AI分野の初期参入者であり、数千人のユーザーを獲得し、品質面ではSalesforceのようなテクノロジー大手の製品さえも凌駕した（彼自身のベンチマークによる）にもかかわらず、このスタートアップは最終的に失敗しました。ユーザーからのフィードバックで驚くべき点は、多くの人がツール自体よりも、「2人の男と1匹の犬」によって構築されたOutropyが、なぜこれほど効果的な「エージェント的な振る舞い」—自律的で意思決定能力—を持つシステムを、大手企業が苦戦する中で作り出せたのか、その逆エンジニアリングに興味を持っていたことでした。この逆説が、カルサドに、なぜほとんどのAI製品、特に生産性分野で、期待に応えられないのかを深く分析するきっかけを与えました。

カルサドは、今日AIを構築するための3つの主要なアプローチを特定し、それぞれに独自の落とし穴があると指摘します。1つ目は「Twitter駆動開発」で、まだリリースされていない、今後登場するモデルへの執着と、現在の技術的限界の無視が特徴です。これはしばしば、資金を確保するためだけの派手なデモにつながり、現実世界での価値を提供できません。2つ目は、AI開発を純粋な「データサイエンスプロジェクト」として扱うもので、これは通常、大企業で見られます。この方法は、しばしば遅く研究に重点が置かれ、わずかな改善にも何年もかかることがあり、AIが製品のクリティカルパス上にある場合には許されない贅沢です。3つ目、そしてカルサドが好むアプローチは、AI開発を伝統的な「エンジニアリングプロジェクト」として扱い、最初から反復開発を取り入れることです。

彼は次に、生成AIシステムの基本的な構成要素であるワークフローとエージェントについて深く掘り下げました。ワークフローは、彼が「推論パイプライン」と呼ぶことを好むもので、メールの要約など、AIの目標を達成するための事前定義された一連のステップを表します。一方、エージェントは半自律的なソフトウェアコンポーネントであり、大規模言語モデル（LLM）が自身のプロセスを動的に指示し、ツールを使用し、協力して、与えられた目標を達成するためのタスクを実行します。

ワークフローに関して、カルサドは、コンテキストをLLMに直接供給すると約束するRetrieval-Augmented Generation (RAG) ベンダーにのみ依存するという一般的な落とし穴に警告しています。彼は、LLMがこの単純なアプローチには十分賢くないことが多く、構造と意味的な意味を追加するための追加ステップが必要であることを見出しました。例えば、Outropyが日次ブリーフィングで成功したのは、複雑なタスクを、データパイプラインのように、より小さな構造化された変換に分解したからでした。これにより、既存のデータパイプラインツールと方法論を適用でき、AI開発をなじみのあるエンジニアリングの領域に根付かせることができました。

エージェントについて、カルサドは挑発的な主張をしています。「エージェントはオブジェクト指向プログラミングにおけるオブジェクトと非常によく似ている。」彼は、従来のマイクロサービスがそのステートフル性、非決定的な振る舞い、そしてデータ集約的な性質のためにエージェントには不向きであることを認めつつも、オブジェクト指向パラダイム — メモリ（状態）、目標指向（カプセル化）、ダイナミズム（ポリモーフィズム）、コラボレーション（メッセージパッシング）といった概念 — がエンジニアにとって有用なメンタルモデルを提供すると主張しています。

アーキテクチャ的には、カルサドはエージェント間のポイント・ツー・ポイント連携を避けるよう忠告しています。これは密結合につながり、20年前の複雑なWebサービススタックを再発明することになりかねません。代わりに、彼はRedisやKafkaのようなメッセージバス上の「セマンティックイベント」を提唱しています。エージェントは特定の、明確に定義されたイベントに関心を登録し、疎結合とスケーラビリティを促進します。彼はまた、AnthropicのModel Context Protocol (MCP)のような新興標準を内部製品に採用することにも警告しています。それらはSOAPのような初期の、過剰設計されたプロトコルを想起させると見ています。内部システムには、RESTfulアーキテクチャやgRPCのような経験的に証明された方法に固執することを提案しています。

「エージェント的記憶」—エージェントがユーザーに関する知識を保持するという課題—に関して、カルサドは、すべての情報をベクトルデータベース内の長いテキスト文書に保存するという一般的なアプローチを却下しています。彼は、欠陥のある記憶は記憶がないよりも悪いと主張します。彼が推奨する解決策は「イベントソーシング」です。これは、ユーザーに関するセマンティックイベントのストリームを構造化された表現に圧縮し、しばしばNeo4jのようなグラフデータベースに保存することで、より堅牢で進化する理解を可能にします。

最後に、カルサドはデータサイエンスプロジェクトにおける一般的な「モノリシックパイプライン」アプローチに異議を唱えています。これは、データ取り込みから出力までの全プロセスが単一の、密結合されたユニットとして構築されるものです。彼はこれらのワークフローを、明確に定義されたインターフェースを持つ、より小さく独立したコンポーネントに分解することを支持しています。これは、ドメイン駆動設計やマイクロサービスからおなじみの概念で、柔軟性と再利用性を可能にします。

彼は最後に、たとえ「分散オブジェクト」の魅力があったとしても、現代のクラウドインフラを支える「Twelve-Factor App」マニフェストの基本的な原則は、エージェントAIシステムの固有のステートフル性と非決定的な性質のために、しばしば破られていると述べています。このため、レジリエンス、再試行、チェックポイント処理を扱う「耐久性のあるワークフロー」（Temporalなどが提供）への移行が必要であり、エンジニアがこれらの重要なインフラストラクチャコンポーネントを絶えず再発明するのを防ぎます。

カルサドの最終的な結論は力強いものです。Outropyのような現在のAI製品アーキテクチャに見られる複雑さは、サービスを提供するユーザー数に対してしばしば「過剰に複雑」であり、より良いプラットフォームの必要性を強く示唆しています。しかし、彼は、成功するAI製品を構築することは、根本的に、長年のソフトウェア工学の知恵を適用することに尽きると断言しています。エンジニアは既存の知識を活用し、AIが、その誇大広告にもかかわらず、これまで取り組んできた課題と根本的に異なると信じる誘惑に抵抗すべきです。