Cloud Platform部の萩原です。Cloud Platform部では、Cybozuのクラウドサービス「cybozu.com」の提供基盤をVMベースの旧基盤からKubernetesベースの新基盤（Neco）へ移行するミッションに取り組んでいます。現在は、Cybozuのセッションストアとして旧基盤上にホストされているMemcached互換のKVSを、新基盤に移行するプロジェクトに取り組んでいるところです。本記事では、新規実装されたKVSと旧実装の互換性の問題を、Fuzzingと差分テストを用いることで、個々の操作列を手で列挙する負担を減らしながら検出する方法を紹介します。KVS移行における課題yrmcdsはCybozuがOSSとして公開しているMemcached互換のKVSです。通常のMemcachedの機能に加えてレプリケーションやサーバサイドロックといった拡張機能を提供しています。詳細は以下をご確認ください。blog.cybozu.ioyrmcdsの移行では、ForestとNecoの基盤間の差分を克服しつつ、現行のyrmcdsと同等の振る舞いを実現しなければなりません。しかし、yrmcdsの振る舞いを完全に記述したドキュメントはありません。基本的な振る舞いはMemcachedやyrmcdsのドキュメントにありますが、細かい挙動については記されていません。新しい実装がyrmcdsと同等の振る舞いを実現しているかをどのように確認すればよいでしょうか。仕様を単体テストに書き起こす手法は有効ですが、網羅するのは困難です。細かい挙動を事前に把握しなくても、yrmcdsと新規KVSを機械的に比較して非互換を検出できる方法が望まれます。そこで、本課題をサマーインターンの課題として岡田さんに取り組んでいただきました。岡田さんが採用したのはFuzzingと差分テストを組み合わせたアプローチでした。本記事では、この手法がどのように非互換の検出に役立つのかを紹介します。Fuzzing+差分テストによる非互換検出Fuzzingは、実装に多様な入力を与え、クラッシュや予期しない挙動などを検出する手法です。通常のテストでは、開発者が実装やドキュメントを確認し、入力と期待する結果を考えてテストケースを作成します。Fuzzingでは入力の生成を自動化することで、手作業では思いつきにくい組み

こんにちは！サイボウズの社内コネクトチームのhokatomo(@tomoko_and)です。このチームでは開発系の社内イベント担当しています。最近、私は同僚と歩数対決をしているんですが、歩数を稼ぐために20km以上走ったら、相手も同じくらい走ってきて、もはや泥試合です!!といったように、普段一緒に仕事をしていても、その人が仕事以外で何にハマっているのか、何を「面白い！」と思っているのかは意外と知りません。だったら、そこだけを話すLT会をやってみよう!!!というのが今回の「業務の話禁止」のLT会です。話しながらスシを食べるから = 話スシサイボウズでは社内LTの一部を「話スシ」と呼んでいます。「話スシ」という名前は、以前はLT会で寿司が出ていたことから、「話す」と「寿司」を掛け合わせてつけられと言われています。（実際に寿司が出ていたのは10回に1回くらいだったらしい）ここ数年の「話スシ」では、技術やプロダクト、仕事で得た知見などがテーマになることが多いですが、始まった当初の「話スシ」は仏像、クレジットカード、けん玉など、テーマもかなり多彩だった模様！職能や年次、担当製品に関係なく、いろいろな人が話していました。以前やっていた頃の記事blog.cybozu.ioちなみに今回で129回目！もはやサイボウズ社内用語としてはLT会=話スシ、と定着している印象です。業務の話だけでは生まれない繋がりを作りたい業務ではない話のLT会をしたら、普段とは違う人たちが集まるかもしれない。それを起点に新しい交流も生まれるかも！？と思い、今回企画をしました。なお、今回は寿司ではなく都合によりおにぎりになりました。今回の「話スシ」は、3DプリンタにAIで結婚式準備、ギャルネイルにeスポーツ！発表タイトルを並べるとSwitch2の抽選に外れた腹いせに3Dプリンタを買ったらどハマりして、最終的には結局Switch2も買った話結婚式の準備にGeminiが大活躍した話（2026年版）eスポーツにおけるデータ活用の話10本しかない爪に、どうやってギャルネイルを設計していく？AIと協働するネイルデザインの話WW2 最後の分断国家、韓国🇰🇷と北朝鮮🇰🇵を隔てる軍事境界線（≒DMZ）を見に行こう普段の仕事ではなかなか聞くことのない趣味や体験、個人的にハマっていることなど、多彩！多彩すぎる〜！！！！思っ...

はじめにこんにちは。ログ基盤チームの吉本です。cybozu.com では、2018年のブログ記事でご紹介したログ基盤を長期にわたって運用してきましたが、このたびサイボウズの Kubernetes 基盤である Neco へ移行しました。今回の移行では、旧ログ基盤が抱えていた課題や移行に伴う制約を踏まえ、アーキテクチャを全体的に刷新しています。本記事では、この新しいログ基盤の全貌についてご紹介したいと思います。blog.cybozu.ioはじめにアーキテクチャ刷新のモチベーションNeco に適した構成への見直しログの発生源に関する制約新ログ基盤の全体像ログの収集LogShipper によるログの回収Kafka によるログの一時保存Kafka MirrorMaker 2.0 による Neco へのログ転送新旧ログ基盤の並行運用ログの変換・保存ログの保存先と保存方式保存先：Neco のオブジェクトストレージ保存方式：Apache IcebergKafka Connect による Iceberg テーブルへの書き込みIceberg Sink Connector によるログの加工Iceberg のカタログが担う役割Apache Gravitino によるカタログの提供カタログを介した書き込み側と読み出し側の分離ログの活用Trino によるクエリの実行Redash によるクエリの実行と可視化おわりにアーキテクチャ刷新のモチベーションはじめに述べたとおり、今回の移行では移行に併せてアーキテクチャを刷新しています。その構成を考えるにあたっては、大きく2つの点を踏まえました。ひとつは、旧ログ基盤の構成をそのまま Neco に持ち込むのではなく、Neco が提供する仕組みを活かした構成にしたいと考えたこと。もうひとつは、アクセスログの発生源が cybozu.com の旧基盤である Forest に現在も残っているという制約があることです。ここではそれぞれについてご説明します。Neco に適した構成への見直し旧ログ基盤は、HDFS や Hive といった Hadoop エコシステムの上に構築されていました。HDFS は「データのある場所に計算を寄せた方が効率が良い」という考え方を前提に設計されており、ストレージと計算リソースを同じノードに配置する構成が一般的です。私たちの環境もその構成を採

こんにちは！サイボウズのトニオ（@tonionagauzzi）です。普段はkintone開発チームにてAndroidアプリを主に開発しています。2026年10月6日（火）にサイボウズ株式会社とSTORES株式会社の合同で DroidKaigi × iOSDC After Night をサイボウズ東京オフィスで開催しました。本記事ではその当日の様子をレポートします！cybozu.connpass.com今回のイベントは、DroidKaigiとiOSDCの後にAndroidとiOSのエンジニアが合同で話せる場を作りたいと思い企画しました。ちゃんくろさんのオープニングトークTakahashiさんの会社紹介企画はこの二人、26卒のちゃんくろさん（@ryota1582）とYu Takahashi さん（@yutk_941）を中心に進みました。私は当日の司会と会場準備を担当しました。なお、本イベントはDroidKaigi 2026およびiOSDC Japan 2026の公式イベントではなく、両カンファレンスに協賛しているサイボウズとSTORESが主催したものです。LTの様子まずはLT。ちゃんくろさんが司会を務め、6名の方に発表いただきました。発表順にご紹介します！（ちなみに発表者の名前を呼ぶ際、司会がiOSDC恒例のトークタイトルの読み上げを再現していました）ARKit × RealityKit でミー文字風バーチャルライバーになるKyomeさんの登壇の様子トップバッターはサイボウズのKyomeさん（@Kyomesuke）で、顔の動きを3Dモデルのアバターに反映する仕組みの紹介とデモが行われました。ARKitが顔を読み取り、RealityKitが3Dモデルを描くという、2つのフレームワークの役割分担でアバターが動きます。ARKitはカメラやセンサーから顔や空間を読み取って数値にし、RealityKitはモデルの読み込みやライティング、レンダリングを担う3Dを描きます。ARKit側とモデル側でキー名が一致しないと表情が動かなかったり、ARKitとRealityKitで座標系が異なるので端末のカメラ位置にも合わせないとアバターの向きがずれるそうです。Kyomeさんは、これらを吸収するライブラリとしてFaceAvatarKitを作られています。ARKit と RealityKit の

