Tsuzura

作りたいサービスに必要な仕組みを決める

一つの利用場面について、端末内だけで作れるか、バックエンド/API、DB、外部サービス、オフライン後の同期、画面外の処理が必要かを判断票で決めます。

公開日
更新日

AIに「このサービスを作って」と頼む前に、まず一つの利用場面を選びます。たとえば「予約機能」ではなく、「利用者が空き枠を選び、ほかの人と重ならないよう予約を確定する」までを一つにします。

その場面が一人・一端末で完結し、消えて困るデータも秘密情報も外とのやり取りもなければ、画面と端末内の処理だけで作れるかもしれません。

共有する正本（食い違ったときに基準とするデータ）や利用者ごとのデータがあるなら、保存先を分けて考えます。APIキー、権限、決済、画面を閉じた後の処理がある場合は、バックエンドや外部サービスも検討します。

ここで決めるのは、端末内だけで足りるか、バックエンド/API、DB、外部サービス、オフライン後の同期が必要かです。バックエンドは利用者が直接変更できない側の処理、APIはその処理を呼ぶ受付口、DBは検索・更新する記録の保存先を指します。

完成状態は、選んだ利用場面について「必要な仕組み判断票」を埋め、未決事項を保留（HOLD）にできた状態です。具体的な製品名やフレームワーク、構成図、データモデル、API仕様は次の工程で決めます。

最初に答える5問

次の5問は、サービス全体ではなく一つの利用場面に答えます。現行業務がある場合は、始まりと終わり、担当者、待ちや例外、二重入力、今回は変えない範囲も先に一行で残します。

  1. 誰が、何人・何台で使うか。 一人・一端末か、複数人・複数端末か。全員に同じ内容を見せるか、利用者ごとに内容が違うか。
  2. 何を残し、どこを正本にするか。 終了後もデータを残すか。共有、検索、履歴、監査、復旧が必要か。端末、運営側の保存先、外部サービスのどれを最終判断の基準にするか。
  3. 信頼できる側で何を守るか。 APIキーなどの秘密情報、決済、権限、利用者が書き換えてはいけない業務ルールをサーバーで扱う必要があるか。
  4. 通信できない間も使うか。 オフラインで読む・更新するか。再接続後に同期するか。同時変更が起きたとき、どちらを残すか。
  5. 画面の外で何が動くか、誰が面倒を見るか。 定時処理、webhook（外部サービスから届く通知）、メール・通知、長時間処理があるか。外部APIだけで済むか。バックアップ、書き出し、保存期間、費用、障害対応の責任者は誰か。

一つでも答えが不明で、その答えによって構成が変わるなら、推測で埋めずHOLDにします。

まず作業を始めるなら、この5問を答えた時点で「必要な仕組み判断票」へ進めます。分からない言葉や判断が出たときだけ、間の解説へ戻ります。

本文のリンク先は、仕様や各サービスの条件を確認する資料です。「候補」「別に決める」「判断票」と書いた部分は、資料を使って構成を決めるためのこの記事の整理です。

まず役割と保存先を分ける

「画面があるか」「DBがあるか」ではなく、処理する場所とデータの置き場所を別々に見ます。

  • client-only / browser-only（端末側だけ）：計算や表示などを、利用者のブラウザー・アプリ・端末で処理します。端末内データのバックアップ、共有、権限、秘密情報の保護までは決まりません。
  • server / backend（バックエンド）：クライアントから要求を受け、利用者が直接変更できない側で処理して結果を返します。APIや外部サービスの関数もこの役割を担えますが、安全性、正しさ、データ保存の有無は別に決めます。
  • ブラウザー・端末内保存：Web Storage、IndexedDB、端末上のファイルなどへ保存します。別端末との同期、共有正本、端末紛失からの復旧は別の判断です。
  • サーバー側のDB：複数の要求から検索・更新する記録を運営側で保存します。データモデル、認可、バックアップ、運用の正しさはDBを置くだけでは決まりません。
  • オブジェクトストレージ：画像、添付ファイル、書き出しファイルなどを保存します。業務記録との対応、公開範囲、保存期間は別に決めます。
  • 外部サービス側の保存：フォーム、決済、メール、AI、認証などの提供事業者がデータを保持します。自分たちの責任がなくなるわけではなく、正本、書き出し、削除条件の確認が必要です。

