校正過程: フロントエンド発のFeature-Sliced Designを、自作のRust製ゲームエンジンに持ち込んだ話

CNK 2026 採択 abstract の「型」を移植し、Round 1〜5 のレビューと改善を経た記録。

トーク設計#

幹（一文）#

「フロントエンド発の FSD を、ゲームエンジン (Rust + Bevy + Dioxus) のエディタに持ち込んだら、Rust のコンパイラ強制と AI 駆動開発の両方が新しい守護者になった」。

2 つの越境: ①ドメイン（Web FE → デスクトップ / ゲームエンジン）が主役 / ②実装（FSD コミュニティの主戦場である JS/TS → Rust）が副次。

3 つの守護者: ①FSD の決定木（機械可読な配置）/ ②Rust のコンパイラ（FSD の世界では Steiger 等の linter が担う encapsulation 強制をネイティブで）/ ③AI 駆動開発との相性

対象（ペルソナ）#

• FE エンジニアで FSD に興味あり／採用検討中の人
• Rust / Dioxus desktop アプリ開発者（少数だが熱量高い）
• 個人開発でアーキテクチャに悩んでいる人
• AI 駆動開発で「AI のコード配置が迷子になる」に心当たりがある人

持ち帰り価値#

• メイン: 「フロントエンド発のアーキテクチャがゲームエンジンエディタで通用する ─ 配置を機械的に決める文化はデスクトップ Rust + AI 駆動開発で増幅される」越境体験
• サブ: Rust の mod 可視性で FSD を「コンパイラに守らせる」翻案レシピ
• サブ’: AI にも自分にも効く「機械可読な決定木」という設計思想

避けたいこと#

• FSD の概念解説で時間を食いすぎる（ある程度しっかり扱う方針だが過多は禁物）
• Rust 詳細 / Bevy / Dioxus の細部に潜って聴衆を置き去りにする
• 「皆さんよく知ってる FSD」のような前提押し付け（FSD は比較的新しい概念）
• FSD origin を「TS 発」と不正確に語らない（公式は framework / language 非依存、FE プロジェクト向け methodology と明言。実態として JS/TS 界隈で採用例が多いだけ）
• TS との比較で TS 側を deep に説明しすぎる（聴衆に Steiger 経験者は少ない想定）

構成の型#

フック先出し + 二山構造（PREP に近いが Reason → Example ×2 → Point の重み）

流れ（30 分配分）#

• フック + 自己紹介 + Bebeu 紹介 (0:00–3:00): テーマ呼応「画面の向こうに誰かがいる限り、地続き」+ 越境宣言（インフラ屋・SRE が FE の話を持ってきた）+ Bebeu（Rust + Bevy + Dioxus desktop の個人ゲームエンジン）の世界観をスクショ 1 枚で共有
• FSD 概念きっちり (3:00–8:00): 「Feature-Sliced Design は比較的新しい FE アーキテクチャ」と正直に切り出す（origin は framework 非依存だが FE 向け / 実態として JS/TS の React/Vue 界隈で広まっている）/ 6 layer（app / pages / widgets / features / entities / shared）/ 同レイヤー間の slice 依存禁止 / FSD の世界では Steiger という公式 linter (JS/TS の FE で動く) で encapsulation を守る選択肢
• 持ち込み動機 (8:00–10:00): Bebeu の editor で多ドメイン（Character / SpriteGroup / Animation / Effect 等）+ CRUD feature 増殖の予感 / 配置をその都度判断したくない
• ★山①: Rust 翻案 (10:00–18:00): facade パターン / slice.rs + slice/ ディレクトリ流儀（mod.rs 不使用）/ pub mod 禁止で内部隠蔽 / FSD の世界で linter が担っていた encapsulation を Rust の mod 可視性が「コンパイラで強制」/ deep-import 違反 = build error / 「Web 発の架構がゲームエンジンエディタで予想以上にハマった」をオチに置く
• ★山②: 機械可読な決定木の恩恵 ─ AI にも自分にも (18:00–24:00): 「どこに置く?」「どこにある?」が機械的に決まる / 自分: 半年後の復帰コストが低い（個人開発の現実的価値）/ AI: prompt が短く済む + deep-import を Rust が build error で止める / FSD 世界の linter との対比は軽く（Rust の優位を示す程度）
• 振り返り + 結論 (24:00–28:00): 3 つの守護者を得た越境ストーリー / 「持ち込んだら思った以上に効いた」 / 持ち帰り（フロントエンド発のアーキテクチャはゲームエンジンでも通用する / FSD 公式エコシステムでも Steiger 使えば近づけるが Rust だと標準で手に入る）
• バッファ + Q&A 誘導 (28:00–30:00)

