Hello, I am Maya from KINTO Technologies and today I’d like to quickly share a kaizen the Localization team implemented along with our Product Development team. Keeping internationalization (i18n) files aligned across systems is a challenge every growing product faces. For our team, revising the data of a specific project, together with the development team revealed how quickly inconsistencies can sneak in, and how painful manual fixes can be. The Problem When working across multiple GitHub repositories, both teams discovered a mismatch in one of the i18n files we were relying on for a product. We huddled together one day and created a problem framing grid to visualize the issue to product managers and team leads alike in the hopes to gain support (which we quickly did!) so we could work on implementing a solution. Category Details Who The Product Developers and Localization team What We found that i18n file data diverged between GitHub and Lokalise Where Issues were detected in both GitHub repositories and Lokalise projects When During cross-checking of all i18n files for a certain product project Why it matters ・Unnecessary or outdated data can accumulate. ・If left unresolved, the Single Source of Truth (SSOT) breaks down. ・Manual verification means going line by line, which is time-consuming and error-prone. The Impact By not having ways to detect data discrepancies, developers risk working with broken keys, outdated strings, or misaligned naming conventions. On the localization side, we sadly wasted effort working on content that did not exist in production. We learned the hard way that these misalignments may seem so small and harmless at the beginning, but if left unchecked, could end up creating and accumulating unnecessary data that clutters the files and leads to inefficiency. This can also contribute to higher costs and cause inconsistent user experiences in the long run. From Idea to Solution We needed a way to automatically keep track of i18n files, detect changes in GitHub as soon as they occurred, and have an alert that lets us know (the Localization side) so we could work on reconciling differences between GitHub and Lokalise before the files drifted too far apart. To achieve this, we built a GitHub Action that runs whenever a Pull Request (PR) touches any i18n file. The action inspects the files in the PR and, if changes are detected, sends an alert to a dedicated Slack channel. The Localization team is instantly notified and can decide whether a change is a legitimate key rename or removal, and whether the same update should be reflected in Lokalise. This small automation keeps development and localization in sync and sparks quick conversations before issues pile up. The following diagram illustrates how it works: 1. Repositories A to E each contain i18n files. 2. The GitHub Action monitors these files and triggers whenever a PR modifies one. 3. The Action sends an alert to a dedicated Slack channel we called #notice-localization-watcher. 4. The Localization team reviews and syncs updates with Lokalise if needed. The alert looks like this and is sent to me, the Localization team and the Product Development team we added to the channel: Benefits Using GitHub Actions to watch i18n files turned a tedious manual job into a simple, scalable process. It’s already making work smoother and saving both teams time and effort. We accomplished: • Faster detection of unnecessary data and avoiding surprises during cross-checks. • Cleaner data, keeping GitHub and Lokalise in sync as a Single Source of Truth. • Quicker team collaboration prompted by the alert, which allows us to do small check-ins via Slack between teams to check which data is needed and which isn't. Drawbacks & Next Steps Like any automation, it has its ups and downs. Although we haven't experienced it yet, frequent alerts could cause noise and fatigue, especially if every PR triggers a notification. Alerts also provide limited context as they flag that “something changed” but don’t show which keys were added, removed, or renamed at a glance unless you access the full PR. Without an even clearer way to define and maintain the source of truth, file drift can continue despite the above efforts. To improve, we plan to add diff snippets to alerts so changes are immediately visible, and filter to focus on meaningful updates like key additions, deletions, or renames. Another idea is to batch alerts into daily or weekly summaries to reduce noise. We’re excited to see how these refinements make it even smoother!

はじめに こんにちは、KINTO FACTORYのバックエンドエンジニアをしている西田です。 今回は、7/24にYOUTRUSTさん×KINTOテクノロジーズで共催させていただいた「 関西エンジニアプライド、ここに集結。Tech Boost LT 」で登壇した「開発チームに生成AIを導入して変化したこと」について、発表内容を記事としてまとめてみました。 KINTO FACTORY で取り組んでいる生成AIの活用を知っていただくきっかけになれば幸いです。 KINTO FACTORYについて KINTO FACTORY は、「安心安全なカーライフを愛車で長く楽しめるアップグレードサービス」です。 従来の新車を売って終わりではなく、販売後もお客様の幸せを量産できるように、クルマを進化させ、クルマの一生に寄り添うライフタイムサービスの提供を目指しています。 チーム体制 開発チームの体制としては、エンジニアだけでなく、PdM（プロダクトマネージャー）、デザイナー、マネージャー、ディレクターなど多様なメンバーが協力し合いながら開発を進めています。 また、東京、大阪とそれぞれの拠点にメンバーが在籍していてリモートでコミュニケーションをとりながら開発しているのも特徴です。 開発チームで抱えていた課題 ローンチしてから、約2年が経過し、サービスが成長する中で、以下のような課題が表面化してきました。 限られたリソースでの開発 複数の案件を開発することでコンテキストスイッチ負荷の増大 技術負債の蓄積 組織の拡大を見据えつつ採用活動といった人材獲得を積極的に進めつつもすぐに改善できることでもないため、 この 限られたリソースでどう戦うか が重要になってきます。 なぜ開発チームに生成AIを導入したか ここからは、開発チームに生成AIを導入した理由についてお話しします。 前述の課題を解決するための期待値と会社の環境が揃ったことが、生成AI導入の大きな理由です。 期待 増加するタスクへの効率化 開発負荷の軽減 少人数でも戦える体制作り 環境 会社として今期の開発テーマに「 AIファースト 」を掲げており、AI活用の推進が積極的に行われていた これらの要素が揃ったことで、生成AIの導入を積極的に進めることができました。 生成AI導入の歩み これまでの生成AI導入の歩みを振り返ると、コードレビュー自動化から始まり、コーディング支援、タスク実行まで生成AIツールの進化によって対応領域を広げてきました。 2024年〜 PR-Agent : レビューの自動化 GitHub Copilot (Agent) : コーディング支援 2025年〜 Devin : リポジトリ横断的な調査や開発タスクの実行 Claude Code : より高度な思考力で設計、開発タスクを実行 Devinを使った活用事例 その中でも、特にDevinを使った運用事例として実際に起きたインシデント対応を紹介したいと思います。 インシデント対応 KINTO FACTORYではインシデントが発生した際にSlackで検知する仕組みを導入しています。 通常であれば、エンジニアが手動で調査を行い、修正を行う必要がありますが、今回はDevinを使って対応することにしました。 はじめに、Slackから通知されたエラー内容を元に、Devinに調査を依頼します。 調査結果から原因が特定できたらそのままコード修正も依頼します。 細かい修正もSlack上で行うことができます。 その後、PRを作成し、approveされるとDevinから通知を受け取りマージします。 調査、修正、PR管理までをDevinに任せることで、修正までの時間を大幅に短縮することができました。 今回の対応ではこれまで2日程度かかるところを、Devinを使うことで1日で対応できました。 Devinでタスク実行する前にやっていたこと Devinにタスク実行を依頼する前に、以下のような準備を行っていました。 Knowledge機能 デフォルトで設定しておきたいプロンプトを定義 呼び出し時にインプットされた状態でタスク実行できる Devin's Machine機能 開発環境のセットアップを事前に行うことでタスク実行時のwaitingが短縮される これらの機能を活用することで、Devinにタスク実行を依頼する際の準備がスムーズになり、実行までの時間を短縮することができました。 生成AI導入後の成果 KINTOテクノロジーズでは、生産性を可視化するためのツールとしてFindy Team+を導入しています。 今回、こちらのツール上でも生成AI導入前後で変化が起きていることが確認できました。 コミットからオープンまでの時間 の改善 生成AIによるPR作成数が増え、トータルの PR数も増加 デプロイ頻度 の改善 生成AIを導入することで、開発の効率化が進み、チーム全体の生産性が向上していることが数値としても確認できました。 学び 今回、生成AIの導入を進めることで、開発チームの生産性向上に大きく寄与しました。 特に以下の点が大きな学びとなりました。 定型作業の効率化 既存コードから挙動を横断的に調査（そのまま修正も） イメージ通りになるまでプロンプトを叩く → 技術負債の蓄積を減らす 一方で注意点もあります。 生成AIの提案を鵜呑みにすると想定しない挙動（バグ）が仕込まれることも コンテキスト不足だと的外れな改修（ハルシネーション）が発生する コンテキストの解像度を高めて、最後はヒトの目を通せる仕組みが重要 であることを実感しました。 まとめ 今回、生成AIツールを段階的に導入することで活用できる領域を広げ、 生産性向上の改善に繋げることができました。 生成AIは開発者を置き換えるのではなく、開発者をエンパワーする存在です。 限られたリソースで戦う開発チームにとって、生成AIは強力な味方になることを実感しています。 私たちの経験が、同じような課題を抱えるチームの参考になれば幸いです。

弊社の大阪オフィス「Osaka Tech Lab」が7月に引越ししました。（ 新オフィスの様子はこちらをチェック ）このオフィスでは「イノベーション・新しいもの・実験を加速させること」「Osaka Tech Lab発信のプロダクトをつくること」という目標がありました。その目標に賛同してくれる人を「この指と〜まれ」で集めて、どんどん巻き込んでいこうという動きが自主的に生まれ、東京支社にいるクリエイティブ室の私のもとへも依頼がきました。 大阪オフィスメンバーの熱い想いにクリエイティブ視点で叶えたい！私もこの一員として実現したい！と思い、微力ながらジョインすることに（やりたいことをやる、この柔軟性も魅力ですね）。 まずは、新オフィスが誕生する今、どうあるべきかを可視化するために、コンセプトをつくり、オフィスのインテリアや採用プロモーションにつながるストーリーをつくることにしました。タイトルは「Osaka Tech Lab2.0 STORY」。 「Osaka Tech Lab2.0 STORY」目的に向かうまでのストーリー そもそも、大阪にオフィスをつくった会社の思いからはじまる、目指すべき未来へのストーリーを社長や副社長にインタビュー。いつかの理想を叶えるために「いま、そのためにどうするのか、どんな場にするのか」という部分がこの新オフィスプロジェクトのコンセプトになってくると考えました。 こちらの軸を基本に、社内のどの人が見てもわかりやすい言葉にし、みなの意識統一のための合言葉（コンセプトワード）をつくりました。この辺りが出てくる頃には、週一の定例で大阪メンバーと東京在籍の制作陣もコミュニケーションをとっていたので、「めっちゃブレークスルーしようや！」という意識が生まれていて、ポロッと話した言葉がそのまま活かされるなど、やわらかい頭のなかを言葉にできる楽しい会議でわきあいあいとできました。（ワイワイやろうや〜というプロジェクトマネージャーに感謝） そして、生まれたコンセプトワードがこちら コンセプト企画書時点では、「Co-LAB」の表記でしたが「CO-LAB」とCompanyの略称ではなく、 幅広い意味をもたせるため「CO」と大文字にすることになりました。 集ゴウは、やってみようの意味をもたせて「GO」とし、発シンには様々な「シン」の意味をもたせたかったので「SHIN」としました。大阪オフィスのメンバーの気合いが入っているので、コンセプトという堅苦しいものではなく、あいことばとして使っていこう！となりました。 デザイナーやエンジニア、マネージャーなど、肩書きとはいっさい関係なく意見やアイデアを伝え、形にしていきたいという気持ちがこもった言葉になりました。 あいことばは決まった！つぎは、社内外の人が集まる空間の壁デザイン 大阪オフィスには、東京の室町オフィス同様、ジャンクションと呼ばれる空間があります。社内外の人が集まり、イノベーションを起こしていく場にしようという意味でつくられた空間に、横8400mm×高さ2500mmくらいの壁になにか意味のあるグラフィックを描こうというプランが生まれました。 はい、こちらが、その壁に描いたグラフィックになります。ずっとオフィスに残るものなのでクリエイターとしてはとてもやりがいのあるものになります。Osaka Tech Labに在籍しているデザイナーと東京にいるデザイナーとでアイデアを出し合い、生成AIを駆使しながら、Osaka Tech Lab所属のデザイナーが仕上げました。あいことばである、「集GO！発SHIN！CO-LAB」や、「めっちゃブレイクスルーしよう！」がつまったデザインです。 おもしろいデザインの仕掛けは次の機会に！ 次回、コンセプト「集GO！発SHIN！CO-LAB」から生まれたデザイナーのこだわりが詰まった壁や、 LP についての制作ストーリーを書いてみたいと思います。

Hello! I'm Kasai from the SRE Team. KINTO Technologies Corporation (hereinafter referred to as KTC) will be a platinum sponsor of "SRE NEXT 2025" which will be held at TOC Ariake on Friday and Saturday, July 11 and 12, 2025. This will be KTC’s first time sponsoring SRE NEXT. Our SRE Team got a fresh start last year. While we face the daily challenges of practicing SRE, we continue to work on improving the reliability of our services. I’m sure many of you are also going through the similar process of trial and error. We decided to become a sponsor because we wanted to support a space where SREs can come together and connect. What is SRE NEXT? SRE NEXT is a conference for engineers with a strong interest in reliability practices. It is organized and hosted primarily by members of "SRE Lounge," another community-based SRE study group. The theme of SRE NEXT 2025 is "Talk NEXT." Building on the values introduced at SRE NEXT 2023— Diversity, Interactivity, and Empathy—the event will provide a space for discovering new insights through discussions and communication on a wide range of SRE-related topics, including technology, organizational design, and talent development. Home | SRE NEXT 2025 Event Overview Date: July 11 (Fri) and 12 (Sat), 2025 Venue: TOC Ariake and Online Official Website: https://sre-next.dev/2025/ There Will Be a Sponsored Session! On Day 2 (July 12), from 13:00 to 13:20 on Track B, Osanai will be holding a sponsored session titled: "What Does an SRE Do in a Role-Fragmented Organization?" In a fragmented organization where roles often overlap, questions naturally arise, such as "What should we be doing?" and "Where does the value of SRE lie?" This session will share how our SRE Team has faced and worked through questions like these. Details: https://sre-next.dev/2025/schedule/#slot081 We’ll Also Have a Booth! We’ll have a short and easy questionnaire available at our booth. If you participate, you can spin a gachapon machine for a chance to win original novelty items. Be sure to stop by and give it a try! Our SRE Team members will also be at the booth, so come and talk with us about SRE.

