# urokogumo Tech — full public content

Generated from: https://tech.urokogumo.org
Language: ja

---

# Site metadata
name: urokogumo Tech
description: urokogumo Techは実装と運用の技術ログ。n8n・インフラ・社内ツール・マルチサイト。記事は urokogumo.org/tech と同一ソース。うろこ手帖（人間味）とは別チャネル。
tagline: n8n、インフラ、自動化のログ
url: https://tech.urokogumo.org
email: contact@urokogumo.org
address: 〒277-0827 千葉県柏市松葉町2丁目15-11 よしいビル2階E号室

---

# Hero
urokogumo Tech · tech.urokogumo.org
実装と運用のログを、そのまま公開する。
n8n・インフラ・自動化・社内ツール。小さなチームが実際に回している構成と手順のメモ。記事本体は urokogumo.org/tech と同一ソースです。

# Sections
## 何を書くか
実装メモ、構成の選び方、運用で効いたこと。失敗や制約も残す。社内 Lab から説明できる形に整えた記事がここに載る。

## 記事の出典
Markdown は content/sites/urokogumo/tech/ が正本。tech.urokogumo.org は contentSources で同じチャネルを読む。urokogumo.org/tech と二重管理しない。

## うろこ手帖との違い
notes.urokogumo.org（うろこ手帖）は旅・食・会社づくりの人間味ログ。ここは技術の深掘り専用。トーンも読者も分ける。

## 何を書かないか
クライアント固有の秘密、本番の認証情報、未整理の雑メモ。荒い実験は Lab。実績として外に出せるものは Works / Services 側へ。

# Cards
## n8n / 自動化
ワークフロー、Slack 連携、バッチの切り方。手作業を減らす設計メモ。

## インフラ / デプロイ
Vercel マルチサイト、環境分離、監視とコスト。小さなチーム向けの構成選択。

## 社内ツール / ops
自社で回す仕組みの公開版。Cursor SDK、フォーム監視、情報整理の単一入口など。

## マルチサイト運用
monorepo・media テンプレ・contentSources。Tech がコーポレート tech チャネルを共有する実例。

---

# Pages index
- Home: https://tech.urokogumo.org/
- Posts: https://tech.urokogumo.org/posts
- RSS: https://tech.urokogumo.org/feed.xml
- About: https://tech.urokogumo.org/#about
- Audience: https://tech.urokogumo.org/#for
- FAQ: https://tech.urokogumo.org/#faq
- プライバシーポリシー: https://tech.urokogumo.org/privacy
- 利用規約: https://tech.urokogumo.org/terms
- Contact: https://tech.urokogumo.org/https://urokogumo.org/contact

---

# News (full text)
## 通知は増やさない。毎朝ひとつの入口にまとめる業務改善
date: 2026-06-24
url: https://tech.urokogumo.org/posts/2026-06-info-organize-03-single-entry
summary: Slack などは作業場所ではなく入口。通知を増やさず、必要なときに業務画面へ誘導する。

[1本目](/tech/2026-06-info-organize-01-morning-view)で「毎朝見る画面」、[2本目](/tech/2026-06-info-organize-02-pick-select-apply)で「拾う・選ぶ・反映する」を書きました。最後は **通知と入口** の話です。

## 通知が増えると、仕事が止まる

チャットツールは便利です。依頼が早い。雑談もできる。ただ、**通知は作業場所ではありません**。

- ポップアップが出るたびに集中が切れる
- 「とりあえず返信」で終わり、タスク化されない
- 重要なものと雑談が同じ速度で流れる

小さな会社ほど、全員が同じチャンネルを見ていることが多く、**通知の量＝全員の負荷** になりやすいです。

## 方針：通知を増やさない

うちで試しているのは、次のルールです。

1. **新しい通知チャンネルを増やさない**（既存の入口を増殖させない）
2. 依頼や更新は **業務画面に載せる**（朝見る場所に寄せる）
3. チャットは **「見に行ってください」ではなく「載せました」** の確認程度に留める

つまり、Slack（やメール）は **入口の裏方** に寄せ、**毎朝開く画面** を業務の正面に置きます。

## 入口が一つあると何が変わるか

- 朝のルーティンが固定される（[1本目](/tech/2026-06-info-organize-01-morning-view)の話）
- 「見落とした」が **画面を見ていない** 問題として話せる
- チャットを追いかけなくても、**載ったものは載った** 状態になる

