この記事は KINTOテクノロジーズ Advent Calendar 2025 の 1 日目の記事です🎅🎄 こんにちは、技術広報の ゆかち(@ukcpo) です！ KINTOテクノロジーズは今年もアドベントカレンダーを実施します☆* アドベントカレンダー、今年で 5 回目！ 今年はフリーテーマで 2 シリーズ、計 50 記事公開予定です！ @ card 過去アドベントカレンダーは技術広報から各部署へ個別で声がけをして集めておりましたが、 今回はSlackチャンネルでの公募でほとんどの数が集まりました＼(^^)／ ちなみに合計 50 記事中半分のメンバーが執筆デビューとなります！ せっかくなので・・とチャレンジしてくれるメンバーが多くて素敵！！！ 余談ですが、去年のアドベントカレンダーからアドベントの執筆時期は技術広報メンバーが毎日 30 分、 Slackのハドルにてゆるっと相談会を開いております。 ちょっと困った時にハドルに入ればサクッと聞けちゃうの、 相談のハードルが下がると思うので開催している側として良い取り組みな気がしていますがいかがでしょう！？ " 初の執筆なので初歩的な質問なのですがいいですか・・？ " などちょこちょこ相談いただけて嬉しいです！  相談しやすい雰囲気をつくるのが得意なマネ そんなこんなで弊社の "リアル" をアドベントカレンダーを通して楽しんでいただけたら嬉しいです！ 更新内容は 公式X(@KINTOTech_Dev) にて毎日更新予定です。 気になる記事があればぜひ目を通してみてください♩ 今年もあと1ヶ月、頑張りましょう〜＼(^^)／

この記事は KINTOテクノロジーズ Advent Calendar 2025 の1日目の記事です🎅🎄 はじめに QAグループのMobileチームのokapiです。 AIで画像を作成するとき、「こういう画像が欲しい！」とプロンプトで伝えたはずなのに、なぜか意図が伝わらず、何度もやり直す羽目に…。そんな経験、ありませんか? そこで今回は、テックブログのカバー画像を「一度の生成」で作れるプロンプトを作成しました! この考え方は、他の画像作成にも応用可能です。ぜひ活用してみてください。 使い方 使用する画像生成AI Microsoft Copilot ※画像生成に対応した生成AIツールであれば、基本的にどれでもOKです（例：ChatGPT、DALL-E、Midjourneyなど） プロンプトの修正箇所 プロンプトの修正箇所は、たったの4点だけ! 修正箇所 内容 1. 表示タイトルの設定 執筆したテックブログのタイトルを「表示タイトル」に貼り付ける 2. スタイルの選択 「■スタイル」から1つ選び、残り2つを削除 3. 概要の設定 執筆したテックブログの内容を「■テックブログの記載内容」に貼り付ける 4. 以前のカバー画像添付 以前使っていたカバー画像を「プロンプト」に添付 実際に使ったプロンプト テックブログのカバー画像を作成してください。 添付している前回のテックブログで使用した画像と同じ形式でお願いします。 ■目的 以下のブログ記事のカバー画像を作成したいです。 ■表示タイトル （ここに記事のタイトルを貼り付け） ■注意点 ・日本語表現に不自然な点が入らないようにしてください。 ・画像のテイストやレイアウトは前回と同様でお願いします。 ・タイトルが中央または目立つ位置に配置されていること ■スタイル （下記3つからお好きなのを選ぶ） ・テック感（技術的な雰囲気） ・AIと機械学習系（生成AIとの協働） ・モーショングラフィック風（静止画でも） ■テックブログの記載内容 （ここに記事の概要を貼り付け） 添付した以前のカバー画像 本記事で実際に作った画像 本記事では、上記3パターンのスタイルで作りました。 スタイル 生成された画像 テック感（技術的な雰囲気） AIと機械学習系（生成AIとの協働） モーショングラフィック風（静止画でも） プロンプト設計のポイント解説 ポイント 解説 1. 修正箇所を最小限に設定 プロンプト内で修正が必要な箇所を「4点に絞り込む」ことで、誰でも簡単にコピペで使いやすいテンプレートとしました。 2. 参考画像の添付 言葉だけで「前回と同じ雰囲気で」と伝えても、AIには正確に伝わりません。実際の画像を添付することで、レイアウト・配色・フォント感などの「伝えるのが難しい曖昧な部分」を共有できます。 3. 構造化された指示 目的・タイトル・注意点・スタイル・内容と、情報を明確に分類することで、AIが各要素の優先度を理解しやすくなります。 4. 避けたい要素の明記 「日本語表現に不自然な点が入らないように」という否定形の指示を入れることで、自然な日本語を選定しやすくなります。 5. 選択肢を提示(スタイル) AIに完全に任せるのではなく、3つのスタイルから選ぶ形式にすることで、ここを増やすだけで、カスタマイズが可能なプロンプトとなります。 おわらない（まだ完璧ではない） 今回のテンプレートは「タイトル・スタイル・概要・参考画像」の4点を差し替えるだけで、再現性を保ったまま量産できます。 実は課題が2つあります 一発で画像生成できたものの、よく見ると以下の2つの問題が発生していました。 課題1: 日本語の誤字 「日本語表現に不自然な点が入らないように」とプロンプトに記載しているにも関わらず、誤字が発生していました。 テック感(技術的な雰囲気): 「自動化 化 」となっている(「化」が重複) 「開発」が表示崩れ AIと機械学習系(生成AIとの協働): 「機械学」となっている(「習」が抜けている) 課題2: ロゴの改変 参考画像のロゴを再現してほしかったのですが、生成AIによってロゴが微妙に改変されてしまいました。 一見すると同じように見えますが、よく見ると 細部のデザインが変わっている ことがわかります。 著作権やブランドガイドラインの観点から、 ロゴの改変は避けたい ところです。 改善を試みました 課題1への対応: 日本語の誤字 プロンプトの注意点(日本語表現に不自然な点が入らないように)をカスタマイズして複数パターンを試してみました。 試行 変更内容 結果 ① ・日本語の文字は、正しい漢字・語句を使用してください。 ・誤字脱字や意味不明な日本語が含まれないようにしてください。 ・画像内の日本語テキストは、自然で読みやすい表現にしてください。 変わらず - 同様の誤字が発生 ② ・日本語表現に不自然な点が入らないようにしてください。 ・作成する前に漢字は正しい漢字となっているかレビューしてから作成してください。 漢字自体が全部消される - テキストが表示されなくなる ③ 画像を添付の上、「左上の『自動化化』→『自動化』に修正してください」 修正されず - 元の誤字がそのまま残る 課題2への対応: ロゴの改変 ロゴを正確に再現するため、以下のプロンプト調整を試しました。 追加プロンプト：ロゴを添付の上、下のロゴは全く同じとしたいので、添付している（rogo.png）を貼り付けて使ってください。 を追加した結果、本物に近いロゴができますが、微妙に角度や太さが異なりました。 おわりに 画像作成自体は一発でできるものの、以下の2つの課題がありました: 日本語の漢字表現 - プロンプトだけでは完璧な制御が難しい ロゴの正確な再現 - AIが自動的に改変してしまう このようなトライ&エラーを繰り返すことで、生成AIの特性や限界を理解でき、より効果的な活用方法を見つけられると感じています。 現実的な運用方法: 画像生成AIに「レイアウト・雰囲気・背景」の生成を任せる(画像生成AIの得意分野) 「ロゴ」は画像編集ツールで後から追加(人間が正確に制御) この組み合わせで、 画像生成AIの強みを活かしつつ、一定の品質も担保できる と分かりました。 本テックブログカバー画像は、上記運用で手動でロゴを貼り付けて作りました。 もし「AIで生成した画像内の漢字やロゴを正確に再現できるプロンプト」をお持ちの方がいらっしゃいましたら、ぜひ教えてください! 今後も「おもしろいAIの活用方法」や「つまずいた課題と解決策」を見つけたら、記事を執筆していきます。

This article is the Day 1 entry for the KINTO Technologies Advent Calendar 2025 🎅🎄 Hello, I'm Yukachi (@ukcpo) from the Developer Relations Group! KINTO Technologies is doing an Advent Calendar again this year☆* This is the fifth year for our Advent Calendar! This year, we have two series on free topics with a total of 50 articles planned! @ card In the past, the Developer Relations Group would individually reach out to each division to gather contributions for the Advent Calendar, but this time, most of the participants were recruited through a Slack channel call for submissions＼(^^)／ By the way, half of the 50 total articles will be written by first-time contributors! It's wonderful to see so many members taking on the challenge, thinking "why not give it a try"! As a side note, since last year's Advent Calendar, the Developer Relations Group has been hosting a casual 30-minute consultation session every day via Slack huddle during the writing period. Being able to pop into the huddle and quickly ask questions when you're a bit stuck lowers the barrier to seeking help, so from our perspective as the hosts, it feels like a great initiative. What do you think!? We're happy to receive questions like "This is my first time writing, so is it okay to ask a basic question...?"  Our manager who's great at creating an approachable atmosphere With all that said, we hope you will enjoy our company's "real" through the Advent Calendar! Updates will be posted daily on our official X account (@KINTOTech_Dev) . If any articles catch your interest, please give them a read♩ One more month left this year—let's do our best＼(^^)／

This article is the 12th entry in the KINTO Technologies Advent Calendar 2025 . Introduction I'm Uehara ( @penpen_77777 ), a backend engineer in the FACTORY E-commerce Development Group at KINTO Technologies. I participated in Techbook Fest 19 as part of the KINTO Technologies Writing Club, a circle (a small creator group) formed by volunteer engineers at KINTO Technologies. In this article, I'll share our journey of creating a technical book with company volunteers. Here's the introduction to the new book we created! It's free. If you're interested, please download the digital version. https://blog.kinto-technologies.com/posts/2025-10-31-techbookfest19-announcement/ https://techbookfest.org/product/qCPrJpWLmKnLt7eWVd9zJ6 The Beginning I had written technical books before and had been wanting to write one again after a long break. While tech blogs and presentations are sufficient for getting your writing read by others, there's something deeply satisfying about seeing your writing become a physical book. Since our company had never organized a circle of employee volunteers to write technical books, I decided to take on this challenge. Building the Team Finding Supportive People I started working on this in June, about six months before participating in Techbook Fest. Finding supportive people early on is extremely helpful when moving tasks forward. Our company has a Developer Relations Group that can provide consultation for employees' external technical communications. I truly believe we were able to accomplish this thanks to the Developer Relations Group. I'm very grateful. Finding People Interested in Writing Since participating in Techbook Fest was a first-time endeavor, I was worried about whether we could actually gather participants. Announcing a call for participants company-wide out of the blue felt like a high hurdle. So I decided to reach out to people who seemed interested and gather those who were highly likely to participate in advance. At our company, many people use times (personal update channels) on Slack, which is great for casually expressing your thoughts. By hinting at my desire to exhibit at Techbook Fest, I was able to know who might be interested. About five people gathered at this point, so I felt reassured that even if a company-wide announcement didn't attract more participants, we could still make the project work. Making the Announcement I created a simple slide to recruit writers company-wide. It summarized information about Techbook Fest and the benefits of writing, designed to encourage participation. The official sponsorship materials were helpful for introducing the scale of the event. https://techbookfest.org/assets/tbf18/for-sponsors.pdf Selecting a Printing Company Since we were creating a physical book, we needed to select a printing company. Techbook Fest has designated backup printing companies, and by submitting your manuscript to one of them, they handle everything from printing to delivering it to the venue. It’s a very convenient system. The backup printing companies are Nikko Kikaku and Neko no Shippo, and we chose Nikko Kikaku for this project. Selecting and Configuring the Typesetting System A typesetting system converts manuscripts into a print-ready format. Re:VIEW is commonly used as a typesetting system for technical books. By processing text files written in the proprietary Re:VIEW format through Re:VIEW, they are converted into formats commonly used for e-books such as EPUB and PDF. The benefit is that the separation of page style settings from content allows writers to focus on the essential task of writing without worrying about appearance. For this project, we used Vivliostyle^[It reads "kumihan," but I always mistakenly read it as "soban." https://ja.wikipedia.org/wiki/%E7%B5%84%E7%89%88] as our typesetting system. https://vivliostyle.org/ja/ Vivliostyle's distinguishing feature is the ability to change appearance using CSS, so anyone familiar with frontend technologies should be able to use it without difficulty. Since setting everything up from scratch would be challenging, we utilized a template distributed by YUMEMI. We're very grateful for the distribution of such a template. Thank you! https://github.com/yumemi-inc/daigirin-template Based on the above template, we made the following modifications: Updated the title, publisher, and colophon for our technical book Changed the paper size to B5^[This is when I learned that B5 comes in both JIS B5 and ISO B5. Be careful, as they have different dimensions despite both being called B5.] Enabled automatic table of contents output and adjusted the template for sections that weren't outputting correctly Registering Your Circle for Techbook Fest While there's a lot to prepare, don't forget to submit your circle participation application. It might be a good idea to add it to your calendar. Having Writers to Write I created and shared guidelines so writers wouldn't struggle with the writing process. Overall schedule and what to do in each phase Writing methods (Vivliostyle Flavored Markdown^[A notation that extends common markdown to express book-specific structures. https://vivliostyle.github.io/vfm/#/] syntax, PDF preview methods, etc.) Manuscript Management We managed manuscripts on GitHub, with each writer branching off from the main branch to write. Having each writer create a PR is convenient for tracking progress. Using Slack Lists To prevent topic overlap within the book, I asked writers to add their topics to a Slack list once decided. It's also helpful to include other information you want to track, such as self-introductions for the appendix and writing status. While we could have managed this with tables in Confluence, I personally check Slack more frequently, so I managed it using Slack lists, which can be used similarly to Notion databases. Getting the Book Cover Created When I was wondering whether to create the book cover myself, one of the participants suggested asking designers from the Creative Office for help. Since we wanted to create it in a fun, collaborative way, we decided to hold a Generative AI × Live Visual Creation event where designers would create the cover using generative AI. The event held to create this technical book: Vibe Painting Hour #01 Five designers joined the event and, while participants watched, used generative AI to create covers within a one-hour time limit. Despite my vague request to create a cover with a sense of mobility and futuristic feel, all five final cover proposals were of such high quality that choosing only one seemed like a waste! Through participant voting and my judgment, the cover for this technical book was selected.  The cover of our new book, TECH BOOK By KINTO Technologies Vol.01. Setting Manuscript Deadlines This is important. The submission deadline is absolute, so you should set it with plenty of buffer time. Also, it's best to assume that manuscripts won't be ready on the first try. You should set not just one deadline but two or three backup deadlines, with minimum requirements for each deadline. Having Writers Review Each Other's Work We had writers review each other's work. The review items followed our external communication review guidelines, while also keeping in mind that the final product would be a physical book. Since you can't even start reviewing without all manuscripts being submitted, I recommend setting the second deadline early. Proofreading After compiling all manuscripts, we adjusted the overall page layout. After noticing the font size was too small, I made it slightly larger. The table of contents had grown to 10 pages, so I narrowed down the items to include. We also had to adjust the page count to be a multiple of four, or the submission wouldn't be accepted. This caused display issues in some chapters, so we asked writers to make corrections. Since we were working under time pressure, we decided to set the third deadline early. Submission Once the PDF file for submission was ready, we submitted it to the printing company. With Nikko Kikaku, we paid in advance and then sent the cover and body data via a form. If there were any data issues, they would point them out and we'd need to resubmit. This time there were no issues and submission went smoothly. Booth Setup Simulation With help from a Developer Relations team member who was experienced with booth setup, we carried out a simulation the day before. By visualizing the booth in advance and identifying what we needed, I think we avoided the situation where we'd look at the actual booth on the day and feel like "hmm, this isn't quite what I imagined..." The Day of the Offline Event When I first saw the finished book at the offline venue, I thought it was thicker than expected. Since we distributed this thick book for free, we heard surprised reactions from attendees. We printed about 300 copies and distributed them all, so I think it was a great result for our first participation! https://x.com/KintoTech_Dev/status/1989983294059168095 Depositing at the National Diet Library The day after Techbook Fest, we deposited the book at the National Diet Library. Apparently, publications issued for distribution within Japan are generally subject to legal deposit, and even technical doujinshi like ours can be deposited. https://www.ndl.go.jp/jp/collect/deposit/deposit.html Publications issued for distribution within Japan are, in principle, all subject to legal deposit (see "Overview of the Legal Deposit System"). When you deposit publications with the National Diet Library, their bibliographic data becomes searchable as the "National Bibliography" through the NDL Search. Additionally, they are widely used as library materials, preserved as cultural assets shared by the nation, and passed down to future generations as records of the Japanese people's intellectual activities. I also referenced the following article for the deposit process. https://qiita.com/mitsuharu_e/items/850ae6688a94ea3d67f3 : Off to Deposit Being a central government location, various train lines converge here, including the Ginza, Marunouchi, and Hanzomon lines. Exit 2 is the closest to the National Diet Library, so depending on your line, you may need to walk a bit. Area directory near the station. Exit 2 is the closest. I took the Ginza Line, so I had to walk quite a bit. National Diet Library sign. There's a notice that those depositing materials should go to the service entrance (west gate). Enter through the National Diet Library's service entrance (west gate) and tell the security guard at the building entrance that you want to deposit books, and they'll handle the procedure. National Diet Library service entrance (west gate) At the deposit counter, hand over the book and fill out the paperwork. Once the procedure is complete, they'll give you a receipt. Material receipt After depositing, the book appears in National Diet Library Search results and becomes available to read as a resource at the National Diet Library. https://ndlsearch.ndl.go.jp/books/R100000002-I034410569 Reflections After Completion Don't Try to Do Everything Alone; Reach Out for Help Even creating just one book involves many decisions and tasks, and handling everything alone is quite difficult. It's better to delegate tasks that others can do, or that others can do better than you. The Technical Book Expanded Our Connections As well as interacting with attendees at the Techbook Fest offline venue, I believe the connections among company volunteers deepened through creating the technical book. Set Multiple Early Deadlines Even though I thought I had set deadlines with plenty of buffer, I still ended up feeling short on time. Next time, I plan to build in an even larger margin. Setting multiple deadlines is important. Summary While there were many challenges on the road to participating in Techbook Fest 19, looking back, we gained a lot and it was truly enjoyable. If this article has piqued your interest, please try taking on the challenge of creating a technical book. We'll keep working hard so that we can show up even stronger at future Techbook Fests! https://techbookfest.org/product/qCPrJpWLmKnLt7eWVd9zJ6

