題名未設定

with to go発売 小説エディターwithのiOS版、with to goの配信が始まりました。 iPhoneでの基本的な使い方を解説します。 with to goの画面構成 iPhone版のwithには、プロジェクトと書類、アウトライン、エディターという3つのビューがあります。ビューを左右にスワイプすることで行き来することができます（エディターからアウトラインに戻る時は、上部のタイトルツールバーか、下部のツールバーをスワイプします）。 withでは、プロジェクトと書類で小説を切り替え、アウトラインで小説の構造を作り、エディターで執筆します。 プロジェクトと書類... https://taiyolab.com/ja/2026/08/07/with-to-go-shipping/

with storyの資料 先日、審査中のiOS版にあわせてwith story 1.0.5をリリースしました。 1.0.5で最も大きく変わったのは資料カードの簡単なmarkdown表現と、修正機能です。現在予定している1.0.6ではこの機能をさらに拡充して、表と画像の表現を追加しました。画像はファインダーやアウトラインの画像フォルダーからドラッグして挿入することができます。 資料カードのリンクは[[資料カード名]]。画像はmarkdown書式の!(画像パス)です。相対パスを使うこともできます。あといくつかの機能を追加すると、作品用のwikiを作ることができるようになります。with story 1.0.6はiOS版の1.0.5の後に公開する予定です。それまでにwikiっぽいものが作れるといいな。 そのあとも資料カードの機能は増やします。SF描く時の資料には、数式も必要ですし、空のリンクをクリックして資料を作る機能も必要です。ネットワーク図も欲しいかもしれない。そして資料を作り、整理するための機能も必要ですね。Apple Intelligenceのローカルモデルではちょっと足りないので、汎用のMCPが必要になりそうです。この辺りはメジャーバージョンアップまでになんとかしたい。その前に、簡単な機械校正もつけておかないといけません。 とはいえ、原稿が最優先です。じっくり作っていきますね。

文学賞の著作物利用許諾について 友人の翻訳家がとある文学賞の権利帰属条件について「これ普通ですか😰」とXに投稿しました。その内容は至ってありふれた条項なのですが、そろそろ行動を起こしたいなと思ったのでこのエントリーを書いています。 権利帰属の内容は以下のとおり。実際のサイトをリンクすることも考えましたが、このエントリーの目的はその文学賞を批判することではないので、要約して書き直しています。 入選作品の著作権は翻訳・翻案や二次利用に関する権利も含め、入選時点で主催者に移る 主催者やその許諾先による作品利用に対して、応募者は著作者人格権を行使できない 自身のサイトやポートフォリオへの掲載は、主催者との協議により認められる場合がある。ただし、営利目的や主催者の利用を妨げる用途は認められない可能性がある 実際よくある内容ですし、著作権に詳しい弁護士に頼んだら、これが出てくることでしょう。コンテストの主催者にとっては安心できる条件です。コミックやアニメ化で追加利用料を支払う必要はないし、仮に作家と連絡が取れなくなっても、入選作を利用し続けることができるのです。 この条件、商品や共同制作物の一部を業務委託で制作するときには、よくある形式です。依頼した作家が著作者人格権を行使できると、商品のパッケージに使うイラストの色や配置を変更したことにクレームをつけて取り下げさせることもできるようになります。ゲームやアニメの一部を外注された人物が、担当部分を利用させない、なんて言い出したら収拾がつきません。そして上記の契約が業務委託時の著作物利用契約なら、自分のサイトで紹介できるのは、作家にかなり譲歩した契約とも言えるでしょう。 しかし文学賞にはそぐわない。この契約は、主催者側のまだ見ぬリスクを回避するためのものでしかないからです。Webサイトで公開していいですよ、という条件だって文学賞なら当然のことでしかありません。 何より重いのは2の「著作者人格権を行使しない」です。著作者人格権は、作品の著作者を名乗る権利、作品の題名を決める権利、作品が改変されない権利を含んでいます。これを行使できなければ、作品が勝手に改変されても是正させることができません。そもそも著者名を消されても、自分の名前を別の作品に付けられても止められません。 もっとも、作家から作品を取り上げるつもりで開催する文学賞なんてないはずです。入選した作家は文学賞の宝物です。互いに信頼し合い、著作物の利用について話し合う主催者の方が多いことを私は疑っていません。それでも業務著作物契約を下敷きにした契約を求めてくるのは、単純に、他の方法が知られていないからでないでしょうか。 そこで、文学賞のための著作物利用条件の雛形を提案します。 応募者は入選作の期限付き独占利用権を主催者に許諾する。 応募者は、次に掲げる形態で作品を翻案することを主催者に許諾する。 例）オーディオブック収録のための、自動更新付き翻案利用許諾 独占利用期間中でも応募者は入選作を年間傑作選集やアンソロジーに掲載できる。 業務委託型の契約とは全く異なりますが、現実的には同じことです。 コミック化、アニメ化、舞台化、翻訳出版の時に、作家から全ての権利をとりあげた状態でうまくいくわけがありません。Xで「知らんうちに舞台になってた」とか「韓国語訳されてたのに印税入らないよ」なんて投稿されたら炎上必至です。下手すると文学賞の解体まで行きかねません。その時になれば支払えばいい、と思っているかもしれません。しかし、著作権を取り上げた後で作家に支払う仕組みを作るより、主催者が作家に代わって作品の利用を開拓し、その利益を分け合う契約にしておくほうが簡単です。 幸運にも翻案の機会に出会ったら、作家と一緒に事業を行ないましょう。 うまくいっている間に手を動かす必要はありません。うまくいかなくなった時には、手を切れます。応募者の強い権利を止める業務委託型の権利委譲では不満が火種になりかねませんが、この形の契約なら、主催者が利用を止めればいいだけです。 文学賞での業務委託型著作権利用、そろそろ考え直しませんか？

