最近、LLMを使った開発、いわゆるAIDD（AI-Driven Development）に関心がある。

AIDDについて見聞きするうちに、気になる問いが出てきた。AIが開発をうまく進められるかどうかは、モデルの性能だけで決まるのだろうか。

モデルが高性能であることは前提になる。コードやドキュメントを検索して参照できる環境も必要だ。ただ、それだけでAIが長時間、迷わず作業を続けられるとは限らない。人間が最初にどんな問題を渡し、どこまで判断を任せるか。その設計が、同じモデルの成果を大きく左右するように思う。

AIDDの成否は、モデル性能だけでは決まらない

AIDDでいう「開発」は、コードを一度生成して終わる作業ではない。目的を理解し、必要なファイルを読み、変更し、テストし、失敗したら原因を調べて修正する。人間の開発と同じように、複数の工程が続く。

この流れをAIに任せるなら、AIが途中で判断に迷わない問題設定が必要になる。何を達成すれば完了なのか。どこまで変更してよいのか。結果を何で評価するのか。これらが曖昧なままだと、モデルが賢くても作業の方向は安定しない。

たとえば、次のような目標は比較的評価しやすい。

• テストの成功率を80％まで上げる
• レイテンシを20％改善する
• ベンチマークの値を一定の水準まで向上させる

一方、新機能の追加や設計変更では、途中で仕様を見直したくなる。作業中に新しい課題が見つかることもある。人間が判断したくなる場面を、最初からすべて予測するのは難しい。

そのため、AIDDでは「性能の高いモデルを選ぶこと」と同じくらい、「AIが進められる単位まで問題を分けること」が大切になるのではないか。

ナイトコーディングに必要なIssue設計

最近、「ナイトコーディング」という言葉を耳にするようになった。人が寝ている間にAIが開発を進め、朝になったら成果を確認するという進め方だ。

人間が使える時間には限りがある。一方、実行環境とタスクが整っていれば、AIは夜のあいだも作業を続けられる。この考え方には魅力がある。

ただし、夜間に任せる前に、人間が十分な準備をしなければならない。Issueとは、開発管理上の作業単位を指す。AIに渡すIssueには、目的だけでなく、対象範囲、完了条件、確認方法まで含める必要がある。

「検索機能を改善する」だけでは、AIは何をもって改善とするか判断できない。対象となる画面やAPI、変更してよいファイル、守るべき互換性、実行するテストが書かれていれば、AIは次の行動を選びやすくなる。

反対に、判断を残したまま作業を夜間に持ち越すと、翌朝までに不要な変更が積み上がる可能性がある。ナイトコーディングは、人間の作業を単純に夜へ移す仕組みではない。夜に任せられる問題へ、昼のうちに変換する作業だと思う。

社内ハッカソンで確かめたいこと

私は参加していないのだが、社内ハッカソンもAIDDを前提に開催されるらしい。人間に与えられる時間は12時間、初日10時間と翌日2時間。その一方で、AIは24時間動かし続けるという形式だそうだ。

最初に聞いたときは、「本当にそれで開発が進むのか」と思った。24時間もHITL（Human In The Loop、人間が途中で確認・判断すること）なしに進めるなら、途中で方針を修正する機会が少なくなる。AIが予想外の方向へ進んだ場合、翌朝には大量の手戻りが発生しているかもしれない。

24時間動かした場合のLLM利用料金も気になる。成果物ができたとしても、投入した時間と費用に見合っているかは確認しなければならない。

だからこそ、このハッカソンには興味がある。完成したアプリケーションだけでなく、AIへどの粒度の作業を渡したのか、どこに評価条件を置いたのかを観察できるからだ。

成果物より、運用を見たい

今回は参加を見送った。今の立場では、12時間を確保するのが難しいと判断したためだ。それでも、可能なら会場には行ってみたいと思っている。

私が知りたいのは、何が作られたかだけではない。次のような運用の詳細だ。

• Issueをどのように分割したのか
• AIにどのような指示を書いたのか
• 途中で人間は介入したのか
• 失敗した作業をどのように止め、戻したのか
• 朝になった時点で、どこまでを完成と判断したのか

成果物は、いずれ自分でも作れるかもしれない。しかし、実際の運用でどのような準備と判断が必要だったかは、参加者の経験からしか学びにくい。

特に知りたいのは、AIが一度も迷わなかったかどうかではない。迷ったときに、どの情報や評価条件によって進む方向を修正できたのかである。

長時間実行を支える環境

最近、時間が足りないと感じることが増えた。出社回帰もあり、通勤時間をどう使うかを考える機会も多い。

これからは、PCを持ち歩いて作業するだけでなく、自宅で動き続けるAIへ指示を出す時間が重要になるのかもしれない。Claude CodeのRemote Controlのように、離れた環境でAIの作業を確認する選択肢も現実的になってきた。

ただ、自宅に常時稼働させられるMac Studioのようなマシンがあるわけではない。手元にあるのはMacBook Proなので、スリープをどう扱うか、長時間動かしたときに安定するか、といった課題が残る。

AIに作業を任せる場合、モデルと指示文だけでは足りない。実行環境、権限、ログ、停止方法まで含めて準備する必要がある。ここもAIDDの運用を考えるうえで、見落としやすい部分だと思う。

AIDDを評価するための仮説

現時点での私の仮説は、AIDDの成否を次の四つで見ると整理しやすいというものだ。

• AIが迷わず進められるIssue設計
• 成否を判定できるGoal（達成目標）
• 人間が介入するタイミングと停止条件
• 長時間の実行を支える環境

もちろん、これで十分だと断言できるわけではない。モデルの性能や参照できる情報の品質も重要だ。ただ、そこだけを見ていると、同じモデルを使っても結果が変わる理由を説明できない。

今回のハッカソンで、完成したアプリケーションと同じくらい、その前後のプロセスを観察したいと思っている。AIDDが一晩の開発として成立する条件は、夜の実行中ではなく、その前の準備に表れるはずだ。