第1 Web章

Webアクセシビリティとはアクセシビリティとは

図1-1-1

ユーザビリティとアクセシビリティの関係性『見えにくい、読みにくい「困った！」を解決するデザイン』P.23 より転載
（一部改変）

1.2

1.2

Web アクセシビリティとはユーザビリティある状況での使いやすさ

Web におけるアクセシビリティを考えるうえでは、まず Web 自体の特徴使いやすさを理解する必要があります。誤解を恐れずにいえば、Web はアクセシビリティのために存在するメディアなのです。そう言い切れるほどに、ほかの使えるメディアにはない「アクセスを可能にするしくみ」が Web には備わっています。そのしくみによって、あらゆる状況で利用できる可能性が開かれてい使えないます。
アクセシビリティ

使える状況の幅広さ

Web にあるだけで圧倒的にアクセシブルアクセシビリティは利用しやすさ？
アクセシビリティは「利用しやすさ」と翻訳されることもあり、辞書を引くとそのように記載されている場合もあります。しかし、この訳は誤解を生みがちです。「利用しやすさ」という語感からは「利用できることを暗黙の前提として、そのうえで使いやすいかどうかである」というイメージを持つ

そもそも、Web にコンテンツやサービスがあることは、それだけでかなりアクセシブルな状態です。むしろ、Web を通じてコンテンツやサービスを提供することは、このアクセシビリティという恩恵を得たいと考えた結果といえます。
図 1-2-1 は、Web がそもそも持っているアクセシビリティの側面を層に分けたものです。この図でいえば、Web にコンテンツを載せて公開するだ人が一定数存在すると考えます。そして、この語感が「改善したほうがよいけで、堅牢・発見・携帯までがカバーできます。Web では、あらゆるデバけど、使えないわけではないから優先度は高くない」という解釈につながっ

イスからインターネットにアクセスでき、URL によってコンテンツを一意ているように思えるのです。
しかし、利用しやすさが「ゼロ」である、つまりまったく使えないことも多くあります。本書の題材である Web アプリケーションでも、そもそも UI（User Interface）
上にあるボタンに気付くことすらできない、キーボードフォ

図1-2-1

アクセシビリティのレイヤー
改変：加工できる、再利用できる

hackability

共有：誰かに渡せる、共有できる

shareability

題が当たり前のように潜んでいます。いずれも致命的なものであり、バグ

使用：知覚・理解・操作、目的達成

usabilityと称しても差し支えないでしょう。

携帯：持ち運べる、呼び出せる

portability

発見：特定できる、探し出せる

ﬁndability

堅牢：存在が維持される

robustnessーカスが見えずにまったく操作できない、マウスオーバーすると要素が消滅したように見えて操作できない……といった、まったく使えなくなる問

アクセシビリティを高める活動とは、こうしたことが起きないように、「まず利用自体は可能である」という状況を増やしていくこと、そのための選択肢を用意していくことです。

45

第1 Web章

Webアクセシビリティと「障害」

アクセシビリティとは

図1-3-12

滞留コントロール

クリックが難しい場合、マウスポインタを一定時間、同じ場所にとどめておくとアクションが実行されるという操作方法がある。図は macOS の滞留
コントロールの操作状態

図1-3-143 音声コントロール

図1-3-18

画面内のラベルや番号を発話することで選択した
り、グリッドで区切られた領域の番号を発話してマウス相当の操作を実施したりできる。テキストの入力や修正も音声で行える。図は macOS の音声
コントロールの操作状態（項目番号）

操作の選択と実行をすべてスイッチのオン／オフだけで行える。大きいスイッチ、弱い力でも押せるスイッチ、息で操作する呼気スイッチ、筋肉の動きを検知する筋電位スイッチなど、さまざまなものがある。写真は、わずかな筋肉の動きで作動するピエゾセンサー（圧電素子）と、指先の僅かな動きで作動するエアバッグセンサー（空圧）の 2 種類が付くピエゾニューマティックセンサスイッチ
写真提供：パシフィックサプライ株式会社

図1-3-191.3

センサー式のスイッチmacOS のスイッチコントロール（ホーム）スイッチコントロールのメニューから、マウスポインタ操作モードを選択する

図1-3-14

音声コントロール

図1-3-15

Bluetooth接続のスイッチ

図1-3-20

