Web Development Guidelines

基本

ディレクターはクライアントから指定の Web サイト要件を満たし、Web サイトのビジネスゴールを達成するため、適切な情報提供、提案を行う、また Web サイトの情報設計からプロジェクトの進行管理、プロジェクトメンバーの業務管理、納品物の品質管理を適切に行うものとする。

ディレクターはクライアントを含めプロジェクトメンバー間でのコミュニケーションを積極的に取ることで円滑なプロジェクト進行を心がける。また、クライアントに対しては進捗の報告、情報共有を適時、および明確に行い、信頼関係の構築に努める。

プロジェクトキックオフ

新規 Web サイト制作案件が立ち上げに際して行われるキックオフミーティングについては、下記の要領を基本として開催する。クライアントとの間では現状の把握、ゴールイメージの共有、プロジェクト進行におけるスケジュールを含めた認識の共有を主な目的とする。

また、社内のプロジェクトメンバー間においては、現状の把握、ゴールイメージの共有、スケジュールの共有の他、要件の確認に伴い、事前の意見交換を目的とする。これは例えば「事前に実装担当者、デザイナー、プログラマが知っていればもっと効率よくやる方法があった」「こうしておいてくれればもっと作業がしやすかった」といった無駄をなくすことで、生産性を高め、納期の短縮や品質の向上でクライアントに還元する。

クライアントと行うキックオフ

• プロジェクトの要件確認
  • 求められる動作環境や検収条件などの確認
  • 納品物の内容や納品形態についての確認
  • 開発言語、環境の指定やその他要件の確認
• プロジェクトの対象となる Web サイト等のユーザー層、ターゲット層の理解（必要に応じて下記を実施）
  • ユーザーのセグメンテーションとペルソナ
  • ユーザーインタビュー
  • カスタマージャーニーマップ
  • 既存 Web サイトが存在する場合はその分析
    • アクセスデータ解析
    • ヒューリスティック評価
    • ユーザビリティテスト
• クライアントビジネスの理解
• スケジュールの共有
• 議事録の作成（プロジェクトメンバー間で共有すべき決定事項などは「ヒアリングシート」としてまとめる）

社内キックオフ

• プロジェクトの要件確認
  • 求められる動作環境や検収条件などの確認
  • 納品物の内容や納品形態についての確認
  • 開発言語、環境の指定やその他要件の確認
• プロジェクトの対象となる Web サイト等のユーザー層、ターゲット層の理解
• 既存 Web サイトが存在する場合はその分析結果の共有
• クライアントビジネスの理解
• スケジュールの共有
• 議事録の作成

社内プロジェクトメンバーのアサイン

社内におけるプロジェクトメンバーのアサインは Web サイト制作事業の責任者権限で行う。リソース管理の観点から、ディレクターが現場の独自判断でメンバーをアサインしたりすることは禁止する。

守秘義務契約、及び業務委託契約を結んでいない外部の個人事業主、及び企業へのプロジェクト情報の開示や作業の依頼は当然ながら一切禁止する。

ドキュメント

制作過程でディレクターが作成する標準的なドキュメントは下記の通りとする。フォーマットは問わないが、クライアント環境で問題なく閲覧ができること。当然、プロジェクトに応じて必要なドキュメントは変化する。

• ヒアリングシート（キックオフミーティング時に確定した内容などをまとめたもの）
• スケジュール案
• サイト構成図
• ワイヤーフレーム
• 導入 CMS 等の操作マニュアル（状況に応じて）

CMS 等のマニュアルに関しては通常作成不要。開発元の公式ドキュメントがある場合はそれで代用できる。カスタムフィールドを用いた特殊な入力画面をクライアントに提供するなど、公式ドキュメントでは対応できない場合などに、簡易なものを作成する前提とする。

プロジェクト進行における連絡手段

プロジェクト進行中のクライアントを含むプロジェクトメンバーとの連絡・情報共有の手段は、クライアントと協議の上、Backlog、Slack、Chatwork をはじめとしたチャット・プロジェクト管理ツールを利用するが、原則として Backlog の利用を推奨する。ただし、クライアントがすでに Slack、もしくは Chatwork を利用している場合など、Backlog よりもそちらを利用した方が効率がよいと考えられる場合はこの限りではない。

プロジェクトのキックオフがされた後、ディレクターによってチャット・プロジェクト管理ツールに当該プロジェクト用のスペースが開設され、プロジェクトメンバーが招待される。

なお、クライアントの要望や、プロジェクトの特性、要件に応じて、連絡・情報共有用のツールは前述したサービス以外にも最適なものを選択できる。ただし、情報管理の観点から、使用ツールの選定はクライアント、および当社の情報管理ポリシーに基づき行う他、連絡の内容がすべて、ログとして長期にわたり保存され、後から検索可能なツールを選択すること。

アクセシビリティ

設計段階からアクセシビリティに配慮する。

例えばカルーセルパネル（数秒ごとに画像や要素がスライド等で差し替わる UI）は数秒間で要素内に記述されたテキストを把握できない可能性や要素が切り替わるまでの間に正しく操作できない可能性もあり、重要なナビゲーション機能をカルーセルに持たせるべきではないと考える。

あるいはナビゲーション機能を持たせるのであればカルーセルパネルの動作を一時停止できる仕組みを持たせるなど配慮が必要である。

また、色に依存したナビゲーション、文章の使用は禁止する。例えば「下記の赤い方のボタンを押してください」「文章内の赤い文字は重要項目です」などの表記、あるいは色を選択させるような際にカラーパレットのみで色名のラベルがない等の UI は、一部の色覚障がい者にとっては認識できない可能性がある。UI や文章作成時には配慮するものとする。

操作性

特別、スマートフォン等、画面サイズの小さいデバイスへの対応を行わない場合でも、マルチデバイスで操作しやすい UI を意識して設計する。「スマートフォンサイトではないのでスマートフォンでの操作が困難でも仕方ない」ということはない。

文字サイズ変更ボタン

Web ページ内の文字サイズ変更を Web サイト側で提供する所謂「文字サイズ変更ボタン」の提供は原則として行わない。文字サイズの変更はブラウザ UI に任せるべきで、必要であれば操作方法をヘルプページ等に表記するものとする。

ページタイトルやURL

各ページのタイトル、およびディレクトリ名やファイル名はディレクターが実装担当に指示すること。実装担当者が勝手に決めたりはしない。

ページ一覧（各ページタイトルや URL を記載した）をワイヤーフレームと同一ファイル内などに作成し、実装担当者はそれを基準に各ページを作成する。

必要に応じて、ページ内に記述する <meta name="description" /> の値なども決められる場合は記述しておく。

なお、この一覧に CSS や JavaScript 等、ページで読み込まれる各リソースのパス指定などは不要（これらに関しては別途コーディング関連のセクションで定める）。

文言の統一

案件の状況やクライアントの要望により異なるものの、原則的には下記のように Web サイト内で使用する文言を統一する。表記のブレによる品質の低下を防ぐ。

特にクライアントからの明確な指定がなく、迷ったときは、例えば下記を参考に統一する。

• Webサイトのトップページに移動するリンクのラベル：トップページ（×ホームページ、×トップ）
• ページ上部に移動するページ内リンクのラベル：このページの上部へ（×ページトップ、×トップ）
• お問い合わせ（×お問合せ、×お問い合せ）
• メールアドレス（×Mailアドレス、×アドレス、×email、△E-mail）
• 英数字は原則半角、URLや数値、英単語を全角で記述しない
• 文章内の全角スペースは半角に統一

その他、サイト内で複数の文言が混在しないように注意すること。

• 例）弊社|当社、貴社|御社、お客様|クライアント、～します|～いたします …etc

アクセス解析

制作する Web サイトに対して、アクセス解析ツールの導入は必須と考える。なお、クライアントからの特別な指定がない場合のアクセス解析ツールとしては、Google Analytics 4（GA4）を導入する前提とする。

ディレクターは、Web サイト公開前に必ず Web サイトへの Google Analytics 計測タグの設置、及び設定（主にコンバージョン設定）が行われていることを確認する。

また、Web サイトには必ず個人情報保護方針（プライバシーポリシー）を掲載し、その中で、Google Analytics の使用、およびクッキー（Cookie）を使用したアクセスログ収集に関する掲示を行うものとする。その際、Google 社のプライバシーポリシーページへのリンクもあわせて掲載すること。（詳しくは個人情報保護方針のセクションを参照）

個人情報保護方針

Web サイトには個人情報保護方針（プライバシーポリシー）のページを必ず用意する。クライアントによってすでに個人情報保護方針が策定されている場合はそれに準じるが、アクセス解析に Google Analytics を用いる場合は、必ず Google Analytics の利用規約に則り、クッキー（Cookie）を使用したアクセスログ収集に関する掲示を追加で行うものとする。

その際、Google 社のプライバシーポリシーページへのリンクもあわせて掲載すること。下記の記述をサンプルとして利用できる。

---

アクセス解析について

当サイトにおけるアクセスログの収集、および解析には Google Analytics を使用しています。Google Analytics ではクッキー（Cookie）を使用してアクセスログを収集しますが、これは個人を特定する情報を含みません。

なお、収集されるアクセスログは Google 社のプライバシーポリシーに基づいて管理されます。

Google Analytics で収集したアクセスログに関するプライバシーポリシーについては、下記をご確認ください（外部サイト）。

• ユーザーが Google パートナーのサイトやアプリを使用する際の Google によるデータ使用
• Google 社のプライバシーポリシー

---

上記サンプル文章は、下記ページの内容を参考にしたもの。

• 個人情報保護方針：バーンワークス株式会社

サーバや外部サービスの契約

クライアントから新規のサーバ契約やその他外部サービス（ドメイン取得、ASP の利用等）の利用を求められた場合は、当社にてその選定や申し込みの代行を行うなど、最大限協力するものとする。しかし、実際の契約自体はクライアントとサービス提供元間での直接契約とし、当社が代理契約をすることは原則として行わない。

アクセシビリティ

デザイン時にもアクセシビリティに配慮すること。

背景色とテキストのコントラスト、色覚障がい者向けの配色等に考慮する。WCAG 2.2 における達成基準は下記引用の通り。

1.4.3 コントラスト（最低限レベル）の達成基準