全員が常にチャットを監視している必要が減ります。緊急の連絡は別ルート（電話、明示的なメンションルール）で足ります。

## AI との組み合わせ

[2本目](/tech/2026-06-info-organize-02-pick-select-apply)の「拾う・選ぶ・反映」がここで効きます。

- チャットに流れた依頼 → AI が **候補として拾う**
- 人が **選ぶ**
- 選んだものだけ **業務画面に反映**

チャットに新しい Bot 通知を足すのではなく、**既存の流れを業務画面側で受け止める** イメージです。通知音が増えないのがポイントです。

## うまくいかなかったこと

- 最初は「全部チャットで完結」派がいた → 習慣の移行に時間がかかった
- 業務画面が見づらいと、結局チャットに戻る → UI もセットで直した
- 「載せる」ルールが曖昧だと、誰も載せない → 最低限のテンプレを決めた

## 小さな会社で再現するなら

大規模な開発は不要です。

1. **毎朝開く URL を決める**（スプレッドシートでも可）
2. **「載せる」担当をローテーション** しない（全員が載せられる形に）
3. **チャットは入口、画面は作業場** とチームで合意する
4. AI は載せる前の **下書き** から始める

完璧な統合より、**通知が増えない** ことを優先しました。

## シリーズのまとめ

| # | テーマ |
|---|--------|
| 1 | [毎朝何を見るか決める](/tech/2026-06-info-organize-01-morning-view) |
| 2 | [拾う・選ぶ・反映する](/tech/2026-06-info-organize-02-pick-select-apply) |
| 3 | **本記事** … 通知を増やさず入口を一つに |

urokogumo は小さな会社です。情報整理は「大きな DX」ではなく、**毎朝の見方と、AI の使い所を決める** ことから始まりました。

同じ規模の会社で、入口が増えすぎていると感じたら、参考になれば幸いです。

---

シリーズ: [小さな会社のための情報整理](/tech/2026-06-info-organize-01-morning-view) · 3 / 3

---

## AIに任せきらない。拾う・選ぶ・反映する、社内タスク整理の考え方
date: 2026-06-23
url: https://tech.urokogumo.org/posts/2026-06-info-organize-02-pick-select-apply
summary: AIが拾い、人が選び、必要なものだけ仕事に反映する。現実の業務に入れる設計の話。

[前回](/tech/2026-06-info-organize-01-morning-view)は、毎朝見る場所と順番を決めた話でした。今回は、その画面に**何を載せるか**——特に AI をどこまで使うか——です。

## 「AI 導入」より先に決めたこと

うちは AI を使っています。ただ、最初のゴールは **「AI で全部自動化」ではありません**。

現場で本当に困っていたのは、

- 依頼がチャットの流れに埋もれる
- 口頭で終わったつもりのことがタスクにならない
- 共有ドライブに置いたが、誰も見に行かない

といった **拾い漏れと、拾ったあとの行方** でした。

だから設計は3段階に分けました。

## 拾う · 選ぶ · 反映する

| 段階 | 誰が | 何をする |
|------|------|----------|
| **拾う** | AI（＋ルール） | 散らばった情報から「候補」を抽出する |
| **選ぶ** | 人 | 今日やるか、保留か、不要かを決める |
| **反映する** | 人（＋ツール） | 選んだものだけタスクや業務画面に載せる |

**拾う**は AI が向いています。文章の要約、カテゴリ分け、重複の検出——ルールを決めれば、一定の精度で回せます。

**選ぶ**は人が向いています。優先度、緊急度、誰がやるか、本当に今必要か——ここを AI に任せきると、現場の違和感が溜まります。

**反映する**は、選んだ結果を仕事の形に落とす段階です。タスク管理に登録する、カレンダーに載せる、業務画面の「今日やること」に入れる——**反映先を一つに寄せる**と、前回書いた「毎朝見る画面」とつながります。

## AI 万能論を避ける理由

小さな会社では、間違った自動化のコストが大きいです。

- 不要なタスクが増える
- 現場が「AI が勝手に作った」と感じて使わなくなる
- 結局、人が全部チェックする二重作業になる

うちの方針は **「AI は下書き係。決定権は人」** です。候補として並べ、人が yes / no / あとで を選ぶ。選ばれなかったものは捨ててよい（またはアーカイブ）。

## うまくいっている使い方

- 長いやりとりから **「タスクになりそうな一文」** だけ抜き出す
- 似た依頼が既にないか **重複チェックのたたき台** を出す
- 載せる前に **一行サマリ** を AI に書かせ、人が修正する

