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

暗号資産取引所におけるテスト案件について、「一般的なウェブサービスのテストと何が違うのか」「金融や暗号資産の知識がなくても対応できるのか」と不安を感じるケースは少なくありません。 暗号資産取引所では、画面や機能が仕様どおり動くだけでなく、 顧客の資産や取引データが正確かつ安全に処理されること が非常に重要です。 国内の暗号資産交換業者には登録制度が設けられており、利用者保護の観点からシステム管理や分別管理などが求められています。 さらに近年は、署名鍵の管理だけではなく、外部委託先を経由した攻撃なども踏まえ

決済や送金などを扱うFinTechシステムでは、「一般的なWebシステムと同じテストをすれば十分なのか」と判断に迷う場面があります。 画面や機能が仕様どおり動くことはもちろん重要ですが、金融サービスでは、わずかな処理ミスでも残高不整合や二重決済といった大きな問題につながる可能性があります。 そのため、 取引・データの正確性、API（アプリケーション・プログラミング・インターフェース）による外部連携、性能、セキュリティ、障害時の復旧 まで含めて考えることが欠かせません。 また、テスト項目を大量に増やせば安心

チューリングの MLOps エンジニアの岩政です。 チューリングでは、センサ入力から車両の将来の行動を一貫して推定する学習ベースのモデルとして End-to-End (E2E) 自動運転 AI を開発しています。E2E 自動運転 AI の学習にはデータセットが必要です。私の所属する MLOps チームが、これを作成するためのデータ基盤の開発を行っています。 MLOps チームでは車両に搭載したカメラなどのセンサから走行データを収集し、Data Lake に格納しています。更に ETL (Extract,

航空業界では、散在するデータの横断的な活用が長年の課題でした。本ブログでは、 Amazon S3 を中心としたデータレイクに航空データを集約し、Amazon Bedrock AgentCore と Amazon Bedrock Knowledge Bases で横断的に AI 検索できる 航空オペレーション基盤 を紹介します。この基盤の上に業務アプリケーションを載せて具体的な課題を解決する例として、 ターンアラウンド管理 （フライトの地上折り返し作業の可視化・管理ツール）を紹介します。 また、本ソリューシ

本記事は 2026年7月6日に公開された「 Turn Your Amazon CloudWatch Alarms into Actionable Signals 」を翻訳したものです。 午前2時にアラームが鳴ります。スマートフォンを手に取り、目を細めて通知を見ると、こう書いてあります： 「ALARM: my-service-alarm が ALARM 状態に遷移しました。」 コンテキストなし。アプリケーション名なし。200台のインスタンスのうちどれが問題なのか、そもそもそれが重要なのかすら分かりません。

融資システムのテストを担当すると、「一般的なシステムテストと同じ考え方でよいのか」「どの機能まで細かく確認すればよいのか」と迷いやすいものです。 特に融資業務は、申込情報を登録して終わるものではなく、 審査・承認・契約・融資実行・返済まで複数の処理が連続してつながっています 。 個人融資を扱うシステムでも、商品や申込内容に応じたワークフロー、自動審査、信用情報機関への照会、勘定系システムとの連携など、多くの機能が組み合わされています。 そのため、個々の画面が正常に動くことだけを確認しても、融資システム全体

クレジットカードシステムのテストを担当すると、「正常に決済できることは確認したものの、ほかに何をテストすればよいのかわからない」と悩むケースは少なくありません。 クレジットカード決済は金銭を扱うため、一般的な入力フォーム以上に、 テスト漏れが売上や顧客対応へ大きな影響を与えやすい機能 です。 正常なカードで購入できるかだけではなく、カード利用拒否、本人認証の失敗、通信エラー、取消、返金、二重決済といった状況まで想定する必要があります。 さらに、画面上では決済に成功していても、注文データや管理画面のステータ

AIを活用すれば、テストケースやテストスクリプトの作成、テスト結果の分析など、これまで人が時間をかけていた業務を効率化できます。 一方で、「AIが作成したテストケースをそのまま採用してよいのか」「重要な確認項目が抜けていないか」と不安を感じる場面も少なくありません。 生成AIは、自然で説得力のある内容を出力できても、実際の仕様とは異なる情報を生成することがあります。 さらに、ソースコードやログ、顧客情報などを入力することで、情報管理上のリスクが生じる可能性もあります。 そのため、AIによるテスト管理で大切

保険システムのテストでは、申込画面が正しく動くかを確認するだけでは十分ではありません。 保険料計算、引受査定、契約成立、収納、契約内容の変更、解約、失効、復活、保険金支払、帳票作成、会計処理、外部システム連携など、確認すべき領域が広範囲に及びます。 さらに、年齢、契約日、保険期間、払込方法、保険金額、特約といった条件の組み合わせによって、期待される結果が変わります。 すべての組み合わせをテストしようとするとケース数が膨大になり、納期や要員の制約から実行できなくなることも少なくありません。 だからこそ、保険

証券システムのテストを任されたものの、一般的な業務システムとの違いが分からず、どこまで確認すればよいのか迷うケースは少なくありません。 証券取引では、注文受付、発注、約定、残高更新、顧客への通知といった複数の処理が連動します。 そのため、画面が仕様どおりに動くことだけを確認しても、取引全体の品質を十分に保証できません。 注文データが正しく市場へ送信されているか、約定結果が口座残高へ反映されているか、通信障害の発生時にも二重注文を防げるかなど、確認すべき範囲は多岐にわたります。 さらに、相場急変時のアクセス

「Figmaデザインエージェント（ベータ版）」が登場 5月20日に、Figmaにて「デザインエージェント」機能がベータ版として登場しました。 今回は、この機能を少し利用した内容を、使用感レポートとして、キャプチャー画像中心にお伝えします。 公式の案内はこちらをご覧ください。 公式ブログ： Figmaデザインエージェントが登場 | Figma Blog 利用方法は簡単で、既存のFigmaデザインのナビゲーションに追加された「エージェント」や、各フレームなどに表示されるエージェントアイコン（✦）から自然言語で

勘定系システムは、預金、振込、融資、利息計算、残高管理など、金融機関の中核業務を支える仕組みです。 そのため、小さな不具合であっても、顧客の資産や金融機関の業務、社会的な信用にまで影響が広がる可能性があります。 画面が設計どおり動くことだけを確認しても、十分な品質を保証できるとは限りません。 業務の流れ、周辺システムとの連携、夜間処理、データ移行、性能、障害からの復旧まで、複数の観点をつなげて確認する必要があります。 一方で、すべての機能や条件を同じ深さで確認しようとすると、膨大な工数がかかります。 大切

はじめに CIU（CyberAgent group Infrastructure Unit）で Ia ...

はじめに はじめまして。CyberAgent group Infrastructure Unit（C ...