AIとソフトウェア開発に関しての所感と予感

ここ半年程度のソフトウェア開発領域におけるAI利用の所感

以前は個人開発では仕様書のようなものはあまり書かず、コードファーストで自分でがりがり書いて進めていた。
ただ最近は、AIエージェントによるコード作成が圧倒的に速く、自分でコードを書く理由があまりなくなってきていると強く感じる。

その代わり、コードを先に書くよりも、アイディア出しと基本的な仕様、作業計画を重視する形になりつつある。
（仕様駆動開発を理解できてないけど、重視している観点としては似ているのかも。）

一方で仕事ではもともとそういった文書は必須なので、個人開発の進め方が仕事のやり方にかなり近づいてきているとも感じている。

この辺はすでにさまざまなところで語られていて、自分が特筆して語りたいことは特にない。
ただWebアプリやモバイルアプリのように、もともとオープンソースとして公開・提供する文化が強い領域だからこそ、AIエージェントが強い、という面はあると思っている。

逆に、クローズドソース（企業間で、NDAや強い制限のもとで提供されるミドルウェアやSDK、あるいは社内で継続的に開発されているクローズドな製品）を前提にソフトウェア開発をしなければならない場合、AIエージェントの力を借りようとしてもうまくいかないことはあるかもしれない、とも想像している。
それでもAIエージェントに与える情報や環境をきちんと整備できれば、その壁は比較的早く乗り越えられそうでもある。

いずれにせよ、ソフトウェア開発において人間が力を入れる場所が、仕様とその確認（テスト）へより大きく移ってきた、という感覚はありほぼみんながプロダクトオーナーになるようなイメージを持っているが、では本当に経験のない領域でも同じことができるかというと、それはまだ無理そうだ、というのが現段階の正直な感想。

最近の個人開発のやり方

エージェントを並列で動かして、もはや指示とチェックだけを人間が行う、というのがおそらく最先端のやり方なのだと思う。
ただ、今のエージェントの出力を見ていると、並列動作ですべて作らせるにはやや不安がある。
よって相変わらず1〜2エージェントの動作に留めている。正直、個人開発ならそれで十分そうではある。

ということで、それを前提として、最近は以下のような流れで進めている。

  1. エージェントと壁打ちしながら、作るアプリや機能のアイディア出し、現実性の検討、あわせてざっくりとしたアーキテクチャの検討を行う。
  2. 基本仕様書を作成する。内容は、アーキテクチャ、バックエンド処理、バックエンドAPI、DBスキーマ、フロントエンドのページ遷移や気になる部分のUIパーツなど。 この基本仕様書は人間がレビューする。 ただし、コード生成が速くなっているため、フロントエンドは割と気軽に変更できるようになった。そのため、そこまで詰める必要はないと感じている。
  3. 仕様書をもとに、AIエージェント向けの作業指示書をまず作成させる。
    これは具体的な実装の話ではなく、今回の機能を作る背景、目的、前提、優先順位、方針、注意事項、そしてその機能で何を達成すべきか（ユーザーに何を提供するのか、どのような性能が必要か、などの受け入れ条件）といった情報を載せる。これも人間がレビューする。
  4. 作業指示書をもとに、作業ステップごとの実装計画書を作らせる。
    これは作業ステップごとの完了条件を明確にすることと、AIエージェントのセッションを常にクリーンに保ちながら作業を継続できるようにすることが目的。 残念ながら、基本仕様書や作業指示書は概要レベルにとどまりがちで、期待したコードがそのまま出てくるわけではない。また、エージェント側が保持できるコンテキストもそこまで大きくない。
    そのため、作業単位を小さくするための下準備としても機能する。これも人間がレビューする。
  5. 4で作った実装計画書に沿って、順に実装させていく。
    この時点で実装にあたって不明瞭な点がないかは、実装担当のセッションで先に確認する。実装後には単体テストも実装させる。
    機能追加によって既存コードが変わる場合は、過去の単体テストコードも同時に修正させる。単体テストは別セッションで実装させてもよい。コードレビューも適宜行わせる。
  6. ある程度実装が進むと、回帰テストができる段階に達するので、その時点で回帰テスト用のスクリプトなどを実装させる。
    以後、回帰テストを適宜実行させる。人間も適宜、手動でテストを行う。
  7. すべての実装が終わった後に、改めて作業指示書に記載した受け入れ条件を満たしているかをチェックさせる。

今はこの1〜7の繰り返しで、比較的安定して開発を進められていると思う。

予感

当たるも八卦、当たらぬも八卦。
以下は単なる予感でしかない、という前置きはありつつも、当たったら面白い。

運用はまだ大変そう

これまで経験がない人でも、ソフトウェアだけであれば「動くもの」は作れるところまで来ている。
ただ非機能要件まで含めて同時に考慮するのは、まだ難しい印象を受ける。

また動かす場所（コンピューティングリソース）は必要である。
特に社内のちょっとしたツール用途であっても、他の人に使ってもらおうとするとWebアプリケーションのほうが手間が少ない場面は多い。一方で、そのアプリケーションをどこでホスティングするのか、オンプレサーバであったとしても誰がメンテし、ハードウェアが故障したら誰が直し、どう運用していくのかといった課題は残り続ける。

そういった「作る」ことよりも、「作ったものを維持する」ための業務は今のAI単体ではどうにもならないなと思っている。

もちろん運用業務のうち、たとえばログやメトリクスを監視してエラー原因を自動的に探るなど、つまりソフトウェアの領域だけで完結する部分については、どんどんAIによって人手が不要になっていくだろう。

リソース不足と従量課金の隆盛

今のAIエージェントを本当にフル活用すれば、24時間365日働かせることもできてしまう。
また、企業がこれまで蓄積してきたデータがある場所や、そのエージェントが作業した結果を吐き出す場所もまた何らかのソフトウェアであり、それはクラウド上で動いていることが多い。この2点から、多くのSaaSは従量課金に移行するのではないか、と想像している。

今のエンタープライズ向けSaaSで多く採られている課金形態は、「ユーザー一人当たりいくら」というものである。
しかしこの課金形態は、あくまでユーザー一人がせいぜい10時間程度作業するために必要なリソースを前提にしているはずだ。

人間より短時間で大量のアウトプットが可能で、しかも24時間働きうるエージェントは、人間よりも大量の通信を発生させる。
SaaS側で処理した結果をAIエージェントが受け取り、何らかの処理をした後、すぐにまたSaaSへアクセスしてくる。しかもこのAIエージェントはユーザー一人で複数台動かしうる。

こうなると「ユーザー一人当たりいくら」という課金形態では儲けが出ない、ということになるのではないだろうか。

事実、人間がアクセスする場合であっても、大量のデータ転送が発生するようなサービス（例：JFrog Artifactory）は、すでに転送量による課金となっている。

社内インフラのひっ迫

一人の人間が複数台のエージェントを動かして作業する、という未来が当たり前になるなら、企業内の通信インフラやデータストレージなどもどんどん手狭になるだろう。

また、ローカルでさまざまなアプリを動かしたい、もしくはローカルLLMで十分な領域はオンプレミスでローカルLLMを稼働させたい、といった要望はすでにいろいろ出てきている。
これも社内インフラに負荷をかけることになる。

ということで

AIエージェントは、個人開発レベルであればアイディアをすぐ形にしてくれるので、とても助かっていて楽しいね、という話です。