AI画像編集ツール徹底比較！どれが一番自然？ Google・OpenAI・ByteDanceの最新モデルを検証【2025秋】 はじめに 2025年10月24日（金）、弊社の大阪テックラボにてCO-LAB Tech Night vol.4に発表者として参加してきました。「gpt-image-1 Gemini 2.5 Flash Image Seedream4.0の一貫性を検証」と題しまして、その時に発表した内容の一部をこちらでも共有させていただきたいと思います。 内容としてはOpenAI、Google、ByteDanceが提供する画像生成・編集機能を使って同じお題で画像編集を行い、どの様な出力結果になるのかを検証するといったものになります。一部以前にこちらのテックブログでも披露した内容と重なりますが、新たにSeedream4.0も加えて改めて出力結果を検証しております。 どのツールがいいのかなと悩んでいる方はぜひ参考にしていただければと思います。 改めて、gpt-image-1とは？ こちらはOpenAIが2025年3月に発表し、GPT-4oに標準搭載された画像生成・編集が可能な機能です。APIなどでは「gpt-image-1」というモデル名で参照されることもあります。 input_fidelity というパラメータが提供されており、「high」に設定することで編集時の被写体やキャラクターの一貫性を格段に上がると話題になりました。参照機能なし、インペイント機能あり。 Gemini 2.5 Flash Imageとは？ 通称Nano Bananaと呼ばれ被写体やキャラクターの一貫性を維持する能力に特化してチューニングされていると言われています。発表当初はその性能の高さにSNSで非常に話題になりました。提供開始は2025年8月。参照機能あり、インペイント機能なし。 Seedream4.0とは？ 特徴としては4K出力という巨大な画像が出力可能で、スピードも速いことからプロの商用ワークフローにも耐えうると言われています。こちらも被写体やキャラクターの一貫性の高さがSNSなどで話題に上りました。2025年9月に提供開始されました。参照機能あり、インペイント機能あり。 AIの弱点：被写体やキャラクターの一貫性の維持 画像の一部分だけを編集したい場合においても、画像全体が生成し直されてしまうことから一貫性を保つことが難しく、生成を繰り返しているうちに元の画像から徐々に見た目が変化してしまうことが起こりますが、そうした「弱点」は現在克服されつつあります。 というわけで、これら3つのツールの出力画像を比較検証してみたいと思います。 ちなみに、Gemini2.5 Flash Image、Seedream4.0に関しては参照機能（別の画像を参考に元の画像を変更する機能）を使用しておりますが、gpt-image-1は参照機能がないので、元の画像に被写体を重ねるといった方法で編集を行なっております。ですので、プロンプトはなるべく同じ内容にしつつもgpt-image-1は若干違う内容で行いました。 また、平均10枚前後を出力してその中で最も良好な結果を示した出力を掲載しています。 お題01:空白のラベルに文字を記載する 空白のラベルに商品名を記載するというお題です。  出力結果の比較 gpt-image-1  文字の太さにばらつきがありますが、破綻は見られませんでした。全体的に一貫性が保たれています。 Gemini2.5 Flash Image  文字の太さ、大きさも問題なく、特に破綻は見られませんでした。全体的に一貫性が保たれています。 Seedream4.0  文字の太さ、大きさも問題なく、特に破綻は見られませんでした。全体的に一貫性が保たれています。ちなみにこちらのみセリフ体ですね。 お題02:透明な花瓶追加 右下の空間に透明な花瓶を追加してもらうというお題です。  出力結果の比較 gpt-image-1  花瓶の配置、角度、光の透過具合など特に違和感なく出力されています。菜の花と花瓶についても一貫性が保たれています。 Gemini2.5 Flash Image  こちらも花瓶の配置、角度、光の透過具合など特に違和感なく出力されています。菜の花と花瓶についてはこちらも一貫性が保たれています。 Seedream4.0  花瓶の配置はちょっと遠くになってしまい花瓶の一部が切れてしまっていますが、角度、光の透過具合など特に違和感なく出力されています。菜の花と花瓶についてはこちらも一貫性が保たれています。 お題03:家族を車の後部座席に座らせる 家族写真に映っている人々を車の後部座席に座っている様に編集するというお題です。 出力結果の比較 gpt-image-1  顔の一貫性は維持されていないようです。そして全体的にやや黄色味がかってしまっています。ただ人物とシートの大きさのバランスはいいと思います。 Gemini2.5 Flash Image  こちら、12枚生成しましたが破綻なく出力されることはありませんでした。またシートに対して人物が小さいです。ただし顔の一貫性についてはかなり維持されています。 Seedream4.0  こちらはシートに対して人物がやや小さい気がします。しかし顔の一貫性はまあまあ保たれている気がします。 お題04:男女をソファに座らせる 別々の画像の男女を仲良くソファに座っている様に編集するというお題です。 出力結果の比較 gpt-image-1  構図が被写体により過ぎています。そして今回も顔の一貫性は保たれていないようです。 Gemini2.5 Flash Image  一見よさそうなのですが、ソファに対して人物が小さいようです。 Seedream4.0  こちらは構図、ソファと人物の大きさのバランス、顔の一貫性、いずれも問題ないようです。 お題05:スーツ姿の男性をバイクに跨らせる スーツ姿の男性をバイクに跨らせるというお題です。 出力結果の比較 gpt-image-1  またもや構図が被写体により過ぎています。そして顔のAI感が強いです。バイクのディテールに対する一貫性は一部維持されていない様です。 Gemini2.5 Flash Image  全体的なバランスが良いです。また人物の顔、スーツの柄、バイクのディテールに対して一貫性が維持されています。 Seedream4.0  夕焼けが強く出てしまっています。そして人物がバイクに対してやや大きいですね。 お題06:雑誌のタイトルを日本語へ変更する 雑誌のタイトルを日本語へ変更するというお題です。  出力結果の比較 gpt-image-1  タイトルに関しては漢字もひらがな（やや太い？）も問題ないかなといったところでしょうか。タイトル以外の細かい部分は完全に破綻しています。そして全体的な色味が黄色っぽくなっている感じがします。 Gemini2.5 Flash Image  こちらはタイトル、細かい見出しは全く日本語になっておりませんが、それ以外の一貫性は完全に維持されているようです。 Seedream4.0  こちらは日本語は成立していますが、ひらがなが太字になってしまっています。細かい文字も他と同じく日本語の体（てい）をなしていません。また、腕時計もなくなってしまっていますし、袖も短くなってしまっております。 お題07:真上からのアングルに変更 真横から撮影された花瓶に入ったひまわりを真上からのアングルに変更するというお題です。  出力結果の比較 gpt-image-1  アングルは真上からになっていますが、花が不自然に整列されてしまっています。 Gemini2.5 Flash Image  アングルはやや斜め上からですが、花の配置や高さなど元の画像からの一貫性が非常に高く感じます。 Seedream4.0  こちらも同じくアングルはやや斜め上からですが、花の配置など一貫性が高く感じます。ただし、中央の奥にある花の高さは明らかに違ってしまっているようです。 お題08:男性の髪型をイラストに合わせて変更 男性の髪型をイラストの髪型に合わせて変更し、4枚並べて出力するというお題です。  出力結果の比較 gpt-image-1  一見悪くないのですが、元の画像と比べると顔の皮膚の感じがのっぺりとしており、ほくろなどが消えてしまっています。 Gemini2.5 Flash Image  全てではないですがほくろなどが維持されていたりなど、顔の一貫性は高く感じますが、色が変わってしまっているなど髪型の再現度は低く感じます。 Seedream4.0  今まで高い一貫性を見せてきたSeedream4.0ですが、髪型に関しては完全に指示に背く結果となってしまっているようです。出力結果の中には髪型が長髪化してしまうなど、指示から大きく外れるものも見られました。 この様に比較検証を行なってみると、それぞれの癖などが分かってくるので非常に興味深いと感じました。ただしこの様に各社ごとのバラツキや傾向など今は顕著に見えておりますが、すぐにその差も分からないくらいに精度を上げてくるのではないかと思います。 最後に安全な画像生成・編集について この様に画像編集を簡単に行える様になってきましたが、簡単であるがゆえに意図せずとも間違った使い方をしてしまう可能性があります。 著作権を侵害する様なアウトプットをしない 生成の過程で著作権を侵害する恐れのあるものを参照しない こういったことはもちろんのこと、 未成年者など社会的立場の弱い人々に配慮する 差別や侮辱といった暴力から他者の尊厳を守る ディープフェイクなどによる誤情報の拡散をしない 画像生成・編集を行う際には、この様な配慮も忘れないことを心がけたいと思っております。

AI Image Editing Tool Comparison! Which is the Most Realistic Image Generator through Testing the Latest Models: Google, OpenAI, and ByteDance? [Fall 2025] Introduction On Friday, October 24, 2025, I participated as a presenter at CO-LAB Tech Night vol.4 held at our Osaka Tech Lab. At this event, I presented on the topic of testing the consistency of gpt-image-1, Gemini 2.5 Flash Image, and Seedream 4.0. Since Google recently released Nano Banana pro, I have updated some of the content and would like to share it here as well. The content involves using image generation and editing features provided by OpenAI, Google, and ByteDance to perform image editing on the same tasks and examine what kind of output results we get. If you are wondering which tool is the most suitable for you, I hope this will be helpful. What is gpt-image-1? The model is released in March 2025 and integrated as standard in GPT-4o with a feature capable of image generation and editing. In APIs and other contexts, it is sometimes called by its model name gpt-image-1. A parameter called input_fidelity is enabled. Setting the parameter to high helps significantly improve the consistency of subjects and characters in image editing, which gathered attention. The model has no reference feature but inpainting feature. What is Gemini 3 Pro Image? Commonly known as Nano Banana, it is said to be tuned specifically to maintain consistency of subjects and characters. At its launch, the model with high performance become a hot topic on social media. Upgraded to 3 Pro, the model’s text generation feature is apparently enhanced. Nano Banana was released in August 2025 with reference feature support but without inpainting. What is Seedream 4.0? The model includes a feature to output massive 4K images with fast speed, as well as a capability of handling professional commercial workflows. Particularly, the model’s high subject and character consistency also became a topic on social media. The model was released in September 2025 with both reference and inpainting feature support. AI's Weakness: Maintaining the Subject and Character Consistency When you want to edit only part of an image, AI models often regenerate the entire image, which makes it difficult to maintain the image consistency. Iterated generation by AI models causes gradual changes in the original image; however, such weakness is currently being overcome. So, I would like to compare and examine the output images from these three tools. By the way, for Gemini 3 Pro Image and Seedream 4.0, I used the reference feature (a function that modifies the original image by referencing another image). On the other hand, for gpt-image-1, which does not have a reference feature, I performed editing by overlaying subjects onto the original image. Therefore, while I tried to keep the prompts for all the tools as similar as possible, I applied the ones with slightly different content for gpt-image-1. In this comparison experiment, I generated an average of around 10 images and am posting the output that showed the best results among them. Task 01: Writing Texts on a Blank Label The task is to write a product name on a blank label on a bottle in the following image.  Comparison of Output Results gpt-image-1  The text is somewhat distorted, but no major breakdown was observed. Overall consistency is maintained. Gemini 3 Pro Image  The thickness and size of the text are fine, and no particular breakdown was observed. Overall consistency is maintained. Seedream4.0  The thickness and size of the text are fine, and no particular breakdown was observed. Overall consistency is maintained. Task 02: Change to a Top-Down Angle The task is to change an image of sunflowers in a vase photographed from the side to a top-down angle.  Comparison of Output Results gpt-image-1  The angle is from directly above the sunflowers. Their petals somehow feel artificial. Gemini 3 Pro Image  The angle is from directly above the sunflowers, but they may look slightly small. The texture of the petals looks realistic. Seedream4.0  The image is ended up being slightly from above at an angle, but the texture of the flowers and the detail where just a sunflower on the right side has changed direction have been reproduced. Task 03: Seat a Family in the Back Seat of a Vehicle The task is to edit the people in a family photo as if they are seated in the back seat of a vehicle. Comparison of Output Results gpt-image-1  Facial consistency does not appear to be maintained. And the overall color of the image appeared somewhat yellowish. However, the balance between the people and seat sizes seems good. Gemini 3 Pro Image  The balance, color tone, and other aspects appear to be output with quite high quality. Seedream4.0  The color tone came out dark, but I felt the consistency of the people and the balance were quite high quality. Task 04: Seat a Man and Woman on a Sofa The task is to edit a man and woman from separate images to appear sitting together on a sofa. Comparison of Output Results gpt-image-1  The composition is too close to the subjects, and the people feel a bit large in comparison to the sofa. Facial consistency does not appear to be maintained. Gemini 3 Pro Image  At first glance it looks good, but the people are small in comparison to the sofa. Seedream4.0  There is seemingly no problem with all the composition, balance between sofa and people sizes, and facial consistency. Task 05: Convert English Title on a Magazine to Japanese The task is to convert an English magazine title to Japanese.  Comparison of Output Results gpt-image-1  The title font has become quite bold, but it does not appear to be broken. The cover page photo has also changed to the one showing a castle, giving it a Japanese feel. Gemini 3 Pro Image  Since the model’s text generation feature was enhanced, the output is quite good. The magazine in the image even includes the Japanese subtitle below the title. Moreover, the subtitle clearly makes sense as Japanese. The cover shows cherry blossoms in full bloom alongside red autumn leaves, which is an odd seasonal mismatch. Seedream4.0  The title font is not particularly broken, but unnecessary punctuation is inserted. Small text in the cover has broken down. The photo shows a harbor town-like location with cherry blossoms, giving it a Japanese feel. Task 06: Change a Man's Hairstyle Based on an Illustration The task is to restyle a man's hair to match three different hairstyles from an illustration, outputting the results side by side. Comparison of Output Results gpt-image-1  There seems that subjects tend to be output large. Facial consistency does not appear to be maintained. Also, the long-permed hairstyle could not be reproduced. Gemini 3 Pro Image  The face with long permed hair leans slightly toward an illustrated look, but overall the hairstyles from the illustration have been reproduced well. Seedream4.0  Seedream 4.0, which had shown high consistency so far, did not produce results according to instructions when it came to hairstyles. Conducting this kind of comparative examination reveals the quirks of each, which I found very interesting. While the differences and tendencies of each model are now clearly visible, I think the models will quickly improve their accuracy to the level where these differences become indistinguishable. Finally, about Safe Image Generation and Editing As image editing becomes increasingly easy, the risk of unintentional misuse also grows. To this end, we should NOT: Produce output that infringes copyright; or Reference things that may infringe copyright in the generation process. Of course, as well as these, we should also: Show consideration for minors and others in socially vulnerable positions; Protect the dignity of others from violence such as discrimination and insult; or Not spread misinformation through deepfakes. I would like to take the above points in consideration when performing image generation and editing.

