はじめに こちらの記事 で実際にKubernetes環境にKubeBlocksを導入し、DBaaSの基盤を構築しました。 前回の記事 ではKubeBlocksを利用してDBaaS基盤上にMySQLを構築しました。 今回は、KubeBlocksを利用してNoSQLのインメモリデータベースであるRedisを構築していきます。 導入環境構成図 以下の図は、DBaaS基盤上にRedisを導入する環境の構成図です。 「KubeBlocksオペレーター」は こちらの記事 で構築しました。 本記事では、赤丸で囲まれた「DB(Redis)」の構築を対象とします。 Redisはすべてのデータをメモリ上で処理する「インメモリデータベース」の一種で、NoSQLに分類されます。 ディスク（SSD/HDD）にアクセスする一般的なデータベースと比較して圧倒的に高速なのが特徴で、主にWebサイトやアプリの高速化（キャッシュ）や、リアルタイム処理に利用されるDBになります。 導入環境構成図 Redisの構築方法 KubeBlocksを使用してRedisを構築する手順をご紹介します。 今回は最もシンプルな、1台のサーバーでRedisを稼働させるスタンドアロン構成で作成していきます。 前提条件 KubeBlocksが構築済みであること KubeBlocksによってデフォルトでインストールされるRedisアドオン（以下コマンド結果のredis 1.0.1）が有効になっていること 以下のkbcliコマンドで有効化されているアドオンを確認することができます。 kbcli addon list # 出力例 NAME VERSION PROVIDER STATUS AUTO-INSTALL qdrant 1.0.1 community Disabled false rabbitmq 1.0.1 community Disabled false apecloud-mysql 1.0.1 community Enabled true etcd 1.0.1 community Enabled true kafka 1.0.1 community Enabled true mongodb 1.0.1 community Enabled true mysql 1.0.1 community Enabled true postgresql 1.0.1 community Enabled true redis 1.0.1 community Enabled true Namespeaceの作成 まずはRedisをデプロイするNamespeaceを作成します。 kubectl create namespace redis # 出力例 namespace/redis created デフォルトユーザー認証用Secretの作成 Redisのデフォルトユーザー用のユーザー名・パスワードを設定したSecretを作成します。 kubectl create secret generic custom-redis-root-secret \ --from-literal=username='default' \ --from-literal=password='<任意の値>' \ -n redis # 出力例 secret/custom-redis-root-secret created ※Redis作成時に本手順で作成したSecretを指定することで、デフォルトユーザーのパスワードを任意の値で設定することができます。 Secretの指定がない場合は、KubeBlocksがデフォルトユーザー用のパスワードを自動発行します。 Redisの作成 MySQLクラスター構築時と同様に、KubeBlocksのカスタムリソースである「Cluster」のマニフェストを適用し、Redisを作成します。 cat <<EOF | kubectl apply -f - apiVersion: apps.kubeblocks.io/v1 kind: Cluster metadata: name: redis-cluster namespace: redis spec: terminationPolicy: Delete clusterDef: redis topology: standalone componentSpecs: - name: redis replicas: 1 systemAccounts: - name: default secretRef: name: custom-redis-root-secret namespace: redis serviceVersion: 8.0.3 disableExporter: false resources: limits: cpu: "0.5" memory: "0.5Gi" requests: cpu: "0.5" memory: "0.5Gi" volumeClaimTemplates: - name: data spec: accessModes: - ReadWriteOnce resources: requests: storage: 20Gi EOF # 出力例 cluster.apps.kubeblocks.io/mycluster created clusterDef: redis Redisアドオンが提供するRedisの構成テンプレートを、作成するDBクラスターのベースとして指定する設定です。 topology: standalone Redisを単一のRedisサーバーインスタンスで構成されるスタンドアロンクラスターとして起動する設定です。 terminationPolicy: Delete クラスターを削除した際、関連するデータも一緒に削除する設定です。 systemAccounts Redisのデフォルトユーザーの認証情報（ユーザー名・パスワード）に、事前に作成したSecretを割り当てる設定です。 volumeClaimTemplates DBのデータを保存するためのPVの設定です。 Redisの作成確認 Redis作成コマンド実行後、以下のコマンドでクラスター・Podのステータスを確認します。ステータスがRunningになっていれば正常に動作しています。 kubectl get cluster redis-cluster -n redis # 出力例 NAME CLUSTER-DEFINITION TERMINATION-POLICY STATUS AGE redis-cluster redis Delete Running 110s kubectl get pods -n redis # 出力例 NAME READY STATUS RESTARTS AGE redis-cluster-redis-0 4/4 Running 0 2m15s 動作確認 Redisへの接続テストを行います。 まず、作成したRedisのエンドポイント（Service名）を確認します。 kubectl get svc -l app.kubernetes.io/instance=redis-cluster -n redis # 出力例 NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE redis-cluster-redis-redis ClusterIP 10.43.163.160 <none> 6379/TCP 3m kubectl runコマンドでRedisクライアント用のPodを作成し、コンテナ内でシェルを起動します。 kubectl run redis-client -n redis --rm -i --tty --image=redis:8.0.3 --restart=Never -- bash # 出力例 If you don't see a command prompt, try pressing enter. root@redis-client:/data# redis-clientコマンドを使用し、確認したRedisのエンドポイント、「 デフォルトユーザー認証用Secretの作成 」で作成したユーザ名・パスワードを指定して接続します。 root@redis-client:/data# redis-cli -h redis-cluster-redis-redis.redis.svc.cluster.local -p 6379 --user default --pass xxxxx # 出力例 Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. redis-cluster-redis-redis.redis.svc.cluster.local:6379> Redisに正常に接続できているか、以下のPINGコマンドを使用して確認します。 redis-cluster-redis-redis.redis.svc.cluster.local:6379> PING # 出力例 PONG 「PONG」が出力されれば、正常に接続できています。 続いて、データの登録・取得が行えるかを確認します。 キー「test」に値「”Hello World” 」を登録します。 redis-cluster-redis-redis.redis.svc.cluster.local:6379> SET test "Hello World" # 出力例 OK 登録したデータが正しく取得できるかを確認します。 redis-cluster-redis-redis.redis.svc.cluster.local:6379> GET test # 出力例 "Hello World" 登録した「”Hello World” 」という文字列が出力されれば、Redisへのデータ登録と取得は正常に行えています。 これでRedisの構築と動作確認は完了になります。 おわりに 前々回構築したKubeBlocksを使用し、実際にRedisの構築から接続テストを行うまでの流れをご紹介しました。 前回のMySQL構築に引き続き、容易にRedisを構築できることを体感できたのではないでしょうか 。 今回は最もシンプルな「Redisサーバ1台のスタンドアロン構成」として構築しましたが、KubeBlocksなら本番環境向けの冗長構成も、マニフェストの設定を少し変更するだけで簡単に構築することができます。 KubeBlocksは様々なDBをサポートしているため、他のDBも同様の方法で手軽に導入することができます。 本記事が、Kubernetes上でDBを構築する際の選択肢として、KubeBlocksを検討するきっかけになれば幸いです。 参考文献 https://kubeblocks.io/docs/preview/kubeblocks-for-redis/03-topologies/01-standlone https://kubeblocks.io/docs/preview/kubeblocks-for-redis/06-custom-secret/01-custom-secret ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post KubeBlocksでRedisを導入！Kubernetes上での高速キャッシュ/NoSQL構築を体験 first appeared on SIOS Tech Lab .