はじめに こんにちは、2025年6月入社のemimです！ 本記事では、2025年6月入社のみなさまに入社直後の感想をお伺いし、まとめてみました。 KINTO テクノロジーズ（以下、KTC）に興味のある方、そして、今回参加下さったメンバーへの振り返りとして有益なコンテンツになればいいなと思います！ Jun 自己紹介 業務システム開発部 業務システムGで、中古車を扱う業務システムを担当しています。 前々職はSIerにて受託開発案件のPMをしたり、前職ではスタートアップでB2BのSaaSプロダクトの開発をしたりしていました。 所属チームの体制は？ 私が所属しているチームはKINTOで扱う中古車の業務で使うシステムの開発と運用を担当しています。 私が所属しているチームには私を含めKTCのメンバーが5人います。開発（プログラミング）の大半をパートナーさんに委託しており、KTCのメンバーは主にプロダクトマネージメント、プロジェクトマネージメント、要件定義、システム設計、運用保守を担当しています。 現場の雰囲気はどんな感じ？ 事業の拡大に合わせて常に業務とシステムの見直しが動いており、また、新しい技術の活用なども積極的に推進されていて飽きる暇がない雰囲気です。 現在担当しているシステムではバックエンドにはJava、フロントエンドはVue3を使っています。AIの活用はまだあまりできていないですが、GitHub CopilotやDevinを開発で活用しようとしています。 KTCへ入社したときの入社動機や入社前後のギャップは？ ITと事業が直結している会社にてシステム開発をしたくKTCへ入社しました。業務・システム運用を楽にするための開発にもっと時間を割きたいところですが、まだそこまで手が回っていません。 オフィスで気に入っているところ 日当たりが良いところに小さな休憩スペースと給茶機があり、いつもそこで昼食を食べています。特に豪華な設備があるわけではないですが、良い気分転換になります。 Sさん ⇒　Junさんへの質問 いろいろな車に乗りたいとおっしゃっていたので、今一番気になっている車とその理由を教えてください！ GRヤリスです。本格的なスポーツカーに乗ってみたいです。 なかの  自己紹介 DXソリューションGという販売店向けのDX支援を行うチームに所属しています。PdM業務や今後の計画業務などに携わっています。 所属チームの体制は？ PdM+デザイナーで8名で構成される、販売店DXプロダクトの設計やディレクションを担うチームです。 同部門中の営業や開発チームの方と連携してプロジェクトを進めます。 現場の雰囲気はどんな感じ？ 穏やか、優しい、シゴデキな方ばかり！ システム開発だけでなく、複雑な販売店業務への理解・興味をみなさんがもたれている事に驚きました。 KTCへ入社したときの入社動機や入社前後のギャップは？ 前職が広告代理店でITは事業の一部だったので、会社の軸がIT & 知見のある方が集まる会社で働きたい！と考えていました。入社後もそういう方々の集まりだ、という印象は変わりません！ オフィスで気に入っているところ Osaka Tech Lab所属で、自席から見える大阪一望の窓がめっちゃ気に入っています。（どの席からでも見える） 山も見えて、仕事の合間で癒やされる景色があるのはありがたい... Junさん ⇒　なかのさんへの質問 KTCに入社して、ここがすごい！と思ったことを1つ教えてください 🙇 前のめりでポジティブな方が多い所です！ 入社してから常に情報が動き続けていて、みなさん仕事、技術、拠点の成長、他色々…前のめりに取り組まれているんだなと感じます。（Osaka Tech Labの一体感はホントにすごい） Kazuki Otaka 自己紹介 6月にクラウドセキュリティグループにJOINした大高です！業務では、クラウドセキュリティ分野に携わっており、CSPMや脅威検知の仕組みを活用して、マルチクラウド環境のガードレール監視とカイゼン活動を行っています。過去にテックブログにも投稿していますので、ぜひご覧ください。（過去の投稿は、 こちら ） 所属チームの体制は？ Osaka Tech Labに2名と、神保町オフィスに1名の3名体制です。 現場の雰囲気はどんな感じ？ 落ち着いた印象で、フレンドリーな人が多い印象です。社内では勉強会やLT大会やBeer Bashなども頻繁に開催されています。技術力の高くプロフェッショナルな人もたくさんいるので、自分も置いていかれないように頑張りたいと思います！ KTCへ入社したときの入社動機や入社前後のギャップは？ 前職では、オンプレミス環境のシステムの構築に携わる機会が多く、クラウド環境を用いたシステム構築・運用のスキルを身につけたいと考え、フルクラウドでシステムを構築しているKINTOテクノロジーズに入社を決めました。AWSを中心にIaC化が進んでいたり、生成AIの検証・活用を進めていたり、想像していた以上にクラウドインフラ運用の最前線の環境にあると感じています。 オフィスで気に入っているところ 普段は静かで落ち着いた感じですが、突然、社内に機器が設置されて、PoC（概念実証）が始まるところなどは、新しいことにチャレンジしていく雰囲気が肌で感じられて意外と気に入っています。 なかのさん ⇒　Kazuki Otakaさんへの質問 セキュリティ界隈の仕事のおもしろさ、難しさを教えてください！ セキュリティは、被害が生じるとビジネスに大きな影響を与えるリスクがありますが、逆にセキュリティを高めすぎるとビジネスや開発を阻害する可能性があります。サイバー攻撃も進化する中で、いかにビジネスの成長を妨げずに、必要なセキュリティを実装・運用していくかのバランスが難しいところでもあり、逆に面白い部分でもあるかなと思っています。 ゆな  自己紹介 業務システム開発部 業務システムGで、販売店の方が利用する業務システムのチームに所属しているゆなです。現在は、販売店が商談時に利用するシステムのリニューアルプロジェクトを担当しています。 最近、KINTOで契約した車が納車され、毎週末ドライブへ出かけるのがすっかり趣味になりました。 所属チームの体制は？ 私含めてプロパー3人のチームです。リーダーともう一人のメンバーから日々サポートを受けながら、要件定義や保守運用に取り組んでいます。新しい知識やスキルを吸収しながら、着実に貢献していけるよう取り組んでいます。 現場の雰囲気はどんな感じ？ チーム内外問わず温かく迎え入れてくださって、とても良い雰囲気です。 KINTOの商品や業務は複雑で、把握すべき情報も多いですが、丁寧に教えていただきながらキャッチアップし、業務を進められています。 KTCへ入社したときの入社動機や入社前後のギャップは？ 前職に引き続き、プロダクトマネージャーとして入社しました。 自身のキャリアをさらに伸ばすため、「自分がプロダクトマネージャーとしてやりたいことを実現できそうか」という観点で会社を探し、KTCに出会いました。 面接では現マネージャーやリーダーの方とお話しし、具体的な業務内容を確認できたこと、また社員の皆さんの雰囲気が良かったことが決め手になりました。 入社前から、前職よりもテック寄りの領域に関わることは理解していましたが、業務が始まり、より高いスキルが必要だと実感し、現在は日々勉強しています。 オフィスで気に入っているところ 室町オフィスの16Fで働いています。三越前駅・新日本橋駅から地下直結でアクセスできるので、雨の日も快適です。 ビル内にはスタバがあり、周辺には飲食店やショップも多く、とても便利な環境です。昼休みに少し散歩をすると良い気分転換になり、午後の仕事もはかどります。 Kazuki Otakaさん ⇒　ゆなさんへの質問 趣味のお菓子作り・パン作りで、一番お気に入りのものはありますか？私もパンにハマっていた時期があり、学芸大学付近にあるパン屋さんに通っていました！ 夏らしく、旬のとうもろこしをたっぷりのせた「マヨコーンパン」を作るのが最近のお気に入りです。甘いとうもろこしとマヨネーズの香ばしさがふんわりしたパン生地にしみ込んで、焼き上がりを待つ時間も幸せになります。 emim  自己紹介 Engineering Officeという組織横断チームで、組織全体の開発力を高めるための分析や仕組みづくり、各部署やチームへの働きかけ等をデザイナー目線で行っています。 所属チームの体制は？ チームには私を含め3名しかおらず、一人はフロントエンド開発が本職ながら組織全体に目を向けているマネージャー、もう一人はソフトウェアプロセス改善を軸に開発生産性を見られています。私は開発組織の中でのデザイナーのプレゼンスを上げる為の様々な取り組みを行っています。 現場の雰囲気はどんな感じ？ Engineering Officeが極めて特殊で、それぞれが全く違うことに取り組んでいる一方で、拠点も一箇所なわけでもないのに情報共有及び連携がものすごくしっかりしています。少し特殊な技能を持ったメンバーが集まっているからこそな気がしています。 KTCへ入社したときの入社動機や入社前後のギャップは？ 元々クルマも好きだったのもありますが、モビリティ業界はとても遠いと考えていました。私がこれまで身につけてきたスキルを転用できる所があると気づき、応募しました。 入社前にかなり解像度の高い情報共有をチームメンバーからできていたので、そこまでギャップは持っていません。 オフィスで気に入っているところ 日本橋室町という立地自体が、毎日の出社がとても楽しいです。 ゆなさん ⇒　emimへの質問 映画やドラマがお好きとのことだったのですが、これまでに見た映画やドラマで、“デザインの仕事に活きた”作品はありますか？ 趣味を覚えててくださってありがとうございます！SFがとても好きで、見たことのないようなUIや端末が出てくるのに毎度ワクワクしています。デザインの道を選んだのも、あんな未知のデバイスのデザインがしたかったのがもとで、どんな情報端末でも正しく情報提供出来るような情報設計……という志向で、デザインについて学んでいる／向き合っているフシがあります。 Taka  自己紹介 n=1と統計のあわいで思考して戦略を作るのが生業だと思っています。目標達成のための定量データ分析とデプスインタビューが大好きで、ずっとやってられます。自分が人生において発露してきた重要な衝動は3つで、「Observe（観察する）」「Weave a story（物語を紡ぐ）」「Curate（再構成する）」です。 所属チームの体制は？ 事業会社（大企業〜スタートアップ）経験者と、優秀なデータアナリスト、優秀なエンジニアが所属しています。 現場の雰囲気はどんな感じ？ カルチャーとしては目標達成マインドを大事にしているチームです。前例にとらわれずに、自発的に問題解決を行って行く姿勢が重視されています。 KTCへ入社したときの入社動機や入社前後のギャップは？ 入社動機は、自動車業界が世界的に変革期にある今、重要なのはn=1起点のマーケティングだという仮説を持っており、それを実践し、変革を推進するため。 オフィスで気に入っているところ 室町オフィス16Fの大きな窓から入る明るい陽射しです。窓の周囲が大きなビルで囲まれていないから、大きな空と自然光を感じながら仕事ができるのを嬉しく思っています。 emim ⇒　Takaさんへの質問 これまでジョブチェンジされながら色々なお仕事をされてきたと伺っていますが、もしやり残した仕事があればそれを教えていただきたいのと、現在の（最高の）スキルを持った上でのKTCでの野望を教えてください！ そうですね、ジョブチェンジして来ましたが、実は軸は変わっていないと捉えていまして、やって来たことは「人と人とを繋げるためのデザイン」だと思っています。やり残したことは起業してないことです。野望は入社動機に書いた通りになります！ S  自己紹介 KINTO ONE（新車サブスクサービス）のフロントエンド開発を行うチームに所属しています 所属チームの体制は？ メンバー構成はエンジニア8名（東京6名、大阪1名、福岡1名）です 開発の体制はスクラム開発を採用しており、1スプリントを1週間として進めています 現場の雰囲気はどんな感じ？ 私は大阪所属で1人なので基本的にオンラインでのやり取りになりますが、気軽に質問もしやすく良い雰囲気の中で仕事ができています チャットで質問などをしてもすぐに返事が返ってくるので業務で困ることもありません KTCへ入社したときの入社動機や入社前後のギャップは？ 入社動機はモビリティ領域がこれからさらに発展していく分野だと考えており、その成長を支えるプロダクト開発に携わりたいと思ったからです 入社前にチームの状況などはしっかりと聞くことができていたので、ギャップはほとんどありませんでした オフィスで気に入っているところ やはり大阪駅直結で通勤しやすい・オフィスが広くて綺麗なところと、オフィス内にガレージや道路を模したところがあるのが面白いなと思います Takaさん ⇒　Sさんへの質問 Sさんが、ご自身ではとても好きなことや興味深いことなのに、人に話したら少し相手に引かれたエピソードがあれば教えてください。（そこにSさんの衝動が隠れていることがあります） 普段の食事で完全栄養食が準備に手間がかからず楽なので、いろんなメーカーのものを試しています。冷蔵庫の中もほとんどそれで埋まっているのですが、周りの人に話すと「考えられない」とよく言われます さいごに みなさま、入社後の感想を教えてくださり、ありがとうございました！ KINTOテクノロジーズでは日々、新たなメンバーが増えています！ 今後もいろんな部署のいろんな方々の入社エントリが増えていきますので、楽しみにしていただけましたら幸いです。 そして、KINTO テクノロジーズでは、まだまださまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくは こちら からご確認ください！

Introduction Hello! I'm high-g ( @high_g_engineer ) from the New Car Subscription Development Group at the Osaka Tech Lab. In this article, I'd like to introduce the front-end study group that we started within the company. Background One day, I had the opportunity to show my supervisor the TSKaigi 2024 timetable during a one-on-one meeting in the New Vehicle Subscription Development Group. He responded positively, saying, "This covers a wide range of topics and is a great teaching material. It'd be great if we could use this to hold study sessions where front-end engineers across departments to share insights and build horizontal connections." Those words prompted me to reach out to front-end engineers who seemed eager to join, and I began planning an in-house study group. Purposes of the Study Group This study group has three goals: Learning : Deepen our understanding by discussing and sharing presentations from external conferences and web standards Applying : Take what we learn and put it to use in real projects Sharing : Share the outcomes, challenges, and insights from real-world applications to accumulate knowledge across the organization This is a practical study group that aims not to simply acquire knowledge, but to get to the point where we can actually use it on the job. We set aside a one-hour time slot once a week and conduct the sessions in a format appropriate to the content, such as read-along, mob programming, hands-on sessions. Main Themes and Development History Since September 30, 2024, 34 events have been held to date, and the following topics have been addressed: Sharing insights from conferences and tech events (Session 1 to 17) To get things rolling, we focused on the latest trends in front-end technologies using presentations from events like TSKaigi 2024 and JSConf JP 2024 as starting points. Thinking about the Future of Prettier (Session 1): The future direction of code formatters Improving TypeScript Performance (Session 2): Comparing with issues in actual business code **This is What Happened When We Unified Everything with TypeScript! ** (Session 3): A full-stack development case study TypeScript Journey: Helpfeel's journey of trials and errors on the road to success (Session 5) Type-Safe and Efficient Routing with TanStack Router (Session 7) ** Storybook-Driven Development: Reproducibility and Efficiency of UI Development ** (Session 9) Setting Trust Boundaries Instead of Blindly Relying on TypeScript Type Declarations (Session 10) LAPRAS Open Performance Tuning by Mizchi-san (Sessions 12-13): Performance improvement learned from external case studies ** Micro-Frontends on the Top Page of Yahoo! JAPAN** (Session 15): A development example from a large organization JavaScript Module Resolution Interoperability (Session 16) You Don't Know Figma Yet - Hacking Figma with JS (Session 17) Cross-Team Knowledge Sharing & Understanding (Sessions 18-24) As more people joined, we started sharing personal skills and the status of each division's front-end team. This helped shape the future direction of the study group and gave us a chance to review different projects at the code level. It also allowed us to identify common front-end challenges across KINTO Technologies. Looking Back So Far (Session 18): Discussing the direction of the study group Self-Introductions with Career Backgrounds (Session 19): Promoting mutual understanding among members Frontend Development Status Sharing Session for Each Team (Sessions 20-24): A five-session series in which each team shares their tech stack, ongoing challenges, and current initiatives in detail Understanding and Applying Web Standards (Sessions 25-28) At the retrospective session, some expressed interest in better understanding web specifications. Therefore, we decided to dive into the Baseline project together. https://web.dev/baseline?hl=ja Dive into Baseline (Sessions 25-27): A systematic study of web standards in a three-session series Baseline Review and Discussion of Next Steps (Session 28): Summarizing what we learned and discussing what to explore next Practical Performance Improvement (Sessions 29-Present) Using Mizchi-san's public performance tuning video as a reference, we began applying performance improvements to actual products. https://www.youtube.com/watch?v=j0MtGpJX81E ** FACTORY Performance Improvement** (Sessions 29-30): A two-session series sharing specific optimization strategies and the results TSKaigi 2025 Presentation Sharing Session (Session 31): Preview of presentation content by internal members ** KINTO ONE Performance Improvement** (Sessions 32-34): A three-session series where everyone worked on real performance improvements through mob programming, resulting in our most hands-on learning experience The Impact of Ongoing Sessions Increasing and Retaining Participants We kicked off the study group with just 5 members, but over time and with consistent sessions, it's grown into a group of over 10 regular members. Participants are not only from the New Vehicle Subscription Development Group but also from other groups, realizing horizontal connections. Many of the original members are still actively involved and the retention rate of new members is also high, proving that this study group has become a truly valuable space for everyone. Gradual Improvement of Organizational Technical Capabilities Knowledge gained from conferences and tech events often stays at the individual level, but by learning simultaneously with front-end engineers from each department who have different perspectives on issues, not only does it benefit the entire organization, but it also leads to insights that are hard to gain alone. Members who consistently took part in the Baseline series now understand web standards at a specification level, rather than just using the technology vaguely, which helps them make more well-founded decisions when choosing tools for their work. Acquiring Practical Problem-Solving Skills In the most recent sessions, we used a mob programming format to work on improving the performance of actual products such as KINTO ONE and KINTO FACTORY. By applying the knowledge gained in the workshop directly to the product and actually doing it, the participants were able to overcome their aversion to performance tuning. This was a practical and valuable initiative that also led to increased sales. Deepening Technical Collaboration Between Teams Through the development status sharing sessions, we've had more chances to learn about the technical efforts and challenges of other teams that we hadn't fully understood before. As a result, there's been a growing number of cases where teams with similar issues follow up individually after sessions to consult and collaborate. The study group is no longer just a place for learning; it's becoming a hub for solving real business challenges. Conclusion This study group, which was started with the aim of strengthening horizontal connections between front-end engineers within the company, began by sharing knowledge at external conferences and has now evolved into performance improvement based on actual products. We plan to keep it going, fostering collaboration while helping raise the overall technical proficiency of the organization.

