← 提出本文に戻る

校正過程

校正過程: フロントエンド発のFSDをRust製ゲームエンジンで守らせた話

対応する提出本文: 『これ、どこに置けばいい？』─ フロントエンド発のFSDを、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 との両輪が成立した状態

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

  • 「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 の約束を担保できる