HTTPでは、クライアントは要求を送り、サーバーは要求を受けて結果を返す役割です。同じプログラムが接続によって両方の役割を持つ場合もあります。RFC 9110のクライアント/サーバー定義は通信上の役割を示すもので、製品全体の構成を自動で決めるものではありません。

ブラウザーのWeb Storageは、名前と値の組み合わせをクライアント側へ保存します。localStorageは利用を終えた後も残せますが、ストレージの無効化や容量超過で書き込みが失敗する場合があります。HTML StandardのWeb Storageを使う場合も、保存できたかを確認します。

構造化した記録や索引が必要ならIndexedDBが候補です。W3CのIndexed Database API 3.0はブラウザー内のデータベースAPIを定義していますが、2026-08-20時点では作業草案（Working Draft）です。ブラウザー内にDBを置く場合も、別端末の共有正本と復旧先は別に決めます。

Webプラットフォームの端末内ストレージは、初期状態では保存が保証されないベストエフォート（best-effort）で、容量不足時に消去対象になり得ます。WHATWG Storage Standardの永続モード（persistent mode）を選ぶ場合も、端末紛失や故障に備えた外部バックアップは別に決めます。一端末の保存を選ぶなら、消えたときの影響、書き出し方法、復旧責任者まで決めます。

どのデータを正本にするか決める

正本は、内容が食い違ったときに最終判断の基準とするコピーです。「サーバーにあるから正本」「最後に更新されたから正しい」とは限りません。

一人・一端末のチェックリストなら端末内コピーを正本にできます。共有予約では、全員が同じ空き状況を見るためのサーバー側コピーが正本候補です。ローカルファーストの原典では、共同ノートの各端末に主要なコピーを置き、変更を統合する考え方が示されています。どれを選んでも、削除、同時更新、復旧時に正本をどう判定するかを書きます。

サーバーが必要になる条件

バックエンドが必要かは、DBが必要かとは別に判断します。共有する正本、秘密情報、認可、決済、改ざんされたくない業務規則、外部から届く通知、画面外の処理があるときは、クライアントから直接変更できない処理場所を候補にします。

秘密情報と業務ルールを守る

ブラウザーへ配るコードや設定に秘密情報を埋めると、利用者はその値を取得できます。OpenAIはAPIキーをブラウザーやモバイルアプリへ配置せず、要求をバックエンド経由にするよう案内しています。この扱いはOpenAIのAPI key safety guidanceで確認できます。

提供事業者によっては、クライアントへ置ける公開用キーとサーバーへ置く秘密キーを分けています。Stripeのsecret API key guidanceもこの区別を示します。

「APIキーがある」だけでは配置場所を決められません。対象サービスがクライアント利用を許す認証情報かを、提供事業者の公式条件で確認します。

別の接続先をブラウザーから呼び、応答を読み取るには、接続先がCORS（接続元をまたぐ読み取りの規則）に必要な応答を返す必要があります。WHATWG Fetch StandardのCORS protocolで一般条件を確認したうえで、利用回数の上限、利用規約、費用は採用候補ごとに別途確認します。

秘密情報、決済確定、割引判定、在庫確保などはバックエンド候補です。

表示制御と認可を分ける

利用者ごとに読める・更新できるデータが違うなら、認証結果と対象データを使い、要求ごとに認可します。

ボタンを隠す、URLを表示しないといったクライアント側の制御は、操作性には役立ちます。ただし、最終的な認可にはなりません。OWASP Authorization Cheat Sheetは、サーバー、ゲートウェイ、サーバーレス関数などで確認するよう示しています。

