2026年6月28日(日)

改修案件で迷わないために — 調査してから決める手順

改修
ワークフロー
CSS
Sass
レガシー

受託の改修案件では、サイト内に「正解の CSS 設計」が1つとは限らない。ページごとに rem の基準が違う、画像パスが WordPress テーマ内とサイト直下（公開フォルダ）で混在する、ブレイクポイントの数値がファイルによってバラバラ——こういう状態でいきなり SCSS を書き始めると、実装のたびに「これで合ってる？」と立ち止まる。

よしあきは、コードを書く前に「調査 → 決定」を済ませることで、その迷いを減らそうとしている。ここでは、調査項目と決定項目をチェックリストとして固定し、改修案件ごとに同じ順番で回す型をまとめる。

全体の流れ

1. 調査（事実を書き出す）
   └ サイズ単位 / ブレイクポイント / assets / コンポーネント / ライブラリ
2. 決定（この案件の「正」を1枚に固定する）
   └ Sass function / mixin / ソースと出力の置き場
3. 実装（決定した前提のもとでページを触る）

調査結果は Markdown レポート（案件リポの ai-docs/ や調査メモなど）に残す。推測は「推測」と書き、根拠にファイルパスを添える——これだけで、2週間後の自分や AI への引き継ぎが楽になる。

着手前に調査すること

サイズ指定

フォントサイズの単位

まず フォントサイズに何の単位が使われているか を把握する。

調べること	手がかり
主な単位	`px` / `rem` / `em` / `vw` / `clamp()` のどれが多いか
ルート `font-size`	`html { font-size: … }` の有無と値（62.5% や `vw` 可変など）
CSS 変数	`--font-size-` や `--fs-` のようなトークンがあるか
ページ差	対象ページと隣接ページで rem の実寸が同じか

調べ方の例

Sass / CSS を font-size で grep し、代表ファイルを5〜10件ピックアップする
ブラウザ DevTools で対象ページの html computed font-size を確認する（1440px 幅など、デザインカンプと同じ幅で）
rem が多いのにルート指定が無い場合、どの CSS が html に font-size を当てているか を読み込み順まで追う

rem 前提のテンプレ（ルート 10px 相当）と、可変ルートのレガシーが混在していると、Figma の px を rem に換算した瞬間からズレる。換算式を決める前に、対象ページの 1rem = 何 px かを数値でメモしておく。

その他のサイズ指定

フォント以外の 余白・幅・高さ・角丸 も単位の癖がある。

調べること	手がかり
余白	`margin` / `padding` が `px` か `rem` か `%` か
レイアウト幅	`max-width` の px 値、`container` クラスの有無
可変	`vw` / `vh` / `calc()` / `clamp()` の使用箇所
トークン	spacing 用 CSS 変数や Sass 変数（`$spacing-*` 等）

コンポーネント SCSS を1つ開き、数値の書き方がプロジェクト内で統一されているか を見る。バラバラなら「新規追加分だけ統一する」のか「既存に合わせる」のか、後段の決定で明示する。

ブレイクポイント

調べること	手がかり
数値一覧	`768px` / `1024px` など、何 px で切り替わるか
定義場所	Sass の `$breakpoint-*`、`mq()` mixin、PostCSS 設定
向き	`min-width` 中心（SP ファースト）か `max-width` 中心（PC ファースト）か
混在	ファイルによって mq の書き方が違わないか

調べ方の例