テキスト及び文字画像の視覚的提示には、少なくとも 4.5:1 のコントラスト比がある。ただし、次の場合は除く（レベル AA）。
a) 大きな文字 サイズの大きなテキスト及びサイズの大きな文字画像には、少なくとも 3:1 のコントラスト比がある。
b) 附随的 テキスト又は文字画像において、次の場合はコントラストの要件はない。アクティブではないユーザインタフェース コンポーネントの一部である、純粋な装飾である、誰も視覚的に確認できない、又は重要な他の視覚的なコンテンツを含む写真の一部分である。
c) ロゴタイプ ロゴ又はブランド名の一部である文字には、最低限のコントラストの要件はない。

WCAG 2.2「1.4 判別可能のガイドライン」から引用

コントラストのチェックに関しては、下記のツール等を推奨。

• Colour Contrast Analyzer (CCA)

フォントサイズやボタンサイズ

フォントサイズは、最小サイズを 12px 相当とする。ただし、重要でない注釈等に関しては 10px 相当まで許容する。現在のディスプレイサイズ等を考慮すれば、標準的なフォントサイズは本文で 14px 相当〜 18px 相当が妥当と考える。その他、ボタンサイズ等についてはタッチデバイスのセクションを参照。

デザインデータ

基本的には Figma を使用して作成することを推奨する。インストール版ソフトウェアやデスクトップアプリの場合は、できる限り最新バージョンを使用し、プロジェクトメンバー間でのデータ互換性による作業遅滞を避けるよう努めること。

デザインデータには必ず「指示」レイヤーを追加し、リンクカラー（通常、ホバー時、訪問済み、アクティブ時）の指定をはじめ、実装担当者向けの指示を記載するのもとする。

ディレクター、およびデザイナーはデザインの進行、確定にあたり、実装面からの意見を必ず実装担当者に聞くこと。それにより実装時になってデザインの不具合により手戻りが発生するなどの無駄を省き、実装面の負荷を低減する。

原則としてデザインデータのクライアントへの提供は行わないが、あらかじめ業務委託契約内などでの取り決めがある場合、デザインデータはクライアントに納品される。レイヤーの分け方や名前の付け方など、他の人が見てもわかりやすいように配慮すること。これは実装担当者の作業効率も向上させる。

スタイルガイド

スタイルガイドの作成を行う。ワイヤーフレームに特に指示がなかった場合でも、各見出しレベルのデザイン（h1〜h6）、リスト（ul, ol, dl）、表組み（table）、引用（blockquote）など、頻繁に使用される HTML 要素のデザインはスタイルガイドとして用意する。

また、各要素が配置された際の他要素とのマージンなどもスタイルガイド内に明記する。この際、例えば同じレベルの見出しにもかかわらず、配置される場所によってマージンが異なるなど、1つの要素に複数のスタイルが混在するような事態は避けること。

加えて、デザイン内で使用している基本カラーの一覧、および使用フォントの一覧もスタイルガイド内に記載すること。

画像素材のライセンス

画像の著作権には十分配慮し、著作権、モデルリリース等の権利関係がクリアされていない、あるいは明確にされていない画像素材の使用は一切禁止。また、画像の使用にあたり、提供元サイトへのリンクが必須の素材（所謂リンクツール）、およびサービスの利用も禁止とする。

素材として使用する画像のライセンスは、原則として「ロイヤリティフリー」のものとする。ただし、クライアントの許可を得た上で、「ライツマネージドライセンス」の画像素材を購入することは問題ない。その際の契約は素材提供業者とクライアント間で行い、当社が代理で契約することはしない。

SVG

アイコン、簡単な図版などに関しては、SVG の使用を推奨する。SVG での書き出しは実装担当者が行う。実際のデザイン上での表示サイズなどはデザインデータ内で明確に指定すること。

長いテキストの可読性など

行間や行長

Web ページ内に表示するテキストの行間や各段落の間隔などは下記を基準とする。

• 行の間隔をフォントサイズの少なくとも 1.5 倍に設定する（例：line-height: 1.5;）
• 段落ごとの間隔をフォントサイズの少なくとも 2 倍に設定する
• 文字の間隔をフォントサイズの少なくとも 0.12 倍に設定する（原則として letter-spacing: normal を推奨）
• 単語の間隔をフォントサイズの少なくとも 0.16 倍に設定する（日本語の場合はあまり関係しないが、原則として word-spacing: normal; を推奨）

なお、1行あたりの文字数（行長）は、最長で 30〜40 文字程度になるよう調整することが読みやすさの点から望ましい。

上記はデザインの要件や文字サイズ等によって変動、もしくは Web ページを閲覧する環境に依存するため、あくまで基準とするが、1行あたりの文字数が極端に多すぎる場合、逆に少なすぎて改行が多すぎる場合などは可読性を低下させるため注意が必要。

デバイスフォントの利用

画像処理が適当である箇所を除いては、なるべくデバイスフォントを使用する前提でデザインすること。また、デザインデータ内では、画像処理すべきテキストとそうでないものが実装担当者にわかるよう、指示レイヤーに記述する。

Web サイトのパフォーマンス、メンテナンス性や CMS の利用も考慮し、バナーなど画像化が必然な場合を除き、テキストの画像化は原則として禁止する。

Favicon

新規構築の Web サイトに関して、デザインには Favicon のデータも含めること。既存のデータがある場合はそれを使用する。サイズは最低限、下記を実装担当者が生成する前提でデザインを用意すること。基本的にはすべて同じデザインとするため、最小サイズでも認識しやすいようにデザインする。

• favicon.ico（16×16, 32×32, 48×48）
• favicon.png（64×64）
• apple-touch-icon.png（180×180）

favicon.png は 64×64 の画像を作成せず apple-touch-icon.png（180px×180px）のファイル名だけ変更して同じ画像を使用してもよい。

実装担当者は上記サイズの画像をデザイナーのデータを基に生成する。SVG ベースの favicon（favicon.svg）も現代のブラウザではサポートされており、使用を検討してよい。

基本

明確にスマートフォン対応が要件に含まれていない案件においても、スマートフォンやタブレットによる操作を想定したデザインや実装が求められる。特に後述するタッチデバイスの特性に関しては十分配慮すること。

画面サイズが小さいデバイスでは、モーダルウィンドウ形式の UI は操作性を著しく低下させる可能性があるため避ける。あるいは画面サイズが小さい場合は無効にするなどの配慮が必要。

タッチデバイス

タッチ操作を考慮したデザインや実装を行うこと。マウスオーバーに依存した UI は避ける他、タッチ操作により表示非表示を切り替える所謂アコーディオン形式の UI は、数が多くなると操作が煩わしくなるため、はじめからすべて開いた状態にするなど配慮する。

画面の縦サイズが長くなることよりもタッチ操作が多くなりすぎないことを重視すること。

また、タップ可能な要素（ボタンやリンク）には、最低でも 44px × 44px 以上のサイズを持たせること。もし視覚的にそのサイズを持たせることが難しい場合はタップ可能領域を広げるなどして対応する。また、タップ可能な要素同士の間には十分な余白をもたせること（ただし十分にサイズが大きいタップ可能要素同士であれば問題はない）。

タップ可能な要素は視覚的にわかりやすいよう配慮する。

ブレイクポイント

要件説明時に特別な指定がないレスポンシブ Web デザイン対応案件では、ブレイクポイントを 1つ、768px に設定することを基準とする。スマートフォンの最小画面サイズは横幅 360px とし、768px までの間は横サイズの可変で対応する。

ディスプレイの横サイズ 768px 以上のデバイスに関しては PC 向けレイアウトを表示する。

ただし、上記はプロジェクトの要件によって変動する場合がある。タブレットサイズを独立したブレイクポイントとして扱うなど、より細かな設定が必要な場合はプロジェクト要件に応じて決定する。

高精細ディスプレイ対応

所謂 Retina 対応。

前提として、スマートフォン向けページのデザインに際しては、レイアウトの基準は、最小横幅を 360px での表示とし、そのサイズで文字サイズやレイアウトが最適化されていること。

ブレイクポイントのセクションで指定されているとおり、複数のブレイクポイントを指定しない案件におけるスマートフォン向けデザインの最大サイズは横幅 768px での表示となるため、360px〜768px までの間でデザインの整合性がとれるように配慮する事（この間の画面サイズによってレイアウトが変わるような指定は禁止。要素のサイズ可変で対応する）。

よって、Retina 対応が必要なスマートフォンサイトのデザインデータの作成は、ブレイクポイントとなる 768px の 2 倍の横サイズ（1,536px）で行うこととなる。その際、SVG アイコンや CSS を利用し、極力画像の使用を避けるデザインを心がけることで実装時の負担を低減する。また、Web サイトの表示速度面も配慮すること。

PC 向け Web ページについても、HiDPI ディスプレイ（いわゆる Retina ディスプレイ）を搭載した Mac や外部モニターが広く普及しているため、高精細対応は検討すること。ただし、画像のファイルサイズ増加に十分注意し、WebP や AVIF 形式の採用と srcset 属性による解像度切り替えを基本とする。また、SVG で代替できる画像は SVG を優先する。

基本

納品は、クライアントが Git および GitHub の使用、操作に慣れている場合は、プロジェクトで使用しているリポジトリに、クライアント担当者を招待することで引き継ぎを行う。そのまま運用・更新を当該リポジトリで行う場合は、別途ブランチの作成ルール、コミットやプルリクエストのルールなどを事前にクライアントとの間で決めておくこと。

納品後に希望される場合は、リポジトリの移管も可能。その場合は移管先リポジトリをクライアントに用意して頂いた上で、手順に基づいて移管する。

上記以外で、クライアントが Git および GitHub を使用できない事情がある場合は、HTML、CSS、JavaScript 等ファイル、及び画像を含む、Web サイトを構成するリソース一式を、クライアントサーバにアップロードした状態で納品とする。

Git 管理外にある、例えば外部 CDN から直接読み込まれた JavaScript ライブラリや CMS、および使用プラグインに関してはその情報を 1つのドキュメントにまとめてディレクターに提出すること。

また、クライアントサーバへのアップロードにて納品する場合、Sass ファイルや、プリプロセスされた中間制作物一式（中間制作物のセクションを参照）は、特に要望がない限りはクライアントへは納品しない。元のファイル群が Git 管理されていることをクライアントに説明し、納品物への直接の編集は、差分や修正履歴の把握が難しくなることを前提として共有すること。

バージョン管理

