CodeAGIの紹介

設計書からプログラムコードを自動生成してくれたらなぁ…
エンジニアならば一度は考えであるこの夢を CodeAGI なら実現してくれる！？

今回 Qiita Engineer Festa 2024 にて CodeAGI が無料で試せるということを知ったのが記事投稿のきっかけです。

はじめに

今回の記事ではできるだけ 実際の開発での利用を想定 して使ってみた感想を率直に書きます。

私の立場

普段の業務ではシステム開発をメインで実施
実際の開発でもAIチャットをほぼ毎日活用
軽く OSS のソース自動生成ツールなどを触った経験あり

コード生成の流れ

とりあえず使ってみないと分からないのでまずは公式のサンプルを利用します。

コード生成するための大まかな流れを先に整理。

CodeAGI のセットアップ
コード生成に利用したい AI(LLM) を選択
プロジェクトを作成
プロジェクトに設計書を登録
AIによるコード生成実施！
AIによるテストケース生成

実際の画面メニューと紐づけるとこんな感じ。

1. CodeAGI のセットアップ

セットアップの方法は公式のマニュアルに詳しく記載されており、他の皆さんの記事もあるので割愛しますが、特に難しい場所は無かったです。

登録時の必須情報

メールアドレス（認証コードの受け取りに必要）
会社名
部署名
氏名

ちなみに公式マニュアルはアプリ画面からも辿れる。

2. コード生成に利用したい AI(LLM) を選択

現在選択可能なLLM。

OpenAI - ChatGPT
Azure – OpenAI
Google - Vertex AI

実際に業務で使う場合、設計書の内容がLLMに送信されるため、セキュリティ上のリスクはどうしても感じる。
弊社では最低限のセキュリティ対策が実施済みの社内向けのAI（Azure - OpenAI）が提供されているため、今回はそのAPIの利用を想定して検証を実施。

（画像の値はダミーです）

セキュリティ観点で言えば、LLM以外にも、登録した設計書情報が意図せずどこかに送信されないか等は気になる点

3. プロジェクトを作成

CodeAGIの一番大きな単位はプロジェクトとなるようで、まずはこれを作成します。

必要となる主な情報。

プロジェクト説明
コードの出力先フォルダの指定
コードの実行環境の指定（OS, DB, ブラウザ）
プロジェクト依存環境設定（開発言語, フレームワーク）
出力コードのフォルダ構成

複数プロジェクトでの利用が想定されるのでプロジェクト単位での管理は必要。
また設計書は変えずに環境設定だけで、異なる言語やDBに切り替えられるでの システム移行などでも使える かも。

現状ではβ版のため選べる言語やフレームワークが少ない。
順次サポートされるようなのでそのあたりは期待したい部分です。

4. プロジェクトに設計書を登録

サンプルの設計書は2つありました。

04.会議室予約システム - テーブル定義書.xlsx
- 「テーブル定義書指定」から登録
04.会議室予約システム - 画面設計書.xlsx
- 「機能設計書指定」から登録

「テーブル定義書」は設計書をアップするだけでOK。

「機能設計書指定」では 機能名 や 機能種別 を選択する必要あり。
この 機能名 単位でコード生成や画面イメージ指定などが実施されるため、 CodeAGI においてこの 機能名 は重要な位置づけだと感じました。

慣れれば問題はないですが、この 機能名 単位というのが当初すこし困惑。

ちなみに 機能概要 などは指定した設計書から自動的に生成されるとちょっとうれしいかも。（実際、上図の機能概要は個別にAIで生成）

取り込んだ設計書の内容は「指定データ確認」で参照可能。
またある程度 ラフなフォーマットでも取り込んでくれる ようです。

ここが CodeAGI の大きな魅力の１つかと思いました。
弊社でも設計書のほとんどがエクセルベースであり、特に加工せずにエクセルファイルをそのまま放り込めるというのは大きなポイントです。

5. AIによるコード生成実施！

機能名 単位に出力したい機能を選択し「プログラム生成」を実施。

あとは待つだけ…

無事生成できました。

私の環境では3分ほどで生成できたようです。

生成速度は選択しているLLMやネットワークの影響を強く受けるため、今回の3分でも人間が作るよりも全然早い。
ちなみに別のAPIを利用したい場合には1分ほどで生成できたので、現状で速度面での問題は無さそう。（もちろん早ければ早いほど良いが）

なおもっと大規模なプロジェクトの場合だと機能数も多くなるため、その場合の処理時間は気になるところ。

なお実運用で考えると、多少時間がかかってもその時間で人間は別の作業もできるので、プロジェクトによっては 時間 よりも お金 が重要になってくるかもしれない。

例えば費用の目安として API が利用したトークン数やその概算費用などが確認できればコストメリットを感じられそう

実際に生成されたコードの確認

生成されたソースは適切なファイル名が自動付与され、フォルダ構成を保ったまま指定フォルダにダウンロード可能。

なおソースの中身ですが、こちらは（当然ながら?）完璧なソースではありません。
この辺りは私自身も普段からAIによるソース生成などは実施しており、今回同じエンジンを利用していることもあり想定範囲内。

例えば Entity のプロパティ名が間違っているためにエラーが出ている。

あるいは、設計書には記載がないはずの予約完了画面やその遷移処理などが勝手に作られているなど。

もちろん完全なコードの生成が望ましいですが、現在のAIの性質上、生成されたソースをそのまま利用するという用途はあまり考えていない。
とりあえず動くものを生成して素早く検証したり、実装のひな型として活用するなどの利用が想定される。

6. AIによるテストケース生成

CodeAGI ではテストケース／データの生成もできるようなので検証。

テストケースはエクセルファイルとしてダウンロードが可能。

1つの機能に対して全72ケース生成。非機能要件のテストも存在。

