Claude Codeのhtml-planとは？導入方法と実装前の計画レビュー

html-planは、今どこまで公開されているのか

html-planは、AnthropicのGitHub組織にあるコミュニティ向けプラグインのリポジトリで公開されています。確認時点の定義ファイルには、名前、作者Thariq Shihipar、バージョン1.0.0が記載されています。プラグイン定義

ここは少し区別して読みたいところです。Anthropicの組織内に公開されていることと、Claude Codeの標準機能として全員に組み込まれたことは同じではありません。公開先のREADMEは、コミュニティが提供したプラグインの配布場所だと説明しています。配布リポジトリの説明

Thariqも紹介時点では、より広く届ける前に意見がほしいと書いています。したがって、「計画モードが全員HTMLに切り替わった」「従来の計画は廃止された」と受け取るのは早いです。

新しい道具を見たときは、発表の勢いと利用できる範囲を分けておくと、試す目的がはっきりします。今回は「標準機能の変更に対応する」より、「自分の計画レビューに役立つか確かめる」と考えるのがよさそうです。

導入コマンドは2行。使える状態も別に確認する

導入前に、Claude Codeを利用できることに加え、Node.jsが使えるかを確認してください。html-planのREADMEでは、関連ファイルを単体HTMLにまとめる処理にNode.jsが必要とされています。ターミナルでnode --versionが実行できることを確認したうえで、作者が案内する次の2行で配布元の追加とインストールを行います。

claude plugin marketplace add anthropics/claude-plugins-community
claude plugin install html-plan@claude-community

この配布元とプラグイン名は、公開されている一覧でも確認できます。マーケットプレイスの定義

ただ、コマンドを実行したことと、今開いているClaude Codeで使えることは分けて確認しましょう。公式ドキュメントでは、シェルから入れたプラグインは次のセッション開始時、または開いているセッションでの再読み込み後に反映されると説明しています。/pluginでインストール済み一覧を見て、/を入力した候補にスキルが現れるか確認できます。公式のプラグイン導入手順

html-plan自身のREADMEでは、/html-planに続けて作りたいものを書く例が示されています。一方、公式の一般的な説明では、スキルのコマンド名にプラグイン名が付いて表示される場合があります。手元では候補に表示されたコマンド名を選ぶのが確実です。html-planのREADME

このあと掲載するプロンプトは、そのスキルを選んでから渡す依頼文の例として読んでください。この記事ではインストールや実行の成功までは検証していません。

最初の1件を、生成・確認・回答まで進める

導入後は新しいClaude Codeセッションを開くか、プラグインを再読み込みし、/の候補にhtml-planがあることを確認します。見つからなければ/pluginのInstalledで有効状態と導入範囲を見ます。

計画を依頼するときは、例えば「この変更の計画をhtml-planで作り、plan.htmlに保存してください。単体HTMLにまとめる検査を行い、保存先と結果を報告してください」と伝えます。ファイル名は編集部の例で、固定の出力名ではありません。ブラウザでファイルを開き、各判断を確認したうえで、ページのRespondから回答をコピーし、元のClaude Codeの会話へ貼り付けます。以下では、その判断で見るべき内容を説明します。

計画を読む順番は「画面で何が変わるか」から

html-planのREADMEでは、計画を段階的に開いて読める構造が紹介されています。最初に利用者に見える変化、その下に仕組み、さらに必要ならコードを読む、という順番です。質問への回答やコメントをまとめてClaudeへ戻す流れも用意されています。計画の構造と回答の流れ

この順番を、身近な例で考えてみます。

社内の問い合わせ管理画面に、「担当者を選んで、自分が対応する問い合わせだけ見たい」という要望が来たとします。

ファイルを中心に説明されると、「一覧コンポーネントを更新」「検索APIの引数を追加」「クエリを修正」という計画になりがちです。開発者には意味が通じても、日々その画面を使う人が知りたいことは、もう少し手前にあります。

「担当者を選んだ瞬間に一覧が変わるのか」「検索ボタンを押すのか」「担当者を外すと全員分に戻るのか」。ここが見えれば、仕事の場面を思い浮かべて答えられます。

