phpの作業で数値の正規表現をチェックする時にいつも検索してコピーして使っていました。
しかし、自分で自由に修正したい場合は、正規表現書き方や人が書いてあるものを理解していないと困る。
今日はいつも面倒見てくれているエンジニアが説明してくれたので、理解できるようになりました。
理解しておくと効率がいいですね（^_^）
少しだけですが、今日覚えたことを書きたいと思います。
<table>
<tbody>
<tr>
<td>&#8211;</td>
<td>範囲</td>
</tr>
<tr>
<td>^</td>
<td>文字列の先頭</td>
</tr>
<tr>
<td>$</td>
<td>文字列の末尾</td>
</tr>
<tr>
<td>a-z </td>
<td>小文字の半角英文字</td>
</tr>
<tr>
<td>A-Z</td>
<td>大文字の半角英文字</td>
</tr>
<tr>
<td>0-9</td>
<td>数字</td>
</tr>
<tr>
<td>^0-9</td>
<td>数字以外</td>
</tr>
<tr>
<td>*</td>
<td>0回以上の連続する文字</td>
</tr>
<tr>
<td>+</td>
<td>1回以上の連続する文字</td>
</tr>
<tr>
<td>? </td>
<td>0または1回だけの文字</td>
</tr>
<tr>
<td>{n}?</td>
<td>n回の連続する文字</td>
</tr>
<tr>
<td>{n,}?</td>
<td>n回以上の連続する文字</td>
</tr>
<tr>
<td>{n, m}?</td>
<td>n回以上、m回以下の連続する文字</td>
</tr>
</tbody>
</table>

PHP正規表現

2024年4月1日より、障害者差別解消法の改正内容が適用され、障害がある方への「合理的配慮」が義務付けられました。これまでは、国や地方公共団体などに義務付けられていましたが、その適用範囲が拡張され、民間事業者に対しても適用されます。  
  
合理的配慮とは、例えば、  
  
・車いすの利用者が移動しやすいように手伝う。スロープを設置する。  
・窓口で、手話や筆談で意思の疎通をする。  
  
などが該当します。  
  
社会生活の中にある障壁を取り除き、全ての人が利用しやすいバリアフリーな環境を実現するため、負担が重すぎない範囲で対応することが努力義務となりました。これは接客業を行う事業者に限定された話ではありません。スターフィールドのようにWeb制作を行う事業者も対応が必要となります。  
  
Webサイト制作においては、「Webアクセシビリティを確保した開発」が求められます。  
  
##bアクセシビリティとは
  
Webアクセシビリティとは、すべての人がWebサイトにアクセスしやすく不自由なく使える状態を指します。そしてなるべく向上させていくことを理想としています。  
  
一般的に、Webアクセシビリティが確保できているとは、以下の状態を指します。  
  
・視覚障害あっても情報が伝わり、操作もできること。  
・キーボードだけで操作できること。  
・一部の色が区別できなくても得られる情報に欠損が無い事。  
・音声コンテンツや動画コンテンツを設置したさい、音声が聞こえなくても情報が分かること。  
  
もはやインターネットは情報インフラとして社会に欠かせない物となり、あらゆる方が使用します。もちろん五体満足の健常者だけでなく、高齢者や、視覚障害や聴覚障害などの障害者なども利用します。  
特に障害者に関しては、症状や程度は人それぞれです。そういった個々の状況に応じた対応が求められます。障害者に限定しなくても怪我や病気で一時的ハンデを負う人、加齢により視力の衰えが有る方も利用しやすい環境整備が必要です。  
  
こういったすべての人々がWebサイトを不自由なく利用できるようにすることが、ウェブアクセシビリティの要件です。なので、どんな事情がある方でも利用しやすい環境を提供することが、企業の社会的な責任として求められます。

