This article is part of Day 13 of the KINTO Technologies Advent Calendar 2024 Hi, I’m Nakanishi from Learning Roadside Station. This year, the Learning Roadside Station project was officially launched and structured as an organization. As part of our initiatives, we also run an in-house podcast, and for this year’s Advent Calendar, we’d like to share more about it. What is "Learning Roadside Station"? “Learning Roadside Station” is a project aimed at making in-house study sessions, which are frequently held, more accessible and effective. The initiative is led by passionate volunteers within the company, with the goal of supporting study sessions and fostering a culture of knowledge sharing across the organization. Factory Automotive Study Group The Learning Roadside Station Podcast features interviews with employees who organize study groups within the company. This segment is called "Surprised! My Neighbor's Study Group." This time, we interviewed Miura-san from the Factory Team. Interview Hoka-san: Thank you, Miura-san. Could you introduce yourself and tell us about your role? Miura-san: Thank you very much. Officially, I am the Team Leader of the KINTO Factory Team, part of the Project Promotion Group in the Project Development Division. The Factory Team develops products not only with KTC but also in collaboration with KINTO's General Planning Department. Hoka-san: For this interview, we’d like to focus on the fact that you are studying automobiles within the Factory Team. Could you tell us more about that? Miura-san: First of all, I want everyone to enjoy their work. I believe that understanding the products we sell makes the work more engaging and rewarding. Since we handle automobile-related products, having technical knowledge about cars makes the development process even more enjoyable. Having a background in the automotive industry, I felt that sharing my knowledge would help us make better proposals, which is why I started the study group. Hoka-san: How did you decide to share that knowledge? Miura-san: We hold online study sessions. At first, session was for an hour, but now we've reduced it to 30 minutes and hold it once a month. Recently, we’ve been discussing the evolution of in-car networks and navigation systems. Hoka-san: How have the participants responded to the study sessions? Miura-san: Based on survey feedback, many participants found the information fresh and valuable since they wouldn’t normally come across such details in their daily work. The number of participants has not decreased, and they are listening with interest. Hoka-san: How long have you been running these sessions? Miura-san: At first, the sessions were one hour long, but now it’s 30 minutes and we hold them once a month. Hoka-san: What topics have you covered in your study sessions so far? Miura-san: Recently, we talked about the evolution of in-car networks and navigation systems. We also discussed how the automotive industry is evolving based on insights from CES in Las Vegas. Hoka-san: Did you attend CES in Las Vegas? Miura-san: I wasn’t able to attend in person, but I shared my own thoughts based on the exhibition content that are open to the public on the Internet. Hoka-san: Do you have any upcoming study sessions planned? Miura-san: Next, we’ll be discussing the vehicle installation process. Using dealer manuals, we’ll explore how different parts are assembled and installed in cars. Hoka-san: What should I do if I want to join the study sessions? Miura-san: Our sessions are conducted online, so anyone interested is free to participate. We’re also working on creating a system to visualize and organize study session information for easier access. Hoka-san: What inspired you to start the study group? Miura-san: It started as a team-building initiative. Our group transitioned from a project team to a formal team, and I wanted to ensure that everyone had a deeper understanding of automobiles. Hoka-san: Lastly, do you have a message for your colleagues? Miura-san: Since we work in the automotive industry, I believe that deepening our knowledge of cars makes our work more enjoyable and meaningful. If you’re interested, I encourage you to join our study sessions! Hoka-san: Thank you very much, Miura-san. I hope you will continue to share the fascinating world of automobiles with your colleagues through these study sessions. This time, we shared insights about the Factory Team, the background to its operations, and future prospects. Please look forward to the next study session!

自己紹介 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 ファイル、２つ目は 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 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エンジニアの皆様、カジュアル面談なども受け付けていますのでお気軽にご連絡お待ちしております。

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

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  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!)  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.

