AIアシスタントを社内で使う企業が知っておきたい道具を隔離するOSS「IronClaw」の確認点

「社員が個人で使い始めたAIアシスタントに、メールやチャットの鍵を預けてしまっていないか心配だ」「安全を売りにしたAIアシスタントのOSSが出てきたが、どこまで信じてよいのか判断できない」——情報システム部門やセキュリティ担当の方から、最近こうした声を聞きます。安全をうたう道具が出てくると、それを選べば守りは済むと考えられがちです。しかし本当に問うべきなのは、その道具が何を守り、何を守らないのかを、自社の言葉で説明できるかという点です。この記事では、AIアシスタントが使う道具を一つずつ隔離し、鍵を道具に見せない設計をとるOSS「IronClaw」を取り上げ、守りの仕組み、データの送り先、運営体制について、企業が導入前に確かめたい点を整理します。導入や設定の手順は扱いません。

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

IronClawは、GitHubで公開されているAIアシスタントのOSSです。リポジトリの説明は「プライバシー、セキュリティ、拡張性に重点を置いたエージェントのための基盤」で、READMEの冒頭には「いつもあなたの側に立つ、安全な個人向けAIアシスタント」と書かれています。常に動き続け、チャットや定期的な処理を通じて利用者の代わりに作業する、常駐型のAIアシスタントとして作られています。

公開元を確かめます。リポジトリはNEAR AIの組織のアカウントで2026年2月3日に作られました。組織のアカウント自体は2017年6月に作られ、公開しているリポジトリは78件あります。このラインの精査を行った2026年10月19日時点で、スターは12,662、派生は1,482、最後の更新は10月18日でした。1日あたりのスターの伸びは約49件で、公開から8か月で大きな注目を集めていることが分かります。

ライセンスは、GitHubの表示ではApache-2.0ですが、READMEには「Apache 2.0とMITのどちらかを利用者が選べる」と書かれ、両方のライセンスの文書が置かれています。どちらも商用での利用を認める一般的なライセンスです。リリースは小刻みに出ており、確認した時点の最新の安定版は9月29日の1.4.1でした。試験版には「プレリリース」の表示が付いています。日本語のREADMEも用意されていますが、日本語で守りの仕組みや注意点を整理した資料は、確認した範囲では見つけられませんでした。

なぜ注目されているのか：OpenClawを安全重視で作り直したという位置づけ

READMEによると、IronClawは個人向けAIアシスタントのOpenClawに着想を得て、Rustという言語で作り直したものです。READMEの「OpenClawとの主な違い」の節では、Rustで書いて一つの実行ファイルにまとめたこと、道具の隔離にコンテナではなくWebAssemblyの箱を使うこと、何層もの守りと鍵の保護を最初から設計に組み込んだことが挙げられています。

公式サイトも、IronClawを「OpenClawの個人向けAIアシスタントを、簡単な導入と組み込みの守りで提供するもの」と紹介しています。AIアシスタントにメールやチャット、外部のサービスの鍵を預ける使い方が広がるにつれ、鍵がAIや道具の手元にあること自体が危ないという問題意識が強まっています。IronClawは、この問題に設計で応えようとする試みの一つと位置づけられます。

READMEの考え方の節には、「AIアシスタントは利用者のために働くべきで、利用者に背くべきではない」という一文があり、データは手元で暗号化して保存し外に出さないこと、隠れた利用状況の送信をしないこと、外から紛れ込んだ指示や情報の持ち出しに何層もの守りで備えることが並んでいます。これらは公開元の主張であり、第三者の監査で確かめられたものではない点は押さえておく必要があります。

何ができるのか：常駐するAIアシスタントとしての機能

READMEに載っている機能を、守りに関係する観点で整理します。まず利用の窓口です。端末での対話、外部からの通知の受け口、ブラウザで使う画面のほか、TelegramやSlackとつなぐ窓口が用意されています。利用者は普段使うチャットからアシスタントに頼みごとができる作りです。

次に、自動で動く仕組みです。決まった時刻や出来事をきっかけに処理を走らせる機能、監視や保守のために自ら定期的に動く機能、複数の依頼を並行して処理する機能、止まった処理を自動で立て直す機能が挙げられています。つまり、人が見ていない時間にも動き続けるAIだということです。便利な半面、何をしたかを後からたどれる仕組みが重要になります。