焦点化#

一人称・内的（「Bebeu で試した」「思った以上に効いた」）。“べき論”の俯瞰解説にしない。

削った素材 → 退避先#

• ADR-0003（DDD 集約ルート ⇔ FSD slice の 1:1 対応） → Q&A 退避
• ADR-0002（synchronous-only data flow）など他 ADR → Q&A / ブログ
• Dioxus の reactivity / undo-redo / OOUI 等の周辺話題 → Q&A
• Bevy 側（engine）の話 → 今回は editor のみに絞る
• AI エージェントの具体ツール名（Claude Code / Cursor 等） → 抽象的に「AI エージェント」で扱う

タイトル候補#

• 現行案: 「『これ、どこに置けばいい？』─ フロントエンド発のFSDを、Rust製ゲームエンジンで守らせた話」
• 補欠案B: 「『FSDはFEだけのもの？』─ ゲームエンジン(Rust + Bevy + Dioxus)に持ち込んでみたら、3つの守護者がついてきた」
• 旧案: 「フロントエンド発のFSD、ゲームエンジンで使える？ ─ RustとAI駆動開発が増幅した越境の話」

旧版アーカイブ#

v1: 初期案#

サブ見出しを切った構成で、テーマへの呼応から本論に入っていた版:

「画面の向こうに誰かがいる限り、地続き」 ─ そのテーマに乗らせてください。

本職はインフラエンジニアで SRE をやっています。今日は、フロントエンドで広まったアーキテクチャ Feature-Sliced Design (FSD) を、Rust + Bevy + Dioxus desktop のゲームエンジンエディタ「Bebeu」(個人開発) に持ち込んでみた話を 30 分で。

フロントエンド発の FSD を、ゲームエンジンに持ち込んでみる#

FSD は比較的新しい FE アーキテクチャです。app / pages / widgets / features / entities / shared という 6 つのレイヤーに分け、同レイヤー間の依存を禁止することで「どこに置くか」を機械的に決める設計思想。FSD の世界では Steiger という公式 linter (JS/TS の FE で動く) で encapsulation を守る選択肢があります。

しかしゲームエンジンのエディタは Rust で書かれた Desktop アプリ。Web ではなく、ましてや TS でもない。それでも FSD の決定木はそのまま使えるのか？

やってみた ─ Rust の mod 可視性で、コンパイラが encapsulation を守る#

Bebeu の editor を slice.rs + slice/ の facade パターンで組み直したら、deep-import 違反がそのまま build error になりました。FSD の世界で linter が頑張っていた encapsulation の強制が、Rust では標準で手に入る。フロントエンド発の架構が、ゲームエンジンエディタで予想以上にハマりました。

さらに ─ 機械可読な決定木は、自分にも AI にも効く#

「どこに置く?」「どこにある?」がレイヤー名で機械的に決まるので、半年後に戻ってきた自分が迷わない。AI エージェントへの prompt も短く済む。AI が deep-import してきても Rust が即 build error で止めてくれる。

持ち帰り#

フロントエンドで生まれたアーキテクチャは、ゲームエンジン (Rust + Bevy + Dioxus) でも通用する。むしろ Rust のコンパイラと AI 駆動開発で増幅される。3 つの守護者 ─ FSD の決定木 / Rust のコンパイラ / AI 駆動開発との相性 ─ を、フロントエンド越境の実例として持ち帰ってください。

リポジトリ (公開ミラー): github.com/sakai-nako/Bebeu

移植した CNK 型の要素チェック#

• #1 一人称の問い: 「これ、どこに置けばいい？ 半年後の自分は、ちゃんと見つけられる？」+「インフラ屋のわたしが…抱えてきたモヤモヤ」で実存に接続
• #2 違和感・モヤモヤの開示: 「ここに置いた理由を、半年後の自分が覚えていられない」「配置に毎回悩むコストがスピードを削る感覚」
• #3 転換点の物語化: 「そんな折、…FSD に行き着きます」
• #4 姿勢フレーズ: 「持ち込むのは Web。守るのは Rust。」
• #5 具体ツールと自前性: slice.rs + slice/ facade、pub mod 禁止、Rust の mod 可視性、build error 強制
• #6 内的変化のビフォーアフター: 「フロントエンド発の架構が、ゲームエンジンエディタで予想以上にハマりました」+「半年後の自分も、AI エージェントも…レイヤー名さえあれば、迷子にしません」（冒頭のモヤモヤと同じ語彙で輪を閉じる + テーマ「画面の向こうに誰か」と語彙レベルで接続）
• #7 独自概念で整理: 「3 つの守護者」「機械可読な決定木」
• #8 本セッションでは…: 最終段落で持ち帰り価値を明示 + Rust を使わない FE 聴衆向け翻案レシピも明示

