急成長を遂げる事業において、海外展開は避けて通れない大きな一歩です。 しかし、複数のプロダクトやマイクロサービスが並走するメガベンチャーの現場では、各チームでテスト方針や品質基準がバラバラになり、思わぬ手戻りやブランド毀損のリスクに直面することも少なくありません。 特に「ローカライゼーション」は、単に言葉を置き換えるだけの作業と誤解されがちですが、その実態は「特定の市場でプロダクトが自然に受け入れられる状態」を保証するための極めて戦略的なプロセスです。 そこで今回はQAマネージャーや品質推進リードが、部分

XI本部 クラウド イノベーション センター所属、2年目の米田です。 今回は、 AWS サービス上でのコンテナイメージの運用と、それをより効率的に実現するFutureVulsについて、基礎的な部分を中心に共有させていただきます。 本ブログは、 10月下旬にあった社内向けの勉強会 にて発表させていただいた内容を含んだものになっており、少し振り返りながら改めてまとめさせていただきました。 勉強会当日は100名以上の参加者となり、そのような場での発表は私自身とても良い経験でした。勉強会にご参加いただいた方、コメ

はじめに ども！龍ちゃんです。技術調査にAIを活用していますか？ 「○○について調べて」とClaude Codeに頼むと、WebSearchでサッと検索して「こういう感じです」と返ってくる。便利なんですが、こんな経験ありませんか？ クオリティがまばら : 日によって深さが違う。「今日は浅いな…」 出典が不明 : 「この情報、どこから持ってきたの？」 フォーマットがバラバラ : 後から整理しようにも形式が統一されていない 保存先もバラバラ : どこに保存されたか分からない、または保存されない この問題を解決

急成長を続けるメガベンチャーの開発現場において、マイクロサービス化によるシステムの複雑肥大化は、従来の品質保証を困難にしています。 ステージング環境で本番を完璧に再現することには限界があり、リリース直前の全件テストが事業のスピードを阻害するボトルネックとなっているケースも珍しくありません。 こうした状況下で、QAマネージャーや品質推進リードが「部分最適」な改善から脱却し、組織全体のスピードと品質を両立させるための鍵となるのが、フィーチャーフラグを活用したテスト戦略です。 フィーチャーフラグは単なる条件分岐

本ブログは 2025 年 11 月 13 日に公開された AWS Blog “ Amazon Inspector detects over 150,000 malicious packages linked to token farming campaign ” を翻訳したものです。 Amazon Inspector のセキュリティリサーチャーは、 npm レジストリにおいて、 tea.xyz トークンファーミングキャンペーンに関連する 15 万件以上のパッケージを特定し、報告しました。これはオープンソー

QA担当としての業務が、単なるテスト実行の繰り返しに留まっていないでしょうか。 急成長する組織や複雑化するプロダクト開発の現場において、QAの役割は「不具合を見つける」ことから「品質を設計・保証する仕組みを作る」ことへと大きく変化しています。 特にメガベンチャーのような規模では、各チームの部分最適から組織全体の全体最適へと視座を引き上げることが、キャリアアップの決定的な鍵となります。 現場と経営層の板挟みに悩みつつも、属人化を排除し、持続可能な品質体制を築くことは、QAマネージャーとしての真の手腕を証明す

本ブログは 2025 年 10 月 2 日に公開された AWS Blog “ Defending against supply chain attacks like Chalk/Debug and the Shai-Hulud worm ” を翻訳したものです。 オープンソースパッケージを利用することで、開発を加速できます。npm、PyPI、Maven Central、NuGet などで提供されている一般的なライブラリやモジュールを使用することで、チームは自社固有のコード作成に集中できます。これらのオープ

本ブログは 株式会社アド・ダイセン 様とアマゾン ウェブ サービス ジャパン合同会社が共同で執筆いたしました。 みなさん、こんにちは。ソリューションアーキテクト 瀬高 拓也です。 株式会社アド・ダイセンの理念は「”顧客”から”個客”へ」。付加価値を追求し、One to One コミュニケーションを具現化することを掲げています。目標を共有する二人三脚の戦略パートナーとして、顧客一人ひとりの「おもてなし」にフォーカスした”個客”戦略を打ち出しています。 このような理念を実現するためには、お客様ごとにカスタマイ

