AIで「作れないもの」が作れるようになる

前回は、ChatGPT・Codex・Geminiを小さな開発チームのように使っている、という話を書いた。

ChatGPTで構想を整理する。
Codexで実装する。
Geminiでレビューする。
人間はPM/POのように、方針決定と採否判断を行う。

この体制にしてから、Model Weaveの開発はかなり進めやすくなった。

今回は、その中で感じているもう一つの変化について書いてみたい。

それは、AIによって「自分だけでは作れなかったもの」に手が届くようになる、ということだ。

AIは、できる人の置き換えだけではない

AIの話をすると、どうしても「プロの仕事が置き換えられるのか」という話になりやすい。

プログラマーの仕事はどうなるのか。
ライターの仕事はどうなるのか。
デザイナーの仕事はどうなるのか。
設計者やPMの仕事はどうなるのか。

この不安はかなり現実的だと思う。
実際、AIはかなり多くの作業を代替し始めている。

ただ、自分がModel Weaveを作っていて強く感じたのは、AIは「できる人を置き換える道具」である前に、まず「できなかった人の範囲を広げる道具」でもあるということだった。

自分は、もともと一からObsidianプラグインを作れるタイプの開発者ではない。
コードを読んだり、方針を考えたり、仕様を整理したりすることはできても、実装を全部自力で進めるにはかなりハードルが高い。

それでも、Model Weaveは形になってきた。

それは、AIに全部を丸投げしたからではない。
構想、設計、実装指示、実装、レビュー、修正、記事化を分けて、それぞれにAIを使ったからだ。

この変化はかなり大きい。

これまでなら「作りたいものはあるけれど、自分では作れない」で止まっていたものが、
「作りたいものを整理し、AIに実装してもらい、人間が確認しながら進める」形に変わった。

自分だけでは作れなかったものに手が届く

Model Weaveは、もともと「テキストを正本にしたモデリングツール」を作りたい、というところから始まった。

最初は、ファイル管理、エディタ、プレビュー、図の表示まで全部を自前で作ろうとしていた。
その後、Obsidianプラグインへ切り替えたことで、ファイル管理やエディタの基盤はObsidianに任せ、Model WeaveはMarkdownから図やPreviewを生成する部分に集中できるようになった。

この判断自体も、AIとの壁打ちをしながら整理していったものだ。

ただ、方針が見えても、それだけで実装できるわけではない。

Obsidianプラグインとしてどう作るのか。
Markdownをどう解析するのか。
ER図やクラス図をどう表示するのか。
DFDをMermaid-firstにするにはどうすればよいのか。
Viewerでzoom、pan、diagnostics、PNG exportをどう扱うのか。

こうした実装をすべて自分だけで進めるのは、かなり難しかったと思う。

そこでCodexが大きかった。

ChatGPTで仕様や実装指示を整理し、Codexに実装してもらう。
実装結果を確認し、必要ならGeminiにレビューさせる。
レビュー結果をまたChatGPTで整理して、次のCodex指示にする。

この流れを繰り返すことで、自分だけでは届かなかったところまで進めるようになった。

もちろん、毎回一発でうまくいくわけではない。
実装が意図と違うこともある。
差分を見て戻すこともある。
方針を変えることもある。

それでも、ゼロから自分で全部実装する場合とは、進められる範囲がまったく違う。

構想・設計・実装指示に分けると前に進めやすい

AIを使っていて大事だと感じたのは、「作って」と一言で頼むのではなく、作業を分けることだ。

たとえば、Model Weaveの開発では、いきなりCodexに大きな機能を作らせるのではなく、まずChatGPTで方針を整理する。

この機能は本当に必要か。
今やるべきか。
既存仕様と矛盾しないか。
どのファイルを触りそうか。
どこまでを今回の範囲にするか。
何を対象外にするか。
確認コマンドは何か。

こうした内容を整理してから、Codex向けの実装指示にする。

これは、実際の開発プロジェクトで作業をチケット化する感覚に近い。

「いい感じにして」ではなく、

• 目的
• 対象範囲
• 作業内容
• 対象外
• 確認方法
• 期待する結果

を明確にして渡す。

この形にすると、AIに実装してもらう場合でもかなり安定する。

逆に、ここが曖昧なままだと、AIはそれっぽく進めてしまう。
実装はできているように見えても、目的からズレたり、不要な変更が混ざったりする。

だから、AIを使うほど、むしろ人間側の設計整理が重要になる。

Codexがあることで、実装の壁がかなり下がった

Model Weaveの開発で特に大きかったのは、Codexによって実装の壁が下がったことだ。

ChatGPTだけでも、実装方針やコード例は出せる。
しかし、実際のリポジトリの状態を前提に、複数ファイルを編集し、ビルドやテストを確認しながら進めるには、Codexの方が向いている。

