フロントエンドの案件では、画面の指定を前にして「ここは変えていいのか、変えてはいけないのか」で手が止まる場面が繰り返し訪れます。デザイナーが決めた色や余白のように見えても、実装する側から動かせる部分は案外残っています。境界を引く手がかりは、職種の分担表ではなく、指定に添えられている理由のほうにあります。公的に運用されているデザインシステムの更新履歴を読むと、この線引きの材料がいくつも見つかります。この記事では、実際の更新履歴から読み取れる理由の種類を手がかりに、実装する側が使える境界の引き方を具体的に整理します。

1. 境界は職種では引けない

「変えていいのか」で手が止まる瞬間

案件の画面を実装していると、色や余白、ホバーの動きといった細部で判断に迷う瞬間が繰り返し訪れます。相談すると話が止まると感じられそうで、そのまま指定どおりに進めてしまうこともあるはずです。迷いを抱えたまま進める時間は、思っている以上に積み重なっていきます。後になって指定の意図を尋ねると、なぜ今さらと思われるのではないかという遠慮も働きます。

迷いの正体は、たいてい「これは誰の担当か」という職種の線引きで考えてしまうことにあります。デザイナーが決めた指定だから触れない、という前提がまず立ってしまうためです。しかし担当の線引きは、指定そのものの根拠を教えてくれるわけではありません。担当が誰かを気にするほど、指定そのものの中身を確かめる手が止まりやすくなります。

境界は、職種の分担表では引けません。むしろ引けるのは、指定に添えられている理由のほうです。理由があるかどうかで、実装側から提案できる余地は大きく変わります。理由が明示されているなら要件として受け止め、そうでないなら相談の入り口にできます。この線引きの基準さえ持っておけば、初めて見る指定でも同じ手順で向き合えます。

フォントサイズと文字色は、好みではなく要件

公的に運用されているデザインシステムの更新履歴には、指定の背景にある理由がそのまま書かれている場面がいくつもあります。フォントサイズは16px以上を求める方針です。理由はアクセシビリティの確保です¹。数値そのものより、その数値が何を守るためにあるのかが要点です。数値の大きさだけを覚えても、根拠を尋ねられたときに答えられなければ、次の指定でまた同じ迷いが生まれます。

基本の文字色も、ディスレクシアへの対応を理由にGrey-900からGrey-800へ変更されています⁶。どちらも見た目の好みで決まった数値ではなく、読む側の条件に合わせて設定された要件です。色や大きさを個別の好みとして扱ってしまうと、要件としての重みを見落としたまま進めることになります。

見た目の一致を優先するよりも、コントラストや読みやすさといった条件を確かめるほうが、指定の背後にある要件に近づけます。理由を確かめる習慣は、次に受け取る指定にもそのまま持ち越せる考え方です。次の章では、同じように理由が明示されている例をもう少し具体的に見ていきます。

図の作成：Remogu編集部。指定の性質を整理したもので、統計データではありません

2. 指定に理由が添えられている例

視認性を理由にした変更が続いている

更新履歴を読み進めると、視認性という同じ理由で複数の指定が動いていることに気づきます。単発の思いつきによる変更ではなく、条件をそろえるために連なった変更だと分かると、指定に対する見方が少し変わります。複数の指定を並べて眺めることで、単発の思いつきではなく方針として動いていることが確かめられます。

フォーカスの状態は、視認性の向上を理由にフォーカスインジケーターのスタイルが変更されています²。キーボードで操作する場面を前提にした変更であり、マウスの操作だけを見ていると気づきにくい理由です。マウス操作だけを基準に考えていると、この理由には気づきにくいままです。

リンクの視認性を高めるため、標準の状態と訪問済みの状態の両方に下線が加えられています⁴。押した後の状態まで含めて対応されている点が特徴で、状態がいくつあるかによって加える範囲が変わってきます。状態が増えるほど、そろえる範囲も広がっていくという読み方ができます。

見た目が近い変更でも、理由が視認性なのかコントラストなのかで、確かめる対象や相談する相手が変わります。理由の種類を区別しておくと、次に似た指定に出会ったときの判断が速くなります。似ている変更ほど、理由を確かめずに済ませてしまいがちなので注意が必要です。

更新履歴に書かれている理由を並べて見る

対象の要素、実際の変更内容、そこに書かれている理由を並べると、指定の位置づけが見えやすくなります。色や太さといった見た目の変更でも、背景にある理由まで確かめると、動かせるかどうかを判断する材料が具体的になります。数値だけを覚えるより、理由の欄まで含めて読む習慣をつけておくと、初めて見る指定にも応用できます。次の一覧は、更新履歴に明記されている理由をそのまま並べたものです。

