📖

ObsidianとLongFormで小説を書く

に公開
Markdown
Obsidian
EPUB
電子書籍
tech

1. はじめに

Obsidianはいいぞと言い続けて

Obsidianはいいぞと言い続けてn年。人類は滅亡し、地表に生き延びたものは猫しかいなかった。

ということもなく、いつから使っていたのか思い出せないのだがドキュメント管理ツールは大事である。 大事だ。本当に大事だ。

Yojimboを長いこと何でもツッコミ箱にしていたくらいの、記憶力はアウトソーシングに頼る、先カンブリア時代の化石の一種が私だ。余談だが、まだYojimbo元気にしてたんだね。

なお箱に入れたものを、見返さない人間であることもここに記しておく。 何度、英会話に入門しただろう？ 入門した回数だけ、英語が喋れるようになっていれば良かったのだが……それはそれ。

その後DEVONthinkに乗り換えかけて「こんなに色々いらねーやい」と思い、Evernoteはリッチエディタにいらつき重すぎ〜と人差し指を振り、結局スクラップ系のものはやめた。
Instapaperを使うようになったし、書きつけはThingsに全部まとめておくようになった。ちなみに今もThings3に至るまで、Thingsを愛用している。

忘れっぽい人間に「最低限」が提供されるということほど良いものはない。
これは古今東西、変わらぬ真実だ。

あまり仕事でも多くドキュメントを書くことがなく、個人ではもっとなかったので、それほど困っていなかった。だが年を取ってくると仕事上でもアウトプットを、まあまあ求められるようになってくる。職場の変化もあって、手元に書きつけをまとめる必要が出てきた。

それでリサーチを続けつつ、Notionを使ってみたりLogseqを使ってみたり、
様々な浮気を重ねながらも「美しい画面は必要だが、もっさりや余白たっぷりは嫌だ」という自分の我儘を満たすものがなかなか見つからず、最終的にObsidianに辿り着いた。

拡張機能も多くて、気づくと時間が溶けるのもまた憎いところである。

現在は、公私共にObsidianを愛用している。
保管庫（データベースのフォルダ）は無論分けている。 分けないと大変なことになる……それはもう、何が起こるかは考えたくないほどに。

2. Obsidianで執筆するメリット

私がObsidianを執筆にも使うようになったのには、いくつか理由がある。

もともと、資料と書く場所がバラバラになってしまうのが面倒だった。 とりあえず資料を手当たり次第に集めて、それを眺めながら書くのが一番やりやすいのだが、その行き来がどうしても煩雑になる。

Obsidianは画面を分割してタブを横に並べられるので、資料を開いたまま書ける。 これが思った以上に快適で、「あ、これでいいじゃん」となった。 快適さとはこういうことを言うのだろう、と思った。

それと、ウインドウがシンプルなのも大きい。 余計な装飾や動作が少なくて、書くことに集中しやすい。 シンプルこそ正義。シンプルこそ至高。

あと、クラウドサービスに依存せずにデータを手元で管理できるのも安心感がある。 私はiCloudに置いているが、それでも「自分の手元にある」という感覚がある。 サービスが突然終了してデータが消えた話を聞くたびに、胃が痛くなる。 その点では、Obsidianは優秀だと言えるだろう。

そんな流れで、気づいたら執筆もObsidianでやるようになっていた。

書き方としては、ひとつの長い本文を最初から最後まで書く、という形ではない。 シリーズごとに作業場所を分けて、その中でメモや本文を管理しながら進めている。

本文も一枚で書き切るのではなく、いくつかの単位に分けて扱っている。 そのほうが全体を見失いにくいし、途中から書きたい場面が出てきたときにも動きやすい。 悪役令嬢が断罪されるシーンを先に書きたい気持ち、わかる。 それができるのがこの方法の強みだ。

私の小説フォルダは、だいたい次のような構成にしている。
無論、タイトルは仮タイトルなので安心していただきたい。

