先日、私の結婚式がありまして、その際に使用することにした写真共有WEBアプリのお話をさせてください。

これリポジトリ： https://github.com/HrOkiG2/wedding-memory-sns

何を作ったの？

結婚式によくある卓に配置されたインスタントカメラ（写ルンです）の代わりにリアルタイムで式の様子を共有するWEBアプリを作成しました。

下記のようにQRコードとスクリーンに式の様子が共有されるというWEBアプリです。
（このQRコードには悪意のあるスクリプトが含まれているので読み込まないように。。嘘です、もうページ開けないです）

なぜ自作したのか

シンプルにお金がなかったからです。

自身の結婚式にあたり、初めはゲストが写真を撮って楽しめる演出として、各テーブルに「写ルンです」を配置することを検討していました。

しかし、本体代に加えて「現像・データ化代」を含めると、想定以上のコストになることが判明しました。

• 本体代： 2,000円/1台 * 卓数分
• 現像代： 950円 * 卓数分
• データ化： 900円 * 卓数分

今回の結婚式ではゲストの卓数が15になるため以下のコストが掛かります。

(2000 * 15) + (950 * 15) + (900 * 15) = 57,750

結婚式を実施するだけでもウン百万かかっているので、不必要な出費がかなり痛く、そもそもの段階として 写ルンですを配置するという企画を取りやめうと考えました。

嫁さんからの「あんたエンジニアだからどうにかならないの」の一言からそれもそうだ自分で作ろうと思い立ち結婚式用の写真共有WEBアプリを開発しました。

システム概要

仕組みはシンプルです。

1. 各テーブルに QRコード を設置。
2. ゲストがスマホでスキャンすると、ブラウザアプリが起動（ログイン不要）。
3. 撮った写真をアップロードすると、会場の スクリーンにリアルタイムで反映 される。

技術構成

開発期間は仕事の合間を縫って約2週間。

「維持費を極限まで下げる（サーバーレス）」ことと、「TypeScriptで統一する」ことをテーマに構成しました。

フロントエンド

• Framework: Nuxt 3 (Vue 3)
• Language: TypeScript
• Styling: Tailwind CSS
• Hosting: S3 + CloudFront (Static Site)

バックエンド・インフラ (AWS CDK)

インフラは全て AWS CDK でコード管理しています。
使用したスタックは以下のとおりです。

こだわった技術ポイントと「ハマりどころ」

単純なアップローダーに見えますが、「不特定多数のゲストが」「多様な端末で」「一斉に使う」 という環境特有の課題がありました。

署名付きURL (Presigned URL) の活用

Lambdaを経由して画像をアップロードすると、ペイロードサイズ制限（6MB）や実行時間課金の問題が発生します。

そこで、クライアントから「アップロードしたい」とリクエストがあった際に、Lambdaが S3への一時的な書き込み許可証（Presigned URL） を発行し、クライアントがS3へ直接アップロードする構成にしました。

これにより、サーバー負荷を最小限に抑えています。

iPhoneの「コードスキャナー」

これが開発中最大の落とし穴でした。

iPhoneのコントロールセンターにある「コードスキャナー」でQRを読むと、Safariではなく一時的なアプリ内ブラウザで開かれてしまいます。

このブラウザは画面を閉じるとCookieやLocal Storageが即座に破棄されるため、「さっきアップした写真を確認しよう」と再度QRを読み込むとログアウト状態になってしまいます。

技術的に「強制的にSafariを開かせる」方法は存在しないため、「iPhoneの方は標準カメラアプリで読み取ってください」 という物理的なPOPを各卓に置くという、アナログな解決策に着地しました。

やらなかったこと

あえて、アップロードされた画像のダウンロード機能は実装しませんでした。

これは嫁と相談した結果なのですが、アップロードされた画像は一度、私達夫婦のもとに落としてそれをLINE等で発信したい。その過程の中で結婚式の思い出にもう一度触れたいという考えのもとです。

結果としては、LINEで結婚式について参列者の友人たちと思い出に浸ることもできました。

また、機能減らしたことで実装コストが下がったのも大きかったですね。

コスト比較結果

AWS利用料は、開発期間を含めても数百円。当日のスパイクアクセス（CloudFront, Lambda, S3）も微々たるものでした。

約3.5万円の節約 に成功し、その分を料理や引き出物のグレードアップに回すことができました。

参列者の反応

結果は 大成功 でした。

• リアルタイム性: 投稿した写真がすぐスクリーンに出るため、「今の面白い瞬間」が共有され、会場の一体感が生まれた。
• 懐かしさの共有: 「新郎新婦との昔の写真」をスマホから掘り出して投稿してくれるゲストが多数おり、スライドショーがエモい雰囲気に。
• 交流: ゲスト同士で「今の写真送って！」ではなく「QRから上げといて！」という会話が生まれ、自然な交流のきっかけになった。

副次的な成果として、参列していた友人2名から「自分の式でもこれを使わせてほしい」とオファーをもらいました。(すごく嬉しかった)

また、アップロードされた画像は約300枚になり、予定していた100枚よりも大幅に多い画像がアップロードされました。
余興の多い沖縄の結婚式の中で、これだけの数の画像がアップロードされたのは機能を絞ったこととUIをシンプルにしたことが影響したのかなぁという印象です。（シンプルにすごく嬉しい）

今後の改善点

1. 画像配信の最適化:現在はS3のPresigned URLで画像を表示しているため、エッジキャッシュが効いていません。CloudFront経由の署名付きCookie/URLに切り替え、表示速度を向上させたいです。
2. 不適切画像のAI検知:今回はゲストのモラルに助けられましたが、Amazon Rekognitionを使って「不適切な画像」を自動で弾く機能を入れれば、より安心して運用できます。
3. アクセス解析:Microsoft Clarityなどを入れて、ゲストがどこでつまづいたか（UX）を計測すべきでした。
4. これネイティブアプリにしたら面白そうじゃねという気持ちがあります（作ったことないけど…誰か共同で開発しませんか…！）

まとめ

「節約」から始まったプロジェクトでしたが、結果として 「写ルンです」には出せないリアルタイムな体験価値 を提供できました。

なにより、自分の技術で一生に一度のイベントを盛り上げられた達成感は、何にも代えがたいものでした。

これから結婚式を挙げるエンジニアの皆さん、「結婚式自作Webサービス」、おすすめです。

先日、友人のWebアプリケーションエンジニアとIaC（Infrastructure as Code）について話す機会がありました。 話の発端は「Terraform と CDK、どっちを採用すべきか？」というよくあるテーマだったのですが、友人からこんな強烈な一言をもらいました。

