『マクベス』のノック音はどう字幕になる？ 舞台に必要な「バリアフリー字幕」とは
『マクベス』第2幕第2場。ダンカンを殺した直後、マクベス夫人は短剣を持って去ります。そこで台本に現れるのが、きわめて短いト書きです。
Knock within.
マクベスはすぐに “Whence is that knocking?” と反応し、続けて “How is ’t with me when every noise appalls me?” と口にします。ト書きは「音が起きた」ことを示し、マクベスの台詞はその音への反応を示しています。同じ一瞬を構成する情報ですが、実際に人物が発話しているのは後者だけです。
バリアフリー字幕を準備する側から見ると、この二つは同じ種類の情報ではありません。ト書きをそのまま字幕に置き換えるのではなく、実際の上演で何が聞こえ、どう見えるのかを確認したうえで考える必要があります。
この音を聞き取れない観客には、何を文字で伝えるべきか。
それが、ここでいうバリアフリー字幕の役割です。
SurtitleLive Editor には今回、手動で選べる独立した行種別として 「アクセシビリティ字幕」 が加わりました。重要な音の出来事を、台詞やト書きに無理に分類せず、「観客に届くべき情報」として扱えます。本番では通常の字幕 cue と同じように進み、たとえば次のように角括弧付きで表示されます。
[ドアをノックする音]
Editor 上では小さな追加に見えますが、扱っているのはもっと大きな問題です。舞台に存在する異なる種類の情報を、システムの中でどう区別するかという問題です。
バリアフリー字幕とは？
字幕というと、まず「人物が話した内容を文字にするもの」と考えがちです。しかし、それだけではありません。
W3C の Web Accessibility Initiative は captions を、発話だけでなく、内容を理解するために必要な非言語の音声情報も含む同期テキストとして説明しています。効果音、音楽、笑い声、話者の識別、声がどこから聞こえるかといった情報も対象になり得ます。W3C の captions 解説。
舞台では、この違いがさらに分かりやすくなります。英国の Stagetext は、劇場の captioner が台本をもとに準備し、必要に応じて効果音、人物のアクセント、舞台外の音などを加えると説明しています。また、主に外国語公演の翻訳を目的とする surtitles と、ろう・難聴の観客のための captions を区別し、後者には人物名や舞台外の音などのアクセス情報が含まれ得るとしています。Stagetext の Theatre Captioning と captions / subtitles / surtitles の説明。
つまり、ト書きとバリアフリー字幕は同じ舞台上の出来事から生まれることがあっても、同じ情報ではありません。ト書きは制作側に「何を起こすか」を伝えます。字幕は観客に「聞こえなければ失われる重要な音は何か」を伝えます。
台本は出発点になれますが、最終的な文言は実際の上演の音と演出に照らして確認する必要があります。
なお、W3C、DCMP、Stagetext が定めているのは captioning の内容や実務であり、すべてのソフトウェアに特定の内部名称やデータモデルを要求しているわけではありません。「アクセシビリティ字幕」は SurtitleLive がこの手動行種別に付けた製品上の名称です。 別のツールなら、タグ、スタイル、cue class、metadata などで同じ区別を表現できます。
SurtitleLive の 登場人物 / ト書き / アクセシビリティ字幕 というモデルの意味は、情報の種類に応じて本番中の挙動を変えられることにあります。これは製品アーキテクチャ上の選択であって、業界全体に必須の分類体系ではありません。
舞台で対象になり得るのは、ノック、警報、ガラスの割れる音、舞台外の群衆、電話、銃声、あるいは場面の意味を変える音楽の変化などです。
大切なのは「音があるか」ではありません。
その音が情報を運んでいるか。
マクベスが怯える姿だけを見るのと、何が彼を怯えさせたのかという音の情報も同時に受け取るのとでは、観客が得るドラマの因果関係が違います。実際の演出でドアへのノックだと明確に分かるなら、たとえば：
[ドアをノックする音]
マクベスが凍りつく。
といった字幕が考えられます。
captions、subtitles、surtitles の違いについては、劇場字幕の用語ガイドも参照してください。
材料の多くは、すでに台本の中にある
バリアフリー字幕を作るために、劇作家が別の台本を書かなければならないわけではありません。
劇台本には、台詞以外の情報がもともと大量に含まれています。人物の出入り、ノック、電話、銃声、音楽、争い、舞台外の声、群衆のざわめきなどは、ト書きとして記されることがあります。
シェイクスピアのト書きは非常に簡潔で、Knock within. や A noise within. のような例があります。現代の台本では、音響や技術的な出来事がより細かく書かれることも珍しくありません。
ただし、ここには重要な区別があります。
ト書きがあることと、観客向けのバリアフリー字幕が完成していることは同じではありません。
ト書きはまず制作情報です。俳優、演出、舞台監督、デザイナーなどに、何が起こるべきかを伝えます。
バリアフリー字幕は観客情報です。問いは別です。
この瞬間を十分に聞き取れない観客が、場面を追うために何を知る必要があるか。
同じ舞台上の出来事から、二つの違う文章が生まれることがあります。出発点は同じでも、読者も目的も異なります。
ト書きは材料になっても、完成字幕とは限らない
もう一度 Macbeth に戻ります。
台本の指示は：
Knock within.
です。
これは「実際の音を確認すべき場所」を示す手がかりであって、そのまま使える字幕ではありません。
Knock within. から分かるのは、見えている舞台の外側からノックが聞こえるということです。しかし、その上演で観客が実際にどのような音を聞くのかまでは決めていません。
音響や演出によって「ドア」が明確なら [ドアをノックする音] が合うかもしれません。実際に速いノックなら [速いノック音] が適切かもしれません。確実なのが「舞台外から聞こえる」ことだけなら [舞台外からノック音] のほうが安全です。そこまで確かでなければ、さらに中立的な文言にすべきです。
正しい字幕は、ト書きを必要以上に具体化することからではなく、実際の公演を見て聞くことから生まれます。
字幕は「その音が象徴するもの」ではなく、「観客が実際に聞く音」を記述するべきです。Stagetext は短く事実に基づき、作品世界の中にとどまる音の説明を勧めています。DCMP も、画面から音源が明らかでない場合には必要に応じて音源を示し、理解や鑑賞に必要な効果音を caption に含めるよう勧めています。Stagetext Digital Subtitling Guidelines と DCMP の効果音ガイド。
そのため、[ドアをノックする音] はドアが実際の演出で明確な場合に限って適切です。[速いノック音] はリズムという情報を追加するので、本当に速い場合だけ使うべきです。[舞台外からノック音] は、それ以上の場所を作り足さずに舞台外の音であることを示せます。
一方、[外から切迫したノック音] は「切迫している」「外から」という二つの情報を加えています。Knock within. だけでは、そのどちらも確定しません。さらに [マクベスの罪悪感が彼を追い詰める] となれば、もはや音の説明ではなく作品解釈です。
ト書きが答えるのは：
台本上、何が起きるのか。
バリアフリー字幕が答えるのは：
観客が理解するために何を知る必要があるのか。
だから、すべてのト書きをそのまま観客画面に流すことは、ほとんどの場合よいアクセシビリティ設計ではありません。観客に見せる必要のないト書きも多く、逆に「この音は実際の上演を確認して字幕化を検討すべき」と知らせる材料になるト書きもあります。
『ハムレット』にも同じ構造がある
『ハムレット』第4幕第5場では、クローディアスとガートルードがポローニアスの死とレアティーズの帰還による政治的危機を話しているところで、“A noise within.” という指示が入ります。ガートルードが音について尋ね、使者が飛び込んできて、レアティーズと群衆が押し入ろうとしていると告げます。群衆が扉に近づくにつれて騒ぎは再び聞こえます。MIT Shakespeare の Hamlet 第4幕第5場。
聞こえる観客は、説明より先に脅威を感じるかもしれません。最初に騒ぎが聞こえ、次に人物が反応し、その後で説明が入るからです。
実際の公演で、遠くの騒ぎから群衆が迫ってくる音へと変化するなら、字幕はたとえば：
[群衆のざわめき]
その後：
[群衆が近づく]
となるかもしれません。
どちらも “A noise within.” の直訳である必要はありません。その公演で観客が実際に体験している、意味のある音を記述することが重要です。
SurtitleLive では、なぜ以前扱いにくかったのか
今回の更新以前、Editor には「アクセシビリティ字幕」という独立した行種別がありませんでした。
観客向けの音情報を追加したい制作には、実質的に二つの不完全な選択肢がありました。
一つは台詞として扱うことです。そうすれば観客には届きますが、データ上は不正確です。誰も [ノック音] と発話しているわけではありません。長い台本では、音情報が台詞や翻訳の中に混ざってしまいます。
もう一つはト書きとして扱うことです。原文には近いように見えますが、別の問題があります。オペレーター画面の ト書きをスキップ（Skip Stage Directions） は、通常の「前へ／戻る」操作でト書き cue を飛ばします。
アクセシビリティ字幕をト書きとして分類していると、一緒に飛ばされる可能性があります。
操作側から見れば一つの cue を飛ばしただけでも、字幕を頼りにしている観客にとっては、次の台詞や行動の意味を説明する音情報そのものかもしれません。
三つの情報を別々のまま扱える
SurtitleLive Editor では現在、次の三つを明確に分けられます。
| 行種別 | 表すもの | 観客向け？ | 通常の前へ／戻る操作 |
|---|---|---|---|
| 登場人物 | 発話された台詞 | はい | cue 列に残る |
| ト書き | 台本・制作上の指示 | 通常はいいえ | スキップされる |
| アクセシビリティ字幕 | 観客に必要な重要な非言語音情報 | はい | cue 列に残る |
たとえば Macbeth の一瞬を：
ト書き
マクベス夫人、短剣を持って退場。
アクセシビリティ字幕
ノック音
登場人物 — マクベス
Whence is that knocking?
と整理できます。
三つは同じ劇的瞬間に関係していますが、情報の種類は別です。退場は制作指示。ノックは、実際の公演を確認したうえで観客向け字幕にするか判断する音の出来事。マクベスの言葉は台詞です。
この三分類は SurtitleLive の製品データモデルであり、captioning 標準が要求する業界共通の分類ではありません。実務上の価値は、意味によって動作を変えられることです。通常操作でト書きを飛ばしても、アクセシビリティ字幕は飛ばさない、という挙動が可能になります。他のソフトウェアはタグや metadata など別の方法で同じ区別を実現できます。
別設定の 登場人物名を非表示（Hide Character Names） は、名前を表示するかどうかだけを制御します。アクセシビリティ字幕を cue 列に残すかどうかとは別です。
Editor の画面録画には、例示用の制作に合わせた音の説明が含まれています。独立した行種別を示すための例であり、Knock within. をどの公演でも同じ言葉で字幕化すべきだという意味ではありません。
ト書きを飛ばしても、バリアフリー字幕は飛ばさない
新しい行種別の最も重要な実務上の効果です。
アクセシビリティ字幕は観客向け cue であり、制作内部だけのト書きではありません。通常の「前へ／戻る」操作では、ト書きをスキップするとト書きは飛ばされますが、アクセシビリティ字幕は cue 列に残り、観客へ送ることができます。
特定の cue に直接ジャンプする操作は別のオペレーター操作であり、この通常ナビゲーションのルールとは別です。
これにより、制作上の指示を飛ばしながら、ろう・難聴の観客向けに用意した音情報を誤って飛ばすことを防げます。
角括弧は表示形式であり、保存内容そのものではない
アクセシビリティ字幕は角括弧付きで表示されます。
[ノック音]
[遠くで雷鳴]
[音楽が突然止まる]
角括弧は音情報を示す一般的な captioning の慣例ですが、すべてのソフトウェアに必須の規則ではありません。DCMP の Captioning Key は、理解や鑑賞に必要な効果音を角括弧で記述する方法を推奨しています。DCMP のガイド。
SurtitleLive は今回、この表示処理を統一しました。Editor には ノック音 とだけ保存し、シミュレーション、投影、観客画面で一組の角括弧を付けて表示できます。
すでに角括弧が入力されている場合は、二重には付けません。
内容と表示上の慣例を分けて管理できます。
すべてのト書きをバリアフリー字幕にする必要はない
新しい行種別は「ト書きをすべて観客に表示せよ」という意味ではありません。
たとえば「マクベスがテーブルへ歩く」という動きが舞台上ではっきり見えるなら、[マクベスがテーブルへ歩く] と表示することは通常、音の captioning ではありません。それは視覚情報を説明する別のアクセシビリティ実践に近づきます。
音楽も同じです。「静かな音楽が続く」という指示が単なる雰囲気なら、必ずしも字幕は必要ありません。しかし音楽が突然始まる、あるいは止まることが場面の意味を変えるなら、その変化は重要な情報かもしれません。
よりよい問いは：
この音が聞こえなければ、その瞬間を理解するのに必要な情報を失うか。
これは確立された captioning の考え方とも一致します。DCMP は、聞こえるものすべてを書き起こすのではなく、理解や鑑賞に必要な効果音を caption に含めることを勧めています。DCMP のガイド。
SurtitleLive は最終的な編集判断を代行しない
「アクセシビリティ字幕」は 手動 の行種別です。
SurtitleLive が Knock within. を見て、自動的に「これは字幕にすべきだ」と判断するわけではありません。これは意図的です。ト書きは、実際の上演音を確認すべき場所を示す手がかりであって、定型文を自動生成する命令ではありません。
同じト書きでも、公演によってまったく違う音になります。“A noise within” が舞台裏の数人の口論になることもあれば、群衆が扉を破る音になることもあります。音楽も、一つの演出では雰囲気にすぎず、別の演出では重要な物語上の cue かもしれません。
ソフトウェアは、演出家と音響デザイナーが最終的に何を作ったかを知りません。
制作チームは知っています。
したがって SurtitleLive の役割は、アクセシビリティを「推測する」ことではなく、チームが判断したあとに、その判断を正しく記録できる場所を用意することです。
一つの行が明確に：
これはト書き。
あるいは：
これは観客に届けるべき音情報。
と意味できるようになりました。
両者を同じ分類に押し込む必要はありません。
小さな行種別が、より大きな概念上の問題を直す
舞台台本には昔から、台詞、動き、音、制作情報が書かれてきました。しかしト書きを書くことと、その音が持つ情報をろう・難聴の観客にどう届けるかを考えることは、同じ作業ではありません。
バリアフリー字幕は、そこに観客の視点を加えます。
制作側は改めて問い直します。
どの音は単なる雰囲気か。
どの音は物語を進めるのか。
どの音が人物の反応を説明するのか。
情報が「聞こえるだけ」のままだと意味が欠ける瞬間はどこか。
Macbeth のノックは何百年も前から台本にあります。足りなかったのはト書きではありません。
アクセシビリティの仕事は：
Knock within.
を固定の字幕に直訳することではありません。
上演を確認し、その音が観客に必要な情報を運んでいる場合に、実際の音を正確に記述するという編集工程を加えることです。公演によっては [ドアをノックする音]、本当に速ければ [速いノック音]、舞台外から聞こえることだけが確かなら [舞台外からノック音] が適切かもしれません。文言はト書きだけから推測せず、実際の上演に根拠を置くべきです。
SurtitleLive Editor には、その判断を保存するための独立した場所ができました。
バリアフリー字幕の材料の多くは、すでに劇台本の中にあります。
新機能は Knock within. を作り直すためのものではありません。
制作チームが、別の問いに答えるための明確な場所を用意します。
あのノックが聞こえない観客には、何を表示するべきか。
参考資料
要点
- アクセシビリティ字幕は、台詞ではない重要な音の情報を観客が読める形で伝えます。
- ト書きは上演を作るための指示です。観客向けの字幕では、実際に聞こえる音に合わせた表現が必要なことがあります。
- 通常の「次へ／前へ」操作ではト書きがスキップされますが、アクセシビリティ字幕はキューの順番に残ります。
- 表示時の角括弧はSurtitleLiveが付けます。どの音を伝えるかは制作チームが判断します。
よくある質問
劇場のアクセシビリティ字幕とは何ですか？
上演の理解に必要な音情報を文字にしたものです。重要な効果音、警報、音楽の変化、舞台外の出来事などを含み、特に聴覚に障害のある観客に役立ちます。
台詞字幕とは何が違いますか？
台詞字幕は主に登場人物が話した内容を示します。アクセシビリティ字幕は、誰も発話していない重要な音も伝えます。
なぜト書きをそのまま表示しないのですか？
ト書きは主に上演を作るための文章だからです。観客には不要なものも多く、必要な場合でも、その舞台で実際に聞こえる内容に合わせて書き直す方が自然です。
ト書きをスキップすると、アクセシビリティ字幕も飛ばされますか？
いいえ。通常の「次へ／前へ」操作ではト書きがスキップされますが、アクセシビリティ字幕はキューの順番に残り、観客に送ることができます。特定のキューへの直接ジャンプは別の操作です。
用語集
- アクセシビリティ字幕: 台詞以外も含め、意味のある音情報を観客に伝えるための文字。
- ト書き: 主に上演を作るための指示として台本に記された文章。
- 観客向け情報: 音では届かない可能性のある情報を観客に伝える文字。
- 非言語の音情報: ノック、警報、音楽の変化、舞台外の物音など、言葉ではない音の情報。
- 手動の行種別: ソフトウェアが推測するのではなく、制作チームが行に指定する分類。