Claude CodeでClaude Designのcanvasが読めない件と回避策

Claude Designで作ったcanvas artifactを/artifactsでClaude Codeのセッションに付けても、アートボードの中身をコードに起こせない。この報告がGitHubのIssue #99534に上がっています。起票は2026年10月4日で、ラベルはenhancementとarea:toolsです。

先に切り分けの結論を書きます。読めないのは「ページの外側(実行用のシェル)だけが返る」読み方をしたときで、後続のコメントにはpath指定でproject/canvas.jsonが読めたという報告があります。書き込みは所有者なら通り、他組織から招待された編集者では拒否される、という報告も出ています。

何が起きるか — 3つの読み方が全部空振りした

起票者は、Claude Codeのセッションにcanvasを付けたうえで、次の3つを試しています。

シェルの中にあるREADMEには、canvasの実体がproject/canvas.jsonと、アートボードごとのproject/<path>.dc.htmlに入っていると書かれています。つまり中身の置き場所は分かるのに、そこへ辿る読み出し口が見つからない、というのが起票時の状況です。URLの末尾にパスを足すと「urlが成果物の内側のパスを指している。成果物自身のURLを渡すこと」という趣旨のエラーで弾かれます。

起票者の用途は、Claude Designでモバイル画面を設計し、そのアートボードからFlutterのウィジェットをClaude Codeに作らせることです。いまの回避策は、アートボードを手作業でリポジトリへ書き出すこと、と書かれています。

後続コメントで分かった読み書きの差

3件のコメントのうち2件は、起票内容の補足です。ここが切り分けの材料になります。

• 読み出しは通った報告がある: 10月11日のコメントは、Claude Code 2.1.295(デスクトップアプリのCodeタブ、Linux)で、Artifactツールのreadにpath: "project/canvas.json"を渡すとファイルがローカルに保存できたと書いています。.dc.htmlも同じです。起票時に「読み出し口が無い」とされた部分は、pathを付けた読み方で届く可能性があります
• 所有者の書き込みは通る: 10月16日のコメントでは、自分のアカウントが所有するcanvasなら、project/canvas.jsonをpublishすると新しいバージョンが作られました
• 招待された編集者の書き込みは拒否される: 他のアカウントが所有し、自分がEditorとして招待されたcanvasは、claude.aiでは編集できます。Claude Codeからのpublishは「その他のファイルはArtifact typeから作られた成果物にしか公開できない」という趣旨の理由で拒否されたとあります
• admin操作の失敗: 10月11日のコメントには、/design consentが403で失敗し、/design-loginが存在しないビルドだったという記述もあります

このうち編集者の拒否は、Claude Code側のArtifact機能が「typeから作られた成果物のうち、自分が所有するもの」しか書き換えられない形に見える、という状況報告です。原因がサーバー側の権限なのか、ツール側の判定なのかは、Issueには書かれていません。

どのバージョン・環境の話か

Issueに出てくる環境は、Claude Code 2.1.295(デスクトップアプリ、LinuxとmacOS)です。同じ機能の挙動は更新で変わりうるので、手元で試すときは、まず自分のバージョンと、canvasの所有者が自分か他人かを控えておきます。

Claude Codeのドキュメントでは、/artifactsが自分の成果物と共有された成果物を一覧し、Enterで現在のセッションに付けられると説明されています。編集者になれるのはTeamとEnterpriseのプランで、共有ダイアログで役割をviewerからeditorへ切り替える形です。canvasが他組織から共有されたものだと、この「編集者」の扱いがClaude Code側で通らない、というのが10月16日の報告です。

回避策 — 書き出してから読ませる

Issueの起票者が挙げている回避策は、アートボードを手作業でリポジトリへ書き出すことです。ドキュメントによると、canvasを開いてアートボードを選び、各アートボードをPNGまたはPDFとして書き出せます。

書き出した画像をリポジトリに置き、Claude Codeには画像として読ませる流れです。

mkdir -p design/artboards
# claude.aiでアートボードをPNGで書き出し、design/artboards/ に保存する
ls design/artboards

そのうえで、次のように頼みます。これは例示で、手元の構成に合わせて名前を替えてください。

design/artboards/home.png と settings.png を見て、
同じ構成のFlutterウィジェットを lib/screens/ に作って。
色と余白は design/tokens.md の値に合わせて。

色や余白の値は画像から読み取らせると揺れます。CLAUDE.mdかdesign/tokens.mdのようなファイルに、色コード・フォント・余白の段階を書いておくと、画像は構成の参考、数値は文字から、と役割を分けられます。このやり方はIssueの起票者が使っている「手動で書き出す」案を具体化したものです。

もう一つの回避策は、10月11日のコメントにあるzipの方法です。書き込みが拒否されるときにも、.dc.htmlとcanvas.jsonをzipにしてclaude.aiでcanvasに添付し、そちらのClaudeに追加を頼めた、と書かれています。向きは逆(Claude Codeで作ってDesignへ入れる)ですが、Code側から直接書けない場面の代替になります。

自分の環境で切り分ける順番

どこで止まっているかを見るには、次の順に確かめます。

DesignSyncで届かない理由と、既存のコマンドとの違い

/design-syncはReactのデザインシステムをClaude Designへ送る方向のコマンドで、canvasの中身を取り込む用途とは違います。Issueでlist_projectsがデザインシステム型のプロジェクトしか返さなかったことは、この役割分担と矛盾しません。詳しい使い方はClaude Code design-syncの使い方に、/designでcanvasを作る側はClaude Code /designの使い方にあります。

/designで作ったcanvasを、同じClaude Codeで読み返す場面にも注意が要ります。ドキュメントは、/designが複数のアートボードを持つキャンバスをClaude Design artifactとして公開すると説明しています。公開までは通るのに、読み返しでつまずく可能性があるのが、今回のIssueの核心です。

12月14日以降の話は別に確認が要る

スタンドアロンのClaude Design(claude.ai/design)は、2026年12月14日までに閉じます。Claude Codeの/design-syncと/design-loginには、この終了を知らせる通知が入りました。移行の手順はClaude Designの移行手順にまとめています。

終了後にcanvasの読み書きの経路がどう変わるかは、Issue #99534には書かれていません。canvasを起点にコードを作る運用を組むなら、手動の書き出しを前提にした手順に寄せておくと、経路が変わっても作り直しが少なく済みます。

まとめ

Issue #99534の症状は、URLだけでreadすると実行用シェルしか返らず、read_dbもDesignSyncも届かない、というものです。後続コメントではpath指定の読み出しが通った環境と、他組織から招待された編集者の書き込みが拒否される環境が報告されています。

実務では、まずpath付きで読めるかを1回試し、通らなければPNG・PDFの書き出しと、色や余白の文章化で運用します。Issueはopenで、修正の見通しは書かれていません。canvasを起点にした実装フローを組む前に、自分の所有か共有かと、使うバージョンで一度通しておくと、後で作り直さずに済みます。