Hello, I'm Xu Huang from the KINTO ID Platform team. For the past few years now, we have been providing user authentication and authorization systems (known internally as UserPool) across multiple countries. To support this, we adopted a broker model that connects Userpools across multiple regions, building and operating an architecture that allows them to share authentication and authorization information with each other. Last year, as part of our cost optimization efforts, we redesigned and migrated this architecture. In this post, I’ll walk you through what changed and why. In our initial deployment, we used AWS Aurora Global Database (referred to as Global DB) as part of our global deployment strategy. To minimize access load and latency, we deployed Slave DBs in close proximity to each UserPool and placed Broker servers in the same regions as the corresponding Slave DBs. (Due to Global DB limitations, only one Master DB is allowed, and it supports up to five Slave DBs.) As shown in the diagram above, we gradually rolled out the UserPool service to the regions outlined in blue. To enable centralized user management, we designed the system so that unique IDs would be issued from a central aggregation point and synchronized this information to each region’s sub-DB for local management. Phase 1: Migrating from Global DB to a Normal DB and Removing Write-Only Applications The original architecture prioritized minimizing access load by deploying servers across multiple regions. However, in reality, the system had not yet reached a scale that required such complexity, leading to unnecessary operational costs. To optimize the setup, we conducted a thorough evaluation and concluded that a Global DB setup was not essential for our current usage. We then redesigned the system to allow direct R&W access from the Broker to a shared common DB. The diagram below illustrates the updated architecture: Phase 2: Consolidating the Broker While Phase 1 significantly delivered cost savings, we looked for further optimization opportunities. This led us to consider whether we could consolidate the system into a single Broker instance. However, there was one challenge: as an identity provider, we also offer redirect URLs to external third party services. If those URLs were to change, it would require the third parties to update their configurations as well. So we started thinking about how we might migrate without changing the domain. With support from our infrastructure team, we realized that by updating DNS settings in Route53 and routing traffic through CloudFront to the new unified server, we could avoid changing the domain altogether and transition to a unified Broker. When implementing the design as shown above, we were concerned about the impact on latency caused by the increased physical distance between servers, particularly from the UserPool to the now-centralized Broker. So, we measured it. The results showed that communication between the UserPool and the Broker became about 10% slower, but since the Broker was now located in the same region as the database, DB communication became faster. Overall, there was no significant impact in end-to-end performance before and after the architecture change, so we proceeded with planning for the Phase 2 migration. Results Through these two phases, we optimized the system architecture to better align with the actual usage patterns of our business operations. Going forward, we will continue reviewing system functionality and regularly working on cost-efficiency efforts.

Introduction Hello! I am Ren.M, working on the front-end development of KINTO ONE (Used Vehicles) . I am pleased to announce that KINTO Technologies Corporation will be a Gold Sponsor at TSKaigi 2025, which will be held on Friday, May 23, and Saturday, May 24, 2025. What is TSKaigi 2025 TSKaigi is Japan's largest technology conference themed around TypeScript. Event Dates: May 23 (Fri) and 24 (Sat), 2025 Venue: Bellesalle Kanda (Chiyoda-ku, Tokyo) Official Website: https://2025.tskaigi.org/ Sponsored LT On the second day, from 11:20 to 11:30, our company's Torii( @yu_torii ) will be holding a sponsored LT! He is scheduled to talk on the theme of Backend Code-First OpenAPI Schema-Driven Development so please look forward to it! Sponsored Booth We have prepared a survey about TypeScript at our booth! Those who complete the survey can try their luck at our capsule toy machine and receive original novelty items as a gift! We Are Hiring！ At KINTO Technologies, we are looking for new team members to work with us! We are open to casual interviews to start with. If you are even slightly interested, please apply through the link below! https://hrmos.co/pages/kinto-technologies/jobs/0000127 Conclusion If you are interested, please visit our booth! We look forward to meeting you at the event!

はじめに こんにちは！ KINTO ONE(中古車) のフロントエンド開発をしていますRen.Mです。 この度、KINTOテクノロジーズ株式会社は 2025年5月23日(金)・24(土)にて開催されるTSKaigi 2025ゴールドスポンサーを務めます。 TSKaigi 2025とは TSKaigiは、日本最大級のTypeScriptをテーマとした技術カンファレンスです。 開催日程：2025年5月23日(金)・24日(土) 会場：ベルサール神田（東京都千代田区） 公式サイト： https://2025.tskaigi.org/ スポンサーLT 2日目の11:20〜11:30に弊社の鳥居( @yu_torii )によるスポンサーLTを行います！ 「バックエンドのコードファーストなOpenAPIスキーマ駆動開発」 というテーマでトークを予定していますのでお楽しみに！ スポンサーブース ブースではTypeScriptにまつわるアンケートを用意しています！ 回答いただけた方にはガチャガチャを回していただき、オリジナルノベルティをプレゼントします！ We Are Hiring！ KINTOテクノロジーズでは一緒に働く仲間を探しています！ まずは気軽にカジュアル面談からの対応も可能です。少しでも興味のある方は以下のリンクからご応募ください！ https://hrmos.co/pages/kinto-technologies/jobs/0000127 おわりに 興味をお持ちの方はぜひブースまでお越しください！ 当日みなさまに会場でお会いできるのを楽しみしています！

はじめに こんにちは！KINTOテクノロジーズでデザイナーをしているKです。 普段はECサイトのUI/UXデザインをメインで担当していますが、時々コミュニケーションデザインも担当させてもらう機会があります。 2024年11月に開催された社内イベント「超本部会」で、そのイベントの顔となるロゴの制作を担当することになりました！せっかくなので、今回はその制作の裏側やこだわったポイントをゆるっとご紹介したいと思います。 ロゴって何？ ロゴって、ただの飾りじゃなくて、そのブランドやイベントの「顔」になるものですよね。 パッと見ただけで「これはあのイベントだな！」「これみたことある！」ってわかるし、見た人にどんな印象を持ってもらうかを大きく左右します。 「なんとなくカッコいいから」という理由だけで作るのではなく、「このイベントってどんな雰囲気？」「どんなメッセージを伝えたい？」「見た人にどんな印象を持ってもらいたい？」を考えながらデザインしていくことが大切だなと、改めて実感しました。 コンセプトを固める：イベントの核を探る まずはイベント全体のアートワークを監修するアートディレクターの方にヒアリング。 イベントの目的や伝えたいメッセージを整理しながら、ロゴに込めるコンセプトを考えていきました。 超本部会イベントコンセプトは「主体性」と「交流」。 仲間と主体的につながる場であること 自分たちが「主体的に行動できる会社だ」と実感できること 仲間とワイワイ楽しむエネルギーが、次の挑戦への活力になること こうした思いを、「自由に楽しめるデザイン」「仲間と盛り上がれるエネルギッシュな雰囲気」で表現したいと考えました。 デザインの方向性を探る 次は、コンセプトをもとに、どんなビジュアルが合うかを探るフェーズ。 「自由に楽しめるデザイン」「仲間と盛り上がれるエネルギッシュな雰囲気」をどう表現するか？を考えたときに浮かんできたのが、「オタク文化×テクノロジー」というテーマでした。 イベントには、開発やクリエイティブに関わるメンバーが多く参加します。そういった参加者たちにとって、アニメやゲーム、メカ、マンガといった“オタク的”なカルチャーは、親しみがあってワクワクする要素のひとつ。そこにテクノロジーの未来感を掛け合わせることで、より自由で、ポジティブな熱量を持った世界観をつくれると考えました。 検討したビジュアル要素はこんな感じ： メカ・ロボット・特撮の要素 ：無機質な硬さやメカっぽさを取り入れる 漫画・コミック的な要素 ：勢いのある文字や吹き出しのようなシェイプを試す デジタル感のあるタイポグラフィ ：少し未来感のある雰囲気に まずは手描きでラフスケッチを描きながら、アイデアをどんどん出していきました。 ラフ案を選定して、データ化へ スケッチから方向性が見えてきたところで、Illustratorを使って本格的にデータ化。 ラフを整理しながら、ベースとなる形を作成 微妙なニュアンスの違いで複数バリエーションを制作 アートディレクターと「どれが一番コンセプトを体現できているか」を検討 もちろんボツ案もたくさん出ましたが、この試行錯誤のプロセスこそが、いいデザインを生むためには欠かせないと改めて感じました。 ディテールの磨き込み ラフが固まったら、仕上げフェーズです。ここでは、細かい部分まで納得がいくように調整を重ねていきました。 そして、 ロゴの印象を決定づける大きな要素のひとつが「フォント」。 例えば、丸みを帯びたフォントは柔らかさや親しみやすさを感じさせ、シャープなフォントは洗練された印象を与えます。ちょっとした違いが、ロゴ全体の雰囲気を大きく左右するんですよね。 今回は既存のフォントに頼らず、オリジナルでフォントを書き起こしました。イベントのキーワードである「主体性」と「交流」をイメージしながら、以下の点を意識して調整： 視認性の向上 ：読みやすく、文字の幅や縦横比、余白を整えることで全体にまとまりを持たせる 曲線の調整 ：パスの数を減らして、滑らかで整った印象に 漢字とカタカナの調和 ：並んだ時に違和感が出ないよう、形状の統一感を意識 赤い基準線と見比べると、最終的な形は大きく変化しました。フォント選びや細部の形の違いが、ロゴの印象を大きく左右することを、改めて体感したプロセスでした。 ロゴの完成：遊び心と汎用性のバランス そしてついにロゴが完成しました！ 遊び心を取り入れつつ、いろんな場面で使いやすい汎用性をキープ サブカル×テクノロジーのミックス感が自然に表現できた シェイプやフォントにこだわることで、全体の完成度がUP！ まとめ ロゴデザインって、本当にちょっとした差で印象が大きく変わるものなので、「これだ！」と思えるまでやりきることが大事だなと、今回改めて思いました。 今回は「なんとなくカッコいい」だけじゃなく、「このイベントらしさがちゃんと伝わって、いろんな場所で使えるデザイン」に仕上げられたかなと思っています。 この記事が、誰かのデザインのヒントや気づきになればうれしいです！

久しぶりのブログにどきどき。KINTOテクノロジーズ（以下KTC略）・クリエイティブ室の杉本です。 弊社は会社設立から3年目にあたる2024年、コーポレートサイトをリニューアルしました。設立から3年、今後もいっしょに働く仲間を増やすため、採用活動にフォーカスしたコーポレートサイトにしたいと人事部からリクエストがあり、プロジェクトがはじまりました。 採用にフォーカスしたコーポレートサイトということで、人事部はもちろんですが、会社の進むべき方向性を経営者から、現場の声を拾い上げるために、エンジニアでつくられた技術広報部のメンバーへヒアリングを行いました。 「会社が欲しい人材は、そもそもどんな人だ？」、「我々はどんな仲間といっしょに働きたいのか」など、それぞれの視点から、課題感や希望をヒアリングすると、コーポレートサイトが果たす役割が明確になっていきました。 「常にテクノロジーへの興味を持ち、最新の技術への感度が高く、 自発的に動くエンジニア＆クリエイターへ、KTCらしさを伝えるサイトにしていこう」。この目的をもとに、コンセプトを打ち出しました。 コンセプトは「The Power of Technology & Creativity」。トヨタのモビリティサービスをテクノロジーとクリエイティビティでリードしていこうという気持ちを込めたワードにしました。 コンセプトを立てておくのは、ひと手間なのかもしれませんが、制作過程で迷うときに、立ち戻る場所として、様々な職種の人が関わる案件ではとくに重要です。 「そんな機能はいるのだろうか？」「もっと、おもしろく魅せることはできないか？」視点の違う問いにも、このコンセプトがあれば、「だから、やる」「だから、やらない」の判断がしやすくなるからです。 パーソナリティの設定 次にクリエイティブ室として手がけたのは、会社を人として例えたら、どんな人で、どんなふるまいをするのかを明確にする「ブランドパーソナリティ」を設定。（※ブランドパーソナリティについては 後述 ） 「ブランドパーソナリティ」は、何もないところからはじめると、全社を巻き込むレベルの開発になるので時間とカロリーを使うのですが、コーポレートサイトのローンチは、採用が目的なだけにスピードが重要。そこで、弊社ですでに明文化していた「ビジョン」、「バリュー」、「カルチャー」、「働く姿勢」をもとに進めました。 導き出したKTCのパーソナリティは、ずばり「クリエイター」。創造者という役割で、私たちは「テクノロジーやクリエイティブの力でお客様にとって、最高の（使いやすく、分かりやすく、人に寄り添って、便利な）プロダクトを作る存在である」と、定義しました。 盛り上がるムードボードづくり ブランドパーソナリティが決まったので、次は具体的にコーポレートサイトの表現デザインをどう落としていくかになります。そこで、もうひと手間！担当デザイナーが手を動かす前に、クリエイティブ室全員で、ムードボードをつくりました。 この作業をすることで、コンセプト同様、ビジュアル面でも立ち戻る場があるので、迷走することがなくなるので、アウトプットまでがスムーズになります。 自分たちが思うKTCらしいビジュアルなどを持ち寄り、デザイナーどうし、ムードボードづくりはとても盛り上がりました。 ムードボードをつくることで、新たな発見もありました。それまでは、いわゆるカリフォルニアのキラキラしたテックカンパニーの勢いで制作したアウトプットになるかなと想定していたのですが、会社の存在を「我々は〜である」という視点で取り組むと、トヨタグループの現場主義を根底に据えた、日本のモノづくりのスピリットを尊重したプロフェッショナルエンジニアリング集団である（ありたい）という点が見えてきました。 ムードボードは、世界基準のモダンなシステムと、ブランドパーソナリティをベースとし、使いやすさと企業ブランドのうえに、表現を載せたアウトプットを目指しました。 クリエイティブのジャンプアップと効率化が実現 「パーソナリティ」「ムード」「サイトの目的」をクリアにしたことで、撮影のトーン、インタビュー内容、コピー、実装、すべてが一貫したつながりでつくれたので、結果的にクリエイティブのジャンプアップと効率化が叶うなと改めて思いました。デザイナー以外の関係者と話すときも、ロジカルに説明ができ、デザインの言語化までが叶いました。 おかげさまで海外アワードを受賞 こうして、リニューアルができたコーポレートサイトですが、おかげさまで国際的なWebデザインアワードである「CSS Design Awards」をはじめとする、複数の海外Webデザインアワードを受賞することができました。 みなさんもご覧になって、もしよければ、私たちに興味をもっていただければと思います！ コーポレートサイトはこちら！ https://www.kinto-technologies.com/ ※ブランドパーソナリティとは ブランド＝企業を人間に例えるとどんな要素、性格で構成されているかを示したものです（アーキタイプ）。一般的に「人柄」を12の属性に分けたフレームワークを活用し、企業の性格、思考、行動、振る舞い、持ち味などを探求していきます。これを持っていると、統一されたブランドイメージを常に発信することができるので、to Cでなくても、今回のようなコーポレートサイト制作やイベントで配るグッズまで、ターゲットとなる人に同じ印象でアピールすることができます。

Introduction Hello, this is Matsuo from the Cloud Infrastructure Group. Our team is responsible for taking care of a wide range of infrastructure-related tasks across the company, from design to operations. This time, I would like to introduce the AWS Transfer Family web apps , which were announced at re:Invent. https://aws.amazon.com/jp/about-aws/whats-new/2024/12/aws-transfer-family-web-apps/ In this article, I will give an overview of the web apps, the steps to create them, how to set them up, and share my impressions after trying them out. I hope you will find this helpful. Overview To put it simply AWS Transfer Family web apps let you build applications to manage files in S3 buckets directly from a browser without writing any code. Previously, accessing S3 through a GUI required dedicated tools like the AWS Console or WinSCP, both of which also needed configuration. This created challenges for non-technical and casual users as it made operation difficult. The new AWS Transfer Family web apps feature an intuitive interface that is easy to use, even without technical knowledge. Additionally, they are integrated with IAM Identity Center and S3 Access Grants, enabling fine-grained access controls. Pricing AWS Transfer Family web apps are billed hourly based on the number of units (each support up to 250 sessions for 5 minutes per session). Region Price Tokyo Number of units x 0.5 USD/hour For example, running one unit 24 hours a day will cost 12 USD/day , meaning it will cost 360 USD a month; so using it for long periods of time can be quite costly. That's a little pricey for such a simple service. Depending on the usage, the cost may outweigh the benefit, so it is important to use the service according to your needs. How to Create a Web App Now let's create a web app. (Note: Terraform is not supported at the time of writing this article, so I will use the AWS Management Console.) Log in to the AWS Management Console, select "Web Apps" from the AWS Transfer Family navigation pane, and click Create Web App. For now, just set the Name tag and click "Next." * IAM Identity Center configuration is required in advance . If you haven’t set it up yet, please make sure to prepare it in advance. Set the page title, logo, and favicon, then click "Create." This time, I will skip the logo and favicon.. This completes the creation of the web app! It's that easy! Configuring Users/Groups and S3 Access Grants Next, let's set up group assignments and S3 Access Grants for the web app. Group assignment Click "User and group assignment" on the web app details screen. Since I have already created groups, I will select an existing group to assign. Setting up S3 access grants Next is setting up Access Grants. There are two things to set: Location and Permissions. If you go to Access Grants from the S3 navigation pane, you will see the Permissions and Location tabs, from which you can use to configure access. Start by setting the Location. This defines the S3 bucket to be accessed, along with the IAM role that has the necessary permissions for that bucket. For testing purposes, I have granted the AWS managed policy "AmazonS3FullAccess" this time. Then move to Permissions. Specify the location you configured previously, then set the sub-prefix, permission level, grantee type, IAM principal type, and the IAM principal user, and create the permission. Authentication will be done through IAM Identity Center, and it is set up as shown in the image below. Although I have not set it this time, it seems possible to set app-specific access restrictions. Setting CORS Add CORS settings from Cross-Origin Resource Sharing (CORS) to the target S3 bucket so that you can view the contents of the bucket. Here’s the configuration I used: [ { "AllowedHeaders": [ "*" ], "AllowedMethods": [ "GET", "PUT", "POST", "DELETE", "HEAD" ], "AllowedOrigins": [ "https://${ウェブアプリID}.transfer-webapp.ap-northeast-1.on.aws" ], "ExposeHeaders": [ "Access-Control-Allow-Origin" ] } ] Try It Out If you made it this far, you're ready to go. After accessing the web app URL and completing authentication, the S3 management screen appears! You will see the S3 bucket you configured in Location settingss. Now let's actually try deleting an S3 file from the target bucket. I tried to access an object from a folder link, but... It didn't work. Turns out the IAM role used for Access Grants was missing the sts:SetContext permission. This is also mentioned in the User Guide as well. I added the settings and tried again, and was able to access the object successfully. By the way, if CORS is not configured properly, a Network Error will appear here. Now, let's select the object here and delete it. Simply select the file you want to delete (in this case, test1.txt) click the ellipsis, and choose Delete. The file has been deleted from the web app. I also confirmed that it was removed from the console. Impressions Although setting up IAM Identity Center and Access Grants was required, I was impressed by how easy it was to be able to build an S3 management app without writing any code. There were a few confusing aspects due to the numerous configuration settings, but I believe that support for Infrastructure as Code (IaC) will likely make it even more user-friendly in the future. This service is built on top of the Storage Browser for Amazon S3 , which was also announced at re:Invent, so if you are comfortable with programming, you can use that service to create your own customizations. https://aws.amazon.com/jp/about-aws/whats-new/2024/12/storage-browser-amazon-s3/ I hope this blog post was helpful to you.