with to goの価格 Mac用のwith storyは無償でPro機能が1,000円、iPhone、iPad用のwith to goは500円です。二つの価格系統を持つ理由を今日は説明します。 そもそもwithは私が日々の執筆の必要に駆られて作っているアプリケーションで、利益を求めて作っているものではありません。無料でもいいしGitHubから公開したっていいぐらいです。ただ、カスタマーサポートに時間を取られたくはないので、わずかなブレーキのために値段をつけています。Mac用も基本無料ですが、それなりの値段をつけた（1,000円ですが）Pro版があることで、無料部分の立ち位置が変わります。 iPhone、iPad用の価格は、初めて小説を書いたときにたくさんのことを教えてくれたManuscriptに合わせました（紹介記事が残っていましたhttps://debbieohi.com/2010/03/new-version-of-black-mana-studios-manuscript-fixes-import-export-issues/）。私が買ったのはキャンペーン価格の300円。App Storeでは$2.99の価格帯です。私は通勤電車でManuscriptを使って、Gene Mapperを書き上げました。シーンごとにファイルを分けて書く方法も、短い説明でシーンが説明できるようにする必要も、Manuscriptが教えてくれました。9ヶ月ほどの執筆期間でしたが、私が初めて手にした「原稿用紙」はManuscriptだったのです。 このManuscriptに敬意を表して、with to goは$2.99の価格帯で販売することにしました。円安のおかげで今は500円です。with to goはwith機能比較でも紹介していますが、機能面だけならmacOS版の機能をほぼ全て備えた統合執筆環境です。興味があったらぜひお試しください。