初めにクラウド基盤本部 NWDC 部 Kubernetes ネットワークチームの寺嶋です。Kubernetes ネットワークチームでは 2026 年 8 月 17 日から 2 週間インターンシップを開催し、2 名の方に参加していただきました。cybozu.co.jp本記事では、インターンシップで白川さん（@KasumiMercury）に担当していただいた「Cilium Conntrack のメトリクス拡張の検証と提案」というテーマの成果を紹介します。もう一方の小野さん（@no2ca）さんに取り組んでいただいた成果は別記事で紹介していますので、そちらもあわせてご覧ください。blog.cybozu.io背景サイボウズでは、Neco というオンプレミスの Kubernetes 基盤を運用しています。Neco ではネットワーク部分に Cilium を採用しています。Cilium は eBPF をデータプレーンに活用した高効率かつ高機能な CNI プラグインです。eBPF は Linux カーネルを安全かつ動的に拡張するための仕組みです。Cilium は様々な機能を提供していますが、我々は主に L4LB やネットワークポリシー、kube-proxy Replacement を利用しています。Neco での Cilium の活用については過去の記事をご覧ください。blog.cybozu.ioCilium は Kubernetes クラスタ内の通信を制御するために Connection Tracking（以下 Conntrack） を実装しています。Conntrack は通信の状態を保存・追跡する機能です。送信元・宛先のアドレスやポート、プロトコルなどの情報とその通信の状態（TCP セッションの状態など）をペアで保存して逐次更新します。Cilium は Conntrack で通信の状態を把握して、負荷分散やネットワークポリシーなどの Kubernetes のネットワークモデルに沿った通信制御を実現しています。そのため、Cilium の Conntrack は非常に重要なコンポーネントであり、クラスタを適切に運用するためには Conntrack の負荷状況を詳細に把握しておく必要があります。現状の Cilium には、Conntrack の負荷状況を知るためのメトリクスがいくつか存

クラウド基盤本部 NWDC 部 Kubernetes ネットワークチームの花田です。この記事では2026年8月にサイボウズで開催していた Kubernetes ネットワークインターンコースにて、インターンの小野さん（@no2ca）に取り組んでいただいた課題とその成果を紹介します。今回小野さんには、Cilium の IP アドレス管理（IPAM）機能の一つである Multi-Pool IPAM が Neco の Kubernetes クラスタでも動作するか検証していただきました。もう一方の白川さん（@KasumiMercury）に取り組んでいただいた成果は別記事で紹介していますので、そちらもあわせてご覧ください。背景サイボウズでは、Neco というオンプレミスの Kubernetes 基盤を運用しています。現在 Neco では、Coil と Cilium という二つの CNI プラグイン を用いて Kubernetes クラスタ内外の通信を実現しています。それぞれの役割は次のとおりです。Coil:Coil はサイボウズが OSS として開発している CNI プラグインで主に以下の二つの役割をになっています。プライマリ CNI として Pod の IPAMKubernetes クラスタ内の Pod からクラスタ外に通信するための NAT (Egress NAT)また、Coil は BGP speaker である BIRD と連携することで、クラスタ内で Pod の IP アドレスを直接用いたルーティングを可能にしています。Coil の詳細に関しては過去にも記事が上げられているので、よければそちらもご覧ください。blog.cybozu.ioCilium:Cilium は CNCF Graduated Project の一つで、eBPF をデータプレーンに活用した CNI プラグインです。Cilium は Service Mesh や IPAM、LoadBalancer などといった幅広い機能を備えていますが、Neco では主に以下の三つの役割を担っています。クラスタ外からクラスタ内に通信するための L4 LoadBalancerクラスタ内外との通信に適用される NetworkPolicyクラスタ内通信の高速な負荷分散 (kube-proxy replacement)cil

替え玉.webの様子こんにちは、フロントエンドエンジニアのおぐえもん（@oguemon_com）です。福岡では、9月12日（土）に「フロントエンドカンファレンス福岡」（FECF 2026）が開催され大いに盛り上がりました。実は、その前日（9月11日（金））の夜、博多駅前にあるサイボウズ福岡オフィスにおいて、FECF 2026のサブイベントとして「替え玉.web」という勉強会を開催していました。今回は、名前だけでは何をやっているか分かりにくい替え玉.webの開催レポートをお届けします。替え玉.webとは？替え玉.webは、「過去の発表の再演が原則」のWebフロントエンド勉強会です。福岡が発祥とされるラーメンの麺だけのおかわり「替え玉」のごとく、美味しかった過去の発表をおかわりするのが趣旨です。詳しくは開催前の記事をご覧ください。開催レポート前述の通り、替え玉.webはサイボウズの福岡オフィスで開催されました。博多駅直結で、12階までエレベーターで上るとオフィスの入り口にすぐ着きます。会場入り口の様子会場である福岡オフィス最大の会議室には「とんこつ」という名前が付けられています。まるで替え玉.webのために作られた部屋のようですね。始まる前は、ラーメン屋の環境音をBGMにして、今にも「替え玉」がやってきそうな雰囲気を演出しました。始まる前の様子19:00ちょうどに開始しました。オープニングトークでは、念のために替え玉とは何かの説明からはじめ、参加者と当勉強会の前提を共有しました。「替え玉」と聞いた時に、ラーメンのおかわりでなく、そこから派生した替え玉受験などの「なりすまし」の意味が真っ先に連想されることも少なくなかったりします。オープニングトークオープニングが終わったら、いよいよ6杯の替え玉（6本の発表）です。1杯目は、Riya Amemiya（@Riya31377928）さん。「V8のTorqueを語りたい」というテーマです。JavaScriptエンジンV8の最適化のためにV8の中でだけ使われているプログラミング言語Torqueについて語られていました。画面に映るエディタにはシンタックスハイライトが全くない無地のTorqueコードが映し出されていましたが、心の眼で色分けを見てプログラミングするそうです。Riya Amemiyaさんの発表2杯目は、Yusaku Miya

