コラム
実践編 第4回：ホームページの"修正"をAIで進める【行政書士×開業×AI】
Q：ホームページをAIで作成してみたけど、レイアウトやコンテンツ、フォームやブログ機能まで含めて修正したい場合はどうする？ A：多くの場合は、現…
<p><strong>Q：ホームページをAIで作成してみたけど、レイアウトやコンテンツ、フォームやブログ機能まで含めて修正したい場合はどうする？<br />
A：</strong>多くの場合は、現状ソースと「目的（1行）」「修正範囲（4分類）」「触らない領域」をまとめて渡し、AIに"修正後ソース（ファイル単位）＋変更点一覧（差分）＋動作確認項目"まで一括で出させると進めやすいです。 ただし、入力の長さや扱える形式は環境により異なるため、難しい場合は対象を分割して進めます。この回では、出力形式の指定を先に固め、コピペ用プロンプト（修正指示書）のテンプレートまで揃えます。</p>
<hr />
<p>第1〜3回でホームページを形にできても、「ここだけ直したい」が積み重なると手が止まりがちです。特に、レイアウト・文章・導線に加えて、フォームやブログ機能など"動く部分"が絡むと、どこから手を付けるべきか迷いやすくなります。</p>
<p>そこで今回は、修正指示書（コピペ用プロンプト）を使い、AIに修正自体をさせたうえで、修正後ソースと差分まで出させる流れを中心にまとめます。うまくいかないときの代替手順（小分け修正）も含め、実務で回しやすい形に整理します。</p>
<hr />
<h2>1. 最初に3つそろえる：目的・現状ソース・修正範囲</h2>
<h3>目的は「1行」だけにする（例：不安を減らし問い合わせ増）</h3>
<p>修正が止まる最大の原因は、要望が膨らんで"目的"が散ることです。まずは目的を1行に固定します。</p>
<p><strong>例：</strong></p>
<ul>
<li>不安を減らし、問い合わせの一歩目を軽くする</li>
<li>料金と流れを明確にし、相談前の迷いを減らす</li>
<li>フォーム離脱を減らし、送信完了まで到達させる</li>
</ul>
<p>この1行が、修正指示書の「軸」になります。</p>
<h3>現状ソースを「HTML/CSS/JS」と「文章」に分けて用意する</h3>
<p>AIに修正させるときは、入力を次の2束に分けると破綻しにくくなります。</p>
<p><strong>ソース束（HTML/CSS/JS、テンプレート、設定ファイル等）</strong></p>
<ul>
<li>可能ならファイル名つきで用意する（例：index.html / style.css / main.js）</li>
</ul>
<p><strong>文章束（ページ内の文章・導線テキスト・注意書き等）</strong></p>
<ul>
<li>ソースに埋め込まれていても、別途「抽出した文章」として渡すと指示が通りやすくなります</li>
</ul>
<blockquote>
<p><strong>つまずきやすいポイント：</strong> 貼り付けが長すぎて途中で欠けることがあります。 <strong>回避策：</strong> まずは「対象ページ」「対象機能」「対象ファイル」だけに絞り、1ファイルずつ進めます（後半の代替手順参照）。</p>
</blockquote>
<h3>修正範囲を4分類する（レイアウト／コンテンツ／表現／機能）</h3>
<p>修正指示は、最初に4分類してラベルを付けると混乱が減ります。</p>
<ul>
<li><strong>レイアウト：</strong> 配置、余白、色、レスポンシブ、見出し階層の見え方</li>
<li><strong>コンテンツ：</strong> サービス説明、料金、流れ、よくある質問、導線の不足</li>
<li><strong>表現：</strong> 断定の強さ、読みやすさ、専門用語の言い換え、安心材料の出し方</li>
<li><strong>機能：</strong> フォーム項目、送信後表示、ブログ一覧/詳細、動作するUI</li>
</ul>
<blockquote>
<p><strong>つまずきやすいポイント：</strong> やりたいことが多すぎて指示が長文化し、軸がぶれます。 <strong>回避策：</strong> 4分類のうち"今回触るもの"だけ残し、優先順位を1〜3つに絞ります。</p>
</blockquote>
<hr />
<h2>2. 修正の頼み方は2択：丸ごと再生成より「差分指定」で安定する</h2>
<h3>「差分で出す」指定（どこを／何を／どう変える）</h3>
<p>AIに任せるときの基本は、<strong>差分指定</strong>です。「全体を直して」ではなく、次の3点をセットにします。</p>
<ul>
<li>どのページ／どの機能を対象にするか</li>
<li>何を変えるか（目的に直結する内容）</li>
<li>どう変えるか（制約、触らない領域、優先順位）</li>
</ul>
<p>なぜ差分指定が有効なのか、丸ごと再生成と比較します。</p>
<table style="width: 961.778px;">
<thead>
<tr>
<th style="width: 153px;">項目</th>
<th style="width: 383px;">丸ごと再生成</th>
<th style="width: 404px;">差分指定（推奨）</th>
</tr>
</thead>
<tbody>
<tr>
<td style="width: 153px;">精度</td>
<td style="width: 383px;">予期せぬ箇所が書き換わるリスクが高い</td>
<td style="width: 404px;">修正箇所が限定され、崩れにくい</td>
</tr>
<tr>
<td style="width: 153px;">確認コスト</td>
<td style="width: 383px;">全行のチェックが必要になりがち</td>
<td style="width: 404px;">提示された差分（変更点一覧）の確認が中心</td>
</tr>
<tr>
<td style="width: 153px;">再現性</td>
<td style="width: 383px;">指示の揺れや出力のブレが出やすい</td>
<td style="width: 404px;">既存構造を維持したまま微調整しやすい</td>
</tr>
</tbody>
</table>
<h3>「置換できる形で出す」指定（ファイル名・該当箇所・修正後）</h3>
<p>出力形式は、反映作業のしやすさを左右します。AIには置換できる形で出させます。</p>
<ul>
<li>ファイル名ごとにコードブロックで出力する</li>
<li>変更箇所の目印を添える（検索キー：該当セクション名、id/class、コメント等）</li>
<li>変更点一覧（差分）として、どのファイルのどの箇所をどう変えたかを示させる</li>
</ul>
<h3>修正後の崩れを減らす制約（触らない領域を決める）</h3>
<p>特にレイアウトや機能は、触らない領域を明記すると安定します。</p>
<p><strong>例：</strong></p>
<ul>
<li>既存のクラス名／ID／関数名／イベント紐付けは原則維持</li>
<li>外部ライブラリの新規導入はしない</li>
<li>フォーム送信先や環境依存値は変更しない（プレースホルダーで表記）</li>
<li>ブログのデータ取得処理は触らない（表示調整のみ）</li>
</ul>
<blockquote>
<p><strong>つまずきやすいポイント：</strong> 見た目だけ直したいのに、構造まで作り替えられて崩れます。 <strong>回避策：</strong> 「必要最小限の変更」「触らない領域」を、修正指示書の先頭に置きます。</p>
</blockquote>
<hr />
<h2>3. PC手順は5ステップ：AIに修正→差分確認→反映まで</h2>
<h3>ステップ1：現状ソースと要望をまとめて貼る</h3>
<ol>
<li>修正対象（ページ／機能）を決めます</li>
<li>ソース束（該当ファイル）を用意します</li>
<li>目的（1行）＋修正範囲（4分類）＋触らない領域を用意します</li>
<li>コピペ用プロンプトに沿って貼り付けます</li>
</ol>
<h3>ステップ2：修正後ソースを「ファイル単位」で出させる</h3>
<ol>
<li>「ファイル名ごとに出力」を指定します</li>
<li>既存ファイルと同じ構成で、修正後ソースを返させます</li>
<li>追加ファイルがある場合は、新規ファイルとして明示させます</li>
</ol>
<h3>ステップ3：差分（変更点一覧）を必ず出させる</h3>
<ol>
<li>変更点一覧を箇条書きで出力させます</li>
<li>各項目に「対象ファイル／検索キー／現状→修正後／目的との関係／副作用チェック」を入れさせます</li>
<li>影響が大きい変更があれば強調させます</li>
</ol>
<h3>ステップ4：ローカルで差し替え→表示崩れを確認する</h3>
<ol>
<li>反映前に、現状ソースを退避します（戻し用）</li>
<li>修正後ソースをファイル単位で差し替えます</li>
<li>PC表示で主要ページを確認します</li>
<li>画面幅を狭めて崩れを確認します（スマートフォン想定）</li>
</ol>
<blockquote>
<p><strong>つまずきやすいポイント：</strong> CSSだけのつもりが、HTML側のクラス名も変わっています。 <strong>回避策：</strong> 差分の「クラス名／ID／イベント紐付け」の変更有無を最優先で確認します。</p>
</blockquote>
<h3>ステップ5：戻せる状態を作ってから公開反映する</h3>
<ol>
<li>いつでも戻せるように、修正前ソースを確保します</li>
<li>公開反映は可能なら段階的（1ページ／1機能ずつ）に行います</li>
<li>フォーム送信やブログ表示など、動作確認が必要な箇所を優先して確認します</li>
</ol>
<h3>（補足）スマートフォンで行う場合の留意点（貼り付け・長文入力・ファイル扱い）</h3>
<p>スマートフォンは「長文貼り付け」「複数ファイルの扱い」で差が出やすいです。多くの場合は次の進め方が現実的です。</p>
<ol>
<li>まずは差分設計（変更点一覧）だけ出させます</li>
<li>対象を絞ります（1ファイル／1機能）</li>
<li>出力形式を固定します（ファイル名→コードブロック→差分→動作確認）</li>
</ol>
<hr />
<p><strong>参考：作業全体の見取り図（AIと人の役割分担）</strong></p>
<pre>
<code>【人】目的1行・範囲4分類・触らない領域を決める
↓
【人】現状ソースを用意（対象を絞って貼る／分割も可）
↓
【AI】修正後ソース（ファイル単位）＋変更点一覧＋動作確認項目を出力
↓
【人】差分（変更点一覧）で影響範囲を確認（クラス名/ID/イベントを優先）
↓
【人】ローカル差し替え→表示・動作確認（フォーム／ブログ）
↓
【人→AI】ズレがあれば追いプロンプトで再修正（最小変更で繰り返す）
↓
【人】戻せる状態で公開反映
</code></pre>
<hr />
<h2>4. コピペ用プロンプトは最低3本：修正指示書テンプレート集</h2>
<h3>基本（汎用テンプレート）：現状→修正後ソース＋差分を出す</h3>
<p><strong>コピペ用プロンプト</strong></p>
<table border="0" cellpadding="1" cellspacing="1" style="width:750px;background-color: #f0f0f0">
<tbody>
<tr>
<td>
<p>あなたは「Webディレクター（要件整理）＋Webデザイナー（UI/可読性）＋Webプログラマー（安全な改修）」として、既存ホームページを改修します。<br />
目的に沿って、現状ソースを土台に「必要最小限の変更」で修正し、差し替え可能な修正後ソースを提出してください。</p>
<p>【機密情報の扱い（必須）】<br />
- パスワード、APIキー/トークン、DB接続情報（接続文字列・ホスト・ユーザー名等）、顧客/依頼者の個人名、実在のメール/電話/住所、管理画面URLなどは入力しない<br />
- 上記がソース内に含まれる場合は、必ず「dummy」等のプレースホルダー（例：DUMMY_PASSWORD）に書き換えてから入力する</p>
<p>【表現の条件（必須）】<br />
- 景品表示法や士業の広告規定に抵触し得る比較優良表示（No.1、最安、最大、必ず、100% 等）は使用しない<br />
- 事実に基づき、必要に応じて前提（期間・対象・範囲）を添える<br />
- 医療・健康等の表現が含まれる場合は、薬機法にも配慮し、断定を避けた文章にする（該当する場合のみ）</p>
<p>【最重要ルール（崩れ防止）】<br />
- 既存のファイル構成・クラス名・ID・関数名・イベント紐付けは原則維持（変更が必要なら理由と影響範囲を明記）<br />
- 外部ライブラリの新規導入はしない（必要なら代替案も提示）<br />
- サーバー設定や認証情報、送信先URLなど環境依存値は変更しない（出力にはプレースホルダーを使う）<br />
- 変更箇所は必ず「差分」と「検索キー（該当箇所の目印）」で追える形にする<br />
- 不足情報がある場合は質問し、仮定する場合は「仮定」と明記する</p>
<p>【目的（1行）】<br />
{例：不安を減らし、問い合わせの一歩目を軽くする}</p>
<p>【修正範囲（4分類で列挙）】<br />
- レイアウト：{例：ファーストビューの余白を詰め、要点を見やすく}<br />
- コンテンツ：{例：料金と流れを追記}<br />
- 表現：{例：断定を避け、読みやすい文章に調整}<br />
- 機能：{例：フォーム項目整理／ブログ一覧表示調整}</p>
<p>【触らない領域（必須）】<br />
{例：ブログのデータ取得処理、フォーム送信処理、管理画面連携}</p>
<p>【出力形式（厳守）】<br />
A) 修正方針（3行）<br />
B) 変更点一覧（10点、各点に「対象ファイル／検索キー／現状→修正後／目的との関係／副作用チェック」を含める）<br />
C) 修正後ソース（ファイル名ごと、必ずコードブロック）<br />
D) 動作確認チェックリスト（最低8点：フォーム導線、入力エラー表示、送信後文章、ブログ一覧、ブログ詳細、レスポンシブ想定、簡易なアクセシビリティ確認の想定、主要導線）<br />
E) 未確定事項（質問／仮定の明記）</p>
<p>【現状ソース】<br />
---ここから---<br />
{ファイル名: 内容 を貼る。複数ファイルなら繰り返す}<br />
---ここまで---</p>
</td>
</tr>
</tbody>
</table>
<p><strong>使いどころ：</strong> 一度で「修正後ソース」「差分」「動作確認」を揃えたいとき。</p>
<p><strong>入力時の注意（プレースホルダー化）：</strong> 機密情報や環境依存値は、必ず「dummy」等に置換してから入力します。</p>
<p><strong>NG例（やりがち）：</strong> 送信先URLやAPIキー等をそのまま貼る（機密漏えいと誤反映の原因になります）。</p>
<hr />
<h3>具体例（匿名化入力例）：レイアウト＋文章＋機能（フォーム／ブログ）を同時に直す</h3>
<p><strong>コピペ用プロンプト</strong></p>
<table border="0" cellpadding="1" cellspacing="1" style="width:750px;background-color: #f0f0f0">
<tbody>
<tr>
<td>
<p>あなたは既存ホームページの改修担当です。目的に沿って、現状ソースを土台に「最小変更」で改修し、差し替え可能な修正後ソースを出してください。</p>
<p>【機密情報の扱い（必須）】<br />
- パスワード、APIキー/トークン、DB接続情報、顧客/依頼者の個人名、実在の連絡先、管理画面URLなどは入力しない<br />
- 含まれる場合は必ず「dummy」等のプレースホルダーに書き換えてから入力する</p>
<p>【表現の条件（必須）】<br />
- 比較優良表示（No.1、最安、最大、必ず、100% 等）は使用しない<br />
- 事実に基づき、必要に応じて前提（期間・対象・範囲）を添える<br />
- 医療・健康等の表現が含まれる場合は薬機法にも配慮し、断定を避けた文章にする（該当する場合のみ）</p>
<p>【目的（1行）】<br />
初回相談の不安を減らし、フォーム送信まで迷わない導線にする</p>
<p>【優先順位つき修正要望】<br />
1. レイアウト：ファーストビューで「取扱業務／地域／相談の流れ」が1画面内で把握できる配置に整理<br />
2. コンテンツ：料金の前提（範囲・例外）と、相談の流れ（3ステップ）を追記<br />
3. 表現：断定を避け、安心材料を増やす（誇大表現は避ける）<br />
4. 機能（フォーム）：項目を「連絡先（必須）／相談概要（必須）／氏名（任意）」に整理し、送信後に表示する案内文章を追加<br />
5. 機能（ブログ）：一覧のカード表示を「スマートフォン想定で1列」になるよう表示調整（データ取得処理は触らない）</p>
<p>【崩れ防止の制約（厳守）】<br />
- 既存のクラス名・ID・関数名・イベント紐付けは維持<br />
- ブログのデータ取得処理（API呼び出し等）と、フォームの送信処理は変更しない（表示と文章のみ調整）<br />
- 環境依存値（送信先URL等）はプレースホルダーで表記<br />
- 不足情報がある場合は質問し、仮定する場合は「仮定」と明記する</p>
<p>【出力形式（厳守）】<br />
A) 修正方針（3行）<br />
B) 変更点一覧（10点：対象ファイル／検索キー／現状→修正後／目的との関係／副作用チェック）<br />
C) 修正後ソース（ファイル名ごと、コードブロック）<br />
D) 動作確認チェックリスト（フォーム導線、入力エラー、送信後文章、ブログ一覧/詳細、レスポンシブ想定）</p>
<p>【現状ソース（例：プレースホルダー化済み）】<br />
---ここから---<br />
index.html:<br />
{...}<br />
style.css:<br />
{...}<br />
main.js:<br />
{...}<br />
---ここまで---</p>
</td>
</tr>
</tbody>
</table>
<p><strong>使いどころ：</strong> 修正要望が複数あるときに、優先順位でブレを抑えたいとき。</p>
<p><strong>入力時の注意（プレースホルダー化）：</strong> 機密情報・環境依存値は「dummy」等へ置換してから入力します。</p>
<p><strong>NG例（やりがち）：</strong> 「サーバー設定も含めて全部直して」（表示調整と環境設定が混ざり、崩れやすくなります）。</p>
<hr />
<h3>編集（追いプロンプト）：意図違い・崩れ・反映しにくさを詰める</h3>
<p><strong>コピペ用プロンプト</strong></p>
<table border="0" cellpadding="1" cellspacing="1" style="width:750px;background-color: #f0f0f0">
<tbody>
<tr>
<td>
<p>出力ありがとうございます。次の問題点を解消するように「最小変更」で再修正してください。<br />
※出力形式（ファイル単位＋変更点一覧＋テスト）は崩さないでください。</p>
<p>【機密情報の扱い（必須）】<br />
- パスワード、APIキー/トークン、DB接続情報、顧客/依頼者の個人名、実在の連絡先、管理画面URLなどは入力しない<br />
- 含まれる場合は必ず「dummy」等のプレースホルダーに書き換える</p>
<p>【表現の条件（必須）】<br />
- 比較優良表示（No.1、最安、最大、必ず、100% 等）は使用しない<br />
- 事実に基づき、必要に応じて前提（期間・対象・範囲）を添える<br />
- 医療・健康等の表現が含まれる場合は薬機法にも配慮し、断定を避けた文章にする（該当する場合のみ）</p>
<p>【問題点（当てはまるものだけ残す）】<br />
- 意図違い：{例：導線が増えすぎて目的（不安を減らす）から外れている}<br />
- 表示崩れ：{例：画面幅を狭めると見出しが重なる／ボタンがはみ出す}<br />
- 機能影響：{例：フォームの必須表示が不自然／送信後文章が出ない}<br />
- 反映しにくい：{例：ファイル単位でなく一塊になっている／どこを置換すべきか分からない}</p>
<p>【再修正のルール（厳守）】<br />
1) 目的（1行）に関係しない追加要素は削る<br />
2) 既存のクラス名・ID・関数名・イベント紐付けは維持<br />
3) CSSは「触るセレクター範囲」を明示し、必要最小限で修正<br />
4) 変更点一覧は「対象ファイル／検索キー／現状→修正後／副作用チェック」を必ず含める<br />
5) 出力は必ず A)方針 B)変更点一覧 C)修正後ソース D)テスト の順</p>
<p>【目的（1行）】<br />
{再掲}</p>
<p>【対象ソース（前回あなたが出した修正後ソース）】<br />
---ここから---<br />
{ファイル名: 内容}<br />
---ここまで---</p>
</td>
</tr>
</tbody>
</table>
<p><strong>使いどころ：</strong> 1回目の出力を"差し替えできる形"に整え直すとき。</p>
<p><strong>入力時の注意（プレースホルダー化）：</strong> 固有情報は「dummy」等に置換してから入力します。</p>
<p><strong>NG例（やりがち）：</strong> 「もっと良くして」だけで、どこが問題かを書かない（同じズレが再発しやすいです）。</p>
<hr />
<h3>（追加）短縮／整形用：文章量と導線を最適化する</h3>
<p><strong>コピペ用プロンプト</strong></p>
<table border="0" cellpadding="1" cellspacing="1" style="width:750px;background-color: #f0f0f0">
<tbody>
<tr>
<td>
<p>あなたはWebのビジネスライター兼編集者です。次のページ内文章を、目的に沿って短縮・整形してください。<br />
※意味を変えず、読みやすさと導線（次に何をするか）を最優先します。</p>
<p>【表現の条件（必須）】<br />
- 比較優良表示（No.1、最安、最大、必ず、100% 等）は使用しない<br />
- 事実に基づき、必要に応じて前提（期間・対象・範囲）を添える<br />
- 医療・健康等の表現が含まれる場合は薬機法にも配慮し、断定を避けた文章にする（該当する場合のみ）</p>
<p>【目的（1行）】<br />
{例：料金と流れを明確にし、問い合わせまで迷わない文章にする}</p>
<p>【条件】<br />
- 断定を避ける（「一般的には」「場合によっては」を適切に使用）<br />
- 1文を長くしない<br />
- 見出し→要点→次の行動（フォームへ）を明確にする<br />
- できれば「取扱範囲／料金の前提／流れ／よくある質問」を不足なく配置</p>
<p>【出力形式】<br />
1) 直し方針（2行）<br />
2) 修正後の文章（見出し構造つき）<br />
3) 置換指示（どの見出しの下を差し替えるか、箇条書きで）</p>
<p>---対象文章---<br />
{貼り付け}</p>
</td>
</tr>
</tbody>
</table>
<p><strong>使いどころ：</strong> ページが長くなり、要点と導線が埋もれたときの整形に使います。</p>
<p><strong>入力時の注意：</strong> 固有の事例・固有名詞は一般化した文章に置き換えます。</p>
<p><strong>NG例（やりがち）：</strong> 料金や流れを削りすぎて、次の行動が分からない文章にする（導線が弱くなります）。</p>
<hr />
<h3>（追加）ファクト確認／安全表現化：誤認誘発・断定を避ける文章に寄せる</h3>
<p><strong>コピペ用プロンプト</strong></p>
<table border="0" cellpadding="1" cellspacing="1" style="width:750px;background-color: #f0f0f0">
<tbody>
<tr>
<td>
<p>あなたは編集者として、次の文章に「誤認誘発」「断定が強い表現」「誇大に見える表現」「比較優良表示」がないか点検し、安全側の言い回しに修正してください。<br />
※意味はできるだけ維持し、必要なら前提（範囲・条件）を補ってください。<br />
※医療・健康等の表現が含まれる場合は、薬機法にも配慮して断定を避けてください（該当する場合のみ）。</p>
<p>【出力形式】<br />
1) リスクがある表現（最大10個）<br />
2) 安全側の修正案（現状→修正後、理由を1行）<br />
3) 修正後の全文章（読みやすい見出し構造つき）</p>
<p>---対象文章---<br />
{貼り付け}</p>
</td>
</tr>
</tbody>
</table>
<p><strong>使いどころ：</strong> 公開前に「強すぎる表現」を減らし、誤解されにくい文章へ寄せたいとき。</p>
<p><strong>入力時の注意：</strong> 推測につながる固有情報は避け、一般化した文章で点検します。</p>
<p><strong>NG例（やりがち）：</strong> 「必ず」「100%」などの断定を残したまま公開する（誤解につながりやすいです）。</p>
<hr />
<h2>5. 直すポイントは4分類で迷わない：レイアウト／文章／導線／機能</h2>
<h3>レイアウト修正：余白・並び・レスポンシブの指示の出し方</h3>
<p>レイアウトは「見た目」だけでなく「読ませたい順」の設計です。指示は次の順にすると通りやすくなります。</p>
<ol>
<li>先に見せたい要素（取扱業務・地域・流れ等）</li>
<li>並び順</li>
<li>余白やサイズの方向性（詰める／広げる）</li>
<li>画面幅を狭めたときの対応（1列化など）</li>
</ol>
<h3>コンテンツ修正：サービス説明・料金・流れの不足を埋める</h3>
<p>「何を頼めるか」「いくら／どのくらいかかるか」「次に何をするか」が揃うと、問い合わせまでの迷いが減ります。料金の前提（範囲・例外）と、流れ（最初の一歩）は不足しやすいため、優先して補います。</p>
<h3>表現修正：言い過ぎ回避・読みやすさ・専門用語の置き換え</h3>
<p>対外文章は、断定が強いと誤解を招きやすいです。「一般的には」「場合によっては」を適切に挟みつつ、比較優良表示に見える言い回しを避けると安全側に寄ります。</p>
<h3>機能修正：フォーム項目・送信後表示・ブログ一覧/詳細の直し方</h3>
<p>機能は「見える部分」と「動く部分」を分けると事故が減ります。</p>
<ul>
<li><strong>見える部分：</strong> フォーム項目の並び、ラベル、送信後の案内文章、ブログ一覧の表示</li>
<li><strong>動く部分：</strong> 送信処理、バリデーション、データ取得</li>
</ul>
<p>修正指示書では、まず「表示と文章」を優先し、動く部分を触る場合は理由と影響範囲を明示させます。</p>
<h3>実績・クチコミ文章の直し方：実績が少ない場合の代替安心材料も含める</h3>
<p>実績が少ない時期は珍しくありません。その場合は、次のような"代替の安心材料"を文章として整えます。</p>
<ul>
<li>取扱テーマの範囲（何ができて／何ができないか）</li>
<li>相談時の進め方（ヒアリング→見通し提示→次の行動）</li>
<li>学びや研鑽の蓄積（一般化した言い方）</li>
<li>地域性・対応方針（分かりやすさ、連絡の取り方等）</li>
</ul>
<blockquote>
<p>※比較優良表示に見える表現は避け、数値や実績を出す場合は前提（期間・対象・母数）を添えます。</p>
</blockquote>
<h3>強み文章の直し方：強みが分からないときのAI壁打ち（整理・言語化）</h3>
<p>「強みが分からない」は開業前後によく起きます。ここはAIに"決めさせる"のではなく、壁打ちで整理します。得意な相談の型／説明が得意な場面／避けたい案件の傾向を箇条書きにし、ホームページの文章へ落とし込みます。</p>
<blockquote>
<p>※比較優良表示に見える言い回し（最強、No.1等）は避け、事実に基づく範囲の表現に寄せます。</p>
</blockquote>
<hr />
<h2>6. つまずきポイントは7つ：崩れる・動かない・反映できないの対策</h2>
<h3>崩れる：CSSを触りすぎた／クラス名が変わった</h3>
<p><strong>対策：</strong> クラス名は変えない前提にします。CSSは"触るセレクター範囲"を指定し、必要最小限に絞ります。</p>
<h3>動かない：JSの依存関係が壊れた／イベントが消えた</h3>
<p><strong>対策：</strong> 関数名・イベント紐付けを維持します。変更が必要なら、理由／該当箇所／動作確認項目をセットで出させます。</p>
<h3>フォームが送れない：必須項目・バリデーション・送信先の不整合</h3>
<p><strong>対策：</strong> フォームは「表示」と「送信」を分けます。送信先など環境依存値はプレースホルダーで扱い、反映前に確認します。</p>
<h3>ブログが表示されない：一覧と詳細の参照先・テンプレートの不一致</h3>
<p><strong>対策：</strong> 一覧と詳細の参照関係（リンク先、テンプレート）を変える場合は、差分でセット提示させます。</p>
<h3>差分が追えない：出力形式がバラバラ（統一させる追い指示）</h3>
<p><strong>対策：</strong> ファイル名→コードブロック→差分→動作確認、の順に固定します。崩れたら追いプロンプトで矯正します。</p>
<h3>意図と違う：目的・優先順位・触らない領域が曖昧</h3>
<p><strong>対策：</strong> 目的1行＋優先順位＋触らない領域を必ず入れます。ここが弱いほど、別方向に進みやすくなります。</p>
<h3>代替手順：小分け修正（1ファイルずつ／1機能ずつ）に切り替える</h3>
<p><strong>対策：</strong> うまくいかないときは範囲を絞って進めます。例として、style.cssだけ → index.htmlの特定セクションだけ → フォーム表示だけ、の順に行います。</p>
<hr />
<h2>7. 最後に3チェック：速くするほど確認が重要になる</h2>
<h3>表示チェック（PC/スマートフォン想定・主要ブラウザー想定）</h3>
<ol>
<li>PC表示で主要ページを確認します</li>
<li>画面幅を狭めた表示を確認します（スマートフォン想定）</li>
<li>見出し階層と余白が意図通りか確認します</li>
</ol>
<h3>導線チェック（問い合わせまで迷わない文章か）</h3>
<p>次の3点がページ内で迷わず追えるか確認します。</p>
<ol>
<li>何を頼めるか</li>
<li>いくら／どのくらいかかるか</li>
<li>次に何をするか（フォームへ）</li>
</ol>
<h3>公開前チェック（バックアップ・戻し方・影響範囲）</h3>
<ol>
<li>修正前ソースを戻せる状態にします</li>
<li>影響範囲（他ページ・他機能）を想定します</li>
<li>フォーム送信、ブログ表示など"動作"を優先して確認します</li>
<li>公開する文章に、誤認誘発・断定・比較優良表示に見える表現がないか最終点検します</li>
</ol>
<hr />
<h2>まとめ</h2>
<ul>
<li><strong>「目的1行・範囲4分類」で指示を固定する：</strong> AIのブレを防ぐための必須設定です。</li>
<li><strong>「修正後ソース＋差分＋テスト」をセットで出させる：</strong> 確認負荷を最小化する出力形式です。</li>
<li><strong>「触らない領域」を明文化する：</strong> フォームやJSなど既存機能を壊さないための防衛策です。</li>
</ul>
<hr />
<h2>免責</h2>
<p>本稿は一般情報であり、個別具体の事情に応じた法的判断・個別案件への助言・成果の保証を行うものではありません。画面表示や機能、入力上限等は利用環境により異なる場合があります。</p>
<hr />
<h2>HANAWA行政書士事務所</h2>
<p><a href="https://hanawa-office.jp/">HANAWA行政書士事務所公式サイト</a></p>
<p><a href="https://hanawa-office.jp/AI_knowledge/index.php">AI活用学習サイト</a></p>
<p><a href="https://hanawa-office.jp/blog_detail.php?id=472">前の記事：実践編 第3回：サーバーはどうすればよい？ドメインってなに？取った方がいいの？</a></p>
<p><a href="https://hanawa-office.jp/blog_detail.php?id=478">次の記事：実践編 第5回：GASとGEMの違い｜Geminiの「Gem」で定型化し、GASで自動化する最短ルート</a></p>
A：</strong>多くの場合は、現状ソースと「目的（1行）」「修正範囲（4分類）」「触らない領域」をまとめて渡し、AIに"修正後ソース（ファイル単位）＋変更点一覧（差分）＋動作確認項目"まで一括で出させると進めやすいです。 ただし、入力の長さや扱える形式は環境により異なるため、難しい場合は対象を分割して進めます。この回では、出力形式の指定を先に固め、コピペ用プロンプト（修正指示書）のテンプレートまで揃えます。</p>
<hr />
<p>第1〜3回でホームページを形にできても、「ここだけ直したい」が積み重なると手が止まりがちです。特に、レイアウト・文章・導線に加えて、フォームやブログ機能など"動く部分"が絡むと、どこから手を付けるべきか迷いやすくなります。</p>
<p>そこで今回は、修正指示書（コピペ用プロンプト）を使い、AIに修正自体をさせたうえで、修正後ソースと差分まで出させる流れを中心にまとめます。うまくいかないときの代替手順（小分け修正）も含め、実務で回しやすい形に整理します。</p>
<hr />
<h2>1. 最初に3つそろえる：目的・現状ソース・修正範囲</h2>
<h3>目的は「1行」だけにする（例：不安を減らし問い合わせ増）</h3>
<p>修正が止まる最大の原因は、要望が膨らんで"目的"が散ることです。まずは目的を1行に固定します。</p>
<p><strong>例：</strong></p>
<ul>
<li>不安を減らし、問い合わせの一歩目を軽くする</li>
<li>料金と流れを明確にし、相談前の迷いを減らす</li>
<li>フォーム離脱を減らし、送信完了まで到達させる</li>
</ul>
<p>この1行が、修正指示書の「軸」になります。</p>
<h3>現状ソースを「HTML/CSS/JS」と「文章」に分けて用意する</h3>
<p>AIに修正させるときは、入力を次の2束に分けると破綻しにくくなります。</p>
<p><strong>ソース束（HTML/CSS/JS、テンプレート、設定ファイル等）</strong></p>
<ul>
<li>可能ならファイル名つきで用意する（例：index.html / style.css / main.js）</li>
</ul>
<p><strong>文章束（ページ内の文章・導線テキスト・注意書き等）</strong></p>
<ul>
<li>ソースに埋め込まれていても、別途「抽出した文章」として渡すと指示が通りやすくなります</li>
</ul>
<blockquote>
<p><strong>つまずきやすいポイント：</strong> 貼り付けが長すぎて途中で欠けることがあります。 <strong>回避策：</strong> まずは「対象ページ」「対象機能」「対象ファイル」だけに絞り、1ファイルずつ進めます（後半の代替手順参照）。</p>
</blockquote>
<h3>修正範囲を4分類する（レイアウト／コンテンツ／表現／機能）</h3>
<p>修正指示は、最初に4分類してラベルを付けると混乱が減ります。</p>
<ul>
<li><strong>レイアウト：</strong> 配置、余白、色、レスポンシブ、見出し階層の見え方</li>
<li><strong>コンテンツ：</strong> サービス説明、料金、流れ、よくある質問、導線の不足</li>
<li><strong>表現：</strong> 断定の強さ、読みやすさ、専門用語の言い換え、安心材料の出し方</li>
<li><strong>機能：</strong> フォーム項目、送信後表示、ブログ一覧/詳細、動作するUI</li>
</ul>
<blockquote>
<p><strong>つまずきやすいポイント：</strong> やりたいことが多すぎて指示が長文化し、軸がぶれます。 <strong>回避策：</strong> 4分類のうち"今回触るもの"だけ残し、優先順位を1〜3つに絞ります。</p>
</blockquote>
<hr />
<h2>2. 修正の頼み方は2択：丸ごと再生成より「差分指定」で安定する</h2>
<h3>「差分で出す」指定（どこを／何を／どう変える）</h3>
<p>AIに任せるときの基本は、<strong>差分指定</strong>です。「全体を直して」ではなく、次の3点をセットにします。</p>
<ul>
<li>どのページ／どの機能を対象にするか</li>
<li>何を変えるか（目的に直結する内容）</li>
<li>どう変えるか（制約、触らない領域、優先順位）</li>
</ul>
<p>なぜ差分指定が有効なのか、丸ごと再生成と比較します。</p>
<table style="width: 961.778px;">
<thead>
<tr>
<th style="width: 153px;">項目</th>
<th style="width: 383px;">丸ごと再生成</th>
<th style="width: 404px;">差分指定（推奨）</th>
</tr>
</thead>
<tbody>
<tr>
<td style="width: 153px;">精度</td>
<td style="width: 383px;">予期せぬ箇所が書き換わるリスクが高い</td>
<td style="width: 404px;">修正箇所が限定され、崩れにくい</td>
</tr>
<tr>
<td style="width: 153px;">確認コスト</td>
<td style="width: 383px;">全行のチェックが必要になりがち</td>
<td style="width: 404px;">提示された差分（変更点一覧）の確認が中心</td>
</tr>
<tr>
<td style="width: 153px;">再現性</td>
<td style="width: 383px;">指示の揺れや出力のブレが出やすい</td>
<td style="width: 404px;">既存構造を維持したまま微調整しやすい</td>
</tr>
</tbody>
</table>
<h3>「置換できる形で出す」指定（ファイル名・該当箇所・修正後）</h3>
<p>出力形式は、反映作業のしやすさを左右します。AIには置換できる形で出させます。</p>
<ul>
<li>ファイル名ごとにコードブロックで出力する</li>
<li>変更箇所の目印を添える（検索キー：該当セクション名、id/class、コメント等）</li>
<li>変更点一覧（差分）として、どのファイルのどの箇所をどう変えたかを示させる</li>
</ul>
<h3>修正後の崩れを減らす制約（触らない領域を決める）</h3>
<p>特にレイアウトや機能は、触らない領域を明記すると安定します。</p>
<p><strong>例：</strong></p>
<ul>
<li>既存のクラス名／ID／関数名／イベント紐付けは原則維持</li>
<li>外部ライブラリの新規導入はしない</li>
<li>フォーム送信先や環境依存値は変更しない（プレースホルダーで表記）</li>
<li>ブログのデータ取得処理は触らない（表示調整のみ）</li>
</ul>
<blockquote>
<p><strong>つまずきやすいポイント：</strong> 見た目だけ直したいのに、構造まで作り替えられて崩れます。 <strong>回避策：</strong> 「必要最小限の変更」「触らない領域」を、修正指示書の先頭に置きます。</p>
</blockquote>
<hr />
<h2>3. PC手順は5ステップ：AIに修正→差分確認→反映まで</h2>
<h3>ステップ1：現状ソースと要望をまとめて貼る</h3>
<ol>
<li>修正対象（ページ／機能）を決めます</li>
<li>ソース束（該当ファイル）を用意します</li>
<li>目的（1行）＋修正範囲（4分類）＋触らない領域を用意します</li>
<li>コピペ用プロンプトに沿って貼り付けます</li>
</ol>
<h3>ステップ2：修正後ソースを「ファイル単位」で出させる</h3>
<ol>
<li>「ファイル名ごとに出力」を指定します</li>
<li>既存ファイルと同じ構成で、修正後ソースを返させます</li>
<li>追加ファイルがある場合は、新規ファイルとして明示させます</li>
</ol>
<h3>ステップ3：差分（変更点一覧）を必ず出させる</h3>
<ol>
<li>変更点一覧を箇条書きで出力させます</li>
<li>各項目に「対象ファイル／検索キー／現状→修正後／目的との関係／副作用チェック」を入れさせます</li>
<li>影響が大きい変更があれば強調させます</li>
</ol>
<h3>ステップ4：ローカルで差し替え→表示崩れを確認する</h3>
<ol>
<li>反映前に、現状ソースを退避します（戻し用）</li>
<li>修正後ソースをファイル単位で差し替えます</li>
<li>PC表示で主要ページを確認します</li>
<li>画面幅を狭めて崩れを確認します（スマートフォン想定）</li>
</ol>
<blockquote>
<p><strong>つまずきやすいポイント：</strong> CSSだけのつもりが、HTML側のクラス名も変わっています。 <strong>回避策：</strong> 差分の「クラス名／ID／イベント紐付け」の変更有無を最優先で確認します。</p>
</blockquote>
<h3>ステップ5：戻せる状態を作ってから公開反映する</h3>
<ol>
<li>いつでも戻せるように、修正前ソースを確保します</li>
<li>公開反映は可能なら段階的（1ページ／1機能ずつ）に行います</li>
<li>フォーム送信やブログ表示など、動作確認が必要な箇所を優先して確認します</li>
</ol>
<h3>（補足）スマートフォンで行う場合の留意点（貼り付け・長文入力・ファイル扱い）</h3>
<p>スマートフォンは「長文貼り付け」「複数ファイルの扱い」で差が出やすいです。多くの場合は次の進め方が現実的です。</p>
<ol>
<li>まずは差分設計（変更点一覧）だけ出させます</li>
<li>対象を絞ります（1ファイル／1機能）</li>
<li>出力形式を固定します（ファイル名→コードブロック→差分→動作確認）</li>
</ol>
<hr />
<p><strong>参考：作業全体の見取り図（AIと人の役割分担）</strong></p>
<pre>
<code>【人】目的1行・範囲4分類・触らない領域を決める
↓
【人】現状ソースを用意（対象を絞って貼る／分割も可）
↓
【AI】修正後ソース（ファイル単位）＋変更点一覧＋動作確認項目を出力
↓
【人】差分（変更点一覧）で影響範囲を確認（クラス名/ID/イベントを優先）
↓
【人】ローカル差し替え→表示・動作確認（フォーム／ブログ）
↓
【人→AI】ズレがあれば追いプロンプトで再修正（最小変更で繰り返す）
↓
【人】戻せる状態で公開反映
</code></pre>
<hr />
<h2>4. コピペ用プロンプトは最低3本：修正指示書テンプレート集</h2>
<h3>基本（汎用テンプレート）：現状→修正後ソース＋差分を出す</h3>
<p><strong>コピペ用プロンプト</strong></p>
<table border="0" cellpadding="1" cellspacing="1" style="width:750px;background-color: #f0f0f0">
<tbody>
<tr>
<td>
<p>あなたは「Webディレクター（要件整理）＋Webデザイナー（UI/可読性）＋Webプログラマー（安全な改修）」として、既存ホームページを改修します。<br />
目的に沿って、現状ソースを土台に「必要最小限の変更」で修正し、差し替え可能な修正後ソースを提出してください。</p>
<p>【機密情報の扱い（必須）】<br />
- パスワード、APIキー/トークン、DB接続情報（接続文字列・ホスト・ユーザー名等）、顧客/依頼者の個人名、実在のメール/電話/住所、管理画面URLなどは入力しない<br />
- 上記がソース内に含まれる場合は、必ず「dummy」等のプレースホルダー（例：DUMMY_PASSWORD）に書き換えてから入力する</p>
<p>【表現の条件（必須）】<br />
- 景品表示法や士業の広告規定に抵触し得る比較優良表示（No.1、最安、最大、必ず、100% 等）は使用しない<br />
- 事実に基づき、必要に応じて前提（期間・対象・範囲）を添える<br />
- 医療・健康等の表現が含まれる場合は、薬機法にも配慮し、断定を避けた文章にする（該当する場合のみ）</p>
<p>【最重要ルール（崩れ防止）】<br />
- 既存のファイル構成・クラス名・ID・関数名・イベント紐付けは原則維持（変更が必要なら理由と影響範囲を明記）<br />
- 外部ライブラリの新規導入はしない（必要なら代替案も提示）<br />
- サーバー設定や認証情報、送信先URLなど環境依存値は変更しない（出力にはプレースホルダーを使う）<br />
- 変更箇所は必ず「差分」と「検索キー（該当箇所の目印）」で追える形にする<br />
- 不足情報がある場合は質問し、仮定する場合は「仮定」と明記する</p>
<p>【目的（1行）】<br />
{例：不安を減らし、問い合わせの一歩目を軽くする}</p>
<p>【修正範囲（4分類で列挙）】<br />
- レイアウト：{例：ファーストビューの余白を詰め、要点を見やすく}<br />
- コンテンツ：{例：料金と流れを追記}<br />
- 表現：{例：断定を避け、読みやすい文章に調整}<br />
- 機能：{例：フォーム項目整理／ブログ一覧表示調整}</p>
<p>【触らない領域（必須）】<br />
{例：ブログのデータ取得処理、フォーム送信処理、管理画面連携}</p>
<p>【出力形式（厳守）】<br />
A) 修正方針（3行）<br />
B) 変更点一覧（10点、各点に「対象ファイル／検索キー／現状→修正後／目的との関係／副作用チェック」を含める）<br />
C) 修正後ソース（ファイル名ごと、必ずコードブロック）<br />
D) 動作確認チェックリスト（最低8点：フォーム導線、入力エラー表示、送信後文章、ブログ一覧、ブログ詳細、レスポンシブ想定、簡易なアクセシビリティ確認の想定、主要導線）<br />
E) 未確定事項（質問／仮定の明記）</p>
<p>【現状ソース】<br />
---ここから---<br />
{ファイル名: 内容 を貼る。複数ファイルなら繰り返す}<br />
---ここまで---</p>
</td>
</tr>
</tbody>
</table>
<p><strong>使いどころ：</strong> 一度で「修正後ソース」「差分」「動作確認」を揃えたいとき。</p>
<p><strong>入力時の注意（プレースホルダー化）：</strong> 機密情報や環境依存値は、必ず「dummy」等に置換してから入力します。</p>
<p><strong>NG例（やりがち）：</strong> 送信先URLやAPIキー等をそのまま貼る（機密漏えいと誤反映の原因になります）。</p>
<hr />
<h3>具体例（匿名化入力例）：レイアウト＋文章＋機能（フォーム／ブログ）を同時に直す</h3>
<p><strong>コピペ用プロンプト</strong></p>
<table border="0" cellpadding="1" cellspacing="1" style="width:750px;background-color: #f0f0f0">
<tbody>
<tr>
<td>
<p>あなたは既存ホームページの改修担当です。目的に沿って、現状ソースを土台に「最小変更」で改修し、差し替え可能な修正後ソースを出してください。</p>
<p>【機密情報の扱い（必須）】<br />
- パスワード、APIキー/トークン、DB接続情報、顧客/依頼者の個人名、実在の連絡先、管理画面URLなどは入力しない<br />
- 含まれる場合は必ず「dummy」等のプレースホルダーに書き換えてから入力する</p>
<p>【表現の条件（必須）】<br />
- 比較優良表示（No.1、最安、最大、必ず、100% 等）は使用しない<br />
- 事実に基づき、必要に応じて前提（期間・対象・範囲）を添える<br />
- 医療・健康等の表現が含まれる場合は薬機法にも配慮し、断定を避けた文章にする（該当する場合のみ）</p>
<p>【目的（1行）】<br />
初回相談の不安を減らし、フォーム送信まで迷わない導線にする</p>
<p>【優先順位つき修正要望】<br />
1. レイアウト：ファーストビューで「取扱業務／地域／相談の流れ」が1画面内で把握できる配置に整理<br />
2. コンテンツ：料金の前提（範囲・例外）と、相談の流れ（3ステップ）を追記<br />
3. 表現：断定を避け、安心材料を増やす（誇大表現は避ける）<br />
4. 機能（フォーム）：項目を「連絡先（必須）／相談概要（必須）／氏名（任意）」に整理し、送信後に表示する案内文章を追加<br />
5. 機能（ブログ）：一覧のカード表示を「スマートフォン想定で1列」になるよう表示調整（データ取得処理は触らない）</p>
<p>【崩れ防止の制約（厳守）】<br />
- 既存のクラス名・ID・関数名・イベント紐付けは維持<br />
- ブログのデータ取得処理（API呼び出し等）と、フォームの送信処理は変更しない（表示と文章のみ調整）<br />
- 環境依存値（送信先URL等）はプレースホルダーで表記<br />
- 不足情報がある場合は質問し、仮定する場合は「仮定」と明記する</p>
<p>【出力形式（厳守）】<br />
A) 修正方針（3行）<br />
B) 変更点一覧（10点：対象ファイル／検索キー／現状→修正後／目的との関係／副作用チェック）<br />
C) 修正後ソース（ファイル名ごと、コードブロック）<br />
D) 動作確認チェックリスト（フォーム導線、入力エラー、送信後文章、ブログ一覧/詳細、レスポンシブ想定）</p>
<p>【現状ソース（例：プレースホルダー化済み）】<br />
---ここから---<br />
index.html:<br />
{...}<br />
style.css:<br />
{...}<br />
main.js:<br />
{...}<br />
---ここまで---</p>
</td>
</tr>
</tbody>
</table>
<p><strong>使いどころ：</strong> 修正要望が複数あるときに、優先順位でブレを抑えたいとき。</p>
<p><strong>入力時の注意（プレースホルダー化）：</strong> 機密情報・環境依存値は「dummy」等へ置換してから入力します。</p>
<p><strong>NG例（やりがち）：</strong> 「サーバー設定も含めて全部直して」（表示調整と環境設定が混ざり、崩れやすくなります）。</p>
<hr />
<h3>編集（追いプロンプト）：意図違い・崩れ・反映しにくさを詰める</h3>
<p><strong>コピペ用プロンプト</strong></p>
<table border="0" cellpadding="1" cellspacing="1" style="width:750px;background-color: #f0f0f0">
<tbody>
<tr>
<td>
<p>出力ありがとうございます。次の問題点を解消するように「最小変更」で再修正してください。<br />
※出力形式（ファイル単位＋変更点一覧＋テスト）は崩さないでください。</p>
<p>【機密情報の扱い（必須）】<br />
- パスワード、APIキー/トークン、DB接続情報、顧客/依頼者の個人名、実在の連絡先、管理画面URLなどは入力しない<br />
- 含まれる場合は必ず「dummy」等のプレースホルダーに書き換える</p>
<p>【表現の条件（必須）】<br />
- 比較優良表示（No.1、最安、最大、必ず、100% 等）は使用しない<br />
- 事実に基づき、必要に応じて前提（期間・対象・範囲）を添える<br />
- 医療・健康等の表現が含まれる場合は薬機法にも配慮し、断定を避けた文章にする（該当する場合のみ）</p>
<p>【問題点（当てはまるものだけ残す）】<br />
- 意図違い：{例：導線が増えすぎて目的（不安を減らす）から外れている}<br />
- 表示崩れ：{例：画面幅を狭めると見出しが重なる／ボタンがはみ出す}<br />
- 機能影響：{例：フォームの必須表示が不自然／送信後文章が出ない}<br />
- 反映しにくい：{例：ファイル単位でなく一塊になっている／どこを置換すべきか分からない}</p>
<p>【再修正のルール（厳守）】<br />
1) 目的（1行）に関係しない追加要素は削る<br />
2) 既存のクラス名・ID・関数名・イベント紐付けは維持<br />
3) CSSは「触るセレクター範囲」を明示し、必要最小限で修正<br />
4) 変更点一覧は「対象ファイル／検索キー／現状→修正後／副作用チェック」を必ず含める<br />
5) 出力は必ず A)方針 B)変更点一覧 C)修正後ソース D)テスト の順</p>
<p>【目的（1行）】<br />
{再掲}</p>
<p>【対象ソース（前回あなたが出した修正後ソース）】<br />
---ここから---<br />
{ファイル名: 内容}<br />
---ここまで---</p>
</td>
</tr>
</tbody>
</table>
<p><strong>使いどころ：</strong> 1回目の出力を"差し替えできる形"に整え直すとき。</p>
<p><strong>入力時の注意（プレースホルダー化）：</strong> 固有情報は「dummy」等に置換してから入力します。</p>
<p><strong>NG例（やりがち）：</strong> 「もっと良くして」だけで、どこが問題かを書かない（同じズレが再発しやすいです）。</p>
<hr />
<h3>（追加）短縮／整形用：文章量と導線を最適化する</h3>
<p><strong>コピペ用プロンプト</strong></p>
<table border="0" cellpadding="1" cellspacing="1" style="width:750px;background-color: #f0f0f0">
<tbody>
<tr>
<td>
<p>あなたはWebのビジネスライター兼編集者です。次のページ内文章を、目的に沿って短縮・整形してください。<br />
※意味を変えず、読みやすさと導線（次に何をするか）を最優先します。</p>
<p>【表現の条件（必須）】<br />
- 比較優良表示（No.1、最安、最大、必ず、100% 等）は使用しない<br />
- 事実に基づき、必要に応じて前提（期間・対象・範囲）を添える<br />
- 医療・健康等の表現が含まれる場合は薬機法にも配慮し、断定を避けた文章にする（該当する場合のみ）</p>
<p>【目的（1行）】<br />
{例：料金と流れを明確にし、問い合わせまで迷わない文章にする}</p>
<p>【条件】<br />
- 断定を避ける（「一般的には」「場合によっては」を適切に使用）<br />
- 1文を長くしない<br />
- 見出し→要点→次の行動（フォームへ）を明確にする<br />
- できれば「取扱範囲／料金の前提／流れ／よくある質問」を不足なく配置</p>
<p>【出力形式】<br />
1) 直し方針（2行）<br />
2) 修正後の文章（見出し構造つき）<br />
3) 置換指示（どの見出しの下を差し替えるか、箇条書きで）</p>
<p>---対象文章---<br />
{貼り付け}</p>
</td>
</tr>
</tbody>
</table>
<p><strong>使いどころ：</strong> ページが長くなり、要点と導線が埋もれたときの整形に使います。</p>
<p><strong>入力時の注意：</strong> 固有の事例・固有名詞は一般化した文章に置き換えます。</p>
<p><strong>NG例（やりがち）：</strong> 料金や流れを削りすぎて、次の行動が分からない文章にする（導線が弱くなります）。</p>
<hr />
<h3>（追加）ファクト確認／安全表現化：誤認誘発・断定を避ける文章に寄せる</h3>
<p><strong>コピペ用プロンプト</strong></p>
<table border="0" cellpadding="1" cellspacing="1" style="width:750px;background-color: #f0f0f0">
<tbody>
<tr>
<td>
<p>あなたは編集者として、次の文章に「誤認誘発」「断定が強い表現」「誇大に見える表現」「比較優良表示」がないか点検し、安全側の言い回しに修正してください。<br />
※意味はできるだけ維持し、必要なら前提（範囲・条件）を補ってください。<br />
※医療・健康等の表現が含まれる場合は、薬機法にも配慮して断定を避けてください（該当する場合のみ）。</p>
<p>【出力形式】<br />
1) リスクがある表現（最大10個）<br />
2) 安全側の修正案（現状→修正後、理由を1行）<br />
3) 修正後の全文章（読みやすい見出し構造つき）</p>
<p>---対象文章---<br />
{貼り付け}</p>
</td>
</tr>
</tbody>
</table>
<p><strong>使いどころ：</strong> 公開前に「強すぎる表現」を減らし、誤解されにくい文章へ寄せたいとき。</p>
<p><strong>入力時の注意：</strong> 推測につながる固有情報は避け、一般化した文章で点検します。</p>
<p><strong>NG例（やりがち）：</strong> 「必ず」「100%」などの断定を残したまま公開する（誤解につながりやすいです）。</p>
<hr />
<h2>5. 直すポイントは4分類で迷わない：レイアウト／文章／導線／機能</h2>
<h3>レイアウト修正：余白・並び・レスポンシブの指示の出し方</h3>
<p>レイアウトは「見た目」だけでなく「読ませたい順」の設計です。指示は次の順にすると通りやすくなります。</p>
<ol>
<li>先に見せたい要素（取扱業務・地域・流れ等）</li>
<li>並び順</li>
<li>余白やサイズの方向性（詰める／広げる）</li>
<li>画面幅を狭めたときの対応（1列化など）</li>
</ol>
<h3>コンテンツ修正：サービス説明・料金・流れの不足を埋める</h3>
<p>「何を頼めるか」「いくら／どのくらいかかるか」「次に何をするか」が揃うと、問い合わせまでの迷いが減ります。料金の前提（範囲・例外）と、流れ（最初の一歩）は不足しやすいため、優先して補います。</p>
<h3>表現修正：言い過ぎ回避・読みやすさ・専門用語の置き換え</h3>
<p>対外文章は、断定が強いと誤解を招きやすいです。「一般的には」「場合によっては」を適切に挟みつつ、比較優良表示に見える言い回しを避けると安全側に寄ります。</p>
<h3>機能修正：フォーム項目・送信後表示・ブログ一覧/詳細の直し方</h3>
<p>機能は「見える部分」と「動く部分」を分けると事故が減ります。</p>
<ul>
<li><strong>見える部分：</strong> フォーム項目の並び、ラベル、送信後の案内文章、ブログ一覧の表示</li>
<li><strong>動く部分：</strong> 送信処理、バリデーション、データ取得</li>
</ul>
<p>修正指示書では、まず「表示と文章」を優先し、動く部分を触る場合は理由と影響範囲を明示させます。</p>
<h3>実績・クチコミ文章の直し方：実績が少ない場合の代替安心材料も含める</h3>
<p>実績が少ない時期は珍しくありません。その場合は、次のような"代替の安心材料"を文章として整えます。</p>
<ul>
<li>取扱テーマの範囲（何ができて／何ができないか）</li>
<li>相談時の進め方（ヒアリング→見通し提示→次の行動）</li>
<li>学びや研鑽の蓄積（一般化した言い方）</li>
<li>地域性・対応方針（分かりやすさ、連絡の取り方等）</li>
</ul>
<blockquote>
<p>※比較優良表示に見える表現は避け、数値や実績を出す場合は前提（期間・対象・母数）を添えます。</p>
</blockquote>
<h3>強み文章の直し方：強みが分からないときのAI壁打ち（整理・言語化）</h3>
<p>「強みが分からない」は開業前後によく起きます。ここはAIに"決めさせる"のではなく、壁打ちで整理します。得意な相談の型／説明が得意な場面／避けたい案件の傾向を箇条書きにし、ホームページの文章へ落とし込みます。</p>
<blockquote>
<p>※比較優良表示に見える言い回し（最強、No.1等）は避け、事実に基づく範囲の表現に寄せます。</p>
</blockquote>
<hr />
<h2>6. つまずきポイントは7つ：崩れる・動かない・反映できないの対策</h2>
<h3>崩れる：CSSを触りすぎた／クラス名が変わった</h3>
<p><strong>対策：</strong> クラス名は変えない前提にします。CSSは"触るセレクター範囲"を指定し、必要最小限に絞ります。</p>
<h3>動かない：JSの依存関係が壊れた／イベントが消えた</h3>
<p><strong>対策：</strong> 関数名・イベント紐付けを維持します。変更が必要なら、理由／該当箇所／動作確認項目をセットで出させます。</p>
<h3>フォームが送れない：必須項目・バリデーション・送信先の不整合</h3>
<p><strong>対策：</strong> フォームは「表示」と「送信」を分けます。送信先など環境依存値はプレースホルダーで扱い、反映前に確認します。</p>
<h3>ブログが表示されない：一覧と詳細の参照先・テンプレートの不一致</h3>
<p><strong>対策：</strong> 一覧と詳細の参照関係（リンク先、テンプレート）を変える場合は、差分でセット提示させます。</p>
<h3>差分が追えない：出力形式がバラバラ（統一させる追い指示）</h3>
<p><strong>対策：</strong> ファイル名→コードブロック→差分→動作確認、の順に固定します。崩れたら追いプロンプトで矯正します。</p>
<h3>意図と違う：目的・優先順位・触らない領域が曖昧</h3>
<p><strong>対策：</strong> 目的1行＋優先順位＋触らない領域を必ず入れます。ここが弱いほど、別方向に進みやすくなります。</p>
<h3>代替手順：小分け修正（1ファイルずつ／1機能ずつ）に切り替える</h3>
<p><strong>対策：</strong> うまくいかないときは範囲を絞って進めます。例として、style.cssだけ → index.htmlの特定セクションだけ → フォーム表示だけ、の順に行います。</p>
<hr />
<h2>7. 最後に3チェック：速くするほど確認が重要になる</h2>
<h3>表示チェック（PC/スマートフォン想定・主要ブラウザー想定）</h3>
<ol>
<li>PC表示で主要ページを確認します</li>
<li>画面幅を狭めた表示を確認します（スマートフォン想定）</li>
<li>見出し階層と余白が意図通りか確認します</li>
</ol>
<h3>導線チェック（問い合わせまで迷わない文章か）</h3>
<p>次の3点がページ内で迷わず追えるか確認します。</p>
<ol>
<li>何を頼めるか</li>
<li>いくら／どのくらいかかるか</li>
<li>次に何をするか（フォームへ）</li>
</ol>
<h3>公開前チェック（バックアップ・戻し方・影響範囲）</h3>
<ol>
<li>修正前ソースを戻せる状態にします</li>
<li>影響範囲（他ページ・他機能）を想定します</li>
<li>フォーム送信、ブログ表示など"動作"を優先して確認します</li>
<li>公開する文章に、誤認誘発・断定・比較優良表示に見える表現がないか最終点検します</li>
</ol>
<hr />
<h2>まとめ</h2>
<ul>
<li><strong>「目的1行・範囲4分類」で指示を固定する：</strong> AIのブレを防ぐための必須設定です。</li>
<li><strong>「修正後ソース＋差分＋テスト」をセットで出させる：</strong> 確認負荷を最小化する出力形式です。</li>
<li><strong>「触らない領域」を明文化する：</strong> フォームやJSなど既存機能を壊さないための防衛策です。</li>
</ul>
<hr />
<h2>免責</h2>
<p>本稿は一般情報であり、個別具体の事情に応じた法的判断・個別案件への助言・成果の保証を行うものではありません。画面表示や機能、入力上限等は利用環境により異なる場合があります。</p>
<hr />
<h2>HANAWA行政書士事務所</h2>
<p><a href="https://hanawa-office.jp/">HANAWA行政書士事務所公式サイト</a></p>
<p><a href="https://hanawa-office.jp/AI_knowledge/index.php">AI活用学習サイト</a></p>
<p><a href="https://hanawa-office.jp/blog_detail.php?id=472">前の記事：実践編 第3回：サーバーはどうすればよい？ドメインってなに？取った方がいいの？</a></p>
<p><a href="https://hanawa-office.jp/blog_detail.php?id=478">次の記事：実践編 第5回：GASとGEMの違い｜Geminiの「Gem」で定型化し、GASで自動化する最短ルート</a></p>