エンジニアとしてインドネシアに出張して顧客同行に行ってきました! | 株式会社SENRI
はじめにSENRIのWebアプリの開発をしている宮本です!7月の中旬にインドネシアに5日間出張に行ってきました!🇮🇩スカルノハッタ国際空港。めちゃくちゃデカい。初めての海外出張ということで、主に...
https://www.wantedly.com/companies/senriltd/post_articles/1009703
SENRIでWebアプリケーションエンジニアとして開発をしている宮本です!
一昨年、昨年に引き続きRuby Kaigiにいってきました!
今年は昨年JoinしたOdashi(おだし)と2人で参戦しました✈️
※本記事の後半はおだしパートとなっております
今回は北海道は函館での開催!
初めての北海道で服装に迷いましたが、着いてみると思ったより過ごしやすく、ちょうど桜の開花時期と重なったり、食事も言うまでもなく絶品で最高でした…
今年も個人的に気になったセッションについて、ざっくばらんに振り返ろうと思います!
こちらの発表ではMCP、ひいてはLLMから見たRubocopの現在地と展望についてお話がありました。
MCP SDKにTierという「MCPの仕様をどこまで実装しているか」の概念があること(現状ではRubyはTier3という一番下のレベル)やStreamable HTTPなど知らない知識を知れたというのも良かったですが、個人的に面白かったのが、
RuboCopのような「同じ入力に対して同じ結果を返す」決定的なツールと、LLMのような確率的・非決定的な存在をどう接続するか、という問いでした。
RuboCopはこれまでその決定性こそが価値であり、開発者にとっての信頼性の源泉でもありました。一方でLLMは、その場その場で異なる提案を返せる柔軟さが強みという中で、この性質の違いを単純に混ぜるのではなく、「どこまでをツールに委ね、どこからをAIに委ねるか」を設計する必要がある、という視点がとても面白かったです!
特にMCPのElicitationという仕組みを使い、「修正方針が一意に定まらない場面では人間に問い返す」というHuman in the LLM Loopの考え方は印象的でした。
単にAIに判断を丸投げするのではなく、決定性の流れの中に人間の意思決定ポイントを差し込むことで、既存ツールの信頼性を維持しながらAIの柔軟性を活かせる。
この発想はLinterだけではなく、FormatterやTest Runnerなど他のRubyツールチェインにも広がる可能性がありそうですし、さまざまな制約の中でそれぞれの得意な部分、苦手な部分の境界を意識して最適な関わり方を考えていきたいと、AI時代における開発体験そのものを考え直すきっかけになりました!
「The design and implementation of ZJIT & the next five years / Max Bernstein」をはじめにその他いくつかの発表(メモから抜けており特定できず申し訳ありません)で、内部的にCで書かれているコードをRubyに置き換えることで処理が早くなる、という話がありました。個人的にはなんとなくCの方が早そうなイメージがあったため、できる範囲で深堀りしてみたところ、ざっくり以下のような理解をしました。
(誤っている箇所があればマサカリをいただきたいのですが)
こういったことは普段の開発では基本的に意識することがないため、より言語処理に近いところを学ぶきっかけとしても改めてRuby Kaigiに行ってよかったなと思いました。
昨年はSpeeding up Class#newというClass#newの処理高速化の発表がありましたが、今年もClass.newについての発表(今回はLT)がありました!
今回の発表では、Class#newが思ったよりも早かった。ので計測してみた(意訳)といった内容という理解をしました。この発表を聞いて、改めて実測値の大事さを感じました。
AIで開発スピードが加速している中で、「現状より早い書き方はある?」「比較して」と、比較までAIに聞いてしまうこともありました。
今のAIではその聞き方でも大方外れていない可能性が高いのですが、ハルシネーションや、最新の情報が学習されていない、といった可能性もあるためパフォーマンスチューニング等、処理速度が大事になる局面ではこれだけではいけないと思いました。
最初の取っ掛かりとしては活用しつつ、実際にどのメソッドを採用するか判断する際には実測値を計測する、というように判断する役割を人間側に引き戻す、そのための情報を得るために活用していくのが現状の良い付き合い方なのかもしれないと感じました。
最終日のDrinkupでJeremyさん、igaigaさんなどのレジェンドとESM(英和システムマネジメント)さんのRuby Timelineゲームをやった結果、YARVくらい知っておかないとやばい?と思ったり、「CからRuby runtimeに最適化」の項でも興味が湧いた結果、昨年まではあまり興味を持てていなかった言語処理系の深堀りをしてみたり、会を重ねるごとに見えるもの、分かることが増えていることが実感できて今年も参加できてよかったです!
各社さんのDrink up、Meet upもバリエーションに富んでおりとても楽しむことができました🙌
運営の皆さん、ありがとうございました!!
ps. 北海道グルメの話
北海道グルメといえばのジンギスカン、海鮮、ザンギや函館ローカルグルメのラッキーピエロのチャイニーズチキンバーガー、ハセガワストアの焼き鳥(豚)弁当などなど一通り食すことができましたが、個人的には予想に反して海鮮よりも野菜が特に違いを感じました。付け合せのポテトフライがめちゃ甘かったり、お寿司屋さんのマヨコーンのコーンがジューシーで甘かったり…
写真は五稜郭の近くにある50品種以上のじゃがいもを扱う専門店「じゃがいもFACTORY」のポテトフライ。6~7種類入っているのですが甘さも食感も少しずつ違ってとても美味しかったです!
前回書いた記事はこちら
昨年のレポートはこちら
ここからはおだしパートです。僕もいくつかセッションを聞いたのでその感想を書きます。
このセッションはDatadogのTest Impact Analysis(TIA)という機能が紹介されつつ、いかにして変更箇所のみをテストするか試行錯誤したという内容でした。
コードをほぼほぼ書かなくなったことでエンジニアの時間的リソースが他のエンジニアやPdM、QAといった「人との対話」に多く割かれていってる印象があります。実際に動くものを作るまではかなり早くなってますが、次のボトルネックはCI/CDに移っていってると感じます。
弊社のCIも並列実行してもなお40分程度かかっていたものを余計なフィクスチャ生成や無駄なテストコードの削除などで10数分程度まで短縮する改善をしてきたのですが、こういうTIAも利用できればもっと短縮できるかもしれないと思いました。
Pythonの依存関係管理ツールであるuvの発表に影響を受けてもっとBundlerを速くできないかと思ったことから始まります。結果的にBundler 4がそれまでより3倍くらい速くなったことが紹介されてました。
HTTP並列接続する、Gemのフェッチではパラレルでgit cloneする、Gemをプリコンパイルする、などの手法に触れてました。
アプリケーションの実装だけなら普段はあまり気にしない部分ではあるものの、CIのようにbundler installが必須になるプロセスの改善はかなり嬉しいものでフィードバックループを高速に回せるようになりますよね。
↓詳しくはこちらで紹介されてます。
ここではSpinelというRuby製コンパイラが紹介されました(2026/4/24時点ではまだexperimentalということでした)。Rubyをnative binaryにコンパイルして配布できるのでRuby runtimeが不要です。
「Rubyを書く楽しさ」を残したままバイナリ化できるので、最近はコードを書くこと自体AI任せが多いですけどまた自分で書く時間も作ってみようかと思いました。
SpinelはAIを使って3週間くらいで実装ができた(構想はもっと前からあった)ということで、やはり今の時代はAI必須なんだろうなと。とは言え目指す先をしっかり見据えているからこそ一気に実装できたんだろうとも思うので、その軸がブレないことが大事なんだと改めて思いました。
セッション以外ではhacomonoさんのDynamite training at RubyKaigi Day2, Day3に参加しました。クロスフィットというトレーニングで体を動かして頭をスッキリさせてからRubyKaigiに臨めたので次もあればまた出たいと思いました。ちなみに思ってた以上に運動量ありました(笑)
ドリンクアップはivryさんのIVRy Climbing & Drinkupに参加してボルダリングや海鮮を楽しみました。ほぼ1年ぶり(これまたRubyKaigi 2025のIVRy Climbing & Drinkup)なので怪我しないように楽しみましたが、案の定普段使ってない筋肉を動かしたことで脇腹を股関節が筋肉痛になりました(笑)
そして今年の特製ホールドは五稜郭を模しておりとてもクールでした。