はじめに CTO室 Dev Enable グループの羽馬（ X: @naohaba70 ）です。 昨年は私たちにとって、初めて「カンファレンス運営」に挑戦した年でした。 初めて協賛や運営に取り組む中で、成功の喜びや予想外の課題に直面し、多くの学びを得ることができました。この経験は、チームにとって 大きな成長の一歩 となり、今後の活動の土台を築くものになったと感じています。 この記事では、そんな 「カンファレンス運営1年目」 を振り返り、成功や課題、そしてこれからの展望についてお話しします。特にこの記事が参考になればと思うのは、次のような方々です： 社内で技術広報を行っている方 これからカンファレンス運営に挑戦してみたい方 カンファレンス運営のリアルな裏側をお届けします！少しでも皆さんの挑戦のヒントになれば嬉しいです。 スポンサー活動の背景や、カンファレンスブースの取り組みについては、以下の記事で詳しく解説しています。 tech.every.tv 昨年のカンファレンス協賛 昨年は、次のカンファレンスに協賛を行いました： Go Conference 2024 Kotlin Fest 2024 Vue Fes Japan 2024 ISUCON14 PHP Conference Japan 2024 それぞれのカンファレンスについての参加レポートは、以下のリンクからご覧いただけます： カンファレンススポンサーブログまとめ ISUCON 14 に ISUポンサーの枠で出場しました ISUCON 14感想戦 その中でも、特に印象に残ったのは「Go Conference 2024」と「Vue Fes Japan 2024」です。 印象に残った2つのカンファレンス Go Conference 2024：初めての協賛、いきなり最高位スポンサーに挑戦 Go Conference 2024は、私たちの会社にとって初めて協賛したカンファレンスでした。この協賛枠は 抽選制 で、実際に応募したときは「当選しなければ来年改めて挑戦しよう」と思っていたのですが、 運よく当選！ しかも最高位の「プラチナGoルドスポンサー」枠でした。 正直、初めての協賛で最高位スポンサーになるのは かなりの挑戦 でした。ブーススペースは広かったものの、「どうすれば来場者に楽しんでもらえるか」をゼロから考える必要がありました。試行錯誤しながら、次のような取り組みを行いました： デザイナーさんに依頼し、目を引くブースデザインを作成 広報や人事と連携して、発注や当日の運営をサポート エンジニア有志がブース運営を担当し、直接来場者と交流 さらに、新しい挑戦として アフターイベント も開催しました。このイベントでは、ブースに来ていただいた方々や他の参加者と技術について深いディスカッションが行われました。また、協賛企業同士の交流も深まり、今後につながる良い出会いが多くありました。 every.connpass.com every.connpass.com 結果的に、初めての協賛ながら多くの来場者と直接対話する機会を得て、ポジティブなフィードバックを多数いただきました。「挑戦してよかった」と心から感じた瞬間です。 Vue Fes Japan 2024：経験を活かした新たな挑戦 Vue Fes Japan 2024は、会社として3回目のカンファレンス協賛でした。これまでの経験を活かし、企画から運営までスムーズに進行することができました。 今回も新しい試みとして、 他の協賛企業との「プレイベント」や「アフターイベント」 を開催しました。特にアフターイベントでは、エンジニア同士が直接つながりを深める場を提供でき、多くの参加者から「こういう交流の場がもっと増えると嬉しい」といった声をいただきました。 optim.connpass.com studist.connpass.com さらに、これまで蓄積してきた知見を活かし、役割分担や運営の効率化が進み、チーム全体に余裕が生まれたのも大きな収穫です。初回の頃と比べてスムーズに準備を進めることができ、各担当が自信を持って運営に取り組めたことが印象的でした。 成功と課題を振り返って この1年間を振り返り、私たちは以下のことを実感しました： 社内の連携が成功の鍵 多くの部署やメンバーが関わることで、大きなプロジェクトも成功させることができました。 経験の蓄積が次の挑戦を支える 初回協賛で得た知見が、次の協賛をよりスムーズで効果的なものにしてくれました。 新しい挑戦が成長を生む アフターイベントやプレイベントといった試みが、コミュニティに大きな価値を提供する結果につながりました。 これからの展望 私たちは、今年以降も技術コミュニティへの貢献を続けていきます。カンファレンス協賛だけでなく、エンジニア同士が交流し、学び合える新しい取り組みにも積極的に挑戦していきたいと考えています。 この記事が、カンファレンス運営や技術広報に挑戦してみたい方々の参考になれば幸いです。これからも学びを重ね、挑戦を続けていきます！

この記事は every Tech Blog Advent Calendar 2024 の25日目、 締めくくりの投稿となります。 今年も無事完走できたことを大変嬉しく思います。 CTOの @imakei_ です。 本稿では、2024年における当社の技術的進化と組織的成長を振り返りつつ、2025年に向けた展望をお伝えしたいと思います。 昨年の 振り返り と併せてご覧いただくことで、この1年間の変遷をより立体的にご理解いただけるかと思います。 2024年の主要な取り組み 本年は特に以下の3つの施策を重点的に推進してまいりました。 DevEnableグループの創設と技術カンファレンスへの参画 「社内外から憧れられる開発組織の実現」 というビジョンのもと、 DevEnableグループを創設し、技術コミュニティへの積極的な貢献を開始しました。 2023年に試験的に発足した組織活性化委員会を、正式な社内組織として再構築し、DevEnableグループとして本格始動させました。 詳細は こちらの記事 をご参照ください。 既存の施策である挑戦WEEK、技術勉強会、TechBlogの取り組みを継続しつつ、 新たな試みとして技術カンファレンスへのスポンサーシップを展開しました。 当社として初めての試みであり、社内でもカンファレンス運営の経験者が限られる中、 GoConference、KotlinFest、VueFes、ISUCON、PHPConferenceという 主要な技術カンファレンス5件への協賛を実現できました。 これにより、長年お世話になってきた技術コミュニティへの恩返しの第一歩を踏み出せたと考えています。 そのほか、 新卒研修の実施 、 内定者向けの研修(勉強会) の実施 などより社内の開発組織を活性化する施策も続々と実施しており、 立ち上げて1年経っていない中ですでに弊社のエンジニア組織の文化を形成する良い組織となっています。 生成AIを活用したサービスのリリース プロダクト面では、弊社として生成AI元年とも言える年となりました。 デリッシュAIのリリース はもちろん、社内向けにも生成AIを活用したサービスをリリースしたり、 PoCやツールの活用程度にとどまっていた生成AIを活用し、プロダクトまで昇華させることができたのは大きな成果でした。 また、来年以降のロードマップでもすでに生成AIを活用したサービスの開発が控えており、 これからさらに開発を加速していきたいです。 弊社の生成AI活用の変遷としては、昨年3月にChatGPTにてGPT-4が有償でリリースされた直後に、エンジニア全員にその利用の補助を出すことを決めたところから、GithubCopilotの導入や、AWS様とのBedrock勉強会、挑戦WEEKでの活用など地道に社内に浸透させてきました。 なかなか大々的に発表できるまで行かないことに自分としてはもどかしさを感じる部分も多く、 他社のCTOの方々にいろいろ相談させてもらった部分もありましたが、 こうしてリリースまで持っていけたのはチームとして生成AIという未来に向き合ったからだと思います。 リテールハブ開発部の発足とデリッシュキッチン開発部長の交代 ブログ でも書いた通り、10/1でリテールハブ開発部を新設し、そこの開発部長を私が務めることになりました。 リテールハブ開発部は、これまでデリッシュキッチン開発部で手掛けてきた小売向けのサービス開発に注力をする新しい部門となります。 一方これまで務めてきたデリッシュキッチン開発部長には、2019年新卒の村上に引き継ぐことができました。 組織としてより一層強くなれたこと、また何より新卒が成長し要職になっていただけたことは、 挑戦 や 成長 を掲げる開発組織としてとても嬉しく思います。 RetailHub、デリッシュキッチン共に、さらに成長を加速していきたいです。 2025年に向けて 2024年は、DevEnable・生成AI・新組織など新しい一歩を踏み出した1年でした。 2025年は、それらをさらに加速すると共に、成果にこだわる1年にしたいと思います。 特に生成AIについては、今後のデファクトを自分たちから作り出していく心づもりで、 全事業部でのプロダクト導入を目指していきます。 最後に、昨年のブログで今年のテーマとしていた「採用」についても、まだまだ全然足りていません！ ちょっとでも面白そうと思ってくれた方は、 ぜひ下記からご応募いただくか、X(旧Twitter)でも気軽に声かけてください！ 美味しいご飯でも食べながら弊社のプロダクトや開発組織を語りましょう！ Tweets by imakei_

サンタさんへ、MySQL5.7から8.4にアップグレードしてください この記事は every Tech Blog Advent Calendar 2024 の 24 日目の記事です。 背景 　こんにちは、開発本部 RetailHUB開発部 NetSuperグループに所属するフルスタックエンジニアをやらせていただいています、ホーク🦅アイ👁️です。 リテールハブ事業部 　私の所属しているリテールハブ事業部の話をもう少し詳細にしてみようと思います。 　ネットスーパーシステムは事業継承したので弊社が作ったものではなく、10年以上も前に作られたものがベースになっています。CentOSサーバ内にPHP5.3とMySQL5.6,5.7のLAMP環境で構成されており、クラウドもAWSではなくFJcloud-V(旧ニフクラ)を使っているという一癖も二癖もあるインフラ環境で保守運用がしづらい状況にあります。本チームではようやく、PHPからGoへのリプレイス計画を発進させたばかりです。 　一方でGraphQL＋Pythonで動くものやREST＋Goで動くもの、REST＋Laravelで動くものもありインフラ環境としてはそれらは全てAWSで構築されているのでモダンな部分もあります。そういった複数言語・インフラ環境をエンジニア全員でメンテナンスしていくスタイルを取っているので自ずとフルスタックスキルを発揮することになリます。アプリはクロスプラットフォーム対応したFlutterアプリで開発制作しているのですがここだけは現在専属エンジニアに頼っておりC/S面でのフルスタックは発揮できていないのですが、来年から専属ではなくなるので今からチーム内でFlutter勉強会を開催してスキル習得を目指しています。 　また、プロダクト向き合いが身近で声が通りやすいので企画段階から関わることもでき技術選定もできる用意があるので既存の開発環境に固執せず最適なアーキテクチャや新技術・ツールを使う チャンス があります。 　私というと普段の業務は本当に幅広く、既存システムの追加開発に始まり小売様からの問い合わせ対応、障害調査＆火消し作業、アラート監視、ビジネスサイドの方々とのプロダクト改善・利益増のための施策・企画会議への参加などあります。レガシーかつ機能豊富な巨大システムであるため障害も起きてしまうことがあります。地味にトラブルの迅速対応(調査・解決など)推進力というのは経験豊富なエンジニアでないと発揮しづらい能力なのかなとは思うのでこのあたりの漠然としたスキルをうまく布教できると良いなと最近は思っています。 　最近のトピックとしては、2025年4月より導入の義務化となっている3Dセキュア2.0認証にいち早く対応させました。2025年1月以降順次導入小売様よりスタート予定です。 　さて、実際にリプレイスを行うにあたりいずれ必要になるであろう作業としてMySQLのアップグレードがあります。これは単純に2024年12月現在、AWSではMySQL5.7系のRDS、AuroraがEOLを迎えているからです。なのでまずは今のインフラ構成のままでMySQL8系にアップグレードしてみたらどうなるのか、案外簡単にできるのか？！を試してみたので以降で話させていただきます。 MySQL8.4について 公式MySQLが8.4をLTSに指定 AWS Aurora次期メジャーバージョン互換対象の可能性が高いのではないか 　こういった点から、現在AWSがサポート中のMySQL8.0系ではなくいきなり8.4にあげてみることにしました。 MySQL5.7利用中のシステムに導入してみる 　前提としていきなり本番環境に適用はできないので開発用に手元でDockerコンテナを利用したローカル開発環境があるのでそれを使ってアップグレード作業を行います。また、MySQL8.4サーバ設定ファイルは一旦デフォルトのままにします。 DBバックアップとリストア 　まず、MySQL5.7側のデータを全てダンプします *1 。 # on MySQL 5.7 $ mysqldump --single-transaction --skip-lock-tables -p -h127.0.0.1 -P33306 -uappuser -B app_test > app_test_dump20241224.sql 　次に、MySQL8.4側に先ほどのデータを全てリストアします。 # on MySQL 8.4 $ mysql -p -h127.0.0.1 -P33308 -uappuser < app_test_dump20241224.sql 問題1 　ここで、MySQL8.4にリストアすると以下のようなエラーメッセージが出てしまいました。 ERROR 1118 (42000) at line 1224: Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline. 　ここで 解決策 を色々調べてみると先ず、MySQL8.0からinnodb_file_formatが廃止され内部的にBarracuda固定になったようなのでその設定変更は不要でしたのでこれは原因ではなかったようです。次に、ダンプファイルの中身を実際に見てみるとROW_FORMAT=COMPACTになっているCREATE文が32個あったのでROW_FORMAT=COMPRESSEDに全置換しました。そして再度リストアコマンド実行したところ今度はエラーが出ずに成功しました！ 参考） 問題2 　システムとデータが入ったMySQL8.4を接続してシステムが動作するかいざ試そうとすると、今度は以下のエラーが出て接続失敗となりました。 Client does not support authentication protocol requested by server; consider upgrading MySQL client 　どうやら、MySQL8.0からデフォルトになった認証プラグインcaching_sha2_passwordに対応できてないエラーでした。この認証プラグインは結構大きな落とし穴でMySQL8.4では設定ファイルで有効化すれば使うことができました。また、MySQL9.0以上になると完全にmysql_native_passwordプラグインが廃止となって使えなくなります。 　そこで、 解決策 としてデフォルト設定だったmy.cnfに以下を追加して再起動しました。 [mysqld] mysql_native_password=on authentication_policy=mysql_native_password,, 　再起動後に以下のSQLクエリで確認するとACTIVEに変わっており有効化に成功したのでさらに、pluginカラム値を変更します。この時、パスワード変更もしなければならないので注意です。BY以下を省略してしまうと空文字列のパスワードになってしまいます。また、 FLUSH PRIVILEGES を実行しないとプラグイン変更が反映されないのでこれも注意です、このせいで私もさらに詰まっていました。 mysql> SHOW PLUGINS; 'mysql_native_password','ACTIVE','AUTHENTICATION',NULL,'GPL' mysql> SELECT user, host, plugin FROM mysql.user WHERE user='appuser'; +---------+------+-----------------------+ | user | host | plugin | +---------+------+-----------------------+ | appuser | % | caching_sha2_password | +---------+------+-----------------------+ 1 row in set (0.00 sec) mysql> ALTER USER 'sha2user'@'%' identified WITH mysql_native_password BY '[新しいパスワード]'; +---------+------+-----------------------+ | user | host | plugin | +---------+------+-----------------------+ | appuser | % | mysql_native_password | +---------+------+-----------------------+ 1 row in set (0.00 sec) mysql> FLUSH PRIVILEGES; 問題3 　ここまででようやく接続までができたので今度こそクエリ発行をしてみようとネットスーパーユーザ向けTOPページにアクセスしてみたら今後は以下のエラーが出てページ表示ができませんでした。 General error: 1525 Incorrect DATETIME value: '0000-00-00 00:00:00' 　調べていくとSQLモードのデフォルト設定を変更しなければならないことがわかりました。 The default SQL mode in MySQL 8.4 includes these modes: ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, and NO_ENGINE_SUBSTITUTION. 参考） 　上の引用文から8.4ではsql_modeのデフォルト値は6つあり厳密モードが有効化されていたので起きたエラーでした。したがって、 解決策 として権限が一番緩い設定にしました *2 。 参考） 参考） 　解決策としてmy.cnfに以下の設定を追加して再起動するとエラーが出なくなりました。 [mysqld] sql_mode=NO_ENGINE_SUBSTITUTION 問題4 　今度こそTOPページを表示させる！という意気込みでページのリロードを試みましたが、残念またもエラーが出てしまいました。 Error Code: 1525. Incorrect DATE value: '--15' 　 --15 は、PHP側のバグでした。以下のコード例のように日付を年、月、日という変数から生成している箇所があり、そこで年と月の変数値が空文字列になっていたのでこのような文字列が生成されてその後date変数値が日付前提で後続処理していたのでそこでコケていたのでした。 $date = sprintf(“%s-%s-%s”, $year, $month, $day); 　具体的には、MySQL側にSELECT文発行する際のWHERE条件句右辺にこのdate変数をそのまま渡しておりそこでコケると出るエラーでした。MySQL8.0.16以降はDATE型の比較演算対象の型チェックが厳密になったらしいです。一方でそれ以前のバージョンだったMySQL5.7の既存システムではこのバグ状態の変な文字列を右辺に渡していても正常クエリのレスポンスが返ってきていた *3 と思うとゾッとしますね...後は、PHPのバグを修正して正しいクエリを発行させたら解決です。 参考） 　これでようやくTOPページが表示されました！ 総括 　本記事では、AWSリプレイス前段階としてMySQLサーバのバージョン5.7からバージョン8.4への挑戦について話しました。弊社提供のネットスーパーシステムは多くの機能を持つのですが、現状ではTOPページを表示させることができたに過ぎず今回のようないくつかの問題はまだまだ氷山の一角に過ぎないと予測しておりこれから長い検証を行っていかなければならないと思っています。例えば、 SQL_CALC_FOUND_ROWS というクエリ発行が散在しているのでこれらを全て COUNT() 関数に置換していくというコードリファクタリングが見えていたりします *4 。なお、代替案の COUNT() 関数で処理速度が遅くなるバグが報告されており、バージョン8.0.37以降で改善されたそうです。 参考） 　今後は、2024年11月21日に正式版がリリースされたAmazon RDS for MySQL8.4で動作検証できた時のお話ができればと思いつつ、これにて本記事の結びとさせていただきます。 最後に エブリーでは、ともに働く仲間を募集しています。 テックブログを読んで少しでもエブリーに興味を持っていただけた方は、ぜひ一度カジュアル面談にお越しください！ corp.every.tv Merry X'mas！🎄 六本木一丁目駅降りて直ぐの六本木グランドタワー駅前広場のイルミネーションツリー *1 : コードブロックにあるコマンド類は本記事用に適当な名称やポート番号などに書き換えています *2 : この点、後で気付いたのですがMySQL5.7でもデフォルトだと厳密モード有効なのでシステム利用の設定ファイルには既に無効化設定が入っていました。よって、8.4だから起きるエラーではないです *3 : もちろん無条件として解釈されます *4 : MySQL8.0.17以降非推奨となっていますが、8.4.3現在でも発行自体は可能でした

