ENECHANGE Developer Blog

こんにちは、エンジニア採用担当の村上です！先日、STORESさん、マネーフォワードさん、ENECHANGEの3社から学生インターンに登壇いただき、「【Ruby】テックベンチャー3社のインターン生が語る！学生エンジニアの本音トーク」というテーマのオンラインイベントを開催しました。その中での発表が非常に素晴らしかったので、皆様にもレポートをお届けします。社会人と遜色ない高いレベルの業務に取り組み、スキルを磨かれており、またインターンとして働くことで「社会人として働く」ことに対する解像度も非常に高く持っている方ばかりで、私も非常に刺激を受けましたのでぜひ最後までご覧ください！Rubyを知らない私が STORES に惹かれた理由最初に登壇してくださったのは STORES 株式会社でインターンをされている大学院修士2年の大塚真太朗さんです。大塚さんはインターンを始めるまでRubyを使ったことがなかったとのこと。STORES との出会いのきっかけは就職活動に向けてなんとなく参加した1on1イベント。STORES はイベントのスポンサーなどもしているため、名前をなんとなく聞いたことがあり、さらに1on1ではこれまでの学習・開発の深い話で盛り上がることができたため、会社や人に対しての好感を抱き、ジョインすることを決めたそうです。最初に任されたタスクは、なんとなくしかわからない状態から始まりました。「CIとして行っている、Railsのassets:precompileが遅いSprocketsから依存しているexecjsを速くできるか調査してほしい」よく分からないながらも、「Sprocketsを起点に調査し、assets:precompileのタスクを速くする」という漠然としたイメージを持ち、取り掛かりました。ここでまずは未経験のRubyの勉強が必要になりました。Rubyの学習は、他の言語でも同じ動作のある言葉や、Ruby特有の動作、並列処理の癖など、これまで使ったことのある技術の知識をベースに違いを理解しながら進めたそうです。Rubyは日本語のドキュメントや記事が豊富、仕様もシンプルなのでスムーズにキャッチアップができたとのこと。その後内部調査をする中で、並列処理が可能な部分を発見し、ローカル環境で処理時間を40%削減することに成功。実運用に採用するのは一旦見送ったそうですが、Rubyのキャッチアップができていることを実感しました。任された課題については、execjsというRubyからJavaScriptのコードを実行するgemの、ランタイムをより速いものに差し替えることで解決できるのではないかと見立てました。速いランタイムとして案に上がったExecJS FastNodeを検討したところ、あまり改善が見込めないと判断。その原因となる並列性能の悪さを解消するためにランタイムを自作したそうです。その後レビュー等を実施し、実運用を開始。assets:precompileのタスクにかかる時間は従来から20%削減することに成功したとのこと。大塚さんはRuby未経験ながらも、公開されている豊富な情報に加え、社内の充実したサポート体制により無事業務を遂行できました。インターンを経て、個人開発では触れられない大規模で高品質なコードと、その開発体制を知ることができたと感じているそうです。マネーフォワードで学んだRuby on Railsの乗りこなし方次に登壇したのは株式会社マネーフォワードでインターンをしている大学院修士2年の髙橋光さんです。マネーフォワードとの出会いは2週間のサマーインターン。それまでは競技プログラミングの経験はあった一方で開発の経験はなく、参加できるインターンも限られる中でたまたま見つけたのがマネーフォワードさんのインターンだったそうです。髙橋さんはそのインターンで初めて、Rubyや開発に触れたとのこと。実際のインターンの業務ではマネーフォワードクラウド会計の既存機能の改修や速度改善にメインに携わっていたそう。タスクの大きさは1日で終わるものから、人を巻き込んで数ヶ月かかるものまで様々でした。こうしたインターンの業務経験での学び、気づきや心掛けたことを3つシェアしてくださいました。1.Ruby on Railsとの付き合い方開発に初めて携わって特に実感したのはコードについて、「書く力」より「読む力」の方が強く求められるということ。現状のコードを理解できれば、実装は単純だったりAIに任せられたりするため、そのように感じ、「読む力」を鍛えるため、普段からコードを批判的に読むように意識していたそう。Ruby on Rails独特のファイルの連携や、データベースへのアクセスなどでコードを追うのに苦戦したそうですが、メンターとの壁打ちも積極的に行いながら読む力を鍛えているそうです。2.タスクの進め方事前の業務のイメージは設計書を読んでプログラミングをするものだったそうですが、実際は与えられるのは課題のみ。解決の手段やタスクの進め方は自分次第で任せてもらったそうです。髙橋さんは、まず解決すべき問題を深掘りして分析し、その問題をどうしたら解決できるのかを検討、さらに今後はどのように運用できると良いのか、を順に追いながら「あとはプログラミングするだけ」になるように進めるとのこと。3.再現性を持たせる最後に、コードを読む力の強化やタスクを進めるにあたり、一番意識していたのは「再現性を持たせること」。「メンターの手を借りればできる」ではなく自立して一人前になれるように、メンターとの壁打ちを欠かさず行なっていたそうです。具体的にはまずは自分の思考をアウトプット、そこにメンターからのフィードバックをもらうことでメンターの思考フレームを身につけられるように話し合いを行なっているとのことでした。この発表から、社員を巻き込みながらインプット・アウトプットを精度高く回している髙橋さんの学びの姿勢に感銘を受けました。私のENECHANGEでのインターンシップと今後最後に登壇したのはENECHANGE株式会社 インターン生で大学2年の山田直生さん。山田さんは小学生の時からプログラミングをはじめ、Rubyにも触れていたそう。高校生の時には「中高生国際Rubyプログラミングコンテスト」で最優秀賞を受賞。大学生になってからはいくつかの企業でインターンを経験した後、現在はENECHANGEでインターンをしています。山田さんが「中高生国際Rubyプログラミングコンテスト」で最優秀賞を受賞した話については、下記インタビュー記事で詳細を語られていますのでぜひご覧ください。note.com初めに、インターンシップはいくつかの方法で探しているとのこと。技術カンファレンスやプログラミングコンテストのスポンサーを探すWebサイト 魔法のスプレッドシート他の学生のSNSで情報収集更新がきちんとされている技術ブログENECHANGEのインターンも、RubyKaigiのスポンサー一覧から見つけて応募してくださったそうです。インターンの業務としては、大手クライアント向けに提供しているEV充電アプリのバックエンド開発を担当されています。実際の案件のタスクをもらい、メンターと一緒に仕様の詳細を決めたのち、実装をしていきます。具体的なタスクとしてこれまでに取り組んだのは3つ。1.Good Jobのダッシュボードの導入Good Jobという非同期処理を行うために利用するgemについて、利用状況を可視化ができておらず状況が把握しづらかったため、ダッシュボードを導入し、Good Jobの実行状況をリアルタイムで見られるようにしたそうです。2.FCMのpush通知における500エラーのリトライスマートフォンにプッシュ通知を送信するためのサービスであるFCM（Firebase Cloud Messaging）において、時折リクエストで500エラーを返却することがあり、プッシュ通知が失敗してしまうことが課題でした。その解決に向けて、通知の際に500エラーが返却されたデバイス情報を格納しておき、時間をおいて再度エラーが起きたデバイスに向けて処理を行うようにしました。3.分間バッチにログを仕込んでCloudWatchで調査EV充電器が使用可能かどうかのステータスを毎分更新するバッチについて、1分以内に処理が終わらないケースがあるため、どの処理に時間がかかっているのかを調査したいという課題がありました。それに対してバッチ内で処理時間を計測し、その内訳をログ出力することで、バッチ処理のボトルネックを調査できるようにしました。インターンでこのような業務に取り組む中で実務経験を積むことができ、技術的な新しいチャレンジもできるのがよかったとのことです。またENECHANGEでは社内の技術勉強会（Tech Talk）にも参加でき、これまで触れたことのない知識のインプットや、他の事業部の取り組みも知ることができて学びが多いと感じているそう。今後もカンファレンスや勉強会への参加・登壇や、技術書でのインプット、ハッカソンやプログラミングコンテストへの挑戦などで技術力を深めていきたいとのことです。発表資料はこちらで公開してくださっていますのでぜひご覧ください。本イベントを主催したENECHANGE株式会社では新卒エンジニアや長期インターン生を募集しています。興味のある方は下記もご覧ください！newgrads.enechange.co.jp

テックベンチャー3社のインターン生が語る！学生エンジニアの本音とは【イベントレポート】

日本にはAWS Community Builderが足りていないので、目指すなら今がお勧めです。AWS Community Builderに選ばれると、AWSのクレジットやグッズがもらえたり、新サービスや新機能の情報が早く得られたりするなど、さまざまなメリットがあります。背景筆者の岩本は、10月12日に開催されたJAWS FESTA 2024 in 広島に参加しました。日本のAWSユーザーグループ (JAWS-UG) が主催した、全国規模の交流イベントです。そのイベントで「日本にはAWS Community Builderが足りていない」ことを知りました。AWSの沼口さんのセッションで、そのような話があったのです。実にもったいない。岩本自身、今年からAWS Community Builderとして活動しており、さまざまなメリットを感じています。ぜひ多くの方に目指していただきたく、この記事を書きました。107人も足りない沼口さんによると、AWS Community Builderの数は世界で2,244名、うち117名が日本にいるそうです。一方で、適正な人数は世界の10%、つまり224名と考えているとのことでした。224名が適正で、実数が117名なので、107名も足りないことになります。豪華グッズこちらは、イベントから帰宅したら届いていたグッズの写真です。拡張パック付きのAWS BuilderCards、re:Invent 2023の詰め合わせバッグなどが含まれています。AWS Community Builderに選ばれたおかげで、このようなグッズがもらえるようになりました。今回より前にも、いろいろ頂いています。AWSクレジットも、具体値は明かしませんが、相当な額を頂きました。結論このように、AWS Community Builderにはさまざまなメリットがあるので、足りていないうちに目指すことをお勧めします。次回、2025年1月の申請サイクルに備えて、今のうちにウェイティングリストに登録しておきましょう。下記のページから登録できます。aws.amazon.com

日本にはAWS Community Builderが足りていない

こんにちは。エンジニア採用担当の村上です！先日、新しい技術の習得と活用を促進するために始まった社内イベント「I/O Day」のアウトプットの場としてオンラインLT大会が開催されましたのでレポートをお届けします。I/O Dayの起案者岩本さんへ、起案の背景や想いをお伺いしたインタビューも下記からご覧ください！tech.enechange.co.jp開催背景・概要ENECHANGEでは3ヶ月に一度の1日間、すぐに業務に役立てるのは難しいが、興味のある新しい技術などをインプットできる日を設ける「I/O Day」を開催しています。I/O Dayの取得にはアウトプットの提出も求められます。これまではブログの執筆等でアウトプットをしていましたが、今回は初めての試みとしてLT大会を開催しました。今回は6名のエンジニアが登壇し、LTをしてくれました。当日はエンジニアでないメンバーも含む常時40名以上が参加し、非常に盛り上がりました！エネルギークラウド事業部：杉田さん「ECS Scheduled Taskについて調べてみた」最初に登壇されたのは杉田さん。携わっているプロジェクトにおいて、現状のインフラ構成では全タスクがリソースを共有しており、パフォーマンスに影響を与える可能性があることを発見し、これを解消できないかと思い、ECS Scheduled Taskについて調べたそうです。他タスクの影響を受けず、定期バッチ処理に向いていることがわかり、実業務にも活用できそうとのこと。質疑応答ではI/O Dayでの感想を質問されていましたが、今回しっかりインプットの時間を取ることが出来て非常に良かったと感じたそうです！エネルギークラウド事業部：常盤さん「AWS Step Functions ゼロから入門」2人目に登壇した常盤さんは最近ETLパイプラインやバッチ処理に関わることが多く、データ周りへの興味が出てきたため、実際の業務に活かせるかどうか、ユースケースを調査したそうです。内容の詳細は記事としても公開されていますのでぜひご覧ください！zenn.dev別の事業部でもAWS Step Functionsを検討したことがあったり、主催者の岩本さんも実際に使ったことがあるとのことで、LT後の議論も盛り上がりました。岩本さんのAWS Step Functionsの活用事例は記事になっていますので下記もご覧ください。tech.enechange.co.jpEV充電サービス事業部：佐々木さん「AWS Security Hub で検出されたリスクに対応した結果」佐々木さんは、I/O Dayではなく業務の中での取り組みですが、その結果をシェアしたいとのことでLTに参加してくださいました。「AWS Security Hub」はAWS環境全体のセキュリティ状況を可視化・管理できるサービスです。AWS Security Hubから、頻繁にアラートが飛んできていたため、今回はその中から重要度の高いリスクをピックアップして対応してくださったそうです。セキュリティグループやコンピューティング、セキュリティ関連サービスの利用に関するリスクが検出されたため、対応ができるものは対応し、難しいものは抑制することで処理したとのこと。これで頻繁なアラートが飛んでくることはなくなる、と思っていたのですが...この対応でセキュリティモニタリングを強化した結果、潜在的なリスクが顕在化し、これまでの何倍もの数のリスクが検出されるようになったそうです。一見ネガティブに見えますが、進歩ですね。見えているリスクに対応したことで潜在化していた奥深いリスクにも気づくことができてよかったと感じられています。すぐに全てに対応することは難しいですが、継続的に取り組みながらセキュアで信頼できるサービスにしていきたい、ということで非常に頼もしく感じました！CTO室：岩本さん「DockerのマルチプラットフォームイメージをGitHub Actionsでビルドして公開する際に、参考にしたドキュメントと便利だったツール」岩本さんは今回、リクエストに対応するためマルチプラットフォームイメージ2種を公開したそうです。有料のツールもありますが、今回は無料の範囲内でできる方法を採用したとのこと。実際にLTで使用したスライドを公開いただいていますので具体的な内容はこちらからぜひご覧ください！LT後にはこうした参考ドキュメントやツールなどの情報収集の仕方について質問がありました。岩本さんは、サイボウズさんの生産性向上チームのZennをよく見ているそうです。サイボウズ 生産性向上チーム 💪 | Zennエネルギークラウド事業部：清水さん「AnimaでFigmaからReactコンポーネントを自動生成してみた」Figma等のデザインツールからReact、Vue、HTML/CSSのコードを自動生成してくれる「Anima」というツールを利用しての学びや気づきをシェアしてくださいました。AnimaではAIによるコード生成や動作のコード化、レスポンシブデザインの実現などが可能です。Animaでのコード自動生成は3ステップで可能です。Figmaでデザインを作成PluginでAnimaを追加デザインを選択してコードを生成実際の画面を写してデモをしてくださいましたが、とてもスムーズにコンポーネントが生成されて驚きました！実際に使ってみて、想像以上に実用的なコードが出力でき、またオプションも豊富なのでニーズに柔軟に対応できそうとのこと。一方で、最適なコードを出力させるには、コンポーネントベースの設計やレイヤー構造の整理など、Animaに適したデザインを作る必要があるため、そのスキルを身につけるにはコストがかかりそうと感じられています。エネルギークラウド事業部：片田さん「Flutter Webの可能性を探ってみる」今回は、今後作るかもしれないアプリでFlutter Webを使う可能性があるため、どのくらい現実的に使えるのか調べての知見を共有いただきました。詳細は下記でアウトプットしてくださっていますのでぜひご覧ください！zenn.dev実際のアプリを動かしてみた際のデモを見せてくださいましたが、弊社でやりたいことを十分に実現するのはなかなか難しそうとのこと。しかし、活用できそうな部分もありそうで、もっと深掘りしたいと感じたそうです。今回のアウトプットイベントでは、I/O Dayをきっかけに興味が広がり、また知見が深まったことが伝わり、とても素敵でした！ENECHANGEには今回のI/O Dayのアウトプット以外にも、2週間に一度、LTなど技術共有を行う社内イベントの「TechTalk」や、Slackで技術の雑談や共有ができるチャンネルなど、エンジニア同士のコミュニケーションや技術情報の共有の場が多くあります。弊社ではエンジニアも含め事業部制をとっていますが、こうした発表の後には質疑応答や議論がされることも多く、事業部を超えて切磋琢磨していける環境があると感じます。ENECHANGEでは様々なポジションでエンジニアを募集していますので、エンジニア同士のコミュニケーションが活発な組織に興味のある方は下記もご覧ください！engineer-recruit.enechange.co.jp

初実施の「I/O DayオンラインLT大会」、その内容を大公開！

AWS CodeDeployでブルー/グリーンデプロイしているAmazon ECSサービスについて、もしネットワーク設定を変えたくなったら、AppSpecを編集したうえで、新しいデプロイメントをトリガーしましょう。この方法を知らないと、ECSサービスをわざわざ作り直すか、ネットワーク変更をあきらめるか、どちらかになってしまいます。背景CodeDeployでブルー/グリーンデプロイしているECSサービスでは、ネットワーク設定を直接的には変更できません。ECSのUpdateService APIを呼び出して変更しようとすると、下記のエラーが起こります。InvalidParameterException: Unable to update network parameters on services with a CODE_DEPLOY deployment controller. Use AWS CodeDeploy to trigger a new deployment.これは、CodeDeployで新しいデプロイメントをトリガーする必要があることを示すエラーメッセージです。この制約についてはドキュメントにも書かれています。For services using the blue/green (CODE_DEPLOY) deployment controller, only the desired count, deployment configuration, health check grace period, task placement constraints and strategies, enable ECS managed tags option, and propagate tags can be updated using this API. If the network configuration, platform version, task definition, or load balancer need to be updated, create a new AWS CodeDeploy deployment. For more information, see CreateDeployment in the AWS CodeDeploy API Reference.引用元：UpdateService - Amazon Elastic Container Service解決策新しいデプロイメントをトリガーすべきなのは分かりましたが、具体的にどうしたらよいのでしょうか。答えは「AppSpecを編集してからトリガーする」です。編集せずにCodeDeployのCreateDeployment APIを呼んでトリガーしても、当然ながらネットワーク設定は変わりません。appspec.ymlの場合、下記のように編集します。        NetworkConfiguration:          AwsvpcConfiguration:            Subnets: ["subnet-1234abcd","subnet-5678abcd"]            SecurityGroups: ["sg-12345678"]            AssignPublicIp: "ENABLED"引用元：AppSpec File example - AWS CodeDeployECSタスクのサブネットやセキュリティグループ、また、パブリックIPアドレスを割り当てるかどうかを、AppSpecで指定するわけです。その際には、下記ドキュメントの通り Subnets、SecurityGroups、AssignPublicIp のすべてを指定する必要があります。All or none of the settings under NetworkConfiguration must be specified. For example, if you want to specify Subnets, you must also specify SecurityGroups and AssignPublicIp. If none is specified, CodeDeploy uses the current network Amazon ECS settings.引用元：AppSpec 'resources' section (Amazon ECS and AWS Lambda deployments only) - AWS CodeDeployAppSpecを編集後、新しいデプロイメントをトリガーすれば、ネットワーク設定が変わります。グリーン環境のECSタスクが、指定したネットワークで起動されるはずです。デプロイメントが完了したら、AppSpecから NetworkConfiguration を削除してOKです。まとめ以上のように、CodeDeployでブルー/グリーンデプロイしているAmazon ECSサービスでも、AppSpecを編集したうえで新しいデプロイメントをトリガーすれば、ネットワーク設定が変えられます。筆者の岩本はこの方法を知らず、もう少しでECSサービスを作り直すところでした。この記事が、似たような状況にある方の参考になれば幸いです。

ブルー/グリーンなAmazon ECSサービスのネットワーク設定を変える方法