たとえば朝、自分の未対応分を確認する人なら、最初から自分が選ばれているほうが便利かもしれません。一方、全員分を見て割り振る管理者には、毎回自分の分だけ出ると不便です。同じ「担当者で絞る」という短い要望にも、二つの使い方があります。

計画を画面の変化から読む意味は、ここにあります。技術的な説明が始まる前に、作ろうとしている機能が本当に仕事に合うか判断できる。html-planを試すなら、まずこの読みやすさを見たいです。

最初の依頼には、利用場面と困りごとを入れる

ここからは、問い合わせ一覧を題材にした独自の使い方を紹介します。日常の開発で試すために考えた例です。

最初から細かいファイル名を指定できなくても大丈夫です。何をする人が、どこで困っているのかを先に渡します。

社内の問い合わせ一覧に、担当者で絞り込む機能を追加したいです。

利用者は、朝に自分の未対応分を見る担当者と、
全員の状況を見て割り振る管理者です。
今は件数が多く、自分の担当分を探すのに手間がかかっています。

既存の画面と検索処理を調べ、html-planで計画を作ってください。
通常の表示、該当する問い合わせがない場合、読込中、
取得に失敗した場合について、画面でどう見えるかを確認したいです。

判断が必要な仕様は、選択肢とおすすめの理由を出してください。
まだアプリの実装には進まず、先に計画を見せてください。

この依頼で伝えているのは、色や余白の好みではありません。誰が使うのか、何に困っているのか、どの場面を確認したいのかです。

「使いやすくして」という依頼だけだと、AIは使いやすさの基準も自分で補います。担当者に便利な初期表示を選んだ結果、管理者の仕事を遅くするかもしれません。利用者を二種類書くだけでも、考えるべき違いを表に出せます。

反対に、依頼文へ思いつく限りの条件を詰める必要もありません。最初から全部決めようとすると、いま確定している条件と、まだ相談したい希望が混ざります。「これは必須」「ここは相談したい」を分けたほうが、計画のどこを見ればよいか明確になります。

モックで見るべきは、普段の画面以外の3場面

画面のモックは、完成後の見た目を考える材料になります。ただし、きれいにデータが並んだ一枚だけでは、仕事で困るところを見落としやすいです。

今回の例なら、まず「問い合わせが0件」の画面を見ます。単に空白になるのか、「この条件に合う問い合わせはありません」と出るのか。条件を解除する場所は、その画面でも見つけられるのか。

0件は、必ずしも異常ではありません。担当業務が終わった結果かもしれないし、条件の選び方が違うのかもしれません。画面に何も出ないだけでは、利用者は状況を判断しづらくなります。「読み込みに失敗したのか」と不安になる可能性もあります。

次は「読み込み中」です。担当者を切り替えた直後、前の担当者の一覧が残っていると、今見ている結果が誰のものか迷います。すぐに白紙にするのがよいのか、前の結果を薄く残すのか。これは見た目の好みだけでなく、間違った問い合わせを開かないための判断です。

最後に「取得に失敗した場合」を見ます。再試行できるか。選んだ担当者は保持されるか。エラー文は何を意味するのか。「失敗しました」とだけ出るより、一覧の更新に失敗していて、問い合わせ自体が消えたわけではないと分かるほうが、次の行動を選びやすくなります。

この3場面を並べると、普段の画面では見えなかった仕様が出てきます。モックに完成品らしい見栄えを求めすぎず、利用者が迷う瞬間を見つけるために使う。そのほうが、計画段階での価値を確かめやすいと思います。

質問は、実装が変わる分岐に絞る

質問がある計画書でも、質問が多すぎると読み手は疲れます。「どのようなデザインがよいですか」「何色が好きですか」と並んでいても、いま決めるべきことが見えない場合があります。

今回の例で先に決めたいのは、たとえば次の3つです。この機能なら自分は何を確認するか、という提案です。

