はじめに

こんにちは、とらのあなラボの服部です。

AIにアプリのコードを書かせるのは、もはや日常です。

ただ、使っていて気になることがありました。AIの出してくる設計が、インフラから浮いているのです。コードとしては筋が通っているのに、「どんなインフラの上で、どんな制約で動くか」が抜けています。

この記事で言いたいのは、IaCをアプリと同じ土俵に置けば、AIはインフラとアプリを一貫して設計できる、ということです。今回は AWS CDK で、S3バケットなどのインフラ側も、それを叩くアプリ側も、どちらもAIに作らせました。その成果を、S3起点の処理を例に説明します。

課題：AIの設計はアプリ層で閉じがち

アプリの実装だけを頼むと、AIはアプリのコードだけを文脈に設計を始めます。頼んだ範囲がアプリの中で閉じているからです。すると、こういうことが起きます。

ネットワーク境界を知らない。 このエンドポイントが外部公開か内部通信専用かを判断できず、とりあえず一般公開向けのAPIとして組もうとします。
非同期処理基盤の有無を推測で埋める。 ジョブキューがあるか分からないので、コントローラの中で重い処理を同期的に書いてしまったりします。
外部からどう呼ばれるかを推測で組む。 このアプリを叩いてくる相手が何を渡してくるかを知らないまま、それらしいパラメータ設計をします。

どれも「アプリのコードを読んだだけでは分からない」情報です。人間ならインフラ構成を頭に入れて設計しますが、AIにはその前提が渡っていません。プロンプトで毎回口頭説明する手もありますが、説明は漏れますし、何より面倒です。

IaC（CDK）をアプリと同じ土俵に置く

ここで効いてくるのがIaCです。

アプリのコードは「何をするか」を、IaCのコードは「どんなインフラの上で、どんな制約で動くか」を記述しています。 この2つが揃って初めて、AIは「インフラを考慮した設計」ができます。

しかもIaCはコードなので、構成図やWikiと違い、AIが読んで構造を把握でき、必要なら自分で書き換えることもできます。

今回のプロジェクトでは、このインフラ定義は AWS CDK で書かれていて、アプリと同じリポジトリの中にあります。構成はこんなイメージです。

my-app/
├── app/
│   ├── controllers/
│   ├── models/
│   └── jobs/
├── config/
├── db/
└── iac/          # CDKのコードがここに
    ├── cdk.json
    └── lib/

この「同じ場所に置いてある」ことが、後で効いてきます。

実例：S3にファイルが上がると処理が走る仕組み

例として、「S3にファイルがアップロードされたら、それをトリガーにアプリの処理が走る」という、よくあるイベント駆動の構成を取り上げます。流れはこうです。

ファイル出力元
   │ ファイルをアップロード
   ▼
S3バケット
   │ オブジェクト作成イベント
   ▼
イベント連携
   │ 内部呼び出し
   ▼
アプリ(Rails) が受信
   │ 受け取って即応答
   ▼
非同期ジョブで処理

ファイルが置かれるとS3のオブジェクト作成イベントが発火し、イベント連携（EventBridge）を経由してアプリの内部エンドポイントが呼ばれます。アプリは受け取ってジョブに流し、処理本体は非同期で走ります。

この図のうち、S3バケットからイベント連携までをCDKで、アプリ側をRailsで、いずれもAIに作らせました。

同じAIが書くと、境界面が噛み合う

ここで重要なのは、イベント連携が「何を渡すか」を決める側（CDK）と、それを受け取る側（アプリ）を、同じAIが書いていることです。

CDK側でイベント連携を定義するとき、AIは「アプリのどのパスを、どんなペイロードで呼ぶか」を決めます。続けてアプリのエンドポイントを書くとき、AIはそのペイロードを前提に受け口を作ります。送る側と受ける側が同じAIの中でつながっているので、「インフラ側が送る形とアプリ側が期待する形が食い違う」というズレが起きません。

人間がインフラ担当とアプリ担当に分かれると、この境界面（どのパスを叩くか、何を渡すか）はよく食い違い、仕様書を介して擦り合わせる手間がかかります。同じAIに一貫して書かせると、そこが最初から揃っていました。

設計に表れた具体例

同じAIが書くことの効果は、境界面の整合だけではありません。AIはインフラ側の制約を読み取って、アプリの設計そのものも変えてきます。実際、アプリの設計には次の判断が表れました。