うまくいっていない使い方もあります。**優先度の最終判断** や **見積もり** を AI だけで決める——ここはまだ人の領域です。

## 小さな会社向けの現実ライン

- 完璧な分類より、**毎日同じ画面で見られる量** を守る
- AI の出力は **提案** とラベル付けする（確定ではない）
- 週に一度、人が「溜まりすぎていないか」を見る

## 次回

[3本目](/tech/2026-06-info-organize-03-single-entry)では、Slack などの **通知を増やさず、業務画面へ誘導する** 話を書きます。入口は一つ、作業場所も一つ——通知疲れを減らす設計です。

---

シリーズ: [小さな会社のための情報整理](/tech/2026-06-info-organize-01-morning-view) · 2 / 3

---

## 情報を集めるだけでは足りない。毎朝“何を見るか”を決める仕組みを作った
date: 2026-06-22
url: https://tech.urokogumo.org/posts/2026-06-info-organize-01-morning-view
summary: 情報が増えるほど仕事は進みにくくなる。だから、毎朝見る場所と見る順番を決めた。

合同会社 urokogumo は小さな会社です。メンバーは少ない一方で、案件・開発・運用・事務が同時に動きます。チャット、メール、共有ドライブ、タスク管理——入口は増え続けました。

## 集めるほど、見失う

情報を「ためる」こと自体は悪くありません。むしろ、残しておかないとあとで困います。

ただ、**集めただけでは仕事は進みません**。朝、どこから手を付けるか迷う時間が長くなる。昨日の続きがどこにあったか思い出すのにエネルギーを使う。気づけば午前中が「確認」で終わる——そんな日が続いていました。

小さな会社ほど、一人あたりの「見るべき場所」が多くなりがちです。全員が全部を見る必要はないのに、入口がバラバラだと、各自が自分なりに探し回ることになります。

## 毎朝の業務画面、という考え方

うちで試しているのは、**毎朝ひとつの業務画面を開き、決めた順番で見る**というシンプルなルールです。

- 今日やること（タスク）
- 期限や更新が近いもの
- 前日から持ち越した未読・未整理
- 社内からの依頼や相談

「全部のツールを巡回する」のではなく、**業務の起点になる画面**に情報を寄せます。詳細は元の場所に残してよい。大事なのは、**朝の最初の15分で何を見るかが決まっている**ことです。

## 小さく始めた理由

最初から大きな基幹システムを作るつもりはありませんでした。小さな会社に必要なのは、

- 毎日使う
- 説明が短い
- 誰が見ても同じ順番で読める

という条件を満たす**見方の型**です。ツールを増やす前に、**見る順番**を決めました。

## うまくいったこと

- 朝の立ち上がりが速くなった（「どこを見るか」で迷わない）
- 「見落とし」を共有の言葉で話せるようになった
- 情報の追加先が「とりあえずチャット」から「業務画面に載せる」に寄った

## まだ課題

- 載せすぎると画面が太る（次の記事で「選ぶ」話につながる）
- 習慣化には時間がかかる
- 案件や役割によって見る範囲は違う

## このシリーズについて

**小さな会社のための情報整理**——3本で、うちの試行を一般化して書きます。

1. **本記事** … 毎朝何を見るか決める
2. [AIに任せきらない。拾う・選ぶ・反映する](/tech/2026-06-info-organize-02-pick-select-apply)
3. [通知は増やさない。ひとつの入口にまとめる](/tech/2026-06-info-organize-03-single-entry)

AI が全部を自動でやる話ではありません。**人が仕事を進めるための、情報の置き方**のメモです。

---

## 7 サイト monorepo に mist と Tech を足した
date: 2026-06-21
url: https://tech.urokogumo.org/posts/2026-06-multisite-seven-sites
summary: SITE_ID で切り替える 1 エンジン構成を 5 → 7 サイトに拡張。Vercel プロジェクトと main 未反映の落とし穴。

urokogumo 公開サイトは **1 リポジトリ・1 Next.js（apps/web）・SITE_ID 切替** で運用しています。2026-06 時点で **7 ドメイン** です。

## サイト一覧

| SITE_ID | URL | テンプレート |
|---------|-----|-------------|
| urokogumo | urokogumo.org | corporate |
| snow-kotan | snow-kotan.com | restaurant |
| pon-kotan | ponkotan.cafe | brand |
| kotan-atelier | kotan-atelier.com | brand |
| uroko-notes | notes.urokogumo.org | media |
| mist | mist.urokogumo.org | service |
| urokogumo-tech | tech.urokogumo.org | media（記事は urokogumo/tech 共有） |

