藤井太洋 Taiyo Fujii (he/him)

@taiyolab.com

Japanese SF writer, author of Gene Mapper and Orbital Cloud. Local translation iOS App zen-Babel ->-> https://apps.apple.com/app/zen/id6761398433

with storyの資料 先日、審査中のiOS版にあわせてwith story 1.0.5をリリースしました。 1.0.5で最も大きく変わったのは資料カードの簡単なmarkdown表現と、修正機能です。現在予定している1.0.6ではこの機能をさらに拡充して、表と画像の表現を追加しました。画像はファインダーやアウトラインの画像フォルダーからドラッグして挿入することができます。 資料カードのリンクは[[資料カード名]]。画像はmarkdown書式の!(画像パス)です。相対パスを使うこともできます。あといくつかの機能を追加すると、作品用のwikiを作ることができるようになります。with…

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が必要になりそうです。この辺りはメジャーバージョンアップまでになんとかしたい。その前に、簡単な機械校正もつけておかないといけません。 とはいえ、原稿が最優先です。じっくり作っていきますね。

taiyolab.com

文学賞の著作物利用許諾について 友人の翻訳家がとある文学賞の権利帰属条件について「これ普通ですか😰」とXに投稿しました。その内容は至ってありふれた条項なのですが、そろそろ行動を起こしたいなと思ったのでこのエントリーを書いています。 権利帰属の内容は以下のとおり。実際のサイトをリンクすることも考えましたが、このエントリーの目的はその文学賞を批判することではないので、要約して書き直しています。 入選作品の著作権は翻訳・翻案や二次利用に関する権利も含め、入選時点で主催者に移る 主催者やその許諾先による作品利用に対して、応募者は著作者人格権を行使できない…

文学賞の著作物利用許諾について

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

taiyolab.com

with to goの価格 Mac用のwith storyは無償でPro機能が1,000円、iPhone、iPad用のwith to goは500円です。二つの価格系統を持つ理由を今日は説明します。…

with to goの価格

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

taiyolab.com

macOS版に続いて、iOS版のwith to goもApp Storeのレビューに提出しました。 macOS版は明日公開。 iOS版は何度か差し戻しがあるかと思いますが、それほど遠くない時期に公開できるでしょう。

macOS版に続いて、iOS版のwith to goもApp Storeのレビューに提出しました。 macOS版は明日公開。 iOS版は何度か差し戻しがあるかと思いますが、それほど遠くない時期に公開できるでしょう。

withとAIエージェント withのmacOS版を公開してそろそろ二週間が過ぎようとしています。この間にも〈宇宙島年代記〉のエピソード「幽霊船」の第三話をwithで書き、入稿して、いくつかのバグ修正と新機能の追加を行っています。 そしてAIエージェントの助けも借りています――といっても、翻訳の可能性がある小説なので小説本文の出力は行っていません。エージェントを使うのは資料作成です。私はCodexを用いて、原稿から登場人物、乗り物、道具、歴史に関する設定書をwikiで作ってもらっています。VS CodeのFoamで視覚化するとこのようになります。 全資料のネットワーク…

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 のファイル名を尊重する。 - 依頼範囲外のファイルを整理、改名、削除しない。 - 作業後は、作成・変更したファイルと要点、未確定事項や見つかった矛盾を簡潔に報告する。 …

taiyolab.com

I've been writing a lot of short stories lately, and I'm excited to receive these two. In Ellen Datlow's ALL HALLOWS EVE you'll find "Or So the Story Goes." In Jonathan Maberry and Henry Herz's THE BIG BAD BOOK OF KAIJU you'll find "Hanging Gardens," a collaboration between me and my son Daniel!

Bild

with storyのアップデートを審査に提出しました。レビューが終わり次第自動的に配信されます。  今回の バージョンでは以下の機能追加とバグの修正を行いました - 検索フィールドの空白を無視しないように修正 - プロジェクト固有のエディター設定を追加  プロジェクト固有のエディター設定がない場合、プロジェクトを開くときは開いた時のエディターの状態を引き継ぎます apps.apple.com/jp/app/with-...

with storyアプリ - App Store

Taiyo Fujiiの「with story」をApp Storeでダウンロードしてください。スクリーンショット、評価とレビュー、ユーザのヒント、「with story」に似たゲームを見ることなどができます。

apps.apple.com

ちなみにこのPangram、私の短編をAI翻訳した文を「100%ニンゲン製」、私が翻訳した英文を「25%AI製の可能性あり」とする程度の占いサービス。 AI判定機なんて、テストは簡単にできるんだよ。2010年以前に書かれた文を一つでもAi製だと判定するならそれはゴミ。そんな2秒でゴミ判定できるサービスに投資するのが「AI景気」の正体なんだよ。