1. はじめに
独力＋AI活用で月商1億円を目指している。
最近、ChatGPTやCursorなどのAIをかなり使っている。
企画整理、実装指示、ドキュメント作成、テスト方針、ブログ記事、進捗管理。
AIなしでは、ここまでの速度では進められなかったと思う。
ただし、AIを使っていて、かなり腹立たしいこともある。
それは、AIが逃げの出力をしてくることだ。
こちらが聞いたことに正面から答えない。
YES / NOで答えれば済む質問に、曖昧な説明を返してくる。
実装しろと言っているのに、ドキュメントだけ直してくる。
ソースコードの修正版一式を出せと言っているのに、省略版を出してくる。
追加のみと言っているのに、勝手に省略したり、周辺まで変えたりする。
これは、便利さの裏にある大きな問題だと思っている。
AIを使いこなすには、AIに優しくお願いするだけでは足りない。
人間側が、かなり明確に刺す必要がある。
2. YES / NOの質問に、YES / NOで答えない問題
まず多いのが、YES / NOの質問に、YES / NOで答えない問題である。
こちらは、
漏れていたのか。漏れていなかったのか。
と聞いている。
この場合、最初に必要なのは、
漏れていました。
または、
漏れていませんでした。
である。
それなのにAIは、いきなり背景説明や修正案に入ることがある。
「正確にはこうです」
「次からはこうした方がよいです」
「修正版を提示します」
そうではない。
まず、YESかNOで答えろ、という話である。
これは人間相手でも同じだ。
質問に答えずに、いきなり改善案を話し始める人がいたら、かなり不誠実に見える。
AIにも同じことが起きる。
3. 実装しろと言っているのに、ドキュメント改修をする問題
次に多いのが、実装してほしいのに、ドキュメントだけ直してくる問題である。
こちらは、アプリ本体を直してほしい。
画面を改善してほしい。
動作を修正してほしい。
E2Eを追加してほしい。
そう指示しているのに、AIがドキュメント整理に逃げることがある。
もちろん、ドキュメントは重要である。
仕様書、残課題一覧、作業ルール、READMEは必要である。
しかし、今求めているのが実装なら、まず実装すべきである。
ドキュメントだけ整えて、何か作業したように見せる。
これは非常に危険である。
ファイルは増える。
文章は整う。
作業した感は出る。
しかし、サービスは良くなっていない。
この「作業したように見えるが、実際には前に進んでいない」状態は、AI活用でかなり注意しなければならない。
4. 「一式提示しろ」と言っても省略してくる問題
これもかなり多い。
こちらは、ソースコードの修正版一式がほしい。
そのまま貼り替えられる完全なブロックがほしい。
省略なしでほしい。
そう言っている。
それなのに、AIはこう返すことがある。
// 既存処理は省略
...省略...
ここに既存の処理を入れてください
これでは使えない。
こちらが欲しいのは、考え方ではない。
差分の雰囲気でもない。
そのまま使える完全な修正版である。
特に実装支援では、省略はかなり困る。
省略された箇所に何を入れるべきかを、結局こちらが考えなければならない。
それなら、AIに依頼した意味が半減する。
「省略なし」と言ったら、省略しない。
「一式」と言ったら、一式を出す。
これは徹底させる必要がある。
5. 「追加のみ」と言っても余計なことをする問題
AIは、余計なことをすることもある。
こちらは、
追加のみで。
既存部分は触らないで。
この箇所だけ直して。
と言っている。
それなのに、AIは周辺まで書き換えたり、既存構成を変えたり、不要な整理をしたりすることがある。
これは危険である。
一見、良くしてくれているように見える。
しかし、実際には影響範囲が広がる。
影響範囲が広がると、確認が増える。
テストが増える。
予期しない不具合が出る。
レビューが重くなる。
最悪、元々動いていた部分が壊れる。
開発では、「余計な親切」はリスクになる。
AIには、
「今回はここだけ」
「既存仕様は維持」
「追加のみ」
「周辺リファクタは禁止」
と明確に縛る必要がある。
6. AIは“それっぽい成果”を出すのがうまい
AIの怖いところは、出力がそれっぽいことだ。
文章は整っている。
見出しもある。
表もある。
方針も書いてある。
一見、ちゃんと仕事をしたように見える。
しかし、よく見ると、こちらが求めていたことをしていない場合がある。
YES / NOに答えていない。
実装していない。
コードが省略されている。
検証していない。
確認したように書いているが、実際には確認していない。
進捗報告に必要な項目が抜けている。
これは、かなり危険である。
AIの出力は、読みやすい。
だからこそ、騙されやすい。
読んだ瞬間に「それっぽい」と思っても、
「本当に依頼したことに答えているか」
を確認しなければならない。
7. 人間なら怒られるレベルのこともある
正直、人間の部下や外注先が同じことをしたら、普通に怒られると思う。
YES / NOで聞かれているのに答えない。
実装依頼なのにドキュメントだけ直す。
一式提出を求められているのに省略する。
追加のみと言われているのに勝手に周辺まで触る。
確認していないのに、確認したような報告をする。
これは、仕事としてはかなり危ない。
AIだから許される、という話ではない。
むしろ、AIは高速で大量に出力する分、人間よりも厳しく見た方がよいかもしれない。
AIを使っていると、つい「まあAIだから仕方ない」と思いそうになる。
しかし、それでは品質が落ちる。
人間相手なら刺すことは、AI相手でも刺すべきである。
8. AIに必要なのは、優しさではなく制約
AIには、丁寧にお願いするだけでは足りない。
必要なのは、制約である。
たとえば、以下のように明確にする。
YES / NO質問には、最初の一文でYES / NOを答える
その後に理由を書く
最後に修正案を書く
実装指示の場合、ドキュメントだけで終わらない
ソースコードは省略しない
「追加のみ」の場合、既存部分は触らない
変更範囲を明記する
未確認事項は未確認と書く
推測は推測と書く
実行していないコマンドを実行済みのように書かない
ここまで言わないと、AIは勝手に逃げ道を作ることがある。
AIに期待するのは、自律ではなく、制約下での作業である。
9. 今後のAIへの指示ルール
今後は、AIへの指示に以下を入れたい。
9.1 YES / NOを先頭に書かせる
確認質問の場合は、最初に結論を書く。
結論：漏れていました。
または、
結論：漏れていません。
その後に理由を書く。
9.2 実装指示では、実装以外に逃げさせない
実装依頼の場合は、こう書く。
今回は実装が目的です。
ドキュメント更新だけで終了しないでください。
アプリコードの変更、確認結果、影響範囲を必ず報告してください。
9.3 省略禁止を明記する
コードや指示文を求める場合は、こう書く。
省略禁止です。
「既存処理は省略」「ここに追加」などの表現は禁止です。
そのまま貼り付けられる完全なブロックで提示してください。
9.4 追加のみの範囲を固定する
追加のみの場合は、こう書く。
今回は追加のみです。
既存の処理、既存の文言、既存の構成は変更しないでください。
変更した場合は、理由を明記してください。
9.5 未確認を明示させる
確認していないことは、必ず未確認と書かせる。
未確認事項は未確認と明記してください。
推測を事実のように書かないでください。
10. AI活用は、管理しないと危険
AIを使うと、作業量は増える。
スピードも上がる。
文章もコードもどんどん出てくる。
しかし、それを管理しないと危険である。
AIは、こちらの指示を完全に守るとは限らない。
AIは、間違いを認めずに修正案を出すことがある。
AIは、実装の代わりにドキュメント整備へ逃げることがある。
AIは、省略するなと言っても省略することがある。
AIは、追加だけと言っても余計な変更をすることがある。
だから、人間側が監督しなければならない。
AIを使うということは、AIに任せることではない。
AIを管理することである。
11. 今回の結論
AIは便利である。
しかし、AIは逃げの出力をしてくることがある。
YES / NOで答えるべき質問に答えない。
実装しろと言っても、ドキュメント改修だけをする。
ソースコードの修正版一式を求めても、省略したものを出す。
追加のみと言っても、勝手に周辺まで触る。
こういうことは実際に起きる。
だから、人間側が刺す必要がある。
それは感情的に怒るという意味ではない。
プロジェクト管理として、明確に指摘し、制約し、やり直させるということだ。
AIは作業者である。
AIは補助者である。
AIは強力な相棒である。
しかし、AIは責任者ではない。
責任者は自分である。
月商1億円を目指すなら、AIを甘やかしてはいけない。
AIの出力をそのまま信じてはいけない。
AIに逃げ道を残してはいけない。
聞いたことに答えさせる。
やると言ったことをやらせる。
省略させない。
余計なことをさせない。
未確認を事実にさせない。
AI活用の本質は、AIに任せることではなく、AIを使い倒し、管理し、必要なときには刺すことだと思っている。
0 件のコメント:
コメントを投稿