ID:83877さん

### プロジェクト経験概要 保守性が低下していたレガシー自社フレームワーク+EC2構成のふるさと納税ポータルサイトを、Laravel+ECS構成へ全面リアーキテクチャしました。旧構成ではフレームワークの制約からテストコードを使えず、モダンな開発プロセスへの移行が困難になっており、自社フレームワークからの脱却はチーム共通の課題でした。2026年6月に本番リリースを完遂しています。 ### チーム情報 - 上長、アプリケーション担当3名(私を含む)、インフラ担当ほか、計7名 - 役職上の肩書はない対等な体制 - 以下のうち、ジョブキュー・キャッシュの提案、一次レビュー体制の立ち上げ、性能改善、インフラ担当との連携は、私が主体となって進めた部分です ### 開発・実装内容A: 性能問題の計装と検索の高速化 **【概要】** 本番相当データで応答が遅い画面について、計測の仕組みを先に作り、原因を特定してから改善しました。 **【どのような機能の開発・実装か】** - 性能ログへの計装の追加(担当:**自分**) - 約250万件のデータに対する検索処理の改善(担当:**自分**) **【課題・問題点】** - 約250万件のデータに対する検索で、20〜30秒の応答遅延が発生していました - 「体感で速くなった」では改善の判断ができず、修正のたびに効果を比べられる状態がありませんでした **【打ち手・使用した技術】** - 改善に着手する前に、ローカルで定量判定できる状態を作ることを優先し、性能ログにクエリ数・DB I/O比率・実行時間の計測を追加しました(**自分**) - 計測の結果、遅延の原因が `%LIKE%` 検索による全件走査であると特定しました(**自分**) - 改善策はGitHub Copilotに複数の候補を挙げさせ、比較したうえでMySQLのFULLTEXTインデックス導入を私が選定しました(**自分**) - `%LIKE%` の中間一致では通常のインデックスが効かないため、追加費用をかけずにインデックスを効かせられる方法としてFULLTEXTを選びました - Elasticsearchも検討しましたが、新たなサービス利用で費用が発生すること、チームに知見がなく実装に時間がかかりリリースに間に合わないと判断し、見送りました - 日本語検索のためngramパーサを使い、トークンサイズは2に設定しました。既存の `%LIKE%` 検索の挙動にできるだけ近づけるためです - 実行時間ログで、数秒台への改善を確認しています - 同じ計装から、アクセサ経由の処理でEagerLoadの宣言漏れによるN+1を発見し、修正しました(**自分**) ### 開発・実装内容B: Redisジョブキューの導入 **【概要】** 重い処理を非同期化するため、Redisジョブキューの導入を提案し実装しました。 **【どのような機能の開発・実装か】** - ジョブキュー導入の提案(担当:**自分**) - アプリケーション側のジョブ実装(担当:**自分**) - キューワーカー・Redis基盤の構築(担当:**インフラ担当**) **【課題・問題点】** - 画像の保存処理(URLからの画像ダウンロード、画像名のテーブル登録、S3への保存)は時間のかかる処理で、新構成で同期実行するとタイムアウトが問題になると予見していました **【打ち手・使用した技術】** - 他チームのAPI開発でジョブキューの採用実績があることを知っており、本件にも適用できると判断して自ら提案しました - Laravelのキュー機能を使ってジョブを実装し、ワーカーに必要な設定をインフラ担当へ要件として伝えて構築してもらいました ### 開発・実装内容C: 状態の外部化(セッションのRedis化) **【概要】** ECS移行に伴い、ファイルで保持していたセッションをRedisへ移しました。 **【どのような機能の開発・実装か】** - セッションの保存先をファイルからRedisへ変更する処理への組み込みと設定調整(担当:**自分**) - Redis基盤の構築(担当:**インフラ担当**) **【課題・問題点】** - ECSではスケーリングでコンテナが頻繁に入れ替わるため、セッション等の状態をコンテナ内に持てません(チーム共通の認識) **【打ち手・使用した技術】** - LaravelのセッションドライバをRedisへ切り替え、既存処理への組み込みと設定調整を行いました ### 開発・実装内容D: マスターデータのキャッシュ **【概要】** 都道府県・地域情報などのマスターデータのキャッシュ処理を提案し、実装しました(担当:**自分**)。 **【どのような機能の開発・実装か】** - 更新頻度が低いマスターデータをRedisにキャッシュする処理 **【課題・問題点】** - 以前から、Botによる過剰アクセスでDBリソースが高騰することが問題になっていました - 小さな部分でも、削減できるDBアクセスはなくすべきだと考えました **【打ち手・使用した技術】** - 対象は都道府県・地域など、更新されないマスターテーブルに絞りました - 更新がない前提のため、更新時の破棄処理は持たせず、有効期限1か月のシンプルなキャッシュにしています ### 開発・実装内容E: バッチ処理のECSスケジュールタスク移行 **【概要】** EC2上で動いていたバッチ処理を、ECSスケジュールタスクへ移行しました。 **【どのような機能の開発・実装か】** - 各バッチの作成と適用調整(担当:**自分**) - スケジュールタスク自体の構築(担当:**インフラ担当**) **【打ち手・使用した技術】** - 移行に合わせて各バッチを作成し、スケジュールタスク上で動くよう適用調整しました - 各バッチの実行に必要な設定は、インフラ担当へ要件として伝えて構築してもらいました ### 開発・実装内容F: 二段レビュー体制の立ち上げ **【概要】** MRのレビュー滞留を解消するため、一次レビュー担当を引き受けました。 **【どのような機能の開発・実装か】** - MR承認フローの設計(担当:**上長**。私は意見を出す形で参画) - 一次レビュー担当として、二段レビュー体制への変更(担当:**自分**) **【課題・問題点】** - 運用開始後、上長のみがレビューする体制だったため、レビュー待ちの滞留と上長への負荷集中が起きていました **【打ち手・使用した技術】** - 一次レビューを自ら申し出て、一次(私)→最終(上長)の二段体制に改めました - 一次レビューでは、次の3点を重点的に確認しました - 変数名・関数名が規約に沿っているか - N+1などの非効率な処理になっていないか - エラーパターンやエラーハンドリングに不足がないか - 二段体制にしたことで、上長の確認にかかる時間が減り、MRの滞留は以前より少なくなりました ### 開発・実装内容G: テストとローカル開発環境・CI **【どのような機能の開発・実装か】** - Unit/Featureテストの骨組み作成(担当:**上長**) - 骨組みに沿ったテストコード(生成:**GitHub Copilot**。機能実装とあわせて生成。テスト失敗時の軽微な修正:**自分**。テストフレームワークはPest) - テストはプッシュ時に実行されて成功しないとプッシュできない仕組みで、マージリクエストのパイプラインでも実行されます - ローカル開発環境のベースイメージ選定、開発用コンテナのdocker-compose.yaml作成(担当:**自分**) - 同じベースイメージから、ローカル開発用とECS用のステージを書き分けたマルチステージのDockerfile作成(担当:**自分**) - ベースイメージは、BFF構成の開発時と同じ理由(更新作業の手間とセキュリティ更新の期間)でDebian bookwormを採用 - ローカル用:開発ツール(tinker)を入れ、vendorはWSL上でインストールしたものをそのまま使用 - ECS用:composer.lockを参照して `composer install --no-dev` を実行し、本番に必要なパッケージだけを導入 - Nginx・PHP-FPMの設定ファイルを、ローカル用とECS用で分けて適用 - ビルドキャッシュが効く記述にし、変更のない層の再ビルドを省いてECS向けビルドを高速化 - GitLab CIによるビルド〜ECRプッシュのジョブ構築(担当:**自分**) ※ 開発環境の標準化(DevContainer等)は「開発環境の標準化・DX改善」に記載しています ### 開発・実装内容H: 旧システムからの機能移行とコードの構造 **【概要】** 旧システムの機能をLaravelへ移行・実装し、チームの規約に沿ってコードの構造を揃えました。 **【どのような機能の開発・実装か】** - 寄附者向けサイトの静的ページ・自治体・ランキング・返礼品の一覧と詳細・お気に入り・カート・お知らせ・レビューなどの移行・実装(担当:**自分**) - CMS側の外部連携・決済確認・集計などのバッチと、管理画面の一部の移行・実装(担当:**自分**) - トップ・会員登録・マイページ・決済などは、他メンバーが最初に実装(担当:**他メンバー**。自分は以降の修正に参加) - 外部APIの呼び出しをまとめる専用のクライアント層の新設(担当:**自分**) **【課題・問題点】** - 旧システムには、取得しているのにどこにも表示していないデータがありました **【打ち手・使用した技術】** - チームで旧システムのソースを読み解き、移行先でそのカラムがどう使われているかを確認しながら移行しました(**チーム**) - コントローラー・サービス・リポジトリの3層構造とコーディング規約はチームで決めたものです。上長と規約を考える中で互いに持っていた認識が、チーム内の認識として決まりました(**チーム**) - その規約に沿って、リポジトリ層の呼び出し方と例外処理を35ファイルで統一しました(**自分**) - 外部APIの呼び出しは、責任範囲を分けてテストを書きやすくし、エラーハンドリングとログを一元化して保守性を上げるため、専用のクライアント層を新設してまとめました(**自分**) ### 開発・実装内容I: フォームの遷移制御とセキュリティ対応 **【どのような機能の開発・実装か】** - 入力→確認→完了のフォームの遷移制御(担当:**自分**) - 静的解析による脆弱性検査(SAST)で検出された箇所の修正、reCAPTCHAの導入(担当:**自分**) **【打ち手・使用した技術】** - ミドルウェアとセッションロックで、途中の画面への直接アクセスと二重送信を防止しました

