こんにちは！サイボウズの開発広報チーム兼開運まつり実行委員長のhokatomo（@tomoko_and）です。社内テックカンファレンス「開運冬まつり」を開催しました。職能も拠点も違うエンジニアが、2日間の交流と対話を通じて、次への行動に繋げる場です。こうした場が自然と生まれ、改善しながら継続してきた過程にサイボウズの文化を感じています。この記事では、開運まつりそのものだけではなく、背景にあるサイボウズの文化について少しでも伝えられたらと思います。開運まつりとは-交流のきっかけと、新しい視点を持ち帰る場-開催概要この場が成立することが、私たちの文化多角的に関われる場作りセッションでは、いま考えていることを共有する場にOSTでは問いを持ち寄り、対話する参加者の声イベントが成熟してきたからこそ、運営での悩みおわりに開運まつりとは-交流のきっかけと、新しい視点を持ち帰る場-開運まつりは、サイボウズで開発・運用に関わる様々なチームや職能の人が集まり、セッションの聴講や体験型コンテンツ・懇親会・シャッフルランチ・Open Space Technology（以下OST）を通じて交流を深める、オフラインのお祭りです。2024年から始まり、これまで年2回夏と冬で開催、これで5回目の開催です。（前回夏開催時の記事）チームワークあふれる社会を目指しているサイボウズも、コミュニケーションに課題を感じています。これを解決する企画の一つが、開運まつりです。チームや職能の垣根を超えて交流することで、対話のきっかけや、新たな視点を得ることを目的にしています。サイボウズでは開発＆運用を担うエンジニアリンググループの総称として「開運」と呼んでいます。関連するメンバーが一堂に会するということで、開運まつりと命名しました。開催概要日付：2026年2月18、19日の合計2日間場所：サイボウズ東京オフィス開催形式：発表系のコンテンツはハイブリッド、それ以外の交流や対話メインのコンテンツはリアル開催のみコンテンツDay1：セッション（3トラック30テーマ）、懇親会Day2：シャッフルランチ、OST参加人数：オンライン含めて311名運営：実行委員10名、ボランティア16名この場が成立することが、私たちの文化開運まつりは、最初から大きなイベントとして計画されたものではありません。日々の開発や運用の中で生まれた「もっ

この記事は kintone 生成 AI チームで連載中の kintone AI リレーブログ 2026 の 10 本目の記事です。リレーブログでは生成 AI チームのメンバーが AI トピックに限らず、さまざまなことについて発信していきます。こんにちは！ kintone の生成 AI チームでソフトウェアエンジニアをやっている福田です。私たちのチームでは cdk8s を使って Kubernetes マニフェストを管理しています。（cdk8s の詳細は別の記事で紹介していますので、あわせてご覧ください。）cdk8s を使うと TypeScript でマニフェストが書けるだけでなく、Helm チャートと統合したマニフェスト管理も簡単に行うことができて非常に便利なのですが、YAML のマニフェスト生成に時間がかかることがチーム内でも問題になっていました。Kubernetes へのデプロイは、cdk8s で生成した YAML のマニフェストを apply するという方法で行っており、その生成に時間がかかってしまうと、開発のイテレーションが遅くなってしまいます。今回はマニフェスト生成が遅いという問題に対して、その原因の特定と解決方法の実装について共有します。何が遅かったのかcdk8s は TypeScript のコードを実行してマニフェストを生成する仕組みになっているため、コードを実行する際のプロファイルを取ることで、どの部分で時間がかかっているか特定できると考えました。Node.js には --prof オプションがあり、これを使うことで JavaScript のコードの実行時のプロファイルを取ることができます。私たちのプロジェクトでは TypeScript を使っているので、tsc で JavaScript にトランスパイルしてから Node.js で実行してプロファイルを取ることにしました。以下はプロファイリングの結果の抜粋です。 [Bottom up (heavy) profile]: ticks parent name 9129 88.6% epoll_pwait@@GLIBC_2.6 5439 59.6% JS: ~spawnSync node:internal/child_process:1105:19 3741 68.8% JS: ~spawnSync nod

こんにちは、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、サイボウズ Of

