<p><img width="200" height="200" src="https://techblog.recochoku.jp/wp-content/uploads/2024/04/css-icon-200x200.png" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p><h2>はじめに</h2>こんにちは！レコチョクでWebアプリ開発のフロントエンド領域を担当している山本です。最近、Next.jsに<a href="https://tailwindcss.com/">Tailwind CSS</a>というCSSフレームワークを導入して開発する機会がありました。CSSフレームワークを導入することで、1から全てスタイルを当てることなく統一感のあるデザインを作成することができます。しかし、デザイナーが指定しているフォントのサイズ感や余白感が導入したCSSフレームワークの定数と異なることは多々あるかと思います。また、命名が汎用的すぎて逆に分かりにくいということもあるのではないでしょうか。Tailwind CSSのクラスをカスタマイズして開発を行なっていたので、その設定方法をご紹介します。<h2>やりたいこと</h2>Tailwind CSSには以下のような汎用的なクラスが用意されています。<a href="https://tailwindcss.com/docs/font-size">フォントサイズ</a><img src="/wp-content/uploads/2025/05/c019cec0c8eaa82726751d67a39b7eb8.png" alt="スクリーンショット 2025-04-25 17.01.09.png" /><a href="https://tailwindcss.com/docs/color">色</a><img src="/wp-content/uploads/2025/05/5b994126dbe6c64f53c25ceeea5e29a1.png" alt="スクリーンショット 2025-04-25 17.01.32.png" /><a href="https://v2.tailwindcss.com/docs/margin">余白<

<p><img width="180" height="180" src="https://techblog.recochoku.jp/wp-content/uploads/2016/10/Compute_AWSLambda.svg_-180x180.png" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p><h2>はじめに</h2>NX開発推進部の森川です。運用しているシステムにおいて、外部のAPIにリクエストを送るという部分があるのですが、SQSで処理する様になっています。SQSで処理することには様々な利点がありますが、一例としては、「外部APIが何らかの障害等で停止している」場合でも、解消後に再リクエストすることで簡単にリカバリーできる点が挙げられます。ただ、このSQSでデッドレターキュー(以降はDLQと表記)の作成を有効にしている場合、inactive状態でキューの処理が実行されると、その処理はエラーにならずに流れてしまいます。そういった場合にも自動でリカバリーできる様に、Amazon EventBridgeとLambdaを使って定期的にDLQに積まれたキューを再実行させる仕組みを作成しました。今回はその方法を記載していきます。また、今回の記事ではFIFOを対象としています。<img src="/wp-content/uploads/2025/05/all_statue.png" alt="all_statue.png" /><h2>目次</h2><ul><li><a href="#はじめに">はじめに</a></li><li><a href="#目次">目次</a></li><li><a href="#バージョン情報">バージョン情報</a></li><li><a href="#lambda用の関数作成">Lambda用の関数作成</a></li><li><a href="#lambdaの作成">Lambdaの作成</a><ul><li><a href="#関数の作成">関数の作成</a></li><li><a href="#アクセス権限の設定">アクセス権限の設定</a></li></ul></li><li><a href="#eventbridgeの作成">E

<p><img width="200" height="200" src="https://techblog.recochoku.jp/wp-content/uploads/2025/04/MCP.png" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p><h2>本記事の対象の読者(読了時間: 10分弱)</h2><ul><li>生成 AI や MCP (Model Context Protocol) に興味がある方、初学者</li><li>LLM アプリと外部サービス連携の仕組みをざっくり知りたい方</li></ul><h2>はじめに</h2>レコチョクのシステム開発第1グループに所属している山根と申します。普段は「OpenAI」「Anthropic (Claude)」「Google (Gemini)」のモデル等に対応したチャット基盤を運営・開発しております。目まぐるしいほど、日々の生成 AI のニュースやモデルの更新情報が流れてきますが、特に3月末から近日にかけてよく耳にするようになった、Model Context Protocol (MCP) という言葉。聞いたことがあったり、ご存知の方も多いかと思います。初めて知ったという方は名前からして難しそうだな〜と感じたり、調べてみても概念的な説明も多くあまりピンと来なかったという方も多いのではないでしょうか。本記事では、自分がそのように感じた経緯もあって MCP の基本からざっくり理解できるように、私なりにまとめてみた記事となります。<h2>目次</h2><ul><li>Model Context Protocol (MCP) って結局、何者？</li><li>とりあえず使ってみる</li><li>MCP の仕組み</li><li>まとめ</li></ul><h2>Model Context Protocol (MCP) って結局、何者？</h2>MCP とは、生成 AI モデル Claude で有名な Anthropic 社が2024年11月に発表した、<strong>LLM アプリと外部システムをつなぐためのオープン標準プロトコル</strong> です。<a href="https://docs.anthropic.c

