1. はじめに

自分と彼女が使う2人用の精算アプリ「settla（セトラ）」を、ChatGPT・Codexを使って開発しました。

settlaでは、普段は6:4、食事だけ7:3といった支出ごとの負担割合を記録し、最後に誰から誰へいくら渡せばよいかを計算できます。確定した精算結果はLINEでも共有できます。
※画面の名前・支出はデモ用の架空データです。

この記事では、身近な困りごとからAIとアプリを形にした過程を紹介します。開発を通して感じたのは、AIに作業を任せられても、できたものを理解して判断するには自分にも知識が必要だということでした。「作れる」と「運用できる」の間に何があったのか、今後どう学び、仕事に活かしたいかを振り返ります。

2. 作った背景

彼女とのお金のやりとりはこまめに行っています。かつて遠距離だったので、交通費や旅費のやり取りが毎回あったので、Notionでこまめに記録して精算する習慣がつきました(笑)

自分がNotionにDBを作り、支出ごとに支払者・内容・金額・負担割合を記録していました。月末の精算は彼女の担当です。

基本の負担割合は決めていましたが、毎回同じ割合にはできません。たとえば食事で自分が多く食べたら、その支出だけ7:3にしたい。こうした例外は別に計算する必要があり、月末の精算に手間と時間がかかっていたのがモヤモヤでした。

今後は同棲も考えていて、これからも続く記録と精算を楽にしたいと思い、アプリを作ることにしました。

3. 開発前の経験と利用環境

自分の技術経験

SES企業で働くエンジニアで、社会人3年目です。機械学習モデルの保守運用や、PythonとAWSを使ったバックエンド開発を経験しています。資格はPython関連の資格とAWSのSAA・DVAを持っており、現在はAIエージェントの導入支援の仕事をしています。

フロントエンド開発は未経験で、HTMLとCSSがざっくり分かる程度でした。

利用したAIと開発期間

ChatGPT Plusを利用し、ChatGPTで要件・モックを検討、Codexで実装・環境構築を進めました。
開発期間としては約10日間（2026年8月30日〜9月9日）。

主な用途	モデル	推論レベル
モック・実用版開発	gpt-5.6-sol	high / xhigh
公開対応・アイコン検討	gpt-6-astra	high

4. モックから本番配信まで

まず要望からモックを作ってもらう

最初は要望をとにかく列挙して、AIにモックを作ってもらいました。詳細な仕様は、実際の画面を触りながら考えることにしました。

最初はうまく動かない部分もありましたが、作り直してもらい、支出入力やグループ切替を試しながら修正を重ねました。AIが画面を作り、自分が触って要望を返すという進め方です。「割合を入力するときに負担額も見たい」「精算した後に共有したい」と、実物を見ながら具体的に話せました。

UI部品やデザインの専門用語を知らなくても、ニュアンスを伝えれば変更案を見せてもらえます。操作して初めて気づくこともあり、モックを先に作る進め方は自分に合っていました。

普段の使い方からMVPを決める

モックを触る中で、最初に作る範囲を絞っていきました。基準は、自分たち2人が日常の支出を記録し、迷わず精算できることです。

精算単位を月や旅行などグループで分ける。
普段の負担割合を初期値にして、例外だけ支出ごとに変更する。
精算結果は履歴に残し、LINEで共有できるようにする。

この流れを最初の実用版であるMVPの範囲にしました。

一方で、一般ユーザーの自由登録、3人以上の割り勘、家計簿のようなカテゴリごとのグラフ表示などは初回の対象から外しました。

仕様の整理や実装はかなりAIに任せましたが、どの機能が必要かは自分たちの使い方に照らして決めました。

見た目もこの段階から調整しました。「AIっぽくないUI」にしたかったので、Material 3 Expressiveをベースに、すっきりした金融アプリの雰囲気を伝えました。AIに調整してもらい、気に入るまで確認と修正を繰り返しています。

参考：Material 3 Expressive

設計書と作業ルールをGitHubに置く

決めた内容は、AIにMarkdownの設計書としてざっくり起こしてもらい、GitHubでコードと一緒に管理しました。何を作るかをプロダクト仕様書に、どう作るかをシステム設計書にまとめています。
以前、コードと設計書が別の場所にあり、AIに両方を参照してもらうのに手間がかかったことがありました。今回は同じリポジトリにまとめています。

たとえば、「基本割合を変えても既存支出は変えない」「精算済みの支出は編集できない」といったルールを残しました。次の実装を依頼するときには、まずこの文書を読んでもらいます。

Codexには、設計書に加えて作業ルールも伝えました。主な指示は次のとおりです。