Hello. My name is Momoi ( @momoitter ), and I’m a designer in the Creative Office at KINTO Technologies. In this article, I’ll walk through the process of using Midjourney V7’s new Omni-Reference feature to keep the look of the original character KTC AI WEB consistent. This article is for: Those who want to learn more about Omni-Reference in Midjourney V7 Those looking to generate character images with a consistent look Those interested in creating high-quality visuals using AI tools I’ll walk through how to use Omni-Reference, along with tips for fine-tuning, using actual prompts and generated images. What is Omni-Reference? In May 2025, a long-awaited feature called Omni-Reference was introduced in Midjourney V7. This feature allows you to generate new images while maintaining visual consistency by referencing a specific image. It is now possible to maintain characterization, which was previously difficult in V7, and it’s not limited to people; it works with objects and vehicles, too. There’s also a parameter called Omni Strength (ow), which lets you fine-tune how closely the output follows the reference image using numerical values. About "KTC AI WEB" What is KTC AI WEB? In November 2024, an AI-generated character named KTC AI WEB made her debut in the opening video of KINTO Technologies’ internal event CHO All-Hands Meeting. Since then, she’s served as a navigator, appearing at developer events and recruitment events to help introduce KINTO Technologies. Read the story behind KTC AI WEB’s creation here. https://blog.kinto-technologies.com/posts/2025-03-07-creating_a_mascot_with_generative_AI/ Why Unify Her Appearance? Since the birth of KTC AI WEB, image and video generative AIs have evolved rapidly. As a result, her original visuals started to feel a bit outdated. Shortly afterwards, Midjourney V7 and Runway Gen-4 were released, dramatically improving generation quality. We also decided to update KTC AI WEB’s visuals at this time. See the update process. https://blog.kinto-technologies.com/posts/2025-06-06-ai-character-movie-making/ However, while V7’s expressive power is extremely high, it didn’t initially offer a way to keep a character’s appearance consistent. KTC AI WEB’s face changed slightly with each generation. Furthermore, while the update improved quality, it came with a side effect—some of KTC AI WEB’s original approachable charm faded. Meanwhile, in May 2025, a new feature called Omni-Reference was added to Midjourney V7. I used this feature to reconstruct an "evolved KTC AI WEB" that combines the beauty and realism of V7 with the original character’s look and feel. Let’s Put it into Practice! Consulting ChatGPT To start, I asked ChatGPT the following: I want to upload an image to Midjourney V7’s Omni-Reference to generate a front-facing image of this pink-haired female character with a clean background while keeping her look consistent. Give me some prompts for Midjourney." ChatGPT responded with these prompts: upper body portrait of a female virtual operator in a clean futuristic interior, facing camera directly, symmetrical composition, looking straight ahead, centered, gentle expression, slightly relaxed face, subtle smile, brightly illuminated face, soft front lighting, high key lighting on the face, studio-style lighting setup, clear and vivid facial features, softly lit background, minimalistic sci-fi control room, white and silver tones, crisp details How to Use Omni-Reference Step 1: Drag and drop the image Drag the image you want to reference into the Midjourney prompt input box. A bar labeled Omni-Reference will appear at the top of the screen, drop it there. Step 2: Adjust Omni Strength (ow) Omni Strength allows you to adjust the strength of consistency (how closely the output matches the reference image). The numerical value is specified by the parameter called ow. Step 3: Start generating Enter the prompt you got from ChatGPT and start generating! Changes by "ow" values Low ow (e.g. 100-200): Less similar to the original image, but with Midjourney’s signature soft, beautiful rendering. High ow (e.g. 800-1000):Closer to the original image, but with less of Midjourney’s distinctive feel. ow100 ow200 ow400 ow600 ow800 ow1000 Finding the Right Balance After much trial and error, I found that setting ow between 200 and 400 worked best for updating KTC AI WEB. With these values, the output preserved her original features while still capturing Midjourney’s signature soft, beautiful rendering. At one point, "This is it!" I came across an image that felt just right. It was the ideal image capturing KTC AI WEB’s feature with Midjourney’s signature fine, delicate beauty. Expanding Scenes and Building a World Using the final image as a base, I expanded the composition and backgrounds using Omni-Reference. I also consulted ChatGPT again to get scene ideas and prompts for Midjourney. Having a solid base made it easier to build out a consistent world around her. The updated look for KTC AI WEB is also featured at the start of the company’s introduction video. https://www.youtube.com/watch?v=8Df_0StDAiw Application: Expanding to Other Internal Content KTC AI WEB was also featured in presentation materials for a recent internal study session. Thanks to Omni-Reference, there’s no need to stress over whether the visuals stay on-model, making it much easier to use her across slides, event visuals, and other materials. Tips Learned Through Practice Omni-Reference is a very powerful feature, but the reference can be too strong. Want to change the outfit -> Attach an image that only shows the face Want to change the hairstyle, too -> Focus on just the eyes or another minimal area Fine-tuning the reference range like these allows for consistent facial features while preserving Midjourney’s signature creative flexibility. Summary: A Time When Anyone Can Create "KTC AI WEB" The introduction of Omni-Reference has made it possible to create high-quality scenes while maintaining consistent character visuals. In other words, we’ve entered a time when anyone can create something like KTC AI WEB. It feels like a waste to keep her confined to my own imagination. That’s why I hope KTC AI WEB will continue to grow through the creativity of everyone in the company. I want to expand the range of expression and help her spread her wings even further. As AI technology continues to evolve, so will KTC AI WEB.

はじめに こんにちは。KINTOテクノロジーズ株式会社（以下、KTC）でプロダクトマネージャー（以下、PdM）をしているK.Ichinoseです。 「PdMって企画を考えるだけの仕事じゃないの？」 そんなイメージを持っている方も多いかもしれません。実際には、日々の業務は多岐にわたり、関わる人も多種多様です。 この記事では、私が担当している 「KINTO FACTORY」 のPdMとしての一日を通して、KTCのPdMのリアルな働き方をお伝えします。 読んだ後に、「PdMって面白そう！」「KTCで働くイメージが湧いた」と感じてもらえたら嬉しいです。 KTCにおけるPdMの役割とは？ 一般的にPdMは、プロダクトの方向性を定め、企画から開発、リリース、改善までをリードする役割です。 KTCの場合、 モビリティサービス に関するプロダクトを扱っています。 私はその中で、 KINTO FACTORY （以下、FACTORY）というサービスを担当しています。 FACTORYは、TOYOTA・LEXUS純正オプションを正規販売店で「後付け」ができるアップグレードサービスです。 これにより、購入後でも最新の機能やパーツを追加でき、クルマの価値や使い勝手を高められます。 私は「プロダクトマネジメントトライアングル」でいうところの開発者寄りの領域を主に担当し、ビジネスと開発者の橋渡しを担っています。 データ分析も最近始めています。 図はPdMの役割を「ビジネス」「顧客」「開発者」の3領域で表したものです。 具体的には、企画や要求をヒアリングして要件を整理し、開発スケジュールを組み、リリースまで推進します。 さらに、KTC全社で複数プロダクトを横断する開発案件では、社内調整や他チームとの連携も重要な仕事です。 PdMの一日の流れ ここでは、私の一日のスケジュール例をご紹介します。 （KTCはフルフレックス制ですが、私は毎日ほぼ同じ時間に始業しています。規則正しい方が集中できるタイプです） 時間 活動内容 09:30 始業・メールチェック Slackやメールを確認し、今日のタスクを整理します。 「誰に確認が必要か」「今日中に決めるべきことは何か」をこのタイミングで把握します。 10:00 朝会（デイリースクラム） 開発チームと進捗や課題を共有。 小さな課題でも早めに共有することで、後の大きな遅延を防ぎます。 10:30 開発チーム内レビュー PRD（プロダクト要求文書）やDesignDoc（設計ドキュメント）、その他仕様書のレビューを行います。 11:00 ビジネス担当(トヨタ or KINTO)と定例ミーティング FACTORY関連の新機能要件や仕様を確認します。 KTCからの提案や要望を伝えることもあります。 12:00 昼休憩 オフィス周辺でランチ(会社のある室町は少々お高め・・・)。 13:00 要件整理・提案資料作成 企画段階で受け取った要求を要件に落とし込み、エンジニアやデザイナーと共有できる形にまとめます。 15:00 開発案件の実現性、工数確認 エンジニアリーダーと要件をすり合わせ、実現方法や課題、必要工数を確認します。 ここで現実的なスケジュールを固めます。 16:00 社内全社PJの定例ミーティング 複数プロダクトにまたがる案件の進捗や課題、スケジュール調整を行います。 17:00 データ分析 利用データを分析してユーザー傾向を把握。改善のヒントを探ります。 随時 問い合わせ対応 KTC内の仕様や設計に関する質問、運用改善、テスト改善、リリース調整などを行います。 また、KINTO/トヨタからの新機能や、運用相談など多岐にわたります。 KTCのPdMとして働く魅力 モビリティ業界の未来に関われる クルマの価値を高める という新しい挑戦に直接関われます。 様々なステークホルダーとのコミュニケーション トヨタ、KINTO、社内外のさまざまな立場の方と関わり、異なる視点からの意見を聞けるのは刺激的です。 チームの雰囲気 役職や年齢に関係なく意見を言いやすく、議論も前向きです。 やりがい FACTORYはまだ世の中で認知度が高くない新しいサービスです。 その分、成長の余地が大きく、方向性に関わる仕事はサービスの成長をダイレクトに感じられます。 自分が関わった機能がリリースされ、実際にユーザーが申し込みしてくれる瞬間は大きな達成感があります。 これからKTCのPdMを目指す方へ 私が思うKTCで活躍できるPdMの条件は、次の3つです。 コミュニケーション力 関係者と信頼関係を築き、スムーズに情報をやり取りできる力。 柔軟さ 変化を前向きに受け入れ、改善につなげられる力。 プロダクトへの愛着 担当するプロダクトを深く理解し、こだわりを持てること。 特に3つ目は、仕様や細部へのこだわり、改善アイデアの源泉になります。 愛着を持つことでチーム全体のモチベーションにも良い影響を与えられます。 おわりに KTCのPdMは、変化の激しいモビリティ領域で、まだ新しいサービスをより良い形に育てていくやりがいのある仕事です。 この記事が、「PdMって面白そう！」と思うきっかけになれば嬉しいです。 もし興味を持っていただけたなら、ぜひ一緒にKTCで未来のモビリティをつくりましょう！

