拙者、『型は欲しいが型は書きたくない』者たちとの和睦を結び、るびぃにおける型の領地安堵を実現せんと欲す者也 #sekigahara01/sekigahara01

by Masatoshi Moritsuka

Embed

Start on current slide

Slide 1

Slide 1 text

拙者、『型は欲しいが型は書きたくない』者たちとの和睦を結び、るびぃにおける型の領地安堵を実現せんと欲す者也大江森塚三矢大坂守小輔次郎真年 @sanfrecce_osaka 2026/05/30 #sekigahara01

Slide 2

Slide 2 text

遠からん者は音にも聞け、近くば寄って目にも見よ我こそは大江森塚三矢大坂守小輔次郎真年也西軍一番槍の誉、至極名誉に存ずる一世一代の祭、歌舞き狂わねば末代までの恥に御座る故に本日は紅玉の赤備えで参陣いたした

Slide 3

Slide 3 text

鈴威那按技術国此度の戦の同盟国に御座る兵站の刷新を旗印に掲げ日々東奔西走しておる猫の忍を召し抱えておる巣羅作の勝鬨の陣にて猛者共が日々勝鬨を上げておる関ケ原対応企業と申しても過言では御座らぬであろう

Slide 4

Slide 4 text

鈴威那按技術国の日常

Slide 5

Slide 5 text

出陣

Slide 6

Slide 6 text

No content

Slide 7

Slide 7 text

謝練度不足によりこれよりは基本令和の言の葉にて失礼仕る

Slide 8

Slide 8 text

貴公らにとって Ruby の型はどういう存在であろう？

Slide 9

Slide 9 text

型の話題、二元論になりがち型を好む人型に気持ちのある人型を書きたい人 VS 型を好まない人型に気持ちのない人型を書きたくない人

Slide 10

Slide 10 text

あいや待たれい

Slide 11

Slide 11 text

言葉の認識や目線、前提は揃っておるか？型の話題に限らずこれが揃っていないと感じる場面に結構ある紛糾している、レスバ・空中戦になっている議論や会話揃えながら会話を進める重要さを KoR 2025(※1) の二次会でさんから学んだそれ以来、仕事をするうえでも非常に大事にしています(※2) ※1: Kaigi on Rails 2025 の略 ※2: 常にできているとは言っていません注: 柔らかい状態の意見を表に出すことを禁じるものではないです @fusagiko

Slide 12

Slide 12 text

No content

Slide 13

Slide 13 text

例: 型に気持ちのある人 vs 型に気持ちのない人型に気持ちのある人型大好き！Ruby でも型安全！最終的には型は書きたくないだから型にコントリビュートしている型に気持ちのない人型の話題に全く興味がない Ruby に型なんて不要

Slide 14

Slide 14 text

例: 型に気持ちのある人 vs 型に気持ちのない人型に気持ちのある人型大好き！Ruby でも型安全！最終的には型は書きたくないだから型にコントリビュートしている型に気持ちのない人型の話題に全く興味がない Ruby に型なんて不要「型が不要」という気持ちがあるという見方もできる

Slide 15

Slide 15 text

例: 型に気持ちのある人 vs 型に気持ちのない人型に気持ちのある人型大好き！Ruby でも型安全！最終的には型は書きたくないだから型にコントリビュートしている型に気持ちのない人型の話題に全く興味がない Ruby に型なんて不要「型が不要」という気持ちがあるという見方もできる「気持ちがある/ない」をポジティブ/ネガティブで分類するのは適切なのか？「気持ちがある/ない」ことを「型に対して肯定/否定的」というように捉えてしまっていないか？

Slide 16

Slide 16 text

型は欲しいが型は書きたくない Rubyist の型に対する気持ちとしての代表格とにかくよく使われるしかし様々な要素が含まれすぎている今回はこの言葉に焦点を当てます

Slide 17

Slide 17 text

この発表の目的 Ruby における「型」についての目線を合わせること型に詳しい人でなくても型の恩恵を受けられるための道筋を探る

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

1. 要素の分解

Slide 20

Slide 20 text

型は欲しいが型は書きたくない

Slide 21

