CHUWI AuBox Ai365：私のAIホームラボがひとつの箱に収まった形です

CHUWI AuBox Ai365は、ごく安価なタブレットで知られるメーカーが販売しているミニPCですが、ほとんどの人がその存在を知らない製品です。このPCは通常はノートパソコンに搭載されるAMD Ryzen AI 9 365プロセッサを核としています。私のモニターの後ろに設置されており、チップ単体で4.6Wの消費電力しかありません。このPC上では6つのAIエージェントや家族用のチャットアプリ、メールの分類サービス、そして私が管理しているすべてのウェブサイトが動作しています。ここ数年で私が所有したハードウェアの中で最も「退屈」なものですが、前に使っていた機器と比べれば、この「退屈さ」こそが狙い通りなのです。ただし、大規模なAIモデルを実行することはできません。このページの後半では、そうした事実をどうやって知ったか、またそれに伴って何を別の機器に移行させたかについて記述しています。

完全な仕様詳細

構成要素	仕様
モデル	CHUWI AuBox Ai365（BIOS：AuBox_06）
CPU	AMD Ryzen AI 9 365 “Strix Point” — 10コア／20スレッド（Zen 5が4つ、Zen 5cが6つ）、最大動作周波数5.0 GHz、L3キャッシュ24 MB、製造プロセスは4nm
GPU	AMD Radeon 880M — RDNA 3.5アーキテクチャ、12つのコンピュートユニットを搭載、最大動作周波数2.9 GHz
NPU	AMD XDNA 2 — 性能は50 TOPS（プラットフォーム全体では73 TOPS）
メモリ	16 GB DDR5-5600 SODIMMを2枚搭載し、デュアルチャネル構成。利用可能なメモリ容量は30 GBで、最大96 GBまで拡張可能
メモリ帯域幅	128ビットバスを通じて約90 GB/s
ストレージ	1 TBのPCIe 4.0 NVMeドライブ。M.2 2280スロットが2つあり、現在は両方とも使用済み
有線LAN	Realtek RTL8125チップを2基搭載した2.5GbEポート
無線通信	Realtek RTL8851BE — Wi-Fi 6（802.11ax）およびBluetooth 5.3に対応
USB	40 Gbps対応のUSB4ポートが2つ（DP代替モードおよび最大100 Wの電力供給も可能）、USB 3.2 Gen 2 Type-Aポートが3つ
映像出力	HDMI 2.1、DisplayPort 1.4、そして2つのUSB4ポートを利用可能。最大4台のディスプレイに接続でき、8K60Hzや4K144Hzの表示も可能
オペレーティングシステム	Bluefin 44 — Fedora SilverblueベースのアトミックOS。GNOME 50.3がWayland上で動作します。初期設定時のLinuxバージョンは7.0.12、2026年9月15日時点では7.1.8にアップデート済み
電源	19 V / 6.32 A、120 W出力の円形プラグ式アダプター
外形寸法・重量	140 × 139 × 55 mm、重量は846 g。全金属製でファンが1つのみ。VESA規格に準拠しており壁掛けも可能
価格	定価は899ドル。私が購入した際の支払額は約900ドルでした

なぜこのボックスなのか

以前使っていたホームラボ用マシンは、128GBの統合メモリを搭載したゲーミングタブレット「ROG Flow Z13」でした。2026年7月頃から電源に不具合が生じるようになりました。起動してロゴ画面で停止し、約30秒後に自動的にスリープ状態になるのです。詳細な原因調査の記録はこちらにあります。要するに、ブートローダーに到達できないため、ソフトウェア上で私ができることは何もなかったのです。

そのため、かなり具体的な仕様条件が必要となりました。少なくとも32GBのRAMを備えたLinuxホスト、ローカルでの画像処理用に十分な性能を持つGPU、有線ネットワーク機能が必要でした。また、バッテリー駆動型マシンが電源管理で失敗するのを見たことから、重要な処理経路においてはバッテリーもUSB-PDの通信も不要であることも条件としました。さらに、バレルコネクタとファンも必要でした。