Introduction Hello, I'm Tetsu, and I joined the company in March 2025! In this article, I interviewed new members who joined us in March 2025 and gathered their first impressions after joining KINTO Technologies. I hope this article will be helpful for those interested in KINTO Technologies (KTC from now on) and serve as a nice reflection for those featured here! Osada Yoshihiro Self-introduction My name is Osada from the Group Core Systems Division. I’m in charge of the Business Development Team and the global community website TOYOTA Community by KINTO. How is your team structured? There are about 40 members in the Group Core Systems Division. We have members from various countries who communicate in Japanese, English, and various other languages. Our division includes the Business Development Group, the Systems Development Group, and the Common Service Development Group. The Business Development Group is responsible for global leasing systems. The Systems Development Group handles the planning, development, and operation of the Global KINTO ID Platform and TOYOTA Community by KINTO. The Common Service Development Group develops and manages the Membership Platform, the Payment Platform, and the recently launched AI Platform. **What was your first impression of KTC when you joined? Were there any surprises? ** I noticed that the company offers a variety of club activities and after-hours events, like the optional Beer Bash. The automotive club in particular seems very active, with events like race viewings and circuit karting. Even non-members can join some of the events, which gives the impression that both work and club life at KTC are full of energy. What’s the atmosphere like on the team? We start each day with a cheerful “Good morning!” Our team is made up of people from different countries and professional backgrounds, and we make progress through open and friendly discussions. **How did you feel about writing a blog post? ** I thought it was a great opportunity to help others learn more about KTC and the Group Core System Division.　It also gave me a chance to reflect on my own experience. KJ-san -> Question to Yoshihiro Osada-san I heard you’re a big fan of movies. Could you recommend a few that you think are must-sees? One movie I’d really like everyone at KTC to watch is "Tucker: The Man and His Dream." It’s a 1988 American film directed by Francis Ford Coppola and executive produced by George Lucas, with an outstanding team behind it. It’s set in a different era, but the passion for cars really comes through. Tetsu Self-introduction My name is Tetsu, and I work as a platform engineer in the Platform Group! How is your team structured? I belong to the Platform Engineering Team within the Platform Group, which consists of six members at the Jimbocho office and three members at the Osaka Tech Lab. Even though there’s a physical distance between Tokyo and Osaka, we stay connected using tools like Slack, Gather, etc. We also plan study sessions together with members from both locations! **What was your first impression of KTC when you joined? Were there any surprises? ** Nothing big in particular. At first, I thought it might be hard to communicate with people from other teams since our offices are in different locations. But thanks to events like BeerBash and active internal clubs, we have plenty of chances to interact with other teams, which makes our work much smoother. What’s the atmosphere like on the team? We have serious technical discussions and enjoy casual chats during breaks in a friendly atmosphere. When I mentioned that I wanted to study Kubernetes, some members in Osaka said they were interested too. That’s why we decided to plan study sessions together, and now we hold them across different groups, including Cloud Infrastructure Team and the DBRE team. **How did you feel about writing a blog post? ** I used to read blog posts like this when I was thinking about changing jobs. So now that I’m the one writing it, I feel a bit nervous, especially when I think that someone out there might be doing the same. (laughs). Yoshihiro Osada-san -> Question for tetsu-san Can you recommend some good lunch spots around the Jimbocho Office? I’m a big fan of noodles, so I often go to Marugame Seimen or Kasugatei for abura soba (soupless ramen). There’s also a tendon (tempura rice bowl) place called Hachimaki that I’ve been curious about, so let's check it out together next time you come to Jimbocho! YY Self-introduction I'm a back-end engineer in the Common Service Development Group. How is your team structured? We have 13 members working on development at the Muromachi office. **What was your first impression of KTC when you joined? Were there any surprises? ** I felt very reassured by how well the onboarding and follow-up process was set up when I joined the company. I was also impressed by the team’s strong culture of thorough documentation, which helps accumulate and share operational know-how. What’s the atmosphere like on the team? I think everyone works with mutual respect. Our team policy is to "speak up without hesitation," and it's a really reassuring environment where someone is always willing to help if you're stuck. **How did you feel about writing a blog post? ** I've never been the type to take the initiative with things like this, so I was very happy to be given the opportunity. I also hope it lowers the barrier for me to write more in the future. tetsu-san -> Question for YY-san I think you mentioned that you had a car when you joined the company, but do you have any particular preferences when it comes to yours? I'm not sure if you’d call it a “preference,” but I guess I’d say choosing the body color I like. Even if I payed additionally for it, I went with the one that catched my eye, without worrying about resale value. Namiki Yuji Self-introduction My name is Yuji Namiki, and I’m part of the Innovation Drive Team within the Corporate IT Group. I mainly work on solving problems in KTC's M365 environment, verifying and implementing new technologies, and supporting the IT operations of dealers. How is your team structured? There are nine members in the team, including myself. Our members are spread across multiple locations: Muromachi, Jimbocho, and Nagoya. **What was your first impression of KTC when you joined? Were there any surprises? ** My first impression was, “People respond on Slack incredibly fast!” I was surprised by the overall speed of communication. It felt like the entire organization shares a strong habit of quickly checking Slack notifications and replying right away. Something I didn’t expect was how well-organized the internal documentation already was, considering how new the company is. I was also impressed by how effectively tools like Confluence and SharePoint are used. If I ever have a question, I can usually solve it myself by asking our in-house generative AI or checking the internal portal. That kind of environment was a pleasant surprise. What’s the atmosphere like on the team? It's a friendly atmosphere where it’s easy to start a conversation or invite someone out for a meal. There are lots of great restaurants around the office, so lunch is always something to look forward to. Having some mazesoba (mixed noodles) after work is also a highlight. We have good working relationships with team members at other locations too. Being able to meet and work with them in person every few months really helps. I also appreciate how company events make it easy to connect with people from other departments. (It's only been three months since I joined, but I’ve already had the chance to talk to around 50 to 70 people from other divisions. That makes me really happy!) **How did you feel about writing a blog post? ** I was honestly happy when the team managing the Tech Blog reached out to us directly. After joining the company, I had been wanting to write for the Tech Blog, and this also gave me a great chance to reconnect with my fellow new hires. I’d like to take this opportunity to keep writing and posting on the Tech Blog in the future. (Aiming for one post a month!) YY-san -> Question for Namiki Yuji-san We're both in the same sauna club. Are there any sauna spots you're interested in lately? I’m really curious about Everyday Sauna Koshigaya (in Japanese), which just opened this May! It’s the third branch, following Maebashi (the first) and Hachioji (the second). What makes the Koshigaya location unique is that it’s the first to offer an herbal bubble bath, a new feature for Everyday Sauna. I'd love to go there with the sauna club members sometime! KJ Self-introduction I used to be really into golf. I practiced so much that I got blood blisters. I started playing in my late 30s and was half-seriously dreaming of becoming a senior professional golfer (laughs). But after the COVID-19 outbreak, I started playing less and eventually stopped practicing, so my skills declined. Then in April 2025, I was deeply moved by McIlroy completing his career Grand Slam at the Masters, and it inspired me to start over. How is your team structured? At KINTO, where I’ve been seconded, I’m part of a four-person team called the Business Project Improvement Team, which focuses on improving leasing operations. At KTC, I’m not assigned to a specific team. **What was your first impression of KTC when you joined? Were there any surprises? ** My first impression was that KTC isn’t a bureaucratic, top-down organization. Instead, it’s full of people who look at the company as a whole and think independently about what they can and should do. The surprising part, in a good way, was that it didn’t feel like a typical Toyota-style company. What’s the atmosphere like on the team? Since this division handles the leasing operations at the core of KINTO services, the atmosphere is pretty structured and organized. At the same time, the team is made up of friendly and unique individuals with all kinds of backgrounds. Our team is always looking for ways to improve quality and cut down workload and lead time. We have a healthy culture of questioning the status quo in a constructive way. **How did you feel about writing a blog post? ** I thought it was an interesting initiative. I'm grateful for the spotlight on new employees, who often go unnoticed, and I think it also provides helpful insight for people considering applying or joining the company, since it’s coming from someone they can relate to. Namiki Yuji-san -> Question for KJ-san How do you interact with members of other departments? I’m the only person in my division who was hired in Nagoya, so I’m usually based in the Nagoya office instead of the Muromachi office. There are far fewer KTC members in Nagoya compared to Muromachi, but because of the smaller number, we feel closer to each other and often have work-related conversations and casual conversations with people from other divisions. We also go out for lunch quite often. In addition, as I’ve been seconded to KINTO's Business Division, I’m gradually getting to know more people through the leasing operations. I'm hoping to make 100 friends in the next year or two (laughs). Finally Thank you to everyone for sharing your impressions after joining the company! KINTO Technologies continues to welcome new members on a regular basis! We'll be posting more stories from our newcomers across divisions, so stay tuned! And yes: we're still hiring! KINTO Technologies is looking for new teammates to join us across a variety of divisions and roles. For more details, click here !

FACTORY開発チームで執筆祭り始めます 🎉 KINTO FACTORY開発グループの水野です。 はじめましての方も、そうでない方もこんにちは。 KINTO FACTORY開発グループでグループのマネージャをしている水野です。 普段はKINTO FACTORY開発グループのグループマネージャをやっていて、その他のプロダクトマネジメントや進行管理の役割なんかもしています。 最近は菜園で野菜を育てることにハマっています。 KINTO FACTORY開発グループって？ 🏭 KINTO FACTORY開発グループは、KINTO FACTORYの ECサイト を市場へ投入・改善を目的に立ち上がったチームです。 約3年前にPoCとして開始されたTOYOTA・LEXUS・GR車両のメーカー純正品のアップグレードビジネスを、2年前に内製化・サイトリプレイスして本番化しました。 そこから商品の追加やECサイトの改善を続けて現在に至ります。 現在は以下のような体制で活動しています： メンバー数：12人（2025年8月時点） 主な役割：プロダクトマネージャ、Webディレクター、Frontendエンジニア、Backendエンジニア、QAエンジニア チームの雰囲気：フラットで自由、興味を惹かれたらやる、要望を達成する プロダクト紹介 🚀 KINTO FACTORYは、クルマの“あとから進化”を叶えるサービスなのです。 自分の愛車をアップデートできる。 しかも、オンラインで申し込めて、施工証明書もPDFで発行されるという、カスタムを体験。 名前にKINTOと付くのでKINTOの車だけが対象なのかと勘違いしやすいですが、お持ちのTOYOTA・LEXUSの車が対象なんです。 サービスカテゴリは大きく3つに分かれていて： アップグレード ：安全装備や快適機能を後付けできる。たとえば「なめらかブレーキ」や「パーキングサポートブレーキ」など。 リフォーム ：内装・外装をリフレッシュ。シートやステアリングの交換で、気分も一新。 パーソナライズ ：運転データに基づいて、もっと自分に合ったクルマに。 技術的にも面白くて、裏側はAWS上のマイクロサービス構成で動いていたり、施工証明書（施工実施商品に限る）がデジタル発行だったり どんなエンジニアが作っているのか、気になる方はぜひ下のインタビューとこれから執筆していくブログをチェックしてみてください！ Frontendエンジニアのインタビュー https://www.wantedly.com/companies/company_7864825/post_articles/537179 Backendエンジニアのインタビュー https://www.wantedly.com/companies/company_7864825/post_articles/959387 執筆祭り、始めます ✍️🔥 さて、今回の本題です。短いです。 KINTO FACTORY開発グループでは、8月から9月に掛けて 夏のテックブログ執筆祭り を始めることにしました！ KINTO FACTORYってなんなのか 技術的な知見の共有 チームの雰囲気を伝える いろいろな方との接点を増やす 目的に共感できる仲間を増やしたい などなど、まずはこのテックブログでKINTO FACTORYを作っている人たちを「知ってもらう」ことから始めます。 それぞれのメンバーの役割や日常などの視点で書いてくれます。 すでに、メンバーそれぞれがブログを投稿してくれているので、ぜひ見てみてください！！ KINTO FACTORY開発グループメンバー一同、よろしくお願いします

Introduction Hi, I'm Hinomori, an iOS engineer in the Mobile Development Group. With over 10 years of experience in iOS app development, I work as a senior engineer handling day-to-day development tasks. Today, I’d like to share how simply going about my usual work eventually led to full in-house development. The Situation at the Time With only two months left until release, development was being handled mostly by an external vendor, who reported the project was already 70–80% complete. However, the management team was new to smartphone app development and seemed uncertain about how to provide clear direction. In that situation, two iOS engineers, including myself, were brought in to join the development team. It was in this situation that two iOS engineers including myself, were brought in to join the development team. Pinpointing What Needed Improvement I still remember feeling slightly dizzy when I first opened the repository. What I found was an impressively tangled mess of spaghetti code. Jumping straight into a major refactor right after joining and trying to coordinate that with an external vendor would have come with a huge communication cost. So instead, we let the vendor continue development as planned while we focused on understanding the specifications and working on the refactor in parallel. At that point, there were three major areas for improvement in the code: ⛔ An underutilized CI environment ⛔ No consistent architecture ⛔ Singleton classes were being called from everywhere without control There were plenty of other smaller issues too, but we decided to start by tackling these three as our main improvement tasks. Large-Scale Refactor Once we had a rough plan in place, we decided to start with improvements that didn't directly touch the code. From there, we gradually worked our way deeper into the internals. ✅ An underutilized CI environment The CI environment technically existed, but it was barely being used. So we set up a proper CI workflow that could regularly handle the following two tasks: Static code analysis Running unit tests At the time, the unit test coverage rate was 0%. Since increasing it immediately wasn’t realistic, we started by simply displaying the coverage rate and focused on establishing a basic review environment. ✅ No consistent architecture While there were traces of an MVVM structure, in practice, the processing wasn’t properly separated from the View. In most cases, the ViewModel was just a placeholder and didn’t function as part of a real architectural pattern. To address this, we introduced Clean Architecture principles into the existing MVVM setup. We implemented a consistent pattern across all ViewControllers and ViewModels, where the ViewModel handled Publishers using clearly defined Inputs and Outputs. We also moved unnecessary logic out of the View and into the appropriate ViewModel or Model layer. Koyama-san wrote an article that covers the development approach we used. If you're interested, it's a great resource for understanding the structure in more depth. https://blog.kinto-technologies.com/posts/2022_12_07_Combine%E3%82%92%E4%BD%BF%E3%81%A3%E3%81%A6MVVM%E3%82%92%E5%AE%9F%E7%8F%BE%E3%81%97%E3%81%9F%E8%A9%B1/ ✅ Singleton classes being called from everywhere without control The Singleton pattern is convenient and easy to use, but it is also often misunderstood. When misused, it can quickly lead to tight coupling, increased complexity, and poor testability. Without careful handling, it can quickly become a black box. This pattern can be especially risky in a team-based development, so we began removing classes that were being used as uncontrolled singletons By completing these three tasks all at once over the course of a month, the overall visibility of the codebase improved dramatically. As a result, we were finally able to trace the actual specs incorporated in the code, and feature additions became much smoother and more manageable. Moving into Team Development Once the large-scale refactor was done, it naturally became faster for us to handle development ourselves rather than relying on the vendor. At that point, we were able to fully take over the development work. That said, all we had at that stage was a solid foundation for team development. There was still a lot left to do, such as expanding the lacking unit tests, organizing data flow, refactor the UI, and more. With a solid foundation, PR rules, branching strategy, and review flow in place, the team gradually built a consistent coding philosophy. Even as the team grew, the code stayed clean and manageable and members' review feedback became more focused. I feel we've become a self-sufficient team. 👨‍💻👩‍💻 Currently, we're taking on the challenge of SwiftUI and modern architecture as a team, learning through trial and error so we can all grow with today's development methods. Finally At KINTO Technologies, we are actively looking for teammates to take on new challenges with us. We look forward to the day we can build a team together.