はじめに こんにちは、2025年8月入社の野村です！ 本記事では、KINTO テクノロジーズ株式会社（以下、KTC）に2025年8月に入社した新メンバー4名の入社直後の感想をお伺いし、まとめました。 KTCに興味のある方、特に入社を検討されている方や、今回参加したメンバーの振り返りとして、有益な情報をお届けします。 KTCの社風や雰囲気、新入社員の生の声を通じて、当社の魅力を感じていただければ幸いです。 松倉一光 (Hikaru Matsukura) - MatsuIchi 自己紹介 モバイルアプリ開発Gにてモバイルアプリがアクセスするバックエンドの開発を担当しています。 主に販売店DXの領域で活動しています。 所属チームの体制は？ DX開発G、DXソリューションG、DXエンゲージメントGの方々とOneTeamでDXプロダクトの提供に取り組んでいます。 KTCへ入社したときの第一印象？ギャップはあった？ クラウドインフラチームにインフラ周りの相談ができるのはすごく頼りになり有難いです。 現場の雰囲気はどんな感じ？ みなさん主体的にどんどん動いていてすごい！置いていかれないように頑張ります。 ブログを書くことになってどう思った？ ついに来たか～、思いました（笑） 今後も機会があれば情報発信していきたいです。 三輪 優介さん ⇒　松倉一光さんへの質問 猫派ですか？犬派ですか？ どっちも好きです！　妻の実家で猫飼ってるので、猫と触れ合う機会の方が多いかも。 野村 宏樹(Hiroki Nomura) 自己紹介 AIファーストGという横串組織に所属しています。私の拠点は名古屋です。 前職は自動車会社のSIerとして、とくに自動車制御領域への生成AI活用に取り組んでいました。 所属チームの体制は？ AIに関わることならなんでもやります。 横ぐし組織として、生成AIに関する仕組みやツールの整備もしています。 KINTOのプロダクトや社内生成AIアプリの開発やサポート、トヨタグループの案件にも携わっていますね。 さらに、横串組織として溜まったナレッジをもとに、社外に向けて生成AI研修もしています。 先月はVibeCodingWeekも実施しており、生成AIを使いこなすための社内施策も実施していました。 KTCへ入社したときの第一印象？ギャップはあった？ JTCてきな会社の雰囲気とは逆で、自ら考えてInputとOutputをし続けていくところです。 ツール観点でいうと、Teams文化とSlack文化はここまで違うのか！と驚きました。皆さんが積極的に投稿する文化がとてもいいなと感じてます。 現場の雰囲気はどんな感じ？ 手段先行になるのではなく、やりたいことを実現できるための手段は問わない！ ブログを書くことになってどう思った？ 前職ではなかった文化です。個人的に技術ブログを書いているので抵抗はないですね。 Outputをすることで、客観的に自身の活動の振り返りができるので、とてもPositiveです！ 松倉一光さん ⇒　野村 宏樹さんへの質問 おすすめ名古屋めしはなんですか！？　自分は昔（今はもうなくなっちゃいましたが）東浦町にあったナンハウスの食べ放題によく行ってました。 私はひつまぶしが好きですねー。高いので頻度高く食べれるものではないですが... オフィスの1Fに「炭焼 うな富士 名駅店」がありますね。名古屋にいらしたときにはぜひ！ 三輪 優介(Yusuke Miwa) - Y.M 自己紹介 新車サブスク開発プロダクトマネジメントGに所属してます。室町オフィスで勤務です。 前職では、ふるさと納税サイトの開発PMとしてプロジェクト計画・推進を行なっておりました。 所属チームの体制は？ グループとしては7名ですが、開発者や様々な部署の方とコミュニケーションを取ってます。 実務としては、新車サブスク開発におけるプロジェクト案件やハギレ案件のQCD管理を行い、プロジェクトを完遂させる動きをしてます。 KTCへ入社したときの第一印象？ギャップはあった？ エンジニアの皆さんのコミュニケーションが以前所属していた会社よりも活発で、テックブログの発信はもちろん、プロジェクト開発や要件確認の場面でも積極的にコミュニケーションを取ってくださるので、とても助かっています！ 現場の雰囲気はどんな感じ？ 要求を鵜呑みにして開発するのではなく、要求意図をしっかり理解して最大効果が出るような要件定義と体制構築を日々試行錯誤してます。 ブログを書くことになってどう思った？ 外部発信するという経験は初めてなので、緊張してますw 野村 宏樹さん ⇒　三輪 優介さんへの質問 仕事でもプライベートでも、一番ハマっていることは？ プライベートですが、野球観戦にハマってます！毎年数回程度しか行ってなかったのですが、今年は月に1~2回の頻度で行ってます！ さいごに みなさま、入社後の感想を教えてくださり、ありがとうございました！ KINTOテクノロジーズでは日々、新たなメンバーが増えています！ 今後もいろんな部署のいろんな方々の入社エントリが増えていきますので、楽しみにしていただけましたら幸いです。 そして、KINTO テクノロジーズでは、まだまださまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくは こちら からご確認ください！

こんにちは、KINTOテクノロジーズのFACTORY EC開発グループでバックエンドエンジニアをやっている上原です。 技術書典19に、KINTOテクノロジーズの有志エンジニアによるサークル「KINTOテクノロジーズ執筆部」として参加します。 ※本活動は有志による技術知識の共有を目的としており、企業の公式活動ではありません。 技術書典とは？ 技術書典は、技術書限定の同人誌即売会イベントです。2025年11月15日(土)から11月30日(日)の16日間、オンラインマーケットとオフライン会場で開催されます。 オフライン会場は11月16日(日)に池袋サンシャインシティ 展示ホールDで開催されます。幅広い技術分野の知見が集まり、技術に対してアンテナが高い参加者同士が直接交流できる場となっています。 オフライン会場では実際に著者と対話しながら本を手に取ることができ、オンライン会場では全国どこからでも技術書を入手できます。 商業出版では扱われにくい専門的な技術や実践的なノウハウなど、ここでしか得られない貴重な知見に出会えるのが魅力です。 詳細は技術書典の公式サイトでもご確認いただけます。 https://techbookfest.org/event/tbf19 今回頒布する新書 技術書典19での頒布に向けKINTOテクノロジーズの社内有志でKINTOテクノロジーズ執筆部を結成し、技術本「TECH BOOK By KINTO Technologies Vol.01」を執筆しました。 それぞれの著者がそれぞれのテーマで書き上げた章たちを一冊にまとめた、オムニバス形式の本となっています。  新書「TECH BOOK By KINTO Technologies Vol.01」の表紙。 本書では、Go言語でのテスト手法から、AWSセキュリティ、生成AI、インフラ自動化、モバイル開発、組織づくりまで、幅広いテーマを扱っています。 第1章 Goで学ぶ単体テストのベストプラクティス 第2章 なぜIAM Roleを使うことが、IAMユーザよりセキュリティが高いのか 第3章 「責任ある生成AI」をAWSを使って実装してみよう 第4章 New Relic導入から学ぶフロントエンドエラー監視の実践 第5章 Infrastructure as Codeを利用したクラウドインフラ自動化・統合管理の過去・現在・未来 第6章 今から始めるiOSアプリ開発 第7章 トヨタグループ内製開発組織が追求する、カルチャー×技術両輪によるAIとの協業 第8章 ファシリテーションの力で自律した組織を作りたい 第9章 AzureFunctionsでMCPサーバーを作ってみよう 第10章 AWSのガバナンスとアジリティの両立 第11章 AWSの運用を生成AIを活用して楽にする 第12章 (多分)２周遅れくらいから始めるおうちK8sのススメ 第13章 AWS IoT Greengrassをサンプルアプリを使ってハンズオンしてみよう たっぷり内容が詰まった本書を 無料 で配布します！ こんな方におすすめ Go言語やAWSを使った開発に興味がある方 モバイルアプリ開発やインフラ自動化について学びたい方 生成AIの実践的な活用方法を知りたい方 組織づくりやチームマネジメントに関心がある方 トヨタグループの内製開発に興味がある方 各章で扱う技術的な課題と解決方法が、同じような問題に直面している方々の参考になれば幸いです。 会場 オフライン・オンライン会場ともに出展します。 オフライン会場 開催日時: 2025年11月16日(日) 場所: 池袋サンシャインシティ 展示ホールD（文化会館ビル2F） ブース番号: お15 技術書典19でのフロアマップ。KINTOテクノロジーズ執筆部のブースは「お15」になります オンライン会場 2025年11月15日(土)～11月30日(日) オンラインマーケットにて電子版pdfが配布される おわりに 技術書典19 オフライン会場へお越しの際は、ぜひブース「お15」でお会いしましょう。 遠方にいて現地に行けない方も、電子版を技術書典オンラインマーケットで公開予定ですので、ぜひご覧ください！

Hello, I'm Uehara, a backend engineer in the FACTORY E-commerce Development Group at KINTO Technologies. We will be participating in Techbook Fest 19 as the KINTO Technologies Writing Club formed by volunteer engineers from KINTO Technologies. ※This activity is conducted by volunteers for the purpose of sharing technical knowledge and is not an official corporate activity. What is Techbook Fest? Techbook Fest is a doujinshi convention exclusively for technical books. It will be held for 16 days from November 15 (Sat) to November 30 (Sun), 2025, both in an online marketplace and at a physical venue. The offline event will be held on November 16 (Sun) at Ikebukuro Sunshine City Exhibition Hall D. It will bring together knowledge from a wide range of technical fields and provide a space where participants with a keen interest in technology can interact directly. At the physical venue, you can pick up books and talk directly with the authors, while at the online venue, you can access technical books from anywhere in Japan. The appeal lies in gaining access to valuable knowledge available only here, including specialized technologies and practical know‑how that are seldom addressed in commercial publishing. For more details, please check the official Techbook Fest website. https://techbookfest.org/event/tbf19 New Book to be Distributed For distribution at Techbook Fest 19, volunteers from within KINTO Technologies formed the KINTO Technologies Writing Club and wrote the technical book "TECH BOOK By KINTO Technologies Vol.01." It is an omnibus-format book that compiles chapters written by each author on their respective themes.  Cover of the new book "TECH BOOK By KINTO Technologies Vol.01." This book covers a wide range of topics, from testing methods in Go language to AWS security, generative AI, infrastructure automation, mobile development, and organizational building. Chapter 1: Best Practices for Unit Testing with Go Chapter 2: Why Using IAM Roles Provides Higher Security Than IAM Users Chapter 3: Let's Implement Responsible Generative AI Using AWS Chapter 4: Practical Frontend Error Monitoring Learned from New Relic Implementation Chapter 5: Past, Present, and Future of Cloud Infrastructure Automation and Integrated Management Using Infrastructure as Code Chapter 6: Getting Started with iOS App Development Chapter 7: Toyota Group's In-House Development Organization Pursuing Collaboration with AI Through Both Culture and Technology Chapter 8: Creating an Autonomous Organization with the Power of Facilitation Chapter 9: Let's Create an MCP Server with Azure Functions Chapter 10: Balancing AWS Governance and Agility Chapter 11: Making AWS Operations Easier Using Generative AI Chapter 12: Recommendations for Home K8s Starting (About) Two Laps Behind Chapter 13: Let's Try a Hands-On Session with AWS IoT Greengrass Using a Sample Application We will distribute this book, packed with content, for free ! Recommended For Those interested in development using Go language or AWS Those who want to learn about mobile app development or infrastructure automation Those who want to know practical applications of generative AI Those interested in organizational building or team management Those interested in in-house development within the Toyota Group We hope that the technical challenges and solutions covered in each chapter will serve as a reference for those facing similar problems. Venue We will exhibit at both physical and online venues. Physical Venue Date and Time: Sunday, November 16, 2025 Location: Ikebukuro Sunshine City Exhibition Hall D (Cultural Center Building 2F) Booth Number: O15 Floor map at Techbook Fest 19. The KINTO Technologies Writing Club booth is "お15" Online Venue Saturday, November 15 - Sunday, November 30, 2025 Electronic version PDF will be distributed at the online marketplace Conclusion If you visit the Techbook Fest 19 physical venue, please come see us at booth お15. For those who live far away and cannot attend in person, we plan to publish the electronic version on the Techbook Fest online marketplace, so please take a look!

Introduction Hello, I'm Nomura, who joined in August 2025! In this article, I interviewed four new members who joined KINTO Technologies Corporation (KTC) in August 2025 about their impressions right after joining to compile their responses. I hope this provides useful information for those interested in KTC, especially those considering joining us, as well as serving as a reflection for the members who participated. I would be happy if you could get interested in our company through learning from the article about the corporate culture, atmosphere, and candid voices of its new employees. Hikaru Matsukura - MatsuIchi Self-introduction I'm in the Mobile App Development Group, where I'm responsible for developing the backend that mobile apps access. I mainly work in the domain of Dealer Digital Transformation (DX) projects. How is your team structured? We work as one team with members from the Digital Transformation Development Group, Digital Transformation Solution Group, and Digital Transformation Engagements Group to deliver products to accelerate DX. What was your first impression of KTC when you joined it? Were there any surprises? Being able to have discussions with the Cloud Infrastructure Team about infrastructure matters is extremely helpful and encouraging. What is the atmosphere like on-site? Everyone proactively takes initiative and moves forward—it's amazing! I’ll do my best, not to falling behind. How did you feel about writing a blog post? I thought like, "So it's finally my turn!" (lol) I'd like to continue to share information if I get any chance to post my blogs in the future. Question from Yusuke Miwa to Hikaru Matsukura Are you a cat person or a dog person? I like both! My wife's family has a cat, so I probably have more opportunities to interact with cats. Hiroki Nomura Self-introduction I belong to the AI First Group, which is a cross-functional organization. I’m based in Nagoya. In my previous job, I worked as a system integrator (SIer) for an automotive company, particularly focusing on applying generative AI to automotive control areas. How is your team structured? We do everything AI-related. As a cross-functional group, we also develop systems and tools related to generative AI. We're involved in developing and supporting KINTO products and internal generative AI apps, as well as Toyota Group projects. Additionally, using the knowledge shared across the whole company, we are providing generative AI training externally. Last month, we held the Vibe Coding Week event, and we've been implementing internal initiatives to master generative AI. What was your first impression of KTC when you joined it? Were there any surprises? Unlike the atmosphere of traditional Japanese companies, here you continuously think for yourself and keeping up a cycle of input and output. In terms of tools used in KTC, I was surprised by the difference between Teams culture and Slack culture! I really appreciate the culture where everyone actively posts. What is the atmosphere like on-site?? We focus on achieving what we want to accomplish by any means necessary, rather than thinking about the means first! How did you feel about writing a blog post? This is a culture that was not at my previous job. I personally write technical blogs, so I feel comfortable with it. By producing output, I can objectively reflect on my own activities, so it's very positive! Question from Hikaru Matsukura to Hiroki Nomura What do you recommend us as a local specialty food in Nagoya? I used to frequently go to Nan House, a buffet-style Indian restaurant in Higashiura-cho (that is currently closed, though). I like hitsumabushi. It's so expensive that I can't enjoy it often, though... There's Sumiyaki Una Fuji Meieki Branch on the 1st floor of the building where our office is located. Please try it when you come to Nagoya! Yusuke Miwa - Y.M Self-introduction I belong to the New Vehicle Subscriptions Product Management Group, working at the Muromachi office. In my previous job, I worked as a PM to develop a furusato nozei (hometown tax) website, planning and driving projects. How is your team structured? Our group has 7 members, and I communicate with developers and people from different divisions. In practice, I manage QCD for new vehicle subscription development projects and other miscellaneous projects to complete them. What was your first impression of KTC when you joined it? Were there any surprises? Communication among engineers in KTC is more active than at my previous company. Not only do they publish tech blogs, but they also actively communicate with others during project development and requirements confirmation, which is very helpful! What is the atmosphere like on-site? Rather than developing products simply by following requirements, we thoroughly understand the product users’ intent behind their requests and continuously try to define the requirements and build the structures to produce maximum effect. How did you feel about writing a blog post? This is my first experience to share information externally, so I'm nervous (lol). Question from Hiroki Nomura to Yusuke Miwa What are you most into these days, whether for work or personal life? On the personal side, I'm into watching baseball! I used to go to baseball games only a few times a year, but this year I'm going once or twice a month! Closing Thanks to everyone for sharing their impressions after joining KTC! KINTO Technologies is constantly welcoming new members! We'll continue to feature more blog posts to introduce new members from various divisions going forward, so we hope you to look forward to them. And we are still recruiting members to work with us in various divisions and positions! Please check here for details!

