ID:83079さん

## プロジェクト経験概要 オンプレミス環境で稼働していた自社EC（LOHACO）のバックエンド基盤を、AWS上へ移行するプロジェクトに参画。 既存構成の分析からインフラ設計・構築、リリースおよび運用設計までを担当。 ## チーム情報 - チーム構成：内製2名（PM1名＋自分）＋ベンダー3名 - 自身の役割：インフラ構築および運用移行の実行担当 - 関与フェーズ：設計後半〜構築・移行・運用設計 ## ①オンプレミスからAWSへのインフラ移行 ### 概要 複雑な既存システム構成を踏まえ、移行速度とリスク低減を優先したAWSへのインフラ移行を実施。 ### どのような機能の開発・実装か - 現行オンプレ環境の構成整理および依存関係の把握（自身が実施） - AWS上でのインフラ構築（全体の約60%を担当） - EC2ベースでのアプリケーション実行基盤の構築 - RDSへのデータベース移行 - EFS / S3を用いたストレージ再構成 ### 課題・問題点 - システム構成が複雑であり、全面的な再設計を伴う移行はリスク・コストが高い - サーバー老朽化に伴う障害リスクおよび運用負荷の増大 - ダウンタイムを最小限に抑えた移行が必要 ### 打ち手・使用した技術 - リフト＆シフトに近い形でEC2への移行を採用し、移行速度と安定性を優先 - ロードバランサーによる切り替えにより、数分程度のダウンタイムでリリースを実現 - TerraformによるAWSリソースの一元管理 - EC2構成はAnsibleで管理し、環境構築の再現性を担保 - Terraform moduleを活用し、インスタンスおよび監視設定を含めた構成を標準化 ## ②運用基盤および運用プロセスの刷新 ### 概要 属人化していた運用基盤を整理し、ジョブ管理・実行プロセスの標準化および自動化を実施。 ### どのような機能の開発・実装か - Rundeck環境の移行およびEC2での再構築（自身が主担当） - 既存ジョブの棚卸しおよび整理 - 運用ジョブのコード化（GitHub管理） - AWS環境に対応した新規ジョブの作成 - DB操作など手動運用の自動化 ### 課題・問題点 - Rundeckジョブが未整理で、管理・可視化されていない状態 - メモリ不足等の複合的な要因により度々サーバーダウンなどが発生していた状態 - 手動でのDB更新作業など、ヒューマンエラーのリスクが高い運用が存在 ### 打ち手・使用した技術 - ジョブの棚卸しを実施し、不要・重複ジョブを整理 - ジョブ定義をコード化し、GitHubでバージョン管理 - 自動的なメンテナンス処理や潜在的な設定不備を改善し、サーバーの安定稼働を実現 - AWS移行に伴う監視・運用ジョブを新規に設計・実装 - 定型的なDB更新作業を自動化し、運用負荷とミスリスクを低減 ## ③移行後のモダナイズ対応 ### 概要 初期移行後、段階的に一部機能をマネージドサービスへ移行し、運用効率の改善を実施。 ### どのような機能の開発・実装か - 一部バッチ・API処理のコンテナ化およびサーバーレス化 - ECS / Step Functions / AWS Batch / Lambdaへの移行対応 ### 課題・問題点 - EC2ベース構成ではスケーリングおよび運用負荷に課題が残る - バッチ処理の実行管理やリトライ制御が複雑 ### 打ち手・使用した技術 - ワークロード特性に応じて実行基盤を分離 - バッチ処理はAWS Batch、ワークフロー制御はStep Functionsで管理 - 軽量な処理はLambdaへ移行し、運用コストを最適化 - APIの一部をECSへ移行しスケーラブルに