Round 1 改善ログ#

• タイトル: 案 A 採用（本文冒頭の一人称の問いと完全呼応するため）
• #1 強化: 「インフラ屋のわたしが、Rust の個人開発でずっと抱えてきたモヤモヤ」を冒頭に追加し、配置の悩みを実存に接続
• #3 強化: 「目に入ります」（受動）→「行き着きます」（能動）
• #4 短縮: 22 字 →「持ち込むのは Web。守るのは Rust。」14 字。CNK 採択版「あるものでやる。ないものは作る。」(16 字) と同等のリズムに
• #6 輪を閉じる: 「半年後の自分は、もう迷いません」を追加し、冒頭の「半年後の自分が覚えていられない」を同じ語彙で受ける
• #7 抽象削除: 「対称構造でした」を削除
• 末尾の重複解消: 「予想以上にハマった越境体験」→「Rust と AI に増幅された越境体験」

Round 2 改善ログ（文章リズム・引き込み）#

• タイトル: カッコ「(Rust)」を外し、「ゲームエンジンの Rust で守らせた話」に。口に出した時の引っかかりを解消
• 段落 1 の記号過密解消: 「『これ、どこに置けばいい？──そして半年後、自分はちゃんと見つけられる？』」→ 内側のダッシュを半角スペースに置換し「『これ、どこに置けばいい？ 半年後の自分は、ちゃんと見つけられる？』」に。引用符＋ダッシュ＋ダッシュの三重記号 → 二重まで軽減
• 段落 2 を二分: 一文に修飾と挿入と心情が同居していたのを「個人開発しています。/ ドメイン…」で 2 文に
• 段落 3 を段落 3+4 に分割: 「FSD 概念紹介」と「持ち込み実装〜ハマった」を別段落に。山の頂を立てる
• 「FSD の世界」二連発を解消: 後者を「Steiger が JS/TS で頑張っていた encapsulation が」に変更
• 段落 6 の主述ねじれ解消: 「フロントエンド発のアーキテクチャが…30 分で共有します」→「フロントエンド発のアーキテクチャをゲームエンジンエディタに持ち込み、Rust と AI に増幅された越境体験を 30 分で共有します」
• 冗長削除: 「個人開発」の同段落 2 回 → 1 回に / 「そのまま FSD の守護者に据えました」→「FSD の守護者に据えました」
• 「半年後」連発回避: 段落 5 中盤の「半年後に戻ってきた自分にも」→「明日の自分にも」に変奏。最終文の「半年後の自分は、もう迷いません」だけ残す

Round 3 改善ログ（CFP 審査者目線）#

• 採否予測 (Round 3 レビュー前): 3/5 (「物語の型・独自角度は強いが、本体が Rust 寄りで FE 編成として通すか審査者が一拍迷う」)
• タイトル変更: 「ゲームエンジンの Rust で守らせた話」→「Rust 製ゲームエンジンで守らせた話」。係り受け「ゲームエンジンの Rust」(所属関係が弱い) →「Rust 製ゲームエンジン」(複合名詞で主役を明示)
• FE 聴衆向け翻案レシピを明示: 最終段落に「Rust を使わない方は可視性で encapsulation を守れる他言語への翻案レシピとして」を追加。レビュー指摘「FE 聴衆の “翌週月曜” が弱い (持ち帰りの中核が Rust の mod 可視性)」への対応
• テーマ「画面の向こうに誰か」と語彙接続: 段落 5 末尾を「半年後の自分は、もう迷いません」→「半年後の自分も、AI エージェントも、コードの “向こう側” にいる読者。レイヤー名さえあれば、迷子にしません。」に置換。これによって：
  • テーマ「画面の向こうに誰かがいる限り、地続き」と “向こう側” で語彙レベルで接続
  • レビュー指摘「3 つの守護者の③ AI 駆動開発が abstract で担保されていない」を「AI エージェント」を読者として位置づけることで具体化
  • 「半年後の自分は、もう迷いません」よりも能動的・対象 2 つ並列 (自分 + AI) で締まる

