2026年5月に初版がリリースされた RAD Studio 向け AI エージェント Kai は、RAD Studio による開発に新しいワークフローを提案するツールとして注目を集めています。筆者もこの Kai の便利さや効率性を日々体感している一人です。
Kai の特徴のひとつは、作業に使用する AI モデルをユーザー自身が選択できる点にあります。Gemini や Codex などのクラウド AI サービスを利用できるのはもちろん、Ollama や LM Studio といったアプリケーションを使用して、ローカル LLM を利用することもできます。
ローカル LLM を利用するメリットは、ソースコードやプロジェクト等の情報を外部へ送信せずに済むこと、そしてクラウド AI サービスとの契約が不要で、その利用料金を抑えられることが挙げられます。このように、自分のローカルネットワーク環境で LLM を利用できるのであれば、さまざまなメリットがあるように見えます。
しかしながら、実用的なローカル LLM 環境を構築しようとすると、それなりの GPU やメモリが必要になります。近頃は、高性能な GPU と潤沢な RAM を搭載したコンピューターは非常に高額です。
今回の検証は、そんな背景から始まりました。
「では古いパソコンをローカル LLM サーバーにできないか？」という疑問です。
結論から言えば、2018年に購入したパソコンでも Kai 用のローカルLLM サーバーとして動作はしましたが、実用性には課題が残る結果となりました。
また、検証結果以外にも、LM Studio を使ったローカルLLM 環境の構築手順についても紹介しています。ぜひ最後までご覧ください。
Table of Contents
検証環境
ローカル LLM を実行するコンピューターのスペックは以下のとおりです。
本体: 2018年購入 Windows デスクトップPC
OS: Windows 11 Pro
CPU: Intel Core i7-8700K (3.7Ghz, 6コア, 12スレッド)
GPU: NVIDIA GeForce RTX 2080 (VRAM 8GB)
RAM:16GB
なお、RAD Studio(Kai) の環境は別のコンピューターに用意します。
ローカルLLMの選定
ローカル LLM 構築・検証にあたっては、まず LLM(Large Language Model) の選定が必要になります。
現在、私たちが利用できるLLMにはさまざまなものがあります。その中から、どれを選べばよいのでしょうか。
AI の世界は日進月歩以上のスピードで進んでいるため、この記事で特定のモデルを推奨しても、すぐに古い情報になってしまう可能性があります。そのため重要なのは、「いま、どのような選択肢があるのか」を確認し、その中から目的と環境に合ったものを選ぶことです。
今回の検証では、ハードウェアのスペックが決して高いものではないことも考慮すべき条件になります。いくら優秀な LLM であっても、手元のハードウェアで実行できなければ利用できない恐れがあるためです。
そこで今回は、ハードウェアに合った LLM を探すために、llmfit というアプリケーションを利用しました。llmfit は PowerShell で動作し、実行中のコンピューターに合う LLM をリスト化してくれます。
※インストール方法や利用方法については割愛します。興味がある方は公式サイトをご覧ください。
今回は、検証用のモデルとして Gemma 4 12B を使用します。
補足
今回使用する LM Studioでも、選択した LLM が実行環境のハードウェアに適しているかどうかが簡易的に確認できます。図では「Likely too large」と表示されており（赤枠内参照）、実行中のハードウェアには適していない可能性が高いことが分かります。
検証内容
Kai を用いたローカル LLM の評価は、以下の内容で行います。
① Kai のチャットを使用してコーディングを行う
②コーディングが完了するまでの時間を記録する
③完了したコーディングの内容を評価する
この結果をもとに、今回の環境でローカル LLM サーバーとして現実的に利用できるかを検討します。
LLM環境の構築
ローカル LLM 環境には LM Studio を選択しました。図は、LM Studio をインストールした直後の状態です。
LM Studio でローカル LLM を利用するには、使用するモデルを取得し、ロードする必要があります。そのためには、左のサイドバーにある Developer タブをクリックします。
図は Developer 画面です。中央に Status: Running と表示されています。これは、LM Studio が利用可能な状態であることを示しています。
また、Reachable at: に続く URL は、Kai から接続する際に使用する URL です。LANからリクエストを受け付けたい場合は Server Settings > Serve on Local Network を有効にします。
次に、LM Studio で使用するモデルを取得し、ロードします。+ Load Model をクリックしてモデルを選択します。今回は、google/gemma-4-12b を選択しました。
モデルをロードできたので、Kai からアクセスしてみます。
図の通り、接続テストに成功しました。次にチャットも試してみます。しかし、ここでエラーが発生しました。エラーの内容を確認すると、コンテキスト長が不足していることが分かります。
|
1 2 3 4 5 6 7 |
予期しないエラーが発生しました: -32603: Internal error; stream disconnected before completion: The number of tokens to keep from the initial prompt is greater than the context length (n_keep: 15324>= n_ctx: 4096). Try to load the model with a larger context length, or provide a shorter input. 訳:予期しないエラーが発生しました: -32603: 内部エラー。完了前にストリームが切断されました。 初期プロンプトから保持するトークン数がコンテキスト長を超えています（n_keep: 15324 >= n_ctx: 4096）。 より大きなコンテキスト長でモデルを読み込むか、入力を短くしてください。 |
図のようにコンテキスト長をデフォルトの 4096 から 32000 に変更し、Reload to apply change ボタンをクリック、モデルを再ロードした後に再度チャットを行います。
今度は Howdy! と、AI もテキサス風の挨拶を返してくれました。
Kai チャットの検証
次に、簡単なコーディングを指示したいと思います。Delphi で新規コンソールアプリケーションを作成したら、Kai のチャットウィンドウを表示させます。
また、応答時間を計測するためタイマーを用意しました。
プロンプトの内容は以下のとおりです。これを Kai に入力し、送信します。
|
1 2 |
@project1.dpr コンソールに Howdy partner!と出力して プログラムの最後で readlnして結果を確認できるようにもして |
図はプロンプト実行中の LLM サーバ側の状態です。
メモリの使用量が限界に達し、GPU の負荷も一気に上がったままです。
図は、Kai 側の処理が終了し、再びプロンプトの入力待ちとなった状態です。
WriteLn と ReadLn の2行がKaiによって追加されました。（WriteLn のインデントがズレているのは御愛嬌ということで・・）
しかしながら、問題点もあります。それは致命的に遅いということです。 タイマーを確認すると2行のコードを書くのにおよそ7分を要しました。
次の図は、同じ要求をCodex (クラウドAI)に行った結果です。わずか28秒です。
この差はどこから来るのでしょう？ まず考えられるのは AI モデルやハードウエアの性能かもしれません。
Codex 等のクラウド AI は専用のハードウエアを備え、世界中からくる無数のリクエストを受け止める性能を備えます。それに対し、2018年に発売された「たまたまGPUを搭載していた」デスクトップPCにとっては荷の重い作業であり、そもそも比較することすら意味のないことなのかもしれません。
条件を変えてみる
では、少しでも快適に使用する方法はあるのでしょうか？google/gemma-4-12b が要求するハードウエア仕様は、テストに用いたコンピュータにとって無理のあるものだったのかもしれません。
そこで次は、すこし軽いモデルとして google/gemma-4-e4b を使用してみます。応答時間は短くなったものの、結果は期待したものではなく、とても実用的であるとは言えないものでした。
これはプロンプトを変えるなどしても結果は同様でした。
今回の検証からわかったこと
- 重いモデルは、プロンプトの指示を正確に実行できることが多い一方、使用するコンピューターの性能によっては処理の完了までに時間がかかったり、そもそもモデルをロードできなかったりします。
- 軽いモデルでは、指示の理解や実行の正確性に欠ける場合があります。
このように、モデルの性能と、それを動作させるために必要なハードウェアにはトレードオフがあります。そのため、ローカル LLM を利用する場合は、まず「Kai で何を実現したいのか」を明確にすることが重要です。
コンピューターのスペックに合わせてモデルを選び、その結果として Kai の利用範囲を制限してしまっては、本来の目的から外れてしまいます。まず目的に合った LLM を選び、そのモデルを動作させるために必要なコンピューターを用意する、という順序で考える必要があります。
Kai でローカル LLM サーバーを利用することは、クラウド AI サービスの利用コスト削減や、秘密保持の観点から有効な選択肢です。一方で、今回の検証を通じて、Kai を実用的に利用できるローカル LLM 環境を構築するには、相応のハードウェアや環境構築の労力が必要であることも分かりました。
そのため、最初から Codex や Gemini などのクラウド AI サービスを利用するほうが、現実的であるという見方もできます。クラウド AI サービスでは、最新のモデルをクラウド側の高性能なハードウェアで利用できるため、初期費用や環境構築の手間まで含めると、結果として費用対効果が高くなる場合もあります。
もちろん、これらは今回の検証環境と、その結果に基づく見解に過ぎません。
読者の皆様が保有するコンピューターや、利用を検討している AI モデルによっては、まったく異なる結果になる可能性もあります。
個人的には、今回のようなローカル LLM サーバーの構築は、筆者にとって AI に関する知見を広げるよい経験となりました。限られた環境の中で、最高のパフォーマンスを引き出せるものを探り当てていく。そんな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
