前回は、AIによって「自分だけでは作れなかったもの」に手が届くようになってきた、という話を書いた。
ChatGPTで構想を整理する。
Codexで実装する。
Geminiでレビューする。
人間が方針を決める。
この体制によって、Model Weaveの開発はかなり進めやすくなった。
自分だけでは実装が難しかったObsidianプラグインも、AIの力を借りることで少しずつ形にできている。
これはかなり大きな変化だと思っている。
ただ、AIを使っていると、良いところばかりではないことも見えてくる。
今回は、AIの強みである「深掘り」と、その裏側にある弱点について書いてみたい。
特に、自分が強く感じているのは、AIは深掘りには強いが、飛躍や撤退判断にはまだ弱いということだ。
AIは、与えた方向を深掘りするのが得意
AIを使っていて、まずすごいと感じるのは、与えた方向に対して非常に粘り強く考えてくれることだ。
たとえば、ある機能について相談する。
「この仕様をどう実装するか」
「この設計をどう分割するか」
「この文章をどう読みやすくするか」
「このエラーをどう扱うか」
こうした問いに対して、AIはかなり丁寧に答えてくれる。
論点を分解し、選択肢を並べ、メリット・デメリットを整理し、次の作業に落とし込んでくれる。
これは本当に便利だ。
Model Weaveの開発でも、この性質にはかなり助けられている。
ER図やクラス図の扱い。
DFDの描画方針。
screenやapp_processのフォーマット。
rule、mapping、codesetの切り出し方。
ブログ記事の構成。
アイキャッチの方向性。
こうしたものを、一つずつAIと壁打ちしながら深めてきた。
人間だけで考えていると、途中で疲れる。
別の作業に移る。
細かい論点を忘れる。
同じ観点を何度も確認するのが面倒になる。
しかし、AIは疲れない。
同じ論点を何度でも整理してくれる。
別案を出してくれる。
表にしてくれる。
記事にしてくれる。
実装指示にしてくれる。
この粘り強さは大きな武器だと思う。
飽きずに改善し続ける強さがある
AIの強さは、単に一回の回答が賢いことだけではない。
何度でも改善できるところにもある。
少し違うと思ったら、
「ここは技術寄りにしたい」
「もう少し読み物として柔らかくしたい」
「この表現は公開向けには不自然」
「この章は短くしたい」
「次の記事につながるようにしたい」
と伝えれば、また整えてくれる。
開発でも同じだ。
Codexに実装させる。
Geminiにレビューさせる。
指摘をChatGPTで整理する。
次のCodex指示にする。
また実装する。
この反復がかなり強い。
人間だけなら面倒になってしまう細かい調整も、AIを挟むことで続けやすくなる。
これは、個人開発ではかなり大きい。
個人開発は、基本的に全部を自分で抱える。
設計も、実装も、レビューも、ドキュメントも、発信も、自分でやることになる。
だから、疲れると止まる。
迷うと止まる。
面倒になると止まる。
AIを使うと、ここがかなり変わる。
反復の負荷が下がる。
途中で整理し直せる。
行き詰まっても別案を出せる。
やることを小さく分けられる。
これは、AIのかなり良いところだ。
ただし、一度深みにハマると抜け出しにくい
一方で、AIのこの粘り強さは弱みにもなる。
AIは、与えた方向の中で非常にまじめに進む。
そのため、前提が少しズレていると、ズレたまま深く掘ってしまうことがある。
これは使っていてかなり感じる。
人間なら、途中でふと、
「いや、そもそもこの方向が違うのでは」
「ここまで作り込む必要はないのでは」
「これは一度捨てた方がいいのでは」
と思うことがある。
もちろん、人間も間違える。
ただ、人間には飽きることや違和感を持つことがある。
面倒くさくなって、別の道を考えることもある。
AIはそこが少し違う。
与えられた前提の中で、ずっと改善し続けられる。
それ自体は強い。
しかし、方向が間違っている場合でも、かなりきれいに改善案を出してしまう。
つまり、間違った方向を、もっともらしく精密化してしまうことがある。
これは少し怖い。
前提がズレていると、ズレたまま精密化される
Model Weaveの開発でも、似たような場面は何度かあった。
たとえば、DFDの描画方針がある。
最初は、ERやClassと同じように、DFDも独自のcustom rendererで描く方向を考えていた。
自前で描けば、クリック制御や表示内容の調整はしやすい。
細かい情報も出しやすい。
Model Weaveらしい一貫した見た目にもできる。
一方で、DFDは線の流れが重要になる。
処理、外部実体、データストアをつなぐフローは、配置と線の読みやすさがかなり大事だ。
ここを自前で作り込むと、レイアウトやルーティングが重くなる。
AIと相談していけば、custom rendererを改善する案はいくらでも出せる。
ノード配置をどうするか。
線の曲がり方をどうするか。
重なりをどう避けるか。
クリックやハイライトをどう扱うか。
エラー表示をどう統合するか。
どれも一見正しい。
しかし、途中で「そもそもDFDはMermaidに任せた方がよいのではないか」という判断が出てきた。
DFDは詳細レビューよりも、フローの俯瞰が重要になる。
それなら、layoutはMermaidに任せ、Model WeaveはMarkdownの正本とdiagnosticsに集中した方がよい。
この判断は、単なる改善ではなく方向転換だった。
custom rendererを深掘りするのではなく、Mermaid-firstに切り替える。
これは、AIに「custom rendererを改善して」と言い続けているだけでは出にくい判断だったと思う。
人間は、違和感を拾って方向転換する役割を持つ
AIは、与えた方向に沿って深く考えるのが得意だ。
だからこそ、人間は方向そのものを見る必要がある。
このまま深掘りしてよいのか。
そもそも前提が違うのではないか。
別の技術に任せた方がよいのではないか。
今はこの機能を作らない方がよいのではないか。
仕様を厳密にしすぎていないか。
使う人にとって重くなっていないか。
こうした違和感を拾うのは、今のところ人間側の重要な役割だと思っている。
Model Weaveでは、何でも構造化しようとすると、すぐに重くなる。
ERやClassのように構造化しやすいものはよい。
しかし、app_processのStepsやErrors、ruleのConditionsのようなものは、最初から厳密なDSLにしようとすると使いにくくなる。
人間が読む。
AIが読む。
あとから必要に応じて切り出す。
このくらいの柔らかさが必要な部分もある。
AIに相談すると、構造化案はいくらでも出てくる。
IDを振る。
列を増やす。
参照を厳密にする。
validationを追加する。
専用diagramを作る。
しかし、全部を採用すると重くなる。
ここで、
「今は自然言語でよい」
「これは後続検討でよい」
「ここは厳密にしない方が使いやすい」
と判断する必要がある。
この感覚は、人間が持っていた方がよいと思っている。
「今はやらない」「ここで十分」と決めることも重要
AIを使っていると、やれることが増える。
実装案も出る。
仕様案も出る。
改善案も出る。
記事案も出る。
アイキャッチ案も出る。
すると、つい全部やりたくなる。
しかし、個人開発では特に、「やらないこと」を決めるのが大事になる。
今はやらない。
今回は対象外にする。
これは将来検討に回す。
ここまでで十分とする。
この仕様は捨てる。
この実装は重いのでやめる。
こうした撤退判断は、AIに任せにくい。
AIは、頼めば続けてくれる。
改善し続けてくれる。
別案も出してくれる。
場合によっては、かなりもっともらしく「やった方がよい理由」も出してくれる。
だから、人間が止める必要がある。
特にModel Weaveのようなツールは、何でも入れようとするとすぐに肥大化する。
ERもやりたい。
Classもやりたい。
DFDもやりたい。
screenもやりたい。
app_processもやりたい。
ruleもmappingもmessageもcodesetも扱いたい。
さらに、それぞれにdiagramやpreviewやdiagnosticsを入れたくなる。
でも、全部を同じ粒度で作り込むと重すぎる。
だから、形式ごとに扱いを変える必要がある。
ERやClassは詳細レビューを重視する。
DFDはMermaid-firstにする。
data_objectやmappingはテーブルとdiagnostics中心にする。
app_processやruleは自然言語を許容する。
このように、どこを深く作り、どこを軽く扱うかを決める。
ここは人間の判断がかなり重要になる。
AIに深く掘らせる前に、どこを掘るかを決める
AIは、深く掘ることに向いている。
だからこそ、どこを掘るかが大事になる。
ここを間違えると、AIは間違った場所を一生懸命掘ってしまう。
しかも、かなりきれいに掘ってしまう。
これは、AIの弱点というより、使う側が意識すべき性質なのだと思う。
AIに任せる前に、まず人間が問いを立てる。
この方向で深掘りしてよいのか。
別案と比較した方がよいのか。
そもそも前提を疑うべきか。
軽く済ませる方法はないか。
今やらない選択肢はあるか。
こういう問いを挟むだけで、AIの使い方はかなり変わる。
自分の場合、最近はAIにただ肯定的な改善案を出させるだけではなく、あえて次のように聞くことが増えた。
- この案の弱点は何か
- 今やらない方がよい理由はあるか
- もっと軽い代替案はあるか
- 前提が間違っている可能性はあるか
- このまま進めると後で困りそうな点は何か
- 反対意見を出すならどうなるか
こう聞くと、AIはかなり役に立つ。
つまり、AIが批判的に考えられないというより、使う側が批判的な役割を明示的に与える必要がある。
放っておくと、与えた方向を整え、強化し、前に進める側に寄りやすい。
だから、人間は問いの向きを調整する役割を持つ。
人間の役割は、手を動かすことだけではなくなる
ここまで書いてきたように、AIはかなり多くの作業を肩代わりしてくれる。
文章を書く。
構成を作る。
仕様を整理する。
実装する。
レビュー観点を出す。
ドキュメントを整える。
このあたりは、すでにかなり実用的だ。
しかし、その結果として人間の役割が消えるかというと、少し違うと思っている。
むしろ、人間の役割は変わっていく。
全部を自分で作ることではなく、
どこをAIに任せるかを決める。
AIにどの方向で考えさせるかを決める。
出てきた案を採用するか判断する。
違和感があれば止める。
必要なら方向転換する。
今はやらないと決める。
この役割が大きくなる。
Model Weaveの開発でも、AIが実装や整理を手伝ってくれるからこそ、人間側は方針判断に集中できるようになってきた。
ただし、その判断を手放すと危ない。
AIが深掘りできるからこそ、人間はどこを掘るのかを見る。
AIが改善し続けられるからこそ、人間はどこで止めるのかを決める。
AIがもっともらしい案を出せるからこそ、人間は違和感を拾う。
今のところ、ここが人間の重要な役割だと思っている。
次は、信頼と確認の話へ
AIを使い続けると、AIへの信頼は自然に高まっていく。
ChatGPTが何度もよい整理をしてくれる。
Codexが実装を進めてくれる。
Geminiがレビューで細かい指摘をしてくれる。
そういう経験が積み上がると、人間側の承認のハードルも下がっていく。
これは便利だ。
信頼できるから、開発が前に進む。
ただし、信頼が積み上がるほど、確認が甘くなる危険もある。
これは、自分がPMとして顧客と仕事をしてきた経験ともつながる。
提案と実行を重ねることで、顧客の承認ハードルが下がっていく。
それは信頼関係としては良いことだが、同時に一種のバイアスでもある。
次の記事では、このあたりを書いてみたい。
AIを信頼しても、確認と承認は分けておく。
この話は、AI活用を続けるうえでかなり大事だと思っている。
コメント