1. 一覧を開いたとき、最初は全員分を出すか、自分の担当分を出すか。
2. 担当者を選ぶとすぐ検索するか、検索ボタンで確定するか。
3. 画面を開き直したとき、前に選んだ担当者を引き継ぐか。

どれも利用者の仕事や実装に関わる判断です。初期値を誰に合わせるかで、担当者と管理者の使い勝手は変わります。検索のタイミングで考えたいのは、操作回数と画面の反応です。前に選んだ条件を覚えるかどうかも、翌日に迷わず使えるかに関わります。

AIには選択肢だけでなく、おすすめと理由も出してもらうと判断しやすいです。ただし、そのおすすめは決定済みの仕様ではありません。

たとえば「朝に自分の担当分を確認する人が多いので、自分を初期値にする」という提案があったら、その前提を確かめます。管理者も毎朝使うなら、利用者ごとの設定が必要かもしれない。あるいは、初期値は全員のままにして、「自分の担当」へすぐ切り替えられるだけで十分かもしれません。

よい質問は、作るものを決めるための分岐です。答えた後に何が変わるかが分かると、判断する意味も見えてきます。

回答を返すときは、未確認の項目を明示する

公開されているスキルの説明には、質問を開いて既定の案を維持した場合と、質問を開かず既定の案が残った場合を区別する記述があります。後者を同意と見なさないよう、明示されています。回答の扱いに関する説明

この違いは、実務でもかなり大切です。

「変更していない」は、「読んで了承した」とは限りません。忙しくて飛ばしたのかもしれないし、質問の存在に気づかなかったのかもしれません。あらかじめチェックが入っている画面では、特に意識しておきたい部分です。

自分が確認するなら、返答する前に質問だけを一度見直します。判断できない項目があれば、黙って既定値を残すより、「利用者へ確認したいので、この項目は保留」と書きます。ほかの部分を進めてよいかどうかも添えると、作業範囲を共有できます。

また、画面を見ている間に気が変わることもあります。最初は即時検索がよいと思っていても、複数の条件を組み合わせるなら、最後に検索ボタンを押すほうが使いやすいかもしれません。そういう変更は正常です。計画の段階で見つかったからこそ、コードを大きく直す前に相談できます。

回答を返す作業は、単なる「承認ボタンを押す時間」ではありません。何を理解し、何を選び、何をまだ決めていないのかをAIへ伝える時間です。

自動チェックが通っても、仕事に合うとは限らない

html-planには、HTMLを検査し、計画の表示に必要な関連ファイルを一つにまとめる処理があります。公開されているpack.mjsでは、計画の構造などを検査し、エラーがあれば出力を止める仕組みを確認できます。公開されている検査・梱包処理

こうした仕組みは、作った計画を読みやすく渡す助けになります。ただし、検査の通過を、その計画で仕事がうまく回る証明にしてはいけません。

問い合わせ一覧で、「担当者を変えると一覧が更新される」という説明と、その画面が正しく構成されていても、管理者が本当に必要としていたのは「担当者が決まっていない問い合わせを先に探す」ことかもしれません。計画の形が整っていても、目的を外している可能性は残ります。

また、モックで検索が成功しているように見えることと、本物のデータで正しく検索できることも別です。計画を確認した後には、実装した画面で動かし、条件を変え、件数や対象が合うか確かめる作業があります。

レビューでは「見せ方の不備」と「判断の誤り」を分けると考えやすくなります。前者は検査で拾える範囲があります。後者を確かめるには、目的、利用者、既存の仕組みと照らして人が読まなければなりません。

新しいツールに期待するなら、「確認を省くこと」より、「確認する場所を見つけやすくすること」に期待したいです。

検査で止まった場合の直し方：たとえば回答欄が質問番号を持たず、Respondに含まれないなら、見た目だけ直して完了にせず、該当番号と回答の対応を直します。生成を依頼したClaudeへ「使用したpackコマンド、検査の終了状態、生成ファイルの保存先を示して」と頼み、ファイルを開いて同じ質問を選び直します。検査コマンドは導入した版のSKILL.mdに合わせます。コピーできない場合は質問番号と回答を手動で転記し、未回答を勝手に補わず戻してください。

