I wish it could be Christmas everyday

RNI 開発部 koshima です。

この記事はRNIアドベントカレンダー8日目の記事になります。予定では今年の物価について考察するつもりだったのですが、明るくおもしろい感じに仕上がらなかったので、心の片隅で困っている写真の話をします。

I wish it could be Christmas everyday.

サンタさん、ちょっと聞いて。 ここ5年くらい同じようなこと話してるかもしれないけどサ。

photo storage

写真の保管に NAS が欲しい。

ジャパンカップで全力で撮ると3日間で 128GB, 64GB, 128GB くらい写真を撮ってしまうんです。それをあけて現像したりしてるうちに翌週にまた次のイベントで 128GBくらい撮っちゃう。

お金で殴るなら、aws s3 にアップロードして解決ですが、1年に 0.5TB とか増えていきます。どんどん維持費はかかるし、遠いところに置くと、ちょっと見直そうとか新しいソフトで現像やり直してみようとかするのが面倒です。あの写真を使おうとしてもなかなか引っ張り出せない。

NAS の箱に HDD 2本くらい入れて RAID 1 ＋ SSD キャッシュだと金額最小で写真のアップロードが速くていいかな。HDD 3本入れて RAM増やして RAID-Z にするべきか。

NAS の箱

8ベイの箱に４ドライブ入れて大きなファンで冷やしたい。

懸念点。

• 今、活線挿抜の箱っていくらくらいするのかな？ 中古のサーバーを買って中身を入れ替えるのがいい？
• ZFS を使うためにメモリには ECC が欲しいけれど、AMD Ryzen + ECC って落ち着いているの？（知識不足）
• AMD Ryzen + TrueNAS って kernel 突然死解消した？（調べて PR 送るのだ）

NAS とネットワーク

SSD cache を有効に使うなら、コピー元と無線で繋ぐのはもったいない。せめて 2.5GbE くらいの有線が欲しいです。OM3 で 10GbE にしようぜ。

NAS の設置場所

仕事部屋や寝室に置くと、ある時不意に怒りの電源断に遭遇するのは既定路線。ファンを静かなものにして、重たいケースで HDD の音を押さえ込まなくてはならない。 2階や屋根裏は夏は灼熱なので、1階に置くか平日はクーラーが入る仕事部屋で妥協するか。

課題： 1-2階の有線ネットワーク

雷鳴る土地なので、UPS も忘れずにね！

考えることはいろいろです。

そもそも NAS のリスクは

• HDD 故障 ← 一定時間過ぎるとリスクが上がる。バスタブ曲線。放熱がよくケース（＋設置場所）が頑丈だと振動が減り故障率が下がる。
• RAID コントローラー故障 ← わりとよくある
• 電源故障 ← わりとよくある
• 停電 ← UPS で防御する。安いのは 2万円から。
• ECC なしメモリのパリティエラー ← 宇宙線の影響でメモリのビットが反転する。私はもう3度見た。データセンターではたまにエラー訂正起きている。
  • https://japan.cnet.com/article/20401367/

TrueNAS のソフトウェア RAID にしておくことで、ハードウェアの故障から逃げられる。暗号化鍵を保管しておけば。

NAS のバックアップ

結局、aws s3 に投げるの？

UPS バッテリー定期更新

メーカーのやつではなくて定格が同じオートバイ用のバッテリーでいいよ。 10年くらい経ったら本体買い替えで。

future

と色々考えていくと、 写真のストレージだけではなく、家庭内のネットワークや仕事環境の問題に行き着くのです。 えいやっと一気に解決するのは大変なので、一つ一つコツコツ解決していきますかね。

AppClipを使ってアプリのデモを作る

RnI開発部 iOSチームのtaigaです。

この記事はRNIアドベントカレンダー6日目の記事になります。 AppClipを使ったアプリのプロモーションについての話です。

App Clipを使うことでオフラインの場で簡単にアプリの機能を一部体験してもらうことができると考えたので、App Clipについてや実装方法についてまとめた記事となります。

AppClip とは？

