DuDuClaw OSアプライアンス

電源とLANケーブルをつなぐだけで、小型PCがヘッドレスなAIスタッフに 変わります。2分もかからずダッシュボードがLAN上に立ち上がり、 モニターもキーボードも不要です。

これは何か

DuDuClawは通常、すでに管理しているマシンにインストールするバイナリと して動きます。アプライアンスはその対極にあるものです。既製の小型 ミニPCを、DuDuClaw専用機に変える起動可能なディスクimageです。設定す るOSも、インストールする依存関係も、開くターミナルもありません。電源 を入れれば箱はそのままDuDuClawに直行し、そこにとどまり続けます。電源 投入後のすべての作業は、自分のLAN上のブラウザで完結します。

対象ユーザーはDuDuClawの他の部分と同じです。Telegram/LINE/Discord/ Slackを24時間見張ってくれるAIスタッフが欲しいけれど、そのためだけに ノートPCを1台割り当てたくない、アカウントの認証情報を第三者に預けた くもない、という人向けに作られています。

電源投入から準備完了まで

1. インストール。 各リリースはマシンごとに2つの形式で提供されま す。liveインストーラーISOは、USBメモリに書き込む(またはディスク に焼く)、対象マシンをUEFIモードで起動しSecure Bootをオフにす る(公開されているimageはSecure Boot署名済みではないため、詳しく は下記の「エディションとデスクトップ」と信頼チェーンの説明を参照 )、グラフィカルなインストーラーで内蔵SSDを選ぶ、そしてインストー ル済みのシステムに再起動する、という流れです。ディスク全体の image(.wic.zst)はインストーラーを使わず、展開してそのまま対象 ディスクに書き込みます。チャネル経由で導入された機体で、出荷前に ドライブが書き込み済みの場合は、この手順自体を丸ごとスキップでき ます。
2. 初回起動。 箱はネットワークに触れる前にNTPで時刻を同期し、デ フォルトのタイムゾーンを設定します(時刻がずれているとOAuthやTLS が静かに壊れるため、これを最初に行います)。続いて有線DHCPでアドレ スを取得し、duduclaw.localとしてLAN上に自分の存在を通知します。 ダッシュボードは箱自身だけでなくローカルネットワークにバインドさ れて立ち上がりますが、ファイアウォールが通すのはダッシュボードの ポートと探索プロトコルだけです。箱の他の部分にはどこからも到達で きず、デフォルトでパブリックインターネットに公開されることも一切 ありません。
3. 接続。 同じネットワーク上のMac、iPhone、Windowsマシンから http://duduclaw.localを開きます。Androidは.localアドレスを解 決できないため、箱は自分のアドレスを直接表示する小さな付随の探索 ページも提供します。セットアップが終わる前に最初に接続した人が、 セットアップを行う人になります。これは他のセルフホスト型アプライ アンスと同じ、早い者勝ちの慣習です。
4. 管理者を設定し、言語を選んでタイムゾーンを確認します。
5. モデルアカウントとチャットチャネルを接続します。 セットアップ ウィザードが箱の上でclaude setup-tokenを実行し、リンク(とQRコー ド)を表示します。自分のブラウザでそれを承認し、短いコードを箱に貼 り戻すと、箱は何かを保存する前に実際にAPIを1回呼び出すので、無効 または期限切れのトークンが有効なものと誤認されることはありませ ん。APIキーを直接貼り付ける方法もあり、その場合はOAuthの手順は一 切不要です。チャットチャネルについては、Telegram、Discord、Slack、 Webチャットは直接アウトバウンドで接続できるので、トークンを貼るだ けです。LINEなどwebhook型のチャネルは、家庭用ルーターのNAT配下に ある箱では何も受信できないため、公式のリレーサービスを経由しま す。リレーは箱自身が開いた接続の上で不透明なバイト列を転送するだ けで、受信した各webhookの実際の署名検証は今もリレーではなく箱の側 で行われます(詳細は下記のセキュリティ設計を参照)。
6. 業種テンプレートを選びます。 これで最初のAIスタッフが作成され るので、いま接続したばかりのチャネルでテストメッセージを送ってみ てください。返信が来れば、ダッシュボードが単に読み込まれただけで はなく、箱がエンドツーエンドで実際に動いていることの確認になりま す。
7. スタンバイ。 ここから先、箱はただ動き続けます。systemdの watchdogがハングしたgatewayプロセスを再起動し、起動失敗が連続する と自動的に前のOSバージョンにフォールバックして、詰まったままには なりません。

デバイスページ

アプライアンスとしてインストールするとデバイスページが追加されま す。これはアプライアンスでのみ表示されるページで、通常のデスクトップ 版やサーバー版のインストールではナビゲーションにまったく現れず、ペー ジ自体もアプライアンス以外の環境では、誤解を招く表示をするくらいなら と、描画そのものを拒否します。

• ステータス——CPU/メモリ/ディスク/温度/ネットワークのライブス ナップショット。
• アップデートセンター——OS自体はDuDuClawアプリケーションとは独 立して、A/Bパーティション方式で更新されます。アップデートを適用 し、その後箱が起動に失敗した場合は、以前実行していたバージョンに 自動的にフォールバックします。オンデマンドのワンクリックロールバ ック(失敗時に自動で行われる種類とは別のもの)は、意図的に「まだ利 用不可」として報告されており、当て推量では済まされていません。基 盤となる更新ツールには組み込みの「undo」コマンドがなく、仕組みを 確信できないままブートスロットを選ぶと、デバッグ用の画面が何もつ ながっていない箱を文鎮化させるリスクがあるためです。
• ネットワーク——現時点では箱のネットワークインターフェースの読 み取り専用ビューです。ダッシュボードから静的IPを編集する機能はま だ配線されていません。
• バックアップ——箱が学習・保存してきたすべて(エージェントの記 憶、会話履歴、設定)をダウンロード可能な1つのファイルにアーカイブ します。
• 危険ゾーン——工場出荷時リセット(ボタンを押すだけでなく「RESET」 という単語を入力して確認する必要があります)、再起動、シャットダウ ンで、それぞれ個別の確認が必要です。

