業務アプリは「UI中心」から「API中心」へ——AI-Nativeアーキテクチャで考える、これからのSaaS

これまでのSaaS——UIが主役の三層構造、APIは「二級アクセス」

Salesforce、freee、kintone——おそらく皆さんが触っている業務SaaSのほとんどは、次の三層で構成されています。

• プレゼンテーション層（UI）：ユーザーが操作する画面。ここが事実上の「アプリ本体」として扱われる
• ビジネスロジック層：業務のルールが書かれているが、画面に紐づいて散らばっていることも多い
• データ層：データベース

API は「外部システムと連携したい人のための、あれば便利な入口」という位置付け——いわば二級アクセスです。UI から呼べることは API からは呼べない、UI でしか実行できない処理がある、エラーメッセージはUI前提で書かれている……ということが、ごく普通に起きます。

この構造のままでは、LLM は「画面を操作する代理人」か「外側からポチポチ API を叩く下請け」のどちらかにしかなれません。本来 LLM が持っている「複数のシステムを横断し、状況に応じて手順を組み立てる」力は、ほとんど活かされない。

AI-Nativeアーキテクチャ——APIが主役、UIとLLMは対等な「クライアント」

僕がリクステップで採っている設計思想はシンプルです。

層構造を、従来とAI-Nativeで並べてみるとこうなります。

この設計の何が新しいかというと、「UI でできること」と「AI でできること」のズレが構造的にゼロになる点です。マウスのクリックでも、自然言語の会話でも、まったく対等にドメインモジュール（業務の本体）を動かせる。「AI からはここまでしかできません」という気まずい制約が、設計上発生しません。

GUI Chat Protocol——プレゼンテーションを「アプリから独立した部品」にする

API を主役に据えると、もう一つ重要な役割を担うのが「GUI Chat Protocol」と呼ばれる仕組みです。これは「アプリから独立した汎用プレゼンテーション部品」を、LLM が必要に応じて呼び出して画面を組み立てるためのプロトコルです。

従来であれば、開発者が事前に作り込んでいた拡張UIや、顧客側が独自開発していたカスタムUIを、LLM が実行時に自動生成できるようになります。汎用部品にはたとえば次のようなものがあります。

これらは「どの業務アプリにも属さない汎用部品」として、独自のペースで進化します。業務アプリ側はグラフ描画ライブラリを自前で抱える必要がなく、「グラフ化可能なデータ」だけを返せばよい。LLM が実行時に DSPL（Domain Specific Presentation Language）を生成して、データと部品をつなぎ合わせる役割を担います。

つまり LLM は「一つのアプリのコントローラ」ではなく、複数のプラグインを横断してデータの流れを組み立てるオペレータです。「第3四半期の売上をグラフにして、前年同期と並べて」というワークフローは、コードとしてはどこにも書かれていません。LLM が実行時に「会計プラグインから読み、チャート部品に渡す」と判断した瞬間に、初めて出現します。

「不変条件こそが価値の中心」——会計・在庫・スケジューリング系で効く

この設計が本当に効いてくるのは、「破ってはいけないルール（不変条件）こそが価値の中心」であるアプリです。会計、スケジューリング、在庫管理、契約管理、計画系——誰が呼んでもルールが破られてはならない領域。

会計を例に取れば、複式簿記の不変条件——「すべての仕訳が貸借一致」「過去仕訳の削除は不可」「修正は逆仕訳ペアで行う」——は、UI でも API でも LLM でも、絶対に破られてはいけません。これらをドメインモジュール側にがっちり持たせることで、LLM がどんな自然言語入力を投げてきても、「結果として不正な状態にはなりようがない」という安全性が成立します。

逆に言うと、UI 側にバリデーションが書かれていて、API はそれを信じて素通しさせるような従来設計は、AI-Native の文脈では完全に破綻します。LLM は UI を通らずに API を直接叩くので、UI 層のチェックは存在しないのと同じだからです。

なぜ今、この設計が成立するのか——3つの条件が同時に揃った

AI-Native アーキテクチャは、突然うまく回り始めたわけではありません。次の3つの能力が、ここ数年でようやく同時に揃いました。