ENECHANGEの Yuto Ono です。エンジニアリングマネージャーをしながら、フロントエンドの開発もしています。2024年4月に、React 19 Beta がリリースされました。2024年9月現在、 React 19 はRC版となっており、正式リリース間近となっております。そこで、早めに React 19 の新機能をキャッチアップし、正式リリース時にスタートダッシュをきれるようにしたいと思いました。最近、実務でアンケート機能の実装をしていることもあり、このようなアンケートアプリケーションを作ってみました。React 19 の機能をふんだんに使ってみましたので、その解説を書いていこうと思います。アクションuseActionStateuseOptimisticuseフック<Context.Provider> → <Context>メタデータのサポートrefを propsとして受け取れる（forwardRefが不要に）その他の新機能・改善まとめ今回のソースコードはこちらのGitHubリポジトリに公開しています。github.comまた、こちらにデプロイしております。よかったら触ってみてください。https://yuto-ono-react-19-sample.vercel.app/また今回 React 19 の学習にあたり、React公式ブログと、uhyoさんのZenn本を参考にさせていただきました。この場をお借りして、お礼申し上げます。ja.react.devzenn.devアクションReact 19 を語るうえで欠かせないのが、「アクション」という概念です。これは、非同期処理をスマートに実装できる仕組みのようなものです。詳しい説明は、React公式ブログや、uhyoさんの解説記事をご覧ください。アクションの最も基本的な実装方法は、 useTransition に非同期関数を渡すことです（React 18 にも useTransition がありますが、非同期関数を処理する機能はないのでご注意ください）。なお、他にもアクションを扱う便利なフックがあり、例えば後述する useActionState などがあります。実際にはそちらを使ってアクションを定義することが多いでしょう。useActionStateuseActionState は、アクションの定義とstateの管理を同時にできるものです。useFormState からリネームされただけあって、公式ドキュメントを見ても、フォームとともに使うことを想定されていそうです（もちろん、フォーム以外でも使うことができます）。また、それに関連して、 form の action に、非同期アクションを指定することができるようになりました。しかも、アクションの引数に formData が渡されるため、入力された値を取得するのも簡単にできるようになりました（公式ドキュメント）。今後は、フォームが非制御コンポーネント (uncontrolled component) で良い場合は、追加のライブラリなしでも快適に実装できそうです（制御コンポーネント (controlled component) を使う場合は、今まで通り、 react-hook-form などのライブラリを導入するのが良さそうです）。実際、今回の試作アプリでも、 useActionState を使って、送信途中や、送信後の挙動などをスマートに実装することができました。useActionState 使用箇所useOptimisticuseOptimistic は楽観的更新を行うためのフックです。これを使うと、非同期アクションの完了を待たずに、UIを更新することができます。いいねボタンを押したときにレスポンスを待たずにいいねのカウントが増えるイメージです。これにより、ユーザーにアプリケーションがサクサク動く印象を与えることができます。実際、今回、フォーム送信処理のモックにわざと1秒のsleepを入れていますが、送信処理が終わるのを待たずにアンケート結果が描画されていることがわかります。useOptimistic 使用箇所（上と同じ）useフックuse はPromiseやContextなどのリソースから値を読み取るためのフックです（公式ドキュメントでは、フックではなくて React API として紹介されていますが、便宜上フックと呼びます）。ただし、今回は、Promiseを読み取るための useは使いませんでした。なぜなら、公式ブログにはプロミスをキャッシュできるサスペンス対応のライブラリまたはフレームワークで作られたプロミスを渡す必要があります。とあり、現時点では他のライブラリと組み合わせて使うことが前提となっているからです。結局、データフェッチ系は、実務でも使っている、SWR で実装しました。将来的には、レンダー中にプロミスをキャッシュしやすくする機能を提供する予定です。とあるので、近いうちに、 React だけでデータフェッチを良い感じに書けるようになるかもしれません。良い感じのキャッシュ機構が開発されるのを楽しみに待ちましょう。もう1つの、Contextを読み取るための useは、下と関係するので、そこで一緒に言及します。<Context.Provider> → <Context>今まで <Context.Provider> と書いていたものが、 <Context> と書けるようになります。いずれは <Context.Provider> が非推奨になります（公式ブログ）。ちょっとした改善ですが、読みやすくなっていいですね。それに関連して、 useContext(Context) の代わりに、 use(Context) と書けるようになりました。読みやすくなっただけでなく、柔軟さも増しているようなので、今後はContextに対しては useを優先的に使うことが推奨されます（公式ドキュメント）。<Context> 使用箇所use 使用箇所メタデータのサポート<title>、<link>、<meta> などのメタデータタグをレンダリングするのに、今までは react-helmet のようなライブラリが必要でしたが、React 19 からはメタデータタグを認識して自動的に <head> セクションに移動してくれるようになりました（公式ブログ）使用箇所refを propsとして受け取れる（forwardRefが不要に）今まで forwardRefを使って回りくどい方法で refを渡していたのが、シンプルに propsで refを受け取れるようになります（公式ブログ）。その他の新機能・改善他にも今回紹介しきれなかった新機能・改善が色々あります。ぜひ公式ブログやuhyoさんの記事を参考にしてみてください。サーバコンポーネント・サーバアクションハイドレーションエラー時の差分表示ref 用のクリーンアップ関数useDeferredValue の初期値スタイルシートのサポート非同期スクリプトのサポートリソースのプリロードサードパーティのスクリプトおよび拡張機能との互換性改善カスタム要素のサポートまとめReact 19 で登場したアクションという概念と、それを扱うための useActionState 、useOptimistic は、非同期処理を実装するうえで、非常に便利だと感じました。きっと周辺ライブラリもアクションに対応してくると思うので、そのへんもウォッチしていきたいなと思いました。それ以外にも嬉しい新機能や改善が色々とあったので、19の正式リリースが楽しみです。あと、フロントエンド界隈は常に新しい技術や概念が出続けるので、勉強を続けることが大事だと思いました。ぜひ皆さんも常に新しい情報をキャッチアップし続けていきましょう！

React 19 RC で、アンケート画面を作ってみた

すべての情報処理技術者試験に合格するには「体力」が、すべてのAWS認定資格を取得するには「お金」が、それぞれ最大の鍵です。鍵が分かれば、効率よくダブル全冠が狙えます。相手を知らずに戦うのは非効率です。ダブル全冠が達成できれば、エンジニアとしての市場価値が高まります。レアだからです。現時点の達成者は多くて数百人でしょう。背景筆者の岩本は2021年にIPA全冠を、また本日、AWS全冠を達成しました。その経験で気づいた戦い方をお伝えし、参考になればと思っています。IPA全冠：若いうちに省エネして狙うIPA全冠の鍵は体力です。高度試験は9:30から16:30まで論述式の問題では2時間で3,000字ほど筆記が必要なので、以下の戦略が有効です。若いうちに受ける（今が人生でいちばん若い）午前I試験は免除を狙う試験会場の近くに前泊する疲れにくい筆記用具を使う（マークシート用鉛筆とデルガードがおすすめ）とくに高度試験こそ若いうちの受験をおすすめします。年に一度しかない機会を逃せば、それだけで1年の損です。ちなみにぼくは、体力が落ちてきたので、もう受けたくありません。IPA全冠を達成していちばんうれしかったのは「もう受けなくて済むこと」でした。AWS全冠：勤務先の福利厚生で狙うAWS全冠の鍵はお金です。試験によっては受験料が40,000円（情報処理技術者試験は7,500円）3年ごとに更新が必要（情報処理技術者試験は更新不要）なので、以下の戦略が有効です。勤務先に受験料補助や資格手当があれば遠慮なく使うそのような仕組みがなければ提案する提案してもダメなら転職するたとえば、ENECHANGEには受験料補助の制度があります。IPAでもAWSでも、合否にかかわらず、全額を補助してくれるありがたい制度です。この制度、ぼくが提案したものでした（「ENECHANGE における AWS 認定受験料補助制度の創設」）。社員の成長を願っている企業であれば、きっと検討してくれるはずです。AWS無冠だったぼくは、受験料負担ゼロで、AWS全冠が達成できました。結論ダブル全冠を効率的に狙うには、以下の戦略が有効です。IPA全冠：若いうちに省エネして狙うAWS全冠：勤務先の福利厚生で狙うエンジニアとしての市場価値を高め、キャリアの選択肢を増やすために、ぜひ次の情報処理技術者試験に申し込みましょう。

IPAとAWSのダブル全冠、鍵は体力とお金

概要CloudTrailはCloudWatchLogsと統合できるため、CloudWatchを利用して改ざんや不正アクセスに関連する疑わしいイベントを検出できます。検知条件の策定セキュリティと運用の観点から合理的かつ包括的なアプローチを取るためにターゲットは下記としました。CloudTrailAWS全体の監査基盤であり、これ自体の設定変更を監視することは、AWSリソース全体の監視に直結します。S3重要なデータの保管場所であり、機密データの改ざんやアクセス制御の変更を監視することでデータの保護を強化できます。闇雲に指定しても意味ないので、下記要件を1つでも満たすものを対象とした。機密性の高いデータを含むコンプライアンス要件があるビジネスクリティカルなデータを含むアプリケーションの設定ファイル、バックアップデータ、重要なレポートなど外部公開されている（存在しない認識）Lambda全Functionを対象としました。サーバーレスアーキテクチャの中心として、アプリケーションロジックを保護するための監視が重要です。CloudTrailCloudTrailに適用する検知条件1. CloudTrailの無効化（StopLogging / DeleteTrail）説明: 攻撃者がAWSアカウントに不正アクセスした場合、最初に監査ログを無効化しようとする可能性があります。これにより、後続の不正アクション（例: リソース削除、データアクセスなど）が監視されなくなります。リスク: StopLogging や DeleteTrail APIが実行されると、CloudTrailはログ記録を停止します。不正アクセスや改ざんの追跡が困難になります。対策: これらのイベントをCloudWatch Logsで監視し、検知した際にすぐに対応できるようにする。2. ログの保存先S3バケット変更（UpdateTrail）説明: CloudTrailのログ保存先バケットが変更されると、誤って設定されたバケットに保存され、不正アクセスの痕跡が削除・改ざんされる可能性があります。リスク: 不正なバケットポリシーの場合、攻撃者はログを削除または改ざんする可能性があります。対策: UpdateTrail イベントを監視し、保存先バケットの変更を検知した場合にアラートを発生させる。3. CloudTrailのロギング無効化（StopLogging）説明: StopLogging APIで特定のCloudTrailがログ記録を停止される可能性があります。これは、悪意あるユーザーが操作の痕跡を隠すために行われることがあります。リスク: ログ記録が停止されると、セキュリティ監査に必要なデータが失われ、不正アクセスが検出できなくなります。対策: StopLogging イベントを監視し、すぐにCloudTrailの再開や調査を実施する。S3S3に適用する検知条件説明は省略1. オブジェクト削除 (DeleteObject, DeleteObjects)2. オブジェクト変更 (PutObject, CopyObject)3. バケットポリシーや設定の変更 (PutBucketPolicy, PutBucketAcl, PutBucketVersioning)4. バケット削除 (DeleteBucket)LambdaLambda関数に適用する検知条件1. Lambda関数の無効化や削除（DeleteFunction / UpdateFunctionConfiguration）説明: 攻撃者が不正アクセスを行った場合、Lambda関数を無効化または削除することで、ビジネスロジックを停止させる可能性があります。リスク: DeleteFunction や UpdateFunctionConfiguration APIが実行されると、Lambda関数が無効化され、重要なビジネスロジックや処理が停止する恐れがあります。対策: これらのAPI呼び出しをCloudWatch Logsで監視し、検知した際にアラートを発生させます。2. Lambda関数の設定変更（UpdateFunctionCode / UpdateFunctionConfiguration）説明: Lambda関数のコードや設定が変更されると、不正なコードが実行され、機密データが漏洩する可能性があります。リスク: 関数のコードが改ざんされることで、悪意のある動作が実行されたり、設定変更によってセキュリティポリシーが緩和される可能性があります。対策: UpdateFunctionCode や UpdateFunctionConfiguration イベントを監視し、関数コードや設定変更が発生した場合に通知を行います。3. Lambda関数の呼び出し（InvokeFunction）説明: Lambda関数が不正に呼び出されることで、機密データの流出や不正な処理が行われる可能性があります。リスク: InvokeFunction APIが不正に呼び出され、ビジネスクリティカルなデータにアクセスされたり、不正な処理が実行される可能性があります。対策: Lambda関数の呼び出しログをCloudWatch Logsで監視し、異常な呼び出しが検知された場合にアラートを発生させます。Terraform構成chatbotとsnsはModuleにしています。cloudtrail├── cloudtrail.tf├── cloudwatch_log.tf├── cloudwatch_metric_log.tf├── iam_role.tf├── locals.tf├── main.tf└── module.tf1 directory, 7 files設定例locals {  important_s3_buckets = [    "arn:aws:s3:::xxxxxxxx/",    "arn:aws:s3:::xxxxxxxx/",    "arn:aws:s3:::xxxxxxxx/",    "arn:aws:s3:::xxxxxxxx/",  ]}# CloudTrailがCloudWatchLogsにログを書き込むためのIAMロールresource "aws_iam_role" "cloudtrail_cloudwatch_role" {  name = "cloudtrail-cloudwatch-logs-role"  assume_role_policy = jsonencode({    Version = "2012-10-17",    Statement = [      {        Effect = "Allow",        Principal = {          Service = "cloudtrail.amazonaws.com"        },        Action = "sts:AssumeRole"      }    ]  })}# CloudTrailがCloudWatchLogsにログを送信するためのポリシーresource "aws_iam_role_policy" "cloudtrail_cloudwatch_policy" {  role = aws_iam_role.cloudtrail_cloudwatch_role.id  policy = jsonencode({    Version = "2012-10-17",    Statement = [      {        Effect = "Allow",        Action = [          "logs:CreateLogGroup",          "logs:CreateLogStream",          "logs:PutLogEvents"        ],        Resource = "*"      }    ]  })}resource "aws_cloudwatch_log_group" "cloudtrail_s3_log_group" {  name              = "/aws/cloudtrail/cloud-trail-s3-data-events"  retention_in_days = 365}# s3の設定変更やログの停止イベントの監視resource "aws_cloudwatch_log_metric_filter" "cloudtrail_s3_change" {  name           = "S3ChangeFilter"  log_group_name = aws_cloudwatch_log_group.cloudtrail_s3_log_group.name  pattern        = "{ ($.eventName = DeleteObject) || ($.eventName = DeleteBucket) }"  metric_transformation {    name      = "S3ChangeEvents"    namespace = "S3Metrics"    value     = "1"  }}resource "aws_cloudwatch_metric_alarm" "cloudtrail_s3_change_alarm" {  alarm_name          = "CloudTrail-S3-ChangeAlarm"  comparison_operator = "GreaterThanOrEqualToThreshold"  evaluation_periods  = "1"  metric_name         = aws_cloudwatch_log_metric_filter.cloudtrail_s3_change.metric_transformation[0].name  namespace           = aws_cloudwatch_log_metric_filter.cloudtrail_s3_change.metric_transformation[0].namespace  period              = "300"  statistic           = "Sum"  alarm_actions = [    module.aws_chatbot_slack.sns_topic_arn  ]  ok_actions = [    module.aws_chatbot_slack.sns_topic_arn  ]}resource "aws_cloudtrail" "s3_data_events" {  name                          = "cloud-trail-s3-data-events"  s3_bucket_name                = <s3bucket-name>  s3_key_prefix                 = "CloudTrail-S3/" # S3用のフォルダ  is_multi_region_trail         = true  enable_log_file_validation    = true  include_global_service_events = true // グローバルサービスの管理イベント  # CloudWatchLogs設定  cloud_watch_logs_group_arn = "${aws_cloudwatch_log_group.cloudtrail_s3_log_group.arn}:*"  cloud_watch_logs_role_arn  = aws_iam_role.cloudtrail_cloudwatch_role.arn  event_selector {    read_write_type           = "All"    include_management_events = true // 管理イベント    data_resource {      type   = "AWS::S3::Object"      values = local.important_s3_buckets    }  }}module "aws_chatbot_slack" {  source             = "git@github.com:xxxxxx/terraform-modules.git//chatbot-slack?ref=x.x.x"  configuration_name = "cloudtrail-change-chatbot-configuration"  slack_channel_id   = "xxxxxxx"  slack_team_id      = "xxxxxxx" // #slack channel  sns_topic_name     = "custom-cloudtrail-change-notifications"  logging_level      = "ERROR"  iam_role_name      = "cloudtrail-change"}

CloudTrailとCloudWatchLogsの統合

こんにちは。人事室の村上です。先日弊社オフィスにて「今さら聞けない！オフィス・開発でのAI活用」をテーマにイベントが開催されました！主催は「うら原アジャイルコミュニティ」で、弊社は共催として参加しました。オフライン・オンラインの同時開催で、それぞれ10名以上の方にご参加いただき、当日も盛り上がっていましたので本記事ではレポートをお届けしたいと思います。概要今回のテーマは「オフィス・開発でのAI活用」です。登壇者3名がそれぞれ下記のテーマで発表しました。谷口 崇：生成AIとその活用岩本 隆史：RAGもファインチューニングも使わない 素朴なAIチャットボットを職場に導入した結果小野 優人：GitHub Copilotの活用方法①谷口 崇：生成AIとその活用最初に登壇されたのは谷口さん。現在は株式会社バックテックに所属され、ReactでのSPA開発をメインに携わっていらっしゃいます。今回は生成AIの成り立ちや特徴、そこから考える効果的な使い方と利用時の注意点をお話しくださいました。谷口さんは普段開発業務や新しい言語の学習、ドキュメント作成やブレインストーミングなど日常の様々なシーンで生成AIを活用されています。生成AIの活用の際のコツとして以下が挙げられました。事前知識を教えておく余計な情報は与えないステップバイステップで答えを引き出していく会話を重ねると発言を忘れていくので短く簡潔に答えを引き出すAIは非常に便利で使い方に配慮することで精度高く利用できますが、ありもしない情報を真実のように告げることもあるそうです。生成AIはあくまでツールとして、検証できる範囲で使いましょうとのこと。谷口さんはAIを壁打ち相手やアシスタントとして使っているそうです。筆者も仕事でChatGPTを利用することがありますが、思うように答えが返ってこなかったり、画像生成の結果がとんでもないことになったりします。プロンプトの作り方が難しいと感じていたので、今回学んだコツを試してみようと思います！②岩本 隆史 (iwamot)：RAGもファインチューニングも使わない 素朴なAIチャットボットを職場に導入した結果次の登壇者は岩本さん。岩本さんは当社ENECHANGEのCTO室でVPoTとして活躍されていらっしゃいます。ENECHANGEではSlackでAIチャットボットと会話ができるのですが、その仕組みを作ってくださったのが岩本さんです。今回は、岩本さんがAIチャットボットを導入した結果や、導入の際のコツを話してくださいました！ENECHANGEは業務効率の向上を目指し、ChatGPTやGitHub Copilotを希望する全従業員・エンジニアに導入しました。その後、全社的に利用している「Slack」というコミュニケーションツールにもAIチャットボットを導入しました。AIチャットボットは特にファインチューニングやRAGは行わず素のGPT-4モデルで導入しましたが、各AIツールの併用により、5ヶ月で業務効率が平均44%改善されたとのこと。SlackでAIチャットボットに質問できるチャンネルは毎日動いており、今では欠かせない存在となっています。この利用率の高さの背景には「最新モデルへのスピーディーなアップデート」があると推察しているそうです。AIの技術は日々向上し、高性能かつ高速なモデルが次々と出ます。そこでモデルの切り替えやすさを重視しChatGPT-in-Slackという環境変数の変更のみでモデルの切り替えができるOSSを利用して運用していました。しかし最近、Claude 3.5 Sonnetというモデルが出てきたためそちらも活用したいと思ったところ、上記OSSではGPTモデルしか導入できないという課題が出てきました。そこでOSSをforkしてCollmboを開発。Sonnet Botの導入に成功しました。筆者はSlackでSonnet Botが利用可能であることを恥ずかしながら初めて知りましたのでさっそく使ってみました！GPTモデルとの違いなどまだわからないことばかりですが、色々触って勉強してみたいと思います。③小野 優人：GitHub Copilotの活用方法最後に登壇されたのは小野さん。小野さんはENECHANGE株式会社でフロントエンドをメインに開発に携わられ、エンジニアリングマネージャーとしても活躍されています。小野さんは開発でGitHub Copilotを活用しているそうです。ENECHANGEでは、GitHub Copilotを希望する全エンジニアに提供しています。具体的な活用方法5つをデモ動画とともに教えていただきました。※なお、下記の活用方法はVSCodeでの使用を前提としています。他のエディターをお使いの方は適宜使用方法をお調べいただければと思います。コード補完：特に何も意識しなくても、コードを自動で補完してくれるのがとても便利です。関連ファイルをタブで開いておいたり、先にコメントを入れておくと精度がより高まるそうです。Copilot Chatで質問する：チャットで聞きたいことをすぐに聞けます。「エディタでチャットを開く」を使うと、チャットの画面が広くなり、エディタのタブとして残るので後で見返すときにも便利でオススメです。テストを書いてもらう：Copilot Chatの「コードの単体テストを追加する」というメニューから一瞬でテストを作ってもらえます。 /tests コマンドでも同様のことができます。Inline Chat in Editor：エディター内で「Command + I 」というショートカットでインラインチャットを開くことができます。そこで例えば「〇〇な関数を追加して」と指示すると、指示の意図や周囲のコードを汲み取って、関数を一瞬で書いてくれます。Inline Chat in Terminal：インラインチャットはターミナルでも使えます。コマンドを忘れてしまった時などに質問すると、コマンドを提案してくれるのでとても便利です。筆者はエンジニアではないので、開発実務に関して詳しくはありませんが、コードの記述やテストの作成など本当に一瞬の出来事だったので「すごい技術だな...」と思いました。生産性が非常に高まる機能なのだろうと感じましたのでエンジニアの皆さんぜひ使ってみてくださいね。おまけ発表終了後にはオフライン参加の皆さんでいろいろな話をして盛り上がりました。オンラインでのイベントも増えていますが、こうした交流が現地参加の醍醐味だと感じました。ENECHANGEでは定期的にイベントを開催しています。オンラインのものがメインですが、オフラインイベントも企画できればと思いましたので、最新情報はこちらからチェックしてください！https://enechange-meetup.connpass.com/enechange-meetup.connpass.comーーーーーーーーーーーーーーーーーーーーーーーー最後までご覧いただきありがとうございました。ENECHANGE株式会社では幅広い職種で仲間を募集しています。興味のある方はこちらから気軽にエントリーください！engineer-recruit.enechange.co.jp