さらに、道具を増やす仕組みがあります。READMEは「必要なものを説明すれば、IronClawがそれを道具として作る」と書き、MCPのサーバーとの接続や、再起動せずに道具や窓口を足す仕組みも挙げています。記憶の機能として、過去のメモや記録を検索して使う仕組みもあります。AI自身が道具を作り、記憶を持ち、自分で動くという性格は、守りの設計を考えるうえで前提になります。

守りの柱1：道具を一つずつ箱に閉じ込める仕組み

IronClawの守りの中心は、道具の隔離です。READMEによると、信頼できない道具はWebAssemblyの箱の中で一つずつ動き、外部への通信、鍵の利用、ほかの道具の呼び出しは、それぞれ明示的に許可したときだけ使えます。道具の資料によると、箱の中の道具が使える機能は、記録の書き出し、時刻の取得、作業用の文書の読み書きに限られ、新しいプログラムを起動したり、外部の部品を読み込んだりはできないとされています。

道具ごとに、届いてよい宛先、触れてよいファイルの場所、使ってよい鍵、通信の回数の上限を宣言する仕組みです。ファイルへの接近は既定で切られています。計算量と記憶の量にも上限があり、既定では計算は1億命令、記憶は16メガバイトで、超えると道具はすぐに止められます。許可していない宛先への通信は、接続が張られる前に中継役が拒否すると資料にあります。

一方で、資料には「信頼できない出どころの道具を入れる前に、権限の宣言を確かめること」という注意書きがあります。箱の中で何ができるかは宣言しだいで、入れる道具と、与える権限の中身を確かめるのは利用者の役目です。なお、READMEには箱とは別に、コンテナで処理を隔離して動かす仕組みも載っています。

守りの柱2：鍵を道具に見せない設計と漏えいの検知

二つ目の柱は鍵の扱いです。READMEとセキュリティの資料によると、鍵は暗号化して保存され、道具は鍵を直接読めません。道具は必要な鍵を宣言するだけで、通信が外へ出る境目で、許可した宛先に限って鍵が差し込まれる作りです。道具の資料にも「道具は鍵の生の値を見ない」と書かれています。

鍵を暗号化する元の鍵は、端末の鍵の保管庫に置かれ、設定ファイルには書かれないと導入の資料にあります。8月27日の1.4.0の更新では、箱の外へ出る通信を利用者ごとの中継役でまとめて扱うようになり、鍵は箱の中のプログラムに渡されないことが改めて示されています。

加えて、漏えいの検知があります。セキュリティの資料によると、言語モデルに渡す入力を、利用者の入力も道具の結果も含めて調べ、外部サービスの鍵、合言葉、秘密鍵、接続文字列などの形をしたものを見つけます。公式サイトは、外へ出る通信を常に調べ、鍵らしきものを止めると説明しています。ただし、決まった形に当てはまらない秘密は見逃しうることは、形で見つける方式の性質上、前提として考えておくべきです。

守りの柱3：外から紛れ込む指示への備え

三つ目の柱は、外から紛れ込む指示への備えです。メールやウェブのページ、チャットの書き込みに仕込まれた文で、AIに本来の依頼と違う動きをさせる手口は「プロンプトインジェクション（外から紛れ込ませた指示でAIを操る攻撃）」と呼ばれます。セキュリティの資料は、入力の長さや文字の検査、危ない内容を無害にする処理、深刻さに応じて止める・警告する・確認に回す・無害化するを決める方針の仕組み、漏えいの検知、道具の結果を目印で包んでからAIに渡す処理の五つを挙げています。

リリースノートからも、この考え方が読み取れます。1.2.0では、Slackの過去の書き込みを信頼できない引用としてAIに渡すように改められ、共有の場では書き込んだ人ごとの権限と承認の関門で動くようになったとされています。1.4.0では、承認や認証を求める通知を、見逃しても後から確認できるように残す仕組みが加わりました。

ただし、紛れ込んだ指示を完全に見分ける方法は、現時点では業界全体でも確立していません。資料が挙げる守りは被害を小さくするための層であり、すべてを防ぐ壁ではないと受け止めるのが妥当です。どの操作を人の承認に回すかは、利用者の側で決めておく必要があります。

データはどこに置かれ、どこへ送られるのか