この記事は kintone の生成 AI チームで連載中の kintone AIリレーブログ 2026 の 9 本目の記事です。 リレーブログでは、生成 AI チームのメンバーが AI トピックに限らずさまざまなことについて発信していきます。こんにちは！kintone 生成 AI チームの 386jp です。前回の記事「cdk8s をもっと使いこなす - kintone AI チームの活用 Tips」では、 cdk8s を使う上で工夫している実践パターンを紹介しました。今回は、 cdk8s で生成したマニフェストをどのようにデプロイしているか、デプロイ戦略について紹介します。目次:前回のおさらいcdk8s をプロダクション運用する上での 3 つの課題課題1へのアプローチ：マニフェストの事前生成と書き出しの工夫マニフェストを事前に生成するメリットマニフェストの書き出し方の工夫FOLDER_PER_CHART_FILE_PER_RESOURCE の効果課題2へのアプローチ：GitOps 用リポジトリとの分離2 つのリポジトリ構成なぜ 2 つのリポジトリに分けたのか課題3へのアプローチ：段階的デプロイを実現する CI/CD パイプラインデプロイフローの全体像cdk8s コードの PR での変更確認段階的デプロイと自動検証まとめWe are hiring !!前回のおさらい前回の記事では、 cdk8s を使う上での実践パターンとして、以下の内容を紹介しました:core/apps の分離: インフラコンポーネントとアプリケーションを分けて管理YAML による設定管理: 環境ごとの差異を柔軟に管理CRD の型安全な扱い: TypeScript の型定義として取り込み、型安全に記述再利用可能な Construct: 共通パターンをまとめて開発速度を向上cdk8s をプロダクション運用する上での 3 つの課題cdk8s を使って Kubernetes マニフェストを TypeScript で柔軟に生成できるようになった一方で、それを実際のプロダクション環境へ安全かつ確実にデプロイするためには、いくつかの運用上で考えるべき課題がありました。実際にデプロイされるマニフェストが不透明になりがちArgo CD のプラグインなどで動的にマニフェストを生成させた場合、「結局何がデプロイされるの

kintoneの開発部門には、「プラットフォームエンジニアリング部（以下、PfE部）」があります。aki (@aki366) が、PfE部が何をする部なのか、なぜ今このタイミングで立ち上がったのかを、立ち上げメンバーへのインタビューを通してひも解く3部作。今回はその最終回です。第1回：なぜ、kintoneにプラットフォームエンジニアリング部は生まれたのか第2回：探索型開発と向き合う、kintoneプラットフォームエンジニアリングの挑戦人と文化の両面から、PfE部の今とこれからを探るプラットフォームは機能や基盤の進化だけでなく、そこに関わる人たちの考え方や文化も重要です。こんにちは。プラットフォームエンジニアリング部所属の aki (@aki366) です。前回に引き続き 上岡 (@ueokande) さんと 三苫 (@mitomasan) さんにお話を伺っていきたいと思います。この記事の構成は以下の通りです。人と文化の両面から、PfE部の今とこれからを探るPfE部の今Q. 今のPfE部には、どんなメンバーが集まっていますか？Q. このチームらしさはどこに現れますか？PfE部のこれからQ. 今後、プラットフォームとしての役割はどのように進化していきそうですか？Q. そのために、どんな文化を育てていきたいですか？Q. 今、PfE部を拡大させたいと考えている理由は何ですか？PfE部が大切にしたい人の姿勢Q. PfE部にフィットする思考とは？Q. 「こういう人は活躍しているな」と感じる共通点は？最後にここまで読んでくださった方に向けて、メッセージをお願いします。インタビューを終えてPfE部の今Q. 今のPfE部には、どんなメンバーが集まっていますか？上岡：aki：上岡：aki：三苫：三苫：利用者の生産性をどう伸ばせるかを考える。そのうえで、相手の意見にきちんと耳を傾け、フラットに受け止めたうえで、自分なりに咀嚼して判断できる。aki：Q. このチームらしさはどこに現れますか？上岡：「なぜそうしたのか」を技術的な確証を持って説明できるところは強みだと思っています。aki：三苫：上岡：PfE部のこれからQ. 今後、プラットフォームとしての役割はどのように進化していきそうですか？上岡：本当に作りたいものを実現できるようにしていきたいですね。aki：三苫：上岡：aki：Q. そのた