バージョン管理には Git、および GitHub を使用する。新規リポジトリの作成に当たっては別途定める社内ルールに基づいてディレクターが申請を行うこと。プロジェクトに使用されるリポジトリはすべてプライベートリポジトリとし、会社契約以外の個人リポジトリをプロジェクトに使用することなどは一切禁止する。

ただし、クライアントからの指定で、クライアントが管理するリポジトリでの作業を行う場合などは、クライアントからの指示、要望に従って対応すること。

なお、デザインデータに関しては、GitHub にはアップロードしないこと。

ディレクトリ構成

既存の Web サイトを踏襲する場合やクライアントからの指定がある場合等を除き、基本的なディレクトリ構成は下記の通りとする。

htdocs/
├── index.html
└── static/
       ├── css/
       │     └── style.css
       ├── img/
       │     ├── share/
       │     │     └── logo.png
       │     └── service/ (例)
       │            └── image.png
       └── js/
              └── function.js

Web ページ以外のファイルについては、static ディレクトリを最上位ディレクトリとした上で、スタイルシートは css ディレクトリへ、同様に、画像、JavaScript ファイルをそれぞれのディレクトリに格納する。画像は全ページ共通で使用するものを share ディレクトリへ、その他は使用するページのディレクトリ構成に合わせて格納する。

フレームワークやビルドツールを利用する場合は、そのツールの標準的なディレクトリ構成に準じること。

ファイル名の基本ルール

画像などのファイル名は下記の基本ルールに則って付ける。

• 区切り文字はハイフン（-）を使用する。
• 大文字小文字を混ぜず、すべて小文字で付ける。
• 同じ種別のファイルは頭に同じ接頭辞を付ける。例えば、バナー関連なら bnr- など。
• 背景画像は頭に bg- という接頭辞を付ける。
• 例えば同じ内容の画像でサイズが異なる場合はサイズを入れたり（例：example-200x50.png）、デバイスピクセル比を入れたりしてわかりやすくする（例：example-x2.png）。
• ある class 名に対応する画像は、class 名と同じファイル名を付けるなどわかりやすくするとよい（例：bg-module-section-header.png）。

ディレクトリ構成のルールとあわせて、第三者が見てもわかりやすいファイル名を心がけること。

動作検証ブラウザ

当社が標準で保証する動作環境ブラウザは下記の通りとする。このセクションは 6ヶ月ごとに見直される。

パソコン

• Microsoft Edge（Chromium 版）最新版および 1つ前のバージョン
• Google Chrome 最新版および 1つ前のバージョン
• Safari 最新版および 1つ前のバージョン
• Mozilla Firefox 最新版および 1つ前のバージョン

スマートフォン

スマートフォン OS に関しては、原則としてプロジェクト開始時点における最新リリースから 1 バージョン前までを動作確認対象とする。

• iOS Safari（最新版および 1つ前のメジャーバージョン）
• Android Chrome（最新版）

その他

ヘルプページ等に対応ブラウザ（推奨環境）を記載する場合は、上記動作検証ブラウザを踏まえ、下記の記述を基本とする。

---

JavaScript、スタイルシート、画像表示が有効になっている下記のブラウザソフト

• Microsoft Edge 最新版
• Google Chrome 最新版
• Safari 最新版
• Mozilla Firefox 最新版

---

プログレッシブエンハンスメント

上記、動作検証ブラウザに含まれない旧式ブラウザに関しても、最低限必要な操作、情報の取得ができるよう、スタイルシートを無効にした場合の構造には配慮すること。例えばある CSS プロパティが解釈されなかったときに、重要な情報が表示されない、といったことが起こらないように最低限の配慮は必要。一方で多少のレイアウト崩れや装飾目的の画像の表示がされないといった問題に関しては気にする必要はない。

HTML コーディング → アクセシビリティのセクションや、JavaScript → 基本・バリデーションのセクション等もあわせて参照のこと。

文字コード

Web サイトの文字コードは、特別な指定がない限り UTF-8 (no BOM) を使用すること。HTML 文書においては、<meta charset="utf-8" /> を head 要素内の可能な限り上部（基本的には最初の子要素として）に記述すること。

インデントルール

インデントを行う場合、タブ文字は使用しないこと。エディタの設定等で 1タブ = 2半角スペース に設定し、1階層の字下げは 2半角スペースを基準とする。HTML のインデントは任意。CSS は宣言ブロック部分に必ずインデントを入れること。

<!-- 推奨 -->
<ul>
  <li>HTML</li>
  <li>CSS</li>
</ul>

/* 推奨 */
.example {
  color: red;
}

/* 非推奨 */
.example {color: red;}
.example{
color:blue;
}

CSS においては、@media 規則内に記述した規則集合を、すべて 1階層インデントすること。

/* 推奨 */
@media (min-width: 1200px) {
  .block-container {
    max-width: 970px;
  }
}

ただし、プリプロセッサやビルドツールを使用する場合においては、最終的な納品物からインデントや改行が削除されていてもよい。元のコーディングファイル、あるいは中間制作物はこのフォーマットに従うこと。

大文字小文字

HTML の要素名、属性名、および CSS 内のカラーコード等はすべて小文字で統一すること。また、画像をはじめとしたファイル名などでも大文字小文字を混在させたりしないこと。

<!-- 非推奨 -->
<A HREF="/sample/"><IMG SRC="sampleImage.png" ALT="Sample" /></A>

<!-- 推奨 -->
<a href="/sample/"><img src="sample-image.png" alt="Sample" /></a>

/* 非推奨 */
.example {
  color: #E5E5E5;
}

/* 推奨 */
.example {
  color: #e5e5e5;
}

コメント

HTML、CSS、JavaScript 共にわかりやすくコメントを付けること。ただし、プリプロセッサやビルドツールを使用する場合においては、最終的な納品物にコメントが含まれなくてもよい。元のコーディングファイル、あるいは中間制作物にコメントが残るようにすること。

HTML において、深くネストした要素や長い構造ブロックの閉じタグ付近に、構造を明示するコメントを入れることは許容する。ただし、特定のフォーマットは定めない。現代のエディタやコードフォーマッターが構造の把握を支援するため、コメントの使用は本当に必要な箇所にとどめること。

また、HTML 文書内で不要になった要素ブロックや、CSS ファイル内の不要なスタイル宣言等を、一時的な場合を除いてコメントアウトで長い期間運用することは推奨しない。

viewport

viewport に関しては、原則として下記の記述を標準とする。

<!-- 推奨 -->
<meta name="viewport" content="width=device-width, initial-scale=1" />

ユーザーによる拡大縮小ができなくなるため、下記の記述を使用してはいけない。

<!-- 禁止 -->
<meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no" />

補足

なお、ページ幅が固定されている Web ページの場合、viewport meta を記述しない、もしくは数値を指定して記述する。

<meta name="viewport" content="width=640px" />

スキームの記述

外部 CDN からの JavaScript ライブラリ読み込み等を行う場合、URI のスキーム（http: / https:）はすべて https:// から記述すること。

<!-- 非推奨 -->
<script src="http://example.com/library.min.js"></script>

<!-- 非推奨 -->
<script src="//example.com/library.min.js"></script>

<!-- 推奨 -->
<script src="https://example.com/library.min.js"></script>

原則として HTTPS で提供されない第三者サーバからのライブラリの読み込みは禁止する。また配信先ドメイン所有者の信頼性については事前に確認すること。

また、外部 CDN からスクリプトやスタイルシートを読み込む場合は、Subresource Integrity（SRI） を利用してリソースの完全性を検証することを推奨する。CDN が改ざんされた際に意図しないスクリプトの実行を防ぐことができる。

<!-- 推奨：SRI ハッシュを付与した例 -->
<script
  src="https://example.com/library.min.js"
  integrity="sha384-xxxxxxxx"
  crossorigin="anonymous"
></script>

SRI ハッシュは SRI Hash Generator などのツールで生成できる。なお、npm 経由でパッケージを管理しローカルでバンドルする場合は SRI の付与は不要。

ライブラリ・フレームワーク

CSS / JavaScript ライブラリやフレームワークの利用はプロジェクトの要件に応じて選択可能。ただし、使用するライブラリやフレームワークに関してはメンテナンスが継続されていること、バグフィックスや脆弱性への対応等が、適切に行われていることを重視して選択すること。また、各ライブラリ、フレームワークの利用規約、ライセンスは必ず確認し、不明な点がある場合はディレクターに相談すること。

OSS については Fork した上で、クライアントの要望に合わせて利用することも可能だが、継続的なメンテナンスが可能、かつ会社としてメリットがある場合のみとする。

また、使用したライブラリ・フレームワークは一覧できるように別途ドキュメントに記載すること。

基本・バリデーション

基本的な考え方

HTML はメンテナンス性を考慮すること。各ブロックのモジュール化を意識し、CSS の記述と合わせて、あるブロックを他のページにそのまま移動したり、同一ブロック内で要素が多少変更されたとしても（ul 要素 → ol 要素や段落の追加など）、レイアウトや見た目が変化しないように考慮し、モジュールの使い回しを容易にすること。

HTML Living Standard で追加された新要素は適切に使用すること。また、input 要素の type 属性値などについても HTML Living Standard から追加された属性値を用途に応じて適切に使い分けること（type="email"、type="number"、type="tel"、type="search" など）。

id 属性は適切に使用すること。セレクタとしての利用も特に制限しないが、多用しすぎてメンテナンス性や再利用性が妨げられてはならない。

バリデーション

各要素は、HTML Living Standard のコンテンツモデルや使用できる文脈に基づき適切に記述すること。またアウトラインが適切かについて必ず確認すること。

また、納品前の HTML ファイルは、必ず The W3C Markup Validation Service によるチェックを行うこと。特に HTML タグの閉じ忘れといったミスは避ける。なお、バリデーションはビルドツール等によって行っても構わない。

アクセシビリティ

WCAG 2.2 の 適合レベル A に該当する達成基準を満たすことを社内基準とする。ただし、Web サイトの特性や要件によっては、適合レベル A 対象となる全項目にわたる適合を必須とするものではなく、また逆に 適合レベル AA、適合レベル AAA 項目を無視してよいということではない。WCAG 2.2 の全項目に関して適切な知識を持って制作にあたる。

最低限、下記の事柄についてはクリアすること。

