「AIの文章長すぎて結局ちゃんとよんでないんですよね😅」
「Claude Code に毎月1.5万円超を払っているのに、元で回収できてる気がしてない」
AIを使っていること自体に満足して、実際に成果につなげている人はまだまだ少数です。「使った気」になってしまう状態です。
Claude Code を使っていて、こんな経験はありませんか？
- 月曜の朝に「先週の競合動向をまとめて」と頼むと、長いレポートが返ってくる。それをちゃんと読まずに軽く見ただけで放置してる
- AI任せで自分もちゃんと読んでいない資料をチームの誰かが読んでくれているわけがないと薄々気付いている
- Claude Code に毎月3,000円以上払っているのに、出力した成果物が会議や提案で 1 度も使われていない
- ChatGPT や Claude の 成果物 は綺麗だったのに、Claude Code から出てくるのはなぜ Markdown ばかりで文章読むのがしんどすぎる
これはそんな方向けの記事です。
この記事を読み終わるころには、自分も他人もちゃんと読んでくれる資料が、Claude Code から自然に出てくるようになります。
そして「Claude Code に何を頼むか」よりも、「どんなフォーマットで出させるか」のほうが、使い手の判断力としてはるかに大きい、という見え方も持って帰れるはずです。
Anthropic で Claude Code 本体を作っている開発者本人 Thariq Shihipar 氏 (@trq212) が、社内で広がりつつある考え方を X に書いたら、Claude Code 周辺ではトップクラスの保存数が付いて広がっています。
公開速攻でかなりの反響をすでに読んでいます。
AIオタクのちょっとしたテクニックの話ではなく、これまで AI 業界の暗黙の標準だった Markdown に、作っている本人が「もう違う」と一石を投じた話です。
重要だと考えたので速攻日本語で解説することにしました。
読み始める前に 2 つだけ。
- ブックマークしてください。今週 1 本だけでいいので、HTML で出してみるための時間を確保するためです
- Claude Code を一緒に触っているチームメンバーがいるなら、共有しておいてください。週報や PR レビューでの「読まれ方」が、来週から目に見えて変わります
今回はその内容を、日本のビジネス現場で何にどう効くかに置き換えながら、噛み砕いて解説します👇
元ポストはこちら：
https://x.com/trq212/status/2052809885763747935
Anthropic 内部の開発者本人がもう Markdown を使わない
ここから話の起点です。今回の元ポストを書いた Thariq Shihipar 氏 (@trq212) は、Anthropic で Claude Code 本体を作っている開発者本人です。Claude が plan モードで「ユーザーに質問を投げ返して要件を詰める」ふるまい、要件をインタラクティブにヒアリングする機能も、彼が手を動かして Claude Code に入れたものです。
その彼が、自分で作っているはずの Claude Code から、もう Markdown を受け取らなくなったと書いています。彼自身の言葉を借りると、Markdown は自分にとって制約のあるフォーマットになってきた、ということです。
これは個人の好みの話ではありません。Thariq 氏は記事の中で、Claude Code チームの内部でも HTML 採用が広がっている、と書いています。ツールを作っている当事者たちが、自分たちのツールから出てくる Markdown を捨てて、HTML に切り替え始めているわけです。
しかも証拠が触れる場所に置いてあります。デモサイト https://thariqs.github.io/html-effectiveness/ に、自己完結した HTML が 20 個並べてあります。debounced search の 3 アプローチ比較、タスク完了の小さな達成感を演出するマイクロインタラクション、design system のトークン一覧、コード例を切り替えられるタブ付き解説、用語集を本文の余白に置いた読み物。どれも「ざっと眺めるだけの文書」を「ちゃんと最後まで読まれる文書」に置き換えた実例です。手元のブラウザですぐ開けます。
ここまで読んで、ひとつ思い当たる節があるはずです。あなたが普段 ChatGPT や Claude.ai で受け取っている Artifacts、あの「タブで切り替わる UI」「色付きの図解」「動かせるボタン」は、実は HTML として出力されていたものです。「あれが綺麗に見えたのは、フォーマットそのものの差だったのか」というのが、ここでの腹落ちです。Claude Code でも、同じ世界が手元に出てくるようになります。
これまで AI が出してくるテキストは、ほぼ Markdown でした。その前提に、作っている人が静かに「もう違う」と異議を唱え始めている。ニュースとしての中身はそれだけです。ですが、毎日 AI と仕事をしているあなたにとって、これは月曜の朝から効いてくる話です。
そもそも Markdown は AI 業界の暗黙の標準だった
ここで一度、当たり前と思っていた前提を一緒に確認します。これがないと、HTML への切り替えがただの好みの話に見えてしまうからです。
これまで、AI 出力の事実上の標準は Markdown でした。日々目にしているテキストを思い返してみてください。
- Claude Code が読み書きしているプロジェクト直下の CLAUDE.md、エージェント定義の *.md、Skills の SKILL.md
- Anthropic の公式ドキュメント、Claude.ai の Help、Claude Code の各種ガイド
- 同業の AI 開発ツール群、Cursor の rules、GitHub Copilot の instructions、Cline の指示書も、すべて .md 前提
- 社内 Wiki、GitHub README、Notion から書き出したテキスト、Slack に貼られる議事録
- ChatGPT のチャットからコピーしてきたまとめ文章
ここまで全部、Markdown 前提で組まれてきた世界です。あなたが AI と接している文字情報のうち、Markdown 以外のフォーマットを思い出すほうが難しいくらいです。
Karpathy 氏が公開した CLAUDE.md パターンが GitHub で 8 万スター以上を集めたのも、Markdown が業界の共通言語だったからこそ起きた現象です。
Thariq 氏の言葉をそのまま借りればMarkdown は agent の主流フォーマットになっている、です。彼自身、長らく Markdown 前提でツールを作ってきた立場の人です。
その立場の人が、今回はっきり言いました。
Markdown は自分にとって制約のあるフォーマットになってきた、と。これは Anthropic の中の人が、業界全体が乗ってきた前提に「もう違う」と一石を投じた瞬間です。
「業界の標準」と書くと大げさに聞こえますが、要はこういうことです。
あなたが Claude Code から受け取っている Markdown も、Cursor が読み込んでいる rules も、社内 Wiki に貼ってある AI 出力も、全部「Markdown でいいよね」という同じ流れの中にあった。その流れに、作っている本人が違う水路を引き始めた。
ここから先は、なぜ Markdown では届かないのか、何に置き換えれば届くのか、という具体の話に入っていきます。
Markdown が読まれない 5 つの理由
ここで Markdown 側の限界を整理します。これは技術仕様の話ではなく、あなた自身の月曜から金曜までの体感の話です。元記事で挙げられている HTML の利点を、Markdown の側に裏返して並べました。
① 100 行を超えると、自分でも読まなくなる
Thariq 氏自身が書いています。Markdown ファイルが 100 行を超えると、自分自身が読むのをやめる、と。
あなたが Claude Code に「先週の競合動向をまとめて」と頼んだとき、返ってきた 120 行をスクロールせずに閉じた経験が、おそらくあるはずです。出した本人が読まないものを、チームの誰かが読んでくれることはありません。著者本人だけでなく、組織の他のメンバーも同じように読み流している、というのが現実です。
② 共有しても、ブラウザで綺麗に開けないから誰も触らない
Markdown はブラウザでネイティブには綺麗に描画されません。Slack に貼ると改行が崩れる、メールに貼ると体裁が壊れる、提案資料に組み込むときは PDF 化やスクリーンショットを挟む手間が要る。
共有のたびに、誰かが「読める形」に変換する作業が発生していました。それが面倒で、結局リンクが届かない、というところまで含めて、Markdown は共有のたびに摩擦を生むフォーマットです。
③ 色も図も付かないから、伝わるのは輪郭だけ
数字の差を強調したい、警告だけ赤で出したい、フローを矢印で見せたい。Markdown でこれをやろうとすると、ASCII 文字でダイアグラムを描いたり、Unicode の罫線文字で色を表現したりする羽目になります。
誰も読み解こうとしないし、書く側も疲れる。Claude が頑張って図を描いても、結局は読み流されて終わりです。
④ 触れない、動かせないから、読むだけで終わってしまう
色を少し落ち着かせたい、アニメーションの速さを試したい、数値を 1.5 倍にしたらどう見えるか確かめたい。
判断のために「触ってみる」が必要な場面は、ビジネスの現場でも頻繁にあります。Markdown ではそれができません。読んで、頭の中でシミュレートして、また文章で指示を返す、という非効率なループになります。
⑤ モバイルで開くと崩れる
移動中の Slack、移動中のメール、移動中の Notion。日本のビジネス現場では、共有された資料の半分はモバイルで最初に開かれます。
Markdown のレイアウトは画面幅に追従しません。表が横にはみ出す、コードブロックが折り返される、見出しの階層が見えなくなる。読む気はその瞬間に消えています。
ここで一度、名前を付けておきます。読まれない Markdown を量産するたびに、出した本人にも、共有された相手にも、開く前から疲労だけが積もっていきます。100 行をスクロールするコスト、Slack で改行を直すコスト、図と色がないせいで伝わらないコスト、触れないせいで判断が遅れるコスト、モバイルで崩れるコスト。
これら全部が、目に見えないところで毎日支払われている料金です。本記事ではこれを「フォーマット税」と呼びます。
これは小さい税金ではありません。Claude Code の価値の半分以上は、出力の中身ではなく「誰に、どこまで届くか」で決まります。届かないフォーマットで出している時点で、契約の半分を捨てているようなものです。
切り替え方は「HTMLファイルで出して」と書き加えるだけ
ここで身構える必要はありません。やることは思っているよりずっと少ないです。
普段の Claude Code への依頼の最後に、1 行だけ書き加えるだけです。次の 3 つはどれも同じ意味で通ります。
- 「HTML ファイルで出して」
- 「HTML の 1 枚もので出して」
- 「読み手がそのまま開けるように HTML にして」
英語で書く方が安心するなら、make a HTML file や make a HTML artifact でも大丈夫です。中身は同じです。
Claude Code は MCP、ブラウザ、git、ファイルシステムから文脈を取り込めます。ChatGPT や Claude.ai の Web チャット側よりも、はるかに広い情報源を 1 つの HTML に束ねて返してくる、というのが Claude Code 側の強みです。
ここで、先ほど触れた話と繋がります。あなたが ChatGPT や Claude.ai で受け取って「綺麗だな」と感じてきた Artifacts、あれは HTML として出力されていたものです。
同じ世界を、Claude Code 側でも受け取れるようになります。難しい技術の話ではなく、頼み方の 1 行を変えるだけで、ちゃんと届く資料が出てくるようになります。
ここで Thariq 氏が記事の中で念を押している点があります。「これを /html Skill にしないでほしい、まずはプロンプトから慣れてほしい」と書いているんです。彼自身が Claude Code チームの開発者で、Skill を量産する側にいるにもかかわらず、です。
これは Skill 化を否定しているのではありません。「使い方が固まる前にパッケージングすると、本当に効く部分を見逃す」という話です。
Anthropic 内部でも、HTML 出力のうち頻度が高くなったものは、後に Playground プラグインのような形で部品化され始めています。最初から完成品を待つのではなく、まず 1 行プロンプトで試して、自分の業務にハマる型を見つける。そこに辿り着いてから初めて Skill 化に進む、というのが推奨される順序です。
毎回プロンプトに「HTML で出して」と書くのは作業に見えますが、フォーマットを選ぶ判断そのものは作業ではありません。Markdown のままで出してくる Claude を、HTML で出してくる Claude に切り替えた瞬間に、あなたは「設計済みの Skill を待つ前に、出力を設計する側に半歩回っている」状態になっています。
5 つの業務シーンが HTMLに切り替えるだけで変わる
ここからが、月曜から金曜までの実務に効く章です。元記事に出てくる 5 つのユースケースを、日本のビジネス現場での出現頻度の高い順に並べ直しました。週報・リサーチ要約、企画書・調査資料の並列、デザイン微調整、判断のための編集画面、PR・仕様書レビュー、の 5 つです。
各シーンは、いまの困りごと、Before / After、最後に Claude Code に投げる指示文サンプル、の順でまとめます。
【シーン 1】 週報・リサーチ要約を、図解つきで届ける
日本のビジネス現場あるあるですよね。月曜の朝、上司から「先週の動向まとめて」と振られる、あの仕事です。
Before。120 行の Markdown を Slack に貼り付けます。
改行は崩れます。上司は開きません。経営会議の資料には載りません。「Claude にやらせたんですよ」と口頭で説明する羽目になります。
After。Slack の今週ログ、Linear や Notion のチケット履歴、git log、社内ドキュメントを横断して取り込んだ HTML 1 枚にまとめます。SVG で簡単な業務フロー図を入れ、注意点を 3 つだけ色付きブロックで下に置きます。
これを社内ストレージに置いて URL を共有すれば、上司は移動中のスマホでも開ける、経営層は引用できる、議事録に貼れる、という状態になります。
ここで効くのが、Claude Code が MCP、ブラウザ、git、ファイルシステムから文脈を取り込める、という点です。同じ「HTML を作ってください」を Web チャットに頼んでも、これだけの情報源を 1 つの HTML に束ねるのは難しい。Claude Code 側だからこそ作れる週報です。
Thariq 氏自身も、自分が書く記事の図解を、自分のコードフォルダの全 HTML を Claude Code に読ませて、そこから 1 枚にまとめて作らせた、と書いています。「読まれる週報」と「読まれる解説記事の図」は、構造としては同じです。
▼ 指示文サンプル：
「先週の Slack のやり取りと、Linear のチケット消化と、git log を全部読んで、上司が 1 分で把握できる週報を HTML 1 枚で出して。SVG で簡単な業務フロー図と、注意点を 3 つだけ色付きブロックで下に付けて。スマホで開いても崩れないようにして。」
【シーン 2】 企画書・調査資料を、6 案そのまま並列で見せる
来週の提案、どの方向で行くか。社内で複数案を作って意思決定者と擦り合わせる、企画／営業／経営企画でよくある場面です。
Before：
6 つの案を 6 つの Markdown ファイルに分けて送る。クライアントは 1 つずつ開いて読み比べることができない。「結局どれが一番おすすめなんですか」と聞き返されて、自分の中でも比較しきれていなかったことに気付かされます。
After：
トーン、密度、想定ターゲットを変えた 6 案を、1 枚の HTML にグリッド状に並べます。各案の下にトレードオフを 1 行ずつ付ける。意思決定者は 1 画面で全部を見比べて、「これとこれを混ぜたい」「3 番のターゲットで 1 番の密度にしてほしい」と即座に返してきます。並列で見せた瞬間に、議論の解像度が変わります。
意思決定者にとって、6 案を 6 ファイルで送られるのと、6 案を 1 画面で並べてもらうのとでは、判断にかかる時間が桁違いです。読んでもらえるようになる、というよりも、判断してもらえるようになる、という変化のほうが近いです。
▼ 指示文サンプル：
「来週の提案で出す企画案を 6 つ、トーン・密度・想定ターゲットを変えて、1 枚の HTML にグリッドで並べて。各案の下にトレードオフを 1 行で書いて。決定したら結果を Markdown でコピーできるボタンも下に付けて。」
【シーン 3】 デザイン・プロトタイプを、触って決める
色やサイズや動きを決めるとき、文章ですり合わせるのは諦めたほうがいいです。マーケ、広報、企画でも、サンクスメールやランディングページのボタンを巡って何往復も認識合わせが起きる場面です。
Before：
「もう少し落ち着いた青で」「動きをふわっと」と言葉で伝え合います。受け取る側のイメージは、毎回ずれます。1 周回って戻ってきた案を見て、「いや、そっちの落ち着きじゃなくて」とまた言葉を増やしていく。時間も精神も削れます。
After：
Claude Code に、色とアニメーション速度をスライダーで動かせる HTML を作ってもらいます。サンクスメールのボタン、ランディングページの CTA ボタン、こうした要素のプロトタイプを HTML 1 枚で作って、関係者に URL を投げる。各自が触ってベストの値を決めて、その値だけを Claude にコピペして戻す。文章の往復が減って、合意までの時間が短くなります。
これに関連して、Anthropic の Labs 側でも、こうした「触って決めて、その操作内容を Claude にコピペして戻す」型の発想が、Playground プラグインとして公式機能化され始めています。HTML 出力は単なる小ワザではなく、Anthropic 自身が型として育て始めている方向、ということです。
▼ 指示文サンプル：
「サンクスメール内のボタンの色とアニメーション速度を、3 種類のスライダーで動かしながら決められる HTML を作って。決定した値をコピーできるボタンも下に付けて。」
【シーン 4】 編集画面を、3 分で 1 枚作って判断する
来期どの施策を Now、Next、Later、Cut に振り分けるか。30 件のチケットを並べ替えて優先順位を決める、PdM、企画、経営企画にとって典型的な「判断作業」です。
Before：
スプレッドシートに 30 件並べ、優先度列を 1 つずつ手で埋めていく。ソートしては考え直し、別のシートに移しては戻す。30 分かけても結論が出ない、という日があります。
After：
Claude Code に「Now、Next、Later、Cut の 4 列にドラッグで振り分けられる HTML を作って」と頼みます。3 分で専用の編集画面が出来上がります。30 件のカードをドラッグで移して、振り分けが終わったら結果をコピー。判断作業の時間が桁で縮みます。
ここでひとつ、見落とされやすいけれど効きどころとして大きい設計原則があります。Thariq 氏が記事の中で「常にエクスポートで終わる」と書いている、あの一文です。編集画面を作るときは、最後に必ず「JSON でコピー」「プロンプトでコピー」「Markdown でコピー」のボタンを置く。
これがないと、せっかく振り分けた結果を Claude に戻せず、ただの作業ツールで終わってしまいます。HTML で判断して、その結果を構造化テキストで Claude に戻す、というループまで作って初めて、編集画面は判断装置になります。
これは feature flag の編集、システムプロンプトの左右比較エディタ、データセットの approve / reject / tag のような場面でも丸ごと同じ発想で使えます。「専用の使い捨て UI を 3 分で作る」というのが、Claude Code の真価が一番分かりやすく出るところです。
▼ 指示文サンプル：
「来期 30 件の施策を Now / Next / Later / Cut の 4 列にドラッグで振り分けられる HTML を作って。最後に『Markdown でコピー』ボタンを置いて、振り分け結果を 1 行ずつ理由付きで出力できるようにして。」
【シーン 5】 PR レビュー・仕様書共有を、色分け差分で渡す
最後は、エンジニアと協働する場面です。PdM、ディレクター、編集者、コードを読まない立場でも、PR レビューや仕様書の確認に呼ばれる、あの場面です。
Before：
GitHub の差分画面を開いてもらいます。差分のどこが大事で、どこは見なくていいのか、見ただけでは分かりません。コメント欄を読み込まないとストーリーが追えない。コードを読まない立場の人は、結局「何かあったら言ってください」と返して閉じます。
After：
Claude Code に「この PR を、コードを読まない立場の人でも 30 秒で全体像が掴める HTML レビュー資料にして」と頼みます。差分の横にコメントが付き、影響範囲が色で分かれ、最後に懸念点が 3 つだけまとめられた HTML が返ってきます。これを社内ストレージに上げて URL で共有すれば、PdM やディレクターも 1 ボタンで意見を返せるようになります。エンジニアと協働する側の立場の人も、これでようやくレビューに参加できるようになります。
ここで言いたいのは、HTML はエンジニアの言語ではなく、ストーリーを渡すための道具だ、ということです。差分の意味、リスク、影響範囲、こうした「読み解きが必要な情報」を、注釈と色とレイアウトで一緒に渡す。それが HTML 化の意味です。
▼ 指示文サンプル：
「この PR を、コードを読まない立場の人でも 30 秒で全体像が掴める HTML レビュー資料にして。差分の横にコメントを付けて、影響範囲を色分けで示して、最後に懸念点を 3 つだけまとめて。」
ここまでの 5 シーンを Markdown のままで出している間、フォーマット税は静かに、しかし毎日積み上がり続けています。気付いたタイミングで止めるかどうかが、来週からの違いになります。
切り替えるときに浮かぶ 6つの疑問は先回りで消える
ここまで読んでいただいた方の頭の中に、おそらく順番に浮かんでくる疑問があります。元記事の FAQ 章を、日本のビジネス読者の出会いやすい順序に並べ直しました。
■ トークンを多く使うのでは？
使います。元記事では、Markdown の 2-4 倍の生成時間がかかる、と書かれています。一方で、Opus 4.7 は 1M トークンのコンテキストを持っていて、HTML を返してきても context 切れで会話が破綻するシーンは事実上なくなっています。
「数字としては増えるが、結果が読まれる方を選ぶと、トータルの仕事として元が取れる」というのが Thariq 氏の結論です。あなたの月3,000円超の契約を、開かれない Markdown 1,000 行に使うのか、開かれる HTML 1 枚に使うのか、という選択の話です。
■ デザインがダサくなるのでは？
これはもっともな心配ですが、対策が用意されています。
1 つは、Claude Code の frontend design 系プラグインを使うこと。もう 1 つは、自社のサイトや既存資料からサンプルの HTML を 1 枚 Claude に渡しておくことです。「このトーンで」「このフォントとパレットで」と参照ファイルを渡しておけば、Claude はあなたの会社の見た目に合わせて HTML を出してきます。コードベースに design-system.html のようなファイルを 1 枚置いておくと、毎回参照させられます。
■ HTML を編集するのが面倒では？
これも気持ちは分かりますが、自分で編集する必要はありません。
Thariq 氏自身、自分で HTML を直接いじることはしていない、と書いています。「ここの色を少しだけ落ち着けて」「3 番目のセクションだけもう少し小さく」と Claude に話しかければ直してくれます。仕様書、ブレインストーミング、参考資料として使う限り、編集は全部 Claude に任せられます。
■ どうやって開くの？ どうやって共有するの？
開くのは簡単です。Claude Code が出した HTML ファイルを、ブラウザでローカルに開くだけです。
Claude に「このファイルを開いて」と頼めば、勝手にブラウザで開いてくれることもあります。共有するときは、社内ストレージや S3 のような場所にアップロードして、URL を渡すのが一番楽です。リンクを Slack やメールに貼れば、相手はブラウザで開けます。Markdown を PDF 化していたあのひと手間が、丸ごと消えます。
■ バージョン管理はどうするの？
正直、HTML は Git の差分管理にはあまり向いていません。1 行直すと、フォーマッタの都合で別の場所まで diff が動きます。Thariq 氏自身も、HTML は version control の最大の弱点だ、と書いています。
だからこそ、「人に届ける成果物」は HTML、「履歴を残したい仕様書や記録」は Markdown、という使い分けが現実解です。Markdown を全廃するという話ではなく、出力する目的別にフォーマットを選ぶ、という発想に切り替わります。
■ Markdown はもう使わなくていいの？
いいえ。記録、変更履歴、レポジトリに残しておきたい構造化されたテキストは、これからも Markdown のままで構いません。
CLAUDE.md や Skills の SKILL.md は Markdown のままで運用したほうが、差分が追えて運用しやすいです。HTML が向いているのは、「人に届ける」「触ってもらう」「複数案を並べる」「色付きで判断してもらう」、こういう成果物です。「Markdown は AI とのやり取り、HTML は人への配り物」、という大づかみで理解すると、迷いません。
ここまでで、「気になっていた疑問が一通り消えた」状態になっているはずです。短所も含めて書いてある記事は信用できる、というのも記事を書く側の信念です。
フォーマット税を払い続けるか 設計する側に回るか
ここまで来たら、最後に視座を 1 段上げて締めます。
以前扱った「プロンプト税」の話、つまり毎回同じ前提を Claude にチャットで打ち直しているコストの話。それから、.claude フォルダで設計レイヤーに上がる、という話。今回の「フォーマット税」は、その続編に当たる第 3 のテーマです。会話レイヤー、設計レイヤー、ときて、今回扱ったのが出力レイヤーです。
"フォーマット税"を、ここで一度、読者と共有できる定義として置いておきます。
読まれない出力フォーマットを選び続けると、自分にも他人にも、開く前から疲労が積もる。Claude Code に毎月3,000円以上払っているのに、成果物が会議で 1 度も使われない。あの感覚は、フォーマット選びを判断していなかったところから来ています。これがフォーマット税です。
Markdown のままで出すのは作業です。HTML を選ぶのは判断です。同じ Claude Code を使っていても、フォーマット選びという判断ひとつで、成果物の届く距離が大きく変わります。
そして、HTML はエンジニアの言語ではありません。読まれる資料を作るための道具です。Web サイトを組むという発想はいったん脇に置いてください。あなたが今週書く週報を、企画書を、レビュー資料を、HTML で出してみる。それだけで十分です。
少し大きい話もしておきます。
Markdown が AI 業界の暗黙の標準だった時代は、いま Anthropic の中で静かに終わりつつあります。CLAUDE.md も、SKILL.md も、Cursor の rules も、全部が Markdown 前提で組まれてきた世界の上に、出力フォーマットだけが先に切り替わり始めています。標準が変わる瞬間に立ち会っている読者は、半歩先に動けます。
もちろん、自分の中で「この使い方は毎週やっている」と分かってきたら、その時にはじめて Skill 化に発展させる選択肢も出てきます。
Anthropic 内部でも、デザイン系の Playground のような形で、HTML 出力の頻度が高い型は徐々に部品として育てられはじめています。ただ、最初の 1 週間は 1 行プロンプトで十分です。今夜、月曜の週報を 1 本だけ HTML で出してみる。来週の提案で 6 案を 1 枚のグリッドで並べてみる。そこから始めれば、フォーマット税は静かに減り始めます。
Thariq 氏自身も、記事の最後でこう書いています。Markdown を深く読まなくなって、Claude に判断を任せきりになる怖さが自分の中にあった、と。HTML に切り替えてから、Claude のループに居る感覚が以前よりむしろ戻ってきた、何より作っていて単純に楽しい、とも。
フォーマットを選ぶ判断は、AI と仕事をするときの主導権を取り戻すスイッチで、同時に毎日の仕事に少しだけ熱が戻るスイッチでもあります。
読まれない Markdown を量産し続けるのか、フォーマットを選ぶ側に回るのか。次の 1 週間が、その境目になります。
まとめ
- Anthropic で Claude Code を作っている開発者本人が、もう Markdown を使わないと宣言した。社内のチームでも HTML 採用が広がっている
- これまで Claude Code、Cursor、GitHub Copilot、Cline、社内 Wiki、ChatGPT 出力まで、AI 周辺は Markdown が暗黙の標準だった。その業界スタンダードに、作っている本人が一石を投じた
- Markdown が読まれない理由は 5 つ。100 行で読み返せない／共有のたびに崩れる／色も図も付かない／触って判断できない／モバイルで崩れる。これらの目に見えないコストが「フォーマット税」
- 切り替え方は「HTML ファイルで出して」と書き加える 1 行だけ。Skill 化は使い方が固まってからで遅くない
- 5 つの業務シーン、週報・リサーチ要約、企画書 6 案の並列、デザイン微調整、判断のための編集画面、PR レビュー、これらは HTML に切り替えるだけで、開かれる、判断される、戻ってくる資料に変わる
- フォーマット選びは作業ではなく判断。Markdown のままで出すのは作業、HTML を選ぶのは判断。Claude Code の使い手の差は、ここで開く
この記事が少しでも参考になった方へ。
東大Claude Code研究所（ @ClaudeCode_UT ）は、東大生チームが本気で運営しているアカウントです。大手企業との Claude Code 業務共同開発も進行中で、現場で実際に動いている設計とノウハウだけを発信しています。
実務特化型で「ガチで役立つ」情報やノウハウを毎日届けます👇
■ 実務で使える Claude Code スキルの無料公開
■ 海外の AI 一次情報を日本のビジネス文脈に翻訳・再構成
■ 『ガチで役立つ』ものを東大生チームが本気で開発したスキル・ツールとして無料で受け取れるのはここだけ❗️
ご興味を持っていただけた方は、ぜひフォローしてチェックしてみてください。
LINEはこちら⇩