このボックスの特異な点は、Strix Pointデスクトップであるということです。Ryzen AI 9 365はノートパソコン向けのチップであり、ThinkPadやOmniBookなどに搭載されています。140mm角の金属製筐体に2つの2.5GbEポートと2つのUSB4ポートを備えるという構成は、規模の小さいOEMメーカーが何か珍しいものを作るときにしか考えられない仕様です。まさにこの「珍しさ」こそがホームラボに求められる要素なのです。つまり、ノートパソコン並みの省電力性、デスクトップ級の電力供給能力、そしてサーバー並みのネットワーク機能が得られるのです。

このハードウェア上でのLinux

本来なら苦労すると予想していた部分ですが、実際にはそうではありませんでした。箱に同梱されているすべてのデバイスが、標準のFedoraカーネル内にあるドライバーによってサポートされています。サードパーティ製のリポジトリもなければ、DKMSモジュールも存在せず、私の設定の中にもGPU関連の環境変数の上書き設定は一切ありません。

デバイス	ドライバー	Linux 7.0.12での動作状況（7.1.8でも再確認済み）
Radeon 880M (gfx1150)	amdgpu	正常に動作します。strix1として認識され、特別な上書き設定は不要です。
RTL8125 2.5GbE×2	r8169	両方とも検出され、問題なく動作しています。モジュールパラメータも不要です。
RTL8851BE Wi-Fi	rtw89_8851be	6.5以降のメインラインカーネルでサポートされています。動作はしますが、下記の注意点にご留意ください。
XDNA 2 NPU	amdxdna	6.14以降のカーネルでサポートされており、/dev/accel/accel0として認識されます。
USB4	thunderbolt	正常に動作します。

Wi-Fiに関する注意点をはっきりと述べておく必要があります。CHUWI自身のマーケティング情報ではその点が曖昧であり、私が見つけた仕様書では「Wi-Fi 7」と記載されていました。しかし実際にはそうではありません。RTL8851BEはWi-Fi 6、シングルストリーム、6GHz帯非対応のモジュールです。802.11axコントローラーとして認識され、実際の通信速度はおよそ300～400Mbps程度です。このマシン内で最も性能が低い部品と言えます。またこれはM.2 2230 A/Eキーのカードなので、Wi-Fi 7を求める場合はMediaTek MT7925に交換することも可能です。ただし私の場合は有線の2.5GbEを利用しているため、Wi-Fiインターフェースは単純に無効化しています。

特にBluefinについて

ここでは意図的にBazziteではなくBluefinを選びました。両者ともublueベースの仕組み（イメージベースのrpm-ostree、Flatpak優先、不具合が生じた更新も再起動1回でロールバック可能）を採用していますが、Bluefinはゲーム向けにパッチが適用されたカーネルではなく、標準のFedoraカーネルを追跡します。最新ハードウェアとしてNPUが搭載されており、そのドライバーもまだ発展途上であることを考慮すると、アップストリームのカーネルを追う方が安全だからです。このOSは署名済みのイメージとして提供され、正常に起動するかロールバックされるのみなので、半分だけ適用された更新や誰も覚えていない手作業での編集内容などが存在しません。こうした問題こそが、家庭用サーバーを再起動するのが怖くなる原因となるのです。ただしその代償としていくつかの注意点も存在します。

実際に動作しているもの

すべてが systemd --user サービスとして実行されており、失敗した場合には自動的に再起動します。コアスタック部分ではDockerは使用せず、監視用スクリプトもなく、停電後も手動での再起動は一切不要です。

サービス	役割
エージェントゲートウェイ	各メッセージを適切なエージェントに転送し、そのツールを実行したりセッションを維持したりします。通信はループバックのみで受け付け、チャットアプリが唯一の入り口となります。
家族用チャットアプリ	DisPatch。家族全員がスマートフォンやタブレットから利用するチャットです。
小型ローカルモデルサーバー	2026年9月16日に廃止されました。現在は埋め込み表現の生成や小規模なフォールバックモデルもGPUマシン側から提供されています。
メール振り分け処理	MailForgeが3つのメールボックスを読み取り、返信文を作成します。ただし自動的に送信することはありません。
夜間バックアップ処理	午前2時に Borgスナップショットが作成され、ゲートウェイの設定やエージェントの状態も保存されます。さらに午前2時30分には日付付きのミラーデータが第2のSSDにも書き込まれます。
システム監視機能	15分ごとにGPUマシン上の画像処理バックエンドが正常に動作しているかを確認し、異常があればチャットへ警告を送信します。

なぜ一部の機能をこのマシンから外したのか

