taisei

# 自社受注・請求管理システムの運用保守・改修開発 ## プロジェクト概要 お弁当宅配事業で利用される、受注・請求管理システムの運用保守および機能改善を担当しています。 店舗、本部、営業、カスタマーサポートが日常的に利用する基幹業務システムで、受注、請求、売掛、配達、届け先、商品管理などの機能を扱っています。 長期運用されてきたシステムのため、不具合修正や機能追加だけでなく、既存仕様の調査、現場運用との整合確認、問い合わせ対応、次期システムへの移行を見据えた仕様整理にも取り組んでいます。 --- ## 役割・体制 エンジニア3名程度の少人数体制で、開発、運用保守、不具合対応、仕様確認、リリース対応を横断的に担当しました。 入社当初はPHP、Laravel、Vue.jsの実務経験がなく、軽微な不具合修正や既存コードの調査から担当しました。コードレビューや日々の開発を通じて段階的に担当範囲を広げ、3年目以降は、問い合わせ・障害の調査、仕様整理、設計、フロントエンド・バックエンドの実装、テスト、リリース後の確認まで一貫して担当しています。 フロントエンドではVue.js／TypeScriptによる画面改修、バックエンドではPHP／Laravel／MySQLによる業務ロジック、バリデーション、データ取得処理、受注・請求関連機能の改修を行っています。 --- ## 使用技術 PHP、Laravel、Vue.js、JavaScript、TypeScript、MySQL、AWS、Docker、Git、PHPUnit、Vitest --- ## 背景・課題 受注・請求を扱う業務システムのため、税率、日付判定、金銭計算、売掛処理、請求書発行など、小さな変更でも店舗業務や売上へ影響する可能性がありました。 また、長期運用の中で、仕様が既存コード、DB、過去の対応履歴、現場独自の運用に分散していました。そのため、コード上の挙動だけでは正しい仕様を判断できないケースもあり、システムと実際の業務の両方を確認する必要がありました。 特定の時間帯にアクセスが集中する特性もあり、データ量の多い画面や処理では、クエリの変更がシステム全体のパフォーマンスへ影響する可能性がありました。 --- ## 取り組み ### 業務影響を考慮した改修 税率、日付、金銭、請求などの重要な処理では、修正対象だけでなく、関連機能、既存データ、画面表示、DB上の状態への影響範囲を確認した上で改修しました。 正常系だけでなく、月末・月初、税率の切り替わり、未入力、既存データとの組み合わせなどの境界条件を確認し、必要に応じてテストを追加しました。 共通処理や広範囲に影響するコードについては、安易に全体を書き換えず、既存動作を調査した上で変更範囲を限定し、運用中のシステムへ与える影響を抑えました。 --- ### 仕様調査・問い合わせ対応 店舗、本部、営業、カスタマーサポートからの問い合わせに対し、ログ、DBデータ、画面上の挙動、既存コード、過去の対応履歴を照合して原因を調査しました。 コード上の仕様と現場での使われ方が一致しない場合は、カスタマーサポートや営業へ実際の利用状況を確認し、次の点を整理した上で対応方針を決定しました。 ・不具合なのか既存仕様なのか ・どの業務や利用者へ影響するか ・仕様を変更した場合に別の運用へ影響しないか ・サポート部門が利用者へ説明できる内容になっているか また、同様の問い合わせが特定の担当者へ集中しないよう、調査結果、仕様、回答内容をナレッジとして整理し、問い合わせ対応の標準化にも取り組みました。 --- ### 設計・実装 「昨日の自分は他人」「属人化を防ぎ、保守しやすい構成にする」という考え方を意識し、可読性・保守性・テスト容易性を重視した設計・実装を行いました。 フロントエンドでは、Vue.js / TypeScript を用いた画面改修やUI改善を担当しました。 バックエンドでは、PHP / Laravel を用いた業務ロジック、DB取得処理、バリデーション、請求・受注関連処理の改修を担当しました。 また、将来的な仕様変更や次期システム移行を見据え、処理の責務分離、共通化しすぎない設計、影響範囲を限定した改修を意識しました。 --- ### パフォーマンス・安全性を意識した改修 アクセスが集中する処理やデータ量の多い画面について、クエリとデータ取得方法を見直しました。 具体的には、N+1の解消、取得項目の絞り込み、不要なループの削減、SQLによる抽出条件の最適化、処理単位の分割などを実施しました。 機能上の正しさだけでなく、データ量が増えた場合の処理時間やメモリ使用量も考慮し、既存機能への影響を確認しながら改善しました。 --- ### 次期システム移行に向けた仕様整理 既存システムから次期システムへの移行に向けて、現行仕様の調査、運用課題の洗い出し、移行時に問題となり得る仕様差分の整理を行いました。 特に、受注、請求、配達、売掛、届け先管理など、移行後の業務影響が大きい領域について、現行システムでの挙動や運用実態を確認し、移行リスクの低減に取り組みました。 また、業務部門やサポート部門が移行後の変更点を理解できるよう、仕様整理や説明文の作成も行いました。 --- ### 次期システム移行に向けた仕様整理 次期システムへの移行に向けて、受注、請求、売掛、配達、届け先管理など、業務影響の大きい領域の現行仕様を調査しました。 現行システムの画面、コード、DBだけでなく、業務部門やカスタマーサポートへの確認を通じて実際の運用を整理し、新旧システムの仕様差分、移行後に変更となる運用、問い合わせが発生しそうな箇所を洗い出しました。 調査結果は、開発者だけでなく業務部門やカスタマーサポートも確認できる形で整理し、リニューアルプロジェクトの要件整理と移行リスクの低減へつなげました。 --- ## 成果・身につけたこと ・実務未経験から、仕様調査、設計、実装、テスト、リリース後確認まで一人称で担当できるようになった ・Vue.js／TypeScriptからPHP／Laravel／MySQLまで、フロントエンド・バックエンドを一貫して担当した ・税率、日付、金銭、請求など、業務影響の大きい領域で安全な改修を経験した ・コード、DB、ログ、画面挙動、現場運用を照合し、明文化されていない仕様を整理した ・クエリやデータ取得方法を改善し、データ量とアクセス集中を考慮した実装を行った ・問い合わせ内容をナレッジ化し、属人化しやすいサポート対応の標準化に貢献した ・現行システムで得た業務知識を、リニューアルプロジェクトの要件整理・移行設計へ活かした

