サーバーレスアプリケーションに参画して失敗した話

新春！初心者だらけのLT大会！ サーバレスアプリケーションの開発に 入れたけど何も知らなくて失敗した話 2026/1/192025/09/30 阿部健太郎 あべけん@食パン

自己紹介 名前：阿部健太郎（食パン） 年次：社会人3年目 業務：ポータルサイトの保守運用 @Plainbread2009 @Plainbread2009 趣味：ダーツ、ガンダム 2

目次 1.自己紹介 2.案件の概要 3.苦戦したこと 4.できたこと（ちょっとだけ） 5.まとめとこれから 3

参画した案件概要 クライアント証明書発行システム 申請、承認、否認APIが存在 API Gateway Lambda StepFunctions 申請情報登録 申請画面 バリデーションチェック ・2025年6～9月で参画 承認/否認URL ・失効の申請も同じようなフロー ・承認/否認も同じような構成 ・申請画面はお客様の別部署が開発 承認依頼メール ステータス更新 ・主にStepFunctionsを担当 4

失敗したこと①（エラーハンドリング） 組み込みのRetryを利用せずにChoice stateを利用して 複雑化させてしまった 5

失敗したこと①（エラーハンドリング） 組み込みのRetryを利用した場合 6

失敗したこと①（エラーハンドリング） 理由① Lambda側がexceptionエラーが発生した際に raiseで例外を再スローするようになっておらず StepFunctionsのリトライキャッチが使えなかった 理由② 組み込みのリトライキャッチを知らなかった 既にあった別のStepFunctionsを見て作ってしまった Lambdaを修正してもらう判断ができず、複雑化 7

ステートの入出力 8

入出力処理の設計 ResultSelectorで出力の一部を利用 { } “id.$”: ”$.Payload.id”, “XXX.$”: “$.Payload.XXX” ResultPathで入力（State Input）に合成 API Gatewayのステージ変数をすべてのlambdaで利用 例：dev,prod,table名 9

失敗したこと②（入出力処理） 申請画面側で入力した情報がbodyに入ってくる API Gateway Lambda StepFunctions 申請情報登録 申請画面 バリデーションチェック ResultPathでbodyに合成してしまうと 失敗時にbodyの申請情報が上書きされてしまう 10

対応方法 一旦bodyではなく、lambdaResultに結果を格納 PassステートでlambdaResultから編集 11

出来たこと IAMのロールとポリシーの最適化 インラインポリシーを 含めて80ポリシー 35ロールが乱雑に 9ポリシー 5ロールですっきり 12

まとめと今後 ・StepFunctionsのエラーハンドリングは できる限り組み込みのRetryをつかう ・入出力の設計はしっかりと ・ハンズオンとやったことを記事にする 13

ご清聴ありがとうございました 14