みなさん、こんにちは。AWS ソリューションアーキテクトの三厨です。 今年の目標は Kiro にどんどん業務をオフロードしていくことです。今日ご紹介する AWS Observability の Kiro Power を使ってみたのですが、複数の監視/運用に関する MCP とその使い方がパッケージングされていて体感として想定している作業を実現するためのプロンプト入力作業が減ってトラブルシュートが加速しました。 先週は Amazon と OpenAI の Strategic partnership が発表されました。 Stateful Runtime Environment や OpenAI Frontier に関しても言及されているので、気になる人はぜひご一読をお勧めいたします。また、 3 月 26 日（木）には「 Amazon Quick Suite で変わる業務の現場 — 活用企業・AWS社員による事例紹介 」が開催されます。分析業務や定型業務の効率化に興味がある方はぜひご参加ください！ それでは、2 月 24 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース AWS 生成 AI 国内事例ブログ: 住信 SBI ネット銀行様、Amazon Bedrock AgentCore を活用した AI 銀行サービス「NEOBANK ai」で顧客体験を革新 住信 SBI ネット銀行様は、デジタル金融における新しい UI/UX の可能性を見据え、ユーザーが「やりたいこと」を伝えるだけで必要な手続きが立ち上がる体験の実現を目指していました。従来のメニュー階層をたどる UI では、ユーザーの意図に沿ったスムーズな体験を提供しにくい場面があったためです。そこで、Amazon Bedrock AgentCore を中核とした AI エージェント機能を活用し、AI 銀行サービス「NEOBANK ai」のベータ版を開発しました。テキスト入力に加え、音声・画像を含むマルチモーダルなインプットを受け取り、AI エージェントが意図を解釈したうえで、照会・分析・手続き案内に必要な“その場で立ち上がる UI”を生成します。AgentCore Runtime による自動スケーリングや、タスクごとに異なる AI モデルを使い分ける柔軟なアーキテクチャ、AgentCore Observability による実行プロセスの可視化も実現しています。今後は ITSM 連携の強化やさらなるサービス高度化を目指すとのことです。 AWS 生成 AI 国内事例ブログ: ミツイワ株式会社様、Amazon Bedrock と AWS CloudFormation を活用した次世代インフラ自動構築ソリューション ミツイワ株式会社様は、ICT ライフサイクル全体をサポートするワンストップソリューションを提供する中で、顧客からの問い合わせ内容の整理や要件定義、環境構築に多くの時間がかかり、リードタイムの長期化や品質のばらつき、属人化といった課題を抱えていました。そこで、Amazon Bedrock による問い合わせ内容の自動解析と、AWS CloudFormation によるインフラ構築の自動化を組み合わせた次世代ソリューションを開発しました。AWS Lambda 上で MCP サーバーを起動するサーバーレスな構成により、問い合わせ受付から環境構築・初期設定・完了通知までを一気通貫で自動化し、従来数日から数週間かかっていたプロセスを大幅に短縮することに成功しています。 ブログ記事「 Amazon Q Developer 活用をプロジェクト全体へ拡げた取り組み 」を公開 株式会社 NTT ドコモ様の主要な Web サービス提供基盤「POPLAR」における Amazon Q Developer の組織展開事例です。 Software/Middleware のバージョンアップ案件で最大約 50% の効率化を達成し、その成功体験をもとに利用ガイドライン・環境設定マニュアル・プロンプト集などを体系化してプロジェクト全体へ展開しました。さらに生成 AI 開発ガイドラインの標準化や MCP Server 連携環境の整備、利用状況のダッシュボード可視化と個別フォローまで、段階的な取り組みの全体像が紹介されています。 ブログ記事「 Strands Labs の紹介: エージェント開発の最先端実験的アプローチを今すぐ体験 」を公開 エージェンティック AI 開発のための実験的なアプローチを試せる新しい Strands GitHub 組織「Strands Labs」が発表されました。ローンチ時には 3 つのプロジェクトが公開されています。Robots は AI エージェントが物理ロボットを制御するフィジカル AI、Robots Sim はシミュレーション環境での迅速なプロトタイピング、AI Functions はコードの代わりに自然言語仕様で関数を定義する実験的アプローチです。Strands Agents SDK を活用したエージェント開発に興味のある方はぜひチェックしてみてください。 ブログ記事「 AWS Elemental Inference でライブ動画をモバイルオーディエンス向けに変換 」を公開 新サービス AWS Elemental Inference が発表されました。ライブ動画やオンデマンド動画を AI で自動的に分析し、TikTok や Instagram Reels などのモバイルプラットフォーム向けに縦型形式へリアルタイム変換するフルマネージド AI サービスです。エージェンティック AI アプリケーションを使用しており、人間の介入なしにコンテンツを自律的に最適化します。ベータテストでは、複数のポイントソリューションを使用する場合と比較して 34% 以上のコスト削減を達成しています。 ブログ記事「 カスタム Amazon Nova モデル用の Amazon SageMaker Inference の発表 」を公開 Amazon SageMaker Inference でカスタム Nova モデルのサポートが一般提供開始されました。Nova Micro、Nova Lite、Nova 2 Lite のカスタマイズモデルを、G5 や G6 インスタンスを使用してコスト効率よくデプロイできます。SageMaker Training Jobs や HyperPod でトレーニングしたモデルをシームレスにデプロイする、エンドツーエンドのカスタマイズジャーニーが実現しています。 ブログ記事「 Agentic AI でサプライチェーン ロジスティクスを変革 」を公開 この記事では、AWS プロフェッショナルサービスがシンガポールの科学技術研究庁（A*STAR）と共同で開発した物流エージェントの事例を紹介しています。Amazon Bedrock を活用し、ERP・TMS・WMS などの複数データソースからリアルタイムにデータを集約・統合することで、自然言語での問い合わせに対して即時かつ正確な回答を提供します。手動での検索・照合作業を最大 50% 削減し、緊急配送コストを物流費用の 3〜5% 削減する効果が見込まれています。 ブログ記事「 AI コーディングに潜む非効率性とその発見方法 」を公開 AI コーディングエージェントは合格率やトークン数といったベンチマークで評価されることが一般的ですが、タスクが「合格」していても、エージェントが非効率な経路をたどっているケースがあります。この記事では、Kiro の AI エージェントが取った一連のアクション全体を軌跡ベースで分析し、ベンチマークでは見逃される非効率性を発見・改善する仕組み「CORAL」を紹介しています。具体例として、検索ツールの説明に 1 行追加するだけで誤った grep パターンを約 99% 削減した事例や、cd コマンドの誤用を検知して自動的に正しいパラメータに変換する仕組みが解説されています。 サービスアップデート Amazon Bedrock の Responses API にて AgentCore Gateway 連携によるサーバーサイドツール実行をサポート Amazon Bedrock の Responses API にて、Amazon Bedrock AgentCore Gateway を通じたサーバーサイドツール実行がサポートされました。AgentCore Gateway の ARN をツールコネクタとして指定すると、Amazon Bedrock がゲートウェイから利用可能なツールを自動検出し、モデルがツールを選択した際にサーバーサイドで実行します。これにより、クライアントサイドのツールオーケストレーションループを構築・維持する必要がなくなり、エージェンティックワークフローのアプリケーション複雑性とレイテンシーが削減されます。Responses API と AgentCore Gateway の両方が利用可能なすべてのリージョンで利用できます。 Amazon Bedrock バッチ推論にて Converse API フォーマットをサポート Amazon Bedrock のバッチ推論にて、モデル呼び出しタイプとして Converse API がサポートされました。従来はモデル固有のリクエストフォーマットが必要でしたが、リアルタイム推論とバッチ推論で同じ統一リクエストフォーマットを使用できるようになり、プロンプト管理の簡素化とモデル切り替えの手間が削減されます。Amazon Bedrock バッチ推論がサポートされているすべてのリージョンで利用可能です。 Amazon Bedrock にて OpenAI 互換 Projects API を発表 Amazon Bedrock の分散推論エンジン Mantle にて、OpenAI 互換の Projects API がサポートされました。複数のアプリケーション、環境、チームを持つお客様は、個別のプロジェクトを作成して分離を実現できます。各プロジェクトに異なる IAM ベースのアクセス制御を割り当てたり、タグを追加してコスト可視性を向上させることが可能です。追加料金なしで利用できます。 Amazon Bedrock Guardrails の Automated Reasoning ポリシーにてソースドキュメント参照を追加 Amazon Bedrock Guardrails の Automated Reasoning ポリシーにて、ソースドキュメント参照機能が追加されました。Automated Reasoning checks は形式検証技術を使用して、基盤モデルが生成したコンテンツがポリシーに準拠しているかを検証する機能で、AI ハルシネーション検出において最大 99% の精度を実現します。今回の更新により、生成されたポリシールールや変数を元のドキュメントの内容と照らし合わせてレビューできるようになり、ポリシーの確認・改善が容易になりました。 Amazon Q Developer にて生成 AI ベースのアーティファクト機能を一般提供開始 AWS マネジメントコンソールにて、Amazon Q Developer アーティファクト機能が一般提供開始されました。リソースデータをテーブル形式で、コストデータをチャート形式で可視化できる生成 AI ベースのユーザー体験です。例えば「タグ値が production の S3 バケットを一覧表示」と質問すると表形式で表示され、「過去 6 か月の RDS コストをインスタンスタイプ別に表示」と質問するとチャートで表示されます。Q アイコンがナビゲーションバーに移動し、コンソールのどこからでもアクセスしやすくなりました。 AWS Elemental Inference を一般提供開始 ライブ動画やオンデマンド動画を AI で自動的に変換するフルマネージドサービス AWS Elemental Inference が一般提供開始されました。エージェンティック AI を使用して、横型配信を TikTok や YouTube Shorts などのモバイルプラットフォーム向けの縦型形式にリアルタイムで変換する機能と、ライブコンテンツからハイライトクリップを自動生成する機能を提供します。米国東部（バージニア北部）、米国西部（オレゴン）、アジアパシフィック（ムンバイ）、欧州（アイルランド）で利用可能です。 AWS IAM Policy Autopilot が Kiro Power として利用可能に re:Invent 2025 で発表されたオープンソースの静的コード分析ツール AWS IAM Policy Autopilot が、Kiro Power として利用可能になりました。Kiro IDE からワンクリックでインストールでき、手動での MCP サーバー設定が不要です。AWS アプリケーションの迅速なプロトタイピングや新規プロジェクトのベースラインポリシー作成に活用できます。 AWS Observability が Kiro Power として利用可能に AWS Observability が Kiro Power として利用可能になりました。CloudWatch、Application Signals、CloudTrail、AWS Documentation の 4 つの MCP サーバーをパッケージ化し、アラーム対応、異常検知、分散トレーシング、SLO コンプライアンス監視、セキュリティ調査などの包括的なワークフローを IDE 上で実現します。自動ギャップ分析機能により、コード内の不足しているインストルメンテーションパターンの特定と改善提案も行います。 Amazon Location Service が Kiro Power として LLM コンテキストを提供 Amazon Location Service が、Kiro Power および Claude Code プラグインとして AI エージェントコンテキストを提供開始しました。住所入力フォーム、地図表示、最寄り店舗検索、ルート可視化などの一般的な位置情報ソリューション開発を加速する、事前検証済みの実装パターンとステップバイステップの手順が含まれています。東京リージョン含む複数のリージョンで利用可能です。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 三厨 航  (Wataru MIKURIYA) AWS Japan のソリューションアーキテクト (SA) として、ヘルスケア・ハイテク製造業のお客様のクラウド活用を技術的な側面・ビジネス的な側面の双方から支援しています。クラウドガバナンスや IaC 分野に興味があり、最近はそれらの分野の生成 AI 応用にも興味があります。最近の趣味はカメラです。 週刊 AWS の新しいサムネイルを撮影したので、是非ご覧ください。

