Claude Artifactsで公開できない「can't be shared publicly」の原因と対処
ArtifactのShareで「This version can't be shared publicly」と出て公開リンクを作れないときの切り分けです。再公開で直らない理由と、SVG・AVIF・Mermaidなど報告された原因を示します。
Artifactの共有メニューで「Anyone with the link」に切り替えた直後、次のエラーが出て「Only you」に戻される現象があります。
This version can't be shared publicly. Publish a new version or change the shared version, then try again.
メッセージは「新しいバージョンを公開するか、共有するバージョンを変えてください」と促します。ところが従った人の多くが、同じエラーに戻されています。Claude Codeの課題管理ページ(anthropics/claude-codeのissue 79824)には、再公開しても新しいArtifactを作っても直らない報告が集まっています。報告者の環境はClaude Code CLIのPro・Maxの個人アカウントが中心です。
先に結論を書きます。原因は1つではありません。ページの中身が引っかかっている報告が最も多く、特にSVGのdata: URIが目立ちます。中身を直すと共有できた例が複数ある一方、アカウント側の問題を疑う報告も残っています。
このエラーは何を示しているのか
エラーは、共有メニューで公開を許可しようとした時点で出ます。同じ画面の「Shared version」の選択肢が「Latest」のままグレーアウトしていて、メッセージが勧める操作ができないという報告もあります。
報告者のひとりが通信を調べたところ、公開を切り替えるリクエスト(PATCH /api/frame/perm/<id>)が409を返していました。
つまり、Artifactの公開自体は成功していて、閲覧者を「リンクを知る全員」に広げる操作だけが拒否されています。オーナー本人には普通に表示されるのも、この見え方と合っています。
この拒否の理由は、画面にも応答にも書かれません。ここが調べにくい最大の理由です。Claude Codeのドキュメントにも、このエラーや拒否される条件の記載はありません。以下は、issueに集まった利用者の報告をもとにした整理です。Anthropicが条件を確定させたものではない点に注意してください。
再公開しても新規Artifactでも直らない理由
issueの最初の報告者は、同じファイルの再公開と、別パスのコピーから作った新しいArtifactの両方を試し、どちらも同じエラーになりました。ここから「アカウントかセッションの問題」と推測しています。
その後の報告は、別の読み方を示しています。
- 新しいArtifactを作っても、ファイルの中身は同じなので、同じ理由で拒否される
- 4回再公開しても、2つのArtifactを作っても変わらなかった例では、能力宣言(capabilities)を空にしても、ランタイムの契約バージョンを最新にしても直らなかった
- 同じアカウントの別のArtifactは共有できた、と気づいたことで、アカウント起因ではなく内容起因だと絞れた報告がある
別のページが共有できるなら、アカウント側の閉塞ではなく、そのページの中身が原因という可能性が高くなります。
報告されている原因の候補
issueに載った切り分けの結果を、原因の候補としてまとめます。いずれも利用者による検証です。
| 引っかかった中身 | 報告された結果 | 共有できた直し方 |
|---|---|---|
生のdata:image/svg+xml,<svg …> | 報告された結果144バイトのページ(faviconの1行だけ)でも拒否 | 共有できた直し方base64にする、またはその行を消す |
base64化したSVGのdata: URI | 報告された結果SVG3枚+PNG3枚の構成で拒否 | 共有できた直し方6枚すべてPNGに変換 |
パーセントエンコードしたSVGのdata: URI | 報告された結果スクリプト内の1行だけで拒否 | 共有できた直し方実行時にencodeURIComponentで組み立てる |
Mermaid図(<pre class="mermaid">) | 報告された結果図を含むページで拒否された例が2件 | 共有できた直し方図をHTMLとCSSで書き直す |
| 埋め込みのAVIF画像 | 報告された結果2KBのAVIF1枚でも拒否 | 共有できた直し方PNGまたはJPEGに変換 |
SVGのdata: URIは形式を問わず疑う
最初に特定された例は、絵文字のfaviconを書いた1行でした。<link rel="icon">に生のSVGをdata:で置いただけで、ページ全体が公開できなくなりました。別の報告では、base64にしたSVGでも拒否され、PNGに置き換えると通っています。パーセントエンコードした形でも、同じ結果が出ています。
一方で、基本のPNGとJPEGは通ったという点は共通しています。
ここは公式の推奨と食い違います。ドキュメントは図にSVGかHTMLとCSSを勧め、画像はdata: URIでの埋め込みを前提にしています。それでもdata: URIで埋め込んだSVGが拒否された報告が続いているので、公式どおりに作った人がここで引っかかります。図はインラインの<svg>要素かHTMLとCSSで書き、data: URIには入れない形で試せます。この回避は報告ベースで、Anthropicが確認したものではありません。
報告者は、公開時のスキャナーがSVGのマークアップを実行可能な内容として扱っているのではないかと推測していますが、仕組みはわかっていません。
自分で書いていないSVGにも注意
書いた覚えのないSVGが原因になる例もあります。ある報告では、組み込んだUIライブラリ(Shopify Polaris)の中に、同種のdata: URIが4つ入っていました。そこだけを無効化すると、公開できるようになっています。
Mermaidも同じ構造に見えます。Mermaid図を含むページは、公開時にランタイムが埋め込まれて3.2MBほどに膨らみます。図をHTMLの表に置き換えたら38KB程度まで減って、公開できました。ランタイムの中身にはSVGを文字列で組み立てるコードがあり、これが引っかかっている可能性が報告されています。ただし、Mermaid自体が原因だと証明した検証ではありません。
画像形式はAVIFでも起きる
SVGともMermaidとも関係なく、AVIFだけで拒否された報告もあります。同じページに画像を1枚だけ差し替えて試したところ、結果は次のとおりでした。
インライン画像1枚だけを差し替えた結果
AVIF(約2KB)
拒否
ページ全体で3.7KB
PNG(約26KB)
公開できた
ページ全体で35.8KB
JPEG(約2KB)
公開できた
ページ全体で4.0KB
3.7KBのAVIF入りが拒否され、その10倍近いPNG入りが通っているので、サイズは関係ないと読めます。実際、6.9MB・1.4MB・144バイトのページがどれも拒否された例があり、0.39MBまで削っても直らなかったという報告もあります。能力宣言やwindow.claude.*への参照、本文の文章も原因ではありませんでした。
自分のページがどれに当たるか調べる
まず、公開できないファイルの中身を調べます。Claudeが書いたファイルは一時ディレクトリに置かれるので、パスはClaudeに聞いてください。
f=report.html
# 画像の埋め込み形式を数える
grep -o 'data:image/[a-z0-9+.-]*' "$f" | sort | uniq -c
# SVGの文字列とMermaid図の有無
grep -c '<svg' "$f"
grep -c 'class="mermaid"' "$f"image/svg+xmlかimage/avifが出たら、ここが怪しい箇所です。<svgが数えられても、ページ本来のインラインSVGなのか、ライブラリ内の文字列なのかは、この出力だけではわかりません。
公開できないときの切り分けの順序
- 1
中身に当たりをつける
上のコマンドで、SVGやAVIFの
data:URI、Mermaid図、同梱ライブラリを探します。 - 2
疑わしい箇所を置き換える
PNGかJPEGに変換するか、HTMLとCSSで描き直します。タブのアイコンは公開時にClaudeが選ぶので、
<link rel="icon">は不要です。 - 3
再公開して共有を入れ直す
同じURLに再公開してから、共有を一度「Only you」に戻し、「Anyone with the link」を選び直します。
- 4
だめなら二分する
ページを半分に割って別々に公開し、どちらが拒否されるかを見ます。最小の見本ページ(本文だけの数行)も公開し、それも拒否されるかを確かめます。
4番目の最小ページが共有できれば、原因は中身にあります。最小ページすら拒否されるなら、次に書くアカウント側の可能性が高まります。
二分の手順をClaudeに任せる
自力で二分するのは手間なので、Claudeに反復させる手もあります。次のような指示を、公開前の定型にしておく例です。
このHTMLを公開する前に、SVGの data: URI、AVIF、Mermaid図が入っていないか
grep で確かめて。入っていたらPNGかHTML/CSSに置き換えてから公開して。issueには、同じ考え方の応用もありました。Claude Designで作ったファイルが公開できず、ダウンロードしたものをClaude Codeに渡して、ブロック要因を1つずつ見つけて規則集にまとめさせた例です。ブラウザ上の拒否は画面でしか判別できないので、実ブラウザで検証できるツールを併用しています。
公開リンクが古い版のまま残るとき
公開できた後にもう1つ落とし穴があります。issueには、再公開してもリンクを開いた人に古い内容が表示され続けた報告があります。
ドキュメントによると、公開のたびに版(バージョン)が記録され、共有メニュー(Share)で閲覧者に見せる版を選べます。メニューには「Always share latest version」の切り替えと、共有する版を選ぶ欄があります。最新版を共有する設定なら再公開に追従し、特定の版を選ぶとその版のまま変わりません。報告された例がどちらの設定だったかは、issueからは読み取れません。
公開リンクを配ったあとで中身を更新したときは、共有メニューの設定を確かめ、公開済みのURLを開いて新しい内容が出るかを見てください。再公開に追従させる設定は、Claude Code Artifactsの共有ページが同じURLで自動更新される仕組みで扱っています。
なお、再公開で通ったという報告が1件あります。報告者は一時的なエラーだったと見ています。中身を直す前に、1回だけ再試行する価値はあります。
原因が内容ではなくアカウントにある場合
内容を直しても、最小ページを作っても共有できない報告もあります。
- Proのアカウントで、開く前に共有を設定した新規のClaude Docsもロックされた
- チャットで作ったDocsも、同じアカウントで公開できなかった
- MaxのアカウントでCLIを使い、4回の再公開と2つのArtifactで再現した例では、個人アカウントにはExternal sharingのスイッチがなく、自動で作られる個人の組織で外部共有の既定がオフとして評価されているのではと推測された
最後の推測は、報告者の仮説です。Claude Codeのドキュメントでは、Pro・Maxには組織による管理が入らないと説明されています。そのため、個人アカウントには切り替えるべき管理者設定が見当たりません。一方で、同じ個人アカウントで別のArtifactは公開できたという報告もあり、仮説で全件を説明できるわけではありません。
最小ページでも拒否される場合、利用者側でできることは限られます。issueのコメントで状況を共有するか、別の公開手段で回避します。回避策として、静的なHTMLをそのまま配信できるホスティングや、PDFに書き出す方法が挙げられていました。ただしPDFはレイアウトやスクリプトが崩れることがあります。
Team・Enterpriseで同じ画面が出たとき
TeamとEnterpriseでは、組織のOwnerが外部共有を有効にするまで、公開リンクは使えません。この設定がオフの場合に、同じエラー文が出るのかどうかは、issueには書かれていません。ですから、組織のアカウントで公開できないときは、中身を疑う前に管理設定を確かめるのが先です。手順はClaude Artifactsの管理者が組織外共有を制御する設定手順にまとめています。組織全体の管理項目はClaude Code Artifactsの組織管理が扱います。
まとめ
エラー文の指示に従って再公開しても直らないのは、原因がバージョンではなく中身にあるからです。報告では、SVGのdata: URI(生・base64・パーセントエンコードのどれでも)、Mermaid図、AVIFのいずれかを外したら共有できた例が目立ちます。まずファイルをgrepして、PNGかHTML/CSSに置き換えてください。
中身を直しても、最小の見本ページまで拒否される場合は、アカウント側の問題です。その場合は、自分のページだけを疑い続けず、issueへの報告や別の公開手段を検討する段階です。状況はissue 79824で追えます。