エラーの言葉を人の言葉にする：「失敗しました」の言い換え

「失敗しました」に足りない3つのもの

「失敗しました」は事実を伝えているようで、読む人が知りたいことをほとんど含んでいません。足りないのは次の3つです。

1. 何が起きたか：どの操作の、どの部分で止まったのか。
2. 何が無事か：入力した内容や進行は残っているのか。
3. 次に何をするか：自分で直せるのか、待てばよいのか、問い合わせるべきなのか。

3つのうち、2番目は見落とされがちです。失敗の言葉を読んだ人が最初に不安になるのは、たいてい「さっきまでの作業は消えたのか」だからです。原因の説明より先に、無事なものを一言で伝えるほうが、落ち着いて次の行動を選べます。

加えて、主語にも気をつけます。「ファイルが不正です」は読む人を責める響きになります。「このZIPでは入口のファイルが見つかりませんでした」と、物を主語にすれば、人を主語にせずに同じ内容を伝えられます。

ゲームの中の失敗は、次の行動つきで設計されている

公式作品には、失敗を「行き止まり」にしない設計が見られます。確認済みの範囲で、設計から読み取れることを挙げます。

• こだまの森：間違いは30点減で、3回で終了します。聴き直しは15点減です。失敗に点数という具体的な重さがつき、間違えたときの選択肢（聴き直す、続ける、一時停止する）も用意されています。読み取れるのは、失敗がゲームの一部として数えられ、取り返し方まで含めて設計されていることです。
• 紙ひこうき郵便：風船にぶつかると紙が傷み、3回で終了します。「傷む」という表現は、失敗を「あと何回で終わるか」という残りの数と結びつけます。
• 月夜の配達：燃料は有限で、1区間で燃料1を使います。バッグは2枠です。ヒントと「一歩戻る」があり、行き詰まっても進み方を探せる作りです。
• 潮目のオセロ：置けない手番は自動でパスになります。「置けません」と止めるのではなく、手番を先へ進めます。

自動パスは特に参考になります。置けない状況はエラーではなくルール上の自然な状態であり、読む人に操作を求めない設計です。言葉でいえば、「次に何をするか」が「何もしなくてよい」になっている例です。ただし、パスが画面上でどう知らされるかは確認済み事項にありません。作品を開いて、パスの瞬間にどんな表示が出るかを確かめてください。

投稿の制限を人の言葉にする

投稿の場面では、制限の数字がそのままエラーの原因になります。確認済みの制限を、書き換えの材料として表にまとめます。右端の列は、あくまで書き方の例です。

• ファイルが大きい、技術的な言い方になりがちな例：「サイズ超過」、言い換えの例：「アップロードは20MiBまでです。画像や音声を圧縮して、もう一度お試しください。入力した内容は残っています」
• 入口がない、技術的な言い方になりがちな例：「無効なアーカイブ」、言い換えの例：「ZIPの一番上の階層にindex.htmlが見つかりませんでした。フォルダの中ではなく、直下に置いて固め直してください」
• 対象外の機能、技術的な言い方になりがちな例：「サポートされていません」、言い換えの例：「サービスワーカーを使う作品は、アソバースでは公開できません。その部分を外して再度お試しください」
• 回数の上限、技術的な言い方になりがちな例：「リクエスト制限」、言い換えの例：「今日の投稿回数の上限に達しました。日付はUTC（協定世界時）で区切られるため、日本時間では午前9時が境目です」
• メール未確認、技術的な言い方になりがちな例：「権限がありません」、言い換えの例：「公開にはメールアドレスの確認が必要です。届いた確認メールのリンクを開いてから、もう一度公開してください」

この表から読み取れる工夫が3つあります。

数字は必ず単位つきで出します。 「大きすぎます」だけでは、どれだけ減らせばよいか分かりません。20MiBという上限を添えれば、読む人は自分のファイルと比べられます。ZIP展開後の合計100MiB、1,000ファイル、1ファイル30MiBという別の上限があることも、原因の切り分けに役立ちます。

直し方を一つに絞ります。 「index.htmlが必要です」より、「直下に置いてください」まで書くほうが、迷う時間が減ります。素材は相対パスで指定するという条件も、同じ場面の手がかりになります。

