舞台脚本を書くためのWebサービス、

「戯台（ぎだい）」というものを作りました。

https://gidai.shitai.co.uk/

SNSで投稿したところ、970いいねをいただけるほどの反響をいただきました。

一言でいうと、**「舞台のための脚本OS」**みたいなものです。

脚本を書く。
直す。
誰かに見てもらう。
変更点を確認する。
役者や演出と共有する。
舞台図を作る。
稽古で使う。
最後にPDFにする。

このあたりを、なるべく一つの場所で完結させようとしています。

今回はサービスの紹介だけじゃなく、

なんで作ったのか
どうやって作っているのか
裏側で何が動いているのか
毎月どれくらいお金がかかっているのか

あたりまで、せっかくなので全部書いてみます。

使ってくださっている方にも、個人開発している方にも、
「へー、こんな感じで動いてんのね」
くらいの感じで読んでもらえれば。

実際の画面

■ まず最初に。まだβ版です

ここは一番最初に書いておきます。
戯台は現在、β版です。
普通に不具合もあります。

「ここちょっと使いづらいな」
みたいな部分もまだあります。

完成しました！！！
という顔をして出しているわけではありません。

むしろ今は、**「実際に使ってもらって、見つかった問題を直していく」**という段階です。

そのため、不具合報告や改善要望も受け付けています。
さらに、いただいた内容については、
「今どこまで対応しているのか」もできるだけ公開するようにしています。

「なんか変」
「このボタン分かりにくい」
「こういう機能ほしい」

くらいでも全然大丈夫です。β版なので、そういう声がめちゃくちゃありがたいです。

【不具合報告フォーム】

https://tally.so/r/eqXlXE

【対応状況】

https://airtable.com/appIESB9Rqb5XvB6X/shrjpbWTBFTmANVko/tblIYjUyu8kqX4OuN/viwhPvNi1YhaO1xTo

■ で、戯台って何ができるん？

ざっくりいうと、「脚本を書くところから、舞台で実際に使うところまでまとめて管理するサービス」です。

例えば現在は、

Wordっぽい感覚で脚本を書く
縦書き / 横書きを切り替える
ルビ、傍点、太字を使う
PDF から脚本を読み込む
台詞、場面、舞台指示、照明、音響を区別する
コメントを付ける
修正案を出す
過去の版を保存する
どこが変わったのか差分を見る
役者やスタッフと共有する
舞台図を作る
稽古予定を管理する
PDFを書き出す

みたいなことができます。

普通の文章エディタとちょっと違うのが、戯台の中では脚本を「ただの長い文章」として持っていないことです。

例えば、

「これは田村の台詞」
「これは舞台指示」
「これは照明の指示」
「これは場面の切り替わり」

みたいな情報を内部では持っています。
見た目は普通の脚本でも、裏側では文章を意味のある単位として管理しています。なので、

「この版でどこが変わった？」
「この変更に関係するのは誰？」
「この役の人に関係するところだけ見たい」

みたいなことを、将来的にはもっと自然に扱えるようにしたいと思っています。

縦書きの場合

横書き

過去の原稿との差分表示機能

読み合わせ時に嬉しい自分の役のみのハイライト表示

舞台図も作れて、台本上に挿入できるよ。

役者に対して、役者に影響のある変更箇所のみを自動でメール通知もできるよ
口頭でわざわざ伝える必要なし！

■ なんで作ったん

脚本を書くソフト自体はいっぱいあります。

Wordもある。
Googleドキュメントもある。
共有するならGoogle Driveもある。
連絡するならLINEやDiscordもある。
スケジュール管理するサービスもある。

でも舞台を作っていると、

「結局それ全部使うやん。」

となります。

脚本はここ。
連絡はここ。
舞台図はこれ。
稽古予定は別。

で、

「最新版の脚本ってどれ？」

となる。

○○さんに送ったのはv3？
いやv4？
こっちのPDFが最新版？

みたいな。だったら最初から、

「舞台を作ること」

を前提にした場所があってもいいんじゃないか。
そう思って作り始めたのが戯台です。

なので個人的には、「高機能な脚本エディタ」というより、
「脚本を中心に、舞台制作そのものをまとめる場所」
にしたいと思っています。

まだ道半ばですが。
というかβ版なので、普通にまだめちゃくちゃ作っています。

■ 公開したら、思ってたより使ってもらえた

戯台を公開してから5日。

ありがたいことに、登録ユーザー数が180人を突破しました。
さらに、
作成されたプロジェクト数も100件を突破しました。

これは結構びっくりしました。
正直、最初はもっと静かに始まると思っていました。
もちろん登録者数だけでサービスの良し悪しが決まるわけではないです。
でも、登録して終わりではなく、
実際に100件以上プロジェクトが作られている。
つまり、ちゃんと中まで触ってくれている人がいる。
これはかなりうれしかったです。
ほんまにありがとうございます。