はじめに こんにちは！KINTO テクノロジーズ、クラウドセキュリティ G の大高です。 普段は、クラウド環境のガードレール整備と CSPM や脅威検知を利用した監視やカイゼン活動に取り組んでいます。 私たちのグループでは、日々の業務の一環として、 Amazon GuardDuty が検知した脅威に関して、ログの詳細分析を行い、正常な操作であるかを確認する場面があります。このログ分析の効率化を目指して、Amazon Q Developer を活用した検証をしてみました。 Amazon GuardDuty の脅威検知の対応 KINTO テクノロジーズでは、 AWS 環境の脅威検知に Amazon GuardDuty を利用しています。 Amazon GuardDuty が脅威を検知すると、Slack のチャンネルに通知が届くようになっており、この通知を受けて、セキュリティ担当者がログの詳細分析を行います。必要に応じて、対象のユーザーにヒアリングを行いながら、 JIRA チケットに経過を記録し、対応状況を管理しています。 現在の Amazon GuardDuty の脅威検知対応のフロー 今回の取り組みでは、脅威検知後の対応フローのうち、ログ分析のタスクを Amazon Q Developer を活用して、効率化することを目指しています。 AI によるログ分析を組み込んだ場合の Amazon GuardDuty の脅威検知対応のフロー Amazon Q Developer とは Amazon Q Developer は、 AWS が提供する開発アシスタント AI です。 AWS を活用したクラウド開発に特化しており、以下のような様々なユースケースに対応しています。 AWS 環境のリソース、イベント、アクティビティの調査 AWS 環境のトラブルシューティング 開発・デバッグ・コーディング支援 ドキュメントの作成 Amazon Q Developer は、デフォルトの状態でも Amazon GuardDuty で検知した脅威について、関連ログを分析することができます。例えば、Amazon GuardDuty で検知された脅威の Findings ID とともにログ調査を依頼すると、以下のように Amazon Q Developer は Built-In のツールを使用して、自律的に調査と分析を行ってくれます。 (以下は、 Amazon Q Developer がログ調査を行う過程を一部抜粋したものです。) Amazon Q Developer が自律的にログ分析を行う様子 Amazon Q Developer が生成したレポートには、操作を行なったユーザーや影響を受けたリソースなど検知した脅威の概要がまとめられており、推奨される対応の提案も含まれています。 デフォルトの状態で Amazon Q Developer が出力した分析レポート しかし、実際の業務では、操作を行なったユーザーの認証の状態や操作時間のログも含めて、確認・分析を行い正常な動作であるかを判断しており、上記の内容に加え、さらなる追加の調査が必要です。 また、詳細なログ調査・分析を行うために、Amazon Q Developer とチャットによるやり取りを重ねる中で、様々な課題が見えてきました。 ログ分析を行う上での課題 Amazon Q Developer は、デフォルトの状態でも Amazon GuardDuty で検知した脅威の分析を行うことができますが、実務レベルのログの詳細分析を行うためには多くの課題があります。 1. AWS API のスロットリング制限 Amazon Q Developer は、 Built-In のツールや MCP サーバーにより提供されているツールを使用して実行した API リクエストにエラーレスポンスが返ってきた場合、自律的に修正を行い、再度、 API リクエストを送信します。 例えば、 API リクエストの文法が誤っていた場合は、自律的にコマンドの修正を行い、再度、リクエストを送信します。しかし、 API リクエストの再送が多くなると、スロットリングの上限に達してしまい、最終的に必要な情報を取得できないまま、不正確な回答や期待とは異なる回答を生成してしまうことがあります。 Amazon Q Developer で実行した API リクエストがスロットリングの上限に到達してしまい、情報の取得ができない。 2. 収集しているログの制限 Amazon Q Developer は AWS CloudTrail に保存されているログを検索・分析できますが、そもそもログが取得されていない場合は分析することができません。 AWS CloudTrail では、デフォルトで管理イベント（ IAM ユーザーの作成や EC2 インスタンスの起動など）のログは自動的に収集されますが、データイベント（ S3 バケットへのファイルアップロードや Lambda 関数の実行など）のログは手動で設定を有効化しなければ収集されません。そのため、Amazon GuardDuty が S3 バケットや Lambda 関数への不審なアクセスを検知した場合でも、事前にデータイベントのログ収集を有効化していなければ、Amazon Q Developer で AWS CloudTrail ログを検索しても詳細な分析に必要な情報を取得することができません。 Amazon Q Developer がログ分析に必要な情報を取得できなければ、推測による不正確な回答の生成をしてしまう可能性があります。 AWS CloudTrail でデータイベントの取得を有効化していないが、 Amazon Q Developer はデータイベントの検索を試みる。 AWS 環境のログの収集・保存にはコストがかかるため、会社や組織の予算に合わせて、意図的にログの収集・保存を実施していない場合もあります。現在の AWS 環境のログの収集状況を考慮して、 Amazon GuardDuty で検知した脅威の分析を行う際に、Amazon Q Developer がどのログを活用することができるかについて整理する必要があります。 3. コンテキストウィンドウの制限 生成 AI が一度に処理することができるテキストの長さのことをコンテキストウィンドウと言い、生成 AI の「記憶力」を指し示します。コンテキストウィンドウは、トークンという単位でカウントされており、過去のやり取りを含めて一定のトークン数の範囲内であれば過去のやりとりの内容を踏まえた受け答えを生成することができます。 非常に長い文章をプロンプトに入力したり、生成 AI と長いやり取りを続けたりして、トークン数の合計がコンテキストウィンドウの範囲を超えると、Amazon Q Developer は、過去に与えた指示を忘れてしまい、期待した回答をしてくれなかったり、不正確な情報を出力してしまったりする可能性が高まります。 コンテキストウィンドウを超過すると、 Amazon Q Developer が自動的に過去情報を要約して、詳細な内容は忘れてしまう Amazon Q Developer もコンテキストウィンドウの制限があり、 200K トークンまでとなっています。（2025年10月16日現在） トークン数のカウントには、 API のリクエストやレスポンスにより得られた情報も含まれます。無駄なプロンプトの入力を避けるだけでなく、不要な API コールを繰り返して、不要なトークンを消費しないように注意する必要があります。 4. 出力の一貫性の課題 生成 AI は、全く同じプロンプトを与えたとしても、生成する回答の出力フォーマットや含まれる情報が毎回異なります。Amazon Q Developer にログ分析のレポートを生成するように指示した場合でも、レポートに含まれる情報が毎回異なったり、レポートの構成が毎回異なったりする可能性があります。 このような場合、必要な情報を得ることができず、レポートに基づいて対応を検討したりすることが難しくなります。 課題を克服するための工夫 このように Amazon Q Developer で Amazon GuardDuty が検知した脅威を詳細分析するには、多くの課題があります。 これらの課題を乗り越えて、Amazon Q Developer を期待通りに動作をさせるために、以下の2つのアプローチで改善が必要です。 Amazon Q Developer がログの詳細分析に必要となる情報を効率的に収集して、正確な情報に基づく回答を生成できるようにする。 Amazon Q Developer にログの詳細分析を実施する手順や必要な操作に関する詳細な指示を与えて、実際の分析業務と同様にタスクを実行させる。 具体的には Amazon Q Developer に、MCP 連携とプロンプトの調整を行うことで改善を図りました。 1. MCP 連携 MCP（ Model Context Protocol ）とは、生成 AI が外部のツールやデータソースと連携を行うために定められた標準プロトコルです。Amazon Q Developer は、MCP に対応しています。連携したい MCP サーバーを設定ファイルに記入して、 Amazon Q Developer を起動することで、外部のツールの利用や、データ参照を行うことができます。 Amazon GuardDuty で検知した脅威に関するログの詳細分析を行うために、 Amazon Q Developer に以下のツールを連携しています。 ツール 内容 Built-in ローカル環境へのファイルの読み書きや、API による AWS リソースの操作が実行できるツールがデフォルトで提供されています。 AWS Knowledge MCP Server AWS に関する最新のニュースやブログの情報を含む AWS ナレッジにアクセスするためのツールが提供されています。 AWS Documentation MCP Server AWS に関するドキュメント情報にアクセスするためのツールが提供されています。 CloudTrail MCP Server AWS CloudTrail を使用してログを検索したり、分析を行うためのツールが提供されています。 Splunk MCP Server Splunk に保存されているログを検索したり、分析を行うためのツールが提供されています。 弊社では、Splunk Cloud を利用して SIEM ( Security Information and Event Management ) を構築しており、AWS CloudTrail のログや Entra ID の認証ログといったさまざまなログが集約されています。 Splunk 社が提供する Splunk MCP Server と連携し、 Splunk Cloud の検索クエリを実行することができるツールを提供することで、Amazon Q Developer が AWS CloudTrail に保存されたログに限らず、横断的に詳細分析を行うことができるようにしています。 2. プロンプトエンジニアリング プロンプトエンジニアリングとは、生成 AI に与える入力情報を工夫することで、意図した応答を引き出したり、回答精度の向上を図る手法です。生成 AI に対して、指示の背景や追加の情報を提供したり、タスクの遂行に関する詳細な指示を与えることで、期待した回答を生成するように調整を行っていきます。 Amazon GuardDuty で検知した脅威に関するログの詳細分析では、 Amazon Q Developer に以下のような情報をプロンプトで提供することで回答精度の改善を図っています。 項目 記載内容 例 ログ調査に必要となるシステム構成の情報 ・どんなログが保存されているか ・どこに保存されているかなど CloudTrail のログは、Splunk Cloud に保存されています。 ログの調査手順を明示的に指示 ・ログ分析の際に使用するツール ・何を調査するかなど ・ログ分析の際は、Splunk MCP Server を優先的に使用してください。 ・操作時間帯が 09:00 〜 18:00 の時間帯は正常な動作であり、低リスクと判断してください。 出力形式（レポートの内容）を具体的に指定 ・レポートの出力形式の指定 ・レポートに含める情報の指定 ・レポートは、Markdown 形式で作成してください。 ・レポートは、以下の章立てで作成してください。: （以下、章立てを記載） 実行するコマンドの具体的サンプルを提供 Splunk の検索クエリなど 認証状況の確認では、以下のコマンドを実行してください。 'index=example userPrincipalName="<メールアドレス>" | stats count by status.errorCode, status.failureReason | sort -count' 禁止事項の明記 ・実行をしてはいけない操作は何か ・出力に含めてはいけない情報は何か ・自分で日付から曜日を計算しないでください。 ・推測や仮定に基づく関連付けはしないでください。 プロンプトエンジニアリングにおいては、生成 AI に与える情報量が少ないと、出力内容の調整に効果が出ないことがあります。プロンプトに含む条件や指示内容を生成 AI を使用しながらできる限り詳細に記載することで、適切な情報量になるようにプロンプトを調整しました。 工夫による改善と成果 上記の調整を実施後、改めて Amazon Q Developer にログ分析を依頼した結果、生成されたレポートが以下になります。プロンプトに入力した指示は、デフォルト状態の Amazon Q Developer に分析を依頼したときと同じ文章を入力しています。 # GuardDuty Finding 詳細分析レポート **Finding ID**: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx **検出リージョン**: ap-northeast-1 **AWSアカウントID**: 000000000000 **AWSアカウント名**: （不明） **分析日時**: 2025-10-16 17:44:14 ## 1. エグゼクティブサマリー ### 重要な発見 - **実際のユーザー特定**: User Name（ < User Email Address > ） - **外部委託ユーザー**: 「xxxx-」プレフィックスにより外部委託会社のユーザーと判定 - **誤検知の可能性**: 高い（正規ユーザーによる通常業務の可能性） - **CloudTrailログ**: 対象AWSアカウントのログがSplunkに存在せず、詳細な認証チェーン追跡は不可 ### 緊急対応の要否判断 - **緊急度**: 低 - **理由**: 正規ユーザーによる通常業務時間帯での活動、Entra ID認証も正常 ### 主要調査結果の要点 - Finding発生時刻: 2025年9月9日 13:20:05 JST（月曜日の通常業務時間） - 操作内容: S3バケット「< S3-Bucket-Name >」からのGetObject API実行 - ユーザー: 外部委託会社の User Name - 異常性: GuardDutyの機械学習による異常検知だが、業務時間帯での正規操作 ### 推奨アクション（優先度付き） 1. **優先度: 低** - 当該ユーザーへの業務内容確認（念のため） 2. **優先度: 低** - S3アクセスログの詳細確認（必要に応じて） 3. **優先度: 中** - GuardDutyの機械学習ベースライン調整検討 ## 2. 脅威の概要 **脅威タイプ**: Exfiltration:S3/AnomalousBehavior **重要度**: 8.0（高） **検出内容**: IAMエンティティによる異常なS3 API呼び出し GuardDutyが検出した「異常な」S3 GetObject API呼び出しは、機械学習ベースラインからの逸脱を示しているが、実際には正規ユーザーによる通常業務時間帯での操作と判定される。 ## 3. 脅威の詳細 ### 攻撃手法の詳細分析 - **API**: S3 GetObject - **対象バケット**: < S3-Bucket-Name > - **認証方式**: AuthHeader（正規のAWS認証） - **User Agent**: aws-sdk-rust/1.3.8（開発ツール使用） ### 攻撃者のプロファイリング 実際の攻撃者ではなく、正規ユーザー「 User Name 」による操作： - 外部委託会社（「xxx-」プレフィックス）のユーザー - 通常業務でAWS SSOを使用 - 開発環境（sandbox）での作業実績あり ### 攻撃の時系列分析 - **2025-09-09 13:20:05 JST**: S3 GetObject API実行 - **2025-09-09 13:29:43 JST**: GuardDutyによる検出 - **同日同時刻**: Entra IDでのAWS SSOログイン成功を確認 ### 影響範囲の詳細評価 - **影響を受けたリソース**: S3バケット「< S3-Bucket-Name >」 - **データ漏洩リスク**: 低（sandboxバケット、正規ユーザー） - **横展開リスク**: なし - **継続的脅威**: なし ### 類似攻撃パターンとの比較 GuardDutyの機械学習による異常検知であり、実際の攻撃パターンとは異なる： - 正規認証チェーンの使用 - 通常業務時間帯での操作 - 開発環境での作業 ### セキュリティ制御の回避手法 回避手法は使用されておらず、全て正規の認証・認可プロセスを経由： - Identity Center経由のSSOログイン - 適切なロール権限での操作 - 正規のAWS SDK使用 ## 4. プリンシパル情報 **ユーザー名**: < Role Name > **実際のユーザー**: User Name（ < User Email Address > ） **ユーザータイプ**: AssumedRole（Identity Center経由） **アクセスキーID**: < Access Key ID > **プリンシパルID**: < Principle ID> ### ユーザー属性詳細 - **氏名**: User Name - **所属**: 外部委託会社（「xxx-」プレフィックス） - **メールアドレス**: < User Email address> - **ロール**: < Role Name > ## 5. 異常性分析 ### 時間帯による異常性評価 - **Finding発生日**: 月曜日（通常業務日） - **Finding発生時刻**: 13:20:05 JST（通常業務時間） - **異常性レベル**: **低** - 通常業務時間帯での活動 - **リスク評価**: 低リスク ### 地理的異常性 - **アクセス元**: 日本（< ISP Name >） - **想定業務拠点**: 日本国内 - **異常性**: なし - 想定される業務拠点からのアクセス ### 操作パターンの異常性 - **使用ツール**: aws-sdk-rust（開発ツール） - **操作内容**: S3 GetObject（データ取得） - **対象**: sandboxバケット（開発環境） - **異常性**: 低 - 開発業務での通常操作 ### 認証チェーンの異常性 - **Entra ID認証**: 正常（エラーコード0） - **Identity Center**: 正常なSSOセッション - **AWS認証**: 正規のAssumedRole - **異常性**: なし - 全て正規プロセス ### Entra ID認証ログ分析結果 #### 実行したSplunkクエリと結果 **1. 基本情報取得**: index=< example > userPrincipalName="< User Email Address >" | table userDisplayName userPrincipalName **結果**: ユーザー名「 User Name 」を確認 **2. 30日行動パターン**: index=< example > userPrincipalName="< User Email Address >" earliest=-30d | stats count, values(location.city), values(deviceDetail.browser), values(appDisplayName) by userPrincipalName **結果**: - 総ログイン回数: 59回 - アクセス地域: < Access Area > - ブラウザ: Chrome 138.0.0 - 利用アプリ: AWS SSO, Microsoft 365 Support Service, Microsoft Account Controls V2, Microsoft Teams Web Client **3. 時間パターン分析**: index=< example > userPrincipalName="< User Email Address >" earliest=-7d | eval weekday=strftime(_time, "%A"), hour=strftime(_time, "%H") | stats count by weekday, hour | sort weekday, hour **結果**: - 平日・休日問わず16時台のアクセスが多い - 深夜0時台のアクセスも複数回確認（金曜、木曜、火曜、水曜） - 通常業務時間外のアクセスパターンも存在 **4. 認証状況**: index=< example > userPrincipalName="< User Email Address >" | stats count by status.errorCode, status.failureReason | sort -count **結果**: - 成功ログイン: 28回（エラーコード0） - 認証失敗: 確認されず - 認証成功率: 100% **5. Finding発生時刻周辺の認証ログ**: index=< example > userPrincipalName="< User Email Address >" (Finding発生時刻周辺) **結果**: - IPv6アドレス（< IPv6 Address >）からのAWS SSOログイン成功 - 日本国内からのアクセス - 認証成功（エラーコード0） ### 本人性確認結果 **振舞い分析による本人確認**: - **通常パターンとの一致**: 高い一致度 - **アクセス地域**: 通常の< Access Area >からのアクセス - **利用アプリケーション**: AWS SSOの通常利用 - **認証成功率**: 100%（異常な失敗なし） - **本人らしさ**: **高い** - 通常の行動パターンと一致 ## 6. リスク評価 ### 総合リスク評価: **低** #### 根拠 1. **正規ユーザーによる操作**: 実在する外部委託ユーザーによる操作 2. **通常業務時間**: 月曜日13:20の通常業務時間帯 3. **正規認証プロセス**: Identity Center経由の正常な認証チェーン 4. **開発環境**: sandboxバケットでの開発作業 5. **本人性確認**: Entra IDログで本人の通常パターンと一致 #### 誤検知の可能性 **高い** - GuardDutyの機械学習ベースラインが、このユーザーの通常パターンを十分に学習していない可能性 #### セキュリティ影響 - **データ漏洩リスク**: 極低 - **システム侵害リスク**: なし - **横展開リスク**: なし ## 7. 詳細調査 ### CloudTrailログ存在確認結果 **対象AWSアカウント（000000000000）のCloudTrailログがSplunkに存在しないため、詳細な認証チェーン追跡は困難** 実行したクエリ: index=< example > sourcetype=aws:cloudtrail account=000000000000 | head 1 結果: 0件のログが見つかりました ### ソースIPアドレスからの候補ユーザー調査 **地理的近接性による候補ユーザー調査**: - Finding詳細のIPアドレス（< IP Address >）での直接検索: 0件 - 実際の認証ログではIPv6アドレス（< IPv6 Address >）を使用 - 両方とも日本国内からのアクセスで地理的整合性あり ### 追加調査すべき点 1. **GuardDutyベースライン調整**: 外部委託ユーザーの通常パターン学習 2. **S3アクセスログ**: 必要に応じてバケットレベルでの詳細ログ確認 3. **ユーザー業務確認**: 当該時刻での業務内容確認（念のため） ### 不明な点や疑問点 1. GuardDutyが「異常」と判定した具体的な学習ベースライン 2. 同一バケットでの他ユーザーのアクセスパターン 3. aws-sdk-rustツール使用の業務上の必要性 ## 8. 推奨対応策 ### 即座の対応（優先度: 低） 1. **ユーザー確認**: User Name 氏への業務内容確認（念のため） 2. **継続監視**: 同様のパターンでの再発監視 ### 短期対応（1週間以内） 1. **GuardDuty調整**: 外部委託ユーザーの正常パターン学習促進 2. **アクセスパターン分析**: sandboxバケットでの通常アクセスパターン確立 ### 中長期対応（1ヶ月以内） 1. **ベースライン最適化**: GuardDutyの機械学習ベースライン調整 2. **監視ルール見直し**: 外部委託ユーザー向けの監視ルール策定 3. **ドキュメント整備**: 正常な開発作業パターンの文書化 ### 対応不要と判断される理由 - 正規ユーザーによる通常業務時間帯での正当な操作 - 全ての認証プロセスが正常 - セキュリティリスクが極めて低い - 誤検知の可能性が高い **結論**: このFindingは誤検知と判定され、セキュリティインシデントとしての対応は不要。GuardDutyのベースライン調整を推奨。 デフォルト状態の Amazon Q Developer に Amazon GuardDuty で検知した脅威のログ分析を依頼した場合と比較して、次のような改善が見られました。 MCP 連携やプロンプトエンジニアリングにより Amazon Q Developer を調整したことで、ログ分析の出力に含まれる情報とその内容を期待するものに近づけることができました。 プロンプト内で生成するレポートのフォーマットを指定したことで、複数回の検証でも出力内容に必要な情報が安定して含まれるようになりました。 Splunk Cloud 上のログデータを利用して、検知した脅威のリスク判定を行うこともできており、より実務に近い分析を行うことができました。 一方で、以下の観点では、さらなる改善が必要になります。 複数回の検証を行う中で、不正確な情報を含むレポートが生成されることもありました。 プロンプト内で明確な指示をしているにもかかわらず、指示を無視した出力がされることがありました。 Splunk Cloud 上に AWS CloudTrail のログが取り込まれていない場合に、CloudTrail MCP Server が提供するツールを使用して、直接 AWS CloudTrail のログを検索せずに、Entra ID のログのみでリスク判断を行なうことがありました。 完全にハルシネーションを排除することはできず、引き続き、出力内容の検証と実行した操作をモニタリングしながら、 Amazon Q Developer の調整を継続的に行う必要があります。 まとめ Amazon Q Developer を活用したログ分析は、デフォルトの状態では課題も多いですが、 MCP 連携やプロンプトの調整を行うことにより、実際にログ分析に活用できそうな応答を生成できるようになりました。しかし、その生成内容を完全に信用することはできず、回答の正確さや実際に操作した内容などについては、引き続き、調整と改善を行なっていく必要がありそうです。 また、今回は Amazon Q Developer をログ分析に活用するための方法に焦点を当てて検証を行ったため、本記事では言及していませんが、生成 AI のセキュアな活用という観点で、MCP サーバの最小権限の管理や認証情報の管理など、実際に運用を行なっていくためには、まだまだ改善すべき課題はあります。 引き続き、 Amazon Q Developer の活用方法を模索しながら、セキュリティ運用の改善・強化に取り組んでいきたいと思います。