## プロジェクト概要 自社ECプロダクト（LOHACO）における電子帳簿保存法対応として、領収書・納品書発行システムの新規開発を実施。既存のHTML帳票をPDFとして発行可能にする機能を追加しつつ、クラウド設計からAPI実装までを担当。 ## チーム情報 - チーム規模：4名（社員2名＋ベンダー2名） - 役割：バックエンドAPI開発およびインフラ構築を主担当 - 担当範囲： - API設計・実装（PDF発行機能） - バッチ処理設計・実装 - クラウドアーキテクチャ設計・構築 - リポジトリ構成・フレームワーク選定など初期開発基盤の整備 ## ①：領収書・納品書PDF発行APIの新規開発 ### 概要 既存のHTML形式の帳票を、法要件を満たすPDFとして発行するAPIを新規開発。 ### どのような機能の開発・実装か - 領収書・納品書のPDF生成API - ユーザーからのリクエストに応じた動的生成・返却処理 ### 課題・問題点 - 法要件に対応した形式での帳票出力が必要 - ファイル生成処理におけるメモリ使用量の最適化 - コスト制約の中でのシステム構成設計 ### 打ち手・使用した技術 - JasperReportsでのPDF変換処理の設計・実装 - メモリ効率を考慮したストリーム処理ベースの実装 - AWS（ALB / ECS Fargate / RDS）を用いたスケーラブルな構成設計 ## 成果 - 電子帳簿保存法の要件を満たす帳票発行システムを新規構築 - HTMLベースの既存資産を活用しつつ、PDF化対応を実現 - インフラからアプリケーションまで一貫した設計により、整合性のあるシステムを構築 - コストおよびメモリ効率を考慮した実装により、安定した運用を実現 ## 再現性 - 制約（法要件・コスト・性能）を踏まえたシステム設計 - 新規プロジェクトにおける開発基盤・インフラの立ち上げ - API・バッチを組み合わせたバックエンド設計 - クラウド環境における実践的なアーキテクチャ構築

AI基盤構築 # 社内AI基盤の構築・展開 ## プロジェクト経験概要 社内のAI活用を推進するため、OSSを活用したWebUI・API・Slack Botを含むAI基盤を設計・構築。 少人数体制（1〜2名）で、アーキテクチャ設計から実装、ガバナンス整備、組織展開までを一貫して主導。 ## チーム情報 - 体制：1〜2名（自身でPdM兼務） - 役割：アーキテクト兼実装担当（設計〜開発〜展開を主導） ## ①AI基盤アーキテクチャ設計 ### 概要 複数LLMを統合し、社内から統一的に利用可能なAI基盤を構築。 ### どのような機能の開発・実装か - WebUI（LibreChat）、API（LiteLLM Proxy）、Slack Bot（Lambda）を統合した基盤を設計・実装（自身が担当） - OpenAI / Gemini / Claudeを横断利用可能なマルチLLM構成を構築 ### 課題・問題点 - 近い将来でAI利用が個別最適化され、統制・再利用が困難になることを懸念 - モデルの変化に追従できる柔軟な基盤が必要 ### 打ち手・使用した技術 - LiteLLM Proxyを採用し、LLM呼び出しを標準化 - モデル変更に対してアプリケーション改修不要な抽象化レイヤを設計 - 利用ログを一元管理し、利用状況の可視化と制御を可能に ## ②セキュリティ・ガバナンス設計 ### 概要 社内展開を前提とした安全なLLM利用環境を構築。 ### どのような機能の開発・実装か - Oktaベースの認証認可設計（自身が担当） - ネットワーク制御を含めたアクセス制御 - 利用ログ・監査設計およびガイドライン整備 ### 課題・問題点 - 外部LLM利用に伴う情報漏洩・不正利用リスク - 非エンジニア利用拡大に伴う統制強化の必要性 ### 打ち手・使用した技術 - 認証・認可とネットワーク制御を組み合わせた多層防御構成を設計 - 利用用途に応じた制限ポリシーを定義 - コーディングエージェント配布時には、エンジニア以上に厳格な制御実施 ## ③高速立ち上げと組織展開 ### 概要 短期間で基盤を立ち上げ、全社展開を推進。 ### どのような機能の開発・実装か - WebUIを1ヶ月でリリース、2ヶ月でAPI展開（自身が主導） - WebUI / Slack / API / Difyの複数チャネルを提供 - 勉強会・ユースケース展開による利用促進 ### 課題・問題点 - 基盤構築だけでは利用が定着しない - エンジニア・ビジネス双方への展開が必要 ### 打ち手・使用した技術 - 利用導線ごとにインターフェースを分離し、利用障壁を低減 - 実業務ユースケースに紐づけた展開を実施 ## 成果 - 利用者数：約800名、月間約1,000万リクエスト規模の基盤として運用（増加中） - 社内AI活用の共通基盤を確立し、属人化解消への環境を整備 - マルチLLM構成により、モデル変化への追従性と柔軟性を確保 - 利用の可視化と制御により、リスクを管理可能な状態での全社展開を実現