「CDK一択でしょ。だってCDK（CloudFormation）はデプロイ失敗時に自動ロールバックしてくれるけど、Terraformは作りかけで止まるでしょ？怖くて使えないよ」

なるほど、確かにその視点はあります。DBのトランザクションに慣れ親しんだエンジニアからすれば、「失敗したらAtomicに元に戻る」挙動こそが正義でしょう。

しかし、普段Terraformを触っている身からすると「うーん、それは『ロールバック』の定義や運用思想が違うだけでは？」というモヤモヤが残りました。

今回は、この「IaCにおけるロールバックと復旧戦略」について、公式ドキュメント等の情報を交えながら整理してみたいと思います。

そもそも「ロールバック」とは何を指しているのか？

友人が言っていた「ロールバック」は、主に 「デプロイ（Apply）が途中でコケた時の挙動」 を指しています。

CDK の場合

CDKは、コンパイルされると最終的に AWS CloudFormation テンプレート になり、デプロイもCFnを通じて行われます。

• 挙動
  スタックの更新中にエラーが発生すると、CFnは 「自動的に直前の正常な状態に戻そう」 とします。
• ステータス
  UPDATE_ROLLBACK_IN_PROGRESS → UPDATE_ROLLBACK_COMPLETE

これはCloudFormationの基本機能として提供されています。
スタックの更新のロールバック – AWS CloudFormation

メリット
何もしなくても「壊れた状態」で放置されることが少ないです。
「オール・オア・ナッシング」に近い挙動をするため、整合性が保たれやすい安心感があります。

デメリット
ロールバックには時間がかかります。
リソース作成に30分かかって失敗した場合、ロールバックにも同等の時間がかかることがあります。
また、ロールバック自体が失敗するUPDATE_ROLLBACK_FAILEDという状態に陥ると、手動での介入が必要になり、復旧難易度が跳ね上がります。
参考: 更新のロールバックに失敗したスタックを更新できるようにする – AWS CloudFormation

Terraform の場合

Terraformは、AWSのAPIを直接叩いてリソースを操作します。

• 挙動
  terraform apply 中にエラーが発生すると、その時点で処理が停止します。
• ステータス
  成功したリソースは作成済み、失敗したリソースは未作成（または中途半端）な状態で残ります。

Terraformには「自動ロールバック」という機能自体が存在しません。これはバグではなく仕様（思想）です。
HashiCorp Terraform: Command: apply

メリット
エラーの原因が明確で、「ここまでは成功した」という状態がStateファイルに保存されます。
コードを修正して再実行（terraform apply）すれば、差分のみを適用し直すため、復旧までの時間が圧倒的に短いです。

デメリット
「中途半端な状態」が一時的に発生するため、手動でのリカバリ（State操作やTaint）が必要になる場合があります。

なぜTerraformには自動ロールバックがないのか？

Terraform派の意見として、「自動ロールバックがないこと」は 「Fail Fast（早く失敗して早く直す）」 という設計思想に基づいています。

1. Stateの一貫性重視
   Terraformは「現在のインフラの状態」をtfstateファイルで厳密に管理します。
   勝手にロールバック（過去の状態に戻すAPIコール）を行うと、ローカルのコードと現実のリソースの乖離が複雑化するリスクがあります。 State – Terraform by HashiCorp
2. Roll Forward（前進による修復）の推奨
   インフラ変更において、失敗した場合は「元に戻す」よりも「修正して適用し直す」方が早いケースが多いです。
   Terraformは plan コマンドで事前に変更内容を詳細に確認できるため、実行時エラーは「権限不足」や「パラメータ不正」などが主であり、コードを直して再Applyすれば済むことがほとんどです。

ロールバックというバージョン切り戻し

友人の言う「デプロイ失敗時の自動復旧」ではなく、「正常にデプロイしたけどアプリが動かないから昨日の構成に戻したい」 という場合のロールバックはどうでしょうか。

• CDK (CloudFormation): Gitで以前のコードに戻し、再デプロイします。 ※ CFnの自動ロールバックはあくまで「デプロイエラー時」の挙動であり、論理的なバグまでは戻してくれません。
• Terraform: Gitで以前のコードに戻し、terraform apply します。

つまり、「正常デプロイ後の切り戻し（Revert）」に関しては、両者の手間に大きな差はありません。 どちらも「Gitを正」として、過去のコミットの状態へインフラを収束させる作業になります。

結論：どっちが良いのか？

友人の「CDKの方が優秀」という意見は、「デプロイ作業中の安全性」 に重きを置いた意見と言えます。特にアプリケーションエンジニアにとって、デプロイ失敗時に環境が散らかったままになるのは恐怖でしょう。

一方でTerraformは、「状態の透明性と制御」 に重きを置いています。「勝手に戻るより、どこで止まったか教えてくれ。俺が直すから」というスタンスです。

まとめ

• CDK (CloudFormation)
  • 特徴: 失敗時は自動で元通り（トランザクション的）。
  • 向いているケース
    インフラの詳細なステータス管理より、デプロイパイプラインの安定性を重視したい場合。ロールバック待ち時間が許容できる場合。
• Terraform
  • 特徴
    失敗時はそこでストップ（即時停止）。修正して再実行（ロールフォワード）。
  • 向いているケース
    terraform plan で事前に結果を予測し、失敗時も自分の手ですぐに復旧させたい場合。APIコールの速さを求める場合。

「ロールバックがあるからCDK」ではなく、「失敗時のリカバリ戦略として、自動復帰（CDK）と即時停止（Terraform）のどちらが自分たちのチームに合っているか」で選ぶのが正解ではないでしょうか。

私は……やっぱり terraform plan で「何が起きるか完全に把握してから実行する」安心感が好きですね（笑）

直近、業務でECSへのデプロイワークフローを実装することになりました。

主な流れは以下の通りです。

1. フロントエンドのビルド
2. Docker Image のビルド
3. ECR へのログイン
4. ECR へPush
5. ECS のサービス更新

この中でボトルネックになるのが 「2. Docker Image のビルド」 です。

毎回フルビルドしていると時間がかかりすぎるため、キャッシュの利用は必須です。

Docker Buildx のキャッシュバックエンドには、大きく分けて以下の3つの選択肢があります。

1. GitHub Actions Cache (type=gha)
2. GitHub Container Registry (type=registry)
3. Amazon ECR (type=registry)

これらを比較検討した結果、今回は 「GitHub Actions Cache (type=gha)」 を採用しました。

その理由はズバリ、「利用料（ランニングコスト）」と「実装（設定）コスト」が最も低かったからです。

比較検討：3つのキャッシュ戦略

それぞれの特徴を「コスト」と「手間」の観点で整理しました。

