マイクロサービスの原則を参照軸にする

マイクロサービスについては「サービスを小さく分割する」という技術的な説明が広まっています。しかしこの定義は表面だけを捉えており、AI エージェントとの共存を論じるには不十分です。

Fowler と Lewis（2014）が提唱したマイクロサービスの定義には 9 つの特性があります。それは技術的な分割手法ではなく、組織とアーキテクチャの両方にわたる設計思想です。この探索では特に次の 4 つを参照軸として使います。

Organized around Business Capabilities（ビジネス機能による組織化）。サービスの境界はビジネスの機能単位で引きます。チームはその機能を UI からデータまで end-to-end で所有し、運用の責任を持ちます。「注文」「メニュー」「配送」がそれぞれ独立したチームとサービスを持つのは、組織の責務の写像です。

Products not Projects（プロジェクトではなくプロダクト）。作ったら終わりではなく、チームはサービスを継続的に運用します。“You build it, you run it.” この原則は、system prompt や skill ドキュメントの管理責任にも直接つながります。

Smart Endpoints and Dumb Pipes（スマートエンドポイント、ダムパイプ）。ビジネスロジックはサービス自身（エンドポイント）が持ちます。サービス間の通信路（パイプ）は単純な HTTP にとどめ、そこにロジックを置きません。AI エージェントを加えたとき、この原則との関係が最も鋭い問いになります。後述します。

Decentralized Governance / Decentralized Data Management（分散ガバナンス・分散データ管理）。各チームが自サービスの技術選択とデータを独自に管理します。中央集権的な調整を最小化することで、独立したデプロイと進化が可能になります。

この 4 つの特性を保ったまま AI エージェントを組み込めるか。これがこの探索の中心的な問いです。

単一巨大エージェントが抱える問題

マイクロサービスがモノリスの中央集権性から逃れようとしたのと同じ理由で、AI エージェントも単一の巨大なものであることの危険を避ける必要があります。

単一の巨大エージェントに全機能を集約すれば、システムは「自然言語の入口を持つモノリス」になります。これが引き起こす問題を、マイクロサービスの教訓と照らし合わせて整理します。

1. System Prompt の責務肥大化による業務ルールの衝突不透明化

prompt の責務が肥大すると、複数のビジネスドメインの判断基準・優先順位・例外処理が一つのテキストに混在します。「注文の推薦ロジック」「配送ルール」「課金基準」が同じ system prompt で競合するとき、どちらが優先されるべきかが不明瞭になります。変更の影響範囲も追いにくくなり、予期しない副作用が生まれやすくなります。これは、モノリシックなコードベースで責務の境界が曖昧になるのと本質的に同じ問題です。

2. Tool 権限の境界消失と「何でもできるエージェント」の誕生

単一エージェントが全サービスの全 API へアクセス権を持つと、tool 定義に明確な境界がなくなります。意図しない操作の組み合わせが可能になり、データ整合性を保つ責任が曖昧になります。たとえば「注文の金額を確定してから配送料を計算する」という順序が重要な場合でも、エージェントが自由に両方の tool を呼び出せると、異なる順序で実行してしまう可能性があります。これは、マイクロサービスがサービス間の責務境界を明確にしようとしたのとは逆の方向です。

3. Team Ownership の崩壊と保守責任の曖昧化

複数ドメインを担当する複数チームがいるとき、誰が「単一エージェント」を保守するのかが不透明になります。注文チームが prompt 変更を加えて、配送チームに予期しない影響を与える。配送チームが tool 定義を追加して、注文チームの意図と衝突する。こうした変更が次々と加わると、コード所有権が不明確なモノリシックなシステムと同じ状況になります。「Products not Projects」の理想は失われ、変更の責任者が曖昧になります。

4. デプロイメント爆発による変更の局所化不可能性

単一エージェントの prompt・tool・skill に変更を加えるたびに、全エージェントがリスタートします。ある機能の小さな調整が、全システムのエージェント行動に波及する可能性があります。これは、モノリシックなアプリケーションのある部分を変更するたびに全体をリデプロイするのと同じ問題です。変更の局所化ができず、小さな改善が全体への影響を恐れた結果、進化が遅くなります。

5. Context 汚染による暗黙的な状態共有

単一エージェント内で複数ドメインの会話履歴が混在すると、前のドメインの会話が後のドメインの判断を不意に影響する可能性があります。これは、マイクロサービスが「分散データ管理」で避けようとした「暗黙的な共有状態」です。形を変えて、エージェントの会話コンテキストの中で再発します。結果として、システムの動作が状態依存的で再現困難になり、デバッグと保守が難しくなります。

