みなさん、こんにちは！
今回は、個人で運営している Web ツール集「KantanTools」を、なぜ作ったのか、どんな構成で作っているのかを紹介します。
技術スタック、ドメインの取得から公開までの手順、AI を使った開発の進め方まで、ひととおりまとめました。個人で小さな Web ツールを作ってみたい方や、Claude Code・Codex を開発にどう組み込むか気になっている方の参考になればうれしいです。
仕事で困っていたこと
仕事では、データを扱う作業がよくあります。たとえば IoT ゲートウェイの設定ファイルを作ったり、CSV や JSON のデータを作成・加工したり、といった作業です。
こういう作業は、今なら AI に自然言語で頼んでもできます。ただ、AI の出力をそのまま使うわけにはいかないので、最後は同僚とダブルチェックをすることになります。特にお客さんの環境の設定を変える前は、確認にかなりの時間を使っていました。
この確認の時間をなんとか減らしたい、というのがツールを作り始めたきっかけです。
毎回同じ結果が出る「道具」にしてしまう
そこで、よく使う作業を AI に手伝ってもらいながらツールにしました。最初に作ったのは、CSV を生成するツールです。
ツールにして変わったのは、ダブルチェックがほぼなくなったことです。
ツールを使い始めた最初の一回は、出力が正しいかをしっかりダブルチェックしました。でも二回目からは、同じ入力なら同じ結果が出るとわかっているので、毎回すべてを確認する必要がなくなりました。今は、環境へ投入する担当者が、投入前に最初のデータと最後のデータを確認するだけで済んでいます。
AI に毎回お願いするのではなく、AI の力を借りて「決まった処理をする道具」を作る。この切り替えが、自分にとってはいちばん効果がありました。
データはできるだけブラウザの中で処理する
仕事で扱うデータは、外部に送れないものがほとんどです。なので KantanTools では、ファイルの変換や解析は原則としてブラウザ内で処理し、入力したデータをサーバーへ送らない作りにしています。
たとえば CSVファイル生成 のページにも、入力した設定や生成データはサーバーへ送信されないことを書いています。
ただし、すべてがブラウザだけで完結しているわけではありません。出欠確認のように、複数人でデータを共有する必要がある効率化ツールもあります。こういったツールはデータベースが必要なので、サーバー側（Cloudflare Workers と D1）で処理しています。
技術スタック
| 用途 | 使っているもの |
|---|---|
| フロントエンド・静的サイト生成 | Astro 7、TypeScript |
| テスト | Vitest |
| 配信・API | Cloudflare Workers、Static Assets |
| データベース | Cloudflare D1 |
| 開発に使っている AI | Claude Code、Codex |
ツールの中身は、ほとんどがブラウザで動く TypeScript です。文字コードや PDF のように自分で一から書くと大変な部分は、ブラウザで動くライブラリに任せています。
構成：基本は静的サイト、必要なところだけ Worker
サイトは Astro で静的な HTML を生成して、Cloudflare Workers の Static Assets で配信しています。
リクエスト
├── /api/* や出欠確認など → Worker（必要に応じて D1）
└── それ以外のページ → 静的ファイルをそのまま返す
どの URL を Worker で処理するかは、wrangler.jsonc の run_worker_first で決めています。抜粋するとこんな感じです。
{
"name": "tools-website",
"main": "./worker/index.ts",
"assets": {
"directory": "./dist",
"binding": "ASSETS",
"run_worker_first": [
"/api/*",
"/attendance/*"
// ほかにもいくつかのパスを指定しています
]
},
"d1_databases": [
{
"binding": "DB",
"database_name": "kantantools-db",
"database_id": "<your-database-id>"
}
]
}
ここに書いていないパスは Worker を通らず、ビルドした静的ファイルがそのまま返ります。ほとんどのツールはこちらなので、サーバー側の処理はかなり少なく済んでいます。
ドメインを Cloudflare で取得する
ドメイン（kantantools.net）は Cloudflare で購入しました。
Cloudflare Registrar は、レジストリなどに支払う金額だけを請求し、上乗せをしない方針です（公式ドキュメント）。料金は TLD によって違いますが、安いドメインなら年 2,000 円前後で持てるイメージです。
購入の流れは、公式ドキュメントによるとこんな感じです。
- Cloudflare ダッシュボードで Register domains を開く
- 欲しいドメイン名を入力して Search を押す
- 買いたいドメインの Purchase を押す
- Payment option で登録する年数を選ぶ
- 連絡先の情報を入力する
- 支払い方法を選ぶ
- 規約を確認して Complete purchase を押す
検索すると、TLD ごとの価格と更新価格（Renews at）が一覧で表示されます。
ダッシュボードの画面は変わることがあるので、実際に操作するときは公式ドキュメントもあわせて見てください。
Astro のサイトを Cloudflare Workers に公開する
ドメインが手に入ったら、いよいよサイトを公開します。ここでは KantanTools で実際に使っている形を、Astro のビルド → ファイル構成 → GitHub 連携での公開、の順に紹介します。
Astro のビルド設定
KantanTools は、Astro で全ページを静的な HTML として書き出しています。astro.config.mjs の主な設定はこんな感じです（実際のファイルから一部を省略しています）。
import { defineConfig } from 'astro/config';
import sitemap from '@astrojs/sitemap';
export default defineConfig({
output: 'static', // 全ページを静的 HTML として出力
site: 'https://kantantools.net', // canonical URL やサイトマップの基準になる URL
trailingSlash: 'never', // URL の末尾に / を付けない
integrations: [sitemap()], // サイトマップを自動生成
});
output: 'static' にしているので、サーバー側でページを組み立てる処理はありません。ビルドすると dist/ に HTML・CSS・JavaScript が出力され、これをそのまま Cloudflare に置くだけで動きます。
ふだんの開発で使うコマンドはこの 3 つです。
npm run dev # 開発サーバーを起動（http://localhost:4321）
npm run build # 本番用の静的ファイルを dist/ に出力
npm run preview # ビルドした結果をローカルで確認
trailingSlash: 'never' は、wrangler.jsonc 側の "html_handling": "drop-trailing-slash" とそろえています。Astro と Cloudflare で URL の形が食い違わないようにするためです。
ファイル構成
リポジトリの構成は、ざっくりこうなっています。
.
├── src/
│ ├── pages/ # URL になるページ（tools/csv-generator.astro など）
│ ├── components/ # Header・Footer や、各ツールの画面
│ │ └── tools/
│ ├── lib/ # 画面から切り離した変換・解析ロジックとテスト
│ │ └── tools/
│ ├── data/ # ツール一覧・カテゴリなどの共通データ
│ ├── layouts/ # 共通レイアウト
│ └── styles/ # 共通スタイル
├── public/ # 画像や robots.txt など、そのまま配信するファイル
├── worker/
│ └── index.ts # Worker の入口（API・リダイレクト・静的ファイルへの振り分け）
├── migrations/ # D1 のテーブル定義（SQL）
├── astro.config.mjs # Astro の設定
├── wrangler.jsonc # Cloudflare Workers の設定
└── package.json
1 つのツールは、だいたい 4 つのファイルに分かれています。CSVファイル生成ツールなら、こんな形です。
| ファイル | 役割 |
|---|---|
src/pages/tools/csv-generator.astro |
ページ本体（URL は /tools/csv-generator） |
src/components/tools/CsvGenerator.astro |
画面と操作 |
src/lib/tools/csvGenerator.ts |
CSV を組み立てるロジック |
src/lib/tools/csvGenerator.test.ts |
ロジックの単体テスト |
さらに、ツールの名前・説明・カテゴリなどは src/data/tools.ts にまとめて登録しています。ヘッダーのメニューやツール一覧、関連ツールの表示は、すべてこのデータを参照しています。ツールを追加するときは「ページを作る」だけでなく「ここに登録する」までがセットです。
ロジックを lib/ に分けているのは、テストしやすくするためです。画面がからまない純粋な関数にしておけば、Vitest で入力と出力を確かめるだけで済みます。
GitHub と連携して公開する
公開は、Cloudflare の Git 連携（Workers Builds）を使っています。流れはこうです。
GitHub の main に push
↓
Cloudflare が自動でビルド（npm run build）
↓
自動でデプロイ（npx wrangler deploy）
↓
kantantools.net に反映
つまり、手元で main に push するだけで、本番に反映されるようになっています。設定の手順は次のとおりです。
1. wrangler.jsonc を用意する
まずはリポジトリに wrangler.jsonc を置きます。静的サイトだけなら、最小限はこれくらいです。
{
"name": "tools-website",
"compatibility_date": "2026-09-03",
"assets": {
"directory": "./dist"
}
}
assets.directory には、Astro のビルド結果の出力先（dist）を指定します。KantanTools では、ここにさらに main（Worker の入口）や run_worker_first、D1 の設定を足しています。
2. GitHub リポジトリを Worker に接続する
Cloudflare ダッシュボードで Workers & Pages を開き、対象の Worker を選んで Settings → Builds → Connect から GitHub のリポジトリを接続します（公式ドキュメント）。
ここで気をつけたいのが Worker の名前です。ダッシュボード上の Worker 名と、wrangler.jsonc の name が一致していないと、ビルドが失敗します。
3. ビルドの設定をする
KantanTools では、ビルド設定をこうしています（各項目の意味は公式ドキュメントを参照）。
| 項目 | 設定値 |
|---|---|
| Production branch | main |
| Build command | npm run build |
| Deploy command | npx wrangler deploy |
| Root directory | / |
ビルドのときだけ使う環境変数（KantanTools では PUBLIC_ で始まる公開用の値）は、同じ Builds の設定の下のほうにある Variables and secrets に登録します。ここに入れた値はビルド用なので、Worker の実行時には使えない点に注意です。
逆に、API キーのように Worker の実行時に使う Secret は、Builds とは別の Variables and Secrets の設定に登録します。名前が似ているので、最初は少しまぎらわしいところです。
4. push してデプロイを確認する
あとは main に push すると、自動でビルドとデプロイが走ります。
git push origin main
デプロイの結果は、Worker の Deployments タブで確認できます。push ごとに履歴が並び、成功すると Ready と表示されます。
push するだけで本番に出てしまうので、push する前に、手元で型チェック・テスト・ビルドを通すようにしています（具体的なコマンドは後半の「開発の進め方」で紹介します）。
独自ドメインをつなぐ
最後に、買ったドメインを Worker に割り当てます。方法は二つあります。
一つは、wrangler.jsonc に書く方法です。KantanTools ではこちらを使っています。
{
"routes": [
{
"pattern": "kantantools.net",
"custom_domain": true
}
]
}
もう一つは、ダッシュボードから設定する方法です（公式ドキュメント）。
- Workers & Pages を開いて、対象の Worker を選ぶ
- Domains タブを開く
- Add Domain を押して、ドメインを入力して追加する
追加すると、Custom Domains and Routes の一覧にドメインが表示されます。
DNS レコードは Cloudflare が自動で作ってくれます。なお、すでに同じホスト名の CNAME レコードがある場合は Custom Domain を追加できないので注意してください。
開発の進め方：考える AI と、書く AI
開発では Claude Code と Codex の両方を使っています。ポイントは、「考える」と「実行する」で役割を分けていることです。
| 担当 | 役割 |
|---|---|
| Codex | 全体の設計・構成を考える |
| 人間（自分） | 設計が経験的に正しいか判断する |
| Claude Code | コードを書く |
| 人間 + Codex | テスト・確認する |
AI に設計から実装まで全部任せることもできますが、そうすると「本当にこれで大丈夫？」を判断する人がいなくなってしまいます。なので、方向性を決めるところと、最後に確かめるところには、必ず自分が入るようにしています。
ツールを 1 つ追加するときの流れ
新しいツールを追加するときは、だいたいこんな順番で進めています。
1. Codex に設計を相談する
作りたいツールの目的と、入力・出力のイメージを伝えて、構成を考えてもらいます。
CSV の列名を一括で変更するツールを追加したい。
入力は CSV ファイルと「旧列名 → 新列名」の対応表、出力は列名を変えた CSV。
データはブラウザ内だけで処理したい。
既存のツールの構成に合わせて、必要なファイルと処理の分け方を考えてください。
2. 設計を自分で判断する
出てきた設計を読んで、実際の業務で使えるかを判断します。たとえば「取り込み先は Shift_JIS のこともあるから、文字コードの指定が必要」といった、経験からくる指摘はここで入れます。
3. Claude Code に実装してもらう
決まった設計を Claude Code に渡して、コードを書いてもらいます。
4. 自分と Codex でテスト・確認する
最後に、自分と Codex で動作を確認します。コマンドでの確認は、次の順番です。
npm run check # Astro と TypeScript の型チェック
npm test # Vitest の単体テスト
npm run build # 静的ファイルを dist/ に生成
npx wrangler deploy --dry-run # Worker と Assets の構成を検証（公開はしない）
AI が迷わず作業できるように、リポジトリには AGENTS.md と CLAUDE.md を置いてプロジェクトのルールを書き、README にはこの確認手順をまとめています。
変換や解析のロジックは画面のコードから分けて、単体テストを書いています。ツールの結果が毎回同じであることが KantanTools の一番大事なところなので、テストはそれを守るための仕組みでもあります。
作ってみて感じていること
AI のおかげで、仕事で「これがあれば楽なのに」と思ったものを、すぐに形にできるようになりました。2026年9月に作り始めて、今ではツールもかなり増えています。
一方で、ツールにできるのは、手順が決まっている作業だけです。毎回判断が必要な作業は、やっぱり人が考える必要があります。「決まった作業はツールに、判断は人に」という分担を意識しながら、これからも少しずつツールを増やしていきます。
KantanTools は個人で運営しているサイトで、CSV や JSON、文字コード、PDF など、日々の「ちょっと困った」に使えるツールを置いています。同じような作業をしている方は、よければ試してみてください。
さいごに
AI に毎回頼むより、AI と一緒に道具を作るほうが、結果的に確認の手間を大きく減らせました。似たような作業で確認に時間を取られている方の参考になればうれしいです。