Claude Codeのproject-artifactプラグインで状況ページを自動更新する

project-artifactは、複数の作業が並行して進むプロジェクトの状況ページを作り、公開し、あとから更新し続けるためのプラグインです。移行、リリース準備、調査のように「1回の報告では収まらない」取り組みが対象で、更新のたびに前回からの変化だけを返します。

project-artifactは何を作り、何を自動にするのか

作られるのは、タブ付きの単一HTMLファイルです。概要と成功基準、作業の流れ(ワークストリームの順序)、常に見えている「次の一手」の帯が基本で、背景・計画・リスクなどのタブは中身があるときだけ加わります。Claude Codeに組み込みのArtifactツールで公開されるため、置き場所はclaude.ai/code/artifact/...の非公開ページです。

自動になるのは、状態の再収集と同じURLへの再公開、変更点の要約です。更新を始める合図までは自動になりません。次のセッションで「refresh the artifact」と頼むと、プラグインが記録済みの出典から最新の状態を集め直します。

「自動更新」と聞いて定期実行を想像すると、期待とずれます。更新の公開には対話セッションが必要で、claude -pのような非対話の実行にはArtifactツールがありません。スクリプトでページを組み立てたり更新したりはできても、公開の最後の一手は対話側に残ります。

導入する: 公式マーケットプレイスから入れる

プラグインはAnthropicの公式マーケットプレイスに載っています。Claude Codeは対話セッションを初めて開いたときにこのマーケットプレイスを追加するため、セッション内なら次の1行で足ります。

/plugin install project-artifact@claude-plugins-official

セッション内でこのコマンドを打つと、すぐには入らず、そのプラグインの詳細パネルが開きます。内容を確認してスコープを選ぶ流れです。シェルから入れる場合は次の形です。

claude plugin install project-artifact@claude-plugins-official

まだ対話セッションを一度も開いていないマシンでは、公式マーケットプレイスが登録されていません。その場合は先にclaude plugin marketplace add anthropics/claude-plugins-officialを実行します。入れたプラグインは次回起動時か、開いているセッションで/reload-pluginsを実行したときに読み込まれます。導入後に何が入ったかはclaude plugin list --jsonで棚卸しでき、コンテキストへの負荷はclaude plugin detailsで測れます。

使える条件を先に確かめる

このプラグインはArtifactツールの上で動くので、ツールが使えない環境ではプラグインを入れても公開できません。プラグインのREADMEが挙げる要件は、claude.aiへのログインを前提とするArtifactツールと、PR主体のプロジェクト向けの任意のgh CLIです。APIキー、Bedrock、Vertexで動かすセッションにはArtifactツールがありません。

READMEとArtifactsの公式ドキュメントで、対象プランの書き方が食い違っています。

• プラグインのREADME: Team・Enterpriseプランでベータ提供
• Artifactsのドキュメント: Pro・Max・Team・Enterpriseのいずれか(Pro・Maxでは共有するまで自分だけに見える)

READMEの記述は、artifactsがTeam・Enterprise向けのベータだった時期の書き方のまま残っているように見えます。プランで迷うときは、Artifactsのドキュメントの条件表を優先して確かめるのが手堅い方法です。組織のポリシーやモデル提供元、CMEK・HIPAA・Zero Data Retentionの扱いを含む全条件はClaude Code Artifactsの共有ページが同じURLで自動更新される仕組みの表にまとめてあります。

最初の状況ページを作る

作成は/project-artifactにプロジェクト名と出典を添えるだけです。出典には、リポジトリとそのPR、トラッカー、設計ドキュメントを指せます。次はプロンプトの一例です。

/project-artifact billing-migration
出典: このリポジトリのPRのうちラベル billing-migration が付いたもの、
docs/billing-migration.md、トラッカーのエピック BILL-120

実行すると、プラグインが出典を読んで内容を組み立て、ページを公開し、URLを知らせます。URLはサーバー側で発行されるため、事前に決めることはできません。プラグインは最初の公開のあとでそのURLを記録し、以降の更新が同じアドレスに着地するようにします。

プロジェクトごとの設定と最新の描画結果は、お使いのマシン上のプラグインのデータディレクトリに置かれます。共有用の正本は公開済みartifactのほうで、手元のデータは更新の足場です。別のマシンで同じプロジェクトを更新したいときは、手元のデータが無いことを前提に、artifactのURLを渡して始める流れになります。

PR主体のプロジェクトでは依存の順番とCIが載る

ワークストリームがプルリクエストのプロジェクトでは、ページがPRに順番を振って依存関係を見せ、gh CLI経由でPRの状態、CIチェックの結果、未解決のレビュースレッドを引きます。進捗はdone・now・next・warnの状態ピルで表されます。

ページに出る数字が正しいかを疑うときは、同種の状態を手元でも引けます。

gh pr list --state all --label billing-migration \
  --json number,title,state,isDraft,reviewDecision,statusCheckRollup

