最初の完成目標

事業を紹介する1ページのサイトをつくり、正しい問い合わせ先・予約先などへ進めるようにします。ログイン、決済、顧客データベースの新規開発は扱いません。必要なら既存サービスへのリンクで始めます。

進む順番と、残すもの

困ったら27–28ページ。通しの記入例は29–30ページ。自力でできるかは31ページで確認します。用語は32ページ、出典は33–34ページです。

依頼文の使い方

「P01」などの依頼文をコピーし、［ ］の中を自分の内容に置き換えて送ります。指定された画像や資料を実際に添付してください。ファイル名を書くことと、ファイルを渡すことは別です。配布セットの prompts.md には依頼文だけをまとめています。

再現するのは、同じ画像ではなく制作の手順です。 生成結果、所要時間、費用はモデルや環境で変わります。各工程の確認項目を使い、同じ結果が出ないときも自分で前に進めることを目指します。

まず用意するもの

パソコン、普段使うAI、画像を生成できるAI、画像を読めるAI、ファイルを編集・実行できる実装AIを用意します。同じサービスが複数の役割を兼ねても構いません。最初から有料サービスを何種類も契約しないでください。

操作例はChatGPTの画像生成 → 画像理解AI → Codexのデスクトップ環境です。画像理解はChatGPTやGeminiを使えます。Googleの公式資料ではGeminiの画像理解とGemini 3.8 Flashを確認できます。実装側ではGPT-6 Astraの利用案内がありますが、利用可能なモデル・権限・プランは自分の画面で確認してください。優劣の順位を示すものではありません。[S1][S2][S3][S4]

作業場所を一つつくる

パソコンの書類フォルダなどに my-website をつくり、その中に materials フォルダをつくります。テンプレート3枚は materials にコピーします。

my-website/
  materials/
    brief.md       思いと第一印象
    reference.png  採用した見本画像（保存後に追加）
    design.md      見た目を保つための指示
    content.md     掲載する事実と文章

画像はJPEGなどでも構いません。拡張子だけをPNGに変えないでください。AIには実際の名前を伝えます。materials は制作資料置き場で、公開用フォルダではありません。

準備完了： 画像を1枚添付できる／専用フォルダがある／使える機能と利用上限を把握した。

最初に決めるのは、技術ではなく範囲

この練習は、新しい作業フォルダ内で行います。既存の本番サイトを直接編集しません。公開は20ページの確認後です。外部への送信、課金、既存データの削除、権限変更は、その操作の対象と影響を理解してから許可します。

AIへの依頼は「最高の品質を実現するため、必要な技術は選んでよい」。ただし、公開・課金まで何でも許可する、という意味にはしません。安全機構が拒否した操作を、別の方法で迂回しないことも約束します。

お金の扱いを先に決める

使用する契約の利用枠を確認し、この作業で追加支出してよい上限を brief.md に書きます。新しい有料素材、API、ホスティング契約は勝手に追加しません。ChatGPTアカウントによるCodex利用と、自分のAPIキーによる利用は、請求の扱いが異なります。[S2]

画像はまず1案。違いが明確になってから次を生成します。同じ失敗を繰り返すときは、回数を重ねる前に原因を確認します。モデルの数、生成回数、追加ファイルの数を成果と取り違えないでください。

渡してよい情報だけを渡す

社内で許可されたAIとアカウントを使います。個人情報、顧客の生データ、未公開の契約内容、秘密鍵・パスワードは、この練習の資料に入れません。ローカルで作業するAIでも、会話やタスクの文脈がクラウドへ送られる場合があります。[S2]

「書かなくていい」と「確認しなくていい」は違う

コードの文法を覚えることは、このガイドの前提ではありません。ただし、生成されたコードや文章が正しいとは限りません。実際に動かし、画面を見て、必要な確認を行います。

見た目を探す間は仮の表現でよい。公開する情報は仮のままにしない。 実在しない実績や顧客の声を、レイアウトの穴埋めとして公開しないでください。

この段階で記録： 追加支出の上限／使ってよい素材／作業フォルダ／公開を承認する人。

やること

普段使うAIを開き、次ページのP01を送ってから話します。音声入力を使う場合は、入力欄に文字として残ることを確認してください。ライブ音声会話でも、最後に自分の言葉を文字で残します。音声を使えない環境では、箇条書きやメモで十分です。

最初にページ数、機能一覧、料金表を詰め込む必要はありません。今は、誰に、どんな印象を持ってもらいたいかを探します。事業の詳しい説明は、16ページ以降で扱います。

話し始めるきっかけは、一つだけでいい

「この業界の、こういう見せ方が苦手なんだよね」
「見た人に、こんな気持ちになってほしい」
「ちゃんとしてるだけじゃなくて、こういう強さが欲しい」

この中の一つから、自分の言葉で続けてください。熱い言葉だけが正解ではありません。静かな願いや、説明しにくい違和感も材料です。「どう感じてほしいか」がまだ分からなくても、嫌な感じなら話せるかもしれません。

例えば、こんな独り言

AIのことを教えるサイトなんだけど、機械の話に見せたくない。人間の可能性の話をしたいんだよね。経営者が見て、またAIの研修か、で流さない感じ。知的だけど冷たくない。整ってるけど、おとなしく収まってない。見た人の背筋が、ちょっと伸びるような。

この言葉を、すぐに「信頼・革新・高品質」の3語へ薄めないこと。「知的だけど冷たくない」のような組み合わせは、そのまま大切にします。

この段階で決めなくてよいもの

フレームワーク、色の正確な番号、フォント名、細かい文章、SEOの設定。分からないものを無理に埋めるより、気になる例や写真があれば添えてください。第三者の参考は方向性を理解する材料であり、素材の無断転用を認めるものではありません。

次へ進む目安： 「こう見られたい」「こうは見られたくない」を、それぞれ自分の言葉で一つ言える。

P01｜壁打ちと brief.md の作成

自分の事業のWebサイトをつくります。まずは内容や機能ではなく、誰にどんな第一印象を持ってほしいかを探したいです。
これから、思いや好みを音声入力などでそのまま話します。ポエム、比喩、言い直しを許容し、きれいな事業説明に整えすぎないでください。

まず私が話すのを待ってください。その後、必要なときだけ一度に一問、具体的な質問をしてください。既に話したことは繰り返し質問しないでください。
「静かだけど強い」のような意図的な緊張感を、矛盾として消さないでください。私の実際の言葉と、あなたの解釈は分けてください。

