「認証は動いています。ただ、パスワードのハッシュが平文に近い実装で、トークンの失効も入っていません」。エージェントに任せたバックエンドのレビューで、こういう報告が上がってくる。動いているデモは確かにある。だが中身は、テーブル設計もエラーハンドリングも認証も、その時々のプロンプト次第でバラバラに組まれていて、本番に出せば必ずどこかが破綻する。受託でAIエージェントにバックエンドを書かせ始めた人なら、一度はこの「動くけど怖い」状態を経験しているはずだ。
問題は、エージェントが下手だからではない。エージェントには「このプロジェクトで正しいとされるアーキテクチャ」が与えられていないから、毎回その場で最善らしきものを選び直してしまうのだ。つまり、書かせる前に「正しい書き方の枠」を用意できていないことが本質にある。
そこに対する一つの答えとして、AWSが「AWS Blocks」というフレームワークを公開した。本記事では、これを「生成を速くする道具」ではなく「AIに正しいバックエンドを強制する土台」として捉え直し、受託開発で実際に使えるのか、どこに線を引くべきかを、業務システムの設計を預かる立場から整理する。
AWS Blocks が解こうとしている問題
AWS Blocks は2026年6月16日にパブリックプレビューが始まった、オープンソースのTypeScriptフレームワークだ（AWSの紹介記事はInfoQの解説がまとまっている）。中核にあるのは「Block」という単位で、これは1つのバックエンド機能——DBテーブル、ユーザー認証、AIエージェント、ファイルアップロード、バックグラウンドジョブ、定期タスク、リアルタイム通知、メール送信など——を、アプリコード・ローカルモック・AWSインフラ定義まで含めて一つにまとめたnpmパッケージである。
開発者は必要なBlockをimportして組み合わせる。すると、その背後でベストプラクティスに沿ったAWSインフラ（認証ならCognito、PostgresならAurora経由、AIならBedrock、ストレージならS3、といった具合）が生成される。プレビュー時点で約20種類のBlockが用意されている。AWSアカウントがなくてもローカルで動かせて、同じコードを変更ゼロのまま Lambda / DynamoDB / Aurora / Bedrock などへデプロイできる、というのが売り文句だ。Blocks自体に追加料金はなく、課金されるのは実際に使ったAWSサービスの分だけになる。
ここまでなら「AWS版のお手軽スターターキット」に聞こえるかもしれない。だが本当に注目すべきは設計思想のほうだ。
「AIエージェントが書く」前提で設計されている
AWS Blocks がこれまでの足場（足回りを整えるツール群）と一線を画すのは、最初から「コードを書くのは人間ではなくAIエージェント」という前提で組まれている点にある。各Blockには「steering files」と呼ばれる誘導用の定義が組み込まれていて、これがカスタム設定なしに、コーディングエージェントを正しいアーキテクチャへ向かわせる。
これは受託の現場が地味に欲しかったものだ。AIに指示を与える仕組みについてはAGENTS.md・SKILL.md・DESIGN.mdの役割分担を整理した記事で触れたとおり、「何を・どう書かせるか」をファイルとして外出しし、プロジェクトの流儀をエージェントに刷り込むのが定石になりつつある。Blocks はそのstreering（誘導）の部分を、AWSのベストプラクティスというかたちで標準添付してきた。エージェントは毎回ゼロから設計判断をせず、Blockが敷いたレールの上でコードを書く。結果として、生成物の「設計のばらつき」が構造的に抑えられる。
AWSにはすでに Amplify や App Studio があるが、Blocks の立ち位置は少し違う。Amplify がホスティングとフルスタック寄りの統合、App Studio がローコードの作成体験を志向するのに対し、Blocks はローカルファースト・コンポーザブル（組み合わせ前提）・エージェント前提という性格が強い。マネージドな完成品を提供するのではなく、エージェントが正しく組み立てるための部品と誘導を渡す、という方向だ。
受託で見るべきは「生成スピード」ではない
ここが本記事で一番伝えたい主張だ。Blocks を受託で評価するとき、「バックエンドが速く立ち上がる」を価値の中心に置くと判断を誤る。速さは結果にすぎない。受託にとっての本当の価値は、AIに正しいアーキテクチャを強制できる土台が手に入ること、言い換えれば品質の下限（フロア）を底上げできることにある。
これまで、エージェントが書いたバックエンドの品質は、プロンプトの巧拙やその日の運に左右されていた。良いときは綺麗だが、悪いときは認証が穴だらけになる。Blocks のように「認証はこのBlock、DBはこのBlock」と部品が決まっていれば、最悪のケースでも一定の水準を割らない。受託で怖いのは平均ではなく最悪値だ。納品物のうち一番ひどい部分が、そのまま事故とクレームの原因になる。だからフロアを上げる道具は、それだけで受託にとって意味がある。
ただし、ここで取り違えてはいけないことがある。Blocks を入れても、設計責任は依然として人間（受託側の自分たち）にある。Blockが敷くのはあくまで一般的なベストプラクティスであって、目の前の業務要件に対する設計判断ではない。どのBlockを選び、どう組み合わせ、業務ロジックをどこに置くかを決めるのは人間だ。Blocks は「下限を保証する道具」であって、「設計を肩代わりする道具」ではない。この線引きを曖昧にした瞬間に、後述する落とし穴に落ちる。
受託に向く場面、向かない場面
私はこれまで自動販売機の管理システムや装置制御、基幹・業務系のバックエンドを手掛けてきたが、その経験から言うと、Blocks の適否は案件のフェーズと制約でかなり分かれる。
向いているのは、新規の小〜中規模バックエンドやPoC・検証段階だ。ゼロから足場を組む手間が省け、認証やジョブやストレージといった「毎回似たような実装になる部分」をエージェントに安定して書かせられる。立ち上がりの速さと品質下限の両方が効く局面で、特にAWSを採用する前提が固まっている案件なら相性がいい。AWSのデータベース寄りの選定についてはAurora Serverless v4を受託のDBモダナイゼーションで使う記事でも整理しているので、Blockが生成するインフラの裏側を理解する助けになるはずだ。
逆に正直に書いておきたい弱点もある。
| 論点 | 受託で気をつけること |
|---|---|
| AWSロックイン | 生成されるのはAWS前提の構成。マルチクラウドや将来の移行要件があると詰みやすい |
| プレビュー段階 | パブリックプレビューであり仕様変更・破壊的変更があり得る。本番採用は慎重に |
| 既存案件への後付け | 稼働中システムにBlocksを差し込むのは難しい。新規ベースが基本 |
特にロックインは契約段階で確認すべき論点だ。「将来クラウドを変える可能性がある」と顧客が言っているのにAWS前提で固めれば、後で大きな手戻りになる。AWS上でのエンタープライズなAI活用の射程についてはClaude Platform on AWSを受託で使う記事でも扱っているが、いずれにせよ「なぜAWSに寄せるのか」を顧客と握ったうえで採用するのが筋だ。
steering files を自社の流儀に拡張する
Blocks を受託で本当に使いこなすなら、付属の steering files をそのまま使うのではなく、自社の流儀で拡張する運用にまで踏み込みたい。AWSが用意した誘導は「一般的に正しい」が、「あなたの会社で正しい」とは限らないからだ。
具体的には、命名規則、レイヤリング（どこにドメインロジックを置き、どこにI/Oを置くか）、テスト方針、エラーハンドリングの統一形といった、自社が受託で守っているルールを steering 側に足し込む。こうしておくと、エージェントが書くコードがAWSのベストプラクティスと自社規約の両方に同時に従うようになり、レビューで毎回同じ指摘を繰り返す消耗が減る。
// 例: 自社の steering に「ドメイン層を薄いI/Oから分離する」方針を足すイメージ
// Block が生成する auth() / db() は I/O 境界として扱い、
// 業務ルールは domain/ 配下のピュアな関数に閉じ込める、と誘導する。
import { auth } from "@aws/blocks-auth";
import { table } from "@aws/blocks-dynamodb";
import { approveInvoice } from "../domain/invoice"; // 副作用を持たない業務ロジック
export const handler = async (req: Request) => {
const user = await auth.requireUser(req); // I/O境界(Block)
const invoice = await invoices.get(req.invoiceId); // I/O境界(Block)
const next = approveInvoice(invoice, user); // 純粋な業務判断(自社流儀)
await invoices.put(next); // I/O境界(Block)
return Response.json(next);
};ポイントは、Block が引いてくれるレール（認証やDBアクセス）と、自社が守りたい設計判断（業務ロジックの置き場所やテスト容易性）を、steering の層で接続することだ。フレームワーク側の標準と自社規約がぶつかる箇所こそ、テクニカルマネージャーが事前に方針を決めておくべきところになる。
「エージェントが書いたから正しい」が一番の落とし穴
最後に、受託でBlocksを使うときに最も危ないパターンを挙げておく。
第一に、「Blockの誘導に従ってエージェントが書いたのだから正しいはず」と検証を飛ばすこと。steering files が下限を引き上げても、上限を保証するわけではない。業務要件への適合や境界値の振る舞いは、依然として人間がレビューし、テストで確かめなければならない。AIが量産するコードをどう受領・レビューするかはAIエージェントが量産するコードのレビュー・管理を扱った記事で詳しく書いたが、土台が良くなったぶん、かえって検証を省きたくなる誘惑が強まる点に注意したい。
第二に、Blockの組み合わせ前提から外れる要件で無理をすること。Blocks は「典型的なバックエンド機能を組み合わせる」設計に最適化されている。業務システム特有の複雑な状態遷移や、既存基幹系との密な連携など、部品の組み合わせでは表現しきれない要件にBlockを無理やり当てると、かえって歪んだ構造になる。そこは素直にBlockの外で組むべき領域だ。
第三に、ロックインを軽視してマルチクラウド要件に詰むこと。これは前述のとおりだが、採用判断の段階で必ず顧客と握っておく。
これらはどれも、Blocks が悪いのではなく、道具の位置づけを誤った結果として起きる。Blocks は品質のフロアを上げる土台であって、設計と検証の責任を引き取ってくれる存在ではない——この一点を外さなければ、受託にとって十分に頼れる選択肢になる。
どこから着手するか
もしいまAIエージェントにバックエンドを書かせていて、出来上がりの品質が案件ごとにブレているなら、まずは「エージェントに何のアーキテクチャ方針も渡せていない」状態を疑ってほしい。Blocks のように誘導を標準で持つフレームワークを小さなPoCで試し、生成物の下限がどれだけ揃うかを自分の目で確かめるのが、現実的な第一歩になる。
そのうえで、AWSに寄せてよい案件か（ロックインを許容できるか）、自社の流儀を steering にどう載せるか、という二点を整理できれば、Blocks を受託にどう組み込むかの判断はかなりクリアになるはずだ。
新規バックエンドの設計をAIエージェント前提で組み直したい、Blocks を受託フローにどう載せるか相談したい、あるいは「動くけど怖い」状態のバックエンドを品質の読める構造に立て直したい——そうしたお悩みがあれば、グリームハブのお問い合わせからご相談ください。要件と制約を拝見したうえで、AIに任せる部分と人間が握る部分の線引きから、ご一緒に設計します。