対象要素	変更内容	示されている理由
フォーカスの状態	フォーカスインジケーターのスタイルを変更	視認性の向上
リンクの下線	標準の状態と訪問済みの状態に下線を追加	リンクの視認性の向上
ホバー時の表現	背景色の変化をやめ、下線の太さの変化に変更	コントラストの要件を満たすため

3つとも、変更そのものより理由のほうが一貫しています。色を変える、太さを変える、下線を足す——手段は違っても、視認性やコントラストという条件を満たすための動きです⁵。この一貫性こそが、指定を「要件」と呼べる根拠になります。この一貫性を踏まえておくと、次に似た変更に出会ったときも同じ視点で向き合えます。

3. 同じ目的で手段が変わることがある

ホバーの表現：背景色から下線の太さへ

指定の中には、目的は変わっていないのに、実現する手段だけが入れ替わっているものがあります。見た目の差分だけを追うと方針が変わったように感じられますが、実際にはそうではない場合が少なくありません。見た目の差分だけを比べていると、方針転換のように誤解してしまう場面が生まれます。

ホバー時の表現は、背景色を変える方法をやめ、下線の太さを変える方法に変更されています⁵。ここで動いているのは手段であって、コントラストを満たすという目的そのものが動いたわけではありません。背景色という手段から下線の太さという手段へ、条件を満たす方法だけが置き換わっています。

職種の分担で線を引くよりも、目的と手段のどちらが動いたのかを見分けるほうが、提案の精度が上がります。目的が同じだと分かれば、別の実現方法を持ちかける余地があります。目的を先に確かめておけば、提案する側も安心して別案を出せます。

表の選択行：塗りから塗り＋区切り線へ

表の中で選択されている行の示し方も、同じ構図で動いています。塗りだけで示す表現から、区切り線を加えた表現に変更されています¹²。色の面積という手段が、線という手段に置き換わった形です。面積で示す方法から線で示す方法へ、伝え方の手段が変わったと捉えられます。

これは色だけに頼らない見分け方への変更です。色の判別が難しい場面でも行の境目が分かるようにする、という目的に沿った手段の入れ替えだと読み取れます。色の判別に頼らない設計は、見え方の条件が異なる読者にも配慮した変更だと読み取れます。目的を先に押さえておくと、変更の理由が自然に見えてきます。

同じ目的のまま手段が変わる指定は、実装側から別の手段を逆提案できる余地がある指定でもあります。目的を起点に考える習慣は、次章で見る「指定が消える」場面にも役立ちます。次の章では、指定そのものが消えていく例を見ていきます。

図の作成：Remogu編集部。更新履歴に書かれている変更を整理したもので、統計データではありません

4. 消える指定——移行の猶予は切れる

移行期間という猶予があった

新しい指定に切り替わるとき、古い指定がすぐに消えるとは限りません。しばらくの間は新旧が並んで残り、実装側が移行の準備を進める時間が用意されています。この猶予があることで、一括での書き換えを避けられます。一括での置き換えを避けられる分、実装側にも準備の時間が生まれます。

この並存の期間が終わると、残されていたものは順番に整理されていきます。猶予があったことに気づかないまま、ある日参照できなくなっているという場面も起こり得ます。気づいたときには手戻りになりやすい部分です。猶予の終わりに気づけるかどうかは、更新履歴を定期的に確かめているかどうかで変わります。

更新履歴では、この整理が実際にどう進んだかが具体的に書かれています。色のトークンと文字のトークン、両方で同じ構図の削除が起きており、片方だけを気にしていると見落としが生まれます。色と文字、それぞれのトークンで同じ構図の削除が起きている点は覚えておく価値があります。

移行期間中に残されていたものが、今回どう扱われたか

削除された対象と、それがどんな位置づけだったのか、現在どう扱われているのかを並べると、猶予の切れ方が見えてきます。対象を並べて眺めると、削除の対象がいずれも移行用に残されていたものだと分かります。次の一覧は、移行用に保持されていたものが今回どう扱われたかをまとめたものです。

削除された対象	位置づけ	現在の扱い
Focus-BlueとFocus-Yellowのトークン	スタイル変更にともなう色トークン	削除され、参照できない
移行用に保持していた旧カラートークン	移行期間中の互換のための保持	削除され、参照できない
移行用に保持していた旧タイポグラフィトークン	移行期間中の互換のための保持	削除され、参照できない