勘定系システムは、預金、振込、融資、利息計算、残高管理など、金融機関の中核業務を支える仕組みです。 そのため、小さな不具合であっても、顧客の資産や金融機関の業務、社会的な信用にまで影響が広がる可能性があります。 画面が設計どおり動くことだけを確認しても、十分な品質を保証できるとは限りません。 業務の流れ、周辺システムとの連携、夜間処理、データ移行、性能、障害からの復旧まで、複数の観点をつなげて確認する必要があります。 一方で、すべての機能や条件を同じ深さで確認しようとすると、膨大な工数がかかります。 大切なのは、テストケースをやみくもに増やすことではなく、 守るべき業務と起こしてはいけない障害を明確にすること です。 顧客への影響、取引件数、金額、復旧の難しさなどを基準に、重大なリスクから優先して確認します。 そこで今回は、勘定系システムのテストで押さえるべき観点と進め方を、全体像から本番移行の判断まで順番に整理しました！ 限られた期間と人員の中で、テストの抜け漏れを減らし、関係者へ品質の根拠を説明するために役立つ内容です。 import haihaiInquiryFormClient from "https://form-gw.hm-f.jp/js/haihai.inquiry_form.client.js";haihaiInquiryFormClient.create({baseURL: "https://form-gw.hm-f.jp",formUUID: "927d2c4e-f06c-45b1-bd36-0240e55ccf72",}) ▼テストの種類について詳しい内容はこちら▼ 【保存版】テストの目的別タイプ一覧 勘定系システムのテストで最初に押さえたい全体像！ 勘定系システムのテストを計画するときは、個別の機能や画面を並べる前に、 どの業務を何から守るのか を整理する必要があります。 勘定系では、取引の正確性だけでなく、サービスを継続できることや、障害発生時に安全に復旧できることも重要な品質です。 単体テスト、結合テスト、総合テスト、受け入れテストには、それぞれ異なる役割があります。 工程ごとの目的が曖昧なまま進めると、前工程で確認すべき問題が後工程へ持ち越され、修正範囲や影響確認が大きくなります。 また、勘定系の品質は、機能だけを見ても判断できません。 業務シナリオ、周辺システム連携、性能、障害対応、運用、データ移行、セキュリティを含めて全体を捉える必要があります。 最初に確認領域を整理しておけば、テスト項目の重複や抜け漏れを減らし、業務部門、開発部門、基盤部門、運用部門の役割も分けやすくなります。 テストの全体像は、ケース作成だけでなく、環境準備、品質評価、本番移行の判断までをつなぐ設計図として扱うことが重要です。 まずは勘定系システムで「絶対に守るもの」を明確にする！ 勘定系システムで最初に守るべきものは、 顧客の取引と金融機関が管理する数値の正確性 です。 入出金、振込、振替、利息、手数料、融資返済などの処理では、画面に正しい結果が表示されるだけでは不十分です。 口座残高、取引明細、元帳、仕訳、帳票、周辺システムへ送られるデータまで、同じ取引結果が一貫して反映されている必要があります。 特に避けるべきなのは、取引の欠落、重複、二重計上、誤った口座への反映、残高不整合などです。 オンライン処理だけでなく、日次、月次、期末などの一括処理も対象に含めます。 日中の取引が夜間処理へ正しく引き継がれ、翌営業日の残高や帳票へ反映されるところまで確認することが大切です。 品質の優先順位を決める際は、顧客影響、取引金額、発生件数、決済への影響、業務停止時間、復旧難易度を基準にします。 すべての機能を均等に確認するのではなく、 障害時の影響が大きい領域ほど深くテストする設計 が現実的です。 この基準を最初に共有することで、テスト項目を絞る場合にも、判断の根拠を関係者へ説明しやすくなります。 単体・結合・総合・受け入れテストの役割を混同しない！ 単体テストでは、計算ロジック、入力値の判定、データ更新など、個々の機能が設計どおり動くかを確認します。 利息計算や手数料計算であれば、通常値だけでなく、上限値、下限値、端数、日付境界なども確認対象です。 結合テストでは、機能同士やシステム同士をつなぎ、データの受け渡しや処理順序が正しいかを確かめます。 送信先の停止、通信遅延、異常な応答など、連携先で問題が起きた場合の動作も確認します。 総合テストでは、本番に近い環境で、複数の機能やシステムをまたぐ業務が成立するかを確認します。 個別の処理が正常でも、一連の業務として実行したときに残高や状態が不整合になる場合があるためです。 受け入れテストでは、金融機関の利用部門が、実際の手順で業務を安全に遂行できるかを判断します。 操作性、帳票、運用手順、例外時の対応など、システム仕様だけでは判断できない部分も対象です。 各工程で目的、確認対象、実施者、開始条件、終了条件を明確にし、 後工程へ問題を先送りしないこと が重要です。 勘定系テストを支える7つの確認領域を整理する！ 勘定系システムのテストは、七つの領域に分けて整理すると全体像を把握しやすくなります。 一つ目は、取引や計算結果を確認する 機能・勘定処理 です。 二つ目は、口座開設から取引、締め処理までの流れを確認する 業務シナリオ です。 三つ目は、現金自動預払機、インターネットバンキング、決済ネットワークなどとの システム連携 です。 四つ目は、大量取引やピーク時の応答を確認する 性能・長時間稼働 です。 五つ目は、停止、切り替え、再実行、復旧を確認する 障害・運用 です。 六つ目は、旧環境から新環境へ残高や履歴を正しく引き継ぐ データ移行 です。 七つ目は、認証、権限、ログ、不正操作への耐性を確認する セキュリティ です。 これらは独立した領域ではなく、相互に影響します。 たとえば、連携処理の遅延が夜間処理の開始を遅らせ、翌日のサービス開始へ影響する場合があります。 確認領域を一覧化したうえで、要件、業務、リスク、テストケースを対応付けることが重要です。 七つの領域を共通の分類として使えば、複数部門や外部ベンダー間でも、テスト範囲と責任分担を共有しやすくなります。 抜け漏れを防ぐ！勘定系システム特有のテスト観点 勘定系システムでは、処理が正常終了したことだけで合格と判断すると、重大な問題を見逃す可能性があります。 画面上では完了していても、元帳や仕訳に反映されていない場合や、周辺システムへ同じ取引が重複送信されている場合があるためです。 そのため、 一つの操作がどこへ、どのように影響するか を追跡する視点が欠かせません。 通常取引だけでなく、取消、訂正、再送、再実行、障害復旧など、例外時の振る舞いも確認します。 さらに、営業日、休日、月末、年度末などの日付条件や、大量処理が集中する時間帯も重要です。 データ移行では、件数の一致だけでなく、金額、残高、履歴、業務状態が正しく引き継がれているかを確認する必要があります。 重要な観点を機能別に分断せず、取引の開始から後続処理、帳票、運用まで一本の流れとして検証します。 勘定系特有のテストでは、 正常系よりも異常系や境界条件で何が起こるか を明らかにすることが、重大障害の予防につながります。 取引の正確性は「正常終了」だけで判断しない！ 取引の正確性を確認する際は、処理結果が成功と表示されたことだけで判断してはいけません。 入金、出金、振込、振替、取消、訂正、組戻しなどを組み合わせ、残高や取引状態が正しく変化するかを確認します。 同じ取引について、画面、口座残高、取引明細、元帳、仕訳、帳票、外部送信データの結果が一致していることが重要です。 処理要求が重複した場合には、二重計上を防ぐ仕組みが機能するかを確かめます。 通信が途中で切れた場合や応答が返らない場合には、取引が完了、取消、保留のどの状態になるのかを明確にします。 状態が不明なまま再実行すると、重複処理につながる恐れがあるためです。 金額条件では、ゼロ、上限、下限、端数、最大桁数、桁あふれを確認します。 日付条件では、休日、月末、年度末、うるう年、利息計算日などを対象にします。 さらに、エラー発生後に正しい状態へ戻せるか、再処理後に元帳と残高が一致するかまで検証します。 取引の入口から会計上の結果まで追跡すること が、勘定系テストの基本です。 実際の業務をつなげたシナリオで隠れた不具合を見つける！ 業務シナリオテストでは、個別機能を一つずつ確認するのではなく、利用者や行員が実際に行う手続きを一連の流れで再現します。 たとえば、口座開設、入金、振込、利息計算、各種変更、口座解約までをつなげて確認します。 個々の機能が正常でも、処理の順番や組み合わせによって、残高や契約状態に不整合が生じる場合があるためです。 シナリオには、通常の流れだけでなく、取消、訂正、再処理、承認却下、権限不足、入力途中の中断なども含めます。 顧客、営業店、事務センター、運用担当者といった複数の立場から作成すると、部門をまたぐ問題を見つけやすくなります。 すべての業務を同じ深さで確認する必要はありません。 取引量が多い業務、高額な取引、障害時の影響が大きい業務、過去に問題が起きた業務を優先します。 期待結果は画面表示だけでなく、データベース、元帳、帳票、仕訳、後続処理まで定義します。 業務が最後まで正しく完了したか を合否の基準にすることが重要です。 周辺システムとの連携は「送れたか」より「業務が完了したか」を見る！ 勘定系システムは、現金自動預払機、インターネットバンキング、営業店端末、決済ネットワーク、情報系システムなど、多くの仕組みと連携します。 連携テストでは、データを送信できたことだけでなく、接続先で処理され、結果が勘定系へ正しく戻ったかまで確認します。 送信項目、受信項目、桁数、文字コード、日時、金額、取引番号などが一致していることも必要です。 通信遅延、時間切れ、重複送信、順序の逆転、接続先の停止など、異常な状況も再現します。 再送や再実行を行う場合は、同じ取引が二重に反映されないことを確認します。 勘定系では完了し、接続先では失敗した場合など、片側だけ処理が進んだ状態への対応も重要です。 不整合を自動的に検知できるか、照合によって発見できるか、運用担当者が解消できるかを確かめます。 障害からの復旧後には、保留データや未送信データを洗い出し、再処理後の結果まで検証します。 連携の成功ではなく、連携を含む業務全体の完了を確認すること が重要です。 ピーク取引・長時間稼働・障害復旧まで本番条件で確かめる！ 性能テストでは、通常時の応答速度だけでなく、給与日、月末、連休明けなど、取引が集中する条件を再現します。 オンライン取引と夜間処理が重なる時間帯でも、応答時間や処理時間を維持できるかを確認します。 取引量を増やした際に、どの時点から遅延が大きくなるかを把握しておくことも重要です。 長時間稼働テストでは、メモリーや接続資源が徐々に消費され、処理速度が低下しないかを確かめます。 ログや一時データが蓄積し、容量不足につながらないかも確認します。 障害テストでは、サーバー、ネットワーク、データベース、接続先などを意図的に停止させます。 待機環境への切り替え、処理の継続、データの整合性、復旧後の再開を検証します。 途中で停止した一括処理については、最初から再実行するのか、停止地点から再開するのかを明確にします。 RTO（目標復旧時間）や、業務として許容できる停止時間を事前に定め、結果を合否判定につなげます。 障害対応は手順書を読むだけでなく、 本番に近い体制で実際に動けるか を確認する必要があります。 データ移行は「件数一致」だけでなく残高と業務の継続性を保証する！ データ移行テストでは、移行元と移行先の件数が一致しただけで合格と判断してはいけません。 口座残高、取引履歴、契約情報、顧客属性、各データの関連性まで正しく引き継がれている必要があります。 コード体系の変更、桁数の変更、項目の統合や分割がある場合は、変換ルールを一つずつ検証します。 通常の口座だけでなく、休眠口座、未処理取引、特殊な契約、古い履歴、欠損値なども対象です。 旧システムと新システムで同じ取引を実行し、結果を比較する 現新比較 も有効です。 移行直後のデータが正しくても、オンライン取引、夜間処理、利息計算、帳票出力を実行した際に問題が発生する場合があります。 そのため、移行後に主要業務を動かし、業務継続性まで確認します。 移行リハーサルは、本番と同じデータ量、手順、体制、時間制約で複数回実施します。 作業時間やエラー件数を記録し、改善を繰り返すことが重要です。 予定時間内に完了しない場合や重大な不整合が見つかった場合に備え、 切り戻しを開始する条件と手順 も検証します。 実務で迷わない！テスト計画から品質判定までの進め方 勘定系システムのテストを安定して進めるには、ケースを作成する前に、リスク、体制、環境、データ、品質基準を整理する必要があります。 最初に重要業務と重大障害を洗い出し、影響の大きさと発生可能性から優先順位を決めます。 次に、テストの目的、対象範囲、役割分担、開始条件、終了条件を計画書へ落とし込みます。 テストケースは、操作手順だけでなく、期待結果と確認証跡まで具体化します。 実施中は、消化件数や不具合件数だけで品質を判断してはいけません。 重大不具合の残存状況、原因の偏り、未実施範囲、リスクの網羅状況を合わせて確認します。 繰り返し実行する作業は自動化し、人は業務の妥当性や例外時の判断へ集中することが効果的です。 最終的には、テスト結果、データ移行、性能、運用準備、残存リスクを一つにまとめ、本番移行の可否を判断します。 計画から本番判定まで同じリスク基準でつなぐこと が、説明できる品質保証につながります。 業務とリスクからテスト対象の優先順位を決める！ テストの優先順位は、機能一覧の上から順番に決めるのではなく、重要な業務と障害影響から考えます。 まず、顧客や金融機関に大きな影響を与える取引を洗い出します。 高額取引、大量取引、複雑な計算、外部システムとの連携、例外処理などは、優先度が高くなりやすい領域です。 次に、障害が発生する可能性と、発生した場合の影響度を組み合わせてリスクを評価します。 影響度には、顧客数、金額、業務停止時間、復旧の難しさ、社会的信用への影響などを含めます。 過去の障害、問い合わせ、仕様変更、設計レビューの指摘も重要な判断材料です。 変更箇所だけでなく、その変更が影響する周辺機能も確認します。 高リスク領域では、条件の組み合わせや異常系のケースを増やします。 低リスク領域では、代表的なケースへ絞ることで工数を調整します。 優先順位を下げた項目についても、対象外にした理由と残るリスクを記録します。 何をテストするかだけでなく、なぜその深さで確認するのか を説明できる状態にすることが重要です。 誰が見ても判断できるテスト計画を作る！ テスト計画書には、目的、対象範囲、対象外、工程、方法、スケジュールを明記します。 対象となる業務、システム、機能、接続先を具体的に記載し、部門ごとの認識差を防ぎます。 テスト環境、接続環境、テストデータ、マスターデータの準備条件も重要です。 勘定系の大規模テストでは、複数チームが同じ環境を利用するため、データの競合や利用時間の重複が起こりやすくなります。 環境を利用できる時間帯、データの初期化方法、障害発生時の復旧担当を事前に決めます。 業務部門、開発部門、基盤部門、運用部門、外部ベンダーの役割も明確にします。 さらに、開始条件、終了条件、中断条件、再開条件を数値や状態で定義します。 重大不具合が残っている場合や、必要な接続先が利用できない場合など、開始・継続できない条件も決めておきます。 障害の重要度、修正期限、再テスト、影響範囲の確認方法も統一します。 担当者の経験に依存せず、同じ基準で判断できる計画 を作ることが重要です。 テストケースを「操作・結果・証拠」まで具体化する！ テストケースは、前提条件、入力値、操作手順、期待結果を分けて記載します。 担当者が変わっても同じ条件で再現できる具体性が必要です。 期待結果を「正常に処理される」とだけ書くと、確認範囲が担当者ごとに変わります。 画面の表示内容、口座残高、元帳、仕訳、帳票、ログ、連携データなど、どこを確認するかまで指定します。 正常系だけでなく、異常系、境界値、権限、日付、状態遷移を組み合わせます。 一つのケースに多くの目的を詰め込みすぎると、失敗した際の原因を切り分けにくくなります。 ケースごとに、何を保証するためのテストなのかを明確にします。 要件、業務、リスクとテストケースを対応付ければ、確認漏れを発見しやすくなります。 レビューでは、ケース数の多さよりも、重大リスクを十分に検証できているかを確認します。 実施結果には、画面画像、帳票、ログ、検索結果などの証跡を残します。 操作、期待結果、確認証跡を一組として設計すること が、再現性と説明力の向上につながります。 不具合件数ではなく品質の中身を分析する！ テストの品質は、不具合の総数だけでは判断できません。 重要なのは、重大度、発生した機能、原因、検出工程、再発状況など、不具合の中身です。 重大な不具合が残っていれば、全体の合格率が高くても本番稼働のリスクは高い状態です。 反対に、不具合が極端に少ない場合も、品質が高いとは限りません。 テスト条件が不足している、期待結果が曖昧で問題を検出できていないといった可能性があります。 不具合を原因別に分類すると、設計不足、認識違い、影響調査不足などの偏りが見えます。 同じ原因が複数の機能に存在する場合は、修正対象だけでなく横断的な確認が必要です。 テスト消化率、合格率、重大不具合数、未実施ケース、未解決課題を合わせて確認します。 さらに、重要な要件や高リスク領域を十分にカバーできているかを評価します。 品質会議では、数値を報告するだけでなく、 本番に残るリスクと対応策 を明らかにすることが重要です。 繰り返し作業を自動化し、人は重要な判断に集中する！ 勘定系システムのテストでは、同じ操作や結果確認を何度も繰り返す場面があります。 回帰テスト、画面への定型入力、データ比較、帳票比較などは、自動化を検討しやすい作業です。 ただし、工数を減らせそうという理由だけで自動化すると、保守負担が大きくなる場合があります。 実行頻度が高いケース、操作量が多いケース、期待結果を機械的に判定できるケースから優先します。 画面構成や仕様が頻繁に変わる機能は、自動テストの修正回数が増えやすいため注意が必要です。 自動化の目的には、実行時間の短縮だけでなく、条件の統一、確認ミスの削減、証跡の標準化も含まれます。 一方で、業務として自然か、利用者が迷わないか、想定外の問題がないかといった判断は、人による確認が適しています。 異常時の振る舞いや複雑な業務シナリオも、手動テストを組み合わせる必要があります。 自動化によって生まれた時間は、重要シナリオの追加、不具合原因の分析、高リスク領域の確認へ振り向けます。 自動化と手動確認の役割を分けること が、品質と効率の両立につながります。 本番移行の可否を「根拠のある条件」で判断する！ 本番移行の判断では、テストケースをすべて実施したかだけでなく、残っているリスクを総合的に評価します。 重大不具合の件数、未実施ケース、性能目標の達成状況、データ移行の結果、運用準備の状況を確認します。 すべての不具合をゼロにできない場合は、残存不具合の影響、発生条件、回避策、対応期限を明確にします。 業務部門、システム部門、運用部門が、同じ判断基準を共有することも重要です。 本番移行中に問題が起きた場合に備え、切り戻しを開始する条件を定めます。 判断者、判断期限、連絡経路、切り戻し後の業務対応まで具体化します。 移行後は、残高、取引件数、エラー、処理時間、連携状況など、重点的に監視する項目を決めます。 異常を検知した際の初動担当や、営業店、顧客への案内方法も準備します。 本番移行の可否は、担当者の感覚や不具合件数だけで決めるものではありません。 テスト結果、移行結果、運用体制、残存リスクをまとめた客観的な根拠 によって判断する必要があります。 まとめ 勘定系システムのテストでは、機能が設計どおり動くことに加え、取引の正確性と業務の継続性を保証する必要があります。 機能・勘定処理、業務シナリオ、システム連携、性能、障害・運用、データ移行、セキュリティを横断して確認することが重要です。 限られた期間と人員で、すべての条件を同じ深さで検証することは現実的ではありません。 顧客や業務への影響、取引量、金額、発生可能性、復旧の難しさを基準に、重大なリスクから優先します。 テスト計画では、対象範囲、役割分担、環境、データ、開始条件、終了条件を明確にします。 テストケースは、操作手順だけでなく、期待結果と証跡まで具体化することが大切です。 品質評価では、不具合件数や消化率だけでなく、重大な問題の残存状況やリスクの網羅性を確認します。 本番移行では、テスト結果、性能、データ移行、運用準備、残存リスクを共通の基準で判断します。 まずは、プロジェクトで 絶対に起こしてはいけない障害 を洗い出すことが出発点です。 現在のテスト観点と照らし合わせ、不足する確認を優先順位付きで追加することで、根拠を持って本番稼働へ進めるようになります。 QA業務効率化ならPractiTest テスト管理の効率化 についてお悩みではありませんか？そんなときはテスト資産の一元管理をすることで 工数を20%削減できる 総合テスト管理ツール「 PractiTest 」がおすすめです！ PractiTest (プラクティテスト) に関する お問い合わせ トライアルアカウントお申し込みや、製品デモの依頼、 機能についての問い合わせなどお気軽にお問い合わせください。 お問い合わせ

