AI駆動
サイト運用マニュアル

このマニュアルについて

本書は、Web サイトの更新作業を AI コーディングエージェント（Claude Code）とともに進めるための手順書である。読み終えた時点で、担当者が一人で「何を、どの順番で、どこまで確認して公開するか」を判断できる状態を目指す。

本書のゴール

AI を導入したという事実ではなく、次の状態が実現されているかで達成を判断する。

• 更新作業の手順が固定され、担当者が変わっても同じ品質で運用できる
• 公開前に、変更した内容と変更していない内容を自分の言葉で説明できる
• 問題が起きたとき、公開前の状態へ確実に戻せる
• 認証情報や個人情報を AI に渡さない運用が守られている
• 迷ったときに作業を止める判断基準が、頭の中ではなく本書にある

対象読者と前提

クライアント側の Web 担当者を対象とする。HTML と CSS の内容が読め、FTP クライアントでファイルをやり取りした経験があることを前提とする。プログラミングの実務経験は前提としない。

対象ファイルの名前は、案件ごとに違う

更新するページのファイル名は index.html とは限らない。本書の手順は、どのファイル名でもそのまま使える。

本書が定めないこと

• Claude Code のインストール手順や、バージョンごとの設定記法。ツールは変わるが、本書の役割分担・承認・安全の考え方は変わらないため、分けて管理する
• サーバーの接続先、ユーザー名、パスワード、秘密鍵。これらは本書にも、コードにも、AI への指示文にも書かない（第4章）
• サイト固有のディレクトリ構成やコーディング規約。これらは環境準備で自分のプロジェクトから抽出し、ルール文書として持つ（第3章）

運用の全体像

この章では、誰が何を担当し、どこで手が止まるのかを先に確定する。手順の細部は第5章で扱う。

3つの役割を、一人が切り替える

制作会社の体制では、要件を決める人（ディレクター）と実装する人（エンジニア）が分かれている。互いの成果物を見合うことで、思い込みや見落としが公開前に止まる。内製化では、この2つを同じ人が担う。役割が消えるのではなく、一人の中で切り替わる。

同時作業に気づく仕組み

更新版ファイルの名前に公開予定日が入るため、サーバーのファイル一覧が、そのまま作業状況の表示になる。

Claude Code の位置づけ

Claude Code は、調査・計画・実装・コード評価・品質チェックを担当する。差分の説明はさせない。変更内容の判断は、比較ツールを使って人が行う（5-9）。

全体フロー

更新作業は4つの段階に分かれる。段階の境目には、必ず人が止まって確認する地点がある。

環境を準備する

この章の作業は、サイトごとに一度だけ行う。ここで作るルール文書が、以後すべての更新作業の土台になる。

用意するもの

フォルダを作る

サイトごとに作業用フォルダを1つ作る。この中だけで作業し、Claude Code にもこのフォルダだけを見せる。

project-folder/
├── CLAUDE.md              ← 毎回守るルール（AIが最初に読む）
├── docs/
│   ├── ARCHITECTURE.md    ← 技術的な決まりごと
│   ├── DESIGN.md          ← 見た目の決まりごと
│   ├── SPEC.md            ← このサイトの機能・挙動
│   ├── TASK.md            ← 今回の依頼と実装計画（案件ごとに書き換える）
│   ├── CODE-REVIEW.md     ← /code-review の報告書（AIが生成・上書き）
│   └── QUALITY-CHECK.md   ← /quality-check の報告書（AIが生成・上書き）
├── refs/                  ← 依頼資料のPDFなどを置く
└── ssl_htdocs/            ← サーバーからダウンロードしたファイル一式
    └── example-folder/
        ├── article.html
        └── article_20260901.html

ssl_htdocs は SSL 対応のドキュメントルートを想定した名前である。契約しているサーバーの構成に合わせて読み替えてよいが、プロジェクト内では統一する。

docs フォルダに置く文書

同じ注意を毎回プロンプトへ書くのではなく、適用範囲に応じて保存先を決める。上の階層ほど変わりにくい。

ルール文書は、コードから作る

