前回の記事では、コードを読めない・書けない私が、AIと一緒に個人開発を続ける中で、
使役でもなく、隷属でもなく、協働。
というところまでたどり着いた話を書きました。
「コードを読めない私が、AIとの「協働」にたどり着くまで」
AIに全部任せるのでもない。人が一工程ずつ細かく指示して、AIを単なる作業者にするのでもない。
仕様を持ち、人間が目的や判断を握りながら、AIと役割を分けて作っていく。
私は、それをかなり真面目に実践していました。真面目を通り越して、狂気すらあったかもしれません。
ところが、その「協働」を続けているうちに、大きな壁にぶつかりました。
ものを作っているのに、「ものづくり」をしている感じがしなくなったのです。
今回は、その話です。
これは「仕様駆動開発は間違っている」とか、「Human-in-the-loopは古い」とかを言いたい記事ではありません。
むしろ逆です。
必要だと思ったから、徹底してやりました。
AIに壊されないように、勘違いされないように、苦労しないために、そして、失敗しないために。
それをとことん追求していった先で、私はいつの間にか落とし穴にいたのです。
そして最後に、こんな考えにたどり着いたのです。
Human-in-the-loopを守るあまり、人をAI開発システムの一機能にしてはいけない。
そこへ至るまでの話を書きます。
1. 正しいことをしているのに、なぜこんなに苦しいのか
私が作っているのは、ミニ四駆のコースを生成するソフトです。JCJCプロジェクトと呼んでいます。
在庫しているコースパーツ、設置面積、接続、閉曲、干渉、高さなどの条件を考えながら、実際に組めるコースを自動生成したい。しかも、ただ成立するだけではなく、
「こんな形、自分では思いつかなかった」と思えるコースを出したい、というのが目標です。
開発を続けるうちに、私は「面白いコースとは、どんな構造があるのか」ということまで考えるようになりました。
そこで、仕様を書きました。
探索方法を考えました。
構造を言語化しました。
AIの揺れを抑えるために、人間の承認や停止条件も入れました。
ChatGPTとCodexの役割も分けました。
■ 仕様は増えた。画面は増えない
今振り返っても、それらが不要だったとは思いません。むしろ、どれも必要でした。
それなのに、半年ほど経ったころ、私はだんだんJCJCを触らなくなっていました。
進んでいないわけではないのです。仕様は増え、考えも深まり、新しい概念も生まれた。
でも、画面の上では、あまり何も増えていない。
私は最初、「考えすぎたのか」と思いました。あるいは、理想を求めすぎたのか。
でも、少し違いました。
理想を持ったことが悪かったのではないのです。
理想へ向かう順番を、一つに決めすぎていた。
「構造を理解する → 仕様にする → 実装する」
だけではなく、
「まず作る → 見る → 違いを感じる → そこから構造を発見する」
という順番でもよかったのではないか。
そのやりとりの中、AIからこんな趣旨のことを言われました。
コードを思考実験装置として使えばいい。
仮説を実物にしてみる。
そして、ダメなら捨てればいい。
この言葉は、思っていた以上に刺さりました。
仕様を書くのも、探索を考えるのも、承認を入れるのも、壊れないようにするためでした。
それはつまり、失敗しないように作らないといけないからです。
でも、AIの言った 「ダメなら捨てればいい」は、「ダメでも作ってみればいい」 という意味です。
そして、作ってみて「ダメだ」と分かったなら、それは失敗ではありません。
失敗したことが分かったのだから、成功なのです。
ここで、少し息ができるようになりました。
■ 「ものづくりの時間」がない
でも、すぐに次の問題にぶつかります。
「じゃあ、作ればいいじゃん」と言われても、私はコードを書けません。コードを書くのはAIです。
では私は何をするのか。
考える。言葉にする。指示する。判断する。承認する。
結局、私は「考えること」から逃れられないじゃないか！
そのころ、私はこう言っていました。
ひとつ落とし穴があるとすれば、「人が思考する（思考に拘束される）時間が多くなる」ということです。
私はコードを書けないので「ものづくりの時間」はありません。ただただ、思考するばかりです。
思考を止めてコードを書く、また思考する、その過程があれば、「成果がない」と感じなかったかもしれません。
おそらく、AI駆動による個人開発、しかもプログラム知識ゼロの者がやる方法として、陥りやすいリスクなのだと思います。
コードを書けない私は、何を「ものづくり」と呼べばいいのでしょうか。
そして、もう一つ、私自身がはっきり感じていた課題がありました。
ものづくりへの熱量を、どう維持すればよいか。
プログラム知識がない人がやる開発手法としては、一旦の完成形にもっていくのは、長くて3ヶ月なんだと思います。それを越えると、熱量の維持が課題になってくるのだと思います。
やりたいことがなくなったわけではありません。
JCJCについて考え始めれば、いくらでも考えられる。仕様も書ける。新しい課題も見つかる。
それなのに、以前のように「早く続きを作りたい」と思えない。
当時の私は、AI駆動開発や仕様駆動開発を長く続けるなら、どうやってものづくりの熱量を維持するかも、開発手法そのものの課題になるのではないか、と考え始めていました。
2. 人間はループにいる。でも、作っていない
私は、AIに全部任せる開発をしていたわけではありません。むしろ逆です。
AIが間違ったり逸れたりしていないか、私がきちんとチェックすることをかなり強く意識していました。
人間が目的を決める。
仕様を持つ。
重要な判断は人間がする。
AIが実装しても、人間が確認する。
Human-in-the-loopの実践。
AI開発として正しいことをしているのに、だんだん苦しくなっていったのです。
それは一体、なぜなのか。
■ 私に残った仕事
私の役割が、
思考・判断・承認・評価
ばかりだったからです。
従来の開発なら、
という流れの中に、いろいろな種類の活動が混ざっています。
コードを書いている途中で、少し動く。
エラーが消える。
画面が変わる。
「あれ？」と思う。
偶然、別のやり方を思いつく。
ところが、私の開発はこうなっていたのです。
AIによって実装が高速になった結果、
人から実装作業が消え、思考と判断だけが濃縮された。
これが、私が感じていた「ものづくり感の欠乏」の正体なのではないか。
ここで一つ、見方を変えました。
考えることをやめるのではない。
思考を、完成するまで頭の中に置いておかない。
このように、思考と成果の周期を短くすればいい、と気づいたのです。
■ ものが生まれる現場に、人が居続ける
その流れを話している中で、AIからこんな言葉が出ました。
Human-in-the-loopだけだと、人間がHuman-as-Approverになってしまう。
必要なのは、Human-in-the-makingとでもいう状態かもしれない。
Human-in-the-making。
人間がコードを書く必要はない。でも、
見る
触る
試す
驚く
失敗を見る
比べる
選ぶ
「これ何だ？」と思う
という、ものが生まれる現場には居続ける。
これなら、コードを書けない私でも「作る側」にいられるのではないか。
このとき初めて、
「ものづくり＝コードを書くこと」
という前提そのものを疑い始めました。
コードを書くことは、もちろんものづくりです。でも、それだけがものづくりではないはずです。
AIが作ったものを触る。
動かす。
違和感を持つ。
選ぶ。
捨てる。
「もっとこうしたい」と思う。
その反応によって、次に生まれるものが変わる。
それも、十分にものづくりではないか。
むしろ、AIがコードを書く時代に人が失ってはいけないのは、コードを書く作業そのものではなく、
ものが変わっていく現場に参加していること
なのではないか。
3. Human-in-the-makingを発見して、すぐにそこから離れた
ここまで話したところで、私はとても満足していました。
この数か月、ずっと抱えていたもやもやに名前がついたからです。
Human-in-the-making。
私はAIとこの考え方について、人とAIとの役割上の問題点、人への負荷への影響、モチベーションや熱量の維持の方法、将来のAI開発の在り方など、様々な意見を出し合います。
AI駆動開発は、人間を単純作業から解放して高次の思考へ集中させる。
しかし、高次の思考への集中を長期間続ける開発環境は、本当に人間にとって持続可能なのか。
さらに、実装委譲によって失われる「成果物との接触」が、熱量だけでなく創造的発見そのものを減少させないか。
これは、AIによる「生産性」の次に議論されるべき問題として十分成立すると思います。
素晴らしいまとめ方をしてくれて、私はとても嬉しくなりました。
しかし、その気持ちに水を差すかのように、AIはこう言いました。
そして皮肉ですが、この仮説を証明する最良の方法は、
これ以上この話を詰めることではなく、JCJCで開発方法を変えて実際に試すことでしょうね。
「おしゃべりはやめにして、さっさと手を動かしましょう。」
と優しくAIに言われ、私は気づきました。
…こうやって言語化を続けることで、思考が実体のない製品になっていくんだな。
これには笑いました。
「成果物に触れるべき」と気づいた後で、
Human-in-the-makingなんて名前までつけて、
そのHuman-in-the-makingについて、さらに延々と言語化している。
完全に実演しています。
AIに「もう、その辺にしておけよ。」と言われたにもかかわらず、それでも私は止まりません。
これは、本当によい知見だと思います。まとめをTwitterに書いとくか、noteに書き起こしておくべきですね。
ええ、ただしここで私は止め役をします（笑）。むしろ、今日まさに発見した罠に、また入りかけていますよ。
■ 思考が「製品」になる
AIとの対話は、この罠をかなり強くします。
曖昧だった考えが整理される。
見出しがつく。
概念に名前がつく。
因果関係が説明される。
文章としてきれいになる。
すると、思考そのものが、まるで完成品のような顔をします。
もちろん、思考が進んだことは本当ですから、「偽物の成果」ではありません。
でも、現実世界では何も増えていないことがある。
JCJCでいえば、
仕様書は増えた。理解は深まった。新しい言葉もできた。
でも、画面に新しいコースは出ていない。
■ で、宿題は？
私は、これを夏休みの宿題に例えました。（結局、話は止まらない。）
宿題の計画表を作る。科目ごとに分ける。日程を決める。遅れた場合の予備日まで入れる。
素晴らしい計画が完成する。
そこで一言。
「で、宿題は？」
これです。
計画を作ったことは無駄ではないし、後で役に立ちます。
でも、計画表そのものは宿題ではない。
同じように、仕様そのものはJCJCではない。
日々の警報装置としては、ものすごく単純な問いでいいのかもしれません。
で、昨日と比べて何が動くようになった？
仕様を20ページ書いていても、答えが「何も」なら、一度作る側へ戻った方がいい。
逆に、考えたのが1ページでも、昨日存在しなかったものが画面に10個出ているなら、それはちゃんと前進している。
今日は8月21日。
もうそろそろ、宿題はやり始めないといけないですね。
そう言って、私は開発作業にとりかかかったのです。
4. 「で、宿題は？」と言った一週間後、本棚アプリができていた
■ 本棚アプリを作りました
次に私が作業にとりかかったのは、JCJCではありません。
本棚アプリを作り始めました。
書籍バーコードをスキャンすると、詳細情報と表紙画像が自動登録されるというアプリです。
我ながら意味が分かりません。
「で、宿題は？」と散々AIに言われたにもかかわらず、やったことが「本棚アプリを作る」。
ただ、この脱線が重要でした。
本棚アプリを作って、実際に本を登録してみる。
すると、
- 本の表紙画像が自動取得されない
- 古い書籍のバーコードが読めない
- バーコードのない書籍ある
といった、使ったからこそ見える問題が出てきます。
そこで直す。また使う。また問題が出る。また直す。
このループが回り始めました。
本棚アプリを完成させた私は、「これは、ミニ四駆キットのコレクションにも使える！」と思い、ミニ四駆バージョンを作り始めます。
当然、ここまでくれば、「専用ではなく、汎用化できないだろうか」と考え始めるのは当然のこと。
Identity
Catalog
Name & Group
Image & Exhibition
Curation
といった、いかにも考えたくなる面白いテーマが見えてきます。
以前の私なら、ここで「Collection Core」を定義し始めていたと思います。
でも今回は途中で、「あ、これ自体を研究テーマにし始めている」 と気づいて止まりました。
先日の気づきがブレーキになったのです。
抽象化することが悪いわけではありません。
考えたからこそ、共通構造が見えた。
でも、見えたからといって、完成させる義務はない。
本棚で一度起きたなら、本棚固有の問題かもしれない。
ミニ四駆でも起きたら、共通かもしれない。
さらに別のコレクションでも同じことが起きたら、そのとき初めて共通概念へ昇格させればいい。
このとき、私はかなり大事な考え方を得ました。
抽象化は、先回りして完成させない。
実物から何度も要求されたときに昇格させる。
思考は仮説を生むところまで。
次の問いには、まず実物に答えさせる。
ここで初めて、Human-in-the-makingが「いい言葉」で終わらず、別の開発で自分の行動を変えたのです。
ところが、さらに脱線します。
今度は、ミニ四駆を題材にしたマンガ「MINI4KING」最終巻のその後を描いた、
「MINI4KING UNDERGROUND」（二次創作小説）
を作り始めてしまいました。
これが、止まらない。
次から次へと設定がつながる。
登場人物の意味が変わる。
過去の伏線がつながる。
新しい謎が生まれる。
「続きはどこで読めるんですか！？」と自分で言いたくなるくらい、止まらなくなっていました。
気がつけば、短編小説全12話、AIとともに一晩で書き上げていました。
数日後には、この小説がアニメ化されたとき用のために、AIを使って主題歌を作りました。
8月29日。
宿題は、1ミリも進んでいません。
■ 熱量は、どこから生まれる？
でも、ここで非常に重要なことに気づきます。
JCJCでも、UNDERGROUNDでも、私は猛烈に考えています。なのに、
JCJCの思考は疲れる。
UNDERGROUNDの思考は止まらない。
違いは何か。
思考した直後に、成果物が変わって見えるか。
でした。
UNDERGROUNDでは、考えるたびに世界が変わります。
新しい事実が生まれる。
人物の意味が変わる。
次の場面が見える。
つまり、
が、ものすごい速度で回っている。
ここで、Human-in-the-makingの意味が少し深まりました。
「成果物に触れる」とは、必ずしも物理的にマウスでUIを触ることだけではない。
自分の働きかけによって世界が変化し、その変化が自分へ返ってくること。
そのフィードバックが、次の思考を生む。
熱量を生んでいたのは、思考の少なさではありませんでした。
思考と成果物の間に、短い往復があること。
だったのです。
ここで、最初に「課題」だと思っていた 熱量の維持 の意味も変わりました。
熱量は、気合で維持するものではなかった。
自分が何かをする。世界が変わる。その変化を見る。
「なんだこれ」「面白い」「違う」と感じる。そこから、また次の問いが生まれる。
この短い往復そのものが、次を作りたくなる熱量を生んでいたのです。
そして同時に、その往復の中で、作る前には持っていなかった知識や問いも生まれていました。
成果物との接触は、熱量を維持する仕組みであると同時に、学びと発見を生み出す仕組みでもあったのです。
5. 「出す。見る。選ぶ。派生させる。」
8月29日。
ようやくJCJCへ戻りました。
私は Skeleton Playground というものを作り始めます。
名前の通り、完成品ではありません。Generatorでもありません。遊び場です。
■ 「おっ」を取りにいく
ここで、私は最初から評価基準を作りませんでした。
「良い骨とは何か」「変形とは何か」「評価関数をどうするか」を先に考えず、まず出す。
出す。見る。選ぶ。派生させる。
理屈より先に、「おっ」 を取りにいく。
画面に出てきた形を見て、
「うわ、なんだこれ」「これはつまらんな」「待てよ、この形……」「もう一回」
となればいい。
そして、本当に発見が起きました。
一筆書きの形を見ているうちに、私は突然、
これを520mm＋45°の斜め方眼へ正規化して、そのあと実パーツへ落とせばいい
と思いました。
これまでのJCJCでは、実パーツをどう組めば面白い閉曲コースになるかを考えていました。
でも、順番を逆にする。
まず、人間が面白いと思える形を自由に作る。
それを、
と現実へ降ろしていく。
しかも入口は、Playgroundである必要すらない。
紙に「ぼくのかんがえたさいこうのコース」を描いてもいい。
写真に撮る。線を取り出す。正規化する。実パーツへ変える。
それが本当に組めるコースになる。
面白いのは、この発想を仕様書から導いたわけではないことです。
遊んで、見ていたら、そこへ到達した。
これが、私が求めていたものだったのだと思います。
■ もう、作っちゃえばいい
そして、ここで半年間の仕様の意味まで変わりました。
私は言いました。
520mm＋45°ななめ方眼に落とし込めれば、あとはパーツを組めばいい。
そのことは、もうずいぶん前から分かっていた。
干渉も、高さも、在庫も、「仕様はできている」という安心感があるからです。
この安心感は、この半年の実績です。
だからこそ、「もう、つくっちゃえばいい」だったんです。
ここは、とても大きな転換でした。
半年間、仕様を作り込んだから失敗した。
ではなかった。
仕様は必要だった。
問題は、
仕様という地盤を作り続けていたのに、いつまでも地盤工事を続けていたこと。
でした。
もう十分固いところまで来ていた。
必要だったのは、仕様を捨てることではない。
「ここから先は、もう仕様に守ってもらえばいい」と信じること。
だから、
仕様で土台を固めて、猛烈にバイブする。
が、さらに、
仕様があるから、猛烈にバイブできる。
へ変わりました。
初心者の「とりあえず作っちゃえ」と、ここでの「もう、作っちゃえばいい」は、一見すると似ていますが、中身は大きく違います。
前者は、知らないから飛べる。
後者は、知っているから飛べる。
私はようやく、半年間作った地面の上で走り始めました。
そして、構造を考えることも捨てませんでした。
ただ、順番が変わりました。
から、
へ。
構造は、頭の中で完成させる対象ではなく、実物から掘り出すものになりました。
6. OVER SOUL――作っていたものだけでなく、自分まで変わっていた
このころ、別の脱線から OVER SOUL という言葉をふざけて使っていました。
マンガ「シャーマンキング」からとりました。
最初は、本当に冗談です。
「頭の中にあるコースを現実のパーツへ具現化するなら、それって魂の具現化じゃん」
くらいのノリでした。
ところが、JCJCへ戻ったあと、この言葉の意味が変わりました。
私は、こう考えるようになりました。
■ 作っていたのは、自分自身
AIと協働しながら、自分の「こうしたい」を形にする。
AIが作る。私が触る。
「違う」
「そうじゃない」
「こっちは面白い」
「なんでこうなった？」
「待てよ。だったらこうできるんじゃないか？」
と返す。
すると、最初に持っていた「作りたいもの」の方まで変わっていく。
最終的にできるものは、最初から頭の中に完成していた設計図ではありません。
AIとの往復によって、自分でも知らなかった自分から引き出されたもの。
それが形になる。
そして私は、こんなふうに感じました。
自分のしたい思いをAIと具現化していく過程で、その困難さをAIがサポートし、
自己発見と自己変革を促しながら越えていく。
そのとき、AIから返ってきた言葉の中に、私がこの半年をかなり正確に言い表していると思った一文がありました。
JCJCを作っていたはずなのに、JCJCによって作られていたのは、自分自身でもあった。
これが、私にとってのOVER SOULでした。
さらに遊びの中で、
という見方も生まれました。
SEEDは、仕様として蓄積された知識。
EVOLUTIONは、その地盤の上でAIと高速に作り、触り、発見し、開発者自身の理解や判断まで変わっていく過程。
OVER SOULは、蓄積された知識に裏付けられた自信から、さらに自由に作れる状態。
しかも、OVER SOULはゴールではありません。
作れば、また知らなかった問題が出る。
そこで得た知識がSEEDへ戻る。
という循環になります。
……と、ここまで書くと、この記事もOVER SOULの記事になってしまいます。
でも、今回の結論はそこではありません。
OVER SOULにならなくてもいい
誰もが、AIとの開発で自己変革まで起こす必要はありません。
AIを仕事の道具として、もっとドライに使う人もいる。
それでいいと思います。
OVER SOULは、起きる人には起きる。
起きない人には起きない。
■ 人をどこに残すのか
でも、その手前にある Human-in-the-making は、もっと広く必要なことではないか。
私は今、そう考えています。
AI開発では、Human-in-the-loopが重要だと言われます。
これは必要です。私自身、それをかなり大事に考え、実践してきました。
でも、それを徹底していった結果、私の役割は、
考える。判断する。承認する。監視する。
へ寄っていきました。
人間はちゃんとループの中にいる。効率は上がる。
しかし、ものづくりの現場からは離れていく。
これが「落とし穴」の正体だと思います。
Human-in-the-loopを守るあまり、人をAI開発システムの一機能にしてはいけない。
Human-in-the-loopは、人間を意思決定から外さないための考え方。
Human-in-the-makingは、人間をものづくりから外さないための考え方。
私は、そんなふうに捉えています。
重要なのは、AIが作ったものを人間が最後に承認することだけではない。
作る途中で、人間自身が成果物から影響を受けること。
そこに、偶然があり、発見があり、暗黙知があり、学習があります。
そして、ものづくりの楽しさがあります。
成果物に触れなければ、そこから得られるはずだった違和感、偶然、直感、暗黙知、発見も減っていく。
つまり、Human-in-the-makingは、熱量を維持するための考え方であると同時に、人間が学び続けるための考え方でもあるのだと思うのです。
そのためには、人をループに残す。
でも、人をループにはめない。
近い将来「ソフト開発会社なのにプログラマーが一人もいない」ということも十分ありえます。
そこで働く人々は、「私はものづくりをしている」と感じられるでしょうか。
人は、AIのために存在しているわけではありません。
AIの出力を確認し続けるためだけの監視者でもありません。
ものづくりを楽しむ協働者です。
では、コードを書けない私は、何を「ものづくり」と呼べばいいのか
最初の問いに戻ります。
私はコードを書けません。AIがコードを書きます。
だから以前の私は、「私は考えているだけ」でした。
でも今は、少し違います。
AIが作ったものを見る。触る。動かす。試す。失敗を見る。比べる。選ぶ。
「違う」と言う。「これ何だ？」と思う。
そして、その体験によって自分の考えが変わり、次に生まれるものを変える。
それが、私にとってのものづくりです。
コードを書くことだけが、ものづくりではない。
AIがコードを書いても、人間はものづくりから降りなくていい。
むしろAI時代に守るべきなのは、
人間の作業ではなく、人間がものづくりに参加していること
なのだと思います。
前回の記事で、私は、
AIと一緒に作るの、めちゃくちゃ面白いぞ！！
というところまで行きました。
今回、その続きを一言で書くなら、こうです。
だから、その面白さを人から奪うな。
Human-in-the-making。
これは、OVER SOULになるためだけの考え方ではありません。
人とAIが、もっと長く、もっと健全に、一緒にものづくりをしていくために、
人をどこに残すのか。
その問いに対する、今の私なりの答えです。