1. この記事について
「小さなサイトの手帖」は、運営のK+が、AIの支援を受けて制作・運営しています。記事は公式資料で確認した内容を中心に書いていますが、実際にこのサイトを作って公開するなかで、何度も間違えて、直しました。この記事は、その記録です。
書いてあることは、運営の記録に残っている出来事と、公開後に実際に確認した内容です。あわせて、過去に制作した他のサイトの作業記録から、作業上の出来事を取り上げています。その場合、顧客の名前、商品名、画面、URLは出さず、作業の内容だけを書きます。小さなサイトを自分で作る人が、同じところでつまずかないための参考にしてください。
2. 失敗：運営側の事情を、訪問者向けのページに書いていた
公開した直後に、自分たちのページを最初から読み返しました。すると、訪問者には関係のない記述がいくつも見つかりました。たとえば、「アクセス解析は未導入です」「問い合わせ窓口は準備中です」、記事の中の「この手帖の初回公開は制作記録」といった文です。どれも、運営側の都合です。読む人にとっては、「まだ準備中のサイトなのか」という不安にしかなりません。
公開から1日以内に、これらを削除するか、現状に合う書き方に直しました。公開前の確認では、見た目や動作だけでなく、運営側の事情が文章に残っていないかも読みます。公開前チェックリストの「内容と素材」の項目には、その意味で、仮の文言が残っていないかの確認を入れています。
3. 失敗：見た目を三回、作り直した
最初のデザインは、生成りの紙色と深い緑で、手帖のような雰囲気にしました。運営者の評価は「見た目がよくない」でした。次に、黒と金で高級感を出しました。すると今度は、「アフィリエイトサイトとしては、信頼しにくい」という評価でした。そこで、青を基調に、3Dの飾りまで加えて明るく作りました。しかしそれも、「ありきたりで、テンプレートのようだ」と評価されました。
最終的には、飾りをやめました。グラデーション、影、3Dをすべて外し、文字、余白、細い罫線だけで見せる作りです。そのうえで、「やりたいことから選ぶ」の一覧を、トップの最初に置きました。高級感や派手さを足すほど、かえって信頼感が薄れる、というのが、この三回の作り直しで分かったことです。見た目で迷ったら、訪問者が目的のページにたどり着くまでの手数を、まず減らします。
4. 失敗：AIが書いた文章に、強すぎる断定が混じっていた
記事の原稿は、AIの支援で書きました。公開後に、記事ごとに外部の事実を述べた文を抜き出して、公式資料と照合しました。さらに、指摘が出た点は、別々の確認で公式資料を開き直して、再検証しました。多くが「問題」と判断した指摘だけを確定したところ、16本の記事で54件になりました。
多かったのは、「必ず」「すべて」「防げる」のような、測定した範囲を超える言い切りです。これらは、実際に確認できた範囲の書き方に弱めました。また、Cloudflare Pagesについては、公式資料が新しいプロジェクトにはWorkersから始めることを案内していると確認できたため、関係する記事にそう明記しました。AIが書いた文章は、読みやすく整っているぶん、根拠のない断定が紛れ込みやすいと感じています。人が根拠を見て、確かめる手順は省けません。
5. 失敗：iPhoneで、入力欄をタップすると画面が拡大された
費用計算の画面は、パソコンの表示と、スマホ向けの狭い幅の表示で確認して、問題ないと考えていました。公開後にiPhoneのシミュレーター（Safari）で本番を開き、入力欄をタップすると、画面が自動で拡大され、レイアウトがずれました。入力欄の文字が16px未満だったためです。
入力欄の文字を16pxにして解消しました。初期値の「0」の後ろに入力すると「012000」になる点も、タップしたときに全選択するように直しました。画面の幅を縮めて見るだけでは見つからない問題でした。スマホの横はみ出しの確認とあわせて、実際の端末の挙動で試すことが大切です。
6. 公開のときに気をつけるようになったこと
- 仮の文字が残ったまま公開しない。広告のコードをまだ取得していない記事に、仮の置き換え文字を入れておき、残っていると、公開用のファイルを作る時点で止まるようにしました。実際に、この仕組みが、置き換え忘れを止めました。
- 公開した後に、実際のURLで確認する。公開用のファイルと、公開されたファイルが一致するかを調べます。新しい記事を公開した直後に、一部のページが一時的に見つからない状態（404）になったことがありました。少し待って確認し直すと、解消しました。
- 料金が確認できないサービスは、数字なしで比べない。公式ページから料金を取得できなかったサービスは、比較記事にしませんでした。
- 広告のコードは、掲載するサイトを確認して取得する。コードは、掲載するサイトごとに内容が変わります。別のサイト用のコードを使っていないか、取得するときに確かめました。
更新するときは、Search Consoleの確認用ファイルのような、残すべき固定ファイルも含めて公開し直します。ファイルを消すと、所有権の確認が外れるためです。更新と、元に戻す方法にも、この点を書いています。
7. 制作の現場で起きたこと（過去の制作案件の作業記録から）
このサイトとは別に、これまでに制作した他のサイトの作業記録からも、作業上の出来事を拾いました。顧客や商品が分かる情報は書きません。
古いファイルを編集して、公開版を消しかけた
日程を募集する申込サイトで、受付が満員になり、「満員」の表示を入れる依頼を受けました。作業の前に、手元のHTMLを調べると、公開中のページより古いものでした。公開中のページには、あとから追加した日程と、日程を選ぶ選択肢がありましたが、手元のファイルにはありませんでした。そのまま編集して公開していたら、公開後に入れた日程、スマホ向けの修正、フォームの改善が、すべて消えるところでした。
公開中のページのHTMLを取得して、元のファイルとして復元し、その上に必要な変更だけを載せました。変更は10箇所でした。表示の差し替えだけでなく、満員の日程の選択肢を選べないようにし、検索結果向けの構造化データの「在庫状況」も、満員の状態に直しました。無効にした選択肢をクリックしても選べないことは、実際に確かめました。一方、SNSで共有したときの説明文には、日程の案内が残っていたため、勝手に直さず、直すかどうかを依頼主に確認しました。更新の前に、手元のファイルが公開版と同じかを確かめることと、見た目だけでなく、フォーム・構造化データ・共有用の説明文まで確認することが、このときの教訓です。
大きな見出しが、パソコンでは途中で改行し、スマホでははみ出した
商品を紹介するランディングページで、迫力を出すために見出しの文字を大きくしました。パソコンの幅で確認すると、日本語の見出しが途中で改行され、下の数値のカードに重なりました。スマホの幅では見出しは収まったものの、ヘッダーの購入ボタンが非表示になっていました。さらに、横幅の計算で少しはみ出していました。原因は、大きな見出しの幅と、スマホ用の商品画像の配置でした。
見た目を保ったまま、横にスクロールしない寸法に詰めて、幅1440pxと390pxで確認しました。ブラウザの小さなアイコン画像が見つからない（404）という別の問題も、あわせて直しました。大きな文字は、パソコンとスマホで、別々の形で崩れます。どちらの幅でも確認が必要です。
「はみ出しても見えないだけ」の設定が残っていた
既存の店舗サイトを点検しました。結論は、「ある程度は対応しているが、すべての端末で安定しているとは言い切れない」でした。短い画面のiPhoneではヒーロー部分の要素が詰まる構成で、背景を固定する指定をiPhoneとiPadのSafariで使うと、崩れる可能性がありました。ページ全体に、はみ出た部分を隠す設定があり、「はみ出しても見えなくなるだけで、根本の解決にはならない」という指摘もしました。この点は、スマホの横はみ出しの記事でも説明しています。
対応として、ヒーローの高さの基準を変え、背景の固定をスマホだけ無効にして、折り返さない指定の周りを調整しました。ただし、このときは、ブラウザでの実際の画面確認が環境側の不具合で止まり、コードの点検が中心でした。実機での確認までは、していません。
埋め込み動画が「エラー153」になった
埋め込んだYouTube動画が、「エラー153」で再生できないという連絡を受けました。原因は、制作中のファイルをブラウザで直接開いていたことでした。この開き方では、動画サービスに必要な参照元の情報を送れません。URLに設定を足しても、解消しませんでした。
公開されたサイトと、ローカルのサーバー経由の表示では、これまでどおりページ内で再生し、ファイルを直接開いたときだけ、サムネイルと「YouTubeで見る」のリンクを出す方法にしました。本番に使うブランチは変えず、テスト用のブランチだけを公開して、再生を確認しました。制作中に直接開いて見える状態と、公開後の状態は、同じではありません。ローカルのサーバーで開いて確認します。
ノーコードのカスタムコードは、エディタでは動かない
ノーコードのサイト制作サービスで、アニメーション用のコードを、カスタムコードの欄に貼りつけて動かす案件がありました。このとき、エディタの画面や、ライブプレビューでは、カスタムコードが反映されないと分かりました。確認は、公開したURLで行う必要がありました。カスタムコードの利用には有料プランが必要で、文字数にも制限があります（公式の記載）。手順書には、「公開URLで動作確認する」と明記しました。
小さなサイトを作る人へ、五つの確認
- 公開前に、自分のページを最初から読み、運営側の事情や仮の文言が残っていないか確かめる。
- 見た目は、足すより減らす。訪問者が目的のページへ行く手数を、まず減らす。
- AIが書いた文章は、断定の強さと根拠を、人が確かめる。
- スマホは、画面の幅だけでなく、実際の端末の動きで試す（入力欄、文字の大きさ）。
- 公開した後に、実際のURLで、表示・リンク・ファイルの一致を確かめる。
公開前の確認は、公開前チェックリストで、一項目ずつ試せます。AIに制作を頼む前の整理は、必要な機能とページ数の記事にまとめています。
参照した公式資料
この記事は、このサイトの運営記録と、公開後に実際に確認した内容、過去の制作案件の作業記録に基づく記録です。過去の案件については、顧客の名前、商品名、画面、URLを出さず、作業内容だけを書いています。記事中の「54件」などの数字は、運営の点検記録（2026年10月）の値です。この記事に広告リンクはありません。