たとえば、機能追加をするときには、コードだけではなく、READMEや仕様ドキュメント、サンプルも影響することがある。

人間が全部追うと大変だが、Codexならリポジトリ全体を見ながら修正できる。
もちろん、完全に任せきりにはできない。
それでも、実装担当としてかなり強い。

この効果は、単に「作業が速くなる」だけではない。

自分のように、実装の専門家ではない人間でも、作りたいものを具体化しやすくなる。
設計の方向性を考え、AIに実装してもらい、結果をレビューすることで、開発を進められる。

これは個人開発のハードルをかなり下げる。

今までは、ある程度の実装力がないと、アイデアはあっても形にできなかった。
今は、実装力そのものが足りなくても、目的や仕様を整理できれば、そこから先をAIに手伝ってもらえる。

ここはかなり大きな変化だと思っている。

ただし、何を作りたいかは自分で持つ必要がある

一方で、AIがあれば何でも作れる、という話ではない。

AIは実装を助けてくれる。
仕様整理も助けてくれる。
レビューもしてくれる。
ブログ記事やアイキャッチ案まで作ってくれる。

ただし、「何を作りたいのか」は人間側に必要だ。

Model Weaveであれば、中心にあるのは、Markdownを正本にしたいという考えだ。
図やPreviewは派生出力にしたい。
Obsidianの中で設計情報を読みやすくしたい。
ER、Class、DFD、data_object、screen、app_process、rule、mappingを、テキストとしてつなげていきたい。

この方向性がないと、AIは便利な機能をいくらでも提案してくる。
しかし、何を採用すべきかは決まらない。

AIは候補を出すのが得意だ。
でも、候補が多いほど、判断する人間が必要になる。

この機能は今やるべきか。
この仕様は重すぎないか。
この表現は公開向けとして自然か。
この実装は保守できるか。
この変更はModel Weaveのコンセプトに合っているか。

こういう判断は、人間側に残る。

だから、AIによって「作れる範囲」は広がるが、「何を作るか」が不要になるわけではない。

むしろ、作れる範囲が広がるほど、何を作らないかを決めることも重要になる。

「誰でも作れる」ではなく「作れる範囲が広がる」

AIを使った開発について、「誰でも作れるようになる」と言いたくなることがある。

たしかに、以前よりはかなり作りやすくなっている。
自分のように、実装を全部自力でやるのが難しい人間でも、AIを使えば形にできるものが増える。

ただ、「誰でも作れる」と言い切るのは少し危ない。

実際には、作るにはいくつか必要なものがある。

まず、作りたいもののイメージが必要だ。
次に、それを分解してAIに伝える力が必要だ。
そして、出てきたものを確認し、違和感を拾う力が必要だ。

完全にコードが書けなくてもよいかもしれない。
ただし、何が起きているかをまったく見ないまま進めるのは危ない。

AIはかなり賢いが、間違えることもある。
こちらの意図と違う方向に進むこともある。
もっともらしいが、後で困る実装をすることもある。

だから正確には、

AIによって、作れる範囲が広がる

という表現が一番近いと思っている。

「できない」が「できる」に一気に変わるというより、
「自分だけでは難しい」が「AIとなら進められる」に変わる。

これが、今のところ一番実感に近い。

Model Weaveは、その実例になった

Model Weaveは、自分にとってこの変化の実例になっている。

最初に作りたかったのは、業務システム設計をテキストで管理し、AIにも人間にも読みやすくするためのツールだった。

Excel設計書のように自由度が高すぎる形式ではなく、
専用モデリングツールのようにツール依存しすぎる形式でもなく、
Markdownを正本にして、図やPreviewを派生出力にする。

この考え方自体は、自分の中にあった。

ただ、それを実際にObsidianプラグインとして形にするには、実装の壁があった。
そこをAIで補うことで、少しずつ前に進められた。

ChatGPTで考えを整理する。
Codexで実装する。
Geminiで確認する。
人間が方針を決める。

この分担によって、Model Weaveは「作れたらいいな」から「実際に使えるツール」へ近づいてきた。

これは、自分にとってかなり大きい。

AIは、すでにできる人の作業を速くするだけではない。
できなかった人が、作れる側に近づくための道具にもなる。

もちろん、その先には別の問題もある。

作れる範囲が広がるということは、プロの仕事の一部がAIで代替されるということでもある。
それは便利さであると同時に、不安にもつながる。

次の記事では、そのあたりをもう少し掘り下げてみたい。
AIによって作れる範囲が広がるとき、プロの仕事はどう変わるのか。
その不安はどこまで現実的なのか。
そして、専門性はどこに残るのか。

このあたりを書いてみたい。