1. Amazon ECR (type=registry)

AWS環境に統一できるメリットはありますが、以下のデメリットがあります。

• 実装コスト
  IAMロールの設定、aws-actions/amazon-ecr-login の設定が必要。
• 利用料
  • データ転送量
    GitHub Actions (インターネット) ⇔ AWS ECR 間の通信が発生します。
    NAT Gatewayを経由する場合などは特に通信費がかさむ可能性があります。
  • ストレージ料金
    キャッシュイメージの分だけECRのストレージ料金が発生します。
  • 実行時間
    ネットワーク越しにPush/Pullするため、ビルド時間が伸び＝GitHub Actionsの課金対象時間（Minutes）も消費します。

2. GitHub Container Registry (type=registry)

GitHubのエコシステム内で完結しますが、こちらも考慮が必要です。

• 実装コスト
  docker/login-action での認証設定や、パッケージの読み書き権限設定が必要。
• 利用料
  • Organizationのプランによっては、GHCRのストレージ容量やデータ転送量に制限・課金が発生する場合があるらしい

3. GitHub Actions Cache (type=gha)

今回採用した方法です。

• 実装コスト
  認証設定が一切不要。YAMLに数行書くだけ。
• 利用料
  • 通信費ゼロ
    GitHub Actionsの内部ネットワークで完結するため、外部への転送コストがかかりません。
  • ストレージ無料
    リポジトリあたり10GBまで利用可能（超過分は古いものから自動削除されるだけなので、追加課金のリスクがない）。
  • 実行時間短縮
    ネットワークが高速なため、キャッシュのリストアが速く、結果としてActionsの実行時間を節約できます。

比較まとめ表

なぜ type=gha を選んだか

今回の要件において、私が重視したのは以下の2点です。

1. ワークフローの利用料を抑えたい
   • 無駄なデータ転送費やストレージ料金を払いたくない。
   • ビルド時間を短縮して、GitHub Actionsの利用枠（Minutes）を節約したい。
2. 実装コストを最小限にしたい
   • キャッシュのためだけにIAM権限を調整したり、Secretsを管理したりする手間を省きたい。
   • シンプルに保ち、メンテナンスしやすくしたい。

この2点を満たすのが type=gha でした。

「ローカル開発環境でも同じキャッシュを使いたい」という要件があれば registry 系が候補に挙がりますが、今回は「CIの高速化」が主目的だったため、迷わずこちらを選択しました。

実装コード

設定は驚くほどシンプルです。docker/build-push-action に cache-from / cache-to を追加するだけです。

      # Buildxのセットアップ（必須）
      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      # ビルド & Push
      - name: Build and push
        uses: docker/build-push-action@v5
        with:
          context: .
          push: true
          tags: ${{ steps.login-ecr.outputs.registry }}/my-app:latest
          # ★ここがポイント
          cache-from: type=gha
          cache-to: type=gha,mode=max

ポイント：mode=max

cache-to: type=gha,mode=max を指定することで、最終的なイメージだけでなく、中間レイヤー（npm install などを行ったレイヤー）もキャッシュされます。
これにより、コードを少し変更しただけでもフルビルドが走るのを防げます。

まとめ

技術選定において「高機能であること」も重要ですが、「コストがかからない」「設定が楽」 というのは、運用を続ける上で正義です。

ECSデプロイのビルド時間に悩んでいる方は、まずは一番手軽で財布に優しい type=gha から試してみてはいかがでしょうか。

先日、業務にて「既存のRDSのストレージを暗号化したい」という、シンプルかつ重たい要件が降ってきました。

これの何が困るかというと、皆様ご存知の通りRDSの仕様です。 RDSは作成後の暗号化ステータスの変更ができません。つまり、既存のRDSを暗号化するためには、「暗号化有効」設定で作り直す（再作成する）必要があります。

参考: Amazon RDS DB インスタンスおよびクラスターの暗号化 – AWS Prescriptive Guidance

さらに今回はインフラを AWS CDK で管理しています。
単純にCDKのコードを書き換えてデプロイすると、CloudFormationの仕様により「リソースの置換」が発生し、予期せぬダウンタイムやデータ損失のリスクがあります。
また、よくある「スナップショットから復元して差し替え」という手法も、CDKのState管理との兼ね合いで今回は採用できませんでした。

様々な制約がある中、「既存データを維持しつつ」「CDK管理のまま」暗号化リソースへ移行できたので、その手法を共有します。

今回の要件と制約

今回のミッションにおける前提条件は以下の通りです。

• 既存RDSの暗号化（最重要）
• 既存データをそのまま移行できること
• アプリ側の変更を避けるため、エンドポイント（またはDNS）の変更がないこと
• ダウンタイムは許容（ALBでメンテナンス画面を挟む前提）
• バッチ処理が稼働していない夜間帯での作業
• CDKコードの変更は最小限に留め、今後もCDKで管理し続けること

結論：CDKデプロイを3回行う

結論から言うと、「削除ポリシーを変更して既存RDSをCDK管理から切り離し、新規で暗号化RDSを作成する」という力技で解決しました。

具体的には以下の3ステップでデプロイを行います。

1. RemovalPolicy.RETAIN を設定（既存保護）
2. instanceIdentifier を変更（既存切り離し）
3. storageEncrypted: true を指定（新規作成）

なぜこの手順が必要なのか？（ハマりポイント）

通常、CDKで管理されているリソースに対し、instanceIdentifier（物理ID）を固定したまま storageEncrypted: true に変更してデプロイしようとすると、以下のエラーが発生して失敗します。

CloudFormation cannot update a stack when a custom-named resource requires replacing

これは、「カスタム名（明示的な名前）がついているリソースを置換（削除＆作成）することはできない」というCloudFormationの安全装置です。これを回避するために、あえて識別子を変更して別リソースとして認識させる必要があります。

手順詳細

1. 削除ポリシーの変更

まず、既存のRDSがCDKのスタック操作によって削除されないようにします。 これをやらないと、次の手順で「既存RDSの削除」が走ってしまい、データが消えます（超重要）。

コード スニペット

new rds.DatabaseInstance(this, 'RdsInstance', {
  instanceIdentifier: 'my-prod-db', // 現在の識別子
  // ...
  removalPolicy: cdk.RemovalPolicy.RETAIN, // ここを追加！
});

この状態で一度 cdk deploy します。 これで、このRDSはスタックから削除される際も、AWS上にはリソースが残るようになります。

2. instanceIdentifier の変更

次に、既存のRDSをCDKの管理下から外す（Orphanにする）作業です。 CDK上の識別子を、既存のものとは別の名前に書き換えます。

