週次レポートをSlackに貼っても既読すらつかない。PowerPointでまとめた提案書を送っても「後で見ます」と言われたまま流れていく。Notionに丁寧に書いた手順書は、リンクを踏まれた形跡すらない。チームで働いていると、こういう「作ったのに読まれない資料」の壁に何度もぶつかる。
私自身、Claude Codeで作った検証レポートをMarkdownやPDFで共有していた時期は、まさにこの壁にぶつかっていた。転機になったのは、AIに「1枚で完結するHTMLファイル」として資料を作らせ始めてからだ。ダブルクリックすれば誰の環境でも同じように開き、しかも触って反応が返ってくる。単一HTMLファイルを「読ませる資料」ではなく「配布できる実行体」として使う、その実務上の活用法をここに書いていく。
依存なしで開ける、配布が一行で終わる
そもそもAIとのやり取りでMarkdownとHTMLのどちらを選ぶべきか、というフォーマット選択の論点は「HTML is the New Markdown」という記事で詳しく扱った。今回はフォーマットの選び方ではなく、成果物としてのHTMLファイルそのものの使い方に絞って書く。
Claude CodeでもClaudeのArtifactでも、HTMLファイルを1枚に生成させると、CSSもJavaScriptも画像もすべてがそのファイルの中に埋め込まれる。外部のCDNにも社内サーバーにも依存しない。メールに添付してもいいし、Slackにドラッグ&ドロップしてもいい。受け取った側はダブルクリックしてブラウザで開くだけで、ネットワークに繋がっていなくても中身を確認できる。
この「1ファイルで完結する」という性質は、Claude CodeのArtifact機能そのものが持つ技術的な制約(外部リクエストを一切許さない設計)からも生まれている。その仕組みの詳しい中身、どこまでが安全でどこからがガバナンス上の注意点かは、以前「Claude CodeのArtifact機能、社内利用で漏洩しないか検証する」という記事で扱った。今回はその制約の副産物として、ローカルファイルとして人に渡すという、より一般的な使い方に焦点を当てる。
画像を1ファイルに埋め込むには、data URIという仕組みを使う。画像データを文字列としてHTMLの中に直接書き込む方法で、これを使えば「HTML1枚だけ送ればいい」を実現できる。ただしBase64というエンコード方式の性質上、元の画像よりファイルサイズが3割ほど増えるというトレードオフがある。スクリーンショットを何枚も貼り込んだ資料だと、この増加分がそのまま重さに跳ね返ってくるので、大きな画像を多用する資料にはあまり向かない。
印刷やオフライン利用にも強い。@media printというCSSの仕組みを使えば、画面表示用のボタンやナビゲーションを印刷時だけ非表示にできる。「経営会議で紙に印刷して配る可能性がある」といった要件がある場合は、AIへの指示に一言添えるだけで対応できる。
「レポート」から「ミニアプリ」へ
単一HTMLファイルが本当に威力を発揮するのは、静止した資料としてよりも、入力を受け付けて計算する小さなツールとして使うときだと感じている。ローン返済シミュレーター、社内向けのROI計算機、稟議書のチェックリスト、簡易的な診断フォーム。こうした「ちょっとした業務ツール」を、エンジニアの手を借りずにAIだけで組み立てられる。
私が実際に試したのは、1on1の準備チェックリストだった。「聞くべき質問」「避けるべき言い回し」をチェックボックスでまとめ、全部にチェックが付くと「準備完了」と表示されるだけの簡単なものだが、Notionのテンプレートよりも実際に使われた実感がある。理由は単純で、開いた瞬間に何をすればいいか一目で分かり、操作した結果がその場で返ってくるからだ。読むだけの資料と、触って反応が返ってくるツールでは、使う側の関与の度合いがまるで違う。
こうしたミニアプリを作らせるときは、依存関係を断つ言葉を明示的にプロンプトへ入れるのがコツだ。私が実際に使っているテンプレートを載せておく。
Build this as a single HTML file with everything inlined: no separate
CSS/JS files, no external libraries, no CDN links, plain vanilla JS.
The tool should be: [ここに機能を書く。例: 残業時間から翌月の負荷を診断するフォーム]
Show the calculation formula used at the bottom of the page, so a human
can verify the logic.
Make sure it still looks correct on a 600px-wide screen.
日本語にすると「外部ライブラリなしの単一HTMLファイル、Vanilla JSのみで作ってほしい。CSSとJSは同じファイルにすべて埋め込むこと。使った計算式は画面の下部に明記して、人間が検算できるようにしてほしい。スマートフォンの幅(600px)で見ても崩れないようにしてほしい」という指示になる。特に計算式を画面に明記させる一文は地味だが効果が大きい。見た目が整っているツールほど、中身のロジックが正しいと錯覚しやすい。実際に自分で検算できる状態にしておくことは、意思決定に使うツールでは欠かせない。
なお、Claude CodeのArtifact機能には、公開したページがMCPコネクタ経由でその都度最新データを取りに行く、準ライブ更新型のダッシュボードを作れる機能もある。閲覧者ごとに自分のアカウント権限でデータを取得する仕組みで、作った瞬間のスナップショットではなく、常に最新の状態を見せられる。
⚠️ ただしこの機能を使うには、Team/Enterpriseプランの管理者があらかじめこの機能をトグルで有効にしている必要があり、Pro/Maxプランでも閲覧者側が接続を許可する操作をしないと動かない。誰でも見られる公開リンクでは使えない、という制約もある。社内向けの限定共有を前提に検討したほうがよい機能だ。
単一HTML vs PowerPoint vs Excel/SaaS、判断軸で選ぶ
それでも「結局PowerPointでいいのでは」「Excelで十分では」という声は当然出てくる。作成時間を定量的に比較した信頼できる調査は見当たらなかったので、時間短縮の数字を語ることはしない。その代わり、判断軸ごとに質的な違いを整理してみた。
| 判断軸 | 単一HTML | PowerPoint | Excel/専用SaaS |
|---|---|---|---|
| 配布のしやすさ | ファイル1つ、メール添付・Slack共有で完結 | ファイル1つだが専用ソフト・ビューアが前提になる場合がある | SaaSはアカウント・権限設定が必要、Excelはバージョン差異が起きやすい |
| 保守性 | ソースはテキストだが、1行直すだけで生成物全体が書き換わりやすい | スライド単位で編集しやすいが、過去バージョンとの差分は見えにくい | Excelは数式が壊れやすい、SaaSはベンダーの仕様変更に依存する |
| コスト | 追加ソフト・ライセンス不要、ブラウザさえあれば動く | Office/Keynote等のライセンスが前提 | SaaSは月額課金が前提、Excelはライセンス前提 |
| 向いているケース | 計算ツール・チェックリスト・軽量な社内ダッシュボードなど、配布したその場で完結させたいもの | 対面プレゼンでストーリーとして語る資料 | 大量データの集計・分析、複数人での同時編集 |
表からも分かる通り、単一HTMLが得意なのは「配布したら、その場で完結してほしいもの」だ。逆にプレゼンで喋りながら見せる資料や、大人数で同時に触るスプレッドシートには向いていない。「これはHTMLで渡すのが自然か」を都度立ち止まって考えるくらいがちょうどいい。
落とし穴——受け取る側の立場で考える
便利な反面、単一HTMLファイルには見落としやすいリスクもある。ここは筆者自身の実務経験からの注意点として書いておきたい。
知らないHTMLファイルを開くリスク
HTML形式のファイルは、フィッシングやマルウェア配布の手口として昔から使われてきた。理由は単純で、拡張子が「.html」というだけでは無害に見えてしまい、メールセキュリティのフィルタをすり抜けやすいからだ。JavaScriptを埋め込んで、開いた瞬間にブラウザ上で偽のログインフォームを組み立てる、といった手口も知られている。
これは煽るために書いているのではなく、単一HTMLを配布物として使う運用を始めるなら、セットで考えておきたい現実的な注意点だという話だ。自分がAIで作ったファイルを渡すときは、「これはClaude Codeで作った社内資料です」とSlackメッセージやメール本文に一言添えるようにしている。既知の社内ドメインやチームの共有ドライブ経由で渡す、送信元が分かる経路を使う、といった当たり前の配布導線を意識するだけで、受け手の警戒感はだいぶ変わる。逆に、心当たりのない相手から届いた.htmlファイルは、どれだけ丁寧に作られていても不用意に開かない、という基本を崩さないことも大切だ。
機密情報とファイルの中身
data URIで画像を埋め込む設計は、スクリーンショットや図表がBase64という文字列としてファイルの中に残ることを意味する。人の目には読めない文字列だが、中身が消えているわけではない。ファイルを社外に渡す前には、埋め込んだ画像に機密情報が写り込んでいないか、一度中身を確認する癖をつけたい。
保守性とShadow AI化
JavaScriptをファイルに直書きする設計は、動かすまでの手軽さと引き換えに、バージョン管理のしにくさを抱える。1行直しただけでも生成されたHTML全体が丸ごと書き換わることが多く、Gitの差分レビューはお世辞にも快適とは言えない。
もう一つ気になるのは、非エンジニアが自分でこうしたツールを作れるようになった結果、IT部門の目の届かないところに「誰も所有していない業務ツール」が増えていくリスクだ。セキュリティ企業の調査でも、組織の多くがAIツールの利用実態を十分に把握できていない、という指摘がある。単一HTMLの気軽さは長所であると同時に、「誰かが個人で作った、レビューされていないツール」が知らないうちに業務プロセスへ組み込まれる入り口にもなりうる、と筆者は見ている。便利だからこそ、チームで使うツールについては誰が作ったか・どこに置かれているかを一言共有しておく運用がちょうどいい。
まとめ
単一HTMLファイルは、資料を「読んでもらう」ものから「渡したらその場で動く」ものに変える手段だ。次に週次レポートやチェックリストをAIに作らせる機会があれば、今日紹介したプロンプトの一文、「単一ファイル・Vanilla JSのみ・計算式を画面下部に明記」を、そのまま付け加えてみてほしい。15分もあれば試せる。
あなたが今読まれずに眠らせている資料のうち、ひとつでも「渡したら動くツール」に変えられるとしたら、それはどれだろうか。

コメント