メインコンテンツへスキップ
レッスン一覧に戻る
このレッスンの前に学ぶと理解しやすい関連レッスン

必須ではありませんが、先に目を通しておくとスムーズに進められるレッスンがあります。

atom.nocode-builder.design-error-handling

失敗時の処理を設計する

失敗時の処理を設計する あなたが作ったアプリで、ボタンを押したのに画面が真っ白になる――そんな体験をしたことはありませんか? レストランにたとえてみましょう。注文した料理がいつまでも出てこないとき、何も言われなけれ...

design-error-handling-docdesign-error-handling-doc「design error handling doc」に関するスキルがこのレッスンで身につきます。
想定時間未設定公開状態: draft
学習メモ

成果物成果物このレッスンが終わったとき、あなたの手元に残る具体的な成果物です(例: 公開済みの Web ページ、動作するフォームなど)。

種類: markdown_doc検証: basic_manual_check_v1

証跡証跡成果物が正しく作れたことを確認するためのチェックリストです(例: ブラウザで動作する、フォーム送信で値が保存される)。

screenshot

メディアメディアレッスン内に出てくる図や動画のスロットです。実際の画面やイメージで理解を補助します。

diagramscreen_capture

レッスン本文

失敗時の処理を設計する

あなたが作ったアプリで、ボタンを押したのに画面が真っ白になる――そんな体験をしたことはありませんか?

レストランにたとえてみましょう。注文した料理がいつまでも出てこないとき、何も言われなければ不安ですよね。でも店員さんが「あと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つで十分です。

AIで失敗ポイントを洗い出す画面

ステップ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つのチェックポイントを確認しましょう。

  1. すべての失敗ポイントに対応方針が書かれているか ― 漏れがあれば追記する
  2. メッセージに専門用語が入っていないか ― 家族や友人に読んでもらって「意味が分かる」と言ってもらえるか試す
  3. 「次にどうすればいいか」が必ず書かれているか ― 各メッセージに具体的なアクション(「もう一度押す」「別のフォームを使う」など)が含まれているか

3つともパスしたら、このレッスンは完了です。

つまずき対策

こんなときこうしてみましょう
失敗ポイントが多すぎて終わらない影響が大きい順に3つだけ選ぶ。残りは後日追加すれば大丈夫です
AIの回答が難しすぎる「小学生にも分かる言葉で書き直してください」と追加で聞いてみてください
そもそもアプリの流れが決まっていないまず画面を3つだけ決めて、その間の移動を矢印で書くところから始めましょう
どのパターンを選べばいいか分からない迷ったら「もう一度やってもらう」を選んでおけば、たいていの場合で無難です
エラーメッセージの文面が思いつかないステップ3のAIプロンプトを使えば、複数の候補を出してもらえます
成果物成果物このレッスンが終わったとき、あなたの手元に残る具体的な成果物です(例: 公開済みの Web ページ、動作するフォームなど)。

種類: markdown_doc

検証: basic_manual_check_v1

証跡とメディア

証跡証跡成果物が正しく作れたことを確認するためのチェックリストです(例: ブラウザで動作する、フォーム送信で値が保存される)。

screenshot

メディア

diagramscreen_capture
学習完了