Claude CodeでHTML資料を作る｜計画・比較・レビューを伝える実践例

HTMLにするかは、読み手が何を判断するかで決める

変更履歴を追いながら文章を共同編集したいなら、Markdownが扱いやすい場面があります。候補の見た目を並べて選ぶ、操作の結果を切り替えて確かめる、長い説明を必要なところだけ開く。こうした読み方にはHTMLが役立ちます。

目的の違う資料を一枚に詰め込まず、「この資料を読んだ人が最後に何を決めるか」を1文にします。それが決まれば、必要な図や比較軸も選びやすくなります。

依頼文には、内容・読む人・使い方を入れる

「いい感じのHTMLを作って」だけでは、読み手や判断基準が伝わりません。以下は問い合わせ管理画面を検討するための編集部の依頼例です。実際の製品画面や計測結果を示すものではありません。

営業担当が使う問い合わせ一覧の改善案を、1つのHTMLにしてください。
目的は、担当者で絞り込む方法を決めることです。
現状、案A、案Bを同じ画面サイズとデータで比較します。
各案に、操作手順、利点、増える手間、未決定の質問を付けてください。
スマホでも読める通常スクロールの構成にしてください。
架空データを使い、実装前の見本であることが分かるように表示してください。

このように依頼すれば、デザインだけでなく、資料として必要な比較条件が入ります。検証できる目標を渡す考え方はClaude Code公式のベストプラクティスも参考になります。

保存したHTMLを開き、判断を会話へ戻す

最初は共有基盤を作らず、手元のファイルで一巡できます。上の依頼に「review.htmlへ保存し、画像やCSSなど別のファイルが必要ならその一覧も報告してください」と添えます。保存先を確認し、ファイルをブラウザで開きます。空白の画面になる場合は、本文が保存されているか、依存ファイルの場所が合っているかを調べます。

画面を見て選んだ後は、同じClaude Codeの会話に「採用する案／変更する条件／保留する項目」を返します。回答をMarkdownとしてコピーするボタンが必要なら、制作時にその機能も依頼します。未選択の項目まで承認済みに変えないよう、コピー内容を読んでから送ります。

review.html の案Bを採用します。
変更：0件のときは検索条件を解除する操作を表示。
保留：担当者の初期値は、利用者に確認してから決めます。
この回答を計画へ反映し、未決定の仕様を列挙してください。

開けたのに回答を返せない場合は、表示と送信を分けて切り分けます。ローカルのHTMLを開いた場合と共有URLを開いた場合で、選択内容やコピー操作が同じように動くとは限りません。コピーに失敗したら「質問1：A、質問2：未確認」のように画面で選んだ内容を手動で転記し、依頼先の会話に戻してから反映結果を確かめます。ボタンを押しただけで、AI側が回答を受け取ったとは判断しません。

画面の見本は、うまく動く状態だけにしない

通常の一覧だけを見ると、どの案も良く見えることがあります。実装後に違いが出るのは、データがないとき、読み込み中、失敗したときです。HTMLの見本では、この4つを同じ操作で切り替えられるようにすると、仕様の不足に気づきやすくなります。

通常・0件・読み込み中・失敗を比較する

0件の場合は、条件が厳しすぎるのか、元データがないのかを区別できる表示にします。読み込み中なら、前の結果を残すのか空にするのか。失敗なら、再試行ボタンを置くのか、問い合わせ先を示すのか。こうした判断を、実装前に見える形にします。

表の内容が本番データに見えると、読み手が実績として受け取る可能性があります。説明用の数字や名前には、その場で架空の例だと分かる表記を付けます。資料の最後だけに小さく注記する方法では、途中から開いた人に伝わりません。

折りたたみやタブは、重要な情報を隠すために使わない

情報を整理できても、読む順序が分からなくなると逆効果です。最初の画面には結論、選ぶ必要がある項目、未解決の問題を置きます。細かなコードや補足資料は、その判断が必要な場所から開けるようにします。

タブに入れた重要な条件が、印刷やPDF化で見えなくなることもあります。資料をどう配るのかを先に確認し、ブラウザで見る版と、印刷で残す版の両方が必要なら、それぞれで情報が欠けないかを点検します。単にタブが動くことと、必要な人に内容が届くことは別です。

資料の最後に、何を返してほしいかを書く

「ご確認ください」だけでは、見た人が何を答えればよいか分かりません。採用する案、修正してほしい条件、まだ判断できない点を選べる形にします。回答の内容によって実装が変わる質問に絞ると、読み手の負担も減ります。

未回答の項目を、採用された仕様へ自動で変換しないことも重要です。返された判断を、版と一緒に記録し、変更が入ったらどの案が最新なのかを明示します。

検収は、文章・操作・共有先の3つを見る

文章は、一度読んで結論と次の行動が分かるかを確認します。操作は、ボタンやタブ、リンクが実際に働くかを確認します。共有先は、読み手にアクセス権があり、必要な端末で表示できるかを確認します。ローカルで開けたというだけでは、共有完了にはなりません。

スマホでは、長い表やコードがページ全体を横に押し広げていないか、文字が小さくなり過ぎていないかを見ます。必要な情報が色だけで区別されている場合は、ラベルや形も併用します。公開する資料には、内部パスや未公開の顧客データが入っていないかも点検してください。

よくある質問

MarkdownをすべてHTMLへ変えるべきですか？

いいえ。編集や差分管理にはMarkdownを使い、共有や判断に必要な部分をHTMLで見せる運用もできます。

HTMLのモックができたら、そのまま本番実装になりますか？

見本と実装は別です。データ接続、権限、エラー処理、検証などは、本番の要件に合わせて作る必要があります。

まとめ：見せ方を、判断のために選ぶ

HTMLは、複雑な内容を比べたり、操作の結果を確かめたりするための選択肢です。まず共有したい資料を1つ選び、読み手が決めることを書き出してください。その判断に必要な画面、比較、質問だけを組み合わせると、読む価値のある資料になります。