「AI駆動開発【大阪支部 #14】with クラスメソッド」で気になったワードをChatGPTに聞いた

AI駆動開発の本質は「AIに何を任せるか」ではなく「人間がどこで判断するか」の設計にある。イベント参加者が気になったワードをChatGPTに投げた記録から、その核心が浮かぶ。Issueの内容によって、人間が入る場所は固定ではない。ファーストワンマイルは問題設定・目的定義の段階で人間が決める。「これは本当にバグなのか、仕様変更なのか、直すべき優先度なのか」。曖昧さや経営判断が大きいIssueほど、ここに人間が入りやすい。一方、ラストワンマイルは最終判断・承認の段階で人間が見る。本番反映、顧客への送信、金銭支出、権限変更。不可逆で高リスクな操作ほど、人間を手前に置く。可逆な変更はAIに深く任せ、不可逆な変更ほど人間を手前に置く。この軸が、実務で扱いやすい整理をもたらす。

入力経路は複数あってよい。人がIssueを書く、メールから起票する、監視アラートから起票する、AI自身が異常を検知して起票する。だが出口は一本化する。同じ承認フロー、同じCI/CD、同じ監査ログ。複数の出口があると、本番変更経路が増え、承認を迂回できるようになり、ログが分散する。出口を一本化することで、利便性とガバナンスを分離できるのだ。トークンコストの意識も大事だ。AIに途中経過を逐次出力させるほど、その分だけ出力トークンを消費する。詳細ログはシェルやCI側に保存し、AIは判断だけに寄せる。「実況者」ではなく「判断器」として設計すれば、長時間ループでも効率よく回せる。

AIが自力で進められなくなったとき、単にエラーで止めるのではなく、人間が判断できる形にまで整理して返す。「何が分からないのか、どの判断が必要なのか、選択肢は何か」。AIの停止を人間のアジェンダに変換することで、ループが再開できる。こうした設計思想は直線ではなく、課題に応じて行き来する。Prompt→Context→Harness→Loopは成熟度レベルではなく、問題に応じて見直す場所が常に変わるのだ。AI導入時に「最終形はこれだ」と固定して考えるのではなく、運用の中で何度も立ち返り、修正し、改善する柔軟性が求められる。