• 各ページにはページの内容を推測しやすい適切なタイトルを必ず付けること。ページ分割等を行う場合も、（1/2ページ）などとページ数表記を入れるなどして、ページタイトルは Web サイト内で重複しないようにすること
• 画像には適切な代替テキストを付与する。代替テキストは、画像の内容を具体的に示すものとする（下記サンプル 1）
• 文字間隔の調整を空白文字を用いて行ってはならない
• 英単語をすべて大文字で記述することは避けること。text-transform: uppercase; などを適切に使用すること。
• 略称にはなるべく正式名称を abbr 要素を用いて付与する（下記サンプル 2）。
• 背景色と文字色には適切なコントラスト比を持たせる。
• ブラウザによる文字サイズの変更が可能なように実装すること。また、10px 以下のサイズの文字は重要でない注釈等を除いて原則として使用しないことが望ましい。
• 文字サイズ変更ボタンを Web ページ側で独自に提供しないこと（ブラウザの UI に任せる）。
• JavaScript が無効な環境を常に配慮すること。アコーディオンメニューなど、JavaScript によって開閉するような UI については、JavaScript が無効だった場合には開いた状態になるなど、重要な操作が JavaScript の無効によって不可能になるような実装は行わない。
• リンクアンカーとなるテキストは適切に選択すること。アンカーテキストに制約がある場合は、title 属性を併用すること（下記サンプル 3）。
• リンク領域、ボタンのサイズ等は適切なサイズを考慮すること。また、各リンクのマージンは適切にとり、誤クリックを誘発するような実装は行わないこと。
• PDF ファイルなど、HTML 以外のフォーマットへのリンクを提供する場合は、そのリンク先のフォーマットやファイルサイズがわかるようにしておくことが望ましい。
• フォームコントロールは、label 要素を適切に用いてラベルとの関連づけを行うこと。
• キーボードによる操作を考慮した実装を行うこと。

<!-- サンプル 1 -->
<img
  src="photo.jpg"
  alt="熱海に行ったときに撮影した写真。海をバックに白壁の民家とペットの黒猫が写っています。"
/>

<!-- サンプル 2 -->
<p>
  <abbr title="World Wide Web Consortium">W3C</abbr> は World Wide Web で使用される各種技術の標準化を推進する為に設立された標準化団体です。
</p>

<!-- サンプル 3 非推奨 -->
資料のダウンロードは<a href="/dl/">こちら</a>から

<!-- サンプル 3 推奨 -->
<a href="/dl/">資料のダウンロードはこちらから</a>

また、ある要素（例えばナビゲーションなど）の位置固定表示（e.g. position: fixed;）を行う場合は、画面サイズが小さいときなどに画面外に要素がはみ出して閲覧できなくなるなどの可能性を十分に配慮する。

文書型宣言

新規に作成する HTML 文書は、特別な指定がある場合を除いて HTML Living Standard を使用すること。文書型宣言は <!DOCTYPE html> と記述。大文字小文字も左記の通りとする。

MIME Type は text/html を指定すること。特別な指定がある場合を除いて、XHTML（application/xhtml+xml）は使用しないこと。

HTML は記述統一の観点から下記のルールに則って記述すること。

• 閉じタグは省略しないこと
• 空要素は必ず閉じること。<br> → <br />
• 属性値は必ず " " で囲むこと
• 論理属性は属性名のみで記述すること。<input type="checkbox" checked="checked" /> → <input type="checkbox" checked />
• URL 内やテキストノード内の & は & と文字参照で記述すること

ただし、静的サイトジェネレーターなど、フレームワークを使用した場合に空要素が閉じられないなど、フレームワーク側のデフォルト設定、あるいは仕様により避けられない場合は問題ない。一方でページによって記述方法にばらつきが出るようなことはないように注意すること。

要素や終了タグの省略

HTML における省略可能な要素、あるいは終了タグの省略は原則として行わないこと。

<!-- 非推奨 -->
<title>example page</title>
<article>
  <h1>Example 1
  <p>This is example page.

<!-- 推奨 -->
<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>example page</title>
  </head>
  <body>
    <article>
      <h1>Example 1</h1>
      <p>This is example page.</p>
    </article>
  </body>
</html>

本セクションにおける「省略可能な要素」とは、ある要素のコンテンツモデル上は必須だが、条件を満たすことで記述を省略することができるとされている要素（html 要素、head 要素、body 要素）がその対象となる。記述が任意の要素、例えば table 要素内における thead 要素、tbody 要素などはこの限りではない。

なお、要素に関わらず、終了タグの省略は禁止する。

参考リンク（省略可能な要素）

• 13.1.2.4 Optional tags - HTML Standard

セマンティクス

要素の意味と異なる動作を与えたりしないこと。例えば div 要素や p 要素をクリックすることでリンクとして機能させたりといったことは行わない。リンクを設定したい場合は a 要素を使用すること。

<!-- 非推奨 -->
<div onclick="allEntries();">すべての記事一覧へ</div>

<!-- 推奨 -->
<a href="/all/">すべての記事一覧へ</a>

また、class 名や id 名を要素に付与する際も命名規則にはセマンティクスを意識すること。

<!-- 非推奨 -->
<span class="red">注意してください</span>

<!-- 推奨 -->
<span class="elm-caution">注意してください</span>

class 名や id 名の命名規則に関して詳しくはセレクタの命名規則セクションを参照。

CSS や JavaScript ファイルの読み込み

CSS を外部ファイルとして読み込む場合、パフォーマンスを考慮して 1ファイルにまとめること（ビルドツールを使用する場合はバンドル処理に任せてよい）。また、link 要素に対する media 属性の使用は原則として行わず、CSS ファイル内に @media 規則を用いて記述すること。また、原則として CSS ファイル内での @import 規則の使用、および HTML 文書内でのインライン・スタイルの記述は禁止する。

JavaScript の読み込みは、defer 属性を付与した上で head 要素内に記述することを推奨する。defer 属性により、スクリプトのダウンロードは HTML 解析と並行して行われ、実行は DOM の構築完了後となるためレンダリングブロックを回避できる。なお、Google タグマネージャが使用できる場合は、導入することが望ましい。

<!-- 非推奨 -->
<link rel="stylesheet" href="base.css" media="screen" />
<link rel="stylesheet" href="grid.css" media="screen" />
<link rel="stylesheet" href="print.css" media="print" />

<!-- 推奨 -->
<link rel="stylesheet" href="style.css" />

<!-- 非推奨：defer なしで head に記述するとレンダリングブロックが発生する -->
<head>
  <script src="plugin.js"></script>
  <script src="function.js"></script>
</head>

<!-- 推奨：head 内に defer 付きで記述する -->
<head>
  <script src="plugin.js" defer></script>
  <script src="function.js" defer></script>
</head>

ただし、async 属性、defer 属性はスクリプトの依存関係等によって正常に動作しなくなる場合があるため、スクリプトの動作を優先してよい。

パフォーマンスのセクションもあわせて参照のこと。

type 属性

link 要素による CSS の読み込み時や、script 要素に対して type 属性は付与せず省略する。

<!-- 非推奨 -->
<link rel="stylesheet" href="style.css" type="text/css" />

<!-- 推奨 -->
<link rel="stylesheet" href="style.css" />

<!-- 非推奨 -->
<script src="https://example.com/library.min.js" type="text/javascript"></script>

<!-- 推奨 -->
<script src="https://example.com/library.min.js"></script>

構造化データ

HTML 文書に対する構造化データの付与は、JSON-LD を推奨する（Microdata、RDFa Lite も可）。語彙は schema.org を原則として使用すること。ただし、構造化データの付与自体は必須ではない。

構造化データのテストには、Google の リッチリザルト テスト を推奨する。

メタデータや OGP

メタデータ

<meta name="description" /> に関しては、主要なページでは設定しておく事。その際、重複が発生しないように注意。主要でないページで description が重複するくらいであれば最初から記述しない事。

<meta name="keywords" /> に関しては記述不要。

OGP

トップページに関しては原則として OGP の記述を入れておく事。その他、商品ページなど重要なページに関してはクライアントとの取り決め、もしくはディレクター、実装担当者の判断で記述する。下記に標準的な OGP 設定のサンプルを示す。

<!-- トップページへの記述例 -->
<meta property="og:title" content="サイト名" />
<meta property="og:url" content="https://example.com/" />
<meta property="og:description" content="サイトの説明" />
<meta property="og:image" content="https://example.com/img/1200x630.png" />
<meta property="og:type" content="website" />

<!-- 個別ページ（商品ページやニュース記事）への記述例 -->
<meta property="og:title" content="記事タイトル" />
<meta property="og:url" content="https://example.com/article/1/" />
<meta property="og:site_name" content="サイト名" />
<meta property="og:description" content="記事の説明" />
<meta property="og:image" content="https://example.com/img/article/1200x630.png" />
<meta property="og:type" content="article" />

条件付きコメント

条件付きコメントの使用は禁止する。

<!-- 非推奨 -->
<!--[if IE 8]>
 ...
<![endif]-->

ページ上部へのアンカーリンク

ページ上部に移動するためのページ内リンク（所謂アンカーリンク）として使用する a 要素の href 属性値には #top を指定すること。HTML Living Standard においては、#top を指定することで自動的にページ上部へのリンクとして機能する。

<a href="#top">このページの上部へ</a>

SVG

スクリプトを伴わない SVG データに関しては img 要素での埋め込みを推奨する。

CSS によるスタイル制御やアニメーション、スクリプトとの連携が必要な場合はインライン SVG（文書内への <svg> 要素の直接記述）を推奨する。アイコンの再利用には <use> 要素を使ったスプライトが有効。なお、<object> 要素や <iframe> による SVG の埋め込みは現代では使用しないこと。

基本・バリデーション

基本的な考え方

CSS はメンテナンス性と再利用性を考慮すること。各ブロックのモジュール化を意識し、HTML の記述と合わせて、あるブロックを他のページにそのまま移動したり、同一ブロック内で要素が多少変更されたとしても（ul 要素 → ol 要素や段落の追加など）、レイアウトや見た目が変化しないように考慮し、モジュールの使い回しを容易にすること。

セレクタによる詳細度を極力高くしないように心がけ、単一セレクタによる記述を基本とする。また、要素セレクタの使用はなるべく避け、HTML 側の変更によって CSS の変更まで行わなければならなくなる事態を極力避けるよう配慮すること。

/* 非推奨 */
.block-header ul.block-main-nav li a {...}

/* 推奨 */
.block-main-nav a {...}

フォーマット