どれか一つでも欠けると成立しません。だからこそ「AI を業務SaaSに後付けする」フェーズは過渡期で、いずれ「最初から AI を一級クライアントとして織り込んだプロダクト」に置き換わっていく——僕はそう確信しています。

リクステップの開発思想——「トリログ」はこの設計で作っている

抽象論だけだと宙に浮くので、自社プロダクト第1弾「トリログ」でこれをどう実装しているかを、少しだけ開きます。

トリログは、出張経費の自動計算アプリです。「スマホに入れるだけでGPSが出張を判定し、社内の旅費規程に基づいて非課税の出張手当を自動で適用する」——というのが見える機能ですが、設計の中心は「旅費規程ドメイン」を独立した API モジュールとして切り出したことにあります。

• 不変条件はドメイン側にある：役職別の日当単価、エリア別の宿泊費上限、海外出張規程、連泊割引、社用車利用時の控除——これらの「破ってはいけないルール」は、UI からも、将来の自然言語インターフェースからも、必ず同じロジックで適用されます。
• UI はクライアントの一つ：スマホアプリは GPS ログを送り、規程に基づく計算結果を受け取って表示するだけ。同じ API を、会計ソフト連携や承認ワークフロー、将来の自然言語経由の問い合わせがそれぞれ叩きます。
• 会計ソフト連携は GUI Chat Protocol 的に外出し：freee / マネーフォワード / 弥生 / 勘定奉行 への仕訳エクスポートは、トリログ本体の関心事ではありません。「仕訳可能なデータ構造」を返し、変換は外側の部品に任せる、という分け方をしています。

結果として、「自然言語で『先月の関西出張だけの日当を集計して』と聞いたら、その場で集計UIが組み立てられる」——という未来の体験まで、追加開発なしに射程に入ります。LLM が API を呼び、結果を presentSpreadsheet 的な汎用部品に渡せばよいからです。

これから——SaaSの価値は「UIの豊富さ」ではなく「APIに織り込まれた業務知」へ

SaaS産業は過去20年、「豊富な UI を提供する」「業務に合わせて細かくカスタマイズできる」「他のアプリと連携する」——という方向に投資を集中させてきました。けれど、これらはどれも「アプリの価値は UI にある」という90年代の価値観に基づく進化です。

自然言語を理解し、GUI Chat Protocol を通じてプレゼンテーション部品を駆使できる LLM が当たり前に存在するこれからの時代は、価値の重心がはっきり移ります。

この前提に立つと、業務SaaSを作る側のやるべきことは大きく変わります。

• 業務ドメインの不変条件を、UI ではなくドメインモジュールに固定する
• API を「連携用の二級アクセス」ではなく「プロダクトそのもの」として設計する
• プレゼンテーション層は薄く保ち、いずれは汎用部品＋LLM に置き換わってもよい構造にする
• 「自然言語で何を聞かれても、ドメイン側の不変条件は絶対に破れない」状態を作っておく

リクステップは、トリログをはじめとした自社プロダクトと、お客様の業務システム開発の両輪で、この設計を本気で展開していきます。「30年続いた『アプリ＝UI』という固定観念から自由になれる時代がようやく来た」——僕にとって、ここに張らない理由がありません。

中堅企業の経営者・情シスの皆さまへ

「うちの業務システムも AI で何かしたいけれど、既存システムの上に Copilot 的なものを乗せるだけで本当にいいのか？」——この問いを持ち始めた経営者・情シス責任者の方には、ぜひ一度ご相談ください。

AI 後付けで済む業務と、いっそ AI-Native でゼロから組み直したほうが筋がよい業務は、はっきり分かれます。リクステップは、その見極めと、ドメインモジュール化〜API ファースト設計〜LLM 連携までを一気通貫でお手伝いできる数少ない開発会社です。

関連リンク

• ・出張経費自動計算アプリ「トリログ」プロダクトページ
• ・AIエージェントと業務自動化——「答えるAI」から「実行するAI」へ
• ・エージェントAIインフラ：YC W26の41%が構築する「実行するAI」基盤