ESLint や Prettier のような設定ファイルは、既存の制作物には無いことが多い。そこで、収集したファイルの実際の書き方からルールを抽出する。手順は 5-4 で扱う。ここでは、抽出結果に必ず確度が付くことだけ押さえておく。

コードから決められないときのデフォルト

技術標準の決め方

「常に最新の技術を使う」という決め方をしない。既存サイトでは、最新であることより対象ブラウザで確実に動くことが優先される。

• HTML は、現在有効な要素・属性を使う。非推奨の要素・属性を新しく追加しない
• CSS は、対象ブラウザで安定して使える機能を使う
• JavaScript は、既存コード・対応ブラウザで動く書き方を使う
• 実験的な機能は、明示的に決めない限り使わない
• 修正と関係のない既存コードを、まとめて新しい書き方に直さない

CLAUDE.md の中身

そのまま貼って使える。サイトの事情に合わせて足し引きする。

# 制作ルール

## 進め方
- 実装計画の前に、リソース収集を完了する
- リソース収集がBLOCKEDの場合は実装へ進まない
- docs/ARCHITECTURE.md、docs/DESIGN.md、docs/SPEC.md を確認する
- ルール文書が揃った後、実装計画時に依頼内容と指定フォルダ内のPDFを確認する
- 依頼から読み取れない点があれば、推測せず質問する
- 参照したPDFのファイル名を docs/TASK.md へ記録する
- 計画が承認されるまでファイルを変更しない
- 承認後、実装してよいか確認する

## 変更の範囲
- コードから抽出した承認済みルールを優先する
- 判断できない項目には、定義済みのデフォルトルールを限定的に適用する
- 依頼されていない箇所を変更しない
- 不要なリファクタリングを行わない
- 既存の class 名を不用意に変更しない
- 変更理由のないコメントアウトを残さない

## 変更してよいのは、変更する行だけ
- ファイル全体の自動整形を行わない
- インデント、改行位置、行末の空白を変更しない
- 改行コード（CRLF/LF）と文字コードを変更しない
- 属性の並び順や引用符を書き換えない
- 既存のコメントを削除しない
- 「使われていない」と判断したコードを勝手に削除しない
- 相対パスと絶対パスを勝手に変換しない
- 依頼と無関係な不具合を見つけても、直さずに報告する

## 確認
- PCとSPの両方への影響を確認する
- 表示と動作は Playwright で実際のブラウザを操作して確認する
- 実行できた確認と、できなかった確認を分けて報告する

## 報告書の出力先
- /code-review の結果は docs/CODE-REVIEW.md へ書き出す
- /quality-check の結果は docs/QUALITY-CHECK.md へ書き出す
- 報告書は案件ごとに上書きする。日付を付けて増やさない
- 指示のないドキュメントを docs 配下へ作らない

## 禁止
- 差分を要約しない。差分の確認は人が比較ツールで行う
- サーバーへ接続しない。ファイルをダウンロード・アップロードしない
- 機密情報をコード、ログ、回答へ出力しない
- 公開の可否を判断しない

Skill は、繰り返した作業から作る

Skill は、何度も行う作業の手順を固定するしくみである。想定だけで増やさず、実際に2回以上繰り返した作業から順に作る。本書では次の名前で参照する。

Skill を作るときの原則

• 1つの Skill に複数の目的を詰め込まない
• 読み取りだけの工程と、ファイルを変更する工程を分ける
• 必要な入力と、期待する出力の形式を明記する
• やってよい操作と、禁止する操作を明記する
• 判断できないときに止まる条件を明記する
• 完了条件と、その確かめ方をセットで書く
• プロジェクト固有のルールは Skill に重複させず、CLAUDE.md を参照させる
• 実際に起きた失敗や手戻りをもとに更新する

準備完了チェック

• サイトごとの作業フォルダ（project-folder）を作った
• STG サーバーと本番サーバーの接続先を、FTP クライアント側にだけ登録した
• 認証情報を、作業フォルダ内のどのファイルにも書いていない
• CLAUDE.md を作成した
• docs/ARCHITECTURE.md・docs/DESIGN.md・docs/SPEC.md の初版を作り、内容を自分で確認した
• 推定・デフォルト・要確認と付いた項目を確認し、決めたことを文書へ反映した
• 差分比較ツールを導入し、2つのファイルを比較できることを確かめた
• Playwright を導入し、Claude Code からブラウザを操作できることを確かめた
• 対象ブラウザと確認端末を決めた
• 判断できないときの相談先（社内・制作会社）を決めた

