AIエージェントとは
AIエージェントとは、与えられた目標を達成するために、自律的に環境を認識・分析し、最適な行動を選択し実行する人工知能のことです。
従来のAIは、与えられた単一タスクの自動化や分析をするだけでしたが、AIエージェントは「目標達成」に向けて自律的に複数のタスクを計画→実行→検証→改善します。
つまり、自律的にマネジメントサイクル（PDCA）を実行し最適な方法を見出し目標を達成するのです。
このAIエージェントですが、現在、ロボットや機械に組み込んで自律的に最適な行動を取らせる研究も非常に活発に進んでいます。
さて、社員一人ひとりがデータを利活用してマネジメントサイクル（PDCA）を遂行し、自律的に業務課題を解決することができる経営をデータドリブン経営といいますが、近い将来、人ではなくAIエージェントがデータドリブン経営をまわし、人はAIエージェントを調教する役割を担うという時代がくるかもしれません。
なぜ今マイクロサービスなのか
VUCAやビッグデータの文脈でデータマネジメントの重要性が叫ばれて久しいですが、AIエージェントの時代になると、企業にある業務データを、いかに人が有効活用するかだけでなく、いかにAIエージェントに有効活用させるかを考えなければなりません。
さて、AIエージェントは、API（Application Programming Interface）を介して外部システムのデータを活用します。
なので、AIエージェントにデータを有効活用させるためには、企業全体のAPIを漏れなくダブりなく整備して、OpenAPIでAPIをカタログ化しておくことが、会社にとって重要な課題になります。
※OpenAPIとは、「OpenAPI Specification（OAS）」の略称で、主にWebアプリケーションが利用するREST APIの仕様を記述するための標準フォーマットのことです。
しかし、多くの会社が、ビジネスの変化が加速し、ビジネスとITが密接化する中、全体の設計図もなく、必要に応じてシステムを導入してきた結果、
- 大規模で複雑なシステムがサイロのように乱立している
- 重複して整合していないデータが散在している
- 個別の業務やシステムは詳しいが全体を理解できる人や資料がない
というカオスで雁字搦めな状況に陥っています。
特に、開発コストが下がるという神話に騙されて、盲目的に業務パッケージを導入してきた会社は、データや機能がブラックボックス化され身動きがとれないという傾向が強いようです。
結果、多くの企業では、業務データや業務機能が散在、重複し、APIの整備がしにくい状況にあるのではないでしょうか。
企業の業務領域（業務ドメイン）を明確にし、業務ドメインごとにマイクロサービスを整備し、そこで、業務データや機能を一元管理できるようにすることによって、企業に散在する業務データや機能を漏れなくダブりなく統合することができます。
業務ドメインごとに分けられたマイクロサービスの各機能に対してAPIを設けることによって企業全体で漏れなくダブりなくAPIを整備することができるだけではなく、マイクロサービスごとに構造化された業務データを管理、統制することでデータクオリティを担保することもできます。
さらに、マイクロサービス本来の特徴であるモジュール性とデプロイの容易性という性質によって、企業全体のシステム全体の保守性と生産性を上げることができ、企業を、環境の変化に柔軟に適応できる体質、変化に強い構造にトランスフォームすることができるのです。
それでは、サイロのように乱立している大規模で複雑なモノリシックなシステムをどのようにマイクロサービスに移行すればよいのでしょうか。
基幹システムを段階的にマイクロサービス化する手順
ここでは、基幹システムなどモノリシックなシステムを段階的にモダナイズして、マイクロサービスへ移行する方法、ストラングラーアプリケーションパターンについて紹介します。
ストラングラーアプリケーションパターン（Strangler Application Pattern）とは、既存のシステム（特にレガシーシステム）を一度に全面リプレースするのではなく、機能単位で段階的にマイクロサービスへ移行していくソフトウェア開発戦略のことです。
ストラングラーアプリケーションパターンのストラングラーとは「絞め殺しのイチジク（Strangler Fig）」という植物に由来します。
新旧システムを共存させながら徐々に新しいシステムへ移行する手法を、イチジクが他の木に絡みつき、徐々に元の木を包み込み、最終的に置き換えてしまう様子になぞらえているのです。
具体的にみていきましょう。
例えば、SCM（サプライチェーンマネジメント）全体を一元管理するモノリシックな基幹システムがあったとします。
このSCMシステムの内部には、販売管理や生産管理など多くの業務機能が含まれています。
そこで、まず、SCMシステムの業務機能を、業務ドメイン単位に論理的に分類します。
次に、業務ドメイン単位に論理的に分類された業務機能ごとにAPIを整備します。
基幹システムがフロントエンドアプリケーションがAPIを介してバックエンドアプリケーションに接続する構成になっていない場合、フロントエンドアプリケーションがAPIを介してバックエンドアプリケーションに接続するようにします。
この段階で、論理的に分割されたAPIが整備されますが、マイクロサービス化するには、並行して各業務ドメイン単位にマイクロサービスを構築します。
次に、段階的にAPIの実装部分を従来の機能からマイクロサービスに置き換えていきます。
このプロセスを繰り返し、最後の機能が置き換わるまで実施します。
そして、すべてのSCM機能がマイクロサービスに置き換わった時点で移行が完了します。
以上、SCMシステムを例にしてマイクロサービス化の説明をしました。
これを企業全体のシステムに適用するにはどうすればいいでしょうか。
エンタープライズアーキテクチャの重要性
企業全体のシステムをマイクロサービス化するために重要になるのがエンタープライズアーキテクチャ（EA）です。
EAは企業全体の業務とシステムの設計図なので、マイクロサービスの単位である業務ドメインを次のように規定します。
- 事業ドメインの定義
まず、企業にある事業ドメインを、「誰に何の価値を提供するか」という事業パーパスの単位で分割します。 - 活動領域の定義
次に、企業の活動領域を考え、事業ドメイン固有の活動領域と、事業ドメイン共有の活動領域に分けます。
次の図は、不動産会社を事業ドメイン固有の活動領域と、事業ドメイン共有の活動領域に分けた例です。
※活動領域は、活動ドメイン、あるいは、サブジェクトエリアとも言われます。 - ジョブの設計
次に、各活動領域をベースに会社のジョブ（職務）を設計します。 - アプリケーションポートフォリオの設計
最後に、ジョブの単位に論理的なアプリケーションの単位、アプリケーションタイプを設定します。
ジョブは、内部統制による職務分掌や、同じスキルセット、ドメイン知識を持つ機能単位として考えられているので、ジョブ単位にトランザクション処理アプリケーションを分割することで、業務機能とアプリケーションを対応させることができます。
これは、結果的に、ソフトウェア設計原則の単一責任の原則「変更する理由が同じものは集める、変更する理由が違うものは分ける」に則ることになります。
そして、このアプリケーションタイプがマイクロサービスの単位になります。
なお、データアーキテクチャとして、アプリケーションタイプごとに設計された概念データモデルに基づいて、マイクロサービスが管理するデータベースが構築されます。
さて、このEAは、企業の設計データを創りますが、設計（デザイン）は人間の意思によって行われます。
近い将来、AIエージェントが人間の仕事を代行するようになると、人間の意思が全体のアーキテクチャを決め、それを実現するのがAIエージェントという構図になるのではないでしょうか。
この図は、人間の意思を表すEAによって設計データが創られ、それに基づいてマイクロサービスが構築される。
設計データに従ってAIエージェントがマイクロサービスを活用してタスクを遂行して実行データを作り、それが設計や実行に活用されるというストーリーを表しています。
さらに、これからますます進む「個の時代」を考えると、一人ひとりが自分の得意分野で会社（myCompany）を創り、その会社の設計データや実行データはブロックチェーン上のパブリックドメインとして透明かつ公平に管理される世界がくるかもしれません。
