現在、システム開発への生成AIの利用はコーディングに対して適用するのが主流になっています。GitHub CopilotであったりAmazon Q Developerなどが代表的でしょう。
その中で、システム開発の上流から下流まで全体的に生成AIを適用しようという書籍を目にし、興味を持ったので読んでみました。
生成AIの適用とコンテキストの重要性
僕が思うに、生成AIの適用が実装工程に集中している一因は、生成AIに与えるコンテキストを限定しやすいことかなと思います。 確率的な生成モデルに対して適切な出力を生成させるには、与えるコンテキストが重要です。コンテキストが限定されているほど、生成AIの出力が適切になる可能性が高まります。それが実装工程におけるコードの補完と相性が良い。知らんけど。
一方で、そのコンテキストが複雑になればなるほど、意図した出力を生成することが難しくなります。例えば設計には大きな自由度があり、その自由度を制約するコンテキストをうまく生成AIに与えないと、生成AIから適切な設計は生まれません。人が設計を行う際も同様の課題が生じますが、人は要求・要件や、要件定義者と会話した中で掴んだ優先度設定、さらには自分の経験やチームのスキルセットによって自由度を制約しています。それはもしかすると無意識の中でかもしれませんが。
要求・要件が与えられるものではなく、要求・要件自体を探していくのはさらに自由度が大きくなるのかもしれません。
情報依存関係とプロンプト
この生成AIをシステム開発に適用するにあたって重要なこととして、情報の依存関係が挙げられています。
アイデアがなければ業務制約が導けず、業務制約がなければそれをシステム制約に落としていくことができない。システム制約がなければ仕様が導けず、仕様がなければ設計が導けない。これはある意味、自由度を制約していく過程でもあるでしょう。
さらに言えば、プロンプトには次の要素を含めたいと述べられています。 これも、ある意味自由度を制約していく過程の一部とも言えるでしょう。
（１）生成AIに割り当てたい役割 （２）前提条件や背景情報 （３）生成する成果物とその出力形式 （４）仕事の遂行のために不足している情報があれば質問をするように生成AIへ促す
生成AIを活用した商店街活性化のシステム開発
この書籍では、商店街を活性化させたいというざっくりとした要求から、生成AIとの対話・要求定義者との議論を繰り返しながら、システム開発を進めていく様子が描かれます。何か新しいツールを使うでもなく、単に生成AIにコンテキストと質問を与え、得られる回答に対してフィードバックを与えることを繰り返していくという意味で派手さはありません。一方で、人がフィードバックをしやすいように回答をMermaidで可視化したり、人間が先に「知識」（例えば、ビジネスモデルキャンバスとはどういうものか）を生成AIに与えその知識を前提とした回答を生み出すといったやり取りは、なるほどと頷けるものがありました。
限られた誌面の中で生成される設計は必ずしも十分な解像度に到達している訳ではないのですが、システム開発に生成AIを適用するという意味では示唆に富んだ内容でした。
