【概要のみ紹介】AWS Cost Anomaly Detection に Amazon Q による「AI コスト調査」が追加されました
はじめに 何がうれしいのか 仕組み（How it works） 前提条件（Prerequisites） 料金 使い方 手順 1: コスト管理コンソールを開く 手順 2: Cost Anomaly Detection を開く 手順 3: 検出された異常を選ぶ 手順 4: Investigate with Amazon Q を実行する 手順 5: 調査結果を読む 手順 6: フォローアップ質問で深掘りする クロスアカウント調査について 制限事項（Limitations） まとめ 参考リンク 余談 アプリケーションサービス部エデュケーショナルサービス課の山本です。 中途社員のトレーナー業務をしていま…
- AWS
- コスト削減
PRごとに検証環境が立ち上がる仕組みをTerraform × GitHub Actionsで作った話
【デジカルチーム ブログリレー 3日目】 クラウド型電子カルテデジカルチームの黒木です。 最近、私たちのチームで 「Pull Requestごとに、そのコードがそのまま動く環境が自動で立ち上がる」仕組み──いわゆる PR環境（ephemeral environment / preview environment）を構築しました。 なぜ作ったのか 設計の方針 実装のポイント 1：stateを「1 PR = 1 state」で完全分離する 2：DBはPRごと、クラスタは共有 3：ALB Listener Ruleの優先度をPR番号から決める 4：デプロイワークフロー（ラベル起点） 5：破棄ワークフロー（PR close + 毎朝の掃除） まとめ We are hiring! なぜ作ったのか 普段からプロダクト開発を続けるなかで、こんな不満がじわじわ溜まっていました。 レビューでコードは読めても、実際に触ってみないと分からない。特にフロントエンドの見た目や操作感 Storybookはあるものの、モックの限界がある かといってレビュアー全員が git fetch してブランチを切り替えてローカル起動……は何かと面倒 共有のステージング環境は限られた数しかなく、調整や、たまに順番待ちも発生する 「このPR、ちょっと触ってみたいんだけど」が気軽にできず、これを解決したいというのが出発点です。 完成後はPRに preview ラベルを付けると、数分後にBotがこんなコメントを返してきます。 ## 🚀 PR Dev Environment https://PR固有のID.preview.example.dev にデプロイしました (commit `a1b2c3d`)。 - DB は毎回リセットされます。手動で投入したデータは消えます - 再デプロイしたい場合は `preview` ラベルを一度外してから再付与してください - ラベルを外しても環境は残ります。最終デプロイから 3 日経過するか、PR がクローズされたタイミングで自動削除されます URLを開けば、そのPRのコードがそのまま動く環境にアクセスできます。レビュアーも、非エンジニアのステークホルダーも、URLを踏むだけで動作検証が可能です。 設計の方針 PR環境を作るうえで最初に決めたのは「何を環境横断で共有し、何をPRごとに作成するか」でした。 PRごとに VPC や RDS クラスタまで丸ごと作っていては、コストも起動時間もかかりすぎます。一方で、アプリのコンテナや DB のスキーマは PR ごとに完全に独立させたいので、次のように役割を割り当てました。 グループ 扱い 具体例 共有インフラ 全PRで使い回す VPC、ALB、Aurora（RDS）クラスタ、ECSクラスタ、ECR、CloudFront、ワイルドカードDNS per-PR リソース PRごとに生成・破棄 ECSサービス群、ALB Target Group / Listener Rule、DBスキーマ、他SQSキュー等 ルーティングは、共有ALBにPRごとのListener Ruleを足していく方式です。PR固有のID.preview.example.dev というホストヘッダーで振り分け、そのPR専用の Target Group（= ECSサービス）へ転送します。DNSは *.preview.example.dev のワイルドカードレコードを共有インフラ側に1つ用意しておけば、PRごとにレコードを作る必要はありません。 実装のポイント 1：stateを「1 PR = 1 state」で完全分離する PR環境の実体は、1つの Terraform スタックです。ポイントは state を PR ごとに完全に分けていることです。 # backend.tf （key は CI 側から動的に渡す） terraform { backend "s3" { bucket = "example-terraform-state" # key は terraform init -backend-config で指定する } } CI側では、PR番号から state のキーを組み立てて init します。 terraform init -backend-config="key=states/${PR_NUMBER}.tfstate" terraform apply -auto-approve \ -var="pr_number=${PR_NUMBER}" \ -var="image_tag=${IMAGE_TAG}" これにより、 PRごとのリソースが互いに干渉しない（state が別なので、他PRの apply / destroy の影響を受けない） 並列に何個でも PR環境を立てられる 破棄はそのPRの state に対して terraform destroy するだけ という性質が手に入ります。共有インフラの情報（VPC ID、ALBの Listener ARN、Aurora のエンドポイントや ARN など）は、別管理している共有スタックの state を terraform_remote_state で参照して取得します。 2：DBはPRごと、クラスタは共有 RDSクラスタを PR ごとに立てると、起動に時間がかかるうえコストもかさむので、CREATE DATABASE pr_123 のようにそのPR専用のDBを作成し、そこにマイグレーションとシードデータを流すだけにします。 これを Terraform の terraform_data リソース + local-exec プロビジョナで実現しています。apply 時に CREATE DATABASE、destroy 時に DROP DATABASE します。SQLの発行には RDS Data API（aws rds-data execute-statement）を使いました。 resource "terraform_data" "db_bootstrap" { triggers_replace = { pr_database_name = local.pr_database_name # 例: "pr_123" } # apply 時：存在しなければ CREATE DATABASE provisioner "local-exec" { interpreter = ["/bin/bash", "-c"] command = <<-EOT EXISTS=$(aws rds-data execute-statement ... \ --sql "SELECT 1 FROM pg_database WHERE datname = '${self.output.pr_database_name}'" \ --output json | jq '.records | length') if [ "$EXISTS" = "0" ]; then aws rds-data execute-statement ... \ --sql "CREATE DATABASE ${self.output.pr_database_name}" fi EOT } # destroy 時：接続を切ってから DROP DATABASE provisioner "local-exec" { when = destroy command = <<-EOT aws rds-data execute-statement ... \ --sql "SELECT pg_terminate_backend(pid) FROM pg_stat_activity WHERE datname = '${self.output.pr_database_name}' AND pid <> pg_backend_pid()" aws rds-data execute-statement ... \ --sql "DROP DATABASE IF EXISTS ${self.output.pr_database_name}" EOT } } ※ ECSサービスがDBに繋ぎっぱなしだと DROP が失敗するので、DROP DATABASE の前に pg_terminate_backend で明示的に切断しています 3：ALB Listener Ruleの優先度をPR番号から決める 共有ALBに複数PRの Listener Rule がぶら下がるので、ルールの優先度（priority）が PR 間で衝突しないようにする必要があります。 これはシンプルに priority = PR番号 としました。PR番号が50000に到達すると問題になりますが、現状まだ大丈夫です。 4：デプロイワークフロー（ラベル起点） デプロイの起点は、PRへの preview ラベル付与です。opened / synchronize で毎回立てるのではなく、レビュアーや作者が明示的にラベルを付ける運用にしています。これでコストを必要なときだけに抑えられます。 on: pull_request: types: [labeled] jobs: deploy: if: github.event.label.name == 'preview' concurrency: # DB操作の途中でキャンセルされて環境が壊れるのを防ぐため、 # cancel-in-progress: false（キャンセルせず順番待ちにする） group: pr-dev-env-deploy-${{ github.event.pull_request.number }} cancel-in-progress: false ジョブの流れは次のとおりです。 PRのheadコミットをチェックアウト OIDCでAWSへ認証（長期キーは持たない） バックエンドのコンテナイメージをビルドしてECRへpush フロントエンドをビルド terraform init（PRごとのstateキーを指定）→ terraform apply フロントエンドの成果物をS3の pr-{N}/ プレフィックスへsync、CloudFrontをinvalidate ECSサービスが安定するまで待機（aws ecs wait services-stable） ECS Exec経由でDBを初期化 プレビューURLをPRにコメント（既存コメントがあれば更新） マイグレーションとシードデータ投入は、起動済みの api コンテナの中で実行しています。aws ecs execute-command でコンテナに入り込み、初期化 → マイグレーション → シード投入の順で叩きます。 ここで注意点があります。aws ecs execute-command は、リモートで実行したコマンドの終了コードを呼び出し元に伝播してくれません。セッションさえ確立できれば、リモート側が失敗していてもCLI自体は exit 0</code
- Terraform
- GitHub Actions
- AWS
- ECS
- Infrastructure as Code
「Commit to Thailand」——AWS Summit Bangkok 2026 で感じた東南アジアの熱量
こんにちは、サーバーワークス松本です。2026年5月28日に開催された AWS Summit Bangkok 2026 に参加してきました！今回はその様子をレポートします！ バンコクという街 AWS Summit Bangkok 2026 概要 キーノート：AIがイノベーションを加速させる ブースの様子 サーバーワークスとIIJの海外連携について まとめ バンコクという街 タイ国内に足を踏み入れた瞬間に感じたのは、東南アジア独特の蒸し暑さです。 5月末の日本と比べてもかなり湿度が高く、空港で車を待つ30分でしっかり汗をかきました。 到着は夜21時過ぎで道路は空いており、空港からホテルまでは約4…
- AWS
- 生成AI
- クラウド
AWS Security Hub と Security Hub CSPM、結局どっちを使えばいいの？
AWS Security Hub と Security Hub CSPM、結局どっちを使えばいいの？ AWS Security Hub と Security Hub CSPM、結局どっちを使えばいいの？ そもそもどういう関係？ Security Hub CSPM とは（旧 Security Hub） 主な機能 データフォーマット EventBridge 連携 前提条件 Security Hub（統合プラットフォーム）とは エクスポージャー検出（Exposure Findings） 攻撃経路分析（Attack Path Analysis） 重大度の自動計算 未使用 IAM アクセス分析 その他の…
- AWS
- セキュリティ
- IAM
Nagoya Tech Talk #3 〜CloudNative × Platform〜 イベントレポート
中部支店に勤務しているData Intelligence Unit Master Data Groupのウチウゾウです。 前回、前々回とご好評をいただいた「Nagoya Tech Talk」の第3弾、「Nagoya Tech Talk #3 〜CloudNative × Platform〜」を開催しました！sansan.connpass.comこれまでは「AI」をメインテーマに扱ってきましたが、第3回となる今回は「オブザーバビリティとプラットフォームエンジニアリング」に特化しました。おかげさまで、当日は多くのエンジニアの方にお集まりいただき、熱気あふれるイベントとなりました。 CTO笹川によるオープニング本記事では、当日の発表内容やイベントの熱量をコンパクトに振り返ります。 1：研究開発部の監視基盤 - DatadogからNew Relicに移行 speakerdeck.com弊社の上田より、研究開発部のEKS基盤（Circuit）の監視基盤をDatadogからNew Relicへ、わずか1カ月で移行した事例が紹介されました。EKS基盤（Circuit）の使われ方とDatadogのコスト体系の相性があまりよくなかったため、移行に踏み切ったそうです。この爆速移行の裏側には、AWSが提供するAI統合開発環境Kiroの活躍がありました。具体的には、Datadog上にあった4つのダッシュボードと160個のウィジェットをJSONにエクスポートして、KiroとNew Relic MCPを組み合わせ、半自動移行を成功させました。これまで大きなコストがかかっていた移行作業をAIによって比較的容易にできた点に驚かされました。 上田の発表 2：作るより難しい、使い続けてもらうこと - Platform as a Productの実践 speakerdeck.comSansanには、研究開発部のCircuitのほかに、Orbitという全社横断Platformも存在します。弊社の辻田より、開発者体験を向上させ、使いたいと思われるPlatformにするため、Orbitという社内開発基盤をProductとして捉えた実践についての紹介がありました。まず、フィードバックループによる改善を目指して、1対1のユーザーインタビューを通し、社内開発基盤のユーザーの解像度を地道に上げていったそうです。その後、RICEスコア（Reach/Impact/Confidence/Effort）により施策の優先順位を決め、初期構築時の複雑さを解消する施策を実施しました。その結果、導入時のオンボーディング時間は半減しました。AIでなんでもすぐに作れてしまうものの、作り物が増えてしまうと、どうしても運用負荷もじわじわと膨れていきます。開発者の生産性を高く保つためにも、開発者に選ばれ続けるためのPlatform as a Productの実践の大切さを学べるお話でした。 辻田の発表 3：アラート削減でチームの開発生産性を向上 speakerdeck.com研究開発部のEKS基盤（Circuit）の上で動いているサービスのSREである野首より、システム運用負荷を大幅に改善した取り組みに関する発表がありました。アサイン初期は、アラート発報のたびにSREがまず調査する対応を繰り返していたそうです。この運用負荷を下げるべく、研究員とSREの責任境界の明確化に取り組みました。この明確になった責任境界を運用に乗せるため、SREに属人化していたナレッジをRunbookに整理しました。また、調査方法については、Agent Skillsに落とし込むことで、運用の属人化を解消していったそうです。これらの取り組みに伴い、不要なアラートを削減していった結果、アラートの9割削減に成功したとのことでした。SREと開発の責任境界を明確にしつつも、それを運用に乗せるには協働するという姿勢と、知見の共有が大事であることを改めて感じさせられました。 野首の発表 終わりに 改めて、会場にお越しいただいた参加者の皆さま、本当にありがとうございました。名古屋のエンジニアコミュニティーをさらに盛り上げ、最先端の知見をシェアし合える場として、「Nagoya Tech Talk」は今後も継続して開催していきます。「名古屋のエンジニアコミュニティーに関心がある」という方は、ぜひconnpassグループのフォローをお願いします！また、Sansan中部支店では、このような刺激的な環境で共に挑戦するメンバーを募集しています。イベントのオープニングでCTOの笹川が登壇した際の「Sansan中部支店の紹介資料」も公開しておりますので、私たちの組織や開発環境に少しでも興味を持っていただけた方は、ぜひチェックしてみてください。 speakerdeck.comそれでは、次回のNagoya Tech Talkでお会いしましょう！ Sansan技術本部ではカジュアル面談を実施しています Sansan技術本部では中途の方向けにカジュアル面談を実施しています。Sansan技術本部での働き方、仕事の魅力について、現役エンジニアの視点からお話しします。「実際に働く人の話を直接聞きたい」「どんな人が働いているのかを事前に知っておきたい」とお考えの方は、ぜひエントリーをご検討ください。
- Platform Engineering
- SRE
- Datadog
- New Relic
- AWS
検証で理解する、AWS KMSエンベロープ暗号化とBYOKの仕組み
はじめに 概要 エンベロープ暗号化とは？基礎から理解する エンベロープ暗号化の基本概念 AWS KMSにおける鍵の階層構造 なぜ二重に暗号化するのか？ S3におけるSSE-KMSの動作フロー BYOK（Bring Your Own Key）とは？ 基本概念と通常のKMSキーとの違い インポートに必要なラッピングキーとインポートトークン ラッピングキー（Wrapping Key / 公開鍵）とは インポートトークン（Import Token）とは 今回の検証：キーマテリアルを削除してファイルへのアクセスを遮断する 検証の目的 検証の流れ 前提条件 実装手順 【1. 鍵の準備とインポート】 Ste…
- AWS
- セキュリティ
Coding Agentの時代: ソフトウェアエンジニアの未来
社内 IT の部署であるGYOMUハックでマネージャーをやっている kumataro です。私たちの取り組みから実感している次の時代のソフトウェアエンジニア像のひとつについて書いてみました。 2025年から2026年にかけて、Coding Agent が爆発的に進化しました。Claude Code や Codex、GitHub Copilot Agent など、コードを書くだけならAIが人間よりも高速かつ正確にこなせる時代が現実のものになりつつあります。 最近は、自分で1行もコードを書いていないという話も聞くようになってきました。 そんな環境ですので「AIに仕事を奪われるのではないか」という不安を抱いているソフトウェアエンジニアの方も多いのではないでしょうか。 「コードを書くことそのもの」に強いやりがいを感じているエンジニアにとっては、大きな変化に戸惑う側面もあるかもしれません。しかし「課題を解決すること」が目的であるエンジニアにとって、AI はこれ以上ない強力な武器です。私たちはこの変化を、エンジニアという職種がより本質的な価値へと回帰するチャンスだと捉えています。 Coding Agent 時代に陥りやすい罠 私たちは社内のバックオフィスの生産性を向上させるためのエンジニアチームです。Claude Code を用い、実装の速度が増したことにより、寄せられる要望に対応できる能力も高まっています。 同時に、ここには罠が存在することにも気づきました。それは、開発速度が増したことにより、寄せられた要望に素早く対応するだけの存在に陥ってしまいやすいということです。対応は感謝されるだけに、すぐに要望を実現したい気持ちはエンジニアにとっても、とても強いものです。 しかし、この先に待ち受けているのは、部門、業務ごとに個別最適化された処理やデータの乱立です。一見、業務は最適化されているように見えますが、全体的な視点では業務の重複による一貫性のなさや、データの散在が起こり、連携が困難な状況が急速に拡大するのが目に見えています。 実際に freee のバックオフィス内でも、従業員数の予測値について、労務と社内IT、財務の間でそれぞれの課題感から別々に算出している事例がありました。このような組織横断的な不整合の解決は個別の部署の業務改善では実現できません。 こうした「部分最適の罠」を回避し、AI を真の武器として活かすためには、単なる「対応力」を超えた、より戦略的なアプローチが不可欠です。そこで私たちが今改めて立ち返ったのが BPR と FDE というふたつのキーワードです。 道を切り開くふたつのキーワード、BPR と FDE BPR（Business Process Re-engineering）: 既存の業務プロセスをそのままシステム化するのではなく、プロセスそのものを根本から再設計すること。 FDE（Forward Deployed Engineer）: 本社のオフィスで仕様調整を待つのではなく、現場に入り込み、業務を観察し、課題を発見し、動くものを作って解決する「前線配備エンジニア」。 FDE は米国 Palantir 社などが先駆けて導入し有名になったポジションですが、これが「今の時代」に特にもてはやされているのには、明確な技術的・ビジネス的な背景があります。 freee でも社内のバックオフィスでは、ドッグフーディング的に自社プロダクトを利用しています。そういった環境での業務改善において、パッケージ化された SaaS をそのまま導入するだけでは解決できない企業固有の複雑な課題は残るのが現実です。 SaaS のデータと社内独自のデータの統合: 業務活動ではデータ分析の要求は常にあります。しかし、SaaS 内のデータと SaaS 外のデータを統合して扱うのは簡単なことではありません。また同じ元データのはずのものが部署毎の処理の中で異なる数字になって出てくることもあります。 スピード感: フィードバックは SaaS プロダクトに届けることができます。しかし、開発優先度の問題や SaaS としての全体最適化の中で、対応スピードは思うように上がりません。 個別最適化: SaaS という性質上、個社別の環境に最適化するわけには行かないため、個別の事情にピッタリマッチする改善はできないのが現実です。 こういった課題に対して、FDE は現場で活動している強みで、自ら解決策を提示し、導入、運用まで進めることができる役割となっています。 私たちのチームは社内における FDE として、業務をハックするエンジニアチームです。私たちが取り組んでいるのは、まさにこの FDE の動きを通じた BPR の実践です。 ミッションとバリュー では、ふたつのキーワードと陥りやすい罠を避けるために、どのようなマインドセットを持って業務に取り組めば良いと考えているのか紹介してみます。 私たちのミッションは「テクノロジーと対話を通じて、バックオフィスの生産性を最大化し、全従業員がより創造的な業務に集中できる環境を創り出す」ことです。このミッションを実現するために、以下の4つのバリューを大切にしています。 Why First（なぜ？から始める） 私たちは、表面的な要望の奥にある本質的な課題を探求することを常に最優先します。依頼された解決策をそのまま実装するのではなく「その業務はそもそも必要なのか？」「理想の状態は何か？」という問いから始めます。必要であれば「開発しない（業務自体をなくす）」という選択すら積極的に行います。 Be a Partner（最高のパートナーであれ） 私たちは、依頼者を「お客様」ではなく「課題解決のパートナー」と捉え、共に考え、共に成功を目指します。依頼者と対話し、業務のAs-Is/To-Beを描きながら、現場の泥臭い課題を共に解きほぐしていきます。 Impact Driven（インパクトで動く） 私たちは、取り組むべき改善を、そのインパクト（効果）の大きさによって判断します。 Go Simple（シンプルを追求する） 私たちは、複雑な問題を、誰もが使い続けられるシンプルで持続可能な解決策へと導きます。 私たちが目指すシステム全体像 こういった理想を実現するため、現場の課題に寄り添いながら、同時にそれを支える強固な技術基盤も並行して構築しています。現在、私たちが構築しているシステム全体のイメージ図を共有します。 開発中の基盤の全体像 Cadiz: OneLogin × AWS Cognito × Cerbosを組み合わせ、行・列レベルの認可制御を一元化した社内アプリ開発基盤。社内業務で用いる社員のセンシティブなデータも適切に守る。 Service Data Pipeline: AWS EKS 上で構築した自前のデータ連携基盤。複数の SaaS やデータソース間を柔軟に連携。 データ分析基盤: Google Cloud（BigQuery）/ Looker Cloud Core / Looker Studio Pro で構築したバックオフィスデータマネジメントを支えるデータ活用基盤。局所最適化された自動化でデータの分断が起こらないように一元化。 これらは単なるツールではなく、バックオフィスという複雑な領域を、他社にも誇れる「ショーケース」に変えるための重要なパーツです。これらの技術選定の裏側や、なぜその構成を選んだのかというトレードオフについても、また別の機会に詳しく共有していきたいと考えています。 まだまだ道半ば ここまで「FDE 的な動き」や「強固な基盤」について書いてきましたが、正直に言えば私たちはまだ、目的を成し遂げるための努力が必要な「発展途上」の段階です。 バックオフィスの現場には、未解決の複雑な業務フローや、解決すべきレガシーな仕組みが山ほど残っています。しかし、だからこそ面白い。 完成されたシステムを保守するのではなく、業務の現場に深く入り込み、技術の力で泥臭い課題を一つずつ解きほぐし、組織のあり方そのものを変えていく。この「変化のプロセス」こそが、私たちがエンジニアリングを通じて体験できる最大の醍醐味です。 これらの状況は、程度の差こそあれ、どのような会社にも存在するものではないでしょうか。 Coding Agent が強力になる中で、これからのエンジニアに必要なスキルセットは現場の深い理解（ドメイン知識）と、それを技術で最適化するアーキテクチャ設計能力の掛け合わせではないか、というのをひとつの答えとして提示してみました。 最後に GYOMUハックは、AIを武器に変え、バックオフィスの「前線」で挑戦を続ける仲間を募集しています。 「技術を使って組織を強くしたい」「コードを書く以上に、本質的な課題解決をしたい」と考えているエンジニアの方、ぜひ私たちと一緒にバックオフィスの新しいあり方を創りませんか？ hire.wantedly.com
- 生成AI
- アーキテクチャ
- AWS
- Google Cloud
sam deploy コマンドで変更セットの扱いを決める2つのオプションについて整理した (no_execute_changeset/confirm_changeset)
こんにちは、サービス開発部のくればやしです。 CloudFormationでのデプロイにおいて、変更セットの利用は非常に便利でデプロイの安全性を高めてくれるものです。 AWS SAM CLIでも変更セットを利用したデプロイが行われます。 今回は AWS SAMのデプロイコマンドである sam deploy で利用できる --confirm-changeset と --no-execute-changeset というオプションについて解説します。 AWS SAM CLIで選択できるデプロイ動作の種類とオプションとの対応 SAM CLIではオプションの指定方法で以下の3種類のデプロイに関する動作を…
- AWS
- CloudFormation
そのAI活用、実は「あの人頼み」になっていませんか? ― Amazon Quickで、AIを「個人技」から「チームの仕組み」へ
クロスインダストリー第一本部の渡部です。 最近はAIの普及により、業務が大きく効率化されてきました。「もうAIが無いと仕事にならない」という方も多いのではないでしょうか。 そんな中で、こんな声を耳にすることがあります。 「AIを使えば、誰でも質の高いアウトプットが出せる」 「AIを使えば、業務の属人性は排除できる」 果たして、本当にそうでしょうか。 私はむしろ、「AIの活用の仕方そのもの」に新たな属人性が生まれていると感じています。同じツールを使っているはずなのに、人によってアウトプットの質が大きく違う。その差は、次の2つから生まれます。 AIにどんなデータを読み込ませるか（データの属人性） …
- 生成AI
- AWS
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
- フロントエンド
【2028年問題】Salesforce Open CTI廃止！ 移行負担を減らすAmazon Connect連携パッケージをリリースしました
突然ですが、SalesforceとクラウドPBXを連携させてコールセンター業務を行っているみなさま、「2028年問題」の準備は進んでいますか？ 「……え、2028年問題って何？」 「初耳なんだけど、何かあったっけ？」 そう思った方、安心してください。実はまだ知らない方もたくさんいます。 しかし、知らなかったでは済まされない大きな変化が、今まさに水面下で進行しているのです。 今回は、SalesforceのCTI連携に訪れる激震と、それを賢く乗り越えるためにサーバーワークスがリリースした「新ソリューション」についてお話しします。 実は知らない人も多い「Salesforce Open CTI廃止」の…
- Amazon Connect
- Salesforce
- 生成AI
- AWS
【GitHub Actions】明日からマネできる CI 高速化テクニック 3 選
はじめに こんにちは、タイミーでエンジニアをしている徳富(@yannKazu1)です。 タイミーではメインサービスのバックエンドを Rails で開発しています（Go を採用しているプロダクトもありますが、本記事では Rails を前提とします）。 突然ですが、皆さんのチームでは CI の待ち時間、気になっていませんか？ 「Push した、コーヒー淹れた、戻ってきた、まだ回ってる……」みたいな経験は、開発者なら一度はあるのではないでしょうか。 本記事では、そんな状況を改善するために GitHub Actions 上のテスト実行パイプラインで取り組んだ 3 つの高速化テク を紹介します。どれも「知っていれば明日から試せる」くらいの温度感なので、気軽に読んでいただければと思います。 1. キャッシュの保存先を GitHub Cache から S3 に移行 課題: actions/cache が安定して速くない 最初にぶつかった壁が actions/cache の速度でした。vendor/bundle（数百 MB〜1 GB 超）の save/restore でやたら時間がかかることがあり、リストアだけで数分待たされる場面がちょくちょくありました。これはセルフホストランナーに限った話ではなく、GitHub ホステッドランナーでも起きます。 実際、公式リポジトリにも Extremely slow cache on self-hosted from time to time という Issue が立っていて、セルフホスト・GitHub ホステッド問わず同様の報告が寄せられています。 さらに私たちの場合、AWS 上のセルフホストランナー を使っているのでなおさらです。actions/cache のバックエンドは Azure Blob Storage のため、セルフホストランナーからだとインターネット経由のアクセスになり、スループットが 約 20 MB/s まで落ちる ケースも報告されています（Actuated Blog）。突発的に遅いうえに経路も遠い——これでは安定した速度は望めません。 容量面でも、リポジトリあたり 10GB の制限があります。また、7 日間アクセスのないキャッシュは自動削除されます。その結果、ブランチが増えるとすぐに上限に達し、必要なキャッシュが消えてしまうのも地味にストレスでした。 解決策: runs-on/cache で S3 をバックエンドに そこで [runs-on/cache](https://github.com/runs-on/cache) を導入し、キャッシュの保存先を 同一リージョン（東京）の S3 バケット に切り替えました。 前述のとおり、セルフホストランナーで actions/cache を使うとスループットが ~20 MB/s まで落ちるケースがあります。一方 runs-on/cache は同一リージョンの S3 を使えるため、200 MiB/s 以上 のスループットが出ます（公式ドキュメント）。単純計算で 10 倍近い改善 です。 actions/cache とインターフェースがそのまま同じなので、uses: を差し替えて環境変数を 1 つ足すだけで移行できました。 # .github/actions/setup-ruby-with-s3-cache/action.yml - name: Restore cache uses: runs-on/cache@v4.2.3-r2 env: RUNS_ON_S3_BUCKET_CACHE: your-gha-cache-bucket with: path: "**/vendor/bundle" key: bundle-v1-${{ runner.os }}-${{ inputs.ruby_version }}-${{ hashFiles('Gemfile.lock') }} restore-keys: | bundle-v1-${{ runner.os }}-${{ inputs.ruby_version }}- bundle-v1-${{ runner.os }}- なぜ runs-on/cache を選んだか S3 をキャッシュバックエンドにする方法は他にもあります（tespkg/actions-cache、whywaita/actions-cache-s3、自前の aws s3 cp スクリプトなど）。その中で runs-on/cache にした決め手はこのあたりです。 環境変数 1 つで切り替え: RUNS_ON_S3_BUCKET_CACHE を設定するだけで S3 バックエンドに切り替わる 自前実装が不要: 圧縮・展開・キャッシュキーのマッチング・フォールバックなど、地味にめんどくさい部分を全部やってくれる 容量無制限: S3 なので 10GB の制限もキャッシュの自動削除もなし キャッシュキーの設計 キャッシュキーは 3 段階のフォールバック構造にしています。 bundle-v1-Linux-3.3.6-<Gemfile.lock のハッシュ> ← 完全一致（最速） bundle-v1-Linux-3.3.6- ← Ruby バージョン一致 bundle-v1-Linux- ← OS のみ一致 完全一致しなくても、部分一致したキャッシュをリストアして bundle install すれば差分の gem だけで済みます。ゼロからインストールするより圧倒的に速いので、新しいブランチでもほぼキャッシュが効く状態を維持できます。 OIDC 認証で安全に S3 にアクセス AWS へのアクセスには OIDC 認証 を使っています。長期的なアクセスキーをシークレットに保存しなくて済むので、セキュリティ面でも安心です。 - name: Configure AWS credentials uses: aws-actions/configure-aws-credentials@v6 with: role-to-assume: arn:aws:iam::123456789012:role/your-gha-role aws-region: ap-northeast-1 2. マイグレーション結果をまるごとキャッシュ 課題: 毎回のマイグレーションが地味に重い テストジョブは毎回データベースをセットアップします。ここで問題になったのが、マイグレーション数が数百を超えてくると rails db:create db:schema:load だけで 数分かかる ということ。 「schema:load だからすぐ終わるでしょ？」と思いきや、テーブル数が多いとそうでもないんですよね。 解決策: MySQL のデータディレクトリごと S3 にキャッシュ 発想を変えて、マイグレーション済みの MySQL データディレクトリ (/var/lib/mysql) をまるごと S3 にキャッシュ することにしました。要は「マイグレーション済みの DB をそのまま持ってくれば、マイグレーション自体を省略できるよね」という作戦です。 仕組みの全体像 【キャッシュの生成】 【キャッシュの利用】 master ブランチ feature ブランチ db/migrate/** 変更 テストジョブ起動 or 毎日定時 │ │ ▼ ▼ S3 からキャッシュをリストア MySQL 起動 → ./tmp/mysql_data に展開 │ │ ▼ ▼ rails db:create db:migrate MySQL 起動（データマウント済み） │ │ ▼ ▼ ./tmp/mysql_data を S3 に保存 rails db:migrate（差分のみ） │ ▼ テスト実行 キャッシュの生成: master で定期的に焼き直す master ブランチでマイグレーションファイルが変更されたとき、または毎日定時に、専用のワークフローがキャッシュを更新します。 # .github/workflows/update-migration-cache.yml on: push: branches: [master] paths: - 'db/migrate/**' - 'db/schema.rb' - '.github/workflows/update-migration-cache.yml' - '.github/actions/migration-hash/**' schedule: - cron: '0 2 * * *' # 毎日 UTC 2:00（JST 11:00）に実行 workflow_dispatch: # 手動実行も可能 やっていることはシンプルです。 MySQL コンテナを起動（データディレクトリを ./tmp/mysql_data にマウント） rails db:create db:migrate でフルマイグレーション実行 ./tmp/mysql_data をまるごと S3 にアップロード - name: Run database migration run: bundle exec rails db:create db:migrate - name: Save migration cache uses: runs-on/cache/save@v4.2.3-r2 env: RUNS_ON_S3_BUCKET_CACHE: your-gha-cache-bucket with: path: ./tmp/mysql_data key: test-${{ runner.os }}-${{ runner.arch }}-mysql${{ steps.migration-hash.outputs.mysql_version }}-${{ runner.environment }}-db-migration-${{ steps.migration-hash.outputs.hash }} キャッシュキーの設計: 何をキーに含めるかが大事 キャッシュキーには地味に気を使っています。 test-Linux-X64-mysql8.0.28-self-hosted-db-migration-<db/schema.rb のハッシュ> │ │ │ │ │ OS ARCH MySQL Ver ランナー環境 スキーマハッシュ ポイントは db/schema.rb のハッシュを含めていること。マイグレーションの内容が変われば schema.rb も変わるので、自動的に新しいキャッシュが生成されます。MySQL バージョンやアーキテクチャもキーに入れているのは、バイナリ非互換でハマらないための保険です（一度やらかしました……）。 <h3 id="キャッシュの利用-Composite-Actio
- GitHub Actions
- MySQL
- Docker
- AWS
- CI/CD
AWS アカウントの組織への参加または離脱をどのように監視すれば良いのか？
セキュリティサービス部 佐竹です。2026年5月28日に AWS Organizations の運用に関連して、メンバーアカウントの参加および離脱（脱退）に関する新しい CloudTrail イベントが追加されました。これらを踏まえたアカウント監視設計をどうすべきかについて詳細に記述しています。
- AWS
- CloudTrail
- セキュリティ
- AWS Organizations
AIへの指示ファイル設定どうしてる？私の場合のお話
はじめに 今月お誕生日の人、おめでとうございます🎉エデュケーショナルサービス課の森純子です。 最近は、業務でも日常生活でも生成AIを使うのがすっかり当たり前になってきましたよね。 さまざまなAIツールがある中で、今回は私が愛用しているAIコードエディタ「AWS Kiro（以下、Kiro）」の「Agent Steering（以下、ステアリング）」という機能についてのお話です。 これは簡単に言うと、「新しくチャットを開くたびに、毎回同じ指示を打ち込む面倒くささをゼロにする機能」です。 たとえば、新しくチャットを開くたびに「丁寧語で書いて」「マークダウンは使わないで」と何度も同じ指示を入力するのは大…
- 生成AI
- プロンプトエンジニアリング
- AWS
AWS MCP Serverで2アカウント同時操作をやってみた
はじめに 今月誕生日の人、おめでとうございます🎉 エデュケーショナルサービス課の森純子です。 AWS MCP Server に接続するクライアントプロキシ「mcp-proxy-for-aws」を使うと、AIエージェントから直接AWSリソースを操作できます。 でも、「アカウントをまたいで操作できたらもっと便利なのに…」と思っていた方も多いのではないでしょうか。 そんな方々に朗報です！ 2026年6月5日のAWSアップデートで、クロスアカウント・クロスロールアクセスに対応しました🎉 The AWS MCP Server now supports cross-account and cross-ro…
- AWS
- IAM
AWS Configレコーダー不要でCSPM即稼働？検証してみた
はじめに 今月誕生日の人、おめでとうございます🎉 エデュケーショナルサービス課の森純子です。 AWS Summit Japan 2026まであと3週間ですね！気になるセッションの予約は完了してますか？ ハンズオンセッションやGameDayは速攻で満席になりましたね…来年こそは！と思っています。 さて、2026年6月2日、AWS ConfigがInternal Service-Linked Rulesをサポートしました。 aws.amazon.com このアップデートにより、Security Hub CSPM（Cloud Security Posture Management、以下CSPM）が、…
- AWS
- セキュリティ
- AWS Config
- Security Hub
CA DATA NIGHT #9 〜スポーツの現場を支えるAI・データ活用の最前線〜 開催レポート
こんにちは。サイバーエージェントの佐藤です。 先日開催された CA DATA NIGH ...
- 機械学習
- AWS
- データ分析
【トラブル対策】AWSとAzureをSite-to-Site VPNで接続する際の3つの注意点
【トラブル対策】AWSとAzureをSite-to-Site VPNで接続する際の3つの注意点 はじめに こんにちは！ エデュケーショナルサービス課の三角（みすみ）です。 AWS運用において、他クラウドとの連携は避けて通れないテーマになってきました。特に、AWSのVPCを仮想プライベートゲートウェイ（VGW）で、Azureの仮想ネットワーク（VPN Gateway）とSite-to-Site VPNでつなぐマルチクラウド構成の要件は増えています。 両者はどちらも標準的なIPsecをサポートしているため簡単に繋がりそうに思えますが、「クラウドごとのデフォルト設定の違い」や「コンソール画面上の表記…
- AWS
- Azure
- VPN
- ネットワーク
CA DATA NIGHT #9 〜J1サッカークラブにおけるデータ分析と現場実装の最前線〜
CA DATA NIGHTは、サイバーエージェントが主催するデータサイエンスに特化した技術者向けの勉 ...
- AWS
- Databricks
- データ分析
- 生成AI
Kiro IDEとAWSとNextDNSによるペアレンタルコントロール
こんにちは。 アプリケーションサービス本部、DevOps担当の兼安です。 今回は、業務ではなく個人で、Kiro IDEを使ってペアレンタルコントロールを作った話をします。 ちょっとしたアイデアを仕様駆動開発を使って形にした話だと思ってください。 はじめに NextDNSによるペアレンタルコントロール システム構成 Kiro IDEによる仕様駆動開発の流れ PoCのSpec 実装のSpec 振り返りと課題 最後に はじめに 今回ペアレンタルコントロールを作ったという話をしますが、これは私個人の家族における話です。 私も親が管理することが子育ての絶対正義とは思っていないことはご理解ください。 Ne…
- AWS
- AWS Lambda
- TypeScript
- AWS CDK
AWS IAM Identity Center をマルチリージョン化する方法と注意点
こんにちは！イーゴリです。 背景 AWS IAM Identity Center （旧 AWS SSO）はデフォルトでは単一リージョンで動作します。例えば、東京リージョンで障害が発生した場合、AWS アクセスポータルにアクセスできなくなり、すべての AWS アカウントへのログインが不可能になります。DR 要件がある環境では、追加リージョン（大阪など）を設定することで、東京リージョン障害時でも継続してアクセスできるようになります。 本記事では、IAM Identity Center のマルチリージョン設定手順を紹介します。 イメージ図 背景 イメージ図 前提条件 作業の大まかな流れ AWS IA…
- AWS
- セキュリティ
- IAM
Amazon Bedrockのモデル呼び出しログの上限値100KBってどんだけ？CloudWatch Logs/S3で実測してみた
はじめに こんにちは、久保(賢)です。 本記事ではAmazon Bedrockではモデル呼び出しログのCloudWatch Logsの上限値100KBが具体的にはどのくらいのサイズ感なのか？を調べた結果を共有します。 先に結論を書くと、CloudWatch Logsにインラインで残る本文は inputBodyJson / outputBodyJson のシリアライズ後UTF-8バイト数が基準で、100,000バイトまでは残り、100KBを超えると本文はS3参照または省略に切り替わりました。 また、入力と出力は別々に判定され、日本語では約33,000文字程度で100KBに到達します。 対象読者 …
- Amazon Bedrock
- AWS
- 検証
- CloudWatch
- Amazon S3
【手を動かしながら学ぶ】AWS SAM CLI のはじめの一歩
こんにちは、サービス開発部のくればやしです。 今回はAWS SAM CLI(SAM CLI)のはじめの一歩をコマンドを実行しながら学んでいきたいと思います。 私自身、はじめてSAMコマンドを触った際、 sam init? --guided ? samconfig? となってしまい、それらの関係がよく分からなかったので、まず基本の使い方として deploy コマンドの使い方をおさえておくと分かりやすいと思いましたので、そこの解説をしていきたいと思います。 本記事で確認したSAM CLIのVersionは SAM CLI, version 1.145.1 です。 その前に：AWS SAM と SA…
- AWS
- CloudFormation
【AWS Control Tower 解体新書】 CloudTrail統合編
Landing Zone 4.0によってさらに柔軟になったAWS Control TowerのCloudTrail統合機能と、その詳細設定を紹介。
- AWS
- AWS Control Tower
- AWS CloudTrail
- Amazon S3