# 自社受注・請求管理システムのリニューアル開発・システム移行推進 ## プロジェクト概要 法人・個人向け弁当宅配事業を支える、受注・請求管理システムのリニューアル開発に従事しました。 7〜8年にわたり運用されてきた現行システムから、受注、請求、売掛、配達、届け先、商品管理などの業務を新システムへ移行するプロジェクトです。既存業務を継続できることを前提に、操作性、保守性、処理性能を改善し、段階的に新システムへ移行することを目的としていました。 単なる新規開発ではなく、現行システムの仕様調査、実際の業務運用との整合確認、新旧システムの仕様差分整理、関係部門との認識合わせ、不具合・改善点の洗い出しまで幅広く担当しました。 特に、受注、請求、売掛、税率、日付、金銭計算など、業務停止や金銭トラブルにつながる可能性がある領域について、移行後も安全に運用できる状態を目指して改善を進めました。 --- ## 役割・体制 エンジニア3名の少人数体制におけるコアメンバーとして、要件整理、設計、フロントエンド・バックエンドの実装、テスト、データ移行、リリース後の確認まで一貫して担当しました。 フロントエンドではVue.js／TypeScript／Inertia.jsを用いた画面開発、バックエンドではPHP／Laravel／MySQLを用いた業務ロジック、データ取得処理、バリデーション、受注・請求・売掛関連機能の改修を担当しています。 また、専任PMが不在で、部門責任者も他部署を兼務していたため、約1年にわたり、開発と並行してプレイングリードとしてプロジェクト推進を担当しました。 顧客、店舗担当者、営業、SV、カスタマーサポート、運用部門と開発チームの間に入り、以下を行いました。 ・要望・課題の収集と仕様への落とし込み ・開発優先順位と対応範囲の整理 ・進捗、課題、リスクの管理 ・日次での仕様確認と認識合わせ ・経営層・部門責任者への週次進捗報告 ・移行に向けた懸念事項と残課題の可視化 --- ## 使用技術 PHP、Laravel、Vue.js、TypeScript、JavaScript、Inertia.js、MySQL、AWS、Docker、Git、PHPUnit、Vitest --- ## 背景・課題 現行システムは長期間運用されており、業務仕様がコード、DB、過去の対応履歴、業務部門の運用手順に分散していました。 そのため、新システムでは、現行の挙動をそのまま再現するのではなく、次の切り分けが必要でした。 ・業務継続のために再現すべき仕様 ・現行運用に合わせて見直すべき仕様 ・誤操作や金銭トラブルを防ぐために変更すべき仕様 ・新システムへの移行に伴って廃止・統合できる仕様 また、顧客、営業、運用部門、カスタマーサポートなど、関係者ごとに要望や優先順位が異なっていました。少人数かつ仕様変更の多い環境だったため、すべての要望を同時に実装するのではなく、業務影響と移行リスクを基に対応範囲を決める必要がありました。 データ移行についても、大量の受注・請求関連データを扱うため、処理速度、メモリ使用量、重複防止、エラー発生時の再実行方法を考慮する必要がありました。 --- ## 取り組み ### 要件整理とプロジェクト推進 顧客や各部門から寄せられる要望をそのまま機能へ置き換えるのではなく、「誰の、どの業務で、何が問題になっているのか」「改善によって何が変わるのか」を確認し、目的から仕様を整理しました。 資料だけでは実際の運用を把握できない部分も多かったため、店舗担当者、営業、SV、カスタマーサポートに実際の画面を操作してもらいながら、レビューとヒアリングを実施しました。 また、開発側・運用側で数日かけて数百画面を確認し、以下の観点から移行前の課題を整理しました。 ・現場で実際に業務を完結できるか ・現行システムと挙動が異なる箇所はないか ・画面表示とDB上のデータが一致しているか ・操作方法が分かりにくい箇所はないか ・移行後に問い合わせが発生しそうな箇所はないか ・金銭・請求処理に誤りが発生する可能性はないか その結果、仕様変更、改善要望、不具合候補を含む約200件の課題を抽出しました。 抽出した課題は、業務への影響、緊急度、金銭トラブルのリスク、移行への影響、サポート部門の説明負荷、実装コストを基準に分類し、対応順序とリリースまでに必要な範囲を整理しました。 日次の仕様確認と週次の進捗共有では、決定事項、未決事項、担当者、期限、リスクを整理し、関係者間の認識齟齬と手戻りを抑えながらプロジェクトを進めました。 --- ### 不具合・改善点の解消 約200件の課題のうち、約100〜120件について、2〜3か月の間に自ら実装・修正を担当しました。 主な対応内容は以下のとおりです。 ・受注・請求・売掛処理の仕様不備 ・日付・税率・金額計算の判定不備 ・対象データの抽出条件の不備 ・画面表示とDB状態の不整合 ・入力バリデーションの不足 ・請求書発行時の挙動不備 ・操作導線やエラーメッセージの改善 ・現行システムとの仕様差分の調整 単に件数を消化するのではなく、業務影響と移行リスクを確認し、関連する処理への影響を調査した上で対応しました。 仕様として判断が必要な課題については、開発チームだけで決めず、営業、運用部門、カスタマーサポートと認識を合わせてから実装しました。 --- ### 受注・請求・売掛領域の仕様整理 受注、請求、売掛など、移行後の業務と金銭処理へ直接影響する領域について、現行仕様の調査と新システム側の仕様整理を担当しました。 既存コード、DB、画面挙動、過去の対応履歴、業務部門へのヒアリングを通じて、次の観点を確認しました。 ・請求対象となるデータの抽出条件 ・売掛の計上・消込に関する条件 ・税率と金額計算の判定 ・日付を基準とする処理の境界条件 ・二重登録・二重請求を防ぐための制御 ・操作ミスが発生した場合の影響と復旧方法 ・現行システムから引き継ぐべき例外処理 現行システムの挙動をそのまま再現するのではなく、業務上必要な仕様と、過去の経緯によって残っている仕様を切り分け、新システムで安全に運用できる形へ整理しました。 --- ### 設計・実装 保守性、テスト容易性、将来の仕様変更を考慮し、業務ロジックとデータアクセスの責務を分離して実装しました。 具体的には、Controllerへ処理を集中させず、業務ロジックをService、データ取得条件をRepositoryへ整理し、変更箇所とテスト対象を特定しやすい構成を意識しました。 データ量の多い処理では、以下の点を考慮しました。 ・N+1の解消 ・不要な全件取得の回避 ・必要なカラム・データだけを取得 ・SQL・クエリビルダによる抽出条件の最適化 ・PHP側の不要なループとメモリ使用量の削減 ・処理単位の分割 ・複数レコードの一括登録 共通処理や広範囲に影響するコードについては、変更による副作用を確認し、必要以上に大きな改修を行わず、影響範囲を限定することも重視しました。 --- ### テスト・品質改善 PHPUnit／Vitestを用いたテストに加えて、画面操作、DB上のデータ確認、現行システムとの挙動比較を行いました。 特に受注・請求・売掛領域では、以下を重点的に確認しました。 ・金額と税率の計算結果 ・日付条件と境界値 ・対象データの抽出条件 ・既存データとの整合性 ・画面表示とDB状態の一致 ・関連する機能への副作用 ・エラー時に利用者が原因を把握できるか 不具合修正時には、発生した問題だけを直すのではなく、原因と影響範囲を整理し、同種の不具合を検出できるテストを追加しました。 --- ### 業務部門・サポート部門との移行準備 現行システムと新システムの仕様差分、移行後に変更となる運用、問い合わせ対応で説明が必要な点を整理しました。 Slackやミーティング用の資料を作成し、開発状況、決定事項、残課題、移行時の懸念点を共有しました。特に受注・請求・売掛・配達関連の仕様については、開発側の都合だけで決めず、実際の業務運用とサポート対応を踏まえて整理しました。 これにより、開発チームだけでなく、業務部門とカスタマーサポートも同じ認識を持って移行準備を進められる状態を目指しました。 --- ### 成果・価値 ・3名のエンジニアチームで、要件整理から設計、実装、テスト、移行準備まで横断的に担当 ・専任PM不在の中、約10か月にわたり、開発と並行してプロジェクト推進を担当 ・数百画面のレビューと関係部門へのヒアリングを通じて、約200件の仕様変更・改善点・不具合候補を抽出 ・抽出した課題のうち、約100〜120件を2〜3か月で自ら実装・修正 ・Vue.js／TypeScript／Inertia.jsからPHP／Laravel／MySQLまで一貫して開発 ・受注、請求、売掛、税率、日付、金銭計算など、業務影響の大きい領域の仕様整理と改修を担当 ・大量データ移行において、データ取得、処理単位、一括登録、再実行方法を見直し、移行処理の実用性と安全性を改善 ・業務部門とカスタマーサポートを含む関係者間で、仕様差分、優先順位、残課題を共有できる状態を整備 ---

