9:16のインタラクティブ短編ドラマは横向き映像の切り抜きでは作れない:ショット、字幕、選択ボタン、テンポを一緒に設計する方法
構図、字幕、ボタン、カウントダウン、端末テストを通じて、読みやすくタップしやすい、物語を隠さない縦型インタラクティブ短編ドラマを設計する。

はじめに
横向き映像を9:16に切り抜くと、人物の関係性を示す情報が失われ、動作が隠れ、ボタンのスペースも圧迫される。縦型インタラクティブ映像では、絵コンテの段階で人物、字幕、選択UIを共通のセーフエリアの仕組みに組み込む必要がある。映像の編集後に操作部品を重ねるのでは遅い。
構図:横並びの代わりに奥行きを使う
二人の関係は、前景と後景、上下の位置、一人ずつのリアクションへの切り替えで表現できる。選択肢が現れる前には、重要な顔や小道具を中央の物語領域に置き、下部に操作スペースを残す。誰が上方を占め、誰がカメラに近いかも力関係を伝えるため、画面に収めるためだけに適当に立ち位置を決めてはいけない。
字幕:読み終えてから選ぶ
最後の重要なセリフが終わった後、理解するための短い間を置いてから選択肢を表示する。字幕と選択肢が同時に3行を超えないようにする。長い選択肢は短い行動に書き換え、必要な説明は前のショットに入れる。大きな文字を有効にした場合も、人物の顔やボタンが隠れないことを確認する。
ボタン:行動と代償を読み取れるようにする
「彼を信じる/信じない」よりも「鍵を渡す/鍵を持っておく」のほうが明確だ。二つのボタンは、文法、長さ、情報量をおおむね均等にする。作者が好む選択肢だけを、より具体的で安全な表現にしてはいけない。
カウントダウン:登場人物にも時間的な切迫感があるときだけ表示する
追跡や逃走、着信、閉まりかけた扉には時間制限が適している。複雑な道徳的判断、長文の読解、アクセシビリティへの配慮が必要な場面には、一時停止や時間延長が適している。カウントダウンには数字、進捗、色以外の手がかりを併用し、時間切れの結果を事前に定義する必要がある。
テンポ:選択後すぐに反応する
タップ後、約0.2秒以内に押下表示、音、触覚のいずれかのフィードバックを出し、数秒以内に物語上の反応を返す。実際の結果が次のエピソードまで出ない場合も、現在の場面で人物の表情や環境をわずかに変化させ、入力が記憶されたことを示す。
複数プラットフォームのプレビューチェックリスト
- 小さい画面でも大きい画面でも片手で操作できるか。
- ノッチ、ステータスバー、システムジェスチャー、プラットフォームの操作部品が表示を隠していないか。
- 最大の文字サイズで字幕とボタンが干渉しないか。
- 縦横の切り替えや切断からの復旧後も選択が保持されるか。
- 画面録画、ライブ配信、画面のキャスト中も操作部品が読み取れるか。
プラットフォームごとにセーフエリアは変わるため、本文では恒久的なピクセル値の結論を示さず、対象端末で上記の項目を再確認することをチームに求める。公開原稿では文章によるルールとチェックリストで説明し、製品のスクリーンショットは埋め込まない。
縦型インタラクティブ設計が成功すると、プレイヤーはチームが「ボタンのために場所を空けた」ことを意識しない。適切なタイミングで情報をはっきり見て、代償を理解し、正確に決定を完了するだけだ。
絵コンテには三つのインターフェース状態を含める
各選択ノードで、選択肢が現れる前、選択待ち、確定後の状態をすべて描く。選択肢が現れる前には重要な表情、証拠、動作を最後まで見せる。待機中は字幕、人物、ボタンが同じ位置を取り合わないようにする。確定後はハイライト、音、触覚で反応し、次のショットにつながる姿勢を保つ。静止した絵コンテを1枚渡すだけでは、操作部品が実際に現れたときの遮蔽を発見できない。
同じ素材を異なる画面に対応させる場合は、まず切り抜いてはいけない物語領域を示し、次に拡張可能な背景を定義する。自動中央配置は顔を追跡していても、重要な小道具を切り落とす可能性がある。通常のつなぎの場面は安全に構図を組み直せるが、重要な選択ショットは最初から縦型で設計するのが望ましい。横型の完成映像を作ってから修正する方法に頼ってはいけない。
文言にはローカライズの余裕が必要
ボタンの文言は行動を表す動詞を軸にし、文法上の粒度をそろえる。例えば「鍵を渡す」と「鍵を隠す」のようにする。一方には結果をすべて書き、他方には態度だけを書くことは避ける。許容される最長の文言、ローカライズによる文字量の増加、システムの最大文字サイズに対応する状態を作る。収まらない場合は、読みにくい小さな文字に縮めるより、書き換えやコンポーネントの高さの拡大を優先する。
カウントダウンには、開始、終了間近、一時停止、時間切れの四つの状態が必要だ。複雑な推論や関係についての意思表明は、原則として時間制限を設けない。物語上の時間的な切迫感が実際にある場合も、延長、一時停止、無効化を設定できるようにし、結果や実績に影響するかどうかを説明する。
実際の親指と実機で受け入れテストを行う
テスターは、小型画面、全面ディスプレイ、ノッチやパンチホールのある画面を片手で操作し、システムジェスチャー、不安定な通信からの復旧、縦横の切り替え、注意が中断される状況を確認する。誤タップ、時間切れ、字幕を読み終えられなかったケース、タップしても反応がないケース、戻った後の状態消失を記録する。デザイン案上でマウスを使ってボタンを押せても、スマートフォンで使えることの証明にはならない。
納品記録には、セーフエリア、最大文字サイズ、最長の文言、カウントダウン終盤のテスト結果を構造化テキストで保存し、端末とシステムの表示倍率を明記する。そのうえで、スクリーンリーダーの読み上げ順、色以外の状態表示、動きを減らす設定、字幕の読みやすさを確認する。ブログの公開ページには、これらの内部テスト画面を埋め込まず、ページのリソースと読み込み負荷の増加を避ける。
公開後の異常の兆候
選択肢が表示されたのに選択が送信されない場合は、文言が分かりにくい、ボタンが隠れている、カウントダウンの時間が足りない、ページが重いといった原因が考えられる。タップ直後に戻る場合は、誤タップや、結果が提示された内容と一致しないことが原因かもしれない。端末、文字設定、言語、ネットワークごとに分け、操作録画とインタビューを組み合わせて原因を判断する。
選択しなかったすべてのケースを、物語上の迷いと解釈してはいけない。技術的な失敗と設計による迷いでは、必要な修正がまったく異なる。イベント記録と実機テストを組み合わせて初めて、両者を区別できる。


