🗂 管理確認デッキ

横断ステータス（頭合わせ）

更新: 2026-07-03 3プロジェクト（Miyoki親 / Nompass本体 / Nompass LP・個別運用）を跨ぐ現在地の頭合わせ。 各事実の「正」は各プロジェクト側（下記「正の置き場」）。ここは要約＋ポインタのみ。矛盾したら正に合わせ、ここを直す。 どのフォルダで起動しても、まずこのファイルで3つの頭を揃える。

---

北極星（全プロジェクト共通の向き）

• Miyoki ⊃ Nompass：Miyoki（個人・親）が Nompass（事業・子）を内包。発信人格＝Miyoki Labs（AIプロダクトエンジニア）。
• 同じゴール：Miyokiの独立（月30万・別軸）× Nompass事業の伸長。両者は競合せず相互補強（Miyoki Labs＝実績、Nompass＝看板事例）。
• 最上位の正：人格・ブランド＝02_ポジショニング（人格キャノン）。全プロジェクトはここを向く。

---

Miyoki（親・C:\Miyoki）

• 現在地: Miyokiブログ公開2記事・収益導線稼働（2026-07-07時点：ドメイン比較=A8アフィリ7本・ファクトチェック済み／ChatGPT×Claude比較=実体験リライトで公開。正=公開台帳）。見た目改修完了（正式ロゴ/アイキャッチ・OGP自動生成/チェックリストUI）。記事の型=06_ブログ計画§6確定。pipeline側は⚠️審査ゲート暫定70点＋APIクレジット切れ（→Claude Codeスキル化でAPI脱却予定＝チャージ不要の方向）。
• 次の一手: 発信立ち上げの順番（ロードマップ実行キュー2026-07-05決定／2026-07-08に④追加）＝①承認ダッシュボード（コード完成・週末の本番反映=Access待ち／下記週末バッチ） → ②各媒体の自己紹介投稿 → ③記事リレー開始（X告知①はここ） → ④有料note 1本目（リレー3〜4本後）。並行=pipelineスキル化（API脱却・投稿レイヤー・リライトモード）。
• 📱 スマホでできる（平日夜・蓄積不要）: noteの本人確認＋振込口座設定（有料noteの前提。④より先に潰す）／自己紹介投稿4媒体（ドラフト済み＝投稿するだけ）。
• 蓄積の商品化（2026-07-08決定）: 「蓄積で稼ぐ」10案を検討 → 今期は有料note 1本のみ、残りは着手条件つき保留（表＝ロードマップ「蓄積の商品化」）。線引き＝理解は売らない、再現を売る（L1/L2/L3＋判定テスト。正=_knowledge-log-rule）。短期の現金化は受託（CW＋Nompass）が主軸で変えない。
• 🖥️ 週末PC限定バッチ（PCを開いたら上から消化）:
• [miyoki-post-deck] Access→token→deploy：①Cloudflare Access で限定公開（/api/*も保護＝Qiita投稿APIのガード本命）＋deck.miyoki-labs.com割当＋3幅実機確認 → ②wrangler secret put QIITA_TOKEN→npm run deploy→まず限定共有で1本テスト→公開。QIITA_TOKENは必ずAccess有効化の後に設定（順序厳守＝公開サイトに投稿可能APIを晒さない）。詳細=miyoki-post-deck「次の一手」。
• [GSC連携] OAuth本番運用への切り替え：2026-07-08にGoogle Cloud Console上でMiyoki用OAuthアプリ（プロジェクト名Miyoki Labs）をテスト状態で構築済み（Client ID/Secret/Refresh Token取得済み・未保存）。テスト状態のリフレッシュトークンは7日で失効するため、定期自動化を維持するには「検証センター」タブでwebmasters.readonlyスコープの本番運用化要件（プライバシーポリシー提出等）を確認し、本番（In production）へ切り替える。
• [GSC/Bingレポート] 週次の改善候補レビュー：毎週金曜22:30にWindowsタスクMiyokiSeoReportが自動実行し、個人\seo-insights\reports\にSearch Console＋Bing Webmaster（2026-07-08にAPI統合完了・gsc-report.mjsにGetQueryStats/GetPageStats追加）のレポートを出力。「🔎改善候補」セクション（CTRが低いキーワード／2〜3ページ目のキーワード）は自動抽出のみで判断はしていないため、週末PC作業のたびに最新レポートを開いて目視レビューし、記事直しの要否を判断する。実際の記事編集は必ずこのレビューを経てから行う（自動抽出→人が判断、の順を崩さない）。Bingのサイト検証・サイトマップ送信・優先ページのRequest indexingは2026-07-08に完了済み（「Discovered but not crawled」警告は新規ドメインの正常な遅延と切り分け済み）。
• [秘密情報] Bitwarden導入＋一元化：2026-07-09の認証情報漏洩対応（Neon DATABASE_URL・CRON_SECRET・counter-app Stripe をローテ済み）の後始末。.env をメモ帳代わりにしていた2FAバックアップコード類14件を C:\Users\kiyom\.secrets\vault.md（git外・平文）へ退避済み。①Bitwarden無料アカウント作成＋デスクトップ/ブラウザ拡張導入 → ②C:\Users\kiyom\.secrets\secrets-inventory.md（env全19ファイルのキー名の地図＝移行チェックリスト）を上から順に移送 → ③済んだら平文の vault.md を削除（plaintext撲滅）。スマホアプリも入れて平日運用に載せる。再発防止の要＝.envに控えを書かない。
• 正: 優先順位=ロードマップ／プロジェクト状態=プロジェクト棚卸し／ブログ設計=06_ブログ計画／人格=02_ポジショニング（Miyoki人格キャノン）。

Nompass本体（C:\Miyoki\Nompass）

• 現在地: 実装ほぼ完了・初顧客フェーズ（実顧客 tomomi の予行演習中）。
• 次の一手: nompass.jp LP実地テスト＋自動化まわりの実機確認。
• 🖥️ 週末PC: Buildテンプレ見た目改修（feat/rts-easing-and-heading・push済み・mainは無傷）の3幅目視→mainマージ待ち。作業は Nompass\build フォルダで起動する。手順=Nompass\build\docs\reference_rt-solutions.md §7。
• 正: C:\Miyoki\Nompass\STATUS.md（実装状況・インフラ・次アクションの唯一の正）。

Nompass LP・個別運用（C:\Miyoki\Nompass\Nompass Build\00.Nompass）

• 現在地: 個別運用の拠点。LP本体=client-Nompass-hp、自社発信=voice-kit（本番API温存・Claude Code生成→手動投稿）。
• 次の一手: Nompass STATUS の B-2（LP実地テスト）と連動。
• 正: 00.Nompass 配下／開発知見の母艦=knowledge-log/history/core.md。

---

正の置き場（SSOT・1事実1置き場）

整合性プロトコル（都度整合・自動）

どのフォルダで起動しても、これに従えば3者（Miyoki／Nompass本体／Nompass LP）の認識が同じ方向に揃う。

1. 開始時に読む：このハブ → いま触る領域の正（上のSSOT表）→ 人格の正（02_ポジショニング）。
2. 事実を変えたら：① その事実の正（SSOT）を更新 → ② ハブの該当ブロックを1〜2行だけ更新 → ③ 他プロジェクトに波及する事実なら該当ファイルも直す（例：ドメイン変更 → 06/07/C:\Miyoki\Nompass\STATUS.md）。
3. 齟齬を見つけたら：正（SSOT）に合わせて直し、ハブを更新。放置しない。
4. 迷ったら向き：上の「北極星」＋ 人格キャノン（02）に合わせる。
5. 薄く保つ：詳細はここに書かない（重複＝齟齬の元）。ハブは1画面に収める（＝「絞る」）。

roadmap 優先順位・リソース配分

確定方針：独立志向／名乗り=AIプロダクトエンジニア／Nompassとは別で月30万（独立ブースト）／ 可処分時間=平日夜21時〜＋土日のみ（少ない）。 時間が少ない＝「絞る」が最重要。手を広げない。 反映：Web/LP制作はNompassに一本化（Miyoki個人受託＝AI業務自動化・ツール開発の1本）。 フェーズ認識（2026-07-03）：いまは「作る」→「確かめる」フェーズ。各取り組みの需要深掘り＋最初の一歩は 2026-07-03-需要検証と最初の一歩。

【2026-07-09 最優先の更新】即金性・「退職/転職に使える時間創出」を最優先に格上げ（詳細は別途計画中）。 - 判断軸：すぐ現金になる／退職・転職の準備時間を生む取り組みを、それ以外（Nompass新規開発・発信の作り込み・蓄積の商品化）より前に置く。手を広げず、時間を生む方に絞る。 - API予算の制約は解除の見込み：Claude/Gemini のAPIを少額から自分でチャージして回す方針に決定（2026-07-09）。→ AI生成フォールバック（正=Nompass\docs\design\20_ai_generation_fallback.md）は、方針B（Claude.ai手動）を障害時の保険に降格、通常は正規API課金で回す。 - この転換に伴い、本セッションで積んだNompass/発信系タスク（媒体ガイド肉付け／投稿フェーズ戦略の実行／admin-deck実装 等）は時間創出の妨げにならない範囲で後追いにする。

---

実行キュー（2026-07-01 統合・最新）

2つの引き継ぎ（2026-07-01_ポートフォリオ公開／2026-07-01_ブランド統一と記事カード）を突き合わせた最新の実行順。下の「直近アクション（21時〜）」より優先。

• 【2026-07-05 決定】発信立ち上げの順番（P2の順序をこれで上書き）：
• 承認ダッシュボード開発（スマホから記事/投稿のチェック・承認・コピペ。仕様=miyoki-media-pipeline Phase 3）— Nompassの信用度向上・宣伝素材（AI業務自動化の実例）を兼ねるのでリレー開始より先行
• 各媒体の自己紹介投稿（Zenn/Qiita/note/X固定ポスト。一覧=記事キュー冒頭）— 入口に来た人が「何者か」わかる状態を先に作る。※P2の「Zenn初投稿=ai-portfolio下書き」は自己紹介に置き換え（旧下書きは2本目以降に回す）
• 記事リレー開始（公開済みブログ記事のX告知①もここから。リレー・曜日時間帯=03_posting_workflow）
• 並行して pipeline の Claude Codeスキル化（API脱却）を進める（正=miyoki-media-pipeline）
• 【2026-07-08 追加】有料note 1本目（③のリレーが3〜4本回ってから／読者ゼロで有料を出さない）。束ね＝記事キュー#31〜34「Claude Codeを自動運用するときに踏む地雷と、踏まないためのhook設計一式」。980円スタート。KPIは売上額ではなく販売実績（受託の信用装置）。設計の正=03_収益化②-b／線引き規約=_knowledge-log-rule／消化順=記事キュー
• 📱先行して済ませる（スマホ完結・蓄積不要）：noteの本人確認＋振込口座設定

• 【2026-07-03 着手中】ストック収益の箱＝Miyokiブログ構築（詳細 06_ブログ計画）。本人判断で発信ロールアウト（P2）より先行。
• ✅ miyoki-labs.com 取得完了（2026-07-04・Cloudflare Registrarで直接決済成功。当初懸念していた決済不調は再試行で解消、Xserver迂回は不要だった）
• ✅ Astro実装（個人\miyoki-blog） → Cloudflare Pages で blog.miyoki-labs.com Custom domain設定済み（DNS反映待ち・最大48h）／ポートフォリオ用に miyoki-labs.com（ルート）も同時設定済み
• MVP＝◎必須のみ（タグ/関連記事/TOC/著者/ページネーション/CTA差替/アフィリUI/slug）
• アカウント方針：現Cloudflare=Miyoki／Nompass分離は案件増加時に後追い（06_ブログ計画 付録）
• P0｜セキュリティ（✅完了・2026-07-04）：counter-app の git履歴に残存していたStripe秘密鍵をローテーション済み（Firebase Secret Manager登録＋deploy確認）。public化するなら履歴クリーン化（git filter-repo）は別途必要。
• P1｜ブランド統一の反映（✅ 全媒体リネーム完了・2026-07-02）
• ✅ 各媒体リネーム完了：note/X/Zenn/Qiita=miyoki_labs、GitHub=miyoki-labs、表示名=Miyoki Labs、ハンドルは全て小文字。アイコン使い分け（X/note=人物、Zenn/Qiita/GitHub=Mロゴ）・ヘッダー・YouTubeリンク削除まで済み。詳細はメモリ miyoki-labs-branding と 2026-07-01-アカウント設定手順書。GA4測定ID=G-WWQHEJ2B95（Zenn設置済）。Zennは作り直し済（旧記事の再投稿は保留＝新規で書き直す）。
• リネーム後：miyoki-portfolio/src/data/articles.ts の ZENN_USER/QIITA_USER を miyoki_labs に、src/data/site.ts の全リンク差し替え（youtubeリンク削除も同時）→ npm run deploy。
• ✅ リンク集ページ /links（実装済み）：Linktree的な導線をポートフォリオ内に実装済み（個人\miyoki-portfolio\src\app\links\page.tsx＋共通 components\LinkTree）。外部サービスは使わない＝ハブ集約。
• 内容：Mロゴ＋名乗り／ボタン群（ポートフォリオ本体・Zenn・Qiita・GitHub・X・note・Nompass＝別ブランド明記）＋各一言。
• ヘッダーにも Links を追加し、クリックでリンクツリー形式のパネル（ドロップダウン）表示。中身は /links と共通コンポーネントにして1回実装で両対応。X bioの着地先＝/links。
• 「@miyoki_labs で探して」を見せ場に：全媒体ハンドルが小文字統一なので、/links・トップ・フッターに「Find me everywhere → @miyoki_labs」を配置。統一ハンドルを最大の武器として前面に出す。
• P2｜発信ロールアウト（受託の入口＝現金化に直結）
• Zenn初投稿：2026-07-01-ai-portfolio-cloudflare-pages（published:false）を確認→末尾にポートフォリオURL→公開。
• 順次：2本目Zenn（seedsの「next/image」等）→ note（ビジョン1本）→ Qiita（AEO/構造化データ）→ X告知スレッド。
• 記事公開のたび npm run deploy（記事カードも最新化される）。
• P3｜ポートフォリオ仕上げ
• 記事カード Phase 2：note（RSS）の fetchNote() 実装（noteリネーム後）。週次自動更新は Deploy Hook不可なので npm run deploy 運用 or ルーティンに追加。
• /contact（問い合わせフォーム → Slack通知＋記録メール／Turnstile）は後追い。本人がメールを開かない前提で、通知をSlackに集約（詳細は 04_ポートフォリオ計画「/contact設計」）。独自ドメインは本格運用時（site.ts siteUrl変更＋Cloudflareで割当）。
• P4｜ストック：miyoki-media-pipeline のサイト別プロファイル対応 → Miyokiブログ（アフィリ）1本目。
• P5｜温存：SDC（RAG改修／teleapo）、家族向け、次の柱。受託化できれば前倒し。

背景で稼働中：記事ネタ週次自動収集 MiyokiSeedScan（金曜22:00 → ideas/seeds-miyoki.md / seeds-nompass.md）。 需要ヒアリングログ（父/母/税理士候補への需要検証を随時蓄積。P0〜P4の優先度は変えず、隙間時間で並行収集）。

---

完了までの段階（α〜δ）

「完了」を4段階に分ける（新規開発を待つと無限に伸びるため）。詳細な残作業は各P・構築予定を参照。可処分＝平日夜＋土日の少なめ前提。

• α 発信・現金化ローンチ：リネーム（手作業）→ portfolioハンドル差替+deploy → 発信ロールアウト（Zenn→note→Qiita→X）。約2〜3週。※律速＝アカウントのリネーム。
• β ストック自動化の定着：pipelineサイト別プロファイル+seeds結合 → アフィリ1本目 → harvestループ習慣化。αと並行で +2〜3週。
• γ 既存の仕上げ：RAG改修（要件次第）。※counter-app Stripe鍵ローテは完了済み。
• δ 新規開発：上記「構築予定」（RAG系譜／家族向け／SaaS構想）。各要件確定後に見積。

作りかけの仕分け（全部を完成させない＝「絞る」の実践）：

• 収益に効く（pipeline / portfolio / RAG本番）＝完成させる（α・β・δ）
• デモ実績（Proposal / Writing / teleapo / counter / reply-draft）＝見せられる状態で“完成扱い”・作り込まない
• 趣味（character / Horse Racing）＝塩漬け保持（受託に効かない・優先度最下位。※扱い変更可）
• hp-builder-test/miyoki-portfolio＝新portfolio公開後にアーカイブ

立ち上げ〜自動化定着（α+β）＝約1〜1.5ヶ月。γ/δは要件次第。

---

時間配分の目安

---

P1：現金化（最優先）— 受託で月30万へ

• (1) ポートフォリオ完成（04準拠・MVP優先）：build流用でトップ＋/works(実績5件)＋/contact＋/about＋/privacyをまず公開。
• (2) 受託メニューを1本に集中：AI業務自動化・ツール開発（RAG/提案文/執筆自動化が実績）。
• 少数・高単価・短納期化（テンプレ/AI活用）。21時〜＋土日で回せる範囲に絞る。
• Web/LP案件はNompassへ（個人では受けない＝送客）。
• (3) CW（クラウドワークス）活性化（プロフ作成済・未獲得 crowdworks.jp/public/employees/5476485）：
• ボトルネックは提案運用（CWは応募型。プロフだけでは獲得できない）。→ 自作 Proposal Generator で定型提案文を用意し、平日夜＋土日で週数件応募する運用に乗せる（ドッグフーディング＝実績にもなる）。
• プロフ最適化：アイコン＝人物（受託接点）／肩書き=AIプロダクトエンジニア／実績にポートフォリオ・制作物リンク／受注メニューはAI業務自動化・ツール開発に特化（HP/LPはNompass送客なのでCWでは前面に出さない）。
• 初期は実績づくり優先（低単価でも1〜2件受注→レビュー獲得→単価上げ）。

P1並走：Nompass — 初顧客獲得・運用

• プロダクトはほぼ完成。新規開発は抑え、初顧客の獲得・運用に寄せる。
• Web/LPの受け皿はここ（build＝量産テンプレが本体）。

P2：ストック仕込み — 半自動運用

• miyoki-media-pipelineを仕上げる（サイト別プロファイルが肝、05参照）。
• Miyokiブログ（学習者向けAIツール紹介/Pros·cons）を週1本ペースで半自動運用。
• 記事ネタはideas/seeds-miyoki.mdから。

P3：温存（後回し・受託化できれば前倒し）

• SDC：RAG改修／teleapo（SMS自動化）。受託化できれば前倒し。
• 家：父(建設業の効率化)・母(経営コンサル向け)＝小さく実用から。
• 個人（次の柱）：税理士向けAI活用コンサル、業種特化マイクロSaaS。

構築予定（新規開発パイプライン・2026-07）

すべて要件検討中。同じ粒度で管理し、漏れが出たらここへ同粒度で追記する。期間は要件確定後に見積（完了段階のδ）。新規は立ち上げ時に knowledge-log をテンプレから最初に敷く。 2026-07-08再検討：優先順位（P0〜P5）は変更なし。構築予定は全項目「需要検証フェーズ」のまま据え置き、需要ヒアリングログ.mdで低コストに並行収集する（専用の時間枠は確保しない＝他Pを押しのけない）。

RAG系譜（源流＝SDC向け accounting-tax-rag-demo＝“作ってみた”デモ）

• 業務効率特化RAG（本番化）：源流の本番版。Embeddings+ベクトルDB／社内データ連携／専門家確認ワークフロー。別リポ想定。
• 税理士向けチャットボット：源流RAGの発展形（②）。税理士事務所/顧問先向けの税務Q&A。

家族向け業務効率化

• 父用ツール（建設業）：新規。小さく実用から。
• 母用ツール（経営コンサル向け）：新規。小さく実用から。

SaaS構想（次の柱・温存）

• AIライティングSaaS：pipeline（深掘り）＋voice-kit（多媒体展開）の統合。個人運用は分離のまま、プロダクト化は温存。
• 業種特化マイクロSaaS：次の柱の本命枠。上記の税理士向け/家族向けが特定業種SaaSの起点になりうる。
• 着手条件（2026-07-08決定）：家族向けツール（父/母のいずれか）が実際に3ヶ月以上使われ続けたら、同業種への横展開を検証する。それまでは着手しない。

蓄積の商品化（2026-07-08 検討・着手条件つき保留）

「蓄積で稼ぐ」10案を検討した結果、今期やるのは有料note 1本のみ（上記P2-4）。残りは下表の条件を満たすまで着手しない。 凍結ではなく条件付き保留＝再検討のたびに同じ議論をしないための記録。判断根拠は 03_収益化②-b。 切り分けの軸＝「事務手続き（蓄積不要・📱スマホ完結）は先に仕込んでよい／中身の制作は蓄積後」（2026-07-08 Miyoki決定）。

短期の現金化は①受託（CW＋Nompass）が主軸という 03_収益化 の二段構えは、調査の上でも変えない。 スポットコンサル（ビザスク等）・MENTA/技術顧問は単価の高い入口だが、有料noteの販売実績が立ってから着手する（「絞る」＝今期はCW1本＋Nompass）。

---

戦略メモ（2026-06-30 確認）

• ドッグフーディング（自社＝Nompass最初の顧客）：賛成。Traceは登録して使う（被りなし・分析は普遍的に有用）。VoiceはNompass運用に限定し、Miyokiブログはmiyoki-media-pipelineのまま（二重化回避）。
• Voice × media-pipeline 統合は「Nompass個人用サービス展開」のタイミングでやる（今は統合しない＝手を広げない）。
• 既存制作物をNompass機能モジュールへ転用：RAG→ナレッジ応答／提案文→営業支援／執筆補助・pipeline→Voice強化／teleapo→電話・SMS応対。これらはMiyoki実績かつNompass強化の両取り（「自作を自社プロダクトに組み込んだ」が実績として一段強い）。

---

整理タスク（無計画の温床を畳む）

アーカイブ確定（Web/LP一本化に伴う）

2026-06-30 実行済み：C:\Miyoki\_reference\_archive\ へ移動（削除ではない＝元に戻せる）。

• [x] C:\dev\HP → C:\Miyoki\_reference\_archive\HP
• [x] C:\dev\hp-test → C:\Miyoki\_reference\_archive\hp-test
• [x] C:\dev\hp-builder → C:\Miyoki\_reference\_archive\hp-builder
• [ ] C:\Miyoki\_reference\hp-builder-test\miyoki-portfolio … 新ポートフォリオ完成後にアーカイブ（それまで参考保持）

アーカイブ（趣味・実験系）

2026-06-30 実行済み：C:\Miyoki\_reference\_archive\ へ移動。

• [x] Creator-Catalyst / music-vibe-app / money-app / Claude Code Tutorial
• ※ 残す：counter-app（公開済み実績）／Horse Racing Analysis・character-profile-book-app（本人希望で保持）。

---

直近アクション（21時〜＋土日で回す順）

1. ポートフォリオMVP着手（buildコピー→ポートフォリオ用に減算改造）。
2. 実績5件の/works原稿（課題→作ったもの→AIの使いどころ→技術→結果）。
3. 公開前チェック（OGP/構造化データ/画像WebP/404/フェイルセーフ）→公開。
4. 公開プロセスをnote/Zennに記事化（発信ネタ＝制作物）。
5. 並行：pipelineのサイト別プロファイル実装→ブログ1本目。
6. アーカイブ実行（HP系3つ）。

---

進捗（このセッション）

• ✅ 現状把握 → プロジェクト棚卸し
• ✅ 04_ポートフォリオ計画 / 05_コンテンツ計画 / ロードマップ 作成
• ✅ 03_収益化 更新（Web/LP一本化）
• ⬜ ポートフォリオMVP着手（次セッション）

プロジェクト棚卸し（現状把握）

作成: 2026-06-30 / 全プロジェクト横断の完成度・稼働/停滞・収益化可否を1枚に。 方針反映: Web/LP制作はNompassに一本化（Miyoki個人受託は「AI業務自動化・ツール開発」1本）。

---

P1：受託の実績になるもの（AI業務自動化・ツール開発）

---

P2：ストックの要

---

P1並走：Nompass（別事業・Web/LPの一本化先）

Web/LP制作はすべてここに集約。Miyoki個人では受けない（送客のみ）。

---

ポートフォリオ

---

アーカイブ確定（Web/LP一本化に伴い役目終了）

✅ 移動済み（2026-07-04）：すべて C:\Miyoki\_reference\_archive\ に収容。

---

アーカイブ候補（趣味・実験系／roadmap送り）

以下は受託訴求が弱い。_reference\_archive\ に収容済み（counter-appは公開済みのため除外＝個人\ に現役で残す）。

• Creator-Catalyst
• character-profile-book-app
• music-vibe-app
• money-app
• Horse Racing Analysis
• Claude Code Tutorial（学習用）

---

P3：温存（後回し・受託化できれば前倒し）

• SDC：C:\Miyoki\個人\RAG（改修予定）/ C:\Miyoki\個人\teleapo-demo（SMS/テレアポ自動化）。引越サイトはNompassへ。
• 家：父=建設業の業務効率化 / 母=経営コンサル向け（小さく実用から）。
• 個人（次の柱）：税理士向けAI活用コンサル、業種特化マイクロSaaS。

構築予定（新規開発パイプライン・要件検討中 2026-07）

すべて要件検討中。漏れが出たら同粒度で追記。詳細は ロードマップ「構築予定」。 需要検証の進捗（2026-07-08時点）：全項目まだ実装未着手。父/母はヒアリング前、税理士候補は接触前。進捗は需要ヒアリングログで追う。

共通で先に固めるべき技術要素：Embeddings+ベクトルDB（RAG系譜2件で共有）／マルチテナント設計（税理士chatbot・SaaS構想で共通）／認証・課金基盤（counter-appから横展開可）

Miyoki 全体計画（目次・地図）

Miyoki個人（Miyoki ⊃ Nompass）の全体計画のマスター。ここから全ドキュメント・プロジェクトに1階層で到達できる。 横断の現在地・整合ルールは 現在地.md（ハブ）。このファイルは「地図」に徹する。

---

計画ドキュメント（計画\ 配下）

---

フォルダ構成（2026-07-04 再編後）

C:\Miyoki\
├── 計画\            … 横断計画・SSOT（上の表＋プロジェクト別\＋引き継ぎ\）
├── 個人\            … Nompass以外の現役実装9件
│     miyoki-portfolio / miyoki-blog / reply-draft-assistant /
│     miyoki-media-pipeline / proposal-generator / Writing-Assistant /
│     counter-app / RAG / teleapo-demo
├── Nompass\         … 本体事業（別事業・子）。Nompass Build\（運用衛星）を内包
├── 下書き\          … 投稿前ドラフト（Miyoki-Labs\ / Nompass\ × 媒体）
├── ideas\           … 記事ネタ蓄積（seeds-*）＋シリーズ\＋公開台帳＋週次自動収集
├── voice-kit\       … 発信の司令塔（文体・テンプレ・ワークフロー）
├── output\          … 公開済み成果物・アセット（アカウント設定/バナー画像/ブランド画像）
├── _reference\      … 塩漬け（参照専用・原則触らない）
└── .claude\         … ワークスペース指示・hooks・汎用スキル（品質チェック/UXレビュー/整合チェック/self-post発信）

---

プロジェクト別計画（ロールアップ）

各1枚＝目的/現在地/次の一手。詳細は各実装フォルダの docs/CLAUDE.md へ。

---

運用の入口

• セッション開始 → 現在地.md（ハブ）を読む → 整合性プロトコルに従う
• 記事ネタ → ideas\seeds-miyoki.md / seeds-nompass.md（週次自動収集＝金曜22時）。シリーズ束ね＝ideas\シリーズ\、公開実績＝ideas\公開台帳.md
• 発信の文体・手順 → voice-kit\
• 優先順位に迷ったら → ロードマップ.md

関連

• Nompass本体: C:\Miyoki\Nompass（別事業。実装状況の正=Nompass\STATUS.md）
• Nompass LP: C:\Miyoki\Nompass\Nompass Build\00.Nompass\client-Nompass-hp
• Buildテンプレ: C:\Miyoki\Nompass\build

01 ビジョン・目的・価値観（下書き／要補正）

既知のプロフィール＋これまでの会話からの叩き台。要確認 はMiyokiが補正。

現状

• 現職はエンジニア職ではないが、個人でWeb／AIアプリを開発している。
• すでに「Nompass」という事業（小規模事業者向けWeb×AI支援）を自力で立ち上げ中＝企画から制作・運用・事業化まで一人で回せる実績がある。
• 発信：X / note / Zenn / Qiita を想定。

目的（ゴール）

• AIエンジニア・データアナリストとして独立、または転職する。
• AIを武器に、個人で稼げる・作れる状態を確立する。
• 作ったもの・学んだことを言語化して発信し、それ自体を資産（信頼・集客・収益）に変える。

期間の目安（要確認）

• 〜1年：受託/スキル販売で最速の収益化。ポートフォリオ＝営業資料を完成。
• 〜2-3年：ストック資産（ブログ/アフィリ/プロダクト）と本業（独立 or 希望条件での転職）。

価値観・スタンス

• AI活用で「やりたくない作業を仕組みで回す」（Nompassの思想と一致。自分自身にも適用）。
• 誠実・煽らない。誇張より「体験・判断の経緯・失敗」で語る。
• 完璧より「まず動かして回しながら上げる」。
• 続かないことは無理にやらない＝低負荷の仕組み（自動化）で継続する。

「なぜやるか」（要確認）

• 会社・場所に依存せず、自分のスキルで食べていける自由がほしい。
• 同じく独学・キャリアチェンジを目指す人の役に立ちたい（発信の動機）。

未確定・要決定リスト

• 最終的に「独立」か「転職」か、どちらを主軸にするか（両立期間の置き方）。

→独立

• 「AIエンジニア」と「データアナリスト」のどちらを前面に出すか（両方なら見せ方）。

→AIエンジニア寄り、プロダクトマネージャーのような立ち位置

• 1年後の具体的な収益目標（数字）。

→Nompassとは別で月に30万は確保して、独立へのブーストにしたい

02 ポジショニング・差別化・ターゲット（下書き／要補正）

ひとことで言うと（要確認）

「AIを使って、個人で“作って・売って・運用まで”できる人」

制作だけの人でも、分析だけの人でもなく、企画→制作→運用→事業化を一人で通せるのが核。 その証明が Nompass（自分で立ち上げた実事業）。

差別化ポイント

• 一気通貫：Web制作・AIアプリ・データ分析・発信・事業設計を横断できる。
• AI活用の実践知：「AIで何をどこまで任せ、どこを人が握るか」を実例で語れる（Nompass＝AIが主役の運用設計）。
• 事業を自分で作った当事者：理論ではなく、収益・撤退ラインまで考えた実体験。
• 誠実な発信：失敗・判断の経緯まで出す（差がつきにくい技術記事より信頼が積む）。

ターゲット読者・顧客

• A. 同じ立場の人：独学・キャリアチェンジでAIエンジニア/データアナリストを目指す人（noteの主読者）。
• B. 技術で調べている人：同じ実装・同じハマりを踏む開発者（Zenn/Qiitaの読者）。
• C. 仕事の依頼者：Web/AI制作を頼みたい個人事業主・小規模事業者（ポートフォリオ→受託、Nompassとも連動）。

見せ方の方針

• ポートフォリオ＝実績（作ったもの）で信頼を作り、受託/相談につなげる入口。
• 発信＝体験・判断・失敗ベース（Miyoki文体：カジュアル・等身大）。
• NompassとMiyokiは別ブランドだが相互リンクで人柄・信頼を補強。

要確認

• 「AIエンジニア」寄りか「データアナリスト」寄りか、もしくは「AIで事業を作れる人」という独自枠で立つか。

→AIエンジニア寄りのプロダクトマネージャーの方向、Nompassがしっかり立てばAIで事業を作れる人になれるようにも感じてる

• 名乗り（肩書き）をどう置くか（例：AIエンジニア／個人開発者／"作れる人"）。

→違和感なく名乗れる一番強く聞こえるものにしたい →確定: 「AIプロダクトエンジニア」（企画→制作→運用までAIでプロダクトを形にする。Nompassが軌道に乗れば「AIで事業をつくるエンジニア」へ昇格）

---

Miyoki人格キャノン（正・全整合の基準）

名乗り・ブランド・媒体分担・ドメインの唯一の正。他ドキュメント（Nompass側含む）はここを参照し、再定義しない。矛盾を見つけたらここに合わせる。一次ソースの経緯は下の「一次ソース」。

• 人物 / 親ブランド: Miyoki（みよき）。Miyoki ⊃ Nompass（Nompassは内包する別事業）。
• エンジニア発信の屋号: Miyoki Labs（🔬）。旧Music系（Miyoki_Music 等）とは分離。
• 名乗り（肩書き）: AIプロダクトエンジニア（企画→制作→運用までAIでプロダクトを形にする）。Nompassが軌道に乗れば「AIで事業をつくるエンジニア」へ昇格。
• ハンドル統一（小文字）: X / note / Zenn / Qiita = miyoki_labs、GitHub = miyoki-labs（_不可）、表示名 = Miyoki Labs。合言葉「@miyoki_labs で探して」。
• ドメイン: miyoki-labs.com（ポートフォリオ = apex ／ ブログ = blog.miyoki-labs.com）。
• 媒体分担（＝無料発信をどこに置くかのルール）:
• 技術の中身（開発ログ = Zenn ／ 技術解説 = Qiita）＝ 🔬 Miyoki Labs
• ビジョン・生き方 = note ／ 拡散・告知 = X
• アフィリ（AIツールレビュー）＝ Miyokiブログ（blog.miyoki-labs.com・独立メディア）
• 成果・事例（Before/After・LP効果）＝ 🏢 Nompass（公式note／LP）
• 媒体分担の例外：有料コンテンツ（ストック商品）は対象外（2026-07-08追加）:
• 上の媒体分担は「無料発信の置き場」を決めるもので、商品の販売チャネルは決めない。器は「売れる場所」で選ぶ＝現状 note（正=03_収益化.md②-b）。
• よって note の有料記事は技術内容を含んでよい（例：hook設計テンプレ一式）。noteの無料発信は従来どおり「ビジョン・生き方」のまま変えない。
• 無料↔有料の線引き（L1/L2/L3・判定テスト）＝ideas\_knowledge-log-rule.md。
• 一次ソース: ブランド統一の経緯 = 引き継ぎ/2026-07-01_ブランド統一と記事カード.md ＋ メモリ miyoki-labs-branding／媒体方針 = 05_コンテンツ計画.md／ブログ設計・アカウント方針 = 06_ブログ計画.md。

03 収益化戦略（下書き／要補正）

方針：「最速の現金収入」と「時間がかかるストック」を二段構えで。 SNS/ブログが続かない不安は「自動化ツール」で負荷を下げて解消する。

収益の柱（優先順）

① 最速ルート：受託・スキル販売（現金化が速い）

• 既存スキル＋Nompass／ポートフォリオが営業資料になる。実績があるので説得力が出る。
• 例：Web/LP制作、AIアプリ開発、データ分析・可視化、AI導入支援、スポット相談。
• 入口：ポートフォリオサイト（実績見せ）→ 問い合わせ／クラウドソーシング／紹介。
• これを当面の主軸にするのが現実的（アフィリより速い）。

② ストック資産：アフィリエイトブログ＋自動化ツール（時間はかかる）

• 並行で仕込む。収益化まで時間がかかる前提で、自動化ツールで継続コストを下げるのが肝。
• Miyoki側（アフィリ/学習者向け）と Nompass側（リード/AEO）でサイト別プロファイルを1ツールで両対応。
• 動画は挫折済み→テキスト（ブログ）に資源集中。

②-b 有料コンテンツ（有料note・2026-07-08追加）

蓄積した知見に値札を付ける。器＝note有料記事（Zenn有料Book・BOOTH・KDP等は当面採らない＝手を広げない）。

• 無料↔有料の線引き：理解は売らない。再現を売る（L1/L2/L3の3層＋判定テスト）。規約の正＝ideas\_knowledge-log-rule.md／消化順＝ideas\記事キュー.md。
• 有料の単位＝「最初から最後まで動くワークフロー1つ」。無料記事N本を束ね、テンプレ・設定ファイル実物・チェックリストを足す。無料記事がそのまま有料noteの目次になる。
• 価格：980円スタート → 販売実績が出たら1,480円（noteは公開後に価格変更可）。実用系ノウハウは500円以下に落とすと専門性が伝わらない。
• 前提：無料リレーが3〜4本回ってから1本目（読者ゼロで有料を出さない）。noteの本人確認・振込設定だけ先に済ませる。
• 手数料：決済（カード5%）→ 残額にプラットフォーム利用料10% → 振込手数料270円/回。980円カード決済なら手取り約838円。※「1,000円売って手取り585円」という記述が散見されるが、あれは1本ごとに振込手数料270円を引いた計算。まとめて振り込めば実質85%前後。

KPIは売上額ではなく「販売実績が立ったか」。 ストックで月30万は1〜2年スパン（参考：Zenn有料本の実測例で500円×88冊/年＝年約5万円）。 有料noteの本当の役割は現金ではなく受託の信用装置＝「自分の知見に値札を付け、他人が金を払った」という第三者検証済みの証拠。 無料記事100本より、有料1本×30部の方がCWの提案文とポートフォリオで効く。だから①を食わない範囲で回す。

③ Nompass：月額継続収益（別事業）

• 別ブランドだが、Miyokiの「AIで事業を作れる」実績の中核証明にもなる。

役割分担（サイト別）

Nompass と Miyoki受託の切り分け（Web/LP一本化）

確定（2026-06-30 更新）：Web/LP制作はすべてNompassに一本化する。 Miyoki個人では受けない（送客のみ）。 理由：ブランドが明確になり迷いが消える／build（量産テンプレ）の資産・継続収益が活きて速い／Miyokiは「AI開発」に集中できる。

• Web・HP・LP制作（業種・規模問わず） → Nompassで受ける（build流用・料金・継続収益・実績が活きる）。
• AI業務自動化・ツール開発（AIアプリ・RAG・自動化・ツール・AI導入相談等） → Miyoki個人受託（ポートフォリオ実績と直結。受託の主力1本に集中）。
• お金の見方：月30万（独立ブースト）は Miyoki受託＋ストックで測る。ただしNompassの利益も独立資金に合算してよい（無理に除外しない）。
• メリット：ブランド明確・自由度高・目標管理が綺麗。実績/営業資料が2分散しない（Miyoki＝AI、Nompass＝Web）。

注意・前提

• アフィリは「継続×時間」が前提。「投稿が好きじゃない＋最速収益化」とは噛み合わないので、最速は①、アフィリは②として割り切る。
• 無理に全チャネルをやらない。低負荷の1〜2個に絞る＋自動化。

要確認

• 当面の月次目標金額／受託に割ける時間。

→Nompassとは対応時間を分けないと常に追われるから、平日21時以降からの2時間程度。（またはNompassの対応時間である12：00-18：00で受託も受けるも選択肢） （確定）平日9-18は通勤込みで8時前〜19時過ぎ拘束＝実質不可。確保できるのは「平日夜21時〜＋土日」のみ。可処分時間が少ないので、受託は“少数・高単価・短納期化（テンプレ/AI活用）”に振る。

• 受託の主力メニュー（何を売るか）を1〜2個に絞る。

→個人開発がメイン。webやアプリを開発してほしい。またはAIを導入してほしいという相談。 →現状はRAGの作成や提案文ジェネレーター、執筆補助ツールやカウンターアプリを作成済み。

• RAG構築（改修予定）: C:\Miyoki\個人\RAG\
• Nompass: C:\Miyoki\Nompass\
• Nompass LP: C:\Miyoki\Nompass\Nompass Build\00.Nompass\
• 提案文ジェネレーター: C:\Miyoki\個人\proposal-generator\
• 執筆補助ツール: C:\Miyoki\個人\Writing-Assistant\
• カウンターアプリ: C:\Miyoki\個人\counter-app\
• 執筆自動化ツール（開発中）: C:\Miyoki\個人\miyoki-media-pipeline\

→また、Miyokiとして取り組もうとしているのが以下 Nompass — HP/LP制作、SNS投稿サポート、数値分析 ストック — ブログ/Zenn/note/Xの半自動化、画像生成レシピ販売 SDC — 引越サイト作成、RAG、SMS自動化 家 — 父(建設業の業務効率化)・母(経営コンサルタント)向け 個人 — 税理士向けAI活用コンサル、業種特化マイクロSaaS、提案文ジェネレーター

• アフィリのジャンル（何のブログにするか）。

→現状はAI全般だが、ポートフォリオの兼ね合いも考えるとまずは学習者向けのブログ（おすすめツールやPros consなど）が良いか。

04 ポートフォリオサイト構成・技術・ページ設計

名乗り＝AIプロダクトエンジニア（企画→制作→運用までAIでプロダクトを形にする）。 目的＝AI開発の実績を見せて受託リードを取る入口。Web/LPはNompassに送客（このサイトでは売らない）。 思想：Nompass LP同様「先に固めてから作る」。C:\Miyoki\Nompass\build の学びを最大流用して速く・強く作る。

---

0. 結論（おすすめ構成）

Nompass build準拠でゼロから作り直す（既存 miyoki-portfolio scaffoldは参考のみ）。 理由：buildには画像最適化・OGP・SEO/AEO・常時CTA・ブランド404・初回真っ白フェイルセーフがルール化済みで、流用すれば最短で「弱くないサイト」が建つ。

---

1. 役割とゴール

• 主目的：AI開発の実績を見せ、問い合わせ（受託相談）につなげる。
• 副目的：Nompassへの送客（Web/LP案件はこちら、と明示）／発信(Zenn/note)への導線。
• KPI：問い合わせ数。月30万（独立ブースト）の入口として測る。

2. ターゲット（02準拠）

• C. 仕事の依頼者（最優先）：AIアプリ・RAG・業務自動化を頼みたい個人/小規模事業者・toB担当。
• B. 開発者（Zenn/Qiitaから流入）／A. 同じ立場の人（noteから流入）も拾うが、CV設計はCに最適化。

---

3. 技術構成（Nompass build流用）

必ず流用するルール（buildのCLAUDE.md / docs/04_launch.md より） - 画像は事前WebP化＋適正サイズ（Cloudflareでnext/imageが効かない。sharp変換）。 - layout.tsxにmetadataBase＋OGP（public/og.png 1200×630）＋Twitterカード。 - JsonLdで構造化データ（Person/WebSite/BreadcrumbList、実績はCreativeWork、記事はBlogPosting）。 - 全ページCTA（MobileFixedCTA）／ブランド404（not-found.tsx）／初回真っ白フェイルセーフ（__nbReveal 2.6秒）。 - lucide-react（絵文字禁止）／本文15px以上／コントラスト4.5:1。

---

4. ページ設計

トップ（/）— 1枚で「誰が・何を作れて・どう頼むか」

1. Hero：肩書き「AIプロダクトエンジニア」＋一言（企画→制作→運用までAIで形にする）＋CTA（相談する）。
2. 強み（一気通貫）：企画→制作→運用→事業化を一人で通せる（証明＝Nompass）。3〜4枚。
3. 実績ハイライト：下記5件をカード表示（→ /works）。
4. 提供できること（受託メニュー）：AI業務自動化・ツール開発の1本に集中（RAG構築/AIアプリ/業務自動化/AI導入相談）。Web/LPは「Nompassへ」と明示リンク。
5. 発信：Zenn/note/Qiita/Xへの導線（最新数件）。
6. CTA（問い合わせ）＋フッター。

実績（/works, /works/[id]）— サイトの主役

各実績ページの型（受託の「このまま御社にも」を言える見せ方）：

• 課題 → 作ったもの → AIの使いどころ（どこを任せ・どこを人が握ったか）→ 技術 → 結果/学び → 関連記事リンク。

掲載する実績（AI系に統一）：

Web制作実績は載せない。「Web/LPはNompassで」と送客リンクのみ。

プロフィール（/about）

• 02のポジショニング：制作だけ/分析だけでなく企画→運用まで通せる人。Nompass＝自分で立ち上げた実事業が証明。
• 誠実な発信スタンス（失敗・判断の経緯まで出す）。

受託メニュー（/services または トップ内セクション）

• AI業務自動化・ツール開発に集中。少数・高単価・短納期（テンプレ/AI活用）。
• 例：RAG構築、業務特化AIアプリ、提案文/執筆など定型業務の自動化、AI導入相談（スポット）。
• 進め方・想定納期・ざっくり料金感（実績ゼロ表現の景表法に注意＝モデルケース表記）。

ブログ ※05・06と連動

• 学習者向けAIツール紹介/Pros·cons。miyoki-media-pipelineで半自動運用。
• 現行方針：独立ブログ＝個人\miyoki-blog（Astro）。ポートフォリオ内 /blog + microCMS案は旧方針（正=06_ブログ計画.md）。ポートフォリオからはリンクで送客。

必須・補助ページ

• /contact（フォーム）＋ /thanks（noindex）
• /privacy（必須）／not-found.tsx（ブランド404）
• /links（リンク集・実装済み）：全媒体ハンドル @miyoki_labs を見せ場に。ヘッダーのドロップダウンと共通コンポーネント。

/contact（連絡導線・2026-07-03設計／実装は後追い）

背景：本人がメールをあまり開かないため、問い合わせを取りこぼさず通知を確実に受け取れる設計にする。現状の暫定は mailto: ＋アドレス表示だが、PCで既定メーラーが無いと開かず取りこぼす。

• フォーム：名前／連絡先／相談内容（＋希望連絡手段）。react-hook-form + zod + Honeypot ＋ Turnstile。
• 送信フロー：Cloudflare Pages Functions で受け、①Slack Incoming Webhook に通知（スマホで即気づく・将来の複数窓口を1chに集約）②Resend で記録用メール。完了 → /thanks（noindex）。
• 通知先＝Slack推奨（LINEでも可）。「トータルで通知を受け取る」目的に集約性で有利。
• 実装流用：reply-draft-assistant / Nompass voice の Functions パターン（APIキー・Webhook URLはサーバ側のみ、フロントに出さない）。
• ※ static export 構成でも Cloudflare Pages Functions（functions/）は共存可能。

---

5. 作る順番（時間が少ない前提＝絞る）

1. build をベースにポートフォリオ用へ最小改造（不要な業種テンプレ/CMS依存を削る減算式）。
2. トップ＋/works（実績5件）＋/contact＋/about＋/privacy まででまず公開（MVP）。
3. OGP/構造化データ/画像WebP/404/フェイルセーフを公開前チェック（docs/04_launch.md準拠）。
4. 公開後に /services 詳細・/blog・実績追記を回しながら強化。

MVPを先に出す（完璧待ちしない＝01の価値観）。実績は案件ごとに追加。

---

6. ブランド整理（Miyoki ↔ Nompass）

• 別ブランドだが相互リンク（人柄・信頼の補強、02準拠）。
• 役割分担を明示：AI開発＝Miyoki / Web・LP＝Nompass。迷わせない導線にする。

05 コンテンツ・発信計画

前提：投稿は得意じゃない＋最速収益化が主軸。だから自動化で負荷を下げて継続する（03準拠）。 ストックは「仕込み」。期待値を高くしすぎず、低負荷で回す。心臓部＝C:\Miyoki\個人\miyoki-media-pipeline。

---

0. 結論（おすすめ）

Miyokiブログ（学習者向けAIツール紹介/Pros·cons）を主戦場にして、miyoki-media-pipelineで半自動運用する。 Zenn/Qiita/noteはideas/seeds-miyoki.mdを起点にネタが出たときだけ書く（無理に量産しない）。Xは各記事の告知に絞る。

---

1. 媒体ごとの役割（グローバルCLAUDE.md準拠）

有料noteは媒体分担の例外（＝商品の販売チャネルであって、無料発信の置き場ではない）。技術内容を含んでよい。 正＝02_ポジショニング.md「媒体分担の例外」／収益設計＝03_収益化.md②-b／線引き（L1/L2/L3）＝ideas\_knowledge-log-rule.md。

---

1-2. 媒体の切り分け確定（2026-07-01）

エンジニア人格は Miyoki Labs に統一。Music系（旧 Miyoki_Music/miyoki_music）とは完全分離する。

• Zenn＝開発ログ・技術発信に一本化。アフィリのAIツールレビューはZennに載せない。
• 理由：Zennはエンジニアコミュニティで収益レビューは文化的に浮く。Zennで「AIプロダクトエンジニアの実装力・判断の中身」を見せることが独立・受託獲得の信頼に直結する。レビューを混ぜると「結局何屋？」になり入口価値が薄まる。
• AIツールレビュー（アフィリ）＝Miyokiブログ（自前メディア）専用。miyoki-media-pipeline の出力先はこっち。ZennやQiitaとは別媒体。
• miyoki-media-pipeline は現状サイト/媒体別プロファイルの差し替え不可（＝アフィリブログ専用の作り）。Zenn/Qiita/noteの発信には流用せず、軽い作成フロー（Writing-Assistant系）で書く。プロファイル対応は §4 の「やること」のまま据え置き。

アカウント・ハンドル確定（2026-07-01）

ブランド人格＝Miyoki Labs（屋号。counter-app で自称していた「Miyoki's Labs」を正式化）。全媒体を統一する（YouTube除く）。記事/リポジトリが少ない今のうちに347を捨てる。

• 命名規則：ハンドル/URLは小文字（miyoki_labs・GitHubのみmiyoki-labs）。大文字の見せ場は表示名 Miyoki Labs で全媒体統一。X/GitHub/Qiitaはハンドル大文字表示も可だがURL解決は小文字と同一なので小文字で揃える。
• Xはドット不可（英数字＋_のみ）。区切りは _。
• 要確認：Zenn/Qiita の miyoki_labs 空き（実行直前に再チェック）。QiitaのID変更可否。
• TODO（手動）：各媒体リネーム → GitHubはローカル git remote 張り替え → miyoki-portfolio/src/data/site.ts の全リンク差し替え。

Nompassブランドとのすり合わせ（2026-07-03 確定）

Nompass側の台帳と頭合わせ済み（正典：C:\Miyoki\Nompass\Nompass Build\00.Nompass\nompass-accounts.md の「媒体マップ」）。

• Zenn／Qiita は miyoki_labs 個人に一本化（この§の方針どおり）。Nompass専用アカは作らない。
• Nompass開発ログにブランドを乗せたい時は Zenn Publication／Qiita Organization「Nompass」（中の人＝miyoki_labs）に束ねる。＝アカウントは増やさず露出だけ足す。
• note は2本立て：miyoki_labs（ビジョン・生き方＝この計画の担当）／ Nompass公式note（事例・成果＝00.Nompass 側で新設）。読者もCTAも別物なので混ぜない。
• Nompass公式の新設面：note公式・Googleビジネス（MEO・無料）・Threads。Miyoki Labs 側の運用には影響なし（相互リンクで信頼補強のみ）。

---

2. Miyokiブログの方針（主戦場）

• ジャンル：学習者向けAIツール紹介／Pros·cons／使い分け（ポートフォリオの肩書きと整合）。
• 読者：独学・キャリアチェンジでAIを使い始める人（02のA）＋ツール選びで検索する人。
• 型（AEO意識・buildのブログ作法を流用）：
• タイトル冒頭に検索キーワード（28〜32字）。
• リード300字で「誰向け・何がわかるか」。
• 末尾にFAQ（AIに引用されやすい）。CTAは中盤と末尾。
• AI臭さ回避（誇張・「まとめると」・同語尾3連続を避ける／体験・理由ベース）。
• アフィリは「継続×時間」前提で割り切る。最速収益は受託、ブログは仕込み（03）。

---

3. Nompassブログの方針

• 事業リード・AEO狙い。少数エバーグリーン＋お客様の声(Voice)。
• 業種別の集客記事はbuildのblogEnabled業種ルールに従う（clinic/juku/fitness/agriculture/shigyou等）。
• Miyokiブログとは読者もCTAも別物（混ぜない）。

---

4. 自動化ツール連携（miyoki-media-pipeline）

一言でいうと：「キーワードから記事下書きまでを6ステップで生成するツール」。続かない発信を仕組みで回すための心臓部。

• 現状：6ステップ実装済み（Keywords→Research→Structure→Draft→Review→Export）＋Cloudflare functions。開発中。
• やること（仕上げの肝）＝サイト別プロファイル：
• 1ツールで Miyoki/Nompass を両対応。プロファイルで切り替える項目：
• トーン（Miyoki＝カジュアル等身大 / Nompass＝事業者向け信頼）
• キーワード戦略（Miyoki＝ツール比較 / Nompass＝業種×地域）
• CTA（Miyoki＝相談・記事内アフィリ / Nompass＝無料診断）
• 出力先（Miyokiブログ現行=Astro＝mdファイル。Nompass側はmicroCMS＝見出しにマークダウン記法を使わないbuildルール）。
• 連載化：開発過程自体がZennネタ（seedsの「ブログ自動化ツール開発（進行中）」）。

---

4-2. 発信ツールの全体設計（2026-07-02 確定・運用統合）

pipeline と voice-kit は統合せず役割分担（形態・コスト・処理粒度が違うため）。ただし運用フローは1本に束ねる。

• ネタ源（共通）＝ ideas/seeds-miyoki.md（knowledge-log から集約）。全発信の唯一の入口。
• Miyoki版 voice-kit（C:\Miyoki\voice-kit）＝発信の司令塔。Zenn/Qiita/note/X を多媒体展開。普段の発信はここで完結。
• pipeline ＝ アフィリブログの深掘り専任。外部キーワード（検索需要）起点＋ seeds-miyoki を「実践パート」として結合（体験入りで差別化・E-E-A-T強化）。深掘り記事が要る時だけ呼ぶ。

ネタは2系統（X がハブで束ねる）：

• 収益系：外部KW → pipeline → アフィリブログ → X告知
• 発信系：seeds-miyoki → voice-kit → Zenn/Qiita/note → X告知

§4の「サイト別プロファイル」は pipeline内のアフィリ複数サイト用に限定（Nompass発信は 00.Nompass/voice-kit が別途担う）。 将来構想：pipeline＋voice-kit を統合したAIライティングSaaS（roadmap 構築予定・温存）。

---

5. 運用リズム（低負荷で続ける・2026-07-08更新）

フェーズ設計の正＝計画\投稿フェーズ戦略.md（P0立ち上げ→P1定着→P2拡大でペース・内容を変える。曜日/時刻の実データは各posting-calendar、頻度背景はメモリ posting-cadence-2026-07-08）。以下は現状（平常運転）のリズム。

前提が変わった：ideas/seeds-miyoki.mdへの集約に加え、毎日21時にクラウドルーチンが🔬🏢両レーン分の下書きを自動生成（個人\miyoki-post-deckが取り込み）。生成の供給は週次時代よりかなり増えたが、出す頻度まで供給に合わせて増やすとは限らない（noteは事実・景表法の確認が必須＝人間のレビュー速度がボトルネック）。2026-07-08時点はZenn/Qiita/noteの頻度は現状維持のまま様子見し、空いている枠だけXで供給を活用する方針。

• 週次：pipelineでMiyokiブログ1本を半自動生成→手直し→公開（土曜21時〜の枠で完結を狙う）。
• 週次：Zenn（火7-8時）／Qiita（木7-8時）／note（日21時）を自動生成ドラフトから選んで公開（詳細スケジュール=個人\miyoki-post-deck\generate.mjsのschedule定義）。
• 週2（余剰活用）：X単独投稿（水・金 8:00）＝記事に紐付かない小ネタを自動生成の余剰から。
• 随時：作業で詰まり/学びが出たらideas/seeds-miyoki.mdに1行追加（ネタ切れ防止。とはいえ現状は自動生成が上回っており枯渇リスクは低い）。
• 都度：記事公開時にXで告知（1投稿目は「問い」か「意外な事実」、3〜5スレッド）。
• 見直しトリガー：1〜2週間運用してレビュー負荷・反応を見てから、Zenn/Qiita週2化などの頻度増を再検討する（2026-07-08時点は保留）。

やらないことを決める：動画はやらない（挫折済み）。全チャネル同時運用もしない。ブログ＋告知に集中。

---

6. 最初の一歩（seeds起点）

ideas/seeds-miyoki.md にネタあり。最速で出せるのは実作業由来のZennネタ：

• 「Cloudflare Pagesでnext/imageが効かない問題と対策」（実測値つき・刺さる）
• 「実績ゼロのLPで実績をどう見せるか（景表法）」（note向け・駆け出しに刺さる）
• pipeline開発ログ（連載の入口）

ポートフォリオ公開 → そのプロセスをnote/Zennに書く、が一石二鳥（発信ネタ＝制作物）。

06 Miyokiブログ設計プラン（アフィリ・独立メディア）

作成: 2026-07-03 / 05_コンテンツ計画.md の「Miyokiブログ＝アフィリ専用の自前メディア」を実装レベルに落とす。 前提：主戦場＝アフィリ（ストック収益の箱）。収益源は PV × 滞在 × 信頼。だから「回遊・発見・E-E-A-T」を最初から仕込む。 心臓部（記事生成）＝ C:\Miyoki\個人\miyoki-media-pipeline（出力＝フロントマター付きMarkdown）。この箱はその出力先。

【更新 2026-07-03】箱の実装方針を確定・変更。以下の旧記述は次の通り読み替える（本文は履歴として残す）： - 箱＝Astro で新規構築（Content Collections / Tailwind v4 / MDX）。microCMS は不採用。build流用もしない。 理由：pipeline の実出力は Markdown フロントマターで、Astro Content Collections が"そのまま食える"。microCMS前提は実態と不一致だった。 - 記事投入＝pipelineの .md を src/content/blog/ に直接置く（API変換不要）。 - ドメイン＝miyoki-labs.com（ハイフン有）に統一（人格キャノン 02 に合わせる。旧 miyokilabs.com は誤記）。 - 実装は C:\Miyoki\個人\miyoki-blog。§3のmicroCMSスキーマは src/content.config.ts の Zod スキーマに置換済み。 - MVP◎必須（タグ/関連/TOC/著者schema/ページネーション/CTA差替/アフィリUI/slug）は Phase 1 で実装・動作確認済み。

---

0. 確定事項（このセッションで合意）

• 箱の作り方：~~Nompass build の blog を流用して減算改造 → 新規microCMS~~ → Astro で新規構築（Content Collections）→ Cloudflare Pages。【更新で変更・上部バナー参照】
• 理由：pipeline の .md フロントマターを直接投入でき、表示も最速（SEO有利）。SEO/AEO・OGP・構造化データは Astro 側で再現済み（build作法を仕様書として流用）。
• ドメイン：Cloudflare Registrar で .com 取得（原価・年$10前後）。ポートフォリオとルート共有。

`` miyoki-labs.com → ポートフォリオ（既存・受託リード） blog.miyoki-labs.com → Miyokiブログ（新・アフィリ／別Cloudflare Pagesプロジェクト） ``

• サブドメイン分離で「発信系と収益系は別媒体・混ぜない」（05）を守りつつブランド（Miyoki Labs）は統一。
• MVPは「◎必須」だけ入れる。○△は箱が立って記事が数本たまってから追加（＝絞る）。

---

1. buildのblogが「今」持っているもの（流用価値）

• 記事一覧（カード・アイキャッチ・日付・カテゴリ・抜粋）／記事詳細（ヒーロー画像・本文）
• 構造化データ：BlogPosting schema、本文からFAQ自動抽出→FAQPage schema
• パンくず（UI）、canonical、OGP、ISR（revalidate 3600）
• microCMS連携（news エンドポイントを section でお知らせ/ブログに論理分割）
• 記事末CTA（ただし HP誘導固定＝「サービスを見る」）

---

2. ギャップ洗い出し（独立メディア＝はてブ型に足りないもの）

buildのblogは「HP付随の読み物」なので、回遊・発見・収益・E-E-A-T が抜けている。目的（アフィリ）で優先度を振る。

◎必須（これが無いとアフィリ箱として機能しない）＝MVPスコープ

○欲しい（回遊・継続を底上げ・第2弾）

• サイドバー（人気記事・カテゴリ・プロフィール・検索）＝はてブ型2カラム
• シェアボタン（X／はてブ／コピー）
• RSSフィード（購読・他媒体連携）
• メルマガ／購読フォーム（リスト化＝アフィリの資産）
• 前後記事ナビ、読了時間表示

△後回し（無くても回る）

• サイト内検索（初期はタグで代替可）／コメント欄／月別アーカイブ

---

3. microCMS スキーマ拡張（MVPの前提）

現状の News 型は title / body / category / section / eyecatch のみ。以下を追加する。

pipeline 側の出力も上記フィールドに合わせて調整（05 §4 サイト別プロファイルの一部として）。

---

4. build（HP主役ブログ）へのバックポート候補

MiyokiブログのMVPで実装 → 次に build を触るタイミングで厳選バックポート。build は量産テンプレ＝軽さが命なので、SEO/AEO・信頼に効く低コストなものだけ。

足す価値あり

足さない（アフィリ専用・テンプレを重くする）

• 記事内アフィリUI（商品カード・rel="sponsored"）／人気ランキング／サイト内検索／メルマガ／サイドバー2カラム

切り分け：build は Nompass本体の資産（別事業）。バックポートは「Miyokiブログ作業」とは別タスク。 Miyokiブログが「バックポート機能のテスト場」を兼ねる（一石二鳥）。

---

5. 構築ステップ（段階）

【更新で改訂】Astro構築に合わせて実態化。✅＝Phase 1完了分。

1. ✅ 箱の骨組み … C:\Miyoki\個人\miyoki-blog に Astro新規構築（Tailwind v4 / MDX / sitemap / RSS）
2. ✅ ◎必須の実装 … タグ／関連記事／TOC／著者schema／ページネーション／CTA差替／アフィリUI（商品カード・比較表・rel="sponsored nofollow"）／slug／OGP・BlogPosting・BreadcrumbList
3. ✅ ○の一部前倒し … シェアボタン・RSSは実装済み
4. ✅ 先行デプロイ … npx wrangler login（ブログ内で実行）→ npm run deploy で *.pages.dev に公開
5. ✅ ドメイン確保 … miyoki-labs.com 取得（2026-07-04・Cloudflare Registrar）→ blog.miyoki-labs.com を Pages に割当済み（DNS反映待ち）
6. pipeline接続（Phase 2） … pipelineの出力フロントマターを Zodスキーマに一致（metaDescription→description／publishedAt→pubDate／categoryをenum化／tags・author追加）→ .md を src/content/blog/ に直接投入
7. 1本目投入 … pipelineで生成 → .md を配置 → 公開
8. 第2弾 … サイドバー・メルマガ等を記事が溜まってから追加

---

6. 記事の標準構成（2026-07-06 確定＝リライト・新規生成の型）

全記事をこの型に統一する。pipeline生成・リライトモード・人力執筆すべて共通。正はここ（voice-kitはブログ管轄外）。

1. リード（H2の前・300字以内）：①定義や直接回答＋具体数値（AEO）→②具体的ターゲットの名指し（「〜していませんか？」の漠然呼びかけ禁止）→③この記事で得られるものを1文
2. 「この記事はこんな方におすすめ」：blockquote＋箇条書き3〜4点（自己選別の導線）
3. 結論先出しセクション：おすすめTop3や早見表を最初のH2で提示
4. 本文：比較表→深掘り→実体験（一次情報・証拠必須。[📸証拠：…]は公開前に実物へ差し替え）→状況別の選び方
5. FAQ：「Q：/A：」形式・Aの1文目で結論、補足は後続文
6. 出典・確認先セクション（必須）：料金・スペック等の外部数値は公式ページへのリンク一覧＋確認日を明記。実体験値は「筆者自身の契約・支払いで確認」と明示。AIリサーチ由来の数値は公開前に一次ソース照合必須（2026-07-07の誤り3件事故より）
7. まとめ：要点3つ＋状況別の結論表＋背中押し1文＋CTA
8. CTA配置：中盤（比較表直後）・実体験後・まとめの計2〜3箇所。アフィリは rel="sponsored nofollow"＋計測ビーコン
9. 表記ルール：太字**はCJKに密着させない（前後半角スペース）／対象KWのH2出現は2箇所以内（過剰=スパム判定リスク）／誇張語・「まとめると」締め禁止／日付・金額・体験は一次情報の範囲だけ（捏造禁止）

---

7. カテゴリ別の実体験の範囲（2026-07-09確認・記事生成前に必ず参照）

「日付・金額・体験は一次情報の範囲だけ（捏造禁止）」（§6）を、カテゴリ「オンラインスクール・教材」（online-school）に具体的に適用したメモ。

• 実際に受講経験があるのは SHIFT-AI・DMM の2つのみ。この2つは一次情報（実体験）として書ける。
• それ以外のスクール・教材は未経験。記事化する場合は「筆者自身の受講経験」と書かず、公式サイト等のソース情報ベースの比較であることを明示する（§6の「出典・確認先セクション」で出典を明記すればOK＝ソース情報だけの記事自体は問題ない）。
• 結果として、このカテゴリは実体験ベースの記事は本数が限られる（量産できない）。無理に本数を稼がず、比較・まとめ系（ソース情報の範囲）で補う。

---

付録：Cloudflare / GitHub アカウント方針（2026-07-03 決定）

現状

• Cloudflareアカウント Miyoki.43834@gmail.com（＝Miyoki個人の実メール）に Miyoki と Nompass が混在：
• Miyoki資産：miyoki-portfolio（Pages）
• Nompass資産：nompass.jp（DNSゾーン）／nompass-dashboard・nompass-lp・nompass-portal（Pages）
• GitHubは Miyoki個人アカウントに Nompassリポも同居（会社用Orgの費用を避けた経緯）。

決定：現アカウント＝Miyoki、Nompassは後で分離

• 現Cloudflareアカウント＝Miyokiとして継続（メール変更なし）。個人メールは親ブランドMiyokiに残すのが自然。
• 当初の「現アカ→Nompass、Miyoki新設」案は、個人アドレスが現アカのメール1つのため向きを反転（Miyokiが現アカを継ぎ、Nompassを新アカに出す）。
• miyoki-labs.com は現アカウント（=Miyoki）で取得。portfolio移設は不要（既に現アカに在る）。
• Nompass分離は後回し（案件が増えたタイミングで実施）。ブログ構築をブロックしない。

目標の最終形

• Miyoki＝個人GitHub ＋ 現Cloudflareアカウント（個人メール）
• Nompass＝専用Cloudflareアカウント（nompassメール）＋（必要なら）無料GitHub Org
• GitHub Organizationは無料枠あり（private/publicリポ無制限）。「会社用は有料」は誤解。将来の法人化/共同運営/譲渡時にリポ所有権をスパッと渡せる。

GitHub連携は分離後も継続できる

• wrangler CLIデプロイ（portfolio/build＝wrangler pages deploy）：デプロイ先は wrangler login で選ぶだけ。GitHubはソース置き場でデプロイに絡まない → アカウント分割の影響なし。
• CloudflareのGit連携（push→自動ビルド）：新Nompassアカウントで Cloudflare GitHub App を再認可するだけ。1つのGitHubアカウントを複数Cloudflareアカウントに繋げられる。

nompass.jp DNS の扱い

• 今：現アカに置いたまま放置でOK。miyoki-labs.com を別ゾーンとして同居させるだけで競合しない。
• 分離時の移設手順（.jp＝Cloudflare Registrar非対応＝外部レジストラ登録なので、ネームサーバー切替でラクに移せる）：
• 旧ゾーンのDNSレコードをエクスポート（BIND形式）
• 新Nompassアカウントに nompass.jp を追加 → レコードをインポート → 一致確認
• 新アカウントの割当ネームサーバーを、.jpレジストラ側で差し替え
• 反映確認後、旧アカウントからゾーン削除
• ⚠️ レコードは先に新アカに揃えてからネームサーバー切替（逆だと一時ダウン）。Pagesのカスタムドメイン再割当もセットで。

07 アカウント接続マップ（2ブランド横断・SSOT）

役割: Miyoki Labs（個人）⇄ Nompass（事業）のアカウント接続の正。横断ビューはここだけに置く。 各ブランドの詳細台帳（bio文・設定手順・env）はここに複製しない（下記ポインタが正）。ここは「網羅の要約＋どう繋ぐか」に絞る。 更新: 2026-07-03 ／ 人格・媒体分担の最上位の正 = 02_ポジショニング.md（Miyoki人格キャノン）。

---

詳細台帳の正（ポインタ・ここを複製しない）

---

網羅台帳（横断・要約）

発信・SNS

インフラ・所有基盤

---

接続の基本原則

繋ぐ目的＝相互の信頼補強。

• Miyoki Labs ← 「本物の事業(Nompass)を作って運営してる」＝"作って・売って・運用できる"の証明
• Nompass ← 「本物のAIエンジニアが作ってる」＝地元事業者への安心材料

ただし読者層が真逆（Nompass=足立区の非技術な事業者／Miyoki Labs=開発者・受託先・独学層）。全相互リンクは地元客を混乱させCTAを弱める。→ 方向性を持たせ、必要な所だけ繋ぐ。

---

接続マップ（どこ・向き・なぜ）

---

今すぐ効くアクション（順）

1. ✅ canonical URLを miyoki-labs.com に統一（ドメイン取得済み・2026-07-04。ポートフォリオ/ブログ/Nompass LPのコード内リンクは差し替え済み）。残作業：各SNS（X/Zenn/Qiita/note）のプロフィールbioリンクを手動で miyoki-labs.com に更新（voice-kitテンプレのCTAは差し替え済み）
2. ✅ Nompass LPの「制作・運営: Miyoki Labs」クレジット → 既に実装済み（client-Nompass-hp/src/app/page.tsx）。リンク先の古いpages.dev URLを本日修正
3. ポートフォリオ /works に Nompass をフラッグシップ事例
4. Zenn Publication／Qiita Org「Nompass」設定（別アカは作らない）

---

更新ルール

• 詳細は各台帳（上のポインタ）に書く。ここは横断の要約と接続方針だけ（薄く保つ）。
• ハンドル/ドメイン/媒体分担を変えたら 02_ポジショニング(人格キャノン) → ここ(07) → 各台帳 の順で整合を取る。

投稿フェーズ戦略（🔬Miyoki Labs ＋ 🏢Nompass・2026-07-09）

役割: フェーズごとに「ペース・内容・目標」を変える運用リズムの正。曜日/時刻の実データは 🔬voice-kit\03_posting_workflow.md／🏢00.Nompass\voice-kit\posting-calendar.md、頻度方針の背景は posting-cadence-2026-07-08。ここは"フェーズ設計"に絞る。 前提: 可処分時間＝平日21時〜＋土日。生成は毎日21時ルーチンで供給済み。律速はレビュー（事実確認・景表法）であって生成ではない。

---

0. 前提の補正（ここを外さない）

• 現行カレンダーの頻度は「初期値・平常運転」であって、最適と検証済みではない（両ファイルとも「実測で調整する」段階）。
• 2026-07-08の判断で Zenn/Qiita/事例note は"人間の確認"が律速だから、生成が増えても頻度は上げないとあえて絞っている。
• よって「立ち上げ＝毎日投稿で露出増」は正しいが、全媒体一律には適用しない。→ 露出はレビュー負荷が軽い面に集中させる（下記マトリクス）。
• 研究の裏取りでも一貫していた結論：「続けられる頻度」＞「一時的なバースト」／新規アカウントの最高ROIは"外向きの返信・コメント"（投稿だけではない）。

---

1. フェーズ定義（ステージ×マイルストーンのハイブリッド）

期間はあくまで目安。次フェーズへは"マイルストーン達成"で進む（期間が来ても未達なら留まる）。

内容の重心もフェーズで変える：

• P0＝自己紹介・なぜやるか・世界観・小ネタ連発（"人"を出す。過去資産ゼロなので量で点を打つ）
• P1＝失敗談/開発ログ/技術解説をシリーズ化（"線"にする・相互リンクで導線）
• P2＝成果/実績/Before-After/オファー（"面"にして収益へ）

---

2. 各フェーズのペース×内容×目標

★＝毎日いける面（レビュー軽・露出効く）／●＝品質ゲートで週次死守（誤情報・景表法リスク）

P0（立ち上げ）

P0の"毎日感"は X＋Threads＋MEO で作る。記事とIGは質を守って週1。外向き返信（1日20分・niche内の良コメント）を投稿と同格のタスクにする＝新規最高ROI。

P1（定着）

• Xは各1〜2/日を維持しつつリレー方式（ブログ→Zenn→Qiita→X告知）を毎週1本回す。
• 反応データでZenn/Qiita週2化をトリガー達成時のみ検討（律速＝レビューを超えない範囲で）。
• IG週1〜2、note週1、MEO週1〜2。

P2（拡大）

• 効いた媒体に時間を寄せ、効かない面は削る。事例・実績・オファー比率を上げる。
• 収益導線（有料note/受託/発注）を各投稿の着地に固定。

---

3. 媒体別ブリッツ可否マトリクス（なぜ日次を分けるか）

結論：日次の露出は◎の面（X・Threads）で作り、✕の面（記事）は質を守る。これが「立ち上げブリッツ」と「レビュー律速」を両立させる線。

---

4. 画像仕込み戦略（画像必須媒体のネック対策）

画像が要るのは主に Instagram/Threads画像・ブログOGP・たまのX画像。ここを詰まらせない設計：

1. 実素材優先（原則・02_image_prompt_guide）：🔬はスクショ/画面録画が最強＝実質コスト0。🏢は現場/商品の実写。→ 記事・機能紹介・MEOは画像を"作らない"で済む。
2. Canvaテンプレ方式（週末バッチの肝）：IG/OGP用にブランド固定の穴埋めテンプレを数種用意（背景・色・ロゴ固定、文言だけ差し替え）。週末に翌週分をまとめて量産すれば日次投稿を止めない。※Canvaはブランドテンプレ運用が可能（将来はテンプレ作成自体を自動化する余地）。
3. 露出面を画像不要に寄せる：P0の"毎日"はテキスト先行のX/Threadsで作る＝そもそも画像を必要としない設計にする。
4. 生成プロンプトは補助：実素材もテンプレも無い概念図だけChatGPT/画像AIプロンプト（型は02_image_prompt_guide）。
5. 週末仕込みの画像タスク化：土曜バッチに「翌週のIG/OGP画像◯枚をCanvaテンプレで作る」を1タスクとして固定（下記6章）。

まず決めること（週末）：IG用テンプレを2〜3種・OGP用1種作る。以後は差し替えるだけ＝画像がボトルネックでなくなる。

---

5. 投資（期間・労力）→ 見込める成果ケース

⚠️ 数字は約束ではなく目安。SNSの伸びは題材・運・外向きエンゲージ量で大きくブレる。ここは「どの労力でどの成果が"見込めるレンジか"」を持つための地図。 前提労力＝平日夜〜＋土日（＝重い毎日エンゲージは常時は張れない）。研究の"3-6ヶ月で1万"級は「毎日2-3h＋日次エンゲージ」前提の上限ケースで、この制約では基本は保守〜標準側に置く。

P0（立ち上げ・約4〜6週）

P1（定着・2〜3ヶ月）

P2（拡大・以降）

• 標準で「効いた媒体に寄せる」＝時間対効果が最大化。収益導線（有料note/受託/事例→発注）が動き始めるのはここが現実的ライン。

読み方：P0は"投資期間（延期リターン）"と割り切る。2週で判断せず、月次で分析・四半期で方針転換（研究の一致見解）。

---

6. 立ち上げの具体：この土日の仕込み＋7/13〜初週

今日=2026-07-09(水)。仕込み=7/12(土)・7/13(日)、投稿開始=7/13(日)〜。

土日の仕込みリスト（週末バッチ）

• [ ] X下書きを1週間分×2アカ（🔬🏢）＝毎日21時ルーチンの供給から選別・確認
• [ ] Threads分（Xから使い回し前提で微調整）
• [ ] Zenn or Qiita 週1本を1本仕上げ（記事キュー先頭から）＋X告知文
• [ ] note 週1本（🔬ビジョン or 🏢ノウハウ）
• [ ] IG 週1投稿の画像をCanvaテンプレで作成（テンプレ未作成ならまずテンプレ2〜3種を作るのが今週の最優先）
• [ ] MEO投稿1（実写）
• [ ] X/note/IGは純正予約をセットして閉じる（Zenn/Qiitaの平日朝公開だけ手動）
• [ ] Googleカレンダーに投稿日/予約セット日を登録（⑥ voice-kit\05_投稿効率化設計.md）

初週スケジュール雛形（7/13(日)〜7/19(土)）

毎日「投稿＋外向き返信20分」をセット。記事は週1死守。画像はテンプレ差し替えのみ。

---

7. 実測→次フェーズ移行トリガー（何を見るか）

• P0→P1：X各アカが投稿を切らさず反応が付き始める／刺さった型が1〜2特定できた。
• P1→P2：リレー導線が毎週回る／エンゲージ安定上昇／流入元・勝ち媒体が数字で見える。
• レビュー負荷が上限に来たら頻度を上げない（生成ではなく確認が律速、を判断軸に）。
• 分析は月次、方針転換は四半期。2週での早計な打ち切りをしない。

---

8. 継続可能性の担保（燃え尽き防止）

• "毎日"は続けられる面（X/Threads）だけ。記事を毎日にしない。
• 外向きエンゲージは1日20分で上限を切る（青天井にしない）。
• 供給は自動・確認だけ人間。確認が回らない週は頻度を下げてよい（頻度<信頼）。

---

9. 研究の出典 ＆ SSOTとの関係

• 出典（2026）: X頻度=Tweet Archivist／IG・Threads=Buffer・HeyOrca・SocialPilot／GBP=RichwoodMarketing・BrandHopper／新規90日=Drie Marketing・Heropost・Sprinklr。要点は本文に反映。
• SSOT関係: 曜日/時刻の実データは各posting-calendarが正・本ファイルはフェーズ設計の正。残作業＝05_コンテンツ計画(運用リズム節)と両posting-calendarに「フェーズ設計は本ファイル」ポインタを1行追加（→ /consistency-check）。

やることチェックリスト（Miyoki 手動・確認）

Miyokiさん側で確認/対応する項目をカテゴリ別に。実装（articles.ts など）は Claude 側で対応。 更新: 2026-07-01

---

現在地（次に再開する所）

直近の作業＝返信下書き支援ツールの初回起動（詳細は下記 E）。

• ツールは C:\Miyoki\個人\reply-draft-assistant（C:\dev から移動済み）。
• .dev.vars に ANTHROPIC_API_KEY 投入済み（Miyokiさん手動）。ターミナルコマンドでの再投入は不要。
• 次の一手：

``powershell cd C:\Miyoki\個人\reply-draft-assistant npm run dev `` → ブラウザで http://localhost:8788 を開く（※5173ではない）→「返信案を作る」で動作確認。

• 動いたら文体（functions/api/draft.ts の SYSTEM_PROMPT）を一緒に調整。

その他の残タスクは A〜E。

---

A. セキュリティ（Stripe）※完了 2026-07-04

• [x] Secret key をローテーション（sk_live_... を更新）
• [x] Webhook 署名シークレットを Roll（whsec_...）
• [x] Firebase Secret Manager登録＋firebase deploy --only functions（stripeWebhookデプロイ確認済み）

手順: 個人\counter-app\docs\Stripeキー_ローテーションと再開手順.md メモ: 課金は今オフのまま。再開する場合のみテスト決済で動作確認。

---

B. アカウントを Miyoki Labs に統一（リネーム）※完了 2026-07-02

共通: 表示名=Miyoki Labs／ハンドル小文字／アイコン=アバター／bio=手順書の文面 手順・文面: output/アカウント設定/2026-07-01-アカウント設定手順書.md

• [x] X: @miyoki_labs にリネーム＋表示名/bio/アイコン/ヘッダー（output/バナー画像/Xヘッダー.png）
• [x] note: ID miyoki_labs＋プロフィール＋カバー（output/バナー画像/noteカバー.png）
• [x] Zenn: miyoki_labs にリネーム
• [x] Qiita: miyoki_labs
• [x] GitHub: miyoki-labs にリネーム → ローカル git remote 張り替え → プロフィールREADME（output/アカウント設定/2026-07-01-github-profile-readme.md）
• [x] Claude側: articles.ts / site.ts 差し替え＋deploy 済み（ZENN_USER/QIITA_USER/NOTE_USER/各リンクともmiyoki_labsに反映確認済み）

---

C. 発信ロールアウト（受託の入口）

原稿: 下書き/Miyoki-Labs/Zenn/2026-07-01-ai-portfolio-cloudflare-pages.md（2本目: 下書き/Miyoki-Labs/Zenn/2026-07-01-cloudflare-next-image-optimize.md／X告知: 下書き/Miyoki-Labs/X/2026-07-01-x-thread-ポートフォリオ告知.md）

• [ ] Zenn 初投稿を公開（Zennリネーム後に published: true）
• [ ] X で告知スレッド（1投稿目は「問い」か「意外な事実」）
• [ ] 2本目Zenn（seedsから）→ note（ビジョン）→ Qiita（AEO）を順次

---

D. 事前確認（Claudeが確認できたものは結果を反映）

• [x] Zenn の miyoki_labs 空き … 空き確認済み（2026-07-01 / ページ無し）
• [x] Qiita の miyoki_labs 空き … 空き確認済み（2026-07-01 / 404）
• [x] Qiita の ID変更 … リネーム完了済み（Bと同時に解消）

---

E. 返信下書き支援ツール（C:\Miyoki\個人\reply-draft-assistant）

X/Zenn/note/Qiita のコメント返信をMiyoki文体で下書きする独立ツール（自動送信しない）。 構成: Vite+React+TS+Tailwind ／ Cloudflare Pages Functions ／ Claude Haiku 4.5＋構造化出力。

• [x] 実装・ビルド・型チェック通過
• [x] C:\dev → C:\Miyoki へ移動
• [x] dev起動の不具合修正（--proxy 5173 明示、開くのは 8788）＋UIのエラー表示を親切化
• [x] .dev.vars に ANTHROPIC_API_KEY 投入（Miyokiさん手動）
• [ ] npm run dev → http://localhost:8788 で動作確認（← 次はここ）
• [ ] 動作OKなら SYSTEM_PROMPT（functions/api/draft.ts）で文体調整
• [ ] （任意）本番化：Cloudflare Pagesに ANTHROPIC_API_KEY を設定して npm run deploy

ハマりどころ：5173(Vite)を開くとAPIが無くJSONエラー→必ず8788。Windowsでwmicのポート検出が失敗するため dev は --proxy 5173 指定済み。

---

参考：Claude側タスク（依頼待ち/先行実装）

• [x] 記事カード Phase1（Zenn/Qiita）実装・ビルド確認
• [x] note 記事カード Phase2（fetchNote）… コード実装済み（fast-xml-parser）。noteアカウント有効化後、次回deployで自動表示
• [ ] articles.ts / site.ts 差し替え … Bのリネーム完了後
• [ ] youtubeリンク削除の本番反映 … 次回 deploy 時（Bと同時が効率的）

需要ヒアリングログ

作成: 2026-07-08 「構築予定」（父用ツール／母用ツール／税理士向けRAG等）の需要検証で、父・母・税理士候補など"顧客想定の相手"から聞いたこと／伝えたことを蓄積する受け皿。 背景・全体方針は output\2026-07-03-需要検証と最初の一歩.md。着手条件は ロードマップ.md「SaaS構想」参照。

---

使い方（スマホ運用）

会話中〜直後にスマホのメモ帳／LINEキープ／音声メモへ一言だけ即メモ（整形不要）。 あとでそのメモをClaude（claude.aiアプリ/ブラウザでOK）に貼って話しかければ、その場で整形してこのログに追記する。

エントリ雛形

### YYYY-MM-DD｜相手（父/母/税理士候補/その他）
- 聞いたこと：
- 伝えたこと：
- 要件ヒント / 次のアクション：

流し先（溜めっぱなしにしない）

エントリが増えてきたら、都度ではなく次にそのプロジェクトを触るタイミング／週次の見直しのタイミングで以下に流す。新規の自動化は組まない。

• 実装計画へ：「要件ヒント」が具体化したら 計画\プロジェクト棚卸し.md の該当行（父用ツール／母用ツール等）を更新
• 発信へ：汎用性・具体性・物語性があるエントリは ideas\seeds-miyoki.md に★★以上として昇格（_knowledge-log-rule.mdの雛形・ネタ度基準に従う）

---

父（建設業）

2026-07-08｜父

• 聞いたこと：（未ヒアリング。次回の「最近時間取られてる作業ある？」で聞く）
• 伝えたこと：-
• 要件ヒント / 次のアクション：経費関連の効率化に見込みがありそう（見積・請求書まわりが候補。本人の見立てで、本人ヒアリング前の仮説）。次回の会話で裏取りする。

---

母（経営コンサル向け）

2026-07-08｜母

• 聞いたこと：すでにコンサル的な動き方を自分から進めている（詳細は次回具体化）
• 伝えたこと：その場で会話・アイデアを共有済み（内容は次回このログに追記）
• 要件ヒント / 次のアクション：母は父と違いすでに需要側の動きが先行しているため、ツール化より先に「今どこで困っているか」を次回の会話で具体的に聞き直す。

---

税理士候補（RAG系譜の需要検証）

アクセス方法一覧（X発信者接触／知人ネットワーク／無料相談窓口／資格不問コミュニティ／スポットコンサル）は ideas\seeds-miyoki.md「需要検証アクション化 由来」参照。

（まだ接触実績なし）

Nompass Build（薄い計画書）

• 目的：Nompass運用衛星。自社LP＋発信＋dashboard/ops。将来は顧客サイトの受け皿
• 実装：C:\Miyoki\Nompass\Nompass Build\（00.Nompass\＝自社。将来 01_/02_＝顧客）
• 運用の正：00.Nompass\CLAUDE.md／開発知見の母艦=00.Nompass\knowledge-log\history\core.md

現在地（2026-07-04）

• 00.Nompass 稼働（client-Nompass-hp / dashboard / ops / voice-kit / knowledge-log）

次の一手

1. 自社発信の継続（nompass-self-post スキル・seeds-nompass.md 起点）
2. 初顧客が決まったら 01_<顧客名> を開設（buildテンプレ流用）

Nompass（薄い計画書）

• 目的：別事業（子）。小規模事業者向けWeb制作×AI成長支援。Web/LP受託の一本化先
• 実装：C:\Miyoki\Nompass\（portal / build / map / voice / trace / docs …）
• 実装状況の正：Nompass\STATUS.md（このファイルでは要約しない）

現在地（2026-07-04）

• プロダクトほぼ完成・初顧客フェーズ。新規開発は抑制し獲得・運用に寄せる

次の一手

1. 初顧客獲得・運用（ロードマップ時間配分25%）
2. Miyoki側からは送客のみ（Web/LP案件は個人で受けない＝計画\03_収益化.md）

込み入った開発は Nompass\ 配下でセッションを立ち上げる（文脈ブレ防止）

RAG（薄い計画書）

• 目的：受託主力実績。「説明可能なRAG（根拠スタンプUI）」が差別化の核
• 実装：C:\Miyoki\個人\RAG\accounting-tax-rag-demo\（経理・税務デモ）

現在地（2026-07-04）

• 実装あり・稼働。改修予定（要件は未確定）

次の一手

1. 改修は要件確定後に見積（ロードマップγ。受託化できれば前倒し）
2. ポートフォリオ実績の主役として訴求維持（業種非依存で汎用）

記事ネタ：説明可能RAG・bi-gram検索まわりは ideas\シリーズ\AIプロダクト設計.md の主力

Writing-Assistant（薄い計画書）

• 目的：執筆補助ツール（ストリーミング/画像プロンプト/履歴）。受託実績
• 実装：C:\Miyoki\個人\Writing-Assistant\（React）

現在地（2026-07-04）

• 完成度高。稼働可

次の一手

1. ポートフォリオ実績ページに掲載（掲載済みなら維持のみ）
2. 作り込まない（デモ実績＝完成扱い。ロードマップの仕分け準拠）

counter-app（薄い計画書）

• 目的：公開済み実績（作り切る力の証明）。数値分析カウンター
• 実装：C:\Miyoki\個人\counter-app\（Firebase公開中＋Android対応）

現在地（2026-07-04）

• 公開中。現役で維持（アーカイブ対象外）

✅ P0（セキュリティ・完了 2026-07-04）

• git履歴に残存していた Stripe秘密鍵をローテーション済み（sk_live_.../whsec_...を再発行 → Firebase Secret Manager登録 → firebase deploy --only functionsでデプロイ確認）。

public化する場合は履歴クリーン化（git filter-repo）が別途必要。 手順の正：個人\counter-app\docs\Stripeキー_ローテーションと再開手順.md

次の一手

1. 完成扱い・実績掲載のみ（新規対応なし）

miyoki-blog（薄い計画書）

• 目的：アフィリ独立メディア＝ストック収益の箱（学習者向けAIツール紹介/Pros·cons）
• 実装：C:\Miyoki\個人\miyoki-blog\（Astro。旧build流用+microCMS案は履歴）
• 設計の正：計画\06_ブログ計画.md（記事の型=§6、出典セクション必須）

現在地（2026-07-07）

• 公開2記事（ドメイン更新料比較＝アフィリ7本稼働・ファクトチェック済み／ChatGPT×Claude比較＝実体験ベースでフルリライト公開）。公開実績の正=ideas\公開台帳.md
• 見た目改修 完了：正式ロゴ（透過版）ヘッダー/favicon／アイキャッチ「計測ラベル」自動生成（カテゴリ4色）／OGP PNGビルド時生成（sharp）／インタラクティブチェックリスト／著者ボックスロゴ
• A8.net 稼働中：エックスサーバー・お名前.com・ムームードメイン提携済み（素材の控え=knowledge-log 2026-07-06）
• デプロイ＝npm run deploy（og生成→build→--branch main）

次の一手

1. 証拠スクショ（任意・急がない）：①Claude Code開発画面 ②ChatGPT生成画像 ③Cloudflare $10.46請求画面。Claudeがブラウザ経由で代行可（②③はログイン済みブラウザで取得→マスキング→配置まで。①だけ本人の画面）。撮ったら output\ブランド画像\ 同様の証拠素材フォルダに貯めて使い回す（ルールの正=voice-kit 01・2026-07-07改訂＝出典リンク必須／スクショは推奨止まり）
2. 🖥️週末PC：3幅（375/768/1280）＋Lighthouseモバイル90+（CSS/画像生成が増えた後の実測）
3. 記事3本目以降：ideas\記事キュー.md（時系列消化）に従う ※リレー開始条件=ダッシュボード→自己紹介（ロードマップ実行キュー参照）
4. リライトモード／アイキャッチのpipeline連携は pipelineスキル化に同梱（正=プロジェクト別\miyoki-media-pipeline.md）
5. ASP第2弾：もしも=記事5本後／バリュコマ・afb=10本後（ラッコドメイン案件はバリュコマ圏）

記事ソース：ideas\記事キュー.md（消化順の正）＋ ideas\seeds-miyoki.md（ネタ台帳）＋ pipeline の外部KW起点

miyoki-media-pipeline（薄い計画書）

• 目的：ブログ半自動運用の心臓部（キーワード→記事下書きを6ステップ生成）
• 実装：C:\Miyoki\個人\miyoki-media-pipeline\（Cloudflare Functions）
• 設計の正：計画\05_コンテンツ計画.md §4

現在地（2026-07-05）

• 6ステップ実装済み。ブラウザ実機通しで初記事を公開済み（ドメイン更新料比較→ https://blog.miyoki-labs.com/blog/domain-koshinryo-hikaku ）
• 実機確認で直した不具合4件と残課題は knowledge-log/history/main.md 2026-07-05 が正
• ⚠️ 既知の課題：①審査スコアが70点前後に張り付き平均80ゲートが通らない → PASS_SCORE暫定70（採点再調整後に80へ戻す）。②Anthropic APIクレジット切れ（要チャージ）。③改善再生成が審査例文の架空データを本文に注入する捏造リスク → 改善後は一次情報の事実チェック必須

次の一手（ロードマップP4／β）

1. Claude Codeスキル化の設計・実装（Miyoki発案 2026-07-05）：生成・審査をClaude API課金からClaude Code（サブスク内）へ移す。Tavily→WebSearch代替、6ステップを /article-pipeline スキル手順化。使用量管理の悩みを解消。既存Web UIは編集用に残すか廃止かを設計時に判断
2. 投稿レイヤーも同時設計（Miyoki発案 2026-07-05）：Zenn=GitHub連携リポ（push=公開）／Qiita=qiita-cli or API／note・X=生成まで自動・投稿は手動。転載でなく媒体別書き分け（/self-post の出力）を投稿に繋ぐ
3. リレー順序・曜日/時間帯スケジュールの正＝voice-kit\03_posting_workflow.md（ブログ→X→Zenn→X→Qiita→X→note→X。Zenn/Qiita平日朝公開の自動化がスキル化の要件）
4. 証拠ルールのプロンプト組み込み（Miyoki発案 2026-07-05）：生成時に [📸証拠：…] プレースホルダを本文へ差し込む指示を生成プロンプトに追加（ルールの正=voice-kit\01_media_templates.md 共通ルール。pipelineのagentPromptsにも同趣旨を追加する）
5. 承認ダッシュボード（Phase 3・Miyoki発案 2026-07-05）：スマホから①記事内容の確認→チェック済み、②投稿文の確認→チェック済み、③投稿用コピペ（Xはツイート1個ずつコピーボタン）、④予約済み/公開済みのステータス管理、ができるモバイルファーストの管理画面。データ源=下書き\Miyoki-Labs\＋記事キュー.md＋公開台帳.md。実装候補=Cloudflare Pages（静的生成 or KV）。未着手（2026-07-05時点で存在しない）
6. 審査プロンプトの採点再調整（few-shot採点例 or 減点方式の明文化）→ ゲート80復帰
7. 想定読者3択の提案機能（KW/内容から読者ペルソナを3案提示→選択して生成。Miyoki発案 2026-07-05）※スキル化するなら対話で自然に実現可
8. ライティングスタイル設定に voice-kit の文体サンプルを常用（今回未設定で生成→本文が汎用調になった反省）
9. サイト別プロファイル対応（トーン/KW戦略/CTA/出力先の切替）

2026-07-05 追記：今回の記事作成ルール（具体的ターゲットのリード・おすすめボックス必須・CJK太字スペース・捏造ガード×生成/改善/審査）は agentPrompts.ts に組み込み済み。記事の消化順は ideas\記事キュー.md（時系列）が正。

voice-kit とは統合しない（役割分担。発信の司令塔=voice-kit／深掘り専任=pipeline）

miyoki-portfolio（薄い計画書）

• 目的：AI受託の実績見せ・入口。全媒体（@miyoki_labs）のハブ
• 実装：C:\Miyoki\個人\miyoki-portfolio\（Next.js 15 / React 19 / Tailwind / Cloudflare Pages）
• 設計の正：計画\04_ポートフォリオ計画.md

現在地（2026-07-04）

• 公開済み（Cloudflare Pages）。ブランド統一（miyoki_labs）反映済み・記事カード実装済み
• 実績5件掲載（RAG / 提案文 / 執筆補助 / pipeline / teleapo）

次の一手

1. /links リンクハブ実装（ヘッダーにも Links パネル。X bio の着地先）
2. 記事カード Phase 2：note RSS の fetchNote()（noteリネーム済みなので着手可）
3. /contact（Slack通知＋Turnstile）は後追い

デプロイ：npm run deploy（next-on-pages → wrangler pages deploy）

miyoki-post-deck（薄い計画書）

• 目的：Miyoki Labs（🔬）の発信下書きをスマホから確認・コピペ投稿できるWebデッキ。ロードマップ最優先「承認ダッシュボード（pipeline Phase3）」の実体化。
• 実装：C:\Miyoki\個人\miyoki-post-deck\（生成静的HTML → Cloudflare Pages）
• 設計の正：この計画書＋プロジェクト別\miyoki-media-pipeline.md Phase3。Nompass版（nompass-post-deck）とは完全別物（混同しない）。

分離ルール（Nompassと混ぜない）

• ドメイン=deck.miyoki-labs.com／CFアカウント=Miyoki／ブランド=Mロゴ・Miyoki配色
• データ源＝下書き\Miyoki-Labs\（Zenn/Qiita/note/X）＋ideas\記事キュー.md＋ideas\公開台帳.md
• 対象媒体＝個人（Zenn/Qiita/note/X）。事業（Nompass）発信は扱わない

アーキテクチャ（MVP＝生成静的・バックエンドなし）

• Node生成スクリプトが下書き .md を読む → コピーボタン付きモバイルHTMLを生成 → dist/ → wrangler pages deploy dist --branch main
• 状態（未/ドラフト/投稿済）は 記事キュー.md・公開台帳.md から読む（UIで持たない＝Claude Codeが更新する既存フローに乗せる）
• 限定公開＝Cloudflare Access（未公開下書きを守る・無料枠）
• Phase2（効率化）：KV動的化＋"生成→push"を/self-postに組み込み自動反映

MVP機能

1. 媒体別タブ（Zenn/Qiita/note/X）＋ステータス表示
2. 全文表示（Markdownレンダリング）
3. ワンタップ コピー（Xはツイート1個ずつ）
4. 文字数カウント（X・note）

投稿フィードバック（UIから送る・実装済み 2026-07-07）

「UIから実際に投稿した内容を送る→学習＆アーカイブ」を Cloudflare Pages Function＋KV で実装。Miyoki/Nompass共通。

• UI：各未投稿カードに「✅投稿したら送る」＝編集欄（最終版に貼替可）＋送信ボタン → POST /api/posted（KV POSTED に保存）。軽いトークンPOST_SECRETでbot除け（正の保護はCloudflare Access）。
• Claudeの処理フロー（セッションで実行）：
• curl "https://miyoki-post-deck.pages.dev/api/posted?token=<POST_SECRET>" → 投稿済みを値付きで取得
• 各itemの postedText を原案（下書き）と差分比較→鼻に付く言い回しを voice-kit/01_media_templates.md の「避ける言い回し」に追記（学習）
• 該当ファイルを posted/ へ移動＝アーカイブ（Nompass=output/<media>/posted/、Miyoki=下書き/Miyoki-Labs/<媒体>/posted/）→ npm run deploy
• curl -X DELETE ".../api/posted?token=<POST_SECRET>&all=1" で処理済みKVをクリア
• KV注意：Pagesがバインドした物理名前空間はCLIのnamespace-idと不一致 → 読み書きは必ずFunction経由（GET/DELETE）。put直後のgetは結果整合で最大60秒ラグ（後で読む運用なので問題なし）。
• 秘匿：POST_SECRET＝wrangler.jsonc vars ＆ generate.mjs POST_TOKEN を一致させる。

Phase2：投稿レイヤー（UIから投稿）

投稿レイヤー設計の正＝計画\プロジェクト別\miyoki-media-pipeline.md「投稿レイヤーも同時設計」。ここはそのUIトリガーを担う（重複定義しない）。

• MVPはコピー運用で先に出す。Zenn/Qiita の投稿ボタンはPhase2で足す（バックエンド＝Pages Function＋secret管理が要るため）。
• 各媒体は常に理想構成・文字数を目指す（生成ルールの正＝voice-kit\01_media_templates.md「運用の固定ルール」）。デッキは字数カウント表示でこれを可視化する。

現在地（2026-07-06）

• 発信ハブ（マルチページ）としてデプロイ済み。本番＝https://miyoki-post-deck.pages.dev（200確認）
• index.html＝トップ（🔬Miyoki / 🏢Nompass の2カード・プロジェクト選択）
• miyoki.html＝Miyoki専用（下書き10件＋週間おすすめ投稿カレンダー）
• nompass.html＝Nompass専用（下書き0件＝要生成＋Nompassカレンダー）
• アーキ変更：当初「2つ別々にデプロイ」→ 1つの私的ハブに統合（トップから各プロジェクトへ／個別ページは各プロジェクトのみ＝混同なし）。私的ツールなのでAccess保護前提で1アプリに集約
• カレンダー＝各プロジェクトの 03_posting_workflow.md/posting-calendar.md の標準スケジュールを週グリッド化＋「▶次に出す下書き」を各枠に表示
• ⚠️ 現状URLを知れば誰でも閲覧可（noindexのみ）→ Cloudflare Access 未設定（最優先の残）

進捗追記（2026-07-07・self-post連携）

• /self-post の保存先をデッキの読み場所に統一：ブランド文脈=Miyoki→下書き\Miyoki-Labs\<媒体>\、=Nompass→voice-kit\output\<媒体>\draft\。旧 knowledge-log\drafts\ は廃止（デッキ未読だった）。→ 以後の下書きは自動でデッキに載る。
• 既存の孤児3本（技術Zenn・認証ループ/slice例外/fade-in）を 下書き\Miyoki-Labs\Zenn\ へ移動し掲載。Miyoki下書き 10→13件。再デプロイ済み（本番反映確認）。
• ⚠️ 未設定のまま：Cloudflare Access（＝現状URLを知れば下書きが誰でも閲覧可）。最優先の残として継続。

進捗追記（2026-07-07）

• バグ修正：microCMS本文のHTMLエンティティ未デコード（"等が生表示・コピー）→ generate.mjs の htmlToText() にデコード追加。
• Phase2 Qiita投稿ボタン＝コード実装・ローカルE2E検証済（未デプロイ）：functions/api/post/qiita.js（POST /api/post/qiita＝frontmatter解析→Qiita API投稿。トークン無しは安全なno-op）＋Qiita未投稿カードに「限定共有/公開で投稿」2ボタン（2段階確認）。既存 /api/posted（投稿ログKV・別セッション実装）と非競合。
• Zennボタンは保留：GitHub連携リポ未作成のため。連携リポ作成後に別途。

次の一手

1. 🖥️Step B（週末・最優先）：Cloudflare Access で限定公開（/api/* も保護＝投稿APIのガード本命）／deck.miyoki-labs.com 割当／3幅・コピー動作の実機確認
2. 🖥️Qiita投稿を有効化（週末・上記Accessとセット）：wrangler secret put QIITA_TOKEN → npm run deploy → まず限定共有で1本テスト→公開
3. 更新運用：新下書き後 npm run deploy で再反映（Phase2で自動化＝生成→push・KV）
4. 型が固まったら Nompass版へ横展開（nompass-post-deck）
5. Phase2続き：Zenn投稿ボタン（GitHub連携リポ作成後・GitHub API）
6. 投稿推奨日の自動計算（Rule2・2026-07-07決定）：現状は各下書きの推奨日=ファイル作成日ベース。→ 媒体別の投稿曜日/時間帯を正に、各下書きへ「次の投稿枠」を逆算表示（キュー順＝収集日古い順に枠を割当。先出し例外は前倒し）。⏳媒体別スケジュール表の確定待ち（Miyokiが提示）→確定後 generate.mjs のカレンダー/カードに実装。スケジュールの正の置き場＝voice-kit\03_posting_workflow.md/posting-calendar.md（確定時にそこへ）。

nompass-post-deck（薄い計画書）

• 目的：Nompass（🏢）の自社発信下書きをスマホから確認・コピペ投稿できるWebデッキ。既存ローカル content-dashboard.html のデプロイ版。
• 実装：C:\Miyoki\Nompass\Nompass Build\00.Nompass\（既存 assets\content_dashboard.py を進化）→ Cloudflare Pages
• 設計の正：この計画書。Miyoki版（miyoki-post-deck）とは完全別物（混同しない）。

分離ルール（Miyokiと混ぜない）

• ドメイン=deck.nompass.jp／CFアカウント=Nompass／ブランド=Nompassサービスカラー
• データ源＝00.Nompass\voice-kit\output\（＋microCMS下書き・公開分）
• 対象媒体＝事業（note公式/X/Instagram/LP）。個人（Miyoki Labs）発信は扱わない
• 顧客ポータル（app.nompass.jp/Render）とも分離＝これは社内用の自社発信デッキ

アーキテクチャ（MVP＝生成静的・バックエンドなし）

• 既存 content_dashboard.py を土台に、voice-kit\output\ を読む → コピーボタン付きモバイルHTML → dist/ → Cloudflare Pages デプロイ
• 既存機能（全文表示・📋投稿用コピー・microCMS編集リンク）を流用＝実装量を圧縮
• 限定公開＝Cloudflare Access（社内のみ）

MVP機能

1. 媒体別（X/Instagram/note/ブログ）＋公開状態
2. 全文表示・ワンタップコピー・microCMS編集リンク
3. Miyoki版と同じ操作感（型は共通・データとブランドは別）

現在地（2026-07-06・方針変更＝無駄なく運用）

• 別デプロイはしない。発信ハブ（miyoki-post-deck）の nompass.html ページとして統合（トップから選択・個別ページはNompassのみ＝混同なし）。
• 既存資産＝microCMSを取り込み済み（content_dashboard.py のロジックを generate.mjs に移植）。生成時に microCMS news API から公開ブログ/お知らせ/下書きを取得→カード化。既存2記事（公開1＋下書き1）＋「サイトで見る」「microCMSで編集」導線が本番で稼働（https://miyoki-post-deck.pages.dev/nompass ）。APIキーはローカル.env.localのみ・出力HTMLに含まない（漏洩チェック済み）。
• 方針修正：ゼロから下書き量産→中止。無駄なく運用（北極星＝相互補強／リレー＝1ネタ→多媒体）に合わせ、既存microCMS記事を活用する方向に。
• 次＝リレー派生：既存ブログ1本から X告知スレッド/note等の派生を用意する導線（voice-kit/output に置く＝カレンダーの枠に載る）。ゼロ書きでなく書き分け。

次の一手

1. Miyoki版（miyoki-post-deck）の型確立を待つ
2. 📱Step A：content_dashboard.py を deploy 対応に改修（voice-kit/output 読み込み＋モバイル整形）
3. 🖥️Step B（週末）：Cloudflare Pages デプロイ／deck.nompass.jp 割当／Cloudflare Access設定／3幅確認

proposal-generator（薄い計画書）

• 目的：営業提案文の自動生成。受託実績＋CW応募運用のドッグフーディング
• 実装：C:\Miyoki\個人\proposal-generator\（Next.js）

現在地（2026-07-04）

• ほぼ稼働可（構成一式＋.env.localあり）

次の一手（ロードマップP1-(3)）

1. CW（クラウドワークス）応募の定型提案文をこれで量産 → 週数件応募の運用に乗せる
2. 使用感・改善は knowledge-log に記録（実績記事のネタ化）

位置づけ：デモ実績＝見せられる状態で完成扱い・作り込まない

reply-draft-assistant（薄い計画書）

• 目的：X/Zenn等の返信下書き生成＝発信の継続コストを下げる自作ツール
• 実装：C:\Miyoki\個人\reply-draft-assistant\（Vite + React / Cloudflare Functions）

現在地（2026-07-04）

• 作成済み（メモリ登録済み・作り直さない）

次の一手

1. 発信ロールアウト（ロードマップP2）が始まったら実運用に組み込む
2. 位置づけは「見せられる状態で完成扱い」＝作り込まない（ロードマップの仕分け準拠）

使った学びは knowledge-log → seeds へ（自作ツールのドッグフーディング自体がネタ）

teleapo-demo（薄い計画書）

• 目的：テレアポ切り返しAI＋SMS自動化のデモ。現場業務×AIの実用例
• 実装：C:\Miyoki\個人\teleapo-demo\（Next.js）

現在地（2026-07-04）

• 完成度高・稼働

次の一手

1. 完成扱い・実績掲載のみ（作り込まない）
2. SDC系の受託が動いたら前倒しで拡張（ロードマップP5温存）

管理確認UI（構想・設計メモ）

種別: 新規プロジェクト構想（未着手）。発案 2026-07-09。 ひとことで: 管理側が「確認・計画のために見たい .md」を、種類別フォルダに整理してスマホから網羅的に読めるビューア。 ステータス: 設計のみ。実装は週末以降（🖥️PC）。

---

目的（何を解決するか）

SSOT・手順・計画・ネタが 計画\ ideas\ voice-kit\ 00.Nompass\ Nompass\docs\ などに散っていて、「何がどこにあるか」「今どうなってるか」を見返すのに毎回パスを辿る必要がある。 → 見たいものが種類ごとに並び、スマホでそのまま読める1つの入口を作る（平日スマホ前提の確認を楽にする）。

---

スコープ（今回の要望の確定事項）

• 管理側が確認すべきものを 種類ごとにフォルダ分け して見せる。
• スマホから見やすい形式（＝miyoki-post-deckと同じモバイル前提）。
• 🔬個人の媒体プレイブック（voice-kit\04_媒体別プレイブック.md）もこのUIの網羅対象に載せる。
• read-only の「確認」用途（編集はしない。編集は各エディタ/claude.ai/code）。

---

実装方針（推奨MVP）

既存 個人\miyoki-post-deck のパターンを流用した"別ツール"を新規に作る（post-deckは発信下書き専用なので混ぜない）。

• 技術: 依存ゼロの generate.mjs 相当が、マニフェスト(見せるファイル一覧) を読んで dist/index.html を生成 → Cloudflare Pages。post-deckと同じ「ローカルbuild→deploy」。
• 限定公開: noindex ＋ Cloudflare Access（管理者だけ）。post-deckと同じ作法。
• モバイルUI: 種類別のタブ/アコーディオン → ファイル → md本文をレンダリング表示。折りたたみ・全文検索・「最終更新日」ソート。
• マニフェスト方式が肝: 全mdを機械的に舐めるのではなく、「管理側が見たいもの」をカテゴリ付きで列挙した1ファイル（例 manifest.json or .md）を正にする。増減はここを直すだけ。

マニフェスト（確定版・2026-07-09）

これが④の「何を確認できるようにするか」の正。実装時に 個人\miyoki-admin-deck\manifest.json へ書き出す（このセクションが人間可読の正、JSONは写し）。 全パスは C:\Miyoki 起点。admin-deckのビルドはローカルの実ファイルを読む（git内/git外・別リポを問わず、ローカルにあれば読める）。 優先度: ★core=まず載せる（頻繁に確認）／○=あれば便利／△=任意。

🧭 現在地・整合

🗺 計画・戦略

📁 プロジェクト別（薄い計画書）

📣 発信

💡 ネタ

🏢 Nompass運用

🧾 手順書

あえて載せない（除外）

• node_modules\ 等の実装物・_reference\（塩漬け）・各種CLAUDE.md（AI向け指示で"確認"用途と別）・article-seeds.md（移行済みアーカイブ）。
• 除外理由: ノイズを増やさない。CLAUDE.md群は必要なら別カテゴリで後付け。

運用: 増減はこの表を直す→manifest.jsonに反映。ワイルドカード（プロジェクト別\*.md等）は展開ルールをbuild側に持たせ、個別追加を減らす。

---

論点（設計で決めること）

1. read-only の"地図+本文"で足りるか（＝当面MVP）／将来ステータスやTODO集約まで要るか
2. MVP＝本文レンダリング＋検索で十分。ステータスは棚卸し/キュー側が既に正なので二重に持たない。
3. 単独ツール vs post-deck拡張 → 単独推奨（対象・アクセス権・更新頻度が違う。post-deckは発信専用に保つ）。
4. 鮮度の担保（重要）:
5. MVP: post-deckと同じ「ローカルbuild→deploy」（PC必須）。
6. Phase2案: このワークスペースはGitHub同期(miyoki-workspace-docs)。GitHub Actionsでリポからbuildすれば、平日にclaude.ai/codeがリポへ書いた変更→CIで自動再ビルド→スマホのデッキが最新化（PC不要）。post-deckがPhase2で狙っている自動化と同じ発想。
7. 命名: 個人\miyoki-admin-deck（仮）。post-deck(発信) / admin-deck(管理確認) と役割で分ける。

---

現在地 → 次の一手

• 現在地: 構想（本メモ）。実装なし。
• 次の一手（週末🖥️）:
• 個人\miyoki-admin-deck を post-deck の generate.mjs を土台にコピーして起こす
• manifest（上記カテゴリ＋初期ファイル）を定義
• モバイルHTML生成（アコーディオン＋検索）→ ローカルbuildで手元確認
• Cloudflare Pages + Access で限定公開
• うまく回ったら Phase2（GitHub Actions自動ビルド）を検討

---

参照

• 流用元: 個人\miyoki-post-deck\（README／計画\プロジェクト別\miyoki-post-deck.md）
• 網羅対象になるファイルの所在: ルート .claude\CLAUDE.md の各一覧表・計画\現在地.md
• 横断検索の落とし穴（buildでファイルを舐めるとき）: メモリ workspace-search-scope-caveat

記事キュー — 次に書く順番の正（時系列消化）

ルール（基幹＝.claude\CLAUDE.md「昇格ネタを投稿化する順番」と同一）：未執筆★★以上を収集日の古い順に上から消化する（同日内は★が高い順）。汎用的で有益な知見を、前の話を受けた"続き物/シリーズ"として積む前提。 - 例外＝先出しOK（作成も投稿も前倒し）：早く投稿した方がよいもの＝①時流・時事性（旬・話題性・公開直後の熱）／②緊急度（早く出さないと価値が落ちる・読者が困っている）／③重要度（事業・ブランド/受託導線に直結）。当たるものは時系列を飛ばして先に作り先に出す（その場合もキューから消す）。 - 執筆・公開したら：この表から行を削除 → 公開台帳.md に1行追記 → 元の seeds/log のステータスを書き戻す - 週次 MiyokiSeedScan 後、新しい★★以上をこの表の末尾（収集日順の正しい位置）に追記する - 出典キーは seeds-miyoki.md / 各プロジェクト knowledge-log/log.md の見出しと対応 - 公開手段の現状（2026-07-05）：ブログ=pipeline直接書き出し→deploy／Zenn・Qiita・note=/self-postで下書き生成→手動投稿（投稿自動化はpipelineスキル化と同時に設計予定＝計画書参照） - 1ネタの回し方＝リレー方式（ブログ→X→Zenn→X→Qiita→X→note→X・曜日/時間帯つき）。正＝voice-kit\03_posting_workflow.md

---

無料↔有料の線引き（2026-07-08確定・規約の正＝_knowledge-log-rule.md）

このキューの各行は原則すべて L1（無料）。有料noteは、複数のL1を束ねた上で「実物」を足したものになる。

判定テストは1問だけ：「これを読んだ人が、明日、自分の環境で同じものを動かせるか？」 → Yes = L3（有料） / No（理解はできるが手は動かない）= L1（無料）。理解は売らない。再現を売る。

• 有料化の前提：無料リレーが3〜4本回ってから1本目を出す（読者ゼロで有料を出さない）。
• 1本目の束ね＝ #31 Stop hook ＋ #32 BOM ＋ #33 保護置換 ＋ #34 定期エージェント×git

→ 「Claude Codeを自動運用するときに踏む地雷と、踏まないためのhook設計一式」（980円スタート → 実績が出たら1,480円。noteは公開後に価格変更可）。

• 上記4本はL1として先に無料公開する（有料noteの目次かつ流入導線になるので、出し惜しみしない）。

---

リレー開始の前提（2026-07-05 Miyoki決定・正=ロードマップ実行キュー）：①承認ダッシュボード開発 → ②下記の自己紹介投稿 → ③キューのリレー開始。公開済みブログ記事のX告知①も③まで保留。

先に済ませる：各媒体の初回＝自己紹介投稿（2026-07-05 Miyoki決定）

ブログ・Zenn等から入ってきた人に「何者か」が伝わる状態を作ってから、キューのリレーを始める。 ネタ元＝計画\02_ポジショニング.md（人格キャノン）＋ ポートフォリオ実績。生成は /self-post。

収益の前提も並行（2026-07-06決定・正=計画\プロジェクト別\miyoki-blog.md）：A8.net登録＋Xserver/お名前.com提携申請（📱本人操作）→承認後、公開済み記事のCTAをアフィリリンクへ差し替えてからリレー開始するとロスがない。 公開済み記事の扱い（2026-07-07更新）：domain-koshinryo-hikaku=✅標準構成・数値ファクトチェック済み（誤り3件修正・出典セクション追加）。chatgpt-claude-hikaku=✅実体験ベースでフルリライトし公開再開（quality-checkで料金2件追加修正済み・公開台帳に記録済み）。記事の型=計画\06_ブログ計画.md §6。残タスク=証拠スクショ3枚（任意・Claude代行可。blog計画書 次の一手1／ルール改訂=出典リンク必須・スクショ推奨止まり）。

キュー（上から消化）

公開台帳 — 何を・どこに・いつ出したかの一元記録

公開実績の正はここ。 記事・投稿を公開したら必ず1行追記する（ログ側のステータス書き戻しとセット）。 週次スキャン（_auto-seed-scan.md）が seeds のステータスとの同期をチェックする。 並び：新しい順（上に足す）。

---

🔬 Miyoki Labs

🏢 Nompass

---

使い方メモ

• 1行＝1公開。同じ記事を複数媒体に展開したら媒体ごとに行を分ける（クロスポストの追跡）
• 「元ネタ」は seeds/log の出典キー（repo＋日付見出し or repo@短SHA）
• シリーズ列が埋まっている行が一定数溜まったら、ideas\シリーズ\ の該当インデックスで「まとめ記事・連載・note有料化」を検討する
• 有料化の単位＝「最初から最後まで動くワークフロー1つ」。線引き（L1/L2/L3・判定テスト）＝_knowledge-log-rule.md「無料↔有料の線引き（tier）」

投稿ワークフロー（低負荷・継続重視）

全部ひとりで回す前提。手間を最小に・続けられるバランス重視。 ネタ＝ideas/seeds-miyoki.md / 生成ルール＝01_media_templates.md / テンプレ＝templates/。 フェーズ別のペース・内容の正＝計画\投稿フェーズ戦略.md（立ち上げ/定着/拡大で変える）。ここは曜日/時刻の実データ。

全体像

① ネタは seeds にたまる     knowledge-log→seeds-miyoki（週次harvestで自動集約）。消化順=ideas\記事キュー.md（時系列）
        ↓
② 週1でまとめ生成           土日に /self-post で渡す → templates準拠で 下書き\Miyoki-Labs\ に生成
        ↓
③ 確認（人間必須）          事実・数字・技術の正確性チェック（seedsの範囲を超えてないか）
        ↓
④ 予約／公開               リレー方式（下記）で媒体別の曜日・時間帯に分散
        ↓
⑤ 告知＆記録               X告知（都度） → 公開台帳に1行 → seeds/キューのステータス書き戻し

自動化の線引き：生成と準備は自動化。「公開してよいかの最終判断（③）」は必ず人間。技術記事は誤情報が信頼を損なうので、正確性チェックは自動化しない。公開の実行（予約・push）は人間チェック後なら仕組み化してよい。

---

リレー方式（1ネタ→多媒体・都度X告知）＝2026-07-05 Miyoki決定

1つのネタを媒体別に書き分けて時間差でリレーし、各公開の直後に必ずXで告知する。1ネタが1週間で4〜5回露出する。

ブログ記事（親・アフィリ）公開 ──→ X告知①
   ↓ 関連ネタを開発ログ視点で書き分け
Zenn記事（ブログへリンク）公開 ──→ X告知②
   ↓ 技術解説視点で書き分け
Qiita記事（ブログ/Zennへリンク）公開 ──→ X告知③
   ↓ （物語・働き方視点があるネタのみ）
note記事 公開 ──→ X告知④

• 転載禁止：各媒体は視点を変えた別記事（媒体分担＝01_media_templates.md）。相互リンクでブログ（収益の親）へ導線を集める
• 全部の媒体を毎回やる必要はない。最低セット＝ブログ or Zenn ＋ X告知

曜日・時間帯の標準スケジュール（初期値・実測で調整する）

制約前提：平日は21時までPCなし。生成・チェック・予約セットは週末に一括、平日は予約が自動で走る形にする。

運用のコツ：週末のバッチで「下書き全部＋X告知文×媒体数」まで作り、X/noteは予約を入れて閉じる。Zenn/Qiitaの平日朝公開だけが現状手動（→pipelineスキル化と同時に自動化。正=計画\プロジェクト別\miyoki-media-pipeline.md 次の一手）。

2026-07-08：毎日21時の自動生成ルーチン稼働後の頻度方針——供給（生成量）は週次時代より大幅に増えたが、Zenn/Qiita/noteは事実確認の人手がボトルネックなので頻度は現状維持のまま様子見。空いている水・金だけXの単独投稿で供給を活用する（上表9）。1〜2週間運用してから頻度増を再検討する。

---

毎週やること（土日・30〜60分）

1. Nompass\Nompass Build\00.Nompass\knowledge-log を git pull（金曜夜のクラウドルーチンが drafts/ に自動ドラフトを積んでいる。土9時のGitHub Issueにも候補Top3が届く）
2. seeds-miyoki.md の「今週書くならTop3」or ★の高い未執筆から選ぶ（drafts/ に自動ドラフトがあればそれを仕上げるのが最短）
3. Claude Code にまとめて渡す（00_self_voice_guide.md §5 の頼み方）
4. 生成物（下書き\Miyoki-Labs\）を読み、事実・技術・実績表記をチェック。[📸証拠：…] プレースホルダを実スクショ・実データに差し替える（差し替えゼロの記事は公開しない＝証拠ルール、正=01_media_templates.md共通ルール）
5. 画像が要るものは実素材優先／無ければ Writing-Assistant で画像プロンプト
6. 予約・公開（下表）
7. 公開後、X告知スレッド → seeds の該当エントリに公開URLを書き戻す

予約先（すべて無料）

---

pipeline に回すケース（深掘り）

• 検索需要が大きく収益化できるネタ（ツール比較・使い方）は pipeline でアフィリ記事化。
• その際 seeds を実践パートとして渡す（体験入りで差別化）。
• 完成したら X で告知（voice-kit のXレーンで告知スレッドを作る）。

やらないこと（今は）

• API/Zapier での全自動投稿（誤情報リスクが手間削減に見合わない）
• 有料予約ツール（純正で足りるうちは不要）
• ネタの新規大量生産（seeds＝既存の開発知見の使い回しが基本）
• 動画（挫折済み・やらない）

04_媒体別プレイブック（🔬Miyoki Labs個人・骨組み）

誰向け: Miyoki自身（技術発信レーン）。「媒体ごとにどう見せ・どう動くと効くか」の攻略メモ。 03_posting_workflow（運用フロー＝いつ何を回すか）とは切り分け、本ファイルは媒体ごとの見せ方・攻略だけを集める。 媒体分担の正: 01_media_templates（X=拡散入口／Zenn=開発ログ／Qiita=技術解説／note=ビジョン/生き方／ブログ=アフィリ独立メディア）。 ステータス: 骨組み（設計）。★基本は下書き済み、★★★★★は肉付けGO後。 置き場の意図: 本ファイルは ④ 管理確認UI の網羅対象（管理側が「見たい時に開く」ファイルの1つ）。

---

共通フレーム（3本柱）＋難易度3層

各媒体を 活用法 / 最適な投稿運用 / 避けるべきこと の順で。難易度タグ:

• ★ 基本（調べれば出る定石）／★★ 実践（実測で効く）／★★★ 効かせどころ（裏技・初速・アルゴリズム）

全媒体共通の土台: AI臭い表現を避ける・体験/失敗ベース・結論先出し（正=グローバルCLAUDE.md／00_self_voice_guide）。避ける言い回しの正=01_media_templates。

---

① X（拡散の入口）

活用法

• 記事の初速と拡散のハブ。各媒体公開の都度告知で露出を稼ぐ（リレー方式=03_posting_workflow）。

最適な投稿運用

• ★ 記事告知は「1行フック→何が学べるか→リンク」。リンクは1〜2ツイート目以降に置くと初速が落ちにくい。
• ★★ スレッドで要点を3〜5個先出し→最後に記事リンク（記事を読む前に価値を渡す）。
• ★★★ 朝の技術者TL（7:30〜8:30）に合わせる。画像/コードスクショ1枚で滞在時間を稼ぐ。

避けるべきこと

• リンクだけ投げる告知（伸びない）。
• 同じ告知文の使い回し・同語尾3連続。

---

② Zenn（開発ログ・失敗談）

活用法

• 「作った過程・詰まった点・直した話」を時系列で。開発者の共感と信頼を得る主戦場。

最適な投稿運用

• ★ タイトルに「何を・どうした」を具体で（数字・エラー名）。
• ★★ 公開直後の初速がZenn内トレンドに効く→火曜朝公開＋X告知直結。
• ★★★ GitHub連携リポでスケジュールpush（平日朝の自動公開）。Publication「Nompass」に乗せて事業ブランドも補強。

避けるべきこと

• 完成した綺麗な手順だけ（失敗と判断過程が価値。そこを削らない）。

---

③ Qiita（技術解説）

活用法

• 再現性ある技術解説・Tips。「検索で長く読まれる」ストック型。

最適な投稿運用

• ★ 1記事1テーマ・コードは動く形で・結論から。
• ★★ デイリートレンドが朝リセット→木曜朝公開が有利。
• ★★★ タグは実際に検索される粒度で3〜5個。Organization「Nompass」で信頼を上乗せ。

避けるべきこと

• ポエム化（Qiitaは解説の場。思想はnoteへ）。
• 動かないコード貼り（信頼を最も損なう）。

---

④ note（ビジョン・生き方）

活用法

• 数字や技術でなく「なぜやるか・どう生きたいか」。人としてのファン化と長期の指名に効く。

最適な投稿運用

• ★ 体験→気づき→これからの順。等身大で（誇張しない＝鼻に付かせない）。
• ★★ 日曜夜21時前後に公開（振り返り系が読まれる時間帯）。
• ★★★ 有料note1本に蓄積を集約する線引き（無料↔有料のtier規約に従う）。

避けるべきこと

• 説教調・言い切りの自己アピール（miyoki-tone-avoid-pretentiousの学び）。

---

⑤ ブログ（blog.miyoki-labs.com・アフィリ独立メディア）

活用法

• 収益の親（アフィリ）。検索流入を集め、他媒体から導線を集約する資産。

最適な投稿運用

• ★ 検索意図のあるテーマ・結論先出し・内部リンク。
• ★★ 記事公開→Zenn/Qiita/noteから相互リンクで導線を親へ集める（リレーの起点）。
• ★★★ OGP・全ページCTA・表示速度（Astro）で回遊と収益率を底上げ。

避けるべきこと

• 転載（各媒体は視点を変えた別記事に）。
• CTA不在（読んで終わりにさせない）。

---

残作業（GO後）

• [ ] 各媒体★★/★★★を自分の実データ（伸びた投稿の数値）で裏取り・肉付け
• [ ] リレー方式との突き合わせ（03_posting_workflowの曜日表）
• [ ] ④管理確認UIのカタログにこのファイルを登録

05_投稿効率化設計（FB差分学習＋カレンダー通知）

対象: 🔬Miyoki Labs個人 と 🏢Nompass 両方（仕組みは共通、置き場と反映先だけ分ける）。 目的: 投稿づくりを回すほど「文体・作り方が自分好みに寄り」「やる日を忘れない」状態にする。 ステータス: 設計のみ。実装（カレンダー登録・FBログ運用）はGO後。 関連: 運用フロー=03_posting_workflow／文体の正=01_media_templates・00_self_voice_guide／避ける言い回しの学び=miyoki-tone-avoid-pretentious。

---

パートA — FBを受けて文体・作り方を差分学習する

狙い

投稿前後に出した直し（「この言い回しは鼻に付く」「導入は具体ターゲットに呼びかけて」等）を捨てずにルール化し、次の生成に効かせる。人間の添削を"学習データ"として蓄積する。

仕組み（軽量ループ）

① 直し発生     生成物への赤入れ・「ここ直して」の指示・投稿時の手直し
      ↓ その場で1行記録
② FBインボックス  voice-kit\feedback-inbox.md に「日付 / 媒体 / 直す前→直した後 / なぜ」
      ↓ 週末に選別（★★＝繰り返す型のものだけ昇格）
③ ルール反映    ・文体/NG言い回し → [[01_media_templates]]（避ける表現の正）に追記
               ・普遍的な効き（書き出し等）→ セルフメモリに保存（例[[article-lead-targeting]]）
      ↓
④ 次の生成に効く  self-post/nompass-self-post 生成時に②③を参照

置き場（🔬🏢で分ける）

• 🔬 Miyoki Labs: voice-kit\feedback-inbox.md（新規）→ 昇格先 01_media_templates.md／セルフメモリ
• 🏢 Nompass: 00.Nompass\voice-kit\feedback-inbox.md（新規）→ 昇格先 同フォルダの 01_media_templates.md
• 正の一元化: 「避ける言い回し」の最終正は各 01_media_templates.md。inboxは一時置き（二重管理しない）。

記録フォーマット（1行）

- 2026-07-09 | Zenn | 「〜という観点から」→ 削除/具体化 | AI臭い・冗長。結論を先に出す

スキルへの繋ぎ（将来）

• /self-post・nompass-self-post の生成前に feedback-inbox と 01_media_templates を必ず読ませる（差分が自動で効く）。
• ★★昇格の判定は既存の「記録→選別→昇格」プロトコルに乗せる（新プロトコルを作らない）。

---

パートB — 投稿日・予約設定日にGoogleカレンダー通知

狙い

「作る日」「予約をセットする日」「手動公開する日」をカレンダー予定にして、スマホ標準通知で取りこぼしを防ぐ（平日スマホ前提）。

通知したい日（=予定にするもの）

運用フロー(03_posting_workflow)の標準スケジュールから、"人間が動く必要がある日"だけを予定化する（自動で走るX予約実行などは通知不要）。

曜日/時刻の正は 🔬=03_posting_workflowの標準スケジュール表、🏢=00.Nompass\voice-kit\posting-calendar.md。ここでは再定義せず、そこを見て予定を作る。

実装方式（推奨＝毎週の繰り返し予定を1回登録）

• 方式1（推奨）: Googleカレンダーに週次の繰り返し予定として上表を一度だけ登録。以後スマホが自動通知。メンテ最小・PC/API不要。
• Claude（Googleカレンダー連携）で一括作成も可能（create_event を上表ぶん）。スケジュール変更時だけ作り直す。
• 通知は各予定に「当日/前日」ポップアップを設定。
• 方式2: スケジュールが頻繁に変わるなら、posting-calendar.mdを正にして週次でカレンダーへ同期する仕組み（cron/ルーチン）。今は過剰。まず方式1。

カレンダーの持ち方

• 専用カレンダー「Miyoki発信」を1つ作り、🔬🏢の予定をそこに集約（色分け）。オン/オフを1タップで切れる。

---

残作業（GO後）

• [ ] feedback-inbox.md を🔬🏢に新規作成し、記録フォーマットを置く
• [ ] /self-post・nompass-self-post の入力にinbox＋01_media_templatesを読む一文を追加
• [ ] Googleカレンダーに週次繰り返し予定を登録（方式1・上表）→通知設定
• [ ] 1〜2週回してから頻度・通知タイミングを調整（posting-cadence-2026-07-08の様子見方針に沿う）

Miyoki Labs 発信キット — 運用ガイド（発信の司令塔）

Miyoki Labs の多媒体発信（Zenn / Qiita / note / X）を、seeds-miyoki を泉に・低負荷で回すキット。 位置づけ：05_コンテンツ計画.md §4-2（運用統合）。アフィリブログの深掘りは pipeline（別ツール）が担う。 Nompass版（00.Nompass/voice-kit）を雛形に、ブランド・ネタ源・CTA・媒体を Miyoki 用に差し替えたもの。

---

1. 原則

• ネタ源＝ C:\Miyoki\ideas\seeds-miyoki.md（knowledge-log から集約）。新規に作らず、seedsから拾う。
• 文体＝Miyoki文体（です/ます調ベースのカジュアル・体験/失敗談ベース）。AI臭い表現は禁止。
• レーン＝🔬Miyoki Labs（技術の中身・体験）。事業成果は Nompass 側 voice-kit の管轄（混ぜない）。
• 生成は Claude Code が 01_media_templates.md のルールで C:\Miyoki\下書き\Miyoki-Labs\<媒体>\ に保存する（下書きは中央集約・本番API不要・無料）。ワンコマンド＝/self-post。

---

2. 媒体の役割

---

3. pipeline との連携（運用統合の要）

• 普段の発信はこのキットで完結（seeds → Zenn/Qiita/note/X）。
• 検索需要が大きく深掘り価値のあるネタは pipeline でアフィリ記事化する。その際 seeds を「実践パート（体験の肉付け）」として渡す（借り物でない一次情報で差別化）。
• 振り分けの判断：
• 体験・学び・判断の経緯が中心 → voice-kit（Zenn/note）
• 検索需要 × 収益（ツール比較・使い方） → pipeline（アフィリ）＋ seeds で肉付け
• どちらも最後は X で告知して入口に流す（Xがハブ）。

---

4. 週次ルーティン（土日・30〜60分・低負荷）

1. seeds-miyoki から今週ぶんのネタを選ぶ（★の高い未執筆から）
2. Claude Code にまとめて渡す（下の頼み方）
3. 生成物（`下書き\Miyoki-Labs\`）を読み、事実・数字・実績表記をチェック（人間必須）
4. 画像が要るものは実素材優先／無ければ Writing-Assistant で画像プロンプト生成
5. X標準 / note の予約投稿で日時セット
6. 公開したら seeds-miyoki の該当エントリを「公開済み→URL」に更新（ループを閉じる）

5. Claude Code への頼み方（コピペ）

今週の発信を作って。ネタは ideas/seeds-miyoki.md のこれ：
（タイトル or 出典を貼る）
媒体と本数：Zenn 1本 ＋ X告知スレッド（3〜5連）
templates/ と 01_media_templates.md に従って 下書き/Miyoki-Labs/<媒体>/ に保存して。
画像が要るものは実素材優先で、無ければ画像プロンプトも添えて。

---

6. ネタ源は seeds に一本化（idea-inbox は持たない）

Nompass版は idea-inbox.md を持つが、Miyoki は seeds-miyoki.md が本体（knowledge-log から週次harvestで自動集約される）。 思いつきの1行も seeds に足す。この重複を避けるのが「無駄をなくす」設計。

ファイル構成

媒体別テンプレート（Miyoki Labs）

Claude Code はこのファイルのルールに沿って発信を生成する。 対象媒体：Zenn / Qiita / note / X（アフィリブログは pipeline 管轄）。 文体・フォーマットの一次ソースはグローバル CLAUDE.md「媒体別フォーマット」。

---

共通ルール

• 文体は Miyoki文体（です/ます調ベースのカジュアル・体験/失敗談ベース・短文と長文でリズム）。
• AI臭い表現は禁止：「〜の観点から」「非常に重要」「〜に他なりません」「まとめると」始まりの締め、同語尾3連続、誇張（画期的/革命的/驚くべき）。
• 事実・数字は seeds の範囲だけ使う。創作しない（技術記事は特に正確性優先）。
• Nompassの顧客企業の具体名は、Miyoki・Nompassどちらのアカウントでも出さない（2026-07-08確定）。事例・実装ネタで顧客に触れる時は「小規模事業者」「顧客」等の一般化した表現に留める。Nompass自身のサービス名（=Miyokiの自社サービス）はこの制限の対象外（記事ごとに出す/伏せるは別途判断）。
• 証拠（一次情報）のルール（2026-07-05制定→2026-07-07改訂＝続けられる運用に調整）：
• 必須＝出典の明記：料金・スペック等の外部数値は公式ページへのリンク＋確認日（記事の「出典・確認先」セクション）。リンクは貼る時に中身を照合する（貼るだけ禁止。2026-07-07に照合で誤り5件を発見した実績）
• 推奨（任意）＝スクショ：体験談の核になる主張（請求画面・操作画面・独自データ）に限り効果大。都度撮影はしない——output\ブランド画像\ 方式で証拠素材フォルダに一度貯めて使い回す（例：Cloudflare請求画面1枚は全ドメイン系記事で再利用可）
• Claude代行OK：ブラウザ（ログイン済みセッション）経由で撮れる画面はClaudeが取得・マスキング・配置まで代行できる。撮れない証拠は主張ごと弱める（捏造しない）
• 生成時のプレースホルダは非表示コメント（{/* 📸証拠：… */} 等）で置く＝未差し替えでも表示が壊れない
• URLは「独立した行」に置くとOGPカード化される（note・Zenn・Qiita共通仕様。2026-07-08確認）。文中にtextで埋め込むと単なる青字リンクにしかならないが、URLだけを前後空行で独立させると、リンク先のタイトル・説明・サムネイルを含むカードとして表示され、クリック率が大きく上がる。Nompass・ポートフォリオ・他媒体（Zenn/Qiita）への誘導は、文中で名前に軽く触れた直後にそのURLだけの行を続ける形にする（例：本文「〜Nompassという事業を運営しています。」の次の行に空行を挟んでhttps://nompass.jpだけを置く）。noteの記事末尾には「他にもこちらで書いてます」的にZenn/Qiitaのプロフィールページ（https://zenn.dev/miyoki_labs／https://qiita.com/miyoki_labs）のURL単独行を添えると回遊カードになる（媒体間の回遊導線として積極活用する）。
• 見出しに「リード文/本文/まとめ」等の役割名を使わず、内容に即した具体的タイトルにする。
• 新しい概念は「一言でいうと〜」で要約してから詳細へ（独学補助の姿勢）。
• 【運用の固定ルール】各媒体は常にその媒体にとって理想的な構成・文字数を目指す。 下の「媒体別 構成の型」に必ず沿わせ、「媒体別 文字数の目安」の目標レンジに収める。外れていたら縮める／足すで調整してから確定する（自己紹介・告知でも例外なく媒体の型に載せる）。Zennに自己紹介を出すなら"開発ログの初回"の形にする等、媒体の作法を優先する。
• 【避ける言い回し＝Miyokiの好み・随時追記】 文言が「鼻に付く／意識高い／押し付けがましい」とならないよう、下記は避ける。Miyokiが投稿時に直した確定版を戻したら、その差分から新しいNG言い回しをここに追記する（＝学習の器）。
• 自分を大きく見せる言い切り（「〜を一人でやってます」「当事者として」等の自己アピールが前に出る表現）→ 事実＋控えめに。
• 定型のキメ台詞・説教調（「〜でしかない」「〜が本質」「まず〜すべき」）。
• 熱量過多の締め・煽り。読者を試す上から目線。
• 記事末尾で読者に直接質問を投げて回答を迫る締め（「〜は何ですか？教えてください」等）→ 実投稿では「よかったら、また覗きに来てもらえたら嬉しいです。」的な柔らかい一言に簡略化される傾向（2026-07-09・note自己紹介記事のFB差分で確認）。問いかけ自体は残してもよいが、末尾に据えて回答を強く求める形は避け、軽い誘いに留める。
• ※迷ったら「友達に近況を話すトーン」に寄せる（等身大・自慢しない）。

