**#9110（シャープ きゅういちいちまる）**は、日本の警察が設けている
**「警察相談専用電話」**です。

■ 概要

• 緊急ではない相談を受け付ける窓口

• 全国どこからでも「#9110」で最寄りの警察相談窓口につながる

• 管轄は 警察庁

■ 110との違い

■ 具体的に使うケース

例えばこんなとき👇

• ストーカー・嫌がらせの相談

• 詐欺っぽい連絡を受けた

• 近所トラブル（騒音など）

• ネットトラブルや脅迫

• 被害にあったか判断がつかないとき

■ 注意点

• 受付時間は基本「平日昼間」（地域によって異なる）

• 夜間・休日は各都道府県警の代表番号に転送されることもある

• 緊急時は迷わず110

■ 一言でいうと

👉 「警察に相談したいけど、110ほどではない時の窓口」

必要なら、「これ#9110に相談すべきか？」も具体例で判断できます。

Astro × Kinde × Stripe 月額サブスクリプション実装ガイド

対象スタック: Astro (SSRモード) + Cloudflare Pages/Workers + Kinde + Stripe

全体アーキテクチャ

ブラウザ
  │
  ├─ /pricing          → Kindeの Pricing Table ウィジェットを埋め込み
  ├─ /api/auth/*       → Kinde SDK が処理（ログイン・コールバック・ログアウト）
  ├─ /dashboard        → 認証＋サブスク状態チェック後に表示
  └─ /api/portal       → Stripe カスタマーポータルへリダイレクト
         │
  Cloudflare Workers (Astro SSR)
         │
  ├─ Kinde Auth  ←→  Kinde管理画面（ユーザー管理・プラン管理）
  └─ Stripe API  ←→  Stripe（決済・Webhook）

STEP 0: 前提パッケージとプロジェクト初期状態の確認

# Node.js 18以上、npm 9以上が必要
node -v
npm -v

# 既存プロジェクトの確認
cat astro.config.mjs
cat package.json

astro.config.mjs が以下になっていることを確認します。output: 'server' が必須です：

いいですね。ここはかなり面白い領域です。
👉 **「CodexにSaaSを丸投げして作る手順」**を、実務レベルで解説します。

（あなたの構成：Workers + D1 + Stripe + Kinde 前提で説明します）

🔥 全体像（超重要）

人間：仕様を書く
   ↓
Codex：コード生成・実行・修正
   ↓
完成（ほぼ自動）

OpenAI Codex は
👉 コード生成だけでなく「実行・修正」までやるエージェントです (OpenAI)

① 環境準備（5分）

CLIインストール

npm install -g @openai/codex

APIキー設定

export OPENAI_API_KEY=xxxx

👉 これで準備完了
👉 ターミナルでCodexが動く (OpenAI Help Center)

② プロジェクト作成（ここから自動）

mkdir saas-app
cd saas-app
codex

③ 最初の命令（これが9割決める）

ここが一番重要👇

Cloudflare Workers + D1 + Stripe + Kindeで
SaaSアプリを作成してください。

要件：
- 認証：Kinde（login / callback）
- DB：D1（users, subscriptions）
- 課金：Stripe Checkout
- Webhook処理あり
- middlewareで未課金ユーザー遮断
- APIとUIを含む
- wrangler.tomlも生成

最後に動作確認まで実行してください

④ Codexの動き（内部で起きてること）

Codexは👇を自動でやります

Astroをベースとしたプロジェクト（Cloudflare Pagesへのデプロイを想定）で、KindeとStripeを組み合わせて月額サブスクリプション機能を構築する具体的な手順を解説します。

まず、関連するスキルファイルを確認します。構成の全体図と詳細な手順を作成します。—

全体の流れ

ユーザーが登録 → Kinde でログイン → Stripe で課金 → D1 にプラン状態を保存 → ページアクセス時に Middleware がプランを確認してルーティングする、というシンプルな構成です。

Step 1 — プロジェクト作成

npm create cloudflare@latest my-saas -- --framework astro
cd my-saas

wrangler.toml の compatibility_flags に nodejs_compat を追加します。

[compatibility_flags]
compatibility_flags = ["nodejs_compat"]

Step 2 — Kinde の設定（認証）

Kinde ダッシュボードでアプリ作成

1. kinde.com でアカウント作成
2. Applications → Add application → 「Back-end web」を選択
3. Callback URL: http://localhost:4321/api/auth/kinde_callback
4. Logout URL: http://localhost:4321

パッケージインストール

npm install @kinde-oss/kinde-typescript-sdk

環境変数（.dev.vars / Cloudflare Secrets）

KINDE_DOMAIN=https://your-subdomain.kinde.com
KINDE_CLIENT_ID=xxx
KINDE_CLIENT_SECRET=xxx
KINDE_REDIRECT_URI=http://localhost:4321/api/auth/kinde_callback
KINDE_LOGOUT_REDIRECT_URI=http://localhost:4321

認証ルート作成

src/pages/api/auth/
  login.ts          → Kinde の認証URLへリダイレクト
  kinde_callback.ts → コールバック処理・セッション保存
  logout.ts         → ログアウト

// src/pages/api/auth/login.ts
import type { APIRoute } from "astro";
import { createKindeServerClient, GrantType } from "@kinde-oss/kinde-typescript-sdk";

export const GET: APIRoute = async ({ request, redirect, locals }) => {
  const client = createKindeServerClient(GrantType.AUTHORIZATION_CODE, {
    authDomain: import.meta.env.KINDE_DOMAIN,
    clientId: import.meta.env.KINDE_CLIENT_ID,
    clientSecret: import.meta.env.KINDE_CLIENT_SECRET,
    redirectURL: import.meta.env.KINDE_REDIRECT_URI,
    logoutRedirectURL: import.meta.env.KINDE_LOGOUT_REDIRECT_URI,
  });

  const loginUrl = await client.login(sessionManager); // sessionManager は Cookie ベースで実装
  return redirect(loginUrl.toString());
};

Step 3 — Cloudflare D1 セットアップ

wrangler d1 create saas-db

wrangler.toml にバインドを追加：

Cloudflare Workers + Kinde + Stripe を組み合わせて月額サブスクリプションを構築するための、具体的かつ実践的な手順を解説します。

この構成は、インフラコストを抑えつつ（0円〜）、本格的なB2B/B2C SaaSを構築するのに非常に適しています。

全体像：役割分担

• Kinde: ユーザー認証、プラン（権限）管理、Stripeとの連携。

• Stripe: 決済処理、サブスクリプションの課金実行、カード情報管理。

• Cloudflare Workers: 認証チェック、有料コンテンツ/APIの提供。

ステップ 1：Kinde と Stripe の連携設定

1. Stripe 側での準備:

   • Stripeアカウントにログインし、開発用の「テストモード」を有効にします。

   • APIキー（公開可能キーとシークレットキー）を控えておきます。

2. Kinde 側での接続:

   • Kinde管理画面の [Settings] > [Billing] に進みます。

   • Stripeをコネクターとして選択し、StripeのAPIキーを入力して接続します。

3. プラン（Product）の作成:

   • Kinde上で「Pro Plan」などの名前でプランを作成します。

   • 支払サイクルを「Monthly」、金額を設定します。

   • これにより、Stripe側にも自動的に対応する商品（Product）と価格（Price）が作成されます。

ステップ 2：Cloudflare Workers への SDK 導入

Workers プロジェクト（AstroやHonoなどを使用している場合を含む）に、Kinde の SDK をインストールします。

Bash

npm install @kinde-oss/kinde-typescript-sdk

次に、wrangler.toml に Kinde から発行された環境変数を設定します。

Ini, TOML

[vars]
KINDE_DOMAIN = "https://your_subdomain.kinde.com"
KINDE_CLIENT_ID = "your_client_id"
KINDE_CLIENT_SECRET = "your_client_secret"
KINDE_REDIRECT_URL = "https://your-app.pages.dev/api/auth/kinde_callback"

ステップ 3：認証とサブスク情報の取得（コード実装）

Workers 内で、ユーザーがログインしているか、かつ「Proプラン」の権限を持っているかを判定するロジックを実装します。

**Groundfridge（グラウンドフリッジ）**は、オランダのデザイナー、フロリス・ショーンダービーク（Weltevree社）によって開発された、**電気を一切使わない「現代版の地下貯蔵庫（穴ぐら）」**です。

伝統的な地下貯蔵の知恵と現代のデザインを融合させた、サステナブルな冷蔵システムとして世界的に注目されました。

主な特徴と仕組み

• 自然の断熱効果を利用: 地中の温度が一年を通じて一定（約10〜12°C）であることを利用しています。これにより、ワイン、野菜、果物、チーズなどを新鮮に保つことができます。

• 構造: 強度が高く腐食しにくいラミネートポリエステル製で、球体に近い形状をしています。容量は一般的な冷蔵庫約10〜12台分（約3,000リットル）に相当し、大人が中に入って作業できるほどの広さがあります。

• 設置方法: 地面に大きな穴を掘って埋め込み、掘り出した土を上から被せるだけで設置が完了します。この「土の層」が天然の断熱材として機能します。

• 換気システム: 太陽光パネルやバッテリーを必要とせず、自然な空気の対流を利用して内部の湿度と温度を管理する仕組みが備わっています。

メリット

1. 電気代ゼロ: 運用コストがかからず、停電の影響も受けません。

2. 大容量: 根菜類（ジャガイモやニンジン）、リンゴ、ワイン、自家製の保存食などを大量にストックできます。

3. 環境負荷の低減: フロンガスを使用せず、エネルギー消費もないため、非常にエコです。

適している用途

一般的な家庭用冷蔵庫のように「キンキンに冷やす（4°C以下）」ことはできませんが、**「涼しく一定の湿度を保つ」**のが得意です。そのため、以下のようなものの保管に最適です。

• 根菜類や果物の長期保存

• ワインセラーとしての利用

• チーズや発酵食品の熟成

オフグリッドな生活を目指す人や、庭を活用して大量の備蓄をしたい人にとって、非常に機能的で美しいソリューションといえます。

田んぼ 1反（10a）あたりの米の売上と収支を、できるだけ現実に近い数字で説明します。
※地域や販売方法で大きく変わるので「代表的な例」です。

① 1反で取れる米

平均収量
約500kg（玄米）

30kg袋にすると
約16～17袋

② 米の販売価格（2024〜2025年頃の目安）

※品種：コシヒカリなど

③ 1反の経費（リアルな目安）

合計

約5万〜8万円／反

④ 1反の利益

JA出荷

売上
13万〜20万

経費
5万〜8万

利益
5万〜12万円

直販

売上
30万〜40万

経費
6万〜10万

利益
20万〜30万円

⑤ 面積別のリアルな収入

⑥ なぜ米農家が儲からないか

理由は3つです。

農地（田んぼ）は、農地法により農業目的以外の利用や貸し借りが厳しく制限されています。そのため、農業委員会で小作契約（農地の賃貸借）が認められない場合でも、いくつかの利用方法があります。

1️⃣ 自分で耕作する

最も基本的な方法です。

内容

• 所有者または世帯員が直接耕作する

• 水稲・野菜・飼料作物などを作る

メリット

• 農業委員会の許可不要

• 農地として維持できる

注意

• 長期間耕作しないと「遊休農地」と判断されることがあります。

2️⃣ 農作業だけ委託する（作業委託）

土地は貸さず、作業だけ頼む方法です。

例

• 田植えだけ委託

• 稲刈りだけ委託

• 全作業委託

この場合
農地の賃貸借ではないため農業委員会の許可が不要です。

ただし

• 収穫物の所有者は土地所有者

3️⃣ 農地中間管理機構に貸す

通称
👉 農地バンク

正式名称

• 農地中間管理機構

特徴

• 機構が農地を借りて

• 担い手農家へ再貸付

メリット

• 個別に小作契約しなくてよい

• 管理してくれる

4️⃣ 市民農園として利用

条件を満たせば

• 体験農園

• 市民農園

として使うことも可能です。

関係法

• 特定農地貸付法

ただし

• 面積制限

• 農業委員会への手続き
  などがあります。

5️⃣ 農地転用（田んぼを別用途にする）

農業以外に使う場合は

• 駐車場

• 資材置き場

• 宅地

などに変更することになります。

必要手続き
👉 農地法第4条・第5条許可

ただし

• 農振地域

• 優良農地

だと転用は難しいです。

✔ よくある実務対応

農業委員会で小作契約が難しい場合は

1. 作業委託で実質的に耕作してもらう

2. 農地バンクに預ける

この2つが一番多いです。

💡もしよければ教えてください

• なぜ小作契約ができないと言われましたか？

**行政手続法（ぎょうせいてつづきほう）**は、日本の行政機関が行う手続きを「公正で透明にする」ための基本ルールを定めた法律です。
1993年に制定され、国民が不利益を受けないように行政のやり方をコントロールする役割があります。

■ 行政手続法とは（ざっくり）

行政が勝手な判断や不透明な処理をしないように、

👉 事前にルールを明確にし、説明責任を持たせる法律

です。

■ 主な目的

1. 公正の確保（えこひいき防止）

2. 透明性の向上（ブラックボックス防止）

3. 国民の権利保護

■ 対象になる主な手続き（超重要）

行政手続法は主にこの4つを規制します👇

① 申請に対する処分

例：

• 許可・認可（営業許可など）

• 補助金の申請

👉 ポイント

• 審査基準を事前に公開する義務

• 標準処理期間を設定する努力義務

② 不利益処分

例：

• 生活保護の停止

• 営業停止

• 免許取消

👉 ここが一番重要です

必須ルール：

• 理由の提示（なぜ処分するのか）

• 弁明の機会（言い分を言える）

• 聴聞・弁明手続

👉 いきなり処分は基本NG

③ 行政指導

例：

• 「できればこうしてください」という指導

👉 ポイント

• 強制ではない（従わなくても罰則なし）

• しかし現実では圧力になりやすいので規制あり

禁止事項：

• 従わないことで不利益扱いすること

④ 届出

例：

• 開業届

• 各種変更届

👉 条件を満たせば「受理しなければならない」

■ 超重要ポイント（実務で効く）

あなたの過去の話（ケースワーカー対応など）にも直結する部分です👇

● 行政は理由を言う義務がある

→ 「なんとなくダメ」は違法の可能性

● 弁明の機会なしの処分は違法の可能性

→ いきなり停止・取消は要注意

● 行政指導は“断れる”

→ 従わなくてもOK（ただし現実は工夫が必要）

Cloudflare Workersのデプロイコマンドと動作の違いについて説明します。Cloudflare Workersのデプロイコマンドと、それによってWorkerの動作がどう変わるかを整理します。各コマンドについて詳しく説明します。

wrangler dev — ローカル開発

Workerはデプロイされず、リクエストはローカルマシン上で処理されます。

フラグによる動作の違い：

• デフォルト（フラグなし） — Cloudflareのエッジにリクエストをプロキシしつつ、コードはローカルで実行。KV・D1などのバインディングはプレビュー用のサンドボックスを参照します。
• --local — Miniflareを使った完全ローカルエミュレーション。インターネット不要で動作し、CI環境やオフライン開発に向いています。
• --remote — コードはローカルで動くが、KVやD1・R2などは本番リソースに接続。「ローカルコード × 本番データ」で検証したい場合に使います（本番データを読み書きするため注意が必要）。

wrangler deploy — 本番デプロイ

コードをビルドしてCloudflareのグローバルエッジネットワーク（300拠点以上）に即時配信します。デプロイ後、数秒以内に全世界に反映されます。

--env で環境を切り替え：

# wrangler.toml
[env.staging]
route = "staging.example.com/*"
vars = { API_URL = "https://api-staging.example.com" }

[env.production]
route = "example.com/*"
vars = { API_URL = "https://api.example.com" }

• wrangler deploy --env staging → stagingルートにデプロイ、stagingの変数を使用
• wrangler deploy --env production → 本番ルートにデプロイ、本番の変数を使用

環境ごとに別のWorkerスクリプトとして登録されるため、stagingと本番が独立して動作します。

バージョン管理コマンド（段階的ロールアウト）

大規模なトラフィックへの影響を抑えながら新バージョンを公開したい場合に使います。

# バージョンをアップロードのみ（まだトラフィックには流れない）
wrangler versions upload

# トラフィックの10%だけ新バージョンに流す
wrangler versions deploy --version-id <id> --percentage 10

# 問題があれば即ロールバック
wrangler rollback

コマンドまとめ

バインディング設定について詳しく説明します。まず全体の構造をひと目で把握できる図から始め、その後各バインディングの詳細と実際のコードを説明します。Workerはすべてのバインディングを env オブジェクト経由で受け取ります。wrangler.toml での宣言と、コード内での使い方をバインディングごとに説明します。