このブログ記事は、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 技術を活用し、お客さまに真に価値あるデジタル金融サービスを迅速に提供し続けることで、金融サービスのイノベーションをリードしてまいります。」

はじめに 昨年の 2025年12月に RevComm では Hack Day 2025 という社内イベントを開催しました。今日はその内容について振り返ります。 何をやったの？ お題 private-isu というリポジトリを題材に、Webアプリケーションのパフォーマンスチューニングに取り組みました。 github.com 開催地は RevComm オフィスが入っているビルのレンタルスペースを使用しつつ、遠方のメンバーなども参加できるようオフラインとオンラインを併用した形式で開催しました。 様々なチームや担当領域のメンバーが参加できるよう、下記の3つの言語の中から各々のメンバーが使いたい言語を選択した上で、一定人数ごとにグループを分けて取り組みました。 Python Go TypeScript (Node.js) 準備 まずは private-isu の公式マニュアルや 達人が教えるWebパフォーマンスチューニング の書籍を参考に作成されたハンズオン資料を確認しつつ、ログの確認方法やベンチマークの実行方法などを全体で確認しました。 github.com 最初の例としてテーブルへのインデックスの設定を行いました。 ab コマンドなどを活用してベンチマークを実施し、パフォーマンスが改善されていること確認していく一連の手順をハンズオン形式で学びました。 実践 ハンズオン形式で方法や手順を確認した後は、各自でグループに分かれてパフォーマンスチューニングに取り掛かりました。 筆者は普段はフロントエンド開発を行なっているため、 TypeScript で取り組みました。private-isu ではTypeScriptにおいては Hono とMySQLをベースにWebアプリケーションが実装されています。 まずは N+1 問題の解消やその他、細かな改善などを取り組んでみることにしました。都度、ベンチマークを実行して意図した通りにパフォーマンスが改善されていることを確認しながら作業を進めました。 成果発表 最後に各グループごとに成果の発表を行いました。グループごとに採用している言語や実践したチューニング内容などが異なっており、参考になりました。 まとめ 筆者は日頃、フロントエンド開発を中心に行なっており、サーバーサイドにおけるパフォーマンスチューニングに携わる機会が少ないため、こういった実践を通して安全にパフォーマンスチューニングを体験することができて、とても有意義に感じました。 また、今回題材として活用した private-isu はとてもよくできていると感じました。private-isu を題材にパフォーマンスチューニングに取り組むことで、ベンチマークの計測方法やパフォーマンスチューニング、ログの閲覧方法など様々なことを学ぶことができました。もし社内イベントの企画などを検討されている場合は、題材として検討されてはいかがでしょうか。