この記事はkintone生成AIチームで連載中のkintone AI リレーブログ 2026 の8本目の記事です。リレーブログでは生成AIチームのメンバーがAIトピックに限らず、さまざまなことについて発信していきます。こんにちは！ kintone の生成 AI チームでソフトウェアエンジニアをやっている福田です。以前の記事で生成 AI チームで Kubernetes の基盤を構築してアプリケーションを運用していることをご紹介しました。アプリケーションを運用する上で、セキュリティは欠かせない要件の 1 つです。セキュリティと一口に言ってもさまざまな側面での対策が考えられますが、アプリケーションによる通信を無条件で許可するのではなく、必要な経路に絞って許可することは最も基本的な対策のひとつなのではないでしょうか。Kubernetes ではこのような要件に対応するための仕組みとして NetworkPolicy という仕組みが用意されています。この記事では EKS Auto Mode 環境で NetworkPolicy をどのように適用しているか、そして、実際に遭遇したハマりどころと解決方法を共有します。NetworkPolicy の基本Kubernetes の NetworkPolicy は Pod の通信を IP アドレスとポート単位で制御できる仕組みです。NetworkPolicy は Namespace 単位のリソースとなっており、1 つの NetworkPolicy リソースを複数の Namespace の Pod に適用することはできません。（ある Namespace の Pod から他の Namespace の Pod への通信を許可することはできます。）指定方法としては ある Pod が通信できる相手を Pod の selector または CIDR 範囲で指定します。それぞれの用途としては、クラスタ内の Pod を指定したい場合は Pod の selector、通信元や通信先としてクラスタ外部を指定したい場合は CIDR 範囲で指定することになります。NetworkPolicy はステートフルに通信を制御するので、通信先の egress が許可されていれば戻りの通信も許可されます。ただし、通信先の Pod に NetworkPolicy が適用されている場

こんにちは！サイボウズでプロダクトエンジニアをしている @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 の設計│ │ └── glossa

状況が変化する中での意思決定前回記事 なぜ、kintoneにプラットフォームエンジニアリング部は生まれたのか で触れた、プロダクト開発とプラットフォーム開発の 「時間軸の違い」。探索型プロダクト開発（短期）仮説検証 / 変更前提 / 速度重視プラットフォーム（長期）安定運用 / 先回り設計 / 継続投資どちらも正しい。いま私たちが直面しているのは、「どちらが正しいか」ではなく、複数の選択肢の中から何を選ぶかという問題です。選択肢が増えた世界で、どうやって選び続けるのか。こんにちは。プラットフォームエンジニアリング部所属の aki (@aki366) です。この記事の構成は以下の通りです。状況が変化する中での意思決定なぜプラットフォームは難しいのかQ. 今のPfE部で、率直に難しいと感じていることは何ですか？Q. 組織面と技術面、それぞれで課題はありますか？PfE部は何を担う存在なのかQ. インフラエンジニアやSREと比べると、どんなところが違うと思いますか？Q. 改めて、PfE部の役割を一言で表すとしたら何でしょう？Q. 逆に、「これはプラットフォームエンジニアリングっぽくないな」と感じる行動はありますか？PfE部のEMは、いま何に取り組んでいるのかQ. アラインメントで大変なこと、意識してることってありますか？Q. 複数の選択肢が並んだとき、優先順位を決めるのが難しかった判断はありましたか？PfE部が目指す未来とはQ. 少し先の未来ですが、PfE部はどんな状態になっていたら嬉しいですか？変わり始めている今、どう向き合っているのかQ. 今のフェーズの面白さは、どこにあると思いますか？まとめなぜプラットフォームは難しいのかQ. 今のPfE部で、率直に難しいと感じていることは何ですか？aki：前回に引き続き 上岡 (@ueokande) さんと 三苫 (@mitomasan) さんにお話を伺っていきたいと思います。まずは、今のPfE部で率直に難しいと感じていることから伺います。上岡：今だとプロダクト開発側が、デプロイ先のプラットフォーム間の差分として全文検索で使っている OpenSearch か Elasticsearch かを意識しないといけない。補足：国内市場向けのcybozu.comと、グローバル市場向けのkintone.comは異なるプラットフォームを使用してい