ブラウザー内の値も、利用者権限や、ページへ悪意あるスクリプトが入り込むXSSによって読み取り・変更され得ます。OWASP HTML5 Security Cheat Sheetが示すように、localStorageやクライアント側のDBを、認可済み・改ざん不能・機密という前提で扱いません。

サーバーがあるだけで安全になるわけではありません。認証認可の欠落、公開設定、入力処理、ログ、秘密情報の管理、バックアップの誤りは残ります。

送信処理と保存処理を分ける

問い合わせフォームでは、送信内容を処理するバックエンド、外部サービスの関数、またはフォーム・メールサービスが候補です。送信先のサービスを正本とし、検索・履歴・再処理を自分たちで行わないなら、自前DBを不要にできる場合があります。

問い合わせ記録を検索する、対応履歴を残す、削除期限を管理する、送信失敗を再処理するなら、保存先と責任者が必要です。「バックエンドが要る」から「自前DBも要る」へ飛ばず、処理と保存を二段階で決めます。

オフラインと画面外の処理を分ける

オフライン利用には、通信がない間に必要なコードとデータを端末へ置きます。その後、再接続時に送る変更、重複送信を避ける方法、サーバー側の変更との競合、同期失敗の表示を決めます。

Service Workerはイベントを受けて起動し、オフライン対応を助けられます。ただし常時動くわけではなく、イベントごとに起動し、実行時間に上限があります。W3C Service Workers Candidate Recommendation Draftの規定を、任意時刻の必達処理と読み替えません。

Background Syncは再接続後の送信候補ですが、2026-08-20時点の文書はW3C標準ではないコミュニティグループ草案です。発火時期、再試行、実行時間にはブラウザー実装の裁量があります。WICG Web Background Synchronizationの文書状態と対象ブラウザーの対応を確認し、同期できなかったときの手動再試行も用意します。

画面を閉じても指定時刻に動く処理には、サーバーまたは外部サービスの定時実行基盤が候補になります。Cloudflare Workers Cron Triggersは定時実行機能の一例で、特定サービスの推奨ではありません。採用候補の公式資料で、許容遅延、時間帯、再試行、重複実行、監視、費用を確認します。

Webhookは外部サービスからイベントを受ける仕組みです。Stripeのwebhook公式資料では、公開HTTPS URLを登録し、署名を検証します。これはStripe固有の条件です。ほかのサービスでは到達先、認証、再試行、順序、重複の仕様を読み直します。

8つの短いサービス例

各例は完成構成ではありません。「必要候補」「不要にできる条件」「判断を変える条件」を同じ順で見ます。

端末内処理から始められる例

1. 単位換算・計算機

  • 必要候補：端末側の計算と表示
  • 不要にできる条件：計算式が固定で、保存・共有・秘密情報・外部APIがなければバックエンドとDBは不要
  • 判断を変える条件：利用者別履歴、共有、課金API、サーバーだけで管理する計算規則

2. 一端末の個人チェックリスト

  • 必要候補：端末側の処理と端末内保存
  • 不要にできる条件：一人・一端末だけで使い、消失を受け入れられるならバックエンド、認証、サーバーDBは不要
  • 判断を変える条件：端末紛失からの復旧、書き出し、複数端末、共有、機密データ

3. 問い合わせフォーム

  • 必要候補：送信先のバックエンド/関数またはフォーム・メールサービス
  • 不要にできる条件：外部サービスを送信先・正本とし、自前検索・履歴・再処理が不要なら自前DBは不要
  • 判断を変える条件：添付、スパム対策、受付番号、監査、保存期間、再送、権限別対応

4. 共有予約

  • 必要候補：バックエンド、共有正本のDB、認証認可、同時更新の競合制御
  • 不要にできる条件：常時オンラインなら端末内の業務データやオフライン同期は不要
  • 判断を変える条件：仮予約期限、決済、取消権限、通知、オフライン受付、監査・復旧

共有予約でDBを置く場合も、同時更新の方式まで決める必要があります。どの更新を受理するか、失敗をどう返すか、再試行で二重予約しないかを判断票に残します。

