エンジニア必見！僕の「自動化」開発プロセスを公開します

現在、この記事の内容はまだ公開されていませんが、今後私の開発ワークフローを効率化するために実践している自動化のヒントやツール設定について詳しくまとめていく予定です。乞うご期待！

ソフトウェアエンジニアリングという職業を飲み込みつつある、AI支援型の開発手法にどう向き合うか、自分なりに試行錯誤してきた結果がこれ。去年からのトレンドを見て、LLM開発に飛び込んでみたけど、どうやらこのプロセスは今後を見据えた現実的な選択肢になりそうだよ。

仕様駆動開発についての記事って、その前提となるプロダクト要求定義書が正しいものとして話が進むことが多いよね。でも、本当にそうかな？もしそうなら、君もそれについて書いていただろうし、そのリサーチの段階でエージェントを関与させていたはず。直感だけど、機能が妥当か、実現可能か、正しい前提に基づいているかを疑うことよりも、実装することばかりに重きが置かれている気がするんだ。

同じワークフローに行き着いたよ。ただ一点、OPと同じようにやると、Claude Codeはオーバーエンジニアリングに走りがちだよね。例えば、めったに起きないし影響も些細なレースコンディションに対して複雑な解決策を構築したりする。でも、「懐疑的なチェック（skeptical pass）」を挟むだけでいいことに気づいたんだ。やり方はこう：専門のエージェントたちに計画や実装をレビューさせ、その結果を重複排除・統合したあと、メインのエージェントに次の分類で仕分けさせるんだ。A) 単純・明らかな修正、B) 複数の解決策があるがLLMが自信ありと判断、C) 本質的な曖昧さがあり、ユーザー（自分）の判断を仰ぐ、D) 対応不要（Wontfix）。重要なのは、その後に「懐疑的なチェック」を実行させて、これらの結果を厳しく見直させ、格下げすべきものがないか確認すること。実際、これで多くのものが「対応不要」に振り分けられるんだ。オーバーエンジニアリングを自分で押し返す必要はなくて、LLM自身にやらせれば、かなりうまくこなしてくれるよ。

妙に「エレクトリック・モンク」を彷彿とさせるね。

『エレクトリック・モンクとは、食器洗浄機やビデオデッキと同じような労働節約装置だった。食器洗浄機が面倒な皿洗いを肩代わりしてくれるように、ビデオデッキが退屈なテレビ番組を代わりに見てくれるように、エレクトリック・モンクは持ち主の代わりに信じるべきことを信じてくれる。おかげで、世間から信じることを期待されるあらゆる事柄を自分で信じなければならないという、ますます厄介さを増す責務から解放されるのだ』

――ダグラス・アダムズ『ダーク・ジェントリーの霊的探偵事務所』

AIからそれなりの品質を引き出すために、対立的かつ協力的なアプローチをとるのは一般的だと思う。個人的には、役割に応じて複数のモデルを使い分けたり、継続的なドキュメントをしっかりメンテナンスしたり、計画の中で人間が検証可能な成果物をできるだけ早い段階で見えるようにしておくのが好きだね。まあ、多くの人が許容できる以上に注意を払う必要はあるだろうけど。