はじめに 2026 年 6 月 25 日(木)、26 日(金)の 2 日間にわたって幕張メッセで開催された AWS Summit Japan 2026 では、AWS Expo の Industry Zone に「AWS for Telecom」として通信業界に関する展示ブースを出展しました。 本ブログでは、株式会社NTTドコモ、KDDI株式会社、ソフトバンク株式会社の各社と共に展示した全 7 ブースの内容をご紹介します。通信領域では NW 設計・構築から運用保守まで、非通信領域ではスマートシティやコンタクトセンターの領域で Agentic AI が通信業界をどう変えつつあるのか を、各社の最新の取り組みからご覧いただけます。 展示一覧 カテゴリ ブース ID 出展社 テーマ 通信領域 A063 株式会社NTTドコモ Agentic AI で AWS 上に 5G コア構築・運用開始 A064 KDDI株式会社 AI 駆動開発で加速する RAN 自動制御と品質改善 A067 株式会社NTTドコモ ネットワーク保守 AI エージェント A068 ソフトバンク株式会社 Amazon Neptune で実現する NW トポロジー可視化 A069 AWS エージェンティック AI が実現する自律運用 非通信領域 A065 KDDI株式会社 KDDI が創る、未来のスマートシティ A066 AWS AI で変革する通信業界の顧客体験 A063：Agentic AI で AWS 上に 5G コア構築・運用開始（株式会社NTTドコモ） ＊ 資料ダウンロード NTTドコモは AWS 上に 5G コアを構築し、国内初となるハイブリッドクラウド環境での商用サービスを開始しました。 この AWS 上の 5G コア構築は、 世界初となる Agentic AI と GitOps を組み合わせた設計・構築自動化 によって実現されています。膨大な過去コンフィグやドキュメントの確認、相互依存する複数コンフィグ間の整合性担保、手動作業によるデプロイ完了までの長期間化の課題がありましたが、AI エージェントが自律的にドキュメントを参照しながら設定ファイルを自動生成し、Git を介した CI/CD パイプラインで自動デプロイする仕組みへと変革することで、従来から 80% のリードタイム短縮と自動化による品質向上をを実現しました。 本展示では、この取り組みの概要や効果、技術要素をご紹介しました。 ポイント： 国内初：AWS 上での 5G コア商用構築・運用開始 世界初：AI × GitOps による 5G コアの設計・構築自動化 Amazon Bedrock AgentCore 上のオーケストレータエージェントが複数の専門 AI エージェントを統括 A064：AI 駆動開発で加速する RAN 自動制御と品質改善（KDDI株式会社） ＊資料ダウンロード 説明 | デモ画面抜粋 KDDI は、無線ネットワーク（RAN）の自動制御に向けて、O-RAN 標準インタフェースに準拠した基地局制御の共通基盤（SMO: Service Management and Orchestration）と、その上で動作するネットワーク制御アプリ（rApp）を AWS 上で内製開発しています。その開発において、 AWS が提唱する AI-DLC（AI-Driven Development Life Cycle）を導入 しました。 AWS が公開している AI-DLC ワークフロー（ aidlc-workflows ）をそのまま使うのではなく、社内のガイドラインやセキュリティ要件に合わせてカスタマイズしています。具体的には、開発スコープ・技術制約・質問事項を整理して議論のたたき台を作る事前フェーズの追加や、社内ルール対応のための Claude Code スキル化などを実施しました。 AI-DLC を取り入れた結果、要件定義からデプロイまでの開発期間を 70％ 削減しました。 この取り組みで開発した新 rApp により、 基地局パラメータの全国展開期間を約 50% 短縮 しています。 この展示内容については、 KDDI Tech note でも紹介されています。 ポイント： AI-DLC は導入して終わりではなく、社内要件に合わせて継続的にカスタマイズ コード生成だけでなく設計・レビュー・ドキュメントまで、開発ライフサイクル全体への AI 適用 要件定義からデプロイまでの開発期間を 70% 削減、パラメータ全国展開期間も約 50% 短縮 A067：ネットワーク保守 AI エージェント（株式会社NTTドコモ） ＊ 資料ダウンロード NTTドコモは、RAN からコアネットワークまで 世界最大級の 100 万台超の通信機器データを分析し、 ネットワークの保守運用を効率化する AI エージェントの商用利用を開始 しました。 本展示では、AI が自律的に異常を検知し、複雑な障害の原因特定から復旧手順の提案を行うまでの一連の動作をご紹介しました。本技術により 障害復旧時間を 50% 以上短縮 し、通信インフラの安定稼働および早期の異常復旧に貢献することで、お客様の通信をつなぎ続けます。 ポイント： 100 万台超の通信機器データをリアルタイム分析 異常検知 → 原因特定 → 復旧手順提案まで自律的に実行 障害復旧時間 50% 以上短縮を商用環境で実現 A068：Amazon Neptune で実現する NW トポロジー可視化（ソフトバンク株式会社） ＊資料配布はございません ソフトバンクは、ネットワークにおける障害検知から復旧までのプロセスを運用者の手を介さず自動で完結させるクローズドループの取り組みを紹介しました。また、この取組みのさらなる拡張のため、 Amazon Neptune を用いたトポロジーの時系列化 のアプローチを紹介しました。 即時性の高いトポロジー把握はネットワーク運用に有用ですが、ネットワークは計画作業に伴う変動に加え、障害起因の突発的な変動も発生します。そのため、設計情報や config 等の静的データに加え、実際のネットワークの状態変化を示す動的データを継続的に収集し、トポロジー情報へ反映することも重要です。トポロジーの時系列情報を扱うことができれば、障害調査の際にリアルタイムの状態だけでなく障害前後のトポロジー情報を原因の特定や迂回可否判断に活用できます。 ポイント： 静的データ＋ 動的データを取り込み Digital Twin と実ネットワークとの同期精度を向上 Amazon Neptune によるグラフデータベースでトポロジーを時系列管理 クローズドループをさらに拡張し、状態追従性、判断根拠の鮮度、判断の迅速性を向上 A069：通信ネットワーク運用の未来 — エージェンティック AI が実現する自律運用（AWS） ＊ 資料ダウンロード エージェンティック AI が通信事業者のネットワーク運用を自律的に監視・分析・実行し、 リアクティブからプロアクティブへ 変革するオペレーションセンターのデモを展示しました。すべて Amazon Bedrock AgentCore 上のマルチエージェントで実現し、専門エージェントが協調して RAN〜Transport〜Core の E2E 運用を担います。デモ全体のコンセプトは、 AI が分析・事項を行い、人間は戦略的な意思決定に集中 することです。 本展示では、来場者の関心に応じて4つのデモをご覧いただきました。 ① データ統合基盤の構築 ：4つのソースに分散したデータを AWS Glue で正規化・時刻同期・トポロジー相関付けし、Amazon DynamoDB・Amazon Timestream・Amazon Neptune・Amazon Bedrock Knowledge Bases に格納。エージェントが自律判断できる土台を整えます。 ② 障害の自動検知・復旧 ：バックホール回線の物理故障をアラームスパイクから検知し、グラフ解析で真因と巻き添えを切り分け。バックアップルート起動から故障機器の交換手配まで、人手の判断を待たずに数分で完結します。 ③ 予測に基づく最適化 ：Amazon SageMaker が大規模イベント時の需要急増を事前に予測し、サービス・インフラ・トランスポートの3層にまたがる最適化戦略を自動立案。人間の承認後にエージェントが並列実行します。 ④ 顧客別のプロアクティブ対応 ：障害の影響を SLA やビジネスインパクトで把握し、影響の大きいお客様を優先。代替経路への自動切替と、状況に応じたパーソナライズ通知の自動生成までを実行します。 いずれも最終判断は人間が行う Human in the Loop を前提とし、受動的な運用から AI 主導のプロアクティブな運用への変革をご体感いただきました。 ポイント： Amazon Bedrock AgentCore 上のマルチエージェントが、データ統合基盤から障害復旧・予測最適化・顧客対応までを自律実行 障害検知から復旧までを数分で完結し、需要急増は事前に予測して予防（リアクティブからプロアクティブへ） 重要な実行判断は人間が担う Human in the Loop——「AI が分析・実行、人間は戦略に集中」 A065：KDDI が創る、未来のスマートシティ（KDDI株式会社） ＊資料配布はございません KDDI は「つなぐチカラ」で、都市の価値を最大化するスマートシティを推進しています。「100年先の心豊かなくらしのための実験場」を掲げる TAKANAWA GATEWAY CITY では、JR東日本と共創し、都市OS「TAKANAWA GATEWAY URBAN OS」を核としたサービスを展開しています。 本展示では、この都市OS 上で動く 2 つのサービスをご紹介しました。 来街者向け：TAKANAWA GATEWAY CITY アプリ 都市OS のリアルタイムデータを活用し、街で働くワーカーや来街者に、街の中での“快適さ”を提供するアプリです。駅改札やオフィス入館ゲートとの連動で来街タイミングを捉えたレコメンドを実現し、Amazon Bedrock でコンテンツ訴求文章を自動生成しています。 事業者向け：「データダッシュボード」で街の状況を可視化するサービス 街の有事（防災・警備）と平時（マーケティング・イベント計画）を同一機能で可視化・分析するダッシュボードです。3D 人流シミュレーションやリアルタイム可視化に加え、Amazon Bedrock による AI 分析でイベントの成果や改善策を把握できます。 ポイント： JR東日本との共創による都市型デジタルツイン URBAN OS を核としたリアルタイムデータ連携 来街者と事業者それぞれに最適化された体験の提供 A066：AI で変革する通信業界の顧客体験 — Amazon Connect で実現する自律的な顧客支援（AWS） ＊ 資料ダウンロード 通信業界の顧客サポートを、AI エージェントで リアクティブからプロアクティブへ 、そしてコ ストセンターと捉えられがちなコンタクトセンターを収益に貢献するバリューセンターへ変革 するソリューションを、コンタクトセンターとデバイスの両面から実現する 2 部構成のデモでご紹介しました。 前半：コンタクトセンターの自律型顧客応対エージェント（日本語デモ） Amazon Connect 上の AI エージェントが、携帯電話料金の問い合わせを 日本語 で自律対応する様子をご覧いただきました。意図認識から本人確認、請求明細の取得、最適なプランの提案、プラン変更の実行まで、 Amazon Bedrock AgentCore Gateway（MCP） で業務システムと連携し、回答だけでなく手続きまでを一気通貫で完結します。人手が必要な場面では会話の文脈を引き継いで有人対応へシームレスにつなぎ、AI が担当者を支援します。 後半：Agentic AI で実現するコネクテッドデバイスケア デバイスを起点に、問題が起きる前に対応する体験もご覧いただきました。お客様の許可のもと、デバイス上の SDK が多数の診断テストでバッテリー劣化などの予兆を検知し、デバイス上で動く Agentic AI の音声エージェント（ Amazon Nova Sonic ）がプロアクティブに連絡してその場で解決します。解決しない場合も文脈を引き継いだまま有人対応へつなぐため、お客様が同じ説明を繰り返す必要はありません。海外の通信事業者での導入実績をもとにした発展形で、課題解決を起点に最適な料金プランや端末下取りといった次の提案（＝「ケアをコマースへ」）にもつなげられます。 ポイント： 前半：Amazon Connect の AI エージェントが日本語で自律対応し、Amazon Bedrock AgentCore Gateway（MCP）連携で手続きの実行まで完結（必要時は文脈を保ったまま有人へ） 後半：予測 AI と Amazon Nova Sonic による、デバイス起点のプロアクティブなケア リアクティブからプロアクティブへ、コンタクトセンターを収益に貢献するバリューセンターへ（＝「ケアをコマースへ」） まとめ 今回の AWS Summit Japan 2026 AWS Expo「AWS for Telecom」展示では、通信業界における Agentic AI の活用が、ネットワークの設計・構築から運用保守、顧客体験、さらにはスマートシティまで、幅広い領域で商用レベルで活用されていることをお伝えしました。 AWS は今後も通信業界の皆さまと共に、ネットワークの自律化と新たなサービス創出に向けた取り組みを加速してまいります。 著者 神谷 拳四郎 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 通信・メディア技術本部 通信第二ソリューション部 ソリューションアーキテクト 川岸 基成 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 通信・メディア技術本部 通信第一ソリューション部 ソリューションアーキテクト 小林 新一 アマゾン ウェブ サービス ジャパン合同会社 技術統括本部 通信・メディア技術本部 通信第一ソリューション部 ソリューションアーキテクト