こんにちは。ファインディ株式会社でプリンシパルエンジニアをしている戸田です。 開発業務そのもののAI活用が進むにつれて、次に効いてくるのが開発以外の仕事、いわゆるトイルの対応でした。なかでも時間を取られがちなのが問い合わせ調査でした。 そこで、この問い合わせ調査をAIに任せることにしました。Slackから投げられた問い合わせに対して調査をして回答を返すエージェントを作り、AnthropicのManaged Agentsを使って、問い合わせが来たときだけ起動する仕組みにしています。 platform.cla

本記事は、私たちDBRE（Database Reliability Engineering）チームが2026年3月末までに行った改善を紹介する3つの記事の3つ目（最終回）です。 1つ目の記事「 メルカリにおけるTiDB改善の取り組み：IN句内100万件クエリへの対応 」では、IN句に多数の要素を含むクエリがTiDBクラスタ全体のレイテンシを悪化させた事例を紹介しました。2つ目の記事「 メルカリにおけるTiDB改善の取り組み：リソース制御・リージョンサイズ・プランキャッシュ編 」では、リソースグループの不具

1. はじめに 本シリーズでは、OpenCanvas Type-Oracle Alloy を用いながら、Oracleに限らず各種技術検証の結果をブログ形式で紹介していきます。 シリーズ1本目となる今回は、Oracle Database に搭載されている可用性機能 Transparent Application Continuity (TAC) を4回にわたって取り上げます。TAC は Oracle Database 18c で導入された技術で、従来の Application Continuity (AC)

2026 年8 月 10 日週、 OpenSearch と Valkey のチームはソウルを訪問し、 Open Source Summit Korea 2026 と MCP DevSummit Seoul 2026 でオープンソース開発者とコントリビューターに会いました。4 日間のイベントでは、オープンソースプロジェクトと新興エージェント AI のコミュニティリーダーとユーザーが集まり、知識を共有し、ソリューションについて協力し、プロジェクトを推進しました。 韓国の OpenSearch コミュニティのリ

本ブログは 2024 年 11 月 5 日に公開された AWS Blog「 Amazon Inspector suppression rules best practices for AWS Organizations 」を翻訳したものです。原文公開後のサービスアップデートを訳注として補足しています。 脆弱性管理は、ネットワーク、アプリケーション、インフラストラクチャのセキュリティに不可欠な要素であり、その目的は、機密データやインフラストラクチャが意図せずアクセスされたり露出したりすることから組織を保護す

こんにちは、AWS ソリューションアーキテクトの秦です 現在、AI コーディングエージェントの活用が広がり、コーディングの生産性は大きく向上しています。 筆者がとある開発部門で、AI コーディングエージェントの導入を支援するプロジェクトに参加したところ、個人利用の段階では成果が出ていたものの、複数チームへの展開を始めたところでいくつかの課題に直面しました。 本記事では、そのチーム展開の際に直面した課題に対して私たちが実際に行ったアプローチと、そこから得られた学びを共有します。 なお、本記事は、特定のプロジ

本ブログは、コニカミノルタ株式会社と Amazon Web Services Japan が共同で執筆しました。 はじめに 2026 年 6 月 25 日、26 日に幕張メッセで開催された AWS Summit Japan 2026 で、コニカミノルタ株式会社 ( 以下、コニカミノルタ ) は「Amazon Bedrock による自然言語駆動型自律実験」を展示しました。自然言語の指示を AI が構造化し、カメラで実験台の状態を確認しながらロボットアームを動かし、結果を電子実験ノートへ戻すデモです

こんにちは、エス・エム・エスでカイポケの報酬算定開発を担当しているエンジニアの宮坂です。 以前、カイポケリニューアルに向けた介護報酬算定ロジックの再実装について紹介しました。 この算定ロジックを組み込み、事業者が提供した介護サービスの内容をもとに、介護保険制度のルールに沿って金額を計算するのが報酬算定エンジンです。以前の記事では、難解な算定ロジックと向き合うための取り組みとして、専門家によるテストケースの作成やテスト実行の自動化について触れました。 この記事ではその続編として、QA観点のテストケースを算定

