ID:82607さん

## OCR機能の処理時間改善 ### 概要 物件概要書の画像から、物件情報を自動入力するOCR機能の改善を担当しました。 ### 課題・問題点 既存機能では、1回の処理に平均約41秒かかっており、結果が返らない場合やJSON形式が崩れる場合もありました。 営業デモや実際の登録業務で待ち時間が長く、安定性にも課題がありました。 ### 自分の担当範囲 既存処理の調査、改善方針の検討、バックエンドとフロントエンドの改修、動作確認を担当しました。 ### 判断・打ち手 処理フローを確認したところ、AIに任せる必要のない機械的な処理までAI側で行っていることや、トークン上限・リトライ設定が処理時間に影響していました。 単純なモデル変更だけでは改善が不十分と考え、以下を行いました。 * 使用モデルの変更 * AIが担当する処理と、プログラムで確定的に処理する部分の分離 * トークン上限とリトライ処理の見直し * JSON形式が崩れた場合の補正処理 * フロントエンド側のエラー表示改善 ### 結果 平均処理時間を約41秒から約12秒に短縮しました。 AI機能を新規設計したというより、既存機能の処理内容を調査し、速度と安定性の両面から改善した取り組みです。 --- ## 画面表示速度の改善 ### 概要 物件情報を表示する画面で、表示完了まで最大約60秒かかる問題の改善を担当しました。 ### 課題・問題点 ユーザーから画面表示が遅いという声がありましたが、フロントエンド、バックエンド、データ取得のどこが原因かは明確になっていませんでした。 ### 自分の担当範囲 対象画面の処理確認、SQL発行状況の調査、Rails側の修正、改善後の確認を担当しました。 ### 判断・打ち手 画面の処理内容とデータベースへのアクセス状況を確認し、関連データの取得時にN+1問題が発生していることを特定しました。 全面的な作り直しではなく、影響範囲を抑えながら改善できるよう、関連データの取得方法を見直しました。 ### 結果 LCPを最大約60秒から約15秒まで改善しました。 大規模なアーキテクチャ変更ではなく、既存コードのボトルネックを調査し、局所的に改善した経験です。 --- ## CI/CDの整備 ### 概要 既存のAWS環境に対して、GitHub Actionsを利用したデプロイフローを整備しました。 ### 課題・問題点 デプロイ作業の一部を手作業で行っており、作業負担や手順の属人化が課題となっていました。 ### 自分の担当範囲 既存のAWS構成を確認し、GitHub Actionsのワークフロー作成、動作検証、手順のドキュメント化を担当しました。 ### 判断・打ち手 新しい基盤を一から構築するのではなく、既存のECR・ECS環境を活用し、変更範囲を抑えて自動化する方針としました。 以下の処理をGitHub Actions上で実行できるようにしました。 * Dockerイメージのビルド * ECRへのイメージ登録 * ECSサービスの更新 あわせて、実行方法やトラブル時の確認事項をWikiにまとめました。 ### 結果 手作業で行っていたデプロイ工程を減らし、他のメンバーも同じ手順でデプロイできる状態にしました。 AWS基盤全体の設計ではなく、既存環境におけるデプロイ作業の改善を担当した経験です。 --- ## AI開発ツールの利用促進 ### 概要 チーム内でCursorなどのAI開発ツールを活用するため、利用方法の検証と共有を行いました。 ### 課題・問題点 ツール自体は利用可能でしたが、メンバーによって使い方が異なり、調査や実装に十分活用できていませんでした。 ### 自分の担当範囲 自分の開発タスクでの検証、Rules・Skillsの作成、利用方法の共有、勉強会の実施を担当しました。 ### 判断・打ち手 最初からチーム共通の運用を決めるのではなく、まず自分の担当タスクで有効な使い方を検証しました。 そのうえで、再現しやすかった利用方法をRulesやSkillsとして整理し、勉強会で共有しました。 ### 結果 調査、実装、テストなどの工程で、AIツールを利用するメンバーが増えました。 開発組織全体の導入責任者として推進したものではなく、利用者として検証し、チームへの共有を行った取り組みです。