<p><img width="180" height="180" src="https://techblog.recochoku.jp/wp-content/uploads/2016/11/android-180x180.jpg" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p><h2>はじめに</h2>こんにちは。<br />NX開発推進部プロダクト開発第1グループでAndroidアプリを開発している休井です。<br />我々Androidエンジニアはグループの取り組みとして、モブプロ会を定期開催しています。<br />今回は、モブプロ会の経緯やそこで得られた成果を紹介したいと思います。<h2>モブプロとは</h2><strong>モブプログラミング（モブプロ）</strong> は、複数人で1つの課題に取り組みながら、1台のPCを使ってコードを書いていく開発手法です。<br />コードを書く「ドライバー」と、方向性を示す「ナビゲーター」に役割を分け、交代しながら進めていきます。<br />ペアプログラミング（ペアプロ）と似ていますが、モブプロは3人以上のチームで行う点が特徴です。<br />チーム全員で議論しながら進めるため、ナレッジ共有や設計の理解が深まりやすいという利点があります。<h2>モブプロ会について</h2><h4>背景</h4>我々レコチョクのAndroidチームでは、次のような課題感を持っていました。<ul><li>多くの現行プロダクトが運用フェーズに移行している中で、0からの設計や技術の導入に関わっていないメンバーが多い</li><li>未導入の技術や新しい技術に対し、プロダクトに本格採用する前にあらかじめ検証を重ねて知識を深めておきたい </li></ul>元々Jetpack Compose等の新技術についてモブプロ形式で学習をした経験があり、チーム全体での学習にモブプロが有効的であるという認識がありました。<br />そのため、上記課題を解決しエンジニアとしてのスキルを底上げするためにモブプロ会を定期開催しよう！という運びになりました。<h4>参加者</h4>モブプロ会には10名程度参加しており、Android開発経験は以下のような分布になっていま

<p><img width="200" height="200" src="https://techblog.recochoku.jp/wp-content/uploads/2021/12/shinsyakaijin_couple2-200x200.png" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p><h1>はじめに</h1>こんにちは、株式会社レコチョク新卒1年目の本多啓路と申します。現在はプロダクト開発第1グループに所属しており、Androidアプリの開発に携わっています。本記事は、我那覇さんの<a href="https://techblog.recochoku.jp/11774">OJTを通じたアプリ開発の取り組み</a>の続きの記事になります。アプリ開発中に工夫してうまくいったことと、失敗したことについて紹介していきます。<h2>工夫してうまくいったこと</h2>まずは開発中に工夫したことについて紹介していきます。<h3>・GitHub Projectsの使用</h3>アプリ開発についての進捗や自分の担当しているタスクを管理するために、今回はGitHub Projectsを使用しました。GitHub Projectsは、GitHub上でプロジェクト管理を行うための機能になります。ソフトウェア開発のプロジェクト管理やタスク管理を支援するために提供されており、以下のような特徴を持っています。<ol><li>カンバンスタイルのボードを利用して、タスクを視覚的に管理できます。</li><li>GitHubのIssueとPull Requestを直接プロジェクトにリンクでき、それらをタスクとして扱うことができます。</li></ol>この特徴を利用しつつ、毎週ミーティングを行うことで効率的に進捗確認や1週間ごとに行うタスクの割り振りを行うことができたと考えています。<img src="/wp-content/uploads/2025/04/GitHub-Project.png" width="100%"><h3>・mermaid.jsを使用したダイアグラムの作成</h3>アプリ作成には要件(詳しくは我那覇さんの記事を参照)があり、その中の一つにシーケンス図とクラス図の