Slide 21 text

型シグネチャ型推論型検査型システム

Slide 22

Slide 22 text

型は欲しいが型は書きたくない

Slide 23

Slide 23 text

型は欲しい(== 型の恩恵は受けたい) ドキュメント型検査入力補完コードジャンプ

Slide 24

Slide 24 text

型は欲しいが型は書きたくない

Slide 25

Slide 25 text

型は書きたくない理由型のためのコードを書きたくない型を書くメリットを感じない型を書くのが面倒型の文法を覚えたくない型を保守したくない範囲ライブラリ含めて全部アプリケーションコード全体主要でない部分(private 等) 手段自動生成でも型を書きたくない手動では型を書きたくない

Slide 26

Slide 26 text

2. 考察と提案

Slide 27

Slide 27 text

2.1. (先に)方針の提示ドキュメントの話と型検査・型推論の話は分けて考えよう AI を使った型のメンテと型をなるべく意識しない開発体験

Slide 28

Slide 28 text

ドキュメントの話と型検査・型推論の話は分けて考えよう

Slide 29

Slide 29 text

2.2. AI 時代に型は必要なのか

Slide 30

Slide 30 text

型は欲しい(== 型の恩恵は受けたい) ドキュメント型検査入力補完コードジャンプ

Slide 31

Slide 31 text

型は欲しい(== 型の恩恵は受けたい) ドキュメント型検査入力補完コードジャンプコーディングエージェントの進化によりエディタから受ける恩恵が減少

Slide 32

Slide 32 text

https://x.com/sinsoku_listy/status/2057773924335976759?s=20

Slide 33

Slide 33 text

LSP https://azukiazusa.dev/blog/claude-code-lsp-support/

Slide 34

Slide 34 text

Rubydex / translated by ( ) en ja @hachi8833 RubyKaja特別賞

Slide 35

Slide 35 text

Spinel https://github.com/matz/spinel/pull/618

Slide 36

Slide 36 text

ここまでの結論長期的に見ると型から恩恵を受ける余地はまだまだ残っていそう

Slide 37

Slide 37 text

2.3. Ruby における型推論・型検査

Slide 38

Slide 38 text

型は書きたくない理由主要因が型検査によるものがほとんどではないか？理由型のためのコードを書きたくない型を書くメリットを感じない型を書くのが面倒型の文法を覚えたくない型を保守したくない範囲ライブラリ含めて全部アプリケーションコード全体主要でない部分(private 等) 手段自動生成でも型を書きたくない手動では型を書きたくない

Slide 39

Slide 39 text

偽陽性に対するヘイト本質的ではないコードが Ruby っぽくなくなるテストでカバーできるケースが多い def bushou_hash(users) user = users.find(&:bushou?) || raise # <= こういうやつとか { id: user.id, name: user.name } end def daimyou_hash(users) user = users.find(&:daimyou?) { id: (user || raise).id, name: (user || raise).name } # <= こういうやつとか end def ashigaru_hash(users) user = users.find(&:ashigaru?) { id: user.id, name: user.name } # steep:ignore -- こういうやつとか end

Slide 40

Slide 40 text

RubyKaigi 2019 Keynote by Matz 型を書くことに対する言及これも型を書くことが型検査をするために書くものという前提になっていそう型宣言嫌いなんですよね。なんでかっていうと DRY じゃないからなんですよ。今私達の書いている Ruby のプログラムは型宣言ないんですね。で、それでもちゃんと動いているんですよ。それに対してさらに情報を付け加えるっていうのはなんかこうコンピュータに仕事をさせられている感じがするわけですよね。本当はコンピュータが私達のために働いてほしい。 https://youtu.be/WZu-WVzbEOA?si=b3kkPGV630GeUzGn&t=334

Slide 41

Slide 41 text

型推論・型検査ツール戦国時代型推論 + 型検査型検査型推論どこまで型検査に求めるかが人によって好みが分かれるエコシステム側でデフォルトを見出すのは難しい似たケースだと rubocop 型推論も決め手になるものがない(特に RBS を利用する場合) Sorbet TypeProf Solargraph Method-Ray Steep Ruby LSP Guessed type TypeGuessr