こんにちは！kintone 開発チームの Android エンジニア、トニオ（@tonionagauzzi）です。2026年9月1日(火)〜3日(木)にベルサール渋谷ガーデンで開催された DroidKaigi 2026 に、サイボウズはゴールドスポンサーとして参加しました！サイボウズからは、SWE・QA・EM など多様な職種のメンバーが参加しました。この記事では、DroidKaigi 2026 スカラーシッププログラムの一環で実施したサイボウズのオフィスツアーと、会場ブースの様子をレポートします！スカラーシッププログラムのオフィスツアー去年に引き続き、今年も DroidKaigi 2026 1日目のワークショップの裏側で、スカラーシッププログラムに参加する学生の皆さまをサイボウズの東京オフィスにお招きし、オフィスツアーを開催しました！今年のオフィスツアーの様子当日はお弁当を食べながら会社説明や2本の技術LTを実施し、サイボウズのAndroidアプリエンジニア4名を交えて懇親会を開きました。 懇親会では、DroidKaigiの注目セッションや最近気になっている技術の話、社内での働き方や入社理由など多岐にわたる話題で盛り上がり、楽しく親睦を深めることができました。食事の後は東京オフィス内を巡るツアーを実施しました。27階の「サイボウ樹」エリアなど、ユニークな社内環境に参加者の皆さんも楽しんでくださった様子でした。「サイボウ樹」エリア今回のツアーを通じて、サイボウズに少しでも興味を持っていただけたら幸いです！サイボウズブース今年もサイボウズブースを出展しました！メンバーはサイボウズの Android コミュニティTシャツや法被を着用し、来場者のみなさまと交流しました。ブースでは、次の3つの企画をご用意しました。会話が広がる！アンケート企画イーゼルパッドでフリートークブース限定のノベルティ1. アンケート企画事前告知記事で当日のお楽しみとしていたアンケートのお題は、最近、どんな事でチームワークを感じましたか？でした！みなさまとお話ししながらたくさんの回答をいただきました。集計・分析結果せっかくなので、集まった回答をカテゴリに分類して集計してみました！最も多かったカテゴリは困っている時の助け合いで、次いで多かったのが合宿・ランチなどの交流イベント、その次がリリース・成果達成の

こんにちは、フロントエンドエンジニアのmehm8128です。2026年9月12日（土）に行われたフロントエンドカンファレンス福岡にて、サイボウズはゴールドスポンサーとして協賛しました。当日の様子を紹介します。ブースTSKaigiのときと同様、「サイボウズ エンジニア社員が何でも話します！！」というテーマでブースを出展していました。blog.cybozu.io開場前のブースの様子ブースのイーゼルパッド予め貼ってある付箋の中から気になったトピックについて質問してもらうか、全く関係ないことでも何でも聞いてもらい、社員が答えるという形式でした。ブースの様子トピックとしては、OSS寄付や、Frontend Monthlyやサイフロ通信、Zennの記事など発信の話、「AIでフロントエンドエンジニアはどうなるのか？」という話などで盛り上がっていました。フロントエンドに直接関係ないものだと、サイボウズの社内イベントに興味を持ってくれる人も多かったです。また、今回は「応援メッセージを下さい」というコーナーも設けていました。漠然としていて何を書けばいいかよく分からないコーナーではありましたが、「Zenn読んでいます！」や「サイフロ通信聞いています！」などなど、日頃の活動がちゃんと届いていることが分かるようなコメントをいただきました。メッセージを書いてもらっている様子立ち寄って下さった方にはステッカーやアクキーなどのノベルティをお渡ししていました。また、今回はW3Cのブースからいくつかステッカーを渡していただいたので、途中からはそちらも配布していました（最初の写真の左端の3種類）。配布していたノベルティ今後もフロントエンド系のカンファレンスでは、似たような形式でブース出展することがあると思います。弊社のエンジニアがブースに立っているので、見かけたときは是非色々な話を聞きに来てください！弊社メンバーの活躍今回のカンファレンスは、弊社のデザインテクノロジストであるsakuさんが実行委員長を務め、最初から最後まで盛り上げていました。他に、スタッフとして運営に参加したメンバーもいました。オープニングトーク中のsakuさん懇親会でアナウンス中のsakuさん同じく弊社の、フロントエンドエンジニアの後輩であるコサキンが「Webで実用的な縦書きエディタは可能か？──現在地と普及に向けて」というタイトルで

こんにちは！サイボウズの開発広報のhokatomo（@tomoko_and）です。この度、日本CTO協会が発表した「開発組織ブランドアワード2026」で、サイボウズは6位となりました！このように評価していただき光栄です。調査方法やランキングの詳細は、日本CTO協会のプレスリリースをご覧ください。cto-a.org普段のプロダクト開発や組織づくり、それを社外に伝える発信が「サイボウズの開発組織」のイメージにつながったと思い、うれしく感じます。評価コメントから見る「サイボウズの開発組織」今回の受賞にあたり、「革新的／先進的」「働きやすそう／多様な働き方がありそう」「強いプロダクト／技術を重視していそう」といったコメントをいただきました。そのコメントを踏まえて、それぞれの印象につながるサイボウズの取り組みやコンテンツをまとめました。まずは、サイボウズの開発組織の全体像を知りたい方に組織や開発体制、プロダクト開発の進め方、現在取り組んでいるテーマをまとめて知りたい方には「開発本部採用ピッチ」がおすすめです。サイボウズ 開発本部採用ピッチ / Cybozu Engineer Recruit - Speaker Deck革新的／先進的 ― これからのチャレンジ開発本部長の @teppeis が語る「エンジニアトップメッセージ」では、AIとプロダクトの融合、エンタープライズ・グローバルへの展開、レガシー技術の刷新など、これから取り組んでいくテーマを紹介しています。cybozu.co.jp働きやすそう／多様な働き方 ― 開発・運用の仕事と環境組織体制や仕事内容から、開発文化、技術、働く環境まで、サイボウズの開発・運用組織の全体像を紹介しているのが以下のページです。cybozu.co.jp強いプロダクト／技術を重視 ― 技術やチームの発信技術ブログ「Cybozu Inside Out」AI、Web、モバイル、QA、OSSなど、幅広いテーマを発信しています。技術だけでなく、開発組織やチームの取り組み、試行錯誤の過程を紹介する記事など、多岐にわたるジャンルで日々発信をしています。Cybozu Inside Out | サイボウズエンジニアのブログほかにも、職能やチームごとにさまざまな媒体で発信を続けています。サイボウズQA｜noteサイボウズ フロントエンド | Zennサイボウズ 生産

2026年9月4日、W3C Japan 30 周年記念イベント - Web Togetherがサイボウズ 東京オフィスで開催されました。w3c-japan.connpass.comwww.w3.orgconnpassでは146人の申し込みがあり、当日も100人以上が来場。長年Web標準に関わってきた方も多い中、学生や若手の参加者も見られ、幅広い世代が集まる場になっていました。この記事では、当日行われた4本のライトニングトーク（LT）とパネルディスカッションの様子や印象に残った議論を、サイボウズプロダクトデザイナー 小林の視点でまとめます。4つの視点から考えるWeb標準sakuさん「30年目から見る Web」古川陽介さん「XHTMLが残したもの」Yuku Kotaniさん「Webとヘルスデータ」木達一仁さん「Web Sustainability Guidelines」パネルディスカッション：Webの30年とこれからの均衡1. Webがキャズムを超えた瞬間：3者それぞれの現場感2. 「Webは本当にキャズムを超えたのか？」と3社の危うい均衡3. なぜ標準化するのか：共通の土台が次の市場をつくるおわりに100人を超える参加者が集まった会場（サイボウズ東京オフィス）4つの視点から考えるWeb標準イベント前半はコミュニティメンバーによる5分間のLTが4本行われました。それぞれの発表は、現在のWebがどのように作られてきたか、Web標準が社会でどう使われているか、これから何を対象にしていくのかを、異なる角度から捉え直すものでした。sakuさん「30年目から見る Web」サイボウズのデザインテクノロジストであるsakuさん（@sakupi01）によるLT。発表資料sakupi01.github.ioWebの30年の歴史に対して、sakuさんがキャリアとして関わってきた期間は約15分の1。その立場から、自分がWebについて当たり前だと思っていた「意外と進化が早い」「互換性が比較的高い」「未来はみんなで議論されている」という3つの前提を、自身が標準化の活動に関わり出してからの体験とともに振り返る内容でした。W3Cに関わりだしたときのイメージを話すsakuさん古川陽介さん「XHTMLが残したもの」古川陽介さん（@yosuke_furukawa）の発表テーマは「XHTMLが残したもの」。