READMEは、データは手元の保存領域に置かれ、鍵は暗号化され、利用状況の送信や分析、データの共有はしないと書いています。セキュリティの資料にも「知らない宛先へ黙って通信しない」とあります。一方で、AIアシスタントである以上、会話の中身は言語モデルの提供元に送られることは避けられません。

言語モデルの接続先の資料によると、IronClawは20を超える提供元に対応しています。その表で既定とされているのは、提供元自身のNEAR AIです。ほかに大手の言語モデルの各社や、手元で動かすOllamaなども選べます。導入時に提供元と型を選ぶ流れですが、既定のまま進めれば会話がどこに届くのかを、社内の情報の扱いの決まりと照らして確かめる必要があります。資料には、各提供元がデータをどう保存し扱うかの説明はありません。

もう一つ、動作の記録を外部に提供する仕組みがあります。資料によると、利用者が自分の動作の記録を伏せ字にしたうえで提供し、見返りにクレジットを得られる仕組みで、既定では切られており、明示的に有効にしない限り何も外に出ないとされています。ただし、管理者がまとめて有効にすれば利用者全員に及ぶ設定もあり、取り消しても、すでに受け取られた写しは別途削除を求めない限り残ると書かれています。社内で使うなら、この機能を有効にしない方針を決めておくのが安全側です。

自社で動かすか、提供元の環境を使うか

IronClawは、自社の端末やサーバーで動かすこともできますが、公式サイトでは提供元のNEAR AIのクラウドで動かす有料の形も案内されています。公式サイトによると、無料から月額20ドル、月額200ドルまでの料金の段階があり、上位ほど動かせるアシスタントの数と使える量が増えます。

提供元のクラウドで動かす場合、公式サイトは、外から中身をのぞけない特別な実行環境の中で動き、クラウドの運営者でさえデータを見られないと説明しています。起動から停止まで記憶の中身が暗号化されるとも書かれています。ただし、これは提供元の説明で、仕組みの詳細や第三者の監査結果は、確認した範囲の公式サイトには載っていませんでした。

企業として判断するなら、自社で動かす場合は、守りの運用と更新の責任を自社で持つことになります。提供元の環境を使う場合は、データの保存場所、保存期間、契約上の扱いを、通常のクラウドの調達と同じ基準で確かめることになります。公式サイトには、個人情報の扱いの方針や、データの保存場所についての説明は見当たりませんでした。

似た手段との比べ方

AIアシスタントの守り方には、いくつかの考え方があります。確認できた範囲の事実をもとに、どこで守るかの違いとして整理します。優劣ではなく、守る場所の違いとして読んでください。

見る点	一般的なAIアシスタントの利用	コンテナで隔離して動かす	IronClaw
道具の隔離	提供元の作りに左右される	アシスタント全体を一つの箱に入れる	道具を一つずつ箱に入れる
鍵の置き場所	アシスタントや道具の手元に置かれやすい	箱の中に置かれやすい	暗号化して保存し、外へ出る境目で差し込む
通信先の制限	設定しだい	網の設定で絞る	道具ごとに許す宛先を宣言する
言語モデルの接続先	提供元が決める	利用者が決める	利用者が選ぶ（既定は提供元）
守りの説明の出どころ	提供元の資料	仕組みとして確かめやすい	公開元の資料と公開されたコード

表のとおり、IronClawの強みは、道具ごとに権限と宛先を分け、鍵を道具から切り離す点にあります。一方で、会話を送る言語モデルの選び方や、どの道具を入れるかは利用者の判断に残ります。端末全体の守りや社内の網の設定と重ねて使うものと考えるのが妥当でしょう。

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

このラインでは、紹介するOSSを公開されている事実だけで精査しています。OSSを入手したり動かしたりはしていません。IronClawの判定は「注意付き」です。運営体制や配布の形に大きな問題は見当たらない一方で、導入する企業が必ず確かめるべき点が二つあるためです。

まず、問題が見つからなかった点です。運営はNEAR AIの組織のアカウントで、2017年に作られ、公開リポジトリは78件あります。ライセンスはApache-2.0（READMEではMITとの選択制）で、商用も含めて使えます。GitHub上にこのリポジトリのセキュリティ勧告は登録されていません。リポジトリの直下にはコンテナを組み立てるためのファイルがありますが、利用者が自分で使うもので、取り込んだだけで自動的に動く処理ではありません。スターの伸びは1日あたり約49件と速いものの、組織の実績や派生の数、更新の頻度と照らして、不自然な水増しの兆候は見られませんでした。