小説/
├── 01_資料/
│   ├── とりあえず放り込む箱/
│   └── シリーズ設定/
│       ├── シリーズ全体構成メモ
│       ├── 文体ルール
│       └── 登場人物メモ
├── S01_悪役令嬢に転生したけど、断罪より先に昼寝します/
│   ├── S01_悪役令嬢に転生したけど、断罪より先に昼寝します__シーン/
│   │   ├── 第一話：昼寝の邪魔をするな
│   │   ├── 第二話：猫がいるので断罪は後にして
│   │   └── 第三話：なぜか聖女扱いされている件
│   ├── 01_制作メモ
│   ├── Index
│   └── S01_悪役令嬢に転生したけど、断罪より先に昼寝します__本文
└── S02_「猫がいるので後にして」と私は言った/

まず一番上に置いているのが「01_資料」だ。

ここにはシリーズ全体に関わる情報をまとめている。 設定や文体のルール、構成のメモなど、作品をまたいで参照するものはすべてここに置く。 執筆中に調べた内容のまとめや、外部の記事の抜き書きなどもここに入れている。あとで触れるが、epub化に関する設定メモもこのフォルダに入れている。 要するに、「作品を書くために参照するもの」はここに集約している。 一箇所にまとまっている、というのは思った以上に大事なことだ。

この中には「とりあえず放り込む箱」というフォルダも作っている。 名前の通りだ。放り込む。それだけだ。 出先でふと思いついたことや、あとで使えそうなものを一旦入れておくための場所である。

iCloudでの連携はかつて不安定という評判が多かったが、現在は大変安定しているように思う。MacでもスマホでもiPadでも快適で困っていないのだ。 かつての評判を知っている人間からすると、隔世の感がある。

その下に、S01から始まる短編のフォルダを並べていく。 各フォルダは、そのまま一作品分の作業領域になっている。 この中には、本文や制作メモなど、執筆に必要なものをまとめている。

そして本文については、少し特殊な構成にしている。 シーンごとにファイルを分け、それをあとからひとつの本文として統合する形を取っている。 その理由は、次の章で説明する。

3. Longformという選択

上記のような構成にしている理由は、Longformというコミュニティプラグインを使っているためだ。このプラグインは実に執筆体験を向上させてくれる。

Longformでは、シーンごとにファイルを分けて管理し、それらをまとめてひとつの本文として出力することができる。

そのため、各シーンは個別のファイルとして書き進め、最終的にそれらを結合して本文を生成する、という形を取っている。

実際に私の場合は、以下のような流れで処理している。

  1. シーンごとにファイルを作成する
  2. 不要なメタ情報やリンクを除去する
  3. シーンタイトルを本文に付与する
  4. すべてのシーンを結合する
  5. 本文として1ファイルに書き出す

この構成にしている一番の理由は、書くときと読むときの負担を分けられることだ。

シーンごとにファイルを分けているので、執筆中は常に小さい単位で書き進めることができる。 長い本文を開いてスクロールし続ける必要がない。 長い本文を開くたびに目的の場所を探すあの作業……あれは地味に消耗するのだ。

一方で、最終的にはそれらをまとめてひとつの本文として出力できるので、通して読みたいときにも困らない。

書くときは軽く、読むときはまとまっている。 そのバランスがちょうどいい。 これが、定番の構成というものだ。

実際に使っていて感じているメリットもいくつかある。

アウトラインを制作メモに書いておけば、それをもとにシーンのファイルを作り、そこに落としていくことができる。どこまで書いたか、どこを書いていないかも見失いづらい。

また、全体の文字数も把握しやすい。

いきなりクライマックスを書きたくなる人もいると思うが、それにも対応できるし、シーンの入れ替えもスムーズなのだ。 断罪シーンを書いてから第一話に戻ればいい。 書きたい場面から書けばいい。 それがLongformというプラグインの強みである。

シーンの分け方については人それぞれだと思うが、私は今回は三話構成のシリーズにしているため、この単位で分けている。

4. Longformの導入と設定

インストールと基本的な仕組み

前章で触れたとおり、この構成はLongformというプラグインによって成立している。ここからはそのLongformを実際にどう使うか、インストールから原稿の書き出しまでを順を追って説明していく。

Longformは、小説・脚本・その他の長編プロジェクトの執筆と編集を助けるプラグインだ。複数のノート（「シーン」と呼ぶ）を順番に並べて、一本の原稿として管理できる。