初めにkintone チームの前田です。kintone には結構な量のレガシーコードがあります。このレガシーコードに対して AI を使って再実装できないかを実験してみました。先に結果だけお伝えすると、うまく再実装できてコードベースに取り込めたものもあれば、うまくいかないものもありました。なお、利用したエージェントは Claude Code、モデルは Claude Opus 5 (1M コンテキスト版) です。AI への指示や情報は、増やせば増やすほど求める実装が生成されやすくなるとは思いますが調整も大変になってくるので、必要最小限にして実験しました。試行回数についてもどの実験でも一回としました。モジュールの再実装今回のリライト対象は kintone のサーバーサイドです。Java で書かれていて総行数は 50 万行を超えています。kintone のサーバーサイド全体をそのまま AI に投げつけるのは現実的ではありません。そこで再実装の対象は kintone 内のモジュールとしました。これで製品の全体に影響を及ぼすことがなくなり、リスクがぐっと下がります。コードレビューができるようになりますし、自動テストも可能です。ここでの自動テストは、モジュールに対する結合テストになっています。それによってデグレしたかどうかを迅速に AI に伝えることもできます。blog.cybozu.ioモジュールkintone では、アプリ設定機能であればアプリ設定モジュール、アプリ機能であればアプリモジュールというように、機能と実装が対応づくようにモジュール分けされています。blog.cybozu.ioモジュールの内部実装は完全にモジュール内に閉じています。定められた公開インターフェイス以外の部分は他のモジュールから依存されないようになっています。したがって、どれだけモジュールの内部実装を変えたとしても、公開インターフェイスの振る舞いを変えてない限りモジュールの機能的な役割の面では問題ありません。実験 1: 整った実装 + 全て AI にお任せ最初に再実装をしたのは 1,000 行ほどの、そこまで規模が大きくないモジュール (モジュール A) です。クリーンアーキテクチャを参考にユースケースレイヤーやエンティティ、ゲートウェイを導入して役割分担が整理されています。このモジュールは何か新しい手

Logos ProjectMythos 級 AI が公開されることをリスクと捉え、Horos というハーネスと、Ergon という LLM-Wiki を作ってきた Logos というプロジェクトを実施しました。Logos: このプロジェクトの名前Horos: ハーネスの名前Ergon: LLM-Wiki の名前Logos の全体像今回は、全体のまとめとして、Logos が走った 2 ヶ月の振り返りを紹介したいと思います。Mythos 対策プロジェクトの 2 ヶ月(概要編) Mythos 対策プロジェクトの 2 ヶ月(ハーネス編) Mythos 対策プロジェクトの 2 ヶ月(LLM-Wiki 編)> Mythos 対策プロジェクトの 2 ヶ月(まとめ編) ハーネスを持つメリット結果から言うと、Mythos そのものは公開されず、セーフガード版の Fable が公開されたところまでが現状です。その意味では「Mythos は公開されなかったから杞憂だった」と思われてしまうかもしれませんが、私たちはそうは思っていません。確かに Mythos は公開されていませんが、他のモデルも同じように成長しています。高度なモデルはセーフガードを付けないと公開できない流れはありますが、全てのモデルが本当にセーフガード付きで公開される保証はありません。特に Local LLM として公開されるオープンウェイトのモデル(例えば Kimi K3)なども、今後同じような脅威として捉えていく必要はあるでしょう。モデル進化への追従Horos ハーネスは、モデルの切り替えができるように設計しています。今後上位のモデルが公開された際は、攻撃者と同時に私たちもそのアクセスを手に入れ、それを Horos で使うことで、精度を上げながら改善していく地盤ができました。これを持っていることは、製品を守る立場としては、心強いアドバンテージです。また、今は Claude Code などを使ってスキャンを回していますが、自社では Local LLM の実行環境も持っています。Local LLM の上位モデルが出た際に、それを自分たちで動かし、Horos の実行をそちらにしていく計画もあります。Kimi K3 レベルのモデルが動かせる環境の調達も計画があり、実現したらスキャン結果の精度もそうですが、本当に「24h 365d

Logos ProjectMythos 対策プロジェクトとして、製品の脆弱性スキャンができるハーネス "Horos" を開発しました。このハーネスのなかで、とりわけスキャン精度向上に重要なのが、「どうやって社内にある製品の知識を Horos に渡すか」でした。私たちはここに、LLM-Wiki の仕組みを取り入れています。名前は、Ergon ちゃんです。Ergon = 仕事・働きMythos が「来たるべき強いモデル」、Logos が「整理された知・理性」を指すのに対し、Ergon は今まさに編纂とスキャンを回している "働き手" を表す。Mythos 対策プロジェクトの 2 ヶ月(概要編) Mythos 対策プロジェクトの 2 ヶ月(ハーネス編) > Mythos 対策プロジェクトの 2 ヶ月(LLM-Wiki 編)Mythos 対策プロジェクトの 2 ヶ月(まとめ編) 社内製品知識 LLM-Wiki ErgonLogos 全体像どんなに AI モデルが進化しても、AI が知っている情報は公開されたもののみです。もちろん、「Web アプリではこんな脆弱性が知られている」といった知識はたっぷり知っているので、一般的な脆弱性があれば、それはあぶり出してくれるでしょう。しかし、製品にある脆弱性は、そうした一般的なものだけではありません。例えば、kintone は情報共有のプラットフォームです。「A さんが作ったレコードを、権限の無いはずの B さんが見られた」というだけで、それは脆弱性です。実際、脆弱性報奨金制度を運用する中でも、そうした権限に関する脆弱性は受理し、報奨金をお支払いしてきました。ところが、こうした現象が脆弱性なのかどうかを判断するには、kintone の仕様について知っている必要があります。他にも、「どうしてこの実装になっているのか」といった、意思決定の履歴も、コードを読む際に役立ちますよね？それは人間でも AI でも一緒です。コードだけを渡すのではなく「コードに書かれていない、社内に蓄積された情報」もハーネス経由で提供することで、スキャンの精度は上がっていきます。では、どうやって情報を渡すのが良いでしょうか？LLM-Wiki社内のドキュメントのなかには、AI には渡せない情報もあります。ドメインを指定して Fetch を許可するのはリスクが高すぎます。そ

こんにちは！開発本部のAI Catalystチームの加瀬（ @Kesin11 ）です。8/17 - 18にAI-DLCという開発手法を体験するAI-DLC Unicorn GymイベントをサイボウズとAWS様の共同開催で実施しました。サイボウズ内でプロダクト開発に携わっているメンバーが新しいAIネイティブな開発手法に触れた様子をイベントレポートとしてお伝えします。AI Catalystチームについてその前に、少しだけ自分が所属しているAI Catalystチームについて紹介させてください。サイボウズでは以前から開発本部のAIやっていきチームが中心となって様々なAI開発ツールを業務で利用できるように整備してきましたサイボウズで利用可能な AI コーディングツールの紹介 - Cybozu Inside Out | サイボウズエンジニアのブログその結果、比較的早期からAIコーディングツールを活用するエンジニアを中心にAIを利用する方は増えていたのですが、その活用は個人が中心となってしまいチーム全体での利用はボトムアップではなかなか進まなかったという課題がありました。そこで今年の1Qから、開発本部でAIを活用してプロダクトを成長させるためのAI Catalystチームが立ち上がりました。Catalystは英語で「触媒・促進の働きをするもの・相手に刺激を与える人」という意味でチームの立ち位置にピッタリであることと、日本語で「語りスト」とも読めるダブルミーニングで採用されました。AI-DLC（AI駆動開発ライフサイクル）とはAI-DLCはAWSが提唱しているAI時代の新たな開発手法です。従来の開発プロセスをAIでサポートするのとは異なるアプローチで、AIの能力を最大限に生かすように開発プロセス全体を再設計したものです。AIがプランニング、タスク分解、実装などを行い、人間はAIのプランや実装に対して検証や意思決定を行うというサイクルで開発を進めていきます。AI-DLCの全体の流れはInception -> Construction -> Operationの3フェーズで構成されており、各フェーズで得たコンテキストを引き継ぎながら次のフェーズに移っていきます。Inception: ビジネス上の目的を要件、ユーザーストーリー、作業単位（Units）へと細分化を行うConstructi

