細粒度サーバーレスは、AIと相性がいい — 疎結合×定義駆動が生む"AIが改善提案できる"開発体験

機能を小さく分け、完全に疎結合にすると、影響範囲が閉じるだけでなく、AIによる改善提案・試作までしやすくなる。

前提小さく分け、定義で表す

通販基幹エンジンでは、機能を「単一責務の小さなサービス」に細かく分割し、単一ゲートウェイの背後に完全に疎結合で配置している。ユニット同士は直接呼び合わず、境界を越える協調はイベントに限る。さらに、多くのロジックはコードではなく定義(宣言的データ)として表現する。

• 判定ロジックはルール定義として
• データ取得はクエリテンプレとして
• 入出力はデータ構造定義として
• キャンペーンは販促の部品の組み合わせとして

「振る舞い」の多くが手続きではなく設定になる。ここが後で効いてくる。

従来の利点影響が閉じる

この構造の古典的な利点は明快だ。機能追加や改修の影響範囲が閉じるため、変更は該当ユニットの内側に留まる。結果として、限定的にテストでき、限定的にリリースできる。ひとつのユニットを差し替えても、他のユニットは何も知らないまま動き続ける。

本題AIが直せる構造

本題はここからだ。この構造は「AIが使える」だけでなく「AIが直せる・良くできる」設計になっている。理由は六つある。

• 丸ごと載る：1ユニットが小さいので、AIはユニット全体をコンテキストに載せて理解・書き換えできる。巨大モノリスは全体を読まないと直せない。
• 副作用が読める：境界が明確で影響範囲が閉じるため、変更の副作用を推論しやすく、レビューも小さく済む。
• few-shotが効く：均質な構造なので、兄弟ユニットを例に一貫したコードを生成できる。
• 定義を書く：定義駆動なら、AIは自由記述のコードより"定義を生成・編集"する方が桁違いに正確で安全だ。
• 安全に試す：時刻バージョニングにより、改善案を新バージョンとして試作・プレビュー・切替・切戻しできる。
• 効果が測れる：ユニット単位の観測(ログ・履歴)が、AIの改善提案とその効果測定のフィードバックになる。

トレードオフ疎結合の弱点

もちろん万能ではない。疎結合の裏返しとして、いくつかの弱点が生じる。

• 全体像の把握が難しい。個々のユニットは読めても、システムが結局どう振る舞うかは一望しづらい。
• 横断的な影響の見落とし。イベントを介した連鎖は境界を越えて広がるため、単体では安全に見えても全体では副作用が出うる。
• 分散の運用複雑性。多数のユニットとバージョンを扱う分、追跡・観測のコストが増える。

これらは、明快なイベント設計、変更の履歴、そして定義の一覧性で補う必要がある。AIにとっても、この横断ビューが揃っているかどうかが、提案の質を左右する。