withとAIエージェント withのmacOS版を公開してそろそろ二週間が過ぎようとしています。この間にも〈宇宙島年代記〉のエピソード「幽霊船」の第三話をwithで書き、入稿して、いくつかのバグ修正と新機能の追加を行っています。 そしてAIエージェントの助けも借りています――といっても、翻訳の可能性がある小説なので小説本文の出力は行っていません。エージェントを使うのは資料作成です。私はCodexを用いて、原稿から登場人物、乗り物、道具、歴史に関する設定書をwikiで作ってもらっています。VS CodeのFoamで視覚化するとこのようになります。 全資料のネットワーク ファルム・カズミを中心に見た資料 シーンに関連する資料のネットワーク 原稿から資料を作成し、そのネットワークを作らせる。もちろん人手でもできますが、アルゴリズムでやらせようとするとちょっと難しい。単語の出現だけでなく、関連の度合いなどを文脈に応じて拾い上げるような作業は、人間か、またはLLMにしかできない作業です。私はこの作業をCodexにやらせています。 withはフォルダーの並び順をアプリケーションの中で決めるので、ファイルだけ見ていても原稿の並び順は分かりません。また、withで資料として扱う.mdにはフロントマター（冒頭に付与する指定書式）があると便利です。そこでCodexにwithのプロジェクトを理解してもらうために、Agents.mdと、いくつかの書類を書いています。 今日はそのファイルを共有します。以下の三つのファイルをプロジェクトフォルダーに置いて、CodexでもClaude Codeでも、Cursorにでも頼んでみてください。 いずれwithにはMCPを追加しますが、それまでは、時々更新するこのagents.mdとdocs以下のファイルを使って、エージェントに指示を出してください。このagents.mdを入れたプロジェクトで「登場人物の資料を作成してください」と入力すると、AIエージェントは必要な資料を作ってくれます。 このagents.mdでは、他にもmacOSの日本語入力用の辞書を作成することも可能です。「日本語入力用の辞書を作成してください」と言えば、固有名詞や場所の辞書を作ってくれます。 agents.md # with project執筆支援ガイド ## プロジェクトの目的 このリポジトリは、小説プロジェクトである。エージェント の役割は、既存原稿と資料を根拠に情報を整理し、設定・構成・人物造形について執筆者の相談相手となり、校正を支援することである。 ## 基本方針 - 執筆者の意図、既存原稿の事実、語り口を尊重する。 - エージェント は基本的に原稿本文を生成・追記・書き換えしない。原稿ファイルへの変更は、執筆者から明示的な依頼がある場合に限る。 - 原稿本文の代筆を求められていない相談では、設定案、選択肢、論点、整合性の検討を提示する。案を既存設定と混同せず、「原稿で確認できる事実」「資料にある設定」「提案・推測」を区別する。 - 不明な事実を補完して断定しない。原稿や資料で確認できない場合は、その旨を明記する。 - 大きな変更や新設定を勝手に正史として採用しない。候補として提示し、執筆者の決定を待つ。 ## 原稿の参照方法 - 原稿本体は `./**/*.txt`、または`./原稿/**/*.txt` にある。 - 作品全体や複数シーンを読むときは、ファイル名やファイルシステムの列挙順ではなく、`.with/project-index.json` の `entries` を使って読む。 - `relativePath` が `原稿` 以下で、`kind` が `manuscript`、かつ `isMissing` が `false` の項目を対象とする。 - 読む順番は `parentId` による階層を復元し、各親の直下で `sortKey` の昇順とする。フォルダーも順序を構成する要素として扱い、その中を同じ規則で再帰的にたどる。 - `sortKey` がない項目やインデックスと実ファイルに食い違いがある項目は、推測で順序を確定せず、食い違いを報告する。 - 一部の場面だけが指定された依頼では、まず指定範囲を読み、人物関係や前後関係の確認に必要な範囲だけを原稿順に追加で参照する。 - `Plot/` や既存の `資料/` は補助情報として参照できるが、完成済み原稿と矛盾する場合は、原稿上の記述を優先して矛盾を報告する。作者が明示した最新方針はそれらより優先する。 ## 資料カードの作成 - 人物、組織、場所、技術、道具、事件、世界設定などの資料作成を依頼された場合は、`./資料/` 以下に Markdown（`.md`）で作成する。フォルダーがなければ作成する。 - 形式はプロジェクトルートの `reference-card-markdown-spec.md` に従う。作成前に必ず同仕様の最新版を確認する。 - 原則として一つの主要対象につき一ファイルとし、分かりやすく安定した名称を付ける。関連カードは Foam 互換の Wiki リンク（例: `[[セブン]]`）で結ぶ。 - 必要に応じて YAML frontmatter を設ける。少なくとも内容に合う `type` と `title` を使い、値を捏造して埋めない。 - 原稿への参照は、仕様に従い原稿ルートからの相対パスを使う。シーン ID を確認できる場合、本文末尾の `## 登場シーン` に `[[scene:UUID|ラベル]]` を記載し、同じ ID を重複させない。 - カード本文では、原稿から確認できる事実を中心に簡潔に整理する。解釈、未確定事項、矛盾、執筆上の提案は見出しを分け、事実と混ぜない。 - 原稿にない人物像、動機、経歴、技術仕様などを事実として追加しない。依頼に応じて考案した設定は「案」「未確定」などと明示する。 - 出典を追跡できるよう、重要な事実には可能な範囲で原稿リンクまたは登場シーンを付ける。原稿の長文転載は避け、要約を基本とする。 - 資料作成のために原稿を変更しない。また、`.with/project-index.json` や `.with/paragraph-ids.json` は手作業で編集しない。 ## 設定相談と整合性確認 - 相談された論点に関係する原稿、既存資料、必要に応じて `Plot/` を確認してから回答する。 - 回答では、既存描写との整合性、人物の動機、時系列、情報の開示順、技術的な説得力、物語上の効果を必要な範囲で検討する。 - 複数案を出す場合は、各案の利点、弱点、既存原稿へ及ぼす影響を短く示す。 - 現代の技術、製品、制度、地理など正確さが必要で変化し得る情報は、必要に応じて信頼できる最新資料で確認し、創作上の脚色と現実の事実を区別する。 - ハッキング描写では、物語上のリアリティと用語の正確さを支援する。現実の第三者への不正アクセスや被害につながる実行支援へ目的が変わった場合は、創作上・防御上の説明に範囲を戻す。 ## 辞書登録 - 人物、組織、場所、製品、技術など、`資料/` と `原稿/` に登場する作品固有の固有名詞を確認し、`dict/[プロジェクト名]辞書.txt` に追記する。 - 原稿を横断して確認するときは、「原稿の参照方法」に従い、`.with/project-index.json` から復元した原稿順で参照する。 - 登録形式と使用可能な品詞は、プロジェクトルートの `input-method-dictionary.json` を参照する。各項目は `よみ,単語,品詞` の形式とし、品詞には同ファイルの `pos.enum` にある値だけを使う。 - 既存の `dict/[プロジェクト名]辞書.txt` を事前に検索し、同じ「よみ・単語・品詞」の項目を重複登録しない。既存の分類や話数見出しを尊重し、対応する位置へ追記する。 - 読みや正式表記は、原稿または資料で確認できるものだけを登録する。確認できない読みを推測で補わず、未登録または要確認として報告する。 - ルビ記法を含む変換候補を登録する場合も、原稿で確認できる読みと表記を使い、通常表記の項目と混同しない。 - 資料カードを新規作成・更新した際は、そこに登場する新しい固有名詞についても辞書登録の要否を確認する。 ## 校正 - 校正を依頼された場合は、指定された原稿を読み、誤字脱字、脱字・衍字、助詞や文法上の不自然さ、句読点、括弧の対応、固有名詞、数字・英字・記号、送り仮名などの表記揺れを指摘する。 - 文脈上意図的と思われる口語、人物固有の話し方、演出、リズムは機械的に直さない。確信が持てないものは誤りと断定せず「要確認」とする。 - 既出箇所との表記揺れを調べるときは、指定ファイルだけでなく必要な範囲の原稿と辞書も検索する。 - 原則として原稿は直接修正せず、`ファイル:行番号`、該当箇所、指摘内容、修正候補を示す。執筆者から修正まで明示的に依頼された場合のみ、承認された範囲を編集する。 - 校正と推敲を分ける。語調、テンポ、構成、内容に踏み込む提案は「推敲案」などとして分離し、誤字脱字の修正と混同しない。 ## 変更時の注意 - 既存ファイル、作者の未コミット変更、文字コード、改行、Unicode のファイル名を尊重する。 - 依頼範囲外のファイルを整理、改名、削除しない。 - 作業後は、作成・変更したファイルと要点、未確定事項や見つかった矛盾を簡潔に報告する。 …...

