前回までのあらすじ
前回は、Web Escape Engine Liteの第1弾を締めくくる回でした。説明書を「やりたいこと別のレシピ集」に作り直し、販売用ZIPを準備する中で、テンプレートの扉が別のゲームの扉にすり替わっていた事件を突き止め、二度と起こさないための自動チェックを作りました。
これで中身は「売れる状態」になりました。ただ、説明書はまだMarkdownという、プログラマー向けのテキストファイルのままです。今回は、この説明書を、買った人が開いて「お、ちゃんとしてる」と思える見た目に仕上げます。
第1章：Markdownのままでは売り物にならない
Markdownは、#や-などの記号で見出しや箇条書きを表すテキストの書き方です。GitHubなどで見ればきれいに整形されますが、パソコンでダブルクリックして開くと、記号がむき出しのまま表示されたり、ダウンロードが始まったりします。プログラミングに慣れていない買い手が最初に開くファイルとしては、かなり不親切です。
そこで、見た目の整った説明書を作ることにしました。候補は2つありました。
| 形 | 良い点 | 気になる点 |
|---|---|---|
| HTML（Webページ） | ゲームと同じくダブルクリックで開ける。コードをそのままコピーできる | 作るのが少し手間 |
| 印刷しやすい。作業が1回で済む | PDFからコードをコピーすると、改行や記号が崩れやすい |
決め手になったのは、この説明書の使われ方です。中身のほとんどは「この行をコピーして、ここを書き換えてください」という手順です。コピーした瞬間に記号が崩れたら、未経験の人はそこで詰まります。なので、HTMLを選びました。
第2章：Claude Designで作ったら、洋館になった
見た目は、ClaudeのDesign機能（キャンバスの上でページをデザインできる機能）で作りました。説明書の中身を渡して、まずたたき台を作ってもらいます。
最初にできあがったのは、暗い木の色に金色のアクセント、見出しは明朝体という、重厚なデザインでした。同梱しているサンプルゲームが洋館の「密室からの脱出」なので、それに合わせた見た目です。単体で見れば雰囲気は出ていました。
でも、見た瞬間に違和感がありました。
このテンプレートを買う人は、洋館の脱出ゲームを作りたいわけではない。
学園祭の出し物、イベントの謎解き、授業や研修、ブログへの埋め込み。画像と文章を差し替えれば、どんな舞台のゲームにもなるのがテンプレートの価値です。説明書はそのテンプレートの「顔」なので、特定のテーマに寄せる必要はありません。むしろ、寄せてはいけないくらいです。
そこで、テーマを選ばない見た目に作り直しました。白とグレーを基調に、ポイントの色を1色だけにした、すっきりしたデザインです。それを見て、さらに「パステル色くらいでもいい」と方向を決めました。最終的には、うすいラベンダーの表紙に、ピンク・クリーム・ミント・水色で色分けした「使う場面」のタグを並べたデザインになりました。
パステルにしても、文字は濃い色のままにしています。説明書なので、読みやすさは落とせません。コードの欄だけは、書き換える行の色分けがはっきり見えるように、濃いめの紺色を残しました。
表紙の見出しは「部屋も謎も、あなたのテーマで。」です。
第3章：コピペで壊れない説明書
デザインが決まったら、実装担当のClaude Codeに、ZIPに入れる本物の説明書（docs/index.html）として組み込んでもらいました。デザインの元ファイルと一緒に渡した条件の中で、いちばん大事にしたのはこれです。
コードをコピーしたときに、← の注記や行の色分けが混ざらないこと
説明書のコード例には、書き換える行に「← 新しい番号」のような注記が付いています。この注記がコピーした中身に混ざると、貼り付けた瞬間にゲームが動かなくなります。
Claude Codeは、注記をコードとは別の部品に分け、選択できないようにしたうえで、コピーするときにも取り除く仕組みにしてくれました。さらに、各コード例に「コピー」ボタンを付けています。
確かめ方も徹底していました。実際にキーボードのCtrl+Cを押す操作を自動で再現し、コピーボタンも押して、次の4通りでコピーした中身を調べています。
- コード欄ごとの全選択（Ctrl+C）
- 一部の行だけを選択（Ctrl+C）
- 章全体を選択（Ctrl+C）
- コピーボタン
説明書の10個のコード例すべてで、コピーした中身が、元の説明書のコード（注記を除いたもの）と1文字も違いませんでした。さらに、注記を取り除く処理をわざと壊した版では、この検査がきちんと失敗することも確かめています。「合格した」だけでなく「壊れたら気づける」ことまで確認してあるのが心強いところです。
ほかにも、作る途中でいくつか見つかって直したことがあります。
- ネットにつながっていなくても開けるように：デザインではWebフォント（ネットから読み込む文字）を使っていましたが、ZIPを展開してオフラインで開くと読み込めません。パソコンに入っている日本語フォントで崩れない作りにして、外部への通信は0件にしました。
- スマホで画面が横に広がる：幅390pxのスマホで、ページが951pxまで広がっていました。長いコードに全体の幅が引っぱられていたのが原因です。横にスクロールするのはコード欄の中だけになるように直しました。
- スマホで表が切れる：「困ったとき」の表は、スマホでは「症状」の下に「対処」を積む形に変えました。
第4章：説明書が2つに分かれない仕組み
HTMLの説明書ができると、新しい心配が出てきます。元のMarkdownとHTMLの2つができてしまい、片方だけ直して内容がずれる心配です。
そこで、Markdownを「正本」にして、HTMLはそこから自動で作る仕組みにしました。
- 説明書の文章を直すのは、Markdownの正本だけ（ZIPには入らない）
- そこからスクリプトでHTMLを作る
- HTMLを直接書き換えて正本と食い違うと、ZIPの作成が止まる
- 正本の各行がHTMLに入っているかも、毎回照合する
あわせて、販売用ZIPを作るときの自動チェックに、説明書の検査も加えました。リンク切れ、画像の参照、外部への通信がないこと、文字の読みやすさ（コントラスト）、スマホ幅で横にはみ出さないこと、そして第3章のコピーの検査です。文字の色をわざと薄くした版で試すと、約30か所の読みにくい文字を、ライト・ダーク、PC幅・スマホ幅の4通りの画面すべてで検出して止まりました。
第5章：リファレンスもHTMLに。長いページの落とし穴
説明書の中には「詳しくはリファレンスへ」というリンクが何か所もあります。リファレンスは、設定できる項目をすべて載せた辞典のようなページです。ところが、こちらはまだMarkdownのままでした。きれいな説明書から飛んだ先がテキストむき出しでは、がっかりさせてしまいます。
そこで、リファレンスも同じ仕組みでHTMLにしました。工夫したのは、リンクのつなぎ方です。説明書の中の「→ リファレンスの『ui』」のような参照は、見出しの名前から自動でリンク先を探してつなぎます。12か所の参照が、それぞれ意図した見出しに直接飛ぶことを確認しました。リファレンスのコード例6個も、説明書と同じコピーの検査を通しています。見出しの名前を変えてリンク先がなくなった場合は、ZIPの作成が止まります。
ここで1つ、面白い落とし穴に当たりました。
文字の読みやすさを測るチェックで、リファレンスの下のほうの文字が、軒並み「不合格」になったのです。スマホ幅で見ると、リファレンスは縦に約25500pxもある長いページです。測定のために、画面を縦に長く引き延ばして1枚で撮ると、ちょうど16384pxを超えたところから先に、ページの上のほうの内容が繰り返し写っていました。そのため、下のほうの文字の「背景」として、まったく別の場所の色が使われ、組み合わせがずれて不合格と判定されていたわけです。
実は最初、Claude Codeはこれを「下が真っ白になっていた」と報告していました。今回の記事の事実確認で実際に画像を比べ直したところ、真っ白ではなく、上の内容の繰り返しだったと分かりました。前回の連載で書いた「AIの報告を実データで裏取りする」が、ここでも役に立った形です。
測り方を、画面の高さごとに区切ってスクロールしながら測る方式に直して、すべて合格になりました。自動チェックを入れると、チェックそのものの不具合に出会うこともある。これも1つの学びでした。
📖 今回作った説明書
今回は、ゲームの代わりに説明書そのものを埋め込みました（ゲーム本体は第10話から変わっていません）。
目次から章を選んだり（画面の幅によって、目次は左か上に表示されます）、コード例の「コピー」ボタンを押して、メモ帳などに貼り付けてみてください。「←」の注記が混ざらずに、コードだけが貼り付けられるはずです。「リファレンス」へのリンクから、辞典のページにも飛べます。
💬 読者へのヒアリング
説明書は、プログラミングに慣れていない人が、迷わず自分のゲームに作り替えられることを目指しています。
- 読んでいて、意味が分からなかった言葉や手順はありませんでしたか？
- コピーして貼り付けたとき、余計な文字が混ざったり、崩れたりしませんでしたか？
- 「こんなことをしたいのに、やり方が載っていない」というものがあれば教えてください
コメントで気軽に教えてもらえると、説明書に反映します。
まとめ＆次回予告
今回は、説明書を「見た目」と「コピペ」の両面から仕上げました。
いちばんの気づきは、説明書はテンプレートの顔だということです。最初のデザインは、サンプルゲームに合わせた洋館風でした。でも、テンプレートを買う人が作りたいのは、それぞれ自分のテーマのゲームです。その人たちが開いて違和感のない見た目にする、という視点に切り替えたことで、方向が決まりました。
もう1つは、「この行をコピーしてください」と書くなら、コピーが本当に正しく動くことまで確かめる、ということです。説明書とリファレンスの合計16個のコード例を、実際のキー操作で検査したのは、少しやりすぎに見えるかもしれません。でも、買い手が最初につまずくのは、たいていこういう小さなところです。
これで、ゲーム・素材・説明書・自動チェックまで、販売に必要なものがすべてそろいました。
次回はいよいよ販売開始編です。どこで売るのか、いくらにするのか、買った人に何を許可するのか。作るのとはまったく違う悩みに向き合います。
次回：第12話「テンプレートを売ってみる：販売先選びから公開まで」
コメント