私が「一度まとめて」と言ったら、次を含む短い brief.md を作ってください。
・私の原文のうち、特に残したい言葉
・誰に、最初に何を感じてもらいたいか
・最優先の印象と、補助的な印象
・避けたい印象
・今は決めなくてよい情報
・私が伝えた予算、素材、公開上の制約
・画像生成AIへそのまま渡す、日本語の依頼文を一つ

画像生成用の依頼文には、第一印象に必要な文脈だけを入れてください。長い事業説明、機能一覧、全ページの情報は入れません。今回はまだコードを書かないでください。

送った後にすること

思いを話し、印象の方向が一つ見えたら「一度まとめて」と伝えます。出力を読み、違うところだけを直してください。「私の言葉を、無難な表現に置き換えないで」という修正も有効です。

AIに brief.md をファイルとして出してもらい、materials に保存します。ファイル出力がない場合は、付属テンプレートに文章を貼り付けるか、手元のメモに保管し、実装AIへ「この内容を brief.md に保存して」と渡します。Markdownは見出し付きのテキストです。

確認： 原文が残った／狙う印象を選べた／画像生成用の依頼文がある。完成度を上げ続けず、画像へ進みます。

操作する

画像生成AIを開きます。ChatGPTの例では、会話で画像の作成を依頼するか、Imagesの機能を選びます。P01が作った依頼文に、下のP02を添えて送ってください。生成後は画像の保存操作で手元に保存できます。[S1]

P02｜第一印象のデザイン画像を1案つくる

以下の思いをもとに、Webサイトのトップページ・ファーストビューのデザイン画像を1枚作ってください。今回はコードではなく画像を生成してください。

［brief.md にある画像生成用の依頼文を貼る］

Webサイトの最初の画面を、正面から見た平面のデザインとして描いてください。端末の枠、斜めのモックアップ、ブラウザの装飾は不要です。横長、目安は16:10です。

目的は第一印象の視覚的な完成度です。実装しやすいUIパーツの配置から発想せず、構図、余白、写真・アート、文字の強弱を一体としてデザインしてください。説明を全部載せる必要はありません。
短い仮のコピーは使って構いませんが、実在する顧客、推薦、導入実績、受賞、数値を捏造しないでください。

狙いに不要な装飾は足さず、ありきたりな配置でよいか一度疑ってください。大胆さ自体を目的にせず、伝えたい印象に合う強い一案にしてください。

何を見ればよいか

最初に見るのは、文字の正確さではありません。全体の印象、文字と画像の主従、余白、色、視線が止まる場所です。文字の崩れは後で実テキストに直せます。ただし、読めない文字や不可能な重なりが魅力の中心になっていないかは覚えておきます。

画像先行は、このガイドで採用する制作上の作戦です。どのモデルでもコード先行より必ず優れた結果になる、という性能保証ではありません。

この段階では公開しません。 見本は完成サイトでも、Web用素材一式でもありません。

最初に、自分の目で選ぶ

画像を大きく表示した後、少し小さくして見ます。「この事業に初めて出会った人が、どう受け取るだろう」と考えてください。好みだけでなく、狙った相手に伝えたい印象との一致を確かめます。

最初の問いは三つです。狙った印象があるか。残したいところはどこか。いちばん違うところはどこか。 一案で方向が見えたら、それを採用して構いません。

P03｜元の良さを残して、画像を直す

添付したデザイン画像を修正してください。
残したいところ：［例：大きな文字と広い余白］
いちばん変えたいところ：［例：写真が広告っぽく、人の気配が弱い］
変えたい理由：［例：知的でも近寄りがたい印象にはしたくない］

今回の変更はこの一点を中心にしてください。元の構図や印象を全面的に作り直さないでください。修正版を1案作ってください。

修正対象の画像を実際に添付して送ります。修正前の画像は上書きせず残します。編集によって指定範囲外が変わることもあるので、修正後は全体も見直します。[S1]

採用する

採用画像を materials/reference.png などの名前で保存します。brief.md の末尾に、「採用理由」「残したい特徴3つ」「変えてよいこと」を追記します。

記入例： 大きな日本語が先に目に入り、紙のような温度がある。余白があるのに弱くない。この三つを残す。細かい仮コピーとボタンの位置は変えてよい。

迷ったとき

「どれも同じ」なら、形容詞を増やすより、自分の原文や比喩へ戻ります。「静か」「派手」の両案が欲しいなら、その違いを指定した追加1案にします。理由のない大量生成はしません。

次へ進む目安： 採用画像を保存した／残したい特徴を3つ言える／未解決の点も書いた。完璧な絵になるまで実装を止めないこと。

やること

画像を読めるAIに、採用画像そのものと brief.md を渡します。ChatGPTやGeminiなどで行えますが、添付画像を実際に見られる状態かを最初に確認してください。[S3][S5]

頼むのは、画像の感想ではありません。実装時に残すべき見え方を、具体的な指示へ翻訳することです。文章だけを見た別のAIが、まったく別の見た目を想像しない程度の手がかりを残します。

三つの区別をする

観察できること： 左側に大きな文字、右側に写真。見出しは本文よりかなり大きい。背景色は明るい。
意図の解釈： 文字の大きさが、自信や意思の強さを感じさせる。
実装時の提案： スマートフォンでは縦に並べ、見出しの主役感を残す。

画像から正確なフォント名、ピクセル寸法、アニメーション、リンク先までは断定できません。似ている候補や比率は「推定」と書きます。原寸に見える数字でも、確認していなければ観察事実にしません。

何を、どれくらい残すか

design.md は長大なデザインシステムではなく、短い実務メモで十分です。狙う印象、主役と脇役、余白・文字・配色・素材、スマートフォンへの移し方、変えてよい部分、まだ分からない部分を含めます。

この対応は万能の法則ではなく、今回の見本に合うかを判断するための例です。

優先順位： 掲載する事実・読めること・必要な操作を守る。そのうえで、印象と主従を維持する。画像の細部をそっくりにすることだけを目的にしません。

P04｜画像を読み、design.md を作成する

添付の見本画像と brief.md を読み、実装AIに渡す design.md を作ってください。最初に、実際に参照できたファイル名を示してください。画像を見られない場合は推測で進めず、そのことを伝えてください。

次の構成で、今回のサイトに必要な内容だけを整理してください。
1. 第一印象のゴールと、本人の原文
2. 絶対に残す特徴3つ
3. 画面内の主役、視線の順番、構図と余白
4. 文字の大小・太さ・改行、配色、写真やアートの役割
5. ボタン等の操作要素と、情報の置き方
6. PCからスマートフォンへ移すときの方針
7. 変えてよい部分、必要な素材、未確認事項