## 追加したもの

- `packages/site-core/src/sites.ts` に mist / urokogumo-tech
- `content/sites/mist/`、`components/themes/service/`
- media テンプレと `contentSources`（Tech は urokogumo の tech チャネルを参照）

## Vercel の共通設定

| 項目 | 値 |
|------|-----|
| Root Directory | `multisite/apps/web` |
| Install / Build Override | **すべて OFF** |
| Include files outside Root | **ON** |
| 環境変数 | プロジェクトごとに `SITE_ID` のみ変更 |

プロジェクト例: `urokogumo-web`, `mist-web`, `urokogumo-tech-web` など **7 本**。

## ハマった: mist が urokogumo になる

Vercel の `SITE_ID=mist` が正しくても、**GitHub main に mist 定義が無い** と `parseSiteId` が失敗し urokogumo にフォールバックします。

対処: ローカルで `npm run build:mist` が通ったら **main に push → Redeploy（Clear cache ON）**。

## 削除した混乱源

統合済みの `apps/urokogumo` / `apps/snow-kotan` は削除。触るのは **apps/web だけ**。

## 関連

- [Vercel マルチサイト構成（2025）](/tech/2025-12-vercel-multisite)
- [Works: monorepo 再構築](/works/2026-02-multisite-rebuild)

---

## Slack 指示を Cursor SDK で自動編集する（fix:watch）
date: 2026-06-21
url: https://tech.urokogumo.org/posts/2026-06-slack-cursor-fix-watch
summary: site-bot + fix-inbox + @cursor/sdk。OpenAI API なしで「Slack → コード変更 → localhost 確認」まで回した。

[以前の n8n 試作](/tech/2026-03-n8n-slack-handoff) から、**Cursor SDK 直結** に寄せました。OpenAI の従量 API は使いません。

## フロー

```
Slack: /fix mist トップの文言を短く
  ↓
site-bot (:3102) — 署名検証、fix-inbox に依頼保存
  ↓
fix:watch — キュー監視
  ↓
Cursor SDK (Agent.prompt) — apps/web / content/ を編集
  ↓
localhost で確認 → git push → Vercel
```

## 主要コンポーネント

| パス | 役割 |
|------|------|
| `apps/site-bot` | Slack `/fix`, `/fix-list` |
| `fix-inbox/*.md` | エージェントへの指示書（gitignore） |
| `scripts/fix-watch.mjs` | 未処理を SDK に自動渡し |
| `scripts/cursor-handoff.mjs` | `@cursor/sdk` ラッパー |

## 最小セットアップ

```bash
cd multisite
cp apps/site-bot/.env.example apps/site-bot/.env.local
# CURSOR_API_KEY, SLACK_SIGNING_SECRET, FIX_BACKEND=cursor

npm install
npm run dev:mist              # プレビュー :3106
npm run slack:daemon          # bot + fix:watch + ngrok
```

Slack なしテスト:

```bash
npm run fix:simulate -- mist フッターの年を2026に
```

## FIX_BACKEND

| 値 | 動作 |
|----|------|
| `handoff` | キュー保存のみ（手動 Cursor 可） |
| `cursor` | SDK 自動編集（推奨） |
| `openai` | 有料 API + GitHub commit（今回は使わない） |

## 依存でつまずいた点

`@cursor/sdk` 単体では足りず、`@connectrpc/connect-node` を明示 install する必要がありました。

```bash
npm i @connectrpc/connect-node @connectrpc/connect -D
```

## 編集される範囲

- `content/sites/{SITE_ID}/site.json`
- テンプレ別 `HomePage.tsx`
- `globals.css`, Header, Footer など（site-bot の `getEditablePaths` 参照）

## 関連

- [Cursor SDK の課金枠メモ（Lab）](/lab/2026-06-cursor-sdk-billing)
- [mist サイト追加](/tech/2026-06-multisite-seven-sites)

---

## Tech ブログを始めます
date: 2026-06-18
url: https://tech.urokogumo.org/posts/2026-06-tech-start
summary: n8n、インフラ、自動化など。うろこ手帖とは分けて、技術の深掘りをここに書きます。

うろこ手帖は旅・食・会社づくりのログに寄せます。技術の手順や構成の話は、この **Tech** チャネルに書きます。