macOS の音声コントロールの操作状態（グリッド） 写真はブルー2
写真提供：パシフィックサプライ株式会社

macOS のスイッチコントロール（ポインタ）
ポインタをどう動かすかを選ぶ。ここでは移動してクリックを選択する

図1-3-21

macOS のスイッチコントロール（グライドカーソル）
X 座標・Y 座標をクレーンゲームのように指定すると、マウスポインタが移動してクリックが実行される

図1-3-16

柔らかいスイッチ

写真はピロースイッチ
写真提供：テクノツール株式会社

16

図1-3-17

指で挟んで押せるスイッチ

写真はフィンガースイッチ
写真提供：テクノツール株式会社

17

第2 Web章

基礎となるマシンリーダブルを理解する

アクセシビリティの基礎

良い例：HTML標準のチェックボックス<label><input type="checkbox" checked="checked" />同意する</label>input 要素は type 属性ごとに異なる役割を持ちます。type="checkbox"

は、チェックボックスの役割を持っています。また label 要素によって「同2.1

HTML はセマンティクスを持っている
読み上げられるボタンの実装例では、button 要素を使用しました。button要素はボタンという役割を持っています。これは HTML のネイティブセマンティクスと呼ばれるものです。
基本的には HTML の要素を適切に使用することでセマンティクスを実装できます。ただし HTML の要素や属性には限りがあります。ドキュメント意する」のコンテンツと関連付けられ、「同意する」という名前を持ちます。

を共有する目的から始まった HTML の語彙は、アプリケーション独特のセこれにより同意するかしないかの真偽値を入力するチェックボックスであマンティクスが不足しています。たとえばタブなどのインタラクションをることがわかります。

含む役割や、要素が展開されているかどうかという状態です。

またチェックボックスがチェックされていると、真偽値を持つ checked 属性に checked の値が入り、チェックされている状態であることを示します。

HTML のセマンティクスを補完するWAI-ARIA

ためしにスクリーンリーダーでチェックボックスを読み上げてみると、これらのセマンティクスを補完するのが WAI-ARIA という仕様です。WAI-ラベルの「同意する」、状態として「チェックされている」、そして役割の「チARIA には主に役割を補完する WAI-ARIA ロールと、状態やプロパティを補ェックボックス」が読み上げられます（図 2-1-4）。

完する WAI-ARIA ステートおよびプロパティがあります。

現在の値がわからなければ、操作ができたとしてもチェックできたかど

もともと WAI-ARIA は、HTML にないセマンティクスを補完するためにうかがわからず、操作の目的は果たせません。何かを入力する UI には「名誕生しました。たとえばタブ UI は、HTML だけではタブ UI であること、タ前」と「役割」に加えて「状態」が必要です。

ブが選択されていること、タブのコンテンツが隠されているかどうかなどのセマンティクスを表現できませんでしたが、WAI-ARIA を使うと表現するHTML のセマンティクスと、それを補完するWAI-ARIAことが可能です（図 2-1-5）。

さて先の例で、セマンティクスを実装することがアクセシビリティにとって大事だと述べました。たとえば要素に「ボタン」というセマンティクスを持たせることによって、ユーザーはその要素が実行可能であることがわ

図2-1-5

WAI-ARIAを用いて実装されたタブ UI のタブ
Google Chrome の開発者ツールによる表示（以下同）

かりますし、「チェックされている」という状態を持たせることによって、入力されているかどうかがわかります。
図2-1-462「同意する」
ラベルがあるチェックボックスのスクリーンリーダーによる読み上げ

63

第3

章 フォームの改善

制約の検証とエラー［事例 2］多様なユーザーへエラーを通知する方法を検討していない

よくある事例で課題を知る

多様なユーザーへエラーを通知する方法が検討されていないと、ユーザ［事例 1］エラーの発生箇所とエラーメッセージの関係がわかりづらい

エラーの発生箇所とエラーメッセージの関係がわかりづらい場合があります。

ーによってはエラーの発生やエラーの発生箇所を理解できない恐れがあります。フォームを送信したときに、エラーが発生した箇所の近くに単にエラーを表示しただけでは、エラーが適切に通知されているとはいえません

たとえば、エラーの発生箇所とエラーメッセージが離れて配置されてい（図 3-3-2）。