Round 4 改善ログ（Anti-Slop）#

• 5 軸スコア (Round 4 レビュー時点): 立場 8 / リズム 7 / 主体性 9 / 具体性 9 / 削減 6 = 合計 39/50。書き直し閾値 35 をクリアして公開可ライン
• 対称構文を 2 文に分解: 段落 6 末尾「フロントエンド越境の実例として、また Rust を使わない方は…翻案レシピとして、持ち帰ってください」→「フロントエンド越境の実例として持ち帰ってください。Rust を使わない方には、可視性で encapsulation を守れる他言語への翻案レシピになります。」（「○○として、また××として」は AI 好みの対称構文）
• 「守護者」前借りの解消: 段落 4 中盤「Rust の mod 可視性を FSD の守護者に据えました」→「Rust の mod 可視性に、FSD のレイヤー境界を守らせました」。最終段落の「3 つの守護者」を独自概念として立てる集中度を上げる
• 名詞化の削減: 段落 3 末尾「encapsulation を強制する世界。」→「encapsulation を強制します。」（「○○の世界」は景色／風景系の名詞化、撲滅語彙の §1）
• 「ふと」の削除: 段落 2「ふと手が止まりました」→「手が止まりました」（「ふと」は AI 常套副詞）
• 記号集計: ── 3 個 → 3 個（変動なし、abstract 推奨 1-2 個に対して満杯）
• 維持判断: 「3 つの守護者」「機械可読な決定木」「持ち込むのは Web。守るのは Rust。」は独自概念・姿勢フレーズとして維持（Anti-Slop の昇華語に該当しても独自性で抜く判断）
• 公開ライン到達: 5 軸合計が閾値超え。CFP 用 abstract として「AI 臭が抜けた」状態

Round 5 改善ログ（接続度 = coherence）#

ユーザー提案による新規軸。文章の各要素間の接続強度と接続タイプを RST 系（Halliday & Hasan の cohesion / coherence、Rhetorical Structure Theory）に基づいて評価し、Cohesion（言語的結束）と Coherence（意味的一貫性）の両面で診断。

全体診断: Cohesion は強い（「どこに置く / 配置 / レイヤー名」「そんな折」「それでも」「さらに」など語彙と接続詞の鎖が太い）。一方で Coherence の弱点は「先出しの細部が後段で回収されない」（SRE 粒度）と「メタファー・新概念の論理橋省略」（AI 初出、読者メタファー）に集中。両者とも CNK 型の Setup-Payoff を狙った配置だが、Payoff 側の語彙接続が abstract 内に閉じていないため、その場では浮いて感じられる。

ワースト 3 → 修正:

• W1: 段落 2「本職はSRE → 趣味でBebeu」接続度 4 → 改善
  • 問題: SRE という細粒度の追加情報が abstract 全体で回収されず、伏線として宙吊り
  • 修正: 段落 2 冒頭に「反復作業を疑うのが日課です。」を追加。これにより「SRE 性 = 反復作業への感度」が Cause-Consequence で接続され、後段「配置に毎回悩むコストが、スピードを確実に削っていく感覚」と語彙接続して回収される
• W2: 段落 4→5「AIエージェント」初出 接続度 6 → 改善
  • 問題: AI 駆動開発が段 5 冒頭で「さらに」と並列追加される（事前予告なし）
  • 修正: 段 5 冒頭「『どこに置く？』『どこにある？』がレイヤー名で機械的に決まる決定木は、AIエージェントへのpromptにも…」→「この機械的に決まる決定木は、AIエージェントと一緒に書くとき効きが倍になりました。promptにも、明日の自分にもそのまま効きます。」。AI を「決定木の効きが倍化する文脈」として導入することで、Cause-Consequence で接続
• W3: 段落 5「向こう側にいる読者」メタファー導入 接続度 4 → 改善
  • 問題: 「読者」というメタファーが論理橋なく挿入される
  • 修正: 「半年後の自分も、AIエージェントも、コードの”向こう側”にいる読者。」→「半年後の自分も、AIエージェントも、わたしのコードを”読みに来る”側 ─ 画面の向こうの読者です。」。「読みに来る側 → 画面の向こうの読者」と橋を一段挟むことで「読者」と呼ぶ根拠を abstract 内に明示。テーマ「画面の向こうに誰か」とも語彙レベルで完全一致

接続度改善後の見立て: W1〜W3 すべて 接続度 7-8 に到達。Coherence の弱点が抜けて、Cohesion との両輪が成立した状態