待てば直る失敗と、自分で直す失敗を分けます。 回数の上限は、読む人が何をしても直りません。待つしかないと分かれば、無駄な再試行をやめられます。確認済みの上限としては、投稿が1人UTC1日10回、アカウントごとに100アップロード・1GiBまで、アバター画像の生成が1人1時間1回（全体でUTC1日10回）、紹介文の作成が1人1時間3回（全体でUTC1日20回）です。個人の上限と全体の上限が別にあるため、「自分は上限に達していないのに使えない」場面が起こりえます。その場合は、全体の枠に達した可能性を言葉で伝える必要があります。「UTC1日」の数え方の詳細は、現在の案内で確認してください。

保存と同期の失敗は「消えたか」に答える

保存まわりの失敗は、読む人の不安が最も大きい場面です。確認済みの仕様から、言葉にすべき事実を整理します。

• 保存があるのは「余白の庭」「WAVE / WAVE」「かたちのあいだ」の3作品だけです。ほかの10作品の記録や録音は、画面を開いている間だけ残ります。
• ログイン中は、クラウドセーブと作品ごとのプレイ履歴が使えます。クラウドセーブは作品ごとにJSONで128KiBまでです。
• 未同期の端末セーブは、クラウドの古いデータより優先して再送されます。
• ゲストの履歴や進行は端末内に保存され、ログイン後のアカウントへ自動では混ざりません。
• オンライン対戦の部屋は24時間、部屋と対戦履歴は作成から7日後に削除対象です。

これらはどれも、「消えた」「残っている」「移っていない」を区別して伝えるための材料です。たとえば、画面を開いている間だけ記録が残る作品で、再読み込みのあとに記録が見えなければ、それは失敗ではなく仕様どおりの状態です。「保存できませんでした」と出すと、起きていない失敗を作り出してしまいます。「この作品の記録は、画面を開いている間だけ残ります」と、状態をそのまま書くほうが正確です。

ゲストで遊んだ進行がログイン後に見えない場面も同じです。「データがありません」では、消えたように読めます。「ゲストの進行はこの端末に残っています。ログイン後のアカウントには自動では引き継がれません」と書けば、探す場所が分かります。

オンライン対戦では、部屋が期限で削除対象になるため、「部屋が見つかりません」だけでは足りません。期限切れの可能性と、新しい部屋を作り直せることを併せて伝える言葉が要ります。再読み込みで同じ部屋へ復帰できる仕様もあるため、「まず再読み込みを試す」を最初の行動にできます。

自分の作品で言い換える手順

自作ゲームのエラー表示を見直す手順です。紙とペンだけで始められます。

1. 失敗の一覧を作ります。 読み込めない、保存できない、操作が受け付けられない、通信できない、など、読む人が目にしうる失敗を全部書き出します。
2. 3つに分類します。 「読む人が直せる」「待てば直る」「作る側の問題」のどれかを、失敗ごとに決めます。
3. 3要素で書き直します。 「何が起きたか」「何が無事か」「次に何をするか」を、それぞれ一文にします。三文を超えたら、読む人が読み飛ばす長さです。
4. 声に出して読みます。 専門語が出てきたら、普段の言葉に置き換えます。置き換えられない語は、初出で短く説明します。
5. 別の人に読んでもらいます。 メッセージだけを見せて、「次に何をしますか」と聞き、答えを書き留めます。

記録は、メッセージ1つにつき、想定した次の行動、読んだ人の答え、迷った点を並べた表にします。読んでもらう人数に決まりはありませんが、メッセージ1つにつき2〜3人から答えをもらうと、偏りに気づきやすくなります。

結果の読み方は単純です。全員の答えが想定した行動と同じなら、そのメッセージは機能しています。答えが割れたら、書き直しの合図です。「何もしない」「もう一度押す」「作者に連絡する」など、行動が分散する場合は、次に何をするかが一つに絞れていません。

起こりやすい誤りも挙げておきます。

• 謝罪が長くなる：お詫びの文が先に来ると、肝心の行動が後ろに押し出されます。
• 「もう一度お試しください」だけで終える：待てば直るのか、直さなければ同じ結果なのかが分かりません。
• 画面に出す情報が多すぎる：技術的な詳細は、別枠で見られるようにして、本文は短く保ちます。
• 個人情報を表示する：メールアドレスなど、他の人の目に触れうる情報を、エラー文に入れないようにします。

次の行動

自作のゲームやアプリで、画面に出る失敗の言葉を一つ選び、3要素（何が起きたか、何が無事か、次に何をするか）で書き直してみてください。書き直したら、家族や友人に見せて、「次に何をするか」を答えてもらいます。公式作品で失敗にあたる場面（こだまの森の間違い、潮目のオセロのパスなど）を実際に起こして、画面の言葉がどんな順番で情報を伝えているかを見比べると、自作の言葉を整える手がかりになります。