アプリをインストールせずにQRコードやNFCなどから使用できる極小のアプリです。 国内で見かける利用例ではスキャン表示読み取りがよく採用されていて、円状のQRコードのような形をしています。

App Clipコードのサンプル

eager_loadでサービスを停止させた話

RNIアドベントカレンダー 5日目の記事です。
リサーチ・アンド・イノベーションの横山です。
今年もアドベントカレンダーの季節になりました。ちょっと今年もアウトプットしなさすぎでしたね。もっと書かないと。

自己紹介

RNIにお世話になってはや8年目。
エンジニア歴20年くらい、Ruby歴は25年くらいです。
三浦半島の付け根に住んでいます。
今年の2月から三浦半島.rbという地域Rubyコミュニティが立ち上がり、そちらにもお邪魔しています。
だいたい二ヶ月に一度くらいの頻度で集まっているので、お近くにお住まいの方は是非顔を出してみて下さい。

miurahantorb.connpass.com

みんなで三崎港に行ってマグロを食べたりしてます

マグロ

三崎館本店

サービスの紹介

ここから本題です。
表題の障害が発生したサービスは、買い物をしてレシートをアップロードするとポイントが貰えるアプリ(のbackend)です。
弊社のメインとなるアプリ、CODEとは別に、（CODEのノウハウと技術を活かして）他社さんと協業でやっているサービスです。
技術的には流れをくんでいるものの、backendは全く別に一から開発しています。
今回はこのサービスに起きた障害を紹介し、原因究明までお話ししたいと思います。

iOS アプリ内データ管理をSharedStateに移行する

これは RnI 開発部 (DD) Advent Calendar 2025 4日目の記事です。

こんにちは。リサーチ・アンド・イノベーションの小川です。 iOSエンジニアとしてCODEアプリの開発を担当しています。

今年はアプリ内のデータ管理について大きく改善し、扱いやすい構成にしましたのでそちらについてご共有したいと思います。

概要

CODEでは色々なデータが混在して表示されています。

クリアすることでポイントが確定できる クエスト 、抽選で景品が当たる ラッキーエッグ などユーザが参加できる案件に幾つかタイプがあり、さまざまなデータがさまざまな画面から更新されることとなります。

例

すべてタブ画面: クエスト・ラッキーエッグなどの色々な種類の要素が表示されている

クエストタブ画面: クエストの情報が表示されている

エッグタブ画面: ラッキーエッグの情報が表示されている

すべて	クエスト	タブ

各データは色々な画面経由で更新されることになります。(該当データを表示していない画面からも更新が入ったりします)

勉強会/SDD/大規模言語モデル時代で知った方がいい知識

はじめに

こんにちは！

これは RnI 開発部 (DD) Advent Calendar 2025 2日目の記事です。

リサーチ・アンド・イノベーションのhongです。iOSエンジニアをやっています。

CODE アプリではTCA移行が順調に進んでいる中、AIも大活躍してます！

興味がある方は是非試してください！

CODEアプリ：https://code.r-n-i.jp

今回のテーマはAI関連です、最近 github copilot for xcode のおかけで仕事がもっとスムーズになりました。今回使うだけじゃ足りないと思って色々調査しました、少し整理しようと思います。

github copilot for xcodeについて

定番のAskモード以外でAgentモードも用意されています、底部のスライドボタンで切り替えます

モード切り替え後、Xcodeが出してるエラーの隣にアイコンが追加されます：

このアイコンをタップするとエラーの分析と修正をLLMに投げます、そして分析と修正をやってくれます：

これは素晴らしいです、ワンクリックでエラー修正されて、しかも分析とエラーの原因もしっかり生成されます！

今回、基礎の概念をシンプルに説明しようと思います

LLM と Prompt

LLMはLarge Language Models(大規模言語モデル)の略称、「大量のテキストデータを学習し、人間のように自然な文章を生成・理解することに特化したAIモデル」

プロンプト（Prompt）とは、AIとの対話やコマンドラインインタフェース（CLI）などの対話形式のシステムにおいて、ユーザが入力する指示や質問のことです。AIがユーザの要求や問いに対して適切な応答や結果を生成するためには、明確で具体的なプロンプトが必要です。不適切なプロンプトを使用すると、AIが望ましくない結果や誤った情報を生成する可能性があります。（以下↓の記事内一部説明引用しました）

