WEBサイトChrome 155の機能一覧に、隠したiframeの音を止める指定が載った。何も書かなければ従来どおり ── 自社の埋め込みを棚卸しして、隠した状態で音が鳴らないか確認する13項目（2026年10月時点）
Chrome 155の機能一覧に、隠したiframeの音を止める指定が載った。何も書かなければ従来どおり ── 自社の埋め込みを棚卸しして、隠した状態で音が鳴らないか確認する13項目（2026年10月時点）
目次
01 何が起きたか — Chrome 155の機能一覧に、隠したiframeの音を止める指定が載った。ただし、何も書かなければ今までどおりである
ChromeStatusとベータ版の記事に書かれた内容
Chromeの機能の状況を公開しているChromeStatusに、「Pause media playback on not-visible iframes」（訳: 見えていないiframeでのメディア再生を一時停止する）という項目がある。2026年10月7日に、この項目をAPIの応答で読んだ。項目の最終更新は、応答によると2026年9月9日である（時刻のタイムゾーンは確かめていない）。項目の概要は、次のように書いている。
"While hidden, attempts made by the embedded iframe to render audible media will be blocked. When the frame is shown again the prohibitions should be lifted."
（訳: 隠れている間は、埋め込まれたiframeが音の出るメディアを出そうとしても、止められる。フレームが再び表示されたときは、その禁止は解かれるはずである。）
Chrome for Developersの「Chrome 155 beta」の記事（2026年9月16日付）にも、同じ項目が載っている。名前は、media-playback-while-not-visibleという「権限ポリシー」である。権限ポリシーとは、ページや埋め込みに、使える機能を許すか止めるかを書く仕組みのことである。
「隠れている」とは、どの状態か
ChromeStatusは、隠れている状態を3つ挙げている。displayが「none」、visibilityが「hidden」、面積が0（幅か高さが0）の3つである。モーダルを閉じたとき、タブを切り替えたとき、アコーディオンをたたんだときに、中のiframeがこの状態になる作りのサイトがある。iframeを消さずに隠すだけだと、中の動画や広告の音が鳴り続けることがある。この指定は、その音を止めるためのものである。
「何も書かなければ今までどおり」という点
この指定は、埋め込む側のページが、自分から書いたときだけ働く。ChromeStatusの「有効にする条件」の欄は、次のとおりである。
"Developers need to opt-in by setting "allow" property of an iframe."
（訳: 開発者は、iframeの「allow」の指定によって、自分から有効にする必要がある。）
仕様の草案（WICGの文書）も、何も書かないときの扱いを、次のように書いている。
"The default allowlist for this policy is "*", meaning that documents are allowed to play media while not rendered unless the policy is explicitly disabled."
（訳: このポリシーの既定の許可リストは「*」で、ポリシーが明示的に無効にされない限り、ドキュメントは描画されていない間もメディアを再生できる、という意味である。）
つまり、Chrome 155に入ったことで、何も書いていないサイトの動きが変わる、とは書かれていない。変わるのは、埋め込む側が「隠れたら音を止める」と書けるようになった点である。
安定版はいつか。公式の書き方が3か所で少し違う
Chromiumのリリースの予定表（2026年10月7日に取得）は、Chrome 155の安定版の日を2026年10月6日と書いている。ChromeStatusの155の機能一覧は、この項目を「Enabled by default」（訳: 既定で有効）に入れている。一方、この項目だけを返すAPIの応答は、状態の表示を「In developer trial (Behind a flag)」（訳: 開発者トライアル中（フラグの向こう側））のままにし、出荷の欄に155と書いている。
Chrome Releasesの「Stable Channel Update for Desktop」は、2026年10月6日付で、155の安定版を出したと書いている。2026年10月7日に開いて確かめた。
"The Stable channel has been updated to 155.0.8059.39/.40 for Windows and Mac and 155.0.8059.39 to Linux which will roll out over the coming days/weeks."
（訳: 安定版が、WindowsとMacでは155.0.8059.39/.40に、Linuxでは155.0.8059.39に更新された。今後の数日から数週間かけて、順次展開される。）
つまり、155の安定版は、10月6日に出ている。ただし、展開は順次で、すべての利用者に届いたわけではない。この告知は、media-playback-while-not-visibleの指定が既定で有効かどうかを、書いていない。Chrome 155の機能ごとのリリースノートのページは、2026年10月7日に開こうとしたところ、見つからなかった（404）。この記事は、155の機能一覧に載っていることまでを書き、「安定版で既定で有効になった」とは書かない。
02 なぜ・背景 — iframeを消さずに隠したいが、音だけは止めたい、という場面のため
解決しようとした問題
この仕組みを提案した説明文書（Microsoftの開発者が書き、WICGに移された文書）は、問題を次のように書いている。
"These applications may not want to unload the entire iframe when it's not rendered since it could generate user-perceptible performance and experience issues when showing the media content again."
（訳: こうしたアプリは、iframeが描画されていないときにiframe全体を読み込み解除したくないことがある。再び表示したときに、利用者に分かる性能や体験の問題が出うるからである。）
iframeを消せば音は止まる。しかし、もう一度表示するときに、読み込み直す待ち時間が出る。仕様の草案は、フォームの入力内容のような、利用者が残っていると思っている状態が失われうる、とも書いている。
すでにあった別の案との違い
WHATWGの最初の投稿（2024年3月18日）は、描画されていないiframeのJavaScriptの実行を止める「execution-while-not-rendered」という別の案があると書いている。この提案は、JavaScriptは止めずに、音だけを止めることを目的にしている。
広告の例
説明文書は、使う場面の例として、見えない間は音を出させたくない第三者の部品と、広告を挙げている。広告の例は、次のとおりである。
"A website which loads video advertisements and wants to guarantee the user doesn’t hear the ad when not visible."
（訳: 動画広告を読み込むサイトで、見えていないときに利用者がその広告を聞くことがないと保証したい場合。）
広告や埋め込みの提供元を数える作業は、当サイトの記事「Chrome 153のリリースノートで、広告とクッキーに関わるAPI 5つが「廃止予定」になった ── 自社のタグと埋め込みの提供元に確認する14項目（2026年10月時点）」で扱った。この記事は、その一覧に「隠れたときに音が出るか」という列を足す作業にあたる。
03 用語 — 読み違えやすい言葉を先にそろえる
権限ポリシーと、allow属性・見出し
用語
権限ポリシー（Permissions Policy）：ページや埋め込みが、どの機能を使えるかを書く仕組みである。書き方は2つある。1つは、サーバーの応答の見出し（Permissions-Policyという名前のHTTPヘッダー）。もう1つは、iframeタグのallow属性である。iframeに書く形は、allow="media-playback-while-not-visible 'none'"のように、機能の名前と許可の範囲を並べる。「'none'」は、どの場所にも許さない、という意味である。
埋め込む側と、埋め込まれる側
用語
埋め込む側（embedder）：iframeを自分のページに置くページである。この指定を書けるのは、この側である。埋め込まれる側：iframeの中身を作っている動画・広告・チャットなどの提供元である。提供元が自分の判断で、この指定を外すことはできない。
音の出る仕組みは、2つある
用語
HTMLMediaElement：videoタグとaudioタグの、ブラウザの中での名前である。AudioContext：JavaScriptで音を作ったり流したりする仕組み（Web Audio）の入口である。ChromeStatusは、この指定が働く対象を、この2つと書いている。
「描画されていない」の意味
仕様の草案は、「描画されていない」を「not being rendered」という言葉で書いている。iframe自身がdisplay: noneのときが、これにあたる。iframeを入れた親の要素がdisplay: noneのとき（モーダルの外側の箱が隠れているときなど）も同じ扱いになるかは、この記事では確かめていない。推測では、ブラウザの画面に箱が作られない状態を指すので、含まれると考えられる。
04 型別 — 自社の埋め込みがどれに当たり、何を、どの順で確かめるか
🅰 型1 — 隠したり出したりする埋め込みを持つサイト
モーダル、タブ、アコーディオン、カルーセル、チャットの最小化などで、iframeを消さずに隠しているサイトである。中に動画・音声・広告が入っているなら、隠れたあとも音が鳴る可能性がある。この指定が役に立つのは、この型である。
🅰 型2 — 埋め込みを隠さない、または持たないサイト
iframeを置いていないサイトや、置いていても常に表示しているだけで、音も出ないサイトである。この指定の影響は小さいと考えられる。ただし、小さいか大きいかは、手順2で数えるまで分からない。
🅰 型3 — 提供元のタグが、iframeを作るサイト
自分のHTMLにはiframeが無いのに、シェアのボタン・認証・計測のタグなどが、読み込まれたあとにiframeを作る場合がある。この場合、iframeのタグに自分でallow属性を書けない。書ける場所は、サーバーの応答の見出しか、提供元への依頼になる。当サイトの実例は、07章に書く。
この指定が対象にするもの
公式文書から読み取れる範囲を、次の表にまとめる。
| 対象 | 隠れたときの動き | 書かれている場所・注意 |
|---|---|---|
| メディア要素（videoとaudio） | 再生中なら一時停止の扱いになる。隠れている間にplay()を呼ぶと、失敗で返る | 仕様の草案の3.1節。再開は自動ではない |
| AudioContext | 再生中なら「interrupted」の状態になる。隠れている間に作ると「suspended」で始まる | 仕様の草案の3.2節。表示に戻ると、中断が終わる |
| 自動再生 | 隠れている間は、自動再生の対象にならない | 仕様の草案の3.3節。表示されているときの自動再生には影響しない |
| 音声合成（読み上げ） | 説明文書は、失敗で返ると書いている | 2026年10月7日に開いた仕様の草案には、この節が見つからなかった |
ChromeStatusは、現在の仕様の範囲を、次のように書いている。
"Currently the feature is spec'ed to work with HTMLMediaElements and Web Audio AudioContexts."
（訳: 現時点では、この機能は、HTMLMediaElementとWeb AudioのAudioContextに働くものとして、仕様に書かれている。）
メディア要素は、隠れている間に再生できず、表示に戻っても自動では始まらない
仕様の草案は、メディア要素の再生を、次のように書いている。
"Note: Calling play() on mediaElement while it is not allowed to play will return a promise rejected with a "NotAllowedError" DOMException."
（訳: 注: 再生が許されていないメディア要素でplay()を呼ぶと、「NotAllowedError」のDOMExceptionで拒否されたpromiseが返る。）
音を出す部品を自分で書いているサイトは、play()が失敗したときの表示（再生ボタンを出すなど）を持っているかを、確かめる必要がある。再生中に隠れた場合について、説明文書は、次のように書いている。
"Callers should treat this scenario as if the user had paused media playback."
（訳: 呼び出す側は、この場合を、利用者がメディア再生を一時停止した場合と同じに扱うべきである。）
つまり、メディア要素は、表示に戻っただけでは再生が始まらないと読める。一方、AudioContextは、表示に戻ると中断が終わる。MicrosoftのエンジニアのテストページにもAudioContextが自動で再開すると書かれている。ただし、提供元の部品が、中断のあとにどう動くかは、部品ごとに違う。
🅱 公式が書いていないこと
次のことは、確かめた範囲の公式文書には書かれていない。この記事も、断定しない。
- 10月6日に出たChrome 155の安定版で、この指定が既定で働くか、フラグが要るか（ChromeStatusの状態の表示は、一覧とAPIの応答で食い違っている）。
- Chrome以外のブラウザで、いつ使えるようになるか（FirefoxとSafariの欄は、肯定的と表明なしである）。
- チャットの通知音のような、隠れた状態で鳴らす音が、止められるかどうか（仕様の読みでは止まりうるが、確かめていない）。
この記事が確かめていないこと
実際のChrome 155で、この指定が働くかは、確かめていない。この記事を書いた環境のChromeは、154.0.8037.99だった。7章の確認は、iframeの数を数えただけで、音が止まるところまでは見ていない。
🅲 手順1 — 自社のコードの中の、iframeを探す
最初に、自社が管理しているテンプレートとJavaScriptのフォルダを、エディタのフォルダ内検索で調べる。探すのは2つである。1つは、HTMLに書かれた<iframe。もう1つは、JavaScriptで作っている形（createElement("iframe")や、createElement('iframe')）である。引用符は、両方の形で探す。見つかったものは、動画・音声・広告・チャット・予約や決済・地図・そのほかに分けて書く。
🅲 手順2 — 実際の画面で、iframeを数える
コードの検索では、提供元のタグが作るiframeは見つからない。ページを開いたあとの画面で数える。代表のページを3つ開き、開発者ツールのConsoleに、次を貼る。
console.table([...document.querySelectorAll('iframe')].map(f => ({
id: f.id,
src: f.src.slice(0, 60),
allow: f.getAttribute('allow'),
display: getComputedStyle(f).display,
visibility: getComputedStyle(f).visibility,
width: f.offsetWidth,
height: f.offsetHeight
})))このコードを、4つのiframe（allow属性つき、display: none、visibility: hidden、幅と高さを0と書いたもの）を置いた手元のページで動かすと、4つ分の行が出た。ただし、幅と高さを0と書いたものは、枠線の分で4と出た。面積が0かは、枠線も含めて見る。
🅲 手順3 — 隠れる前と隠れた後で、音を聞く
音の出る埋め込みを持つページで、埋め込みを表示したまま音を出し、そのまま隠す操作（モーダルを閉じる・タブを切り替える）をして、音が続くかを聞く。この確認は、スピーカーかイヤホンで、耳で聞くしかない。結果は「鳴る」「鳴らない」「確かめられない」で書く。
🅲 手順4 — 見出しとallow属性を確かめ、確認用の環境で試す
まず、自社のサーバーの応答の見出しに、すでに権限ポリシーがあるかを調べる。
curl -sI https://example.com/ | grep -i permissions-policy次に、確認用の環境（本番ではない環境）で、音の出る埋め込みを1つ選び、allow属性にmedia-playback-while-not-visible 'none'を足す。Chrome 155以降で隠して、音が止まるか、表示に戻したときに音がどうなるかを見る。MDNは、allow属性と見出しの関係を、次のように書いている。
"A Permissions Policy specified by the allow attribute implements a further restriction on top of the policy specified in the Permissions-Policy header. It doesn't replace it."
（訳: allow属性で指定した権限ポリシーは、Permissions-Policy見出しで指定したポリシーの上に、さらに制限を足す。置き換えるものではない。）
🅲 手順5 — 提供元に、問い合わせる
手順3で音が鳴った埋め込みの提供元には、次のような文面で問い合わせる。
Chrome 155で、埋め込み側が、隠れたiframeの音を止められるようになります
（allow属性のmedia-playback-while-not-visible）。貴社の部品について、
1. 隠れた状態で音を出す場面はありますか（通知音など）。
2. 音が止められた場合、部品は壊れず、表示に戻すと正しく続きますか。
3. 当社の側で、設定の変更や作業が必要ですか。返事は、提供元の名前、問い合わせた日、返事の日、要点を、一覧に書き足す。
05 自分のサイトで確認するチェックリスト
下の13項目は、1項目5分ほどでできる作業である。項目1〜3が手順1、項目4〜6が手順2、項目7が手順3、項目8〜10が手順4、項目11と12が手順5、項目13が全体の記録に対応している。チェックの状態はブラウザの中にだけ保存され、サーバーには送られない。
- 自社のテンプレートとJavaScriptのフォルダで「<iframe」を検索し、見つかった件数をファイルごとに書く
- 同じフォルダで、「createElement」と「iframe」が同じ行にあるものを、引用符が2重の形と1重の形の両方で検索し、件数を書く
- 項目1と2で見つかった埋め込みを、「動画」「音声」「広告」「チャット」「予約・決済」「地図」「そのほか」のどれかに分けて書く
- 代表のページを3つ、Chromeで開き、開発者ツールのConsoleに手順2のコードを貼って、iframeの件数をページごとに書く
- 項目4の結果から、displayがnoneのもの、visibilityがhiddenのもの、幅か高さが4以下のものを数えて、件数を書く
- 項目5で隠れていたiframeごとに、どの操作（モーダル・タブ・アコーディオン・最小化）で表示に切り替わるかを書く
- 音の出る埋め込みを1つ選び、表示したまま音を出して隠し、音が続くかを耳で聞いて「鳴る」「鳴らない」「確かめられない」で書く
- ターミナルで「curl -sI」に自社のトップページのアドレスを付けて実行し、「permissions-policy」の行があるかを「ある」「ない」で書く
- 確認用の環境で、音の出る埋め込み1つのallow属性に「media-playback-while-not-visible 'none'」を足し、Chrome 155以降で隠して、音が止まるかを「止まる」「止まらない」で書く
- 項目9で隠したiframeを表示に戻し、音が自動で戻るか、再生ボタンを押す必要があるかを書く
- 項目7で音が鳴った埋め込みの提供元の名前を書き出し、それぞれの問い合わせ先のアドレスを1つずつ書く
- 項目11の提供元のうち、3つに手順5の文面を送り、送った日と、返事の有無を書く
- 結果を日付つきで1つのファイルに保存し、Chrome 155のリリースノートが公開されたかを確かめる日を、カレンダーに1つ登録する
時間が限られているときは、項目1・4・5・7の4つだけでも、概要は分かる。iframeが1つも見つからず、隠す操作も無いサイトなら、項目4で0件になった時点で、確認は終わりに近い。
06 代替・他の選択肢 — 音が出ている場合に、公式の文書から読み取れる道
iframeごとに、allow属性で止める
自分のHTMLにiframeのタグがある場合の、いちばん小さな変更である。説明文書の例は、<iframe src="https://foo.media.com" allow="media-playback-while-not-visible 'none'"></iframe>という形である。説明文書は、この書き方で、そのiframeの中にさらに埋め込まれたiframeも、隠れている間は音を出せなくなる、と書いている。
応答の見出しで、ページ全体に止める
提供元のタグがiframeを作る型3のサイトでは、タグの側を触れない。仕様の草案は、ページ全体で止める書き方を、見出しの形で示している。
Permissions-Policy: media-playback-while-not-visible=()草案は、この書き方で、トップのドキュメントと、埋め込まれたすべてのiframeに、この指定が及ぶと書いている。ただし、一括で止めるので、隠れた状態で音を出す前提の部品（チャットの通知音など）も、止まりうる。
提供元の部品が、止められた状態で壊れないかは、手順4の確認用の環境で、先に試す。
iframeを消す、または提供元の止める手段を使う
この指定が使えないブラウザでは、これまでの方法が残る。iframeを取り除く方法は、説明文書が書くとおり、表示に戻すときの待ち時間と、状態の消失を伴う。提供元が止める手段を用意している場合もあるが、提供元ごとに違い、この記事は確かめていない。
実務のヒント
音の出る埋め込みを、モーダルやタブの中に置いているサイトは、まず「閉じたときに音が止まるか」を、耳で確かめる。止まっているなら、この指定を足す必要は小さい。止まっていないなら、allow属性を足した版を、確認用の環境で先に試す。
確認の手がかりになる、当サイトの無料ツール
公開ページの基本情報を一覧で見たいときは、当サイトの無料ツール🔧 WEBサイト総合分析・レポートツールが使える。cssやjsのファイルを読んで確かめたいときは、🔧 cssファイル、jsファイルのソースチェックツールが手がかりになる。どちらも、iframeの音が止まるかを判定するツールではない。
注意
広告の埋め込みは、「表示されている間だけ音が出る」ことが、掲載の条件や計測の定義に関わる場合がある。広告の提供元との契約や、計測の取り決めに関わるときは、広告の担当者に相談する。
埋め込みの高さを中身に合わせる指定は、当サイトの記事「Chrome 154で、iframeの高さを中身に合わせる指定が入った。ただし親のCSSと子のmetaの2か所が要る ── 自社の埋め込みを「両側を持つもの」と「提供元に頼むもの」に分ける13項目（2026年10月時点）」で扱った。この記事は、その内容を繰り返さない。
07 当サイトで確かめたこと
6ページを、実際のChromeで開いて、iframeを数えた
2026年10月7日15時51分に、手元のChrome（バージョン154.0.8037.99・画面を出さない動作）で、当サイトの6ページを開き、読み込みが終わったあとの画面の中身を取り出した。開いたのは、トップ、ブログの1本、無料ツールの1つ、サイト紹介、記事の1本、記事の一覧である。この方法の確認として、MicrosoftのエンジニアのテストページをChromeで開いたところ、iframeが3つと数えられた。3つとも、allow属性にmedia-playback-while-not-visible 'none'が書かれていた。
結果は、次のとおりである。6ページの画面にあるiframeは、合わせて7つだった。トップは0、無料ツールが3つ、ほかの4ページが1つずつである。videoタグとaudioタグは、6ページとも0だった。
見つかった7つの中身
7つのうち5つは、シェアのボタンの提供元（AddToAny）が作る「Utility Frame」だった。幅1ピクセル・高さ1ピクセルで、displayがnoneになっていた。無料ツールのページには、そのほかに、reCAPTCHAの枠が1つと、提供元を特定できなかった、displayがnoneのiframeが1つあった。つまり、displayがnoneで隠れているiframeは、7つのうち6つである。
AddToAnyのUtility Frameが開くページ（717文字の短いHTML）を取得して、音に関わる語を探したところ、videoタグ、audioタグ、AudioContext、new Audio、play()、speechSynthesisは、どれも0件だった。
コードの側でも、音に関わる語を探した
同じ日の15時50分に、同じ6ページのHTMLと、読み込まれるスクリプト（延べ102本）、直接書かれたスクリプト（延べ50本）を取得し、コメントの中を除いて探した。スクリプトは、すべて取得できた。探したのは、iframe・video・audioのタグ、AudioContext、new Audio、speechSynthesis、play()、allow属性、この指定の名前、音声や動画のファイルの拡張子、YouTubeとVimeoのアドレスである。
結果は、iframeを作る呼び出し（createElement）が、Googleのタグ、AddToAnyのスクリプト、無料ツールのページのGoogleのログイン用の部品にあったこと以外、音に関わる語は0件だった。YouTubeのアドレスの文字が、Googleのタグの中に5件あった（動画の計測の設定に使う記述と推測しているが、確かめていない）。応答の見出しに、権限ポリシーは無かった。
この結果から言えることと、言えないこと
言えるのは、確かめた6ページで、隠れているiframeは6つあるが、音を出す仕組みを示す語は、取得できた範囲では見つからなかったことである。言えないことは、3つある。1つ目は、reCAPTCHAのような、操作したあとに別の枠を読み込む部品は、取得しただけでは分からないこと。2つ目は、確かめていないページが残っていること。3つ目は、手元のChromeが154で、この指定を有効にして見てはいないため、音が止まる場面は確かめていないことである。
「0件」を、「無い」と読まないことは、当サイトの記事「「リンク切れ0本」を確認して、安心しかけた ── 自社ブログの内部リンク、59.2%はnoindexへの飛び先だった」で書いた。この記事の「0件」も、見つけられなかったという意味にとどめた。
08 このテーマの、これまで
この指定をめぐる、日付つきの記録
| 日付・版 | 出来事 |
|---|---|
| 2024年3月18日 | WHATWGに、提案の最初の投稿が出た（当時の名前は「media-playback-while-not-rendered」で、displayがnoneの場合だけを書いていた） |
| 2024年5月29日 | ChromeStatusに、この項目が作られた |
| 2024年10月3日・4日 | MozillaとWebKitに、立場の表明の依頼が出た |
| 2025年4月23日 | W3CのTAGに、設計審査の依頼が出た |
| Chrome 137〜142 | オリジントライアル（その後145までの延長が作られた） |
| 2026年9月16日 | Chrome 155 betaの記事に、この項目が載った |
| 2026年10月6日 | Chrome 155の安定版が出た（Chrome Releasesの告知・順次展開）。機能ごとのリリースノートは、10月7日に開けなかった |
名前は、提案の途中で変わっている。ChromeStatusの「ウェブ開発者の意見」の欄は、「not-rendered」から「not-visible」へ名前を変え、面積が0の場合も含めるように、意見に対応した、と書いている。
当サイトの、関連する過去の記事
- 外から取った画面は、目当ての画面とは限らない ── 遮断の画面を404と読み、引用符の違いでnoindexを「無い」と読みかけた — 外から取った画面の種類。
- 「吹き出しが出ていない」と写った ── 壊れていたのは、作ったものではなく写し方だった。自動のスクリーンショットが読者の画面と違う3つ（動き・幅・枚数） — 自動の画面と読者の画面の違い。
- 「リンク切れ0本」を確認して、安心しかけた ── 自社ブログの内部リンク、59.2%はnoindexへの飛び先だった — 「0本」を確認する前に確かめること。
- 出力は在った。だから誰も測らなかった ── datePublished・og:type・用語ハイライト・sitemapで見つけた4つの「値だけ違う」穴 — 出力があるのに測っていなかった穴。
- 「リンク切れ0本」も「200が返る」も、まだ2段目だった ── 番号が変わるサイトで見つけた、リンクの3段目のずれ — リンクの確認の段階。
現在の貴方のIPアドレス
このサイトで書いている人
