構造の観点

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

全体の繋がり

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

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

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

API

画面とサーバー処理の間の窓口です。「この形で頼めば、この形で返す」という約束が安定していれば、画面とサーバーを別々に直せて、同じ処理をスマホアプリや外部システムからも使えます。設計の条件は開発者向けの開発の進め方で扱います。

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

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

Workerとサーバーレス

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

コンテナ

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

データベースとmigration

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

この項目を追加しても、保存済みのデータはそのまま使える?変更の影響と、失敗した場合の戻し方を説明して

バリデーション

利用者の入力を確かめることです。弊社では、必須項目の抜け、不正な金額、極端に長い文章など、受け付けてはいけない条件を決めます。画面にエラーが出ることだけで終わらせず、不正なデータが保存されないことまで確認します。入力を検査する実装上の境界はアーキテクチャで扱います。

空の入力や不正な値で送信した場合、利用者に理由が伝わり、不正なデータが保存されないことを確認して