AIで作る高速CRUDアプリ：ダッシュボードと管理パネル、過剰設計なし

作るもの（および「過剰設計をしない」が意味すること）

CRUDアプリ、ダッシュボード、管理パネルはプロダクトの「バックオフィス」です：データが作成され、レビューされ、修正され、報告される場所。派手なUXは不要なことが多いですが、信頼性が高く、使いやすく、ビジネスが変わったときにすぐ変更できることが重要です。

こうしたツールに通常含まれるもの

大抵の管理系アプリは繰り返し使える小さなパーツに還元できます：

• リストとフィルタ（検索、ソート、ページネーション）
• 詳細ビュー（単一レコードの読み取り専用ページ）
• 作成/編集フォーム（バリデーションと妥当なデフォルト付き）
• 基本ワークフロー（承認/却下、アサイン、ステータス変更）
• ダッシュボード（いくつかのチャート、カウント、要対応テーブル）
• ロール/権限（閲覧 vs 編集 vs 削除の区別）

内部ツールやMVPの管理UIを作る場合、先にこれらの要素を正しく作ることが、先行的な高度なアーキテクチャを導入するより価値があります。

AIが最も役立つ領域

AIは繰り返し作業の高速かつ一貫したアシスタントとして使うと強力です：

• ボイラープレートの足場作り：CRUDルート、コントローラ、コンポーネント、フォーム
• 繰り返しパターン：リスト → 詳細 → 編集画面を毎回同じ方法で生成
• UI文言：ラベル、空状態、ヘルパーテキスト、確認メッセージ
• 抜け漏れの指摘："ページネーションは？" "削除はソフトデリート？"

AIはシステム全体を設計する万能の占い師ではないので、明確な構造を与えてギャップを埋めさせる方が良い結果になります。

実務での「過剰設計をしない」の意味

「過剰設計をしない」は 安全で保守可能な最もシンプルなバージョンを出す ことへのコミットです：

• 深い抽象化レイヤーやカスタムフレームワークよりも デフォルト を優先する。
• 今日のフロー を対象に作り、仮説上の将来フロー用に作りこまない。
• データと権限は 明示的 に保つ（「賢い」仕組みで隠さない）。
• 変更速度 を最適化する：新しいフィールドやステータスを追加するのが小さく予測可能な編集で済むこと。

このアプローチが向いている人

この方法は 小さなチーム、創業者、プロダクトチーム が内部ツール、運用コンソール、MVP管理パネルを今週中に動かしたいときに特に適しています。

タイトなスコープを定義する：エンティティ、ユーザー、少数の主要フロー

速さは「何を作らないか」を決めることから来ます。AIに何かを生成させる前に、実際に必要な管理作業に合わせて狭いスコープを固定してください。

1) 3–5のコアエンティティを選ぶ

アプリが管理すべき最小の「もの」を選びます。各エンティティについて、存在理由と誰が触るのかを一文で書いてください。

例（あなたのドメインに置き換えてください）：

• Customer — ビジネスがサービスする相手
• Order — 顧客が購入するもの
• Product — 販売可能な商品
• Invoice — 請求されるもの
• User — 管理にアクセスできる人

次に必須の関係だけを書き留めます（例: Order → Customer、Order → many Products）。AuditEvent、FeatureFlag、WorkflowStep のような「将来用」エンティティは初日から必要でない限り避けてください。

2) 必須の管理タスクを列挙する

管理パネルは画面ではなくアクションが重要です。プロジェクトの価値を生むごく少数のタスクを書いてください：

• レコードの作成/編集
• レビューと承認（または却下）
• 検索とフィルタ
• 財務/運用向けのCSVエクスポート
• 例外の解決（返金、キャンセル、再同期）

週次の実業務に結びつかないタスクはオプションの可能性が高いです。

3) 成功指標を定める

単純な目標を設定して進捗を測ります：

• 初画面表示までの時間（例：30–60分）
• 初回デプロイまでの時間（同日）
• 実際のタスク完了までの時間（例：注文を承認する）

4) 「今はやらない」リストを作る

マルチリージョン、カスタムレポートビルダ、凝ったロール階層、イベントソーシング、プラグインシステムなど、意図的にスキップする項目を書き出します。これを /docs/scope.md に入れて、全員（とAIプロンプト）が同じ認識を持てるようにしてください。