画像で観察できる事実、あなたの解釈、実装の提案を分けてください。正確なフォント、色番号、寸法、動きは、分からないなら推定と明記してください。

見本全体を1枚の画像として貼る方法ではなく、文章は読めるテキスト、操作は実際のボタン・リンク、写真やアートは適切な素材に分ける前提です。
技術の種類は指定しません。見本の品質を守るための指示に集中してください。画像から分からないことを勝手に確定しないでください。

出力を読んで確認する

特に「絶対に残す特徴3つ」を読みます。自分が好きだった部分が入っていなければ追加します。「何でも変更禁止」にはしません。スマートフォンで成立させるために、配置や改行の調整が必要になるからです。

記述例：
観察：左上の大見出しが画面の重心。
解釈：説明よりも、意思を先に感じさせる。
維持：一番大きな要素として扱う。
変更可：実際のコピーに合わせた改行と、スマートフォンでの配置。

materials/design.md に保存します。引き継ぎは、brief.md＋採用画像＋design.md の3点セットです。画像の代わりに、説明文だけを渡して終わりにしないでください。

操作例：デスクトップでCodexを使う

公式の案内から対応するデスクトップアプリを入れ、自分のアカウントでサインインします。現行の案内では、ChatGPTデスクトップアプリのメニューからCodexを選び、ローカルフォルダを開く構成です。以前のCodexアプリや提供段階によって表示が異なる場合は、公式の案内を優先してください。[S2][S6]

my-website を開き、新しい会話を始めます。まず下のP05を送ります。別の実装AIでも、専用フォルダを開けて、ファイルの編集と実行ができれば同じ進め方です。単にコードを回答するだけのチャットとは区別してください。

P05｜実装前に、できることを確認する

この my-website フォルダで、新しい事業サイトをつくります。まだ公開せず、まず準備状況を確認してください。

materials 内の brief.md、採用画像、design.md を探し、実際に読めたものを列挙してください。画像も実際に確認してください。
この環境で、ファイル編集、コマンド実行、ローカル表示、ブラウザ操作、スクリーンショット取得のうち何ができるかを確認してください。未確認の機能を利用可能と断定しないでください。

このフォルダ外の変更、公開、課金、既存データの削除はしません。必要な初期セットアップがあれば、目的と変更先を説明してください。OSの管理者権限が必要な操作は私に確認してください。
資料が足りない場合は、何をどこへ置けばよいか具体的に伝えてください。問題がなければ、実装を始められる状態だと報告してください。

「準備できた」の確認

実際のファイル名をAIが挙げ、画像内の特徴を説明できたら、受け渡しができています。「Node.jsが必要」などと言われたら、必要性と導入先を説明させ、公式の導入方法で進めます。意味の分からない管理者コマンドをそのまま実行しないでください。

画面が案内と違う場合は、アカウント情報を隠したスクリーンショットをAIへ渡し、「今見えている画面から次の操作だけ教えて」と聞きます。

完了条件： 編集先が正しい／資料を読めた／実行できる範囲が分かった。

P06｜見本から、動くトップページをつくる

materials 内の brief.md、採用画像、design.md をもとに、実際に動くトップページを実装してください。
言語、フレームワーク、ライブラリは指定しません。目的と最高の視覚品質を実現するため、必要な技術はあなたが選んでください。既存構成がある場合は尊重し、品質に寄与しない大がかりな仕組みは追加しないでください。

今回はビジュアルの成立を確認する段階です。仮の短い文章は使えますが、実績、顧客の声、数値、料金を創作しないでください。事業の全情報を詰め込む必要はありません。

見本の構図、主役、余白、文字の強弱、素材の質感を重視してください。一般的なカードの羅列に置き換えないでください。
見本を巨大な1枚画像として貼るのではなく、文章はテキスト、操作部分は本物のリンクやボタンにしてください。画像素材が不足するときは不足と分かる仮素材を使い、無断の有料生成や第三者素材の転用をしないでください。

PCとスマートフォンで成立するようにしてください。最初の対象は1ページで、ログイン・決済・データベースは不要です。
ローカルで起動し、可能ならブラウザで画面を見て修正してください。公開や外部送信はまだ行いません。

最後に、実際の起動方法、確認URL、停止方法、確認できたこと、未確認のことを示してください。実行していないテストを成功扱いにしないでください。途中で重大な障害があれば、同じ試行を繰り返さず原因と対処を報告してください。

動いたら、人間も開く

AIが返した実際のURLをブラウザで開きます。localhost や 127.0.0.1 は、通常そのパソコンの中での確認用です。友人へURLを送っても、同じ画面を見られるとは限りません。

画面が表示されることを確認し、まだ細かい文言は直しません。まず、画像の印象が動くページに残っているかを見ます。スクリーンショットを保存し、14ページの比較へ進みます。

この時点の合格： ページが表示される／主役と印象が残っている／未完成箇所を把握している。公開品質の判定は後です。

まず、画面を構成する要素を分ける

画像を見ながらAIに、テキストで組む部分、写真・イラストとして用意する部分、コードで描画する装飾、操作要素を分けさせます。必要なら写真やアートだけを別に生成・調達します。最初から素材一式を大量につくる必要はありません。

P07｜足りない素材を、必要な分だけ整える

見本画像と現在の実装を比較し、印象を大きく損ねている素材不足を確認してください。
足りない素材を、写真・アート、ロゴ、文字、装飾に分けてください。コードや既存の許可済み素材で足りるものは、新しく生成しないでください。

追加が必要なら、最も効果の大きい素材を一つ選び、用途、縦横比、必要な余白、背景、文字を含めるかどうか、保存先を示してください。画像生成に渡す依頼文も作ってください。
有料生成、購入、第三者画像の取得は、私の許可がない限り実行しません。まず提案までにしてください。

本文と見出しは、原則として文字で組む

生成画像の中の日本語を、そのまま正しい文章とみなさないでください。実装時には、後から編集できるテキストへ置き換えます。Webアクセシビリティの観点でも、ロゴなどを除き、文字を画像だけで伝えることは避けるのが基本です。[S10]

レタリングやタイトルアート自体が表現の核なら、画像として残す判断もあります。その場合でも、同じ内容を読めるテキストや適切な代替テキストで伝え、スマートフォンで読めるかを確認します。ページ全体の画像化で済ませません。

実写・事例写真の扱い

