はじめに
業務システムを作っていると、「この画面を最初から固定で作り込む必要があるのだろうか」と考えることがあります。
たとえば、先月の売上を見たい利用者のために、期間選択、集計条件、表、グラフを備えた画面を用意します。後から店舗別、前年同月比、商品別といった要望が増えれば、画面とAPIを改修します。
AIが利用者の目的を理解し、APIやMCP経由で公開されたTool・Resourceから必要な情報を取得できるなら、その場で表、グラフ、要約を組み立てて見せられる場面もあります。
この記事では、UIが不要になるという話ではなく、固定UIを先回りして大量に作る前提がどこまで変わるのかを考えます。あわせて、AIが任意のデータへ触れるのではなく、どのデータと操作を公開するかをシステム側で決める必要がある理由を整理します。
固定UIは将来の操作を先回りしている
これまでUIが必要だった理由は明確です。利用者はデータベースへ直接SQLを実行せず、APIの仕様も知りません。JSONを受け取っても、そのままでは業務に使いにくいものです。
そのため、サービス側が操作方法を画面として定義してきました。
DB
↓
API
↓
フロントエンド
↓
UI
↓
利用者
業務システムには、一覧、詳細、検索、登録、編集、集計、ダッシュボード、CSV出力といった画面が増えていきます。これは、利用者が将来使いそうな操作を予測し、画面として固定している状態でもあります。
固定UIには利点があります。利用者は決まった場所を開けばよく、入力項目や確認手順も予測できます。一方で、予測していなかった条件や表示方法が必要になると、画面の追加や改修が必要です。
AIが入っても、任意のデータを触らせてよいわけではない
AIが利用者とシステムの間に入ると、利用者が画面やAPI仕様を直接理解しなくても、目的を伝えられます。
利用者
↓
AI
↓
API / MCP Tool
↓
業務ロジック・データ
ただし、ここで重要なのは、AIが自然言語から任意のSQLを組み立ててDBへ実行することではありません。
たとえば、利用者が次のように依頼したとします。
登録から90日以上経過していて、
最終ログインが30日以上前のユーザーを出して
AIが自由にusersテーブルへ問い合わせる設計は、閲覧してよい項目、検索できる範囲、負荷の大きい検索、テナント境界を守りにくくなります。読み取りだけであっても、個人情報や内部状態を返す可能性があります。
代わりに、システム側が許可する条件と結果を定義します。
search_customers({
registeredBefore,
lastLoginBefore,
status,
})
この操作に、認可、検索できる項目、返却する項目、件数上限、監査ログを集約できます。AIは任意のDB操作を行うのではなく、業務上意味のある操作を呼びます。
MCPを使う場合も同じです。MCPはデータそのものではなく、AIアプリケーションが外部システムのToolやResourceを利用するための接続方法です。Toolの粒度や認可を設計しなければ、接続方式をMCPに変えても安全な境界にはなりません。
重要なのは画面より先に公開する操作とデータを決めること
AI時代のサービスは、画面を先に考えるより、何を安全に取得・変更できるかを先に定義する方が扱いやすくなる場面があります。
サービス
=
データ + 操作 + 権限
ここでいう操作は、低い粒度のCRUDだけではありません。利用者やAIが実行してよい仕事の単位です。
search_customers
get_customer
get_transactions
update_customer_status
create_report
操作ごとに、誰が呼べるか、どの条件で検索・変更できるか、何を返してよいかを決めます。変更前の確認項目と実行内容の記録先も、操作と同じ境界で定義します。
この構造では、UIはサービスそのものではなく、許可した操作とデータを表現する方法の一つになります。固定UI、AIが組み立てるUI、CLI、外部連携が同じ制約を共有できます。
探索や分析では生成UIが扱いやすい
売上管理を例にします。従来なら、店舗別売上、前年同月比較、売上推移、CSV出力といった画面を用意するかもしれません。
利用者が「今月の売上を店舗別に見せて」と依頼したとき、AIは許可された集計Toolから結果を取得し、まず表を表示できます。
店舗 売上
東京 1200万円
大阪 850万円
福岡 620万円
続けて「前年同月比も追加して」「グラフにして」と依頼されれば、同じ結果を比較表やグラフへ変換できます。この流れでは、利用者が必要とする表示を事前にすべて画面として用意しなくても済みます。
特に、条件を変えながら探索する作業では、生成UIが役立ちます。固定の検索フォームに最終ログイン日がなければ、従来は画面改修かCSV出力が必要でした。許可された検索条件として公開されていれば、AIは自然言語の依頼を検索条件へ変換し、結果を返せます。
確定操作と定型操作には固定UIが向く
生成UIが常に適しているわけではありません。操作の結果を確定する場面や、毎日繰り返す操作では、予測可能な固定UIの方が安全で速いことがあります。
振込を例にすると、毎回構成が変わる画面より、振込先、金額、手数料、実行後残高、確定ボタンが決まった位置にある方が確認しやすくなります。利用者は何を確認し、どの操作が実行されるかを事前に理解できます。
操作ごとの目安は次のとおりです。
| 操作 | 向いているUI | 理由 |
|---|---|---|
| 先月の売上が落ちた原因を調べる | AIと生成UI | 仮説に応じて比較軸や表示を変えるため |
| データを比較する | AIと生成UI | 表、グラフ、要約を目的に応じて選べるため |
| 条件を変えながら探索する | AIと生成UI | 事前にすべての検索条件を画面化しなくてよいため |
| 保存する | 固定UI | 操作の位置と結果が予測できるため |
| 再生・停止する | 固定UI | 高頻度で素早く操作するため |
| 振込を確定する | 固定UI | 確認項目と実行結果を固定する必要があるため |
| 毎日同じ定型入力をする | 固定UI | 操作を覚えた利用者の方が速いため |
画像編集、CAD、地図、動画編集のように、連続した視覚操作や空間的な操作が中心になる領域でも、固定UIの価値は残ります。AIが補助しても、直接操作するための部品が不要になるわけではありません。
画面単位の開発からUIプリミティブの開発へ
一つの画面を追加するだけでも、要件定義、画面設計、UI実装、バリデーション、API連携、権限制御、テスト、アクセシビリティ対応、保守が必要です。列を一つ追加したい、条件を一つ増やしたいという要望でも、複数の層に変更が広がります。
単純な参照画面なら、許可した操作から結果を取得し、AIが表やグラフとして組み立てる方が、画面追加より小さい変更で済む可能性があります。
ただし、生成UIを成立させるためにもフロントエンドの仕事は残ります。表、グラフ、フォーム、確認ダイアログ、エラー表示といったUIプリミティブを作り、AIが安全な範囲で組み合わせられるようにする必要があります。
個別画面を大量に作る仕事の一部は、AIが組み立てるUIの部品、表示ルール、アクセシビリティ、操作の確認方法を整える仕事へ移るかもしれません。
まず固定UIを減らすのではなく、境界を整える
既存システムの固定UIをすぐに置き換える必要はありません。利用者が毎日使う安定した画面を残しながら、探索、集計、レポートのように要望が増えやすい領域から生成UIを試す方が現実的です。
最初に確認したいのは、次の順番です。
- 必要なデータと操作を、APIやApplication Serviceとして安全に公開できるか
- AIに公開するToolの入力、出力、認可、監査を業務上の単位で定義できるか
- 表、グラフ、フォームなどのUIプリミティブを再利用できるか
- 生成UIより固定UIの方が安全・高速・分かりやすい操作はどれか
この順番なら、AI導入のためにすべての画面を作り直さずに済みます。既存の固定UIも、許可した操作とデータを利用する経路の一つとして徐々に整理できます。
まとめ
AI時代に減る可能性があるのはUIそのものではありません。将来の操作を予測して、大量の固定画面を先回りして作ることです。
探索や分析では、AIが許可された操作から情報を取得し、目的に合わせて表、グラフ、要約を組み立てる方が扱いやすい場面があります。一方で、確定操作、高頻度操作、視覚的な直接操作では、固定UIが引き続き重要です。
画面を作る前に、どのデータと操作を誰に公開するのかを決めます。その境界が整っていれば、固定UI、生成UI、CLI、外部連携を同じサービスの表現として増やしていけます。