日本語の計画書が、そのまま保証されるわけではない

日本語で使う人には、もう一点共有しておきたいことがあります。確認した公開版のスキルには、説明文を簡潔な技術英語の規則に沿って書くよう指定があります。日本語の計画書が常に意図どおり出ることを、この記事で保証することはできません。公開版の文章規則

そこで、最初から全社共通の日本語レビューに導入するより、小さな変更一つで読みやすさを確かめるのがおすすめです。ここでいう小さな変更は、失敗しても困らないという意味だけではありません。画面の目的を自分が把握していて、計画が正しいか判断できる題材を選ぶ、という意味です。

もし計画が英語で出て読みづらければ、Claudeとの会話で「この判断項目を日本語で説明して」と頼む方法も考えられます。ただし、説明を翻訳することと、HTML内の選択肢を変更することは同じ作業ではありません。どの回答を返すのか、番号や内容を対応させて確認します。

チームで使う場合も、実装担当だけが読めればよいのか、業務担当者まで読める必要があるのかで評価が変わります。道具の機能一覧より、実際に確認する人が意味をつかめるかを優先したいです。

すべての変更にHTMLの計画が必要なわけではない

ここまで読むと、毎回使ったほうがよさそうに見えるかもしれません。でも、計画を作るための手間もあります。

誤字を一つ直す、リンク先を決まったURLへ変える、明らかな余白の崩れを直す。こうした変更なら、何を直すかがすでに共有できていて、差分と結果を見れば判断できる場合が多いです。

一方、複数の画面をまたぐ変更や、利用者によって期待が異なる機能では、先に判断をそろえる価値が大きくなります。問い合わせ一覧の例でも、担当者を選ぶ部品を置くだけなら簡単そうに見えますが、初期表示、ページ送り、空の状態まで考えると、相談したい点がいくつもあります。

自分なら、導入するかどうかを「変更するファイルの多さ」だけでは決めません。「作ったあとに初めて分かる食い違いがありそうか」を考えます。ファイルが少なくても、利用者に見える動きが変わるなら、画面を先に見せる意味があります。

逆に内部の修正で見た目が変わらないなら、画面のモックを無理に増やす必要はありません。何を維持し、どの条件で同じ結果になると確かめるのか。その説明が読める計画になっているかを見ます。

道具を使うこと自体を目的にせず、その変更で必要な会話を助けるかどうかで選ぶのがよいと思います。

試すなら、時間より先に「見つかった食い違い」を記録する

新しい開発ツールを評価するとき、「何分速くなったか」は分かりやすい指標です。ただ、計画の道具は、一度使っただけでは効果を判断しにくいところがあります。

今回のような使い方で自分が見たいのは、次の3点です。いずれも推奨する評価方法であり、html-planの効果として測定済みの数字ではありません。

まず、実装前に仕様の食い違いを見つけられたか。たとえば「初期表示は全員分だと思っていた」と分かったなら、計画を読んだことで相談が起きています。

次に、確認したい箇所へ迷わずたどり着けたか。全部を上から読み直さなくても、質問や画面の状態を見つけられるなら、その読み方には価値があります。

最後に、回答後の実装が合意した内容と一致したか。計画がよくても、実装で違う動きをしていたら、計画から開発へ渡すところに課題が残っています。

記録は簡単で十分です。「最初に想像していた動き」「計画で気づいた違い」「選んだ仕様」「実装後の結果」を一つの変更について残す。数件たまると、自分の仕事では画面のモックが効くのか、質問の出し方が効くのかが見えやすくなります。

読みやすかった、きれいだった、だけで終わらせず、どんな判断を助けたかを見る。それなら、使い続けるかどうかも自分の経験を根拠に決められます。

読む順番と、答える問い

試用のときに残す記録

よくある質問

標準のPlan Modeと同じですか？

コミュニティ向けに配布されるプラグインです。標準機能の全面変更として扱いません。

まとめ

まず一つの変更で、実装前に必要な判断ができるかを試します。見た目の整った計画と、仕様を確認できた計画を分けて評価しましょう。