## プロジェクト概要・担当内容 個人事業主（特にインボイス制度対応が不要な免税事業者）向けにスマートフォンから見積書・請求書を作成・PDF出力できるWebアプリを一人で企画・設計・開発し、業務のデジタル化を実現。 ## 役割・体制 ### 自身のポジションと役割 個人開発のため、通常チームで分担する以下の全役割を一人で遂行。 - プロダクトマネージャー: ユーザーヒアリングに基づく要件定義と機能優先順位付け、リリース判断 - UI/UX デザイナー: モバイルファーストの画面設計、画面遷移設計、ユーザビリティ検討 - アーキテクト: Supabase の RLS 設定を含むデータベース設計、Repository/Service パターンによるビジネスロジックのレイヤー分離 - フロントエンド・バックエンドエンジニア: Next.js + TypeScript での実装、認証・認可機能や PDF 生成機能の開発、Vercel へのデプロイ ### チーム規模と構成 - 『個人開発プロジェクトとして、企画から設計・開発・運用まで全工程を単独で遂行。』 ## 背景・課題 - 個人事業主を中心とした免税事業者が手書き伝票で見積書・請求書を作成しており、業務効率化とミス削減のためスマホで完結するデジタルツールが必要とされていた。 - 品質担保とリリーススピードのトレードオフが最大の課題であり、ユーザー（友人）からの早期利用要望に応えつつ十分なテスト期間を確保できない状況だった。 - 個人プロジェクトのため社用 PC を使用できず、自宅の 2015 年製 MacBook Air (macOS 11) で開発を開始したが、最新の AI コーディングアシスタント、Node.js の新バージョン、一部の開発ツールが OS バージョン互換の問題で動作せず、開発効率が大きく制約された。 ## 実際の取り組み ### 開発環境 - Next.js（App Router）とTypeScriptを用いたモバイルファーストのフロントエンド開発を行い、Tailwind CSSでUIを構築。 - バックエンドはSupabase（PostgreSQL）を採用し、RLS（行レベルセキュリティ）でデータ保護を強化。 - AIコーディングアシスタントClaude Codeを活用し、設計レビューやコード品質向上を図った。 - GitHub Codespacesのクラウド開発環境を導入し、ローカル環境の制約を回避して最新ツールチェーンを活用可能にした。 - VercelにCI/CDパイプラインを構築し、段階的な本番デプロイを実施。 ### 設計・改善内容 - ビジネスロジックとデータアクセスをRepository/Serviceパターンで分離し、スナップショット方式で書類発行時点の自社・取引先情報をJSONで保存することで、過去書類の整合性を保持。 - 機能単位で小さなリリースとユーザー確認・改善を繰り返すアジャイル的な運用を導入し、認証基盤・見積書・請求書・PDF生成機能を段階的にリリース。 - バグ修正と新機能追加をPull Request単位で分離し、Vercelのプレビュー環境でユーザーがマージ前に動作確認できる仕組みを整備。 - ユーザー（友人）からの報告を次の優先タスクとして取り込み、実利用環境を活用した継続的改善。 ### その他アピールポイント - 『限られた期間かつ一人開発の中で、ユーザー（友人）のニーズに即応できる柔軟な開発体制を構築し、品質とスピードの両立を実現。』 - 『自ら環境構築の制約を分析し、最新技術を活用可能なクラウド環境を導入することで、技術的課題を克服。』 ## 成果・価値 - 出先のスマホから見積書・請求書を作成・PDF出力できるサービスを提供し、1件あたり10〜15分かかっていた手書き作業を2〜3分のスマホ入力に短縮。 - ユーザー（友人）から「いつも手書きで請求業務がスマホで完結するのは助かる」と高評価を獲得し、業務効率化に貢献。 - 『個人開発ながら要件定義から運用・保守まで一気通貫で担当することで、エンジニアとしての技術力とプロジェクト推進力を大幅に向上させた。』 - 継続的改善によりユーザー（友人）のニーズを素早く反映し、実用性の高いプロダクトを早期に市場投入した。

