こえけん

ChatGPTとClaude Codeで仕事やサービスを作る過程を発信｜非エンジニアからAI開発に挑戦中｜Webサービス・業務効率化・自動化｜成功も失敗もそのまま記録します。

[こえけん @koeken_dev]

ChatGPTとClaude Codeを使って、
「AIで本当に仕事を作れるのか？」を実践しています。

僕は本職のエンジニアではありません。

それでも今、

・顧客管理アプリの開発
・Webサービス制作
・業務自動化
・スマホアプリ化

などに挑戦しています。

このアカウントでは、
成功したことだけでなく、
エラー、失敗、AIへの指示ミスなども含めて発信します。

ChatGPT＝考える
Claude Code＝作る

この2つを使って、
「考える → 作る → 使う → 仕事にする」
までやってみます。

詳しい実践記録はnoteにまとめています👇
https://t.co/p3AQWgkcdk

[こえけん @koeken_dev]

最近、Claude Codeに

「どう実装するのがいい？」

と聞くだけじゃなく、

「3つ案を出してください」

と頼むことが増えました。

例えば、

① 変更範囲を最小にする案
② 保守性とのバランスを取る案
③ 将来の拡張性を重視する案
この3つ。
さらに、

・変更するファイル
・メリット／デメリット
・既存機能への影響
・戻しやすさ
・あとから別案へ移行できるか

まで比較してもらう。

1つだけ提案されると、それが“正解”に見えやすい。
でも3案あると、
「今の自分にはどれが合う？」
で考えられる。
最近は、

AIに決めてもらうというより、判断材料を出してもらって自分で選ぶ

という使い方の方がしっくりきています。

今日のnoteでは、Claude Codeに3案出してもらって比較するときの聞き方をまとめました👇
https://t.co/Ut5VSgOogD

[こえけん @koeken_dev]

Claude Codeに、

「この方法がおすすめです」

と言われると、以前の僕はそのまま採用してました。

でも最近は、そこで一度止まります。

聞くのはこの5つ。

・なぜその方法がおすすめ？
・他の方法はない？
・デメリットは？
・もっと小さく実装できない？
・元に戻しやすい方法はどれ？
特に大事なのが、
「一般的に良い方法」と「今回の目的に合う方法」は同じとは限らない
ということ。
将来の拡張性を考えた綺麗な設計でも、
今の目的には大きすぎることがある。

だから最近は、

AIに正解を聞くというより、選択肢を出してもらって比較する

という使い方が増えました。

Claude Codeが「おすすめ」と言った瞬間は、
実装開始ではなく、むしろ検討開始なのかもしれません。
今日のnoteでは、僕が採用前に確認している5つをまとめました👇
https://t.co/o2fIEl6FTi

[こえけん @koeken_dev]

ChatGPTで仕様を整理して、Claude Codeに渡した。

以前の僕なら、そのまま
「実装してください」
でした。
でも最近は、そこで一度止まります。
実装前に確認するのは、

① どのファイルを変える？
② なぜそこを変える？
③ 必須の変更だけ？
④ 既存機能への影響は？
⑤ もっと小さく実装できない？

この5つ。

仕様が決まっていても、
実際のコードでは想定より変更範囲が大きいことがある。
だから最近よく使うのが、
「まだ変更しないでください。まず調査してください。」
という一文。
AIが速く実装できるからこそ、
実装前に一度止まって確認する。

これだけで、かなり安心してClaude Codeを使えるようになりました。

今日のnoteでは、仕様を渡したあとに僕が確認している5つをまとめました👇
https://t.co/uvoIsxvc8c

[こえけん @koeken_dev]

ハックさん、ありがとうございます！

「時刻を体感で書かせない」は盲点でした…！
作業ログに6時間未来の時刻は、あとから見るとかなり混乱しそうですね😂
dateコマンドで実際の時刻を取得してから記録させる、というのはすごく分かりやすいです。
SecretCRMの開発でもログや日時を扱う場面があるので、僕も意識してみます！

[こえけん @koeken_dev]