自己紹介 2025年3月からKTCに入社したtetsuと申します。 前職ではインフラエンジニア(オンプレ・クラウド)をしており、KTCではPlatformエンジニアとしてジョインしました。 旅行と自然が好きで大きな休みのたびにどこか遠出にしています。 概要 本記事では、Github Actionsのワークフローにて、Docker Hubからパブリックコンテナイメージ(JDK, GO, nginxなど)をPullしていた設定を、ECR Public GalleryからPullするように移行する手順や設定を紹介します。 2025年4月1日から、未認証ユーザによるDocker HubのパブリックコンテナイメージPullに対して制限が厳しくなるという話でした。 具体的には、認証されていないユーザによるPullは、ソースIPアドレスあたり10回のPull/時間に制限されることになります。 詳しくは こちら 。 Github Actionsのワークフローを実行する仮想マシンは全ユーザが共有されるため、Docker HubからみたソースIPアドレスも限られたものになります。よって上記の制限により、Github Actionsを使ってコンテナのBuildを行うにあたりネックとなるため、対応策を練る必要がありました。 前提構成 弊社では以下のような構成でGithub Actionsを利用し、コンテナのBuildを自動化していました（ざっくり抽象化した構成になります）。 対応策の検討 Pull制限問題への対応策をいくつか検討しました。 Personal Access Token(PAT)を使用してDocker HubにログインしたうえでPull 「そもそもDocker Hubに認証すればいいじゃん」という声が聞こえてきます。 Docker HubのPATを発行して、Github ActionsのワークフローでそのTokenを利用してdocker loginすることで認証できます。 それによりPull制限を回避することができます。 ただし、PATは個人に紐づきます。 弊社ではGithub Actionsをチームで共用して使用するため、個人にTokenが紐づいてしまうと、ライセンス管理の面で好ましくないと考えています。 Organization Access Token(OAT)を使用してDocker HubにログインしたうえでPull 上記の方法と同じになるのですが、異なる点はOATという組織に紐づいた共有Tokenで認証するという点になります。 この共有Tokenを利用するには、Docker DesktopのライセンスをTeamもしくはBusinessにする必要があります。 Github Container Registry(GHCR)へ移行 Githubが提供するGithub Container Registry(GHCR)からコンテナイメージをPullする方法です。 Github Actionsのワークフローで{{ secrets.GITHUB_TOKEN }}を使用して認証することで、コンテナイメージをPullすることができます。 ただし、コンテナイメージの検索をするのが少し癖があり、検索しづらいです（Docker Hubで提供されているバージョンと比較するのが難しい印象です）。 ECR Public Galleryへ移行 AWSが提供するECR Public GalleryからコンテナイメージをPullする方法です。 ECR Public GalleryにIAMを利用して認証するか、認証しないかで制限が異なりますが、基本的には無料で使うことができます。 ECR Public Galleryに未認証ユーザはソースIPアドレスあたり以下のような制限になります。 1回/秒のPull 500GB/月のPull 一方で認証ユーザについてはアカウント単位で以下のような制限になります。 10回/秒のPull 5TB/月を超える転送については0.09USD/GB(5TBまでは無料) 以下ドキュメントにて詳細な上限が記載されています。 https://docs.aws.amazon.com/ja_jp/AmazonECR/latest/public/public-service-quotas.html https://aws.amazon.com/jp/ecr/pricing/ AWS アカウントを利用していない場合、パブリックリポジトリから転送されるデータはソース IP によって制限されます。 ECR Public GalleryにはDocker公式のコンテナイメージがあり、それがDocker Hubのコンテナイメージと対応しています。 そのため運用上利用しやすく、容易に移行がしやすいです。 案比較 上記の案をまとめてQCD評価しました。 比較表は以下の通りです。 案 Quality Cost Delivery PATを使用してDocker Hubにログイン × - 個人トークンに依存する状態のため組織としては好ましくない - 利便性については現状と変わりなし 〇 追加費用なし 〇 対応が工数が少ないためすぐ実装可能 OATを使用してDocker Hubにログイン 〇 現状から変わりなし × 利用ユーザに応じてライセンス費用が増える ×　ライセンス変更にリードタイムがかかる GHCRへ移行 △ Docker Hubで利用しているイメージとの対応が検索しづらい 〇 追加費用なし 〇　対応が工数少ないためすぐ実装可能 ECR Public Galleryへ移行 〇 Docker Hubで利用しているイメージとの対応が検索がしやすい 〇 追加費用なし 〇　対応工数が少ないためすぐ実装可能 PATとOATを利用する案は現状から利便性が変わらない点は優位である GHCRはGithubの{{ secrets.GITHUB_TOKEN }} を利用することで容易に実装ができるが、ECR Public Galleryと比べてコンテナイメージの検索がしづらい ECR Public GalleryはIAMポリシーで設定変更が必要であるが、軽微な修正であるので対応工数はそこまで増えない 上記を踏まえて、弊社では、対応工数が少なく、追加費用がかからない、かつ利便性の高い「ECR Public Galleryへ移行」案を採用することにしました。 ※ 各個人・各社によって環境は変わるので、必ずしもこの選択がよいとは限りません。 ECR Public Galleryへ移行するための設定 コンテナイメージの取得元修正、Github Actionsのワークフローを定義するYAMLファイル、AWSでの設定が必要になるためそれらを設定します。 構成図 コンテナイメージの取得元修正 コンテナイメージの検索 Dockerfileやdocker-compose.ymlなどでどこからコンテナイメージをPullするかを指定しているかと思います。今回はDockerfileでJDKのコンテナイメージの取得元をDocker HubからECR Public Galleryに移行するケースで説明します。 以下のようにDockerfileのFROM句があるとします。 FROM eclipse-temurin:17.0.12_7-jdk-alpine ECR Public Galleryにこのイメージが存在するかを こちら で検索します。 今回だと:の前のDocker Hubの公式コンテナイメージ（今回は eclipse-temurin ）を検索して、by Dockerになっているものを選択します。 「image tags」を選択して、イメージ一覧を表示します。 Docker Hubの公式コンテナイメージのタグ（今回は 17.0.12_7-jdk-alpine ）をimage tagsの検索欄に入力し、対象イメージを検索します。そして、「Image URI」をコピーします。 コンテナイメージの取得元修正 FROM句に修正後のコンテナイメージのURIをペーストします。 今回だと、以下のように修正になります（当初のURIと比べてpublic.ecr.aws/docker/library/が追加されています）。 FROM public.ecr.aws/docker/library/eclipse-temurin:17.0.12_7-jdk-alpine これでECR Public GalleryからコンテナイメージをPullするように設定ができました。 AWSの設定 ECR Public Galleryに認証してログインした状態でPullできるようにするため、IAMロールとIAMポリシーを作成します。 IAMロール Github公式ドキュメントで手順の案内があるので、こちらを参考にしてください。 https://docs.github.com/ja/actions/security-for-github-actions/security-hardening-your-deployments/configuring-openid-connect-in-amazon-web-services IDプロバイダの構築 -> IAMロールの構築の順に対応となります。 IAMポリシー ECR Public GalleryからPullするためのアクションを許可するIAMポリシーを作成します。 以下ドキュメントを参考にしています。 https://docs.aws.amazon.com/ja_jp/AmazonECR/latest/public/docker-pull-ecr-image.html { "Version": "2012-10-17", "Statement": [ { "Sid": "GetAuthorizationToken", "Effect": "Allow", "Action": [ "ecr-public:GetAuthorizationToken", "sts:GetServiceBearerToken" ], "Resource": "*" } ] } このIAMポリシーを上記で作成したIAMロールにアタッチをします。 Github ActionsにECR Public Galleryへのログイン処理の追加 ECR Public Galleryに認証した状態でログインするよう、Github Actionsのワークフローを定義するYAMLファイルでログイン処理を追加します。 弊社の環境ですと、Docker Buildのステップの前に以下の記載を追加します。 ## ECR Public Galleryへログイン - name: Login to ECR Public Gallery id: login-ecr-public run: | aws ecr-public get-login-password --region us-east-1 | docker login --username AWS --password-stdin public.ecr.aws ※ ECR Public Galleryがus-east-1リージョンに存在するため、 --region us-east-1 で明示的に指定します。 さいごに Github Actionsのワークフローにて、Docker Hubからパブリックコンテナイメージ(JDK, GO, nginxなど)をPullしていた設定を、ECR Public GalleryからPullするように移行する手順や設定を紹介しました。 この記事が皆様の開発や業務に役立てば幸いです！

