<p><img width="180" height="180" src="https://techblog.recochoku.jp/wp-content/uploads/2016/12/small_v-180x180.png" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p><h2>結論</h2>以下の3ステップで実施可能です。１. 共有サーバー接続用ポートフォワーディング[crayon-691fc050d051a566798716/]２. DB接続用ポートフォワーディング[crayon-691fc050d0522911772188/]３. DB接続設定イメージ(Docker環境のアプリケーションでの設定)[crayon-691fc050d0524950190279/]<h2>背景</h2>こんにちは、株式会社レコチョクで開発を担当している田部井です。社内では主に、<a href="https://recochoku.jp/corporate/murket">murket</a>というサービスの開発を行っています。開発をしている中で、Dockerでの開発環境が存在しつつも、検証やテストのために共有サーバーが存在するような環境が世の中にはあるんじゃないかな〜と思っています。そのような状態で共有サーバーの方で何らかの問題がおき、その問題を解決するためにDocker環境で共有サーバーが利用するDBと同じデータを参照したい時がありました。ローカルだけで完結させたいなら、DBのダンプを取り、Dockerに反映するみたいなことでも解決できますが、ダンプはサイズ大きいと、取得にも反映にも時間がかかり大変だったりみたいなこともあるので、直接接続する方法を考えました。<h2>イメージ図</h2>通常時の調査、作業イメージ図<img src="/wp-content/uploads/2025/11/image-20251030092118326.png" alt="image-20251030092118326.png" />今回やりたいことのイメージ図<img src="/wp-content/uploads/2025/11/image-20251030092131226.png" al

<p><img width="180" height="180" src="https://techblog.recochoku.jp/wp-content/uploads/2016/12/swagger-logo-180x180.png" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p><h2>はじめに</h2> こんにちは！EggsPassチームで主にバックエンドエンジニアをしている徐です。本記事では、APIドキュメントジェネレータを <strong>Swagger v2 から v3 へ移行した経緯と方法</strong> を紹介します。<h3>背景</h3> プロジェクトで使用している API ドキュメントジェネレータ Swagger v2 は、長期間の運用を経て Node.js のバージョンアップや依存ライブラリの廃止などの影響を受けるようになりました。<h3>技術的な問題</h3><ul><li>Node.js のバージョンアップに対応できない</li><li>依存ライブラリが廃止されている</li></ul><h3>実務上の影響</h3><ul><li>新しいメンバーのPCでローカル環境を構築できない</li><li>Swaggerの更新作業を、一部の環境を構築済みのメンバーしか行えない</li></ul> これらの問題を解決するため、Swagger v2 の更新を諦め、v3 へ全面的に作り直すことにしました。本記事ではその手順を解説します。<h2>Swaggerとは</h2> <strong>APIドキュメントジェネレータ</strong>の一つとして、特にREST APIを設計・ドキュメント化・テスト・共有するためのオープンソースフレームワーク です。<h2>Swagger v2 と v3 の主な違い（移行時のポイント）</h2><h4>1.デフォルト機能でタグ参照ができない問題</h4> Swagger v2 では、統合機能により、メインの index.yaml ファイルで<strong>tags</strong>や<strong>paths</strong>単位でファイルを分けて再利用することが可能でした。 例えば、以下のように別ファイルに分けたものを、

<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>こんにちは、株式会社レコチョクの長島です。iOSアプリの開発などをしています。現在はプロダクト開発第2グループに所属しております。以前、ある音楽プラットフォームアプリの大規模改修をする際、Kotlin Multiplatform(以下KMP)という技術を採用しました。KMPは所謂マルチプラットフォーム技術ですが、実際に運用してみると、期待通りの効果もあれば想定外の課題も見えてきました。この記事では、KMP導入を軸としたiOS/Androidチームの統合とプロセス改善により、どのような結果が得られたのかを紹介します。なお、KMPを導入したアプリに関する記事としては「<a href="https://techblog.recochoku.jp/9877">【iOS】Kotlin MultiplatformでApp Clip対応アプリを2か月で作ったので振り返る</a>」なども存在しています。ご興味がある方はそちらもご覧ください。<h2>背景</h2><h3>システム全体の課題</h3>自分が関わっていたアプリは、長きに渡って開発されていたため、技術的負債が多く存在してしまっている状態でした。中でも、「APIの数が膨大かつインターフェースの実際の動きが仕様書と異なる部分がある」という課題が存在し、開発効率が落ちていました。こうした負債解消と将来的なエンハンス対応のため、2023年末から大規模なリアーキテクチャの計画が行われることになりました。様々な案が出ている中で、APIチーム側からBFF（Backend For Frontend）の導入提案がありました。BFFはフロントエンド専用のバックエンド層として、複数のAPIを集約し整形する仕組みです。これにより膨大なAPIや定義書との不一致を解消できる見込みがあったため、アプリチームとしても検討を進めていました。<h3>なぜ共通