Round 6 改善ログ（ダッシュ削減）#

ユーザー指摘「ダッシュ多い気がする」に対応。abstract 全体で ── ─ が 4 個、タイトルに 1 個（計 5 個）あり、AI Slop の典型パターン（ダッシュ多用）に該当。Anti-Slop 推奨値（abstract で 1〜2 個）を超過。

残す判断:

• タイトル ─: 引用部とサブタイトルの構造境界。1 個のみで多用感を出さない
• 段落 5 読みに来る"側 ─ 画面の向こうの読者です: Round 5 で挿入したメタファー導入の論理橋（W3）。coherence 軸の修正経緯があるため温存

削る判断:

• 段落 1 冒頭 ──: 改行 + 「これは、〜のモヤモヤです。」で受け直し。引用の「掴み」を独立段落化し、地の文で説明する構造へ
• 段落 4 冒頭 通用するのか？──「持ち込むのは…: 疑問形「？」だけで間が稼げる。ダッシュ削除のみ
• 段落 6 末尾 「AI駆動開発との相性」── 3つの守護者を: フレーズ列挙 → 総括の常套構文。句点で十分

記号集計: ダッシュ ── ─ 計 5 個 → 2 個（タイトル + 段落 5 のメタファー橋のみ）

Round 7 改善ログ（接続度: 段落 2 内部）#

ユーザー指摘「段落 2『個人開発しています』→『増えていく予感に、手が止まりました』の繋がりが薄い」に対応。Round 5 で段落間の接続度（W1〜W3）を整えたが、段落 2 の内部接続が手付かずだった。

問題:

• 「個人開発しています」（現状・継続）→「増えていく予感に、手が止まりました」（過去形の動作）で時間軸と因果がジャンプ
• Cohesion 上は「Bebeu」「ドメイン」が指示として繋がるが、Coherence 上は「個人開発のどこで予感が来たのか」が抜けている

修正:

「個人開発しています。**editorを書き進めるうちに、**ドメイン…が増えていく予感に、手が止まりました。」

• 時間順序（開発開始 → 書き進めた → 予感）を「うちに」で明示し Continuation + Cause-Consequence で接続
• 副次効果: 「editor」を abstract に先出しすることで、後段「editorをslice.rs + slice/のfacadeパターンで組み直し」と語彙接続が太くなる（cohesion 強化）

接続度: 段落 2 内部 5 → 8

Round 8 改善ログ（体験ベース大幅書き直し）#

ユーザー指摘 8 件に対応。Round 1〜5 で構築した CNK 採択型の独自概念群（3 つの守護者、決定木、姿勢フレーズ、具体ツール詳細）が「専門的すぎてわかりづらい」と評価されたため、体験ベースに大幅書き直し。CNK 型 #4 #5 #7 #8 は緩める判断（ユーザー選択: 体験ベース大幅書き直し方針）。

A 群（軽い修正）:

• 「ゲームエンジンエディタ」表現: 「engine 自体を作るエディタ」と読まれる曖昧さを解消。「Bebeu」を全体（個人ゲームエンジン）、その中の「editor」を別概念として明示
• 「そんな折…行き着きます」接続違和感: 「悩むなかで出会ったのが…FSD でした」と能動的接続に
• Steiger 削除: 公式エコシステム言及を削除（認知度低い判断）。「Web FE 由来で、公式エコシステムは Steiger という JS/TS の linter で encapsulation を強制します」→「Web FE 由来ですが、もとから framework や language には依存しない methodology として設計されています」（FSD 公式の framework/language 非依存性に置換）
• リポジトリ削除: 末尾の「リポジトリ(公開ミラー): github.com/sakai-nako/Bebeu」を削除

B 群（独自概念の解体）:

• 姿勢フレーズ「持ち込むのはWeb。守るのはRust。」削除: CNK 型 #4 を緩め、「半信半疑で editor を組み直してみたら」に
• 段落 4 後半の具体実装削除: slice.rs + slice/, facade パターン, pub mod, mod 可視性, deep-import, Steiger 名を全削除。「レイヤー境界を破る違反はそのまま build error で止まる」「linter で頑張っていた境界の強制が、Rust ではコンパイラ標準で手に入る」と抽象化。CNK 型 #5 を緩める
• 「決定木」削除: 「『どこに置くか』がレイヤー名で決まる仕組み」に置換。「機械可読な決定木」という独自フレーズも放棄
• 末尾段落「3 つの守護者」「翻案レシピ」削除: CNK 型 #7 #8 を緩め、「越境体験」「個人開発の手応え」「FE 文化が他領域でも効く実例」に抽象化

