taiyolab.com
with story配信開始しました
2026年の七夕の日、with storyの配信がAppleのMac App Storeで始まりました。 今日は1.0.2をリリースしました。プロジェクトの原稿を全て繋いでプレビューできるようになりました。 1.0.2で拡張したプレビュープロローグ.txrに続いて過去の経緯.txtが表示されている プレビューは、プロジェクトのエディター設定で指定した文字数で、行を折り返します。掲載誌の文字数に合わせておくと、組版に合わせた執筆ができるようになります。禁則処理はmacOS任せ。ぶら下げなしの緩い禁則です。 原稿を読み直してHTMLに変換するのではなく、プロジェクト全体のAST（抽象構文木）から直接HTMLを生成しているので、長編小説でもすぐにプレビューが表示できます。プレビューはまだ見るだけですが、スタイルテキストをコピーできるので、ちょっとした用事にwithを使うのも楽になるでしょう。開発サイドの観点だと、HTML化したことで印刷機能にも着手できるようになりました。 プロジェクトや資料の作り方やなど、まだ説明が不十分なところもありますが、小説を書く分には不自由しないところまで仕上がってきていると思います。 Pro版とは？ with storyにはPro版があります。1,000円と、それなりの価格なのでアップグレードするべきかどうか悩む方もいらっしゃるかもしれません。with storyのPro機能は1.0.2時点では以下の三点。無料で提供している全機能と比較するとあまりにささやかな機能です。「これに千円？」と思うのも無理はない。でも、これがwith storyのPro機能です。 Word書き出しテンプレートの追加 Wordの部分書き出し 締切の設定と進捗管理 商業的に活動すると、連載の第二話だけ、最低限の手入れで納品できるWordを書き出す機能は必須です。原稿まとめるぞ、となってから二十分、三十分とかかってしまうのはよろしくない。だからここをPro機能にしてあります。 本当はWord書き出しをPro機能にしようと思ったのですが、公募でWord形式が求められることに気づいて、縦書きと横書きの40文字30行はProでなくても使えるようにしておきました。 そして締切管理です。締め切りの日と分量を文字数・枚数・行数のいずれかで設定すると、ステータスバーの表示がタイムアタックに変わります。 現在の締切設定は一週間に書く日数を指定する形式なのですが、アップデータで書く曜日を指定するように変えようかと思います。締め切りが迫ってくると不正確になってしまいますからね。 実はこの機能、デビューした頃に使っていたScrivenerにあった機能です。novel-writerは目標文字数しか実装しなかったので、withで久しぶりに「アスリートのように書く」体験を味わっています。いいもんですよ。とにかく文字を埋めていくというのは。どうせ直すんです。書かなきゃ。 よくある質問 Windows, Linux, Android版は？ ごめんなさい。作れません。 novel-writerは続けますか？ 機能追加を積極的に行うことは減ると思いますが、withとの互換性を保つアップデータは出すことになります。Vivliostyleのプラットフォームとしてはとても使いやすいので、止めることは考えていません。 AI連携は？ withのプロジェクトフォルダーをCursorやAIエージェントでプロジェクト指定して、利用することができます。ファイルの並び順やid、ハッシュは、.withの中にあるproject-index.jsonをエージェントに読んでもらってください。GPTやClaude、Geminiなどの主要なLLMなら原稿の順番を理解したり、保護すべき部分を理解して処理を行うことが可能でしょう。 withのネイティブAI機能は？ Appleの自然言語ライブラリやApple Intelligenceを使ったシーンの要約カードや固有名詞抽出機能、そして要約と関連付けなどは搭載していく予定です。 iOS版はいつ出ます？ 現在、鋭意開発中です。Finderにあるファイル編集機能をwithに持たせなければならないので、機能がとても多くなってしまいます。 数式とか扱えるようになりますか？ 小説の原稿に必要な数式や簡単な図表挿入は検討しています。 登場人物表は？ 1.1.0で資料をカード化して、登場人物や設定などを扱えるようにする予定です。 AIとの開発 作り始めてから100日。TestFlightを初めて50日、審査に提出してから約一週間。そこそこ長い開発期間でした。1ウインドウで使えるエディターですが、見かけよりも中身は複雑です。プロジェクト管理にファイルを扱うアウトライン、ユーザーに見えないアプリ内データ形式から複数の編集モードを作る仕様、履歴、共有などのフルセットを持つアプリケーションです。iOS版との共通設計やデバイスの差もある、なかなか複雑なプロジェクトを、私はCodexで開発しました。 with storyのコードの90パーセントはCodexが書いています。コードに介入するのはGUIの微調整やアルゴリズムの条件を微調整していく程度。40ほどあるカスタムアイコンやプロモーション素材は全て私が作成していますが、クレジットを書くなら開発スタッフはCodexということになるでしょう。 設計は私が決めています。withではCodexに自由に作らせると、アプリケーションを監視するコードが無数に増えてしまい、使用に耐えない状態に陥ることが多々あるのです。一例をあげましょう。つい数日前に、行ハイライトを調整しました。それまで選択行をユーザーに伝える背景をNSText（という文書用の仕組み）の段落書式で描いていました。ところがこの書式、段落に設定するのですが文字を書き直すと再描画されてしまうので、文字が増えたり減ったりするたびにチラつきが出てしまいます。そこで私はテキストが描かれるレイヤーの下にハイライトを描くレイヤーを作ろうと持ちかけました。 レイヤーのサイズはエディターの画面サイズ。withはスクロールの仕組みを自前で構築したので、文字が画面のどの位置にあるのか知っています。固定行送りなので行の領域は計算でも出せるし、テキストレイヤーで確かめることも可能です。描くのはただの四角形。介入するのは選択範囲が変わった時と、IME入力で行を跨いだ時――簡単です。しかしこの設計を受けてCodexがまず作ったのは、幅1500メートルのテキスト最長領域を覆うハイライトレイヤーでした。この巨大なレイヤーの中に画面領域を定義して、アクティブ行の矩形を描き、そしてアクティブでない全ての行の矩形を消す処理を入れていました（今時のMacは大したものです。こんなアホな処理を突っ込まれても「ん？ ちょっと遅いな」ぐらいで済んだのですから）。macOSで扱える最長サイズのテキストをVR表示して、前から後ろから、時には複数のビュワーで見るような時にはそういう描き方も必要かもしれない。SwiftはApple Visionにも対応しているわけですから、Codexが全面的に悪いわけじゃない。ただ、withのハイライトには不要だったというだけの話です。 呆れましたが、極端な条件に対応したテストも書いてくれるので、動いた結果とテストを支保工《スカホールド》にして本当に必要な部品を作り、重い足場を取り払えば、欲しかった軽いハイライトは手に入りました。 アウトラインもエディターも、iCloudの共有も、Codexが出してきたプロトタイプでまず動かして仕様を決め、そのあとで出来の悪い中身を抜くようにして作り上げてきています。まだ手触りの悪いところは残っていますが、徐々に手を入れていきます。 リリース日にコロナを発症してしまいリリースブログが書けなかったので、今回ちょっと、まとめて書いてしまいました。 それではいい執筆を！
