Claude Designを触った日に、フィジカルAIのセキュリティを考えた

リリース直後のClaude Designを実際に触り、Pixels to Motorsのリデザインを試みた。「Claude臭が消えない」という限界が見えた。その流れで、ロボットアーム操作UIをR2R2Rの最終アウトプットとして位置づけるという発見があり、フィジカルAIとセキュリティという本質的な問いにたどり着いた。攻殻機動隊が描いた警告は、男鹿の書斎で設計課題になっている。

💡 Key Takeaway

フィジカルAIの普及は、セキュリティの失敗が「情報漏洩」ではなく「物理的破壊と怪我」を意味する次元への移行だ。操作UIのデザインとセキュリティは分離できない。その交差点を統合して扱える設計者が、まだほとんど存在しない。

Claude Designを触ってわかったこと

—— 2026年4月17日、AnthropicがClaude Designをリリースした。発表と同時にFigmaの株価が6.8%下落した。

実際に触ってみた。Pixels to Motorsのサイトを題材にして、TOPページのリデザインを試みた。

最初に出てきたのは黒背景＋ライムグリーン＋等幅フォント＋幾何学図形という組み合わせだった。今やどのAIツールを使っても似たようなものが出てくる「AI tech aesthetic」のパターンで、どこにでもあるロボティクス系スタートアップのサイトに見えた。

指示を変えた。「文芸誌風に」という方向性を与えると、「半島の書斎から」という副題のついた美しいが過剰に文学的なページが出てきた。

なんかClaudeっぽさが消えないね。

そこで気づいたことがある。「Claude臭が消えない」という問題の正体は、ツールの問題ではなくインプット側の問題だ。ブランドの核心を設計者が事前に言語化していないと、ツールはその空白を「それっぽい何か」で埋めようとする。

もうひとつわかったことがある。Claude Designの本来の使いどころはサイトのリデザインではなく、明確な要件が存在する専用UIの生成だ。ロボットアームの操作UI——機能から逆算できるので指示が具体的に書ける——はその典型だ。

STUDIOという制約から離れる決断

Claude Designを触りながら、別の問いが浮かんだ。

Studio依存は無くしたい方向なんだよね。生成AIが出てきたらStudioは制約が多くてやりたいことができないプラットフォームになってしまった。

STUDIOは「コードを書けない人でも綺麗なサイトが作れる」という価値を売りにしていた。生成AIが登場する前は、それで十分だった。

生成AIが出てきた瞬間に、状況が変わった。「コードが書けなかった人がコードを書けるようになった」ので、ノーコードの価値が相対的に下がった。しかも制約はそのまま残る。Claude Designで作ったビジュアルをそのまま実装できない、Claude Codeで書いたコードを自由にデプロイできない。

移行の方向性が見えた。Markdown管理＋Astro＋Vercelという構成に移す。DAYログはMarkdownファイルで保存してGitHubにpushするだけで完結する。Claude Codeとの相性も抜群で、「新しいDAYログを追加して、タグを整理して、関連記事リンクも更新して」が一発で動く。

現在のSTACKには「Plain HTML, no cms」と書いてある。それをいま、実際に実行する段階に来ている。

操作UIはR2R2Rの最終アウトプットである

Claude Designの使いどころの話をしていた流れで、思わぬ発見があった。

「iPhoneでmechArmを操作するUI」のプロトタイプをClaude Designで作れるのでは。

その発言から、構造が見えた。操作UIはR2R2Rのアウトプットのひとつとして位置づけられる。

R2R2Rのパイプラインを改めて書くとこうなる。

Real（iPhoneで3Dスキャン）
  → Render（Unityでシミュレーション・最適化）
    → Real（mechArmで実機実行）
      → UI（その実機をiPhoneで操作するインターフェース）

「iPhoneで始まってiPhoneで終わる」という循環が成立する。スキャンの入口もiPhone、操作の出口もiPhone。これはPixels to Motorsのコアメッセージと完全に一致する。

確かに！そこまで考えていなかったけど、伝わりやすくなっていいね！

海外のHCI研究者に説明するとき、この一文で全部伝わるようになった。

"I scan with iPhone. I simulate in Unity. I execute on the arm. I control it with iPhone."

UIというアウトプットが加わることで、R2R2Rの物語が視覚的に証明できるようになった。

フィジカルAIになった瞬間、セキュリティの次元が変わる

操作UIを外部公開する前提で設計するという話になったとき、セキュリティの問いが避けられなくなった。

Raspberry PiのWebSocketポートをインターネットに開けっぱなしにすれば、第三者がmechArmを遠隔操作できてしまう。Cloudflare Tunnel＋Cloudflare Accessという構成でロボット側のIPアドレスを一切公開せずに外部公開できることがわかった。コストはゼロだ。

ただその過程で、より根本的なことに気づいた。

今まで「UIのセキュリティ」が意味していたのは、個人情報の漏洩や不正ログインの防止だった。最悪の場合でも被害はデジタルの領域に留まる。

フィジカルAIになった瞬間、これが変わる。

セキュリティの失敗が、物理的な破壊や怪我につながる。mechArmが乗っ取られれば鉄の腕が暴走する。病院の薬剤搬送ロボットが乗っ取られれば薬を誤配送する。スケールが上がれば人が死ぬ。

しかも現実に起きるリスクはSFが描くような高度なシナリオではない。

単純な認証の穴を突かれて、普通のハッカーがロボットを乗っ取るっていう話だよね。

AIの反乱ではなく、ただのサイバー攻撃の延長線上にある話だ。フィジカルAIが研究室から一般家庭・病院・工場に出てくる移行期に、セキュリティの設計標準がまだ確立していない。

ここに、誰もまだ十分に答えていない設計の問いがある。「操作UIのデザインとセキュリティは分離できない」。 エンジニアはセキュリティを技術問題として扱う。デザイナーはUIの使いやすさを考える。でもその交差点——「どう設計すれば安全に使えるか」——を統合して扱える人間がほとんどいない。

攻殻機動隊が描いた警告が、設計課題になった

この問題を考えていたとき、攻殻機動隊の話になった。

攻殻機動隊の世界では「義体（人間の身体のサイバネティクス化）をハックされる」という設定が繰り返し登場する。身体とデジタルが融合した上でのセキュリティ問題として描かれていたから、公開当時はSFの遠い話として受け取られた。

でも構造を抽象化すると、起きていることは同じだ。「身体の延長としてのロボットをハックされる」という問題に、義体か外付けのロボットアームかという違いしかない。

攻殻機動隊はこの問題を30年前に描いていた。

Pixels to Motorsを読んでいる海外のHCI・ロボティクス研究者の多くは、攻殻機動隊を日本のサブカルチャーとしてではなく「先見的なSF」としてリスペクトしている。「男鹿半島の書斎で、攻殻機動隊が警告した問題を実際に設計している」という文脈は、技術的な記録でありながら読み物として強度を持つ。

Claude Designを触った日が、そこまで考える入口になった。

「操作UIとセキュリティの統合設計」は、フィジカルAIが普及するこれからの10年で避けられない問いになる。mechArmの操作UIを設計して、その判断を記録しておくことは、黎明期のドキュメントとして意味を持つ。

※ プロジェクト名「R2R2R」は、UC Berkeley・Toyota Research Instituteの研究「Real2Render2Real」（Yu, Fu et al., 2025）の概念に触発されています。現実空間をデジタルツイン化し、仮想空間での試行から得た知見を実世界のモーター駆動へ還元する——その設計と実装過程を毎日記録しています。技術アプローチおよび目的は独自のものです。