サイオステクノロジーは、OSS管理ツール「SCANOSS」の 日本国内初の代理店 です。 生成AIでコードを書く比重が上がるにつれ、「動くコードは手に入ったが、それを使っていいか」を確かめる工程が抜け落ちるようになりました。テストは通る。脆弱性スキャンを回していれば、それも通る。しかし、そのコードがどこ由来なのかを見る工程は、どちらにも入っていません。 AIが生成したコードに含まれるOSSは、読んで見分けることができません 。機械的な照合で見える範囲と、機械にも見えない範囲が残ります。 この記事でわかるこ

はじめに こんにちは。商品基盤部の藤本です。 私たちのチームでは、生成AIコーディングエージェント（以下、AIエージェント。主にClaude Code）を使って開発に取り組んでいます。以前からAIエージェントに一貫した実装をしてもらうため、ルールを書いて指示する運用を続けてきました。しかし、ルール同士の矛盾やレビューだけでは遵守を保証できないといった課題がありました。本記事ではこの課題と、ArchUnitによる機械的な検証へ落とし込むまでの取り組みを紹介します。 目次 はじめに 目次 背景・課題 ルールの

「だいたい○○ケースくらいですかね」の正体 テスト計画でスケジュールを立てるとき、テストケース数の見積もりはどうやっているだろうか。 正直なところ、多くの現場では「前回と同じくらいの規模感だから○○ケースくらい」「経験的にこの手の機能なら△△ケース」という見積もりが主流だと思う。自分もそうだった。 これで困るのは3つの場面。 初めての領域。 過去実績がないから「だいたい」が通用しない 説明責任。 上席に「なぜその工数なのか」と聞かれたとき、根拠を示せない 精度のばらつき。 見積もる人によって2〜3倍の差が

「テスト＝QA」を卒業したい。でも何から？ 以前の記事で、テストとQAは違うという話を書きました。 テストは「測る」行為です。QAは「良いものが生まれる仕組みをつくる」行為です。勉強にたとえるなら、テストは問題を解くことであり、QAは勉強法そのものを改善することです。 反応をもらった中で一番多かったのが、「わかった。で、具体的に何をすればいい？」 でした。正直、自分も最初はそうでした。 品質戦略の担当になったとき、「分析しよう」と意気込んでパレート分析やODCの教科書を開きました。でもデータが整っていませ

介護ソフトのテストを任されたものの、「一般的な業務システムと同じ観点で確認してよいのだろうか」と迷うケースは少なくありません。 介護ソフトには利用者情報の管理だけでなく、アセスメント、ケアプラン、介護記録、サービス実績、各種帳票、介護報酬請求など、介護現場のさまざまな業務が集約されています。 そのため、個々の画面が仕様通りに動いていることだけを確認しても、十分なテストとはいえません。 たとえば、介護記録への入力自体は正常でも、その情報がサービス実績や帳票、請求処理へ正しく反映されなければ、現場では重大な問

はじめに こんにちは。グループIT推進本部の Roki です。 Claude CodeやOpenAI ...

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

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

決済や送金などを扱う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によるテスト管理で大切