必須ではありませんが、先に目を通しておくとスムーズに進められるレッスンがあります。
atom.nocode-builder.design-error-handling
失敗時の処理を設計する
失敗時の処理を設計する あなたが作ったアプリで、ボタンを押したのに画面が真っ白になる――そんな体験をしたことはありませんか? レストランにたとえてみましょう。注文した料理がいつまでも出てこないとき、何も言われなけれ...
成果物成果物このレッスンが終わったとき、あなたの手元に残る具体的な成果物です(例: 公開済みの Web ページ、動作するフォームなど)。
証跡証跡成果物が正しく作れたことを確認するためのチェックリストです(例: ブラウザで動作する、フォーム送信で値が保存される)。
メディアメディアレッスン内に出てくる図や動画のスロットです。実際の画面やイメージで理解を補助します。
レッスン本文
失敗時の処理を設計する
あなたが作ったアプリで、ボタンを押したのに画面が真っ白になる――そんな体験をしたことはありませんか?
レストランにたとえてみましょう。注文した料理がいつまでも出てこないとき、何も言われなければ不安ですよね。でも店員さんが「あと5分でお持ちします」と声をかけてくれたら、安心して待てます。アプリでも同じです。何かがうまくいかなかったとき、ユーザーに「何が起きたか」と「次にどうすればいいか」をセットで伝える仕組みがあると、ユーザーは安心してアプリを使い続けられます。
このレッスンでは、あなたのノーコード(=プログラミングなしでアプリを作る方法)ツールで「失敗が起きたときの対応」を洗い出し、AIツールの力を借りて 1枚の設計メモ にまとめます。

前提を確認する
このレッスンを始める前に、次の2つが当てはまるか確認してください。
- ノーコードツール(Bubble、Glide、AppSheet など)で画面やワークフロー(=処理の流れ)を1つ以上作ったことがある
- AIツール(ChatGPT、Claude など)に質問して回答を受け取ったことがある
どちらも当てはまらない場合は、まず「業務プロセスを整理する」レッスンから始めると進めやすいです。プログラミングの知識は一切不要です。
ステップ1: アプリの流れを書き出す
まず、あなたのアプリが「ユーザーが開いてからゴールに着くまで」にどんなステップを通るかを、3〜5個で書き出します。
良い例
- 「ログイン画面 → 入力フォーム → 確認画面 → 送信 → 完了画面」のように具体的なページ名で列挙する
悪い例
- 「画面があって、ボタンがある」のように曖昧なまま次に進む
まだ流れが固まっていなくても大丈夫です。「画面は3つくらい」「最後にデータを保存する」くらいのラフなメモで十分です。
ステップ2: 失敗ポイントをAIに聞いて見つける
書き出した流れをAIツールに見せて、「どこで失敗しそうか」を教えてもらいます。次のプロンプト(=AIへの質問文)をコピーして、あなたのアプリ情報を埋めてください。
あなたはノーコードアプリの品質チェック担当です。
次のアプリの流れを読んで、ユーザーが困りそうな「失敗ポイント」を5つ挙げてください。
それぞれ、なぜ失敗するのかの理由も1行で添えてください。
【アプリの流れ】
1. (ここにステップ1で書き出した流れを貼る)
2. ...
3. ...
AIが返してきた5つのポイントを見て、「たしかにここは危ないな」と思うものを 3つ に絞りましょう。最初から全部に対応しようとすると終わらないので、影響が大きい順に3つで十分です。

ステップ3: 対応パターンを選ぶ
絞り込んだ3つの失敗ポイントそれぞれに、「ユーザーにどう伝えるか」を決めます。対応パターンは大きく3つです。
| パターン | いつ使うか | メッセージ例 |
|---|---|---|
| もう一度やってもらう | 通信エラーなど一時的な問題のとき | 「接続できませんでした。もう一度送信ボタンを押してください」 |
| 別の方法を案内する | その機能自体が使えないとき | 「現在メンテナンス中です。お急ぎの場合はこちらのフォームからご連絡ください」 |
| 入力を直してもらう | ユーザーの入力ミスのとき | 「メールアドレスに @ が含まれていません。もう一度ご確認ください」 |
良い例
- 「送信に失敗しました。入力内容はそのまま残っています。もう一度『送信』を押してください」→ 何が起きたか+データは消えていないという安心+次のアクションの3点セット
悪い例
- 「エラーが発生しました」→ 何が起きたか分からず、何をすればいいかも分からない
- 「Error 500: Internal Server Error」→ 技術用語はユーザーを不安にさせるだけ
AIに対応メッセージを考えてもらう
メッセージの文面もAIに手伝ってもらえます。次のプロンプトを使ってください。
次の3つの失敗ポイントについて、それぞれユーザーに表示するエラーメッセージを考えてください。
条件:
- 専門用語を使わない
- 「何が起きたか」と「次にどうすればいいか」を必ず両方含める
- 1メッセージ50文字以内
失敗ポイント:
1. (ここに1つ目の失敗ポイント)
2. (ここに2つ目の失敗ポイント)
3. (ここに3つ目の失敗ポイント)
ステップ4: 設計メモをAIと一緒にまとめる
ここまで集めた情報を、1枚の設計メモにまとめます。次のプロンプトをAIツールに貼り付けてください。
次の情報をもとに、エラー対応の設計メモをマークダウン形式で作成してください。
見出しは「アプリ名」「アプリの流れ」「失敗ポイント一覧」「各ポイントの対応方針とメッセージ」の4つにしてください。
アプリ名: [あなたのアプリ名]
アプリの流れ:
1. [ステップ1]
2. [ステップ2]
3. [ステップ3]
失敗ポイントと対応:
- ポイント1: [内容] → 対応パターン: [もう一度/別の方法/入力修正] → メッセージ: [考えた文面]
- ポイント2: [内容] → 対応パターン: [もう一度/別の方法/入力修正] → メッセージ: [考えた文面]
- ポイント3: [内容] → 対応パターン: [もう一度/別の方法/入力修正] → メッセージ: [考えた文面]
AIが出力したドキュメントをコピーして、手元のファイル(メモ帳やGoogleドキュメントなど)に保存してください。これがあなたの 成果物 です。
検証する
設計メモが完成したら、次の3つのチェックポイントを確認しましょう。
- すべての失敗ポイントに対応方針が書かれているか ― 漏れがあれば追記する
- メッセージに専門用語が入っていないか ― 家族や友人に読んでもらって「意味が分かる」と言ってもらえるか試す
- 「次にどうすればいいか」が必ず書かれているか ― 各メッセージに具体的なアクション(「もう一度押す」「別のフォームを使う」など)が含まれているか
3つともパスしたら、このレッスンは完了です。
つまずき対策
| こんなとき | こうしてみましょう |
|---|---|
| 失敗ポイントが多すぎて終わらない | 影響が大きい順に3つだけ選ぶ。残りは後日追加すれば大丈夫です |
| AIの回答が難しすぎる | 「小学生にも分かる言葉で書き直してください」と追加で聞いてみてください |
| そもそもアプリの流れが決まっていない | まず画面を3つだけ決めて、その間の移動を矢印で書くところから始めましょう |
| どのパターンを選べばいいか分からない | 迷ったら「もう一度やってもらう」を選んでおけば、たいていの場合で無難です |
| エラーメッセージの文面が思いつかない | ステップ3のAIプロンプトを使えば、複数の候補を出してもらえます |
種類: markdown_doc
検証: basic_manual_check_v1
証跡証跡成果物が正しく作れたことを確認するためのチェックリストです(例: ブラウザで動作する、フォーム送信で値が保存される)。
メディア