生成AI関連
Windowsで始めるCodexアプリ入門
見積作成や案件管理といった業務アプリを、エンジニアではない担当者が生成AIで内製する例が出てきています。弊社にも、「社内アプリを生成AIで内製し始めたものの、機能の更新、エラーへの対応、コードレビューを支援してほしい」というご相談をいただくことがあります。動くところまでは作れたのに、その先の保守と品質確認で足が止まる。そういう段階です。
この記事では、その相談の前段にあたる「作る側」の工程を、Codexデスクトップアプリ（以下、Codexアプリ）で最後まで進めます。前提として、依頼する人はプログラムを書けません。使う技術を指定できませんし、できあがったコードも読めません。それでも社内で使えるアプリが1本できるまでに、何をどう頼み、どこを自分で判断したのかを順に追います。
プログラムを書けない立場で用意すべきなのは、技術の指示ではなく業務の答えでした。最初の依頼は「案件管理と見積のアプリを作ってほしい」の1行で足ります。そこから先は、Codexの質問に業務の言葉で答えていけば要件が固まります。ただし、Codexが聞かなかったことと、こちらも答えなかったことは、そのまま実装に残ります。今回は消費税の端数処理がそれでした。完成したアプリは、明細ごとに消費税を四捨五入する作りになっていました。画面は正常に動きますし、自動テストも成功します。それでも、請求書と金額を揃えるつもりなら直しておくべき箇所です。
インストール手順、WSL2の設定、Codex agentの切り替えは扱いません。この範囲は以下の記事で説明しています。
プロジェクト固有の指示をまとめるAGENTS.mdと、作業の前後にスクリプトを挟むHooksについても、それぞれ別の記事があります。
本記事は2026年8月時点の内容です。Codexは更新の速い製品のため、画面や表示が変わっている場合は最新の公式ドキュメントも確認してください。
基幹システム全体を依頼すると、決めるべきことが多すぎて、こちらが答えを出せません。一方、練習用のToDoリストでは、完成しても社内で使う場面がありません。
そこで今回は、案件管理と見積作成に絞りました。案件情報と見積をExcelやスプレッドシートで管理していると、担当者ごとに別のファイルができ、案件の進み具合を表す言葉も揃わないまま数だけが増えていきます。金額の計算も、担当者の手作業しだいです。この題材なら、決めるべきことは業務の言葉で答えられる範囲に収まります。しかも、できたものはそのまま社内で使えます。
作ったアプリの範囲は次の6点です。
| 作るもの | 内容 |
|---|---|
| 案件の登録と一覧 | お客様名、進捗、担当営業などを登録し、絞り込んで探す |
| 見積明細の登録 | 案件ごとに品名、数量、単位、単価、税率を登録する |
| 金額計算 | 小計、税率ごとの消費税、税込合計を自動で表示する |
| 確認状況の記録 | 営業部長と経理が確認した日時を残す |
| 見積書PDF | 取引先へ提出できる形で明細と合計を出力する |
| 変更の履歴 | 案件の登録・変更・削除と、会社情報の変更を時系列で残す |
ログインと権限管理、顧客マスタ、Excelからのデータ移行、受注や請求への連携は対象外です。社内の一部で使う確認用ツールという位置づけを保つためで、この線引きもCodexの質問に答えていく中で決まりました。
完成したのは「見積帖」という名前のアプリで、画面は次の4つです。
生成AIでアプリを作る記事では、要件と技術構成を細かく書いた依頼文が例示されることがあります。しかし、使う言語やデータの保存方法を指定できる人は、そもそも自分で作れます。プログラムを書けない人が用意できるのは、「案件管理と見積のアプリを作ってほしい」という1行程度です。
1行で依頼すると、Codexは足りない情報を自分で埋めて作り始めます。出てきたものは動きますが、想定とは違う形になります。そこで、最初の依頼では作業を始めさせず、質問を先に求めました。
案件管理と見積のアプリを社内で使いたいです。
私はプログラミングが分からないので、作り方はそちらで決めてください。
作り始める前に、決めておくべきことを質問してください。
一度に全部ではなく、5個くらいずつ聞いてもらえると答えやすいです。
専門用語が出てくるときは、意味も一緒に書いてください。
「5個くらいずつ」と指定したのは、質問が一度に20個も並ぶと回答が滞るからです。専門用語の意味も一緒に求めたのは、意味の分からない語が混ざった質問に雰囲気で答えてしまうのを避けるためです。
返ってきた質問は、ほとんどが業務の言葉で答えられるものでした。実際のやり取りを抜き出すと次のようになります。
| Codexからの質問 | 今回の回答 |
|---|---|
| このアプリを使うのは、どの部署・何人くらいですか？ | 営業3人と事務1人。同時に使うことはほとんどありません |
| 管理したい「案件」とは、どんな仕事ですか？ | お客様からの問い合わせです |
| 見積書は、誰が作成・確認・送付しますか？ | 営業が作成し、営業部長が確認し、経理が最終チェックをしたのちに営業がお客様へメール送付します |
| 今は案件や見積を何で管理していますか？ | Excelで管理しています。移行は考慮しなくてよいです |
| 最初に必ずできるようにしたいことを、優先順に3つほど挙げてください。 | 案件の一覧管理、見積書PDFの作成、進捗状況の管理です |
| 案件の進捗は、どんな段階で管理したいですか？ | 新規問い合わせ → ヒアリング中 → 見積作成中 → 部長確認中 → 経理確認中 → 送付済み → 受注／失注 |
| 案件ごとに残したい情報は何ですか？ | お客様名、担当者名、電話番号・メールアドレス、問い合わせ内容、営業担当、見込金額、希望納期、次の対応予定日 |
| 見積書に載せたい自社情報は決まっていますか？ | 1. 会社名、住所、電話番号、振込先、消費税の扱い、見積書番号 |
| 見積の承認は、部長・経理それぞれが「確認済み」にするだけで足りますか？それとも、差し戻し（修正依頼）やコメントも必要ですか？ | 初期段階では不要 |
| お客様へのメール送付は、アプリからメールも送れるようにしたいですか？それとも、PDFを作って普段のメールソフトに添付できれば十分ですか？ | PDFを作ってダウンロードできれば十分です |
| 利用者ごとにログインを分けたいですか？ | 初期段階ではログイン機能は不要です |
| 営業部長と経理は、案件を確認するだけですか？ それとも内容を修正することもありますか？ | 確認するだけでよいです。修正は営業担当者が行います |
| 見積書の商品・作業の明細は、どのように入力したいですか？ | 品名、数量、単位、単価、金額を複数行で入力し、小計・消費税・合計金額を自動計算 |
| 見積書番号の付け方に希望はありますか？ | 案件番号と同じ |
| 一覧画面で、特に見たい・絞り込みたい項目はありますか？ | 進捗、担当営業、お客様名、次の対応予定日、見込金額 |
| 部長確認・経理確認は、各案件にある「確認済み」ボタンを押す形でよいですか？押した人の名前は取れないため、初期版では「確認済みになった日時」の記録だけにする想定です。 | よいです |
| 消費税は、原則10%で自動計算してよいですか？軽減税率8%や、非課税・税抜／税込の切り替えも必要でしょうか？ | 必要です |
| 案件を受注・失注にした後も、一覧に残して検索できるようにしてよいですか？ | よいです |
| 間違って作った案件・見積を削除できるようにしますか？ | 削除できるようにしてください |
| アプリは社内のパソコンで開くWeb画面として作ります。Windowsのブラウザ（EdgeやChrome）で使えれば問題ないですか？ | Chromeで使えれば問題ないです |
| 見積の金額入力は「税抜金額」を基本にして、最後に消費税を加算する形でよいですか？それとも「税込金額」を入力したいですか？ | 最後に消費税を加算する形でよいです |
| 税率は、明細ごとに「10%／8%／非課税」を選べるようにしますか？ | はい |
| 見積書の発行日は、PDFを作る日に自動で入る形でよいですか？ 日付を手動で変更できる必要はありますか？ | 自動で入る形でよいです |
| 見積書の有効期限は必要ですか？必要なら、通常の日数・期間も教えてください。 | 発行日から30日でお願いします |
| アプリのデータは、社内の決まったパソコン1台に保存する形で始めてもよいですか？同時利用がほぼないとのことなので、まずはこの方法がシンプルです。将来、複数のパソコンから使える形へ広げることもできます。 | 社内の決まったパソコン1台に保存する形でよいです |
想像以上の質問攻めにあいましたが、ここまで確認してくれると、頭の中にあるものとのずれは最小限に抑えられそうですね。
今回は25問すべてに答えられたので、「保留」と印を付けた項目はありません。ただ、答えられない項目が出たときは、そこで止めずに印を付け、誰に確認すれば決まるかまで書き残しておきます。逆に言えば、聞かれなかった項目には印を付けようがありません。後半で挙げる改善点は、この網をすり抜けたものです。
ここでCodexが急にアプリを作り始めようとしたため、実行をキャンセルさせました。
キャンセルした理由は、生成AIが理解した内容に齟齬がないかを確認するためです。受託開発で例えるなら、お客様が出した要件を受託側がどう解釈したかをすり合わせないまま開発に入るようなものです。発注側の立場からすると「本当に理解しているのか？」と不安になりますよね。
そこで次の依頼では、答えた内容を日本語の一覧にまとめさせました。人が読んで判断できる形にしておけば、認識のずれを早めに直せて、手戻りも防げます。
今の回答をもとに、作るものを日本語の一覧にまとめてください。
私が読んで判断できるように、専門用語は避けてください。
- どんな画面があるか
- 各画面で何ができるか
- 今回は作らないもの
- 私が答えられなかった項目と、誰に確認すれば決まるか
まとめができたら、「これが全部できたら完成」と言える条件も
一覧にしてください。
返ってきた一覧は「案件管理・見積アプリ：初期版で作るもの」という題でした。画面は4つに整理されていて、「案件一覧」「案件の内容を見る・編集する画面」「変更の履歴」「会社情報・データ」という構成です。「今回は作らないもの」には、ログイン、顧客マスタ、請求書の発行、アプリからのメール送信、Excelデータの移行が並びました。この一覧が、以降の作業の基準になります。
Codexアプリでは、作業対象のフォルダを開いてから依頼します。依頼の前に決めるのが承認モードです。ファイルの書き込みやコマンドの実行を毎回確認する設定から、確認なしで進める設定まで選べます。Codexが触れる範囲をフォルダの中だけに制限する仕組み（サンドボックス）も、ここで指定します。
技術が分からなくても、ここだけは自分で決めます。プログラムの中身は読めなくても、「どこまで触っていいか」は業務の判断だからです。今回選んだのは「代わりに承認」という設定です。開いたフォルダの中であれば、書き込みもコマンドの実行も、毎回確認せずに進みます。
最初からすべてを許可すると、意図しない操作が走ったときに止める余地がなくなります。逆に毎回すべてを確認する設定にすると、内容の分からない確認画面に十数回応じることになり、最後は中身を読まずに許可してしまいます。フォルダの中は任せ、外に出る操作だけ止める。プログラムを書けない立場では、この線引きが現実的な落としどころでした。
実装の依頼では、技術の選定をCodexに任せました。あわせて、あとから困らないための条件を4つ足しています。
先ほどまとめてもらった内容で作ってください。
- 使う道具（プログラミング言語やデータの保存方法）は、
あとから直しやすいものをそちらで選んでください。選んだ理由も教えてください
- 途中で判断に迷ったら、勝手に決めずに私に質問してください
- 金額の計算が正しいかどうかを、私が毎回手で確かめなくても
分かるようにしてください。失敗したときに何が違うのか
日本語で分かる形にしてください
- あとから変更をたどれるように、変更の履歴を残す仕組みも用意してください
- 作業が終わったら、私が画面で確認する手順を書いてください
Codexが選んだのは、HTML・CSS・JavaScriptだけで動く構成でした。特別な開発ソフトを入れずに済み、あとから直しやすいから、という理由でした。データは作業に使うパソコンのChromeに保存され、万一に備えてファイルへ書き出す機能も付きます。見積書はChromeの「PDFに保存」でPDFにする、とのことです。
7分ほどで「初期版を作成しました」という報告が返ってきました。変更されたファイルは8つ、追加された行数は243行です。画面での確認手順は「使い方と確認手順.md」というファイルにまとまっていました。金額計算の自動テストも、すでに実行済みとのことです。
金額の計算は、明細を1行ずつたどって消費税を出す作りでした。参考までに載せておきます。読めなくても問題はありません。あとでエンジニアに見てもらうときの材料になります。
export const TAX_RATES = { '10': 0.1, '8': 0.08, '0': 0 };
export function calculateQuote(lines) {
const rows = lines.map((line) => {
const quantity = Number(line.quantity) || 0;
const unitPrice = yen(line.unitPrice);
const amount = Math.round(quantity * unitPrice);
const taxRate = String(line.taxRate ?? '10');
const tax = Math.round(amount * (TAX_RATES[taxRate] ?? 0));
return { ...line, quantity, unitPrice, amount, taxRate, tax };
});
const subtotal = rows.reduce((sum, row) => sum + row.amount, 0);
const tax10 = rows.filter((r) => r.taxRate === '10').reduce((sum, r) => sum + r.tax, 0);
const tax8 = rows.filter((r) => r.taxRate === '8').reduce((sum, r) => sum + r.tax, 0);
return { rows, subtotal, tax10, tax8, total: subtotal + tax10 + tax8 };
}
画面には、小計、消費税（10%）、消費税（8%）、合計が並んで表示されました。「金額の計算が正しいかどうかを、私が毎回手で確かめなくても分かるようにしてください」という依頼への答えは、2つの形で返ってきました。1つは明細表の下に出る「✓ 金額の確認：計算に問題はありません」という表示、もう1つは金額計算の自動テストです。
Codexは「使い方と確認手順.md」というファイルを一緒に置いていきました。中身は、画面で確かめる手順が6つ。案件を登録できるか、進捗と確認状況を残せるか、金額が自動計算されるか、見積書PDFを作れるか、変更の履歴を見られるか、データの控えを保存できるか。書かれた順に画面を触ると、6つとも手順どおりに動きました。
自動テストの結果も確認できます。実行そのものはコマンドの操作になるので、Codexに頼みました。「金額の自動テストを実行して、結果を日本語で教えてください」と送ると、成功した項目名が日本語で返ってきます。今回は「税率別に小計と消費税を計算する」「計算と違う保存値があれば、違いを日本語で返す」の2つでした。項目名が日本語なので、失敗したときにどの確認が落ちたのかも読み取れます。
ただし、ここで確かめたのは機能が動くことだけです。この時点のアプリには、業務の答えを出さないまま任せた項目がそのまま残っていました。
手元のアプリを業務の側から見直すと、直したい点が4つ出てきました。どれも動作の不具合ではないので、次の表のどの行も、画面上は正常に見えます。いちばん重いのは1つ目の金額の話なので、以下ではそこに紙幅を割きます。
| 改善したい点 | なぜ画面で気づけないか |
|---|---|
| 消費税の端数処理が明細ごと | 表示された金額が正しいかどうかは、社内の決まりを知らないと判断できない |
| 発行日が案件の登録日で固定される | 日付が入っているので、欄が埋まっていること自体は正常に見える |
| 一覧の見込金額が見積の合計と別管理 | どちらの数字も入っているため、食い違っていても気づきにくい |
| 控えを取るのが手作業のまま | 押し忘れた期間があっても、画面には何も出ない |
Codexは税率について質問してきました。10%と8%を明細ごとに選べるようにするか、税抜を基本にして最後に消費税を足すか。どちらにも答えています。ただ、端数をどの単位で何回処理するかは聞かれませんでしたし、こちらも指定しませんでした。
その結果が、先ほど載せた計算の Math.round(amount * (TAX_RATES[taxRate] ?? 0)) という行です。明細1行ごとに消費税を四捨五入し、それを税率ごとに足し上げています。
試しに5行の明細を入れて、2つの計算方法を比べます。
| 品名 | 数量 | 単価 | 金額 | 税率 |
|---|---|---|---|---|
| 会議用チェア | 12 | 8,933 | 107,196 | 10% |
| 折りたたみテーブル | 3 | 15,732 | 47,196 | 10% |
| 搬入・設置費 | 1 | 24,755 | 24,755 | 10% |
| 贈答用菓子詰合せ | 5 | 3,789 | 18,945 | 8% |
| 来客用ペットボトル飲料 | 7 | 1,298 | 9,086 | 8% |
| 計算方法 | 消費税（10%） | 消費税（8%） | 消費税の合計 | 税込合計 |
|---|---|---|---|---|
| 今のアプリ（明細ごとに四捨五入） | 17,916円 | 2,243円 | 20,159円 | 227,337円 |
| 税率ごとにまとめて1回だけ切り捨て | 17,914円 | 2,242円 | 20,156円 | 227,334円 |
3円の差が出ます。明細ごとに四捨五入すると、切り上げ側の端数が積み上がるためです。明細が増えるほど、差も開きます。
インボイス制度で定められた適格請求書には、消費税額の端数処理の回数について決まりがあります。
一方、インボイスでは、端数処理のルールが定められており（一のインボイスにつき、税率の異なるごとに１回）、税率ごとに合計した対価の額に税率を乗じて消費税額を求めることになる。
以上のことから、明細行ごとの端数処理等を行っている場合には、請求書等に係るシステム改修が必要となる。インボイスの端数処理ルールと記載例について（財務省資料、日本税理士会連合会サイト掲載）
見積書は請求が確定した書類ではないため、適格請求書としての記載要件は課されません。インボイス制度の対象外であることは、請求ABCなどでも説明されています。それでも、見積の金額と請求の金額がずれれば、入金の照合や差額の処理を手作業で行うことになります。どちらの計算に合わせるかは、自分で決める話ではありません。経理に聞いて決めます。
この差は、画面の「金額の確認：計算に問題はありません」という表示には出ません。この表示が確かめているのは、保存されている金額とアプリの計算結果が一致しているかどうかです。計算の方針が業務のルールと合っているかは見ていません。自動テストも同じで、いまの計算方法を前提に書かれています。
質問には「見積書の発行日は、PDFを作る日に自動で入る形でよいです」と答えました。実際にできたのは、案件を登録した日が発行日の欄に入り、そのまま保存される作りです。8月に登録した案件を9月にPDFにすると、発行日は8月のままになります。
有効期限も同じで、登録した日から30日後で固定されています。発行日を手で書き換えても、有効期限はそのままです。どちらも手で直せるので運用でしのげますが、直し忘れれば期限切れの見積書を送ることになります。
答えたことと、できあがったものが食い違った例です。要件を日本語の一覧にさせておいたので、画面と読み比べれば気づけました。
案件一覧に出る金額は「見込金額」の欄に手で入れた数字です。見積明細を入れて合計が出ても、この欄は変わりません。絞り込みの「この金額以上」も見込金額を見ています。見積を作ったあとに見込金額を直し忘れると、一覧の数字と見積書の金額が食い違います。
これは仕様どおりです。「一覧画面で絞り込みたい項目」に見込金額を挙げたのはこちらで、見積の合計と揃えたいとは伝えていません。伝えていないことは実装されません。
「社内の決まったパソコン1台に保存する形でよいです」と答えた結果、データはそのパソコンのChromeの中に入っています。控えが取れるのは「データを保存する」ボタンを押したときだけで、手順書には「月に一度を目安に」と書かれていました。パソコンが壊れたりChromeを初期化したりすると、押し忘れた期間に入力した分は戻せません。
直し方を指定できないのは、最初の依頼と同じです。代わりに伝えるのは、業務のルールと、期待する状態です。
消費税の端数処理は、まず経理に聞くところから始まります。仮に「税率ごとにまとめて、端数処理は1回だけ、端数は切り捨て」という答えだったなら、次のように頼みます。
経理に確認したところ、消費税の計算方法は次のとおりでした。
- 税率ごとに金額をまとめてから消費税を計算する
- 端数処理は税率ごとに1回だけ行う
- 端数は切り捨てる
今のアプリがどう計算しているかを調べて、この方法に合わせてください。
直したあとで、次の4つを教えてください。
- 今はどう計算していて、どこをどう変えたか（専門用語なしで）
- 直したことで、画面のどの数字が変わるか
- 5行くらいの見積で、直す前と直したあとの金額を並べて見せてください
- この計算方法を、金額の自動テストにも追加してください
期待する状態を数字や条件で書くのが要点です。「正しく直して」だけでは、何が正しいかを判断する材料がありません。直す前と直したあとの金額を並べさせておけば、コードを読まずに結果を確認できます。
日付と見込金額のずれは、画面を触っていて気づきました。気づいた順にそのまま並べて渡します。
実際に使ってみて、直したいところが3つ出ました。
直し方はそちらで決めてください。
1. 見積書の発行日を、PDFを作る日に自動で入るようにしてください。
今は案件を登録した日のままになっています。
手で変えたいときもあるので、変えられる状態は残してください。
2. 有効期限を、発行日から30日後に自動で入るようにしてください。
発行日を変えたら、有効期限も一緒に変わるようにしてください。
3. 一覧に出る見込金額と、見積の合計金額が別々になっています。
見積を作ったあとは、一覧でも見積の合計が分かるようにしてください。
どちらの数字を残すかで迷ったら、決めずに私に聞いてください。
直したあと、私が画面で確認する手順も書いてください。
残りは控えの取り方です。こちらでは方法を決められないので、前提だけを渡して相談します。
データの控えについて相談です。
今は「データを保存する」を押したときだけ控えが取れる形で、
押し忘れた分は戻せません。押し忘れても困らない形にできますか。
方法はそちらで決めてください。前提にしてほしいことは次の3つです。
- 使うのは社内の決まったパソコン1台で、営業3人と事務1人です
- 社外のサービスにデータを置くのは、今の段階では避けたいです
- 控えがどこに、いつの分まで残っているかを、
私が画面で確認できるようにしてください
決めるときに私の判断が必要な点があれば、作業を始める前に質問してください。
3つのプロンプトとも、技術の指定は入れていません。入れたのは、社内のルール、期待する状態、譲れない前提の3種類だけです。プログラムを書けない立場で用意できるのは、ここまでです。
エンジニアであれば、修正を頼んだあとに変更前と変更後のコードを見比べます。コードを読めない立場では、この手段が使えません。そこで、変更内容を日本語で説明させます。修正を頼んだら、続けてこれを送ります。
今回の3つの変更内容を、次の形で説明してください。
- 変更したファイルの名前と、それぞれ何をするファイルか
- どこをどう変えたか
- 金額の計算に関係する変更はどれか
- この変更で動かなくなる可能性がある画面はどこか
- 私が画面で確認しておくべき項目
返ってきた説明、画面での確認、自動テストの結果を組み合わせれば、変更の範囲は判断できます。今回のアプリは、金額の計算、画面の表示、データの保存が別々のファイルに分かれた作りです。「金額の計算だけを直した」という説明が本当なら、画面のファイルには手が入っていないはずです。どのファイルを触ったかも一緒に説明させておけば、この食い違いは読み取れます。
一方で、この方法で確認できないことも残ります。説明が実際の変更と一致しているかは、コードを読める人でなければ検証できません。金額、取引先の情報、権限に関わる部分では、動作確認だけでは足りません。消費税の端数処理がまさにその例で、経理に聞くまで判断できませんでした。
そこで、変更の種類で線を引きました。画面の追加や表示の調整は自分で進め、金額の計算、データの保存方法、権限に関わる変更は外部のレビューに出します。
この3つを外部に回したのは、いずれも画面を見ても正しさが分からない領域だからです。金額については今回のとおりで、表示された数字が正しいかどうかは、社内の取り決めを知る人が計算して初めて分かります。
データの保存方法は、事務所の1台で使う限り問題が出ません。ただしデータはそのパソコンのChromeの中にあるので、別のパソコンから開いても何も表示されず、Chromeを初期化すれば消えます。この前提が崩れたときに何が起きるかは、1台での動作確認では見えません。
権限はもっと厄介です。本来見えてはいけない案件が実際に隠れているかを確かめる作業になるので、画面が正常に見えるほど確認が難しくなります。
金額まわりだけでも外に見てもらえる先を決めておけば、内製を止めずに済みます。
作り終えたあとに振り返ると、Codexに任せた判断と、任せなかった判断は次のように分かれました。
| Codexが決めたこと | 自分が答えたこと | 外部に確認することにしたこと |
|---|---|---|
| 使う言語とデータの保存方法 | 使う人数と案件の件数 | 消費税の計算方法と端数処理 |
| 画面の構成とファイルの分け方 | 案件に持たせる情報 | 見積と請求で金額を揃える必要性 |
| 金額計算の実装方法 | 進捗の8つの区分 | 金額計算のコードレビュー |
| 自動テストの作り方 | 見積書PDFの要否 | 権限管理を足す場合の設計 |
| 説明書の書き方 | データを置く場所と利用範囲 | 同時利用が増えた場合の保存方法 |
Excelで管理していると、「提案中」「提案済」「見積提示」と似た区分が際限なく増えていきます。それを避けるため、進捗は新規問い合わせから受注・失注までの8つに決めました。データの保存先をそのパソコンのChromeの中にしたのも、事務所の1台で使うと答えたからです。利用者が増えて同時に更新するなら、この前提は成り立ちません。
残った改善点も、実装の誤りが原因ではありません。端数処理のように答えを出さないまま任せたか、見込金額のように伝えていなかったか、そのどちらかです。Codexの質問に答えるだけでは、聞かれなかった項目が手つかずで残ります。答え終わったところで、金額と日付とデータの置き場所だけでも自分で洗い直しておく。技術を学ぶより先に、この一手間のほうが内製を支えます。
同じ流れを再現する場合に送るのは、次の7つです。全文はそれぞれの節に掲載しています。
| 順 | 依頼の目的 | 外せない要求 | 掲載している節 |
|---|---|---|---|
| 1 | 決めるべきことを洗い出させる | 作り始める前に、決めておくべきことを質問してください | 1行だけ頼んで〜 |
| 2 | 回答を日本語の一覧にまとめさせる | 私が答えられなかった項目と、誰に確認すれば決まるか | 質問に業務の言葉で答え〜 |
| 3 | 実装させる | 使う道具は、あとから直しやすいものをそちらで選んでください | 承認モードを決め〜 |
| 4 | 金額の計算を業務のルールに合わせる | 直す前と直したあとの金額を並べて見せてください | 改善も業務の言葉で頼む |
| 5 | 画面で気づいたずれを直させる | 直し方はそちらで決めてください | 改善も業務の言葉で頼む |
| 6 | 変更内容を日本語で説明させる | 金額の計算に関係する変更はどれか | コードが読めなくても〜 |
| 7 | 引き継ぎ用の説明書を作らせる | 私が判断できず、経理や取引先に確認した項目 | 本節 |
7つ目だけ、まだ全文を載せていません。作業の最後に送るものです。
このアプリを他の人が引き継げるように、説明書を作ってください。
専門用語には説明を付けてください。
- 起動のしかたと、画面での確認手順
- 消費税の計算方法と、そうしている理由
- 変えてはいけない部分と、その理由
- 今回作らなかった機能
- 私が判断できず、経理や取引先に確認した項目
最後の項目を残しておくと、次に触る人が同じ確認をやり直さずに済みます。
フォーマットを指定しない場合は、基本的にマークダウンファイルで作成されることが多いです。
一方でエンジニアではない方にとって、マークダウンは慣れていないと思われます。
一度作成させた後からでも、Wordなどで作成させることも可能です。
先ほどの説明書をWord形式で作成してください。
プログラムを書けない前提でも、案件管理と見積作成のアプリは1本できました。用意したのは業務の答えです。ここでの業務の答えとは、使う人数や案件の件数のような事実に加えて、消費税をどう計算するかのように「社内で決まっているはずのこと」を含みます。前者は自分で答えられ、後者は確認先を知っているだけで足ります。技術の指示は一度も書いていません。
残ったのは、その答えを出さなかった項目でした。消費税の端数処理と、見積書の発行日です。日付のずれに気づけたのは、要件を日本語の一覧にさせて画面と読み比べたからです。消費税のほうは、計算方法を経理に確認して初めて判断できました。どちらも、自分から探しにいかなければ表に出ません。
まずは、お手元の見積書と請求書を1件ずつ並べ、消費税の計算方法が一致しているかを確かめてください。ずれていれば、それが最初に社内で決めるべき項目です。そのうえで着手するなら、次の候補は受注後の請求書発行への連携と、複数名で使う場合の権限管理でしょう。どちらも金額や取引先の情報を扱うため、画面での確認だけでは足りません。コードレビューをどこに頼むかを、先に決めておいてください。
Tech Funでは、お客様のフェーズに合わせ、生成AI活用に向けた様々な支援をご提供しています。
生成AIに限らず、Web・業務システム開発やインフラ設計など、技術領域を問わずご相談を承っています。「何から始めれば良いか分からない」という段階でも構いませんので、ぜひお気軽にお問い合わせください。
