JaSST'26 Tohoku 参加レポート
こんにちは！ QAエンジニアの小竹です。OfficeMobileチームでiOSアプリのQAとして働きつつ、QA外部コネクトチームの一員として他社エンジニアの皆さまとのつながりを生み出す活動に携わっています。 サイボウズは、2026年5月29日（金）に開催されたソフトウェアテストのシンポジウム JaSST'26 Tohoku にスポンサーとして協賛しました。 この記事では、 JaSST'26 Tohoku でのサイボウズの発表についてご紹介するとともに、発表に使用した資料を共有させていただきます。 登壇情報 今回はスポンサーセッションに1名が登壇しました。 新卒1年目QAがリリース基準の"なぜ"をたどってみた speakerdeck.com このLTセッションでは、2025年度新卒入社・山形大学出身の「すずりん（@kir1nak.bsky.social）」から、担当製品のリリース基準の裏に潜む背景・目的を探究し、品質保証プロセスの改善に繋げた話を共有させていただきました。 セッションをご視聴下さった皆様、本当にありがとうございました！ また、SNS上で嬉しいコメントをくださった皆様にも、心からお礼を申し上げます。 登壇の様子 登壇者からのメッセージ 会場でセッションを聞いてくださった皆様、そしてJaSST東北実行委員の皆様、ありがとうございました！ 学生時代を過ごした東北の地で、このような登壇の機会をいただけたことを非常にうれしく思っています。 今回の発表内容が、皆様が取り組む業務改善の一助になれば幸いです！ 終わりに 今回のJaSST'26 Tohokuは、基調講演・事例発表でハーネスエンジニアリングが取り上げられたこともあり、「QAがAIとうまくやっていく」というテーマでの盛り上がりが見られました。 「AIを使って何をするか」を模索する段階から一歩進み、AIという新たな「仲間」をチームに迎え、いかにチームワークを発揮してQA活動を推進していくべきかを考えるフェーズに入ってきたことをひしひしと感じますね。 サイボウズQAはこれからも「チームワークあふれる社会を創る」という企業理念のもと、AIという頼もしいチームメートとともにチームワークをフルに発揮し、kintoneやGaroon、サイボウズ Office、メールワイズなど、チームを支えるサービスをお客様にお届けしてまいります。 QAエンジニア採用強化中！ 現在サイボウズでは、チームの一員として活躍していただけるQAエンジニアを募集しています。 サイボウズの企業理念に共感いただけるQAエンジニアの皆様、私たちと一緒に働きませんか？ 募集要項は以下のページにてご確認いただけます。 cybozu.co.jp カジュアル面談も実施していますので、まずは話だけ聞いてみたい、という方もお気軽にお声がけください！ カジュアル面談のお申し込み たくさんのご応募を楽しみにお待ちしています！
- テスト
- 品質保証
- 生成AI
Google I/O 2026 現地参加レポート
はじめに こんにちは！デザインテクノロジストをしている saku です:) 先日行われた Google の開発者向け年次カンファレンス 「Google I/O」に、弊社メンバーで現地参加してきました。 io.google エントランス付近の Google I/O サイン 今年は、2026/5/19~2026/5/20 の2日間、カリフォルニア州の Mountain View にある Shoreline Amphitheatre で開催されました。 I/O では、Google の提供する最新技術や製品のアップデートを、セッションや Googler とのディスカッションを通じてキャッチアップできます。弊社からは Web, AI, Android, Flutter にフォーカスして参加してきました。 現地参加 Overview Pre-I/O 日本からサンフランシスコまでは直行便で 9~10時間ほどでした。帰りは向かい風になるので 11時間で、すごく遠いですね。今回は時差ボケ・前日の予定を考慮して、当日の前々日に到着しました。 当日混まないように、前日は Badge pick up があります。I/O swag もこのときから先着順で受け取れます。 Find Your Way to register の看板 登録を済ませて、Swag を受け取ります。今年のスワッグにはかっこいいタンブラーが入っていて嬉しかったです！ Registration テントの中 Registration を済ませて I/O Pass を受け取りました 今年はなんと新型 gBike のライド体験ができたので、これで Google の BayView Office までサイクリングをしました！山々が望めるのですが、The 「Mountain View」という感じがしてとても爽快です。 Google BayView Office その日のランチは、Google Visitor Center にある Cafe でいただきました。横には Store があって、ここでしか買えない Google グッズが手に入ったりします🧤 Google Visitor Center 夕方からは、一部メンバーで Chrome チームのパーティーに行ってきました。 I/O 中ではしっかりできないようなディスカッションができて、想像もしていなかったとても貴重な時間となりました。こうした偶発的な機会や会話に恵まれるところも、現地参加の意義だとしみじみ感じます。 Chrome チームのパーティーに参加して、会話をしている I/O Day1 待ちに待った Google I/O 1日目は、AM 10:00~ の Keynote からキックオフです！ 道路の混雑が予想されたので、ホテルの朝食をスキップして早めに到着します。Amphitheatre と I/O パネルが見えたときは、流石に「いよいよ！」という感じがして気持ちが高まりました😆 セキュリティチェックを通って中へ。長蛇の列の奥に I/O のサインが見える Keynote の列に並んでいる間に、用意されていた軽食をいただけます。 そんなこんなで、CEO Sundar Pichai の登場から始まる Keynote で I/O 2026 がキックオフ！配信で見てた世界が目の前に現れて、感動がすごかったです！Search & Antigravity は色んな意味で結構面白いなと思いました。 Google I/O 2026: Sundar Pichai’s opening keynote CEO Sunder Pichai 登場の瞬間 Google Keynote のあとは、Developer Keynote。ここでは各領域の開発者にフォーカスした主要トピックが扱われます。全体を通して、主に Antigravity と各領域のその他 AI 関連の機能が feature されている印象を受けました。個人的には、 Antigravity が今年はどのくらい浸透し、開発者市場に影響していくのかが気になるところです。 Developer Keynote 15 updates from Google I/O 2026: Powering the agentic web with new capabilities, tools, and features in Chrome | Blog | Chrome for Developers 15 updates from Google I/O 2026: Powering the agentic web with new capabilities, tools, and features in Chrome | Blog | Chrome for Developers 17 Things to know for Android developers at Google I/O! | Android Developers' Blog https://developer.android.com/blog/posts/17-things-to-know-for-android-developers-at-google-i-o WebMCP | AI on Chrome | Chrome for Developers https://developer.chrome.com/docs/ai/webmcp Modern Web Guidance | Chrome for Developers https://developer.chrome.com/docs/modern-web-guidance Chrome DevTools for agents | Chrome for Developers https://developer.chrome.com/docs/devtools/agents I/O ではランチの提供があります。また、会場にはスナックやフルーツ、ドリンクのカートが常にあって、手ぶらで行っても食べ物には困らないと思います！ Snack Bar のカートが常時出回っている 多くの種類のランチボックスが用意されており、好きに選べる そのあとはテントを回りながら午後のセッションをいくつか聴きます。 こんな感じで Chrome, Cloud, AI, Android のテント, AI Sandbox などがあり、それぞれの demo を体験できたり Googler とキャッチアップができたりします。未公開製品を扱う AI Sandbox は waitlist 制で、順番が来ても中で 1時間くらい待つそうです。 テントではディスカッションができる AI Sandbox 他にも、Nano Banana を用いたプリクラブースや、AI で生成されたラテアートを披露するブースなど、趣向が凝らされた出展でテーマパークのように飽きることなく過ごせます。 <figure class="figure-image figure-image
- Android
- Flutter
- Web
- 生成AI
モバイルQAで積んだテスト設計が、gRPCの自動テストを支えてくれた
こんにちは！サイボウズ Office で QA エンジニアをしている、水谷（@dog_dog_3dog）です！ 今回は、新卒3年目を迎える3人のQA同期メンバーのリレーブログの2本目として、「仕事の変化はあるけれど、やってきたことはちゃんと力になっている」というテーマで書いてみようと思います。 1年前には想像していなかった今の仕事 3年目を迎えた今、私はグループウェア製品の中のLLM アプリの開発チームで、QA のリードとして働いています。 その中で、LLM アプリのバックエンドで使っている gRPC API のテストを、2か月で 500〜600 シナリオほど実装しました。 今の自分だけを見ると、「もともと自動テストや API テストが得意だったのかな」と思われるかもしれません。 でも、実際はそうではありません。むしろ、自動テストにはかなり苦手意識がありました。 LLM アプリの開発に携わることになることも、まして苦手意識のあった自動テストを集中的に実装することになるなんて、1年前の自分はまったく想像していませんでした。 もともとはモバイルアプリの QA だった 入社して最初に配属されたのは、サイボウズ Office モバイル（Android）の開発チームでした。 そのチームではスクラム開発を採用していて、毎週のように新機能が実装され、それに合わせてテスト設計とテスト実施を繰り返していました。 1週間で 5〜6 機能ほど増えるようなスピード感だったので、毎週たくさんのテスト設計をして、モバイルアプリのテストに追われる毎日でした。 2年弱で、合計 200 近いテストスイートを作っていたと思います。 とはいえ、1つ1つの機能は Web アプリの機能をモバイルで再現するものが多く、実装単位としては比較的細かいものでした。 リファインメントが終われば、すぐにテスト設計をして、次の週には実装が終わり次第すぐにテストを実施する。 慌ただしい日々ではありましたが、短期間で新機能のポイントをつかみ、テンポよくテスト設計、テスト実施を進めていく経験を重ねることで、QA としての基礎をしっかり積むことができた期間だったと感じています。 そこから仕事が大きく変わった その後、自分の所属するチームで PoC として開発していた LLM 機能が製品に組み込まれることになりました。 昨年のゴールデンウィークごろに、「実際に製品として開発して半年後にリリースする」という方針が決まり、その流れで私は LLM アプリの QA を担当することになりました。 どんな流れで、どんな業務をしているかはご興味あればこちらをご参照ください。 https://speakerdeck.com/cybozuinsideout/jasst2026tokyo_mizutani そして今年の2月ごろからは、主務の QA メンバーが自分1人、兼務でサポートしてくださる QA が1人という体制の LLM アプリ開発チームに参画し、バックエンドで利用している gRPC のテストをひたすら書いています。 API のインテグレーションテストはそれまでほとんど書いたことがありませんでしたが、Claude Code や Codex を活用しながら、1日あたり 20 ケース前後を書けるようになりました。 Skillsを作成して、テスト観点をAIに渡して、自動でテストスクリプトを生成してもらっています。 もちろん最初からそうだったわけではなく、最初は格闘しながら 1 日 1 本書くのがやっとでした。1か月ほどかけて coding agent との付き合い方を覚え、ようやく 1 人でもある程度進められるようになった、という感覚です。 正直に言うと、バックエンドサービスの堅牢化のために自動テストを追加していく仕事がメインになる、というのは、少し前の自分には考えられなかったことでした。 今でも苦手意識はありますし、わからないことばかりで、本当に手探りで進めています。 それでもやれているのは、前に積んだ基礎があるから それでも、この大きな仕事の変化を少しずつこなせるようになってきたのは、入社してから培ってきた「テスト設計の技術」があるからだと感じています。 モバイルアプリのチームでずっとやってきたテスト業務は、バックエンドでマイクロサービス間の通信を行うための、gRPC のテスト設計や実装にもそのまま活きています。 たとえば、網羅的なテストを考えるためのデシジョンテーブル、何を同値として扱うかを整理する同値分割、エラーケースを漏れなく考えるためのユースケースや異常系の洗い出し、どれもテスト設計の基礎基本です。 今は、自動テストのコードを書くことがQAとしての仕事の中心になり、AIの力も存分に借りながら、この新しい課題に日々取り組んでいます。 でも、「何をテストすべきか」「どの程度の網羅性のテストをすべきか」を考える力は、間違いなく過去２年間の経験で積み上げてきたものです。 もしテスト設計の基礎ができていなかったら、実装をどうするか以前に、「そもそもこのテストはちゃんと設計できているのか」という大きな不安を抱えながら仕事をすることになっていたと思います。 おわりに 3年目を迎えるにあたって、このブログで一番書きたかったことは、 頑張ってこなしてきた仕事の経験は、新しいことをするときにもちゃんと自分を助けてくれる。 ということです。 仕事の内容や、求められるスキルが大きく変わることは避けられないことです。 でも、その変化の中でも、これまで積み上げてきた基礎はなくならないし、きちんと自分の身を助けてくれます。 最近は、そんなことを実感しながら仕事をしています。 明日は、同期のれおくんのブログも上がるのでお楽しみに！！
- QA
- gRPC
- 生成AI
JaSST'26 Tokyo 参加レポート
こんにちは！ QAエンジニアの小竹です。 OfficeMobileチームでiOSアプリのQAとして働きつつ、QA外部コネクトチームの一員として他社エンジニアの皆さまとのつながりを生み出す活動に携わっています。 （QA外部コネクトチームの活動については、本記事末尾でご紹介している資料もぜひご覧ください！） サイボウズは、2026年3月20日（金）に開催されたソフトウェアテストのシンポジウム JaSST'26 Tokyo にスポンサーとして協賛しました。 会場でセッションにご参加下さった皆様、本当にありがとうございました。また、Discord上でもたくさんの方にリアクション／ご発言いただき、とても嬉しく思っています！ この記事では、 JaSST'26 Tokyo でのサイボウズの発表内容をご紹介するとともに、発表に使用した資料を共有いたします。 今回はスポンサーセッションに1名が登壇しました。 LLMでもいつものテスト技術 〜意外と半分はこれまでのテストでした〜 speakerdeck.com このセッションでは、新卒入社3年目にしてAI機能開発チームのQA業務をリードする水谷（@dog_dog_3dog）から、LLMアプリのテストについて、現場での経験を踏まえてリアルにレポートさせていただきました。 発表を聞いてくださった皆様、Discordでの会話にご参加くださった皆様、本当にありがとうございました。 登壇者からのコメント セッションを聴きに来てださったみなさん、ありがとうございました！ LLMアプリの品質保証については、自分も正解がわかっているわけではなく、試行錯誤を繰り返しています。 そんな自分の経験が少しでも参考になれば嬉しいです！ ※登壇の感想をZennでも公開していますので、よろしければあわせてご覧ください。 zenn.dev JaSST'26 Tokyo ファンミーティングを共同開催しました 3月30日（月）にサイボウズ東京オフィスにて、スポンサーをはじめとする4社合同でアフターイベントを開催しました。 JaSSTでの学びの機会をインプットで終わらせず、会社の垣根をこえて交流の輪を広げたり、気づきを共有したりする場を作りたいと思い、OSTを行いました。 当日は定員近い30名弱が足を運んでくださり、用意していた12個の枠いっぱいにテーマが集まりました。 実際に出たテーマ（一部抜粋） ホストからのテーマの説明を聞いてうんうんと唸る方、セッションが終わっても話し込む方などが印象的でした。 皆さまによる自律的な参加に助けられ、クロージングまで和気藹々とした雰囲気で運ぶことができました。 終了後は「いろんな人と話せた」、「こんな話ができて嬉しかった」、「話し足りなかった」などの嬉しいご感想をいただき、運営としてもいち参加者としても充実した時間を過ごすことができました。 スポンサーとしてLTの時間もいただき、サイボウズからはQAエンジニアのmassanがQA外部コネクトチームのご紹介をしました。私たちは今回のファンミーティング運営や一部協賛活動、外部登壇の推進など社外との繋がりを増やす取り組みをしていますが、どのような思いでチームとなり、何をめざしたいかをお話ししました。 LT資料 speakerdeck.com 終わりに 近年、急激に生成AIが社会に浸透していることもあり、今回のJaSST'26 TokyoではAIに関する多彩な講演を満喫できました。 AI4QA／QA4AI、どちらのキーワードも非常に身近なものになり、今後のJaSSTも楽しみですね。 また、今回はアフターイベントでたくさんの方と交流できたのも、とてもよい経験になりました。これからも協賛・登壇など様々な形で技術コミュニティへ貢献していけるよう、サイボウズQA一同頑張って参ります。 直近では、2026年5月8〜9日に開催されるスクラムフェス新潟に協賛予定です。 こちらでも、参加者のみなさまと交流できるのを楽しみにしています！
- テスト
- 生成AI
- コミュニティ
サイボウズは JaSST'26 Tokyo で協賛＆登壇します！
こんにちは、OfficeMobileチームでQAエンジニアをしている小竹です。 サイボウズは 2026年3月20日（金）に開催されるソフトウェアテストのシンポジウムJaSST'26 Tokyoにスポンサーとして協賛します。 今回はスポンサーセッションに弊社のメンバーが登壇し、生成AIを組み込んだ製品のテストについてお話しする予定です。本記事ではこちらのセッション、およびJaSST'26 Tokyoの後に開催を予定しているアフターイベントについてご案内させてください。 LLMでもいつものテスト技術 〜意外と半分はこれまでのテストでした〜 日時 3月20日（金） 14:25（J3-2） タイムテーブル 登壇者 水谷 太一 （@dog_dog_3dog） 内容紹介 LLMアプリのテストについて知見がなく、どう進めるべきか悩んでいました。 しかし、実際にリスク分析からテストスイートを積み上げると、テストの半分は従来型のシステムテストでした。 AIもシステムの一部であり、品質保証のこれまでの考え方が十分通用しました。本セッションでは「従来のシステムテストで何を見たのか」、そして「LLM独自のテストをどう設計したのか」について、私たちのチームでの活動をお話しします。 登壇者の水谷は、新卒入社3年目ながらAI機能開発チームのQA業務をリードし、外部発信にも熱心なメンバーです。現場での経験を踏まえたリアルなレポートにご期待ください。 会場でチラシを配布しています！ オフライン会場にて下記のチラシを配布しています。 登壇情報や次回以降のイベント情報も掲載していますので、見かけたらぜひお手に取ってご覧ください。 JaSST'26 Tokyo チラシ アフターイベントを開催します！ 3/30（月）に、スポンサー4社合同でJaSST'26のアフターイベントを開催予定です！ イベントは参加者主導のOST形式で、JaSSTで得た学びや感想をワイワイ語り合えるような場にしたいと考えています。 「JaSSTの余韻をQA仲間と共有したい」という方は、ぜひふるってご参加ください。 イベントの詳細・お申し込み方法は下記のページにてご確認ください。 JaSST’26 ファンミーティング（Connpass イベント告知ページ） 終わりに サイボウズでは「チームワークあふれる社会を創る」という企業理念のもと、kintoneやGaroon、サイボウズ Office、メールワイズなど、チームを支えるサービスを開発しています。 私たちQAエンジニアは、これらの製品の開発プロセス全体を通じて品質を高めるべく日々奮闘しています。 今回のJaSST'26 Tokyoへの協賛＆登壇、そしてアフターイベントの開催が、ソフトウェアテストコミュニティへのささやかな貢献となることを願っています。 QAエンジニア採用強化中！ 現在サイボウズでは、チームの一員として活躍していただけるQAエンジニアを募集しています。サイボウズの企業理念に共感いただけるQAエンジニアの皆様、私たちと一緒に働きませんか？ 現在はキャリア採用／ポテンシャル採用の両枠で募集しておりますので、「実務経験はないがQAの仕事に関心がある」という方もぜひお気軽にご連絡ください。元カスタマーサポート担当者や医療業界からの転身者といった、ユニークなキャリアを持つメンバーも多数活躍しています。 募集要項は以下のページにてご確認いただけます。 cybozu.co.jp カジュアル面談も実施していますので、まずは話だけ聞いてみたい、という方もお気軽にお声がけください！ カジュアル面談のお申し込み たくさんのご応募を楽しみにお待ちしています！
- QA
- 生成AI
kintone フロントエンド開発における AI 活用の取り組み
こんにちは！サイボウズでプロダクトエンジニアをしている @daikimkw です。 この記事では、kintone のフロントエンド開発で AI をどのように活用しているか、そして kintone 開発全体として生産性を向上させるために今後どのような取り組みをしていくかについて紹介します。 kintone 開発での AI 活用については、以下の記事でも紹介しています。 サイボウズで利用可能な AI コーディングツールの紹介 kintone AI 開発の効率化！Claude Code に Renovate PR レビューをお任せした話 チーム専用の Claude Code Plugin マーケットプレイスを作った話 また、本記事の取り組みの一部は JS ConfJP 2025 で発表しているので、そちらの動画や資料も参考にしてください。 www.youtube.com 資料：大規模プロダクトで実践するAI活用の仕組みづくり AI 活用の取り組み kintone は顧客領域ごとに複数チームで開発されており、コードベースの規模も大きく、AI をうまく機能させるにはいくつかの工夫が必要でした。 ドメイン知識をマークダウンで管理する kintone は歴史的経緯や最適化のための工夫により、コードを読んだだけでは意図が伝わりにくい設計が多くあります。これらを AI に都度伝える必要がないよう、ドメイン知識をマークダウンファイルとしてリポジトリに配置し、AI が参照できるようにしています。具体的には、JS API・プラグイン機構・グラフなどの複雑な実装の設計背景や、kintone 固有の用語集などです。 kintone のフロントエンドはチーム単位でディレクトリが分かれており、その中で pnpm の monorepo として構成されています。この構成を活かし、ドメイン知識のマークダウンもチームごとに配置しています。こうすることで、AI が参照するコードとコンテキストの範囲がチームの担当領域に絞られます。グラフなどの複雑な実装や設計背景も、グラフを管理しているチームに閉じられるため、他チームのコンテキスト消費を抑えられます。 frontend/ ├── teamA │ ├── ai-guide # ドメイン知識をチームごとに管理 │ │ ├── js-api.md # JS API の設計 │ │ └── glossary.md # 用語集 │ ├── app1 │ ├── app2 │ ├── pnpm-workspace.yaml ├── teamB │ ├── ai-guide │ ├── app1 │ ├── app2 │ └── pnpm-workspace.yaml └── ... Agent Skills をチーム横断でリポジトリ管理する kintone 開発では、もともと各チームで Agent Skills を整備していました。 kintone リポジトリのルートに共通の Agent Skills もいくつかありましたが、チームによっては不要な Agent Skills が混ざっていると不要なコンテキスト消費につながってしまいます。一方で、チームの中だけに閉じていると知見がサイロ化してしまいます。 そこで、お互いの Agent Skills を参考にしつつ、チームごとに必要なものだけを選んで導入できるように、kintone 開発全体で共有する共通リポジトリを用意しています。 kintone-skills/ ├── kintone-development/ │ └── skills/ # 汎用 Agent Skills ├── teamA/ │ └── skills/ # チーム固有の Agent Skills └── teamB/ └── skills/ Claude のプラグインマーケットプレイスの構造に準拠させているため、 /plugin から追加でき、Cursor など他のツールでも vercel-labs/skills 経由で利用できるようになっています。ルールは設けず自由に追加できる運用にすることで、他チームがどんな Agent Skills を作っているか見える化し、知見がサイロ化しないようにしています。 具体的な Agent Skills の紹介 実際に使っている Agent Skills をいくつか紹介します。 文言の検討 kintone は多言語対応しており、新しい機能を実装するときには複数言語の文言を用意する必要があります。ただし、デザインシステムのライティングガイドラインや既存の文言パターンとの一貫性を保つのは手間のかかる作業です。この文言作成・レビューのワークフローも Agent Skills 化し、効率よく文言の検討を進められるようにしています。 以下は、「input:type=file にホバーしたときに相当する文言を検討して。」と入力した時の結果です Claude Code とのやり取りのスクショ セッション情報をファイル出力する AI とのやりとりはセッションが途切れたり、サマリー化（Compact）されるとコンテキストが失われます。そこで、AI とのやりとりや、実装計画を全てファイルに出力して残すようにしています。 実装開始時に、次のようなディレクトリを作成します。 0123_feature-name/ ├── plan.md # 実装計画 └── prompt.md # やりとり履歴 plan.md には、実装計画、タスクの分解、進捗を記録します。prompt.md には、生のプロンプト内容と、それに対してどう実装したかを記録します。どういう指示を出して、AI がどう判断したかが残るため、コンテキストの復元に役立ちます。 この 2 つのファイルにより、セッションが途切れても作業を再開でき、計画と実装を別のエージェントに任せるなど、柔軟にエージェントを切り替えることもできます。 エージェントによっては、実装計画専用のプランモードがありますが、プランモードを抜けるタイミングでファイル出力等のコンテキストを忘れてしまうため、今はプランモード相当のサブエージェントを使用しています。プランモードを抜けるタイミングで Hook させ、思い出させることができればもっと良いのですが、今のところはこのようになっています。 ドメイン知識を継続的に育てる ドメイン知識を管理するマークダウンファイルは実装が進むにつれて内容が実態と乖離していきます。そのため、定期的に実装とドキュメント内容に乖離がないかチェックするための Agent Skills も用意しています。 MCP の活用 Agent Skills だけでなく、MCP も AI の作業範囲を広げるのに役立っています。 kintone には kintone Design System チームが管理するデザインシステムがあり、デザイントークンやコンポーネントの仕様が Figma や npm パッケージとして管理されています。 note.com Figma で構築されたデザインの反映には Figma MCP や Chrome Devtools MCP 等を活用し、デザイントークンの取得から動作確認まで AI に任せています。 また、kintone Design System チームでは、コンポーネントの情報や仕様を取得できる MCP サーバーも開発しています。これにより、AI がデザインシステムの仕様を直接参照しながらコードを生成できるようになっています。 これからの課題 AI 活用が進む一方で、まだ解決できていない課題もあります。開発工程での AI 活用が進んでも、全体のリードタイムを短縮するには、デザインや品質保証のプロセスも一緒に変えていく必要があります。現状は、各チームが試行錯誤しながら、うまくいった取り組みを横展開していくという形になっています。この動きを加速させるために、組織横断での AI 活用推進の取り組みもやっています。こちらについては、また 1 〜 2 ヶ月後に誰かが書く記事を参考にしてください。 おわりに kintone 開発における AI 活用は、個人の生産性向上から始まり、開発チーム横断でのナレッジの共有、そして他職能を跨いだ活用推進へと広がりつつあります。開発速度以外も AI を使って加速させていきたいですね！
- 生成AI
- フロントエンド
- デザインシステム