7月にこのマシンを設定した際には、プライベート用エージェント向けに35B規模のミックスド・オブ・エキスパーツモデルをローカルで動かし、フォールバック用として画像生成機能も備えていました。しかし両者が30GBものメモリを奪い合う状態でした。8月15日にはエージェントが利用するすべてのローカルモデルがGPUを搭載した別マシンへ移行し、8月26日にはこのマシンから画像生成機能も完全に取り除かれました。つまりGPUマシンがダウンしている場合は画像生成ができなくなります。それ以外の偽装は一切ありません。

この構成を真似する方へ私が推奨するルールはこうです：ホストマシンは強力である必要はなく、信頼性が求められます。インタラクティブな処理には速度が重要なためクラウドモデルを利用し、プライベート用途や大量処理には十分なメモリ帯域幅を持つハードウェア上のローカルモデルを使うべきです。このようなミニPCはゲートウェイやチャットアプリ、スケジューリングには最適ですが、モデルの実行には不向きです。

エージェントの役割

2026年9月6日現在、このシステムには6つのエージェントが存在します。以前はアイデアごとに1つずつエージェントを増やしていったため、その数はもっと多かったのです。

• リードエージェント：すべてのリクエストを受け取り、どのエージェントが作業を行うかを決定し、結果を確認します。クラウドモデル上で動作します。
• ワーカーエージェント：自身の記憶を持たず、各ジョブごとに適切なモデル（高速型、思考重視型、長文対応型、あるいはGPUマシン上のローカルモデル）を使って起動します。複数の専門化したエージェントの代わりとなっています。
• レビューエージェント：別のクラウドモデル上で動作し、完了した作業や外部へ送信される予定の内容を最終的にチェックします。
• ペルソナエージェント2体：GPUマシン上のローカルモデルで動作するため、会話内容は原則として自宅内に留まります。クラウドモデルは最終的なフォールバック用にのみ利用されます。
• 家族向け安全ボット：家族の各端末からの問い合わせを受け付け、情報検索や回答を行います。ただしファイル操作やコマンド実行はできません。

チャットアプリ側で「家族向け安全制限」がエージェント設定とは別に適用されているため、一方の設定ミスが他方へ影響することはありません。クラウドとローカルの使い分けに関する理由については コスト内訳 をご覧ください。

メッセージがシステム内をどのように流れるか

信頼性を確保するためには主に二つの仕組みが重要です。一つ目は、モデルが忙しい状態またはダウンしている場合でも、エージェントの次のモデルが応答することでリクエストが失敗しないようにすることです。もう一つは、ワーカーに割り当てられた各ジョブの結果をディスクへ記録し、45秒ごとに小さなタイマーがそれを取得してチャットへ送信する仕組みです。これにより、リクエストを出したエージェントが別の作業に移った後でも、処理結果が失われることがありません。どちらも特別高度な技術ではありませんが、これらがあればシステムは人間の介在なしで自動的に運用可能になります。

このシリコンにおける性能

消費電力。 これが私を最も驚かせた数値です。5秒間にわたってSoCパッケージの消費電力を測定したところ、フルスタックが稼働し負荷平均値が約2の状態で、チップの消費電力は4.6 Wでした。メインボードや2基のNVMeドライブ、RAM、NIC、ファンなどを加えると、コンセント側での消費電力はおそらく10 W程度と見積もられますが、実際に電力計で測ってはいません。<5 W未満で全エージェントスタックを動作させられるという事実こそが、Zen 5c効率コアがもたらすメリットの最も明確な証左です。アイドル時の温度はTctlで約40℃程度です。

CPU。 5 GHzに達する4基のZen 5コアと、6基のZen 5c効率コアが搭載されていますが、このワークロードにはそれ以上は必要ありません。エージェントのルーティング処理は負荷平均値には全く現れず、マシンはほとんどの時間をほぼアイドル状態で過ごしますし、1メートル離れた場所からでもファンの音は聞こえません。

ローカル推論処理。 ここがこのマシンの本当の限界となりますが、それは計算能力よりも帯域幅の制限です。Radeon 880Mには12基のコンピュートユニットがあり、メモリ帯域幅は約90 GB/sです。比較として、Z13には40基のCUがあり256 GB/sの帯域幅を持ちますし、私が使っているGPUマシンに搭載されているカードではそれぞれ約1.8 TB/s（RTX 5090）および0.9 TB/s（RTX 3090）の帯域幅があります。トークン生成速度は帯域幅に依存するため、8月15日にはエージェントが利用するすべてのモデルがそのGPUマシンへ移行しました。現在このマシンではいかなるモデルも実行されておらず、小規模なモデルも9月16日に他の全てと共にGPUマシンへ移されました。