はじめに こんにちは。KINTO FACTORYでバックエンドエンジニアをしている上原( @penpen_77777 )です。 普段はGoやRustを使って開発をしており、エディタはVim/NeoVimを愛用しています。 今回は、テストコードの品質向上について、特に テストメソッド名の付け方 にフォーカスしてお話しします。 今回の内容について以下の書籍を参考にさせていただきました。 https://book.mynavi.jp/ec/products/detail/id=134252 テストコードに関わる「辛さ」 皆さんは日々テストコードを書いていると思いますが、こんな経験はありませんか？ テストコードはあるが中身が理解できていないため、テストの結果が信用できない、十分にテストできている自信がない 他の人が書いたテストコードをレビューしていて、内容がよくわからないけれどなんとなくApproveしてしまった どういうテストをしているかよくわからないけどCIが落ちてしまうとPRを出せないので、テストがPASSするように雰囲気でテストコードを直した このような課題を解決するために、まずは テストメソッド名を改善してみませんか？ ということを提案したいと考えています。 なぜテストメソッド名を改善する必要があるのか？ テストコードの品質についてなぜテストメソッド名を改善する必要があるのかについて、具体例を見ながら考えていきましょう。 コード例: ECサイトシステム Go言語で記述されたECサイトシステムで、以下のような商品を購入するメソッドを実装しました。 商品の在庫があれば注文することができ、なければエラーを返して注文できません。 // ECサイトシステム構造体 type ECSystem struct { // 商品ごとの在庫数 stock map[string]int } // 商品を購入するメソッド func (c *ECSystem) Order(itemID string) error { // 商品がない場合はエラーを返す if c.stock[itemID] <= 0 { return ErrOutOfStock } // 商品があれば在庫数を減らす c.stock[itemID]-- // 正常終了 return nil } 改善前のテストメソッド名 このプロダクションコードに対して単体テストを行いたいため、 以下のようなテストコードを作成したとします。 func Test_正常系_在庫数が0より大きい場合(t *testing.T) { } func Test_異常系_在庫切れエラー(t *testing.T) { } これらの名前を見ると、以下のような疑問が浮かびます： 🤔 「在庫数が0より大きい場合、どういう結果が出てくるのが正しいのだろう？」 🤔 「在庫切れエラーとは、どういう条件で発生するのだろう？」 このパターンのテストメソッド名は意外と見かけることが多いと筆者は感じています。 どうテストしていくか、テストメソッド内の中身をどう書いていくか考えるのに気が取られて、テストメソッド名の検討に時間が取れなかった結果が現れていると感じています。 今回はサンプルコードでメソッド内の実装も薄いのでテストメソッド名からどういうテストか容易に推測できますが、 実際のプロダクトコードだとテストメソッドの実装量も数も多くなるため、どういうテストか理解できなくなってしまいます。 第一段階の改善 改善前のテストメソッド名がわかりづらいと感じる1つの要因は、名前から「事前条件」もしくは「想定結果」のどちらか一方が欠落しているためです。 func Test_正常系_在庫数が0より大きい場合(t *testing.T) { } // 「想定結果」の欠落 func Test_異常系_在庫切れエラー(t *testing.T) { } // 「事前条件」の欠落 逆に言えば、テストメソッド名に「事前条件」と「想定結果」を両方書けばわかりやすくなるということなので、 { テスト対象メソッド }_{ 事前条件 }_{ 想定する結果 } の形式に統一してみましょう。 func Test_Order_在庫数が0より大きい場合_正常終了(t *testing.T) { } func Test_Order_在庫数が0の場合_在庫切れエラー(t *testing.T) { } 少し良くなりましたが、まだ改善の余地があります。 問題点：How（どうテストするか）が含まれている 現在のテストメソッド名にはHow（どうテストするか）が書かれているため、読みにくく感じます。 🤔 「Orderが正常終了ってことは...ユーザが商品を購入できるってことか...」 🤔 「Orderが在庫切れエラーを返すってことは...ユーザが商品を購入できないってことか...」 つまり、読んだときに脳内でWhat（どういう振る舞いをテストしているか）へ言い換えることで、脳に負荷がかかり、読みづらく感じます。 この命名規則について「単体テストの考え方/使い方」でも以下のように述べられています。 私はこの十年近く様々な命名規則を試してきたのですが、その中でも、非常に有名で、おそら く、もっとも役に立たないのが次のような命名規則です : {テスト対象メソッド } {事前条件 } {想定する結果 } 厳密な命名規則に従うのではなく、それぞれのテストに応じて適切な名前を考えるべきだという主張なのですが、 個人的には「もっとも役立たない」というのは言い過ぎかなと感じています。 命名に迷ったら規則に従うくらいの温度感で運用することで、チームメンバー間の命名のレベルを揃えられるメリットを考慮すれば非常に有用だと考えています。 最終的な改善案：Whatを書く テストメソッド名には「How(どうテストするか)」ではなく「What(振る舞い)」を書きましょう。 「How」の部分（正常終了の確認、エラー発生の確認）はテストメソッド内に実装します。 func Test_商品の在庫がある場合_ユーザは商品を購入できる(t *testing.T) { // ここで正常終了しているかをみる } func Test_商品の在庫がない場合_ユーザは商品を購入できない(t *testing.T) { // ここで在庫エラーが発生しているかをみる } さらには、非エンジニア（ドメイン・エキスパート）にも伝わるように端的に書くことが重要だと「単体テストの考え方/使い方」では述べられています。 非エンジニアにも分かる名前にする理由 「テストコードは開発者だけが見るものなので、非エンジニアに分かる名前にしなくても良いのでは？」という意見もあるでしょう。 単体テストの考え方/使い方では、この意見について以下のように述べられています。 なぜなら、暗号めいた名前は開発者なのかどうかにかかわらず誰にでも認知的負荷をかけるもの だからです。このような名前はテスト・ケースが実際に何を検証するのか、そして、このテ スト・ケースの内容がどのようなビジネス要求と関係しているのかを把握するのに開発者に 対して余計な認知的負荷をかけることになります。 開発者だけがわかるコードを書いても結局は テストで何を検証し、どのような要件と対応しているか把握しにくくなる コードのメンテナンスが困難になる 書いた本人でも数ヶ月後には読めなくなる 他のエンジニアがコードレビューする際に理解しづらい となってしまい、最初に記述したテストコードに関わる「辛さ」 テストコードはあるが中身が理解できていないため、テストの結果が信用できない、十分にテストできている自信がない 他の人が書いたテストコードをレビューしていて、内容がよくわからないけれどなんとなくApproveしてしまった どういうテストをしているかよくわからないけどCIが落ちてしまうとPRを出せないので、テストがPASSするように雰囲気でテストコードを直した につながるわけです。 わかりやすいテストメソッド名をつけるのは難しい 正直に言うと、わかりやすいテストメソッド名をつけるのって、めちゃくちゃ難しいです。 なぜでしょうか？それは、一度キーボードから手を離して、モニターから目を上げて、こう自分に問いかける必要があるからです。 「我々は一体、何を作ろうとしているんだ？」 コードの海に溺れそうになりながら、ふと立ち止まって考えてみてください。目の前のメソッドは、誰のどんな悩みを解決しようとしているのでしょうか？ そのオブジェクトは、システムの中でどんな役割を担っているのか？ 今やっているタスクは、本当にユーザーを幸せにするのか？ この業務領域で使われているドメイン知識を、我々ははちゃんと知っているのか？ テストメソッド名を真剣に考えるって、実はこういうことなんです。 そして気づくんです。わかりやすいテストメソッド名を追求していくと、不思議なことが起こることに。 テストコードが読みやすくなる。プロダクションコードも自然と整理される。チームでの会話も、なんだかスムーズになっていく。 たかがテストメソッド名、されどテストメソッド名。 小さな改善が、開発チーム全体の幸せにつながっていく。そんな体験を、ぜひあなたにも味わってもらいたいのです。 まとめ 今回はテストメソッド名の話を書かせていただきました。 どのようなテストをしているか把握しやすくするためにテストメソッド名をわかりやすくしよう 非エンジニアでも理解できるくらいまで書いてみよう テストメソッドの名前を改善するだけでテストコードの品質が向上できるのであれば、コストパフォーマンスが良い改善方法だと思いませんか？ この記事でテストメソッド名の重要性を感じ取っていただければ幸いです。 今回参考にさせていただいた書籍「単体テストの考え方/使い方」は全400ページくらいありますが、テストメソッド名に割かれている説明は6ページくらいで決して長くはありません。 ですが、個人的にはこの書籍で一番重要で学びになる箇所ではと感じています。 単体テストで悩みがあれば、ぜひ「 単体テストの考え方/使い方 」を読んでみてください。 きっとあなたの悩みに対する答えを与えてくれるはずです！ 参考文献 https://book.mynavi.jp/ec/products/detail/id=134252

Introduction Hello, I’m Tada from the Security CoE Group at KINTO Technologies. I usually work in the Osaka Office. Our group is taking on various challenges related to cloud security, with the mission of "implementing guardrail monitoring and kaizen activities in real time" in a multi-cloud environment. You can find a summary of what activities our members’ daily activities on this blog . Background Following the trend of developing LLM (Large Language Model) applications in the world, our product team has been actively developing numerous LLM applications, many of which have progressed to the PoC or product-ready stage. Meanwhile, as a group responsible for monitoring cloud security, it is essential that we implement appropriate security measures for these applications as well. Our LLM applications are primarily developed on AWS, Google Cloud, and Azure, and are often built using generative AI services provided by cloud vendors. Our group monitors and operates Cloud Security Posture Management (CSPM). However, currently there are no CSPM controls specifically tailored for generative AI-related services. For example, in the case of AWS, neither the AWS Foundational Security Best Practices (FSBP) nor the Center for Internet Security (CIS) provide direct controls related to generative AI services. Therefore, our group has established guidelines to be followed when developing LLM applications using each cloud vendor’s generative AI services. The guidelines also include recommended usage practices and configuration methods for each vendor’s generative AI services. In other words, the configuration methods described in the guidelines are the controls that should be monitored as part of CSPM. Additionally, the control is implemented in Rego language and is operated as part of CSPM for AWS Bedrock. The term AI-SPM in the title stands for AI Security Posture Management. It is defined as "a solution for visualizing, managing, and mitigating security and compliance risks of AI-related assets such as AI, machine learning (ML), and generative AI models." Given this definition, I deliberately chose to name this initiative AI-SPM. Security Guidelines to be Followed for LLM Applications In creating the guidelines, we referred to the OWASP Top 10 for LLM Applications 2025 . This document is probably a go-to resource when discussing LLM application security. This OWASP document lists the top 10 most critical vulnerabilities commonly seen in LLM applications and includes sections such as "Overview," "Examples of Vulnerabilities," "Mitigation Strategies," and "Attack Scenarios." Based on this content, I reviewed the services and features used in each cloud environment and considered best practices for developing LLM applications accordingly. The first risk listed in the top 10 is "LLM01: Prompt Injection." This refers to the risk that malicious input may unintentionally manipulate the behavior of LLM, resulting in data leakage or unauthorized actions . To prevent and mitigate this risk, validation and filtering of input to LLM is an effective measure. When implementing this prevention and mitigation measure on cloud services, AWS offers a feature in Amazon Bedrock Guardrails to filter prompt attacks . So, enabling this feature serves as an effective countermeasure. After that, by checking whether this feature is enabled as a CSPM control, it becomes possible to achieve both visibility and kaizen. Below is a summary of the most common risks from the Top 10, along with corresponding "Prevention and Mitigation Strategies" and "Implementation of CSPM controls" for AWS services. Top 10 Risk Overview Prevention and Mitigation Strategies Implementation on AWS Implementation of CSPM controls LLM01: Prompt Injection Risk that malicious input (prompts) may unintentionally manipulate the behavior of LLM, leading to data leakage or unauthorized actions. Model behavior restrictions, input/output validation, filtering, authority control, and human approval, etc. Use the "Prompt attacks" content filters in Amazon Bedrock Guardrails. Ensure that the configure prompt attacks filter is enabled , the action is set to " Block ," and the threshold is set to " HIGH ." LLM02: Sensitive Information Disclosure Risk of sensitive information, such as personal information or confidential data, may be leaked through the model’s responses or behavior. Output validation and filtering, training data management, and access controls. Use the "Sensitive information filters" in Amazon Bedrock Guardrails. Verify that the Sensitive information filters are enabled for Output . LLM06: Excessive Agency Risk of unintended actions or manipulations due to granting excessive autonomy or authority to LLMs or their agents Enforcement of least authority, human approval, and authority auditing. Use the "Agent" feature in Amazon Bedrock Builder tools. When using Agents, verify that Guardrail details are properly associated with them. LLM09: Misinformation Risk that the LLM may generate outputs containing misinformation or bias, causing adverse effects on users or society. Train on diverse and reliable data, fact-check, and provide source attribution. Use the "contextual grounding check" feature in Amazon Bedrock Guardrails. Verify that contextual grounding check is enabled . LLM10: Unbounded Consumption Uncontrolled resource consumption by LLMs may lead to DoS, increased costs, and service outages, resulting from unrestricted requests or computational usage. Resource limits, quota settings, and usage monitoring Use the "Model invocation logging" feature in Amazon Bedrock. Verify that Model Invocation Logging is enabled . I presented the above content at a co-hosted event, Cloud Security Night #2 , held in May. Please feel free to refer to the materials here for more details. Implementing CSPM Controls with Rego Now that the CSPM controls have been defined, the next step is to develop a mechanism for checking the control configurations. In our group, we operate CSPM using Security Hub for AWS, Sysdig for Google Cloud, and Defender for Cloud for Azure. While using a unified tool would be ideal, we don’t heavily rely on cloud provider consoles. Instead, we monitor CSPM alerts through APIs and send notifications to Slack when necessary. As such, the lack of tool integration hasn’t posed any particular inconvenience. For the CSPM controls of the LLM application, we decided to implement them using Rego, the policy language used in Sysdig’s CSPM features. The reason we chose Rego is that it’s OSS, and for defining evaluation logic for cloud infrastructure settings, such as CSPM controls, it offers a relatively low learning curve and is easy to develop with. Below is the LLM01:Prompt Injection control implemented in Rego. What it does is set risky == true (risk present) as the default value. If the ContentPolicy.Filters setting in Bedrock Guardrails has Type == PROMPT_ATTACK and InputStrength==HIGH , it determines that the Prompt attack filter is enabled and the threshold is set to High. In this case, it sets risky == false , meaning no risk is present. default risky := true risky := false if { some filter in input.ContentPolicy.Filters lower(filter.Type) == "prompt_attack" lower(filter.InputStrength) == "high" } This Rego needs to be deployed to Sysdig as a Sysdig custom control. For detailed instructions on how to create and deploy custom controls, please see the official Sysdig blog here . We also used this as a reference during our development process. While not covered in this blog post, we accumulated a great deal of know-how on creating custom controls. Custom controls must be deployed to Sysdig as a terraform. The following is the final main.tf used to create the custom control. terraform { required_providers { sysdig = { source = "sysdiglabs/sysdig" version = ">=0.5" } } } variable "sysdig_secure_api_token" { description = "Sysdig Secure API Token" type = string } provider "sysdig" { sysdig_secure_url="https://app.us4.sysdig.com" sysdig_secure_api_token = var.sysdig_secure_api_token } resource "sysdig_secure_posture_control" "configure_prompt_attack_strength_for_amazon_bedrock_guardrails" { name = "Configure Prompt Attack Strength for Amazon Bedrock Guardrails" description = "Ensure that prompt attack strength is set to HIGH for your Amazon Bedrock guardrails. Setting prompt attack strength to HIGH in guardrails helps protect against malicious inputs designed to bypass safety measures and generate harmful content." resource_kind = "AWS_BEDROCK_GUARDRAIL" severity = "High" rego = <<-EOF package sysdig import future.keywords.if import future.keywords.in default risky := true risky := false if { some filter in input.ContentPolicy.Filters lower(filter.Type) == "prompt_attack" lower(filter.InputStrength) == "high" } EOF remediation_details = <<-EOF ## Remediation Impact This control will help you ensure that your Amazon Bedrock guardrails are configured with high prompt attack strength, which is crucial for protecting against malicious inputs designed to bypass safety measures and generate harmful content. ## Remediation Steps 1. Navigate to the [Amazon Bedrock console](https://console.aws.amazon.com/bedrock/home). 2. Select the guardrail you want to modify. 3. In the guardrail settings, locate the "Content Policy" section. 4. Ensure that the "Prompt Attack" filter is set to "High" for the "Input Strength". 5. Save the changes to the guardrail configuration. 6. Repeat this process for any other guardrails in your AWS environment. ## Remediate Using Command Line You can use the AWS CLI to update the guardrail configuration. Run the following command to set the prompt attack strength to HIGH for a specific guardrail: ```bash aws bedrock update-guardrail --guardrail-id <guardrail-id> --content-policy ’{"Filters": [{"Type": "prompt_attack", "InputStrength": "high"}]}’ ``` Replace `<guardrail-id>` with the ID of your guardrail. Repeat this command for other guardrails in your AWS environment. ## Additional Information For more information on configuring Amazon Bedrock guardrails, refer to the [Amazon Bedrock documentation](https://docs.aws.amazon.com/bedrock/latest/userguide/guardrails.html). ## Contact Information Slack Channel: #security-coe-group EOF } Initially, Sysdig did not support Amazon Bedrock as a target resource for CSPM. However, after reaching out to Sysdig, they responded with impressive speed, which made this initiative possible. Beyond the functionality, this kind of responsiveness is incredibly reassuring as a Sysdig user. Following the same approach, we implemented several of the controls listed in the Security Guidelines to be Followed for LLM Applications using Rego and deployed them to Sysdig. AI-SPM Operations by Sysdig Several of the custom controls that were deployed are defined as custom policies, enabling visibility into AWS Bedrock resources. Based on the results of this visibility, any identified issues are addressed through kaizen. In our company, our group submits kaizen requests to the product development group, always including both the issue and kaizen methods. The screen below shows the Sysdig console, where the CSPM control for LLM01：Prompt Injection is being reviewed. The control name is Configure Prompt Attack Strength for Amazon Bedrock Guardrails . The naming was done to align with its intended role. The status indicates that there are three AWS Bedrock Guardrail resources, one is marked as Failling , while the remaining two are Passing . By drilling down into the above screen, you can see the impact of kaizen and how to kaizen. This content also reflects the contents written in main.tf. However, in actual operations, we rarely access the Sysdig console directly. Instead, we typically check alerts through the Sysdig API. Conclusion In this article, I introduced an approach to securing LLM applications by developing Rego-based configuration checks for Amazon Bedrock and operating them using Sysdig. The guidelines not only include Amazon Bedrock but also Azure AI Foundry and Google Cloud Vertex AI, and we plan to continue developing Rego policies and operating them through Sysdig. In addition to traditional CSPM, AI-SPM must go beyond general cloud infrastructure security, such as AI-specific challenges and the protection of data assets, which traditional CSPM cannot fully cover. AI technology is evolving rapidly, with new concepts such as MCP and A2A emerging recently. It is also important to promote security measures that correspond to these developments. We will continue to enhance the security of AI applications while staying aligned with new technologies and challenges. Lastly The Security CoE Group is looking for people to work with us. We welcome not only those with hands-on experience in cloud security but also those who may not have experience but have a keen interest in the field. Please feel free to contact us. For more information, please check here .