Exploring Threat Analysis in Amazon GuardDuty with Amazon Q Developer Introduction Hello! I'm Otaka from KINTO Technologies' Cloud Security Group. My daily work involves establishing cloud environment guardrails and monitoring and improvement activities using CSPM and threat detection. As part of our group's daily operations, we perform detailed log analysis when Amazon GuardDuty detects threats to verify whether they represent normal operations. To streamline this log analysis process, I conducted a verification using Amazon Q Developer. Responding to Threat Detection with Amazon GuardDuty At KINTO Technologies, we use Amazon GuardDuty for threat detection in our AWS environment. When Amazon GuardDuty detects a threat, notifications are sent to a Slack channel. Upon receiving these notifications, the security team performs detailed log analysis. When necessary, we interview the relevant users and record progress in JIRA tickets to manage response status. Current Amazon GuardDuty threat detection response flow In this initiative, we aim to improve efficiency in the log analysis task within the threat detection response flow by utilizing Amazon Q Developer. Amazon GuardDuty threat detection response flow incorporating AI-based log analysis What is Amazon Q Developer Amazon Q Developer is a development assistant AI provided by AWS. It specializes in cloud development using AWS and supports various use cases such as: Investigating resources, events, and activities in AWS environments Troubleshooting AWS environments Development, debugging, and coding assistance Document creation Amazon Q Developer can analyze related logs for threats detected by Amazon GuardDuty even in its default state. For example, when requesting log investigation along with the Findings ID of a threat detected by Amazon GuardDuty, Amazon Q Developer autonomously conducts investigation and analysis using built-in tools as shown below. (The followings are excerpts of the log investigation process performed by Amazon Q Developer.) Amazon Q Developer autonomously performing log analysis The report generated by Amazon Q Developer summarizes the detected threats, including the user who performed the operation and affected resources, and also includes recommended response suggestions. Analysis report output by Amazon Q Developer in default state In actual operations, we also check and analyze the authentication status of the user who performed the action and the log of the operation time to determine whether it was a normal activity. In addition to the above, further investigation is required. Also, while conducting detailed log investigation and analysis through repeated interactions with Amazon Q Developer via chat, various challenges became apparent. Challenges in Log Analysis While Amazon Q Developer can analyze threats detected by Amazon GuardDuty even in its default state, there are many challenges in performing practical-level detailed log analysis. 1. AWS API Throttling Limits When Amazon Q Developer receives error responses to API requests executed using built-in tools or tools provided by MCP servers, it autonomously makes corrections and resends the API request. For example, if API request syntax is incorrect, it autonomously corrects the command and resends the request. However, if API request retries become too frequent, the throttling limit may be reached, which can prevent the necessary information from being obtained and ultimately lead to inaccurate or unexpected responses. API requests executed by Amazon Q Developer reach throttling limits, preventing information retrieval. 2. Collected Log Limitations Amazon Q Developer can search and analyze logs stored in AWS CloudTrail, but cannot analyze logs that haven't been collected in the first place. AWS CloudTrail automatically collects management event logs (such as IAM user creation or EC2 instance launches) by default, but data event logs (such as file uploads to S3 buckets and Lambda function executions) are not collected unless manually enabled. Therefore, even when Amazon GuardDuty detects suspicious access to S3 buckets or Lambda functions, if data event log collection hasn't been enabled beforehand, searching AWS CloudTrail logs with Amazon Q Developer cannot retrieve information necessary for detailed analysis. If Amazon Q Developer cannot obtain information necessary for log analysis, it may generate inaccurate responses based on speculation. Amazon Q Developer attempts to search data events even though data event collection is not enabled in AWS CloudTrail. Since collecting and storing logs in AWS environments incurs costs, organizations may intentionally not collect or store certain logs based on budget constraints. It's necessary to organize which logs Amazon Q Developer can utilize when analyzing threats detected by Amazon GuardDuty, considering the current log collection status in the AWS environment. 3. Context Window Limitations The length of text that generative AI can process at once is called the context window, representing the AI's memory.Context windows are counted in units called tokens, and within a certain token count range including past interactions, the AI can generate responses based on previous conversation content. When extremely long text is input into prompts or long interactions continue with the generative AI, and the total token count exceeds the context window range, Amazon Q Developer forgets previously given instructions, potentially failing to provide expected responses or outputting inaccurate information. When context window is exceeded, Amazon Q Developer automatically summarizes past information and forgets detailed content Amazon Q Developer also has context window limitations, currently set at 200K tokens (as of October 16, 2025). Token counting includes information obtained through API requests and responses. It's necessary to not only avoid unnecessary prompt input but also avoid repeating unnecessary API calls that consume unnecessary tokens. 4. Output Consistency Challenges Generative AI produces different output formats and included information each time, even when given identical prompts. When instructing Amazon Q Developer to generate log analysis reports, the information included in reports and report structure may differ each time. In such cases, it becomes difficult to obtain necessary information and consider responses based on reports. Approaches to Overcome Challenges As shown above, there are many challenges in performing detailed analysis of threats detected by Amazon GuardDuty using Amazon Q Developer. To overcome these challenges and make Amazon Q Developer operate as expected, improvements are needed through two approaches: Enable Amazon Q Developer to efficiently collect information necessary for detailed log analysis and generate responses based on accurate information. Provide Amazon Q Developer with detailed instructions regarding procedures for conducting detailed log analysis and necessary operations, enabling it to execute tasks similar to actual analysis work. Specifically, improvements were made through MCP integration and prompt adjustments for Amazon Q Developer. 1. MCP Integration MCP (Model Context Protocol) is a standard protocol defined for generative AI to integrate with external tools and data sources. Amazon Q Developer supports MCP. By specifying the MCP servers to integrate in the configuration files and launching Amazon Q Developer, you can use external tools and reference data. For detailed log analysis of threats detected by Amazon GuardDuty, the following tools are integrated with Amazon Q Developer. Tool Description Built-in Tools for reading/writing files to local environments and operating AWS resources via API are provided by default. AWS Knowledge MCP Server Tools for accessing AWS knowledge including latest AWS news and blog information are provided. AWS Documentation MCP Server Tools for accessing AWS documentation information are provided. CloudTrail MCP Server Tools for searching and analyzing logs using AWS CloudTrail are provided. Splunk MCP Server Tools for searching and analyzing logs stored in Splunk are provided. At our company, we have built a SIEM (Security Information and Event Management) using Splunk Cloud, aggregating various logs such as AWS CloudTrail logs and Entra ID authentication logs. By integrating with the Splunk MCP Server provided by Splunk and providing tools that can execute Splunk Cloud search queries, Amazon Q Developer can perform detailed cross-sectional analysis not limited to logs stored in AWS CloudTrail. 2. Prompt Engineering Prompt engineering is a technique for eliciting intended responses and improving response accuracy by carefully designing the input provided to generative AI. By providing generative AI with instruction background and additional information, or giving detailed instructions regarding task execution, adjustments are made to generate expected responses. For detailed log analysis of threats detected by Amazon GuardDuty, response accuracy is improved by providing Amazon Q Developer with the following information through prompts. Item Description Example System configuration information necessary for log investigation - What logs are stored - Where they are stored, etc. CloudTrail logs are stored in Splunk Cloud. Explicitly instruct log investigation procedures - Tools to use for log analysis - What to investigate, etc. - Prioritize using Splunk MCP Server for log analysis. - Consider operations between 09:00 and 18:00 as normal and low risk. Specify output format (report content) - Specify report output format - Specify information to include in report - Create reports in Markdown format. - Create reports with the following chapter structure: (chapter structure listed below) Provide specific command execution samples Splunk search queries, etc. Execute the following command to verify authentication status. 'index=example userPrincipalName=" " | stats count by status.errorCode, status.failureReason | sort -count' Clearly state prohibitions - What operations should not be executed - What information should not be included in output - Do not calculate day of week from dates yourself. - Do not make associations based on speculation or assumptions. In prompt engineering, insufficient information provided to generative AI may not effectively adjust output content. Prompts were adjusted to the appropriate level of detail by specifying conditions and instructions using generative AI. Improvements and Results from Adjustments After implementing the above adjustments, the following report was generated when requesting log analysis from Amazon Q Developer again. The instructions input to the prompt were the same text as when requesting analysis from Amazon Q Developer in its default state. # GuardDuty Finding Detailed Analysis Report **Finding ID**: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx **Detection Region**: ap-northeast-1 **AWS Account ID**: 000000000000 **AWS Account Name**: (Unknown) **Analysis Date/Time**: 2025-10-16 17:44:14 ## 1. Executive Summary ### Key Findings - **Actual User Identification**: User Name (< User Email Address >) - **Outsourced User**: Identified as outsourced company user by "xxxx-" prefix - **False Positive Possibility**: High (possibility of normal work by legitimate user) - **CloudTrail Logs**: Target AWS account logs do not exist in Splunk, detailed authentication chain tracking unavailable ### Emergency Response Necessity Assessment - **Urgency**: Low - **Reason**: Activity by legitimate user during normal business hours, Entra ID authentication also normal ### Key Investigation Results Summary - Finding occurrence time: September 9, 2025 13:20:05 JST (Monday during normal business hours) - Operation content: GetObject API execution from S3 bucket "< S3-Bucket-Name >" - User: User Name from outsourced company - Abnormality: Anomaly detected by GuardDuty machine learning, but legitimate operation during business hours ### Recommended Actions (Prioritized) 1. **Priority: Low** - Confirm work content with relevant user (just in case) 2. **Priority: Low** - Verify S3 access logs in detail (if necessary) 3. **Priority: Medium** - Consider adjusting GuardDuty machine learning baseline ## 2. Threat Overview **Threat Type**: Exfiltration:S3/AnomalousBehavior **Severity**: 8.0 (High) **Detection Content**: Anomalous S3 API calls by IAM entity The "anomalous" S3 GetObject API call detected by GuardDuty indicates deviation from machine learning baseline, but is actually determined to be operation by legitimate user during normal business hours. ## 3. Threat Details ### Detailed Attack Method Analysis - **API**: S3 GetObject - **Target Bucket**: < S3-Bucket-Name > - **Authentication Method**: AuthHeader (legitimate AWS authentication) - **User Agent**: aws-sdk-rust/1.3.8 (development tool usage) ### Attacker Profiling Not an actual attacker, but operation by legitimate user "User Name": - User from outsourced company ("xxx-" prefix) - Uses AWS SSO for normal work - Track record of work in development environment (sandbox) ### Attack Timeline Analysis - **2025-09-09 13:20:05 JST**: S3 GetObject API execution - **2025-09-09 13:29:43 JST**: Detection by GuardDuty - **Same date/time**: Confirmed successful AWS SSO login in Entra ID ### Detailed Impact Scope Assessment - **Affected Resources**: S3 bucket "< S3-Bucket-Name >" - **Data Leakage Risk**: Low (sandbox bucket, legitimate user) - **Lateral Movement Risk**: None - **Persistent Threat**: None ### Comparison with Similar Attack Patterns Anomaly detection by GuardDuty machine learning, differs from actual attack patterns: - Use of legitimate authentication chain - Operation during normal business hours - Work in development environment ### Security Control Bypass Techniques No bypass techniques used, all through legitimate authentication/authorization processes: - SSO login via Identity Center - Operation with appropriate role permissions - Use of legitimate AWS SDK ## 4. Principal Information **User Name**: < Role Name > **Actual User**: User Name (< User Email Address >) **User Type**: AssumedRole (via Identity Center) **Access Key ID**: < Access Key ID > **Principal ID**: < Principle ID> ### Detailed User Attributes - **Name**: User Name - **Affiliation**: Outsourced company ("xxx-" prefix) - **Email Address**: < User Email address> - **Role**: < Role Name > ## 5. Abnormality Analysis ### Time-based Abnormality Assessment - **Finding Occurrence Date**: Monday (normal business day) - **Finding Occurrence Time**: 13:20:05 JST (normal business hours) - **Abnormality Level**: **Low** - Activity during normal business hours - **Risk Assessment**: Low risk ### Geographic Abnormality - **Access Source**: Japan (< ISP Name >) - **Expected Business Location**: Within Japan - **Abnormality**: None - Access from expected business location ### Operation Pattern Abnormality - **Tool Used**: aws-sdk-rust (development tool) - **Operation Content**: S3 GetObject (data retrieval) - **Target**: sandbox bucket (development environment) - **Abnormality**: Low - Normal operation in development work ### Authentication Chain Abnormality - **Entra ID Authentication**: Normal (error code 0) - **Identity Center**: Normal SSO session - **AWS Authentication**: Legitimate AssumedRole - **Abnormality**: None - All legitimate processes ### Entra ID Authentication Log Analysis Results #### Executed Splunk Queries and Results **1. Basic Information Retrieval**: index=< example > userPrincipalName="< User Email Address >" | table userDisplayName userPrincipalName **Result**: Confirmed user name "User Name" **2. 30-Day Behavior Pattern**: index=< example > userPrincipalName="< User Email Address >" earliest=-30d | stats count, values(location.city), values(deviceDetail.browser), values(appDisplayName) by userPrincipalName **Result**: - Total login count: 59 times - Access region: < Access Area > - Browser: Chrome 138.0.0 - Apps used: AWS SSO, Microsoft 365 Support Service, Microsoft Account Controls V2, Microsoft Teams Web Client **3. Time Pattern Analysis**: index=< example > userPrincipalName="< User Email Address >" earliest=-7d | eval weekday=strftime(_time, "%A"), hour=strftime(_time, "%H") | stats count by weekday, hour | sort weekday, hour **Result**: - Many accesses at 16:00 hour regardless of weekdays/holidays - Multiple accesses at midnight 0:00 hour confirmed (Friday, Thursday, Tuesday, Wednesday) - Access patterns outside normal business hours also exist **4. Authentication Status**: index=< example > userPrincipalName="< User Email Address >" | stats count by status.errorCode, status.failureReason | sort -count **Result**: - Successful logins: 28 times (error code 0) - Authentication failures: Not confirmed - Authentication success rate: 100% **5. Authentication Logs Around Finding Occurrence Time**: index=< example > userPrincipalName="< User Email Address >" (Around Finding occurrence time) **Result**: - Successful AWS SSO login from IPv6 address (< IPv6 Address >) - Access from within Japan - Authentication successful (error code 0) ### Identity Verification Results **Identity Confirmation through Behavior Analysis**: - **Match with Normal Patterns**: High degree of match - **Access Region**: Access from normal < Access Area > - **Applications Used**: Normal use of AWS SSO - **Authentication Success Rate**: 100% (no abnormal failures) - **User authenticity**: **High** - Matches normal behavior patterns ## 6. Risk Assessment ### Overall Risk Assessment: **Low** #### Rationale 1. **Operation by Legitimate User**: Operation by actual outsourced user 2. **Normal Business Hours**: Normal business hours on Monday at 13:20 3. **Legitimate Authentication Process**: Normal authentication chain via Identity Center 4. **Development Environment**: Development work in sandbox bucket 5. **Identity Verification**: Matches legitimate user's normal patterns in Entra ID logs #### False Positive Possibility **High** - GuardDuty's machine learning baseline may not have sufficiently learned this user's normal patterns #### Security Impact - **Data Leakage Risk**: Extremely low - **System Compromise Risk**: None - **Lateral Spread Risk**: None ## 7. Detailed Investigation ### CloudTrail Log Existence Confirmation Results **Detailed authentication chain tracking is difficult because CloudTrail logs for target AWS account (000000000000) do not exist in Splunk** Executed query: index=< example > sourcetype=aws:cloudtrail account=000000000000 | head 1 Result: 0 logs found ### Candidate User Investigation from Source IP Address **Candidate User Investigation by Geographic Proximity**: - Direct search with IP address from Finding details (< IP Address >): 0 results - Actual authentication logs use IPv6 address (< IPv6 Address >) - Both accesses from within Japan with geographic consistency ### Points Requiring Additional Investigation 1. **GuardDuty Baseline Adjustment**: Learning normal patterns for outsourced users 2. **S3 Access Logs**: Verify detailed logs at bucket level if necessary 3. **User Work Confirmation**: Confirm work content at relevant time (just in case) ### Unclear Points or Questions 1. Specific learning baseline that GuardDuty determined as "abnormal" 2. Access patterns of other users to same bucket 3. Business necessity for using aws-sdk-rust tool ## 8. Recommended Countermeasures ### Immediate Response (Priority: Low) 1. **User Confirmation**: Confirm work content with User Name (just in case) 2. **Continuous Monitoring**: Monitor for recurrence with similar patterns ### Short-term Response (Within 1 week) 1. **GuardDuty Adjustment**: Promote learning of normal patterns for outsourced users 2. **Access Pattern Analysis**: Establish normal access patterns for sandbox bucket ### Medium to Long-term Response (Within 1 month) 1. **Baseline Optimization**: Adjust GuardDuty machine learning baseline 2. **Monitoring Rule Review**: Establish monitoring rules for outsourced users 3. **Documentation**: Document normal development work patterns ### Reasons for Determining No Response Necessary - Legitimate operation by legitimate user during normal business hours - All authentication processes normal - Security risk extremely low - High possibility of false positive **Conclusion**: This Finding is determined to be a false positive, requiring no response as a security incident. Recommend adjusting GuardDuty baseline. Compared to requesting log analysis of threats detected by Amazon GuardDuty from Amazon Q Developer in its default state, the following improvements were observed. By adjusting Amazon Q Developer through MCP integration and prompt engineering, the information included in log analysis output and its content could be brought closer to expectations. By specifying report format to generate in prompts, necessary information was stably included in output content across multiple verifications. Risk assessment of detected threats could be performed using log data on Splunk Cloud, enabling analysis closer to actual practice. However, further improvements are needed in the following aspects: Through multiple verifications, reports containing inaccurate information were sometimes generated. Despite clear instructions in prompts, outputs ignoring instructions sometimes occurred. When AWS CloudTrail logs were not imported to Splunk Cloud, risk assessment was sometimes performed using only Entra ID logs without searching AWS CloudTrail logs directly using tools provided by CloudTrail MCP Server. Hallucinations cannot be completely eliminated, and continuous adjustment of Amazon Q Developer is necessary while continuing to verify output content and monitor executed operations. Conclusion While log analysis using Amazon Q Developer has many challenges in its default state, by performing MCP integration and prompt adjustments, responses that appear usable for actual log analysis could be generated. However, the generated content cannot be completely trusted, and continued adjustment and improvement regarding response accuracy and actually performed operations appear necessary. Additionally, since this verification focused on methods of utilizing Amazon Q Developer for log analysis, this article does not address other aspects. From the perspective of securely leveraging generative AI, there remain many challenges to be improved for practical operation, such as enforcing minimum privilege management for MCP servers and handling credential management. I will continue to explore utilization methods for Amazon Q Developer while working on improving and strengthening security operations.