単純なスタックを選び、デフォルトに従う

速さは予測可能性から来ます。最速のCRUDアプリは「退屈な」技術で構築され、デプロイやデバッグ、採用が容易です。

自信を持ってデプロイできるスタックを選ぶ

ひとつの実績ある組み合わせを選んでプロジェクト中はそれに固執します：

• バックエンド: Rails, Django, Laravel, Express/Nest, または ASP.NET Core（チームが普段使っているもの）
• データベース: Postgres（デフォルト）、または社内標準のMySQL
• ホスティング: 既に使っているプラットフォーム（Render/Fly/Heroku/Vercel/AWS）で、本番までの明確な道筋を持つ

実務ルール：Hello, auth + DB migration アプリを1時間以内にデプロイできないなら、そのスタックは迅速な管理ツール向きではありません。

スタックを自分で配線したくない場合（特に内部ツール）は、Koder.ai のようなビブコーディングプラットフォームがチャットからワーキングベースラインを生成してくれることがあります。通常は React フロントエンドと Go + PostgreSQL バックエンドの組み合わせを生成し、必要に応じてソースをエクスポートできます。

カスタムフレームワークよりスキャフォールドを優先する

AIは主流の慣習に沿っていると効果的に穴を埋めます。ジェネレータとデフォルトに頼ると早く進めます：

• フレームワークの公式の認証、マイグレーション、ORM、ルーティングを使う。
• 独自のコンポーネントライブラリを作る代わりに標準のUIキット（またはフレームワーク付属の管理ツール）を使う。

スキャフォールドが地味に見えても問題ありません。管理パネルは派手さよりも明快さと安定性で成功します。

サーバーサイドレンダリング vs SPA の判断（スキルに基づいて）

• サーバーサイドレンダリング（Rails/Django/Laravel）: CRUD、フォーム、バリデーション、権限で最速—動く部品が少ない。
• SPA（React/Vue + API）: チームがすでに得意で、豊かなクライアント側インタラクションが本当に必要な場合に限定。

迷ったらサーバーサイドレンダリングを選びましょう。後から小さなリアクティブウィジェットを追加できます。

CRUDが動くまでは統合を最小限にする

初期にイベントバス、マイクロサービス、複雑なキュー、マルチテナント設計を追加するのは避けます。コアエンティティ、リスト/詳細/編集フロー、基本ダッシュボードが動いてから統合を増やす方が安全です。

画面を生成する前にデータをモデリングする

AIに綺麗なCRUD画面を生成させたいなら、まずデータを設計してください。画面はモデルの表現です。モデルが曖昧だとUI（及び生成コード）は不整合になりやすい：フィールド名の不一致、混乱するフィルタ、「謎の」関係など。

ページではなくテーブル／コレクションから始める

管理パネルが扱うコアエンティティをリストアップし、各エンティティについて主要フローを支える最小限のフィールドを定義します。

ルール：リストビュー、詳細ビュー、レポート、権限に影響しないフィールドはv1では不要の可能性が高いです。

早すぎる正規化を避ける

正規化は有用ですが、あまりにも早く何でも別テーブルに分けると進行が遅くなり、生成されるフォームが扱いにくくなります。

シンプルに保ちましょう：

• 実際に関係が必要な場合のみ外部キーを使う（例：order.customerId）。
• 多数の「完璧な」テーブルより少数の明確なテーブルを優先する。
• 参照テーブル（ステータス、タグ等）はアプリが価値を証明してから追加する。

初日から監査フィールドを計画する

管理ツールにはトレーサビリティがほぼ必須です。監査フィールドを最初から加えておけば、生成画面に一貫性が生まれます：

• createdAt, updatedAt
• createdBy（任意で updatedBy）

これで責任追跡、変更レビュー、トラブルシューティングが簡単になります。

AIが扱いやすい一貫した命名を使う

スキーマが予測可能だとAI出力が綺麗になります。ひとつの命名スタイルを決めて守りましょう（例：camelCase、単数形のエンティティ名）。

例：customerId か customer_id のどちらかを決めて全体に適用すると、生成されるフィルタ、フォーム、バリデーションが自然に揃います。

一貫性・保守性のあるコードを出すプロンプトを書く