「今さら聞けない！オフィス・開発でのAI活用」イベントレポート

VPoT兼CTO室マネージャーの岩本 (iwamot) です。プレイヤーとしては、おもにクラウド運用を担当しています。先日「IPアドレス制限のあるURLを死活監視したい」と同僚から相談され、Amazon Route 53ヘルスチェックによる監視を実装しました。シンプルな実装ですが、工夫した点もあるため、事例として共有します。要件監視対象は、AWSのALBやCloudFrontで特定クライアントにのみ公開しているURLIPアドレス制限のないURLはPingdomで死活監視しているが、今回は利用不可PingdomのIPアドレスをクロールして許可するのは手間だし、自動化も面倒アーキテクチャ実装した死活監視のアーキテクチャは以下の通りです。Route 53ヘルスチェックとCloudWatchが主役Route 53ヘルスチェックを設定し、ALBやCloudFrontのURLを監視するようにしました。利用は初めてですが、特に難しいところはありませんでした。名前とドメイン名を入れる程度でOKまた、CloudWatchアラームも設定し、異常が検知された（HealthCheckStatusメトリクスの値が「0」となった）場合に、SNSトピックに通知が飛ぶようにもしました。こちらも簡単で、メトリクスがus-east-1に記録される点に注意が必要な程度です。重要な、ヘルスチェック元IPアドレスの許可については、下表のように設定しました。監視対象IPアドレスの定義先許可ルールの設定先ALBマネージドプレフィックスリストセキュリティグループCloudFrontWAF IPセット（詳しくは別記事を参照）Web ACLRoute 53ヘルスチェックを選んだ理由監視対象がAWS上のワークロードのため一元的に管理できるマネージドサービスのため開発が不要マネージドプレフィックスリストが提供されているためアクセス許可が簡単料金が安い（URL1件あたり月1.5ドル程度）工夫した点監視対象は複数あるとのことだったので、社内用Terraformモジュールを作成し、横展開しやすくしました。現時点で10件のURLを監視中です。provider "aws" {  region = "us-east-1"  alias  = "us_east_1"}module "http-healthcheck" {  source = "git@github.com:enechange/terraform-modules.git//http-healthcheck?ref=x.x.x"  providers = {    aws.us_east_1 = aws.us_east_1  }  name          = "prod-example"                  # ヘルスチェック名  url           = "https://example.com/login"     # 監視対象のURL  sns_topic_arn = aws_sns_topic.in_us_east_1.arn  # 通知先SNSトピックのARN}まとめRoute 53ヘルスチェックを使うことで、IPアドレス制限ありのURLでも、手軽に安く死活監視が実現できました。また、ちょっとした工夫として、社内用Terraformモジュールを作成しました。おかげで、横展開がスムーズにできています。Route 53ヘルスチェックをまだ試したことのない方は、簡単に設定・破棄できますので、気軽に試していただくことをお勧めします。

IPアドレス制限ありのURLをRoute 53ヘルスチェックで死活監視する

Amazon S3における条件付きリクエストの活用特定の条件が満たされた場合にのみオブジェクトのアップロードや更新を許可する機能です。競合の防止やデータの整合性を確保するために使用できます。https://aws.amazon.com/jp/about-aws/whats-new/2024/08/amazon-s3-conditional-writes/GetObject、HeadObjectの条件付きリクエストIf-Match: オブジェクトのEtagと一致する場合にのみリクエストを実行If-None-Match: オブジェクトのEtagと異なる場合にのみリクエストを実行If-Modified-Since: 指定日時以降にオブジェクトが変更されている場合にリクエストを実行If-Unmodified-Since: 指定日時以降に変更されていない場合にリクエストを実行PutObjectの条件付きリクエストIf-None-Match: オブジェクトのEtagと異なる場合にのみリクエストを実行重要なのはS3自体には、すべてのリクエストで条件付き書き込みを標準化するための機能は提供されていません。つまり、S3の設定で条件付きリクエストを必須にすることはできません。標準化はクライアント側の実装や運用ポリシーで行う必要があります。PutObjectの使用方法主にIf-None-Matchを使用し、条件付きでオブジェクトの上書きを制御します。If-Matchはサポートされていないため、書き込み時にEtagを使った厳密な制御はできません。--if-none-match: 同名のオブジェクトがすでに存在する場合はアップロードが失敗します。オブジェクトの内容が一致しているかどうかは関係なく、名前（キー）が同じであれば条件に合致せず、アップロードが拒否されます。条件合致しないケース（同名キーが存在する）% aws s3api put-object --bucket hopstepjump --key test.data --body ~/docs/test.data --if-none-match "*"An error occurred (PreconditionFailed) when calling the PutObject operation: At least one of the pre-conditions you specified did not hold条件合致するケース(同名キーが存在しない)% aws s3api put-object --bucket hopstepjump --key test.data2 --body ~/docs/test.data2 --if-none-match "*"{    "ETag": "\"*******************************\"",    "ServerSideEncryption": "AES256"}GetObjectの条件付きリクエストIf-MatchやIf-None-Matchを使用して、Etagの一致を基にオブジェクトの取得条件を設定できます。読み取りに対してEtagによる整合性のチェックが可能です。If-MatchでEtagによる整合性をチェックするケースEtagの確認% aws s3api head-object --bucket hopstepjump --key test.data --query ETag --output text"*******************************"得たEtagを指定した条件合致するケース% aws s3api get-object --bucket hopstepjump --key test.data ~/docs/test.data --if-match "*******************************"{    "AcceptRanges": "bytes",    "LastModified": "2024-09-03T05:15:22+00:00",    "ContentLength": 8888,    "ETag": "\"*******************************\"",    "ContentType": "binary/octet-stream",    "ServerSideEncryption": "AES256",    "Metadata": {}}Etagを指定した条件合致しないケース% aws s3api get-object --bucket hopstepjump --key test.data ~/docs/test.data --if-match "*******************************"An error occurred (PreconditionFailed) when calling the GetObject operation: At least one of the pre-conditions you specified did not holdterraform.tfstateについてterraformのtfstateをDynamoDBによってロックしなくてもこの条件付き上書き機能で運用できるかも？と思いましたが、そもそもPutActionはEtagを使った制御ができませんでした。

Amazon S3 が条件付き書き込みのサポートを開始

結論サービスがIdpと連携していたとしてもALBが認証プロバイダーと連携してトークンの検証を行っていない場合、ALBeast脆弱性の影響はありません。概要https://www.miggo.io/resources/uncovering-auth-vulnerability-in-aws-alb-albeast攻撃者は正規のトークンを模倣した不正に署名されたトークンを生成し、本脆弱性を悪用すると、ALBがこの不正トークンを正しく検証せずに受け入れてしまう。その結果、Idpとの連携システムであっても発行した正規のトークンがなくても、攻撃者は偽のトークンで認証を通過できる可能性があるため、アクセス制御が回避される恐れがあります。対策AWSはALBにおける認証機能を更新済付録トークンを偽装されて接続されたとしてもアプリケーション内でもBasic認証やOAuth2.0などの認証を導入していれば悪意のある接続は防げていたそもそもALBで署名を検証できていなかったというのは耳を疑うような欠陥なので、利用料金の一部を返納しろというコメントがサポートに出てるような気もしますね...

ALB脆弱性の影響と対策

VPoTの岩本 (iwamot) です。8月24日から25日にかけて、AWSタイトルホルダーやAWS内の方が登壇しつづける24時間オンラインイベント「JAWS PANKRATION 2024」が開催されました。jawspankration2024.jaws-ug.jpぼくは24日の23:20 (JST) から「Cost-Effective SLO Error Budget Monitoring with Athena and CloudWatch」のタイトルで登壇しました。発表した内容については、スライドや、後日公開予定のアーカイブ動画をご覧いただければ幸いです。今回の記事では、登壇によって得られたものを記してみます。どなたかの登壇意欲に火をつけられたら、と願っています。豪華なSwagまずは物理的なものから。登壇者は豪華なSwagがいただけました。jawspankration2024.jaws-ug.jp特にデジタル名刺のプレーリーカードは、オフラインイベントでのコミュニケーションで活躍してくれそうで、ありがたい限りです。どこかでぼくを見かけたら、実物をお見せしますので、ぜひお声がけください。世界的イベントで話した実績ここからは精神的に得られたものです。まず、世界的イベントで話す実績が解除できました。https://jawspankration2024.jaws-ug.jp/ja/news/z9rhwkzd4/ よりこのようなイベントでは英語で話さなければならないことが多く、英語が苦手なぼくは応募を控えるのが常でした。しかし、JAWS PANKRATION 2024では、同時翻訳が実装されており、発表者の音声をいろんな言語に訳して読むことができました。そのおかげで安心して応募でき、世界的イベントで話す実績が解除できたのです。準備不足への反省といいながら、ぼくの話し方が下手すぎたせいで、実はうまく翻訳できていなかったようでした。一文を短くしてはっきり発声する、文のあとにスリープを入れる、などの注意点を守れなかったのが原因です。ぼくはイベントのライブ感が好きなので、登壇時はいつもメモを用意せず、即興で話しています。その緊張感が登壇の醍醐味だとすら思っています。今回もそうしてしまったのですが、翻訳にはふさわしくありませんでした。また機会があれば、そのときにはしっかり準備して臨みます。申し訳ありませんでした。運営メンバーへの感謝・尊敬最後に、このような機会を作っていただいた運営メンバーのみなさまに、あらためて感謝申し上げます。24時間連続のオンラインイベントなんて、事前の準備も当日のオペレーションも、イベント運営にほぼ携わったことのないぼくには想像を絶するご苦労があったかと思います。しかも、みなさんボランティアで運営されているわけで、その熱意には尊敬するばかりです。いろんなものをいただき、本当にありがとうございました。

JAWS PANKRATION 2024に登壇して得られたもの

VPoTの岩本 (iwamot) です。この記事では、AWS Lambdaを使わずにサーバーレスな処理を実装する、いわゆる「Lambdaレス」な実装の例をご紹介します。具体的には「AWSサービスのIPレンジ変更を検知し、AWS WAFのIPセットを自動更新してみた」例です。Lambdaレスな考え方は、AWS Summit Japan 2024のセッション「サーバーレス開発のベストプラクティス ～より効果的に、より賢く使いこなすために～」（動画、資料）で取り上げられ、注目されています。*1いざ実装してみると、Lambda関数の保守がいらなくなるメリットが大きく感じられました。Lambdaレス以前の実装例AWSは、AWSサービスのIPレンジ変更を検知し、AWS WAFのIPセットを自動更新するサンプルとして、下記のGitHubリポジトリを公開しています。github.comgithub.comいずれも、IPレンジ変更が通知されるSNSトピック (arn:aws:sns:us-east-1:806199016981:AmazonIpSpaceChanged) にサブスクライブしたLambda関数で、IPセットを更新する実装です。                          +-----------------+         +----------------+                          | Lambda          |         |                |                          | Execution Role  |    +--->+AWS WAF IPv4 Set|                          +--------+--------+    |    |                |                                   |             |    +----------------+                                   |             |+--------------------+    +--------+--------+    ||SNS Topic           +--->+ Lambda function +----+|AmazonIpSpaceChanged|    +--------+--------+    |+--------------------+             |             |    +----------------+                                   |             |    |                |                                   v             +--->+AWS WAF IPv6 Set|                          +--------+--------+         |                |                          | CloudWatch Logs |         +----------------+                          +-----------------+https://github.com/aws-samples/aws-waf-ipset-auto-update-aws-ip-ranges                          +-----------------+         +---------------------+                          | Lambda          |         |                     |                          | Execution Role  |    +--->+AWS WAF IPv4/IPv6 Set|                          +--------+--------+    |    |                     |                                   |             |    +---------------------+                                   |             |+--------------------+    +--------+--------+    ||SNS Topic           +--->+ Lambda function +----+|AmazonIpSpaceChanged|    +--------+--------+    |+--------------------+             |             |    +-------------------+                                   |             |    |                   |                                   v             +--->+AWS VPC Prefix List|                          +--------+--------+         |                   |                          | CloudWatch Logs |         +-------------------+                          +-----------------+https://github.com/aws-samples/update-aws-ip-rangesこれらのサンプルを活用してもよいのですが、できればLambdaレスにして、保守の手間をなくしたいですよね。Lambdaレスな実装例どうしたらよいのか、ぼくなりに考えて出た答えが下記でした。IPセットの更新にStep Functionsを利用トリガーにSQSとEventBridge Pipesを利用以下、説明します。IPセットの更新にStep Functionsを利用IPセットの更新は、AWS WAFのUpdateIPSet APIを呼び出して実行します。Lambdaレスで呼び出す手段として、ぼくはStep FunctionsのAWS SDK統合を選びました。具体的なワークフローは下記の通りです。{  "Comment": "Updates WAFv2 IP set with latest Route 53 health check IP ranges when AWS IP ranges change.",  "StartAt": "Parallel",  "States": {    "Parallel": {      "Branches": [        {          "StartAt": "GetManagedPrefixListEntries",          "States": {            "GetManagedPrefixListEntries": {              "End": true,              "Parameters": {                "PrefixListId": "pl-xxxxxxxxxxxxxxxxx"              },              "Resource": "arn:aws:states:::aws-sdk:ec2:getManagedPrefixListEntries",              "Type": "Task"            }          }        },        {          "StartAt": "GetIPSet",          "States": {            "GetIPSet": {              "End": true,              "Parameters": {                "Id": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",                "Name": "my-ip-set",                "Scope": "CLOUDFRONT"              },              "Resource": "arn:aws:states:::aws-sdk:wafv2:getIPSet",              "Type": "Task"            }          }        }      ],      "Next": "UpdateIPSet",      "Type": "Parallel"    },    "UpdateIPSet": {      "End": true,      "Parameters": {        "Addresses.$": "$[0].Entries[*].Cidr",        "Id.$": "$[1].IpSet.Id",        "LockToken.$": "$[1].LockToken",        "Name.$": "$[1].IpSet.Name",        "Scope": "CLOUDFRONT"      },      "Resource": "arn:aws:states:::aws-sdk:wafv2:updateIPSet",      "Type": "Task"    }  }}マネージドプレフィックスリストを参照しているのは、今回の要件が「Route 53ヘルスチェックで使われるIPv4レンジをIPセットとして提供すること」だったためです。pl-xxxxxxxxxxxxxxxxx で com.amazonaws.<region>.route53-healthchecks を参照し、エントリをAWS WAFのIPセットにコピーしています。Step FunctionsではHTTPリクエストも可能です。今回は試していませんが、Lambdaレス以前の実装のように、https://ip-ranges.amazonaws.com/ip-ranges.json を参照するワークフローも可能でしょう。ちなみに、UpdateIPSetの前にGetIPSetしているのは、その順で呼び出す仕様だからです。詳しくはUpdateIPSet APIのドキュメントをご覧ください。トリガーにSQSとEventBridge Pipesを利用ここまでできれば、あとはSNSとStep Functionsをつなぐだけです。SNSトピックに直接Step Functionsをサブスクライブできるとよいのですが、現時点ではできません。今回は「SNS → SQS → EventBridge Pipes → Step Functions」とつないでみました。EventBridge Pipesは、まさにこのような統合に使えるサービスです。https://aws.amazon.com/jp/eventbridge/pipes/おわりに以上、Lambdaレスな実装例をご紹介しました。Lambdaを「SQS → EventBridge Pipes → Step Functions」で置き換えているため複雑に見えるかもしれませんが、実際にはワークフローを組み立ててサービスをつないでいくだけです。実装してみて、Lambda関数の保守がいらなくなるメリットが大きく感じられました。今後も、Lambdaレスな実装をまず考えるようにします。*1:2024年8月23日から24日にかけて開催されるイベント「JAWS PANKRATION 2024」でも、AWSコミュニティビルダーの鈴木さんが「What is "Lambdaless" serverless?」を発表予定です。

「Lambdaレス」な実装例：AWS WAFのIPセット自動更新

スナップショットテストをやめて、ビジュアルリグレッションテストに移行した話

VPoTの岩本 (iwamot) です。この記事では、Terraformモジュール構成のベストプラクティスをご紹介します。Terraformドキュメントに書かれているものですが、従わずに時間を溶かした失敗談をまじえてお伝えすることで、同じ轍を踏む方が減ることを願っています。取り上げるのは下記のベストプラクティスです。Module Composition（フラットなモジュールツリー）Dependency Inversion（依存性の逆転）Module Composition（フラットなモジュールツリー）Module Compositionは、モジュールをフラットに並べられるよう構成すべし、という話です。Terraformドキュメントでは下記の例が挙げられています。module "network" {  source = "./modules/aws-network"  base_cidr_block = "10.0.0.0/8"}module "consul_cluster" {  source = "./modules/aws-consul-cluster"  vpc_id     = module.network.vpc_id  subnet_ids = module.network.subnet_ids}これに従わず、aws-consul-clusterモジュール内でnetworkモジュールを参照し、ルートモジュールで下記のように記述する設計も可能です。module "consul_cluster" {  source = "./modules/aws-consul-cluster"  base_cidr_block = "10.0.0.0/8"}ただ、後者の設計だと、たとえばnetworkモジュールの変数が増えたときにconsul_clusterモジュールにも追加しなければならず、保守の手間がかかります。モジュールの結合度が強すぎるわけです。ぼくが設計を失敗したのは、モジュールAとモジュールBの共通部分をモジュールCに切り出し、内部的に参照させたケースでした。開発途中で変数の引き回しが面倒になり、結果的にModule Compositionに従うこととなりました。最初から従っていれば、無駄な工数が省けたはずです。Dependency Inversion（依存性の逆転）モジュールがフラットになれば、下記のような記述も可能になります。data "aws_vpc" "main" {  tags = {    Environment = "production"  }}data "aws_subnet_ids" "main" {  vpc_id = data.aws_vpc.main.id}module "consul_cluster" {  source = "./modules/aws-consul-cluster"  vpc_id     = data.aws_vpc.main.id  subnet_ids = data.aws_subnet_ids.main.ids}つまり、networkモジュールを使わずとも、consul_clusterモジュールが使えるわけです。このように、モジュールで必要となるリソースをルートモジュールから渡す設計が「Dependency Inversion」です。ぼくはこの点も考慮が不足していて、前述のモジュールCにおいて、モジュールA・Bのリソース命名規則に依存した処理を記述してしまいました。Module Compositionに従って構成をフラットに変えたものの、結合度の強さは変わらぬままでした。命名規則が変わるたび、モジュールCにも手を入れなければなりません。そこで、モジュールCで必要となるリソースを、モジュールA・Bから渡してもらう設計に見直しました。Terraformドキュメントにあるように、object型の変数を定義すると、リソースが渡しやすくなります。variable "ami" {  type = object({    # Declare an object using only the subset of attributes the module    # needs. Terraform will allow any object that has at least these    # attributes.    id           = string    architecture = string  })}アンチパターン：リソースがなければ作成するまた、Terraformドキュメントでは「リソースがなければ作成する」（Conditional Creation of Objects）設計も避けるよう勧めています。もし不足しているリソースがあれば、ルートモジュール側で作成するほうが、あとで読む人が理解しやすいためです。ぼくはこの点も考慮不足で、条件式の結果を count に代入し、リソースを作ったり作らなかったりする記述をしていました。ただ、当該リソースを参照するのに条件式をいろんな場所で書かなければならず、不便でやめました。こちらも最初から従っていれば、無駄な工数が省けたはずです。まとめ以上、Terraformモジュール構成のベストプラクティスを、ぼくの失敗談をまじえてお伝えしました。結論として、下記の点に気をつけるとよいでしょう。他のモジュールに依存したモジュールは作らない条件式に依存したリソース作成はなるべく避ける（作成後に参照しないならOK）ぼくも、またTerraformモジュールを作る機会があれば気をつけます。

Terraformモジュール構成のベストプラクティス

ENECHANGEのI/O Dayは、新しい技術の習得と活用を促進するための社内イベントです。参加者の目的は、未経験の技術や新しいツール、他事業部で採用されている技術について学び、それをアウトプットを通じて共有することです。VPoT 岩本隆史I/O Dayを通じて技術革新の促進を！ 開催の経緯と目的ーー I/O Day導入の経緯について教えてください岩本：I/O Dayは、エンジニアの開発者体験を向上させるための取り組みとして導入されました。まず、社内で開発者体験をどう向上させるかについてのアンケートを実施しました。その結果、社内のエンジニアから「Googleの20%ルール」のような施策が欲しいという意見が寄せられました。この意見をもとに、私が中心となって具体的な計画を立て、I/O Dayの実現に向けて動き始めました。こうして、エンジニアが新しい技術を学び、業務に活かす機会を提供するI/O Dayが実現しました。ーー I/O Dayの特徴とは何ですか？岩本：I/O Dayの主な特徴は以下の4つです。最新技術の探求知識の深化と共有実践的な学び組織の技術レベルアップへの貢献ーー 続いて、I/O Dayの目的について教えてください！岩本：I/O Dayの開催の目的は以下の2つです。所属エンジニアの開発者体験向上エンジニアの採用強化I/O Dayの開催は、ENECHANGEがエンジニアにとって魅力的な企業となるための一歩です。このイベントを通じて得られた知識や技術は、日々の仕事やプロジェクトに直接役立ち、新しいアイデアの創出や会社全体の競争力の向上にも繋がります。I/O Dayの案内資料I/O Dayイベントを通じた社員の意見把握ーー I/O Day 参加対象者と成果物について教えてください！岩本：今回のI/O Dayの参加対象者は、各事業部（エネチェンジ事業部、エネルギークラウド事業部、EV充電サービス事業部）に所属するエンジニアであり、マネージャーは対象外としています。初めての試みであるため、できるだけ多くのエンジニアに参加してもらい、このイベントが本当に価値のあるものかどうかを評価することを目的に、全員に必須参加をお願いしました。エンジニアたちは事業部の垣根を越えて協力し合い、初回のI/O Dayの日程を5月15日に合わせるための調整や、専用のSlackチャンネルを作成するなど、積極的な姿勢を見せてくれました。また、初回のI/O Dayでは、個人ブログの投稿や社内LTの実施など、多様なアウトプットが見られました。Q3以降もI/O Dayを継続するかどうかは、参加者からのフィードバックに基づいて決定されます。エンジニアたちの成長と企業全体の技術力向上に寄与するイベントとして、I/O Dayが定着することを目指しています。ーー I/O Dayに参加するとどんなメリットがありますか？岩本：業務に没頭していると、自分の成長を実感しにくいことがありますよね。例えば、プロジェクトが3ヶ月間に及ぶ場合に同じ業務を淡々とこなしているだけだと、自分の成長が遅れているのではないかという不安が生じます。そんな不安を払拭し、さらなる成長を促進するために、I/O Dayは非常に価値のある機会だと感じています。I/O Dayに参加することで得られるメリットは、大きく3つあります。自分の成長を実感できる　日々の業務では、目の前のタスクに追われ、自分の成長を実感しにくいことがあります。しかし、I/O Dayでは、最新技術やトレンドに触れ、様々なセッションに参加することで、短期間で幅広い知識とスキルを習得することができます。本当にやりたい仕事を見つけられる　仕事においては、本当にやりたいことができることに大きな価値があります。I/O Dayでは、自分が興味を持ち、情熱を持って取り組める仕事を見つけることができます。新しい技術の習得や問題解決能力の向上が見込める　新しい技術やツールを実際に手を動かして学ぶことで、様々な場面での活用可能性や問題解決能力の向上につながります。　I/O Dayを成功に導くためにとった具体的なアクションーー I/O Dayのテーマ設定方法はどのようにされていますか？岩本：今回私は、I/O Dayの開催を推進したものの、具体的なテーマ設定には関与しませんでした。エンジニアたちは自身でやりたいテーマを決め、マネージャーに許可を得て参加しています。今回のI/O Dayでは、業務に関連し、今後取り組むべきテーマを選定して進めるようお願いしました。多くのエンジニアが、業務をしている上で気になっているが手がつけられていないテーマに取り組みました。具体的には以下の項目です。未導入技術の評価トイルの削減オンボーディングプロセスの改善また、アウトプットに対しては必ずCTO室からコメントをするようにし、エンジニアの成長とモチベーションの向上を図っています。ーー I/O Dayを実施してみて課題はありましたか？岩本：I/O Dayを最初に提案した際、アウトプットの具体的な内容については考えていませんでした。しかし、成果が目に見えないという意見もあり、参加者にはアウトプットも求めることにしました。ですが、1日でアウトプットまで完了するのは難しいという現実も見受けられたため、今後は1日のインプットと別の日にアウトプットを行うようなスケジュールも検討する余地があると感じています。また、期間が短いとやりたいことのテーマ選定の幅が狭くなるリスクもあります。参加者が自分の興味や得意分野に応じて取り組めるテーマを広げることが重要だと考えています。エンジニアがよりI/O Dayを満足できるようにーー I/O Dayの今後の展望について教えてください岩本：まずは、I/O Dayを実施して良かったと感じています。参加者からの意見を参考にして、今後さらに改善していきたいと考えています。I/O Dayを実施する目的は開発者体験の向上と社外へのアピールです。そのため、今後は参加者がより満足できるような取り組みを積極的に導入していきたいと思っています。特に、エンジニアにはテックブログを書いてもらいたいと考えています。これにより、社内外へのエンジニアに技術的な知見を共有し、企業の技術力向上に寄与できると考えています。私自身が直接お願いして、積極的にブログの執筆を進めていきたいと思っています。最後に、I/O Dayを社内の声を反映させて実施できたことが非常に良かったです。意見を出してくれたメンバーにも感謝しています。（以上）参考記事I/O Dayのエンジニアの具体的アウトプットについては、本ブログにいくつか記事があります。よかったらこちらもご覧ください。tech.enechange.co.jptech.enechange.co.jp

ENECHANGEの新たな取り組みI/O Dayとは？ 技術革新の現場をインタビュー！

ENECHANGEの Yuto Ono です。エンジニアリングマネージャーをしながら、フロントエンドの開発もしています。React を使った開発で悩むポイントの1つとしては、 useEffect の使い方だと思います。何でもできる魔法のようなフックですが、それゆえに、間違った使い方をされることも多い印象です。そこで今回は、最近遭遇した useEffect のアンチーパターンと、それの対処法を紹介していこうと思います。こちらの公式ドキュメントに、さらに詳しく書いてありますので、詳しく知りたい方はこちらをご参照ください。ja.react.devなお、最近のフロントエンド開発では TypeScript を使うことが多いですし、弊社でも TypeScript を使っていますが、今回は型についての話はしないので、 JavaScript でコードを記載しています。useEffect のアンチパターンとしてよく取り上げられるのが、他の props や state から計算できるものを、新たな state を用意して useEffect の中で更新してしまう例です。function Component({ firstName, lastName }) {  // ダメ  const [fullName, setFullName] = useState('');  useEffect(() => {    setFullName(firstName + ' ' + lastName);  }, [firstName, lastName]);  // ...}こちらのコードが良くないのは、ぱっと見て気づく方も多いのではないでしょうか。なぜダメかというと、この書き方だと余計なレンダリングが発生しパフォーマンスが悪化するprops が更新されたタイミングで1回目のレンダリング1回目のレンダリングで発火した useEffect 内の state 更新により2回目のレンダリングコードが必要以上に複雑になり可読性が低下これを改善すると下記のようなコードになります。function Component({ firstName, lastName }) {  // Good  const fullName = firstName + ' ' + lastName;  // ...}こちらの方がシンプルですし、パフォーマンスも良くなりますね。この程度であれば、一定の実力のあるエンジニアはほとんどこのようなミスはしないのですが、複雑なパターンになると、意外と経験者でもアンチパターンで実装してしまうことがあることに最近気がつきました。最近のコードレビューで指摘したケースは、簡単に書くと、以下のようなコードでした。function Component({ firstName, lastName }) {  // ダメ  const [fullName, setFullName] = useState('');  useEffect(() => {    if (firstName === '') {      setFullName(lastName);    } else {      setFullName(firstName + ' ' + lastName);    }  }, [firstName, lastName]);  // ...}確かに、条件分岐などのロジックが入って、1行で書けなくなると、つい useEffect を使いたくなる気持ちもわかりますし、実際のコードはこれよりももっと複雑だったりします。しかしよく考えると、これも他の props や state から計算できるという点で、最初に掲載したアンチーパターンと本質的には変わりません。これに対する自分なりの筋の良い対処法は2つあります（もちろん他にも方法はあると思います）。1) fullNameを計算する関数を作るfunction calcFullName(firstName, lastName) {  if (firstName === '') {    return lastName;  }  return firstName + ' ' + lastName;}function Component({ firstName, lastName }) {  // Good  const fullName = calcFullName(firstName, lastName);  // ...}こっちの方がシンプルでコードの意図も伝わりやすくて良いですね！ 僕もよく使う方法です。2) useEffect の代わりに useMemo を使うfunction Component({ firstName, lastName }) {  // Good  const fullName = useMemo(() => {    if (firstName === '') {      return lastName;    }    return firstName + ' ' + lastName;  }, [firstName, lastName]);  // ...}useMemo を使うことにより他の state や prop から値を計算しているという意図が伝わりやすく、良いですね。もしかしたら、わざわざ（計算量的に）メモ化する意味あるの？というツッコミが入りそうなので念のため補足しておくと、確かに公式ドキュメントにもある通り、よっぽど重い処理でなければ、メモ化による最適化の恩恵を受けることはありません。とはいえ、useEffect と違って余計なレンダリングが発生しない点や、可読性が向上するなどのメリットを考えると、十分に使う価値があるのではないかと思っています。また公式ドキュメントにも過度なメモ化を行うことによる重大な害はないとはっきり書いてあるので、迷ったら使うぐらいのスタンスで問題ないと思っています。以上、最近見かけた useEffect のアンチーパターンとその対処法の解説でした。ぜひ今後の参考にしていただければ幸いです！

最近遭遇した useEffect のアンチパターンを紹介 【React】

はじめに初めまして！2024年2月からWebエンジニアとしてENECHANGEの就業型インターンに参加している植月です。現在は大学院修士2年生で計量経済学系の研究室に所属しており、普段は主に一人、チーム問わずWeb開発をしています。約半年間、インターン生としてENECHANGEで働くことで学んだことや感じたことを書いていこうと思います。参加したきっかけENECHANGEさんと初めて接点を持ったのは、とある面談イベントでCTOの有田さんとお話しをさせていただいた時です。いきなりCTOの方と話すのはとても緊張したのですが、滅多にない機会、かつ就活中だったということもありいろんな人の話を聞いておいたほうがいいだろうと思い参加させていただきました。面談ではChatGPTがソフトウェア開発をどのように変えていくか、今後ENECHANGEをどうしていきたいかといったお話を熱く語っていただいたことを覚えています。とても面白そうな事業内容かつ、素敵な人柄に惹かれ、その後のアンケートでもう一度面談を希望する旨を伝えると、後日、再度面談を組んでいただき、その後インターンに参加することが決まりました。インターン業務内容ENECHANGEはEVsmartという日本に存在する電気自動車の充電器スタンドを検索できるサービスを展開しています。自分の担当領域はそこで表示される充電器等のデータを、社内のデータ管理チームが扱えるようにするための社内ツールの開発です。実はこのメンテナンスツールはversion2からversion3に移行中で、担当開発陣は近々本番環境で使用されることになるversion3の開発を主に行っています。使用技術はバックエンドがGolang、フロントエンドがNext.jsで、チーム全員がフルスタックに開発を進めています。自分もバックエンド、フロントエンド問わず様々なタスクをアサインされています。また、自分のチームではスクラム開発というものを採用しており、小規模なチームが短期間のスプリントと呼ばれる期間を設定し、その期間内であらかじめ目標として設定した成果物を生み出すサイクルを繰り返していきます。自分のチームでは2週間を1スプリントとしており、隔週金曜日にスプリントレビューという、データ管理チームにスプリント中に追加した機能などを説明する時間が設けられていました。インターンで得られた経験業務レベルの実装コードに触れる機会自分が今まで携わってきた開発では、年季が入っており技術負債が積み上がっているものや、個人で開発した無茶苦茶なコードがメインだったため、インターンに初めて参加した時はコードの読みやすさに感動したのを覚えています。同チームのエンジニアの方々はシニアレベルの技術力を有しており、実際に彼らのコードを一行一行読み解く過程で、ただ言語・フレームワークの理解だけではなく、ドキュメントにないドメイン知識についても自然と理解することができていました。Golangに関する知見自分はENECHANGEでインターンをするまでGolangについての知見がなかったのですが、業務で使用&勉強会に参加したことで、業務に支障をきたさない程度ではありますが、問題なく使用できるようになりました。また、自分のチームではGinというフレームワークを使用しているのですが、Ruby on RailsやLaravelといったフルスタックなフレームワークと比較すると自由度が高く、開発者側がある程度アーキテクチャの設計を行わなければなりません。DDDやアーキテクチャ等の概念を押さえた上で開発を進める必要があるため、そういった意味でもスキルアップした実感があります。インターンのいい点インターン生としてではなく一人のエンジニアとして扱ってくれるこれまで自分が参加したインターンでは、インターン生のためのタスクがあらかじめ作成されており、期間中はそのタスクにアサインされるものが多かったのですが、ENECHANGEではプロジェクトを進めるにあたって、その都度必要なタスクが振られます。またこれは任意ではありますが、毎週開かれている職種を跨いだミーティングにも参加することができます。自分の今行っているプロジェクトの位置付け、他チームのプロジェクト内容、ビジネス職の人たちとの関わりなど、学生ではなかなか見ることのない、会社内部の動きを垣間見ることができます。社員の方々と話す機会ENECHANGEでは所属部署ごとに優先出社日というものがあり、自分の所属は毎週水曜日に出社が推奨されています(必須ではありません)。自分も都合がつく日はなるべく出社しています。出社した日はお昼時になると社員の方々とランチにいくのですが、職種を問わずいろんな人とお話しする機会があります。他チームのエンジニアの方からビジネス職の方、執行役員、CTOといった様々な方とお話しさせていただくことで、自分が社会に出てから何をしたいか、どのようになっていたいか、改めて考えるきっかけになりました。最後に基本リモートでのインターンですが、わからないことがあってもマネージャーの方はもちろん、チームメンバーやその他の社員の方々に丁寧に質問対応していただいているおかげでとても快適に開発することができています。非常に学びのあるインターンであるため、ご興味がある方は是非ENECHANGEのインターンに参加してみてください。インターンの詳細は下記リンクをご参照ください。newgrads.enechange.co.jp最後までお読み頂きありがとうございました。

インターン生として半年間ENECHANGEで働いてみて

こんにちは、EV充電サービス事業部でFlutterエンジニアをしている小林です。2023年12月に弊社とSmart Shopping様と共同で「IoT系のプロダクト開発の裏側」というテーマのオフライン勉強会を開催いたしました。その中で「事業譲渡を受けたアプリとの統合で失敗、 そしてユーザーからの評価回復に至るまで」というタイトルで発表した内容を、改めてブログ記事としてまとめます。また、その後日談についても触れようと思います。enechange-meetup.connpass.com背景ENECHANGEでは2022年春にEVの充電サービスとアプリをローンチしました。このアプリのコアとなる機能はもちろんENECHANGEが設置する充電器で充電することです。しかし私たちが目指しているのは、すべてのEVドライバーにとって価値のあるアプリになることです。そのためにも自社設置の充電器だけではなく、日本中のあらゆる充電スポットを探すことのできるアプリになる必要がありました。その目的を果たすため、ENECHANGEは2022年9月にアユダンテ株式会社のEVsmartという事業を譲り受けました。EVsmart事業では独自に収集した日本中の充電スポットを網羅したデータベースと、それを探すことのできるモバイルアプリを提供していました。この事業譲受のニュース掲載とほぼ同じタイミングで、私はENECHANGEにFlutterエンジニアとして内定をいただいただきました。しかも、EVの納車直前でEVsmartアプリを使って付近の充電環境を調べていた最中だったため、このニュースにはとても驚き、そしてワクワクしたのでした。入社早々、私はEV充電エネチェンジアプリとEVsmartアプリの統合プロジェクトにアサインされ、この２つのアプリの統合を主導することになりました。この時点で両アプリの機能差分が一覧化されており、EV充電エネチェンジアプリの方に不足機能を移植していくという方針までが決まっている状態でした。アプリ統合のための泥臭い取り組みアプリ統合に取り組み始めて最初に突き当った壁は、EVsmart事業の複雑性でした。EVsmartアプリはEV充電エネチェンジアプリに統合することが決定していましたが、EVsmartアプリと同等の機能をもつウェブサイトやOEMアプリなど提供しているプロダクトが多く、かつそれらは同じバックエンドを参照していました。つまり、統合のために機能に手を加えると、それらのすべてのサービスに影響してしまうのです。このような複雑性から、開発チーム内での設計の議論が停滞してしまい、前に進まない状態に陥ってしまいました。事業目線ではEVsmartアプリのユーザーにエネチェンジの充電器を使ってもらいたく、アプリ統合もなるべく早く終える必要があります。しかしながら統合はそんなに簡単なものではありません。そのため、EVsmartアプリの方にEV充電エネチェンジの充電スポット情報を掲載し、かつその画面からEV充電エネチェンジアプリへ誘導するディープリンクを設置することにしました。これで自社充電器への集客もある程度でき、統合までの時間かせぎとなりました。確保した時間で改めて複雑性に向き合いました。これは本当に泥臭い作業です。EVsmartアプリとそのサーバーサイド、EV充電エネチェンジアプリとそのサーバーサイド、その両方のシステム構成や設計を把握するため、とにかくEVsmart事業と自社のエンジニアにたくさんの質問をしました。そしてアプリ・サーバーサイド問わず、あらゆるコード（PHP、Ruby on Rails、Swift、Kotlin、Dart、・・・）を読みました。最初は大海を泳いでいるような感じでしたが、だんだん島の輪郭が見えるようになってきました。把握できたシステム構成などはなるべくわかりやすい図におこし、開発に関わるメンバーが誰でも理解できるような状態にしました。これにより「現状がこうなっているなら、このようにシステム間を繋ぐといいね」といった議論がようやく進むようになってきました。前述のとおりアプリ統合の都合だけで機能に変更を加えてしまうと、関連するプロダクトに影響が出てしまいます。その影響を最小限にするため、EVsmartのバックエンドは極力変更せずに統合を進める方針に決めました。システム構成を紐解いたことで、定期的なデータベース同期を行うことと、EV充電エネチェンジアプリのAPIサーバーが、EVsmartのバックエンドとの仲介役となれば、一通りうまく統合できそうだという目処がついたのです。このような苦労の末、2023年6月末に予定通り統合したアプリをリリースすることができました。しかしこの時点で重要な点を見逃していることに私たちは気づけていませんでした。リリース後にアプリストア評価が⭐️１に...リリース後、多くのEVsmartアプリユーザーから元のアプリに戻してほしいという声をいただきました。その声はすぐさまアプリストアの評価にも表れ、iOSアプリは⭐️1.4まで下がってしまうことになりました（iOSは統合のタイミングでストア評価のリセットをしてしまったことも影響しています）。EVsmartアプリもEV充電エネチェンジアプリも統合前は⭐️3〜4で一定の評価をいただけていた状態だったのですが、一体何が起きてしまったのでしょうか。EVsmartのみ提供していた機能については、概ねEV充電エネチェンジアプリへの移植ができていましたし、リリース後も目立った不具合は出ていません。EVsmartアプリからEV充電エネチェンジアプリへのユーザー移行も社内のEVsmartヘビーユーザーが驚くほどにシームレスにできたという自負もあります。しかし私たちはEVsmartアプリのコアバリューである「マップで充電スポットを簡単に探せる」というUXレベルの高さを見逃していたのでした。マップで充電スポットを探すための機能一覧ではその差はほとんどありませんでしたが、それぞれの機能の使いやすさはEVsmartアプリに比べると劣る部分が多い状態でした。また、EVsmartアプリユーザーにとってはUIが大きく変化してしまったことも影響していたと思います。アプリストア評価回復のための泥臭い取り組み開発チームはストアの評価回復を最優先課題として取り組むことになりました。まずはユーザーからの声をすべて集めることから始めました。アプリストアへのレビュー投稿やカスタマサポート窓口への問い合わせ、Twitter（現在のX）などのSNSへの投稿（毎日エゴサーチ）、社内のEVドライバーやその知り合いからの声、そしてEVsmart事業譲受前のプロダクトオーナーからの意見、それらすべてを集約しました。集まった声は約250件。これらすべてに目を通し、整理・分類してどの問題から解消すべきか優先度づけを行いました。また、自動的に集められるものは事業部のSlackにも通知し、この現状を事業部メンバーが肌で感じることで、対応の温度感を高めました。対策検討には社内のEVドライバーも巻き込み、いただいた声の本質的な問題は何かをEVドライバー目線で理解するように努めました。そして、優先度の高いものはなるべくミニマムに改善してすぐにリリースするようにしました。根本的な問題解消には時間がかかるようなものでも、少しの改善でその問題の半分でも解消されるのであればそれでリリースするというスタンスです。なるべく早くユーザーの痛みを少しでも解消したかったのです。統合したアプリのリリース後、毎週の頻度でアプリの改善版をリリースし、約2ヶ月間で7回のリリースを行いました。また、リリース内容はSNSを通じてもユーザーに伝えるなど、ユーザーとのコミュニケーションも強化しました。このような取り組みが徐々にユーザーに受け入れられ、SNSでも好意的な意見をいただけるようになりました。それまでは厳しい意見が続いていましたたが、その穴から一旦脱出できたという実感がありました。ここまでの取り組みにより、充電スポットを探すというUXレベルもEVsmartアプリに近いものになりました。改善活動の中で「急速充電スポットはマップのピンでその最大出力を表示する」というEVsmartアプリにはなかった機能を開発したのですが、それは特に多くのユーザーから好意的な声をいただくことができました。しかしながらアプリストアの評価は大きく回復しませんでした。ネガティブな評価に比べるとポジティブな評価は待っていてもつきにくいものです。であればこちらから評価をいただけるように対策する必要があります。その頃ちょうど弊社ではEV充電エネチェンジのPRのためにEVドライバーが集まるイベントへの出展をはじめていました。そこで、開発メンバーも参加しユーザーの声を直接伺いにいくことにしました。イベントに集まってくださるEVドライバーの方には、現状のアプリへの率直なフィードバックとストアの評価を依頼しました。ご意見をいただけた方には、それがポジティブ・ネガティブどちらであるかに関わらず、ノベルティのプレゼントでお礼させていただきました。結果としては、改善したアプリはポジティブに受け入れられており、⭐️4,5といった評価をたくさんいただくことができました。また、この2ヶ月でやってきた改善活動を見ていてくださったユーザーから温かい声をかけていただけたことで励みになりましたし、さらに良くするためのアドバイスをいただいたりと、とても貴重で有意義な機会となりました。直接的な評価回復策ではありませんが、ストア評価の変化を毎日自動的にチェックしてSlackの事業部チャンネルに投稿するようにしました。高めの評価がいただけるようになったことで、日々数字が改善していく過程を社内に伝えることができました。開発チームのモチベーションにもつながったのも良かったです。イベントでの評価獲得はとても効果が高かったのですが一時的なものですので、継続的に新規ユーザーの評価が得られるような仕組みも必要です。そして、ユーザーが本当にアプリで良い体験をしたと感じてもらえた時に評価を依頼できるのがベストだと思います。幸いなことにEV充電エネチェンジには「アプリで簡単に速く充電してもらう」というコアバリューがありました。ENECHANGEでは、現時点で広く普及している普通充電器の倍の出力を持つ充電器のみを設置しており、この強みはどんなEVドライバーにも魅力的なものでした。そこで、ユーザーにとって満足する充電ができたと思われるタイミングでアプリから評価を依頼するようにしました。このような策がしっかり機能したおかげで、アプリを統合して５ヶ月後（2023年12月）までに300件近い評価をいただき、⭐️3.5まで回復させることができました！まとめこのEVsmartとEV充電エネチェンジアプリの統合プロジェクトを経て、統合する両アプリが提供する価値のレベルを下げてはならないということを学びました。今から思えばですが、リリース前に十分なベータテストを行えていれば、リリースを中断するような判断もできたでしょうし、そもそも統合プロジェクトにおけるプロダクトマネジメントが機能するような体制構築ができていれば良かったな、など反省点はたくさんあります。この失敗経験を今後の開発に活かし、より良いプロダクトをユーザーに提供していきたいと考えております。この失敗後のアクションはとても良く機能したと思います。やはりユーザーが何に困っているのかを正確に把握し、その痛みを的確に解消していくような改善活動はユーザーにしっかり伝わります。大きな機能追加も大事ですが、細部の質を上げていくこともユーザーの評価につながることを実感できました。また、アプリのポジティブな評価を得るには待っているだけではダメで、アプリのコアバリューの部分を武器に評価をもらいにいくような取り組みが必要であることもわかりました。そのためにも、アプリに明確なコアバリューがあることは必要条件となりますし、それを磨き続けていくことも重要なのです。そして、私たちのコアバリューは誰にとっても使いやすい持続可能なEV充電インフラを提供することです。EV充電エネチェンジではこれからもこのコアバリューを磨き続けていきますので、応援していただけると幸いです。後日談オフライン勉強会でのこの発表から約半年が経過しました。この間も充電インフラ環境づくりのためのユーザーを巻き込んだ取り組みである「エネチェンジサポーターズ」発足や、この6月初には日中の電力を有効活用した定額プラン「エネチェンジパスポート」といった新しい価値提供のための機能開発を進めてまいりました。もちろん細かな改善活動もEVドライバーイベントへの参加も続けております。2024年4月にテスラオーナーズクラブ主催の全国ミーティングに参加した時の様子おかげさまでアプリストアでも安定的に高い評価をいただけるようになっており、iOS・Androidともに ⭐️4.1 に到達いたしました！これもEV充電エネチェンジを応援してくださる皆様のおかげです。重ねてになりますが、EV充電エネチェンジは誰にとっても使いやすい持続可能なEV充電インフラを拡大すべく尽力してまいりますので、引き続き応援のほどよろしくお願いいたします！アプリストア評価の推移

事業譲渡を受けたアプリとの統合で失敗、 そしてユーザーからの評価回復に至るまで

こんにちは、ENECHANGEの園木です。設定ファイルも用意していますので、興味がある方はぜひ目を通してみてください。CodeRabbitとは？CodeRabbitは、自然言語モデルAIを使用してGitHubプルリクエストのコードレビューと要約を行います。HP: https://coderabbit.ai/ja/GitHub: https://github.com/coderabbitai/ai-pr-reviewerしくみCodeRabbitはGitHub Actionsを用いてAIレビューをおこないます。出力されるものCodeRabbitを導入した場合の実際のアウトプット物を紹介します。1. リリースノートPRコメントの末尾にPRの目的レベルでの説明が記載されます。New Feature：新機能Bug Fix：バグ修正Documentation：ドキュメントRefactor：リファクタリングStyle：スタイルTest：テストChore：雑務Revert：取り消し今回は「CodeRabbitを実装する」という内容なので新機能として説明されています。この箇所はGitHub Actionsが走るたびに内容が更新されます。2. 要約PRの差分を要約します。画像はオリジナルから項目を変更したものです。要約PR全体の変更点を完結に説明してくれます変更点差分ファイルごとにどのような変更がなされたかを要約してくれますこの箇所はGitHub Actionsが走るたびに内容が更新されます。3. コードレビュー差分を元に、AIがコードレビューをしてくれます。レビューのサマリー指摘箇所のレビュー指摘箇所のレビューという形式でコメントが追加されます。プロンプトに沿ったレビューをするので、各チームごとに視点を言語化しておくと良さそうです。準備GitHub Actions実行ファイルの作成.github/workflows配下にGitHub Actions用のyamlファイルを作成します。.github/workflows/code-rabbit.yamlにしました。OpenAI API KEYの設定下記URLにてOpenAIのAPI Keyを取得します。https://platform.openai.com/api-keyshttps://github.com/username/repository-name/settings/secrets/actions OPENAI_API_KEYを新規で作成し、OpenAI API Keyを設定します。デフォルトでの実行https://github.com/coderabbitai/ai-pr-reviewer?tab=readme-ov-file#install-instructions  code-rabbit.yamlを設定し、CodeRabbitが起動するかどうかを確認します。無事にGitHub Actionsが走り、CodeRabbitによるレビューが追加されたらひとまずの実装は完了です🎉最終的なファイルまずは完成形から見せてしまいます。code-rabbit.yamlは最終的に以下のようになりました。設定ファイルname: CodeRabbitpermissions:  contents: read  pull-requests: writeon:  pull_request:    types: [opened, ready_for_review]concurrency:  group:    ${{ github.repository }}-${{ github.event.number || github.head_ref || github.sha }}-${{ github.workflow }}-${{ github.event_name == 'pull_request' && 'pr_event' || 'pr' }}  cancel-in-progress: ${{ github.event_name != 'pull_request' }}jobs:  review:    runs-on: ubuntu-latest    steps:      - uses: coderabbitai/ai-pr-reviewer@latest        env:          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}        with:          openai_light_model: gpt-4o          openai_heavy_model: gpt-4o          language: ja-JP          summarize: |            次のmarkdownフォーマット形式を使用して、本PRの要約を出力します。            [出力形式]            ## 要約                        ## 変更点            以下では、デフォルトから変更した項目について説明します。トリガーの設定を変更する（GitHub Actionsの設定）デフォルトの状態では新規PRが作成されたときpushされたときで毎回ワークフローが走ってしまうので、以下のタイミングをトリガーにしました。新規PRが作成されたときPRがDraftからOpenに変わったときこれにより、開発者の任意のタイミングでAIレビューをすることができます。CodeRabbit独自の設定項目jobs:  review:    steps:      with:配下に独自に設定できる項目があります。https://github.com/coderabbitai/ai-pr-reviewer/blob/main/action.yml openai_light_model, openai_heavy_modelレビューに使用する言語モデルを指定することができます。openai_light_modelとopenai_heavy_modelは以下のように使い分けられているようです。openai_light_model変更点の要約など、軽微なタスクopenai_heavy_modelレビューやコメントといった複雑なタスク参考デフォルトではgpt-3.5-turboとgpt-4になっています。gpt-4oに変更しました。openai_light_model: gpt-4oopenai_heavy_model: gpt-4o理由は以下です。GPT-3.5での要約は信頼性と再現性が低いGPT-4よりもGPT-4oの方が高性能かつ安価参考: 言語モデル別の価格https://openai.com/api/pricing/languageレビューの言語を設定します。language: ja-JPちなみに、この項目で言語設定しておけばプロンプトを日本語訳して設定し直す必要はないハズです。summarizeデフォルトで指定されているWalkthroughという言葉に馴染みが無かったので要約に変更しました。Poemが入ってるので、削除しました。出力形式をマークダウンフォーマットで指定し、各項目で何を出力するのかはコメント形式で指定しました。その他の設定その他にも設定可能な項目がいくつかありました。path_filtersCodeRabbitによるレビューをスキップするファイルdisable_reviewデフォルト値: falsetrueにすることでレビューをスキップさせることが可能disable_release_notesデフォルト値: falsetrueにすることでリリースノートの作成をスキップさせることが可能openai_model_temperatureデフォルト値: 0.050-2の範囲で変更可能。大きくするとより不確実性が増すtempratureって何？という方はこちらsystem_messageCodeRabbitのシステムプロンプトどんな観点でレビューして欲しいのかを設定可能summarize_release_notesリリースノート作成用のシステムプロンプト実際どうなの？実案件で作成されたPRをCodeRabbitにレビューさせた感想は以下です。nil対策をしてくれるnilに対するエラーハンドリングをしていない箇所に対して指摘してくれましたタイポを指摘してくれるメソッド名のタイポを指摘してくれました全体的にtoo muchなレビューではありますが、「指摘された箇所の修正が不要であること」をPR作成者がコメントした上でレビュワー（人間）に渡すことでコードの理解度は増すと思います。また、CodoRabbitが作成した文章はすべてマークダウンで書かれているので、これを編集することで人間がゼロから書く作業コストを削減できます。個人的な結論としては、CodeRabbitは現状でも十分に活用可能なレベルであり、導入することで得られるメリットの方が大きいと感じています。ENECHANGEでは成長意欲の高いエンジニアを募集しています！弊社はエネルギーの未来をつくるというミッションを掲げています。www.wantedly.com参考https://zenn.dev/minedia/articles/7928ef7545b393

AIレビューツールであるCodeRabbitを試してみました【設定ファイルあり】

VPoTの岩本 (iwamot) です。ENECHANGEは、2024年3月にAWSパートナーになりました。パートナーパスとして「ソフトウェアパス」を選択しており、将来的にファンデーショナルテクニカルレビュー (FTR) の通過を目指します。aws.amazon.com今回は、ENECHANGEがAWSパートナーになった意図をかいつまんでご紹介します。AWSパートナーはメリットだらけ意図といっても単純で「メリットだらけ」だからです。具体的に、ENECHANGEの期待しているメリットには下記があります。AWS認定の新規取得によるクレジット毎年もらえる3,500ドルのクレジットFTRによるワークロードの改善、認知度の向上AWS認定の新規取得によるクレジットまず「AWS認定の新規取得によるクレジット」について、AWSは下記のように説明しています。・AWS 認定資格新規取得時に AWS クレジットクーポンを進呈( アソシエイト認定取得につき $300 / プロフェッショナルまたは専門知識認定取得につき $500 )APN パートナーになる “３ つの理由” とは | AWS JAPAN APN ブログ実際、ぼくは3月30日にAWS Certified Advanced Networking - Specialty試験に合格しており、500ドル分のクレジット（プロモーションコード）が4月17日にメールで届きました。そのメールによれば、3か月に1度付与される運用のようです。届いたクレジットは、マネジメントコンソールで適用できます。毎年もらえる3,500ドルのクレジット次に「毎年もらえる3,500ドルのクレジット」についてです。AWSは下記のように説明しています。APN セレクトパートナー以上の皆さまは、毎年の更新時に年会費 ($ 2,500) をお支払い頂いていますが、同時に $ 3,500 (アドバンスドパートナーは $ 5,000 ) の AWS クレジットクーポンでお返しさせて頂いています。APN パートナー様の自社システムや開発環境などでご活用頂けます。APN テクノロジーパートナー “10 のメリット” をご紹介！ | AWS JAPAN APN ブログつまり、年会費の2,500ドルを差し引いても、1,000ドルのプラスになるわけです。日本円だと現時点で157,500円ほどのプラスになります。年会費は6月4日に支払っており、クレジットが届くのを待っているところです。FTRによるワークロードの改善、認知度の向上最後に「FTRによるワークロードの改善、認知度の向上」についてです。AWSは下記のように説明しています。FTR とは、お客様がお持ちのソフトウェアやソリューションが、AWS のベストプラクティスに基づいて実装および運用されているかを、あらかじめ定義されている共通要件に従って検証するパートナープログラムです。すべての要件を満たしてレビューを通過すると、AWS 認定ソフトウェアとして AWS Partner Solutions Finder (PSF) に掲載され、「AWS Qualified Software」ソリューションバッジを利用できるようになります。AWS ファンデーショナルテクニカルレビュー (FTR) とは | AWS JAPAN APN ブログ最初からすべてのベストプラクティスを実装しているワークロードはまずないので、レビューの通過にはワークロードの改善が求められます。首尾よく改善できたら、サービスを実装・運用しているエンジニアの自信になりますし、なによりご利用いただいているお客様の安心にもつながるはずです。また、PSFに掲載されれば、市場認知度の向上も期待できます。まとめENECHANGEは、以上のメリットに期待してAWSパートナーとなりました。AWS認定の新規取得によるクレジット毎年もらえる3,500ドルのクレジットFTRによるワークロードの改善、認知度の向上引用したAWS公式ブログの各記事には、これら以外のメリットも書かれているので、ぜひご参照ください。aws.amazon.comaws.amazon.comAWSパートナーになることを検討される場合は、下記の記事で紹介されている説明会動画をご覧いただくことをお勧めします。aws.amazon.com

メリットだらけなので、AWSパートナーになりました

ENECHANGEの Yuto Ono です。 最近はエンジニアリングマネージャーに任命され、引き続き手を動かして開発しながら、メンバーの育成などにも取り組むようになり、マネジメントの面白さと難しさを実感しています。今回は、前から気になっていた Rails + Hotwire という技術スタックを触ってみたので、それについて書いていきたいと思います。私はフロントエンドが得意分野なのですが、Railsもそれなりに触っているので、Railsでのフロントエンド技術をキャッチアップするのに自分が適任だと思いました（私のフロントエンドの実績は、以前 what we use に寄稿させていただいた記事を見ていただくとわかりやすいかと思います）。whatweuse.dev最近弊社では、 I/O Day という制度を試しに実施しており、エンジニアが1日確保して、通常業務の代わりに技術的なインプット・アウトプットができる制度となっております。今回は、ありがたくその制度を使わせていただきました。キャッチアップするにあたり、こちらのZenn本を参考にさせていただきました。ありがとうございます。zenn.dev技術的な解説はこの本に詳しく書いてあるのでそちらに譲るとして、この記事では、Hotwireを触ってみた感想と、使いどころの考察を書いていきたいと思います。Hotwire を試してみた結果弊社で開発している電気の料金シミュレーションサービス「エネチェンジ」を意識し、電力会社の契約履歴や電気代の請求を管理するサービスをさくっと作ってみました。今回のコードはこちらのリポジトリに上げています。github.com参考記事に書いてあるとおり、Hotwire は Turbo、Stimulus、Strada という3つの技術から構成されています。今回は主に Turbo を活用しています（というか、Turbo しか使えていません…）。Turbo を使うと、ページ遷移することなく画面の一部を更新できるようになり、SPA風の挙動を JavaScript を書かずに実現できます。実際の画面で説明すると、契約履歴管理画面で、画面遷移することなく、履歴を追加したり編集したりできるようになります。 JavaScript を書かずにこれを実現できるのは驚きですよね。「新規追加」をクリックしたときの挙動「編集」をクリックしたときの挙動少しだけ Turbo の仕組み説明をすると、通常の一覧表示の行単位の要素と、入力させるフォームを2つとも turbo_frame_tag というヘルパーで囲みます。<%= turbo_frame_tag contract_history do %>  ...<% end %>該当するコードは下記にあります。app/views/contract_histories/_contract_history.html.erbapp/views/contract_histories/_form.html.erbすると、レンダリング時に <turbo-frame> というカスタム要素になります。<turbo-frame id="contract_history_1" ... >  ...</turbo-frame>そして、このカスタム要素の idを目印に、要素の差し替えをしてくれるという仕組みになっています。ついでに ViewComponent も触ってみた他にも Rails のフロントエンド開発に役立つライブラリで気になっていたものがあるので、ついでに触ってみました。それは ViewComponent というもので、これを使うと、 Rails のビューから呼び出せるコンポーネントを作ることができます。まるで React のように、コンポーネント指向で開発することができる、ということですね。このように、Rubyのクラスと erb を書くことでコンポーネントを宣言できます。class PriceComponent < ViewComponent::Base  def initialize(price:)    @price = price  endend<%= @price.to_i.to_formatted_s(:delimited) %>円app/components/price_component.rbapp/components/price_component.html.erbそして、呼び出す側のビューでこのように書くことで呼び出せます。<%= render(PriceComponent.new(price: 5500)) %>app/views/electricity_bills/_electricity_bill.html.erbこの程度だと正直 helper でも十分な気がしますが、活用できる場面は色々とありそうです。また、今回試せていませんが、Hotwire の構成要素である Stimulus とあわせて使うと、各コンポーネントごとの JavaScript のコードを書けそうだったので、結構色々な使い道がありそうな印象でした。使いどころの考察Rails + Hotwire だけでここまでフロントエンドを作り込めるのはすごいと思いました。Vue や React を導入しなくても、ある程度SPA風の挙動にできるので、 Hotwire で十分というケースは結構多いのではないかという印象を受けました。向いているケース小規模なチーム、特にRailsに慣れている人が多いチームUIに強いこだわりがないプロジェクト人員、時間などのリソースに限りのあるプロジェクト弊社では、Rails経験のあるエンジニアが多く、プロジェクトによっては少数精鋭のチームで開発することもあると思うので、Hotwireを選定する可能性は十分にありそうだなと思いました。向いていないケースフロントエンドエンジニアが確保でき、フロントエンドとバックエンドを分業して進めたい場合リッチなUIを実装したい場合後にSPA化する可能性のあるプロダクト（後からSPA化するのはつらそうなので）toC向けのプロダクトで、リッチなユーザー体験に重きを置くプロダクトだと、Hotwireでは厳しい場面も多いと思います。このような場合は、素直に React や Next.js を使ってSPAとして開発していくのが良さそうですね。感想最近の Rails は、最小限の労力である程度のフロントエンド開発もできるようになっていて、進化が凄まじいなと思いました。今後リリース予定の Rails8 も楽しみです。また、新たな技術を実際に触ってみることで、今後技術選定をする際に実際に触ってみた経験を活かせるので、定期的に技術のキャッチアップをしていくのは大事だなと思いました。今後もプライベートの時間や I/O Day などの施策を活用して新しい技術をインプットしていこうと思います！

Rails + Hotwire を試してみて、使いどころを考えてみた

VPoTの岩本 (iwamot) です。100以上のLLMが使えるSlackbot OSS、Collmboを公開したのでご紹介します。github.com要点：ENECHANGEではChatGPT-in-Slackを便利に使ってきたChatGPT-in-SlackでチャットできるLLMはGPTのみ他のLLMも使えるよう、forkしてLiteLLMを組み込んだENECHANGEではChatGPT-in-Slackを便利に使ってきたENECHANGEでは、LLMとチャットできるSlackbotとしてChatGPT-in-Slackを便利に使ってきました。Slack (Salesforce) のseratchさんが開発されたOSSで、さすがのUXです。github.comSlackbotを社内に公開した2023年5月9日から、もう1年あまりになります。その間、ユーザーとして使うだけではなく、Azure OpenAIのサポートやFunction Callingのサポートなどのコントリビュートもしてきました。ChatGPT-in-SlackでチャットできるLLMはGPTのみただ、ChatGPT-in-SlackでチャットできるLLMは、現時点ではGPTのみです。他のLLMのサポート予定もありません。Claude 3を始め、他のLLMも活発に開発されている状況を考えれば、それらともチャットしてみたいところです。特にClaude 3 Opusは、GPT-4にくらべ高いベンチマーク結果を誇っています。他のLLMとのチャットをChatGPT-in-Slackに遜色ないUXで実現するには、別の手段が必要です。どうすべきでしょうか。他のLLMも使えるよう、forkしてLiteLLMを組み込んだぼくの答えは「ChatGPT-in-SlackをforkしてLiteLLMを組み込む」でした。LiteLLMは、OpenAIと（つまりGPTと）同じインターフェースで100以上のLLMが呼び出せると謳うツールです。GitHubのスター数は9,600を超え、2024年4月のTechnology Radarに掲載されるなど注目を集めています。github.comChatGPT-in-Slackをforkし、OpenAIに依存している箇所をLiteLLMに差し替えられたら、オリジナルと遜色ないUXでGPT以外のLLMも呼び出せそうですよね。ということで、実際に進めて公開したのがCollmboです。github.com名前には「共に育てるLLM bot」の意味を込めました。「コロンボ」とお読みください。ちなみにENECHANGEの社内Slackbotは、すでにこのCollmboに置き換え済みです。狙いどおり、ChatGPT-in-Slackに遜色ないUXを維持できています。ただ、残念ながらLiteLLM側に不具合があるため、Claude 3とのチャットはまだ実現していません。バグレポートは出したので、修正に期待しているところです。まとめ今回は、100以上のLLMが使えるSlackbot OSS、Collmboをご紹介しました。要点：ENECHANGEではChatGPT-in-Slackを便利に使ってきたChatGPT-in-SlackでチャットできるLLMはGPTのみ他のLLMも使えるよう、forkしてLiteLLMを組み込んだまた、本文では触れませんでしたが、Collmboにはカスタムコールバック機能も追加済みです。分析用のログ出力などに活用できます。「共に育てるLLM bot」ということで、気軽にお試し・フィードバックいただけると幸いです。

100以上のLLMが使えるSlackbot OSS、Collmboを公開しました

はじめにJaSST Tohokuについて参加目的セッションについて10:30-12:00 (90分)説明できるテストをつくるためにできることを考える13:50-15:10 (80分)同値分割法と境界値分析15:20-17:10 (110分)クラシフィケーションツリー技法スポンサーライトニングワークスについて終わりにはじめにENECHANGEの工藤です。フルリモートで体が鈍ったので朝活で筋トレを始めたところ、胃の調子がだんだんと良くなってきています。QAと同じで胃も意識すれば品質を上げられると信じております。早速ですが2024年5月31日に仙台で開催されたJaSST'24 Tohokuに参加してきたので、それぞれのセッションの感想およびセッションで取り扱ったテスト技法のポイントについてこの記事で解説できればと思います。また、ENECHAGEではQAのポジションを募集してますので、ご興味おありの方はぜひご応募ください。www.wantedly.comJaSST TohokuについてJaSST（Japan Symposium on Software Testing）は日本各地で開催されている有名なソフトウェアテストシンポジウムです。X（Twitter）では、タグ「#jassttohoku」で、参加者などからの投稿をみれるようになっています。JaSST Tohoku 2024の開催場所は仙台の仙台復興記念館で、タイムテーブル等は以下のURLをご覧ください。jasst.jp参加目的QAエンジニアとして色々な案件に関わっているうちに品質をよりもっと挙げていきたいと強く感じようになってきており、品質をあげるためには何が必要かと自問自答した結果としてイベントに参加して見識を広めたいと思ったからです。また、自分が所属しているエネルギークラウド事業部では社内のQA同士での交流も非常に活発ですが、将来的にはより良い品質のプロダクトを生み出し続けるようになるためにはQA業務のあり方を視座の高い視点で考えて整備していく必要があるとも考えています。セッションについて10:30-12:00 (90分)説明できるテストをつくるためにできることを考える全体的に分かりやすくて、相手に伝わりやすいようにテストとは何かという点に主眼を置いて実際のやりとりの際に生じがちな認識の齟齬の解消を行うことで何をどうしたいのか、具体的に伝えたほうがいいのか、それとも抽象的に伝えた方がいいのか検討をすることは実際の案件でもかなり有効活用できそうだと思いました。また、テスト技法等を使うことでより分かりやすくしたり、説明をしないときでも説明できるような期待結果の書き方を日頃から意識することは大事だなとも感じました。　13:50-15:10 (80分)同値分割法と境界値分析数値の入力欄のフォームをベースに前後の席の方と4人1組になって同値分割法と境界値分析に焦点を当てて、ワークショップを実施しました。午前中に聞いたことを活かしながら、例題について自分の考えとチームの皆さんと議論をしながら認式合わせを行うことができたので、実案件の開発者と認式合わせを行う際にも積極的に使っていこうと思いました。　15:20-17:10 (110分)クラシフィケーションツリー技法普段はあまり聞き慣れないクラシフィケーションツリー技法について解説を聞きながら、実際に自分たちで大きめの方眼用紙に付箋を貼り付けて書き込みを実施しました。例題はとあるECサイトのランク別の配送料についてのものでしたが、エイヤのノリで作ったら途中で思ったのと違ったので作り直しましたが、作り直したことによってシンプルで分かりやすいツリーにすることが出来て良かったです。スポンサーライトニングワークスについて午後の初めとクロージングセッション手前にありましたが、どの会社様も品質を高めるためにQAエンジニアの育成をどうしたのか、ツールをどうやって使っているのか、もしくは内製化を目指すのかといったそれぞれの観点で解決策を提示されていて非常に勉強になりました。その中でも代表的なものを掲載させていただきます。www.docswell.com終わりに普段から勉強会にはそれとなく参加していましたが、オフライン開催のみの勉強会にでたのは初めてだったので移動も含めて非常に新鮮でした。（仙台のホテルがポケモンのイベントのために取れずに、朝4時起きの深夜12時帰宅だったのは内緒）今回学んだことを社内業務に活かして、現在取り組んでいる自動化についても内容を研磨していきチームにもいい影響を与えることができればいいなと思います。最後になりますが、ENECHANGEではQAエンジニアを募集していますのでぜひご応募ください。www.wantedly.com

JaSST'24 Tohokuに参加してきました！〜テスト技法編〜

ENECHANGEの園木です。本記事では、一部のセッションの内容やRuby会議の様子をお届けします。参加したセッションを一部紹介Let's use LLMs from Ruby 〜 Refine RBS types using LLM 〜近年急激に性能を向上しているLLMを活用し、Rubyの型推測をおこなうチャレンジについて発表してくださいました。スピーカーさんの記事RubyKaigi 2024 で RBS と LLM の話をしましたExploring Reline: Enhancing Command Line UsabilityRelineとGNU Readlineの違いを紹介したうえで、Relineにundo機能を追加したという内容を発表してくださいました。Getting along with YAML comments with Psychyamlファイル内に#を使ってコメントを記載するためにPsych-commentsというgemを作成したという内容を紹介してくださいました。どのような流れかというと、、目的の共有（こういうことを実現したい）成果物の提示（成果物はこちらです）前提（そもそもxxというのは、、、）アプローチ（だから、このようなアプローチをしました）実装中に発生した壁（すると、新たにこんな問題が発生しました）アプローチ_2（それをこのようにして乗り越えました）成果物のデモ（その結果できあがったのがこちらです）（今後の課題）締め課題と結論を最初に提示することで、コアな部分を理解できなくてもセッションの全体像を掴むことができます。登壇資料Getting along with YAML comments with Psych - Speaker DeckMatz Keynote今回のRubyKaigiでは、まつもとゆきひろ氏のキーノートは最後におこなわれました。MatzはRubyに対して、以下の理由でGoodと表現していました。「こういうメソッドがあったら良いのにな」が大体ある制限が少ないさまざまな企業で採用されている（参考）昔と比べて効率がよいコミュニティが活発そんなRubyをGreatにするためには、何よりもパフォーマンスの向上が必要であることを伝えていました。コミッターさんやスピーカーさんとも会話をすることができました単身で乗り込んだRubyKaigiを最大限に楽しむために、たくさんの方に声をかけさせて頂きました。コミッターとしてのモチベーションや、海外でのRuby事情、各企業の文化などを聞くことができました。特に印象的だったのは、Shopifyさんが壇上で話していた以下のことです。Shopifyは100年続く企業を目指しているShopifyはRubyで作られているつまり、Rubyの発展はShopifyの発展だ自分が気持ちよくRubyで開発できているのも、コミッターさんがRubyを改善してくださったり、スピーカーさんが新しい使い方を提示してくださるからなんだなぁとしみじみと感じました。毎日がお祭り騒ぎ会場にはRubyを採用している企業のブースが並んでいました。会期中は毎日がお祭りのようでした。また、会期中は毎晩Rubyを採用している企業がイベントを主催してくださっていました。次回開催閉会式では、次回開催情報も発表されました。日時: 2025年4月16日-18日場所: 愛媛県松山市来年も私は行きたい気持ちがありますので、本記事を読んだ方は現地でお話できたら嬉しいです！以上でRubyKaigi 2024のレポートを終わりにしたいと思います。ENECHANGEではRubyエンジニアを募集しています！弊社はエネルギーの未来をつくるというミッションを掲げています。www.wantedly.com

RubyKaigi 2024 に参加してきました！

概要最近、最新のアクションカメラを購入してYoutube用に動画編集してるCTO室のKazです今回、MySQLのマイグレーション時、Index有効クエリを高速化するため、ボトルネックを特定してそれを解消しました。結果Index有効化において適切なメモリ量を確保し、MySQL Workbenchのパフォーマンスレポートを確認することで、システムのボトルネックを特定しました。その結果、プロビジョニングIOPSを利用することにより、特に時間を要していたテーブルのインデックス有効化の時間を大幅に短縮し、システム全体の効率化を図ることができました。インデックス有効化の実行時間の比較 項目                            時間                          プロビジョニングIOPS利用前     約178.94分                   プロビジョニングIOPS利用後     約74.3分                     時間の短縮量                   約104.64分                   短縮率                         約58.5%                     Import先DB 項目                 詳細                                       インスタンスクラス    db.m7g.2xlarge                             vCPU                 8                                          RAM                  32GB                                       ストレージタイプ      汎用 SSD (gp2)                             ストレージ            198 GiB  （最大IOPSは9900）                      プロビジョンド IOPS  5000 (測定値の最大値近くを設定)            プロビジョンド IOPS：5000インスタンスクラス：db.m7g.2xlarge- 総合的に考えると、最低でも24 GB以上のメモリが必要でした。Info 監視ツールで80%のメモリ使用率が可視化されているとしても、それはバッファプールに割り当てられたメモリの量を反映しています。実際に必要なメモリ量は、バッファプール内のデータアクセスパターンによって異なるため、常に80%のメモリがアクティブに使用されているわけではありません。MySQLのメモリ使用状況を確認MySQLのメモリ使用状況を確認SHOW ENGINE INNODB STATUS;SHOW ENGINE INNODB STATUS コマンドの出力の一部----------------------BUFFER POOL AND MEMORY----------------------Total large memory allocated 2745958400Dictionary memory allocated 2122468Buffer pool size   163840Free buffers       8205Database pages     155340Old database pages 57179Modified db pages  0Pending reads      0Pending writes: LRU 0, flush list 0, single page 0Pages made young 3056426, not young 1848894540.00 youngs/s, 0.00 non-youngs/sPages read 12983565, created 620638, written 373918700.00 reads/s, 0.00 creates/s, 0.00 writes/sNo buffer pool page gets since the last printoutPages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/sLRU len: 155340, unzip_LRU len: 0I/O sum[96]:cur[0], unzip sum[0]:cur[0]Total large memory allocated: 2745958400 bytes (約2.56 GB)Dictionary memory allocated: 2122468 bytes (約2 MB)Buffer pool size: 163840 pages (1ページ = 16 KB, 約2.56 GB)Free buffers: 8205 pagesDatabase pages: 155340 pagesOld database pages: 57179 pagesModified db pages: 0Pending reads: 0Pending writes: LRU 0, flush list 0, single page 0SHOW ENGINE INNODB STATUSからメモリ使用量の計算バッファプール全体のメモリ量: Total large memory allocated約2.56 GBディクショナリメモリを引く: Dictionary memory allocated約2.12 MBバッファプールが使用しているメモリ量:約2.56 GB - 約2.12 MB = 約2.56 GB（innodb_buffer_pool_sizeは{DBInstanceClassMemory*3/4}と推奨の値になっているので一致）メモリ使用量の見積もりSELECT     table_schema AS 'Database',     ROUND(SUM(data_length) / 1024 / 1024, 2) AS 'Data Size (MB)',     ROUND(SUM(index_length) / 1024 / 1024, 2) AS 'Index Size (MB)',     ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS 'Total Size (MB)'FROM     information_schema.tables WHERE     table_schema = '<schema>' GROUP BY     table_schema; Database   Data Size (MB)  Index Size (MB)  Total Size (MB)    5746.02          13400.30         19146.31        データベースの現状データサイズ: 約5.75 GBインデックスサイズ: 約13.4 GB合計サイズ: 約19.15 GBInnoDBバッファプールのサイズ現在のバッファプールサイズ: 約2.56 GB（163,840ページ、1ページ16 KB）現在のメモリ使用状況バッファプールが使用されているメモリ量: 約2.37 GB必要なメモリ量の見積もり基本的には、データサイズとインデックスサイズの合計量に加え、ある程度のバッファやシステムのオーバーヘッドを考慮してメモリを割り当てることが推奨されます。以下に、計算手順を示します：データとインデックスの合計サイズ約19.15 GBバッファプールのサイズ一般的には、データとインデックスの合計サイズの80%～100%程度のバッファプールサイズを設定19.15 GBの80%は約15.32 GBシステムのオーバーヘッドMySQLサーバやOS自体が必要とするメモリも考慮する必要があるので通常、4 GB程度とする推奨メモリ量総合的に考えると、データベースサーバに最低でも24 GB以上のメモリが必要。最小メモリ量: 約24 GB（15.32 GBのバッファプール + 4 GBのオーバーヘッド + 追加の余裕）推奨メモリ量: 32 GB（19.15 GBのバッファプール + 4 GBのオーバーヘッド + 追加の余裕）Exportストアドプロシージャとストアドファンクションを除外せず、データベース全体の完全なバックアップを作成するデータベースマイグレーション時にストアドプロシージャやストアドファンクションを含めた完全なバックアップを作成することは、アプリケーションの機能維持、データ整合性の確保において重要です。index無効化export時はIndexサイズが大きいテーブルにおいてIndex無効化しておく。インデックスサイズが大きいものを無効化するというアプローチは合理的だが無効化によってデータの整合性が失われるリスクに注意する。index無効化対象テーブル Table  Table Size (MB)  Data Size (MB)  ndex Size (MB)  Table_A  16891.77  4311.00  12580.77  Table_B  998.81  424.94  573.88  Table_C  328.33  155.67  172.66  Table_D  136.25  118.67  17.58 テーブルが持つインデックスサイズを知る(top10)SELECT     table_schema AS `Database`,     table_name AS `Table`,     ROUND(SUM(index_length) / 1024 / 1024, 2) AS `Index Size (MB)`FROM     information_schema.tablesWHERE     table_schema NOT IN ('information_schema', 'mysql', 'performance_schema', 'sys')GROUP BY     table_schema, table_nameORDER BY     `Index Size (MB)` DESCLIMIT     10;テーブルが持つインデックスサイズを知るSELECT    TABLE_NAME,    INDEX_NAME,    SEQ_IN_INDEX,    COLUMN_NAMEFROM    INFORMATION_SCHEMA.STATISTICSWHERE    TABLE_SCHEMA = '<database_name>'    AND TABLE_NAME = 'Table_A'ORDER BY    INDEX_NAME, SEQ_IN_INDEX;Index無効化use <database_name>;ALTER TABLE Table_A DROP INDEX <index_name>;Export commandmysqldump --host=<hostname> --port=3306 --default-character-set=utf8 --user=<username> --password --protocol=tcp --routines <schema> > C:\Users\Administrator\Documents\dumps\<schema>_full_backup.sql--routinesストアドプロシージャとファンクションのエクスポートこのオプションを使用することで、MySQLデータベースからストアドプロシージャとストアドファンクションを含めたエクスポートが可能です。所要時間約120分ImportImport先DB指定したschemaがDBに存在しない場合はエラーになるのでschemaは事前に作っておくCREATE SCHEMA `<schema>` ;mysql --host=<hostname> --port=3306 --default-character-set=utf8 --user=<username> --password --protocol=tcp <schema> < C:\Users\Administrator\Documents\dumps\<schema>_full_backup.sql所要時間約60分Index有効化インデックス有効化とプロビジョニングIOPSの関係データベースのインデックスを有効化する際に、プロビジョニングIOPSを利用していなかった場合、クエリの実行に長時間が必要です。これは、インデックスの作成や更新には多くのディスクI/Oが必要となり、ディスクアクセスがボトルネックになるためです。具体的には、以下のような状況が発生しました。状況: インデックスの有効化を行うクエリの実行中、ディスクI/Oの負荷が高まり、IOPS（Input/Output Operations Per Second）の制限に達しました。(gp2のバースト性能の上限は、3,000 IOPS)結果、クエリの実行時間が長くなり、データベースの応答性が低下しました。ボトルネック解消の打ち手プロビジョニングIOPSを使用したEBSに変更することで、以下の利点が期待できます。高いI/Oキャパシティ: プロビジョニングIOPS EBSボリュームは、予測可能かつ高いI/Oパフォーマンスを提供します。これにより、データベースの書き込み操作が迅速に行われ、ボトルネックが解消される可能性が高くなります。低レイテンシ:プロビジョニングIOPSは低レイテンシを提供するため、データの読み書き速度が向上し、インポート時間が短縮されます。一般的な用途でOKなio1を選択するindex有効化実行無効化しているテーブルに対してIndexを有効化します。use <schema>;ALTER TABLE <table_name> ADD INDEX <index_name> (colum1, colum2, colum3, colum4);インデックス有効化の時間と効果プロビジョニングIOPSを利用することで、一番時間を要していたテーブルのインデックス有効化の時間が大幅に短縮され、効率化が図られました。 項目                  時間                実行時間             約63分              時間の短縮量         約47.4分            短縮率               約75.3%            05:35:56  ALTER TABLE <table_name> ADD INDEX <index_name> (column1, column2, column3, column4)    0 row(s) affected Records: 0  Duplicates: 0  Warnings: 0  933.094 sec 項目                                    プロビジョニングIOPS利用前  プロビジョニングIOPS利用後  インデックス有効化にかかる時間          約63分                      約15.6分                    時間の短縮量                           -                           約47.4分                    短縮率                                 -                           約75.3%                     実行前、後の効果                       -                           大幅に短縮され、効率化     補足これらのパラメータを設定することで、接続が長時間アイドル状態になるのを防ぎ、サーバのリソースを効果的に管理することができます。RDStimeoutしないようにしておく パラメータ           説明                                                                                                                  設定値       interactive_timeout  このパラメータは、MySQLサーバがインタラクティブクライアント（通常はMySQLコンソールなどの手動入力が行われるセッション）に対してどれくらいの時間アイドル状態を許可するかを指定します。このタイムアウト時間が経過すると、サーバは接続を閉じます。  3600秒  wait_timeout        このパラメータは、MySQLサーバが非インタラクティブクライアント（アプリケーションやスクリプトなどの自動接続）に対してどれくらいの時間アイドル状態を許可するかを指定します。このタイムアウト時間が経過すると、サーバは接続を閉じます。  28800秒 MySQL Workbenchtimeoutしないようにしておくボトルネック調査で推奨されるレポートHot Spots for I/O:Top File I/O Activity Report: どのファイルが最もI/Oを引き起こしているかを確認します。Top I/O by File by Time: 時間ごとのファイルI/Oを確認します。Top I/O by Event Category: イベントカテゴリ別のI/Oを確認します。Top I/O by Time by Event Categories: イベントカテゴリごとの時間別I/Oを確認します。Top I/O Time by User/Thread: ユーザーやスレッドごとのI/O時間を確認します。High Cost SQL Statements:Statements in Highest 5 Percent by Runtime: 実行時間が最も長い上位5%のSQLステートメントを確認します。With Sorting: ソートを伴うクエリを確認します。Full Table Scans: フルテーブルスキャンを行っているクエリを確認します。Database Schema Statistics:Schema Index Statistics: インデックスの統計情報を確認します。Schema Table Statistics: テーブルの統計情報を確認します。Tables with Full Table Scans: フルテーブルスキャンを行っているテーブルを確認します。Unused Indexes: 使用されていないインデックスを確認します。Wait Event Times (Expert):Global Waits by Time: 全体の待機時間を確認します。Waits by User by Time: ユーザーごとの待機時間を確認します。Wait Classes by Time: 待機クラスごとの待機時間を確認します。Wait Classes by Average Time: 平均待機時間ごとの待機クラスを確認します。InnoDB Statistics:InnoDB Buffer Stats by Schema: スキーマごとのInnoDBバッファの統計を確認します。InnoDB Buffer Stats by Table: テーブルごとのInnoDBバッファの統計を確認します。User Resource Use:Overview: ユーザーごとのリソース使用状況を確認します。I/O Statistics: I/O統計情報を確認します。Statement Statistics: ステートメントの統計情報を確認します。

MySQLパフォーマンス向上のためのプロビジョニングIOPSの活用とその結果

こんにちは、ENECHANGE株式会社でVPoTを務めている岩本 (iwamot) です。このブログの人気記事ランキングをSlackに自動投稿するよう実装したので、事例としてご紹介します。Google Analytics 4 (GA4) のレポートを見に行かなくても、どんな記事が読まれているのか手軽に確認できて便利です。実装方法はいろいろ考えられますが、今回選んだのは下記でした。Amazon AppFlowを使い、GA4データをAmazon S3に保存保存をトリガーにAWS Lambda関数を呼び出し、データを加工してSlackに投稿以下、AppFlowを中心に詳しくご説明します。SaaSとAWSのデータ連携が自動化できるAmazon AppFlowAppFlowは、SaaSとAWSサービス間のデータ連携を自動化できるサービスです。たとえば、Salesforce・SAP・Google Analyticsなどのデータを、Redshift・S3などに連携できます。左側のSaaSから、右側のAWSサービスへ、AppFlowでデータ連携できる（画像引用元：https://aws.amazon.com/jp/appflow/）ENECHANGEでは、ほとんどのワークロードをAWSで運用しているので、人気記事ランキングの自動投稿もAWSで運用したいところです。そこで、AppFlowを使って、GA4のデータをS3に保存することにしました。事前準備：AppFlowとGA4の接続を作成AppFlowでGA4のデータをS3に保存するには、まず接続を作成する必要があります。ぼくは、AWSのドキュメントや、クラスメソッドさんの記事を参考に進めました。docs.aws.amazon.comdev.classmethod.jpAppFlowのフローを作成続いて、AppFlowのフローを作成します。こちらは、AWSのソリューションアーキテクト・はまーんさんの記事を参考に進めました。track3jyo.com具体的な設定は下記の通りです。送信元の設定送信元として、GA4の接続やオブジェクトを選びます。送信先の設定送信先として、S3バケットを選びます。ファイル形式はCSVにしました。デフォルトのJSON Linesデータより、今回のLambda関数では処理しやすいためです。フロートリガーの設定フロートリガーは月曜10時としました。転送モードを増分転送にしたのは、週間ランキングを投稿したいからです。完全転送だと月間（30日）ランキングになります。フィールドマッピングの設定フィールドマッピングでは下記を指定しました。customEvent:post_date（投稿日。はてなブログ独自のカスタムディメンション）screenPageViews（ページビュー数）unifiedPagePathScreen（URLのパス。例：/entry/2022/10/25/100000）unifiedScreenName（記事名）これで下記のようなCSVが得られます。"unifiedScreenName","unifiedPagePathScreen","screenPageViews","customEvent:post_date""DockerfileでのENTRYPOINTとCMDの関係を整理する 〜 2つの記述形式に環境変数展開とシェル引数展開を添えて 〜 - ENECHANGE Developer Blog","/entry/2022/10/25/100000","40","2022-10-25"パーティションと集約の設定パーティションの設定は「毎日」としました。S3のフォルダパスを見るだけで、何年何月何日に作られたデータか分かるからです。集約の設定は、1ファイルとしました。複数ファイルだと、Lambdaで処理しづらくなります。フィルターの設定フィルターは下記の2件を設定しました。unifiedPagePathScreen が次を含む /entry/（記事ページのみに絞りたい）unifiedScreenName が次を含む - ENECHANGE Developer Blog（翻訳されたアクセスは無視したい）Lambda関数を作成あとは、S3保存をトリガーとするLambda関数を作るだけです。データ加工と、Slack投稿を担当します。はまーんさんの記事ではデータ加工にAWS Glue DataBrewを使っていますが、今回のようにLambda関数でSlackに投稿するのであれば、加工も同じ関数に任せるのがシンプルだと判断しました。ChatGPTに相談しながら最終的にできたのが下記のコードです。import csvimport ioimport jsonimport osimport urllib.parseimport urllib.requestimport boto3base_url = "https://tech.enechange.co.jp"slack_webhook_url = os.environ["SLACK_WEBHOOK_URL"]s3 = boto3.client("s3")def lambda_handler(event, context):    # S3のCSVデータを取得する    bucket = event["Records"][0]["s3"]["bucket"]["name"]    key = urllib.parse.unquote_plus(        event["Records"][0]["s3"]["object"]["key"], encoding="utf-8"    )    response = s3.get_object(Bucket=bucket, Key=key)    body = response["Body"].read().decode("utf-8")    csv_string = io.StringIO(body)    reader = csv.reader(csv_string)    # ヘッダを読み飛ばす    _ = next(reader)    # ページビュー数の降順でソートする    data_rows = [row for row in reader]    sorted_data = sorted(data_rows, key=lambda x: int(x[2]), reverse=True)    # 上位10件のデータで投稿メッセージを組み立てる    message_lines = []    for i, row in enumerate(sorted_data[:10]):        # 記事名からブログ名を削除する        title = row[0].replace(" - ENECHANGE Developer Blog", "")        # URLを「https://」からに整える        url = f"{base_url}{row[1]}"        # メッセージに行を追加する        page_views = row[2]        post_date = row[3]        line = f"*{post_date}* <{url}|{title}> {page_views} views"        message_lines.append(line)    # メッセージを整えてSlackに投稿する    header = "ENECHANGE Developer Blogの先週の人気記事です :medetai-nya:"    message = header + "\n\n" + "\n".join(message_lines)    data = json.dumps({"text": message}).encode("utf-8")    req = urllib.request.Request(        slack_webhook_url, data, headers={"Content-Type": "application/json"}    )    urllib.request.urlopen(req)    return {        "statusCode": 200,        "body": "OK",    }これで毎週月曜10時に、人気記事ランキングが投稿されるようになりました。おわりにAppFlowでGA4のデータをS3に保存し、Lambdaで加工してSlackに投稿する例をご紹介しました。今回は人気記事ランキングでしたが、各種コンバージョンの分析結果も簡単に投稿できるはずです。GA4に限らず、SaaSのデータをAWSで処理したいときには、AppFlowの活用をお勧めします。接続できるSaaSは、AWSのドキュメントでご確認ください。docs.aws.amazon.com

Amazon AppFlowをGA4に接続し、人気記事ランキングをSlackに自動投稿する

Wi−Fiネットワーク調査報告カスタマーサービスセンターの新拠点におけるネットワークを調査し、スケジュール遅滞なく業務を開始できることを目的としました。新拠点では既存の通信速度と安定性を担保する必要があり、特にインターネット接続とAWSに構築しているVerified Accessの品質を確認しました。これにより、現行のネットワーク基準を満たし、業務のスムーズな移行と運用が可能であることを確認しました。運用しているVerified Accessについて説明従来のVPN接続で発生する待機時間や、VPNクライアントのアップデート、設定変更といった追加の手間が不要になります。これにより、ユーザーはよりスムーズにセキュアな接続を確立できるため、AWS Verified Accessを採用しています。これにより、運用の効率化とセキュリティの向上が実現できます。Verified Access Instance:Verified Accessの管理とポリシー設定の中心。全体的なアクセス制御とポリシーを管理します。Verified Access Trust Providers:ユーザーの認証と信頼性の確認を担当。外部IDプロバイダーや他の信頼ソースと連携。Azure Entra ID:Verified Access Trust Providersの一部として機能。ユーザー認証およびアクセス管理に使用され、MicrosoftのID管理ソリューションと統合。Verified Access Groups:同じアクセス要件を持つユーザーやデバイスをグループ化。アクセス管理の単位として機能。Route 53 (DNS):DNSサービスを提供し、Verified Accessエンドポイントの名前解決をサポート。Verified Accessエンドポイントへのアクセスを簡素化し、冗長性と可用性を向上。Verified Access Endpoints:ユーザーがアクセスするための具体的なエントリーポイント。アクセスされるリソースやサービスを指定。Users:Verified Access Endpointsに接続するユーザー。Azure Entra IDを使用して認証され、アクセスが許可されます。                     +----------------------------------------------------+                     |                  Verified Access                   |                     |                      Instance                      |                     +----------------------------------------------------+                                     /|\              /|\                                      |                |                                      |                |                    +-----------------+                +-----------------+                    |                                                      |     +--------------+-----------------+            +-----------------------+----------------+     | Verified Access trust providers |            |     Verified Access groups             |     +--------------+-----------------+            +-----------------------+----------------+                    |                                                      |                    |                                                      |                    |                                                      | +------------------+-----------+                           +--------------+-----------------+ |  Azure Entra ID (Azure AD)   |                           |      Route 53 (DNS)           | +------------------------------+                           +--------------+-----------------+                    |                                                      |                    +-----------------+                +-------------------+                                      |                |                                      |                |                                     \|/              \|/                     +----------------------------------------------------+                     |                    Verified Access                  |                     |                       endpoints                     |                     +----------------------------------------------------+                                     /|\                                      |                                      |                                     \|/                              +----------------+                              |      Users      |                              +----------------+評価要素スピード接続安定性ネットワークキャパシティテスト方法ツール: speedtest-cli、iperf、pingを使用してインターネット速度とネットワーク品質を測定。プロセス:speedtest-cliを実行してダウンロード速度、アップロード速度、レイテンシを測定。                    +------------------------+                    |       ローカルネットワーク   |                    |        クライアント        |                    +------------------------+                               |                               | インターネット経由                               |                    +------------------------+                    |      インターネット         |                    |    speedtestサーバ      |                    +------------------------+iperfを使用してアップロード速度を測定し、特にAWS内のVerified Accessの品質を確認。                    +------------------------+                    |       ローカルネットワーク   |                    |        クライアント        |                    +------------------------+                               |                               | インターネット経由                               |                    +------------------------+                    |          AWS           |                    |       iperfサーバ       |                    +------------------------+pingを使用してGoogle DNSサーバー（8.8.8.8）への接続性とレイテンシを測定。                    +------------------------+                    |       ローカルネットワーク   |                    |        クライアント        |                    +------------------------+                               |                               | インターネット経由                               |                    +------------------------+                    |      インターネット         |                    |    Google DNSサーバ      |                    +------------------------+テスト場所Wi-Fi機器を部屋の中心に地上高1.5mに配置し、一番近い場所と遠い場所で計測しました。使用した周波数は2.4GHzで部屋の内部にはパーティションなどの障害物はありません。結果場所によってネットワーク速度に大きな差が見られるため、WiFi機器を増やすなどの対策を検討し、ネットワークのカバレッジと安定性を向上させる必要がありました。近い場所での計測結果ダウンロード速度測定値: 163.50 Mbit/s評価: 非常に高速。大容量のファイルのダウンロードや高解像度のストリーミングに適しており、一般的なインターネットアクティビティに対して優れた性能を提供します。アップロード速度測定値: speedtest-cliでは375.96 Mbit/s、iperfでは275 Mbit/s評価: 非常に高速。クラウドストレージへの大容量ファイルのアップロード、ビデオ会議、ライブストリーミングなどに対して優れた性能を提供します。レイテンシspeedtest-cli: 10.876 msping: 平均8.523 ms（最小5.047 ms、最大15.605 ms、標準偏差2.335 ms）評価: 低レイテンシ。オンラインゲームやビデオ会議などのリアルタイムアプリケーションにおいて、非常に快適な使用感が期待できます。パケットロス測定値: 0.0%評価: 非常に安定した接続。データの損失がないため、信頼性の高いネットワーク接続が提供されています。遠い場所での計測結果ダウンロード速度測定値: 12.27 Mbit/s評価: 一般的なWebブラウジングや標準画質の動画ストリーミングには十分ですが、大容量のファイルダウンロードや高画質ストリーミングにはやや遅いと感じるかもしれません。アップロード速度測定値: speedtest-cliでは88.60 Mbit/s、iperfでは140 Mbit/s評価: 比較的高速なアップロード速度。クラウドストレージへのファイルのアップロードやビデオ会議には十分な性能を提供します。レイテンシspeedtest-cli: 66.487 msping: 平均43.817 ms（最小9.416 ms、最大783.431 ms、標準偏差113.130 ms）評価: ピン値の平均と最大値が高く、標準偏差も大きいため、リアルタイムアプリケーション（オンラインゲームやビデオ会議）では不安定さを感じる可能性があります。パケットロス測定値: 0.0%評価: パケットロスがないため、データの損失がないことを示しており、安定した接続が提供されています。反省点複数回のテストを行い、それぞれの計測値で最も高い値と最も低い値を除外したトリム平均（トリムメディアン）を使用して、より信頼性の高い速度評価を行うべきでした。

カスタマーサービスセンターの新拠点のネットワーク調査

こんにちは、2023年7月からコツコツ集めて現在72WLD所有しているCTO室のkazです。OpenAI Whisperを試してみたOpenAIが開発した音声認識モデルWhisperを使用して、実際の音声データをテキストに変換してみました。その結果、非常に高い精度で音声を文字起こしできることが確認できました。具体的には、Google ColaboratoryでGoogleドライブをマウントし、マウントしたディレクトリにある音声データをWhisperを使用してテキストデータに変換します。生成されたテキストデータをChatGPTで要約し、議事録を作成します。OpenAI Whisper についてOpenAI Whisperは、OpenAIによって開発された音声認識モデルです。以下にWhisperの概要と特徴について簡単に説明します。OpenAI Whisper概要Whisper は、音声データをテキストに変換するための高度な音声認識モデルです。様々な言語やドメインの音声データを処理する能力があります。高い精度で音声から文字起こしを行い、多様なアクセントや方言にも対応できます。特徴高精度な認識:Whisperは、大量の音声データで訓練されており、高い認識精度を誇ります。ノイズやバックグラウンド音がある環境でも良好なパフォーマンスを発揮します。多言語対応:Whisperは、英語だけでなく、多くの言語をサポートしています。多言語間の音声認識が可能で、国際的なアプリケーションにも適しています。アクセントと方言の認識:様々なアクセントや方言に対応しており、異なる地域の音声データも正確に認識します。リアルタイム処理:Whisperはリアルタイムでの音声認識をサポートしており、ライブイベントやストリーミングアプリケーションでの利用が可能です。使いやすさ:OpenAIが提供するAPIを通じて、簡単にWhisperを統合することができます。開発者は、音声データをAPIに送信するだけで、テキストに変換された結果を受け取ることができます。使用例字幕生成:映画や動画の自動字幕生成に利用できます。音声コマンド:スマートデバイスやアプリケーションに音声コマンド機能を追加できます。音声検索:音声による検索クエリの処理に利用できます。カスタマーサービス:カスタマーサポートの音声応答システムに統合し、顧客の問い合わせを自動処理できます。Google Colaboratory についてGoogle Colaboratory（略してGoogle Colab）は、Googleが提供する無料のクラウドベースのJupyterノートブック環境です。データサイエンス、機械学習、ディープラーニングのプロジェクトに特化しており、Pythonコードの記述と実行を簡単に行うことができます。Google Colaboratory概要クラウドベース: インストール不要で、ブラウザ上で直接使用可能。無料のGPUサポート: 高性能なハードウェア（GPU、TPU）を無料で利用可能。Python環境: データサイエンスや機械学習に最適化されたPython環境を提供。共有とコラボレーション: ノートブックを他のユーザーと簡単に共有し、共同編集が可能。特徴インストール不要:ブラウザ上で動作するため、ソフトウェアのインストールや設定が不要です。高性能なハードウェア:無料でGPUやTPUを使用でき、大規模なデータ処理や機械学習モデルのトレーニングが可能です。Pythonと統合:データサイエンスや機械学習で広く使用されているPythonライブラリ（NumPy、Pandas、TensorFlow、PyTorchなど）をサポートしています。シームレスな共有:Googleドライブと統合されており、ノートブックを他のユーザーと簡単に共有できます。共同編集も可能です。セルベースのコード実行:Jupyterノートブック形式を採用しており、セルごとにコードを実行し、結果をすぐに確認できます。使用例データサイエンス:データの前処理、可視化、解析を簡単に行えます。機械学習:モデルの構築、トレーニング、評価を行うための理想的な環境です。教育:プログラミングやデータサイエンスの教育ツールとして利用できます。ChatGPT についてChatGPTは、OpenAIによって開発された高度な対話型AIモデルです。GPT（Generative Pre-trained Transformer）アーキテクチャに基づいており、人間のような自然な対話を行うことができます。ChatGPT概要開発元: OpenAIアーキテクチャ: GPT（Generative Pre-trained Transformer）目的: 自然言語処理と生成に特化し、様々な対話型アプリケーションに利用されます。特徴自然な対話:人間のように自然な文章を生成し、流暢な対話が可能です。多用途:カスタマーサポート、教育、エンターテインメントなど、様々な分野で利用されています。高度な理解能力:文脈を理解し、適切な応答を生成する能力があります。継続的な学習:大量のテキストデータを基に訓練されており、定期的にアップデートされることで、最新の知識を反映しています。使用例カスタマーサポート:顧客からの問い合わせに自動で応答し、問題解決を支援します。パーソナルアシスタント:スケジュール管理、リマインダー設定、情報提供など、日常生活をサポートします。教育:学習支援ツールとして、学生の質問に答えたり、学習資料を提供します。エンターテインメント:対話型ゲームやストーリーテリングに利用され、ユーザーにインタラクティブな体験を提供します。手順WhisperOpenAIでAPIキーを作成します。Google Colaboratoryノートブックを新規作成します。「ハードウェアアクセラレータ」をGPUに変更する「ハードウェアアクセラレータ」をGPUに変更する主な理由Google Colaboratoryで「ハードウェアアクセラレータ」をGPUに変更する主な理由は、計算速度の向上、モデルのトレーニング時間の短縮、高精度なモデルの効率的な訓練です。これにより、特にディープラーニングや大規模なデータセットを扱うタスクにおいて、開発効率が大幅に向上します。OpenAIのAPIキーを登録するためにコードを実行します。ColabAIを使用すればプログラムの知識が無くてもなんとかなりますね。Googleドライブをマウントしますとりあえず、音声データを指定してテキストデータに変換します。OpenAIのWhisperモデルの各バリエーション（tiny、base、small、medium、large）が用意されています。これらのモデルは、音声認識性能と計算リソースのトレードオフが異なります。Whisperモデルのバリエーションと特徴Whisperモデルのバリエーションと特徴モデルの種類Whisperモデルは、以下のように複数のサイズがあり、それぞれ性能と計算リソースのバランスが異なります。1. Tinyパラメータ数: 約39Mモデルサイズ: 約72MB推論速度: 非常に高速特徴: 最小サイズのモデルであり、計算資源の少ない環境やリアルタイム処理が求められるアプリケーションに適しています。音声認識の精度は他の大きなモデルに比べてやや低いですが、十分な性能を発揮します。2. Baseパラメータ数: 約74Mモデルサイズ: 約140MB推論速度: 高速特徴: Tinyモデルよりも精度が高く、依然として高速な推論を提供します。計算資源が限られているが、精度がより求められる場合に適しています。3. Smallパラメータ数: 約244Mモデルサイズ: 約466MB推論速度: 中速特徴: ベースモデルよりもさらに高い精度を提供し、一般的な用途での音声認識に非常に適しています。計算資源と精度のバランスが良いモデルです。4. Mediumパラメータ数: 約769Mモデルサイズ: 約1.5GB推論速度: 低速特徴: 小規模なモデルよりも高い精度を持ち、大規模なデータセットや高精度が求められるタスクに適しています。計算資源が豊富にある環境で使用するのが理想的です。5. Largeパラメータ数: 約1550Mモデルサイズ: 約3GB推論速度: 非常に低速特徴: 最高の精度を提供し、大規模なデータセットや最高の認識精度が求められるプロジェクトに適しています。計算リソースを大量に消費するため、性能重視の環境での使用が推奨されます。選択のポイント計算資源: リアルタイム処理や低リソース環境では、TinyやBaseモデルが適しています。認識精度: 高い精度が求められる場合は、Small、Medium、Largeモデルを選択します。推論速度: 推論速度が重要な場合は、TinyまたはBaseモデルを選択します。この程度のデータなら誤字はありませんね。3時のNHKニュースです。消防によりますと、きょう昼過ぎ、熊本県阿蘇市黒川の山中に、遊覧ヘリコプターが不自着したということです。処理が終わったらGoogleドライブをアンマウントしますテキストデータにした会議内容をChatGPTに要約させる（実際の録音データだともっとノイズが入りますが適切なモデルを使用すれば精度は高いです）今日は明日の天気予報の公表方法について議論したいと思います。まず、佐藤さんから明日の天気予報の概要を教えてください。はい、明日の天気は全国的に晴れですが、一部地域で午後から雨が降る予報が出ています。特に北部では雷を伴う激しい雨になる可能性があります。気温は平均して25度前後です。ありがとうございます。では、鈴木さん、今回の天気予報をどうやって公表する予定ですか？そうですね、まずは公式ウェブサイトに詳細な予報を掲載し、その後、SNSやメルマガを通じて速報を流す予定です。特に激しい雨の地域については、注意喚起を強調したいと思います。なるほど。では、山田さん、SNSでの公表についてご意見をお願いします。はい、SNSではインフォグラフィックを使って視覚的にわかりやすい形で情報を発信しようと考えています。また、リアルタイムで更新されるストーリーズも活用して、最新の情報をタイムリーに届ける予定です。それはいいですね。小林さん、インフォグラフィックのデザインについて何か提案はありますか？はい、地域ごとの天気を色分けして一目でわかるようにし、特に注意が必要な地域は赤や黄色などの強調色を使って視覚的に警告する形にしたいと思います。また、スマホでの閲覧を考慮して、縦長のデザインも準備しています。素晴らしいですね。それでは、最後に公表のタイミングについて確認しましょう。鈴木さん、ウェブサイトとSNSでの情報発信はどの時間に行う予定ですか？ウェブサイトには午前7時に詳細な予報を掲載し、SNSではその後すぐに速報を流します。また、午後1時と夕方6時に追加の更新情報を発信する予定です。承知しました。それでは、このスケジュールで進めるということで、皆さん問題ないでしょうか？はい、問題ありません。では、今日の会議はここまでとします。皆さん、準備をよろしくお願いします。お疲れ様でした。明日の天気予報公表方法に関する会議 議事録明日の天気予報公表方法に関する会議 議事録日時: 2024年5月15日時間: 10:00 AM - 11:00 AM場所: 第2会議室出席者司会者: 田中さん気象予報士: 佐藤さん広報担当: 鈴木さんSNS担当: 山田さんデザイン担当: 小林さん議題明日の天気予報の概要公表方法の検討SNSでの公表方法インフォグラフィックのデザイン公表のタイミング確認議事内容1. 明日の天気予報の概要佐藤さん（気象予報士）:- 明日の天気は全国的に晴れ。- 一部地域で午後から雨が降る予報が出ている。- 特に北部では雷を伴う激しい雨になる可能性がある。- 気温は平均して25度前後。2. 公表方法の検討鈴木さん（広報担当）:- 公式ウェブサイトに詳細な予報を掲載。- SNSやメルマガで速報を流す予定。- 特に激しい雨の地域については注意喚起を強調。3. SNSでの公表方法山田さん（SNS担当）:- インフォグラフィックを使って視覚的にわかりやすい情報を発信。- リアルタイムで更新されるストーリーズの活用。4. インフォグラフィックのデザイン小林さん（デザイン担当）:- 地域ごとの天気を色分けし、特に注意が必要な地域は赤や黄色などの強調色で視覚的に警告。- スマホでの閲覧を考慮して、縦長のデザインも準備。5. 公表のタイミング確認鈴木さん（広報担当）:- ウェブサイトには午前7時に詳細な予報を掲載。- SNSではその後すぐに速報を流す。- 午後1時と夕方6時に追加の更新情報を発信。決定事項ウェブサイトとSNSでの情報発信スケジュールを以下の通りに実施:ウェブサイト: 午前7時SNS: ウェブサイト更新後すぐ追加更新: 午後1時、夕方6時アクションアイテム佐藤さん: 明日の天気予報の詳細を準備。鈴木さん: ウェブサイトおよびSNSでの情報発信の準備。山田さん: SNS用のインフォグラフィックおよびストーリーズの準備。小林さん: インフォグラフィックのデザイン作成。次回会議日時: 2024年5月16日 午前10時議題: 公表後の反響の確認および改善点の検討結論文字起こしサービスは多くの競合がありますが、会議などの機密事項を含む内容を外部のサービスに任せるのは難しいです。しかし、Googleドライブをマウントして利用すれば、情報漏洩のリスクを低く抑えた状態で音声データをテキストデータに変換できるため、おすすめです。

音声認識モデルの精度を検証

ENECHANGE VPoTの岩本 (iwamot) です。2024年4月～6月の四半期から、社内I/O Dayを試験的に始めています。「プロダクト開発や事業課題の解決に活用できそうな技術について、集中的にインプット／アウトプットする日を宣言する制度」のことです（くわしくは別の機会にお伝えします）。多くのエンジニアが本日5月15日にI/O Dayを宣言していたので、ぼくも乗っかってみました。お祭り感があって、いいですね。ぼくが取り組んだテーマは、Slackのfiles.upload API廃止対応でした。2025年3月までに、新しいAPIに移行する必要があるんですよね。まだ時間はあるものの、ボリューム的にちょうどよさそうなので選びました。今回の記事では、Google Apps Scriptからの呼び出し方をどう変えたのかご紹介します。これから廃止対応を進める方の参考になれば幸いです。変更前のコードまず、変更前のコードをご紹介します*1。とあるクラスの uploadFile メソッドです。files.upload APIをシンプルに呼んでいます。  /**   * ファイルをアップロードする   *   * @param {Blob} fileBlob - ファイル   * @param {String} filename - ファイル名   * @return {String} アップロードしたファイルURL   */  uploadFile(fileBlob, filename) {    const options = {      payload: {        token: this.oauthToken,        file: fileBlob,        filename: filename,      },    };    const response = UrlFetchApp.fetch(      "https://slack.com/api/files.upload",      options    );    const responseBody = response.getContentText();    const data = JSON.parse(responseBody);    if (!data.ok) {      throw new Error(data);    }    return data.file.permalink;  }新しいアップロード手順新しいAPIでのファイルアップロード手順は、下記のとおりです。files.getUploadURLExternal API を呼び出してファイルアップロードに使用する https://files.slack.com/upload/v1/... URL とファイル ID を取得するhttps://files.slack.com/upload/v1/... URL に POST リクエストを送信してファイルをアップロードするfiles.completeUploadExternal API にファイル ID に加えて チャンネル ID などを送信して、アップロード処理を完了させるqiita.com変更後のコード変更後のコードは下記のようになりました。新しいアップロード手順を素直に実装した形です。クラスにメソッドを3つ追加しています。  /**   * ファイルをアップロードする   *   * @param {Blob} fileBlob - ファイル   * @param {String} filename - ファイル名   * @return {String} アップロードしたファイルURL   */  uploadFile(fileBlob, filename) {    const [fileUploadUrl, fileId] = this.getFileUploadUrl(      filename,      fileBlob.getBytes().length    );    const options = {      method: "post",      payload: fileBlob,    };    const response = UrlFetchApp.fetch(fileUploadUrl, options);    Logger.log(response);    this.completeFileUpload(fileId);    return this.getFilePermalink(fileId);  }  /**   * ファイルアップロード用URLを取得する   *   * @param {String} filename - ファイル名   * @param {Number} length - ファイルサイズ   * @return {String[]} ファイルアップロード用URL、ファイルID   */  getFileUploadUrl(filename, length) {    const options = {      method: "get",      headers: {        Authorization: "Bearer " + this.oauthToken,      },      payload: {        filename: filename,        length: length.toString(),      },    };    const response = UrlFetchApp.fetch(      "https://slack.com/api/files.getUploadURLExternal",      options    );    Logger.log(response);    const responseBody = response.getContentText();    const data = JSON.parse(responseBody);    if (!data.ok) {      throw new Error(data);    }    return [data.upload_url, data.file_id];  }  /**   * ファイルアップロード処理を完了する   *   * @param {String} fileId - ファイルID   */  completeFileUpload(fileId) {    const options = {      method: "post",      headers: {        Authorization: "Bearer " + this.oauthToken,      },      contentType: "application/json",      payload: JSON.stringify({        files: [{ id: fileId }],      }),    };    const response = UrlFetchApp.fetch(      "https://slack.com/api/files.completeUploadExternal",      options    );    Logger.log(response);    const responseBody = response.getContentText();    const data = JSON.parse(responseBody);    if (!data.ok) {      throw new Error(data);    }  }  /**   * ファイルのURLを取得する   *   * @param {String} fileId - ファイルID   * @return {String} ファイルのURL   */  getFilePermalink(fileId) {    const options = {      method: "get",      headers: {        Authorization: "Bearer " + this.oauthToken,      },      payload: {        file: fileId,      },    };    const response = UrlFetchApp.fetch(      "https://slack.com/api/files.info",      options    );    Logger.log(response);    const responseBody = response.getContentText();    const data = JSON.parse(responseBody);    if (!data.ok) {      throw new Error(data);    }    return data.file.permalink;  }いくつか補足します。整数化はtoStringで  getFileUploadUrl(filename, length) {    const options = {      method: "get",      headers: {        Authorization: "Bearer " + this.oauthToken,      },      payload: {        filename: filename,        length: length.toString(),lengthを文字列に変換しているのは、数値型のままだと 12345.0 のような値がPOSTされ、エラーになるためです。配列を含むペイロードはJSON.stringifyで  completeFileUpload(fileId) {    const options = {      method: "post",      headers: {        Authorization: "Bearer " + this.oauthToken,      },      contentType: "application/json",      payload: JSON.stringify({        files: [{ id: fileId }],      }),    };JSON.stringifyしているのは、files.completeUploadExternal APIのペイロードで配列を指定するのに必要なためです。contentTypeにも要注意。くわしくは下記の記事をご参照ください。qiita.comまた、トークンをヘッダに移動したのは、JSONペイロード内で渡しても無視されてしまうためです。トークンはヘッダに含めるようドキュメントでも推奨されています。We prefer tokens to be sent in the Authorization HTTP header of your outbound requests.api.slack.comfiles.info APIを呼ぶならfiles.readの許可を  getFilePermalink(fileId) {    const options = {      method: "get",      headers: {        Authorization: "Bearer " + this.oauthToken,      },      payload: {        file: fileId,      },    };    const response = UrlFetchApp.fetch(      "https://slack.com/api/files.info",      options    );多くのユースケースでは、アップロードしたファイルのURLが必要になることでしょう。今回のコードもそうでした。ファイルのURLを取得するには、files.info APIが使えます（他の方法もあるかもしれませんが、調べていません）。ただし、files.info APIを呼び出すには files.read スコープが必要です。files.write だけではエラーになります。おわりに以上、Slackのfiles.upload API廃止に備えて、Google Apps Scriptのコードに手を入れた例をご紹介しました。Slack APIもGoogle Apps Scriptも不慣れでしたが、社内I/O Dayを活用することで、コードリーディングからブログ投稿まで1日で終えられました。次の四半期でも、また何か取り組めたらと思っています。追記 (2024-05-16)HTTPメソッドを明示的に指定するようコードを変更しました。記事公開時には method: "post"  などの指定をしていませんでした。瀬良さん、フィードバックありがとうございました！ありがとうございます！一応どの HTTP メソッドでも動くんですが POST の方が安全かと思うので options に method: "post", を追加しておいた方がよいと思います。あと、この記事からリンクさせていただきました！ https://t.co/1QizWfF65i #SlakDevJP— Kazuhiro Sera (瀬良) (@seratch_ja) 2024年5月15日   *1:記事内のコードはすべてMITライセンスです

ENECHANGE Developer Blog

テックベンチャー3社のインターン生が語る！学生エンジニアの本音とは【イベントレポート】

日本にはAWS Community Builderが足りていない

初実施の「I/O DayオンラインLT大会」、その内容を大公開！

ブルー/グリーンなAmazon ECSサービスのネットワーク設定を変える方法

React 19 RC で、アンケート画面を作ってみた

IPAとAWSのダブル全冠、鍵は体力とお金

CloudTrailとCloudWatchLogsの統合

「今さら聞けない！オフィス・開発でのAI活用」イベントレポート

IPアドレス制限ありのURLをRoute 53ヘルスチェックで死活監視する

Amazon S3 が条件付き書き込みのサポートを開始

ALB脆弱性の影響と対策

JAWS PANKRATION 2024に登壇して得られたもの

「Lambdaレス」な実装例：AWS WAFのIPセット自動更新

スナップショットテストをやめて、ビジュアルリグレッションテストに移行した話

Terraformモジュール構成のベストプラクティス

ENECHANGEの新たな取り組みI/O Dayとは？技術革新の現場をインタビュー！

最近遭遇した useEffect のアンチパターンを紹介【React】

インターン生として半年間ENECHANGEで働いてみて

事業譲渡を受けたアプリとの統合で失敗、そしてユーザーからの評価回復に至るまで

AIレビューツールであるCodeRabbitを試してみました【設定ファイルあり】

メリットだらけなので、AWSパートナーになりました

Rails + Hotwire を試してみて、使いどころを考えてみた

100以上のLLMが使えるSlackbot OSS、Collmboを公開しました

JaSST'24 Tohokuに参加してきました！〜テスト技法編〜

RubyKaigi 2024 に参加してきました！

MySQLパフォーマンス向上のためのプロビジョニングIOPSの活用とその結果

Amazon AppFlowをGA4に接続し、人気記事ランキングをSlackに自動投稿する

カスタマーサービスセンターの新拠点のネットワーク調査

音声認識モデルの精度を検証

Slackのfiles.upload API廃止に備え、Google Apps Scriptのコードに手を入れる

テックベンチャー3社のインターン生が語る！学生エンジニアの本音とは【イベントレポート】

日本にはAWS Community Builderが足りていない

初実施の「I/O DayオンラインLT大会」、その内容を大公開！

ブルー/グリーンなAmazon ECSサービスのネットワーク設定を変える方法

React 19 RC で、アンケート画面を作ってみた

IPAとAWSのダブル全冠、鍵は体力とお金

CloudTrailとCloudWatchLogsの統合

「今さら聞けない！オフィス・開発でのAI活用」イベントレポート

IPアドレス制限ありのURLをRoute 53ヘルスチェックで死活監視する

Amazon S3 が条件付き書き込みのサポートを開始

ALB脆弱性の影響と対策

JAWS PANKRATION 2024に登壇して得られたもの

「Lambdaレス」な実装例：AWS WAFのIPセット自動更新

スナップショットテストをやめて、ビジュアルリグレッションテストに移行した話

Terraformモジュール構成のベストプラクティス

ENECHANGEの新たな取り組みI/O Dayとは？ 技術革新の現場をインタビュー！

最近遭遇した useEffect のアンチパターンを紹介 【React】

インターン生として半年間ENECHANGEで働いてみて

事業譲渡を受けたアプリとの統合で失敗、 そしてユーザーからの評価回復に至るまで

AIレビューツールであるCodeRabbitを試してみました【設定ファイルあり】

メリットだらけなので、AWSパートナーになりました

Rails + Hotwire を試してみて、使いどころを考えてみた

100以上のLLMが使えるSlackbot OSS、Collmboを公開しました

JaSST'24 Tohokuに参加してきました！〜テスト技法編〜

RubyKaigi 2024 に参加してきました！

MySQLパフォーマンス向上のためのプロビジョニングIOPSの活用とその結果

Amazon AppFlowをGA4に接続し、人気記事ランキングをSlackに自動投稿する

カスタマーサービスセンターの新拠点のネットワーク調査

音声認識モデルの精度を検証

Slackのfiles.upload API廃止に備え、Google Apps Scriptのコードに手を入れる

ENECHANGEの新たな取り組みI/O Dayとは？技術革新の現場をインタビュー！

最近遭遇した useEffect のアンチパターンを紹介【React】

事業譲渡を受けたアプリとの統合で失敗、そしてユーザーからの評価回復に至るまで