自作APIのMCP化講座をMiller Column形式に変換して公開した — レビュー指摘の全ページ横展開とCOPYボタン復活

「昨日の積み残しって何かありましたっけ」と2つのリポジトリで聞くところから一日を始めた。mdx-playground 側にはチュートリアル用リポジトリの GitHub push が、eurekapu-nuxt4 側には Miller 講座のカラムずれ修正の未コミットが残っていた。そこから journal-mcp チュートリアル（自作の仕訳APIをMCP化する講座）を Miller Column 形式の講座に変換し、レビュー対応を経て公開するところまで進んだ。

先に結論を書く。

mdx-playground の長文記事を eurekapu-nuxt4 の Miller Column 講座に変換する仕組みは、既存スキルの転用ではなく計画書を書かせて新規に実装した。データ6ファイル・ページ7本・配布zipまで1セッションで形になった
レビューで「全部のページを同じようにしてほしい」と指摘し、コード抜粋を4ページ・12セクション・15箇所に横展開させた。1箇所直して終わりにしない
ブラウザレビュー時のサイズ変更は実ウィンドウのリサイズ禁止・viewportエミュレーションで行う、というルールを ~/.claude/rules/browser-review-emulation.md に固定した
本日3コミット（講座追加 → 公開 → 一覧カテゴリ再編）。すべて学習ゲート（/learn）経由

朝: 積み残しの回収から

eurekapu-nuxt4 側の積み残しは、Miller 講座の本文カラムが目次の有無で100pxずれる問題の修正（前日実施・未コミット）だった。検証スクリプトを回してもらい、design-system 全ページのズレ0件を確かめてから /learn を通してコミット、そのままデプロイまで進めた。本番URLでも症状の解消を実測してもらって完了。

mdx-playground 側は journal-mcp チュートリアルのリポジトリ作成が残っていた。GitHub 側にまだ存在しないことを確かめて、プライベートリポジトリとして作成・push。保留になっていたキャラクターモーション化は「もうやらない」と決めて締めた。積み残しリストを眺めて、やるものとやらないものを朝のうちに切り分けられたのがよかった。

記事→講座の変換: スキルの転用か新規か

eurekapu-nuxt4 には「スキルをコンテンツに変換する」既存スキル（skill-to-content）がある。ただ今回やりたいのは逆方向に近くて、mdx-playground で書いたリポジトリ付きの長文記事を、eurekapu-nuxt4 の「0から作る実務スキル」セクションに Miller Column Layout で載せることだった。これに対応するスキルはない。新規で作るか、既存スキルに追加するかは任せる形で「ミラーカラムレイアウトでこっち側に作ってほしい」と依頼した。

計画書を書かせたところ変更対象が10ファイルを超えたので、ルールどおり Codex レビューにかけた。2周回して指摘5件を全部反映してから計画書を確定。実装は eurekapu-nuxt4 側の新セッションで始めたかったので、フルパス前提の引き継ぎプロンプトを出させてセッションを切り替えた。

実装: データ6ファイル・ページ7本・QAまで

実装セッションでは計画書の Step 1〜8 を順に走らせた。

講座データ6ファイル（millerJmcpSetup.ts 〜 millerJmcpScale.ts）を原典記事から執筆
ページ .vue 7本（slot型の入口 contents.vue + Loader型6ページ）
配布ファイル（コード6ファイル＋zip）
全7ページ 200 OK を確認後、Chrome DevTools で描画QA

途中で章扉SVGを11箇所追加させ、原典との突き合わせ（parity検証）が PASS を維持していることも確かめた。機械照合と目視QAの両方を通してから、計画書に実装時の補正を記録させて実装フェーズを閉じた。

ブラウザレビューはエミュレーションで — ルールとして固定

QAが終わってレビューしようとブラウザに向かったら、表示幅がQA用に調整されたままだった。「戻しておいてくれませんか」と頼んで解除してもらったところで、これは逆にチャンスだと気づいた。

以前から、レビューのたびにブラウザの実ウィンドウをリサイズしてスクリーンショットを撮られると、自分が見ている全タブのサイズまで変わってしまうのが困っていた。今回はエミュレーション（viewport の上書き）で調整していたので、自分のウィンドウは元のまま。「レビュー時のサイズ変更は必ずエミュレーションでやってほしい。これどこに記録すればいいんですかね」と聞いたら、全プロジェクト共通ルールとして ~/.claude/rules/browser-review-emulation.md に新設し、グローバル CLAUDE.md にポインタを足す形で記録してくれた。