生成された人物や場所を、実在する社員・顧客・施設の写真として掲載しないでください。実在の紹介には許可済みの実素材を使います。イメージ画像を使う場合は、その役割が誤解されない扱いにします。

素材を保存したら、content.md にファイル名、用途、入手元、使用許可の確認状況を残します。フォントも同様に、利用条件を確認します。確認できない素材は公開候補から外します。

完了条件： 仮素材と本番素材を区別できる／使う素材の出所が分かる／主要な文章が編集できる。

比較できる条件をそろえる

見本画像と実装画面を、同じくらいの幅で並べます。例えば見本が16:10なら、PCの確認画面を1440×900程度にそろえると比較しやすくなります。これは練習用の目安で、必須の画面サイズではありません。

実装AIがブラウザを使える場合は、そのAIに撮影と比較を依頼します。Codexの公式資料にも、実ブラウザやスクリーンショットを使い、見本と比較して調整する手順があります。[S7][S8]

P08｜実装画面を、見本と比較する

採用画像、design.md、現在の実装を比較してください。まずローカルページを実際に開き、PCとスマートフォン幅の画面を確認してください。目安はPC 1440×900、スマートフォン390×844です。

ビルド成功だけで完成と判断しないでください。主役の大きさ、余白、文字の強弱、画像の扱い、配色、最初に見える範囲の順で比較してください。
印象を最も損ねる差を最大3つに絞り、一番影響の大きいものから修正し、同じ条件で再確認してください。満たした条件を壊さないでください。
今回は最大2周でいったん止め、修正前後の画面と、残る差、実際に行った確認を示してください。合格したら早く止めて構いません。
画面が見られない場合は、そのことを明示し、私がどの画面を撮って添付すればよいか教えてください。見ていない画面を確認済みにしないでください。

AIが画面を撮れないとき

人間がローカルページを開き、PC表示を撮ります。次にブラウザの幅を狭めるか、開発者ツールの端末表示でスマートフォン幅を撮ります。見本と一緒に画像理解AIへ添付し、差分の指示だけを実装AIへ渡します。添付前に個人情報や別タブの情報を確認します。

直す順番： 構図・主役 → 文字の強弱・余白 → 素材 → 細部。ボタンの角丸だけを磨いても、大きな構図のずれは解消しません。

「もっとかっこよく」から、一歩だけ進む

曖昧： もっとインパクトが欲しい。
具体： 最初に目に入るものが三つあり、視線が散る。大見出しを主役に戻し、小さなバッジを減らしたい。

曖昧： 人間味が足りない。
具体： 整った素材写真ばかりで、誰の事業か見えない。本人の手や表情が分かる写真へ変えたい。

大きく変えるときは、変更前の画面と状態を保存します。小さな不満を直すために、良かった構図まで失わないようにします。

P09｜違和感を、修正指示へ変える

添付の画面を見て、私の違和感を実装AIへ渡す具体的な修正指示にしてください。
私の言葉：［例：整っているけれど、普通の研修サイトに戻ってしまった］
残したい部分：［ここは好き、と感じた場所］

私の感覚を否定せず、ただし無条件に同意もしないでください。構図、情報量、文字、素材など、画面で確認できる原因候補を挙げ、今回直す一点を提案してください。見えない原因は断定しないでください。
元の意図と違う新しいデザインに作り直すのではなく、残すものと変更するものを分けてください。

ほかの人に聞くなら、「どう？」で終わらせない

対象に近い人がいれば、説明する前に画面を見せます。「どんな人向けに見える？」「何をしてくれる事業だと思う？」「何が気になった？」を聞き、答えをそのまま記録します。相手の好みに合わせるのではなく、狙いが伝わったかの材料にします。

この段階では、第一印象だけを聞いて構いません。内容を入れた後は「次に何をすればよいか分かる？」も確認します。周囲の反応を集められないときは、未確認として残します。AIの仮想ユーザー評価は補助であり、実際の顧客の反応とは区別してください。

次へ進む目安： 自分が残したい印象がある／PCとスマートフォンで主役が分かる／大きな見た目の問題を放置していない。

集める資料

許可済みの営業資料、サービス説明、正確な料金・提供条件、問い合わせ先、掲載してよい実績や写真を集めます。完璧な原稿に直してから渡す必要はありません。ただし、古い資料と新しい資料がある場合は、何が正本かを伝えます。

P10｜事実と文章を content.md にまとめる

これから渡す資料をもとに、事業サイトの content.md を作ってください。
見た目の方向は brief.md と design.md にあります。今回は、掲載すべき事実と文章の整理です。

誰のどんな状況に対し、何を提供し、どんな変化を目指す事業かを整理してください。最初の画面で伝えること、スクロール後に説明すること、詳細ページや外部リンクへ回せることを分けてください。

各情報を「確認済みの事実」「私の承認が必要な表現」「未確認」に分け、元資料や確認先を記してください。料金、期間、成果、実績、顧客の声、問い合わせ先を推測で埋めないでください。資料が矛盾する場合は、矛盾を示してください。

トップページの短い見出し、補足文、提供価値、必要な説明、主な行動を促す文と正しいリンク先をまとめてください。掲載根拠がない要素は無理に作らなくてよいです。
画像のファイル名・用途・使用許可の状況も記録してください。本文中の要確認事項を目立つ形で残してください。

人間が確認すること

数値、名称、条件、効果の言い方、問い合わせ先を読みます。AIが根拠を挙げても、その根拠に本当に書かれているかを確認してください。「知らなかったけれど、AIがそう書いたから」は公開理由にしません。

最後に materials/content.md に保存します。空欄があっても構いませんが、未確認項目を確認済みに変えるのは人間です。

この段階でまだしてはいけないこと： 情報を収めるために、文字を一律に小さくする／全部の文章を最初の画面に押し込む／見本の雰囲気に合うよう事実を変える。

まず三つの層に分ける

最初の画面： 誰のための何か、いちばん伝えたい価値、次の行動。
その下： 具体的な内容、選ぶ理由、不安を解く説明、必要な条件。
詳細： 長い背景、細かい仕様、追加資料、詳しい事例。

説明が増えたら下へ送る、まとまりを分ける、別ページや資料へつなぐ、という選択をします。料金や重要な利用条件など、判断に必要な情報を、見た目のためだけに見つけにくくしないでください。

content.md の記入イメージ

事業名：［正式名称］
対象：［誰が、どんな状態のときに読むか］
提供内容：［実際に提供するもの］
主な行動：［例：相談の予約をする］
リンク先：［実際に確認したURL。未定なら未定］