コード スニペット

new rds.DatabaseInstance(this, 'RdsInstance', {
  instanceIdentifier: 'my-prod-db-temp', // 3と被らない一時的な名前に変更
  // ...
  removalPolicy: cdk.RemovalPolicy.RETAIN,
});

この状態で cdk deploy します。

何が起きるか：
CloudFormationは「my-prod-db を管理から外し、新しく my-prod-db-temp を作る」という挙動をします。 ステップ1で RETAIN を設定しているため、旧RDS（データ入り）は削除されずにそのまま残ります。
※この時点でアプリはまだ旧RDSを見ています。

3. いよいよ暗号化RDSの構築

最後に、本命の「暗号化されたRDS」を作成します。

コード スニペット

new rds.DatabaseInstance(this, 'RdsInstance', {
  instanceIdentifier: 'my-prod-db', // 元の名前に戻す（ここが変わるとエンドポイント変わるので注意）
  storageEncrypted: true,           // 暗号化をON
  removalPolicy: cdk.RemovalPolicy.RETAIN,
  // ...
});

この状態で cdk deploy します。

注意点：
もし instanceIdentifier を手順1と同じ名前（my-prod-db）に戻したい場合、手順2の時点でAWS上に古い my-prod-db が残っているため、名前重複でエラーになる可能性があります。
その場合は、AWSマネジメントコンソールまたはCLIから、古いRDS（手順2で切り離されたもの）の識別子を手動で my-prod-db-old などにリネーム してからデプロイしてください。

これで、暗号化された空っぽのRDSが立ち上がりました。

データ移行

新旧2つのRDSが存在している状態になりました。

• 旧RDS
  • データあり
  • 非暗号化
  • CDK管理外
• 新RDS
  • データなし
  • 暗号化済み
  • CDK管理下

データ量がそれほど多くない（数GB〜数十GB程度）ため、今回はシンプルに mysqldump で移行を行いました。TB級の場合は AWS DMS (Database Migration Service) の利用を検討してください。

# SSM Session Manager 等で踏み台サーバーに接続

# 1. 旧RDSからデータをエクスポート（パイプで圧縮して転送時間を短縮）
mysqldump -h [旧RDSエンドポイント] -u [ユーザー名] -p \
  --single-transaction --routines --triggers \
  --databases [対象のスキーマ] \
  | gzip > dump.sql.gz

# 2. 新RDSへインポート
zcat dump.sql.gz | mysqldump -h [新RDSエンドポイント] -u [ユーザー名] -p

データの移行が完了したら、アプリケーションの接続先が新RDSに向いていることを確認し、メンテナンスを解除します。

後片付け

無事稼働確認が取れたら、不要なリソースを削除してお財布を守りましょう。

1. 手順2で立ち上がった一時的なRDS（CDKの管理からは外れているはずですが、念の為確認して削除）
2. 手順1以前から存在していた旧RDS（リネームした my-prod-db-old など）

スナップショットが取れていることを確認した上で、マネジメントコンソールから削除しました。

(おまけ) 試したけどうまくいかなかったこと

cdk import での既存リソース取り込み

既存のリソースをリネームして、新しいスタックに取り込もうと cdk import を試みましたが、以下のようなメッセージが出てスキップされました。

TmpStack: no new resources compared to the currently deployed stack, skipping import.

また、定義と実リソースのプロパティ（暗号化の有無）が食い違っているため、インポート自体が整合性エラーになる可能性が高いです。

DatabaseInstanceFromSnapshot の利用

スナップショットから復元するCDKのクラスですが、これをメインの定義にしてしまうと、常に「スナップショットから作られた状態」が正となり、パラメータグループやバージョン更新などの運用時にドリフト（設定乖離）の管理が面倒になると判断し、今回は見送りました。

まとめ

CDKで管理しているステートフルなリソース（RDSなど）の「再作成必須な変更」は非常に神経を使います。 「Retainで保護」→「Identifier変更で管理から切り離し」→「新規作成」 というフローは、RDSに限らず他のリソースでも応用が効くテクニックなので、覚えておいて損はないはずです。

なにはともあれですが、RDSは最初から暗号化しましょう。これだけは覚えて頂けると。。。

同じ悩みを抱えるPHPer（およびAWS使い）の助けになれば幸いです！

CDK、楽しいですよね。Typescript でインフラがかけるなんて最高です。でも、学習を始めていくとある壁にぶつかりました。

ネット上の「CDKでECS構築してみた！」系の記事を参考にすると、大抵の場合 VPCもECSもRDSも全部一つの lib/my-stack.ts に処理が書かれている」のです。サンプルコードとしてはわかりやすいのですが、いざ実務でLMAP環境を作ろうとすると⋯…

• VPC は更新頻度が低いからスタックを分けたい
• RDS はステートフルだから独立させたい
• ECS はアプリケーションコードのデプロイで頻繁に更新が入るかも

とスタックを分割したくなりませんか？
でも、分割した途端に「StackA で作ったVPCのIDをどうやってStackBにわたすの？」という問題が発生します。

当記事では、現時点での私の持論である スタック間のリソース共有を紹介します。

IDではなくオブジェクトを渡す

VPC スタックとECSスタックを分けるときに、ついやってしまいがちなのが VPC IDを Props で渡す という手法です。
Terraform に慣れていると、この発想になりがちですよね。

この手法では CDK の 型安全を活かすことが出来ないので、 VPCオブジェクトそのもの を渡すのがベストだと考えています。

私の構成案：
司令塔となる エントリーポイント app がバケツリレーのようにオブジェクトを渡していくイメージです。

1. VPCStack： VPCを作る。 public readonly vpcでVPCオブジェクトを公開する
2. APP： VpcStack からVPCオブジェクトをもらい、 ECSStackに渡す
3. EcsStack： 受け取ったVPC オブジェクトを使ってクラスターを作る

実際にコードを見ていきましょう。

型安全の恩恵を受ける

VPCStack ⇒ 渡す側

ここでは this.vpcをクラスのメンバ変数として公開しておきます。

// lib/vpc-stack.ts
import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import { Construct } from 'constructs';

export class VpcStack extends cdk.Stack {
  // 外部に公開するプロパティ（これが重要！）
  public readonly vpc: ec2.IVpc;

  constructor(scope: Construct, id: string, props?: cdk.StackProps) {
    super(scope, id, props);

    this.vpc = new ec2.Vpc(this, 'LampVpc', {
      maxAzs: 2,
    });
  }
}

EcsStack ⇒ 受け取る側

ここがポイントデス。 vpcId: stringではなく、 vpc: ec2.IVpc というインターフェース型で受け取ります。