こんにちは、iOSエンジニアの @tochi86_ です。今年も iOSDC Japan の時期が近づいてまいりました。「iOSDC Japan」とは、iOS関連技術をテーマとした iOS技術者のためのカンファレンスです。 iosdc.jpサイボウズでは、kintone / サイボウズOffice / Garoon の3製品のモバイルアプリを開発・運用しており、SwiftUI や Swift Concurrency を積極的に使い、Swift Package によるマルチモジュール構成やモダンな技術に適したテスタビリティの高い設計に挑戦したりと、iOSアプリ開発に力を入れています。当日ブース当日はサイボウズのブースにて、時間帯ごとにトークテーマを設定しています。トークテーマ一覧「#開運夏まつり」「#開運冬まつり」また今回の iOSDC Japan 2026 限定で、特別なデザインのキーボードキーホルダーを製作しました。（押すと光ります✨）限定キーボードキーホルダー社員登壇情報スポンサーセッション9/12(土) day1 Track C 11:25〜（20分）@el_metal_fortee.jpレギュラートーク9/12(土) day1 Track D 16:45〜（40分）@el_metal_fortee.jpアフターイベントiOSDC Japan 2026 終了後には、STORES さんとサイボウズの2社合同アフターイベントを開催します！DroidKaigi × iOSDC After Nightcybozu.connpass.comiOSDC Japan や DroidKaigi に参加した方、モバイル開発に興味のある方向けに、各社エンジニアによるLTと交流会を行います。サイボウズでは「#チームワークあふれる社会を創る」という理念を実現するべく、iOSエンジニアを絶賛募集中です！ 詳しくは下記をご参照ください。cybozu.co.jp

Logos ProjectMythos 級 AI の公開をリスクと捉え、AI を用いた製品のセキュリティスキャンを行うハーネスを開発しました。ハーネスを "Horos" と名付けました。Horos 境界標／定義・術語: サンドボックス境界と「判定基準」の二重義ハーネスエンジニアリング/ループエンジニアリングなど、いろいろなところで聞く言葉ですが、私たちが開発した「セキュリティスキャンハーネス」とはどういうものだったのか。今回は、その概要をご紹介します。Mythos 対策プロジェクトの 2 ヶ月(概要編) > Mythos 対策プロジェクトの 2 ヶ月(ハーネス編) Mythos 対策プロジェクトの 2 ヶ月(LLM-Wiki 編)Mythos 対策プロジェクトの 2 ヶ月(まとめ編) セキュリティスキャンハーネス "Horos"Logos 全体像ソースコードを渡し「脆弱性をスキャンして」と言えば、ある程度のスキャンはしてくれます。しかし、単純なプロンプトを単発で回しても、十分な結果は得られません。これはモデルの性能だけの問題ではありません。そもそも脆弱性のスキャンは、ソースコードを細かく解析する必要がありますが、モデルは一度に全てのコードをつぶさに見てくれるわけではありません。一定の観点で怪しそうな場所を見つけ、そこを重点的に見るような「偏り」をもってスキャンをします。大事なのは、スキャンを何度も回すことです。でも同じ情報だと、何度も回しても同じようなところを見て、同じような結果を出してきます。今回のスキャンはどこを見たのか、その結果何が検出されたのか、そのうちどれが本当に脆弱性で、どれが誤検出だったのか。前回の結果を次のコンテキストに積む「フィードバックループ」が非常に重要です。セキュリティスキャンハーネスの最も重要な点は、このループを回せるような土台を整えることでした。サンドボックス環境脆弱性情報は、コンフィデンシャルな情報です。本来は AI に渡すのもためらわれるような、重要な情報ですよね。でも、今回はその情報を AI 自体に見つけてもらっているわけです。矛盾しています。もちろん、学習されないように設定することはできます。そこは信じるしかありません。それでも、AI がうっかりその情報を外に投げ出したりしたら、それ自体がインシデントになってしまいます。そこで、A

Project LogosMythos の存在についてアナウンスされた今年の 4 月。サイボウズのサービスでも、攻撃のリスクがあるなら対策が必要かもねぇ、と思っていました。5 月ごろ、しばらくは調査として、様々なモデルを使い、一人で検証を重ねていました。ところが 6 月の「本当に公開されそう」という続報をきっかけに、本格的な対策に動き出さないとまずそうだと考え、サイボウズ社内で Mythos 対策プロジェクトを始動しました。私たちはそれを "Logos プロジェクト" と名付けました。Mythos 神話・物語・語られるもの = 人を動かす物語Logos 説明可能な言葉・理性・理論 = 物語を検証する> Mythos 対策プロジェクトの 2 ヶ月(概要編) Mythos 対策プロジェクトの 2 ヶ月(ハーネス編) Mythos 対策プロジェクトの 2 ヶ月(LLM-Wiki 編)Mythos 対策プロジェクトの 2 ヶ月(まとめ編) Logos プロジェクトの発端6 月はまだ、Mythos 級 AI が公開され、攻撃者の手に渡ると、多くのサービスが被害に遭うという懸念が取り沙汰されていました。実際にはセーフガードが搭載された Fable の公開にとどまり、今に至っても Mythos そのものへのアクセスは一般公開されていません。しかし、実際に脅威なのは Mythos だけではありません。オープンウェイトを含め各モデルが進化していけば、リスク自体は永続的に続くはずです。私たちも、このリスクを評価するため、リポジトリを渡して「ここから脆弱性を見つけて」といった検証を、実験レベルで行ってはいました。この方法で出るのは、一般的な Web サービスの脆弱性パターンについての誤検出ばかりです。そこで私たちは、いわゆる「セキュリティスキャンハーネス」を構築することにしました。ハーネスといってもいろいろな定義がありますが、作ったのは以下のようなものです。製品に関する情報をしっかり把握する長いスキャンをタスク分割し実行する検出した結果から重複や誤検出をフィルタリングする再現できるかを半自動で検証する結果をフィードバックしながら繰り返し実行する手元にあるモデル(当時で言う Opus 4.8)であっても、これを繰り返し実行することで精度が上がり、上位のモデルが公開されたら、モデルだけを差し

こんにちは！ソフトウェアエンジニアとして活動している @nissy_dev です。サイボウズでは、各プロダクトを新しいインフラ基盤「Neco」に移行する取り組みを進めています。サイボウズ Office とメールワイズも例外ではなく、私たちのチームは 2024 年頃からこの 2 つの製品の移行に取り組んできました。この記事では、その中から特に大変だった点や、設計・運用で工夫したトピックについて紹介します。目次なぜ Kubernetes に移行するのかSQLite を利用する CGI を Kubernetes で動かすステートフルワークロードと CGI の性質Pod とボリュームの配置に関する制約ローリングアップデートの安全性を検証するfcntl(2) のロックが Pod 間で機能することを確認するページキャッシュが Pod をまたいで残ることを確認するCGI のコマンドライン呼び出しを gRPC の API でラップするWeb リクエスト以外にも CGI を呼び出す処理があるPod 内の構成大量のファイルを短い停止時間で移行する事前転送と最終転送の 2 段階の構成mtime ベースの差分転送の安全性を検証する移行先でもバックアップとリストアをできるようにする外形監視を再設計するまとめなぜ Kubernetes に移行するのかサイボウズでは kintone や Garoon などの各製品で Neco への移行が進んでいます。移行することで、テナント管理やリリースの仕組みを全社共通の基盤に統合でき、ハードウェアの世代交代やスケーリングも Kubernetes の仕組みに乗せられるようになります。一方で、製品自体は 20 年以上続く C++ 製の CGI アプリケーションで、テナントごとのデータを SQLite で保持しています。この構成を Kubernetes 上で動かすには、製品固有の前提に合わせた設計が必要でした。サイボウズ Office については、開発チームの紹介スライドも公開されているので、あわせて見てもらえればと思います。SQLite を利用する CGI を Kubernetes で動かすステートフルワークロードと CGI の性質Kubernetes 上でアプリケーションを動かすとき、ローカルファイルを操作しないステートレスなプロセスであれば、Pod はどのノ