NPU。 XDNA 2 NPUは/dev/accel/accel0として正常に認識されていますが、現時点では何も行いません。50 TOPSという性能自体は実際のものですが、「NPUがある」という状態から「エージェントスタックがそれを利用する」という段階までのソフトウェアパスは、長いコンテキストウィンドウや高度なツール呼び出し機能が必要な私が関心を持つモデル向けにはまだ存在しません。将来的に活躍できる可能性があるのは、メール検索用の埋め込みベクトルエンドポイントの提供や、どのメールを本格的なモデル処理対象とするべきかを判定する一次分類器といった、小規模で固定化されたタスクでしょう。このNPUがなくてもマシンは問題なく動作します。

ネットワーク機能。 2つの2.5GbEポートは設定なしで問題なく動作します。一方はネットワークに接続されており、もう一方は予備用となっています。

私が犠牲にしたもの

この変更による実際のコストはメモリです。それも決して小さなコストではありません。Z13には128GBの統合型LPDDR5Xメモリがあり、そのうち64GBをVRAMとして確保し、1200億パラメータを持つモデルをローカルで実行していました。一方、今回のマシンでは利用可能なメモリは合計30GBだけで、これがOSやその他すべての用途で共有されています。

そのため、このマシンでは1200億パラメータ規模のモデルはもう実行できなくなりました。最初の数週間は代わりに350億パラメータ規模のミックスド・オブ・エキスパーツ型モデルをここで動かしていました。これも実際に役立つ本物のモデルではありますが、規模や性質は先ほどのものとは異なります。8月15日以降は、ローカルモデルの処理は別のGPUマシンで行われており、これがメモリ不足問題に対する実際の解決策となっています。本サイトの以前の記事では自宅のラボ環境で1200億パラメータ規模のモデルを動かしていると書いてありますが、それはZ13の時の話であり、現在はそうではありません。

その代わりに得られた利点こそが、今回の変更が行われた主な理由です。バッテリーの劣化の心配がなくなり、負荷下でのUSB-PDのネゴシエーションも不要になり、Modern Standby状態でクラッシュするリスクもなくなりました。このマザーボードには2つのSODIMMスロットがあり、最大96GBまでメモリを増設することも可能です。そうすれば以前の水準に近づくこともできるのですが、私はそうしません。なぜならDDR5 SODIMMの価格は私がこのマシンを購入した時よりも大幅に高騰しており、容量を増やしても帯域幅は向上しないからです。実際、ここでは帯域幅こそがローカルでの推論処理を制約する要因となっているのです。

Z13のSSDは今、ここに収まっています

個人的に気に入っている点があります。Z13でユーザーが交換可能だった部品といえば、スタンド部分の扉の裏にあるSSDだけでした。このSSDは無事に取り出され、2230用から2280用へのアダプターブラケットを介して、現在はこのケースの2番目のM.2スロットに取り付けられています。

このSSDにはバックアップデータが保存されています。毎晩02時30分になると、その時点でのマシンの状態を日付付きでこのドライブに記録しているのです。もともとは本体自体だったこのドライブは、今では後継機が元の状態に復元できるよう手助けをしています。また、故障する前日に作成された古いシステム全体のイメージもまだ保存されており、そのおかげで移行作業は再構築ではなく単なるコピーで済んだのです。

費用について

項目	金額	備考
本体	一度きりで約900ドル	定価は899ドル。32GBメモリ＋1TBストレージの構成です。
電気代	月々数ドル程度	24時間365日稼働するとした場合、消費電力は約10Wと見積もっています。実際にはメーターで計測されていません。
クラウドモデル利用料	2026年8月30日以降、税込みで月額約60ドル	リードエージェントおよびワーカー用の定額プランであり、それに加えて若干の従量課金もあります。実際に毎月口座から引き落とされた金額（6月242ドル、7月225ドル、8月385ドルなど、他のサービス料も含む）については、詳細な費用内訳をご覧ください。
ローカルモデルの利用料	追加費用は0ドル	既に所有しているハードウェア上で動作します。GPUマシンの消費電力分はここには含まれていません。

