NemoClaw PoCとは何か――なぜ必要なのか
PoC（Proof of Concept：概念実証）とは、NemoClawが本番業務で機能するかを限定環境で検証するフェーズです。NVIDIAはNemoClawを現時点でアルファ版として提供しており、APIや設定スキーマが変更される可能性を公式に認めています。このためいきなり本番導入するのではなく、PoCで技術的実現可能性・業務フィット・費用対効果の3点を確認することが強く推奨されます。
NemoClaw固有のPoC検証ポイントは以下のとおりです。
- 推論プロファイルの選定：クラウド（Nemotron 3 Super 120B）・ローカルNIM・ローカル軽量（Nano 30B + vLLM）の3プロファイルは、精度・レイテンシ・コストが大きく異なります。実際の業務データで計測しないと最適解は選べません
- OpenShellポリシーの整合性：blueprint.yamlで定義するサンドボックスポリシーが、業務上必要なファイル操作・API呼び出しを適切に許可し、かつ不要な操作を遮断しているかを実動作で確認します
- インフラコストの実測：試算ではなく実際のトークン消費量・GPU時間を計測し、月間コストを確定させます
PoCで取得したレイテンシ・精度・コストの実測値は、本番投資判断（稟議書）の根拠として直接使えます。定性的な「使えそう」ではなく定量的な数字を出すことがPoCの最大の目的です。
PoC期間の目安――4〜8週間が標準
NemoClaw PoCの標準期間は4〜8週間です。業務の複雑度とスコープの広さによって変わります。下記の3パターンを参考にしてください。
| パターン | 対象業務の特性 | 標準期間 | 費用目安 |
|---|---|---|---|
| ミニPoC | 単一タスク・社内向け・評価データ整備済み | 2〜4週間 | 50〜100万円 |
| 標準PoC（推奨） | 2〜3タスク・社内外向け・データ加工必要 | 4〜8週間 | 100〜200万円 |
| 大規模PoC | 複数部門・複数システム連携・機密データ含む | 8〜12週間 | 200〜300万円 |
「標準PoC（4〜8週間）」を推奨する理由は、短すぎると評価データが不足して判断根拠が弱くなり、長すぎると競合他社に先行される機会損失が発生するためです。最初のPoC対象は「最もデータが揃っている、最もリスクが低い」業務を選ぶことが期間短縮のカギです。
4週間PoC（標準）のスケジュール例
| 週 | 作業内容 | 完了物 |
|---|---|---|
| Week 1 | 環境構築・blueprint.yaml初期設定・評価データ準備 | PoC環境稼働・ゴールドセット50〜100件 |
| Week 2 | エージェント実装・初回動作確認・ログ計測基盤構築 | エージェントv1動作確認・計測ダッシュボード |
| Week 3 | 精度・レイテンシ・コスト計測・ポリシー調整 | KPI実測値・ポリシー違反ログ分析 |
| Week 4 | 結果整理・レポート作成・本番移行判断 | PoCレポート・GO/NOGO判断・移行計画書 |
Week 1の「評価データ準備」が全体の中で最もボトルネックになりやすいです。過去の業務アウトプットをゴールドセットとして整備する作業は、エンジニアではなく業務担当者が主体となる必要があります。PoCキックオフ前にデータ準備担当を明確にしてください。
PoC延長が必要なケースと判断基準
以下のいずれかに該当する場合、PoCを1〜2週間延長することを検討してください。
- Week 2終了時点で精度が目標値の70%未満（プロンプト再設計が必要）
- Week 3でOpenShellポリシー違反が頻発し、blueprint.yamlの大幅見直しが必要と判明した場合
- 評価ゴールドセットの品質に問題があり、再収集が必要な場合
- NemoClawのバージョンアップ（アルファ版のため随時）によって動作が変わった場合
逆に以下の場合は4週間を待たずに本番移行判断を前倒しできます。Week 2終了時点で全KPIが成功基準を達成しており、チェックリストの技術面が完了済みの場合です。
最小ハードウェア構成――RTX 4090またはクラウドAPIから始める
NemoClaw PoCで使えるハードウェア構成は「オンプレミス（GPU購入）」と「クラウドAPI」の2パターンです。それぞれのメリット・デメリットと推奨シナリオを整理します。
オンプレミス最小構成：GeForce RTX 4090
コスト重視のPoC、または本番もオンプレミスを想定している場合はGeForce RTX 4090が最小構成のベースになります。
| コンポーネント | 推奨スペック | 最低スペック | 備考 |
|---|---|---|---|
| GPU | RTX 4090（24GB VRAM） | RTX 4080（16GB VRAM） | Nano 30Bモデルには16GB以上必要 |
| CPU | Ryzen 9 7950X / Core i9-14900K | 8コア以上 | NemoClawホストプロセスに4コア割当 |
| メモリ（RAM） | 64GB DDR5 | 32GB DDR4 | Docker + vLLM + エージェントで30GB使用 |
| ストレージ | NVMe SSD 2TB（読込7,000MB/s以上） | NVMe SSD 1TB | モデルキャッシュに100〜200GB占有 |
| OS | Ubuntu 22.04 LTS | Ubuntu 22.04 LTS | CUDA 12.4以上が必要 |
RTX 4090構成でNemotron Nano 30B（Qモデル）をローカル実行した場合、平均レイテンシは4〜8秒（タスクの複雑度による）です。クラウドプロファイルより応答は遅いですが、推論コストはゼロになります。
PoC期間のみRTX 4090搭載ワークステーションをレンタルするサービスも活用できます。GPU搭載PCの月額レンタルは5〜15万円程度が相場です。PoC完了後に本番用ハードウェアの仕様を確定してから購入する方がリスクを抑えられます。
クラウドAPI構成：NVIDIA Cloud Functions
ハードウェア調達なしにすぐPoCを開始したい場合は、NVIDIA Cloud Functions（NIM API）を使ったクラウドプロファイルが最速です。
| 項目 | クラウドAPI構成 | RTX 4090構成 |
|---|---|---|
| 初期費用 | なし（APIキーのみ） | 40〜60万円（ハードウェア購入 or レンタル） |
| 推論コスト | $0.003〜$0.008 / 1Kトークン | 電気代のみ（ほぼゼロ） |
| 平均レイテンシ | 0.5〜2秒（Super 120B） | 4〜8秒（Nano 30B） |
| データ国内保持 | 不可（米国データセンター） | 可能 |
| PoC開始までの時間 | 即日 | 機材調達1〜2週間 |
金融・医療・官公庁などデータ国外持ち出しが問題になる業種は、クラウドAPIでのPoCには注意が必要です。匿名化・マスキングしたダミーデータを使ってPoC精度を検証し、本番は必ずオンプレミスで構築するという「ハイブリッドPoC」が現実的な方法です。
評価KPIの設定方法
PoCの評価KPIは「精度」「レイテンシ」「コスト」の3軸が基本です。さらにNemoClaw固有の評価軸として「OpenShellポリシー違反件数」を必ず含めてください。
| KPI軸 | 指標名 | 計測方法 | 推奨計測頻度 |
|---|---|---|---|
| 精度 | タスク正答率（対ゴールドセット） | ゴールドセット50〜200件との比較スコア | 週次 |
| 精度 | ハルシネーション発生率 | 出力に事実と異なる内容が含まれた件数 / 全件数 | 週次 |
| レイテンシ | 平均応答時間（ms） | task.duration_msの平均値 | 日次 |
| レイテンシ | P99レイテンシ（ms） | task.duration_msの99パーセンタイル値 | 日次 |
| コスト | 1タスクあたりの推論コスト（円） | usage.total_tokensからAPI課金額を計算 | 日次 |
| コスト | 月換算推論費用（円） | 1タスクコスト × 月間想定タスク数 | 週次 |
| セキュリティ | OpenShellポリシー違反件数 | blueprint.yamlのpolicy blockログのカウント | 日次 |
| セキュリティ | 重大ポリシー違反件数 | severity: criticalのログカウント | リアルタイム |
ゴールドセットの作り方
精度計測の基準となるゴールドセット（正解データセット）は、業務担当者（ドメインエキスパート）が作成します。エンジニアだけで作ると業務の正解が反映されず、計測精度が低下します。
- 件数の目安：PoC期間中に最低50件、できれば100〜200件。件数が少ないと統計的信頼性が低い
- データの多様性：「典型ケース」だけでなく「エッジケース（例外・複雑なケース）」を全体の20〜30%含める
- 正解の粒度：「ほぼ正解」「完全正解」「誤答」の3段階評価を設定する。完全正解のみを正解とすると過剰に厳しい評価になる場合がある
- 評価者間一致率：複数人が評価する場合、評価者間の一致率（Kappa係数）を計測して0.7以上を確保する
レイテンシ・コストの業務別目標値設定
レイテンシとコストの目標値は業務の性質によって大きく変わります。一律の閾値を適用せず、業務種別に合わせた目標を設定してください。
| 業務種別 | レイテンシ目標（平均） | コスト目標（1タスク） | 理由 |
|---|---|---|---|
| リアルタイム顧客対応（チャットボット） | 2秒以内 | 5〜10円 | 体感速度がUXに直結 |
| バックオフィス処理（帳票・メール） | 10秒以内 | 10〜30円 | 非同期処理が多く速度要件が緩い |
| 夜間バッチ処理（データ分析・集計） | 60秒以内 | 30〜100円 | 精度重視・速度は問わない |
| ドキュメント生成（報告書・契約書要約） | 30秒以内 | 50〜200円 | 出力品質が最重要 |
成功・失敗判定基準の設定方法
PoC開始前に「成功」「条件付き成功」「失敗」の判定基準を定量的に定義することが最重要です。PoCを開始してから基準を決めると、結果に合わせて基準を後付けする「基準の歪み」が発生します。
3段階判定モデル
「成功 / 条件付き成功 / 失敗」の3段階で判定することを推奨します。「成功か失敗か」の2択では判断が硬直化しやすいためです。
| 判定 | 条件 | 次のアクション |
|---|---|---|
| 成功（本番GO） | 必達KPI（精度・コスト）をすべて達成 かつ 重大ポリシー違反ゼロ | 本番移行チェックリストに進む |
| 条件付き成功（改善後GO） | 必達KPIを1項目のみ未達 かつ 改善策が明確 かつ 2〜4週間で改善見込み | 改善スプリントを実施 → 再評価 |
| 失敗（NOGO） | 必達KPIを2項目以上未達 または 重大ポリシー違反が発生 または 根本的な設計変更が必要 | PoC設計の見直し → 再PoC計画 |
「失敗（NOGO）」判定は投資の失敗ではなく、本番での大規模損失を防いだ学習コストです。PoCのNOGOは組織として共有すべき貴重な知見です。「何がうまくいかなかったか」をドキュメント化して次のPoC（または別のアプローチ）に活かしてください。
成功基準の設定例（バックオフィス処理PoCの場合）
以下は経費精算書の自動チェックエージェントのPoC成功基準の設定例です。実際のPoC計画に合わせて数値を調整してください。
| KPI | 必達（GO条件） | 努力目標 | NG（NOGO条件） |
|---|---|---|---|
| タスク正答率 | 90%以上 | 95%以上 | 80%未満 |
| ハルシネーション発生率 | 2%以下 | 0.5%以下 | 5%超 |
| 平均レイテンシ | 10秒以内 | 5秒以内 | 30秒超 |
| 1タスクコスト | 現行人件費比40%以下 | 現行人件費比20%以下 | 現行人件費比60%超 |
| 重大ポリシー違反 | ゼロ件 | ゼロ件 | 1件以上 |
PoC→本番移行の判断基準と移行条件
PoCで成功判定が出たとしても、そのまま本番稼働にするのは時期尚早です。本番移行前に技術・ビジネス両面のチェックリストをクリアすることが必要です。
技術面の移行条件
- blueprint.yamlのコードレビュー完了：セキュリティ専門家（または外部レビュアー）によるOpenShellポリシーの設計レビューを実施済み
- 負荷テスト実施済み：PoC時の推定トラフィックの10倍規模でのロードテストを実施し、レイテンシとエラー率が許容範囲内であることを確認
- 異常動作の自動停止機能：エージェントが想定外の動作をした際に自動でセッションを停止するキルスイッチが実装されている
- ログ保管体制の整備：全タスクの入力・出力・ポリシー判定結果が90日以上保管される体制（法令・社内規定対応）
- NemoClawバージョン管理手順：アルファ版のため頻繁に更新が入る。バージョンアップ時の影響確認・デプロイ手順が定義されている
- モニタリング基盤の稼働：GPU使用率・推論レイテンシ・エラー率をリアルタイムで監視できるダッシュボード（Grafana等）が稼働している
ビジネス・組織面の移行条件
- 運用体制の確定：障害対応担当・監視担当・NemoClawアップデート管理担当が決まっている
- エスカレーションフローの定義：エージェントが対応できないケースを人間にエスカレーションする手順と担当者が決まっている
- 現場担当者への研修完了：エンドユーザーへのAIエージェント活用説明・出力の確認方法・誤答の報告方法について研修済み
- ROI計測体制の構築：本番稼働後に工数削減・コスト削減を定期的に計測できる仕組み（KPIダッシュボード）が用意されている
- 撤退基準の設定：本番稼働後に所定のKPIを達成できない場合の撤退（または縮小）基準が事前に決まっている
技術面と組織面のすべての条件をPoC終了前に満たすことが理想ですが、現実的には一部が未完のままGoを判断するケースも多いです。その場合は「未完了項目」「担当者」「完了予定日」を明記した移行計画書を作成し、本番稼働開始から30日以内に完了させることをコミットメントとして記録してください。
パイロット展開（限定本番）という選択肢
PoCが成功し移行条件を概ね満たした場合でも、いきなり全社展開するのではなく「パイロット展開（限定本番）」という中間ステップを設けることを推奨します。
パイロット展開では特定の部門・チームだけを対象に本番相当の環境でNemoClawを稼働させます。全社展開前に最後のリスク確認と運用ナレッジ蓄積を行う期間です。
| フェーズ | 期間 | 対象範囲 | 目的 |
|---|---|---|---|
| PoC | 4〜8週間 | 開発チームのみ | 技術的実現可能性・KPI達成確認 |
| パイロット | 4〜8週間 | 特定部門（10〜30名） | 運用ナレッジ蓄積・UX改善 |
| 本番全社展開 | 段階的（4〜12週間） | 全社（部門ごとに順次） | スケール時の問題検出・定着化 |
PoC開始前チェックリスト
NemoClaw PoCを正式にキックオフする前に、以下のチェックリストが完了していることを確認してください。「Yes」の数が多いほどPoC成功確率が高まります。
| チェック項目 | 重要度 | 未完了時のリスク |
|---|---|---|
| PoC対象業務を1〜3タスクに絞っている | 必須 | スコープ拡大によるPoC長期化・迷走 |
| 成功・条件付き成功・失敗の判定基準を定量的に定義した | 必須 | PoC終了時に判断できず継続・先送りになる |
| ゴールドセット（評価データ）の準備担当者が決まっている | 必須 | Week 1〜2がデータ準備で消化され計測期間が取れない |
| PoC環境（GPU or クラウドAPI）の調達が完了または確定している | 必須 | 環境準備待ちでスケジュールが後ろ倒しになる |
| PoC期間中のデータは匿名化・マスキング済みである | 必須 | 情報漏洩リスク・GDPR/個人情報保護法違反 |
| PoC予算（100〜200万円）の承認が得られている | 必須 | 途中で予算不足になりPoC中断 |
| PoC担当エンジニアが2名以上確保されている | 推奨 | 1名担当では病欠・離脱時にPoC停止 |
| 業務担当者（ドメインエキスパート）がPoC期間中に協力可能である | 推奨 | ゴールドセット精度が低下し評価が不正確になる |
| PoCレポートのフォーマットと提出先が決まっている | 推奨 | PoC終了後に報告フォーマット調整で時間を消費 |