Conclusions
観察で仮説を裏づけられたか
このページでは、Observation 記録を根拠に仮説がどこまで成り立つかを示します。証拠は各 Observation ページで確認できます。
検証範囲（この結論が有効な範囲）
この結論は、food-delivery-demo の Observation 記録（コード断片・API 仕様・実行記録）を根拠にしています。ここで確認していない環境・期間・運用条件には、そのまま当てはめません。重要な限定：この評決は、設計者自身が仮説に沿って設計・実装した demo への適用記録であり、独立した第三者による検証や、既存システムへの後付け適用を確認したものではありません。
要約（先に全体像を読みたい方向け）
- order-service と menu-service は、同じ LLM バックエンドを使っていても、各サービスが独立した prompt と tool で動いていた。境界は HTTP 契約で保たれていた。
- REST API は残り、x-ai-prompt-contract によってエージェント向けの契約も API 仕様として確認できた。
- payment-service は決定論的な実装に戻すことで起動が安定し、「AI を使わない」原則の実例になった。
- system prompt と skill は、コードやドキュメントとしてバージョン管理でき、変更の責任範囲を分けられた。
- capability-based discovery により、呼び先を固定しなくても、利用可能なサービスの変化に追従できた。
評決
このサイトで検証した範囲では、5 つの設計原則は両立でき、Fowler/Lewis の 4 特性とも矛盾しなかった。
根拠は food-delivery-demo の Observation 記録（obs-01〜obs-08）。各原則について、後から再確認できる振る舞いを示した。未観測の環境や条件は、この結論の対象外とする。
観察から見えてきたのは、整合性の確認にとどまりません。自然言語フロントドアは機能境界と利用者の意図の接続を強め、skill document はワンチーム内で業務側が直接関与できる運用深度を広げ、capability-based discovery は名指し依存を弱めました。これらは、マイクロサービスが掲げていた理想を、AI エージェント導入によってより実装可能な形へ前進させる方向を示しています。
原則評価サマリー
6 原則すべてについて、Observation 記録で仮説を支持できる振る舞いを確認しました。詳細は下の各原則の説明を参照してください。
成立 Products not Projects
system prompt はエンジニアが管理するシステム制約として書く
Obs-04 で証拠を見る →
成立 Products not Projects / Decentralized Governance
skill は業務知識の公開面として分離する
Obs-05 で証拠を見る →
成立 Decentralized Governance
サービス間の collaborator 解決は capability ベースで動的に行う
Obs-06 で証拠を見る →
原則ごとの説明
Smart Endpoints and Dumb Pipes
エージェントは自然言語フロントドアとして追加する 成立
観察の要約：order-intake-agent は自然言語入力を 4 つの意図（DIRECT_ITEM / RECOMMENDATION / REORDER / REFINEMENT）に整理し、menu-service に渡す groundingContext を型で定義した。menu-service は explicitItemIds と additionalItemIds を structured output で分けて返した。DIRECT_ITEM / RECOMMENDATION の経路でも、POST /internal/menu/suggest の API 契約は変わらなかった。
説明：この結果は仮説を支持する。自然言語の解釈は order-intake-agent が担当し、結果は HTTP ペイロードの追加フィールドとして既存 API に渡された。エンドポイントを変えずにエージェントを追加できており、「エンドポイントを賢くしつつ、パイプは変えない」設計が成り立っている。
証拠ページ（Obs-01）を見る →
Smart Endpoints and Dumb Pipes
従来の API は機械間連携の正本契約として残す 成立
観察の要約：OrderController の POST /suggest と MenuController の POST /internal/menu/suggest には x-ai-prompt-contract 拡張があり、エージェントが期待する入力構造・任意入力・サービスの振る舞いを OpenAPI 上で確認できた。
説明：この結果は仮説を支持する。エージェントを追加しても REST API は残り、API 自体がエージェント向け契約の公開面として機能した。x-ai-prompt-contract により、エージェントの期待値を API の外部仕様として管理できる。つまり、従来の API が正本契約として維持されていることを確認できた。
証拠ページ（Obs-02）を見る →
Smart Endpoints and Dumb Pipes
金額計算・課金・認可は決定論的コードで処理する 成立
観察の要約：PaymentApplicationService には AgentFactory も LLM 呼び出しもなく、支払い金額は RoundingMode.HALF_UP で端数処理し、承認 ID は UUID.randomUUID() で生成している。エージェントを外すと、ArachneAutoConfiguration が起動時に出していたプロバイダー未設定例外も消えた。
説明：この結果は仮説を支持し、原則が「AI を使わない」方向にも効くことを示した。もともと payment-service では起動時例外が出ていたが、agent を外すと例外が消えて安定した。つまり「正確性が必要な処理はコードに残す」という原則は、AI を追加するときだけでなく、AI を外す判断にも適用できる。
証拠ページ（Obs-03）を見る →
Products not Projects
system prompt はエンジニアが管理するシステム制約として書く 成立
観察の要約：order-intake-agent の system prompt は ArachneOrderIntentPlanner の private メソッドに Java 文字列として実装されており、「やること / やってはいけないこと」を明示している。言語設定は Locale.getDefault() ではなく、HTTP リクエストの locale を resolveResponseLanguage(locale) で解決して注入している。
説明：この結果は仮説を支持する。system prompt がコードにあるので、変更は git diff に残り、いつ・誰が・なぜ変えたかをレビューできる。「やってはいけないこと」の定義も、システム制約として管理できる。つまり、system prompt の変更を通常のリリース工程に載せられる。
証拠ページ（Obs-04）を見る →
Products not Projects / Decentralized Governance
skill は業務知識の公開面として分離する 成立
観察の要約：family-order-guide/SKILL.md の YAML フロントマターには activationHint があり、MenuServiceConfiguration がそれを読み込んで skillActivationHints Bean に変換し、MenuApplicationService が system prompt のスキル有効化セクションに注入する。発動条件の自然言語は SKILL.md が持ち、コード側はスキル名の配列を持つ。
説明：この結果は仮説を支持する。activationHint は SKILL.md を単一の情報源にしており、SKILL.md を更新してデプロイすれば、コードを変えずにエージェントの発動条件を変えられる。これは業務知識と実装変更サイクルを分離する設計であり、業務ルールの所有権を業務側に寄せられる。
証拠ページ（Obs-05）を見る →
Decentralized Governance
サービス間の collaborator 解決は capability ベースで動的に行う 成立
観察の要約：order-service の application.yml には「menu-service」という固定名はなく、「メニュー提案 在庫付き提案 注文候補」という capability クエリだけがある。RegistryServiceEndpointResolver は POST /registry/discover を呼び、稼働中サービスの endpoint を動的に取得する。hermes-adapter 停止中に配送ステップを実行すると、delivery-agent は idaten-adapter のみを推奨した。
説明：この結果は仮説を支持する。order-service は menu-service の固定名を知らなくても、capability クエリで対象サービスを見つけられた。hermes-adapter 停止時も delivery-service のコード変更は不要で、推奨内容と理由だけが変わった。つまり、サービス同士が直接依存せず、registry を介した能力記述で協調できる。
証拠ページ（Obs-06）を見る →
最も重要だった両立が難しいポイントと対応
問い：複数サービスが同じ LLM バックエンドを共有すると、LLM がパイプになるのか
order-service と menu-service の実行履歴を見ると、両者はそれぞれ独立した system prompt と tool 定義で LLM を呼び出している。そのため、order-service 側の結果や内部状態が menu-service 側に自動で流れ込むことはない。サービス間で渡るのは、HTTP リクエストとして明示的に送ったデータだけである。ここでは order-intake-agent が作った groundingContext が payload として menu-service に渡され、menu-service はそれを自分の prompt と tool で処理する。つまり、LLM はサービス間の共有パイプではなく、各サービス内部で使う処理コンポーネントである。
Obs-07 を見る →
問い：payment-service にエージェントを置かない判断は原則の逃げか
これは逃げではなく、原則の実践である。観察 3（payment-service のエージェント不在）が示すように、agent を外すと起動時例外が消え、安定性が上がった。「正確性が必要な処理はコードに残す」という原則は、AI を追加するときだけでなく、AI を使わない判断にも適用される。
Obs-03 を見る →
問い：capability-based discovery は Decentralized Governance を維持するか、新たな中央集権点を生み出すか
GET /registry/services（一覧確認用）と POST /registry/discover（実行時の collaborator 解決用）を分けている。観察 6 のとおり、order-service に「menu-service」を名指しするコードはない。registry はサービス名を固定管理する場所ではなく、capability 記述で照合する仲介点として機能している。
Obs-06 を見る →
今後の問い
- チームが複数あるとき、skill ドキュメントの所有権と変更権限をどう分けるか。
- 複数サービスで同じ LLM バックエンドを使うとき、モデル選択・バージョン管理・コスト配分の責任分界をどう決めるか。
- capability クエリの書き方がサービスごとにばらつく場合、discover の信頼性をどう担保するか。
- capability クエリの記述がサービスごとにばらつくと、discoveryの信頼性が落ち、単一巨大エージェントと同じ「暗黙依存」が別の形で再発する可能性がある。各サービスが capability を公開・記述する際のガイドライン化が必要。
- Skillの更新権限が曖昧なままだと、業務知識の陳腐化という新しい技術的負債が生まれる。メンテナンスオーナーシップと変更申請プロセスの明示化が求められる。
- system prompt の肥大化を放置すると、サービス単位でもモノリス化が起きる。各エージェントの system prompt の適正サイズと、分割の判断基準を定める必要がある。
- food-delivery-demo 単体断面では立証しきれない論点（後付け導入、長期運用での変化耐性）は、既存 Observation と混ぜずに別トラックの「追加検証」として段階的に公開する。
方針メモ: 追加検証は価値が高い一方、現在の結論根拠（obs-01〜obs-08）とは証拠線を分離して扱います。
実装上の制約（設計の否定ではないもの）
以下は設計仮説への反証ではなく、現在の実装・SDK に残る未完成点です。
interrupt と structured output の同一フローでの組み合わせ
セッション復元時に、型付き structured-output invocation メタデータを永続化する機能は Arachne に未実装。これはエージェントランタイム側の実装課題であり、今回の設計仮説の検証範囲外。
skill ドキュメントの変更影響の定量評価
DeterministicModel パターンで振る舞いの回帰は検出できるが、変更が自然言語出力の質に与える影響を定量化する指標は未整備。