開発本部 開発組織デザインチームでオンボーディングを担当している久宗(@tignyax)です。2026年もエンジニア新人研修を行いましたので、研修の概要と、講義資料および講義動画を公開いたします。2026年のエンジニア研修について新卒メンバーの研修の流れとしては、「人事全体研修→エンジニア研修→職能受入研修→配属先チーム研修」と進んでいきます。エンジニア研修としては、4/23(木)~5/29(金)の期間で「講義実習」と「実践演習」の2フェーズで行われました。本記事では、研修の概要と社外公開可能な資料および動画を紹介いたします。コンセプト今年のエンジニア研修のコンセプトは去年同様、以下になります。エンジニアリング組織の新卒メンバーが​エンジニアリング組織で仕事をする土台となる知識を学び、実践することができたエンジニアリング組織がどういう組織で、どんなチームがあるのかわかったエンジニアリング組織同期の繋がりを強化することができた研修の理想目指す状態配属後にスムーズに業務に取りくむことができる​入社1年後にチームや組織に貢献できている実感がある​この先の長いキャリアを歩むにあたっての土台を作る要素自社~自身を理解する事業を理解するエンジニアリング組織を理解する自身のチームについて理解する自身について理解する成長するための力を身につける任意で補うものこの先の長いキャリアを歩むにあたって土台になるもの（エンジニアリング組織に限らないもの）エンジニアリング組織共通の標準/基本チームや職種の標準/基本講義資料公開（2026年版）セキュリティ講義資料：開運研修セキュリティ講義2026 | ドクセルエンジニアのためのアウトプット講座〜知識をシェアするはじめの一歩〜講義資料：エンジニアのためのアウトプット講座2026 | ドクセルソフトウェアテスト講義資料：ソフトウェアテスト2026 | ドクセルAWS入門講義資料：AWS入門2026 | ドクセルDocker入門講義資料：開運研修2026 Docker入門 | ドクセル暗号と認証のサーベイ講義資料：暗号と認証のサーベイ | ドクセルAIコーディング活用講義資料：開運研修2026 AIコーディング活用 | ドクセルKubernetes入門講義資料：開運研修kubernetes入門2026 | ドクセルサイボウズ製品のプロダクトデ

こんにちは、kintone 開発チームの Android エンジニア、トニオ（@tonionagauzzi）です。サイボウズは、2026年9月1日(火)〜3日(木) にベルサール渋谷ガーデンで開催される DroidKaigi 2026 にゴールドスポンサーとして参加します！DroidKaigi とサイボウズDroidKaigi は、日本最大級の Android 開発者カンファレンスとして、2015年から継続して開催されています。毎年多くの Android 関係者が参加し、とても盛り上がっています。このカンファレンスでは、Android の最新の技術情報や開発手法に関するさまざまなセッションとワークショップがあります。スポンサー各社のブース展示や交流企画も毎年充実しています。参加者同士の交流も活発です。Android 開発に関わる人々にとっては国内最大規模のイベントで、貴重な学習と交流の機会だと思います。サイボウズは DroidKaigi の取り組みに賛同し、2021年から継続してスポンサーとして参加しています。今年も Android コミュニティの皆さんと共にこのイベントを支えていけることを嬉しく思います。Android とサイボウズサイボウズでは、kintone、サイボウズ Office、Garoon という3つのサービスで Android アプリを開発・提供しています。「チームワークあふれる社会を創る」という理念のもと、チームで働く人々を支援するグループウェアづくりに取り組んでいます。私たちの Android アプリ開発は、Android コミュニティからの多くの知見や技術に支えられています。そうした日々の恩恵への感謝を込めて、私たちもコミュニティ活動に貢献したいという思いから、DroidKaigi に協賛しています。今年もブースを出展！DroidKaigi 2026 でも、サイボウズブースを出展します！ブースでは、サイボウズの Android エンジニアとの交流をお楽しみいただけるよう、以下のコンテンツを用意しています。会話が広がる！アンケート企画ブース限定のノベルティトークテーマを選んで、サイボウズ社員とフリートークブースで配布するノベルティは以下の5種類です！kintone サイボウズAIシールkintoneロゴふせん軍手セット 3種類きとみちゃんお星様ラ