@media / mq( / breakpoint で grep し、出てきた px を一覧化する
mixin 定義ファイル（global/mixins/_mq.scss など）を Read し、引数の意味を確認する
代表ページを DevTools のレスポンシブモードで縮め、実際にレイアウトが変わる幅 を目視で補足する

一覧表は次の形で十分だ。

px	用途メモ	定義ファイル
768	タブレット〜	`_mq.scss` など

assets の格納場所

改修で画像・CSS・JS を どこに置き、どこから読むか は案件ごとに違う。触るページの「正」を先に特定する。

画像

調べること	手がかり
配置	テーマ `assets/images/`、サイト直下 `/images/`、ページ固有 `./assets/` など
参照	HTML / PHP の `src`、CSS の `url()`、WP 関数（`get_template_directory_uri()` 等）
圧縮	WebP / AVIF があるか、ビルドで生成されるか、手置きか
命名	連番・日付・BEM 風など

CSS

調べること	手がかり
ソース	`.scss` / `.sass` / `.css` の場所
出力	`dist/`、`assets/css/`、結合1ファイルなど
読み込み	`<link>` の順序、WP の `wp_enqueue_style`、条件分岐
ビルド	Vite / Webpack / Gulp / なし（手編集）

JS

調べること	手がかり
配置	テーマ JS、サイト直下、`npm run build` 出力
読み込み	フッター / ヘッダー、defer / module
依存	jQuery 必須か、バンドル済みか

混在サイト（WP テーマ + 静的 HTML）では、ページ種別ごとに表を分けると後で迷わない。

その他

再利用可能なコンポーネント

調べること	手がかり
命名	BEM の `c-` / `p-` / `l-` など、接頭辞の意味
置き場	`components/`、テンプレートパーツ、EJS partial
流用可否	対象ページで既に読み込まれている CSS に含まれるか
差分	流用すると Figma からどれくらいズレるか（数 px 単位でメモ）

新規 UI を既存 c-btn 等に寄せるか、ページ専用 p-* を新設するかは、調査段階で候補を列挙しておく。実装中に「似たボタンを探す」時間を削れる。

使用ライブラリ

調べること	手がかり
package.json	依存と scripts
CDN / 直読み	`<script src="https://…">`、テーマ同梱
WP プラグイン	スライダー・フォーム等がプラグイン出力か
バージョン	古い jQuery / Swiper 等、API の違い

function_exists や class_exists の分岐が PHP にあれば、本番で有効なプラグインの痕跡として記録する。

調査結果を踏まえて決めること

調査は「サイトに何があるか」の事実集め。ここから先は 「この案件では今後こう書く」 という決定を1枚にまとめる。実装中にブレないよう、案件リポの AI 向けメモ（ai-docs/ 等）か調査レポート末尾に書いて固定する。

サイズ指定 → Sass の function 準備

function とは — Sass 内で 値を計算して返す仕組み。コンパイル時に 16px や 1rem など 1つの CSS 値に展開される。

改修案件で function を決める理由は、デザインカンプの px を毎回手計算しないためだ。font-size: 0.8125rem のような分数をコンポーネントごとに書くと、ルート font-size の解釈が人によってブレる。function に px を渡す形にそろえれば、「Figma の 13px → rem(13)」と 入口が1つになる。

具体例（よくあるパターン）

px → rem 換算 — ルートが 16px 相当のとき:

@function rem($pixels) {
  @return math.div($pixels, 16) * 1rem;
}

.p-card__title {
  font-size: rem(24); // → 1.5rem
  margin-block-start: rem(16);
}

ルートが 10px 相当（html { font-size: 62.5% } など）の案件では、分母を 10 に変えるだけでよい。調査で「1rem = 何 px か」をメモしたうえで、既存 function の分母に合わせるのが先。

vw / 可変サイズ — デザイン幅 375px 基準で SP カンプから vw に落とす例:

@function vwsp($size) {
  @return math.div($size, 375) * 100vw;
}

.p-fv__lead {
  font-size: vwsp(14);
}

clamp / fluid — 768px〜1440px のあいだでサイズを滑らかに変える function がある案件もある。調査で既存定義を見つけたら、新規も同じ function を使う。

決めること

調査で rem と px が混在していたら、換算の入口を1つに決める。

状況	決定の例
ルート 10px 相当が固定	`@function rem($px) { … }` を既存定義に合わせる
ルートが可変	新規は px 固定にする / デザイン幅基準の function を新設する
既存が px だらけ	追加分も px に合わせる（無理に rem 化しない）

決定メモに書く項目

1rem = 何 px か（対象ページ・代表幅）
新規 SCSS で使う function 名と置き場（global/functions/_rem.scss 等）
CSS 変数がある場合、新規トークンを足すか既存を使うか

function を新設する場合は、既存の同名 function と衝突しないか を grep で確認してから追加する。

ブレイクポイント → Sass の mixin 準備

mixin とは — Sass 内で 宣言ブロックを再利用する仕組み。@include で呼び出すと、コンパイル後の CSS にそのブロックが展開される。

改修案件で mixin を決める理由は、@media の数値と書き方をファイルごとにバラけさせないためだ。768px / 767px / 769px が混在すると、レイアウト切り替えのタイミングがページによってずれる。ブレイクポイント用 mixin（多くの案件で mq という名前）を 正本として1つ決め、以降は @include mq(md) のように呼ぶ。

具体例（メディアクエリ mixin）

定義側（global/_setting.scss や _mq.scss などにまとまっていることが多い）:

$breakpoints: (
  md: 768,
  lg: 1024,
);

@mixin mq($key: md) {
  @media screen and (min-width: #{map.get($breakpoints, $key)}px) {
    @content;
  }
}

呼び出し側 — SP ファーストで、768px 以上のときだけ余白を広げる:

.p-section {
  padding-inline: rem(20);

  @include mq(md) {
    padding-inline: rem(50);
  }
}

調査で @media (max-width: 767px) が多い PC ファーストのレガシーなら、無理に min-width に統一せず、既存 mixin の向きに合わせるか、新規ファイルだけ SP ファーストにするかを決定メモに書く。

mixin のほか（参考）

ブレイクポイント以外にも、プロジェクトによっては次のような mixin がある。

用途	例	役割
テキスト省略	`text-truncate()` / `line-clamp(2)`	1行・複数行省略の宣言セットを共通化
ホバー・フォーカス	`hover-opacity` 等	`:hover` と `:focus-visible` をセットで書く
reduced-motion	`reduced-motion { … }`	`prefers-reduced-motion` 対応を1か所に

改修の 着手前に決める優先度が高いのは mq だ。省略やホバー mixin は、対象コンポーネントを触る段階で既存を @include すれば足りることが多い。

決めること

調査一覧と 実際に使う mq を一致させる。

決定項目	内容
正本の mq	既存 mixin をそのまま使う / 数値だけ揃える / 新規 mixin を足す
SP / PC 方針	min-width 統一か、レガシーに合わせて max-width も許容するか
呼び出し方	`@include mq(md) { … }` など、プロジェクト内の慣例を1行で示例

新規 mixin を作るのは最後の手段にする。既存の _mq.scss があるなら、そこに定義されている breakpoint 名・px を正とする。

assets の格納場所

決定項目	内容
SCSS・圧縮前画像の置き場	例: `src/assets/sass/components/`、`src/assets/images/`
CSS・圧縮後画像の吐き出し場	例: `dist/assets/`、テーマ `assets/css/`
参照パス	PHP / HTML ではどのヘルパー・相対パスを使うか
ビルド	手元で `npm run build` が必須か、Sass だけ watch か

差分納品（変更ファイルだけ上げる）の案件では、出力先を変えられないことが多い。調査で判明した「触ってよいディレクトリ」を決定メモに明記し、それ以外は読み取り専用と割り切る。

よしあきの読み順（実務）

対象ルートを特定 — WP テーマ / 静的一式 / 混在のどれか
上記「調査」チェックリスト — レポート形式で事実を埋める（手動でも Agent でもよい）
「決定」1枚 — function / mixin / assets 置き場を固定
対象ページの既存 SCSS を Read — reset / base / root とコンポーネントの重複を避ける前提を確認
ここから CSS・HTML の実装

キックオフ（納期・納品形態・デザイン FIX）は別チェックリストで先に済ませる。コードに触る直前の論点は、本稿の調査 → 決定に集約する。

まとめ

改修案件で迷いがちなのは、技術力より 前提がページごとにバラバラ なことだ。

着手前: サイズ単位・ブレイクポイント・assets・コンポーネント・ライブラリを 事実として 調査する
着手直後: 調査結果から Sass の function / mixin と置き場所を 1枚に決める
実装: 決定した前提のもとで、既存 reset / base / コンポーネントを読んでから最小差分で入れる

この順番を案件ごとに固定すれば、「毎ページ正解探し」に実装時間の大半を使う状態を避けやすい。調査レポートは見積の根拠にもなる——実装に入る前に決定内容まで固定しておく。