この記事は 創作系 Obsidian Advent Calendar 2025の15日目の記事です。
13日目はMaybeFixさんの「Reference Preview というプラグインを考えた」
16日目は同じく私PlasticHeartの「Obsidianで始める文章作成」です。
みなさんどうも初めまして。PlasticHeartと言います。この記事は創作系 Obsidian Advent Calendar 2025という企画で書いた記事のひとつで、ObsidianをTRPGシナリオエディタとして使うという応用事例について書いてみました。私が何者なのかについてはこことかここをご覧ください。それでは始まります。
なぜObsidianを使うに至ったのか
先日、私がメンバーのひとりである同人サークルHNO₃++で、クトゥルフ神話TRPG(Call of Cthuluhu: CoC, 以下CoC)のシナリオを作ろうという話が持ち上がった1。TRPG(テーブルトーク・ロール・プレイング・ゲーム)というのはゲームごとのルールやシナリオに沿って参加者が会話や想像力、発想力を活かして物語を紡ぎ、時にはサイコロを転がして楽しむゲームのことで、オフラインで遊ぶものもあれば、インターネットの発展に伴ってオンラインで遊ぶようになったものもある。
CoCのシナリオは公式が提供しているものだけでなく、コミュニティで作成したものもあり、もちろん後者のほうが圧倒的に数が多い。コミュニティ製のものはBOOTHやTALTOといったポータルサイトで販売され、価格は無料から数百円とさまざまだ。
シナリオについて
公式シナリオはクトゥルフ神話という大きな世界を遊ぶ上での基礎知識を学ぶための導入としての意味合いがあり、世界観を把握するための教材的な側面が強くなっている。しかし、国内の多くのプレイヤーにとっては、公式シナリオの高い自由度が即興性と想像力が要求されることに繋がり、プレイするにあたっての負担を強くしているため、結果的に遊ばれにくいという傾向を生み出している。
これに対して、コミュニティ(同人・個人制作)シナリオはJRPG的な構造を採用していて、登場人物や事象に明確な動機づけがあり、強固なストーリーラインが設定されているので、初心者にとっても参入しやすく、慣れたプレイヤーであってもプレイへの負担が少ない。加えてCoCを遊びたい人にとっては、コミュニティシナリオは作者の数だけ独自のクトゥルフ神話の世界観があるので、次回作を待つことなく次から次へと一期一会の物語を楽しむことができるので、プレイするにしても回転がよい。さらに近年ではSNSの普及がコミュニティシナリオの人気を後押ししており、プレイ体験や感想、キャラクターを共有することで2、単純にゲームを遊ぶ以上の充実感が得られるようにもなっている。
こうした背景を把握した上で、我々も多くに遊ばれるようなシナリオを作成すべく、CoCのシナリオを書いてみるという試みを始めたのである。
作ってみた
結果として出来上がったものはビスク・ドールは螺旋と踊るというシナリオで3、分量があればいいというわけではないが、書いているうちに本文52,000文字で約100ページと他の作品と比較しても大ボリュームになってしまった。この本文部分はすべてバニラ環境のObsidianで作成されており、Markdownにも拡張記法は採用していない。
これは最初からObsidianで作成しようという構想があったわけではなく、いろいろと模索した結果として今回のシナリオ作成においてはObsidianが最適な選択であり、それを最終成果物の形に持っていくことができる手段があったからである。これから紹介する手法は人によっては技術的要件が高いところにあると感じるかもしれないが、同じようなことを考えている人がいるかもしれないので、実際にやってみるとどういう苦労があるのか、という観点でも見てもらいたい。
百文は一見にしかずということで、以下に実際のObsidian上のプレビュー(左: Markdown)と成果物(右: PDF)を示す。PDF版のサンプルは作品ページからも確認できる。私はObsidianにコミュニティプラグインを導入していないので、プレビューはバニラ環境のObsidianのものである。
調査と分析
我々はCoCのセッション(TRPGをプレイすること)には詳しいものの、シナリオの作成経験はなかったので、まずは市場調査を行なった。なにごとも調査と分析から始めることで、おおよその着地点を決められるからだ。しかし、調査と言っても、それほど大掛かりではなく専門性を伴うものでもなかったが、ほかの人々がどのようにシナリオを作成して成果物を作り、販売しているかを把握できた。
市場調査
このためには前述のBOOTHやTALTOといったポータルサイトで人気のシナリオをダウンロードすることにした。日本のTRPGコミュニティでは体験版やサンプルを配布していることが多く、あるいは本文無料の代わりにセッション用素材(主に画像)を有料としていることもあるので4、調査用のデータを集めることには苦労せず、現在の市場の大まかな傾向を掴むことができた。
その結果として分かったことは、半ば予想通りではあったものの、ほとんどのシナリオはPDF形式で提供されることが多いようだ。一部はゲームマスター(あるいはキーパーと呼ぶ)が自由に内容を編集したいという要求に応えるために、プレーンテキスト形式やWord文書で提供することもあるようだが、改ざんされにくいという意味でもPDFを採用することは妥当なところだと言える。
次にPDFに注目してみると、PDFは最初からPDFとして作成されることはなく、なんらかの文書形式から変換されることが通常である。変換前にどのような文書作成ツールを使っているのかは気になるところだが、組版の特徴から推察するに、多くはWordやPagesといった一般的な文書作成ソフトウェアを使っているようだ。
WordとPagesの検討
したがってまず文書作成ソフトウェアによるシナリオの執筆を検討した。これらのツールは今やOSに付属しているか、ウェブ上で無料で利用できるため第一候補になりうる。言わずもがな文書作成に特化しており、必要に応じて表や画像も挿入できるし、その他デザイン上の要求が生まれても、なんらかの落としどころは見つけられる余地がある。一方で文章のレイアウトを適切に設定して、それを維持することに労力が割かれることになり、スタイルの適用漏れや崩れに対処し続ける必要がある。
他方、クトゥルフ神話TRPGが公式で配信しているクイックスタート・ルール(PDF版)を見れば、それほど複雑な組版は必要とされていないが、その代わりに能力値や技能値のような注目すべき単語に対しては文字装飾が適用されている。同じことを単純に文書作成ソフトウェアを実現しようとしても、チマチマとスタイルを適用するといったじれったい作業をしなければならず、やりたいこととできることを考えると少し噛み合わないところがある。
私が考えるところによると：
- 複雑な組版は必要ない
- レイアウト修正を簡単にしたい
- 注目すべき単語を装飾したい
ということになる。簡単に言えばWordやPagesは高機能が故にやりすぎ感があり、それでいてこういった特殊ケースにおいては痒いところに手が届かないのだ。
MarkdownとObsidian
そこまで複雑な構造の文書を作る必要がなければ、ソフトウェアエンジニアの中では有名なMarkdown(拡張子.md)と呼ばれる文書フォーマットがある。これはシンプルな記法を使って一般的に文書で必要とされる本文・見出し・リンク・文字装飾・リスト・表・画像挿入等を実現できる形式で、Obsidianの文書フォーマットとしても採用されている。
ここでObsidianをMarkdownエディタとしてみれば、かなり優秀であることがわかる。言わずもがな操作性に優れているし、見た目と内容が一致しているWYSIWYGエディタでもある。グラフビューによって記事の接続関係も視覚的に把握できる。少なくともVisual Studio CodeのMarkdownプレビューよりは優秀だ。
WordやPagesを使うことを否定するつもりはないが、これらのリッチなエディタを使う際によくある失敗としては、作業中に文書とレイアウトを一緒に考えてしまうことだ。文章が全然できていないにも関わらず、レイアウトに凝りすぎてしまい、できてもいないものに対する期待を膨らませすぎてしまうことは、人によりけりではあるが、経験があることなのではないだろうか。
その点では人によっては不満に思うかもしれないMarkdownの表現力の低さは有利に働く。レイアウトという誤魔化しに注力することなく中身に集中できるし、いざデザインが必要になっても表現力が少ないが故の利点として統一感が出せることにも繋がるので、表記揺れやデザイン崩れも起こしにくい。
Markdownの表現力
それではMarkdownでいいか？と問われると、やっぱり表現力には限界があるし、Obsidian上で綺麗に見えたとしても、それはObsidianのプレビュー機能が優れているからである。Obsidian Publishを契約している人は、ウェブ上に出力した結果を見ればいい意味でも悪い意味でもそれを感じられることだろう。議論がいったりきたりでMarkdownがいいのか悪いのかどっちなんだと思うかもしれないが、どっちにも決められないのであれば第三の方法を取るしかない。そう、Markdownをもっと表現力が高い形式に変換してしまえばいいのだ。
例えばHTMLとして書き出せばスタイルシートで装飾できるようになるし、デザインを変更したくなっても、元となるスタイル定義を変更すればすべての箇所に対して適用できるので編集コストも下がる。さらにHTMLに書き出すときに特別な単語(トークン)を検知して追加の文言を付加することができれば、文字装飾や追加の文字列を追加して、好きな表示が実現できるはずだ。
そこで私はMarkdownから最終的な成果物としてPDFを得るための流れとして次の手順を考えた。
- Obsidianでシナリオを作成する
- ページ順を決める定義ファイルを作成する
- HTMLのテンプレートを作成する
- Markdownをmarked.jsで解析する
- marked.jsのHTMLエレメント解析をフックして出力をカスタムする
- スタイルシートでデザインを整える
- PythonプログラムでMarkdownをテンプレートに挿入するコードを実行する
- ローカルHTTPサーバーで表示してブラウザの印刷でPDF出力する
- 表紙や付録などの必要なページを追加してPDFのメタ情報を消去する
これは原本となるMarkdownをObsidianで記述することから始まる。そこからHTMLに変換してスタイルシートで装飾をする。最後にブラウザで開いて印刷からPDFを出力すれば、ObsidianをベースとしたCoCシナリオ作成の仕組みが完成するはずだ。
標準のPDF出力
Obsidianには標準で直接PDFを出力する機能もあるが、そこまで組版を考慮した出力はできないし、私が試す限りは1ファイルごとの出力しかできないようだ。もしかしたらコミュニティプラグインでもっといいものがあるかもしれないが、ここは手間であっても自分でHTMLとCSSを使って組版用のレイアウトを作ったほうが自分たちの思い通りにできるし、将来的に好ましい状況になると考えている。
と言うのも、やりたいことズバリのプラグインやライブラリがあればそれに乗っかると短期的には成功しやすいが、長期的な目線で捉えた場合には、仕様変更やサポート終了によって自分たちの目論見がいとも容易く破壊されうるので、保証したい大切な仕組みがあるなら、なるべく自分たちで用意して、外的要因による影響を排除する方向に動いたほうがいいかもしれないからだ。
美麗な組版
加えて、私は市場調査を経て、意外とシンプルかつ美麗なシナリオデータがないことに気づいた。コミュニティにおける有名なシナリオであっても、視認性が悪いものや指示がわかりにくいもの、作者の意図が読み取りにくいものがある中で、Markdownの表現力だけでシンプルかつデザイン性に富んだ形式の提案ができないかという観点でもこの挑戦に取り組んでみた。もし元文書がMarkdownであっても、整形によって美麗な出力が得られるのであれば、新たな価値提供にも繋がると考えたのだ。
Obsidianによるドキュメント生成
1. Obsidianでシナリオを作成する
まずはObsidianでシナリオを作成する。仕組みを簡単にするために、1つのシナリオに対して1つの保管庫で管理することにした。
デザイン的な統一感を出すために、Markdown上の見出しやリスト、引用といった要素をシナリオ上の要素にどう対応づけるかはあらかじめ決めておかなければならないが、最終的な校正の際に調整すればいいので、この段階では思いつくままにシナリオを記述していくこととした。必要に応じてページを分けたりフォルダに移動したりということも起きるが、むしろそれこそが思考を整理するためのツールであるObsidianを使うことでもあるからだ。
言うまでもないがここに一番時間がかかった。デザインやレイアウトを考えて調整する組版作業というのは面倒な仕事ではあるものの、やれば終わりが見える作業である。それよりも、シナリオを作成するということこそが価値提供に繋がる重要な部分なので、考えていることを書き出して、それをなるべく客観的に捉えて自然な表現になるように修正することを繰り返した。
2. ページ順を決める定義ファイルを作成する
シナリオが完成したら、次にシナリオのページ順を決める設定ファイルを作成する。これはMarkdownからHTMLに変換する際に、保管庫内のすべてのMarkdownファイルを取得することになるが、人間が期待した順序で取り出せるわけではないからである。
そこであらかじめ定義ファイルにMarkdownの結合順を決めるファイルを作成しておいて、その順番で処理するようにした。私の場合はMarkdownのファイルパスを取得順に列挙したJSONファイルを作成した。
ファイル名やフォルダ名の先頭に連番を振ることや、フロントマターに取得順を記載する方法も考えたが、ファイルに対してメタ情報を含ませることが柔軟性を失わせることにも繋がると判断したので、定義ファイル方式を採用している。
3. HTMLのテンプレートを作成する
次にMarkdownをHTMLに変換することになるが、これにはmarked.jsを利用した。marked.jsはMarkdownをHTMLに変換してくれるJavaScriptのライブラリなのだが、出力結果には基本的なスタイルしか適用されていない。変換後のエレメント(HTMLタグ)にはそれぞれクラスが追加されているので、自分好みのスタイルで上書きしていくことになる。
marked.jsによるMarkdown変換はカスタムすることもできる。追加のタグを表示したり、解析ルールを追加したりもできるので、CoCのルールブックに準拠するようにカスタム表現を定義した。ここで一番苦労したことはカスタム解析ルールのための正規表現を定義することだ。人間が書く文章はそれこそ自由な記述ができるし、また一方で元のMarkdownに拡張記法を導入したくはなかったので、トライアルアンドエラーで正しい解析ができるようにルールの調整を繰り返した。
4. PythonでMarkdownをテンプレートに挿入する
必ずしもPythonでなくてもいいのだが、私が使い慣れているということからPythonを使用している。このプログラムで行うことは、Obsidianの保管庫内のすべてのMarkdownファイルを再帰的に(サブフォルダやそのさらにサブフォルダも)取得して、すべてのファイルを連結したのちにHTMLのテンプレートに挿入することだ。
Obsidianにはページ間でローカルリンクする記法があるが、HTMLに出力する際にこの記法はうまく働かなくなってしまうので、ローカルリンクのための解析ルールをmarked.jsで追加した上で、各ページのHTMLの先頭にファイル名を持つ id 属性を持つ見えないタグを配置して解決している。id 属性は好きな値を設定できるものの、空白文字が入って動作しなくなる可能性があるので、実際にはBase64に変換した結果を使用している。
出力結果として得られたHTMLはPython製のHTTPサーバーであるflaskで表示することにした5。これはローカルファイルを開くための file:/// プロトコルを使用すると、ブラウザのセキュリティ制限に引っかかって画像が表示できないので、その制約を回避するためである。
5. PDFとして印刷する
HTTPサーバーで公開されたページをブラウザで表示して、印刷機能からPDFで保存する。今やどのブラウザでもPDF出力ができるようになっているがGoogle Chromeを使う。Chomeは印刷向けのスタイルシートへの対応状況も良好で、印刷時も余白をギリギリまで削ることができるからだ。
6. 仕上げをする
本文が印刷できたらあとは別個に作成した表紙や目次を連結する。どうしてもMarkdownだけではこういった特殊なページの記述には向かないので、それはWordやPagesといった文書作成ソフトウェアやペイントツールで作成したものを差し込むことにした。画像ページを差し込む際には品質を考慮しないと思わぬ容量増加を招きかねないので、適度に画質を下げる等の処理を加える必要があるかもしれない。
また、あまり気にしない人もいるが、通常PDFには誰が作ったとか、どのページを印刷したものなのかといったメタ情報と呼ばれる本来のデータを補足する追加の情報が含まれている。個人が特定できるような情報が含まれていることはあまりないが、なるべく消しておくことが好ましい。これにはAdobe製のツールを使わずともexiftoolやqpdfといったツールが提供されているので、コマンドラインによるアプリケーションの実行に不慣れな人はいるだろうが、難しいことはないので試してみてほしい。
結果的に
昨今では困ったらHTMLと言えるほどにウェブ技術は高度化してきており、例えウェブ技術が最終的に必要なかったとしても、ウェブの世界に課題を持ち込むと簡単に解決することも多い。しかし、必要な知識は多岐に渡り、HTML + CSS + JavaScriptの3点セットは必須であるし、加えて取り組んでいる分野をウェブ上で実現するための知見も必要となる。
今回紹介した手法はObsidianを単なるMarkdownエディタとして使用するに留まっていて、その後の作業に技術的な複雑さや強引な印象を与えるかもしれないが、コンテンツ制作に集中するObsidianと複雑な表現を担うウェブ技術という分業制にして、各ステップの役割を明確に分けたことで、組版に惑わされることなく文章作成に集中することができ、シナリオの完成とデザインの統一という両立した結果が得られている。これはPDF出力だけでなく、Obsidian Publishによるウェブ出力においても同様の恩恵を得られるはずだ。
さらに、今回Obsidianで編集しているMarkdownには一切デザイン的な手を加えておらず、コミュニティプラグインも導入していないので、このコンテンツ資産を活かして、もっと簡単な変換方法を採用するとか、別の出力形式に対応するといった拡張性が残されている点にも注目したい。
この描画内容も標準のObsidianによるMarkdownの範疇を超えていない。Markdown上では色付き文字はないし、サイコロの絵文字もない。marked.jsによるカスタム変換ルールとスタイルの調整によってのみ実現されている。
しかし、こうして成果物としてはうまくいったものの、売上は振るわない。いいものを作ったと思っても、それが売れるということはまた別の話なのである。