ID:83877さん

保守性が低下していたレガシー自社フレームワーク+EC2構成のふるさと納税ポータルサイトを、Laravel+ECS構成へ全面リアーキテクチャするプロジェクトです。モダンな開発プロセスへの移行が困難になっていたことが背景にあり、チーム内でも自社フレームワークからの脱却は共通課題として認識されていました。本プロジェクトで私はアプリケーション側の主担当を務めました。 担当領域はアプリケーション側です。コンテナがスケーリングで頻繁に入れ替わるECSでは、セッション等をコンテナ内に保持できない——このチーム共通認識のもと、状態の外部化に伴う処理側の実装を担当しました。セッションのRedis化は処理への組み込みと設定調整を担当。ジョブキューは、他チームのAPI開発での採用実績を知っており、本件でも重い処理のタイムアウトが問題になると予見できたため、Redisジョブキューの導入を自ら提案して実装しました。バッチ処理はECSスケジュールタスクへの移行に伴う各バッチの作成と適用調整を担当し、スケジュールタスク定義のTerraformファイルはGitHub Copilotを活用して自分で作成、Terraform管理を担うインフラ担当と調整のうえ適用しています。また、都道府県・地域情報などマスターデータのキャッシュ処理も自ら提案し実装しています。Redis基盤・キューワーカー・スケジュールタスク自体の構築はインフラ担当(Terraform管理)が主導しており、私は「この処理のためにこの設定が必要」という要件を随時相談しながら進めました。 品質面では、PM(課長)が設計したMR承認フローに意見を出しながら参画しました。運用開始後、課長のみがレビューする体制でレビュー待ちの滞留と課長への負荷集中が起きたため、一次レビュー担当を自ら申し出て二段レビュー体制に改めています。テストはPMが作成したUnit/Featureテストの骨組みに沿い、GitHub Copilotを活用しながらテストコードを実装しました。 性能面では、本番相当データで応答の遅い箇所があり、「体感ではなく、改善したことをローカルで定量判定できる状態を先に作りたい」と考えました。GitHub Copilotを壁打ち相手に、性能ログへクエリ数・DB I/O比率・実行時間の計測を追加する計装を導入。この計測で、約250万件のデータに対する検索の20〜30秒の遅延が%LIKE%検索の全件走査に起因すると特定しました。改善策はCopilotに複数の候補を挙げさせた上でFULLTEXTインデックスの導入を私が選定し、実行時間ログで数秒台への改善を確認。計装からはアクセサ経由処理のEagerLoad宣言漏れも発見し、修正しています。AIの提案をそのまま使うのではなく、候補の比較と採否判断を自分が握る進め方は、個人のAI開発環境運用でも実践している方針です。 ローカル開発環境のベースイメージ選定、Dockerfile・docker-compose作成、GitLab CIによるビルド〜ECRプッシュジョブの構築も担当し、2026年6月に本番リリースを完遂しています。

シリアルコード型の新規ふるさと納税サイトとその管理CMSを、ゼロから立ち上げたプロジェクトです。技術スタックとインフラ構成を白紙から決められる一方、選定を誤ると長期の負債になる局面でした。 かねてよりチーム内で「フロントとバックエンドを分離した構成を試したい」という会話があり、本案件で課長(PM)がBFF構成——フロントエンドNext.js(App Router)+Nginx、バックエンドPHP-FPM+Laravel——を提案。部長・CTO・ECS構築経験のある他部署インフラ担当への相談を経て採用が決まりました。管理CMSはNginx+PHP-FPM・Laravel構成です。 2名とも初めて扱う技術スタックだったため、ライブラリ選定や実装ノウハウを相互に共有しながら開発を進め、私はフロントエンド(Next.js)の実装を比重多く担当しました(GitHub Copilotを活用)。画像ストレージについては、他サイトで実績のあるEFSがFargate構成では一般的である一方、コスト面が課題でした。画像キャッシュ用に導入予定だったCloudFrontのオリジン・ビヘイビア設定でS3バケットと接続すれば、CMSとサイトで画像を共有しつつEFS自体を不要にできると考え、インフラ担当と相談・検討のうえこの構成を採用しています。この検討は、後のリアーキテクチャにおける静的配信のS3+CloudFront化にも繋がりました。 認証はBFF構成に合わせ、従来のセッション管理からトークン方式へ変更し、リフレッシュトークンを併用する形で実装しました。バッチ実行基盤についてはBref+Lambdaでの実行も検証し、のちのECSスケジュールタスク採用の判断材料としています。 加えてバックエンドのLaravel実装、インフラエンジニアと協議しながらのECS構成の初期インフラ策定、Dockerfile作成、GitLab CIによるビルド〜ECRプッシュジョブの構築を担当し、期間内に新規サイトのリリースを完遂しています。

企業運営ポータルサイトの管理CMSをEC2環境で新規開発したプロジェクトです。部内ではそれまで自社フレームワークのみで開発されており、本案件が部内初のLaravel採用案件となりました。Laravel採用の提案は同僚エンジニア(現・課長)が主導し、私は選定の補佐と開発を担当しています。 課題は短期スケジュールでした。管理画面のUIをスクラッチで作る工数は残されていなかったため、管理画面テンプレートのAdmin-LTEを活用する方針を自ら提案。UI構築の工数を圧縮してドメインロジックの実装に時間を割り当てる判断で、期間内のリリースを実現しました。 この案件を起点に、その後の新規サイト開発(BFF構成)や既存サイトのリアーキテクチャでも部内でLaravelが標準的に採用されるようになり、私自身もそれらの案件で技術リード・主担当を務める流れに繋がっています。

