構造の観点

製品の内部構造に関わる言葉です。構造の判断そのものはClaudeに任せられます。どの構造が必要かは製品の規模と今後の予定で決まるため、該当しそうな場面で言葉を出します。

全体の繋がり

個々の言葉の前に、全体の地図を持っておきます。弊社の標準構成では、ブラウザからの要求をWorkerが受け、必要に応じてデータベース（D1）、ファイル置き場（R2）、外部APIとやり取りして、応答を返します。

この地図が頭にあると、「データはどこに保存されている?」「障害はどこで起きた?」「費用はどこで発生する?」という質問の行き先が分かります。自分の製品の地図は、Claudeに描いてもらえます。

この製品の構成図を説明して。データがどこに保存されて、どの外部サービスと繋がってる?

API

画面とサーバー処理の間の窓口であり、契約です。「この形で頼めば、この形で返す」という契約が安定していれば、画面とサーバーを別々に直せて、同じ処理をスマホアプリや外部システムからも使えます。弊社ではRESTfulな設計を標準にしています（推奨する技術スタック）。

同じ処理を複数の画面から使う予定、スマホアプリの予定、外部への提供の予定が少しでもあるなら、早めに伝えます。

この処理は後でスマホアプリからも使いたい。APIとして分離して

Workerとサーバーレス

サーバー機を常時動かす代わりに、リクエストが来た時だけ処理が実行される仕組みです。サーバーの台数、夜間の監視、アクセス急増時の増強を自分で持たなくてよいのが価値で、弊社の標準（Cloudflare Workers）はこの形です。特別な要望がなければ、意識しなくてもこの構成になります。

コンテナ

アプリを実行環境ごと箱詰めして、どこでも同じように動かす仕組みです。「手元では動くのに、あちらでは動かない」の原因のうち、OSやインストール済みソフトといった実行環境の差を消します。データ、設定、外部サービスの差は残ります（環境の分離）。弊社の標準構成では出番が少なく、特殊なソフトウェアが必要な場合や、他社の環境へ納品する場合に登場します。名前と目的だけ知っておけば十分です。

データベースとmigration

データベースの形（どんな項目を持つか）は、データが入った後に変えるのが難しい部分です。migrationは、形の変更を再現可能な手順としてコードにしたものです。項目の削除や型の変更は保存済みのデータを壊し得るため、変更の前にバックアップと手順の確認を頼みます。

この項目を追加するmigrationを作って。既存のデータが消えない手順で

バリデーション

利用者の入力を検証することです。Webではフォームを経由せずサーバーへ直接データを送れるため、画面側の入力チェックだけでは防御になりません。だから弊社では、検証をサーバー側にも入れることを基本にしています。指定しないと、画面側だけで済まされることがあります。

入力の検証は画面側だけでなく、サーバー側にも入れて