ID:85104さん

# 背景と概要 - 期間：2026年3月〜（PoCから本番構築までが約2ヶ月、その後に段階展開） - 規模：数百店舗 / 1日あたり数千件の商談 / 音声の平均時間 約30分 / 商談終了からSFA反映まで10分以内 - 体制：PM 1名 / アプリケーションエンジニア 2名 / インフラ 1名（私が単独で担当） - 担当：インフラ領域全般（ギャップ分析、優先度設計、Terraformでの実装、本番テスト、負荷テスト、段階リリース） 小売チェーン向けに、店舗での商談音声をiOSアプリで収録し、AWS上のバックエンドで文字起こしとLLM分析を行い、スコアリング結果をSalesforceへ書き戻すシステムです。 参画時点でPoC環境は動作していましたが、それは「1件だけ通せば動く」状態であり、本番の負荷では確実に破綻する構成でした。この環境を約1ヶ月で本番運用に耐える基盤へ引き上げ、その後は段階的な負荷テストを挟みながら、少数店舗から全店舗まで5段階に分けてリリースを拡大するところまでを担当しました。 進め方としては、社内にインフラ領域の知見を持つ人が他におらず、課題の洗い出しから優先度付け、技術選定、工数見積もり、顧客への説明まで自分で起案し、PM・顧客と合意しながら進める形でした。 # 取り組み内容 ## 方針の決定 最初に取り組んだのは実装ではなく、「どこまでやれば本番リリースして良いか」という基準を作ることでした。期限は約2ヶ月で固定されておりリリース日も決まっている一方、PoC環境と本番要件のギャップは全部を潰せない量があり、その状態で個別の施策から手を付けると、判断の根拠がないまま作業だけが進むと考えたためです。 そこで優先度の定義そのものから設計しました。「重要そうだから高い」ではなく、サイレント障害（誰も気づかないまま処理が止まり、データが静かに欠落する状態）とデータ消失が今すぐ起こりうるものを最上位に置く基準としていました。障害は止まること自体より、止まったことに誰も気づけなく復旧対応ができないことのほうが事業影響が大きいという判断をしました。 この基準でPoC環境を棚卸しし、バックアップ、エラー通知、キューイング、データロスト対策、外部AI連携、ネットワーク、Salesforce連携、可観測性、DB最適化、認証監視といった領域ごとに分類しました。各項目に「対応内容」「対応が必要な理由」「優先度」「工数」「顧客調整の要否」を付けた一覧と、営業日ベースのガントチャートに落とし込み、リリース前に完了させるべきラインを明示しました。 優先順位の考え方としては、 1. 失ったら取り返せないもの(データ保全) 2. 壊れたことに気づけない状態の解消(検知と可観測性) 3. 壊れた時に人が戻せる(復旧手段) 4. 壊れても自動で戻る(処理の信頼性) という順序を置きました。また議論を進めやすくする目的で、各項目の「対応が必要な理由」は技術用語ではなくビジネスサイドが理解しやすいように生成AIとの対話を通して逐一用語を変換し、インフラ知見のないPMや顧客が優先度の妥当性を判断できる状態にしました。 ## 構築の決定 まず既存のPoC環境の構成を洗い出し、本番要件との差分を整理しました。PoC環境はLambdaからLambdaを直接呼ぶFan-out構成で、並列処理の上限を超えると分析ジョブが消え、リトライもされず、消えたこと自体が記録されず、月あたり数百件規模の商談データが失われている可能性がありました。 期間に余裕がなかったため、既存構成の把握、AWSサービスの比較、設計案の洗い出しには生成AIを使い、調査にかかる時間を圧縮しました。一方で、どの案を採るか、本番に入れて良いかの判断は自分で行い、AIの出力はAWSの公式ドキュメントと実環境の挙動で裏を取ってから採用する進め方にしました。 最初に決めたのは、処理のメインフローをどうするかです。ここが決まらないと他のすべてが仮置きになるためです。既存のコンピューティングサービスを変えると処理そのものを大きく作り替えることになり、この期間では事業リスクのほうが大きいと判断しました。そこでLambdaでの構築を前提としたうえで、失敗したものを後から人が確認して再実行できるよう、処理フローをStep Functionsで一元管理する構成にしています。あわせて処理状態を記録するタスク管理テーブルを新設し、同時実行数の制御と失敗時のDLQ退避を入れました。 土台が決まったあとは、方針の決定で置いた優先順位の順に手を入れています。 はじめにデータ保全です。バックアップが短期保持のみで削除保護もなく、誤操作ひとつで復元できなくなる状態でした。そのため削除保護、定期エクスポートの自動化、長期保管のライフサイクル定義、音声ファイルの上書き・削除禁止を入れました。保持期間は保管コストに直結するので、こちらで決め打ちせず、試算を出して顧客と合意する項目にしています。 次が検知です。全リソースにアラームを付けることもできますが、通知が埋もれれば検知していないのと変わらないため、通知はトラフィック・アプリケーションエラー・レイテンシ・サチュレーションの4つに絞りました。文字起こしジョブの失敗、LLM APIの停止（利用上限に達した場合を含む）、Lambdaの処理上限などが該当します。加えて、商談が発生しない時間帯は監視が死角になるため、主要な依存先の疎通を数分間隔で確認するヘルスチェックを入れました。障害箇所の特定にはX-Ray、アプリケーション例外の集約にはSentryを、アラート通知にはChatbotを使い構築を簡単にすませるようにしています。 あわせて外部依存のリスクにも手を入れました。単一プロバイダが止まると分析が全停止する構成だったため、複数サービスへ切り替えられる抽象化レイヤを設け、モデル名も設定ファイルで管理するようにしています。モデルが廃止されるたびにリリースが必要になる構造を避けたかったためです。またLambdaと外部API呼び出しのタイムアウトが噛み合っておらず、呼び出し元が終了した後も外部への呼び出しが続いてコストが数倍に膨らんでいたので、全体を整合させました。 最後が復旧手段です。リリースに失敗した場合に戻せる経路を用意しました。全Lambdaをバージョン固定のエイリアス経由の呼び出しに変更したうえで、旧スキーマのデータベースをスタンバイとして常時同期させ、同期停止 → 接続先の切り替え → エイリアスの切り替え → ヘルスチェックを、SSM Automationのランブックで一連の操作として実行できるようにしていました。あわせて、特定の誰かしか復旧できない状態を作らないようにするため、自動化が使えない場合の手動手順書も整備していました。 ## 負荷テストと段階的リリース 一度に全店舗へ展開すると問題発生時の影響と切り戻しコストが許容できないため、少数店舗から5段階に分けて拡大し、各段階で負荷テストと監視結果を評価してから次の段階のリソース設計に反映しました。想定していたボトルネックには、上限緩和申請とキャパシティ設計で先回りして対応するようにしました。 ## 成果 短期間での本番構築となりとましたが、以下の対応を通じて、約2ヶ月で本番構築を終えました。 - 優先度の基準を定義し、期限内にリリース可能なスコープをPM・顧客と合意 - 処理の消失を解消し、基本的な失敗分を検知して再実行できる状態を確立 - 障害の発覚経路を、顧客からの指摘から自動検知へ転換 - 段階的な負荷テストを経て、全店舗規模での本番稼働を実現 限られた時間ではありましたが、生成AIも活用して不足していた知識を素早く補い、自分なりに最適な構成を考えたうえで構築を終えることができました。 この案件での評価をきっかけに、同じ顧客から数千万円規模の構築を継続して依頼いただくようになっています。