AIは大量のコードを迅速に生成できますが、再利用可能なプロンプト構造がないと命名不整合やバリデーションのばらつき、ほぼ同じパターンの散在が生まれ保守が大変になります。AIを規律あるチームメイトのように振る舞わせるのが目標です：予測可能で、スコープが決まり、同じ計画に沿うこと。

再利用できる「アプリブリーフ」を最初に作る

毎回の生成プロンプトに貼る短いドキュメントを作り、バージョン管理します。

ブリーフに含めるもの：

• 目的：管理パネルが果たす役割（1文）
• ユーザー/ロール：誰が使い何ができるか
• エンティティ：少数のテーブル/リソースと関係性
• 主要フロー：重要なアクション（例：「注文作成、返金、顧客履歴の閲覧」）

チャット駆動のビルダー（例：Koder.ai）を使う場合、このブリーフをプロジェクトの「system prompt」として扱い、各画面生成で同じ制約に基づくようにします。

コード生成前にファイル単位の計画を要求する

生成前にAIに具体的な設計図を出させます：追加/変更するファイル、各ファイルの内容、想定している前提条件。

その計画がチェックポイントとなります。ファイルリストが多すぎる、抽象化が過剰、知らない新フォルダが含まれるなど不適切なら計画を修正してからコード生成に進みます。

一貫性を強制する制約を付ける

保守性は制約から生まれます。次のようなルールを明示してください：

• 命名規則：単数/複数、ケーシング、ルートパターン、コンポーネント名
• バリデーション：必須フィールド、最小/最大、フォーマット、サーバーエラーの扱い
• 一覧の振る舞い：ページサイズ、デフォルトソート、許可フィルタ、空状態
• APIの形：レスポンスの封入、エラー形式、IDの型（UUIDか整数か）

どこでも「退屈なデフォルト」を明示することで、すべてのCRUD画面が同じシステムの一部に見えるようになります。

プロンプトドリフトを防ぐための決定ログを残す

「ユーザーはソフトデリート」「支払い済みの注文は編集不可」「デフォルトページサイズ25」などの選択を都度書き留め、関連する行を将来のプロンプトに貼り付けます。

これが、前の画面と後の画面で微妙に挙動が変わってしまうのを防ぐ最も簡単な方法です。

便利な構成は三つの再利用ブロック：App Brief, Non-Negotiable Constraints, Current Decisions (Changelog)。これで各プロンプトが短く、再現性があり、誤解されにくくなります。

繰り返せるパターンでCRUD画面を生成する

速さは「賢さ」ではなく「反復」から来ます。CRUDをプロダクト化されたパターンとして扱い、毎回同じ画面構成、同じコンポーネント、同じ挙動を使います。

一つのエンティティを端から端まで仕上げる

まず単一のコアエンティティ（例：Orders, Customers, Tickets）を選び、完全なループを生成します：list → detail → create → edit → delete。途中で5つのエンティティを中途半端に生成しないこと。完成したセットが他の画面の基準になります。

毎回同じ画面パターンを使う

各エンティティは一貫した構造に従います：

• リストページ: テーブル + フィルタ + プライマリアクション（"New ..."）
• 詳細ページ: 読み取り専用サマリ + 関連項目 + アクション（"Edit", "Archive/Delete"）
• 作成/編集: モード（create vs edit）を切り替える共通フォームコンポーネント

テーブル列（例：Name/Title、Status、Owner、Updated、Created）やフォームコンポーネント（テキスト入力、セレクト、日付ピッカー、テキストエリア）を標準化すると、AI出力のレビューが容易になりますしユーザーの学習も早いです。

最初から「退屈な」状態を用意する

CRUD画面がプロフェッショナルに見えるのは現実的な状態を正しく扱うときです：

• 空状態: 何が足りないか説明し次の手順を提示する（"最初の...を作成"）
• 読み込み状態: スケルトン/プレースホルダ、アクション無効化
• エラーメッセージ: フレンドリーな要約 + フィールドレベルでの対処可能なエラー

これらの状態は繰り返し発生するため標準化して再利用するのに最適です。

再利用できるプロンプトテンプレート

Generate CRUD UI for entity: <EntityName>.
Follow existing pattern:
1) List page: table columns <...>, filters <...>, pagination, empty/loading/error states.
2) Detail page: sections <...>, actions Edit/Delete with confirmation.
3) Create/Edit form: shared component, validation messages, submit/cancel behavior.
Use shared components: <Table>, <FormField>, <Select>, <Toast>.
Do not introduce new libraries.