最初の画面
・見出し：［短い表現］
・補足文：［何のサービスかが分かる文章］
・ボタン：［押した後の行動が分かる文］

掲載する事実
・内容／出典／確認者／確認日
未確認
・確認が必要な情報／確認先
素材
・ファイル名／用途／出所／使用許可の状況

コピーは「短ければよい」わけではない

「未来を変える」だけでは、何の事業か分からないかもしれません。大きな見出しで感情を動かし、短い補足文で具体的な内容を伝える、という役割分担を試します。

例えば「自分の事業を、もう一度動かす。」という見出しに、「AIを使い、仕事の進め方を実践しながら見直すプログラム」と添える。ただし、これは架空の表現例です。実際の提供内容に合うかを確認してから使います。

次へ進む目安： 一番伝えたいことが一つに絞れた／主要な行動とリンク先が決まった／掲載する事実と未確認情報を区別した。

P11｜確定した内容を、デザインへ統合する

現在の実装に materials/content.md の内容を反映してください。採用画像、brief.md、design.md も改めて読み、元の第一印象と主役を保ってください。

「確認済み」の情報を使い、「未確認」や要承認の表現は勝手に確定しないでください。仮のコピー・写真・リンクが残る場合は、公開前に処理すべき一覧にしてください。

文章をすべて最初の画面へ詰め込まず、最初に伝えること、スクロール後の説明、詳細へ回す情報を分けてください。収まらないとき、ただ文字を小さくするのではなく、構成や配置を調整してください。意味の変更や重要な条件の省略は、実行前に私へ示してください。

PCとスマートフォンで、内容の理解、読みやすさ、次の行動を両立させてください。実際の問い合わせ・予約はまだ送信しません。実装後に画面を見て、元の見本から変えた部分と理由を示してください。
既存の良さを失う大規模な再生成をせず、必要な範囲を修正してください。

内容と見た目がぶつかったときの判断

「静かで高級感がある」と「説明が詳しい」は、必ずしも矛盾しません。説明を読む場所や順序を設計すれば両立を目指せます。一方で、狭い領域に大量の長文と巨大な余白を同時に求めると、調整が必要です。

衝突したら、まず何を最初に感じ、何を次に理解してほしいかへ戻ります。ブランドの意味を保ったまま、ページの長さや情報の分け方を変えます。事実や使いやすさを犠牲にして、画像の配置だけを守りません。

最初の画面を、もう一度見る

大見出しが弱くなっていないか。文章を入れたことで写真が押し出されていないか。ボタンが増えて迷いやすくなっていないか。変更前後を同じ画面幅で比較します。

完了条件： 事業内容が分かる／次の行動が分かる／意図した第一印象が残る／仮情報の処理状況を説明できる。

P12｜公開前の動作と表示を確認する

現在のサイトを、公開前の候補として検証してください。変更範囲に必要なチェックを選び、実際に実行してください。

・起動／公開用ビルドが正常か（該当する場合）
・PCとスマートフォン幅で、文字の切れ、横にはみ出す内容、画像崩れがないか
・見出し、本文、ボタンが読めるか。拡大やキーボード操作でも主要な内容へ到達できるか
・画像の代替テキスト、リンクの目的、フォーカス表示が適切か
・メニュー、主要リンク、外部の予約・問い合わせ先が意図どおりか
・仮コピー、架空の数値、要確認表現、仮画像、無効なリンクが残っていないか
・公開用ファイルに秘密情報や内部資料が含まれていないか
・ページタイトル、説明文、共有画像などが内容に合っているか

フォーム・予約・購入などの外部送信は行わず、必要な試験は方法と影響を先に示してください。

結果を「項目／確認方法／結果／証拠または画面／未確認」でまとめてください。自動確認が通っただけで、安全性やアクセシビリティの完全保証にしないでください。見つかった重要な不具合を直し、関連箇所を再確認してください。

人間が少なくとも試すこと

最初から最後まで読み、全ての主要なリンクを開きます。ブラウザで文字を拡大し、Tabキーで移動して、選択中の場所が分かるかを見ます。送信を伴う確認は、送信先の担当者と試験方法を決めてから行います。

スマートフォン幅の表示は、実機そのものではありません。公開後にスマートフォン実機でも確認します。ローカル段階で未実施なら、そのことを記録しておきます。

W3Cの簡易チェックは、見落としを減らす入口です。合格しただけで全面的なアクセシビリティ適合とは判断できません。[S9]

次へ進む目安： 主要な操作が確認できた／重要な不具合がない／未確認部分の影響を説明できる。

公開前の確認表

該当しない項目は理由を書きます。確認していない項目を、便宜上「合格」にしないでください。

一つでもあれば、公開を止める

事実が未確認のまま断定されている。重要なボタンが動かない。主要情報が読めない。素材の利用可否が不明。機密や個人情報が混ざっている。誰が管理するか不明。これらは「あとで直す軽微な問題」にはしません。

反対に、小さな余白や細部の好みだけを理由に、いつまでも公開を止める必要はありません。判断の基準は、利用者や事業に与える影響です。

承認を一文で残す

「［日付］、［承認者］が、［対象サイト・版］の内容と確認結果を確認。［公開先］への新規公開を承認。追加料金の上限は［金額］。既存の本番サイト、ドメイン設定、他のサービスには変更しない。」

社内の管理ルールがある場合はそちらを優先します。個人情報を集める仕組みを追加するなら、このガイドの公開判断だけで済ませず、管理・利用目的・保護・運用について担当者と確認してください。

プレビューという名前でも、非公開とは限りません。 Cloudflare Pagesでは、プレビューURLは初期状態で公開されます。アクセス制限と単なるURLの非告知は別です。[S12]

まずAIに、二つの方式を判定させる

A：静的な公開用ファイルで動く。 サーバー側の専用処理が不要なら、22ページのCloudflare Pagesへのアップロードを使えます。
B：サーバー側で処理する実行環境が必要。 単なるファイルのアップロードでは動かない場合は、23ページのGitHub連携による公開例へ進みます。選んだサービスが実装方式に対応するかをAIに確認させます。

P13｜公開方式を判断し、公開の準備をする

現在の実装を読み、公開の準備をしてください。まだ外部へアップロードしません。

まず、このサイトが静的ファイルだけで動くか、サーバー側の実行環境が必要かを、コードに基づいて判定してください。判定理由と、適合する公開方法を一つ提案してください。特定の公開先に合わせるためだけに、勝手に全体を作り直さないでください。