### プロジェクト経験概要 シリアルコード型の新規ふるさと納税サイトと、その管理CMSをゼロから立ち上げました。技術スタックとインフラ構成を白紙から決められる一方、選定を誤ると長期の負債になる局面でした。期間内にリリースを完遂しています。フロントエンドとバックエンドを分離したことで、不具合の修正時に片方だけを対応できるようになり、関係のないファイルに触れることが減って、反映時のヒューマンエラーが減りました。 ### チーム情報 - 上長と私の2名。2名とも初めて扱う技術スタックだったため、ライブラリ選定や実装ノウハウを相互に共有しながら進めました - インフラ構成は、ECS構築経験のある他部署のインフラ担当と協議 ### 開発・実装内容A: BFF構成の採用 **【どのような機能の開発・実装か】** - フロントエンドNext.js(App Router)+Nginx、バックエンドPHP-FPM+Laravelの分離構成。管理CMSはNginx+PHP-FPM・Laravel(担当:**チーム**。提案は**上長**) **【課題・問題点】** - かねてよりチーム内で、フロントとバックエンドを分離した構成を試したいという話が出ていました **【打ち手・使用した技術】** - 上長の提案をもとに、部門責任者・CTO・インフラ担当へ相談したうえで採用が決まりました - 分離した結果、不具合の修正をフロントエンドだけ・バックエンドだけで完結できるようになり、不用意にファイルを触ることが減って、反映時のヒューマンエラーが減りました ### 開発・実装内容B: Next.jsによるフロントエンド実装 **【どのような機能の開発・実装か】** - サイトのフロントエンド実装(担当:**自分**が多くを担当。GitHub Copilotを活用) - 主な画面:返礼品一覧・詳細、会員登録・ログイン、カートから寄附申込完了まで、マイページ(寄附履歴・会員情報変更・クレジットカード管理)、パスワード再設定 - 寄附申込画面での3Dセキュアなどのフロント側の連携(決済バックエンドは担当外) **【打ち手・使用した技術】** - 操作の多い画面は、Client Componentを中心に構成しました - データ取得は基本的にNext.jsのAPI RouteをBFFとして経由させ、Laravel APIと接続しています - 認証トークンをブラウザのJavaScriptから直接扱わないよう、HttpOnly Cookieを利用しています ### 開発・実装内容C: 寄附申込フローの遷移制御 **【概要】** 複数画面に分けた寄附申込フローで、途中の画面への直接アクセスや手順の飛ばしを防ぐ遷移制御を実装しました。 **【どのような機能の開発・実装か】** - 寄附申込フローの画面遷移制御(担当:**自分**) **【課題・問題点】** - 寄附申込を複数画面に分けたため、途中の画面へ直接アクセスしたり、手順を飛ばしたりできないようにする必要がありました - ログインを挟む場合や、再読み込み・途中離脱後の状態も考慮する必要がありました **【打ち手・使用した技術】** - Zustandで「現在のステップ」と「到達済みの最大ステップ」を管理し、未到達の画面にアクセスした場合はカートへ戻すようにしました - ログインを挟んだ場合や、再読み込み・途中離脱後のケースに合わせて状態のリセットや遷移先を調整し、動作検証を繰り返して仕上げました ### 開発・実装内容D: 画像ストレージのS3+CloudFront化 **【概要】** CMSとサイトで画像を共有する方式として、EFSを使わない構成を考え、インフラ担当と検討して採用しました。 **【どのような機能の開発・実装か】** - 構成の発案(担当:**自分**) - 構成の検討・構築(担当:**自分+インフラ担当**) **【課題・問題点】** - 他サイトで実績のあるEFSはFargate構成では一般的ですが、コスト面が課題でした **【打ち手・使用した技術】** - 画像キャッシュ用にもともと導入予定だったCloudFrontで、オリジン・ビヘイビア設定によりS3バケットに接続すれば、CMSとサイトで画像を共有しつつEFSを不要にできると考えました - この構成は、後のリアーキテクチャでの静的配信のS3+CloudFront化にもつながりました ### 開発・実装内容E: トークン方式の認証 **【どのような機能の開発・実装か】** - 認証をセッション管理からトークン方式へ変更し、リフレッシュトークンを併用する形で実装(担当:**自分**) **【課題・問題点】** - フロントとバックエンドを分離したBFF構成に合わせて、認証方式を見直す必要がありました **【打ち手・使用した技術】** - Laravel Sanctumのアクセストークンと、アプリ独自に管理するリフレッシュトークンを組み合わせました - どちらもHttpOnly Cookieに保存し、有効期限はアクセストークン1時間、リフレッシュトークン30日にしています ### 開発・実装内容F: バッチ実行基盤の検証とインフラ・CI **【どのような機能の開発・実装か】** - Bref+Lambdaでのバッチ実行の検証(担当:**自分**) - ECS構成の初期インフラ策定(担当:**自分+インフラエンジニア**の協議) - ECS構成のTerraformを、AIを活用してプロトタイプとして作成し、インフラ担当へ引き渡し(担当:**自分**。以降の管理は**インフラ担当**) - 開発用コンテナのdocker-compose.yamlと、ローカル開発用とECS用をマルチステージで書き分けたDockerfileの作成、GitLab CIによるビルド〜ECRプッシュのジョブ構築(担当:**自分**) - バックエンドのLaravel実装(担当:**自分**) **【打ち手・使用した技術】** - Bref+Lambdaを検証したところ、次の2点が制約になりました - Lambdaの最大実行時間が15分で、バッチ処理の制約になる - Lambdaごとのハンドラーや起動コマンドの設定・管理が必要になる - 既存のLaravel実行環境をそのまま使え、15分を超える処理にも対応しやすいことから、ECSのスケジュールタスクを選びました - ベースイメージとバージョンは、サポート期間の長さ・軽量さ・互換性を基準に選定しました(担当:**自分**) - Node.jsはLTSの22を、軽量なslim版(bookworm)で採用。必要なパッケージは都度追加する方針にしました - PHP-FPMは、拡張や依存ライブラリとの互換性を重視してフル版のDebianを採用。Debianは、古い版にすると更新作業が手間になることと、セキュリティ更新の期間が長いことからbookwormを選びました - Next.js 15・React 19・Laravel 12・PHP 8.4は、サポート期間内の最新安定版を採用しました

