生成AIはシステム開発・ソフトウェア開発をどう変えるのか？

　生成AIの台頭と開発現場への普及

近年、生成AI（Generative AI）は私たちの私生活だけなく、仕事の局面においても利用されるケースが多くなってきました。

生成AIは、従来のルールベースや機械学習と異なり、コードだけでなく、人が普段使用する自然言語や画像などを生成する能力をもっています。

• • メモ：
    • ルールベース：人が設定した事前のルールに基づいて動作し、特定のタスクについて高い精度と一貫性を持つ反面、柔軟性には欠ける。
    • 機械学習：大量のデータから自己学習し、パターンを見つけ出す能力を持つが、結果の根拠がわかりにくく、学習の偏りが性能に影響する。

一方開発現場は、仕様書作成や、コードレビュー、テスト設計、教育資料作成など「知的集約型作業」が多く、生成AIの活用余地が大きい印象があります。

• • メモ：
    • 知的集約型作業：技術・知識・情報・判断力が価値の中心で、労働の量だけでなく、知識の質が成果を決める。生産性を高めるには、知識の蓄積と再利用、設計の品質を高めることが重要となる。
    • 労働集約型作業：主に人の手作業や現場の働き手の数に依存する生産・サービスで、生産性を高めるには、人数を増やすか、作業を標準化して手間を減らすかが鍵となる。

今回は、生成AIをどのように開発プロセスに導入していくと良いのかを考察してみました。唯一の答えではなく、あくまでひとつの見解として読んでいただけると幸いです。

 

　生成AIの活用ケース

皆さんご存知のように、生成AIはプロンプトを入力することで、「それなり」の出力を返してくれるので、開発プロセスの様々な場面で利用できる可能性があります。

要求定義と仕様書作成の支援アイデア

• ユーザストーリーやユースケースの作成：プロンプトから指定した形式のストーリーやケースを作成する
• 曖昧性の検出：自然言語仕様に潜む曖昧表現（例：「これまでと同様に処理する」）を指摘し、改善案を提示する
• 翻訳支援：日英併記仕様書の生成、用語統一を支援する
• 国際標準の適用：要求工学との整合性を意識し、構文化された要件記述を促進する。

設計・実装作業の支援アイデア

• 短いコードの断片生成：設計書から関数の雛形を生成する
• 設計書の記述補完：クラス図やシーケンス図の説明文を自動で生成する
• スクリプト自動化：JIRAやConfluenceの操作をScriptRunnerで自動化するために、そのスクリプトを提案する
• 面倒な作業のたたき台作成：FMEAなど多くの工数が必要なる作業のたたき台を生成する
  （「生成AIを活用した設計ドキュメント作成プロセス効率化支援」を参照）

テスト・品質保証への応用アイデア

• テストケース生成：仕様書から境界値・異常系を含むテストケースを生成する
• 不具合報告書の作成：不具合内容を自然言語で要約し、指定したカテゴリに分類する
• テスト結果の報告書作成：テスト結果を要約し、報告書を自然言語で自動生成する
• レビューや監査のコメント生成：プロジェクト成果物のレビューや監査のコメントを提案する

教育・ナレッジマネジメントへの利用アイデア

• 教育資料の作成：ISOやIEEEなどの一般知識を図解付きで説明する資料を作成する
• FAQ・用語集の作成：社内固有の用語を定義と使用例を自動生成する
• 多言語展開：既存の日本語教材を、技術用語や文脈を考慮して英語教材へ翻訳する
  （「AIの力でリアルを超える！多言語対応の次世代動画制作を始めました」を参照）

 

　導入における留意点と課題

一見すると、人間にとって都合の良いように、何でもやってくれそうですが、生成AIはまだ、発展途上であり日々進化しているため、現時点では利用する際には、いくつか留意点があると考えています。

出力の信頼性

皆さんご存知のように、生成AIは虚偽または誤解を招くような情報を、あたかも事実にように提示するハレーション（ハルシネーション）を起こします。

また、生成AIは、事前に学習した膨大なデータから「次に来る言葉」を確率モデルから予測して出力しているため、毎回同じ出力が出るわけではありません。

よってルールベースにように、精度が高く一貫性のある出力を生成するわけではありませんから、生成結果はあくまで「提案」と捉え、人間によるレビュー・検証が不可欠になります。

プロンプト設計力

「プロンプトエンジニアリング」という言葉があるように、適切な指示を与える技術やスキルが、生成AIの出力の品質を左右します。プロンプトエンジニアリングに関する書籍やサイトが多くあることからも、その重要性を一目瞭然です。

また、開発現場の当たり前が生成AIにとっての当たり前でない可能性もあります。プロンプトやコンテキストなどの入力を与える際には、それが一般的な情報なのか、組織や製品に固有な情報なのかを整理し、質の良い出力を得る様々な工夫が必要であると考えます。

セキュリティ・著作権

社内情報や第三者の知的財産を扱う際には注意が必要です。

生成AIが出力する際、クラウド上で処理される可能性が高いため、情報漏洩リスクがあります。生成AIの学習範囲を限定したり、社内ポリシーで入力可能な情報の範囲を明示したり、入力検証・フィルタリングの仕組みを導入して、利用制限を設ける必要があります。

生成AIが学習したデータに著作権がある場合、その影響を受けた出力が著作権侵害と判断される可能性がありますが、個々の出力結果に対して警告してくれるわけではありません。AIが生成したコードや文章をそのまま使う場合、著作権の所在が不明確なことがあるので注意が必要です。

 

　今の生成AIはあくまで「良き相棒」

前述の留意点や課題を考えると、特定の開発工程や開発作業を、マルっと人に代わって生成AIにやってもらう（自動化してもらう）には時期尚早ではないか。というのが筆者の見解です。

「設計のアイデアを他の人からもらいたい」「誰かちょっと分析を手伝ってほしい」といった、開発者個人のサポート役として生成AIを活用するのが、現時点での適切なやり方ではないかと考えています。1990年代後半から2000年代初頭に流行った「ペアプログラミング」のように、開発者に代わるモノではなく、開発者の良き相棒になってくれれば、個人の生産性や作業の質は向上し、開発者の集合体である組織の開発プロセスの生産性と質の向上にもつながるのではないでしょうか。

生成AIに関して、いま組織が標準化すべきは、生成AIによる自動化を狙ったプロセスではなく、開発者個人に向けた「生成AIの利用ガイドライン」なのかもしれません。

 

内山　哲三