1. はじめに：クラウド開発における「見えない制約」との戦い
AWSをはじめとするクラウドプラットフォームは、現代のWebシステム開発において不可欠な存在です。
しかし、その利便性の裏側には、PoC（概念実証）や開発環境の小規模なデータ量では顕在化しにくい、「仕様の壁」が存在します。
本記事では、2つの「壁」をご紹介します。
2. 事例1：AWS Lambda 「15分タイムアウト」の罠
直面した状況
あるプロジェクトで、顧客のデータを集計・加工するバッチ処理をAWS Lambdaで実装しました。
開発段階では数分で完了していたため、手軽でサーバーレスなLambdaは最適な選択肢に見えました。
しかし、本番稼働後に顧客のデータが日々増加するにつれて、処理時間が徐々に伸長。
ある日、Lambdaの実行時間上限である「15分」の壁に突き当たり、処理がタイムアウトによって強制終了し、データ欠損を引き起こす事態となりました。
根本原因の考察
これは単なる「処理が重かった」という話ではありません。
根本的な原因は、「本番環境におけるデータ量のスケール（増加）に対する予測の甘さ」と、「同期処理を前提としたコンピューティングリソース選択のミスマッチ」にありました。
Lambdaは、長時間実行が想定される重厚なバッチ処理には本来不向きだったのです。
アプローチ：AWS Batchの利用に変更しました。
3. 事例2：REST API 「GETメソッドのURL長制限」の罠
直面した状況
次に紹介するのは、Webアプリケーションの検索機能で発生した問題です。
私たちはRESTの設計思想に則り、多数の検索条件（IDリストなど）をGETメソッドのクエリストリングでサーバーに送信する仕様で実装していました。
しかし、こちらも顧客の利用が進むにつれて検索条件が複雑化・長大化。
結果として、ブラウザやAWSのALB (Application Load Balancer) が規定するURLの最大長（約2KB～8KB）を超過してしまい、「414 URI Too Long」エラーが頻発するようになりました。
根本原因の考察
原因は、「取得処理はGETメソッドで行うべき」というRESTfulの原則を厳密に解釈しすぎた結果、ブラウザやミドルウェアが持つ物理的な制約への考慮が漏れてしまったことでした。
アプローチ：POSTメソッドへの変更
4. これらの失敗から得られた「エンタープライズ設計の教訓」
今回ご紹介した2つの事例は、私たちに重要な教訓を与えてくれました。
データ量のスケールを設計に組み込む: PoCのコードをそのまま本番に持ち込んではいけません。
非機能要件を考慮した設計にする必要があります。
特性を正しく理解し、プロジェクトの制約に合わせて柔軟にアーキテクチャを選択する「技術的柔軟性」が必要でした。
5. おわりに
自身のノウハウにすることでレビュー時の観点としてありますが、同じ過ちを犯さないように、そういったチェックリストをAI駆動開発でチェックするといったプロセス強化をできるようにしたいと考えております。