Obsidianの設定画面にある「コミュニティプラグイン」から検索してインストールできる。 検索して、インストールする。ね？簡単でしょ？ってやつだ。

プロジェクトを作る

インストールしたら、まずプロジェクトを作る。プロジェクトとは「この小説のシーンはここに入っています」とLongformに教えるための単位だ。

フォルダを右クリックし、Create Longform Project（Longformプロジェクトを作成）を選択する。モーダル（設定ダイアログ）が開くので、長編なら Multi、短編や詩のように一枚で完結するなら Single を選んでタイトルを入力し Create（作成）をクリック。

これだけだ。Longformが必要なファイルを自動で作ってくれる。 プロジェクトの管理用にIndex Fileというファイルが1つ生成されるが、これはLongformが使うものなので中身を直接触らなくていい。壊さなければそれでいい。
なお壊した場合でも原稿が異世界に送られることはない。本文ファイル自体は消えないので、最悪プロジェクトを作り直せば復旧は可能だ

シーンを作って書く

Multi で作ったプロジェクトを選ぶと、サイドバーに Scenes（シーン一覧）／Project（プロジェクト情報）／Compile（書き出し）の3タブが並ぶ。

Scenesタブの New Scene（新しいシーン）フィールドをクリックしてシーン名を入力してEnterを押すと、そのノートが作られてエディタに開く。あとは書くだけだ。

シーンが増えてきたら、ドラッグ＆ドロップで並び替えられる。章の中に節を入れたいときはネストが使える。シーンを左右にドラッグするか、コマンドパレットから Indent Scene（シーンをインデント）／Unindent Scene（シーンのインデントを戻す）を使えばいい。

コンパイルで原稿を書き出す

バラバラのシーンを一本の原稿にまとめる処理がコンパイルだ。Compileタブでワークフロー（処理の流れ）を組み立てる。

ワークフローはステップの組み合わせで構成される。ステップには3種類あり、各シーンに処理を施すSceneステップ、複数シーンをひとつに結合するJoinステップ、結合後の原稿全体に処理を施すManuscriptステップがこの順番で並ぶ。

主なビルトインステップは後述のリファレンスにまとめているが、「リンクを削除→タイトルを先頭に挿入→シーンを結合→ノートに書き出す」という流れが基本形だ。ワークフローは保管庫(Vault)全体で共有されるため、変更すると同じワークフローを使う全プロジェクトに反映される。プロジェクトごとに設定を変えたい場合はワークフローを複数作って使い分ける。

私の設定例

実際に使っているマルチシーンプロジェクトのワークフローと設定を参考として載せておく。

Compileタブのワークフロー設定

# ステップ 種別 設定内容
2 Remove Links（リンクを削除） Scene Wikilinks・External Links ともにチェックあり
3 Prepend Title（タイトルを先頭に挿入） Scene Title Format: ## $1 / Separator: \n\n
4 Concatenate Text（テキストを結合） Join Separator: \n\n---\n\n
5 Save as Note（ノートに書き出し） Manuscript Output path: $1__本文.md / Open Compiled Manuscript: オン

シーンとシーンの間に --- を挟むことで、読むときに区切りが分かりやすくなる。出力パスの $1 はプロジェクトのタイトルに置き換わるので、S01_悪役令嬢に転生したけど、断罪より先に昼寝します__本文.md のように自動で命名される。

Projectタブの設定

もう一点、フォルダ構成にも意図がある。

ProjectタブのScene Folderを見ると、シーンの格納先がIndex Fileと同じ階層ではなく、S01_悪役令嬢に転生したけど、断罪より先に昼寝します__シーン というサブフォルダになっている。

これによってコンパイル時の出力先が $1__本文.md、つまりIndex Fileと同じ階層に本文ファイルとして書き出される。シーンファイルたちとは別の場所に本文が生成されるので、シーンと完成原稿が混在せずに済む。