https://www.softbank.jp/biz/solutions/generative-ai/ai-glossary/prompt/

user prompt

ChatGPTが発表されましたが、見た目は普通のSNSアプリとほぼ同じです。我々は問題もしくは話したいメッセージを送って、AIがメッセージを生成して返信します。そこで我々が送信したのはuser promptですね：

system prompt

一方で我々がリアルで他の人に質問した時、全く同じ質問でも相手によって答えはバラバラになりますよね。例えば 腰が痛い、どうすればいい を友たちに聞くと 貼り薬使ったら で返答しますが、両親に聞くと お医者さんに見てもらう？ :laughing:

けれどAIは自分の友達でもないし、親でもない。質問を投げると 腰痛緩和の方法XX みたいな返答を生成されます。悪くないですが、もっと生き生きとした答えが欲しいですね。

そこでAIにも一定の設定を最初から持たせると、生成された答えはもっと正確になると思われます：

AIに投げるuser prompt内 君が僕の両親 の設定を入れて、君が僕の両親で、私は今腰が痛いのuser promptをAIに投げると、より生き生きとした答えをもらえます。

ですが、毎回質問した際 この設定を書くのはイマイチですね、そこで設定だけはuser promptから分離した物system promptとなります。

system promptは主にAIのキャラクター設定、性格、言葉使いなどのデータを保存してます。AIに質問するたびAIツールはsystem promptとuser promptをまとめてLLMに投げます。 system promptはAIツールで事前設定されます、通常我々は変更できません：

AI Agent・Tool

AIとのやり取りは問答の形式でできるですが、このやりとりですと自分達でAIの答えを見てコードを書く必要あります。具体的な任務を完成までできると最高じゃないですか？

そこでAutoGPTが出ました：

https://github.com/Significant-Gravitas/AutoGPT

日本語のチュートリアルもあります!

AutoGPTはローカルで走らせられます。具体的に何ができるか一つの例を説明します。 AutoGPTにやることを投げます：パソコン内のXcodeのpathを教えてください：

list_filesとread_filesは事前書いた関数です、そしてこの関数たちの具体の説明と使用方法をAutoGPTに登録しています。

AutoGPTが登録された関数のもとに：どのような関数（list_files, read_files）が用意されたか、どうやって使う（call_toolname）のか、system promptを生成されます。

①AutoGPTは我々が出した指令（user prompt）と事前生成されたsystem prompt一緒にまとめてLLMに投げます。

②LLMが賢いのであれば、その要求に対し適切な関数を呼ぶメッセージを生成して、AutoGPTに投げます（ここAutoGPTに投げたメッセージはAutoGPTがsystem prompt内定義された形式になります、例：call_toolname）

③AutoGPTがメッセージを受け取って解析成功したら、関数list_files()を呼ぶ事ができます。そして関数実行し、結果をAutoGPTに返却します。

④最後関数実行した結果をLLMに投げます、LLMはそれを分析しAutoGPTに新しいメッセージを返却します。

やることを完成させるまで、①から④の過程を循環します。

この様なuser、関数、LLMの間通信するプログラムをAI Agentと呼びます。 そして関数の部分はAgent Toolと呼びます

function calling

AI AgentのおかけでAIが自力で問題解決する事ができました！しかし少し問題があります。

system prompt内では具体的なfuncの使い方や使うため返すべきフォーマットを自然言語で説明しましたが、一定の確率で違う答えを生成します。AIは確率分布ですので。

この問題を解決する為一部のAI Agentは間違えたフォーマット受けた際問題をAIにもう一度投げ、正確のフォーマット受けるまで再試行します。

この方法は問題を解決できますが、デメリットも大きいですね、不安定かつtokenを大量に消費します。

そこで、LLM側で解決すればいいじゃない？という声が出て、LLM提供する企業がLLM内に新しい機能実装しました、それがfunction callingです：

function callingが何をやってるのかを一言で言うと: フォーマットを統一し、AIにもルールを分からせる