• CSS は宣言ブロック部分に必ずインデントを入れること。
• セレクタと ”{” の間には半角スペースを 1つ入れる。さらに、プロパティと ”:” は続けて記述し、その後ろに半角スペースを 1つ入れた上で、値を記述する。
• すべての宣言ブロック末尾には ”;” を付与すること。
• 規則集合ごとに 1行改行を入れて記述する。
• 複数のセレクタをカンマ区切りで記述する場合は、セレクタごとに改行する。
• プリプロセッサやビルドツールによる最終納品物からの改行やインデント等の自動削除は問題ない。

/* 非推奨 */
.example {
color:red;
margin:0
}
.sample{color:red;margin:0}

/* 推奨 */
.example {
  color: red;
}

.sample {
  ...
}

/* 非推奨 */
h1,h2,h3 {
  font-weight: normal;
  line-height: 1.2;
}

/* 推奨 */
h1,
h2,
h3 {
  font-weight: normal;
  line-height: 1.2;
}

バリデーション

W3C CSS 検証サービスによるバリデーションを行うこと。特にスペルミスや記述ミスは確実にチェックし、排除すること。なお、プリプロセッサやビルドツールを用いたバリデーション、あるいはエディタの機能として提供されている機能（Stylelint 等）を利用したバリデーションでも構わない。

デフォルトスタイルシートのノーマライズ

デフォルトスタイルシートのノーマライズには、下記の選択肢から適切なものを使用する。リセット CSS の使用は非推奨とする。

• modern-normalize — 軽量で現代的なブラウザ向けのノーマライズ
• Normalize.css — 従来の実績あるノーマライズ
• Tailwind CSS の Preflight（Tailwind CSS を使用する場合）

セレクタの命名規則

セレクタとなる class 属性名、id 属性名は、セマンティクスを意識した命名規則を用いること。また、キャメルケースは用いず、”-“（ハイフン）による連結を原則とする。

/* 非推奨 */
.blockHeader {...}
.mainNavigation {...}

.red {...}
.h1 {...}

また、レイアウト、モジュール、テキストへの意味づけ等、用途別に先頭文字列を分類するなど、class 名や id 名からセレクタの用途がある程度推測できるなどが望ましい。セレクタの命名規則に関しては、下記を基準とする。

layout- : Web ページ内のレイアウトに用いられる要素には layout- から始まる class 名を使用する。

block- : 各ページに共通の要素ブロックなどは block- から始まる class 名を使用する。原則として layout- の子要素のみに使用する。

module- : block- 内でそのまま他の場所に抜き出しても意味が通じる程度のまとまりとなった要素ブロックに付ける。原則として block- の子要素のみに使用する。

elm- : module- 内で単一の要素にスタイルを当てるために使用する class 名は elm- から始める。原則として module- の子要素のみに使用する。

状態の変化 : block- や module-、elm- がスクリプトなどによって変化した状態を示すマークアップは、WAI-ARIA / state を利用することが望ましい。ただし、WAI-ARIA / state では語彙が足りない場合（active など）に関しては state- から始まる class 名を使用する。

/* 推奨 */
.layout-main-content {...}
.layout-sub-content {...}

.block-header {...}
.block-main-nav {...}
.block-section {...}

.module-section-header {...}
.module-page-title {...}

.elm-pub-time {...}
.elm-caution {...}

<!-- 推奨 -->
<ul class="module-sub-menu" aria-expanded="true">
  <li class="state-active">
  ...

/* 推奨 */
.module-sub-menu[aria-expanded="true"] {...}
.state-active {...}

なお、Tailwind CSS や CSS Modules などのユーティリティファースト・スコープベースの手法を採用する場合は、本命名規則に縛られず、各手法の推奨規則に従うこと。

ショートハンド

極力ショートハンドプロパティを使用する。

/* 非推奨 */
font-family: "Hiragino Kaku Gothic ProN", Sans-Serif;
font-size: 100%;
font-style: normal;
font-weight: bold;
line-height: 1.6;
margin-bottom: 1em;
margin-left: 1em;
margin-right: 1em;
margin-top: 1em;
padding-bottom: 2em;
padding-left: 1em;
padding-right: 1em;
padding-top: 0;

/* 推奨 */
font: normal bold 100%/1.6 "Hiragino Kaku Gothic ProN", Sans-Serif;
margin: 1em;
padding: 0 1em 2em;

ただし、font 関連プロパティのショートハンドに関しては、記述順などが煩雑なことや、スタイルの継承が複雑になる場合もあるため、メンテナンス性や記述ミスのリスクを考慮して、無理に使用する必要はない。body 要素に対しての指定のみにとどめるなど、実装時に判断する。

@media 規則

HTML ガイドラインにて、link 要素に対する media 属性の使用は原則として禁止しているため、メディアクエリに関しては CSS ファイル内での @media 規則のみ許可する。

ただし、プリント用 CSS を記述する場合は、CSS ファイルの末尾に記述すること。また、原則として CSS ファイル内での @import 規則の使用は禁止する。

単位などの省略

値が 0 となるプロパティに関しては、単位を省略して記述すること。

margin: 0;
padding: 0;

また、line-height プロパティの値も原則として単位を省略して記述すること。

line-height: 1.5;

値が 0 以下の数値となる場合、0 は省略して記述すること。

opacity: .8;
font-size: .875em;

リンクの文字色

リンクの文字色は、:link、:visited、:hover それぞれに必ず異なる文字色を設定すること。

a {
  color: #52a437;
  text-decoration: none;
}

a:visited {
  color: #428bca;
}

a:hover {
  color: #fc4f00;
  text-decoration: underline;
}

a:active {
  color: #fc4f00;
}

リンクの下線はデザイン要件により非表示にしてもよいが、本文内など、通常のテキストとリンクテキストが混在する部分では、下線やアイコンを付与するなどして通常のテキストとの差異を明確にし、リンクがわかりやすいように配慮すること。

font-family の指定

font-family プロパティの指定は下記を標準とする。

body {
  font-family: system-ui, "Helvetica Neue", Arial, "Hiragino Kaku Gothic ProN",
               "Hiragino Sans", "BIZ UDPGothic", Meiryo, sans-serif;
}

ビルドツールや CSS フレームワーク（Tailwind CSS など）を使用する場合は、各ツールの設定ファイルでフォントスタックを定義すること。

z-index の値

z-index プロパティの値は下記の範囲、及びルールに従い指定する。

• 使用可能な数値の範囲：0〜5000 まで、10 刻み を基本とする。
  • 10 刻みとする理由はメンテナンス等でどうしても既存要素の中間となる値を指定しないといけなくなった場合に備えて。
• スタート数値はある要素群の役割ごとに変えてもよい。例えばロールオーバーする要素は 1000 番台から始めるなど。
• オーバーレイなど、確実に他の要素より上部に表示されないと困る要素群に対しては 4000 以上の値を指定する。
• 大規模サイトで上記ルールでは数値が足りなそうなことが想定される場合はこの限りではない。

Web フォントやアイコンの利用

Web フォントやアイコンフォントの利用は可能。アイコンについては、SVG アイコン（インライン SVG またはスプライト）の利用を推奨する。アイコンフォントを利用する場合は Font Awesome 6.x などを推奨する。

第三者が提供するフォントを使用する場合は、ライセンスのセクションも確認すること。

モダン CSS プロパティ

現代の CSS で追加された新しいプロパティは積極的に利用して構わない。当社が定めた動作検証ブラウザでサポートされているプロパティは原則として使用可能。

下記はよく利用されるモダン CSS の例。

• border-radius、text-shadow、box-shadow、linear-gradient — 広くサポートされており問題なく使用可能。
• CSS カスタムプロパティ（変数）：--color-primary: #333; — テーマ管理やコンポーネント設計に積極的に活用すること。
• CSS Grid / Flexbox — レイアウトには積極的に使用すること。
• clamp()、min()、max() — レスポンシブなサイズ指定に有効。
• :is()、:where()、:has() — セレクタの簡潔化に活用できる。
• @container（コンテナクエリ）— ビューポートではなく親要素の幅に基づいてスタイルを切り替えられる。コンポーネント単位のレスポンシブデザインに活用できる。
• @layer（カスケードレイヤー）— スタイルの優先順位をレイヤー単位で明示的に制御できる。サードパーティ CSS との詳細度の競合を防ぐのに有効。

サポート対象ブラウザでサポートされていないプロパティを使用することで、閲覧に支障が出るほどレイアウトが大きく崩れたり、アクセシビリティを損ねるような状態になることが予想される場合には、フォールバックを用意すること。

CSSハック

CSS ハックは原則として使用しないこと。やむを得ない場合のみ使用できるが、CSS ファイル内の末尾などにまとめて記述し、標準的なスタイルの記述と混ぜないこと。

中間制作物

ビルドツールやプリプロセッサを使用する場合、最終納品物（Web サイトで読み込まれる CSS ファイル）と、実際に編集している Sass ファイル等の間に、改行、コメントを残し、1ファイルにまとめた CSS ファイルを中間制作物として必ず出力するようにすること。CSS によるコードレビューが必要な場合などに配慮して。

通常は、中間制作物となる CSS ファイルからコメント、改行等を取り除いた（Minify した）ものが最終納品物となる。

基本・バリデーション

基本的な考え方

操作、および情報の取得に影響する部分については、常に JavaScript が無効な環境を考慮すること。それらに影響のない、装飾的な部分に関してはその限りではない。

Web サイトのパフォーマンスを重視し、本質的でない不要な処理を入れないこと。また、モダンブラウザが標準で提供する Web API（fetch、IntersectionObserver、ResizeObserver、querySelectorAll 等）を積極的に活用し、外部ライブラリへの依存を最小化すること。

TypeScript の使用を推奨する。型安全なコードはバグの早期発見とメンテナンス性の向上に貢献する。

バリデーション・静的解析

ESLint を使用した静的解析を推奨する。TypeScript を使用する場合は @typescript-eslint プラグインを合わせて導入すること。

ESLint の設定例（eslint.config.js）：

import js from '@eslint/js';
import tseslint from 'typescript-eslint';

export default tseslint.config(
  js.configs.recommended,
  ...tseslint.configs.recommended,
);

シングルクォーテーションとダブルクォーテーション

統一感の問題から、シングルクォーテーションを基本とする。ただし、TypeScript / モダン JavaScript ではテンプレートリテラル（バッククォート）の積極的な活用を推奨する。

const message = 'Hello, World!';
const greeting = `Hello, ${name}!`;

セミコロン

セミコロンの省略は行わないこと。JavaScript ではセミコロンの省略が許されるが、セミコロンの挿入を処理系に任せた結果、自動補完が意図せず行われたり、または行われないことでエラーが発生し、デバッグが困難になる等の問題が想定されるため。

変数 / 関数の命名規則

変数名 / 関数名は原則として、キャメルケースを使用する。変数名 / 関数名における「$」は使用禁止。

変数の宣言には const を基本とし、再代入が必要な場合のみ let を使用すること。var は使用禁止。

const firstName = 'taro';

function getListElement() {
  // ...
}

アロー関数を積極的に使用すること。

const getListElement = () => {
  // ...
};

コンストラクタ関数 / クラス

コンストラクタ関数やクラス名の先頭は大文字とする。

class Person {
  constructor(name, age) {
    this.name = name;
    this.age = age;
  }
}

const taro = new Person('taro', 32);

定数

定数はすべて大文字で記述し、単語間をアンダースコア（_）で接続する。

const API_KEY = 'b6lC50HCr4mA';

ブロックの中での関数宣言

ブロック内での関数宣言は、実行環境によって挙動が一致しない場合があり、可読性も低下するため推奨しない。

// 非推奨
if (x) {
  function foo() {}
}

ブロック内で関数を定義したい場合は、関数式（またはアロー関数）を使用する。

// 推奨
if (x) {
  const foo = () => {};
}

jQuery

jQuery の使用は原則として推奨しない。モダンブラウザの Web API を使えばほとんどの処理をバニラ JavaScript で実現できる。新規プロジェクトでは jQuery を導入しないことを基本とする。

ただし、下記の場合は使用を検討してよい。

• 既存プロジェクトで jQuery が使われており、追加の依存関係となることが許容される場合
• クライアントの要件により特定の jQuery プラグインの使用が求められる場合

要件により使用する場合は 3.x 系の最新版を使用すること。

プラグイン

jQuery プラグインの利用に特に制限はないが、メンテナンスが継続されていること、軽量であることを重視して選択すること。また動作検証ブラウザにおいてプラグインを使用しなくても実装可能な方法があればそちらを優先すること。

プラグインの動作を理由に読み込む jQuery のバージョンを下げることは禁止する。最新の jQuery で動作しないプラグインは利用不可。

また、使用したライブラリは一覧できるように別途ドキュメントに記載すること。

プロダクトの選定

使用するプロダクトはサポート体制、および開発元が定めるプロダクトライフサイクルポリシー（主に旧製品のメンテナンス継続期間や後方互換性の確保に関するポリシー）を考慮する。

オープンソースプロダクトは、クライアントが保守対応可能な部署、人材を自社で持つ場合は問題ないが、そうでない場合はサポートの提供方法について事前に十分配慮する。

「無料」であることを理由にオープンソースプロダクトを選択するようなことはしない。クライアントに対してはプロダクトのサポート体制やプロダクトライフサイクルポリシーについて説明を怠らない。

上記を踏まえ、当社では原則として SixApart 社の Movable Type、およびその関連プロダクトを選択肢の第一候補とするが、プロダクト選定はクライアントの要件、ビジネスゴールの達成に対してそのプロダクトが最適であるかが前提となる。

なお、コンテンツの配信要件によってはヘッドレス CMS（例： microCMS、Strapi など）の採用も選択肢として検討すること。

Movable Type

Movable Type、およびその関連製品として案件で利用を推奨するプロダクトは下記の通り。

• 通常版ライセンス
  • Movable Type（ソフトウェア版）
• エンタープライズ向けライセンス
  • Movable Type Advanced
  • PowerCMS
• SaaS
  • Movable Type クラウド版
  • MovableType.net

プラグイン

Movable Type や WordPress など CMS のプラグイン利用に特に制限はないが、メンテナンスが継続されていること、脆弱性など、不具合への対応が適切に行われていることを重視して選択すること。

プラグインの動作を理由に CMS のバージョンを下げること、あるいは CMS 本体のプログラムの改変を行うことは禁止する。最新のバージョンで動作しないプラグインは利用不可。

また、使用したプラグインは一覧できるように別途ドキュメントに記載すること。

基本

Web サイト、及び Web アプリケーションの実装にあたって参考とすべき外部のガイドラインとしては、IPA 独立行政法人 情報処理推進機構が公開する、「安全なウェブサイトの作り方（改訂第 7 版）」を参考とすること。

• 安全なウェブサイトの作り方：IPA 独立行政法人 情報処理推進機構

また、納品物として Web アプリケーションのセキュリティ実装の実施状況を確認する必要がある場合は、同ガイドライン付属の「セキュリティ実装 チェックリスト」を利用、あるいは参考の上、クライアントの要望に応じたチェックリストを作成する。

強固なパスワード

CMS インストール時のアカウント設定など、新規でアカウントを設定する際は推測されにくいアカウント名、および強固なパスワードを設定すること。

パスワードは 32 桁以上が望ましいが、状況に応じて 16 桁以上であれば許容する。必ず英数字を混在させ、数字だけのパスワードや英単語によるパスワードは禁止する。また、同一のパスワードを複数のサービスやアカウントで使い回すことも禁止。

上記は、クライアントの要望によらず厳守すること。

推測されやすいアカウント名の例

• admin
• root

改善案

• example-admin（“example” 部分はクライアントに応じて変えるなど）

不適切なパスワードの例

• 12345（数字のみ / 桁数も不足）
• companyname（社名そのままなど）
• 0312345678（電話番号など外部からわかりやすいもの）

強固なパスワードの例

• yrQpjO9BI4gx84a@

管理画面のパスワード保護

サーバに設置した管理画面をもつプログラムへのログインページは、可能な限りパスワードによって保護する。ベーシック認証を用いる場合は、必ず HTTPS 上で運用すること（HTTP 上のベーシック認証では認証情報が Base64 エンコードされるのみで実質的に平文送信となるため禁止）。また、ブルートフォース攻撃対策として IP アドレスによるアクセス制限と組み合わせることを強く推奨する。

例として、管理画面にベーシック認証を設定する場合は、下記のような .htaccess の記述が考えられる。

<Files mt.cgi>
  AuthUserFile /var/www/html/.htpasswd
  AuthName "Please enter your ID and password"
  AuthType Basic
  Require valid-user
</Files>

ディレクトリ単位で認証をかけても問題ない場合は、そのように対処する。

SSL の利用

問い合わせフォームなど、個人情報を伴うデータをブラウザ・サーバ間で受け渡すプログラムに関してはその通信を SSL（TLS）で保護する。サーバへの SSL 導入をクライアントに提案し、暗号化されていない状態でのデータ送信は原則として行わないこと。

SSL を使用する場合、レンタルサーバ業者が提供するような所謂共有 SSL の利用は原則として不可。

SSL サーバ証明書を発行する際に申請する証明書の公開鍵暗号は 2048bit RSA 以上（推奨は ECDSA P-256 または P-384）、ハッシュ関数は SHA-2 を基準として選択する。また暗号化強度は 128bit 以上の信頼できる認証局発行 SSL 証明書を利用する。推奨する認証局は下記の通り。

• Let’s Encrypt
• セコムトラストシステムズ（セコムパスポート）
• GMO グローバルサイン
• ジオトラスト

HTTP Strict Transport Security（HSTS）

HTTPS 運用が確定しているサイトでは、Strict-Transport-Security レスポンスヘッダを設定し、ブラウザに HTTPS 接続を強制することを推奨する。

# Apache（.htaccess）での設定例
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

max-age は最低でも 1 年（31536000 秒）を推奨する。設定前に、サイト内のすべてのリソース（画像・スクリプト等）が HTTPS で提供されていることを確認すること。

Content Security Policy

Content Security Policy（CSP）は、XSS 攻撃などを緩和するための重要なセキュリティ機能である。特に個人情報を扱うフォームや管理画面を持つ Web サイトでは、CSP の設定を検討すること。

CSP は HTTP レスポンスヘッダ（Content-Security-Policy）またはメタタグで設定できる。

<!-- メタタグによる設定例 -->
<meta http-equiv="Content-Security-Policy"
      content="default-src 'self'; script-src 'self' https://trusted.example.com;" />

CSP の設定は Web サイトの構成によって大きく異なるため、まずは Content-Security-Policy-Report-Only ヘッダを使ってレポートのみ行い、影響を確認してから実際のポリシーを設定する方法を推奨する。

FTP

サーバへのファイル転送に関して、FTP の使用は禁止する。SFTP（SSH File Transfer Protocol）、もしくは FTPS（File Transfer Protocol over SSL/TLS）を利用し、FTP クライアントに関しては、これらに対応していないものの使用は禁止。

SFTP/FTPS 対応クライアントとして、Windows 環境であれば、WinSCP の利用を推奨。macOS では Cyberduck 等を利用すること。

Movable Type

Movable Type プログラムは、下記の通り主要な実行ファイルのリネーム、および設定ファイルへの追記を行うこと。リネームのルールは別途定めているため下記は参考。

• mt.cgi → mt-example.cgi
• mt-upgrade.cgi → mt-upgrade-example.cgi
• mt-data-api.cgi → mt-data-api-example.cgi
• mt-check.cgi → mt-check-example.cgi

#mt-config.cgiに追記
AdminScript mt-example.cgi
UpgradeScript mt-upgrade-example.cgi
DataAPIScript mt-data-api-example.cgi
CheckScript mt-check-example.cgi

また、Web サイトの構築に不要な機能に関しては .cgi ファイルの実行権限を削除してもよい。

基本

Web ページの表示速度、反応速度に関して、フロントエンド側で対応できる部分に関しては可能な限り配慮すること。

HTML 側での配慮

HTML での配慮については、CSS や JavaScript ファイルの読み込みのセクションを参照のこと。

パフォーマンスチェック

PageSpeed Insights によるパフォーマンスチェックを必須とする。目安は PC で 85 点以上、モバイルで 75 点以上。

ただしこれを下回った場合でも、すでにやるべきことができているのであれば問題はない。特にスマートフォン向けに最適化されていないサイトのモバイル項目の数値は低く出るので、実機テストにおいて著しく操作性が低いといった問題がない場合は不問。

Core Web Vitals

Google が定める Core Web Vitals はユーザー体験を測定する重要な指標であり、SEO にも影響する。下記 3 指標の改善を目標とすること。

指標	意味	目標値
LCP（Largest Contentful Paint）	最大コンテンツの描画時間	2.5 秒以下
INP（Interaction to Next Paint）	インタラクションの応答性	200 ミリ秒以下
CLS（Cumulative Layout Shift）	累積レイアウトシフト	0.1 以下

LCP 改善のポイント

• ヒーロー画像などに fetchpriority="high" を付与する
• <link rel="preload"> でクリティカルリソースを先読みする
• 画像の最適化（WebP / AVIF 形式、適切なサイズ）
• サーバ応答時間の短縮

CLS 改善のポイント

• 画像や動画には width / height 属性を必ず指定する
• 広告や動的コンテンツの埋め込みに十分なスペースを確保する
• Web フォントの読み込みには font-display: swap を使用する

INP 改善のポイント

• JavaScript の長時間実行タスクを分割する
• 不要な JavaScript の読み込みを排除する
• イベントハンドラの処理を軽量化する

画像の最適化

画像は用途に応じて適切なフォーマットを選択すること。

• 写真・複雑な画像：WebP または AVIF 形式を推奨（JPEG はフォールバック用）
• ロゴ・アイコン・図版：SVG を推奨
• シンプルなグラフィック：PNG（8ビットカラー / アルファチャンネル可）

ブラウザが対応している場合は WebP や AVIF を使用し、<picture> 要素で対応を確認してから配信すること。

<picture>
  <source srcset="image.avif" type="image/avif" />
  <source srcset="image.webp" type="image/webp" />
  <img src="image.jpg" alt="説明" width="800" height="600" />
</picture>

画像圧縮ツール

• Squoosh — ブラウザ上で様々な形式に変換・圧縮可能
• TinyPNG — PNG / JPEG の圧縮
• SVGOMG — SVG の最適化

ビルドツールを使用する場合は sharp、imagemin 等のプラグインで自動最適化すること。

Retina 対応

JPEG / PNG 画像の Retina 対応については、表示サイズの 2 倍サイズで画像を用意した上で、WebP で高圧縮することで見た目とファイルサイズのバランスが最もよい場合がある。

CSS の最適化

CSS は必ず 1 ファイルにまとめ、CSS ファイル内での @import 規則は使用しないこと（ビルドツールのバンドル処理に任せる場合を除く）。また、セレクタは簡略に記述し、スタイルの上書きが頻繁に行われないように配慮することでパフォーマンスは向上する。

Sass 等を使用する場合は、ネストが深くなりすぎないように注意。またはメディアクエリが複数の場所に分散したりしないように配慮すること。また、実際にページで読み込まれる CSS は必ず Minify すること。

また、メンテナンス等により、使われていないスタイル宣言が大量に残ったままになるなど、ファイルサイズを無駄に肥大化させる記述は、ツール（PurgeCSS 等）などを用いてなるべく早期に排除するよう心がける。

JavaScript の最適化

複数の JavaScript ファイルを使用する場合は、なるべく 1 ファイルにまとめること（ビルドツールのバンドル処理に任せてよい）。実際に読み込まれる JavaScript は必ず Minify し、ファイルサイズを最適化すること。

Google Analytics のトラッキングコード、各 SNS のシェアボタン系コードなどは、必ず最新のコードを使用すること。また、CSS や JavaScript ファイルの読み込みのセクションを参照し、defer 属性を可能な限り使用する。

Google タグマネージャ

可能な限り、Google タグマネージャの利用を推奨する。Google Analytics のトラッキングコードも Google タグマネージャから配信すれば個別にコードをページに入れる必要はない。

コード分割

モダンなビルドツール（Vite 等）を使用する場合は、dynamic import によるコード分割を活用し、初期読み込みを最小化すること。

// 必要な時だけ読み込む
const module = await import('./heavy-module.js');

サーバサイドでの設定

下記の設定がサーバ側で可能な場合はできる限り行うこと。

圧縮転送

gzip または Brotli による圧縮転送を有効にすること。Apache の場合は mod_deflate / mod_brotli が有効であれば .htaccess に下記の記述で有効にできる。

<ifModule mod_deflate.c>
  SetOutputFilter DEFLATE
  SetEnvIfNoCase Request_URI \.(?:gif|jpe?g|png|ico|webp|avif)$ no-gzip dont-vary
</ifModule>

キャッシュ設定

画像など、一度公開されれば変更される可能性が低いファイルはキャッシュを長めに設定する。

<ifModule mod_expires.c>
  ExpiresActive On
  <Files ~ "\.(gif|jpg|jpeg|png|webp|avif|ico|svg)$">
    ExpiresDefault "access 1 year"
  </Files>
  ExpiresByType text/css "access 1 month"
  ExpiresByType text/javascript "access 1 month"
  ExpiresByType application/javascript "access 1 month"
  ExpiresByType font/ttf "access 1 year"
  ExpiresByType font/woff2 "access 1 year"
</ifModule>

HTTP/2 以降

サーバ側で HTTP/2 または HTTP/3 の利用が可能であれば利用する。CDN（Content Delivery Network）の利用など、サードパーティのサービスを利用する場合はクライアントと協議の上決定すること。

リソースの先読み

チュートリアルなど、連続して次のページを読んでいくようなコンテンツの場合、あるいは、ほぼ次に移動する静的なページが決まっているような場合は、Link prefetching の利用が効果的な場合がある。

<link rel="prefetch" href="step-2.html" />

なお、rel="prerender" はモダンブラウザでは廃止されており使用しないこと。代替として Speculation Rules API が利用可能。次に移動する可能性が高いページを JSON 形式で宣言的に指定することで、ブラウザがバックグラウンドでページのプリレンダリングを行う。

<script type="speculationrules">
{
  "prerender": [
    {
      "urls": ["step-2.html"]
    }
  ]
}
</script>

詳細は下記を参照。

• rel=prefetch：MDN Web Docs
• Speculation Rules API によるページのプリレンダリング：Chrome Developers

基本

ChatGPT、Claude、Gemini をはじめとする AI サービス、および AI エージェントを業務に活用する場合は、情報漏洩リスクや法令上の問題を踏まえた適切な利用を行うこと。

利用可能なサービス・プランの基準

業務で AI サービスを利用する際は、入力したデータがモデルの学習に使用されないプランまたは設定であることを必ず確認すること。無料プランや一部のプランでは、入力内容がサービス改善・学習データとして利用される場合があり、業務上の情報を入力することは情報漏洩につながるリスクがある。

利用前に確認すべき主な事項は以下のとおり。

• 入力データが学習に利用されない設定・プランであるか（オプトアウト設定の確認を含む）
• データが第三者に共有・開示されないか
• データの保存期間および削除ポリシー
• 利用規約・プライバシーポリシーが業務利用を許可しているか

代表的なサービスのビジネス向けプランや API 利用（Enterprise プランなど）では、入力データを学習に使用しない旨が明示されていることが多い。不明な場合はサービスのプライバシーポリシーおよびサポートページで確認すること。

なお、当社で法人契約済みの AI サービスとプランは以下の通りである。

• ChatGPT Business （OpenAI 社）
• Claude Team （Anthropic 社）
• Google Workspace with Gemini / NotebookLM （Google 社）

また、上記契約に基づき利用可能な AI エージェントは以下の通りである。

• OpenAI Codex
• Claude Code

当社従業員は上記 AI サービス、および AI エージェントのみ使用し、個人で契約した AI サービスを業務において使用しないこと。

AI エージェントの利用

コードの自動生成・実行、ファイルの読み書き、外部サービスとの連携など、複数のツールを組み合わせて自律的にタスクを実行する AI エージェントを利用する場合は、以下の点に特に注意すること。

• エージェントに付与する権限は必要最小限にとどめる
• 実行内容のログを残し、予期しない操作が行われていないか確認する
• 本番環境への直接アクセス権限を与えないこと
• コードの自動コミット・デプロイなど不可逆な操作は人間がレビューしてから実行する
• 安全性の確認できていないリポジトリに対して不用意に AI エージェントを起動したりしないこと

AIへの機密情報入力の禁止

業務で AI サービスを使用する際、下記に該当する情報を入力することを原則として禁止する。

入力してはいけない情報の例

クライアント・プロジェクト関連

• クライアントの社名、担当者名、連絡先
• 契約内容、見積・請求金額
• 公開前のプロジェクト情報（デザイン案、機能仕様、リリース日程など）
• クライアントから提供された素材・データ（画像、テキスト、データベースの内容など）
• 未公開の商品・サービス情報

認証・アクセス情報

• パスワード、APIキー、アクセストークン
• 秘密鍵・証明書
• サーバーの接続情報（IPアドレス、ホスト名、ポート番号など）

個人情報

• 氏名・住所・電話番号・メールアドレスなど個人を特定できる情報（PII）
• マイナンバーをはじめとする各種番号・識別子
• 健康・医療情報

自社内部情報

• 財務情報・売上データ
• 従業員の個人情報・評価内容
• 社外秘と指定された資料・データ

情報を入力する前の確認

プロンプトに実際のデータを含める前に、ダミーデータや匿名化された情報に置き換えられないかを検討する。コードのデバッグや文書の校正などは、機密部分を伏せた形でも AI に依頼できる場合が多い。

著作権・法令上の注意点

AI が生成したコンテンツ（テキスト、画像、コードなど）を業務成果物として使用する際は、著作権をはじめとする法的なリスクを十分に考慮すること。

AI 生成物の著作権

現行の日本の著作権法では、AI が自律的に生成したコンテンツには著作権が発生しないと解されている。ただし、人間が創作的な関与（プロンプト設計、選択・編集など）を行った場合は保護の対象となりうる。この解釈は今後の法改正・判例によって変わる可能性があるため、最新の動向に注意すること。

学習データに起因するリスク

AI が生成したコンテンツには、学習データとして取り込まれた第三者の著作物と類似した内容が含まれるリスクがある。特に画像生成 AI については訴訟事例も存在するため、クライアントの成果物に使用する場合は慎重に判断すること。

そのままでは不安が残る場合は、AI 生成物を参考にとどめ、人間の手で大幅に修正・再創作する形で利用することを検討する。

個人情報保護法・その他の規制

個人情報を含むデータを AI サービスに入力することは、個人情報保護法上の「第三者提供」に該当する可能性がある。プライバシーポリシーや利用規約でデータ処理の委託関係が明確になっているサービスを選択し、個人情報の取り扱いに関する社内ルールおよびクライアントとの契約内容を遵守すること。

クライアントへの説明責任

AI を使用して制作した成果物をクライアントに納品する場合、クライアントから AI の利用有無を問われる可能性がある。利用の有無や範囲について、あらかじめ合意を得ておくことが望ましい。プロジェクト開始時の合意事項として AI 利用方針を明確にしておくこと。

基本

情報管理の意識を常に持ち、適切な管理を行うことで情報漏洩を防止する。

事例としての紹介許可を得ているかいないかに関わらず、クライアント名やプロジェクトの内容、その他、プロジェクトに関連する情報を、公共の場所など、不特定多数が集まる場で話題にしたりすることを一切禁止する。

例えば、食事の最中、電車などでの移動中の会話などでクライアント名や案件の内容を出したりしない。これは家族や友人、知人などに対しても同様とする。クライアントの情報やプロジェクトの内容を不用意に第三者に話したりしないこと。これは機密情報とされるもの以外も含めすべての情報が該当する。

外出先での電話

やむを得ず、外出先などで携帯電話でクライアント、もしくは社内スタッフとプロジェクトの内容などについての会話をしなければならない場合、会話の内容が第三者に聞こえていないか十分に注意すること。

駅の構内や人通りの多い路上など、不特定多数が往来する場所での通話は禁止する。

パソコンや携帯電話の管理

業務で使用するパソコンや携帯電話（スマートフォン）の管理は厳重に行い、必ずパスワード等にてロックすること。また、画面ロックを解除したまま席を外したり、他人にそれらを貸したり、使わせたりはしないこと。（パソコンのセキュリティセクションも参照）

メールアドレス

クライアント情報やプロジェクト関連のファイルを、@gmail.com など、フリーのアドレス（不特定多数が @ 以降を共用しているアドレス）宛に送信することを禁止する。仮にクライアントからそのような要望があったとしても不可。メールアドレス間違いによる外部への情報漏洩を防止するため。

SNS やブログ

個人としての SNS の利用やブログの開設、運営は原則として禁止しないが、クライアントやプロジェクトの内容に関してそれらに投稿することは一切禁止する。これはアカウントが非公開になっている場合も含む。

パソコンのセキュリティ

デスクトップ、モバイルを問わず、使用するパソコンには必ずパスワードによるロックをかけること。また、画面ロックをしないまま PC の前を離れたり、第三者にパソコンを貸したりはしないこと（どうしても一時的に貸さなければならない場合はゲストアカウントを使用し、目の届く範囲で使用させること）。

カフェなど、複数の人間が周囲にいる状況で会社やクライアントの重要な情報が記載されたファイルを開くことを禁止する。また、公衆無線 LAN など、安全でないネットワーク上において、さらに通信が暗号化されていない状況で重要なファイルをメール送信したり、受け取ったりしないこと。

パスワード等の管理

業務で使用する Google Workspace、Dropbox など Web サービスは 2 要素認証（MFA）を必ず有効にすること。また、使用するパスワードは最低でも 16 桁、できれば 32 桁以上の強固なものを設定し、他サービス間での同じパスワードの使い回しは堅く禁じる。

パスワードの管理にはパスワードマネージャー（1Password、Bitwarden 等）の使用を推奨する。

また、パスワードを平文でメール送信することは禁止。リモートで送付する必要がある場合は、チャット・プロジェクト管理ツール上など、関係者以外がアクセスできない場所で投稿、あるいは送信すること。ファイルの閲覧に受取手のログインが必須な設定であれば、Google ドライブや、Dropbox などの共有ドライブサービスを利用することも可能。

また、「パスワードを伝達する」という目的を果たしたら、なるべく早めにファイルや投稿を削除し、いつまでもパスワード情報が放置されたままにしないこと。

パスワード情報などを誰でも閲覧可能な場所に保存したりはしないこと。

機密情報の管理

クライアントから提供された機密情報は、担当者の責任において厳重に管理する。

また、紙で提供された情報は、不用意に書類ケースに放置したり、シュレッダーにかけずに廃棄したりするようなことがないように注意すること。

クラウドサービスの利用

Dropbox をはじめとした、データを外部サーバに預けるサービスの利用に関しては、2 要素認証を行うなど、セキュリティの要件を満たしていれば特に制約はしないが、クライアントとの業務委託契約、あるいは機密保持契約の内容が優先される。

使用する場合でも、クライアント関連のデータは暗号化して保存するなど、データの取り扱いには注意すること。なお、機密情報と文書または口頭にて明示されたデータのクラウドサービスへのアップロードは原則として禁止する。

他者の著作権

映像、写真、音楽など、他者が創作したものを Web サイトで使用する場合は著作権の侵害を行わないよう十分に注意すること。映像や音楽等、他者が創作したものを公の場で利用する場合は、原則として創作者に対する利用許諾が必要なため、クライアントから提供された素材だとしても、必ず著作権の問題がクリアされているかを確認の上、使用する。

その他、フレームワークやライブラリをはじめとしたプログラムのソースコード等、ライセンスに則った適切な利用を行うこと。詳しくはライセンスのセクションを参照。

ライセンス

案件で使用する JavaScript ライブラリ、CSS フレームワーク、アイコンライブラリのライセンスは必ず確認し、ライセンスの元に正しく使用すること。また、ソースコードに記載されたライセンス表記は削除しないように注意すること。

ビルドツールなどを使用する場合にコメントの自動削除が適用されてしまう場合があるので /*! ... */ 形式のコメントになっていることを確認する。

なお、リンクツール（利用にあたり、作者ページへのリンクが必須のライブラリ等）は使用不可とする。

ブランドロゴ等の利用

Web サービスなど、ブランドロゴをバナーやボタンに使用する際は、各ブランドロゴの利用規約、ガイドラインを必ず確認し、それに従って利用する事。下記に代表的なブランドロゴの利用規約を挙げる。

• X（旧 Twitter）ブランドガイドライン
• Meta Brand Resource Center（Facebook、Instagram など）
• YouTube ブランド関連情報とガイドライン
• Android ブランドガイドライン
• Apple マーケティングリソースとアイデンティティに関するガイドライン
• LINE アイコンガイドライン

ビルドツール等

開発環境については各担当者の裁量で選択することができるが、複数人でのメンテナンス等を考慮し、下記に推奨ツールを記載する。特定の OS に依存するようなツールは使用しないこと。

CSS プリプロセッサ

Sass の使用を推奨する。ただし、CSS カスタムプロパティ（変数）の普及により、シンプルな案件では Sass を使わず素の CSS で対応することも可能。

CSS フレームワーク

クライアントと協議の上、問題ない場合は Tailwind CSS の使用を推奨する。

ビルドツール

Vite の使用を推奨する。npm-scripts との組み合わせで高速なビルド環境を実現できる。

バージョン管理

Git を推奨。リポジトリサービスは GitHub の使用を推奨するが、クライアント案件のソースコードをパブリックなリポジトリには保存しないこと。

JavaScript ライブラリ・フレームワーク

• React、および Next.js の使用を推奨する。原則として TypeScript を導入すること。
• 静的サイトジェネレーターについては Astro を推奨する（Astro プロジェクトの場合、GitHub テンプレートとして用意してある burnworks-astro-starter を使用してもよい）。
• 状態管理が必要な場合は、React の組み込み機能（useState / useReducer / Context）を優先し、必要に応じて Zustand 等の軽量ライブラリを検討すること。

パッケージマネージャー

npm を基本とする。プロジェクトの要件に応じて pnpm の使用も可。

ガイドラインの目的

本ガイドラインは、バーンワークス株式会社が行う Web サイト制作全般においての品質を保持するために定めたものであり、当社が本ガイドラインに基づいた Web サイト制作を行うことで、クライアントに対して常に安定した品質の納品物を提供するために策定されている。

本ガイドラインはプロジェクトの開始から納品までの各段階について、プロジェクトメンバーが考慮すべき、または守るべき指標をまとめたものであり、クライアントに対して当社の制作ガイドラインを示す際にも使用される。各プロジェクトメンバーは本ガイドラインに基づいた制作を行い、クライアントに対する一連のサービス提供、及び納品物の品質にばらつきが生じないよう努める必要がある。

なお、本ガイドラインによって策定された内容も、クライアントとの協議の結果、もしくはプロジェクトの円滑な進行、クライアントのビジネスゴール達成のためにより最適な方法がある場合は必ずしも順守する必要はない。ただし、その決断に至った経緯や結果に関しては必ず社内にて情報共有し、必要に応じてガイドラインの改善に役立てるものとする。

本ガイドラインで扱わない内容

就業規則やビジネスマナーに関するガイドライン、パートナー企業・フリーランスに関する規定、及びより細かな情報管理ルール等は別途定めているため、本ガイドラインの対象外としている。

また、コーディングにおいて、HTML や CSS をはじめとした Web 標準技術は W3C / WHATWG の各仕様に基づいて正しく使用することを前提としており、本ガイドライン内のコーディング規則ではその詳細について取り扱わない。

ガイドラインの改定

必要に応じて本ガイドラインは適時更新、改訂される。

バージョン ナンバリングのルール

本ガイドラインのバージョン番号は、

• [メジャーバージョン番号].[マイナーバージョン番号].[リビジョン番号]

という 3つの番号の組み合わせで構成される。公開版の最初のバージョン番号は、1.0.0 である。

本ガイドラインは、下記のルールに則って、更新、改訂ごとにバージョン番号が変更される。

1. メジャーバージョン番号は、大幅な構成の変更など、前バージョンと別のドキュメントとして扱うのが妥当なほどの変更が行われた場合に 1 ずつ増加する。
2. マイナーバージョン番号は、項目、項目内のセクションの追加が行われた場合に 1 ずつ増加する。
3. リビジョン番号は誤字脱字の修正や文章の軽微な修正などが行われた場合に 1 ずつ増加する。メジャーバージョン番号、またはマイナーバージョン番号が変更された際は、0 にリセットされる。

本ガイドラインの改訂履歴は下記、GitHub 上で確認できる。

• History for burnworks/burnworks-guidelines

ガイドラインの公開とライセンス

本ガイドラインは、下記のライセンスで一般に公開される。

• Creative Commons — 表示 - 非営利 4.0 国際 — CC BY-NC 4.0

本ガイドラインのソースファイル一式は下記から取得可能。

• burnworks/burnworks-guidelines