S01_悪役令嬢に転生したけど、断罪より先に昼寝します/
├── S01_悪役令嬢に転生したけど、断罪より先に昼寝します__シーン/   ← シーンはここ
│   ├── 第一話：昼寝の邪魔をするな
│   ├── 第二話：猫がいるので断罪は後にして
│   └── 第三話：なぜか聖女扱いされている件
├── Index.md                    ← Longform管理ファイル
└── S01_悪役令嬢に転生したけど、断罪より先に昼寝します__本文.md   ← コンパイル結果がここに出る

フォルダレベルで分離することで、余計なタブをバタバタ開かないで済む。 これは地味だが、じわじわ効いてくる。 地味に効いてくるものが、最終的には一番大切だったりするものだ。

ここまでで、インストールから原稿の書き出しまでひととおり動かせるはずだ。以降は、必要になったときに読めばいい内容をまとめている。

作業メモをシーンと共存させる

設定メモや資料ノートをプロジェクトフォルダに置きたい場合、Longformが「このファイル知らないけどどうする？」と聞いてくる。Ignore（無視）を選べばそのファイルはシーンリストにもコンパイルにも現れなくなる。ワイルドカードで一括除外もできるので、たとえば -scratch.md で終わるファイルを全部除外したいなら：

ignoredFiles:
  - "*-scratch"

とIndex Fileに書けばいい——ここはさすがに直接書く必要があるので諦めよう。

シングルシーンプロジェクト

Single で作ったプロジェクトは、ノートが1つしかない。そのノート自体が作品本文になる。短編詩・エッセイ・読切小説など、複数ファイルに分けるほどではないけれどLongformのコンパイルやワードカウントは使いたい、というときのためのモードだ。

Scenesタブはなく、ProjectタブとCompileタブだけが並ぶ形になる。

ドラフト管理

一つのプロジェクトに複数のドラフト（草稿バージョン）を持てる。新しいドラフトはProjectタブの +（新規ドラフト）ボタンから作成できる。「書き直したいけど元稿も残したい」というあの葛藤を、ファイルを複製せずに解決できる。ドラフト名を変えたければProjectタブでドラフト名を右クリックして Rename（名前を変更）を選ぶだけだ。

ワードカウントと執筆セッション

書いた量が見えると、続く。これは（人によっては）体感できると思う。

設定から Show word counts in status bar（ステータスバーにワードカウントを表示する）をオンにすると、Obsidianの画面下部に文字数が常に出るようになる。シーン単位とドラフト全体の合計が表示され、クリックするとProjectタブに飛べる。更新は少し遅延があるが、気になるほどではない。

執筆セッション機能もある。1日に書きたい文字数の目標を設定しておくと、達成したときに通知が来る。毎日「今日は1000字書く」と決めて進捗を可視化したい書き手には、地味に刺さる機能だ。

セッションデータの保存先はデフォルトでプラグイン設定ファイルと同じ場所だが、保管庫内の任意の .json ファイルに変更することもできる。複数デバイスで保管庫をGit管理している場合、.gitignore でデバイスごとに除外したいときに便利だ。

ビルトインステップ一覧
ステップ名 種別 何をするか
Prepend Title（タイトルを先頭に挿入） Scene シーン冒頭にタイトルを挿入
Remove Comments（コメントを削除） Scene / Manuscript %% や <!-- --> のコメントを削除
Remove Links（リンクを削除） Scene / Manuscript WikiリンクやURLリンクを削除
Remove Strikethroughs（取り消し線を削除） Scene / Manuscript 取り消し線テキストを削除
Strip Frontmatter（フロントマターを除去） Scene / Manuscript フロントマターを除去
Concatenate Text（テキストを結合） Join シーンを区切り文字で結合
Save as Note（ノートに書き出し） Manuscript 原稿を保管庫内のノートとして保存
ユーザースクリプトで独自ステップを作る

ビルトインで足りなければ、JavaScriptで自分専用のステップを書ける。保管庫内に .js ファイルを置き、プラグイン設定の「スクリプトフォルダ」を指定するだけで読み込まれる。たとえば「3行以上の連続空行を2行に統一する」ステップはこう書ける：

const compile = (input, context) => {
  return input.map(scene => ({
    ...scene,
    contents: scene.contents.replace(/\n{3,}/g, '\n\n')
  }));
};

