開発mdx-playground

この日やったこと

NVIDIA 2026年定時株主総会のJensen Huang Business Updateを音声入力で受け取り、日本語翻訳+SVG図解の記事に仕上げた。 出力先は最終的に apps/web/content/2026-06/2026-06-25/nvidia-2026-annual-shareholder-meeting-japanese.md。 途中で3回フィードバックが入り、そのたびにClaude Codeに直しを派遣して反映する流れになった。

「人間は画面を見て違和感を拾う係、AIは実装を回す係」の構図がきれいに出た日。

ステップ1: 音声入力 → memo HTMLで翻訳と図解のキャンバスを作る

ユーザーから音声入力でJensenのBusiness Updateが流れ込んできた。 内容は10〜15年ごとの computing reset(mainframe → PC → internet → cloud → mobile → AI)、60年続いた「人間がソフトを書き、コンピュータが命令を実行する」パラダイムの転換、Blackwellランプ、各事業セグメントの進捗。

最初の判断として「いきなり公開記事に書くより、memoで検討キャンバスを作って配色・余白・図解の判断材料を出してから本番に流す」方針にした。 保存先は memo/2026-06-25/nvidia-2026-annual-meeting-jp.html。 HTMLにしたのは、SVG図解とCSSで本物の記事レイアウトに近い見え方を確認したかったため。

Claude Codeに memo HTMLを書かせて、ブラウザで開いて配色・図解の位置・全体の流れをチェックした。

ステップ2: 「公開記事の方に入れといて」→ 本番展開とSVG外部ファイル化

memo HTMLが固まった段階で、ユーザーから一言。

OK、ありがとう。公開記事の方に入れといてください。

ここで本番展開に切り替えた。

  • slug は nvidia-2026-annual-shareholder-meeting-japanese
  • 保存先は apps/web/content/2026-06/2026-06-25/nvidia-2026-annual-shareholder-meeting-japanese.md
  • SVGはインラインのままだと記事が肥大化するので、apps/web/public/images/nvidia-2026-annual-shareholder-meeting-japanese/ 配下に figure-01.svgfigure-07.svg の7枚を外部ファイル化

content-managementスキルでfrontmatterルールを確認してから、SVG 7枚をサブエージェントの並列起動で書かせた。 記事本体は1つにまとめて、![](/...) 形式で各SVGを参照する構成にした。

ステップ3: フィードバック1 ── 雨風空メタファーを削除

ここで1つ目のフィードバックが飛んできた。

だからこの雨風空とか入れないでください。鬱陶しいんで。その構成はその構成でいいんで、もう分かりきったことは書かないでください。だからこれね、多分スキルに依存してると思うんですけど、ドキュメントコミュニケーションの。

doc-communicationスキルの「空・雨・傘」フレームがそのまま本文に「【空】今期はBlackwellランプが…」「【雨】これにより…」「【傘】したがって…」と顔を出していた。 構成として裏で使う分には機能するが、読者に対して「いま空の話をしています」と書き出すのは確かにうざい。

該当箇所を全部削除した:

  • 記事の見出し「空・雨・傘サマリー」→ 「サマリー」に変更
  • 各セクションの【空】【雨】【傘】ラベルを削除(中身の3点要約は維持)
  • memo HTML 側も同じく削除して整合性を保つ

スキルが裏でフレームワークとして働くのは良いが、それを本文に露出させるとAI臭が出る、という体感が残った。 今後 doc-communicationスキルを使うときの記憶事項として刻んだ。

ステップ4: フィードバック2 ── 三角矢印の向きが逆

次にスクショ付きで指摘が来た。

これ矢印というか、三角のその図形の矢印の向きが逆っすね。三角の尖ってる方が右じゃないですか。

3つ並んだフェーズ図(左から右に時系列で流れる)の境界線に三角形を置いていたが、その三角の頂点が左を向いていた。 左→右の流れなら頂点は右を向くべき。完全にミス。

SVGの修正は座標を3点ずらすだけ。figure-03.svg(記事側)とmemo HTML内のインラインSVGの両方で同じ修正をかけた。

<!-- Before: 頂点が左 -->
<polygon points="190,80 170,70 170,90" />

<!-- After: 頂点が右 -->
<polygon points="198,80 178,70 178,90" />

3つの矢印すべてで x座標を 190 → 198 366 → 374 542 → 550 にずらして頂点を右に向けた。 画像を見た瞬間「あ、本当だ」となるタイプの間違いで、目視チェックの重要さを再認識した。

ステップ5: フィードバック3 ── 業績ハイライトはSVG装飾ではなくP&L表組に

3つ目のフィードバック。

やっぱ売上高、営業利益、EPS、キャッシュフローとかは、普通にテーブルデータっぽい表記にしてくれませんかね。SVGの図なんですけど、普通にそのなんだろう、いわゆるPLっぽくしてくれませんか。

最初はカード型のSVG装飾(売上高をでかく出して、横にYoY%バッジを添える)で作っていた。 ぱっと見はビジュアルだが、読者が「いくらいくら」と数字を拾うには情報密度が低い。

figure-05.svg をP&L風テーブル形式に作り直した:

  • 行: Revenue / Operating Income / EPS / Operating Cash Flow / Free Cash Flow
  • 列: FY26(実績)/ YoY 増減 / コメント

罫線とフォントを抑え、IBスタイル寄りの落ち着いた表組にした。 memo HTMLのインライン版も同じ表組に揃えて、両者の見た目が割れないようにした。

数字を読ませたいときは図解より表組、というシンプルな判断基準を改めて確認した。

学び

  • スキルのフレームワークは裏で効かせ、本文に露出させない。doc-communicationの「空・雨・傘」はストーリーを組む段階で効かせる道具であって、見出しに【空】とラベルを出した瞬間にAI臭が出る
  • 形を作るのはAI、違和感を拾うのは人間。三角の向きが逆、P&L風の方が読みやすい、メタファーが鬱陶しい ── どれもスクショ1枚+一言の指摘で十分で、人間がやるのは「眺めて違和感を言葉にする」だけ
  • memo HTMLは本番前のキャンバスとして機能する。配色・余白・図解の判断材料を本番ファイルとは別の場所で詰められるので、public/ 配下を汚さずに済む

明日以降に持ち越し

  • doc-communicationスキルに「『空・雨・傘』を本文に明示しない」ルールを追記する(同じ指摘が再発しないように)
  • SVG図解で「数字を読ませる図」と「流れを見せる図」の使い分け基準をスキル化する