本記事は 2026 年 2 月 23 日に公開された “ Resilience testing on Amazon ElastiCache with AWS Fault Injection Service ” を翻訳したものです。 Amazon ElastiCache は、Valkey、Memcached、Redis OSS をサポートするフルマネージドのインメモリキャッシングサービスで、99.99% の可用性を提供しながら、コスト効率の良い価格でアプリケーションのパフォーマンスをリアルタイムに向上させます。 頻繁にアクセスされるデータに対してサブミリ秒のレスポンスタイムを提供するため、データベースクエリのキャッシング、Web セッション状態の管理、ゲームのリアルタイムリーダーボードの実現などに広く使用されています。 多くのアプリケーションは、キャッシュが常に利用可能であることを前提に構築されています。 耐障害性テストを行わないと、Amazon ElastiCache へのアクセスが失われた際にアプリケーションで問題が発生することがよくあります。 アプリケーションがデータベースへ適切にフォールバックせずにクラッシュすることに気づくかもしれませんが、それは本番環境でのインシデント発生時、つまり手遅れになってからのことです。 そのため、キャッシュが利用できなくなるイベントに備えて構築し、アプリケーションが期待どおりにそれらの障害ケースを処理することをテストする必要があります。 この投稿では、 AWS Fault Injection Service (AWS FIS) を使用して Amazon ElastiCache で耐障害性テストを実行する方法と、アプリケーションの耐障害戦略を強化するためにAWS FISをどのように活用できるかをご紹介します。 ソリューションの概要 このソリューションでは、AWS FIS を使用しています。 これは、AWS ワークロードに対して制御された障害注入実験を実施するためのフルマネージドな耐障害性テストサービスです。 メンテナンスや特権を必要とするカスタムスクリプトやサードパーティツールに頼る代わりに、AWS FIS はシステムの耐障害性をテストするための安全でスケーラブル、かつ高可用性のプラットフォームを提供します。 AWS FIS は、システムにストレスがかかった際の応答を観察するために、意図的に障害を発生させるという手法に基づいて動作します。 これらの実験により、弱点を特定し、システムの動作に関する仮定を検証し、実際の障害に耐えるアプリケーションの能力に対する信頼を高めることができます。 AWS FIS を使用すると、テスト環境または本番環境で耐障害性テストを実施できます。 例えば、ピークトラフィック時の Amazon ElastiCache ノード障害のような現実的なシナリオをテストし、最も重要な場面でフェイルオーバーの仕組みが機能することを確認できます。 この記事では、耐障害性テスト用の ElastiCache クラスターのセットアップ方法、AWS FIS 実験テンプレートの作成方法、制御されたフェイルオーバーテストの実行方法、および結果のモニタリングと解釈方法について説明します。 前提条件 このソリューションを実装する前に、以下を確認してください： アクティブな AWS アカウント テスト用の非本番環境 Amazon ElastiCache サービスの基本的な理解 このソリューションでは、新しい AWS リソースの作成と利用が必要です。 そのため、アカウントに費用が発生します。 詳細については、 AWS Pricing を参照してください。 本番環境に実装する前に、非本番環境でセットアップし、エンドツーエンドの検証を実行することを強くお勧めします。 方法論 この実験では、Amazon ElastiCache が自動フェイルオーバーを使用してノード障害時に高可用性を維持する方法を示します。 Multi-AZ が有効でクラスターモードが無効な Amazon ElastiCache for Valkey クラスターでノード障害を発生させ、アプリケーションが手動介入なしで復旧できることを確認します。 フェイルオーバー中は、以下のアクションが実行されます。 障害検出 : ElastiCache がプライマリノードの障害を検出します。 レプリカの昇格 : レプリケーションラグが最も小さいレプリカがプライマリに昇格します。 DNS 更新 : プライマリエンドポイントが自動的に新しいプライマリを指すようになるため、アプリケーションは同じ接続文字列を引き続き使用できます。 ノードの復旧 : 障害が発生したノードは、復旧後にリードレプリカとして再参加します。 クラスターモード無効の構成を使用しているのは、フェイルオーバープロセスをコンソールで観察しやすくするためです。個々のノードの役割がプライマリからレプリカに変わる様子を明確に確認できます。 ただし、これらのテスト原則はクラスターモード有効のデプロイメントにも適用されます。クラスターモード有効の場合、設定エンドポイントがすべてのシャード間のルーティングを自動的に管理します。 この実験は実は ElastiCache Serverless では意味がありません。ElastiCache Serverless はマネージドプロキシの背後で Multi-AZ フェイルオーバーを処理するため、アプリケーションは中断の影響を受けません。 ElastiCache Serverless の仕組みについては、 ドキュメント を参照してください。 耐障害性の高いアプリケーションでは、接続の中断は短時間にとどまり、自動的に再接続し、データベースに過負荷をかけることなく一時的にフォールバックできる必要があります。 ウォークスルー Valkey クラスターの作成 既存の Amazon ElastiCache for Valkey クラスターモード無効クラスターを使用するか、 Valkey (クラスターモードが無効) クラスターの作成 (コンソール) の手順に従って新しいクラスターを起動できます。 このテストでは、Amazon ElastiCache の汎用バースト可能な T4g または T3-Standard microキャッシュノードを使用することで、コストを抑えることができます。 次のスクリーンショットは、プライマリノードと 3 つのレプリカノードを持つクラスターを示しています： また、クラスターにキー名と値を持つタグを作成します。 以下のスクリーンショットでは、キーを fis-testing 、値を yes としています。 このタグは、AWS FIS 実験テンプレートでターゲットの詳細を編集する際に使用します。 AWS FIS テンプレートのセットアップ Amazon ElastiCache クラスターの準備が整い利用可能になったら、以下のような AWS FIS テンプレートを作成します。このテンプレートでは、注入する障害の種類と対象となるリソースを定義します。 AWS FIS を使用するには、AWS リソースで実験を実行して、障害条件下でアプリケーションやシステムがどのように動作するかという仮説をテストします。 実験を実行するには、まず実験テンプレートを作成します。 テンプレートの詳細については、 ドキュメント を参照してください。 AWS FIS コンソールを開きます。 ナビゲーションペインで、 Experiment templates を選択します。 Create experiment template を選択します。 最初のステップ Specify template details で、テンプレートの詳細に関連する説明と名前を入力し、 Account targeting はこのアカウントのままにしておきます。 Next を選択します。Actions と Targets コンポーネントを設定する前に、それらの用途を理解しておく必要があります。 アクションは、ターゲットに対して実行される障害注入アクティビティです。 AWS FIS は、さまざまな AWS サービス向けのアクションを提供しています。 実験テンプレートにアクションを追加すると、AWS FIS はそれを使用して実験を実行します。 ターゲットは、実験中に AWS FIS がアクションを実行する AWS リソースです。 実験テンプレートを作成するときにターゲットを定義し、複数のアクションで使用できます。 AWS FIS は、アクションを開始する前にターゲットを特定し、実験全体を通じてそれらを使用します。 Add Action を選択します。 Action Type で、 aws:elasticache:replicationgroup-interrupt-az-power を選択して、Multi-AZ が有効になっているターゲット ElastiCache レプリケーショングループの指定されたアベイラビリティーゾーン内のノードへの電源を中断します。レプリケーショングループごとに一度に影響を受けるアベイラビリティーゾーンは 1 つだけです。 プライマリノードがターゲットになると、レプリケーションラグが最も少ない対応するリードレプリカがプライマリに昇格します。 指定されたアベイラビリティーゾーン内のリードレプリカの置き換えは、このアクションの期間中ブロックされます。 つまり、ターゲットのレプリケーショングループは容量が減少した状態で動作します。 詳細については、 ドキュメント を参照してください。 必要に応じて関連する Name を入力します。 Target には、 Targets セクションで定義したターゲットを選択します。 このアクションのターゲットをまだ定義していない場合、AWS FIS が新しいターゲットを作成します。 Action parameters で、アクションのパラメータを指定します。 テスト要件に応じて duration を設定してください。 これは、ターゲットノードで障害アクションが継続する時間の長さです。 Save を選択します。 アクションを保存すると、次のスクリーンショットに示すようにターゲットが自動的に作成されます。 aws:elasticache:replicationgroup を選択して Edit Target ページを開きます。 Target method では、 Resource tags, filters and parameters ラジオボタンがすでに選択されています。 Amazon ElastiCache をターゲットにするには、 resourceTags 要素でタグのみを指定できます。 Add new tag ボタンを選択してリソースタグを追加します。 ここでは、キーを fis-testing 、値を yes として使用しています。 Availability Zone identifier ドロップダウンで、このテストで障害を発生させたいノードのアベイラビリティーゾーンを選択する必要があります。 プライマリノードを含むアベイラビリティーゾーンを選択すると、その AZ が影響を受けたときにフェイルオーバーがトリガーされます。 Selection mode では、識別されたすべてのターゲットで実行するデフォルトオプションの ALL を選択します。 Save を選択します。 Next を選択します。 Service access セクションで、デフォルトの選択である Create a new role for the experiment template のままにします。 コンソールに表示されているサービスロール名をコピーしてください。後で使用します。 このステップが完了すると、コンソールに表示されている名前で IAM ロールが作成されます。 Next を選択します。 Send to CloudWatch Logs チェックボックスを選択します。 ロギングは、実験のタイミングとアプリケーションの動作を関連付けるのに役立つため、Amazon CloudWatch 統合を設定しましょう。 そのためには、まず CloudWatch にロググループを作成する必要があります。 ロググループを作成するには、 CloudWatch ドキュメント の手順に従ってください。 テンプレート作成の AWS FIS タブで、Logs セクションの Browse オプションを選択し、右側の Refresh ボタンを使用します。 作成したロググループ名を検索します。 Log version として Version 2 を選択します。 次のスクリーンショットでは、ロググループ名として aws-fis-elasticache を使用しています。 View Permission details ボタンを選択し、Amazon CloudWatch ロギングに必要な権限ポリシーをコピーしてメモ帳に貼り付けます。 後のセクションで、ステップ 19 で作成されたロールを更新するために使用します。 Next を選択します。 テンプレートを確認し、 Create experiment template を選択します。 Amazon CloudWatch 用の AWS IAM ロールの編集 テンプレートが作成されたら、CloudWatch ロギングに必要な権限を持つように、作成した IAM ロールを編集する必要があります。 IAM コンソールを開き、IAM ロールを選択すると、このロールに 2 つのポリシーがアタッチされていることがわかります。 FIS-Console-CWLogging-XXXX という名前で作成されたポリシーを編集し、前述のポリシー JSON ドキュメントをコピーして、ポリシーを保存します。 AWS FIS 実験の実行 AWS FIS コンソールページで、ステップ 2 で作成したテンプレートの右上にある Start experiment を選択し、開始操作を続行します。 モニタリングとログの確認 実験の状態が Running 状態になることを確認できます。 CloudWatch ログの送信先リンクを選択して、先ほど作成したロググループ aws-fis-elasticache の CloudWatch ログを開きます。 ログイベントには、 log_type:action-start のログエントリが 1 つ表示されます。 これは、実験が実際にアクションを実行している、または有効になっている時刻を示しています。 Amazon ElastiCache コンソールに移動すると、クラスターのステータスとノードが以下のように Modifying 状態になっていることが確認できます: また、ノード elasticache-chaos-test-cluster-001 のロールが primary から replica に変更されていることにも気づくでしょう。 これは、以下に示すように Amazon ElastiCache で公開されたイベントからも確認できます: フェイルオーバーは、ロググループ aws-fis-elasticache の AWS FIS ログによると、アクション開始時刻から数秒以内に完了しました。 Amazon ElastiCache クラスターのログを有効にしている場合、他のノードがプライマリノードとの接続の問題を示すログも確認できます。 5 分間 (テンプレートの Action ページのデフォルト設定) が経過すると、AWS FIS ログに log_type:action-end が表示されます: Amazon ElastiCache コンソールでは、ノードとクラスターのステータスが Available と表示されます。 耐障害性の検証: 確認すべきポイントと対応方法 耐障害性テストの実行は最初のステップに過ぎません。 本当の価値は、フェイルオーバー中に何が起こったかを理解し、アプリケーションがそれを適切に処理できることを確認することにあります。 ElastiCache イベントの理解 ElastiCache イベントは、フェイルオーバー中のクラスターの健全性を可視化します。 確認すべき主要なイベントは以下の通りです: Recovering cache nodes は、影響を受けたノードが復元中であることを示します Finished recovery for cache nodes は、元のノードがレプリカとしてクラスターに再参加したことを確認します フェイルオーバープロセス全体は、Multi-AZ 構成の場合、通常数秒以内に完了します クラスターログの分析 ElastiCache クラスターでエンジンログを有効にしている場合、フェイルオーバー中の詳細な接続動作を確認できます: レプリカがプライマリノードの障害を検出した正確なタイミング 「Connecting to MASTER」や「Replica has started synchronizing with the primary」などのメッセージは、リカバリプロセスを示しています 同期成功のメッセージは、データの一貫性が維持されたことを確認しています アプリケーションの耐障害性テスト ElastiCache はフェイルオーバーを自動的に処理しますが、この期間中のアプリケーションの動作が重要です。 接続処理: 適切に設計されたアプリケーションでは、短時間の接続エラー (5 〜 15 秒) の後に自動的に再接続されるはずです。より長い停止時間は、接続プールの設定やリトライロジックに問題があることを示しています。 キャッシュミス時の動作: アプリケーションがデータベースに過負荷をかけることなく、適切にフォールバックすることを確認してください。データベースのクエリレートは一時的に増加しますが、管理可能な範囲に収まるべきです。 パフォーマンスの低下: フェイルオーバーの前、最中、後のレスポンスタイムを測定してください。耐障害性のあるアプリケーションでは、フェイルオーバー中にレイテンシーが 50ms から 200ms に増加し、その後正常に戻ることがあります。1 秒を超えるスパイクが発生した場合は、接続タイムアウトとリトライの設定を調査する必要があります。 Amazon ElastiCache でのアプリケーション動作の監視の詳細については、 Monitoring best practices with Amazon ElastiCache for Redis using Amazon CloudWatch を参照してください。 まとめ この記事では、AWS Fault Injection Service (AWS FIS) を使用して Amazon ElastiCache で耐障害性テストを実装する方法を学びました。 このテストにより、キャッシュ戦略の弱点を事前に特定し、フェイルオーバーメカニズムを検証し、実際のインシデントが発生する前に適切な縮退動作を確保できます。 これらの実験を実行することで、チームはインシデント対応手順を練習し、キャッシュ障害がシステムアーキテクチャ全体に与える連鎖的な影響を理解できるようになります。 Amazon ElastiCache 全般のベストプラクティスについては、 ElastiCache のベストプラクティスとキャッシュ戦略 を参照してください。 クリーンアップ このウォークスルーのために新しい Amazon ElastiCache クラスターを作成した場合は、 ElastiCache でのクラスターの削除 ドキュメントの手順に従ってクラスターを終了し、コストを最適化できます。 また、 実験テンプレートを削除する ドキュメントの手順に従って AWS FIS 実験テンプレートを削除することもできます。 IAM ロールの削除と CloudWatch ロググループの削除については、それぞれ IAM ロールの削除 (コンソール) と CloudWatch Logs の削除 のドキュメントを参照してください。 この記事の翻訳は Solutions Architect の堤 勇人が担当しました。 著者について Raunak Gupta Raunak は AWS のシニアデータベースソリューションアーキテクトです。AWS に 6 年以上在籍しており、Aurora と RDS オープンソースの専門家でもあります。17 年以上の実務経験を持ち、エンタープライズのお客様にデータベースの運用パフォーマンスとデータベースのベストプラクティスに関する技術支援を提供しています。