Slide 42

Slide 42 text

Ruby における型推論・型検査の結論 Ruby では型検査は optional なものとして扱うのが良さそう型推論もデフォルトになるものはまだない特に RBS を利用する場合

Slide 43

Slide 43 text

新勢力による奇襲 (リガー) by @tadsan Rigor 元ツイート元ツイート

Slide 44

Slide 44 text

No content

Slide 45

Slide 45 text

PHP Conference Japan 2026 で話を聞けるかも (2026/07/20 開催) https://fortee.jp/phpcon-2026/proposal/97e0a9cc-9f25-4138-be4e-516cd20c282a

Slide 46

Slide 46 text

関西Ruby会議09 もよろしく (2026/07/18 開催) https://regional.rubykaigi.org/kansai09/

Slide 47

Slide 47 text

閑話休題

Slide 48

Slide 48 text

2.4. Ruby におけるドキュメントと型

Slide 49

Slide 49 text

RubyKaigi 2019 Keynote by Matz 型検査のために型を書くからコンピュータに仕事をさせられている感じがするドキュメントは人のためという側面が強いドキュメントのための型ならコンピュータに仕事をさせられている感じはなくなるのでは？型宣言嫌いなんですよね。なんでかっていうと DRY じゃないからなんですよ。今私達の書いている Ruby のプログラムは型宣言ないんですね。で、それでもちゃんと動いているんですよ。それに対してさらに情報を付け加えるっていうのはなんかこうコンピュータに仕事をさせられている感じがするわけですよね。本当はコンピュータが私達のために働いてほしい。 https://youtu.be/WZu-WVzbEOA?si=b3kkPGV630GeUzGn&t=334

Slide 50

Slide 50 text

ドキュメントで型シグネチャを使っていこう型シグネチャを書くことは型検査と必ずしもセットではない「ドキュメントを書くのが面倒」はあれど「ドキュメントを書くメリットはない」はないはず「ドキュメントを書くのが面倒」は AI が解決してくれる

Slide 51

Slide 51 text

型シグネチャはドキュメントの表現として非常に有用 yard のタグよりも rbs の方が表現力が高い # こっちより # # @param bar [Hash{Symbol=>String,Integer}] key は uuid・name・age で age は optional、uuid は UUIDv4 形式 # @return [Foo] 〇〇な ☓☓ def foo(bar) # こっちの方が表現力が高い # # @rbs bar: { uuid: String, name: String, ?age: Integer } -- uuid は UUIDv4 形式 # @rbs return: Foo -- 〇〇な ☓☓ def foo: ({ id: Integer, name: String, ?age: Integer } bar) -> Foo

Slide 52

Slide 52 text

型シグネチャは仕様のサマリなので概観を把握しやすい module Ancestry module HasAncestry def has_ancestry: (?{ ?ancestry_column: String | Symbol, ?orphan_strategy: :destroy | :rootify | :restrict | :adopt | :none, ?cache_depth: bool | String | :virtual | Symbol, ?depth_cache_column: String | Symbol, ?touch: bool, ?counter_cache: bool | String | Symbol, ?primary_key_format: '[0-9]+' | '[-A-Fa-f0-9]{36}', ?update_strategy: :sql | :ruby, ?ancestry_format: :materialized_path | :materialized_path2 } options) -> void gem_rbs_collection/gems/ancestry/5.1/ancestry/has_ancestry.rbs

Slide 53

Slide 53 text

書くとして全部に書かなければいけないの？理由型のためのコードを書きたくない型を書くメリットを感じない型を書くのが面倒型の文法を覚えたくない型を保守したくない範囲ライブラリ含めて全部アプリケーションコード全体主要でない部分(private 等) 手段自動生成でも型を書きたくない手動では型を書きたくない

Slide 54

Slide 54 text

ドキュメントも型もすべてに書く必要はない Effective TypeScript「推論できる型でコードを散らかすな」 https://speakerdeck.com/andpad/effective-typescript-haiizo?slide=11

Slide 55

Slide 55 text

ちなみに

Slide 56

Slide 56 text

例のあの図 https://zenn.dev/mametter/articles/3e8580ec034201