ることがあります。特に画面を拡大しているユーザーは、エラーの発生箇

たとえば、スクリーンリーダーを利用するユーザーはエラーが発生した所とエラーメッセージを同時に視認できないことがあるため、エラーがどことに気付けない可能性があります。スクリーンリーダーは基本的にフォこで発生しているのかわかりにくくなります（図 3-3-1）。

ーカスしている箇所を読み上げます。送信ボタンを押してクライアントエほかにも、エラーの発生箇所とエラーメッセージの関係が適切にマークラーが発生したときには送信ボタンにフォーカスしています。したがってアップされていない場合もあります。たとえば、以下ではエラーが適切に送信ボタンとは別の箇所にエラーメッセージが表示されても、そのままでマークアップされておらず、エラーメッセージがフォームコントロールにはエラーメッセージが読み上げられません。

関連付けられていません。

また、画面を拡大しているユーザーもエラーが発生したことに気付けな

悪い例：エラーが適切にマークアップされていないフォームコントロール<label for="username"><span>ユーザー名（半角英数字で入力）</span></label><span>エラー：すでに同じユーザー名が登録されています。</span><input type="text" id="username">

い可能性があります。画面を拡大していて画面の一部しか視認できていな
いと、エラーメッセージが画面におさまっていなければエラーメッセージを見落としてしまうからです。
［事例 3］エラーの修正方法がわかりにくい

エラーが関連付けられるようにマークアップされていないと、スクリーエラーの修正方法がわかりにくいと、ユーザーはエラーを通知されてもンリーダーはエラーの発生箇所にたどり着いてもエラーメッセージを読みエラーを修正できません。わかりにくいエラーメッセージには典型的なパ上げません。スクリーンリーダーを利用しているユーザーは、エラーが発ターンがあります。

生していることがわからない恐れがあります。
図3-3-13.3

図3-3-2多様なユーザーへエラーが通知されない

エラーの発生箇所とエラーメッセージが離れて配置されている?
?

142

143

第4 UI
章

色とコントラストデザインの改善

グラフの例も、色以外に形状を利用して改善します。折れ線グラフであ背景色のコントラスト比を 4.5：1 以上にすることを求めています（図 4-1-9）。

れば、線を破線にする、マーカーの形状を変えるなどにより、色に依存せ「色のコントラスト（高度）」注 4 では、文字色とより発展的な達成基準 1.4.6

4.1

ずに情報を提供できます（図 4-1-7）。
そのほか、凡例とデータの対応を直接線で結ぶ方法があります。また形状で示す以外にも、「赤」と「緑」の組み合わせを避けるなど、さまざまな色覚でも見分けやすい配色を検討することも大事です（図 4-1-8）。
色のみに依存することに問題があるだけで、ユーザーが情報の分類を理

注4

https://www.w3.org/WAI/WCAG21/Understanding/contrast-enhanced.html
日本語訳：https://waic.jp/docs/WCAG21/Understanding/contrast-enhanced.html

図4-1-8折れ線グラフの改善例
凡例とデータを線で結び、配色も見分けやすくしている

解するのを助けたり、イメージを喚起したりと、色が強力なツールであることは間違いありません。情報提供を色のみに依存しないようにしたうえで、色をうまく活用することを目指しましょう。

C型［事例 2 の改善❶］文字のコントラスト比を改善する
注3
WCAG 2.1 の達成基準 1.4.3「色のコントラスト（最低限）」
では、文字色と注3

https://www.w3.org/WAI/WCAG21/Understanding/contrast-minimum.html
日本語訳：https://waic.jp/docs/WCAG21/Understanding/contrast-minimum.html

図4-1-7折れ線グラフの改善例
データと判例の紐付けが色だけでなく、線のスタイルやマーカーの形状でもされている

C型

P型

図4-1-9

3：1、4.5：1、7：1 のコントラスト比のサンプル
白の背景に黒もしくはグレーの文字で示されている

P型

184

185

第5

章 複雑な UI パターンの改善

モーダルダイアログ

5.1

5.1

「モーダル」とは、一時的にシステムが通常と違うモードになって、限定的な操作だけを受け付ける状態を指します。通常の Web ページは「モードモーダルダイアログレス」で、ページ内のいろいろな部分を行き来できるのに対し、「モーダル」なダイアログはそのダイアログという「モード」にユーザーを閉じ込めてし本節ではモーダルダイアログを取り上げます。モーダルダイアログまたまいます。