こんにちは！開発広報チームのhokatomo（@tomoko_and）です。サイボウズでは7月に開催された女子・ノンバイナリーの中高生を対象としたオンラインイベント「Waffle Club」への協賛をし、QAエンジニアの水野菜々穂さんが登壇をしました。特定非営利活動法人Waffleが主催するイベントで、Waffleの「テクノロジー分野のジェンダーギャップを解決する」というミッションに共感し、協賛を5年以上続けています。Waffle Clubとはプログラミング体験や社会人のキャリアトークを通じて、中高生がテクノロジーや進路の選択肢を広げるきっかけを作るイベントです。今回は、水野さんによるキャリアトークの後、参加者がプログラミングのワークショップに取り組みました。「やりたいことが見つからなくても、まずは気になることから」水野さんは中学生のころはITとの接点がほとんどなく、高校で初めてプログラミングに触れたときには途中で挫折したこともあり、苦手意識を持ったそうです。それでも、「こんなアプリがあったら、自分の困りごとを解決できる」という気持ちからビジネスコンテストに挑戦し、大学ではプログラミングに再挑戦！最初から将来やりたいことが決まっていたわけではなく、困っていることや少し気になることをきっかけに動いてみたことで、少しずつ選択肢が広がり、今の仕事につながった話をしました。今回の登壇資料www.docswell.com参加者から、こんな反応がありました参加者からはQAという新しい分野のお仕事を知れてとても面白かったです。あまり年齢が離れていない方だったので、さらに身近に感じられました。文理の選択に阻まれないで、自分が楽しいと思うこと・やれると思うことを仕事にすることができると学べてよかったです。中でも印象に残ったという声があったのが、次の話です。「失敗したら自分にご褒美をあげるようにしています。受かったら受かったことがご褒美だからという感じで、"失敗しても大丈夫"って思うようにしています」この話には、「自分も取り入れたい」という感想も寄せられました。私自身もこの話を聞き、まずチャレンジした自分の行動を認めて褒める！という大切さに気付かされました。なぜ、サイボウズはこの取り組みを続けているのかサイボウズでは、Waffleへの協賛を継続し、これまでにも多くの社員がWaffleの

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。はじめに25新卒入社でkintoneのAndroidアプリ開発チーム所属の市村です。本記事では2年目になった私が、どんな1年目だったかを振り返ります。1年目のロールモデルの一例として参考にしてもらえたり、kintone Androidがどういうチームか知ってもらえたら幸いです。私は2025年7月に、kintone Androidチームに配属されました。サイボウズの社員歴はすでに1年半に迫りつつありますが、配属を基準に考えるとちょうど1年ほど経っているので、2025年の7月から現在までの振り返りの内容が中心になっています。配属から現在までに関わった機能開発以下が配属からこれまでに取り組んだ機能開発です。 時期 着手内容 2025/07 PDFプレビューで文字検索を追加 2025/08 ログイン画面のUI改善 2025/09〜10 Androidアプリ版の検索AI（kintone AI）を実装 2025/11〜12 Android開発基盤整備 2026/01〜02 未処理一覧ウィジェットの実装 2026/02〜04 書類スキャン機能を追加 2026/05〜06 Androidアプリ版のレコード一覧分析AIの実装 2026/06〜08 Androidアプリ版のスレッド要約AIを実装 入社当初は業務コードに触れた経験がなく、最初はモブプロでほとんど指示通りに動くだけのラジコン状態でした。検索AIの開発に着手したあたりで慣れてきて、一人でタスクを進めることが増えました。 印象に残った仕事：書類スキャン機能の追加一気に開発業務の解像度が上がったのは書類スキャン機能の実装です。着手は2026年2月頃、一人でタスクを回し始めた時期でした。このタスクで初めて自動テストとちゃんと向き合いました。今はAIでテストを簡単に生成できますが、そのカバレッジや保証の仕方が適切かを見極めるのが非常に難しいです。自動テストがないと自信を持って機能追加や変更ができない一方、多すぎればCIのたびに時間がかかり、不安定なテストの割合も増えます。何を保証すべきかは、壊れた時のリスクと、テストの実装・保守コストのバランスで判断します。リスクはユーザーの利用頻度とビジネス的な影響度を加味しての判断が必要で、この観点からどの機能がどの程度

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。こんにちは！サイボウズのトニオ（@tonionagauzzi）です。普段はkintone開発チームにてAndroidアプリを主に開発しています。2026年7月23日（木）に、ディップ株式会社、株式会社ヤプリ、株式会社Voicy、サイボウズ株式会社の4社合同モバイル勉強会、Mobile Tech Flex #2 〜4社合同！私たちが「越境」した話〜をサイボウズ東京オフィスで開催しました。本記事ではその当日の様子をレポートします！mobiletechflex.connpass.comイベントの概要Mobile Tech Flexは、モバイルアプリ開発に携わる人々が集まり、各自の取り組みをLT形式で発表する合同勉強会です。モバイルの勉強会で敷居が一番低いコミュニティを目指し、発表を後押しする場でありたいと思っています。モバイルに関わる方なら職能を問わず誰でも発表できるのが特徴です。詳しくは以下の紹介記事にまとめていますので、ぜひあわせてご覧ください。blog.cybozu.io第2回の開催となる今回のテーマは、越境でした。職能や技術領域の垣根を越えて挑戦した経験談を、エンジニア、QA、PdMの方々から共有していただきました！当日の様子かわいい動物たちがお出迎え！登壇ステージはこんな感じです！乾杯からスタート！猛暑の中お越しいただいた参加者の皆さんと最初に乾杯して、和やかな雰囲気でLTセッションが始まりました。オープニングのビールスポンサーセッション今回は転職ドラフトさんからビールスポンサーとして、オリジナルデザインのビールをご提供いただきました！エンジニアのキャリアをコミュニティと共に支えたいというコンセプトに、主催としてとても共感しています。転職ドラフトさんのオリジナルビール「ひと粒の種、万葉の選択肢。」「雨宿りの、サードプレイス」ビールはユニークで美味しいと評判でした。転職ドラフトさん、この度はありがとうございました！LT (1): チームの仕組みで作る心理的ハードルを下げる越境トップバッターはディップの吉本さん（@tokotoko_kt）。新卒2年目のAndroidエンジニアとして、バイトルアプリのリニューアルプロジェクトに携わっておられます。越境をためらう背景には、前提知識の壁、設計思想の

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。こんにちは、フロントエンドエンジニアのおぐえもん（@oguemon_com）です。今年の9月に、「フロントエンドカンファレンス福岡」（FECF 2026）が7年振りに開催されます。サイボウズはFECF 2026に「Gold Sponsors」として支援している他、当社エンジニア（コサキン）の登壇予定もございます。さて、サイボウズでは、そんなFECF 2026の開催前日にあたる9月11日（金）の夜に、当社福岡オフィスでWebフロントエンドの勉強会を開催します！その名も、「替え玉.web」です。替え玉.webのイメージ画像替え玉.webとは？「替え玉」とは、ラーメンの麺をおかわりする追加注文のことで、福岡が発祥と言われています。「替え玉.web」は、そんな替え玉のように、美味しかった過去の発表をおかわりする勉強会、つまり、「過去の発表の再演が原則」のWebフロントエンド勉強会です。一般的に、IT勉強会の発表は完全新作が求められる傾向があります。しかし、過去の発表を再演することにも数多くのメリットがあると考えています。発表者にとっての主なメリット初回発表時の反省点を活かした、より洗練された発表ができるかつての発表を新たな人たちに届けられる準備の負担が比較的少ない聞き手にとっての主なメリット面白かった題材が集まりやすい、題材に磨きが掛かりやすいので面白い可能性が高まる当時見られなかった発表を見るチャンスが得られる一度見たものも再び見ることで記憶に定着するウケが良かった発表を「替え玉.web」に持ち寄り、参加者の皆さんで改めてその面白さを噛み締めようというのが今回の勉強会の趣旨です。発表者&参加者を募集中！ただいま「替え玉.web」の登壇者と参加者をともに募集しています！いずれも、Webフロントエンドに興味のある方でしたら、学生、社会人、FECF 2026参加予定か否かなど不問で誰でもWelcomeです。詳細や申込についてはConnpassをご覧ください。発表について10分間（質疑応答込）の持ち時間で発表いただける方を募集しています。テーマは「Webフロントエンドに関するもの」ならば何でも歓迎です！また、コンセプトの通り、「過去の発表の再演が原則」です。かつてウケた発表、上手く伝わらなくて悔しい思いを

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。こんにちは。kintoneの開発組織でEMをしている上岡（@ueokande）です。サイボウズでは2025年から本格的にkintoneのEM採用を進めてきました。EM採用を進める中で、採用活動だけでは見えなかった課題や発見がありました。当初は「採用できれば成功」と考えていましたが、実際は採用後のほうが重要で意思決定が難しいことが分かりました。この記事ではこの1年間のEM採用を振り返りながら、採用・配属・オンボーディングを通じて得られた学びと、これからのチャレンジについて紹介します。背景：なぜkintoneのEM採用を始めたのかEM採用を始めたきっかけには、組織設計のいくつかの転換点がありました。2024年より開発組織のインパクト向上のため、EMを軸とした組織設計を進めてきました。マネージャーの役割も変わり、人材マネジメント中心だったマネジメント業務が、プロジェクトの推進、チームの意思決定、機能設計など、製品開発を前進させる役割も担うようになりました。一方で組織拡大によりEM不足が顕在化し、多くのEMが複数組織やプロジェクトを兼務する状態となりました。こうした背景からEMの社内育成だけでなく、外部からも経験のあるEMを採用することになりました。エンジニアリング組織の様々なレイヤーにEMを配置、マネジメント範囲の成果最大化に責任を持つエンジニアリング組織の様々なレイヤーにEMを配置、マネジメント範囲の成果最大化に責任を持つサイボウズの組織設計の移り変わり、および現在のEMの業務は以下の資料も合わせてご覧ください。エンジニアが主導できる組織づくり ー 製品と事業を進化させる体制へのシフト - Speaker Deckkintoneエンジニアリングマネージャー業務紹介 | ドクセル「採用すること」よりも「どこで活躍してもらうか」採用を始めた当初は、EMが不足しているチームに配置すればよいと思っていました。しかし実際には、それほど単純ではなく、選考を重ねるうえでも考え方が徐々に変わりました。EMの中にも、組織づくりが得意な人、技術的な意思決定が得意な人、プロジェクト推進が得意な人など、様々な強みがあります。またkintoneでも、各チームの状況や成果物によって、求める役割は異なります。そのため選考プロ