はじめに｜なぜ“AI × DesignOps”なのか？ プロダクトが成長すればするほど、ビジュアルアセットの需要は指数関数的に増えていきます。しかし、デザイナーの数は（悲しいことに）指数関数的には増えません。 従来のイラスト制作は個人のスキルに依存しやすく、結果として品質のバラツキや制作スピードが開発ベロシティを阻害する「 デザイン負債（Design Debt） 」を生み出していました。DesignOps の本質は、デザインを「一点物のマニュアルアート」から「再現可能なシステム」へと昇華させることにあります。 私たちは今回、AI を単なる「便利な魔法の筆」ではなく、一貫性のあるデザインシステムを支える「 レンダリングエンジン 」として再定義する検証を行いました。 DesignOpsとは？ 「DesignOps（デザインオプス）」という言葉、デザイナー以外にはまだ少し耳慣れないかもしれません。 簡単に言うと、 DesignOps は 「 デザイン版の DevOps 」です。 属人的になりがちなデザイン業務をプロセスとして整理し、担当者が変わってもチームとして一定の品質をデプロイできる状態を目指す考え方です。 今回の取り組みでは、生成 AI を「クリエイティブな遊び」としてではなく、プロダクトのコードベースの一部のように運用できるかを検証しました。特にエンジニア主体の組織においては、デザインも「 ロジックとして扱えるか 」が、持続可能な運用の鍵になります。 プロジェクトの背景：Unlimited App で直面した「成長の痛み」 Unlimited App ではこれまで、プロダクトデザイナーがイラストの世界観設計から品質の最終調整まで、いわば「職人のこだわり」をもって一貫して担ってきました。しかし、プロダクトが成長し、機能追加やコンテンツ拡張が加速するなか、必要とされるイラストの量と展開範囲は、私たちの想像を超えるスピードで拡大していきました。 https://kinto-jp.com/unlimited/app/ その過程で、個人の努力だけではカバーしきれない「 構造的なボトルネック 」が浮き彫りになってきたのです。 工数の比例増加 ：表現を都度最適化する運用では、制作アセット数に比例して工数も積み上がっていく（まさに O(n) の世界です）。 再現性の設計難度 ：クオリティの判断が個人の経験値に依存しやすく、「なぜこれが正解なのか」という基準を仕組みとして残しづらい。 属人的なバランス調整 ：スピードと完成度のトレードオフを、常に個人の「さじ加減」で調整し続けなければならない。 これらは決して個人のスキルの問題ではなく、プロダクトが次のステージへ進むために解決すべき「 システム上の課題 」でした。 そこで生まれたのが、「 イラスト制作を個のスキルに依存する形から、再現性のある設計へとリファクタリングできないか？ 」という問いです。私たちはこの問いに対し、生成 AI という強力なエンジンを DesignOps のプロセスに組み込むことで、持続可能な制作体制の構築に挑みました。 ※ [ ちょこっと技術解説 ]： O(n) とは？ エンジニアがよく使う「計算量」を測る指標です。ここでは「描くイラストの枚数（ n ）」が増える分だけ、「制作時間」も正直に増えていくという 線形の現実 を指しています。 つまり、「 単なる「魔法」ではなく、10 倍の依頼が来たら 10 倍の工数が必要になる 」という、デザイナーにとっては少し切ない、そしてエンジニアにとっては「今すぐ最適化（リファクタリング）したい！」と血が騒ぐ状態のことです。 今回の検証アプローチ｜“AIに寄せる” vs “AIを寄せる” AI を活用する際、戦略は大きく 2 つに分かれます： AI に寄せる（AI-Native Approach） AI が得意な表現（原生スタイル）をそのまま受け入れ、効率を最大化する。「AI っぽさ」を味方につける手法です。 AI を寄せる（Brand-Centric Approach） 独自のブランドアイデンティティに基づき、AI の出力を厳格に制御する。 Unlimited App はすでに確立された世界観を持つプロダクトです。そのため、前提条件として「AI を寄せる」 アプローチを選択しました。これは、プロンプトを単なる命令文ではなく、ブランドの 「デザイン・トークン（Design Tokens）」 として定義し、AI という不確実な実行環境において 「決定論的な出力（Deterministic Output）」を目指す、エンジニアリング的な挑戦でもあります。 イラスト標準化の設計思想とプロンプトアーキテクチャ 「AI なら、プロンプトひとつで何でも描いてくれるのでは？」——そんな期待は、運用フェーズに入った瞬間に崩れ去ります。実用的な DesignOps において、プロンプトは単なる「魔法の呪文」ではありません。明確な設計意図を AI へ伝えるための、厳密な「 インターフェース 」であるべきです。 標準化プロセスの構築にあたり、筆者は下図のような 7つのステップ を策定しました。ビジュアル定義の抽出（Step 1）からリファレンスの整理（Step 4）までは、いわば「 視覚的な仕様書 （ Visual Spec ）」を書き上げる、設計の根幹を支えるフェーズです。 Step 1〜4：プロンプトを「エンジニアリング」するための前処理 Step 1｜ビジュアル定義の抽出（Extracting Visual Tokens） 最初に取り組んだのは、デザインシステムとの整合性チェックです。2.5D の立体感、余白の持たせ方、低コントラストな配色……。これらを言語化する工程は、後に解説する 「 Style Tokens （ スタイル定数 ）」 の基盤となります。 Step 2｜イラスト用途の分類（Defining the Scope） 生成 AI の活用範囲を「クリエイティブな表現」ではなく、「 UX を補助するインフォグラフィック 」 と定義しました。目的を限定することで、維持すべき「再現性」と、AI に任せるべき「表現幅」の境界線が明確になります。 Step 3 & 4｜リファレンスの構造解体（Deconstructing References） 大量のリファレンスを収集し、「好き嫌い」という感性ではなく、構図や影の強度といった「 Visual Spec（視覚仕様） 」として分解・整理しました。「なんとなく似ている」を「仕様通りである」に変えるための、最も泥臭く、かつ重要なリサーチ工程です。 この Step 1〜4 の本質は、「 AI に依存しない設計構造を人間側で作る 」 ことにあります。 このプロセスで最もエキサイティングであり、かつ重要なのが Step 5 の「プロンプト作成」 です。ここを単なる「作文」にせず、 エンジニアリング的に構造化された工程 として設計しました。 具体的には、プロンプトを以下の 2 層構造（Layered Architecture） として定義しています： Part 1：Style Tokens（スタイル定数層） 線画の太さ、立体感、陰影のルール、配色など、プロダクトの DNA を定義します。「何を描くか」に依存しない、 再利用可能な Constant（定数）レイヤー です。 Part 2：Content Variables（コンテンツ変数層） 「車」「人物」「スマホを持つ手」など、画面ごとに差し替え可能な Dynamic Variable（動的変数）レイヤー です。 この 「 スタイルとコンテンツの解耦（Decoupling） 」 こそが、DesignOps 視点での解決策です。これにより、「何を描いても同じトーンで出力される」という、デザイナーにとっての聖杯（Holy Grail）を目指しました。 ツールごとに異なる「Prompt の最適解」 検証を進める中で面白いことが分かりました。AI ツールごとに「プロンプトの癖」が全く違うのです。以前は同一のプロンプトで比較していましたが、現在は「構造（Part 1 / Part 2）は共通、実装（実際の記述）は各ツールに最適化」 という方針に切り替えました。 「プロンプトを共有する」のではなく、 「プロンプトを設計するインターフェース（ルール）を共有する」。この方が、ツールの進化に柔軟に対応できる持続可能な仕組みになります。 徹底検証：生成 AI 3 社の「性格診断」—— イラスト標準化の最適解を探る 2025年10月時点の Midjourney 検証 まずは、2025年10月に行った Midjourney（V7）での検証結果です。 当時の出力は、視覚的な完成度が非常に高く、一枚絵としての魅力は群を抜いていました。 しかし、標準化という観点では、いくつかの課題が見えてきました。 装飾的な要素が多く、情報量がやや過剰 構図がダイナミックで、並べた際の統一感が出にくい ブランドトーンよりも「生成AIらしさ」が前面に出る傾向 つまり、 創造性は高いが、制御性が低い。 この特性はクリエイティブ用途には適していますが、UI内で量産・運用するインフォグラフィック用途には不向きであると判断しました。 ChatGPT / Gemini へのシフト Midjourney との比較を経て、検証の軸を「表現力」から「再現性」へとシフトしました。 同一のビジュアルリファレンスと構造化プロンプトを用い、ChatGPT および Gemini で出力を比較しました。 この時点で明確になったのは、 ChatGPT は構図の安定性が高い Gemini はクリーンだが、再解釈が入る傾向がある という違いでした。 最新検証：観点別比較 プロンプトの構造を定義したところで、次なるステップは「どの実行エンジン（AI モデル）が最も安定して仕様通りに動くか」のベンチマークテストです。私たちは、構図・人物・色彩・命令遵守性の 4 つの観点から、プロダクト運用への適性を評価しました。 ① 構図の安定性—— UI に馴染むか？ インフォグラフィックにおいて、余白と主体のサイズ感は「UI の整合性」に直結します。 ChatGPT は視点・余白・被写体のバランスが安定しており、複数枚を並べた際の一貫性が高い結果となりました。 一方 Gemini は、微妙な視点変更や背景処理の差異が発生しやすく、量産時の揺らぎがやや大きい傾向が見られました。 ② 人物表現の精度—— 意図が伝わるか？ 「シートベルトを締める」「スマホを見る」といった具体的な動作の正確さを検証しました。 人物の顔パーツ・視線・身体バランスにおいて、ChatGPT は安定したクオリティを維持しました。 Gemini は柔らかいトーンで描写される一方、表情や骨格の一貫性に若干のばらつきが見られました。 ③ 用色とブランド整合性 ChatGPT は指定した色調レンジを忠実に守る傾向が強く、ブランドトーンとの整合性が高い結果となりました。 Gemini は自然なグラデーション処理を行う反面、色相・彩度が微妙に変化するケースがあり、厳密なトーン統制には追加調整が必要でした。 ④ 命令遵守性（Instruction Following）—— 仕様書通りに動くか？ 最も大きな差はここでした。 ChatGPT はプロンプト構造（Part 1 / Part 2）をほぼそのまま出力に反映する傾向が強く、設計思想と出力結果の対応関係が明確でした。 Gemini は意図を解釈し、最適解を“再構成”する挙動が見られ、創造性は高いものの、決定論的制御はやや難しいという印象です。 ※ 正密に Gemini が過度な再解釈を試みるからこそ、私たちは Part 1（定数層）において、より厳密なビジュアルのガードレールを定義し、封鎖（Lockdown）する必要があるのです。 各ツールの本性：創作のパートナーか、信頼の実行エンジンか Midjourney：気分屋な天才アーティスト 2025 年 10 月時点の検証では、Midjourney は 圧倒的な 「 映え 」を誇りました。一枚絵としての完成度は素晴らしいのですが、標準化という観点では少し「個性が強すぎ」ました。 情報量が多すぎて UI の邪魔をしてしまう。 構図がダイナミックすぎて、並べた時に統一感が出にくい。 つまり、「 クリエイティブな爆発力はあるが、規律を守るのが苦手なタイプ 」です。 Gemini：再解釈を試みるクリエイティブ・ディレクター Gemini 3 Flash などの最新検証では、非常にクリーンな UI イラストを生成してくれますが、時折「自分の色」を出したがる傾向があります。 構図や余白が毎回少しずつズレる「自由奔放さ」。 プロンプトを忠実に守るというより、「 意図を汲み取ってリミックスしてしまう 」挙動が見られました。これは創作には良いですが、量産プロセスでは「予測可能性」を下げる要因になります。 ChatGPT (DALL-E)：仕様書通りに動くシニアエンジニア 対照的に ChatGPT は、 プロンプトの構造をそのまま出力に反映する能力 （ Instruction Following ）が極めて高いことが分かりました。 構図が安定し、用色も保守的でルール化しやすい。 まさに DesignOps における 「 信頼できる実行エンジン 」 です。 「イラストを作る（Make）」ツールではなく、「運用する（Ops）」ツール としての適性が最も高いと判断し、現在は ChatGPT を中心に検証を進めています。 ※ もちろん、表現の幅や偶発的なひらめきという点では、Midjourney や Gemini に軍配が上がる場面もあります。 実装結果：Unlimited App で何が変わったのか？ 確立した標準スタイルは、現在 Unlimited App 内の「車種別イラスト」や「レベル選択カード」などで試験的に運用されています。「 AI で 8 割のベースを生成し、人間が最後の 2 割を整える 」というフローにより、制作スピードと一貫性が（ついに！）両立し始めました。 しかし、この取り組みは Unlimited App という「実験場」だけで完結するものではありません。私たちが構築したプロンプトの 2 層構造は、いわばデザインの「共通プロトコル」です。将来的には、「スタイル定数（Part 1）」というコンフィグを各ブランドの DNA に合わせて差し替えるだけで、社内のあらゆるプロダクトやサービスへこの仕組みを横展開（スケール）させていくことを目見据えています。プロダクトを跨いで「一貫性のあるビジュアルを即座にデプロイできる」状態——これこそが、私たちが目指す真の DesignOps の姿です。 やってみて分かった課題 数ヶ月の検証で分かったのは、プロンプトには「 賞味期限（Prompt Rot） 」があるということです。ツールのアップデートにより、昨日まで動いていた魔法の言葉が、今日には効かなくなる。 そのため、プロンプトを一度作って終わりにするのではなく、 継続的にリファクタリングしていく前提の設計 が必要です。今後は、これらのメンテナンスを自動化する「AI Agent 的なアプローチ」も視野に入れています。 まとめ：AI × DesignOps は何を変えうるのか 今回の検証を通じて確信したのは、生成 AI は単なる「魔法」ではなく、 DesignOps を再設計するための強力なトリガー であるということです。 標準化とは、自由を奪うことではありません。むしろ、「 どこを固定し（Constants）、どこを柔軟にするか（Variables） 」を定義することで、変化の激しいプロダクト開発においてクリエイティブな安定走行を可能にする行為です。 DesignOps は、デザインを「属人的な手癖」から「再現可能なプロセス」へと拡張します。この取り組みが、皆さんのプロダクトにおけるクリエイティブ運用のヒントになれば幸いです。