こんにちは こんにちは、2024年10月入社のたなちゅーです！ 本記事では、2024年10,11月入社のみなさまに、入社直後の感想をお伺いし、まとめてみました。 KINTOテクノロジーズ（以下、KTC）に興味のある方、そして、今回参加下さったメンバーへの振り返りとして有益なコンテンツになればいいなと思います！ H.I 自己紹介 はじめまして。このたびモバイルアプリ開発グループに配属されましたH.Iです。 これまでAndroidの開発に携わってきましたが、新しい環境で皆さんとともに成長し、貢献できることを楽しみにしています。 特に開発だけではなくデーター分析やサービスGrownに関心があり、チームの一員として力を発揮していきたいと考えています。まだまだ学ぶことも多いですが、精一杯頑張りますので、どうぞよろしくお願いいたします！ 所属チームの体制は？ 私の所属するチームでは、スクラムを採用し、アジャイルな開発プロセスを通じて業務を進めています。スプリントを軸に計画・開発・振り返りを行いながら、短いサイクルで継続的に改善を図っています。 KTCへ入社したときの第一印象？ギャップはあった？ 大企業のグループ会社だと思い、少しは硬い感じの雰囲気を考えましたが、入社してみたら、驚くほど、柔軟な雰囲気でした。勉強会もたくさんありますし、これからが楽しみです。 現場の雰囲気はどんな感じ？ メンバーはみんな高い技術力を持ち、向上心も高いと感じました。気軽く質問したり、提案したりできる雰囲気だと思います。 ブログを書くことになってどう思った？ できるだけ書きたいと思います。自分が覚えたことや経験を配信して行きたいと思います。 ほりちゃん → H.Iさんへの質問 社内で好きなイベント(公式/非公式問わず)はありますか？ 開発の勉強会や社外イベント参加がたくさんあります。自分が知らないことや興味があったけどできなかったことを共有してもらうのでこれから自分の成長の種になると思います。 地元自慢をどうぞ！ 韓国ソウルの近くの島です。自然が豊富でウナギや高麗人参生産地で有名です。お寺など歴史ある場所もたくさんあるので観光客も結構来てます。 たなちゅー 自己紹介 10月入社のたなちゅーです。セキュリティ・プライバシーGのサイバーセキュリティディフェンスチームに所属しています。 前職では、セキュリティベンダーでサイバーセキュリティに関するインシデントレスポンスやログ解析などを行っていました。 現在のチームでは、主にSIEMを用いたセキュリティログ監視や監視体制構築などに従事しています。 所属チームの体制は？ グループ全体で9名体制です。日本を含め4つの国出身のメンバーで構成されています。 グループは4つのチームで構成されており、セキュリティやプライバシーに関するインシデントレスポンスやセキュリティガイドラインのアセスメント、社内サイバーセキュリティ体制の構築、脆弱性診断、SOCなどの業務を行っています。 所属チームは4名体制です。主に、脆弱性診断メンバーとSOCメンバーで構成されています。 KTCへ入社したときの第一印象？ギャップはあった？ 入社前から色々な国出身のメンバーが在籍していると聞いていましたが、所属チーム内に日本人が自分しかいなかったことには少し驚きました。 会社として想像以上に生成AIの活用を強く推進しており、手軽に生成AIを業務で活用できる環境であることはポジティブなギャップでした。生成AIとのチャット以外に、自身の業務で活用できないか日々模索しています。 現場の雰囲気はどんな感じ？ 週に1回、参加可能なメンバーでランチ会を開催しており、メンバー間のコミュニケーションを大切にしている印象です。 ブログを書くことになってどう思った？ 入社前に見ていたブログだったので、自分のメッセージが掲載されることに少し不思議な感覚です。 H.Iさん → たなちゅーへの質問 自分だけのリラックスする方法があれば教えてください！ 一日の終わりにテレビ東京のニュース番組「ワールドビジネスサテライト」を観ることです！ lksx 自己紹介 11月入社のlksxです。DX開発Gでバックエンドエンジニアを担当しています。前職でも同じくバックエンドエンジニアをしていました。緊張もありましたが、学びが多く、とても充実した日々を過ごしています。どうぞ、よろしくお願いいたします。 所属チームの体制は？ 私が所属している開発チームは現在8人で構成されています。そのうち7人は室町オフィス勤務で、1人は大阪オフィスからリモートで参加しています。多拠点にメンバーがいるので、オンラインでのやり取りも多く、効率的な連携が求められるチームです。 KTCへ入社したときの第一印象？ギャップはあった？ KTCはスタートアップという印象が強く、複数のプロダクトが同時並行で進行しているのがとても新鮮でした。また、POC段階のプロダクトもいくつかあるのが印象的で、「新しいことに挑戦していく会社なんだな」と感じました。今のところ、特に大きなギャップは感じていませんが、スピード感のある環境なので、自分もそのペースに慣れていきたいと思っています。 現場の雰囲気はどんな感じ？ 現場はみんな話しやすく、和やかな雰囲気です。分からないことや困ったことがあったときにも気軽に相談できる環境なので、入社したばかりの私でも安心して仕事に取り組めています。 ブログを書くことになってどう思った？ あんまりブログは書いたことがなく、今回始めてなので、ワクワクしてます。 たなちゅー → lksxさんへの質問 平均的な一日の仕事の流れ（業務開始直後は〇〇をする。午後は〇〇の業務をすることが多いなど）はどのような感じですか？ まだ入社したばかりで、覚えることや勉強しないといけないことがたくさんあります。そのため、朝9:30から約30分ほど業務スキルの勉強をしています。午前中は頭を使う業務に集中し、午後は体力を使う業務をメインに進めることが多いです。 かーびー 自己紹介 2024年10月入社のかーびーです。 東京のIT事業会社で6年間ディレクター・PdMとしての経験を積み、地元大阪で自分のスキルを活かしながら生活ができたらと考え帰阪。リアルイベントの企画・運営業務を経て、KTCに入社しました。 現在は新サービス開発GのKINTO FACTORY開発チームに所属し、Osaka Tech Lab.で勤務しています。 所属チームの体制は？ KINTO FACTORY開発チームは、KTCではマネージャー1名、PdM2名、フロントエンドエンジニア4名、バックエンドエンジニア5名、QA1名で構成され、車のオーナーに向けた愛車のカスタム・機能向上サービスのサイト開発を行っています。Osaka Tech Lab.では、バックエンドエンジニアと私を含めた2名で開発を進めています。 KTCへ入社したときの第一印象？ギャップはあった？ 東京・名古屋・大阪と拠点が離れているため、コミュニケーション面が少し心配でした。しかし、KINTO・KTCにもTOYOTAグループの「直接会って話すこと」を大切にする文化（面着）が根付いており、オフラインでも頻繁に顔を合わせてコミュニケーションをとる機会があります。そのため、良い意味でギャップがありました。（このブログも今名古屋で書いています。） Osaka Tech Labのメンバーはプロジェクトを超えたコミュニケーションも活発で、横のつながりが強く、技術的な挑戦をしたいエンジニアの方も多く触発されています。 現場の雰囲気はどんな感じ？ プロダクトやサービス開発に携わりたい、より良いサービスにしたいという想いを持ったメンバーと一緒に働くことができて嬉しいです。 ブログを書くことになってどう思った？ 入社前にがっつり見ていたテックブログに参加できて嬉しいです！ lksxさん → かーびーさんへの質問 KTCで「これをやってみたい！」と思うことは？ KINTO FACTORYのサービスグロース貢献はもちろん、Osaka Tech Lab.だけで1つのプロジェクトを手掛けられるような挑戦もしていきたいです！ Jun 自己紹介 2024年11月に入社しましたJunです。 事業会社で7年近くWebエンジニアとして経験を積んだ後、よりチャレンジングな職場でスキルを磨きたいと考えKTCに転職を決意しました。 所属チームの体制は？ 私が所属しているのは新車サブスク開発グループのバックエンドチームで、チームには13名所属しています。チーム内では常に複数のプロジェクトが並行で進行しており、プロジェクト発足時にメンバーが選出されて2~4人程で一つのプロジェクトを回しています。 KTCへ入社したときの第一印象？ギャップはあった？ 学習意欲に溢れるエンジニアが多い印象でした。チーム内での勉強会はもちろんですが、会社横断での勉強会も頻繁に開かれており、多くのエンジニアが意欲的に参加されていました。エンジニアリングの学習は一人でコツコツ行うものと思っていたのでいい意味で裏切られました。 現場の雰囲気はどんな感じ？ 皆さん中途入社で幅広い知見をお持ちで、こうしなければいけないというのが無いので技術選定や運用方法のディスカッションは非常に盛り上がっています。毎日いい刺激を受けながら仕事ができています。 ブログを書くことになってどう思った？ テックブログは以前も書いていたのですが長い間更新が止まっていたので、また再開したくなりました。 かーびーさん → Junさんへの質問 気分を切り替えるおすすめルーティーンがあれば教えてください！ コーヒーが好きなので、ちょっと考えが煮詰まってしまった時などはコーヒを淹れてリフレッシュしてます。 H.I. 自己紹介 11月入社のH.I.です。 これまで数社のITベンチャーでマーケと開発、PdMを経験してきました。現在はKINTO UnlimitedのPdMとして東京の室町オフィスで勤務しています。 所属チームの体制は？ 私が担当しているKINTO Unlimitedでは、PdMが私含めて3人、エンジニアが20名ほどいます。 3人いるPdMの役割分担としては私がデータ分析とマーケ系、一人が開発系、もう一人がUI/UXの分野を担当されています。PdMとしての役割をうまいこと分担できていて、それぞれの強みを発揮できるかなりいいバランスが取れていると思っています。 KTCへ入社したときの第一印象？ギャップはあった？ これまで経験してきた会社に比べ、年齢層が少し高めだったので少し気を張っていましたが、みなさんいい人ばかりで安心して仕事ができています（ほんとに）。 一方で入社前に思ってたよりもずっと大きな組織だったので、ステークホルダーの多さや、誰が何をやっているかのわからなさは、ベンチャー出身の私としては適応しなければいけないギャップでした。 現場の雰囲気はどんな感じ？ おそらくプロダクトを持ってる一般的な会社に比べ潤沢なリソースがあるので、アイデアさえあれば様々な企画ができます。 別チームの方とも仲良くさせていただいていて、最近私の席の近くではクリスマスにみんなでケーキを食べたり、豆やミルを持ち寄って小さなコーヒー屋さんができたりしています笑 ブログを書くことになってどう思った？ いつか自己紹介ではないことも書いてみたいです！ Junさん → H.I.さんへの質問 前職で培ってきた技術やスキルセットで特にKTCで活かせている・役にたっていると思うスキルセットはなんですか？ 趣味で勉強したpythonや統計の知識がかなり役立っています。 それと、マーケと開発どちらも経験していたので、PdMの立場としては守備範囲を広げられていたと感じました。 福原（Fúyuán） 自己紹介 2024年11月に入社した開発支援部企画管理グループのFúyuánです。Osaka Tech Labに勤務しています。 受託開発業務にかかわる予算編成や請求支払などKTCの会計関連のバックオフィス業務を担当しています。 所属チームの体制は？ 企画管理グループは5名体制で、KTCの受託開発業務にかかわる予算編成・契約・請求支払・知財管理等の各業務を担当分けして業務を行っています。 また、グループメンバーの勤務地は東京・名古屋・大阪とバラバラで物理的な距離は遠いですが、slackで常につながっているので感覚的には隣で仕事しているくらいの近さでコミュニケーションをとっています。 KTCへ入社したときの第一印象？ギャップはあった？ 「THE JTC」な会社から転職したので、 決めて行動するまでのレスポンスが早く、社内の人間関係がフラットでコミュニケーションがとりやすいことに驚きを感じました。 入社面接でも面接官の方に同様の印象を得てそれを魅力に感じて入社を決めたのでギャップは無かったです。 現場の雰囲気はどんな感じ？ メリハリがとても効いていて、静かにもくもくと作業をしている時間とワイワイ雑談に花を咲かせているときのギャップがすごいです。皆さん国籍・年齢・社歴等バックグラウンドが様々なので日々良い刺激を受けてます。 ブログを書くことになってどう思った？ 普段ROM専でプライベートでもSNSやブログ等をやっていないので、びびっております… H.I.さん → 福原（Fúyuán）さんへの質問 在宅勤務の日のモーニングルーティンを教えてください！ 体を動かしてから仕事を始めると頭がさえるのでラジオ体操をすることを心掛けています 天気が良い日にベランダで日光を浴びながら体操するのが一番好きです（早く花粉シーズンよ終われ…！） R.O 自己紹介 新サービス開発部 プロジェクト推進グループに所属してます。プロジェクトマネージャーとしてKINTO ONEの開発プロジェクトに携わっています。 前職ではオフショア開発会社に勤めておりプロジェクトマネージャーとしてベトナムメンバーと協力しながら建設・エンタメ・金融系など様々な開発プロジェクトに従事してました。 所属チームの体制は？ パートナーさんも含めた10名ほどのチームになります。 全員がプロジェクトマネージャーでそれぞれがKINTO ONEに関する別々の開発プロジェクトに参画しています。 KTCへ入社したときの第一印象？ギャップはあった？ 前職より年齢層が少し上がることと中途採用の方のみという情報を聞いていて社内の雰囲気や社員の方との距離感を掴むのに勝手に緊張していましたが、スマートな方が多く相談や質問など連携がしやすい環境だと思いました。 社内勉強会の開催と社外勉強会への参加が想像より活発でした。 他拠点メンバーとオフラインで連携を取るために必要に応じて出張しているメンバーが結構いること。オンラインでのやり取りがメインだと想像してましたが、必要に応じて遠方にいるプロジェクト関係者と直接会う機会を得やすいのは良いなと思いました。 現場の雰囲気はどんな感じ？ 自分が所属しているプロジェクト推進グループは賑やかというよりは落ち着いた雰囲気で仕事の相談や雑談が穏やかに行われてます。 普段はSlack等のコミュニケーションツールでメッセージベースのやり取りが多いのですが、開発メンバーがいる席に出向いたりして直接仕様の確認などをする機会も結構あるので部署を跨いだ会話や相談がしやすい雰囲気だと感じました。 エンジニアさんが多いチームだと賑やかに仕様や実装に関して会話しながら仕事を進めているチームもあるのでチームによって雰囲気の色は違うなーとも感じてます。 ブログを書くことになってどう思った？ 自分の感じたことや思考を文字に起こすのは好きなので楽しみ 入社前の情報収集に活用していたブログに自分も寄稿する機会がもらえて嬉しい Fúyuánさん → R.Oさんへの質問 世の中の新しい技術やプロダクト、サービスのキャッチアップはどの様にされてますか？ X(旧Twitter)でそういった情報を発信しているアカウントのみをフォローしたアカウントを作成して、欲しい情報のみが流れてくるTLから拾う 他業界の友人・知人と連携（飲み会）して情報収集 サービスや新技術周辺の熱量まで含めて感じたい時はカンファレンスなどのオフラインイベントへの参加 ほりちゃん 自己紹介 2024年10月入社のほりちゃんです！広島出身のカープファンで、芋焼酎が好きです。 元々はAndroidエンジニアで、2年前に前職でPdMに転向しました。現在はトヨタ販売店様の課題を解決するためのシステム開発にディレクターとして携わっており、日々奮闘中です。 所属チームの体制は？ モビリティプロダクト開発部 DX Solution Gは7人で、プロデューサー1人、ディレクター3人、デザイナー3人がそれぞれ担当のプロジェクトを進めています。 KTCへ入社したときの第一印象？ギャップはあった？ 第一印象は「大手とベンチャーのいいとこ取りな会社」です！家賃補助や有給日数の多さなど環境は大手っぽいけど、社員主体で勉強会(やBeerBash)が頻繁に行われていたり超本部会のエネルギーがすごいところはベンチャーっぽくて好きです。 ギャップは強いて言うならツールですかね・・前職では社内向けシステムを担当していたので資料系は全部 FigJam か Notion で作成していたのですが、今は PowerPoint がメインツールです。でもけっこう慣れてきました！この調子でパワポマスター目指します💪 現場の雰囲気はどんな感じ？ グループのみなさんは優しくてのびのびと勉強させていただいてます！ランチも楽しいです🫶 プロジェクトチームではそれぞれの職種のプロフェッショナルたちがみんなで販売店様の課題解決を目指すワンチーム感があります。 ブログを書くことになってどう思った？ 前職でも何本か書いたことがあるので気になってました！参加できてうれしいです☺️ R.Oさん → ほりちゃんへの質問 KTCで面白いなーと感じた会社の文化や出来事はありますか？ 経営層のお話を聞く機会がたくさんあるところです！入社時研修で社長の小寺さんと副社長の景山さんとの懇談会がそれぞれあるのが既に驚きでしたが、その後も月一の全体会議や超本部会、1on1(希望者)やU35イベント(希望者)など盛りだくさんです😳 入社時研修の時に小寺さんが飲みに誘ってくれても良いよとおっしゃっていたので実際に何人か誘って一緒に飲みに行ったんですが、色々なお話ができて楽しかったです🍶(R.Oさんとたなちゅーさんも一緒に行きましたね！🙌)

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!