# 背景と概要 - 期間：2026年6月〜（本番レベルまでの構築が約3ヶ月） - 規模：顧客企業の経営層のみが利用 / 適合が必要なセキュリティ要件は数百項目 - 体制：PdM 1名 / PM 1名 / アプリケーションエンジニア 4名 / インフラリード 1名（私） / インフラ担当 2名（自社・大手業務委託先・顧客企業による複数ベンダー体制） - 担当：インフラ領域のリード（方針策定、外部ベンダーとの分担設計、検証工程の設計、構築、進行管理） 経営層の業務を支援するAIアプリケーションを、顧客側が用意するプラットフォーム環境（AWS上に構築されたもの）へ、約3ヶ月で本番レベルまで構築した案件です。 対象は、メール受信からAIによる回答生成、返信までを一気通貫で処理するアプリケーションのインフラ構築です。 難しかったのは、顧客側のセキュリティ要件が数百項目に及び、そのすべてに対応する必要があったことです。加えて、移行先のプラットフォーム自体がまだ構築途上で、こちらが前提にしたい機能・権限・ネットワークが揃っていませんでした。検証環境を使うための申請にも時間がかかり、先方の整備を待っていると期限に間に合わない状況でした。 # 取り組み内容 ## 方針の決定 最初に取り組んだのは実装ではなく、タスクと方針の整理でした。期限は約3ヶ月で固定されており、生成AIの制限もされていました。 また、インフラに知見があるのが自分一人だったため、何を自分でやり、何を外部ベンダーへ依頼するかを定義するところから始めています。 分担については、最初の調査を外部ベンダーと一緒に進めてキャッチアップしてもらい、コア機能は自分で実装して手本を示す形にしました。仕様だけ渡して任せると、インフラ側の前提が共有されないまま進んで手戻りになると考えたためです。 そのうえで、先に作ってから問題を見つける進め方にすると、複数ベンダー体制では手戻りのコストが跳ね上がると考え、着手前に、検証を4つのフェーズに分けて定義しました。 1. gap分析：コンピュート／デプロイ、トリガー／非同期キュー、データ層、セキュリティ／ネットワーク、観測／通知の5領域で、現行と本番要件の差分を洗い出す 2. 実機スパイク：長時間実行タスクとサイドカー構成、非同期化・重複防止・定期起動、観測の貫通、セキュリティ実機の4本を、実際に動かして検証する 3. E2E貫通：メール1通が取得からキュー、Agent処理、返信まで通ることを検証環境で確認する 4. 判断・報告：gapの総括、工数見積もり、build vs buy の判断書をまとめる 要点は、4を最初から工程として置いたことです。決まったものを作るのではなく、自前で作るか既製のものを使うかの判断材料を出すところまでを自分の仕事として定義しました。gap分析と実機スパイクは、その判断を裏付けるための材料集めとして位置づけています。 結果として、顧客が自前で作っているプラットフォームの方が数百項目ある独自のセキュリティ要件を満たしやすく、また他ベンダーへ依頼した際にインシデントを起こしにくくなるとして、AWS上で動いている顧客プラットフォームへ載せる方針としました。 ## 構築の決定 顧客プラットフォーム上で利用できるものに制限があったため、結果としてAWS環境で構築することとなりました。AWSサービス自体にも制限がかけられており、コンピュートはECS Fargateで構築しています。 そのうえで機密性を高めるため、エージェント本体の処理、MCPの処理、RAGの処理をそれぞれ別のコンテナに分離し、間をSQSで繋ぐ設計にしました。LLMを組み込んだシステムでは、プロンプトインジェクションのように入力経由で想定外の動作をさせられる経路を完全には塞げないため、処理を同じコンテナにまとめると、そこが突破された時点で持っている権限がすべて渡ってしまうため、影響をコンテナ単位に閉じ込めることを優先しました。 ## 進行管理 複数ベンダー体制のため、こちらの作業が他社の対応待ちで止まる場面が多くありました。そこで週次で進捗を共有する場を設け、ブロッカーとマイルストーンを明示的に切り出して管理しています。基盤側のリスク・懸念点についても、着手前に整理して関係者へ共有しました。 # 成果 セキュリティ難易度が高く短期間での本番構築となりましたが、以下の対応を通じて約3ヶ月で本番構築を終えました。 - gap分析と実機検証の結果をもとに build vs buy の判断書をまとめ、顧客プラットフォームへ載せる方針を提案 - エージェント・MCP・RAGの処理をコンテナ分離し、プロンプトインジェクション時の影響を局所化する構成を設計 - 数百項目にわたるセキュリティ要件への対応を含め、約3ヶ月で本番レベルまで構築 短期間でセキュリティ要件が厳しい中でも、自らスケジュールを先に引き妥協点を探ることで構築を終えることができました。