最初のエンティティが望ましい形になったら、同じレシピを最小限の差分で他のエンティティにも適用します。

複雑化せずに認証と権限を追加する

認証と権限は「素早い管理ツール」が見えないうちに大きなプロジェクトに変わりやすい箇所です。目的は単純：正しい人が正しい画面やアクションにアクセスできるようにする—しかし完全なセキュリティフレームワークを発明する必要はありません。

まずは三つのロールから（ロールの増えすぎを避ける）

最初は小さなロールモデルにとどめ、具体的な必要が出てきたら拡張します：

• Admin: フルアクセス（ユーザー/ロール管理含む）
• Editor: レコードの作成と更新が可能
• Viewer: 読み取り専用

新しいロール提案が出たら、"今日ブロックされている単一の画面またはアクションは何か？" と問うと多くの場合レコードレベルのルールで足ります。

まずルートレベルのアクセス、次にレコードレベルのルール

権限は二層で行います：

1. ルートレベルのアクセス: セクション全体をゲートする（例：/admin/users は Adminのみ、/admin/reports は Admin+Editor）。
2. レコードレベルのルール: ページ内でユーザーができることを制限する（例：Editorは自チームのレコードのみ編集できるが削除はできない）。

ルールはデータモデルに近い場所で明示的に定義することが重要です："このレコードを誰が読める/更新できる/削除できるか？" が例外の長いリストより良い。

既存の認証プロバイダを使う

会社ですでに Google Workspace, Microsoft Entra ID, Okta, Auth0 等を使っているならSSOを統合し、クレーム/グループを3つのロールにマップしてください。自前のパスワード管理や "ログインを自作" は特別な事情がない限り避けます。

重要な操作を監査する

基本的な管理パネルでも敏感なイベントはログに残すべきです：

• 削除（特に一括削除）
• ロール変更や権限編集
• データエクスポート

誰が、いつ、どのアカウントから、何を変更したのかを保存しておくとデバッグやコンプライアンス、安心感に役立ちます。

実用的なダッシュボードを作る

良い管理ダッシュボードは「ホームページ」ではなく意思決定ツールです。データベースが知っていることを全て可視化しようとすると過剰構築の近道です。代わりに、オペレータが30秒以内に回答を得たい問いをいくつか書き出してください。

アクションを促す少数の指標を選ぶ

5–8の主要指標 を目標にし、それぞれが今日誰かの行動につながるものにします。例：

• 本日作成されたアイテム（先週比）
• レビュー待ちアイテム
• 決済失敗 / エラー数
• 平均滞留時間（pending）
• ボリューム上位の担当者／キュー

指標が行動を変えないなら、それはレポートで十分です。

まずはフィルタ、その次にビジュアル

ダッシュボードはスライスできると賢く見えます。ウィジェットに共通のフィルタをいくつか用意してください：

• 期間（Today / 7 days / 30 days / Custom）
• ステータス（open, pending, completed）
• 担当者（assignee, team, region）

デフォルトは妥当な値（例：過去7日）にして、フィルタを保持する（sticky）ようにするとユーザーの手間が減ります。

チャートより先にテーブルを出荷する

チャートは有用ですが集計方法や軸のフォーマット等で追加作業が発生します。ソート可能なテーブルと合計があれば多くの場合早く価値を出せます：

• Top 10 テーブル（カウント付き）
• Latest 20 テーブル（レコードへのクイックリンク付き）

チャートを追加する場合はオプションであり、出荷の障害にしないでください。

エクスポートは慎重に扱う

CSVエクスポートは便利ですが権限のある操作として扱います：

• 生成前に権限チェックを行う
• ダッシュボードのフィルタと同じ条件を適用する
• 誰がいつエクスポートしたかをログに残す

管理体験の一貫性を保つ方法については /blog/common-overengineering-traps を参照してください。

保護措置：バリデーション、セキュリティの基本、そして安全なデフォルト

速さは重要ですが、運用上安全でなければ意味がありません。CRUDアプリや管理パネルでは小さなガードレールで多くの現実世界の問題を防げます—重厚なアーキテクチャを足す必要はありません。

バリデーション：UXはクライアント、真理はサーバー

