複数の利用者を分けてAIエージェントを動かすツール「GoClaw」の仕組みと導入前の注意点

「部署ごとに別々のAIエージェントを持たせたいが、一つの基盤にまとめても情報が混ざらないのか」「ソースコードが公開されているなら、社内で無料のまま使ってよいのではないか」——AIエージェントを複数の部署や顧客に向けて動かそうとしている企業の、情報システム部門や法務の窓口に届く問いです。どちらも、性能の高い基盤を選べば片づく話に見えます。しかし本当に先に確かめるべきなのは、機能の多さではありません。利用者を分ける仕組みが誰の言葉で説明されているのかと、ライセンスがその使い方を許しているのかの二点です。この記事では、複数の利用者を分けてAIエージェントを動かすツール「GoClaw」を取り上げ、一次情報で確かめられる仕組みと、導入前に押さえるべき注意点を整理します。導入や設定の手順は扱いません。

GoClawとは何か。2026年10月時点で確かめられる事実

GoClawは、GitHubで公開されているAIエージェントの基盤です。READMEでは「複数の利用者に対応するAIエージェントの基盤」と位置づけられ、Go言語で作られた一つの実行ファイルで動き、20以上の大規模言語モデルの提供元と、7つのチャットの窓口につなげると説明されています。リポジトリの説明文には、OpenClawをGo言語で作り直し、利用者ごとの分離と5層の守りを加えたという趣旨の一文が掲げられています。

配布の形を確かめます。リポジトリは nextlevelbuilder という組織のアカウントで2026年2月22日に作られました。2026年10月18日時点でスターは3,658、派生は1,073、最後の更新は10月17日です。組織のアカウントは2025年11月30日に作られ、所在地はベトナム、公開しているリポジトリは17件です。一日あたりのスターの伸びは約15.4件で、短期間で注目を集めた一方、運営の実績はまだ一年に満たないことが分かります。

版の出し方にも特徴があります。安定版として示されている最新の版は2026年6月15日の3.14.0で、それ以降はベータ版が10月17日の3.15.0のベータ229番まで続いています。READMEは、開発中の枝が既定で、安定版は別の枝だと注記しています。つまり、リポジトリの入口に見えている内容は開発中のものであり、安定版とは限らないという前提で読む必要があります。

「OpenClawを作り直した」という位置づけをどう読むか

OpenClawは、2026年に海外で利用が広がった、個人の端末で動くAIエージェントのOSSです。GoClawは、その考え方を、複数の利用者が同じ基盤を共有する形に広げたものとして自らを説明しています。ただし、READMEの末尾の謝辞では「もともとOpenClawの設計に着想を得た」と書かれており、説明文の「作り直した」よりも控えめな表現になっています。

この違いは、細かな言い回しの差にとどまりません。元のOSSとの関係が「作り直し」なのか「着想を得た別物」なのかで、権利の扱いと、元のOSSの改善がどこまで引き継がれるかの見通しが変わるからです。OpenClawの公開リポジトリのライセンスはMITで、権利者はOpenClawの財団と記されています。一方、GoClawのライセンス文書は後で詳しく見るとおり別の条件です。

さらに、GoClawのライセンス文書は、2026年3月15日に追加された当初、著作権者を「OpenClawの貢献者」と記していました。4月11日の変更で「GoClawの貢献者」に書き換えられています。なぜ当初そう書かれていたのか、その理由は確認した一次情報からは読み取れません。どのコードが誰の権利なのかは、導入する側が一次情報で確かめる対象だと押さえておけば十分です。

複数の利用者を分けて動かす仕組み

GoClawの文書は、使い方を二つに分けています。一つは個人や小さなチームが付属の管理画面からそのまま使う形、もう一つは自社のサービスの裏側に組み込み、顧客ごとに環境を分けて使う形です。後者では、顧客や部署を「テナント」（基盤を共有する利用者のまとまり）として扱います。

文書によると、テナントごとにエージェント、会話の記録、チーム、記憶、モデルの提供元の設定、外部の道具との接続、技能（スキル）が分けられます。外部からの要求はテナントに結びついた鍵で受け付け、データベースへのすべての問い合わせにテナントの識別子による絞り込みをかけ、識別子が欠けていれば処理を止める作りだと説明されています。データベースにはPostgreSQLを使い、利用者ごとの作業場所、利用者ごとの設定、暗号化した鍵の保管、役割に応じた権限管理を備えるとされます。