はじめに こんにちは！ KINTOテクノロジーズの生成AI活用PJTで生成AIエンジニアを担当しているAlexです。 最近、LLM（大規模言語モデル）を利用したマルチエージェントシステムの需要が急速に高まっています。今回、LangGraphの最新アップデート「langgraph_supervisor」を活用し、わずか30分以内でSupervisor型マルチエージェントシステムを構築した実例をご紹介します。このシステムは、複数の専門エージェントを中央のスーパーバイザーが効率的に調整・連携させる仕組みとなっており、業務の自動化やカスタマイズ可能な提案シナリオの生成など、さまざまなユースケースに応用可能です。 LangGraphとは LangGraph は、AIエージェントやRAG（Retrieval-Augmented Generation）システムの構築を容易にするPythonライブラリです。LangChainと組み合わせることで、複雑なワークフローやタスクを効率的に設計・実装できます。状態（State）の永続化、ツールの呼び出し、そして「人間の介在（human-in-the-loop）」や「後からの検証」が容易な中央パーシステンス層を提供しており、今回のSupervisor型システムの基盤となりました。 langgraph-supervisorとは langgraph-supervisor は、LangChainに最近発表されたLangGraphを活用して階層型Multi Agentシステムを構築するためのPythonライブラリです。中央のスーパーバイザーエージェントが各専門エージェントを統括し、タスクの割り当てや通信を管理します。これにより、複雑なタスクを効率的に処理できる柔軟なシステムの構築が可能です。 主な機能 Supervisor Agentの作成： 複数の専門エージェントを統括し、全体のオーケストレーションを行います。 ツールベースのAgent間Handoff機構： エージェント間の円滑な通信を実現するためのメカニズムを提供します。 柔軟なメッセージ履歴管理： 会話の制御を容易にするため、メッセージ履歴を柔軟に管理できます。 @ card Supervisor型Multi Agentシステムとは 出典： https://langchain-ai.github.io/langgraph/tutorials/multi_agent/agent_supervisor/ Supervisor型Multi Agentシステムとは、Supervisorと呼ばれる全体を統制するAgentがツールコール対応の各LLM Agentと連携して、どのAgentをいつ呼び出すか、またそれらのAgentに渡す引数を決定するMulti Agent構造です。 langgraph-supervisorでMulti Agentシステムを構築 以下は、実際にlanggraph-supervisorでMulti Agentシステムを構築する手順を紹介します。 今回は、匿名化した顧客の基本情報を入れるだけで、その顧客にお勧めする車と、お勧めのエンジンタイプも出力するシステムを構築します。 また、車の情報とエンジン情報に関しては、ローカルで格納している「車両情報.csv」からAgentが取得していきます。 環境準備 Azure OpenAIのAPIキーの用意 今回は、Azure OpenAI経由でGPT-4oを使用します。ご自身の状況によって、OpenAI APIやAnthropic APIなどを使用することも可能です。 また、Azure OpenAIのAPIキーやエンドポイントを環境変数として設定します。 os.environ["AZURE_OPENAI_API_KEY"] = "YOUR API KEY" os.environ["AZURE_OPENAI_ENDPOINT"] = "YOUR ENDPOINT" os.environ["AZURE_OPENAI_API_VERSION"] = "YOUR API VERSION" os.environ["AZURE_OPENAI_DEPLOYMENT"] = "YOUR DEPLOYMENT NAME" LangGraph、LangChainのインストール pip install langgraph pip install langchain pip install langchain_openai langgraph-supervisorのインストール pip install langgraph-supervisor LLMおよび各Agentで使うツール関数のセットアップ Azure OpenAI GPT-4oでモデルを定義します。 また、エージェント用のツール関数も定義します。 from langchain_openai import AzureChatOpenAI import pandas as pd # LLMの初期化 llm = AzureChatOpenAI( azure_deployment=os.getenv("AZURE_OPENAI_DEPLOYMENT"), api_version=os.getenv("AZURE_OPENAI_API_VERSION"), ) car_information_path = "/xxx/xxx/車両情報.csv" # ツール関数の定義例 # CSVファイルから車両情報を読み込み、候補を生成する例 def get_car_features(): """The python code to get car information.""" path = car_information_path # CSVファイルのパスを指定 df = pd.read_csv(car_information_path) car_features = df[["車種名", "ボディタイプ", "説明"]].drop_duplicates() return car_features.to_dict(orient="records") # 選択された車種に対してエンジンタイプを抽出する例 def get_engine_type(selected_car): """The python code to get engine type and engine information.""" path = car_information_path df = pd.read_csv(car_information_path) engine_types = list(df[df["車種名"] == selected_car]["エンジンタイプ"].unique()) return engine_types, "エンジンに関する補足情報" 各Agentの定義 LangGraphの「create_react_agent」を利用して、各専門エージェント（車種推薦、エンジンタイプ選択）を定義します。 from langgraph.prebuilt import create_react_agent # 車種推薦エージェント car_agent = create_react_agent( model=llm, tools=[get_car_features], name="car_agent", prompt=""" # 指示書 提案パターンに基づいて、推薦する車種を選び、200文字程度の根拠を説明してください。 """ ) # エンジンタイプ選択エージェント engine_agent = create_react_agent( model=llm, tools=[get_engine_type], name="engine_agent", prompt=""" # 指示書 推薦車種に最適なエンジンタイプを選び、200文字程度の根拠を説明してください。 """ ) Supervisorの定義 各エージェントを統括するSupervisorを作成し、顧客情報に基づいた最終提案を生成します。 ここで工夫した点としては、Supervisorに入力するプロンプトをモジュール化して、より高い汎用性を実現しました。roleやtask変数の中身と、紐づくAgentを変更すれば、他のタスクにも流用可能です。 from langgraph_supervisor import create_supervisor # プロンプトの各モジュールの内容を作成 role = "車のセールスマン" task = "顧客情報をもとに、最適な車とエンジンタイプを提案してください。" guideline = """ - 出力は必ず上記JSON形式で行ってください。 - 各根拠は200文字程度の豊かな文章で記述してください。" """ output_format = """ { "提案内容": { "提案する車種", "車種の根拠", "選択したエンジンタイプ", "エンジン選定理由" } } """ # プロンプトを作成 system_prompt = f""" ## ロール あなたは優れた{role}です。 ## タスク {task} ## ガイドライン {guideline} ## 最終生成物のフォーマット {output_format} """ # Supervisorの作成 workflow = create_supervisor( # 先ほど作成したエージェントと紐づく [car_agent, engine_agent], model=llm, prompt=system_prompt ) # グラフのコンパイル app = workflow.compile() 実行例 from langchain.schema import HumanMessage import time # 顧客情報の例（必要に応じて詳細情報を追加） customer_info = "顧客情報: 年齢35歳、燃費重視、現在乗車中の車はコンパクトカー" # 実行例 start_time = time.time() result = app.invoke({ "messages": [ {"role": "user", "content": customer_info} ] }) end_time = time.time() # 最終出力の表示 print("最終提案:") print(result["messages"][-1].content) print("実行時間: {:.3f}秒".format(end_time - start_time)) Supervisorからの返答 最終提案: { "提案内容": { "提案する車種": "ハイブリッド技術を採用した最新コンパクトカー", "車種の根拠": "顧客は現在コンパクトカーに乗車中であり、燃費性能の良さを重視しています。ハイブリッド技術を採用した車は、燃料使用の効率が高く、経済的負担や環境への配慮が優れています。また、ハイブリッドシステムは短距離や都市部での走行にも最適です。そのため、最新のハイブリッドコンパクトカーが最適な選択肢となります。", "選択したエンジンタイプ": "ハイブリッドエンジン", "エンジン選定理由": "ハイブリッドエンジンは燃費性能が非常に優れており、顧客のニーズである燃料効率を最優先に考慮しています。さらに、コンパクトカーとの相性も良く、都市部での利用や日常の移動において高いパフォーマンスを発揮します。このエンジンの選択は、快適性、経済性、環境性能を全て満たします。" } } 実行時間: 21.938秒 実際に構築してみた感想 迅速なプロトタイピング langgraph_supervisorを利用することで、従来のLangGraphに必要だった複雑なAgent間の連携や状態管理がシンプルなコードで実装でき、30分以内にプロトタイプを構築できた点は非常に印象的でした。 柔軟性と拡張性 各Agentは独自のpromptやツール関数で実装できるため、ビジネスニーズに合わせたカスタマイズが容易です。また、状態管理が中央で行われるため、将来的な改善や新しい機能の追加もスムーズに行えそうです。 We Are Hiring！ KINTOテクノロジーズでは、事業における生成AIの活用を推進する仲間を探しています。まずは気軽にカジュアル面談からの対応も可能です。少しでも興味のある方は以下のリンク、または XのDM などからご連絡ください。お待ちしております！！ @ card ここまでお読みいただき、ありがとうございました！