Introduction Hello. I am Yamada, and I develop and operate in-house tools in the Platform Engineering Team of KINTO Technologies' (KTC) Platform Group. As an application engineer, I primarily develop a CMDB (Configuration Management Database), working on both the backend using Java and Spring Boot, and the frontend with JavaScript and React. Over the past year or so, I’ve also been riding the wave of generative AI, working on a chatbot for our CMDB that uses technologies like RAG and Text-to-SQL. This is my previous article about Text-to-SQL. If you’re interested, feel free to check it out! https://blog.kinto-technologies.com/posts/2025-01-16-generativeAI_and_Text-to-SQL/ This time, I’d like to share my experience exploring Spring AI, a topic related to generative AI. Spring AI reached General Availability (GA) on May 20, 2025, and I had the opportunity to try it out firsthand. Overview of Spring AI Spring AI is a generative AI framework that reached GA on May 20, 2025, as part of the Spring ecosystem. In the generative AI space, Python-based frameworks like LlamaIndex and LangChain are widely known. But if you’re looking to add generative AI capabilities to an existing Spring application, or want to experiment with generative AI in Java, Spring AI could be a great option. https://spring.pleiades.io/spring-ai/reference/ What I Tried This time, using Spring AI, I implemented the following two functions: Chat Function (LLM interaction) A conversational function powered by AWS Bedrock using the Claude 3.7 Sonnet model. Embedding Function A document embedding and similarity search function using Cohere's embedding model in combination with Chroma, a vector database. Technology Stack Spring Boot 3.5.0 Java 21 Spring AI 1.0.0 Gradle Chroma 1.0.0 AWS Bedrock LLM Model: Anthropic Claude 3.7 Sonnet Embedding model: Cohere Embed Multilingual v3 Environment Setup Setting Up Dependencies First, add the necessary dependencies for using Spring AI in your build.gradle file. plugins { id 'java' id 'org.springframework.boot' version '3.5.0' id 'io.spring.dependency-management' version '1.1.7' } java { toolchain { languageVersion = JavaLanguageVersion.of(21) } } ext { set('springAiVersion', "1.0.0") } dependencies { implementation 'org.springframework.boot:spring-boot-starter-web' implementation 'org.springframework.boot:spring-boot-starter-validation' implementation 'org.springframework.ai:spring-ai-starter-model-bedrock-converse' implementation 'org.springframework.ai:spring-ai-starter-model-bedrock' implementation 'org.springframework.ai:spring-ai-bedrock' implementation 'org.springframework.ai:spring-ai-starter-vector-store-chroma' testImplementation 'org.springframework.boot:spring-boot-starter-test' } dependencyManagement { imports { mavenBom "org.springframework.ai:spring-ai-bom:${springAiVersion}" } } Application Configuration In application.yml , configure your AWS Bedrock credentials, model selection, and vector store connection settings. spring: application: name: spring-ai-sample ai: bedrock: aws: region: ap-northeast-1 access-key: ${AWS_ACCESS_KEY_ID} secret-key: ${AWS_SECRET_ACCESS_KEY} session-token: ${AWS_SESSION_TOKEN} converse: chat: options: model: arn:aws:bedrock:ap-northeast-1:{account_id}:inference-profile/apac.anthropic.claude-3-7-sonnet-20250219-v1:0 cohere: embedding: model: cohere.embed-multilingual-v3 model: embedding: bedrock-cohere vectorstore: chroma: client: host: http://localhost port: 8000 initialize-schema: true That's all for the configuration. From here, you can easily inject the necessary classes into your application using dependency injection (DI). Implementation Example 1. Conversational Function with a Generative AI (LLM) With Spring AI, you can easily implement conversations with an LLM using the ChatClient interface. Service Layer Implementation Implement the conversational function with an LLM in a class called ChatService. @Service public class ChatService { private final ChatClient chatClient; public ChatService(ChatClient.Builder builder) { this.chatClient = builder.build(); } public String generate(String message) { return this.chatClient.prompt(message).call().content(); } } By injecting the ChatClient.Builder , you can automatically build a client based on the configuration file. Controller Implementation Create a REST controller to provide the API endpoint. @RestController public class ChatController { private final ChatService chatService; private final EmbeddingService embeddingService; public ChatController(ChatService chatService, EmbeddingService embeddingService) { this.chatService = chatService; this.embeddingService = embeddingService; } @PostMapping("/generate") public ResponseEntity<String> generate(@RequestBody ChatRequest request) { return ResponseEntity.ok(chatService.generate(request.getMessage())); } } Once this is set up, when you send a POST request to the /generate endpoint, you’ll receive a response generated by Claude 3.7 Sonnet. Here’s an example: curl -X POST http://localhost:8080/generate -H "Content-Type: application/json" -d '{"message": "こんにちわわ"}' こんにちは！ 何かお手伝いできることはありますか？ 2. Implementing the Embedding Search Function Next, implement a function that vectorizes documents and enables semantic search. Embedding Service Implementation In this service, vectorize a sample text as a Document object and store it in Chroma. Then, use "Spring" as the query to search for similar documents. Behind the scenes, the Cohere Embed Multilingual v3 model converts the text into vectors. @Service public class EmbeddingService { private final VectorStore vectorStore; public EmbeddingService(VectorStore vectorStore) { this.vectorStore = vectorStore; } public List<Document> embed() { List<Document> documents = List.of( new Document("Spring AI is a framework for building AI applications with the familiar Spring ecosystem and programming model."), new Document("LlamaIndex is a data framework for LLM applications to ingest, structure, and access private or domain-specific data."), new Document("LangChain is a framework for developing applications powered by language models through composability.") ); vectorStore.add(documents); return vectorStore.similaritySearch(SearchRequest.builder().query("Spring").topK(5).build()); } } Implementing the API Endpoint @GetMapping("/embedding") public ResponseEntity<List<Document>> embedding() { return ResponseEntity.ok(embeddingService.embed()); } This implementation defines the /embedding endpoint, which vectorizes a sample document, performs a similarity search, and returns the results. Here’s an example: As expected, the document containing the word "Spring" has the highest similarity score. curl http://localhost:8080/embedding [ { "id": "af885f07-20c9-4db4-913b-95406f1cb0cb", "text": "Spring AI is a framework for building AI applications with the familiar Spring ecosystem and programming model.", "media": null, "metadata": { "distance": 0.5593532 }, "score": 0.44064682722091675 }, { "id": "5a8b8071-b8d6-491e-b542-611d33e16159", "text": "LlamaIndex is a data framework for LLM applications to ingest, structure, and access private or domain-specific data.", "media": null, "metadata": { "distance": 0.6968217 }, "score": 0.3031783103942871 }, { "id": "336b3e07-1a70-4546-920d-c4869e77e4bb", "text": "LangChain is a framework for developing applications powered by language models through composability.", "media": null, "metadata": { "distance": 0.71094555 }, "score": 0.2890544533729553 } ] Conclusion This was a brief introduction to implementing generative AI functions using Spring AI. After trying it out, Spring AI seems like a good option when integrating generative AI capabilities into Java-based systems. Also, I feel that combining the chat and embedding functions introduced here makes it relatively easy to build RAG functionality. At this point, Python-based frameworks like LlamaIndex and LangChain still provide more advanced features and a richer ecosystem for generative AI. However, since Spring AI has only recently been released, there's a lot of potential for growth, and I’m excited to see how it develops.

はじめに こんにちは、 KINTO FACTORY （以下 FACTORY）のフロントエンド開発を担当しているきーゆのです。 今回は、FACTORYのリアルイベントにFEエンジニアが参加してきた件についてまとめてみようと思います。 ここでいうリアルイベントは技術系のカンファレンスとかではなく、 車好きのオーナーが広い敷地に集う、車好きのためのミーティングにてFACTORYプロモーションブースをFEエンジニアがお手伝いしてきた というお話です。 ITやネットにあまり馴染みのない方々も参加するイベントなので、我々エンジニアとは異なった視点のフィードバックを得られる、とても貴重な機会でした。 イベントの展示内容 我々のプロダクトは「愛車にメーカー純正オプションをWEB上からの申し込みで後付けできるアップグレードサービス」を提供しています。 基本はWEBや マガジン記事 などで商品について知っていただき購入していただく流れのため、購入前に実車両を見る機会はほとんどありません。 そのため、このようなイベントではWebでは見ることのできない施工済みの車両も展示します。 今回は「メーターデザインカスタマイズ」を施工済みのカローラクロスを展示しました。 「メーターデザインカスタマイズ」は、車のメーターパネルに新しいデザインを追加できる商品です。 ※画像はクラシックギア 実際に施工されたメーターパネルを見ると、想像以上にワクワクしてきますね！ 免許を持っていない方が思わず教習所に入校手続きをしてしまう くらい、魅力に溢れています。 FACTORYの紹介とノベルティ イベントでは来場されたオーナーの皆様にFACTORY上で車両情報を登録していただくまでを案内します。 最後までご対応いただいた方にはハズレなしのガチャガチャに挑戦していただき、ノベルティをお渡しします。 ペンライト、タンブラー、オリジナル車検証ケースなど、ノベルティは非常に豪華！ 今回用意したオリジナル車検証ケースは、弊社のクリエイターがデザインした至極の一品です！ ペーパードライバーが思わずカローラシリーズを契約してしまう くらい、魅力に溢れています。 実際の操作から見えてきたこと ここからエンジニアの本領発揮です。 実際にオーナーの皆様にFACTORYを触っていただくと、以下の課題が見えてきました。 案内用のQRコードから会員登録を進めると、途中でFACTORYへの導線が切れてしまう 会員登録時に「利用規約はこちら」のリンクをタップすると、利用規約ページから会員登録に戻る導線がない メールに届く認証URLをタップ後に誤ってページを閉じると、再度会員登録の導線に戻れない 我々エンジニアが特に意識せずに進めていたフローでも、離脱に繋がる要素が散りばめられていることが見えてきました。 特に会員登録導線は、動作確認をする際の前提条件でアカウントを事務的に用意することが多いため、 障壁を感じることなく会員登録することに慣れきってしまっていた のです。 見えてきた課題に対するアクション イベントから帰ってきてすぐに、課題に対してアクションを実施しました。 まず、案内用のQRコードのURLは我々エンジニアが期待していたものと異なるURLが利用されていたことが判明しました。 そのため、正常に動作するURLを共有することでこの課題を解決しました。 利用規約ページから会員登録に戻る導線がない件と認証URLタップ後にページを閉じた際に戻る導線がない件は、担当チームに状況と修正案を連携しました。 まとめ 実際にイベントに参加してサービスに触れていただくと、我々が気づかない場所でもユーザーは困っているということがよくわかりました。 特にエンジニアはプロダクトを触る機会が非常に多く、サービスフローの正解パターンを最初からわかっています。このように正解パターンを知った状態に慣れてしまうと、今回のように灯台下暗しのような事態が起こります。 いくらユーザーのことを想定して開発していても、この状態のままでは自然とユーザーとの距離は開いてしまいます。 もし皆様が担当しているプロダクトでユーザーとコミュニケーションを取る機会があるのであれば、参加してみませんか？ 今一度原点に立ち返って「誰のために開発しているのか」、「何のために開発しているのか」を振り返る意味でも、機会があるのならば参加するべきだと思います。 もしそのような機会がなくても、社内の無関係メンバーに依頼してユーザーテストをしてみたり、端末を変えてみたりすることでも普段とは異なる気づきを得られるかと思います。 百聞は一見にしかず、です。これぞユーザーファーストではないでしょうか。 以上、読んでいただきありがとうございました。 おまけ 帰りの新幹線で隣になった初対面の方と、ハイボール片手にお菓子交換をしました。 これも出張の醍醐味？かもしれません(笑)

Introduction Hi, my name is Jongseok and I'm an Android app developer at KINTO Technologies. One day, I was sorting through documents and transferring content into Google Sheets when it suddenly struck me. "This is way too tedious." Typing the same kind of content over and over again, adjusting the cell formatting... it's not difficult, but I wondered if this is really something a human being should be doing. That thought stuck with me. That's when I started looking into whether I could automate this process using the AI tools I've been seeing lately. And what I came across was MCP (Model Context Protocol) . After trying out a few different tools, I found that I could actually control Google Sheets with just a single line of natural language. Honestly, it was kind of mind-blowing. What is MCP? MCP stands for Model Context Protocol. The name may sound a bit technical, but the concept is actually very intuitive. Simply put, MCP is like an "interpretation coordinators" that allows AI to freely operate real-world tools and services. In this article, I'll focus on examples of integration with Google services. To put it more simply, services we use every day, such as Gmail, Google Drive, and Google Sheets, are operated by people clicking on them. MCP enables AI to handle those tasks for you. For example, let's say you want to record something in Google Sheets. Normally, you would: Open the sheet Click on a cell Enter your data With MCP, the AI can handle all of that automatically. Next, let's take a look at an actual demo: https://www.kinto-technologies.com/products/ Using the following web page as a reference, create a new Google Spreadsheet and organize the products and services listed. The video below shows what happens when MCP processes a request like above.  With just one command like this, the AI calls the Google Sheets API and automatically fills in the data into the sheet. Organizing data became incredibly easy. Is MCP Trending Right Now? Being technically possible doesn't always mean people are actually interested in it. So, I checked Google Trends to see how much attention the term MCP is getting. Looking at the data from March to May 2025, there's a clear spike in search volume especially from mid-April. This suggests that interest in MCP has moved beyond curiosity. Not only developers but also general users are actually starting to use MCP. I guess I jumped on that wave, too. So, if you want to try out MCP, what are the options? To make use of MCP, you need an environment where natural language commands can be received and executed. There are several AI agents that can work with MCP, such as Claude (Anthropic), but the one I chose this time was Cursor, a code editor with built-in AI features. What is Cursor? Put simply, Cursor is a code editor with built-in AI features. If you write a code request in natural language, the AI will automatically offer suggestions, edits, and explanations. It also makes writing MCP commands a lot smoother. If you're curious and want to learn more about Cursor, I recommend checking out their official website and blog. https://www.cursor.sh Now, Let's Get Started Together To automate tasks with MCP and Google Sheets, there are a few things you need to set up first. But don't worry, no complicated knowledge is required. We'll go step by step. Preparation Before getting started with automation, make sure you've got the following: Install an editor that supports MCP (we'll be using Cursor this time) A Google account Google services you want to automate (Drive, Sheets, etc.) MCP Server( https://github.com/xing5/mcp-google-sheets ) ←This is what we will use in this article. A simple natural language command you want to try Google Cloud Platform (GCP) Setup First, we'll configure GCP to use the Google Sheets API. 1-1. Create a project Go to the GCP Console and create a new project.   1-2-1. Create a service account To let the AI access Google Sheets, create a Service Account.  Click + Create service account under Service accounts.  Enter the Service account name and click Done. 1-2-2. Add permissions  Go to Permissions -> Manage access -> Role, and set it to Editor, then click Save. 1-2-3. Add Keys  Go to Keys -> click Add key, select JSON and click Create. Then the authentication file will be downloaded.  The contents of the file will look something like this. That's it. You've successfully created your service account. We will use this file client_email later. 1-3. Set up Google services  Click Library under APIS & Services.  You can see the services we want to use this time. Drive Sheets Click Enable for the two services. 2-1. Set up Google Drive  Go into Google Drive and create a folder to use AI. Examples) Created "Sheets For MCP" -> Then click "Share."  In the top field, copy and paste the client_email from the JSON file made in 1-2. Create a service account.  Check that it has been added and click Done. 2-2. Get the Folder ID  Once the settings are complete, obtain the Folder ID . Everything you need for the setup is now ready to go. Let's move on to the actual setup and use it! MCP Setup (Cursor & Terminal) This can also be done on Windows, but the instructions here are for Mac. There's a way to use a simple cloud server for MCP setup, but this time we'll use LocalServer. First, we need uv and uvx. Open your terminal and get these installed. uvx appears to be part of uv , a fast Python package installer and resolver. 1. Install uv and uvx & Set Environment Variables curl -LsSf https://astral.sh/uv/install.sh | sh  Installation completed successfully. Enter values according to your environment. export SERVICE_ACCOUNT_PATH="/path/to/your/service-account-key.json" export DRIVE_FOLDER_ID="YOUR_DRIVE_FOLDER_ID" Set the two prepared SERVICE_ACCOUNT_PATH and DRIVER_FOLDER_ID as environment variables. 2. Project Setup git clone https://github.com/yourusername/mcp-google-sheets.git cd mcp-google-sheets Clone the project and move to the cloned directory. You can place it anywhere you like, but for easier management, I moved the service_account.json file under Project.  Let's start up the server. uv run mcp-google-sheets  The local server is now ready. Finally, let's configure the MCP for use. 3. MCP Setup  To set up MCP, click the ⚙️ icon in the top right corner.  In the MCP section, click + Add new global MCP Server.  You'll see a input screen. { "mcpServers": { "mcp-google-sheets-local": { "command": "uv", "args": [ "run", "--directory", "/Users/jongseok.bae/MCP/GoogleServices/mcp-google-sheets", "mcp-google-sheets" ], "env": { "SERVICE_ACCOUNT_PATH": "/Users/jongseok.bae/MCP/GoogleServices/mcp-google-sheets/service_account.json", "DRIVE_FOLDER_ID": "1n4HUOiglwjiTKHcw8jSATYcPtCRqNn6O" } } } } In args , enter the path to your project directory. In env , enter SERVICE_ACCOUNT_PATH and DRIVE_FOLDER_ID. Input the above values and save.  A 🟢 light means you're all set. You should now see a list of available MCP tools like list_spreadsheets, create_spreadsheet, get_sheet_data, etc. Your setup is now complete. Good job! Now, let's try giving natural language commands and see how it automatically updates Google Sheets. Try It Out Now that we're ready, it's time to put it into action. For example, simply give a natural language command like: https://news.google.com/home?hl=en-US&gl=US&ceid=US:en Create a new Google Spreadsheet named Today's Google News. Organize the top news articles listed into three columns: title, summary, and URL. In fact, here's what's happening behind the scenes: You enter a command in Cursor The MCP Server receives the command It analyses the natural language and converts it to Google Sheets API A spreadsheet is automatically created, and the data is inserted  This is what it looks like behind the scenes when MCP runs. (Analyzes the natural language and executes the process)  As a result, the spreadsheet described earlier was automatically generated! Summary The integration between MCP and Google Sheets isn't just a technical introduction. The experience of running tasks through a single natural language command is no longer futuristic, it's fully achievable right now . Of course, there are still things to consider, such as security and access control. However, by starting with small automations gave me a strong sense of just how much more efficient work can become. If you’re thinking about automating your tasks, feel free to use this case study as a reference and give it a try. You might be surprised how quickly you can start making changes.