この記事はkintoneの生成AIチームで連載中のkintone AIリレーブログ2026の7本目の記事です。 リレーブログでは、生成AIチームのメンバーがAIトピックに限らずさまざまなことについて発信していきます。こんにちは、kintoneの生成AIチームでエンジニアリングマネージャーをしている立山です。みなさんのチームはAIを活用していますか？ここ最近はコーディングエージェントが高速にそこそこいいコードを作ってくれる時代で、個人の開発生産性は上がっていると思います。一方で、チームでAIを活用するというのはまだまだ限られているのではないでしょうか？この記事ではチームでAI、特に自律的に仕事を進めてくれるAIエージェントとの協業のはじめ方についてお話ししようと思います。私たちのチームでは、AIエージェントとの協業を始めるにあたって、以下の3つに取り組みました。仕事を言語化し、Agent Skills として定義する — 「すごいAIシステム」を作る意識ではなく、まず仕事の形を整え、AIに委任できる手順に落とし込むチームで共有可能な資産にする — 個人のノウハウに留めず、チーム全体で使える共通資産として運用する失敗できる環境を整える — AIが失敗しても素早く検知・復旧できる安全網を敷き、安心して委任できるようにする※ この記事ではチームがClaude Codeを使っている前提で話を進めますが、他のAIツールを使っていても同様の考え方が適用できると思います。 なぜチームでのAIエージェント活用が必要なのか仕事を言語化し、Agent Skills として定義するAIエージェントに移譲する仕事の範囲を決める仕事を自然言語・Agent Skillsで記述するチームで共有可能な資産にする失敗できる環境を整えるSmoke Testによるデプロイ検証Application Signals SLOとアラートAIエージェントと協業できる環境の効果チームのナレッジ共有が加速する本業に集中できる開発サイクルのスピードが上がる今後の課題ドキュメントの管理場所の最適解リモートでエージェントを動かす実行環境まとめWe are hiring!なぜチームでのAIエージェント活用が必要なのかAIツールの進化は目まぐるしく、状況は日々変わっています。そのなかで積極的に活用しているのはAIに関心のある一

speakerdeck.comこんにちは！サイボウズOfficeという製品でQAをしている水谷(@dog_dog_3dog)です。社内で「LLMアプリの品質保証 ～LLMの特性から全体像まで～」というテーマで勉強会を主催しました。この記事では、勉強会の内容と開催の背景を簡単に紹介します。資料の内容資料では、ざっくり以下のような流れで話をしています。COMPASからのケーススタディ LLMアプリ独自の品質特性 リスク分析 LLMアプリ全体の品質保証 開催の背景私がLLMアプリの品質保証に取り組み始めた頃、全体像を俯瞰できる資料が少なく、テストの枠組みを考えるのに苦労しました。そこで、今後社内で別のLLMアプリが開発される時に全体感を掴むための一つのきっかけになればと思い、勉強会を実施しました。なお、この勉強会は、産業技術総合研究所（産総研）が主催する「AI品質マネジメント講座」に参加させていただいたことに影響を受けて企画したものです。講座で多くのことを学ばせていただきました。産総研と講師の皆さまには大変お世話になりました。おわりに自分自身もまだまだ試行錯誤の途中ですが、この資料がこれからLLMアプリの品質保証を考える方のとっかかりになれば嬉しいです。

この記事は kintone の生成 AI チームで連載中の kintone AIリレーブログ 2026 の 6 本目の記事です。 リレーブログでは、生成 AI チームのメンバーが AI トピックに限らずさまざまなことについて発信していきます。こんにちは！kintone 生成 AI チームの 386jp です。前回の記事「cdk8s を使ってみた！ - TypeScript で Kubernetes を管理する実践 Tips」では、 cdk8s を導入した背景と実感したメリットを紹介しました。今回は、より実践的な内容として、私たちのチームが cdk8s を使う上で工夫しているパターンを詳しく紹介します。目次:前回のおさらいkintone AI チームでの活用core と apps によるコンポーネント管理config ディレクトリ: 設定ファイルを簡単に管理するresources ディレクトリ: CRD を TypeScript の世界に取り込むsrc/resources ディレクトリ: よく使うマニフェスト定義をまとめるまとめWe are hiring !!前回のおさらい前回の記事では、 cdk8s の概要と、 TypeScript で Kubernetes マニフェストを管理するメリットを紹介しました。今回は、私たちのチームが実際にどのような工夫をしているか、具体的な実装パターンを紹介します。kintone AI チームでの活用私たちのチームでは、複数環境への対応、再利用可能なコンポーネント化を意識して、以下のような構成を採用しています。まずはディレクトリ構成から、全体像を見てみましょう:our-awesome-cdk8s-project├── config # 設定ファイルの保存場所├── resources # CRD の TypeScript 定義を配置└── src ├── apps # k8s マニフェストの内容を記述 ├── core # k8s マニフェストの内容を記述 ├── config # 設定ファイルの parse など ├── resources # 再利用できそうなコンポーネントをまとめたもの ├── test └── utilそれでは、各ディレクトリの役割と使い方を詳しく見ていきます。core と apps によるコンポーネント管理チー