外部API・同期・画面外処理を含む例

5. 公開天気表示

  • 必要候補：天気サービスの公開API。条件によりクライアント直結またはバックエンド仲介
  • 不要にできる条件：ブラウザー利用が許可された認証情報だけで済むか認証情報が不要で、CORS条件を満たし、採用候補の利用回数上限・利用規約・費用を確認できれば自前バックエンドは不要
  • 判断を変える条件：秘密にすべきAPIキー、利用量統制、キャッシュ、課金保護、利用者別内容、障害時の代替

6. AIチャット

  • 必要候補：提供事業者のAPIキーを守るバックエンドとAIサービス
  • 不要にできる条件：履歴を残さず、リクエスト単位で完結し、提供事業者側のデータ保持条件を受け入れるなら自前履歴DBは不要
  • 判断を変える条件：利用者別履歴、検索、削除・書き出し、監査、利用上限、長時間処理

7. 複数端末・共同ノート

  • 必要候補：端末内データ、同期、利用者の識別、競合の解消、バックアップ
  • 不要にできる条件：一人・一端末に限定し、端末消失を受け入れるなら同期と共有用の識別は不要
  • 判断を変える条件：同時編集、共有範囲、履歴、別端末復旧、離脱者の権限、容量

8. 定時リマインダー

  • 必要候補：画面の稼働状態から独立した定時処理とメール・プッシュ通知などの基盤
  • 不要にできる条件：画面を開いている間だけの通知でよければ、サーバーの定時実行基盤を不要にできる場合がある
  • 判断を変える条件：ブラウザーを閉じても実行、厳密な時刻、再試行、時間帯、購読解除、配信記録

AIチャットでは、提供事業者のAPIキーを守るバックエンドと会話履歴のDBを同じ必須事項にしません。キーの保護は必要でも、履歴を残すかは別の要件です。

ステートレスとローカルファーストを誤解しない

  • ステートレス（stateless）なサーバーは、個々の処理拠点が前の要求に依存する状態を自分のメモリやディスクへ持たない構成です。製品全体がデータを持たない、という意味ではありません。
  • **ローカルファースト（local-first）**は、端末上のコピーを主要として扱い、オフライン利用や利用者による管理を重視する設計思想です。バックエンド、同期、利用者の識別、競合解消、バックアップが不要になるわけではありません。

HTTP自体はステートレスな通信規約ですが、それは各要求の意味を単独で理解できるということです。RFC 9110の定義を「製品に履歴やデータがない」と読み替えません。

ステートレスな処理でも、必要なセッションや業務データを外部のキャッシュやDBへ置けます。AWS Well-Architectedの指針はAWS上の構成例です。処理拠点を交換しやすくしても、外出し先の整合性、バックアップ、費用、責任者は残ります。

ローカルファーストの原典では、端末上のコピーを主要にしながら、複数端末を助ける補助コピーをサーバーに置く構成も説明しています。詳しくはInk & SwitchのLocal-first softwareで確認できます。複数端末では同期が必要になり、共同編集では競合、利用者の識別、履歴、バックアップを決めます。

同原典の試作品に関する知見は、5人の開発チームによる利用と約10人の外部利用者への探索的なテストに基づきます。同時編集の変更を統合する方式がうまくいったという結果を、すべてのデータモデル、規模、権限要件への保証として使いません。

マネージドサービスを使っても、利用者側の運用は残ります。AWS Shared Responsibility Modelでは、利用者側の責任は、選ぶサービス、連携、法令、用途によって変わります。

ほかの提供事業者では、バックアップ、書き出し、保存期間、削除の分担を契約と公式資料で確かめます。セキュリティ設定、障害対応、問い合わせ窓口、費用の責任者も必要です。

サーバーがあれば安全、DBがあれば正しい、端末内なら非公開、と決まるわけではありません。マネージドサービスや同期サービスを選んでも、運用や競合の検討は残ります。構成要素だけで判断を終えず、要件、設定、実装、テスト、運用と責任者まで確認します。