# 背景と概要 - 期間：2024年2月〜2026年2月 - 規模：事業規模3億円のBtoBサービス - 体制：PdM 1名 / チームリーダー 1名 / テックリード 1名（私）/ エンジニア 2名 / QA 2名 - 担当：機能開発（要件定義〜フロントエンド／バックエンド）と、インフラ・アーキテクチャの刷新 医療機関向けの採用支援管理アプリケーションの開発・運用を担当しました。採用候補者の管理や、マッチ度算出、勤怠管理といった機能を持つシステムです。 はじめはシステムエンジニアとして、マッチ度機能や勤怠管理機能などを要件定義からフロントエンド・バックエンド開発まで担当していました。その後、インフラ改善に注力しています。 当時の課題として、技術的負債が積み上がっていました。インフラリソースがコンソール上で手動管理されており、設定の再現性も変更の監査性もなく、人為的なミスによりバグが頻発することが多々ありました。 また、インフラ環境などにおいては複数開発者がデプロイまでにテストの順番待ちをしており、利用ユーザが望む機能開発が進んでいないような状況がありました。 QCDとしても悪化している状態になっており、サービス的にも継続が難しくなっていた状況でした。 # 取り組み内容 ## 改善の打診 個々の課題をそれぞれ直すことも考えましたが、構成が古いまま部分的に手を入れても同じ問題が再発すると考えました。アプリケーション側のアーキテクチャ再設計が並行して動いていたこともあり、現状の課題を棚卸ししたうえでPdMやチームリーダーへ共有し、半年間でインフラのコード化・実行基盤の移行・アプリケーションの再設計・CI/CDの刷新を、同じ線の上でまとめて進めることを提案しました。 期間を半年と区切ったのは、社内に改善そのものを進める文化がなかったためです。まず効果を実測し、どれだけの成果が出るのかを数値として示すことに注力すれば、その後の改善施策につなげられると考えました。 ## アーキテクチャ設計 はじめに、手動管理されていたAWSリソースをTerraformでコード化しました。設定の再現性と、誰がいつ何を変えたのかという監査性を確保するためです。アーキテクチャを変更してバグが出た際に即座に戻せる状態を先に作っておきたかったので、コード化を最初に持ってきています。 また、チームのほとんどがアプリケーション出身のエンジニアだったこともあり、先にコード化しておくことで、インフラ側の改善をチームで進められるようにする狙いもありました。 実行基盤は、長年改善が放置されてきた経緯から、極力メンテナンスをしなくて済むようコンテナのサーバレス構成へ移行しました。半年という制約の中でアプリケーションコードを全面刷新するのは難しいと考え、アプリケーション側はモジュラーモノリスへの段階的な再設計にとどめ、運用の手間は実行基盤側を変えることで下げる判断をしています。 CI/CDのパイプラインは、環境を簡単に増減できる仕組みに刷新しました。ここで要点にしたのが、環境の作成と削除をブランチ戦略に紐づけたことです。紐づけた背景には、履歴の管理も煩雑になっていたことがあります。環境をブランチと対応させることで、そこも合わせて整理したいという狙いがありました。 そのため、開発者はGitHub Actions上でブランチを選んで環境を作成でき、ステージングブランチへマージされた時点で環境が自動的に削除する構成とし、停止し忘れを運用ルールで防ぐのは無理があると考え、環境が消し残らない仕組み自体を作りました。あわせて、アクセス制御のためにリポジトリの分離も行っています。 # 成果 半年間という期間ではありましたが、以下の対応を通じて構築を終え、改善活動を継続させることに成功しました。 - CI/CD刷新と環境の動的な増減により、インフラ運用コストを約2割削減 - デプロイの待ち時間をほぼゼロに短縮し、開発者の生産性向上に直接貢献 - 環境のコード化により、設定の再現性と監査性を確立し、アプリケーションエンニジアでも保守可能なよう改善 - アプリケーションの再設計とサーバレス移行を主導し、システムの長期的な保守性と拡張性を確保