AIシステムの品質保証は、従来のソフトウェアテストとは異なるアプローチが求められます。本記事では、品質モデルの国際規格「ISO/IEC 25059」で拡張された「自律性」「自己学習性」「予測性」「公平性」「堅牢性」という5つの新しい品質特性に焦点を当て、それぞれの特性に対する具体的なテストアプローチの考え方を解説します。AIの進化が著しい過渡期において、プロジェクトごとに最適なテストを設計するQAエンジニアの重要性を論じます。

はじめに こんにちは、Recruit Data Blog 担当の森です。 リクルートのデータ推進室では「Data Meet Up!」と題して、定期的にイ

こんにちは。メルペイ Payment & Customer Platform（PCP）チームでBackend Engineerをしている @ryuyama です。この記事は「 Merpay & Mercoin Tech Openness Month 2026 」の1日目の記事です。 はじめに メルカリでは、2025年9月30日にグローバル版のメルカリアプリをリリースしました。このアプリは台湾・USをはじめとして、 3年以内に50カ国へ展開することを目指しており 、メルカリのグローバル展開を

中国 (国番号 +86) へのコンプライアンスに準拠した発信を維持することは、通信規制が進化し続ける中、グローバル企業にとって大きな課題です。 Amazon Connect Customer を使用して中国へ顧客コミュニケーションを行っている場合、コンプライアンスのベストプラクティスを理解し実装することで、サービスの中断を回避し、顧客との関係を保護できます。 あるグローバル旅行サービス企業は、承認済みの電話番号の設定とレート制限の実装によって、Amazon Connect Customer による中国への

1. この記事で書いていること Amazon Web Services（以下AWS）より、2026年5月にAmazon Aurora MySQL 8.4がGAとなったことのリリースがありました。[1] Aurora MySQL v3はMySQL 8.0互換のメジャーバージョンでしたが、Aurora MySQL 8.4は MySQL Community Edition 8.4 LTSをベースにしたメジャーバージョンです。 このため、Aurora MySQL v3から8.4への移行は、単なるマイナーバージョン

※本記事は、ホスト系COBOL処理系からオープン系COBOL処理系への移行検証を整理する連載の最終回です。 1. シリーズの振り返り 本シリーズでは、移行時に発生し得る差異を以下の観点で整理してきました。 暗黙初期値 データ例外（0C7） ファイル定義 中間演算精度 移送元と移送先の属性 ソート順 いずれも共通しているのは、 コンパイルは通る 文法も正しい しかし動作が変わる という点です。 2. 差異の構造（3層モデル） 移行時の差異は、偶発的に発生するものではありません。 検証結果を整理すると、次の3

みなさん、こんにちは。AWS ソリューションアーキテクトの木村です。 AWS Summit Japan が開催される 6 月 25 – 26 日 まで 1 ヶ月を切りましたね。登録がまだの方は こちら から登録しぜひ来場ください！様々なコンテンツをご用意してお待ちしております！ また最近気軽に参加いただける勉強会として「昼休みの 30 分」を活用した Amazon Quick 勉強会が開催されています。 6 月 3 日 、 6 月 10 日 に予定されていますのでぜひご参加ください！ 「 AWS ジャパン

2026 年 5 月 13 日に公開された “ Accelerating VMware migrations with AWS Transform and MGN replication agent installation automation ” を翻訳したものです。 オンプレミスの VMware 環境から AWS への数百台のサーバー移行には、チーム、アカウント、ツール間の調整が必要です。ターゲット環境のセットアップ、ウェーブの計画、レプリケーションエージェントのデプロイ、進捗の監視、テストの実行、

こんにちは、ファインディでFindy Toolsの開発をしている本田です。 この記事は「 エンジニア達の人生を変えた一冊 」として、ファインディのエンジニアが人生を変えた本を紹介していくシリーズです。 Part7では、本田・加藤・山田の3名でお届けします。アジャイル開発との出会いになった本、iOSアーキテクチャ設計の答え合わせになった本、AI時代に再読して背筋が伸びた本。3冊それぞれ切り口は違いますが、いずれも自分の中の「開発の判断軸」を作り直してくれた一冊です。 それでは、さっそく紹介していきましょう。

テスト管理は、テストケースを実行して結果を記録するだけの作業ではありません。 テストの目的や範囲を決め、設計・実行・不具合管理・進捗報告・終了判定までを一連の流れとして管理し、リリース判断に必要な情報を整理する活動です。 現場ではテスト終盤になって未実行ケースが大量に残ったり、不具合の重要度や優先度が整理されないままリリース判定を迎えたりすることがあります。 こうした状況を防ぐには、テスト開始前の計画、実行中の進捗管理、不具合の可視化、終了時の報告までを仕組み化しておくことが重要です。 そこで今回はテスト

テスト管理では、テストケースの消化率や不具合件数を確認していても、「本当に品質は十分なのか」「リリースして問題ないのか」を判断しきれない場面があります。 消化率が高くても重要機能の確認が残っている場合や、不具合件数が少なくてもテスト観点が不足している場合があるためです。 そこで重要になるのが、テスト管理におけるメトリクスです。 メトリクスを活用すると、テストの進捗、品質状態、欠陥傾向、カバレッジ、修正状況などを数値で可視化できます。 これにより、感覚的な報告ではなく、根拠に基づいて品質状況やリスクを説明し

Claude Codeで仕様書を書くようになって、初稿の作成時間は劇的に短くなりました。 しかしながら、運用してみると、 リリースまでのリードタイム全体はほとんど変わっていない ことに気づきました。 今回は、「初稿は速くなったのにリードタイムが減らない」現象がなぜ起きるのか、自分の現場での観察をもとに整理してみます。 体感は爆速、でも実は遅い 正直、具体値を測っているわけではないんですが、 「仕様作成までは、爆速でおわる、仕様調整に時間がかかる」 といった実感があります。 ↓イメージ 「AIで爆速になった

はじめに こんにちは。リテールハブ開発部小売アプリチームの池です。 業務で Laravel Octane のメモリが残る挙動について調査する機会がありました。 Laravel Octane は、長時間稼働するプロセス上で Laravel アプリケーションを動かして高速化するツールです。便利な一方で、プロセスが長く生きるためメモリが残り続け、書き方次第ではリクエスト間で状態が引き継がれてしまうという、従来の Nginx + PHP-FPM 構成の Laravel では発生しにくい特性を持っています。この特性

本記事は 2025 年 12 月 10 日 に公開された「 How to use Sustainability Insights Framework on AWS 」を翻訳したものです。 従来、組織は炭素排出量を追跡し、気候関連レポートを作成する際に、複雑で労働集約的、かつエラーが発生しやすい手動プロセスに直面してきました。このプロセスでは通常、従業員が公共料金の請求書、燃料消費記録、調達文書、出張領収書、施設運営ログなど、異なるソースから無数の時間をかけてデータを収集する必要がありました。大規模なチーム

はじめに 前回の記事 では、Webアプリで映像を扱う際の産業用途におけるリアルタイムコミュニケーション実現のための検討ポイントと、intdashとintdash-RTC SDKという選択肢を紹介しました。 要点をおさらいすると: SFU選定時はベンダー固有の実装に依存する点も考慮が必要 センサーデータとの統合や録画・解析は追加の設計が必要になる可能性 intdashは、産業用途に適したもう一つの選択肢 前編では概要しか触れなかったため、実際の使用感について興味をお持ちいただいた方もいらっしゃると思います。