次に、注意付きとした理由です。一つ目は、言語モデルの接続先の資料で既定とされているのが提供元のNEAR AIで、既定のまま使うと会話が外部の提供元に送られることです。二つ目は、セキュリティ方針の文書がなく、弱点を見つけたときの報告の窓口と修正の対象となる版が示されていないことです。どちらも次の節で詳しく見ます。

なお、問題が見つからなかった点も含めて、安全の保証ではありません。精査は公開情報の範囲に限られ、コードの中身を検証したものではないからです。AIアシスタントは鍵と会話を預かる道具である以上、評価は導入する側でも重ねる必要があります。

企業が確認しておきたい注意点

第一に、セキュリティ方針の文書がない点です。GitHubのセキュリティの画面には、方針の文書がまだ用意されていないと表示されています。弱点を見つけたときの報告の窓口と、修正の対象となる版が明示されていないことになります。9月29日の1.4.1では、道具の箱を動かす部品を更新し、計算量の数え方に関する最近の弱点を直したとリリースノートにありますが、弱点の中身や深刻さは書かれていません。

第二に、言語モデルの既定の接続先が提供元のNEAR AIである点です。前の節で見たとおり、導入時に選び直せますが、既定のまま使えば会話は提供元に届きます。第三に、提供元の背景です。NEAR AIは、暗号資産の基盤として知られるNEARの名を冠し、公式サイトにもその関連の窓口へのリンクがあります。確認した一次情報の範囲では、IronClaw自体に暗号資産の機能は見当たりませんでした。一方、第三者の情報では、この名前に便乗した非公式の暗号資産があるとの話も見られますが、一次情報では確かめていません。公式を名乗る関連の勧誘には、社内でも注意を呼びかけておくのが安全側です。

第四に、強い権限を扱う機能がある点です。1.4.0のリリースノートは、任意で有効にする遠隔ログインの窓口について、その秘密鍵を「サービスへの操作権限そのもののように扱うこと」と注意しています。1.3.0では、Telegramの端末連携により、アシスタントが利用者として振る舞える機能が加わったとされています。どれも既定で有効になるものではありませんが、使う場合は権限の重さを理解したうえで判断する必要があります。

悪用されうるリスク

IronClawは守りを重視したAIアシスタントで、攻撃のための道具ではありません。それでも、使い方しだいで生まれうる危険はあります。最も大きいのは、「安全なアシスタントだから、何を預けても大丈夫」という安心が独り歩きすることです。守りは宣言した権限と許した宛先の範囲で働くもので、広い権限を与えれば、その範囲ではアシスタントは何でもできます。

次に挙げるのは推測ですが、検討の材料になります。道具を外部から入れられる仕組みがある以上、便利な道具を装って広い権限や宛先を求める道具が出回る可能性があります。資料が権限の宣言を確かめるよう注意しているのは、この点への備えと読めます。また、アシスタントが道具を自ら作る機能は、作られた道具の権限を誰が確かめるのかという問題を生みます。

もう一つは、社員が業務の鍵を個人のアシスタントに預ける、いわゆる管理外のAI利用です。IronClawが鍵を丁寧に扱う作りであっても、会社が把握していない場所で業務のメールやチャットの鍵が使われること自体が問題です。なお、IronClawが実際に悪用された事例は、2026年10月19日時点で確認した一次情報からは見つけられませんでした。

導入を検討するときの確認点

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

この手順の要は、道具の守りを信じる前に、預けるものと送る先を人が決めることです。守りの仕組みは、決めた範囲を超えないように支えるもので、範囲そのものを決めてはくれません。

企業が取るべき対策

一つ目は、社員が使っているAIアシスタントの棚卸しです。IronClawに限らず、常駐型のAIアシスタントに業務の鍵を預けている例がないかを確かめます。業務の鍵を預けてよいアシスタントと条件を、会社として決めて示すことが出発点です。

二つ目は、送り先の管理です。会話が届く言語モデルの提供元を、社内で認めたものに限ります。三つ目は、道具の受け入れの基準です。外部の道具を入れる前に権限と宛先を確かめる担当を置き、広い権限を求める道具は理由を確かめてから認めます。道具の追加を、ソフトウェアの導入と同じ審査に乗せる考え方です。