観点	インフラを考えないと出がちな設計	今回AIが出した設計
エンドポイント設計	一般公開向けのAPIとして組む	VPC内部からのみ呼ばれる内部用エンドポイントにする
受け取るパラメータ	それらしい形を推測で組む	イベント連携が送ってくるペイロードの形に合わせる

分かりやすいのはエンドポイント設計です。アプリのことだけを考えると、AIはふつうの公開APIとして組みがちです。でもCDK側で「このエンドポイントへの経路はVPC内部に閉じている」と定義されていれば、それを前提に内部通信向けの設計へ切り替えます。自分が引いた境界線を、アプリ側でも守るわけです。

ただし注意も要ります。「受信したらすぐ応答を返し、処理本体は非同期ジョブに回す」という分離は、ジョブ基盤がある前提の判断です。これはCDKではなくアプリ側のコードを見れば分かることで、インフラ定義の効果ではありません。「インフラを考慮した設計」と言っても、判断材料がアプリ側にあるのかインフラ側にあるのかは分けて見る必要があります。

どう頼んだか

なお、この記事での検証環境は以下の通りです。

AIツール: Claude Code（Claude Sonnet）
IaC: AWS CDK v2（TypeScript）
アプリ: Ruby on Rails + Stimulus(TypeScript)

特別なプロンプト技術はありません。インフラとアプリを切り離さず、地続きの一つのタスクとして頼んだだけです。

アプリのことだけを頼むと、こうなりがちです。

S3にCSVがアップロードされたときに、それを取り込んで処理するエンドポイントとジョブを作ってください。

これだとAIは「S3にアップロードされたとき」を自分の知っている一般的なパターンで補完し、公開APIを生やして同期的に処理を書く、といったどこにでもある構成を出してきます。肝心の「S3からどうアプリまでつなぐか」は頼んだ範囲の外なので、ふんわりしたままです。

代わりに、インフラからアプリまでをひとつながりで頼みます。

同じリポジトリの iac/ でCDKを管理しています。S3にCSVが上がったら、その通知を受けてアプリ側で取り込み処理が走るようにしたいです。バケットの作成からアプリへの通知連携までをCDKで、それを受け取る取り込み処理をRails側で設計してください。CDK側がアプリに渡すもの（パスやペイロード）と、Rails側が受け取る形を、最初から揃えてください。

ポイントは2つです。

インフラとアプリを一つのタスクとして渡す。 境界をまたいだ範囲をまとめて任せると、AIは自分が引いたインフラ側の前提を、そのままアプリ側に反映します。
境界面を揃えるよう明示する。 「渡す形と受け取る形を揃えて」と一言入れておくと、食い違いが最初から潰れます。

別々のお願いに分けると、この境界面でズレが生まれます。地続きで頼むことが、整合を取るうえでいちばん効きました。

補足：渡すIaCは絞る

CDKのスタック全体を文脈に入れると、関係ない構成までノイズになります。今回なら「S3バケットとそのイベント、アプリへ届くまでの経路」だけで十分でした。扱わせる範囲を、いま設計したい処理の周辺に絞ると精度が上がります。

なぜ効くのか

一貫して設計させられた理由は、突き詰めるとインフラの前提がコードとして同じ場所にあったからです。

インフラがコードなら、AIはそれを読んで前提を組み立て、必要なら書き換えます。「VPC内部からのみ呼ばれる」と毎回説明しなくても、コードがそれを語ります。そして境界面は、片方を書いたAIがそのままもう片方を書くので噛み合います。

中でも効いたのが、IaCをアプリと同じリポジトリに置いていたことです。AIは開いているリポジトリの中を文脈にします。インフラ定義が同じ場所にあれば、アプリを書くついでにインフラも書く、インフラを直すついでにアプリも合わせる——この往復が一つの作業で完結します。別リポジトリだと、どこまで渡すかを毎回考えることになり、片方だけ直して境界面がズレる事故も起きやすくなります。リポジトリ分割には運用上の事情がありますが、AIに一貫して設計させるなら、同じリポジトリにある方が圧倒的に楽でした。

ひとつ注意点もあります。IaCが実態とズレているとAIも間違えます。 AIは手元のIaCを正として設計するので、古かったり食い違っていたりすると、誤った前提のまま設計します。IaCの鮮度が、そのまま設計品質を左右します。 同じリポジトリに置き、アプリの変更と一緒に更新していくと、この鮮度を保ちやすくなります。