本記事は 2025 年 12 月 10 日に公開された How smart Europe Revolutionized Automotive Customer Support with Amazon Bedrock を翻訳したものです。 自動車メーカーにとって、新型車のリリース、無線通信 (OTA) によるソフトウェアアップデート、コネクテッドサービスの開始は、新鮮な顧客体験を生み出します。これらのイノベーションは運転体験の向上に役立つ一方で、自動車所有者から車両の機能、充電機能、メンテナンス手順、デジタ

はじめに こんにちは、基盤グループでインフラの運用管理を担当している布川です。 今年の10月28日にAWS目黒オフィスにて、堅牢で回復力に優れたシステムの構築について学ぶAWS Architectural Resilience Dayが開催されました。 本イベントには弊社から基盤グループのメンバー3名が参加しました。本記事では、その内容や得られた学びをレポートとしてご紹介します。 はじめに 高いレジリエンスの実現に向けた6つのステップ 1. システムの中でビジネスクリティカルな部分を明確にする 2. 個々

1. 始めに こんにちは。LIFULLでエンジニアをしている稲垣です。 2025年10月の3日間、AWSが提供する「AI駆動開発ライフサイクル（AI-DLC）Unicorn Gym」の研修に参加しました。この研修では、6つのチームに分かれて、AI-DLCを活用しながら実際のプロジェクト課題に取り組みました。 私たちのチームが取り組んだのは、「サポートが終了したサービスの新基盤への移行計画」です。具体的には、Amazon Linux 2のサポート終了（EOL: End of Life）への対応として、既存シ

概要 こんにちは、RevCommでインフラを担当している齊藤です。 ECS Fargate を踏み台にする構成自体は、すでに多くの知見があります。 本記事ではそこからさらにもう一歩踏み込み、ABAC を用いた「適切な人に、適切な時だけ」アクセスを許可する仕組みについて紹介します。 単なるサーバーのコンテナ化に留まらず、IdP の属性を活用した本人認証の強化や、Slack 連携によるオンデマンドな環境提供を組み合わせることで、「必要な時に、権限を持つ本人のみが利用できる」という、実運用に即したアクセス管理を

はじめに こんにちは！早稲田大学 創造理工学部 総合機械工学科 3 年の野村恒晴です。   ...

img[src="https://cdn-ak.f.st-hatena.com/images/fotolife/v/vasilyjp/20251222/20251222150607.jpg"] { height: 600px; width: auto; } img[src="https://cdn-ak.f.st-hatena.com/images/fotolife/v/vasilyjp/20251230/20251230110649.png"], img[src="https://cdn-ak.f.st

本ブログは 2025 年 12 月 15 日に公開された AWS Blog “ Amazon Threat Intelligence identifies Russian cyber threat group targeting Western critical infrastructure ” を翻訳したものです。 2025 年の締めくくりとして、Amazon Threat Intelligence は、重要インフラを標的とした攻撃において大きな進化を示す、数年にわたるロシア国家支援型サイバー攻撃キャン

通信業界のネットワーク運用ではより安定した通信ネットワークを提供するために、障害の検知、要因特定、復旧を早期に対応する必要があります。一方で、近年拡張し複雑化し続けるネットワークに追従することは従来のオペレーションでは難しく、自動化、高度化、自律化が求められています。その実現手段の1つとして、AI エージェントとデータ活用が注目されており、導入への期待が高まる一方で、AI を適用する運用ユースケースの策定、より簡単な AI エージェントの実装方法、商用運用への本格導入、といった課題があります。そこで、本ワ

はじめに CI/CDツールとして広く利用されているJenkinsですが、Windows環境のスレーブノードやエージェントでビルドを実行する際、特有のエラーに悩まされることがあります。 その代表的なものが、ファイルパスに関連するエラーです。 Linux環境では問題なく動作していたジョブをWindows環境に移行した際や、プロジェクトのディレクトリ階層が深くなったタイミングで、突如としてビルドが失敗することがあります。 本記事では、Jenkinsでのビルド実行時に**「パスの一部が見つかりませんでした」**と

はじめに こんにちは、タイミーでPlatform Engineerをしている近藤です。 タイミーでは、インフラ管理においてTerraformを積極的に活用しています。 当初はAWSリソースの管理が中心でしたが、事業や組織の拡大に伴い、管理対象は多岐にわたるようになりました。 現在では、以下のような様々な用途でTerraformリポジトリが運用されています。 AWSインフラ: メインとなるサービス基盤の構築・運用 GCPインフラ: BigQueryなどのデータ分析基盤や、特定のGoogle Cloudリソー

.mermaid { background-color: #ffffff !important; } import mermaid from 'https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.esm.min.mjs'; mermaid.initialize({ startOnLoad: true }); はじめに こんにちは。 エンタープライズ 第三本部 データマネジメントユニット マーケティング IT部の藤澤です。 先日、 API プラットフォー

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

事業が急速に拡大するメガベンチャーにおいて、複数プロダクトやマイクロサービスの品質を横断的に担保することは容易ではありません。 各チームが独立して開発を進める中で、テスト方針の不一致や手戻りの増加に課題を感じる場面も多いはずです。 これまでのUI主体のテストだけでは、リリースの高速化と複雑なシステム構造に対応し続けることは限界を迎えています。 そこで重要となるのがAPIテストの自動化です。 今回は部分最適に陥りがちな現場の改善を全体最適へと導くために、APIテスト自動化の戦略的な進め方や具体的な手法につい

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

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