本物のサインイン画面でコードを入力したのに、第三者にアカウントを使われることがある。その理由と、組織での利用実態を確かめる方法を紹介します。 こんにちは、かみしろです。

企業利用では社員の注意力に頼らないことが重要 個人情報を入力しないよう社員に呼びかけることは大切です。ただ、毎回すべての情報を確認してからAIに渡すことを、会社全体の運用の前提にするのは難しいと考えています。

はじめに こんにちは。検索基盤ブロックのXEIです。私たちのチームには、ZOZOTOWNの検索に関する問い合わせが社内から日々寄せられます。 本記事では、この問い合わせ対応を複数のAIエージェントの組み合わせでどう効率化したかを紹介します。読み終わる頃には、役割を分けたAIエージェントをどう組み合わせ、人間の関与をどこに残すと問い合わせの件数を維持したまま対応の負荷を下げられるのか、その設計の勘所を持ち帰っていただけるはずです。なお、本記事は「問い合わせに回答する」部分に絞り、管理・運用の自動化は扱いませ

サイオステクノロジーは、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台のインスタンスのうちどれが問題なのか、そもそもそれが重要なのかすら分かりません。