ITオリエンテーションとその改善について はじめに KINTOテクノロジーズ（KTC）のコーポレートITでは、グループ会社のIT業務支援も行っています。 私は現在、グループ会社にてヘルプデスク業務の支援を担当しており、その中で新規入場者向けのITオリエンテーション（以下、オリエン）も実施しています。 その中で、PCとスマホの取り扱い方法や業務環境の説明や初回のパスワード変更をサポートしております。 他社のIT部門がどのようにオリエンを行っているかを知る機会は少ないと体感しているので、少しでも参考になればと思い記事にまとめました。 背景と課題 オリエンは月に1〜2回の頻度で実施されています。 これまでは、担当者の経験と知識に依存した運用で、資料はなく、簡単なメモ（いわゆる“あんちょこ”）のみが存在していました。 もともと1人でヘルプデスク業務を担っていたため、資料化の必要性がなかったという背景があります。 しかし、属人化から脱却し、組織として対応できる体制を目指すために私がジョインし、改善に取り組むことになりました。 （正直なところ、オリエンを担当した初日、「これはつらい…」と感じたのが一番のきっかけです（笑）） オリエンのゴール設定 業務においてPCがない環境というのは考えられないため、よりスムーズに業務に入っていただけるように 「会社PC・スマホを使える状態になっている」「自社のおおまかなPC環境を理解している」 状態になってもらう。をゴールとして設定しました。 改善についても、参加者がよりゴールに達成しやすくなるように行いました。 実施した改善 改善は主に以下の2点に取り組みました。 1. 資料化 これまでのメモをベースに、説明内容を体系的に整理し、資料として整備しました。 システムの説明や注意点を網羅し、説明漏れがないように構成しています。 また、略称が多く使われる環境のため、資料内で都度解説を加えるようにしました。 さらに、以下の工夫も取り入れています。 アイスブレイクの工夫 入場者は緊張していることが多く、理解力や質問のしやすさに影響します。 そこで、ヘルプデスクメンバーの自己紹介を資料に盛り込み、趣味や好きなことを「ゆるめ」に紹介することで、親しみやすさとリラックス感を演出しています。 支援先は堅めな会社なので、盛り込むのには勇気が必要でしたが、より効果的に行うにはこれが必要だ。という信念をもとに対応しました。 想いの表明 我々が「社内のサポートメンバーとして、ビジネスを止めないために活動している」ということを、熱量高めに伝えるようにしています。 「困ったら遠慮なく頼ってほしい」というメッセージは、問い合わせの増加による稼働超過。過度な依存につながる懸念もありますが、サポート部門としての存在価値は、頼られることにあると考えています。 良好な関係性が築けていないと、我々起因で仕組みを変えたりする際のヒアリングや、課題解決がスムーズに進みません。 また、親密感を持ってもらうことは、結果的に不要な問い合わせを減らしたり、トラブルの解決時間削減の効果もあると感じています。 講師もわかりやすい資料化 属人化脱却のためには、講師をやる難易度も下げる必要があります。 そのため、参加者にとってもわかりやすいだけでなく、講師にとってもわかりやすい資料にする必要があります。 その際に工夫したのは下記の2点です。 説明の流れを意識 オリエンの中で、PCのパスワード変更があるのですが、それをスムーズにするため、以下の順序で資料を整理しました。 業務スマホのロック解除して使える状態にする スマホの初期パスコード変更と生体認証設定 PCへのログイン（スマホを利用した多要素認証解除） PCパスワードの変更 この順番にすることで、必要となる操作が一本道となり、参加者も講師も迷いなく進められます。 1ページ1コンテンツ 1ページに詰め込みすぎず、「このページで何を説明するか」を明確にしました。 これも参加者は理解しやすく、講師も話す内容を把握しやすくなります。 2. 振り返りの仕組み オリエン終了後、なるべく早くチームで振り返り会を実施しています。 記憶が新しいうちに、KPTA（Keep・Problem・Try・Action）のフレームワークを使って小さなところでも改善点を洗い出し、次回に活かしています。 改善案（Action）はチームのタスク管理に組み込み、漏れがないようにしております。 この振り返りで改善をし続けています。 具体的には、下記のようなActionを実行しました。 順番を入れ替えることで重複の説明を排除した 参加者にも簡単な自己紹介をしてもらうことで、同期間のコミュニケーションを促進した オリエンテーションの内容 改善後のオリエンでは、以下のような内容を説明・実施しています。 時間としては、1時間をとってもらっております。 雑談や質問の時間もとっており、はじめての緊張を和らげつつ、自社の環境について知ってもらう時間としております。 メンバーの自己紹介 業務環境（VDI）の説明 初回ログインとパスワード変更 機器取り扱いの注意点 サポート窓口の案内 やってみて感じたこと 参加者からは「今までこんなに楽しい説明会はなかった」といった感想をいただくことが増えました。 特に、我々の自己紹介をきっかけに声をかけてもらえることが多くなり、関係性の構築にもつながっています。 また、特定のメンバーに依存せず、誰でもオリエンを担当できる体制が整い、組織としての対応力も向上しました。 さいごに オリエンの参加者は、緊張や不安を抱えていることが多いです。 業務に欠かせないPCやスマホも、会社ごとに環境が異なるため、初めてその会社の機器に触れた際に戸惑うところが多いのは当然だと思います。 KTCのようなITのプロ集団でも戸惑われる方がそれなりにいらっしゃるので、IT専業ではないグループ会社ではなおさらです。 また、活躍を期待されて入場しているので「うまくできない自分を見せるわけにはいかない」という心理はとても強く働き、質問や相談がしづらくなります。 だからこそ、 「誰でも最初はうまくできない」「ITのプロである私も失敗した」 ということを積極的に伝え、安心して頼ってもらえる雰囲気づくりを心がけています。 ITオリエンテーションは様々な立場の方に実施するため、我々の存在を認知してもらい、頼ってもらえる関係性を築いていくための第一歩になるものだと思います。 こういうところから、組織でのIT活用の促進、ひいては事業の加速にまでつながっていると信じています。