はじめに この記事は every Tech Blog Advent Calendar 2024 の 23 日目の記事です。 こんにちは、開発本部のデータ＆AIチームの24新卒の蜜澤です。 4月に入社して以降Amazon QuickSight(以下quicksight)を社内で最も利用したので、quicksightで開発をしてきた中で身につけたTipsを紹介します！ 本記事の内容はquicksightの細かな機能について触れるので、quicksightを使い慣れている方に向けた内容となっております。 使用する模擬データ レシピ動画サービスのレシピ毎のインプレッション数とクリック数の模擬データを使用します。 模擬データなので簡略化のために4~6月の各月の1~7日のデータのみになっております。 date：日付（2024/04/01~2024/04/07,2024/05/01~2024/05/07,2024/06/01~2024/06/07） recipe：レシピ名（ハンバーグ・からあげ・生姜焼き） click：ある画面でレシピ動画のサムネイルがクリックされた回数 impression：レシピ動画が表示された回数 ※dateに関してはquicksightにデータを入れる際にデフォルトで「Apr 1, 2024 12:00am」という形式になってしまうので、表示形式を「YYYY/MM/DD」に変更しています。 さらにこのデータを月毎に集計した以下のデータも使用します。 date：日付（2024/04~2024/06） recipe：レシピ名（ハンバーグ・からあげ・生姜焼き） click：ある画面でレシピ動画のサムネイルがクリックされた回数 impression：レシピ動画が表示された回数 YYYY/MM形式の日付データを絞り込む際のハマりどころとその対処法 まず、日付を絞り込むために開始日と終了日を指定するStartDateとEndDateというパラメータを作成し、dateカラムに対してStartDateとEndDateの間というフィルターを追加します。 さらに、StartDateは開始日、EndDateは終了日という名前でコントロールを作成しておきます。 パラメータやフィルターに関しての説明は本記事の範疇ではないため説明を省きます。 私が以前執筆した こちらのブログ で解説しているので、パラメータやフィルターに関して詳しく知りたい方はご覧ください。 以下のようにコントロールで指定した範囲の日付のデータのみが表示されます。 日付の集計粒度が「日」の場合はこのやり方で問題ないのですが、集計粒度が「月」になると想定外の挙動になる可能性があります。 月毎集計したデータの開始日を2024/04/01、終了日を2024/05/31にすると、以下のように4月と5月のデータが表示されて問題ありません。 次に開始日を2024/04/02に変更すると、5月のデータのみしか表示されません。 なぜこのようなことが起こるのかというと、冒頭の模擬データの説明でも少し触れましたが、quicksightでは日付データ(Date型のデータ)は「Apr 1, 2024 12:00am」という形式になってしまいます。 2024/04という月のデータであっても「Apr 1, 2024 12:00am」という形式になって、2024年4月1日という判定になってしまいます。 表示形式はYYYY/MMのように変更ができますが、データ自体は「Apr 1, 2024 12:00am」の形式のままです。 そのため、フィルターの期間に1日が入っていない場合はその月のデータが表示されないという現象が起きてしまいます。 対策法はいくつかあります。 簡単なものだと、 そもそも期間を指定するときに1日は必ず入れるようにする dateをDate型ではなくString型にする などがあります。 しかし、1日を必ず入れないといけないというの周知させるのが大変、String型にするとコントロールで日付選択ツールを使用できなくなってしまいコントロールに日付を入力しないといけなくなるといった問題が生じます。 ということで、これらの問題を解決しながら、各月の日付が入っていたら1日が入っていなくても、その月のデータを表示できるようなフィルターを作成する方法を紹介します。 まずは以下のような「日付フィルター」という名前の計算フィールドを追加します。 やっていることとしては、 extract を使用して日付からYYYYとMMを抽出しYYYYMMという文字列を作成して、StartDateとEndDateの間にmonthがある場合のみ1を返すようにしています(それ以外の場合は0が返ってきます)。 YYYYに100をかけている理由は、1をかけない場合だと2024/01が20241になってしまい、2023/12~2024/01のような範囲を指定した場合に、202312よりも20241の方が小さくなってしまい、正しく範囲を指定できなくなってしまうのを防ぐためです。 次に、日付フィルターに対して以下のようなフィルターを設定します。 1と等しいというフィルターを設定することで、日付フィルター計算フィールドの条件を満たすデータのみが表示されるようになります。 これらの設定をすることで、開始日を2024年4月2日にしても4月のデータが表示されるようになります。 2.グラフタイトルに相対日付の◯月を入れる方法 先ほどのデータを使用して、日付をコントロールで変更するのではなく、相対日付を設定して先月や3ヶ月前などの各レシピのデータを閲覧できるビジュアルがあると想定し、そのタイトルに「◯月のデータ」のようなタイトルをつける方法を紹介します。 「先月のデータ」や「3ヶ月前のデータ」のようなタイトルにするならば、プロパティからタイトルの編集をしてタイトルを変更すれば良いですが、相対的に変わる「◯月」をタイトルに入れることはできません(毎月手動で変更するならできるがやりたくはないはず)。 そこで、かなり周りくどい方法になってしまいますが、Highcharts Visualを利用して「◯月」を擬似的なタイトルに入れる方法を紹介します。 まずは以下のような「月」と「タイトル」という2つの計算フィールドを追加します。 toString でDate型のmonthをString型にして、 substring で日付のMMの部分を抽出します。 if文でMMが10,11,12の場合は２文字抽出して、01,02のような場合には１文字のみ抽出して0を除外するようにしています。 concat を利用して、divタグと月計算フィールドと「月のデータ」という文字列を結合しています。 次に、Highcharts Visualを追加し、グループ化の条件に、先ほど作成した「タイトル」を選択します。 そして、Chart codeに以下のコードを書いて、「APPRY CODE」をクリックします。 { " title ": { " useHTML ": true , " text ": [ " get ", [ " getColumn ", 0 ] , 0 ] , " style ": { " fontSize ": " 18px ", " fontWeight ": " bold ", " color ": " #000000 " } } } そうすると、以下のようなテキストのビジュアルが作成されます。 このままでは幅が大きすぎてタイトル感がなくなってしまうので、最後にスタイルを調整します。 編集→分析設定→Sheets Settingsと進み、「フリーフォーム」を選択し、「適用」を押します。 フリーフォームにすることで、ビジュアルを重ねたり、好きな幅に調整したりとスタイルの微調整ができるようになります。 調整をするとこんな感じになります！ なんとかタイトルと呼べる見た目になると思います！ 3.データポインタホバー時に出現するカードのカラム名を変更する方法 模擬データを使用して、レシピごとのクリック数を比較する折れ線グラフを作ると以下のようになります。 軸名と凡例は元のカラム名を参照するため、カラム名と同じ英語表記になっています。 これを好きな表記にするには、プロパティから対応する項目を変更します。 例えばX軸の場合は、プロパティのX軸のタイトルを編集すればX軸を好きな名前に変更できます。 Y軸や凡例もプロパティからタイトルを変更すればOKです！ ただし、ここで名称を変更してもデータポインタにカーソルを合わせたときに表示される以下の赤枠の部分の名前は変更することができません。 （凡例は「レシピ名」、Y軸は「クリック数」になっていますが、recipe、clickのままになっている。 ） データのカラム名を変更すれば良いのですが、簡単に変更できない場合もあると思います。 そんなときに、カラム名を変更せずに表示名を変更する方法を紹介します。 まず、計算フィールドに名前を変更したいフィールドを記入し、計算フィールドのタイトルに変更後の名前を記入します。 その後、グラフで指定するフィールドを今作成したものに置き換えます。 これだけで以下のように名前を変更することができます。 4.ビジュアルの枠線削除 ビジュアルをクリックすると以下のような枠線が表示されます。 これはダッシュボードを公開してもビジュアルをクリックすると枠線が表示されます。 ビジュアルをクリックしてもこの枠線が表示されないようにする方法を紹介します。 まずは、先ほども登場した「フリーフォーム」に変更します。 変更すると、プロパティのディスプレイ設定に「選択」という項目が出現するので、「選択」の目のアイコンを押して斜線がついた状態にすれば、ビジュアルをクリックしても枠線が表示されなくなります。 枠線削除後は以下のようになります。 分析ではクリック時に白い四角が表示されますが、ダッシュボード上では見えなくなります。 さいごに 本記事ではquicksightのかなり細かなTipsを紹介させていただきました。 使用頻度はかなり低いと思いますが、いつか誰かの役に立てれば嬉しいです！ 最後まで読んでいただきありがとうございました！

title エブリーは2024年12月22日（日）に大田区産業プラザPiOで開催されたPHPカンファレンス2024に参加させていただきました。 今回は参加レポートとして、会場の様子やセッションの感想についてお届けします！ エントランス スポンサー セッションホール スポンサーブース イベント概要 PHPカンファレンスは、PHP関連の技術を主とした日本最大級の技術者カンファレンスです。2000年に日本のユーザ会によって初めて開催され、今年で25回目という記念すべき開催となりました。 イベントには約1,000名以上の参加者が集まり、エンジニア同士の交流や最新技術の発表で熱気に包まれていました。会場は技術愛好家の熱量と笑顔にあふれ、PHPの魅力を共有する空間となっていました。 今回のイベントは、これからPHPをはじめる方から、さらにPHPを極めていきたい方まで、幅広い層のエンジニアが楽しめる内容となっており、まさに「PHPの今と未来」を体感する1日でした。 phpcon.php.gr.jp セッションの感想 PHPの今とこれから2024 今年のPHPカンファレンスで特に印象に残ったのは、PHP 8.4に関するセッションでした。2024年は、日本のエンジニアコミュニティがPHPのコア開発に大きく貢献した年であり、その裏話も興味深く聞けました。 今回発表された新機能の中で特に注目したいのは以下の3つです： JITの大幅な進化 ：IRフレームワークが導入され、実行速度が18.5%向上。PHP 8.0から始まったJITがさらに強化され、パフォーマンス改善が期待されています。 プロパティアクセスフック ：オブジェクトのプロパティアクセスを柔軟に制御できる新機能。実際のコード管理が大きく改善されそうです。 遅延オブジェクト ：オブジェクトを必要になるまで初期化しない仕組みで、メモリ効率を向上。特に大規模プロジェクトでの恩恵が大きい機能です。 その他、まだまだ新機能があり、PHP 8.4のリリース内容を読み込まないといけないと感じました。 www.php.net そーだいさんに聞く！コミュニティとともに在るエンジニアの良いキャリアの歩み方 キャリア形成に関するセッションも大きな学びがありました。そーだいさんの講演では、特に「今日から始められること」の重要性が強調されており、キャリアを前進させるための具体的なアクションが提案されていました。 今日からできること コミュニティ活動への参加 ：勉強会での発表、懇親会での交流を通じて、自分の存在を周りに知ってもらう。 ライフステージに合わせたキャリア設計 ：「カレイドスコープ（万華鏡）キャリア」の考え方を紹介。キャリアは一直線でなく、多様な経験を活かすことが大切だと話されました。 アウトプットの実践 ：ブログ執筆やOSSへの貢献が、自分自身の「名刺」になるとのこと。 技術だけでなく、人的な繋がりを築くことの重要性を改めて感じたセッションでした。 fortee.jp スポンサーブース紹介 エブリーでは、 DELISH KITCHEN などのサービスに加え、小売業者向けのデータ連携サービス retail HUB の開発・運用にPHPを活用しています。 retail HUBは、小売業のDXを推進するサービスです。詳細は こちら をご覧ください！ PHPを活用する中で多くの恩恵を受けている私たちも、コミュニティのさらなる盛り上がりに貢献するため、スポンサーとして協賛させていただき、ブースを出展しました。 「なぜエブリーが協賛しているのか？」については、こちらのブログもご覧ください！ → PHPカンファレンス2024協賛の理由 ブース エブリーでは、今回も弊社が提供するDELISH KITCHENのサービスをイメージしたブースの雰囲気を作りました。多くの方からDELISH KITCHENをを使っていますとの声をかけていただき、とても嬉しかったです。 ブース ノベルティ 今回もDELISH KITCHENにちなんだノベルティを用意させていただきました。 ステッカー DELISH KITCHENグッズ CTOブレンドのコーヒーバッグ ノベルティ DELISH KITCHENグッズに関してはXフォローでの抽選プレゼントキャンペーンを行いました。DELISH KITCHENグッズに関してはたくさんの商品があるのですが、その中でも人気のある商品を中心に5つ準備させていただきました。参加者の方々にも好評で多くの方に参加していただけました！ アンケート 今回、アンケートでは『PHPの好きなところ』と題して回答をしてもらいました。付箋に内容を記述して貼っていただく形式を取ることで様々な意見をいただくことができ、コミュニケーションのきっかけとなり会話が活発になりました。回答いただいた多くの皆様、ありがとうございました！ アンケートボード アンケート結果 各社スポンサーブースの様子 スポンサーブースでは、各社趣向を凝らしたブースが展開されました。 クイズやアンケートボード、コードレビューなど様々な企画が用意されていて、会場全体が賑わっていました。 また、スポンサーブースでは、各社のエンジニアと直接話すことができる機会もあり、普段なかなか話すことができないような話もできてとても楽しかったです。 転職DRAFTさんのブースでは「あなたが会社を選ぶ時の軸を教えてください」と題して特色別の仮想3社からどの会社を選ぶかというアンケート企画を行なっていました。参加者からの様々な観点が書かれており、その中でも一緒に働く人を大事に考えられている方が多いように見受けられとても興味深かったです。 PR TIMESさんのブースでは PHP8.4 にちなんで ストップウォッチを8.4秒で止めると景品がもらえるという企画を行っていました。PHPの最新バージョンに絡めたとても面白い企画だと思いました。 スタンプラリー企画 各ブースを巡るスタンプラリー企画も実施され、多くの参加者が積極的に各ブースを訪れていました。 スタンプラリー まとめ PHPカンファレンス2024 運営の皆様、参加者の皆様、本当にありがとうございました！ PHPカンファレンス2024は、25年の歴史を感じさせる充実した内容のイベントでした。最新技術や実践的なセッションだけでなく、エンジニア同士の交流やコミュニティの大切さも改めて実感できました。 今回学んだことを基に、まずはPHP 8.4の新機能を活用したプロジェクトを始める予定です。また、PHPコミュニティのイベントや勉強会に積極的に参加して、さらに知識を深めていきたいと思います。 次回のカンファレンスにもぜひ参加し、引き続きPHPの進化を追いかけたいと感じました！

この記事は every Tech Blog Advent Calendar 2024 の 22 日目の記事です。 データ&AIチームでデータエンジニアを担当している塚田です。 弊社のデータ基盤はDatabricksをベースにデータストアとしてAmazon S3を利用しています。 今回、データストアとして利用しているAWSアカウントとは異なるAWSアカウント上でデータ利用する必要があり、比較検討しましたのでその内容をご紹介します。 クロスアカウントにおけるS3で保持しているデータの利用方法 S3にはデータの参照やコピー方法が多数あり、全てを網羅するとそれだけで長くなってしまうので、今回は以下のシチュエーションで利用する前提でいくつか方法を考えてみます。 データを保持しているアカウントとは別のAWSアカウント上のAthenaによるクエリ実行でデータを取得させる どちらのアカウントの話をしているのかわかりにくくなるため 基盤側アカウント と 利用側アカウント で表記します。 データは基盤側アカウントに保持しアクセスする場合 基盤側アカウントのS3バケットのバケットポリシーに利用側アカウントからのアクセスを許可する設定を行う 基盤側アカウントにS3 アクセスポイントを作成し、そのバケットポリシーに利用側アカウントからのアクセスを許可する設定を行う 利用側アカウントにS3 アクセスポイントを作成する データを基盤側アカウントから利用側アカウントにコピーしてアクセスする場合 AWS DataSyncを利用しアカウント間でデータ連携を行う S3 クロスリージョンレプリケーション(CRR)を利用しアカウント間でデータ連携を行う S3 バッチオペレーションを利用しアカウント間でデータ連携を行う 比較・検討 前項で複数の方法を挙げてみましたので、それぞれについて比較・検討していきます。 具体的な設定方法の記載はしておりませんので、実際に利用する場合には公式ドキュメントなどを参照し実施するようにしてください。 データは基盤側アカウントに保持しアクセスする場合 基盤側アカウントのS3バケットのバケットポリシーに利用側アカウントからのアクセスを許可する設定を行う 個人的にですが、一番メジャーでかつ設定が容易な方法だと思います。 データを保持している基盤側アカウントがアクセス制御を行うため管理体制として正常に機能する状態が実現できます。 基盤側アカウントにS3 アクセスポイントを作成し、そのバケットポリシーに利用側アカウントからのアクセスを許可する設定を行う ほぼ、S3バケットのバケットポリシーを利用したアクセス許可と同じ内容で余計なアクセスポイントを作成することによって管理するリソースが増えているように感じるかもしれません。 ただ今回は利用先が1アカウントの前提で記載していますが、データ基盤で利用しているS3は他のAWSアカウントでも利用するシチュエーションは十分に考えられます。 都度S3バケットのバケットポリシーを変更するのはミスをする可能性もあり他のアクセス制限に影響が発生する場合も考えられます。 その点でS3 アクセスポイントを利用することによりアクセスポイント側でアクセス制御が行えるため上記のようなリスクを回避することができます。 利用側アカウントにS3 アクセスポイントを作成する こちらもS3 アクセスポイントを利用しますが、作成するアカウントが利用側アカウントになっています。 この案の特徴としては利用側アカウントにアクセスしポイントのリソースが作成されているため、どのバケットに対してのアクセスが行える設定がされているのかを知ることができるところにあると思っています。 アクセス制御自体は基盤側アカウントで行いますのでアクセス管理が煩雑になるというリスクは発生します。 データを基盤側アカウントから利用側アカウントにコピーしてアクセスする場合 今回の利用方法であればデータをコピーするメリットがなく以下のデメリットがあるため、検討はしましたが、データのコピーを行う方式自体合わないと判断しました。 データが複数箇所で管理されるためデータ基盤側が想定していない利用をされる場合がある 利用側アカウントから他の環境にデータ連携を行うなど データ容量が多いためストレージコストが倍になってしまう 差分更新ができたとしても保持するデータの総量は増える データ更新には多少なりとも時間がかかりデータ基盤側の処理完了とデータ更新のタイミングを考慮する必要がある 利用するサービスによっては利用するための設定が煩雑になる場合があり、データを利用したいというシンプルな要件に対して対応コストがかかる 最終判断 今回は 利用側アカウントにS3 アクセスポイントを作成する を選択しました。 判断理由 データ基盤側のデータは利用するがAthenaを介した方法のためその参照データがどこにあるか重要ではありません。 ただし、AWS Glue crawlerを利用したスキーマの自動生成を行いたいためS3のどこに該当のファイルを配置しているかを把握した上で利用するニーズがありました。 (アクセスポイントを利用するとマネジメントコンソールでデータの構成を参照することができる) 上記のような理由により、利用側アカウントにS3 アクセスポイントを作成し参照管理する方式としました。 おわりに Amazon S3はオブジェクトストレージとして様々なシチュエーションで利用することができるサービスだと思います。 その結果として多数の機能、連携できるサービスも多岐にわたっているため利用時に何を採用するべきかは悩むポイントでもあります。 今回ご紹介した方式や判断については全てに通用するものではありませんが、利用用途に沿った調査と判断をした例として参考になれば幸いです。