リアーキテクチャの7名並行開発が始まったことで、それまで顕在化していなかった問題が表面化しました。各メンバーのローカル(WSL)環境の差異によりコードフォーマッタ(Pint)の設定に不整合が生じ、ポート競合が開発のボトルネックになっていました。 個別に直しても人が増えるたびに再発するため、環境そのものを配布物にする方針を取り、DevContainer導入を提案・構築して設定をコンテナ内に完全統一しました。ポート競合には防止ツール「tug」を導入し、ツールは入れるだけでは定着しないため勉強会を開いて全メンバーへ浸透させています。さらに、フォーマットと静的解析を人の注意力に依存させないよう、GitLab CIにPint/PHPStanの自動実行ジョブを追加し、品質チェックをCI段階で強制する形にしました。 結果として、環境差異起因のトラブルと属人性を排除し、新規メンバー参画時の環境構築工数を大幅に削減。コード品質がCI段階で恒久的に担保される仕組みになっています。

放送局・鉄道会社・大手コンビニエンスストア・自治体など、複数の運営主体が展開するふるさと納税ポータルサイト/管理CMSの機能開発・保守運用を担当しています。エンジニアは私1名のため、技術面の調査・設計・実装・障害対応の意思決定を一貫して担う体制です。 主な実績: 決済機能追加(Amazon Pay・3Dセキュア)、不正検知サービスのAPI連携実装(注文時の配送先住所・電話番号を外部判定システムに連携し、判定結果で処理を分岐)、PHP/MySQLバージョンアップ対応、OEM連携機能開発、専用LP管理機能開発。また、ソース管理のSVN→GitLab移行(課長主導)に中核メンバーとして参画し、ブランチ戦略の検討を課長と共に行ったほか、本番・ステージング環境のソース差異の確認・調整から開発用ブランチへの反映までの移行作業を担当しました。

データセンター運用監視業務に客先常駐で従事し、8名チームのリーダーを担当しました。AWS/GCP上に構築されたサービスのリソース監視・ログ監視、障害一次対応・エスカレーションを実施。AWSマネジメントコンソールでのリソース確認、Lambda・CloudShellでのバッチ実行、LinuxサーバへのSSHオペレーションを日常的に担当しています。 チームリーダーとしては、障害発生時の指示出し、アラート発生時のメンバーへの対応割り振り、次シフトへの引継ぎ仕様の作成と実施を担当。また、既存のSlack Bot(GAS)の改修・保守による業務効率化や、Vue.jsを用いた社内教育システムの開発への参画(途中参加。中心メンバーの退場後は保守・機能追加のヒアリングを担当)も行いました。この3年で「障害がどう起き、どう検知されるか」を体で覚えたことが、現在の開発業務における設計判断(計装の導入、検知可能性を考えた実装)の土台になっています。

Claude CodeとOSSのマルチエージェント基盤「multi-agent-shogun」(階層型エージェント構成)をフォークし、自然言語の指示から要件定義→実装→品質チェックまでを自動実行する個人の開発環境として構築・運用しています。動かすだけでなく、運用で起きた問題を仕組みで解決することをテーマにしています。 【運用で直面した課題と工夫】 - 待機中のポーリングによるAPI消費が無視できなかったため、inotifywaitを用いたイベント駆動方式へ変更し、待機コストをゼロ化しました - エージェントの停止や無応答が「静かに」発生して検知できない事象があったため、障害が必ず音を立てるフェイルラウド設計(死活監視と例外時のみの通知)に改めました - エージェントによる意図しないファイル書き込みを防ぐ書き込みガードを導入しました - 承認フローは「可逆な操作は自動進行、不可逆な操作は人間の承認必須」という基準で分岐させています - AIのレビュー指摘は採用/棄却を記録し、委任範囲の判断材料として蓄積しています これらの構築・運用の知見(モデル更新の自動適用をやめて検知だけ自動化した判断、監視スクリプトの誤判定対応など)はZennで継続的に記事化しています。AIへの委任と人間の判断の線引きを、実運用のデータに基づいて改善し続けることがこの取り組みの中核です。

Go言語の学習を目的とした個人開発です。複数の情報源(RSS/GitHub)を定期チェックし、新着を検知・通知する常駐プログラムを、Goの標準ライブラリ中心で開発しています(net/http、encoding/xml、goroutine/channelによる並列fetch、contextによる制御)。 学習の進め方に方針を設けています。業務ではAIコーディングを活用していますが、本プロジェクトでは「AIには解説とコードレビューのみを依頼し、コードはすべて自分で実装する」という制約を課しています。言語の基礎体力は自分の手で書いてしか身につかないと考えているためです。AIのレビュー指摘は採用/棄却を記録しながら進めており、「解説→自力実装→レビュー」のサイクルで学習過程をドキュメント化しています。