これら 5 つの問題は、マイクロサービスがモノリスから学んだ教訓と対応しています。マイクロサービスが「疎結合」「独立進化」「責務の明確化」を達成しようとしたのは、モノリスに集約することの苦しさを経験したからです。AI エージェント導入でその同じ苦しさを繰り返さないためには、エージェントもまた、責務の単位で分割し、境界を明確にする必要があります。

自然言語フロントドアという設計原則

私が今考えている設計の中心は「AI エージェントをサービスの自然言語フロントドアとして置く」という一文に集約できます。この設計は Fowler/Lewis の 4 特性を保つことを前提として組み立てています。

具体的には次の 5 つの原則として整理しています。

まず、チームは機能（capability）を所有する（Organized around Business Capabilities）。サービスの境界は引き続きチームの責務に沿って引きます。AI を導入してもこの構造は変えません。

次に、サービスは機能を API として公開し続ける（Smart Endpoints and Dumb Pipes）。REST や gRPC といった機械可読な API は廃止しません。これがシステム間連携や状態変更の正本契約であり続けます。

そして、AI エージェントをその上に自然言語インターフェースとして追加する。ここで重要なのは「追加」です。エージェントは API の代わりではなく、API の手前に置く会話インターフェースです。自然言語入力を解釈し、サービスの capability へ橋渡しします。既存の API 契約は変わりません。

エージェントは API の代わりではなく、API の手前に追加する層として位置づけます。

graph TD
  U["ユーザー（自然言語）"] --> A["エージェント（自然言語フロントドア）"]
  SP["system prompt / skill"] -. 制約・業務知識 .-> A
  A --> API["サービス API（REST）"]
  API --> BL["業務ロジック / 決定論的コード"]
  BL --> D[("データ")]

system prompt はエンジニアが管理する（Products not Projects / Decentralized Governance）。役割・制約・ツール利用方針・エラー時の振る舞いを system prompt に書きます。これはソースコードと同じ扱いで、レビューとバージョン管理の対象です。

skill は業務知識の公開面として、業務側がメンテできる形で分離する（Products not Projects）。商品の特徴・調理時間の目安・配達エリアの注意事項といった業務用語や判断の観点は、skill ドキュメントに書きます。エンジニアでなくてもメンテナンスできる形にしておくことで、業務知識の陳腐化を防ぎます。

そして最も重要なポイントがあります。金額計算・在庫確定・課金・認可のような「正解が必要な処理」はコードに残す（Smart Endpoints and Dumb Pipes）。LLM は曖昧さの解釈や文脈の補完が得意ですが、べき等性や整合性の保証は苦手です。ここを LLM に任せると、再現性のない障害と監査不能な状態が生まれます。この分担を守ることが、エージェントを業務システムに組み込む上での最大の安全弁になります。

要点は、agent-first でも API-less にはしない。知識駆動でも rule-in-prompt にはしないということです。

5 つの設計方針と Fowler/Lewis 4 特性の対応。各方針はいずれかの特性に根拠を持ちます。

graph LR
  subgraph 設計方針
    P1["capability を所有する"]
    P2["API を公開し続ける"]
    P3["NL IF として追加する"]
    P4["system prompt を管理する"]
    P5["skill を分離する"]
    P6["正解はコードに残す"]
  end
  subgraph FL["Fowler / Lewis"]
    FL1["Organized around Business Capabilities"]
    FL2["Smart Endpoints, Dumb Pipes"]
    FL3["Products not Projects"]
    FL4["Decentralized Governance"]
  end
  P1 --> FL1
  P2 --> FL2
  P3 --> FL1
  P3 --> FL2
  P4 --> FL3
  P4 --> FL4
  P5 --> FL3
  P6 --> FL2

4 特性はどこまで前進したか

ここまでの記述は「矛盾しないか」を中心に説明してきました。後述するデモシステムの観察範囲に限れば、もう一段踏み込んだ見方もできます。AI エージェントの導入は、4 特性と両立するだけでなく、特性が意図していた理想をより実装しやすい形に前進させる面があります。

Organized around Business Capabilities 従来は、機能境界がコードと API の境界として存在していても、ユーザー入力はその境界に直接届きませんでした。注文者は API 形式を意識せずに「おすすめを知りたい」「これを頼みたい」と話します。注文受付エージェントが意図を型付きの payload に正規化することで、人間の意図を機能境界に接続できるようになりました。ここでは、アーキテクチャの境界と利用者の認知境界が近づいています。

Smart Endpoints and Dumb Pipes 従来の「スマートさ」は、主に型付けされた入力を受け取った後のコードロジックにありました。自然言語フロントドアは、そのスマートさを入力解釈まで拡張します。重要なのは、拡張先がパイプではなくエンドポイント内部である点です。サービス間通信は引き続き HTTP 契約のままで、賢さだけをエンドポイント側に追加しています。