この記事は every Tech Blog Advent Calendar 2024 の21日目の記事です。 はじめに こんにちは、リテールハブ開発部のネットスーパーチームでFlutterエンジニアをしている野口です。 今回は弊社で運用しているFlutterアプリのログの出し方を整理した際の話をします。 なぜログを整理するか 弊社で運用しているアプリの中で事業譲渡で引き継いだアプリがあります。 そのアプリは以下のように３つのパターンでログを出しており、統一されていませんでした。 print logger ( https://pub.dev/packages/logger ) developer.log (DevToolを使う方法： https://docs.flutter.dev/testing/code-debugging) 統一されていないため以下のような問題があり、整理することにしました。 ログがどこで出てるのか把握しづらい 開発者によって書き方が異なってしまう エラーなどの問い合わせの際に、状況が把握できない ログ整理の方針 ログを整理するにあたり、以下の理由で logger に統一することにしました。 デフォルトでログレベルのサポートがある logger はデフォルトで以下のログレベルを提供しており、これを利用することでログの重要度に応じたログの出しわけができます。 ログレベルの種類 trace debug info warning error wtf(What a Terrible Failure) また、デフォルトでログレベルに合わせて色が変わるため視認性が良くなります。 実際にログを整理する 1. 不要なログ出力コードを整理 まず初めに、既存のログ出力をしている箇所で不要なログを削除しました。 print や developer.log の使用箇所はログ出力する意味がないものだったので削除しました。 logger は例外処理のログ出力で使用していたので、後述のログ出力方法に置き換えるようにします。 2. ログの出力処理を一元化 次に、 AppLog クラスを作成し、ログの出力処理を一元化しました。 これにより、統一された方法でログを出力できるようになり、誤った使い方を防ぐことができるようになります。 class AppLog { static final Logger _logger = Logger(); static void debug({ String message, StackTrace stackTrace}) { _log(message: message, level: Level.debug, stackTrace: stackTrace); } static void info({ String message, StackTrace stackTrace}) { _log(message: message, level: Level.info, stackTrace: stackTrace); } static void error({ String message, Exception exception, StackTrace stackTrace}) { _log(message: message, level: Level.error, exception: exception, stackTrace: stackTrace); } static void _log({ String message, Level level, Exception exception, StackTrace stackTrace}) { if (!kReleaseMode){ _logger.log(level, message, exception, stackTrace); } if (level.index >= Level.info.index && message != null ) { FirebaseCrashlytics.instance.log(message); } if (level.index >= Level.error.index && exception != null ) { FirebaseCrashlytics.instance.recordFlutterError(FlutterErrorDetails(exception: exception, stack: stackTrace)); } } } ログレベルはdebug、info、errorの３種類に分けており、 _log 関数の中でログレベルに応じて処理を分けています。 また、 !kReleaseMode ではリリースビルドでログを表示しないようにしており、本番環境では表示されないため、安心して使用できます。 debugログ debugログは、主に開発時に変数の値やアプリの状態を確認したい場合に使用します。 if (!kReleaseMode){ _logger.log(level, message, exception, stackTrace); } debugログの使用例： void fetchData() { final data = { "key" : "value" }; AppLog.debug(message: "fetchData() called with data: $data" ); } infoログ infoログは、アプリの動作状況やユーザーの操作イベントを記録したい場合に使用します。 また、Firebase Crashlyticsに情報を送信することで、本番環境での挙動を把握するのにも役立ちます。 if (!kReleaseMode){ _logger.log(level, message, exception, stackTrace); } if (level.index >= Level.info.index && message != null ) { FirebaseCrashlytics.instance.log(message); } infoログの使用例： void userLogin( String username) { AppLog.info(message: "User logged in with username: $username" ); } errorログ errorログは、例外が発生した場合や補足したいエラーを記録する際に使用します。 また、Firebase Crashlyticsに例外情報を送信することで、問題を迅速にトラッキングできます。 if (!kReleaseMode){ _logger.log(level, message, exception, stackTrace); } if (level.index >= Level.error.index && exception != null ) { FirebaseCrashlytics.instance.recordFlutterError(FlutterErrorDetails(exception: exception, stack: stackTrace)); } errorログの使用例： void processPayment() { try { // エラーが発生する可能性のある処理 throw Exception( "Payment processing failed" ); } catch (e, stackTrace) { AppLog.error( message: "Payment error occurred" , exception: e, stackTrace: stackTrace, ); } } 終わりに 今回はログの出し方を整理する話をしました。 ログの出し方を一元化したことで、ログの使い方が開発者に伝わりやすくなり、誤ったログの使い方を防ぐことができるようになりました。 さらに、以前は本番環境でユーザーが abd logcat など使用すればログが見える状況でしたが、ログを本番環境で出ないようにし、誤ってユーザー情報がログ出力されるなどのリスクを防ぐことでセキュリティ面でも改善ができました。 ご覧いただきありがとうございました。

この記事は every Tech Blog Advent Calendar 2024 の 20 日目の記事です。 (2025年5月更新) 目次 はじめに エンジニア内定者研修を実施するに至った背景 エンジニア内定者研修の概要 エンジニア内定者研修の目的 エンジニア内定者研修カリキュラム terminal および Git/GitHub の基礎 ネットワーク／インフラ基礎 DB 研修 プログラム基礎 Web 基礎 Web アプリケーション開発基礎 個人開発 受講者のフィードバック おわりに はじめに こんにちは。 トモニテ開発部ソフトウェアエンジニア兼、CTO室Dev Enableグループの庄司( ktanonymous )です。 現在弊社では、2025年新卒のエンジニア内定者向けに初めての内定者研修を実施しております。 今回の記事では、その内容について紹介したいと思います。 エンジニア内定者研修を実施するに至った背景 まずは、なぜこのタイミングで初めての内定者研修の実施を決定したのか、その背景についてお話ししたいと思います。 弊社では、今年の2月に、開発組織を横断して様々な課題解決を促進するための DevEnable というグループが立ち上がりました。 （以下の記事で DevEnable グループを設立した際の話について綴ってあります） 筆者も所属している DevEnable グループでは、新卒エンジニア向けのサポートも積極的に行っていきたいと考えています。 そんな中で今回のエンジニア内定者研修の実施に至ったのには、主に2つの理由があります。 1つ目の理由としては、これが一番大きいですが、内定者の意欲がありました。 内定者側から「学習機会があれば入社前でも積極的に利用していきたい」という意欲的な意見が上がっていました。 そういった意見を受けて、DevEnableとしても、内定者の積極性と学習意欲に応えたいと感じていました。 そこで、入社前の段階ではありますが、内定者向けに研修を実施するのが良いのではないかと考えました。 2つ目の理由として、今年度の初めに実施したエンジニア新卒研修での反省があります。 DevEnableグループの発足後、1つの新しい大きな取り組みとして、2024年新卒エンジニアの入社後のサポートをするために新卒エンジニア研修を実施しました。 （この新卒研修もエンジニア向けのものは初めてとなる取り組みでした。新卒研修の概要に関しては以下の記事をご覧ください） それまでは、新卒全体での職能に依らない研修はこれまでも実施されていましたが、エンジニア向けの研修は行われておらず OJT でのオンボーディングが基本となっていました。 そのため、エンジニアにフォーカスした研修を実施したことで、エブリーのエンジニアとしてのマインドセットの獲得や 幅広い知識をインプットすることでスムーズな開発組織への参画をサポートすることができました。 一方で、先の記事でも触れている通り、専門領域外を含めて社内の実際の技術スタックに触れてもらったため、以下のようなネガティブなフィードバックもありました。 最低限必要な知識などを事前に共有することで、もう一段階踏み込んだ講義内容になると感じた。 研修で使用する各種ツールの使い方についての研修か資料があると取り組みやすいと思いました。 このようなフィードバックを受け、今後も入社後のより良い新卒研修を実施していくために、受講者の知識のベースラインを揃えておくことが重要ではないかと考えていました。 上記のように、内定者の意欲を受け、新卒研修でのフィードバックを参考にしてエンジニア向けの内定者研修を実施することを決定しました。 エンジニア内定者研修の概要 エンジニア内定者研修の目的 先述の通り、内定者研修では内定者の学習意欲に応えること、来年度入社する新卒のエンジニアメンバーが入社後の研修を通じてよりスムーズに開発組織にジョインできるように ベースとなる基礎知識を学べる機会を提供することを主な目的としています。 具体的には、以下のような目的と方針を設定しました。 目的 入社前に基本的な技術や知識をキャッチアップする環境を提供する 方針 入社前に身に着けてほしい技術や知識のキャッチアップをサポートする 基礎知識を早期にキャッチアップすることで入社後の研修・オンボーディングをよりスムーズに進められるようになる 上記の目的と方針を踏まえ、筆者を含めた新卒3年目までの若手メンバーが中心となり、研修を企画・運営しています。 エンジニア内定者研修カリキュラム 今回の研修では以下のテーマで講義を行うこととしました。 各回 2 時間を目安に、2 週間に 1 回のペースで実施しています。 （執筆現在、第6回まで完了しています） ターミナルおよび Git/GitHub の基礎 ネットワーク／インフラ基礎 DB 研修 プログラム基礎 Web 基礎 Web アプリケーション開発基礎 個人開発 また、遠方から参加する方もいるため、全ての講義はオンラインで実施して録画を残すようにしています。 ただし、学業を優先してもらいたい思いもあったため、任意での参加としています。 terminal および Git/GitHub の基礎 terminal および Git/GitHub の講義では、下記のようなトピックを通じて、 普段から利用機会の多いCLI（ターミナル）やチームでの開発を行うにあたり弊社でも利用している Git/GitHub の基本的な使い方について学びました。 ターミナル／シェルとは何か コマンドはどのようにして実行されているのか 主要なコマンドの紹介 Git の基本的な仕組み Git の基本的なコマンド GitHub の使い方 ネットワーク／インフラ基礎 ネットワーク／インフラ基礎の講義では、OSI 参照モデルを中心に、 ネットワークやインフラの基礎知識について学びました。 具体的には以下のトピックを取り上げました。 プロトコル TCP/IP ネットワークセグメント HTTP アドレス DB 研修 DB 研修では、DB の基本概念やバックエンド／データ系それぞれの視点での利用について学びました。 具体的には以下のトピックを取り上げました。 「データ」の種類 データ基盤 サーバーエンジニア視点でのデータ利用 データエンジニア視点でのデータ利用 プログラム基礎 プログラム基礎の講義では、プログラムの基本的な構造やデータ構造、アルゴリズムについて学びました。 具体的には以下のトピックを取り上げました。 データ構造 配列とリスト スタックとキュー ハッシュ 木構造 アルゴリズム ソート 探索 Web 基礎 Web 基礎の講義では、API や Web アプリケーションの基本構成や仕組み、 バックエンド／フロントエンドそれぞれの役割について学びました。 具体的には以下のトピックを取り上げました。 Web アプリケーションの基本構成 ブラウザでの HTML のレンダリングについて ブラウザとサーバーの通信について ページの配信方式 フロントエンドとバックエンドの役割 Web アプリケーション開発基礎 Web アプリケーション開発基礎の講義では、アーキテクチャやテスト、コーディング時に意識することなど、 組織／チームでの開発に携わるうえで重要となってくる考え方について学びました。 具体的には以下のトピックを取り上げました。 良いコードを書くために意識すること アーキテクチャ テスト CI/CD 個人開発 個人開発では、入社までの期間を通じて、OpenAI の API を利用した Webアプリケーションの開発に取り組んでもらいました。 各々が課題感を持っている事柄に対して自分なりのソリューションを考え、個性豊かなアプリケーションを開発してくれました。 作ってもらったアプリケーションはどれも面白いもので、社内向けに実施した成果報告会では、とてもワクワクしたという声もありました。 受講者のフィードバック 研修の改善のために、受講者からのフィードバックをアンケートで収集しており、その中でも以下のようなポジティブな意見が見受けられました。 以前勉強してから時間が経っていたので、いい復習になりました。それらの知識がエブリーの中でどういうところに当てはまっているのかも知ることができました。 学校の授業ではあまりやらないような，実際のアプリケーション開発に役立つ部分をやってくださり，とても勉強になった 研修自体はまだ続きますが、今回得られたフィードバックをもとに、今後の研修の改善に活かしていきたいと考えています。 講義の風景① 講義の風景① おわりに 今回の記事では、現在進行中の弊社で初めての実施となるエンジニア向け内定者研修についてご紹介いたしました。 内定者研修を通じて、今後入社するエンジニアのメンバーが入社後のオンボーディングをよりスムーズに進められるようにサポートすることができると考えております。 また、研修の企画・運営に携わった若手メンバーにとっても、 知識の整理や研修の主要メンバーとしてという新たなチャレンジの機会となり、貴重な成長の機会となっていると感じています。 今回の研修の経験を含めて、今後もエンジニアの成長を支援する取り組みを続けていきたいと考えています。 最後まで読んでいただき、ありがとうございました。

この記事は every Tech Blog Advent Calendar 2024 19 日目の記事です。 はじめに こんにちは、 @きょー です！普段はデリッシュキッチン開発部のバックエンド中心で業務をしています。 導入 Go 1.24 が来年の 2 月にリリースされます。 ドラフトではありますが Go 1.24 のリリースノートは既に公開されています（2024 年 12 月 19 日時点）。 tip.golang.org encoding/json に omitzero という json タグが追加され omitempty と何がどう違うのか気になったため、調べたことについて共有していこうと思います。 encoding/json とは json のエンコードとデコードを実装しているパッケージになります。json と Go の値の対応付けを Marshall、Unmarshal によって行っています。 pkg.go.dev サーバーからのレスポンスを json 形式にしてデータを返す際や、リクエストからデータを読み込む際に使うことが多いパッケージかと思います。 まずは omitzero を理解するために omitempty の挙動とその問題点についてみていきます。 omitempty について Go の構造体を json に変換する際に、フィールドの値がゼロ値の場合にそのフィールドを出力しないという便利な機能です。この機能を活用することで、json のサイズを削減したり、不要な情報を排除したりできます。 以下のように json タグに omitempty とつければ機能します。 type User struct { ID int `json:"id,omitempty"` Name string `json:"name,omitempty"` } 実際に空の構造体を用意して動かしてみましょう。全てのフィールドがゼロ値となり、何も出力されないことが期待されます。 func main() { u := User{} jsonData, _ := json.Marshal(u) fmt.Println( string (jsonData)) } output は以下のようになり、省略してほしい値は出力されていないことが確認できました。 {} しかし omitempty には 2 つの課題がありました 課題１ プリミティブな値で構成された空の構造体に対して omitempty を指定するとフィールドが出力されてしまう点です。 例を見ていきましょう。 以下のような構造体で、先ほどと同じように実行してみます。 type User struct { ID int `json:"id,omitempty"` Name string `json:"name,omitempty"` SampleStruct SampleStruct `json:"sample_struct,omitempty"` } type SampleStruct struct { SampleField1 int `json:"sample_field_1,omitempty"` SampleField2 int `json:"sample_field_2,omitempty"` } output は以下のようになり、 omitempty を指定している構造体の値が空なので何も出力されないことを期待しますが、構造体のフィールド名が出力されてしまっています。 { " sample_struct ": {} } 課題２ 課題 1 に繋がるところではありますが、構造体自体はその中身が空であっても omitempty はゼロ値とはみなさない点です。 これも例を見ていきましょう。 以下のような構造体で、先ほどと同じように実行してみます。 type User struct { ID int `json:"id,omitempty"` Name string `json:"name,omitempty"` CreatedAt time.Time `json:"created_at,omitempty"` UpdatedAt time.Time `json:"updated_at,omitempty"` } output は以下のようになりました。 int や string などのプリミティブな値は期待通り出力されていませんが、構造体を指定した箇所は出力されてしまっています。 { " created_at ": " 0001-01-01T00:00:00Z ", " updated_at ": " 0001-01-01T00:00:00Z " } これは Go の仕様で以下の値しかゼロ値を定められていないためです。 変数や各要素 ゼロ値 bool false 数値型 0 文字列 "" ポインタ nil 関数 nil インターフェース nil スライス nil チャンネル nil マップ nil tip.golang.org 上記のような悩みを解決できるものが omitzero になります。 omitzero について Go 1.24 から使える json タグの一つで、 omitempty と同様にフィールドに指定することで使えるようになります。 先ほどあげた課題が解決されるようになったので、確認していきます。 課題１に対して プリミティブな値で構成された空の構造体も省略されるようになります。 以下のような構造体で、先ほどと同じように実行してみます。 type User struct { ... SampleStruct SampleStruct `json:"sample_struct,omitzero"` } type SampleStruct struct { ... } output は以下のようになり、期待している値になっていることが確認できました！ {} 課題２に対して omitzero オプションが追加されたフィールドの構造体に IsZero メソッド(帰り値は bool )がある場合はそのメソッドを用いてゼロ値かどうかを判定し、ゼロ値である場合は omitempty と同様にエンコードから省略されるようなります。 以下のような構造体で、先ほどと同じように実行してみます。 type User struct { ... CreatedAt time.Time `json:"created_at,omitzero"` UpdatedAt time.Time `json:"updated_at,omitzero"` } output は以下のようになり、カスタムした値を初期に設定した構造体も省略されていることがわかります。 {} これは time パッケージの Time 構造体にある IsZero メソッドがゼロ値チェックに使われ、ゼロ値であったために省略されるようになったことを示しています // IsZero reports whether t represents the zero time instant, // January 1, year 1, 00:00:00 UTC. func (t Time) IsZero() bool { return t.sec() == 0 && t.nsec() == 0 } pkg.go.dev 例として Time 構造体を使いましたが、以下のように構造体とそのメソッドである IsZero を用意することで自分たちのアプリケーションに合わせたゼロ値を定義できるようになります。 type User struct { ... SampleStruct SampleStruct `json:"sample_struct,omitzero"` } type SampleStruct struct { ... } func (s SampleStruct) IsZero() bool { // 何の値をゼロ値とするか決められるようになる return s.SampleField1 == 1 && s.SampleField2 == 1 } func main() { u := User{} jsonData, _ := json.Marshal(u) fmt.Println( string (jsonData)) } 使う際は慎重に ここまでゼロ値の省略について話してきましたが、使う際は慎重に使っていきましょう（ omitempty もそうですが）。 例えばレコードごとの ID や作成日時などはサーバー側では一見不要に見えるかもしれませんが本当に不要かどうかは判断できません。 省略しても良いかどうかはアプリケーションごとのロジック（ゼロ値をそのまま使いたい場合もたくさんある）にもよりますし、フロントやクライアント側でどう使われているかを把握していなければ適切に使うことは難しい気がしています。 まとめ 以上 Go 1.24 で encoding/json に追加される omitzero オプションの説明でした。軽くまとめます。 omitempty ゼロ値の場合、json 出力から省略する omitzero プリミティブな値で構成された空の構造体の場合はフィールド名も含めて省略する 構造体に IsZero メソッドが実装されている場合、そのメソッドの結果に基づいてゼロ値かどうかを判断し、ゼロ値であれば省略する どちらを使うべきか 構造体のゼロ値判定が必要な場合 omitzero 構造体以外のゼロ値を判定したい場合 omitempty 注意点 必須フィールドやビジネスロジック上重要なフィールドを誤って省略しないように注意が必要 最後に Go 1.24 楽しみですね！ 今回紹介したものはほんの一部ですので、気になった方はぜひリリースノート追ってみてください！ 明日のアドベントカレンダーは 庄司( ktanonymous )さんによる 「エブリー初のエンジニア向け内定者研修を実施しています」 です！ 参考 https://tip.golang.org/doc/go1.24 https://tip.golang.org/ref/spec#The_zero_value https://github.com/golang/go/issues/45669 https://devcenter.upsun.com/posts/go-124/ PS みなさんは好きなゲームありますか？僕は最近 DAVE THE DIVER というゲームにハマっているのですが、永遠に時間が溶けててやばいです。ゲームのやりすぎで朝日を見る事も厭わない勇気有る方達、どうぞ一歩前へ。 store.steampowered.com

この記事は every Tech Blog Advent Calendar 2024 の18日目の記事です。 はじめに こんにちは、TIMELINE 開発部 Service Development をしている hond です！ 今回は12/8に行われ、弊社がISUポンサーとして協賛した ISUCON 14 に会社の同期と友人と共に参加した際に行った事前準備と当日の流れ、反省をまとめていこうと思います。 本ブログ以外にも ISUCONに向けて勉強したこと や ISUCON14 に ISUポンサーの枠で出場しました もアドベントカレンダーとして投稿されているのでぜひ読んでみてください！ 事前準備 前提 今回はチームメンバー全員がGoの経験があることから言語はGo、 ISUCON 12予選 より他のDBだとしても使い慣れているMySQLに移行することが良いことを知っていたのでMySQLを使うことを前提に準備を行いました。 概要 事前準備としては主に下記の三つを行いました。 達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践 の読解 過去問 競技に使うツール導入スクリプトの作成 達人が教えるWebパフォーマンスチューニング 〜ISUCONから学ぶ高速化の実践の読解 こちらの本はモニタリングや負荷試験、ログの集計をはじめとしたWebサービスのパフォーマンス改善を行う際に必要なメソッドがまとまったものになっています。 また、本番同様の環境が準備された private-isu に対し、どのような改善を行えばスコアが上がるか丁寧に順序立てて説明されているのでISUCONに参加したことない人やWebサービスのパフォーマンス改善の概要を知りたい人にはおすすめの一冊です！ 過去問 AWS環境で構築するものであればISUCON 5以降の一部予選、本戦の問題が公式にてAMIでの実行方法が公開されています。( ISUCON過去問 )本番では例年EC2サーバーが三台用意されるので先ほどのAMIを元に三台起動すると本番同様の環境で過去問に着手することができます。 過去問を解いた後は一部の予選・本戦問題では公式から解説と講評 ISUCON13 問題の解説と講評 が出ているのでそちらを参考に答え合わせを行うとより理解が深まります。 ISUCON 13ではDNSが初登場するなどまだまだ進化し続けるISUCONなので過去問を解いて引き出しを増やしておくと良さそうです。 競技に使うツール導入スクリプトの作成 競技ではMySQLスロークエリーの解析やアクセスログの集計、APIサーバーのプロファイリングが必要になるので、それらを円滑に行うためのツールやcnfを事前にまとめておきました。 MySQLスロークエリーの解析 初期状態ではスロークエリーログの有効化や出力先が設定されていないのでmy.cnfに以下を記述します。 [mysqld] slow_query_log = 1 slow_query_log_file = /var/log/mysql/mysql-slow.log long_query_time = 0 上記によって /var/log/mysql/mysql-slow.log にスロークエリーログ(0秒を閾値にしているので全てのクエリー)が出力されるようになっているので、それらを解析するためのツールとして pt-query-digest を導入します。 pt-query-digestを用いることでそれぞれのクエリーが全体のリクエストタイムに締める割合やRow sentやRow examineを可視化することができます。 最後にこの状態ではスロークエリーログが同一ファイルに出力されベンチマークごとの結果を確認できないので、一時的に出力先を変更するためにpt-query-digestのラッパーの query-digest を導入します。 下記のコマンドを実行することでquery-digestを実行することができます。 perl ./query-digester -duration 10 アクセスログの集計 基本的にISUCONではnginxを経由してAPIサーバーに到達するかたちになっているので、nginxのcnfを修正しJSON形式でログが出力されるようにします。 http { // 省略 log_format json escape=json '{"time":"$time_iso8601",' '"host":"$remote_addr",' '"port":$remote_port,' '"method":"$request_method",' '"uri":"$request_uri",' '"status":"$status",' '"body_bytes":$body_bytes_sent,' '"referer":"$http_referer",' '"ua":"$http_user_agent",' '"request_time":"$request_time",' '"response_time":"$upstream_response_time"}'; access_log /var/log/nginx/access.log json; //省略 } 次にアクセスログを集計するツールとして alp を導入します。 alpはステータスコードやカウント数をはじめレスポンスタイムの最大・平均・最小値などのメトリクスでアクセスログを集計できるツールとなっています。 最後にMySQLのスロークエリーログ同様にベンチマークごとに結果を確認するために、アクセスログファイルをローテートするスクリプトを作成します。 #!/bin/sh new_file_name =/var/log/nginx/access.log. `date +%Y%m%d-%H%M%S` mv /var/log/nginx/access.log $new_file_name nginx -s reopen APIサーバーのプロファイリング 今回APIサーバーの言語はGoを選択しているので、プロファイリングツールとして pprof を用います。 pprofの導入はとても簡単で、下記のように main.go に数行追加するだけでプロファイリングできるようになります！ func main() { // ここから runtime.SetBlockProfileRate( 1 ) runtime.SetMutexProfileFraction( 1 ) go func () { log.Fatal(http.ListenAndServe( "localhost:6060" , nil )) }() // ここまでを追加する log.Fatal(http.ListenAndServe( "localhost:8080" , nil )) } 当日 ここからは当日の流れになります。 ツール導入スクリプトの実行 10:00 ~ 10:30 競技に使うツール導入スクリプトの作成 にて作成したスクリプトを実行し計測可能な状態に、一部のコードをGithubに連携しdevelop branchにmergeしたらEC2にデプロイされる状態にしました。 その後初めてのベンチマークの実行を行いスコアの計測を行いました。 この時点でのスコアは700点程度。 10:30 ~ 13:00 計測の準備が完了したので実際にベンチマークを実行してその結果を確認していきました。 初期の実装ではMySQLのCPU使用率が175%付近になりAPIサーバーやnginxがうまく使えていない状態だったのでquery-digestを用いてスロークエリーログの確認を行いました。 スロークエリーの改善では主にquery-digestを用いてトータルレスポンスの割合が上位になっているクエリーの特定、EXPLAINを用いて実行計画の確認を行いクエリーの改善を行いました。 query-digestと実行計画の結果から上位のスロークエリーはテーブルにインデックスが不足していることでフィルタ処理される行の割合、調査される行の見積もりが悪化していることがわかったのでそれぞれのテーブルに対してインデックスの追加を行い改善を行いました。 オーナーに紐づく椅子を取得するクエリーに関してはサブクエリーを実行するなどクエリー自体の改善が必要そうだったので僕がインデックスの追加を行っている間にチームメイトに改善をお願いしました。 インデックスの追加とクエリーの改善によりスロークエリーは改善されお昼時点で3000点を超え一時80位台に到達しました！ 14:00 ~ 16:00 スロークエリーの改善は完了していたので、マニュアルの スコアの計算 とアクセスログの結果から配車と通知の改善が必要そうなことを確認し対象の箇所の改善に挑みました。 スコアの計算は下記のように示されていました。 以下に示す要素の合計がスコアとなります。 - 椅子がライドとマッチした位置から乗車位置までの移動距離の合計 * 0.1 - 椅子の乗車位置から目的地までの移動距離の合計 - ライド完了数 * 5 結果としては二時間ほどかけて改善に挑んだのですが、アプリケーションの理解不足でめぼしい改善ができずスコアとしては横ばいでした。 16:00 ~ 18:00 16:00以降は当初より予定していたAPIサーバーとDBのインスタンスを分離する作業に着手しました。 初期実装ではnginx, APIサーバー、DBは全て一つのインスタンスで完結していてスロークエリー改善後もMySQLがCPU使用率の大半を占めていたのでnginxとAPIサーバーのインスタンス、DBのインスタンスと二台構成にする対応を開始しました。 作業としてはAPIサーバーの向き先DBのホストの修正とMySQLで bind-address を追加するのみだったので練習で行った通りに作業を完了しベンチマークでスコアを測定しました。 CPU負荷の大半を占めていたMySQLが分離したことでAPIサーバーで使えるCPUが増えベンチマークのログを見るとスコアが8000点を超えるなど順調に思われましたが下記のクリティカルエラーが発生ベンチマークが失敗する状態になってしまいました。 msg=クリティカルエラーが発生しました error="椅子に想定していないライドの状態遷移の通知がありました (CODE=12): ride_id: 01JEJMQWN1HEGJM5NZQ40A6KG2, expect: MATCHING, got: COMPLETED" クリティカルエラーの内容によると15:00まで改善に着手していた通知の不整合とのことだったのでチームメイトとペアプロで改善を試みましたが、対象のクリティカルエラーは改善することはできず複数台構成を諦めることになりました。 後日同僚にクリティカルエラーについて話したところそのチームでも同様の現象が見られ、初期実装では通知間隔が短く複数台構成にしてパフォーマンスが向上することで不整合が発生するので通知間隔を延ばせば改善できたとのことでした。 通知間隔をどこまで延ばして良いかなどは当日マニュアルの 猶予時間 に記述されていました。 結果 結果スコアの推移は下記画像のようになりました。 インデックスやクエリーの修正によるスロークエリーの改善を行った14:00付近以降はめぼしい改善ができていないので約四時間スコアが横ばいのまま競技終了を迎えました。 しかし、 5.環境チェックNG で失格になりました😭 おそらく原因としては僕が複数台構成にするときにAPIサーバーをdisableにしたような気が。 まとめ 僕自身3回目のISUCON参加となるのですが、今まではろくに準備を行わず参加していたのでそれまでに比べれば入念に準備を行えたため当日は納得のいく動きをできたと感じました(結果としては失格ですが笑)。 複数台構成にした時にベンチマークでクリティカルエラーが発生した通知機能に関してはヒントとなる猶予時間が、当日のマニュアルに記述されていたので改めてマニュアルを確認することは大事だと感じました。 また、ペアプロを行うときにアプリの仕様について確認し合う場面が多くあったので、チームで時間を取りマニュアルの読み合わせを行う時間を取ることでその後の実装で共通認識を持って作業できるのではないかと思いました。 失敗の原因になった環境チェックに関して、当日マニュアルの 競技環境の確認 に環境チェックを行うコマンドが明記されています。 今回はこのチェックを行うことを怠り終了間際までGoのコードと向き合っていたので、普段の過去問を行う際や次回本番では環境確認時にエラーが発生することがあることも踏まえ終了時間の30分以上前には環境確認を含めた締め作業を行おうと思います。 来年はより高スコアを狙えるように普段の業務からパフォーマンスの改善を行えるところがないかなど意識していきます。

この記事は every Tech Blog Advent Calendar 2024 の17日目の記事です。 はじめに エブリーでデリッシュキッチンの開発をしている本丸です。 恥ずかしながら今までWebのパフォーマンスの調査をしたことがなかったのですが、直近で触れる機会があったため、どのように調査したのか簡単にではありますが説明させて頂こうかと思います。 背景 デリッシュキッチンでSEO対策を行う中で、別のエンジニアの方からPageSpeed Insightsを使ってパフォーマンスの改善を行なってはどうかという話が上がりました。 PageSpeed Insightsについてあまりよくわかっていなかったため調査するところから開始しました。(パフォーマンスでページのランキングが上がるという記述は公式のドキュメントからは見つけられておりませんので、確実にページのランキングに効くという内容ではないことはご認識いただければと思います。) PageSpeed Insights Google DeveloperのPageSpeed Insights API について によれば、PageSpeed Insightsとは下記のことができるツールとされています。執筆時点(2024/12/16)では日本語のページと英語のページに差分があるので 英語ページ を参照していただく方が良いかもしれません。 PageSpeed Insights では、モバイル端末やパソコン向けのページの実際のパフォーマンスに関するレポートと、そうしたページの改善方法を確認できます。 PageSpeed Insightsでは、実際のユーザーの情報の統計からのスコアとLighthouseを使用したシミュレーション環境のスコアを出力してくれます。 Lighthouse chrome for developersのLighthouse の概要 によると、Lighthouseは下記のことができるツールとされています。 Lighthouse は、ウェブページの品質を改善するためのオープンソースの自動化ツールです。公開されているウェブページでも、認証が必要なウェブページでも実行できます。パフォーマンス、ユーザー補助、プログレッシブ ウェブアプリ、SEO などの監査が行われます。 LighthouseではCPUやネットワーク環境を指定することができ、指定したシミュレーション環境でのパフォーマンスを確認することができます。また、パフォーマンスのスコアが低いものに関してどのような改善方法があるのかを教えてくれます。 話の本筋と外れますが、Chromeの開発者ツールなどからPageSpeed Insightsの一機能としてではなくLighthouse単体として使用することもできます。 公開されているものであればPageSpeed Insightsを使用しても良いのですが、ローカルや開発環境など外部に公開していない環境でパフォーマンスを確認したいときにはLighthouseをChromeの開発者ツールから使うのが便利そうです。 デリッシュキッチンをPageSpeed Insightsで確認 デリッシュキッチンをPageSpeed Insightsで確認すると実際のユーザー情報の統計からのスコアは次のようになっていました。 こちらのスコアでは各指標でユーザーごとに良好・改善が必要・不良の3つのどれかで判定され、その75パーセンタイルが最終的な結果として出力されます。 各指標が何を表しているのかを下記にまとめます。 Largest Contentful Paint (LCP) ユーザーがページにアクセスしてから、表示領域内で最も大きなコンテンツが表示されるまでの時間 Interaction to Next Paint (INP) ユーザーがページ内で行うクリックなどの操作の応答性の指標 Cumulative Layout Shift (CLS) ユーザーが予期しないレイアウトの変更がどの程度発生したかの指標 First Contentful Paint (FCP) ユーザーがページにアクセスしてから最初のコンテンツが描画されるまでの時間 Time to First Byte (TTFB) リソースをリクエストしてから最初のデータが返ってくるまでの時間 デリッシュキッチンのスマホ表示では全ての指標で良好を示しているので、実際にデリッシュキッチンを使用しているほとんどのユーザーの環境ではパフォーマンスが問題ないと言えるかと思います。 シミュレーション環境に関しては次のようになっていました。 パフォーマンス、ユーザー補助、おすすめの方法、SEOの4つの項目があるのですが、今回はパフォーマンスに注目していこうかと思います。 パフォーマンスでは次の5つの指標を確認することができます。 First Contentful Paint (FCP) 最初にコンテンツが描画されるまでにかかった時間 Largest Contentful Paint (LCP) 表示領域内で最大のコンテンツが表示されるまでにかかった時間 Total Blocking Time (TBT) コンテンツの最初の描画から、50ms以上かかったタスクの処理時間の合計 Cumulative Layout Shift (CLS) ブラウザの表示領域内で意図しないレイアウトの変更がどの程度あったかの指標 Speed Index (SI) ページのロード中にコンテンツがどれだけ早く視覚的に表示されるか 残念ながらデリッシュキッチンは、CLSの指標以外のスコアが全体的に低いようです。 PageSpeed Insights(Lighthouseでも同様)ではシミュレーション環境で見つかった問題をどのように修正すれば良いかの方針も示してくれます。 例えば、TBTのスコアに悪影響を及ぼしているメインスレッドの処理に関する問題がある場合は図のように方針を示してくれます。 Webのパフォーマンス改善に向けて ここからは少し話が変わりますが、PageSpeed InsightsでTBTの指標が悪いことがわかったのでもう少しだけ詳細に見ていこうかと思います。 Chromeの開発者ツールの中にパフォーマンスの項目があります。 このパフォーマンスを確認してみると次のような結果になりました。(ボトルネックがわかりやすいようにCPUとNetworkの品質を落としています。) 画像のうち、赤枠で囲った箇所がメインスレッドのパフォーマンスを表している箇所で、その中で赤で表示されているものが50ミリ秒以上かかっていてTBTのスコアに悪影響を与えているものになります。 この次に、何の処理がパフォーマンスに悪影響を与えているかの確認などをしていくことになるかと思うのですが、本記事では概要をつかむところまでということでここまでにしておこうかと思います。 まとめ PageSpeed Insightsを使って、実際にデリッシュキッチンのパフォーマンスを見てみましたが、改善の余地がたくさんあることがわかりました。 現段階では、パフォーマンスに関する調査を行い、改善の方針を立てるというところまでしかできておりません。来年から実際にパフォーマンスの改善に向けて動く予定ですので、実際に改善を進める中で何かお伝えできる点があればまた共有させていただければと思います。

この記事は every Tech Blog Advent Calendar 2024 の 16日目の記事です。 はじめに こんにちは。 株式会社エブリーの開発本部データ&AIチーム(DAI)でデータエンジニアをしている吉田です。 今回は、Databricks Mosaic AIによるLLM アプリケーションの評価についてのお話です。 背景 近年、LLMを利用したアプリケーションが増えており、DELISH KITCHENでもAIによる料理アシスタントとして「デリッシュAI」の提供を開始しました。 そのような状況の中で、サービスにLLMアプリケーションを組み込む際には、アプリケーションの評価がますます重要な課題となっています。 しかし、LLMアプリケーションの品質は、データの質、モデルの性能、プロンプト、retrieverの性能など複数の要素が影響するため、評価は複雑で難しい課題です。 また、アプリケーションの評価に利用するユーザーからフィードバックを収集するためには、レビュー環境の構築やテスト人員の確保、さらに収集したフィードバックの分析といった作業が必要となります。 そこで、Databricks Mosaic AI Agent Evaluationを利用することで、アプリケーション評価にかかる負担を軽減することが可能です。 Databricks Mosaic AI Agent Evaluationとは Databricksドキュメント、 Mosaic AIエージェント評価とは? によると、以下のように説明されています。 Agent Evaluationは、開発者がRAGアプリケーションやチェーンを含む エージェントAIアプリケーションの品質、コスト、およびレイテンシを評価するのに役立ちます。 エージェント評価は、品質の問題を特定し、それらの問題の根本原因を特定するように設計されています。 Agent Evaluation の機能は、 MLOps ライフサイクルの開発フェーズ、ステージングフェーズ、本番運用フェーズ全体で統合されており、すべての評価メトリクスとデータは MLflowランに記録されます。 https://docs.databricks.com/ja/generative-ai/agent-evaluation/index.html 主に以下のような機能が提供されています。 Review App作成 : ユーザからフィードバックを効率よく収集できるアプリケーションを簡単に作成できます 評価と原因分析：集めたフィードバックを活用して、評価指標を可視化し、問題の根本原因を明確にします モデルのデプロイに合わせてReview Appが作成されることで、ユーザからのフィードバックを効率的に収集できる仕組みが提供されます。 また、Databricks Model ServingやVector Search、Unity Catalogと組み合わせることで、LLMアプリケーションの構築、運用、評価を単一のプラットフォームで行うことができます。 LLMアプリケーションの評価 今回は、RAGアプリケーションを例にLLMアプリケーションの評価を行います。 テストには Generative AI Cookbook の 10 minute demo of Mosaic AI Agent Framework & Agent Evaluation 上のコードを利用しました。 Unity CatalogにRAGモデルが登録されている前提で、以下の手順で評価を行います。 Serving EndpointにRAGモデルを登録 & Review Appの作成 Review Appを利用して、ユーザからフィードバックを収集 収集したフィードバックを利用して、評価と根本原因分析 Review Appの作成 Review Appの作成は、以下のコードを実行することで行います。 import mlflow from databricks import agents mlflow.set_registry_uri( 'databricks-uc' ) model_name = "{catalog}.{schema}.{model_name}" # Unity Catalogにモデルを登録 model_register_info = mlflow.register_model(model_uri= "{model_uri}" , name=model_name) # Serving Endpointにモデルをデプロイ & Review Appが作成される deployment_info = agents.deploy(model_name=model_name, model_version=model_register_info.version) agent.deploy を実行することで、Serving Endpointにモデルがデプロイされます。 このとき、Review App用のfeedbackというモデルが同時に作成され、自動的にReview Appが作成されます。 フィードバックの収集 Review Appを活用することで、ユーザからフィードバックを迅速に収集できる環境を整えられます。 これにより、モデルデプロイ後数分から十数分でフィードバックの収集をスタートでき、URL共有するだけでユーザの評価を収集する仕組みが構築されます。 ドメイン知識を持つ社内メンバーやステークホルダーからのフィードバックを収集することで、モデルの品質向上に寄与する重要なインサイトを得ることができます。 Review Appのフィードバック入力 Review Appを利用することでユーザはLLMアプリケーションを利用しつつ、フィードバックを提供できます。 主に以下のようなフィードバックを収集します。 回答に対する正誤 フィードバックの理由 期待される回答 参照されたドキュメントへの正誤 収集されたフィードバックは、自動的にDeltaテーブルに記録され後続の分析に活用することが可能です。 評価と根本原因分析 収集したフィードバックを活用し、以下のような評価を行います。 回答は、ユーザの質問に対応しているか 回答は、期待される回答と比較して適切か 回答は、取得されたドキュメントを元にしているか 取得されたドキュメントは適切か 収集されたデータは以下のような形式で記録されています。一部のカラムを抜粋しています。 {catalog_name}.{schema_name}.{model_name}_payload_assessment_logs : フィードバックの詳細 text_assessment : LLMからの回答に対する評価 ratings : 評価 suggested_output : 期待される回答 retrieval_assessment : 取得されたドキュメントに対する評価 {catalog_name}.{schema_name}.{model_name}_payload_request_logs : ユーザのリクエストとアプリケーションの回答 request : ユーザのリクエスト response : アプリケーションの回答 これらのデータを利用して、以下のような評価データセットを作成し、 mlflow.evaluate を利用して評価を行います。 import mlflow import pandas as pd eval_df = pd.DataFrame([ { "request_id" : "{ID}" , "request" : "{ユーザのリクエスト}" , "response" : "{アプリケーションの回答}" , "expected_retrieved_context" : "[{期待されるドキュメント}]" , "expected_response" : "{期待される回答}" , } ]) eval_results = mlflow.evaluate( data=eval_df, model={評価したいモデル}, model_type= "databricks-agent" , ) mlflow.evaluate を実行することで、モデルの評価を行います。 Evaluation Results Evaluation Result Detail モデル出力と期待結果の比較を行うことで、モデルの性能を評価しています。 評価に対する根拠や、推奨される改善点が表示されるため、モデルの品質向上に寄与する重要な情報を得ることができます。 また、モデル間で評価を比較することで、改善の方向性を検討することも可能です。 終わりに LLMアプリケーションの評価は、サービスの品質向上やユーザ体験の最適化において非常に重要なプロセスです。 Databricks Mosaic AI Agent Evaluationを活用することで、従来は複雑だった評価作業を効率化し、フィードバックの収集から分析まで一貫したプロセスで実施できる強力なフレームワークが提供されます。

この記事は every Tech Blog Advent Calendar 2024 の 15 日目の記事です。 iPadOS 18の新しいタブバー iPadOS 18では、タブバーのデザインが一新され、これまで画面下部にあったタブバーが画面上部のナビゲーションバー内に移動しています。これによってコンテンツを表示するスペースがより広くなる利点があります。 新デザインはほぼ強制的に適用されるため、タブバーを持つ既存アプリで何らかの対処が必要になる場合があります。トモニテアプリでの対応をご紹介します。 参考 WWDC2024 iPadOSのタブとサイドバーの利用体験を向上 https://developer.apple.com/jp/videos/play/wwdc2024/10147/ 新しいタブバーデザインの適用条件 iPadOS 17上で動作 iPadOS 18上で動作 Xcode 15.xでビルド 旧デザイン 旧デザイン Xcode 16でビルド 旧デザイン 新デザイン タブバーが画面上部にある Xcode 16以降でビルドしたアプリをiPadOS 18以降で動作させた場合だけ、新規デザインが適用されます。 Xcode 16への移行スケジュール 2025年4月以降、App Store ConnectにアップロードするアプリはiOS 18、iPadOS 18に対応したSDKでビルドする必要があります。 そのため2025年3月中にXcode 16に移行する必要があり、新しいタブバーデザインへの対応もそれまでに完了しておく必要があります。 https://developer.apple.com/jp/news/?id=utw4yhtp 既存デザインを維持する方法 タブバーの旧デザインを選択する公式の方法はありませんが、 traitOverrides.horizontalSizeClass を利用して強制的にiPhoneと同じ表示にすることで変化を回避できるようです。 SwiftUI TabView { ... } .environment(\.horizontalSizeClass, .compact) UIKit class MyTabBarController : UITabBarController { override func viewDidLoad () { super .viewDidLoad() traitOverrides.horizontalSizeClass = .compact } } 引用 https://stackoverflow.com/questions/78631030 このコードでは MyTabBarController の配下のViewControllerも影響を受けるため、それらのViewControllerが想定と異なる動作になってしまう可能性があります。また、MacOSでは別の問題があります。 将来のiPadOSでもこの方法が有効な保証はないため推奨できませんが、一時的な回避策としてこの方法の採用を検討しても良いかもしれません。 新しいタブバーデザインに対応 navigationItem.titleView を使っている場合 トモニテアプリでは navigationItem.titleView に検索文字列を入力するためのテキストフィールドを置いていました。 Xcode 16 + iPadOS 18では以下のように、 navigationItem.titleView に配置したビューとタブが重なって表示されてしまいます。 トモニテアプリでは今後、iPadOSでは navigationItem.titleView を使わないこととして、ビューを他の箇所に移動することにしました。ここでは navigationItem.rightBarButtonItems にボタンとして配置することにしました。 navigationItem.title を使っている場合 Xcode 16 + iPadOS 18ではタイトルの文字列が以下のように表示されます。ナビゲーションバーが太くなり、2段目にタイトルが表示されます。 無駄にスペースを消費するため、iPadOSでは今後、重要でない場合はタイトルに表示しないなどの対応をするのが望ましいと思います。トモニテでは、情報が重複する箇所ではタイトルを表示しない対応をしました。 その他 その他、タブバーの旧デザインに依存した箇所を見直す必要があるかもしれません。 タブアイコンの画像が表示されないため視認性が悪化する可能性がある タブバーのカスタマイズをしている場合、カスタマイズができなくなる 最後に Xcode 16 + iPadOS 18のタブバーデザイン変更への対応は、UXが大きく変わり影響範囲が広くなる可能性があります。デザイナー/PdMと連携して十分余裕を持ったスケジュールで対応する必要があると感じました。 この記事が、同様の課題に直面している開発者の方々の参考になれば幸いです。

この記事は every Tech Blog Advent Calendar 2024 の 14 日目の記事です。 はじめに こんにちは。 開発本部のデータ&AIチームでデータサイエンティストをしている古濵です。 直近開発に取り組んでいるデリッシュAIのアーキテクチャについてご紹介します。 DELISH KITCHENでは 「作りたい！が見つかる」をサービスのコンセプトとして、様々な機能を提供してきました。 一方、ユーザーひとりひとりの多様なニーズに合わせたレシピを提案していくには既存機能だけでは難しい部分があります。 そこで、AIによる料理アシスタントとして「デリッシュAI」ベータ版を一部ユーザーから提供し始めています。 アーキテクチャ AI Server あらかじめレシピのタイトル、手順、タグ情報などを持ったデータをEmbedding化するバッチを組んでおく そのレシピEmbedding情報をベクトル検索できるように Mosaic AI Vector Search を用いたベクトルストアを用意 RAGの仕組みを活用して、ユーザのクエリをベクトル検索し、検索して得られたレシピのコンテキストをプロンプトに入れ込んで、LLMにリクエスト LLMはOpenAI APIを利用し、Structured Outputs機能を活用して、レシピの提案コメントとレシピIDを返す これらのコードをmlflow.pyfunc.PythonModelを継承したクラスとして定義し、mlflow.pyfunc.log_modelでモデルを保存（後述する 今度の課題>コード管理 参照） Mosaic AI Foundation Model Serving の機能で、保存したモデルをデプロイし、Seving EndpointsのURLを取得 例) https://{サブドメイン}.cloud.databricks.com/serving-endpoints/{モデル}/invocations API GatewayにSeving EndpointsのURLを登録しておく Delish Server ユーザからのリクエストを受け取る 過去の会話履歴に基づいてレシピ提案するため、レシピデータと会話履歴を取得し、レシピのメタデータを持った会話履歴データを作成 API Gatewayにユーザのクエリと会話履歴データをリクエスト API Gatewayのマッピングテンプレート機能を使って、リクエストのフォーマットを変換し、DatabricksのModel Servingにリクエスト Model Serving Endpointからのレスポンス（AI検索結果）を受け取り、レシピIDがハルシネーションしていないかなど、レスポンスが適切かをチェック ユーザにレシピを提案するレスポンスを返す 同時に会話履歴を踏まえたレシピの提案をするために会話履歴を保存 同様に蓄積したデータを分析するために、event logを保存 意図 職責による実装の分離 弊社では、データ&AIチームがデータの収集・分析基盤の開発・運用を担当し、事業部のサーバーサイドエンジニアがユーザに提供するためのAPIやバックエンドシステムの開発・運用を担当していることが多いです。 今回のデリッシュAIの開発も同様に、データ&AIチームが機械学習モデルを開発し、事業部のサーバーサイドエンジニアがこれらのモデルをサービスに統合するという役割分担をしました。 これにより、それぞれのチームが普段使い慣れている技術をベースに開発を進めることができ、短期間でデリッシュAIを提供することができています。 API Gatewayの活用 Delish ServerとDatabricksの繋ぎ込み部分は、 Amazon API Gateway マッピングテンプレートと Amazon SageMaker を使用して機械学習を搭載した REST API の作成 を参考に、API Gatewayを採用しています。これは、 以前のPoC実績 をベースにしています。 API Gatewayを利用することで、以下の2点の恩恵を受けられると考えています。 1. ログやメトリクスの拡充 ログやメトリクスは、DatabricksのMosaic AI Foundation Model Servingでも確認できるのですが、詳細を見ることができる情報量がAPI GatewayからCloundWatchに送られるログの方が多いです。実際に開発時にも、CloundWatchのログからエラーの原因を特定することができた実績もあります。 2. リクエスト/レスポンスの柔軟なフォーマット変換 「モデルのI/O」と「APIのリクエスト/レスポンス」が必ずしも一致しない場合があります。 また、何らかの理由でフォーマットを変更したい可能性もあります。 そのとき、マッピングテンプレートを変更することで、「モデルのI/O」と「APIのリクエスト/レスポンス」のどちらかを変更したい場合でも、柔軟な対応が可能になります。 今後の課題 コード管理 デリッシュAIのロジックであるRAGの実装部分は以下のようなコード構成になっています。 これまでは、これをDatabricksの1ノートブック内に全てコーディングする管理をしていました。 しかし、これから開発がさらに進むことを想定して、ある程度コードを共通化したいニーズが生まれて来ており、新たなコード管理の整備が必要だと感じています。 import mlflow from mlflow.models import infer_signature def generate_answer (query, conversation_history): # ここでRAGの仕組みを活用してレシピの提案コメントを生成 return response class DelishAI (mlflow.pyfunc.PythonModel): def predict (self, context, input ): query = str ( input [ 'query' ][ 0 ]) conversation_history = list ( input [ 'conversationHistory' ][ 0 ]) return generate_answer(query, conversation_history) # サンプルデータ query_sample = "もっとスパイシーなカレーのレシピ教えて" conversation_history_sample = [...] input_sample = { "query" : query_sample, "conversationHistory" : conversation_history_sample } output_sample = generate_answer(query_sample, seed_sample, conversation_history_sample) # シグネチャの作成（モデルのI/Oを保存時に付与） signature_sample = infer_signature(input_sample, output_sample) # Unity Catalogで登録するモデル名 model_name = f "{catalog}.{schema}.{model}" # モデルの保存 with mlflow.start_run(): model_info = mlflow.pyfunc.log_model( artifact_path= "model" , python_model=DelishAI(), signature = signature_sample, registered_model_name=model_name, ) 評価データの収集 Databricksでは、 Mosaic AI Agent Frameworkを使用してAIエージェントを作る ことができます。 AIエージェントをデプロイすると、Databricks上で簡単に自分たちが作成したモデルをレビューアプリとして利用することができます。 レビューアプリは AIエージェントの品質に関するフィードバックを利用者から集める ことができ、社内で公開することで、toC向けの機能だとしても品質向上に役立てることができると考えています。 デリッシュAIも、Slackbotで社内提供させるところから始まって改善を繰り返しており、実際にどんな使われ方をしているかを把握することは、開発する上で重要だと感じています。 ただ、AIエージェントの利用には 入出力のスキーマが特定のフォーマット である必要があります。ここでも柔軟にフォーマット変更できるマッピングテンプレートが活きてくると考えています。 まとめ デリッシュAIのアーキテクチャについてご紹介しました。 今後も、ユーザのニーズに合わせた提案していくために、デリッシュAIの機能を拡充していく予定です。

この記事は every Tech Blog Advent Calendar 2024 13 日目の記事です。 はじめに こんにちは、DELISH KITCHEN でクライアントエンジニアを担当している kikuchi です。 普段会話をする際に、話す相手は誰か、言及する対象は人であるか物であるか、性別はどうか、といった様々な情報から微妙にニュアンスを変えて話すことがありますが、 もしアプリでユーザの特性によって文言を出し分ける、というような機能を実装する場合は、条件分岐が複雑化するなど多くの手間がかかってしまいます。 今回はそのユーザの特性の中でもユーザの性別 (文法上の性別) によって、簡単にアプリ上で表示する文言を切り替えることができる Grammatical Inflection API という機能を紹介したいと思います。 Grammatical Inflection API を使用することで、性別による複雑な条件分岐を実装する手間を省くことができます。 文法上の性別とは 一言で「文法上の性別」と記載しても少し分かりづらいと思いますので、具体例を記載したいと思います。 Android Developer サイト で本件について「フランス語でサービスに登録されていることをユーザに知らせるメッセージの例」があるため引用します。 Masculine-inflected form: 「Vous êtes abonné à...」 (English: 「You are subscribed to...」) Feminine-inflected form: 「Vous êtes abonnée à...」 (English: 「You are subscribed to...」) Neutral phrasing that avoids inflection: 「Abonnement à...activé」 (English: 「Subscription to ... enabled」) この様に英語では文法が変わりませんが、フランス語では微妙に文法が変わっている (「abonné」と「abonnée」で差異がある) ことが分かります。 日本語でも「あなたは〇〇に登録しています」といった統一の文法になると思いますが、上記の様に文法上の性別への対応が必要な言語も存在するため、 多言語対応をする場合は言語に合わせて適切な文法を設定することがユーザに対しての適切なアプローチとなります。 Grammatical Inflection API の概要 こちらの API で提供される機能は大きく分けて 2 つあります。 文法上の性別を選択する 性別によって文字列のリソースを分ける まず 1 についてですが、こちらで選択できる性別の修飾子は 女性的 (feminine) 男性的 (masculine) 中性的 (neuter) の 3 つが存在します。 そして 2 についてですが、Android は以前から言語で文字列のリソースを分けることができますが、そこに更に性別でもリソースを分けることができる様になります。 先程のフランス語を例にすると フランス語、かつ女性的 : res/values-fr-feminine/strings.xml フランス語、かつ男性的 : res/values-fr-masculine/strings.xml フランス語、かつ中性的 : res/values-fr-neuter/strings.xml といった分け方ができ、例えば 1 の機能で女性的 (feminine) を選択していると、 res/values-fr-feminine/strings.xml のリソースから文字列が読み込まれる様になります。 なお、本 API ですが、 Android 14 以降の端末のみサポートされる Android Studio Giraffe Canary 7 以降の環境のみ、性別のリソースの修飾子 (values-fr-masculine の masculine の部分) がサポートされる といった制約があるため、事前に対象の OS を絞る、開発環境を新しくするといった対応が必要となります。 実装方法 本項目では具体的な実装方法について説明したいと思います。 文法上の性別を選択する 文法上の性別を選択する API の実装方法について説明します。 まずは AndroidManifest.xml で API を実施する Activity に宣言を追加します。 <activity android:name=".TestActivity" android:configChanges="grammaticalGender" ← こちらを追加する android:exported="true"> </activity> そして次に性別を選択する API を以下の様に実装します。 val gIM = getSystemService(requireContext(), GrammaticalInflectionManager::class.java) gIM?.setRequestedApplicationGrammaticalGender(Configuration.GRAMMATICAL_GENDER_FEMININE) GrammaticalInflectionManager のサービスにアクセスし、setRequestedApplicationGrammaticalGender メソッドを呼ぶのみとなります。 こちらで指定できる値は Configuration.GRAMMATICAL_GENDER_FEMININE : 女性的 Configuration.GRAMMATICAL_GENDER_MASCULINE : 男性的 Configuration.GRAMMATICAL_GENDER_NEUTRAL : 中性的 となります。 本 API ですが、アプリの初回起動時のアンケート、あるいは設定画面などで性別を選択する UI を用意し、ユーザが選択したタイミングで性別を選択する API を実行する、といった使い方ができるかと思います。 なお、選択した性別を取得する API は以下の様に実装します。 val gIM = getSystemService(requireContext(), GrammaticalInflectionManager::class.java) val grammaticalGender = gIM?.applicationGrammaticalGender こちらも選択のケースと同様で、GrammaticalInflectionManager サービスにアクセスし applicationGrammaticalGender で値を取得するのみとなります。 性別によって文字列のリソースを分ける 次に性別によって文字列のリソースを分ける方法ですが、こちらは特にコードを書く必要はありません。 概要で説明した通り、性別のリソースファイルを用意するのみとなります。 ●res/values-fr/strings.xml (言語のリソースファイル) <resources> <string name="test">test</string> </resources> ●res/values-fr-feminine/strings.xml (女性的のリソースファイル) <resources> <string name="test">test_feminine</string> </resources> ●res/values-fr-masculine/strings.xml (男性的のリソースファイル) <resources> <string name="test">test_masculine</string> </resources> ●res/values-fr-neuter/strings.xml (中性的のリソースファイル) <resources> <string name="test">test_neuter</string> </resources> 文法上の性別を選択する API で Configuration.GRAMMATICAL_GENDER_FEMININE を設定していた場合、test の識別子のリソースにアクセスすると 女性的のリソースファイルにアクセスするため、「test_feminine」という文字列が取得できる様になります。 なお、文法上の性別を選択する API を実行していない場合は言語のリソースファイルにアクセスするため「test」という文字列が取得できます。 実装としては以上となります。 注意点 言語のリソースファイルには全てのリソースの識別子が網羅されており、性別によって変化させたい文字列のみ性別のリソースファイルに定義する必要があります。 また言語のリソースファイルに定義されていないリソースの識別子を性別のリソースファイルに定義はできません。 具体例を記載します。 ●res/values-fr/strings.xml (言語のリソースファイル) <resources> <string name="test">test</string> </resources> ●res/values-fr-feminine/strings.xml (性別のリソースファイル) <resources> <string name="test">test_feminine</string> </resources> ●res/values-fr-masculine/strings.xml (性別のリソースファイル) <resources> <string name="test_aaa">test_masculine</string> </resources> このようなケースの場合、 values-fr-masculine に 「test」が無いが、values-fr に定義されているのでエラーにはならない (values-fr の「test」が読み込まれる) values-fr-masculine に 「test_aaa」が定義されているが、values-fr に定義されていないためエラーになる となるため、エラーを回避する場合は values-fr にも test_aaa を定義する必要があります。 こちらは大本のリソースファイルと言語のリソースファイル (values/strings.xml と values-fr/strings.xml) の関係と同様のルールとなります。 また、values-fr-neuter が存在しませんが、values-fr が存在しているのでエラーとはなりません。 まとめ 翻訳自体はかなり専門的な知識が必要となりますが、私自身海外のアプリを使用する際は翻訳が雑だと怪しいと感じ、逆に翻訳が行き届いていると丁寧なアプリだと感じることがあるので、 こういった細かい部分を丁寧に対応することがユーザの獲得、継続利用に繋がると考えています。 また日本語の場合でも、性別によって言葉を変えることでよりターゲットを絞った訴求ができることも考えられるため、一度この機能の導入を検討してみてはいかがでしょうか。

はじめに この記事は every Tech Blog Advent Calendar 2024 の12日目の記事です。 DELISH KITCHENのiOSアプリ開発を担当している池田です。今回はiOSプロジェクトでのGraphQLクライアントをApollo iOSから自前実装へ移行した経験についてお話しします。 背景 DELISH KITCHENのAPIの一部でGraphQLを利用しており、開発効率向上のために Apollo iOS を導入していました。これにより、GraphQLの利用をより簡単に行える環境を整えていました。導入時の詳細については以下の記事をご参照ください。 tech.every.tv GraphQLについて GraphQLでは、必要な情報だけを取得できたり複数のエンドポイントのリクエストをひとつにまとめたりできる柔軟なデータ取得が特徴です。クライアント側で必要なデータを宣言的に指定できるため、データの過不足なく効率的な通信が可能になります。一方で、新しい技術仕様の習得やクエリ設計のベストプラクティスの理解など、学習コストが比較的高いことが課題として挙げられます。 Apollo iOSを使う利点 Apollo iOSには主に以下の利点があります： GraphQLのスキーマとクエリからSwiftコードを自動生成できることによる開発効率の向上 クライアントサイドでのキャッシュ管理の簡略化とパフォーマンスの最適化 型安全性の保証による実行時エラーの防止 DELISH KITCHENでは、特にコードの自動生成による開発効率向上を目的としてApollo iOSを導入していました。 自前実装の経緯 Apollo iOSは、コード自動生成機能により当初の目的であった開発効率化を実現していました。しかし、DELISH KITCHENのAPIの大半はRESTfulで、GraphQLの利用は限定的であったため、実際の効率化の効果は想定を下回っていました。 さらに、今後もGraphQLの利用を積極的に拡大しない方針が決定されたことで、Apollo iOSを維持するコストが相対的に高くなってきました。具体的には以下の課題が浮き彫りになりました： iOSプロジェクトのApollo iOSへの依存関係の管理 コード自動生成に必要な非Swiftファイルの維持 自動生成されたファイルによるプロジェクト管理上の複雑さ これらの状況を踏まえ、Apollo iOSへの依存を解消し、必要最小限の機能に特化したGraphQLクライアントを自前で実装することを決定しました。 GraphQLクライアントの自前実装 GraphQLは本質的にはHTTP POSTリクエストであり、適切なリクエストボディを構築することで実装が可能です。ここでのクエリ文字列自体はApollo iOS使用時と同様にスキーマを元に構築する必要があります。以下に基本的な実装例を示します： // GraphQLのエンドポイントURL let url = URL(string : "https://api.example.com/graphql" ) ! var urlRequest = URLRequest(url : url ) urlRequest.httpMethod = "POST" urlRequest.setValue( "application/json" , forHTTPHeaderField : "Content-Type" ) // スキーマを元に構築したGraphQLのクエリGraphQLのクエリ let query = """ mutation CreateOrder($productId: ID!, $quantity: Int!, $shippingAddress: AddressInput!) { createOrder(productId: $productId, quantity: $quantity, shippingAddress: $shippingAddress) { orderId totalPrice estimatedDeliveryDate status } } """ // 変数の定義 let variables : [ String : Any ] = [ "productId" : "prod_123456" , "quantity" : 2 , "shippingAddress" : [ "street": "123 Main St", "city": "Tokyo", "postalCode": "100-0001", "country": "Japan" ] ] // リクエストボディの構築 let body : [ String : Any ] = [ "query" : query , "variables" : variables ] // リクエストの実行 urlRequest.httpBody = try ? JSONSerialization.data(withJSONObject : body ) do { let (data, response) = try await URLSession.shared.data( for : urlRequest ) // レスポンス処理 if let httpResponse = response as? HTTPURLResponse { switch httpResponse.statusCode { case 200 : let json = try JSONSerialization.jsonObject(with : data ) print( "注文が成功しました:" , json) default : print ( "エラーが発生しました。ステータスコード:" , httpResponse.statusCode) } } } catch { print( "リクエストエラー:" , error) } このように、GraphQLクライアントの基本的な機能は標準的なネットワーキング処理で実装することができます。実際のプロジェクトでは、この基本実装をベースに、既存のRESTful APIクライアントと同じインターフェースで利用できるよう設計し、ネットワーキング層の実装を共通化しました。 おわりに 今回は、Apollo iOSから自前実装への移行について紹介しました。GraphQLの利用範囲や開発方針に応じて、時にはサードパーティライブラリへの依存を見直し、シンプルな実装へ移行することも選択肢のひとつとなり得ることが分かりました。 この記事が、同様の課題に直面している開発者の方々の参考になれば幸いです。

はじめに この記事は every Tech Blog Advent Calendar 2024 11 日目の記事です。 こんにちは。DELISH KITCHEN 開発部 RHRA グループ所属の池です。 2024年6月、エブリーは5つの小売アプリの運営について事業譲渡を受け、『 retail HUB 』へ移管しました。 移管してから半年間、引き継ぎ元の企業様からサポートをいただきながら、システムの移管と運営を行ってきました。 システムの移管は、システムを構成する各種サービス・ツールの公式の移管手順に従って基本的には行いますが、中には記述が不明瞭な場合もあり、試行錯誤が必要でした。 本記事では、事業譲渡を受けた小売アプリのシステム移管作業をまとめ、移管作業における注意点もあわせて紹介します。 同じようにシステムを引き継ぐ機会がある方々の参考になれば幸いです。 また、引き継ぎ作業の前段階で行ったシステムデューデリジェンスについても先日別の記事にて紹介しておりますので、もし興味があればご覧ください。 tech.every.tv 移管対象のシステムについて 事業譲渡を受けた小売アプリのシステムは、iOS/Androidのネイティブアプリと、入稿管理画面の Web アプリケーションサーバー、アプリ向け API サーバー、それらを構成するシステム（AWS環境、ロードバランサー、データベース、バッチサーバーなど）です。 これらは以下を利用して構築され、それぞれが移管対象となります。 システム GitHub リポジトリ AWS アカウント Firebase プロジェクト Google Analytic プロパティ ドメイン App Store Connect アプリ Google Play Console アプリ 外部サービスの契約 PUSH通知サービス システム監視サービス WAFサービス SMSサービス その他 ドキュメント Backlog また、移管にあたっての前提ですが、移管元の企業様はエブリーへの事業継承後も引き続き一部の開発を担う契約となっているため、システム移管後も開発が継続できる状態を保つことが前提となります。 そのため、各種移管において、ユーザーアカウントの権限設定やユーザー自体の移管も含めて検討・作業を行う必要があります。以下の内容はその前提を踏まえた作業内容および注意点としてお伝えします。 それでは、それぞれのシステムに関する移管作業まとめていきます。 GitHub リポジトリ の移管 GitHib リポジトリの移管は 公式手順 にて確認できますが、公式手順の他にもいくつかの考慮事項がありました。 エブリーのGitHubに招待する移管元開発者の権限設定 移管対象のリポジトリのみを閲覧操作できるような権限設定が必要 移管に伴う影響の確認 上記を踏まえて、GitHubリポジトリの移管は次の手順で行いました。 移管元企業様にGitHubリポジトリと連携している外部サービスを洗い出していただく 事前に移管元の開発者を移管先のGitHub組織に招待し、移管対象のリポジトリだけを閲覧できるように設定したTeamに所属させておく 移管元GitHubにてリポジトリの移管を行う リポジトリの Settings > Transfer から移管先のGitHub組織名を入力して移管を行う 移管先GitHubにてリポジトリが移管されたことを確認する 移管されたリポジトリを対象のTeamに所属させる 1.で洗い出した外部サービスにおいて、GitHubと再接続させる 注意点 注意点は2つあります。 移管対象のリポジトリ自体に直接属しているGitHubアカウントが合わせて移管される リポジトリを参照しているサービスとの連携が切れる 1点目について、GitHub組織のシートに空きがある場合、移管元のリポジトリ自体に直接属しているGitHubアカウントも合わせて移管されてしまいます。 私たちもそのことを正しく把握できていなかったため、移管後に意図しない引き継ぎ元企業様のGitHubアカウントがエブリーのGitHub組織に属している状態になっており、費用が余分に発生していました。幸いにも権限設定を正しく管理していたため、他のリポジトリを閲覧操作できることはなかったのですが、組織自体の権限設定次第では見せてはいけないリポジトリが閲覧操作できてしまう可能性があるので、注意が必要です。 2点目について、移管を行うと、GitHubリポジトリを参照している外部サービスにおいて参照できない状態になるため、再接続するまで使えなくなります。 私たちのシステムでは AWS CodePipeline で GitHub リポジトリと接続しており、移管後に再接続が必要でした。もし他にも接続しているサービスがあれば再接続が必要になるので、移管前の準備として接続しているサービスやツールを洗い出して影響範囲を確認しておく必要があります。 AWS アカウント の移管 前提として、移管対象のAWSアカウントは 移管元企業様の AWS Organizations に各AWSアカウントが所属おり、それらをエブリーの AWS Organizations に属する形へと移管を行います。 AWS Organizations 間におけるAWSアカウントの移管は こちらの手順 にて確認できます。 公式手順以外には以下のようなことが考慮事項でした。 AWSアカウントの所有権の譲渡 移管後にAWSアカウントを利用する移管元開発者の権限設定 まず、移管の前段でAWSアカウントの所有権の譲渡を行いました。所有権の譲渡が完了してしまえば、後の作業は全て弊社内の作業にて完結するようになるので、先に移しておくと作業しやすくなります。 所有権の譲渡については、今までは譲渡同意書をAWSに提出する必要があったようですが、今年から譲渡同意書は不要になりました。 譲渡要件は こちら で確認ができます。今回の作業では以下のアカウント情報を更新することで所有権を譲渡できました。 アカウント設定 連絡先情報 支払いの詳細設定 所有権をエブリーに移した上で、権限設定の考慮事項を踏まえて AWS Organizations 間におけるAWSアカウント移管の作業を以下の手順で行いました。 移管元の開発者を移管対象のAWSアカウントごとにIAMユーザーとして作成（管理上の都合で各AWSアカウントごとにそれぞれIAMユーザーとして作成） 最小限の権限となるようにポリシー設定を行う 移管先の AWS Organizations にてAWSアカウントの招待を行う 招待の画面にて、移管対象のAWSアカウントIDを入力することで招待を行える 招待したAWSアカウントに設定されているメールアドレスに招待メールが届き、招待を承認する 移管したAWSアカウントにSSOログインできるように設定を行う 以上でAWSアカウントの移管は完了です。 注意点 AWSアカウントの移管にあたっては、大きく注意すべきポイントはありませんでしたが、強いてあるとすれば、移管したタイミングで請求書が分かれるということです。 移管した月は請求書が2つに分かれるので、そのことを把握していないと片方の請求書を見落としてしまう可能性があるので、ご注意ください。 また、今回は各AWSアカウントごとにIAMユーザーを作成する形をとりましたが、移管元企業様が引き続き開発を行える状態をどのように維持するかについて、事前に十分に協議して擦り合わせておくことが大切です。 Firebase プロジェクト の移管 Firebase プロジェクトはGoogle Cloud プロジェクトと連携しているので、該当のGoogle Cloud プロジェクトの移管を行うことでFirebase プロジェクトを移管できます。 移管の前提として、今回移管したプロジェクトは組織に属していない「組織なし」のプロジェクトを、エブリー組織に属するよう形への移管となります。 組織なしのプロジェクトの移管は こちらの手順 にて確認できます。 GitHubやAWSの移管と近しいですが、手順書以外の考慮事項は以下でした。 プロジェクトに設定されているIAMの整理 作業者アカウントの権限準備 上記を踏まえて次の手順を移管作業を行いました。 プロジェクトに設定されているIAMの整理 プロジェクトに設定されているIAMは移管時に移管先の組織に属するように設定されてしまうため、事前に全てのIAMを確認して整理します。 作業者のアカウント権限を準備 移行作業を実施する Google Cloud アカウントは以下のような状態にする必要があります。 移管対象プロジェクトのオーナー 移管先の組織の管理者 移管の実施 Google Cloud コンソールからコマンド実行するためのターミナルを開き、移管コマンドを実行します。 // 移行コマンド gcloud beta projects move <移管対象のPROJECT_ID> --organization <移管先のORGANIZATION_ID> // プロジェクトが属しているORGANIZATION_IDを取得するコマンド。移管確認用。 gcloud projects describe <移管対象のPROJECT_ID> --format=json | jq -r ".parent" 注意点 注意点はGitHubリポジトリの移管と同様で、アカウントも一緒に移管されることです。想定しないアカウントが移管先の組織に属する形になることを防ぐため、移管前にIAMの整理を行うことが大切です。 Google Analytics プロパティ の移管 Google Analytics プロパティの移行手順は公式の [GA4] プロパティを移行する 手順にて行いました。 手順の流れは Firebase プロジェクトの移管と同様で、以下のような流れでした。 プロパティに属しているアカウントの整理 作業者のアカウント権限を準備 移行作業を実施する Googleアカウントを以下のように権限設定する必要があります 移管対象プロパティの管理者 移行先のGAアカウントに対する管理者もしくは編集者 移管の実施 Google Analytics コンソール画面から公式の手順に沿って移管を実行することができます 注意点 まず、移管にあたって一つ理解が必要なのは、Google Analytics は GAアカウントに複数のGAプロパティが属する構造となっており、GAアカウントとGAプロパティはそれぞれで権限設定が行えるという点です。 GAアカウントとGAプロパティの言葉の違いを理解した上で、適切にそれぞれのユーザー権限設定を行うこと大事です。 また、注意点ではないですが、移管作業では以下の点について問題ないかどうかをドキュメントから正確に読み解くことが難しかったので、記録として残しておきます。 過去のデータが引き継がれるか 移管の実施はデータ収集に影響がないか これらは問題ありませんでした。過去のデータは引き継がれ、データ収集も影響がないことを確認しました。 ドメインの移管 移管対象のドメインはDoレジで管理されており、エブリーで主に利用しているお名前.comへと移管しました。移管手順は 他者からお名前.comへのドメイン移管 に沿って比較的楽に実施することができます。 作業自体に関しては注意点は特にありませんが、作業に費用が発生するため、注意が必要です。 App Store Connect アプリ の移管 App Store Connect アプリについては移管はこれから実施を予定しており、現在計画立てを行っている段階です。 計画立ての途中ではありますが、現時点で以下のような影響がわかっています。 移管実施に伴うユーザー影響 キーチェーンにデータ保存している場合に参照できなくなる Sign in with Apple でログインできなくなる 譲渡における影響は アプリの譲渡の概要 にて確認できます。 Google Play Console アプリ の移管 Google Play Console アプリについてもこれから移管する予定となっているので、本記事では割愛いたします。 移管作業が完了したらまた具体的な話をお伝えできればと思います。 まとめ 本記事では、システム移管の作業内容と、作業から得られた注意点を紹介しました。 移管するシステムの状態によって具体の作業内容は少しずつ異なってくると思うので、その点を踏まえてご参考にしていただければ幸いです。 最後までお読みいただき、ありがとうございました。

この記事は every Tech Blog Advent Calendar 2024 の 10 日目の記事です。 エブリーで小売業界に向き合いの開発を行っている @kosukeohmura です。 エブリーは ISUCON14 にて ISUポンサーとして協賛いたしました。社に 1 枠の参加確定枠を頂き、僕は社内で きょー と mbook と組んでチーム EveryBitCounts として出場する機会をいただけました。残念ながら最終スコアは 0 と惨敗でしたが、前日までの準備と当日のこと、それから反省について書きたいと思います。 tech.every.tv 前日までの準備 チームの 3 人はいずれも業務で Go を使うバックエンドのエンジニアですが ISUCON の参加や学習経験はありませんでした。前準備として社内の ISUCON 参加経験者を招き、概要の説明を受け、それから準備のための数時間のミーティングを数回組みました。 過去回の競技内容・レギュレーションを確認し、下記の攻略記事を読み合わせたところ、 isucon.net 計測結果を見て、問題を見出す。 比較的簡単に（見える）修正を施す。 改善されたことを確認する。 以上を繰り返すとそれなりの高得点を目指せそうだと捉えました。また上記の中で「計測結果を見て、問題を見出す。」ステップには比較的自信がなかったことから、練習用の t3.micro の EC2 インスタンスを立ち上げ学習を行いました。 具体的に行ったことを記します: GitHub でのソースコード管理 当日用のリポジトリを作成、当日必要となりそうなコマンドを Makefile 化しておく RSA 鍵ペアを生成し設置。EC2 サーバー上で git push などが行えるようにする デプロイ EC2 サーバー上で git pull した後サーバーアプリをビルドし、各種サービスの再起動までを 1 コマンドで行えるように MySQL スロークエリの表示 スロークエリログの有効化、しきい値の設定方法メモ mysqldumpslow の結果の読み方の把握 alp での NGINX のアクセスログの集計 コマンドの実行、結果の読み方の把握 -m オプションを使っていい感じに結果を束ねて表示する pprof の使い方 プロファイリング方法、プロファイリング結果の読み方の把握 問題の見出し方 計測結果から変更対象の箇所を特定するまでどのような思考を経るかを話し合う 当日 チーム全員起床に成功しオフラインで集まり作業しました。時系列でざっと流れを書きます。 開始〜12:00 まず技術要素(MySQL, NGINX, go-chi/chi, jmoiron/sqlx)を軽く確認し、公開されたドキュメントを読み込みました。この間に 1 人はソースコードを Git 管理したりベンチマーク計測したりと開発準備を行いました。結果、開始 1 時間以内には変更をデプロイできるようになり、チームのうち 2 人はドキュメントを一通り把握した状態となりました。 その後 mysqldumpslow や alp での集計を行いつつ、以下 3 つの問題に目をつけて 3 人でそれぞれ分担・着手しました。 GET /api/owner/chairs で椅子をリストアップするクエリが重いこと GET /api/app/nearby-chairs での処理が遅く、中身を見ると椅子全件取得後に椅子とライドでの多重ループで O(N * M) なクエリ発行がされていること GET /api/internal/matching の処理内容がランダムかつ椅子 1 つのみに対しての処理であり、適切な椅子とライドのマッチングができずスコア算出に大きく影響を及ぼしそうなこと 前日までの準備の甲斐あって、デプロイや計測ツールの準備については問題なく行えました。また問題箇所の特定についても(通知周りの問題を後回しにしてはいますが)おおよそ的を得た内容だったと思います。 この時点のスコア: 900 前後 (初期状態) 12:00〜14:00 昼食を取りつつ、それぞれの問題の解消に向けて処理を読み改修方針を考える時間でした。それぞれが別々の問題に取り組んでいるので会話もまばらになります。 僕は定期実行される GET /api/internal/matching でのマッチング処理の改善を担当していました。表には出ない Endpoint であり、マッチングできさえすれば好きに変えて良い(Endpoint 自体廃止しても良い)とのことで、いろんなことを考え方針策定に時間をかけていました。具体的には下記のような事を考えていました。 マッチングの間隔: 初期状態では 500ms ごとの処理だが、この間隔はどの程度椅子の稼働率に影響があるのか？ ユーザーからの評価の上げ方: 高い評価を得るほどにユーザーが増え結果スコアも伸びるが、距離の長いライドに遅い椅子がマッチすると到着が遅くなり評価が得られないということになるか。 むしろ長距離ライドに対しては速い椅子が確保できるまでマッチングを控えたほうが平均の評価としては上がるのか？ とはいえマッチングまでの時間も評価対象だし、、むしろ長距離過ぎるライドは無視するのが得策か？でも緯度経度に制限がない以上どこからを長距離としてもいいかわからないな、、？ 全体効率の最適化: 椅子の性能(スピード)にかかわらず片っ端から近い順にマッチングさせたほうが全体としては効率が良くなるか？ 速い椅子をフル稼働状態にすることを優先し、遅い椅子の稼働は控えめにしたほうが高効率か？ 結果、考えても良くわからなくなってきたので、メンバーと相談し マッチング処理の定期実行を廃止。ライドが新規発生した際と評価完了した際、それとオーナーにより新しい椅子が有効化された際にそれぞれマッチング処理を実行するようにする マッチング間隔の短縮は、ライドのマッチング時間短縮と椅子の稼働率向上それぞれに寄与する。よって短いに越したことはないだろうということで マッチングの際、速い椅子を遅い椅子より優先的に使い、また乗車位置に近い椅子を遠い椅子より優先的に使うように 評価の上げ方は細かくは非公開であり、また全体効率も考えてもわからないと判断し一旦の決め。試行錯誤前提のロジック と方針を立てて実装を開始しました。この時点ではスコアは伸びていないものの、まっとうに方針を決められたことで、これからしっかり実装すればスコアを爆上げできるとと考えていました。 この時点のスコア: 1,000 前後 14:00〜16:00 立てた方針に沿って実装を行いました。変更箇所が思ったより多く、見立てより時間がかかりました。 この時間帯にはぼちぼち他のメンバーの修正が完了し、デプロイが行われはじめました。しかしデプロイしても期待した上がり幅が得られなかったり、FAIL し revert したりしている様子でした。 このとき、開発フロー面での課題が明らかになってきました: 変更後の検証作業が直列でしか行えない 3 人で作業しているにも関わらず、共通の Makefile などを main ブランチにコミットした後、そのままの成り行きで全員 main ブランチを使っている ブランチと同様に、3 台のマシンが与えられたにも関わらず 1 台のみを 3 人で共用している デプロイ環境整備を行ったメンバー 1 人のみが成り行きでサーバー上での作業役となり、他のメンバーのデプロイ作業の肩代わりやデプロイ順番待ちの管理をする羽目になっている ベンチマーカーが FAIL した際に直接の原因 (何の Assert に失敗したのか) はわかるものの、根本原因を知る手段 (エラーログを見るなど) がなく確実な修正ができない この時点で開発フローを変えようという気にはなりませんでしたが、開発フローの問題は最後までつきまといました。 細かな経緯は忘れましたが、主に ride_statuses テーブルにインデックスが貼られたことにより、スコアは倍増しました。 この時点のスコア: 2,120 16:00〜終了 16:00 過ぎに僕の担当していたマッチング処理の修正が完了しました。僕としてはいち早く適用しスコア爆上げと行きたかったところですが FAIL し、その原因が修正できず revert しました。 サーバーを全員で 1 台しか使っておらず、他の修正のデプロイ＆ベンチマーカー実行の試行錯誤が盛んに行われていたことから、僕は担当していたマッチング処理の修正適用を諦め、せめてサーバーと RDB のマシンを分けようとしましたが、間に合いませんでした。 終了前の数十分は焦りが増す中でベンチマーカーが FAIL を示すようになり、 git reset で変更を切り戻しては混んできたベンチマーカーに Enqueue し、祈り、FAIL し絶望するという辛い時間を過ごし、終了時間を迎えました。 最終スコア: 0 悲しい結果となりましたが、以降記憶が新しいうちに振り返ってみます。 良かったところ 準備の成果を十二分に発揮できました。変更を Git 管理し反映できる状態をスムーズに作れ、また alp 等を使った問題特定も早期かつ妥当に行うことができました。 反省 圧倒的素振り不足 一度でも本番相当の演習を行っておけば気付けるような開発フローの問題が露呈し、クリティカルな敗因となりました。社内で一番良い成績を取った別チームのメンバーも「問題を何度も解いた」と書いてますし、全員揃った状態実践を想定した演習を一度でも行っておくべきでした。 tech.every.tv パフォーマンス改善には改修を伴う 何を当たり前のことと思われるかもしれませんが、ISUCON の勘所は問題の特定だと捉え、それさえ正しくできればその後の修正は普段の開発業務の延長であろうと高をくくっていました(これはチーム全体というより僕だけかもしれません)。 本番では問題特定には概ね成功したものの、それを解消するための変更に失敗しました。普段の開発ではローカルでの開発環境があり、気軽に単体テストを書き CI/CD に反映を委ねます。それがない状況でどのように改修を行うのかを真面目に検討できていませんでした。 担当の割り振り方 これは結果論かもしれませんが、一見関係の薄そうに見える処理についても元をたどると共通の問題に当たったりします。今回(気軽に相談は挟むものの)ハッキリと問題ごとに担当を分け作業をしたので、多くの表面的な問題の背後に存在する根本的な原因について相談し共通の意思決定に持っていくことができませんでした。分担するにしてもその単位を細かくするなど担当の割振りは改善の余地があると考えています。 具体的には chairs テーブルに最新の位置情報やマッチング状態が存在しないことが、 rides や ride_statuses , chair_locations テーブルとの JOIN やループ処理を発生させパフォーマンス劣化につながるという事態が複数箇所で見られたはずで、そこはチーム共通で指針を立てられたら良かったと思います。 ドキュメントを全員で読み合わせなかった 最初にデプロイの仕組みを整備したメンバーは、その後クエリのチューニング作業を担当し、そのまま実作業に入りました。その結果、そのメンバーはスコアの算出方法すら後半に知るような事態が起こりました。 複数人で協力して作業するにあたり、まずドキュメントを読み合わせ、不明点を解消し、何を目指していくのかの認識をざっと揃えておくことがその後の作業のスムーズさに大きく寄与すると感じました。 さいごに 反省点はたくさんありますが、ISUCON14 に楽しく参加することができました。他の方のリポジトリやブログ記事を読みたいと思っていますが、全然追いついていません。 またこの場を借りて運営の方々への感謝を申し上げます。Discord や公式ブログでのアナウンスもとてもわかりやすかったですし、当日のライブ配信も楽しく観覧しました。出題内容やドキュメント、当日の Dashboard も良くできており、ワクワクしながら競技に参加することができました。ありがとうございました。 当日の問題やドキュメントを含むリポジトリが公開されており、docker compose でも動かせるようですので時間を見つけてまた触ってみようと思います。 github.com エブリーでは、ともに働く仲間を募集しています。不甲斐ない結果でしたが、少しでもエブリーに興味を持っていただけた方は、一度カジュアル面談にお越しください！ corp.every.tv

この記事は every Tech Blog Advent Calendar 2024 9 日目の記事です。 はじめに こんにちは。DELISH KITCHEN開発部の村上です。 DELISH KITCHENでは、これまでの『レシピ動画アプリ』から『AI料理アシスタント』を目指すべく、これまで以上にAI領域に力を入れています。詳しくはこちらにも記載があるので、ぜひご覧ください。 AI/LLMでtoC向けサービスはどう変わるのか？『DELISH KITCHEN』は、「レシピ動画アプリ」から「AI料理アシスタント」へ このAI活用は社内での業務改善にも進んでおり、直近でOpenAI APIを用いた社内システムの開発をする機会がありました。その中で今回はVercelの AI SDK を使う機会があったのでAI SDKを用いたストリーミング可能なUIをwebアプリケーション内で実現する方法を紹介します。 AI SDKとは VercelのAI SDKはAI/LLMを用いたwebアプリケーション開発を支援するためのツールです。AI/LLMを用いた開発ではOpenAI, Claudeなど外部APIへの繋ぎこみやチャットUIの実装、チャット履歴の保存、ストリーミング機能、RAGの利用などの機能が求められたりしますが、これを全て自分で開発しようと思うと、たとえwebフレームワークを使っていてもかなり手間がかかってしまいます。AI SDKを利用することでこうした実装工数を削減し、より周辺の機能開発に時間を割くことができます。 現状AI SDKは以下の3つから構成されています。 AI SDK Core テキスト生成、構造化オブジェクトの生成、LLM（大規模言語モデル）を使用したツール呼び出しを行うためのプロバイダーに依存しない統一APIの提供 AI SDK UI チャットやその他ユーザーインターフェースを構築するためのツールの提供 AI SDK RSC React Server Components (RSC) を使用してユーザーインターフェースをストリーミングする機能。※現在は実験的な開発段階。 AI SDKは同じ開発元から出ているNext.jsはもちろんNuxtやSvelteなど他環境への対応もしていますが、AI SDK RSCはNext.jsのApp Routerだけをサポートしていたりするので、環境別で何が使えるかは公式を参照するのがおすすめです。 https://sdk.Vercel.ai/docs/getting-started/navigating-the-library#environment-compatibility AI/LLMを用いたアプリケーションにおけるストリーミング機能 特にLLMを用いたwebアプリケーション開発をしていく場合、開発上ケアしておきたいポイントはいくつかありますが、その一つにストリーミング機能があります。 まず、単純な一問一答的なものを実現しようと思っても質問内容や回答によってはAPIでLLMを用いて回答を生成する段階でその出力までユーザーに待ち時間が発生してしまいます。さらに単純な1回のAPI呼び出しだけで終わればいいですが、多くの場合では複数のAPI呼び出しや処理のステップを経て、出力結果を作っていくのでその待ち時間はユーザー体験として無視できないものになってきます。 そこで身近なところであれば、ChatGPTでも全ての回答を生成し終わる前に回答の出力が段階的に行われ、ユーザーが体感する待ち時間を軽減していると思いますが、出力や処理の途中でもユーザーにフィードバックできるようなストリーミング機能が求められます。 AI SDKではAI SDK RSCの中でその機能をサポートしているので以降ではいくつかの種類に分けて機能を紹介していきます。 テキストの出力結果をストリーミングで表示する Server Server側ではまず createStreamableValue でServerからClientにストリーミングで送るためのデータの格納先を準備し、 streamText を使ってOpenAI APIなどProviderからストリーミングされた出力結果で更新します。 'use server' ; import { streamText } from 'ai' ; import { openai } from '@ai-sdk/openai' ; import { createStreamableValue } from 'ai/rsc' ; export async function generate ( input : string ) { const stream = createStreamableValue( '' ); ( async () => { const { textStream } = streamText( { model : openai( 'gpt-4o-mini' ), prompt : input, } ); for await ( const delta of textStream) { stream.update(delta); } stream.done(); } )(); return { output : stream.value } ; } Client Client側ではServer側が createStreamableValue で生成されたデータを readStreamableValue を用いることで簡単に読み取ることができるので受け取ったものを処理するhooksを定義します。 import { StreamableValue, readStreamableValue } from 'ai/rsc' import { useEffect, useState } from 'react' export const useStreamableText = ( content : string | StreamableValue < string > ) => { const [ rawContent , setRawContent ] = useState( typeof content === 'string' ? content : '' ) useEffect(() => { ;( async () => { if ( typeof content === 'object' ) { let value = '' for await ( const delta of readStreamableValue(content)) { if ( typeof delta === 'string' ) { setRawContent((value = value + delta)) } } } } )() } , [ content ] ) return rawContent } 表示するコンポーネント側ではServerからの結果を上記で定義した useStreambleText を使って表示するだけで簡単に実現できます。 'use client' ; import { useState } from 'react' ; import { generate } from '@/lib/actions' ; import { useStreamableText } from '@/lib/hooks' ; import { StreamableValue } from 'ai/rsc' ; export default function QuestionAnswer () { const [ answer , setAnswer ] = useState< string | StreamableValue < string >>( '' ); return ( < div > < button onClick = { async () => { const { output } = await generate( '簡単に作れるお弁当レシピを教えてください。' ); setAnswer(output); } } > Ask </ button > { answer && < AssistantMessage answer = { answer } /> } </ div > ); } export function AssistantMessage ( { answer , } : { answer : string | StreamableValue < string > ; } ) { const text = useStreamableText(content); return ( < div > { text } </ div > ); } オブジェクトの出力結果をストリーミングで表示する Server Server側では、同じように createStreamableValue を利用するところは同じですが、ここではオブジェクト形式の出力に対応する streamObject を利用して、プロバイダーから逐次送信される構造化されたデータで更新します。AI SDKではOpenAI APIの Structured Outputs にも対応しているので、 structuredOutputs パラメーターで指定します。 'use server' ; import { streamObject } from 'ai' ; import { openai } from '@ai-sdk/openai' ; import { createStreamableValue } from 'ai/rsc' ; import { z } from 'zod' ; export async function generateObject ( input : string ) { const stream = createStreamableValue( { answer : '' , quotation_links : [] } ); ( async () => { const { objectStream } = streamObject( { model : openai( 'gpt-4o-mini' , { structuredOutputs : true , } ), schema : z.object( { answer : z.string(), quotation_links : z.array( z.object( { title : z.string(), link : z.string(), } ) ), } ), prompt : input, } ); for await ( const delta of objectStream) { stream.update(delta); } stream.done(); } )(); return { output : stream.value } ; } 上記の例では、 objectStream には常に { answer: '', quotation_links: [] } の形式が保たれた形で随時そのテキスト情報や配列要素が追加されていくので、特に複雑な加工処理をすることなく、Client側で利用可能な状態になります。 Client Client側では、テキストをストリーミングする時と同じように readStreamableValue を使用してストリーミングされたオブジェクトを受け取り、動的に更新します。 import { StreamableValue, readStreamableValue } from 'ai/rsc' ; import { useEffect, useState } from 'react' ; type AnswerObject = { answer : string ; quotation_links : { title : string ; link : string } [] ; } ; export const useStreamableObject = ( content : AnswerObject | StreamableValue < AnswerObject > ) => { const [ rawContent , setRawContent ] = useState< AnswerObject | null >( typeof content === 'object' && !( 'subscribe' in content) ? content : { answer : '' , quotation_links : [] } ); useEffect(() => { ( async () => { if ( typeof content === 'object' && 'subscribe' in content) { let value: AnswerObject | null = null ; for await ( const delta of readStreamableValue(content)) { if ( typeof delta === 'object' ) { setRawContent((value = { ...value, ...delta } )); } } } } )(); } , [ content ] ); return rawContent; } ; 定義した useStreamableObject を使用して、ストリーミングで受け取ったオブジェクトデータを表示します。 'use client' ; import { useState } from 'react' ; import { generateObject } from '@/lib/actions' ; import { useStreamableObject } from '@/lib/hooks' ; import { StreamableValue } from 'ai/rsc' ; type AnswerObject = { answer : string ; quotation_links : { title : string ; link : string } [] ; } ; export default function ObjectDisplay () { const [ answer , setAnswer ] = useState< AnswerObject | StreamableValue < AnswerObject > | null >( null ); return ( < div > < button onClick = { async () => { const { output } = await generateObject( '環境問題に関する最新のレポートを教えてください。' ); setAnswer(output); } } > Ask </ button > { answer && < AssistantObjectMessage answer = { answer } /> } </ div > ); } export function AssistantObjectMessage ( { answer , } : { answer : AnswerObject | StreamableValue < AnswerObject > ; } ) { const data = useStreamableObject(answer); return ( < div > { data ? ( < div > < p > { data.answer } </ p > < ul > { data.quotation_links. map (( item , index ) => ( < li key = { index } > < a href = { item. link } target = "_blank" rel = "noopener noreferrer" > { item. title } </ a > </ li > )) } </ ul > </ div > ) : ( 'Loading...' ) } </ div > ); } オブジェクト形式のストリーミングのメリットは上記のようにそれぞれ異なる要素に対して個別のスタイリングや処理を行うことができる点です。今までのテキストでのストリーミングは表現方法が限定的になるか、やろうと思ってもテキスト情報を変換するような複雑な処理をしないといけず不安定になってしまいますが、オブジェクト形式で受け取れることによって、アプリケーションによって独自の見せ方が可能になり、自由度が上がりました。 処理に合わせてUI自体をストリーミングで表示する Vercelではテキストやオブジェクトだけではなく、UI自体をストリーミングすることができます。この機能を使うことでテキストやオブジェクトだけではなく、LLMの回答結果をUIで表示することも可能になります。 今回は、AIアプリケーションでありがちな回答を出力するまで進捗を表示するUIを例に紹介します。 一番最初に利用した AssistantMessage と以下の WorkflowProgress コンポーネントをServerとClientでやりとりします。 進捗を表示するWorkflowProgressコンポーネント export function WorkflowProgress ({ workflowSteps }) { const completedSteps = workflowSteps . filter (( step ) => step . status === 'completed' ) . length ; const totalSteps = workflowSteps . length ; const progressValue = ( completedSteps / totalSteps ) * 100 ; return ( < div className = "p-4 bg-gray-100 rounded-lg shadow" > < h3 className = "font-semibold text-lg" > Progress </ h3 > < progress value = { progressValue } max = "100" className = "w-full mb-2" ></ progress > < ul > { workflowSteps . map (( step ) => ( < li key = { step . id } className = "mb-2" > < strong > { step . name } : </ strong > { step . status } </ li > ))} </ ul > </ div > ) ; } Server サーバー側では createStreamableUI を利用して、ストリーミングするコンポーネントを追加、更新することができます。今回はAI SDKの機能紹介がメインのため、step毎の具体的な処理については省略します。 'use server' ; import { streamText } from 'ai' ; import { openai } from '@ai-sdk/openai' ; import { createStreamableUI } from 'ai/rsc' ; import { WorkflowProgress } from '@/components/WorkflowProgress' ; import { AssistantMessage } from '@/components/AssistantMessage' ; export async function generateWithSteps ( input : string ) { const workflowSteps = [ { id : 'step1' , name : '質問を解析中' , status : 'in-progress' , tasks : [] } , { id : 'step2' , name : '探索方法を検討' , status : 'pending' , tasks : [] } , { id : 'step3' , name : '関連データを取得' , status : 'pending' , tasks : [] } , ] ; const displayUI = createStreamableUI( < WorkflowProgress workflowSteps = {workflowSteps} /> ); ( async () => { // Step 1: 質問を解析 await new Promise (( resolve ) => setTimeout (resolve, 2000 )); workflowSteps[ 0 ]. status = 'completed' ; workflowSteps[ 1 ]. status = 'in-progress' ; displayUI.update( < WorkflowProgress workflowSteps = {workflowSteps} /> ); // Step 2: 探索方法を決定 await new Promise (( resolve ) => setTimeout (resolve, 2000 )); workflowSteps[ 1 ]. status = 'completed' ; workflowSteps[ 2 ]. status = 'in-progress' ; displayUI.update( < WorkflowProgress workflowSteps = {workflowSteps} /> ); // Step 3: データを取得 await new Promise (( resolve ) => setTimeout (resolve, 2000 )); workflowSteps[ 2 ]. status = 'completed' ; displayUI.update( < WorkflowProgress workflowSteps = {workflowSteps} /> ); // 結果を生成 const { textStream } = streamText( { model : openai( 'gpt-4o-mini' ), prompt : input, } ); let generatedText = '' ; for await ( const delta of textStream) { generatedText += delta; // 進捗状況のコンポーネントから回答結果のコンポーネントに変える displayUI.update( < AssistantMessage answer = {generatedText} /> ); } displayUI.done(); } )(); return { display : displayUI.value } ; } Client クライアント側では、定義したアクションを呼び出し、その結果をそのまま表示することで簡単に動的なUIが作れます。実際の挙動はまず最初にProgressを表示し、回答結果がLLMから出力され始めるとProgressは非表示になり、回答が生成されていくような形になります。 'use client' ; import { useState } from 'react' ; import { generateWithSteps } from '@/lib/actions' ; export default function DynamicProgressDisplay () { const [ display , setDisplay ] = useState< React.ReactNode | null >( null ); return ( < div > < button onClick = { async () => { const { display } = await generateWithSteps( '環境問題に関する最新のレポートを教えてください。' ); setDisplay(display); } } className = "mb-4 px-4 py-2 bg-blue-500 text-white rounded" > Ask </ button > { display } </ div > ); } 最後に 今回はVercelのAI SDKを使って、いくつかの手法でストリーミング可能なUIをアプリケーション上で実装する方法を紹介しました。この他にも会話履歴の保存やその状態の管理を簡単に扱えるように豊富な機能が提供されています。AI SDK RSCはまだベータ的な位置付けですが、webでLLMを使ったアプリケーションをする際には比較的簡単にリッチなアプリケーションが作れるので、ぜひ社内ツールや簡単に動くものを作りたい場合にはVercelのAI SDKを使ってみてください。 冒頭でも紹介したようにDELISH KITCHENではこれまでの『レシピ動画アプリ』から『AI料理アシスタント』への変化を起こそうとしています。ぜひ、この取り組みに興味を持った方は一度カジュアル面談でお話しましょう！ corp.every.tv

はじめに この記事は every Tech Blog Advent Calendar 2024 の8日目の記事です。 こんにちは、リテールハブ開発部でバックエンドエンジニアをしています。 実はまだ転職して２ヶ月のため、まだまだわからないことだらけですが、 現在、Laravelを利用したAPI開発をしていて、その中でPestを利用した単体テストを行なっています。 前職のAPIテストは結合テストメインで行っていて、単体テストはほとんど行なっていなかったのですが、 検証データの準備や継続的なテストにおいて課題がありました。 今回LaravelもPestも初めて利用するのですが、今回行った単体テストを経験する中で、 これを利用すれば以前感じていた課題が解決できるかもしれないと思いました。 本ブログでは、課題解決できると思った点や実際に単体テストを経験して感じたことなどをお伝えできればと思っています。 同じ課題感をお持ちの方やテストに興味のある方はぜひ読んでいただけると嬉しいです。 今回はLaravel、Pestを例にしたお話にはなりますが、他のフレームワークでも同様のケースは多いのかなと思っています。 前職で行っていたAPIテストで感じていた課題 私が今まで行っていたAPIのテストは基本的にはDBにテストデータを投入し、 データと各パラメーターによって変わるAPI結果を検証する結合テストがメインでした。 できる限りのパターンを網羅し、各ロジックが検証できるようデータ準備をしていたりもしました。 その後はSeleniumなどを使用してテストパターンを登録して自動テストなども行なっていました。 しかし、以下のような課題がありました。 「データ整備の課題」 検証用のデータをDBにあらかじめ入れないと検証できない DBデータの最新化や別件の対応などで内容が変わったりと検証データの担保がしにくい 検証データが不足していて意図した結果が得られていないケースがある 外部要因による結果を利用するテストが行いにくい 「検証データの信頼性の課題」 自動テストの実行でエラーが発生した場合、検証データによるものかロジックによるものかの特定に時間がかかる 上記課題は、DBデータを固定化したり、検証用DBを別途作ったりして回避しようとしていましたが、 やはりそれだけではデータパターンの担保や変更されないことの保証はうまくできていないことがありました。 特にデータ担当が別部署だったりするとなお難しい状況でした。 Laravel、Pestを利用したテストについて LaravelやPest以外でも同じような機能はあると思いますが、 今回のテストでは、LaravelのModel、Factoryを利用して、コード記述によって任意のテストデータを作成(DB投入)し、 Pestを使って各テストケース毎に独立した検証ができるテストを経験しました。 簡単ではありますが、単体テストのメリットとデメリットを記載してみました。 メリット メソッド単位で１つ１つ検証することができる ケース毎に独立したテストができるため、環境やデータ状況に左右されない Mockを利用して仮想的な結果を混ぜることで、データ整備だけでは難しいケースにも記述次第で対応できる デメリット テストケースが増えるほどコストも増加する 機能仕様の変更などをすると単体テストにも影響が大きくあり変更負荷が高い 当然ではありますが、今回行ったような単体テストは、１ケースずつ細かく行うため工数はどうしてもかかるなと思いました。 様々なケースを考えながら記述もするので単純作業というわけでもなく、 そもそもテストコードが間違えていたら意味もないため、手早くこなすのも厳しそうです。 また、最終的にはAPIの機能検証も別途必要なため、複合して行う必要があります。 課題が解決できると思った点 上記だけでは、やはり工数の問題などで優先度を下げて対応してしまいそうではありますが、 今回自分の中で非常に使えそうと思ったのは、 指定のテーブルに任意のデータをコード記述により固定で入れられ、検証したいデータパターンを柔軟に記述することができる点 簡単にテストデータを作る仕組みがあり、複数データ作成の手間も省ける点 １テストケース毎に他のデータの影響を与えず独立して実行することができる点 かなと思いました。 簡単な例ですが、以下の要件に合わせたPestのサンプルコードがあります。 getListメソッドのテストを行いたい APIリクエストからのパラメーターはidのみ status引数の値によって分岐があり結果が変わる statusはAPIのリクエストからは指定できず、外部要因によって決定される コードの記述のみでデータ投入、メソッド実行、結果比較を行うことができます。 Pest記述のサンプルコード <?php namespace Tests\Unit\Sample; // ここにTest前の処理を記述 beforeEach ( function () { $ this -> sample = new Sample () ; }) ; // ここにTest後の処理を記述 afterEach ( function () { }) ; // １テストケースずつ以下の形式で作成していく it ( '指定IDとステータスがokの場合一覧を検索できること。' , function () { // 検索したいパラメーター $ id = 1 ; $ status = 'ok' ; // statusはAPIのパラメータからは指定できない // 任意のテーブルにデータを入れる機能 // この記述によりデータがテストケース毎に固定できる。 SampleTable :: factory () -> create ( [ 'id' => 1 , // primary key 'status' => 'ok' , 'name' => 'サンプル1' , ] ) ; SampleTable :: factory () -> create ( [ 'id' => 2 , // primary key 'status' => 'ok' , 'name' => 'サンプル2' , ] ) ; // id, statusから一覧を取得するメソッドのテスト $ result = $ this -> sample -> getList ( $ id , $ status ) ; // 返却内容は以下の記述でチェックできます。 // 結果が何件返ってきているかをチェック expect ( $ result -> count ()) -> toBe ( 2 ) ; // 結果のnameが正しいかチェック expect ( $ result [ 0 ][ 'name' ]) -> toBe ( 'サンプル1' ) ; expect ( $ result [ 1 ][ 'name' ]) -> toBe ( 'サンプル2' ) ; }) ; // ２ケース目 it ( '指定IDは合っていてもステータスがok以外のためヒットしないこと。' , function () { // 検索したいパラメーター $ id = 1 ; $ status = 'test' ; // statusはAPIのパラメータからは指定できない // 任意のテーブルにデータを入れる機能 SampleTable :: factory () -> create ( [ 'id' => 1 , // primary key 'status' => 'ok' , 'name' => 'サンプル1' , ] ) ; SampleTable :: factory () -> create ( [ 'id' => 2 , // primary key 'status' => 'ok' , 'name' => 'サンプル2' , ] ) ; // id, statusから一覧を取得するメソッドのテスト $ result = $ this -> sample -> getList ( $ id , $ status ) ; // 返却内容は以下の記述でチェックできます。 // 結果が何件返ってきているかをチェック expect ( $ result -> count ()) -> toBe ( 0 ) ; }) ; <?php class Sample { public function getList ( int $ id , string $ status ) : Collection { $ query = SampleTable :: query () -> where ( 'id' , $ id ) ; if ( $ status == 'ok' ) { $ query -> where ( 'status' , $ status ) ; } else { $ query -> where ( 'status' , 'ng' ) ; } return $ query -> get () ; } } 上記、２つのテストケースがありますが、 1つ目はid=1, status=okでデータが取得できるケース 2つ目はid=1, status=testでデータが取得できないケース どちらのケースもid=1、id=2と入れていますが、各テストは独立しているのでデータの重複や状態を考慮する必要がなく、 自由なデータを入れることができます。 また、サンプル内の「status」はAPIパラメータ指定ではなく、何らかの条件で決まる場合、 外部APIの結果などの別要因で決まる値 他のデータの組み合わせで決まる値 上記のようなケースでも単体テストでは値を固定してそれぞれのパターンを簡単に試すこともできます。 前職で行っていたテストではこういった外部要因で決まった値によって変わるテストが、 データ調整や外部APIの結果を無理やり変えたりと大変苦労していました。 また、サンプルでは非常にシンプルなテストですが、 複数使用したテーブルやテーブルの項目が増える場合 いろんな条件によって検索する値が変わる場合 通常は起こり得ないデータを入れないとテストできない場合 など複雑化していくケースの場合、 あらかじめ検証したいデータを投入しておく API検証時に各パラメーターのパターンを変えて試す だけではどうしても漏れが起きてしまったり、複雑なケースのデータ投入の限界や他のテストケースに影響を与えないデータ考慮などが必要になってきてしまいます。 また、もしエラーが発生した場合にそれが検証データによるものか、ロジックによるものかの判断もより難しくなってきます。 これが１テストケースごとで独立したデータ、テストであれば、 難しいデータパターンもコードに１度書いてしまえば、同じ検証、同じ結果が担保できる 各ケースが様々な記述をしても、他のケースに影響を与えない 　（データパターンも自由に変更可能） ある時からエラーが発生するケースを検知した場合でもデータによるものではなくロジックによるものと判断しやすい このメリットを利用することができれば、今まで課題だった問題が解決できそうと思ったところです。 実際に使ってみて感じたところ ただ今回のような単体テスト実行は、前職のプロジェクトでは一時的に導入はしたものの、 前述の通り、 対応コストが多く掛かってしまう 機能変更した場合の修正コストも都度必要 通常のプログラムとは別の記述方法が必要 が、やはり大きく影響し、最初は導入しても徐々に対応しなくなってしまうケースがほとんどでした・・・。 しかし、今までのようにすべてやらなくなるのではなく、 一部だけでも取り入れる方法はメリット部分を大きく活かせそうかなと思いました。 この一部だけというのが、また別の課題も生みそうではありますが、 検証しにくいデータパターンだが重要なケース データの変化が起きやすく安定した検証がしにくいケース 一部の重要なロジックだけでも固定データと合わせて動作保証を担保したいケース よく利用されるもの、共通のケース など もちろん現在のプロジェクトで実施しているようなできる限り網羅するのが良いと思っていますが、 それぞれのプロジェクトの状況によっては、上記のような必要な部分だけに今回のようなテストコードのコストをかけるだけでも大きな効果があるのではないかと思いました。 最後に 抽象的な表現でわかりにくい点もあったかと思いますが、 データパターン検証、安定した検証に今回のような単体テストも有効そうであることは伝わりましたでしょうか。 今回のような単体テスト方法はしばらく触れてきていなかったのもあり、大変勉強になりました。 今後のテスト検証の際にぜひ少しでも参考にしていただければ幸いです。 最後までお読みいただき、ありがとうございました。