こんにちは。SRE課のtaku_76です！ 今回はKubernetesマニフェスト内の非推奨API / 削除済みAPIを継続的に検知する仕組みについて紹介します。 PlutoとGitHub Actionsを使い、定期実行から検出結果の更新まで自動で行うようにしました。 他チームにも使ってもらうことを想定していたため、Plutoを実行するだけでなく導入方法や検知結果の確認方法まで含めて運用に乗せる形にしています。 はじめに 仕組みを作成した目的 全体像 利用者の負担を減らすために工夫したこと Issueを作るだけで管理対象に追加できるようにした 結果確認をIssueに集約した READMEを自動生成して対象一覧を確認しやすくした 管理対象からの除外もIssue Close起点にした Actionsの設計 repos.jsonをmatrixに展開して複数リポジトリをチェックする helm templateでレンダリングしてからPlutoに渡す リポジトリごとのvalues差分を吸収する まとめ はじめに 仕組みを作成した目的 これまではKubernetesマニフェスト内の非推奨API / 削除済みAPIを定期的に確認する仕組みがありませんでした。 そのため、Kubernetesのバージョンアップ時に対象リポジトリを都度確認する必要があり、確認漏れがあるとアップデート後にリソースが適用できなくなる可能性があります。 このリスクを減らすために非推奨API / 削除済みAPIの利用状況を継続的に検知・追跡できる仕組みを作成しました。 また、対象リポジトリは複数ありそれぞれマニフェストの構成も少しずつ異なります。 そのため継続的に検知できるだけでなく利用者ができるだけ少ない手間で導入・確認できる形にすることも重視しました。 全体像 今回作成した仕組みでは、Kubernetesマニフェストを管理しているリポジトリを対象に非推奨API / 削除済みAPIが含まれていないかを定期的にチェックします。 検知にはPlutoを利用しました。PlutoはKubernetesマニフェストやHelm Chartなどに含まれる非推奨API / 削除済みAPIを検出できるツールです。 詳細は割愛しますが、対象のKubernetesバージョンを指定して実行することでそのバージョンで問題になるAPIを確認できます。 今回のworkflowでは、チェック対象のKubernetesバージョンとして実行時点のstableバージョンを取得してPlutoに渡しています。 そのため、Kubernetesのstableバージョンが更新された場合も次回実行時には新しいバージョンを基準に検知できます。 運用の流れは以下のようになります。 この記事では、リポジトリごとの検知結果を更新するIssueを管理用Issueと呼びます。 利用者側で必要な作業は、基本的に管理用Issueを作成することだけです。 運用の流れ 利用者の負担を減らすために工夫したこと Issueを作るだけで管理対象に追加できるようにした チェック対象のリポジトリはJSONファイルで管理しています。 JSONを直接編集してもらうこともできますが、利用者側に余計な作業を増やしたくありませんでした。 また、記載ミスや手順のばらつきも起きやすくなります。 そのため管理対象への追加はIssueを起点にすることにしました。 利用者はIssueテンプレートに沿って、以下の情報を入力します。 チェック対象リポジトリ チェック対象ブランチ values/ 配下で利用するvaluesファイル issue Issueが作成されるとGitHub Actionsが起動し、入力内容をもとにJSONファイルを更新するPull Requestを自動作成します。 最終的な反映は管理者がPull Requestを確認してから行うため、利用者の作業を減らしつつ追加内容も確認できる形にしています。 結果確認をIssueに集約した Plutoの検出結果は対象リポジトリごとに紐づいたIssueに更新しています。 以下のような運用は利用者の手間になるので避けました。 Actionsのログで結果を確認する 日次チェックの結果ごとに新しいIssueを作成する リポジトリごとに管理用Issueを用意し、チェック結果でIssue本文を上書き更新する形にしました。 Issueのイメージは以下です。 結果 検出結果がない場合は「検出なし」として更新します。 これによりチェックが実行されていないのか、問題が検出されなかったのかを区別できます。 READMEを自動生成して対象一覧を確認しやすくした 管理対象の一覧はJSONをもとにREADMEへ自動反映しています。 対象が増えてくると、どのIssueでどのリポジトリをチェックしているのか追いづらくなるためREADMEで一覧を可視化しました。 表示内容は対象リポジトリ・ブランチ・valuesファイル・管理用Issueへのリンクです。 これによりチェック対象と確認先のIssueをすぐ確認できます。 ↓イメージ readme 管理対象からの除外もIssue Close起点にした 管理対象から外す場合も、JSONファイルを直接編集するのではなく対象の管理用IssueをCloseする運用にしました。 IssueがCloseされるとGitHub Actionsが起動し、対象のIssueに紐づく情報をJSONファイルから削除するPull Requestを作成します。 これにより利用者はIssueをCloseするだけで管理対象からの除外を依頼できます。 Actionsの設計 ここからはGitHub Actions側でどのように複数リポジトリをチェックしているかを紹介します。 この仕組みではチェック対象のリポジトリ情報を .github/repos.json で管理しています。 GitHub Actionsでは、このJSONに登録された情報をもとにリポジトリごとにチェックを実行しています。 repos.jsonをmatrixに展開して複数リポジトリをチェックする チェック対象のリポジトリ情報は .github/repos.json にまとめています。 例えば1つの対象リポジトリは以下のような形式で管理しています。 { " repo ": " example-manifests ", " branch ": " main ", " valuesFile ": " prd-001.yaml ", " issue ": 123 } 各項目には、対象リポジトリ、ブランチ、valuesファイル、更新対象Issue番号を持たせています。 複数リポジトリを扱う前提だったため、workflowにリポジトリ情報を直接書くのではなく repos.json でまとめることにしました。 日次チェック用のworkflowでは、この repos.json を jq -c で1行のJSONに変換し、GitHub Actionsの fromJSON を使ってmatrixに展開しています。 matrixに展開することで、登録されているリポジトリごとに同じチェック処理を実行できます。 対象を追加する場合も repos.json にリポジトリ情報を追加すれば次回のチェックから対象に含まれるため、workflow本体を修正せずに済みます。 実際のチェック処理はreusable workflowにまとめており、以下の処理を行っています。 ワークフロー helm templateでレンダリングしてからPlutoに渡す 対象リポジトリではKubernetesマニフェストをHelm Chartとして管理しています。 そのためPlutoにChartのテンプレートファイルをそのまま渡すのではなく、まず helm template でvaluesを反映したKubernetesマニフェストを生成しています。 チェック処理では、対象リポジトリの manifests/* 配下を見て Chart.yaml があるディレクトリをHelm Chartとして扱います。 処理としては以下の流れになります。 チェック処理 Plutoはレンダリング後のマニフェストを確認するため、実際に適用される内容に近い状態で非推奨API / 削除済みAPIを検知できます。 また、Helm Chartの crds/ 配下にあるCRDも出力に含めるため helm template では --include-crds を指定しています。 リポジトリごとのvalues差分を吸収する 基本的には、各Chartに対して以下のvaluesファイルを指定して helm template を実行しています。 values.yaml values/<valuesFile> ただし、リポジトリによってはこれだけではレンダリングに必要な値が足りない場合があります。 例えばあるChartが別のChart用のvaluesを参照していたり、共通設定を別ファイルに分けていたりするケースです。 そのため、 .github/repos.json には任意でChartごとの追加valuesファイルを指定できるようにしました。 以下イメージです。 { " repo ": " example-app-manifests ", " branch ": " main ", " valuesFile ": " test.yaml ", " issue ": 123 , " valueFiles ": { " app-a ": [ " common/values.yaml ", " database/values/prd.yaml " ] } } workflow側にリポジトリごとの例外を増やしていくと管理がつらくなるため、差分は repos.json 側に寄せるようにしました。 これによりworkflow側は共通のままリポジトリごとのvalues構成に対応できます。 まとめ 今回は、PlutoとGitHub Actionsを使って、Kubernetesマニフェスト内の非推奨API / 削除済みAPIを継続的に検知する仕組みを作成しました。 Issueを起点に管理対象の追加や結果確認を行うことで、利用者の作業をできるだけ増やさずに継続的に確認できる形を意識しました。 今後は運用しながら課題が見つかれば改善していきたいと考えています。

はじめに こんにちは、2026年1月入社のI.Kobayashiです！ 本記事では、2026年1月入社のみなさまに入社直後の感想をお伺いし、まとめてみました。 KINTOテクノロジーズ（以下、KTC）に興味のある方、そして、今回参加下さったメンバーへの振り返りとして有益なコンテンツになればいいなと思います！ YY  自己紹介 デジタル戦略部 データグロースグループでプロデューサーをしています。 各サービスの成長に向けて、データドリブンな意思決定を支援する施策を企画・推進しています。 また、社内ツールのプロダクトマネージャー（PdM）も兼任しており、社内業務効率化のためのツール開発や改善にも取り組んでいます。 所属チームの体制は？ ビジネス支援を行うチームに所属しており、デジタルマーケティングに強みを持つプロデューサー、定性調査に強みを持つプロデューサー、データサイエンスに強みを持つエンジニア達などに囲まれて仕事をしています。 それぞれの専門性を活かしながら、チーム一丸となってサービスの成長を支えています。 KTCへ入社したときの第一印象？ギャップはあった？ 制作・開発に比重の強い会社だという印象を持っていましたが、実際にはビジネス側との距離も近く、連携が密である点にギャップを感じました。 現場の雰囲気はどんな感じ？ 私が所属するデータ活用チームは、複数のサービスチームと横断的に関わるため、日常的にコミュニケーションが活発です。データで支援する立場から、サービスの理想の姿やデータから見える実像について、普段の会話の中で自然に議論が交わされています。 オフィスで気に入っているところ スカイツリーを眺めながらランチできる休憩スペースがお気に入りです。 眺望の良さはもちろん、リフレッシュしやすい雰囲気があり、午後の仕事への切り替えにも役立っています。 天野さん　⇒　吉川さんへの質問 普段の業務でAIってどうやって使われていますか？ データ分析をAIに任せて、プロジェクトの進む方向性や現在地を一緒に考えることを行っています。 壁打ち相手としても、分析担当としても利用しており、自分の役割を忘れてしまいそうになるぐらいに多用しています。 会議に向けたアジェンダ作成、それに伴うデータ分析、示唆出しまで、一言のプロンプトで完了してしまうのは革命的だと感じています。 Mizoguchi Hiroki  自己紹介 KINTOを開発するグループで新車サブスクのWebフロントエンド開発チームに所属しています フロントエンドチームにいますがバックエンドもインフラも全般好きです 自転車に乗って走り回るのが趣味です！走り回りすぎて最近骨折しましたが、治ったら懲りずに走り回ろうと思っています 所属チームの体制は？ 東京6名・大阪3名のフロントエンドエンジニア9名で構成されています バックエンド・フロントエンド・PdM・QAなど職種によってチームが分かれていて、開発する機能ごとに各チームから数名集って開発を進めるような体制になっています KTCへ入社したときの第一印象？ギャップはあった？ 行動力がある大人が集まっているという印象でした。経験値からくる冷静さと、周りを巻き込んでやりたいこと・やるべきことを進めるアクティブさを持った人が多い印象を受けています 現場の雰囲気はどんな感じ？ チームメンバーそれぞれで異なったタスクを進めることが多いので、主にモクモクと作業しています。協力が必要なことや相談したいことをslackや対面で声を掛けると皆さん積極的に会話に参加してくれるのでコミュニケーションは円滑です オフィスで気に入っているところ とにかく開放感があって、外の景色を見渡せるところが気に入っています オフィス全体が車をテーマにデザインされていて、遊び心があるところが気に入っています。イベントも頻繁に開催しているので、ぜひ覗きにきてください 吉川さん ⇒　溝口さんへの質問 フロントエンド開発において、AIと人とどのように作業を分担されていますか？ 私は大枠の設計は完全に人間、業務ロジック設計やコードのレイヤー分割などはAIの提案をもとに対話して決定、具体的な実装は殆どAIに任せるなど具象度に応じてAIへの依存が高まっていくような分担になっています。 地味にUIの見た目チェックや操作時の挙動確認は具象な作業なものの、人間がポチポチ画面操作して担当しています。（なんとかAIを使って自動化できないか模索中） Kosuke Kihara  自己紹介 新サービス開発部 FACTORY EC開発G所属です。 趣味は自作キーボード・ヴィオラ・園芸、ヴィオラは市民オーケストラで演奏していました。 所属チームの体制は？ 新サービス開発部 FACTORY EC開発Gで、TOYOTA/LEXUS UPGRADE FACTORYのEC基盤を開発・運用しています。 フロントエンド、バックエンド、PdM、SRE、QA、ディレクター、マネージャーなど合わせて15名ほどの体制です。 KTCへ入社したときの第一印象？ギャップはあった？ 入社前に受けていた説明と大きく印象が異なることもなく、戸惑うことはなかったです。 あえて言えば、自分が勤務しているOsaka Tech Labでは特に遊び心を大事にしているところが良い意味でギャップに感じました。 現場の雰囲気はどんな感じ？ チームではバーチャルオフィスのGatherを利用しており、リモートでも気軽に相談できる空気感があります。 オフィスで気に入っているところ Osaka Tech Labのパークです。 ヨギボーを持っていってリラックスしながら仕事すると、頭が柔らかくなっていろんな発想ができる（気がする）。 溝口さん ⇒　木原さんへの質問 最近AIを使ってうまくいった仕事や作業あれば教えてください！ JiraチケットやPRのURLから紐づくConfluence・Jira・Slack・コードを自動で追わせてまとめるスキルを作成しました。 案件の周辺コンテキストの理解にかかる時間を大幅に削減できています。 やまそと  自己紹介 プラットフォーム開発部Cloud Infrastructure Gのやまそとです。 トヨタグループへのクラウド領域の技術支援を担当しています。 前職まではSES/SIerでバックエンドの開発エンジニアとして働いていましたが、気づいたらインフラエンジニアになっていました。 プライベートではビールとバイクにハマってます！ 所属チームの体制は？ 大阪4名東京2名の体制です KTCへ入社したときの第一印象？ギャップはあった？ コミュニケーションが活発でアクティブな人が多いなーという印象でした トップダウンではなくフラットに意見を言えますし、自律的に行動する人が多いのは良いギャップでした 現場の雰囲気はどんな感じ？ 普段はみんなそれぞれの案件に携わっていますが、社内のチームミーティングはワイワイやってます オフィスで気に入っているところ OsakaTechLab勤務ですが、全体的にキレイでテンションが上がります 駅と繋がっていて雨に濡れずに済むので助かります 木原さん ⇒　山外さんへの質問 バイクが趣味とお聞きしましたが、最近バイクで行ったおすすめの場所などあれば教えてください！ 去年の秋頃に兵庫の須磨に行きました！海沿いを走るのは気持ちよかったです。 あったかくなってきたので淡路島か琵琶湖にいきたいですね。 やまと  自己紹介 my route開発部でAWSインフラアーキテクトとして働いています。 国内旅行が趣味で、アーケードゲームの全国行脚機能で43都道府県、スターバックスのアプリでは14都県巡っています。(2026年4月現在) インドア趣味のほうでは某オンラインゲームの/playtimeが執筆時点で10,047時間でした。 所属チームの体制は？ 所属しているバックエンド開発チームでインフラを主に担当するのは私一人で、サーバサイドアプリケーションを開発する他のメンバーと密にコミュニケーションを取って仕事を進めています。 KTCへ入社したときの第一印象？ギャップはあった？ 入社前の想像よりも、チームメンバーの一人ひとりが開発しているアプリケーションのことをもっとこうしたい！と考えていると感じました。 現場の雰囲気はどんな感じ？ メンバーが2人以上出社すれば一緒にランチに行って雑談をしているので、仕事の依頼や質問もしやすく過ごしやすい雰囲気だと感じています。 オフィスで気に入っているところ 神保町オフィスは集中しやすくもあり孤独を感じるほど少なくもない、ほど良い出社率です。レストエリアがお洒落でアップルティーを取りに行くのがリフレッシュになります。 山外さん ⇒　大和さんへの質問 おすすめの旅行先を教えてください！ 美味しい酒・魚を求めるなら四国地方 or 日本海側、綺麗な景色を求めるなら海沿い、が良かったです！ その土地の名産であれば、味はもとよりお値段も都市圏より安くてたくさん食べられます。 ただし、食を堪能する旅には登山やハイキングも取り入れた方が、よいです（戒め）。 I.Kobayashi  自己紹介 クラウドセキュリティG所属のI.Kobayashiです。 KTCで利用しているクラウドのセキュリティ改善や改善活動の効率よくするためのツール開発などを行っています。 所属チームの体制は？ クラウドセキュリティGは現在、大阪2名、東京3名が在籍しています。 KTCへ入社したときの第一印象？ギャップはあった？ 入社前にチーム状況・求められていることなど共有いただいていたのでギャップ全然ありませんでした。 現場の雰囲気はどんな感じ？ 皆さん優しいので仕事がしやすいです。 利用したことないサービスや技術であっても一緒に調査してくれます！ オフィスで気に入っているところ １階コンビニ、２階レストランがあるので雨で外出たくない時によく利用しています！ 大和さん　⇒　小林さんへの質問 ご趣味は！（アウトドアでもインドアでも構いませんので！） 音楽・ポッドキャスト聴きながら目的もなく歩くのが好きです！ HOKAMA  自己紹介 開発支援部企画管理Gの外間です。 主に会社の予算管理や業務フローの調整などを担っている部署となります。 休みの日は小学3年生の息子の町クラブ（サッカー）でコーチをやっています。 趣味はフットサルとゴルフで夏になると日焼け止めを塗っても真っ黒になります。 所属チームの体制は？ 企画管理Gは室町2名、大阪1名、名古屋1名です。 KTCへ入社したときの第一印象？ギャップはあった？ ある程度のミッション内容を入社前に伺っていたので、あまりギャップは感じませんでした。 現場の雰囲気はどんな感じ？ 全員中途採用なので落ち着いた雰囲気です。 オフィスで気に入っているところ 室町7階の休憩室が気に入っています。マッサージ機もあるので体を労わりながら仕事が出来るので！ 小林さん　⇒　外間さんへの質問 室町周辺でおすすめのお店教えてください！(行ってみたいお店でも大丈夫です！) 室町オフィスから少しあるきますが、「新日本橋中華 龍龍龍龍 TETSU」の炒飯が美味しいです。 週一回は通ってます。 きーた  自己紹介 2026年1月入社のきーたです。 セキュリティ・プライバシー部に所属し、福岡オフィス（Fukuoka Tech Lab）で勤務しています。 アビスパ福岡が好きな方、お待ちしてます！ 所属チームの体制は？ 所属チームは3名体制です。 TFSグループが定める基準をベースとしたセキュリティのアセスメントを主に担当しています。 少人数なのでコミュニケーションも取りやすく、日々連携しながら進めています。 KTCへ入社したときの第一印象？ギャップはあった？ 会社のカルチャーや雰囲気など、良い意味で入社前に抱いた印象とのギャップはありませんでした。 入社後のフォロー面談でも「ギャップはありましたか？」と聞かれますが、いつも「何もないですね」と答えていますｗ 現場の雰囲気はどんな感じ？ 「個々がプロフェッショナルでありつつ、しっかりチームで連携して動ける」といった印象です。 困ったときはすぐに相談に乗ってもらえるので助かっています。 オフィスで気に入っているところ 立地がいいところ。あとは地下街と繋がっていたら最高でした。 外間さん　⇒　紀伊さんへの質問 これまで仕事で一番やらかしたことはどんなことですか？（言える範囲でお願いします） 言えることだと…、某大手メーカーさんの重要拠点のインフラを数時間止めてしまったこと、でしょうか。 あの経験があったおかげて、作業は人一倍慎重になりました！！ sasanoshouta  自己紹介 AIファーストグループでAIエンジニアをしています、sasanoshoutaです。 社内外に対して生成AI活用の推進の為に折衝からPoC、実装までを幅広く行う業務に取り組んでいます。 所属チームの体制は？ AIファーストグループは東京9名、名古屋3名、大阪1名の体制を敷いています。 KTCへ入社したときの第一印象？ギャップはあった？ 入社間もなく、チーム内にはいい意味で上下の関係がなく、相互に取り組んでいることについて共有しながら技術的な共有や議論について交わすことができる印象を持ちました。 また、事前に自分への期待値や会社・チームの状況を聞いた上で役割を想像しながら入社しているので、ギャップはありませんでした。 現場の雰囲気はどんな感じ？ チーム全員が同じ取り組みをしている訳ではないですが、共通言語として「誰の為のものか」を全員が常に意識しながら目の前の事に集中して取り組んでいる雰囲気が常にあります。 オフィスで気に入っているところ 日本橋の室町という歴史あるエリアにあるオフィスで、オフィスの内装もモダンで働きやすいですが、周辺のロケーションも気に入っています。 紀伊さん　⇒　笹野さんへの質問 今年のサッカーW杯で日本以外に注目している国はありますか？ たくさんあります。 優勝候補スペイン・フランスや、逸材を輩出し続けているアフリカ勢の国々、初参加国の中でもノルウェー・ウズベキスタン・エジプトがどこまでいくのか、数大会振り出場のチェコあたりに注目したいと思ってます！ satoshi  自己紹介 AIファーストグループの天野です！生成AIの活用推進を社内外に向けて活動しています。 非ソフトウェアエンジニアリング領域を中心に活動しています。 動画生成や記事執筆、顧客理解に対してのAI活用検証を行なっています。 所属チームの体制は？ AIファーストグループは東京9名、名古屋3名、大阪1名の体制を敷いています。 KTCへ入社したときの第一印象？ギャップはあった？ 皆さん主体的に新しい事に取り組む方が多いなと感じました！ 私もアイデアを出して試してみるのが好きなので、カルチャーに馴染みやすかったです。 現場の雰囲気はどんな感じ？ 皆さん和気あいあいとした感じがありながらも、しっかりと目的感を持っている印象でした。 オフィスで気に入っているところ オフィス周辺が綺麗なので帰宅時に優雅な感じに帰れる所です！ 笹野さん　⇒　天野さんへの質問 入社の決め手を教えてください！ AIの非ソフトウェア領域での活用や推進ができるポジションがあり、自分のやりたい事と重なった為です。 元々はソフトウェア領域でAIを活用していましたが、開発経験が浅く方向転換をしたかったので、私と同じような考えの方がいればAIファーストGオススメです！ さいごに みなさま、入社後の感想を教えてくださり、ありがとうございました！ KINTOテクノロジーズでは日々、新たなメンバーが増えています！ 今後もいろんな部署のいろんな方々の入社エントリが増えていきますので、楽しみにしていただけましたら幸いです。 そして、KINTOテクノロジーズでは、まだまださまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくは こちら からご確認ください！

こんにちは、タイミーでSRE業務を担当している徳富(@yannKazu1)です。 先日、函館で開催されたRubyKaigi 2026に参加してきました。Ruby本体やパーサ、GC、JITといった「言語の中身」を深掘りするカンファレンスなので、普段アプリケーションコードよりインフラ寄りの仕事をしている自分が行って楽しめるのか、という気持ちも少しありました。ですが、結果としてとても楽しめたので、感想を書いておきます。 SREが行っても普通に楽しめた 普段の仕事はRailsアプリケーションを安定して動かしたり、スケールさせたり、観測したりすることが中心です。Ruby本体にコミットするわけでも、パーサを書くわけでもないので、専門外の話も多いだろうと思っていました。 実際、聞いていて全部の細部までは追えないセッションもありました。それでも、 普段ブラックボックスとして扱っているGCやランタイムの中身が、作っている人の口から語られる 他社のRails運用をやっている人たちと直接話せる このあたりだけでも参加する価値を感じました。 Day 1のブースが意外と良かった 参加されたことがある方ならわかると思いますが、Day 2以降はブース巡りが意外と慌ただしくなります。スタンプラリーで人が流れたり、セッションの合間で時間が限られていたり。 その点、 Day 1はスタンプラリーがまだ始まっていないので、ブースが比較的空いていてゆっくり話せる時間帯 でした。立ち寄っても順番待ちがほとんどなく、エンジニアの方とじっくり話せます。 RubyKaigiにはほぼ例外なくRailsを本番運用している会社さんがスポンサーとして出展しているので、SREとしては「他社さんのアーキテクチャや困りごとを直接聞ける場」として、これがかなり面白かったです。 Railsで完結する vs クラウドネイティブに振り切る 複数の会社さんと話して興味深かったのが、「Railsの中で完結させるか、AWSのマネージドサービスに切り出すか」の判断基準が会社によって全然違うことです。 Railsはよくできていて、ActiveJob + Sidekiq、ActiveStorage、ActionCableなどを組み合わせれば、大抵のユースケースはRailsの世界の中で完結します。わざわざクラウドネイティブなマネージドサービスに切り出さなくても、運用負荷を抑えながら回せるケースは多い。 一方で、「ジョブの遅延が事業KPIに直結するので、マネージドサービスに切り出して水平スケールを確実にしている」と話す会社さんもあれば、逆に「今のスタックで十分捌けているし、Rubyエンジニアが運用できる構成に揃えたほうが組織的に強い」と話す会社さんもありました。 技術選定の基準として挙がっていたのは、ざっくりこんな観点です。 スパイク耐性が事業上クリティカルかどうか 運用するチームのスキルセットと採用市場 コールドスタートを許容できるワークロードか RubyKaigiは登壇者も来場者もアプリケーションエンジニアが中心です。そのため、「Sidekiqのままいくか、それとも切り出すか」といったテーマひとつとっても、「アプリケーション側からどう見えているか、何が嬉しいかつらいか」という視点で語られていたのが印象的でした。 普段、SRE系のイベントで「インフラ側の都合」としてこの手の話を聞くことが多い私にとっては、この視点の対比が非常に新鮮に感じられました。 「正解は一つじゃない」と頭ではわかっていても、SRE目線とアプリ目線では同じ意思決定でも見えている景色が違います。両方の視点を持っておくことが大事だなと、改めて感じました。 AI活用の温度感 もう一つ、多くのブースでも話題になったのが AI活用 です。プロダクトへの組み込み、社内開発フローへの導入、営業・カスタマーサポートへの活用と、レイヤーごとに状況が違っていて面白かったです。 特に印象に残ったのが、SmartBankさんのブースで展示されていた「スマートバンクで働くAI Agentたち」のポスターでした。アプリユーザー向けの「 ワンバンフレンズ 」(家計を読み解いて気づきを届けるAIアシスタント)、社内メンバー向けの「 Ask! ワンバン 」(自然言語で社内データを検索・分析する分析AI)、そして開発者向けの「 Guardie 」(エラーや異常を検知してログ・コード・変更履歴を横断して原因特定を支援する番犬AI)という三本立てで、 ユーザー向け / 社内向け / 開発者向けの3レイヤーに対してそれぞれAIエージェントを配置している のがすごく整理されていて印象的でした。 特にGuardieはSRE視点でめちゃくちゃ刺さりました。「2時間覚悟していた調査が10分で終わった」という社内の声が紹介されていて、これは障害対応における MTTR(平均復旧時間)を本質的に短縮しに行っている 事例だなと。エラー検知 → ログ・コード・変更履歴を横断した原因特定までをAIに任せる、というのはこれから我々も作っていこうと思っていた仕組みが普通に動いていて、刺激を受けました。 ブース担当の方とは「どこまでをAIに任せて、どこから人間がやるべきか」「誤検知や暴走への安全装置をどう設計しているか」みたいな話までできて、こういう一次情報が聞けるのもRubyKaigiならではでした。 気になった話は、その後のアフターパーティでさらに深掘りできました。資料には載らない現場のリアルな知見が交換される場として、ブース + アフターパーティの組み合わせは、セッションと同じくらい価値があったと感じます。 参加したセッションを日ごとに振り返る ここからは、自分が参加して特に印象に残ったセッションを日ごとに紹介していきます。 Day 1: Exploring RuboCop with MCP (Koichi ITO さん) 1日目に聴いたのが、RuboCopコアチーム・MCP Ruby SDKチームメンバーのKoichi ITOさんによる、 RuboCopとMCP(Model Context Protocol) を組み合わせる試みについてのセッションです。 これまでRuboCopは「人間」または「他のプログラム（CIなど）」をきっかけに実行されてきました。そこにAI時代になって、 AIエージェントという新しい実行のきっかけ が登場した、というのが導入の話です。生成AIとリンター/フォーマッターをどう組み合わせるか、Rubyで実装されたMCPサーバーをエージェントの隣で走らせるとどうなるか、という内容でした。 技術的には、 MCP SDKの構造(サーバーとクライアントそれぞれのSDKがあること) トランスポート層として stdio と Streamable HTTP の2種類があり、用途で使い分けること HTTPトランスポートではセッション管理が肝になり、Pumaのようなスレッドモデル + シングルプロセス構成だと素直に動くが、複数プロセス・複数ホストに横断するとセッションの保持が難しくなること ただし Stateless Mode ( stateless: true )を使えば、Pumaの複数ワーカーやUnicornのような複数プロセス構成にも対応できること。ただしこれは リクエストごとに新しいtransportインスタンスが生成されるためMCP-Session-Idを共有できない という制約とのトレードオフであり、「セッション保持を諦める代わりに複数ワーカー/プロセスでもスケールできる」という割り切り あたりが特に勉強になりました。特にセッション管理の話は、MCPサーバーをWebアプリケーションとして本番に乗せようとすると、ロードバランサーやスケールアウトとの兼ね合いが出てくるという点で実践的でした。 ステートフル/ステートレスをどう使い分けるか は、これから考えないといけないテーマになりそうです。 セッションの締めくくりで「LLMの 確率的な性質 を決定的なツールに組み込むことで、これまでの決定的なツールとは違う未来が描ける」という話があって、そこも印象的でした。MCPの サンプリング (サーバーがクライアント経由でLLM補完を要求する仕組み)や、 Elicitation (実行中にユーザーへ追加情報を問い合わせる仕組み)といった機能は、ツールの形そのものを変えそうな予感があります。 スライド: https://speakerdeck.com/koic/exploring-rubocop-with-mcp Day 2: Chasing Real-Time Observability for CRuby (Shintaro Otsuka さん) 2日目で一番テンションが上がったのがこのセッション。CRubyの実行状態を リアルタイムに3D可視化する というツール「rrtrace」の話でした。 普通のプロファイラはサンプリングベースで、後から集計して結果を見る形が多いですが、このツールは「いまこの瞬間にCRubyの中で何が起きているか」を、複数スレッドのスタック状態として3次元空間にレンダリングしながら見せる、というアプローチです。デモを見せてもらった時、IRBに入力するたびにスタックが積み上がっていく様子がリアルタイムで見えて、純粋に「すごいものを見ている」という感覚になりました。 技術的なポイントとしては、 計測側のC拡張は軽量に保つ設計 で、イベントの収集と転送に特化している イベントは TracePoint API ( CALL / RETURN / INTERNAL_GC_ENTER / INTERNAL_GC_EXIT )や内部のスレッドイベント( INTERNAL_THREAD_EVENT 、こちらはWindowsでは利用不可)から収集し、timestamp(60bit) + event type(4bit) + method id/thread id(64bit)の合計16バイトの構造体に統一 C拡張(計測側)とビジュアライザプロセスの間は OS管理の共有メモリ上のリングバッファ で受け渡し ビジュアライザ側はCRubyのコアを使っていない別プロセスなので、可視化処理が重くてもCRubyの実行を直接ブロックしない スタックシミュレーションが重いため、 Parallel Scanアルゴリズム で並列化している という設計でした。ただし、スライドのベンチマーク結果を見ると、rrtrace有効時は 関数呼び出しスループットがplain CRubyの17%程度 (73,417,127 → 12,760,131 calls/s、約5.9倍遅くなる)、 Railsサーバーのrpsもplain CRubyの55%程度 (203.19 → 110.84 rps)になるとのことで、 計測のオーバーヘッド自体は「小さくない(not small)」 とスライドでも明記されていました。TracePointフックのコストが支配的で、ここは今後の課題とのことです。 それでも、「 重い処理を別プロセスに全部寄せる 」というアーキテクチャの考え方は面白かったです。計測側はできるだけ軽く保って、分析・可視化は別のリソースでやる。この割り切りが設計をシンプルにしていて、きれいだなと思いました。 「現代のマシンは10コア以上あるのが普通で、CRubyが1コアで動くなら残りのコアを観測やビジュアライズに自由に使える」という、リソースの捉え方の話も新鮮でした。GVLがある世界での観測ツールの設計思想として、納得感が強かったです。 スライド: https://speakerdeck.com/whitegreen/chasing-real-time-observability-for-cruby Day 3: The Less-Told Story of Socket Timeouts (Misaki Shioi さん) 3日目に聴いたのがこれ。ソケットライブラリのタイムアウトの 歴史と内部実装 を、Issue/Commitを参照しながらRuby 4.0までの流れに沿って解説していくセッションでした。タイトルからして気になっていたけど、期待以上の内容でした。 Socket.tcp / TCPSocket.new には、 resolv_timeout (名前解決のタイムアウト) connect_timeout (接続のタイムアウト) そしてRuby 4.0で追加された open_timeout (全体のタイムアウト) の3種類があります。「この3つがなぜ必要で、どういう順番で導入され、どんな歴史的な紆余曲折があったのか」を、Issue/Commitを参照しながら丁寧に追っていく構成でした。 特に印象的だったのが、 まず Socket.tcp に connect_timeout が導入され、続いて Addrinfo.getaddrinfo への timeout および Socket.tcp への resolv_timeout が追加されたこと resolv_timeout と connect_timeout を両方指定しても、全体のタイムアウト時間は制御できない (複数アドレスに対して逐次接続を試行するため、合計時間が想定より長くなりうる) これらの問題を解決するために、Ruby 4.0で 全体時間を管理する open_timeout が追加された という話の流れです。普段、HTTPクライアントの open_timeout / read_timeout / write_timeout を「だいたいこのくらい」で設定しがちですが、その下のレイヤーでは名前解決と接続が並行で走っていて、 タイムアウトの組み合わせによっては想定と全然違う挙動になる ということを、改めて意識させられました。 また、歴史的な経緯として特に面白かったのが、 名前解決の中断可能化(interruptible)をめぐる話 です。 getaddrinfo(3) はブロッキング呼び出しで、 Ctrl+C でも中断できないという問題が長年ありました。これを解決するアプローチとして、まず 2020年1月に「 Addrinfo.getaddrinfo が timeout をサポートする」提案が行われ、そのパッチで Addrinfo.getaddrinfo に timeout 、 Socket.tcp に resolv_timeout が追加されると同時に、内部的に「GNU拡張の getaddrinfo_a(3) が利用可能ならそれを使う」実装が入りました ( getaddrinfo_a(3) はワーカースレッドで非同期に名前解決を行う仕組み)。その後 2020年8月には「Make Socket.getaddrinfo interruptible」がマージされ、 Socket.getaddrinfo の内部もこの getaddrinfo_a(3) を使うように利用範囲が拡張 、さらに 2020年9月には TCPSocket.new にも resolv_timeout / connect_timeout が追加 され、名前解決を中断可能にする方向で進められました。 ところがその後、 Rails ActiveJobの統合テストが失敗するようになった という報告が入り、調査の結果、 fork後の子プロセスで getaddrinfo_a(3) を呼び出すとハングする ことが判明します。 getaddrinfo_a(3) は内部で再利用可能なワーカースレッドを保持しているのですが、forkでコピーされる子プロセスにはワーカースレッドが存在しないにもかかわらず内部状態は「ワーカースレッドが待機中」のままになっており、これによってデッドロックが発生する、という仕組みでした。 2ヶ月以上の調査と回避策の検討を経て、最終的には getaddrinfo_a(3) の導入自体が撤回 され、関連変更もrevertされました。その代わり、後に別アプローチとして 「名前解決ごとに専用のpthreadを立てて getaddrinfo(3) を実行する」方式 (mameさん提案、 ruby/ruby#8695 )が採用され、こちらは rsock_getaddrinfo 内に実装されることで、内部的に rsock_getaddrinfo を呼んでいる Addrinfo.getaddrinfo や Socket.getaddrinfo を含む幅広いメソッド で名前解決のブロッキング問題が解消された、という流れです。 外部API連携で「タイムアウトを設定したはずなのにハングする」「 connect_timeout を短くしたのに、複数アドレスがあるホストで合計時間が想定の何倍もかかる」みたいな経験がある人は少なくないと思いますが、まさにあれの背景にある話でした。タイムアウト設計の見直しや、Ruby 4.0以降は open_timeout を積極的に使っていくこと、テストでタイムアウト周りの挙動を確認しておくことなど、すぐに持ち帰れる学びがいくつもありました。 スライド: https://speakerdeck.com/coe401_/the-less-told-story-of-socket-timeouts リモートワーク時代の副次効果 もう一つ書いておきたいのが 社内メンバーとの関係性 の話です。 弊社エンジニアはリモートワーク中心で、普段の業務だと開発チームの全員と毎日話すわけではありません。SlackやZoomでは話すけれど、雑談ベースで「最近どう?」みたいな会話になりにくい人もいます。 それが、RubyKaigiで3日間一緒に過ごすと一気に距離が縮まります。一緒にセッションを聞いて、休憩中に「今のどう思った?」と話して、夜は飲みに行って、移動中に雑談する。この3日間の密度は、リモートでの数ヶ月分のコミュニケーションに相当するんじゃないかと思います。 おわりに RubyKaigiは「Ruby本体に関わっている人たちのお祭り」という側面が強いカンファレンスですが、Rubyを本番で動かしている側の人間にとっても十分に楽しめる場でした。SREとしても、ランタイムの理解が深まったり、他社の運用知見をもらえたり、社内の関係性が深まったりと、副次効果を含めて満足度の高い3日間でした。 普段Railsを動かしているSREの方や、これからRubyKaigiどうしようかなと迷っている方の参考になれば嬉しいです。