こんにちは、フロントエンドエンジニアのおぐえもん（@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導入当初は私が専任で自動テストの

この記事は、CYBOZU SUMMER BLOG FES '25の記事です。こんにちは！サイボウズでQAエンジニアをしている Trabbie(@QA_tabu5)です！この記事では、私が入社前に持っていた理想と入社から半年が経って感じた現実についてお話します。サイボウズのQAエンジニアに興味があるけど、「どんなことをやっているかいまいちイメージが湧かない」と感じている方の参考になれば嬉しいです。注意チームによって業務内容が大きく変わるので、あくまでも参考までに読んでいただければと思います。わかりやすさを重視しているため、言葉の定義が若干異なるところがあります。ご了承ください。入社から配属までの流れは同期がわかりやすい記事「未経験25卒QAエンジニアがチームで業務を担当するまで」を書いているのでそちらをご覧ください目次はじめにそもそもQAエンジニアとは？なぜQAエンジニアに？自分の入社前の理想と実際1. サービスの品質を支えたい（１）テスト活動（２）バグを作りこまないようにする活動2. ユーザーの方に近い距離でサービスを支えたい（１）ユーザーフィードバック（２）自身がユーザーになれること成長を後押しするサイボウズの環境1. 研修の充実2. 挑戦ができる環境3. ザツダン文化が支える心理的安全性おわりにはじめに著者の背景が分からないと内容がわかりにくいかもしれないので、軽く自己紹介をしておきます。私は、2025年に新卒で入社をしてQAエンジニアとして働いております。そもそもQAエンジニアとは？「QAエンジニア」という職種を聞いたことがある人は少ないのではないでしょうか。私自身も入社前は具体的なイメージを持てていませんでした。QAとは、Quality Assurance（品質保証）の略です。つまり、QAエンジニアとは、品質保証をする（製品・サービスの品質を守る）職種です。QAエンジニアの業務の中で、一番イメージしやすいのが「テスト」だと思います。テストでは、開発されたソフトウェアを実際に動かし、不具合を見つけたり、期待通りに動作しているかを確認したりします。サイボウズでは、テスト以外にも多角的に品質に関わることができます。詳しくは「（２）バグを作りこまないようにする活動」で記載します。サイボウズのQAエンジニアについて、より知りたい方は、以下の【サイボウズ インターンシッ

この記事は、CYBOZU SUMMER BLOG FES '25の記事です。こんにちは、25新卒フロントエンドエンジニアのmehm8128（めふも）です。サイボウズでは現在、フロントエンド刷新プロジェクトとしてkintoneをGoogle Closure ToolsというフレームワークからReactに移行しています。詳しくは以下の記事をご覧ください。blog.cybozu.io僕はその中でも、kintoneのアプリに関連する画面のReact化を行っている、「ババロア」チームに所属しています。アプリではレコードを作成でき、以下のようにレコードの情報を編集したり閲覧したりできます。レコード一覧画面レコード編集画面この記事では、ババロアチームでReact化を行うにあたり実装していたインテグレーションテスト（以下integテスト）の書き方を改善したケースを例にとり、kintoneアプリ領域のフロントエンド刷新について紹介します。kintoneアプリ領域で扱う巨大データkintoneのアプリ領域では前述のように、アプリごとに設定されているフォームに情報を入力し、それを閲覧・編集できるようになっています。フォームスキーマgetFormSchemaという関数で、バックエンドからフォームのスキーマを取得することができます。これは、以下のような形式になっています。vi.spyOn(cybozuData, 'getFormSchema').mockReturnValue({ groups: [], table: { fieldList: { '2000': { id: '2000', label: '文字列（1行）', var: '文字列__1行_', type: 'SINGLE_LINE_TEXT', properties: { noLabel: 'false', required: 'false', defaultValue: '', expression: '', hideExpression: 'false', max: null, min: null, unique: 'false' } }, ...（同様に他のフィールドが羅列される） } } });fieldListの中に各フィールドのデータが羅列されています。これはフィールドの分だけ詰め込まれていて、kintoneのフォ