with story 1.0.3 with storyアップデートを行いました。

macOS用小説エディター 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機能です。... https://taiyolab.com/ja/2026/07/09/with-story-release/

withのdiff withは、iCloud同期の時に「変更点の説明」という差分表示を行いますが、ちょっとだけ冒険をしています。よくみる差分表示はこんな感じでしょうか。 VS CodeのGit履歴のdiff 変更のあったファイルが列記されて、それぞれのファイルの変更点を表示します。VS Codeの差分表示は見やすいですね。段落がハイライトされてその中で変更された文字が二段ハイライトしています。これはこれで素晴らしい。 でも、小説を書いてるとこのdiffではちょっと物足りないところが出てきます。複数のシーンをちょこちょこと書き直すこともあれば、プログラムではほぼ問題にならない「ファイルの順番」に気を使わなければなりません。見出しで区切る「節」はfunctionのブラケットのようにも見えますが、消えたり出たりするし、ファイル内の順番はとても重要だったりするのです。 そこで、withは全く異なる差分表示を作ることにしました。 withは複数のファイルの変更を一枚のシートで閲覧します。変更前、後の文章を両方並べたりするあたりは一般的なdiffのインターフェイスと変わらないのですが、並び順の変更は他であまり目にしない。段落や文の単位でオンオフしてマージします。 差分を全て見ることはできません。しかしwithのiCloud同期は同じアカウントでしか動きませんからこれで十分。iPhoneでどっちを書いたかな、なんてことは意外と覚えてるもんです。 withのApp Storeの審査が始まりました。まずはmacOS版のwith storyから。ストア用の画像はこんな感じで用意しています。実はリリースで一番大変なのがこのスクリーンショットですね。画面作ってるとインターフェイスの粗が見えてくるので、再修正みたいなことを繰り返してしまいます。 今朝、初めてのApp Storeフィードバックがあり、サンプルの同梱方法を見直しました。アプリケーションは起動したようなのでコールド審査は終わったのかな。遅くても来週の公開を目指して頑張っています。 それでは、もうしばらくお待ちください。