kube-state-metrics で Deployment Sharding を採用した話この記事は、CYBOZU SUMMER BLOG FES '26の記事です。こんにちは、クラウド基盤本部の藤井です！この記事では、Neco で kube-state-metrics をシャーディング構成へ移行するにあたり、検討した方式と Deployment Sharding を採用した理由を、kube-state-metrics v2.19.1 の実装をもとに紹介します。Neco については紹介ブログもあるのでこちらを参照してください！blog.cybozu.ioなお、本記事の AI Influence Level（AIL）は Level 1です🤖danielmiessler.comkube-state-metricsとはシャーディングを検討した背景シャーディングの方法方法１： Kubernetes API サーバーから取得するリソースを絞り込む方法２： 取得したリソースのうち、メトリクスに変換する対象を絞り込むHorizontal Sharding の仕組みDeployment ShardingAutomated Sharding結局どうしたのかまとめkube-state-metricsとはkube-state-metrics（以後、KSM ）は、Kubernetes の API サーバーから Pod などのリソースを取得し、その情報をメトリクスへ変換するコンポーネントです。メトリクスは KSM Pod の/metrics にアクセスすることで、取得できます。KSMの/metricsにアクセスするとメトリクスを取得できる例えば、次のようなメトリクスが生成されます。kube_pod_status_phase{namespace="argocd",pod="argocd-server-5f898b9cbc-4pbbx",...,phase="Running"} 1kube_pod_info{namespace="argocd",pod="argocd-server-5f898b9cbc-4pbbx",...,pod_ip="10.244.1.7",node="kind-cluster-worker2",...} 1kube_deployment_status_replic...

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。kintone dashboard Teamの開発をしている まつもと です。これまで、kintoneの開発や、海外向けの kintone (kintone.com) の Amazon Web Services (AWS) への移行や、その運用などをしてきました。kintoneとは別基盤で動くダッシュボードに、テナントごとに違うOIDCエンドポイントをどう繋ぐかサイボウズでは、kintoneの性能や利用状況を可視化する「ダッシュボード」を提供しています。kintone本体がサイボウズのクラウド基盤で動いているのに対し、このダッシュボードはAWS上に構築されていて、kintoneとは別のシステムになっています。kintoneにログインしているユーザーがダッシュボードを表示した際にユーザー情報をどうやって連携するかという課題がありました。今回はその認証まわり、特に「テナントごとにOpenID Connect (OIDC) のエンドポイントが異なる」という、kintoneならではの制約にどう向き合ったかを紹介します。kintone特有の制約kintoneはOIDCのエンドポイントが実装されていて、社内で利用できる状態だったので、OIDCを利用して認証し、ユーザー情報を取得する構成は自然な選択でした。一般的なOIDC連携では、IdP (Identity Provider)のエンドポイント、つまりAuthorization EndpointやToken Endpoint、JWKs EndpointなどのURLはサービスごとに1つに決まっていることがほとんどです。多くのOIDCライブラリは「issuerは起動時に1つ設定する」といったことが前提に作られているように思います。kintoneは、example.cybozu.com のように契約(テナント)ごとにサブドメインが割り当てられるマルチテナント型のSaaSで、OIDCのエンドポイントもテナントごとに独立しています。ダッシュボードは全テナント共通の1つのアプリケーションとして提供しているため、アクセス元のテナントに応じて、その場でOIDCエンドポイントを切り替える必要がありました。どのように解決したかテナントの数が限られる場合は個別のOIDC設定を持

この記事は、CYBOZU SUMMER BLOG FES '26の記事です。Cloud Platform部のpddgです。サプライチェーン攻撃やAIによる脆弱性の検出が盛んになった昨今、迅速な影響の把握と更新の適用が求められ、ソフトウェアが抱える依存関係の脆弱性の検出はその重要性が増してきています。一方で、ナイーブに脆弱性を検出するだけでは誤検知（偽陽性）が多くなり、開発者の負担が増えることになります。Goのプロジェクトでは、govulncheckを用いることでモジュールレベルではなく関数のシンボルレベルで影響の有無を検出でき、偽陽性を削減できます。一般的なOSSスキャナーのスキャンとgovulncheckのスキャン結果を組み合わせることで、より正確な脆弱性検出が可能になります。背景ソフトウェアを構成する依存関係に存在する脆弱性を早く検知し、攻撃に繋がる前に早く対応することは現代の開発において重要性が増しています。TrivyやGrype、OSV-ScannerなどのOSSの脆弱性スキャナーを通して、依存関係に含まれる脆弱なライブラリ・モジュールを検知し、開発者に通知することは有効な手段です。これらのスキャナーはモジュールレベルでの検知を行うことが多く、実際に影響を及ぼすかどうかに関わらず脆弱性ありとして報告されることがあります。実際にはあるライブラリの脆弱性が検知されたとき、そのライブラリのうちどのような機能を利用しているかによって影響を受ける箇所は変わってきます。静的解析により当該機能を利用しているかどうかを知ることができれば、より精度の高い脆弱性検知が可能なはずです。govulncheckGoは脆弱性管理のためのデータベースを持っています。このデータベースを用いて、現在のGoのプロジェクト内・もしくはバイナリにおいて依存関係に既知の脆弱性を含むかどうかを調べるのが govulncheck コマンドです。Goのコードもしくはビルドしたバイナリを対象に解析を行い、ソースコードの場合は脆弱性の見つかった機能への到達可能性まで見て影響を受けるかどうかを判定します。そのため、単に依存関係に脆弱性の見つかったライブラリが依存関係として存在するかどうかだけで判断するよりも偽陽性を抑えられます。脆弱性スキャナーとgovulncheckの現在ほとんどの脆弱性スキャナーは現状では依

サイボウズでデザインテクノロジストをしている @saku です。今回は、サイボウズと同時期に W3C に加入した Studio さんと、各社がどうして W3C に加入したのかを、お互いにインタビューするコラボブログ企画を実施します。今回は、 Studio の CTO 諸田さんをサイボウズにお迎えし、 Studio が W3C に加入した経緯やビジョンについてお伺いしました。諸田さんとsakuの対談風景Studio 社の紹介Saku: まず Studio は、何をされている会社か教えてください。諸田: Studio は、Web の制作から公開・運用までを支える、Web サイトビルダーをホスティング込みで提供するサービスをしています。studio.incただツールを提供しているというよりは、社会の皆さんが諦めてしまっている部分を「本当にそこって諦める必要あるんだっけ」と、うちのプラットフォームで解決して、本当にやりたいこと・やるべきことに集中できるようにする、"Unleash Creativity" というビジョンを掲げている会社です。Saku: 構造上サイトを作るのが難しいところなどを一挙に Studio さんが担って、もっとクリエイティブなとこにリソースを割けるようにするというビジョンですね。組織の中に入っていく改善とかも、含まれるんですか?諸田: 長期的には含まれます。今のスコープではサイトから入っていますが、Web サイトビルダーは、そのきっかけとしてやり始めたという感じです。Studioが「これができますよ」ってポンとツールを提供するだけでは、ユーザーも僕らもまだまだ先に繋がらない。ユーザーのやりたいことを本気で支えたいんです。どちらかというと、「自分から発信しよう」とか「社会にこれを表現していこう」で「アクションを起こしていこう」というユーザーの動きが大事で、それを支えたいなという感覚です。それこそモリサワさんなど、分野の違うサービスとも一緒に手を組んでもっと価値のあるサービスにしていきたいですし、今日の話である W3C に入っているということも、そのために必要なことだと思っています。Saku: 社会のクリエイティビティをエンパワーメントするという最終的な目標に向かっていく手段は何でも取れるといい、みたいな感じですかね。諸田: そうですね。「社会」ってニュア