<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>はじめに</h2>システム開発推進部 システム開発第2グループでWeb開発をしている笹野です。今さらながらですが、最近アニメ「CLANNAD」を見返しました。高校生の頃に見たときとは大違いでとんでもなく嗚咽泣きしてしまいました。(成長したってこと…？)さて、今回は最近発表されたChrome DevTools MCPについてです。どうやらWeb開発において幅広く活躍してくれそうなMCPということで、早速簡単にですが触ってみたので紹介します。<h2>Chrome DevTools MCPについて</h2>AIエージェントがChrome検証ツールを使えるようにするMCPです。コンソールログを見たり、ネットワーク状況やパフォーマンスを見たりなどなど、、、<br />とにかくChromeでの動きをAIが見られるようになります。指示すればChromeでのブラウザ操作もしてくれます。<h2>今回やること</h2>今回はAIくんによるChromeでの、<ul><li>コンソールログ調査</li><li>パフォーマンス測定</li><li>動作テスト</li></ul>といったところを実際に使って挙動を見てみます。AIにVue.jsで作ってもらった簡素なTODOリストを対象に使ってみます。こんな感じ↓<img src="/wp-content/uploads/2025/10/image-20251027031003083.png" alt="image-20251027031003083.png" /><h2>今回の実行環境</h2><strong>AI関連</strong><ul><li>Claude Code 2.0.27</li><li>Node.js v22.20.0 (Claude Code)</li><li>npm 10.9.3</li></ul><strong>確認対象のサイト(TODOリスト)</strong><ul

<p><img width="200" height="200" src="https://techblog.recochoku.jp/wp-content/uploads/2022/12/SwiftUI_logo-200x200.png" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p><h2>🔰 はじめに</h2>はじめまして。株式会社レコチョク NX開発推進部 プロダクト開発第2グループの上野です。2025年4月に新卒で入社し、9月より「PlayPASS」のiOSエンジニアを担当しています。趣味はポケモンカードで、先日有明GYM-EXで2日間に渡って開催された公式大会では、個人戦7戦中5勝2敗、チーム戦7勝0敗で、合計12勝2敗という好成績を残しました。夏のよい思い出です。<hr />配属前のエンジニアOJTでは、SwiftUIとUIKitのそれぞれで音楽アプリのホーム画面のモックを開発しました。まずはSwiftUIから実装を進めたのですが、「データと表示がそのままつながる」宣言的なフレームワークであったため、Swift初学者の私でも直感的にコードを書けました。一方、UIKitでは「データと表示とイベントがわかれる」命令的なフレームワークで、各コードが複数ファイルをまたぎ、その内容を理解しないまま書いてしまいました。本記事では、そのUIKitについて理解を深めるために、整理して解説していきます。<h2>👞 UIKitでつまずいた2行のコード</h2>そもそもUIKitには、レイアウトやデータ更新を制御しやすくするための4つのコンテナView（<a href="https://developer.apple.com/documentation/uikit/uicollectionview">UICollectionView</a>、<a href="https://developer.apple.com/documentation/uikit/uitableview">UITableView</a>、<a href="https://developer.apple.com/documentation/uikit/uistackview">UIStackView</a...