四つ目は、記録の活用です。IronClawは道具の実行の記録を残すとしています。記録を残すだけでなく、誰がどの頻度で見るかを決めておかなければ、問題が起きても気づけません。五つ目は、調達のときの確認です。セキュリティ方針の文書がないこと、試験版と安定版が分かれていること、提供元の環境を使う場合のデータの扱いを踏まえ、社内で使える段階かどうかを文書で判断します。

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

IronClawは、AIに日々の作業を任せるためのアシスタントで、自ら動き、道具を作り、記憶を持ちます。だからこそ、AIに判断させない部分を先に決める必要があります。

具体的には、どの鍵を預けるか、会話をどこへ送るか、どの道具と宛先を許すか、どの操作を人の承認に回すか。この四つはAIにも道具にも委ねず、人が決めて記録に残します。アシスタントに作業を任せる場合も、操作の根拠を書かせ、取り返しのつかない操作の前には人が確かめる流れにしておくと、後から判断を振り返れます。人が確認する範囲を先に決めておくことが、任せる範囲を広げる前提になります。やってはいけない向き合い方を挙げます。

• 安全をうたう作りであることを理由に、業務のメールや顧客管理の鍵を広い権限のまま預ける
• 言語モデルの接続先を確かめず、既定のまま社内の情報を含む会話を送る
• 外部から入れる道具の権限の宣言を読まずに追加する
• アシスタントが自ら作った道具を、人が中身と権限を確かめないまま使い続ける
• 送信や削除などの操作を、人の承認を挟まずにアシスタントに任せる
• 動作の記録を外部に提供する機能を、社内の決まりと照らさずに有効にする

裏を返せば、人が決める範囲ははっきりしています。何を預け、どこへ送り、何を許し、何を人が承認するか。この四つが決まっていないまま使い始めても、守りの仕組みは本来の力を発揮できません。

よくある質問：安全を重視したアシスタントなら社内で使ってよいのか

答えは「作りだけでは決められない」です。IronClawは、道具を一つずつ隔離し、鍵を道具から切り離し、許した宛先にしか通信させない作りを持っています。これは、AIアシスタントに鍵を預ける危険を確かに小さくする工夫です。一方で、会話の送り先、入れる道具、与える権限は利用者の判断に残ることも、資料から読み取れます。

「公開元が利用状況を送らないと書いているなら、外への送信は心配いらないのではないか」という問いもありそうです。READMEの記述は、IronClaw自体が利用状況を集めないという意味で、言語モデルの提供元に会話が届くこととは別の話です。社内で判断するときは、アシスタント本体の送信と、言語モデルへの送信、外部のサービスへの通信を分けて確かめるのが確実です。

もう一つ、「提供元のクラウドなら運営者も見られないので安心ではないか」という問いもあるでしょう。確認した範囲では、その仕組みの詳細や第三者の監査結果は公式サイトに示されていませんでした。提供元の説明を前提にしつつ、契約とデータの扱いを通常の調達と同じ基準で確かめる、という分け方が妥当でしょう。

• IronClawの機能・版・守りの仕組み・接続先は、GitHubのリポジトリとその中の資料、リリースノート、公式サイトを2026年10月19日に確かめた範囲に基づきます。更新が速いため内容は変わる可能性があります
• 守りの仕組みの効果、提供元のクラウドの実行環境の詳細、言語モデルの提供元ごとのデータの扱いは、確認した一次情報の範囲では十分に確かめられませんでした。導入の判断では最新の資料を確認してください
• この記事は守りと評価の目線で書いています。導入・設定・実行の手順は扱いません

まとめ

IronClawは、NEAR AIの組織が公開する個人向けAIアシスタントのOSSです。OpenClawに着想を得てRustで作り直し、道具をWebAssemblyの箱で一つずつ隔離し、鍵は暗号化して保存したうえで外へ出る境目で差し込み、許した宛先にしか通信させない作りをとっています。ライセンスはApache-2.0（MITとの選択制）で、GitHub上にセキュリティ勧告は登録されていません。

一方で、セキュリティ方針の文書はなく、言語モデルの既定の接続先は提供元のNEAR AIとされています。入れる道具の権限や、人の承認に回す操作も、利用者が決める範囲です。預ける鍵、会話の送り先、許す道具と宛先、人が承認する操作を先に決めたうえで使うことが、AIアシスタントに日々の作業を任せる時代のIronClawとの付き合い方です。

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