は単にモーダルと呼ばれる機能は、ユーザーへの説明や確認、フォームのモーダルダイアログが表示されると、ユーザーはその外のコンテンツを表示など、モダンな Web アプリケーションには必ずといってよいほど存在操作できなくなります。表示されている間はユーザーのできることが限定します。

されてしまいますが、特定の順序に沿って情報を確認したり操作したりす

モーダルダイアログは、以下のような特徴を持ちます。

る必要があるときには有効な手段です。

・ページの描画よりあとに、ユーザーの操作やアプリケーションのロジックによって表示される
・ほかのコンテンツの上に被さるように表示され、表示されている間はモーダルダイアログ内の要素のみ操作できる・モーダルダイアログ内での操作によって非表示になる（閉じられる）ことがある

Web ページにおけるモーダルダイアログは多くの場合、ネイティブアプ
く けい

リケーションのダイアログを模した小さなウィンドウ状の矩形領域として表示されます。半透明の要素で全画面を覆い、その上に重ねて表示することもあります（図 5-1-1）。

モーダルダイアログの例と問題点モーダルダイアログはページ内のほかの要素に被せて表示するため、しばしば body 要素の最後に要素を差し込む形で実装されます。body 直下に配置することで、親要素のスタイルの影響を受けないようにしつつ、最後に挿入することで同じ z-index を持つ要素が存在しても最前面に表示されます。

以下のコードは、モーダルダイアログを React によって実装した例です。のリ表示すると「ダイアログを開く」ボタンと「技術評論社の Web サイト」

ンクが置かれ、モーダルダイアログには「ダイアログを閉じる」ボタンが配置されています（図 5-1-2）。

図5-1-1

モーダルダイアログ
背後のコンテンツは半透明の要素で隠されている

悪い例：アクセシビリティを考慮せず作られたモーダルダイアログのコンポーネント（TypeScript）

import { useEffect, useState, useRef } from 'react';
import { createPortal } from 'react-dom';

図5-1-2268

モーダルダイアログの表示例269

第5章 複雑な UI パターンの改善

5.4
シンプルなツールチップ

シンプルなツールチップ

5.4

チップが表示されるタイミングを制御したり、ツールチップの見た目を変えたり、多機能化したりすることはできません。
そこで、多くの Web サイトやサービスでは、ツールチップのような見た目と挙動をするもの、すなわち特定の場所にマウスオーバーすることでそ

本節ではツールチップについて紹介します。本節では、特定の場所にマの付近に表示されるものを独自に実装しています。たいていの場合、ツーウスオーバーすることによって、マウスポインタの付近に表示されるもの

ルチップの対象となる要素の位置の近くに、CSS で position: absolute を全般をツールチップと呼びます。
「対象となる要素へのマウスオーバーによって何かを表示する」という単純な機能ひとつでも、アクセシビリティに関して多くの問題を生みます。
たとえば、ツールチップの内容を読めるようにするには、画面を拡大しての使用や、キーボードでの操作、スマートフォンやタブレットでの使用にそれぞれ別々の工夫がいります。
すべての問題をひとつの方法で解決できる定石はありません。作ろうとしているものについて起き得る問題をきちんと認識し、ひとつひとつどう対処していくのかを考えなければなりません。
本節では、内容がテキストのみの「シンプルな」ツールチップについて紹介します。内部にリンクなどのインタラクティブな要素や複雑な構造を含んでいたり、自然な表示になるように DOM 上の離れた箇所に挿入されたりしている、「リッチな」ツールチップについては次節で扱います。ツールチップの要件によっては次節の内容まで考慮に入れて検討する必要があります。あわせて参照してください。

シンプルなツールチップの例と問題点
最も簡単なツールチップの実装は、title 属性を使用するものでしょう

指定して配置しています。

以下は React でツールチップを独自実装した例です（表示例は図 5-4-2）。
この実装には、次のような問題があります。
・画面拡大時にツールチップを読めない・キーボード操作ではツールチップを読めない
・スマートフォンやタブレットではツールチップに気が付かない・スクリーンリーダーではツールチップに気が付かない

本節では順番に改善方法を紹介します。
悪い例：アクセシビリティを考慮せず作られたツールチップのコンポーネント（TypeScript）

