【概要のみ紹介】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
中途入社の私からみた、SmartHRのユニークなコミュニケーション文化
はじめまして。SmartHRでプロダクトエンジニアをしているshuutieです。2026年2月にSmartHRに入社し、SmartHRオプション機能の開発に従事しています。 入社して4ヶ月ほど経ちますが、この数ヶ月を通して、「SmartHRって改めていい文化を持っているな」と感じたことがいくつもありました。 特に強く感じたのが、コミュニケーションの総量が多く、かつ質が高い（そして何より楽しい！）ということです。 この記事では、中途入社の視点から「SmartHRで開発するってこういう感じ」を、特徴的だと思ったコミュニケーションを交えながら紹介します。読者の皆さんに、当社の開発組織の雰囲気が少しでも伝わればうれしいです。 実際に入ってみて、SmartHRは「コラボレーションをうまくいかせるための工夫や文化」がかなり言語化・習慣化されていると感じています。その中でも特に印象的だったものを3つ紹介します。 Slack絵文字の圧倒的な多さ 私が一番驚いたのは、Slackの絵文字の量と多様さです。カスタム絵文字の数は、2026年6月現在でなんと40,860個！ 会話の中に自然に絵文字が飛び交い、メッセージには次々と多彩なリアクションが付きます。 Slackでのやりとり 最初は「絵文字が多すぎでは？」と思っていたのですが、使っているうちに、これが単なるノリと勢いではなく、テキスト中心だからこそニュアンスを丁寧に補っているんだな、と腑に落ちました。 例えば、同じ「OK」でも、👍なのか✅なのか🙆なのかで、使い所や受け取り方は微妙に違いますよね。 絵文字を使うことによって、テキストで「了解です。」とだけ送るよりも、少しだけ多くの情報を読み手に伝えることができたり、受け取る側にやさしそうな印象を与えることができたりします。 ちなみに私の好きな絵文字は、「恐竜」です。 恐竜の絵文字。「共有」の語呂合わせとして使用される 実はこれ1つで、「共有」のことを表しています。 「共有です。」とだけ書くより、少し温かみを感じますよね。 ミーティングごとにスレッドを立てて、実況する SmartHRでは、ミーティングを実施中、Slackのスレッドで実況するのが当たり前です。 このスレッドに、議題・感想・メモ・決定事項・宿題・軽い冗談などがどんどん発信されていきます。 これの何が嬉しいかというと、ひとつは大人数でも意見が埋もれにくいことです。 特に私たちが所属するチームはフルリモートで開発しているため、ミーティングもリモート中心です。 リモートミーティングでは、リモート特有の「発言してから音声が乗るまでにタイムラグがある」「一度に音声を拾えるのは一人だけ」といった物理的制約に直面しがちです。 一方、ミーティング単位のスレッドになんでも書き込んでよい、というルールがあれば、「声を出す」というハードルそのものがなくなります。 口頭の議論を止めずに、「それって〇〇の件ですか？」と関連リンクを貼ったり、「その視点漏れてました！」とテキストで挟んだりできるので、言い忘れる・深く考えずに発言するなどの行動が減ります。結果としてミーティングの情報密度が上がると言えます。 例えば、先日チームで実施したとある書籍の輪読会では、「コーディングのWhyをどこに書くか」というテーマで以下のようなやりとりがされていました。 輪読会実況スレでのやりとり このようにテキストでのやりとりが増えると、同時に発言しているのは1〜2人だとしても、大人数のミーティングで手持ち無沙汰の人がほぼ誰もいない状態を作ることができます。 もうひとつは、意思決定や重要事項の背景情報がテキストに残ることです。 実況スレッドを残しておくことで、「この決定って、どの会話の流れでそうなったんだっけ？」が後から辿れます。 例えば先日、私が別件の対応中に開かれたミーティングで、ある重要なテーマについて議論していたことがありました。 正式な議事録ができる前の段階でしたが、実況スレッドのおかげで、隙間時間に密度の濃い情報をキャッチアップすることができました。スレッドが残っていなければ、あとで他のメンバーに「さっきの会議どうだった？」と聞くしかなかったはずです。 このように、テキストで情報が残っていることの恩恵は大きいと感じています。 ドッグフーディング文化の浸透 いわゆるドッグフーディング（自社プロダクトを自分たちで使い込んで改善につなげる取り組み）のためのSlackチャンネルが活発です。誰もが気づいたことを自由に投げています。SmartHRを支える文化の一つとして、個人的には最も印象的でした。 「とはいえ、活用されてないんじゃないの？」 「投げっぱなしになっていて、形骸化しているんじゃないの？」 と思う方もいるかもしれませんが、そんなことはありません。実際に開発側がそれを拾ってプロダクト開発に反映していくケースは多くあります。 例えば、私が担当するプロダクトで、「チェックボックスの選択範囲が見た目上の広さと合っていない」というフィードバックをいただくことがありました。 チームメンバーはドッグフーディングチャンネルを巡回していたところ、このフィードバックが目に留まり、不具合と判断、このケースでは数日で修正しました。 フィードバックしていいよ！という価値観や空気感だけでなく、あげた声がちゃんとプロダクトに反映されるところまで含めて、いい循環ができているなと思います。 まとめ 今回は中途入社目線で見た、SmartHR特有のコミュニケーションカルチャーを紹介してきました。 絵文字で温度感を、実況スレで透明性を、ドッグフーディングで当事者意識を高める。こうした小さな工夫の積み重ねが、リモート中心でも質の高いコラボレーションを支えているのだと感じています。 We Are Hiring! SmartHRでは一緒にSmartHRを作りあげていく仲間を募集中です！ こんな文化のなかで、一緒にプロダクトを良くしていきたい、日本の未来をよくしていきたいと思った方は、ぜひ一度カジュアル面談でお話ししましょう。 hello-world.smarthr.co.jp
- Slack
- 働き方
さくらのVPS×Difyでカンタン構築！「現場で回せる」AI契約書レビューシステム ―スタートアップスクリプトで始める専門業務AX―
1. はじめに ChatGPTやClaudeのような汎用的なLLMサービスを業務に取り入れる動きが広がる一方、専門業務の現場で本格活用しようとすると、二つの課題にぶつかります。 一つは「生成AIだけでは業務を完遂できず、 […]
- Dify
- 生成AI
- VPS
Google I/O 2026（+Recapイベント）初参加レポート！
こんにちは、LINEヤフー株式会社の福野です。先月開催されたGoogle I/O 2026に初めて参加してきました。本記事ではそんな初参加者の目線からGoogle I/Oの魅力を紹介するほか、当社で行...
- 生成AI
- Android
Cloud Functions 世代移行で発生した1000万件のメッセージ滞留：Pub/Sub × Cloud Run × Spanner のチューニング
はじめに こんにちは。Merpay の Payment & Customer Platform で会計システムを開発・運用する Accounting チームで Backend Engineer をしている @mewuto です。本記事は「Merpay & Mercoin Tech Openness Month 2026」の11日目の記事です。 マネージドサービスの世代移行では、コードを変えていなくても、デフォルト値の違いだけでシステムの振る舞いが変わることがあります。ある月末の早朝、Cloud Functions の世代移行が引き金となり、会計イベント基盤で Cloud Pub/Sub のメッセージが大量に滞留して、新規の会計データを Cloud Spanner に登録できないインシデントが発生しました。 直接の引き金は、Cloud Functions を 1st gen から 2nd gen（Cloud Run ベース）へ移行した際に --max-instances を明示しておらず、Cloud Functions のスケール上限が「無制限」（1st genのデフォルト）から「100」（2nd genのデフォルト）へ下がっていたことでした。しかし、障害がここまで大きくなったのは、この引き金だけが原因ではありません。本記事では、1000万件規模に達したこの滞留がどのように構成されていたのかを解き、Cloud Run と Spanner、そして監視の各面で私たちが講じた対策を紹介します。 1. 月末ピークを支える会計イベント基盤 まず、私たちが運用する会計システムの全体像を説明します。会計システムは、社内の各マイクロサービスが発行する「会計イベント」を集約し、Cloud Spanner に記録する基盤です。この会計データは送信元サービスとの突合（リコンサイル）を経て、加盟店への精算や月次の会計締めといった後続処理の前提となるため、取りこぼしや遅延がそのまま業務影響に直結します。 会計システムは、次のような非同期パイプラインでイベントを受け取ります。送信元から Spanner までは、おおむね一方向の流れです。 この構成には、今回の障害を理解するうえで重要な特性が2つあります。 1つ目は、すべてが非同期で動く点です。送信元マイクロサービスはイベントを発行したら応答を待たず、配信・リトライ・整合性の担保はすべて Pub/Sub 以降のパイプラインが引き受けます。特に Pub/Sub から Cloud Run へは push 型サブスクリプションで配信されるため、消費側である Cloud Run とその書き込み先である Spanner の処理能力が、そのままパイプライン全体のスループット上限になります。 2つ目は、負荷が月末に集中する点です。業務特性上、月末・月初の締めに合わせてトランザクションが一気に押し寄せ、平常時の数十倍のスパイクが発生します。 なお、Pub/Sub に届いたメッセージは、この push 経路とは別の pull 型サブスクリプションを通じて Dataflow でも読み取られ、並行して Cloud Storage（GCS）に保存されています。本処理の滞留に巻き込まれないこのGCS上のデータを使って後の復旧を行いました。 2. 1000万件の滞留はどのように発生したか インシデントは、ある月末最終営業日の早朝に発生しました。6時ごろから Pub/Sub のメッセージが滞留しはじめ、Spanner への新規登録が滞り、新規の会計データを受け付けられない状態が断続的に続きました。復旧と再発を繰り返し、収束までには丸一日以上を要しました。 データロスそのものは、先ほど触れた GCS上のデータから再投入することで回避できました。しかし会計システムでは、送信元サービスと DB の間でリコンサイルが完了したものだけが、加盟店精算や月次の会計締めといった後続処理の対象になります。Spanner に登録されなかったデータはリコンサイル未完了のまま残り、締め日と重なったことで、広範な業務影響につながりました。 この滞留が深刻なのは、一度始まるとインフラリソースの上限でスケールが頭打ちになり、処理が遅れるほど次の処理も遅れる悪循環に陥るからです。会計イベントが高い密度で連続して到着すると、maxInstances=100 で頭打ちになった Cloud Run はこれを処理しきれません。上限まで張り付いた Cloud Run が一斉に書き込むことでSpanner CPUが逼迫し、1件あたりの書き込み時間が延びます。すると、処理スループットがさらに落ち、滞留はさらに進んでしまいます。やがて滞留時間が eventMaxAge（メッセージを破棄するまでの最大保持期間）を超えると、メッセージは Spanner に登録されないまま破棄されてしまいます。 3. きっかけは 2nd gen 移行時のデフォルト値 滞留の原因を調べていくと、今回の障害の1ヶ月以上前に行った Cloud Functions の世代移行に行き着きました。私たちは関数を 1st gen から 2nd gen（Cloud Run ベース）へ移行しましたが、このときデプロイコマンドで --max-instances を明示しておらず、世代によってデフォルト値が変わることを、十分に意識できていませんでした。 この「明示しなかった」ことが、スケール上限を静かに引き下げていました。下の表のとおり、1st gen ではスケール上限が実質無制限だったのに対し、2nd gen のデフォルトは 100 です。 Version デフォルトの max instances 1st gen 無制限（プロジェクト Quota の範囲） 2nd gen 100 コードもデプロイスクリプトも変えていないのに、移行しただけで上限が実質無制限から 100 へ下がっていたことになります。平常時は 100 インスタンスで十分だったため、移行後しばらくは問題が表面化せず、私たちの体感としては、ある月末に突如として障害が発生したように見えました。しかし実際は、監視がなかったために気づけていなかっただけでした。インシデント後に振り返ると、上限に迫っていた月もあり、水面下ではすでに限界の兆候が出ていたのです。 4. 障害を大きくした複数の要因 --max-instances の指定漏れは引き金ではありましたが、それだけでこの障害を説明することはできません。調べてみると、2nd gen移行後に迎えた月末のピーク時でも条件はほとんど同じだったからです。maxInstances は 100、eventMaxAge も同じ 21分で、トラフィック総量も3時間で約17〜19GBとほぼ変わりませんでした。 それでも、そのときは障害は起きていませんでした。決定的に違ったのは、トラフィックの「連続性」です。合間に負荷が落ち着く「谷」があり、その短い谷の間に Spanner CPU と未 ack の蓄積がリセットされていました。ところが障害当日は、この谷がないままピークが約40分間続き、システムは回復の契機をついに得られませんでした。 整理すると、今回の障害は3つの要因が連鎖して成り立っていました。まず maxInstances=100 という処理上限が滞留を発生させ、次にトラフィックの連続性がその滞留を固定化し、最後に eventMaxAge によるメッセージのドロップ、という連鎖により実害となりました。いずれか1つでも条件が違えば被害の規模は抑えられたはずで、だからこそ私たちは対策を1箇所に絞らず、制御できる Cloud Run と Spanner の両方に講じることにしました。 5. Cloud Run の処理能力を引き上げる 最初に着手したのは、直接の引き金となった Cloud Run のスケール上限です。あわせて、1インスタンスあたりの処理効率も見直しました。本番に反映した設定値は次のとおりです。 パラメータ 変更前 変更後 max-instances 100（暗黙のデフォルト） 1000 min-instances 0（暗黙のデフォルト） 1 concurrency 1（暗黙のデフォルト） 10 cpu デフォルト 1 memory 512MB 1Gi ここでの本質は、値を大きくしたこと以上に、必要なパラメータをすべて明示したことにあります。今回の引き金は、暗黙のデフォルト値に依存していたことでした。そこで max-instances をはじめとするスケール関連のパラメータをデプロイ定義に明示し、世代やデフォルトの変化に左右されない状態にしました。あわせて、 min-instances を 1 にしてコールドスタートを避け、concurrency を 10 に引き上げ、それに見合うよう CPU とメモリも増強しています。なお max-instances は、書き込み先である Spanner への負荷も考えて、一度に上げきらず段階的に引き上げました。 concurrency を 1 から引き上げることができたのは、ハンドラ内の共有状態を見直し、複数リクエストを同時に処理しても安全だと確認できたためです。Spanner クライアントは内部にコネクションプールを持ち並行アクセスに耐えられます。また、その初期化は sync.Once によって一度だけ行われます。こうした前提を確かめたうえで同時処理数を増やし、必要なインスタンス数そのものを抑えました。 6. Spanner autoscaler の監視軸を Total CPU へ広げる Cloud Run の処理能力を上げると、今度は書き込み先である Spanner がボトルネックになります。Spanner には以前から autoscaler を導入していましたが、障害のさなか、CPU が高負荷であるにもかかわらず PU（Processing Unit。Spanner の計算容量の単位）はまったくスケールアップしていませんでした。autoscaler があるのにスケールしない、という一見不可解な状況でした。 原因は、autoscaler が見ていた指標にありました。Spanner の CPU 使用率には High / Medium / Low の優先度があり、その合算が Total CPU 使用率です。当時の autoscaler は High priority CPU 使用率だけを見ており、障害時は Total CPU が 100% に張り付く一方で、High priority 単体では閾値（60%）の超過が続かず、起動条件を満たしませんでした。この死角は月末ピークに限りません。たとえばリアルタイム性を求めない大量データの削除ジョブは、意図的に Low priority で実行するため、Total は高いのに High は低いという同じ状態を容易に作り出します。優先度別の CPU だけを見る監視は、こうしたケースを構造的に取りこぼすのです。 しかし、これは autoscaler の設定変更では解決できませんでした。当時、OSSである mercari/spanner-autoscaler には、Total CPU でスケールする機能そのものが存在しなかったからです。そこで、OSS をメンテナンスしている SREチームに相談し、High priority と Total を OR 条件で評価する dual CPU scaling mode を実装してもらい、v0.8.0 として取り込みました。設定した閾値は次のとおりです。 パラメータ 変更前 変更後 Total CPU 閾値 （監視なし） 70% High priority CPU 閾値 60% 55% Total CPU 閾値は新設で、これが今回の障害への直接の対策です。値は Google Cloud の throughput 最適化推奨（〜70%）に合わせました。High priority CPU 閾値は、より早くスケールアップを起動するために 60% から 55% へ下げています。下げすぎると平常時のコストが増えるため、より低い 50% 等は避け、Google Cloud の推奨（regional で 65% 以下）に収まる 55% を選びました。これにより autoscaler は High priority(55%) と Total(70%) のいずれかが閾値を超えればスケールアップするようになり、「Total は逼迫しているのに High が閾値未満だからスケールしない」という障害時の挙動は原理的に起こらなくなりました。 また、スケール条件に加えて、運用面でも2つの調整を行いました。1つは、早朝5時から7時のスケールダウンを禁止することです。月末ピークの立ち上がりで、せっかく確保した PU が削られてしまうのを防ぎます。もう1つは、スケジュールによる事前の PU 確保です。月末早朝や大規模なリコンサイルが走る月など、負荷が読める期間にはあらかじめ PU を確保しておき、リアクティブなスケールアップだけに頼らない構えにしました。 7. 上限への接近を検知する監視を整える 今回の障害には、予兆を早期に捉える機会も、発生を即座に検知する機会も逃してしまったという課題があります。スケール上限に達してもそれを知らせるアラートがなく、水面下で限界に近づいていた兆候も見逃していました。そこでDatadog に2つの監視を追加しました。 1つは、Cloud Run のインスタンス数が上限の 40% / 60% に達した時点で警告・重大として通知する監視です。これにより、メッセージのドロップが始まる前に、上限への接近そのものを検知できます。もう1つは、Pub/Sub の未配信メッセージ数が閾値を超えたら通知する監視で、滞留という現象を直接とらえます。後者は誤検知を避けるため、当初は保守的な閾値から始め、定常状態の理解が進むにつれて段階的に下げていく方針にしています。 設定値を最適化するだけでは不十分です。これ自体は当たり前かもしれませんが、どれだけ良い値を入れても、その値への接近を検知できなければ、次の同じ障害は防げません。キャパシティの設計と、その接近を知る監視をセットで整える。この当たり前を当たり前に徹底することこそが大切だと、今回あらためて実感しました。特に、システムをゼロから作った当人ではなく、引き継いで運用していることのほうが多い現場では、こうした設定や前提を定期的に振り返り、整え直す文化を持つことが欠かせません。 8. まとめ 今回の障害は、1つのデプロイフラグを明示しなかったことから始まりました。しかし振り返れば、本当の教訓はもっと一般的なところにあります。 第一に、マネージドサービスの世代移行では、自分が変更していないデフォルト値こそが、負荷時に問題として表面化します。スケール上限・並行数・タイムアウトのような、平常時には効かないパラメータは、移行のたびに明示しておくべきでした。第二に、障害の原因は単一とは限りません。「直近の月は同じ条件で起きなかった」という事実がトラフィックの連続性という決定的な要因を浮かび上がらせたように、トリガー・増幅・被害化のそれぞれに目を向けることが再発防止には欠かせません。そして第三に、設定の最適化と、その状態に気づくための監視は、つねに一体で考える必要があります。 マネージドサービスの便利なデフォルト値は、平常時には何も語りません。だからこそ、ピーク時に初めて顔を出すその振る舞いを、移行のたびに確かめておく価値があります。この記事が、みなさんが運用するサービスの設定を今一度見直す、ひとつのきっかけになれば幸いです。 次の記事は um（うめ）さんです。引き続きお楽しみください。
- GCP
- Cloud Run
- Spanner
- Datadog
- SRE
DevinからClaude Code Actionsへ ── アカウント管理の自動化基盤を移行した判断とアーキテクチャ
こんにちは。ファインディのPlatform開発チーム（以降、SREチーム）でSREを担当している原（こうじゅん）です。 SREチームでは、AWSのユーザーとGitHubのアカウントの管理をTerraformで運用しています。Slackから申請が来たらTerraformのコードを書き換えてPRを出す、という作業を以前はDevinで自動化していました。 しかしDevinのアカウント利用形態が変わったことをきっかけに、この自動化基盤をClaude Code Actionsへ移行しました。同じようにAIツールでインフラ運用を自動化している方や、Claude Code Actionsの実践的な使い方を探している方に向けて、移行に至った判断理由と、移行後のアーキテクチャについて紹介します。 背景：Devinでアカウント管理を自動化していた 移行を決めた理由 移行後のアーキテクチャ triageジョブ：申請の振り分け routine-prジョブ：ファイル編集とPR作成 escalateジョブ：自動処理できない申請の通知 まとめ 背景：Devinでアカウント管理を自動化していた ファインディでは、GitHub Teamへのメンバー追加やチームの作成・廃止といったアカウント管理を、SREチームがTerraformで運用しています。 エンジニア・ビジネスサイド問わず、メンバーがSlackから申請を出すと、SREがTerraformのコードを手動で書き換えてPRを出し、レビュー・マージ後にapplyされる、という流れでした。毎回決まったパターンのYAML編集とPR作成を手作業でやるのは、典型的なトイルです。 このトイルを減らすために、Devinを使って自動化していました。Slackの申請内容をDevinに渡すと、Terraformリポジトリのコードを編集してPRを作ってくれる仕組みです。この取り組みの詳細は次の記事で紹介しています。 tech.findy.co.jp 移行を決めた理由 きっかけは、2026年4月1日のDevinのアップデートです。このアップデートでDevinアカウントを持たないユーザーはSlackのDevinスレッドに参加できなくなりました。 アカウントを持たない申請者が@Devinに返信してもDevinが反応せず、「動かない」というSREへの問い合わせが増えました。コンプライアンス上、全メンバーへのアカウント一律払い出しも現実的ではありません。そのため、Devinからの移行に踏み切りました。 移行先の選定にあたっては、次の3つを重視しました。 全メンバーが個人アカウントなしで使えること — Anthropic公式の@Claude（Claude in Slack）も検討しましたが、各ユーザーにClaude Codeのアカウントが必要で同じ問題を抱えて断念しました 申請者の体験を変えないこと — Slack Workflowのフォームはそのまま、バックエンドだけを差し替えます チームのツール統一 — 開発チーム全体がすでにClaude中心の開発体制になっており、自動化基盤もそれに合わせました この選定理由より、今回のアーキテクチャとなりました。 移行後のアーキテクチャ 移行後の全体構成は次のとおりです。 flowchart TD subgraph Slack["Slack （申請者の体験）"] F1["メンバー申請"] F2["チーム申請"] Thread[("申請者スレッド")] end subgraph GHA["GitHub Actions"] Triage["triage\n(Claude Code Action)\n整合性チェック・名前解決"] RoutinePR["routine-pr\n(Claude Code Action)\nファイル編集・PR作成"] Escalate["escalate\n自動処理不可を通知"] end SRE["SRE承認・マージ"] Apply["terraform apply"] F1 -->|workflow_dispatch| Triage F2 -->|workflow_dispatch| Triage Triage -->|routine| RoutinePR Triage -->|escalate| Escalate RoutinePR -->|PR作成| SRE RoutinePR -->|受付通知| Thread Escalate -->|エスカレ通知| Thread SRE -->|マージ| Apply Apply -->|完了通知| Thread classDef unchanged fill:#e6f4ea,stroke:#34a853,stroke-width:2px,color:#1b5e20; class F1,F2,Thread unchanged style Slack fill:#f1f8f4,stroke:#34a853,stroke-width:2px; Slack Workflowからの申請がGitHub Actionsのworkflow_dispatchをトリガーし、正常系ではtriageジョブとroutine-prジョブの2つのClaude Code Actionが順に処理する構成です。 ただし、Slack Workflow Builderから直接workflow_dispatchは呼べません。間にSlack Custom Function（Deno Slack SDK）を挟み、GitHub APIへの認証付き呼び出しを行っています。 api.slack.com sequenceDiagram participant WF as Slack Workflow Builder participant CF as Custom Function<br/>(Deno Slack SDK) participant GH as GitHub API WF->>CF: フォーム入力値を渡す CF->>CF: GitHub App秘密鍵でJWT署名 CF->>GH: JWT → Installation Access Token取得 GH-->>CF: Token返却 CF->>GH: workflow_dispatch（Token認証） GH-->>CF: 202 Accepted 申請者から見ればSlackのフォームに入力するという体験は変わっていませんが、裏側ではCustom FunctionがGitHub Appの認証（JWT署名 → Installation Access Token取得）を行い、workflow_dispatchを呼び出しています。 triageジョブ：申請の振り分け 最初のClaude Code Actionは、申請内容の整合性チェックと振り分けを担当します。 チーム名の名前解決（申請者が入力した表記ブレを、リポジトリ上の実際のディレクトリ名に解決する）、申請内容のバリデーション、そしてroutine（自動処理可能）かescalate（自動処理不可）かの判定を行います。 triageとPR作成を1つのジョブにまとめることもできますが、責務と権限を分離するためにあえて分けました。triageジョブは--max-turns 5と少ないターン数に制限し、使えるツールもReadとBash(ls:*)だけに絞っています。判定がおかしければPR作成に進まない安全弁にもなります。 判定結果はJSON Schemaで構造化出力させるので、後続のジョブが確実にパースできます。 claude_args: | --max-turns 5 --allowedTools Read,Bash(ls:*) --json-schema '{"type":"object","properties":{"verdict":{"type":"string","enum":["routine","escalate"]},...}}' routine-prジョブ：ファイル編集とPR作成 triageでroutineと判定された申請は、2つ目のClaude Code Actionが処理します。TerraformリポジトリのYAMLファイルを編集し、ブランチを切ってPRを作成するジョブです。 --max-turns 20とターン数を多めに確保し、ファイル編集やgit操作、PR作成に必要なツールを許可しています。 claude_args: | --max-turns 20 --allowedTools 'Read,Edit,Write,Bash(git checkout:*),Bash(git add:*),...,Bash(gh pr create:*)' PR作成後はSlackの申請スレッドに受付通知を送り、SREがレビュー・マージすればterraform applyが走って完了通知が届きます。 escalateジョブ：自動処理できない申請の通知 triageが自動処理できないと判断した申請は、Slackの申請スレッドにその旨が通知されます。Claude Code Actionは使わず、シェルスクリプトで通知を送るだけのシンプルなジョブです。 まとめ Devinのアカウント利用形態変更をきっかけに、アカウント管理の自動化基盤をClaude Code Actionsへ移行しました。Claude Code Actionをtriage（振り分け）とroutine-pr（PR作成）の2段階に分け、それぞれの責務と権限を絞った設計にしています。 現在、GitHubアカウント管理の移行は完了し、運用を開始しています。今後はAWSのユーザー管理なども移行を進めていきます。 ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 herp.careers
- SRE
- Terraform
- GitHub Actions
- 生成AI
Claude Code更新 Fable 5緊急停止・サブエージェント入れ子【6/7〜13】
はじめに サーバーワークスの池田です。 今週（6/7〜6/13）の Claude Code で最も大きな出来事は、6月9日にリリースされたばかりの新モデル Claude Fable 5 が、わずか3日後の6月12日に米政府の指令で緊急停止されたことです。日本のユーザーを含む外国籍者は、現時点で Fable 5 を利用できません。 機能面では、サブエージェントが自分の配下にさらにサブエージェントを生成できるようになり、セッションのタイトルが会話の言語で生成されるようになりました。 対象は v2.1.168 から v2.1.177 までの9バージョンです（v2.1.171 は欠番）。Fable 5…
- 生成AI
- CLI
「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
RubyKaigi 2026 でfreee Drink upを開催しました!
はじめに こんにちは！freee人事労務のエンジニアのkaseです。 RubyKaigi 2026が函館にて開催されました。 参加された方はいかがでしたか？私は初参加だったのですが、興味のある講演を聞きつつ、ハセガワストアのやきとり弁当やラッキーピエロといったローカルフードを満喫でき、大変満足でした!(少し食べすぎました) freeeは、GoldスポンサーとDrinkupスポンサーとして参加しており、三日目の夜にDrinkupを開催しました。 今回はその模様をレポートします! SweeeもDrinkupの参加者をお出迎え Drinkup当日の様子 Drinkupは、PREMIER HOTEL -CABIN PRESIDENT- HAKODATEにて開催されました。 Matzさんのkeynoteと、次回開催地が宮崎であるという発表をもってRubyKaigi 2026は閉幕。その余韻のなか、Drinkup会場には少しずつ参加者が集まり、乾杯が行われました。 円卓のオードブルを囲みながら、各テーブルで振り返りや会社の話に花を咲かせました。 会場全体は、落ち着いたトーンで、RubyKaigi最終日の夜にふさわしい空気でした。 ビンゴも盛り上がりました 食事が落ち着いてからは、ビンゴも開催されました! これはただのビンゴゲームではなく、RubyKaigiにちなんでRubyのメソッドをビンゴのマスとしたWebアプリを有志で企画し完成させたものです! 先ほどまでの落ち着いた空気から一転、みんな画面に集中して手元のビンゴと照らし合わせていました。 開発運営の私視点では、リーチからなかなかビンゴ達成者が出ず、バグがあるのではと非常にソワソワしました。 先着10名にfreeeオリジナルのノベルティを用意していたのですが、10人目と一瞬の差でビンゴを達成した方がいて……結局、11人にお渡ししました! 普段業務で扱わないメソッドも多く、「これは何だろう？」といったRuby自体への反応も生まれ、最後までRubyKaigiの空気を楽しめたのかなと思います。 出てくるRubyメソッドに一喜一憂 おわりに RubyKaigi、最高のイベントでした!改めて、Drinkupに参加してくださった方ありがとうございました! 来年もぜひ参加したいです!
- Ruby
SSII2026（画像センシングシンポジウム）にスポンサー・登壇しました
Data＆Analysis部の稲葉です。 キャディは2026年6月10日(水)〜12日(金)にパシフィコ横浜で開催されたSSII2026（第32回 画像センシングシンポジウム）にプラチナスポンサーとして協賛しました。また、キャディから3名が登壇しましたので、当日の様子をレポートします。 オーガナイズドセッション：産業界における生成AIの利活用 技術動向解説セッション：CADにおけるAI分野の動向と製造業への実適用 インタラクティブセッション 終わりに オーガナイズドセッション：産業界における生成AIの利活用 生成AIが産業界でどのように価値を生み、どのような条件で実運用に乗るのかを議論するセッションです。 キャディからは、オーガナイザーとしてシニアリサーチエンジニアの福原（@gatheluck）、また講演者として私、稲葉（@mi_spindel）が登壇しました。会場には約450名と、非常に多くの方にお越しいただきました。 登壇資料はこちらです。 speakerdeck.com speakerdeck.com 私からは、Data＆Analysis部として取り組んでいる生成AI活用事例として製造業RAGを紹介しました。 （本当は、他にも様々な取り組みがあるのですが、また機会を見て紹介したいと思います。） また、この中で直面した課題の一つが「各LLM/VLMモデルが我々のドメイン特有のタスクをどこまで実行できているかが不明」というものでした。 そこで、製造業LLM/VLMベンチマークとしてManuDraw-Benchを独自構築し、比較評価したお話しをしました。 皆様からのたくさんの質問をいただきまして、ありがとうございます。当日は時間の関係で回答しきれませんでしたので、ここで回答したいと思います。 Question： CADでのDXFはパースせずに図面の見た目で拾ってしまった方が総合的なコストが安いという判断でしょうか？ Answer：DXFなどベクター図面のまま処理した方が、QualityやCostの観点で良いタスクは存在していると思います。ただ、結局はimage encoderが必要なタスクはありますし、処理プロセスの種類が増えることによって運用負荷も増えますので、QCDを総合的に判断して技術選定をしています。 Question：会社の固有知識については基本的にはRAGで対応となると思うのですが、RAGでは対応しきれないのではないか、モデルの Fine Tuning が必要ではないかという意見も社内であり、意見が分かれています。 Fine Tuning まで実施したというような事例はあるでしょうか？ Answer：Fine Tuningまで実施した事例があるかないかの詳細はお答えできないのですが、Fine Tuningを考える前に基本はナレッジ管理とGroundingで対応できないかを先に考えるべきだと思っています。また、Fine Tuningと言えど一定のデータ量は確保しなければならないですが、機密情報の漏洩を考えると個社ごとに調整をすることになりがちです。確保できるデータ量とその労力に対する効果を検討する必要があります。 Question：過去の故障事例などは、設計改善に使用可能なレベルで、原因情報が現場から上がってくるモノでしょうか？実は、原因をLLMが把握するところに課題はないでしょうか。 Answer：おっしゃる通りで原因とその対応が上がってくる仕組みを作ることが重要ですし、そこは課題です。その解決のためにも、キャディが提供しているような部横断のデータ基盤を構築しデータを紐づけることが必要になります。 Question：P15のVLMによる3次元点群予測は1点1点を文字列として出力しているわけではないのだと思いますが、Pythonスクリプト出力などでCADモデリングさせて、表面に点を生やしているのでしょうか？ Answer：1点1点を点群を文字列として出力させているのではなく、メッシュモデルとして形状を面の組み合わせで出力させてから点群サンプリングをしています。おっしゃるようにPythonスクリプト出力などでCADモデリングする方法もありますが、コーディング能力や各LLM/VLMが扱える開発環境にも依存するため、このような方法を取っています。 Question：位置やサイズなど幾何的な理解の性能は、モデルの進化を待てばある程度上がってきそうなベンチの結果になっているのでしょうか？ Answer：そのあたりは今後の傾向を見てみないと何とも言えないところですので、今後もトラッキングしていきます。ただ、自然画像や文字列で表現されている位置やサイズの理解は進化が見られます。 Question：3面図とアイソメ図でVLMからみた理解度にどれだけ差があるのでしょうか？VLMの訓練にメインで使われているであろう写真データには三面図的な見え方は珍しそうに思います。写真に近そうなアイソメ図の方が理解してくれたりするのでしょうか？ Answer：とても良いご指摘です。三面図をそのまま与えるよりは、斜めから見たアイソメ図の方が形状の理解力は高い印象です。ただ、アイソメ図には寸法など必要な情報が抜けているので、処理プロセスのどこかでアイソメ図にリフトするとかデータを組み合わせて利用するとか工夫は必要にはなると考えています。 共に登壇いただいたエクサウィザーズの加藤様、LayerXの松村様、素晴らしい発表をありがとうございました。エクサウィザーズ様はやはり取り組まれていることの幅が広いですし、生成AIの性能だけでなくUI/UXやガバナンスといった活用推進の重要なポイントを俯瞰して抑えられているなと感じました。LayerX様はAgentありきの業務フローに変革していく強い意思を伝えながらも、結局は当たり前をやりきれるかという話に共感しました。 登壇の様子 技術動向解説セッション：CADにおけるAI分野の動向と製造業への実適用 昨今の3D基盤モデルなどの潮流を概観し、CAD解析技術の実プロダクト適用における「研究と実践」のリアルを解説するセッションです。 キャディから、Data Platform本部長の今井（@imaimai0）が登壇しました。こちらも500名近い方に聴講いただくことができました。 speakerdeck.com なぜ製造業においてCADが重要なのか、CADの活用において何がボトルネックになっているのか、最新研究の動向はどうなっているのかをお話ししています。 詳細は資料をご確認いただけると幸いですが、私からは特に、CAD（Geometric系）やMechanical Engineering系の研究開発をもっと盛り上げたいと思っていることをお伝えしたいです。 資料の中でもCVPRにおいてGeometric系の論文は5%程度というお話しがありましたが、製造業のGDPが日本の2割程度を占める巨大産業にも関わらず日本においても類似の研究開発が少ないように思います。我々もResearchチームの規模を拡大中ですし、共同開発や共同研究の機会も探しているところです。一緒に盛り上げていただける仲間を募集中です。 インタラクティブセッション 6/11（木）のブース出展では、多くの方にキャディブースへお越しいただきました。セッションを聴講して「話を聞いてみたい」と立ち寄ってくださった方もいらっしゃいました。 ポスター発表では、現在取り組んでいる研究開発テーマを紹介しました。注力しているテーマとして、以下の3点をご紹介しました。 設計資産全体を横断して検索するための、2D図面と3D CADモデルの埋め込み空間の統合 3D CADデータ内の加工に必要な特徴の認識 製造業ドメインに特化した独自の視覚言語モデル（VLM）評価ベンチマーク ManuDraw-Bench ManuDraw-Benchは公開されているのか？されないのか？といった質問をたくさんいただきましたが、権利の関係上公開は難しいです。ただ、業界の研究開発を促進したいと思っていますので、何かしら対応を考えていきたいとは思っています。 お話いただいた皆様、本当にありがとうございました！ 終わりに SSII2026への協賛・参加を通じて、製造業領域におけるAIの研究開発の現状や、その中でのキャディのチャレンジについて知っていただく貴重な機会となりました。また、来場者の方との交流から、日々取り組む課題に対してもヒントを得られる非常に有意義な場でした。 運営の皆様、素晴らしい会をありがとうございました。 今後もキャディは技術的な挑戦を続け、画像センシング・コンピュータビジョン研究コミュニティの発展と、モノづくり産業のポテンシャル解放の両面に貢献していきたいと思っています。 また皆さんとお会いできることを楽しみにしています！
- 生成AI
- LLM
- CAD
人工知能学会全国大会（第40回）にシルバースポンサーとして協賛、研究発表を行いました！
SmartHRのML（機械学習）エンジニアの井上です。 SmartHRは2026年6月8日〜12日に群馬・高崎のGメッセ群馬で開催された「2026年度 人工知能学会全国大会（第40回）（JSAI2026）」にシルバースポンサーとして協賛、および研究発表を1件行いました。 現地組・リモート組を合わせて複数のメンバーが参加し、「うちのプロダクトに使えるのでは？」と大盛り上がりの5日間でした！ 人工知能学会全国大会とは 人工知能学会全国大会は、AI技術に関する国内最大の学会です。 機械学習の基礎・応用研究から産業応用まで幅広い発表が集まり、AIの最新動向を把握できる機会として毎年多くの参加者が集まっています。 今回の第40回大会は40周年にあたる節目の大会で、約5000人の参加者が集まりました！ 人工知能学会全国大会（第40回） 今年の研究トレンドの変化 JSAI2026の全発表タイトルをキーワードで分析し、昨年の傾向と比較したところ、興味深い傾向が見えてきました！ 技術テーマ出現頻度ランキングの変化（JSAI2025→JSAI2026） 発表の出現頻度をもとにランキングをスロープチャートで比較すると、「LLM・基盤モデル」「AIエージェント」「対話・会話AI」の上位3テーマは今年も順位変動がなく、この領域が引き続き学会全体の中心軸であることが確認できました。 一方で最大の急上昇は「生成AI」で、19位から7位へと12ランク上昇、「ロボット・フィジカルAI」も13位から6位へ7ランク浮上しており、フィジカルAIへの関心が学術研究の領域にも着実に波及していることがうかがえます。 最大の急上昇を見せた「生成AI」も、発表の内容は多岐にわたっていました。生成AI自体を技術として扱う研究だけでなく、keep4o を代表とする生成AIをめぐる人間・社会の動きの考察、生成AIを要素技術として活用したシミュレーション研究、プロダクト活用の実践知を共有する発表も増えており、生成AIが「研究する技術」から「社会に埋め込まれた前提」へと変わりつつあることを実感しました。 SmartHRからの発表 SmartHRからは1件の機械学習領域における口頭発表を行いました！ 敵対生成プロンプト同時探索による内省型プロンプト最適化 発表者: 井上 耕太朗 セッション: 4M5-GS-2f-05（6/11 16:30-16:45） LLMアプリケーションのプロンプト最適化に関する研究です。SmartHRでは RAG を活用した AI アシスタントなど様々な LLM アプリケーションを提供していますが、これらをローンチ前から高品質な状態に保つには、プロンプトを事前に検証・改善しておくことが重要です。しかし従来のプロンプト最適化手法の多くは大量のラベル付きデータを前提としており、ローンチ前の段階では活用しにくいという問題がありました。 今回の研究ではこの課題に取り組み、目的タスクを正しく解くプロンプトと、目的タスクを欺くための敵対的な生成プロンプトを同時に育てる手法「Adversarial GEPA」を提案しました。ラベル付きサンプルがわずか4〜8件という少数データの設定においても、既存手法（GEPA）を上回るプロンプト改善を実現しています。 発表をする井上 発表に使用したスライドは Speaker Deck で公開しています。 speakerdeck.com We Are Hiring! SmartHRでは最新技術に明るいメンバーが集まった環境で、革新的なAIプロダクトづくりに取り組んでいます。 ぜひ一度SmartHRのAIチームにご興味をお持ちの方へをご覧いただき、お気軽にお問い合わせください！ tech.smarthr.jp
- 生成AI
- LLM
- 機械学習
スクラムが新卒の学習環境として優れている理由 ── リファインメント・プランニング・モブプロから何を学んだか
はじめに 2025年新卒のブランドソリューション開発本部ZOZOMO部OMOブロックの東谷です！ 私は筋トレが趣味なのですが、増量期（筋肉をつけるために体重を増やす時期）が終わろうとしています。早く痩せなきゃと思いつつ、つい揚げ物や甘いものを食べ、現実から逃げている今日この頃です。 早いもので入社からもう1年が経ちました。この1年を振り返って一番強く感じているのは、スクラムは「アジャイル開発の手法」であると同時に、新卒にとっての最高の学習環境だったということです。 配属直後の自分は、リファインメントの議論についていけず、実装中もどこから手をつけてよいか分からない状態でした。それでも1年後、チームの中でスクラムを一通り回せるようになりました。この変化は、研修や独学だけではなく、スクラムの各イベントそのものに大きく支えられました。 スクラムがよく語られるのは「ビジネス価値を最大化する仕組み」としての側面です。しかし新卒視点から見直してみると、これらはすべて先輩たちの思考プロセスを短時間で観察し、その場で質問できる場でもありました。書籍やドキュメントでは身につきにくい「思考の型」、つまり先輩がどんな問いを立て、何をよりどころに判断しているかという基準があります。これを学べる環境として、スクラムは新卒にとって非常に整った構造を持っていると感じています。 この記事では、「思考の型」を自分が新卒1年目に具体的にどう身につけたかを振り返ってみます。題材として取り上げるのは、プロダクトバックログリファインメント（以下、リファインメント）、スプリントプランニング（以下、プランニング）、モブプログラミングの3つです。前者2つはスクラムイベントで、モブプログラミングはチームで採用している開発プラクティスです。新卒エンジニアには「スクラムは新卒の最高の学習環境になりうる」という視点を、新卒受け入れを担う開発組織には育成設計のヒントを提供できればと思っています。 目次 はじめに 目次 配属直後の自分とチームの環境 スクラム開発で身についた3つの学び 1. リファインメント：機能を「課題解決の手段」として見る視点が身についた 先輩が立てる「問い」が、自分の視野を順に広げていった 議論を経て、機能の質と学びが見えた 2. プランニング：Acceptance Criteriaで「実装の自由度」を制御することを学んだ Acceptance Criteriaで「実装の自由度」を制御する 見積もり精度はAC定義の解像度の問題に集約される 3. モブプログラミング：「事実ベースで実装する」という姿勢が身についた 先輩は事実から方針を決めていた 「事実から始める」という型を学んだ AI時代に、思考の型はどう活きるか おわりに 配属直後の自分とチームの環境 配属前の自分にとって「開発」とは、仕様が決まったタスクを実装することとほぼ同じ意味でした。 学生時代に長期インターンとして参加していたのは、ITベンチャー企業のBtoBプロダクト開発チームでした。そのチームのバックログには仕様まで書かれたタスクが並んでおり、エンジニアはその中から自分でタスクを取って作業する開発サイクルでした。タスクはリーダーが起票していき、起票時点で何を作るかは決まっています。自分の仕事は、それをコードに落とす精度と速度を上げることだと思ってました。 そんな自分が配属先の今のチームに入ったとき、まず驚いたのは開発サイクルの「広さ」でした。 リファインメントでは、プロダクトバックログアイテム（PBI）の目的や受け入れ条件を整理し、チームで認識を揃えながら実装可能な粒度まで要件を具体化します。プランニングでは、スプリントゴールを踏まえてチーム全員で作業内容を確認し、相対見積もりをしながらスプリント内で達成する内容を決定します。開発中はモブプログラミングを通じてリアルタイムに知識共有と意思決定を行います。スプリントレビューでは完成したインクリメントをステークホルダーとともに確認し、次の方向性を議論します。 この1週間のスプリントを、新卒の自分も初日からチームの一員として回すことになります。それまでの開発経験と決定的に違ったのは、バックログにタスクが並ぶ前の段階から、自分も議論に参加するという点でした。 もう1つの驚きは、議論についていくために要求される知識の量です。リファインメントやプランニングでは、複数の前提知識を踏まえた議論が当たり前のように展開されます。例えば、自分の担当しているサービスが他のサービスとどう連携しているか、CQRSで構築されたデータの流れはどうか、認証基盤との関係はどうなっているのかなどです。配属直後の自分は、議論の中で出てくる用語の半分も追えていない状態でした。 「自分が貢献できるだろうか」。最初の数週間、率直に言ってそう感じていたのを覚えています。 ところが、振り返ってみるとこの環境が、自分にとってこれ以上ない学習機会になっていました。スクラムの各イベントが、まさに知識、経験が足りていない新卒にとって最適な学習装置になっていたからです。 スクラム開発で身についた3つの学び ここからは、新卒1年目で身についた3つの学びを、具体的なエピソードとともに紹介します。 1. リファインメント：機能を「課題解決の手段」として見る視点が身についた 私が所属しているチームでは、ZOZOTOWN上でブランド様の店舗在庫を確認し、商品の取り置きができるサービス「ZOZOMO店舗在庫取り置き」を開発しています。複数のマイクロサービスが連携し、CQRSを採用しているため、イベントを通じたデータの流れを理解することが開発の前提になるプロダクトです。 配属されてしばらく経った頃、ブランド様の店舗情報をシステム上で更新できる機能を実装しました。それまでは開発チームが手動で対応しており、完了までに3営業日ほどかかっていました。ブランド様を待たせることになり、運用者の認知負荷や作業時間も大きいという課題がありました。 議論に参加する前、私の頭にあったイメージは簡単でした。「入力フォームを作って、POSTで更新するAPIを叩けば完了」。配属されたばかりの私は、機能を「実装するもの」として捉え、実装イメージが浮かんだ時点で完成像が見えたつもりになっていました。 ところが、実際のリファインメントの議論はまったく別の地点から始まりました。 先輩が立てる「問い」が、自分の視野を順に広げていった 最初に出てきたのは、システム構造に対する問いでした。認証基盤との関係、マイクロサービスごとの責務、そしてデータがどのサービス間をどのように流れるのか、といった内容です。私が「POSTを1つ作ればいい」と思っていた機能は、実際には複数のサービスにまたがってイベントを発行し、各サービスがそれぞれの責務でデータを更新していくものでした。CQRSやイベント駆動の設計は独学で吸収するには時間のかかる領域ですが、議論の場で出てくる用語や設計判断についてその場で質問できることで、認知負荷の高い情報を一気に吸収できました。 次に、システム設計が具体化してくると、想定していなかった論点が次々と出てきます。「店舗情報が更新されたことをどう確認するのか」「確認するためにはどのデータが必要か」。考えるべきことが膨らんでいくなかで、先輩から自然に出てきたのが「この機能はそもそも何を解決するものだったっけ？」という問いでした。 そこから議論は、機能を実装する話からユースケースを実演してみる話に切り替わります。実際の運用者の動きを想像し、ときには運用者に直接ヒアリングしながら、ユーザー体験ベースで仕様が具体化されていきました。 例えば、「店舗情報として更新できるデータは何があるのか」を全部洗い出すところから始まりました。さらに「運用者が更新ボタンを押す前に、入力ミスがないと安心できる状態は何か」「更新した後、本当に意図通りに反映されたかをどう確認するか」など、ユーザー体験の細部にまで問いが続いていきます。これらに応える形で、機能の中身が具体化されていきました。 さらに出てきたのが、「この機能を実装した後の恒久的な運用フローはどうなるか？」という問いです。「今回のケース以外にも対応できる汎用性って必要だっけ？」「逆に今回のユースケースに限定すれば不要となる実装ってないっけ？」のように汎用化を考える問いと、削ぎ落とすための問いが、同じ場で同時に飛び交っていたことが印象的でした。 象徴的だったのが、ブランド情報の鮮度をめぐる議論です。ZOZOMOのシステム構成上、店舗が所属するブランド様の情報が変わったとき、システム側は正常に更新されますが、その変更がリアルタイムで運用ツールに表示されない仕組みでした。そのため運用上、「正確なデータを変更しているかどうか確認したい」と運用者から開発側へ問い合わせを受けるケースの発生も予測されました。今回の店舗情報の更新機能を考えるうえで、この運用上の課題へ手を入れる余地があると判断し、ブランド情報を最新状態として取得し直す機能を同じ画面の中で組み込むことになりました。この機能を実装した結果、関連する問い合わせは発生していません。目の前の機能要求だけでなく、運用される将来の状態まで含めて考えることで、機能の質が変わっていく瞬間でした。 議論を経て、機能の質と学びが見えた リファインメントの議論を経て、最終的な機能は、私が当初抱いていたイメージとは大きく違うものになりました。最終的にできたのは、店舗情報の更新作業だけでなく、その前後で必要になる作業まで1画面で完結できる機能でした。 1画面に統合したのは、更新前の確認（店舗IDから店舗名・ブランド名を表示）、更新後の確認（変更後データの表示）、そしてブランド情報の鮮度を保つための再取得機能の3つです。これにより、運用者は別ページに遷移したり、別件で開発側に問い合わせをしたりする必要がなくなりました。効率よく作業できる機能に仕上がっています。 この一件で体感したのは、機能の「核となる実装」は全体のごく一部にすぎないということでした。POSTのAPIとUIという核は確かにイメージできていましたが、それが実際のユーザーへ届きビジネス価値へとつながるまで、想像をはるかに超える議論と設計判断が積み重なっていました。 リファインメントに新卒のうちから参加できたことで、私は機能を「実装するもの」ではなく「課題を解決するもの」として見る視点を、議論の中で自然に身につけることができたと感じています。これは、先輩から受け取った最初の思考の型のひとつでした。 2. プランニング：Acceptance Criteriaで「実装の自由度」を制御することを学んだ リファインメントで十分実装が可能だと判断されると、次はプランニングでスプリントの計画を立て、タスクの洗い出しやタスクの規模を見積もります。配属直後の私にとって、この時間はリファインメント以上に難しいものでした。 規模の見積もりには、チームごとに蓄積されるベロシティ（過去のスプリントでどれくらいの規模を消化できたかという感覚値）があります。「このくらいの規模の変更ならだいたい何ポイント」という相場が、過去の実装経験から自然と形成されていきます。配属されたばかりの自分にはそれがなく、対象機能の核となる変更部分の理解もまだ浅い状態で、規模を出すのは正直難しい作業でした。 では、先輩はどう見積もっているのかなと気になりました。観察して印象的だったのは、実装を頭の中で先取りして見積もるやり方でした。ZOZOMOではDDDやCQRSを採用しているため、これはコードベースを頭の中で走らせる形になります。例えば「Query側のStore集約のUsecaseでデータを整形して、Infra層に店舗集約をUpsertするクエリを書いて、UnitTestとE2Eを書いて…」といったイメージです。見積もりは「数字の当てっこ」ではなく、この工程をどれだけ正確に頭の中で走らせられるかなのだと理解しました。そして、その想像力を支えているのは、過去の実装を積み重ねてきた経験にほかなりませんでした。 Acceptance Criteriaで「実装の自由度」を制御する 想像力と経験がある程度身についた状態で、より規模を正確に見積もり、要件を満たすために考えるべき重要な指標があることに気づいたのは、1年経ってからでした。それがAcceptance Criteria（受け入れ基準、以下AC）の解像度です。 ACとは、その機能が「完成した」と判断するための条件を具体的に言語化したものです。重要なのは、ACの粒度が実装の自由度をコントロールするということでした。 象徴的だったのが、ブランド様と店舗の紐付けを除外する設定を確認する機能の実装です。これはリファインメントの結果、ブランド様ごとに検索ができ、絞り込んだ結果をExcelとして出力する機能も追加するスコープに広がりました。Excelはメールで該当ブランド様に送り、店舗とブランド様の紐付きが正しいかを確認してもらうためです。 このときのACの一例は、「検索後、Excel出力ボタンを実行したタイミングでポップアップが表示され、絞り込みした店舗の属するブランド一覧がポップアップに表示されること」と定義しました。 このACは、自由度の制限の仕方が絶妙でした。検索のクエリや検索ロジック、Excel生成の方法そのものには制限がかかっていません。より良い実装方法があれば実装時に改善できる余地が残されています。一方で、出力時にポップアップで対象データを一覧表示するという最終的な体験の部分は明確に固定されています。これは複数ブランドを指定して検索できる仕様上、運用者が「どのブランド様のExcelを送ろうとしているんだっけ？」を実行直前に視覚的に確認できる状態を保つことで、ヒューマンエラーを抑えるためです。 ACが「実装の細部までガチガチに固定する文書」になっていると、開発者は工夫の余地を失います。逆にACが曖昧すぎると、実装中に判断を迫られる回数が増え、規模が大きくブレます。ACは、考えてよい部分と考えなくてよい部分を明確に切り分け、実装の自由度を意図的にコントロールするための装置なのだと、この実装を通じて理解しました。 見積もり精度はAC定義の解像度の問題に集約される ACの粒度をこの形でコントロールできていたから、実装中に時間をかけて考える部分と、考えずに型通り進めてよい部分の切り分けが明確でした。結果として、見積もった規模と要件の両方を、ある程度の確度で同時に守れる構造になります。 規模そのものを正確に当てに行くのではなく、ACの粒度をコントロールして実装中の判断回数を制御します。プランニングを1年続けた末に言語化できたのは、「見積もり精度の問題は、その手前のAC定義の抽象度に集約される」という知見でした。 数字を出すこと自体に意識を向けていた1年前の自分から、今は「ACで実装の自由度を制御することで、規模と要件の両立を狙う」ことに意識を向けるようになりました。プランニングの場の捉え方がこのように変わったことが、この1年で起きた最も大きな変化の1つです。ACの粒度を意図的に調整するという考え方も、私のなかに定着した思考の型のひとつです。 3. モブプログラミング：「事実ベースで実装する」という姿勢が身についた リファインメントとプランニングを経て、いよいよ実装フェーズです。私のチームでは実装の多くをモブプログラミングで進めます。複数人が同じ画面を見ながら、ナビゲーター役とドライバー役を交代しつつコードを書いていく形式です。 モブプロから学んだことは数多くありますが、今の自分に最も大きく影響しているのは「事実ベースで実装する」という姿勢です。 先輩は事実から方針を決めていた リファインメントやプランニングで要件をどれだけ詰めても、実装段階で「考慮しきれていなかったこと」は必ず出てきます。とくにマイクロサービス間でデータを連携している箇所では、外部要因も絡んで挙動が読みにくくなります。 ZOZOMOでも、他のマイクロサービスとイベントを通じたデータ連携をしています。しかし、さまざまな要因によりイベントの連携順序が入れ替わり、本来連携されるべきデータを正しく届けられないケースもありました。この問題に対処する仕組みを実装した際、モブプロで先輩のアプローチを間近で見たのが印象的でした。 先輩はまず、入れ替わりが起きたデータを全件出してくるところから始めました。一部ではなく全体を並べて共通項を探すと、どの経路の、どのタイミングで入れ替わりが起きているのかという事実が浮かび上がってきます。 そこから先輩が見出したのは、ZOZOMO側の開発基盤にデータが連携される箇所で、入れ替わりそのものを直すという根本的な解決策でした。全件のデータという事実から出発したからこそ見つけられた解決策です。 「事実から始める」という型を学んだ このやり方の何がすごいかというと、実装の前に「何を解決すべきなのか」が事実として明らかになっていることです。事実から始めれば「この具体的なケースを直すには何が必要か」という明確な目的が手元にあります。結果として、不要な処理が混ざらず、シンプルでビジネス価値の高い実装にたどり着きやすくなります。 このとき自分が何より学ん
- スクラム
- アジャイル
- モブプログラミング
- チームビルディング
Build First, Discuss Later｜初回ミーティングに動くプロトタイプを持ち込んだら、意思決定が爆速になった
こんにちは、メルペイiOSエンジニアのkubomiです。 この記事は Merpay & Mercoin Tech Openness Month 2026 の 10日目の記事です。 生成AIによって、エンジニアが短時間でプロトタイプをつくれる場面はかなり増えました。最近、小規模なプロジェクトで「初回ミーティングの前に、動くものをつくり切ってしまう」という進め方を試したところ、意思決定のスピードが劇的に変わりました。私はこのやり方を "Build First, Discuss Later（まずつくる、議論は後）”と呼んでいます。この記事では、その具体的な進め方と、実践を通じて私自身に起きたマインドセットの変化を紹介します。 よくある開発フローと、その課題 私たちの現場では、開発に取りかかる前に、まず関係者の認識をそろえておくのが一般的です。具体的には、最初にプロダクトマネージャー（PdM）が大まかな仕様を用意し、それをもとにキックオフミーティングを開いて詳細を議論します。議論を経てPdMが仕様を固め、エンジニアはその仕様をもとに見積もりを出して実装に入ります。 ただ、議論して仕様を固めたつもりでも、いざつくり始めると「あれ、ここの挙動どうするんだっけ？」という疑問が次々と出てくることがあります。そのたびにPdMへ確認したり、追加のミーティングを開いたりすると、少しずつコミュニケーションの往復が増えていきます。 "Build First, Discuss Later" という提案 そこで私が実践したのが、プロセスの順番をあえて逆転させる "Build First, Discuss Later" です。仕様が固まる前に、まず動くプロトタイプをつくってしまうという発想で、ミーティングはその動くものを土台に議論を進めます。 従来は「議論して仕様を固めてからつくる」流れでしたが、これを「先につくり、その動くものを見ながら議論する」へと入れ替えます。実際に触れる画面があると、抽象的な仕様書をめぐる議論よりもはるかに早く、関係者の認識がそろっていきます。 ただし、何にでもこの進め方を使うわけではありません。何日もかかるような大きな実装でこれをやると、方針が変わったときの手戻りが大きすぎます。私の場合は、数時間から1日以内でつくれるくらいの小規模な施策に限定しています。そのくらいの規模なら、悩んで待つより、とりあえずつくってしまったほうが圧倒的に速い、という実感があります。 ミーティングにプロトタイプを持ち込む3つのステップ 私は "Build First, Discuss Later" を、ミーティングの前・中・後という3つの場面に分けて実践しています。ここでは、アプリの画面にバナーを追加した事例を例に、それぞれの場面で意識していることを順に紹介します。 ミーティング前：自分のベスト案でつくり切る ミーティング前は、手に入る計画書や仕様書をAIと一緒に読み込み、「なぜつくるのか（Why）」「何をつくるのか（What）」を自分なりに解釈します。この段階で最も大事なのは、完璧な実装をつくることではなく、どこが曖昧なのかを目に見える形にすることだと考えています。実際、詳細が決まっていないことがほとんどですが、曖昧な点にぶつかっても立ち止まりません。PdMに質問する代わりに、いったん自分が考えるベストな案でつくり切り、迷ったポイントはミーティングのアジェンダに整理しておきます。 たとえば、バナー追加の事例では、リリースに必要な最小限の機能に絞って早くリリースするか、将来使い回せる再利用性を優先するか迷いながらも、まず最小限の機能で動くプロトタイプをつくりました。UIデザインがまだない場合も、既存の画面部品を組み合わせた仮の見た目で形にしました。 ミーティング中：動くものを見ながら論点を解消する ミーティング中は、その動くプロトタイプを見せながら議論し、可能な限りその場で論点を解消します。意見が分かれそうな箇所には、あらかじめA案とB案を用意し、「私はこういう理由でA案を推します」と推奨案まで添えておきます。バナーの例では、期日を踏まえて、リリースに必要な機能に絞った設計プランと、将来の再利用まで見据えた設計プランを提示し、PdMはその場で前者のプランに合意できました。細かな仕様も、プロトタイプを見ながらサクサクと決まっていきました。判断の材料がそろっているため、議論は驚くほど早く前に進みます。 ミーティング後：決まった内容をすぐ反映する ミーティング後は、決まった内容を仕様書に反映し、実装を微修正したうえで品質保証（QA）のテストに回します。大きなつくり直しが起きにくく、初回ミーティングの直後にはリリースが見えている、という状態になりました。バナーの例では、私がつくった仮の見た目をデザイナーが本番デザインへブラッシュアップし、実装側はそれを反映する微修正で済みました。 "Build First, Discuss Later" で起きた3つの変化 この進め方を試してみると、ミーティングの進み方やPdMとのやり取りがかなり変わりました。特に大きかった変化は、次の3つです。 1つ目は、ミーティングがほぼ1回で完結するようになったことです。うまくいけば、初回ミーティングが終わった時点で仕様も実装もほぼ固まっており、開発見積もりすら不要になることもあります。その後の往復も大きく減りました。 2つ目は、議論が速く、かつ正確になったことです。実際に動くものを見せながら「この画面の挙動はこれでよいですか」と確認できるため、言葉だけのやり取りで生じがちな認識のズレが起きにくくなりました。 3つ目は、PdMの負担が軽くなったことです。エンジニアが具体的な仕様の案まで持っていくので、PdMは方針を確認するだけで済みます。特にPdMが複数プロジェクトを兼務しているような状況では、その確認コストを減らせるだけでも大きな価値があります。 「待つエンジニア」から「提案するエンジニア」へ こうした変化は、単に開発プロセスやコミュニケーションを効率化しただけでなく、私自身のエンジニアとしてのマインドセットにも影響を与えました。 以前の私は、決まった要件を正しく実装することがエンジニアの主な役割だと思っていました。けれど、PdMが持つWhyと大まかなWhatを起点に、まず動くものをつくってみると、「これは要らないかもしれない」「こっちの方がお客さまに価値を届けられるのでは」といった議論を、自分から持ち込めるようになりました。 いちばん大きかったのは、「私はこれがいいと思う」というアイデアを持ってミーティングに参加できるようになったことです。ただ仕様を待つのではなく、要件定義の段階から意見を出し、仕様を決めていく側に少しずつ入っていけるようになりました。 そうやって関わっていると、「この機能は今いちばん自分が詳しい」というオーナーシップも自然と生まれてきます。自分の提案が仕様に反映され、動くものを通じてプロダクトの方向性が決まっていく。その過程に関われるようになって、プロダクトづくりが前より一層楽しくなりました。 生成AIによって「まずつくってみる」ハードルが下がったことで、エンジニアが上流の議論に入りやすくなったと感じています。プロトタイプをつくってミーティングに持ち込むことは、単に開発を速くするだけではなく、エンジニアがより主体的にプロダクトづくりに関わるためのきっかけにもなるのだと思います。 まとめ "Build First, Discuss Later" は、先に動くプロトタイプをつくり、それを見ながら議論することで、意思決定を速くする進め方です。みなさまも、「仕様待ちで開発が始められない」「仕様が曖昧で手戻りが多い」と感じたら、自分なりのプロトタイプを会議に持ち込んでみてください。会話が前に進むだけでなく、プロダクトづくりの楽しさも少し違って見えてくると思います。 次の記事は mewutoさんです。引き続きお楽しみください。
- 生成AI
- プロトタイピング
- プロダクトマネジメント
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
CA Tech JOB 参加記録【極予測やりとりAI】
はじめに こんにちは！電気通信大学大学院 情報理工学研究科 修士1年の南村栞多と申します。2026年 ...
- Datadog
- Slack
- Go
- バッチ処理
そのAI活用、実は「あの人頼み」になっていませんか? ― Amazon Quickで、AIを「個人技」から「チームの仕組み」へ
クロスインダストリー第一本部の渡部です。 最近はAIの普及により、業務が大きく効率化されてきました。「もうAIが無いと仕事にならない」という方も多いのではないでしょうか。 そんな中で、こんな声を耳にすることがあります。 「AIを使えば、誰でも質の高いアウトプットが出せる」 「AIを使えば、業務の属人性は排除できる」 果たして、本当にそうでしょうか。 私はむしろ、「AIの活用の仕方そのもの」に新たな属人性が生まれていると感じています。同じツールを使っているはずなのに、人によってアウトプットの質が大きく違う。その差は、次の2つから生まれます。 AIにどんなデータを読み込ませるか（データの属人性） …
- 生成AI
- AWS
【CloudFormation/SAM】デプロイ時の環境変数を参照する方法
こんにちは、サービス開発部のくればやしです。 今回は、AWS SAM CLI（以下SAM CLI）で実行環境の環境変数をテンプレート内で展開する方法を解説します。 解説 例えば別のIaCツールである Serverless Framework の場合は以下のようにテンプレートファイルの中で指定するだけで参照が可能になります。 provider: environment: API_KEY: ${env:API_KEY} SAM CLIの場合は、一度 Parameters として外部から入力される値として定義した上で、参照する必要があるため、例えば以下のように定義したうえで、 Parameters:…
- AWS SAM
- CloudFormation
Code w/ Claude Extended | Tokyo 参加レポート
ファインディの森（@jiskanulo）と西村（@sontixyou）です。 2026年6月11日に開催されたAnthropic主催のイベント「Code w/ Claude: Extended | Tokyo」に終日参加してきました。 claude.com 本記事はその参加レポートです。私たちがセッションを聴いてどう感じたか、セッションの内容をどう活かすかの感想も書いていきます。 Workshopで気になったセッション How we Claude Code Ship your first Managed Agent ドメインエキスパートがソフトウェアを作る What happens when domain experts can finally build The 1% problem: How domain expertise + Claude let a 2-person team hit #1 on a global classification benchmark まとめ ファインディでは一緒に働く仲間を募集しています Workshopで気になったセッション 西村は主にAnthropicメンバーによるWorkshopへ参加しました。Anthropicが取り入れている設定や仕組みを弊社のプロダクト開発フローに適用できるかを意識して聴きました。 How we Claude Code claude.com Anthropicメンバーが実際に使っているClaude Codeのセットアップ方法を紹介するものです。 今回のイベントでのワークショップで説明された題材は次のリポジトリで公開されています。 github.com このセッションで最も印象に残ったのは「徹底インタビュー」と「HTML先行プロトタイプ」の2つです。 「徹底インタビュー」では、Claude Codeにインタビュアー役を担わせて要件を引き出します。 インタビューでは、つぎのインタビュープロンプトをClaude Codeに渡して、HTMLのプロトタイプを作るための要件を引き出す設計になっていました。 I want to build a bill-splitting app, can you help me brainstorm with me on who the audience is, and then interview me in-depth using the AskUserQuestion tool about what to build, focusing on pulling out any ambiguities to create a spec. 上記のプロンプトを実行し、Claude Codeとのやりとりを通して、要件の曖昧さを潰していき、SPEC.mdを作成する流れが紹介されました。要件の曖昧さを上流で潰すことで、実装のやり直しを減らすという設計思想です。 つぎに「HTML先行プロトタイプ」ではSPEC.mdをもとに、4つの異なるデザインを提案させて、HTMLのプロトタイプを作る流れが紹介されました。 Read ../phase-1-planning for its spec file, then help me figure out the overall design of this app. Explore 4 different designs, and create a set of HTML files with important screens for each. 上記のプロンプトを実行すると、つぎのHTMLのプロトタイプが出力されました。 Markdown形式でデザイン仕様を書き出すのではなく、クリックできるHTMLのプロトタイプを出力することで、見た瞬間に判断できます。 設計するタイミングで、Claude Codeとの認識合わせが視覚的にできることで、実装フェーズでのやり直しが少なくなり、トークン使用量の削減につながります。 また、既に運用しているサービスではデザインシステムといったデザイン基盤があれば、精度よくHTMLを出力できる可能性があります。それによって、新しい機能のデザインをするときの認識合わせがスムーズになりそうだと思いました。 Ship your first Managed Agent claude.com Claude Managed Agents（CMA）の全体像を、インシデントレスポンスのデモを通して整理するワークショップです。 このセッションで印象に残ったスライドが「The brain left the box」でした。 以前のアーキテクチャは、Agent loopとTool executionが同じコンテナの中に同居していました。Managed AgentsではAnthropicが管理する1つのサービスとして動き、ツール実行のSandboxはツールが必要なときだけオンデマンドで起動します。クライアントが切断されていてもループは動き続けるため、ローカルのターミナルを閉じてもセッションが止まりません。 これまで西村の開発環境のClaude Codeの使い方では、ローカルPCでClaude Codeを稼働させているため、プロンプトを入力しないとAIエージェントが動き出せませんでした。また、並列セッション数も最大8が限界でした。 Managed Agentsはこの2点を変えられると感じました。オンデマンドで非同期で動き続ける実行環境があれば、人間の合図を待たずに実装する用途が一気に現実的になります。 試したい用途として思い浮かんだのは、着手できていないイシューの開発・リファクタリング、そして人間が介在せずにPRをマージすることです。 最後の「自律マージ」には前提条件を考えなくてはいけません。最低限必要な前提条件を決めておかなければなりません。 例えば、テストカバレッジが一定基準を超えていること、テストの堅牢性が担保されていることなどです。 これらの前提条件を満たすための仕組みを整えることが、AIエージェントによる自律マージの実現に向けた重要なステップになると感じました。 ドメインエキスパートがソフトウェアを作る 森はFounder stageを中心に話を聞いていました。 いずれのセッションもドメインエキスパートの知識・決定が重要であることを話されていました。 いくつかご紹介します。 What happens when domain experts can finally build claude.com 登壇はクイーンズランド大学のJason Tangen教授。AIネイティブ時代のプロダクトは、汎用的な人材ではなく深いドメイン知識を持つ個人から生まれるという主張です。 「去年までソフトウェアを一行も書いたことがなかった」という彼が、6ヶ月で3つの本番アプリをデプロイしました。 登場したアプリはいずれも学生向けのもので、シラバス生成ツール（classbuild.ai）、法廷証言トレーニング（crosscoach.ai）、学生向け説明ツール、学生の顔と名前を覚えるゲームなど。 専門家の頭の中に眠っていたアイデアが、AIにより作るコストが下がり具現化できるようになりました。 最後に聴衆へ「あなたが何年も密かに欲しいと思っていた小さなツールは何ですか？」「チームの中で、実際にその仕事をやり続けてきた人は誰ですか？」と問いかけられました。 コードを書く能力ではなく、「何を作るべきか」を知っていることが大切なのだと感じました。 The 1% problem: How domain expertise + Claude let a 2-person team hit #1 on a global classification benchmark claude.com 登壇者はGahee Seo氏。分類の誤りが金銭的損失に直結する貿易コンプライアンス領域で、ドメイン知識とClaudeの組み合わせが基盤モデル単体を超える優位を生むことを示します。 韓国からEUへの輸送など、さまざまな規制が複雑に絡み合う貿易の領域では、どんなAIモデルを使うかよりも専門家の判断フローをどう再現するかが優位を決めるとのことです。 最初のプロトタイプはSingle agentで1件の分類に6分かかっており、また、アウトプット精度にも課題があったとのことです。 課題を解決するために分類器を新しく訓練するのではなく、専門家が5段階で判断するワークフローを複製したという設計思想を発表してくれました。 入力が曖昧なまま処理が走らないようinput gateを設けたこと 全規制ルールをsystem promptに詰め込む設計をやめ、必要な文書を検索する Retrieval と出力結果を検証する Verifierという構想に転換 これらの対応をとりあげていました。さらにエージェントを役割ごとに分割することで30秒まで短縮しました。 アウトプットではなくワークフローを教える、という発言もありました。 期待する出力形式を示すのではなく、専門家がどういう順番で何を見て判断するかをシステム化する。職人芸をインフラに変える、という表現が使われていました。 まとめ 西村が午前に参加したAnthropicのワークショップ2つには、共通した問いがありました。 How we Claude CodeのHTMLプロトタイプは、実装前に人間の判断を前の工程に集約する仕組みです。Ship your first Managed Agentの非同期実行は、後工程での人間の介在を手放すための基盤です。 方向は逆に見えますが、根底にある問いは同じだと感じました。「人間はどこで関与すべきか」を先に設計する、という考え方です。その2点を組み合わせることで初めて、AIと人間の役割分担がきちんと設計できると思いました。 森の参加したセッションは「個人開発者・アーリーステージな創設者向け」という性格のものが多かったです。個人が専門知識を武器にプロダクトを作る事例が多く、それ自体は示唆に富んでいました。 どのセッションでも専門家の知識、決定が大事であるという主張を別の角度から語っていました。 一方で、チームでどう使っていくか・チームの中でどう成長していくかという話はありませんでした。 最近個人的に悶々としている「専門家がいない領域でどう専門性を担保するか」「専門家をどう育てるか、時間をかけるしかないのか」という問いには答えが見つからなかったので引き続き考え続けます。 ファインディでは一緒に働く仲間を募集しています ファインディでは一緒に会社を盛り上げてくれるメンバーを募集中です。興味を持っていただいた方はこちらのページからご応募お願いします。 <iframe src="https://hatenablog-pa
- 生成AI
- Claude
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
- フロントエンド