こんにちは！サイボウズのトニオ（@tonionagauzzi）です。普段はkintone開発チームにてAndroidアプリを主に開発しています。今回は、ディップ株式会社、株式会社Voicy、株式会社ヤプリ、そしてサイボウズ株式会社の4社合同でモバイル勉強会を開催しました。本記事では、イベントの概要と当日の様子をお届けします！イベントの概要イベント情報当日の様子LT (1) : AIとなら実現できる事業と品質のシン化の両立LT (2) : OSアップデート：年に一度の「大仕事」を乗り切るQA戦略LT (3) : "レビュー"だけだったAI活用から半年。ヤプリのiOS開発・運用はどう変化したか？LT (4) : 謎現象の解決手段を発見して プチ英雄になりましたLT (5) : Claude × Markdown で仕様書をいい感じに管理したいLT (6) : Kotlin Multiplatform + iOS アーキテクチャの実践LT (7) : バイトルiOSアプリのリアーキテクト / SwiftPMとAIルールで実現するモジュール設計懇親会まとめイベントの概要Mobile Tech Flexは、モバイルアプリ開発に携わる人々が集まり、各自の取り組みをLT形式で発表する合同勉強会です。DroidKaigi 2025の会場やアフターイベントで出会った4社のメンバーたちが2025年末から開催準備を進め、無事開催することができました。今回のテーマは「モバイル開発で自慢したいこと」です。技術的な挑戦、チームの文化、プロダクトへのこだわりなど、各社が「ここを見てほしい！」というポイントを持ち寄って共有することで、お互いの学びを深め、モバイルコミュニティを発展させるねらいがあります。ソフトウェアエンジニアだけでなくQAエンジニアなど幅広い職能に参加させてもらえるよう、職能の壁を越えた交流を意識し、勉強会のテーマ決めを行いました。会場は六本木の株式会社ヤプリで、29名の方に事前申し込みいただきました。六本木の高層からの絶景！おしゃれなカフェスペースでした！イベント情報イベント名：Mobile Tech Flex 〜4社合同！私たちのモバイル開発自慢大会〜開催日：2026/02/16(月) 19:00開始会場：株式会社ヤプリ共催：ディップ株式会社 / サイボウズ株式会社 / 株式会

こんにちは、ソフトウェアエンジニアの @ajfAfg です。弊社には複数のヘルプサイトが存在しますが、その一部を半年ほどで刷新しました。刷新と呼んでいますが、WOVN という多言語化用 SaaS の導入に加え、ヘルプサイトのコンテンツを作成するテクニカルライターの生産性向上を狙った取り組みも含まれていました。本稿では、刷新プロジェクトの中で私が担当した取り組みを紹介します。なお、本稿では特に断りがない場合、旧ヘルプサイトは刷新前のヘルプサイトを指し、新ヘルプサイトは刷新後のヘルプサイトを指すものとします。文脈から明らかな場合は単にヘルプサイトと書く場合もあります。目次目次背景刷新プロジェクトのスコープ刷新プロジェクトにおけるインフラのゴール旧ヘルプサイトのインフラ旧ヘルプサイトのインフラに関する技術的負債ほぼ全てのインフラが手動で構築されていたテストや監視がなかったリージョン間の意図しない差分が多かった事前調査および技術選定コンテンツ管理システム静的サイトジェネレーターホスティングサービスクラウドベンダーインフラ構築WOVN 導入WOVN 導入のモチベーションWOVN の導入方法静的サイトの配信基盤の構築Netlify のリダイレクトの仕組み（redirects）の模倣redirects 速習リダイレクトの基本リダイレクトを強制する404 リライト200 リライトパスを展開する新ヘルプサイトにおける redirects の実装新ヘルプサイトにおける独自仕様WOVN プロキシへのリライトredirects を模倣する仕組みのパフォーマンス登場人物がやや多い理由CloudFront のオリジンとして S3 を設定しない理由DynamoDB の役割検索基盤の構築検索基盤の仕組みGoogle 検索に似るシンタックス・セマンティクスで検索可能にする仕組みプレビュー環境の構築プレビュー環境の要件プレビュー環境の仕組みプレビュー環境の認証監視基盤の構築Terragrunt を用いた Terraform コード設計インフラの要求Terraform コード設計Lambda 関数のコード設計今回の設計で良かったこと・悪かったことテクニカルライターの生産性向上textlint の導入textlint によるリンク切れチェックの仕組みtextlint のプラグイン開発ヘルプサイトを Git