<p><img width="200" height="200" src="https://techblog.recochoku.jp/wp-content/uploads/2021/12/shinsyakaijin_couple2-200x200.png" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p><h2>はじめに</h2>こんにちは、株式会社レコチョク新卒1年目の我那覇です。プロダクト開発第1グループに所属し、Androidアプリエンジニアとして業務に携わっています。配属から約半年間、個別課題を進めた後、業務と並行して同期の本多と２人でのアプリ作成課題に取り組みました。本記事では、アプリ作成課題の詳細と全体の流れを振り返りながらご紹介します。<h2>目的</h2>アプリ作成課題の目的は大きく次の2つです。<ul><li>これまでの研修で習得した知識をアウトプットする</li><li>２人で協力し、チーム開発を経験する</li></ul><h2>アプリ開発の要件</h2>今回の課題を進めるにあたり、以下の要件が提示されました。<ul><li>UI：Jetpack Composeを利用して2画面以上のUIを作成し、画面間の遷移を実装する</li><li>通信：無料APIを用いて通信を行い、OkHttp + Retrofitのライブラリを活用する</li><li>設計：MVVMアーキテクチャを採用し、シーケンス図、クラス図を作成する</li><li>機能：ライトモードとダークモードを選択可能にし、アプリ再起動後も設定を保持する Coilライブラリを使用してWebから取得した画像を表示する</li></ul>これらの要件を満たすため、GitHubのIssuesやProjectsを使ってタスクを細分化し、進捗を管理しました。<h2>開発の進め方</h2>一週間単位に区切り、以下の方法で情報を共有しながら開発を進めました。<ul><li>週2回のMTGを設定<ul><li>水曜：私と本多の2人で進捗確認</li><li>実装について困っていることがあれば相談し、機能のアイデアや改善点について話し合う</li><li>金曜：OJTの先輩も交えた進捗確認</li><li>一週間の

<p><img width="200" height="200" src="https://techblog.recochoku.jp/wp-content/uploads/2017/11/OpenAPISpec-200x200.jpg" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p><h1>はじめに</h1>こんにちは🌞システム開発推進部システム開発第3グループの小河です。普段はレコチョクの各サービスが共通で利用するバックエンドシステムの開発や運用を担当しています。本記事では、<strong>Swagger Editor</strong>と<strong>Redoc</strong>と<strong>GitHub Pages</strong>を組み合わせ、<strong>OpenAPIベースの仕様書を管理・社内公開する方法</strong>について、事例を通してご紹介します。<h1>APIドキュメントツールを用いる背景</h1>弊社では様々なサービスを展開していますが、共通で必要となる機能も多くあります。(例: 課金・音源の配信など)そのため、それぞれの共通機能を主にREST APIとして提供し、他組織が開発するサービスがそのAPIを利用して機能を実現しています。我々システム開発第3グループにてそれらAPIの開発を行っている都合上、<strong>API仕様書の管理と社内の他組織への公開</strong>を行う必要があります。<h1>Postmanを利用する上での課題</h1>我々システム開発第3グループでは、APIドキュメントツールとして<a href="https://www.postman.com/">Postman</a>を利用していました。しかし、ユーザーごとに課金がなされる料金体系(2025/03現在)のため、コスト上の課題がありました。社内の運用方法として<strong>利用ユーザー数に上限を設けたため、新たに案件に参画したメンバーはPostmanをすぐに利用を開始できない状態が発生していました。</strong><h1>なぜSwagger Editor + Redoc + GitHub Pagesか</h1>そこで、<a href="https://s...