ここで注意したいのは、チャットの窓口の扱いです。文書の表では、チャットツールからの接続は認証の方式が「なし（直接の受け口）」とされ、どのテナントに属するかは窓口ごとの設定で決まると書かれています。窓口の設定を一つ誤れば、別の顧客や部署のエージェントに話しかけてしまう構造とも読めます。分離の仕組みがあることと、それが正しく設定されていることは別に確かめる必要があります。

エージェントの道具とチームで動かす仕組み

READMEは、8段階の処理の流れ、4種類の指示文の組み立て方、3層の記憶、文書の保管庫、エージェントどうしの協働を主な機能に挙げています。道具は8分類・30種以上とされ、ファイルの読み書き、コマンドの実行、ブラウザーの自動操作、ウェブ検索、画像や音声の生成、定期実行などが含まれます。コマンドの実行には承認の流れがあると書かれています。

エージェントどうしの協働では、それぞれのエージェントが固有の身元、道具、モデルの提供元を持ち、誰から誰へ仕事を渡せるかを結び付けで定めるとされます。仕事の受け渡しは切り離した作業場所を通して行うと説明されています。加えて「自己進化」と呼ぶ機能があり、利用の指標から改善案を作り、エージェントが自分の話し方や専門の記述を自動で調整するとされます。身元や名前、中心の目的は変えない、と書き添えられています。

このほか、外部のシステムから専用の受け口を通してエージェントを動かす仕組みもあります。READMEは、管理用の鍵を使わずに外部から呼び出せると説明しています。便利な反面、エージェントを動かせる入口が管理画面の外にも増えることを意味します。どの入口を開け、誰に鍵を渡しているかを一覧にしておく必要があります。

「5層のセキュリティ」は何を指すのか

開発元の守りに関する文書によると、5層とは、通信、入力、道具、出力、隔離の五つです。通信の層では接続元の制限、要求の大きさの上限、時間差を突かれにくい認証、要求の回数制限を挙げています。入力の層では、指示の上書きをねらう文章（プロンプトインジェクション）を6種類の型で探すとしています。

道具の層では、危険なコマンドの型を7分類で拒む仕組み、作業場所の外へのファイルの参照を防ぐ仕組み、内部のネットワークや管理用の宛先への取得要求を防ぐ3段階の確認、コマンド実行の承認が挙げられています。出力の層では、鍵やパスワードに見える文字列を伏せ字にする処理を、隔離の層では利用者ごとの作業場所と、任意で使えるコンテナによる隔離を説明しています。いずれも開発元の文書に書かれた自己申告で、第三者が検証した結果ではない点を前提に読む必要があります。

文書の書き方は具体的で、何をどう防ぐつもりなのかを読み取れる点は評価できます。一方で、型に当てはめて探す方式は、決められた言い回しから外れた攻撃を取りこぼしうるという限界があります。この記事では、5層を「備えている」とは書かず、「開発元はこう説明している」と扱います。

既定の設定と任意の設定で気をつけたい点

同じ守りの文書を読むと、既定の状態と、使う側が選ばないと働かない設定が混在していることが分かります。たとえば、指示の上書きを探す入力の検査は、既定では警告の記録を残して処理を続ける設定だと明記されています。止める設定もありますが、既定のままでは、怪しい入力を見つけても処理は止まらないということです。検査を完全に切る設定もあります。

通信の層でも、接続元を許可する一覧が空のときは、以前の版との互換のためにすべての接続元を許すと書かれています。コマンドの実行を閉じた入れ物で動かす隔離も、READMEでは任意で足す追加の機能として案内されています。隔離の入れ物そのものは、読み取り専用、権限の全削除、ネットワークの遮断、記憶容量と時間の上限といった強めの設定が並んでいます。使うと決めて有効にしたときに初めて効く守りだという点が大切です。

守りの層が多いことは、そのまま安全の厚さを意味しません。どの層が既定で働き、どの層が使う側の選択に任されているかを分けて把握しておかないと、説明書の上では5層あるのに、実際には2層しか動いていないという状態が起こりえます。導入を検討するなら、まず既定値の一覧を作ることから始めるのが現実的です。

自己申告の守りと、導入側が確かめること

開発元が説明する守りと、その既定の状態、導入する側が確かめるべき点を表にまとめます。表の内容は、開発元の文書を2026年10月18日に読んだ範囲に基づくもので、版が変われば変わりえます。