これはプラグインが内部で実行する命令そのものではなく、同じ種類の状態を確かめるための例です。ページとコマンドの出力が食い違うなら、更新が古いか、出典の範囲(ラベルやブランチ)が想定と違っています。後者はREADMEの言う「出典の指し方」の問題なので、次の更新で出典を言い直します。

gh CLIが無い環境でも、PR以外の出典(設計ドキュメントやトラッカー)でページは作れます。ただしCIと未解決レビューの欄は、gh CLIがあるPR主体のプロジェクトで効く機能です。

更新する: 「refresh the artifact」と差分の読み方

日々の運用はほぼこの一言です。

refresh the artifact

プラグインはプロジェクトの出典と公開済みURLを覚えているので、新しいセッションでも同じ一言で足ります。ライブの状態を集め直し、同じURLに再公開し、前回の描画から変わった点だけを短く返します。マーケットプレイスの説明は、この要約を状態の差分(delta)と呼んでいます。

差分を返す設計は、報告を読む側にとって効きます。ページ全体を読み直さなくても、「今回動いたのはここ」だけを拾えるためです。

ページを開いている人の画面は、公開のたびにその場で更新されます。公開のたびに版が記録され、閲覧者に見せる版はShareコントロールで選べます。Always share latest versionのトグルを使うか、特定の版に固定するかは、ページ上で決めます。

別のセッションや別の人が更新したいときは、artifactのURLをClaudeに渡すか、/artifactsの一覧からアタッチします。URLを渡さないと、新しいセッションは既存のページを更新せず、新しいartifactを作ります。同じページを育てたいのに別URLができてしまうのは、この見落としが原因のことが多いです。

出典の指し方をCLAUDE.mdに書いておく

プラグインは出典を記憶しますが、読み方の癖はプロジェクトで決めておくほうが更新のたびにぶれません。CLAUDE.mdに、状況ページの更新で守る規約を書いておく例です。

## 状況ページの更新ルール
- ページの出典は PR(ラベル billing-migration)、docs/billing-migration.md、BILL-120 の3つ
- ステータスは done / now / next / warn の4種類だけを使う
- 「次の一手」には担当者と期限が決まっている項目だけを載せる
- 更新後は、変わった点を3行以内で報告する

ここで効くのは、判断の基準が人の側に固定される点です。「次の一手」の条件や報告の長さを決めておけば、更新者が変わっても読み味が揃います。プラグインが生成するタブ構成そのものはプラグイン側の仕様なので、CLAUDE.mdで変えられるのは出典と運用の約束です。

共有の範囲と見せ方

作成直後のページは作成者だけが見られます。共有はclaude.aiのビューアのShareコントロールから行い、範囲はプランで変わります。Pro・Maxでは公開リンクが共有の手段です。Team・Enterpriseでは相手を指定して共有でき、公開リンクは管理者が有効にするまで使えません。

プラグインのREADMEは、URLをブックマークするか、チームのハブページに載せることを勧めています。ページ自体は「見つけてもらう場所」を持たないためで、状況ページが複数あるときほどハブが要ります。組織全体での有効化、保持期間、監査ログはClaude Code Artifactsの組織管理で扱っています。

ページは外部の依存を持たず、スタイルをすべてインラインで埋め込み、ライト・ダークの両モードとレスポンシブに対応します。スマートフォンから見る共有先にも崩れにくい作りです。

つまずきやすい点

• headlessで公開できない: claude -pにはArtifactツールがありません。夜間のスクリプトから公開まで通す構成は組めず、対話セッションで更新の合図を出す運用になります
• ログイン方式が違う: APIキー、Bedrock、Vertexのセッションでは、プラグインを入れても公開できません。/loginでclaude.aiアカウントにサインインしたセッションが必要です
• 別URLができる: 新しいセッションでURLを渡さずに頼むと、新しいartifactが作られます。更新したいページのURLを毎回添えるか、/artifactsで選びます
• 手元のデータが無い: プロジェクトの設定と最新の描画は、作った人のマシンにあります。引き継ぐときは、公開済みartifactのURLから始めます

タブの構成にも注意が要ります。マーケットプレイスの説明は、背景・計画・リスク・決定事項のタブを「中身があるときだけ」入れると書いています。READMEの例示はFAQを挙げており、記述が揺れています。どのタブが出るかはプロジェクトの内容次第なので、必要なタブがなければ作成時に明示的に頼むのが確実です。

PRと関係のないプロジェクトでも、ページを同じURLで育てる点は共通です。コネクタ経由で外部データを読み続けるダッシュボードに寄せたい場合は、Claude Code ArtifactsのMCP連携で公開後もライブデータを更新するが参考になります。

まとめ

状況ページの価値は、同じURLが最新で、前回からの変化がすぐ読めることにあります。project-artifactは、その2つを「refresh the artifact」の一言に畳んだプラグインです。定期実行ではない点だけは前提として押さえておくと、運用のイメージがずれません。

導入前の確認は、claude.aiログインのセッションであることと、組織のartifacts設定です。PR主体のプロジェクトなら、gh CLIの有無でページの情報量が変わります。