今僕はA1AというスタートアップでCTO室をやってる。まぁ結構面白くて難しい問題を考えていて、考えていること晒すわ。面白そうだなと思ってくれた人がいたら、手伝ってくんね？

注）今日思ったことを書いたものなので、明日には違うことを言っているかもしれません。

LLM時代のWebアプリケーションアーキテクチャ

背景と問題意識

LLM技術のコモディティ化

LLMを利用する技術は急速にコモディティ化している。フレームワークを利用してLLM APIを活用したり、マルチエージェントAIを構築する技術が、専門家ではなく一般のアプリケーションエンジニアにまで求められるようになる。

これは、サーバー側でHTTP(S)を喋るシステムを作る技術だけでは不十分となり、ReactやNext.jsなどのフロントエンド技術まで手を広げなければならなくなった近年の流れに似ている。

Webアプリケーションの進化

Webアプリケーションは以下のように進化してきた：

1. 第一世代: データを保存して、データを表示する仕組み
2. 第二世代: データを出し入れする仕組みに、UI/UXの洗練とドメイン特化が乗ったもの
3. 第三世代（LLM時代）: 「ある種の賢さ」がWebアプリケーションに乗ってくる

核心的な思想

「ある種の賢さ」とは

• 単一の「AI機能」が主要機能として存在するのではない
• Webアプリケーションの大小様々な機能が、AIの見た目をしている・していないにかかわらず、裏では当たり前のようにLLM poweredな機能としてUXを築いている
• RDBにクエリを投げたり、プログラム可能な一定のロジックだけでは実現できない出力
• 今まで「ユーザーに判断してもらうしかない」とされていたものを、AIが判定・提案できるようになる

チーム構成の変革

古い体制:

• 主要な機能のAIの精度を高めるための専門家チーム
• それをユーザーに届けるためのUI開発チーム

新しい体制:

• 「ユーザーに価値を届けるための開発チーム」が1つ
• このチームはUIも作るし、LLMを活用した「賢さ」も開発する
• 原則として、全員が全部できなければならない

アーキテクチャの方向性

• LLMは「専門家チームが提供するbackendマイクロサービス」ではない
• もっとアプリケーションに近く、場合によってはユーザーの近くにある
• 大小さまざま、たくさんのLLM活用が存在する

現実的な制約

技術スタックの制約

• 現状では「LLMによる賢さ」の部分はPythonかNodeでなければまともに作れない
• この制約は将来的にも解消されないだろう
• LangChain/LangGraphやVercel AI SDKを超えるものは各言語で出てこない

移行期の課題

• 既存のRailsアプリケーションは現役
• しかし「マイクロサービス」でAIとそれ以外を分けるのは開発オーバーヘッドが大きい
• もっとRailsの近くでAIが動いてほしい

これから考えるべきこと

1. 移行期のアーキテクチャパターン

• RailsとPython/NodeのAIサービスをどう連携させるか
• サイドカーパターン、プロセス制御、その他のアプローチの検討
• 開発体験（DX）をどう保つか

2. セキュリティとコスト制御

• ユーザーごとのRate Limit管理の実装レイヤー
• プロンプトインジェクション対策の共通基盤化
• コスト予測・監視の仕組みの組み込み方

3. 開発プロセスとテスト

• プロンプトのバージョン管理とA/Bテスト戦略
• 非決定的な出力に対するテスト手法
• 開発環境でのLLM利用（モックか実APIか）

4. 具体的な実装例の検討

• 最初にLLMで「賢く」すべき機能の選定
• アーキテクチャ構成の具体化
• 技術選定の基準と理由
• 予想される課題と対策

5. 組織の変化と成長戦略

• 既存のRailsエンジニアがLLM技術を習得する道筋
• 採用戦略の見直し
• 「全員が全部できる」理想に向けた現実的なステップ

今後の展望

インフラ技術がクラウド化とIaCによってアプリケーションエンジニアの責務に吸収されたように、AI技術も同様の道を辿ると予想される。AIエンジニアという専門家の役割は希薄化し、AI poweredな機能は当たり前のようにアプリケーションのあらゆる機能の中に存在するようになる。

この世界では、単にLLM APIを呼べばそれっぽい賢さを演出できるというだけでは価値にならず、ユーザーのドメインに深い理解をし、真にユーザーの課題を解決できるかどうかが差別化要因となる。