フォーカスまわりのスタイル変更にともなって、Focus-BlueとFocus-Yellowという色のトークンが削除されています³。単独の削除ではなく、フォーカスまわりのスタイル全体の変更にともなう整理です。

移行の間だけ残されていた旧カラートークンも、同じように削除されています⁷。旧タイポグラフィトークンについても、同じ扱いで削除されています⁸。色と文字、それぞれで別々に猶予が切れた形です。色と文字、どちらの猶予も同じタイミングで終わったことが確認できます。

図の作成：Remogu編集部。更新履歴の内容をもとに整理したもので、統計データではありません

5. 他に合わせて動く指定

ボタンの高さが、別のコンポーネントに合わせて動く

指定が変わる理由は、アクセシビリティのような明確な要件だけではありません。他の要素との釣り合いを取るために動く指定もあり、単体だけを見ていると理由が見えにくい種類の変更です。単体の指定だけを眺めていると、この種の理由には気づきにくいままです。

ボタンの高さは、別のコンポーネントの大きさに合わせる形で40pxから48pxへ変更された例があります⁹。ボタン単独では説明のつかない変更ですが、周辺の部品と並べて見ると理由が見えてきます。周辺の部品と合わせて確認する習慣があると、こうした変更にも早く気づけます。

この種の変更を「好みで動いた」と受け取ると、次に似た指定に出会ったときに同じ判断を誤ります。合わせる先が何かを確かめる視点を持っておくと、提案の説得力が上がります。合わせる先を尋ねる姿勢は、提案の説得力を高める材料になります。

呼び方そのものが変わることもある

指定は数値だけでなく、呼び方そのものが変わることもあります。区分の名前が変わると、資料の読み方も少しずれ、以前のやり取りとの対応づけが必要になります。呼び方の変更は数値の変更と違って、見た目には現れにくい種類の更新です。

実際に、ページの区分を指していた名称は「基本デザイン(foundations)」という表記に変更されています¹⁴。以前の資料を参照するときは、名称の対応関係を確かめておく必要があります。古い資料と新しい資料を突き合わせるときは、名称の対応づけを先に済ませておくと迷いが減ります。

数値の変更よりも、呼び方の変更のほうが見落としやすい類いの更新です。呼び方の変化に気づけるかどうかも、実装側の確認力として積み重なっていきます。次の章では、受け取るデータの単位そのものが変わっていく例を見ていきます。

6. 受け取る形そのものが変わる

レイヤー・作例・素材、それぞれで起きている変化

指定の話は数値や色に限りません。実装側が受け取るデータそのものの形も、更新のたびに変わっていきます。渡される単位が変わると、確認する手順そのものを見直す必要が出てきます。手順を見直す手間を惜しむと、古い前提のまま作業を続けてしまう恐れがあります。

レイヤーの構造そのものが整理される更新も行われています¹⁰。積み上がっていた構造が整理されると、受け取る側の読み方も変わり、以前の手順のまま進めると迷いが生まれます。構造が整理されると、以前は複数箇所に分かれていた確認が一箇所で済むようになる場合もあります。

作例は、想定されるページ数の幅を満たす形に修正されています¹¹。イラストの素材は、デザインデータから分離されています¹³。受け取る単位が、以前より細かく分かれてきています。受け取る単位が細かくなるほど、全体像を把握する手間も新たに発生します。

同じ「デザインデータ」でも、渡される単位が変わってきている

対象ごとに、これまでどう扱われていたか、今回どう変わったのかを並べると、受け取る単位が分かれていく方向性が見えます。同じ名前で呼ばれていても、中身の単位が変わっていることに気づけるかどうかが実務上の差になります。次の一覧は、同じ「デザインデータ」という呼び名の中身がどう変わってきているかをまとめたものです。

対象	これまで	今回の扱い
レイヤーの構造	個別に積み上がった構造	整理された構造
作例	一部の幅だけを想定	想定されるページ数の幅に合わせて修正
イラストの素材	デザインデータに同梱	デザインデータから分離

単位が細かく分かれるほど、必要な部分だけを受け取れるようになります。反面、どの単位で渡されているかを確かめずに扱うと、古い前提のまま作業を進めてしまう場面も出てきます。単位が変わったことに気づかないまま進めると、後になって認識のずれが表面化します。

職種の分担よりも、受け取る単位そのものの変化を追うほうが、実装側にとっては実務に近い確認になります。渡され方が変わったことに気づけるかどうかが、次の案件でも差になります。受け取り方の変化を追う視点は、職種の分担を確かめるより実務に直結します。