ChatGPTとClaude Code、最初は正直かなり同じように使ってました。

でも今は、少し役割を分けています。

ChatGPT
・何が問題か整理する
・選択肢を出す
・比較する
・仕様を考える

Claude Code
・今のコードを調べる
・変更箇所を確認する
・実装する
・テストする
・バグを直す

僕の中では、
ChatGPT＝相談役
Claude Code＝実装担当
に近いです。

流れも、
ChatGPTで考える
↓
自分で決める
↓
Claude Codeで作る
↓
自分で確認する

が増えてきました。

「どっちのAIが優秀？」より、
どこで使うと一番仕事が進むか。
そこを考える方が大事だと思ってます。

今日のnoteでは、僕なりのChatGPTとClaude Codeの使い分けを書きました👇
https://t.co/kGmomt8LbL

[こえけん @koeken_dev]

Claude Codeに渡す仕様って、
細かく書けば書くほど良いと思ってました。
でも最近は、少し違うと思ってます。

人間が決めるのは、

・何のために作る？
・ユーザーにどう使ってほしい？
・今回はどこまでやる？
・何は変更しない？
・何ができたら完成？

ここまで。
逆に、
・どのファイルを変える？
・どう実装する？
・どの関数を使う？
・どう既存コードを再利用する？
この辺はClaude Codeに任せる。
つまり、

「何を作るか」は人間。
「どう作るか」はAI。

仕様は長さより、
人間が決める部分とAIに任せる部分が分かれているかの方が大事だと感じてます。

今日のnoteでは、Claude Codeに渡す仕様をどこまで細かく書くかについてまとめました👇
https://t.co/6wJPw0HeBx

[こえけん @koeken_dev]

最近は、思いついた機能をそのままClaude Codeに投げないようにしてます。

先にChatGPTで、

・何のために作る？
・今回はどこまでやる？
・何はやらない？
・何ができたら完成？

を整理する。
そのあと、Claude Codeに渡す。

つまり、

ChatGPTで考える
↓
仕様にする
↓
Claude Codeで実装する

という流れ。

以前は、

「検索機能つけて」
だけで頼んでました。

でも今は、
やることだけじゃなく、“やらないこと”まで決めてから渡す。

このひと手間で、想定外の変更や「そうじゃなかった」がかなり減りました。

AI開発って、上手いプロンプト一発で完成させるより、
実装前にどこまで整理できるかの方が大事なのかもしれません。

今日のnoteでは、ChatGPTからClaude Codeへ渡す前に僕がやっている「実装前の整理」をまとめました👇
https://t.co/0pgNPj9m3n

[こえけん @koeken_dev]

最近、分からないことがあるとすぐChatGPTに聞く癖がついてました。

でもAIに聞く前に、
5分だけ自分で考えるようにしています。

・今の問題は何？
・自分ならどうしたい？
・何を優先する？
・その理由は？

ここまで考えてからAIに聞く。

すると、
「答えをもらう」より
自分の考えを検証してもらう感じになる。
AIは何でも答えてくれる。

だからこそ、

自分はどうしたいのか

を先に持つことが大事なんだと思ってます。

今日のnoteでは、あえてAIにすぐ聞かない理由を書きました👇
https://t.co/wSThTK8fcW

[こえけん @koeken_dev]

Claude Codeに任せられることが増えるほど、
人間の仕事は減ると思ってました。

でも実際は逆でした。

コードを書く。
エラーを直す。
テストをする。

このへんはAIにかなり任せられる。
その代わり増えたのが、

・何を作る？
・今やるべき？
・どれを優先する？
・どこまで作る？
・何を作らない？

という「決める仕事」。

AIは「できます」とたくさん提案してくれる。

でも、
作れることと、作るべきことは別。

最近はClaude Codeに任せるほど、
人間側の「選ぶ・捨てる・止める」が重要だと感じてます。

今日のnoteでは、AI開発で人間の役割がどう変わったかを書きました👇
https://t.co/1MSD8AwTtE

[こえけん @koeken_dev]