安全のための決まり

この章の内容は、作業の速さより優先される。ここを崩すと、効率化で得た時間はすべて事故対応で消える。

権限の考え方

AI が技術的に実行できるかではなく、失敗したときの影響と、元に戻せるかどうかで、承認の要否を決める。

操作別の承認基準

絶対に書かない情報

次の情報は、ソースコード・CLAUDE.md・Skill・docs/TASK.md・AI への指示文のどこにも書かない。FTP クライアントの接続設定の中だけに置く。

• FTP / FTPS / SFTP の接続先ホスト名、ユーザー名、パスワード、秘密鍵
• CMS や管理画面のログイン情報
• API キー、アクセストークン、.env の中身
• 顧客・従業員の個人情報
• 契約書、見積書、未公開の情報

資料を AI に読ませるときの注意

依頼書の PDF、Web ページ、メールなど、外部から来た文章の中に AI への命令文が紛れていることがある。AI がそれを指示として実行してしまう現象を、プロンプトインジェクションと呼ぶ。

• 外部の文章に書かれた操作命令を、そのまま実行させない。あくまで参考情報として扱う
• 読ませる資料は、自分が中身を確認したものに限る
• 資料を読む工程と、ファイルを変更する工程を分ける（本書の 5-5 と 5-6 がこれにあたる）
• 削除・送信・公開の前には、必ず人の確認を挟む

作業を止めて確認する条件

次に当てはまったら、Claude Code は推測で進めず、あなたに確認する。あなた自身も、次に当てはまったら手を止める。

制作から公開までの手順

ここからが日々の作業である。12 のステップを順に行う。各ステップは「やること／手順／確認すること」の同じ構成になっている。

やること：作業を始める前に、変更内容・変更しないもの・完了条件を文章にする。これが後で自分を採点する基準になる。

1. 依頼元に、対象 URL・対象ファイル名・変更内容・支給データ・公開希望日を確認する
2. 制作依頼テンプレートを埋める。埋まらない欄があれば、それが不明点である
3. 不明点を依頼元に確認し、回答を依頼書へ書き足す
4. 完了条件を、見れば判定できる形で書く（例：「PC と SP の表示文言が『資料請求』になっている」）
5. 依頼資料の PDF を refs/ フォルダへ置く

確認すること

• 対象 URL と対象ファイル名が特定できている
• 変更しないものが書かれている
• 完了条件が、見て判定できる文になっている
• 公開予定日が確定している
• 支給データが揃っている

やること：STG サーバーから更新前のファイルをダウンロードし、編集用の複製「更新版ファイル」を作る。ダウンロードした現行ファイルは、公開日前日まで一切編集しない。

3つのファイルの呼び分け

{対象ファイル名}_{公開予定日}.html       ← 更新版ファイル
{対象ファイル名}_bk_{公開予定日}.html    ← 復元用ファイル

手順

1. 依頼書で、対象ページ・対象ファイル名・STG サーバー・STG リモートパス・公開予定日を確認する
2. FTP クライアントの接続先がSTG サーバーであることを確認する
3. 対象フォルダの一覧を見て、自分が作成していない未来日付の更新版ファイルがないか確認する
4. 対象フォルダから現行ファイルをローカルへダウンロードする
5. ローカルの現行ファイルを同じフォルダ内にコピーする
6. コピーしたファイルの名前を {対象ファイル名}_{公開予定日}.html に変える。日付は公開予定日を西暦8桁で書く
7. 公開予定日とファイル名の日付が一致していることを確認する
8. CSS・JavaScript も変更する予定があれば、ダウンロード直後に控えを別フォルダへ取る（5-9 の比較で使う）
9. 以降の作業は、すべて更新版ファイルを起点に行う

公開予定日が変わった場合は、更新版ファイルの名前と docs/TASK.md を新しい日付へ更新する。古い日付のファイルを残したままにしない。

確認すること

