はじめに
筆者は最近、あるAI駆動開発チーム（社内でAIエージェントを開発フローに組み込んでいるチーム）向けに、調査資料を1本のナレッジベースにまとめる作業をしました。このとき成果物の器として選んだのが Claude の Artifact です。
最初は「HTMLを1枚吐き出して終わり」くらいのつもりだったのですが、実際に使ってみると Artifact は 作って配って終わりの静的資料ではなく、対話で継続的に育てられる生きた資料 として機能しました。本記事では、その一連のワークフローを実体験ベースで共有します。
この記事でわかること
- 調査資料を Artifact 製の HTML ナレッジベースにまとめる流れ
- publish してチームに配布するときの手順と注意点
- 元資料が更新されたときに「対話で」反映して版を上げていく運用
- 閲覧者が書き込めるメモ機能を後付けするときのハマりどころ
対象読者
- Claude（Pro 以上）を触っていて、Artifact を「使い捨てのプレビュー」以上に活用したい人
- チーム内に散らばった調査・設計資料を1枚に集約して配りたい人
前提
Artifact の基本操作（コード生成、プレビュー、ダウンロード）は把握している前提で進めます。プランは Pro 以上を想定しています（永続ストレージや publish の一部挙動がプランに依存するため）。
背景：4本の調査を「配れる1枚」にしたい
チームでは、AIエージェント開発に関する調査を複数の Markdown に分けて蓄積していました。マルチエージェント設計、Skills の運用、MCP、モデル・プランの使い分け…といった具合に4本ほどに分かれており、それぞれは充実しているものの、「メンバーに配って参照してもらう」という観点だと分断されていて使いづらい 状態でした。
やりたかったのは次の3点です。
- 4本の調査を横断できる 1枚のナレッジベース にまとめる
- メンバーが アカウントの有無を気にせず開ける 形で配布する
- 元資料が更新されたら、作り直しではなく差分で追従 できるようにする
なぜ Artifact だったのか
候補は他にもありました（Markdown をそのまま共有、静的サイトを立てる、ドキュメントツールに転記、など）。それでも Artifact を選んだ理由は、「章立てのHTMLを対話で組み上げて、そのまま公開リンクにできる」 という一気通貫さでした。
特に効いたのが次の2点です。
- 生成と修正が同じ会話の中で完結する — 「KB-02にこの節を足して」「この表にリンクを付けて」といった指示をそのまま反映でき、資料の履歴が会話として残ります。
- publish で誰でも開けるリンクになる — 標準的なHTML Artifactなら、リンクを知っている人はClaudeアカウントなしで閲覧できます（公式ヘルプ）。
ワークフロー全体像
実際の流れを図にすると、こうなります。
ポイントは、C の配布と E の更新がループになっているところです。一度配って終わりではなく、元資料の更新のたびに同じ会話で追従して版を上げる という運用に落ち着きました。
1. HTMLナレッジベースを章立てで組む
最初にやったのは、4本の調査＋既存の計画書をアップロードし、章立ての設計から合意することでした。いきなり全文を書かせるのではなく、「ホーム＋各調査を1章ずつ＋横断早見表＋出典」という骨格を先に決めた のが後々効きました。章の粒度が決まっていると、あとから「この章に節を足す」という差分指示が通しやすくなります。
生成は一気にではなく、章ごとに段階的に組み立てていきました。全体を一度に吐かせると、修正のたびに巨大なHTMLを丸ごと書き直すことになり、時間もかかれば事故も増えます。章単位で構築・置換する ほうが安定します。
※画像は記事向けにマスキングしています
2. Artifact として publish して配布する
ここで一つ、地味だけれど重要な点があります。Claude 自身は公開リンクを発行できません。 publish はユーザーがプレビューパネルの共有／Publish メニューから行う操作です。
publish すると「リンクを知っている人は誰でも閲覧できる」状態になります。裏を返すと、社外秘の情報を含むなら公開範囲に注意が必要 ということです。筆者のケースはチーム内配布だったので、リンクの共有先を絞る運用にしました。
3. 元資料が更新されたら「対話で」反映する
このワークフローでいちばん恩恵を感じたのがここです。調査Markdownは一度書いて終わりではなく、その後も加筆されていきました。そのたびに、更新版を再アップロードして「この資料を更新したのでナレッジベースに反映して」と伝えるだけ で、該当章に新しい節が足され、出典一覧と版数（v1.1 → v1.2 …）が更新されていきます。
作り直しではなく差分で追従できるので、資料が「育って」いく感覚がありました。実際、筆者のケースでは最終的に v1.6 まで版が上がり、途中で個別の依頼（リポジトリ名にGitHubリンクを付ける、特定キーワードの言及有無を grep で確認する、といった細かい作業）も同じ会話の中でこなせました。
4. 閲覧者が書き込めるメモ機能を後付けする
配布したあと、「閲覧者が章ごとにメモやToDoを残せると便利では」と思い、開閉式の右サイドバー を後付けしました。ここは実装的にハマりどころが2つあったので、そのまま共有します。
localStorage は使えない → window.storage
Artifact はサンドボックス化された iframe 内で動くため、localStorage / sessionStorage は使えません（エラーになるか、書き込みが黙って失われます。公式の説明）。
publish 済み Artifact でメモを永続化したい場合は、専用の永続ストレージAPI（window.storage）を使い、それが使えない環境ではセッション内メモリに退避する、というフォールバックを噛ませるのが安全です。
// ※ API名・形はプレビューで要確認。永続ストレージがあればそちらへ、ダメならメモリへ退避する
async function saveNote(key, value) {
try {
if (window.storage && typeof window.storage.setItem === "function") {
await window.storage.setItem(key, value);
return;
}
} catch (e) {
// 権限・環境の都合で失敗したらフォールバックに回す
}
memoryStore[key] = value; // セッション内メモリ
}
なお永続化は「publish 済み・対象プラン・テキスト・容量20MB以内」といった条件が揃って初めて効きます。条件を外すとエラーも出ずに翌セッションで空 になるので、過信は禁物です。
エクスポートも用意しておく
永続化が保証しきれない以上、書いたメモをテキストで書き出せる導線 を併せて用意しておくと安心です。筆者は「章ごとのメモをまとめてコピー／.txt でダウンロード」する機能を足し、ToDoは Markdown のチェックボックス形式（- [x] / - [ ]）で出力するようにしました。ダウンロードがブロックされる環境ではコピーに自動フォールバックさせています。
publish 時に出た CSS エラーと対処
最後に、publish 時にだけ出たエラーを1つ。次のようなメッセージが出ました。
Error: Error inlining remote css file SecurityError...
Error: Error loading remote stylesheet Error: Failed to fetch
Error: Error while reading CSS rules from https://fonts.googleapis.com/...
原因は <head> に入れていた Google Fonts の外部リンク でした。publish 時に全CSSをインライン化しようとした際、クロスオリジンのスタイルシートは cssRules を読み取れず（ブラウザのセキュリティ制限）、エラーになっていたのです。
対処はシンプルで、外部フォントのリンク（preconnect + stylesheet）を削除し、システムフォントのフォールバックだけで組む ことにしました。
/* 外部フォントに依存せず、OS 標準フォントで組む */
body {
font-family: "Noto Sans JP", "Hiragino Sans", "Yu Gothic UI",
"Meiryo", sans-serif;
}
日本語のナレッジベース用途なら、これで見た目の劣化はほぼ気になりませんでした。Artifact を publish する前提なら、最初から外部CSS/フォントに依存しない構成にしておく のが無難、というのが学びです。
まとめ
Artifact を「使い捨てのプレビュー」ではなく チームで育てるナレッジベースの器 として使うと、次のような運用が回せます。
- 章立てのHTMLを 対話で段階的に 組み上げる
- publish して アカウント不要のリンク で配布する（公開範囲には注意）
- 元資料の更新を 再アップロード＋差分指示 で追従し、版を上げていく
- メモなどの機能は後付けできるが、永続化は
window.storage＋フォールバック＋エクスポート で守る - publish 前提なら 外部CSS/フォントに依存しない 構成にしておく
「調査資料が複数に分かれていて配りづらい」という課題を持っているチームには、選択肢として試す価値があると感じました。