層・仕組み	開発元の説明	既定の状態（文書の記述）	導入側が確かめること
通信	接続元の制限・回数制限・認証	許可の一覧が空ならすべて許す	許可する接続元を決めて登録したか
入力	6種類の型で指示の上書きを探す	警告を記録して処理は続ける	止める設定にするか、記録を誰が見るか
道具	危険なコマンドの拒否・内部宛先への要求の遮断・承認	承認の流れがあるとされる	どの道具を誰に許し、誰が承認するか
出力	鍵やパスワードに見える文字列を伏せ字にする	型に合うものを伏せる	社内独自の機密の形式も伏せられるか
隔離	利用者ごとの作業場所・コンテナによる隔離	コンテナは任意の追加機能	実行を伴う作業で隔離を有効にしたか
利用者の分離	問い合わせを利用者のまとまりで絞る	識別子が欠ければ止めるとされる	窓口ごとの設定に誤りがないか

表の右端の列は、どれも開発元ではなく導入する側が決める事柄です。守りの仕組みを持つ基盤ほど、その仕組みをどう使うかの判断が導入側に残ると言い換えられます。開発元の説明を疑うためではなく、自社の使い方に合わせて確かめるための表として使ってください。

ライセンス文書を一次情報で読む

GitHubの画面でライセンス欄を自動判別した結果は「NOASSERTION」、つまり既知のどの型とも判別できないという表示です。そこでリポジトリの最上位にあるライセンス文書そのものを読みました。文書の冒頭には、クリエイティブ・コモンズの表示・非営利4.0国際ライセンス（CC BY-NC 4.0）で提供すると書かれています。READMEの末尾とバッジも同じ表記です。

文書の本文は、正式な条文ではなく要約の形です。複製と再配布、改変は認める一方、条件として「表示」（適切な名前の表示、ライセンスへのリンク、変更の有無の明示）と「非営利」（商用目的で使ってはならない）を挙げています。保証はしないこと、肖像やプライバシーなど別の権利が利用を制限しうることも書かれています。全文は外部の条文を参照するよう案内されています。自動判別が効かないのは、文書が条文の全文ではなく要約の形で置かれていることが一因と考えられます。

履歴も確かめました。ライセンス文書が追加されたのは2026年3月15日で、リポジトリの公開から3週間ほど後です。それより前のREADMEにはMITと書かれ、ライセンス文書へのリンクもありましたが、その時点のリポジトリにライセンス文書は見当たりませんでした。公開直後に複製されたものは、いまも「MIT」と表示している可能性があるため、第三者の複製や紹介ページのライセンス表記をそのまま信じず、公式のリポジトリの現在の文書で確かめる必要があります。

商用利用の条件をどう読むか

クリエイティブ・コモンズの条文は、非営利を「主として商業上の利益や金銭的な対価を目的としない、またはそれに向けられていないこと」と定めています。GoClawを自社の有料サービスの裏側に組み込み、顧客ごとに分けて提供する使い方は、文書が想定する「自社のサービスに組み込む形」そのものですが、このライセンスのもとでは、まさに商用目的の利用に当たる可能性が高いと考えられます。

判断が分かれやすいのは、社内の業務だけで使う場合です。営利企業の社内利用が非営利に当たるかどうかは、条文の定義だけでは一律に決まらず、使い方の目的しだいで解釈が分かれます。この記事では結論を出しません。社内利用でも、業務で使う前に法務の判断を通し、必要なら権利者から書面で許諾を得るのが安全な進め方です。公式サイトには「企業向けの支援を提供している」との記載と連絡先がありますが、商用の許諾の条件や料金は確認できませんでした。

もう一つ見落とせないのが、ライセンスの選び方そのものです。クリエイティブ・コモンズは自身の質問集で、ソフトウェアに同団体のライセンスを使うことを勧めないと明言しています。ソースコードの配布や特許についての条項がなく、主要なソフトウェアのライセンスと両立しないことが理由に挙げられています。さらに著作権者は「GoClawの貢献者」とされ、貢献者は100人を超えます。誰が商用の許諾を出せるのかは、確認した一次情報からは読み取れませんでした。

安全性の評価：注意付きとした根拠

このラインでは、紹介する題材を公開されている事実だけを基に精査しています。題材を入手したり動かしたりはしていません。GoClawの判定は「注意付き」です。