作業前にプロダクト仕様書とシステム設計書を読む
仕様と実装に矛盾があれば、勝手に変更せず影響を説明する
既存UIを全面改修せず、必要な部分から段階的に変更する
編集前にgit statusを確認し、未コミットの変更を上書きしない
mainへ直接コミットせず、機能ブランチとPRで変更を管理する
秘密情報や実メールアドレスをコード・文書・コミットに残さない
実装後は検証を行い、変更内容と結果を報告する

参照する文書と変更範囲を明確にし、判断に迷う場面では確認してもらうようにしました。機能を追加したついでに、気に入っていたUIまで大きく変わるようなことを避けたかったためです。

セッションを切り替える際には、完了した作業・未決事項・次に進める順序も引き継ぎ書に残しました。会話の記憶だけに頼らず、リポジトリを読めば作業を再開できる状態を目指しています。

アーキテクチャを決める

今回は、2人だけで使うアプリを、運用負担と固定費を抑えて動かすことを重視し、Cloudflareを中心とした構成にしました。

用途	採用技術	役割
フロントエンド	React 19 / Vinext / TypeScript / Tailwind CSS	画面表示と支出入力
API・配信	Cloudflare Workers	UI配信、入力検証、精算処理
データベース	Cloudflare D1	利用者・支出・負担割合・精算履歴の保存
認証	Cloudflare Access + Googleログイン	アクセス制限と本人確認
ソース管理・CI	GitHub / GitHub Actions	コード管理、テスト、ビルド

画面配信とAPIにはCloudflare Workers、データ保存にはD1を採用しました。支出や精算履歴を共有DBで管理し、精算計算や更新制御をAPI側にまとめることで、2人が同じルールでデータを扱えるようにしています。

認証にはCloudflare AccessとGoogleログインを使っています。利用者が自分と彼女に限られるため、一般向けの会員登録機能を用意するより、事前に許可したアカウントだけがアクセスできる方式が今回のMVPに合っていました。API側でもJWTとペア所属を確認し、対象データへの操作権限をチェックします。

Cloudflareは、配信・API・DB・アクセス制御を同じプラットフォーム上で構成できる点が便利だと感じました。無料枠を前提に設計し、公開先にはworkers.devを使用しています。

環境はLocal・Staging・Productionに分け、それぞれ独立したDBを使用します。Localでは架空データで開発し、Stagingで変更を確認してからProductionへ反映する流れです。開発や検証の操作で本番データを壊さないことを目的に、環境は分離しました。

普段使っているAWSも候補でしたが、今回はCloudflare上にまとめられる構成を選びました。費用は利用量や構成によって変わるため、AWSより安いと比較したわけではありません。2人向けの小規模なアプリとして、構成と運用のシンプルさを優先しました。

設計書をもとに、実装と環境構築を進める

Codexに設計書を読んでもらい、基盤整備、認証、DB、API、UI接続と順番に進めました。コードや設定ファイルの作成は、主にCodexに任せています。

一度にすべてを依頼せず、工程ごとに変更内容と検証結果を報告してもらい、確認してから次へ進む形にしました。モックで調整したUIは維持し、支出の保存や精算処理をAPIへつないでもらいました。

自分は、仕様や設定に関する確認事項への回答と、Google認証などの管理画面での一部操作を担当しました。AIから案内を受けながら設定し、その結果を伝えて続きを進める、というやり取りもありました。

テストで品質を確認し、本番へ配信する

プロダクト仕様書とシステム設計書に記載したルール・テスト観点を基準に、Codexがテストコードを作成し、実行しました。精算計算の正確性、精算済みデータの保護、不正なデータ操作の拒否などを検証しています。

作成したテストはGitHub Actionsにも組み込み、コードのpushやPR作成時に、型チェック・ビルドなどと合わせて自動実行するようにしました。

自分は、Codexから報告されたテスト内容と実行結果を確認し、次の工程へ進めるかを判断しました。ただし、テストコードや検証方法の妥当性まで、すべて自分でレビューできたわけではありません。

これらのテストに加え、Codexによるローカルでの画面操作確認やStagingでの認証保護の確認を経て、本番環境へ配信しました。

5. AIと自分の役割

振り返ると、おおむね次の分担でした。

工程	AIに任せたこと	自分が行ったこと
モック	画面・操作の実装と修正	操作感の確認、要望の具体化
MVP・UX	要件の整理、仕様への落とし込み	2人の使い方を説明し、範囲やルールを決定
UI・アイコン	候補作成、見た目の調整、素材の組み込み	方向性の指定、候補の選択
設計・実装	構成検討の支援、文書化、コード・環境設定の作成	制約や公開方針の判断、管理画面での一部設定
テスト・公開	自動テスト、動作確認、配信作業	確認結果を受けた要望、ログイン・利用者登録の操作

