はじめに
kickflowでバックエンドエンジニアをしているワイハナです。Rubyに関しては初心者で、本格的に触り始めたのは入社（2026年2月）してからです。
弊社は、2026年4月22日から24日にかけて函館で開催された RubyKaigi 2026 にスポンサーとして参加しました。今回が初めてのRubyKaigiスポンサー出展となります。エンジニア5名、人事3名の合計8名で函館へ向かい、3日間ブースを運営しながら、各自セッションにも参加しました。
提供しているクラウドワークフローシステムはRuby on Railsで開発しており、Rubyは事業の根幹を支える技術です。プログラミング言語としてのRubyやコミュニティの活動から日々恩恵を受けている事業会社として、何らかの形で貢献し、直接コミュニティに触れる場を持ちたい。そんな思いから、今回のスポンサー出展となりました。
この記事では、ブース運営の様子と、印象に残ったセッションを中心にお届けします。
ブース運営
なぜ「利きAIクイズ」だったのか
kickflowでは日々の開発でAIを積極的に活用しています。コードを書く場面はもちろん、ドキュメント作成、調査、テスト、運用にいたるまで、複数のAIモデルを使い分けながら仕事を進めるのが当たり前の風景になっています。
ブースの企画を考える段階で、せっかくならkickflowの普段の開発文化と地続きのものを、と「利きAIクイズ」を選びました。同じプロンプトに対する複数モデル（ChatGPT / Claude / Gemini）の回答を見比べていただき、「どのモデルが書いたか」を当てていただくクイズです。全部で5問用意しました。
想定外がそのまま会話の入口に
当初は日本語版のみで準備していたのですが、海外からの参加者が想像以上に多く、初日途中で急遽 Google フォームで英語版を作成しました。
Day2からは会場全体でスタンプラリーが始まり、ブースを訪れる方が前日よりも増えました。スタンプを準備していなかったため、近所の百均で買ったシールに「k」と書いてスタンプ代わりに使う、という即興対応もありました。準備不足ではあったのですが、結果として、こうした手作り感もそのまま会話のきっかけになっていた気がします。
クイズの題材がAIだったこともあり、解いている間に「◯◯は絵文字を使いがち」など、参加してくださった方それぞれが日々感じているAIのクセを教えていただく場面が多くありました。そこから「普段どのモデルを使っているか」「どんな使い分けをしているか」といった話題へ自然と広がっていき、エンジニア同士の技術談義のきっかけになりました。
自社プロダクトをどう伝えるか
ブースで来場者の方とお話しするなかで気づいたのは、エンジニアが集まる場で自社プロダクトをどう紹介するか、というところでした。
kickflowはクラウドワークフローシステムですが、「稟議」という言葉そのものは、エンジニアの方や海外からの参加者の方にはあまり馴染みがありません。「稟議システムです」と一言で言うだけでは伝わりにくい場面が多く、ブースに立っていて早い段階で気づきました。
エンジニアの方には、まず「最近、なにか申請しましたか？」と尋ねるところから話を始めるようにしました。「会社で申請する」という、ほぼ全員が経験している身近な行為を出発点にしてから、「その裏側を支えるプロダクトです」とつなぐと、ぐっと話が伝わりやすくなります。海外からの参加者の方には、相手の業務にある承認や申請のプロセスに置き換えながら、「日本の会社にはこういう承認フローが必要で、それを支えるのがこのプロダクトです」と説明していくことを意識しました。
プロダクトを説明する言葉は、相手の文脈に合わせて選ぶ必要があるんだな、と気づきました。
AI時代のRuby — 印象に残ったセッション
今回のRubyKaigiでは、セッション全体を通じて「AI」が一つの大きなテーマになっていた印象です。Rubyという言語そのものがAI時代にどう向き合っていくのか、コミッタはAIをどう自分の道具として取り込んでいるのか。そうした問いを、いろんな角度から考えさせられた3日間でした。
ここでは、特に印象に残ったセッションをいくつか紹介します。
Ruby Committers and the World
rubykaigi.org CRubyのコミッタによる恒例のパネルセッション Ruby Committers and the World では、AIをめぐる開発のあり方や、Rubyの今後の意思決定のあり方について議論が交わされました。 特に印象に残ったのは、AIが書いたコードをどう扱うかという話題のなかで、「自分の署名つきでコミットしたものは、自分が責任を持つ」という考え方を語っていた方がいたことでした。AIが書いたコードであっても、それを世に出す主体は最終的に人間であり、署名はその責任の所在を明示するものだ、という整理です。AIを開発に取り込んでいる組織であれば一度は向き合うことになる論点を、Rubyのコミッタが日々どう考えているかが垣間見える話でした。
Autoresearching Ruby Performance with LLMs
rubykaigi.org Nate Berkopec さんの Autoresearching Ruby Performance with LLMs は、LLMエージェントを使ってRubyのパフォーマンス問題を自動でリサーチする取り組みの発表でした。LLM、MCP、スクリプト、スキルを組み合わせて再現可能なベンチマーク環境を構築し、agent-native なパフォーマンス改善ワークベンチを作り上げるアプローチと、その現状での限界が紹介されました。 「LLMが計測する／LLMが原因の仮説を立てる／LLMが改善案を試す」という、人間のパフォーマンスエンジニアが普段やっている試行錯誤のループを、エージェントに丸ごと代行させようという挑戦でした。kickflowの開発でもパフォーマンスチューニングは継続的なテーマなので、「LLMにベンチマークを任せる」という発想は、持ち帰って試してみたいなと思いました。
Matz Keynote — Spinel
rubykaigi.org 3日目のクロージングを締めくくった Matz Keynote で発表されたのが、新しいAOTコンパイラ Spinel GitHub - matz/spinel · GitHub でした。Rubyのコードを一度C言語に変換し、Cコンパイラでネイティブバイナリにコンパイルする仕組みで、起動時間や実行性能の面でのメリットを目的としています。 自分にとってインパクトが大きかったのは、Spinelの実装の 大部分がAIによって書かれた ということでした。Matzご自身がAIに指示を出しながら開発を進めたとのことで、「これまでヒューマンインテリジェンス（コミッタの方々）に頼んでいたことが、AIに頼むようになっただけ」という旨の言葉が会場から大きな反応を呼んでいました。Rubyの生みの親がAIを開発の道具としてここまで使いこなしているのは、自分にはかなり意外でした。
もうひとつのRuby — 実行系と表現の多様性
AI関連のテーマとはまた別に、RubyKaigiの面白さの一つは、Rubyの実行系や表現の幅広さに触れられるところにあります。CRubyの新しい機能から別実装、軽量な環境への移植まで、「Rubyという言語をどこで・どう動かすか」の選択肢が広く見渡せる場でした。
The Journey of Box Building
rubykaigi.org 初日のキーノート The Journey of Box Building は、tagomorisさんによるRuby 4.0の実験的機能 Ruby Box の紹介でした。コードを他から隔離して実行できる仕組みで、いまどのBoxの中でメソッドが実行されているかを実行時にどのように特定するか、といった実装上の難所が丁寧に語られていました。 「Box Building = 函館」という言葉遊びから始まる構成で、技術的な内容と開催地・函館への思いとが入り混じった、RubyKaigiらしいキーノートでした。
Twenty Years of JRuby
rubykaigi.org Twenty Years of JRuby は、Charles Nutter さんによるJRuby 20年史のセッションでした。Ruby初のJITコンパイラ実装、並列スレッドの導入、そして長らく「本番運用される代替Ruby実装」としての歩みが振り返られ、JRuby 10.1の新機能（事前コンパイル、シングルファイルデプロイ、本番プロファイリング、マルチスレッド、GUI/ゲーム/AI向けライブラリ）が紹介されました。 JVMの機能を背景に、ワークロードによってはCRubyよりも高速に動く場面があったり、Logstash のような実運用システムでJRubyが使われていたりと、Ruby初心者の自分にはどれも勉強になる話でした。
Rubyに対して、より前向きになれた
Rubyに関しては初心者の自分ですが、これまで主に書いてきたのは Java、Kotlin、Go といった静的型・コンパイル系の言語ばかりでした。動的型のLL系言語にはあまり馴染みがなく、正直なところ Ruby はちょっと苦手寄り、というのが本音でした。
そんな自分にとって、今回のRubyKaigiでRubyに対する見方が少しでも前向きに変わったのは、なかなかのインパクトでした。「Rubyが好きで仕方ない人たちが集まって成果を発表する場」という空気を肌で感じて、その熱を少し分けてもらった気がします。もしかすると単に、会場の雰囲気にあてられただけなのかもしれません。
処理系やAIをめぐる議論など技術的な話だけでなく、こうした「言語そのものへの向き合い方」が変わるきっかけにもなるのは、RubyKaigiの面白さの一つだと思います。
おわりに
3日間を終えて感じたのは、RubyKaigiが独特な場だということです。「どこかで決まったことを日本に持ち帰って共有する」のではなく、「ここで議論し、ここで決まったことが、これからのRubyの方向性につながっていく」。そういう手触りのあるイベントだと思います。
セッションは、Rubyという言語そのものや処理系の根っこを掘り下げる発表が中心だったように思います。すぐに使えるノウハウを得る場というよりも、自分たちが日々使っている言語の足場を理解しに行く場として、参加した意味のあった時間でした。
kickflowは、これからもRubyコミュニティの一員として、何らかの形で関わり続けていきたいと考えています。来年の RubyKaigi 2027 は2027年4月14日から16日にかけて宮崎県で開催される予定とのこと。今年は初参加で準備が追いつかない場面もあったので、来年は宮崎で、もう少ししっかり準備をして皆さんとお会いできるようにしたいと思います。
We are hiring!
kickflow（キックフロー）は、運用・メンテナンスの課題を解決する「圧倒的に使いやすい」クラウドワークフローです。
サービスを開発・運用する仲間を募集しています。株式会社kickflowはソフトウェアエンジニアリングの力で社会の課題をどんどん解決していく会社です。こうした仕事に楽しさとやりがいを感じるという方は、カジュアル面談・ご応募お待ちしています！