Miyoki文体：使ってよい表現（元：グローバルCLAUDE.md）

• 「〜かなって思ってます」「端的に言うと」「ざっくり言うと」
• 「正直なところ」「思い返すと」「気づいたら」
• 読者への問いかけ（「〜と思いませんか？」「どっちがいいか教えてください」）
• 自己ツッコミ・ユーモアを自然に混ぜる／体験・失敗談ベースでリアル感
• 短文と長文を混在させてリズムを作る

句読点・改行のルール（2026-07-07 Miyoki確認済み・全生成とリライトで遵守）

• 読点「、」は呼吸で打つ：文法的に打てる場所すべてには打たない。1文に多くて2つが目安
• 長い一文は「。」で切る：読点でつなぎ続けず、切ってテンポを出す
• 強調・タメは「——」（ダッシュ）か体言止めで作る（例：「決め手は更新料。取得料ではありません。」）
• 「！」はほぼ使わない：記事内はゼロ、Xでも最大1個
• 単語・文節の途中の不自然な折返しを許さない：本文に手動改行は入れない。Web側はCSSの禁則処理 word-break: auto-phrase（文節単位の改行・miyoki-blogは2026-07-07実装済み）が担当。新しい媒体・サイトを作る時も同じCSSを入れる

SEO・コンテンツ最適化（元：グローバルCLAUDE.md）

