ID:85117さん

## 1. 変更に強い設計と、テストのない既存コードへの向き合い方 長く運用されるプロダクトほど、変更のたびに影響範囲を確認するコストが大きくなると感じています。現職ではCodeIgniter 3の自社サービスを担当しており、自動テストがないため、リリース前の確認に実装以上の時間をかけることもありました。 自分でテストを書こうとした際、依存を差し替えられる構造になっておらず、テストデータを用意する段階で止まった経験があります。この経験から、責務を適切に分け、依存を差し替えられるように設計する力と、仕様が明文化されていない既存コードに対して、まず現在の挙動をテストなどで記録し、そこから安全に改善していく進め方をもっとしっかりと身につけたいと考えています。 ## 2. 複数サービスにまたがる処理の可観測性 本人確認OCRの自動化では、Lambda・API Gateway・Amazon Bedrock・Google Cloud Vision APIをまたぐ構成を設計・実装し、リリース後もCloudWatchで利用状況やエラーを監視してきました。 一方で、処理が遅い場合に、複数のサービスのうちどの区間に時間がかかっているのかを追跡する手段を十分に持てておらず、原因の特定に時間がかかった経験があります。 今後は、リクエスト単位で処理を横断して追跡できる仕組みや、後から検索・集計しやすいログ設計など、複数サービスで構成されたシステムの可観測性について理解を深め、障害や性能問題の原因により早く到達できるようになりたいと考えています。 ## 3. 生成AI機能を、品質を検証できる形で設計する力 Amazon Bedrock（Claude）を使ってOCR結果を構造化する際には、「推測させない」「不確実な場合は値を返さない」というルールを設け、誤った値が業務に流れないように設計しました。また、出力形式の揺れに対しては再試行処理を実装しています。 一方で、プロンプトやモデルを変更した際に、品質が上がったのか下がったのかを、本番のログだけでは十分に判断できない課題も感じています。 今後は、評価用のデータセットを用意し、変更前後の結果を定量的に比較できる仕組みを設計できるようになりたいと考えています。AIによって実装の速度が上がるほど、生成されたものを適切に評価し、品質を継続的に検証する仕組みの重要性は高まると考えています。