当然ですが、
使ってもらう人数が増えると、

「ここ壊れてます」
「スマホだと変です」
「この機能ほしいです」

みたいなフィードバックも増えます。
でもこれはむしろありがたくて、
今はそれを一個ずつ直しながら育てています。

■ どうやって作ってんの？

ここからちょっと開発の話です。

戯台は、かなりAIを使って作っています。
大まかな流れはこんな感じです。

ChatGPTで画面・仕様を考える
↓
Codexで実装する
↓
型チェック・Lint・回帰テストなどを実行
↓
実際のブラウザを操作して確認
↓
問題があれば修正
↓
Pull Requestを作成
↓
確認・承認
↓
デプロイスクリプトを実行
↓
本番反映

という流れです。

■ まずChatGPTでデザインを考える

いきなりCodexに、「脚本管理サービス作って」とは投げていません。

最初にChatGPTで、

「こういう画面だったら使いやすいんじゃない？」
「スマホだとどうする？」
「この機能はどこに置く？」
「画面遷移どうする？」
みたいなことを結構詰めています。

必要なら実際の画面イメージも作ります。
そこである程度、**「こういうものを作りたい」**という形を決めてから、Codexに実装してもらいます。

人間でも、仕様がフワフワしてるのに
「とりあえず作って」
と言われたら困るので、
そこはAIでも同じかなと思っています。

■ 実装はCodex

実装はCodex（5.6 Luna Thinking level High）をかなり使っています。

タスクによって推論量を高めにして、
単純に、「このボタン追加して」
だけではなく、

既存機能への影響
過去のテスト

関連する処理まで確認してもらいます。便利です。
ほんまに便利。AIがなかったら、
今の開発速度では絶対作れていません。

■ でもAIが「できました！」と言っても信用しすぎない

ここは結構大事にしています。
Codexが、

「実装完了しました」

と言っても、ほんまか？となります。
なのでまず、

TypeScriptの型チェック
Lint
回帰テスト
Build

などを実行します。ただし、

「テストが全部通った = 実際に使える」

ではありません。Webサービスって普通に、
コード的には正しいけど、画面を見ると盛大に壊れている、
みたいなことがあります。
なので、そのあと実際のブラウザを触ります。

■ VISUAL_QA.mdという、まあまあ狂ったファイルがある

戯台には、VISUAL_QA.mdというファイルがあります。

名前の通り、**「実際に画面を触って確認した内容」**をずっと残しているファイルです。

実際のファイルの中身

例えば開発初期には、

「縦書きの本文がちゃんと表示されない」

とか、

「スマホで横スクロールが出てしまう」

とか、普通にありました。
それを、

問題
↓
修正
↓
もう一回ブラウザで操作
↓
PASS / FAIL

という感じで残しています。

PCだけじゃなく、スマホも確認します。
PDF読み込みなら、

実際の84ページある脚本PDFを入れて、
ちゃんとページが出るか、
縦書きが壊れていないか、
文字が読み取れるか、
OCRがおかしくないか、

みたいなとこまで確認しました。
地味です。でもこの地味なやつが結構大事です。

■ 一回直したバグが復活してないかも見る

機能を増やしているとありがちなのが、

「前に直したところが、別の改修でまた壊れる」

やつです。いわゆるデグレです。

なので新しい機能を作ったときも、

過去のテストやVisual QAを見ながら、
以前壊れた場所がまた壊れていないか確認します。

Codexにブラウザ操作をさせる場合もありますし、
最後は自分で触ることもあります。

「AIが全部作って、AIが全部確認しています」
ではなく、
**AIをめちゃくちゃ使う。でも最後は人間も普通に触る。**という感じです。

■ そのまま本番には出さない

確認が終わったらGitHubにpush。
そこから、main → productionのPull Requestを作ります。

PRには、

何を変えたか
どんなテストをしたか
PCで何を確認したか
スマホで何を確認したか
まだ確認できていない部分
影響範囲
問題が起きた場合の戻し方

などを残します。

それを確認して、問題なければ承認してproductionへマージ。
その後にデプロイスクリプトを実行します。
なので、

Codex
「できたで！」
僕
 「ほな本番！」

ではないです。さすがに怖い。

■ サーバー側はこんな感じ

ここは開発者向け。ざっくり構成を書くと、

ユーザーのブラウザ
↓
Cloudflare
↓
UFW（ファイアウォール）
↓
Nginx
↓
Next.js
↓
PostgreSQL

という感じです。

構成図