この記事はkintoneの生成AIチームで連載中の kintone AI リレーブログ 2026 の 5 本目の記事です。リレーブログでは、生成 AI チームのメンバーが AI トピックに限らずさまざまなことについて発信していきます。こんにちは！kintone の生成 AI チームでバックエンド開発・運用を担当している齋藤です。日頃 AI 機能やその基盤の開発・運用などの業務に取り組んでいる私たちですが、 今回は私たちが AI をどのように活用しているのかという話の一つとして、 チーム専用の Claude Code の Plugin マーケットプレイス を作った話を紹介します。Claude Code の導入と「配布」の課題Cybozu では、昨年（2025年）夏ごろからコーディングエージェントツールとして Claude Code を導入しておりました。今年からは Claude の Team Plan が全社展開されるようにもなり、AI ツールの活用はますます加速しています。Claude Code を使い始めると、各メンバーがそれぞれに便利なプロンプトを書いたり、MCP Server を設定して AWS や GitHub と連携させたりするようになったのですが、それを配布する仕組みも当時はなかったため、個々人が各々の方法で管理・設定している状態でした。MCP Server の設定は接続先の URL やコマンド、環境変数などを正しく書く必要があり、意外と面倒です。「この設定で動いたよ」というのを共有し、各自が手で settings.json に貼り付ける、といったような運用をしていました。転機：Plugin と Skills の登場2025年10月、Claude Code に Plugin 機構が追加されました。同時期に Anthropic から Agent Skills も発表され、12月にはオープンスタンダードとして公開されています。これにより、MCP Server の設定だけでなく、各自が持っていた「秘伝のプロンプト」を Skill としてパッケージ化 し、チームに配布できるようになりました。Plugin を通じて Claude Code に追加できる機能は主に3つです。Skills : AI が自動的に発動するプロンプトテンプレートMCP Server : 外部

「この部って具体的に何をするんだろう？」プラットフォームエンジニアリング部に配属されて、最初に浮かんだのはそんな戸惑いにも似た疑問でした。aki (@aki366) です。kintoneの開発部門には、「プラットフォームエンジニアリング部（以下、PfE部）」があります。社内外からも、「kintoneのPfE部って何をする部なの？」「なぜ今、このタイミングで立ち上がったの？」といった声をよく耳にしますし、それは私自身が抱いていた疑問でもありました。そこで今回、PfE部立ち上げを牽引してきたお二人に直接インタビューしました。本記事では、PfE部が生まれた背景や狙いを、対談形式でひも解く3部作のインタビューをお届けします。PfE部ができた生い立ちについてお送りします。「kintoneのPfE部って、なんだろう？」この記事の構成は以下の通りです。「この部って具体的に何をするんだろう？」自己紹介なぜ今、PfE部が生まれたのかQ. PfE部が立ち上がる前って、どんな状況だったんでしょうか？Q. もしこのままバックエンドのままだったら、厳しかったポイントってありますか？Q. PfE部を立ち上げると決めたとき、率直にどんな気持ちでしたか？Q. なぜ “プラットフォームエンジニアリング” という選択をしたのですか？立ち上げ初期のリアルQ. 部の立ち上げ当初、一番大変だったことを教えてくださいQ. 社内からはどんな声や反応がありましたか？正解のない中で、設計し続ける自己紹介aki：aki (@aki366) です。開発本部/kintoneプラットフォーム副本部/プラットフォームエンジニアリング部/サービスプラットフォーム副部/サービスプラットフォーム（Yakumo）チーム / 奥田 晃洋三苫：三苫 (@mitomasan) です。開発本部/kintoneプラットフォーム副本部/プラットフォームエンジニアリング部 副部長 三苫 亮上岡：上岡 (@ueokande) です。開発本部/kintoneプラットフォーム副本部/プラットフォームエンジニアリング部 部長 / 上岡 真也aki：なぜ今、PfE部が生まれたのかQ. PfE部が立ち上がる前って、どんな状況だったんでしょうか？上岡：ref:サイボウズ流エンジニア組織の作り方 | CodeZine , ref:エンジニアが主導できる組織づくり