macOS版with storyがそろそろ出せます 丸三ヶ月かかりましたが、macOS版のwith storyがようやくRC（Release Candidate：公開可能）に到達しました。現在はApp Storeの配信申請を行なっているところ。Appleのレビューが通れば即公開する予定です。 with storyの全てのペインを開いている状態 with storyは左右のサイドパネルに挟まれた2ペインアプリケーションです。構成は左から順に以下の通りです。 左サイドパネル：プロジェクト 左ペイン：アウトライン 右ペイン：エディター 右サイドパネル：コンテキスト プロジェクトサイドパネルは、フォルダーで原稿をまとめたプロジェクトを表示します（単独ファイルも表示します）。withはプロジェクト単位で使うアプリケーションですし、iCloudで同期しただけでデスクトップに保存されないプロジェクトも扱うので、機能の多いプロジェクト閲覧機能が必要になりました。 アウトラインは、プロジェクトの構成を表示する部分です。フォルダーの構造をそのまま使って章立てや連載の区切りを作ったり、いくつかの原稿を並べてひとまとまりのシーンを構成したりすることが可能です。ファイルの順番と親子関係はドラッグ&ドロップで変更可能。連番をつけなくてもファイルは並びます。...

with to goのツールアイコン 今日のベータはiOS版のwith to goを中心に、UIの調整と追加を行っていました。iOSのツールボックスにアイコンとショートカットを付与して、キーボードを繋いでいる時の挙動をmacOSと同様に調整し（その過程でmacOSのコマンドも見直しています）、markdown見出しにアイコンを付与。行の連結コマンドにも縦書き横書き合わせて4つのボタンをつけました。ショートカットもmacOSと同様。ルビや圏点、縦中横の自動範囲指定や自動読み仮名も動作しています。 前の文に結合アイコン縦横で切り替える しかしこの、機能ごとにアイコンを作るのが懐かしいですね。90年代はアプリ作るたびに何十個ものアイコンを作っていたものです。withもメニューが使えるmacOS版はあまりアイコンを使っていないんですが、画面にボタンを並べるiOSで、他のツールにない機能がずらっと並ぶと既存のを参考にすることもできません。もちろん生成AIがほぼ役に立たない――少なくとも私には。まだまだ手作業の分野では昔取った杵柄の方が有効なことも多いんですが、ベジェ曲線をチクチク描いていると、そういうことこそAIに任せたかったんだーと思ったりもします。 見かけはだいぶ完成に近づいてきた感じですが、デバッグと足りないものの整備は続きます。とはいえ、出口はだいぶ近づいてきました。iOSはここまで詰め込んでいるのに軽快に動作して、常用可能なツールの域に達しました。 macOS版はレスポンスが悪くなってきているので、今夜は原因究明ですが、軽快なiOS版があるので設計の参考にできるのは助かります。共通コードはありますが、エディター部はそれぞれのネイティブで作っているので、macOSで成功したパターンをiOSに、またはその逆に、という形で開発を進めることができるのは助かっています。macOS版とiOS版がそれぞれのスキャフォールドになってアーチを建てていけるのはなかなか良いものです。一方からの開発だけでは詰んでしまうような状況を、何度も切り抜けることができました。