根拠は二つです。一つ目はライセンスです。GitHub上の自動判別は判別できないという表示で、文書の中身を読むと非営利に限る条件でした。精査の基準では、非商用に限るライセンスは注意付きに当たります。二つ目は運営の実績です。組織のアカウントは2025年11月30日に作られ、リポジトリは2026年2月の公開で、実績を判断するための期間がまだ短い状態です。

一方で、GitHub上にこのリポジトリのセキュリティ勧告は登録されていませんでした。スターの伸びは1日あたり約15.4件で、精査の基準にある不自然な水増しの目安には当たりません。リポジトリの最上位には、コンテナの定義や組み立て用の設定があります。ただし、勧告がないことは弱点がないことを意味しません。精査は公開情報の範囲に限られ、コードの中身や実際の動きを検証したものではないため、安全の保証にはならない点を添えておきます。

運営体制と更新の速さ

更新の量は非常に多い状態です。開発中の枝のコミットは2,000件を超え、ベータ版は9月末から10月にかけて数日おきに出ています。動きが活発であることは良い面ですが、検証が追いつかないまま版が入れ替わる危険とも隣り合わせです。安定版が6月で止まっているため、安定版を選ぶと4か月分の修正を受け取れず、ベータ版を選ぶと変更の多さを引き受けることになります。

体制の面では、弱点を報告するための窓口の文書（セキュリティポリシー）が、リポジトリの最上位にも専用のフォルダにも見当たりませんでした。貢献のための案内文書はあります。コミットの多くは少数のアカウントに集中しており、未解決の課題と変更の提案は合わせて279件です。弱点を見つけたときにどこへ知らせ、どの程度の期間で直るのかが文書で示されていない点は、業務で使う基盤としては確かめておきたいところです。

配布の面では、デスクトップ向けの軽量版について、インターネットから取得した導入用の処理をそのまま端末で動かす方式が案内されています。一方、サーバー向けの実行ファイルの更新では、取得したファイルの改ざんを照合する手順があると書かれています。社内の端末で使う場合は、配布の経路と更新の方式を、社内の導入の決まりに照らしてから許可する必要があります。

悪用されうるリスク

GoClawはエージェントを動かすための基盤で、攻撃のための道具ではありません。それでも、使い方しだいで生まれうる危険はあります。以下は推測を含む整理で、GoClawが実際に悪用された事例は、2026年10月18日時点で確認した一次情報からは見つけられませんでした。

一つ目は、利用者の分離が崩れたときの影響の大きさです。一つの基盤に複数の顧客や部署をまとめるほど、設定の誤りや弱点が一度に多くの利用者へ及びます。とくにチャットの窓口のように、どの利用者に属するかが設定だけで決まる入口は、誤りが起きたときに気づきにくい経路です。二つ目は、外部から届く文章に紛れた指示です。入力の検査が既定で警告にとどまる以上、コマンドの実行やファイルの書き込みを許したエージェントが、外部の文章に誘導されて想定外の操作をする筋書きは考えられます。

三つ目は、エージェントを動かす入口が多いことです。管理画面、外部からの受け口、7種類のチャットの窓口、定期実行と、エージェントを起動できる経路が複数あります。鍵が漏れた場合、どの経路から誰が動かしたのかを後から追えなければ、被害の範囲を確定できないおそれがあります。四つ目は、自己進化の機能です。エージェントが自分の振る舞いを自動で調整する以上、いつ何が変わったかを人が把握できる記録が欠かせません。

導入を検討するときに確かめること

実際に検討するときは、動かす前に、文書と社内の取り決めで確かめられる点から整理します。下の手順は、ツールを動かす前の段階で終えられるものに絞っています。

この手順の要は、動かす前に「使ってよいか」と「どの守りが既定で働くか」を文書で確かめることです。機能の比較から始めると、ライセンスの問題に気づくのが導入の後になりがちです。順番を逆にしないことが、手戻りを防ぐ近道です。

企業が取るべき対策

一つ目は、公開されているソフトウェアを業務で使う前のライセンス確認を、例外なく決まりにすることです。ソースコードが公開されていても、商用での利用が認められているとは限りません。GoClawのように公開の途中でライセンスの表記が変わった例もあるため、確認した日付と文書の版を記録に残します。二つ目は、自己申告の守りを、自社の確認項目に置き換えることです。開発元の説明をそのまま安全性の根拠にせず、既定値と自社の設定を突き合わせます。

