01本番化を阻む三つの企業課題
デモ用 Agent は単一リポジトリで完結しますが、事業部横断の本番 Harnessでは別の制約が効きます。
1. 権限の拡散。シェル、クラウド API、社内 Wiki まで一括接続すると、退職者のトークンや過剰権限が残り、監査で説明できません。
2. 状態とコストの不可視。長時間ループや巨大コンテキストは、部門別の請求と SLA を壊します。上限なき PoC は四半期で予算超過になります。
3. Apple 系工程の断絶。Linux 上の Harness だけでは Xcode ビルドや TestFlight 昇格が再現できず、人手の Mac がサイロ化します。
02導入方式の比較：判断マトリクス
「IDE 連携のみ」「自社 Harness」「マネージド Harness」の三方式を、企業が重視する観点で比較します。予算会議の前に、下表で役割分担を固定してください。
| 観点 | IDE 連携のみ | 自社 Harness | マネージド Harness | 企業向き |
|---|---|---|---|---|
| 監査・RBAC | 端末依存 | 完全カスタム | 標準ゲート | コンプライアンス重視は後二者 |
| 立ち上げ速度 | 即日 | 四〜十二週 | 二〜六週 | PoC は IDE、本番は Harness |
| ツール権限 | 開発者裁量 | ポリシー as Code | テンプレート承認 | 本番 API はホワイトリスト必須 |
| コスト予測 | 不可視 | 自社 SRE 工数 | シート＋トークン | 部門上限を Harness 側で設定 |
| Apple 工程 | ローカル Mac | 外部 Runner 要 | 外部 Runner 要 | neokvm 専用 Mac を併設 |
結論：Harness は「モデル」ではなく組織の実行 OSです。推論はクラウドでもオンプレでもよく、分離すべきはツール権限と証跡です。
03六段階の企業導入手順（非本番六週間）
- 区分定義：読み取り専用、ステージング書込、本番デプロイの三ゾーンにユースケースを振り分けます。
- 権限設計：ツールごとにスコープと承認者を固定し、シークレットは短命 OIDC に寄せます。
- パイロット：単一プロダクトで Harness を回し、失敗時のロールバック手順を文書化します。
- Mac レーン：neokvm の Mac mini M4 に Xcode／署名を閉じ、Harness から SSH または CI Webhook で起動します。
- 可観測性：トークン、待ち時間、ツール失敗率をダッシュボード化し、部門別上限を設定します。
- 本番昇格：チェックリスト通過後のみ本番ツールを開放し、四半期ごとに権限棚卸しを行います。
04引用しやすい運用数値
- 承認 SLA 15 分：本番ツールの人間承認は p95 で十五分以内を目標にします。超過は自動ロールバックのサインです。
- コンテキスト 128K 上限：部門ごとに日次トークン上限を Harness 側で切り、異常ループを止めます。
- Mac mini M4 16GB：単一アプリのアーカイブと Simulator スモーク。24GB は並列 Agent レーン向きです。
05まとめ：Harness と専用 Mac の二層で本番へ
企業導入の勝ち筋は「Harness で権限と証跡を固定し、Apple 系は専用 Mac に閉じる」ことです。neokvm の Mac mini M4 なら、東京・シンガポール・US West などから SSH／VNC で調査でき、ディスクと Xcode バージョンが持続します。まず非本番で一台を借り、Agent のビルドレーンだけを切り出してください。効果が出たら 24GB 枠で並列し、机の Mac 積み上げはやめましょう。購入ページでプランを選べば、当日から Harness 実行基盤として使えます。
AI Harness の Apple レーンを Mac mini M4 で固定しましょう
neokvm の専用 Mac で Xcode・TestFlight・署名を分離し、Harness から安全に呼び出せます。部門が増えたらノードを追加するだけでスケールします。