「テスト」って、最初はエンジニア向けの難しいものだと思ってました。

でもClaude Codeを使っていて、少しずつ理解が変わってきた。

今の僕の感覚では、

テスト＝「前にできていたことが、今もできるか自動で確認する仕組み」

です。

例えば、

・顧客を登録できる
・予約を保存できる
・過去に直したバグが再発していない

これを変更のたびに自動で確認してもらう。
全部のテストコードを自分で書けなくても、

「何が壊れたら困るか」は非エンジニアでも決められる。

そこをClaude Codeに伝えて、テストを書いてもらう。

AIで作るだけじゃなく、
AIと一緒に“壊れにくくする”こともできるんだなと最近感じています。

今日のnoteでは、非エンジニアの僕が「テスト」をどう理解してきたかを書きました👇
https://t.co/pJiX5JI4aC

[こえけん @koeken_dev]

Claude Codeがバグを直してくれた。

動作確認もOK。

でも最近は、そこで終わらないようにしてます。

修正後に聞くのは、

① 根本原因は何だった？
② どのファイル・処理が原因？
③ なぜこの不具合が起きた？
④ 他にも同じ問題が起きそう？
⑤ 再発を検知するテストは追加できる？

この5つ。

「直った」だけだと、また同じことが起きたときに最初からになる。

でも原因まで聞いておけば、
少しずつ自分にも知識が残る。

さらにテストやチェック項目に残せれば、
次はもっと早く気づける。

AIに直してもらうだけじゃなく、
1回のバグを次の開発に活かす。

これもAI開発で大事だと感じてます。

今日のnoteでは、バグ修正後にClaude Codeへ聞いていることをまとめました👇
https://t.co/xA2wSgGMI1

[こえけん @koeken_dev]

Claude Codeにバグ修正を頼むとき、

「動かないので直してください」だけでは情報が足りない。

最近は最低でも、

① 何をしたか
② 実際に何が起きたか
③ 本来どうなってほしいか
この3つをセットで伝えるようにしてます。
例えば、

「保存できない」

ではなく、

「顧客編集画面で名前を変更して保存した。完了表示は出るけど一覧では変更前のまま。本来は保存後すぐ反映されてほしい」

まで書く。

自分で原因が分からなくても大丈夫。

原因を決めつけるより、“症状”を正確に伝える。

非エンジニアでも、これはできる。

AI開発ではコードを書く力だけじゃなく、
問題を言葉にする力もかなり重要だと感じてます。

今日のnoteでは、僕がClaude Codeにバグを伝えるときの書き方をまとめました👇
https://t.co/p3AQWgkcdk

[こえけん @koeken_dev]

Claude Codeに
「ここだけ直して」と頼んだのに、
想定以上にファイルが変わってる。

そんなとき最近は、
すぐ「元に戻して」とは言わないようにしてます。

まず、

・どのファイルを変えた？
・なぜ変更した？
・本当に必要な変更？
・ついでに変えた部分はある？
・既存機能への影響は？
を確認する。

頼んでない変更＝間違い、とは限らない。
でも、理由が分からないまま進めない。

Claude Codeを使うほど、
「作らせる力」だけじゃなく
一度止めて確認する力も大事だと感じています。

想定以上に変更されたときの確認手順を、今日のnoteにまとめました👇
https://t.co/ral1r9NvD8

[こえけん @koeken_dev]

Claude Codeが便利だからこそ、
「全部まとめて直して」はなるべく言わないようにしてます。

5個まとめて変更して壊れると、
どの修正が原因なのか分からなくなる。

だから最近は、

修正を1つ頼む
↓
自分で確認する
↓
問題なければcommit
↓
次の修正へ

という進め方。

さらにClaude Codeには、
「今回の目的に必要な箇所以外は変更しないでください」
と伝えることが増えました。

AI開発は一気に進めるより、
小さく任せて、小さく確認する方が結果的に速いと感じています。

Claude Codeに修正を1つずつ頼むようになった理由を、今日のnoteにまとめました👇
https://t.co/J38ZRC0hGF

[こえけん @koeken_dev]