この記事は、CYBOZU SUMMER BLOG FES '25の記事です。クラウド基盤本部の新井です。この記事では、DB へのアクセスを伴う Go の単体テストについての私たちの考え方、そしてそれを実践するために開発・公開したライブラリをご紹介します。DB のモックとその問題点DB へのアクセスを伴う Go のプログラムをどのように単体テストしたいとき、最初に思いつくのは go-sqlmock などのツールを使って DB をモックする方法です。サンプルコードでは、次のようなテストを書いています。package mainimport ( "fmt" "testing" "github.com/DATA-DOG/go-sqlmock")// a successful casefunc TestShouldUpdateStats(t *testing.T) { db, mock, err := sqlmock.New() if err != nil { t.Fatalf("an error '%s' was not expected when opening a stub database connection", err) } defer db.Close() mock.ExpectBegin() mock.ExpectExec("UPDATE products").WillReturnResult(sqlmock.NewResult(1, 1)) mock.ExpectExec("INSERT INTO product_viewers").WithArgs(2, 3).WillReturnResult(sqlmock.NewResult(1, 1)) mock.ExpectCommit() // now we execute our method if err = recordStats(db, 2, 3); err != nil { t.Errorf("error was not expected while updating stats: %s", err) } // we make sure that all expectations were met if err := mock.ExpectationsWereMet(); err != nil { t.E

こんにちは、新卒フロントエンドエンジニアのmehm8128（めふも）です。10/23（木）に、弊社東京オフィスにてNihonbashi.js #10を開催したのでその開催レポートです。nihonbashi-js.connpass.comNihonbashi.jsとはNihonbashi.jsとは、JavaScriptが好きな人たちが日本橋周辺で集まる勉強会です。会場の様子本レポートでは、LTや懇親会の様子を紹介します。intro弊社Sajiさんから、Nihonbashi.jsについての説明や会場についての注意事項、サイボウズのフロントエンドについての紹介がありました。SajiさんLT7名によるLTが行われました。各LTのスライドはconnpassのページからご覧ください。「ChromeDevTools(MCP) を活用したフロントエンド開発」by くらっちさん（会場提供枠）くらっちさんChrome DevTools MCPを活用してChromeの操作する方法についてのLTでした。「大モジュラーモノリスのテスト戦略」by ShinyaigeekさんShinyaigeekさんUbieにおけるモジュラーモノリスの選定理由・モジュラーモノリスであることによる自動テスト実行における課題についてのLTでした。「JSConf JP の website を Gatsby から Next.js に移行した話 - Next.js の多言語静的サイトと課題」by れこさんれこさんJSConf JPのWebサイトを、レガシー化していたGatsbyからNext.jsに移行した話のLTでした。「フロントエンドカンファレンスの Web サイトをどう作るか」by ken7253さんkenさんフロントエンドカンファレンス東京のWebサイトを作ったときの工夫についてのLTでした。「React Native in 2025」by NaturalclarさんNaturalclarさんReact Nativeが今年で10周年になったことを受け、React Nativeの利点や課題についてのLTでした。「pnpm に provenance のダウングレードを検出する PR を出してみた」by まっつーさんまっつーさんnpmのサプライチェーン攻撃を受けて、リリースが作られたときの情報を検証可能なProvenan

こんにちは。kintone 開発チームでプロダクトエンジニアをしているぶっちーです。概要Webアプリケーション開発コースでは、8 月と 9 月で各 10 日ずつ開催し、計 5 名の方に参加いただきました。インターンのコンテンツについて10 日間の大まかなスケジュールは以下の通りです。サマーインターンのスケジュールオンボーディング最初の 3 日間はオンボーディング期間として、以下の内容に取り組んでいただきました。kintone 開発チームの構成・開発プロセスのインプットオンボーディングコンテンツを使用した kintone コードベースの基本知識のインプットこれらを通して、実際にチームにジョインするにあたって必要な知識や技術などを吸収していただきました。チーム開発オンボーディングコンテンツが終わった後は、実際に開発チームにジョインいただいて、メンバーの一員として開発タスクに取り組んでいただきました。ペアプログラミング・モブプログラミングを活用して、社員と一緒に議論しながら開発を進めました。blog.cybozu.ioまた、kintone 開発チームはスクラム開発を採用しており、1 スプリントの中でさまざまなスクラムイベントが開催されます。それらほぼ全てのイベントにもチームメンバーと一緒に参加いただき、kintone 開発チームのメンバーとしての働き方を体験いただきました。スケジュールにある「探求時間」についても社員同様の体験をしていただきました。探求時間とは、主な開発業務以外にエンジニアが自由に使える時間で、以下のような活動を行います。興味のある新技術の学習勉強会の開催・参加開発業務中に生じた疑問点のキャッチアップ改善活動参加いただいた皆さんもこの時間を活用し、kintone に関する ADR を読み込んだり、社内公開されている学習コンテンツに取り組んだり、過去のプロジェクトについて調査したりと、ご自身の興味に合わせて有意義に過ごしていただきました。その他イベントその他にも、社員による「アクセシビリティ勉強会」であったり、インターン生の方の希望をお聞きして社員を招いてのざつだんなども行いました。これらを通して、社内の雰囲気であったり情報を知っていただけました。エンジニアリングマネージャー生産性向上チームのメンバーフロントエンド刷新を行っているメンバー情報のキャッチアップ