急成長を遂げるメガベンチャーにおいて、マイクロサービスアーキテクチャの採用は事業スピードを加速させる強力な武器となります。 しかし、品質保証の観点に立つと、その複雑性はモノリスなシステムとは比較になりません。 サービスが細分化されるほど、チーム間でのテスト方針のズレや、予期せぬ場所での副作用、そして重すぎる統合テストといった課題が顕在化します。 現場の個別改善だけでは限界が見え始めている今、QAマネージャーに求められるのは、各チームを俯瞰し、リソースをどこに集中させるべきかを示す「テストの地図」を描くこと

リリース直前のテストや本番環境で、「まさかこんな操作をするなんて」「そこまで想定していなかった」という不具合に遭遇し、肝を冷やした経験はないでしょうか。 QAエンジニアとして真面目に仕様書と向き合っている人ほど、記載された「正しい挙動」を完璧に確認することに集中してしまい、異常な入力や予期せぬ操作に対する備え、すなわちネガティブテストが手薄になってしまうことがあります。 「テスト観点が浅い」という指摘を恐れる必要はありません。ネガティブテストが漏れてしまうのには明確な理由があり、それをカバーするための「思

システムのリリース直前、あるいは運用が始まってから「想定外の入力でエラーになった」「ネットワークが切れた瞬間にデータが消えた」といった不具合に直面し、焦った経験はないでしょうか。 仕様書に書かれた通りに動くことを確認するだけでは、現実の多様なユーザー操作や不安定な実行環境からシステムを守り切ることはできません。 品質の高いプロダクトを作るためには、正常な挙動を保証する「ポジティブテスト」と、異常な事態への耐性を確認する「ネガティブテスト」の両輪が必要です。 しかし、これら二つのテストの境界線や、よく似た言

大規模なプロダクト開発において、QA（品質保証）の役割は「不具合を見つけること」以上に「リリース可否の判断軸を示すこと」へとシフトしています。 特に週次や日次でのリリースが繰り返されるメガベンチャーの現場では、QAの一言が開発スピードを左右すると言っても過言ではありません。 しかし現場では「念のため確認してください」「一通り見ておきましょう」といった曖昧な言葉が飛び交い、結果として過剰なテストや重複確認を招いているケースが多く見受けられます。 QAが良かれと思って発する言葉が、実はチームの足を引っ張り、ス

近年、クラウドサービスの選択肢はますます多様化しており、さまざまなクラウドが活用されています。 世界のクラウドプロバイダーのシェア上位3社を見ると、AWSが29%、Microsoft Azureが20%、Google Cloudが13%となっており※、 Microsoft AzureやGoogle Cloud Platformも成長を続けていますが、依然としてAWSがトップの座を維持しています。 (※2025年第3四半期データ　 Cloud Market Growth Rate Rises Again i

はじめに 2025年11月にMicrosoft が最新の技術戦略や製品情報を発表する年次テックカンファレンス “Microsoft Ignite 2025” に参加しました。 今回はアメリカ・サンフランシスコの Moscone Center と Chase Center を会場に開催され、周辺は技術イベントとは思えないほど多くの来場者で賑わい、活気に満ちていました。 本イベントでは多岐にわたるアップデートが発表され、全容について日本語でも様々な方がレポートをまとめています。ここでは一例として、当社の寺井の

こんにちは、サイオステクノロジーの遠藤です。 前回のブログ「 A2A（Agent2Agent）プロトコル入門｜MCPとの違いと活用メリット 」では、A2Aプロトコルの概要を解説しました。 今回は、 実際にA2Aプロトコルを使ってマルチエージェントアプリを作ってみた ので、その実装を紹介します。 5秒でわかる：この記事の内容 項目 内容 やったこと A2Aプロトコルで「ライター×校閲者」マルチエージェントアプリを構築 得られるもの A2Aエージェントの実装パターン、Python SDKの使い方 対象読者 A