### プロジェクト経験概要 リアーキテクチャで7名の並行開発が始まり、それまで表に出ていなかった環境差異の問題が顕在化しました。個別対応ではなく仕組みで解決するため、環境そのものの配布と、品質チェックのCI化を提案・推進しました。 ### チーム情報 - 提案・構築・定着まで、いずれも**自分**が担当 ### 開発・実装内容A: DevContainerによる環境の統一 **【課題・問題点】** - 各メンバーのローカル(WSL)環境の差異で、コードフォーマッタ(Pint)の設定に不整合が生じていました - 個別に直しても、人が増えるたびに再発する構造でした **【打ち手・使用した技術】** - 環境そのものを配布物にする方針をとり、DevContainerを提案・構築して設定をコンテナ内に統一しました - 新規メンバーの環境構築時間は、約半日から2〜3時間程度に短縮されました(目安) ### 開発・実装内容B: ポート競合の解消 **【課題・問題点】** - ローカル環境でのポート競合が、開発のボトルネックになっていました **【打ち手・使用した技術】** - ポート競合防止ツール「tug」を導入しました - ツールは入れるだけでは定着しないため、勉強会を開いて全メンバーへ浸透させました ### 開発・実装内容C: Pint/PHPStanのCI自動実行 **【課題・問題点】** - フォーマットや静的解析が、各自の注意力に依存していました **【打ち手・使用した技術】** - GitLab CIにPint・PHPStan(レベル4)の自動実行ジョブを追加しました - プッシュ時とマージリクエスト作成時のパイプラインで実行し、警告があればパイプラインが失敗してマージできないようにして、品質チェックをCI段階で強制しています ### 開発・実装内容D: ローカルのS3互換ストレージの切り替え(MinIO→SeaweedFS) **【どのような機能の開発・実装か】** - リアーキテクチャとBFF構成の新規サイトのローカル環境で、画像保存用に使っていたS3互換ストレージの切り替え(担当:**自分**) **【課題・問題点】** - ローカル環境ではMinIOをS3互換ストレージとして使っていましたが、今後バージョンアップが提供されなくなるという情報を目にしました **【打ち手・使用した技術】** - 乗り換え後の違和感をなるべく減らすことを重視し、設定の変更が少なく済むことと、MinIOと同じくGUIで操作できることを基準にSeaweedFSを選びました - 両環境のdocker-compose.yamlを更新し、各メンバーに周知しました