// lib/ecs-stack.ts
import * as cdk from 'aws-cdk-lib';
import * as ec2 from 'aws-cdk-lib/aws-ec2';
import * as ecs from 'aws-cdk-lib/aws-ecs';
import { Construct } from 'constructs';

// Propsの定義：文字列ではなく「VPCの型」を指定する
interface EcsStackProps extends cdk.StackProps {
  vpc: ec2.IVpc;
}

export class EcsStack extends cdk.Stack {
  constructor(scope: Construct, id: string, props: EcsStackProps) {
    super(scope, id, props);

    // 文字列から検索する必要なし！そのまま使える
    const cluster = new ecs.Cluster(this, 'LampCluster', {
      vpc: props.vpc, 
    });
  }
}

bin/app.ts ⇒ 繋ぐ場所

最後にエントリーポイントで紐づけます。

// bin/app.ts
import * as cdk from 'aws-cdk-lib';
import { VpcStack } from '../lib/vpc-stack';
import { EcsStack } from '../lib/ecs-stack';

const app = new cdk.App();

// 1. VPCを作る
const vpcStack = new VpcStack(app, 'VpcStack');

// 2. VPCオブジェクトをECSスタックに渡す
const ecsStack = new EcsStack(app, 'EcsStack', {
  vpc: vpcStack.vpc, // ここでバケツリレー
});

この方法の何が良いの？

この方法のメリットは2つあると思っています。
（一言で言うとプログラミング言語による抽象化です。）

1. 圧倒的な型安全性
   もし間違えてS3のオブジェクトを渡そうとすると、エディタがその場でエラーを吐いてくれます。
   「デプロイしてみたらIDが違ってコケた」という悲劇が未然に防げます
2. 記述がメチャ楽
   受け取る側で ec2.Vpc.fromLookup() のようなインポート処理を書く必要がありません。渡された瞬間から props.vpc.addInterfaceEndpoint のようにメソッドが使えます

議論したいポイント

ここまで「これが正解だ」という顔で書いてきましたが、実はこの構成には明確なデミリットもあります。それは、 スタック同士が密結合 になることです。

Cloudformation の Export/Import 機能でガッチリ紐づいてしまうため、以下のような問題が置きます。

• スタック間の参照があるため、「VPCだけを作り直したい」が出来ない

ただし、私は上記のような問題が発生したとしても、
LAMP 環境という一つのアプリケーションにおいて、VPCとECSは「運命共同体」にあたるため問題ないと考えています。

「ECSが生きているのにVPCだけ消したい」という状況は稀ではないでしょうか。そのためこの密結合はあえて受け入れるべき仕様だと割り切っています。

ただ、もし組織の基盤となる共通のVPCを作る場合は、ライフサイクルが異なるため、疎結合なID渡しにするのが正解なのかもしれません。

皆さんの構成おしてほしいっす。

正直に告白します。僕はこれまで、なんとなくログを出していました。
「エラーが起きたら怖いから、とりあえず try-catch してログに残しておこう」
「ないよりはマシだろう」

でも、いざ本番で障害が起きたとき、そのログは僕を助けてくれませんでした。
深夜のアラート対応で、システムエラーが発生しました とだけ書かれたログを前に途方に暮れた経験、皆さんにもありませんか？

今回は、そんな「なんとなくログ」を卒業し、トラブルシューティングや分析に本当に役立つ「使えるログ」を設計するために学んだことをまとめました。

ログの目的を再定義する

そもそも、なぜログを書くのでしょうか？ チームで決まっているからではなく、エンジニアとして以下の3つの目的を意識する必要があります。

1. トラブルシューティング（Why & Where?）
   • 「なぜ落ちたのか」「どこで落ちたのか」を特定し、バグを再現・修正するため。
2. 可観測性・分析（Observability）
   • 「この機能、どれくらい使われてる？」「処理に何秒かかってる？」といったシステムの健康状態やユーザー行動を知るため。
3. 監査・セキュリティ（Security）
   • 「いつ、誰が、重要なデータを変更したか」の証跡を残すため。

これらを意識すると、「とりあえず出力」ではなく「目的に合わせて出力」する必要があることに気づきます。

構造化ログってなんや

ログ設計を学ぶと必ず出てくるのが「構造化ログ（Structured Logging）」です。

構造化ログとは「ログを人間への手紙ではなく、機械へのデータとして扱う」ということです。

非構造化ログ

従来のテキスト形式のログです。

// 人間には読めるけど、機械（検索）には辛い
Log::error("User 123 failed to login from 192.168.0.1");

これだと、「ユーザーID 123 のエラーだけ集計したい」と思ったときに、正規表現で頑張って文字列解析をしなければなりません。
ログの文言が少し変わっただけで検索できなくなるので、運用が非常に辛くなります。

構造化ログ

ログをJSONなどの形式で出力します。

// メッセージとデータを分ける
Log::error("Login failed", [
    "user_id" => 123,
    "ip_address" => "192.168.0.1",
    "event" => "auth_error"
]);

これが出力されると、以下のようなJSONになります。

{
  "level": "ERROR",
  "message": "Login failed",
  "context": {
    "user_id": 123,
    "ip_address": "192.168.0.1",
    "event": "auth_error"
  },
  "datetime": "2024-01-07T12:00:00+09:00"
}

こうしておけば、DatadogやCloudWatch Logsなどのログ管理ツールで context.user_id = 123 のようにクエリ一発で検索・集計ができます。

現代のWeb開発では、ログは「読むもの」ではなく「検索・集計するもの」です。
構造化ログはマストと言えます。

ログ設計の実践

では、実際にコードを書くときに何を意識すべきでしょうか。

やるべきこと

コンテキスト（文脈）を含める

「エラーです」だけでは無意味です。
「その時何が起きていたか」の情報を連想配列（Context）として渡しましょう。

何が起こったかを把握するためにも 5W1H を意識するといいかもですね。

• 誰が？ (User ID)
• 何を？ (Input Data)
• どこで？ (Request URL, IP Address)

トレースID (Trace ID / Request ID) を通す

これが今回一番の学びでした。
「1回のリクエスト」に対して、ユニークなID（Trace ID）を割り当て、それを全てのログに含めます。

// 理想的なログ出力
{
    "message": "DB error",
    "request_id": "a0eebc99-9c0b...",  // これ
    "user_id": 101
}

これがあれば、マイクロサービスや非同期処理でログがバラバラになっても、IDで検索して「一連の処理の流れ」を追うことができます。

Laravelなどでは、ミドルウェアで自動的にIDを発行し、Log::shareContext() 等を使って全ログに自動付与する設定を入れておくと、コードを書くときに意識しなくて済むので最高です。