function callingを使えば、元々system prompt内に自然言語で書かれた どのような関数（list_files, read_files）が用意されたか、どうやって使う（call_toolname）のかの記述は標準化され、system promptから分離されます。

上の例ですと一個のAgent ToolはJSONで定義されて、tool nameはname keyのvalueに指定、tool descriptionはdesc keyのvalueに指定、必要なparamsはparams keyに指定します。

最後はLLM側生成される物のフォーマットも決めます（例はJSONですね）

これで全てのAgent toolの説明、AIに投げる時のフォーマット、LLM側生成された物のフォーマットこれら全部function calling内管理されます。

フォーマットが統一された事でLLMの特定のトレーニングがもっと簡単になります、トレーニングの最後ではLLMは自分がやった事をより理解し、同じ質問を投げると： あぁ、この問題やった覚えがある の様に素早く回答を生成します。

もう一点素晴らしい事は、function callingはLLMが生成された内容のフォーマットを決めたので、もしAI生成された内容が決めたフォーマットと違う場合、AIサーバー内でその間違えを自動検知して、自ら再度答えを生成します。これでAI Agentの開発難易度も下がり、プラスでclient側のToken消費も抑えられます。

これらのメリットによって多くのAI Agentはsystem promptからfunction callingに切り替えができますね。

実はfunction callingも抱える問題があります、LLMによって提供されたAPIもそれぞれ違うので（LLM開発された会社がAPI決めるので、仕方ないですね）複数のLLMがサポートするAI Agentを開発するのも簡単ではないです。

なのでまだsystem prompt使用して開発されたAI Agentもある程度あります。

mcp

AI AgentとLLM間の通信問題ほぼ解決の後、まだAI AgentとAgent tool間通信の問題が残ってます。

一番シンプルなやり方はAI AgentとAgent toolを同じプロジェクト内に書くことです、そうするとただfunctionを叩けば問題ないです。

しかし汎用的なAgent tool（例えばweb browserのAgent toolとか）をAI Agent作るたびにコピーして入れるのも良くないですね。

そこで解決策が出されました、それがmcp（Model Context Protocol）です：

mcpは通信protocolの一種です：（http(Hypertext Transfer Protocol)、ftp(File Transfer Protocol)、みんなprotocol同士）

https://ja.wikipedia.org/wiki/Model_Context_Protocol

mcp server内共通で使用したいtoolsを入れてます、そしてmcp server内のtool使用するAI Agentはmcp clientと呼びます。

mcpはprotocolなのでAgentとTool間の通信はこのprotocolのルール（フォーマット、APIとか）に従う必要があります。

mcp serverも色んなAPI提供しています、例えばmcp内のtool listのAPIとか、各toolの説明とか、リクエスト時必要のパラメーターとか。

tool以外他にresourcer（ファイルのread・write機能）とprompts（promptのテンプレート機能）も提供してます。

mcp serverはAI Agentと同じサーバーに置くことができますが、AI Agentと分離し他のサーバーに置くのも出来ます、その時はhttp（Streamable HTTP）を使用してデータ交換をします。

mcpは基本LLMと関連しない、AgentがどのLLMモデル使用したのかmcpは気にしないです。

最後

最後少し整理しましょう：

①：ちょっと腰が痛いので、AI Agent（mcp client）に腰が痛い、どうすればいい？の問題を投げます。

②：Agentは問題を処理してuser promptを生成する

③：Agentはmcp serverと通信しtoolsのデータを取得してsystem promptに処理する（もしくはfunction callingリクエストのフォーマットに変換）

④：Agentはsystem prompt（もしくはfunction callingリクエスト）とuser prompt結合してLLMに投げる

⑤：LLMはデータを処理して分析した後、web_browserのtoolsの使用を決めて、AI Agentにweb_browser tool使用するリクエスト（system prompt内決めたフォーマットもしくはfunction calling）をAI Agentに投げる

⑥：AI Agentはリクエストを処理し、url指定して、mcp server内のweb_browser toolでの使用リクエストする

⑦：mcp serverがweb_browser tool使って指定したurlを解析し、データをAgentに返す

⑧：Agentはmcp serverから貰ったデータをLLMに渡す