### プロジェクト経験概要 放送局・鉄道会社・大手コンビニエンスストア・自治体など、複数の運営主体が展開するふるさと納税ポータルサイト/管理CMSの機能開発・保守運用です。会員数万人規模・返礼品数百万件規模のサイトを含みます。 ### チーム情報 - エンジニアは私1名のため、技術面の調査・設計・実装・障害対応の意思決定は一貫して**自分**が担っています ### 開発・実装内容A: 不正検知サービスのAPI連携 **【どのような機能の開発・実装か】** - 注文時の配送先住所・電話番号を外部の判定システムへ連携し、判定結果で処理を分岐させるAPI連携部分(担当:**自分**) **【打ち手・使用した技術】** - 外部APIが遅延・停止したときに返すレスポンスコードを判定し、その場合は注文処理を止める設計にしました ### 開発・実装内容B: 決済機能の追加 **【どのような機能の開発・実装か】** - Amazon Payの追加、3Dセキュア対応(担当:**自分**) **【課題・問題点】** - 決済の途中で外部サイトの画面を経由するため、自サイト内で処理が完結しません **【打ち手・使用した技術】** - 外部サイトへの遷移前後で、どこでトランザクションを区切るかを設計しました - 起こり得るエラーパターンを洗い出して対応しました ### 開発・実装内容C: PHP/MySQLのバージョンアップ **【どのような機能の開発・実装か】** - PHP・MySQLのバージョンアップ対応(担当:**自分**) **【打ち手・使用した技術】** - 公式ドキュメントから、新バージョンで使えなくなった機能を洗い出しました - それらが実際のソースで使われているかを、人による確認とAIによる確認の2重チェックで調べました ### 開発・実装内容D: SVNからGitLabへの移行 **【どのような機能の開発・実装か】** - 移行の主導とブランチ戦略の検討(担当:**上長**。ブランチ戦略は**上長と自分**で検討) - 本番・ステージング環境のソース差異の確認・調整と、開発用ブランチへの反映(担当:**自分**) ### 開発・実装内容E: 決済キャンセル失敗の通知漏れへの対応 **【課題・問題点】** - 決済のキャンセル処理が失敗したときの通知処理がなく、クライアントからの問い合わせで発覚しました。気づかれないままだと、返金漏れや請求業務への影響が出る不具合でした **【打ち手・使用した技術】** - 入社3か月で不慣れな中、決済ロジックを最初から最後まで読み込んで処理を理解し、仕様書と突き合わせて原因を特定しました(担当:**自分**) - 失敗時にメールで通知する処理を追加し、同様にエラーハンドリングが抜けている箇所がほかにないかも調査しました - 以降、エラーハンドリングの実装を徹底し、レビューでも重点的に確認する観点にしています ### 開発・実装内容F: 年末の問い合わせ対応 **【打ち手・使用した技術】** - 寄附が集中する年末の「決済できない」という問い合わせを調査し、アプリのログと不正検知サービスのダッシュボードから、3Dセキュアの失敗などユーザー側の要因と切り分けました(担当:**自分**) - クライアントには、カートやFAQページへの注意文言の掲載を提案しました ### その他の担当 - 専用LP管理機能の開発(担当:**自分**) - 他社ふるさと納税サービスとのOEM連携機能の新規開発は、別プロジェクトとして記載しています