静的に公開できる場合：必要なら本番ビルドを行い、公開対象だけを入れたフォルダとZIPを用意してください。ルートに index.html があるなど、アップロード先の形式に適合させてください。
サーバー実行が必要な場合：対応する公開先、ビルド・起動設定、必要な設定値、費用確認先を整理してください。

どちらも、秘密情報、.env、内部資料、制作メモ、不要なソースマップ等を公開物へ含めないでください。ブラウザへ配信される設定値に秘密を埋め込まないでください。
最後に、公開する対象、実際のファイルパス、管理者が操作する手順、確認方法、元へ戻す方法を示してください。未解決の公開ブロッカーがあるなら明示してください。

公開前に保存するもの

動く状態の制作データと、公開用データを別々に保存します。日時が分かる名前をつけ、正常に戻すための基準にします。公開用ZIPだけでは、将来の修正に必要な元のコードが足りない場合があります。

完了条件： 公開方式を説明できる／対象ファイルが分かる／費用と利用条件を確認した／承認済みの範囲が分かる。

実行前の条件

P13が「静的ファイルとして公開できる」と確認済みであること。公開内容と費用の承認があること。社内の公開先が決まっている場合は、その運用を優先します。

操作手順

1. Cloudflareへログインし、管理画面の Workers & Pages を開きます。
2. Create application → Get started → Drag and drop your files の経路で、Pagesの新規アップロードを選びます。
3. 新しいプロジェクト名を入力し、P13で用意した公開用フォルダまたはZIPを指定します。my-website 全体や materials を渡さないでください。
4. 対象を最終確認して Deploy site などの公開操作を実行します。
5. 発行された実際の pages.dev のURLを開きます。表示や名称が異なる場合は、公式のDirect Upload案内を参照します。[S11]

公開されたら、別の利用者として確認

別ブラウザまたはプライベートウィンドウで開きます。スマートフォンでも、公開URLから最初の画面、スクロール、主要リンクを確認します。これは公開後の実機確認です。ログインなしで見られることが今回の公開意図に合っているかも確認します。

記録： 公開URL／プロジェクト名／公開日／管理アカウントの担当者／公開したデータの保存場所。パスワードやトークンは書きません。

この方法の注意点

Direct Uploadで作った同じPagesプロジェクトを、後からGit連携方式へ切り替えることはできません。自動デプロイへ移る場合は、新しいプロジェクトが必要です。また、管理画面へのドラッグ＆ドロップはPages Functionsのコンパイルに対応しないため、サーバー処理が必要な構成を無理にこの経路で公開しないでください。[S11]

独自ドメインは、まず発行URLで動作を確認してから追加します。CloudflareのCustom domainsの案内に従い、既存のDNSやメール設定への影響は管理者と確認します。独自ドメインの取得は、この練習の必須条件ではありません。[S15]

成功： 外部のURLで表示され、実機で主要な行動まで確認できた。

先に、利用条件を確認する

実装がVercelで動くかをP13で確認します。Vercel Hobbyは非商用の個人利用向けです。事業サイトを、無料だからという理由でHobbyへ載せないでください。 商用利用に適合する契約・費用・組織アカウントを確認します。[S16]

1. GitHubへ制作データを保存する

GitHubで New repository を開き、組織の管理ルールに従って所有者を選びます。名前を決め、まず Private を選びます。既存のローカルリポジトリを取り込むときは、README等を追加しない空のリポジトリをつくります。作成後のURLを実装AIへ渡します。[S13]

AIに「この新規Privateリポジトリへ制作データを保存したい。まず送信対象を確認し、秘密情報と不要ファイルを除外した候補を示して」と依頼します。対象を確認してからpushを許可します。認証操作は自分で行い、トークンを会話へ貼りません。

2. Vercelへ接続して公開する

Vercelの New Project を開き、GitHubを接続して対象リポジトリだけを選びます。P13の結果に合わせてビルド設定、出力先、必要な環境設定を確認し、公開の承認後に Deploy を実行します。公式の案内では、Git連携したブランチへのpushでデプロイが自動実行されます。[S17]

初回デプロイも外部公開につながります。仮情報や内部資料を含んだまま操作しません。新規プラグインやデータベースの追加は、必要性がなければ行いません。

3. 公開後を確認する

発行された実際のURLを、別ブラウザとスマートフォンで確認します。メニューや外部リンクも試し、URLと正常な版を記録します。

注意： Privateリポジトリはソースの閲覧制限であり、サイトの非公開設定ではありません。GitHub上の公開範囲と、公開サイトの閲覧範囲は別々に確認します。[S14]

A/Bどちらも適合しない場合は、P13で選ばれた対応環境の公式手順を使います。認証・支払い・既存本番変更で判断できない点は、管理者と解決してから進めます。

保存のタイミング

見た目を採用したとき、内容を入れて確認が終わったとき、公開したとき。この3点で、後から識別できる状態を残します。最初は制作フォルダのバックアップでも構いません。公開用ZIPとは区別して、社内で認められた場所に保存します。

Gitを使う場合は、AIに「今の状態を保存するローカルのコミットを作って」と依頼できます。GitHubはコードやファイル、変更履歴を保管する場所です。Privateでも、秘密情報を含めてよいわけではありません。[S14]

P14｜変更前に保存し、必要なときに戻す

これから変更を行う前に、現在の正常な状態を保存してください。Gitがあれば変更内容を確認してローカルのコミットを作り、なければ、この作業に必要な制作データのバックアップを作ってください。外部へのpushはまだ行いません。
保存した版を識別できる情報と、その状態へ戻す方法を記録してください。

後で私が「戻したい」と言ったら、まず現在の未保存の変更を退避し、どの版・どの範囲へ戻すかを確認してください。ローカルファイルの復元と、公開サイトの差し戻しを区別してください。
未確認の変更を削除したり、履歴を強制的に書き換えたりせず、安全に戻せる方法を優先してください。公開中の内容を変える操作は、その対象を私が承認してから行ってください。

小さく、復元の練習をする

公開前のローカル環境で、見出しを一時的に一語だけ変えます。表示を確認し、直前の正常な状態に戻します。元の文章に戻ったら成功です。本番サイトで練習しません。

公開後の戻し方

Direct Uploadなら、保存した正常な公開用データを、新しいデプロイとして再アップロードする方法があります。Git連携なら、どのブランチの更新が公開につながるかを確認してから、修正を取り消す変更を用意します。必ず公開先で戻ったことを確認します。[S11][S17]