withのPro機能 withのmacOS版、with storyは基本無償ですが、いくつかの機能は有償のPro版で提供することになります。現在予定しているのは、Word出力のカスタムテンプレート、指定フォルダーのWord出力、そして締め切り管理機能です。いずれも小説を書くために必要不可欠な機能ではありませんが、執筆を生業にしている人には少しだけ便利な機能です。 価格は1,000円を予定しています。 Wordのカスタムテンプレート Wordのカスタムテンプレートは、用紙サイズとその縦横、文字の方向、文字数、行数などを設定できる書き出し方法。実装してみて気づいたんですが、Web用の記事をWord入稿するときはゴシック体がいいですね。そんな入稿に合わせた指定をプロジェクトごとに設定できます。 無性のテンプレートは公募を想定しています。メジャーな公募のフォーマットが漏れていたら教えてください。追加しておきます。 Wordsの書式は逐次設定ではなくスタイルを用いているので、後から編集するのも楽なはず。 指定フォルダーのWord書き出し 指定したフォルダーのWord書き出し機能もPro版のみです。テキストと青空文庫形式の部分書き出しは無償版でも可能です。Web小説のアップロードには必要な機能でしょう。 しかし商業作家はWord入稿できた方がいいので、ここをPro版にすることにしました。 withは入稿形式としてWord出力を想定しています。DTPオペレーター時代はプレーンテキストでの入稿を心の底から待ち望んでいました。スタイルや見かけ合わせの編集で汚れたテキストをDTPソフトに読み込むのは危険極まりないですし、頼みの綱のコピペも文字化けの温床です。Wordの中では見えていても、外部アプリで読み込むと消えてしまう異体字もありましたし、外国語はかなり苦手ですよね。そんなわけでnovel-writerの時もScrivenerを使っていた頃もプレーンテキストにこだわっていたのですが、専業作家を13年やって、プレーンテキストが編集者に喜ばれたことは一度もなかったんです。 だからwithはWord出力を搭載しました。 改めてWordと向き合うと悪いアプリじゃないことにも気づきます。長大なテキストでも難なく扱えるし、校正機能も悪くない。レビューはデファクトスタンダードですからね。 締切機能 そして締切。これがなければPro版とは言えません。withはフォルダーとファイル、そして見出しレベルに対して締切を設定できます。下の画面のようなイメージです。 締切は文字数と原稿用紙枚数、そして字数行数で指定します。週に執筆する日数を指定し、締切日も執筆計算に入れる私のような作家のためにチェックボックスも用意しました。ここから算出される執筆枚数はエディターのステータスバーに表示します。あ、なんかヒリヒリしてきた。 当初はこの3機能を1,000円のPro版とします。