• タイトルは28〜32文字、検索意図キーワードを冒頭に
• リード文（最初の300字）で「誰向けか」「何がわかるか」を明示
• 具体的な数字・期間・体験談を必ず含める
• CTAは中盤と末尾の2箇所
• H2見出しにもキーワードを自然に含める（詰め込み禁止）

---

媒体別 文字数の目安

• 日本語も全角1文字＝1で数える。
• 生成後に必ず字数を数え、目標レンジ外なら調整してから確定する（短すぎ＝具体例/経緯を足す・長すぎ＝要点に絞る）。数値は目安だが「明らかに外れたまま出さない」を運用の基準にする。

---

Zenn ＝ 開発ログ

• 構成：何を作ったか → なぜ作ったか → 詰まった点・解決策 → 結果・学び。
• 失敗談・試行錯誤のプロセスを積極的に含める。完成品だけでなく途中経過でも可。
• コードより「判断の経緯」を重視。コードブロックには最小限の説明コメント。
• seeds の「その時の本音」を活かして人間味を出す。
• topicsはfrontmatterに書く（最大5個・Zenn仕様の上限）。Web編集画面・CLIどちらでもfrontmatterをそのまま読むため、本文と別枠にする必要はない。

Qiita ＝ 技術解説

• 構成：概要 → 前提知識 → 手順 → コード例 → まとめ。
• コードブロックには説明コメントを必ず入れる。「なぜこの方法を選んだか」を書く。
• SEO を意識したタイトル（「〇〇とは」「〇〇の使い方」「〇〇 エラー 解決」）。
• タグはfrontmatterに書く（title/tags/private）。投稿画面ではタグは本文とは別の専用欄なので、本文と混ぜて地の文にしない。最大5個（Qiita仕様の上限）。