自分は「どう動いてほしいか」を伝え、画面や報告で結果を確認することが中心でした。仕様だけでなく、実現方法の検討やテストもAIに助けてもらっています。その一方で、生成されたコードや設定を自分で読み解く時間は別に必要だと感じました。

6. こだわった機能とデザイン

支出入力：その支出だけ負担割合を変えられる

グループの基本割合を初期値にしつつ、支出ごとに変更できます。入力中にそれぞれの負担額も確認できるので、例外の計算を別途行う必要がなくなります。

精算・共有：結果をそのままLINEへ

精算した結果は履歴に残り、その場でも後からでもLINEで共有できます。送信先を選んで送るところは、利用者がLINE上で操作します。

お気に入りのアイコン

「目のある、ふたりが寄り添うs」を採用しました。自分たちが使うものなので、かわいさにもこだわっています。

気分に合わせて色をカスタマイズ

気分に合わせてテーマカラーを変えられます。自分のわがまま機能です(笑)。こういう好みを入れられるのも、個人開発の楽しいところでした。

7. 感想：使う側と、作った側から

彼女の感想

彼女に使ってもらったところ、最初の反応は「めっちゃいい！」でした。

「UIも見やすくて使いやすい！」「LINE送信までできて天才！」と言ってくれました。グループや割合の設定だけでなく、精算した後の共有まで考えて作ったので、そこを喜んでもらえたのはうれしかったです。

細かいところの指摘や要望はありますが、かなり満足してくれたようです。自分と彼女が使うことを基準に作ったアプリとしては、大成功でした。

自分の感想

自分たちが面倒に感じていたことをアプリにできて、彼女にも喜んでもらえた。それが何よりうれしく、社会人になって初めて「エンジニアでよかった」とさえ思いました。……と、のろけはこのくらいにして。

フロントエンド未経験の自分でも、AIとやり取りしながらここまで形にできたことは、大きな収穫でした。

ここからは運用も続けていく必要があります。機能は実現できても、それを支える技術や設定の細かな仕組みまでは把握しきれていません。今後の変更やトラブルに対応するために、作ったものを読み解き、原理から理解する時間が必要だと感じました。

8. 「作れる」と「運用できる」の距離をどう埋めるか

利用者としての理解が、MVPを決める助けになった

今回うまく進められた理由の一つは、自分も利用者だったことだと思います。Notionで何を記録し、どんな支出で割合を変え、月末にどう精算しているかを具体的に説明できました。彼女が担当していた精算についても、身近に話を聞ける相手がいました。

そのため、MVPを決めるときも「あると便利そう」だけで機能を増やさず、普段の入力から精算、共有までに必要なものを選べました。一般向けの自由登録や3人以上の割り勘を対象から外せたのも、まず誰のどんな困りごとを解決したいかが明確だったからだと感じます。

これはAI駆動開発に限らず、要件定義の学びとして実務にも通じるのではないでしょうか。仕事では自分が利用者とは限りませんが、ヒアリングの段階で普段の業務や手間がかかる場面を聞くことで、理解を深められると思います。要望された機能だけでなく、その機能を必要とする場面まで知ったうえで、最初にどこまで作るかを一緒に決めていきたいです。

開発の進み方に、自分の理解が追いついていなかった

今回、使いやすさについては自分たちの生活を基準に判断できました。画面を触って要望を返し、彼女にも喜んでもらえたので、日常の手間を減らすアプリとして手応えがあります。

ただ、その反応だけで技術的な品質や安全性まで判断できるわけではありません。自分は画面やテスト結果を確認していましたが、機能を支える処理をすべて追えていたわけではありませんでした。

たとえば、Googleログイン後のリクエストがどこを通り、APIでどう本人を識別するのか。入力した支出がどこに保持され、保存結果がどう画面へ反映されるのか。構成図にサービス名を書けても、一連の処理をコードや設定と結びつけて説明するには、まだ理解が足りない部分があります。

AIと開発を進めて実現できた範囲に、自分が仕組みを理解して対応できる範囲が追いついていない。これが、今回感じた「作れる」と「運用できる」の距離でした。

品質を判断するために、仕組みを理解したい

「精算済みの支出を変更できないようにする」という要望を考えても、その実現方法は一つではありません。画面の編集ボタンを隠すことと、APIやDBで変更を拒否することでは、守れる範囲が違います。このアプリでは複数の層で制限していますが、その違いを知らなければ、提案された実装が十分かを判断しづらくなります。