<p><img width="200" height="200" src="https://techblog.recochoku.jp/wp-content/uploads/2022/12/GitHub-Logo-200x200.png" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p><h2>はじめに</h2>最近、ソフトウェア開発界隈で話題になっている概念として「仕様駆動開発（SDD）」があります。これはその名の通り、コードを書き始める前に詳細な仕様書を作成し、その仕様書に沿って開発を進めていく手法です。ここ10年間はアジャイル開発のように動くコードを作りながら後で仕様をまとめる方法が主流でしたが、AIの普及に伴い、AIエージェントに意図したコードを書いてもらうためのガードレールとして再注目されています。今回はGitHub社が公開している仕様駆動開発支援ツールである「<a href="https://github.com/github/spec-kit?tab=readme-ov-file#-get-started">Spec Kit</a>」を利用し、Gemini CLIを使ったバイブコーディングにおいて、利用した場合と利用しない場合で成果物にどのような差が出るのかを検証していきたいと思います。<h2>作るもの</h2>今回、仕様駆動開発を試すにあたって作成するアプリケーションはTODOアプリです。TODOアプリは様々な形態がありますが、今回は以下のように定義します。<strong>TODOアプリの定義</strong><ul><li>カード形式でTODOが管理できる</li><li>TODOのCRUD操作ができる</li><li>TODOの優先度を入れ替えることができる</li></ul><h2>開発環境</h2><ul><li>macOS Sequoia(Version: 15.1.1)</li><li>Gemini CLI (Version: 0.5.5, 利用モデルはGemini 2.5 Flashのみ)</li><li>Spec Kit (Version: 0.0.52)</li><li>iTerm2 (Version: 3.6.1)</li></ul><h

<p><img width="200" height="200" src="https://techblog.recochoku.jp/wp-content/uploads/2025/10/Elemental-MediaConvert-200x200.png" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p>株式会社レコチョクでバックエンドエンジニアをしている早坂といいます。弊社のサービスである、<a href="https://dhits.docomo.ne.jp/">dヒッツ</a>や<a href="http://miruhaco.jp/rectv/">RecTV</a>などのバックエンドシステムを担当しています。<h1>本記事の要旨</h1>VBR・QVBR方式でエンコードした動画を以下の観点で比較し、効率性と品質がどのように異なるのかを検証します。<ul><li>効率性<ul><li>ファイルサイズ</li><li>エンコード時間</li></ul></li><li>品質<ul><li>ビットレートの推移</li><li>3指標による定量比較（各指標についての説明は後述します）<ul><li>VMAF（Video Multimethod Assessment Fusion）</li><li>PSNR（Peak Signal-to-Noise Ratio）</li><li>SSIM（Structural Similarity Index）</li></ul></li></ul></li></ul>AWSの動画変換サービスである<a href="https://aws.amazon.com/jp/mediaconvert/">AWS Elemental MediaConvert</a>（以降、MediaConvertと記載）によりQVBRとVBR方式のエンコードします。結論としては、VBR は効率的でコストを抑えやすい一方、複雑なシーンでは画質が不安定になる傾向がありました。また、QVBR は品質を一定水準に保ちやすいものの、エンコード時間やファイルサイズが増え、コストも高くなる点に注意が必要となります。本記事の趣旨は、結論そのものではなく、結果へ至るプロセスを示すこ

<p><img width="200" height="200" src="https://techblog.recochoku.jp/wp-content/uploads/2025/10/AdobeStock_476055400-200x200.jpeg" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p><h2>はじめに</h2>こんにちは。システム開発推進部第1Gの坂本です。突然ですが、みなさんは <strong>生成AIによる画像や音源コンテンツの無断学習</strong> 問題について関心を持っていますでしょうか。生成AI技術の進化に伴い、AIが既存のコンテンツを無断で学習することによる著作権侵害やプライバシーの問題が増えています。本記事では、生成AIによる無断学習の事例と、コンテンツを守るための対策についてまとめました。<h2>無断学習の事例</h2>生成AIによる無断学習はさまざまな分野で問題となっています。以下にいくつかの具体的な事例を紹介します。<h3>新聞記事の無断利用</h3>朝日新聞社と日経新聞社は、生成AI検索サービス「Perplexity（パープレキシティ）」が自社の記事を無断で利用しているとして提訴しました。自社コンテンツが無断で複製され利用者の回答に使用されているほか、回答の引用元として社名が表示されているにも関わらず誤った情報が含まれており、新聞社としての信用が著しく傷つけられているとしています。<a href="https://www3.nhk.or.jp/news/html/20250827/k10014904401000.html">生成AI検索サービスめぐり朝日新聞社 日経新聞社がPerplexity（パープレキシティ）を提訴 “記事無断利用” | NHK | 生成AI・人工知能</a><h3>声の無断利用</h3>声優などが加入する「日本俳優連合」「日本芸能マネージメント事業者協会」「日本声優事業社協議会」の3つの業界団体は、AIによる声の無断利用に対して共同で声明を発表しました。この声明はAIで声優の声を利用する際は本人の許諾を得ること、またAIによる音声であると明記することを求めるものになります。<a href="https:/