はじめに こんにちは、2025年12月入社の齋藤です！ 本記事では、2025年11月・12月に入社したメンバー8名に入社直後の感想をお伺いし、まとめました。 KINTOテクノロジーズ（以下、KTC）に興味のある方、そして、今回参加してくださったメンバーへの振り返りとして有益なコンテンツになればいいなと思います！ 齋藤 諒太  自己紹介 KINTO開発部でフロントエンドエンジニアとして働いています。新潟県出身で今は大阪市在住です。 業務としては主にKINTOのシミュレーションや申し込み、マイページの開発を行っています。 前職ではRailsやNext.jsで構成された比較メディアサイトの開発をフロントエンド・バックエンドの領域を問わず担当していました。 趣味は自作PC、ゲーセン、ペットの猫をこねることです。よろしくお願いします。 所属チームの体制は？ Osaka Tech Labに3人、室町オフィスに6人の合計9人のチームです。 1週間単位のスプリントで開発を進めています。毎週のプランニングでタスクを決め、レトロスペクティブで成果と課題を振り返ります。 毎日デイリースクラムで進捗を共有し、互いの状況を把握することで効率的な開発体制を維持し、短いサイクルで改善を重ねています。 チームの雰囲気はどんな感じ？ 拠点や勤務形態が多様でオンライン中心ですが、不明点があればすぐに質問でき、相談もチーム内外で活発に行われています。 課題や改善案があればADRを通じて提案できます。ADRはアーキテクチャに限らず、チームのルールや方針を幅広く決めるための仕組みとして活用しており、誰でもカジュアルに新しいアイデアを発信し、継続的な改善を進められる環境です。 KTCへ入社したときの入社動機や入社前後のギャップは？ これまで培った技術や知識を活かせる環境で働きたいと考え、以前から関心を持っていたKINTOのサブスクリプションサービスに、ユーザーとしてだけでなく開発者としても携わりたいと思い入社しました。 入社後、大きなギャップはありませんが、Osaka Tech Labは思っていたよりもまだ人数が少なく、落ち着いた雰囲気だった点はギャップかもしれません。 オフィスで気に入っているところ JCTと駅直結の利便性です。外部イベントも開催され、気軽に参加できるうえ、雨でも濡れずに出社できます。 フクロウさん ⇒　齋藤 諒太さんへの質問 おすすめのアプリやサービスありますか？ 10年以上1Passwordを使っています。覚えておくのは1Passwordのマスターパスワードだけで済み、強力なパスワードを自動生成して保存・同期してくれるのでとても楽です。さらにクレジットカード情報の管理機能や、パスワードの使い回し・漏えいを自動検出して通知するセキュリティ監査機能も備わっています。Windows、Mac、iOS、Androidに加え、ブラウザ拡張機能にも対応しており、ほぼすべての環境で使える点も魅力です。 うえぽん  自己紹介 デジタル戦略部DataOpsG所属となります！ 前職はSESエンジニアとして多様な業種、システムにかかわってきました。 趣味は釣りで最近は月に1回程度しか行けていないので食卓と話題のネタを仕入れに行かなければ。という意気込みです！ よろしくお願いします。 所属チームの体制は？ チーム内でもデータの蓄積を行う基盤チーム、蓄積したデータを提供する仕組みを扱うnicolaチームという構成になっていて、全体で9名の体制です。 チームの雰囲気はどんな感じ？ それぞれの強みを生かして日々業務や技術・知識習得に取り組んでいます。 共有の場では積極的に深掘りをしてチームとしての向上心が高いと感じています！ KTCへ入社したときの入社動機や入社前後のギャップは？ 特定の分野で技術を磨き自身の強みとしたい！ フルスタックエンジニアとしての経験を活かせる！ 入社前に丁寧な説明をしていただけて、業務環境についてギャップはなかったです。 オフィスで気に入っているところ 名古屋オフィスは駅の地下街から直結されているため悪天候の影響を受けずに出社できます！ 齋藤 諒太さん ⇒　うえぽんさんへの質問 これまで多くの現場を経験されたとのことですが、特に印象に残っている現場はありますか？ 銀行関係の現場なこともありセキュリティー意識がとても高かったです。（検証環境エリア、本番環境エリア共に作業者・作業理由・作業時間の事前申請必須など） また、利用者がいない時間に更新するため、深夜当番と早朝当番を月1でやっていました。 debugon  自己紹介 Engineering Officeでアクセシビリティを社内文化にする仕事をしている辻です。KTCには辻さんが何人かいらっしゃるので、私のことは debugon と覚えてください。 AIで音楽を作るのが趣味です。 所属チームの体制は？ それぞれの専門領域を持つメンバーが、東京、名古屋、福岡で活動するチームです。 専門的な知識を生かしつつ、他のメンバーの専門性との化学反応を生かし、社内の様々なチームの力を最大限に発揮できるように共創しています。 チームの雰囲気はどんな感じ？ 複数拠点で活動するチームなので、オンラインやオフラインでコミュニケーションをしっかりとっています。 「食べ物」の話しが好きなメンバーが多いので、食べる話になるとSlackチャンネルが盛り上がります。 KTCへ入社したときの入社動機や入社前後のギャップは？ モビリティカンパニーに文化としてアクセシビリティの考え方を広めたくて入社しました。 「一緒に良いものを作っていきたい」という考えの方がたくさんいらっしゃるので、とてもやりがいを感じています。 オフィスで気に入っているところ トヨタ車の模型がたくさん置いてあって、それぞれの形を手で触って確認できたことがうれしかったです。 うえぽんさん ⇒　debugonさんへの質問 AIで音楽作成されるとのことですが、どんなジャンルの音楽が好きですか？制作に使うお気に入りのツールやソフトあれば教えてください！ 音楽を作るときには Suno を使っています。ジャズが好きなのですが、気分のままにこれまでに聞いたいろいろなジャンルの音楽を思い出しながら作っています。 なかぴー  自己紹介 障害者雇用枠で2025年12月に入社しました。在宅勤務です。 経歴としましてはSIerのエンジニアからキャリアをスタートして、事業会社の社内SE、PM、ITコンサルタントの経験があります。 伴走型のPMで、「餅は餅屋」をモットーに駆けずり回るスタイルでフットワークには定評がありました。 約1年半前に脳出血で左半身麻痺になりました。完全在宅の時短勤務で働けることが有難いです。 所属チームの体制は？ 開発支援部人事グループの中の労務総務チームです。チームは自分を含めて4名です。 チームの雰囲気はどんな感じ？ 定例会では休日の様子も共有し合って和やかな雰囲気です。 KTCへ入社したときの入社動機や入社前後のギャップは？ 入社動機：経験を活かしてエンジニアの方のサポートが出来そうだと感じたから。 入社前後のギャップ：1on1が多い。激務な職場が多かったのですが、今は業務量を調整してもらえて有難いです。 オフィスで気に入っているところ 室町オフィスがあるコレド室町はお洒落な商業ビルで駅直結なのでリハビリを頑張って出社したいです。 debugonさん ⇒　なかぴーさんへの質問 お気に入りのデスクアイテムや文房具は？ とにかく忘れないように、付箋を頻繁に使っています。シンプルなものが一番使いやすいです。 miurat  自己紹介 デジタル戦略部DataOpsGにデータエンジニアとしてジョインしました。 前職では、事業会社でデータ基盤構築やデジタルマーケティング関連の仕事に従事してきました。 趣味は、テニス、ゴルフでボールを打つことが好きです！ 所属チームの体制は？ メンバーは東京・名古屋・大阪の3拠点あわせて計9名です！ チームの雰囲気はどんな感じ？ チーム全体の雰囲気は風通しが良く、相談や雑談もしやすい雰囲気です。 また、好奇心旺盛なメンバーが多く、最新のトレンドや業界ニュースなどを積極的に共有し合う文化が根付いています。 KTCへ入社したときの入社動機や入社前後のギャップは？ ビジョン・バリューに共感したからです！ 入社後のギャップは、ドキュメントが整っているなと思いました！ オフィスで気に入っているところ 大阪オフィスは、高層階の為、景色が綺麗です。また、駅直結なので、通勤が便利です！ なかぴーさん ⇒　miuratさんへの質問 データ分析で心がけていることは何ですか？ 誰もがストレスなく使えるよう、複雑さを取り除いたシンプルな設計と、データの品質維持を心がけています。 でこぽん  自己紹介 Cloud Infrastructure G にエンジニアとしてジョインしました。 前職では AWS 専業のエンジニアとしてシステム開発やお客様の内製化支援などを行っていました。 趣味はテニスや登山で、主に神奈川の山を登ってます！ 所属チームの体制は？ 10名程度の組織で、サービスを支えるインフラチーム、中長期的な課題への改善を繰り返すカイゼンチーム、そしてトヨタグループの CCoE を支えるソリューションチームがあり、私はソリューションチームに所属しています。 チームの雰囲気はどんな感じ？ 和気あいあいな雰囲気です。 お昼は出社しているメンバーのほとんど全員で外に出て神保町のいろいろな美味しいお店を開拓しています。 二郎系ラーメンを食べる人が多くいます。 KTCへ入社したときの入社動機や入社前後のギャップは？ ビジョンに対してチームで前向きに進んでいけそうな雰囲気に魅力を感じました。 入社後のギャップも特になく、自由な雰囲気で成果を出していくことができると思います。 オフィスで気に入っているところ 神保町オフィスに在籍しているのですが、周りに美味しいお店が無限にあります！ miuratさん ⇒　でこぽんさんへの質問 ストレス発散方法を教えてください！ 同僚や友人とお酒を飲みに行くことです🍻 Yanaggy  自己紹介 プロダクトマネージャーとして入社しました。 TOYOTA UPGRADE FACTORY/LEXUS UPGRADE FACTORYというクルマの「アップグレード」をWebで申し込めるサービスを担当しています。 漫画から小説までいろんな本を読むのが好きです。 所属チームの体制は？ チームはFE/BEエンジニア、SRE、QA、ディレクター、PDMなど約10名からなり、東京、大阪にまたがっています。 PDMは東京1名、大阪1名の2名体制です。毎朝オンラインで話して案件状況や課題をシェアしながら案件を進めています。 チームの雰囲気はどんな感じ？ 拠点は離れていますが、Slackの非同期コミュニケーション、オンラインでのデイリーMTG、ちょっとした相談など同期コミュニケーションを使い分けながら仕事を進めています。 KTCへ入社したときの入社動機や入社前後のギャップは？ これまでは金融やデジタルコンテンツのシステム開発をしており、次は実物のあるモノに関わる業界で仕事したかったのと、小寺さんがインタビューで語っていた「最初のクルマ、最後のクルマ」のコンセプトにひかれたからです。 良いギャップとしては職務・職種の経歴、年齢層など思ってたより様々な背景を持ったメンバと仕事できるのが刺激的です。 オフィスで気に入っているところ 大阪オフィスの机が広い。あとJCTと呼ばれているイベントを行える広いスペース。社内外の様々なイベントが開催されています。 でこぽんさん ⇒　Yanaggyさんへの質問 Osaka Tech Lab 周辺で一番お気に入りのランチもしくは居酒屋があれば教えてください！ 九州ラーメン亀王。高校生の時から通っているラーメン店です。オフィスから少し離れていますがよく行きます。 フクロウ  自己紹介 開発支援部人事G採用チームに配属。 これまで在宅でバックオフィス業務に加え、デザインや動画制作などのクリエイティブ業務も経験してきました。 昨年まで療養期間がありましたが、体力づくりを経て、最近は本格的に筋トレに取り組もうと考えています。 所属チームの体制は？ 開発支援部人事G採用チーム（7名）に所属しています。 採用計画に沿って、募集・面接・進捗共有などを進めながら、より良い採用に向けて日々改善しています。 チームの雰囲気はどんな感じ？ オンラインでのMTG参加はまだ多くありませんが、問題点の共有や改善に積極的に取り組む姿勢がうかがえます。 笑い声も絶えない和やかな雰囲気もあります。 KTCへ入社したときの入社動機や入社前後のギャップは？ 障害者雇用という立場ではありますが、面接時、他社に比べて良い意味で特別扱いされすぎず、他のメンバーと同じように見てもらえている点にとても好感。 入社後も必要な配慮は十分過ぎるほどありつつ、想像していたようなギャップは特に感じていません。 オフィスで気に入っているところ 完全在宅のためオフィス出社の機会はありませんが、社内外の様々なイベントに参加してみたいなと思っています。 Yanaggyさん ⇒　フクロウさんへの質問 体力・健康維持のためにやっていることはありますか？ 基本的な体調管理はもちろん、障害の特性的に、体温と気温、食事の温度などは常に気にしています。 さいごに みなさま、入社後の感想を教えてくださり、ありがとうございました！ KINTOテクノロジーズでは日々、新たなメンバーが増えています！ 今後もいろんな部署のいろんな方々の入社エントリが増えていきますので、楽しみにしていただけましたら幸いです。 そして、KINTOテクノロジーズでは、まだまださまざまな部署・職種で一緒に働ける仲間を募集しています！ 詳しくは こちら からご確認ください！

