ここでは、AIエージェントネイティブに備えた基幹システムの拡張について次の観点で説明します。
AIエージェントに適したプラットホーム
GUIは、人間がデータを正しく理解し、操作するためのインターフェースです。
AIエージェントがGUIを操作することは可能ですが、GUIは人間向けに最適化されており、必ずしもAIエージェントにとって扱いやすいとは限りません。
AIエージェントにとっては、データとその意味が明示的に構造化されたAPIのほうが、直接的かつ効率的に利用できます。
したがって、AIエージェントネイティブな利用を見据えるのであれば、AIエージェントが直接アクセス可能なAPIを備えておくことが望ましいと考えます。
このような構成を前提として、AIエージェントが自律的にデータへアクセスし、推論・連携できるプラットフォームをあらかじめ構築しておくことが重要です。
ユースケースベースAPIの重要性
基幹システムの多くは、
UIを司るプレゼンテーション層、
ビジネスロジックを司るアプリケーション層、
データアクセスを司るデータ層から構成される、
3階層アーキテクチャを採用しています。
この構成を前提とすると、基幹システムがAPIを提供する場合、アプリケーション層のAPIとデータ層のAPIの二種類を考えることができます。
データ層のAPIは、データベースに対するCRUD（Create／Read／Update／Delete）操作を中心としたAPIであるのに対し、アプリケーション層のAPIは、ビジネスロジックや業務ルールを含んだユースケースベースのAPIとなります。
これらのうち、AIエージェントに公開すべきAPIは、CRUDベースのAPIではなく、ユースケースベースのAPIです。
なぜなら、AIエージェントがCRUDベースのAPIを直接操作すると、本来アプリケーション層で担うべきビジネスロジックが迂回され、結果として、データの整合性が損なわれ、信頼できないデータが蓄積されるリスクがあるためです。
仮に、ビジネスロジックが完全に文書化され、AIが常に正確にそれを解釈し、例外ケースも網羅され、将来の変更にも即時に追従できるのであれば、CRUDベースのAPIのみを公開しても運用できる可能性はあります。
しかし、実際にはルールは常に変化し、例外も頻発し、さらに法規制や監査要件も存在します。そのような状況において、AIエージェントが常に正しく推論できることを前提とする設計は現実的ではありません。
定型的な処理は、AIエージェントよりも従来のアプリケーションが担う方が良いと考えられます。
全てのアプリケーションにAIが接続されたAIネイティブの世界では、ヒトは「GUIを操作する」存在ではなく、「意図を伝える」存在へと変わるのではないでしょうか。
基幹システムの拡張
それでは、AIエージェントネイティブに備えて基幹システムをどのように拡張すればよいでしょうか。
ここでは、
・APIを備えていない基幹システム
・CRUDベースのAPIしか備えていない基幹システム
を対象に考えます。
すると、大きく次の二つの戦略を考えることができます。
- 基幹システムに直接ユースケースベースのAPIを実装する
- ユースケースベースAPIを備える別システムを作り基幹システムのCRUDベースAPIをアクセスさせる
基幹システムに直接ユースケースベースのAPIを実装する場合について考えてみます。
すでにフロントエンドアプリがAPIを介して基幹システムと連携している場合、そのAPIはユースケースベースAPIである可能性が高く、これを外部に公開することで、比較的低コストにAIエージェント対応を行えると考えられます。
一方で、CRUDベースのAPIしか備えていない基幹システムに対して、改めてユースケースベースのAPIを実装しようとすると、アプリケーション層の大規模な改修が必要となり、多大な拡張コストが発生することが予想されます。
それに対して、ユースケースベースAPIを備えた別システムを構築し、そのシステムから基幹システムのCRUDベースAPIにアクセスさせる方式であれば、既存の基幹システムに手を加える必要がなく、比較的低コストで開発することが可能です。
以上を踏まえると、AIエージェントネイティブに備えるための方針は、基幹システムの状態に応じて、次のように整理できます。
| No. | 基幹システムの状態 | 条件 | 採用する方針 |
|---|---|---|---|
| 1 | APIを備えていない基幹システム | ― |
ユースケースベースAPIを備えた別システムを構築し、 基幹システムを包み込む方式を採用する。 |
| 2 | CRUDベースのAPIしか備えていない基幹システム |
① フロントエンドアプリがAPIを経由して 基幹システムと連携している場合 |
そのAPIがユースケースベースであれば、 当該APIを外部に公開する。 |
|
② フロントエンドアプリがAPIを経由して 基幹システムと連携していない場合 |
ユースケースベースAPIを備えた別システムを構築し、 基幹システムのCRUDベースAPIにアクセスさせる。 |
仮想マイクロサービス化
業務は、ジョブ（職務） と ビジネスプロセス の組み合わせによって構成されます。
ジョブは内部統制や事業戦略を考慮して分掌されます。
【参考】
ジョブの設計方法
一方、ビジネスプロセスは、各ジョブに紐づくタスクが連鎖することで構成されます。
次の図は、業務の仕組を構成する要素同士の関係を表したものです。
これを見ると次のことがわかります。
- 事業ドメインには、複数の活動領域がある。
- 活動領域には複数のビジネスプロセスがある。
- ビジネスプロセスには、ビジネスプロセスの本質的（不変的）な流れを表すアクティビティフローがある。
- アクティビティフローのアクティビティには、アクティビティの中身の流れを表すアクションフローがある。
- アクションフローのアクションを実行する主体がジョブである。
アクションは、ジョブのタスク（課業）に対応する。 - 事業ドメインには、価値を創る活動（Creation）、価値を届ける活動（Operation）、価値を伝える活動（Communication）というマネジメントサイクルから成るバリューチェーンがある
- マネジメントサイクルは、複数のビジネスプロセスから構成される。
このように考えると、ジョブ（職務）を一つの業務ドメイン と捉え、その業務を支援する単位としてマイクロサービスを導入することで、
ビジネスとITをスムーズに連動させることが可能になります。
また、このアプローチにより、企業に必要なシステム機能やデータをMECE（漏れなく、ダブりなく） 整理・導入することができます。
マイクロサービスは、それぞれが高い信頼性とセキュリティが担保されたデータを内包するため、それを疎結合に組み合わせてアプリケーションシステムを構築することで、環境変化に迅速に適応できる構造を実現します。
これにより、開発の生産性や保守性が向上するだけでなく、信頼性の高い分散型データ基盤を構築することが可能になります。
さらに、マイクロサービスにAIエージェントを組み込み、コアプロセスを再設計することで、環境の変化を自動的に察知し、自律的に最適な状態へと調整する、ホメオスタシスのような仕組みを実現することができます。
マイクロサービスが信頼できる定型的なビジネスロジックと、信頼できるデータを管理し、AIエージェントが、そのデータを活用してジョブ（職務）のタスクを遂行します。そして、マルチエージェントということで、AIエージェント同士が協力してビジネスプロセスのワークフローを継続的に廻します。
次の図は、自律分散型データ基盤のイメージ図です。
ここでは、ユースケースベースAPIを備えた別システムを構築し、基幹システムのCRUDベースAPIにアクセスさせる方法の一つとして仮想マイクロサービス化という方法を紹介します。
次の図は、通常のマイクロサービスのイメージ図です。
一方、次の図は、ユースケースベースAPIを備えたマイクロサービスを構築し、基幹システムのCRUDベースAPIにアクセスさせたイメージ図です。
この基幹システムのCRUDベースAPIにアクセスするユースケースベースAPIを備えたマイクロサービスを導入することを、ここでは、仮想マイクロサービス化といいます。
仮想マイクロサービスは、分散システムのトランザクション管理機能の一つであるSagaのオーケストレーターの役割を担います。
CRUDベースのAPIしか備えていない基幹システムで、フロントエンドアプリがAPIを経由して基幹システムと連携していない場合、基幹システムを仮想マイクロサービス化することをお勧めします。
これによって、既存の基幹システムをそのまま活かした上で、自律分散型データ基盤を構築することができます。
仮想マイクロサービス化の手順
それでは、どのように仮想マイクロサービス化を進めれば良いのでしょうか。
仮想マイクロサービス化は、次のて手順で進めます。
ジョブの定義
会社のジョブが定義されていない場合、定義します。
アプリケーションタイプの設計
次に、ジョブをベースにアプリケーションタイプを設計します。
アプリケーションタイプは、概念レベルの本質的な（製品や技術に左右されない）アプリケーションの型です。
アプリケーションタイプはジョブを支援する役割でジョブの単位に定義します。
次の図は、ジョブとアプリケーションタイプの関係を表したものです。
この図を見ると、ジョブとアプリケーションタイプが対応し、ジョブのタスクと、アプリケーションタイプのタスク（業務レベルのユースケース）が対応していることがわかります。
アプリケーションカテゴリの設計
続いて、アプリケーションタイプをベースにアプリケーションカテゴリを設計します。
アプリケーションカテゴリとは、アプリケーションタイプをアプリケーションの種類という観点で論理的に分類した単位のことです。
会社で××システムと呼んでいるものは、通常、アプリケーションカテゴリのレベルのものです。
次の図は、ビジネスストラクチャマトリクスにおけるアプリケーションの分類を示したものです。
アプリケーションの種類は次のようになります。
- SoR（System of Record）
トランザクション処理アプリケーション。
社内の業務活動によって発生する事実を記録するためのシステム。
ここでは、さらに、マスターデータを管理するシステム、参照データを管理するシステム、トランザクションデータを管理するシステムに分けて管理します。 - SoI（System of Insight）
分析アプリケーション。
主に様々な切り口でKPIを分析することで財務、顧客、業務、資産に関する洞察を得るためのシステム。 - SoE（System of Engagement）
変革アプリケーション。
顧客や従業員、パートナーにサービスを提供することで良好な顧客関係を構築するためのシステム。
アプリケーションの設計
次に、アプリケーションカテゴリをベースに、アプリケーションを設計します。
アプリケーションとはIT基盤にデプロイするアプリケーションの物理的な単位のことです。
ここでは、UI/UXを担うフロントエンドアプリケーションと、ビジネスロジックとデータ管理を担うバックエンドアプリケーションに分割します。
マイクロサービスは、バックエンドアプリケーションの一種になります。
現行アプリケーションの分析
次に、アプリケーションのどの部分を現行のアプリケーションが担っているか分析します。
アプリケーション戦略の立案
続いて、将来、どの部分を仮装マイクロサービス化するのか戦略を立案します。
モデルドリブン開発
どの部分を仮装マイクロサービス化するのか戦略が立案できたら、モデルドリブン開発で仮想マイクロサービス化を進めます。
ユースケースベースのAPIを定義するためには、以下に業務の観点でユースケースを抽出するかが重要になります。
モデルドリブン開発については、モデルドリブン開発で創るアプリケーションシステムを参照してください。