### プロジェクト経験概要 企業運営ポータルサイトの管理CMSを、EC2環境で新規開発しました。所属部署ではそれまで自社フレームワークのみで開発しており、本案件が部署内で初めてのLaravel採用案件です。 ### チーム情報 - プロジェクト全体6名、うちCMS担当2名 - Laravel採用の提案は同僚エンジニア(現在の上長)が主導し、私は選定の補佐と開発を担当 ### 開発・実装内容A: Admin-LTEによる管理画面の構築 **【課題・問題点】** - スケジュールが短く、管理画面のUIをスクラッチで作る工数が残っていませんでした **【打ち手・使用した技術】** - 管理画面テンプレートAdmin-LTEの活用を自ら提案しました(担当:**自分**) - UI構築の工数を圧縮し、その分をドメインロジックの実装に充てることで、期間内のリリースを実現しました ### その後への影響 - この案件を起点に、新規サイト開発(BFF構成)やリアーキテクチャでも部署内でLaravelが標準的に採用されるようになり、私自身もそれらの案件で中心的に開発を担っています

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

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

Go言語の学習を目的とした個人開発です。複数の情報源(RSS/GitHub)を定期チェックし、新着を検知してntfyへ通知する常駐プログラムを、Goの標準ライブラリ中心で完成させました(2026年10月。net/http、encoding/xml、goroutine/channelによる並列取得、signal.NotifyContextによる終了処理、httptestによるテスト)。 学習の進め方は途中で変えています。当初はAIに解説とコードレビューのみを依頼していましたが、知識が少ない段階では実装を積み重ねて理解する方がよいと判断し、解説・穴あきの手本コード・添削を受けながら自分で書き進める形に切り替えました。学習の過程は講ごとにドキュメントとして残しています。今後は、書いたコードを読み直して設計判断を自分の言葉で説明できるようにすることと、既読記録の永続化・GitHub取得処理のテストに取り組みます。