完了条件： どれが正常な版か分かる／ローカルで復元を試した／本番へ反映する操作を区別できる。

P15｜目的を絞って、サイトを更新する

このサイトを、次の目的のために更新してください。
目的：［例：新しい事例を一件紹介する］
変更内容：［確定した文章・画像・URL］
変えないもの：［元の第一印象、見出しの強弱など］

まず現在の実装と materials 内の資料を確認し、変更前の正常な状態を保存してください。今回の目的に不要な技術変更や全面リニューアルはしないでください。
content.md などの正本も、実装と食い違わないよう更新してください。ローカルで変更を確認し、必要な表示・リンクの確認を行ってください。
最後に差分、確認方法、未確認事項、公開に必要な操作を示してください。外部の公開・pushは、対象と影響を私が承認するまで行いません。

更新の判断材料

「問い合わせで同じ説明を繰り返した」「リンク先が分かりにくいと言われた」「新しい提供内容が増えた」。こうした具体的な理由があるとき、該当する部分から変えます。

アクセス解析を使う場合も、先に「何を知りたいか」を一つ決めます。閲覧数だけでサイトの価値を判断せず、実際に次の行動につながったか、問い合わせ内容が期待に近いかを見ます。個人情報や同意の扱いは、導入する計測方法と社内ルールに合わせて確認します。

ページを増やすとき

トップページの情報を圧縮し続けるより、詳細が必要な内容を別ページにします。AIへ「既存のデザイン原則と共通部分を使い、今回の目的に必要な1ページだけ追加して」と依頼します。ページ名、移動リンク、戻る導線、直接開いたときの表示も確認します。

AIを変えるとき

新しいモデルが出たからといって、作り直す必要はありません。既存の画像、brief.md、design.md、content.md とコードを、新しい実装AIへ渡します。次ページのP16で、現在地を引き継ぎます。

更新完了： 必要な変更だけが入った／内容と資料が一致する／確認結果を見て公開を判断できる。

P16｜別のAIへ、現在地を引き継ぐ

このサイト制作を、別のAIまたは担当者へ引き継ぎます。現在のコードと資料を確認し、短い引き継ぎメモを作ってください。

含めるもの：目的／現在できていること／対象フォルダと重要なファイル／採用画像と設計資料／実際の起動・停止・ビルド方法／公開先と公開につながる操作／正常な版と戻し方／実施した確認／未確認・未解決事項／次に行う最小の一手。

秘密情報の値は書かず、必要ならどの管理画面で設定するかだけ示してください。過去の計画より、現在の実装と実行結果を優先してください。
受け取るAIには、資料を読んでから既存構成を尊重し、いきなり全面的に書き直さないよう伝えてください。

渡すものの確認

制作フォルダまたはアクセスを許可したリポジトリ、採用画像、3つの文書、引き継ぎメモを渡します。画像が会話にしか残っていない場合は、ファイルで保存して渡します。機密を含む別案件のフォルダまで共有しないでください。

P00｜このガイドを、一歩ずつ案内してもらう

添付した「思いから、Webをつくる。」のガイドに沿って、自己学習を進めたいです。まずガイドを読み、現在地を確認してください。

一度に全工程を説明せず、今の工程の「目的」「渡すもの」「次にする操作」「成功の確認」を一つずつ案内してください。既に完了した工程は繰り返しません。
思いは音声入力やポエムのまま受け止め、最初はコードではなく画像で見本をつくります。技術選定は実装AIに任せます。
使えない機能や見ていない画面を、使えた・確認したと扱わないでください。操作画面が違うときは、機密を隠したスクリーンショットと公式情報から案内してください。
公開・課金・削除・権限変更は、私が対象と影響を確認して承認した範囲だけで行います。
現在地：［まだ準備していない／見本画像までできた、など］

使い方： ガイド本体のPDFまたはMarkdownをAIへ実際に添付してから、P00を送ります。

画像ではなく、説明文だけが返ってきた

その会話で画像生成機能が使えるか確認します。P02を、画像生成できる機能・サービスへ送ります。文章生成モデルの名前が高性能でも、その環境で画像を生成できるとは限りません。

何を生成しても、よくあるサイトに見える

「高級」「洗練」「革新的」だけになっていないか、brief.md の原文へ戻ります。例えば「会議室ではなく、工房のような知性」と、自分が本当に感じている比喩を足します。業界の定型を避けることを目的にせず、誰に何を感じてほしいかを中心にします。

画像の日本語が崩れる

画像段階では短い仮コピーにします。文章を正しく読む必要がある場所は、実装時にテキストへ置き換えます。見本内の文字修正だけで生成回数を使い切らないでください。

画像は良いのに、実装すると普通になる

実装AIへ採用画像そのものが渡っているか確認します。次にP08で、主役の大きさ・余白・画像の扱いを比較します。「似た色と似た部品」だけで再現を終えていないかを見ます。足りない素材が主因ならP07へ戻ります。

全部を1枚画像として貼られてしまった

「本文と見出しはテキスト、操作はリンク・ボタン、素材は個別に分けて」とP06の該当部分を再度渡します。残すべきレタリングアートと、編集可能にする本文を区別します。

中身を入れた途端、雰囲気が崩れた

P11へ戻り、最初の画面に載せる内容を選び直します。文章を減らすだけでなく、説明を読む順番や配置を変えます。意味のある情報を捨てていないかも確認します。

PCは良いが、スマートフォンで弱い

PCの縮小コピーを求めず、「何を最初に見せたいか」を同じにします。縦並び、改行、画像の切り取りを調整します。横幅の狭い画面でも、大見出しの主役感を残す方法をAIに考えさせます。

共通の戻り方： 原文 → 採用画像 → design.md → 実装画面。ずれが初めて生じた場所から直します。

ローカルのURLが開かない

実装AIに、サーバーが起動しているか、実際のポート番号、起動時エラーを確認させます。例示のURLをそのまま開いていないかも確認します。スマートフォンのlocalhostは、パソコンのlocalhostとは別です。

画像が表示されない／画面が真っ白

スクリーンショットとエラーをAIへ渡します。ファイル名の大文字・小文字、保存先、参照パス、ビルド結果などを確認させます。原因を調べず同じビルドを繰り返しません。

フォームの「送信しました」が出るが届かない

見た目だけのデモである可能性があります。送信処理と送信先を確認し、勝手に本物の顧客情報で試験しません。最初の公開では、既存の正しく動く問い合わせ・予約サービスへのリンクへ戻す方法もあります。

公開すると404／画像だけ見つからない