note ＝ ビジョン・生き方

• 構成：体験ベースの書き出し → 気づき・変化 → 読者への問いかけ。
• 冒頭200字以内で「誰向けか」「何の話か」を明示。
• 技術的正確さより「リアルな体験・感情」を優先。最後は次回予告か読者への質問で締める。
• ハッシュタグは3〜5個、内容に即したものを（雑多な人気タグは避ける）。noteは投稿画面に本文とは別の「タグを追加」欄があるため、本文には含めず独立したセクションのまま渡す（Xのように本文へ畳み込まない）。
• 記事末尾にZenn/Qiitaプロフィールのカードリンクを添える（共通ルールの「URL単独行」参照）。技術の詳しい話はZenn/Qiitaに置いている、という導線を毎回の記事で回遊させる。

X ＝ 拡散・告知

• 1投稿目は「問い」か「意外な事実」で始める。3〜5ツイートのスレッド形式。各120字以内。
• ハッシュタグは最終ツイートの末尾に畳み込む（1〜2個・別枠で出さない・汎用語は避ける）。全ツイートには付けない＝スパム回避＋判断の認知負荷を下げる。
• Zenn/note/Qiita を書いたら必ず告知スレッドを作る。末尾にリンク導線。

---

CTA（Miyoki Labs 用）

• 受託相談：ポートフォリオ https://miyoki-labs.com ／ メール miyoki.43834@gmail.com へ誘導。
• 記事内アフィリ：アフィリ対象ツールの記事のみ（Zenn/Qiitaの技術記事には無理に入れない＝文化的に浮く）。
• ポートフォリオ誘導：X告知・note末尾で「作ったものはこちら」と実績ページへ。
• CTAは中盤と末尾の2箇所を基本（noteは末尾の問いかけと兼ねてよい）。

Nompassへの言及（2026-07-08追加・正=計画\07_アカウント接続.md「接続の基本原則」）

読者層が真逆（Nompass=足立区の非技術な事業者／Miyoki Labs=開発者・独学層）なので、機械的に毎回リンクを足さない。07の方針どおり「方向性を持たせ、必要な所だけ」。

• 入れてよい：記事の内容そのものが「個人で事業(Nompass)を作って運営している」という文脈に触れているとき（自己紹介・独立/キャリアの話・Nompass開発の裏側ログ等）。文中は名前だけ（インラインリンクにしない）→ その直後に空行を挟んでURL単独行（共通ルール参照・OGPカード化）。
• 入れない：純粋な技術Tips・エラー解決系（Qiita・Zennの多く）。文脈と無関係にNompassへ誘導すると唐突で浮く（07の警告どおり）。
• リンク先：https://nompass.jp。「事業を作って運用まで持っていける証明」という角度で触れる（宣伝色を出さない・控えめに）。

---

出力の形

そのまま貼れるテキストで 下書き\Miyoki-Labs\<媒体>\（ファイル名=YYYY-MM-DD_日本語タイトル.md）に保存する。1ファイルに以下を含める：

# [媒体]／[テーマ]

## 投稿本文
（そのまま貼れる本文）

## ハッシュタグ
（X・noteのみ。X＝1〜2個・投稿画面に専用欄が無いため本文末尾に畳み込む／note＝3〜5個・投稿画面の専用タグ欄に貼るため本文には含めず別枠のまま）

## 画像プロンプト（画像が要る場合）
（Writing-Assistant / ChatGPT等に貼る用）

## 補足
- 出典（seedsのどのエントリか）・事実確認ポイント・CTA

保存名：YYYY-MM-DD-[媒体]-[テーマのケバブケース].md

seeds — 🔬 Miyoki Labs（横断マスター）

全プロジェクトの knowledge-log/log.md の🔬レーンを集約した横断ネタ台帳。記事化の起点はここ。 運用ルール／エントリ雛形＝_knowledge-log-rule.md。出典＝重複防止キー。★・ステータスは育てる。 週次 MiyokiSeedScan が各プロジェクトのlog.md🔬レーンをここへ追記する。 書く順番は 記事キュー.md（収集日の古い順）が正（2026-07-05運用開始）。ここは台帳、あちらは消化順。