👋 Introduction Hi there! I’m Moji, the product designer behind Toyota Community by KINTO platform. Today, I’m excited to share the story behind its creation; a journey of collaboration, innovation, and designing with purpose. For me, design goes far beyond aesthetics; it’s about solving problems and balancing user needs with business goals. That’s why the Toyota Community by KINTO has been such an inspiring project for me. Toyota Community by KINTO logo and mobile interface mockups showing platform features 🚀 Background What started as a simple idea during a hackathon has evolved into a product (responsive web application) that we are now preparing to pitch as a scalable solution for better customer engagement, aimed at connecting Toyota customers and enthusiasts under one global platform. Over the past 2 years, my journey with this project, hasn’t just been about design and development , it’s been an ongoing process of navigating corporate feedback , understanding the nuances of regional markets , and consistently refining the product to align with both business objectives and user’s needs . Photos from KINTO Global Innovation Days 2022, showcasing the winning hackathon team, team collaboration, and the Innovator of the Year awards 💡 The Challenge Decentralized Structure and Value Chain Gaps In the automotive industry, some brands operate with a decentralized structure. While this approach allows for flexibility and customization to meet local market needs, it can sometimes create challenges in maintaining global brand consistency and engaging customers effectively after purchase. This highlights an exciting opportunity for a centralized hub where brands can gain valuable customer insights, and strengthen their image in a positive and impactful way. Competitive Analysis To better understand the online community landscape, I conducted a comprehensive analysis of existing online car communities and competitive platforms. Key Insights 🚗 Toyota enthusiasts, especially those with older or restored models, are heading to external platforms like Toyota Nation (owned by VerticalScope) or Reddit to interact, share feedback, and discuss their vehicles. 🌐 Most platforms already offer community spaces (forums) where users can connect, exchange ideas, and learn from one another. However, one significant gap stood out! Car lovers are deeply passionate about showcasing their vehicles. There wasn’t a specific section that allowed car owners to create a dedicated virtual garage where they could: 🛠️ Showcase modifications and customizations. 📸 Share photos of their cars. Identifying the Opportunity The following three strategic integrations ensured that our platform stood out from competitors and wasn’t just a siloed social space but became a gateway where users could consume and discuss authentic content as well. 1. Connecting with Mr. Land Cruiser As part of the broader Toyota network, we had the privilege of connecting with ex-Chief Engineer of Toyota Land Cruiser, Mr. Sadayoshi Koyari , also known as Mr. Land Cruiser . This connection allowed us to feature exclusive videos and a dedicated Ask Me Anything (AMA) channel, where users could directly interact with him, ask questions, and gain valuable insights. Collaboration with Sadayoshi Koyari, famously known as Mr. Land Cruiser, featuring team discussions and filming sessions. 2. Sharing Reputable Automotive News from Toyota Times Additionally, because a reputable automotive news is also valuable, we negotiated with Toyota Times a well-known source, and they approved sharing their official articles on our web application. This gave users access to both reliable brand content and a space to share personal stories and engage in meaningful discussions. A screenshot of the Toyota Community by KINTO platform showing an article from Toyota Times about the Land Cruiser 3. Introducing the "Garage" Feature Also, for car lovers, we know how much joy comes from showing off their ride, sharing the customizations and modifications they’ve worked hard on, and connecting with others over that passion. So, we introduced the "Garage" feature in a fun and personalized way for car owners to: Showcase photos of their cars. Document modifications, customizations, and significant milestones. Share their vehicle's unique story, all within a visually appealing interface. A screenshot of the Toyota Community by KINTO platform showcasing a user's 1981 Land Cruiser FJ40 Soft Top in the virtual garage, with details on modifications and personal history. 🎨 Designing the Solution Distributor Feedback Before starting the development of the MVP (Minimum Viable Product), I designed mockups and prototypes to gather early feedback from key stakeholders. After multiple iterations based on their input, we presented the finalized prototype to a few regional distributors across different markets to solicit feedback. Early mockups of the Toyota Community, showcasing proposed features to solicit feedback on the design proposal. Given the feedback received, we adjusted the platform's design to align with our new business goals and highlight our key differentiators. This allowed us to begin the actual development of the MVP, with the goal of securing a proof of concept (PoC) before investing more time and resources. 🛠️ Phase 1 - Development Crafting the MVP (Minimum Viable Product) With limited resources, we designed and developed an MVP (Minimum Viable Product) that addressed the gaps and differentiated itself from existing platforms. The product came to life in July 2024 around two core features: 💬 Community Section A space for discussions around Toyota culture by creating threads and adding reactions by using emojis. Channels Dedicated to Mr. Land Cruiser: Exclusive videos featuring his garage, experiences, and interviews. A dedicated channel to ask him anything, allowing enthusiasts to connect directly with him. Toyota News Channel: A dedicated channel sharing reliable automotive news about Toyota. 🚘 Virtual Garage A dedicated space where users could showcase their cars with images and personal stories, and share them with others. Figma design screens and a timeline highlighting design stages and milestones Three mobile screens showing Garage, Home, and Community sections of the Toyota Community by KINTO platform Gathering User Feedback A critical moment for the product came after our product owner attended a Land Cruiser event in Germany . This direct interaction with Toyota enthusiasts provided invaluable insights. Attendees loved the idea of having a space to showcase their vehicles while connecting with Toyota icons like Mr. Koyari. Photos from the Land Cruiser event in Germany, featuring modified vehicles and a group photo of Land Cruiser owners and enthusiasts. Recognizing the significance of this event, we decided to create a strong presence that users could remember. I took the lead in designing a logo and marketing materials, working closely with stakeholders to create one that aligned seamlessly with both KINTO and Toyota's brand identities. A collection of promotional materials for the Toyota Community by KINTO, featuring flyers promoting the virtual garage and community benefits. This combination of user feedback and last-minute branding helped refine both our product’s direction and its visual identity , giving us a clearer path forward. 🔄 Phase 2 - Refinement Adoption and Scaling While we haven’t yet had the resources to test the MVP with a larger audience, insights gained from distributor feedback and the Land Cruiser event have guided ongoing improvements to the platform . These refinements are paving the way for the next stages of development. The Toyota Community by KINTO platform is being positioned as a scalable solution, showcasing its potential to address challenges tied to a fragmented value chain while offering the flexibility to adapt to diverse regional markets. What is Next We remain focused on fine-tuning the platform for further review and exploring opportunities to highlight its value. ✨ Conclusion A Scalable Future For Toyota's Engagement Toyota Community by KINTO offers an opportunity to reconnect and unify global engagement within a centralized hub. With additional resources, this platform has the potential to become a valuable asset, enhancing not only customer engagement but also fostering stronger brand loyalty opportunities. This project wasn’t just about UX design or feature-building . It has shown me that user-centered design’s true power lies in its ability to adapt , to both business goals and cultural needs. If you enjoyed this, feel free to explore my past articles, where I dive into topics like importance of diversity and inclusivity as well as the process of redesigning the TechBlog itself.

