菜单
note.com の記事を企画・執筆・サムネ生成・投稿まで一気通貫で行う。ユーザーが「note記事を書いて」「noteに投稿して」と頼んだときに使う。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | note-article |
| description | note.com の記事を企画・執筆・サムネ生成・投稿まで一気通貫で行う。ユーザーが「note記事を書いて」「noteに投稿して」と頼んだときに使う。 |
このスキルは note-mcp（drillan/note-mcp）と codex MCP を組み合わせて、note の記事をサムネ付きで生成・投稿するためのものです。画像生成は Codex のサブスクリプション内で完結するため、OpenAI API キーは不要です。
以下がセットアップ済みであること。未セットアップなら README の手順へ案内する。
note-mcp が MCP クライアントに登録されている（https://github.com/drillan/note-mcp）note.com に note_login 済み（Cookie が OS キーチェーンに保存済み）codex MCP が登録されている（Codex のサブスク内で画像生成できる）sips（macOS標準）または ImageMagick が利用できる| ツール | 用途 |
|---|---|
note_create_draft | 下書き作成 |
note_update_article | 記事の更新 |
note_publish_article | 下書き→公開 |
note_upload_eyecatch | アイキャッチ（サムネ）アップロード |
note_upload_body_image | 本文埋め込み用画像アップロード |
note_insert_body_image | 本文に画像挿入 |
note_upload_audio | 音声ファイル(.mp3/.aac/.m4a) を本文に埋め込み |
note_upload_file | 任意ファイルを添付として本文に埋め込み |
note_insert_toc | 目次ブロックを末尾に挿入（通常は h2/h3 から自動生成されるので不要） |
note_login | ブラウザログイン（初回のみ） |
note_check_auth | 認証状態確認 |
note_set_username | username を手動設定 |
ユーザーの要望を聞いて、以下のステップを順に実行する。途中でユーザーに確認する箇所は必ず止まること。
次の情報を引き出す（明示されていなければ質問する）：
見出し（H2, H3）レベルの構成案を Markdown で提示し、ユーザーに「この構成で書いていい？」と確認する。ここで必ず止まる。
合意した構成に従って Markdown で本文を書く。note互換の記法に注意：
$${...}$$（KaTeX互換）[TOC] または <!-- TOC --> を単独行で書くと、note-mcp の Markdown 変換器が <table-of-contents> ブロックに変換してそこに目次が出る（自前変換なので、変換せずに [TOC] を直接書くと文字列のまま表示される従来の罠は回避済み）<!-- IMAGE: プロンプト --> というプレースホルダーを残しておき、Step 7 で埋め込む`code`）を一切使わない。note のレンダラはリスト内だけでなく 本文の地の文に書いた場合も インラインコードを別ブロック扱いにして、その前後に巨大な余白を挿入する（実測済みの罠）。コマンドやフラグやファイルパスを示したい場合は次のいずれかで代替する：
**npx skills add**）「~/.claude/skills/」）本文は templates/article.md を下敷きに使ってもよい。
note エディタで「＋ → 埋め込み → URL を入力 → 適用」とやる手作業は、本スキルでは 完全に不要。
note-mcp の Markdown→HTML 変換器が、対応 URL を 単独行（前後に空行を入れた独立したパラグラフ） で見つけると、それを自動で <figure embedded-service="..."> の埋め込みプレースホルダに変換し、下書き作成後に /v2/embed_by_external_api を叩いて note サーバ側の正規 embed key を埋め込む。完成形は note 上で「＋ → 埋め込み → URL → 適用」を手でやったのと同じ、プレビュー画像付きのリッチ埋め込みになる。
| サービス | 認識される URL 形式 |
|---|---|
| YouTube | https://www.youtube.com/watch?v=… / https://youtu.be/… / https://youtube.com/embed/… |
| Twitter / X | https://twitter.com/<user>/status/… / https://x.com/<user>/status/… |
| note 記事 | https://note.com/<user>/n/n… |
〜という発表がありました。
https://www.youtube.com/watch?v=dQw4w9WgXcQ
詳しくは動画をご覧ください。
動画はこちら: https://... のように本文と混ぜると、ただのプレーンテキストとして表示されてしまう）[テキスト](URL) を使わない（テキストリンクになって埋め込みにならない）. / 。）を付けない（URL の一部として吸い込まれて埋め込み解決に失敗する）?v=xxx&t=42s）でも OK。ただし埋め込み iframe ではタイムスタンプは無視される（note 側仕様）| ❌ NG | ✅ OK |
|---|---|
動画はこちら: https://youtu.be/xxx | 一行空けて URL 単独行に分離する |
[YouTube動画](https://youtu.be/xxx) | リンクテキストではなく URL 単独行で書く |
https://youtu.be/xxx です。 | URL を単独行に出して です。 を別行へ |
- https://youtu.be/xxx（リスト内） | リスト外の独立段落として書く |
下書き作成後、note_get_preview_url でプレビュー URL を取得して開けば、埋め込みが正しく iframe としてレンダリングされているか確認できる。テキストのまま見えていたら Markdown 側で URL が単独行になっていない可能性が高いので、本文を見直して note_update_article で再保存する。
ユーザーがサムネ生成を希望した場合のみ。Codex MCP のサブスク内で画像生成できるので、OpenAI API キーは不要。独自の画像生成スクリプトは経由させない。
サムネには文字を入れるのがデフォルト （タイトル or キーワードを入れると CTR が上がる）。
mcp__codex__codex を次のように呼ぶ：
prompt: |
note 記事のアイキャッチ画像を1枚生成してください。あなた（Codex）の
サブスク内で使える画像生成機能を直接使ってください。外部 API は呼びません。
- アスペクト比: 16:9（後段で 1280:670 にクロップするため）
- サイズ: 1536x1024 程度
- 品質: 高品質
- 出力先: thumbnails/thumb_note_<UNIX秒>.png （タイムスタンプ付きで上書きしない）
プロンプト（英語）:
"<画像の見た目を英語で具体的に。"Bold large text 'XXXX' in clean sans-serif at center" のように
テキストの内容と配置も英語プロンプト内で具体的に指示する>"
最後に保存した絶対パスを1行で報告してください。
cwd: <ユーザーのプロジェクトルート>
sandbox: workspace-write
approval-policy: never
サムネの文字に関するルール:
保存ファイル名は thumbnails/thumb_note_<UNIX秒>.png 形式で重複を避ける。返ってきた保存パスは Step 6 で使う。
note_create_draft を呼ぶ。引数はタイトル・本文（Markdown）・タグ。返り値として 記事ID が返ってくるので必ず保持してユーザーにも明示する。
重要: note.com のアイキャッチは アスペクト比 1280:670 が必須。違う比率だと API が {"error":{"code":"invalid","message":"見出し画像は1280:670の縦横比の画像を設定してください"}} を返し、note-mcp 側では "API response missing required field 'url'" という誤解を招くエラーに化けて見える。
アップロード前に 必ず 1280:670 にクロップ + リサイズする。macOS なら sips で完結：
SRC=thumbnails/thumb_note_<UNIX秒>.png
DST=thumbnails/thumb_note_<UNIX秒>_1280x670.png
cp "$SRC" "$DST"
# 元が 1672x941（16:9）の場合、1672x875 にクロップしてから 1280x670 にリサイズ
sips --cropToHeightWidth 875 1672 "$DST" >/dev/null
sips --resampleHeightWidth 670 1280 "$DST" >/dev/null
元のサイズが違う場合は target_ratio = 1280/670 ≈ 1.91 に合わせてクロップ値を計算しなおす。
クロップ後の画像パスを note_upload_eyecatch に渡す。
ユーザーから記事内に載せたい動画ファイル（.mp4 / .mov / .webm など）が渡された場合は、必ずこのステップを挟む。Step 1 のヒアリングで動画がある場合 or 添付ファイルから動画を検知した場合に発動。
note の本文画像 API（note_upload_body_image）が受け付けるのは .gif / .jpeg / .jpg / .png / .webp のみ。
| 形式 | 可否 |
|---|---|
| mp4 / mov 直接アップロード | ❌ 不可（API が拒否） |
| アニメーション WebP | ❌ note 側で invalid_param エラー（静止 WebP は OK だがアニメは弾かれる） |
| アニメーション GIF | ✅ OK（ただし 10MB 以下） |
| YouTube / Vimeo URL | ✅ URL 単独行で自動的にリッチプレビュー化 |
ffprobe -v error -show_entries format=duration -of csv=p=0 src.mp4
SRC=src.mp4
DST=thumbnails/clip.gif
ffmpeg -y -i "$SRC" \
-vf "fps=10,scale=450:-2:flags=lanczos,split[s0][s1];[s0]palettegen=max_colors=64[p];[s1][p]paletteuse=dither=bayer:bayer_scale=5" \
-loop 0 "$DST"
scale=420 → scale=400 のように横幅を削るfps=8 まで落とすmax_colors=48 まで下げると更にサイズダウンするが画質は落ちるnote_upload_body_image で GIF をアップロード → 本文の動画埋め込み箇所に Markdown 画像として挿入
*GIFは画質・色数を圧縮しているため、フル品質は<元ソース>でご覧ください。*
fps=15, scale=540 でも 10MB に収まることが多い本文中に 適度に画像を挟む（読みやすさ・視認性アップのため）。プレースホルダーは <!-- IMAGE: 画像内容の説明 --> 形式で本文に残しておき、このステップで実画像に置き換える。
画像を入れる目安（AI が自動判断する）:
画像の入手方法（優先順）:
page.screenshot()実装手順:
<!-- IMAGE: 画像内容の説明 + 出典URL（あれば） --> プレースホルダーを残すnote_upload_body_image でアップロード → 返ってくる Markdown 断片（画像URL）を取得note_update_article でプレースホルダーを画像 Markdown に置換*画像出典: [タイトル](URL)* を添えるスクショ撮影時の注意:
重要な落とし穴: note_update_article は 下書き（note_draft.body）だけを更新する。すでに公開済みの記事に対して呼んでも、読者が見る公開側の本文は古いままになる。
公開後に本文を修正したら、必ず note_publish_article を再度呼んで公開側に反映する。
注意点：
separator_uuid も新しい body から取り直す必要がある（古い UUID を渡すと 有料エリアを再度設定し直してください エラーで失敗）note_update_article → note_get_separator_candidates で新 UUID 取得 → note_publish_article(separator_uuid=新UUID, ...) で再公開note_publish_article は内部的に /v3/notes/{id} の data.name（公開版タイトル）を再利用してしまうため、note_update_article で新タイトルに変えた後に note_publish_article を呼ぶと 公開側のタイトルは古いままになる。確実に直すには PUT /v1/text_notes/{numeric_id} を直接叩いて name フィールドに新タイトルを明示的に渡す。直接叩くサンプルは note-mcp-patches/changes.patch を参照下書き URL をユーザーに伝え、プレビュー確認を促す。ユーザーが「公開して」と言ったら note_publish_article を呼ぶ。ユーザーの明示的な許可なく公開しない。
公開時、ユーザーが希望すれば以下を一緒にセットする（note_publish_article の引数）：
magazine_keys: マガジン追加（事前に note_list_my_magazines で一覧確認）circle_plan_keys: メンバーシップ限定にする（事前に note_list_circle_plans で一覧確認）price: 有料記事化（円）separator_uuid: 有料エリア開始位置（後述の自動選定を使う）limited: True で有料モード ONユーザーが価格設定を希望した場合、AI が「いい感じの位置」を自動で選ぶ。ユーザーに位置を聞かない（毎回聞かれるのが面倒なので任せる方針）。
自動選定ルール（このルールで AI が separator_uuid を決める）：
note_get_separator_candidates で本文の全ブロック UUID を取得（h2/h3/h4/p）n 個のとき、floor(n * 0.4) 番目の h2 を選ぶ（0-indexed）
int(6 * 0.4) = 2 → 3番目の h2 がセパレータになるint(4 * 0.4) = 1 → 2番目の h2 がセパレータになる価格のデフォルト:
価格は 必ずユーザーに確認してから設定する。位置は AI が自動選定して結果を伝えるだけで OK（不満があればその時に変更要求がくる）。
選定結果は必ずユーザーに伝える（例: 「『○○』の見出しから後ろを有料エリアにします」）。
mcp__codex__codex）。Claude から OpenAI API を直接叩かない[…](URL) や同じ行への混在は禁止（埋め込みが効かなくなる、Step 3.5 参照）note_publish_article を呼ばないnote-mcp のツールが見えない: .mcp.json を確認 → Claude Code を再起動accounts.google.com が「このブラウザまたはアプリは安全でない可能性があります」と表示する場合、Playwright を Google が弾いている。メールアドレス + パスワード方式でログインするnote_login がタイムアウト: デフォルト300秒では足りないケースあり。600秒（10分）に延長して再実行note_set_username で後から設定可Use when creating and publishing a Japanese note.com article for AI PLAY GUILD / PORSEO as a free public article with no membership plan, no paid separator, and no price. Uses the shared note article workflow for article writing, fact-checking, screenshots/diagrams, 1280:670 eyecatch generation, note draft creation, preview/editor verification, original publish, unpublished duplicate preview creation, and Discord delivery. Do not use for light-plan limited articles or Zoom-recording-sourced Pro articles; use note-light-publish or note-pro-publish instead.
Use when creating and publishing a Japanese note.com article for AI PLAY GUILD / PORSEO from a Zoom recording or Zoom-derived material as a Pro-plan limited article with one-off 2000 yen access. Uses the shared note article workflow for article writing, fact-checking, recording screenshots/diagrams, 1280:670 eyecatch generation, note draft creation, paid separator setup, preview/editor verification, original publish, unpublished duplicate preview creation, and Discord delivery. Do not use for free public articles or non-Zoom light-plan articles; use note-free-publish or note-light-publish instead.
Use when creating and publishing a Japanese note.com article for AI PLAY GUILD / PORSEO as a light-plan limited article with one-off 500 yen access. Uses the shared note article workflow for article writing, fact-checking, screenshots/diagrams, 1280:670 eyecatch generation, note draft creation, paid separator setup, preview/editor verification, original publish, unpublished duplicate preview creation, and Discord delivery. Do not use for free public articles or Zoom-recording-sourced Pro articles; use note-free-publish or note-pro-publish instead.