図の作成：Remogu編集部。更新履歴の内容をもとに整理したもので、統計データではありません

7. 守る範囲は増えていく

守る範囲は、これからも増えていく

指定は、既存のものが変わるだけでなく、新しく増えることもあります。増えた分だけ、実装側が確かめる範囲も広がっていき、覚えることが減るという方向には進みにくいのが実情です。増える指定を後追いで覚えるより、増える理由の型を先に押さえておくほうが負担は軽くなります。

実際に、「タブ」という新しいコンポーネントが追加されています¹⁵。新しい部品が増えるたびに、状態の数や表現のルールを新しく確かめる必要が出てきます。新しい部品が加わるたびに、既存の指定との整合も併せて確かめる必要が出てきます。

境界は職種では引けません。理由が添えられているか、他の要素に合わせて動いているか、受け取る単位がどう変わったか——この記事で見てきた手がかりを使えば、増え続ける指定にも同じ考え方で向き合えます。手がかりを一つずつ確かめる姿勢さえあれば、指定の数が増えても迷いは積み重なりません。

Remogu（株式会社LASSIC運営）は、リモートワーク案件に特化したエンジニアマッチングです。案件の90%以上がフルリモート可能です。実装から少し離れて、こうした読み方が活きる案件を確かめてみるのも、次の一歩になります。

デザインシステムを使っていない案件でも、この考え方は使えますか

使えます。ここで示した境界の引き方は、指定に理由が添えられているかどうかを確かめる考え方であり、特定のデザインシステムの有無に依存しません。公開されている更新履歴が無い案件では、指定を受け取った際に理由を一言確かめる、という形で同じ考え方を持ち込めます。更新履歴が公開されていない案件ほど、指定を受け取った時点で理由を確かめる一言が効いてきます。

指定に理由が書かれていないときは、どう伝えればいいですか

理由が見当たらない指定については、変えたい・変えたくないという主張ではなく、「この部分に理由があるか確認したい」という形でクライアントと協議する進め方が向いています。理由が分かれば要件として受け止め、分からなければ相談できる余地として扱えます。理由の有無を先に切り分けておくと、協議の場でも要点がぶれません。

新しいコンポーネントが増えると、実装側の負担はどう変わりますか

守る対象の数がその分だけ増えるので、確認する範囲は広がります。ただし、理由の有無、他の要素との釣り合い、受け取る単位の変化——この記事で見てきた手がかりを使えば、増え続ける指定にも同じ考え方で向き合えます。次に指定を受け取ったとき、その理由を一つ確かめてみることから始めてみませんか。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 デジタル庁「デジタル庁デザインシステム お知らせ（デザインデータ）」指定の理由（2026年8月）
＊2 デジタル庁「デジタル庁デザインシステム お知らせ（デザインデータ）」操作の見え方（2026年8月）
＊3 デジタル庁「デジタル庁デザインシステム お知らせ（デザインデータ）」消える指定（2026年8月）
＊4 デジタル庁「デジタル庁デザインシステム お知らせ（デザインデータ）」状態ごとの指定（2026年8月）
＊5 デジタル庁「デジタル庁デザインシステム お知らせ（デザインデータ）」やり方が変わる（2026年8月）
＊6 デジタル庁「デジタル庁デザインシステム お知らせ（デザインデータ）」読みやすさ（2026年8月）
＊7 デジタル庁「デジタル庁デザインシステム お知らせ（デザインデータ）」移行の終わり（2026年8月）
＊8 デジタル庁「デジタル庁デザインシステム お知らせ（デザインデータ）」2種類のトークン（2026年8月）
＊9 デジタル庁「デジタル庁デザインシステム お知らせ（デザインデータ）」そろえる変更（2026年8月）
＊10 デジタル庁「デジタル庁デザインシステム お知らせ（デザインデータ）」渡し方の整理（2026年8月）
＊11 デジタル庁「デジタル庁デザインシステム お知らせ（デザインデータ）」作例の役割（2026年8月）
＊12 デジタル庁「デジタル庁デザインシステム お知らせ（デザインデータ）」状態の表し方（2026年8月）
＊13 デジタル庁「デジタル庁デザインシステム お知らせ（デザインデータ）」持ち場の分離（2026年8月）
＊14 デジタル庁「デジタル庁デザインシステム お知らせ（デザインデータ）」呼び名の変更（2026年8月）
＊15 デジタル庁「デジタル庁デザインシステム お知らせ（デザインデータ）」増える対象（2026年8月）