{
  "schema": "urokogumo-site-content/v1",
  "generatedAt": "2026-09-19T12:13:53.135Z",
  "site": {
    "id": "urokogumo-tech",
    "name": "urokogumo Tech",
    "tagline": "n8n、インフラ、自動化のログ",
    "description": "urokogumo Techは実装と運用の技術ログ。n8n・インフラ・社内ツール・マルチサイト。記事は urokogumo.org/tech と同一ソース。うろこ手帖（人間味）とは別チャネル。",
    "url": "https://tech.urokogumo.org",
    "locale": "ja",
    "template": "media",
    "contact": {
      "email": "contact@urokogumo.org",
      "address": "〒277-0827 千葉県柏市松葉町2丁目15-11 よしいビル2階E号室"
    },
    "social": null
  },
  "machineReadable": {
    "llmsTxt": "https://tech.urokogumo.org/llms.txt",
    "llmsFullTxt": "https://tech.urokogumo.org/llms-full.txt",
    "contentJson": "https://tech.urokogumo.org/content.json",
    "sitemap": "https://tech.urokogumo.org/sitemap.xml"
  },
  "pages": [
    {
      "title": "Home",
      "path": "/",
      "summary": "合同会社urokogumo の技術メディア。n8n ワークフロー、Vercel マルチサイト、Slack 連携、社内ツール運用の実装メモ。記事は tech.urokogumo.org と urokogumo.org/tech で共有。RSS: /feed.xml。",
      "url": "https://tech.urokogumo.org/"
    },
    {
      "title": "Posts",
      "path": "/posts",
      "summary": "8 articles",
      "url": "https://tech.urokogumo.org/posts"
    },
    {
      "title": "RSS",
      "path": "/feed.xml",
      "summary": "Atom/RSS feed",
      "url": "https://tech.urokogumo.org/feed.xml"
    },
    {
      "title": "About",
      "path": "/#about",
      "summary": "実装メモ、構成の選び方、運用で効いたこと。失敗や制約も残す。社内 Lab から説明できる形に整えた記事がここに載る。",
      "url": "https://tech.urokogumo.org/#about"
    },
    {
      "title": "Audience",
      "path": "/#for",
      "summary": "Who this is for",
      "url": "https://tech.urokogumo.org/#for"
    },
    {
      "title": "FAQ",
      "path": "/#faq",
      "summary": "Frequently asked questions",
      "url": "https://tech.urokogumo.org/#faq"
    },
    {
      "title": "プライバシーポリシー",
      "path": "/privacy",
      "url": "https://tech.urokogumo.org/privacy"
    },
    {
      "title": "利用規約",
      "path": "/terms",
      "url": "https://tech.urokogumo.org/terms"
    },
    {
      "title": "Contact",
      "path": "https://urokogumo.org/contact",
      "summary": "contact@urokogumo.org",
      "url": "https://tech.urokogumo.org/https://urokogumo.org/contact"
    }
  ],
  "content": {
    "template": "media",
    "hero": {
      "eyebrow": "urokogumo Tech · tech.urokogumo.org",
      "title": "実装と運用のログを、そのまま公開する。",
      "lead": "n8n・インフラ・自動化・社内ツール。小さなチームが実際に回している構成と手順のメモ。記事本体は urokogumo.org/tech と同一ソースです。"
    },
    "sections": [
      {
        "title": "何を書くか",
        "body": "実装メモ、構成の選び方、運用で効いたこと。失敗や制約も残す。社内 Lab から説明できる形に整えた記事がここに載る。"
      },
      {
        "title": "記事の出典",
        "body": "Markdown は content/sites/urokogumo/tech/ が正本。tech.urokogumo.org は contentSources で同じチャネルを読む。urokogumo.org/tech と二重管理しない。"
      },
      {
        "title": "うろこ手帖との違い",
        "body": "notes.urokogumo.org（うろこ手帖）は旅・食・会社づくりの人間味ログ。ここは技術の深掘り専用。トーンも読者も分ける。"
      },
      {
        "title": "何を書かないか",
        "body": "クライアント固有の秘密、本番の認証情報、未整理の雑メモ。荒い実験は Lab。実績として外に出せるものは Works / Services 側へ。"
      }
    ],
    "cards": [
      {
        "title": "n8n / 自動化",
        "body": "ワークフロー、Slack 連携、バッチの切り方。手作業を減らす設計メモ。"
      },
      {
        "title": "インフラ / デプロイ",
        "body": "Vercel マルチサイト、環境分離、監視とコスト。小さなチーム向けの構成選択。"
      },
      {
        "title": "社内ツール / ops",
        "body": "自社で回す仕組みの公開版。Cursor SDK、フォーム監視、情報整理の単一入口など。"
      },
      {
        "title": "マルチサイト運用",
        "body": "monorepo・media テンプレ・contentSources。Tech がコーポレート tech チャネルを共有する実例。"
      }
    ],
    "cta": {
      "label": "記事一覧",
      "href": "/posts"
    },
    "audience": [
      {
        "title": "n8n / 自動化 / インフラに興味があるエンジニア",
        "body": "ワークフロー設計、連携の切り方、デプロイと監視の実務メモを探す人向け。チュートリアルより、実際に動かしている構成の記録。"
      },
      {
        "title": "社内ツール・マルチサイト運用の実践例を探す人",
        "body": "小さな会社が contentSources や monorepo で複数サイトを回す例、Lab → Tech への昇格の考え方など、運用の型を参照したい人向け。"
      },
      {
        "title": "urokogumo.org/tech と同じ記事を tech.urokogumo.org で読む人",
        "body": "記事 Markdown は urokogumo の tech チャネルを contentSources で参照。ドメインが違っても中身は同じ。RSS は /feed.xml。"
      }
    ],
    "faq": [
      {
        "q": "うろこ手帖（notes）との違いは？",
        "a": "手帖は旅・食・会社づくりなど人間味のログ（notes.urokogumo.org）。Tech は n8n・インフラ・自動化・社内ツールの技術深掘り専用。同じ会社でもチャネルを分けている。"
      },
      {
        "q": "記事の出典はどこ？ urokogumo.org/tech と同じ？",
        "a": "同じ。正本は urokogumo サイトの tech チャネル（Markdown）。tech.urokogumo.org は contentSources でそのチャネルを読むだけなので、記事を二重に置かない。"
      },
      {
        "q": "RSS はある？",
        "a": "ある。https://tech.urokogumo.org/feed.xml（パスは /feed.xml）。記事一覧は /posts。"
      },
      {
        "q": "何を書かないか？",
        "a": "秘密情報・本番クレデンシャル・クライアント固有の非公開情報は書かない。未整理の実験は Lab。外向け実績は Works / Services。ここは再現可能な技術メモに限定する。"
      },
      {
        "q": "誰向け？",
        "a": "自動化・インフラ・ops に興味があるエンジニア、社内ツールやマルチサイト運用の実例を探す人、urokogumo.org/tech と同じ記事を tech サブドメインで読む人。"
      }
    ],
    "highlights": [
      {
        "title": "同一ソース・二ドメイン",
        "body": "tech.urokogumo.org と urokogumo.org/tech は同じ tech 記事。複製せず contentSources で参照。"
      },
      {
        "title": "RSS",
        "body": "購読は /feed.xml。新着はフィード経由で追える。"
      },
      {
        "title": "Lab → Tech",
        "body": "荒い実験は Lab。人に説明できる形になったら Tech へ昇格。"
      },
      {
        "title": "実務ログ",
        "body": "製品紹介ではなく、動かしている構成と手順の記録。再現と判断材料を優先。"
      }
    ],
    "seo": {
      "title": "urokogumo Tech — n8n / インフラ / 自動化の技術ログ",
      "description": "合同会社urokogumo の技術メディア。n8n ワークフロー、Vercel マルチサイト、Slack 連携、社内ツール運用の実装メモ。記事は tech.urokogumo.org と urokogumo.org/tech で共有。RSS: /feed.xml。",
      "keywords": [
        "n8n",
        "自動化",
        "インフラ",
        "Vercel",
        "マルチサイト",
        "社内ツール",
        "Slack",
        "Cursor",
        "ops",
        "urokogumo",
        "tech.urokogumo.org"
      ]
    }
  },
  "news": [
    {
      "slug": "2026-06-info-organize-03-single-entry",
      "title": "通知は増やさない。毎朝ひとつの入口にまとめる業務改善",
      "date": "2026-06-24",
      "summary": "Slack などは作業場所ではなく入口。通知を増やさず、必要なときに業務画面へ誘導する。",
      "body": "[1本目](/tech/2026-06-info-organize-01-morning-view)で「毎朝見る画面」、[2本目](/tech/2026-06-info-organize-02-pick-select-apply)で「拾う・選ぶ・反映する」を書きました。最後は **通知と入口** の話です。\n\n## 通知が増えると、仕事が止まる\n\nチャットツールは便利です。依頼が早い。雑談もできる。ただ、**通知は作業場所ではありません**。\n\n- ポップアップが出るたびに集中が切れる\n- 「とりあえず返信」で終わり、タスク化されない\n- 重要なものと雑談が同じ速度で流れる\n\n小さな会社ほど、全員が同じチャンネルを見ていることが多く、**通知の量＝全員の負荷** になりやすいです。\n\n## 方針：通知を増やさない\n\nうちで試しているのは、次のルールです。\n\n1. **新しい通知チャンネルを増やさない**（既存の入口を増殖させない）\n2. 依頼や更新は **業務画面に載せる**（朝見る場所に寄せる）\n3. チャットは **「見に行ってください」ではなく「載せました」** の確認程度に留める\n\nつまり、Slack（やメール）は **入口の裏方** に寄せ、**毎朝開く画面** を業務の正面に置きます。\n\n## 入口が一つあると何が変わるか\n\n- 朝のルーティンが固定される（[1本目](/tech/2026-06-info-organize-01-morning-view)の話）\n- 「見落とした」が **画面を見ていない** 問題として話せる\n- チャットを追いかけなくても、**載ったものは載った** 状態になる\n\n全員が常にチャットを監視している必要が減ります。緊急の連絡は別ルート（電話、明示的なメンションルール）で足ります。\n\n## AI との組み合わせ\n\n[2本目](/tech/2026-06-info-organize-02-pick-select-apply)の「拾う・選ぶ・反映」がここで効きます。\n\n- チャットに流れた依頼 → AI が **候補として拾う**\n- 人が **選ぶ**\n- 選んだものだけ **業務画面に反映**\n\nチャットに新しい Bot 通知を足すのではなく、**既存の流れを業務画面側で受け止める** イメージです。通知音が増えないのがポイントです。\n\n## うまくいかなかったこと\n\n- 最初は「全部チャットで完結」派がいた → 習慣の移行に時間がかかった\n- 業務画面が見づらいと、結局チャットに戻る → UI もセットで直した\n- 「載せる」ルールが曖昧だと、誰も載せない → 最低限のテンプレを決めた\n\n## 小さな会社で再現するなら\n\n大規模な開発は不要です。\n\n1. **毎朝開く URL を決める**（スプレッドシートでも可）\n2. **「載せる」担当をローテーション** しない（全員が載せられる形に）\n3. **チャットは入口、画面は作業場** とチームで合意する\n4. AI は載せる前の **下書き** から始める\n\n完璧な統合より、**通知が増えない** ことを優先しました。\n\n## シリーズのまとめ\n\n| # | テーマ |\n|---|--------|\n| 1 | [毎朝何を見るか決める](/tech/2026-06-info-organize-01-morning-view) |\n| 2 | [拾う・選ぶ・反映する](/tech/2026-06-info-organize-02-pick-select-apply) |\n| 3 | **本記事** … 通知を増やさず入口を一つに |\n\nurokogumo は小さな会社です。情報整理は「大きな DX」ではなく、**毎朝の見方と、AI の使い所を決める** ことから始まりました。\n\n同じ規模の会社で、入口が増えすぎていると感じたら、参考になれば幸いです。\n\n---\n\nシリーズ: [小さな会社のための情報整理](/tech/2026-06-info-organize-01-morning-view) · 3 / 3",
      "url": "https://tech.urokogumo.org/posts/2026-06-info-organize-03-single-entry"
    },
    {
      "slug": "2026-06-info-organize-02-pick-select-apply",
      "title": "AIに任せきらない。拾う・選ぶ・反映する、社内タスク整理の考え方",
      "date": "2026-06-23",
      "summary": "AIが拾い、人が選び、必要なものだけ仕事に反映する。現実の業務に入れる設計の話。",
      "body": "[前回](/tech/2026-06-info-organize-01-morning-view)は、毎朝見る場所と順番を決めた話でした。今回は、その画面に**何を載せるか**——特に AI をどこまで使うか——です。\n\n## 「AI 導入」より先に決めたこと\n\nうちは AI を使っています。ただ、最初のゴールは **「AI で全部自動化」ではありません**。\n\n現場で本当に困っていたのは、\n\n- 依頼がチャットの流れに埋もれる\n- 口頭で終わったつもりのことがタスクにならない\n- 共有ドライブに置いたが、誰も見に行かない\n\nといった **拾い漏れと、拾ったあとの行方** でした。\n\nだから設計は3段階に分けました。\n\n## 拾う · 選ぶ · 反映する\n\n| 段階 | 誰が | 何をする |\n|------|------|----------|\n| **拾う** | AI（＋ルール） | 散らばった情報から「候補」を抽出する |\n| **選ぶ** | 人 | 今日やるか、保留か、不要かを決める |\n| **反映する** | 人（＋ツール） | 選んだものだけタスクや業務画面に載せる |\n\n**拾う**は AI が向いています。文章の要約、カテゴリ分け、重複の検出——ルールを決めれば、一定の精度で回せます。\n\n**選ぶ**は人が向いています。優先度、緊急度、誰がやるか、本当に今必要か——ここを AI に任せきると、現場の違和感が溜まります。\n\n**反映する**は、選んだ結果を仕事の形に落とす段階です。タスク管理に登録する、カレンダーに載せる、業務画面の「今日やること」に入れる——**反映先を一つに寄せる**と、前回書いた「毎朝見る画面」とつながります。\n\n## AI 万能論を避ける理由\n\n小さな会社では、間違った自動化のコストが大きいです。\n\n- 不要なタスクが増える\n- 現場が「AI が勝手に作った」と感じて使わなくなる\n- 結局、人が全部チェックする二重作業になる\n\nうちの方針は **「AI は下書き係。決定権は人」** です。候補として並べ、人が yes / no / あとで を選ぶ。選ばれなかったものは捨ててよい（またはアーカイブ）。\n\n## うまくいっている使い方\n\n- 長いやりとりから **「タスクになりそうな一文」** だけ抜き出す\n- 似た依頼が既にないか **重複チェックのたたき台** を出す\n- 載せる前に **一行サマリ** を AI に書かせ、人が修正する\n\nうまくいっていない使い方もあります。**優先度の最終判断** や **見積もり** を AI だけで決める——ここはまだ人の領域です。\n\n## 小さな会社向けの現実ライン\n\n- 完璧な分類より、**毎日同じ画面で見られる量** を守る\n- AI の出力は **提案** とラベル付けする（確定ではない）\n- 週に一度、人が「溜まりすぎていないか」を見る\n\n## 次回\n\n[3本目](/tech/2026-06-info-organize-03-single-entry)では、Slack などの **通知を増やさず、業務画面へ誘導する** 話を書きます。入口は一つ、作業場所も一つ——通知疲れを減らす設計です。\n\n---\n\nシリーズ: [小さな会社のための情報整理](/tech/2026-06-info-organize-01-morning-view) · 2 / 3",
      "url": "https://tech.urokogumo.org/posts/2026-06-info-organize-02-pick-select-apply"
    },
    {
      "slug": "2026-06-info-organize-01-morning-view",
      "title": "情報を集めるだけでは足りない。毎朝“何を見るか”を決める仕組みを作った",
      "date": "2026-06-22",
      "summary": "情報が増えるほど仕事は進みにくくなる。だから、毎朝見る場所と見る順番を決めた。",
      "body": "合同会社 urokogumo は小さな会社です。メンバーは少ない一方で、案件・開発・運用・事務が同時に動きます。チャット、メール、共有ドライブ、タスク管理——入口は増え続けました。\n\n## 集めるほど、見失う\n\n情報を「ためる」こと自体は悪くありません。むしろ、残しておかないとあとで困います。\n\nただ、**集めただけでは仕事は進みません**。朝、どこから手を付けるか迷う時間が長くなる。昨日の続きがどこにあったか思い出すのにエネルギーを使う。気づけば午前中が「確認」で終わる——そんな日が続いていました。\n\n小さな会社ほど、一人あたりの「見るべき場所」が多くなりがちです。全員が全部を見る必要はないのに、入口がバラバラだと、各自が自分なりに探し回ることになります。\n\n## 毎朝の業務画面、という考え方\n\nうちで試しているのは、**毎朝ひとつの業務画面を開き、決めた順番で見る**というシンプルなルールです。\n\n- 今日やること（タスク）\n- 期限や更新が近いもの\n- 前日から持ち越した未読・未整理\n- 社内からの依頼や相談\n\n「全部のツールを巡回する」のではなく、**業務の起点になる画面**に情報を寄せます。詳細は元の場所に残してよい。大事なのは、**朝の最初の15分で何を見るかが決まっている**ことです。\n\n## 小さく始めた理由\n\n最初から大きな基幹システムを作るつもりはありませんでした。小さな会社に必要なのは、\n\n- 毎日使う\n- 説明が短い\n- 誰が見ても同じ順番で読める\n\nという条件を満たす**見方の型**です。ツールを増やす前に、**見る順番**を決めました。\n\n## うまくいったこと\n\n- 朝の立ち上がりが速くなった（「どこを見るか」で迷わない）\n- 「見落とし」を共有の言葉で話せるようになった\n- 情報の追加先が「とりあえずチャット」から「業務画面に載せる」に寄った\n\n## まだ課題\n\n- 載せすぎると画面が太る（次の記事で「選ぶ」話につながる）\n- 習慣化には時間がかかる\n- 案件や役割によって見る範囲は違う\n\n## このシリーズについて\n\n**小さな会社のための情報整理**——3本で、うちの試行を一般化して書きます。\n\n1. **本記事** … 毎朝何を見るか決める\n2. [AIに任せきらない。拾う・選ぶ・反映する](/tech/2026-06-info-organize-02-pick-select-apply)\n3. [通知は増やさない。ひとつの入口にまとめる](/tech/2026-06-info-organize-03-single-entry)\n\nAI が全部を自動でやる話ではありません。**人が仕事を進めるための、情報の置き方**のメモです。",
      "url": "https://tech.urokogumo.org/posts/2026-06-info-organize-01-morning-view"
    },
    {
      "slug": "2026-06-multisite-seven-sites",
      "title": "7 サイト monorepo に mist と Tech を足した",
      "date": "2026-06-21",
      "summary": "SITE_ID で切り替える 1 エンジン構成を 5 → 7 サイトに拡張。Vercel プロジェクトと main 未反映の落とし穴。",
      "body": "urokogumo 公開サイトは **1 リポジトリ・1 Next.js（apps/web）・SITE_ID 切替** で運用しています。2026-06 時点で **7 ドメイン** です。\n\n## サイト一覧\n\n| SITE_ID | URL | テンプレート |\n|---------|-----|-------------|\n| urokogumo | urokogumo.org | corporate |\n| snow-kotan | snow-kotan.com | restaurant |\n| pon-kotan | ponkotan.cafe | brand |\n| kotan-atelier | kotan-atelier.com | brand |\n| uroko-notes | notes.urokogumo.org | media |\n| mist | mist.urokogumo.org | service |\n| urokogumo-tech | tech.urokogumo.org | media（記事は urokogumo/tech 共有） |\n\n## 追加したもの\n\n- `packages/site-core/src/sites.ts` に mist / urokogumo-tech\n- `content/sites/mist/`、`components/themes/service/`\n- media テンプレと `contentSources`（Tech は urokogumo の tech チャネルを参照）\n\n## Vercel の共通設定\n\n| 項目 | 値 |\n|------|-----|\n| Root Directory | `multisite/apps/web` |\n| Install / Build Override | **すべて OFF** |\n| Include files outside Root | **ON** |\n| 環境変数 | プロジェクトごとに `SITE_ID` のみ変更 |\n\nプロジェクト例: `urokogumo-web`, `mist-web`, `urokogumo-tech-web` など **7 本**。\n\n## ハマった: mist が urokogumo になる\n\nVercel の `SITE_ID=mist` が正しくても、**GitHub main に mist 定義が無い** と `parseSiteId` が失敗し urokogumo にフォールバックします。\n\n対処: ローカルで `npm run build:mist` が通ったら **main に push → Redeploy（Clear cache ON）**。\n\n## 削除した混乱源\n\n統合済みの `apps/urokogumo` / `apps/snow-kotan` は削除。触るのは **apps/web だけ**。\n\n## 関連\n\n- [Vercel マルチサイト構成（2025）](/tech/2025-12-vercel-multisite)\n- [Works: monorepo 再構築](/works/2026-02-multisite-rebuild)",
      "url": "https://tech.urokogumo.org/posts/2026-06-multisite-seven-sites"
    },
    {
      "slug": "2026-06-slack-cursor-fix-watch",
      "title": "Slack 指示を Cursor SDK で自動編集する（fix:watch）",
      "date": "2026-06-21",
      "summary": "site-bot + fix-inbox + @cursor/sdk。OpenAI API なしで「Slack → コード変更 → localhost 確認」まで回した。",
      "body": "[以前の n8n 試作](/tech/2026-03-n8n-slack-handoff) から、**Cursor SDK 直結** に寄せました。OpenAI の従量 API は使いません。\n\n## フロー\n\n```\nSlack: /fix mist トップの文言を短く\n  ↓\nsite-bot (:3102) — 署名検証、fix-inbox に依頼保存\n  ↓\nfix:watch — キュー監視\n  ↓\nCursor SDK (Agent.prompt) — apps/web / content/ を編集\n  ↓\nlocalhost で確認 → git push → Vercel\n```\n\n## 主要コンポーネント\n\n| パス | 役割 |\n|------|------|\n| `apps/site-bot` | Slack `/fix`, `/fix-list` |\n| `fix-inbox/*.md` | エージェントへの指示書（gitignore） |\n| `scripts/fix-watch.mjs` | 未処理を SDK に自動渡し |\n| `scripts/cursor-handoff.mjs` | `@cursor/sdk` ラッパー |\n\n## 最小セットアップ\n\n```bash\ncd multisite\ncp apps/site-bot/.env.example apps/site-bot/.env.local\n# CURSOR_API_KEY, SLACK_SIGNING_SECRET, FIX_BACKEND=cursor\n\nnpm install\nnpm run dev:mist              # プレビュー :3106\nnpm run slack:daemon          # bot + fix:watch + ngrok\n```\n\nSlack なしテスト:\n\n```bash\nnpm run fix:simulate -- mist フッターの年を2026に\n```\n\n## FIX_BACKEND\n\n| 値 | 動作 |\n|----|------|\n| `handoff` | キュー保存のみ（手動 Cursor 可） |\n| `cursor` | SDK 自動編集（推奨） |\n| `openai` | 有料 API + GitHub commit（今回は使わない） |\n\n## 依存でつまずいた点\n\n`@cursor/sdk` 単体では足りず、`@connectrpc/connect-node` を明示 install する必要がありました。\n\n```bash\nnpm i @connectrpc/connect-node @connectrpc/connect -D\n```\n\n## 編集される範囲\n\n- `content/sites/{SITE_ID}/site.json`\n- テンプレ別 `HomePage.tsx`\n- `globals.css`, Header, Footer など（site-bot の `getEditablePaths` 参照）\n\n## 関連\n\n- [Cursor SDK の課金枠メモ（Lab）](/lab/2026-06-cursor-sdk-billing)\n- [mist サイト追加](/tech/2026-06-multisite-seven-sites)",
      "url": "https://tech.urokogumo.org/posts/2026-06-slack-cursor-fix-watch"
    },
    {
      "slug": "2026-06-tech-start",
      "title": "Tech ブログを始めます",
      "date": "2026-06-18",
      "summary": "n8n、インフラ、自動化など。うろこ手帖とは分けて、技術の深掘りをここに書きます。",
      "body": "うろこ手帖は旅・食・会社づくりのログに寄せます。技術の手順や構成の話は、この **Tech** チャネルに書きます。\n\n## すでにある記事\n\n- [Vercel マルチサイト構成](/tech/2025-12-vercel-multisite)\n- [n8n × Slack 修正依頼](/tech/2026-03-n8n-slack-handoff)\n- [7 サイト monorepo（mist / Tech 追加）](/tech/2026-06-multisite-seven-sites)\n- [Slack × Cursor SDK（fix:watch）](/tech/2026-06-slack-cursor-fix-watch)\n\n### シリーズ: 小さな会社のための情報整理\n\n業務改善・AI 活用の考え方（3本）。\n\n1. [毎朝“何を見るか”を決める](/tech/2026-06-info-organize-01-morning-view)\n2. [拾う・選ぶ・反映する](/tech/2026-06-info-organize-02-pick-select-apply)\n3. [通知は増やさない](/tech/2026-06-info-organize-03-single-entry)\n\n### Lab（荒いログ）\n\n- [Cursor SDK 課金枠](/lab/2026-06-cursor-sdk-billing)\n- [mist LP を SDK 編集](/lab/2026-06-mist-lp-cursor-edit)\n- [旧 apps 削除](/lab/2026-06-monorepo-cleanup)\n\n## 昇格の想定\n\n1. **Lab** … 試してみたログ\n2. **Tech** … 人に説明できる形に整理\n3. **Works** … クライアント OK の実績\n4. **Services / MIST** … サービスとして打ち出す\n\nまずは読める実例から増やしていきます。",
      "url": "https://tech.urokogumo.org/posts/2026-06-tech-start"
    },
    {
      "slug": "2026-03-n8n-slack-handoff",
      "title": "n8n で Slack 修正依頼を Cursor に渡す",
      "date": "2026-03-05",
      "summary": "site-bot + n8n + 手元スクリプトで「Slackで指摘 → 修正キュー → エージェント」の流れを試作。",
      "body": "社内の「ここ直して」を Slack に投げたら、修正キューに乗って Cursor 側で拾える——そんな流れの試作です。\n\n## フロー\n\n1. Slack で `/fix` またはメンションで指摘\n2. `apps/site-bot` が内容を整形してキュー JSON に追加\n3. `npm run fix:list` / `fix:apply` で手元 or CI から適用\n4. 適用結果を Slack に返す（任意）\n\n## なぜ n8n を挟むか\n\n- 将来的に **GitHub Issue 連携** や **承認ステップ** をノーコードで足したい\n- Slack 以外（フォーム、メール）からの入口も同じキューに流したい\n\n## 学び\n\n- 最初から完全自動より **「キューに乗る」まで** を堅牢にした方が運用が続く\n- 修正対象を `SITE_ID` 単位にすると、multisite 構成と相性がいい\n\n## ステータス\n\n本番運用前の **Lab 昇格候補**。失敗パターンは [Lab: fix-queue 試作](/lab/2026-01-fix-queue) に残しています。",
      "url": "https://tech.urokogumo.org/posts/2026-03-n8n-slack-handoff"
    },
    {
      "slug": "2025-12-vercel-multisite",
      "title": "Vercel で 1 リポジトリから複数ドメインを配信する",
      "date": "2025-12-20",
      "summary": "SITE_ID と ignore build step で、urokogumo.org / snow-kotan.com 等を分岐デプロイ。",
      "body": "urokogumo の公開サイトは **1つの Next.js アプリ** から複数ドメインを配信しています。\n\n## 構成の要点\n\n| 要素 | 役割 |\n|------|------|\n| `SITE_ID` 環境変数 | ビルド時にどのサイトか決定 |\n| `@urokogumo/site-core` | サイト定義・URL・テンプレ種別 |\n| `content/sites/{id}/` | 文章・team・サービス定義 |\n| `vercel-ignore.sh` | 変更のないサイトはビルドスキップ |\n\n## なぜやるか\n\n- キッチンカー用のデザインと会社サイトを **同じコンポーネント資産** で保ちたい\n- コンテンツ担当が JSON / Markdown だけ触れるようにしたい\n- 将来 `tech.urokogumo.org` を別プロジェクトにしても **記事フォルダは共有** したい\n\n## コード側のイメージ\n\n```typescript\n// packages/site-core — サイトはデータで切替\nexport const SITES: Record<SiteId, SiteConfig> = { ... };\n\n// apps/web — テンプレート出し分け\nif (site.template === \"corporate\") return <CorporateHome />;\nif (site.template === \"restaurant\") return <RestaurantHome />;\n```\n\n## ハマったところ\n\n- Vercel の `outputFileTracingRoot` が環境によって二重パスになる → 本番のみ無効化\n- 各プロジェクトの Root Directory を `multisite/apps/web` に統一\n\n## 関連\n\n- [Works: 公式サイト monorepo 再構築](/works/2026-02-multisite-rebuild)\n- Lab では fix-queue など社内ツールの試作ログを別チャネルに置いています",
      "url": "https://tech.urokogumo.org/posts/2025-12-vercel-multisite"
    }
  ]
}