三つ目は、利用者を分ける単位の設計です。部署や顧客ごとに別の基盤を立てるのか、一つの基盤で分けるのかを、扱う情報の重さで決めます。機密度の高い情報を扱う部署は、基盤そのものを分ける選択肢も残しておきます。四つ目は、入口と鍵の棚卸しです。管理画面、外部からの受け口、チャットの窓口、定期実行の一覧を作り、使わない入口は閉じます。

五つ目は、記録の設計です。READMEは、大規模言語モデルの呼び出しを追跡する機能を内蔵していると説明しています。どのエージェントが、どの利用者のために、どの道具を使ったかを後から追えるよう、記録の保存先と見る人、頻度を決めておきます。記録があっても見る人がいなければ、異常は見過ごされます。

AIに任せる範囲と、人が決める範囲

GoClawは、エージェントにコマンドの実行やファイルの読み書き、外部とのやり取りまで任せる基盤です。さらに、エージェントどうしで仕事を渡し合い、自分の振る舞いを調整する機能まであります。だからこそ、先に決めるのは、AIに判断させない部分です。

具体的には、どの利用者のまとまりにどの情報を置くか、どの道具を許すか、コマンドの実行を誰が承認するか、エージェントの振る舞いの変化を誰が確かめるか。この四つはAIに委ねず、人が決めて記録に残します。エージェントには、操作の前に理由を書かせ、人が確かめられる形にしておくのが基本です。やってはいけない向き合い方を挙げます。

• ソースコードが公開されているからと、ライセンスを読まずに業務で使い始める
• 第三者の紹介ページの「MIT」という表記を信じて、公式の文書を確かめない
• 「5層の守り」という説明を、自社で確かめないまま安全性の根拠として社内に報告する
• 入力の検査を既定の警告のままにし、その記録を誰も見ない
• コマンドの実行を許したエージェントを、隔離を有効にしないまま動かす
• エージェントの自己調整を有効にしたまま、振る舞いの変化を誰も確かめない

裏を返せば、人が決める範囲ははっきりしています。使ってよいか、何を分けるか、何を許すか、誰が確かめるか。この四つが決まらないまま基盤を入れても、守りの厚みは増えません。

よくある質問：社内だけで使うなら商用利用に当たらないのか

答えは「この記事では断定できない」です。非営利の定義は「主として商業上の利益や金銭的な対価を目的としない」ことですが、営利企業が業務の効率化のために社内で使うことがこれに当たるかは、使い方によって解釈が分かれます。社内利用だから問題ないと現場が判断して進めないことが大切です。

では、評価のために文書を読むことも避けるべきかというと、そうではありません。公開されている文書を読み、仕組みや守りの考え方を学ぶことは、自社でエージェントの基盤を選ぶときの比較の材料になります。問題になりうるのは、業務での利用や、顧客に提供するサービスへの組み込みです。その段階に進む前に、法務の判断と、必要に応じて権利者からの許諾を得てください。

もう一つ、「元になったOpenClawなら商用で使えるのか」という問いもありそうです。OpenClawの公開リポジトリのライセンスはMITと記されており、条件は大きく異なります。ただし、二つは別のソフトウェアで、機能も守りの仕組みも同じではありません。ライセンスの条件だけで乗り換えを決めず、それぞれの守りと運営の体制を同じ観点で確かめる必要があります。

• GoClawの機能・版・守りの仕組み・ライセンスは、GitHubのリポジトリとその中の文書、公式サイトを2026年10月18日に確かめた範囲に基づきます。開発中の枝の内容を読んでおり、安定版とは異なる可能性があります
• ライセンスの解釈は法的な助言ではありません。商用利用に当たるかどうかの判断は、自社の法務と、必要に応じて権利者に確認してください
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

GoClawは、複数の利用者や顧客を分けてAIエージェントを動かす基盤です。OpenClawをGo言語で作り直したとうたい、利用者ごとの作業場所、エージェントどうしの協働、多数の道具とチャットの窓口を備えると説明されています。守りについては「5層」を掲げ、文書の記述は具体的ですが、あくまで開発元の自己申告です。入力の検査は既定で警告にとどまり、隔離は任意の設定とされます。

導入を考えるうえで最も大きな論点は、ライセンスです。現在の文書はクリエイティブ・コモンズの表示・非営利で、商用目的での利用は認められていません。公開直後のREADMEにはMITと書かれていたため、表記の食い違いにも注意が要ります。運営の実績も一年に満たず、弱点の報告窓口も文書で示されていません。使ってよいかを確かめ、既定値を一覧にし、人が決める範囲を先に決めることが、GoClawを検討するときの出発点です。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。