必要な仕組み判断票

判断票は、サービス全体ではなく一つの利用場面につき一枚作ります。各欄に「必要」「不要」「未決」の状態を書き、続けて「根拠｜確認責任者｜確認先｜期限」を一行で残します。値が分からない欄をAIに補完させません。

利用場面と処理

  • 利用場面：誰が、何を始め、どの結果で終わるか＿＿＿＿
  • 現行業務との境界：現在の担当、待ち・例外・二重入力、今回は変えない範囲＿＿＿＿
  • 利用者・端末：一人/複数人、単一/複数端末、全員同じ/利用者別＿＿＿＿
  • クライアント処理：端末で行う計算、入力、表示、端末内更新＿＿＿＿
  • サーバー処理：信頼できる側で行う検証、業務規則、仲介、集約＿＿＿＿

保存先と信頼境界

  • 保存先：ブラウザー/端末、サーバーDB、オブジェクトストレージ、外部サービス、保存なし＿＿＿＿
  • 正本：食い違ったときに基準とするコピーと責任者＿＿＿＿
  • 保存目的：終了後の保持、共有、検索、履歴、監査、復旧の要否＿＿＿＿
  • データの境界：個人情報、組織の基幹データ、既存ID・マスター・承認記録、外部へ渡すデータ＿＿＿＿
  • 秘密情報・決済：APIキー、認証情報、決済、改ざんされたくない規則と保管場所＿＿＿＿
  • 認証・認可：誰を識別し、どのデータ・操作をどこで許可/拒否するか＿＿＿＿
  • 外部サービス：API、フォーム、メール、AI、決済、認証の提供事業者とデータの扱い＿＿＿＿

接続と障害

  • オフライン：通信なしで読む/更新するデータと、利用不能時の表示＿＿＿＿
  • 同期・競合：再接続後の送信、重複防止、同時変更の統合/拒否、利用者の識別＿＿＿＿
  • 画面外の処理：定時処理、webhook、通知、長時間処理、再試行、重複実行＿＿＿＿
  • 障害・復旧：クライアント、サーバー、保存先、外部サービスが失敗したときの結果＿＿＿＿
  • 確認方法の引継ぎ：期待結果、権限差、重複更新、例外、締め・締切・期間境界、復旧を後続工程でどう確かめるか＿＿＿＿

運用と判断

  • データ運用：バックアップ、書き出し、保存期間、削除、復旧テスト＿＿＿＿
  • 費用・運用責任：費用上限、監視、主担当・副担当、仕様・変更記録、定期棚卸しの対象・時期・責任者、引継ぎ先、廃止条件＿＿＿＿
  • 相談・承認：管理職、IT、セキュリティ、個人情報担当など組織が定める相談先と承認状態＿＿＿＿
  • 未決：不明な事実、影響、確認責任者、確認先、期限＿＿＿＿
  • HOLD：止める工程、再開条件、承認者＿＿＿＿

端末内コピーとサーバーDBの両方を正本と書いたなら、同期して食い違ったときの規則が必要です。外部サービスを保存先にしたなら、書き出し・削除・保存期間・障害時の責任者が空欄でないかを見ます。

個人情報、組織の基幹データ、外部共有、認証連携、組織ポリシーの対象に触れる場合は、自部署だけで決めません。組織が定める相談先と承認状態を書き、確認が終わるまで実装や公開をHOLDにします。

記入例：共有予約

これは条件を置いた短い記入例です。複数人が各自の端末から同じ予約枠を予約し、常時オンラインで使う場面を想定します。予約と取消履歴は残し、予約枠のDBを正本にします。