公開用の出力フォルダをアップロードしたか確認します。静的公開の場合は、ZIPを開いたときのトップ階層に必要な index.html や素材があるかをAIに調べさせます。ソースフォルダと出力フォルダの取り違えを確認します。

権限を求められた／課金が必要と言われた

対象、必要性、影響を確認します。プロジェクトの外まで書き換える権限や、全リポジトリへのアクセスを自動的に許可しません。承認できないなら、その範囲で止めて別の独立した作業を進めます。拒否された操作の迂回はしません。

P17｜エラーを、原因から解決する

現在の問題を調べてください。
起きたこと：［見えた症状］
直前にした操作：［具体的な操作］
期待した結果：［どうなるはずだったか］
添付：［機密を除いたエラー全文、スクリーンショット］

まず現在の状態と原因候補を確認し、最小の修正を一つずつ試してください。同じ処理の無根拠な再実行、大規模な作り直し、テストの削除による見かけ上の成功はしません。
直した後は、最初の症状が解消したか実際に確認してください。確認できない部分は、そのまま明示してください。

題材：架空の家具修理工房「つぎめ」

話した言葉：
「傷があるから、もう駄目だ、って思ってほしくないんだよね。ずっと一緒に暮らした椅子を、また使えるようにしたい。懐かしいだけの店じゃなくて、今の生活にちゃんと合う。職人を神様みたいに見せたくないけど、仕事は信用してほしい。」

brief.md に残すこと

原文： 「ずっと一緒に暮らした椅子」「懐かしいだけじゃない」「職人を神様にしない」
対象： 思い入れのある家具を、捨てる前に直せるか相談したい人。
第一印象： 静かで誠実。古さではなく、これからの暮らしを感じる。
避ける： 安売りの修理広告、過度な高級感、職人気質で近寄りがたい演出。

画像生成へ渡す例

家具修理工房「つぎめ」のトップページの第一印象を、正面から見た平面デザイン画像にしてください。「また、一緒に暮らせる。」という短い仮コピー。手入れされた椅子と、人の手の気配。静かで現代的、誠実だが近寄りがたくない。古さを飾るのではなく、暮らしの続きを感じさせる。説明や料金表はまだ不要。端末枠なし、横長で一案。

画像を見た後の判断例

仮に「椅子の写真、大きな短い見出し、温かい余白」の案が出たとします。本人が「この静けさは好きだが、豪華な家具の店に見えすぎる」と感じたら、写真の生活感だけを修正します。全面的に再生成する必要はありません。

design.md に残す例

維持： 椅子と短い見出しを主役にする。余白を残す。写真に生活の痕跡を残す。
変更可： 仮コピー、細かい配置、スマートフォン時の順番。
未確認： 実際の施工写真、正確な書体、追加の画像素材。
実装提案： 本文はテキストにし、写真は素材として独立させる。

ここまでが、見た目の目標をつくる工程です。まだ「営業可能なサイト」とは判断しません。

練習用に設定された事業情報

この例では、「椅子やテーブルの修理相談を受ける」「状態を確認して対応可否と見積もりを案内する」を、練習上の前提とします。実在の工房の情報ではありません。料金、納期、地域、受付URLは未確認のままにします。

content.md の整理例

「無料相談」「最短3日」「修理実績1,000件」などは、見栄えのために足しません。URLが未確認なら、練習中は非公開のまま、確認すべき項目として残します。

統合で起きる問題と直し方

説明文が増え、椅子の写真が画面の下へ押し出されたとします。最初に「見出しを小さく」するのではなく、大見出しと短い説明、相談ボタンまでを最初の画面にまとめ、詳しい流れをその下へ置きます。

スマートフォンで文字が写真に重なるなら、写真の上に無理に全部載せず、縦に並べる案を試します。PCと同じ座標ではなく、静けさと主役を保つことを優先します。

どう確認するか

「何をしてくれる工房か」を人が説明できるか。相談ボタンの行き先が正しいか。写真は実際の掲載許可済み素材か。PCとスマートフォンで、修理の流れが読めるか。この例では未確認事項が残るため、公開は不合格です。

きれいな画面ができても、正しい行き先と事実がそろうまでは公開しない。この判断までできて、制作の一連の流れを再現できたことになります。

実技：この三つを行う

1. 見た目を一か所だけ直す。
変更前を保存し、「残すもの」と「変えるもの」を言葉にしてAIへ渡します。変更後の画面を比べ、狙った部分が変わり、残す部分が維持されたことを確認します。

2. 内容を一か所だけ更新する。
実際の事業に基づく説明を一文変えます。content.md とページの両方が更新され、PCとスマートフォン幅で読めることを確認します。本番へ出すかは別に判断します。

3. 別の会話で再開する。
P16の引き継ぎと必要ファイルを別のAI会話へ渡します。「現在できていること」と「次の一手」が正しく説明されるかを確認します。過去の全会話を貼らずに再開できれば成功です。

判断クイズ

Q1. 見本画像は美しいが、事実未確認の推薦コメントが入っている。画像のまま公開してよい？
Q2. 実装AIが「ビルド成功、デザインも問題なし」と言ったが、画面は見ていない。確認は終わり？
Q3. PrivateのGitHubリポジトリを使っている。デプロイしたサイトも自動的に非公開？
Q4. 「静かだけど力強い」という要望は、矛盾なのでどちらかを消す？

答えと理由

A1. いいえ。 見本内の仮情報を事実として使わず、掲載根拠を確認します。
A2. いいえ。 実画面を確認し、表示と動作を別に検証します。
A3. いいえ。 コードの公開範囲とサイトの閲覧範囲は別です。[S14]
A4. 消しません。 意図的な表現の組み合わせとして残し、画像と実装で成立するかを試します。

このガイドの修了条件

採用画像と3つの文書があり、動くサイトを開ける。掲載情報と主要な操作を確認できる。公開の可否を説明でき、正常な版へ戻せる。公開権限がある場合は、実URLでの確認まで完了している。

公開待ちでも学習は進められます。 ただし「ローカル完成」「公開準備完了」「公開・実機確認完了」は区別して記録してください。

GitHubとリポジトリについては公式の用語説明も参照できます。[S14]

特に覚える区別

制作データ ≠ 公開用データ。
ローカルで動いた ≠ インターネットに公開された。
環境変数に入れた ≠ ブラウザへ漏れない。
AIが回答した ≠ 実際に確認した。

分からない操作が出たら、「何のための操作で、どこに影響し、失敗したらどう戻すか」を説明してもらってから進めます。