アプリケーションは、Next.js / React / TypeScript。
DBはPostgreSQLです。
メール送信にはResend。
PDF周りではPDF.jsやPlaywright。
OCRではPopplerやTesseract。

アップロードされたファイルについては、
ClamAVで検査するようにしています。

あとは、Prometheusでサーバーの状態を取ったり、
Lokiでログを集めたり、Grafanaで確認したり。
NginxやPostgreSQL、UFW、fail2banなどのログも集めています。

Grafanaの画面

Grafanaの画面2

個人開発にしては、ちょっと盛り盛りです。

■ バックアップも取っています

人の脚本を預かるサービスなので、ここは結構怖いところです。

現在はPostgreSQLのデータを、毎日1回バックアップしています。
保存しているのは直近30世代。

バックアップの中に、
ちゃんと戯台のデータが入っているかも確認しています。
失敗した場合には通知も飛ばします。

なので例えば、**「操作ミスでデータを消してしまった」**みたいなケースには、ある程度対応できる状態です。

ただし。
ここには一個、結構大きな問題があります。

■ バックアップが同じサーバーにある

現在のバックアップ、
基本的に戯台が動いているサーバーの中にあります。
これ、データを間違えて消したときには役立ちます。

でも、サーバー自体が完全にぶっ壊れたらどうすんの？

という問題があります。例えるなら、

パソコンのデータを外付けHDDにバックアップしたけど、
HDDも同じ机の上に置いている

机ごと吹っ飛んだら終わる。

なので今後は、バックアップを別のサーバーや外部ストレージにも送って、
「戯台のサーバーが丸ごと死んでも、別の場所からデータを戻せる」
状態にしたいと思っています。派手な新機能ではないです。

ユーザーから見ても、多分何も変わりません。

でも何かあったときに、こういうところが一番効いてくるので、
ここはかなり優先度高めです。

■ で、毎月いくらかかってんの？

せっかくなので、ここも出します。

現在、開発に使っているChatGPT Plusです。

為替で多少変わりますが、日本円でだいたい月3,100円前後。

そしてサーバー代。

現在使っているサーバーは、VPS、固定IPv4、通信量などを含めて、
税別で月約1,320円くらいです。

だいたいこんな内訳

なので、今見えている固定費だけを単純に足すと、
月4,400円前後＋税という感じです。

もちろん為替によって変わります。

ちなみにこのサーバーは、戯台だけの専用サーバーではなく、自分が運営している別サービスとも一部共用しています。

なので、約1,320円全部が「戯台だけのサーバー代」という意味ではありません。

ただ、利用者が増えれば、メモリも使う。保存データも増える。
PDFも増える。バックアップも増える。

ということで、このまま永久に今のスペックでいけるとも思っていません。

■ 今後、お金を使いたいところ

今考えているのは、

大きく3つです。

■ 1. AIの開発環境をもう少し強くしたい

現在はChatGPT Plusを使っていますが、今後はProへの変更も検討しています。

戯台はCodexをかなり使っているので、大きな修正や、長時間の確認、回帰確認などをもう少し余裕を持って回せるようにしたいです。

単純に、**「もっと高速で機能を増やしたい」**というより、

**確認やQAにもAIをもっと使える余裕を作りたい。**という方が近いです。

■ 2. サーバーを少し強くしたい

現在のサーバーは、まだ普通に動いています。
ただ、確認した時点でストレージ使用率は約74％。
空き容量も約9GBほどでした。
PDFやバックアップを扱うサービスなので、
ここはもう少し余裕を持たせたいです。

特に今後、メモリとディスク容量は増強したいと思っています。

■ 3. バックアップをサーバーの外へ逃がしたい

これがかなり大事です。
今も毎日バックアップはしています。
ただ、本体とバックアップが同じサーバーにあるという状態。

なので今後は、別のストレージや別サーバーへ、バックアップを自動でコピーするようにしたいです。
こうしておけば、万が一サーバー自体に何かあっても、
別の場所から復旧できます。

派手じゃないです。多分、
実装しても誰にも気づかれません。

でも、何かあったときに一番ありがたいやつです。

■ 最後に

公開からまだ5日。
登録ユーザー180人。
作成プロジェクト100件。
まだβ版です。

普通に直すところもいっぱいあります。
でも、思っていたよりたくさんの人に触ってもらえて、
**「ちゃんと続けたいサービス」**になってきました。
なので、機能だけじゃなく、

どう作っているのか。
どう運営しているのか。
どんな問題が起きているのか。
何にお金がかかっているのか。

そのへんも、できるだけオープンにしていこうと思っています。
完成してから見せるではなく、作っている途中も含めて見せていく。
β版の今だからこそ、それでいいかなと思っています。
また何か大きく変わったら書こうと思います。