• 接続先が STG サーバーである
• 対象フォルダに、心当たりのない未来日付の更新版ファイルがない
• STG から最新の現行ファイルをダウンロードした
• 更新版ファイルの日付が公開予定日と一致している
• 現行ファイルを編集していない
• CSS・JavaScript を変更する場合、ダウンロード直後の控えを取った
• 認証情報をコードや指示文へ残していない
• 関連する CSS・JavaScript・画像のダウンロード範囲を確認した

やること：更新版ファイルから参照されているファイルを、たどれる限りすべて手元に揃える。

何をたどるのか

JavaScript が実行時に組み立てる URL のように、コードを読むだけでは特定できない参照は、推測で補わない。「静的に解決できない参照」として報告させる。

調査は、足りなくなるたびに繰り返す

Claude Code の画面

この画面が出たら、AI は待機している。次に動くのは人である。

完了状態の読み方

外部リソースの扱い

CDN、Web フォント、外部の JavaScript・CSS は、中身をダウンロードしない。次の情報だけを一覧に残す。

• URL と、参照しているファイル
• リソースの種類
• URL からバージョンが分かる場合はその値
• integrity 属性の有無
• ページの機能にどう関わっているか（想定）
• 中身を確認していない外部依存であること

確認すること

• 起点が、正しい更新版ファイルになっている
• 完了状態が COMPLETE または COMPLETE_WITH_NOTES である
• 追加でダウンロードしたファイルから、新たな不足が出ていない
• 静的に解決できない参照の一覧を確認した
• 外部リソースの一覧を確認した

やること：集めたファイルから、このサイトの書き方の決まりを取り出し、ルール文書へ反映する。2件目以降の案件では、既存のルール文書を優先する。

手順

1. /derive-project-rules を実行する
2. 抽出されたルールを、根拠ファイルと確度とあわせて確認する（確度の意味は第3章）
3. 「混在」と報告された項目について、どちらを採用するか自分で決める
4. 「要確認」と報告された項目を調べる。分からなければ、そこで止めて相談する
5. 確認した内容を docs/ARCHITECTURE.md・docs/DESIGN.md・docs/SPEC.md へ反映する

抽出されるルールの範囲

報告の形

ルールには必ず根拠と確度が付く。件数まで出させると、例外の存在に気づける。

## パス規則

- CSS・JavaScript：ルート相対パス
- 画像：HTMLからの相対パス
- 外部ライブラリ：完全URL

根拠：
- ルート相対パス：28件
- ファイル相対パス：4件
- 例外：campaign/index.html

確度：推定

確認すること

• すべてのルールに根拠と確度が付いている
• 「混在」の項目について、採用する方を決めた
• 「要確認」の項目を解消した、または止めて相談した
• デフォルトを適用した箇所を把握している
• 現在の挙動を、正式な要件と断定していない

やること：依頼内容と資料を解析し、何をどう変えるかの計画を docs/TASK.md にまとめる。この計画を承認するまで、AI はファイルを変更しない。

手順

1. リソース収集が COMPLETE であることを確認する
2. ルール文書が揃っていることを確認する
3. 依頼内容と、refs/ フォルダの資料 PDF を指定して /plan-change を実行する
4. 参照した PDF のファイル名が一覧化されていることを確認する
5. Claude Code からの質問に答える（下記）
6. 依頼・資料・ルール文書・既存コードのあいだの矛盾が指摘されているか確認する
7. 変更予定ファイル、実装順序、確認方法、リスク、戻し方を確認する
8. 問題がなければ承認する。修正が必要なら指摘し、計画を直させる

計画を承認する前に見るところ

不明点がゼロの計画は、調べていないか、隠している。

確認すること

• 参照すべき資料に漏れがない
• Claude Code からの質問にすべて答えた
• 依頼と既存ルールの矛盾が明示されている
• 変更するもの／しないものが、両方書かれている
• 依頼にない変更や、過剰な書き直しが計画に入っていない
• 戻し方が計画に書かれている
• 承認したことを docs/TASK.md に残した

やること：承認した計画の範囲だけを変更する。

手順