KINTO テクノロジーズの酒巻裕也です。 普段はデータの分析から施策提案、機械学習を用いた機能の開発に従事しています。 以前は Prism Japan のAI機能開発を担当していました。 社内で Cursor と GitHub Copilot の比較検証を行ったので、その結果をご紹介します。 前提 KINTOテクノロジーズ社内では GitHub Copilot が標準備品として使えるルールがある。 Cursor エディタを利用することで、さらに生産性の向上が見込めないか、検証する。 Cursor AIを搭載したコードエディタであり、Visual Studio Codeをフォークして作成されている。 Github Copilot GithubがOpenAIと共同開発したツールであり、様々なIDE(Visual Studio Code, JetBrains, Eclipseなど)のプラグインとして利用が可能。 免責事項 本記事には私の主観が多分に含まれます。Cursor の有用性を否定するものではありません。 検証したプラン Copilot Enterprise ... $39 / month Cursor Business ... $40 / month 結論 2025年2月時点 で、GitHub Copilot と Cursor の機能差はほぼ感じない。 2024年12月時点 では Cursor を推したかったが、Copilot の驚くべき進化速度によって、Cursor エディタを新たに選択する必要性を感じなくなった。 評価期間 2024年12月 〜 2025年2月 比較表（Copilot vs. Cursor） Copilot と Cursor を併用してみて、よく議論に上がったポイントを表にまとめました。 それぞれの項目について、詳細は後述します。 項目 GitHub Copilot Cursor UI/操作性 - VSCode上でインラインの提案やチャット可能 - 右クリックでの操作が多い - AI利用ショートカットがすぐに表示される - インラインメニューがわかりやすい QuickFix（import などの補完） - VSCode標準のクイックフィックスが強力 - 不安定で出ないことがある - Fix in Composer など少し手間 類似修正の自動反映 - 何かを書き始める必要がある - タブで次修正箇所を予測・提案してくれる (複数箇所の修正に便利) モデル選択 - 変更可能だが種類は少なめ - 追加・選択が豊富 (AIモデルを複数使い分けできる) ルールファイル - .github/copilot-instructions.md の設定で対応可能 - .cursorrules ファイルでプロジェクト毎のルールを適用可能 ドキュメント読み込み (@Docs など) - プラグイン等で対応可 - @Docs 機能でフレームワークやライブラリの文書を読み込める エージェント機能 - Copilot Chat / Copilot CLI で類似機能あり - エージェントモードで自動実行・try & error テストコード自動生成 - 生成自体は可能 (ただし精度はまちまち) - 同様に生成可能だが精度は微妙。要修正が必須。 価格 (Business/Enterprise) $39 $40 ※評価内容は 2025年2月時点の主観的なものです。 Cursor のメリット（GitHub Copilot に比べて） AI利用ショートカットがすぐに表示される コードを選択した際に AI 利用のショートカットが自動で表示されるため、特別な操作を覚える手間が省ける。 Copilot で同様のことは？ インラインチャット自体は可能。ただし他のファイルを参照する COMPOSE モードはなく、右クリックメニューから呼び出す必要があるなど、ひと手間かかる。 類似修正をまとめて提案してくれる 似たような修正を複数箇所に当てはめたいとき、Cursor だと「次にどこをどう直すか」をタブで順番に予測してくれる。 Copilot で同様のことは？ 何かを書き始めないと予測をしてくれないため、Cursorほどスムーズな一括提案は難しい。 Copilotでも同様の機能が可能に ※執筆中にも状況が変わってきました モデル選択・追加が柔軟 Cursor は自分で任意のモデルを追加・選択しやすい構造になっている。 Copilot で同様のことは？ Copilot Chat もモデル切り替えが可能だが、現状できる範囲は限定的。 @Docs 機能でフレームワーク／ライブラリのドキュメントを読み込める ドキュメントを事前に読ませておくことで回答精度を上げられる。 Copilot で同様のことは？ プラグインなどで近いことは可能だが、標準機能としてはそこまで充実していない。 エージェントモードでの try & error 自動実行 Cursor 内のエージェントモードでは、AI が一定の権限のもとコマンドを自動実行して試行錯誤してくれる。 Copilot で同様のことは？ Copilot CLI や Copilot Chat にも類似機能が出始めているが、まだ細かい部分で操作が必要。 まだプレビュー版ではあるが Copilotでもエージェントモードが利用可能に なった。 Cursor のデメリット（GitHub Copilot に比べて） import補完が少し手間 VSCode + Copilot では自動で import を補完してくれるが、Cursor ではマウスカーソルを合わせクイックフィックスを選択しないとimportしてくれない。 Copilot のほうが安定して優秀 テストコードの自動生成精度がイマイチ 自動生成をするとストレートにはテストが通らず、結局修正が必要なケースも多い。 Copilot も同様ではあるが、Cursor だからといって大きく向上している印象はなかった。 運用に合わない部分もまだ多い 開発中のアプリによっては、Cursor に含まれる AI 機能が必要以上に多く、かえって混乱するメンバーもいた。 Cursor の「Composer」と「Chat」の違い Cursor には大きく分けて Composer と Chat の2つのモードが存在します。使い方やコンテキストの扱いに違いがあるため、社内で比較した結果を簡単にまとめました。 機能項目 Composer Chat コンテキスト理解 自動的に現在のファイルを紐づける。 関連ファイルを自動提案する。 初期状態ではコンテキストが空。 必要に応じて手動で共有する必要あり 主な用途 コード生成・編集がメイン。 提案内容をインラインで即時修正しやすい 一般的な質問や説明を受ける用途が中心。 長めのやりとりに向いている 履歴管理 コントロールパネルに自動保存 チャット履歴を選択可能 UI インラインメニューでも利用可能。 サイドメニューからも操作できる サイドメニューのみ コードブロック実行 できない 可能（サイドメニュー内のChatでコマンドを実行） Composerを使うべき場面 コンテキストがシンプルなコード修正 コード生成・編集をすぐに行いたいとき Chatを使うべき場面 コンテキストが大きめのコード修正 エラーメッセージの解析、一般的なプログラミング質問 長期間コンテキストを維持しながら作業したいとき 再度結論 2025年2月時点では、Copilot と Cursor の機能差はそこまで大きくない むしろ Copilot の進化が想像以上に早く、2024年12月当時に「Cursor の勝ち」と思っていた部分を、数ヶ月で Copilot が埋めてしまった印象があります。 Cursor を使うメリットが少ないわけではない AI搭載のIDEとして専用のショートカットやエージェントモードなど、Cursor ならではの強みも依然としてあります。ただし、Copilot も対応を進めてきているため、あえて新規導入するメリットはやや薄れてきたかもしれません。 結局どちらを使うか？ もし社内で GitHub Copilot が既に標準備品として利用可能なら、当面は Copilot だけで事足りる場面が多いでしょう。 とはいえ、大規模なコード修正やチャット駆動型の開発を積極的に取り入れたい場合、現状Github CopilotでのAIエージェントはVSCode Insidersで利用可能となっていますが、Cursor の Composer / Chat 機能を試してみる価値はあります。 価格面でもほぼ同等なので、UI・操作感で選んでしまうのも一手です。 開発アプリ Prism Japan - iOS Prism Japan - Android 参考 Cursor - The AI Code Editor GitHub Copilot を使用して IDE でコードの提案を取得する 以上、Cursor と GitHub Copilot を使い倒してみた結果でした。 製品のアップデート速度はますます加速しているので、今後もぜひ定期的に検証していきたいと思います。