⑨：LLMはデータのもとに思考を始め、そして答えを生成してAgentに渡す

⑩：最後Agentは答えを我々に見せる（テキストフィールドに展示）

system prompt、user prompt、AI Agent、Agent tool、function calling、mcpたちが連携してようやく問題解決にたどり着きました！

今回のまとめは以上となります、ありがとうございました！

入社して2ヶ月、実際どう？働いて感じた会社の魅力

はじめに

こんにちは！

2025年10月からサーバーサイドエンジニアとして働いている Judeeeです。

これは RnI 開発部 (DD) Advent Calendar 2025 1日目の記事です。

私の入社の経緯や 実際に働いてみて感じたことなどを紹介していこうと思います。

入社の経緯

私が会社を知ったのは、受講していたオンラインプログラミングスクール フィヨルドブートキャンプの合同企業説明会でした。

そこで初めてサービスの存在を知り、興味本位でアプリを利用してみたことがきっかけです。

code.r-n-i.jp

それまでポイ活アプリは手間がかかる印象が強く、利用したことがありませんでした。 しかし、実際使ってみると、ゲーム感覚で気軽に利用できる点や、高い還元率によってポイントがすぐ貯まっていく点にも魅力を感じました。

また、自分がこれまで何かを継続できた理由を振り返ると、共通して 「楽しいから続けられた」 という理由があったため、「楽しさで行動を促すこと」に関心がありました。

そのため、弊社のミッションの一つである「消費者の普段の買い物を便利で楽しくする」と自身の価値観が一致したことも入社を決めた大きな理由のひとつです。

入社してからの印象

まだオンボーディング期間中ではありますが、魅力的に感じる感じる点がいくつもあります。

相談しやすい

入社したばかりの私にとっては特にありがたさを感じています。

相談のハードルが高く感じることもあると思うのですが、

• Slackの何でも質問していいチャンネル
• バーチャルオフィスGather

など気軽に質問できる場が用意されているのがとても心強く、いつも利用しています🙏

働き方が柔軟

時差出勤と中抜け制度があり、多くの方が活用しています。

また、フルリモートなので地方や海外在住の方も在籍しており、働く場所に縛られない自由さがあります。

学び続けられる環境

毎週、開発部全体の勉強会があり、サーバーサイドだけでなく、アプリチームの話を聞けるなど、知的好奇心が刺激される機会が多いのも面白いです。

また、RubyKaigi など外部カンファレンスへの参加支援もあり、非常にありがたい制度だと感じています。

穏やかな雰囲気

サーバーサイド、アプリ、PMといったチームの垣根を越えて積極的に協力している印象が強く、境界に縛られず課題解決に取り組んでいます。

「それはそっちの仕事だろ！」というような雰囲気は一切なく、「どうしたら早く問題を解決できるか？」を一緒に考える姿勢が文化として根付いていると感じています。 皆さん穏やかで、お互いをリスペクトしながら一緒に仕事をしている印象を受けます。

さいごに

リサーチ・アンド・イノベーションではエンジニアを募集中です！！

興味を持っていただけた方はお気軽にご連絡ください🙏

カジュアル面談もお待ちしています！

r-n-i.jp

RNIアドベントカレンダー2025

2025年、今年もRNIアドベントカレンダーを開催します！

日付	名 前	所属	内容
12/17	Judeee	サーバサイドエンジニア	入社して2ヶ月、実際どう？働いて感じた会社の魅力
12/18	ホン	iOSエンジニア	大規模言語モデル時代で知った方がいい知識
12/19	武田	Androidエンジニア	「今ひとつ」から「あって良かった」へ。2025年、GitHub Copilotのアップデート振り返り
12/20	小川	iOSエンジニア	iOS アプリ内データ管理をSharedStateに移行する
12/21	横山	サーバサイドエンジニア	eager_loadでサービスを停止させた話
12/22	Taiga	iOSエンジニア	AppClipを使ってアプリのデモを作る
12/23	松本	SRE	AWS MCP を触ってみた話
12/24	koshima	サーバサイドエンジニア	I wish it could be Christmas everyday