こんにちは。ファインディのPlatform開発チームでSREを担当している 原 です。 ファインディでは、普段私たちが開発しているファインディのプロダクトの裏側や、開発メンバーが日々どのように働いているのかをお伝えするために、Findy Tech Talkという技術系のオフラインイベントを開催しています。 今回は、そのイベントの第二弾となる「Findyのサービスを支える、横断SREチームのマネジメントと技術の挑戦」を開催しまして、その当日のそれぞれの登壇内容について書いていこうと思います。 findy-inc.connpass.com 今回のイベントでは、Platform開発チーム(以下、SREチーム)が登壇し、チームのミッションや普段の業務内容について各々の立場から発表していきました。 本記事では、イベントでの登壇内容をベースに「横断SREチーム」の立ち上げ戦略や、AI(Devin/Claude Code)による運用自動化、未経験からのキャリア形成など、登壇者自身からダイジェスト版にてお届けしていきます！！ 登壇内容 SREチームをどう作り、どう育てるか ― Findy横断SREのマネジメント Platform SREの軌跡：Terraform汎用化とAIで進めた「インフラ基盤」の構築と、その成果 フリーランスからSREへの転身 SREとしての第一歩：3週間の活動報告 BEから未経験でSREへ：オンボーディングとトイル改善の記録 まとめ 登壇内容 SREチームをどう作り、どう育てるか ― Findy横断SREのマネジメント speakerdeck.com SREチーム サブマネージャーの 安達(@adachin0817) です。Findyのサービスを横断的に支えるSREチームの立ち上げから現在までの3年間における「技術的な挑戦」と「マネジメントのリアルな葛藤」の2つについてお話させていただきました。 SREチームは、この3年間で多岐にわたる基盤整備と改善を実行し、着実に土台を整えてきました。 基盤のコード化・標準化 全環境のTerraform import化や、GitHub Actionsのテンプレート化を実施。 オブザーバビリティと信頼性の向上 Datadogの導入や、全サービスにおけるSLI/SLOの計測。 セキュリティの強化 Shisho Cloud(CSPM)やTakumi(SAST/DAST)を導入し、SOC2 Type2への対応。 開発体験の向上 開発環境の改善に加え、AI(Devin等)を活用した運用・構築の自動化など、先進的な取り組みも行う。 また、技術面だけでなく、チームビルディングやタスク管理の苦労、そしてその解決策についてもまとめていきました。 サブマネージャーとしてはマネージャーの右腕となり、メンバーへの技術指導・リスクマネジメント（過稼働の防止など）・ロードマップの策定を担っています。 チーム結成当初は、ビジョンやミッションが抽象的だったり、誰がどのサービスの責任を持つかが不明確で属人化しやすいといった課題がありました。 そこで「SREよもやま会」を実施してチームの方向性やマインドセットを議論し、GitHubのカンバンやロードマップでタスクと優先順位を可視化・管理する改善を行いました。 去年から新サービスが増加し続ける中で、SREチームだけで全ての工数や問い合わせを抱え込むことには限界が見えてきました。 そこで今後は、SREチームが全てを巻き取るのではなく、各部署内でSREの知識や運用方法を展開・定着させるEnabling(SRE社内留学制度)を推進する方針へとシフトしていきます。 具体的には、ドキュメントや動画を用いた学習、Sandbox環境での実践（SRE社内留学制度）などを通じて各部門の自律性を高め、組織全体としてスケールできるSRE体制への成長を目指しています。 去年のチームの振り返りについては次のTechBlogに記載されていますので、ぜひご覧ください。 tech.findy.co.jp Platform SREの軌跡：Terraform汎用化とAIで進めた「インフラ基盤」の構築と、その成果 speakerdeck.com 原からは、「Platform SREの軌跡：Terraform汎用化とAIで進めた「インフラ基盤」の構築と、その成果」と題して発表しました。 入社してから1年間で行った取り組みの中から、Terraform汎用モジュールとDevinを用いたAI活用でのトイル削減についてピックアップして紹介しました。 昨年ファインディがリリースした新サービスについて、品質を保ちつつスピード感を持ってインフラ環境構築を行う工夫を紹介しました。 SREチームが担当したサービスは次のとおりです。 Findy Conference Findy AI+ Findy Team+ AIチャットボット Findy ID Findy Insights アーキテクチャ壁打ちAI by Findy Tools 品質とスピードの両立を目指した「汎用モジュール」では、ファインディのプロダクトで頻繁に利用するリソースをモジュール化して、モジュールごとにパラメーターを指定すれば環境が立ち上がる仕組みを整備しています。 汎用モジュールを使ったインフラ環境構築は、今では開発者自身に担当してもらうこともあり、SREチームのEnabling活動の一環となっています。より構築しやすい汎用モジュールにアップデートし続けていきます。 詳しい内容は、次のTechBlogにも記載されています。 tech.findy.co.jp tech.findy.co.jp もう一つ、Devinを使ったAI活用によるトイル削減についての事例を複数紹介しました。 例えば、SREチームではコーポレートサイトの運用も担当しており、会社概要や利用規約の変更依頼が来ることがあります。以前はソースコードを直接編集していましたが、現在はこれらの作業をDevinに任せています。 Slackのワークフローから申請するとDevinが自動起動する仕組みを整備しました。事業部からの依頼をワークフロー経由で受け付けることで、SREチームはPRレビューのみに注力でき、工数削減を実現しました。 このように、汎用モジュールやAI活用でのトイル削減について紹介しました。 発表の最後では、ログ基盤の整備やAIOpsなど今後の取り組みについても触れました。これからも信頼性向上に向けたプラクティスを続けていきます。 フリーランスからSREへの転身 SREとしての第一歩：3週間の活動報告 speakerdeck.com SREチームの もずます(@mozumasu) です。 フリーのインフラエンジニアからSREへの転身を果たし、入社後3週間の活動報告をさせていただきました。 フリーランスから正社員になって変化したことや、お気に入りの自動化の仕組みなどを紹介しました。 まず現状の把握として、Findy ToolsのTerraform構成に触れました。現在は汎用モジュールがなく、environmentsとmoduleで管理しており、環境ごとのtfファイルでmoduleを呼び出す構成になっています。 運用を楽にするための自動化も進んでおり、次のようなツールが組み込まれています。 Renovate: 依存関係の自動アップデート tfcmt: PRに対してTerraform planの結果を自動コメント Trivy: 脆弱性スキャン この3週間で、主に2つの大きな取り組みを行いました。 SLO定点観測会の改善 SREチームと各プロダクトのエンジニアで、隔週で「SLO定点観測会」を実施しています。 これはDatadogやGrafanaを見ながらサービスの状態（SLO、ステータスコード、レスポンスタイム、APM、インフラリソースなど）を確認し、SLI/SLOの達成状況を把握する会です。 以前は、ダッシュボードの画像をGeminiで画像解析し、その結果をNotionに自動記載するという運用をしていました。 しかし、この運用には次の課題がありました。 画像から分かる情報が冗長に記載されてしまう 重要な情報が埋もれやすい 解析結果が誤っていることがある 議事録の準備に工数がかかる そこで手法を見直し、現在では「注視するべき部分（項目）のみを手動で記載する」というシンプルな形へと変更しました。 DatadogのダッシュボードをClaude Codeで作成 現状、SLO、Synthetic Testing、Slack通知などはTerraformで管理していますが、ダッシュボードのレイアウトなどはTerraformの管理外になっています。既存のダッシュボードをエクスポートすると約2000行のJSONになり、非常に可読性が悪いという印象を受けました。 そこで今回、Claude Codeを使ってこれを解析し、HCL（Terraform）化を試みてみました。 結果として、HCLにしても約1500行と行数自体はそこまで劇的に減りませんでしたが、HCLであれば変数の参照ができるようになるため、ダッシュボードをコード管理するならHCL化するメリットは十分にあると感じました。 入社からの3週間で、Datadogの設定やSLO定点観測会の改善など、SREとしての第一歩を踏み出すことができました。 今後はセキュリティ周りの改善などにも力を入れていく予定です。 BEから未経験でSREへ：オンボーディングとトイル改善の記録 speakerdeck.com SREチームの 富田 です。「BEから未経験でSREへ オンボーディングとトイル改善の記録」というタイトルで登壇予定でしたが、当日は諸事情により欠席となりました。 この記事では、発表予定だったスライドをもとに、SREとして未経験から立ち上がるまでの過程と、実際に取り組んだトイル改善の内容をお伝えします。 バックエンドエンジニア（BE）から未経験でSREへキャリアチェンジした背景と、入社してからの半年間で行った取り組みの中から、「SLO定点観測会」と「GitHub Actionsを用いたトイル削減」についてピックアップして紹介します。 BEとして働いていた時代、当時のCTOが自ら新サービスの環境構築やデプロイフロー改善を行う姿を目にしました。その経験から、アプリ開発にとどまらず開発環境そのものを整備し、エンジニアの開発生産性を支えたいと考えるようになりました。これがSREへ転向したきっかけです。 SREへ転向してから取り組んだこととして、1つ目は「SLO定点観測会」です。 SREチームの各担当と各プロダクトのエンジニアが隔週で集まり、DatadogやAmazon Managed Grafanaを見ながらアプリケーションの状態を確認する定点観測会を行っています。 この会でモデレータを務めることで、次のような学びを得ました。 対話しながらDatadogを確認することで身についた、実践的なダッシュボードの読み方 開発者の視点を聞きながら状況を判断することで得た、複数の角度からシステムを捉える力 「なぜこの数値になっているのか」を問い続けることで養われた、分析的な視点 地道な積み重ねですが、SREとして考える力の土台になっていると感じています。 2つ目は、ファインディのサービスの一つ「Findy Conference」の運用で発生していたトイルの削減事例です。 Findy Conferenceはセッション終了時などに瞬間的なトラフィックが集中するため、事前にコンテナ数の調整が必要でした。 以前は本番環境のAWSマネジメントコンソールにて手動で作業しており、ペアオペ必須で毎回約1〜2時間弱もの時間がかかっていました。 このトイルを削減するため、GitHub Actionsのworkflow_dispatchとAWS CLIを活用し、GitHubの画面上からフロントエンド・バックエンド両方のコンテナ数を変更できる仕組みを構築しました。 これにより、約2時間かかっていた作業が数分へと大幅に短縮されました。さらに、本番環境での手動介入がなくなったことでヒューマンエラーの心配が解消され、SRE以外のエンジニアでも安全にコンテナ調整が可能な状態を実現しました。 詳しい内容は次のTechBlogで紹介しています。ぜひご覧ください。 tech.findy.co.jp 以上が、登壇で伝える予定だった内容です。BEからSREへ転身し、できることから着実にトイル削減に挑戦した記録が、同じような境遇の方の参考になれば幸いです。 まとめ 以上、SREチーム主催のFindy Tech Talk「Findyのサービスを支える、横断SREチームのマネジメントと技術の挑戦」での登壇内容となります。 イベント当日は多くの方に参加いただき、賑やかな中開催することができました。参加いただいたみなさん、本当にありがとうございました！ いただいたアンケート結果より、またブラッシュアップしたFindy Tech Talkをお届けできればと思います。 次回イベント開催の際はぜひお越しください！ 現在、ファインディでは一緒に働くメンバーを募集中です。 興味がある方はこちらからご覧ください。 herp.careers