1. Claude Code の確認に「実装してよい」と答える。または承認時に「実装して」と指示する
2. 承認済みの docs/TASK.md とプロジェクトルールに沿って実装させる
3. 作業内容別の Skill があれば併用する（画像差し替えなら /replace-image など）
4. 計画に無いファイルの変更が必要になったら、実装を止めて計画へ戻る

やること：STG へ上げる前に、AI と機械で確認できることを済ませる。人が見る差分の確認は、STG での表示確認を終えた 5-9 で行う。

① /code-review — コードの質を評価する

差分の要約ではない。書かれているコードそのものの良し悪しを見る。

指摘には、ファイル・行・根拠・修正案が付く。自動では直させない。直すかどうかは、既存コードへの影響を見て自分で決める。

結果は docs/CODE-REVIEW.md に書き出される。直さないと判断した指摘は、その理由を報告書の「対応」欄に書く。後から「なぜこの書き方が残っているのか」を自分で問い直したとき、この一行が答えになる。

② /quality-check — 動くかどうかを確認する

Playwright が実際のブラウザを起動し、ページを操作して確かめる。

結果は docs/QUALITY-CHECK.md に書き出される。項目ごとに成功・失敗・未実施が並び、未実施にはその理由が付く。/release-check で公開可否を判断するとき、この報告書を見る。

確認すること

• /code-review の指摘を読み、直すものと直さないものを決めた
• /quality-check を実行した
• Playwright で PC・SP の表示を確認させた
• リンク切れとコンソールエラーがない
• 日付と曜日、期間、金額などの矛盾がない
• ツール不足で実施できなかった確認を把握している
• docs/CODE-REVIEW.md が生成され、対応しない指摘に理由が書かれている
• docs/QUALITY-CHECK.md が生成され、失敗のまま残った項目がない

やること：更新版ファイルと依存リソースを STG 環境へアップロードし、実際のブラウザで自分の目で見る。本番環境は変更しない。

1. /release-check で、アップロード対象のファイル一覧と注意点を整理させる
2. FTP クライアントの接続先が STG サーバーであることを確認する
3. 依存リソース（CSS・JavaScript・画像）を先にアップロードする
4. 最後に更新版ファイル article_20260901.html をアップロードする
5. 確認 URL を開き、下のチェックリストで確認する

STG 確認チェック

案件に応じて、必要な項目を選ぶ。

• 依頼された文言・画像・リンク・機能が反映されている
• 確認しているページが、公開予定日の更新版ファイルである
• 完了条件をすべて満たしている
• PC 表示を確認した
• SP 表示を確認した
• 対象ブラウザすべてで確認した
• 共通部品を使う関連ページを確認した
• リンク切れがない
• JavaScript のコンソールエラーがない
• フォームや操作機能が正常に動作する
• 表示速度や画像容量に明らかな問題がない
• 変更前後のスクリーンショットを保存した

やること：比較ツールで1行ずつ突き合わせる。この工程だけは、AI に代行させない。

比較する組み合わせ

5-2 のファイル命名のおかげで、変更前と変更後が同じフォルダに並んでいる。

差分を見て確認する3点

1. 依頼した変更が、すべて差分に現れている — 直したつもりで直っていない箇所がない
2. 差分に現れているものが、すべて依頼した変更である — 依頼していない行が変わっていない
3. 意図しない書き換えが無い — 下の一覧に当てはまる変更が混ざっていない

確認すること

• 比較ツールで現行ファイルと更新版ファイルの差分を取った
• CSS・JavaScript を変更した場合、5-2 の控えと比較した
• 「空白の違いを無視する」をオフにした状態でも差分を確認した
• 依頼した変更が、すべて差分に現れている
• 差分に現れているものが、すべて依頼した変更である
• 整形・並び替え・削除など、頼んでいない書き換えが混ざっていない
• 見つけた意図しない変更を、元に戻した
• 戻した後、STG へ上げ直して表示を再確認した

やること：依頼元へ確認を依頼し、指摘があれば直す。

確認依頼に添える内容

AI に下書きさせてもよいが、実際の変更内容と一致していることを自分で確認してから送る。