## すでにある記事

- [Vercel マルチサイト構成](/tech/2025-12-vercel-multisite)
- [n8n × Slack 修正依頼](/tech/2026-03-n8n-slack-handoff)
- [7 サイト monorepo（mist / Tech 追加）](/tech/2026-06-multisite-seven-sites)
- [Slack × Cursor SDK（fix:watch）](/tech/2026-06-slack-cursor-fix-watch)

### シリーズ: 小さな会社のための情報整理

業務改善・AI 活用の考え方（3本）。

1. [毎朝“何を見るか”を決める](/tech/2026-06-info-organize-01-morning-view)
2. [拾う・選ぶ・反映する](/tech/2026-06-info-organize-02-pick-select-apply)
3. [通知は増やさない](/tech/2026-06-info-organize-03-single-entry)

### Lab（荒いログ）

- [Cursor SDK 課金枠](/lab/2026-06-cursor-sdk-billing)
- [mist LP を SDK 編集](/lab/2026-06-mist-lp-cursor-edit)
- [旧 apps 削除](/lab/2026-06-monorepo-cleanup)

## 昇格の想定

1. **Lab** … 試してみたログ
2. **Tech** … 人に説明できる形に整理
3. **Works** … クライアント OK の実績
4. **Services / MIST** … サービスとして打ち出す

まずは読める実例から増やしていきます。

---

## n8n で Slack 修正依頼を Cursor に渡す
date: 2026-03-05
url: https://tech.urokogumo.org/posts/2026-03-n8n-slack-handoff
summary: site-bot + n8n + 手元スクリプトで「Slackで指摘 → 修正キュー → エージェント」の流れを試作。

社内の「ここ直して」を Slack に投げたら、修正キューに乗って Cursor 側で拾える——そんな流れの試作です。

## フロー

1. Slack で `/fix` またはメンションで指摘
2. `apps/site-bot` が内容を整形してキュー JSON に追加
3. `npm run fix:list` / `fix:apply` で手元 or CI から適用
4. 適用結果を Slack に返す（任意）

## なぜ n8n を挟むか

- 将来的に **GitHub Issue 連携** や **承認ステップ** をノーコードで足したい
- Slack 以外（フォーム、メール）からの入口も同じキューに流したい

## 学び

- 最初から完全自動より **「キューに乗る」まで** を堅牢にした方が運用が続く
- 修正対象を `SITE_ID` 単位にすると、multisite 構成と相性がいい

## ステータス

本番運用前の **Lab 昇格候補**。失敗パターンは [Lab: fix-queue 試作](/lab/2026-01-fix-queue) に残しています。

---

## Vercel で 1 リポジトリから複数ドメインを配信する
date: 2025-12-20
url: https://tech.urokogumo.org/posts/2025-12-vercel-multisite
summary: SITE_ID と ignore build step で、urokogumo.org / snow-kotan.com 等を分岐デプロイ。

urokogumo の公開サイトは **1つの Next.js アプリ** から複数ドメインを配信しています。

## 構成の要点

| 要素 | 役割 |
|------|------|
| `SITE_ID` 環境変数 | ビルド時にどのサイトか決定 |
| `@urokogumo/site-core` | サイト定義・URL・テンプレ種別 |
| `content/sites/{id}/` | 文章・team・サービス定義 |
| `vercel-ignore.sh` | 変更のないサイトはビルドスキップ |

## なぜやるか

- キッチンカー用のデザインと会社サイトを **同じコンポーネント資産** で保ちたい
- コンテンツ担当が JSON / Markdown だけ触れるようにしたい
- 将来 `tech.urokogumo.org` を別プロジェクトにしても **記事フォルダは共有** したい

## コード側のイメージ

```typescript
// packages/site-core — サイトはデータで切替
export const SITES: Record<SiteId, SiteConfig> = { ... };

// apps/web — テンプレート出し分け
if (site.template === "corporate") return <CorporateHome />;
if (site.template === "restaurant") return <RestaurantHome />;
```

## ハマったところ

- Vercel の `outputFileTracingRoot` が環境によって二重パスになる → 本番のみ無効化
- 各プロジェクトの Root Directory を `multisite/apps/web` に統一

## 関連

- [Works: 公式サイト monorepo 再構築](/works/2026-02-multisite-rebuild)
- Lab では fix-queue など社内ツールの試作ログを別チャネルに置いています

---