テストデータはCSVファイルとして生成される。

こちらもソースコード同様にこのまま利用するというより、このテストケースをベースに不要ケース削除や、追加・修正するといった利用方法になるかと。

多数のケースが生成されるのでたたき台として使えそう
またテストデータの生成は作業の省力化につながる

テストコードも自動生成されるとうれしい

実際の開発を想定した検証

概要はわかったつもりなので、さらに実際の開発を想定し個人的に気になる点を使ってみました。

複数機能ある場合

大規模なプロジェクトでは機能数が増えることを想定し、検証のため3つほどの機能を持つプロジェクトを作成。
簡単な社員検索システムを想定して、3つの機能設計書を登録。

画面設計書_メニュー.xlsx
画面設計書_社員検索.xlsx
画面設計書_社員登録.xlsx

全量ではなく機能単位で確認しながらコード生成できるのは良い

ここでは3つまとめて出力。

機能単位で順次生成が進み…（この順序は設計書の登録順かしら？）

無事生成できたので、生成されたコードをファイル出力。
ファイル出力も機能単位で行うのですが…

異なる機能で同名のファイルが生成されたようでており、上書き処理のメッセージが。

これは私のやり方は間違っていたのかもしれませんが、やはり機能数が大規模なプロジェクトではこのあたりの整合性の問題が気になるところ

設計書の不備

現状のフローでは設計書自体は依然として人間が書くことになります。
もし設計書に不備があった場合、AIはその不備をどのように扱うのか？

ロジックの重複

CodeAGI ではフレームワークとして Spring を利用した場合、単項目チェックはアノテーションベースで実装される。
例えばこの項目定義書だと

以下のようなアノテーションを付けてくれる。

ここであえてアクション定義にも同じような単項目チェックを書くとどうなる？

さすがにそのまま実装されていました。
（むしろここでは全角文字チェックが抜けていることが気になる…）

よって今までと変わらず 設計書自体の品質は重要 だと再認識。

スペルミス

上記はちょっと無理のある設定だったので、もっと単純にスペルミスはどうでしょうか？

例えば user というスペルをあえて uesr に間違ったテーブル定義を登録します。

この場合はAIが自動的に user に修正してコード生成された。

もっと意地悪く hourly を horly にしたらどうなる？（uが抜けている）

こちらは Entity の変数名は horly と間違ったまま実装されていますが、メソッド名は getHourlyRate のように正しいスペルが使用されました。

ちなみにAIが user と自動的にスペル修正したことは一見うれしい話のようですが、もしDBのテーブルが意図的に Uesrs で作成されている場合には問題となります。

AIは設計書をそのまま実装してくれる保証は無いのでその前提で付き合う

複数メンバーでの開発

会社組織においては複数人でチーム開発することがメインとなるので

チームとしての規約やルールの適用
環境設定を含めたコードの生成
プロジェクトファイルの共有方法

チームとしての規約やルールの適用

AIによって生成されるコードには統一的な記載ルールが適用されないため、機能によってコメント有無やコーティングスタイルが異なる可能性あり。

例えば対応策としては

生成コードを別途フォーマッタなどのツールで成形する
生成コードに対しては規約やルールは適用しない

コード生成時に規約を反映させたり、独自のプロンプトをユーザが指定できる仕組みなどがあれば解決につながるかも

環境設定を含めたコードの生成

生成されたコードを実際に動かすためには、少なくともDBや依存ライブラリの準備が必要。
複数メンバーいる場合にはその作業もメンバー毎に実施する必要があることも。

DBのセットアップスクリプトや、ビルド設定（Javaなら ant, maven, gradle など）の関連ファイルも出力されると便利？
と言いつつ、DDLなどはテーブル定義書から機械的に生成するほうが確実

プロジェクトファイルの共有方法

今回も公式の提供サンプルを利用させていただく際に、プロジェクト設定（OSやフレームワークなど）をどう選択すれば良いかが分からなかった。

プロジェクト設定をエクスポート／インポートできると他メンバーと設定内容の共有がしやすい

保守運用フェーズ

保守運用フェーズでのコード生成を考えると、バグ修正や機能追加といったシステム改修がメインとなる。
その場合には修正箇所以外は変更しない、既存機能に対する影響度の少ない変更方式の採用などの考慮が必要となる。

ところで公式提供のサンプルでは設計書だけでなく生成コードも提供されており、以下の処理は

次のように生成されていた。

一方で私が手元でコード生成した結果、設計書の項番（1.1など）がコメントにも反映されており、個人的には設計書とコードの対応関係がわかりやすいと感じた。

上記の違いが発生している原因は不明だが、このような保守性の高いコードを安定的に生成したい

独自フォーマット

CodeAGI は多用なフォーマット対応が大きな魅力。
実際に社内で利用している設計書は公開できないので、私が独自に作った以下のようなデータ定義書を読み込ませた。

結果、ヘッダ、デザイン、付加情報という形で正しく読み込まれているよう。（各情報が生成にどのように利用されているかは不明ですが）

もちろん極端に不明瞭な設計書は読み込めないが（それは人間が読むことも困難）、ある程度は既存のフォーマットにも対応できそう

まとめ

CodeAGI を実際に利用してみての感想をまとめました。

小規模なシステムであれば現状でも用途によっては利用可能で、作業の省力化につながると感じました。

もちろん実際の開発を想定とするといくつか課題があるのも事実ですが、これらの課題は LLM の性能に依存する部分も多く、今後の性能向上により解消される部分もあると思われます。

いずれにしてもAIという性質を理解する必要性、AIを利用した開発のあり方など、私自身も改めて考える機会にもなった。

ちなみに現在は CodeAGI だけでなく、GPT-4o のモデルも無料で使えるキャンペーンも実施されているようです