---

🔥 今週書くならこれ（未執筆・ネタ度順 Top3）

1. Cloudflare Pages で next/image が効かない問題と対策（Zenn/Qiita・★★★）— 実測273KB→34KB
2. 「説明可能なRAG」で経理・税務アシスタント（Qiita/note・★★★）— 差別化＋AIに判断させない倫理設計
3. BOMなしUTF-8でPowerShellフックが「静かに死ぬ」（Zenn/Qiita・★★★）— 日本語パス×PS5.1の無音no-op罠

---

AI生成フォールバック設計 由来（2026-07-09）

手を広げすぎたと気づいて「即金性と時間創出」に絞り直した日（2026-07-09）

• 出典: Miyokiワークスペース 2026-07-09（媒体ガイド・投稿フェーズ戦略・管理deck・フォールバック…と設計を積んだ末に、優先順位を即金性／退職・転職に使える時間創出へ格上げした意思決定）
• 収集日: 2026-07-09
• 何が起きた/やった: 1セッションで、媒体活用ガイド／投稿フェーズ戦略／管理確認UI／AI生成フォールバックと、発信・運用まわりの設計をどんどん積み上げた。途中「APIにチャージする余力がない」→「サブスク(claude.ai)をアプリのAPI代わりにできないか」で詰まったが、これは規約上できない。そこで実額を見積もったら、低ボリュームのNompass生成は Voice(Haiku)≈1円/回・Map(Sonnet)≈9円/回＝月数百円で、"チャージできない"は半ば杞憂だった（少額課金で解決）。ここで立ち止まり、「作り込みより、すぐ現金になる／退職・転職の準備時間を生むことを最優先」に優先順位を格上げ。積んだ発信系タスクは「時間創出の妨げにならない範囲で後追い」に降格し、ロードマップSSOTに日付付きで明記した。
• 記事のフック（なぜ刺さる）: 個人開発者の"あるある"＝手を広げるほど「作った気」になるが、現金にも自由時間にも直結しない。①コスト不安は実額を出すと消えることが多い（サブスク流用という規約違反の裏技を探すより、月数百円のAPIを正規に払う方が速い）。②設計を積む手を一旦止めて「これは即金/時間創出に効くか？」で仕分け直す判断。退職・転職を見据えて動く人に効く、働き方・優先順位の話。
• その時の本音: 設計docが増えていくのは気持ちいいが、ふと「これ、いま一番やるべきことだっけ」と我に返った。API予算の心配も、実額を出す前は大きく見えていた。手を広げず、現金と時間を生む方に絞る——毎回言っている「絞る」を、また自分で破りかけていた。
• レーン/媒体: 🔬Miyoki Labs（note＝手を広げすぎて絞り直す働き方の話／即金性と時間創出を優先する意思決定）
• tags: 働き方 / 個人開発 / 優先順位 / 独立・転職
• series: -
• refs: 計画\ロードマップ.md（2026-07-09 最優先の更新）／Nompass\docs\design\20_ai_generation_fallback.md（実額とAPI少額チャージ決定）／メモリ phase-verify-demand
• ネタ度: ★★
• ステータス: 素材（退職/転職の別計画が進んだら、結果と併せて書くと強い）

生成を自動化したら、次に詰まったのは「レビュー」と「画像」だった：発信のフェーズ戦略（2026-07-09）

• 出典: Miyokiワークスペース 2026-07-09（「立ち上げは毎日投稿で露出を増やすべきか」→ フェーズ別の投稿戦略を、最新の媒体別ベストをWebで裏取りして設計）
• 収集日: 2026-07-09
• 何が起きた/やった: 毎日21時ルーチンで下書き供給は自動化済み。なのに「毎日投稿ブリッツ」を全媒体に一律適用できないのは、律速が生成ではなく"人間のレビュー（事実確認・景表法）"だから、という前提補正から出発。解＝露出の日次はレビュー負荷が軽く効く面（X/Threads/MEO）に集中させ、誤情報が信頼を壊す記事(Zenn/Qiita)と景表法のかかる事例noteは週1で質を死守する線引き。もう一つの実務ネックが画像必須媒体（Instagram等）で、これは①実素材優先（🔬はスクショが実質コスト0）②Canvaブランドテンプレの週末バッチ量産③そもそも日次露出をテキスト先行のX/Threadsに寄せる、で回避。フェーズは「ステージ×マイルストーン」のハイブリッド（P0立ち上げ/P1定着/P2拡大、卒業条件つき）にし、各フェーズに投資(期間・労力)→見込み成果を保守/標準/挑戦の3ケースで"約束ではなくレンジ"として添えた。Web裏取りの一致見解＝続けられる頻度＞バースト／新規の最高ROIは投稿より"外向きの返信・コメント"／月次分析・四半期転換も反映。
• 記事のフック（なぜ刺さる）: 「AIで発信を自動化しよう」の次に必ず来る現実＝ボトルネックは生成から"確認"と"画像"へ移る、という話。個人でマルチ媒体を回す人ほど刺さる。特に「頻度を上げる前に、詰まってる工程が生成かレビューか画像かを切り分ける」「画像必須媒体をテンプレ化し、日次はテキスト面に寄せる」は再現性のある型。数字の伸びを"約束せずレンジで持つ"正直な設計観も。
• その時の本音: 「媒体ごとに最適数は割り出せてるよね？」に、正直に「あれは初期値・平常運転で、しかもレビュー律速であえて絞ってる」と補正するところから始めた。要望（毎日ブリッツ）を否定せず、"どこに毎日を張るか"に翻訳し直すのが設計だった。
• レーン/媒体: 🔬Miyoki Labs（note＝AI発信自動化の次に来るレビュー/画像ボトルネックとフェーズ戦略／Zenn＝毎日21時生成×手動レビューの運用設計）
• tags: 発信戦略 / 個人開発 / AI自動化 / SNS運用 / ワークフロー
• series: -
• refs: 計画\投稿フェーズ戦略.md（本設計）／voice-kit\03_posting_workflow.md・00.Nompass\voice-kit\posting-calendar.md（初期値カレンダー）／メモリ posting-cadence-2026-07-08（レビュー律速の判断）
• ネタ度: ★★
• ステータス: 素材（P0を実際に数週回した実測が付くと一気に強い。伸びの数字を添えて書く）

散らばったドキュメント群を「スマホで読む管理deck」に畳む設計（2026-07-09）

• 出典: Miyokiワークスペース 2026-07-09（「管理側の確認ファイルが四方に散って何がどこにあるか分からない」→ 確認用UIの設計＋マニフェスト確定）
• 収集日: 2026-07-09
• 何が起きた/やった: SSOT・計画・手順・ネタが 計画\ ideas\ voice-kit\ 00.Nompass\ Nompass\docs\ に散在し、見返すのに毎回パスを辿る状態。ここに「見たい.mdを種類別に、スマホから網羅的に読む」ビューアを設計。肝は2つ。①既存の発信deck(miyoki-post-deck＝依存ゼロのgenerate.mjsがmdを読んでモバイルHTML生成→Cloudflare Pages+Access限定公開)のパターンをそのまま流用し、別ツールmiyoki-admin-deckとして起こす（対象・権限・更新頻度が違うので混ぜない）。②マニフェスト方式＝全mdを機械的に舐めず、「管理側が見たいもの」をカテゴリ付きで列挙した1ファイルを正にする。7カテゴリ・★core約27本・除外(node_modules/_reference/CLAUDE.md群)まで実パスで確定。鮮度の担保は、このワークスペースがGitHub同期(miyoki-workspace-docs)である点を使い、GitHub Actionsでリポからビルドすれば平日にスマホ(claude.ai/code)がリポへ書いた変更→CIで自動再ビルド→手元のdeckが最新化（PC不要）。
• 記事のフック（なぜ刺さる）: 個人開発者ほど「散らかったmd/メモをどう一望するか」問題を抱える。専用の重いツールを入れず、既存の静的サイト生成パターンを流用して"自分専用の閲覧UI"を最小コストで作る話。特に「GitHub同期＋CI自動ビルドで、平日スマホ書き込みがそのまま反映される」導線は、平日スマホ/週末PCという制約下の運用ハックとして具体的。マニフェスト方式（全舐めしない・見たいものだけ列挙）は情報の量より導線を設計する考え方の実例。
• その時の本音: 「確認UIを作った？」と聞かれて、作ったのは設計メモだけで実物はまだ無い、と正直に返した回。設計と実装を混同させないことと、まず"何を見せるか(マニフェスト)"を平日に固めて週末の実装を軽くする、の順序が腑に落ちた。
• レーン/媒体: 🔬Miyoki Labs（Zenn＝依存ゼロ静的生成deckの流用で自分専用ビューアを作る／note＝散らかったワークスペースを畳む・平日スマホ運用のツール化）
• tags: 個人開発 / ドキュメント設計 / Cloudflare / 自動化 / ワークフロー
• series: Cloudflare学び（静的生成deck＋Pages＋Access）
• refs: 計画\プロジェクト別\管理確認UI.md（設計＋マニフェスト確定版）／個人\miyoki-post-deck\README.md（流用元の静的生成パターン）／計画\プロジェクト別\miyoki-post-deck.md（設計の正）
• ネタ度: ★★
• ステータス: 素材（2026-07-09 実装まで完了＝個人\miyoki-admin-deck（依存ゼロgenerate.mjs＋最小Markdownレンダラ＋検索、7カテゴリ×60ファイルをビルド）。初回はスマホで「全容が見えない」FB→カテゴリ折りたたみ＋上部ジャンプチップで"最初の1画面＝全体像"に修正＝情報量の多いツールは俯瞰→ドリルダウンにする、が実地の学び。さらに「更新の都度、どこが変わったか」をmtime差分検出（.deck-state.json）＋🆕/🔄バッジ＋上部の変更サマリー（新しい順・タップでジャンプ）で表示＝"確認ツール"は最新反映と差分可視化がセットで効く。残＝deploy(週末)＋GitHub Actions自動ビルド（00.Nompassはgit外＝トリガー方式を要決定）。通せば★★★級）

「APIが切れたらサブスクのClaudeで生成」はできない、を設計に落とす（2026-07-09）

• 出典: Miyokiワークスペース 2026-07-09（NompassのVoice/Map生成が「APIが切れたら契約中のClaudeアカウントで生成できるように」という要望から、フォールバック設計を起こした）
• 収集日: 2026-07-09
• 何が起きた/やった: 要望は「本番のVoice/Map生成でAPIが落ちても、契約してるClaude(サブスク)で生成できるようにしたい」。ここで詰まるのが、claude.ai/Claude Codeのサブスク契約枠を、アプリのバックエンドから自動APIとして叩くのは規約上できないという壁。そこで生成物を「顧客セルフ生成」と「管理側（人間が操作）生成」に二分し、方針を分けた。①顧客セルフ→正規API課金のみ。AIProvider抽象層で ClaudeAPI⇄GeminiAPI を切替＆retryable(429/529/5xx)時に別プロバイダへ1回フェイルオーバー（サブスクは噛ませない）。②管理側→管理者本人の手動操作ならClaude.ai(Claude Code)生成は可。API課金 or Claude.ai の二刀流にでき、systemプロンプトをコードから写した「手動生成キット」に顧客データを貼って生成→画面に貼り戻す運用でAPI障害時も止めない。既存 provider.ts は Claude 専用だが GEMINI_API_KEY はenv予約済みで、外形(generateText)を変えずにプロバイダ差し替えできる土台があった。
• 記事のフック（なぜ刺さる）: 「Claude Pro/MaxのサブスクをAPI代わりにプログラムから使えないの？」は個人開発者が一度は思う疑問。答え（＝規約上ダメ・正規APIの別プロバイダ切替で担保する）と、"人間が手動操作する管理機能ならサブスク生成でよい／自動で叩く顧客機能はAPIのみ"という線引きが実務的に効く。プロバイダ抽象層＋フェイルオーバーの型もそのまま流用できる。
• その時の本音: 要望をそのまま「サブスクにフォールバック」で実装するとToS違反になる。要望の意図（コスト温存・止めたくない）を汲みつつ、やっていいことの線を引き直すのが設計の仕事だと感じた一件。
• レーン/媒体: 🔬Miyoki Labs（Qiita＝AIプロバイダ抽象層とフェイルオーバーの実装／Zenn＝「サブスクをAPIにできない」を回避する管理側手動フォールバックの設計／note＝要望を否定せず線を引き直す話）
• tags: AI / 設計判断 / API / 個人開発 / ToS
• series: -
• refs: Nompass\docs\design\20_ai_generation_fallback.md（本設計）／Nompass\portal\src\lib\ai\provider.ts（Claude専用の現状・generateText外形）／Nompass\portal\CLAUDE.md（GEMINI_API_KEYenv予約・AI出力の信頼性ルール）
• ネタ度: ★★
• ステータス: 素材（方針A実装＝顧客セルフ生成フェーズで書けるとより厚い）

---

認証情報の漏洩調査 由来（2026-07-09）

スクショ流出を調べに行ったら、まったく別の場所で本番Stripeキーがgit履歴に眠っていた（2026-07-09）

• 出典: Miyokiワークスペース 2026-07-09（「NeonやCronのキーが漏れたかもしれない」という相談から、影響範囲の特定 → /security-review まで）
• 収集日: 2026-07-09
• 何が起きた/やった: 発端は「Zedの設定中にスクショがclaude.aiに写り込んだ」という自己申告。実際に写っていたのは Nompass\portal\.env で、DATABASE_URL（Neon）と、64桁hexが1行入っていた。ところがそのhexは CRON_SECRET= が付いておらず、cron というラベルの下に裸で置かれていた＝環境変数として読み込まれていない（本番値はRenderダッシュボード側にある）。cronルートは if (!cronSecret || authHeader !== ...) の fail-closed なので、未設定でも401で閉じるだけ。つまりスクショで漏れた"cronキー"は、そもそも動作していない文字列だった。ここまでで終わらせず全リポのgit履歴を機械監査したら、申告と無関係な漏洩が2件出た。①Nompass\portal … .open-next/ をコミットした際にビルド成果物へ焼き込まれた .env が混入（b17b66d）。後に 1c3bdc2 で追跡解除されたが履歴には残り、調査時点で現在の .env とSHA-256が一致＝漏れた接続文字列がまだ現役（neondb_owner＝DB全権）だった。②個人\counter-app … functions/.env に sk_live_ のStripe本番シークレットと whsec_。コミット 4144ab8「Stripeシークレットを Secret Manager 化し.envを追跡解除」があり「追跡解除は失効ではないから危ない」と身構えたが、実測で末尾を突き合わせたら追跡解除(07-01)の3日後・07-04に本人がちゃんと再発行しており、漏洩キーは既に無効だった（＝教訓「追跡解除≠失効」は真だが、この件は本人が回していた）。両リポともPrivateで不特定多数の露出ではない。対応：①のNeonは 2026-07-09 にパスワードリセット→Render/ローカル同期でローテ完了（旧接続文字列は失効）。②のStripeは対応不要（ローテ済み）。あわせて cron_secret も新規乱数へ更新し、退避すべき2FAバックアップコード類は git/env の外（~\.secrets\vault.md）へ移送。ついでに /security-review でAPI 40本を突き合わせたところ、認証カバレッジ40/40・IDOR所有者チェック漏れなし・Webhook署名は Stripe が constructEvent()＋生ボディ、LINEが長さガード付き timingSafeEqual・dangerouslySetInnerHTML ゼロ・getAdminClient()（RLSバイパス）は1箇所のみでadmin判定が使用箇所より前、とアプリコードは堅牢だった。穴は全部コードの外側にあった。なお調査中、裸のhex行が「= を含む行だけマスクする」自作の伏せ字処理をすり抜けてセッションログに全文出力される事故を起こし、直後に同じ値をコマンドへ直書きしようとして権限分類器に止められた（正しい挙動）。
• 記事のフック（なぜ刺さる）: ①自己申告された漏洩経路は、たいてい実際の漏洩経路ではない。「スクショが流出した」を調べに行って、スクショとは無関係な sk_live_ を掘り当てた。インシデント対応は申告を起点にしつつ、申告の外側を機械的に全走査すべきという型。②「追跡解除した」「.gitignoreに入れた」は失効ではない——という原則で身構えたら、実測したら本人はちゃんと3日後に再発行していた。原則は正しいが、思い込みで「対処されていない」と決めつけず末尾突き合わせで裏を取る、という所まで含めて型（＝AIの「危ない」も人間の「対処済みのはず」も、両方SHA/末尾で検証する）。③漏れた値が今も現役かはSHA-256を突き合わせれば数秒で判る（値を一切表示せずに緊急度を判定できる調査テク）。④.env をメモ帳にすると、環境変数として機能していない行（2FAバックアップコード・ラベル付きhex）が被害面だけ増やす。⑤ビルド成果物（.open-next/）に .env が焼き込まれてコミットされる、というNext.js×Cloudflare特有の踏み方。⑥公開範囲の冷静な評価＝claude.aiへのアップロードはクローラに拾われず、Xへの公開投稿とは危険度が2桁違う（🔴と🟠を分ける判断軸）。
• その時の本音: 「Neonとcronのキー」と言われたので、その2本の影響範囲を出して終わるつもりだった。念のため git log --diff-filter=A を全リポに回したのは半ば手癖で、counter-app の functions/.env が引っかかった時は正直「これ今日の話じゃないぞ」と手が止まった。4144ab8 の chore(security): を見て「対処したつもりで蓋をしていたパターンだ」と決めつけかけたが、末尾を突き合わせたら3日後にちゃんと再発行済みで、過去の自分をあやうく濡れ衣で裁くところだった。逆に自分の伏せ字処理は裸のhex行をすり抜けてログに全文を出しており、「他人（過去の自分）の対応は疑い、自分の手元は信じる」の非対称を地で行った。分類器に止められた時は、素直に助かったと思った。
• レーン/媒体: 🔬Miyoki Labs（Zenn＝git履歴の認証情報を機械監査する手順とSHA-256突き合わせ／Qiita＝「追跡解除≠失効」とビルド成果物への.env焼き込み／note＝申告された経路の外側を疑うインシデント対応の話）
• tags: セキュリティ / git / 個人開発 / 調査手法
• series: -
• refs: Nompass\portal@b17b66d（.open-next/assets/server-functions/default/.env 混入）／Nompass\portal@1c3bdc2（追跡解除・履歴には残存）／個人\counter-app@4144ab8（sk_live_ を追跡解除・07-01／その後07-04に再発行済み＝ローテ済み）／Nompass\portal\.gitignore:34（現在は .open-next/ を除外済み）／Nompass\portal\src\proxy.ts（楽観チェックのみ・実検証は getServerSession() に一本化）／Nompass\portal\src\app\api\line\webhook\route.ts:34-41（timingSafeEqual の正しい実装）／Nompass\portal\src\lib\security\validate.ts（parseBody＝詳細を伏せた汎用400）
• ネタ度: ★★★
• ステータス: 素材（Neon/cron/Stripe すべてローテ完了・2026-07-09。漏洩値はすべて失効済みなので執筆可。記事化時は具体的な旧値・コミットの結びつきを出しすぎない配慮のみ）

「対応済み」と「計画に載っている」は別モノ——完了報告の後の一言でフォローが宙に浮くのを防いだ（2026-07-09）

• 出典: Miyokiワークスペース 2026-07-09（認証情報漏洩の対応完了報告の後、ユーザーの「やり残しなく完了していて、計画にも入ってる？」の一言から）
• 収集日: 2026-07-09
• 何が起きた/やった: 漏洩対応（ローテ3件・平文退避・vault/inventory新設）を「完了」と報告した直後、「計画にも入ってる？」と聞かれた。実地確認したら、作業のやり残しはゼロだが、残ったフォロー作業（Bitwarden移行して平文vaultを消す）は memory とユーザーの記憶にしかなく、計画\ のどこにも載っていなかった＝典型的な「次の週末に忘れて宙に浮く」経路だった。しかもこれはPC必須タスクなので、グローバルルール上は 現在地.md の「🖥️ 週末PC限定バッチ」に文脈込みで積むべきもの。そこで①現在地.md 週末バッチに1項目追加（次にPCを開くと必ず目に入る）②~\.secrets\secrets-inventory.md＝移行チェックリスト③memory＝場所の道しるべ、の三重で受ける形にした。「完了」の定義に「忘れずに再開できる導線があるか」まで含めた。
• 記事のフック（なぜ刺さる）: ①タスクの「完了」には2種類ある——その場の作業が終わった（done）と、続きが確実に再開される導線が引けた（tracked）。個人開発／AI協働では前者だけで満足して後者が抜ける。②AIに作業させると「memoryに記録しました」で終わりがちだが、memoryは人間の週次ルーティンには乗らない。人間が実際に開くファイル（週末バッチ／チェックリスト）に落とさないと消える。③"三重の受け皿"（実行導線＝週末バッチ／中身＝inventory／場所＝memory）で役割を分けると、1つが漏れても他で拾える。過去に何度も出ている「書いた/直したのに反映されない」ドキュメントdriftの、タスク管理版。
• その時の本音: 「全部閉じました、おつかれさまでした」と締めた直後の質問だったので一瞬ヒヤッとした。作業自体は本当に終わっていたが、「計画に入ってる？」がなければフォローは自分の記憶頼みで、週末には確実に忘れていた。完了報告のたびに"再開導線があるか"を自問する癖にすべきだと思った。
• レーン/媒体: 🔬Miyoki Labs（note＝AI協働のタスク管理・「done≠tracked」／Zenn＝Stop hookとknowledge-log運用の実装ログに絡めて）
• tags: 個人開発 / AI協働 / タスク管理 / ドキュメント設計
• series: -
• refs: 計画\現在地.md「🖥️ 週末PC限定バッチ」（追加した [秘密情報] Bitwarden項）／C:\Users\kiyom\.secrets\secrets-inventory.md／memory secrets-vault-location.md
• ネタ度: ★★
• ステータス: 素材

---

Buildテンプレのリファレンス調査 由来（2026-07-08）

整合チェックを全部通したのに、週末の自分がその手順書に辿り着けない設計だった（2026-07-08）

• 出典: Miyokiワークスペース 2026-07-08（/consistency-check 完了後、「実機テストの際に出てくるよね？」の一言で到達可能性の欠落が発覚）
• 収集日: 2026-07-08
• 何が起きた/やった: Buildテンプレの改修手順を build/docs/reference_rt-solutions.md §7 に実行可能な粒度で書き、Nompass/STATUS.md の週末バッチにも積んだ。/consistency-check で「参照実在性」「旧パス残存」「SSOT齟齬」を照合し、検出した8件（行番号ref のズレ・「未push」の嘘・テンプレ実数6種→7種 等）を全部直して残存ゼロを確認した。そこで「実機テストの際に出てくるよね？」と聞かれて調べたら、3つの起動フォルダのうち2つから辿り着けなかった。C:\Miyoki（ハブ 現在地.md に未記載）と C:\Miyoki\Nompass\build（build/CLAUDE.md から手順書へのリンクなし）。しかも週末に npm run dev を打つのはまさに build フォルダで、一番出てきてほしい入口で出てこなかった。原因は整合性プロトコルの「正（SSOT）→ ハブ → 波及先」のうち、正だけ更新してハブと波及先を飛ばしたこと。
• 記事のフック（なぜ刺さる）: ドキュメント整合チェックは「参照先が実在するか」を見るが、「そこへ辿り着く導線があるか」を見ていない。前者は壊れたリンクを検出でき、後者はリンクが存在しないことを検出できない（無いものは grep できない）。到達可能性は「入口（起動フォルダ・CLAUDE.md）を列挙して、各入口から目的地へ2ホップ以内で着けるか」を人が問わないと出てこない。AI向け指示書（CLAUDE.md）を持つ人ほど刺さる——AIは自分が読むファイルに書いていないものを読まないので、導線の欠落はそのまま「その情報が存在しない」と同義になる。
• その時の本音: 「残存ゼロを確認しました」と報告した直後だった。8件の齟齬を全部潰して満足していたところに一言で穴を開けられた。しかも齟齬8件は全部その日の自分の作業由来で、導線の欠落も自分がプロトコルの2ステップを飛ばしたせい。チェックリストを通すことと、チェックリストの項目が十分であることは別だと痛感した。
• レーン/媒体: 🔬Miyoki Labs（Zenn＝ドキュメント整合チェックに「到達可能性」を足す話／note＝AIに読ませる前提のドキュメント設計）
• tags: ドキュメント設計 / AI協働 / 整合性 / 個人開発
• refs: C:\Miyoki\.claude\skills\consistency-check\SKILL.md（Step 2 に到達可能性の観点がない）／C:\Miyoki\.claude\CLAUDE.md「整合性プロトコル」（正→ハブ→波及先）／Nompass\build\CLAUDE.md（導線を追加したコミット Nompass-Build-Template@4bd7ab5）／計画\現在地.md Nompass本体ブロック
• series: -
• ネタ度: ★★
• ステータス: 素材（/consistency-check スキル本体への Step 追加は別セッションで）

多層 .gitignore に騙されて、正しく動いている設定を「壊れている」と報告しかけた（2026-07-08）

• 出典: Miyokiワークスペース 2026-07-08（Buildテンプレ改修の完了確認中に knowledge-log の追跡状態を調べ、誤った結論を出してから自分で覆した）
• 収集日: 2026-07-08
• 何が起きた/やった: 「今日やれることは完了か」を確認する流れで、その日 00.Nompass/knowledge-log/ に書いた★★エントリがどのリポジトリに入るのかを確かめた。C:\Miyoki の .gitignore:3 が Nompass/ を、C:\Miyoki\Nompass の .gitignore:32 が Nompass Build/ を除外している。Nompass Build で git rev-parse --show-toplevel を打つと親の C:/Miyoki/Nompass が返る。00.Nompass 直下にも client-Nompass-hp 以外に .git はない。ここまでで「knowledge-log はどのリポにも入っていない＝ CLAUDE.md の『git管理下・バックアップあり』は嘘」と結論し、.gitignore に例外を切る提案までした。ところが .gitignore を書き換える直前、中身のサイズと機密混入を確認するため find . -type f を打ったら ./.git/config が出てきた。knowledge-log/ 自身が独立リポジトリ（miyoki-labs/nompass-knowledge-log・リモート・コミット履歴あり）だった。.gitignore の Nompass Build/ は「実装は別リポなので親からは追わない」という正しい設計で、意図どおり動いていた。69003e3 も追跡ファイルを1つも外しておらず、.gitignore に1行足して明示しただけだった。
• 記事のフック（なぜ刺さる）: 「検証したこと」と「検証範囲が正しいこと」は別という話。git ls-files も git check-ignore -v も git rev-parse --show-toplevel も、打ったコマンドは全部正しく、出力も全部正しかった。間違っていたのは.git を探す階層（00.Nompass 直下しか見ず、2階層下の knowledge-log/ を見なかった）。rev-parse は .git が無いディレクトリから親を返すので、入れ子リポの不在を証明したことにはならない。もう少しで、正しく動いている .gitignore を「修正」して壊すところだった。AIが自信満々に「確認しました」と言うときほど、確認範囲を疑うべきという実例にもなる（この誤りを出したのは Claude 自身）。
• その時の本音: 「git ls-files で確認しました」と報告した時点では本当に確信していた。.git/config が find の出力に紛れて出てきた瞬間、血の気が引いた。ユーザーが「特にない（除外した理由に心当たりがない）」と答えたのを「隠す意図はなかった」の裏付けだと解釈したが、実際はそもそも隠していなかった。手を止めて聞く運用にしていなければ、その日のうちに .gitignore を壊していた。
• レーン/媒体: 🔬Miyoki Labs（Zenn＝多層 .gitignore × 入れ子リポの調査手順と落とし穴／note＝AIの「確認しました」を人間がどこまで信じるか）
• tags: git / 調査手法 / AI協働 / 個人開発
• refs: C:\Miyoki\.gitignore:3（Nompass/）／C:\Miyoki\Nompass\.gitignore:32（Nompass Build/）／Nompass@69003e3（.gitignore 1行追加のみ・追跡ファイルの削除なし）／miyoki-labs/nompass-knowledge-log（knowledge-log の実リポ）
• series: -
• ネタ度: ★★
• ステータス: 素材

「動きが気持ちいい」他社サイトを分解したら、アニメーションライブラリを1つも使っていなかった（2026-07-08）

• 出典: 00.Nompass/knowledge-log/log.md 🔬レーン 2026-07-08（同名エントリ）／core.md 2026-07-08（続き13・続き14）
• 収集日: 2026-07-08
• 何が起きた/やった: 詳細は上記 log.md を参照（Nompass側が一次）。要点＝curl で生HTML＋CSS＋JSチャンク12本を落として grep したら framer-motion / GSAP / lenis すべてゼロヒット。正体は IntersectionObserver + CSS transition + rAF の手書きで、イージングは全箇所 cubic-bezier(.16,1,.3,1) の1種類のみ。一方 three.js は生で544KB、prefers-reduced-motion の記述はゼロ。Buildテンプレへは「採用12／保留5／不採用5」に仕分けて逆輸入し、tscもeslintもbuildも通ったのに SectionHeading の37箇所中29箇所が中央寄せで、左だけの横線が非対称になっていた（/quality-check の逆引きで検出）。
• 記事のフック（なぜ刺さる）: ①憧れのサイトの「気持ちよさ」はライブラリではなくイージングを1本に絞ったことだった ②同じサイトに544KBの3D装飾とa11y無視が同居している＝丸ごと真似してはいけない ③型もLintもBuildも通るのに見た目だけが壊れるという、自動検証の限界。「リファレンスから型を借りるときは、借りた先の使われ方の分布を先に数える」が教訓。
• その時の本音: grepが全部ゼロヒットで拍子抜けし、直後にthree.js 544KBを見つけて笑った。「1ファイル直せば37箇所に効く」と喜んだ直後に、その37箇所の内訳を見ていなかったのが恥ずかしい。
• レーン/媒体: 🔬Miyoki Labs（Zenn＝バンドルから他社サイトを分解する手順／Qiita＝IntersectionObserver + イージング1本で作るスクロールリビール）
• tags: フロントエンド / パフォーマンス / アクセシビリティ / 設計判断
• refs: Nompass\build\docs\reference_rt-solutions.md（採用12/保留5/不採用5の判断表）／Nompass\build\src\app\globals.css:45-117／Nompass-Build-Template@4058023・@3aa2fd9
• series: -
• ネタ度: ★★
• ステータス: 素材

Obsidianでワークスペースを可視化 由来（2026-07-08）

48万ファイルの作業フォルダを、ジャンクション6本と実況型トラブルシュートでObsidian化した（2026-07-08）