<p><img width="200" height="200" src="https://techblog.recochoku.jp/wp-content/uploads/2025/03/compute-amazon-ecs-200x200.png" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p>NX開発推進部の齋藤です。今回は Amazon Elastic Container Service (ECS) で発生した接続不安定障害とその対応策（アベイラビリティゾーンの再調整）について紹介します。この記事は ECS をある程度運用したことがある方を対象にしています。<h2>【背景】</h2>現在運用中の Web サイトは、次の構成で稼働しています。<img src="/wp-content/uploads/2025/03/archtecture_1.drawio.png" alt="archtecture_1.drawio.png" />図1: NLB を使用した Web サイトの構成（簡略図）(図は簡略化していますが、) ECSのコンテナをアベイラビリティゾーン別で2台起動しています。この構成の特徴は、固定 IP が必要なため、別アカウントの Application Load Balancer (ALB) からの通信を受ける目的で Network Load Balancer (NLB) を採用している点です。アベイラビリティゾーンごとに固定IPを設定し、ALBからそのIPに転送しています。ある日、Web サイトへの接続が不安定になる障害が発生しました。調査の結果、ECSのタスクがパッチリタイアメントにより自動再起動され、その際にアベイラビリティゾーンへの配置が偏っていたことが原因であると判明しました。<img src="/wp-content/uploads/2025/03/az_rebalancing_1.png" alt="az_rebalancing_1.png" />図2: アベイラビリティゾーンの偏りが発生した状態この偏りにより、NLB の振り分けが正しく行われず、一部のゾーンでは 504 エラーが発生し、接続が困難な状況となりました。<img src="/w

<p><img width="180" height="180" src="https://techblog.recochoku.jp/wp-content/uploads/2016/09/Python-180x180.jpg" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p><h2>はじめに</h2>こんにちは、株式会社レコチョクの小林です。日頃は、主にPythonを用いたバックエンドの開発に携わっています。最近参画した業務で、バックエンドをPythonのFastAPIで、フロントエンドをNext.jsとTypeScriptで実装する機会があり、それぞれ異なるチームが開発を担当する中で、バックエンドとフロントエンド間での型情報の共有が課題となりました。そこで本記事では、異なる言語間でどのように型定義を同期させるか、その解決方法を検討します。<h2>開発環境</h2><ul><li>バックエンド：Python 3.12.0、FastAPI 0.110.3</li><li>フロントエンド：Next.js 15.2.2、TypeScript 5.8.2</li><li>コード管理：GitHubで別々のリポジトリで管理</li><li>コンテナ管理：Dockerを使用</li></ul><h2>現状の型定義方法とその課題</h2>前述のプロジェクトでは、バックエンドとフロントエンド間の型共有に関して、主に以下のような方法を採用していました。<ul><li><strong>手動での型定義</strong>：フロントエンド開発者がバックエンドのAPIドキュメントを参照し、TypeScriptの型定義を手動で作成</li><li><strong>ドキュメントベースの開発</strong>：Swagger UIなどのAPIドキュメントを参照しながら開発を進める</li><li><strong>コミュニケーションベース</strong>：バックエンドの変更があった場合、口頭やチャットでフロントエンド開発者に伝達</li></ul>これらの方法には以下のような課題がありました：<ul><li><strong>手動更新の手間</strong>: APIの変更ごとに型定義を手動で更新する必要があ

<p><img width="200" height="200" src="https://techblog.recochoku.jp/wp-content/uploads/2024/03/Kotlin_logo-200x200.png" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p><h2>はじめに</h2>こんにちは、株式会社レコチョク新卒1年目の我那覇です。昨年10月よりプロダクト開発第1グループに配属され、Androidアプリ開発エンジニアとして業務に携わっています。Serializationは、KotlinでJSONレスポンスを扱う際に便利なライブラリです。本記事では私自身の経験を交えながら、使用する際に初心者が気をつけたいポイントを紹介していきます。これからSerializationを導入しようと考えている方の参考になれば幸いです。<h2>実行環境</h2>macOS 14.4.1 SonomaAndroid Studio Koala | 2024.1.1 Patch 1Kotlin 1.9.0<h2>導入</h2>Serializationを利用するには、[crayon-682ae8642cb2a291724462-i/]に以下のプラグインの設定を追加します。[crayon-682ae8642cb30626809552/]この設定により、データクラスに[crayon-682ae8642cb31184448418-i/]アノテーションを付与することで、データクラスのシリアライズ/デシリアライズが可能になります。本記事では詳しい説明は割愛するため、詳細な導入方法や基本的な使い方については公式ドキュメントをご参照ください。<blockquote> <a href="https://kotlinlang.org/docs/serialization.html#formats">公式ドキュメント</a> <a href="https://github.com/Kotlin/kotlinx.serialization/blob/master/docs/json.md#ignoring-unknown-keys">GitHub</a></blockquote><h2>使用