ここでは、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エージェントネイティブに備えて基幹システムをどのように拡張すればよいでしょうか。
ここでは、
・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にアクセスさせる。 |
仮想マイクロサービス化
業務は、ジョブ（職務） と ビジネスプロセス の組み合わせによって構成されます。
ジョブは内部統制や事業戦略を考慮して分掌されます。
一方、ビジネスプロセスは、各ジョブに紐づくタスクが連鎖することで構成されます。
このように考えると、ジョブ（職務）を一つの業務ドメイン と捉え、その業務を支援する単位としてマイクロサービスを導入することで、
ビジネスとITをスムーズに連動させることが可能になります。
また、このアプローチにより、企業に必要なシステム機能やデータをMECE（漏れなく、ダブりなく） 整理・導入することができます。
マイクロサービスは、それぞれが高い信頼性とセキュリティが担保されたデータを内包するため、それを疎結合に組み合わせてアプリケーションシステムを構築することで、環境変化に迅速に適応できる構造を実現します。
これにより、開発の生産性や保守性が向上するだけでなく、信頼性の高い分散型データ基盤を構築することが可能になります。
さらに、マイクロサービスにAIエージェントを組み込み、コアプロセスを再設計することで、環境の変化を自動的に察知し、自律的に最適な状態へと調整する、ホメオスタシスのような仕組みを実現することができます。
次の図は、自律分散型データ基盤のイメージ図です。
ここでは、ユースケースベースAPIを備えた別システムを構築し、基幹システムのCRUDベースAPIにアクセスさせる方法の一つとして仮想マイクロサービス化という方法を紹介します。
次の図は、通常のマイクロサービスのイメージ図です。
一方、次の図は、ユースケースベースAPIを備えたマイクロサービスを構築し、基幹システムのCRUDベースAPIにアクセスさせたイメージ図です。
この基幹システムのCRUDベースAPIにアクセスするユースケースベースAPIを備えたマイクロサービスを導入することを、ここでは、仮想マイクロサービス化といいます。
CRUDベースのAPIしか備えていない基幹システムで、フロントエンドアプリがAPIを経由して基幹システムと連携していない場合、基幹システムを仮想マイクロサービス化することをお勧めします。
これによって、既存の基幹システムをそのまま活かした上で、自律分散型データ基盤を構築することができます。
仮想マイクロサービス化の手順
それでは、どのように仮想マイクロサービス化を進めれば良いのでしょうか。
仮想マイクロサービス化は、次のて手順で進めます。
ジョブの定義
会社のジョブが定義されていない場合、定義します。
アプリケーションタイプの設計
次に、ジョブをベースにアプリケーションタイプを設計します。
アプリケーションタイプは、概念レベルの本質的な（製品や技術に左右されない）アプリケーションの型です。
アプリケーションタイプはジョブを支援する役割でジョブの単位に定義します。
次の図は、ジョブとアプリケーションタイプの関係を表したものです。
この図を見ると、ジョブとアプリケーションタイプが対応し、ジョブのタスクと、アプリケーションタイプのタスク（業務レベルのユースケース）が対応していることがわかります。
アプリケーションカテゴリの設計
続いて、アプリケーションタイプをベースにアプリケーションカテゴリを設計します。
アプリケーションカテゴリとは、アプリケーションタイプをアプリケーションの種類という観点で論理的に分類した単位のことです。
会社で××システムと呼んでいるものは、通常、アプリケーションカテゴリのレベルのものです。
次の図は、ビジネスストラクチャマトリクスにおけるアプリケーションの分類を示したものです。
アプリケーションの種類は次のようになります。
- SoR（System of Record）
トランザクション処理アプリケーション。
社内の業務活動によって発生する事実を記録するためのシステム。
ここでは、さらに、マスターデータを管理するシステム、参照データを管理するシステム、トランザクションデータを管理するシステムに分けて管理します。 - SoI（System of Insight）
分析アプリケーション。
主に様々な切り口でKPIを分析することで財務、顧客、業務、資産に関する洞察を得るためのシステム。 - SoE（System of Engagement）
変革アプリケーション。
顧客や従業員、パートナーにサービスを提供することで良好な顧客関係を構築するためのシステム。
アプリケーションの設計
次に、アプリケーションカテゴリをベースに、アプリケーションを設計します。
アプリケーションとはIT基盤にデプロイするアプリケーションの物理的な単位のことです。
ここでは、UI/UXを担うフロントエンドアプリケーションと、ビジネスロジックとデータ管理を担うバックエンドアプリケーションに分割します。
マイクロサービスは、バックエンドアプリケーションの一種になります。
現行アプリケーションの分析
次に、アプリケーションのどの部分を現行のアプリケーションが担っているか分析します。
アプリケーション戦略の立案
続いて、将来、どの部分を仮装マイクロサービス化するのか戦略を立案します。
モデルドリブン開発
どの部分を仮装マイクロサービス化するのか戦略が立案できたら、モデルドリブン開発で仮想マイクロサービス化を進めます。
ユースケースベースのAPIを定義するためには、以下に業務の観点でユースケースを抽出するかが重要になります。
モデルドリブン開発については、モデルドリブン開発で創るアプリケーションシステムを参照してください。
