Claude Code全体の使い方は Claude Code完全ガイド2026：インストールから本番運用まで をご覧ください。
01 Anthropic公式プラグイン「playground」の何が新しいか
Anthropic所属のClaude Code開発者Thariq（@trq212）が2026年1月29日に公開したX投稿が、わずか数日で84万インプレッションを記録した。タイトルは「Making Playgrounds using Claude Code」。Anthropicが公式マーケットプレイスから配布する新プラグインplaygroundの使い方を、5つの具体例とともに紹介した内容だ。
このプラグインがやることは一見シンプルに見える。Claude Codeに対して「playgroundスキルを使って、〇〇のHTMLを作って」と頼むと、ClaudeがスタンドアロンHTMLファイルを1枚生成する。ブラウザで開くと、生成されたHTML上でClaudeとインタラクトできる仕組みだ。
しかしThariqが強調しているのは、その単純さの裏にある思想転換だ。これまでClaude Codeとの対話はターミナル上のテキスト往復が基本だった。コードベースの構造を聞けば文章で返ってくる。レイアウトを相談すれば文字でCSS案が並ぶ。ところが人間が判断する対象が「視覚的なもの」のとき、テキスト往復は本質的に不向きだ。
playgroundプラグインは、Claudeが生成する成果物に「ユーザーが触って判断できる対話UI」を含めることで、この摩擦を回避する。生成されたHTMLでクリック・スライダー・ドラッグなどを通じて意思を伝え、最終的にターミナルへ貼り戻すプロンプト文字列を出力する。Claude Code側はそのプロンプトを受けて実装に進む——という二段階のループを設計している。
# Thariqがツイートで公開した実際のインストールコマンド
/plugin marketplace update claude-plugins-official
/plugin install playground@claude-plugins-official
Claude Codeの/pluginコマンド経由で1分で導入でき、追加のサーバー構築やAPIキー発行は不要。Anthropic公式マーケットプレイスclaude-plugins-officialにホストされているため、信頼面でも安心して試せる。
- playgroundはClaudeにスタンドアロンHTMLを作らせるClaude Code公式プラグイン
- 視覚的判断が必要な作業でテキスト往復の摩擦を解消する設計思想
- ThariqのX投稿が84万impでバイラル化、Anthropic公式から1コマンドで導入可能
02 インストール手順——/plugin marketplaceから1分で
Claude Code 2.x系（プラグイン機構が安定版になったバージョン）が動いていれば、playgroundの導入は2行のスラッシュコマンドで完了する。順番にターミナルから入力するだけだ。
# 1. 公式マーケットプレイスのインデックスを更新
/plugin marketplace update claude-plugins-official
# 2. playgroundプラグインをインストール
/plugin install playground@claude-plugins-official
1行目は「Anthropic公式マーケットプレイスの最新カタログをローカルに同期する」コマンド。新しいプラグインが追加されたとき、または既存プラグインの更新があったときに必要になる。Claude Code初心者が見落としやすいが、updateを省略するとplaygroundが「見つからない」と表示されることがある。
2行目で実際のインストールが走る。@claude-plugins-officialという指定はソース指定で、サードパーティのマーケットプレイスを併用している場合に名前衝突を避ける役割がある。インストールが終わると、Claude Codeのスキル一覧にplaygroundが追加される。
導入後の使い方は徹底してシンプル。Claude CodeのチャットでUse the playground skill to ...と書き、その後ろに作りたい内容を自然言語で続けるだけ。Thariqが公開した実例はすべてこの形式に則っている。
# 基本フォーマット
Use the playground skill to <ユーザーがやりたいこと>
# Thariq実例(1)：レイアウト探索
Use the playground skill to create an playground that helps me explore
new layout changes to the AskUserQuestion Tool
# Thariq実例(2)：SKILL.md校閲
Use the playground skill to review my SKILL.MD and give me inline
suggestions I can approve, reject or comment
呼び出されたClaudeは、リクエストの種類に応じてHTMLファイル1枚（多くの場合playground.html相当の名前）を作業ディレクトリに生成する。HTMLはVanillaのHTML/CSS/JavaScriptで構成され、外部ライブラリも基本的にCDN経由で読み込む形が多い。プロジェクトの依存関係を汚さない設計だ。
インストール直後は
Use the playground skill to create a simple counter appのように軽量な依頼で動作テストすると、出力先のディレクトリ・ファイル名・ブラウザ起動の有無といった挙動を把握しやすい。最初から本番タスクで試すと、生成物の評価軸が複雑になりすぎる。
ここで気をつけたいのはブラウザ手動オープンが基本動作になっている点。Claude Codeは生成したHTMLのパスを表示するが、自動でブラウザは立ち上げない。open playground.html（macOS）やxdg-open playground.html（Linux）、エクスプローラーでダブルクリック（Windows）で開く必要がある。
- 導入は
/plugin marketplace updateと/plugin installの2行のみ - 使い方は
Use the playground skill to ...という固定の前置きで自然言語タスク指示 - 生成物はスタンドアロンHTML、依存ゼロでブラウザから手動で開く
03 実例1：AskUserQuestionのレイアウトを視覚的に試す
Thariqが最初に挙げた実例は、Claude CodeのAskUserQuestionツール（ユーザーに選択肢を提示してその回答を受け取る組み込みツール）の新しいレイアウト案を探索する作業だ。投稿されたプロンプトは次の通り。
Use the playground skill to create an playground that helps me explore
new layout changes to the AskUserQuestion Tool
このタスクは一見「CSS書けばいいじゃないか」と思える。しかし実装担当者の視点で見ると、レイアウト変更は並列に複数案を比較し、相対的に良いものを選ぶ作業だ。テキストでClaude Codeに「3案出して」と頼むとコードが3つ並ぶが、頭の中でレンダリング結果を想像しなければならない。
playgroundが生成するHTMLは、Thariqの説明によると複数のレイアウト候補を切り替えながら、リアルタイムでパラメーターを調整できる対話UIになる。たとえば「縦並び/横並び」「カード密度」「説明文の量」をスライダーやセグメントコントロールで切り替え、見た目の変化を即座に確認できるイメージだ。
骨格は次のようなHTMLになる（Thariq投稿そのものではなく、playgroundが典型的に生成する構造を再現した最小例）。
<!doctype html>
<html lang="ja">
<head>
<meta charset="utf-8" />
<title>AskUserQuestion Layout Playground</title>
<style>
body { font-family: system-ui; margin: 24px; }
.controls { display: flex; gap: 12px; margin-bottom: 24px; }
.layout-vertical { display: grid; gap: 8px; }
.layout-horizontal { display: flex; gap: 8px; flex-wrap: wrap; }
.option {
padding: 12px; border: 1px solid #ccc; border-radius: 8px;
cursor: pointer;
}
</style>
</head>
<body>
<div class="controls">
<select id="layout">
<option value="layout-vertical">Vertical</option>
<option value="layout-horizontal">Horizontal</option>
</select>
<input type="range" id="density" min="4" max="24" value="12" />
</div>
<div id="preview" class="layout-vertical">
<!-- 選択肢のプレビューがJSで動的に描画される -->
</div>
<button id="export">Copy prompt to Claude Code</button>
<script>
// ユーザーが選んだ最終構成を、Claude Code向けプロンプトとして
// クリップボードにコピーするロジック
</script>
</body>
</html>
ポイントは末尾のCopy prompt to Claude Codeボタンだ。playgroundの設計上、ユーザーがプレビューで気に入った設定に到達したら、その状態を自然言語のプロンプト文字列に変換してクリップボードに渡す。それをClaude Codeのチャットに貼り戻すと、実装フェーズへ進める。
つまりplaygroundは「最終仕様の決定者である人間」と「実装担当のClaude Code」の間に立つ仕様確定UIとして機能する。Claude Code本体に対して曖昧なテキストで「いい感じに」と頼むより、明示的なJSON相当のパラメーター列が渡るので、実装の精度が格段に上がる。
playgroundが生成するHTMLは作業ディレクトリ直下に置かれることが多い。プロジェクトの
.gitignoreにplayground*.htmlを追加しておかないと、レイアウト試作の中間成果物がコミット対象に紛れ込む。
- レイアウト案を「並列比較」できる対話UIを生成、テキスト想像力に頼らない
- 最終的にClaude Code向けプロンプトとして書き出すボタンが組み込まれる
- 仕様確定UIとして人間とClaude Codeの中間に立つ役割
04 実例2-3：SKILL.md校閲とRemotion動画調整
実例2はSKILL.mdファイルの校閲。SKILL.mdはAnthropic Claude Skillsの定義ファイルで、Claudeに「いつ、どう振る舞うか」を指示するMarkdown文書だ。Thariqのプロンプトはこうだ。
Use the playground skill to review my SKILL.MD and give me inline
suggestions I can approve, reject or comment
ここでplaygroundが生成するのはインラインコメント機能を持つMarkdownレビューUI。GitHubのプルリクエストレビュー画面に近い体験で、Claudeが各行に対して「この記述は曖昧」「ここはサンプル追加を推奨」といった指摘を貼り付け、ユーザーがApprove/Reject/Commentを選んでいく。
なぜこれをplaygroundでやる価値があるのか。理由は指摘のサイズと数にある。100行のSKILL.mdに対してClaudeが20件の指摘を出した場合、テキストチャットだと「指摘1：行5……指摘2：行12……」と長大なリストになり、ユーザーは1件ずつスクロールして判断するしかない。
playgroundは指摘を該当箇所の真横に吹き出しで表示できる。ユーザーは画面全体を一望しつつ、左クリックで承認、右クリックでコメント追加といった操作ができる。最終的に「承認した修正だけを反映したSKILL.mdの新バージョン」をClaude Codeに渡せる。
実例3はRemotion（React製のプログラマブル動画ライブラリ）で作ったイントロ画面のチューニングだ。
Use the playground skill to tweak my intro screen to be more interesting
and delightful
動画のチューニングは、まさにテキスト対話が無力になる典型例。「もっとインタラクティブで楽しい感じに」というフィードバックを文章で返してもClaudeは抽象化されたパラメーターしか触れない。playgroundはRemotionのインプロップス（入力プロパティ）をライブで操作するスライダーUIを生成する。
// Remotionコンポーネントの例（plagroundが触る対象）
import { useCurrentFrame, interpolate } from "remotion";
export const Intro = ({ titleScale, particleCount, hueShift }) => {
const frame = useCurrentFrame();
const opacity = interpolate(frame, [0, 30], [0, 1]);
return (
<div style={{ opacity, transform: `scale(${titleScale})` }}>
<h1>Welcome</h1>
{/* particleCount に応じてパーティクルを描画 */}
</div>
);
};
titleScale、particleCount、hueShiftといったプロップスをplayground HTML上のスライダーで動かすと、リアルタイムプレビューで動画の質感が変わる。気に入った値の組み合わせを「これで実装して」とClaude Codeに渡せば、Remotionプロジェクトのデフォルト値や演出ロジックを更新するコード変更が走る。
| 観点 | テキストチャット | playground HTML |
|---|---|---|
| 適した対象 | 仕様明確・コード中心 | 視覚・触感が判断軸 |
| フィードバック単位 | 1往復1案 | 1セッション内で複数案 |
| 並列比較 | 苦手（前後比較が必要） | 得意（同一画面内） |
| 最終出力 | コードまたは文章 | プロンプト文字列＋設定値 |
| 学習コスト | 低 | 中（HTMLが何を意味するか理解） |
| ファイル副産物 | 少ない | HTML 1枚（gitignore推奨） |
- SKILL.md校閲はGitHub PRレビュー風のインラインコメントUIを生成
- Remotionチューニングはプロップス操作スライダーでライブプレビュー
- テキスト対話は仕様明確タスク、playgroundは視覚・触感重視タスクで使い分け
05 実例4：アーキテクチャ図にコメントできる対話UI
4つ目の実例が、エンジニアにとって最も応用範囲が広いと言われるパターンだ。プロンプトは次の通り。
Use the playground skill to show how this email agent codebase works
and let me comment on particular nodes in the architecture to ask
questions, make edits, etc
これは「メールエージェントのコードベースのアーキテクチャ図を描き、各ノードに対してユーザーが質問・編集指示を貼り付けられるUI」を作らせている。Mermaid図やD3.jsベースのノードグラフが生成され、各ノードがクリッカブルになる構造だ。
なぜこれが画期的か。コードベース可視化は「全体像と詳細を行き来する作業」であり、テキストチャットでは絶望的に効率が悪い。「Aコンポーネントの責務を教えて」「Bとどう連携している?」「では仮にCを変えたい」と1問ずつ聞くと、毎回Claudeは全コンテキストを再構築しなければならない。
playgroundが生成するアーキテクチャUIでは、ユーザーは図全体を眺めながら個別ノードに「ここを別実装に置き換えるとどうなる?」と貼り付ける。最後にすべてのコメントをまとめてCopy promptすると、Claude Codeは位置情報付きのリファクタリング指示を受け取れる。
ここで生成されるHTMLの典型的な構造を最小例で示す。
<!doctype html>
<html>
<head>
<title>Email Agent Architecture Playground</title>
<script src="https://cdn.jsdelivr.net/npm/mermaid/dist/mermaid.min.js"></script>
</head>
<body>
<div class="mermaid" id="arch">
graph TD
A[Inbox Watcher] --> B[Classifier]
B --> C[Reply Drafter]
B --> D[Calendar Booker]
C --> E[Send via SMTP]
</div>
<div id="comments-panel">
<!-- ノードクリックで吹き出しが開く -->
</div>
<button id="export">Generate refactor prompt</button>
<script>
mermaid.initialize({ startOnLoad: true });
// ノードクリック → コメント入力フィールドを開く処理
// exportボタン → 全コメントをClaude Code向けプロンプトに整形
</script>
</body>
</html>
このパターンは個人プロジェクトだけでなくチームの設計レビュー会にも応用できる。エンジニアが集まって画面共有しながらノードにコメントを貼り、最後にClaude Codeへ渡す——という集団意思決定→Claude実行の橋渡しに使える。
コードベース全体のアーキテクチャ図をHTMLに埋め込むと、内部関数名・依存関係・データフローが1ファイルに集約される。社外秘プロジェクトの場合、このHTMLを安易に共有すると情報漏洩になる。生成HTMLの取り扱いは通常のソースコードと同等の注意で。
なお、上記Mermaidサンプルの構造は必ずしもThariqの実装そのものではない。Mermaid以外にもD3.js、ReactFlow、Cytoscape.jsなど、Claudeはタスクに応じて適切なライブラリをCDN経由で組み込む。生成HTMLを開いた瞬間にどのライブラリが使われているかが分かるので、好みに応じて「ReactFlowで作り直して」と指示し直すこともできる。
- コードベース可視化はテキストチャット最大の苦手領域、playgroundが解放する
- ノードクリック→コメント貼付→一括書き出しで位置情報付きリファクタ指示
- チーム設計レビューとの相性が良く、集団意思決定の出力をClaudeに繋げられる
06 実例5：ゲームバランス調整——テキストで無理な操作を可視化
5つ目の実例が、ThariqのX投稿で最もユニークな反応を集めた事例だ。プロンプトはこうだ。
Use the playground skill to help me balance the 'Inferno' hero's deck
文脈は、Thariq自身が個人開発しているスーパーヒーロー・ローグライクカードゲームの「Inferno」というヒーローのデッキバランス調整。デッキ構築型ゲームのバランス調整は、各カードのコスト・効果量・確率・組み合わせを多次元同時に動かして勝率を確かめる作業で、テキスト対話は完全に無力だ。
playgroundは典型的にこのようなUIを生成する。
- カード一覧の左ペイン（コスト・ダメージ・特殊効果がスライダー）
- 中央に「シミュレーション結果」（n回戦闘して何回勝ったかのヒストグラム）
- 右ペインに「変更案のサマリー」
ユーザーがスライダーをドラッグすると、内部のJavaScriptが100戦のモンテカルロ・シミュレーションを瞬時に走らせ、勝率がリアルタイムで更新される。気に入った数値セットに到達したら、Apply this balance to the codebaseボタンでClaude Codeに渡し、実際のゲームコードのカード定義ファイルを書き換える。
// playgroundが生成するシミュレーションロジックの最小例
function simulateBattle(deckConfig, opponentDeck, trials = 100) {
let wins = 0;
for (let i = 0; i < trials; i++) {
if (runSingleBattle(deckConfig, opponentDeck)) wins++;
}
return { winRate: wins / trials, sampleSize: trials };
}
// スライダー変更時のハンドラ
document.getElementById("inferno-damage").addEventListener("input", (e) => {
const newConfig = { ...currentDeck, infernoDamage: +e.target.value };
const result = simulateBattle(newConfig, balancedOpponent);
updateChart(result);
pendingChanges.push(newConfig);
});
ゲームバランスは「正解がない、感覚で決める」領域。デザイナーやプロデューサーが手で動かして納得した値が正解だ。playgroundはこの「感覚で決める作業」を、Claudeとの対話の中に自然に組み込む。
このパターンはゲーム開発以外にも応用できる。たとえば次のような領域はすべて同じ構造だ。
- 機械学習モデルのハイパーパラメーター・チューニング（モンテカルロ評価）
- A/Bテストの効果サイズ事前見積もり
- 価格戦略のシミュレーション（割引率と需要弾力性の関係）
- レコメンドシステムの重みづけ調整
いずれも「数字を動かして結果を確かめ、感覚で良し悪しを決める」作業だ。Claude Codeに対して「いい感じの値にして」と頼んでも自動最適化はできないが、playgroundが対話UIを用意すれば、人間の判断をClaudeが理解できる数値仕様に変換できる。
- ゲームバランス調整は多次元数値の感覚的決定でテキスト対話が無力
- モンテカルロ・シミュレーションを内蔵したスライダーUIをplaygroundが生成
- 同じ構造はML・A/Bテスト・価格戦略・レコメンドにも応用可能
07 自分でplaygroundを作るときの設計指針
5実例を踏まえると、playgroundが活きる領域には共通のパターンがある。Thariqが投稿末尾で添えた助言は「モデルとのユニークな対話方法を考えて、それを表現させる」。これを具体的な設計指針に分解すると、4つのチェックポイントが浮かび上がる。
第一に「判断軸が視覚・触感・並列比較に依存するか」。コード生成や仕様明確なリファクタリングは通常のClaude Codeチャットで十分だ。playgroundは、人間が「見て・触って・並べて」初めて判断できるタスクに使う。レイアウト探索、デザインのブレスト、アーキテクチャ可視化、ゲームバランス、データ可視化、機械学習可視化——いずれも該当する。
第二に「最終出力がプロンプト文字列に変換可能か」。playgroundが価値を生むのは、人間がUIで決めた結果がClaude Codeに渡せて、そこから実装が進む構造だ。渡す内容が複雑すぎてプロンプトに収まらないなら、playgroundではなく通常のWebアプリを別プロジェクトで作るほうがいい。
第三に「セッションの寿命が短いか」。playgroundが生成するHTMLは、その瞬間のタスクのために使い捨てる前提のもの。同じUIを何度も再利用したいなら、.gitignoreから外して正式なツールに昇格させる、もしくは別の専用Webアプリにリファクタリングする判断が必要だ。
第四に「プライバシーと共有範囲」。生成HTMLにコードベースの構造や社内データが含まれる場合、ファイル共有時の取り扱いはソースコードと同等の注意が要る。チーム外への送信は禁止、Slackで共有するときは内容を確認、というルールを最初に決めておくと安全だ。
# playground運用時に推奨するgitignore追加
echo "playground*.html" >> .gitignore
echo ".playground-cache/" >> .gitignore
git add .gitignore
git commit -m "chore: ignore playground artifacts"
playground HTMLの典型的なワークフローは次の図に集約される。
HTML生成"] C --> D["ブラウザで
対話UI操作"] D --> E{"気に入った?"} E -- "No" --> D E -- "Yes" --> F["Copy promptで
仕様文字列を出力"] F --> G["Claude Codeに貼り戻し"] G --> H["コードベースに
実装反映"]
ループの本質は「曖昧な要望→対話UI→明確な仕様→実装」という4段階の翻訳機構だ。人間の感覚的判断をClaude Codeが扱える形式仕様に変換するのが、playgroundの実体的な価値だと言える。
最後にThariq自身が投稿末尾で書いた一文をそのまま受け取るなら——「やってみると驚きがあるはず」だ。これまでテキスト対話で諦めていたタスク、または「ClaudeにやらせるのではなくWebアプリを自分で書く」と判断していたタスクを、もう一度playgroundで試してみる価値はある。インストールが2分、実例の再現が10分。失敗してもHTMLが1枚生成されて終わるだけだ。
- 視覚・触感・並列比較が判断軸のタスクが第一の適用条件
- 最終出力がプロンプト文字列に変換可能なときに価値が最大化する
- 使い捨て前提・gitignore推奨・社内データ取り扱いはコード同等の注意
- 「曖昧な要望→対話UI→明確な仕様→実装」の4段階翻訳機構と捉えると設計しやすい