残った要素:

• タイトル（変更なし。「Rust 製ゲームエンジン」も指摘外で温存）
• 段落 1 の「掴み」と段落 2 の「モヤモヤ」（実存接続）
• 段落 5 末尾「読みに来る側 ─ 画面の向こうの読者」（Round 5 W3 のメタファー橋）

ベタ詰め適用: 新規追加分（「framework や language」「FE 文化」等）も既存ルールに合わせて半角スペース除去（「frameworkやlanguage」「FE文化」）。

懸念: CNK 採択型の移植戦略を緩めた結果、独自性は「タイトル」と「Bebeu 体験」に集中する形に。Round 4 の Anti-Slop 5 軸スコア（39/50）は再計測していないが、独自概念の昇華語が消えたので独自性 9 → 7 程度に低下する可能性。一方で具体性・主体性は維持されており、公開ライン 35 は超える見込み。

Round 9 改善ログ（タイトル変更 + 用語平易化）#

ユーザー指摘 9 件に対応（リポジトリ削除は Round 8 で対応済みだったので除外）。Round 8 の体験ベース書き直しで残った専門用語・違和感のある表現をさらに削減。

タイトル変更（指摘 1, 2）:

• 「『これ、どこに置けばいい？』─ フロントエンド発のFSDを、Rust製ゲームエンジンで守らせた話」→「フロントエンド発のFSDを、自作のRust製ゲームエンジンに持ち込んだ話」
• 「これ」抽象的（→ 削除）、「FSDを守らせる」擬人化違和感（→「持ち込んだ」に）
• ユーザー選択は案 C（Rust 明示版）。掴みフレーズとタイトルの呼応は Round 1 で意識した要素だが、平易さと違和感解消を優先

Bebeu 説明の再整理（指摘 3, 4, 9）:

• 「個人ゲームエンジン」違和感 → 「自作のゲームエンジン」に
• engine と editor の流れ不明 → 「エディタ部分(Dioxus desktopで実装)」と注記して engine と editor の関係を本文側で明示
• 「ゲームエンジンのeditor」→ 「自作ゲームエンジンのエディタ」「エディタ部分」に統一

用語の日本語化・カナ化（指摘 5, 6, 7）:

• CRUD feature → CRUD 機能
• FE → フロントエンド（「Web FE」→「Web フロントエンド」、「FE 文化」→「フロントエンド文化」）
• 「framework や language には依存しない methodology」→「特定の言語やフレームワークに依存しない設計思想」（英単語くどさ解消）
• editor （英）→ エディタ（カナ）に統一

FSD 用語の平易化（指摘 8）:

• 「レイヤー境界を破る違反」→「禁止されているレイヤー間の依存」（段落 3 の「同レイヤー間の依存を禁止する」と語彙接続）
• 「AI がレイヤー境界を破ってきても」→「AI が禁止された依存を書いてきても」

残った要素:

• 段落 1 の「掴み」と段落 2 の「モヤモヤ」（実存接続）
• 段落 5 末尾「読みに来る側 ─ 画面の向こうの読者」（Round 5 W3 のメタファー橋）
• ダッシュは 2 個（タイトルにダッシュなしになったので、メタファー橋の ─ のみが残る計 1 個）

懸念: タイトルから掴みフレーズ「『どこに置けばいい？』」が消えたので、本文冒頭の引用との呼応は弱まる。一方、本文の引用は実存接続として独立して機能する。タイトルは「持ち込んだ」越境体験を直球で示す形に。

Round 10 改善ログ（段落 2 の Dioxus desktop 重複解消）#

ユーザー指摘「段落 2 の 2 文の繋がりに違和感」に対応。Round 9 で engine と editor の関係を明示するために入れた注記「(Dioxus desktopで実装)」が、1 文目の「Rust + Bevy + Dioxus desktop」と語彙重複していた。

修正:

「…ゲームエンジン『Bebeu』を作っています。エディタ部分**(Dioxus desktopで実装)**を書き進めるうちに、…」→「…ゲームエンジン『Bebeu』を作っています。そのエディタを書き進めるうちに、…」

• 注記を削除し「その」で指示接続。1 文目（Bebeu = engine + editor 全体）→ 2 文目（その中のエディタにフォーカス）の流れが明示
• engine と editor の分業説明はカット。段落 4「Rust の desktop アプリで通用するのか？」あたりで自然に補える範囲と判断

