はじめに
今回は、私が個人開発しているライブ予定・費用管理アプリ「GenBGT（ゲンバジェット）」について紹介します。
私はこれまで、主に自動車向け組込みソフトウェアの開発に携わってきました。
業務ではC言語を使用する機会が多かったのですが、以前からWebアプリケーション開発にも興味があり、独学で学習を進めていました。
また、近年はClaude Code・Codex・GitHub Copilotなど、生成AIを活用した開発環境が充実しています。
これらを活用すれば、個人でも本格的なWebアプリケーションを開発出来るのではないかと考え、実際に開発に取り組むことにしました。
そして完成したのが、ライブ予定と費用を一元管理するアプリ「GenBGT」です。
現在はWeb版を公開しており、Android版についてもGoogle Playの内部テスト環境で動作確認を進めています。
本記事では、開発に至った背景から実装した機能、使用技術、インフラ構成、実際に発生している運用費用まで紹介します。
公開アプリ：
https://www.genbgt.com/
私の共有ページ：
https://www.genbgt.com/share/may04
1. 開発の背景｜ライブ予定と費用を一元管理したい
私はライブに参加することが趣味で、年間を通して様々な公演に足を運んでいます。
ライブに参加するとなると、当然ながら予定の管理が必要です。
公演日や会場、開演時間などを記録するだけであれば、Googleカレンダーなどの一般的なスケジュール管理アプリでも十分対応出来ます。
しかし、個人的にはそれだけでは物足りませんでした。
ライブには様々な費用が発生する
ライブに参加する際は、チケット代以外にも様々な費用が発生します。
例えば、遠征を伴うライブであれば、交通費や宿泊費が必要です。さらに、グッズ代や飲食代などが発生することもあります。
これらの費用を含め、ライブごとにいくら使ったのかを把握したいと考えていました。
また、年間を通してどの程度のお金を使っているのかも確認したいところです。
一般的な家計簿アプリを利用すれば支出自体は管理出来ますが、ライブ予定と紐付けて管理するには不便です。
一方、スケジュール管理アプリには、ライブに関する費用を細かく管理する機能がありません。
ライブ予定の管理と費用管理を1つのアプリで完結させたい。
これが、開発を始めた大きな理由の1つです。
一般的なスケジュールアプリでは物足りない
ライブには、一般的な予定とは異なる固有の情報があります。
例えば、公演名、出演アーティスト、会場、開場時間、開演時間などです。
また、同じツアーであっても複数の公演に参加することがありますし、複数のアーティストが出演するイベントもあります。
こうした情報を一般的なカレンダーアプリで管理しようとすると、どうしても自由記述が中心になってしまいます。
私は、ライブに必要な情報をそれぞれ独立した項目として管理したいと考えていました。
当初はNotionで管理していた
実は、最初からアプリを開発しようと考えていたわけではありません。
当初はNotionを利用して、ライブ予定や関連情報を管理していました。
Notionはデータベース機能が充実しており、様々な情報を自由に整理出来る便利なサービスです。
しかし、使い続けるうちに、いくつかの不満が出てきました。
特に不便に感じていたのが、年ごとのアーカイブページの作成です。
私は、過去に参加したライブを年別に振り返れるようにしたいと考えています。
例えば、2024年、2025年、2026年といった形でページを分け、それぞれの年に参加した公演を一覧表示する仕組みです。
単にデータを年別に絞り込むだけでなく、表示方法やレイアウトにもこだわりたいと考えていました。
しかし、Notionでは既存の機能やレイアウトに合わせる必要があり、毎年思い通りのアーカイブページを作成することが難しいと感じました。
そこで、ふと思いました。
「それなら、いっそのことゼロから自分で作ってしまえば良いのでは？」
これが、GenBGTの開発を始めたきっかけです。
2. アプリ名「GenBGT」の由来
アプリ名の「GenBGT」は、次の2つの言葉を組み合わせた造語です。
- Gen：現場
- BGT：Budget（予算・費用）
ライブに参加することを「現場に行く」と表現することがあります。
その「現場」と、費用を意味する「Budget」を掛け合わせました。
また、「GenBGT」という文字の並びが、何となく「ChatGPT」に似ているのも気に入っています。
覚えやすく、アプリの特徴も表現出来ているのではないかと思っています。
3. GenBGTで実現したかったこと
GenBGTでは、ライブ予定を単に登録するだけでなく、予定に関連する情報をまとめて管理出来ることを目指しました。
3-1. ライブ予定の登録・編集
ライブの基本情報を登録し、一覧で管理する機能です。
公演名や開催日、会場などの情報を管理し、各公演の詳細を確認出来るようにしています。
また、登録済みの予定を編集したり、複製したりする機能も実装しています。
同じツアーの複数公演に参加する場合など、共通する情報を再入力する手間を減らすことを意識しました。
3-2. ライブに関連する費用の管理
GenBGTの大きな特徴が、ライブ予定と費用を関連付けて管理することです。
ライブでは、チケット代に加えて、交通費や宿泊費などが発生することがあります。
これらを予定と併せて記録することで、ライブにどの程度の費用を使っているのかを把握しやすくすることを目指しました。
家計簿とは別に、趣味に関する支出を管理したい場合にも役立つと考えています。
3-3. 年別アーカイブ
開発において、特にこだわった機能の1つです。
過去のライブ予定を年別に整理し、アーカイブとして閲覧出来るようにしました。
私は、ライブの予定は単なるスケジュールではなく、後から振り返る思い出でもあると考えています。
そのため、開催日が過ぎた予定を削除するのではなく、過去の記録として残せることを重視しました。
例えば、数年前にどのようなライブに参加していたのかを確認したり、過去の活動を振り返ったりする用途を想定しています。
3-4. データのグループ化
ライブ予定を整理しやすくするため、データをグループ化する機能も実装しました。
ライブ予定は、アーティストやツアーなど、様々な単位でまとめたくなることがあります。
こうした情報を整理し、単なる時系列の一覧にとどまらない管理方法を目指しています。
3-5. 共有ページの公開
登録したライブ予定を、他の人にも共有出来るようにしています。
共有URLを利用することで、ログインしていない人でも公開対象の予定を閲覧出来る仕組みです。
一方、予定の作成や編集などの操作には認証を設けています。
自分のライブ予定を整理するだけでなく、SNSなどで共有する用途も想定しています。
3-6. 現在の公開状況
GenBGTはWebアプリケーションとして一般公開していますが、現時点では新規ユーザーの登録を停止しています。
新規登録機能については、フロントエンドのUIだけでなく、バックエンドのAPI側でも無効化しています。
そのため、現在の利用者は開発者である私自身のみです。
ただし、公開している共有ページについては、ログインしていない方でも閲覧出来ます。
今後、一般ユーザー向けに新規登録を開放するかどうかは未定ですが、まずは自分自身で利用しながら、機能の改善や安定性の向上に取り組んでいきたいと考えています。
4. 使用している技術
ここからは、技術的な内容について紹介します。
GenBGTでは、フロントエンドにTypeScript・React Native、バックエンドにRust・Axumを採用しています。
また、Web版だけでなく、iOS・Androidへの対応も視野に入れた構成としました。
4-1. 技術スタック一覧
| 分類 | 使用技術 |
|---|---|
| フロントエンド | TypeScript |
| UIフレームワーク | React・React Native |
| 開発プラットフォーム | Expo |
| 画面遷移 | Expo Router・React Navigation |
| バックエンド | Rust |
| Webフレームワーク | Axum |
| 非同期処理 | Tokio |
| API | REST API |
| データベース | SQLite |
| データベースアクセス | SQLx |
| 認証 | JWT・bcrypt |
| Webホスティング | Cloudflare Pages |
| APIサーバー | AWS EC2 |
| リバースプロキシ | nginx |
| プロセス管理 | systemd |
| データバックアップ | Amazon S3 |
| CI/CD | GitHub Actions |
| AWSへの接続・操作 | AWS Systems Manager |
| モバイルビルド | EAS Build |
| ソースコード管理 | Git・GitHub |
| AIコーディング支援 | Claude Code・Codex・GitHub Copilot |
フロントエンドとバックエンドは、1つのGitHubリポジトリで管理しています。
いわゆる「モノレポ」と呼ばれる構成です。
ソースコードを一元管理することで、フロントエンドとバックエンドの変更をまとめて確認しやすくしています。
4-2. Rustを採用した理由
バックエンドにはRustを採用しました。
私はこれまで、車載メーターなどの組込みソフトウェア開発に携わり、主にC言語を使用してきました。
そのため、C/C++との関連性が深く、システムプログラミングにも適したRustに以前から興味を持っていました。
Rustは、C/C++が活用されてきた分野でも採用が進められているプログラミング言語です。
特に、所有権や借用といった仕組みによって、メモリ安全性を確保しやすい点が特徴です。
また、ガベージコレクションに依存せず、実行時の性能を重視したプログラムを開発出来る点にも魅力を感じました。
RustはWebバックエンドだけでなく、組込みシステムやシステムソフトウェアなど、様々な分野で活用出来る可能性があります。
Webアプリケーション開発の学習と、これまでの組込み開発経験の延長線上にある技術習得を両立出来ることが、採用した理由です。
学習にはUdemyや参考書を活用しています。
4-3. Axum・Tokioによるバックエンド開発
RustによるWeb APIの実装には、Axumを採用しています。
Axumは、Rust向けのWebアプリケーションフレームワークです。
HTTPリクエストを受け付け、URLやHTTPメソッドに応じて処理を振り分けるルーティング機能などを提供しています。
GenBGTでは、ライブ予定の取得・登録・更新などをREST APIとして実装しています。
また、非同期処理にはTokioを採用しました。
TokioはRust向けの非同期ランタイムで、ネットワーク通信や入出力処理などを効率的に実行するために利用しています。
AxumとTokioを組み合わせることで、非同期処理に対応したAPIサーバーを構築しています。
私自身、これまでの業務では10ms、20ms、100msといった周期処理を扱うことが多く、Webサーバーにおける非同期処理は新鮮でした。
組込み開発とは異なる実行モデルを学べたことも、個人開発の成果だと感じています。
4-4. React Native・Expoを採用した理由
フロントエンドには、TypeScript・React Native・Expoを採用しています。
React Nativeは、Reactを利用してモバイルアプリケーションを開発するためのフレームワークです。
また、Expoを組み合わせることで、iOS・Android向けの開発環境を整えやすくなります。
GenBGTでは、React Native for Webを利用することで、Web版にも対応しています。
つまり、Web・iOS・Androidの3つのプラットフォームで、フロントエンドのコードを共通化する構成です。
プラットフォームごとに個別のアプリをゼロから開発する場合と比較して、コードの重複を減らせることが大きな利点です。
また、画面遷移にはExpo Routerを利用しています。
Expo Routerはファイル構成に基づいてルーティングを定義する仕組みで、画面数が増えても構成を整理しやすい点が特徴です。
個人開発では開発工数が限られるため、複数のプラットフォームに対応しながら実装を共通化出来ることは重要だと考えています。
4-5. SQLite・SQLxによるデータ管理
データベースにはSQLiteを採用しています。
SQLiteは、独立したデータベースサーバーを必要とせず、ファイルを利用してデータを管理するデータベースエンジンです。
GenBGTのような比較的小規模なWebアプリケーションであれば、構成を簡潔に出来ることが魅力です。
また、RustからデータベースへアクセスするためにSQLxを使用しています。
SQLxは、Rust向けの非同期SQLライブラリです。
SQLを利用してデータを操作する構成であり、型安全性も意識した実装が可能です。
GenBGTでは、ライブ予定や関連情報、ユーザー情報などをデータベースで管理しています。
さらに、運用時にはデータベースのバックアップも取得しています。
4-6. JWT・bcryptによる認証処理
ユーザー認証にはJWTとbcryptを採用しています。
JWTは、認証情報などを含むトークンを安全に検証するための仕組みです。
GenBGTでは、ログイン後のAPIアクセスに利用しています。
一方、bcryptはパスワードをハッシュ化するためのアルゴリズムです。
パスワードをそのまま保存するのではなく、ハッシュ化した値を利用して認証する構成としています。
また、ログイン不要で閲覧出来る共有ページと、認証を必要とする編集機能を分けています。
共有機能を実装する以上、誰でも閲覧出来る情報と、本人だけが変更出来る情報を適切に区別する必要があります。
こうした認証・アクセス制御についても、個人開発を通して学習しています。
5. インフラ構成｜Cloudflare PagesとAWSを組み合わせて運用
GenBGTは、ローカル環境で動作するだけのアプリケーションではなく、実際にインターネット上へ公開しています。
インフラには、Cloudflare PagesとAWSを採用しました。
5-1. システム構成
現在の主な構成は、次の通りです。
フロントエンド
Webブラウザ
↓
Cloudflare Pages
↓
React Native for Web
バックエンド
フロントエンド
↓ HTTPS
nginx
↓
Rust・Axum API
↓
SQLite
バックエンドはAWS EC2上で稼働しています。
また、データベースのバックアップ先にはAmazon S3を利用しています。
フロントエンドとバックエンドを分離することで、それぞれ独立して構築・運用出来る構成としました。
5-2. Cloudflare PagesによるWeb版の公開
Web版のホスティングにはCloudflare Pagesを利用しています。
Expoで開発したフロントエンドをWeb向けにビルドし、静的ファイルとして公開しています。
Cloudflare Pagesは無料枠が充実しているため、個人開発でも導入しやすいサービスです。
特に、Web版のホスティング費用を抑えられる点が魅力でした。
また、GitHubとの連携によるデプロイにも対応しているため、ソースコードの管理と公開作業を組み合わせやすい点も便利です。
5-3. AWS EC2によるバックエンドの運用
バックエンドのRust製APIサーバーは、AWS EC2上で動作させています。
EC2は、AWSが提供する仮想サーバーサービスです。
OSやミドルウェアを含めて環境を構築出来るため、自由度が高い一方、サーバーの管理も必要になります。
GenBGTでは、EC2上にRustの実行環境を用意し、APIサーバーを常駐させています。
また、nginxをリバースプロキシとして使用しています。
nginxが外部からのHTTPリクエストを受け付け、内部で稼働するRust製APIサーバーへ転送する構成です。
さらに、systemdを利用してAPIサーバーをサービスとして管理しています。
これにより、サービスの起動・停止・再起動などをOS側で管理出来るようにしています。
Webアプリケーションを公開するだけでなく、Linuxサーバーの構築や運用を経験出来たことも、大きな学びになりました。
5-4. GitHub Actionsによる自動デプロイ
開発を進める上で、毎回手動でサーバーへ接続してデプロイするのは手間がかかります。
そこで、GitHub Actionsを利用して自動デプロイの仕組みを構築しました。
GitHub Actionsは、GitHub上でビルドやテスト、デプロイなどの処理を自動実行出来るサービスです。
GenBGTでは、バックエンドの変更をmasterブランチへ反映すると、GitHub ActionsからAWSへのデプロイ処理を実行する構成としています。
具体的には、AWS Systems Manager（SSM）を利用してEC2上でコマンドを実行しています。
サーバー側では、最新のソースコードを取得し、Rustのリリースビルドを行った後、systemdのサービスを再起動します。
また、GitHub ActionsとAWSの認証にはOIDCを採用しています。
OIDCを利用することで、GitHub ActionsからAWSのIAMロールを引き受け、長期的なアクセスキーをGitHub側に保存せずに認証出来る構成としています。
個人開発ではありますが、実際の運用を意識してCI/CD環境を整備しました。
5-5. デプロイ前のデータベース自動バックアップ
デプロイ時にデータベースの内容が失われてしまっては困ります。
そこで、バックエンドのデプロイ前にSQLiteデータベースを自動バックアップする仕組みを実装しました。
バックアップにはGitHub ActionsとAWS SSMを利用し、取得したデータをAmazon S3へ保存しています。
また、デプロイ前だけでなく、定期的なバックアップも実行しています。
バックアップ処理とデプロイ処理を連携させることで、更新作業に伴うデータ消失リスクを軽減することを目指しました。
こうした運用面の仕組みについても、個人開発だからこそ自由に試せた部分だと思います。
6. モバイルアプリへの対応
GenBGTでは、Web版だけでなく、モバイルアプリへの対応も進めています。
現在はAndroid版を開発しており、Google Playの内部テスト環境で動作確認を行っています。
ただし、現時点では私自身のみが利用出来る状態であり、一般公開はしていません。
モバイルアプリのビルドには、Expo Application Services（EAS）を利用しています。
EAS Buildは、Expoが提供するアプリケーションのビルドサービスです。
Androidでは、Google Playの内部テスト機能を利用することで、正式公開前のアプリを実際の端末へインストールし、動作確認を行うことが出来ます。
一方、iOS版については現時点では未対応です。
ただし、GenBGTではReact Native・Expoを採用しているため、技術的にはiOSへの対応も可能です。
React Nativeは、iOS・Android間で多くのソースコードを共通化出来ることが特徴です。
そのため、将来的にiOS版を開発する場合も、既存のコードを活用出来ると考えています。
もっとも、プラットフォーム固有の処理や画面表示の違いなどがあるため、追加の実装や動作確認が必要になる可能性はあります。
まずはWeb版とAndroid版の開発・改善を優先し、iOS版については今後の対応を検討していきたいと考えています。
7. 生成AIを活用した開発とツールの使い分け
GenBGTの開発では、生成AIを積極的に活用しています。
主に利用してきたのは、Claude Code、Codex（ChatGPTのWorkを含む）、GitHub Copilotの3つです。
それぞれ特徴が異なるため、開発の工程や利用する環境に応じて使い分けてきました。
7-1. Claude Code｜開発の中心を担うツール
GenBGTの開発で、最も中心的な役割を担ってきたのがClaude Codeです。
新機能の実装や既存機能の修正、リファクタリングなど、幅広い開発作業に利用してきました。
特に、複数のファイルにまたがる修正や、フロントエンドとバックエンドの双方に変更が必要な場合など、比較的大きな開発作業で活用しています。
一方、普段からChatGPTを利用していることもあり、今後は開発環境をCodexへ統一することも検討しています。
そのため、現在はClaudeのProプランを解約し、無料プランへ変更しました。
ただし、Claude Codeの開発能力には満足しており、今後、大規模な機能追加などが必要になった場合には、再び有料プランを契約する可能性もあります。
7-2. Codex・ChatGPT Work｜別の視点からコードをレビュー
Codexについては、現時点では開発そのものよりも、コードレビューを中心に活用しています。
厳密には、Codex単体というよりも、ChatGPTのWorkを利用したレビューが中心です。
Claude Codeで実装したコードを別のAIに確認してもらうことで、実装時には気付かなかった問題点や改善点を発見出来ることがあります。
実際に、Claude Codeでは拾いきれなかった点を指摘してもらうことも多く、非常に重宝しています。
同じAIに実装からレビューまで任せることも可能ですが、異なるツールを利用することで、別の視点からコードを確認出来る点にメリットを感じています。
もちろん、AIによるレビューが必ずしも正しいとは限らないため、指摘内容については自分自身でも確認するようにしています。
今後は、普段から利用しているChatGPTとの連携も考慮し、Codexを開発の中心に移行していきたいと考えています。
7-3. GitHub Copilot｜スマートフォンからの修正に活用
GitHub Copilotについては、主にスマートフォンから利用していました。
個人的に便利だと感じていたのは、スマートフォンから気軽に開発作業を依頼出来る点です。
例えば、GenBGTのモバイル表示やAndroidアプリ版を確認している際に、不具合を発見することがあります。
そのような場合、スマートフォンでスクリーンショットを撮影し、そのままGitHub Copilotに修正を依頼していました。
PCを開かなくても、実際の画面を確認しながら修正を依頼出来る点は便利でした。
ただし、GitHub Copilotについては、試験的に利用してみたという側面が強く、現在は有料プランを解約して利用していません。
開発作業の大部分はClaude CodeやCodexで対応出来るため、現時点ではGitHub Copilotを再び利用する予定はありません。
7-4. 今後はCodexを中心とした開発へ
これまでのGenBGTの開発では、Claude Codeを中心に実装を進め、ChatGPTのWorkでレビューを行い、必要に応じてGitHub Copilotを利用してきました。
現在の利用状況を整理すると、以下のようになります。
| ツール | 主な用途 | 現在の利用状況 |
|---|---|---|
| Claude Code | 新機能の実装・修正・リファクタリング | Proを解約し、無料プランへ変更 |
| Codex・ChatGPT Work | コードレビュー・改善点の洗い出し | 継続利用中。今後は開発の中心にする予定 |
| GitHub Copilot | スマートフォンからの不具合修正 | 解約済み。現在は利用していない |
今後は、Codexを中心とした開発へ移行し、必要に応じてClaude Codeを併用する方針です。
生成AIを利用すれば、これまで時間がかかっていた実装や修正を効率的に進められます。
一方、AIが生成したコードに問題がないとは限りません。
そのため、単にAIへ実装を任せるだけでなく、レビューや動作確認を行い、最終的な品質を自分自身で判断することが重要だと考えています。
GenBGTの開発を通じて、生成AIをどのように開発工程へ組み込むべきかについても、引き続き試行錯誤していきたいと思います。
8. 実際の運用コスト｜AWSは月額約2,500〜2,800円
個人開発を行う上で、気になるのが運用費用です。
GenBGTでは、フロントエンドにCloudflare Pages、バックエンドにAWSを利用しています。
Cloudflare Pagesについては無料枠を活用していますが、AWSでは毎月一定の費用が発生しています。
8-1. AWSの月別コスト
AWS Cost Explorerで確認した、2026年5月から10月までの利用料金は、概ね次の通りです。
| 月 | AWS利用料金（概算・USD） |
|---|---|
| 2026年5月 | 約16ドル |
| 2026年6月 | 約16ドル |
| 2026年7月 | 約16ドル |
| 2026年8月 | 約16ドル |
| 2026年9月 | 約17〜18ドル |
| 2026年10月 | 約17〜18ドル |
※AWS Cost Explorerのグラフから読み取った概算値です。為替レートや税金の扱いにより、実際の円建て請求額とは異なります。
月ごとの変動は比較的小さく、概ね16〜18ドル程度で推移しています。
1ドル150円で換算すると、月額約2,400〜2,700円です。
8-2. 実際の請求金額
AWSの請求履歴では、次の金額を確認出来ました。
| 請求月 | 請求金額 |
|---|---|
| 2026年9月 | 182円 |
| 2026年10月 | 2,780円 |
2026年10月の請求金額は、2,780円でした。
一方、9月の請求金額は182円と、通常より大幅に少なくなっています。
この差については、クレジットの適用や請求調整などが影響している可能性がありますが、添付の請求履歴だけでは正確な理由までは判断出来ません。
そのため、通常の運用費用を考える際は、Cost Explorer上の利用料金と、10月の実際の請求額を参考にするのが妥当だと考えています。
なお、2026年10月からは、転職活動で使用する職務経歴書にGitHubのアカウントを記載するようになりました。
それに伴い、GitHubリポジトリへのアクセスも増加しています。
GenBGTのソースコードも公開しているため、採用担当者などがGitHub経由で実際のアプリへアクセスしている可能性があります。
2026年9月から10月にかけてAWSの利用料金も若干増加しているため、こうしたアクセス数の増加が影響しているのかもしれません。
ただし、GitHubへのアクセスが増加しただけでAWSの費用が発生するわけではなく、実際にアプリやAPIへのアクセスが増えた場合に限られます。
また、今回の費用増加がアクセス数によるものなのか、AWS側の利用状況や料金体系によるものなのかは、現時点では確認出来ていません。
今後はアクセス状況とAWSの利用料金を比較し、どの程度の関連性があるのか確認してみたいと考えています。
8-3. AWSで費用が発生しているサービス
Cost Explorerで確認出来る主なサービスは、次の通りです。
| サービス | 用途 |
|---|---|
| Amazon EC2 – Compute | APIサーバーの稼働 |
| Amazon VPC | ネットワーク関連 |
| EC2 – Other | EC2に関連するその他の費用 |
| Amazon Route 53 | DNS管理 |
| その他 | 関連サービスの利用料金 |
最も大きな割合を占めているのは、EC2のコンピューティング費用です。
グラフを見る限り、毎月約11ドル前後を占めています。
次いで、Amazon VPC関連の費用が約3〜4ドル程度発生しています。
EC2自体の利用料金だけでなく、ネットワーク関連の費用も無視出来ないことが分かります。
また、Route 53やEC2関連のその他の費用も発生しています。
なお、Amazon S3はデータベースのバックアップ先として利用していますが、今回のグラフでは独立した大きな費用項目としては表示されていません。
8-4. 年間の維持費はどの程度になるのか
仮に、毎月2,780円の請求が続くとすると、年間の費用は次の通りです。
2,780円 × 12か月 ＝ 33,360円
年間約3.3万円です。
趣味のために開発したアプリとして考えると、決して安い金額ではありません。
一方、Webアプリケーションの開発だけでなく、AWSやLinuxサーバーの運用を学ぶための費用として考えれば、それほど高額ではないとも感じています。
特に、EC2の構築、nginxの設定、GitHub Actionsによる自動デプロイ、S3へのバックアップなど、実際に運用することで得られた経験は多くあります。
もちろん、今後も利用者数やアクセス状況に応じて、適切な構成を検討していく必要があります。
また、現在のAWS利用料金以外にも、独自ドメインの更新費用やモバイルアプリの公開に伴う費用などが発生する場合があります。
そのため、アプリ全体の維持費はAWSの請求金額だけで判断出来るものではありません。
今後は、サービスの安定性を維持しながら、運用費用を削減出来ないかについても検討していきたいと考えています。
9. 個人開発を通して学んだこと
今回の開発では、これまでの業務とは異なる技術を数多く経験出来ました。
私はこれまで、主に車載メーターの組込みソフトウェア開発に携わってきました。
要求仕様に基づいた設計、C言語による実装、単体検査、結合検査などが中心です。
一方、GenBGTの開発では、アプリケーションの企画から設計、実装、テスト、デプロイ、運用まで、一通り自分で取り組んでいます。
特に印象的だったのは、次の3点です。
9-1. フロントエンドとバックエンドを横断した開発
これまでの業務では、担当する機能や開発範囲が決まっていることが一般的でした。
しかし、個人開発では画面表示からAPI、データベースまで、全体の動作を理解する必要があります。
例えば、画面上でライブ予定を登録する場合、フロントエンドからAPIへリクエストを送り、バックエンドでデータを処理し、データベースへ保存する必要があります。
こうした一連の処理を自分で実装することで、Webアプリケーション全体の構成を理解する機会になりました。
9-2. 開発だけでなく運用まで経験出来た
アプリケーションは、実装して終わりではありません。
実際に公開するためには、サーバーの構築や設定、デプロイ方法の検討などが必要です。
また、公開後はデータのバックアップや不具合対応なども考慮する必要があります。
GenBGTでは、AWS EC2やCloudflare Pagesを利用して公開環境を構築しました。
さらに、GitHub Actionsによる自動デプロイや、データベースの定期バックアップも実装しています。
これまでの業務では経験する機会が少なかったインフラ・運用分野についても、実践的に学ぶことが出来ました。
9-3. 自分が使いたいものを自由に開発出来る
個人開発の魅力は、自分の考えた機能を自由に実装出来ることです。
企業での開発では、当然ながら要求仕様や開発計画、納期などの制約があります。
一方、個人開発では、自分自身が利用者でもあります。
実際に使ってみて不便だと感じた部分を修正したり、新しい機能を追加したりすることが出来ます。
特に、今回のGenBGTは、自分自身が以前から欲しいと考えていたアプリです。
そのため、開発そのものを楽しみながら進められています。
10. 今後の開発について
GenBGTは、一度完成させて終わりというわけではありません。
今後も実際に利用しながら、機能の改善や追加を進めていきたいと考えています。
特に、ライブ予定や費用をより管理しやすくすること、年別アーカイブの使い勝手を向上させることなどに取り組みたいと考えています。
また、Web版だけでなく、モバイルアプリとしての利用環境も整えていきたいところです。
技術的には、RustやTypeScriptの理解を深めるとともに、AWSをはじめとしたクラウド技術についても学習を続けたいと考えています。
今後も組込みソフトウェア開発に携わりたいという思いは変わりませんが、組込み分野だけに技術を限定する必要はないと考えています。
Webアプリケーションやクラウド、生成AIなど、異なる技術分野の知識を身に付けることは、将来的に組込み開発にも役立つ可能性があります。
本業とは異なる分野での開発経験を積むことで、エンジニアとしての技術の幅を広げていきたいと思います。
おわりに
今回は、個人開発しているライブ予定・費用管理アプリ「GenBGT」について紹介しました。
開発を始めたきっかけは、既存のアプリでは自分の理想とするライブ予定管理を実現出来なかったことです。
当初はNotionで管理していましたが、機能や表示方法に制約を感じ、ゼロから自分でアプリを開発することにしました。
開発にはRust・Axum・TypeScript・React Nativeなどを採用し、生成AIも積極的に活用しています。
また、Cloudflare PagesとAWSを利用して実際にサービスを公開し、GitHub Actionsによる自動デプロイやデータベースのバックアップなど、運用面の仕組みも構築しました。
AWSの維持費は月額約2,500〜2,800円程度ですが、実際にサービスを運用することで得られる経験を考えると、個人的には価値のある投資だと感じています。
生成AIの登場によって、個人でも様々な技術に挑戦しやすい環境が整ってきました。
今後もGenBGTの開発・改善を続けながら、新しい技術を学んでいきたいと思います。
興味のある方は、是非一度アクセスしてみてください。
コメント