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

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%以上がフルリモート可能です。実装から少し離れて、こうした読み方が活きる案件を確かめてみるのも、次の一歩になります。

8. よくある質問

旧トークンが削除されると、どの指定が参照できなくなりますか

色のトークンではFocus-BlueとFocus-Yellowが削除されました¹。移行用に保持されていた旧カラートークン¹と旧タイポグラフィトークン¹も削除されており、いずれも参照できません。

ホバー時の表現は、何を理由に変更されましたか

コントラストの要件を満たすためです¹。背景色を変える方法をやめ、下線の太さを変える方法に変わりました。

基本の文字色は、何を理由に変更されましたか

ディスレクシアへの対応を理由に、ベースとなるテキストカラーがGrey-900からGrey-800へ変更されました¹。見た目の好みではなく、読む側の条件に合わせた設定です。

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

出典・参考情報

＊1 デジタル庁「デジタル庁デザインシステム お知らせ（デザインデータ）」指定の理由（2026年8月・2026年10月確認）