この記事は kintone の生成 AI チームで連載中の kintone AIリレーブログ 2026 の 4 本目の記事です。 リレーブログでは、生成 AI チームのメンバーが AI トピックに限らずさまざまなことについて発信していきます。こんにちは！kintone 生成 AI チームの 386jp です。突然ですが、みなさんは Kubernetes のマニフェストをどのように生成・管理していますでしょうか?ArgoCD で GitOps を実践されている方であれば、Kustomize や Helm、Jsonnet などのツールで管理されているかと思います。サイボウズでも、これらのツールを活用してマニフェストを生成していることが多いです。これらのツールは非常に強力ですが、それぞれ独自の記法が採用されており、構文でつまづくことがあるという共通の課題があります。Helm は Go テンプレートの知識が必要で、Jsonnet も独自の記法を覚える必要があり、Kustomize も overlay の仕組みでつまづくケースがあります。そこで、 kintone 生成 AI チームでは、 cdk8s を導入することで、これらの課題を解決しました。本記事では、 kintone 生成 AI チームが cdk8s を導入した背景と、実際に使ってみて感じたメリットを紹介します。 Kubernetes マニフェストを管理する上で、 TypeScript で管理するという選択肢もあります。これから cdk8s を使ってみたい方の参考になれば幸いです。目次:kintone 生成 AI チームでの課題cdk8s とはcdk8s を選んで良かったことTypeScript の恩恵を受けられる再利用可能なコンポーネント化柔軟な設定管理cdk8s の基本的な使い方基本概念簡単なコード例まとめWe are hiring !!kintone 生成 AI チームでの課題さて、私たちのチームは、 AI という変化の激しい領域に対応するため、チーム独自で AWS 基盤を構築し、 kintone の AI 機能を提供しています。「kintone AI でも Kubernetes はじめました」という記事で紹介した通り、 EKS を用いた Kubernetes 基盤を最近構築しました。この基盤の立ち上げにあたり、

この記事は kintone の生成 AI チームで連載中の kintone AI リレーブログ 2026 の 3 本目の記事です。リレーブログでは、生成 AI チームのメンバーが AI トピックに限らずさまざまなことについて発信していきます。こんにちは！@takamin55 ) です。Cybozu には「大人の体験入部」や「兼務」といった制度があり、所属チームの枠を超えた活動を通じてキャリアの可能性を広げることができます。cybozu.backstage.cybozu.co.jpcybozushiki.cybozu.co.jpkintone 生成 AI チームは AI 機能を開発するだけでなく、自分たちの開発プロセスにも AI を積極的に活用し、日々その可能性を探求しています。この記事では、その取り組みの 1 つとして Renovate の運用を Claude Code を使って効率化した事例を紹介します。Renovate 運用にまつわる課題kintone 生成 AI チームでは Renovate を使って依存関係を定期的にアップデートし、安全なプロダクトを提供できるよう心がけています。定期的に作成される Renovate の PR に対しては、以下のような対応を行なっていました。変更差分のリリースノートを確認し、破壊的変更やその他の影響を調査する影響がある場合はコードを修正するレビューするマージしかし「少人数チームである」×「複数リポジトリを持っている」という条件が重なり、Renovate の負荷が大きいという声がチームの振り返りで上がりました。devDependencies の自動マージや packageRules を使ったグルーピングで PR をまとめて数を減らすなど、負荷軽減の工夫はしていたものの、みな終わりのない Renovate 業務に疲弊していたのです。Renovate 対応のつらさを物語る書き込み（もちろん冗談です）そこで Renovate 運用の負荷軽減に注目が集まりました。特にリリースノートの確認と影響調査の作業を AI で自動化できれば、チームにとって以下のようなプラスの効果が期待できると考えました。Renovate PR の影響調査にかかっていた時間が削減され、メイン業務に集中できるRenovate タスクに取り組むハードルが下がる。結果とし

この記事は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 の