UIでは入力チェックを行いUXを改善します（必須、フォーマット、範囲など）が、サーバー側のバリデーションを必須にしてください。クライアントは簡単に迂回できます。

サーバー側で強制するもの：

• 型と制約（例：整数ID、最大長）
• ビジネスルール（例：ステータス遷移）
• 正規化（文字列のトリム、一貫した大文字小文字）

AIにエンドポイント生成を依頼する際は、共有バリデーションスキーマ（または共有できないスタックなら複製したルール）を明示的に要求してください。そうすればフォームとAPIのエラーが一致します。

一貫したページネーション、ソート、検索

一覧の挙動がバラバラだと管理UIは壊れます。1つのパターンを選んで全体に適用してください：

• page + pageSize（本当に必要ならカーソルページネーション）
• sortBy + sortDir（ソート可能フィールドの許可リストを持つ）
• 単純なテキスト検索は q、必要なら構造化フィルタも追加

予測可能なレスポンスを返す：{ data, total, page, pageSize }。これで生成されたCRUD画面が再利用しやすく、テストもしやすくなります。

よくある攻撃への対策

頻度の高いリスクに集中します：

• インジェクション：常にパラメタライズドクエリ/ORMを使い、SQLを文字列連結しない。
• IDOR（Insecure Direct Object Reference）：管理権限だけでなくレコードごとに権限をチェックする。
• 情報過剰露出：内部フィールド（トークン、内部ノート、PII）はデフォルトで返さない。

またデフォルトを安全にします：deny by default、最小権限ロール、センシティブなエンドポイントへの保守的なレート制限。

シークレットと設定はリポジトリに置かない

シークレットは環境変数かデプロイ先のシークレットマネージャに保存します。非センシティブなデフォルトだけをコミットしてください。

ワークフローに簡単なチェックを追加：.env を .gitignore に入れる、.env.example を用意する、CIでの“コミットにシークレットがないか”の簡単なスキャン（正規表現ベースでも有効）を行うようにします。

品質を落とさずに速度を保つ：テスト、リンティング、CI

速く出すだけでなく「出すたびに壊さない」ことも重要です。軽量な品質チェックを入れて明らかな回帰を捕まえつつ、CRUDアプリを科学プロジェクトにしないことがコツです。

高価値のスモークテストの小さいスイート

管理アプリで致命的になるフローに集中します。多くの場合は：

• ログインが機能し正しくリダイレクトされる
• メインのリストページが読み込まれる
• 作成 → 保存 → リストで確認できる
• 編集 → 保存 → 変更が持続する
• 権限：低権限ユーザーがAdmin-onlyルートにアクセスできない

これらはエンドツーエンドか「API + 最低限のUI」で行い、目標は合計5–10テスト程度にすること。

AIをテスト草案に使い、その後簡素化する

AIは第一稿のテストを作るのが得意ですが、過剰なエッジケースやモック、壊れやすいセレクタを生成しがちです。生成物を取って次のように手直しします：

• 重複を削除する
• 安定したセレクタ（data-testid 等）を使う
• 過度なモッキングを避け、可能なら実際のルート/サービスを使う
• 失敗時に読みやすい（分かりやすい名前とアサーション）ようにする

リンティング、フォーマット、プリコミットチェック

コードベースを編集しやすく保つための自動化を入れます—特にコードをまとめて生成する場合は重要です。

最低限：

• フォーマッタ（Prettier / Black 等）
• リンター（ESLint / Ruff 等）
• TypeScriptを使っているなら型チェック
• プリコミットフックで高速チェック（フォーマット + リント）だけを実行

これでスタイル議論を減らし、差分ノイズを抑えられます。

プッシュごとに回る基本的なCI

CIは正しくても早くなければ無視されます。CIでやることは3つに絞ります：

1. 依存関係のインストール
2. リント/型チェックの実行
3. スモークテストの実行

所要時間は数分に抑えましょう。遅くなると誰も見なくなります。

早く出荷する：デプロイ、シードデータ、モニタリング

早く出して使ってもらうのが、管理パネルが実際に使えるかを学ぶ最速の方法です。シンプルなパイプラインを目指してください：コードをプッシュ→ステージングにデプロイ→主要フローを手で確認→本番に昇格。

ステージング環境を早期に用意する

初日から staging（内部）と production（実運用）を分けて用意します。ステージングは本番と同じ設定を反映させますがデータは別にします。