残った要素: 段落 2 の流れ「Bebeu 作っている → そのエディタを書き進めるうちに → ドメインと CRUD 機能の予感 → 手が止まる」で Cohesion-Coherence 両面が成立

Round 11 改善ログ（coherence-review 再実施）#

slop-review に進む前の coherence-review 通し。Round 10 までの修正の結果、新たに浮いた接続度の弱点 3 つに対応。

接続マップ診断結果（全体）:

• 段間接続度は概ね 7+ で安定
• スコア 5 未満は ①段 4→段 5、②段 4 内部「設計思想」反復、③段 3 内部「反復作業を疑う」→「Bebeu」の 3 つ
• Cohesion（語彙連鎖・接続詞）は強い、Coherence の論理橋が弱い箇所が残存

ワースト 3 修正:

• W1（段 4→段 5 論理橋）: 段 4 末「Webフロントエンド由来ですが、もともと特定の言語やフレームワークに依存しない設計思想として作られています。」を削除。段 5 冒頭に「採用例は見当たりません。」を 1 文追加。段 4 文 1「フロントエンド界隈で広まっている FSD」と段 5「Rust desktop では採用例なし」の対比が成立し、「それでも通用するか？」の論理橋が自然に。Coherence 5 → 8
• W2（段 4 内部 Restatement Loop）: 段 4 末削除で「設計思想です。…設計思想として作られています。」の「設計思想」2 連発が解消。Coherence 5 → 段落短縮で問題消滅
• W3（段 3 内部 Buried Setup）: 「反復作業を疑うのが日課です」→「反復作業を削るのが日課です」。段 3 末「スピードを確実に削っていく感覚」と「削る」で語彙接続成立。「SRE は反復作業を削る側 / 配置の悩みはスピードを削ってくる側」の逆襲構造が見える。Coherence 5 → 8

実装中の発見: W1+W2 の当初案（段 4 末を「Webフロントエンド界隈で広まっています。」に簡潔化）は、段 4 文 1「フロントエンド界隈で広まっている FSD」と「広まっている」が重複し別の Restatement Loop を生むことに気付き、段 4 末を削除に変更。これで段 4 が 3 文構成になるが、FSD の説明としては「定義 → 構造 → 思想」で完結。

トレードオフ:

• 「FSD は framework / language 非依存と公式に設計されている」事実が abstract から完全に消えた。Round 8 で Steiger 削除した時点でこの情報も役割を失っていたため、abstract で扱う情報密度の判断として整合
• 「反復作業を疑う」の問いかけのニュアンスが「削る」の実行アクション側に寄った。Slidev-video CFP の「Toil を削った話」と語彙が揃う副次効果あり

修正後の見立て: 全段間が 7+。接続マップ上、Coherence の弱点なし。次は slop-review で語彙・記号・装飾の磨き込み。

Round 12 改善ログ（slop-review 再実施）#

coherence-review (Round 11) の後に通した slop-review。5 軸暗黙評価は 36/50（書き直しライン 35 はクリア）で、削減と立場の 2 軸に残る課題に対応。

論点 3 つ（同時解消）:

• (a) 語彙: 「効く」系の連発: 段 5-7 の短い区間で「効きが倍 / そのまま効きます / 効いた越境体験 / 他領域でも効く実例」+ 近義「予想以上にハマりました」が 5 個密集
• (b) 立場: 段 7 末の抽象気味な持ち帰り: 「フロントエンド文化が他領域でも効く実例として持ち帰っていただきたいです」が「フロントエンド文化 / 他領域 / 効く」と抽象語の組み合わせ
• (c) 語彙: AI 常套副詞・昇華語: 「予想以上に」「個人開発の手応え」

修正:

• 段 5 末「フロントエンド発のアーキテクチャが、自作ゲームエンジンのエディタで予想以上にハマりました。」→「…自作ゲームエンジンのエディタで綺麗にハマりました。」（(a)+(c)）
• 段 6「promptにも、明日の自分にもそのまま効きます。」→「…そのまま使えます。」（(a)）
• 段 7 末（全体書き直し）:
  • 「効いた越境体験」→「噛み合った越境体験」
  • 「個人開発の手応え」→「個人開発の実感」
  • 「フロントエンド文化が他領域でも効く実例」→「言語もドメインも越えるアーキテクチャ移植のレシピ」（“言語”= Rust、“ドメイン”= ゲームエンジン、と二段具体化）