<p><img width="100" height="100" src="https://techblog.recochoku.jp/wp-content/uploads/2018/06/flutter-mark-square-100.png" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p><h1>はじめに</h1>NX開発推進部プロダクト開発第1Gの瀬川です。普段はAndroidアプリエンジニアとしてKotlinを使用した開発を行なっていますが、今年の5月末から新規プロジェクトのスマホアプリをFlutter で開発しています。 今回はそんなFlutterで新規アプリを開発する中で「追加読み込み機能」をFlutter/Dartで実装したためその知見を共有したいと思います。Flutter開発を行っているエンジニアの力に少しでもなれれば良いです。<h1>概要</h1>今回実装した「追加読み込み機能」は至ってシンプルで、リストで表示しているデータが表示分が最後の方になったタイミングで新しく追加のデータを取得＆追加して表示する機能となります。YouTubeの動画一覧画面で実装されている機能と同様のものになります。YouTubeの場合は次々と動画データが増えていきますが、今回は擬似的な再現として数字データを10ずつ追加していく形で実装を紹介します。<h1>準備</h1><h2>開発環境</h2>開発環境は以下になります。IDE：Android Studio Meerkat | 2024.3.1 Patch 1Flutter : 3.29.3Dart : 3.7.2<h2>使用技術</h2>主に使用した技術は下記3つです。<ul><li><strong>ScrollController</strong> <ul><li>ScrollControllerはユーザーのスクロール動作検知・スクロール位置取得などに使用します。ListView に登録すると、そのリスト内での現在のスクロール位置や残りスクロール距離を取得できスクロールイベントをフックできます。 </li></ul></li><li><strong>ListView（Flutter標準）</strong> <ul><li>スク

<p><img width="200" height="200" src="https://techblog.recochoku.jp/wp-content/uploads/2025/08/github_copilot-200x200.png" class="attachment-thumbnail size-thumbnail wp-post-image" alt="" /></p><h1>はじめに</h1>こんにちは、NX開発推進部プロダクト開発第1グループの本多啓路です。Androidエンジニアとして日々開発を行っております。最近、GitHub Copilotの自動コードレビュー機能を自分が関わっているプロジェクトに対して設定しました。今回はこの自動コードレビュー機能の設定方法について紹介します。<h2>GitHub Copilotとは</h2>GitHub Copilotは、GitHub社が提供するAIコーディングアシスタントです。<br />エディター上でコメントやコードを入力するとAIが続きのコードを推測し提案してくれるため、開発効率が大きく向上します。かく言う私もGitHub Copilotには、日々の開発でお世話になっています。<h2>GitHub Copilotの自動コードレビュー機能</h2>GitHub Copilotはコード補完だけでなく、Pull Requestのコードレビュー機能も存在します。PR作成時にAIがコードの変更点を分析し、レビューコメントを生成してくれるため、レビューの質や効率を向上させたい開発チームにとって、非常に便利な仕組みになっています。コードレビューを行ってもらう手順自体は簡単で、レビュワーにGitHub Copilotを指定するだけです。<img src="/wp-content/uploads/2025/08/copilot_reviewer.png" width="50%" style="border: solid 1px #888">こちらはリポジトリ内で設定をすることによって、レビュワーにGitHub Copilotを指定する手間を省くことが可能です。自分が行った設定方法を紹介します。<h3>コードレビュー機能を自動化する手順</h3><h4>1. リポジトリのSettingsへ移動します</h4><h4>2