# モバイル確認はウィンドウを触らずエミュレーションで
emulate viewport: "390x844x3,mobile,touch"
# 終わったら空文字で解除（解除までがワンセット）
emulate viewport: ""

「どこに書けばいいか分からないが、この運用は残したい」というときに、記録先の選定ごと任せられるのは楽だった。

レビュー対応: 「全部のページを同じようにしてほしい」

計画書にレビュー対応フェーズを追記させ、次のセッションでレビュー指摘を投げていった。

最初の指摘は api ページの「勘定科目ホワイトリスト」セクション。本文はホワイトリスト制の設計を語っているのに、Python でどう定義しているか（ACCOUNTS の dict）が画面に出ていない。該当コードの抜粋を導入文付きで表示させた。

直ったのを見て、次はこう指摘した。「全部のページを同じようにしてほしいわけなんですよ。このエンドポイントも3つだけっていうところも、結局Pythonでどう定義してるか表示できるわけじゃないですか。全ページですよ」。本文がコードの設計を語っている箇所すべてが対象になり、4ページ・12セクション・15箇所の抜粋が追加された。あわせてコードブロック左上にタブ型のファイル名ラベルも付けさせた。1ページ直して満足せず、同種の全箇所に広げる指摘を最初から言えたのは、過去に「1箇所だけ直して終わり」で何度も往復した経験があるからだと思う。

COPYボタンの復活

もうひとつ気づいたのが、コードをコピーするUIが講座変換で消えていたこと。コマンドはコピペしたいので復活を頼んだ。実装はシンタックスハイライトを当てている v-highlight-code ディレクティブにボタンを注入する方式に落ち着いた。クリックで api.py 全文4,486文字がクリップボードに入るのを readText で実測させ、モバイル幅390px（これもエミュレーション）でボタンの重なりを見つけて直すところまで確認して完了。

コミット3本と学習ゲート

この日の eurekapu-nuxt4 側のコミットは3本になった。

43a982a7: 講座一式の追加（48ファイル・+5,657行。レビュー対応分も含む）
8395321f: draft 解除で公開
11084de7: 講座一覧のカテゴリ再編

コミットはいずれも学習ゲート（/learn）経由。講座一式のコミットでは、クイズ4問中「draft: true の本番挙動」を問う設問で自分が1問落とした。再出題で合格して受領証発行、コミット。draft の挙動を分かっていなかったのは、直後に「あ、これはオープンでいいです」と公開指示を出す自分にとってちょうどいい復習だった。公開は topics.ts の2行削除だけで済んだ。

夕方には講座一覧のカテゴリ再編も実施。途中、別セッションで走らせていた英単語アプリの作業が動いていない気配だったので、ファイルの最終更新時刻で様子を確かめてもらってからカテゴリを変えた。学習ゲートのクイズを30分放置してタイムアウトさせる場面や、モデルの利用上限に当たる場面もあったが、「続きやってくださいね」で再開して3コミット目まで到達した。

学び

記事→講座の変換のような「既存スキルがありそうでない」作業は、転用か新規かの判断ごと任せて計画書から始めると速い。10ファイル超なら Codex レビューを挟む運用も機能した
計画 → 実装 → レビュー対応をセッション3本に分け、切り替えのたびにフルパス前提の引き継ぎプロンプトを出させる流れが安定していた。計画書に「レビュー対応フェーズ」のセクションを追記させてから切り替えたので、次セッションが迷わず走り出せた
レビュー指摘は「この1箇所」ではなく「同種の全箇所」で出す。全ページ横展開（12セクション・15抜粋）を1往復で終えられた
ブラウザレビューのサイズ調整はエミュレーション一択。実ウィンドウを触られると自分の見ている全タブが巻き込まれる。ルールファイルに固定したので次回からは指示不要
変換で消えた既存UI（コードコピー）に気づけたのは実画面レビューのおかげ。機械照合（parity検証）はコンテンツの脱落は拾えても、UIの脱落は拾えない