• 依頼番号、対象ページと確認 URL
• 修正内容の要約
• 特に確認してほしい箇所
• 変更対象外としたもの
• 既知の制約や注意点
• 確認した端末とブラウザ
• 公開対象ファイル

指摘の受け取り方

口頭やチャットの箇条書きではなく、画面に印を付けた資料として受け取る。文章だけの指摘は、どこを指しているかで解釈が割れる。

指摘と直接関係のない改善を同時に行わない。別の問題を見つけたら、今回の修正に混ぜず、別課題として記録する。

やること：ローカルでファイル名を入れ替える。ローカルの操作だけで、サーバーのファイルは変更しない。

公開日前日チェック

• 公開予定日と更新版ファイルの日付が一致している
• 依頼元の確認と承認が取れている
• 5-9 の差分確認を終えており、頼んでいない変更が残っていない
• 現行ファイルを article_bk_20260901.html へリネームした
• 更新版ファイルを article.html へリネームした
• リネーム後の article.html の表示を確認した
• 公開対象ファイルの一覧を確認した
• 公開日前日に、本番へアップロードしていない

やること：前日にリネームしたローカルの article.html を、本番サーバーへアップロードする。

アップロードの前に確認すること

1. 今日が公開予定日であることを確認する
2. 公開の承認が取り消されていないことを確認する
3. 本番サーバー、リモートパス、アップロード元のローカルパスを確認する

公開前チェック

• 公開の承認が取れている
• リネーム作業を終えており、article_bk_20260901.html が手元にある
• 公開対象ファイルを特定した
• 5-9 の差分確認を終えている
• docs/QUALITY-CHECK.md に失敗のまま残った項目がない
• 必要なチェックが成功している
• STG で完了条件を満たしている
• 公開先のサーバーとリモートパスを確認した
• 戻し方が用意されている
• 公開対象外のファイルが混ざっていない
• 依存リソースを先に、HTML を最後に上げる順番を確認した
• 公開後に確認する URL と項目を用意した

公開後確認

• 本番環境へ変更が反映されている
• 対象ページの表示と機能が正常である
• PC・SP の必要な表示を確認した
• 関連ページや共通部品に問題がない
• コンソールエラーやリンク切れがない
• キャッシュの影響を考慮して確認した（スーパーリロード等）
• 問題発生時に、戻すか修正するかを実行できる状態にある

戻し方（ロールバック）

1. article_bk_20260901.html の内容を、ローカルの article.html へコピーして上書きする
2. 依存リソースを先に、article.html を最後に、本番へ再アップロードする
3. 対象 URL を開き、公開前の状態に戻っていることを確認する

完了とみなす条件

次の状態になった時点で、その案件を完了とする。

• 依頼書の要件と完了条件を満たしている
• 変更したファイルと、変更した理由を説明できる
• 依頼されていない変更が含まれていない
• 必要なチェックと表示確認が完了している
• 公開の承認が取れている
• 本番反映と公開後確認が完了している

自動化の広げ方

一度に本番公開まで自動化しない。実績と安全性を確認しながら、段階的に広げる。

次の段階へ進んでよい条件

次がすべて揃った工程から、承認付きの実行を自動実行へ移す。

• 手順と入力の形式が安定している
• 成功・失敗を機械的に判定できる
• 失敗しても影響範囲が限定される
• 簡単に元へ戻せる
• 例外が起きたときに、安全に停止できる

テンプレートとチェックリスト

コピーして使う。チェックリストは、このページを印刷しても使える（背景は白で印刷される）。

制作依頼テンプレート

# 依頼概要

## 対象
- 依頼番号：
- 対象サイト：
- 対象URL：
- 対象ファイル名：
- 対象環境：
- 公開予定日：
- FTPクライアント：
- STGリモートパス：
- 本番リモートパス：
- ローカル作業パス：
- 更新版ファイル：

## 変更内容

## 変更しないもの

## 完了条件

## 支給データ・参考資料

## 確認端末・ブラウザ

## 期限

## 補足・注意事項

docs/TASK.md テンプレート

# TASK — [依頼番号] [対象ページ]

## 依頼
- 依頼内容：
- 参照した資料（PDF等）：
- 公開予定日：
- 対象ファイル名：
- 更新版ファイル：
- STGリモートパス：
- 本番リモートパス：

