#台本( シナリオ )とは
台本( シナリオ )とは主に映像作品のためのセリフ原稿です。
この投稿では台本=シナリオ=脚本として説明致します。
実際には映画、舞台、TVドラマ、ラジオドラマをはじめゲームやイベント、番組進行の為にも用意されます。
広い意味では何かを進行させるための進行指示書のようなものと言えるでしょう。
大切なことは台本は作り手側にとって必要な資料ですが、視聴者にとってはその存在が意識されるべきものではありません。
#台本( シナリオ )の書式
台本( シナリオ )の書式は“一応”古くから決まっています。
最近では400字詰めの原稿用紙(縦書き)やA4横 (縦書き) などが一般的ですが、本来は200字詰め原稿用紙 (縦書き) に書くのが正しいとされています。
この 200字詰め原稿用紙 1枚を“ペラ”と呼び、非常に大凡に言えば30秒のシーンになります。
つまり“非常に単純な”計算として作品の時間をペラの枚数で判断(計画)できるのです。
#書式を守る?守らない?
シナリオを教える学校などに行くと、柱、ト書き、セリフの書き方、様式などを習うのですが、これらの様式を守る必要があるでしょうか。
答えとしては、シナリオ が指示書である以上、制作現場で決められている様式を守る必要がありますが、逆に言えば現場で理解されればどのような様式でも構わないでしょう。
古くからある 柱、ト書き、セリフ の情報構成はドラマ の指示書としては概ね良く出来ており基本形ともいえますが、その書き方、例えば ト書きの頭を3マス空ける、セリフに カギ括弧を使うなどのシナリオ記法に関しては改善する必要があります。
現在は横書きの時代です。
縦書きは元々の日本語の慣習に沿ったものですので、新たな時代の慣習が発生すればその慣習や環境に沿った手法が生まれるのが自然と言えるでしょう。
文章を書くツールが手書きで無くなった現在では、より効率の良いライティングが提案され、新しい標準ルールが策定されるべきだと考えます。
#シナリオは映像化のための設計図である
シナリオは単なる映像化のための設計図です。
通常の流れとして、先ず大凡のプロット(アイデア)が生まれますが、シナリオ作成はその次の段階に発生する作業です。
シナリオはアイデアレベルのライティングを含め、何度も修正されながら映像と共に完成します。
修正がフィードバックされていないシナリオは設計図を無視した建築をその場で進め、設計図にその結果すらフィードバックしていない作業のようなものです。
#シナリオ作成の次の作業は絵コンテの作成です。
絵コンテに関はこれもまた映像のための設計図です。
通常、映像制作は複数の人間の手によって作られるものですので、作りて側チーム内の制作物に対しての共通イメージとコンセンサスが必要となります。
つまりシナリオや絵コンテによって映像化を徐々に具体化し制作チーム内でのブレを無くすのです。
チームを例としていますが、個人での制作作業においても同じです。
映像化するための一人ブレインストーミングの為の作業です。
#そこで問題点
現在、日本で流通している旧来のシナリオ記法は以下の様々な問題点を抱えています。
このことは日本の映像芸術の衰退や次世代の作家の国際的な活躍のチャンスを遠ざける結果にもつながります。
- デジタルツールでの入力が煩雑である
- 頭の字下げ指示やカギ括弧の必要性は デジタルでの入力が考慮されていないため、 入力リズムを壊すものであり作業を煩雑にさせる要因となっている。
- 他のソフトウェアでの解析に適していない
- シナリオ記法としてフォーマットが無いために他のソフトウェアでの解析ができない。
例えばシナリオデータを読み込んでAdobe Aftereffectsなどの映像編集ソフトで空コンポを書き出すなどに対応できない。
標準化されていない
大雑把なレイアウトとルールは決められているが、詳細な記法が標準化されていないため情報の追加などに対応できない。
米国では『Fountain』などのマークアップによるシナリオ記法も立案されており、拡張性や可読性からもこれらプレーンなテキストによるマークアップ又はマークダウンなどの記法が適していると思われ、海外ソフトウェアとしては『finaldraft』やWEBサービスhttps://www.studiobinder.com/ などが存在します。
#シナリオ記法『SPES ScreenPlay ExpressSheet』
現在、日本国内ではシナリオの記法が定められていないために、拡張性、可読性、記述性に優れた シナリオ記法の策定が望まれます。
米国の『Fountain』 などは一つのモデルとなりますが、大文字やイタリックと言った日本語や他の言語には適さないルールが含まれているのでこのあたりの要素を排除し、よりグローバルな記法の立案が望まれます。
個人的に理想として考えられるのは、 マークダウン的な記法が良いと思っていますが、マークダウンだけで表現するのは少し難しいかも知れません。
現在一般的に利用されている言語仕様を取り入れるのも一考です。
一先ず必要な要素を記述できる構造を考え、便利な記法に寄せていくのも現実的かも知れないと思い少し考えてみました。
名称を**SPES ( ScreenPlayExpressSheet )**と言います。
- 基本はシーン、カットを全て数字の { } で括り、各情報をクラス的に記述する感じです。
- 平易な記述で言語知識の無い人でもある程度読めることが必須ですが、ファイルインポートなどによりカメラデータなどにアクセス可能で3Dシーンの構築に使用可能なデータ構造が必要です。
- セリフ以外の各値は;で区切りマルチで記述できます。
インデントは必須ではありません。 - – 時間、+サウンド、*ト書き(コメント)
- シーンやカット番号後の : 以降にカメラとデュレーション(できればmsecが理想ですが可読性と自由度は維持したいところです。)、ライトの設定が記述可能です。
- カット直下にはキャラクター名とセリフが { } で入ります。
- 大切なことはパース可能であり且つ言語仕様を知らなくても可読可能なことですので、現在は{}を利用していますが、Pythonなどのインデント記法への変更も考えています。
ざっくりの素案なので適宜修正しながらの策定思案中となります。
#SPES ( ScreenPlayExpressSheet )入力例
/* カミチェン ショートショート『ラッシュ・アワー』
想定10分
プロット
通勤メトロに乗る3人
車内放送
通勤客A
通勤客B
通勤客C
*/
@inport const.spes;
1: 走る電車内{ /*シーン1 シーンタイトル(柱)*/
e=ドアの開く音、雑踏, /*ト書き*/
t=12:15, /*シーンの絶対時間を指定できます*/
s=プラットフォームのアナウンスBG; /*サウンド指定 URIなどもOK*/
1: 車内放送と通勤客ABの会話{ /*カット1 カットタイトル*/
c=$cam1, d=30, l=ライトB; /*カメラ、尺、ライトなどを文章による記述、又は@inportしたカメラデータ等 数字で始まる値はシーン又はカットとなり自由に入れ子できます*/
車内放送{
e= 明るい声、社内ノイズ;
駆け込み乗車はおやめください。
扉が閉まりますご注意ください。
リュクサック、ショルダーバックなどお荷物は邪魔にならないように網棚の上に上げるか、手前でお持ちください。
できるだけ奥までお詰め下さるようお願い致します。
お早うございます。本日もメトロスターをご利用頂き誠に有難うごさいます。
次は『ポートタウン8丁目』
快速急行は『ポートタウン8丁目』より各駅に停車致します。
中央ラインはお乗り換えです。
}
通勤客B{
おぉ、お早う。
}
通勤客A{
e=独り言のように小声で;
ああ、お早うございます先輩。
混みますね。
}
}
}
#####参考のシナリオ本編ドラマ