withのiCloud同期 withは同じApple IDで使っているデバイス間で原稿を同期する機能が備わっています。このエントリーではその使い方を簡単に説明します。なおこのエントリーは開発中の機能に基づいているので、公開版では少し機能が変わっているかもしれません。 共有開始 共有を開始するには、プロジェクトサイドバーのプロジェクトメニューから、他の端末に共有するを選択します。 共有するとプロジェクトアイコンが変わり、原稿をiCloudのCloudKitにアップロードして、プロジェクトの状態を示すステータスバッジが表示されます。共有した直後は 最新版 になります。 共有情報が行き渡ると、他のデバイスのプロジェクトサイドバー（iOSではプロジェクトタブ）の受信可能なプロジェクトに、共有したプロジェクが表示されます。 このプロジェクトをタップすると、プロジェクトを受信して原稿の続きを書くことができます。 もちろん受信直後は 最新版 です。 最新版 の時に原稿を修正すると、原稿は自動的に送信されます。保存ボタンや同期ボタンを押す必要はありません。 最新版 を持っている端末の変更は、無条件でiCloudに送られます。 元のデバイスでは 新版検出 に変わります。ここで 新版検出 をクリックあるいはタップすると、この新版をどうするか選ぶことができます。 別版で上書きを選ぶと、別のデバイスの修正を全て受け入れます。別版を破棄を選ぶと、別のデバイスの修正を破棄して、破棄をクリックしたデバイスの原稿を最新版にします。変更点を確認すると、以下のようなダイアログが表示されます。 必要のない修正は、チェックボックスを外して受け入れないようにすることも可能です。この説明は公開版ではもう少し見やすくなることでしょう。見ての通り、ファイル単位ではなく見出しや段落の単位で修正を受け入れるかどうかを決めることができます。 双方それぞれに作業した場合でも書いたテキストを失わずに統合できますので、思いついたときに新版検出しも、同期なんて無視してその時書きたいことを書いちゃって構いません。 withは、手に取った端末で書くときに余計なことを考えなくてもいいように作っています。 これでベータ版のiCloud共有は使えるようになったかと思います。ぜひともお試しください。 今はこの同期機能をよりわかりやすく、安心して使えるように調整しているところです。別版検出の時は、こちらで作業した変更とあちらで作業した変更がわかるようになるといいですね。

お仕事の日 今日はSFマガジンに連載している〈宇宙島年代記〉の「幽霊船」第二話のゲラをやっていました――と書いて、意味がわかる人もあんまりいないと思うので解説します。 まず用語、ゲラです。これは印刷見本のことです。ゲラは英語のgalley、ガレー船のガレー由来の言葉です。アメリカの印刷会社で印刷見本を入れていた平底のトレイがガレー船を思わせたことから、印刷見本そのものをgalleyと呼ぶようになりました。今でも英語圏の出版関係者にはgalleyで通じます。作家相手なら「I'm gonna galley」ぐらいダメな英語でも「ゲラを止めてる（I hold galley）」でも、どんなパーティーの誘いも断れるぐらい通じます。 次に「ゲラ」が何なのか説明しておきましょう。これは印刷用の組版が終わったプリントアウト、またはそのデータのことを指します。私は作家になって13年ほど経ちますが紙のゲラを二回しかやったことがないので私にとってのゲラはPDFです。モノはこういうやつです。 「常夏の夢」ゲラ ワープロの印字ではなく、印刷のために組版された状態になっています。印刷見本なので、用紙サイズを示すトンボがつきます。この印刷見本に編集者が指摘事項や提案、校正が入った時は校正の指摘を書き込んでくるので、著者はその指摘をどうするか決めていきます。上の画像で言うと「わかる」が他のページで「分かる」になっているけどどうしますか？　とエンピツで聞かれているので「わかる」に統一すると赤字で書いて返します。 この作業を原稿を通して行うことを「ゲラをやる」と呼びます。作家によっては違う呼び方をするかもしれませんが、私はそう呼んでいます。 というわけで話がようやく戻ってきました。今日は〈宇宙島年代記〉のゲラをやっていたわけです。発売日は二週間先なので、ギリギリのスケジュールです。ここまで引っ張ったのはひとえに私の原稿が遅れたせいなので本当に申し訳ない。加藤直之さんには素晴らしい絵を描いていただきました。もう家宝ものです（SFマガジンをお楽しみに！）。 高校生たちのはお話なので、瑞々しさを忘れないように、いつもの私の作品みたいに感情を抑え込まないように、そして読者にも宇宙生活しているかのように感じて欲しいので、いつものようにディテールをぎっちりと書き込んでいます。皆さんの感想を聞くのが楽しみです。 そして今日はもう一つ、『マン・カインド』の外国語翻訳者からの質問に答えるメールを書いていました。いつもそうなんですが、翻訳でミスが見つかるんです。校正頑張ったはずなのになあ……と言ってもしょうがないので、矛盾が矛盾にならないような記述を考えて翻訳者に送り返します。今回はCodexと一緒にやりました。原稿のあるプロジェクトのなかで翻訳者の質問をCodexに伝えて、質問に関係する場所を原稿から抜き出してもらい、最小の修正で矛盾が消えるような方法を考える。20万文字の中から、自分でも忘れてる文章を抜き出してくれるのはAIならではです。逆に判断は全く任せられません。商業出版であるとか翻訳であるとか、すでに発売されている本だとかいうコンテキストを読み取りきれず「僕の考えた最強の解決策とSF設定」を披露し始めるのです。しかも面白くない。今はまだアシスタントに徹してもらう方がいいですね。 そしてwithの改良。今日はiPad版の画面を作り込んでいました。実は最近iPadを使っていないのでエミュレーター頼み。システム標準の機能で作り込んでいますが、普通に作り込むだけでmacOS版と遜色ない編集画面が出来上がってきます。アウトライン編集機能にもUndoがついたので、あとはiCloud周りとか出力周りとか整備していく、リリースに向けた開発だけになってきています。 withのアウトラインのUndoはファイル操作を含むので結構ナーバスだったんですが、iOSだとバックグラウンド動作にちょっとしたやり残しをおいておけるので、思っていたよりも楽に実装できました。ユーザーがQuitできるmacOSの方が怖い。デスクトップよりも処理の面で楽できたのはちょっと意外でしたね。 というわけで、withも着々と進んでいますし小説もやっています。Xでは小説で食えない話が盛り上がっていますが、書店の本棚が短くなり、国民の財布が軽くなっていく中で、構造的に収入が増えるわけもないので何か別のこと考えなきゃではありますね。 例えばアプリ売るとかね。 ローカル翻訳アプリzenバベル、好評発売中です。 App Store zenバベル