• 出典: Miyokiワークスペース 2026-07-08（「Obsidianに記憶を蓄積したら効率化するか」という相談から、実際にPC・スマホ両方でセットアップまで実施）
• 収集日: 2026-07-08
• 何が起きた/やった: C:\Miyoki（総ファイル数48万・node_modules含む）を直接Obsidian vault化するのは実用外と判明（起動が重すぎる）。代わりにC:\MiyokiVault\を新設し、計画ideasvoice-kit下書きoutputと、Claude Codeの記憶フォルダ（~\.claude\projects\...\memory\）だけをNTFSジャンクション（mklink /J相当）でリンクし、実体は動かさずvaultサイズを88件程度に絞った。スマホでも見たいという流れでモバイル同期を検討したが、①ジャンクションはクラウド同期サービスに追従されない、②remotely-saveプラグインのGoogle Drive対応は独自PRO会員限定（Obsidian本体の課金ではない）、③OneDriveは認証のブラウザ→アプリのハンドオフが2回とも「Something went wrong」で失敗、の3段階でつまずき、最終的にDropboxに切り替えたら一発で通った。さらに「Remotely Save has HUGE updates」という同意ダイアログに気づかず同意しないまま使おうとしたため、歯車アイコンもコマンドパレットの項目も一時的に消えるという不可解な状態にハマった（同意後に復活）。スマホ版はコマンドパレットがファイルの⋮メニューになく、設定の「モバイルツールバー」に明示的に追加する必要がある機種依存の罠もあった。あと一歩で、通話録音アプリ（CubeCallRecorder）らしき無関係フォルダをvault内のゴミだと誤認して削除するところだった。最後に、計画\現在地.mdのSSOT表をwikilink化してバックリンクを試したが、Obsidianの「未リンクの言及」機能はバッククォート（` ``）で囲んだファイル名を拾ってくれないことも実測で確認した。
• 記事のフック（なぜ刺さる）: 「ツールを1つ導入する」だけの話が、①巨大フォルダのvault化戦略（ジャンクション）②クラウド同期プラグインの有料/無料の罠③謎の同意ダイアログでプラグインが半壊する現象④モバイル特有のUI差異⑤あと一歩で他アプリのデータを消しかけた事故未遂、と5段階の実録トラブルシュートになった。個人開発者がドキュメント管理ツールを試す時に高確率で踏む罠を先回りできる内容。
• その時の本音: 「Obsidian入れて記憶を繋げよう」くらいの軽い気持ちで始めたら、想定の3倍くらい手戻りがあった。特に「HUGE updates」の同意ダイアログに気づかず歯車アイコンが消えたときは原因不明で一番焦った。スマホ側の検証はユーザーと画面共有しながらのラリーになり、こちらから見えない状態を都度言葉で推測して当てていく感覚があった。
• レーン/媒体: 🔬Miyoki Labs（Zenn＝ジャンクション×Obsidian vault設計の技術ログ／note＝個人開発の情報整理を試行錯誤する話）
• tags: 個人開発 / ドキュメント設計 / Obsidian / トラブルシュート
• series: -
• refs: C:\MiyokiVault\（ジャンクション構成）／C:\MiyokiVault\.obsidian\plugins\remotely-save\／計画\現在地.md（wikilink化した差分）
• ネタ度: ★★★
• ステータス: 素材

Nompassドキュメント再確認 由来（2026-07-08）

疑問に思った7点のうち4点は「決めていない」のではなく「すでに決めていた」と分かった（2026-07-08）

• 出典: Miyokiワークスペース 2026-07-08（Nompassについて雑メモ形式で7点の確認依頼→STATUS.md/CLAUDE.md/docs配下を読み返して回答）
• 収集日: 2026-07-08
• 何が起きた/やった: 「クロージングはLINE/メールで可能か」「Voiceは効果重視で継続すべき」「Miyoki各サイトの検出されやすさ」「Voiceを独立サービス化すべきか」「Map起点の差別化をもっと伝えたい」「toC展開時のポートフォリオ作成+コノハウィング差別化」「toB→toCのスケール計画」の7点を雑メモで確認依頼された。実際に21_service_agreement.md第2条（契約成立=ポータル同意のみ）、19_resource_model.md§1（クロージングは意図的に✅同期区分）、12_nompass_brand.md「真似できない理由：Mapという共通指針」、01_design_foundation.html（「すべては、ポータルで繋がる」）、19_resource_model.md§5（体制別キャパシティ）を読み返したところ、7点中4点はすでに明文化された設計判断として存在していた。本当の未着手ギャップは3点（Search Console/Bing Webmaster未登録・Voice独立化と有機的連携の設計思想の緊張関係・toCポートフォリオ+コノハウィング差別化の未記載）だけだった。
• 記事のフック（なぜ刺さる）: 「疑問に思ったことの大半は、過去の自分がすでにドキュメントに答えを書いていた」という体験。7問中4問という具体的な比率で「聞く前にまず自分のdocsを読み返す」習慣の価値を示せる。ドキュメント文化がない個人開発/小規模チームに刺さる。
• その時の本音: 質問を投げる前は「答えはどこにもない」と思っていたが、19_resource_model.mdの「クロージングは✅同期（契約の意思決定はテキストだと弱い）」のような1行にすでに明文化されていた。過去の自分が書いたドキュメントの厚みに、未来の自分が助けられた。
• レーン/媒体: 🔬Miyoki Labs（note＝個人開発のドキュメント文化／Zenn＝開発ログ）
• tags: 個人開発 / ドキュメント設計 / 事業設計
• series: -
• refs: Nompass\STATUS.md／Nompass\docs\operation\21_service_agreement.md第2条／Nompass\docs\operation\19_resource_model.md§1,§5／Nompass\docs\design\12_nompass_brand.md「真似できない理由」／Nompass\docs\design\16_future_service_lines.md
• ネタ度: ★★★
• ステータス: 素材

個人サイトの小さな試作が、本業側の「審査不要」という思い込みを正した（2026-07-08）

• 出典: Miyokiワークスペース 2026-07-08（個人\seo-insights\のGSC OAuth試作から、Nompass STATUS.mdの記載を見直した流れ）
• 収集日: 2026-07-08
• 何が起きた/やった: Miyoki個人のSearch Console連携を試作する過程で、テスト状態のOAuthアプリは本番運用（不特定多数のユーザーが使う状態）にはGoogleの検証（プライバシーポリシー提出等）が必要になりそうだと実地で分かった。この気づきをNompass側の計画に照らし合わせたところ、STATUS.mdのTrace Phase2に「GA4 OAuth連携（無料・審査不要）」と1行だけ書かれていた前提が、実は検証不要と言い切れない可能性があると判明。顧客向けの詳細フロー自体も未設計だったため、docs/design/19_trace_oauth_flow.mdとして要件を新規に書き起こした。
• 記事のフック（なぜ刺さる）: 「小さく試作してみる」ことの価値は「動くかどうかの確認」だけでなく、「大きい計画に書かれた前提が本当に正しいかの検証」にもなるという話。個人開発の実験が、本業側の計画ドキュメントの誤りを発見するきっかけになった、という順番の逆転が面白い。
• その時の本音: 「無料・審査不要」と自分で書いた記憶がある一行だったので、最初は疑わずに読み飛ばしかけた。実際に手を動かしてOAuthの「テスト状態」「本番状態」の違いにぶつからなければ、この思い込みにはずっと気づかなかったと思う。
• レーン/媒体: 🔬Miyoki Labs（note＝個人開発と本業を行き来する話／Zenn＝OAuth検証要否の技術メモ）
• tags: 個人開発 / API連携 / 事業設計
• series: -
• refs: 個人\seo-insights\gsc-report.mjs／Nompass\STATUS.md「Trace Phase2」／Nompass\docs\design\19_trace_oauth_flow.md
• ネタ度: ★★
• ステータス: 素材

Google Search Console API OAuth設定 由来（2026-07-08）

個人開発でGoogle Search Console APIを叩くまでにハマった3つの罠（2026-07-08）

• 出典: Miyokiワークスペース 2026-07-08（miyoki-labs.comの検索パフォーマンスを自動取得するスクリプト個人\seo-insights\gsc-report.mjsを作るためのOAuth設定作業）
• 収集日: 2026-07-08
• 何が起きた/やった: Google Cloud ConsoleでOAuthクライアントを作りOAuth Playgroundでリフレッシュトークンを取得する一連の作業で、3つの罠を順番に踏んだ。①デスクトップアプリ型では動かない：OAuth Playgroundはリダイレクト先https://developers.google.com/oauthplaygroundへの到達が必要だが、デスクトップアプリ型クライアントにはリダイレクトURI登録欄自体がなくredirect_uri_mismatchになる→ウェブアプリケーション型で作り直し、リダイレクトURIを明示登録して解決。②スコープ入力欄と検索欄を混同：Search Console APIはOAuth Playgroundのチェックボックス一覧に出てこないため「自分でスコープを入力する欄」を使う必要があるが、そこにsearch consoleという平文を入れてしまいinvalid_scope（invalid=[console, search]とスペース区切りで分解されて怒られる）→フルスコープURLhttps://www.googleapis.com/auth/webmasters.readonlyを入れて解決。③リフレッシュトークンは発行時のクライアントID/Secretとセット：①の作り直しで新しいクライアントに切り替わったのに、最初に控えていた（削除したはずの）旧デスクトップ型のClient Secretをそのまま使おうとしていたことにスクリプトを組む段階で気づいた。
• 記事のフック（なぜ刺さる）: Google公式ドキュメントには書いてあるはずの情報だが、実際に手を動かすと「クライアントの型」「スコープ入力欄の場所」「発行済みトークンがどのクライアントに紐づくか」の3点で個人開発者は普通に詰まる。特に③は見落としやすく、動かないままハマり続ける典型パターン。エラーメッセージのスクリーンショット付きで再現できる実録として価値が高い。
• その時の本音: リフレッシュトークンさえ取れれば終わりだと思っていたら、実際にスクリプトの.envを組み立てる段階で「あれ、このシークレットどのクライアントのだっけ」と気づいて手が止まった。動いた"ように見えた"ことと、正しい組み合わせで動くことは別だと再認識した。
• レーン/媒体: 🔬Miyoki Labs（Zenn＝OAuth設定のハマりどころ実録／Qiita＝「Search Console APIをOAuth Playgroundで叩く手順」の技術解説）
• tags: 個人開発 / API連携 / デバッグ
• series: -
• refs: 個人\seo-insights\gsc-report.mjs／計画\現在地.md「GSC連携」週末PCバッチ（Bing側は手動セットアップのみで自動化なし、と状態を明記済み）
• ネタ度: ★★
• ステータス: 素材

需要検証アクション化 由来（2026-07-08）

コネがゼロの専門家に「使ってみて」の反応を取りに行く、低コスト4ルート（2026-07-08）

• 出典: Miyokiワークスペース 2026-07-08（構築予定＝RAG本番化/税理士向けチャットボットの「実践以外にやれること」を洗い出す作業から）
• 収集日: 2026-07-08
• 何が起きた/やった: 「作る→確かめる」フェーズ（output/2026-07-03-需要検証と最初の一歩.md）の実践編として、税理士との面識が一切ない状態から反応を取りに行く方法を4段階に整理した：①X等で発信している当該専門家にリプ/DM ②知人ネットワークに「知り合いいませんか」と1投稿 ③商工会議所・青色申告会等の無料相談窓口（専門家と話せる公的な場） ④資格不問の異業種交流会・勉強会（connpass/Peatixで「AI×士業」等を検索、対等な立場で話しかけやすい）⑤最後の手段としてビザスク等の有料スポットコンサルで確実に1人捕まえる。無料〜低コスト→確実、の順で並べたのがポイント。
• 記事のフック（なぜ刺さる）: 「需要検証しろと言われても、見せる相手のアテがない」は個人開発者の詰まりどころの定番。「人脈がない」を言い訳にせず、資格不問の場・SNS発信者・公的無料窓口という3つの"タダで専門家に会えるチャネル"を具体的に言語化した点が汎用的に使える。
• その時の本音: 最初は「つながりがないから無理」で止まりかけたが、"資格を持ってなくても参加できる集まり"という切り口を足しただけで一気に選択肢が増えた。ハードルの正体は人脈ではなく「探し方を知らないこと」だった。
• レーン/媒体: 🔬Miyoki Labs（note＝個人開発の需要検証シリーズ／Zenn＝実践ログ）
• tags: 個人開発 / 需要検証 / 営業
• series: -
• refs: 計画\ロードマップ.md「SaaS構想（次の柱・温存）」着手条件／output\2026-07-03-需要検証と最初の一歩.md
• ネタ度: ★★
• ステータス: 素材

専用アプリを作らず「スマホでClaudeに話しかける」だけをヒアリング蓄積の受け皿にした（2026-07-08）

• 出典: Miyokiワークスペース 2026-07-08（父/母/税理士候補のヒアリングを蓄積する計画\需要ヒアリングログ.mdの設計）
• 収集日: 2026-07-08
• 何が起きた/やった: 「家族や税理士候補と話すときはPCが手元にないから、スマホから簡単に蓄積したい」という要望に対し、miyoki-post-deckのような専用モバイルフォームを新規開発する案ではなく、①会話直後にスマホのメモ帳/LINEキープ/音声メモへ整形せず一言だけ即メモ ②あとでそのメモをclaude.aiアプリ/ブラウザでClaudeに貼るだけで、その場で整形して需要ヒアリングログ.mdに追記、というゼロビルドの運用を採用した。開発コストゼロで今日から使える点を優先。さらに「溜めるだけで終わらせたくない」という要望を受け、蓄積したエントリを新規自動化なしで実装計画（プロジェクト棚卸し.md）／発信（seeds-miyoki.md）へ流す運用ルールを同ファイルに追記し、蓄積→活用までを1ファイルで閉じた。実際にプロジェクト棚卸し.mdの構築予定テーブルへ「需要検証状況」列を足し、ロードマップ.mdにも「優先順位は変えず隙間で並行収集する」と1行反映して、設計だけで終わらせず即日でループを1周させた。
• 記事のフック（なぜ刺さる）: 「スマホから蓄積したい」と言われると反射的に専用アプリ/フォームを作りたくなるが、個人開発者が本当に必要なのは「摩擦なく続けられる仕組み」であり、すでに使っているチャットAIとの会話自体をデータベースの入力インターフェースにすれば新規開発は不要、という判断の型。過剰実装を避けた具体例として汎用性が高い。
• その時の本音: 需要ヒアリングログ.mdを作った直後に「じゃあ次はスマホ入力フォームか」と考えかけたが、一呼吸置いて「今ある経路で足りるのでは」と立ち止まれたのが良かった。
• レーン/媒体: 🔬Miyoki Labs（note＝個人開発の意思決定シリーズ／Zenn＝ゼロビルド運用の実践ログ）
• tags: 個人開発 / 需要検証 / 自動化
• series: -
• refs: 計画\需要ヒアリングログ.md／計画\現在地.mdSSOT表
• ネタ度: ★★
• ステータス: 素材

ワークスペース監査・リファクタ 由来（2026-07-07）

巨大Reactコンポーネント9本を1セッションで分割した — sed移送・「行数≠優先度」・build検証・釣れた潜在バグ（2026-07-07）

• 出典: Miyokiワークスペース 2026-07-07（Nompass portal のリファクタ洗い出し→分割）
• 収集日: 2026-07-07
• 何が起きた/やった: portal大型コンポ9本を機械抽出で分割（VoiceGenerator 975→139／MapForm 2016→1496／MapHearing 881→566／MapView 878→545／MapPreview 764→446／ClientDetail 748→528／ContractsTab 618→515／VoicePortal 636→560／ProjectDetail 598→51）。全て挙動不変・tsc0・クリーンbuild EXIT0。再現可能な3つの型：①sed移送＝定義ブロックを sed -n 'a,bp' | sed -E 's/^(const|function|type|interface) /export \1 /' で別ファイルへ丸ごと移し本体は sed 'a,bd'＋import1行＝LLMのretype転記ミスを構造的にゼロ化。②行数≠優先度＝2000行のMapFormはuseState5の"静的データで太った型"で低リスク、975行のVoiceGeneratorはuseState28の"状態で太った型"で高難度＝規模でなく状態量で測る。③tscは必要十分でない＝npm run buildまで回して構造検証完了、失敗時はまず古い.nextキャッシュを疑う。
• 記事のフック（なぜ刺さる）: 「AIに大規模リファクタさせると転記ミスが怖い」への具体解＝sedで"移動"に徹すればLLMは書き写さない。加えて"重複コードは仕様のズレを隠す"実例（媒体ピッカー統合でsuggest側だけ欠けていた「予定」バッジが釣れた）。
• その時の本音: 最初はuseState28にビビったが、2000行のMapFormの方がむしろ楽だった。行数の見た目に判断を引っ張られる罠を実地で踏んだ。
• レーン/媒体: 🔬Miyoki Labs（Zenn=開発ログ「巨大コンポを1日で9本割った」／Qiita=技術「LLMで安全にリファクタするsed移送パターン」）
• tags: React / リファクタ / AI協働 / Next.js
• series: -
• refs: Nompass\portal\src\app\admin\clients\[id]\voice\VoiceGenerator.tsx＋同*Parts.tsx群／Nompass\portal\src\app\portal\map\form\{options,components,types}／knowledge-log history\core.md 2026-07-07（続き〜続き5）
• ネタ度: ★★★
• ステータス: 素材

ワークスペース全体を監査したら、技術より"導線"が本丸だった（2026-07-07）

• 出典: Miyokiワークスペース 2026-07-07（コード効率/セキュリティ/UX/サービス動線/SNS回遊の網羅監査）
• 収集日: 2026-07-07
• 何が起きた/やった: Miyoki⊃Nompass全体を監査。①セキュリティ＝portal 40ルートが自前の「4点セット」（認証/テナント分離/署名検証/SSRF/rate limit/エラー非漏洩）を実際に守れており堅牢、②投稿系＝「散らばっている」と思っていたが実態は🔬/🏢の意図的レーン分離（ネタ帳・voice-kit・deck・skillが2系統でも役割が被らない）で真の摩擦は"公開後の3点bookkeeping同期"だけ、③弱かったのは集客導線＝Miyoki個人受託の入口がmailto依存、SNS回遊は設計(07)秀逸なのに"Portfolio→Nompass主力事例"の◎核が空いてループ半開き。
• 記事のフック（なぜ刺さる）: 「負債はコードにある」と思って監査したら、コード・セキュリティ・整合はむしろ健全で、穴は"導線"という非コード領域だった逆転。個人開発者が"作る"に偏り"届ける導線"を後回しにする構造そのもの。「散らばりに見えるものが実は設計だった」の判定プロセスも汎用。
• レーン/媒体: 🔬Miyoki Labs（note=「一人で全部やる人の"監査"の話・技術より導線」／Zenn=監査の型）
• tags: 個人開発 / 監査 / 発信導線
• series: -
• refs: output\2026-07-07_ワークスペース監査_修正チケット.md／計画\07_アカウント接続.md
• ネタ度: ★★
• ステータス: 素材

ワークスペース再編・自動化 由来（2026-07-04 手動追記）

タブの絞り込みが「投稿済みアーカイブ」まで一律に効くと思っていたら、実は別領域として独立させる必要があった（2026-07-09）

• 出典: Miyokiワークスペース 2026-07-09（ユーザーが「note」タブで絞り込んだのに投稿済みのXスレッドが表示されて混乱、とスクショで報告）
• 収集日: 2026-07-09
• 何が起きた/やった: 発信デッキの媒体タブが「下書き」と「投稿済みアーカイブ」の両方の.card要素を無差別に対象にしていたため、フィルタ結果が直感と食い違って見えた。対策として、タブ自体をdata-scope属性で「下書きタブ（.activeareaが対象）」と「アーカイブ専用タブ（.archiveareaが対象・媒体は投稿済みの実績から動的生成）」に完全分離。JS側もdocument.querySelectorAll('.tabs')で各タブ群を独立に処理する設計に書き換え、混同の芽を構造的に断った。
• 記事のフック（なぜ刺さる）: 「1つのフィルタUIに、性質の違う2種類のデータ（進行中／完了済み）を混ぜて乗せると、ユーザーの直感と一致しなくなる」というUI設計の基本教訓。解決も「頑張って条件分岐を増やす」ではなく「そもそも領域を分ける」という設計変更で解消した点が汎用性高い。
• レーン/媒体: 🔬Miyoki Labs（Qiita＝UI設計Tips／Zenn＝開発ログ）
• tags: 個人開発 / UI設計
• series: -
• refs: 個人\miyoki-post-deck\generate.mjs（jsTabs・archTabsNav・.activearea/.archivearea）
• ネタ度: ★★
• ステータス: 素材

コミットしたのに一度もデプロイしていなかった——ポートフォリオのブログ導線が3日間本番に反映されずにいた話（2026-07-08）

• 出典: Miyokiワークスペース 2026-07-08（ユーザーから「ポートフォリオにアフィリブログへの導線が見当たらない」と指摘を受け調査）
• 収集日: 2026-07-08
• 何が起きた/やった: miyoki-portfolioの2026-07-05コミット「独自ドメイン(miyoki-labs.com)取得反映＋ブログへの導線追加」にはFooter/LinkTreeへのBlogリンク追加とドメイン更新が両方含まれていたが、そのコミット以降 npm run deploy が一度も実行されておらず、本番は3日前の状態のままだった。コードを読むだけでは気づけず、robots.txtのSitemap:・OGPのog:urlが旧ドメイン（miyoki-portfolio.pages.dev）のままである点と、本番HTMLに"blog"の文字列が1つもない点を突き合わせて「コードにあるのに本番にない」ことを実測で確定させた。デプロイ実行で即解消。あわせてLinkTreeの「Blog」項目の説明文が「AIツール紹介」という古い/狭い表現のままだった点（実際は4カテゴリ運営）も発見・修正。
• 記事のフック（なぜ刺さる）: 「git commitした＝反映された、ではない」という個人開発者が踏みがちな錯覚。過去に何度も出ている"ドキュメントdrift"（書いた/直したのに反映されていない）のデプロイ工程版。robots.txtのような普段見ない場所を手がかりに"実測で確定させる"調査プロセスも汎用性が高い。
• その時の本音: コードを読んだ時点では「もう直ってるはず」と思い込みかけたが、本番を実測してから「あ、これデプロイされてない」と気づいた。読むだけで確認したことにしてはいけない、を地で行った
• レーン/媒体: 🔬Miyoki Labs（Zenn=調査プロセス／Qiita=「コミット済み≠デプロイ済み」個人開発の運用Tips）
• tags: 自動化 / デバッグ / 個人開発
• series: -
• refs: 個人\miyoki-portfolio@5299642（未デプロイのままだったコミット）／src/components/layout/Footer.tsx／src/components/LinkTree.tsx
• ネタ度: ★★
• ステータス: 素材

媒体別テンプレ7本の棚卸し——「実際の生成契約」と「参考ドキュメント」が別々に進化して食い違っていた（2026-07-08）

• 出典: Miyokiワークスペース 2026-07-08（note/Qiitaのパーサーバグ対応の流れで、他のtemplates/*.mdも同じ食い違いがないか棚卸し依頼）
• 収集日: 2026-07-08
• 何が起きた/やった: voice-kit/templates/配下（Miyoki: zenn/qiita/x-thread、Nompass: zenn/qiita/x-thread/instagram）の計7ファイルが、実際に生成・deckがパースしている契約（## 投稿本文/## ハッシュタグ/## 画像プロンプト/## 補足の見出し構造）と食い違う旧仕様のまま放置されていた。原因は「実際の生成はAIが01_media_templates.mdの"出力の形"契約を直接踏襲して進化し続けた一方、templates/*.mdは初期に作った穴埋め例のまま更新されなかった」という2つの正が非同期に育ったこと。全7ファイルを実際の生成物（下書きファイル）の構造に合わせて書き直した。ブログ（microCMS直送）とGBP（自動化対象外）はdeckのパーサーに影響しないため対象外と判断。
• 記事のフック（なぜ刺さる）: 「実装は日々の試行錯誤で正しく進化するが、参考ドキュメントは"最初に作ったきり"で置き去りになる」というドキュメントdrift。このワークスペースで何度も繰り返し発覚しているパターン（07アカウント接続・ドメイン移行時の幽霊URL等）の、テンプレファイル版。「生成する側」の実践知が「教える側」のドキュメントに反映されない、という構図の一般化。
• レーン/媒体: 🔬Miyoki Labs（note＝AI協働運用のドキュメントdriftまとめネタの一部）
• tags: 自動化 / AI設計
• series: -
• refs: voice-kit\templates\（zenn/qiita/x-thread-template.md）／Nompass\Nompass Build\00.Nompass\voice-kit\templates\（同4種＋instagram-template.md）
• ネタ度: ★
• ステータス: 素材

「ハッシュタグは全部本文に畳み込めば安全」という思い込みが外れた——媒体ごとに専用タグ欄の有無が違った（2026-07-08）

• 出典: Miyokiワークスペース 2026-07-08（発信デッキの点検依頼で、ユーザーから「noteはハッシュタグが本文じゃなく別枠にある」と指摘）
• 収集日: 2026-07-08
• 何が起きた/やった: 直前の修正で「ハッシュタグは漏れ防止のため本文に畳み込む」という設計にしていたが、これはXのような専用タグ欄が存在しない媒体にしか当てはまらないルールだった。noteには投稿画面に本文と独立した「タグを追加」欄があり、Qiitaにも本文とは別の「タグ」入力欄がある（frontmatterのtagsで扱うのはそのため）。ここで媒体ごとに実際の投稿画面の仕様を洗い直し、generate.mjsのパーサーを「畳み込む（X・Instagram）」と「別枠のまま渡す（note・Qiita）」に分岐させた。ついでにQiitaは、frontmatterのtitle/tagsが本文の地の文に混ざって表示されていた（手動コピー時に生のfrontmatter行がそのまま見えてしまう）のも発見し、タイトル・タグ・本文を分離するよう修正。
• 記事のフック（なぜ刺さる）: 「1つの解決策（畳み込めば漏れない）を全媒体に一律適用したら、実は媒体ごとに前提が違って一部で誤りになった」という、マルチプラットフォーム対応の典型的な罠。「専用フィールドがあるかないか」で設計を分岐させる必要がある、という一般化可能な教訓。
• レーン/媒体: 🔬Miyoki Labs（Qiita＝マルチメディア対応のパーサー設計／Zenn＝前回の修正が実は不完全だったと分かった経緯）
• tags: 自動化 / 個人開発
• series: -
• refs: 個人\miyoki-post-deck\generate.mjs（parseDraft・PKIND）／voice-kit\01_media_templates.md／Nompass\Nompass Build\00.Nompass\voice-kit\01_media_templates.md
• ネタ度: ★★
• ステータス: 素材

「抽出したのに元データから消し忘れる」パーサーバグ——発信デッキのnote本文に画像プロンプトが混入していた（2026-07-08）

• 出典: Miyokiワークスペース 2026-07-08（note運用診断の続きで、ユーザーから「note本文に画像プロンプトが入る」「ハッシュタグの用意がない」と指摘を受け調査）
• 収集日: 2026-07-08
• 何が起きた/やった: 個人\miyoki-post-deck\generate.mjs の parseDraft() が ## 画像プロンプト セクションを正規表現で抽出はするが、元の本文（mainPart）からは削除していなかった。セクション境界を判定する WRAP 正規表現に「画像プロンプト」が含まれていないため、splitSections() が前のセクション（投稿本文やハッシュタグ）の一部として画像プロンプトの見出しごと巻き込んでしまい、本文コピー欄に画像プロンプトが二重に表示されていた。同じ構造を持つNompass Instagramの下書きでも、ハッシュタグ欄に画像プロンプトが混入する形で同じバグを確認。原因調査後、抽出した範囲を mainPart から実際にスライスして除去するよう1行追加して解消（if (imgM) mainPart = mainPart.slice(0, imgM.index) + mainPart.slice(imgM.index + imgM[0].length)）。ビルドし直して本文・ハッシュタグ・画像プロンプトが正しく分離されることを実機（生成HTML）で確認。
• 併せて、voice-kit/01_media_templates.md が「ハッシュタグはXのみ」とnoteを対象外にしていた制限も発見・是正（noteも3〜5個のハッシュタグ対象に）。templates/note-template.md（Miyoki/Nompass両方）も実際の生成契約（## 投稿本文/## ハッシュタグ/## 画像プロンプト/## 補足）とズレた旧仕様のままだったので更新。
• 記事のフック（なぜ刺さる）: ①「正規表現で情報を抽出したのに、元データから消すのを忘れる」は個人開発のパーサー実装で誰もが踏む地雷（抽出と削除は別処理という思い込みの穴）。②症状（本文に余計な文字列が混じる）から原因（セクション境界の判定漏れ）を1つずつ切り分けて特定する調査プロセスがそのまま書ける。③「ルール文書（生成契約）が古いテンプレファイルと食い違っている」というドキュメントdriftの再発——過去にも何度も出ているワークスペースの持病だが、今回は実害（バグ）を伴った初のケース。
• その時の本音: バグ報告を受けて最初はテンプレファイルだけ疑ったが、実際に生成されたHTMLをnode -eで覗いて初めて「抽出後に消していない」という一行の欠落に気づいた。コードを読むだけでなく実際の出力を見ないと分からないバグだった。
• レーン/媒体: 🔬Miyoki Labs（Qiita＝パーサー実装のTips・正規表現でのセクション抽出の罠／Zenn＝調査から修正までの経緯）
• tags: 自動化 / デバッグ / 個人開発
• series: -
• refs: 個人\miyoki-post-deck\generate.mjs（parseDraft関数・修正前後）／voice-kit\01_media_templates.md／voice-kit\templates\note-template.md
• ネタ度: ★★
• ステータス: 素材

生成の自動化が投稿頻度の想定を追い越した——「作れる量」と「出すべき頻度」を切り分けた運用判断（2026-07-08）

• 出典: Miyokiワークスペース 2026-07-08（Nompass/Miyoki同時運用の投稿計画づくり）
• 収集日: 2026-07-08
• 何が起きた/やった: 毎日21時のクラウドルーチンが🔬🏢両レーン分の下書きを自動生成するようになった結果、voice-kit/03_posting_workflow.md等の運用ドキュメントが前提としていた「週1でまとめ生成」という古い想定と、実態の生成量が大きくズレていた。ここで「生成量が増えた＝投稿頻度を上げるべき」と短絡せず、ボトルネックが生成ではなく人間のレビュー（事実確認・景表法チェック）にある媒体（Zenn/Qiita/note）は頻度を上げず、レビュー負荷が軽い媒体（X単独投稿・Nompass noteのノウハウ系）だけ余剰供給を頻度増に転換する、という切り分けをユーザーと合意した。
• 記事のフック（なぜ刺さる）: 「自動化を導入すると、つい"作れる量まで出す"に飛びつきがちだが、実際のボトルネックが別の工程（人間のレビュー）にあるなら、供給が増えても頻度を上げるべきではない」という自動化運用の判断軸。個人開発・一人運用で自動化を進める人全般に刺さる普遍的な教訓。
• レーン/媒体: 🔬Miyoki Labs（note＝一人で事業・発信を回す判断軸／Zenn＝自動化運用の設計判断）
• tags: 自動化 / 事業設計
• series: -
• refs: 個人\miyoki-post-deck\generate.mjs（schedule定義）／voice-kit\03_posting_workflow.md／計画\05_コンテンツ計画.md（運用リズム節）
• ネタ度: ★
• ステータス: 素材（各論の反応が出てから再評価）

knowledge-log の Stop hook が並行セッションで鳴り止まない——mtime基準の staleness 検知を、フック本体を読んで特定

• 出典: Miyokiワークスペース 2026-07-06〜07（発信ハブ構築セッション × ブログ実装セッションの並行時）
• 何が起きた: check-knowledge-log.ps1（Stop hook）が停止のたびに発火し続けた。最初は誤検知と決めつけて2回スルーしたが、フック本体を読むと判定は単純で「src配下の最新ファイル mtime > 履歴の最新 mtime かつ6時間以内なら発火」。実際に mtime を比較したら、もう1つのセッションが同じ miyoki-blog（Eyecatch.astro 等）を1分前に編集していた＝誤検知ではなく、他セッションのsrc更新が履歴を追い越し続けていた。自分の作業を全部記録しても、並行編集が動く限り鳴る。stop_hook_active のループガードはあるが、実ファイルが動き続けると別。
• 記事のフック（なぜ刺さる）: ①「Stop hook の staleness を mtime で見ると、並行セッション/リンター/dev server のファイルtouch で誤爆する」という Claude Code hooks 運用の落とし穴。②対処＝鳴ったら憶測で履歴を水増しせず、フック本体を読んで判定条件を確認（＋mtime実測）するのが正解。③"推測より観測"の実例（2回スルー→実測で真因）。
• その時の本音: 「誤検知」と2回言い切った自分が、mtimeを見た瞬間に間違いだと分かった。ハンドラを読まずに挙動を語ってはいけない
• レーン/媒体: 🔬Miyoki Labs（Zenn=Claude Code hooks運用の落とし穴／自動化デバッグ）
• tags: 自動化 / デバッグ / AI協働
• series: -
• refs: .claude/hooks/check-knowledge-log.ps1（判定ロジック＝src/history の mtime 比較・6h窓・stop_hook_active ガード）
• ネタ度: ★★
• ステータス: 素材

発信下書きを「スマホから確認・コピペ投稿」するデッキを依存ゼロのNode生成静的＋CF Pagesで作った

• 出典: Miyokiワークスペース 2026-07-06（個人\miyoki-post-deck 新規・計画=計画\プロジェクト別\miyoki-post-deck.md/nompass-post-deck.md）
• 収集日: 2026-07-06
• 何が起きた/やった: 「チャット（Claude Code）を開かないと下書きを確認できない」を解消するため、下書き\Miyoki-Labs\{Zenn,Qiita,note,X} を読んでコピーボタン付きモバイルHTMLを生成するデッキを作った。設計判断が3つ：①stateful SPA+KVではなく生成静的にしてバックエンドを消し、状態は既存の記事キュー.md/公開台帳.mdに持たせた（「絞る」）。②依存ゼロ（Node組み込みのみ）でCIでも動く。③Nompass版と完全分離（別リポ/別ドメイン/別データ源/別ブランド）で混同を防ぐ。詰まった点＝下書きの## 投稿本文を``md`で囲った中に入れ子のコードfence（`bash等）があり、素朴なfence正規表現が誤爆して1記事が6分割された。##セクション境界ベースのパース＋外皮fenceだけ剥がす方式に変えて解決。Xは連投をN/`マーカーでツイート単位のコピーに分割。
• 記事のフック（なぜ刺さる）: ①「個人開発者が自分の運用UIを最小コストで作る」実例（SPA+DBに行かず生成静的で足りる判断）。②Markdownの入れ子コードfenceをどうパースするかは地味に需要がある実装ネタ。③"スマホ運用前提の自作ダッシュボード"という切り口。デプロイ（CF Pages＋Cloudflare Accessで限定公開）まで通したらセットで記事化できる。
• その時の本音: 最初にSPA+KVを考えたが、状態は既にmdファイルが持ってると気づいて一気に軽くなった。作り込む前に「その状態、どこかに既にない？」を問うと絞れる。
• 追記（2026-07-06・パースの罠2段）: ①## 投稿本文を``md`で囲った中にさらに##見出しがあると、素朴なsplit(/^##/m)が記事本文を最初の見出しで切ってコピー本文がtruncateした→「ラッパー見出し（投稿本文/固定ポスト本文/…）だけで分割」に変更。②外皮fence剥がしは入れ子コードがあるとnon-greedyが最初の`で閉じてしまう→全体が1fenceのときだけgreedyで最後の``まで取る二段構えに。この手のバグは"生成物の文字数を実測"して初めて発覚した（見た目は1パートで正常に見えた）＝出力を数える検証の大事さ。あわせてvoice-kitに「各媒体は常に理想構成・文字数を目指す」運用ルールを追加し、当日の下書き5本を目標レンジに調整。
• レーン/媒体: 🔬Miyoki Labs（Zenn=個人運用UIの作り方と設計判断／Qiita=Markdown入れ子fenceのパースと「出力を数える」検証）
• tags: 制作記 / 個人開発 / 発信
• series: -
• refs: 個人\miyoki-post-deck\generate.mjs（splitSections/stripOuterFence/splitTweets）／個人\miyoki-post-deck\README.md／計画\プロジェクト別\miyoki-post-deck.md
• 発信デッキ→"発信オペレーションの司令塔"へ進化（2026-07-07）: 単なる下書きビューアから、確認〜投稿〜学習の一気通貫ツールに拡張。①投稿フィードバックのバックエンド＝Cloudflare Pages Function（/api/posted）＋KVで、UIの「✅投稿したら送る」から実際の投稿内容を送信→私がGETで読んで原案との差分から"鼻に付く言い回し"を学習＋posted/へアーカイブ→KVクリア。②投稿の認知負荷を下げる整形＝ハッシュタグを本文と同じフィールドに畳み込み（漏れ防止）／noteのタイトルを別コピー／note・IGは画像プロンプト＋流用案内を提示／スレッドの1/4分割＆番号マーカー除去。③投稿済みは折りたたみアーカイブに分離。詰まり＝PagesがバインドするKV物理名前空間がCLIのnamespace-idと不一致→読み書きはFunction経由に統一（GET/DELETE）、put直後getは結果整合で最大60秒ラグ。記事フック追加＝「静的サイト＋Pages Function＋KVで"自分専用の投稿×学習ループ"を最小構成で作る」。
• 投稿レイヤーPhase2＋同時編集の競合対応（2026-07-07）: ①Qiita投稿ボタンを実装＝functions/api/post/qiita.js がfrontmatter（title/tags/private・YAMLリスト＆インライン両対応）を解析してQiita APIへ投稿。UIは未投稿カードに「限定共有/公開」2段階確認ボタン。**設計の肝＝実トークン(QIITA_TOKEN=secret)未設定なら安全なno-op、共有トークンは弱く本命の保護はCloudflare Accessが/api/*ごと守る。入力バリデーションをトークンチェックより前に置き、壊れた入力は400・未設定は500 no-opに整理。②バグ＝microCMS本文の"等HTMLエンティティが未デコードで表示&コピーに混入（htmlToTextがタグ除去だけでエンティティを残していた）→デコード追加。教訓＝外部HTMLの「タグ除去」はプレーン化ではない。③並行セッションとの競合＝作業中に別セッションが同じgenerate.mjsへ/api/posted（投稿ログKV）を追記していて、Edit衝突とファイル差し替えで発覚。mtime変化＋機能出現から同時編集を検知→ユーザーが他セッション終了＆引き継ぎ書作成→既存のPOST_TOKEN/auth()パターンに相乗り**して重複宣言を回避。記事フック＝「同一リポを複数Claudeセッションで触るときの競合検知と合流のやり方」＋「投稿APIをAccessで守る前提のno-op設計」。
• 記事生成(self-post)の出力とデッキの読み場所がズレて"孤児下書き"になっていた→継ぎ目を統一（2026-07-07）: /self-post は knowledge-log\drafts\ に保存する一方、デッキは 下書き\Miyoki-Labs\<媒体>\ を読む設計で、両者が繋がっておらず、生成した技術Zenn 3本がデッキに一切出ない孤児になっていた（ユーザーが「どこに出てくる？UI？」で発覚）。対処＝①self-postスキルの保存先をブランド文脈で振り分ける形に変更（Miyoki→下書き\Miyoki-Labs\<媒体>\／Nompass→voice-kit\output\<媒体>\draft\＝どちらもデッキが読む場所）、旧knowledge-log\drafts\は廃止。②孤児3本を下書き\Miyoki-Labs\Zenn\へ移動、log.mdのステータス参照も更新。③再生成→npx wrangler pages deployで本番反映（Miyoki 10→13件・本番確認）。記事フック＝「"生成する側"と"見る側"でファイルの置き場が違うと、成果物が静かに消える」パイプラインの継ぎ目の設計ミス。個人開発で複数の自作ツール（記事生成スキル×閲覧デッキ）を繋ぐときの定番の落とし穴。地味な学び＝.htmlはCF Pagesで拡張子なしURLへ308リダイレクトするのでcurlは-L必須（無しだと空bodyで誤検証しかけた）。
• ネタ度: ★★
• ステータス: 素材（2026-07-06デプロイ済み＝https://miyoki-post-deck.pages.dev・--branch mainで本番200確認。2026-07-07に投稿FBバックエンド追加。記事化はCloudflare Access＋独自ドメインまで通してから）
• 引き継ぎ1枚（セッション作り直し用）: 計画\引き継ぎ\2026-07-07_発信デッキとアカウント始動_進捗.md（デッキ全機能＋投稿FB運用＋7/7始動＋並行セッションとの住み分け）
• 発展（2026-07-06）: 単一デッキ→マルチページの「発信ハブ」に拡張（index=プロジェクト選択／miyoki.html・nompass.html＝各プロジェクトのみ＝混同なし）。各ページに週間おすすめ投稿カレンダー（03_posting_workflow.md/posting-calendar.mdの標準スケジュールを週グリッド化＋「▶次に出す下書き」を枠に割当）を追加。設計判断＝「2つ別々にデプロイ」案を私的ツールなら1アプリ＋ページ分離で十分と絞った（公開ブランドの分離とは別問題＝Access保護の内部管理画面だから混同しない）。記事フック追加＝"個人の発信オペレーションを1画面に畳む設計"。
• アカウント始動の準備（2026-07-06→7/7 19:00始動）: 発信ハブを使い、Miyoki Labs＋Nompassの両ブランドを7/7(火)19:00に一斉始動する準備。方式＝X/note/IGは純正予約・Zenn/Qiitaは当日手動。足りていなかったNompass始動コンテンツ（X始動スレッド・Instagram始動投稿）を新規作成（00.Nompass/voice-kit/output/{x,instagram}/draft＝デッキに反映）。既存資産＝profiles.mdのbio群を活用（無駄なく）。始動ランブック（ideas/2026-07-07_アカウント始動ランブック.md）でSTEP0事実チェック→bio→予約→当日手動を手順化＝「確認と投稿だけ」で回る形に。記事フック＝"個人＋事業の複数アカウントを1日で立ち上げる段取り"。★1（運用ログ）。
• 無駄なく運用への軌道修正（2026-07-06）: Nompass側を「ゼロから下書き量産」しかけたが、ユーザーに「無駄なく運用が方針では」と指摘され修正。既存資産＝microCMSの記事（content_dashboard.pyが取得していた公開ブログ/下書き）を、そのロジックをgenerate.mjsへ移植してデッキに取り込む方向に。Node22のglobal fetchで microCMS news API を叩き、.env.localのキーはローカルのみ・出力HTMLに焼かない（漏洩チェック済み）。既存2記事（公開1＋下書き1）＋「サイトで見る/microCMS編集」導線が本番稼働。教訓＝"作る前に既にある資産を探す"＋"1ネタ→多媒体のリレーで使い回す"が無駄なく運用の芯。記事フック追加＝AI協働だと「生成」に手が伸びがちだが、既存を活かす方が速く強い。

LINE無料診断リンクが「text=無料診断…」で開く——oaMessageは ? 以降を丸ごと本文にする（2026-07-07）

• 出典: Nompass client-Nompass-hp 2026-07-07（nompass.jp/line＝LINE oaMessageへ302／記録の母艦=00.Nompass/knowledge-log/history/lp.md）
• 収集日: 2026-07-07
• 何が起きた/やった: nompass.jp/line をタップするとLINEの事前入力メッセージが「text=無料診断を申し込みたいです」と先頭に text= 混入で入っていた。原因＝https://line.me/R/oaMessage/{id}/?{msg} は ? 以降のクエリ文字列を丸ごとメッセージ本文にする仕様で、?text=… の key=value 形式は解釈されない。text= を外し ? 直後にエンコード文字列を置く形へ3ファイル（302実体 route.ts／発信SSOT links.json／出典doc line-setup.md×2）修正→push→Cloudflare Pages反映を 302 Location で機械確認。別ブランチの worktree 同ファイルも同期。
• 記事のフック（なぜ刺さる）: ①「LINEの事前入力リンク(oaMessage)で ?text= と書くと本文に text= が混ざる」は検索需要のある地味なハマり。②同一URLが3箇所（実体・SSOT・出典doc）に散っており漏れなく直す＝"実体と出典を両方直す"整合の型。③CV導線のバグは静かに転換を削る→出したら Location で確認する検証の大事さ。
• tags: LINE / 外部連携 / デバッグ
• series: -
• refs: client-Nompass-hp/src/app/line/route.ts:6／00.Nompass/voice-kit/links.json:7／client-Nompass-hp/docs/line-setup.md:13,183
• ネタ度: ★★（🔬Qiita＝技術Tips）
• ステータス: ドラフト済み（→下書き\Miyoki-Labs\Qiita\2026-07-07-line-oamessage-text-prefill.md｜deck掲載）本番反映済み。投稿は③リレーの時系列位置（07-07＝末尾寄り）で＝先出しはしない

発信立ち上げの計画整合＝横断ハブに「🖥️週末PC限定バッチ」欄を新設（記録メモ・2026-07-07）

• 出典: Miyokiワークスペース 2026-07-07（post-deck Phase2実装後の整合）
• 何が起きた/やった: 承認ダッシュボード(miyoki-post-deck)がコード完成・週末反映待ちになったのに、横断ハブ 現在地.md は「①承認ダッシュボード開発(着手前)」表記のままだった（drift）。①の状態を「コード完成・Access待ち」に更新し、グローバルルールが求める 🖥️週末PC限定バッチ欄 を 現在地.md に新設して週末タスク(Access→token→deploy・順序厳守)を文脈込みで集約。プロジェクト計画側(miyoki-post-deck.md 次の一手)と二重で揃えた。
• 記事のフック: "完了済みなのに未着手表記"driftの再発。PC必須タスクは横断ハブの1欄に集約しないと分業運用で落ちる。★1（運用ログ）。

投稿作成の優先順位を基幹ルール化＝時系列基本＋（時流/緊急/重要）先出し（記録メモ・2026-07-07）

• 出典: Miyokiワークスペース 2026-07-07（self-postを汎用性で1本先に作ったのを機に、Miyoki指摘で基幹化）
• 何が起きた/やった: /self-post を「汎用的なネタ」で選んで先に1本ドラフト化したところ、Miyokiから「投稿化は基本時系列（続き物/シリーズが見込める）／例外はいち早く出すべきもの(時流・緊急・重要)だけ先出し、を共通ルールにしたい」と指摘。🔬🏢共通の基幹ルールとして .claude\CLAUDE.md「昇格ネタを投稿化する順番」に明文化＋ideas\記事キュー.md 冒頭ルールを3基準に具体化＋self-post スキルの選定を「★最多・新しい方」から時系列優先＋先出し例外へ是正（スキルが基幹と矛盾していた）。あわせてRule2＝投稿推奨日を作成日ベースから媒体別スケジュールの逆算に変える受け皿を miyoki-post-deck.md に設置（媒体別スケジュール確定待ち）。
• 記事のフック: ①スキル/SSOT/CLAUDE.mdが同じ「順番」を別々に定義していて矛盾していた＝"正を1つにして参照させる"整合の型。②AIに任せると「汎用性/新しさ」で選びがち→人の運用意図(時系列でシリーズ化)とズレる。判断基準を言語化してルール化する価値。★1（運用ログ・note「一人運用のルール設計」素材）。

Claude.aiルーチンの選定ロジックが基幹ルールと矛盾＋毎日21時・自動リレー生成＋deckダッシュボードまで拡張（2026-07-07）

• 出典: Miyokiワークスペース 2026-07-07（上記ルール確定の直後、Miyokiが「Claude.aiのルーチンも同じ判断か」「古いルール残ってないか」を確認依頼）
• 何が起きた/やった: RemoteTriggerでスケジュール済みルーチンを監査→「記事ドラフト自動ストック」(週次金曜)が★最多優先という古いロジックのままと判明（基幹ルール確定前のプロンプトが残存＝ドキュメントだけ直してもクラウド側の実行体は別管理で追従しない、という盲点）。時系列＋先出し例外に修正。さらにMiyokiから「🔬🏢共に毎日21時生成＋各投稿（リレー全媒体）も＋反映先は常にdeck＋新着が分かるダッシュボード」の追加依頼。技術的制約＝クラウドルーチンはGitHub pushしかできずローカルC:\Miyokiに直接書けないことを先に明示し、AskUserQuestionで橋渡し方式(deckビルド時git pull／推奨)と生成範囲(1ネタ→リレー全媒体一括／推奨)を確認してから実装。
• Miyokiルーチンを毎日21時cronに変更＋レーン/媒体欄の全媒体を個別記事化＋各記事にX告知スレッドを追加生成するプロンプトに全面書き換え（保存フォーマットをself-post由来の## 投稿本文/## スレッド見出し規約に厳密準拠させ、deck側の既存パーサを無改修で再利用できる設計にした＝新形式を教えずファイル生成側を既存契約に合わせる判断）。
• 🏢Nompass用ルーチンを新規作成（同cron・同knowledge-logリポのdrafts/nompass/に出力・景表法配慮を文体ルールに明記）。
• miyoki-post-deck/generate.mjs：ビルド時にgit pull --ff-onlyでknowledge-logの実体をtry/catch非致命的に取り込み→drafts/・drafts/nompass/をファイル名末尾（-zenn.md/-x-thread.md等）から媒体推定して読み込む「橋渡し」を実装。.deck-state.json（gitignore）で前回ビルドとの差分を検知し「🆕新着」バッジ＋ページ上部ダッシュボードボックス＋ハブの新着件数を表示。ダミーファイルでZenn記事パース・Xスレッド3分割・新着検知→2回目ビルドで消える、まで実地検証。
• 記事のフック: ①「ルールをドキュメントで直しても、それを実行する自律エージェント(クラウドルーチン)は別途更新しないと乖離する」という運用の盲点＝ルールの正とその実行主体が分離している時の同期問題。②「クラウド実行環境はローカルファイルに書けない」という制約から、新形式を教えるのではなく既存パーサの契約に出力側を合わせるという設計判断（Postel's law的な発想の実例）。③RemoteTrigger APIでスケジュール済みエージェントを監査・修正する具体的な操作例。
• tags: 自動化 / Claude Code / 運用設計
• series: -
• refs: RemoteTrigger（trig_014Yc7hairF8N3JsrZX9ABRb＝🔬毎日21時／trig_01Phdvj9X6rPkzKtSzowaqu7＝🏢毎日21時）／個人\miyoki-post-deck\generate.mjs（gitPullSafe/loadSeenState/autoMediaFromFile）
• ネタ度: ★★（🔬Zenn=開発ログ・判断の経緯）
• ステータス: 素材（ルーチン初回実行は翌21:00・deck反映はnpm run deploy後）

スマホ運用の「簡単な構築タスク」探しが空振る真因＝ロードマップのdrift（記録メモ）

• 出典: Miyokiワークスペース 2026-07-06（3プロジェクト横断で「スマホで進められる構築」を仕分け→整合チェック修正）
• 収集日: 2026-07-06
• 何が起きた/やった: 平日スマホで着手できる構築タスクを探したら、「簡単候補」の多くがロードマップ/HANDOFFで未着手表記のまま実は完了済みだった（voice-kitテンプレ7種・ポートフォリオ/links）。加えて「自動投稿表記の復活」は自動連携の実装が前提の*未来条件付き*タスクで、今やると誇大表示になる罠。実際に着手できたのは Nompass dead code削除（/api/auth/create-profile＝src参照ゼロを確認）と、ドキュメントdrift解消（/consistency-checkで3点：ロードマップP1-3に✅／HANDOFFテンプレ行整理／引き継ぎのarticle-seeds→seeds-*注記）のみ。
• 記事のフック（なぜ刺さる）: 「TODOリストは放置すると"完了済みなのに未着手表記"で腐る＝探すたび空振りする」。スマホ/PC分業のような細切れ運用ほど、実態と計画のdriftがコストになる。単体は★1だが、note向け「一人開発のドキュメント運用」まとめの素材。
• 続き（miyoki-blog棚卸し・同セッション）: blogも同じ構図で、MVP必須（タグ/関連記事/TOC/著者/ページネーション/CTA差替/アフィリUI/slug）は全て実装済みなのに「MVP残」と認識していた＝drift。実際に残っていた構築は deployスクリプトの --branch main 焼き込み（本番404の恒久対策・宿題消化）だけ。なお「schema↔pipeline契約が未整合」と最初は書いたが調査したら整合済みで誤認だった（実装本体content.config.tsの古いコメントを鵜呑みにした二次drift）。drift記述を"未整合"と信じるとさらに無駄改修を生む、の実例。
• レーン/媒体: 🔬Miyoki Labs（note=開発の進め方・ドキュメント運用）
• tags: 事業設計 / AI協働
• series: -
• SSOT追随（同セッション末）: 棚卸しSSOT 計画\プロジェクト棚卸し.md に、公開済みなのに未記載だった miyoki-blog（公開中） と 本番 miyoki-portfolio（稼働） を追記（旧scaffoldはアーカイブ待ちへ整理）。出荷済みプロダクトが棚卸しから抜ける、も同じdrift族。
• refs: 計画\ロードマップ.md P1-3／Nompass\Nompass Build\00.Nompass\HANDOFF.md／Nompass\portal\src\app\api\auth（create-profile削除済み）／Nompass\portal\CLAUDE.md（S0行・Better Auth接続節）／個人\miyoki-blog\package.json（deploy --branch main）／個人\miyoki-blog\src\content.config.ts（pipeline整合コメント訂正）／個人\miyoki-media-pipeline\src\components\steps\Step6Export.tsx（buildFrontmatter＝整合の実体）／計画\プロジェクト別\miyoki-blog.md／計画\プロジェクト棚卸し.md
• ネタ度: ★
• ステータス: 素材（各論は昇格対象なし）

「作る→確かめる」を初実践：実機通し1セッションで不具合5件が炙り出された（記録メモ）

• 出典: Miyokiワークスペース 2026-07-05（pipeline実機通し→ブログ初記事公開。計画\現在地・プロジェクト別\miyoki-media-pipeline 更新）
• 収集日: 2026-07-05
• 何が起きた/やった: 「フル稼働テスト成功」と記録されていたpipelineを実機で通したら、配信（古いdist）・生成切れ（maxTokens）・書き出し先（再編の置換漏れ）・ゲート設計（採点張り付き）・捏造注入の5件が1セッションで発覚。個別の技術ネタは各プロジェクトの log.md に★★〜★★★で昇格済み（pipeline×3・blog×1）。ワークスペース視点の学びは「"テスト成功"の記録は成功した経路しか保証しない。公開という実ゴールまで通すと別の不具合層が出る」。計画側はゲート暫定70・APIチャージ・採点再調整を次の一手として記録。
• 記事のフック（なぜ刺さる）: 単体では★1（各論は昇格済みネタが本体）。「作る→確かめる」フェーズの実践記としてnote向けまとめ記事の素材になる
• レーン/媒体: 🔬Miyoki Labs（note=働き方・開発の進め方）
• tags: AI設計 / 事業設計
• series: -
• refs: 個人\miyoki-media-pipeline\knowledge-log\history\main.md 2026-07-05／個人\miyoki-blog\knowledge-log\history\main.md 2026-07-05／計画\プロジェクト別\miyoki-media-pipeline.md
• ネタ度: ★
• ステータス: 素材（各論は log.md 昇格済み）

「記録漏れを防ぐフック」自身が$ErrorActionPreferenceで記録漏れを起こし、無限ブロックした話

• 出典: Miyokiワークスペース 2026-07-04（check-knowledge-log.ps1・Stop hook暴走対応）
• 収集日: 2026-07-04
• 何が起きた/やった: 計画\07_アカウント接続.mdを編集したが対応するideas\側の記録を更新し忘れ、Stop hookが「記録漏れ」を検知してexit 2でブロック→Claude Codeが再試行→毎回同じ理由でブロック、を9回繰り返してハーネスの安全装置（stop_hook_active上限）が発動してようやく止まった。原因調査で判明したのは二重の不具合：①スクリプト冒頭の$ErrorActionPreference = "SilentlyContinue"がその後のWrite-Error自体の出力まで握りつぶし、ブロックの理由（どのプロジェクトが記録漏れか）が一切見えなくなっていた。②スクリプトがStop hookの入力JSONのstop_hook_activeフラグを見ておらず、無限ループを自分では止められない作りだった。
• 記事のフック（なぜ刺さる）: 「セーフティネットのフックが、そのセーフティネット自身のせいで検知不能になり、かつ無限ループする」という二重の皮肉。$ErrorActionPreferenceのスコープが広すぎると意図したWrite-Errorまで消える罠は汎用的な地雷。Stop hookを書く人全員に刺さるstop_hook_activeチェックの重要性も具体例で語れる
• その時の本音: 同じ「変化なし」を6回連続で返していた間、実は裏でハーネスが静かに戦っていたことに気づかなかった。ユーザーからの指摘で初めて発覚
• レーン/媒体: 🔬Miyoki Labs（Zenn=失敗談・PowerShellの罠／Qiita=Claude Code Stop hook設計の注意点）
• tags: 自動化
• series: -
• refs: C:\Miyoki\.claude\hooks\check-knowledge-log.ps1（修正前後のdiff）
• ネタ度: ★★★
• ステータス: 未執筆

アカウント接続マップ(07)の整合性監査で「橋渡し」区分の見た目トラップを発見した話

• 出典: Miyokiワークスペース 2026-07-04（Nompassアカウント整備・consistency-checkスキル使用）
• 収集日: 2026-07-04
• 何が起きた/やった: 「Nompassのアカウントは公式にはX/Instagram/ブログしか無いのでは」という懸念を受け、07_アカウント接続.md（SSOT）ほか5ファイルを照合。実際はZenn/Qiitaブランド橋渡し方針は5ファイル全てに一貫して反映済みだったが、nompass-accounts.mdの媒体マップ表がNompass専有アカウントと「橋渡し」アカウントを別行に分けていたため、Nompass行だけ見ると存在しないように見えていた。あわせてURL相互連携（ポートフォリオ⇄LP・X bio）を実装コードまで遡って監査し、2箇所の未実装（LPからMiyokiへのリンク・Nompass公式Xの運営者言及）を発見・実装した。
• 記事のフック（なぜ刺さる）: ドキュメントが「正しい」かどうかは、書いてあるかだけでなく「表の見せ方」次第で伝わり方が変わるという教訓。複数ブランドを横断するアカウント設計・SSOT運用の実例として汎用性が高い
• その時の本音: （後で記入）
• レーン/媒体: 🔬Miyoki Labs（note=個人開発・複数事業の運用ノウハウ）
• tags: 事業設計
• series: -
• refs: C:\Miyoki\計画\07_アカウント接続.md／C:\Miyoki\Nompass\Nompass Build\00.Nompass\nompass-accounts.md
• ネタ度: ★★
• ステータス: 未執筆

BOMなしUTF-8で、PowerShellの安全フックが「静かに死んでいた」話

• 出典: Miyokiワークスペース 2026-07-04（check-knowledge-log.ps1 全域化作業）
• 収集日: 2026-07-04
• 何が起きた/やった: Stop hookに日本語パス（個人\）を追加したらPS5.1がBOMなしUTF-8をANSI解釈して文字化け→Test-Pathが静かにfalse→フックがエラーも出さず常時素通りになっていた。BOM付与で解決。exit 2の発火テストで「動いている証明」まで取った。
• 記事のフック（なぜ刺さる）: 「エラーが出ない故障」は最悪。Windows×日本語パス×自動化の定番地雷で、再現手順と検証方法（わざと発火させる）まで書ける
• レーン/媒体: 🔬Miyoki Labs（Zenn=失敗談 or Qiita=解説）
• tags: 自動化
• series: -
• refs: C:\Miyoki\.claude\hooks\check-knowledge-log.ps1（冒頭NOTEとprojects配列＝現物）
• ネタ度: ★★★
• ステータス: 未執筆

44ファイル94箇所のパス一括置換を事故らせない「保護置換」設計

• 出典: Miyokiワークスペース 2026-07-04（projects\廃止→個人\/Nompass\再編）
• 収集日: 2026-07-04
• 何が起きた/やった: フォルダ再編で大量のmd/コードの絶対パスが古くなった。同名ファイルの罠（STATUS.mdが2つ、00_index.mdが2つ、18_revenue_roadmap.mdがroadmap.mdを含む）があるため、①別ファイル参照をプレースホルダ退避→②長いプレフィックス順に置換→③復元の3段構え＋実行前後のgrep残存ゼロ確認で無事故完走。
• 記事のフック（なぜ刺さる）: 「一括置換で壊した」経験は誰にでもある。sed一発でやらない設計判断と検証手順が汎用ノウハウ
• レーン/媒体: 🔬Miyoki Labs（Zenn=判断の経緯）
• tags: 自動化
• series: -
• refs: C:\Miyoki\.claude\skills\consistency-check\SKILL.md（保護置換・同名ファイルの罠の注意節）／nompass-knowledge-log core.md 2026-07-04
• ネタ度: ★★★
• ステータス: 未執筆

AIエージェントの指示書（CLAUDE.md）自体が、過去のファイル移行と自己矛盾していた話

• 出典: Miyokiワークスペース 2026-07-04（SNS/Stripe整備セッション後のconsistency-check）
• 収集日: 2026-07-04
• 何が起きた/やった: 記事ネタの集約先をarticle-seeds.md→seeds-miyoki.md/seeds-nompass.mdに移行した2日後、.claude\CLAUDE.md自身の中に新旧指示が両方残っていた（L54/60が旧ファイルを指示、L73の新プロトコルは新ファイルを指示＝自己矛盾）。加えて実在しないoutput\記事\への参照も05_コンテンツ計画.md・ロードマップ.md等5ファイルに残存。grep横断でCLAUDE.md自体を含めて洗い出し、生きている文書は直接修正・日付付き引き継ぎ（履歴）文書は事実を書き換えず注記のみ追加という使い分けで解消。
• 記事のフック（なぜ刺さる）: エージェントの指示書（CLAUDE.md等）自体が「移行漏れでgrep対象から抜けやすい」のはAI協働ワークフローが広がるほど起きる盲点。「指示書もgrepの対象に含める」「現行文書と履歴文書で直し方針を変える」という運用ノウハウは他のClaude Code/エージェント運用者にも刺さる。
• レーン/媒体: 🔬Miyoki Labs（Zenn=開発ログ／Qiita=運用Tips）
• tags: AI設計 / 自動化
• series: -
• refs: C:\Miyoki\.claude\CLAUDE.md（修正箇所 L54, L60, L73）／C:\Miyoki\計画\05_コンテンツ計画.md
• ネタ度: ★★
• ステータス: 未執筆

クラウドの定期エージェント×ローカルgitで「静かな分岐事故」を防ぐ

• 出典: Miyokiワークスペース 2026-07-04（クラウドルーチン3本の最適化）
• 収集日: 2026-07-04
• 何が起きた/やった: 毎週クラウドエージェントが同じリポのmasterへ自動pushする構成で、ローカルに未pushコミットが眠っていた＝翌週確実に分岐する状態を発見。対策3点セット＝ローカルは即push規律／クラウド側にpull --rebase保険／週次ワークフローに回収pullステップ。
• 記事のフック（なぜ刺さる）: AIエージェントの自動コミット運用はこれから増える。人間×botの共同リポ運用の落とし穴として先回りできるテーマ
• レーン/媒体: 🔬Miyoki Labs（Zenn）
• tags: 自動化 / AI設計
• series: -
• refs: nompass-knowledge-log@b4c2c48（未pushだった実コミット）／C:\Miyoki\voice-kit\03_posting_workflow.md（回収pullステップ0）／ルーチン trig_014Yc7hairF8N3JsrZX9ABRb（rebase保険）
• ネタ度: ★★★
• ステータス: 未執筆

ドメイン取得、結局どこが得？お名前.comとCloudflare Registrarを実際に両方使って比べた話

• 出典: Miyokiワークスペース 2026-07-04（miyoki-labs.com 取得・07_アカウント接続.md更新）
• 収集日: 2026-07-04
• 何が起きた/やった: nompass.jpはお名前.com、miyoki-labs.comはCloudflare Registrarで実際に取得。当初はCloudflareの決済不調（海外決済扱いでカードが弾かれる懸念）を避けてXserverドメイン（国内決済）に迂回する計画だったが、再試行したらCloudflareの決済がそのまま通り、Xserver経由は結局不要だった。取得後はCloudflare Pagesの「Custom domains」でブログ用サブドメイン（blog.miyoki-labs.com）とポートフォリオ用ルート（miyoki-labs.com）を同時設定。お名前.com（更新料が跳ね上がる商法・初年度激安）とCloudflare（原価販売・WHOIS代行無料・クレカ決済のみで通れば最速）を両方使った実体験ベースで比較できる状態になった。
• 記事のフック（なぜ刺さる）: 「ドメイン どこで買うべきか」は個人開発者・スモールビジネス運営者の永遠の悩みで検索需要が常にある鉄板テーマ。レビュー記事ではなく実際に2レジストラを使い分けている実体験・実データ（決済が通った/通らなかった経緯含む）で語れるのが強み
• その時の本音: 決済不調を警戒してXserver迂回まで計画していたのに、いざ試したらあっさり通って拍子抜けした
• レーン/媒体: 🔬Miyoki Labs（Zenn=実体験比較／note=個人開発のインフラ選定判断）
• tags: インフラ
• series: -
• refs: C:\Miyoki\計画\07_アカウント接続.md（ドメイン欄）／Cloudflareダッシュボード（miyoki-labs.com Registrations・miyoki-blog Custom domains）
• ネタ度: ★★★
• ステータス: 一部使用済み（実体験素材としてブログ記事に投入・2026-07-05 公開台帳参照。Zenn/note向けの「レジストラ選定の判断記」としての単独記事化はまだ可）

独自ドメイン移行、コードを直して満足していたら「幽霊URL」が3箇所に残っていた話

• 出典: Miyokiワークスペース 2026-07-04（miyoki-labs.com 取得後の横断反映・/consistency-check実行）
• 収集日: 2026-07-04
• 何が起きた/やった: miyoki-labs.com取得後、ポートフォリオ・ブログ・Nompass LPの3コードベースで旧*.pages.dev参照を洗い出して修正した（自分では「これで完了」のつもりだった）。しかし/consistency-checkを回したところ、コード以外に3種類の見落としが発覚：①発信ドラフト生成用のvoice-kitテンプレ（Zenn/Qiita/X）のCTA文言に旧URLがハードコードされたまま＝直さなければ今後生成する全記事に古いリンクが混入し続けるところだった、②計画書の実装チェックリストが「未完了」表示のまま実態と乖離、③「ドメイン取得後にやる」という未来形のTODOが取得後も放置。単純なgrep置換では気づけない、.mdテンプレ・チェックリスト・未来形TODOという3種の"死角"がある。
• 記事のフック（なぜ刺さる）: 「ドメイン移行/リブランディングはコードのURL直しで終わりがち」という誰もがハマる罠を、実例付きで具体的に語れる。個人開発者・小規模チームのインフラ移行チェックリストとして汎用性が高い
• レーン/媒体: 🔬Miyoki Labs（Zenn=チェックリスト形式の実践知／note=AIエージェントとの整合チェック運用）
• tags: 自動化 / インフラ
• series: -
• refs: C:\Miyoki\voice-kit\01_media_templates.md:78／C:\Miyoki\voice-kit\templates\zenn-template.md:21／C:\Miyoki\計画\06_ブログ計画.md:118-119／C:\Miyoki\計画\07_アカウント接続.md:78-79
• ネタ度: ★★
• ステータス: 未執筆

旧Claude.ai用スキルをClaude Codeへ移植したら、環境前提が全部違った

• 出典: Miyokiワークスペース 2026-07-04（Nompassスキル6本の汎用化調査）
• 収集日: 2026-07-04
• 何が起きた/やった: 過去に作ったスキルに /mnt/user-data/outputs/・create_file・present_files 等の旧環境前提が残存し、Claude Codeでは動かない状態だった。Read/Edit/Write前提へ書き換え＋「完全汎用/パラメータ化で汎用/固有」の3分類で6本を仕分けし、汎用3本だけ親に昇格。
• 記事のフック（なぜ刺さる）: AIエージェントのスキル資産は環境進化で腐る。棚卸しの分類フレームがそのまま使える
• レーン/媒体: 🔬Miyoki Labs（Zenn/Qiita）
• tags: AI設計
• series: -
• refs: Nompass@f4c8392（doc-sync/design-doc修正の実diff）／Nompass\skills\nompass-doc-sync\SKILL.md
• ネタ度: ★★
• ステータス: 未執筆

AIセッションの暴走で計画が飛んだ→「引き継ぎテンプレ」で再発防止した話

• 出典: Miyokiワークスペース 2026-07-04（移行計画の再開〜完走）
• 収集日: 2026-07-04
• 何が起きた/やった: 前セッションが無意味な繰り返し出力で暴走しコンテキスト消失。復旧の鍵は「実データ構造をディスクで再確認して正とする」引き継ぎメモだった。教訓を _テンプレ.md（実データ状態・再開ポイント・再発防止欄つき）に固定化。
• 記事のフック（なぜ刺さる）: AI協働の失敗談は需要が高い。復旧プロセスとテンプレ現物を見せられる（note向きの物語性もある）
• レーン/媒体: 🔬Miyoki Labs（Zenn）／note（働き方寄りに書き直しも可）
• tags: AI設計 / 事業設計
• series: -
• refs: C:\Miyoki\計画\引き継ぎ\_テンプレ.md（再発防止テンプレの現物）
• ネタ度: ★★
• ステータス: 未執筆

---

Nompass LP / Build テンプレ由来

Cloudflare Pages で next/image が効かない問題と対策

• 出典: nompass-lp perf: ロゴをWebP化／本検証ログ
• 何が起きた: /_next/image が原寸画像を passthrough（content-type・サイズが原寸のまま）。sharpで事前WebP化＋適正サイズにして 273KB→34KB。
• フック: 「next/imageだから最適化されてるはず」の思い込み。実測値つきでCloudflare Pages利用者に刺さる。
• レーン/媒体: 🔬Miyoki Labs（Zenn=開発ログ／Qiita=技術解説）
• ネタ度: ★★★ / ステータス: 未執筆

Canva MCP でOGP画像を自動生成してサイトに配線した話

• 出典: nompass-lp OGP対応コミット群
• 何が起きた: generate-design→resize(1200×630)→export(PNG)→public配置→next metadata(openGraph/twitter)配線までAIで半自動化。
• フック: 「AIでデザインアセットを実運用に組み込む」具体例。MCP活用の実践。
• レーン/媒体: 🔬Miyoki Labs（Zenn）
• ネタ度: ★★ / ステータス: 未執筆

小規模事業者LPをAEO（AI検索最適化）対応にした

• 出典: nompass-lp 構造化データ強化／Cloudflare AI Crawl Control設定
• 何が起きた: FAQPage/Service・OfferCatalog/BlogPosting/BreadcrumbList/WebSite の構造化データ＋AI Crawl Controlで「学習系ブロック・検索系許可」のbot制御。
• フック: AEOは旬で競合記事が薄い。実装＋運用（bot設定）まで通しで書ける。
• レーン/媒体: 🔬Miyoki Labs（Qiita／Zenn）※成果面は🏢Nompass事例にも化ける
• ネタ度: ★★★ / ステータス: 未執筆

fade-inの「初回真っ白」バグとフェイルセーフ設計

• 出典: Buildテンプレ ScrollObserver/layout、nompass-lp FadeIn堅牢化
• 何が起きた: IntersectionObserverの初回発火漏れで上部が opacity:0 のまま。__nbRevealフラグ＋2.6秒一括表示フォールバックで防ぐ。
• フック: スクロール演出あるあるのバグ。原因と堅牢化パターンがセット。
• レーン/媒体: 🔬Miyoki Labs（Zenn）
• ネタ度: ★★ / ステータス: 未執筆

microCMSの1エンドポイントを section で「お知らせ/ブログ」に論理分割

• 出典: nompass-lp microcms.ts / Buildテンプレ blog/news設計
• 何が起きた: newsエンドポイントを増やさず select フィールド section で /news と /blog に振り分け（isBlogSection で表記揺れ吸収）。
• フック: microCMS実運用の節約テク。表記揺れ吸収が地味に役立つ。
• レーン/媒体: 🔬Miyoki Labs（Qiita）
• ネタ度: ★★ / ステータス: 未執筆

Next.js × Cloudflare Pages の sitemap / robots を実ページに正す

• 出典: nompass-lp sitemap刷新 / robots修正
• 何が起きた: 動的sitemap（静的＋microCMS記事URL）、robotsの example.com 既定値バグ、metadataBaseの重要性。
• フック: SEOの基礎なのに抜けがちな実装ミス集。
• レーン/媒体: 🔬Miyoki Labs（Zenn）
• ネタ度: ★★ / ステータス: 未執筆

「テンプレ→顧客サイト」を量産する設計（map-data駆動・減算式）

• 出典: Nompass Buildテンプレ
• 何が起きた: 1テンプレから業種別サイトを量産。map-data.json駆動、HP-P基準の減算式、CLAUDE.mdへのルール化（法的ページのオプトイン等）。
• フック: 受託/制作を仕組み化する話。個人で回す設計思想。
• レーン/媒体: 🔬Miyoki Labs（Zenn／note＝働き方）
• ネタ度: ★★ / ステータス: 未執筆

実績ゼロのLPで「実績」をどう見せるか（景表法を意識）

• 出典: nompass-lp Works→想定効果(モデルケース)化
• 何が起きた: 架空実績はNG。モデルケース/シミュレーション表記に統一。マーケ訴求と法務のバランス。
• フック: 駆け出し事業/フリーランスが必ず当たる論点。誠実さの設計。
• レーン/媒体: 🔬Miyoki Labs（note＝ビジョン／ポートフォリオ）
• ネタ度: ★★ / ステータス: 未執筆

AIで小規模事業者向けLPをまるごと作った開発記録

• 出典: Nompass LP制作プロジェクト全体
• 何が起きた: AIで個人が事業のLP・テンプレ・運用ルールまで一気に構築した全体振り返り。判断の経緯・失敗・学び。
• フック: 「AI活用で個人が稼ぐ」のリアル。Miyokiのコア発信テーマと一致。
• レーン/媒体: 🔬Miyoki Labs（note＝ビジョン・生き方）
• ネタ度: ★★ / ステータス: 未執筆

---

dev / SDC 由来

4エージェント並列審査でブログ記事を品質チェックする設計

• 出典: dev/miyoki-media-pipeline（パイプラインコックピット）
• 何が起きた: SEO・読者・収益・AEOの4観点を Promise.all で同時実行。審査↔本文の再生成連携（再生成時に体験談セクションを保護）。ストリーミングで逐次表示。
• フック: 「LLMを審査エージェントとして並列で使う」実装パターン。記事量産したい層に直球。
• レーン/媒体: 🔬Miyoki Labs（Qiita／Zenn）
• ネタ度: ★★★ / ステータス: 未執筆

「説明可能なRAG」で経理・税務アシスタントを作る

• 出典: SDC/RAG（経理・税務AIアシスタント PLAN.md）
• 何が起きた: 検索→根拠提示→回答生成を画面で証明＝ChatGPT連携との差別化の核。センシティブ領域は「最終判断を出さず一次トリアージで止める」設計。
• フック: RAGの差別化＋AIに判断させない倫理設計を通しで。競合記事が薄い。
• レーン/媒体: 🔬Miyoki Labs（Qiita／note＝設計倫理）
• ネタ度: ★★★ / ステータス: 未執筆

競馬予想AIで学ぶデータサイエンス（Supabase × XGBoost × Claude）

• 出典: dev/Horse Racing Analysis（CLAUDE.md）
• 何が起きた: 24年分のJRA重賞データを正規化、同日レース平均タイムからトラックバイアスを特徴量化、XGBoost/LightGBMで数値予測→Claudeで展開予想を自然言語化。
• フック: データアナリスト志向と直結。特徴量設計が具体的で学習者に役立つ。
• レーン/媒体: 🔬Miyoki Labs（Zenn／Qiita）
• ネタ度: ★★ / ステータス: 未執筆

写真を送るだけで投稿・ブログ・求人票を自動生成（Nompass Voice）

• 出典: Nompass/voice（CLAUDE.md）
• 何が起きた: Claude Haikuで実装、将来Gemini Flashへ切替を見据えたモデル抽象化。「発信する時間がない」事業者を解消する設計。
• フック: 画像→マルチ成果物の自動生成が分かりやすい。モデル差し替え前提の設計も学びに。
• レーン/媒体: 🔬Miyoki Labs（Zenn）
• ネタ度: ★★ / ステータス: 未執筆

LINE自動返信＋Web問い合わせを「受信ボックス」に一元化

• 出典: Nompass 直近コミット群（LINE Phase1）
• 何が起きた: キーワードトリガーの自動返信、LINEとWebフォームの問い合わせを1受信ボックスに集約。案件化・連携導線まで。
• フック: 小規模事業者の問い合わせ運用あるある。チャネル横断集約が実務的。
• レーン/媒体: 🔬Miyoki Labs（Zenn／Qiita）
• ネタ度: ★★ / ステータス: 未執筆

複数サービスを統合ダッシュボードで束ねる（DBのserviceカラム設計）

• 出典: Nompass/lead-core（CLAUDE.md）
• 何が起きた: Trace/Voice/Build/Coreを1コードベースで管理し、DBの service 列で論理分割。増やしてもコードを増やさない。
• フック: マルチプロダクトを個人で回す現実解。単一コードベース×論理分割の判断が参考に。
• レーン/媒体: 🔬Miyoki Labs（Zenn）
• ネタ度: ★★ / ステータス: 未執筆

テレアポ切り返しAI：顧客プロファイル別に提案を出す

• 出典: SDC/teleapo-demo（README.md）
• 何が起きた: 年代・物件種別・エリアのプロファイルで出し分け。状況分析→切り返しトーク→ポイント解説→次の一手の4段構成。会話履歴で深掘り。
• フック: 営業×AIの具体ユースケース。プロファイル駆動のプロンプト設計が分かりやすい。
• レーン/媒体: 🔬Miyoki Labs（Zenn／ポートフォリオ）
• ネタ度: ★★ / ステータス: 未執筆

提案文ジェネレーター：システムプロンプトで文体を固定する

• 出典: dev/Proposal Generator（README.md）
• 何が起きた: 媒体別（クラウドワークス/ランサーズ）に文体を切替、システムプロンプトで構成・トーンを定義し毎回一貫品質。ストリーミング生成。
• フック: 「プロンプトで品質を安定させる」実例。フリーランス向けで実用性が高い。
• レーン/媒体: 🔬Miyoki Labs（Zenn／Qiita）
• ネタ度: ★★ / ステータス: 未執筆

Vibe CodingでアプリをまるごとAIと作った話（数値分析カウンター）

• 出典: dev/counter-app（README.md）
• 何が起きた: Google Antigravityとの協調開発、Capacitorでモバイルアプリ化、再帰的に統計を算出するBox設計。
• フック: 「AIと個人がプロダクトを高速で磨く」リアル。Miyokiのコア発信テーマと一致。
• レーン/媒体: 🔬Miyoki Labs（note＝ビジョン／Zenn）
• ネタ度: ★★ / ステータス: 未執筆

個人開発でも規約・特商法・賠償上限を整える理由

• 出典: Nompass 直近コミット（規約・申込フロー整備）
• 何が起きた: 利用規約v1（賠償上限1ヶ月）、返金条項、合意管轄、特商法ページとの整合。マーケ訴求と法務のバランスを事業設計に組み込む。
• フック: 駆け出し事業者が後回しにしがちな論点。誠実な設計の実例で差別化。
• レーン/媒体: 🔬Miyoki Labs（note＝ビジョン／Qiita＝実務知識）
• ネタ度: ★★ / ステータス: 未執筆

---

miyoki-portfolio 由来

SPA遷移でフェードインが消える不具合と静的エクスポート構成

• 出典: miyoki-portfolio 直近コミット
• 何が起きた: ページ遷移でIntersectionObserver要素が再表示されない不具合修正、env未設定でもOGP/sitemapが本番URLで出る既定値設計、静的エクスポート移行。
• フック: SPA演出のハマりどころ＋環境変数に依存しないフェイルセーフ設計がセット。
• レーン/媒体: 🔬Miyoki Labs（Zenn）
• ネタ度: ★★ / ステータス: 未執筆

---

働き方・事業設計（note中心）

ブログ自動化ツール開発（進行中・連載向き）

• 出典: dev/miyoki-media-pipeline
• 何が起きた: ブログ記事生成を自動化。サイト別プロファイル（トーン/キーワード/CTA/section）でMiyoki・Nompass両対応を目指す。
• フック: 「続かない発信を仕組みで回す」実例。完成前の試行錯誤も投稿価値あり。
• レーン/媒体: 🔬Miyoki Labs（Zenn＝連載）
• ネタ度: ★★ / ステータス: 未執筆

1人事業で「営業が重い」をインバウンド設計で軽くする

• 出典: Nompass docs/operation/22_self_marketing.md
• 何が起きた: 営業が重いのは能力でなく「能動的に売り込む型」だからと整理。自社SNSをVoice(AI)で自動運用＝1つの行動が営業・実績作り・生きたデモを兼ねる。「紹介して」を「無料診断を1社プレゼントしたいので繋いで」に言い換え。
• フック: 動き出せない人の核心（営業の心理ハードル）を仕組みで解く。Miyokiのコアテーマ。
• レーン/媒体: 🔬Miyoki Labs（note＝ビジョン・生き方）
• ネタ度: ★★ / ステータス: 未執筆

個人名義で作ったインフラを事業名義へ移管する棚卸し設計

• 出典: Nompass docs/operation/16_account_migration_plan.md
• 何が起きた: Render/Cloudflare/Neon/microCMS/Resend/Anthropic等を「ツール×用途×現アカウント×移行方針」で棚卸し。メンバー追加→オーナー移譲やキー再発行で事業名義へ。Anthropic APIは個人立替中で優先。
• フック: 個人開発が事業化したとき必ず当たる「アカウントが個人名義」問題。手順と優先順位が実務的で競合記事が薄い。
• レーン/媒体: 🔬Miyoki Labs（Zenn／note＝働き方）
• ネタ度: ★★ / ステータス: 未執筆

---

自動抽出（2026-07-03）

形態素解析なし・依存ゼロのbi-gram検索でRAGの検索部分を作る

• 出典: SDC/RAG lib/retrieval.ts（2026-07-01）
• 何が起きた/やった: 形態素解析ライブラリを入れず、文字bi-gramで上位3件を抽出。デモに十分な精度を依存ゼロで確保。
• 記事のフック（なぜ刺さる）: 「RAG＝ベクトルDB必須」の思い込みを崩す。小規模なら依存ゼロで始められる、導入ハードルを下げる話。
• レーン/媒体: 🔬Miyoki Labs（Qiita＝技術解説）
• ネタ度: ★★ / ステータス: 未執筆

NDJSONで「根拠チャンク→回答テキスト」を1本のストリームで返す

• 出典: SDC/RAG api/chat/route.ts（2026-07-01）
• 何が起きた/やった: 1行目に証拠チャンク(JSON)、以降をテキストデルタで流すNDJSON。根拠を先に画面へスタンプしてから回答をストリーミング表示。
• 記事のフック（なぜ刺さる）: 「根拠を見せるUI」を実現する具体的なレスポンス設計。RAGのUX実装で役立つ。
• レーン/媒体: 🔬Miyoki Labs（Zenn＝開発ログ）
• ネタ度: ★★ / ステータス: 未執筆

秘密鍵をgit履歴に残してしまった時の現実的なリカバリ

• 出典: dev/counter-app chore(security): StripeシークレットをSecret Manager化し.envを追跡解除（2026-07-01）
• 何が起きた/やった: Stripe秘密鍵がgit履歴に残存。Secret Manager化＋.env追跡解除で対応。鍵ローテと履歴クリーン化（filter-repo）が残課題。
• 記事のフック（なぜ刺さる）: 個人開発で誰もがやりがちな「鍵をコミットしてしまった」事故の、現実的なリカバリ手順。
• レーン/媒体: 🔬Miyoki Labs（Zenn＝開発ログ／Qiita＝セキュリティ）
• ネタ度: ★★ / ステータス: 未執筆

同名フィールドの意味衝突に注意（draft＝本文 vs draft＝公開フラグ）

• 出典: dev/miyoki-media-pipeline Phase 2（history 2026-07-03 / Step6 スキーマ接続）
• 何が起きた/やった: 記事生成ツールの出力をAstro静的サイトのスキーマに繋ぐ際、draft が「本文」と「公開フラグ」で同名別物。素直にマッピングすると事故る→明示的に切り分けた。
• 記事のフック（なぜ刺さる）: ツール間連携で必ず起きる「同じ名前・違う意味」の罠。地味だが刺さる実務Tips。
• レーン/媒体: 🔬Miyoki Labs（Zenn＝開発ログ）
• ネタ度: ★ / ステータス: 未執筆

独自ドメインをどこで取る？お名前/Xserver/Cloudflareを実際に比較した

• 出典: miyoki-labs.com レジストラ選定（2026-07-03）
• 何が起きた/やった: Cloudflare Registrarで決済が繰り返し失敗（GPay/PayPal/カード全滅＝海外USD or 注文側の問題）→ 別レジストラへ。単体契約の実額を比較（Cloudflare$10.46／Spaceship$9.98／Xserver1,721円フラット／お名前0円+更新約1,622円＋維持調整費26%）。純コスパはお名前だが、nompass.jpが既にお名前＝Nompass口座なので、棲み分けのためMiyokiはXserverに分けた。
• 記事のフック（なぜ刺さる）: 「.comをどこで取るのが正解？」は誰もが通る道。価格だけでなく"決済の通りやすさ""ブランドの棲み分け"まで含めた実体験。お名前の維持調整費・アップセルの実態、Cloudflare決済詰まりのリアル、レジストラ境界＝ブランド境界という設計判断。
• レーン/媒体: 🔬Miyoki Labs（Zenn＝開発ログ／note＝働き方・事業設計）
• ネタ度: ★★ / ステータス: 未執筆

Bing Webmaster自動化＋警告切り分け 由来（2026-07-08）

GSCに続きBingも自動化。仕上げは「クロール警告」をcurlのUA偽装で数秒判定

• 出典: Miyokiワークスペース 2026-07-08（個人\seo-insights\gsc-report.mjsへのBing Webmaster API統合、および公開直後のmiyoki-labs.comでBing Webmaster Toolsが出した警告の切り分け）
• 収集日: 2026-07-08
• 何が起きた/やった: 既に自動化済みだったGSCレポートに続き、Bing Webmaster APIを同じスクリプトへ統合。BingはGSCと違い日付範囲を指定できず週次バケットで全期間分が返ってくる仕様のため、Microsoft JSON日付（/Date(数値)/形式）を自前パースし、直近28日分だけをクエリ/ページ単位に集計してGSCと同じ形（表示回数・クリック・CTR・平均順位）に揃え、既存の改善候補抽出ロジックをそのまま再利用する形で実装。実装直後、Bing Webmaster Tools画面で①「alt属性が1箇所missing」という指摘と②新規追加した/worksページの「Discovered but not crawled」「URL cannot appear on Bing」という強めの警告表示に遭遇したが、いずれもBingbotのUser-Agentを偽装したcurlで直接アクセスし通常UAの応答と比較することで、実害の有無を数秒で切り分けた（①は装飾用画像の意図的な空alt＝誤検知、②は公開1日目の新規ドメインゆえの単なるクロール未着手＝定型の警告文言で実害なし）。
• 記事のフック（なぜ刺さる）: 外部の管理画面（Bing/GSC）が赤字で強い警告を出すと個人開発者は身構えがちだが、「本当にブロックされているのか」「単に順番待ちなだけか」はcurlでUAを偽装して直接叩けば数秒で切り分けられる、という実務Tips。加えてBing Webmaster APIという情報が少ない領域の実装記録としても価値がある。
• その時の本音: 「URL cannot appear on Bing」の赤い×印は最初かなり不安を煽られたが、実際はただの新規ドメインのクロール待ちで、curl一発で「壊れていない」と確信できた。警告文言の強さと実害の大きさは比例しないと再認識した。
• レーン/媒体: 🔬Miyoki Labs（Zenn＝Bing Webmaster API実装ログ／Qiita＝「Bing/GSCの警告を数秒で切り分ける」実務Tips）
• tags: 個人開発 / API連携 / SEO / 自動化
• series: -
• refs: 個人\seo-insights\gsc-report.mjs（fetchBingStats/aggregateBingRows/parseMsDate）／個人\miyoki-portfolio\knowledge-log\history\main.md「2026-07-08（Bing Webmaster自動化を実装・稼働確認完了）」「2026-07-08（/worksが「Discovered but not crawled」）」
• ネタ度: ★★
• ステータス: 素材

蓄積の商品化を設計した 由来（2026-07-08）

「理解は売らない、再現を売る」— 無料記事4本が有料noteの目次になる3層設計

• 出典: Miyokiワークスペース 2026-07-08（「蓄積で稼ぐ」10案の仕分けと、有料/無料の線引きルール策定。計画\03_収益化.md②-b を新設し、確定文書を意図的に改訂）
• 収集日: 2026-07-08
• 何が起きた/やった: 「蓄積で稼げそうな案」10件（有料note／BOOTHプロンプト集／Notionテンプレ／スターターキット／教材PDF／Botテンプレ化／ミニSaaS／SEOアフィリ／Kindle／OSS Sponsors）を現在地と突き合わせて仕分けた結果、今期やるのは有料note 1本だけになった。落とした理由が3つとも工数ではない：①読者がまだゼロ（自己紹介投稿すら未投稿・リレー未開始）で、売る商品より先に「無料で読まれる」を立てる必要がある ②案8「SEOアフィリ」は新規案ではなくすでに miyoki-blog として稼働中だった（公開2記事・A8アフィリ7本）③案6「税理士向け」は需要ヒアリングログが「接触実績なし」＝書く材料が存在しない。さらに調査で、売れている有料noteの定石が「続きが気になるで釣る」ではなく「無料部分だけで完結して満足できるように書く」だと分かったので、判定テストを1問に圧縮した＝「これを読んだ人が、明日、自分の環境で同じものを動かせるか？」Yes=有料 / No=無料。副産物として、有料の価値は細分化ではなく束ね（＝「最初から最後まで動くワークフロー1つ」）で生まれると気づき、既存の series フィールドを束ね名に流用して新語彙をゼロに抑えた。手数料も検証：「1,000円売って手取り585円」と書く記事が複数あるが、あれは1本ごとに振込手数料270円を引いた計算で、まとめて振り込めば実質85%前後（980円カード決済で手取り約838円）。
• 記事のフック（なぜ刺さる）: ①「有料/無料の線引き」を判定テスト1問まで削れる、という運用可能な形にした点。理解を売ると値付けに迷うが、再現を売ると迷わない ②無料記事を出し惜しみするほど有料が売れなくなるという反直感（L1の4本がそのまま有料noteの目次＋流入導線になる）③個人開発者が必ず引っかかる「note手数料585円神話」の訂正＝固定費を1本に按分した計算のトリック ④有料noteのKPIは売上ではなく「販売実績が立ったか」（受託の信用装置＝他人が金を払った第三者検証）という位置づけ。ストックで月30万は1〜2年スパン（Zenn有料本の実測例で500円×88冊/年＝年約5万円）という現実を数字で押さえた上での結論なので、精神論にならない。
• その時の本音: 10案を渡された時、正直どれも「やればできる」ので全部Tier分けして並べたくなった。踏みとどまれたのは、週末PC枠がpost-deckのAccess設定とGSC本番化で既に埋まっているのを見た瞬間。手を広げない理由は「意志」ではなく「カレンダー」にあった。あと、案8が既に自分で走らせている miyoki-blog そのものだと気づいた時は苦笑いした。自分の資産を棚卸しできていないまま「新しい収益源」を探していた。
• レーン/媒体: 🔬Miyoki Labs（note＝理解を売らず再現を売る／有料化の設計と「読者ゼロで有料を出さない」／Qiita＝note手数料の正しい計算とプラットフォーム比較）
• tags: 事業設計 / 発信 / 収益化
• series: -
• tier: L1
• refs: 計画\03_収益化.md「②-b 有料コンテンツ」／ideas\_knowledge-log-rule.md「無料↔有料の線引き（tier）」「束ねルール」／計画\ロードマップ.md「蓄積の商品化（着手条件つき保留）」／計画\需要ヒアリングログ.md（税理士候補＝接触実績なし）
• ネタ度: ★★
• ステータス: 未執筆

seeds — 🏢 Nompass（横断マスター）

Nompass等の事業成果として発信するネタの横断台帳（発注検討者・見込み客向け）。 運用ルール／エントリ雛形＝_knowledge-log-rule.md。出典＝重複防止キー。 週次 MiyokiSeedScan が、🏢レーンを持つプロジェクト（Nompass系）の knowledge-log/log.md🏢レーンをここへ集約する。 一次ソースの本体は C:\Miyoki\Nompass\Nompass Build\00.Nompass\knowledge-log\log.md の🏢Nompassレーン（Before/After・画像最適化の成果・AEO・LINE導線 等）。 dev/SDC などMiyoki個人プロジェクトは🏢レーンを持たないため、ここには流入しない。

---

🔥 今週書くならこれ（未執筆・ネタ度順 Top3）

1. （harvest待ち。00.Nompass log.md の🏢レーンから集約される）

---

🏢 Nompass レーン（成果・事例）

<!-- 週次harvestが 00.Nompass 等の knowledge-log/log.md 🏢レーンから追記する。 手動で足す場合のエントリ雛形：

YYYY-MM-DD｜タイトル

• 出典: <repo> の <日付見出し> ／ or SHA
• 何が起きた/やった: 1〜2行
• 記事のフック（なぜ刺さる）: 1行
• レーン/媒体: 🏢Nompass（公式note／LP事例）
• ネタ度: ★★★
• ステータス: 未執筆

-->

シリーズ：AIプロダクト設計（LLMアプリの実装判断）

• tags: AI設計
• パッケージ狙い: Qiita技術解説の柱 → 受託営業資料への転用（「こういう設計ができます」の証明）
• 強み: 説明可能RAG・並列審査など「設計判断の理由」まで書ける一次情報

エントリ（時系列・古い順）

追記ルール：series: AIプロダクト設計 の付いたエントリを1行足す。

シリーズ：Cloudflare学び（Pages × Next.js/Astro 実戦記）

• tags: Cloudflare
• パッケージ狙い: Zenn連載「Cloudflare Pagesで個人開発を全部ホストする」→ まとめ記事 → note有料版（体験談＋ハマり集）
• 強み: 4リポ横断（portfolio / blog / Nompass build / LP）の一次情報。最も厚い塊
• 有料化の作法: 各エントリはL1（無料）で出し、束ねて「動くワークフロー1つ」にした上でL3（有料note）にする。線引きの正＝ideas\_knowledge-log-rule.md「無料↔有料の線引き（tier）」

エントリ（時系列・古い順）

追記ルール：seeds/log で series: Cloudflare学び が付いたら1行足す。公開したら状態をURLに。

シリーズ：個人開発セキュリティ（やらかしと防御の実録）

• tags: セキュリティ
• パッケージ狙い: Zenn「個人開発のセキュリティ実録」連載。失敗談ベースで刺さりやすい
• 強み: 秘密鍵のgit混入リカバリなど「実際にやらかした」一次情報（誰も書きたがらない＝希少）

エントリ（時系列・古い順）

追記ルール：series: 個人開発セキュリティ の付いたエントリを1行足す。 ⚠️ 公開時は「対処完了後」に限る（未対処の脆弱性を晒さない）。

シリーズ：制作記（ポートフォリオ＆ブログを作って公開するまで）

• tags: 制作記
• パッケージ狙い: Zenn開発ログ連載 → note「独学でここまで作れる」ビジョン記事との2面展開
• 強み: 判断の経緯（設計を覆してAstro採用等）と失敗談がそのまま差別化になる

エントリ（時系列・古い順）

追記ルール：series: 制作記 の付いたエントリを1行足す。

シリーズ：決済・課金設計（個人開発×お金の実装）

• tags: 決済
• パッケージ狙い: Qiita/Zennの単発2〜3本 → 溜まったら「個人開発の決済入門」まとめ
• 強み: Stripe請求書リンク・二重請求防止など実運用の判断込み

エントリ（時系列・古い順）

追記ルール：series: 決済・課金設計 の付いたエントリを1行足す。

引き継ぎメモ：ブランド統一 & ポートフォリオ記事カード（2026-07-01）

このセッションで決めたこと・実装したことの記録。別セッションはまずこれを読む。 詳細の一次ソース：05_コンテンツ計画.md / ideas/article-seeds.md（※2026-07-02に seeds-miyoki.md/seeds-nompass.md へ移行済み） / miyoki-portfolio/docs/article-cards-design.md

---

1. 記事ネタの自動収集（実装済み・稼働中）

• 週次で参照フォルダ（C:\Miyoki\Nompass ＋ C:\Miyoki\個人※当時は C:\dev C:\SDC）の更新から記事ネタを抽出し ideas/article-seeds.md に自動追記する仕組みを構築済み。
• タスク：MiyokiSeedScan（Windowsタスクスケジューラ）＝毎週金曜22:00、ideas/_run-seed-scan.ps1 → claude -p ideas/_auto-seed-scan.md。
• 状態ファイル ideas/_scan-state.json（last_scan）／ログ ideas/_scan-logs/。
• 粒度ルール：1エントリ＝記事1本にできる単位、1回最大5件。

2. 媒体の切り分け（確定）

• Zenn＝開発ログ・技術発信に一本化。アフィリのAIツールレビューはZennに載せない（Zennの信頼＝受託の入口を守る）。
• AIツールレビュー（アフィリ）は自前ブログ専用。dev/miyoki-media-pipeline※当時のパス（現 C:\Miyoki\個人\miyoki-media-pipeline）（＝アフィリ専用・プロファイル差し替え不可）の出力先。
• Zenn/Qiita/note の発信は media-pipeline を流用せず軽いフローで書く。

3. アカウント統一（確定・移行はこれから）

• ブランド人格＝Miyoki Labs（屋号）。全媒体を統一（YouTube除く）。347を捨てる。
• ハンドル（URL・小文字）：X / note / Zenn / Qiita = miyoki_labs、GitHub = miyoki-labs（_不可のためハイフン）。
• 表示名（全媒体共通）：Miyoki Labs。大文字はハンドルでなく表示名で見せる。
• 移行方法＝リネーム（削除→新規はしない。メアド付け替え回避）。
• X：ユーザー名変更。note：ID変更。Zenn：リネーム。Qiita：記事1本のみ・ID変更不可なら作り直して貼り直し。GitHub：リネーム＋ローカルgit remote張り替え（14repoは自動リダイレクト）。
• 旧Music系（Miyoki_Music/miyoki_music）は分離。YouTube @Miyoki_Music は据え置き。
• 要確認：Zenn/Qiita の miyoki_labs 空き（未確認・ネットワークで取れず）。QiitaのID変更可否。
• 手動TODO：各媒体リネーム → miyoki-portfolio/src/data/site.ts の全リンク差し替え。

4. ポートフォリオ「最新記事カード」（Phase 1 実装済み）

設計：miyoki-portfolio/docs/article-cards-design.md。方式＝ビルド時取得→静的カード（output:"export" と整合、実行時fetchなし、失敗ソースは空配列でフェイルセーフ）。

• 実装済み（Phase 1・Zenn/Qiita）：
• src/data/articles.ts（fetchZenn/fetchQiita/getArticles。noteは fetchNote() が現状 [] を返すスタブ）
• src/components/ArticleCard.tsx（媒体バッジ＋絵文字＋タイトル＋日付。いいね数は非表示）
• src/app/page.tsx「発信」セクションに最新6件グリッド（記事カードを上、下にACCOUNTSリンク）
• npm run build 成功・実データ4件が out/ に焼き込み確認済み。
• 重要TODO（リネーム後）：src/data/articles.ts の ZENN_USER/QIITA_USER を "miyoki_labs" に変更。
• Phase 2 進捗：
• note（RSS/XML）→ fast-xml-parser で fetchNote() 実装済み（NOTE_USER="miyoki_labs"）。noteアカウント有効化までRSSが404→空配列で無害、有効化後は次回deployで自動表示。
• 週次自動更新：このPagesはwrangler直アップ型でDeploy Hook不可。更新は npm run deploy（ローカル再ビルド）。記事公開のたびに手動デプロイするので、その時にカードも最新化される。自動化するなら _run-seed-scan.ps1 末尾に npm run deploy を足す。
• 表示仕様：最新6件・媒体混在／いいね非表示／記事カードを上。Xはカード化せず @miyoki_labs フォローボタン。

6. 別セッションhandoffとの整合（2026-07-01_ポートフォリオ公開.md）

• ポートフォリオは公開済み（https://miyoki-portfolio.pages.dev ／ repo github.com/Miyoki347/miyoki-portfolio public）。roadmapの「MVP次セッション着手」は消化済み。
• 記事一覧セクションは別handoffで「本人編集中」だったが、本セッションでPhase 1完成。
• ハンドルは別handoff/setup-kitで未決（miyoki347 or miyoki_ai）だったが、miyoki_labs（Miyoki Labs）に決定。setup-kitのハンドル候補はこれで上書き。
• デプロイは直アップ型（npm run deploy）。GitHub自動デプロイは未連携。
• P0宿題（別handoff §5）：counter-app の git履歴に Stripe秘密鍵残存 → 鍵ローテーション必須。

5. 次にやること（順不同）

1. （手動）各媒体を miyoki_labs/miyoki-labs にリネーム。
2. リネーム後：articles.ts のユーザー名を miyoki_labs に、site.ts のリンクを差し替え。
3. Phase 2：note の fetchNote() 実装 ＋ Deploy Hook で週次自動リビルド。

引継ぎ（2026-07-01 時点）— Miyoki ポートフォリオ＆発信

使い方：C:\Miyoki\ で起動し、このファイルを最初に渡す。前提の全体方針は 00〜05 / ロードマップ.md / プロジェクト棚卸し.md を参照。 このセッションでポートフォリオを公開し、発信（アカウント準備・初投稿原稿）まで着手した。その続きをやる。

後続セッション更新（同日・2026-07-01）：一部が上書きされた。詳細は 2026-07-01_ブランド統一と記事カード.md（同フォルダ）。 - ハンドル決定：全媒体 miyoki_labs／GitHub miyoki-labs／表示名 Miyoki Labs（§3のA/B候補と §33 の setup-kit ハンドル候補は無効）。 - 記事一覧セクション（§1F・§4 P2）＝Phase 1 実装完了（Zenn/Qiita。noteはPhase 2）。 - 週次自動更新の方式：直アップ型のためDeploy Hook不可。npm run deploy で更新。 - 統合された優先順位は ロードマップ.md の「## 実行キュー（2026-07-01 統合）」を見る。

---

1. このセッションでやったこと（進捗）

A. 全体プランニング確定

• Web/LP制作は Nompass に一本化。Miyoki個人受託は「AI業務自動化・ツール開発」1本に集中（03_収益化.md 更新済み）。
• 成果物作成：プロジェクト棚卸し.md / 04_ポートフォリオ計画.md / 05_コンテンツ計画.md / ロードマップ.md。
• devプロジェクト整理：HP制作系3つ＋趣味系4つを C:\Miyoki\_reference\_archive\ へ移動。Horse Racing Analysis character-profile-book-app counter-app は残置。

B. ポートフォリオを制作・公開 ✅

• 公開URL：https://miyoki-portfolio.pages.dev
• リポジトリ：https://github.com/Miyoki347/miyoki-portfolio（public）／ローカル C:\Miyoki\個人\miyoki-portfolio
• 技術：Next.js 15（静的エクスポート output:"export"）＋ Tailwind ＋ Cloudflare Pages（wrangler直アップ）。※next-on-pagesはWindowsで不安定なので不使用。
• デザイン：ゴシック（Noto Sans JP）、ブランド色インディゴ #4338CA、2カラムHero＋MMロゴのブランドカード。日本語改行 auto-phrase。OG画像は実ロゴ＋sharpで生成（public/og.png）。ロゴは logo-avatar.webp（アバター）/ logo-mark.webp（MM）、元PNGは brand/。
• 実績データ：src/data/works.ts（直書き）。各実績にリンク追加済み（下記C）。
• 直したバグ：SPA遷移でフェード要素が出ない → ScrollObserver を usePathname 依存で再監視。

C. 実績リポジトリの公開＋リンク付け ✅（秘密情報スキャン実施）

• 新規public化：accounting-tax-rag-demo / teleapo-demo（.gitignoreで.env.local除外・push前ガードで混入なし確認）。
• 既存public：proposal-generator（demo+repo）/ writing-assistant（repo）。
• counter-app は private維持（理由は §5 セキュリティ）。デモリンクのみ。

D. Nompass 改行ルール統一 ✅

• word-break: auto-phrase を build（テンプレ）＋ ui_quality_standards.md ＋ 顧客サイト（client-Nompass-hp）に反映し、本番 nompass.jp にデプロイ済み。portalは元から対応済み。

E. 発信の着手 ✅

• 初投稿原稿（Zenn/開発ログ）：C:\Miyoki\output\記事\Zenn\2026-07-01-ai-portfolio-cloudflare-pages.md（published:false。ポートフォリオ制作のつまづき5本立て。※実際の保存先は下書き\Miyoki-Labs\Zenn\。詳細は§6参照）。
• アカウント準備キット：C:\Miyoki\output\アカウント設定\2026-07-01-アカウント設定手順書.md（各媒体のbio・アイコン運用・ハンドル候補・リンク導線・チェックリスト）。
• 05_コンテンツ計画.md に媒体切り分けを追記（§1-2）：Zenn＝開発ログ / Miyokiブログ＝アフィリ（pipeline専用）。pipelineは現状“媒体別プロファイル未対応”＝アフィリブログ専用。

F. 進行中（本人が編集中）

• ポートフォリオに記事/ブログ一覧セクションを追加中（components/ArticleCard.tsx / data/articles.ts / getArticles / home の CHANNELS 付近）。※この引継ぎ作成時点で本人が実装中。デプロイ前提の未完成コードがある可能性あり。

---

2. 現在の資産・URL・パス

既存アカウント：X=Miyoki_Music / note=miyoki_music / Zenn=miyoki347 / Qiita=Miyoki347 / GitHub=Miyoki347（全部あり。リネーム＆プロフィール刷新をしていく段階）。

---

3. 確定した方針・意思決定

• 名乗り＝AIプロダクトエンジニア。一言＝「創って、動かして、届ける。／AIでプロダクトを形にする。」
• Web/LP＝Nompass、AI開発＝Miyoki（受託の切り分け確定）。
• ブランド：アイコン=アバター / ロゴ=MMマーク / 色=インディゴ#4338CA。
• YouTube（BGM）は挫折済み＝対象外。Miyoki(AI)ブランドに含めない・相互リンクもしない。
• ハンドル統一は別セッションで決定（候補A：miyoki347でdev系統一／候補B：miyoki_ai）。
• ドッグフーディング：Trace は自社登録して使う、Voice は Nompass運用に限定（Miyokiブログはpipeline）。
• Voice×pipeline統合は将来の「Nompass個人向けサービス展開」時。
• 既存制作物は Nompass の機能モジュールにも転用（実績かつ強化の両取り）。
• 可処分時間＝平日夜21時〜＋土日（少ない→絞る）。

---

4. 次にやること（優先順）

P1. 発信ロールアウト（続き）

1. アカウント刷新（本人）：X/note を キット の bio・アイコン（アバター）に。ハンドル統一名を決定して反映。Zenn/Qiita/GitHub は表示名/bio/アイコンを更新。
2. Zenn初投稿：原稿を確認 → 本文末尾にポートフォリオURLを差し込み → 公開。GitHub連携推奨。
3. 順次投稿：2本目Zenn（article-seeds の「Cloudflare Pagesでnext/image」等）→ note（ビジョン1本）→ Qiita（AEO/構造化データ）→ X（各記事の告知スレッド）。
4. （希望あれば）バナー生成：Xヘッダー(1500×500)/noteカバー。OGと同世界観で作成可。

P2. ポートフォリオ仕上げ

• 記事一覧セクション（本人進行中）を完成→デプロイ。
• 問い合わせフォーム（Resend）は後追い（今はメール＋SNS）。
• 独自ドメインは本格運用時に取得 → src/data/site.ts の siteUrl 変更＋Cloudflareでドメイン割当。

P3. ストック

• miyoki-media-pipeline の媒体別プロファイル対応（05 §4）。
• Miyokiブログ（アフィリ）立ち上げ→1本目。

---

5. 注意・宿題

• 【セキュリティ・要対応】counter-app：git履歴に Stripe秘密鍵（STRIPE_SECRET_KEY / STRIPE_WEBHOOK_SECRET）が残存。Stripeダッシュボードで鍵をローテーションすること。public化したい場合は履歴クリーン化（git filter-repo等）＋鍵入替を実施してから。
• site.ts の youtube リンク：src/data/site.ts の links.youtube が残っている（表示はされないがJsonLdのsameAsに入る）。YouTube対象外なので削除推奨（次のデプロイで反映）。
• デプロイ運用の注意：npm run dev 稼働中に npm run build/npm run deploy を叩くと .next が壊れる（__webpack_modules__ ... is not a function）。同時に走らせない。壊れたら .next 削除→再起動。
• GitHub連携の自動デプロイは未設定：現状は手動 npm run deploy ＋ git push の二本立て。自動化したいならCloudflareダッシュボードでPagesをrepoに接続（一度きり）。

---

6. 参照ファイル（このワークスペース）

• 方針：01_ビジョン.md 02_ポジショニング.md 03_収益化.md
• 計画：04_ポートフォリオ計画.md 05_コンテンツ計画.md ロードマップ.md プロジェクト棚卸し.md
• ネタ：ideas/article-seeds.md（※2026-07-02にseeds-miyoki.md/seeds-nompass.mdへ移行済み・当時の記録）
• 発信物：output/記事/Zenn/2026-07-01-ai-portfolio-cloudflare-pages.md（Zenn初稿。※2026-07-04時点で在処確認済み：実際は下書き/Miyoki-Labs/Zenn/2026-07-01-ai-portfolio-cloudflare-pages.md）／output/アカウント設定/2026-07-01-アカウント設定手順書.md（準備キット）
• 前の引継ぎ：_handoff_to_miyoki_session.md（プランニング着手時のもの）

引き継ぎ：アカウント設定・ブランド相談（2026-07-02）

別セッションの冒頭にこの内容を貼れば、アカウント設定・ブランド周りの続きから動けます。 このタスクは「Miyoki Labs ブランドを全媒体に反映する」作業。開発とは分離してこちらで進める。

---

ゴール

エンジニア人格 Miyoki Labs を全媒体に統一して立ち上げる。Music人格（YouTube Miyoki_Music）とは完全分離。

確定していること

• ハンドル（全媒体共通）：miyoki_labs（GitHubのみ miyoki-labs）。※これがブランドの一意キー。
• 表示名：
• 技術媒体（Zenn / Qiita / GitHub）＝ Miyoki Labs
• 人格・日本語圏（note / X）＝ Miyoki Labs（三四輝）（「三四輝」は本名ではなく Miyoki の当て字。日本人個人の親近感を出すため。CWでも Miyoki(三四輝) を使用）
• プロフィール画像＝効果性で使い分け：
• 受託接点（クラウドワークス / Nompass LP / ポートフォリオ / note / X）＝人物アイコン（顔が見える方が信頼・成約に効く）
• 技術発信（Zenn / Qiita / GitHub）＝Mロゴ（記号的でプロ感）
• ※ハンドル・名前が共通なので2枚使いでも同一人物性は担保される。
• 自己紹介文（設定済み・note）：

「AIプロダクトエンジニア。個人でAIプロダクトを開発中。RAG・業務自動化・AIアプリの実装と、独学でここまで来た試行錯誤を発信します。」

画像アセット

• Mロゴ：C:\Miyoki\ロゴ_黒背景.png（黒背景・青紫グラデ・M×2）／webp版 miyoki-portfolio/public/logo-*.webp
• 人物アイコン：C:\Miyoki\人物アイコン_元画像.png（白背景・黒線画・眼鏡＋マスク・下に "Miyoki" 文字）
• バナー：C:\Miyoki\output\バナー画像\noteカバー.png / Xヘッダー.png

やることリスト（このセッションで進める）

1. 人物アイコンの余白調整（最優先の細かい依頼）
2. 現状 人物アイコン_元画像.png は円形トリミングすると顔がパツパツで、下の「Miyoki」文字が切れる。
3. png の周囲に余白（パディング）を足して全体を縮小し、円形トリミングでも人物＋"Miyoki"文字が収まるようにする。
4. トーンの統一：人物アイコン（白黒線画）と Mロゴ（黒背景・青紫）が並ぶと別ブランドに見える。人物アイコンにブランド色（青紫）を一点足す or 背景を寄せる検討。
5. note ヘッダーの作り直し：現行は 1920×1006 だが要素が端まで詰まっていて、note表示で上下（「AIでプロダクトを形にする」等）と右のMロゴが切れる。→ セーフエリア対応（主要素を縦横中央に集約、上下左右に余白）で作り直す。Canva で作成可（前回OGP作成の実績あり）。背景の紺〜紫グラデは活かす。
6. note 過去記事（Music系）の処理：未決定。非公開（削除しない）推奨。ただし「音楽→AIへ転換した話」は note のビジョン記事として新記事に書き直す価値あり（そのまま残すのではなく再構成）。
7. （任意）波形なし Mロゴ版：現行Mロゴ中央の波形は Music 由来。エンジニアブランドとして純化したいなら波形なし版を作る選択肢。
8. 各媒体リネーム（手作業）：
9. note … ID miyoki_labs 取得済み・クリエイター名/自己紹介設定済み・ヘッダーと過去記事が残課題。
10. X / Zenn / Qiita / GitHub … 未リネーム。手順は output/アカウント設定/2026-07-01-アカウント設定手順書.md（※旧ハンドル候補は無効。miyoki_labsで上書き）。

リネーム完了後に開発側でやること（別途・開発セッション）

ポートフォリオのハンドル一括差し替え → npm run deploy：

• miyoki-portfolio/src/data/site.ts … github Miyoki347→miyoki-labs／zenn miyoki347→miyoki_labs／qiita Miyoki347→miyoki_labs／x Miyoki_Music→miyoki_labs／note miyoki_music→miyoki_labs
• miyoki-portfolio/src/data/articles.ts … ZENN_USER/QIITA_USER を miyoki_labs（note は対応済み）
• miyoki-portfolio/src/data/works.ts … repoリンクの github.com/Miyoki347/* を新ハンドルへ

参照

• ブランド方針：05_コンテンツ計画.md §1-2 / メモリ miyoki-labs-branding / 引き継ぎ/2026-07-01_ブランド統一と記事カード.md
• 手順書：output/アカウント設定/2026-07-01-アカウント設定手順書.md