This article is the entry for day 19 in the [KINTO Technologies Advent Calendar 2024](https://qiita.com/advent-calendar/2024/kinto-technologies)🎅🎄 1. Tech Blog Debut Hello! I'm Shiori ( @shor_t8q ) from the Generative AI Development Project. I am currently in charge of training, use case development, and technical support for generative AI! (Though I chose Web3 as the topic for my first Tech Blog post.) This blog is about how we used NFTs at a team activity during the CHO All-Hands Meeting (an in-person meeting event that brought together all employees across all offices) held on November 28, 2024. This is the perfect content for anyone interested in the in-house planning and deployment of large-scale company events, incorporating NFTs into internal activities, or learning more about the company culture at KINTO Technologies. Premise The NFT initiative introduced in this blog was made possible through the cooperation and dedication of all the organizers of the CHO All-Hands Meeting, the activities team, the novelty team, and the Creative Office. Furthermore, this blog is not sponsored by any of the companies providing the NFT services discussed here. The purpose of this blog is solely to share the experiences, creativity, insights, and lessons learned by those in charge of the activities and novelties. 2. About the CHO All-Hands Meeting  2-1. What is a CHO All-Hands Meeting? A CHO All-Hands Meeting is a company-wide event held by KINTO Technologies approximately once or twice a year. The CHO All-Hands Meeting covered in this blog was held on November 28, 2024, with approximately 300 attendees in person and around 50 attendees online. The meeting took place from 3:00 PM to 9:00 PM and was a highly exciting event with a wide variety of content. 2-2. Being Part of Organizing the activities and novelties About a month and a half before the CHO All-Hands Meeting, members from various departments came together to form the organizing team. I was assigned to be part of the team in charge of activities and novelties.  To promote communication across the company, we decided to create desk nameplates as novelty items. The design was handled by J-san from the Creative Office. 2-3. Concept of the CHO All-Hands Meeting The event's concept was "KTC is Made by You”, which was shaped by gathering input from executives, department heads, and managers about their thoughts on teamwork, company culture, and their vision for the future.  3. Activities at the CHO All-Hands Meeting 3-1. What is a team activity? It was the final section of the event, held at the end of the meeting from 7:00 p.m. to 9:00 p.m. Based on the concept of the CHO All-Hands Meeting, the activities team set the following two goals: To promote communication among participants and between members of different departments. To deliver an experience that leaves participants feeling grateful they joined. 3-2. What led to the use of NFTs in the team activity? The activity featured an NFT stamp rally, but why choose that format? I was originally in charge of novelties, but the idea started when I wondered, "What if the novelty items were NFTs?" and "Could this serve as inspiration for future NFT and Web3 projects?" I was also motivated by the desire to try something new and different. With that in mind, I began exploring ways to incorporate NFTs that aligned with the theme of the CHO All-Hands Meeting. Through online research, I discovered the concept of an "NFT stamp rally." Around the same time, members of the organizing team shared that a digital stamp rally had been used at the previous CHO All-Hands Meeting. That inspired us to take it a step further and evolve the concept into an NFT stamp rally. From that point on, I joined the team activity planning discussions, and we began exploring how to bring the NFT stamp rally to life.  4. What Is an NFT? 4-1. NFTs Are Unique Digital Assets NFT stands for "Non-Fungible Token." NFTs are one-of-a-kind digital assets that cannot be exchanged for other tokens due to their uniqueness and characteristics. In addition, NFTs use blockchain technology to ensure transparency in transactions. For example, Bitcoin is a fungible token, meaning one Bitcoin holds the same value as another, whereas NFTs are non-fungible because each NFT holds its own unique value.  Because of their non-fungible nature, NFTs have become a new tool to enhance fan engagement in art, games, music, movies, sports, entertainment, and corporate marketing activities, and their application in other industries is expanding as well. While NFTs provide a means of monetization for creators and a new marketing tool for companies, improving the transparency and traceability of transactions, they also come with challenges such as the environmental impact from the large amount of electricity it requires during mining, legal risks, and price volatility due to market fluctuations. 5. NFT Stamp Rally 5-1. Is it feasible to hold an NFT stamp rally at the team activity? Conducting a survey To explore whether it was feasible to distribute and exchange NFTs as part of the team activity, we began by conducting some research. Through this process, we came across a company called Sushi Top Marketing which has an extensive track record with NFT use cases including organizing NFT stamp rallies. They are also promoting a new concept called “Token Graph Marketing.” What is Token Graph Marketing? Token Graph Marketing is a new marketing approach that uses blockchain technology to reach users while protecting their privacy. Users' hobbies, preferences, and behavioral history can be analyzed based on their NFTs and other token information.  Source: What is Token Graph Marketing? Initial Ideas I had several discussions with the vendor based on the following initial ideas: Content Description Novelty Concept Activating communication among members who rarely interact with each other, stimulate communication and promote innovation, fostering a sense of unity, and provide novelties that appeal across age and gender. The solution should not deviate from this core concept. Accessibility Since the stamp rally would be held on a single day, it needed to be intuitive and easy to use Must be supported for both app and via QR code scanning. Value as a Novelty Showcase NFTs as a new type of novelty item, something participants can transfer to their own wallet and keep as a digital asset. Innovation Reflect the company’s emphasis on creativity and technology by trying something that hasn’t been done before. Brand Alignment Customize the UI to reflect the company’s brand identity, including its colors and character. Concept Visualization For example: “Each department has a different NFT stamp. When Employee A speaks with Employee B from another department, A receives a stamp from B’s department.” This encourages interdepartmental interaction. 5-2. Blockchain Technology Behind the NFT Stamp Rally For the NFT stamp rally, we chose to use Astar, a next-generation blockchain platform known for its compatibility with smart contract and dApps (decentralized apps). Astar is part of the Polkadot ecosystem, enabling interoperability between different blockchains.  5-3. NFT Stamp Rally Concept Idea brainstorming We received four initial proposals for the NFT stamp rally: Proposal Description NFT Card Exchange Participants collect NFTs by exchanging digital cards. Additional NFTs can be unlocked upon exchange. Dynamic NFT Stamp Rally Collecting specific NFT pairs unlocks special NFTs. Different combinations yield different results. NFT Distribution via LINE Commemorative NFTs are distributed through an official LINE account. Those who hold them receive a gift. NFT Business Cards & Stamp Rally NFC or QR-enabled cards are handed out before the event. These cards serve as novelties and as tools for collecting NFTs during the rally. We discussed and refined the proposals based on the following criteria: Criteria Criteria Description Workload Can everything be prepared in about one month? Usability Is it intuitive, with little to no manuals or explanations? Operability Can it run smoothly, in a relaxed atmosphere in an event with 300 participants? Simplicity Can it be used without complex operations or steps? Accessibility Can it be accessed without restrictions, needing third-party services? Innovation Does it offer an interesting NFT experience? Security Does it ensure data privacy and protection? Scalability Can it handle simultaneous access from a large number of users? Compatibility Is it mobile-friendly and Web3-compatible? Budget Alignment Is it achievable within the budget? Combining the ideas and our requirements, we finalized the following plan: 5-4. NFT Stamp Rally Planning Details Overview of the NFT stamp rally We issued 14 NFTs, covering each department, management team, and a completion certificate. Participants would visit different zones during the activity (such as spots where the management and award recipients are present), collect NFTs that are different from the ones they already hold, and engage in communication with members from other departments or the management team, whom they don't often have the chance to interact with. This promotes the start of new projects and fosters relationship-building. A gamified element was added, in which participants who collected all 13 NFTs could earn a final “completion” NFT, which was redeemable for a prize. NFT Collection Points Each participant’s name tags (distributed at check-in) would contain an NFC tag -explained later- and a QR code, allowing participants to collect NFTs through either NFC tapping or QR scanning. Providing both options ensured accessibility for participants who couldn’t use NFC. NFT Stamp Rally Flow Participants visit each zone. Interact with members from other departments and management. Post what they discussed in the chat linked to the department's NFT (sharing the conversations in the NFT-linked chat adds unique value to each department's NFT). Exchange NFTs with the members they interacted with and collect 13 NFTs. Earn the completion NFT. Post their Slack name in the completion NFT chat. The event staff later award prizes via Slack. NFT Design Since this was a company-wide event, we incorporated KINTO's brand character, Kumobii , into the NFT designs to strengthen the sense of unity and identity.  The NFT artwork was created by Momoi-san from the Creative Office. NTF Innovations We added original value to NFTs by: Each department having its own unique design. NFT names were written in both Japanese and English to accommodate global members. A unique collection name and event date attribute were added to each NFT. All NFTs included the keyword "KTC is Made by You," the theme of the CHO All-Hands Meeting. When combined, the NFTs formed the full theme of the activity. 6. Challenges in Realizing an NFT Stamp Rally 6-1. How Should NFTs Be Exchanged? What channel should be used? What technology should be adopted? Using NFT x NFC tags As an element of this get-together, we placed importance on adding small surprises and discoveries, such as "Oh, I didn't know that was possible!". By combining ideas from service providers and the organizing team members, we made it possible to receive an NFT simply by tapping a smartphone on an NFC chip embedded in a name tag. *NFC (Near Field Communication) is a technology and standard that enables wireless communication between devices in close proximity. . It's used in a wide range of applications, including smartphones, IC transit cards, credit cards, and smart appliances. How to write NFT information ito NFC tags? NFC tag: www.amazon.co.jp/dp/B0DFW9WTRW NFC writing app: https://apps.apple.com/jp/app/nfc-tools/id1252962749 We procured NFC tags from Amazon manually wrote NFT URLs for 13 types and approximately 300 people. To cover potential failures, we also prepared NFT QR codes for all participants. This process was carried out manually (the organizers, thyt-san and Oka-san, did the writing.) The completed tags were inserted into name holders.  6-2. How were the rules communicated to all participants? During the host's introduction before the start of the NFT stamp rally, the “NFT Stamp Rally Guide” was projected on screen, while the host and I worked together to make sure everyone was aware of the rules of the NFT stamp rally.  6-3. Since NFT exchange is done on a browser-based web app, how can participants avoid losing track of the NFTs they have acquired? I worked with the event MCs to provide the following information through the projected materials: The web app runs in a browser. Don’t use incognito mode. After acquiring your first NFT, add a NFT list shortcut to your home screen. Take a screenshot of your NFT backup code displayed during the NFT exchange. 6-4. How to issue completion NFTs Participants who collected all NFTs could show their NFT list to staff to receive a special completion NFT.  7. Lessons Learned 7-1. NFT exchange became the only activity everyone had time for Although we got to meet many team members we don't usually talk to, it was difficult to even find time to eat. It was difficult to share conversations with members in the chats linked to NFTs as originally envisioned, and achieving the goal of "accumulating the insights and ideas of department members in each department's NFTs and turning them into unique value for each department's NFT" proved challenging. In addition, the original plan envisioning people exchanging NFTs across zones (spots where management, honored members, awarded members, would stay) didn’t pan out either. At an activity that encourages free communication, there was no need to set up zones. 7-2. We should have supported NFT type-checking Participants commented that, since it was possible to obtain multiple NFTs from any member of the same Department A, participants often ended up with similar designs, such as multiple NFTs from Department A. This made it difficult to check which types of NFTs were still missing. This should have been considered in advance and addressed. 7-3. The completion process should've been simpler. As mentioned in 5-4, things didn’t go as smoothly as expected. Asking participants to post a screenshot of their completed NFT list in Slack could have helped. It would have made it easier for staff to confirm completions. Also, by reporting completion in an open space such as a Slack channel, "My colleague, so and so, has completed it!" would have motivated others and encourage more participation. 7-4. More flexibikity in choosing channels for NFT touchpoints. We manually wrote NFT URLs for 300 people onto the NFC tags. However, considering the potential for human error and the amount of workload involved, it may be better to explore other touchpoints and channels for larger events. 7-5. Provide more proactive English support About 25% of KINTO Technologies' employees are international. Although presentation slides were prepared in both Japanese and English, but when speaking with several international members at the activities, we found ourselves giving additional explanations in English during the event. Things would have gone even more smoothly if we had shared the presentation materials on the Slack channel beforehand and provided explanations in English at the start of the stamp rally. 8. NFT Stamp Rally Results 8-1. 10% of Participants Completed the Rally!!! Out of approximately 300 participants, 30 people, or 10% of the participants completed the NFT stamp rally .  8-2. Overall results A total of 1,734 NFTs were distributed. On average, participants exchanged 6.6 NFTs per person , with a median of 6 . That means each participant talked to members from around 6 different departments . One of the goals was to interact with members from other departments at the team activity, so it can be said that the NFT stamp rally fulfilled that goal. Metric Result Completed participants 30 Total NFTs issued 1734 Average NFTs exchanged 6.6 Median NFTs exchanged 6 9. Future Posibilities for NFTs We learned that NFT stamp rallies can visualize movement and engagement at in-person networking events. Interestingly, it allowed us to see how many NFTs each department issued, which enabled us to identify which departments were most active in communicating with other departments. This experience expanded our vision on how NFTs could be used both online and offline in KINTO Technologies' KINTO product offerings, such as MaaS-related apps and member services. For instance, I thought that NFTs could be effective for approaching customers based on their hobbies and preferences, rather than traditional attributes such as age and gender, and for visualizing customer communication and behavior.  10. Conclusion Through the NFT stamp rally initiative, we realized the potential that can arise from the fusion of new technologies and ideas. It was a valuable experience to create an opportunity for members from different departments to interact and engage with technology in a fun way during a team activity. We’ll keep exploring how to integrate new technologies in engaging ways and share our findings along the way. If you're thinking about trying a project involving NFTs, AI, or Web3, go for it! I'm sure you'll discover something interesting! Thank you for reading until the end!

こんにちは。 DBRE チーム所属の @p2sk です。 DBRE（Database Reliability Engineering）チームでは、横断組織としてデータベースに関する課題解決やプラットフォーム開発に取り組んでいます。 先日、OSS のリポジトリ terraform-provider-aws に対してコントリビュートする機会がありました。具体的には、AWSが 2024 年 10 月に一般提供を開始した DynamoDB or S3 と Redshift との マネージドなデータ連携を Terraform で管理できるようにする「 aws_redshift_integration 」というリソースを新規実装しました。 PR は既にマージ されており、 v5.95.0でリリース され、機能が使えるようになりました。 私は今回が初めての OSS 貢献だったので、完走できるか不安な部分もありましたが、生成 AI の力も借りながら PR の作成までやり切ることができました。 新機能が AWS で GA されてから、Terraform で管理できるようになるまで（＝terraform-provider-aws に新規リソースとして実装されるまで）、数ヶ月かかる場合もあります。そのような場合に、実装されるのを待つ代わりに自分で実装する選択肢を取れるようになったことは、大きなアドバンテージだと感じました。そこで本記事では、私と同じように初めて Terraform の AWS Provider に新規リソースを追加するコントリビューションに取り組みたいと考えている方に向けて、初回から効率的に取り組んでもらえるような情報を提供することを目指します。 いずれはコーディングエージェントに issue を渡すだけで PR 作成まで行ってくれる未来になっているかもしれませんが、現時点ではそこまでは難しい印象で、同じような境遇の方の参考になれば幸いです。 今回追加したリソースについて 今回は以下の 2 つの機能を管理できるリソースを追加しました。それぞれ簡単に説明します。 DynamoDB から Redshift への zero-ETL 統合 S3 から Redshift への event integration zero-ETL 統合は、ETL パイプラインの構築が不要な、マネージドなデータ連携機能です。「zero-ETL 統合」という機能は、最初は Aurora MySQL と Redshift 間のデータ連携として提供が開始され、その後複数のデータソースとターゲットに対象が拡大しています。アーキテクチャ図を以下に示します。  出展：AWS - Amazon Redshift との Amazon DynamoDB ゼロ ETL 統合の始め方 S3 から Redshift への event integration も同様に、S3 バケットに追加されたファイルを自動かつ高速に Redshift に連携する機能です。 これらは機能としては別々ですが、 Integration を作成する API は同一 です。terraform-provider-aws のリソースは API にマップされるため、この API を Terraform 対応させることで、上記 2 つの機能が同時に実装されることになります。したがって、追加したリソース自体は 1 つだけです。 リソース追加の判断基準 公式ドキュメント に以下の記載があります。 New resources are required when AWS adds a new service, or adds new features within an existing service which would require a new resource to manage in Terraform. Typically anything with a new set of CRUD API endpoints is a great candidate for a new resource. 和訳： AWS が新しいサービスを追加したり、既存のサービスに新しい機能を追加したりする場合、Terraform で管理するための新しいリソースが必要になります。一般的に、新しい CRUD API エンドポイントセットを持つものは、新しいリソースの候補として最適です。 ということで、 新しい CRUD API エンドポイントセットを持つかどうか が大きな判断基準となりそうです。今回はこれを満たしており、新規リソース追加の実装を行いました。 Contribution の流れ 流れは 公式のドキュメント に非常によくまとまっています。 開発環境を準備 コードのデバッグ（今回は新規リソース追加のため、スキップ） コードを変更 テストを書く 継続的インテグレーション 変更ログを更新 プルリクエストを作成 上記の項目をベースにしつつ、本記事で推奨する手順を以下に整理します。また、各項目でかかる労力を個人の実体験をベースに「★」の数で示します。詳細な手順は公式のドキュメントの確認が必要ですが、実際に取り組んで得られた知見をまとめているため、ぜひ参考にしてください。 関連 issue の調査または作成 ★ 対応する AWS API と SDK の事前調査 ★ 開発環境を準備 ★ 対象リソースの動作検証・依存リソースのコード化 ★★★ scaffolding ツールでベースとなるコードを生成 ★ コード修正と動作確認 ★★★★★ テストを書く ★★★ 継続的インテグレーション用のテストのローカル実行 ★★ ドキュメント修正 ★ プルリクエストを作成 ★ 変更ログを作成して push ★ 以降は各手順の詳細について触れていきますが、開発をスタートする前に知っておくと良さそうなことを先にまとめます。 留意事項 複数種類の SDK による書き方が混在 terraform-provider-aws では、リポジトリ内で異なる SDK を用いた 2 パターンの書き方が混在しています。 Terraform plugin framework 現時点で使用が推奨されている、新しい SDK Terraform Plugin SDKv2 旧 SDK のため新規利用は非推奨。ただし、この SDK で実装されたリソースのバグ修正などで使うこともある サポート終了の v1 でのコードもまだ存在している可能性もあるため、正確には 3 パターンかも 従って、生成 AI に調査やコーディングを依頼する場合は Terraform plugin framework を対象にすることをプロンプトに含める方が良いです。 この辺りの歴史的経緯などに興味のある方は、 ChatGPT Deep Research のリサーチ結果 を、ハルシネーション混入の可能性に留意いただきつつご確認ください。 ライセンスについて Terraform 本体は 2023年に ライセンスが BSL に変更 され、OSS の定義からは外れていますが、terraform-provider-aws は引き続き MPL 2.0 で、OSS のままになっています。 各種プロバイダは Terraform から fork された opentofu でも使われているようです。 opentofu 用の AWS Provider も terraform-provider-aws から fork されているため、プロバイダーにコントリビュートすると、間接的に Terraform と opentofu 両方に貢献できることになりそうです。 この辺りの経緯に興味のある方は ChatGPT Deep Research のリサーチ結果 をご覧ください。（ハルシネーションに関して同様にご留意ください） 以降では、実際の手順について解説します。なお、記事内でのテストの実行時間などについては、以下の環境におけるおおまかな体感の値です。 マシン : MacBook Pro チップ : Apple M2 Pro メモリ : 32 GB 1. 関連 issue の調査または作成 PR の作成時は、関連 issue へのリンクを記載します（例：下図「Relations」）。そのため、関連する issue を最初に探して、なければ作成します。  既に issue が作成されている場合は、他の誰かが取り組んでいるケースもあります。issue のコメントを一読し、「まだ誰も着手していなさそうか」などは確認しておくと良さそうです。 今回は既に issue が作成されていたため、PR 作成時は既存 issue へのリンクを記載しました。 2. 対応する AWS API と SDK の事前調査 リソースを新規実装するためには、go の SDK（aws-sdk-go-v2）が該当リソースの CRUD 操作に対応している必要があります。基本的には GA されたタイミングで SDK も提供されると推測しますが、多少のラグはあるかもしれません。terraform-provider-aws の go.mod も、該当リソースに対応したバージョンにアップデートされている必要がありますが、 メンテナーにより頻繁に更新されている印象 なので、自分でアップデートしなくても、メンテナーにより最新化されている可能性が高い、という認識で良さそうです。 今回は、以下のリファレンスをブックマークに登録しておくことで、開発途中に都度参照できて便利でした。生成 AI に参照させる場合も重宝すると思います。 API リファレンス https://docs.aws.amazon.com/ja_jp/redshift/latest/APIReference/API_CreateIntegration.html https://docs.aws.amazon.com/ja_jp/redshift/latest/APIReference/API_ModifyIntegration.html https://docs.aws.amazon.com/ja_jp/redshift/latest/APIReference/API_DeleteIntegration.html https://docs.aws.amazon.com/ja_jp/redshift/latest/APIReference/API_DescribeIntegrations.html SDK リファレンス https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/redshift#Client.CreateIntegration https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/redshift#Client.ModifyIntegration https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/redshift#Client.DeleteIntegration https://pkg.go.dev/github.com/aws/aws-sdk-go-v2/service/redshift#Client.DescribeIntegrations 当初は DynamoDB の zero-ETL 統合を Terraform 対応させるのがモチベーションだったのですが、リファレンスを見ると API の SourceARN パラメータのパターンが下図の通り S3 にも対応していることがわかり、S3 の integration も同時に検証しなければいけないことに気づけました。このように、検証のスコープが想定より広い場合もあるため、リファレンスの入出力は最初に一通り確認しておくと良さそうです。  出展：AWS - Redshift CreateIntegration API Reference また、リソースの種類によっては Delete が存在しないものや、Modify が存在しない場合もあるかもしれませんので、その場合は提供されている API だけ実装すれば OK です。例えば、Aurora MySQL と Redshift 間の zero-ETL 統合は、GA 時点では Create / Delete / Describe のみ提供され、後で Modify が提供されたようです。 Redshift は SDK のディレクトリとして redshift と redshiftserverless が存在し、片方でいいのか両方実装すべきなのか迷いましたが、 redshiftserverless 側には該当の API が存在しなかったのと、redshift 側の関数で serverless 用の Integration も作成できたことから、redshift 側だけ実装すれば良いと判断しました。 3. 開発環境を準備 公式のドキュメント に記載の手順通りに実行すれば OK です。ただし、実際のリソースを作成して動作確認を行う make testacc はこの時点では不要です。 make test も実行しなくても良いかもしれませんが、私の環境では 3-40 分ほどかかりました。 Using the Provider に記載の手順を実行することで、手元で build した Provider を使って Terraform コマンドを実行できるようになります。実行時に以下のような warning が表示されることを確認できれば OK です。 これで、自分で build した Provider が Terraform 実行時に使われていることが確認できます。なお、後述の「受け入れテスト」というテスト経由でも動作確認自体はできるのですが、build と動作確認のサイクルを高速に回すためには、自分で build した Provider を使って Terraform コマンドを実行するのが良いと思います。個人的には、この手順で動作確認することで、普段と同じ Terraform の使い方の中で動作が確認できてイメージしやすかったです。 詳細にデバッグしたい場合は delve を使うと良さそう です。 4. 対象リソースの動作検証・依存リソースのコード化 コーディングを開始する前に、まずは追加しようとしている新規 AWS リソースの動作確認を手元で行っておくと理解が深まります。この時、大抵は新規の AWS リソースを作成する前に、依存しているリソースを作成する必要があると思います。例えば、今回は以下の AWS リソースに依存しています。（正確には、Source は プロビジョニングされた Redshift / Redshift Serverless / S3 のいずれかだけで OK） aws_vpc aws_subnet aws_security_group aws_dynamodb_table aws_dynamodb_resource_policy aws_redshift_subnet_group aws_redshift_parameter_group aws_redshift_cluster aws_redshift_resource_policy aws_kms_key aws_kms_alias aws_kms_key_policy aws_redshiftserverless_namespace aws_redshiftserverless_workgroup aws_s3_bucket aws_s3_bucket_public_access_block aws_s3_bucket_policy aws_iam_role aws_iam_role_policy aws_redshift_cluster_iam_roles このような依存リソースは、この時点で tf ファイルとしてコード化しておくことを強くお勧めします。理由は以下の通りです。 検証、開発が 1 日で終わらない場合はコストがかかるため、都度 apply & destroy したい 後述の「受け入れテスト」でほぼ同様の Configuration を用意する必要があるので、最初に用意しておくと後で楽 terraform fmt でフォーマットもしておくと後述の CI テストのローカル実行もより楽に 生成 AI を活用することで HCL のコーディングはかなり時短できると思います。依存リソースのコード化が完了したら、あとはコンソールか AWS CLI を使って手動で対象リソースを作成して動作検証します。 5. scaffolding ツールでベースとなるコードを生成 新しいリソースを追加する場合 は、 Skaff という scaffolding ツールを使ってベースとなるコードを生成することが推奨されています。 リソースタイプ名は 命名規則 が決まっており、 aws_${サービス名}_${AWSリソース名} となります。AWS リソース名は、sdk の関数名に従う必要があります。例えば今回は「CreateIntegration」関数が提供されているため、AWS リソース名は「Integration」となります。サービス名は リポジトリの service ディレクトリ の値を使えば良さそうです。 したがって、今回のリソースタイプ名は aws_redshift_integration となります。この名前はブランチ名にも反映する必要があり、 f-aws_redshift_integration としました。skaff では AWS リソース名を指定すれば良いので、該当サービスのディレクトリへ移動した後に、以下のコマンドを実行しました。 $ pwd /Users/masaki.hirose/workspace/terraform-provider-aws/internal/service/redshift $ skaff resource --name Integration Skaff を実行することで、リソース用のコード、テストコード、ドキュメントの 3 ファイルが生成されるようです。生成されたファイルは こちら からご確認いただけますが、コメントが手厚く記載された親切なファイルになっています。また、これらの初期状態のファイル達と、 最終的にマージされたコード を比較すると、どこを修正すべきかイメージがつきやすいと思います。 6. コード修正と動作確認 生成されたコードをベースに、動作するように修正していきます。 ドキュメントに記載の通り 、Resource Schema をまずはコーディングして、その次に CRUD ハンドラを実装していきます。 Terraform plugin framework では、CRUD ハンドラがそれぞれ「Create」「Read」「Update」「Delete」という直感的な関数名になっています。例えば、初めて terraform apply して新規リソースが作られる際に、ここで実装した Create() 関数が呼ばれます。その中で go の SDK の対応する関数（この場合は CreateIntegration ）が実行され、内部的には対応する AWS API（この場合は CreateIntegration ）が実行され、リソースが作成される、という流れになります。 terraform apply で Replace を伴わない修正のみが実行される場合は Update() 関数が、 terraform destroy でリソースを削除する場合は Delete() 関数が実行されます。リソース情報を読み取る必要がある場面では都度 Read() 関数が呼ばれます。 Resource Schema の実装 Schema() 関数の中で、Terraform が受け付ける引数（arguments）および出力する属性（attributes）をスキーマ情報として定義します。以下のコードのように、Attributes マップに各フィールドを定義します。各属性はキーが Terraform 上の名前（snake case）、値が schema.Attribute インタフェースを実装した構造体で、schema.MapAttribute や schema.StringAttribute などから適切なものを用います。 // 修正後の Schema() 関数の一部を抜粋 func (r *integrationResource) Schema(ctx context.Context, req resource.SchemaRequest, resp *resource.SchemaResponse) { resp.Schema = schema.Schema{ Attributes: map[string]schema.Attribute{ "additional_encryption_context": schema.MapAttribute{ CustomType: fwtypes.MapOfStringType, ElementType: types.StringType, Optional: true, PlanModifiers: []planmodifier.Map{ mapplanmodifier.RequiresReplace(), }, }, names.AttrARN: framework.ARNAttributeComputedOnly(), names.AttrDescription: schema.StringAttribute{ Optional: true, }, "integration_name": schema.StringAttribute{ Required: true, }, 上記のように、SDK のリファレンスで必須になっているパラメータには Required: true を指定し、変更時にリソース置き換えが必要な場合は RequiresReplace() modifier を付与します。適切な modifier を使い分けるのが個人的には難しかったです。modifier は自分でも実装でき、1 つだけどうしても自前で実装が必要と判断して実装したのですが、PR 作成後にメンテナーによって既存の modifier に置き換えられていました。迷った場合は stringplanmodifier など、対象の型に対応する modifier で提供されている関数を最初に理解して、使えないか確認するのが良いと思います。PR 作成後のメンテナーからのフィードバックを通して、基本的には既存の modifier でカバーできるのだなという学びがありました。 合わせて、ResourceModel 構造体も定義します。 type integrationResourceModel struct { AdditionalEncryptionContext fwtypes.MapValueOf[types.String] `tfsdk:"additional_encryption_context"` Description types.String `tfsdk:"description"` IntegrationARN types.String `tfsdk:"arn"` IntegrationName types.String `tfsdk:"integration_name"` KMSKeyID types.String `tfsdk:"kms_key_id"` SourceARN fwtypes.ARN `tfsdk:"source_arn"` Tags tftags.Map `tfsdk:"tags"` TagsAll tftags.Map `tfsdk:"tags_all"` TargetARN fwtypes.ARN `tfsdk:"target_arn"` Timeouts timeouts.Value `tfsdk:"timeouts"` } CRUD ハンドラと関連処理の実装 CRUD ハンドラはいずれも、SDK への入力構造体を組み立てて、SDK の関数を呼び出す流れで実装します。また、CRUD ハンドラ内で利用する関数も合わせて実装します。これには、以下のようなものがあります。 該当リソースの情報を取得するための finder 関数 リソースの作成、修正、削除が完了するまで待つ waiter 関数 リソースのステータスを取得する status 関数 リソースを全削除する sweeper 関数（テスト向けの機能であり、必須ではない模様） 注意点として、service によっては wait.go / find.go など専用の go ファイルが用意されており、その場合はそのファイルに処理を追記する必要があります。そうでない場合は、実装中のファイルに全て処理を記述して問題ないようです。今回対象となった redshift サービスでは wait.go などが存在しており、そちらに追記する形をとりました。 リソースの登録 実装が完了したあとは、Terraform Provider にそのリソースを認識させる登録処理を行います。以下のようなアノテーションが必要ですが、skaff で生成されたコードにすでに入っているので自分で記述する必要はありません。削除しないようにだけ注意しておけば OK です。 // @FrameworkResource("aws_redshift_integration", name="Integration") func newIntegrationResource(context.Context) 上記アノテーションを記述したら、プロジェクトルートディレクトリで make gen を実行します。これにより、各サービスパッケージ内の service_package_gen.go が再生成され、新規実装したリソースも Provider 登録されます。ここまできたら、 make build でビルドし、通れば実際に terraform apply などで動作を確認できる状態になります。 動作確認 新規実装したリソースを HCL で記述し、 terraform apply して動作確認します。手順「# 4. 対象リソースの動作検証・依存リソースのコード化」において、すでに依存リソースはコード化が終わっているので、ここでは新規実装したリソースだけを、別のディレクトリの新規ファイルに記述し、別の state で管理します。これにより、動作確認したい新規リソースだけを apply & destroy できるので確認スピードが上がります。もしくは以下のようにターゲットを指定することで、1 ファイルに全て記載している場合でも個別に apply する方法を取るのでもいいと思います。 terraform plan -target=new_resource_type.hoge -out=myplan terraform apply myplan 7. テストを書く terraform-provider-aws では、以下の 3 つのテストがあります。 受け入れテスト （Acceptance Tests） Terraform を実行し、AWS 上にリソースを作成したり、更新、削除できることを確認するテスト。実際にリソースを操作するので金銭的費用が発生。そのため「実行は任意」とドキュメントに書かれている。 ユニットテスト 関数レベルのテスト。今回は不要と判断し、未作成。 CI テスト PR 作成後に実行される、lint / format などを含む包括的なテスト。 CI テストはすでに用意されているものを実行するだけなので、受け入れテストとユニットテストが、コントリビューターが書くべきテストになります。ユニットテストは複雑な処理などを実装した場合に書くことが推奨されており、今回は不要と判断し、受け入れテストだけを書きました。受け入れテストでは、以下のコードのように、テストに必要な AWS リソースを HCL で記述する必要があります。 func testAccIntegrationConfig_base(rName string) string { return acctest.ConfigCompose(acctest.ConfigVPCWithSubnets(rName, 3), fmt.Sprintf(` data "aws_caller_identity" "current" {} data "aws_partition" "current" {} resource "aws_security_group" "test" { name = %[1]q vpc_id = aws_vpc.test.id ingress { protocol = -1 self = true from_port = 0 to_port = 0 } ... ステップ「4. 対象リソースの動作検証・依存リソースのコード化」で既にコード化が完了していると、ここはほぼコピペで行けるので非常に楽でした。テストを実行する場合は、以下のように関数名を指定すると関数単位で実行できます。 make testacc TESTS=TestAccRedshiftIntegration_basic PKG=redshift リソース単位で一気にテストするには、以下のように「_」以降を削除して実行します。 make testacc TESTS=TestAccRedshiftIntegration PKG=redshift 8. 継続的インテグレーション用のテストのローカル実行 terraform-provider-aws リポジトリは、コードの品質を確保するための厳格な CI パイプラインを持っています。PR 作成後に実行されるものですが、ローカルでこれらのチェックを実行できる機能が提供されているので、できる限りローカル上でパスするように修正しておくと親切かと思います。 完全なチェックは make ci で実行できますが、私の環境だと数時間かかったので、まずは make ci-quick で検出された問題を修正してから make ci を実行するのが、待ち時間を最小化できると思います。 私の場合は何度か修正を行い、ローカル環境で make ci-quick を実行した際に全てのチェックをパスできましたが、 make ci 実行時は一箇所だけ GNUmakefile を修正しないとエラーになる箇所がありました。これは自分の環境特有の問題かもしれないため、PR に含めずローカルだけの修正で回避しました。 ドキュメント に記載がありますが、 make testacc-lint-fix を最初に実行すると、 terrafmt 関連の問題だけは自動で修正してくれるようなので、最初に実行しておくのも一手かと思います。 9. ドキュメント修正 skaff で生成されたドキュメントを修正します。ここで書いた内容が、 よく見るドキュメント として反映されます。既存のドキュメントを参考に書いていけば問題ないと思います。 10. プルリクエストを作成 こちらは特に迷うことはないと思います。 11. 変更ログを作成して push 公式のドキュメント に沿って問題なく作成できると思います。ファイルの命名規則的に PR の番号が必要なので、まず PR を出して、その後に変更ログを作成して push すれば OK です。 ここまでで、PR を作成するまでの流れをお伝えしました。以降では、本取り組みにより得た知見をシェアします。 メンテナーによる修正内容 先日、PR は無事にマージされ、 v5.95.0でリリース され、機能が使えるようになりました。マージまでに、メンテナーによりコードが修正されていたので、どのような修正が行われたかをご紹介します。 schema.Attribute から ID の削除 skaff で生成されたコードにも以下のコメントが記述されていましたが、気づけずに ID 属性を残していたところ、不要とのことで削除されていました。AWS API のリファレンスを見て残すか決めた方が良さそうです。 // Only include an "id" attribute if the AWS API has an "Id" field, such as "IntegrationId" names.AttrID: framework.IDAttribute(), 変数名などの変更 この修正がもっとも多く、自分の命名規則の確認が甘かったと思われます。一方で、「resourceIntegrationModel」という構造体名は skaff によって自動で生成されたものですが、「integrationResourceModel」という修正が加えられており、この辺りは skaff による命名規則の実装に若干の不備があるのかもしれません。 自作の modifier を既存の modifier へ置き換え ある問題を解決するために、自分で plan modifier を実装したのですが、 既存の modifier に修正 されていました。 ここは自分でも自信がない箇所だったので、 手厚めに PR にコメントを残しておいた ところ、以下のコメントもいただき、既存の modifier をもっとよく調べておくべきだったと反省しました。しかし、「なぜこの実装にしたのか」を詳細に示しておいたことで、メンテナーが修正の判断を行いやすい状態にはできたかなと思います。 This can be accomplished with the RequiresReplaceIfConfigured plan modifier. この修正は LLM の力を借りて導き出せなかったかを確認するために、 実装中に使っていたプロンプトを修正して LLM に渡した ところ、上記の既存 modifier での修正案を提案してくれました。開発時は modifier を自作するしかないと判断して LLM を使っていたためプロンプトの指示が具体的になりすぎていたのが良くなかったようです。LLM の使い方の改善余地もあるという学びを得ました。 受け入れテスト時のチェック項目の追加 こちらのコミット にあるように、受け入れテスト時は、そのテストシナリオによって「リソースの作成」を期待するのか、「リソースの更新」を期待するのかまで記述できることを知りました。これにより、意図しないリソースの再作成が発生した場合に気づける、といった効果が期待できそうです。 AWS リソース作成にかかったコスト 今回は受け入れテストも自分で実行し、かつ個別に動作検証も行ったため、AWS リソースの作成による金銭的コストが発生しました。Terraform で IaC 化して、使わないときはこまめに destroy していましたが、合計で約 50$ ほどかかりました。大半は Redshift のコストであり、ここは実装しようとするリソース次第で大きく変わってきそうです。 その他の所感 学び：標準化のために膨大なエネルギーが注がれている Terraform 関連のような、数千人規模のコントリビューターが関わっているリポジトリでは、「誰が走っても同じゴールにたどり着くためのレール」の整備が欠かせません。標準化が甘いと、メンテナー（レビュワー）の負担が大きくなり、機能のリリーススピードが落ちてしまいます。そのような背景から、以下のような様々な情報やツールの提供によってコードの標準化を強く推進する意思を感じました。 豊富なドキュメントの提供 貢献種別（バグ修正、新規リソース追加など）ごとの詳細な手順の整理 命名規則などのルールの記載 専用ツール「skaff」による scaffolding 「これを修正していけばOK」なベースとなるコードを自動生成 ローカルで実行可能な CI テスト lint / format / test など、様々な観点で徹底的にチェック可能 ローカルでパスしておけば、PR 時の CI も全てパスする可能性が高く、メンテナーの負担が下がる 特に、CI テストと同等なものをローカルで実行できるようにするためにエネルギーを注いでいるのは、下記の通り ドキュメント からも伝わってきます。 NOTE: We've made a great effort to ensure that tests running on GitHub have a close-as-possible equivalent in the Makefile. 和訳 注: GitHub で実行されるテストについては、Makefile に可能な限り同等のコードが含まれるよう最大限の努力を払っています。 これにより、例えば const で定義している定数 については、以下のように値をハードコーディングしていると定数を使うように促されるなど、細かい点までコード内の記述の揺らぎが最小化される力が働きます。 このように、テスト項目は非常に細かく多岐に渡りますが、逆にいうと、受け入れテストとローカルでの CI テストをパスした状態であれば、初めての PR であっても自信を持って作成できました。 私が所属する DBRE チームでは、 DevOps のスペシャリスト により上記のような scaffolding から format, lint, test までの開発フローを一通り整理してくれていたため、今回の開発の流れにも違和感なく取り組むことができ感謝しています。 反省点：生成 AI の活用方法に改善の余地あり 初見のリポジトリに対する理解速度を上げるために、Copilot などでリポジトリをインデックス化しておけば、コード理解がより速くなったと反省しています。一方で、今回のように異なる SDK によるコードが混在するリポジトリの場合は、前提として現在推奨されている SDK を指定した上で質問するなどの工夫も必要だと感じました。実際、Plan Modifier 周辺を Deep Research で調べて Web 上の Issue に書かれていた解決策を試したものの、旧 SDK での解決方法だったため、動作しませんでした。代わりに、関連ソース一式を LLM に渡したところ、ほぼ修正不要のコードが提案されて問題を解決できました。LLM をもっとうまく活用してキャッチアップや開発速度を上げていきたいです。 苦労した点：異なる種類の SDK によるコードの混在 前述の通り、異なる種類の SDK によるコードが混在しているため、「既存コードが全て参考になるわけではない」という状況で、これに気づくのに少し時間がかかりました。例えば、sweeper 関数の実装では、現在の SDK（Terraform plugin framework） と 以前の SDK とで実装方法が異なります。今回の実装対象サービスは redshift ですが、 redshift の sweeper 関数を実装するファイル ではまだ現在の SDK での実装が行われておらず、旧 SDK での実装を参考にしてコードを書いたけど動かない、といった問題に遭遇しました。現在の SDK で実装されている関数を別サービスから探して参照することで解決しましたが、参考にする既存コードが現在の推奨 SDK による記法かどうかは気をつけると良さそうです。 手順別の AI と人力の使いわけ 最後に、各手順を AI と人力どちらで行った方がいいのか、主観ですが現時点での見解を表にまとめます。今回の開発完了後に、検証目的で同じタスクを AI エンジニアの Devin にも実施させてみましたが、公式ドキュメントにも書いてある通り、細かくタスクを分解して渡す必要がありそうでした。もちろん、現時点での見解なので、AI の進化によって変化していくと思われます。 手順 AI / 人力 備考 1. 関連 issue の調査または作成 人力 Web検索または GitHub Issues ページを自分で調べるのが最速 2. 対応する AWS API と SDK の事前調査 人力 自分で検索するのが早い 3. 開発環境を準備 人力 自分でセットアップした方が早い 4. 対象リソースの動作検証・依存リソースのコード化 AI＋人力 依存リソースのコード化は LLM 活用が有効 5. scaffoldingツールでベースとなるコードを生成 人力 自分で実行した方が早い 6. コード修正と動作確認 AI＋人力 ベースを LLM に書かせ、細部は自分で仕上げる 7. テストを書く AI＋人力 ベースを LLM に書かせ、細部は自分で仕上げる 8. CI用テストのローカル実行 AI or 人力 AI に任せると自動でパスするようにコードを修正してくれるかもしれないが、テスト実行時間が長いので製品によってはクレジット消費が大きくなる懸念 9. ドキュメント修正 AI＋人力 マージ済みドキュメントを参考として渡して LLM に下書きを作らせると良さそう 10. プルリクエストを作成 人力 自分で行うのが早そう 11. 変更ログを作成して push 人力 自分で行うのが早そう まとめ Terraform Provider へのコントリビューションは敷居が高く感じていましたが、ガイドがしっかりと整備されており、scaffolding ツールやテストフレームワークが充実しているので、慣れればスムーズに進められると感じました。初回だったのでドキュメントの読み込みに時間がかかりましたが、次回からはより高速に開発を進められると思います。AWS の新機能リリースをいち早く Terraform 化したいという方は、ぜひ取り組んでみてください。その際に、本記事が少しでも参考になれば幸いです。 KINTO テクノロジーズ DBRE チームでは一緒に働いてくれる仲間を絶賛募集中です！カジュアルな面談も歓迎ですので、 少しでも興味を持っていただけた方はお気軽に X の DM 等でご連絡ください。併せて、 弊社の採用 Twitter もよろしければフォローお願いします！

Hi, this is Kageyama, from KINTO Technologies! As is customary every year, I'd like take a moment to reflect on 2024 and share some thoughts on what’s ahead in 2025. Review of 2024 Looking back, the number of challenges we needed to address has increased compared to a year ago. In response, our team grew, and the organization expanded. At the same time, even with that growth, I believe believe we’ve made a conscious effort to preserve the strengths of being an in-house development team. One of the major milestones this year was the full-scale launch of the Dealership DX Project, supporting the digital transformation of Toyota dealerships across Japan. We’ve already rolled out tools aimed at reducing the workload for dealerships for creating estimates, as well as customer management apps. In addition, AI-driven product development has been progressing steadily. As AI adoption and cloud usage advance, the scope of security and governance are also expanding. To that end, we have established a dedicated cloud security unit and began reinforcing security around AI-related projects. Internally, we have also moved steadily incorporating AI. The AI integration with Slack, our primary communication platform, is steadily becoming the norm across the company. There have also been cases where even non-engineering employees have used generative AI to develop an application. We have also started offering generative AI training sessions for our group companies and dealerships. Progress of Key Initiatives In last year's Advent Calendar , I wrote about three key priorities we aimed to improve: Technical proficiency Development productivity Release speed First, on technical proficiency, we have expanded our technichal support for Toyota Motor Corporation and its group companies. We also developed use cases that have been well received by various IT vendors. One highlight has been our Tech Blog which attracted an impressive 120,000 unique users this year. As more people started contributing to it, we have received valuable feedback from both inside and outside the company. Next, in terms of development productivity, we've been using Findy Team+ to quantitatively measure team performance, which has led to initiatives aimed at improving the efficiency of individual processes. The company has also introduced systems that integrate generative AI, such as GitHub Copilot, which has increased employees' awareness around development productivity, sparking new initiatives including efforts to increase overall throughput across the entire development lifecycle, from business planning to release. An finally, regarding of release speed, our main focus has been on streamlining the early stages of development, particularly the process until the requirements definition phase. By having the development teams lead the requirements definition process as well, we’re beginning to steer the business side toward a product development approach that is more feasible and demands less development effort. We are still in the trial-and-error stage, but I would like to further spread this awareness of speed throughout the company. Outlook for 2025 So, what will we focus on next year? I plan to center our efforts around two major "firsts": AI First Release First (Fastest Release) AI First AI first means exactly what it says, and we will be strengthening AI initiatives through: Seamless integration of AI across all products Development of more AI-driven products Leading AI adoption at dealerships and throughout the Toyota Group. Thanks to the efforts of all our employees so far, we are in a strong position to accelerate these efforts in 2025. I am optimistic that we will be able to generate significant output next year. Moving forward, I believe it's important to adopt a mindset of actively incorporating AI in product development; even for products that don't necessarily require AI. I look forward to seeing new ideas and cross-functional collaborations that will help bring our AI-first approach to life. Release First Release First (Fastest Release) is about using our expertise and technology to deliver products as quickly as possible. What it takes to achieve the fastest release can vary depending on the business owner and the nature of the product. This year, our focus was on enhancing productivity in both the requirements definition phase and the implementation process for specific projects and teams. Next year, instead of solely focusing on improving the productivity of specific stages, I’d like each product team to collaborate closely with stakeholders and consider how and where they can shorten the entire release cycle to achieve the fastest possible product releases. I also believe we need to fully embrace the concept of MVP (Minimum Value Product). That doesn’t mean every product will follow the same development or delivery model. Our strength as an in-house development team lies in our ability to thoughtfully assess product value while still aiming for the shortest possible release timelines. This balance is one of our greatest contributions to the business, and we will push even further in this direction next year. User First and Organizational Intensity To support AI First and Release First , we will be reemphasizing two foundational themes in 2025: User First and Organizational Intensity . User First means going beyond serving end users of our services: we also need to proactively engage with our business partners and the customers they serve. By identifying what truly matters to users and customers, we can elevate the value and impact of our work. That is why I see methodologies like user research as essential skills to develop. Intensity is insipired by a Soccer Term . One of KINTO Technologies' key strengths is our team of highly skilled individuals. But to achieve even greater outcomes as an in-house development team, we need to further raise the collective capabilities of our teams and organization. I encourage everyone to reflect on the mindset and actions needed to help KTC become a truly high-intensity organization. Full Throttle While we didn’t explicitly include technical expertise and communication skills in our 2025 themes, these have become deeply embedded in our culture and are now expected. They remain timeless pillars at KTC, and I hope each of us will continue to nurture them and strengthen them. We will continue to give our best next year as well, with no shortcuts. Hitoshi Kageyama, Executive Vice-President, KINTO Technologies

自己紹介 初めまして！ KINTOテクノロジーズのCloud InfrastructureグループでManagerをやってる辻です 2020年5月に入社している地味に古株な人です 新卒からずっとインフラ(オンプレ/クラウド両方)エンジニアしています 概要 こないだVSCodeでのGitHub Copilot Agent Mode(以降Agent)が正式リリースされましたね(2025/4/16現在) ちょうどいいのでVSCode Agentを使って何か便利なもんでも作ってみましょう 前提 私は根っからのインフラエンジニアです フロントエンドどころかバックエンドもほぼワカランです その代わりインフラは(特にAWS)はチョットデキル この記事では深いTechなことには触れません やりたいこと Agentを使ってインフラ以外できないエンジニアがどこまで行けるのか挑戦する 日々の 業務で利用できる実用的なシステムをMVP(Minimum Viable Product) で開発する 絶対にコードは自分で書かない じゃあ何を作ろうか？？ KINTOテクノロジーズのインフラは基本的にすべてIaC(Terraform)で作成/管理されています terraformを使ったことがある人ならわかると思いますが、planの内容って慣れてないと見づらいですよね？ なので今回はterraformのplanが見やすくなるナニカを作りたいと思います 作りたいもの terraform planを見やすくする どうせなら生成AI使って要約とかしたい Agentが作るんだからちょっとかっこいいフロントエンドも作ってもらう 開発環境 今回使用した開発環境は下記です　※ご参考までに 項目 使ったもの OS Linux(WSL2) IDE VSCode(1.99.3) Agent GitHub Copilot Agent 生成AIモデル Claude 3.7 Sonnet インフラ AWS やってみましょう まず最初にやることはアレですね。そうプロンプトを考えましょう 今回は超ざっくりにやりたいことを↓のプロンプトでAgentに指示しました terraform planの結果をブラウザで確認する仕組みを実装したいです AWS構成：Cloudfront+S3+Lambda + Bedrock 案 1.ローカルでterraform plan -out hoge.planを実行し、plan内容をファイルに出力 2.hoge.planをs3に送信 3.lambdaが起動し、terraform show hoge.planを実行し、人が見れる形にしてs3に出力 4.terrafrom showの結果をBedrockが解析し、planの要約を出力 5.ブラウザからアクセスを実施し、要約とplanの内容を人が見る 上記案で実施しようと考えています もっと良い案があれば提案してください。もしなければ上記を作る手伝いをしてください コードを作成する必要があるのであれば、/home/mizuki/配下にディレクトリを作成し、そこに出力してください え？もっといいプロンプトあるって？ 細かいことは置いておきましょう なぜなら私はインフラしかできないエンジニアです そしたら賢いAgent君は私のやりたいことを300%ぐらいパワーアップさせて対応してくれました お客様のご要望は、Terraform planの結果をブラウザで確認するシステムの実装についてですね。ご提案いただいた案は実現可能であり、良く練られています。まずはその案を評価し、いくつかの改善点を提案した後、実装のお手伝いをさせていただきます。 # 現在の案の評価 1. ローカルでterraform plan -out hoge.planを実行し、plan内容をファイルに出力 2. hoge.planをS3に送信 3. LambdaがS3のイベントをトリガーに起動し、terraform show hoge.planを実行して人間が読める形式でS3に出力 4. Bedrockがterraform showの結果を解析し、planの要約を生成 5. ブラウザからアクセスして要約とplanの内容を確認 # 考えられる改善点 1. **セキュリティ強化**: S3へのアクセス制限、IAM権限の適切な設定 2. **差分のビジュアル表示**: planの結果をグラフや色付きテキストで可視化 3. **履歴管理**: 過去のplan結果を保存し比較できる機能 4. **通知機能**: 重要な変更がある場合にSlackやメールで通知 5. **インタラクティブな操作**: ブラウザ上でリソースの詳細を展開/折りたたみできる機能 これらを加味した上で、実装を進めていきましょう。まずはディレクトリ構造を作成します。ディレクトリ構造を作成しました。次に、このプロジェクトの各コンポーネントを実装していきましょう。 まず、Terraformの設定ファイルを作成して、必要なAWSリソースを定義します。ディレクトリ構造の作成が完了しました。これから各コンポーネントを実装していきましょう。 まずはTerraformのインフラストラクチャを定義する`main.tf`を作成します。このファイルにはS3バケット、CloudFront、Lambda、IAMロールなどの必要なリソースを定義します。 : : 略 。。。。君すごいね Agentの目玉機能であるローカルへの操作もどんどんやってくれます これは作業ディレクトリ作って、そこにterraformファイルなどを作成してくれている その後は作業内容を説明してくれながら、これやっていい??って随時確認してくれます 私はPythonのことなんてナンモワカランのでとりあえず全部「accept」ボタンを連打します 最終的にJavaScriptやCSS及びPythonやTerraformファイルだけじゃなく、Lambdaのビルド用シェルまで作ってくれました しかもご丁寧に使い方やデプロイ手順や改良案も添えて デプロイしてみましょう 作ってくれたのはありがたい けどほんとに動くの？？？ とりあえず教えてくれたデプロイ手順を愚直にやってみます terraform applyしてAWSにS3とかCloudfrontとか作って ビルドしてLambda用のzip作って Lambdaをデプロイして JSとかCSSをS3に配置して なんのエラーも出ずにデプロイ完了しました 流石にエラーでました 作ってくれた環境にアクセスしたら、流石にLambdaのエラーが出ました 私はPythonの事わからないのでエラー解析なんてできません なので、LambdaのログをそのままAgentに渡して調べて貰いましょう すると予想通りログを解析して問題点の指摘及び修正までやってくれました 修正されたファイルをもう一度デプロイしたら今度はうまくいきました どんなシステムになったのか？ 出来上がったシステム構成ははこんな感じです！！ 流れとしては下記となっており ユーザーがterraform plan結果をS3に送信 イベント駆動でLambdaが起動 LambdaがBedrockへplan結果の解析/要約を依頼 生成されたplan結果の要約と要約ページのHTMLファイルをS3へ配置 Step FunctionsがCloudFrontのキャッシュを削除 ユーザーはS3へplan結果を配置するだけで全て完了します 実際にアクセスしてみましょう めっちゃかっこいいですね じゃあそもそもの目的であったplan結果の要約はできてるのでしょうか？ 完璧ですね。。。。 ちょっとインデントがおかしい気もしますが、細かいことは気にするのやめましょう 良いポイントとしては 作成/更新/削除などの件数が画面上部に表示され見やすい 変更されるリソースの変更内容が説明されている リスク評価が記載されており、このplanでのリスクが把握できる 注意点として今後改善したほうが良い内容を教えてくれる まさに求めていた内容です 細かい要件追加 その後も細かい修正をAgentに指示してやってもらいました 時間がUTCになってるからJSTにして インデントがずれてるから直して スクショを添えて planが生成されたらCloudFrontのキャッシュをクリアして などなど 上記の細かい要件追加も 簡単 にやってくれました やってみた感想 想像以上に簡単にシステムが作れました 1日でこのシステムを作成しましたが、ほとんどの時間がAgentの処理待ちだったので、実作業時間は1時間程度です。私のようにインフラしかできない人間でも、フロントエンド～バックエンドまで1人で構築できました。 ただしPythonコードを見ると素人目でも不要なコードが存在したりしています まだまだ改善の余地がありますが、これはMVP（Minimum Viable Product）段階での開発としては十分な成果です。今後、必要に応じてコードの最適化や機能の拡張を行っていくことができます。 重要なのは、短時間で機能するシステムを作り上げられたことです。これにより、アイデアを素早く形にし、実際の運用を通じて改善点を見出すことができます。 大事なのは 1人で短時間で簡単に作れた ってことです MVP(Minimum Viable Product)でのファーストステップとしてAgentは最適解だと思います まとめ Agentだけ使ってエンタープライズなシステムを作るにはまだまだ時間がかかりそうですが、プロンプト初心者の私でも簡単にシステム開発できました 何より驚いたのが「accept」ボタンを押すだけでAgentがサクサクとシステムを構築してくれる点ですね 今までは生成AIに提案された内容をコピペしたりコマンドを自分で実行したりしてましたが、今回はほぼ自分でコマンドを打っていません。「accept」ボタン押しまくっただけです ボタン押しただけでみんなの工数削減&ミス防止を可能になるシステムが作れたってことです また、今回作ったシステムは実際に利用しており、運用フローに組み込む予定です さいごに 私の所属するCloud Infrastructureグループでは一緒に働いてくれる仲間を募集しています。クラウドに自信のある方もこれからクラウドを学びたいと思っている若手の方も大歓迎です。お気軽にお問い合わせください 詳しくは、 こちら と こちら をご確認ください また、グループの紹介記事もWantedlyにて掲載されています！ こちら で見ることができるので、ぜひCloud Infrastructureグループについて知ってください！

My name is Ryomm and I am developing the app my route (iOS) at KINTO Technologies. The my route app's library management tool has finally migrated from CocoaPods to Swift Package Manager (SPM)! Introduction The my route app used to use CocoaPods. However, around summer 2024, CocoaPods issued the following announcement. https://blog.cocoapods.org/CocoaPods-Support-Plans/ That was an announcement stating that CocoaPods would be transitioning to maintenance mode. It doesn't mean it will become unusable, and they will still support security issues and other concerns. However, support for GitHub issues and the addition of new features will no longer be provided. If you do this, you may find yourself in a situation where you want to add a new library only to find that CocoaPods is no longer supported, or that you are unable to fix a problem with CocoaPods itself. There had been talk of migrating to SPM at my route for some time, but the announcement of CocoaPods gave us the impetus to finally embark on the migration to SPM. What is Swift Package Manager? SPM is a genuine library management tool provided by Apple. https://github.com/swiftlang/swift-package-manager Speaking of library management tools for iOS, there are other third-party tools such as CocoaPods and Mint. The biggest difference between these and SPM is that SPM is directly integrated into Xcode. This means that by simply updating Package.resolved when necessary, the latest specified version of the library will be imported when you open or build a project. This means that I no longer need to tell my team to run pod install every time I update the version. Migration Complete! It’s simply a matter of transferring everything, but there were a few stumbling points and tips that I encountered, so I’d like to share them with you. The Specified Version of the Library Is Not Downloaded I had a problem where, when switching to the desired version, even after executing "Reset Package Caches" or "Update to Latest Package Versions" in Xcode, the version specified in Package.swift would not be downloaded. Even deleting DerivedData doesn't fix this. This is because residual caches remain in locations such as ~/Library/Caches/org.swift.swiftpm and ~/Library/org.swift.swiftpm . When I delete these, the correct version of the library is downloaded. Build Doesn't Pass Only During Testing My route has multiple schemas, each of which depends on slightly different libraries. So, it has a structure separated from the project's own Package.swift as shown below. We create a Dependencies package in the same workspace as the project file and manage the library within this package so that it becomes a one-to-one product (framework) with each schema. These products are linked to each target's Frameworks, Libraries, and Embedded Content as shown in the screenshot on the right. However, with this configuration, I encountered a problem where xcodebuild build passed, but xcodebuild build-for-testing did not. This command corresponds to Run and Test in the Xcode GUI. Typically, items in a package are tested within that same package. However, with the above configuration, tests are run on the project’s main target instead. This means that the tests are executed outside the package. So yes... this is technically an improper setup... which I do plan to fix, but for now the tests are included in the same package, which allows us to proceed with testing preserving the current configuration. It seems that the cause was the different behavior around the linker between Run and Test. The build product for Run is assumed to be 1), and the build product for Test is assumed to be 2). 1) includes SPM in Dependencies, but 2) does not. Therefore, if a test in the MainTarget depends on a library in Dependencies, the build will fail. A simple solution is to move the libraries required for testing to the SPM in MainTarget, which will be included in the build for both Run and Test. To fundamentally solve the problem, it is a good idea to simplify the tests in one package, as mentioned above. Putting SwiftLint and LicensePlist on SPM Since I want to include SwiftLint and LicensePlist in the project's Build Phase so that they are executed during the build, I create a separate package in a location independent of the workspace. Project/ ├── Test.xcworkspace ├── Test.xcodeproj ├── Test/ │ └── ... ├── ... └── tools // <- this! ├── Package.swift └── Package.resolved I placed the libraries I wanted to include in the Build Phase, such as SwiftLint and LicensePlist, into the newly created "tools" package. Then, I created a shell script, which I executed only the first time to download the libraries locally. SPM_PACKAGE_PATH=tools SPM_BUILD_PATH=tools/.build/release echo "swiftlint" && $SPM_BUILD_PATH/swiftlint --version || swift run -c release --package-path $SPM_PACKAGE_PATH swiftlint --version echo "license-plist" && $SPM_BUILD_PATH/license-plist --version || swift run -c release --package-path $SPM_PACKAGE_PATH license-plist --version Then, it becomes executable at tools/.build/release/swiftlint , so I add this to the Build Phase. The same applies to LicensePlist. Even when executing from platforms like Bitrise, it can be confirmed that LicensePlist is executed by executing the shell first, followed by building the project. Conclusion It's been a few months since the migration, and while there are still some issues, I feel that replacing libraries has become easier. When I want to check whether an issue is caused by a library, I personally find it convenient to quickly check it using the app-version of Praygrounds for a quick test. Now that SPM is integrated into the project, it has also become possible to use Apple libraries that are only available via SPM. In the future, I would like to use these libraries to improve our implementation.

Hello(=ﾟωﾟ)ﾉ I'm Hikaru Takeno @t_hikarutaaaan , from the Talent Acquisition team at KINTO Technologies! I've been at KTC for almost three years, but as an HR professional, I'm still a newbie in my first year. In this article, I’d like to share what I applied and learned as a first-time Event PM , as an HR newbie! Event Overview Event name: Product History Conference Organizer: YOUTRUST Inc. Date: 10:00 a.m. to 8:00 p.m., Saturday, November 30, 2024 Location: TODA HALL & CONFERENCE TOKYO @ card The Beginning With less than three months to go until the event, it has been decided that KTC will join as a gold co-sponsor of the event! When I heard, "Alright, the approval's in!!" I was relieved... But at the same time I thought, "Wait, where do we even start...?" That was when a miraculous helping hand reached out to me °˖✧◝(⁰▿⁰)◜✧˖° Kin-chan , the manager of the Developer Relations Group, shared the Slack channel from another event and advised us, saying, "This is how you should approach it!" ( ;∀;) For someone like me who learns best through hands-on experience, it was the most easy-to-understand information. I'm truly grateful. Next Steps: "Alright, let's take a look at the Slack channel." … (ㆆωㆆ)ｰ "Hmm, not very sure but let's get everyone involved together and have a meeting first!!!" We set up a meeting . Then, we rummaged through the internal Confluence. We found meeting minutes that seemed usable. Copy!!  We copied past materials! Somehow, by rummaging through the internal Confluence and the past event-related Slack channels , we were able to resolve most of the issues! Looking back, I’m really impressed and grateful for our environment where knowledge sharing comes so naturally… It was a lifesaver… On the Day of the Event Since we had finished setting up the booth the day before, we arrived at the venue at 09:30 a.m. .  The booth with simple setup completed After settling down a bit, the time of opening the venue was approaching... and then... Someone said, " Let's form a circle among all the members of the sponsoring companies!! " Σ(･ω･ﾉ)ﾉ! So, I firmly put my arms around the shoulders of the people on both sides of me. Then the event started!　As people gradually started to arrive, there was a crowd at the booth by lunchtime!  Many visitors showed interest! We were talking nonstop the whole time!! We conducted a questionnaire at the booth, and I was really happy to see that there were more people who knew about KTC than we expected. The most common response: "I've seen you at lots of events!!" I was reminded once again of the collective effort of all the employees who have steadily participated in many of them!!  KTC's mascot, Kumobii, is also doing its best Kageyama-san takes the Stage This time, we held a cross-talk session featuring our Executive Vice President Hitoshi Kageyama and Mr. Naomichi Okada, CTO of Luup Inc. ! With the theme "Creating a New Standard of Mobility through the Use of Technology: The Future as Imagined by the Two Companies,” they spoke candidly about the challenges both companies are facing, including: The thoughts behind the founding and establishment of each company The evolution of their development organizations across various phases The challenges and excitement of working on product development amid numerous constraints And more.  Crosstalk What I’ve Learned It is best to set agendas and choose appropriate timings for operation meetings. Perhaps it would be a good idea to try a fixed weekly meeting style? Kumobii's unstoppable popularity Cuteness proved to be unbeatable as expected! Kumobii is the official mascot of KINTO Corporation. https://corp.kinto-jp.com/mascot/ An environment where knowledge naturally accumulates is a huge strength. . Thanks to our open Slack channel culture, it's easy to find and learn from past events. So many incredibly experienced employees in our company Hosting a post-event party was absolutely worth it! . It helped keep the connections going beyond the event itself. About 25 to 30 people joined.  People from other companies also joined the post-event party. Thank you to the participants from X Mile Inc. @xmile_product , Asuene Inc. @asuene_inc_ , and note inc. @note_corp !! What I Want to Carry into the Next Event We should think more about what kind of experience we want people to have when they visit our booth. I want to apply our experience to booth setting and the arrangement of novelties. I want to prepare “express cards” that allow people we’ve directly spoken to skip the selection process . Since this was also an event hosted by YOUTRUST Inc., a career-focused social media, many participants were interested in changing jobs. It might have been a good idea to create a process to ensure talented individuals remain in the selection process without fail. I want to set KPIs. Looking Back Being a bit nervous, started off my role as the event PM thinking, "I have no idea what’s going to happen...!" with my heart racing. But in the end, it was like, "We made it!!" and the event finished without any major problems. This was all thanks to the operations team, who not only helped me prepare in advance by guiding me with questions like, "Shouldn’t we decide on this?" and "What’s the status of this?" but also stayed flexible and supportive on the event day itself! Really, thank you so much!!!  Everyone wearing Kumobii!

This article is the entry for Day 23 in the Developer Relations Group Advent Calendar 2024 🎅🎄 Introduction Hello! I am Rina ( @chimrindayo ). I am an engineer at KINTO Technologies, where I am involved in the development and operation of Mobility Market and on the Developer Relations Group as well. KINTO Technologies launched the Tech Blog in July 2022, and thanks to our writers and readers, we have been able to keep it running to this day. Thank you for reading as always! Our Advent Calendar is one of the biggest events on our blog each year, and this time was no exception 🎄 We proudly reached a total of 100 articles up to Series 4 👏 Amazing! Until we were able to release 100 articles, the Developer Relations Group members worked hard every day, coming up with various new ideas. This time, I would like to introduce some of the journey and initiatives we went through to release 100 Advent Calendar articles. Journey of the KINTO Technologies Advent Calendars The KINTO Technologies Advent Calendars were started by volunteers in 2021, prior to the launch of the Tech Blog. The following year, in April 2022, a small team called the Tech Blog Project (now Developer Relations Group) was formed, and the team launched the Tech Blog in July 2022. Since the launch of the Tech Blog, we have consistently posted an Advent Calendar every year, increasing the number of articles by 25 each year ⤴️ Year URL Number of posts 2021 KINTO Technologies - Toyota car subscription service "KINTO" under development! Advent Calendar 2021 24 2022 April: Tech Blog Operation Team was established July: Tech Blog launched🎉 - 2022 KINTO Technologies Advent Calendar 2022 KINTO Technologies Group Introduction Advent Calendar 2022 50 2023 KINTO Technologies Advent Calendar 2023 75 2024 KINTO Technologies Advent Calendar 2024 100 I will reflect on each year to review the steps we took to increase the number of articles. Since we adapted our approach to fit each stage, from the initial launch to the ongoing operation of the Tech Blog, I hope this article will be helpful for anyone thinking about starting a tech blog or are currently running one but facing challenges to increase the number of contrbutors🙌 2022 Advent Calendar Initiatives First, here are some of the initiatives we implemented during the early stage of the Tech Blog. Looking back, I think a defining feature of this initial phase was that we approached individuals to ask them to write for the Tech Blog. Let me introduce some of the specifics. Making it a Rule to Show Gratitude to Writers The first thing we did was to establish the rule of showing "gratitude toward writers" as the stance of reviewers. This rule was decided by project team led by Nakanishi-san . We have also continued to convey gratitude to writers by requesting managers and leaders, who could serve as reviewers, to do so in company-wide meetings or 1-on-1 sessions, and by expressing our gratitude in the PR (pull request) template for the Tech Blog. Excerpt from the PR template for the Tech Blog Even now, expressing gratitude to writers for their contributions is something that the entire Developer Relations Group values very much. Having All the Managers Write Articles The next step we took was to have all the managers write articles. In the early days of the Tech Blog, many people in the company thought, "What is a tech blog? Why are we doing this?" So our first priority was to make sure each group leader understood the value and purpose of the Tech Blog. We also believed that getting General Managers to contribute articles was key to spreading awareness across the company. After a 30-minute meeting with them, we successfully launched the "KINTO Technologies Group Introduction" series. https://qiita.com/advent-calendar/2022/kinto-technologies-introduction Under the theme letting everyone get to know our people and offices , managers and leaders wrote articles for our Advent Calendar. On Christmas Day, Vice President Kageyama closed out the series with an special post titled "2022 Year in Review & 2023 Outlook”🎅. Since then, his article has become an annual tradition, one that's read by nearly all current and prospective employees. His articles condense key aspects about KINTO Technologies, including: What kind of organization we are What we achieved over the past year What we aim to pursue in the year ahead They serve as a compass for the organization. It’s a once-a-year piece Written with care and dedication. Click here 👇 for his review & outlook article: https://blog.kinto-technologies.com/posts/2022-12-25-LookBack2022/ Studying the Structure of Each Article Together We hold 30-minute sessions to help those who are eager to write but lack experience with technical articles and need guidance on where to begin. During these sessions, members of the Developer Relations Group conduct interviews with the writers, asking about: Projects they've worked on Successes, failures, and the lessons learned along the way Their tech stack and tools of choice As we listen, the Developer Relations team helps the writer shape the article structure in real time, laying a solid foundation they can build on. the Developer Relations team shares the proposed article structure with the writer on the spot for feedback. Most writers respond with surprise, saying things like, “This might be easier than I thought!” When we launched the Tech Blog in 2022, we carried out this process with every single writer. Looking back, it might seem like a bit of a brute-force approach; but we believe that this hands-on, all-in communication style is one of our team’s greatest strengths. When we’ve shared this method with technical PR teams at other companies, it’s often met with praise, with many calling it a “wonderful initiative.” There were several reasons behind this approach. The main goals were to: Help every writer understand the value of the Tech Blog Lower the barrier to contributing Gain visibility into who is responsible for what Build trusting relationships, where writers feel comfortable asking us for advice And more. However, what we consider most important is that each writer reaffirms the value of their own work . In face-to-face interviews with them, many would say, "I can write, but my daily work is just ordinary, so it's not something worth putting on a blog." But that’s exactly the kind of story we want to share. It’s perfectly okay to be ordinary! There’s always someone out there facing the same challenges, and if your story reaches even one of them, then it’s absolutely worth sharing on the Tech Blog. That’s why we kept encouraging each writer: “Let’s write it together!” This way of thinking is still valued by the Developer Relations Group, and it was featured in a blog post that was released the other day.👇 https://blog.kinto-technologies.com/posts/2024-12-11-gekishin/ In this way, not only do we work together on the structure of each article, but we also believe it is important to help each writer feel confident about the content they are about to write. 2023 Advent Calendar Initiative In the early stages of the Tech Blog's launch, we focused on encouraging first-time writers through one-on-one conversations. Next, in 2023, we shifted our focus on sustanining that momentum supporting continued contributions and increase the number of writers. Supporting Inputs One of the initiatives the Developer Relations Group undertook first in 2023 was supporting the introduction of Udemy Business . We believe meaningful output on the Tech Blog starts with strong input, the knowledge and skills the writers bring. To reinforce this mindset, we linked access to Udemy Business with participation in the Tech Blog: registering for an account required contributing at least one article. There are actually team members who have taken Udemy courses and are currently writing articles.👇 https://blog.kinto-technologies.com/posts/2024-08-30-udemy-kotlin-coroutines-and-flow/ In 2024, in addition to the support for the introduction of Udemy, we established a new team within the Developer Relations Group called the "Learning Roadside Station". This team was created to offer comprehensive support for both input and output. Read more about the background of the Learning Roadside Station Team's establishment here.👇 https://blog.kinto-technologies.com/posts/2024-04-23_%E5%AD%A6%E3%81%B3%E3%81%AE%E9%81%93%E3%81%AE%E9%A7%85%E3%81%AF%E3%81%98%E3%82%81%E3%81%BE%E3%81%97%E3%81%9F/ Encouraging Newcomers to Write an Article In October 2023, we launched a new initiative asking all new employees to write a blog entry after joining the company. The goals of this initiative are to: Give readers a feel for our company’s atmosphere Reduce the hesitation around writing for the Tech Blog Encourage connections among new hires By having everyone contribute from the start, we aim to lower the barrier to writing and helping newcomers understand how to approach blog writing, ultimately making it a natural practice. https://blog.kinto-technologies.com/posts/2024-01-01-newcomers-introduction/ Initially, the Developer Relations Group planned for each new hire to write their own entry. But when Ryomm-san , who joined in October, suggested, “I’d like to co-author!” it sparked the creation of a new co-writing process. This is just one example of how we’re building a culture where Tech Blog initiatives aren’t just driven by the Developer Relations Group, but shaped by contributions from employees across the company. Asking Teams to Write Next, we implemented a plan where we asked teams at the project and department-level to write for the Advent Calendar. Five groups, with five members each, participated and together filled 25 days' worth of content. The themes were: New Car Subscription Website Renewal Project Agile Development KINTO FACTORY QA Diversity & Inclusion By encouraging people across teams to write together, we aimed to make the writing process more collaborative and approachable. Having teammates work on shared topics made it easier to ask for feedback and consult each other during the writing process. We also hoped that theme-based series of articles would feel more relatable to internal readers, helping to increase engagement, and ultimately, encouraging more people to read and share the Tech Blog, both internally and on social media. The actual project is introduced in the blog here.👇 https://blog.kinto-technologies.com/posts/2023-11-20-advent-calendar/#2.-%E8%A8%98%E4%BA%8B%E3%83%AA%E3%83%AC%E3%83%BC 2024 Advent Calendar Initiative Finally, let us share what we’ve been working on this year. In 2024, our focus has been on expanding the Tech Blog and improving its quality . Holding a Tech Blog Study Session In August 2024, we held an internal study session led by p2sk-san , a member of the Developer Relations Group. The session, titled "Reviewing the Tech Blog and Best Practices for Enhancing Dissemination Power," involved a comprehensive review of all Tech Blog articles published by KINTO Technologies. He shared insights into what we’re doing well, along with suggestions for improvement. The response from participants was overwhelmingly positive: "My motivation increased!" "Made me want to try writing articles!" "Let's do our best for the Advent Calendar!" The session was and full of valuable insights, but we’ll leave the deep dive for another time. Open Call for Planning & Operations In previous years, the Advent Calendar was planned and led by the Developer Relations Group, but this year, we have recruited volunteers to take part. The goal was to engage members beyond the usual circle and reach new voices we hadn’t connected with before.  While we were hoping for up to five volunteers, only one person raised their hand; but that one person made a big difference. naka_shima san stepped forward and thanks to his involvement, we were able to launch a department-based article series you’ll read about later 👏 Filling the Series by Division In 2024, we structured the Advent Calendar series around articles written by Groups (org. structure). A "series" refers to posting a total of 25 articles one for each day from December 1st to 25th The groups involved were the Mobile App Development Group, where our volunteer coordinator naka_shima-san belongs, and the Developer Relations Group. Mobile App Development Group Developer Relations Group The Mobile App Development Group was chosen first because it was the most actively engaged in information dissemination this year. This group stood out for not only planning and managing major sponsored events like iOSDC 2024 and DroidKaigi but also for regularly contributing to the Tech Blog. With a playful challenge of “Can the Mobile Group fill all 25 days by themselves?” they impressively took on the task and completed an entire series 🎉 Next, the reason why it was decided that the Developer Relations Group would fill one series was that we believed it was important for the very team leading information dissemination to actively demonstrate its output through the Tech Blog. Thanks to these efforts, we released a total of 100 articles, which included: Random topics freely contributed by volunteers Articles by the Mobile App Development Group Articles by the Developer Relations Group Translated articles (English-Japanese) by the Localization Team Future Prospects Today I shared our journey through the Advent Calendars over the past three years: from the Tech Blog’s launch in 2022 up to the present in 2024. Thanks to everyone involved and all the efforts made, we proudly reached the milestone of releasing 100 articles in the 2024 Advent Calendar! Looking ahead to 2025, we plan to focus on initiatives that make writing easier and keep motivation high for our contributors. Thank you for reading and supporting us throughout 2024☺️

Hello ( º∀º )/ My name is Yukachi from the Event Team on the Developers Relations Group. In 2024, we began sponsoring conferences and ramped up our external communication efforts, leading to a big increase in events both inside and outside the company compared to previous years! As we started hosting more events with external guests I realized it's a bit tricky to explain how to get to our office. I thought, ¨Maybe I should use more photos to explain...¨ and then I thought, wait, we have the Tech Blog! That's how this article came to be. About the Office Our company has four locations! Now that I think about it, I actually wrote a post introducing them two years ago! @ card Out of all our locations, we host most of our events at TOKYO JCT in the Muromachi office . It's on the 16th floor of the office building in COREDO Muromachi 2 ** Address: Muromachi Furukawa Mitsui Building (COREDO Muromachi 2), 2-3-1, Nihonbashi Muromachi, Chuo-ku, Tokyo 103-0022 Directly connected to Mitsukoshimae Station on the Tokyo Metro Ginza Line *About a 2-minute walk from the ticket gate. Directly connected to Mitsukoshimae Station on the Tokyo Metro Hanzomon Line *About a 5-minute walk from the ticket gate. Directly connected to Shin-Nihombashi Station on the JR Sobu Rapid Line *About a 5-minute walk from the ticket gate. About a 10-minute walk from Kanda Station on the JR Chuo Line, Keihin Tohoku Line, and Yamanote Line. Let me walk you through how to get here from each station with photos! Shortcut to the Access Guide From Mitsukoshimae Station (Tokyo Metro Ginza Line) From Mitsukoshimae Station (Tokyo Metro Hanzomon Line) From Shin-Nihombashi Station (JR Sobu Rapid Line) From Kanda Station (JR Chuo Line, Keihin-Tohoku Line, Yamanote Line) Mitsukoshimae Station (Tokyo Metro Ginza Line) Let's start with the closest stop, which is the Mituskoshimae Station on the Ginza Line!  Exit from the Mitsukoshi Ticket Gate and turn left.  There is Coredo Muromachi 1, so go through it.  Once you pass through, you'll find the entrance to COREDO Muromachi 2.  Go inside, take the escalator up.  The office area will be right in front of you! :::message During event reception time, our staff will be stationed at the entrance to the office area! Since an access card is required to get in from COREDO Muromachi 2, we'll be keeping an eye out and opening the door for anyone who looks like they're here for the event! ::: For appointments or non-event visits before 6:00 p.m., please use the main office entrance, located just to the left after exiting the building.  Step out to Edozakura-street from here.  This is the main entrance. Please check in at the front desk inside the entrance, then go to the floor your host has indicated. :::message If you arrive after event reception hours, please use the same main entrance and contact the person listed in the event details, either via phone or through our official X account. An event staff member will come to meet you on the first floor. @ card ::: Mitsukoshimae Station (Tokyo Metro Hanzomon Line) It's also directly connected from Mitsukoshimae Station on the Hanzomon Line, but it's a bit of a walk...  Exit from the Nihombashi Gate and go straight to the right.  There is a small staircase, go down and take a slight right.  Go straight and turn left at the end.  Here it is — COREDO Muromachi 2!  Go inside, take the escalator up.  The office area will be right in front of you! :::message During event reception time, our staff will be stationed at the entrance to the office area! Since an access card is required to get in from COREDO Muromachi 2, we'll be keeping an eye out and opening the door for anyone who looks like they're here for the event! ::: For appointments or non-event visits before 6:00 p.m., please use the main office entrance, located just to the left after exiting the building.  Step out to Edozakura-street from here.  This is the main entrance. Please check in at the front desk just inside the entrance, then head to the floor your host has indicated. :::message If you arrive after event reception hours, please use the same main entrance and contact the person listed in the event details, either via phone or through our official X account. A staff member will come to meet you on the first floor. @ card ::: Shin-Nihombashi Station (JR Sobu Rapid Line) It's also directly connected from Shin-Nihombashi Station, but it's a bit of a walk...  After exiting the ticket gate, turn left and go straight towards Mitsukoshimae Station (Shin-Nihombashi Station only has one ticket gate!) *  Turn left towards Mitsukoshimae Station.  Continue straight with the Ginza Line on your right.  You'll see COREDO Muromachi 1 on your left, go inside and walk through it.  Once you pass through, you'll find the entrance to COREDO Muromachi 2.  Go inside, take the escalator up.  The office area will be right in front of you! :::message During event reception time, our staff will be stationed at the entrance to the office area! Since an access card is required to get in from COREDO Muromachi 2, we'll be keeping an eye out and opening the door for anyone who looks like they're here for the event! ::: For appointments or non-event visits before 6:00 p.m., please use the main office entrance, located just to the left after exiting the building.  Step out to Edozakura-street from here.  This is the main entrance. Please check in at the front desk inside the entrance, then go to the floor your host has indicated. :::message If you arrive after event reception hours, please use the same main entrance and contact the person listed in the event details, either via phone or through our official X account. A staff member will come to meet you on the first floor. @ card ::: Kanda Station (JR Chuo Line, Keihin-Tohoku Line, Yamanote Line) Finally, here's how to get to the office from Kanda Station!  Exit from the South Exit (for Nihombashi) and walk along the Starbucks.  Cross the street and go straight to the left.  Cross the street and go straight to the right.  Keep going straight.  Go straight to the left in front of COREDO Muromachi 3.  You'll spot COREDO Muromachi 2, but just keep going straight past it.  You'll see the office entrance on your left. That's the one!  You'll find a staff member holding a sign waiting inside the office area entrance (During event hours). For appointments or non-event visits before 6:00 p.m., please use the main office entrance, located just to the left after exiting the building. :::message If you arrive after event reception hours, please use the same main entrance and contact the person listed in the event details, either via phone or through our official X account. A staff member will come to meet you on the first floor. @ card ::: Conclusion Hopefully, this post makes your visit to the KINTO Technologies Muromachi office a little smoother! Thank you for visiting! We look forward to seeing you again soon! (^_^)/

はじめに こんにちは、分析プロデュースグループの平田です！ アナリストとして働いている私が、毎日取り組んでいるSQL作成業務の効率化について、今回はお話しします。 この記事では、「Github Copilot Agent」と「Python」を使って、数百行に及ぶ複雑なSQLを書き上げる業務をどう効率化したのか、その試行錯誤のプロセスと結果、そして今後の改善について語ります。 【まとめ】 ✔︎ テーブル情報を事前に用意して、生成AIにSQLを作成してもらう ✔︎ 作成したSQLをPythonで自動実行・チェックする仕組みを実装 ✔︎ エラーが発生したら自動で修正してもらい、業務効率をアップ！ 背景：日々のSQL作成業務とその悩み 普段、私が直面しているのはこんな課題です… 生成AIとの煩雑なやり取り 生成AIにテーブルの情報やデータ型、日付フォーマットなどを会話の度に何度も説明する必要があり、その都度手間がかかっていました。 膨大なSQLの作成 マーケティングに使うユーザー抽出や分析用データ作成など、何百行ものSQLを書かなければならず、複雑な加工ロジックが散在している。 試行錯誤の繰り返し（ループ） 作成したSQLをコピーして実行、エラーが返るとまたエラーログを渡して修正依頼…この繰り返しがボトルネックに。 自分で修正すると、Github Copilotが作成した最新版と差分が生まれ、次の修正を依頼したときに先祖返りしてしまうことも。 試行錯誤！生成AIとPythonで自動化フローを構築 そこで、こんな流れで業務の効率化に挑戦しました。 自動化フローの全体像 前提情報の登録 各テーブルの構成、データ型、サンプルデータ、サンプルSQL、加工Tipsをそれぞれのpromptファイルにまとめます。 生成AIでSQL生成 全体フローのプロンプト（「テーブル情報をもとにSQLを生成&保存、実行チェック」）を生成AIに渡して、自動でSQLファイルを作成します。 Pythonで実行・チェック 生成されたSQLをPythonスクリプトで実行。エラーがあればエラーログをフィードバックし、自動修正を促す仕組みにしています。 具体的な取り組みポイント 以下は、私が実際に構築したディレクトリ構成とファイル例です： rules / conversation_rules.prompt.md 基本的な会話のルール。 テーブル情報をもとにSQLを生成&保存、pythonファイルを実行してSQLのが正しいかをチェックすること。また、SQL作成の決まりや会話の好みを記載。 tables / <テーブル名>.prompt.md テーブルの情報を記載。 サンプルデータを載せることでデータの特徴を判断してもらう。 ## テーブル名 users ## 説明 ユーザー情報のテーブル。user_idをキーにorderテーブルと紐付け可能 ## sample SQL ```sql select user_id as "顧客ID", name as "顧客名", address as "住所" from users ``` ## sample data | 顧客ID | 顧客名 | 住所 | | ------ | -------- | -------------------------------- | | 1 | 山田太郎 | 東京都新宿区西新宿 | | 2 | 佐藤花子 | 大阪府大阪市中央区難波 | | 3 | 鈴木次郎 | 愛知県名古屋市中区栄 | sql / 作成されたSQLをファイルで保存してもらう。 utils / query_checker.py SQL作成後このpythonファイルを実行し、SQLが正しいかをチェック。 実際のGithub Copilot Agentの回答例 実際の動きが確認できる簡単な例をお見せします。 [in] 今月何回メール配信したかをユーザー別に抽出するSQLを作成して！ [out] まずスキーマ情報を確認してから、メール配信の分析に関する SQLを作成しましょう。メール配信に関するテーブル情報を探します。 "› Searched for files matching /prompts/tables/**, 14 matches" 配信履歴に関するスキーマ情報が見つかりました！ まずはその内容を確認して、今月の配信回数を抽出するSQLを作成していきましょう。 Read メール配信履歴.prompt.md スキーマ情報を確認できました。[メール配信履歴テーブル]というテーブルに格納されているようです。 今月（2025年4月）のメール配信回数を集計するSQLを作成していきます。 このテーブルには以下の重要な列があります： • email_id： メルマガID • delivery_timestamp： 配信日時 • delivery_status： 配信ステータス それでは、今月のメール配信回数を集計するSQLを作成し、ファイルに保存しましょう。 ファイル名は メール配信集計_今月.sql です。 このSQLでは以下の処理が実行されます： ・ 2025年4月1日から4月30日までの期間に配信されたメールを対象にします。 ・ 「配信完了」ステータスのメールのみを集計します。 ・ ユーザーごとに、配信回数、成功数、失敗数、および総配信数を集計します。 ・ 最後に全体の合計も表示します。 Pythonでクエリを検証してみますか？ 検証のため、先ほど作成したSQLを実行してみましょう。 python3 query_checker.py メール配信集計_今月.sql SQL検証が完了しました！ クエリは正常に検証され、実行可能と確認されました。 テスト実行では構文エラーもなく、正しい実行計画が生成されました。 結果と今後の展望 嬉しいことに、一連のプロセスが無事稼働し、SQL作成の自動化に向けた第一歩となりました！ とはいえ、完璧ではありません。今後取り組みたい課題や工夫は…？ ● 現在の課題 レビュー作業の手間 AIが生成したSQLのレビューは、どうしても自分で作成する場合よりミスを見落としがち。 検証する仕組みや、実際にSQLを書かない人でもレビューを完遂できる手法については、いまだ試行錯誤の段階にあり、改善していきたいところです。 また、生成AIの進化によって、これらの課題が解決されることにも期待しています！ 意図通りのデータ抽出のチェック 要件定義の不備や、私の頭の中の情報がうまく言葉にできていないケースがあり、意図通りの処理かを自動判定するのは難しい。細かいニュアンスや意図の伝え方がまだまだ課題です。 ● 次へのチャレンジ 件数チェックの自動化 レビュー高度化のファーストステップとして、抽出した件数が意図通りかどうかのチェック機能を実装していきたい。 「秘伝のタレ」とも言えるデータ加工方法の蓄積 使い込むほどに見えてくる効果的なデータ加工テクニックを、プロンプトにどんどん追加していきたい。 分析の自動化への拡張 最終的には、SQLの作成から抽出データの分析まで、ある程度自動で行える体制を目指します！

Introduction I'm super_spa3 (Hirofumi Nakano), a product manager at KINTO Technologies Corporation. I had the chance to attend our very first overseas conference: the WWDC24! Although it's been a little while since the event, I'd like to share my experience and some related updates here on the Tech Blog. You might be wondering what a product manager has to do with iOS. When I first started my career, I was actually assigned to iOS development (though I had been tinkering with Android as a hobby before that). Later, I joined my second company, KINTO Technologies, as an iOS engineer, and now I’m working as a product manager. At work, I often use App Store Connect to release apps, and I’m also a member of the Apple Developer Program, continuing to develop apps on my own. One of the apps I'm currently involved in is called the KINTO Kantan Moushikomi App (KINTO Easy Application App), which allows users to seamlessly estimate costs and complete the screening process for the KINTO New Vehicle Subscription. https://kinto-jp.com/entry_app/ How I Got to Attend WWDC24 Participation in WWDC is determined by a lottery system. Around March each year, Apple sends out notification emails to members registered in the Apple Developer Program. Members can then click on the provided link to apply, and only those selected in the lottery get the chance to attend the event in person. However, I had tried applying multiple times during my previous job but was never successful. So, when I applied this time, I didn't have high expectations and just pressed the apply button. On the day of the lottery results, I opened my inbox and saw an email "Great News, Hirofumi!". As I read through the message, I realized I had actually been selected!  A clear sign of good news email It turned out that I was the only one from our Mobile App Development Group who got selected. After getting approval from President Kotera, I was set to attend the WWDC24! Eve of the Event at Apple Infinite Loop Campus On the day before the main event, I visited Apple's former headquarters, Apple Infinite Loop One Campus, to collect event merchandise and my name badge.  The entrance to Infinite Loop One is very minimalistic and stylish  My name badge during the event displayed TOYOTA FINANCIAL SERVICE CORPORATION, where our apps are published. The SWAG contents seem to change every year, and this year, it included a picnic mat. It's perfect now that travel is unrestricted post-COVID. How about some open-air coding?  WWDC24 swag bag and additional pins I got from Apple Park  The Apple Vision Pro badge is cool! Once entered the venue, I saw everyone taking photos in front of the WWDC24 logo. Since the event was held in the courtyard, I decided to strike a pose like on TBS's Another Sky.  The 3D WWDC24 board, I took a photo here afterwards!  This is my Another Sky rendition, Apple Infinite Loop Campus! (lol) With food and drinks in hand, I had the chance to interact with fellow developers working within the Apple ecosystem. Since I attended alone, I actively looked for someone to talk to. Whenever I saw an open seat I asked if I could sit next to them and started chatting about what we were developing, which led to great networking moments. Main Event at Apple Park The main event starts early in the morning. Check-in was scheduled for 7 a.m., but I heard that many people planned to arrive even earlier. So, I decided to get there well ahead of schedule and lined up before 7 a.m. at Apple Park Visitor Center, located next to the Apple Park, which houses an Apple Store, a café, a diorama, and a terrace. It seems that Japanese people are particularly good at early mornings because a sizable group of Japanese was already at the front of the line, eagerly waiting for the event to begin. As the clock approached 8 a.m., excitement built up, and the crowd spontaneously broke into chants of "dub-dub-dee-see!", hyping up the atmosphere (of course, I joined in with full enthusiasm!) Then, at 8 o'clock, the gates opened. I rushed to the Keynote venue and managed to secure a seat in the sixth row from the front.  It's so close! I had free time from this point until 10 a.m., so I grabbed breakfast, explored Apple Park, and hopped on a Zoom call with my team members in Tokyo, who were staying up late to watch the Keynote live. Here is a tweet from that time: https://twitter.com/ioco95/status/1800239213851574355 Since my seat was on the right side of the stage, I got a behind-the-scenes glimpse of Tim Cook and Craig Federighi as they prepared to go on stage. Craig's movements were incredibly acrobatic this year. The highlight of this year's Keynote was Apple Intelligence. But personally, what caught my attention the most was the Math Notes feature, which allows handwritten equations to be instantly solved, and the Mac Virtual Display in visionOS 2, which transforms into an ultra-wide monitor view on Apple Vision Pro (even though I don't own an Apple Vision Pro yet.) At lunch, Caffe Macs offered a variety of regional dishes on both sides of the dining area. Some people even lined up multiple times to try different meals. In the afternoon, I watched the Platform State of the Union inside Apple Park. Events at In-Person Labs and Exploring the Venue And finally, it's time for the In-Person Labs. This time is for meeting Apple engineers and staff, who can answer questions and help troubleshoot challenges in different areas. Since I had pre-booked a session for the Design Labs, I headed up to the third-floor area.  At the Design Labs, I was able to hear direct feedback from Apple employees on the KINTO Kantan Moushikomi App, as well as what the designers saw as potential challenges. It's a rare opportunity to get feedback from Apple employees, so this session was incredibly valuable. One lesson I learned from the Design Labs was the importance of ensuring that apps are accessible internationally by using TestFlight or other means. When I applied for the event, I included the App Store URL in the pre-registration form, assuming that Apple employees would be able to access it. However, since our app was Japan-only, they weren't able to check it in advance. As a result, I had to spend part of the limited time explaining the app and its challenges before I could ask my questions. (Something to keep in mind for anyone attending in the future!) After the Design Labs session, I walked around several areas to get answers to the questions I had from our in-house engineers. In between sessions, I also took some time to explore Apple Park (both the courtyard and inside the buildings).  There were a lot of people who looked like they wanted a photo, so I offered, "Would you like me to take a picture for you?" and naturally ended up making new friends. Attending the OMT Conference Actually, the on-site WWDC event only takes place for three days—Sunday, Monday, and Tuesday. While sessions run from Monday to Friday, the on-site event doesn't extend. So, I also attended the One More Thing (OMT) Conference held at a hotel near Cupertino, where Apple Park is located, from Tuesday to Friday.  A lineup of familiar sponsors  I got badges here, too. It says Pro Ticket, but it's actually a free ticket OMT Conference was divided into speaker sessions (Main Room) and consultation sessions (Big & Small Tents) where attendees could discuss various topics with experts. We could listen to talks from different speakers or discuss specific topics with experts. In addition, on Thursday afternoon, there was a workshop by Paul Hudson. Originally, it was planned to focus on SwiftData, but since there weren't many updates in WWDC24, he adapted the content and led a three-hour workshop on "What's New in SwiftUI" instead. I often check out Hacking with Swift, but this was my first time attending one of Paul's workshops in person. I was impressed by how amazing he is as a teacher and how quickly he answered questions. Attending Swift Social 2024 and Core Coffee In addition to attending WWDC and OMT conference, I also joined two community events. The first was Swift Social 2024. This event was organized by the Swift community and rented out a bar in downtown San Jose to celebrate Swift's 10th anniversary.  *Happy 10th Anniversary! *  Stylish SWIFT logo sign During the event, participants competed in a Swift-related quiz using Kahoot, racing to answer as quickly as possible. The top scorers won exclusive Swift merchandise as prizes.  I made it pretty far, but alas! The second was Core Coffee. This gathering took place every day during the WWDC week at different locations, and the session I joined was held on the rooftop terrace of Apple Park Visitor Center, right next to Apple Park. Perhaps due to its proximity, a few Apple employees also joined. Discussions naturally centered around the topics announced at WWDC24, sharing their thoughts and interests. One particularly lively debate was about how a color tint on the home screen might affect. I also had the chance to hear about the work styles of Apple employees and the products they are involved in, which made me feel even more engaging. Establishing Standards For Attending Overseas Conferences After I attended WWDC, several other conferences took place on the U.S. West Coast, and more members from our company began participating in overseas events as well. We are also working on establishing internal guidelines for attending international conferences. These global events offer valuable inspiration, and bringing it back home helps boost both individual and team motivation. Conclusion Attending WWDC for the first time was a long-awaited experience. It reignited my passion for development and game me the opportunity to build new connections. Everyone at WWDC is involved in developing something within the Apple ecosystem, and through conversations, I learned about the apps they were building, their roles, and the challenges they face in development. (Of course it was't just developers, there were also product managers and other contributors to the ecosystem.) It was incredibly inspiring that I also met several attendees whose primary job was not app development, but who were passionate about building apps as a hobby. I also had the chance to connect with developers from Japan, and some of those I spoke with during the event became familiar faces after returning home. If you're involved in product development for the Apple ecosystem, I highly recommend attending WWDC. Connecting with developers from around the world is truly exciting!

こんにちは、 Prism Japan でエンジニアを担当している宇田川です。 React Emailを活用したメールの自動配信を行うマーケティング施策について紹介したいと思います。 マーケティング施策において、直面していた課題 Prism Japanは、2022年8月にローンチされ、サービス開始当初から、様々なマーケティング施策を通じてユーザーを獲得してきました。しかし、一度獲得したユーザーが継続的にサービスを利用し続けてもらえるわけではありません。サービス開始から約2年半が経過しましたが、依然として休眠ユーザーが増加傾向にあります。 この問題に対処するため、プッシュ通知による再訪施策を実施していましたが、いくつか課題に直面しました。 通知設定をオフにしているユーザーには、プッシュ通知は届かない。 再訪を促すプッシュ通知を配信しても、アプリをアンインストールしているユーザーには届かないため、狙った効果を得られない。 実際、プッシュ通知の許諾率は約48%にとどまっており、この許諾率と、アンインストール済みユーザーを考慮すると、通知が届くユーザー数は、かなり絞られてきます。さらに、他のアプリからの通知もあるため、他の通知に埋もれがちです。このようにプッシュ通知で行える再訪施策の効果には限界がありました。 一方で、会員登録時にメールの登録をお願いしているのですが、こちらで登録されたメールの許諾率は、約90%と非常に高い水準を維持しています。アプリを削除していても、退会していないユーザーにはメールを届けられるため、再訪施策に適したマーケティングチャネルです。 しかし、運用面を考えるといくつか課題がありました。 まず、マーケティング担当のリソースが限られており、施策立案からSNS運用まで幅広い業務を、一人で担当している状況でした。メールのコンテンツ制作においては、ランキングの手動集計や適切な画像選定、レイアウト設計などに、工数が多く必要となります。このように、マーケティング担当のリソースを考えると、頻繁な配信が困難です。そのため、効果的なマーケティング手段と認識しつつも、頻度高くメール配信を行うことは、運用負荷を考えると現実的ではありませんでした。 メールの作成を自動化するために、React Emailを使うことに そこで「 メールの作成から配信までを自動化できないか 」という発想が生まれました。 コンテンツに表示する情報を自動的に収集し、メールコンテンツを自動で作成し、スケジュールされた日時に決められたレイアウトで自動的に配信できる仕組みを構築できれば、限られた人的リソースの中でも、ユーザーに合ったメールを送信できます。 しかし、HTMLメールを自動的に作成する処理を考える際に、エンジニアとして、実装方法に頭を悩ませました。 HTMLを直接操作するような処理を実装してしまうと、再利用性が低く、受信するメーラーによって表示が異なるといった問題も発生します。そして、将来的に、コンテンツの差し替えが発生することを見据えると、再利用性が高く、新しいコンテンツを柔軟に追加できるような実装が必要です。 このような悩みを抱える中で発見したのが「React Email」というライブラリです。 この「React Email」には、下記のような特徴があります。 JSXでHTMLメールを作成できる リアルタイムのプレビュー機能 コンポーネント化による高い再利用性 特に重要なのは、再利用可能なコンポーネント化によって、新しいコンテンツの作成が必要になった際に、容易に追加できる点です。また、Reactで記述されていることにより、掲載内容の動的な差し替えも容易になります。このような利点は、ユーザーの行動や興味に基づいて、コンテンツを差し替えることにより、 パーソナライズされたコンテンツの提供 を、低コストで行うことができます。全ユーザーに対して、同一のコンテンツを一斉配信するのではなく、各ユーザーの関心に合わせたコンテンツ配信を行うことで、 高い再訪率やエンゲージメント向上 が期待できます。 React Emailを利用することで、メール配信施策における課題を効果的に解決できる見通しが立ち、効率的なユーザー再訪施策の実現に向けて、施策を進めることができました。 React Emailを使ったHTML生成 ここからは、実装部分について触れていきたいと思います。 実装としては、メールのHTMLを生成する部分に、React Emailを利用しています。 React Emailのrender関数を使って、JSXからHTMLを生成する流れを採用しました。 まずは、以下のようなコンポーネントを作成します。 import React from "react"; const AppCheckSection = () => { return ( <div style={{ padding: "20px 0", borderBottom: "1px dashed #cccccc" }}> <div> <p> 詳しいスポットの情報やアクセス情報はアプリで確認してみましょう。 <br /> 他にも、アプリではあなたにだけのおすすめスポットを掲載中！ </p> <a style={{ padding: "10px 70px", background: "rgb(17,17,17)", borderRadius: "5px", textAlign: "center", textDecoration: "none", color: "#fff", display: "inline-block", marginBottom: "10px", }} > <span>アプリをチェック</span> </a> <br /> <a href="https://deeplink.sample.hogehoge/"> うまく開かない方はこちら </a> </div> </div> ); }; export default AppCheckSection; このように、メールを構成するための、コンポーネントを作成していきます。 その後、親コンポーネントで、作成したコンポーネントを組み合わせるだけで、メールのテンプレートが完成します import React from 'react'; import AppCheckSection from '../shared/AppCheckSection'; import FooterSection from '../shared/FooterSection'; import RankingHeaderSection from './RrankingHeader'; import RankingItems from './RankingItem'; export type RankingContents = { imageURL: string; name: string; catchPhrase: string; }; export type WeeklyRankingProps = { areaName: string; contents: RankingContents[]; }; const WeeklyRanking: React.FC<WeeklyRankingProps> = ({ areaName, contents }) => { return ( <div style={{ backgroundColor: '#f4f4f4', padding: '20px 0' }}> <div> <RankingHeaderSection /> <RankingItems areaName={areaName} contents={contents} /> <AppCheckSection /> <FooterSection /> </div> </div> ); }; export default WeeklyRanking; そして、メールHTMLの生成には、React Emailのrender関数を使用します。 fetchRegionalRankingDataを用いて、住んでいる地域ごとに、異なるコンテンツ情報を取得して、メールを作成することができます。 import { render } from '@react-email/render'; import { WeeklyRankingEmail } from '../emails/weekly-ranking'; import { fetchRegionalRankingData } from './ranking-service'; export async function generateWeeklyRankingEmail(areaName: string): Promise<string> { const contents = await fetchRegionalRankingData(region); const htmlContent = await render(await WeeklyRanking({ areaName, contents })); return emailHtml; } render 関数で生成された HTML は、SaaS サービスの API を介して送信されるメールの本文として使用されます。 バッチ処理では、EventBridge によってスケジュールされたタイミングで ECS が起動し、メールの作成および送信処理が実行されます。 実際に送信されるメールは、以下のような内容になります。 画像では、関東地域に絞られた内容が表示されていますが、ユーザーが設定した地域に応じて内容を柔軟に変更できる仕組みを実装しています。なので、居住地域が、大阪であれば関西地方のランキングがメールとして配信されます。 そして、React Emailでは、プレビュー機能があり、普通にReactで開発するときと同じように、メールの実装を進めることができます。プレビューなしで実装することは、かなり難易度が高いので、この機能は非常に助かります。この機能を活用し、マーケティング担当の方とレイアウトについて、適宜確認しながら実装作業を進められました。 コンポーネント化により、ランキング以外にもフッターやアプリ起動促進セクションなど、様々な要素を再利用可能なパーツとして構成しました。これにより、新規コンテンツの作成においても既存コンポーネントを組み合わせることで、効率的かつ一貫性のあるメール配信が可能になっています。 スケジューリングされたメール配信では、同じようなコンテンツの繰り返しになってしまい、ユーザーの興味低下や、最悪の場合は迷惑メールに登録されてしまい受信を拒否されてしまう可能性があります。自動化されたシステムであっても、 ユーザーの関心を継続的に引きつけるコンテンツ提供 が求められるはずです。 このような状況を踏まえると、素早く提供するコンテンツの変更が出来るように、コンポーネント化による再利用性の高い設計が、重要だと考えています。 メールを自動配信した効果 React Emailとバッチ処理による自動メール配信を開始した結果、配信した日(2月22日)の付近は、インストール数が増加していました。これは、メールを見た休眠ユーザーが、アプリに興味を持ち、 再インストールを促すことができた と考えています。また、メールを配信日付近のDAUが大きく上昇し、メール自動配信の施策開始以降のDAUは持続的に増加傾向を示していました。 このように、アプリをアンインストールしたユーザーも含む、休眠ユーザーの再訪を促すことに成功しました。 まとめ React Emailを活用した自動メール配信により、人の手を介さずに 休眠ユーザーの掘り起こし や、 DAUを増加 させることに成功しました。 アプリ開発で休眠ユーザーが多く、マーケティングリソースに限りがあるという課題は多くのマーケティング担当者が頭を抱えているのではないでしょうか。React Emailを利用したメール作成の自動化は、メールのコンテンツ内容を毎週考える負荷を軽減し、 効率的で、効果的なマーケティング活動 をすることができます。さらに、コンテンツの改善を継続的に行い、それを 素早くリリース するためにも、「React Email」は非常に有用だと感じました。 また、コミュニケーション手段が多様化した現代であっても、 ユーザーの興味に沿ったコンテンツ を届ければ、マーケティングチャネルとして、メール配信は有効に機能することがわかりました。 再訪ユーザーが伸び悩んでいたり、休眠ユーザーの掘り起こしでお悩みの方は、ぜひこのアプローチを検討してみてはいかがでしょうか。

This article is the entry for day 23 in the KINTO Technologies Advent Calendar 2024 🎅🎄 1. Introduction Hi there! I’m Nishida, a backend engineer at KINTO FACTORY. Today, I’d love to share how we managed to slash our AWS costs. 2. What Made Us Start Working on Cost Reduction? At KINTO Technologies, we use Amazon QuickSight to visualize our AWS usage fees, making it easy to track costs for each product. A little while after launching KINTO FACTORY, we casually checked the project’s costs, and to our surprise, it turned out to be the second most expensive product in the entire company. We certainly didn’t anticipate incurring such high costs so early on. This "Wait, what?!" moment served as the catalyst for our applications team to spring into action and begin working on cost reduction efforts. 3. What We Actually Did Now, let’s dive into the specific cost-cutting steps we took. What We Actually Did When we broke down the costs, ECS Fargate stood out as the clear front-runner in expenses. Not too surprising, since KINTO FACTORY’s applications run on ECS Fargate but still, we figured there had to be ways to optimize it. The first thing that caught our eye was: "Wait... are the number of instances in the development environment the same as production?" That definitely didn’t make sense. The development environment shouldn't require nearly as much computing power. So, we reduced the number of instances in the development environment to only those that were absolutely essential. Upon further investigation, we discovered that there is another Fargate launch type called Fargate Spot that is different from the usual one. Fargate Spot is a system that lets you tap into unused AWS resources, offering discounts of up to 70% compared to the regular Fargate. Honestly, why wouldn’t you use it? Fargate Spot allows Amazon ECS tasks that can handle interruptions to run at a much lower cost. It works by running tasks on AWS’s spare compute capacity. When that capacity is needed elsewhere, tasks are interrupted, with a two-minute warning that is provided to wrap things up. -- https://docs.aws.amazon.com/en_us/AmazonECS/latest/developerguide/fargate-capacity-providers.html That said, as noted in the documentation, Fargate Spot relies on spare compute capacity, so tasks may occasionally be interrupted if AWS reclaims those resources. Applying this to the production environment wasn’t really an option, so the settings were adjusted for the development environment, where occasional interruptions wouldn’t cause any issues. Automating Startup and Shutdown of the Development Environment The development environment had also been running 24/7, just like production environment. To avoid unnecessary costs, it was set up to automatically shut down during off-hours — late nights, weekends, and holidays — when it wasn’t needed. Step Functions were used to automate the start-up and shutdown processes for both the application and the database. In the first stage, EventBridge is used to send start and stop triggers to Step Functions based on schedules set with cron. One key point: database startup takes time. Starting ECS right after the DB starts can lead to connection errors. To prevent that, the system first checks the DB status before launching ECS. For reference, here’s a sample code (YAML file) showing the Step Functions workflow: "DB Startup": { "Type": "Task", "Parameters": { "DbClusterIdentifier": "${db_cluster_identifier}" }, "Resource": "arn:aws:states:::aws-sdk:rds:startDBCluster", "Next": "Wait" }, "Wait": { "Type": "Wait", "Seconds": 300, "Next": "Checking DB status after startup" }, "Checking DB status after startup": { "Type": "Task", "Parameters": { "DbClusterIdentifier": "${db_cluster_identifier}" }, "Resource": "arn:aws:states:::aws-sdk:rds:describeDBClusters", "Next": "Check if startup is complete" }, "Check if startup is complete": { "Type": "Choice", "Choices": [ { "Variable": "$.DbClusters[0].Status", "StringEquals": "available", "Next": "Start up each service" } ], "Default": "Wait" }, Moving to a Serverless Architecture Next, while reviewing the batch processing for a certain feature, it became clear that the process (which took less than a minute) was running as a resident service on ECS. This setup wasn’t exactly cost-friendly too, so we moved to a serverless architecture using Lambda. Lambda, with its pay-as-you-go model based on request count and execution time, is perfect for short, quick processes or tasks that don’t need to run constantly. 4. Cost-Saving Results The efforts paid off quickly, with costs dropping by 65% compared to the peak. Less than half; who would’ve thought? Seeing just how much room there was to cut costs was honestly surprising. 5. Conclusion This time, the focus was on sharing cost reduction efforts. The steps taken weren’t complicated or anything fancy, but they still delivered solid results. Along the way, some valuable insights emerged. Cost reduction isn’t just about saying, “Look, we saved money!” By reviewing and eliminating unnecessary resources, we were able to gain better visibility into the entire system. It also provided a great opportunity to revisit the architecture. Asking questions like, "Is this resource really necessary?" naturally became part of the process. That mindset shift brings long-term benefits, making the effort more than worth it. Hopefully, this can be helpful for anyone facing similar challenges.

こんにちは こんにちは、2024年12月入社のまきどんです！ 本記事では、2024年12月入社のみなさまに、入社直後の感想をお伺いし、まとめてみました。 KINTOテクノロジーズ（以下、KTC）に興味のある方、そして、今回参加下さったメンバーへの振り返りとして有益なコンテンツになればいいなと思います！ Fsk 自己紹介 業務システム開発部 業務システムGでフロントエンド開発を担当しています。 これまで主にNextjsを用いたフロントエンド開発を中心に携わっており、皆さんにとって使いやすい画面づくりを心がけています。 まだまだ学ぶことも多いですが、少しでも皆さんのお役に立てるよう頑張っていきたいと思っています。 所属チームの体制は？ 自分を含めて5人体制です。PM１名、フロントエンドエンジニア２名、バックエンドエンジニア２名です。 KTCへ入社したときの第一印象？ギャップはあった？ copilot、chatGPTなど生成AIを使用するのはすごく助かります。 入社前は少し緊張していましたが、皆さんが温かく迎えてくださったので、すぐに安心しました。 現場の雰囲気はどんな感じ？ 困ったときにすぐ相談できる雰囲気があるのはすごくありがたいです。 ブログを書くことになってどう思った？ 自分の考えや感じていることを皆さんに共有する機会ができて、とても良いと思っています。 フランクさん → Fskさんへの質問 もしロボットに1つだけ面倒な日々のタスクを任せられるとしたら、どの作業を任せたいですか？ 無論、掃除です！毎日掃除に時間を取られるのはもったいないですし、その時間を他のことに使いたいですね。 高橋 自己紹介 オウンドメディアＧ、兼マーケティングプロダクト開発でプロジェクトマネージャーを担当しています。 クライアント/事業部の良き隣人として、また、エンジニアと事業部間の橋渡し役としてメンバーが同じ目標に向かって歩めるように日々活動しています。 前職ではWEBデザイナーとしての経験を積み、開発部へ異動してからは、内製の会員、決済、ポイント、施設情報などプラットフォーム系を兼任するマネージャーやってました。 所属チームの体制は？ オウンドメディアＧはPM1名、エンジニア２名。マーケティングプロダクト開発は静的コンテンツの開発に特化して、チームリーダー1名、PM1名、テックリード1名、エンジニア２名です。 KTCへ入社したときの第一印象？ギャップはあった？ 第一印象はオフィスが静か（前職では営業が同じフロアですぐ近くにいてうるさかった）。 ギャップは開発スタイルがグループごとに異なるのでマインドシフトが柔軟にできるように身構えておく事くらい。 現場の雰囲気はどんな感じ？ 静か。飲料の缶をゴミ箱に捨てるときにちょっと気を遣う。 ブログを書くことになってどう思った？ 社内の自己紹介ではモンハンが好きだしか伝わってなかったと思うので書く機会があってよかったです。 Fskさん → 高橋さんへの質問 ワールドとワイルズ、どっちが好き？ww これからのアップデートを期待してワイルズ！ワールドに負けじと10年以上遊べてほしい！ 現在、生成AIはデザイン分野で活用されていますが、多くのエンジニアが「AIプロンプト」エンジニアと呼ばれています、この現象について、どう考えていますか？ 著作権や肖像権に障らぬように気を付けつつ利用する…であれば、生成AIに任せても良いモノもあると思います。ただ、創造力を競うようなコンクールやコンテストなどの場に出るとなった時はふさわしくないと考えます。 呂 自己紹介 現在、業務システム開発部の業務システムGに所属し、主にバックエンドのシステム開発を担当しています。日々の業務では、社内の業務効率化やデータ連携を目的とした各種システムの設計・実装・運用保守を行っており、安定性と拡張性を重視した開発に取り組んでいます。 以前はIBMに勤務しており、日本国内の大規模な病院向けに医療情報システムの開発プロジェクトに従事していました。要件定義から設計、開発、導入、アフターサポートまで、幅広い工程を経験しており、現場のニーズに寄り添ったシステムづくりを意識してきました。 これまでの経験を活かしつつ、より実用的で価値のあるシステムを提供できるよう、日々技術力と業務理解の向上に努めています。 所属チームの体制は？ 自分を含めて5人体制です。PM１名、フロントエンドエンジニア２名、バックエンドエンジニア２名です。みんなは各領域・業務でのプロでチーム内で非常に勉強できました。 KTCへ入社したときの第一印象？ギャップはあった？ 入社して最初に感じたのは、同僚同士の関係がとても温かく、上下関係にとらわれずに気軽にコミュニケーションが取れる雰囲気があることでした。また、社内イベントが充実していることや、さまざまなサークル活動が活発に行われている点も印象的でした。福利厚生制度も社員に優しく、とても働きやすい環境だと感じました。 入社前に想像していた印象と比べても、大きなギャップはなく、むしろ想像以上に良い職場環境だと実感しています。 現場の雰囲気はどんな感じ？ とても明るく楽しい雰囲気です。日々の業務に関する検討はもちろんのこと、ちょっとした面白い出来事やアイデアも気軽に共有し合える環境が整っています。メンバー同士の距離も近く、誰とでもすぐに打ち解けられるので、安心して働くことができます。 ブログを書くことになってどう思った？ 自分の体験をこうして共有できることを、とても嬉しく思います。日々の業務や感じたことを通じて、少しでも誰かの参考になれば幸いです。 高橋さん → 呂さんへの質問 もしKINTOで車を購入するとしたらどの車に乗りたい？ やはり「クラウン」に乗りたいですね。昔からずっとかっこいいと思っていましたし、実は日頃の業務でテストデータを作成する際にも、この車種をよく使っていて、ちょっとした愛着があります（笑）。 また、社員割引の福利制度を活用すれば、非常に手頃な価格でクラウンに乗れるのも魅力的です。さらに、充実した保険制度など、お客様にも優しいサービスが揃っていて、本当に素晴らしいと感じています。 まきどん 自己紹介 12月入社のまきどんです。モビリティプロダクト開発部のマーケティングプロダクト開発Gに所属しています。業務では分析・機械学習周りを担当しています。主な役割は、データから課題を抽出し施策立案や出口戦略のご提案、機械学習を用いたシステムの設計等でサポートさせて頂いています。 前職ではスタートアップで建築×ITを主軸とした事業のPMを担当していました。 所属チームの体制は？ 私が所属しているデータ分析・ML活用チームはPM/PdM1名、スクラムマスター1名、エンジニア6名の計8名で構成されています。 KTCへ入社したときの第一印象？ギャップはあった？ 第一印象は大企業の傘下のため、やはり堅実なイメージがありました。しかし入社してみるとslackに生成AIが活用されていたり、システムにもAI活用を推進していたりと、想定していたよりずっとテックカンパニーかつベンチャー気質のあるスピード感を持った会社だと感じました。 現場の雰囲気はどんな感じ？ 同じチーム内はもちろんのこと、他部署でも悩んだり困ったことがあればすぐに相談でき、安心して働ける環境です。 ブログを書くことになってどう思った？ 実はエントリーより先に テックブログ を執筆させていただきました。ブログ自体書いた経験が無かったのですが、グループ内で相談・協力してくれたので不安なく書けたのが非常に良い経験になりました。今後も新しい知見や経験を社内外に展開していけるよう頑張ります！ 呂さん → まきどんへの質問 これまでの業務の中で、最も誇りに思っていることは何ですか? 機械学習ツールを用いてアウトプットしていたものを内製化することで、コストダウンとクリック率UPを実現できました！ ニーゼン フランク(Frank Neezen) 自己紹介 ビジネスディベロップメントグループのフランク・ニーゼンです。 正式にはビジネス開発マネージャーという肩書きですが、主な役割はテクニカルアーキテクトとして、グローバルフルサービス製品の設計と実装を支援することです。 私のバックグラウンドはコンサルティングで、Salesforceを活用してお客様の技術的・運用的なニーズに応えるためのアドバイスに注力してきました。 所属チームの体制は？ 体制は自分含め、さまざまなスキルを持つ4人のメンバーで構成されています。開発チームと密に連携し、グローバル向けのフルサービスリース事業ソフトウェアソリューションを開発しています。 KTCへ入社したときの第一印象？ギャップはあった？ アムステルダムのSalesforceから東京のKTCへの異動は驚くほどスムーズでした！当初は文化の違いに慣れることができるか不安もありましたが、素晴らしいオリエンテーションと神保町オフィスの心強いメンバーにより全く問題ありませんでした。初日から温かく歓迎いただいたおかげで、スムーズに馴染むことができました。どちらかと言いますと、一番苦労したのは日本語がまだ話せないため、例えば銀行の手続きや住民登録など、生活の準備を整えることでした。でもKTCのメンバーにはたくさん助けてもらえましたのでなんとかうまくいきました。 現場の雰囲気はどんな感じ？ 我々チームは全員神保町オフィス在中でして、多くのエンジニアと隣り合わせに座っています。雰囲気はオープンでプロフェッショナルですが、リラックスできる環境です。良いチーム感があり、みんな自分の仕事を成功させたいと思っているメンバーばかりです。 ブログを書くことになってどう思った？ 過去にSalesforce関連の記事を書いたことがあります。KTCに入社するまでの個人的なストーリーを書いたりなど、共有できるところは喜んでシェアしていきたいと思います！ まきどん → フランクさんへの質問 日本へ来て驚いたことがあれば教えて下さい！ 日本の安全さには本当に驚かされます。世界最大の都市である東京のどこを歩いていても、全く不安を感じません！さらに本当に驚くべきことは、財布や携帯電話などをなくしても、ほとんどの場合手元に戻ってくることです。自分がなくしたことにすら気づいていなかったのに、誰かが私のところに来て、失くした物を届けてくれたことも何度かありました。本当に新鮮で素晴らしい体験です！ さいごに みなさま、入社後の感想を教えてくださり、ありがとうございました！ KINTO テクノロジーズでは日々、新たなメンバーが増えています！ 今後もいろんな部署のいろんな方々の入社エントリが増えていきますので、楽しみにしていただけましたら幸いです。 そして、KINTO テクノロジーズでは、まだまださまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくは こちら からご確認ください！