Introduction Hi, I'm Alex from the AI First Group. As AI technology rapidly advances, demand for agent development is growing fast. However, getting started with efficient agent development can be challenging. Information about the latest tools is fragmented, and development resources are limited. To tackle this, we've launched Agent Store v1.0, a platform to share internally developed AI agents and centralize our technical know-how. Purpose of Agent Store The Agent Store has two primary purposes: Boost in-house agent development efficiency Shorten development cycle by reusing existing agents Enables rapid builds using templates Build technical know-how Centralize management of in-house Agent-related technologies Facilitate yokoten (horizontal deployment) of best practices Usage Patterns and Target Users Agent Store is a platform where employees can freely develop, share, download, and reuse AI agents. For reusability, we envision it like an app store—users can download agents and deploy them in their own environments. The Agent Store is made up of the following components: Github repository for sharing internally developed agents How CI/CD works for agent development Github repository for Agent Store Usage Format Agent Store v1.0 primarily supports AWS Bedrock agents. We designed the agent’s CI/CD process with an Infrastructure as Code (IaC) approach in mind. Agents shared through the Agent Store are stored as SAM templates in its GitHub repository, making them ready for deployment via CloudFormation. Users looking to reuse an agent can download its SAM template and deploy it to their environment using CloudFormation. Deployment is automated using Github Actions. Those who want to build new agents can also jumpstart development using the blank SAM templates available in the Agent Store. Target Users (v1.0) Engineers looking to start building agents using AWS Bedrock Engineers wanting to share Bedrock-built agents within their organization Engineers looking to discover and utilize existing agents ** Expected Use Cases** Agent Store is designed for the following scenarios: Creating new AI agents Speed up development using Agent Store's CI/CD flow Sharing AI agents Share custom-built agents across your company Reusing shared AI agents Equip existing products with AI agents App development to streamline internal operations Avoid building from scratch and boost development efficiency ** AI agent PoC** Deploy existing agents to quickly conduct PoC Shortening the time required for effect verification ** Acquire know-how for developing AI agents** Learn best practices by looking at similar cases Lowering technical barriers Agent Development, Sharing, and Reuse Flow Using Agent Store ** Flow for developing a new agent** The flow begins by retrieving a blank SAM template from the Agent Store repository, filling it out, and deploying it. For more information about SAM, see here . If you're using an agent's Action Group, make sure to fill out and deploy the templates in this order: ①Lambda, ②Agent. ** Flow for sharing agents ** Prepare a SAM template for the agent you developed and submit a pull request to the Agent Store repo. The agent reviewer will check the content and merge it if there are no problems. Flow for reusing a shared agent The overall process is similar to developing a new agent, but it begins by retrieving the SAM template of a shared agent from the Agent Store. After making any needed changes or additions, you can move on to deployment. Agent Architecture Here's the architecture of the agent. After deployment, the Bedrock agent can invoke and execute Lambda functions configured as Action Groups when needed. Stack management is handled through CloudFormation. You can also build multi-agent collaboration,where multiple agents work together. Future Development Plans To boost adoption of the Agent Store, we're planning a variety of internal study sessions, workshops, and hackathons. Currently, v1.0 is designed for engineers with AWS Bedrock experience (Type A), but we plan to expand our target users in stages. | User type | Description | Support status || ---- | ---- | ---- || Engineer type A | Engineers experienced with AWS Bedrock | Supported in v1.0 || Engineer type B | Engineers interested in agent platforms other than AWS Bedrock | In planning || Non-engineers / Beginners | Employees with no coding or development experience | In planning | Summary Agent Store v1.0 is a platform designed to streamline agent development and foster knowledge sharing. Currently, it's available to AWS Bedrock users, but we plan to expand support to a broader user base and integrate with a wider range of agent frameworks. To make the most of our in-house AI development resources and accelerate innovation, we're committed to actively expanding and evolving Agent Store.

はじめに こんにちは。ご覧いただきありがとうございます！ KINTO FACTORY （以下 FACTORY）という今お乗りのクルマをアップグレードできるサービスで、フロントエンド開発をしている Nakamoto です。 今回は、FACTORY 開発Gで取り入れた 改善DAY や、社内での フロントエンド勉強会 を活用して、ページパフォーマンス（CWV）を改善した事例を紹介させていただきます。 改善DAYとフロントエンド勉強会 改善DAY FACTORY 開発Gでは、案件開発している最中で気付いた、技術的負債などの「すぐには対応できない（しなくてもよい）タスク」を、忘れないようにとりあえずチケット化しバックログに残しておく運用になっていました。その運用がずっと続いたところ、日々の案件開発になかなか切れ目が無く、それら改善タスクがバックログに積み上がる一方で消化されることがなく、チケット総数が100件を軽く超えるようになっていました。 そこで、スクラムの振り返りなどで、それらの改善タスクをずっと放置しておくのも問題だという声もあがり、週に１日午後の時間を改善タスクの消化のみにあて、そこにはMTGなどを入れない取り組みをチーム全体で始めてみました（Outlook 上で該当時間をブロックし、他部署からの MTG も入れられないように工夫しています）。 今回は、この 改善DAY を活用し、ずっとできていなかったページパフォーマンス = CWV（Core Web Vitals）のスコア向上を目指すことにしました。 フロントエンド勉強会 また、社内の有志によるフロントエンド勉強会を週に１度開催しており、過去のイベント発表をみんなで見て感想を共有したり、過去〜最新の Baseline をみんなで確認したりと、参加メンバーで都度議題を決め、フロントエンド界隈の技術交流や、実際の開発プロダクトや開発の実情について共有する場というものがあります。 そんな中、勉強会のアウトプットの一つとして、実際のサービスで活かせることがなにかできないか考えるようになり、私の方から題材の一つとして「FACTORYパフォーマンス改善」を提案しました。 実際に参加メンバーみんなで FACTORY ページを検証する枠を作って頂き、合計２回に渡ってライブ検証することができました。 具体的に取り組んだのは以下になります。 ブラウザの Lighthouse を使用して現状のスコアを確認（ネットワークや CPU のスロットリングを適宜設定） 各スコアの改善提案を確認する 分析タグなどページレンダリングに関係のないものをブロックしパフォーマンスの差分を確認 パフォーマンスタブでより詳細なブラウザの動きを確認する キャプチャ画像からレイアウトシフトを確認 これらにより、ブラウザに用意されている検証ツールの使い方や、どのようなところに改善ポイントがあるのか、を明確にすることができました。 :::message フロントエンド勉強会について詳しくは、 こちらの記事 もご覧頂ければと思います！ ::: スコア改善 ここからは、実際に勉強会で得た知見を活用し、どのようにスコア改善を進めたか紹介していきます。 ページパフォーマンスを図る指標として、Core Web Vitals (CWV) がありますが、それらは下記３つの指標に分類されます。 Largest Contentful Paint (LCP): ページの主要なコンテンツがどれだけ速く読み込まれるかを測定 Interaction To Next Paint (INP): ユーザーの操作に対するページの応答性を評価 Cumulative Layout Shift (CLS): ページの視覚的な安定性を測定 FACTORY はサービスの性質上、商品や車種画像の制約が厳しく（商品・車種の色味などが厳格のため）、静的コンテンツ変更（画像圧縮など）は難しかったため、ページ内のコンテンツ配置の変更だけで改善が見込める CLS にまずは焦点を当てました。 Google Search Console を参考に、どのページで CLS スコアが悪いのか確認 SSG により静的ページとして作成し、クライアントでの API アクセス時のロード画面をなくす 画像などのコンテンツロード前後で、高さがシフトしている場所などを探す 実際には、CLS スコアの悪いページにて、ブラウザの「パフォーマンス」タブで確認し、画面キャプチャを見ながらレイアウトシフトしている箇所をひとつひとつ潰していきました。 中でも特定に時間を要したのが、TOPページで発生していた CLS です。 以下のように解析ツールで見てみても、どこがレイアウトシフトしているのかパッと見では特定できませんでした。 ただ、該当の画像あたりを確認すると、 contain-intrinsic-size をcssで定義していることに気づきました。どうやら、こちらのプロパティは比較的新しいもので、非対応のブラウザでは正しく画像のサイズが設定されずレイアウトシフトの原因になっているようでした。 代わりに、画像のサイズ固定を aspect-ratio へ変更しアスペクト比を設定することで、レイアウトシフトを無くすことできました。 結果 今回は、改善DAYでの取り組みと実際の CWV スコアはどうだったのか、両面から振り返ってみたいと思います。 改善DAYでのチケット消化 以下の図は、改善チケットをまとめたボードのチケット解決数を表したものです。 ４月ごろに「改善 DAY」の仕組みを導入しており、グラフ中の赤線が期間中（１ヶ月）に追加したチケット、緑線が完了したチケットを示しております。 4月チケット消化 6月チケット消化 上記はチーム全体の結果になりますが、着実に改善タスクの消費量が増えていることがわかるかと思います。 また、最近は全社的に AI を利用した開発も積極的に取り入れていることもあり、このような改善タスクは「シンプルなタスクな反面、取り掛かるにはコンテキストスイッチなどが発生し人間がやるには腰が重い」作業となり、比較的 AI に任せやすいタスクとも言えます。 そのような面も有り、日々機能追加などの案件の開発も動いている割には、上記のような改善活動にもしっかりコミットできていることが読み取れます。 CWVスコア それでは、改善活動前後での今回のテーマである、CWV スコアがどのように改善されてきたか振り返ります。 PCスコア モバイルスコア 上記のグラフは、Google Search Console で確認できる、URL単位でのパフォーマンススコアの移り変わりになります。 PC / モバイル両方とも 良好URLの数 (緑部分) が増え 不良URL (赤部分) が減少 or ０ となり、大多数のページでパフォーマンス改善することができました。 黄色で表されている 改善が必要なURL が多少残っていますが、こちらは今回対応した CLS スコアだけの結果では無さそうですので、今後はそちらの別指標についても改善していきたいと思います。 まとめ 今回は、FACTORY 開発G で導入している 改善DAY と、社内で開催している フロントエンド勉強会 を活用し、実際に FACTORY のページスコア（CWV）の向上に取り組んだ事例を紹介させて頂きました。 日々、案件を進めるうえでは、納期などの都合でどうしても技術的な負債の消化を後回しにしてしまいがちですが、今後も改善DAYを活用し、そうした技術的負債が溜まらないようにしていくことや、社内勉強会からは、開発しているプロダクト・サービスは違えど、知見や改善案はそんな中からも発見できるので、それらをうまく活用しながら FACTORY のサービスを日々改善し安定運用していきたいと思います！

Introduction Hello! I'm Tanachu from the Security and Privacy Group. In this article, I'll cover a recent security incident at our company involving a generative AI chat tool. Although the technical issue is not particularly new, I would like to introduce it because the circumstances under which it occurred were somewhat unusual. Overview of the Case Our company has created an environment where all employees can easily use the AI ​​chat tool. One day, while using the tool, an employee asked the AI a question. When they clicked on one of the links provided in the response, it led to a support scam website. Image of a generative AI chat Image of a support scam website Even though we had security products in place, they couldn't block the messages, and the user was ultimately led to a support scam website. Fortunately, thanks to the employee's calm and quick judgment, we were able to avoid any serious damage. This experience was a clear reminder that, just like with regular web searches, the links provided by generative AI can't always be trusted. Cause of the Incident To find out why the generative AI ended up suggesting a scam support website, we looked up the website it pointed to using the internet archive service WAYBACK MACHINE . We found that the website had actually provided what seemed to be legitimate content in the past. We also discovered several other websites that listed this website as a reference. This suggests that the generative AI may have learned from the past content of the website in question, along with information about the websites it had introduced. As a result, a hallucination-like phenomenon may have occurred, which led the AI to present incorrect information and possibly suggest a link to a scam support website. Here's a summary of how the content on the problematic websites has changed, based on the investigation results. 2012 to early 2018 There was content history matching the domain name during this period. It is assumed that the site was considered reliable at this time. Late 2018 to early 2019 A domain management service sales page was shown, suggesting that the owner might have let go of the domain. Since late 2019 The domain has shown a history of unrelated content, such as medical issues, online casinos, fake warning screens, and domain parking. For information on why security products were unable to detect the virus, check out " Appendix: Research Notes ." Measures for Similar Cases At this point, it seems extremely difficult to take fundamental steps against cases like this, for the following reasons. Challenges in Learning Generative AI One possible reason behind this incident is that the generative AI may have learned from older content on the website in question, as well as from other websites it featured. Even if the content of a website is later updated, it's unlikely that those changes will be reflected in the AI's responses, including any related security risks. The Best Prevention is Awareness What we can take away from this case is that links suggested by generative AI aren't always safe. That's why it's so important to learn from real examples and understand how to respond if you actually encounter one. Summary This case was a somewhat unusual one, showing that links presented by generative AI are not necessarily safe. Depending on the characteristics of the fraudulent site, it may be difficult for security products to detect it. Also, if the site content is changed after the generative AI has learned, it may not be able to reflect the risk. There may not be a solid solution at this point, but learning from cases like this can be a good reminder to stay alert about security when using generative AI. Appendix: Research Notes These are notes on investigating into why the issue wasn't picked up by security products. Please keep in mind this was a simple research, so it's just for reference. 1. Security Vendor Detection Status We looked up the domain of the problematic website using our security tools and VirusTotal . Almost all the vendors flagged it as "safe." 2. Website Source Code After checking the source code of the website in question, it seems there's a mechanism in place that sends a request to "domaincntrol[.]com" (note the missing o after the c) and then uses the response to dynamically decide where to direct the visitor. We tried accessing the site a few times in a safe environment, and found that it redirected us to various other websites, including support scam pages and domain parking websites. This may have allowed the malware to slip past detection by security vendors. 3. Hosting Environment of Support Scam Website The final support scam website is hosted on the "web.core.windows[.]net" domain, presumably utilizing the Microsoft Azure environment. Not just limited to Microsoft Azure, scam websites hosted on cloud services are generally hard to block with security products. That's because blocking cloud service domains outright isn't realistic, given how easy it is to set them up and how much it could impact legitimate business operations. *As of this article's publication, we've confirmed that this support scam website has been taken down from Microsoft Azure. 4. Survey Results Using PublicWWW Using a tool called PublicWWW , which lets you search website source code, we searched the distinctive string "domaincntrol[.]com/?orighost=" found on the problematic websites. The search revealed that this string appears in the code of over 20,000 websites. We also checked a few of those websites in more detail and found that they showed the same behavior — redirecting users to scammy support websites.

