ChatGPTとCodexで作った業務ツールを育てる方法｜非エンジニアでも迷わない7ステップ
ChatGPTやCodexで作った業務ツールを、画面が動いただけで終わらせず、現場で使える仕事道具まで育てる方法を、非エンジニア向けに7ステップで整理しました。MVP思考と、改善点を4つに分けて優先度を決めるフレームを、現場で実際に育てた経験ベースで解説します。
ChatGPTやCodexで業務ツールを作ったあと、画面が動いた瞬間に「完成」と思って、そのまま使うのをやめてしまう人が多い。実際には、画面が動いたところが「スタート」や。 実際の仕事で使って、面倒だった箇所を一つだけ直す。この繰り返しでしか、AIで作ったツールは「仕事道具」にならへん。この記事では、非エンジニアでも迷わずに進められるよう、業務ツールを育てる7ステップと、改善点を4つに分けて優先度を決めるフレームを、現場で実際に育ててきた経験からまとめる。
結論｜AIで作ったツールは「育てる前提」で作る
結論から言うと、AIで作った業務ツールは、最初から完成形を目指さんでええ。
小さく作る → 実際の仕事で使う → 面倒な箇所を一つだけ直す → もう一度使う
この繰り返しで、ツールは少しずつ「仕事道具」へ育っていく。一発で完璧を狙うほど、機能を盛りすぎて、かえって使いにくくなる。これは、わしが何度もやらかしてきて、ようやくたどり着いた結論や。
この記事の流れは、こうなる。
まず、なぜ「全部入り」がうまくいかへんのかを説明する。次に、MVPという考え方を、非エンジニア向けに翻訳する。そのうえで、7ステップの育て方と、改善点を4つに分けて優先度を決めるフレームを示す。最後に、Codexへ修正を頼むときの注意点と、やってはいけない5つを整理する。
なぜ「最初から全部入り」を作るとうまくいかへんのか
最初から全部入りのツールを作ると、3つの問題が起きる。
ひとつめ、機能が増えるほど、壊れる箇所が増える。
ふたつめ、Codexへ一度に大量の修正を頼むと、新しい機能は完成するんやけど、前まで動いていた機能が壊れることがある。
みっつめ、非エンジニアの場合、問題が起きたときに「どのファイルを見たらいいのか」「どの変更が原因なのか」「Codexに何を伝えたらいいのか」が分からなくなる。
実際、わしも何度もこの罠にハマってきた。ChatGPTに「Codexへ渡す指示文を作ってください」と頼んで、出てきた指示文をそのままCodexへ渡す。追加機能は完成する。でも、別の機能で不具合が出る。その不具合を直すと、また別の機能が壊れている。これを延々と繰り返した時期があった。小さなツールやと、ここまで派手には起きへん。機能が増えて規模が大きくなるほど、この罠にハマる。
だから、最初は一つの作業だけを終わらせられる、小さなツールでええ。
プロフィール情報を入力したら、Markdown形式の文章が出る。投稿のテーマを入力したら、ChatGPTへ渡すプロンプトが出る。文字起こしを貼り付けたら、要約とSNS投稿案が出る。まずはこの程度で十分や。動くものを作って、自分で一度使ってみる。そのあとで、必要な機能だけを足していく。
MVPは「手抜き版」やない｜次に何を直すか知るための最小実用版
システム開発の世界では、よく「MVP」という言葉が使われる。
MVPは、Minimum Viable Product（ミニマム・バイアブル・プロダクト）の略。日本語やと「実用最小限の製品」と訳されることが多い。エリック・リースという人が『リーン・スタートアップ』という本の中で広めた考え方で、本来の定義はこうなっている。
顧客から最大限の学びを得るための、最小バージョンの製品
ちょっと難しく聞こえるかもしれへん。非エンジニア向けに、もう一段かみ砕いて翻訳すると、こうなる。
最初のバージョンは、完成品やない。次に何を直すべきかを知るための、最小実用版や。
MVPは、機能を適当に削った「手抜き版」やない。本当に必要な機能を見つけるために、まず小さく作る、という考え方や。
最初から大きなアプリを作ると、自分が必要やと思い込んでいた機能まで作り込んでしまう。でも、実際に使うと、意外なことが分かる。
- 必要やと思っていた機能を、ほとんど使わへん
- 想定していなかった小さな手間が、毎回ストレスになる
- 便利そうな機能より、コピーボタン一つのほうが役立つ
こういう気づきは、画面設計を眺めているだけでは出てけえへん。自分で触って、実際の仕事に使うから分かることや。
AIを使うと、ツールの最初の形を作るスピードは圧倒的に上がる。だからこそ、最初から作り込みすぎないほうがええ。小さく作って、早い段階で使い始める。 使って分かったことを、次の改善に反映する。この進め方のほうが、現場では無駄が少なくなる。
業務ツールを「仕事道具」に育てる7ステップ
ここからが、この記事の本題や。
AIで作った業務ツールを、実際に使える「仕事道具」まで育てる流れを、7ステップで整理する。難しいことは何もない。順番に進めていけば、誰でもできる。
Step 1｜小さく作る
最初のツールは、一つの作業だけを終わらせられればええ。
入力フォーム、データ保存、ログイン、デザイン、履歴管理、複数アカウント切り替え。アイデアは次々と出てくるかもしれへん。でも、最初から全部入れようとすると、完成せえへんで終わる。
わしも色々作ってきた。診断系のツール、見積・請求まわりのツール、プロンプトジェネレーター、ニュース収集ツール。どれも最初から完成形やったわけやない。最初はもっと単純で、「これだけできれば、今日の仕事は楽になる」というレベルから始めた。
Step 2｜実際の仕事で使う
ツールができたら、すぐに実際の仕事で使う。
「動くか確認するためのテスト」やない。本当の仕事で、本当のデータを入れて、最後まで使う。
ここを飛ばすと、改善点が見えてこない。画面の上で「動いた」を確認しただけでは、現場で何が面倒かは分からへん。
Step 3｜面倒だった箇所をメモする
使いながら、面倒だった箇所をその場でメモする。
形式は何でもええ。テキストファイル、付箋、スマホのメモ、何でも。大事なのは、「面倒や」と感じた瞬間に記録すること。あとから思い出そうとしても、細かいことは忘れる。
メモには、こんな内容を書いておく。
- 今回入力した内容
- 使って不便だったこと
- 今回、優先して直したいこと
- 後で直したいこと
「後で直したいこと」は、今すぐ直さんでもええ。リストとして残しておけば、次の改善で迷わへん。
Step 4｜改善点を一つだけ選ぶ
メモから、今回直す改善点を「一つだけ」選ぶ。
複数の改善点を一気に直したくなる気持ちは分かる。でも、まとめて直すと、どこで何が壊れたか分からなくなる。
選ぶときの基準は、次の章で詳しく説明する4分類フレームを使う。先に結論だけ言うと、事故を防ぐ改善（品質リスク）を最優先、次に出力の手直し、最後に操作の手間と入力項目の追加、という順番で決める。
Step 5｜ChatGPTで改善内容を整理する
Codexへいきなり指示を出さない。先に、ChatGPTで改善内容を整理する。
「もっと使いやすくしてください」「いい感じに改善してください」だけでは、Codexは何を変えるべきか判断しにくい。先にChatGPTで、何を追加するか、何を残すか、どこまで変えてよいかを整理してから、Codexへ渡す。
整理用のテンプレートは、後の章で示す。
Step 6｜Codexで直す
整理した内容を、Codexへ渡す。
ここでも一気に変えへん。今回選んだ改善点だけを直す。Codexが修正したあと、すぐに次の改善へ進まず、必ず動作確認する。
Step 7｜もう一度、実際の仕事で使う
修正が終わったら、画面の上で確認するだけで終わらせへん。もう一度、本当の仕事で使う。
ファイル名は分かりやすいか。文字化けしていないか。不要な説明文が混ざっていないか。見出し構成は使いやすいか。別のアカウントでも使えるか。ここまで確認してはじめて、一つの改善が「終わり」になる。
このあと、また面倒な箇所が見つかったら、Step 3へ戻る。これを繰り返していく。
改善点を4つに分けて、優先度を決める
実際に使い始めると、改善案は次々と出てくる。10個も20個も並ぶことがある。
全部直したくなるけど、まとめて直すと壊れる。だから、改善点を「4つの分類」に振り分けて、優先度を決める。
| 改善タイプ | 気づくサイン | 改善の方向性 | 緊急度 |
|---|---|---|---|
| 品質リスク | 上書き事故・情報漏れ・データ混在の不安がある | 確認ステップ・バックアップ・データ分離 | 最優先 |
| 出力不足 | 生成後に毎回手作業で整え直している | 出力形式・ファイル分割・命名規則 | 高 |
| 操作の手間 | 同じ情報を何度も入力している・毎回コピペしている | 保存・初期値・履歴・コピーボタン | 中 |
| 入力項目不足 | 生成後に毎回同じ条件を書き足している | 入力欄・プリセット・選択肢の追加 | 中 |
優先度の判断軸はシンプルや。業務ツールとして使うなら、「事故を防ぐ改善」が最優先。次に「手直しを減らす改善」。便利さの改善は、その後でええ。
品質リスク｜便利さより、事故を防ぐ
業務ツールで一番怖いのは、便利さの不足やなくて、事故や。
- 入力途中で内容が消える
- 以前のファイルを誤って上書きする
- APIキーやパスワードを含むファイルまで保存される
- 複数アカウントのデータが混ざる
こういうリスクが見つかったら、便利な機能の追加より先に直す。事故を防ぐ改善を後回しにして便利な機能を足しても、いつか痛い目を見る。
出力不足｜「毎回整え直している」を出力側へ持たせる
生成された内容を、毎回人間が整え直しているなら、出力形式に問題がある。
- Markdownの見出しを付け直す
- ファイル名を毎回変更する
- プロフィールとトンマナを手作業で分割する
- 不要な説明文を毎回削除する
こういう手直しが繰り返されているなら、出力側へ機能を持たせる。手作業の繰り返しは、改善のサインや。
操作の手間｜「同じ情報を何度も入れている」を減らす
同じ情報を何度も入力しているなら、保存や再利用の仕組みを検討する。
最初から複雑なデータベースを作る必要はない。ブラウザ内へ一時保存する、前回の入力を読み込めるようにする、初期値として表示する。この程度でも、作業時間は減る。
入力項目不足｜「毎回書き足している」を見つける
生成後に、毎回同じ条件を書き足しているなら、入力項目が足りていない可能性がある。
たとえば、投稿文生成ツールを使うとき、毎回「文字数は30文字前後」「専門用語を減らす」「最後は自然なCTAにする」と書き足している場合。これは、最初から選択項目として用意したほうが楽や。
毎回、人間が同じ修正をしているなら、ツール側へ持たせる。これが入力項目不足の判断軸や。
「一度に直すのは一つだけ」を守る理由
改善案が見つかると、全部まとめて直したくなる。でも、最初は一つずつ進めたほうが安全や。
理由は3つ。
ひとつめ、一気に直すと、どこで問題が起きたか分からなくなる。
ふたつめ、Codexへ大量の修正を頼むと、追加機能は完成しても、前まで動いていた機能が壊れることがある。
みっつめ、非エンジニアが原因を切り分けようとしても、「どのファイルを見たらいいのか」「どの変更が原因なのか」が分からへん。
わしも、何度もやらかしてきた。ChatGPTにCodexへの指示文を作らせて、その指示文をそのままCodexへ渡す。追加機能は完成する。でも、別の機能で不具合が出る。その不具合を直すと、また別の機能が壊れている。小さなツールやと、ここまで派手には起きへん。機能が増えて大規模になってくるほど、この罠にハマる。
だから、最初は一つずつ。コピーボタンを追加する。動作確認する。次にファイル名を調整する。動作確認する。その次に出力ファイルを分割する。この順番で進めれば、問題が起きても原因を絞りやすい。
AIは、たくさんの指示を一度に渡すほど便利になるわけやない。仕事の流れを分けて、一つずつ任せる。これは、AIを業務で使うときの基本姿勢でもある。
ChatGPTで改善内容を整理してから、Codexへ渡す
ツールを使って不便な箇所を見つけても、いきなりCodexへ曖昧な指示を渡さんほうがええ。
「もっと使いやすくしてください」
「いい感じに改善してください」
「便利な機能を追加してください」
これでは、Codexは何を変えるべきか判断できへん。先にChatGPTを使って、改善内容を整理する。
丸投げが失敗する理由
ChatGPTやCodexは賢いけど、こちらの仕事の文脈を全部知っているわけやない。「いい感じに」と頼まれても、Codex側は「何を残すか」「どこまで変えていいか」「どの機能を壊してはいけないか」を判断する材料がない。
その結果、こちらが想定していない部分まで変えられて、前まで動いていた機能が壊れる。これが、丸投げが失敗する一番の理由や。
整理用テンプレート（コピペ可）
ChatGPTで改善内容を整理するときに使うテンプレートを置いておく。次の項目を埋めてから、ChatGPTへ渡す。
現在、Codexで作った小さな業務ツールを改善したいです。
【ツールの目的】
（例：入力したプロフィール情報から、ChatGPTプロジェクト用のMarkdownファイルを生成する）
【現在できること】
（例：
・フォームへ情報を入力できる
・Markdown形式の文章を画面上へ表示できる
・表示された文章をコピーできる）
【実際に使って不便だったこと】
（例：
・Markdownを手作業でファイル保存する必要がある
・複数アカウントで使うと、ファイル名が分かりにくい）
【今回追加したい改善】
（例：
・生成したMarkdownを、ファイルとしてダウンロードできるようにする
・ファイル名へアカウント名を入れる）
【残したい既存機能】
（例：
・現在の入力欄
・画面上のプレビュー
・コピーボタン）
この内容を整理して、
Codexへ渡す修正依頼文を作成してください。
一度に大きく変更せず、
今回の改善に必要な範囲だけを修正する指示にしてください。
最後に、
修正後に確認すべき項目も付けてください。このように整理しておくと、Codexへ丸投げする状態を避けられる。何を追加するのか、何を残すのか、どこまで変えてよいのか、修正後に何を確認するのか。 人間側が先に決めておくと、手戻りを減らせる。
その場の修正やない｜他の機能への影響と、未来のメンテナンス性を必ず書く
ここが、わしが「これは育って良かった」と一番強く感じたポイントや。
改善依頼を出すとき、指示文に必ずこの一文を入れるようにしている。
「この修正で、他の機能に影響が出ないか調査してください。影響が出る場合は、修正の方向を確認してください。今後のメンテナンス性も考慮して、機能改善をお願いします。」
この一文を入れるようになってから、修正の質が圧倒的に変わった。
それまでは、「この場の不具合だけ直して終わり」やった。だから、別の場所がまた壊れる。何度も同じことを繰り返していた。
でも、「他の機能への影響を調査してください」と先に伝えておくと、Codexは修正前に関連箇所を確認するようになる。「ここを直すと、こっちの機能にも影響が出ます」と先に教えてくれる。修正の方向性を、こちらが判断できる状態になる。
さらに、「今後のメンテナンス性も考慮してください」と書いておくと、その場しのぎやない、後から見ても分かる修正をしてくれるようになる。
たった一文や。でも、この一文があるかないかで、ツールの育ち方が変わる。ピラー記事の中で、ここは一番太字で覚えてほしいところや。
改善後は、必ず実際の仕事で使う
Codexに修正してもらい、画面の上でボタンが表示された。これだけで「完成」にしたらあかん。
もう一度、実際の仕事で使う。
- ファイル名は分かりやすいか
- 文字化けしていないか
- 不要な説明文が混ざっていないか
- 見出し構成は使いやすいか
- 別のアカウントでも使えるか
ここまで確認すると、新しい改善点が見つかる。それが、次のサイクルの入口になる。
業務ツールは、画面の表示が完成したら終わりやない。実際の仕事の流れに入れて、最後まで使えるかを確認して、はじめて一つの改善が完了する。
AIで作ったツールを育てるときに、やってはいけない5つのこと
最後に、わしが何度もやらかしてきた「やってはいけない5つ」を整理しておく。
ひとつめ、複数の修正を一気に頼むこと。 どこで何が壊れたか分からなくなる。一度に直すのは一つだけ。
ふたつめ、改善メモを取らないこと。 「あとで思い出そう」と思っても、思い出されへん。面倒だと感じた瞬間にメモする。
みっつめ、壊れたときに元へ戻す手段を用意していないこと。 Codexで修正する前の状態を残しておかへんと、おかしくなったときに戻されへん。フォルダのコピーでもいいから、修正前の状態を残しておく。
よっつめ、画面が動いたら完成にすること。 動くことと、現場で使えることは違う。必ず実際の仕事で使ってから「完了」と判断する。
いつつめ、便利さだけ追って、事故防止を後回しにすること。 業務ツールで一番怖いのは、便利さの不足やない。データ事故や情報漏れや。便利な機能の追加より、事故を防ぐ改善を先にする。
まとめ｜AIで作ったツールは、育てて初めて仕事道具になる
AIを使えば、以前より早くツールの最初の形を作れるようになった。でも、最初に出てきたものを、そのまま使い続ける必要はない。
小さく作る → 実際の仕事で使う → 面倒な箇所を一つだけ直す → ChatGPTで整理してCodexで直す → もう一度使う
この繰り返しで、最初は小さかったツールが、自分の仕事に合った道具へ変わっていく。
そして、Codexへ修正を頼むときは、「他の機能への影響を調査してください」「今後のメンテナンス性も考慮してください」の一文を必ず添える。これだけで、修正の質が大きく変わる。
AIは、完成品を一発で出してもらうためだけのものやない。一緒に試して、直して、仕事の型を育てるための相棒や。
AIは飾りちゃう。仕組みにしてナンボやで。
AI大将の公式LINEでは、AIを業務へ落とし込むときの実践ノウハウや、現場で試した結果を発信しています。AIで作ったツールを「使える仕事道具」まで育てたい人は、登録しておいてください。
よくある質問（FAQ）
Q. ChatGPTやCodexで作った業務ツール、最初は何から直せばいいですか
実際の仕事で使って、最初に面倒だと感じた箇所から直す。複数あるなら、4分類（品質リスク・出力不足・操作の手間・入力項目不足）で振り分けて、品質リスクから手をつける。便利さの改善より、事故を防ぐ改善を先にすると、安心して使い続けられる。
Q. 改善案が10個出てきました。どれから直すべきですか
一つずつ進める。優先順位は、品質リスク → 出力不足 → 操作の手間 → 入力項目不足、の順で決めるとシンプルや。残りはメモに残しておけば、次のサイクルで使える。
Q. AIに「いい感じに直して」と頼むと、前まで動いていた機能が壊れます。どうすればいいですか
丸投げを避ける。先にChatGPTで「何を追加するか・何を残すか・どこまで変えてよいか」を整理してから、Codexへ渡す。さらに指示文に「他の機能への影響を調査してください」「今後のメンテナンス性も考慮してください」と添えると、修正の質が大きく変わる。
Q. AIで作ったツール、いつ「完成」と判断していいですか
完成という状態はない。実際の仕事で使って、改善点が見つからなくなるまでは育て続ける。改善点が見つかったら、そのつど一つずつ直していく。これが、業務ツールを「仕事道具」として使い続けるコツや。
Q. 非エンジニアでも、AIで作ったツールを育てていけますか
育てられる。コードを書く必要はあらへん。やることは、実際の仕事で使う、面倒な箇所をメモする、改善点を一つ選ぶ、ChatGPTで整理する、Codexへ渡す、もう一度使う。この繰り返しや。AIを業務に組み込むスキルは、コードを書くスキルとは別の能力で、現場の経験のほうが効いてくる。