ログレベルを適切に使い分ける

チーム内の基準に従いましょう。ない場合は基準を決めておきましょう。

下記は一例です。

• ERROR: 即時対応が必要（深夜でも電話がかかってくるレベル）。
• WARN: 異常だがシステムは稼働継続可能（後で要確認）。
• INFO: 正常系イベント（KPI分析や動作確認用）。
• DEBUG: 開発時のデバッグ用（本番では出さない）。

アンチパターン

機密情報の出力

パスワード、アクセストークン、クレジットカード番号、個人情報（PII）をログに出してはいけません。

ログファイル自体が漏洩したときのリスクが甚大です。平文なのでね。

「とりあえずcatchしてログ」による握りつぶし

一番やりがちなやつです。

try {
    $user->save();
} catch (Exception $e) {
    // 最悪なパターン：エラーが起きた事実だけログして、処理を続行してしまう
    Log::error("Error happened"); 
}

これだと、データ不整合が起きているのにシステムが動き続け、後で原因不明のバグになります。
対処できないエラーはログに出すだけでなく、適切に例外を再スローするか、エラーレスポンスを返す必要があります。

ログ運用

「ログをどこに出すか」も重要です。

DockerやKubernetesなどのコンテナ環境では、「標準出力（stdout/stderr）に吐く」のが定石です（The 12-Factor Appの思想）。

アプリは標準出力にJSONを流すだけ。あとはFluentdやDatadog Agentがそれを拾って、S3やログ管理基盤に転送する。アプリは「ログの保存場所」に関知しない設計にするのがモダンな運用です。

5. ログローテート

最後に、地味だけど大事な「お掃除」の話です。 もしファイルにログを出力する場合、書き続けるといつかディスクが溢れます。数GBのテキストファイルを開こうとしてエディタが固まった経験、ありますよね？
（いつぞやに対応したEC2のアラート対応で、15GBのログファイルがサーバーを圧迫していた事件がありました。）

• ローテート（Rotation）： 日次やサイズ指定でファイルを分割する（例: app.log -> app.log.2024-01-07）。
• 保持期間（Retention）： 「14日経過したら削除する」といったルールを決める。

PHP（Monolog）なら RotatingFileHandler を使うことで簡単に実装できますし、Linuxの logrotate コマンドで管理することもあります。

「ディスクフルでサーバーダウン」は一番悲しい障害なので、リリース前に必ず確認しましょう。

おわりに

ログ設計を見直すことは、「未来の自分やチームメイトへの思いやり」です。

障害発生時、適切なログ（構造化され、Trace IDがあり、必要な情報が詰まっているログ）があれば数分で解決できる問題が、ログがないために数日かかることもあります。

「何かあったときに、このログを見て原因がわかるか？」 「一年後の自分がこのログを見て感謝するか？」

そう自問しながら、明日からの Log::info() を書いていきたいと思います。

先日、同僚との雑談の中でこんな一言が飛び出し、思わずコーヒーカップを持つ手が止まりました。

「単一テーブルの更新なら、わざわざトランザクション貼らなくても良くない？」

なるほど、確かに。「ユーザーの名前を変更する」みたいなSQLが1行だけなら、データベースの自動コミット（Auto Commit）が働くし、失敗してもエラーが返るだけ。
わざわざ BEGIN~COMMIT で囲う必要なんてない、という意見も一理あるように聞こえます。

でも、「本当にそれで大丈夫？」 と問いかけると、実は冷や汗をかくような落とし穴が潜んでいるんです。

今日は、私がなぜ「単一テーブルでも（場合によっては）トランザクション推奨派」なのか、技術的な挙動と「防御的プログラミング」の観点から整理してみたいと思います。

単一テーブル更新時（単純なUPDATE/INSERT）：実は同僚が正しかった？

まず、同僚が言っていた「単一テーブルへの単純な更新」についてです。

UPDATE users SET name = 'Tanaka' WHERE id = 1;

正直に言います。
データの物理的な整合性（ACID特性）という点では、同僚の言う通り「トランザクションは必須ではありません」。

現代のRDBMS（MySQLやPostgreSQLなど）は非常に優秀です。
この1行のSQLが実行されるとき、DB内部では自動的にトランザクションのような処理が走り、以下を保証してくれます。

• データ行の書き換え
• インデックス（B-Treeなど）の更新
• 一意制約などのチェック

これらは「成功するか、失敗するか」のどちらかであり、「データは書き換わったけどインデックスが壊れた」なんてことは起きません。

それでも私が「トランザクション枠」を作る理由

では、なぜ私はそれでもトランザクションを貼ることが多いのか。それは「未来のバグを防ぐため（防御的プログラミング）」です。

今は「名前の変更だけ」かもしれません。
でも半年後、仕様変更で「名前変更の履歴もログテーブルに残して」と言われたら？

もしトランザクションの枠組み（DB::transaction など）がないコードだと、改修担当者がうっかり履歴保存処理を単に追加するだけで、トランザクション漏れを起こすリスクがあります。

最初から「更新処理の塊」として定義しておけば、処理が増えても安全です。
「転ばぬ先の杖」として、設計の意図をコードに残す意味でも価値があると思っています。

単一テーブル更新時（SELECTが絡むとき）：ここが最大の落とし穴

「単一テーブルだから大丈夫」と油断して一番痛い目を見るのが、Read-Modify-Write（読んで、加工して、書く）のパターンです。

例えば、銀行口座や在庫の管理など、「今の値を取得して、計算して、更新する」処理です。

1. SELECT: 現在の残高を取得（例：1000円）
2. App: アプリ側で500円引く計算（1000 – 500 = 500）
3. UPDATE: 残高を「500円」で更新

これを安全に行うには、読み取る時点で排他ロック SELECT ... FOR UPDATEが必要です。

トランザクションがないとロックは機能しない！

ここで重要なのが、「ロックの寿命はトランザクションの終わりまで」というルールです。

もし明示的にトランザクションを貼らずに FOR UPDATE を投げたとしましょう。

-- トランザクションなしの場合

-- ① ロック付きで読む... つもりだが
SELECT balance FROM accounts WHERE id = 1 FOR UPDATE;
-- ★ ここでAuto Commitが働き、即座にトランザクション終了＆ロック解除！

-- （この計算処理中に、他の人が割り込めてしまう！）

-- ② 更新
UPDATE accounts SET balance = 500 WHERE id = 1;

このように、トランザクションの枠がないと、せっかくのロックが一瞬で外れてしまい、競合（Race Condition）によるデータ不整合を防げません。

単一テーブルであっても、「ロジックを含んだ更新」をするならトランザクションは必須なのです。

