Gemini や ChatGPT などの生成AIは、私たちの日常に欠かせない存在になりつつあります。
何気ない会話の相手として、調べ物のアシスタントとして、あるいは文章作成やアイデア出しのパートナーとして。わずか1、2年前までは「少し賢いおしゃべりアプリ」という印象もありましたが、今ではその高度な思考能力に驚かされる場面も少なくありません。
Embarcadero がリリースした AI アドオン「Kai」も、こうしたAIの進化とともに誕生したツールと言えるでしょう。Kai については、先日のウェビナーもぜひご覧ください。
📺 ウェビナーまとめ『 Delphi / C++Builder / RAD Studio向けAIエージェント「Kai」とは 』
実際、Kai を試している中でも、RAD Studio の IDE 上でコードが書き込まれ、プロジェクトツリーに新しいファイルが追加されていく様子は圧巻ともいえます。
ぼんやりとRAD Studioを眺めているだけなのに、開発作業が目の前でものすごいスピードで進行し、勝手にデバッグが始まったときなど「これ、どういう仕組みなの？」と唖然とすることもありました。
Kai はまだ登場したばかりであり、その可能性については未知数な部分も多く残されています。
そこで今回は、Kai を使用した RAD Studio（Delphi / C++Builder）でのアプリケーション開発シナリオを用意し、その実力を検証してみました。
その結果は予想以上のものです。ぜひ最後までご覧ください。
※ ご注意：本記事で紹介する結果および性能は、OpenAI Codex を利用し、Plus プラン契約環境で検証したものです。そのため、他の AI サービスや異なる契約プランを利用した場合、同等の結果が得られない可能性があります。
Table of Contents
Kai / 使う前に知っておきたいこと
Kai を使用した事例をご紹介する前に、利用前に知っておきたいポイントを簡単に整理します。
✅ Kai は RAD Studio（Delphi / C++Builder）バージョン 12 以降で利用できます。なお、 Community Edition は対象外です。
✅ Kai 本体は GetIt または My Embarcadero から入手できます。ご利用にはライセンスが併せて必要です。
✅ OpenAI Codex など、利用する AI サービスのアカウントは別途用意する必要があります。
AI モデルや契約プランの選び方
Kai を利用するにあたっては、使用する AI サービスを選択する必要があります。では、どの AI モデルや契約プランを選ぶのがよいのでしょうか。
選択の基準になるのは、「Kai で何を行いたいか」と「それがどれくらいの作業量になるか」です。これらを明確にし、規模感を把握したうえで、利用する AI サービスや契約プランを検討します。
目安としては、以下のように考えると分かりやすいでしょう。
(※ 今回の検証を通じて感じた目安であり、Embarcadero から提示されている公式な推奨条件ではありません。)
使用するAIサービスや契約プランの選択の基準
✅ 簡単な相談や部分的なコード作成 → 無料プランや軽量なローカルモデルでも十分な場合があります。
✅ 総合的な開発作業 → AI サービス側の使用量が増えるため、有料プランの利用も検討すると安心です。
図は、Codex（OpenAI）の無料プランを使用した結果、月間利用制限に達したときのものです。この状態で Kai に指示を入力しても、処理は途中で中断してしまいます。
このように、作業の途中で月間利用制限に達してしまうと、Kai の利用を中断せざるを得ません。結果として、作業の進捗が中途半端な状態で止まってしまい、Kai を使って開発を効率化するという本来のメリットも得にくくなります。
今回のシナリオを検証するにあたっては、Codex（OpenAI）の Plus プランを使用しました。これは、ある程度画面数の多いプロジェクトを Kai でまとめて開発するためです。
Kai 検証のための開発シナリオ
今回想定するシナリオは「マスタ画面開発」です。
クライアントサーバー形式の業務アプリケーション開発では、多くの場合、「マスタ画面作成」が作業工程に含まれます。
マスタ画面には複雑な業務ロジックが含まれることは少なく、作業としては「単純作業」に近い性質を持っています。そのため、作業の難易度自体は決して高くありません。
しかし、マスタとなるテーブルの数が多い場合、その作業量は無視できないものになります。結果として、開発工程を圧迫する要因となるため、いかに効率よく進めるかが重要になります。
今回は、RAD Studio に付属している InterBase 用の dbdemos データベースに登録されている 16 テーブルをマスターテーブルに見立てます。
それぞれのテーブルに対して、一覧画面と編集画面を 1 セットとして作成し、合計でおよそ 30 画面規模のマスター管理アプリケーションを作成します。
ここで読者の皆様にお伺いします
もしあなたがプロジェクト管理者だったとして、16 テーブル × 2 画面のアプリケーション開発にどれくらいの工数を見積るでしょうか?
今回のシナリオでは、AI を使用しない場合の工数を 5 人日と設定しました。現場から苦情が来そうな、タイトなスケジュールかもしれません。
シナリオまとめ
その他、今回の開発シナリオや実行環境については以下のとおりです。
目的
- マスタ管理アプリケーションを開発する
開発シナリオ
- 事前準備で用意したプロジェクトにマスタ管理機能を実装する
- InterBase 15 の
dbdemosデータベースに登録されている全 16 テーブルに対し、「一覧」「編集」が行える画面を作成する - 各画面へ遷移するメインメニューを作成する
- 画面の実装には Kai のチャット機能を使用する
- Kai の作業完了後、アプリケーションを実行し、基本的な操作ができるかを簡単なウォークスルーで確認し、エラーが発生しないことをもって完了とする
- 単体テストや詳細なコードレビューは今回の作業には含めない（別工程と想定する）
事前準備
- Kai のインストールと使用する AI の選定
- InterBase 15のインストールと起動
- 新規 VCL アプリケーションの作成と保存
使用 IDE
- Delphi 13.1 Florence + Kai 1.0
使用 AI モデル
- OpenAI Codex(Plusプラン) GPT-5.5
ハードウェア
- Windows 11上に構築した仮想環境
- CPU: Core i7-12650H 2.69GHz(仮想プロセッサ:4)
- RAM: 8GB
- GPU: なし
OS
- Windows 11 Pro
画面イメージ
メニュー画面
一覧画面例(行をダブルクリックで編集フォームを表示します）
編集画面例
開発開始
図は、開発開始時の VCL デスクトップアプリケーションを新規作成した直後の状態です。右下には、作業時間を測定するためのストップウォッチを表示しました。
また、Kai のチャット欄には、今回実行するためのプロンプトを入力し、実行待ちの状態にしています。
以下のプロンプトを Kai に入力し、実行します。
|
1 2 3 4 5 6 7 |
"C:\Users\Public\Documents\Embarcadero\Studio\37.0\Samples\Data\dbdemos.gdb"のデータベースに登録されているすべてのテーブルをリスト表示、編集できるアプリケーションを作りたい 条件 ・ Unit1.pas をメニュー画面にして、各種テーブルのリストを表示するフォームにアクセスするボタンを配置する ・ 各テーブルのリスト表示フォームをダブルクリックすると、ダブルクリックしたレコードを1行表示するフォームにアクセスできる ・レコードを1行表示するフォームではレコードの更新・削除ができる ・メニューを表示する際にデータベース接続が正常であることをチェックし、接続できないときはエラー表示する |
図はプロンプトの実行中にタスクマネージャーで確認したコンピューターの負荷状況です。
CPU、メモリ、ディスクの使用率が大きく上下していません。
その後も定期的に状況を確認しましたが、操作に支障が出るような、いわゆる「重い」状態には至っていません。
実は10分で完成していました！？
図は、作業開始から 8 分 56 秒後の状態です。
Kai のチャット欄を見ると、新しいプロンプトを入力できる状態になっていることが確認できます。これは、Kai の作業が完了し、再び指示待ちの状態であることを意味します。
タイトルでは「45 分で完成」としていますが、この時点ではまだ 10 分も経過していません。
では、すでに作業は完了しているのでしょうか？
早速アプリケーションを実行してみたのですが、エラーが発生します。
この程度のエラーなら人間が修正したほうが早いかもしれませんが、今回はKaiに指示を出して対応します。
|
1 2 3 4 5 6 7 |
アプリケーションを起動すると次のエラーで停止する [Window Title] エラー [Content] Cannot connect to the database. Object factory for class {3E9B315B-F456-4175-A864-B2573C4A2304} is missing. 登録するには、ユニット [FireDAC.DApt] をプロジェクトにインクルードします [OK] |
先程のエラーは解消されましたが、また別のエラーが発生しています。以降、Kaiが修正したものを人間がチェックしていきます。
図は、21分経過した状態です。ついに要求通りの操作が実現できました！
メニュー画面からボタンをクリックするとそのテーブルの一覧を表示し、一覧のリストをダブルクリックするとその行の編集するフォームが表示されます。
（※ 後から気がついたのですが、「追加」ボタンがありませんね😅これはAIプロンプトに「レコードの追加」の機能を含めなかったことが原因と考えられます。)
ついに完成！……と行きたいところではありますが、作成されたプログラムを確認すると、いくつか気になる点があることに気付きました。作成されたプロジェクトを確認すると、プロジェクトは DbCommon、Unit1、UnitRecordEdit、UnitTableList で構成されていました。
Kai は、最初に入力したプロンプトどおりに作業を終えたといえます。しかし、作成された構成は、筆者が今回想定していたものとは少し異なっていました。
例えば、以下のような問題が発生するおそれがあります
- 各テーブルごとに実装したいバリデーションチェックや業務ロジックを追加しにくい
- 各マスタ画面ごとの個別の微調整を行いにくい
実務で利用することを考えると、全 16 テーブルに対応する「一覧」「編集」フォームがそれぞれプロジェクトに追加され、後から個別に機能の追加や変更を行える構成の方が望ましいと言えます。
次はこの問題点を解決するよう指示をします。
|
1 2 |
メニューのボタンは動的に作成するのではなく、DFMに書いて 同様にテーブルの分だけPAS,DFMを用意し、コントロールは動的に作成するのではなく、DFMに書いて |
そして完成へ
指示通りに各テーブルに対応した一覧と編集フォームが用意され、画面デザインも DFM ファイルに集約されています。ソースコードを確認するとまだブラッシュアップの余地がありますが、まずはこれをもって一区切りとできる程度の品質です。
もちろん、これで終わりではありません。この後、生成されたコードの妥当性や品質を確認し、最終的にコミットするかどうかを判断するのは人間の役割です。
ここまでおよそ 45 分。従来の手法では 5 日かかると考えられていた作業と比較すると、その効率の差は歴然です。
作業を終えての率直な感想
正直なところ、私は Kai をはじめとした IDE 統合型の AI アドオンには、少し懐疑的でした。
IDE にわざわざ統合しなくても、AI とやり取りするためのツールはすでに存在しています。また、Kai は有料のアドオンです。既存の AI クライアントで生成したコードをコピーして利用すれば、追加で費用を支払う必要はないのではないか？そう思っていました。
しかし、今回実際に Kai を使ってみて、その印象は大きく変わりました。
ネットミーム風に言えば、「そう思っていた時期が私にもありました」というやつです。
Kai は、IDE に統合されている強みをいかんなく発揮します。その効果は、今回の検証結果にも表れているように、「時間」という非常に分かりやすい形で現れます。
これまで 5 日かかっていた作業が、わずか 45 分でここまで進む。この時間短縮のインパクトを考えると、Kai は開発現場にとって十分に検討する価値のあるツールだと言えそうです。
Kai を使って節約できた時間を活用すれば、AI だけではカバーしきれないアプリケーションのコアな部分に注力することもできます。あるいは、思い切って 1 日休暇を取ってリフレッシュするのも良いかもしれません。
あわせて読みたい
- Kai for RAD Studio
- ウェビナーまとめ『 Delphi / C++Builder / RAD Studio向けAIエージェント「Kai」とは 』
- RAD Studio 向け AI エージェント『Kai』
- RAD Studio 向け AI エージェント『Kai』を利用するための事前準備
Reduce development time and get to market faster with RAD Studio, Delphi, or C++Builder.
Design. Code. Compile. Deploy.
Free Delphi Community Edition Free C++Builder Community Edition
