この記事はkintoneの生成AIチームで連載中のkintone AIリレーブログ2026の2本目の記事です。 リレーブログでは、生成AIチームのメンバーがAIトピックに限らずさまざまなことについて発信していきます。こんにちは！ kintoneの生成AIチームでバックエンドの開発・運用を担当している 齋藤 ( K.Saito (@SightSeekerTw) / X ) です。以前、kintone AI ラボ のバックエンドを OpenTelemetry と AWS CloudWatch Application Signals で可観測性を向上させた話 という記事で kintone の AI 機能を実現しているアーキテクチャについて簡単に紹介しました。この記事の中ではアプリケーション部分は AWS の Lambda 関数としてデプロイして運用していたのですが、この度 Kubernetes (Amazon EKS) の基盤を構築し、こちらに移行する運びとなったことをご報告いたします。ここでは、どういった経緯、モチベーションで Kubernetes に移行することになったのかを紹介したいと思います。なぜ Lambda から EKS へ ?Lambda 運用で感じていた課題CloudFront + Lambda Function URL の構成管理の複雑さCloudFront + Lambda Function URL の構成を採用していましたが、AWS CDK での管理が煩雑でした。CloudFront はグローバルリソースのため北部バージニアリージョン (us-east-1) に、Lambda 関数は東京リージョン (ap-northeast-1) にデプロイする必要があり、リージョンをまたいだ値の受け渡しで整合性が崩れると、デプロイや削除が失敗することがありました。ペイロードサイズ制限によるワークアラウンドLambda には同期呼び出しで 6MB、非同期呼び出しで 256 KB というペイロード制限がありました (現在は 1 MB まで緩和)。 LLM のコンテキストサイズが拡大していく中で、この制限を回避するために Valkey を経由させるなどのワークアラウンドが必要でした。OpenTelemetry との相性前回の記事で紹介した OpenTelemetry で

この記事はkintoneの生成AIチームで連載中のkintone AIリレーブログ2026の1本目の記事です。リレーブログでは、生成AIチームのメンバーがAIトピックに限らずさまざまなことについて発信していきます。こんにちは、kintoneの生成AIチームでエンジニアリングマネージャー (EM) をしている立山です。kintoneにおけるAI機能のこれまで2024年夏：AI機能の開発を開始2024年10月：RAGを活用したAI機能を発表2025年4月：kintone AIラボとしてAI機能を一般提供開始2026年1月現在：提供機能数を拡大中（現在7つのAI機能を提供中）開発初期フェーズでは、まず価値のあるAI機能を素早く届けることを重視し、チーム自身が機能開発を担ってきました。kintone特有のコードベースの理解AIバックエンドの設計・運用・評価といった要素を同時に考える必要があり、チームの認知負荷が高まっていました。チーム方針の転換ちょうどそのタイミングで、毎年開催される大々的な社外向けのイベント（Cybozu Days）に向けてAI機能を量産する体制が求められました。この要求をきっかけに、チームが果たすべき役割を見つめ直し、「AI機能を開発するストリームアラインドチーム」から、「AI機能開発をスケールさせることに注力するプラットフォームチーム」に転換することを決めました。短期的な取り組み：開発の移譲まず着手したのは、AI機能の開発をkintoneの他の機能開発を担当するサブチームに移譲できる状態を作ることでした。AI機能開発に必要なJava, フロントエンドモジュールの提供実装・運用の判断を迷わせないためのドキュメント整備AIバックエンドを利用するための手続きの自動化と社内サービス化を進め、他チームがAIのバックエンドを強く意識せずに機能開発できる状態を目指しました。特に、AI機能開発に必要なJava, フロントエンドモジュールの提供では、AI特有の機能ごと、ユーザーごとに利用可否の制御をしてガバナンスを効かせたいAI用のバックエンドにリクエストを送るための認証の仕組み回答をシームレスに表示し、マークダウン記法もうまく描画したいといった開発上の要求を満たせるようにし、他チームのAI機能開発速度を下げないよう工夫を行いました。このような移譲により、チームとしても

こんにちは！サイボウズの People Experience チームの hokatomo(hokatomo.bsky.social) です。私たちのチームでは、2025年度も Waffle College に協賛し、女子・ノンバイナリー学生がITキャリアへ踏み出すための学びの場を支援しています。Waffle College とは、未経験からプログラミング・AI活用を学び、エンジニアインターンに挑戦するためのコミュニティです。半年〜1年をかけて実践的に学べるプログラムです。今回、このコミュニティにサイボウズは協賛し、コミュニティ内で学生の方に向けてキャリアに関するスピーチを行いました！その報告ブログです。college.waffle-waffle.orgなぜ「ジェンダーギャップ×IT」に取り組むのか今回の協賛： Waffle College に saku さんが登壇当日の学生からの質問は、実践的な内容が多く熱意をたくさん感じられました参加者の背中を押した登壇に！sakuさんから、 Waffle College に登壇してみておわりになぜ「ジェンダーギャップ×IT」に取り組むのか日本には依然として大きなジェンダーギャップが残っており、その影響はIT分野にも及びます。製品開発における視点の偏り、AI学習データの偏り、進学や職業選択のタイミングで受ける数々のバイアスなどなど……。女性がITを選ばないのではなく、選びにくい環境が存在しています。Waffle は、こうした環境を変えていくために活動する団体で、女子中高生・大学生がITに触れ、学び、挑戦できる場を提供しています。サイボウズの理念「チームワークあふれる社会をつくる」と通じるものがあり、当社は4年以上にわたり協賛を継続。これまでに9名が登壇しています。今回の協賛： Waffle College に saku さんが登壇今回は Waffle College 内の社会人にキャリアを聞く講座にて、デザインテクノロジスト saku(@sakupi01) さんが登壇しました。自身のキャリアの選択や価値観、デザインテクノロジストという仕事、日々どのように学び挑戦しているかなど、学生がキャリアを考える上で役立つ内容が多く語られました。当日の学生からの質問は、実践的な内容が多く熱意をたくさん感じられました講座内のQ&Aは非常に盛り上が

こんにちは、kintoneライターチームの安田です。今回は、私たちのチームがAIを活用して業務改善に取り組んだ事例をご紹介します。私たちkintoneライターチームでは、kintoneヘルプの記事の執筆や、製品文言の検討を担当しています。その業務の一環として、kintoneヘルプから匿名でお寄せいただいたお客様アンケートを分析し、「分かりにくかった」とご指摘のあったヘルプ記事を改善する活動を行っています。ヘルプアンケート分析の課題アンケートの回答に記載いただいたお客様のコメントを分析するにあたり、これまでは以下の課題がありました。匿名アンケートのため、お客様がどのような状況でkintoneを使っておられるのか分からず、コメントの意図や背景を正確に読み取ることが難しいどのヘルプ記事のどの記載内容を修正すれば改善するのか、特定に時間がかかることがあるヘルプ記事の修正を行うことで、逆にデメリット（分かりにくくなるなど）が生じないかの見極めが難しい課題解決のために考えたことそこで私たちは「AIの力を借りることで、お客様から頂いたコメントの意図や、改善すべき点の分析をより正確に短時間で行えるのでは」と考えました。最終的には人間のスタッフが判断して決断することに変わりはないのですが、事前にAIによる分析を行うことで、理解の助けになるからです。さまざまなAIツールを比較・検討した結果、「Dify」というAIツールを使えば課題が解決できそうなことが分かりました。Difyとは？Difyとは、誰でも簡単にAIアプリが作れるサービスです。ユーザーが入力した情報をAIが分析して回答してくれるアプリを、直感的なマウス操作で作ることができます。ここまで読まれたところで、「それだと、ChatGPTなどのチャットボットと変わらないのでは？」と疑問に思った方もおられるかもしれません。DifyがChatGPTなどの一般的なAIチャットボットと異なる点は、Difyは外部のサービスが提供するAPI（やり取りを行うためのインターフェース）と接続して、外部のサービスから情報を取得したり、送信したりできる点です。たとえば、kintoneアプリでは「APIトークン」を提供しており、APIトークンを使うことで、kintone以外の製品からkintoneアプリのレコードのデータを取得することが可能です。「Difyから