module.exports = {
  description: {
    name: "Normalize Blank Lines",
    description: "3行以上の連続空行を2行に統一する",
    availableKinds: ["Scene"],
    options: [],
  },
  compile,
};

スクリプトファイルを移動・削除した場合はそのステップが使用不可（動かなくなった状態）になるので、Compile（コンパイル）を実行する前に削除か置き換えが必要だ。

ショートカット一覧

Longformの操作はサイドバーのマウス操作だけでなく、コマンドパレット（Cmd/Ctrl+P）から呼び出せるコマンドでも完結する。「編集中に限る」とは、そのシーンのノートを実際に開いて編集状態にあることが条件という意味だ。

コマンド名 編集中に限る 何をするか
Open Current Note's Project（現在のノートのプロジェクトを開く） ✓ 今開いているノートのプロジェクトをLongformペインで選択する
Previous Scene（前のシーン） ✓ ひとつ前のシーンを開く
Previous Scene at Indent（同階層の前のシーン） ✓ 同じインデントレベルでひとつ前のシーンを開く
Next Scene（次のシーン） ✓ ひとつ次のシーンを開く
Next Scene at Indent（同階層の次のシーン） ✓ 同じインデントレベルでひとつ次のシーンを開く
Indent Scene（シーンをインデント） ✓ 現在のシーンのインデントを一段深くする
Unindent Scene（シーンのインデントを戻す） ✓ 現在のシーンのインデントを一段浅くする
Jump to Project（プロジェクトに移動） — プロジェクト名をあいまい検索して、Longformペインで開く
Jump to Scene in Current Project（現在のプロジェクト内のシーンに移動） — 全シーンを一覧表示し、あいまい検索で素早く移動する
Open Longform Pane（Longformペインを開く） — Longformペインに切り替える
Compile current project with current workflow（現在のワークフローでコンパイル） — 現在のプロジェクトをそのままコンパイルする
Compile project…（プロジェクトをコンパイル） — プロジェクト・ドラフト・ワークフローを選んでコンパイルする

特に使い勝手がいいのは Jump to Scene in Current Project（現在のプロジェクト内のシーンに移動）だ。シーン数が増えてきたプロジェクトで、サイドバーをスクロールせず目的のシーンに一発で飛べる。あいまい検索なのでシーン名を正確に覚えていなくても問題ない。

執筆画面専用CSS

Longformはシーンを表示しているペインに自動で .longform-leaf クラスを付与する。これを使えば、ObsidianのCSSスニペットで「執筆画面だけ」にスタイルを当てられる。

たとえばObsidianはダークテーマで使いつつ、執筆ペインだけライト表示にしたい場合：

.longform-leaf {
  --background-primary: white;
  --background-primary-alt: white;
  --background-secondary: white;
  --background-secondary-alt: white;
}

.longform-leaf .markdown-source-view {
  --text-normal: black;
  color: black;
  background-color: white;
}

.longform-leaf .view-header {
  background-color: white;
}

Obsidian全体のテーマを変えず、書く場所だけ別の空気にできる。

おかしいな？の時は

Longformはノートの内容を書き換えない設計になっている。書き換えるのはIndex Fileのみで、ノートを削除することは絶対にない。

プロジェクトの状態がおかしく見えるときは、Obsidianを再起動するか Reload without saving（保存せずに再読み込み）コマンドを実行するだけで直ることがほとんどだ。

5. まとめ

Longformは書くための構造を押しつけてこない。シーンの粒度は自分で決めればいいし、ネストを使うも使わないも自由だ。中のノートはただのMarkdownファイルなので、Obsidianのリンク・タグ・グラフビューとも普通に共存できる。

最初は Create Longform Project → シーンを作る → 書く、この3ステップだけ覚えれば動き始められる。コンパイルもスタイリングも、必要になったときに手を伸ばせばいい。

英語のReadmeを前に「なんか難しそう……」と思ったそこのあなた。 大丈夫。設定さえ終われば、あとは書くだけだ。

猫がいるので後にして、とは言えない締め切りだけが、作家の敵だ。 それが一番楽しくつづく方法だと、私は感じている。

できあがった作品を電子書籍にしてみよう編はこちら

https://zenn.dev/misari/articles/9c789a1bf40406

Discussion