Codexで業務ツールを自作する第一歩｜見積書・請求書ツールをMVPで作って分かった完成基準と修正点
Codexで業務ツールを自作したい非エンジニア向けに、見積書・請求書ツールをMVPで作った実践過程をまとめた。完成基準の決め方、Codexへの指示の出し方、初回版で起きた4つの問題と修正内容まで、現場で確認した内容だけを書いている。
Codexを契約してみたものの、何から作ったらええか分からん。生成AIで業務ツールを自作してみたいけど、最初の一歩で止まっている。そんな話を、わしの周りでよく聞く。
この記事では、わしが実際にCodexで「見積書・請求書ツール」をMVPで作った過程を、順を追ってまとめる。結論を先に言うと、最初に作るべきは「機能の数」やなくて「仕事の流れを最後まで通せる小さなツール」や。 何をどこまで作るか、Codexへ何をどう伝えるか、初回版で何が起きてどう直したか。現場で確認したことだけを書いている。
結論｜Codexで業務ツールを作るなら、MVPは「小さく作る」やない。「仕事の流れを通す」や
MVPと聞くと、「機能を削った手抜き版」と思う人が多い。実際には違う。
MVPは、仕事の流れを最後まで通せる最小のツールのこと。
機能の数を減らすことが目的やない。入力して、計算して、保存して、再利用するところまで、一つの流れとしてつながっているか。ここがMVPのコアや。
見積書・請求書ツールで言うと、「入力フォームだけ動く」「PDFだけ出る」では、仕事の流れになっていない。お客さん情報を入れて、明細を埋めて、計算が合って、PDFが出て、後で見返せる。ここまで通って、はじめて「仕事道具になる最小版」と呼べる。
この考え方を先に決めておくと、Codexへの依頼内容も、初回版の確認方法も、ブレへんようになる。
今回Codexで作ったもの｜見積書・請求書ツールの完成イメージ
第1回で作ったのは、ブラウザだけで完結する見積書・請求書ツールや。サーバーもデータベースもない。ファイルを開いたら使える、最小構成のツールから始めた。
このツールは、実際に触れる形で公開している。記事を読みながら動きを確認したい人は、こちらから試してほしい。
一画面で、入力・プレビュー・保存・PDF出力までつながる
画面構成は、左側が編集パネル、右側がA4プレビューパネル。
左で項目を入力すると、右のプレビューへ即時反映される。番号、日付、宛先、自社情報、明細、消費税、合計、備考までを一画面でまとめて確認できる。印刷ボタンを押せば、ブラウザのPDF出力でA4の帳票が出る。保存ボタンを押すと、ブラウザの中へデータが残る。次に開いたとき、続きから再開できる。
これだけや。これだけやけど、見積書を作って、請求書へ複製して、もう一度開き直すところまで、一本の流れで通せる。
「機能の数」やなく「仕事の流れ」をMVPにした
最初に意識したのは、「機能を減らす」やなく、「仕事の流れを切らさへん」やった。
たとえば、保存機能がないと、お客さんから「あの見積、金額もう一度確認できる？」と言われたときに対応できへん。複製機能がないと、見積書をそのまま請求書へ移すたびに入力し直しになる。PDF出力がないと、お客さんへ送る形式にならへん。
機能の有無で判断するんやなく、仕事の流れを一本通せるかで判断する。 この基準を先に決めたから、Codexへの依頼もシンプルになった。
Codexへ実装を頼む前に決めた4つの完成基準
Codexへいきなり「見積書・請求書ツール作って」と頼んでも、ろくな結果にならへん。先に、自分の中で完成基準を言語化しておく必要がある。
わしが今回決めた完成基準は4つや。
| 完成基準 | 何を確認するか |
|---|---|
| 見た目 | A4帳票として読みやすいか。罫線、フォント、余白、改ページの位置 |
| 操作性 | 入力に迷わず、プレビューへ即反映されるか。明細追加・削除がスムーズか |
| 正確性 | 計算が壊れず、不正入力（負数・空欄・全角数字）でも画面が落ちへんか |
| 再利用性 | 保存・復元・複製・帳票種別の切り替えができるか |
見た目｜A4帳票として読みやすいか
帳票は、お客さんが受け取って判断する書類や。見た目が雑やと、ツールがいくら便利でも、相手へ送れへん。
罫線が太すぎへんか。フォントが帳票として違和感ないか。会社印や角印を入れる余白があるか。明細が増えたときに、改ページ位置が変にならへんか。A4で印刷したとき、お客さんへ渡せる体裁になっているか。 これを最初の基準にした。
操作性｜入力に迷わず、プレビューへ即反映されるか
業務ツールは、自分が毎日触るもんや。1秒の手間が、月に何十回も積み上がる。
明細を1行追加するのに、いちいち別画面へ移動するようでは使われへん。入力欄をクリックしてから反映までに数秒かかるようでは、ストレスが溜まる。プレビューが見にくいと、見積書の最終形を頭の中で再構築せなあかん。
入力した瞬間に右のプレビューへ反映される。明細の追加・削除がワンクリックで終わる。 これを操作性の最低ラインにした。
正確性｜計算が壊れず、不正入力でも画面が落ちへんか
業務ツールで一番怖いのは、便利さの不足やなくて、間違いや。
数量を負数で入れたら合計がマイナスになる。空欄を含む明細で計算がNaN（数値ちゃう）になる。全角数字を入れたら計算結果が0になる。こういう小さな崩れが、本番で起きると致命傷や。
不正入力が来ても、計算が壊れへん。画面が落ちへん。値はおかしくても、警告は出る。 ここをCodexへ明確に伝えた。
再利用性｜保存・復元・複製・帳票切り替えができるか
帳票は一度作って終わりやない。見積書を出して、後日請求書へ切り替えて、別案件で内容を流用する。この流れを支えるのが再利用性や。
保存ボタンで現状を残せる。次に開いたとき復元できる。見積書から請求書へワンクリックで複製できる。帳票の種別を切り替えても、入力データが消えへん。この4つができれば、第1回MVPとしては十分や、と決めた。
MVPに入れた機能と、今回は入れなかった機能
完成基準を決めたら、次は機能の取捨選択や。MVPの肝は、ここでブレへんことやと思う。
入れた機能｜帳票を作って、保存して、再利用するまで
第1回MVPに入れた機能は、次のとおり。
- 見積書・請求書の種別切り替え
- 番号の自動採番（種別の接頭辞付き）
- 発行日・宛先・自社情報の入力
- 明細行の追加・削除・並び替え
- 数量・単価・合計の自動計算
- 消費税率の選択と消費税額の自動計算
- 備考欄の自由入力
- ブラウザ内へのデータ保存と復元
- 見積書から請求書への複製
- 印刷（ブラウザのPDF出力）
10機能ある。「これだけ入れてMVPなんか？」と思うかもしれへん。でも、これより少ないと、仕事の流れが途中で切れる。機能の数を絞るんやなく、流れが切れる場所をなくす。 これがMVPを設計するときのコツや。
入れなかった機能｜ログイン・DB・マスタ・会計連携
逆に、今回あえて入れへんかった機能も整理しておく。
- ログイン認証
- サーバーサイドのデータベース
- 取引先マスタ
- 商品マスタ
- 過去帳票の検索・一覧
- インボイス番号の管理
- 振込先口座の自動表示
- 会計ソフトとの連携
- 複数ユーザーでの共同編集
- メール送信機能
正直、どれも欲しい。実務で使うなら全部あったほうがええ。
でも、第1回でこれを全部入れようとすると、確実に完成せえへん。ログインを入れた瞬間に、サーバー、データベース、認証フロー、セキュリティ設計と、考えることが10倍に膨らむ。マスタを入れると、データ構造の設計とCRUDの実装が必要になる。
最初の一歩で、ここまで広げると、Codexも迷うし、わしも迷う。 第1回は「一人で帳票を作って、保存して、再利用できる」までで線を引いた。
なぜ削ったのか｜検証範囲を決めたほうが、Codexが迷わへん
機能を削るのは、欲しくないからやない。今回検証したい範囲を、明確にするためや。
第1回で確認したかったのは、「Codexだけで、A4の帳票がきちんと出るブラウザツールを、最小構成で完成させられるか」やった。この問いに答えるためには、ログインもDBもマスタも要らへん。
検証範囲を絞っておくと、Codexへの依頼内容が短くなる。短い依頼は、出力もブレにくい。MVPで一番効くのは、機能を削ることやなく、検証範囲を決めることや。
Codexへ最初の実装を頼むときの伝え方
完成基準と機能範囲が固まったら、Codexへ依頼する。ここで雑に頼むと、ろくな結果にならへん。
「いい感じに作って」は失敗する｜要件と受け入れ条件を分けて渡す
最初にやってしまいがちなのが、こういう頼み方や。
「ブラウザで動く見積書ツール、いい感じに作ってください」
これでは、Codexは何を作ればええか分からへん。明細の数は何行までか。消費税は8%と10%の両対応か。保存はどこに残すか。PDF出力は必要か。何も決まっていない状態で出てきたコードは、十中八九、自分の用途と合わへん。
わしが意識したのは、依頼を「要件」と「受け入れ条件」に分けて渡すことや。
要件は、「何を作るか」。受け入れ条件は、「何ができたら完成と判定するか」。この2つを分けると、Codexの出力もブレにくくなるし、初回版の確認も楽になる。
具体的には、こんな構成で渡した。
【要件】
・ブラウザだけで完結する見積書・請求書ツールを作る
・左側が編集パネル、右側がA4プレビューパネル
・明細は最大20行、数量・単価・合計を自動計算
・消費税率は8%・10%・非課税の3択
・データはブラウザのlocalStorageへ保存
・印刷はブラウザの印刷機能でA4PDF出力
【受け入れ条件】
・入力したら、即時にプレビューへ反映される
・明細の追加・削除・並び替えができる
・数量や単価を負数・空欄・全角で入れても画面が落ちへん
・見積書から請求書への複製がワンクリックでできる
・印刷時、明細が増えても改ページが破綻しない
・保存後、ブラウザを閉じて再度開いても復元できる
【今回入れない機能】
・ログイン認証
・サーバーサイドのデータベース
・取引先マスタ・商品マスタ
・会計ソフト連携この形で渡すと、Codexは「何を作るか」と「どう動けば完成か」の両方を理解した状態でコードを書いてくれる。
受け入れ条件を先に決めると、初回版の確認が楽になる
受け入れ条件を先に書いておくと、もう一つ利点がある。初回版が出てきたとき、自分でチェックリストとして使える。
「入力したらプレビューへ反映される」→確認OK。「明細を負数で入れても画面が落ちへん」→これは落ちた、要修正。こんなふうに、受け入れ条件を一つずつ確かめていくだけで、初回版の評価が終わる。
頭の中で「なんか使いにくいな」と思いながら触るのと、明確な基準でチェックしていくのは、確認の精度が全然違う。
初回版で見つかった4つの問題｜動いたけど、使いにくかった
Codexから出てきた初回版は、確かに動いた。明細を増やせるし、計算もする。保存もできる。印刷もできる。
でも、実際に1件分の見積書を最後まで作ってみると、地味に気になる箇所が4つ出てきた。
明細の削除ボタンが画面からはみ出した
明細行に「削除」ボタンを置いたら、横幅が足りなくて、ボタンが画面外へはみ出した。スクロールせなあかんし、間違えて隣の項目を押してしまう。これは操作性の基準を満たしていない。
種別を切り替えるたび、帳票番号が新しくなった
「見積書」と「請求書」の種別を切り替えるたびに、帳票番号が新しい連番に振り直された。同じ案件で見積書→請求書と進めるとき、番号が連続してほしいのに、毎回新規番号になる。これでは、案件の同一性が失われる。
負数を入れても計算は0、でも入力欄にはマイナスが残った
数量や単価に負数を入れたとき、計算結果は0で補正されていた。ここはええ。でも、入力欄の表示は「-100」のまま残った。画面上は負数、計算上は0という、視覚と動作のズレが起きた。 これは間違いを誘発する。
明細の項目名が窮屈で読みにくかった
明細行の左端に項目名（「Webサイト設計・デザイン」など）を入れる欄があった。文字数が多いと、列の幅が足りずに、文字が途中で切れる。長い項目名は、業務でよく出てくる。読めへんと使い物にならへん。
どう直したか｜地味な修正こそ、仕事道具の品質を決める
4つの問題を、Codexへ追加修正として一つずつ渡した。ここで一気に4つまとめて頼まへんかったのが、後から効いてきた。
一気に頼むと、修正後にどこが直ってどこが壊れたか分かりにくい。一つずつ確認すれば、Codexへの追加指示も短くて済む。
明細を二段配置に変更
削除ボタンを行内に置くと幅が足りなくなる。そこで、明細行を二段に分けた。
上段に項目名、下段に数量・単価・金額・削除ボタンを横並びで配置。これで、項目名の文字数が増えても、操作系のボタンが窮屈にならへん。
帳票番号は接頭辞だけ切り替え
帳票番号は、種別を切り替えても番号本体は維持する設計に変えた。
「EST-2026-0001」が見積書、「INV-2026-0001」が請求書。接頭辞だけ切り替えて、番号は同じ。同じ案件の見積書と請求書がペアになる。業務上の意味と、UI上の挙動を一致させた。
負数は0へ自動補正
数量や単価へ負数が入ったとき、計算だけ0にするんやなく、入力欄の表示も0へ補正する設計に変えた。
画面上の数字と、計算上の数字が一致する。これだけのことやけど、毎日触るツールでは、こういう小さな一貫性が効いてくる。
項目名を独立した上段へ
明細行の二段化に合わせて、項目名は上段の独立した1行へ広げた。
「Webサイト構築一式（コーポレートサイト・5ページ・スマホ対応）」みたいな長い項目名でも、最後まで読める。実務の帳票は、項目名が長くなりがちや。ここを窮屈にしておくと、ツールが現場で使われへんようになる。
実務の流れを通して確認する｜見積書から請求書への複製まで
修正が終わったら、もう一度、最初から最後まで通して使う。これは画面のテストやない。仕事の順番で操作する。
機能テストやなく、仕事の順番で操作する
「ボタンを押したら反応する」を一つずつ確認する形のテストやと、現場で使ったときの違和感が見えてこない。
わしが確認したのは、こういう流れや。
- 新しい見積書を作る
- 宛先を入れる
- 明細を3行入れる
- 消費税率を10%に設定
- 備考に「振込手数料はご負担ください」と入れる
- 印刷プレビューでA4の体裁を確認
- 保存する
- ブラウザを閉じて、もう一度開く
- 復元されているか確認
- 見積書→請求書へ複製
- 番号が「EST-2026-0001」から「INV-2026-0001」へ切り替わるか確認
- 請求書の備考に振込先口座を追記
- 印刷プレビューでA4の体裁を再確認
この流れで操作してみて、引っかかる場所がなければ、第1回MVPは完成と判定できる。
架空データで確認した計算結果
確認には、架空データを使った。本番データを使うと、計算間違いがあったときに被害が出る。
使ったデータは、こんな内容や。
- 宛先：ミライ架空商店 御中
- 件名：コーポレートサイト構築
- 明細1：Webサイト設計・デザイン 数量1 単価120,000円
- 明細2：コーディング 数量3 単価25,000円
- 消費税率：10%
このとき、ツールが出した計算結果は次のとおり。
- 小計：195,000円
- 消費税：19,500円
- 合計：214,500円
電卓で計算した値と一致した。架空データで計算を確認してから、本番運用へ進める。 この順番は守ったほうがええ。
本番運用へ進める前に押さえること｜便利さより、事故を防ぐ
ツールが動いたら、実際の案件で使いたくなる。本番運用へ進めて構わへん。ただし、その前に2点だけ押さえておくと、後で慌てずに済む。
ブラウザのlocalStorageは「消える可能性のある保存先」
第1回MVPでは、保存先にブラウザのlocalStorageを使った。これは、ファイルを開いたらすぐ動くので、MVPには相性がええ。
ただし、特性として次は理解しておく。
- ブラウザのキャッシュをクリアすると、データが消える
- 別のブラウザや別のPCからは見えへん
- 自動的なバックアップは取られへん
- 複数人で共有できない
つまり、保存はされる。でも「データが永遠に残る保存先」やない。一人で自分の事業用に使う範囲なら、これでも十分動くけど、作った見積書・請求書のPDFは別フォルダへ書き出して保管しておく運用にしておくと安心や。
別端末との共有や、複数人での運用が前提なら、保存先をもう一段先のローカルDBや、その先のサーバーDBへ進める必要がある。
法務・税務はツール任せにしない
もう一つ、よく勘違いされるところを書いておく。
見積書や請求書のフォーマットは、業界や取引先によって求められる項目が違う。インボイス制度に対応するなら、登録番号や税率ごとの区分記載が必要や。源泉徴収が絡む場合は、源泉徴収額の表示も必要になる。
これらをツールに自動で全部やらせようとすると、ツール側が複雑になりすぎて、MVPの段階では破綻する。 第1回MVPは、あくまで「自分の事業で、自分の取引先向けに使う最小版」として作っている。
法務・税務の最終判断は、自分の状況に合わせて、専門家へ確認する。ツールはあくまで作業を効率化する道具で、判断の責任までは持てへん。ここの線引きは、最初に意識しておいたほうがええ。
次に足す機能の選び方｜思いついた順やなく、詰まりが大きい順
第1回MVPを使ってみると、足したい機能が次々と出てくる。取引先マスタ、商品マスタ、過去帳票の一覧、メール送信、会計連携。全部欲しい。
でも、思いついた順に足していくと、ツールが膨らみすぎて、また壊れる原因になる。詰まりが大きい順に足していく。 これが基本や。
詰まりの大きさを判断する観点は、別記事で4分類フレームとしてまとめている。改善点を「品質リスク」「出力不足」「操作の手間」「入力項目不足」の4つに振り分けて、優先度を決める考え方や。Codexで作ったツールを育てていく段階で、ここの判断軸があるとブレにくくなる。
→ AIで作ったツールを壊さずに育てる｜改善点を4つに分けて優先度を決める方法
第2回は「ローカルDB接続とマスタ登録」へ進む
第2回では、保存先をlocalStorageからブラウザ標準のローカルDB（IndexedDB）へ移し、取引先マスタと商品・項目マスタ、それから請求データの保存と集計まで進める。これが、第1回MVPで一番大きな詰まりやったからや。
毎回、宛先を手入力するのは手間。商品名・単価も毎回同じものを打ち直している。ここをマスタ化すれば、入力時間がガクッと減る。さらに、発行した請求書を保存しておけば、今月いくら請求したか、顧客別にいくら請求しているかも、別表へ転記せずに確認できる。
サーバーは使わへん。クラウドDBも使わへん。ブラウザの中で完結する構成のまま、保存と集計の段階へ進む。詳しい実装過程は、第2回の記事でまとめる。
まとめ｜小さく作ることと、雑に作ることは別物や
Codexで業務ツールを自作するとき、一番やりがちな失敗は、「小さく作る」と「雑に作る」を混同することや。
機能を10個に絞ったMVPでも、完成基準を4つ決めて、受け入れ条件を先に言語化して、初回版の問題を一つずつ直していけば、ちゃんとした仕事道具になる。小さく作るのは、雑に作る言い訳やない。検証範囲を明確にするための設計や。
第1回でわしがやったことは、次のとおり。
- 完成基準を「見た目・操作性・正確性・再利用性」の4つに絞る
- 検証範囲を「一人で帳票を作って、保存して、再利用する」までに限定する
- Codexへの依頼を「要件」と「受け入れ条件」に分けて渡す
- 初回版の問題を一つずつ直す
- 架空データで計算を確認してから、本番運用へ進める
ここまでやって、ようやく第1回MVPと言える状態になる。
Codexは、依頼の精度を上げるほど、出力の精度も上がる。逆に、丸投げすると、丸投げに見合った結果しか返ってこない。業務ツールの品質は、AIの性能やなく、依頼する側の言語化で決まる。
今回作ったツールは、AI大将のツールページで実際に触れる。仕事の流れがどう通っているかは、文章で読むより、自分で動かしたほうが早い。
次回は、保存先をブラウザ内のローカルDBへ移し、取引先マスタ・商品マスタ・請求データ保存・売上集計までを追加する第2回MVPへ進む。
AI大将の公式LINEでは、Codexやその他AIツールを業務へ落とし込むときの実践ノウハウを、随時お届けしています。第2回・第3回の記事公開もLINEで先に告知するので、続きを追いかけたい人は登録しておいてください。
よくある質問（FAQ）
Q. 非エンジニアでもCodexで業務ツールを作れますか
作れる。コードを書く必要はあらへん。やることは、何を作るかを言語化する、完成基準を決める、Codexへ要件と受け入れ条件を分けて渡す、出てきた初回版を実際に触る、不具合を一つずつ修正依頼で返す。この繰り返しや。コードを読む力より、自分の業務を言葉で説明する力のほうが効いてくる。
Q. MVPはどこまで機能を絞ればいいですか
機能の数で絞るんやなく、検証したい範囲で絞る。たとえば見積書ツールなら、「一人で帳票を作って、保存して、再利用するところまで」と決めれば、ログインもマスタもDBも要らへん。検証範囲が決まれば、必要な機能は自動的に絞られる。
Q. Codexへの指示で一番大事なポイントは何ですか
「要件」と「受け入れ条件」を分けて渡すこと。要件は「何を作るか」、受け入れ条件は「何ができたら完成と判定するか」。この2つを分けると、Codexの出力もブレにくいし、初回版が出てきたときに自分でチェックリストとして使える。
Q. 作ったツールに本番データを入れていいですか
入れてええ。むしろ、本番データを入れて使わへんと、ツールとは呼べへん。架空データで動作確認したあとは、自分の事業の範囲内で本番運用へ進めて構わへん。
ただし、第1回MVPの保存先はブラウザのlocalStorageや。これは、キャッシュクリアでデータが消える、別のPCからは見えへん、複数人で共有できへん、という特性がある。だから、使い始める前にバックアップの取り方を決めておく。具体的には、保存後にPDFを別フォルダへ書き出しておく、定期的にlocalStorageの中身をJSONとして書き出しておく、といった運用や。別端末との共有や複数人での運用が前提なら、第2回でブラウザ内のローカルDB（IndexedDB）へ進めたうえで、さらにサーバー側DBへ進む判断が要る。
Q. 次に何を学べばいいですか
まずは、自分が今回作ったツールを、実際の仕事で1週間使ってみる。使ってみると、必ず詰まる場所が出てくる。その詰まりを「品質リスク・出力不足・操作の手間・入力項目不足」の4分類で整理して、一番大きいものから直していく。詳しくは関連記事の「AIで作ったツールを壊さずに育てる」を参照。