Slide 57

Slide 57 text

トークンの効率を考えたらこういう構成がありになる可能性 .rb 型・ドキュメントは書かない ⇔ AI エディタ参照 (LSP 経由) ⇐ ⇒ 編集 .rbs ドキュメント rbs-inline (Doc style syntax) RBS

Slide 58

Slide 58 text

閑話休題

Slide 59

Slide 59 text

Ruby におけるドキュメントと型の結論 Ruby における型が最低限安堵されるべき領地はドキュメントと型シグネチャである

Slide 60

Slide 60 text

2.5. AI を使った型のメンテと型をなるべく意識しない開発体験

Slide 61

Slide 61 text

現状の型(RBS)を伴った開発の問題

Slide 62

Slide 62 text

ライブラリの型の圧倒的不足の Gemfile を対象に調査型定義なしが約7割型がついていてもメンテが追いついていないものも多い discourse 調査結果

Slide 63

Slide 63 text

DSL への対応が進まない RBI(Tapioca) にはがある RBS は都度独自実装との 2 派閥ある( ) が仕組み的によくできていて自分はすごく推している規約があるので AI とも相性がいいが、利用者を殆ど見かけないドキュメントや利用事例が足りない DSL Compiler orthoses 参考 orthoses

Slide 64

Slide 64 text

導入するまでに必要な手数が多い特に開発が進んでいるアプリケーションへの導入障壁が高い導入時に追加・設定が必要な gem(例: ) or orthoses-xxx 等(DSL によるメソッド定義に対する型生成) Rails アプリケーション rbs repl_type_completor orthoses-rails rbs_rails rbs-trace rbs-inline steep

Slide 65

Slide 65 text

導入してからも必要な手数が多い rbs collection install / update テスト(rbs-trace のため) rbs-inline orthoses-rails or rbs_rails 定期アップデート(dependabot/renovate) dependabot も revovate も対応していない自前で定期更新用の仕組みを組まないといけない

Slide 66

Slide 66 text

これらを解決する gem をつくっています

Slide 67

Slide 67 text

sigsa 仕草(sigsa) 仕事(sigoto) とどちらにするかすごく迷っている型関連の各ツールの統合(インテグレーション) を担う

Slide 68

Slide 68 text

実装間に合ってません😇 5/2〜5/6 まで、GW まるっと風邪引いて作業時間が消し飛んだスライドが二転三転連日夜襲を仕掛けるも寡兵での戦続きで我が方の体力が限界今後は筋肉衆の再調練が必要

Slide 69

Slide 69 text

現状できること

Slide 70

Slide 70 text

1. skill による型定義のサポート AI はやり方と方針さえ決めておけば結構良い精度で型を書いてくれる AI に任せきりにせず人間もコードを読んで最終的な精度を上げる実装と乖離していないかをテストで検証できると今後良いのでは現状以下の skill を提供している gem のバージョンアップに伴う gem_rbs_collection の型の更新 orthoses のミドルウェアの初期実装

Slide 71

Slide 71 text

skill を使った例 https://github.com/sanfrecce-osaka/orthoses-ancestry https://github.com/ruby/gem_rbs_collection/pull/1032 https://github.com/ruby/gem_rbs_collection/pull/1033 https://github.com/ruby/gem_rbs_collection/pull/1034

Slide 72

Slide 72 text

2. bundler と rbs collection の統合 bundle install / update を実行すると rbs collection install / update も走るから着想 bundler の plugin によるフック機構を利用 typesync

Slide 73

Slide 73 text

3. 型導入の scaffold やること gem の追加設定ファイルや関連ファイル(.gitignore 等)のセットアップ対応済 rbs repl_type_completor rbs-trace rbs-inline steep alias で sigaffold

Slide 74

Slide 74 text

関西Ruby会議09 もよろし(ry (2026/07/18 開催) https://regional.rubykaigi.org/kansai09/

Slide 75

Slide 75 text

まとめ何事も認識を揃えつつ議論を進めてほしいドキュメントで型シグネチャを使っていこう AI の力も借りながら Ruby の開発体験を引き続き良くしていくぞ