生成AIエージェントが「PCや業務システムを横断して自律実行する」世界観は、営業・運用・開発の生産性を一段引き上げます。一方で、企業導入では“便利さ”と同じだけ“統制”が問われます。OpenClawは爆発的に普及した反面、「許可不要（permissionless）」な設計がセキュリティ部門の懸念を招きました。NanoClawはその反省点を起点に、OSレベルの隔離と最小コア設計で、監査可能なAIエージェント基盤を提示します。本稿では、OpenClawの課題、NanoClawの設計思想、運用・導入評価のポイントをB2B視点で整理します。
1. OpenClawが抱えた「許可不要」アーキテクチャのセキュリティ課題
OpenClawは、自然言語の指示から複数エージェント（スウォーム）を立ち上げ、端末内外の作業を自動化できる点で注目されました。しかし「許可不要」アーキテクチャは、裏返すと“ホスト環境に対して強い権限を持ち得る”ことを意味します。アプリ内の許可リストやコマンド遮断のような防御は、実装の抜け道や想定外の入力（プロンプトインジェクション）により破られる可能性が残ります。
企業の観点では、次のようなリスクが連鎖します。第一に、エージェントがホストのファイルシステムや認証情報、ブラウザセッションへ広く触れられると、情報漏えいの「爆発半径（blast radius）」が大きくなります。第二に、統合機能が増えるほど依存関係が増え、脆弱性管理・SBOM・監査対応が困難になります。第三に、巨大なコードベースはレビュー不能になり、オープンソースの“透明性”という前提が崩れます。OpenClawは多数のモジュールと統合で魅力を増した一方、企業が求める「境界の明確さ」と「説明可能な安全性」を満たしにくい構造になっていました。
2. NanoClawの中核：OSレベルのコンテナ隔離とサンドボックス設計
NanoClawの最も重要な転換は、アプリケーション内の防御ではなく、OSレベルの隔離を前提にしたことです。各エージェントを隔離されたLinuxコンテナ内で動かし、macOSではApple Containers、LinuxではDockerなどを用いて高性能に実行します。これにより、エージェントが“ホスト上で暴れる”前提を捨て、最初からサンドボックスの中でのみ自律性を許容します。
サンドボックス設計の要点は「明示的にマウントしたディレクトリだけにアクセスさせる」ことです。業務で扱うデータ領域（例：Obsidian保管庫、案件フォルダ、エージェント専用の作業ディレクトリ）だけをコンテナへ渡し、それ以外は見えない状態にします。仮にプロンプトインジェクションや悪性の指示で不正操作が起きても、被害はコンテナ内と限定された通信チャネルに閉じ込められます。
また、スウォーム（複数エージェントの並列協調）を前提にしつつ、サブエージェントごとにメモリ文脈を分離できる設計は、業務グループ間の情報混線を抑えるうえで有効です。営業チームの会話ログと、採用・人事の会話ログが同一メモリに混ざると、漏えいだけでなく誤判断にもつながります。NanoClawは「自律性を上げるほど、隔離は低レイヤで強くする」という企業向けの原則に寄せています。
3. 500行コアで実現する監査性と運用性（依存削減・SQLite/IPCの単純化）
NanoClawがもう一つ重視したのが、肥大化の否定です。OpenClawを評価した開発者は、数十万行規模のコードと多数の依存関係が、監査・保守の現実性を損なうと指摘しました。企業導入では「誰が、いつ、どこまでレビューできるか」が重要で、レビュー不能な規模はそれ自体がリスクになります。
NanoClawは中核ロジックを約500行のTypeScriptに抑え、状態管理からエージェント起動までを短時間で追跡できることを狙います。単に“軽い”のではなく、セキュリティチームが攻撃ベクトルをホワイトボードで洗い出し、設計の前提を検証できるサイズ感にする、という意思決定です。
運用面では、単一プロセスのNode.jsオーケストレーターが、グループ単位のメッセージキューを持ち、並行実行を制御します。分散メッセージブローカーや複雑なマイクロサービスを避け、永続化はSQLite、プロセス間通信はファイルシステムベースのIPCという“原始的だが透明な部品”で構成します。結果として、障害解析・再現性・バックアップ設計がシンプルになり、運用チームが「どこで詰まっているか」を追いやすくなります。
企業運用で効く「単純さ」のメリット
- 監査：依存関係が少なく、レビュー範囲が明確になる
- 変更管理：影響範囲が読みやすく、リリース判断が速い
- 障害対応：ログと状態の所在が単純で、切り分けが容易
- コスト：過剰な基盤（キュー/サービス群）を持ち込まずに済む
4. 「機能よりSkills」思想：AIでローカル実装を最小限にカスタマイズする方法
NanoClawの思想で興味深いのが「機能（features）よりSkills」です。一般的なOSSは、多くのユーザー要望を取り込み“万能ツール化”しがちですが、それは未使用機能まで含めた攻撃面の拡大を招きます。NanoClawは、SlackやDiscordなどの広範な統合を本体に積み増すより、各社・各チームが必要な分だけローカルに組み替える方針を取ります。
具体的には、.claude/skills/ のような場所に「AIにコード改変を教える手順（Skills）」を置き、/add-telegram、/add-gmail のようなコマンドで、ローカルの実装をAIが書き換えて統合を追加します。つまり“機能を配布する”のではなく、“安全に改造する方法を配布する”発想です。これにより、WhatsApp運用だけが必要な組織は、不要な50個の統合を抱えずに済みます。
B2Bでの実装アプローチ（最小カスタマイズ）
- まず「マウントするデータ領域」を業務単位で設計し、アクセス境界を固定する
- 次に必要な入出力チャネル（メール、チャット、CRM）だけをSkillsで追加する
- 追加した統合は、権限（トークン）とログ設計をセットで定義する
- 不要になった統合は削除し、攻撃面と運用面を縮小する
5. 実運用事例：AIネイティブ組織での営業・業務オペレーション自動化
NanoClawは実験的な枠に留まらず、AIネイティブな組織の業務運用に投入されています。あるAIファーストのGTM（Go-To-Market）支援組織では、個人インスタンスのエージェントが営業パイプラインを実質的に運用しています。担当者はCRMを逐一触るのではなく、日々流れてくるメモ、WhatsAppの断片的な情報、メールのスレッドを管理グループへ転送するだけで、エージェントが内容を解釈し、ステータス更新や次アクションを整備します。
運用のポイントは「入力が汚くても回る」ことです。現場の営業情報は、箇条書き、スクリーンショット、口語、途中経過が混ざります。NanoClawはそれを構造化し、Obsidianの保管庫やSQLiteに反映し、フォローアップのリマインドを自動生成します。さらに、エージェントが自分のコードにもアクセスできるため、定期的な技術作業（例：git履歴からドキュメントの乖離を検出、内部関数のリファクタリング）を“業務オペレーションの延長”として回せます。
この種の運用が企業にもたらす価値は、単なる自動化ではなく、情報の集約点を「人」から「隔離された実行環境＋監査可能な基盤」へ移すことにあります。属人的な更新作業が減り、プロセスの再現性が上がります。
6. 企業導入の評価軸：利便性と統制、セキュリティ監査、拡張性の判断ポイント
2026年のAIエージェント導入では、「最短で動く」より「安全に長く回る」が差別化要因になります。NanoClawは“便利さ”を捨てたのではなく、便利さを許容する境界をOSレベル隔離で作り、残りを最小コアとSkillsで成立させる設計です。企業が評価する際は、機能表よりも次の観点で比較すると判断が速くなります。
導入前に確認したいチェックポイント
- 統制設計：コンテナ境界、マウント対象、ネットワーク到達範囲、資格情報の保管方法が明示されているか
- 監査可能性：コアの規模、依存関係、ログ/状態の所在、脅威モデリングのしやすさ
- 運用性：単一障害点、復旧手順、バックアップ、環境差分（macOS/Linux）の吸収方法
- 拡張性：統合は“追加しやすい”だけでなく“削除しやすい”か（Skillsで最小構成を保てるか）
- データ分離：グループ/業務単位でメモリ文脈や永続化領域を分けられるか
特にセキュリティ部門との合意形成では、「リポジトリを渡して短時間で監査できるか」が実務上効きます。巨大で多機能な基盤は、監査コストが導入可否を左右します。NanoClawのように、コアが小さく、隔離がOSレイヤで担保され、永続化とIPCが単純であれば、設計の説明・検証・是正のサイクルを回しやすくなります。
まとめ
NanoClawは、OpenClawが抱えた「許可不要」設計の不安に対し、OSレベルのコンテナ隔離で爆発半径を限定し、約500行の最小コアで監査性と運用性を高めたAIエージェント基盤です。さらに「機能よりSkills」により、必要な統合だけをローカルにAIで実装・削除でき、攻撃面と複雑性を増やしにくい構造を採ります。企業導入では、デモの派手さよりも、隔離境界、監査可能性、運用の単純さ、そして“追加より削除”まで含めた拡張戦略を評価軸に置くことが、持続的な自動化の近道になります。