この記事は、CYBOZU SUMMER BLOG FES '25の記事です。こんにちは。terassyi)です。Neco では Cilium を Kubernetes ネットワークに採用しています。www.cncf.io本記事では Cilium の通信制御のコアである Cilium の Connection Tracking の挙動と実装について解説するものです。前書きCilium は eBPF をパケット処理などに採用したコンテナネットワークを管理するソフトウェアです。Cilium は高速な Kubernetes ネットワークを提供するため、kube-proxy 代替機能や Connection Tracking を eBPF ベースで独自に実装しています。本記事は大きく以下の三つのパートから構成されます。Cilium の紹介Cilium の conntrack の理解に必要な要素の解説Conntrack の一般的な解説Cilium が管理する Kubernetes ネットワークの概要Cilium の BPF プログラムや BPF マップの概要Cilium の conntrack の挙動と実装の解説※ 本記事は、 Cilium 1.16.12 のコードをもとに執筆します。Cilium は開発スピードが非常に早いソフトウェアです。本記事で解説した挙動が、新しいバージョンでは修正されている可能性があることに注意してください。目次前書き目次Cilium とはCNI プラグインeBPFNeco での Cilium の活用例Deep Dive の準備Connection Tracking とはLinux の ConntrackCilium が管理する Kubernetes ネットワークPod 間通信ClusterIP Service の通信LoadBalancer Service の通信externalTrafficPolicy=ClusterexternalTrafficPolicy=LocalNodePort Service の通信Cilium の BPF プログラムとマップの概要Cilium Connection Tracking Deep Dive概要CT mapBPF マップの定義キー構造体（ipv4_ct_tuple）バリュー構造体（ct_entry）Pod 間

この記事は、CYBOZU SUMMER BLOG FES '25の記事です。こんにちは！クラウド基盤本部 PDX（Platform Developer Experience）チームのびきニキ（@BkNkbot）です。今回は連載「サイボウズのKubernetesプラットフォームを支えるOSS」の3回目として、ソフトマルチテナンシー環境でテナント管理を行うKubernetesコントローラーの「Accurate」について紹介します。サイボウズのKubernetesクラスタの現状サイボウズでは1つのKubernetesクラスタを複数のテナント（Kubernetesクラスターリソースへのアクセス権を持つ開発チームの集まり）で共有しています。この共有のやり方には種類がいくつかあるので、まずは本題に入る前に弊社の現状を紹介します。マルチテナンシー複数のユーザーが同じサーバーやアプリケーションなどのシステムやサービスを共有して使う方式をマルチテナンシーと呼びます。この記事においては、1つのKubernetesクラスターを複数のテナントで共有することを指しています。マルチテナンシーモデルマルチテナンシーには大きく2つの形があります。ソフトマルチテナンシー: 1つのclusterを共有し、Namespace, RBAC, NetworkPolicy, ResourceQuota, Pod Securityなどの設定で論理的に隔離する方式。ハードマルチテナンシー: clusterやControl Planeを分離（例：クラスタ単位の分割、kube-apiserver等の仮想クラスタ、専用ノード / ネットワーク）し、強い境界を持たせる方式。サイボウズでは、ソフトマルチテナンシーを採用しています。AccurateとはAccurateは、大規模なマルチテナンシー環境の運用支援をするKubernetesコントローラーです。Kubernetes上でNamespaceに親子関係を持たせ、親Namespaceから子Namespaceへリソースやラベル、アノテーションを正確に継承・伝搬させることができます。Accurateでは、テナントユーザー自身が子Namespaceの作成・削除を実行できるように、専用のカスタムリソースとkubectlプラグインを提供しています。あるNamespaceを「親」とし、