OpenAPI 3.1 が書きたくて
＆ RuboCop を白バイに乗せてみた
2026/07/13
フサギコ fusagiko
self.introduction
↑
RubyMusicMixin 2024でDJしたとき
RubyKaigi 2026
楽しかったですね！
函館山登って夜景見たり
五稜郭行ったり
明治初期の和洋折衷の街並みを観光したり
Day3のスポンサードイベントで発表したり
Day3のスポンサードイベントで発表したり
RubyKaigiは
毎回楽しい
(行ったことない土地行けるし)
しかし今回
いつもと違って
印象に残ったことがある
Matzキーノート
去年までは
コミュニティの方向性を
示すのが主だった
LLM、coding agentの進化
OSSにAI出力コードを
使うことの是非は
立場が分かれうるが…
そうは言っても
猫の手も借りたい
ところもある
OpenAPI
皆さんOpenAPIってご存じですか
jsonスキーマをベースに
API仕様を定義する
マシンリーダブルなスキーマ記述規格
RubyでOpenAPIを扱うgem
committee
しかしこのcommittee
OpenAPI 3.0までの対応
OpenAPI 3.1書きたい！
OpenAPI 3.1書けると何が嬉しいか
type: nullが書ける
OpenAPI3.0におけるnullableの書き方
name: nullable_attr
type: string
nullable: true
OpenAPI3.1におけるnullableの書き方
name: nullable_attr
oneOf:
- type: string
- type: null
これだとOpenAPI3.0のほうが
よさそうに見える？
と思うじゃないですか
object OR nullなkeyでは
nullableが使えない
OpenAPI3.0でobject OR nullを書く方法(1)
name: null_or_object_attr
nullable: true
oneOf:
- type: object
properties: (略)
OpenAPI3.0でobject OR nullを書く方法(1)
name: null_or_object_attr
nullable: true
oneOf:
- type: object
properties: (略)
1種しかないのに
nullableのためだけに
挟まる謎のoneOf
OpenAPI3.0でobject OR nullを書く方法(2)
name: null_or_object_attr
oneOf:
- type: string
nullable: true
enum:
- null
- type: object
properties: (略)
OpenAPI3.0でobject OR nullを書く方法(2)
name: null_or_object_attr
oneOf:
- type: string
nullable: true
enum:
- null
- type: object
properties: (略)
nullを表現するための
謎のworkaround
OpenAPI3.1でのobject OR nullの書き方
name: null_or_object_attr
oneOf:
- type: null
- type: object
properties: (略)
OpenAPI3.1でのobject OR nullの書き方
name: null_or_object_attr
oneOf:
- type: null
- type: object
properties: (略)
書き方が1つに収束
迷わない！
しかしcommitteeは
OpenAPI 3.0まで
issueも開きっぱなし (上: committee, 下: openapi_parser)
issueも開きっぱなし (上: committee, 下: openapi_parser)
正直メンテが活発ではない
待ってても期待できない
でもやっぱり、
OpenAPI 3.1書きたい！！！
というわけで
名乗りを上げて、大方針の同意をもらって
順次、ルールをcontribute中
あと12個くらいPR要るけど
地道にやっていきます
もう一つ
こっちは個人的、技術的興味として
RuboCop
RuboCopは
皆さんご存じですよね
きっと皆さん使ってらっしゃる
偉大なるlinter
RuboCopのルールって、
コールバックベースで書かれている
on_block: ブロックが出るたび呼ばれる
on_send: メソッド呼び出しのたび呼ばれる
それらコールバックの中で
条件に該当したらadd_offense
つまり1ファイルにつき何回も
rubyメソッド呼び出しがされる
対象ファイル数 x 該当箇所数 x ルール数
しかしRuboCopのルールって
長期間変わっていないものもある
Rubyのparserは最近prismが主となり
prismはrustバインディングもある
rubydexとかが使ってる
しかもRuboCopも最近
prism ASTベースに移行した
(2025年3月 RuboCop-ast v1.43.0)
じゃあprismのAST直接横取りして
rustで解析させたら
爆速になるのでは？
作ってみました
shirobai
shirobaiのcopのruby側
shirobaiのcopのruby側
shirobaiのcopのruby側
shirobaiのcopのruby側
shirobaiのcopのruby側
shirobaiのcopのrust側
rust側
なんもわからん
与えたのは制約と定量指標だけ
(RuboCopと完全互換、実行時間短縮)
遅いルールのプロファイリング
チューニング、AST走査の1pass化まで
僕自身は指示をし続けただけ
しかしてその成果は…？
25～40%程度の短縮！
25～40%程度の短縮！
コード規模によっては
遅くなるかも
既知の制約
まとめ