エディションとデスクトップ

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、アプリ互換レイヤー(Bottles、Windows VM、Waydroid)、読み取り専用ルート、ファイアウォール、初回起動時のプロビジョニング、ログイン強化。	ディスク全体の.wic.zstと、専用の live インストーラー ISO(installer-desktop、2026-09-04 に v0.1.0 へ追加)。
ベースイメージ(duduclaw-image-ab)	同じA/B構成、デスクトップシェル、gatewayを持ちながら、アプリ互換レイヤー・読み取り専用ルート・ファイアウォールは含みません。製品ではなくbring-up成果物という位置づけです。	v0.1.0のliveインストーラーISOに収められているペイロード。

モニターが接続されていないときにデスクトップがどう振る舞うか、つま りヘッドレスなダッシュボードのみの箱にフォールバックするのかどうか は、実機ではまだ定義されておらず、未解決のbring-up項目です。上で説 明したLAN上でダッシュボードが立ち上がる流れは、画面の有無にかかわら ず同じように動作します。それを提供しているのはデスクトップではなく gatewayだからです。

セキュリティ設計

• ダッシュボードの電源/アップデートボタンを動かすためだけに、 root権限で動く新しいプロセスは一切起動しません。 再起動、シャッ トダウン、OSアップデートの適用、初回セットアップの再有効化など、 本当にroot権限が必要な少数の操作だけを、独立した小さなヘルパープ ロセスが処理します。このプロセスはローカルのUnixソケット越しに正 確に6つの固定コマンドだけを話し、何かを実行する前に必ず要求元の身 元を確認します。この身元確認が設定されていない場合、信頼をデフォ ルトにするのではなく、すべてのリクエストを拒否します。
• すべてのポートがデフォルトで閉じています。 ファイアウォールは ダッシュボードのポートとローカルネットワーク探索を除くすべての着 信接続を拒否します。リモートSSHアクセスは工場出荷時オフになってお り、ダッシュボードから明示的に有効化した場合のみオンになります。
• webhookリレーはチャネルのシークレットを一切見ません。 それを 必要とするwebhook型チャネルについて、リレーの役割は、箱自身が最初 に開き自分の鍵で認証した接続の上で、着信リクエストの生バイト列を 転送することに限定されています。リレー自体は署名を検証すること も、チャネルのシークレットを保存することも、ペイロードを解析する こともありません。万が一リレーが侵害されても、そこには漏らして困 るようなものは何もありません。
• imageについて「私たちを信じてください」という部分は一切ありませ ん。 imageを生成するビルドレシピは公開されています(下記の「自分 でビルドする」を参照)。そのため、誰でも書き込む前にすべての行を読 んで、箱の中に何が入っているかをベンダーの言葉だけに頼らず確認で きます。

自分でビルドする

imageは正体不明のバイナリとして出荷されているわけではありません——公 開されているYocto layerからビルドされたもので、自分のマシンで監査・ 再現でき、リリースごとの成果物にはすべてSHA-256とminisign署名が付い ています。2026-09以降、このlayerとそのリリースパイプラインは、独立 したDuDuClaw-OSリポジト リに置かれています。署名済みリリースのダウンロード先やソースからの ビルド方法は ビルドガイドを参照してくだ さい。

現在の状況

これはプラットフォームの中でもまだ若い部分であり、話を盛らずに現状を 率直に伝えておく価値があります。DuDuClaw OS v0.1.0(2026-09-04、 DuDuClaw-OSリポジトリからの最初のタグ付きリリース)時点では、次のとお りです。

• x86-64のimageは両方のマシン向けに、両方の形式(ディスク全体image とliveインストーラーISO)で存在し、公開されており、すべて署名済み です。QEMUマシンは両方の形式で起動検証済みです。実機のマシン (duduclaw-genericx86-64)は設定の監査のみが完了しています。
• 実機での完全な検証、つまりメディアを書き込み、起動し、インストー ルし、セットアップを一通り実行し、チャットチャネルでメッセージを やり取りし、OSアップデートを適用し、強制的にロールバックさせ、工 場出荷時リセットを実行するところまで、実際に認証済みのハードウェ ア上ですべて行うことは、まだ行われていません。これが現時点で最も 重要な未解決項目です。
• 信頼チェーンはビルドレイヤーには配線済みですが、公開されている imageで有効化されているのはその一部だけです。v0.1.0で出荷済みなの は、ロールバック付きのA/Bアトミックアップデートと、デスクトップ版 における読み取り専用ルートです。v0.1.0の成果物で 有効化されていないビルド時オプションは、UKIのSecure Boot署名 とdm-verityによるルート検証(どちらもsb-signingビルドオーバーレ イに由来し、公開されているimageはSecure Bootをオフにした状態で起 動します)、およびTPM2 + LUKSの鍵封印(tpm-luksオーバーレイ。その 自動登録は今も未解決の欠陥であり、これを解消するには実機のTPMが必 要です)です。
• OSはプラットフォームとは独立してバージョニングされています (0.xは立ち上げ段階、1.0.0が最初のGAを示します)。リリースごと の状況はDuDuClaw-OSリポジトリのCHANGELOG.mdにあります。

これらのいずれも、今日リリースを書き込んで試すことの妨げにはなりませ ん。これらは、起動失敗を自力でデバッグすることに抵抗がない人以外にも 渡せるものにアプライアンスがなるまでに、残っている作業です。