また、この対応をすることは障害者のために負担を強いられる作業ではなく、使いやすい便利なWebサイトを開発することでもあり健常者にとっても有益なことです。
  

 ![](https://cont.sterfield.co.jp/uploads/photo1_76ee39cc16.jpg) 



## 実践プロセス
  
実際にどういう点に気を付けてコンテンツ制作をするべきか、政府広報オンラインや、デジタル庁のWebアクセシビリティ導入ガイドブックなどでも案内されていますので、紹介します。  
  
### 音声を自動再生させない
  
音声を自動再生することや強制的に再生させることは避けるべきです。もし、自動再生するのなら3秒以内に収め、3秒以上続く場合は利用者が止められるようにする必要があります。  
また、音声の流れるページや動画広告などで自動再生する場合は、一時停止またはミュートボタンを設置するべきです。  
  
### ポップアップなどモーダルウィンドーには終了ボタンをつける
  
Webサイトはマウス操作が難しい場合はキーボードだけで利用する方もいます。その際、モーダルウィンドーを開いた際、モーダルウィンドウを閉じるボタンがないとキーボードの操作だけではモーダルウィンドウからの離脱ができません。  

### 1秒に3回以上光が点滅するコンテンツは作らない
  
高速で光の点滅を繰り返すコンテンツは光感受性発作などを発生する恐れがあります。時には重大な健康被害が出ることもあります。  
アニメーションを制作するならその危険性も十分知っておくべきです。

### 自動でコンテンツを切り替えない
  
情報を受け取れる速度は人によって異なります。また、画面上に動き続けるコンテンツがあると、他の箇所の操作や閲覧を妨げられる利用者もいます。そのため、スライドショーなど、自動で切り替わるコンテンツなどがある場合は、一時停止、非表示、停止の機能を設置する必要があります。

### ロゴ・写真・イラストなどの画像が指し示している情報を代替テキストとして付与する

画像を使用する際はalt属性を設置して代替テキストの設置が必要です。代替テキスト」は画像で提供される情報に対して「同等の役割を果たすテキスト」のことで、画像の変わりにこのテキストが表示されても違和感がないことが望まれます。  
  
具体的には、以下になります。  
  
・画像がリンクの場合、代替テキストはリンク先を示す内容であるべき。  
・グラフや図表はその要約を記述するべき。但し、隣接するテキストに要約があるのなら、何のグラフや図表を示すだけでよい。  
・文字や（ロゴマークや見出しなど）を表現している場合、同じ文字を記述するべき  
・装飾など意味がない画像については空のaltを設置するべき  
  
また、文字数については制限がありませんが、スクリーンリーダなどで音声出力されることを考慮すると80字ほどを目安にするべきです。
  
### キーボード操作だけで、サービスのすべての機能にアクセスすることができるようにする

マウス操作が難しい人はキーボードの操作に頼らず負えません。  
そのため、フォーカスインジケーター（選択中の要素に枠線）をつけるなどキーボード操作前提の作り方をするべきです。

### 色の違いだけで情報を伝えるのやめる
  
色覚に異常があり、正常に色が見えない人がいます。他えば赤色が分からない人が下記図を見ると全てが黒一色に見えてしまいます。


 ![](https://cont.sterfield.co.jp/uploads/sample1_f3f00e436c.png) 

  
このようなデザインでは必須項目が分かりません。  
  
### テキストはスクリーンリーダで音声として出力されることを意識する
  
視覚障害がある方、テストはスクリーンリーダなどを使ってテキストを音声として出力します。  
  
下記図の「日時」と「場所」の表記について、左側の方では、「日　時」「場　所」とスペースが空いています。スペースは全角のスペースを入力して作りました。  
  
 ![](https://cont.sterfield.co.jp/uploads/sample2_dfae820b43.png) 
  

この場合、スクリーンリーダで読んでみると、「ひ　とき」「ば　ところ」と呼んでしまいいます。  
  
もし、このようにスペースを空けるデザインをするなら、CSSを用いて広げないとスクリーンリーダが正しく読み取れません。
  
### リンク先を明確にする
  
リンクでどこか他のページへ移動する際どんなページへ移動するか明確にするべきです。例えば、以下のようなコンテンツの場合、左側のリンクは「詳しくはこちら」とだけ書いてあり、このボタン単体では移動先がどのようなコンテンツか分かりません。  
  

 ![](https://cont.sterfield.co.jp/uploads/sample3a_e9c460827b.png) 

  
視覚情報を使える人なら、テキストに付随したものと判断できるでしょうが、音声情報だけであったり、点字ディスプレイではその前後関係の把握が分かりにくい可能性があるのでリンクだけでどこに移動するか明確にした方がいいです。  
  
  
など、多くの事例があります。  
  
また、肝心なことはプロジェクトを進めるに辺り、一人担当者を決めて対応するのではなく、プロジェクトに関わる全員が対応策を検討し、メンバー全員でどんな対策を検討するべきか検討することが重要です。基本的には、JIS X 8341-3:2016などのガイドラインを参考にして開発を行い、チェックツールで確認しながら、向上させていくのが一般的ですが、結局のところ、最適解は人間が判断して決めなくてはいけないからです。  
  
例えば、画像には代替えテキストを設置するべき点を例にすると、ガイドラインでも示しているし、もし抜けがあったらチェックツールで指摘してくれます。なので、設置漏れは防げますが、どんな代替えテキストが適切かはコンテンツによって異なります。  
仮に犬と猫が映っている写真があったとします。これに入れる代替テキストは「犬の写真」或いは「猫の写真」とした方がいいのか、「動物の写真」とした方がいいのか、これはコンテンツ次第です。この判断は人間にしかできません。  
  
## まとめ
  
今回ガイドラインを見て指摘している点は、普段の業務で「既にやっている」あるいは、「できればやった方がいい」と言われている物が多かったのですが、強く意識していない点でもありました。  
しかし、より良い物を作る上ではしっかり意識しなくてはいけないなと思いました。今後はガイドラインを参考にしてより良いサービスを提供できるようにつ努めていきます。
  
#### 参考記事
  
政府広報オンライン：  
https://www.gov-online.go.jp/useful/article/202310/2.html#c1
  
  
デジタル庁　Webアクセシビリティ導入ガイドブック  
https://www.gov-online.go.jp/useful/article/202310/2.html#c1


240419_mv.jpg

Webアクセシビリティの義務化について調べてみました

## はじめに

Prisma でデータベーススキーマを書く際に、[ZenStack](https://zenstack.dev/) というフレームワークが便利だったので紹介します。
ZenStack にはさまざまな機能がありますが、今回はデータベーススキーマの定義について重点的に説明します。

## ZenStack とは

ZenStack は、Node.js と TypeScript 向けのフルスタック開発フレームワークです。データベーススキーマを定義するだけで、フロントエンドとバックエンドの実装を自動的に生成できます。
ZenStack は、Prisma ORM をベースとして構築されているので、Prisma のすべての機能を利用できます。

## ZenStack を使用したデータベーススキーマの書き方

ZenStack では、[ZModel](https://zenstack.dev/docs/reference/zmodel-language) というデータモデリング言語でデータベーススキーマを作成します。
[Prisma Schema](https://www.prisma.io/docs/orm/prisma-schema) をベースとしているので、基本的な文法は Prisma Schema と同じように書くことができます。

また、VSCode 向けに[ZenStack の拡張機能](https://marketplace.visualstudio.com/items?itemName=ZenStack.ZenStack)が用意されています。
エラーチェックやコード補完をしてくれるので、ZModel でデータベーススキーマを書く際はインストールしておくと便利です。

## ZModel を Prisma Schema に変換する方法

ZModel で定義したデータベーススキーマを Prisma で使用するには、以下のコマンドで ZModel → Prisma Schema に変換する必要があります。

```
npx zenstack generate
```

変換元と変換先のファイルパスを指定したい場合は package.json に以下の設定を記述します。

```
  "zenstack": {
    "schema": "[変換元のZModelファイル(デフォルト：./schema.zmodel)]"
    "prisma": "[変換先のSchemaファイル(デフォルト：./prisma/schema.prisma)]",
  },
```

## ZModel の便利機能

Zmodel で利用できる便利な機能をいくつか紹介します。

### abstract

ベースとなる抽象化 model を作成し、各項目を継承できます。
登録日時などのように、各テーブルに共通なフィールドがある場合に使うと便利です。

```
generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url = env("DATABASE_URL")
}

abstract model Base {
  id Int @id @default(autoincrement())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt
}

model User extends Base {
  email String @unique
  name String
  posts Post[]
}

model Post extends Base {
  title     String
  content   String?
  published Boolean @default(false)
  author    User? @relation(fields:  [authorId], references: [id])
  authorId  Int?
}
```

上記 ZModel を変換すると、以下のような Prisma Schema が生成されます。

```
datasource db {
    provider = "postgresql"
    url = env("DATABASE_URL")
}

generator client {
    provider = "prisma-client-js"
}

model User {
    id Int @id() @default(autoincrement())
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt()
    email String @unique()
    name String
    posts Post[]
}

model Post {
    id Int @id() @default(autoincrement())
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt()
    title String
    content String?
    published Boolean @default(false)
    author User? @relation(fields: [authorId], references: [id])
    authorId Int?
}
```

### ファイル分割

1 ファイルで全てのスキーマを定義すると、スキーマが増えてくるにつれて管理が大変になると思います。
そこで、ZModel ファイルを分割してスキーマ定義する方法を紹介します。

今回の例では ZModel ファイルを以下のように分割してみます。

- base.zmodel: generator や datasource を記述するファイル
- user.zmodel: user のスキーマ
- post.zmodel: post のスキーマ

base.zmodel

```
// importに分割したZmodelファイルをすべて記載します
import "user"
import "post"

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url = env("DATABASE_URL")
}
```

user.zmodel

```
model User {
  id Int @id() @default(autoincrement())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt()
  email String @unique()
  name String
  posts Post[]
}
```

post.zmodel

```
model Post {
  id Int @id() @default(autoincrement())
  createdAt DateTime @default(now())
  updatedAt DateTime @updatedAt()
  title String
  content String?
  published Boolean @default(false)
  author User? @relation(fields: [authorId], references: [id])
  authorId Int?
}
```

変換元のファイルを「base.zmodel」に指定して変換すると、以下のような Prisma Schema が生成されます。

```
datasource db {
    provider = "postgresql"
    url = env("DATABASE_URL")
}

generator client {
    provider = "prisma-client-js"
}

model User {
    id Int @id() @default(autoincrement())
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt()
    email String @unique()
    name String
    posts Post[]
}

model Post {
    id Int @id() @default(autoincrement())
    createdAt DateTime @default(now())
    updatedAt DateTime @updatedAt()
    title String
    content String?
    published Boolean @default(false)
    author User? @relation(fields: [authorId], references: [id])
    authorId Int?
}
```

### 属性

ZModel でのみ使用できる属性を一部紹介します。
詳しい内容は[公式リファレンス](https://zenstack.dev/docs/reference/zmodel-language#attribute)をご確認ください。

#### @password

データベースにハッシュ化した文字列を登録/更新します。
内部的には[bcryptjs](https://github.com/dcodeIO/bcrypt.js#readme)ライブラリを使用してハッシュ化しているようです。

以下のように引数が定義されていて、saltLength からハッシュのコストを設定したり、salt の設定も可能です。

```
@password(saltLength: Int?, salt: String?)
```

#### @omit

この属性を指定したフィールドはデータ呼び出し時に値が取得されなくなります。
上記の@password と組み合わせて使用すると便利です。

## まとめ

最近リリースされたばかりのフレームワークだからなのか、情報量が少なく調べるのに苦労しました。
今回は ZModel を重点的に紹介しましたが、他にも魅力的な機能がたくさんあるライブラリなので、次の機会に紹介したいと思います！

## 参考

- https://ZenStack.dev/
- https://www.ey-office.com/blog_archive/2023/09/20/i-learned-a-little-more-about-zenstack-zmodel-is-useful/
- https://www.Prisma.io/docs/orm/Prisma-schema/data-model/models
- https://zenn.dev/smish0000/articles/f1a6f463417b65


logo.png

ZenStack を使用してデータベーススキーマを作成する

## はじめに

Google Cloud の [Cloud Run](https://cloud.google.com/run?hl=ja) を使ってインターネット上に公開せず内部からのアクセスのみを受け付けるサービスを構築する場合、いくつかの方法がありますが認証オプションを「認証が必要」にしてデプロイする方法がもっとも簡単です。

 ![cloud-run-deploy](https://cont.sterfield.co.jp/uploads/cloud_run_deploy_0b4c2235ac.png) 


この方法でデプロイした Cloud Run サービスの URL にブラウザでアクセスするとリクエストに認証情報が含まれてないため

```
Error: Forbidden
Your client does not have permission to get URL / from this server.
```

というエラーが表示されます。このエラーを回避して、アクセスする方法のうち代表的な3パターンを紹介します。

## 前提

Node.js で書かれたアプリケーションがデプロイされた次の 2 つの Cloud Run サービスがデプロイされている環境があるとします。

- 「Front」はインターネット上から直接アクセスされることを想定しているため、認証オプション「未認証のアクセスを許可」を設定してデプロイされている
- 「Internal」は「Front」から内部でアクセスされるもので外部からのアクセスを拒否したいため、認証オプション「認証が必要」を設定してデプロイされている

![cloud-run-diagram](https://cont.sterfield.co.jp/uploads/cloud_run_diagram_a0a3472409.png) 

## ① 他の Cloud Run サービスからアクセスする方法

「Front」 → 「Internal」

同じプロジェクトでデプロイされた Cloud Run 同士でアクセスする場合、[Google Auth Library](https://github.com/googleapis/google-auth-library-nodejs)を使うことで認証に必要なトークンを含んだ HTTP ヘッダーが取得できます。

「Front」の Cloud Run サービスをデプロイしたサービスアカウントに`Cloud Run 起動元` (`roles/run.invoker`) ロールが付与されている場合、下記のようなコードでアクセスが可能になります。

```
import { GoogleAuth } from "google-auth-library";

・・・

const auth = new GoogleAuth();
const client = await auth.getIdTokenClient(`${「Internal」のURL}`);
const headers = await client.getRequestHeaders();

// headersの中に Authorization: Bearer ${トークン} が設定されている
await fetch(`${「Internal」のURL}`, { headers });
```

## ②Cloud Run 以外のサービスからアクセスする方法

Cloud Scheduler → 「Internal」

[Cloud Scheduler](https://cloud.google.com/scheduler?hl=ja)から「Internal」にアクセスする場合は、HTTP ターゲットを作成する際、Auth ヘッダーを「OIDC トークンを追加」に設定してサービスアカウントに`Cloud Run 起動元` (`roles/run.invoker`) ロールが付与されているものを設定すると、自動でトークンを付与した HTTP アクセスを行ってくれます。

 ![cloud-scheduler](https://cont.sterfield.co.jp/uploads/cloud_scheduler_74457eda15.png) 

[Cloud Pub/Sub](https://cloud.google.com/pubsub?hl=ja)などでも同じように OIDC 認証を設定することでアクセス可能になります。

## ③ ローカルからアクセスする方法

開発者のローカル PC のコンソール → 「Internal」

gcloud CLI を使うことで開発用の汎用 ID トークンを生成することができます。`Cloud Run 起動元` (`roles/run.invoker`) ロールが付与されているユーザーでログインして、[`gcloud auth print-identity-token`](https://cloud.google.com/sdk/gcloud/reference/auth/print-identity-token)を実行するとログインユーザーのトークンが取得できます。

curl コマンドと組み合わせて下記の様に実行することでアクセスが成功します。

```
curl -H "Authorization: Bearer $(gcloud auth print-identity-token)" ${「Internal」のURL}
```

## まとめ

今回紹介した内容はすべて Google Cloud の公式ドキュメントに記載されているものですが、複数のページにまたがって解説されており、個人的に探すのが大変だったのでブログにまとめました。同じような苦労をされている方のお役に立てれば幸いです。

## 参考リンク

- https://cloud.google.com/run/docs/tutorials/secure-services?hl=ja
- https://zenn.dev/steelydylan/scraps/60f3536dd0c9b4
- https://cloud.google.com/scheduler/docs/http-target-auth?hl=ja
- https://cloud.google.com/run/docs/authenticating/developers?hl=ja#curl

cloud_run.png

認証が必要な Cloud Run サービスにアクセスする方法まとめ

## はじめに
フロントエンドにおいても、製品の品質を向上させ、維持していく上で、テストは必須と言えるほど重要になってきています(参考: <a href="https://roadmap.sh/frontend" target="_blank" rel="noopener noreferrer">Frontend Developer Roadmap</a>)。 
テストの状態を計測するよく使われる指標の一つとして、テストのカバレッジ率があります。 
フロントエンドのテストは、主に単体テスト、統合テスト（コンポーネントテスト）、E2Eテストに分けられます。 
Cypressでは基本的にこれらすべてを一元的に実装できるため、テストを書く上で便利です。 
ただ、CypressはJestやJestベースのPlarywrightと違って、標準ではカバレッジレポートを出力できません。 
特にNext.jsでは<a href="https://docs.cypress.io/guides/tooling/code-coverage" target="_blank" rel="noopener noreferrer">公式で紹介されている方法</a>そのままでは計測できなかったので、 
Next.jsとCypressを使ったサイトでテストカバレッジ率を計測する方法について、 
実際に検証しながら整理してみました。

※この記事では、Cypressの導入部分は省略します

## 全体の流れ
1. 計測のためのプラグインを追加する
1. package.json レポートのオプションを追加
1. Cypress の config に計測のための設定をを追加
1. Cypress の 共通設定部分にプラグインの読み込みを追加
1. Next.js の config にプラグインの記述を追加
2. テストを実行し、レポートを表示する

## 計測のためのプラグインを追加する
Cypressでカバレッジ率のタスクを実行するための **@cypress/code-coverage** と Next.jsでレポートを作成するための **swc-plugin-coverage-instrument** をインストールします。
```bash
npm i -D @cypress/code-coverage swc-plugin-coverage-instrument
```

## package.json レポートのオプションを追加
レポートに含めたいファイルや、含めたくないファイルがある場合、以下のように"nyc"の項目を追加して、オプションを指定します。

###### package.json
```diff
{
 "name": "example",
 ︙
 },
+ "nyc": {
+ "extension": [".ts", ".tsx"],
+ "include": ["pages/**/*.tsx", "src/**/*.ts", "src/**/*.tsx"],
+ "exclude": ["node_modules/**", "mock-data/**", "cypress/**", "**/*.cy.ts"],
+ "excludeNodeModules": true,
+ "excludeAfterRemap": true
+ }
}
```

## Cypress の config に計測のための設定を追加
cypress.config.ts へ以下のように、コードカバレッジを計測するための設定を追加します。

###### cypress.config.ts
```diff
import { defineConfig } from "cypress";
+ import codeCoverageTask from "@cypress/code-coverage/task";

export default defineConfig({
 env: {
 enableMock: true,
+ codeCoverageTasksRegistered: true
 },
 e2e: {
+ setupNodeEvents(on, config) {
+ codeCoverageTask(on, config);
+ return config;
+ },
 baseUrl: "http://localhost:3000"
 },
 component: {
 devServer: {
 framework: "next",
 bundler: "webpack"
 },
 defaultCommandTimeout: 6000,
+ setupNodeEvents(on, config) {
+ codeCoverageTask(on, config);
+ return config;
+ }
 }
});
```

## Cypress の 共通設定部分にプラグインの読み込みを追加
cypress/support/component.ts や cypress/support/e2e.ts に、 
プラグイン読み込みのコードを追加します。
###### cypress/support/component.ts | cypress/support/e2e.ts
```diff
+ import "@cypress/code-coverage/support";
```

## Next.js の config にプラグインの記述を追加
next.config.js のビルド設定部分にも、プラグインの記述を追加します。

###### next.config.js
```diff
const withImages = require("next-images");

module.exports = withImages({
 trailingSlash: true,
+ experimental: {
+ swcPlugins: [
+ ["swc-plugin-coverage-instrument", {
+ compact: false
+ }]
+ ],
+ },
});
```

## テストを実行して、レポートを表示する
これで、準備ができましたので、実際にテストを実行してレポートを表示してみます。

### テストを実行
テストの script は package.json で以下のように設定しているとします。
```diff
{
 ︙
 "scripts": {
 ︙
+ "cypress": "cypress open",
+ "cypress:e2e": "cypress run --e2e",
+ "cypress:component": "cypress run --component"
 ︙
 },
 ︙
}
```

コンポーネントテストを実行してみます。
```
npm run cypress:component
```
テストが終了すると、以下のディレクトリにファイルが生成されます。 
- coverage
- .nyc_output

coverage/lcov-report/index.html を表示すると、 
以下のようなレポートを確認できます。 
 
 ![](https://cont.sterfield.co.jp/uploads/report_gui_883931f06d.png) 

また、以下のようにコマンドを打つことで、概要を表示できます。
```bash
npx nyc report --reporter=text-summary 
```
 
 ![](https://cont.sterfield.co.jp/uploads/report_cl_7970bcc25b.png) 
状態、分岐、関数、行数など、色々な方向で評価してくれます。

## まとめ
Next.jsでは、バンドラーがSWCなため、公式ドキュメントに従って設定すると実行が難しいことがわかりました。 
ただ、調査を進めることで、レポートの取得が可能であることがわかりました。 
今後はこれを活用し、Next.jsとCypressを組み合わせて効果的なテスト運用を構築していく予定です。 
この組み合わせにおいては、準備が整えば手軽にテストレポートを取得でき、より効率的かつ信頼性の高い開発プロセスを構築できると考えています。 
今回の課題を克服することで、将来的なプロジェクトでの利用をスムーズに進めることが期待できます。 
Next.js ✖️ Cypressの組み合わせを最大限に活かし、テストの品質向上に貢献していきます。

## 参考リンク

- [Frontend Developer Roadmap](https://roadmap.sh/frontend)
- [Code Coverage | Cypress Documentation](https://docs.cypress.io/guides/tooling/code-coverage)
- [swc-plugin-coverage-instrument](https://github.com/kwonoj/swc-plugin-coverage-instrument?tab=readme-ov-file)

nino-eye.jpg

Next.jsとCypressを使ったWebアプリでテストのカバレッジ率を計測する

2024年1月にアメリカのウォルトディズニー社の初期作品「蒸気船ウィリー」の著作権が消滅しパブリックドメインとなりました。この作品はミッキーマウスが初めて登場したアニメーションであり、著作権が無くなったことで、この作品のストーリーや登場したミッキーマウスをはじめとするキャラクターを自由に使って創作できるようになります。  
このニュースがあり、早くも「蒸気船ウィリー」を題材にしたホラー映画やゲームが発表されるなどの動きがありました。
  
スターフィールドは映像制作をする会社ではありませんが、デザインやシステムなどのものづくり行っています。そのため、無関係のニュースとは言い難いです。  
制作業務を行う者として、漠然と他者が作ったものは無断では使えないという認識を当然のように持っていますが、そもそも著作権とは何なのか、調べてみました。  
  
## 著作権に法的な有効利用がある理由
  
先ず前提として社会は、誰かが作った知的財産は制作者が永続に独占するより、人類共有の財産として誰もが自由に使える方が良いと考えています。その方が産業や文化を育むことに貢献できます。  
  
現にディズニーの作品も「シンデレラ」「不思議の国のアリス」「白雪姫」など、おとぎ話を題材にした作品があります。ディズニーがこれらの作品を題材にしアニメーション映画を作り、それにより文化の発展に貢献したことは間違いありません。  
  
しかし、その一方で誰もが自由に作品を使用できるなら、制作者の利益を守ることができません。著作権は制作者が作品を通じて収益を得る能力と、公共の文化の発展に寄与にすることのバランスを取るために存在しています。  
  
## 著作権の国際ルール  
  
著作権に国境はありません。著作物は国境を越えて利用されるので19世紀末から国際条約を結んで保護してきました。しかし、何を保護するのか？また、作品の権利はいつの時点で派生するのか？など法で銘文化してその対象を定めるのは考え方も色々あり、一筋縄ではいきません。  
  
例えば、日本をはじめとするベルヌ条約を結んだ国家間では作品を作った後、無方式主義をとっており、特に登録などの手続きをしなくても制作物の著作権を得られます。一方、アメリカや中南米では方式主義を取っており、作品を作った後に著作権庁に登録することで著作権が認められます。  
  
このように考え方も異なり、また社会の発展により新しいメディアが登場すると新しく保護するべき物が増えてきます。そのため社会情勢や技術の進歩により保護対象を広げたり、新たな協定や条約を作ってきたようです。  
  
なお、現在では、アメリカのように方式主義をとっている国でも「"&copy;"（コピーライツマーク）」を掲示することで保護の対象になるよう条約のルールで決められています。
  
 ![](https://cont.sterfield.co.jp/uploads/c_mark2_6f537d4ee1.png) 

  
簡単に主な国際条約をまとめてみました。
  
|              | ベルヌ条約 | 万国著作権条約 | 
| ------------ | --------- | -------------- | 
| 創設年       | 1886年     | 1952年         | 
| 日本の締結年 | 1899年     | 1956年          | 
| 加入国数     | 179        | 180            | 
| 主な目的     | 学的及び美術的著作物の保護 | 文学的及び美術的著作物の保護&#124;欧州を中心としたベルヌ条約と米国、中南米を中心としたパンアメリカン条約の精度の調整 | 
| 特長         | 無方式主義（作品を作った後、登録などの手続きは不要）　など | 無方式主義国の著作物であっても©表示によって保護　など |
  
  
|              | ローマ条約 | レコード条約 | 
| ------------ | --------- | -------------- | 
| 創設年       | 1961年     | 1971年         | 
| 日本の締結年 | 1989年     | 1978年           | 
| 加入国数     | 96        | 80            | 
| 主な目的     | レコード製作者、実演家、放送機関などの保護 | レコード製作者の保護 | 
| 特長         | 放送という場面で、実演家や商業用レコードの二次利用について規定　など | 許可されてないレコードの複製、輸入、配布を禁止　など |
  
  
|              | TRIPS協定 | WIPO著作権条約（WCT） | 
| ------------ | --------- | -------------- | 
| 創設年       | 1994年     | 1996年         |
| 日本の締結年 | 1994年     | 2000年          |
| 加入国数 | 164 | 113 |
| 主な目的 | 貿易の際、知的所有権に関する協定 | 著作権に関する世界知的所有権機関条約 |
| 特長 | プログラム、データベース、映画、レコードの著作権と貸与に関する権利の保護　など | 著作物の譲渡権、貸与権、利用可能化権について規定　など |
  
  
|              | 北京条約 | マケラッシュ条約 | 
| ------------ | --------- | -------------- | 
| 創設年 | 2012年 | 2013年 |
| 日本の締結年 | 2020年 | 2018年 |
| 加入国数 | 47 | 92 |
| 主な目的 | 視聴覚的実演に関する条約 | 視覚や聴覚の障害がある人が著作物を利用する機会を促進 |
| 特長 | 実演家氏名の表示や同一性を保持する権利の規定　など | 障害に合わせて著作物を改変する際の制限についての規約　など |
  
  
など、多岐にわたる条約があります。
どのルールが適用されるのか？これは専門家の間でも意見が分かれてしまいますが、
共通することは  
  
・著作物を守る意識が働いていること  
・自国の著作物と同様に外国の著作物も守ること  
  
という点です。
  
しかし、話が複雑になる点ですが、保護期間はその国よって異なります。
  
## アメリカと日本の違い
  
著作物は加盟国で守ることは決まっていますが、自国の著作物と同様に権利を与えるというのが基本方針です。  
そのため、保護期間はその国の考え方で異なります。  
  
今回話題にした「蒸気船ウィリー」を例にするとアメリカは発表年（登録年）からカウントします。期間については紆余曲折があったようですが最終的に95年間になりました。そのためアメリカでは2024年からパブリックドメインになり、初期のミッキーマウスも自由に使えます。  
  
しかし、日本の場合は、このような単純な話ではありません。作品が団体名義か、個人名義かでも期間が変わります。というのはアメリカと違い、団体名義なら発表年からカウントし、個人名義なら作者が生存している期間と死後も保護期間があるからです。  
また、ミッキーマウス単体で考えた場合、ミッキーマウスの原画という絵があります。という事は映画の付属物なのか、美術品なのか？という見解でまた保護期間が異なります。
  
更に日本は連合国と戦争していた歴史があり、平和条約を結ぶ際に、戦争中の期間である10年5ヶ月分も別途保護期間として加算することが決められています。  
  
つまり、日本においてのミッキーマウスの著作権は以下のルールが当てはまることになります。

### ミッキーマウスの保護に影響するルール
  
1. 1928年11月時点（蒸気船ウィリーの発表年）の著作権の保護期間は団体名義なら発表から33年、個人名義なら死後38年間に定められていた。
2. 1970年新たな著作権法が施行され、映画や団体名義の保護期間は発表から50年、美術品は作者の死後50年に延長。また、この法律が施行された時点で保護対象となっている作品も同じく50年間に延長。
3. 2004年、映画の保護期間を公表から70年に延長し、保護対象の作品も延長の対象となった。
4. ルール3に基づく保護期間と、ルール1に基づく保護期間を比べた場合、長い方の保護期間が採用される。
5. 2018年映画以外の著作権の保護期間を20年間延長が決定。
6. 平和条約の義務により、戦争中の期間も保護対象となるため、戦前の連合国の作品は保護期間が別途10年5ヶ月加算される。
  
  
このため、6通りの見解が出てしまい、結論はまだ出ていません。以下にそれぞれ解説します。  
  
### 見解1　ミッキーマウスは映画の一部であり、ディズニー社の著作物である。  
  
保護期間：1989年5月まで
  
この見解に基づいた場合、当時の映画の保護期間は33年なので1961年まで、更にルール6が加算され1972年5月まで延長されます。70年の時点で保護対象である作品という事はルール3も適用され保護期間は50年に延長されます。従って、1989年5月で終了　となります。  
  
しかし、かつてチャップリンの映画の保護期間で、映画監督チャップリンの制作物なのか？映画製作会社の作品なのか？の見解で、裁判になりました。結果、最高裁がチャップリン個人の作品と判断しましたので、映画は監督の死後から保護期間を数えるのが通例となります。よって、この見解は通じないと思われます。
  
  
### 見解2  ミッキーマウスは映画の一部であり、ウォルト・ディズニー氏の作品である。  
  
保護期間：2015年5月まで
  
この場合、ウォルト・ディズニー氏が亡くなったのは1966年12月なので、ルール1に基づき死後38年間までが保護対象なので2004年ま、そこにルール6が加算され、2015年まで5月までとなります。  
  
2004年時点で保護期間があるという事はルール3の発表年から70年というルールも適用範囲ですが、この考えとルール6が加算されると2009年5月までとなります。しかし、このような場合はルール4に該当し、期間が長い方である　2015年5月までが期間となります。  
  
  
### 見解3  ミッキーマウスは映画の一部であり、アブ・アイワークス氏の作品である。
  
保護期間：2020年5月まで
  
アブ・アイワークスはウォルト・ディズニーと共にスタジオを立ち上げた人物です。またミッキーマウスの造形の殆どは彼が担当して制作したようです。当然映画製作に大きくかかわり、蒸気船ウィリーのクレジットには「アブ・アイワークス作　ウォルト・ディズニーアニメ」と表記されています。また、アブ・アイワークスはウォルト・ディズニーより長生きし、1971年に亡くなりました。　　
ということはこの時点から算出し、2020年5月までとなります。
  
  
### 見解4　ミッキーマウスは美術作品でもあり、ウォルトディズニー社の制作物である。
  
保護期間：1989年5月まで
  
見解1～3はミッキーマウスが映画の一部という前提の場合の保護期間です。しかし、ミッキーマウスというキャラクターは原画があり、キャラクターその物が独立して著作権があるという考え方もできます。  
  
そして、キャラクターの制作者がウォルト・ディズニー社という団体であると見ることもできます。この場合、考え方は概ね見解1と同様です。しかし、同じく同様の理由で認められないでしょう。
  
  
### 見解5　ミッキーマウスはウォルト・ディズニー氏名義の美術作品である。  
  
保護期間：2047年5月まで
  
個人名義であるならルール1により死亡した段階で、1966年から算出され2004年までであり、1970年時点で保護対象となるのでルール2が適用され2016年まで延長されます。さらにルール6の戦争中の期間も加算されて2027年5月まで延長します。  
2018年時点で保護対象となるなら、ルール5も適用され保護期間は死後70年という扱いになり、2047年5月まで、という判断になります。
  
  
### 見解6　ミッキーマウスはアブ・アイワークス氏名義の美術作品である。  
  
保護期間：2052年5月まで
  
上述したようにミッキーマウスの誕生にはアブ・アイワークス氏の功績が大きく、ミッキーマウスはこの方の作品という見方もできます。という事はアブ・アイワークスの死亡年から算出するので2052年5月までという判断になります。
  
  
  
こうしてみると日本国内では「蒸気船ウィリー」の著作権は切れているが「ミッキーマウス」の著作権は切れていないという事になります。つまり現時点で断言できることは、  
  
蒸気船ウィリーを題材にした作品を作ることができるが、ミッキーマウスなどのキャラクターは使わずオリジナルのキャラクターを使わなくてはいけない
  
という事になります。
  
  
## まとめ  
  
今回著作権について調べてみましたが、その内容は複雑で全てを把握できませんでした。特に国家間をまたぐ場合はその国の考え方次第でルールも全然違うようです。そのためよく調べ、必要なら専門家の意見を聞くようにしないと思わぬトラブルになるでしょう。  
今回も「ミッキーマウスの著作権が切れた」というニュースで安易に使用していたら権利を侵害したかもしれません。  
  
いずれにしろ、権利を守る意識は国際的にも浸透しているので制作者としてはルールを尊重し業務を行うべきと思いました。
  
  
#### 参考記事
  
・骨董通り法律事務所  
https://www.kottolaw.com/column/190913.html  
  
・公益社団法人著作権情報センター  
https://www.cric.or.jp/qa/hajime/hajime5.html  

mv.png

ミッキーマウスの著作権が切れたというニュースから「著作権」について調べてみました

## はじめに

2023 年 10 月に[Gmail のメール送信者ガイドライン](https://support.google.com/mail/answer/81126)がアップデートされました。 
2024 年 2 月から適用されるので、ギリギリになってしまいましたが、ガイドラインからどのような設定が必要なのかをまとめました。

## 対象となる送信者

個人用 Gmail アカウントに 1 日あたり 5,000 件以上のメールを送信している場合が対象になります。 
個人用 Gmail アカウントとは、末尾が @gmail.com または @googlemail.com のアカウントを指します。 
現在のガイドラインでは Google Workspace を利用しているアカウントは対象外ですが、今後のアップデートで Google Workspace を利用しているアカウントも対象になる可能性があるので、個人用 Gmail アカウントにメールを送信していなくても今のうちに設定しておくことをおすすめします。

### 5,000 件のカウント方法について

同じプライマリドメインから送信されたすべてのメールが対象になります。 
例えば、1 日あたり@example.com から 3,000 件、@sub.example.com から 2,500 件送信している場合、5,500 件とカウントされます。

## ガイドラインの適応スケジュール

[Google の FAQ](https://support.google.com/a/answer/14229414)によると、以下のスケジュールで順次対応するようです。

### 2024 年 2 月

要件を満たしていないメールのうち、一部のメールが一時的なエラーを受け取るようになります。

### 2024 年 4 月

要件を満たしていないメールの拒否を開始します。 
一部のメールから拒否をし始めて、徐々にその割合を増加します。

### 2024 年 6 月

全ての商用メール、プロモーションメールに、ワンクリックでの登録解除を実装する必要があります。

## 対応が必要な内容

今回のガイドラインで対応が必要な項目は下記の通りです。

- 送信ドメインで SPF と DKIM を設定する
- 送信元のドメイン、 IP アドレスに正引き、逆引き DNS レコードを設定する
- メールの送信に TLS 接続を使用する
- [Postmaster Tools](https://gmail.com/postmaster/)で報告される迷惑メール率を 0.1%未満に維持する
- [RFC 5322](https://datatracker.ietf.org/doc/html/rfc5322)に準拠する形式でメールを作成する
- DMARC を設定する
- メーリングリスト等、転送する場合は ARC ヘッダを追加する
- ヘッダ From ドメインは SPF、DKIM ドメインと一致させる
- ワンクリックでの配信停止に対応する

## DNS レコードについて

DNS（Domain Name System）とは、インターネット上でドメイン名と IP アドレスを紐づけるためのシステムです。 
今回のガイドラインでは、送信元ドメインの A レコードから送信元 IP アドレスを参照できるようにし（正引き）、逆に送信元 IP アドレスの PTR レコードから送信元ドメインを参照できるようにする（逆引き）必要があります。

### DNS レコードの例

「example.com」から IP アドレス「172.16.0.1」を参照（正引き）する設定は以下のように記述します。

```
example.com. IN A 172.16.0.1
```

IP アドレス「172.16.0.1」から「example.com」を参照（逆引き）する設定は以下のように記述します。

```
1.0.16.172.in-addr.arpa. IN PTR example.com
```

「1.0.16.172.in-addr.arpa.」の部分は、以下の手順で変換したものを記載します。

1. IP アドレスの各オクテットを逆順に並べる
 「172.16.0.1」の場合は「1.0.16.172」のようにします
2. IP アドレスが IPv4 形式の場合は、後ろに「.in-addr.arpa.」を記述する
 ※ IPv6 形式の場合は「.ip6.arpa.」を付与します

## SPF レコードについて

SPF（Sender Policy Framework）とは、電子メールの送信元ドメインが詐称されていないかを検査するための仕組みです。 
メールを受信する際に受信側は送信側の DNS ヘ SPF レコードを要求し、返答された SPF レコードが受信したメールの実際の送信元 IP アドレスと一致するかを確認します。 
2 つの IP アドレスが一致すれば認証が成功し、ドメインの管理者が意図した通りのメールサーバーから届けられた正しい送信元からのメールであることが証明できます。

### SPF レコードの例

「example.com」の IP アドレス「172.16.0.1」から送信されたメールアドレスのみを認証する場合は、以下のように記述します。

```
example.com. IN TXT "v=spf1 ip4:172.16.0.1 -all"
```

## DKIM レコードについて

DKIM（DomainKeys Identified Mail）とは、電子メールの送信元ドメインの認証技術の一種です。 
メール送信者が秘密鍵を使ってメールに署名し、受信者は送信元ドメインの公開鍵を使って、この署名の正当性を検証します。 
署名が正当であれば、そのメールは送信元ドメインの管理者が意図した通りのメールサーバーから届けられた正しい送信元からのメールであることが証明できます。

### DKIM レコードの例

DKIM レコードは下記のように記載します。 
セレクタ名は、任意の最大 63 文字の英数字を設定できます。 
ただし、セレクタ名はドメインに対して一意である必要があります。

```
[セレクタ名]._domainkey.example.com. IN TXT "v=DKIM1;k=rsa;p=[公開鍵]";
```

## DMARC レコードについて

DMARC（Domain-based Message Authentication, Reporting and Conformance）とは、電子メールの送信元ドメインの認証技術の一種であり、SPF や DKIM と併用することで、なりすましメール対策の強化が期待できます。 
DMARC の仕組みは、以下の 3 つに分けられます。

- 認証
 DMARC は、SPF と DKIM の認証結果を組み合わせて、メールの送信元ドメインの正当性を検証します
- ポリシー
 DMARC は、認証に失敗したメールをどのように処理するかを、ポリシーとして定義できます
- レポート
 DMARC は、認証結果を送信元ドメインに報告できます

ポリシーは、以下の 3 種類に分けられます。

- p=none
 認証に失敗したメールをすべて受信する
- p=quarantine
 認証に失敗したメールを、受信者から隔離する
- p=reject
 認証に失敗したメールを、受信者に拒否する

### DMARC レコードの例

「example.com」でポリシーを「none」、レポートの送り先を「dmarc-fb@example.com」に設定する場合、以下のように記述します。

今回のガイドラインでは、ポリシーは「none」でも問題ありません。

```
_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:dmarc-fb@example.com"
```

## ARC ヘッダについて

ARC（Authenticated Received Chain）とは、メールの認証状況を伝達し、なりすましメールや不正な改ざんを防ぐための技術です。 
SPF、DKIM、DMARC と連携して、メールの信頼性をさらに高める役割を果たします。 
メーリングリストやメールボックスプロバイダの自動転送機能などでメールを転送する場合、SPF や DKIM が失敗することがあるため、それを回避するために ARC ヘッダを追加する必要があります。

## TLS 接続について

TLS（Transport Layer Security）とは、インターネット上での通信を暗号化し、安全性を高めるための技術です。HTTPS や IMAP、POP3、SMTP などのプロトコルで使用され、通信内容の盗聴や改ざん、なりすましを防ぎます。

TLS 接続に対応しているメール配信システムを利用していれば問題ありません。

## ワンクリックでの配信停止について

今回のガイドラインでは、マーケティング目的のメールは 1 クリックでの配信停止の対応が必要です。 
具体的には、[RFC8058](https://datatracker.ietf.org/doc/html/rfc8058)に従い、以下をメールヘッダに含む必要があります。

配信停止リクエストを API 等で処理する場合は下記のように記述します。

```
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <https://example.com/unsubscribe>
```

配信停止リクエストを指定されたアドレスにメール形式で送信する場合は下記のように記述します。

```
List-Unsubscribe-Post: List-Unsubscribe=One-Click
List-Unsubscribe: <mailto:unsubscribe@example.com>
```

[Google の FAQ](https://support.google.com/a/answer/14229414)によると、メール本文内の配信停止リンクを設置するだけでは要件を満たさないのでご注意ください。

## 各種設定の確認方法

設定が正しく適用されているか確認するためのツールを紹介します。

### [dmarcian](https://dmarcian.com/)

SPF、DKIM、DMARC レコードを診断してくれるツールです。

### [mail-tester](https://www.mail-tester.com/)

メールを実際に分析し、送信ドメイン認証のほか、様々な観点で送信メールのチェックを行い、10 点満点で評価をしてくれます。

## まとめ

ガイドラインの要件を満たしていない場合、メールがブロックされたり、迷惑メールに振り分けられたりする可能性が高くなるので、なるべく早く対応することをおすすめします。 
また、[ガイドライン](https://support.google.com/a/answer/81126)は今後も更新される可能性があるため、定期的にチェックしましょう。 
また、Google だけでなく、[米国 yahoo でも同様のアナウンス](https://blog.postmaster.yahooinc.com/post/730172167494483968/more-secure-less-spam)がされていますので、利用している方はこちらも対応が必要です。

## 参考

- https://blastmail.jp/blog/spam/gmail-guideline-202402
- https://sendgrid.kke.co.jp/blog/?p=17213
- https://sendgrid.kke.co.jp/blog/?p=5190
- https://sendgrid.kke.co.jp/blog/?p=1822
- https://www.value-domain.com/media/spf-record/
- https://www.cloudflare.com/ja-jp/learning/dns/dns-records/dns-dkim-record/
- https://hp-shizuoka.jp/column/2016/10/7515/
- https://baremail.jp/blog/2022/06/16/2552/
- https://docs.oracle.com/ja-jp/iaas/Content/Email/Tasks/configure-dkim-using-the-console.htm

20240202_1.jpg

Gmail 送信のガイドラインへの適応

# Webページの画像と原稿制作について

このページとはパソコンとスマートフォンで見比べてご覧ください。  
  
 ![](https://cont.sterfield.co.jp/uploads/qr_reference_materials_72c097b82b.png) 

スターフィールドでは、ECショップのシステムを提供しています。ご利用いただいているお客様から、画像や原稿の作成方法についてよくお問い合わせをいただきます。
お問い合わせ内容を見ると、スターフィールドのシステムに限定したものだけでなく、Webサイトに掲載する素材全般に共通するポイントが多いようです。  
  
そこで、普段Web制作をされていない方がWebサイト用の画像や原稿を作成される際に、気を付けたいポイントについてご紹介します。
  
## 画像サイズの説明
  
Webサイトで画像を作る際には、画面幅とコンテンツ幅の横幅を意識し、どのように掲載されるのかを考えていきます。
  
画面幅は文字通り、画面全体の表示領域です。  
現在ご覧になっているこの記事ページで言うのであれば、画面左上のスターフィールドのロゴから画面右上のメニューアイコンまでの幅を指します。
  
一方、コンテンツ幅はそのページの記事が表示されている領域です。  
このページで言うなら、この記事のテキストが掲載されているエリアとその横側についているボタン類迄です。スマートフォン版で見た場合はこのボタン類はテキストの下に配置されています。  
一般的に、パソコンのWebページでは、画面幅は1500px以上、コンテンツ幅は最大1,000px～1,200px程度で作成されます。このページのコンテンツ幅は最大1,100pxです。  

そのため、パソコンの画面の端から端まで大きく表示される画像は、1500px～2000px程度の大きさで作成されることが多く、コンテンツ幅内に表示される画像は640px以上で作成されることが多くなります。  
  
スターフィールドの業務に関しては、ECショップに関わることが多いです。  
ECショップでは、商品画像やその解説に関わる画像が最も多く使用されます。また、商品は一般的に、図1のように一覧ページと詳細ページに分けて表示され、一覧で商品をクリックすると詳細ページに移動されることが一般的です。
  
図1  
 ![](https://cont.sterfield.co.jp/uploads/sample_pc_fc38f80361.png) 

  
このように画面をレイアウトする場合、写真のサイズは、実際には640pxよりも小さくなります。
具体的には、一覧画面では200px～300px程度、詳細画面でも500px程度が一般的です。  
  
近年のWebサイトは、パソコンだけでなくスマートフォンでも閲覧されることを想定して作られるケースが増えています。そのため、パソコンでもスマートフォンでも快適に閲覧できるよう、画像のサイズを調整して作成することが多いのです。スターフィールドのシステムでも同様です。
  
では、ECショップを例にした場合、スマートフォンでは図2のようなレイアウトが多いと思います。
  
図2  
 ![](https://cont.sterfield.co.jp/uploads/sample_sp_9aebe8495f.png) 
  
パソコンと比べると、スマートフォンの画面は小さくなっています。また、多くのWebサイトでは、画面幅とコンテンツ幅が同じになっており、詳細ページでは、画面の端から端まで商品画像が表示されることが多くあります。そのため、スマートフォンの画面の端から端まで表示しても問題ないサイズの画像を用意する必要があるのです。

スマートフォンの画面サイズは機種によって異なりますが、端から端まで表示する場合は、640pxに設定されていることが多いようです。また、デジタル画像は拡大すると画質が落ちるものの、縮小すると画質が劣化しにくい性質があります。この性質を利用して、画像は640pxで作成し、必要に応じて縮小して表示する仕組みでWebサイトを作成することが多いです。

そのため、お客様から制作者側に提供する画像は、トップページなどの大きな画像を除き、コンテンツ内に表示させるものであれば、640px以上のサイズのものを提供いただくことで作成や更新がスムーズに進みます。

## 文字つきの画像データを作成する際の注意
  
画像の中に文字を入れる場合、画像のサイズが画面幅に応じて変化するため、文字のサイズも変化することに注意が必要です。
実際に図3をご覧ください。

  
図3  
 ![](https://cont.sterfield.co.jp/uploads/sample_1500_8193643d79.png) 

  
図3は、パソコンの画面幅に合わせて横幅1500pxで作成されています。このサイズは、パソコンの画面を端から端まで表示させることを想定しています。
  
しかし、このブログのテキストの表示領域は最大825pxなので、パソコンで見た場合は55%に縮小されて表示されてしまいます。スマートフォンで見た場合はさらに縮小されます。


このように、画像のサイズが画面幅に応じて変化すると、画像内に記載された文字も一緒に縮小されてしまいます。そのため、文字の視認性が著しく低下してしまいます。図3の画像内で一番小さい文字は、14ptで作成されていますが、縮小されたことで読みにくくなっていることが確認できます。
  
Webページのテキストは、一般的に14px～16pxのサイズで作成されます。ptとpxは異なる単位ですが、14ptは約18px相当になります。そのため、文字を読みやすくするためには、14pt以上の大きさで作成することを意識しましょう。
  
また、パソコンの画面幅に合わせて画像を作成すると、スマートフォンではさらに文字の視認性が悪くなります。そのため、このような大きな画像については、図4のようにスマートフォン版専用の画像を用意して、パソコンとスマートフォンで異なる画像を表示するように設定します。

図4    
 ![](https://cont.sterfield.co.jp/uploads/sapmle_640_b27b695332.png) 

  
ネットショップの場合、商品画像に「新発売」などの数文字のフレーズを入れる分には、さほど問題になるケースは少ないでしょう。しかし、商品の説明について、成分の解説や商品ができるまでの過程をグラフィカルにまとめた資料をお客様が作成する場合は、注意が必要です。
  
画面幅に応じて画像のサイズも変化し、記載されている文字も合わせてサイズが変化することを想定せずに画像を作成すると、パソコンやスマートフォンで文字が読みにくくなる傾向にあります。また、デザインによっては、パソコン版とスマートフォン版で別々の画像を作成する必要があり、手間が増えることもあります。
  
## テキストについて
  
お客様から寄せられるお問い合わせの中には、テキストに関するご質問や修正依頼もあります。
  
Webページのテキストサイズは、一般的に14px～16pxを基準に設定します。デザインを行う際は、このサイズでテキストを作成して、テキスト量と画像バランスを考慮してデザインします。 
  
しかし、画像サイズは閲覧する端末によって変化するため、Webページとして実際に表示した際に、想定したバランスが崩れてしまいやすいです。特に、普段、紙媒体のデザインを手がける方々からは、この点に関する指摘が多く寄せられます。
  
よく依頼される指摘の一例として、文字の改行に関するものがあります。しかし、テキストは画像とは異なり、制作者が完璧にコントロールすることが難しいため、意図しない改行が発生することがあります。
  
ディスプレイ性能やOS、ブラウザ、閲覧者の端末の設定などによって、文字サイズや文字間、行間などに微小な差異が生じます。これらの要因が重なり、制作者が意図しない改行に繋がります。
  
そのため、例えば、制作者の開発環境で最適に見えるように調整しても、別の環境で閲覧したら意図しない改行が生ずることがあります。
  
このように、Webページのテキストは、制作者の意図した通りに表示されない可能性があることを前提として、テキストと画像の配分はある程度ずれること、細かな改行指定はしない、などのことを想定して原稿を作る必要があります。
  
## まとめ
Webページは、実際に作ってみないと分からないことがたくさんあります。そのため、制作者も依頼者も、想定外のことが起こることがあります。

そのようなことが起こった場合は、ぜひご相談ください。ご要望をお聞きし、最適な解決策をご提案します。

Company

Our Solutions

Support

News

Blog

カテゴリーから探す

年別から見る

PHP正規表現

合わせて読みたい

2024/03/01

2024/02/22

2024/02/02

2024/01/19

2024/04/19

2024/04/05

2024/03/15

2024/03/01

2024/02/22

2024/02/02

2024/01/19

2024/04/19

2024/04/05

2024/03/15

2024/03/01

2024/02/22

2024/02/02

2024/01/19

–	範囲
^	文字列の先頭
$	文字列の末尾
a-z	小文字の半角英文字
A-Z	大文字の半角英文字
0-9	数字
^0-9	数字以外
*	0回以上の連続する文字
+	1回以上の連続する文字
?	0または1回だけの文字
{n}?	n回の連続する文字
{n,}?	n回以上の連続する文字
{n, m}?	n回以上、m回以下の連続する文字