本体自体は比較的安価な部分です。実際に費用がかさむのはクラウドモデルの利用料であり、作業負荷の増加に伴って従量課金制になったため、定額プランが解決策となりました。

注意点

実際に私が苦労した点を、解決に要した時間の長さ順に挙げます：

• 30 GBという上限は本当です。 公称32 GBからファームウェアやiGPUが使用する分を引くと、free -hで確認できる空き容量は30 GBしかありません。ローカルでの画像生成処理と、中規模なローカル言語モデルを同時に稼働させることはできませんでした。対策：両方とも実際にGPUがあるマシンに移すことです。
• リモートバックエンドが静かに失敗することがあります。 9月2日には、GPUマシン上の画像処理用バックエンドが約14時間ほどダウンしていましたが、このマシンからの要求がなかったため誰にも気付かれませんでした。対策：15分ごとに状態をチェックし、再起動を試みた上で警告を送信する仕組みを設けることです。
• メモリ不足時にローカルモデルサーバーがクラッシュします。 AppImageではメモリが逼迫すると一時的なマウント領域が再利用され、プロセスは「メモリ不足」として適切に終了する代わりにバスエラーを起こしてしまいます。対策：AppImageではなく、systemd経由で展開済みのコピーを実行することです。
• タイムアウト設定はクラウド環境の速度を前提としています。 大規模なローカルモデルは動作が遅いだけで、何ら問題はありません。しかしゲートウェイの既定のタイムアウト設定では、処理中に途中で中断され「応答が止まった」と誤認されてしまいます。対策：タイムアウト値を「リクエスト→処理開始→中断」という順序で段階的に引き上げるか、あるいは失敗が発生する箇所を別に設定することです。また推論用モデルであることも明示しておく必要があります。そうしないと思考中にもかかわらず「応答停止」と判断されて中断されてしまいます。
• エージェントIDの扱いがコードによって異なります。 あるコードパスではエージェントIDが小文字化される一方で、別のパスではそうなりません。そのため許可リストに小文字のエントリを追加するまで、エージェント間通信が静かに失敗していました。エラーもログも出ず、単にメッセージが届かないだけでした。対策：すべてのエージェントIDを常に小文字で統一することです。
• アトミック更新処理ではマシンが再起動します。 更新内容は新たなデプロイメントとして準備され、再起動後に初めて有効になります。作業中にこの再起動が発生すると処理が中断してしまいます。対策：更新は私が定めたスケジュールに従い、負荷の少ない時間帯に行うようにしています。
• システム用のパッケージマネージャーがありません。 ベースとなるOSに自身をインストールしようとするソフトウェアの場合、コンテナやFlatpak、あるいはユーザーレベルでのインストール手段を利用する必要があります。
• 古い設定が引き継がれてしまいます。 移行処理の際に旧マシンのバックアップから古い認証情報ファイルが再導入され、ゲートウェイがクラッシュループ状態になってしまいました。正常に動作していたシステムを復元しただけでは正しい設定にはなりません。対策：生成された設定ファイルだけでなく、元となるソースファイルも修正する必要があります。

私が変更したい点

• もしWi-Fiを使うなら、もっと良いものにしたい。 シングルストリームのWi-Fi 6カードが唯一本当に弱い部分です。これは交換可能なM.2 2230 A/Eキーの部品なので、15分程度で交換できます。ただし有線ネットワークを使っているため、今のところ交換する必要はありません。
• もう少しメモリが欲しいかもしれない。 2つのSODIMMスロットに合計96GB搭載すれば、Z13で持っていたメモリ量が復活します。ただし他のマシンでも同様の構成があり、現在のRAM価格を考えると、もはや必要ないと判断しています。
• ファームウェアの更新方法が謎です。 このモデル用の公開されたBIOSダウンロード先がありません。入手するにはメーカーに型番とシリアル番号を記載してメールを送り、運を天に任せるしかありません。これがマイナーモデルを購入する際の代償ですね。
• NPUには何らかの役割が必要だ。 50 TOPSもの処理能力を持ちながら何もしていないのはもったいないことです。まずは埋め込みベクトルを生成するエンドポイントとして活用するのが最適でしょう。

総評

