コードは100%AI製。速くなったぶんは確認に回しています
今回は、このブログに出てくるツールの、作り方そのものの話です。
先に書いておくと、コードは1行も書いていません。100%AI製です。 ただ、何を作るかは自分で決めていますし、出てきたものが世に出せる状態かどうかも自分で見ています。 書く工程だけがAI側にある、という状態かと思います。
実際の流れ
だいたいこの順で進んでいます。
- Claudeと壁打ちして、何を作るか（何を直すか）を固める
- そのまま設計を詰める
- 設計が固まったら、実装AI向けの指示書をMarkdownで出力させる
- 指示書をAntigravity（Gemini）に読ませて、まず修正プランを作らせる
- プランを読んで、違和感があれば指摘する。怪しいと思えばレビューもさせる
- 内容次第では、修正プランをもとに実装プランをもう一段作らせる
- 通ったら実装させる
- テスト環境にデプロイするか実機に入れて、自分で動かして確かめる
- 一通り直し終わったら、Claudeにソースを読ませてリリース判定用のレビューをさせる
3の「文書にして渡す」は、今のやり方に変えてから始めたことではありません。 Geminiで設計していた頃も同じで、壁打ちで設計が固まったら、 実装AIに渡すためのプロンプトをMarkdownで出力させて、それを持っていく形でした。
実装AIはこちらの会話を知らないので、指示書は毎回それだけで完結している必要がある。 「前回の続き」が通じない相手なので、必然的にそうなります。
分けているのは、まず予算の都合
開発初期の相談にClaudeを使うようになったきっかけは、Fableという上位クラスのモデルを試したことでした。 ※7月頃は期間限定で使える状態だったので、駆け込みで色々やっていました
まとまった作業時間を取って設計の壁打ちに投入してみたら、 頭が良くラリーがスムーズで、返ってくるものの精度も良かったので、それ以来この形が続いています。 ※Proプランで使えなくなった頃にOpus 5が出たので、今はそちらをメインに
ただ、実装まで同じところでやろうとすると、トークンが全然足りません。 設計の壁打ちはテキストのやり取りで済みますが、 実装はコードを読んで、書いて、直してを繰り返すので、消費量の桁が変わる。
なので、設計と指示書までをClaude、実装をAntigravity（Gemini）に分けています。 分業の理由として一番大きいのは、精度うんぬんより先に、そこです。
見るところに濃淡をつけている
前の工程と後の工程で、確認の密度をだいぶ変えています。
指示書やプランの段階は、そこまで細かく読んでいません。 怪しそうなところ、違和感のあるところを指摘する程度で、 前に決めたことと違うのでは、とか、そこは触らなくてよかったはず、とか、 だいたいコードの良し悪しより手前の話です。 引っかかったら指摘するか、別のAIにレビューさせて見てもらいます。
そのぶん、動作確認は自分でやります。 作っているものの大半はブラウザで動くツールなので、 実際に触って、操作の流れが引っかからないか、 初見の人が迷いそうな並びになっていないか、そのあたりを見ていきます。 ここはAIに渡していません。
ただ、触って分かることには限りもあります。 なので一通り直し終わったところで、今度はClaudeにソースを読ませて、 このまま出していい状態かを判定させる工程を入れています。
Androidアプリのときに出てきたのは、 サービスを終了してもコルーチンが後始末されずに残っている、という指摘でした。 動かしている限りは何も起きないので、実機を何度触っても気づけない類のものです。 手触りで拾えるものと、読まないと拾えないものは別なので、そこで分担している形かと思います。
通してしまった話
とはいえ、前の工程を流し読みしているぶんの請求は、後で来ます。
Androidタイマーアプリの音声ガイドが、フェーズ切替のたびにビープ音になる不具合がありました。 一度直したのですが、そのときの指示書にこう書いてありました。
開始直後はTTSの初期化が間に合わず、最初の1〜2回がビープになることがある（許容挙動）
読んで、通しました。 実機で試したら、ほぼ全編ビープでした。10回中9回。
指示書を書いたのはAIですが、これを許容と判断して先へ進めたのは自分です。 実装側は、書かれた条件を満たすところまでを仕事にする。 条件が甘ければ、甘いまま完成品が出てくる。そこは違うのでは、とは言ってくれない。
原因は、TTSのエンジンをワークアウトのたびに作り直していたことでした。 初期化が間に合うかどうかを毎回やり直していて、たまたま勝った回だけ声が出ていた。 アプリの起動時に1回だけ作って使い回す形に組み替えて、ようやく直っています。
一番長いのは、確認して直している時間
実装そのものは、待っていれば上がってきます。
長いのはそのあとで、テスト環境に上げるか実機に入れて、触って、 気になったところを拾って、また指示書に戻して直してもらう。 ※修正はClaudeまで戻さずAntigravity内で完結させるのがほとんど この往復が、体感では一番時間を食っています。
Webのツールでいちばん多いのは、スマホの幅にしたときの表示崩れです。 PCの画面ではきれいに組み上がっているものが、 幅を狭めた途端にはみ出したり、詰まったりする。 毎回どこかしら出るので、今では前提として見に行くところになりました。
あとは、動いてはいるけれど押しにくい、この順番だと迷う、といった類。 仕様の外側にあるものなので、指示書の段階では書きようがなく、 触ってはじめて出てくる、という性質のものです。
まとめ
速度に関しては、はっきり別物になりました。
自分で手を書いていたら何ヶ月か掛かっていただろう物量が、数時間で出てきます。 プライベートの開発で、この差はさすがに効きます。 ツールが立て続けに出せているのは、ここが大きな理由になっています。
ただ、出てくるのが速いことと、出せる状態になっていることは別の話です。 早く上がってくるぶん、確認のほうに時間を回すことになりました。
前の工程は流し読み、後の工程は自分の手と目で。 今のところ、その配分で落ち着いています。