DuDuClaw OSアプライアンス
電源とLANケーブルをつなぐだけで、小型PCがヘッドレスなAIスタッフに 変わります。2分もかからずダッシュボードがLAN上に立ち上がり、 モニターもキーボードも不要です。
DuDuClawは通常、すでに管理しているマシンにインストールするバイナリと して動きます。アプライアンスはその対極にあるものです。既製の小型 ミニPCを、DuDuClaw専用機に変える起動可能なディスクimageです。設定す るOSも、インストールする依存関係も、開くターミナルもありません。電源 を入れれば箱はそのままDuDuClawに直行し、そこにとどまり続けます。電源 投入後のすべての作業は、自分のLAN上のブラウザで完結します。
対象ユーザーはDuDuClawの他の部分と同じです。Telegram/LINE/Discord/ Slackを24時間見張ってくれるAIスタッフが欲しいけれど、そのためだけに ノートPCを1台割り当てたくない、アカウントの認証情報を第三者に預けた くもない、という人向けに作られています。
電源投入から準備完了まで
Section titled “電源投入から準備完了まで”- インストール。 各リリースはマシンごとに2つの形式で提供されま
す。liveインストーラーISOは、USBメモリに書き込む(またはディスク
に焼く)、対象マシンをUEFIモードで起動しSecure Bootをオフにす
る(公開されているimageはSecure Boot署名済みではないため、詳しく
は下記の「エディションとデスクトップ」と信頼チェーンの説明を参照
)、グラフィカルなインストーラーで内蔵SSDを選ぶ、そしてインストー
ル済みのシステムに再起動する、という流れです。ディスク全体の
image(
.wic.zst)はインストーラーを使わず、展開してそのまま対象 ディスクに書き込みます。チャネル経由で導入された機体で、出荷前に ドライブが書き込み済みの場合は、この手順自体を丸ごとスキップでき ます。 - 初回起動。 箱はネットワークに触れる前にNTPで時刻を同期し、デ
フォルトのタイムゾーンを設定します(時刻がずれているとOAuthやTLS
が静かに壊れるため、これを最初に行います)。続いて有線DHCPでアドレ
スを取得し、
duduclaw.localとしてLAN上に自分の存在を通知します。 ダッシュボードは箱自身だけでなくローカルネットワークにバインドさ れて立ち上がりますが、ファイアウォールが通すのはダッシュボードの ポートと探索プロトコルだけです。箱の他の部分にはどこからも到達で きず、デフォルトでパブリックインターネットに公開されることも一切 ありません。 - 接続。 同じネットワーク上のMac、iPhone、Windowsマシンから
http://duduclaw.localを開きます。Androidは.localアドレスを解 決できないため、箱は自分のアドレスを直接表示する小さな付随の探索 ページも提供します。セットアップが終わる前に最初に接続した人が、 セットアップを行う人になります。これは他のセルフホスト型アプライ アンスと同じ、早い者勝ちの慣習です。 - 管理者を設定し、言語を選んでタイムゾーンを確認します。
- モデルアカウントとチャットチャネルを接続します。 セットアップ
ウィザードが箱の上で
claude setup-tokenを実行し、リンク(とQRコー ド)を表示します。自分のブラウザでそれを承認し、短いコードを箱に貼 り戻すと、箱は何かを保存する前に実際にAPIを1回呼び出すので、無効 または期限切れのトークンが有効なものと誤認されることはありませ ん。開始前に、ウィザードはサブスクリプションのリスク説明を表示し、 同意を求めます。Anthropic の規約 では、サードパーティ製品が Claude.ai の認証情報を収集・保存すること や、Free/Pro/Max プランの認証情報でユーザーの代わりにリクエストを中 継することは認められておらず、予告なく執行される場合があります。API キーを直接貼り付ける方法もあり、その場合はOAuthの手順は一切不要で、 Anthropic が製品向けに案内している方法でもあります。チャットチャネルについては、Telegram、Discord、Slack、 Webチャットは直接アウトバウンドで接続できるので、トークンを貼るだ けです。LINEなどwebhook型のチャネルは、家庭用ルーターのNAT配下に ある箱では何も受信できないため、公式のリレーサービスを経由しま す。リレーは箱自身が開いた接続の上で不透明なバイト列を転送するだ けで、受信した各webhookの実際の署名検証は今もリレーではなく箱の側 で行われます(詳細は下記のセキュリティ設計を参照)。 - 業種テンプレートを選びます。 これで最初のAIスタッフが作成され るので、いま接続したばかりのチャネルでテストメッセージを送ってみ てください。返信が来れば、ダッシュボードが単に読み込まれただけで はなく、箱がエンドツーエンドで実際に動いていることの確認になりま す。
- スタンバイ。 ここから先、箱はただ動き続けます。systemdの watchdogがハングしたgatewayプロセスを再起動し、起動失敗が連続する と自動的に前のOSバージョンにフォールバックして、詰まったままには なりません。
デバイスページ
Section titled “デバイスページ”アプライアンスとしてインストールするとデバイスページが追加されま す。これはアプライアンスでのみ表示されるページで、通常のデスクトップ 版やサーバー版のインストールではナビゲーションにまったく現れず、ペー ジ自体もアプライアンス以外の環境では、誤解を招く表示をするくらいなら と、描画そのものを拒否します。
- ステータス——CPU/メモリ/ディスク/温度/ネットワークのライブス ナップショット。
- アップデートセンター——OS自体はDuDuClawアプリケーションとは独 立して、A/Bパーティション方式で更新されます。アップデートを適用 し、その後箱が起動に失敗した場合は、以前実行していたバージョンに 自動的にフォールバックします。オンデマンドのワンクリックロールバ ック(失敗時に自動で行われる種類とは別のもの)は、意図的に「まだ利 用不可」として報告されており、当て推量では済まされていません。基 盤となる更新ツールには組み込みの「undo」コマンドがなく、仕組みを 確信できないままブートスロットを選ぶと、デバッグ用の画面が何もつ ながっていない箱を文鎮化させるリスクがあるためです。
- ネットワーク——現時点では箱のネットワークインターフェースの読 み取り専用ビューです。ダッシュボードから静的IPを編集する機能はま だ配線されていません。
- バックアップ——箱が学習・保存してきたすべて(エージェントの記 憶、会話履歴、設定)をダウンロード可能な1つのファイルにアーカイブ します。
- 危険ゾーン——工場出荷時リセット(ボタンを押すだけでなく「RESET」 という単語を入力して確認する必要があります)、再起動、シャットダウ ンで、それぞれ個別の確認が必要です。
このページにあるものはすべて、他に2つの入口からも到達できます——AIスタッフ
がツールとして呼び出すことができ、オペレーターは本体の端末から実行できます。
3つとも同じ1つの実装(crates/duduclaw-gateway/src/os_ops.rs)を通るので、
どの入口から来たかで答えが変わることはありません。異なるのは権限チェック
だけです——入口ごとに「誰が尋ねているか」を知る方法が違うからです。詳細は
33-os-native-perception.md を参照してください。
エディションとデスクトップ
Section titled “エディションとデスクトップ”DuDuClaw OSのimageはどれも、起動するとDuDuClaw自身のデスクトップに 入ります。専用のcompositorとshellを備え、ロック画面、初回起動ウィザ ード、そしてどのアプリからでもAIスタッフに作業を任せられるCmd+Kバー が用意されています。人とAIは同じマシンを共有しますが、compositorは 人が常に入力の主導権を持つことを保証します。キーボードやマウスに触 れた瞬間、その時AIが画面上で行っていた操作はすべて凍結します。その 仕組みと、AIがあなたのデスクトップ上で何をしてよいか、何をしてはい けないかについては、別記事にまとめています: 52-desktop-edition.md。
リリースごとに2つのimageが提供され、そのデスクトップの上に何が乗る かで違いがあります。
| image | 概要 | 提供形態 |
|---|---|---|
デスクトップ版(duduclaw-image-appliance) |
フルスペックのマシン全体: デスクトップに加えて、オフラインでプリロードされたChromium / LibreOffice(SteamはFlathubからインストール)、アプリ互換レイヤー(Bottles、Windows VM、Waydroid)、読み取り専用ルート、ファイアウォール、初回起動時のプロビジョニング、ログイン強化。 | ディスク全体の.wic.zstと、専用の live インストーラー ISO(installer-desktop、v0.1.0(2026-09-04)から出荷継続中)。 |
ベースイメージ(duduclaw-image-ab) |
同じA/B構成、デスクトップシェル、gatewayを持ちながら、アプリ互換レイヤーと読み取り専用ルートは含みません(ファイアウォールはv0.4.0からデスクトップ版と同じものが入り、v0.3.0以前にはありません)。製品ではなくbring-up成果物という位置づけです。 | 通常の live インストーラー ISO(installer)に収められているペイロード。 |
モニターが接続されていないときにデスクトップがどう振る舞うか、つま りヘッドレスなダッシュボードのみの箱にフォールバックするのかどうか は、実機ではまだ定義されておらず、未解決のbring-up項目です。上で説 明したLAN上でダッシュボードが立ち上がる流れは、画面の有無にかかわら ず同じように動作します。それを提供しているのはデスクトップではなく gatewayだからです。
セキュリティ設計
Section titled “セキュリティ設計”- root権限が必要な操作は、コマンドが固定された小さなヘルパーを通り
ます。 root権限が必要な操作(再起動、シャットダウン、OSアップデー
トの適用とロールバック、工場出荷時リセット、ネットワークと時刻の設
定)は、独立したヘルパー
duduclaw-sysdが処理します。ローカルのUnix ソケット越しに受け付けるのは20個(プラットフォームv1.74.0までは18個) の固定コマンドだけで、何かを実行す る前に呼び出し元のユーザーidを確認します。許可する呼び出し元が設定 されていなければ、すべてのリクエストを拒否します。DuDuClaw OS v0.4.0 (プラットフォームv1.73.4を同梱)から、gatewayは専用の非rootユーザー (duduclaw、uid 1000)で動き、ヘルパーはgatewayのメインプロセスから のリクエストだけを受け付け、OSアップデートをインストールする前に署 名・ハッシュ・バージョンを自分で検証し、v0.4.0より古いimageへのロー ルバックを拒否します。AI社員はgatewayと同じユーザーで動くため、これ で防げるのは社員がrootを得ることで、gateway自身の権限を使うことは防 げません(セキュリティ防御を参照)。v0.3.0 以前のimageではgatewayがまだrootで動き、ヘルパーもrootを受け付けるの で、そこではこの分離はgatewayにできることを制限していません。 - 着信接続は既定で拒否され、SSHは既定でオフです。 DuDuClaw OS
v0.4.0から、デスクトップ版とベース版(通常の
installerISOで書き込む もの)の両方にファイアウォールが入り、通すのはダッシュボードのポート (18789)、ローカルネットワーク探索用のmDNS(UDP 5353)、pingなどの基 本的なICMPだけで、それ以外の着信はすべて破棄します。imageには dropbear SSHサーバーが入っていますが、既定では無効です。ダッシュボー ドのメンテナンスモードにあるSSHスイッチ(プラットフォームv1.73.3以 降。v0.4.0はv1.73.4を同梱)は、duduclaw-sysdにdropbear.socketを 起動させ、ファイアウォールのmaintenance_tcp_portsセットに22番を追加 し、ウィンドウが閉じるとdropbearを停止してセッションのプロセスをすべ て終了し、ポートを外します。imageにはまだSSHでログインできるアカウン トがありません(rootはロックされ、dropbearもrootログインを拒否しま す)。そのため、このスイッチが現時点で制御できるのはポートだけです。 未リリースのプラットフォームコード(CHANGELOGの[Unreleased])は、 メンテナンスログインのヘルパー側を追加します。専用アカウントduduclaw-maint(uid 4800)とウィンドウごとに1つの公開鍵を使い、 ヘルパーが鍵を確認して設置し、ウィンドウが閉じると削除します。期限 と監査ファイルもヘルパーが持ちます (セキュリティ防御を参照)。OSイメージがこのアカウントを同梱 するまでは何も変わらず、同梱したイメージではポートを開けるだけの従 来のスイッチをヘルパーが拒否します。 未リリースのgateway側は、技術者の公開鍵を確認文字列・パスワードの 再入力と同じリクエストで受け取り(5回続けて間違えると15分間開けなく なります)、ヘルパーに頼む前にウィンドウを記録し、ポートだけを開ける 方式には戻りません。v0.4.0以前や一部だけ更新されたimageでは、SSHの 選択肢は非対応と表示されます。gatewayの起動時に始まる別のバックグラウ ンド処理が、期限でのクローズ、対応するウィンドウのない鍵のクローズ、 ヘルパーのログイン記録のメンテナンス履歴への転記を行い、ウィンドウを 開いたときには鍵とデバイスのフィンガープリントをすべての管理者に通知 します。クローズ時にヘルパーへ届かない場合は「未確認」と記録し、閉じ たとは記録しません。 v0.3.0以前のimageでは、dropbearが起動時から22番ポートで待ち受けま す。デスクトップ版のファイアウォールはこれを通さないため、ネットワー クからSSHには届きませんが、ベース版にはファイアウォールがなく、 dropbearとダッシュボードのポートにLANから到達できます。これらのimage が同梱するのはプラットフォームv1.73.1以前で、v1.73.2までのSSHスイッ チはどちらの状況も変えませんでした。このスイッチが起動・停止していた のはssh.serviceという名前のユニット(以前のDebianベースのimageで使っ ていた名前)で、これらのimageには存在せず、ファイアウォールのルール も追加しませんでした。こうしたimageでv1.73.3以降のgatewayを動かして もSSHは開けません。デスクトップ版のファイアウォールにはメンテナンス 用ポートセットがないため有効化は拒否され、拒否後に行う無効化で元か ら動いていたdropbearが止まります。ベース版でも無効化すると同じく止ま ります。どちらも再起動するとdropbearはまた起動します。 - webhookリレーはチャネルのシークレットを一切見ません。 それを 必要とするwebhook型チャネルについて、リレーの役割は、箱自身が最初 に開き自分の鍵で認証した接続の上で、着信リクエストの生バイト列を 転送することに限定されています。リレー自体は署名を検証すること も、チャネルのシークレットを保存することも、ペイロードを解析する こともありません。万が一リレーが侵害されても、そこには漏らして困 るようなものは何もありません。
- ロック画面はメールアドレスを知らなくてもパスワードを確認できま
す。(DuDuClaw OS v0.3.0 以降で利用でき、
duduclaw-shell1.65.3 と プラットフォーム v1.73.1 を同梱しています。v0.2.0 以前のイメージでは、 ロック画面は今もadmin@localとしてパスワードを確認します。)gatewayのPOST /api/owner/verifyに{"password": "..."}を送 ると、gatewayはオーナーフラグでオーナーアカウントを見つけます。その ためadmin@localを自分のアドレスに変えた後もロックを解除できます。 このエンドポイントが返すのは一致({"ok": true})か不一致(401)だけ で、ログイントークンを発行することも、メールアドレスを返すこともあ りません。呼び出せるのはこのマシン自身からだけで、リバースプロキシを 経由したリクエストは拒否します。ローカルの呼び出し元はすべて1つの試 行上限を共有し、オーナーに対するローカルの/api/loginとも共有します (15分間に5回)。そのため、パスワードを推測する別ルートにはなりませ ん。その代わり、マシン上の任意のプログラムがこの5回を使い切れます。 15分の枠は固定なので、動き続けるプログラムは枠がリセットされるたび に再び使い切ることができ、そのプログラムが動いている間はロック画面 が解除を拒み続けます。マシン上ですでに悪意あるプログラムが動いてい るなら、ロック画面が開かないことより深刻な問題なので、このトレード オフを受け入れています。対処法は、そのプログラムを見つけて止めるこ とです。 - imageについて「私たちを信じてください」という部分は一切ありませ ん。 imageを生成するビルドレシピは公開されています(下記の「自分 でビルドする」を参照)。そのため、誰でも書き込む前にすべての行を読 んで、箱の中に何が入っているかをベンダーの言葉だけに頼らず確認で きます。
自分でビルドする
Section titled “自分でビルドする”imageは正体不明のバイナリとして出荷されているわけではありません——公
開されているYocto layerからビルドされたもので、自分のマシンで監査・
再現でき、リリースごとの成果物にはすべてSHA-256とminisign署名が付い
ています。2026-09以降、このlayerとそのリリースパイプラインは、独立
したDuDuClaw-OSリポジト
リに置かれています。署名済みリリースのダウンロード先やソースからの
ビルド方法は
ビルドガイドを参照してくだ
さい。公式サイト
os.duduclaw.dudustudio.monster
の/docs/配下には、このページを含むOSの全ドキュメント(README、
CHANGELOG、SECURITYを含む)が同期されています。
これはプラットフォームの中でもまだ若い部分であり、話を盛らずに現状を 率直に伝えておく価値があります。DuDuClaw OS v0.4.0(2026-10-16、 プラットフォームv1.73.4を同梱。以前のv0.3.0、v0.2.0、v0.1.0はReleases ページに残っていますが、v0.4.0で一度正常に起動したデバイスはそこへ戻 れません)時点では、次のとおりです。
- x86-64のimageは両方のマシン向けに、マシンごとに3つの形式(デスク
トップ版のディスク全体image、デスクトップ版のliveインストーラー
ISO、ベースイメージのliveインストーラーISO)で存在し、公開されて
おり、すべてSHA-256とminisignで署名済みです(ディスク全体imageに
は来歴確認専用の
.manifest.jsonも付属します)。v0.4.0では、QEMU マシンのディスク全体imageがQEMU(ソフトウェアエミュレーション、KVM なし)でリリース前の起動スモークテストに通り、約65秒でログインプロン プトに到達しました。QEMUマシンのインストーラーISO 2本も、それぞれ約 125秒でlive環境のrootの自動ログインまで起動しました。インストールウ ィザードは最後まで通していません。実機のマシン (duduclaw-genericx86-64)はビルドしたものの起動テストはしておらず、 実機での起動もまだ行っていません。 - 非rootのgatewayは、QEMUマシンのデスクトップ版のテスト用imageで、ビ
ルドサーバー上の同じヘッドレスQEMUを使って2回検証しました。2回目は
36項目中35項目が通り、通らなかった1項目は
duduclaw doctorの見出しで す(コンテナ機能は正しく無効になっていたのに、見出しはPASSのままでし た)。この文言はプラットフォームのmainブランチで修正済みで(#132)、 v1.73.4より後の変更です。v0.4.0で未検証なのは、既存のv0.3.0デバ イスをA/Bアップデートで上げる経路(データ所有権の移行、古いブートエン トリの後片付け)、LLMの認証情報が必要なタスクサンドボックス／コンピュー タ操作／Discoveryの全体の流れ、Windows VM(KVMが必要)、実機でのWi-Fi と音声、duduclaw-genericx86-64の起動です。 - v0.4.0へのアップグレードは一方向です。
duduclaw-sysdはv0.4.0より古 いimageへのロールバックを拒否し、v0.4.0の最初の起動が正常と記録され ると古いブートエントリが削除されるため、ブートローダーもそこへ戻れ ません(それらのimageはgatewayをrootで動かします)。後の版に問題があ れば、より新しいimageを入れるかレスキューエントリを使います。 - 実機での完全な検証、つまりメディアを書き込み、起動し、インストー ルし、セットアップを一通り実行し、チャットチャネルでメッセージを やり取りし、OSアップデートを適用し、強制的にロールバックさせ、工 場出荷時リセットを実行するところまで、実際に認証済みのハードウェ ア上ですべて行うことは、まだ行われていません。これが現時点で最も 重要な未解決項目です。
- 信頼チェーンはビルドレイヤーには配線済みですが、公開されている
imageで有効化されているのはその一部だけです。v0.1.0で出荷され、
v0.4.0でも有効なのは、ロールバック付きのA/Bアトミックアップデート
(v0.4.0からはv0.4.0より前には戻れません)、デスクトップ版における読
み取り専用ルート、そしてすべてのリリース成果物に付くminisign署名で
す。v0.4.0時点でも
有効化されていないビルド時オプションは、UKIのSecure Boot署名
とdm-verityによるルート検証(どちらも
sb-signingビルドオーバーレ イに由来)、およびTPM2 + LUKSの鍵封印(tpm-luksオーバーレイ。その 自動登録は今も未解決の欠陥であり、これを解消するには実機のTPMが必 要です)です。これまでどのリリースもこの2つのオーバーレイを連結し ていません。release-os.shはビルドごとにreleaseオーバーレイを1つだ け重ねます(既定はserial1.yml。v0.3.0ではrelease-linux-builder.ymlを使い、これはビルドの並列度を調整してSPDX出力をオフにするだけで す)。公開されたv0.3.0のディスク全体imageを分解して確認したところ、 verityパーティションがなく、UKIとブートローダーにも署名がないため、 Secure Bootをオフにした状態で起動します。v0.4.0のリリースノートも、 Secure Boot、dm-verity、TPM2はリリースimageでまだ有効になっていない と明記しています。 - OSはプラットフォームとは独立してバージョニングされています
(
0.xは立ち上げ段階、1.0.0が最初のGAを示します)。リリースごと の状況は DuDuClaw-OSのCHANGELOG にあります。
これらのいずれも、今日リリースを書き込んで試すことの妨げにはなりませ ん。これらは、起動失敗を自力でデバッグすることに抵抗がない人以外にも 渡せるものにアプライアンスがなるまでに、残っている作業です。
メンテナンス SSH 画面（未リリース）
Section titled “メンテナンス SSH 画面（未リリース）”「デバイス → メンテナンス」で管理者が期間と機能を選択し、
パスワードを再入力して MAINTENANCE と入力します。SSH を選ぶ場合は、
技術担当者の OpenSSH 公開鍵が 1 つ必要です。画面は形式を確認し、
秘密鍵を貼り付けると送信前に消去します。ゲートウェイとデバイス側も
独立して検証します。RSA は 3072–8192 ビットです。対応状況が不明、
旧版、一部だけ更新された OS では SSH を選べません。診断の詳細は
利用できます。パスワードを 5 回連続で間違えると 15 分間ロックされます。
開始後は ssh duduclaw-maint@duduclaw.local、利用可能なプライベート
IPv4 アドレス、担当者の鍵とデバイスの指紋、終了日時、接続数、
ログイン失敗数を表示します。管理者への通知と両方の指紋を照合してください。
通知先がなければデバイス本体の画面で確認します。この画面だけでは
デバイスの身元を確認できません。通知先の設定は配信成功を意味しません。
ポート 22 はプライベート・リンクローカルと VPN CGNAT 100.64.0.0/10
のみ許可し、グローバル IPv6 は拒否します。範囲内でも信頼できる
接続元とは限りません。メニューは指定の診断とモデル・ゲートウェイの
再起動に限定され、ゲートウェイの再起動で終了・切断します。
終了を確認できない場合は警告を表示し続けます。履歴には最近の 鍵の指紋と接続イベントを表示します。状態を 30 秒ごとに取得するため、 期限切れやデバイス側の終了表示は次の取得まで遅れる場合があります。 完全な OS イメージ、実際の SSH、通知配信はまだ検証していません。 未リリースの画面であり、組み立てたデバイスの受け入れ完了を意味しません。