LLMを取り入れたアプリのアーキテクチャについて

備忘録程度。AI導入におけるGUIの話多め。

LLMを取り入れたアプリケーション開発は、アーキテクチャを3層に分けて考えるべきだ。GUI層, AIエージェント層, データ基盤層の3区分である。そしてGUI層とAIエージェント層はいつでも壊したり別のものに代替可能なように、それぞれ独立したアーキテクチャとレイヤー間のインターフェースを設計するべきだ。

GUI層

既存のGUIであれChatBotのようなAIネイティブなアプリであれ、GUIは非常に重要である。単にユーザーが触る (から操作しやすい画面に) という側面よりも、ユーザーの入力値を標準化するという側面がいっそう重要になった。入力値を標準化するというのは、すなわちPromptの品質をユーザーのドメイン知識や経験を問わず、一定以上の水準に保つことを保証するということである。

現在AIエージェントを使い倒せるのは「特定ドメインに詳しく、かつ言語化能力に秀でている人物」に限定されている。言語化能力は各人の脳の認知特性に由来するもので、絵を描く能力と同様に個人差が著しい。だから組織にAIを浸透させ、最大限に活用するにはPromptの教育よりも「誰がAIに命令しようとしても、このフォームに、必要な情報を全部入れなきゃいけない」というGUIを用意してやる方が効くだろう。

実際の例として、Claude Designは「デザイン発注書」のようなGUIフォームを作成するという手法を取った。説明するまでもなく、デザインの制作は何年もの修業が必要なたいへん高度な知的生産活動である。知識もなしに出来のいいというか、ちゃんと役割を果たしてくれるデザインをつくるというのは不可能だ。

Anthropicはこの問題を、生成前にGUIフォーム入力を強制して「デザイン知識がない人が操作しても「デザインに必要な絶対必須の前提要素」を言語化・添付させることで解決した。なにを、なんのために、どんな雰囲気で表現したいのか。参考となるページや画像イメージはあるか」の入力を強制し、まるでデザイナーがクライアントにヒアリングするように、まず何が欲しいのかを訪ね、それを元にすり合わせていくという方法で解決を取ったのだ。

とくに業務用アプリなど、ユーザーのドメイン知識を問えない領域へのAI導入に必要なのはこのような手法である。GUIとフォームによるユーザー入力値の標準化というアプローチは、Prompt品質の標準化 (=生成結果品質の保証) のベストプラクティスとなるだろう。

AIエージェント層

Claude Code for 〇〇といわれるようなAIエージェント開発そのものであれ、既存のアプリケーションへのAI導入対応であれ、アプリケーション開発においてLLM推論モデルの導入はもはやは避けては通れない問題である。

しかし各種推論モデルがいつまで使えるか、採算の取れるコストで使い続けられるかという問題は残っている。可能ならばいつでも乗り換えられるように設計しておくべきだろう。

世はまさにAIエージェント・LLMモデル開発の大戦国時代。各社しのぎを削りながらデファクトスタンダードを取りに行こうと躍起になってる。競争があるというのは素晴らしい事で、AI産業は毎日のように新しいニュースが舞い込んできて1月単位で「一番いい」サービスが変化している。一方で、ある程度競争が固定化しつもあり、そろそろ値上げが行われる可能性や「コーディングエージェントが月20万円になる」といった予想もまことしやかにささやかれはじめている。そもそもClaude,GPT,geminiを使えば簡単にAIを導入出来るとはいえ、外部のサービスに推論モデル (=コア機能) を依存しているわけだから、何かしらの理由で利用できなくなるリスクは常に存在している。

一方で、Anthropic社が提唱してSkills, MCPといった画期的な概念は各社に広く受け入れられ、AIエージェント開発における一種の共通規格となってきている。

以上の理由から、AIのモデルはいつでもつけ外し・乗り換えが可能な「薄い」層として実装すべきだと考えている。オープンソース利用含め自社で推論モデルを用意する場合はこれには当たらないが、その場合も可能な限り薄く留め、いつでも置換が行えるように設計されるべきだと考えている。

データ基盤層

データベースをはじめとしたデータ基盤のアーキテクチャに設計は、今まで以上に重要な要件になる。先の2層とは異なり、これは破壊的な変更・代替が行えない前提で設計されるべきだ。
RAGであれビックデータ活用であれデータサイエンスであれ、データベースの需要と要求は高まる一方である。これはSSOT（Single Source of Truth) として、従来のソフトウェア開発以上に時間をかけて検討必要以上にすべき領域になる。AIの活用は最終的に、どのようなデータにどのような形式でアクセスできるかに集約される。

生成AIの開発速度が速すぎるので、開発速度を損なわないためにという意味では最後に確定すればよい。しかしAPI駆動などでモックサーバで開発し、データレイヤーは可能な限り開発現場から切り離して、変化する仕様を観察意思ながら時間をかけて定義できる体制が用意されるべきである。

AIエージェントもUIも、その時々のトレンドと時代・要件に合わせて好きなように付け替えられるべきである。しかし、接続されるデータソースはそうあるべきではない。

他方、一般レベルや中小企業レベルではgemini (Google) とNotebookLMに集約されていくのではないか、と考えている。GoogleDriveとの連携とアクセス権の認証が強すぎる。もし自社用に同じようなことが出来るデータ基盤を作ろうとすると、開発・維持コスト共に現実的ではない。そのうえNotebookLMの機能にない高度な使い方がしたい場合も、API経由で任意のAIエージェント・サービスに接続可能だ。

googleはいつだって代替不応なデータ基盤プラットフォームだけを生き残らせて、勝たせ続けている。

(以下余談)
GUI (UI) 層は、簡単につけ外し / 作って壊せる前提でAIデザインツールで作る、という流れが一般化していくと考えている。Webの世界ではGUIは時代のトレンドに合わせて頻繁に変化したり、技術スタックも丸ごとリファクタリングされるというのも珍しくなかった。この流れはAIでデザインツールによって加速し、UIは変わる前提のもの・外付けするもの (=いつでもシステムから切り離せる前提の設計) というアーキテクチャ以外では実用的なソフトウェアは開発できなくなる。API駆動というか、フロントとバックエンドを切り離してアプリケーション間のインターフェースを設計することが重要になる。でないとAIの進化速度に開発速度が追い付けなくなる。

コーディングエージェントの実用化によってソフトウェア開発に不可逆な変化が起きたように、インターフェースはAIでデザインし、そのままアプリケーションのGUIとしてImportする、という開発工程への変化は避けられないだろう。インターフェースのデザインと実装作業は、AIによってプログラミングの次に駆逐される。

エンジニアチームであればモダンなアプリケーション開発はUI層はReact (Next)などが中心なので、その意味では大きな変化はないだろう。ただ開発速度が速くなるだけだ。

しかしNo-codeでの開発はゆるやかに時代遅れの、かえって学習・メンテナンスコストが高いだけの開発手法になっていく。