Introduction Hello! I'm Rasel , and today I want to share something that most Android developers overlook - the inlineContent property of Jetpack Compose's Text composable. Recently, while working on the my route app at KINTO Technologies Corporation, we encountered a UI challenge that seemed simple but turned out to be quite complex: displaying colored benefit labels inline with ticket names in our ticket usage history screen.  The tickets shown are samples. Please check the app for tickets that are actually on sale. As you can see in the design, we needed a pink labeled text with rounded corners that flows naturally with the ticket name text. Most developers would reach for Row or FlowRow to solve this, but these approaches have significant limitations when dealing with text that needs to wrap and flow naturally. The Problem: When Row and FlowRow Fall Short Consider this UI pattern from our actual design: [With coupon] One-day Pass for all Kagoshima City buses, trams and ferry routes. Where [With coupon] is a pink label with rounded corners that must appear seamlessly inline with the text. Approach 1: Using Row (The Naive Solution) @Composable fun TicketNameWithRow(name: String, benefitLabel: String) { Row( horizontalArrangement = Arrangement.spacedBy(4.dp), verticalAlignment = Alignment.CenterVertically, ) { Box( modifier = Modifier .background( color = MaterialTheme.colors.subPink, // Design system color shape = RoundedCornerShape(2.dp), ) .padding(horizontal = 4.dp), contentAlignment = Alignment.Center, ) { Text( text = benefitLabel, style = MaterialTheme.typography.body3Bold, color = MaterialTheme.colors.onPrimaryHighEmphasis, ) } Text( text = name, style = MaterialTheme.typography.body2Bold, ) } } Result:  Problems with Row: Label doesn't align perfectly with text baseline Inconsistent spacing when text wraps Breaks the natural text flow Approach 2: Using FlowRow (Better, But Still Limited) @Composable fun TicketNameWithFlowRow(name: String, benefitLabel: String) { FlowRow( horizontalArrangement = Arrangement.spacedBy(4.dp), verticalAlignment = Alignment.CenterVertically, ) { Box( modifier = Modifier .background( color = MaterialTheme.colors.subPink, shape = RoundedCornerShape(2.dp), ) .padding(horizontal = 4.dp), contentAlignment = Alignment.Center, ) { Text( text = benefitLabel, style = MaterialTheme.typography.body3Bold, color = MaterialTheme.colors.onPrimaryHighEmphasis, ) } Text( text = name, style = MaterialTheme.typography.body2Bold, ) } } Result:  As shown above, the UI still doesn't align perfectly with our design. The label and text do not flow naturally when wrapping. Another Approach: Using AnnotatedString (SpanStyle) Before Jetpack Compose supported true inline composables, many developers tried to achieve similar effects using only AnnotatedString and SpanStyle . This approach uses background color and rounded corners via SpanStyle to style part of the text as a label. Approach 3: AnnotatedString with SpanStyle This method is limited compared to inlineContent , but can be useful for simple cases where you only need background color and text styling (not custom composables or padding). @Composable fun TicketNameWithAnnotatedString(name: String, benefitLabel: String) { val cornerRadius = with(LocalDensity.current) { 2.dp.toPx() } val drawStyle = Stroke(pathEffect = PathEffect.cornerPathEffect(cornerRadius)) val nameStyle = MaterialTheme.typography.body2Bold.toSpanStyle() val benefitStyle = MaterialTheme.typography.body3Bold.copy( color = MaterialTheme.colors.onPrimaryHighEmphasis, background = MaterialTheme.colors.subPink, drawStyle = drawStyle, ).toSpanStyle() val annotatedString = remember(name, benefitLabel) { buildAnnotatedString { withStyle(style = benefitStyle) { append(" $benefitLabel ") // Add spaces for padding effect } append(" ") withStyle(style = nameStyle) { append(name) } } } Text(text = annotatedString) } Result:  Limitations: Rounded corners are not achieved properly while using proper value from design (background is mostly a rectangle, and needs to adjust value to make it rounded, still proper rounding is not achieved) No custom composable or icon support Padding is simulated with spaces, not true padding Baseline alignment is good, but label may not look as polished as with inlineContent Text styling also gets changed from design When to use: When you only need a colored background and simple text styling When you want a dependency-free, simple solution for basic badges The Solution: InlineContent - The Proper Way InlineContent allows you to embed custom composable directly within text, treating them as characters in the text flow. Here's how we implemented it in the my route app: Step 1: Understanding the Production Implementation Below is a simplified version of our production code, showing how to use inlineContent to embed a custom label inside text: @Composable private fun TicketNameWithBenefit( name: String, benefitLabel: String, ) { val nameStyle = MaterialTheme.typography.body2Bold.toSpanStyle() val annotatedString = remember(name, benefitLabel) { buildAnnotatedString { appendInlineContent(benefitLabel) // Use label text as unique key append(" ") withStyle(style = nameStyle) { append(name) } } } // ... (inline content implementation) Text( text = annotatedString, inlineContent = inlineContent, ) } Step 2: Dynamic Width Calculation (The Critical Part) Calculating the exact width for the label background is essential for a seamless look. Here is how we do it: The most challenging aspect is calculating the exact width needed for the label background: val density = LocalDensity.current val textMeasurer = rememberTextMeasurer() val horizontalPadding = 4.dp val benefitLabelBgWidthSp = remember(benefitLabel) { val textLayoutMeasure = textMeasurer.measure( text = benefitLabel, style = benefitStyle, ) with(density) { (textLayoutMeasure.size.width.toDp() + (horizontalPadding * 2)).toSp() } } Why this is complex: Text Measurement : We need to measure the text before rendering Unit Conversion : Convert between pixels, dp, and sp correctly Padding Calculation : Include padding in the total width Density Awareness : Handle different screen densities Step 3: Creating the Inline Content Mapping Now, we map the label to a composable using InlineTextContent , ensuring it aligns and sizes perfectly: val inlineContent = remember(benefitLabel, benefitLabelBgWidthSp) { mapOf( benefitLabel to InlineTextContent( placeholder = Placeholder( width = benefitLabelBgWidthSp, height = benefitStyle.lineHeight, placeholderVerticalAlign = PlaceholderVerticalAlign.Center, ), ) { Box( modifier = Modifier .background( color = MaterialTheme.colors.subPink, shape = RoundedCornerShape(2.dp) ) .padding(horizontal = horizontalPadding), contentAlignment = Alignment.Center, ) { Text( text = benefitLabel, style = benefitStyle, color = MaterialTheme.colors.onPrimaryHighEmphasis, ) } } ) } Key implementation details: placeholderVerticalAlign = PlaceholderVerticalAlign.Center ensures perfect alignment height = benefitStyle.lineHeight matches the text height exactly Dynamic width calculation ensures perfect fit for any label text The Complete Production Implementation Here's our actual implementation from the my route app: @Composable private fun TicketNameWithBenefit( name: String, benefitLabel: String, ) { val nameStyle = MaterialTheme.typography.body2Bold.toSpanStyle() val benefitStyle = MaterialTheme.typography.body3Bold val annotatedString = remember(name, benefitLabel) { buildAnnotatedString { appendInlineContent(benefitLabel) append(" ") withStyle(style = nameStyle) { append(name) } } } val density = LocalDensity.current val textMeasurer = rememberTextMeasurer() val horizontalPadding = 4.dp val benefitLabelBgWidthSp = remember(benefitLabel) { val textLayoutMeasure = textMeasurer.measure(text = benefitLabel, style = benefitStyle) with(density) { (textLayoutMeasure.size.width.toDp() + (horizontalPadding * 2)).toSp() } } val inlineContent = remember(benefitLabel, benefitLabelBgWidthSp) { mapOf( benefitLabel to InlineTextContent( placeholder = Placeholder( width = benefitLabelBgWidthSp, height = benefitStyle.lineHeight, placeholderVerticalAlign = PlaceholderVerticalAlign.Center, ), ) { Box( modifier = Modifier .background( color = MaterialTheme.colors.subPink, shape = RoundedCornerShape(2.dp), ) .padding(horizontal = horizontalPadding), contentAlignment = Alignment.Center, ) { Text( text = benefitLabel, style = benefitStyle, color = MaterialTheme.colors.onPrimaryHighEmphasis, ) } }, ) } Text( text = annotatedString, inlineContent = inlineContent, ) } Result:  As you can see, this implementation perfectly aligns with our design goal. Why We Switched from External Library When we couldn't achieve our design using Row, FlowRow and even AnnotatedString approach, we tried using an third party library: val extendedSpans = remember { ExtendedSpans( RoundedCornerSpanPainter(…), ) } Text( modifier = Modifier.drawBehind(extendedSpans), text = remember(text) { extendedSpans.extend(text) }, onTextLayout = { result -> extendedSpans.onTextLayout(result) } ) By using a third-party library, we finally achieved our design goal. But we don't want to ship another library with our app just for this single Text UI item and reconsidered other approaches. Problems we encountered: Additional dependency for a simple feature Less control over styling and behavior Potential compatibility issues with future Compose versions The native solution proved to be better: No external dependencies Full control over styling and behavior Better performance Future-proof with Compose updates Advantages of InlineContent Approach Natural Text Flow : Labels wrap with text naturally, maintaining proper line breaks Perfect Alignment : Consistent baseline alignment with surrounding text Flexible Styling : Full support for complex text formatting (bold, colors, sizes) Dynamic Sizing : Adapts to content automatically while maintaining design consistency Performance : Efficient rendering as part of the text layout engine Accessibility : Screen readers handle it as part of the text flow Common Pitfalls and Solutions Pitfall 1: Hardcoded Dimensions ❌ Wrong: Placeholder(width = 60.sp, height = 16.sp) // Fixed dimensions ✅ Correct: Placeholder( width = calculatedWidth, // Dynamic based on content height = textStyle.lineHeight, // Match text height ) Pitfall 2: Incorrect Unit Conversion ❌ Wrong: textLayout.size.width.toSp() // Direct conversion loses density information ✅ Correct: with(density) { textLayout.size.width.toDp().toSp() // Proper density-aware conversion } Pitfall 3: Missing Performance Optimization ❌ Wrong: // Recalculated on every composition val inlineContent = mapOf(...) val annotatedString = buildAnnotatedString { ... } ✅ Correct: val inlineContent = remember(dependencies) { mapOf(...) } val annotatedString = remember(dependencies) { buildAnnotatedString { ... } } Use Cases Beyond Benefit Labels This technique works excellently for: Status badges in lists Rating stars within reviews Currency symbols with special styling Icon indicators in text Highlighted keywords in search results Performance Considerations The remember usage is crucial for performance: // Expensive operations cached properly val benefitLabelBgWidthSp = remember(benefitLabel) { /* text measurement */ } val inlineContent = remember(benefitLabel, width) { /* composable creation */ } val annotatedString = remember(name, benefitLabel) { /* string building */ } This ensures calculations only happen when dependencies change, not on every composition. Conclusion InlineContent is a powerful but underutilized feature of Jetpack Compose. When you need to embed custom UI within text flow, it's the superior solution compared to layout-based approaches like Row or FlowRow . The dynamic width calculation technique we've implemented solves the common problem of perfectly fitting background elements to text content. While the implementation requires understanding text measurement and unit conversion, the result is a professional, performant UI that scales well across different devices and text sizes. Our experience transitioning from an external library to this native solution proved that sometimes the built-in tools, when used correctly, provide the best balance of performance, maintainability, and design flexibility. Next time you encounter inline UI challenges, remember: inlineContent is your friend! Key Takeaways: Use InlineContent for true inline UI elements that need to flow with text Implement dynamic width calculation using TextMeasurer for perfect fitting Optimize with remember for performance, especially text measurements Prefer native solutions over external libraries when built-in APIs suffice Pay attention to unit conversion and density handling Happy coding!

はじめに QAグループのWebチームのroです。 実際のQA案件業務においては、中古車のテストデータを大量に生成する必要がありますが、その手順は複雑で注意点も多く、作業には多くの時間を要していました。 この課題を解決するため、Playwrightを活用し、中古車データ生成の全工程を自動化しようと思っています。 この取り組みを社内の「Vibe Coding」イベントにおいて実施し、Vibe Codingの手法を用いて中古車データ自動生成用のPythonスクリプトを実装しました。 Vibe Codingとは？ Vibe Codingとは、生成AIと人間のエンジニアが協働して行う新しい開発スタイルです。 AIが「コード生成」や「調査」といった重い作業を引き受け、人間は「品質の検証・改善」に集中することで、高品質かつ効率的な開発を行えます。 Vibe Codingは、以下３つの特徴があります： 自由度が高い：テーマやルールが緩く、各自好きな技術や課題に取り組める 交流の場：普段関わらないメンバーとも一緒に作業でき、知識やスキル共有のきっかけになる モチベーション向上：一人でやるよりも集中しやすく、楽しみながら成果を出せる 中古車データ自動作成のスクリプトの流れ 中古車データ自動作成のスクリプトのシステム構成図 スクリプト実装中に頑張ったこと 実際に中古車データ自動作成用のスクリプトを実装中、いくつかの課題に直面しましたが、試行錯誤と視点の転換を重ねることで、最終的に問題を解決することができました。 1. S3バケットに中古車契約の情報ファイルをアップロードする S3バケットに中古車契約の情報ファイルをアップロードする手順があります。これまで、この手順は中古車チームに依頼して操作してもらっていました。今回は、この手順も自動化するために、事前に中古車チームとクラウドチームに相談し、S3へのアクセス権限を付与していただきました。S3の接続権限を得たことで、Pythonを用いてS3へのファイル自動アップロードを実現できるようになりました。 コードの例： # SSOでログイン済みのプロファイルを指定 session = boto3.Session(profile_name="your_profile_name") # S3クライアント作成 s3 = session.client("s3") # アップロード先情報 bucket_name = "your-bucket-name" local_file_path = r"path/to/your/local/file.txt" s3_object_key = "path/to/s3/object.txt" try: s3.upload_file(local_file_path, bucket_name, s3_object_key) print(f"{local_file_path} を S3バケット '{bucket_name}' の '{s3_object_key}' にアップロードしました。") except Exception as e: print(f"アップロードに失敗しました: {e}") 2. 輸送依頼のExcelファイルの自動生成 本来は、サイトから輸送依頼用のExcelファイルをダウンロードし、その中から不要な内容を削除したうえで、中古車契約の情報を再入力し、再度サイトへアップロードする必要がありました。しかし、この煩雑な手順は時間がかかるうえ、ミスが発生しやすいという課題がありました。今回、Pythonを活用することで、不要な内容を自動削除し、必要な情報を抽出してExcelへ自動記入し、最後にサイトへ自動アップロードすることが可能になりました。これまで手作業で行っていた面倒な作業から解放できました！ コードの例： # 元のCSVファイルパス folder = r"C:\Users\×××\Downloads" pattern = os.path.join(folder, "req_000550_4*.csv") files = glob.glob(pattern) # 正規表現で「req_000550_」＋19桁の英数字に一致するファイルを抽出 regex = re.compile(r"req_000550_[0-9A-Za-z]+\.csv$") target_files = [f for f in files if regex.search(os.path.basename(f))] input_file = target_files[0] #print(f"対象ファイル: {input_file}") # ===== CSV読み込み ===== df = pd.read_csv(input_file, header=None) # ===== セル更新 ===== df.iloc[1, 1] = display_text1 # B2 df.iloc[1, 2] = display_text3_formatted # C2 df.iloc[1, 3] = display_text2 # D2 # G2, H2, I2, J2 → 列番号は G=6, H=7, I=8, J=9（0始まり） today_str = datetime.now().strftime("%Y%m%d") for col in [6, 7, 8, 9]: df.iloc[1, col] = today_str # ===== 保存ファイル名作成 ===== safe_display_text3 = display_text3.replace(":", "-").replace(" ", "_") new_filename = f"req_000550_{safe_display_text3}.csv" output_file = os.path.join(folder, new_filename) # ===== CSV保存 ===== df.to_csv(output_file, index=False, header=False, encoding="utf-8-sig") print(f"更新完了: {output_file}") await page.get_by_role("button", name="輸送状況を登録する").click() new_filename = f"req_000550_{safe_display_text3}.csv" filePath = rf"C:/Users/×××/Downloads/{new_filename}" route = os.path.abspath(filePath) async with page.expect_file_chooser() as fc_info: await page.get_by_role("button", name="受付状況更新ファイル(CSV形式 UTF-8/CRLF/BOMあり) prepended action").click() file_chooser = await fc_info.value await file_chooser.set_files(route) await page.get_by_role("button", name="アップロードする").click() await page.get_by_role("button", name="OK").click() 3. 各システム間におけるデータ反映時間の把握 １つの中古車データに対して、あるシステム上での操作が完了した後、一定の時間を待たなければ、他のシステムで次の操作を行うことができません。この待機時間の管理は容易ではありませんが、自動化スクリプトを活用することで、正確に待機時間を把握し、時間になれば自動的に次の操作へ進めることが可能になりました。これにより、業務効率が大幅に向上しました。 感想 今回の成果物は、今後の案件業務に活用できそうです。 従来200台の中古車データの作成に約2ヶ月かかっていたが、自動化により工数を削減することを期待できそうです。 成果 今回は、中古車データ生成の自動化を実現しただけでなく、今後につながる有益な経験と発想を得ることができました。 この経験を活かし、今後のQA業務においても、自動化できる業務をさらに発掘し、段階的に実現していきたいと考えています。 おわりに 今回のVibe Coding Weekでは、中古車データの自動作成のチャレンジを実施し、短期間で成果を得ることができました。 今後も自動化、AIに力を入れて、データ自動作成だけではなく、テスト設計、テスト実施も自動化にしていきたいと思います。

はじめに こんにちは！KINTOテクノロジーズQAグループで主にWebフロントエンド案件を担当しているoshimaです。 弊社は全社を挙げてAI利用を推進していますが、その波に乗って先月生成AIコーディング企画”Vibe Coding Week”が行われました。この企画で私がチャレンジした内容についてご紹介いたします。 Vibe Coding Week企画そのものの説明は他の記事をご参照いただければと思います。 背景 私自身、通常業務でコーディングをほとんど行うことはありません。一方、私の担当する案件については一つ一つのリリースサイクルが速いことと、同じ期間に複数の案件が重複することで、効率の良いテストが求められていました。 となればテスト自動化が一つのカギになります。実際グループではPlaywrightを用いての自動化が推進されてきました。が、私自身は残念ながら「コードの書けない人」です。これまでは出来る同僚に依頼するなどの方法でしのいできましたが、いつまでも当てにし続けられない（なかなか手が空かない）という状態が続いていました。 救世主！？ 自動化出来れば効率アップできそうな案件関連のネタは持っている。ただ、自身のスキルではどうしようもなかった。そんなもどかしい状態を打ち砕いてくれたのが生成AIです。 やりたいテスト（条件と期待値、制約条件など）がはっきりしていて、AIに正しく伝えることができれば、お望みのコードを生成してくれる。これならコーディングできない自分でも自動化に対して立ち向かっていける。業務の効率化のみならず、今まで自分が越えられなかった壁を越えてくれる（かもしれない）、救世主のような存在がAIでした。 チャレンジ企画との親和性 日本語のプロンプトでPlaywrightによる自動テストコードを生成していこうという取り組みは、先述のVibe Coding Week企画関係なく自然発生的なものでした。なので、企画発表があった時点で、企画意図に沿った内容の報告ができるのではないか？という感触を持っていました。 適用案件の特徴 通常業務での効率化の対象とした案件、そしてチャレンジ企画で取り組んだ案件が、社内では「静的資材」案件と呼ばれているものです。主にはKINTO ONEのサービスで取り扱う車種の仕様をお客様に紹介するためのページや契約内容の案内ページなどの確認を行う案件です。 例： トヨタ ヤリスの紹介ページ 特徴 車種紹介のページになると、KINTOで取り扱う車種が増えるごとに案件が成立しますが、ページレイアウトや項目は全車種共通。異なるのは画像と価格などのため、確認する内容は車種が変われども同じという案件の特徴がありました。 通常のテストでの作業内容 通常のテストで実施していた内容は以下となります。 全体デザインがFigmaで作成されたデザインと比較して差異がなく、またレイアウトの崩れがないこと 表示されている価格・サイズ・燃費などの各種データが指定ファイルと同じであること 画面内のボタンやリンクの遷移先が仕様通りであること これらの確認を今までは目視確認で行ってきました。原始的なやり方ですが、ある程度不具合指摘もできていたのですが、数が重なってくるとこれでは厳しくなってきます。上記の確認3項目については、うまくやれば自動で済みそうな内容です。 幸い試験時にはFigmaでの画面デザイン、価格表や燃費・サイズの記載された諸元表の指定ファイルは提示されます。材料はあります。なので、テスト対象ページの記載内容と自動で比較は特に問題なくできるのではないかという仮説を立て、チャレンジしてみました。 チャレンジ企画での取り組み 全体デザインの自動比較 デザインの比較については、次の手順で取り組みました。 テスト対象の該当Figmaページからコンポーネント情報を抽出してJSONに出力を試みる 全部だと情報量が多く読み込みに失敗 抽出する情報を位置情報に絞って相対位置比較でレイアウト崩れ確認に移行 レイヤーやID情報などが複雑で、ほしい情報を整理するのに苦労 実画面情報との解像度の差もあって、単純な比較でエラー頻発 残念ながらこのチャレンジ期間ではデザイン周りはうまくいきませんでした。 価格などの表示情報の自動比較 こちらについては、次の手順で取り組みました テストページの表示情報を抽出してJSONに出力を試みる 通常テキストは余裕でしたが表形式は項目名指定で工夫が必要でした 元データ（Excel）から情報抽出して同様にJSON出力 比較をしたいので「基本性能・主要装備」と「プラン別ご利用料イメージ」部分を抽出 結果的にうまくいきましたが、実はいろいろ試行錯誤し、結局はセル番号指定でのベタな指令に落ち着きました。 作成された2つのJSONを比較 ここまでくると問題なく実行完了 テキスト情報は比較的スムーズにうまくいきました。 リンク遷移先の確認 こちらは全部終わらなかったのですが、時間かければできそうな実感がありました。 ボタンに設定されたリンク先の取得は問題なし 目視の方が速そうなので比較の自動化までは実施せず チャレンジ企画の成果 ポイントは、単純に情報抽出してくださいではなく、テストコードをタイプスクリプト形式で実装し、Playwrightで実行したことです。このコードを生成しておくことで、他の車種や元データファイルが変わっても少しの改変で対応できるようになりました。 今まで目視確認で行っていたテスト内容を一部でも自動化出来たことは一つの成果ですが、できていない箇所や、より効率的にテストが進められる改善の余地は、残念ながらまだまだ多いです。 とはいえ、チャレンジ企画の短期間である程度できたことも確かです。地道に継続することで、出来てない部分を埋めていけると思います。 未来への妄想 -まとめにかえて- 自動化でできることはとことん自動化ツールでの確認に任せて、人間でしか確認できない箇所を追求する。効率化で時間的な余裕を生み、結果として人力でのテストの質の向上まで図ることができれば理想的です。 現段階ではまだまだ妄想です。ただ、コーディングできない人間でもある程度の自動化ができる時代になった今、妄想の実現は決して遠くない未来にあるのではという期待感も持っています。 チャレンジ企画で対応した案件以外での取り組みも含め、少しずつでも歩みを進めていこうと思います。

こんにちは、KINTOテクノロジーズ大阪拠点「Osaka Tech Lab」所属の中村です。 KINTOテクノロジーズは、トヨタグループの内製開発部隊として、車のサブスクリプションサービス「KINTO」をはじめとしたさまざまなモビリティサービスを開発を行っています。 私たちの拠点は2025年6月に梅田のノースゲートビルディングへ移転し、現在は月に一度のペースで社外向けの勉強会「CO-LAB Tech Night」を開催しています。1つのテーマを設定し、開発・デザイン・データなど、職種の垣根を越えたメンバーが日々の取り組みや気づきを共有し合う勉強会となっています。 今回は、これまでの歩みと、次回Vol.4「生成AI × クリエイティブ」についてご紹介します。 CO-LAB Tech Nightの成り立ち もともと、Osaka Tech Labには、 社外の勉強会やイベントで登壇経験のあるメンバーが何人かいました。ただ、以前のオフィスは手狭で、社内でイベントを開けるようなスペースがありませんでした。「大阪から発信する場をつくりたいね」という話は出ていたものの、なかなか形にできずにいました。 2025年6月末の移転をきっかけに、念願のイベントスペースが整い、 自分たちでもコミュニティを育てていけるようになりました。 関西では、 LINEヤフー株式会社様 をはじめ、 さくらインターネット株式会社様 、 株式会社マネーフォワード様 、 Sansan株式会社様 など、さまざまな企業がコミュニティ活動を展開しています。 そうした盛り上がりを肌で感じながら、私たちももっと関西の企業やコミュニティの方々とコラボレーションして、大阪からIT業界を盛り上げていきたい。 そんな思いから始まったのが「CO-LAB Tech Night」です。 Vol.1〜3の歩み Vol.1｜クラウド開発のリアルを共有 初回はクラウド開発をテーマに、Osaka Tech Labメンバーが登壇。アーキテクチャ設計やIaC化の試行錯誤を中心に、内製開発の現場感をそのまま伝えました。 Vol.2｜クラウド活用に役立つセキュリティ実践例 2回目はクラウドセキュリティを軸に、AWSやAzureなど各チームの知見を共有。「攻めと守りをどう両立するか」という実務的な問いを中心に議論しました。 Vol.3｜QAエンジニアの役割を再考する 3回目はQA（品質保証）をテーマに開催。生成AI時代を迎えた自動化・テスト設計など、常識が変わりつつあるテストの在り方を中心に語り合いました。 見えてきた課題とこれから CO-LAB Tech Nightを続ける中で、関西ではまだKINTOテクノロジーズのことがあまり知られていないと実感することが多くあります。「KINTOテクノロジーズって大阪にもあるんですね」とお声がけいただくことも多く、Osaka Tech Labの認知は、まだまだこれからだと感じています。 現状では、登壇者や運営メンバーの呼びかけで参加者が集まることが多く、どうしても社員個人のつながりや発信力に支えられている部分が大きいのが実情です。一方で、CO-LAB Tech Nightやその他のイベントへの出展などを通じて「大阪にもこういう会社があるんだ」と知っていただく機会は確実に増えてきました。 もともと他拠点に比べても交流が多く、メンバー間の距離も近い環境ですが、改めて「こういう視点で仕事をしていたんだ」と気づく場面が増え、お互いの理解をより深めるきっかけにもなっています。 メンバーの想いや行動をきっかけに始まったこの活動を、組織としての発信やコラボレーションの仕組みとして根付かせていきたい。そして関西の企業や、関西で働く方々とともに、大阪からIT業界を盛り上げていきたいと考えています。 次回:生成AI × クリエイティブの可能性と現在地 次回のVol.4は、デザイナーによるTikTokエフェクト制作、イラストワークフロー、画像生成比較、AIを使ったキャラクター表現など、実際にトヨタグループの内製開発で活用している事例を紹介します。 📅 2025年10月24日（金）19:00〜21:30 📍 KINTO テクノロジーズ Osaka Tech Lab (大阪駅直結・ノースゲートビルディング) ▼申込・詳細はこちらのconnpassページをご確認ください。 https://kinto-technologies.connpass.com/event/369528/ https://www.youtube.com/watch?v=v1fFP5VZEF0 おわりに CO-LAB Tech Nightは、「話してみたい」「聞いてみたい」という声から企画が生まれた、Osaka Tech Labのカジュアルな勉強会シリーズです。社内外の人がつながり、学び合う場として続けていくことで、大阪発のITコミュニティとして、ゆるやかに広がっていけたらと思います。 関西で活動するエンジニア、デザイナー、PdMのみなさん、ぜひ気軽に遊びにきてください！ ▼ KINTO テクノロジーズ Osaka Tech Labのコンセプトや働く人の様子 https://www.kinto-technologies.com/company/osakatechlab/ ▼ Osaka Tech Labでは、エンジニア・デザイナー・PdMなど複数職種で仲間を募集中です！ https://www.wantedly.com/projects/2069536

Hello, I'm Nakamura from KINTO Technologies' Osaka Tech Lab. KINTO Technologies is Toyota Group's in-house development team, creating various mobility services including the car subscription service "KINTO." Our office relocated to North Gate Building in Umeda in June 2025, and we now host a monthly external study session called CO-LAB Tech Night. We set a theme for each session where members from various roles including development, design, data and more, share their daily efforts and insights across professional boundaries. In this article, I'll introduce our journey so far and our upcoming Vol.4 session: Generative AI × Creativity. The Origins of CO-LAB Tech Night Osaka Tech Lab has always had several members with experience presenting at external study sessions and events. However, our previous office was small, and we simply didn't have the space to accommodate events. While we talked about creating a platform to share from Osaka, we couldn't quite make it happen. The relocation at the end of June 2025 finally gave us the event space we'd been hoping for, enabling us to nurture our own community. In Kansai, companies like LY Corporation , SAKURA internet Inc. , Money Forward, Inc. , and Sansan, Inc. are actively building communities. Experiencing this vibrant ecosystem firsthand, we wanted to collaborate more with companies and communities in Kansai and energize the IT industry from Osaka. That's how CO-LAB Tech Night was born. Journey Through Vol.1–3 Vol.1 | Sharing the Reality of Cloud Development Our first session focused on cloud development, with Osaka Tech Lab members presenting. We shared the real-world challenges of architecture design and IaC implementation from our in-house development perspective. Vol.2 | Practical Security Examples for Cloud Utilization The second session centered on cloud security, sharing insights from teams using AWS, Azure, and other platforms. We discussed the practical question of how to balance innovation and security. Vol.3 | Reconsidering the Role of QA Engineers Our third session explored QA (Quality Assurance). We discussed evolving testing practices in the generative AI era, including automation and test design as conventional wisdom shifts. Challenges and the Road Ahead Through continuing CO-LAB Tech Night, we've realized that KINTO Technologies isn't wildely recognized in Kansai. We often hear, "Oh, KINTO Technologies has an Osaka office?" indicating that Osaka Tech Lab's recognition is still developing. Currently, participants often join through connections with speakers or organizers, meaning our reach still heavily depends on individual employees' networks and influence. However, through CO-LAB Tech Night and participation in other events, we're steadily increasing opportunities for people to learn about our company's presence in Osaka. While we've always had strong cross-team collaboration and close relationships compared to other offices, these sessions have created new moments of realization, like "I didn't know you approached work from that perspective," deepening our mutual understanding. We want to transform this activity, which began with members' passion and initiative, into an organizational mechanism for outreach and collaboration. And together with companies and professionals working in Kansai, we want to energize the IT industry from Osaka. Next: The Potential and Current State of Generative AI × Creative Vol.4 will showcase real-world examples from Toyota Group's in-house development, including TikTok effect creation by designers, illustration workflows, image generation comparisons, and AI-powered character expression. 📅 October 24, 2025 (Fri) 19:00–21:30 📍 KINTO Technologies Osaka Tech Lab (directly connected to Osaka Station, North Gate Building) ▼ For registration and details, please check our Connpass page: https://kinto-technologies.connpass.com/event/369528/ https://www.youtube.com/watch?v=v1fFP5VZEF0 Closing CO-LAB Tech Night is a casual study session series born from the desire to talk and listen. We hope it will organically grow as an Osaka-based IT community where people inside and outside the company connect and learn together. Engineers, designers, and PdMs active in Kansai, please feel free to drop by! ▼ Learn about KINTO Technologies Osaka Tech Lab's concept and people: https://dev-www.kinto-technologies.com/company/osakatechlab/ ▼ Osaka Tech Lab is hiring engineers, designers, PdMs, and other roles! https://www.wantedly.com/projects/2069536

はじめに QAグループのMobileチームのokapiです。 「1週間、生成AIを使ってどこまで開発生産性を上げられるか？」そんなチャレンジ精神に火がついた社内イベント「Vibe Coding Week（バイブコーディングウィーク）」に、QAグループも参戦しましたので、執筆させていただきます。 なお、この記事のカバー画像もAIで作成してみました。 Vibe Codingとは？ Vibe Codingとは、生成AIと人間のエンジニアが協働して行う新しい開発スタイルです。 AIが「コード生成」や「調査」といった重い作業を引き受け、人間は「品質の検証・改善」に集中することで、高品質かつ効率的な開発を行えます。 「AIの力を最大限に引き出しながら、人間にしかできない価値を提供する」——それがVibe Coding Weekです。この1週間で、AI活用の限界と可能性を体験し、チーム内のAI活用に対する理解を深めます。 QAは何をやるのか？ 「開発生産性って、QAに関係あるの？」そう思われた方もいるかもしれません。 QAグループでは日々、「自動化・業務改善・AI活用」に積極的に取り組んでいます。 日々の業務で培ったノウハウを武器に、このVibe Coding Weekに挑戦することになりました。 私はQAグループの代表として参戦。 イベント開始の1ヶ月前から週次ミーティングを重ね、「どうすれば成果を出せるのか？」を徹底的に議論しました。 その結果、QA業務を楽にする「3つの自動化チャレンジ」を実施することに決定しました！ 取り組んだ3つの自動化チャレンジ 中古車データ作成の自動化と、画面仕様と実画面比較の自動化については、担当メンバーが詳細記事を執筆予定です。ぜひ公開を楽しみにお待ちください。 チャレンジ 概要 効果 1. Appiumライブラリのメジャーバージョンアップ QA Mobileチームのテスト自動化で利用しているAppiumのライブラリを、メジャーバージョン2つ分（java-client: 7.6.0 → 9.0.0）にアップデート。AIを活用してリリースノート調査、修正タスク化、実装を高速化し、互換性のある周辺ライブラリも同時更新。 メンテナンス性の向上。今後自動化予定のAppiumで行う画面比較に対応したaShotライブラリ（ピクセルパーフェクト比較）が使用可能に！ https://github.com/pazone/ashot 2. 中古車データ作成の自動化 QA Webチームのテストで必要な中古車のデータ作成をPlaywrightで自動化 従来200台作成に約2ヶ月かかっていたが、自動化により工数を削減。これまで手作業で行っていた面倒な作業から解放！ 3. 画面仕様と実画面比較の自動化 QA Webチームのテストで手動で行っていたExcel仕様書と実画面の比較をVS Codeで自動化。仕様書から文字抽出→差分判定→差分箇所表示を自動化 テスト実施の確認時間を削減。目視で探していた差分が一瞬でわかるように！ 各メンバーの感想 メンバー 感想 大島さん これまで地道に取り組んできたことを発表でき、さらに実案件への展開の可能性も見えてきたと感じました。通常業務の中でAIを活用できたのも良かったです。 呂さん 今回の成果物は、今後の案件業務に活用できそうです。 小林さん ClaudeCode、Copilot、Devinをそれぞれ使ってみて、性能の違いをある程度把握できました。どれを使う場合でも、調査や実装のスピードが人力よりも明らかに速い。 パンヌさん GitHub Copilotを使ってMCPのサーバー構築を行い、Figma関連の理解も深まり、すべての作業を完了できました。とても満足しています。 岡 皆さんが事前準備からしっかり取り組んでいたおかげで、3チームとも成果を出せていたので、良いイベントでした。 成果と学び AI活用により、調査・修正作業のスピードと精度が向上。 自動化によって工数を削減し、人的リソースをより重要な品質保証やテスト設計に集中できるようになった。 短期間で普段着手できなかった改善を実施でき、AI活用文化の形成にもつながりました。 おわりに 今回のVibe Coding Weekでは、QA業務の自動化と効率化に向けた3つのチャレンジを実施し、短期間で大きな成果を得ることができました。 事前準備に1ヶ月かけた甲斐があり、イベント期間中は全力疾走。 この経験で得たノウハウは、今後のQA業務に大きく活かされるはずです。 今後も「自動化・業務改善・AI活用」を継続的に推進するとともに、引き続き、色んなチャレンジに挑戦していきます。

Introduction I'm okapi from the Mobile team in the QA Group. "How much can we boost development productivity using generative AI in one week?" With that challenging spirit ignited, the QA Group also joined the internal event Vibe Coding Week, and I'm writing this article to share our experience. By the way, the cover image for this article was also created using AI. What is Vibe Coding? Vibe Coding is a new development style where human engineers collaborate with generative AI. AI takes on heavy tasks like code generation and research, while humans focus on quality verification and improvement, which enables high-quality and efficient development. Maximizing the power of AI while delivering value that only humans can provide—that's what the Vibe Coding Week is all about. During this week, we experience the limits and potential of the AI use to deepen the team's understanding of AI adoption. What Does QA Do? Does development productivity really relate to QA? Some of you might have thought such question. The QA Group actively works on automation, workflow improvement, and AI utilization every day. Obtaining the know-how cultivated through daily work, we decided to take on this Vibe Coding Week challenge. I participated as a representative of the QA Group. Starting one month before the event, we held weekly meetings and thoroughly discussed how we can deliver results. As a result, we decided to implement three automation tasks to make QA work easier! The 3 Automation Tasks We Tackled One of the QA team members will write detailed articles about the automation to create used vehicle data and to compare a screen design on specification with an actually developed screen. Please look forward to the article release. Challenge Overview Effect 1. Major version upgrade of Appium Library Updated the Appium library used for test automation by the QA Mobile team by two major versions (java-client: 7.6.0 → 9.0.0). Leveraged AI to accelerate release note research, modification task creation, and implementation, while updating compatible peripheral libraries simultaneously. Improved maintainability. Now able to use the aShot library (pixel-perfect comparison) compatible with screen comparison planned for future Appium automation! https://github.com/pazone/ashot 2. Used vehicle data creation automation Automated the creation of used vehicle data needed for testing by the QA Web Team using Playwright Previously, creating data for 200 vehicles took about 2 months, but automation reduced the team's workload. Freed from the tedious manual task! 3. Comparison automation between screen design on specification and actual screen Automated the comparison between screen design on specification in Excel and actually developed screen with VS Code that used to be done manually by the QA Web Team. Automated a process from extracting texts from specifications, identifying differences between design on specification and actual screen, and displaying where the differences are identified. Reduced verification time during the test phase. Differences that used to be checked visually can now be identified instantly! Team Members' Impressions Member Impression Oshima-san I was able to present what we had been constantly working on and expect it to be applied for actual projects. It was also good to be able to utilize AI in regular work. Lu-san The deliverables from this time seem useful for future project work. Kobayashi-san By using ClaudeCode, Copilot, and Devin respectively, I was able to grasp their performance differences to some extent. Whichever I used, the speed of research and implementation is definitely faster than manual work. Pann Nu-san I used GitHub Copilot to build an MCP server, which brought me an opportunity to deepen my understanding of Figma-related topics and complete all the work. I'm very satisfied. Oka Thanks to everyone's thorough preparation from the start, all three teams were able to deliver results, so it was a great event. Results and Learnings AI utilization increased the speed and accuracy of research and modification tasks. Automation reduced workload, allowing humans to focus on more important quality assurance and test design. We were able to make improvements that we couldn't normally tackle in a short amount of time. This contributed to forming a corporate culture where we automate routine tasks by leveraging AI. Conclusion In this Vibe Coding Week, we implemented three tasks aimed at automating and improving efficiency of QA work, achieving significant results in a short term. The one month of preparation paid off, and we sprinted at full speed during the event. The know-how gained from this experience should greatly benefit our future QA work. We will continue to promote automation, workflow improvement, and AI utilization continuously, and keep addressing various challenging tasks.