システム開発の見積書を見ると、たいてい上のほうに「環境構築」「基盤設計」「共通機能実装」といった行が並んでいます。総額のうち相応の割合がここに乗っているのに、この行が何の作業なのかを説明できる発注者はほとんどいません。
2026年9月、AWSが「Nx Plugin for AWS 1.0」を正式公開しました。API、ウェブサイト、データベース、さらにAIエージェントやMCPサーバーまで、構成要素ごとのジェネレーターで、デプロイ可能な雛形を生成するツールです。しかも、インフラ定義（CDKまたはTerraform）、WAFによる保護、CloudWatchへのアクセスログ、X-Rayによる追跡まで最初から入っています。
見積書の上のほうの行が、静かに軽くなり始めています。
「共通機能実装」の中身が変わった
これまで、新しいシステムを作るときの最初の数週間は、おおむね次のような作業に消えていました。
- プロジェクトの構成を決めて、フォルダとビルドの設定を作る
- 認証・ログ・監視の共通部分を実装する
- インフラをコードで書き、デプロイできる状態にする
- 型定義をフロントとバックで共有できるようにつなぐ
このうちフォルダ構成や標準的な接続処理は再利用しやすい部分です。一方、認証方式、監視の要件、ネットワークの制約は案件ごとに違います。テンプレートで省ける作業と、個別設計が必要な作業を分けて考えます。
今回のようなツールが標準化されると、この社内資産の価値が下がります。推奨構成が公式から提供され、しかもセキュリティと可観測性の初期設定が入った状態で出てくるためです。テンプレートの有無だけでなく、自社の要件にどう適合させるかが比較の軸になります。
では、どこにお金を払うことになるのか
土台が無料で速く出てくることは、発注額が下がることを必ずしも意味しません。 比重が移るだけです。移る先は3つあります。
1つめは、要件を切る作業です。 雛形は「何を作るか」を決めてくれません。むしろ、作るのが速くなるほど、決めていない要件のまま作り始めてしまう事故が増えます。ここは人の仕事のまま残ります。発注側が何を用意しておくべきかはシステム開発の外注で失敗しない発注ガイドにまとめています。
2つめは、生成された土台を「自社のもの」にする作業です。 雛形は一般解です。自社の既存システムとの接続、既存データの移行、社内の権限体系への適合は、そのままでは埋まりません。むしろ、ここを埋める設計こそが本来の受託の中身です。
3つめは、運用と引き継ぎです。 生成されたコードは、生成した人が中身を完全に理解しているとは限りません。ツールが吐いたものを誰も読まずに本番へ出すと、半年後に手が付けられなくなります。これはAI生成コードで起きている問題と同じ構造で、AIに8割書かせたコードが半年で「腐る」に詳しく書きました。
見積もりを受け取ったときに聞く3つの質問
比重が移ったことを確認するために、次の3つを聞いてみてください。答え方で、相手が今の前提で考えているかが分かります。
- 「初期構築の工数の根拠は何ですか」。 公式の雛形やツールを使うのか、自社テンプレートを使うのか、ゼロから書くのか。どれでも構いませんが、選んだ理由を説明できることが重要です。「いつもこうしています」しか返ってこない場合は、工数が習慣で積まれています。
- 「監視とログは初期状態で何が入りますか」。 後付けになりがちで、しかも後から入れると高くつく部分です。最初から入る前提のツールを使うなら、この行は薄くなるはずです。
- 「生成されたコードのレビュー範囲はどこまでですか」。 ツールが出した部分を含めてレビューするのか、自分で書いた部分だけかで、引き渡し後のリスクが変わります。
なお、これらの質問で金額を値切ることが目的ではありません。 同じ金額でも、初期構築に厚く積まれているのか、要件と運用に厚く積まれているのかで、納品後の結果がまるで変わります。見るべきは総額ではなく配分です。
「初期設定が入っている」は「自社に合っている」ではない
こうしたツールの売り文句に、推奨される構成が最初から入っているという点があります。これは本当に価値があります。監視やログの初期設定を毎回ゼロから用意する作業を減らせるためです。
ただし、入っているのは一般的な推奨設定です。自社にとって正しいかどうかは別の話になります。
| 入っているもの | 確認すべきこと |
|---|---|
| 通信の保護設定 | 自社が守るべき対象と一致しているか |
| アクセスログ | 保存期間と保存先が社内規定に合うか |
| 処理の追跡 | 取得する情報に個人情報が混ざらないか |
特にログの保存期間は、初期値のまま運用すると2つの方向で問題になります。短すぎれば事故のときに追えず、長すぎれば保管費用が想定外に膨らみます。どちらも本番稼働から数ヶ月経ってから気づきます。
引き渡しの前に、初期値のまま使っている設定の一覧を出してもらってください。「全部そのまま使っています」と即答できる会社は、少なくとも把握はしています。一覧が出てこない場合は、誰も中身を見ていない可能性があります。
安く速く作れることの裏側
もう一点、発注側として意識しておくとよいことがあります。
こうしたツールはAIコーディングエージェントから直接呼び出せる形で提供されています。つまり、AIに「この構成で作って」と頼めば、人が手を動かさずに土台が立つところまで来ています。
ここで起きやすいのが、作れる量が増えたぶんだけ、作る対象が膨らむことです。当初は1機能の予定だったものが、「ついでにこれも」で3機能になります。速く作れることは、作りすぎないことの難しさとセットです。納品後に誰が保守するのかを決めてから広げてください。契約に何を書くかは納品されたら終わり、ではないのとおりです。
次にやること
いま見積もりを取っている、あるいは比較している最中なら、「初期構築」に相当する行が総額の何割を占めているかを数えてください。 割合だけに一律の合否基準はありません。生成で省ける作業、個別設計、検証・運用の内訳を聞いて比較します。
そのうえで、要件が固まっていない部分を先に書き出してください。 土台が速く出る時代に、プロジェクトを遅らせるのは技術ではなく、決まっていない仕様です。ここを埋める時間を先に取るほうが、結果的に安く済みます。
システム開発の要件整理、見積もりの妥当性確認、AWS上での構成のご相談は、グリームハブの開発・AI・自動化のご相談で承っています。要件によって最適な構成は変わるため、個別にお見積りします。お問い合わせからご相談ください。
Sources
- AWS announces Nx Plugin for AWS for scaffolding full-stack applications — AWS What’s New
- Build full-stack AWS applications in minutes with AI-powered scaffolding — AWS Open Source Blog
- AWS、AIがフルスタックAWSアプリの基本コードを、セキュリティ、可観測性、インフラまで一気通貫で生成する「Nx Plugin for AWS 1.0」、オープンソースで公開 — Publickey
- awslabs/nx-plugin-for-aws — GitHub