SELECT * FROM users WHERE id = 1 FOR UPDATE;

use Illuminate\Support\Facades\DB;
use App\Models\User;

DB::transaction(function () use ($userId) {
    // ▼ ここでロック
    $user = User::lockForUpdate()->find($userId);

    /** 
    * この時点でレコードはロックされています。
    * 他のトランザクションは、この行を lockForUpdate しようとすると
    * ここで待機状態になります。
    */

    $user->balance = $user->balance - 500;
    $user->save();
}, 3); // デッドロック対策。リトライ処理

複数テーブル更新時：言わずもがなの大本命

最後に、これはもう「必須」と言って反対する人はいないでしょう。複数テーブルにまたがる更新です。

• users テーブルにユーザーを作成
• profiles テーブルに初期プロフィールを作成

もしトランザクションがなかったら、「ユーザーは作れたけど、プロフィール作成でエラーが出た」という状態で処理が終わり、「プロフィールを持たない不完全なユーザー」がDBに残存してしまいます。

これを防ぐのがトランザクションの 「All or Nothing（全部やるか、全部やらないか）」 という鉄の掟です。ここは議論の余地なしですね。

トランザクションは「お守り」ではなく「シートベルト」

「単一テーブルならトランザクションはいらない」という意見は、単純な値のセット（Setter的な動作）においては技術的に正解です。

しかし、バックエンドエンジニアとしてのスタンスは以下の通りが良いのではないでしょうか。

1. 単純な更新（UPDATE一発）なら： 必須ではないが、将来の拡張性を考えて貼っておくと安心。
2. 読んでから書く（SELECT + UPDATE）なら： ロックを維持するために絶対必須。単一テーブルでも関係ない。
3. 複数テーブルなら： 絶対必須。

DBはアプリケーションの心臓部です。「たかが単一テーブル」と侮らず、愛と敬意（そして適切なロック）を持ってトランザクションを貼っていきましょう！

「違いはわかったけど、実際の開発でどう役立つの？」

そう思った方もいるかもしれません。 実は、この使い分けを徹底すると、「運用の楽さ」 が劇的に変わるんです！

今回は実践編として、「例外の種類によって、Slack通知やエラー画面を自動で振り分ける方法」 をご紹介します。

すべてのエラーを通知していませんか？

開発現場でよくあるのが、「エラーが出たら全部Slackに通知！」という運用。 これ、最初はいいんですが、だんだんこうなりませんか？

• 深夜に「DB接続タイムアウト」の通知が来て叩き起こされる（でも数秒後に自然復旧してる）

• 通知が多すぎて、本当に重要なバグ報告を見逃す

• 結果、「通知チャンネル誰も見なくなる」 現象が発生…

これは、「バグ（緊急）」 と 「環境トラブル（要確認）」 を混ぜてしまっているのが原因です。

「型」で振り分ける実装パターン

ここで、前回の知識が活きてきます。 例外ハンドラー（エラーを一元管理するクラス）で、以下のように振り分けてみましょう。

use Psr\Log\LoggerInterface;

class AppExceptionHandler
{
    public function __construct(
        private LoggerInterface $logger,
        private SlackNotifier $slack
    ) {}

    public function handle(\Throwable $e): void
    {
        // パターン1：LogicException / DomainException
        // 意味：「コードがおかしい（バグ）」
        if ($e instanceof \LogicException) {
            // これは緊急事態！開発者にすぐ知らせる
            $this->logger->critical($e->getMessage());
            $this->slack->send("🚨 緊急: 実装バグが発生！すぐ直して！: " . $e->getMessage());
            
            // ユーザーには「システムエラー」とだけ表示
            $this->renderErrorPage(500);
            return;
        }

        // パターン2：RuntimeException
        // 意味：「外部要因で失敗（環境エラー）」
        if ($e instanceof \RuntimeException) {
            // ログには残すけど、深夜に叩き起こすほどではないかも
            $this->logger->error($e->getMessage());
            
            // ユーザーには「現在混み合っています」など、やんわり伝える
            $this->renderErrorPage(503);
            return;
        }

        // その他の予期せぬエラー
        $this->logger->error('Unknown Error: ' . $e->getMessage());
        $this->renderErrorPage(500);
    }
}

この設計のメリット

こうすることで、開発チームの動き方が変わります。

1. Slack通知が来たら「即対応」

   • LogicException だけが通知されるので、「通知 = 自分のコードミス」と認識できます。

2. ログが綺麗になる

   • 一時的な接続エラーなどはログファイルに溜まるだけなので、精神衛生上とても良いです（もちろん定期的なチェックは必要ですよ！）。

3. ユーザーへの案内が親切になる

   • バグなら 500、アクセス過多なら 503 と、状況に合わせたHTTPステータスコードを返せます。

例外処理は「未来の自分」へのメッセージ

例外クラスを使い分けることは、単なるルールではありません。

• LogicException を投げるときは、「これバグだから絶対直してね！」というメッセージ。

• RuntimeException を投げるときは、「運用でカバーしてね」というメッセージ。

この意図を込めてコードを書けるようになると、一人前のエンジニアへまた一歩近づけます。 「エラーハンドリング」という地味な部分ですが、こここだわるとカッコいいですよ！

ぜひ、自分たちのプロジェクトにも導入できないか検討してみてくださいね。

「全部 Exception クラスを使っちゃってるけど、これっていいの？」

PHPを勉強し始めて少し経つと、こんな悩みが出てきませんか？ 実は、僕も最初はそうでした。

でも、「例外の型（種類）」 を適切に使い分けるだけで、コードの品質がグッと上がり、バグの原因究明が驚くほど早くなるんです。

今回は、PHPの標準例外（SPL）の中でも特に重要な LogicException、DomainException、RuntimeException の3つについて、「現場ではどう使い分けているのか」 を解説していきます！

なぜ使い分ける必要があるの？

結論から言うと、「誰のせいなのか」 をはっきりさせるためです。

エラーが起きたとき、それが「プログラマーのミス（バグ）」なのか、「運悪くサーバーが落ちた（環境要因）」のかによって、対応方法は変わりますよね？

• バグなら → コードを修正しないといけない

• 環境要因なら → リトライしたり、ユーザーに「混み合ってます」と伝えたりする

これをクラスの型で表現するために、使い分けが必要なんです。

LogicException（ロジック例外）

「これは開発者のミス！ コードを直して！」

これは、「プログラムの論理がおかしい」ときに投げる例外です。 基本的に、本番環境でこれが出たらアウト。即修正案件です。

例えば、「APIキーをセットしていないのに、リクエストを送ろうとした」みたいなケースですね/p>

