kintoneのダッシュボード開発チームの紹介 - チャレンジ & わいわい
プロダクトエンジニアの谷(@uta8a)です。2025年にkintoneのダッシュボード開発チームにジョインして、1年半近くプロダクトエンジニアとして働き、kintoneの性能ダッシュボード、利用状況ダッシュボードのリリースに関わってきました。今日はチーム紹介をします！ kintoneを、もっと安心して大規模に活用していくために必要なこと kintoneは、様々な業務システムが作れる業務改善プラットフォームです。 現在42,000社(執筆時点)に使われているkintoneは、多様な業務を支えています。しかし、大規模利用に伴い足りない部分も出てきました。 アプリの操作が重いという問い合わせを、現場からIT部門が受け取る IT部門がkintoneの活用を促進していきたいが、どう使われてきたのか分からない こうした大規模利用に伴う不安への対応や、もっとkintoneの利用を拡大していくための後押しが必要です。 これらの課題はお客様が現状を把握できることがまず必要だと考え、kintoneの状態を時系列で把握できるような、管理者向けダッシュボード機能を開発しています。 (性能など、改善もセットで必要な部分は別チームで取り組んでいます！ *1 ) ダッシュボードの開発によって、例えば次のような効果を目指しています。 このペースの利用増だと性能問題が起こりそう。性能カスタマイズオプションを検討しよう 社内のkintone活用の実態が分かった。全社導入に向けて動いていきたい このようにして、もっと安心して大規模にkintoneを活用していける世界を目指しています。 もっと安心して大規模にkintoneを活用していける世界を目指しています kintoneのダッシュボード開発チームの取り組み 今までに、3つの種類のダッシュボードをリリースしています。 性能ダッシュボード 大規模利用顧客向けに、アプリの性能情報を見て改善の効果測定に役立てる 利用状況ダッシュボード 社内のkintone活用状況を見て、活用促進に繋げられる 社内向けダッシュボード サイボウズ社内でのお問い合わせ対応や、次に作るダッシュボードを考えるヒントとして利用する これらのダッシュボードで価値を素早く提供するために、以下のような取り組みをしています。 既存プロダクトとビジョンを共有しつつ、作るものを自分たちで決める ダッシュボード開発はkintone本体とは独立したチームとして開発している プロダクトエンジニアとして、kintone本体の理解を深めつつダッシュボードの役割を考えて開発 チームで意思決定の精度を上げていく 開発速度だけでなく、何を作るか、どういう順番でタスクを進めるかといった意思決定に関する会話がチームで行われる ツール・環境・プロセスを柔軟に試して取り入れる AIツール(Claude Codeなど)はもちろん、小さなチームだからこそ柔軟にやりやすいように開発プロセスを変えていける強み Findy Team+を利用して開発にまつわるメトリクスを活用した振り返り 個人的には、特に意思決定の精度は高いなと感じます。AIによってやることが高速になっても、無駄なことをたくさんやっていたらあまり嬉しくないです。結局何をやるか、どういう順番で進めていくかという意思決定の精度が重要だと思います。例えば、チームの朝会で会話を通してその視点あるなぁ...という気持ちになったりすることがあり、チームで意思決定の精度を上げていると思っています！ チャレンジ & わいわい チームの雰囲気としては、kintone開発の中でも比較的パイオニア寄りというか、小さく実験的なチームなのでチャレンジしていこうという感覚が強いです！とりあえずやってみたいことは試してみて、ダメだったら撤退できる環境であり続けたいと思っています。チャレンジ！ あと、あまり枠組みにとらわれずわいわい越境していこうというのも特徴的です。例えば、私はもともとAWS周りのインフラをメインで取り組んでいたのですが、チームで働く中でフロントエンドのタスクを取ったり、デザイナーやEMと作るものについて議論したりと活動範囲を広げることができました。 リリース後のオンラインお祝いや、対面でのチームビルディングも盛り上がります！わいわい！ 対面でのチームビルディングでみんなで作ったご飯。盛り上がりました。 一緒に働きましょう もっと安心して大規模で使えるkintoneを目指して、ダッシュボード開発に一緒に取り組んでくれる仲間を募集しています！ cybozu.co.jp 小さなチームで大きなインパクトを起こすことに興味があれば、ぜひカジュアル面談からでもお話しましょう。 *1:性能カスタマイズオプション など
- kintone
- AWS
- フロントエンド
Amazon EKS Auto Mode + NetworkPolicy のハマりどころ
この記事は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 が適用されている場合、その Pod の ingress として通信元の Pod を指定しないと通信ができないので注意が必要です。 Pod に NetworkPolicy が適用されると、その Pod は ingress/egress いずれかが「隔離された」状態になり、許可された通信以外は拒否されるようになります。 例えば、ある Pod に ingress の通信を制御するポリシーが 1 つでも存在すれば、その Pod は許可された経路以外の通信は受け入れなくなります。 egress の場合も同様に、Pod に割り当てられたポリシーが 1 つでも存在すれば、その Pod は許可された経路以外に通信できなくなります。 以下は app-1 namespace の app=hoge というラベルを持った Pod から app-2 namespace の app=fuga というラベルを持った Pod への通信を許可するような NetworkPolicy の例です。 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-hoge-egress namespace: app-1 spec: egress: - ports: - port: 80 protocol: TCP to: - podSelector: matchLabels: app: fuga podSelector: matchLabels: app: hoge policyTypes: - Egress このポリシーだけを適用した場合、app-2 の app=fuga に ingress ルールが 1 つも適用されていない場合は通信できます。 適用されている場合は以下のルールも追加で適用する必要があります。 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-fuga-ingress namespace: app-2 spec: ingress: - ports: - port: 80 protocol: TCP from: - podSelector: matchLabels: app: hoge podSelector: matchLabels: app: fuga policyTypes: - Ingress EKS Auto Mode での NetworkPolicy の有効化 Amazon EKS Auto Mode では Amazon VPC CNI（以下 VPC CNI）を使用してネットワークの設定を行う構成になっています。 VPC CNI はデフォルトでは NetworkPolicy が使用できませんが、ConfigMap を作成して NodeClass で有効化することで簡単に有効化できます。 デフォルトで作成される NodeClass では既に有効化されているので、実質的には ConfigMap を 1 つ作成するだけで有効化できます。 apiVersion: v1 kind: ConfigMap metadata: name: amazon-vpc-cni namespace: kube-system data: enable-network-policy-controller: "true" このような ConfigMap を作成することで、NetworkPolicy がデフォルト allow の状態で有効化されます。 デフォルト deny にするには NodeClass の設定を変更する必要があります。デフォルトで作成される NodeClass の設定を変更することはできないようなので NodeClass を自分で定義する必要があり、やや複雑な設定が必要になります。 NetworkPolicy の適用方針 私たちの環境では、デフォルトで全ての ingress と egress の通信を拒否しておき、必要な経路のみで通信を許可する方針で NetworkPolicy を適用しています。 このようにすることで、通信経路を明示的に許可する必要があるため、意図しない通信を防止できます。 一方で、必要な通信経路を全て許可するための NetworkPolicy を定義する必要があるため、運用の手間が増えるのはデメリットです。 このデメリットを軽減するための工夫については後述します。 ハマったところ DNS 解決のために Node 上のプロセスとの通信許可が必要 ある Pod からクラスタ上の他のサービスの名前解決を行うためには、クラスタの CoreDNS と通信する必要があります。EKS Auto Mode では CoreDNS はクラスタ上の Pod としてではなく、ノード上のプロセスとして起動するため、Pod の selector は使用できず、ipBlock を使用して IP アドレス単位のアクセス許可を行う必要があります。 Kubernetes 上で Pod が CoreDNS と通信可能にするためには、kube-system namespace 内の k8s-app: kube-dns というラベルを持った Pod に対してアクセス許可を設定すればよいことが多いです。 しかし、EKS Auto Mode では CoreDNS は Pod としてではなくノード上のプロセスとして起動するため、Pod の selector を使用してアクセス許可を設定することができません。 代わりに、EKS Auto Mode では、CoreDNS はクラスタ CIDR の .10 で終わる IP アドレスに割り当てられる1ため、以下のような ipBlock を指定するルールを適用する必要がありました。 apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-egress-to-coredns namespace: your-namespace spec: egress: - ports: - port: 53 protocol: UDP - port: 53 protocol: TCP to: - ipBlock: cidr: <cluster-cidr>.10/32 podSelector: matchLabels: app: your-app policyTypes<span class="synSpeci
- Kubernetes
- EKS
- セキュリティ
- AWS
- TypeScript