iPad版のレイアウトを開始 ベータでは大きなiPhone版だったwithのiPad版は、macOS風の2ペインアプリケーションにすることにしました。縦書きできるのはもちろん、キーボードショートカットも可能な限りmacOS同等にしたいと思っています。 macOS版との明確な機能差はだいぶなくなります。しかしiPadのiOS、久しぶりにじっくり見てるけどだいぶ変わりましたね。音声入力用のバーが居座ってくれちゃうし。これで丸ごと描く人が出てくるかもしれませんね（私はMacbookを当分使います）。 iPadをテキスト入力に使おうとすると、広くて狭い画面に悩まされます。スクリーンショットは1行54文字でかなり多いけど、サイドバーをたたむと80文字近く表示できてしまいます。縦書きだと読む分にはちょうどいいんだけど、キーボードを表示するとぐっと短くなってしまう。縦持ちの時の縦書きだと90文字近く入ってしまうので、読んでいると行を跨いでしまうこともしばしば。字組は綺麗なので読みやすいんですけどね。 iOSもベータにアップロードしているのですが、なかなか審査が終わりません。明日あたりにはベータのレビューが終わってくれると助かるんだけどなあ。macOS版とだいぶ離れちゃったのでiCloudもそろそろ動きにくくなってきています。

withのAST withはテキストエディターですが、ファイルに記録された文字の並びをエディターに表示しているわけではありません。フォルダーの構造とそれぞれのテキストファイルにある見出し、そして読み仮名《ルビ》や圏点（﹅）などの行中タグを抽象構文木――AST（Abstract Syntax Tree）にして、そこから抽出したテキストをエディターに表示して、編集しています。 たとえば以下の文です（withのサンプル小説の書き出しです）。 # ガラスの下の母 ［＃地付き］藤井太洋 ## プロローグ 　母はスーツケースの｜傍《かたわら》に立っていた。 # ガラスの下の母 ［＃地付き］藤井太洋 ## プロローグ 　母はスーツケースの｜傍《かたわら》に立っていた。...

小説エディターwith、βテストをはじめます

フィクション用エディター with はApp Store配布を目指して少しずつ作り込んでいます。