2025年の開発を振り返る
自己紹介
はじめまして！
Cloud Practica 受講生の mk というハンドルネームでやっている、まつおと申します！
- エンジニア歴: 2年目のピヨピヨエンジニア 🐣
- 現在の技術スタック: Next.js / Go
Jrエンジニアとしての経験談なので、ベテランの方には物足りないかもしれませんが、何卒よろしくお願いします！
目次
- はじめに
- ①React Flowによる木構造インタラクティブ機能作成（Next.js）
- ②AWS Chatbot + CloudWatch Alarm + SNS によるアプリケーション監視（アラート監視）
- ③AWSコスト最適化（コスト最適化）
- ④認証基盤のリプレース（自前認証 → Clerk）
- その他の取り組み
- おわりに
はじめに
今年も1年お疲れ様でした！
2025年、僕のキャリアは目まぐるしく変化しました。
| 時期 | やっていたこと |
|---|---|
| 1月〜5月 | フロントエンドエンジニアとして開発（8割FE、2割BE） |
| 6月〜 | バックエンド専門（Go）へ転向 |
| 7月 | Cloud Practica に入会 |
| 8月〜 | インフラ × バックエンドを主戦場に |
「フロントだけじゃなくて、もっとシステム全体を見れるようになりたい」
そんな漠然とした思いから始まった挑戦でしたが、気づけばサーバーサイドからインフラまで手を動かすようになっていました。
この1年、本当にたくさんの方々に支えられました。新しい領域に飛び込む私の挑戦を温かく見守ってくれたチームや会社の皆さん、Cloud Practica で刺激をくれる仲間たち、全ての方に感謝しています。
それでは、よろしくお願いします！
①React Flowによる木構造インタラクティブ機能作成（Next.js）
背景・課題
組織のゴール管理機能を0→1で新規開発。「ゴールを階層構造で表示したい」という要件があり、React Flow + tree.js で実装しました。
具体的にやったこと
- 木構造でのゴール表示
- ノードクリック時のオートフォーカス機能
- ノードの折りたたみ機能
ハマったポイント
折りたたみ機能でuseEffect周りのバグに遭遇。可変な外部変数を参照していたことで不要な再レンダリングが発生していました。
解決策: stateの整理（コロケーションパターン）、依存配列の適切な設定、let → const への変更
振り返り
- 「副作用と評価順序の依存を断つ」ことの重要性を学んだ
- 最初から状態設計を丁寧にやるべきだった
参考
他にもRecoilからZustandに乗り換えたり、Suspenseをしっかり使うようにしたりしましたが、フロントエンドはいったんここまでで...
②AWS Chatbot + CloudWatch Alarm + SNS によるアプリケーション監視（アラート監視）
背景・課題
アプリケーションのリリースと同時期にチームへ Slack が導入され、
「障害に早く気づいて即時に対処できるしくみを作りたい」という話が持ち上がりました。
導入前は、
- CloudWatch Logs を人が直接見に行く
- ユーザー報告で初めてエラーに気づく
そこで、Slack を起点にアプリケーションのエラーをリアルタイムで検知し、即対応できる通知基盤を構築することにしました。
意思決定のポイント
今回の構成は以下の3つです。
- CloudWatch Alarm：エラーメトリクスを監視
- SNS：アラームのルーティング
- AWS Chatbot：SNS → Slack 通知の橋渡し
この構成にした理由は以下の通りです。
- AWS 内だけで完結するため、低コストかつ即時導入できる
- 外部サービス（Datadog、PagerDuty）の導入フローを踏まなくてよい
→ ビジネス層への承認依頼が不要 - 運用開始までのリードタイムが短い
- 障害検知 → Slack 通知がシンプルでわかりやすい
将来的には Datadog などの外部監視ツールも拡張候補ですが、
"まずは軽量に始めて即効性を出す" という観点で AWS 標準構成を採用しました。
具体的にやったこと
監視対象としたのは主に 5xx エラー（特に 500 系）。
アプリケーション側の致命的エラーをいち早く検知するため、CloudWatch で以下のように設定しました。
- 1分間に 500 エラーが一定回数を超えたらアラートが発火
- SNS トピックへ通知
- AWS Chatbot が SNS を受け取り Slack チャンネルへ投稿
結果・効果
- Slack にエラー通知がリアルタイムに届くようになった
- チーム全員が同じ情報を同時に取得できるようになり、「誰も気づいていなかった」という状態を防止できた
- アプリケーションの安定性向上につながった
振り返り・学び
ただし、運用を続ける中で以下の改善余地も見えてきました。
① アラートのノイズ除去を継続的に行う必要がある
アラート基盤は"作って終わり"ではなく、運用しながら改善するサイクルが重要だと改めて感じました。
② 今後はインフラ層の監視にも広げたい
アプリケーションだけでなく、下記のようなインフラ要素も監視対象に含めることで、
より早期に兆候を掴み、障害を未然に防ぐことができます。
- RDS の CPU、接続数、ストレージ使用量
- ECS の CPU / メモリ逼迫
- ALB の Target Group Unhealthy Host
特に ECS と RDS はシステム全体のボトルネックになりやすいため、
これらに対してアラームを追加することでインフラ × アプリの統合監視を実現できます。
今後の展望：運用を組織に根付かせるために
今後は、技術的な改善に加えて、アラート運用をチームとして継続できる仕組みづくりにも取り組みたいと考えています。
- 定期的にチームでアラートの棚卸し（Notification Review 会）を実施
参考
③AWSコスト最適化（コスト最適化）
背景・課題
フロントエンド中心の役割から新たにインフラ領域も担当することになり、最初に取り組んだのが AWSコストの可視化と最適化でした。
調査の結果、月額コストは 2,159 USD とビジネスフェーズとしては許容範囲でしたが、構成の見直しによってさらに効率化できる部分が明確になったため、改善に取り組みました。
意思決定のポイント
コスト分析の結果、現状の環境では以下のサービスが特に高額であることが判明しました。
- ECS（1位）
- RDS（2位）
- ElastiCache（3位）
影響が大きいサービスから優先的に着手し、
・Savings Plans
・Reserved Instance
・Compute Optimizer
・不要リソースの削除
の4つを並行で進めていきました。
具体的にやったこと
-
Savings Plans の適用
AWS公式の Savings Plans Purchase Analyzer を利用し、実際の利用状況から導き出された最適な購入パターンを採用しました -
Reserved Instance の導入
正規化係数（Normalization Factor）を理解した上で、より効率的にリザーブドを活用できるよう構成を見直して購入しました。インスタンスファミリー間の柔軟な割当を意識して選定しました -
Compute Optimizer の推奨値に基づくチューニング
Compute Optimizer のレポートを見ると、特に ECS タスク定義の CPU / メモリが過剰でした。そこで、推奨値まで引き下げ、無駄なリソース割り当てを解消しました -
不要リソースの削除
利用されていない、または過去のアプリ開発フェーズで残ってしまっていた以下を整理しました
- OpenSearch Service（本番で用途がなかった）
- 未使用の NAT Gateway
- 使われていない RDS インスタンス
- 使われていない ElastiCache
など、運用上不要なリソースを棚卸しして削除しました。
結果・効果
最適化の結果、月額コストは
2,159 USD → 1,594 USD（26%削減）
という明確な改善を達成しました。
一時的な削減ではなく、継続的に効果が出る構造へ改善できました。
振り返り・学び
- 毎月のレポートを確認し、月次でコスト分析 → 対策案の検討を行う体制を構築
- 「削減＝リソース削減」だけでなく、Savings Plans や RI の活用が最も効果的である点を実感
定期的に棚卸しすることで"幽霊リソース"の発生を防ぎ、無駄な支出が抑えられます。
④認証基盤のリプレース（自前認証 → Clerk）
背景・課題
当初は自前実装によるメール／パスワード認証と独自の JWT / Refresh Token 管理を採用していました。しかし、SaaS としての事業拡大を見据える中で、以下の課題が明確になりました。
セキュリティ面のリスクが大きくなっていた
認証は SaaS における最重要コンポーネントであり、一度でも脆弱性が発生すれば
データ漏洩・信頼失墜・契約破棄につながる致命的な事故になりえます。
特に BtoB / 大企業向け SaaS では、
- 厳格なセキュリティ基準（アクセス制御、監査ログ、パスワードポリシー）
- コンプライアンス要求（ISMS、SOC2、GDPR など）
- インシデント発生時の説明責任
が求められ、自前認証では長期的にこれらを満たし続けるのは非常に困難でした。
大企業へ展開する SaaS として、漏洩リスクを最小化する強固な認証基盤は必須でした。
→ これがリプレース検討の決定的な背景となりました。
DBで Refresh Token を保持している構造が限界に近かった
自前実装では Refresh Token を DB に保存し、ローテーション制御や失効管理を行っていましたが、
次のような運用上の問題が発生していました。
- トークンのローテーションが正常に動作しないケースがある
- トークン漏洩時の影響範囲が広く、リスク管理が難しい
- マイクロサービス化・マルチアプリ化に構造的に向かない
大企業向け SaaS で求められる監査性・安全性・再発防止策を満たすには
自前トークン管理の仕組みは弱く、限界を感じていました。
SaaS として"共通の安全な認証レイヤー"を持つ必要があった
今後複数サービスへ展開する計画があるため、認証は各サービスで個別実装するのではなく、
- 統一された ID 管理
- セキュアで
- 拡張性が高く
- セキュリティインシデント時の迅速な対応
これらを自前で作り続けるのは現実的ではなく、
外部の IDaaS による"強固で標準化された認証レイヤー"を導入する方が合理的という結論に至りました。
意思決定のポイント
IDaaSとしては Clerk / Auth0 / Firebase Auth / Supabase Auth / AWS Cognito などを比較し、最終的に Clerk を採用しました。
-
Next.js との相性が圧倒的に良い
SSR/ISR を考慮した公式 SDK が充実しており、フロント実装コストが大幅に削減できました -
開発者体験（DX）が優秀
-
無料枠が大きく、スタートアップに最適
10,000 MAU 無料で利用できるため、初期コストをほぼゼロで導入可能 -
柔軟なカスタマイズ性
独自UIやAPIベースの認証フローにも対応しており、段階的な移行にも向いていました
具体的にやったこと
Clerk の検証環境構築
- Clerkプロジェクトを作成し、AWS 上に Clerk 用 dev 環境を構築しアプリケーションを作成
- Google OAuth の設定
- Clerk Webhooks の実装（ユーザー作成・削除イベントをバックエンドへ連携）
アプリ側の実装変更
バックエンドの認証方式を以下のように変更しました。
- 自前 JWT 検証 → Clerk の JWK（Public Keys）を利用した検証方式に変更
- Middleware レイヤーの差し替え
セッション管理／ユーザー情報取得ロジックを Clerk API ベースに整理
既存ユーザー移行の検証
- 自前ユーザー情報 → Clerk ユーザーへのマッピング方式を検証
- メールアドレス重複や SNS 併用ユーザーの扱いなど、移行時の問題点を洗い出し
結果・効果
現在は Clerk 用 dev 環境で運用確認を完了し、本番環境への適用準備段階です。
移行後は以下のメリットが期待できます。
- セキュリティ標準化(httpOnly,sameSite, accessTokenの5s更新,,,,etc)
- UX 改善（安定したログインフロー、自動ローテーション、SNS ログイン）
- 開発コストの削減（自前認証コードの保守・運用からの脱却）
- 複数サービス展開に対応できる拡張性
その他の取り組み
今年取り組んだその他のインフラ・バックエンド施策です。
| 取り組み | 概要 |
|---|---|
| Event Bridge Scheduler | Googleカレンダーから自前データを作成するバッチ処理を構築 |
| Secrets Manager移行 | AWS Macieで重要な環境変数をスキャンし、Secrets Managerへ移行 |
| Session Manager導入 | EC2踏み台サーバーのSSH接続を廃止し、Session Managerに移行。セキュリティ向上 |
| Read Only DB User作成 | 本番DBへの誤操作防止のため、参照専用ユーザーを作成 |
| Terraform化 | 上記で作成したリソースをTerraformでコード管理 |
おわりに
ここまで読んでくださり、ありがとうございました！
どの取り組みも「なぜこの方法を選ぶのか」を自分なりに考え、意思決定の背景を言語化することを意識しました。まだまだ経験は浅いですが、この積み重ねが少しずつエンジニアとしての土台になっていると感じています。
ピヨピヨエンジニア🐣がここまで分野を横断して経験できたのは、現在の環境に恵まれているからこそです。まずは参画しているプロジェクトの社長に、多大なる感謝を伝えたいです。
そして、師匠をはじめとするチームのメンバー、コミュニティの皆さんのサポートがあったからこそ、ここまでやってこれました。本当にありがとうございます。
来年も、さらに高難易度な問題を解決できるエンジニアであり続けたいです。
2026年が皆様にとって最高な一年になることを願っています。
来年もよろしくお願いします！