import { useState } from 'react';
const TooltipSample = () => {// ツールチップの表示状態を保持するstate
const [isTooltipVisible, setTooltipVisible] = useState(false);

return <span className="withTooltip"><a href="https://gihyo.jp/"// mouseenterでツールチップを表示し、mouseleaveで非表示にする
onMouseEnter={() => setTooltipVisible(true)}

図5-4-1

title 属性によるツールチップ

図5-4-2

独自実装のツールチップの表示例（表示例は図 5-4-1）。
例：リンクにtitle属性でツールチップを付加<a href="https://gihyo.jp/" title="この本を出版している会社のWebサイト">技術評論社のWebサイト</a>title 属性によるツールチップは簡単に実装できます注 11。しかし、ツール注 11 HTML の仕様には、title 属性への依存は推奨しないと記載しています。この記載の主旨は本節の内容とも重なるので、詳細はのちほど解説します。

302303

第6章 デザインシステムとアクセシビリティ

6.1

デザインシステムとは

図6-1-1

6.1

デザイン原則の例
SmartHR Design System のデザイン原則
https://smarthr.design/foundation/

デザインシステムとはデザインシステムは、広い意味でのデザインの一貫性を保つための、ドキュメントや部品、ガイドライン、制作プロセスなどの総称です。
組織の中で一貫性のあるデザインを実現するには、そのデザインがどのようなルールに基づいて、どのように作られるべきかを明文化することが重要です。本章では、これらを体系的に整備したものをデザインシステムと呼びます。

デザインシステムの構成
デザインシステムには多くの場合、以下のものが含まれています。
・デザイン原則
・スタイルガイド・パターンライブラリ

デザイン原則には、製品やそれを作る組織が重視する価値観、判断基準

図6-1-2

スタイルガイドの例
GOV.UK Design System の Colour

https://design-system.service.gov.uk/styles/colour/が定義されます（図 6-1-1）。製品のデザインとして考慮し、目指すもののほか、組織によってはブランドとして表現したいもの（ブランドアイデンティティ）なども含まれてきます。そして、その原則をもとにして、スタイルガイドやパターンライブラリなどが策定されます。
スタイルガイドには、製品が使用するアイコンやタイポグラフィ、カラーパレット、文言のガイドラインなどが含まれます（図6-1-2）。デザイン原則やブランドアイデンティティに沿って、どのようなものを組み合わせてデザインを作っていけばよいのかを示します。カラーパレットなどは、デザイントークンと呼ばれる形で CSS の変数として定義されることもしばしばあります。
パターンライブラリは、デザインを構成するデザイン言語をパターン化し、ライブラリとして再利用可能にしたものです（図 6-1-3）。製品が提供する機能であったり、ユーザーへの見せ方であったりと、パターンの粒度はさまざまです。より細かい粒度で UI コンポーネントのライブラリとなっ362363

第7章 アクセシビリティの組織導入

自身の考えを社内で発信するいった話を続けられることが、アクセシビリティをおもしろいと感じる原動の状態です。会社公認の活動にしていくには、アウトプットに取り組む必力となり、長い目で見るとデザインやエンジニアリングに役立ちます。

要があります。

7.4

こうしたサロンはランチやおやつタイムと合わせて実施されています。freee
では週 1 回、ヤクルトが届く午後の時間に合わせて開催していました注 7。

社内向けにアクセシビリティの記事を書く
社内向け Wiki など注 8 があれば記事を書いてみましょう。

7.4

内容は何でもかまいません。輪読会のメモや、自分なりのスクリーンリーダーの使い方など、前節での活動を実施するたびに、その記録や気付い自身の考えを社内で発信するたことのメモなどを投稿するのが手軽です。そのほか、既存のアクセシビリティ関係の資料の要約や、イベント参加レポートなども有用です。

情報を取得し、アクセシビリティに対する感覚がつかめたら、次はアウ書いておけば誰かの役に立つかもしれないと一瞬でも思えたら、少しずトプットです。現時点ではまだ興味を持った人たちによる、一種の「部活」つでも投稿します。アウトプットを重ねることで、自分が取り組んでいる理由や、フォーカスしたいと思っている領域などの整理が進みます。

注7

本書執筆時点（2022 年 12 月）
では COVID-19 の影響により、オンライン開催に移行しています。

きちんとしたものを書こうとすると、どんどん時間が過ぎます。あなたがあえてハードルの低い記事を投げ込んでいくことで、ほかの人もアクセ

図7-3-3

サロンの開催を伝えるホワイトボード
堅苦しくならないように手書きでゆるい感じを演出し「誰でも参加 OKとも書き添えているお菓子もあるよ」

シビリティにまつわる話を投稿してもよさそうな空気を作れます。短くても拙くても投稿を少しずつ積み上げましょう。

社内の発表会でアクセシビリティの話をする
この時点では、アクセシビリティに関する活動はまだ限られた人にしか伝わっていません。あなたの活動にリアクションしてくれる人たちが何人か出てきていても、それはおそらく「もともとアクセシビリティにある程度関心があった人」なのです。
人間の認知のリソースは限られており、自分とあまり関係ないと思ったものはスルーします。そこに割り込むには、相手がアクセスしてくれるのを待つのではなく、こちらからプレゼンテーションしていく必要があるのです。社内でのライトニングトークや取り組み発表の機会があれば、積極的に手を挙げましょう（図 7-4-1）。
プレゼンテーションの内容は「取り組みの現状報告」でよいでしょう。今注8400

Scrapbox、Confluence、Qiita Team、esa、kibela、Notion などです。

401

第8章 アクセシブルな UI 設計の原理を導く

8.3

アンチパターンと対策❶ ——1 画面に多くの状態を持つ

8.3

キーボードのみで操作する場合も同様です。マウス操作と違い、キーボー

アンチパターンと対策❶ ——1 画面に多くの状態を持つ

ド操作では画面内の領域をまたぐような非連続な移動ができず、Tab キーによる連続的なフォーカス移動でしか操作対象の切り替えが行えないからです。

操作対象が散らばり、状態把握が難しくなる

画面を大きく拡大しているときやスクリーンリーダー利用時も、この「散らばった操作対象の行き来」には同様の手間がかかります。現在マウスポイ

多くの Web アプリケーションのレイアウトは以下の構成になっており、ンタやスクリーンリーダーカーソルがある場所しか認識できない注 6 ので、1 画面内に操作対象が散らばり、多数の状態の組み合わせが存在します（図行き来をするためには毎回ポインタやカーソルを動かして操作対象を探す

8-3-1）。

ことになります。さらに、推定と記憶に頼らざるを得ないという問題も生・ヘッダ、上や左のナビゲーションバー、メインエリアの上部・中央・下部、サブエリア、モーダルダイアログといったさまざまなエリアがある
・エリアごとに、ボタンやリンク、フォームコントロールといったインタラクテ
ィブ要素がある・インタラクティブ要素の操作結果として、ナビゲーションの選択状態、表示内容の切り替え状態、編集モードなどが存在する

マウス操作が困難な場合、多くの操作対象が画面内に散らばるほどに負担も増えます。どこかを選んで、何かを見て、スクロールして、何かを切り替えて、また戻って……という手順自体に大きなコストがかかります。
図8-3-1

アプリケーション画面の例
さまざまなナビゲーションとリンクとボタンが複雑に組み合わさっているじます。操作結果が視界の外に反映されて気付けなかったり、視界から外れた現在位置表示の状態をあとで思い出す必要が生じたりするからです。
多くの操作対象が画面内に散らばり、状態把握が難しい Web アプリケーションが増えている理由としては、以下の点が考えられます。
・切り替えウィジェットの濫用・複数ペイン構成の濫用
・モーダルダイアログの濫用

ここからは、この 3 点について詳しく考察していきます。

切り替えウィジェットの濫用
アンチパターン

切り替えウィジェットは、画面上に存在する要素を一時的に隠しておき、要求があったときに表示する UI パターンです。ユーザーとのインタラクシ
ョンによって内容が変化することを表現するためによく用いられます。一
般的な UI パターンですが、1 画面に要素を押し込みすぎて複雑になってしまった「切り替えウィジェットの使いすぎ」といえる状況も見かけるようになりました。
例としては、アコーディオン型のフォームが挙げられます（図 8-3-2）。

EC サイトでの購入フローなどにおいて、全体がアコーディオン形式になっ注6

460

aria-live 属性を使うなどして、変化を明示的に伝えている場合は除きます。

461