# セルフマネジメントシステム「Clear Dawn」および記憶支援機能「キオク」の企画・開発 ## プロジェクト概要 仕事、健康、生活、個人の目標など、複数のテーマを並行して管理する中で、「情報は記録していても、その日に何を優先すべきか判断しにくい」という自身の課題を解決するため、セルフマネジメントシステム「Clear Dawn」を企画・個人開発しています。 単なるタスク管理ではなく、目標、日々の行動、ルーティン、コンディション、食事、家計、過去の記録を一つのシステムへ集約し、毎日の優先順位と具体的な行動を決めるためのPersonal OSを目指しています。 その中で、思いついた内容を短時間で記録し、AIによる整理・検索・再利用へつなげる記憶支援機能「キオク」も開発しています。 現在はLaravel Cloud上へデプロイし、自身での利用と検証を続けながら、機能単位で改善しています。 ### 関連リンク - [GitHubリポジトリ](https://github.com/tai-namechan/Clear-Dawn-v0) - [プロダクト概要](https://github.com/tai-namechan/Clear-Dawn-v0/blob/main/docs/product/overview.md) - [実装進捗](https://github.com/tai-namechan/Clear-Dawn-v0/blob/main/docs/progress.md) --- ## 役割・体制 個人開発として、課題設定、プロダクト企画、要件整理、仕様作成、UI設計、DB設計、フロントエンド・バックエンド開発、テスト、デプロイ、運用改善まで一人で担当しています。 開発ではClaude Code、Codex、CursorなどのAIコーディングエージェントを活用しています。自身はプロダクトの目的、仕様、データ設計、実装方針、AIへ渡すタスクの分割、生成されたコードのレビュー、テスト、最終的な採用判断を担当しています。 AIに機能を一括して作らせるのではなく、仕様をドキュメント化し、機能単位でPull Requestへ分割して、実装・レビュー・テストを繰り返す形で開発しています。 --- ## 主な機能 Clear Dawn本体では、次の機能を実装しています。 - 生活領域と優先事項を整理するTOP Matrix - 目標・プログラム・ロードマップ管理 - その日に実行する内容の生成・管理 - ルーティン・トレーニング・実行履歴 - 体重・睡眠・コンディションなどの記録とグラフ - 食事・栄養記録 - 動画のアップロード・再生 - 収支・資産・返済状況から金銭的な余裕を確認する機能 食事記録では、バーコードによる食品検索、栄養成分表示の画像からのOCR、料理写真や店名・メニュー名からの栄養情報推定を実装しています。 AIの推定結果を自動確定せず、利用者が内容を確認・修正してから保存する設計としています。 --- ## 記憶支援機能「キオク」 「キオク」は、思いついた内容を失う前に保存し、後から検索・再利用できる状態にすることを目的としています。 テキストと音声による記録に対応し、ネットワークやAI処理の完了を待たず、まず端末上のIndexedDBへ保存する設計としました。 ネットワーク接続後にバックグラウンドでサーバーへ同期し、同一データが再送された場合も重複登録されないよう、クライアント側で発行したIDを使って冪等性を確保しています。 音声データは非公開のObject Storageへ保存し、OpenAI APIによる文字起こし、AIによるタイトル・要約・タグ・重要度の整理をQueueで非同期実行します。 文字起こしやAI整理に失敗した場合も、元のテキストや音声を失わないことを優先しています。 保存された記憶は、キーワード、タグ、重要度、作成日時などを利用して検索できます。 また、関連する記憶だけを取得してAIへ渡すContext Builderを実装し、すべての記憶を毎回AIへ送らない構成としています。 具体的には、取得件数と文字数に上限を設け、利用者本人のデータ、処理済みデータ、現在の質問と関連する記憶だけを候補として取得します。AIへ渡したくない記憶は、SQLによる候補抽出の段階で除外します。 ### 関連する設計資料 - [キオクのクイックキャプチャ・音声入力設計](https://github.com/tai-namechan/Clear-Dawn-v0/blob/main/docs/product/kioku-quick-capture.md) - [キオクの検索・Context Builder設計](https://github.com/tai-namechan/Clear-Dawn-v0/blob/main/docs/architecture/kioku-knowledge-retrieval.md) --- ## AI機能の設計 AI機能を増やす中で、利用料金の予測不能な増加や、API失敗時の二重課金を防ぐため、AI呼び出しを共通化するGatewayを実装しました。 AI呼び出し前に利用予定額を予約し、成功時に実際の利用額を確定、失敗時には予約を解放する形で月間上限を管理しています。 機能、モデル、トークン数、利用額を記録し、どの機能がどの程度AIを利用しているか確認できるようにしています。 また、プロンプトをコードへ直接埋め込まず、バージョンを持つテンプレートとして管理し、変更前後の比較や再現ができるようにしています。 AIの出力はそのまま保存・表示せず、JSON形式や値の範囲を検証し、重要なデータについては利用者の確認を挟む設計としました。 --- ## 設計・品質管理 仕様、データ設計、画面仕様を`docs`ディレクトリで管理し、仕様変更時にはドキュメントを更新してから実装する方針としています。 設計上の重要な判断についてはADRとして記録し、次のような内容を明文化しています。 - ULIDを利用するテーブルと既存IDとの境界 - ユーザーごとのデータ分離 - イベントログを更新せず追記する方針 - 食事記録で登録時点の情報を保持する設計 - AIへ渡す記憶の範囲と上限 - 外部APIやObject Storageとの責務境界 各機能は、Route、Controller、Query／Service、Vue画面、テストまでを一つの単位として実装しています。 品質確認には、次の仕組みを利用しています。 - PHPUnitによるFeature／Unitテスト - Larastan／PHPStanによる静的解析 - vue-tscによるTypeScriptの型検査 - ESLint／Prettier／Laravel Pint - SSRを含むViteビルド確認 - AI・外部APIをFake化したテスト --- ## 工夫した点 ### 元データを失わない設計 「キオク」では、AIが生成したタイトルや要約よりも、利用者が入力した元の文章と音声を正としています。 AI処理の失敗や通信切断が発生しても元データを残し、派生データだけを再生成できる構造にしました。 ### AI処理の非同期化 AIによる文字起こし、分類、栄養情報推定などはQueueで非同期実行し、保存操作や画面表示をブロックしない設計としています。 リトライによって同じAI処理が重複実行されないよう、処理状態の条件付き更新や一意性制御を取り入れています。 ### AIのコスト管理 AIの利用履歴を記録するだけでなく、実行前の利用額予約、成功時の確定、失敗時の解放を行うことで、同時実行時にも月間上限を超えにくい仕組みを実装しました。 ### 仕様と実装の差分管理 実装済み、部分実装、未着手を進捗ドキュメントで区別しています。 将来構想を実装済みとして扱わず、各機能の現在地と残課題を明確にしています。 --- ## 成果・現在地 - Laravel／Vue.jsを用いて、企画から本番デプロイまで個人で一貫して実施 - 目標管理、ルーティン、コンディション、食事、家計、記憶支援を統合したWebアプリケーションを構築 - テキスト・音声の端末保存、再送、重複防止、非同期AI整理までの処理を実装 - OpenAI APIによる音声文字起こしと、Anthropic APIを利用した情報整理・推定機能を実装 - AI利用量の記録、月間上限、実行前予約を含むコスト管理基盤を構築 - 機能単位で仕様、実装、テストを揃え、AIコーディングエージェントを利用した開発プロセスを実践 - 自身での利用を通じて、UI、処理性能、AI推定精度、利用コストを継続的に改善