class ApiClient
{
    private ?string $apiKey = null;

    public function setApiKey(string $key): void
    {
        $this->apiKey = $key;
    }

    public function request(): void
    {
        if ($this->apiKey === null) {
            // 開発者がセットアップ手順を間違えているため、LogicException
            throw new \LogicException('API Keyが設定されていません。request()の前にsetApiKey()を呼んでください。');
        }

        // リクエスト処理...
    }
}

この例外が出たら、catch して握りつぶすのではなく、コード自体を直しましょう。

2. DomainException（ドメイン例外）

「そのデータ、仕様としてありえないよ！」

これは LogicException の親戚みたいなものです。 「ロジックは動くけど、渡されたデータがビジネスルール（仕様）としてありえない」場合に使います。

例えば、「信号機の色」を扱うクラスがあったとして、「紫」を指定されたら困りますよね？

class TrafficLight
{
    private const ALLOWED_COLORS = ['red', 'yellow', 'blue'];

    public function __construct(private string $color)
    {
        if (!in_array($color, self::ALLOWED_COLORS, true)) {
            // 定義外の値がコードから渡された！
            throw new \DomainException("色 '{$color}' は信号機に存在しません。");
        }
    }
}

ユーザーの入力ミスというよりは、「コード上で変な値を渡してしまった」ときに検知するためのものです。

3. RuntimeException（実行時例外）

「コードは合ってるけど、環境のせいで失敗しました…」

一番よく使うのがこれです。 コードは正しいけれど、「DBに繋がらない」「ファイルがない」「外部APIが落ちてる」 といった、実行時の状況（Runtime）によって起きるエラーです。

class ConfigLoader
{
    public function load(string $filePath): array
    {
        if (!file_exists($filePath)) {
            // パスは合ってるはずだけど、ファイルが消えてる（実行時の事情）
            throw new \RuntimeException("設定ファイルが見つかりません: {$filePath}");
        }
        
        // 読み込み処理...
    }
}

このエラーが出たときは、try-catch で捕まえて「ただいま混み合っております」のようなエラー画面を出してあげる必要があります

まとめ

• Logic / Domain 系

  • 意味：「コードのバグ」

  • 対応：コードを修正する（Catchして無視しちゃダメ！）

• Runtime 系

  • 意味：「実行時のトラブル」

  • 対応：エラー画面を出したり、ログに残したりして運用でカバーする

この意識を持つだけで、「エラーが起きたときに何をすればいいか」が一瞬でわかるようになります。 ぜひ、明日からのコーディングで意識してみてくださいね！

AIに頼めば、ものの数秒で大量のコードが生成されます。
まるで魔法のようですが、同時にこうも思うのです。「これ、本当に動くの？」「仕様、合ってる？」と。

大量に出力されるコードの波に飲まれず、「人間が手綱を握り続ける」ために僕が実践してきた開発のTipsを書き残しておきます。

これは、2026年の自分への手紙でもあります。
「あの頃はそんな苦労をしてたんだな」と笑って読み返せますように。

機会にできることは機械に任せる（Lint / Pre-commit / Auto Format）

AIは優秀ですが、たまにインデントを崩したり、変な書き癖を出してきたりします。
生成された大量のコードを目視でレビューして「ここ、スペース空いてないよ」なんて指摘するのは、人間のやる仕事じゃありませんよね。

だからこそ、Lint と Pre-commit、そして 自動フォーマット は必須でした。

• 保存＝整形（Auto Format）
  エディタで保存した瞬間に、コードが綺麗になる設定はマスト。AIが吐き出したコードを貼り付けた瞬間、プロジェクトの規約に合わせて「シュッ」と整う快感。これがないと精神衛生が保てません。
• コミット前の門番（Pre-commit）
  Gitにコミットする前に、Linterが自動で走るように設定しました。型エラーや未使用変数は、人間が気づく前に機械に弾いてもらう。

「コードの見た目」や「単純なミス」に脳のメモリを使わない。これがAI時代を生き抜く第一歩でした。（AI開発がどうっていう話ではないがより一層重要になっている

実装指示は細かくStepByStep形式

最終的なゴールを明示したうえで、StepByStepで実装させました。

ゴールは .documents にMarkdownを配置し、その仕様書通りになるように指示をします。

## As Is

## To Be 

## Task

## Remarks

1. 〇〇を最終ゴールとします。実装方針を出して。
2. ツッコミを入れる
   • Step1の実装のセキュリティホールは？
   • タイムアウトの条件は〇〇に
3. テスト書いてもらう
4. もちろんRed
5. テストのレビュー
   • テスト問題なければ実装
   • 問題あれば2を見直す
6. テストがGreenになるような実装

この辺はガイドラインやコーディング規約などを整備すればよかったのかなぁと考えている反省点です。

テスト戦略：AIに任せる部分、僕が譲らない部分

ここが一番のキモです。
AIはコードを書くのは早いですが、「僕たちが本当に作りたいもの」を100%理解しているわけではありません。
だからテストの役割分担をこう決めました。

単体テスト（ViteTest / PHPUnit）

関数単体や小さなロジックの検証には、ViteTestやPHPUnitを使いました。
ここはAIにも手伝ってもらいやすい領域です。「この関数のテスト書いて」と言えば、エッジケースまで網羅したテストを提案してくれます。

※ 単体テストをAIに書いてもらうために、関数は限りなく小さくするような単一責任の原則でAIに実装してもらっています。ぜーんぶAIです。

Featureテスト（結合・機能テスト）は「僕」が書く

けれど、機能全体が正しく動くかを確認するFeatureテストだけは、僕自身の手で書くようにしました。
これには明確な理由が2つあります。

1. コードの理解：
   AIが書いたブラックボックスなコードも、テストを書く過程で読み解く必要があります。「どう動くべきか」を定義するのは人間です。
2. 要求仕様の達成：
   求められている「要件」を満たしているか判定できるのは、今のところまだ人間だけです。

「AIにコードを書かせるなら、人間はテスト（仕様）を書け」 これが2025年の僕の合言葉でした。
テストが通る＝仕様を満たしているという安心感があって初めて、AIのスピードを享受できるんです。

2026年の僕へ

どうですか？ 2026年の開発現場は。

AIが仕様の矛盾すら指摘して、テストまで完ぺきに書いてくれるようになっているのでしょうか。

もしそうなっていたとしても、2025年の僕は「正しく動くものを届けたい」という一心で、Linterを設定し、Featureテストを書いていたことを覚えていてください。

エンジニアとしての仕事に楽しさは残っていますか？2025年末では、だんだんと辛くなってきています。

それじゃ、また。良い開発ライフを！