高い品質を目指すには、AIに目的や条件を伝えることに加え、その実現方法を自分でも評価できることが大切だと感じました。テストについても、成功したという報告を確認するところから、何をどの方法で検証しているかを読み取れるようになりたいです。

人が最初から唯一の正解を知っている必要はないと思います。AIと相談して設計を決めることもできます。ただ、提案の理由を理解し、別の方法と比較する場面では、自分の基礎知識をもっと深めたいと感じました。

自分の専門外では、説明の中の言葉が分からず、さらに何を質問すればよいか迷う場面もありました。認証なら署名や有効期限、画面なら状態管理など、仕組みを理解するために学びたいことが増えました。

自分がAIと対等に会話したいと思うのは、こうした場面です。回答を受け取るだけでなく、前提を確認し、疑問を返し、採用する理由を自分でも考えられるようになりたい。今の担当に直接関係しなさそうな分野でも、学んだ知識がその会話を支えるのだと思います。

運用に備えて、処理を自分で追う時間を取りたい

これから運用していくうえで、まずは普段どのように動いているかを理解しておきたいです。たとえば支出を保存できなくなったとき、ブラウザ、認証、API、DBのどこで止まっているかを調べるには、通常の処理の流れが手がかりになります。

セキュリティやコストについても、Accessでどの経路を保護しているか、どの処理がサービスの使用量につながるかを把握しておきたいです。今の理解のままでは、設定変更や利用量の増加による影響を十分に判断できるか不安が残ります。

まずは「支出を1件保存する」といった身近な操作から、次の流れをコードや設定で追っていきたいです。

画面がどのAPIへ何を送るか
どこで本人確認と操作権限の確認を行うか
APIが何を検証してDBを更新するか
成功や失敗をどう画面へ返すか

AIに該当するファイルや設定を示してもらい、実際のコードや公式ドキュメントと照らし合わせます。分からない概念を学び、ローカルで条件を変えて理解したとおりに動くかを確かめたいです。

これは、すべての障害を一人で解決できるようになるという話ではありません。調べる場所や変更の影響を判断し、自分で分からない部分は詳しい人に相談できる状態を目指しています。

AI時代のエンジニアとして、お客様の期待にどう応えるか

自分で作ったアプリでも、仕組みが分からない部分には不安があります。この経験から、システムを依頼するお客様にも、外から見えない部分への不安があるのではないかと考えました。

今回、彼女が喜んでくれたのは、日々の入力や精算、共有が楽になったことでした。この経験を仕事にも活かすなら、まずお客様が何に困り、システムによってどう変わることを期待しているのかを理解したいです。そのうえで、予算や納期、使う環境に合った方法をAIと検討し、必要な品質を確かめて届けることが、自分の目指す応え方です。

AIで開発を速く進められることも、そのために活かせると思います。早い段階で動くものを見せて認識を合わせたり、実装にかかる時間を減らせたら、その分を検証や運用の準備に使ったりしたいです。今回のモック開発で要望が具体的になったように、AIを使ってお客様と確かめる機会を増やしていこうと考えています。

そして、納品後も使い続けてもらうために、お客様が導入や運用を判断する助けになる説明をしたいです。たとえば「利用者を増やしたい」と相談されたとき、費用やアクセス権限への影響を調べ、必要な変更と注意点を伝えられるようになりたい。コードの細部まで説明する場面でなくても、その根拠となる仕組みは自分が理解しておきたいと思います。

エンジニアの説明責任は以前からありました。AIによって自分の理解を超える範囲まで開発を進められるようになるほど、その説明に根拠を持てているかは、より強く問われると感じます。AIの回答をそのまま伝えるのではなく、実装や設定、確認した結果に基づいて説明したいです。

そのためにも、何ができて、どこに制約があり、何がまだ分かっていないかを整理して伝えたいです。安心してもらうことを目指しつつ、未確認のことまで大丈夫だと言わない姿勢も大切にしたいと思います。

今回の個人開発は、彼女に喜んでもらえたという意味では大成功でした。次は、使い続けてもらうために自分の理解を深めていく番です。

AIの力を使ってお客様の期待を形にし、その仕組みを理解したうえで、品質や運用について判断し説明できるエンジニアになりたい。 そのために、得意分野だけでなく、使う技術の原理や仕組みを広く学んでいこうと思います。自分たちのアプリで「作れる」と「運用できる」の距離を埋めていく経験を、仕事でもお客様の期待に応える力につなげたいです。

ここまで読んでいただきありがとうございました！