私なら再び購入します。速いからというわけではありません。実際、特別速いわけでもないのですが、常時稼働するホームラボ用ホストとして必要な機能をすべて備えており、不要な機能は一切ありません。サイズは小さく静かで、消費電力も少なく、故障し得る可動部品はファンが1つだけです。メインラインのLinuxを、カスタムドライバーなしで問題なく動作させ、サンドイッチほどのサイズの本体には2つのイーサネットポートと2つのUSB4ポートも備わっています。

以前使っていたマシンから得た教訓としては、故障しやすい高性能なハードウェアよりも、堅実で長く使える平凡なハードウェアの方がインフラにとって価値があるということです。7月から9月にかけて、このマシンを取り巻くシステム環境は大きく変化しました。しかし、そのマシン自体は何も特筆すべきことはしていません。それこそが私からの最高の賛辞だと言えます。

変更履歴

日付順に記録しており、最新の内容が最後に記載されています。これは変更内容の記録であり、定期的な更新を保証するものではありません。

日付（2026年）	内容
7月29日	ゲートウェイの自己修復機能をイベント駆動型に改修しました。つまり、サービスが実際に障害状態になった場合にのみ救急処置ユニットが作動し、意図的なシャットダウンに対しては3回までしか試行せずそれ以上は諦める仕様となりました。以前、エージェントがゲートウェイを停止させて一晩中ダウンしたことがありました。
7月30日	リモートアクセス用に2つの別々の入口を用意しました。1つは冷起動時のログイン画面用、もう1つは実際のデスクトップセッションをミラーリングするためのものです。認証情報の保存場所もそれぞれ異なるため、片方で障害が発生してももう片方へのアクセスが阻まれることはありません。
7月31日	ゲートウェイの監査を行いました。あるパスではエージェントIDが小文字化されていましたが、ディレクトリ上のオーバーライド設定ではそうなっておらず、その結果1つのエージェントのメモリ情報が別のディレクトリに誤って保存されていました。このオーバーライド設定を削除しました。
7月31日	古いマシンのSSDをバックアップ用として2つ目のM.2スロットに取り付けました。毎晩02:30に、02:00に行われるBorgスナップショットの後に日付付きのミラーバックアップが実行されます。
7月31日	画像生成処理をネットワーク上にあるGPUマシンへ移行しました。これにより、以前問題として指摘されていたメモリ競合の問題も解消されました。
8月1日	初めてSoCパッケージの消費電力を測定しました。全機能が稼働している状態で4.6ワット、アイドル時の Tctl 温度は40度でした。
8月15日	エージェントが利用するすべてのローカルモデルをGPUマシンへ移行しました。このマシンには埋め込み用モデルおよび小規模なフォールバック用モデルのみが残っています。
8月26日	このマシンからローカル画像生成機能が完全に削除されたことが確認されました。現在は画像データはすべてGPUマシンから提供されており、ローカルでのフォールバック機能は存在しません。
8月30日	従量制課金が増加したため、メインのエージェントを定額制のクラウドプランへ移行しました（税込みで月額約60ドル）。
9月2日	GPUマシンの画像生成バックエンドが約14時間にわたって停止していましたが、誰にも気付かれていませんでした。そこでこのマシンには15分ごとの監視機能を追加しました。
9月6日	エージェントの構成を6体に改め、そのうち1体は柔軟な作業を行うワーカーとしました。完了したジョブの報告も45秒ごとのタイマーによって自動投稿されるようになりました。
9月9日	チャットアプリで使用されていた古いターミナルコーディングアシスタント機能を廃止しました。
9月15日	OSイメージをBluefin 44（20260915）およびLinux 7.1.8へ更新しました。これまでと同じ5つのドライバーが読み込まれ、NPUのパスも /dev/accel/accel0 のままです。
9月16日	このマシンからローカルモデルサーバー機能を削除しました。現在は一切のモデルを実行しておらず、埋め込み用データもGPUマシンから取得しています。
9月16日	現在の構成に合わせてこのページの内容も修正しました。

関連情報：ROG Flow Z13の事後検証記録（本マシンが置き換えた機器）、私が運用しているOpenClawエージェントスタック、DisPatch（このマシンで稼働するチャットアプリ）、StudioForge（ローカルモデルが移行されたGPUマシン）、および エージェント運用にかかる実際のコスト。