システム開発第一事業部の奥田です。普段はフルスタックエンジニアとしてWebアプリの開発を担当しています。
前回までの記事では、Rubyのclass本体が実行されること、継承とメソッド探索順、定数スコープと可視性を整理しました。
今回は最終回として、Railsでよく見るDSLを「クラス定義の中で呼ばれたRubyメソッド」として読み直し、1リクエストの内部動作まで追います。
include/extend/prepend・メソッド探索順を整理するこんにちは。DX本部 システム開発第一事業部の吉本です。普段はWebアプリケーションの開発を担当しています。
今回、iOSDC Japan 2026に当日スタッフとして参加してきました。技術カンファレンスへの参加はもちろん、社外イベントのスタッフとしての参加も人生初でした。モバイル開発の経験はなく、Swiftに触れるのも初めてでしたが、思っていた以上に学びや出会いの多い3日間になったので、当日の様子を振り返っていきたいと思います。
続きを読むシステム開発第二事業部の冨永です。
主にiOS/iPadアプリの開発を担当しております。
以前、子どもが通う保育園で使う絵本管理のiPadアプリを開発した話を書きました。
あれから約1年...。
先生や使ってくださる保護者の方からの要望もいただき、気づけばPull Requestも100件を超えていました。
今回は、約1年間で実際に使っていただいた中で見えてきた課題と、その改善について書きたいと思います。
特に、幅広い年代の方が使うアプリでのUI設計や、共用端末ならではのプライバシーへの配慮、そして利用者に仕様を覚えてもらうのではなく、画面そのものから自然に理解してもらうための工夫について紹介します。
社内向けアプリや店舗・施設などに設置するiPadアプリを開発している方、あるいは「リリースした後、実際の利用者の声をどうUI改善につなげるか」を考えている方の参考になれば幸いです。
続きを読むシステム開発第二事業部の高山です。普段はエンジニアとして、主にRubyを使用してバックエンドの開発を行っています。
実務でRailsのログマスキングを実装し直す中で prepend を使う機会がありました。一番面白いと感じたのは、prependが単なる「機能追加の仕組み」ではなく、クラスのメソッド探索順序(Method Resolution Order、以下MRO)そのものを書き換える仕組みだったことです。呼び出し側のコードは1行も変えていないのに、実際に呼ばれるメソッドが変わる。この感覚は、他言語出身者にはあまり馴染みがないのではと思い、実務でどう使ったかとあわせて紹介します。
きっかけは、Railsのログマスキングの実装方法を見直したことでした。
Railsには元々 config.filter_parameters(ActiveSupport::ParameterFilter)という、指定したキーの値をログ上で[FILTERED]に置き換える仕組みが用意されています。ただしこれには2つの制約があります。1つは、キーと値のペアを受け取って値を置き換えるだけなので既存にないキーを新しく追加することはできないこと。もう1つは、フィルタ条件がキー名ベースで、リクエストパスごとに対象を変えられないことです。
実務では「パスごとに対象キーを変えつつ、文字数という新しい情報をログに出す」という要件だったため、標準のfilter_parametersだけでは実現できず、もともとはミドルウェアで実装する予定でした。しかしミドルウェアの層で新しいログ用の項目を作ろうとすると、Railsがログ出力時に見ているのは結局request.parameters由来の値なので、新しいキーを反映させるには実際のリクエストパラメーターに値を追加するしかありません。その結果、ミドルウェアで項目を追加した分だけ、コントローラーには本来送られていないはずの項目が追加されて届いてしまうという副作用がありました。パラメーターは permit で明示的に許可したものしか使われないので機能的に壊れることはなさそうでしたが、思わぬ弊害を引き起こす可能性も考えられました。
そこで、ログ出力時の値だけをその場で加工する方針に変更することにし、Railsのリクエストログが request.filtered_parameters の戻り値を使っていることに着目しました。ここだけを狙い撃ちできれば、コントローラーやミドルウェアには一切手を入れずに済みます。この「入口を変えずに、戻り値だけ加工する」という要件と、prepend の「元の処理をsuperで包む」という性質が綺麗にはまりました。
システム開発第二事業部の高山です。普段はエンジニアとして、主にRubyを使用してバックエンドの開発を行っています。
「クライアントの別システムが Kotlin で動いているので、技術スタックを合わせて新規開発が可能か検討して欲しい」。普段は Rails で開発しているチームに、ある日そんな相談が降ってきました。チーム内に Kotlin や Spring Boot の開発経験者がいない状態でした。
そこで「簡単なものを実際に作りながら基礎を学ぶ」ことから始めました。AI コーディング支援を併走させながら、認証・DB・S3・メールが入った REST API を一通り組んでみる、という小さな検証です。本記事はその記録と、普段Railsを使用している立場で感じた所感をまとめたものです。
採用判断に必要十分な要素を盛り込んだサンプル API を、AI 支援を使いながら 2 時間で組みました。プロジェクトの初期構成は Spring Initializr でダウンロードしたものをベースにしています。途中でエラーに引っかかったのは 2 箇所だけで未経験の言語とフレームワークの組み合わせにしては想定より精度高く作業を進められた印象です。
| 項目 | バージョン |
|---|---|
| Spring Boot | 4.0.5 |
| Kotlin | 2.2.21 |
| Java | 17 |
| Gradle | 9.4.1 |
| DB | PostgreSQL 16（Docker） |
| ストレージ | MinIO（S3 互換、ローカル開発用） |
| メール | MailHog（送信モック） |
Spring Boot は 4 系を選びました。3 系で安定を取るか少し迷いましたが、「せっかく検証するなら新しい方で躓いておこう」という理由です。
POST /api/auth/register — ユーザー登録POST /api/auth/login — ログイン → JWT 発行GET /api/users/me — プロフィール取得（要 JWT）POST /api/emails/send — メール送信POST /api/files/upload — S3 互換ストレージへのアップロード採用検討に出てくる定番の関心事（認証・DB・ストレージ・メール）が、ひと通り当たるラインナップにしました。
続きを読むシステム開発第一事業部の広瀬です。 普段はReactのフロントエンドエンジニアとして、日々業務を行っています。
私は田舎に住んでおり地元の農家さんから、「田んぼやビニールハウスなどの現場の温度や水位が異常な値になったとき、気づくのが遅れてしまう」や、「ビニールハウスまでの距離が長く、移動の労力や時間がかかってしまう」など苦労話をよく聞きます。 今回その課題を解消するために、簡単ではありますが、センサーの値を自動で監視し、しきい値を超えた場合「LINE」でアラートメッセージを送信するシステムを作ることにしました。
このシステムは Google Apps Script（GAS）で動いており、追加のサーバーを用意しなくても、Google のスプレッドシートとLINEアカウントさえあれば運用できるようになっています。
続きを読むDX本部システム開発第二事業部の冨永です。
現在、主にiOS/Flutterアプリの開発を担当しております。
今回は、「RevenueCat App Growth Annual Tokyo 2026（RAGA Tokyo）」参加レポートの後編です。後編では、サブスクリプションと広告を組み合わせたマネタイズ設計と、実際に自分でアプリをダウンロードして触ってみた検証についてまとめています。
前編はこちらです。
前編では市場動向やAI活用、海外企業のグロース戦略についてまとめましたが、この後編では「マネタイズをどう設計するか」というテーマに絞って、フレームワークと実例をセットで見ていきます。
続きを読む