KINTOテクノロジーズのブログ - TECH PLAY

TECH PLAY

KINTOテクノロジーズ

KINTOテクノロジーズ の技術ブログ

全1132件

はじめに こんにちは!KINTOテクノロジーズでデザイナーをしている桃井( @momoitter )です。 クリエイティブ室に所属しており、 コーポレートサイト や くもびぃ (KINTO公式マスコットキャラクター)関連サイトなどの制作に、最先端のWEB表現を取り入れながら携わっています。 2024年11月に「超本部会」という会社のイベントが開催され、私はそのイベントのオープニングムービーの作成を担当しました。その冒頭のワンシーンで、3つの生成AIを使用し、イベントのスタートを宣言する女性のキャラクターを作成しました。 実際の映像 https://www.youtube.com/watch?v=pVj_UQ_3-tg 「もちろんです」と言っているのは、その直前に「準備はいい?」と問いかけるシーンがあったため。 今回はこちらの喋るオリジナルキャラクター作成の工程や、作成時にどのようなことを考えたかをご紹介します。 独自のキャラクターを作成して、言葉を喋らせたい AIを取り入れて印象に残る映像を手軽に作成したい という方はぜひご覧ください! 背景 イベント全体のクリエイティブを監修するアートディレクターからのオーダーとしては、「 コーポレートサイト のKVで使われている動画を再編集して1分のオープニングムービーを作る」というものでした。 ですが、ただ再編集するだけでは社員からすると既視感があるので、華やかにイベントのスタートを切れるように、会場の空気を惹きつける何かが必要と感じていました。 そこで目をつけたのが、弊社のSlack内にある「しぇるぱ」というAIチャットボット。 AIを駆使し、サプライズとしてそのしぇるぱを擬人化した映像を作れば、注目があつまるのではないかと考えました。 使用したAI 喋るオリジナルキャラクター作成にあたり、下記3つのAIを使用しました。 Adobe Firefly(キャラ画像生成) TTSMaker(テキスト読み上げ) Runway(キャラを喋らせる) ここから先は、これらのAIを使用しどのように動画を生成したかをご紹介します。 1.キャラ画像生成 Adobe Firefly Adobeが提供している画像生成AIツール。 Adobe Stockなど著作権フリーの画像を学習しているので、著作権の侵害の心配なく使用できます。 一般的に有名な画像生成AIでは、著作権フリーを謳っているものも多いですが、アニメのキャラに似たものが生成できてしまったり実際はグレーなものが多いものの、社内イベントであるとはいえ著作権はしっかりクリアしておきたかったため、そのような問題を気にせず使用できるこちらのAIをセレクトしました。 Adobe Firefly 生成のイメージ 今回のキャラクターの元ネタになった「しぇるぱ」は、弊社のSlackでこのようなアイコンで表示されています。 このアイコンから 「しぇるぱ」の「ぱ」→女性らしさを感じる音の響き アイコンがピンク→ピンクの髪の毛 AIのチャットボット→スマートでデジタル感のある雰囲気 などキャラクターのイメージを膨らませていきました。 画面上の操作 Fireflyを開くとこのような画面になっています。 大まかにいうと、下の入力エリアに画像を生成するためのプロンプトを打ち込み、左側のメニューで縦横比・構成・スタイル・トーンなどの調整を行います。 今回は試行錯誤の末、「3dのキャラクター、女性、ピンクの髪、背景は白、上半身、白くてシンプルでデジタルな服装、正面を向く」というプロンプトで生成していきました。 量産 プロンプトがある程度固まってくると、良い生成結果に出会うためには運次第でもあるので、100~200枚をひたすら生成しました。 選定 イベントの始まりをフレッシュにスタートさせたかったので、「AIオペレーター」的なオフィシャル感、安心感があるキャラクターが理想でした。 そのため 幼すぎる 服が奇抜 顔が怖い など、イメージから遠いものは除外していきました。 決定した画像 細かい選定作業を経て、最終的にクールでありながら親しみも感じられるこちらの画像に決定しました。 2.テキスト読み上げ TTSMaker 打ち込んだテキストを音声に変換するAI音声ジェネレーター。 このようなAI準拠のテキスト読み上げサービスは多数存在するのですが、有料だったり無料でもクレジット表記をしないといけないものが多かったので、無料かつクレジット表記無しで利用できるこちらのツールを使用しました。 TTSMaker 画面上の操作 TTSMakerを開くとこのような画面になっています。 手順としては 言語を選択 読み上げさせたいテキストを入力 サンプル音声を視聴しながら声色を選択 しゃべる速さ、声の高さなど、詳細の設定 変換 になります。 今回はAIオペレーター的な、オフィシャル感、安心感がある声が理想だったので、サンプル音声を聴き比べながら、「406 - yuki つみゆき-🇯🇵 japanese female」の声色を選択し、「もちろんです。超本部会を始めます。」というテキストを読み上げてもらいました。 実際の音声 https://www.youtube.com/watch?v=r4Zw2by669I 3.キャラを喋らせる Runway AIを活用して簡単に高品質な動画を生成・編集できるツール。 「Lip Sync Video」という、人物やキャラクターの静止画を、音声に合わせて喋らせる機能があったため、このツールを使用しました。 画面上の操作 1.「Generative Audio」内、「Lip Sync Video」を開き、先ほど生成したキャラクターの画像をドラッグ&ドロップ 2.キャラクターの画像の顔の範囲の認識が合っているか確認し、問題なければ「upload audio」をクリック 3.先程生成した音声をドラッグ&ドロップし、「Generate」をクリック 生成された映像 https://www.youtube.com/watch?v=usY4yB9Z1YA 音声に合わせて喋るキャラクターの映像が生成されました。 応用編 その1 https://www.youtube.com/watch?v=raYsnhwZONo アップロードする音声を曲にすると、キャラクターに歌わせることもできます。 応用編 その2 https://www.youtube.com/watch?v=3edVClgoLug このように人物の静止画を喋らせることも可能です。 先日の社内勉強会(東京開催)で、急遽登壇者が大阪からの出張ができなくなってしまったため、静止画とボイスメモを用意してもらい、このようなAI生成映像で発表を行いました。 4.仕上げ 喋るキャラクター映像の作成方法としては以上で、ここからはプラスαです。 実は「AIでキャラクターを喋らせる」というところまでは、上記で紹介したAIを使えば誰でも作ることができてしまうぐらい簡単です。 ただ、私はデザイナーとして「クリエイティブ室」に所属しているので、クリエイターとしての意地といいますか、他の部署でも作れるようなものにはしたくなかったため、最後にIllustratorで作成した「しぇるぱ」のバルーン型3DCGを、After Effectsを使用しふわふわ浮遊するモーションをつけ、先ほど生成した映像と合成することで画としての完成度を上げ、「クリエイターならでは」という価値を加えました。 完成した映像 https://www.youtube.com/watch?v=pVj_UQ_3-tg 最後に一手間加えることで、ただのキャラクターが喋る映像が、一気にグラフィカルな表現が加わった映像へと進化しました。 まとめ 会場で投影された際の様子 クリエイティブ系の生成AIにはそれぞれ特性があり、できることには限りがあります。 それらの特性を理解し組み合わせることで、今回は単一のツールでは作成できないクオリティの映像を生み出すことができました。 イベント当日はこのキャラクターが大きいスクリーンで投影され、ありがたいことに あれすごかったですね、どうやって作ったんですか!? クオリティ高くて、外注してるのかと思いました。 など社員から声をかけていただくことも多く、狙ったインパクトを残すことができたかなと思います。 それぞれのAIツールの操作としてはとても簡単で、非クリエイターでも使用できるようなものです。 アイデアさえあればこのような印象に残る映像を作成できるので、この記事を見て気になった方はぜひ実践してみてください! 最後までご覧いただき、ありがとうございました。
自己紹介 KINTOテクノロジーズにて主にプロダクトセキュリティ、セキュリティガバナンス業務に携わっている森野です。 RB大宮アルディージャとちいかわが好きです。 ここ10年はサイバーセキュリティ、情報セキュリティに関する仕事に携わっています。それ以前はWebアプリケーションエンジニアとしてWeb効果測定システムやECサイトのフロントエンドシステムの開発、運用に長く携わっていました。 本記事では当社のVDP(Vulnerability Disclosure Program)カイゼン活動について紹介させて頂きます。 VDP(Vulnerability Disclosure Program)とは 企業や組織が外部のセキュリティ研究者やホワイトハッカーから脆弱性の報告を受け取るための制度です。 2023年10月に楽天グループが公開サーバーに「security.txt」を配置しVDPを開始した事で世間の認知度が向上しました。 参考:楽天が公開サーバーにテキスト設置、セキュリティー向上に役立つ「security.txt」 security.txtとは 2022年4月に「RFC 9116:A File Format to Aid in Security Vulnerability Disclosure」として企業や組織が脆弱性の開示方法を説明しセキュリティ研究者などが発見した脆弱性を報告しやすくするために定義されたものです。 2023年11月に当社もsecurity.txtを配置しました。 security.txt設置後の反応 報奨金の有無を確認する問い合わせが殆どで(当社は報奨金制度は提供していない)、KINTO/KTCの脆弱性情報を持っているのか否か不明な報告が多く寄せられました。 ホワイトハッカーからの報告キタ━(゚∀゚)━! 2024年8月に当社サービスに存在する脆弱性の報告がありました。私たちのグループで報告内容を検証した結果、事実であることが確認できたため開発グループに依頼して脆弱性を修正しました。 VDPのカイゼン VDPの意義を実感できた一方、下記の課題感があったため、Issue Hunt社が提供しているVDPサービスの活用を2024年11月から開始しました。 懸賞金の有無などVDPガイドラインの提示 報告対象となるWebサービスやアプリケーションの提示 報告テンプレートの提示 開始から2025年3月7日現在、6件の報告があり内2件は対応が必要な脆弱性と判断して修正を行いました。予想以上の成果に正直驚いています。 Issue Hunt社のサイトに導入事例として当社が紹介されているので宜しければそちらもご覧ください。 セキュリティ向上の新常識!車サブスク業界におけるVDP導入の成功事例 P3NFEST Bug Bounty 2025 Winterへのプログラム提供 前述の通り、当社では報奨金制度は提供していません。 しかし、報奨金制度の効果検証および将来のインターネットの安全を担う学生を応援することを目的にIssue Hunt社主催の学生向けバグバウンティプログラムにプログラムを提供することにしました。 バグバウンティ対象のサービスは以下の通りです。 KINTOテクノロジーズコーポレートサイト KINTO Tech Blog(当サイト) 開催期間は2025年2月17日(月)から2025年3月31日(月)までです。 詳細はイベント情報ページをご覧ください。学生の皆さんの挑戦をお待ちしております。 P3NFEST Bug Bounty 2025 Winter
Hello! I am Wada ( @cognac_n ), a Generative AI Evangelist at KINTO Technologies (KTC) as part of the Generative AI Utilization(PJT). At KTC, the adoption of generative AI is advancing across various areas. For example, @ card @ card @ card :::details other KTC Tech Blogs on generated AI @ card @ card @ card @ card @ card ::: Both engineers and non-engineers are utilizing generative AI in ways that fit their roles and tasks. The Generative AI PJT has been working towards the vision of becoming a "company where using generative AI is second nature for everyone". This time, we’d like to introduce our efforts. 1. Introduction of Generative AI Utilization PJT This initiative was launched in January 2024 to promote the use of generative AI within the company. Generation AI Utilization PJT currently has three main functions. Three key functions of the PJT Functions of the Generative AI Utilization PJT These functions are not independent but are part of a continuous cycle aimed at accelerating the adoption of generative AI in various scenarios: Generating innovative ideas Assessing feasibility Implementing and delivering solutions Expanding through case study deployment The goal is to speed up this cycle, ensuring generative AI is utilized effectively in every scenario. Generate AI Utilization PJT functions and cycles In this article, we will introduce our activities with a focus on education and training . 2. The Basic Concept of the Education and Training System To realize the vision of "a company where everyone naturally utilizes generative AI", we have adopted three key principles: Generative AI is not just for specialists There are “optimal utilization levels” based on each role Emphasis on step-by-step learning, from basics to advanced expertise Basic idea of the training system At KTC, multiple instructors conduct training sessions on a variety of topics. In addition, the training participants include both engineers and non-engineers, covering a wide range of roles and responsibilities. To ensure consistently high-quality training, even in such a diverse environment, we established a shared understanding of the fundamental principles. This approach wasn’t predetermined from the start; instead, it gradually developed through ongoing refinements driven by internal feedback. 3. Training System Implementation Based on these three core principles, we have developed a structured, step-by-step training program. Training Name Target Audience Content Beginner All employees Basic knowledge of Generative AI and Prompt Engineering. The foundational first step for everything Case Study All employees Introduction of internal and external use cases. Develop the ability to take best practices and adapt them independently Improved Office Productivity Selected employees from each department (Ambassador system) Master generative AI as a tool to create business value. Drive business process transformation with AI integration. Become an in-house advocate and evangelist for AI utilization. Generalist People involved in system development Learn key aspects of system development using generative AI. Develop the ability to assess technology, create value, and validate outcomes Engineering The engineer responsible for implementation Build practical implementation skills for system development using generative AI. Gain hands-on knowledge and experience to effectively deliver value. Each journey uniquely defines the target level of generative AI utilization. 4. Emerging Value How engineers are changing Proposing the addition of generative AI features to existing systems Planning and pitching new services utilizing generative AI Independently developing AI-powered tools to improve work efficiency Advanced utilization of generative AI tools such as GitHub Copilot How non-engineers are changing Active use of generated AI in day-to-day operations Improved technical communication with AI support Taking on the challenge of developing simple tools As I introduced the blog at the beginning, employees who have undergone training are now actively leveraging generative AI within their roles and responsibilities. From daily tasks and communication to system development, generative AI is driving efficiency improvements and adding value across various scenarios. The types of inquiries we receive have also evolved—from "I don’t know what’s possible" to "I tried it! How can I improve it further?" or "I believe we can achieve something like this, can we collaborate?" With growing generative AI literacy, employees are no longer hesitant to "try first", and they are developing an intuitive sense of "this seems possible—and valuable". 5. Future Prospects Generation AI technology is evolving rapidly. KTC/KINTO is beginning to achieve "commonplace AI usage", but there is no definitive goal for what "commonplace" should be. "Aiming to be a company where using generative AI is second nature for everyone". We will continue pushing forward with our initiatives! We Are Hiring! KINTO Technologies is looking for passionate individuals to help drive AI adoption in our business. We’re happy to start with a casual interview. If you’re even slightly interested, feel free to reach out via the link below or through X DMs . We look forward to hearing from you! Great place to stay! @ card Thank you for reading all the way to the end!
この記事は KINTOテクノロジーズアドベントカレンダー2024 の10日目の記事です🎅🎄 背景 KINTOかんたん申し込みアプリ の開発にあたっては、KMP (Kotlin Multiplatform)を利用して共有コードを実装し、Swift Packageとして公開しました。このアプローチではコードの重複を回避することで、プラットフォーム間でコードを効率的に共有できたり、開発プロセスをシンプルにすることができました。 当社のiOSチームは現在XcodeGenを使用して依存関係を管理しており、KMPコードのインポートは project.yml ファイルに修正を4行加えるだけで簡単に行えます。このような変更例は次のとおりです。 packages: + Shared: + url: https://github.com/[your organization]/private-android-repository + minorVersion: 1.0.0 targets: App: dependencies: + - package: Shared - package: ... ところが、コードがプライベートリポジトリにあるためにいくつかの設定を追加する必要があります。このブログではその手順をまとめて、どのようにプロセスを効率化したかを説明します。 Package.swiftについて KMPコードをSwiftパッケージとして公開する方法を簡単に説明します: KMPコードを .xcframework にコンパイルする。 .xcframework をzipファイルにパッケージ化し、チェックサムを計算する。 GitHubに新しいリリースページを作成し、リリースアセットの一部としてzipファイルをアップロードする。 リリースページからzipファイルのURLを取得する。 URLとチェックサムを基に Package.swift ファイルを生成する。 Package.swift ファイルをコミットし、リリースをマークするgitタグを追加する。 そのgitタグをリリースページに関連付け、GitHubリリースを公式に公開する。 結果として生成される Package.swift ファイルは次のようになります。 // swift-tools-version: 5.10 import PackageDescription let packageName = "Shared" let package = Package( name: packageName, ... targets: [ .binaryTarget( name: packageName, url: "https://api.github.com/repos/[your organization]/private-android-repository/releases/assets/<asset_id>.zip", checksum: "<checksum>" ) ] ) 開発環境の権限設定 URLはプライベートリポジトリに存在するため、権限設定を行わないと次のエラーが発生します。 これを解決するために、2つのオプションを検討します。 1つ目は、 .netrc ファイル、2つ目は Keychainを使います。 オプション1: .netrc ファイルを使用する場合 GitHubの認証情報を .netrc ファイルに保存すると、APIリクエストの認証を簡単に行うことができます。 #例: echo "machine api.github.com login username password ghp_AbCdEf1234567890" >> ~/.netrc echo "machine api.github.com login <Your Github Username> password <Your Personal Access Token>" >> ~/.netrc 素早くできて効果的な方法ではあるものの、トークンがプレーンテキストで保存されるため、セキュリティリスクの恐れがあります。 オプション2: Keychainを使用する トークンをプレーンテキストで保存したくない場合は、 Keychainを使用して資格情報を安全に保存することができます。 Keychain Access.app を開く。 ① ログイン Keychainを選択する。 ②を選択して、新しいPassword項目を作成する。 ダイアログボックスで、次の情報を入力する。 Keychain項目名: https://api.github.com アカウント名: GitHubユーザー名 パスワード: パーソナルアクセストークン このアプローチはより安全で、macOS認証メカニズムと円滑に統合します。 SSHユーザーの場合 上記の手順では、 https プロトコルを使用してiOSリポジトリをクローンしたことを想定しています。この場合、 github.com に対して必要な権限はすでに設定済みです。 しかし、 ssh プロトコルを使用してリポジトリのクローンした場合、 github.com に対する権限が不足し、 resolveDependencies フェーズで権限に関連するエラーが発生する恐れがあります。 これを解決するには、 .netrc ファイルにドメイン github.com のエントリを追加します。 #例: echo "machine github.com login username password ghp_AbCdEf1234567890" >> ~/.netrc echo "machine github.com login <Your Github Username> password <Your Personal Access Token>" >> ~/.netrc または、 Keychain Access を使用して、 https://github.com という名前の項目を追加します。どちらの方法でも、システムに必要な権限があることをしっかりと設定できます。 GitHubのアクション ローカル開発環境の課題を解決した後は、 CI環境の権限への課題にも対応してビルド中の自動化をスムーズにする必要があります。 GitHubアクションでトークンを取得する パーソナルトークンを使用する 簡単なアプローチの1つは、プライベートリポジトリにアクセス可能なパーソナルアクセストークン(PAT)を作成し、Actionsシークレットを介してCI環境に渡すことです。効果的な方法ではありますが、欠点がいくつかあります。 トークンの有効期限 有効期限のあるトークンは定期的な更新が必要で、更新を忘れるとCIが失敗する恐れがあります。 有効期限のないトークンは、長期的なセキュリティリスクを引き起こします。 広範囲にわたる権限 通常、個人アカウントは複数のプライベートリポジトリにアクセスできるため、PATの権限を単一のリポジトリに制限することが困難となってしまいます。 属人化 アカウント所有者がロール異動によってプライベートリポジトリへのアクセスを失うと、CIワークフローが失敗してしまいます。 GitHubアプリを使用する より堅牢なソリューションにはGitHub Appの使用があり、次のようないくつかのメリットがあります。 リポジトリに対するきめ細かい権限 個々のアカウントに依存しない セキュリティを強化する一時的なトークンが使用可能 GitHubアプリの設定 最終的にはGitHub Appを使ってアクセス許可を設定しました。手順は次のとおりです。 組織内にGitHubアプリを作成する。 iOSとAndroid両方のプロジェクトにアプリをインストールし、リポジトリへのアクセスを管理する。 iOSプロジェクトのActionsシークレットでアプリの AppID と Private Key を設定する。 ワークフローにコードを追加して一時的なアクセストークンを取得する。例を紹介します。 steps: - name: create app token uses: actions/create-github-app-token@v1 id: app-token with: app-id: ${{ secrets.APP_ID }} private-key: ${{ secrets.APP_PRIVATE_KEY }} owner: "YourOrgName" - name: set access token for private repository shell: bash env: ACCESS_TOKEN: ${{ steps.app-token.outputs.token }} run: | git config --global url."https://x-access-token:$ACCESS_TOKEN@github.com/".insteadOf "https://github.com/" touch ~/.netrc echo "machine github.com login x-access-token password $ACCESS_TOKEN" >> ~/.netrc echo "machine api.github.com login x-access-token password $ACCESS_TOKEN" >> ~/.netrc GitHub Appを使用することで、CIワークフローの安全性と効率性を確保して、個々のユーザーアカウントへの依存が解消できます。このアプローチでリスクが最小限に抑えられ、チーム間の開発がスムーズになります。
This article is the entry for day 10 in the KINTO Technologies Advent Calendar 2024 🎅🎄 Mobility Night is a series of study sessions where software engineers, business professionals, researchers, and product managers in the mobility industry can casually gather to share industry-specific insights and challenges. After hosting our initial closed session (#0), we were excited to open the doors for everyone to join in our first public session (#1). This event focused on 'GPS and Location Information' which are fundamental technologies for mobility services. From car navigation and map applications to on-demand transportation, autonomous driving, and smart city infrastructure, precise location tracking is essential for enabling these innovations. During the event, five sessions were held. Each session explored challenges and possibilities from unique perspectives, focusing on GPS and location information technology. This article is written by Nakanishi from the Development Relations Group, who is also involved in planning and organizing the Mobility Night. 1. Exploring New Google Places API Speaker: Numa, KINTO Technologies Google Places API is one of the core features of the mapping platform and is an important interface for efficiently performing nearby searches and retrieving place information. In this session, the latest improvements were introduced, such as the enhancements to the Autocomplete feature, which provides instant suggestions while typing, and the Fields parameter to filter necessary information. Key points: Performance and cost optimization: By specifying Fields, unnecessary data retrieval can be reduced, leading to lower API costs and faster response times. User experience improvement: Providing quick access to the information they want is a significant advantage for users on the move. The enhanced Autocomplete feature reduces search load, refining the overall UX. Future outlook: Currently, the focus is on location information retrieval, but in the future, personalized strategies integrating IoT sensors and behavioral analysis are also expected. https://speakerdeck.com/kintotechdev/exploring-new-google-places-api 2. Location Data Products Created with Driving Data from AI Dashcam Services Speaker: Shimpei Matsuura, GO Inc. Dashcams are commonly perceived as devices for recording accidents, but in this session, they were reinterpreted as "driving data = a platform for turning streets into sensors." AI analysis of video and GPS data highlighted the potential for dynamically updating maps with real-time information on road signs, traffic signals, and construction conditions. Key points: Dynamic map updates: Evolving static maps into a "living information infrastructure" by reflecting changes in road infrastructure almost in real time. Multiple vehicle data integration: By cross-referencing data from different vehicles, temporary signs and construction sites can be detected with high accuracy. Privacy measures: Ensuring that personal information captured in video data is properly anonymized while retaining essential road-related information is crucial for both technology and operations. Future applications: Potential for various business developments, including HD maps for autonomous driving, smart city planning, and the creation of new services. https://speakerdeck.com/pemugi/aidorarekosabisunozou-xing-deta-dezuo-ruwei-zhi-qing-bao-detapurodakuto-wei-zhi-qing-bao-jing-du-xiang-shang-nogong-fu 3. An Overview of Satellite Positioning Technology: Lessons from Using GPS Modules Speaker: Shinya Hiruta, VP of Engineering, Charichari, Inc. Although GPS is widely taken for granted, but in urban environments, there are many practical issues such as radio wave reflection, poor visibility, and uneven number of satellites. In this session, we explored the fundamentals of satellite positioning technology, as well as potential accuracy improvements and countermeasures. Key points: Environment-dependent issues: Location-specific conditions, such as multipath interference in urban areas and satellite signal loss in tunnels, can significantly impact the accuracy. Multi-GNSS utilization: Instead of relying solely on GPS, combining multiple systems such as GLONASS, Galileo, BeiDou, and Michibiki (QZSS) enhances overall accuracy. Hybrid methods: Improved accuracy with complementary technologies such as accelerometers, gyroscopes, Wi-Fi/Bluetooth beacons, and map matching. Basic knowledge as a guiding principle: This understanding will serve as a guiding principle for future product design, quality assurance, and data analysis. 4. Experimenting the Post-Processing Technique for Location Information Correction (Tentative) Speaker: Kensuke Takahara, IoT Team, Luup, Inc. When real-time positioning accuracy is challenging, there is an alternative called "Post-Processing Kinematic (PPK)," which improves accuracy later. PPK is a method of post-processing by combining acquired data with reference station data without using expensive RTK equipment or special communication infrastructure. Key points: Benefits of PPK: Accuracy can be improved at a later date, regardless of real time. In the end, centimeter-level accuracy is achieved while reducing initial investment. Cost Efficiency and Scalability: Flexibility to improve accuracy later as future demand grows. Useful for delivery robots, drones, and shared mobility services. Application Range: PPK proves highly valuable in areas focused on post-analysis, such as map maintenance, advanced driving log, and infrastructure inspection. https://speakerdeck.com/kensuketakahara/hou-chu-li-dewei-zhi-qing-bao-wobu-zheng-suruji-shu-woshi-sitemita 5. Construction of Simulation Logic Before Introduction of On-Demand Bus Service (Tentative) Speaker: Halufy, New Technology Development Office, Advanced Planning Department, TOYOTA Connected Corporation While on-demand transportation is attractive for flexibility, it is not easy to ensure profitability and sustainability. This session introduced pre-implementation simulations to enable precise demand forecasting and operational planning. Key points: Building a sustainable model: Data is used to verify optimal station placement, fleet size, and time-of-day settings without relying on subsidies. Strategic data utilization: By integrating location data with OD data and reservation requests, simulations are conducted to test demand forecasting, pricing strategies, and route optimization. Long-term vision: It will serve as a foundation for improving overall urban transportation efficiency and convenience by integrating with other mobility means and infrastructure. Future Topics and the Prospects for Mobility Night By focusing on GPS and location information, Mobility Night #1 has taken a deep dive into the mobility industry's "current location awareness" technology. Many participants commented, "I never realized how deep the topic of location data could be!" and "It is valuable to hear about everything from the basics to advanced utilization." However, the mobility industry encompasses far more than just GPS and location information. In the future, we also aim to explore areas such as IoT device utilization: Real-time data collection and control from sensors Data analysis: Demand forecasting and advanced operational optimization Product design: Improving UX and maximizing user satisfaction Quality assurance: Ensuring reliability and compliance with safety standards to make it a place that encourages innovation throughout the industry. Mobility Night is not just planned by the organizers, but also welcome speaker proposals and topic suggestions from participants. We aim to create a community where discussions and co-hosting opportunities can be easily facilitated through Discord, making it accessible and engaging for everyone. https://discord.com/invite/nn7QW5pn8B Summary Mobility Night #1 clarified the core technological challenges of mobility services by focusing on GPS and location-based technologies, highlighting the potential for new value creation through overcoming these challenges. A diverse range of approaches intermingled, including efforts to transform static maps into a dynamic information infrastructure, enhance environment-dependent GPS accuracy through advanced methods, and develop data-driven strategies for on-demand transportation planning. These insights will be combined with future Mobility Night themes such as IoT, data analysis, product design, and quality assurance, further accelerating progress across the industry. Stay tuned to Mobility Night, and let's learn, interact, and create new value together!
This article is the entry for day 10 in the KINTO Technologies Advent Calendar 2024 🎅🎄 Mobility Night is a series of study sessions where software engineers, business professionals, researchers, and product managers in the mobility industry can casually gather to share industry-specific insights and challenges. After hosting our initial closed session (#0), we were excited to open the doors for everyone to join in our first public session (#1). This event focused on 'GPS and Location Information' which are fundamental technologies for mobility services. From car navigation and map applications to on-demand transportation, autonomous driving, and smart city infrastructure, precise location tracking is essential for enabling these innovations. During the event, five sessions were held. Each session explored challenges and possibilities from unique perspectives, focusing on GPS and location information technology. This article is written by Nakanishi from the Development Relations Group, who is also involved in planning and organizing the Mobility Night. 1. Exploring New Google Places API Speaker: Numa, KINTO Technologies Google Places API is one of the core features of the mapping platform and is an important interface for efficiently performing nearby searches and retrieving place information. In this session, the latest improvements were introduced, such as the enhancements to the Autocomplete feature, which provides instant suggestions while typing, and the Fields parameter to filter necessary information. Key points: Performance and cost optimization: By specifying Fields, unnecessary data retrieval can be reduced, leading to lower API costs and faster response times. User experience improvement: Providing quick access to the information they want is a significant advantage for users on the move. The enhanced Autocomplete feature reduces search load, refining the overall UX. Future outlook: Currently, the focus is on location information retrieval, but in the future, personalized strategies integrating IoT sensors and behavioral analysis are also expected. https://speakerdeck.com/kintotechdev/exploring-new-google-places-api 2. Location Data Products Created with Driving Data from AI Dashcam Services Speaker: Shimpei Matsuura, GO Inc. Dashcams are commonly perceived as devices for recording accidents, but in this session, they were reinterpreted as "driving data = a platform for turning streets into sensors." AI analysis of video and GPS data highlighted the potential for dynamically updating maps with real-time information on road signs, traffic signals, and construction conditions. Key points: Dynamic map updates: Evolving static maps into a "living information infrastructure" by reflecting changes in road infrastructure almost in real time. Multiple vehicle data integration: By cross-referencing data from different vehicles, temporary signs and construction sites can be detected with high accuracy. Privacy measures: Ensuring that personal information captured in video data is properly anonymized while retaining essential road-related information is crucial for both technology and operations. Future applications: Potential for various business developments, including HD maps for autonomous driving, smart city planning, and the creation of new services. https://speakerdeck.com/pemugi/aidorarekosabisunozou-xing-deta-dezuo-ruwei-zhi-qing-bao-detapurodakuto-wei-zhi-qing-bao-jing-du-xiang-shang-nogong-fu 3. An Overview of Satellite Positioning Technology: Lessons from Using GPS Modules Speaker: Shinya Hiruta, VP of Engineering, Charichari, Inc. Although GPS is widely taken for granted, but in urban environments, there are many practical issues such as radio wave reflection, poor visibility, and uneven number of satellites. In this session, we explored the fundamentals of satellite positioning technology, as well as potential accuracy improvements and countermeasures. Key points: Environment-dependent issues: Location-specific conditions, such as multipath interference in urban areas and satellite signal loss in tunnels, can significantly impact the accuracy. Multi-GNSS utilization: Instead of relying solely on GPS, combining multiple systems such as GLONASS, Galileo, BeiDou, and Michibiki (QZSS) enhances overall accuracy. Hybrid methods: Improved accuracy with complementary technologies such as accelerometers, gyroscopes, Wi-Fi/Bluetooth beacons, and map matching. Basic knowledge as a guiding principle: This understanding will serve as a guiding principle for future product design, quality assurance, and data analysis. 4. Experimenting the Post-Processing Technique for Location Information Correction (Tentative) Speaker: Kensuke Takahara, IoT Team, Luup, Inc. When real-time positioning accuracy is challenging, there is an alternative called "Post-Processing Kinematic (PPK)," which improves accuracy later. PPK is a method of post-processing by combining acquired data with reference station data without using expensive RTK equipment or special communication infrastructure. Key points: Benefits of PPK: Accuracy can be improved at a later date, regardless of real time. In the end, centimeter-level accuracy is achieved while reducing initial investment. Cost Efficiency and Scalability: Flexibility to improve accuracy later as future demand grows. Useful for delivery robots, drones, and shared mobility services. Application Range: PPK proves highly valuable in areas focused on post-analysis, such as map maintenance, advanced driving log, and infrastructure inspection. https://speakerdeck.com/kensuketakahara/hou-chu-li-dewei-zhi-qing-bao-wobu-zheng-suruji-shu-woshi-sitemita 5. Construction of Simulation Logic Before Introduction of On-Demand Bus Service (Tentative) Speaker: Halufy, New Technology Development Office, Advanced Planning Department, TOYOTA Connected Corporation While on-demand transportation is attractive for flexibility, it is not easy to ensure profitability and sustainability. This session introduced pre-implementation simulations to enable precise demand forecasting and operational planning. Key points: Building a sustainable model: Data is used to verify optimal station placement, fleet size, and time-of-day settings without relying on subsidies. Strategic data utilization: By integrating location data with OD data and reservation requests, simulations are conducted to test demand forecasting, pricing strategies, and route optimization. Long-term vision: It will serve as a foundation for improving overall urban transportation efficiency and convenience by integrating with other mobility means and infrastructure. Future Topics and the Prospects for Mobility Night By focusing on GPS and location information, Mobility Night #1 has taken a deep dive into the mobility industry's "current location awareness" technology. Many participants commented, "I never realized how deep the topic of location data could be!" and "It is valuable to hear about everything from the basics to advanced utilization." However, the mobility industry encompasses far more than just GPS and location information. In the future, we also aim to explore areas such as IoT device utilization: Real-time data collection and control from sensors Data analysis: Demand forecasting and advanced operational optimization Product design: Improving UX and maximizing user satisfaction Quality assurance: Ensuring reliability and compliance with safety standards to make it a place that encourages innovation throughout the industry. Mobility Night is not just planned by the organizers, but also welcome speaker proposals and topic suggestions from participants. We aim to create a community where discussions and co-hosting opportunities can be easily facilitated through Discord, making it accessible and engaging for everyone. https://discord.com/invite/nn7QW5pn8B Summary Mobility Night #1 clarified the core technological challenges of mobility services by focusing on GPS and location-based technologies, highlighting the potential for new value creation through overcoming these challenges. A diverse range of approaches intermingled, including efforts to transform static maps into a dynamic information infrastructure, enhance environment-dependent GPS accuracy through advanced methods, and develop data-driven strategies for on-demand transportation planning. These insights will be combined with future Mobility Night themes such as IoT, data analysis, product design, and quality assurance, further accelerating progress across the industry. Stay tuned to Mobility Night, and let's learn, interact, and create new value together!
This article the entry for day 9 in the 2024 KINTO Technologies Advent Calendar 🎅🎄 KINTO Technologies is an engineer-driven organization with a team of over 300 members. In an increasingly complex business environment, we continuously seek to balance organizational efficiency and creativity. With dispersed locations and increase in remote work, cross-departmental communication has become more limited, making it essential to address this challenge seriously. This article, written by Nakanishi from the Development Relations Group, discusses the first step in revitalizing the organization by using Slack, our primary tool for daily communication and how we're building a talent search system based on Slack. Talent search is a system that allows you to search for data on employees' skills. Why Is Talent Search Needed? While working efficiently is important, innovation often comes from unexpected encounters, and even seemingly mundane conversations can play a crucial role In our organization, the intense focus on daily tasks we often tend to overlook “tacit knowledge” and “latent potential”. For example, even if you think, "Is there anyone with this skill?", you don't know who to consult. As our organization grows, this information asymmetry has become a serious challenge. To tackle this challenge directly, we decided to strategically utilize Slack profiles and take a proactive approach. Benefits of Utilizing Slack Profiles From the Perspective of the Developer Relations (DevRel) Group Discovering previously unnoticed talent There are many individuals whose talents and potential remain unnoticed within the organization. Although members of the Technical PR Group communicate with employees daily, it is still challenging to fully understand everyone. Slack profiles serve as a new tool to make these "hidden talents" visible. Accelerating project support We hope that being able to quickly identify people with the right skills will dramatically improve the speed of project launch and problem solving Until now, finding someone with a specific skill often relied on word-of-mouth searches within the company. However, establishing a network that enables direct communication without relying on hub organizations like us is essential for the organization's future growth. Promoting cross-departmental collaboration Until now, the Technical PR Group has organized various initiatives, such as in-house study sessions, exchange events, and study sessions inviting external lecturers. As a result, natural communication has emerged within the company, creating a chain reaction where initial connections lead to an expanding network, new collaborations are established every day. This Slack initiative will surely spur this trend. Benefits for All Employees Expanding opportunities for career growth Clearly expressing your skills and interests opens up new possibilities that you may not have noticed before. By connecting with keywords that you may not have thought of yourself, various opportunities emerge at a grassroots level. This goes beyond just work, creating opportunities for individuals with shared challenges to learn from each other and grow together. Quick access to skilled colleagues Specifically, when a new employee is looking for a frontend engineer with expertise in Next.js, they can quickly and easily search in Slack, which makes learning and problem-solving much more efficient. An internal talent database will be built and made searchable as an extension of searching messages on Slack. Revitalizing natural internal interactions There are also grassroots activities for various hobbies within the company. Whether or not they can be called as hobbies, there are interest-based channels ranging from back health to sharing easy-to-make recipes. There are also channels for various sports, games, and, of course, new technologies. As individuals become more easily connected to these channels, non-work-related interactions grow, fostering smoother collaboration in urgent work situations through pre-existing relationships. A System to Support Profile Creation For those who feel unsure about what to write, the Technical PR Group is actively providing support. This approach is more than just gathering information, it is a thoughtful dialogue process designed to unlock each employee's potential. Since the launch of our Tech Blog, we have conducted interviews to highlight employees' talents, provided support in writing articles and preparing presentation materials, and organized events and study sessions. If you are reading this article and have not yet complete your Slack profile, or if you are unsure what to include, please reach out. Let's work together to discover your strengths and share them within the organization! Support includes: Uncovering experience and interest through individual interviews One-on-one conversations help discover potential strengths that even the individual may not be aware of. Templates for creating profiles Even if you are not good at expressing yourself, you can fill it out with confidence. Assistance in verbalization for those who find self-expression difficult Specialized staff offer close support to help individuals appropriately express their strengths and interests. Template: Search results Future Prospects Currently, talent search is conducted manually, but in the future, we aim to develop a skill matching system using AI. By effectively utilizing accumulated data, we envision a more efficient and strategic approach to human resource management. Looking ahead, this will enable a deeper understanding of each employee's potential and link them with the best opportunities. Conclusion The Slack profile is more than just a self-introduction. It is a strategic tool that unlocks an organization's hidden potential by connecting people and is the key to unleashing individual possibilities. By actively sharing your interests, skills, and potential, the possibilities of the entire organization can be expanded. We believe that this small step will eventually lead to a significant transformation.
QAグループの中西です。(技術広報もKINTO FACTORY開発も色々兼務でやっています^^) 今年、私たちKINTOテクノロジーズは「AIファースト」「リリースファースト」を掲げ、QAグループとしてもAIを活用してリリース速度を向上させる取り組みを進めています。 今回は、そんな思いを持つQAメンバーが集まり、 「こんなことができると良いな」 「こんなことをやってみたい!」 という気持ちをワイワイと語り合うブレインストーミングを行いました。 この記事では、そこで出てきた魅力的なアイデアを紹介し、AIとQAがどのような可能性を持っているのかを皆さんと共有したいと思います。 話し合いで見えた課題 QA業務には日々多くの資料が生成されますが、情報量が多すぎるあまり必要な情報を探すのが大変になっています。また、仕様書もプロジェクトや担当者ごとにフォーマットが異なり、共有が難しくなっています。さらに、インシデントに対する振り返りや予防策の仕組みが整っていないため、問題の再発防止にも苦労しています。レビュー作業についても人的負担が非常に高く、効率化が求められています。 AIで実現できる未来 情報の効率的活用(RAG) RAG(Retrieval-Augmented Generation)は、最新の生成AI技術を活用した情報検索・分析の手法です。過去に蓄積された膨大な資料やインシデントのデータから関連性の高い情報を素早く抽出し、適切な情報をユーザーに提示します。例えば、あるインシデントが起きた際、AIが過去の類似事例を瞬時に検索・分析し、即座に役立つ解決策を提示します。まるで、過去の経験を全て記憶している優秀な秘書が、必要なときに瞬時にアドバイスをくれるような活躍を期待できます。すでに金融業界やカスタマーサポート業界などで導入され、顧客対応や問題解決の速度を劇的に向上させています。 仕様・設計の整理と支援 仕様書内の矛盾や抜け漏れをAIが見つけ出し、問題点を明確に整理して提示します。さらに、具体的な仕様書を入力するとAIがその内容を解析し、適切なテストシナリオを自動的に生成します。例えば、ECサイトのカート機能の仕様書を入力すると、AIが「商品追加→数量変更→決済→注文確認」といったシナリオを瞬時に作成。さらに、エラー発生時の対応シナリオや境界値テストシナリオなども自動生成可能です。これにより、人手によるシナリオ作成にかかる時間や手間を大幅に削減でき、QA業務の精度と効率を飛躍的に向上させます。 QAプロセスの自動化と効率化 ユーザー操作ログをAIが分析し、人が見落としてしまいそうな細かなミスも未然に防ぎます。具体的には、ユーザーが頻繁に発生させるエラーや異常操作をAIが抽出し、「特定の画面遷移で起こるエラー」や「入力フォームで頻繁に誤入力される項目」を特定します。これにより、テストシナリオの改善や、潜在的な問題箇所への事前対応が可能になります。また、コンフルでの煩雑なテストケース連番管理をAIが自動化し、手作業による管理ミスや作業時間の大幅な削減を実現します。 インシデント分析と予防 過去に発生したインシデントをAIが分析し、具体的な再発防止策を提示します。例えば、過去にECサイトで起きた「特定ブラウザでの表示崩れ」や「支払い機能の障害」などのインシデントをAIが徹底的に分析。その結果、「特定ブラウザのバージョンごとの挙動確認を定期的に行う」や「決済処理前後のエラーハンドリング強化」といった具体的なアクションを提案します。また、緊急性の高いインシデントが発生した際にはAIが即座にリスクレベルを判定し、迅速な対応が取れるように関係者へ自動通知を行うなど、リアルタイムでの問題解決支援を実現します。 テストデータ作成の効率化 テストに必要なデータをAIが瞬時に生成します。具体的には、新車や中古車のデータ、ユーザー情報など、リアルな業務シナリオに必要な多様なデータを迅速かつ大量に作成可能です。また、SeleniumやAppiumといったブラウザ操作ツールとAIを連携させることで、手動で行っていたブラウザ操作を自動化し、簡単な設定だけで大量のテストデータを短時間で作成できます。この連携により、人的ミスを防ぎつつ、テストデータ作成にかかる工数を劇的に短縮できるため、QAプロセス全体の効率化が実現されます。 ツール連携とプロセス自動化 JIRAやAsanaなどのツールとSlackを連携し、必要な情報をタイムリーに自動通知。多くのツールからの情報を一元化して効率よく管理します。多彩なツールの橋渡し役をAIが担い、プロセスの流れをスムーズにします。 QA専用AIモデルの活用 QA業務専用にチューニングされたChatGPTの活用を検討しています。自社専用のAIモデルを構築することで、AIの応答速度を劇的に向上。さらに、開発者自身がAIを活用して手軽にセルフチェックできる環境づくりを推進します。 今後のアクションプラン AIを活用した情報の整理・統合を最優先で開始 レビュー作業をAI支援で効率化し、人的負荷を軽減 専用AIモデルの開発に向けて継続的なデータ収集を実施 AIによるインシデント分析をプロセス改善に積極的に活用 各種ツール間の連携を自動化し、さらなる業務効率化を実現 一人では実現できないことも、みんなで考えることで新しい道が開けます。今回のブレインストーミングで出たアイデアをきっかけに様々なAIを活用したQA活動を行っていきます。AIと共に歩むQAの新たな可能性を一緒に探ったり私たちと一緒に新しい取り組みをしたいQAエンジニアの皆様、カジュアル面談なども受け付けていますのでお気軽にご連絡お待ちしております。
QAグループの中西です。(技術広報もKINTO FACTORY開発も色々兼務でやっています^^) 今年、私たちKINTOテクノロジーズは「AIファースト」「リリースファースト」を掲げ、QAグループとしてもAIを活用してリリース速度を向上させる取り組みを進めています。 今回は、そんな思いを持つQAメンバーが集まり、 「こんなことができると良いな」 「こんなことをやってみたい!」 という気持ちをワイワイと語り合うブレインストーミングを行いました。 この記事では、そこで出てきた魅力的なアイデアを紹介し、AIとQAがどのような可能性を持っているのかを皆さんと共有したいと思います。 話し合いで見えた課題 QA業務には日々多くの資料が生成されますが、情報量が多すぎるあまり必要な情報を探すのが大変になっています。また、仕様書もプロジェクトや担当者ごとにフォーマットが異なり、共有が難しくなっています。さらに、インシデントに対する振り返りや予防策の仕組みが整っていないため、問題の再発防止にも苦労しています。レビュー作業についても人的負担が非常に高く、効率化が求められています。 AIで実現できる未来 情報の効率的活用(RAG) RAG(Retrieval-Augmented Generation)は、最新の生成AI技術を活用した情報検索・分析の手法です。過去に蓄積された膨大な資料やインシデントのデータから関連性の高い情報を素早く抽出し、適切な情報をユーザーに提示します。例えば、あるインシデントが起きた際、AIが過去の類似事例を瞬時に検索・分析し、即座に役立つ解決策を提示します。まるで、過去の経験を全て記憶している優秀な秘書が、必要なときに瞬時にアドバイスをくれるような活躍を期待できます。すでに金融業界やカスタマーサポート業界などで導入され、顧客対応や問題解決の速度を劇的に向上させています。 仕様・設計の整理と支援 仕様書内の矛盾や抜け漏れをAIが見つけ出し、問題点を明確に整理して提示します。さらに、具体的な仕様書を入力するとAIがその内容を解析し、適切なテストシナリオを自動的に生成します。例えば、ECサイトのカート機能の仕様書を入力すると、AIが「商品追加→数量変更→決済→注文確認」といったシナリオを瞬時に作成。さらに、エラー発生時の対応シナリオや境界値テストシナリオなども自動生成可能です。これにより、人手によるシナリオ作成にかかる時間や手間を大幅に削減でき、QA業務の精度と効率を飛躍的に向上させます。 QAプロセスの自動化と効率化 ユーザー操作ログをAIが分析し、人が見落としてしまいそうな細かなミスも未然に防ぎます。具体的には、ユーザーが頻繁に発生させるエラーや異常操作をAIが抽出し、「特定の画面遷移で起こるエラー」や「入力フォームで頻繁に誤入力される項目」を特定します。これにより、テストシナリオの改善や、潜在的な問題箇所への事前対応が可能になります。また、コンフルでの煩雑なテストケース連番管理をAIが自動化し、手作業による管理ミスや作業時間の大幅な削減を実現します。 インシデント分析と予防 過去に発生したインシデントをAIが分析し、具体的な再発防止策を提示します。例えば、過去にECサイトで起きた「特定ブラウザでの表示崩れ」や「支払い機能の障害」などのインシデントをAIが徹底的に分析。その結果、「特定ブラウザのバージョンごとの挙動確認を定期的に行う」や「決済処理前後のエラーハンドリング強化」といった具体的なアクションを提案します。また、緊急性の高いインシデントが発生した際にはAIが即座にリスクレベルを判定し、迅速な対応が取れるように関係者へ自動通知を行うなど、リアルタイムでの問題解決支援を実現します。 テストデータ作成の効率化 テストに必要なデータをAIが瞬時に生成します。具体的には、新車や中古車のデータ、ユーザー情報など、リアルな業務シナリオに必要な多様なデータを迅速かつ大量に作成可能です。また、SeleniumやAppiumといったブラウザ操作ツールとAIを連携させることで、手動で行っていたブラウザ操作を自動化し、簡単な設定だけで大量のテストデータを短時間で作成できます。この連携により、人的ミスを防ぎつつ、テストデータ作成にかかる工数を劇的に短縮できるため、QAプロセス全体の効率化が実現されます。 ツール連携とプロセス自動化 JIRAやAsanaなどのツールとSlackを連携し、必要な情報をタイムリーに自動通知。多くのツールからの情報を一元化して効率よく管理します。多彩なツールの橋渡し役をAIが担い、プロセスの流れをスムーズにします。 QA専用AIモデルの活用 QA業務専用にチューニングされたChatGPTの活用を検討しています。自社専用のAIモデルを構築することで、AIの応答速度を劇的に向上。さらに、開発者自身がAIを活用して手軽にセルフチェックできる環境づくりを推進します。 今後のアクションプラン AIを活用した情報の整理・統合を最優先で開始 レビュー作業をAI支援で効率化し、人的負荷を軽減 専用AIモデルの開発に向けて継続的なデータ収集を実施 AIによるインシデント分析をプロセス改善に積極的に活用 各種ツール間の連携を自動化し、さらなる業務効率化を実現 一人では実現できないことも、みんなで考えることで新しい道が開けます。今回のブレインストーミングで出たアイデアをきっかけに様々なAIを活用したQA活動を行っていきます。AIと共に歩むQAの新たな可能性を一緒に探ったり私たちと一緒に新しい取り組みをしたいQAエンジニアの皆様、カジュアル面談なども受け付けていますのでお気軽にご連絡お待ちしております。
This article the entry for day 9 in the 2024 KINTO Technologies Advent Calendar 🎅🎄 KINTO Technologies is an engineer-driven organization with a team of over 300 members. In an increasingly complex business environment, we continuously seek to balance organizational efficiency and creativity. With dispersed locations and increase in remote work, cross-departmental communication has become more limited, making it essential to address this challenge seriously. This article, written by Nakanishi from the Development Relations Group, discusses the first step in revitalizing the organization by using Slack, our primary tool for daily communication and how we're building a talent search system based on Slack. Talent search is a system that allows you to search for data on employees' skills. Why Is Talent Search Needed? While working efficiently is important, innovation often comes from unexpected encounters, and even seemingly mundane conversations can play a crucial role In our organization, the intense focus on daily tasks we often tend to overlook “tacit knowledge” and “latent potential”. For example, even if you think, "Is there anyone with this skill?", you don't know who to consult. As our organization grows, this information asymmetry has become a serious challenge. To tackle this challenge directly, we decided to strategically utilize Slack profiles and take a proactive approach. Benefits of Utilizing Slack Profiles From the Perspective of the Developer Relations (DevRel) Group Discovering previously unnoticed talent There are many individuals whose talents and potential remain unnoticed within the organization. Although members of the Technical PR Group communicate with employees daily, it is still challenging to fully understand everyone. Slack profiles serve as a new tool to make these "hidden talents" visible. Accelerating project support We hope that being able to quickly identify people with the right skills will dramatically improve the speed of project launch and problem solving Until now, finding someone with a specific skill often relied on word-of-mouth searches within the company. However, establishing a network that enables direct communication without relying on hub organizations like us is essential for the organization's future growth. Promoting cross-departmental collaboration Until now, the Technical PR Group has organized various initiatives, such as in-house study sessions, exchange events, and study sessions inviting external lecturers. As a result, natural communication has emerged within the company, creating a chain reaction where initial connections lead to an expanding network, new collaborations are established every day. This Slack initiative will surely spur this trend. Benefits for All Employees Expanding opportunities for career growth Clearly expressing your skills and interests opens up new possibilities that you may not have noticed before. By connecting with keywords that you may not have thought of yourself, various opportunities emerge at a grassroots level. This goes beyond just work, creating opportunities for individuals with shared challenges to learn from each other and grow together. Quick access to skilled colleagues Specifically, when a new employee is looking for a frontend engineer with expertise in Next.js, they can quickly and easily search in Slack, which makes learning and problem-solving much more efficient. An internal talent database will be built and made searchable as an extension of searching messages on Slack. Revitalizing natural internal interactions There are also grassroots activities for various hobbies within the company. Whether or not they can be called as hobbies, there are interest-based channels ranging from back health to sharing easy-to-make recipes. There are also channels for various sports, games, and, of course, new technologies. As individuals become more easily connected to these channels, non-work-related interactions grow, fostering smoother collaboration in urgent work situations through pre-existing relationships. A System to Support Profile Creation For those who feel unsure about what to write, the Technical PR Group is actively providing support. This approach is more than just gathering information, it is a thoughtful dialogue process designed to unlock each employee's potential. Since the launch of our Tech Blog, we have conducted interviews to highlight employees' talents, provided support in writing articles and preparing presentation materials, and organized events and study sessions. If you are reading this article and have not yet complete your Slack profile, or if you are unsure what to include, please reach out. Let's work together to discover your strengths and share them within the organization! Support includes: Uncovering experience and interest through individual interviews One-on-one conversations help discover potential strengths that even the individual may not be aware of. Templates for creating profiles Even if you are not good at expressing yourself, you can fill it out with confidence. Assistance in verbalization for those who find self-expression difficult Specialized staff offer close support to help individuals appropriately express their strengths and interests. Template: Search results Future Prospects Currently, talent search is conducted manually, but in the future, we aim to develop a skill matching system using AI. By effectively utilizing accumulated data, we envision a more efficient and strategic approach to human resource management. Looking ahead, this will enable a deeper understanding of each employee's potential and link them with the best opportunities. Conclusion The Slack profile is more than just a self-introduction. It is a strategic tool that unlocks an organization's hidden potential by connecting people and is the key to unleashing individual possibilities. By actively sharing your interests, skills, and potential, the possibilities of the entire organization can be expanded. We believe that this small step will eventually lead to a significant transformation.
This article is the entry for day 8 in the KINTO Technologies Advent Calendar 2024 🎅🎄 Introduction Hello. My name is Nakamoto, and I work in the Mobile App Development Group. I usually work from Osaka and collaborate with team members in Tokyo on iOS development for the KINTO Unlimited app . This article deep dives into the process of enhancing the architecture of the KINTO Unlimited iOS. The app's architecture evolved gradually, moving through three different phases, and ultimately transitioning to its current structure. I will adress its design aspect and the challenges encountered at each stage below. The 1st Generation Architecture Adopted the VIPER architechture Implemented all screens using UIKit + xib/storyboard Used Combine to update views Chose an architecture with a proven track record within the company due to the short timeline for the first release Design of the 1st Gen flowchart TD id1(ViewController) -- publish --> id2(ViewModel) -- subscribe --> id1 id2 -- request --> id3(Interactor) id1 -- apply view property --> id4(UIView) id1 -- transition --> id5(Router) ViewController Notify ViewModel of an event Subscribe to outputs triggered by events from the ViewModel. Update the View based on the subscription results and invoke the Router to handle screen transitions. ViewModel Use Combine to update the state reactively. Transform an event Publisher to output the View state through a Publisher. Interactor Perform requests to API and internal DB Router Perform transitions to other screens UIView Layout using code/xib/storyboard Issue with the 1st Gen Layouts built with UIKit come with high development costs and are challenging to modify, particularly when xib/storyboard is used. Transitioning to SwiftUI would significantly enhance the process! The 2nd Generation Architecture Transitioning from UIKit to SwiftUI Replaced UIKit layouts with SwiftUI to enhance development efficiency. Integrated a SwiftUI View into a ViewController using UIHostingController. UIPerform screen transitions using UIKit as usual. At that time, SwiftUI's screen transition API was unstable, so we decided to continue using UIKit. Focus on switching to SwiftUI Making too many changes at once could raise concerns about potential degradation of functional specifications. Design of the 2nd Gen flowchart TD id1(ViewController) -- input --> id2(ViewModel) -- output --> id1 id2 -- request --> id6(Interactor) id1 -- mapping --> id3(ScreenModel) -- publish --> id1 id3 -- publish --> id4(View) -- publish --> id3 id1 -- transit --> id5(Router) ViewController Implement HostingControllerInjectable protocol and add SwiftUI View. Subscribe to the ViewModel's output and update the ScreenModel (ObservableObject) accordingly. Subscribe to the ViewModel output and the ScreenModel Publisher, then utilize the Router to handle screen transitions. ScreenModel An ObservableObject that manages the state of the View. ViewModel/ Interactor/ Router Same features as the 1st Generation Issue with the 2nd Gen State management is split between the ViewModel and ScreenModel, leading to fragmented logic and increased development and maintenance costs. Issues from the 1st generation Using Combine for reactive state changes raises concerns about maintainability and, due to the extensive codebase, can result in reduced readability. Having a single ViewModel for each screen can result in it becoming excessively large on multi-functional screens. Therefore, transitioning away from Combine and ViewModel would be a highly beneficial improvement! The 3rd Generation Architecture Switched from a Combine-driven ViewModel to a ViewStore-based architecture that centralizes state management Implemented a structure that directly updates the ObservableObject with event results, eliminating the need for AnyPublisher. Utilized async/await to achieve reactive state changes without relying on Combine. State management logic can be modularized by dividing it into functions. Design of the 3rd Gen flowchart TD subgraph ViewStore id1(ActionHandler) -- update --> id2(State) end id2 -- bind --> id5(View) -- publish action --> id1 id1 -- publish routing --> id3(ViewController) -- publish action --> id1 id3 -- transit --> id4(Router) id1 -- request --> id6(Interactor) ViewStore State An ObservableObject that manages the state of the View and is used within a SwiftUI View. Action Use an enum to replicate the functionality of the INPUT in the transform method of a traditional ViewModel. ActionHandler A handler that accepts an Action as an argument and updates the State accordingly. Implement using async/await ViewController Subscribe to routerSubject and utilize the Router to handle screen transitions. Interactor / Router Same as 2nd Generation Splitting ActionHandler On multi-functional screens, separating the ActionHandler and State can significantly improve code readability and maintainability. Binding the actionPublisher of one State to another State allows actions to be propagated from one View to another. flowchart TD subgraph ViewStore id2 -- action --> id1 id1(ActionHandler1) -- update --> id2(State1) id5 -- action --> id4 id4(ActionHandler2) -- update --> id5(State2) id8 -- action --> id7 id7(ActionHandler3) -- update --> id8(State3) end subgraph Parent View id3 id6 id9 end id2 -- bind --> id3(View1) id5 -- bind --> id6(View2) id8 -- bind --> id9(View3) Conclusion We have been pursuing this initiative for over a year, alongside ongoing feature development. Now, nearly all of the source code has been transitioned to the 3rd Generation Architecture. As a result, the code has become more readable and maintainable, paving the way for smoother future development. We are excited to continue making improvements!
2025年2月20日に初開催された「Appium Meetup Tokyo」が、Autify社東京オフィスにて開催されました。当日は約10名が現地参加し、オンラインでも多くの参加者が集まりました。 オープニングとアイスブレイク イベントはAutify社の tsueeemura さんのユーモア溢れる軽快なトークでスタートしました。オンライン接続の確認も兼ねて、「今日の夕飯何にしますか?」という質問があり、「今日はお鍋です」という回答が場の雰囲気を和ませました。 Autify社「Appiumプラグインの活用事例」 最初の登壇はAutify社のモバイル製品開発担当 rerorero さん。 Autify社が提供する「Autify NoCode Mobile」は、コードを書かずにモバイルアプリのテスト自動化が簡単に実現できるクラウドサービスです。プログラミングの専門知識がなくても直感的なインターフェースでテストを記録し、自動再実行が可能です。これにより、開発者や非エンジニアでも迅速にテスト環境を整備できる点が最大の利点です。さらに、クラウド上で実機やシミュレーターが利用でき、自社での機材調達が不要となり、設備投資を大幅に削減できることも特徴の一つです。 ただし、大量のUI要素が存在する画面では動作が著しく遅くなる課題があり、通常数秒で完了するはずのタップ操作が最大40秒もかかる問題がありました。 reroreroさんはこの問題を解決するため、Facebookが開発した「 IDB(iOS Development Bridge) 」を導入しました。IDBはCLIベースで高速にiOSのシミュレーターや実機を操作するオープンソースツールで、Core Simulator Serviceに直接イベントを送ることで反応速度を劇的に改善します。Appiumのプラグインとして統合し、サーバー間の複雑なネットワーク設定なしで直接利用可能な仕組みを構築した結果として、40秒の操作が40ミリ秒に短縮され、約1,000倍のパフォーマンス向上を実現したそうです。 登壇の詳細ポイント Appiumプラグインの導入方法とJavaScriptを使った実装例 IDBが高速なタップ操作を可能にする技術的仕組み(コアシミュレーターサービスへのイベント送信) パフォーマンス改善の実際のデモンストレーション プラグインは以下のような書き方で実装するそうです KINTOテクノロジーズ社「効率的なアプリ自動化のためのガイドラインと実践方法」 続いて、KINTOテクノロジーズの岡さんとパンヌさんが、自動化テスト環境の構築方法と成果を発表しました。 弊社では、多様な端末やOSの組み合わせによる手動テストの負荷が増大していました。そこで、開発初期段階からQAチームと開発チームが協力し、統一されたテスト専用IDを設定する方法を導入しました。これにより、レイアウト変更に伴うXPATHの修正負荷を軽減し、テストの安定性が大幅に向上しました。 また、テスト結果はSlackでリアルタイム通知され、詳細なログや動画をBOXで管理する仕組みを構築しました。これにより、関係者全員が容易にテスト状況を確認できる環境を実現しています。 登壇の詳細ポイント 開発プロセスにおける自動テスト意識の統合 テスト専用IDの設定前後でのメンテナンス負荷の比較 SlackおよびBOXを活用したテスト結果の効率的管理方法 Github Copilotを活用したコーディングの効率化 登壇資料 https://speakerdeck.com/kintotechdev/xiao-lu-de-naapurizi-dong-hua-notamenogaidoraintoshi-jian-fang-fa 📌 参加者アンケートから見るE2Eテストの現状と関心トピック 今回、Meetupにご参加いただいた皆さんを対象にアンケートを実施しました。その結果から得られた興味深い傾向を紹介します。 ① 参加者の職種割合 参加者の半数以上(54.1%)はQAエンジニアでしたが、SET/SDET、Webやモバイルアプリケーションエンジニアなど多様な職種の方にもお越しいただきました。 ② Appiumの利用経験 Appiumに関しては、半数以上(55.7%)が「使ったことがない」と回答しており、新規ユーザーや導入を検討中の方が多いことが分かります。一方で一定の経験(1年以上)を持つ方もおり、利用の成熟度には幅がありました。 ③ E2Eテストの実務経験 E2Eテスト全般では、「1〜3年(27.9%)」や「5年以上(24.6%)」といった比較的経験豊富な層が半数を超えており、実務での活用が広がっている状況が確認できました。 ④ 最も関心のあるトピック 参加者が特に興味を持ったトピックとしては以下のようなものが挙げられました。 Appiumによるテスト導入の成果や事例 Appiumの活用シナリオや注意点、実際の苦労話 CI/CDへの組み込みや、クロスプラットフォーム(React Native、Flutterなど)への対応状況 今回のアンケート結果を踏まえて、今後も皆さまの関心やニーズに沿った情報をお届けしていきたいと思います。 ネットワーキングと今後の展望 セッション後のネットワーキングではピザを囲んで積極的な交流が行われ、新しいアイデアや協力関係が生まれました。Appium Meetup Tokyoは今後も定期的に開催予定で、登壇者や運営メンバーを募集しています。ぜひ次回もご参加ください。 参加を検討している方へ モバイルアプリの自動テストをこれから本格的に導入したい方 Appiumに興味があるが具体的な事例やノウハウが欲しい方 CI/CDと組み合わせた運用に関心があるエンジニアやQA担当の方 他社事例を参考に自社のテスト文化を改善したい方 上記に当てはまる方は、ぜひAppium Meetup Tokyoで最新の知見を共有し合いましょう。今後の告知や詳細情報は @AutifyJapan や @KintoTech_Dev でさせて頂きます。ご質問やご要望などがございましたら、お気軽にお寄せください。 次回の「Appium Meetup Tokyo #2」でお会いできることを心より楽しみにしています。 アーカイブ配信 https://www.youtube.com/watch?v=zV4WbClGquE
2025年2月20日に初開催された「Appium Meetup Tokyo」が、Autify社東京オフィスにて開催されました。当日は約10名が現地参加し、オンラインでも多くの参加者が集まりました。 オープニングとアイスブレイク イベントはAutify社の tsueeemura さんのユーモア溢れる軽快なトークでスタートしました。オンライン接続の確認も兼ねて、「今日の夕飯何にしますか?」という質問があり、「今日はお鍋です」という回答が場の雰囲気を和ませました。 Autify社「Appiumプラグインの活用事例」 最初の登壇はAutify社のモバイル製品開発担当 rerorero さん。 Autify社が提供する「Autify NoCode Mobile」は、コードを書かずにモバイルアプリのテスト自動化が簡単に実現できるクラウドサービスです。プログラミングの専門知識がなくても直感的なインターフェースでテストを記録し、自動再実行が可能です。これにより、開発者や非エンジニアでも迅速にテスト環境を整備できる点が最大の利点です。さらに、クラウド上で実機やシミュレーターが利用でき、自社での機材調達が不要となり、設備投資を大幅に削減できることも特徴の一つです。 ただし、大量のUI要素が存在する画面では動作が著しく遅くなる課題があり、通常数秒で完了するはずのタップ操作が最大40秒もかかる問題がありました。 reroreroさんはこの問題を解決するため、Facebookが開発した「 IDB(iOS Development Bridge) 」を導入しました。IDBはCLIベースで高速にiOSのシミュレーターや実機を操作するオープンソースツールで、Core Simulator Serviceに直接イベントを送ることで反応速度を劇的に改善します。Appiumのプラグインとして統合し、サーバー間の複雑なネットワーク設定なしで直接利用可能な仕組みを構築した結果として、40秒の操作が40ミリ秒に短縮され、約1,000倍のパフォーマンス向上を実現したそうです。 登壇の詳細ポイント Appiumプラグインの導入方法とJavaScriptを使った実装例 IDBが高速なタップ操作を可能にする技術的仕組み(コアシミュレーターサービスへのイベント送信) パフォーマンス改善の実際のデモンストレーション プラグインは以下のような書き方で実装するそうです KINTOテクノロジーズ社「効率的なアプリ自動化のためのガイドラインと実践方法」 続いて、KINTOテクノロジーズの岡さんとパンヌさんが、自動化テスト環境の構築方法と成果を発表しました。 弊社では、多様な端末やOSの組み合わせによる手動テストの負荷が増大していました。そこで、開発初期段階からQAチームと開発チームが協力し、統一されたテスト専用IDを設定する方法を導入しました。これにより、レイアウト変更に伴うXPATHの修正負荷を軽減し、テストの安定性が大幅に向上しました。 また、テスト結果はSlackでリアルタイム通知され、詳細なログや動画をBOXで管理する仕組みを構築しました。これにより、関係者全員が容易にテスト状況を確認できる環境を実現しています。 登壇の詳細ポイント 開発プロセスにおける自動テスト意識の統合 テスト専用IDの設定前後でのメンテナンス負荷の比較 SlackおよびBOXを活用したテスト結果の効率的管理方法 Github Copilotを活用したコーディングの効率化 登壇資料 https://speakerdeck.com/kintotechdev/xiao-lu-de-naapurizi-dong-hua-notamenogaidoraintoshi-jian-fang-fa 📌 参加者アンケートから見るE2Eテストの現状と関心トピック 今回、Meetupにご参加いただいた皆さんを対象にアンケートを実施しました。その結果から得られた興味深い傾向を紹介します。 ① 参加者の職種割合 参加者の半数以上(54.1%)はQAエンジニアでしたが、SET/SDET、Webやモバイルアプリケーションエンジニアなど多様な職種の方にもお越しいただきました。 ② Appiumの利用経験 Appiumに関しては、半数以上(55.7%)が「使ったことがない」と回答しており、新規ユーザーや導入を検討中の方が多いことが分かります。一方で一定の経験(1年以上)を持つ方もおり、利用の成熟度には幅がありました。 ③ E2Eテストの実務経験 E2Eテスト全般では、「1〜3年(27.9%)」や「5年以上(24.6%)」といった比較的経験豊富な層が半数を超えており、実務での活用が広がっている状況が確認できました。 ④ 最も関心のあるトピック 参加者が特に興味を持ったトピックとしては以下のようなものが挙げられました。 Appiumによるテスト導入の成果や事例 Appiumの活用シナリオや注意点、実際の苦労話 CI/CDへの組み込みや、クロスプラットフォーム(React Native、Flutterなど)への対応状況 今回のアンケート結果を踏まえて、今後も皆さまの関心やニーズに沿った情報をお届けしていきたいと思います。 ネットワーキングと今後の展望 セッション後のネットワーキングではピザを囲んで積極的な交流が行われ、新しいアイデアや協力関係が生まれました。Appium Meetup Tokyoは今後も定期的に開催予定で、登壇者や運営メンバーを募集しています。ぜひ次回もご参加ください。 参加を検討している方へ モバイルアプリの自動テストをこれから本格的に導入したい方 Appiumに興味があるが具体的な事例やノウハウが欲しい方 CI/CDと組み合わせた運用に関心があるエンジニアやQA担当の方 他社事例を参考に自社のテスト文化を改善したい方 上記に当てはまる方は、ぜひAppium Meetup Tokyoで最新の知見を共有し合いましょう。今後の告知や詳細情報は @AutifyJapan や @KintoTech_Dev でさせて頂きます。ご質問やご要望などがございましたら、お気軽にお寄せください。 次回の「Appium Meetup Tokyo #2」でお会いできることを心より楽しみにしています。 アーカイブ配信 https://www.youtube.com/watch?v=zV4WbClGquE
This is article is the entry for day 8 in the KINTO Technologies Advent Calendar 2024 🎅🎄 Hello, this is HOKA from the Manabi-no-Michi-no-Eki (Learning Roadside Station) Team. It has been nearly a year since the team was launched, so I will be writing a blog post to reflect on its first twelve months. Our Thoughts and Aspirations One Year Ago The team was formed exactly one year ago, at the end of November 2023, when Kin-chan, Nakanishi, and I came together with the goal of making the company’s various study sessions more engaging and dynamic. Shortly after the beginning of 2024, we regrouped and created an inception deck. Here is the result: As a "roadside station" where study sessions converge, we aim to enhance internal activities focused on learning and knowledge sharing. Internal communications Keeping everyone informed about the study sessions being held. Sharing what study sessions are like. Supporting study sessions Providing guidance to those who have concerns, such as: Wanting to start study sessions but not knowing where to begin. Struggling to make their existing study sessions more engaging. There are more details in the Tech Blog post about how it all got started . What We Did in the First Six Months We started by sharing updates on the team activities during KTC’s monthly all-hands meetings, commonly known as HQ meetings. I imagine the slide below has become a familiar sight to everyone in the company. Activity summary Providing a space for discussing study sessions as a whole—offering advice on starting them, addressing challenges, and finding solutions. Popping Into Next Door Study Sessions – an initiative where the administration team visits various study sessions to engage and support participants. ​ KTC Podcast: interviews with study session organizers! Sharing voices from within the company, capturing both the messages and the atmosphere of the study sessions. Tech Blog: Articles in the Tech Blog showcasing the various study sessions at KTC and sharing experiences of participating in them. New activities — Part 1 After about six months, we started to see people supporting and advocating for our activities. We faced the challenge of making it easier for people to search for available study sessions. Fortunately, an engineer from the Mobile App Development Group developed a Slack-based search system to help solve this issue. This allowed people to search for study sessions in the Slack channel by interacting with a character named “Manabyi.” For more details, check out the developer’s blog post. https://blog.kinto-technologies.com/posts/2024-12-04_manabyi/ New activities — Part 2 We also faced the challenge of making study session materials and videos accessible to everyone at any time. As we were exploring solutions, an engineer from the Corporate IT Group proactively reached out and developed a SharePoint-based portal site for the study sessions. It is called the “Manabi-no-Michi-no-Eki Portal.” What was once a set of plain, unorganized folders has now been transformed into a YouTube-like experience. With all the videos and materials in one place, people can: Watch recordings or review materials from study sessions they missed. Rewatch a session they attended to reinforce what they learned. Other Highlights That Made Us Happy We began receiving requests from organizers seeking discussions on improving their study sessions. When we invited people to be featured on the podcast, they all eagerly agreed to participate. The term “Manabi-no-Michi-no-Eki” was featured on a poster for a company-wide event. Internal materials from group companies included information about Manabi-no-Michi-no-Eki as part of introducing KTC. Less than a year after starting, we never would have imagined that our activities would be reaching not only our own company but also group companies. Whenever employees spontaneously express their appreciation for our team’s activities, it gives us a tremendous boost of motivation. Joining the Developer Relations Group In September 2024, Manabi-no-Michi-no-Eki officially became part of the Developer Relations Group. What is the Developer Relations Group? In 2022, KINTO Technologies launched its Tech Blog and established a platform for engineers to share their knowledge through external events and internal study sessions. Delivering results through work is a form of output in itself, but we believe that study sessions and the Tech Blog also play a crucial role in providing engineers with valuable opportunities to share their knowledge and insights. The Technology Developer Relations Group has created outlets for output that can be described as being “between work duties.” When we launched Manabi-no-Michi-no-Eki at the end of 2023, it created a learning forum that fit into the space "between work duties"—essentially, a space for input. This naturally aligned with the activities of the Technology Public Relations Group. Notably, part of the group's founder, Nakanishi’s, vision was to support engineers' growth by guiding them from input to output. So, in a way, these two initiatives may have never truly been separate to begin with. What the Manabi-no-Michi-no-Eki Team will do in the future Please do check out Nakanishi’s TechBlog posts. https://blog.kinto-technologies.com/posts/2024-12-03-the-next-goal/
This article is the entry for day 7 in the KINTO Technologies Advent Calendar 2024 🎅🎄 Introduction Hello! I'm Iki, from the Cloud Infrastructure Group at the Osaka Tech Lab. In this article, I’ll share how the Osaka Tech Lab team applied the MVP development method to build a chat API powered by generative AI. What is MVP (Minimum Viable Product) Development? This method consists of first creating a product that has the bare minimum of features, then verifying and improving it while getting feedback from users, in this case, the Product Manager (PdM) who originally suggested creating it. I think it was an extremely efficient development method for handling the rough requirements we had for this project. What Inspired Us to Create a Chat AI The idea came about naturally. KINTO Technologies has offices in Tokyo, Nagoya, and Osaka (Osaka Tech Lab), but nearly 80% to 90% of its employees are based in Tokyo. Since work isn't assigned by location, everyone, regardless of their office, contributes to Tokyo-led projects. This setup isn't an issue at all —if anything, Osaka team members are particularly close-knit compared to those at other locations! (At least, in my opinion.) Still, at some point, the Osaka members started thinking wouldn’t it be great to work on something uniquely Osaka-based? Around that time, they happened to cross paths with a Product Manager who was exploring the potential of chat systems powered by generative AI. Theme For this project, we decided to use MVP development to verify whether chat using generative AI was a viable idea. However, the term “chat” covers a wide range of situations, with customer service and reporting to bosses also being examples. Rather than tense, stiff conversations, we focused on whether it could emulate the kind of natural, relaxed way that people chat with family and friends. What We’ve Managed to Create So Far Overall structure Note: Deciding that it would be better if there was a robot in the chat, we used BOCCO emo, a commercial robot by Yukai Engineering Inc. Azure schematic ![Azure schematic (simple version)](/assets/blog/authors/norio_iki/chmcha_azure_architecture.png =700x) What We Considered When Creating the Chat AI Time The goal this time was to explore whether conversations powered by generative AI could work. However, even if we succeeded by investing a lot of time and effort, generative AI-powered conversations already exist in the world, so achieving that is a given. In addition, the theme centers on conversation, a natural and intuitive part of human interaction. However, we soon realized that we had chosen an extremely insightful theme, sparking a wealth of ideas for what we aspire to create. Consequently, there would be no end to what we could do if we had the time. Thinking that it wasn't worth spending too much time to create an MVP, we proceeded with the creation with an aim of completing it within the timeframe we had set. How much time we spent on MVP creation Considering the requirements and creating the MVP 2 days Verifying and improving it while getting feedback 15 hours (max) What Did We Actually Do? Considering the requirements and creating the MVP At the beginning, we didn't selected an environment to develop the MVP, while lacking any knowledge of the way to create a generative AI-powered system. With things as they were, before we got as far as verifying the theme (i.e., whether natural, carefree chat can be achieved), we would have first had to start from verifying how to create a generative AI system. However, for expertise about generative AI systems, we got help from ZEN ARCHITECTS , the company that provides the Azure Light-up program. This created a situation that would enable us to focus on the theme. Besides accompanying us along the way as we were building the generative AI system, ZEN ARCHITECTS also gave us ideas based on actual experience (for example, things we should be careful about when using generative AI with a theme as rough as ours), and pulled us along so that we managed to complete the MVP in 2 days. Verifying and improving it while getting feedback Based on comments from actually trying it out, the development members discussed and decided on what improvements to make. We added a feature to let you chat from your current location, and in order to fix issues with robots that only ever chatted in cafes, we spent a month (15 hours) running a cycle of getting feedback on things people noticed about the prompts and so on. To verify the feature for chatting from your current location, we did not simply do it all from the office by changing our location data, but actually went to different places physically. Since KINTO is a car subscription provider, we also did fittingly unique real-time updates, such as ones deployed while receiving feedback in a car. Creating it in-house means we can do things like this! (We repeatedly ran verifications and made improvements with this attitude to guide us!) ![Deployment while driving](/assets/blog/authors/norio_iki/drive_deploy.jpg#right =400x) Conclusion The chat API using generative AI that we created in this project is currently undergoing in-house verification regarding its future potential. If its value exceeds how much it is expected to cost in the future, we plan to push ahead with developing it further. That said, continued development might get canceled if it is deemed to be premature. However, even if it does not get continued, the things we confirmed and experience in a new area (Azure development of generative AI systems) we gained will still remain as outcomes of the project. Those outcomes will fuel new ideas. (For example, they can be fed back into existing systems.) Even if this project does not get continued, I will not think of as a failure. I think we can create an environment that will enable us to constantly move forward and run the innovation cycle, in order to do MVP development that will not fail. I would like to push forward with tackling the challenges that arise with MVPs as an end unto itself! Also, if you want to know a little more about the details, ZEN ARCHITECTS have published a case study on the project, so please check that out. Azure Light-up
Hello. I'm Shimamura from the Platform Group's Platform Engineering team. I'm responsible for the development, operation, and deployment of tools (taking on roles similar to a team leader. Recently, I've also started working on scratch development as well, which has me struggling a bit with things like Scrum and programming languages) based on platform engineering principles. This article is the entry for day 4 in the KINTO Technologies Advent Calendar 2024 🎅🎄 Background There is a thing called SBOM (Software Bill of Materials). In 2024, the Ministry of Economy, Trade and Industry emphasized the importance of utilizing this for security measures . Similarly, back in 2021, the United States also discussed making it a standard practice. However, introducing new SaaS, OSS, and other tools for this purpose might seem like a significant hurdle. KINTO Technologies leverages OSS and incorporates it into the CI/CD pipeline to create and manage a standardized SBOM. In the context of DevSecOps, we also perform vulnerability scanning EOL inspection in conjunction with SBOM generation. I'll introduce "Minimal Start" and provide examples of improvements made along the way. Pros and Cons The most important thing is having visibility into what is being used. Some time ago, you may remember the vulnerability of log4j. There was an inquiry asking, "We don't use it, do we?" At that time, we communicated the issue by checking configuration files or applying common temporary workaround settings, but now you can find out in a single search. Pros EOL/SBOM management can be started for free ! 👌 There are paid services such as Yamory(Cloud Service) and BlackDuck . There is also SBOM-TOOL provided by Microsoft for SBOM generation. Paid software or SaaS services come with application processes and other hassles. The tools we use are available as GitHub Actions, making them easy to use. It can be run locally, so there are many potential use cases to explore. Cons Many of the tools, like EOL and others, are supported by volunteers. Tools like xeol and syft are frequently updated, and sometimes file inconsistencies occur due to version changes. Tool List Name Function Overview Syft SBOM generation A software provided by Anchore to generate SBOMs from files and container images. Both CycloneDX and SPDX, the standard SBOM format, are supported, but note that the standard is Syft's proprietary format. At KINTO Technologies, we use CycloneDX in XML format for output. Because with JSON, if the version changes, the configuration will change considerably and consideration will increase when importing. XEOL EOL Scanner A scanner to determine whether the EOL provided by XEOL is included. The internal configuration is based on Syft and is determined by matching the information in endoffile.date . The major languages and operating systems are supported, and the response to issues is impressively quick. While SaaS is also available, we'll use OSS for this case. Trivy Vulnerability Scanner A vulnerability scanner provided by aqua . Although Anchore also offers a vulnerability scanner called Grype , which pairs well with Syft, we chose Trivy instead because its behavior on CI/CD pipelines (e.g., display) is more favorable for vulnerability detection. It can scan a wide range of targets, including files, repositories, container images, and SBOMs, making it versatile. While it can also generate SBOMs, since XEOL's core relies on Syft, we opted to use Trivy exclusively for vulnerability scanning this time, considering compatibility. GitHubActions CICD tool The CI/CD tool included in GitHub. At KINTO Technologies, we utilize GitHub Actions for tasks such as building and releasing applications SBOM management incorporates SBOM generation into the workflow at the timing of container creation. CMDB (in-house production) CMDB Configuration Management Database。 A configuration management database. Since rich functions were unnecessary, KINTO Technologies has developed an in-house CMDB. Recent additions include repository information management, EOL information, and SBOM packages to be retrieved and searched. Workflow Diagram Excerpt Pipeline (GitHub Actions) :::message I excluded Container Build and Push steps, as their timing is left to individual judgment. Since the target of Trivy's vulnerability scan is images, the build process is assumed to occur before this excerpt. ::: Basically, This task should be executed during the Deployment Phase rather than during the Application Build Phase. While version management for SBOM files was an option, we chose to overwrite them, as the latest version is deemed sufficient. Note that incorporating into the Build will result in an SBOM that does not reflect the container actually present in the workload. The reason the pipeline calls XEOL twice is to display logs to GitHub Action and for file generation. Since the modes appear to be different, a single unified operation wasn't possible, we decided to separate them. ## Vulnerability scanning with Trivy - name: Run Trivy vulnerability scanner uses: aquasecurity/trivy-action@master with: image-ref: '${{ ImageName }}:${{ IMAGETAG }}' format: 'table' exit-code: '0' ## If you want to proceed with ImageBuild/Push despite vulnerabilities, set this to "0" ignore-unfixed: false vuln-type: 'os' ## If you want to include Java, etc., add "library" severity: 'CRITICAL,HIGH' ## SBOM generation with SYFT - name: Run Syft make sbom files(format cyclone-dx) uses: anchore/sbom-action@v0 with: image: '${{ ImageName }}:${{ IMAGETAG }}' format: cyclonedx artifact-name: "${{ github.event.repository.name }}-sbom.cyclonedx.xml" output-file: "${{ github.event.repository.name }}-sbom.cyclonedx.xml" upload-artifact-retention: 5 ## Artifact expiration date ## EOL library detection (display in WF) and file creation from SBOM in XEOL - name: Run XEOL mw/sw EOL scanner from sbom file uses: noqcks/xeol-action@v1.1.1 with: sbom: "${{ github.event.repository.name }}-sbom.cyclonedx.xml" output-format: table fail-build: false - name: Run XEOL mw/sw EOL scanner from sbom file and Output file uses: noqcks/xeol-action@v1.1.1 id: xeol with: sbom: "${{ github.event.repository.name }}-sbom.cyclonedx.xml" output-format: json fail-build: false ## AWS credential settings (SBOM) - name: AWS credentials uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: ${{ S3_ACCOUNT_ROLE }} aws-region: ${{ AWS_REGION }} ## Save SBOM/EOL in the Team's S3Bucket to be managed ## Extracted with Cut, as it is hierarchical in S3 by image name or repository name. - name: SBOM and EOL file sync to s3 bucket run: | ECRREPOS=`echo ${{ ImageName }} | cut -d "/" -f 2,3` echo $ECRREPOS aws s3 cp ${{ github.event.repository.name }}-sbom.cyclonedx.xml s3://${{ s3-bucket-name }}/${{ github.event.repository.name }}/$ECRREPOS/sbom-cyclonedx.xml aws s3 cp ${{ steps.xeol.outputs.report }} s3://${{ s3-bucket-name }}/${{ github.event.repository.name }}/$ECRREPOS/eol-result.json Improvements Made and Future The results of checking whether my department is using the AWS-CORE library. The results of checking whether my department has EOL components. Since KINTO Technologies has integrated SBOM/EOL lists into the CMDB, allowing us to search and confirm the following: What libraries are being used in my product? Are there any components that have reached EOL? With the in-house CMDB, libraries and packages approaching EOL are also highlighted, making it easy to respond in advance. The first step of SBOM management is to output SBOM files in JSON, formatting them with jq, and manage them in Excel. In the future, we would like to start the operation of periodically requesting responses by ticket to products that include EOL. This will involve collaboration with the security team and many others. Impressions I looked into tools for EOL management, but there aren't many dedicated ones; most seem to be extensions of SBOM management, software management, or asset management. Given the prevalence of development involving OSS and libraries, regularly monitoring EOL can be highly effective as part of vulnerability countermeasures. Libraries often reach EOL within 1 to 2 years, requiring frequent updates to keep up with version changes. Being able to see the current state is a strong countermeasure against "not noticing" or "ignoring" issues. Similar to observability (O11y), the first goal should be to "make it visible." In fact, it may not be effective unless it is built up to the operational step which includes requests for fixes. However, I wrote this article under the title "Starting with Minimal" to say, "Let's build it first! Let's get started!" Conclusion The Platform Engineering team manages and develops tools used internally across the organization. We leverage tools and solutions created by other teams within the Platform Group. Based on the company's requirements, we either develop new tools from scratch or migrate existing components as needed. We are automating routine tasks for the MSP team and are also starting to explore CDK, so we started programming in addition to Managed Service. If you’re interested in these activities or would like to learn more, please don’t hesitate to reach out to us. @ card
This article is the entry for day 3 in the KINTO Technologies Advent Calendar 2024 🎅🎄 It's incredible to think that nearly a year has already gone by since the Learning Station was established! I’m Nakanishi from the DevRel (Developer Relations) Group, and I strongly believe that the Learning Roadside Station team plays a pivotal role in enhancing KINTO Technologies' learning culture. In the DevRel team, we work tirelessly connecting the dots of individual growth —from input to output— to reshape our organizational culture. A major shift supporting our engineering culture This year brought a significant change to our engineering culture: the establishment of the DevRel Group. Until recently, our activities had only been carried out as a project. However, we officially formed a team this spring, making it a fully-fledged part of the organization. From now, some team members are dedicated full-time, no longer balancing this role with other responsibilities. This reflects an important milestone for the company in its effort to empower employees to share their knowledge and insights. Moreover, this year, in addition to establishing the team, we gained recognition for the input-focused initiatives we had envisioned from the early days of the Tech Blog’s creation. Explaining the Technical PR Group’s activities using a car analogy If we were to compare our output-focused efforts to a car, it would be like replacing a muffler or modifying the engine structure to improve exhaust efficiency. On the other hand, our input-focused initiatives, represented by the Learning Roadside Station, is like switching the fuel from regular gasoline to premium or even nitro. It’s also comparable to transitioning from carburetors to fuel injection, or adding a turbocharger. In other words, this team is responsible for transforming the fuel and figuring out how to inject it into the engine as efficiently as possible. If we think of the engine as representing individuals or teams, the type and amount of input needed will differ for each engine. For example, diesel engines and gasoline engines require different methods of fuel input, and the efficiency also varies depending on the engine’s displacement. Centralizing learning within the company I may have taken a long introduction, but at the Learning Roadside Station, we are working to optimize learning inputs for each individual and create a system that leverages the strengths shared among employees. Over the past year, we have focused on centralizing learning activities. This included visualizing study sessions, sharing and promoting study session information, supporting their organization, and consolidating scattered study resources across the company into one place. From now on, we will focus on "K to K" to bring people together and strengthen connections across the company. What is "K to K"? "K to K" stands for "KINTO Technologies to KINTO Technologies". It’s all about helping employees share their skills and learn from one another. For example, if some says: "I don't have enough analytical skills." -> One could consult with the Analysis Group. "I want to learn coaching." -> Ask person A who’s could organize coaching sessions. "I’m curious about project management." -> Reach out to PdM (Product Management) team members. By connecting the energy of those who wish to learn with the energy of those who want to share their expertise, such as: "I want to make better use of my skill A." or “I know someone who has this skill but is looking for the right opportunity to use it”, we can help bring out the best in our employees and energize the organization. The next action for the Learning Roadside Station is to focus on what we do best: bringing out the strengths of individuals and teams and connecting the dots across the organization . We look forward to tackling the challenges that lie ahead and are excited to see where our efforts will take us in the coming year. Other activities As part of our input-focused initiatives, we are also considering an expanded version of the podcast we currently run. At the moment, our main activity is interviewing those who host study sessions. However, similar to “K to K” activities, there are many things we would like to share across the company. By transforming these efforts into podcast content, we hope to create more opportunities for employees to learn and even provide a place for output for sharing knowledge beyond the company. Additionally, we are implementing Udemy Business as part of our efforts. We aim to explore how to use video content effectively and make the most of this platform. Conclusion Along with tech blogs, events, and presentations, we aim to expand the scope of the Learning Roadside Station as the next central pillar of our efforts. By continuously growing our input-focused initiatives, we hope to broaden our business horizons and create an environment where every employee can grow, thrive, and fully utilize their unique strengths. We will continue to actively share our progress and plans next year, so please stay tuned!
Hello. We are @p2sk and @hoshino from the DBRE team. The DBRE (Database Reliability Engineering) team is a cross-functional organization focused on resolving database (DB) issues and developing platforms. In this article, we introduce an automatic review function for DB table designs built with a serverless architecture using AWS's generative AI service “ Amazon Bedrock .” This function works with GitHub Actions, and when a pull request (PR) is opened, the AI ​​automatically reviews it and proposes corrections as comments. We also explain how we designed and implemented the evaluation of generative AI applications. We explain the evaluation methods adopted for each of the three phases in the LLMOps lifecycle (i.e., model selection, development, and operation phases), and in particular introduce generative AI- based automated evaluation utilizing "LLM-as-a-Judge" in the operation phase. Purpose of this article This article aims to provide easy-to-understand information on generative AI application evaluation, ranging from abstract concepts to concrete implementation examples. By reading this article, we hope that even engineers who do not have specialized knowledge of machine learning, like our DBRE team, will gain a better understanding of the generative AI development lifecycle. We will also introduce the challenges we faced when using generative AI in our services and how we solved them, with concrete examples. In addition, you can read this article also as one implementation example for the "Considerations and Strategies for Practical Implementation of LLM" introduced in the session " Best Practices for Implementing Generative AI Functions in Content Review " held at the recent AWS AI Day. I hope this article will be of some help to you. Table of Contents This article is structured as follows. This is a long article, so if you’re just interested in how the system works, I recommend you read up to the section on the "Completed System." If you’re interested in developing generative AI applications, I recommend you continue reading beyond that. Background Design Completed System (with demo video) Ideas in Implementation Evaluation of Generative AI Applications Lessons Learned and Future Prospects Conclusion Background Importance of database table design Generally, DB tables have the characteristic that once they are created, they are difficult to modify. As the service grows, the amount of data and frequency of references tend to increase, so we want to avoid as much as possible carrying technical debt that makes us regret later, saying, "I should have done it this way at the design stage...". Therefore, it is important to have a system in place that allows tables to be created with "good design" based on unified standards. " 10 Things to Do to Get Started with Databases on AWS " also states that a table design is still a valuable task, even though database management has been automated in the cloud. In addition, the spread of generative AI is making the data infrastructure even more important. Tables designed with uniform standards are easy to analyze, and easy-to-understand naming and appropriate comments have the advantage of providing good context for generative AI. Given this background, the quality of DB table design has a greater impact on an organization than ever before. One way to ensure quality is creating in-house guidelines and conducting reviews based on them. Our current situation regarding reviews At our company, table design reviews are carried out by the person in charge of each product. The DBRE team has provided the "Design Guidelines," but they are currently non-binding. We considered having DBRE review the table designs of all products across the board, but since there are dozens of products, we were concerned that if DBRE acted like a gatekeeper, it would become a bottleneck in development, so we gave up on the idea. Against this background, we, DBRE team, have decided to develop an automatic review system that acts as a guardrail and apply the system to our products. Design Abstract architecture diagram and functional requirements The following is the abstract architecture diagram for the automatic table design review function. To continuously perform automated reviews, it is important to integrate them into the development workflow. For this reason, we have adopted a system that triggers via a PR the automatic execution of an application on AWS and provides feedback within the PR, including comments on suggested corrections to the table definition (DDL). The requirements for an application are as follows: The ability to set our company's own review criteria To complement human reviews, it should be as accurate as possible, even if not 100%. Policies for implementing review function There are two possible policies for automating table design reviews: (1) Review through syntax analysis and (2) Review through generative AI. The characteristics of each policy are summarized as follows: Ideally, (1) should be applied to review criteria that can be handled through syntax analysis, and (2) to other review criteria. For example, the verification of the naming rule "Object names should be defined in Lower Snake Case" can be handled by (1). On the other hand, subjective criteria, such as "giving object names that allow inferring the stored data," are better suited for (2). Ideally, the two policies should be used separately depending on the review criteria, but this time we have decided to implement only "(2) Review through generative AI" for the following reasons. (1) is feasible, but (2) is something whose feasibility we cannot determine until we try it, so we have decided it is worth attempting first. By implementing the items that can be handled by (1) also in (2), we aim to gain insights into the accuracy and implementation costs of both policies. Review target guidelines To shorten the time to delivery, we have narrowed the review items down to the following six: An index must comply with the DBRE team's designated naming rules. Object names are defined in Lower Snake Case. Object names must consist of alphanumeric characters and underscores only. Object names must not use Roman characters. Object names that allow inferring the stored data must be assigned. Columns that store boolean values ​​should be named without using "flag". The top three can be addressed with syntactic analysis, but the bottom three are likely to be better addressed with generative AI, which also provides suggested corrections. Why create a dedicated system? Although several "systems (mechanisms) for review using generative AI" already exist, we have determined that they do not meet our requirements, so we have decided to create a dedicated system. For example, PR-Agent and CodeRabbit are well-known generative AI review services. Our company has also adopted PR-Agent for reviewing codes and tech blogs . In addition, GitHub Copilot's automated review function is currently available as Public Preview and may become generally available in the future. This function also allows you to have your code reviewed in Visual Studio Code before pushing it, and it is expected that the "generative AI review system" will become more seamlessly integrated into development flows in the future. Additionally, you can define your own coding standards in the GitHub management screen and have Copilot review based on them. The following are some reasons why we want to build our own system: It is difficult to check a large number of guidelines with high accuracy using generative AI, and we have determined that it is currently challenging to handle this with external services. We want to adjust the feedback method flexibly. Example: Columns like "data1" have ambiguous meanings, so it is difficult to suggest corrections, so we want to keep them in comments only. In the future, we aim to improve accuracy with a hybrid structure combining syntax analysis. Next, we will introduce the completed system. Completed system Demo video After the PR is created, GitHub Actions is executed, and the generative AI provides feedback on the review results as comments on the PR. The actual processing time is approximately 1 minute and 40 seconds, but the waiting time has been omitted from the video. The cost of the generative AI when using Claude 3.5 Sonnet is estimated to be approximately 0.1 USD per DDL review. https://www.youtube.com/watch?v=bGcXu9FjmJI Architecture The final architecture is as shown in the diagram below. Note that we have built an evaluation application separately to tune the prompts used, which will be described in detail later. Process Flow When a PR is opened, a GitHub Actions workflow is triggered, and an AWS Step Function is started. At this stage, save the PR URL and the GITHUB_TOKEN generated in the workflow to DynamoDB. The reason for not passing DDL directly to Step Functions is to avoid input character limits. Extract the DDL on the Lambda side based on the PR URL. Step Functions uses a Map state to review each DDL in parallel. Only one guideline should be checked per review. To review based on multiple guideline criteria, the "post-correction DDL" obtained from the first prompt is repeatedly passed to the next prompt, generating the final DDL (the reason will be explained later). After completing the review, provide feedback as a comment on the PR. The review results are stored in S3, and the generative AI evaluates them using LLM-as-a-Judge (more details will be provided later). Examples of the results are shown below. As feedback from the generative AI, the "applied guidelines" and "suggested corrections" are provided as comments (on the left side of the image). The details have been collapsed and can be expanded to check the specific corrections and comments made to the DDL (on the right side of the image). Steps required for implementation The table design review feature can be implemented in just two steps. Since it can be set up in just a few minutes, you can easily introduce it and start the generative AI review immediately. Register the key required to access AWS resources in GitHub Actions Secrets. Add a GitHub Actions workflow for the review function to the target GitHub repository. Simply add the product name to the template file provided by the DBRE team. Next, we will introduce some of the ideas we came up with for our implementation. Ideas in Implementation Utilization of container images and Step Functions Initially, we planned to implement it using only Lambda, but we encountered the following challenges. The library size is too large and exceeds the 250 MB deployment package size limit for Lambda. When chaining and evaluating multiple guideline criteria, there is a concern that the maximum execution time of Lambda (15 minutes) may be reached. When serially processing DDLs, the execution time increases as the number of DDLs increases. To solve issue 1, we adopted container images for Lambda. To solve 2 and 3, we introduced Step Functions and changed the design so that each Lambda execution evaluates one DDL against one guideline criterion. Furthermore, by using Map state to perform parallel processing for each DDL, we ensured that the overall processing time is not affected by the number of DDLs. The diagram below shows the implementation of the Map state, where the prompt chain is realized in the loop section. Measures against Bedrock API throttling During the review, Bedrock's InvokeModel requests occurred according to the number of DDLs multiplied by the number of guidelines , and errors sometimes occurred due to quota limits. According to the AWS documentation , this limit cannot be relaxed. For this reason, we introduced a mechanism to distribute requests on a per-DDL basis across multiple regions and, in the event of an error, retry in yet another region. This has led to stable reviews, mostly without reaching the RateLimit. However, we are currently using cross-region inference , which dynamically routes traffic among multiple regions and allows us to delegate throttling countermeasures to AWS, so we plan to transition to this in the future. Organizing the way to grant permissions to execute GitHub API from Lambda In order to enable Lambda to "obtain the changed files of the target PR" and "post comments on the target PR," we compared the following three methods of granting permissions. Token type Expiration date Advantages Disadvantages Personal Access Token Depending on the setting, it can be unlimited The scope of the permissions is broad. Dependency on individuals GITHUB_TOKEN Only during workflow execution Easy to obtain Concerns about insufficient permissions depending on the processing of the target GitHub App(installation access token) 1 hour Granting permissions not supported by GITHUB_TOKEN is also possible Increased complexity of the steps involved in introduction to a product This time we have adopted GITHUB_TOKEN for the following reasons: Tokens are short-lived (only for the duration of the workflow) and pose a low security risk. Token issuance and management are automated, reducing the operational burden. Permissions necessary for this processing can be granted. The tokens are stored in DynamoDB with a time to live (TTL) and are retrieved and used by Lambda when needed. This allows you to use tokens safely without needing to check whether the token-passing process has been logged. In the following, we present evaluation examples of generative AI applications. Evaluation of Generative AI Applications For generative AI application evaluation, we referred to the diagram below from Microsoft's documentation . Source: Microsoft - Evaluation of Generative AI Applications According to this diagram, there are three types of evaluations that should be performed during the GenAIOps (LLMOps, because the target in this case is LLM) lifecycle. Model selection phase Evaluating the base models and deciding which model to use Application development phase Evaluating the application output (≒ response of the generative AI) from the perspectives of quality, safety, etc., and tuning it Post-deployment operation phase Even after deployment to the production environment, quality, safety, etc., are evaluated continuously. Below, we will introduce some examples of how evaluations were conducted in each phase. Evaluation during the model selection phase This time, we selected an Amazon Bedrock platform model and evaluated it based on the scores from Chatbot Arena and the advice of our in-house generative AI experts and adopted Claude from Anthropic. We reviewed the DDL using Claude 3.0 Opus, which was the highest-performing model at the time of our launch, and confirmed its accuracy to a certain extent. Each model has different base performance, response speed, and monetary costs, but since reviews in this case are infrequent and there is no requirement for "maximum speed," we selected the model with the greatest emphasis on performance. Based on Claude's best practices, we determined that further accuracy could be achieved through prompt tuning and moved on to the next phase. Meanwhile, the higher-performance and faster Claude 3.5 Sonnet was released, which further improved the inference accuracy. Evaluation during the application development phase Generative AI evaluation methods are clearly summarized in the article here . As the article states, "Various evaluation patterns are possible depending on the presence or absence of a prompt, foundational model, and RAG," the evaluation pattern will vary depending on "what is being evaluated.” This time, we will focus on the evaluation of a "single prompt" and provide a concrete example of the design and implementation for the specific use case, which involves "having a database table design reviewed according to our company's guidelines." Prompt tuning and evaluation flow Prompt tuning and evaluation were carried out according to the diagram below, as described in Claude's documentation . Source: Anthropic company - Create strong empirical evaluations The key point is to define an evaluation perspective, such as "how close the prompt execution result is to expectations," as a "score calculated in some way," and to adopt the prompt with the best score. Without an evaluation system (mechanism), determining the improvement in accuracy before and after tuning may rely on subjective judgment, which could lead to ambiguity and an increase in work time. In the following, we will first introduce the generative AI evaluation method, followed by examples of prompt tuning. What is "generative AI evaluation"? The page for the generative AI evaluation product called " deep checks " states the following about evaluation. Evaluation = Quality + Compliance I felt that this was the most concise way to evaluate generative AI applications. Breaking it down further, the article here classifies the criteria for evaluating service providers into four perspectives: "truthfulness, safety, fairness, and robustness." The evaluation criteria and score calculation method should be selected according to the properties of the application. For example, Amazon Bedrock uses different metrics for different tasks, such as "BERT score" for text summarization and "F1 score" for question answering. Method for calculating evaluation scores anthropic-cookbook classifies the methods for calculating scores into the following three main categories: Summary of the score calculation methods described in anthropic-cookbook You can choose to use cloud services, OSS, or create your own score calculation logic. In any case, you need to set your own evaluation criteria. For example, if the LLM's output is in JSON format, "matching each element" may be more appropriate than "matching the entire string." Regarding model-based grading, the code provided in anthropic-cookbook can be expressed more concisely as follows: def model_based_grading(answer_by_llm, rubric): Prompt = f""" Evaluating the answer within the <answer> tag based on the perspective of the <rubric> tag. Answering "correct" or "incorrect." <answer>{answer_by_llm}</answer> <rubric>{rubric}</rubric> """ return llm_invoke(prompt) # Pass the created prompt to LLM for inference rubric = "Correct answers must include at least two different training plans." answer_by_llm_1 = "The recommended exercises are push-ups, squats, and sit-ups." # Actually, the output of LLM grade = model_based_grading(answer_by_llm_1, rubric) "print(grade) # It should be output as "correct" answer_by_llm_2 = “The recommended training is push-ups.” # Actually, the output of LLM grade = model_based_grading(answer_by_llm_2, rubric) print(grade) # It should be output as "incorrect." Summary of evaluation To summarize the content covered so far, the evaluation method is illustrated as the diagram below. Abstractly, the evaluation of generative AI breaks down into Quality and Compliance. These are further broken down, and specific evaluation criteria are set for each use case. Each criterion needs to be quantified, and this can be achieved based on “Code,” “Human,” or “Model.” In the following, we will explain the specific evaluation method from the perspective of "database table design review." Evaluation design in DB table design review We chose a code-based approach to quality evaluation for the following reasons: The cycle of evaluation and tuning by humans increases man-hours and is not worth the resulting benefits. We also considered a model-based approach, but since we wanted to assign the best score for a perfect match with the correct DDL, we concluded that a code-based approach was more appropriate. Since it is difficult to newly implement "similarity in DDL" with the correct data, we adopted the Levenshtein Distance, a method for measuring the distance between texts, as the score calculation method. With this method, a perfect match has a distance of 0, and the higher the value, the lower the similarity. However, since this is not an indicator that completely represents "similarity in DDL," we basically aimed for a score of 0 for all datasets and performed prompt tuning on datasets with non-0 scores. The algorithm is also provided by LangChain's String Evaluators (String Distance) , which is what we use. On the other hand, from a compliance perspective, we decided that it was unnecessary this time because it is an in-house application and the implementation limits user input embedded in the prompt to DDL. Implementation of evaluation The flow of the implemented evaluation is as follows. For each review perspective, we created 10 patterns of datasets combining input DDL and correct answer DDL. To efficiently repeat prompt tuning and evaluation, we developed a dedicated application using Python and Streamlit . The dataset is saved in jsonl format, and when you specify the file, the evaluation is automatically performed and the results are displayed. Each json contains the "evaluation target guideline", "parameters for invoking LLM", "input DDL", and "correct DDL" as shown below. { "guidline_ids": [1,2], "top_p": 0, "temperature": 0, "max_tokens": 10000, "input_ddl": "CREATE TABLE sample_table (...);", "ground_truth": "CREATE TABLE sample_table (...);" } When displaying individual results, the diff between the output DDL and the correct DDL is displayed, making it possible to visualize the differences (= tuning points). Once the evaluation is complete, you can also check the aggregated score results. Prompt tuning Based on Claude's documentation , we created and tuned the prompts, keeping the following points in mind, and ultimately achieved the best results (0 score) for almost all 60 datasets. Setting roles Utilizing XML tags Letting Claude think (instructing Claude to show its thinking process to make debugging easier when the answer is disappointing) Few-Shot Prompting (providing example output) Putting reference data at the beginning and instructions at the end Giving clear and specific instructions Chaining prompts There are many well-known techniques, so we won't go into detail here, but let us provide some additional information on the last two points. "Giving clear and specific instructions" Initially, we embedded the text of our in-house table design guidelines directly into the prompt. However, the guidelines only described "how things should be" and did not include "specific steps to correct the errors." Therefore, we rewrote them into "specific correction instructions" in a step-by-step format. For example, we revised the guideline "Do not use xxx_flag for column names that store boolean values" as follows: Follow the steps below to extract the column name storing the Boolean value and change it to an appropriate column name if necessary. 1. Extract the name of the column that stores Boolean values. The criterion is whether the column uses the Boolean type or contains the word "flag." 2. Check the names of the Boolean columns one by one and understand the meaning of the columns first. 3. Check the names of the Boolean columns one by one, and if you determine there is a more appropriate name, modify the column name. 4. Regarding the appropriate column name conditions, refer to the <appropriate_column_name></appropriate_column_name> tag. <appropriate_column_name> Without using the word "flag"... ... </appropriate_column_name> "Chaining prompts" The more guidelines there are to check, the more complex the prompts will become if you try to check them all in one go, raising concerns that checks will be missed or accuracy will decrease. For this reason, we limited the items that the AI ​​checks in each prompt execution to one. We also reflected this in the architecture by passing the "corrected DDL" obtained in the first prompt as input for the next prompt (Chain), and repeating the process to obtain the final DDL. Chaining prompts also offers the following advantages: Since prompts are short and tasks are limited to one, accuracy improves. When adding guidelines, you only need to create a new prompt, so there is no impact on the accuracy of existing prompts. On the other hand, the time and financial costs will increase as the number of LLM Invokes increases. Evaluation during the post-deployment operational phase In the prompt creation stage, we evaluated the quality using manually created correct answer data. However, in a production environment, no correct answer data exists, so a different approach for evaluation is required. So, we adopted LLM-as-a-Judge, an approach where an LLM evaluates its own responses. According to the Confident AI documentation , there are three methods to this approach. Single Output Scoring (no correct answer data) Giving the "LLM output" and "evaluation criteria" and having the LLM provide a score based on the criteria. Single Output Scoring (with correct answer data) In addition to the above, "correct answer data" is also provided. A more accurate evaluation can be expected. Pairwise Comparison Comparing two outputs and determining which is better. You define the criteria for "better" yourself. This time, we used Single Output Scoring (with no correct answer data). This approach is also supported by LangChain , and we used the provided function. Currently, implementation by LangSmith is recommended. The following two criteria are defined, and each is scored on a 10-point scale. Appropriateness Has the LLM output been appropriately corrected in accordance with the guidelines? Formatting Consistency Are there no unnecessary line breaks or spaces, and is the format consistent? The code and prompt images are below: input_prompt =""" <input_sql_ddl>CREATE TABLE ...</input_sql_ddl> <table_check_rule>Ambiguous object names are...</table_check_rule> Instructions: Based on table_check_rule, correct input_sql_ddl to the appropriate DDL. """ output_ddl = "CREATE TABLE ..." # Actually, DDL generated by LLM is set appropriateness_criteria = { "appropriateness": """ Score 1: ... ... Score 7: Responses generally following the input instructions have been generated with no more than two inappropriate corrections. Score 10: Responses completely following the input instructions have been generated. """ } evaluator = langchain.evaluation.load_evaluator( "score_string", llm=model, criteria=appropriateness_criteria ) result = evaluator.evaluate_strings( prediction=output_ddl, input=input_prompt ) print(result) This implementation produces the following outputs: (Some parts omitted) This answer completely follows the given instructions. The following are the reasons for the evaluation. 1. Extraction and evaluation of column names: The answerer has extracted all column names and appropriately judged whether each column name could infer the contents of the data. 2. Identification of ambiguous column names: All column names in the provided DDL clearly indicate their purposes and the type of stored data. For example, ... ... This answer fully understands and properly executes the given instructions. Rating: [[10]] This mechanism corresponds to the red boxes in the architecture diagram below. Once the LLM review results are stored in S3, the Lambda for LLM-as-a-Judge is launched asynchronously via SQS. This Lambda performs the evaluation, stores the results as logs in S3, and sends the score as a custom metric in CloudWatch. Moreover, CloudWatch Alarm will notify Slack if the threshold is not satisfied. This score is not 100% reliable, but since it is intended for an in-house system, it is an environment that makes it easier to get feedback from users. So, we have established a system to continuously monitor the performance using quantitative scores and collect user feedback on a regular basis. Lessons Learned and Future Prospects Finally, we will summarize what we learned from our attempt at developing generative AI applications and our future direction. Evaluation is very important but difficult By evaluating the prompt results from the same perspective, we were able to quickly repeat tuning and evaluation while eliminating subjectivity. This experience strongly highlighted the importance of evaluation design. However, the three evaluations in GenAIOps (during model selection, development, and operation) need to be judged for each use case, and we felt that "judging the validity of our evaluation design" was difficult. Furthermore, a lack of evaluation perspectives also poses the risk of delivering applications with compliance issues. We believe that, in the future, the provision of more systematic and managed evaluation methods and mechanisms will make it easier to realize GenAIOps. Our scope of imagination for generative AI use cases has broadened. By conducting research and implementing generative AI applications ourselves, we were able to gain a clearer understanding and broaden the range of use cases we can imagine. For example, we can now envision a system that combines agents with mechanisms for collecting information on lock contention , enabling more managed and faster incident investigations. Utilizing generative AI as a replacement for programmable tasks There are the following two main ways to use generative AI in application development. Having generative AI perform the task itself. Improving the productivity of program development with generative AI This time, we used generative AI to implement not only tasks that should be inferred by generative AI, but also tasks that would normally be processed by a program. Initially, we had hoped that by devising innovative prompts, we might be able to obtain high-precision results quickly. But we soon became acutely aware that prompt tuning actually requires a lot of time. On the other hand, by running multiple Claude models on the same task, we found that the more accurate the model, the clearer the improvement in results. Furthermore, we found that more accurate models reduce unpredictable behaviors and require less time for prompt tuning. Based on these experiences, if model accuracy continues to improve in the future, depending on the requirements, there may be an increasing number of cases where the approach of having a generative AI perform a task itself, instead of having it write a program to do so, will be chosen. Future prospects In the future, we plan to focus on the following: Expansion of response guidelines Expansion of introduced products Creating a hybrid configuration with programmatic syntax analysis Improved clarity when providing feedback on review results to users Expanding the current simplified LLMOps to not only include monitoring but also enable prompt and model improvements using logs Reference: Post by @Hiro_gamo Conclusion In this article, we introduced an automated review function for database table design, implemented using Amazon Bedrock within a Serverless architecture. We also explained how to evaluate generative AI applications. At the recent AWS AI Day session titled " Best Practices for Implementing Generative AI Functions in Content Review ," key considerations and strategies for the practical introduction of LLMs (large language models) were presented. Below, we outline how our efforts align with the items covered in the session. Item Content Separation from other methods ●The DBRE team is taking on the challenge of automation using LLM. ● In the future, we aim to combine LLM with a rule-based approach. Accuracy ● Designing evaluation criteria based on the use case "table design review" ● Developing a dedicated application to rapidly repeat prompt tuning and evaluation ● Executing prompt tuning according to the best practices for the selected model (Claude). ● Limiting the number of items the AI checks per prompt execution to one, combined with using prompt chains, to improve accuracy Cost ● Approximately $0.1 per DDL, depending on the number of characters in the DDL ● Model selection focusing on accuracy over cost (Claude 3.5 Sonnet) because of the low frequency of reviews ● We decided that using a prompt chain would similarly increase costs but provide the benefit of improved accuracy. Availability/Throughput ● Implementing request distribution and retry processing between regions with awareness of quotas ● We plan to transition to a more managed cross-region inference . Response speed ● Since there is no requirement to be "as fast as possible," the model selection prioritized accuracy over speed. ● Reviewing each DDL in parallel improved the speed. ● Responses were returned within 2-5 minutes for dozens of DDLs. LLMOps ● Continuous accuracy monitoring was performed using LLM-as-a-Judge. Security ● For integration with GitHub, a GITHUB_TOKEN valid only during the execution of the GHA workflow was adopted. ● Since in-house applications and inputs are limited to DDL, the evaluation of compliance with LLM responses has not been conducted yet. This product is currently being introduced into multiple products, and improvements will continue to be made based on user feedback. Generative AI applications, including development services such as Amazon Bedrock Prompt Flow , continue to evolve, and we believe they will become even more convenient in the future. We will continue to actively venture into the field of generative AI. The KINTO Technologies DBRE team is actively looking for new members to join us! Casual interviews are also welcome, so if you're even slightly interested, feel free to contact us via DM on X (formerly Twitter). If you'd like, feel free to follow our company’s recruitment X account as well!
This article is part of day 2 of KINTO Technologies Advent Calendar 2024 . Introduction Hello! This is high-g ( @high_g_engineer ) from the New Car Subscription Development Group at the Osaka Tech Lab. Recently, solving TypeScript type puzzles, known as type-challenges, has become part of my daily morning routine before work. In this article, I will introduce some infer tips in the TypeScript type system that are a little quirky. First, before explaining infer, I will explain Conditional Types , which are essential for using infer. What are Conditional Types? Conditional Types, also called code branching, are features of the type system that allow conditional branching at the type level. I'd like to demonstrate an example of Conditional Types, as shown below: type ConditionalTest<A> = A extends 'a' ? true : false The right-hand side above has the following meaning: If A type can be assigned to a literal type 'a', it is a true type If A type is other than the above, it is a false type It behaves like the conditional operator in general programming languages. By the way, the extends keyword here has a different meaning than inheritance in general object-oriented programming. In this case, extends becomes the keyword to check the type's assignability. What is infer? infer is only available in Conditional Types, introduced in TypeScript 2.8. I'd like to demonstrate an example of Conditional Types, as shown below: type InferTest<T> = T extends (infer U)[] ? U : never On the right-hand side, we utilize Conditional Types, and to the right of the extends keyword, we specify the type we aim to obtain with infer . In the case of the above type, if the T type is "an array of any element type," it means that the type of the element is returned. (Note: Here "never" is the type returned if the conditions are not met.) (infer U)[] represents an array of any element type, so any array types such as string[], number[], boolean[] are applicable. So if the T type was number[], the type resolution would be as follows. type Result = InferTest<number[]> // number This is just an example, but there are many other ways to use infer. Functional manipulation using infer To get the return type const foo = (): string => 'Hello, TS!!' type MyReturnType<T> = T extends (...args: any[]) => infer R ? R : never type FunctionReturn = MyReturnType<typeof foo> // string Write the Conditional Types as before, and specify the desired type to the right of the extends keyword This time, I want to extract the return type, so I place the function type to the right of extends and infer the return value. This is the same behavior as TypeScript's built-in utility type ReturnType<T> . When retrieving the type of the argument const foo = (arg1: string, arg2: number): void => {} type MyParameters<T> = T extends (...args: infer Arg) => any ? Arg : never type FunctionParamsType = MyParameters<typeof foo> // [arg1: string, arg2: number] Since the arguments are tuple types, the rest parameter (spread syntax) can be used to handle any number of arguments. You can extract types by describing Conditional Types + the type you want to get + infer. This is the same behavior as TypeScript's built-in utility type Parameters <T> . Manipulation of array types (tuple types) using infer If you want to get the last element When retrieving the type of the first element of a tuple type, the type definition is as follows: type Tuple = [number, '1', 100] type GetType = Tuple[0] // number However, if you want to get the type of the last element of a tuple type, you cannot write Tuple[length-1] in TypeScript. The best solution is infer. The type definition is as follows: type ArrayLast<T> = T extends [...infer _, infer Last] ? Last : never [...infer _, infer Last] extracts the last element type as Last if the T type is an array or tuple type. type Test1 = ArrayLast<[1, 2, 3]> // 3 type Test2 = ArrayLast<[string, number, boolean]> // boolean type Test3 = ArrayLast<[]> // never Manipulating literal types using infer To get the type of the first character of a literal type type LiteralFirst<T extends string> = T extends `${infer First}${string}` ? First : never ${infer First}${string} extracts the beginning character of the string as First and treats the rest as string. To obtain a literal type with the first letter capitalized type FirstToUpper<T extends string> = T extends `${infer First}${infer Rest}` ? `${Uppercase<First>}${Rest}` : never As before, the string is processed separately, and Uppercase<First> uses a utility type to convert the first letter to uppercase and combine it with the rest of the string. Returns the never type if the string is empty. To trim spaces, newline characters, and similar elements from the beginning and end of a literal type. type Space = ' ' | '\n' | '\t' type Trim<S extends string> = S extends `${Space}${infer T}` | `${infer T}${Space}` ? Trim<T> : S; If you define a type called Space that includes a space character and a newline character, you can use Conditional Types to recursively apply the Trim type, effectively removing spaces from the beginning and end of the string. Conclusion As shown in these examples, using infer enables you to extract specific parts from a given type, significantly enhancing flexibility in defining and working with types. It's a bit unconventional, so it may take some time to adapt, but it's an incredibly useful feature. Using types enables robust development; however, incorrectly representing types can lead to the following risks: Poor code readability due to unnecessary type definitions Increased maintenance costs due to unnecessarily complex type definitions Reduced type safety By effectively leveraging TypeScript type systems, such as infer, you can achieve concise and clear type expressions while consistently focusing on enhancing development productivity and quality.
Introduction Hello! JSConf JP 2024 recently took place, and we were proud to support it as a premium sponsor! In this post, we’d like to share a session report from our team members who attended the event firsthand! ITOYU You Don’t Know Figma Yet - Hacking Figma with JS https://jsconf.jp/2024/talk/hiroki-tani-corey-lee/ Since Figma runs in a browser, I learned that you can use JavaScript in DevTools to manipulate it. You can use Figma’s official API via the figma global object to retrieve CSS information from elements or create new layers. Leveraging Figma’s browser-based nature unlocks its full potential, and I was truly amazed by the limitless possibilities it offers. Please refer to the official Figma documentation below for information on what can be done through global objects. https://www.figma.com/plugin-docs/api/global-objects/ All happy projects are alike; each unhappy project is unhappy in its own way https://jsconf.jp/2024/talk/mizchi/ Mizchi-san shared insights on common issue patterns based on their experience in performance tuning consulting His remark that adopting an easy anti-pattern can lead to an explosion later, reminded me of my own past experiences. Even though it's marked as deprecated in the documentation, using a hack from StackOverflow to fix an immediate issue might lead to even bigger problems later. This session reinforced the importance of seeking fundamental solutions instead of relying on makeshift fixes. This session reinforced the importance of seeking fundamental solutions instead of relying on makeshift fixes. might lead to even bigger problems later. nam Solving a Coding Test with Generative AI (by HireRoo) https://jsconf.jp/2024/talk/hireroo/ Hosted by HireRoo, a provider of coding test services, this workshop was a true coding exam. It was a workshop where we tried to solve this real coding test with generative AI, which is something we don't usually have the opportunity to try. (I thought it was a session, but when I went to watch, it seems that a PC was required... I'm sorry, but I solved it on HireRoo's PC. Sorry...) I tried solving it using ChatGPT, but simply pasting the problem text as-is didn’t produce the expected code. It turns out some ingenuity is required after all. Things don’t always go as smoothly as you’d hope. By the way, it seems that using generative AI during actual coding tests can provide quite a bit of insight. LT (Lightning Talk): The Ecosystem behind JavaScript (Comedy) https://jsconf.jp/2024/talk/ecma-boys/ In this session, the speaker shared an amusing story where their mother had forgotten the names of certain package managers and bundlers. Based on the characteristics she described, they speculated on what she might have been referring to. The talk featured several hilarious “power words,” such as "the package manager my Okan (mom) is curious about,” which made it incredibly engaging. Personally, one part that stuck with me was when they declared, "If the configuration file is easy to understand, it’s definitely not webpack," during the discussion about bundlers. Kiyuno LT (Lightning Talk): JavaScript Module Resolution Interoperability https://jsconf.jp/2024/talk/berlysia/ In this session, the topic was about resolving JavaScript modules. Recently, I encountered CJS/ESM issues while implementing UT for components that included Swiper, and it made me realize my lack of knowledge in module resolution. It gave me a sense of urgency to improve in this area. Additionally, the migration from Jest to Vitest had also been a minor topic within the team, so I felt it was necessary to fully understand this subject. By the way, the topic was very challenging for me, and I could barely keep up. I hope to become someone who can nod along and fully grasp these discussions someday soon. 🥲 LT (Lightning Talk): The Experience of In-House Production of a Car Subscription Service with Next.js and One Year Later https://jsconf.jp/2024/talk/kinto-technologies/ This was our company’s session. Since the in-house production project was completed long before I joined the company, I attended the session to learn about its history. The technology stack introduced during the session was almost the same as the one I am currently working on, so I felt the challenges and future prospects were highly relevant to me. Ren.M LT (Lightning Talk): romajip: A Story about Creating an English Address Conversion Library Using Japanese Address CSV Data https://jsconf.jp/2024/talk/kang-sangun/ In this session, the speaker talked about creating a library called romajip. Personally, I was surprised to learn that not only the post office but also the Digital Agency provides a Japanese address master. Additionally, I felt that handling issues like place names with the same name (e.g., Nihonbashi in Tokyo and Osaka) seemed quite challenging. If I ever have the opportunity to create a library myself, I’d like to document the challenges I encounter and the areas I pay particular attention to! Introduction of Prerender Technology at LINE Yahoo Japan and Its Effects https://jsconf.jp/2024/talk/masanari-hamada-tomoki-kiraku/ In this session, the speaker discussed the verification process for introducing Prerender technology at LINE Yahoo Japan. Prerender is a technology that pre-loads the destination page when you hover over a link! The result is significantly faster page loading times and a greatly improved user experience. After conducting various tests, LINE Yahoo Japan ultimately decided not to adopt the technology due to issues like link congestion. However, depending on how it’s used, Prerender seems to have the potential to greatly enhance loading speeds. I’m interested in studying it further myself! Novelty We visited the booths of the sponsor companies and received various novelties! Personally, I was happy with Mercari's "SOLD OUT” keychain! Official T-shirts and Tote bags Sponsor novelties We Are Hiring! KINTO Technologies is looking for new teammates to join us! We’re happy to start with a casual chat, so feel free to reach out. If you’re even a little curious, please apply using the link below! https://hrmos.co/pages/kinto-technologies/jobs/1955878275904303141 Conclusion How was it? I hope we’ll be able to participate in next year's JSConf JP in person! Thank you for reading all the way through!