デプロイは退屈で良い：

• 1コマンドまたは1つのCIジョブでデプロイ
• 環境変数は1か所で管理
• URLスキームは予測可能に（別ホストを使う）

最小構成の参考には既存のデプロイ方法を使い、 /docs/deploy に手順を書いて誰でも繰り返せるようにします。

Koder.ai のようなプラットフォームを使うと、組み込みのデプロイ/ホスティングを利用してカスタムドメインを付け、スナップショットとロールバックでリリースを取り消しやすくすることでさらに早く出せます。

シードデータでフローをすぐ検証する

シードデータがあると「コンパイルできた」だけでなく「使える」状態になります。目的は主要画面が意味を持つようにすることです。

良いシードデータの条件：

• 小規模（数十行程度）
• 現実的（ステータス値、タイムスタンプ、境界ケースを含む）
• 繰り返し可能（ワイプ + リシードが数秒で終わる）

少なくとも各主要状態のサンプルを含める（例：アクティブ/非アクティブのユーザー、支払い済/未払いの請求書）。これでデプロイ直後にフィルタ、権限、ダッシュボードの合計を確認できます。

エラーとパフォーマンスの基本を計測する

オブザーバビリティを完璧にする必要はありません。以下をまず揃えます：

• サーバー側エラートラッキング（未捕捉例外、失敗したジョブ）
• 遅いエンドポイントのリクエストタイミング（p95レイテンシ）
• フロントエンドのエラーログ（壊れた画面の検出）

少数のアラートだけに絞る："エラー率急増"、"アプリがダウン"、"DB接続枯渇"。それ以外は後回しで良いです。

シンプルなロールバック戦略を計画する

ロールバックは手作業ではなく機械的にできるようにします。選択肢の例：

• 前のビルドを再デプロイする
• 最後のリリースアーティファクトを保持して切り替える

データベース変更は付け焼き刃を避け、加算的マイグレーションを好み破壊的変更は機能が証明されるまでやらないこと。壊れたときに数分で実行できるロールバックがベストです。

よくある過剰設計の罠（と回避法）

管理パネルが「プラットフォーム」を名乗り始めると速度は失速します。CRUDアプリの目標は単純です：明快な画面、信頼できる権限、質問に答えるダッシュボードを出荷し、実際の利用に基づいて反復すること。

早期に警戒すべきレッドフラッグ

これらのパターンが見えたら、実装を進める前に立ち止まってください：

• 抽象化が多すぎる：BaseRepositoryFactory、GenericServiceLayer、ホームメイドのフレームワークを機能1つ出す前に作る。
• カスタムUIキット：テーブル、フォーム、モーダル、バリデーションを再構築する代わりに既存を使う。
• 汎用エンジン：ワークフローエンジンやルールエンジン、設定可能な管理ビルダーを3–5のフローで作るのは過剰。
• 早すぎる最適化：キャッシュ、キュー、イベントバスをボトルネックを計測せずに導入する。
• マルチテナントやプラグインアーキテクチャ：もしMVPが1チーム・1データセットなら不要。

リファクタの判断基準（やるべき時・やらない時）

リファクタは「繰り返し痛みがあるとき」に行います。

良いトリガー：

• 同じロジックを3箇所以上変えたのに1つ漏れていた。
• 新しいCRUD画面の作成が毎回前より遅くなる共通理由がある。
• バグがある領域（権限、バリデーション、集計クエリ）に集中している。

悪いトリガー：

• "将来マイクロサービスが必要かも"。
• "このコントローラが大きすぎる気がする"（ただし滅多に変わらず動作している場合）。

意図的に「Later」バックログを保持する

キャッシング、マイクロサービス、イベントストリーミング、バックグラウンドジョブ、監査ログUIの磨き込み、高度な検索などは Later に入れておき、利用が実証されたら再検討します。

事前の複雑化チェックリスト

新しい層を追加する前に自分たちに問うべきこと：

1. 今週このユーザ問題を解くか？
2. セキュリティとデータ整合性を満たす最もシンプルなバージョンは何か？
3. 時間・コスト・レイテンシのボトルネックを測定したか？推測か？
4. フレームワークのデフォルトと一つの明確なパターンでできるか？
5. 今やらないと何が壊れるか？壊れるものが無ければ多分「Later」で良い。