このブログ記事は、AWS ソリューションアーキテクトの都築 了太郎と AWS テクニカルカスタマーソリューションマネージャ井元 祐希が執筆し、住信 SBI ネット銀行様が監修しています。 住信 SBI ネット銀行株式会社 （以下、住信 SBI ネット銀行）は、 Amazon Bedrock AgentCore を中核とした AI エージェントの機能を活用し、AI 銀行サービス「NEOBANK ai」のベータ版を公表いたしました。 「NEOBANK ai」は、アマゾン ウェブ サービス (以下、AWS) の生成 AIサービスを活用した革新的な銀行サービスで、「 d NEOBANK 住信 SBI ネット銀行アプリ 」内において、自然言語による対話を通じた銀行手続きを可能にします。本ブログでは、住信 SBI ネット銀行の「NEOBANK ai」による新たな顧客体験向上への挑戦とAWS の先進技術について、活用方法の解説を交えてご紹介します。 新たな顧客体験の創出に向けた挑戦と、求められるシステム要件 住信 SBI ネット銀行が「NEOBANK ai」の開発に着手した背景には、生成 AI の技術革新によってデジタル金融における新しい UI/UX の可能性が広がり始めていることがあります。“画面遷移を辿りながら操作する”従来の体験から、ユーザーが“やりたいこと（意図）を伝えるだけで必要な手続きが立ち上がる”体験へと移行していくことを、住信 SBI ネット銀行は将来のパラダイムシフトとして予見していました。 その未来像を先取りする形で、金融サービスにおける次世代インターフェースの実現を目指した意欲的な取組が「NEOBANK ai」です。日常的に利用される振込、明細確認、各種手続きといった領域においては、メニュー階層をたどる従来型 UI だけでは、ユーザーの意図に沿ったスムーズな体験を提供しにくい場面があります。住信 SBI ネット銀行では、こうした課題に対して、ユーザーの意図に応じて必要な確認項目や安全な手順を動的に提示できるアプローチが、より直感的な体験につながると考えました。 その実現を支える UI 概念のひとつとして、住信 SBI ネット銀行は主体的に「ジェネレーティブ UI」を採用しています。 「NEOBANK ai」では、アプリ内でのテキスト入力に加え、音声・画像を含むマルチモーダルなインプットを受け取り、AI エージェントが意図を解釈したうえで、照会・分析・手続き案内に必要な“その場で立ち上がる UI”を生成します。これにより、ユーザーは直感的かつ効率的に銀行サービスを利用できる体験の実現を目指しました。 本 AI エージェント技術活用に向けた主要なシステム要件として、以下4点ありました。 1. スケーラブルな AI エージェント実行基盤 数百万ユーザーを抱える大規模アプリケーションにおいて、スケーラブルかつ安定した AI エージェント実行基盤の構築が求められていました。ピーク時には多数のユーザーが同時に AI エージェントとやり取りすることが想定されるため、自動スケーリング機能を備え、負荷変動に柔軟に対応可能な基盤が不可欠でした。 2. 実行モデルを切り替えられる柔軟性 日々新たな AI モデルが登場する中で、タスクごとに品質・コスト・パフォーマンスを最適化していく必要があると考えました。そのため、特定のモデルに依存するのではなく、要件に応じて実行対象のモデルを柔軟に切り替え可能なアーキテクチャが求められていました。 3. AI エージェントの可視性 開発環境での検証および本番環境での運用において、AI エージェントの実行プロセスがブラックボックス化することを防ぎ、説明可能性を確保することを重要視していました。AI エージェントが顧客からの自然言語入力をどのように解釈し、どのようなプロセスを経て応答を生成したのかを把握できるよう、実行プロセスの可視性を高める必要がありました。 4. AI セキュリティ対策 社外向けの大規模サービスとして安心・安全な AI 活用を実現するため、AI サービス特有の攻撃的なプロンプトや、銀行取引と関連性のないトピックを検知・制御する仕組みが必要とされていました。これにより、不適切な利用を防止し、セキュリティと信頼性を確保する必要がありました。 AI エージェントシステムのアーキテクチャ 住信 SBI ネット銀行が構築した「NEOBANK ai」では、前述の 4 つのシステム要件を満たすため、AWS の生成 AI をはじめとする複数のサービスを組み合わせたアーキテクチャを採用しています。本セクションでは、各要件に対応するアーキテクチャ上のポイントと、採用した AWS サービスの役割をご紹介します。 1. スケーラブルな AI エージェント実行基盤 住信 SBI ネット銀行が構築した「NEOBANK ai」において、AI エージェント実行基盤の要件を実現するため、AI エージェント機能をスケーラブルに実行可能なマネージドサービスである Amazon Bedrock AgentCore Runtime が採用されています。フロントエンドからのリクエストは、 Amazon API Gateway を経由してセキュアに受け付けられます。API Gateway の後段では、AWS Lambda がリクエストの認証・前処理および Amazon Bedrock AgentCore Runtime へのルーティングを担います。Amazon Bedrock AgentCore Runtime は負荷に応じた自動スケーリングを備えており、ピーク時に多数のユーザーが同時に AI エージェントとやり取りする場合でも、安定した応答を維持できます。この構成により、利用状況に応じた柔軟なスケーリングと高いコスト効率を両立しています。 2. 実行モデルを切り替えられる柔軟性 Amazon Bedrock AgentCore の活用により、さまざまな基盤モデルへのアクセスが可能となり、必要に応じて外部モデルを統合できる柔軟性を確保しました。この設計により、将来的なモデルの技術進歩や、実行タスク・コスト・性能といったビジネス要件の変化にも対応でき、実行モデルを柔軟に切り替え可能なアーキテクチャを実現しています。「NEOBANK ai」では、このモデル切り替えの柔軟性を活かし、処理の特性に応じて以下異なる AI モデルを使い分けています。 ž意図理解・行動決定処理：お客さまの発話から意図を理解し、振込用 UI を描画するといった行動を決定する処理では、チャットボットとしての素早い応答速度を重視し、軽量・高速な推論に適した AI モデルを使用しています。 žガードレール判定処理：不適切な応答を防止するためのガードレール機能では、判定精度を優先し、高精度な分類・判定に強みを持つ AI モデルを採用しています。 このように、モデルの推論性能と生成速度のバランスを用途ごとに最適化することで、素早い応答速度と高い回答品質の両立を実現しています。 3. AI エージェントの可視性 また、AI エージェントの可視性要件を満たすために Amazon Bedrock AgentCore Observability を採用しています。これにより、AI エージェントがお客さまからの自然言語入力をどのように解釈し、どのようなプロセスを経て応答を生成したのかについて、エンドツーエンドの包括的な可視性を確保しています。具体的には、開発環境における検証・デバッグだけでなく、本番環境における品質監査や性能傾向の評価にも活用されており、AI エージェントの実行プロセスがブラックボックス化することを防いでいます。 4. AI セキュリティ対策 社外向けの大規模サービスとして安心・安全な AI 活用を実現するため、複数のレイヤーでセキュリティ対策を講じています。 まず、AI 固有の攻撃に対する対策として、プロンプトインジェクションや銀行取引と関連性のないトピックを検知・制御するガードレールを実装しています。前述のとおり、このガードレール判定には高精度な分類・判定に強みを持つ AI モデルを採用し、検知精度を高めています。 加えて、API Gateway を通過したリクエストに対し、Amazon DynamoDB を用いてクライアントごとのレートリミットを設定・制御することで、過剰なリクエストによるサービスへの影響を防止しています。また、お客さまから入力される自然言語情報の保存にも DynamoDB を活用し、監査証跡の確保に役立てています。 住信 SBI ネット銀行株式会社 執行役員渡邊 弘様からのコメント 「当社は、顧客体験の革新を最重要課題として位置づけ、生成 AI 技術を活用したお客さま向けサービスの高度化に継続的に取り組んでまいりました。その取組の一環として、このたび Amazon Bedrock AgentCore を採用し、NEOBANK ai を通じて、より質の高いサービスをお客さまに提供してまいります。特に、従来のルールベースの仕組みに代えて AI エージェントを活用することで、お客さまとの対話がより自然で、付加価値の高いものになることを期待しています。 セキュリティや可用性といった金融機関として不可欠な要件を満たしながら、同時にイノベーションを実現できる AWS のプラットフォームは、当社のデジタルトランスフォーメーションを推進するうえで欠かせないパートナーです。 今回のシステム構築を通じて得られた知見やノウハウは、今後のさまざまなサービス開発にも積極的に活かしていく所存です。今後も、AWS の豊富なマネージドサービス群と進化を続ける生成 AI 技術を活用し、お客さまに真に価値あるデジタル金融サービスを迅速に提供し続けることで、金融サービスのイノベーションをリードしてまいります。」