修正後の「効く」系分布: 段 6「効きが倍」のみに集約、近義は「ハマる」「噛み合う」に分散。連発感解消。

5 軸再評価:

• 立場 7 → 8（段 7 末の抽象抜け）
• リズム 7 → 7
• 主体性 8 → 8
• 具体性 8 → 8.5（“言語もドメインも越える” “移植のレシピ” で二段具体化）
• 削減 6 → 7（「効く」連発削減）
• 合計 36 → 38.5（書き直しライン 35 を余裕でクリア）

トレードオフ:

• 段 7 末はやや堅い表現「アーキテクチャ移植のレシピ」が入る。抽象抜けと具体化のトレードオフとして許容
• 「綺麗にハマる」「噛み合う」は擬音語的で口語度が増す。トーンがカジュアル寄りに

Round 13 改善ログ（段 6 の浮き文統合）#

ユーザー指摘「段 6『プロンプトにも、明日の自分にもそのまま使えます。』が浮いている」に対応。

背景: Round 12 後にユーザーが段 6 を手編集（「効きが倍 → さらに効果的」「prompt → プロンプト」+ 文 3 と文 2 の順序入れ替え）したことで、文 3「プロンプトにも、明日の自分にも…」が文 2「Rust が build error で止める」と文 4「読みに来る側」の間に挟まり、論点が宙ぶらりんに。文 3 は本来文 1「効果的になりました」の理由として機能するはずだった。

修正（案 C: 文 3 と文 4 を統合）:

• 旧: 「プロンプトにも、明日の自分にもそのまま使えます。半年後の自分も、AIエージェントも、わたしのコードを”読みに来る”側 ─ 画面の向こうの読者です。」

• 新: 「プロンプトにも、明日の自分にも、半年後の自分にも、AIエージェントにも、レイヤー名がそのまま通じます。みんな、わたしのコードを”読みに来る”側 ─ 画面の向こうの読者です。」

• 4 つの読者（プロンプト / 明日の自分 / 半年後の自分 / AI エージェント）を並列に列挙し、共通帰結「みんな読みに来る側」に繋ぐ構造

• 「プロンプト」と「明日の自分」（短期）+ 「半年後の自分」と「AI エージェント」（中長期）を 1 文にまとめることで、Round 5 W3 で構築した「読者メタファー」がより太く回収される

トレードオフ:

• 文 3 の「そのまま使えます」が「レイヤー名がそのまま通じます」に拡張され、何が使えるか（= レイヤー名）が明示。「使える」→「通じる」で語彙の言い換えにもなる
• 字数微増（+ 約 15 字）

ユーザーフィードバック反映#

• 「30 分で」削除: 最終段落「Rust と AI に増幅された越境体験を 30 分で共有します。」→「Rust と AI に増幅された越境体験を共有します。」。CFP フォームで枠（レギュラー 30 分）を選んだ時点で時間は決まっているため、abstract での所要時間表記は冗長
• ベタ詰め適用: タイトル候補とトーク概要本文の英数字・強調・半角括弧・半角引用符と日本語の境界の半角スペースを除去。英語フレーズ内 (Rust + Bevy + Dioxus desktop 等) のスペースと、em-dash ─ 前後、記号と日本語の境界 (？ 半年後 等) は維持
• Markdown 装飾の除去: トーク概要本文から強調 **...** とインラインコード `...` を除去。CNK 採択 abstract も装飾なし運用なので整合

採否予測の推移#

• Round 2 終了時 (型 + リズム済み): 3/5（FE 聴衆の自分ごと化 + テーマ接続の弱さがネック）
• Round 3 改善後想定: 3.5〜4/5（翻案レシピと “向こう側” の接続で両方の弱みに当てた）
• Round 4 終了時: 3.5〜4/5（Anti-Slop で公開ラインに到達）
• Round 5 終了時: 4/5（接続度の Coherence 弱点が抜け、Cohesion との両輪が成立）

留意事項（編成戦略）#

• Round 3 レビューで「LT 版が “FE 文化が外から流入する” のに対し、本案は “FE 文化が外へ流出する” 形で、編成上は同じ著者の LT の方が通しやすい可能性」が指摘された
• 重複採択不可の前提では、編成側が「Regular に FSD、LT に Slidev」と並べる可能性が現実的（または逆方向）。両案の独立性は維持されている
• スライド本編で pub/private を持つ他言語への翻案例（Java の package private、Swift の internal 等）を口頭で 1〜2 個出せると、abstract の約束を担保できる