オフライン受付はしません。確認メールは外部サービスから送り、保持期間と運営者の取消権限は未決とします。

  • クライアント処理：空き枠の表示、入力、送信、成功・失敗の表示
  • サーバー処理：本人確認の結果を受けた認可、空き枠の再確認、同時更新の制御、予約確定
  • 保存先・正本：サーバーDBの予約枠と予約記録。端末内には業務データを残さない
  • 秘密情報：メールサービスのAPIキーをサーバー側で保管
  • 認証・認可：利用者は自分の予約だけを取り消せる。運営者の取消権限は未決
  • 外部サービス：認証と確認メール。渡すデータ、保存期間、削除方法を確認
  • オフライン・同期：不要。通信できない間は受付せず、再読み込みを案内
  • 画面外の処理：予約確定後のメール送信。失敗時の再試行と重複送信防止が必要
  • 障害・復旧：確定結果が不明ならDBの正本を再取得。メール失敗で予約を取り消さない
  • 費用・運用責任：費用上限、監視、主担当・副担当、バックアップ責任者は未決
  • 不要にする仕組み：端末内DB、オフライン同期、添付用ストレージ
  • 未決・HOLD：保持期間、運営者の取消権限、費用上限、運用担当の承認までは実装をHOLD

後続工程には、同じ枠への同時予約、権限のない取消、メール失敗、DB障害からの復旧を確認条件として渡します。

受入条件は要件と受入条件で決めます。保存項目はERデータモデル設計、保護する操作は認証と認可の判断表で具体化します。

AIは調査し、人が決定する

AIには読み取り専用の調査を任せます。この工程ではコードや設定を変更させず、次を一覧にします。

  • 既存の画面遷移、APIの受付口、サーバー/関数、フォームの送信先
  • ブラウザーの保存領域、ファイル、DB、オブジェクトストレージ、外部サービスへの保存処理
  • 環境変数名や秘密情報の参照箇所。値そのものは読ませず、出力させない
  • 認証認可の判定候補と、クライアント側の表示制御だけになっている箇所
  • 定時実行、キュー、webhookの受付口、メール・通知処理
  • バックアップ、書き出し、保存期間、監視、費用設定、責任者が記録された場所
  • 既存記事・設計記録と、判断票の各欄に対応する根拠

AIの出力は「確認できた事実」「見つからなかったもの」「権限がなく確認できないもの」に分けます。見つからないことを「存在しない」と断定させません。秘密情報の値、個人データ、本番変更は調査対象に含めません。

人が決めるのは、保存するデータ、正本、アクセス権限です。許容する消失・遅延・競合や、外部サービスへ渡せるデータも人が判断します。費用上限、保存期間、最終責任者まで決まらなければ、実装へ進めずHOLDにします。

未決ならHOLDにする

誰が何台で使うか、正本、保存期間、削除、バックアップが未決なら、構成を確定できません。秘密情報、決済、認証認可、オフライン、同期、競合も同様です。

外部サービスの認証情報・データ保持・費用も確認します。定時処理の時刻・再試行・重複や責任者が未決で、答えによって構成が変わる場合はHOLDにします。

HOLDには「不明」だけでなく、影響、確認責任者、確認先、期限、再開条件を書きます。

次の記事へ渡す

  • 利用場面の目的と受入条件が未決なら、先に要件と受入条件を作ります。
  • 必要な役割が決まり、具体的なフレームワーク、DB、提供事業者を比べる段階で技術選定へ進みます。
  • HTMLをいつ生成し、どこでキャッシュするかはレンダリング方式で決めます。本記事の製品構成判断とは範囲が違います。
  • 決めたクライアント、バックエンド、DB、外部サービスの境界はC4システム図で図にします。
  • 保存する記録と関係はERデータモデル設計へ渡します。
  • クライアントとバックエンド、バックエンドと外部サービスの要求/応答はOpenAPI契約設計へ渡します。
  • 保護するデータと操作が決まったら認証と認可の判断表を作ります。
  • バックアップ、保存期間、復旧、性能、可用性は非機能要件で条件にし、監視と障害対応の責任者はサービス運用の最小設計へ渡します。

判断票のすべてが決まってから次へ進む必要はありません。未決が構成を変えないと確認でき、責任者と期限がある場合だけ、決まった範囲を後続記事へ渡します。

出典

本文で参照した資料だけをまとめます。いずれも2026-08-20に直接確認しました。