本記事は、私たちDBRE（Database Reliability Engineering）チームが2026年3月末までに行った改善を紹介する3つの記事の2つ目です。 1つ目のブログ記事の「 メルカリにおけるTiDB改善の取り組み：IN句内100万件クエリへの対応 」では、IN句に多数の要素を含むクエリがTiDBクラスタ全体のレイテンシを悪化させた事例を紹介しました。 本記事では、下記の4点の対応や改善についてお伝えします。 リソースグループの不具合に対する対応 リージョンサイズ (coprocessor

みなさん、こんにちは。ソリューションアーキテクトの戸塚です。今週も 週刊AWS をお届けします。 お盆も明け、まだまだ暑い日が続きますが、いかがお過ごしでしょうか。休暇中に溜まったアップデートを一気にキャッチアップされている方も多いかもしれませんね。 さて、生成AI開発の現場に身を置いていると、ここ最近「作る」こと自体のハードルがどんどん下がっているのを実感します。エージェントに任せられる作業が増え、これまで手作業だったコード生成やドキュメント作成、分析までもが数クリックで動き出す──そんな時代になってき

先日、 メルカリのCoreDBをMySQLからTiDBへ移行した振り返り という記事で、MySQLからTiDBへの移行完了に関する報告と、大枠の振り返りについてお伝えしました。これから3つの記事にわたって、私たちDBRE（Database Reliability Engineering）チームが、2026年3月末までに行った改善について紹介します。 1つ目の本記事では、メルカリの最も大きなクラスタ切り替え直前に発覚した、IN句に多数の要素を含むクエリがTiDBクラスタ全体のレイテンシを悪化させた事例を紹介

本ブログは 2026 年 8 月 12 日に公開された AWS Blog「 How AWS IAM role manager rethinks the starting point for IAM roles 」を翻訳したものです。 Amazon Web Services (AWS) 上で新しいアプリケーションや機能を構築するとき、注力したいのは構築そのものです。しかし、サービスを稼働させる作業は、ほとんどの場合 AWS Identity and Access Management (IAM) から始まり

G-gen の武井です。当記事では、Google SecOps で検知したアラートの是正対応を Playbooks で自動化する方法を解説します。 はじめに Google SecOps とは Playbooks（ハンドブック）とは 検証の流れ Cloud Audit Logs の取り込み 検知ルールの確認 インテグレーションの設定 必要なインテグレーション BigQuery Slack ケース Playbooks の設定 Playbooks の構成 トリガー コンディション アクションの設定 動作確認 は

会計システムの導入や刷新でテスト工程に入ると、「何を確認すれば十分なのか」「ベンダーが実施したテストだけで本番移行してよいのか」と迷いやすくなります。 特に会計システムは、画面が問題なく動くだけでは品質を判断できません。 売上や仕入などの取引から正しい仕訳が作られ、残高や元帳、帳票まで一貫して反映されることに加え、税計算、売掛・買掛、入出金、決算、権限、周辺システムとの連携なども確認する必要があります。 さらに、新システムへ切り替える場合は、旧システムから移したマスタや残高、未消込データなどが正しいかとい

はじめに リアルタイム性の高いマルチプレイヤーゲームは、複数のプレイヤーの入力を集約し、ゲームの状態を一貫させて全員へ配信する仕組みを必要とします。この仕組みの一つに、権威あるサーバーがゲームの状態を管理する専用ゲームサーバー (Dedicated Game Server) 方式があります。対戦の公平性やチート対策、多人数の同時接続が求められるタイトルでは、専用ゲームサーバー方式が広く採られています。この方式では、マッチメイキング、ゲームサーバーの割り当て、セッション終了後のサーバー回収といったライフサイ