SCSKの畑です。 今回は実案件における Redis から Elasticashe（Redis OSS）への移行において直面したいくつかの仕様差異について、どのような対策を取ったのかも合わせて紹介したいと思います。ちなみに移行に関する初回のエントリは以下となります。 Amazon Elasticache 移行方式のまとめ とある案件において 他クラウド IaaS 上の Redis から Elasticache（Redis OSS）へのデータ移行要件があったため、移行方式についてどの方式を採用したのかを含めてまとめてみました。 blog.usize-tech.com 2026.02.12   差異その1：Elasticache は停止ができない まずはベーシックな内容から。 よく知られていることだと思うのですが、Redis と異なり Elasticache は停止ができません。メモリ上にデータを保持する以上、インスタンスを停止するとデータが失われてしまうが故の仕様かと類推するのですが、停止できないということは一度インスタンスを立ち上げた後は常時課金が発生してしまうことになります。特に性能試験用の環境のように、使用中は本番環境と同様の大きいインスタンスを必要とする環境ではその弊害もより大きくなってしまいます。 Redis も停止すればデータは失われる以上、（データを保持したままの）停止ができないというのは同様と言えるかもしれません。ただ、Redis の場合はデフォルトで起動時にバックアップ（dump.rdb ファイルなど）からのデータロードが可能なため、起動停止を前提とした運用は Elasticache より実施しやすいと言えると思います。 そこで、大きなインスタンスサイズを必要とする環境については、環境を使用していない時間帯はインスタンスサイズを縮小することで課金額を低減しようと考えていたのですが・・ふと、縮小先のメモリサイズより大きなデータが Elasticache 上に存在したらどういう挙動になるんだろう？という疑問が。実運用時においても同じような状況になることが予想できたため事前に検証しておくことにしました。 試しに 10 GB のキャッシュデータを cache.r7g.xlarge のインスタンスにロードした後、t3.micro にサイズを変更してみたところ・・ Failed to scale down to cache node type Replication Group redis-downsize-test because the node has insufficient memory. Please select a different node type or reduce current memory usage and retry のようなエラーが出力されてしまったため、（ある意味予想通りでしたが）縮小できませんでした。よって、Elasticache の（再）作成・削除により起動・停止を代替する方法が唯一の回避策という結論となりました。削除時にデータをバックアップとして残しておいて、それを（再）作成時に使用するような流れです。先述した Redis の挙動を Elasticache で実現しようとするとこうなります、とも言えますね。 直近にリリースした Elasticache で早速この対応が必要となったため、 一旦は AWS CLI で実装することで解決しました 。 ただし、この手法だと各環境ごとに Elasticache の（再）作成コマンドが必要になってしまうためあまり効率が良いとは言えません。本案件における AWS リソース/サービスのデプロイには CloudFormation を使用しているため、将来的にはそちらに移行したいところです。DeletionPolicy あたりを使用すればできるのかしら・・？   差異その2：一括移行の場合 Elasticache をバックアップから新規作成する必要がある 続いてはこちらのテーマ。上記内容（差異その1）とも関連する内容でもあります。 先般のエントリ でも言及していた通り、本案件における Elasticache のデータ移行は一括移行で実施する旨決定したのですが、一括移行において現行環境で取得したバックアップを新環境に移行する際において、そのタイミングでバックアップから Elasticache を新規作成する必要があります。言い換えると、作成済みの Elasticache に対して特定のバックアップをリストアするというオペレーションが行えません。 よって、一括移行のタイミングまで新環境（Elasticache）のエンドポイントが不明な状態になってしまうという懸念点がありました。当日移行（切替）のタイミングでアプリケーション側の各種設定を変更する必要がある訳ですが、その直前まで新環境（Elasticache）のエンドポイントが分からないというのは作業への影響が大きいと考えたためです。 当初この仕様にものすごく違和感があったのですが、Redis の場合も起動時にバックアップ（dump.rdb ファイルなど）のデータを読み込む挙動をしており、実のところ同じ仕様でした。。ただ、仮に同様のシナリオで別の IaaS 上の Redis に移行するケースを考えてみると、移行先サーバへの接続情報（IPアドレス/FQDN）は Redis 移行前に分かっていることになるので、その点においては差異があると思います。 一方で、過去の経験や上記（差異その1）の対応において Elasticache を同じ設定で再作成した場合、再作成前後で必ず同じエンドポイント名となったことから、裏取りも兼ねてエンドポイントの命名規則が分かれば（少なくとも現在の仕様において）事前に新環境でのエンドポイント名を導出することができると考えました。 AWS のドキュメントには該当するような内容がなさそうだったので、大人しく AWS サポートに確認しました。その結果、命名規則に関する公開情報はないという前提において現在の仕様を確認頂くことができたので、以下に共有します。クラスターモードや転送中の暗号化の差異によりエンドポイントの FQDN が異なるというのは正直気付かなかったところです・・ ◆クラスターモード無効・転送中の暗号化が有効 ・プライマリエンドポイント master.<クラスター名>.<6文字のランダム文字列(※).<リージョン名>.cache.amazonaws.com ・リーダーエンドポイント replica.<クラスター名>.<6文字のランダム文字列(※).<リージョン名>.cache.amazonaws.com ・ノードエンドポイント <ノード名>.<クラスター名>.<6文字のランダム文字列(※)>.<リージョン名>.cache.amazonaws.com ◆クラスターモード無効・転送中の暗号化が無効 ・プライマリエンドポイント <クラスター名>.<6文字のランダム文字列(※)>.ng.0001.<リージョン名>.cache.amazonaws.com ・リーダーエンドポイント <クラスター名>-ro.<6文字のランダム文字列(※)>.ng.0001.<リージョン名>.cache.amazonaws.com ・ノードエンドポイント <ノード名>.<クラスター名>.<6文字のランダム文字列(※)>.0001.<リージョン名>.cache.amazonaws.com ◆クラスターモード有効・転送中の暗号化が有効 ・設定エンドポイント clustercfg.<クラスター名>.<6文字のランダム文字列(※)>.<リージョン名>.cache.amazonaws.com ・ノードエンドポイント <ノード名>.<クラスター名>.<6文字のランダム文字列(※)>.<リージョン名>.cache.amazonaws.com ◆クラスターモード有効・転送中の暗号化が無効 ・設定エンドポイント <クラスター名>.<6文字のランダム文字列(※)>.clustercfg.<リージョン名>.cache.amazonaws.com ・ノードエンドポイント <ノード名>.<6文字のランダム文字列(※)>.0001.<リージョン名>.cache.amazonaws.com (※) 「6文字のランダム文字列」は、同一アカウント・同一リージョンであれば同じ値となる 今回使用するのは 「クラスターモード無効・転送中の暗号化が無効」 のパターンに該当するので、こちらの命名規則を連携して一旦解決となりました。   差異その3：通信暗号化方式と認証方式の組み合わせにおける制約がある さて、ある意味本題というか、相対的に影響が大きかったトピックがこちらとなります。 現行の Redis では 通信暗号化方式：暗号化なし 認証方式：AUTH 認証 という設定だったため Elasticache でも踏襲しようとしたところ、なんと Elasticache の仕様として設定できない ことがわかりました。設定可能な組み合わせは 通信暗号化方式：暗号化あり、認証方式：AUTH 認証 通信暗号化方式：暗号化あり、認証方式：認証なし 通信暗号化方式：暗号化なし、認証方式：認証なし のどちらかに限定されており、どれを選択した場合においても現行 Redis との非互換が発生してしまいます。また、現行 Redis との互換性を考えると、上記 3 つの組み合わせの内、2 についてはどちらの項目も現行 Redis からの変更になるため採用するメリットがないと判断し、それ以外の方式（1 or 3）のメリット・デメリットを整理した上でどちらの組み合わせを採用するかお客さんも交えて検討しました。 Elasticache における方式の組み合わせが限定されている理由として考えられるのは、「通信暗号化なしの場合は認証情報も平文で通信路を流れてしまうため、認証を設ける意味がない」というところだと思います。その意図は理解できるのですが、サービスレベルで組み合わせを限定するほどの意義があるのかというと・・正直ないのでは？というのが個人的な感想です。 ざっくりメリット・デメリットをまとめると以下の通りです。平たく言うと、現行環境と同一にする（ことで影響を抑えたい）項目としてどちらを取るかというような内容ですね。 通信暗号化方式：暗号化あり、認証方式：AUTH 認証 メリット：AUTH 認証に関連するアプリケーションコードの変更が不要 通信暗号化に関連するアプリケーションコードの変更は必要 デメリット：Elasticache への移行により、通信暗号化に伴う性能への影響が生じる可能性あり 通信暗号化方式：暗号化なし、認証方式：認証なし メリット：Elasticache への移行により性能への影響が生じる可能性を相対的に抑えられる（通信暗号化しないため） デメリット：AUTH 認証に関連するアプリケーションコードの変更が必要 結論から言いますと、本案件では性能への影響を重視して 「通信暗号化方式：暗号化なし、認証方式：認証なし」 の組み合わせを選択するになりました。また、現在 AWS へのマイグレーションを先行して実施している別の案件でも同一方式が選択されていたことも理由の一つとなりました。   補足：今回のケースにおける、上記変更に伴うアプリケーションへの影響について 上記にまとめた通り、通信暗号化を有効にする場合・AUTH 認証を無効にする場合どちらもアプリケーションコードの変更はいずれにせよ必要になりますが、実際にどのような変更が必要かはアプリケーション側の実装に依存します。 今回のケースの場合、通信暗号化関連についてはいわゆるアプリケーションのコンフィグ変更が必要でしたが、いずれにせよ移行（切替）時に接続先を Elasticache のエンドポイントに変更する必要があることも鑑みると、影響はほぼなしという判断になりました。 対して、AUTH 認証の無効化については一部のライブラリを使用しているアプリケーションコードにおいて影響がありました。例えば、phpredis ライブラリを使用した以下のような php のコードで AUTH 認証なしのElasticache (Redis) に対して接続しようとすると $redis = new Redis(); $redis->connect($host, $port, $timeout); $authenticated = $redis->auth($password); 以下のように、3行目の $redis->auth($password) 実行部分においてエラーが出力されてしまいます。AUTH 認証が無効であるにも関わらず AUTH コマンドが実行されているという内容ですね。よって、このようなコードについて、対象処理の削除、Elasticache (Redis) に接続できた時点で各種操作ができるようなロジックへの変更などの修正が必要となりました。 PHP Fatal error:  Uncaught RedisException: ERR AUTH <password> called without any password configured for the default user. Are you sure your configuration is correct? in /home/ec2-user/redis_test.php:14 ちなみに、AUTH 認証無効の Elasticache (Redis) に接続した状態でこの処理を実行したとしても、もしライブラリ側でエラーを返さないような実装になっていればコード変更が不要になった可能性もあります。そのあたりは使用しているライブラリに依存するところですが、上記については redis-cli のような公式ツールでも同じ挙動になったので、（言い方が適切がどうかはさておき）この実装自体は正しいのかなと思います。   まとめ 1点目・2点目については仕様だけ見てこういうものなのね、と一旦流していたのですが、よくよくユースケースを考えると困るみたいな内容でした。幸いどちらも事前に気づけてひとまず対策できたので良かったです。 トータルで一番影響が大きかったのはやはり3点目です。パラメータレベルでの互換性は事前にチェックしていたのですが、Elasticache においてはパラメータで設定できない内容だったことに加えて、個々の設定（通信暗号化/ユーザ認証）としては可能だけど組み合わせパターンに制約がある、という非互換性はちょっと予見できておらず面食らいました。先述の通りその意図は理解できなくはないんですけど、Redis との互換性を考えるとできるようにしておいても損しないんじゃないかと思うんですけどどうなんでしょうか。Elasticashe（Redis OSS）を選択する以上は、Redis との互換性を最優先するという意図があるでしょうし。 本記事がどなたかの役に立てば幸いです。