SwallowKitで実践！AIに全部書かせないサーバーレス境界設計の極意

• 事実と背景：ServerlessDays Tokyo 2026にて、AIエージェントとサーバーレス基盤の境界設計手法が提示された。
• 技術的変革：すべてをAIに書かせるのではなく、Zodスキーマを起点にIaCやAPI契約を決定論的に自動生成し、AIの介入を防ぐ。
• 現場への影響：開発者は設計崩壊やセキュリティのデッドロックを防ぎ、AIを「業務ロジックの実装」という本来の強みに集中させられる。

開発現場でAIコーディングエージェント（GitHub Copilot WorkspaceやCursorなど）を導入したものの、数週間後にコードベースが「スパゲッティコードの墓場」と化してしまった経験はないだろうか。私はシニアエンジニアとして、そのような悲惨な現場を何度も目撃してきた。AIは「動くコード」を瞬時に吐き出すが、システム全体の「アーキテクチャの整合性」や「セキュリティ境界」を自律的に守ることはできない。

例えば、Azure FunctionsとCosmos DB、Next.jsで構成されたサーバーレスWebアプリに「復習機能」を追加しようとしたとする。AIエージェントに指示を出すと、彼らは親切心から、BFF（Backend For Frontend）であるNext.jsから直接Cosmos DBに接続するコードを書いてしまうかもしれない。あるいは、既存のデータモデルがあるにもかかわらず、勝手に新しい重複したモデルクラスを新設してしまう。これは、我々が長年培ってきた「業務ロジックはFunctionsに集約し、認可とデータアクセスを厳密に制御する」という設計思想に対する、静かなるテロ行為である。

コードが「正しく動くこと」と、システムが「正しい設計を維持していること」は全くの別物なのだ。このギャップを埋めない限り、AI主導の開発は、深夜の緊急障害対応という名の無限ループへと我々を誘うことになる。我々エンジニアが直面しているのは、AIの生産性を享受しながらも、システムの秩序をいかにして保つかという、極めて生々しいガバナンスの課題である。

この課題に対する極めてエレガントな回答が、ServerlessDays Tokyo 2026で発表されたスキーマ駆動のscaffolding基盤「SwallowKit」である。SwallowKitの核心は、一つの共通「Zodスキーマ」を起点に、画面、API契約、データモデル、そしてIaC（Bicep）やCI/CDパイプラインまでを一気通貫で「決定論的（Deterministic）」に生成する点にある。ここで重要なのは、AIエージェントに「考えさせる領域」と「ツールで強制的に再現する領域」の境界線を厳密に設計していることだ。

SwallowKitでは、プロジェクト内のファイルを以下の3つのライフサイクルに分類し、管理している。

AIエージェントには、MCP（Model Context Protocol）やCLIツールを介して「inspect boundaries（境界の検査）」を実行させ、どのファイルを編集してよく、どのファイルを直接触ってはならないのかを厳密に認識させる。これにより、AIは「APIの型やインフラ構成」という決定論的な構造を破壊することなく、「復習間隔の計算ロジック」といった、本来の「考えるべき業務ロジック」にのみその強力な推論能力を集中させることができるのだ。

この「エージェントに全部書かせず、決定論的なジェネレーターと協調させる」というアプローチは、一過性のトレンドではない。クラウド大手のAWSが2026年9月8日に発表した「Nx Plugin for AWS 1.0」の動向を見ても、これが業界全体のメガトレンドであることは明白だ。AWSのこの最新ツールでも、Coding AgentがMCPを介して「Nx Generator」というツールを呼び出し、API、Webフロントエンド、データ層、そしてCDK（Cloud Development Kit）によるIaCを決定論的にスカフォールディング（雛形生成）するアーキテクチャが採用されている。

つまり、AzureにおけるSwallowKitの思想と、AWSにおけるNx Pluginの思想は完全にシンクロしているのだ。なぜ、メガプラットフォーマーやトップエンジニアたちがこぞってこのアプローチを採用するのか。それは、分散システムであるサーバーレス基盤において、接続権限（IAMやRBAC）、ネットワーク境界、秘密情報の管理、イベントの重複配信（冪等性）といった「非機能要件」をAIにその都度考えさせることが、あまりにもハイリスクだからである。

例えば、メッセージキュー（Service BusやSQS）を介した非同期処理において、同じイベントが2回配信された際の重複排除（デッドロックや二重処理の防止）の設計を、AIの気まぐれな出力に委ねるべきではない。そこは、人間が設計した「決定論的なテンプレート」によって厳密に再現されるべき領域なのだ。AIにアーキテクチャの選択を委ねるのではなく、人間が敷いたレールの上をAIに走らせる。これこそが、現代のモダン開発における最適解であると私は確信している。

我々エンジニアは今、重大なパラダイムシフトの渦中にいる。かつて「優れたエンジニア」とは、複雑なコードを素早く、バグなく書ける人間のことを指した。しかし、その領域は急速にAIエージェントへと代替されつつある。では、これからの時代に我々が担うべき真の役割とは何か？それは「境界（Boundaries）の設計者」となることだ。

システムにおいて「何を大切にするか（要件・権限・許容する失敗の定義）」を人間が決断し、その決断を「決定論的なツール」としてコード化し、AIエージェントが安全に暴れ回れる「砂場（サンドボックス）」を構築することである。もし、あなたのプロジェクトが、AIにプロンプトを投げて出力されたコードをそのままGitにマージしている状態なのだとしたら、それはブレーキのないスポーツカーを自動運転させているようなものだ。

明日から我々が取るべき処方箋は明確である。

• プロジェクト内の「AIに考えさせるべきビジネスロジック」と「ツールで自動生成すべきボイラープレート」を峻別すること。
• BicepやCDK、TerraformといったIaC、あるいは社内ジェネレーターを用いて、接続と検証のプロセスを徹底的に共通化・自動化すること。
• AIエージェントに対して、編集可能な境界を明示する「システムプロンプト」や「MCPツール」を整備すること。

最後に、読者であるあなたに痛烈な問いを投げかけたい。あなたのチームのアーキテクチャは、AIエージェントの「気まぐれな提案」に対して、決定論的な「NO」を突きつける仕組みを持っているだろうか？それとも、AIの出力に怯えながら、深夜のデバッグに追われる未来を受け入れるのだろうか？