はじめにこんにちは！kintoneQA & QAキャリア採用チームに所属しているmiyakeと申します！普段は主にkintoneQAとして活動しており、# サイボウズって最高な仲間の宝庫 # 引き続き最高な仲間を探したいという想いでキャリア採用活動にも参加しています。現在、サイボウズQAではキャリア採用を開始しており、一緒に働く仲間を募集しています。今回は、サイボウズ入社から2年ほど経過し視野が広くなった私が、サイボウズのQAや会社について語ろうと思います。転職を考えている方の参考になれば幸いです。すでにサイボウズをご存知の方、気になっていた方はまずはカジュアル面談で気軽にお話しましょう！以下リンクからエントリーお願いします！カジュアル面談受付フォームサイボウズという会社やQAエンジニアについてサイボウズには「チームワークあふれる社会を創る」という理念があり、その理念に共感した仲間が集まっています。お互いの持つ情報を共有しつつ、共通の理想に向けて全員が舵を切れるように、下記5つの文化を大切にしています。企業理念サイボウズに所属しているQAエンジニア以外の仲間も最高なのですが、ここでは主にQAエンジニアの特徴について、5つの文化をもとに書いていこうと思います。 ※主観成分多めです理想への共感全員が同じ理想（目標）に共感していることを大切にしており、チームに所属している人々が職種を越えて協力的です。シフトレフトの取り組みなど、QAチームだけでなく開発チーム全体で品質向上に取り組んでいます。多様な個性を重視「一人ひとりは違う個性を持つ存在である」という考え方のもと、個性を活かした生産性の高いチームづくりを心がけています。サイボウズでは60名ほどのQAエンジニアが所属しており、元SWE（ソフトウェアエンジニア）やカスタマーサポートの経験者など、多種多様な背景を持ったメンバーがいます。それぞれのバックグラウンドを活かしたレビューなど、日々勉強になっています。公明正大多様な個性を重視するチームで信頼関係を築いていくために、お互いが正直でいなければなりません。社内では情報がオープンかつ議論に参加できる体制で、風通しの良い環境を目指しています。このようにオープンな環境であることに加え、勤続年数が長い人も多く背景情報が豊富なので、新しく入社した人が何かで困っても、気軽に質問すれば解決

BuriKaigi 2026 に登壇 & 協賛してきました！1/9(金), 1/10 (土) に富山の富山国際会議場で開催された BuriKaigi 2026 にてサイボウズのメンバー計 5 名がセッションでの登壇しました。またサイボウズはガンドスポンサーとして BuriKaigi2026 に協賛しており、ブース出展＋スポンサートークも行いました。burikaigi.dev今回は参加メンバーにそれぞれ感想を寄せてもらいつつ、Sajiがその時の様子をお伝えしたいと思います。BuriKaigi 2026 とはBuriKaigi は毎年富山で開催されている分野を問わないソフトウェア開発・IT 技術に関するカンファレンスです。前身となるイベントを含めると今年で 11 回目の開催となり、今年は初めて 2 日間開催となりました。登壇とスポンサートーク今回サイボウズからはスポンサートークを含めて、sakito、nus3、おぐえもん、tekimen 、saku、Sajiの 6 名が登壇しました。ここではそれぞれの登壇内容について、簡単に発表者が内容を紹介します。sakitoタイトル：『2025 年の Web フロントエンドのふりかえりと 2026 年』(プロポーザル)発表資料www.docswell.com2025 年にあったフロントエンドの状況をフロントエンドに詳しい人じゃなくても得られるようにまとめ、2026 年に起きそうな変化を紹介しました。nus3タイトル: 『WebDriver BiDi 2025 年のふりかえり』 (プロポーザル)発表資料 speakerdeck.com仕様策定中の WebDriver BiDi の 2025 年の動向について、主に次のことを話しましたWebDriver BiDi とは何なのか追加、更新された仕様について主要ブラウザの対応状況この発表をする上で、特に WebDriver BiDi の主要ブラウザの対応状況として、Chromium には WebDriver BiDi と Chrome Devtools Protocol 間を変換する JavaScript レイヤーがあることや、WebKit では Linux 向けの WebKitGTK で Igalia の方が実装を進めていることが知れたことが印象に残ってます。Safari でも WebDr

こんにちは。テクニカルライターチームの近藤（@konyukiwork.bsky.social）です。2025年は、生成AIがものすごいスピードで発展し、「どうやったらうまく活用できるのか？」と試行錯誤を重ねた1年でした。今回は、サイボウズのテクニカルライターが、生成AIを活用してリリースノート作成を効率化した事例をご紹介します。どんな課題があった？製品アップデートの頻度が増え、リリースノートの更新作業の負担が大きくなっていた製品ごとに文体（「ですます調」「体言止め」など）が異なり、手作業での修正に手間がかかっていたねらい担当者の負担を減らし、ライターのチェック作業をスムーズにする全製品でルールを統一する案もあったが、まずはツール開発に挑戦することで、AI活用の可能性を探っていくどんなAIツールを作った？課題解決のため、2つのAIツールを開発しました。文体統一AI「アンくん」製品ごとに異なるリリースノートの文体を、ルールに沿って自動で変換します。仕組み ノーコードツール「Dify」というプラットフォームを採用しました。人間が作成した2種類のリリースノートを用意変換元：「cybozu.com共通管理」のリリースノート（ですます調）変換先：「Garoon」のリリースノート（体言止め）この2つの文章を学習させ、次の指示を出すこの2つの特色を分析して変換元の文章を変換先のスタイルに変えるための、プロンプトを考えてDifyの設定画面。異なる2種類のリリースノートの文体を整えてくれる仕組みです。左側にAIに作成してもらったプロンプトがあります。草案自動生成AI「ベーダくん」開発要件から、リリースノートの草案を自動で作成します。仕組みkintoneアプリに登録されたGaroonの開発要件の情報を学習し、AIがリリースノートの草案を生成してくれる、を想定しています。導入してみた効果と、これからのことまだまだ試行段階ではありますが、AIと向き合ったことで色々な発見がありました。得られた効果各製品で行っていた修正作業がなくなり、とても効率的になったAIが生成する草案は、要点がまとまってて、また表記の揺れがなくなったことで、人間による最終チェックもとても校正しやすくなった今後の展望一方で、AIが生成した文章をそのまま公開できるかというと、まだ「人間の目で校正する」という最終チェックは欠かせ

