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

Transcript

1. 拙者、 『型は欲しいが型は書きたくない』 者たちとの和睦を結び、 るびぃにおける型の領地安堵を 実現せんと欲す者也 大江森塚三矢大坂守小輔次郎真年 @sanfrecce_osaka 2026/05/30 #sekigahara01
2. 遠からん者は音にも聞け、近くば寄って目にも見よ 我こそは大江森塚三矢大坂守小輔次郎真年也 西軍一番槍の誉、至極名誉に存ずる 一世一代の祭、歌舞き狂わねば末代までの恥に御座る 故に本日は紅玉の赤備えで参陣いたした
3. 鈴威那按技術国 此度の戦の同盟国に御座る 兵站の刷新を旗印に掲げ日々東奔西走しておる 猫の忍を召し抱えておる 巣羅作の勝鬨の陣にて猛者共が日々勝鬨を上げておる 関ケ原対応企業と申しても過言では御座らぬであろう
4. 鈴威那按技術国の日常
5. 出陣
7. 謝 練度不足によりこれよりは 基本令和の言の葉にて失礼仕る
8. 貴公らにとって Ruby の型はどういう存在であろう？
9. 型の話題、二元論になりがち 型を好む人 型に気持ちのある人 型を書きたい人 VS 型を好まない人 型に気持ちのない人 型を書きたくない人
10. あいや待たれい
11. 言葉の認識や目線、前提は揃っておるか？ 型の話題に限らずこれが揃っていないと感じる場面に結構ある 紛糾している、レスバ・空中戦になっている議論や会話 揃えながら会話を進める重要さを KoR 2025(※1) の二次会で さんから学んだ それ以来、仕事をするうえでも非常に大事にしています(※2) ※1: Kaigi on Rails 2025 の略 ※2: 常にできているとは言っていません 注: 柔らかい状態の意見を表に出すことを禁じるものではないです @fusagiko
13. 例: 型に気持ちのある人 vs 型に気持ちのない人 型に気持ちのある人 型大好き！Ruby でも型安全！ 最終的には型は書きたくない だから型にコントリビュートしている 型に気持ちのない人 型の話題に全く興味がない Ruby に型なんて不要
14. 例: 型に気持ちのある人 vs 型に気持ちのない人 型に気持ちのある人 型大好き！Ruby でも型安全！ 最終的には型は書きたくない だから型にコントリビュートしている 型に気持ちのない人 型の話題に全く興味がない Ruby に型なんて不要 「型が不要」という気持ちがあるという見方もできる
15. 例: 型に気持ちのある人 vs 型に気持ちのない人 型に気持ちのある人 型大好き！Ruby でも型安全！ 最終的には型は書きたくない だから型にコントリビュートしている 型に気持ちのない人 型の話題に全く興味がない Ruby に型なんて不要 「型が不要」という気持ちがあるという見方もできる 「気持ちがある/ない」をポジティブ/ネガティブで分類するのは適切なのか？ 「気持ちがある/ない」ことを「型に対して肯定/否定的」というように捉えてしまっていないか？
16. 型は欲しいが型は書きたくない Rubyist の型に対する気持ちとしての代表格 とにかくよく使われる しかし様々な要素が含まれすぎている 今回はこの言葉に焦点を当てます
17. この発表の目的 Ruby における「型」についての目線を合わせること 型に詳しい人でなくても型の恩恵を受けられるための道筋を探る
19. 1. 要素の分解
20. 型は欲しいが型は書きたくない
21. 型シグネチャ 型推論 型検査 型システム
22. 型は欲しいが型は書きたくない
23. 型は欲しい(== 型の恩恵は受けたい) ドキュメント 型検査 入力補完 コードジャンプ
24. 型は欲しいが型は書きたくない
25. 型は書きたくない 理由 型のためのコードを書きたくな い 型を書くメリットを感じない 型を書くのが面倒 型の文法を覚えたくない 型を保守したくない 範囲 ライブラリ含めて全部 アプリケーションコード全体 主要でない部分(private 等) 手段 自動生成でも型を書きたくない 手動では型を書きたくない
26. 2. 考察と提案
27. 2.1. (先に)方針の提示 ドキュメントの話と型検査・型推論の話は分けて考えよう AI を使った型のメンテと型をなるべく意識しない開発体験
28. ドキュメントの話と型検査・型推論の話は 分けて考えよう
29. 2.2. AI 時代に型は必要なのか
30. 型は欲しい(== 型の恩恵は受けたい) ドキュメント 型検査 入力補完 コードジャンプ
31. 型は欲しい(== 型の恩恵は受けたい) ドキュメント 型検査 入力補完 コードジャンプ コーディングエージェントの進化によりエディタから受ける恩恵が減少
32. https://x.com/sinsoku_listy/status/2057773924335976759?s=20
33. LSP https://azukiazusa.dev/blog/claude-code-lsp-support/
34. Rubydex / translated by ( ) en ja @hachi8833 RubyKaja特別賞
35. Spinel https://github.com/matz/spinel/pull/618
36. ここまでの結論 長期的に見ると型から恩恵を受ける余地は まだまだ残っていそう
37. 2.3. Ruby における型推論・型検査
38. 型は書きたくない理由 主要因が型検査によるものがほとんどではないか？ 理由 型のためのコードを書きたくな い 型を書くメリットを感じない 型を書くのが面倒 型の文法を覚えたくない 型を保守したくない 範囲 ライブラリ含めて全部 アプリケーションコード全体 主要でない部分(private 等) 手段 自動生成でも型を書きたくない 手動では型を書きたくない
39. 偽陽性に対するヘイト 本質的ではない コードが 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
40. RubyKaigi 2019 Keynote by Matz 型を書くことに対する言及 これも型を書くことが型検査をするために書くものという前提になっていそう 型宣言嫌いなんですよね。なんでかっていうと DRY じゃないからなん ですよ。今私達の書いている Ruby のプログラムは型宣言ないんです ね。で、それでもちゃんと動いているんですよ。それに対してさらに情 報を付け加えるっていうのはなんかこうコンピュータに仕事をさせられ ている感じがするわけですよね。本当はコンピュータが私達のために働 いてほしい。 https://youtu.be/WZu-WVzbEOA?si=b3kkPGV630GeUzGn&t=334
41. 型推論・型検査ツール戦国時代 型推論 + 型検査 型検査 型推論 どこまで型検査に求めるかが人によって好みが分かれる エコシステム側でデフォルトを見出すのは難しい 似たケースだと rubocop 型推論も決め手になるものがない(特に RBS を利用する場合) Sorbet TypeProf Solargraph Method-Ray Steep Ruby LSP Guessed type TypeGuessr
42. Ruby における型推論・型検査の結論 Ruby では型検査は optional なものとして扱うのが良さそう 型推論もデフォルトになるものはまだない 特に RBS を利用する場合
43. 新勢力による奇襲 (リガー) by @tadsan Rigor 元ツイート 元ツイート
45. PHP Conference Japan 2026 で話を聞けるかも (2026/07/20 開催) https://fortee.jp/phpcon-2026/proposal/97e0a9cc-9f25-4138-be4e-516cd20c282a
46. 関西Ruby会議09 もよろしく (2026/07/18 開催) https://regional.rubykaigi.org/kansai09/
47. 閑話休題
48. 2.4. Ruby におけるドキュメントと型
49. RubyKaigi 2019 Keynote by Matz 型検査のために型を書くからコンピュータに仕事をさせられている感じがする ドキュメントは人のためという側面が強い ドキュメントのための型ならコンピュータに仕事をさせられている感じはなくなるのでは？ 型宣言嫌いなんですよね。なんでかっていうと DRY じゃないからなん ですよ。今私達の書いている Ruby のプログラムは型宣言ないんです ね。で、それでもちゃんと動いているんですよ。それに対してさらに情 報を付け加えるっていうのはなんかこうコンピュータに仕事をさせられ ている感じがするわけですよね。本当はコンピュータが私達のために働 いてほしい。 https://youtu.be/WZu-WVzbEOA?si=b3kkPGV630GeUzGn&t=334
50. ドキュメントで型シグネチャを使っていこう 型シグネチャを書くことは型検査と必ずしもセットではない 「ドキュメントを書くのが面倒」はあれど「ドキュメントを書く メリットはない」はないはず 「ドキュメントを書くのが面倒」は AI が解決してくれる
51. 型シグネチャはドキュメントの表現として非常に有用 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
52. 型シグネチャは仕様のサマリなので概観を把握しやすい 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
53. 書くとして全部に書かなければいけないの？ 理由 型のためのコードを書きたくな い 型を書くメリットを感じない 型を書くのが面倒 型の文法を覚えたくない 型を保守したくない 範囲 ライブラリ含めて全部 アプリケーションコード全体 主要でない部分(private 等) 手段 自動生成でも型を書きたくない 手動では型を書きたくない
54. ドキュメントも型もすべてに書く必要はない Effective TypeScript「推論できる型でコードを散らかすな」 https://speakerdeck.com/andpad/effective-typescript-haiizo?slide=11
55. ちなみに
56. 例のあの図 https://zenn.dev/mametter/articles/3e8580ec034201
57. トークンの効率を考えたら こういう構成がありになる可能性 .rb 型・ドキュメントは書かない ⇔ AI エディタ 参照 (LSP 経由) ⇐ ⇒ 編集 .rbs ドキュメント rbs-inline (Doc style syntax) RBS
58. 閑話休題
59. Ruby におけるドキュメントと型の結論 Ruby における型が 最低限安堵されるべき領地は ドキュメントと型シグネチャである
60. 2.5. AI を使った型のメンテと 型をなるべく意識しない開発体験
61. 現状の型(RBS)を伴った開発の問題
62. ライブラリの型の圧倒的不足 の Gemfile を対象に調査 型定義なしが約7割 型がついていてもメンテが追いついていないものも多い discourse 調査結果
63. DSL への対応が進まない RBI(Tapioca) には がある RBS は都度独自実装と の 2 派閥ある( ) が仕組み的によくできていて自分はすごく推している 規約があるので AI とも相性がいい が、利用者を殆ど見かけない ドキュメントや利用事例が足りない DSL Compiler orthoses 参考 orthoses
64. 導入するまでに必要な手数が多い 特に開発が進んでいるアプリケーションへの導入障壁が高い 導入時に追加・設定が必要な gem(例: ) or orthoses-xxx 等(DSL によるメソッド定義に対する型生成) Rails アプリケーション rbs repl_type_completor orthoses-rails rbs_rails rbs-trace rbs-inline steep
65. 導入してからも必要な手数が多い rbs collection install / update テスト(rbs-trace のため) rbs-inline orthoses-rails or rbs_rails 定期アップデート(dependabot/renovate) dependabot も revovate も対応していない 自前で定期更新用の仕組みを組まないといけない
66. これらを解決する gem を つくっています
67. sigsa 仕草(sigsa) 仕事(sigoto) とどちらにするかすごく迷っている 型関連の各ツールの統合(インテグレーション) を担う
68. 実装間に合ってません😇 5/2〜5/6 まで、GW まるっと風邪引いて作業時間が消し飛んだ スライドが二転三転 連日夜襲を仕掛けるも寡兵での戦続きで我が方の体力が限界 今後は筋肉衆の再調練が必要
69. 現状できること
70. 1. skill による型定義のサポート AI はやり方と方針さえ決めておけば 結構良い精度で型を書いてく れる AI に任せきりにせず人間もコードを読んで最終的な精度を上げる 実装と乖離していないかをテストで検証できると今後良いのでは 現状以下の skill を提供している gem のバージョンアップに伴う gem_rbs_collection の型の更 新 orthoses のミドルウェアの初期実装
71. 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
72. 2. bundler と rbs collection の統合 bundle install / update を実行すると rbs collection install / update も走る から着想 bundler の plugin によるフック機構を利用 typesync
73. 3. 型導入の scaffold やること gem の追加 設定ファイルや関連ファイル(.gitignore 等)のセットアップ 対応済 rbs repl_type_completor rbs-trace rbs-inline steep alias で sigaffold
74. 関西Ruby会議09 もよろし(ry (2026/07/18 開催) https://regional.rubykaigi.org/kansai09/
75. まとめ 何事も認識を揃えつつ議論を進めてほしい ドキュメントで型シグネチャを使っていこう AI の力も借りながら Ruby の開発体験を引き続き良くしていくぞ
76. 御清聴痛み入る 恐悦至極に御座りまする