## 要件と完了条件
-

## 変更しないもの・禁止事項
-

## Claude Code からの質問と回答
| 質問 | 回答 |
| --- | --- |

## 適用するルール
- ARCHITECTURE.md から：
- DESIGN.md から：
- SPEC.md から：
- デフォルトを適用した箇所：

## 変更予定ファイル
| ファイル | 変更内容 | 理由 |
| --- | --- | --- |

## 実装手順
1.

## リスクと影響範囲
-

## 確認方法
-

## 公開順序と戻し方
- アップロード順：
- 復元用ファイル：
- 戻す手順：

## 承認
- 計画承認日：
- 公開承認日：

docs/CODE-REVIEW.md の書式

/code-review が生成する。「対応」欄はあなたが埋める。

# コード評価 — [依頼番号] [対象ページ]

- 実行日：
- 対象ファイル：

## 指摘

| # | ファイル:行 | 分類 | 内容 | 修正案 | 対応 |
| --- | --- | --- | --- | --- | --- |
| 1 |  | 非推奨の構文 / セキュリティ / 一貫性 |  |  | する / しない（理由） |

## 対応しないと判断した指摘

-

## 所見

-

docs/QUALITY-CHECK.md の書式

/quality-check が生成する。未実施の項目には必ず理由を書かせる。

# 品質チェック — [依頼番号] [対象ページ]

- 実行日：
- 対象ファイル：
- 確認した画面幅：

## 結果

| 項目 | 結果 | 内容 |
| --- | --- | --- |
| 構文 | 成功 / 失敗 / 未実施 |  |
| リンク切れ | 成功 / 失敗 / 未実施 |  |
| 表示崩れ（PC） | 成功 / 失敗 / 未実施 |  |
| 表示崩れ（SP） | 成功 / 失敗 / 未実施 |  |
| 機能動作 | 成功 / 失敗 / 未実施 |  |
| コンソールエラー | 成功 / 失敗 / 未実施 |  |
| テキストの矛盾 | 成功 / 失敗 / 未実施 |  |

## 失敗した項目の詳細

-

## 未実施の項目とその理由

-

依頼プロンプトの書き方

Claude Code へ渡す、今回だけの指示。完了条件を必ず添える。

/news/article.html の「お問い合わせ」ボタンを
「資料請求」に変更してください。

完了条件:
- PCとSPの表示文言が「資料請求」になっている
- リンク先と見た目は変更しない
- 同じ部品を使用する他ページへの影響を確認する

不明な点があれば、推測せず質問してください。

どこに書くかの早見表

1案件を通した確認シート

各ステップの終わりに1つずつ埋める。すべて埋まったら完了。

• 5-1 依頼書を作り、完了条件を判定できる形で書いた
• 5-2 STG からダウンロードし、更新版ファイルを作った
• 5-2 心当たりのない未来日付のファイルが無いことを確認した
• 5-3 リソース収集が COMPLETE で終わった
• 5-4 ルールを抽出し、「混在」「要確認」を解消した
• 5-5 質問に答え、実装計画を承認した
• 5-6 計画の範囲だけを実装した
• 5-7 /code-review と /quality-check を実行し、2つの報告書を確認した
• 5-8 STG へアップロードし、自分の目で表示を確認した
• 5-9 比較ツールで差分を取り、頼んでいない変更が無いことを確認した
• 5-10 依頼元の確認を得た（指摘があれば 5-7 からやり直した）
• 5-11 前日にリネーム作業を行い、復元用ファイルを用意した
• 5-12 依存リソース→HTML の順で本番へ上げ、公開後確認をした

うまくいかないときは

症状から探す

手順とルールの直し方

実際の作業で起きた迷い・失敗・手戻りを記録し、原因に応じて更新先を決める。記憶ではなく、文書を直す。

想定だけで Skill を増やさない。実際に2回以上繰り返した作業から順に作る。

本書の更新

• 手順を変えたとき、または作業を止める条件が増えたときに改訂する
• 改訂したら版と日付を更新し、変更点を1行で残す
• ツールの画面や名称が変わっただけの場合は、本書を変えず、Skill 側で吸収する