こんにちは、フロントエンドエンジニアのおぐえもん（@oguemon_com）です。世間では12月頭から続いたアドベントカレンダーシーズンが終わり仕事納めムード一色ですが、みなさんいかがお過ごしでしょうか。サイボウズでは、アドベントカレンダーとして大量の記事が投下されるこの時期を避けるように、7月中旬から「CYBOZU SUMMER BLOG FES '25」（通称ブログフェス）というブログの夏フェスを開催していました。そしてブログフェスは、7月14日（月）から約3ヶ月半にわたる会期を終え、11月5日（水）に無事幕を下ろしました。結果として、111名の当社社員の手で、120本の記事を投稿することができました！！昨年と比べて執筆社員数と投稿記事数がそれぞれ23人（＋26.1%）、16本（＋15.4%）増え、より大きなイベントになりました！私は、同じようなイベントがもっと色んなところに広がって欲しいと思っています。そこで、そうしたイベントをやりたい皆さんの参考になればと、今年もブログフェスの一部始終を振り返って記録に残します。ちなみに、初開催だった昨年にも同様の記事を残していますので、よければ併せてご覧ください。CYBOZU SUMMER BLOG FES '25とは？「CYBOZU SUMMER BLOG FES '25」（通称ブログフェス）とは、サイボウズが誇るブログ記事の夏フェスです。昨年（'24）の夏に初開催して、今年は2回目です。内容はシンプルで、社内のチーム毎にそれぞれレーンを作り、所定の日にちにブログ記事を投稿してもらうというものです。昨年は毎日投稿とし、今年は所定の曜日に週1投稿としました。このように細かいルールは毎回変えていて、最適な形を模索しています。常に共通するのは夏フェスとしての盛り上がりをイベントに込める熱い気持ちです！ブログフェスの投稿スケジュールのイメージ（上段は'24、下段は'25）イベントの根底には、アドベントカレンダーの時期を避けてアドベントカレンダーをやりたいというシンプルなアイデアがあります。12月1日〜25日に記事を繋ぐアドベントカレンダーの風習は、IT業界全体が盛り上がる一方、結果として12月に記事の供給が過多になり、せっかく書いた記事が他から出た無数の記事に埋もれやすいことを問題視していました。「夏フェス」の開催を決めたのは、

こんにちは！ソフトウェアエンジニアとして活動している @nissy_dev です。サイボウズでは、各プロダクトを新しい Kubernetes 基盤に移行する取り組みを進めています。この記事では、Kubernetes リソースの管理において、従来の環境別ブランチ運用から Jsonnet mixins を活用した単一ブランチ運用への移行について紹介します。目次ArgoCD での環境別ブランチ運用発生していた課題Jsonnet mixins を使った環境別ブランチの廃止Jsonnet mixins設計方法トレードオフパラメータと mixins の使い分けが難しいmixins では配列の上書きの実装が複雑になるまとめArgoCD での環境別ブランチ運用Kubernetes リソースを管理するプロジェクトの構成は、次のようになっていました。├─ namespace-a/ // ArgoCD で管理しているリソースの置き場│ ├─ stg/ // ステージング環境に適用するリソース│ │ ├─ resource-a.jsonnet│ │ ├─ resource-b.jsonnet│ │ └─ ....│ └─ prod/ // プロダクション環境に適用するリソース│ └─ ....├─ namespace-b/ // ArgoCD で管理しているリソースの置き場│ ├─ stg│ └─ prod└─ libs/ // stg や prod で共通で使う libsonnet の置き場 ├─ lib-a.libsonnet ├─ lib-b.libsonnet └─ ...環境ごとにリソースの変更をデプロイしたい場合は、stg や prod ディレクトリ配下を更新する運用をしていました。一方で、stg と prod で共通して利用している libs 配下の libsonnet を修正したときは、まずステージング環境に適用して問題がないことを確認してから、プロダクション環境にも反映させるようにしたいです。そのため、ステージングとプロダクションの両環境に対応するブランチ (stg, prod) を作成しました。ArgoCD ではそれぞれのブランチを環境ごとに対応させ、以下の方針で運用していました。修正は必ず先に stg ブランチへマージするstg ブランチで問題がなければ、同じ変更を

こんにちは！開発本部 組織支援部People Experienceチームの貴島（@jnkykn）です。2025/11/19 東京オフィスで、どう使う？サイボウズと語ろう 生成AIとの付き合い方 Cybozu Tech Meetup#24を開催しました。この記事では、当日の様子をご報告します。どう使う？サイボウズと語ろう 生成AIとの付き合い方 Cybozu Tech Meetup#24Cybozu Tech Meetupは、サイボウズが主催する技術系のMeetupです。回ごとに異なるテーマで、開催しています。24回目の今回は、サイボウズのエンジニアたちが開発の現場で生成AIをどう取り入れているのか、そしてプロダクト開発とAI技術の関係をどう考えているのかを共有し、開発効率化のヒントはもちろん、「生成AIと共に進化する開発のこれから」についてざっくばらんに語り合う会として企画しました。ご参加くださった皆さま、ありがとうございました！https://cybozu.connpass.com/event/372912/当日の様子本日のスケジュールや座談会の参加メンバーの紹介のあと、本編の座談会が始まりました。座談会社内のAIツール利用状況について説明する加瀬さん座談会では、3名のパネリストから、サイボウズ社内の生成AI利用状況や、生成AI利用ツールの確認や組織への導入手順、現場でどのように利用しているか？を、ざっくばらんに共有しました。開発本部長の鉄平さんからは、サイボウズの生成AI利用ツールの予算やセキュリティについてのお話。サイボウズの予算の考え方は、必要であれば予算外でも利用できる柔軟さがある。経営的には費用対効果は気になるが、今のところはまず試してみるということを優先している。セキュリティに関しては、セキュリティ室、PSIRT、情シス、法務などが集まっている会議体が存在するので、必要な場合はそこで議論した上で利用を承認している。AIやっていき副部の加瀬さんからは、次々に登場しアップデートされ続けるAIツールに対して、AIやっていき副部がAIツールの社内利用までの道筋を作っていること、社内の利用促進のためにAIやっていき副部が中心になって、AIコーディングツールについてオンラインで雑談する会を開催していることをご紹介しました。AIツールの社内利用までの道筋AIやってい