0. Introduction My name is Choi Garamoi , and I am responsible for developing the Android app " KINTO Kantan Moushikomi ." This app uses KMP and shares some business logic with iOS app . This time, I've summarized the results of using Tuist to enable smoother development of a KMP project. 1. Overview In Android Studio, the KMP Application project is created using the New Project Wizard. Once it is created, the Monorepo will look like this: KmpProject/ ├── androidApp/ # Android専用モジュール(Kotlin/Android) ├── iosApp/ # iOS専用モジュール(Swift) └── shared/ # 共通ビジネスロジック(Kotlin/Multiplatform) Similar to Gradle for Android, a build environment suitable for modularization and team development is also important in iOS. This article will show you how to build one using Tuist . 2. Challenges in Xcode Project Xcode manages the information required to build an app in *.xcodeproj , but there are some challenges. Merge conflicts occur frequently : When settings are changed, Xcode automatically updates the project.pbxproj file. This file is in an unstructured text format, which often leads to Git conflicts when multiple people edit it simultaneously. Practically meaningless diffs are generated : Xcode's GUI operations can generate many diffs without any real changes, cluttering the history. Difficult to automate : Many settings are GUI dependent, making it difficult to automate builds using CI/CD or scripts. Difficult to review : project.pbxproj is hard to read, making it difficult to review changes. Scalability is limited : As the team size grows, managing multiple targets and build settings can become cumbersome. The *.xcodeproj directory is like a combination of Gradle and .idea directories in an Android project, so it is not possible to separate local Xcode settings from iOS app build settings. Google Trends also shows that there are more searches for "xcode conflict" than for "xcode dev," indicating that there are more conflicts during development. 3. What is Tuist ? It is a tool that can generate Xcode projects and workspaces in the Swift language and can also build in combination with Xcode terminal tools. Main features are as follows: Modularization support Environment-independent builds (team development oriented) Automation support Swift Package Manager support Other Xcode build tools include Swift Package Manager , XcodeGen , and Bazel . Swift Package Manager : It only provides the dependency management functionality of Gradle (the dependencies block). XcodeGen : Insufficient checking of tool settings makes it prone to human error. Bazel : It is complex to use because it is intended for large-scale projects and is overengineered for small and medium-sized projects. 4. Introducing Tuist The following steps are based on Migrate an Xcode project and reflect the latest information: 4-1. Install Tuist brew update brew upgrade tuist brew install tuist For installation methods other than Homebrew , refer to the Manual . 4-2. Add Tuist Config files Add three files (Manifest files): Tuist.swift , Project.swift , and Tuist/Package.swift . KmpWithSwift/ ├── Tuist.swift ├── Tuist/ │ └── Package.swift ├── Project.swift ├── androidApp/ │ └── ... ├── iosApp/ │ └── ... └── shared/ └── ... 4-3. Add a Module ( Target ) to the Settings Project.swift is the main config file, and you can use the sample from Migrate an Xcode project as is for the other files. 4-3-1. Tuist.swift import ProjectDescription let tuist = Tuist(project: .tuist()) 4-3-2. Project.swift Add target settings and build scripts for KMP common modules. infoPlist : Whole screen setup. scripts : Command to build the KMP common module. import ProjectDescription let project = Project( name: "KmpWithSwift", targets: [ .target( name: "App", destinations: .iOS, product: .app, bundleId: "ktc.garamoi.choi.kmp.with.tuist.App", infoPlist: .extendingDefault( with: [ "UILaunchScreen": [ "UIColorName": "", "UIImageName": "", ], ] ), sources: ["iosApp/iosApp/**"], resources: ["iosApp/iosApp/**"], scripts: [ .pre( script: """ cd "$SRCROOT" ./gradlew :shared:embedAndSignAppleFrameworkForXcode """, name: "Build KMP" ) ] ) ] ) 4-3-3. Tuist/Package.swift // swift-tools-version: 6.0 import PackageDescription #if TUIST import struct ProjectDescription.PackageSettings let packageSettings = PackageSettings( productTypes: [:] ) #endif let package = Package( name: "App", dependencies: [ ] ) 4-4. Delete the Old Xcode Project Delete ./iosApp/iosApp.xcodeproj . Add *.xcodeproj to ./.gitignore . 4-5. Check Check whether Tuist has been set up correctly. Verify that the Tuist Manifest file can be opened in Xcode. # KmpWithSwiftディレクトリで tuist edit Generate an Xcode project with Tuist. # KmpWithSwiftディレクトリで tuist generate Once Xcode is open, run the app. If the app starts normally, the process is complete. 5. Separate iOS Settings from Common Features The common module ./shared/build.gradle.kts does not properly separate the scope of responsibility for the common business logic build settings and the iOS-specific XCFramework build. kotlin { // ... listOf( iosX64(), iosArm64(), iosSimulatorArm64() ).forEach { it.binaries.framework { baseName = "shared" isStatic = true } } // ... } 5-1. Response If you separate the iOS XCFramework settings below from :shared and move them to ios , you can set them more effortlessly and enhance modularity. it.binaries.framework { baseName = "shared" isStatic = true } 5-2. Procedure Build XCFramework from the ./iosApp/shared module. Update the scripts in the App target ( ./iosApp/iosApp directory). 5-2-1. Add the :iosApp:shared Module Add the ./iosApp/shared/build.gradle.kts file and add the module to ./settings.gradle.kts . No Android settings are required. // ./iosApp/shared/build.gradle.kts plugins { alias(libs.plugins.kotlin.multiplatform) } kotlin { listOf( iosX64(), iosArm64(), iosSimulatorArm64() ).forEach { it.binaries.framework { baseName = "shared" isStatic = true export(projects.shared) } } sourceSets { commonMain.dependencies { api(projects.shared) } } } // ./settings.gradle.kts // ... 省略 ... rootProject.name = "KmpProject" include( ":androidApp", ":iosApp:shared", ":shared" ) Delete the XCFramework configuration from ./shared/build.gradle.kts . // ./shared/build.gradle.kts plugins { alias(libs.plugins.kotlinMultiplatform) alias(libs.plugins.androidLibrary) } kotlin { // ... 省略 ... iosX64() iosArm64() iosSimulatorArm64() // ... 省略 ... } // ... 省略 ... 5-2-2. Tuist Target Update Update the Gradle command in scripts of Project.swift . Change the module in scripts from :shared to the added :iosApp:shared ( ./gradlew :shared:embedAndSignAppleFrameworkForXcode ➡️ ./gradlew :iosApp:shared:embedAndSignAppleFrameworkForXcode ). // ./Project.swift import ProjectDescription let project = Project( name: "KmpWithSwift", targets: [ .target( name: "App", destinations: .iOS, product: .app, bundleId: "ktc.garamoi.choi.kmp.with.tuist.App", infoPlist: .extendingDefault( with: [ "UILaunchScreen": [ "UIColorName": "", "UIImageName": "", ], ] ), sources: ["iosApp/iosApp/**"], resources: ["iosApp/iosApp/**"], scripts: [ .pre( script: """ cd "$SRCROOT" ./gradlew :iosApp:shared:embedAndSignAppleFrameworkForXcode """, name: "Build KMP" ) ] ) ] ) 6. Multimodularization As your app scales, modularizing features becomes essential. %%{ init: { 'theme': 'neutral' } }%% graph TB App ==> FeatureA App ==> FeatureB FeatureA --> :iosApp:shared FeatureB --> :iosApp:shared But if each feature requires :iosApp:shared , the Tuist config becomes as follows: // ./Project.swift import ProjectDescription let project = Project( name: "KmpWithSwift", targets: [ .target( name: "App", destinations: .iOS, product: .app, bundleId: "ktc.garamoi.choi.kmp.with.tuist.App", infoPlist: .extendingDefault( with: [ "UILaunchScreen": [ "UIColorName": "", "UIImageName": "", ], ] ), sources: ["iosApp/iosApp/**"], resources: ["iosApp/iosApp/**"], dependencies: [ .target("FeatureA"), .target("FeatureB") ] ), .target( name: "FeatureA", destinations: .iOS, product: .framework, bundleId: "ktc.garamoi.choi.kmp.with.tuist.FeatureA", infoPlist: .default, sources: ["iosApp/FeatureA/**"], resources: ["iosApp/FeatureA/**"], scripts: [ .pre( script: """ cd "$SRCROOT" ./gradlew :iosApp:shared:embedAndSignAppleFrameworkForXcode """, name: "Build KMP" ) ] ), .target( name: "FeatureB", destinations: .iOS, product: .framework, bundleId: "ktc.garamoi.choi.kmp.with.tuist.FeatureB", infoPlist: .default, sources: ["iosApp/FeatureB/**"], resources: ["iosApp/FeatureB/**"], scripts: [ .pre( script: """ cd "$SRCROOT" ./gradlew :iosApp:shared:embedAndSignAppleFrameworkForXcode """, name: "Build KMP" ) ] ) ] ) This configuration has the following two major issues: A common XCFramework will be built for the number of feature modules ( :IOSApp:shared ). Depending on your feature module target settings and build options, there is a risk that the app may use multiple versions of :iosApp:shared . To solve this problem, wrap :iosApp:shared with a Tuist target. 6-1. Add Wrapping Target Add the KmpCore target so that feature modules share Xcode targets instead of directly using the Gradle :shared module. %%{ init: { 'theme': 'neutral' } }%% graph TB App ==> FeatureA App ==> FeatureB FeatureA ==> KmpCore FeatureB ==> KmpCore KmpCore --> :iosApp:shared The source code is in iosApp/shared/** , which is the same as :iosApp:shared , but uses KmpCore as a wrapping target to utilize the namespace generated by KMP and to encapsulate it. As a result, the only target that holds information about the KMP common code is KmpCore . // ./Project.swift import ProjectDescription let project = Project( name: "KmpWithSwift", targets: [ .target( name: "App", destinations: .iOS, product: .app, bundleId: "ktc.garamoi.choi.kmp.with.tuist.App", infoPlist: .extendingDefault( with: [ "UILaunchScreen": [ "UIColorName": "", "UIImageName": "", ], ] ), sources: ["iosApp/iosApp/**"], resources: ["iosApp/iosApp/**"], dependencies: [ .target("FeatureA"), .target("FeatureB") ] ), .target( name: "FeatureA", destinations: .iOS, product: .framework, bundleId: "ktc.garamoi.choi.kmp.with.tuist.FeatureA", infoPlist: .default, sources: ["iosApp/FeatureA/**"], resources: ["iosApp/FeatureA/**"], dependencies: [.target(name: "KmpCore")] ), .target( name: "FeatureB", destinations: .iOS, product: .framework, bundleId: "ktc.garamoi.choi.kmp.with.tuist.FeatureB", infoPlist: .default, sources: ["iosApp/FeatureB/**"], resources: ["iosApp/FeatureB/**"], dependencies: [.target(name: "KmpCore")] ), .target( name: "KmpCore", destinations: .iOS, product: .framework, bundleId: "ktc.garamoi.choi.kmp.with.tuist.KmpCore", infoPlist: .default, sources: ["iosApp/shared/**"], resources: ["iosApp/shared/**"], scripts: [ .pre( script: """ cd "$SRCROOT" ./gradlew :iosApp:shared:embedAndSignAppleFrameworkForXcode """, name: "Build KMP" ) ] ) ] ) 6-2. Expose shared via KmpCore Simply the KmpCore target dependency on shared does not allow access from FeatureA and FeatureB to :shared code. Additional configuration is required to allow FeatureA and FeatureB to access the KMP common code (Gradle's :shared module) via KmpCore . First, add the settings configuration to the KmpCore target. // ./Project.swift import ProjectDescription let project = Project( name: "KmpWithSwift", targets: [ // ... 省略 ... .target( name: "KmpCore", destinations: .iOS, product: .framework, bundleId: "ktc.garamoi.choi.kmp.with.tuist.KmpCore", infoPlist: .default, sources: ["iosApp/shared/**"], resources: ["iosApp/shared/**"], scripts: [ .pre( script: """ cd "$SRCROOT" ./gradlew :iosApp:shared:embedAndSignAppleFrameworkForXcode """, name: "Build KMP" ) ], settings: .settings(base: [ "FRAMEWORK_SEARCH_PATHS": "iosApp/shared/build/xcode-frameworks/**", "OTHER_LDFLAGS": "-framework shared" ]) ) ] ) Add the following Swift file so that the KmpCore target exposes the shared namespace in the KmpCore namespace. // ./iosApp/shared/KmpCore.swift @_exported import shared 6-3. Check After building the project in Xcode, FeatureA and FeatureB can access :shared via import KmpCore . For example, if the :shared module has a SomeModel ( shared/src/commonMain/kotlin/ktc/garamoi/choi/kmp/with/tuist/SomeModel.kt ) class, it can be accessed from FeatureA as follows. import Foundation import KmpCore public class SomeFeatureAClass { let model: SomeModel // ... } If a compilation error occurs, the initial build may become unstable due to build order or caching issues. In that case, you can resolve the issue by performing a clean build or building multiple times. 7. Conclusion Xcode's *.xcodeproj is not suitable for automation and team development. I recommend using Tuist as an alternative to *.xcodeproj for Xcode projects. By wrapping the KMP common module's XCFramework generation in an Xcode project target, feature modularization becomes easier. 8. References Kotlin Multiplatform : The official Kotlin project that provides various tools for cross-platform development using the Kotlin language. Gradle : A de-facto build tool for Android and Java projects. Tuist : Build tools for Xcode projects. Swift : An OOP language developed by Apple to replace Objective-C. Xcode : An IDE for Apple platforms. Xcode / Projects and workspaces Swift Package Manager : The official dependency management tool for the Swift language. XcodeGen : A tool to generate Xcode Project in YAML and JSON. Bazel : A build tool developed by Google. Targets large-scale Monorepo . Monorepo Explained : A system for managing multiple software in a single repository. Google Trends : xcode conflict , xcode merge , xcode dev : The proportion of Xcode conflict searches is higher when compared to general Xcode development searches. What is project.pbxproj in Xcode Project configuration / Projects / Project settings : Explanation of the .idea directory in Android Studio and IntelliJ IDEA. Migrate an Xcode project : Manual steps to turn an existing Xcode project into a Tuist project. Homebrew : A system package management tool for macOS. Install Tuist Xcode / Bundles and frameworks / Creating a static framework Swift logo : The official logos can be downloaded below. Kotlin logo Gradle logo Tuist logo KINTO Kantan Moushikomi : Android App KINTO Kantan Moushikomi : iOS App Choi Garamoi