ユーザーテストって、もっと大がかりなものだと思ってた。
でも今のSecretCRMなら、まず30分で十分かもしれない。

0〜5分：最初の操作を見る
5〜15分：基本タスク
15〜20分：少し困る操作
20〜25分：自由に触ってもらう
25〜30分：感想を聞く

見たいのは、
「使えたか」だけじゃなくて、

・どこで止まった？
・どこで迷った？
・何が分かりにくかった？
・明日も使いたいと思った？

という部分。

作った本人には見えない問題を、30分で見つける。
まず1人から試してみたい。

SecretCRMの30分ユーザーテスト手順をnoteにまとめました👇
https://t.co/tWyTlkgoKZ

[こえけん @koeken_dev]

SaaSって、機能の多さより
最初の5分で「使えそう」と思ってもらえるかがかなり大事かもしれない。

SecretCRMでも最初から全部説明するんじゃなくて、

顧客を1人登録する
↓
すぐ検索できる
↓
情報や履歴がまとまって見える
↓
「これなら楽かも」と感じてもらう

まずこの小さな成功体験を作りたい。

「すごい機能があります」より、
「明日も使いたい」につながる最初の5分。

今はそこをかなり大事にしたいと思ってます。

SecretCRMの初回体験をどう作るか、今日のnoteにまとめました👇
https://t.co/sjbbQrAvEs

[こえけん @koeken_dev]

SaaSって、契約してもらった瞬間がゴールじゃない。
むしろ本当に難しいのは、その翌月だと思う。

1ヶ月目は
「面白そう」「試してみたい」で使ってもらえるかもしれない。

でも2ヶ月目は、
「今月もお金を払う価値がある？」
が問われる。

SecretCRMで目指したいのも、
「契約されたサービス」じゃなくて
「毎月使い続けてもらえるサービス」。

最初の1円より、
2ヶ月目の1円の方が難しい。

「契約したのに使われない」をどう防ぐか、今日のnoteに書きました👇
https://t.co/fuQvYOJT8q

[こえけん @koeken_dev]

SecretCRMを月500円にするか、1,000円にするか、3,000円にするか。

考えていて気づいたのは、
「何時間かけて作ったか」は価格の理由にならないということ。

100時間かけた機能でも使われなければ価値は低い。
逆にClaude Codeが30分で作った機能でも、
毎月5時間の作業を減らせるなら価値は大きい。

だから価格は、
作る大変さではなく、使う人にどれだけ価値を返せるか。

そして本当に見たいのは、
「契約してくれるか」より
2ヶ月目も払って使い続けてくれるか。

月500円・1,000円・3,000円をどう考えるか、今日のnoteにまとめました👇
https://t.co/DlZgsJvfaB

[こえけん @koeken_dev]

無料で使ってもらえることと、
お金を払って使ってもらえることは、やっぱり別物。

SecretCRMも最初は無料でテストしてもらうつもりです。

でも、ずっと無料では「商品として価値があるか」は分からない。

僕が有料化の目安にしたいのは、
「便利だった」ではなく「なくなると困る」状態。

そのタイミングで初めて、
「来月から有料でも使いたい？」を聞いてみる。

0円→最初の1円。

金額以上に、この差は大きいと思っています。

無料テストからいつ有料にするか、SecretCRMで「最初の1円」をもらうタイミングをnoteに書きました👇
https://t.co/QDYx42yj3L

[こえけん @koeken_dev]

ユーザーテストで一番聞きたいのは、
「どうでした？」じゃない。

僕が知りたいのは、

・どこで迷った？
・何が面倒だった？
・どの機能を使わなかった？
・今までより何が楽になった？
・明日も使いたいと思った？

という実際の行動。
「使いやすかったです」は嬉しい。

でも、サービス改善のヒントになるのは
“どこで困ったか”の方。

SecretCRMも、これからは作るだけじゃなく
使ってもらって学ぶ段階に進めたい。

SecretCRMのテストで聞きたい10の質問をnoteにまとめました👇
https://t.co/0miVeHdPzh