The PHP FoundationへSilver sponsor以上で寄付されている会社様へ Advisory Board Slackへ参加しませんかAdvisory Board Slackへ参加しませんかこんにちは。Garoon 開発チームのてきめんです。今回は、The PHP Foundationのお話をさせていただこうと思います。The PHP FoundationとはPHPの持続的な繁栄を支えていこうという団体で、サイボウズは設立初期の2021年から寄付を続けています。thephp.foundationSilver sponser以上継続して寄付されている企業には、特典として「Advisory Board (Slack)」というものがあります。Advisory Boardとは、PHP Foundationとアイデアやコミュニティの懸念事項などを一定間隔で交換するためのフォーラムだそうです( https://thephp.foundation/blog/2023/03/31/php-foundation-update-march-2023/#a-new-benefit-for-major-sponsors-%E2%80%93-advisory-board-membership より)こちらにも詳しい内容がありますね：Governance of the PHP Foundation — The PHP Foundation — Supporting, Advancing, and Developing the PHP LanguageSilver sponsorは年間12000ドル以上の寄付によるものです。https://thephp.foundation/sponsor/ より、「Sponsorship Deck」というPDFのリンクがありまして、PDFの10ページ目に「MEMBERSHIP LEVELS」というのがあります。PHP Foundationのスポンサーの特典一覧その中に、「Advisory Board membership (Slack)」というのにチェック☑がはいっていますね。サイボウズはSilver sponsorに長年寄付しておりますが、この特典を使っていないことに気がついてPHP Foundation側にコンタクトを取ってみました。コン

はじめに講演[三井物産セキュアディレクション株式会社] Agentic Web Security[GMO Flatt Security 株式会社] AI エージェント SaaS を安全に提供するための自社サンドボックス基盤ディープフェイク・サプライチェーン：サイバー犯罪の武器となる合成メディアAgentic AIによる実践的ペネトレーションテスト自動化コンテスト・ワークショップMaritime Hacking VillageCyberTAMAGOおわりにはじめにこんにちは、Cy-PSIRTです。2025年11/18, 19の日程で開催された国際的な情報セキュリティカンファレンスであるCODE BLUE 2025にPSIRTから6名参加してきました。本記事では、PSIRTメンバーが特に印象に残った講演や参加したコンテスト・ワークショップを紹介します。講演[三井物産セキュアディレクション株式会社] Agentic Web Security[三井物産セキュアディレクション株式会社]Agentic Web Security | Time Table – 世界トップクラスの専門家による情報セキュリティ国際会議「CODE BLUE（コードブルー）」こちらの講演では、マルチエージェントシステム（MAS）の普及に伴う新たなセキュリティリスクや、従来のAIエージェントとは異なる視点でのリスク分析の必要性が強調されていました。具体的なインシデント事例やガイドラインを通じて、MASの信頼性・安全性を確保するためのベストプラクティスを学ぶ重要性を感じました。今後はブラックボックスになりがちなMASの追跡可能性を高める対策がますます求められそうです。[GMO Flatt Security 株式会社] AI エージェント SaaS を安全に提供するための自社サンドボックス基盤[GMO Flatt Security株式会社]AIエージェントSaaSを安全に提供するための自社サンドボックス基盤 | Time Table – 世界トップクラスの専門家による情報セキュリティ国際会議「CODE BLUE（コードブルー）」こちらの講演では、セキュリティ診断AIエージェントを安全に実行するためのサンドボックス基盤について解説がなされました。Takumiのサンドボックス基盤では操作だけを閉じ込めるAction

クラウド基盤本部の新井です。サイボウズでは、セッション情報など一時的なデータを置くために yrmcds というインメモリキーバリューストア（KVS）を開発し、クラウド基盤にホストして利用してきました。blog.cybozu.io私たちのチームでは、旧基盤にホストされてきた yrmcds を、Kubernetes をベースとした基盤である Neco に移行しようとしています。そこで、プラットフォーム（自社基盤）コースのインターン参加者に、Kubernetes 上で KVS の冗長化を実現するアルゴリズムの設計と PoC の実装を行なっていただきました。本記事は、その成果をメンターがまとめたものです。同じコースのインターンに参加した柳田さんの取り組みは以下の記事にまとまっているので、ぜひ合わせてご覧ください。blog.cybozu.io旧基盤における yrmcds の冗長化旧基盤においては、yrmcds のレプリケーションと Keepalived により冗長化を実現しています。具体的には、yrmcds のプライマリが VIP を持ち、クライアントからのリクエストを受け付けつつ、データをレプリカに送信します。プライマリがダウンすると、レプリカが VIP を引き継ぎ、プライマリに昇格します。しかし、この方法によるフェイルオーバは Kubernetes と非常に相性が悪いです。Kubernetes のネットワークとの相性これを Kubernetes 上で動かすためには、Pod の中で Keepalived を起動して VIP を付与することになります。しかし、Pod の IP アドレスは基本的に Kubernetes のネットワークプラグインが管理しており、Pod の中で任意に IP アドレスを付与することは推奨されていません。さらに、Keepalived が利用する VRRP は Gratuitous ARP のような L2 ネットワークの仕組みを使って VIP の所有権を通知しますが、Kubernetes ではこのような仕組みが期待通り動作しない場合があります。ローリングリスタートとの相性確実に VIP が付与できる*1としても別の問題があります。VRRP はマスタとして動作するノードがダウンした際にバックアップノードが VIP を引き継ぐ仕組みです。そのため、KVS の

こんにちは。kintone拡張基盤チームQAの massan です。今回は、今年2025年8月にリリースされたkintoneローカルMCPサーバー（以下 kinone MCPサーバー）のQAプロセスについてご紹介します。kintone MCPサーバーの紹介拡張基盤チームでは現在、Claude DesktopやCursorといった生成AIからkintoneを操作できるMCPサーバーを公開しています。8月の初回リリースから機能追加を経て、現バージョンではアプリ検索から基本的なレコード操作、アプリ作成までをサポートしています。cybozu.dev開発が決まった頃からQAが参加しており、MCPサーバーについての学習をしたり、サポートする機能の明確化や、リリース前までのテストなどを行っていました。kintone MCPサーバーのQAプロセスQAプロセスとしては主に以下のものが行われました。PdE（プロダクトエンジニア）によるコードレビュー、ユニットテストの実装インスペクタを使った動作確認QAによる手動テストチームではユニットや結合レベルでのテストは本開発に限らず基本的にPdEにお任せしており、QAはあまり関与していません。QAが回帰テストの設計をしているときなどに「こういう観点も繰り返し見たい」とチームに共有し、もしその観点をカバーする自動テストがなければ追加を検討する程度です。インスペクタは、多くのMCPサーバー開発の場で行われている事例を参考に使用しました。今回の開発では、機能テスト前の動作確認や、生成AIと接続した状態の機能テストで挙動がおかしいとき、原因の切り分け等で大いに役立ちました。QAによる手動テスト開発中には担保するべき品質特性の整理やセキュリティに関してPSIRTとの相談も行いましたが、ここでは手動での機能テストのご紹介をします。AIが多少コードを書けるようになり、テスト設計や自動テスト実装もしてくれる昨今ですが、今回のように要件を固めながら進めるプロジェクト、ドメイン知識をもったテストが必要な状況で人間のQAがいる意義はあったのではないかと思います。自動テストでkintone MCPサーバー単体の機能、インスペクタを使った動作確認でリクエストとレスポンスの動作は概ね担保されているため、手動テストでは以下のことを重点的に行いました。生成AIツールとkinto

どうも、フロントエンドエンジニアのnus3です。12/1~2 の2日間で「12 月だﾖ! フロントエンド全員集合!!」という社内イベントをオフラインで開催したので、本記事では、その様子をお届けします。「12 月だﾖ! フロントエンド全員集合!!」 とはフロントエンド開発に関わる・興味があるメンバーが集まり、交流を深めることを目的とし、企画、開催しました。開催時期の問題もあり、体調不良等で参加できなかったメンバーもいましたが、様々なチームから、15 名程度のメンバーが参加してくれました。アイスブレイク「12 月だﾖ! フロントエンド全員集合!!」では様々なチームのプロダクトエンジニアが参加してくれたので、まずはアイスブレイクを行い、メンバー間の氷を徐々に溶かしてもらいました。自分以外にも 1 人くらいおるやろ自分以外に該当者が1人いるテーマを考えるゲームにチャレンジ！ちなみに自分は「サイボウズに入ってから体重が5kg以上増えた」という投稿をしたのですが、該当者が2人いたので、チャレンジ失敗でした。人間ブラックジャック大会次に、チーム対抗でプロフィール項目を1つ検討し、それにまつわる数字の合計値を目標値に近づけるゲームにもチャレンジ！次の画像は各チームで合計値が60になるようなプロフィール項目を検討している様子。その日限りの即席チームでフロントエンド ハッカソン！アイスブレイクによって、参加メンバー間の人間関係がホットになったところで、「12 月だﾖ! フロントエンド全員集合!!」のメインコンテンツとして、即席チームによるフロントエンドハッカソンを行いました。なるべく普段とは異なるメンバーで構成されるチームでフロントエンドに関する課題を考え、実際に取り組んでもらいました。各チームが取り組んだ課題は次の通りです。Vitest Browser Mode のプロダクトへの導入検証特定チームの Jest→Vitest 移行baseブランチと PR の差分をチェックして、 rebase の必要性を判断して PR にコメントしてくれる GitHub Actions俺が考えた最強のカレンダーロジックの作成次の画像は各チームが真剣に課題に取り組んでる様子と取り組んだ内容を発表している様子。最後に特に kintone というプロダクトでは、普段はチームごとに独立して開発を進められる体制に

サイボウズでプロダクトエンジニアをしている daiki です。前編では、TPACに参加した一部のメンバーによる振り返り動画をお届けしました。blog.cybozu.io後編では、参加メンバーそれぞれの視点から、TPACとはどんな場だったのか、何を見て何を感じたのかを綴ってもらいました。Web標準は「どこかから降ってくるもの」ではなく「みんなで作るもの」-- gorohashお恥ずかしながら、今回参加した他のメンバーと違って常日頃からWeb標準関連の動きを事細かにキャッチアップできているわけではないため、初めてのTPAC参加は全てが新鮮な体験でした。世の中にはW3Cを含め標準化団体というものがいくつか存在し、それらがWebの標準仕様を策定しているということは当然知っていました。でもそれは画面の向こうの世界の話であって、率直に言うと自分にとっては手の届かないどこかで決まったものをキャッチアップして、ただ受け入れて、わからなければMDNで調べる、というだけのものでした。今回TPACに参加して、まず当然ながら確かに人と人とが話し合ってWeb標準というものを作り上げているということを実感しました。TPAC全体では500名以上が参加しているものの、5日間×十数並列でミーティングが開催されているため、多くの議論は高々20〜30人によって進められます。今では数十億人が利用するWebのルールが、その一部とはいえ、ちょっとした会議室に収まる程度の人数で決められていることに驚きました。自分の手の届かないどこかで決まるもの、ではなく、ここにいる人たちと議論を交わせば自分の意見も反映できるのだということを実感しました。ただしそれは決して簡単なことではなく、既存仕様や実際のユースケース、それらを取り巻く環境に対する深い理解、そして相手の意見を聞き自分の意見を伝えるだけの英語力が必要であることも痛感しました。今回は日本での開催ということもあって多くの日本人参加者がいましたが、Webという巨大なエコシステムに関わる人数からすれば極々わずかです。そのエコシステムの中で生きる一人としてWeb標準にどのような貢献ができるのか、考え始めるきっかけになりました。WCAGの国際化対応-- mehm8128WCAG 2.2 and non-Latin languagesというbreakoutsで日本人の方が「W

25新卒プロダクトエンジニアの mehm8128 です。今年4月より W3C に加入したサイボウズは、11/10～11/14 に行われた TPAC 2025 に10名ほどで参加してきました。前編と後編に分けて、その様子や感想をお送りします。Shownote11/25 の Cybozu Frontend Monthly にて、参加した一部のメンバーで振り返りの様子を配信しました。前編では、その中身を簡単にさらいます。詳細はアーカイブをご覧ください。cybozu.github.iowww.youtube.comTPAC とはTPAC 2025: OverviewW3C が開催する全体会合一週間の開催で、様々なミーティングが開催される会場神戸国際会議場https://www.w3.org/2025/11/TPAC/venue.html国際会議場受付の様子休憩室の様子。奥で弊社メンバーが作業している登録者数 761 人、現地参加 564 人、リモート 197 人事前準備会議内容は事前に Agenda がまとめられ、スケジュールにリンクされるTPAC 2025: Detailed scheduleIRC特定のベンダーのチャットサービスに依存しないよう、 W3C でホストしているチャットhttps://webirc.w3.orgq+ というコマンドで、発言待ち (Mic Queue) に参加する機能がよく使われる会議のログを書き、それをまとめてログに残すコマンドがある運用はグループによってバリエーションがあるMeeting の種類Group Meeting: Working Group (WG) のミーティングJoint Meeting: WG をまたぐ議題を共同で議論するミーティングBreakout: WG などに属さない新しい話題をもちよるミーティングAC Meeting: Advisory Committee (会員企業の代表) が集まるミーティング会期中もスケジュールが変更したり、新しいミーティングが追加されたりもする食事ランチと水曜の全体懇親会は隣接するホテルでビュッフェランチの様子連れ立って食べに出ることも多い月曜夜は W3C 日本会員向けディナー会W3C CEO の Seth と 弊社 saku さんが同席しましたディナーの様子。W3C CEOの Seth と弊社

こんにちは！Cy-PSIRTの小西、田口、北村、湯浅です。本記事はサイボウズ サマーインターンシップ2025 プロダクトセキュリティコースの開催報告です。 今年は9月に1ターム、昨年と同様にフルリモートで開催しました。概要プロダクトセキュリティコースは、9月8日〜12日の5日間で開催し4名のインターン生に参加いただきました。今年は開催形式を見直し、期間を例年の4日間から5日間へ拡大しました。また、これまでインターン専用環境で業務体験をしていただいていましたが、今回はサイボウズ社員が実際に通常業務で利用している社内環境へ参加してもらい、より実務に近い形でコンテンツを提供しました。5日間のスケジュールは以下です。今年は、例年に続き社員との交流の機会を設けつつ、コンテンツの幅を拡大し、より事業会社ならではのセキュリティ業務を体験いただけるよう構成しました。本記事では一部のコンテンツを抜粋してご紹介します。紹介していないコンテンツについては、昨年のブログに一部記載されていますので、ぜひそちらも参考にしてください。blog.cybozu.io自動検証この時間では、PSIRTで実際に利用している自動脆弱性診断ツール「AeyeScan」を使ったテストを体験していただきました。AeyeScanによる巡回やスキャンの流れを通して、どのように脆弱性を検出し結果を分析していくのかを学んでもらいました。また、サイボウズにおけるツール活用の方針や手動検証との分担、検出結果のトリアージの考え方についても紹介しました。単にツールの操作方法を学ぶだけでなく、PSIRTがどのように日々の検証業務を効率化し運用しているか理解していただく機会にもなったと思います。インターン生の皆さんは興味を持ってツールを触り、積極的に理解を深めていました。自動化の仕組みを実際に体験することで、PSIRTの脆弱性検証がどのように行われているかをより具体的にイメージしてもらえたのではないでしょうか。プロダクトセキュリティを支える活動の体験脅威分析この時間では、サプライチェーンのリスクについて検討していただく演習を行いました。インターン生の皆さんにはサプライチェーンのリスクについて概要を紹介し、実際にどのような脅威があり、それに対してどのような対策ができそうかについてディスカッションを実施していただきました。また、ディスカッ

11/16（日）に開催されたJSConf JP 2025にて、サイボウズがプレミアムスポンサーとして協賛し、ブース出展＋スポンサーセッションを行いました。新卒フロントエンドエンジニアのmehm8128（めふも）が当日の様子をレポートします。JSConf JPとはJapan Node.js Associationによって毎年開催されている、JavaScriptの祭典です。今年で6回目の開催となり、主にJavaScriptに関するセッションが行われます。jsconf.jpブース今回のサイボウズのブースのテーマは「ブースのコンテンツは俺達だ！！」でした。タイムテーブルを決め、フロントエンドのメンバーがそれぞれ得意な分野について参加者の方々と会話し、交流できるような場にしました。JSConf JP 2025 でのサイボウズブースですが、悩んだ結果「コンテンツは俺達だ！！」ということになりました。メンバーが座ってるのでぜひお話しましょう！！#jsconfjp https://t.co/5mrohuvLd0— mugi (@mugi_uno) 2025年11月14日 タイムテーブルは以下のようになっていました。タイムテーブル10:50〜12:00 フロントエンドの発信文化ってどんな感じ？12:00〜12:50 Design & Technology について教えて！12:50〜14:00 サイボウズに新卒から入って今までどんな感じだった？14:00〜15:10 フロントエンドのマネージャーって何してるの？15:10〜16:20 Next.js をプロダクトに導入してみてどうだった？16:20〜17:00 フロントエンドの横断支援って何してる？17:00〜18:00 TPAC 参加してみてどうだった？18:00〜19:10 kintone のフロントエンド開発ってどうなってるん？会話して下さった方々にはステッカーやアクキー、付箋などのノベルティを配布していました。ブースのノベルティたちの様子フロントエンドの発信文化ってどんな感じ？フロントエンドの発信文化について、Sajiさんとmugiさんとnus3が話しました。左からSajiさん、mugiさん、nus3フロントエンドエキスパートチームの話や発信のモチベーションの話、「記事や動画配信だけだと一方向だけど、勉強会やカンファレンスだと

品質保証支援部の徳永です。不具合情報公開サイト（社外向けに不具合情報を公開するWebサービス）を、kintoneとWordPressを組み合わせて構築・運用しています。さらに、Amazon Bedrockを活用することで、生成AIによる記事作成の自動化・効率化を実現し、よりスムーズな情報公開を可能にしました。本記事では、特に生成AIを活用した機能の実装内容と、技術的な工夫についてご紹介します。システム構成の概要kintone：情報の入力・管理を行うノーコードツールWordPress：社外向けに情報を公開するCMSAmazon Bedrock：生成AI（LLM）をAPI経由で利用できるクラウドサービス連携方式： kintone（アプリ1） 実装した生成AI機能の概要今回実装したのは、以下のような処理を行う機能です。不具合情報を管理する kintone（アプリ1） に登録されている、英語の情報を取得Amazon Bedrockを通じて、特定の記法に沿った日本語文章を生成生成された文章を、公開情報作成用のkinotneアプリ（アプリ2）に登録技術的な工夫ポイント1. プロンプト設計の工夫生成AIの出力品質を左右するのは、プロンプトの設計です。今回は以下のような工夫を行いました。翻訳ルールの明示：製品内の文言は辞書的に登録を行い翻訳を指示。文体も統一。記法の明示：出力のフォーマットを定義し、タイトルの書き方・箇条書き・情報の書き分けなどを明確に指示。プロンプトは全体で2500字程度、作業は3ステップに分けて指示を行います。2. モデル選定複数のLLM（GPT-4.1、GPT-4 Turbo、Gemini 2.5 Flashなど）の出力を比較し、今回はClaude Sonnet 4.5を採用しました。理由は以下の通りです。長文処理に強く、文脈保持力が高い出力の安定性が高く、指示した記法からの崩れが少ない日本語の自然さが他モデルより優れていた比較した各LLMについては、次のような評価でした。GPT-4.1：プロンプトに沿った記法反映に難ありGPT-4 Turbo：日本語として違和感のある表現が気になるGemini 2.5 Flash：日本語として違和感のある表現が気になる3. シンク機能への組み込み不具合情報を管理するkintoneアプリ（アプリ1）から、公開情報作成用のkin

こんにちは、サイボウズのhokatomo(@tomoko_and)です。2025年11月14日（金）、15日（土）に開催される YAPC::Fukuoka 2025 に、サイボウズはゴールド＆学生支援スポンサーとして協賛します！yapcjapan.orgYAPC::Fukuoka 2025とはYAPC（Yet Another Perl Conference）は、Perlを軸としながらも特定の言語にとらわれず、ITに関するさまざまな技術について語り合う技術カンファレンスです。YAPC::Fukuoka 2017 HAKATA 以来の7年ぶりです👏サイボウズが YAPC Fukuoka::2025 に協賛する想いサイボウズは福岡にも開発拠点を構えており、今回の YAPC Fukuoka::2025 の実行委員長である びきニキさん（@BkNkbot） はサイボウズの福岡拠点に所属しています。そのため、YAPC Fukuoka::2025 を応援したい！ という気持ち地元・福岡で開催される技術イベントはエンジニア同士の交流の場であり、そこを大切にしたいという想いがあります。当日は、福岡拠点のメンバーを中心にサイボウズのエンジニアも参加します！11月14日 企画LTに弊社エンジニアの tasshi（@tasshi_me） が登壇します！Track Aで18:35から「プロダクトにも、チームにも。サイボウズがAIと共に歩む理由」というタイトルでお話します。ぜひお越しください！fortee.jp11月15日の学生の皆さんとのランチ企画に、サイボウズメンバーが参加しますサイボウズからは1名参加予定です。それでは、YAPC::Fukuoka2025 で皆さんとお会いできることを楽しみにしています👋

こんにちは。Androidエンジニアの向井田(@mr_mkeeda)です。先日2025年11月1日に、Kotlin Fest 2025が開催されました。Kotlin Festは「Kotlinを愛でる」をコンセプトにしたエンジニア向けのカンファレンスイベントです。2025.kotlinfest.devサイボウズは去年に引き続き、スポンサーとして協賛させていただきました。blog.cybozu.ioサイボウズブースの様子ブース内容サイボウズブースでは、2つのコンテンツを用意しました。cybozu.comのアーキテクチャ外観図Kotlinのアンケートパネルサイボウズ製品のアーキテクチャ外観図サイボウズが提供するクラウドサービス（cybozu.com）では、Androidアプリだけでなくバックエンドの一部にもKotlinを使用しています。そこで、製品全体の技術構成がざっくりと分かるアーキテクチャ外観図を用意して、Kotlinが使用されている箇所が分かるようにしました。サイボウズ製品のアーキテクチャ外観図実は、去年はAndroidアプリ開発のネタだけでブースコンテンツを作っていたので、ブースに来てくださったバックエンドエンジニアの方とはあまり深いお話ができないという反省点がありました。サイボウズにはAndroidアプリ以外にもKotlinを活用しているチームがあったため、今年はバックエンドエンジニアの社員にもお声がけをして、一緒にブース出展をしてみました。結果は大成功で、「サイボウズ、バックエンドでもKotlin使ってたんだ」といった声や、「Androidでもバックエンドでも技術課題の向き合い方は同じだね」といった職能の垣根を超えた交流もできました。Kotlinのアンケートパネルブースに来てくださった方とKotlinの技術的なお話で交流するための仕掛けとして、アンケートパネルを用意しました。付箋に質問の回答を書いてもらって、その内容についてお話しました。質問内容は2つ用意しましたKotlinを導入してチームはどう変わりましたか？Kotlinで工夫している点はなんですか？Kotlinのアンケートパネルアンケートパネルは何度か別のイベントでもやっている企画ですが、今回はKotlin Festの小鳥のキャラクターに因んで小鳥の付箋に書いていただきました。たくさん小鳥を集めてブース映

クラウド基盤本部のPlatformチームの昆野です。私たちPlatformチームでは、サイボウズが提供するクラウドサービス「cybozu.com」が安定稼働するためのプラットフォームの開発/運用に取り組んでいます。今回の記事では、私たちのチームがプラットフォームの安定稼働に向けて取り組んでいる内容をご紹介します。ただし、私たちの取り組みは多岐にわたっており、すべての取り組みを説明するのは難しいため、今回はこれまでに取り組んできた「リソースの収容効率を改善するためのアーキテクチャ改修」について、重点的にご紹介します。cybozu.comについてまず、cybozu.comとはどのようなサービスであり、またその内部構成がどのようになっているのかについて説明します。サービス概要私たちが提供している「cybozu.com」について、簡単に説明します。cybozu.comではkintoneやGaroon、Office、Mailwiseといったアプリケーションをサービスとしてお客様に提供しています。お客様はcybozu.comのサービスを利用するにあたり、cybozu.com Storeを通じて利用申し込みを行います。この時、お客様は自身でサービスへアクセスする際に使用するサブドメイン（「（指定したサブドメイン）.cybozu.com」でサービスにアクセスできるようになります）を指定します。cybozu.com側ではこの申し込みを受理すると、バックエンドのシステムで各サービスのセットアップ（ミドルウェアの初期化など）を行い、サービスを利用可能な状態にします。すべてのサービスのセットアップが完了するとその旨がお客様にメールで通知され、通知を受け取ったお客様は事前に指定したサブドメインを使用してサービスにアクセスできるようになります。システム構成cybozu.comでは複数のアプリケーションをサービスとして提供していることを説明しましたが、各製品のアプリケーションサーバ（AP）単体でサービスを提供することはできません。cybozu.comのクラウド基盤上にはAPの他にデータベース（DB）やElasticsearchなどのミドルウェアコンポーネントが稼働しており、各サービスはAPとこれらのミドルウェアが協働することによって利用できるようになります。各製品のAPや各種ミドルウェアなど、サ

こんにちは！開発本部 組織支援部People Experiendeチームの貴島（@jnkykn）です。2025/10/05 東京オフィスで、Cybozu Tech Meetup#23 EMが直面する課題を赤裸々に語り合う会を開催しました。この記事では、当日の様子をご紹介します。Cybozu Tech Meetup#23 EMが直面する課題を赤裸々に語り合う会Cybozu Tech Meetupは、サイボウズが主催する技術系のMeetupです。回ごとに異なるテーマで、開催しています。23回目の今回は、サイボウズのエンジニアリング組織の課題とその向き合い方を一例に、組織課題について語り合う会として企画しました。開催当日は、20名を超えるご参加がありました。当日の様子パネルディスカッションの様子まず最初に、パネルディスカッションで、開発本部 kintoneプラットフォーム副本部の3名が、組織の課題と、どのように取り組んできたか？についてお話しました。kintoneプラットフォーム副本部 副本部長の水戸さんからは、エンジニアリングマネージャー（EM）を置くことになった背景（事業、製品、組織、技術）や、EMに期待していること、kintone EMの役割に幅があり、2パターン作ることで間口を広げていることについて説明がありました。この、2パターンのEMというのは、「理想・業務マネジメント」を担うEMと「理想・業務・組織・人材・投資マネジメント」を担うEMです。kintone EMの業務詳細については、以下のスライドをご覧ください。www.docswell.com池田さんからは、生成AIチーム立ち上げの話、マネジメントにどんなやりがいを感じているか？AI機能基盤開発チームEMの立山さんからは、池田さんが立ち上げた生成AIチームを引き継いだ直後の大変さ（EM何をすればいいの状態、販売サイドの要求の調整など）と、それを乗り越えた現在のやりがいについて発言がありました。会場には現役のEMやCTOの方が多く、一般的なマネジメントの課題についてサイボウズがどう取り組んでいるかにご興味がある様子でした。また、マネージャー採用に取り組んでいらっしゃる人事系の方からは、マネージャーをどのように魅力づけするのかを意識したご質問がありました。パネルディスカッションのあとの交流タイムでは、マネージャー

こんにちは！ OfficeMobileチームで QAエンジニアをしている小竹です。サイボウズは、2025年10月24日（金）に開催されたソフトウェアテストのシンポジウム JaSST'25 Kyushu にスポンサーとして協賛しました。 弊社のセッションにご参加下さった皆様、本当にありがとうございました！この記事では、 JaSST'25 Kyushu におけるサイボウズの発表内容と資料を共有いたします。また、 JaSST'25 Kyushu の前日に福岡天神にて開催されたイベントの様子も、あわせて紹介させていただきます。今回はスポンサーセッションに1名が登壇しました。不具合の先にある面白さ～配属3か月目の新卒QAのいま～ speakerdeck.com新卒一年目のQAエンジニア・タバ （@QA_tabu5）が、入社後に抱いたQA業務に関するイメージやギャップ、日頃の業務を経て感じた仕事の「おもしろさ」についてお話ししました。発表を聞いてくださった皆様、ありがとうございました！登壇者からのコメント登壇を通して、改めてQAに対する自分の考えを整理することができました。発表後には多くの方から感想やアドバイスをいただき、QAという仕事の奥深さと広がりを実感しています。また、今回の発表をきっかけに新しいつながりが生まれたことも、とてもうれしく感じています！これからも日々の学びを自分なりに発信しながら、QAとして成長していきたいと思います。【ご報告】テスト中に考えていることを話す会@福岡天神テスト中に考えていることを話す会@福岡天神 登壇の様子前日開催したイベント「テスト中に考えていることを話す会@福岡天神 」では、普段テストに携わっている福岡にゆかりのある3人がテストについて話しました。当社からは斉藤 裕希（@yuuki_cybozuQA）が登壇し、「製品愛をもってテストする」をテーマに、テスト中に考えていること・やっていることを赤裸々に語りました。テスト実施フェーズにフォーカスした勉強会の開催は弊社としてはあまり経験がなく、有意義な機会になったと思っています。ご多忙の中14名もの方にご来場いただき、とても楽しい勉強会となりました！この場を借りて参加者の皆様にお礼を申し上げます。終わりに全国から大勢の参加者が集まる JaSST Tokyo も楽しいですが、今回の九州を始め各地域

この記事は、CYBOZU SUMMER BLOG FES '25の記事です。こんにちは、PSIRTの大塚です。 サイボウズでは、セキュリティチャンピオンという施策を始めました。本ブログでは、セキュリティチャンピオンが目指す世界と現時点での体制、効果を紹介します。PSIRTとは今回の内容は、前提としてPSIRTの役割が重要になるため、あらためて簡単に紹介します。詳細は「Cy-PSIRTが行っている製品開発におけるセキュリティ支援についての紹介」をご覧ください。PSIRTはProduct Security Incident Response Teamの略で、その名のとおり「プロダクトセキュリティ」を担当し、サイボウズが開発するプロダクトのセキュリティ品質向上を目指すチームです。Purposeは次の2つです。ユーザーに「安全にサイボウズ製品を使える」と言ってもらえる状態をつくる開発チームに「セキュリティ品質に自信を持ってリリースできる」と言ってもらえる状態をつくるセキュリティを高めれば高めるほど上記2つは達成できるかもしれません。しかし、それでリリースが遅れたらどうでしょうか。またユーザーにとって使いにくいプロダクトになったらどうでしょうか。これらのPurposeを達成するやり方はたくさんありますが、最終的なユーザーへの価値を最大化させるのがプロダクトセキュリティの重要な考え方だと思っています。今回紹介するセキュリティチャンピオンはこれらのPurposeをユーザーへの価値を最大化させながら達成するための取り組みです。セキュリティチャンピオンとはセキュリティチャンピオンは、一連の「仕組み」の名前であり、同時にその仕組みに参画し、実際に活動する「メンバー」を指します。サイボウズでは、セキュリティチャンピオンを「開発チームにおけるセキュリティの連携窓口」かつ「開発チーム視点で必要なセキュリティ活動を、PSIRTや他チームと連携しながら推進する」メンバーと定義しています。「これまで開発チームとPSIRTは連携していなかったのか？」というと、そうではありません。セキュリティチャンピオン自体は新しい活動ではなく、これまでの取り組みを整理し、連携経路を明確化することでPSIRTや他チームの支援を受けやすくするための仕組み化です。核となる要素は次の2点です。開発チーム視点で *1」を見極

この記事は、CYBOZU SUMMER BLOG FES '25 の記事です。こんにちは、クラウド基盤本部の伴野です。クラウド基盤本部では cybozu.com を稼働させるため、Neco と呼ばれる Kubernetes クラスタを当社で調達した機材上に構築しています。この記事では、そんなクラスタ上のストレージが正しく動作していることを確認するために開発した pie というソフトウェアについて紹介します。背景私はクラウド基盤本部の中でも CSA（Cloud Storage Agency）というチームに属しています。CSA は「cybozu.com にスケーラブルで信頼性のあるストレージを提供する」というミッションのもと、Neco 上のストレージに関わる開発や運用を担当するチームです。具体的には、Rook/Ceph や TopoLVM といったソフトウェアを Neco 上で運用し、cybozu.com に必要なストレージを提供しています。ストレージシステムの詳細に関しては、直近に筆者が書いた別の記事がありますので、そちらをご覧ください：blog.cybozu.ioさて CSA が提供しているストレージは様々な原因で故障することが想定されます。例えばディスクやノードの故障といったハードウェア的な不具合はもちろん、ソフトウェアのバグによって使用できなくなることもあり得ます。CSA は、ストレージを利用してアプリケーションを運用するチームに対して、ひいてはお客様に対して、ストレージが（一定の範囲で）いつでも利用可能であることを約束しているため、このような不具合が発生した場合は速やかにその原因を特定し、適切に復旧しなければなりません。そのために CSA では、ストレージに関するメトリクスを監視するアラートルールを設定し、不具合に迅速に対応できるようにしています。ただストレージを運用していく中で、大きく分けて二つの点から、既存のメトリクスだけでは不十分な面があることが分かってきました。まず第一に、Kubernetes におけるストレージの取り扱いは複雑で、多くの要素から構成されるという点です。その結果、ストレージを構成する各コンポーネントからメトリクスは出力されるものの、それらをバラバラに監視するだけではストレージ全体として正しく動いていることを保証することが難しくなっていま

この記事は、CYBOZU SUMMER BLOG FES '25の記事です。はじめにこんにちは！kintone開発チームの河上（ @shaba_dev ）です。普段はプロダクトエンジニアとして活動していますが、キャリア採用業務も兼務しており、今回はそちらの話になります。2025年11月現在、kintone開発チームは新しい仲間を募集していますが、そもそも「サイボウズって今どんなことにチャレンジしているの？」「求められている経験がわからない」といったことがわからずに躊躇っている方もいらっしゃるかと思います。そこで今回は、今kintone開発チームでチャレンジしていることや、こういう経験やマインドを持っている方と一緒に働きたいという内容を紹介します。チャレンジしていることkintone開発チームでチャレンジしていることは本当に多岐にわたりますが、ここでは一例として3つ挙げます。Agent方式による外部システムのkintoneアプリ化機能従来のkintoneでは、kintone内のデータしか扱えませんでしたが、外部システム（基幹システム、データウェアハウス等）のデータを直接kintoneアプリのデータソースとして活用できるようになりました。この機能により、利用者は従来のkintoneアプリと同じ操作感で外部システムのデータを扱えるようになり、「kintoneの『外』にある業務やデータまで巻き込んだ業務改善」という新たな領域に挑戦しています。例えば、ERPシステムの売上データやCRMの顧客情報を、kintoneの使いやすいインターフェースで操作・分析できるようになり、より幅広い業務プロセスの改善が可能になります。外部システムとの接続では、セキュリティ要件を満たしつつ、複数のシステム間を跨いでデータを統合する大規模な機能設計が求められるため、認証・認可やアクセス制御の実装経験を活かした堅牢な仕組み作りが不可欠となっています。生成AIを活用した新機能生成AIは現在kintoneで最も注力している機能の一つです。私たちはkintone AIラボとして、チャットでAIに質問するとkintoneアプリに登録されたデータから適切な回答を検索する機能AIと会話をしながらアプリを作成する機能業務フローの説明をチャットで伝えることで適切なワークフロープロセスを提案・設定する機能など、様々なA

この記事は、CYBOZU SUMMER BLOG FES '25の記事です。CloudPlatform部のpddgです。gRPCは高性能・高機能なRPCフレームワークであり、サイボウズではバックエンドサービス間での通信に広く利用されています。gRPCの実際の通信はChannelという仕組みによって抽象化されて管理されており、デフォルトでは最初に接続した単一のサーバのみと通信します。これにより、少数の高負荷をかけるクライアントが存在すると、そのクライアントが接続したサーバに負荷が集中してしまいます。gRPCはクライアント側で接続するサーバを選択するロードバランシング機能を備えており、これを利用することで負荷の偏りを軽減できます。本記事では、gRPCのクライアントサイドロードバランシングの導入方法や注意点について解説します。説明にはgRPC-Goを用いますが、他の言語のgRPC実装でも同様の機能が提供されています。背景gRPCはクライアントとサーバの通信をChannelという仕組みで抽象化しています*1。通常、gRPCクライアントを作成する際、接続先のアドレスを渡すと（必要ならば名前解決して）そのアドレス一つに対してChannelを作成して接続します。このとき、一度作成されたTCPコネクションはデフォルトでは切断されるまで維持されます。つまり、gRPCクライアントは単一のエンドポイントに対して一度接続し、その接続が切断されるまで一つのChannelを使い続けることになります。これにより（gRPCのロードバランシングに対応したL7ロードバランサを実際に用意したりしない限り）バックエンドのgRPCサーバを何台用意しても、あるgRPCクライアントが発行するRPCは単一のサーバに集中してしまいます。サイボウズではgRPCで通信するサービス間にサービスメッシュなどは導入しておらず、現状素のgRPCクライアントとgRPCサーバが直接通信するケースがほとんどです。これにより、多数のRPCを行う少数のクライアントが存在する場合に、gRPCサーバの負荷がPodごとに大きく偏り、99パーセンタイルのレイテンシが悪化するなどの問題が発生していました。gRPCのクライアントサイドロードバランシング通常、Webサーバへの負荷分散はクライアント側ではなくサーバ側で行われることが多いでしょう。L4

はじめに： MagicPod を使った、E2E の継続運用をふりかえってこんにちは。サイボウズ Office の iOS 製品 の QA の玉木( gkzz )です。本記事では、E2E 自動テストの SaaS のひとつである MagicPod を使い始めてから3年目に突入したので運用の経験をご共有できればと思います。特に以下のようなお悩みを抱えている方に向けて、本記事が一助となればうれしいです。E2Eテストを自動化したいけれど運用で苦労しているモバイルアプリの回帰試験の負担軽減の取り組みがなかなか続かないMagicPod の現場運用事例を知りたい第三者目線に立ってのふりかえりある自動テストツールを導入してみたというお話はちらほら見かけますが、その後の後日談、とりわけ苦労話はあまり見かけません。私や私が所属するチームでも E2E の自動テストとの向き合い方にとても試行錯誤しました。そこで、この記事では第三者目線で MagicPod というE2E の自動テストツールを運用してきたことのふりかえりとして書いていきます。（ふりかえりをしたからといって、MagicPod の運用をやめるというわけではなく、今後もガシガシ使っていくつもりです。念のため。）本記事のスコープとこれまでの経緯最初に、本記事のスコープをお伝えさせてください。MagicPod を用いたモバイルアプリの E2E 自動テストの「運用体制の構築」と「継続運用」における実践的な工夫・課題共有チームでテスト自動化運用を進める際の、知見・ノウハウ・改善サイクル運用フェーズで発生する具体的な悩み（属人化・テストの不安定さ・工数分散など）とその対応策MagicPod の現場運用を2年間続けてきた経験から得られた学びや今後の展望続いて、これまでの経緯についてもかんたんにご紹介させてください。冒頭で少し触れたように、私たちのチームでは2年前に Magic Pod を導入し、以後継続して自動テストの運用に取り組んでいます。 ※導入期の取り組みについては下記の資料で詳しく説明していますので、あわせてご覧ください。MagicPodで始めるがんばらない回帰試験の自動化​/Automated Regression Testing Journey with MagicPod​ - Speaker Deck導入当初は私が専任で自動テストの