Products not Projects ワンチーム運用の理想は以前からありましたが、業務知識の反映経路は多くの場合、エンジニア経由のコード変更に集中していました。skill document と activationHint を分離すると、業務担当者が運用フェーズで直接更新できる面が生まれます。構造は同じワンチームのまま、関与の深さが変わる点が実務上の差分です。

Decentralized Governance / Decentralized Data Management 分散ガバナンスの理想は「独立した進化」ですが、実際は呼び出し先の固定名が変更連鎖を生みがちです。capability-based discovery では、呼び出し元が相手サービス名を前提にせず、能力記述で collaborator を解決します。これにより、サービス差し替え時に呼び出し元の変更を減らせるため、独立デプロイの理想に近づきます。

エージェントは「スマートエンドポイント」を破壊しないか

ここで「Smart Endpoints and Dumb Pipes」との関係を整理します。エージェントを追加することで、サービスのエンドポイントはより「スマート」になります。これはこの原則の破壊ではなく、エンドポイントの知性の拡張です。パイプ（サービス間の HTTP 通信）は依然シンプルなままで、ロジックはサービスの内側に閉じています。

複数サービスが同じ LLM バックエンド（例: Bedrock / Claude）を共有しても、構造は複数サービスで Postgres を共有する場合に近いです。各サービスは独自の system prompt・tool 定義・skill ドキュメントで LLM を呼び出し、推論コンテキストはサービス境界の中に閉じます。LLM は共有パイプではなく、共通インフラです。

エージェントを置かない判断の基準

ここまで述べてきた設計原則は、「どこにエージェントを置くか」を決めるものです。同じくらい重要なのが「どこに置かないか」という判断です。

たとえば課金・決済を担うサービスにはエージェントを置かない、という判断があります。課金処理・支払い確定・監査ログは決定論的なコード実行に留めます。この判断は「AI を避ける」ことではなく、「正解が必要な処理」の定義です。

置かない判断の基準は次の 3 点に集約できます。

1. 出力の正確性が要件になる処理 金額計算・課金・認可・在庫確定といった処理では、システムのどの部分でも同じ入力に対して同じ結果を返さなければなりません。LLM は確率的に出力を生成するため、この要件を満たしません。小数点の丸めや課金規則のような「ビジネスルール」が明確に定義されている処理は、LLM の判断より前段の正確性の枠で処理する方が安全です。

2. べき等性・再実行安全性が必要な処理 ネットワーク障害によるタイムアウト後の再試行、バッチ処理中の中断復帰、障害復旧時のリプレイなど、システムが同じ操作を複数回実行する場面があります。LLM の出力は実行のたびに変わる可能性があり、再実行時に前回と異なる結果を返すかもしれません。べき等性が要件の処理は、コード側で状態管理を完結させる方が確実です。

3. 監査可能性・説明責任が必要な処理 支払い処理・ユーザーデータの削除・権限変更といった操作は、後から「誰が・何を・なぜ・どう決めたか」を調査できなければなりません。LLM は推論プロセスの中間ステップを明示しないため、説明責任が必要な決定を LLM に完全に委ねることはできません。

これら 3 つの基準に当てはまる処理は、エージェント導入のスコープから明示的に除外するという判断が、システムの信頼性を守る鍵になります。

実証へ

設計仮説は動くコードで確かめられなければ意味がありません。しかしここで示したいのは「この設計で動くシステムが作れる」という事実だけではありません。

この探索で示したいのは、5 つの設計原則が互いに矛盾せず、Fowler/Lewis の 4 特性とも整合した形で実システムとして成立することです。

原則は個別には妥当でも、組み合わせるとぶつかることがあります。たとえば「チームが capability を所有する」ことと「複数サービスが同じ LLM バックエンドを使う」ことは両立できるか。「正解が必要な処理はコードに残す」という境界はどこに引くべきか。「API を公開し続ける」という原則は、エージェント導入後も形だけにならないか。こうした両立が難しいポイントに実装で答えられているかが、仮説を判断する基準です。

この検証のために、Java / Spring 向けのエージェント実行基盤 Arachne と、10 のマイクロサービスで構成されたフードデリバリーのデモシステム（food-delivery-demo）を実装しました。各サービスの設計判断は、どの原則のどの「両立が難しいポイント」にどう答えるか、という視点で読めます。

各原則とデモの対応関係と実際の観察記録は Demo と Observations で確認できます。サブの Essay では各断面をより深く掘り下げています。

探索を通じて得られた評決は Conclusions にまとめています。