小さな業務改善のためのアプリを AI で作るはじめに自己紹介勉強会の対象者小さな業務改善のためのアプリ小さな業務改善とは？問い合わせ管理ボードアプリの作り方と構成事前準備（勉強会当日までに完了させておく）利用するサービスアカウントを作るClaude Code と GitHub を連携するClaude Code と Cloudflare を連携するCloudflare Access の認証設定準備できたかを確認するアプリ開発土台づくりGitHub でリポジトリを作るClaude Code がリポジトリを使えるようにするCloudflare と GitHub を連携した Worker を作るCloudflare Worker の設定をするアプリを作るClaude Code Web の基本的な使い方最初のセッション：開発ルールと基本ドキュメントを作る次のセッション：アプリの最小版を作るアプリ開発の続き機能を追加する戻してみるデータベースの項目を増やす場合項目を追加した PR を閉じた場合2 つ目の業務を足す 【自習】AI の機能を足す 【自習】うまくいかないときはAI による開発について作るかどうかを判断する作ったアプリの管理費用の目安アカウントは会社の資産にするアクセスできる人を管理するデータを取り出せるようにしておくセキュリティレビュー管理台帳を埋める久しぶりに開発を再開するときやめるときのことを決めておくまとめ
この勉強会の初回で、AI 活用の 3 段階というお話がありました。
AI を使う
AI が業務を担当する、判断する
AI を組織化する
今回は 1 の例として、小さな業務改善のためのアプリを AI で作ります。
1 回目はハンズオンでアプリを作り、2 回目はその続きと座学です。
株式会社アースワークスの小西（[email protected]）です。
ソフトウェアエンジニアで、業務系のアプリケーション開発や、IP-PBX などの電話関係のシステム開発に携わっています。
株式会社アースワークス（https://ews.jp/）は、電気通信工事とソフトウェア開発の会社です。最近では、新しく「CST Design」という体験型セミナーを、合同会社和の杜と一緒に始めました。座学ではなく、書道や古武術などの日本文化の体験を比喩として使い、チームの状態を整えて、プロジェクトを正しく進めるための場をつくる、というものです。
エンジニアがいない会社の経営者や業務改善の担当者で、AI でアプリを作ってみたい方が対象です。プログラミングの経験は必要ありません。パソコンとブラウザの基本操作ができれば OK です。
社内にエンジニアがいる会社でも、非エンジニアがどこまで自分たちで対応してよいかを考える材料になります。
社内にある小さな手作業を減らし、業務の効率を上げたいと思いませんか？
Excel 転記をなくしたい
対応漏れを減らしたい
属人業務を見える化したい
例えば、次のような業務です。
問い合わせ管理
備品の貸出管理
点検記録
日報
簡単な進捗表
これらは、小さなアプリで改善できます。これまではアプリの開発コストが高く、小さな業務改善のためにアプリを作っても採算が合いませんでした。しかし、AI の登場で開発コストが下がり、内製化も現実的になってきています。
例えば、次のような課題があると仮定します。
何に困っているか
問い合わせの対応状況が共有できない
問い合わせ対応に遅れや漏れが生じる
現在はどうしているか
メール、電話メモ、Excel に分散している
改善効果は何か
対応漏れと確認作業を減らせる
対応の遅れによる失注やクレームを防げる
そこで、これを解決するため、「問い合わせ管理ボード」を考えます。
問い合わせ状況を管理する
未対応
対応中
完了
業務を効率化する仕組みを入れる
商品分類と受付経路に応じて担当者を決める
2 営業日を過ぎても完了していない問い合わせは赤く表示する
導入後に確認できる指標を検討する
問い合わせ件数
対応完了までの時間
対応漏れの件数
本来は、作るべきかどうかを「作るかどうかを判断する」（2 回目で扱います）に沿って検討しますが、今回はサンプルとして「問い合わせ管理ボード」を作ることにします。
開発者が指示すると、AI がアプリを作って GitHub に保存し、それがクラウドに配置されて、許可した人だけが使えるようになります。
この構成には、次のメリットがあります。
ブラウザだけで開発できる（開発環境を作る必要がない）
作ったソースコードは履歴付きで管理できる
作ったアプリがクラウドでそのまま動く
サーバーを管理する必要がない
開発中のものをプレビューしてから、本番に反映できる
アプリへのアクセスを制限できる
ハンズオンだけでなく、本番運用の土台としても使えます。また、Web ページの管理などにも応用できます。
勉強会の前に、次の準備を済ませておいてください。コマンドラインやターミナルは使わず、アプリのインストールも不要で、ブラウザだけで完結します。
Claude Code（Anthropic 社）
開発を担当する AI です。
今回はブラウザ版の Claude Code Web（正式名は Claude Code on the web）を使います。
月額 $20 前後の有料プランで、かなり快適に使えます。
本格的に使う場合は $100、$200 のプランもあります。法人プランもあります。
初期設定のままだと、会話やコーディングの内容が AI の学習に使われます。
「アカウントを作る」で説明する設定を必ず OFF にしてください。
会社として契約するなら、学習に使われない Team プランも検討してください。
GitHub
ソースファイルを置いておく場所です。
変更の履歴も管理できます。
今回は Claude Code、Cloudflare と連携させます。
今回のような小規模な利用なら、無料で十分です。法人プランもあります。
Cloudflare
Web 関連のクラウドサービスを提供している会社です。
今回は Workers（アプリの実行）、D1（データベース）、Access（アクセス制限）を使います。
今回のような小規模な利用なら、無料で十分です。法人プランもあります。
アクセス制限は、50 人までは無料です。
次のリンクから、各サービスのアカウントを作ってください。
GitHub のアカウントを作成する（無料） https://github.com/signup 個人のアカウントで構いません。会社で本番運用するときは、あとで会社の Organization に移します（「アカウントは会社の資産にする」で説明します）。
Anthropic Claude の有料プラン Pro を申し込む（月額 $20 税別） https://claude.com/ja-jp/pricing 申し込んだら、claude.ai の設定（Settings）にあるプライバシー（Privacy）を開き、「Claude の改善に協力する（Help improve Claude）」を OFF にしてください。ON のままだと、会社のソースコードを含むセッションの内容が AI の学習に使われます。
Cloudflare のアカウントを作る（無料） https://dash.cloudflare.com/sign-up GitHub のアカウントでも登録できます。
GitHub のリポジトリを Claude Code Web から利用するための準備です。
https://claude.ai/code を開き、Claude のアカウントでログインする。
GitHub との連携を求められるので、案内に従って GitHub の画面に進む。
GitHub にログインして、Authorize をクリックする。
承認すると claude.ai/code の画面に戻ります。
Claude GitHub App のインストールを求められたら、Skip をクリックする。
リポジトリがまだないためです。インストールは当日、リポジトリを作ったあとで行います。
作業環境（クラウド環境）の Default が自動で作られるので、そのまま使う。
手順 2 で GitHub との連携を求められない場合は、次の手順で連携してください。
プロンプト入力欄の左下の + をクリックする。
コネクタ をクリックする。
コネクタを管理 をクリックする。
右上の 🔍 をクリックし、github と入力する。
GitHub連携 が絞り込まれるので、連携 または 連携させる をクリックする。
GitHub の画面で Authorize をクリックする。
Cloudflare のデータベースなどを Claude Code Web から操作するための準備です。データベースの作成や、Cloudflare の公式ドキュメントの検索も、この連携を通して行います。
プロンプト入力欄の左下の + をクリックする。
コネクタ をクリックする。
コネクタを管理 をクリックする。
右上の 🔍 をクリックし、cloudflare と入力する。
Cloudflare Developer Platform が絞り込まれるので、連携 または 連携させる をクリックする。
Cloudflare の画面で Approve をクリックする。
Authorize をクリックする。
Cloudflare Access の最初の設定では、ログイン方法が「Cloudflare アカウントでのログイン」だけになっています。今回は会社のメールアドレスで社員にログインしてもらうので、メールで届くコードでログインする方法（One-time PIN）を追加します。
Cloudflare の管理画面で、左側のメニューから Zero Trust を開く。
初回は、Zero Trust の組織名（team name）を決める画面が出るので、会社名などを英数字で入力する。プランは無料（Free）を選ぶ。支払い方法の入力を求められる場合がありますが、無料プランの範囲では課金されません。
Integrations の中の Identity providers を開く。
Add new identity provider をクリックし、One-time PIN を選んで保存する。
準備ができていないとハンズオンを進められないので、前日までに次の 3 つを確かめてください。
https://claude.ai/code を開いて、新しいセッションを始められる。
そのセッションの画面で、リポジトリを選ぶ欄が開く。
リポジトリはまだ作っていないので、名前が出てこなくて構いません。連携さえできていれば当日で間に合います。
プロンプト入力欄に、次のように入力して、答えが返ってくる。
GitHub と Cloudflare に接続できているか確認して、結果を日本語で教えて。
3 で「接続できていない」になる場合、その画面で「どうすれば接続できますか」と聞いてください。手順を教えてくれます。それでも解決しない場合は、当日までにご連絡ください。
なお、Claude の Pro プランには一定時間に使える量の上限があり、上限に達すると数時間ほど待つことになります。直前に試しすぎるとハンズオンで使えなくなることがあるので、気をつけてください。
この章では、次の用語が出てきます。すべてを覚える必要はありません。
| 言葉 | 意味 |
|---|---|
| リポジトリ | ソースやドキュメントの置き場所。アプリごとに作ります |
| ブランチ | 作業場所。本番用の場所（main）と、開発中の場所を分けます |
| コミット | 変更に区切りをつけて履歴に記録すること。この単位で元に戻せます |
| Pull Request（PR） | 「開発中のものを本番に取り込みたい」という申請 |
| マージ | その申請を承認して、本番用の場所に取り込むこと |
| デプロイ | 取り込んだものを、実際に動く場所に配置すること |
| ビルド | 配置する前に、動く形に組み立てる作業。自動で行われます |
| プレビュー | 本番とは別の URL で、開発中のものを実際に触って確認すること |
| プレビュー用データベース | プレビューだけが使う、本番とは別のデータベース。 プレビューで試したデータはここにだけ残ります |
| セッション | Claude Code との一続きの会話。依頼事項ごとに新しく始めます |
| issue | GitHub に残す「対応が要ること」の記録。次のセッションへの申し送りに使います |
| CI | PR のたびに自動で行われる検査（テストなど）。問題があると赤く表示されます |
| マイグレーション | データベースの項目を変更する手順を書いたファイル |
アプリ開発は、土台づくり、最小版づくり、機能追加の順に進みます。土台づくりはアプリごとに 1 回、最小版づくりは業務ごとに 1 回で、あとは機能追加を必要なだけ繰り返します。最小版づくりも機能追加も、Claude Code に作ってほしいものを伝え、できたものをプレビューで試してから本番に取り込む、という流れで進めます。
なお、この流れを専門用語を使って詳しく言い換えると、次のようになります。Claude Code に作ってほしいものを伝え、できたものを GitHub に PR（本番への取り込み依頼）として出すと、CI（検査）が自動で行われます。CI を通ったらプレビューで試し、問題がなければマージ（本番への取り込み）します。マージすると、自動で本番にデプロイされます。
まず、リポジトリ（ソースの置き場所）を作り、アプリをデプロイ（配置）する設定をします。画面の表記や項目の位置は変わることがあります。目的の欄が見つからないときは、スクリーンショットを Claude Code に貼って「この画面のどこを変えればよいですか」と聞いてください。
このあとの 6.1.1〜6.1.4 で設定するのは、次の図の部分です。
アプリのリポジトリを作ります。
Repository name は shanai-apps とする（Cloudflare Worker も同じ名前になります）。
Cloudflare と連携する場合、小文字の単語を - でつなぐのがおすすめです。
Description には説明を入力する（「社内アプリ」等で OK）。
Choose visibility は Private を選択する。 デフォルトの Public は全世界に公開される設定のため、要注意です。
Add README を ON にして、README.md を作成する。 main ブランチが最初から作られるので、後の作業がスムーズになります。
入力が終わったら、Create repository をクリックする。
作成したリポジトリで、Settings › General の順にクリックする。
Pull Requests の Automatically delete head branches を ON にする。
マージが終わった作業用のブランチを、自動で削除します。
非公開（Private）のリポジトリを Claude Code Web で使うには、そのリポジトリに Claude GitHub App（Claude が GitHub を操作するためのアプリ）をインストールする必要があります。
インストール先に、リポジトリを作った自分のアカウントを選ぶ。
すでにインストール済みの場合は、Configure をクリックする。
Repository access が All repositories になっていれば、この作業は不要です。
Repository access で Only select repositories を選び、Select repositories で shanai-apps を追加する。
すでに選ばれているリポジトリは、外さずにそのまま残します。
Install（インストール済みの場合は Save）をクリックする。
GitHub のリポジトリを更新すると Cloudflare のアプリも自動で更新されるように、GitHub と連携した Worker（アプリを動かすところ）を作ります。
Cloudflare にログインする。 https://dash.cloudflare.com/login
アカウントの選択肢が出る場合は、アカウントを選択する。
左側のメニューから Build › Compute › Workers & Pages の順にクリックする。
右上の Create application をクリックする。
Make something new で、Continue with GitHub をクリックする。
Select a repository で、先ほど作成したリポジトリを選択する。
ダイアログ左上の GitHub アカウントの一覧を開き、+ Add GitHub account を選択する。
Repository access で Only select repositories、Select repositories で対象リポジトリ（先ほど作成した shanai-apps）を選択し、Save をクリックする。
Cloudflare の画面の 🔍 Search repositories... に名前の一部を入れて、その下の選択肢から選択する。
Next → で選択完了。
Deploy を選択すると、Worker が作られ、ビルド作業が始まる。
Cancel build でビルドをキャンセルする。
まだアプリがないので、ビルドしてもエラーになるためです。
キャンセルが間に合わずエラーになっても、問題ありません。
作った Worker を開いた画面で、ビルド設定（Settings）、アクセス制限（Access）、アプリを開くための URL の有効化（Domains）を設定します。
設定画面の開き方（前節から続けて作業する場合はこの操作は不要）
左側のメニューから Build › Compute › Workers & Pages の順にクリックする。
先ほど作成した Worker の名前 shanai-apps をクリックする。
ビルド設定（Settings）
上部メニューの Settings をクリックする。
少し下にある Builds が Production になっていることを確認する。
Build configuration の Deploy command を npm run deploy:prod に変更する。
画面下部の Save をクリックする。
Builds の選択肢で Previews Base を選ぶ。
Builds for Preview branches が有効になっていることを確認する。
Build configuration の Preview command を npm run deploy:preview に変更する。
画面下部の Save をクリックする。
アクセス制限（Access）
上部メニューの Access をクリックする。
Protect this Worker behind Access をクリックする。
表示されない場合は、Worker policies › Worker Access の Manage access をクリックする。
All traffic にチェックを入れる（本番用とプレビュー用の両方にアクセス制限がかかります）
Authentication policy でアクセス制限の対象を選ぶ。
Email domain を選ぶと、指定ドメインのメールアドレスを持っている人だけアクセス可能になる。今回は、こちらを選ぶ。
Cloudflare account を選ぶと、この Cloudflare アカウントのメンバー（自分と、招待した管理者）だけがアクセス可能になる。
Apply Access をクリックする。
表示されない場合は、Save changes をクリックする。
URL の有効化（Domains）
上部メニューの Domains をクリックする。
Worker URL の欄で、Production と Preview の行の右側のスイッチをクリックする。
本番とプレビューの URL が使えるようになります。
セッションを始めて指示する
https://claude.ai/code を開き、新規セッションを選択する。
プロンプト入力欄の近くにあるボタンで、対象の GitHub リポジトリを選択する。
画面を開いてから選択肢が出るまで、しばらく時間がかかる場合があります。
デフォルトで、前回選択したものが設定されています。
プロンプト入力欄の右下から、モデルとエフォート（考える深さ）を選ぶ。
モデルは Opus 5.5 を選び、エフォートを「中」にします。 （Opus 5.5 では、エフォート「中」がよいみたいです）
プロンプトを入力する。
1 つのセッションでは、1 つの依頼事項だけにします（最小版づくりか、機能 1 つの追加など）。複数の依頼がある場合は、マージかクローズをしてから新しいセッションを使ってください。変更が小さい方が確認しやすく、変更をマージしない場合も、その依頼事項だけを取り消せます。
何をどう作るかの説明が出てくるので、次の点を確かめる。
頼んだものと合っているか（説明を自分の言葉で言い直せるか）
「やらないこと」に、必要な機能が入っていないか
項目の名前や区分の分け方など、業務に関わることを AI が勝手に決めていないか
マイナンバー、健康情報、パスワードなど、扱わないと決めたデータが混ざっていないか
確認した結果を返答する。
問題なければ「進めてください」と返す。
気になる点があれば、修正を指示する。
わからないことがあれば、その場で質問する。
PR を確認して本番に反映する
開発が一段落すると、Claude Code が PR（Pull Request、本番への取り込み依頼）を作り、画面に PR #nnn が表示される。
もし、作られない場合は、「PR を作って」と入力する。
CI（検査）が終わるのを待つ。
PR #nnn をクリックすると GitHub の PR 画面が開き、下のほうに検査の結果が並びます。
始まるまで時間がかかる場合があります。
CI がすべて緑になると、Claude Code がプレビューの確認手順と URL を示すので、そのとおりに確認する。
必要なら、PR 画面で PR の説明も読みます。
CI が終わっているのに、プレビューの確認手順と URL が出ない場合は、「CI を確認して」と入力してみてください。
問題があれば、Claude Code に修正を指示すると、PR が更新されるので、2 から繰り返す。
CI が赤い場合は、その行の右側の View logs を開き、メッセージをそのまま Claude Code に貼って直してもらいます。
問題がなければ、Claude Code に「マージして」と入力する。
マージすると本番に反映され、データベースの変更も同時に適用されます。作業ブランチは自動で削除されます。
本番に取り込みたくない場合は、「クローズして」と入力します。
マージ後は、Claude Code が示す手順で本番を確認し、結果を伝える。
本番の URL は、「本番の URL を教えて」と聞けば答えてくれます。
結果を伝えると、Claude Code が引き継ぎの記録などの文書を直す PR を作り、自分でマージすることがあります。文書だけの変更なので、確認は要りません。
最初のセッションで、今後 AI に守らせるルールを作ります。業務の画面はまだ作らず、フレームワーク（アプリの土台になる部品）を選び、CLAUDE.md と関連ドキュメント、データベース、設定ファイル、各業務の入口になるポータルページを用意します。CLAUDE.md は Claude Code が毎回自動で読むファイルで、ここに書いたことは以降の全セッションで適用されます。
プロンプトの例（業務名、会社規模、テーマカラーなどを変更してください）:
x問い合わせ管理・備品の貸出管理などの小さな業務をまとめた社内アプリを内製し、長く運用したい。業務の実装は次のセッションからとし、このセッションでは公式・標準のドキュメント、ベストプラクティス、一般的な慣行の順に調べて、フレームワークを選定し、CLAUDE.md と関連ファイルを作成し、ポータルページを開発して。Cloudflare の調査はしっかり行い、CLAUDE.md は関連ファイルに分けて参照する方式にして。会話・生成物・PR はすべて簡潔でわかりやすい日本語で書き、会話の技術用語には補足を付けて。# 環境社員 30 人の会社で、エンジニアでない開発者が、ターミナルを使わず、ブラウザだけで開発・運用する。`開発者 → Claude Code on the web → GitHub → Cloudflare Workers → Access → 利用者`Worker 1 つの構成で、GitHub、Cloudflare とも無料枠の範囲を想定。# 設定したもの- GitHub に新規リポジトリを作り、Cloudflare Workers と連携- Worker URL を Production、Preview とも有効化- Access は All traffic（本番、プレビュー）にメールドメインを設定- Worker の Deploy command に npm run deploy:prod を設定- Worker の Preview command に npm run deploy:preview を設定# アプリアースカラーで、見やすさ・使いやすさ・安全性を重視して。二重送信防止、楽観ロック、論理削除、CSRF 対策、すべての画面の状態を URL に保持し戻る際に復帰、操作者の記録、削除ダイアログに対象を明記、変更未保存時の離脱防止、パンくずリスト、日時は日本時間で表示、一覧は既定の並び順と件数を示す、画面の文言と項目名は全業務でそろえる。エラー時は、開発者が直すのに必要な情報を画面に出し、コピーボタンを付けて。# 開発の進め方1 セッションは、1 つの依頼事項までとして。まず issue を確かめ、事前に内容を説明・提案・質問し、開発者の承認後に、issue がなければ作り、YAGNI を守って開発し、PR を作って。CI が通ったら、開発者にプレビュー確認を手順や URL 付きで促して。開発者の指示でマージかクローズし、本番確認を促し、その結果を確認して PR に追記して。引き継ぎ等の文書修正は別 PR で自分でマージし、要コード修正事項は issue にして。Cloudflare やライブラリは毎回公式ドキュメントで確かめて。ADR、引き継ぎ情報、管理台帳（本番 URL・月額費用・障害連絡先）を残して。# 試験開発者の手間を極力減らしつつ、既存の業務を壊さないようにしたい。型チェック・lint・自動テストを npm run check に（GitHub Actions は使わない）、E2E を npm run e2e にまとめて。E2E は Claude Code のサンドボックスのみで実行し、スクリーンショットを見て、ずれ・崩れ・ぱっと見の違和感があれば直し、結果を PR に記して。それらで試せないものだけを開発者がプレビューで確認するので、試験項目をこの 3 つに分けた手順書を作って。# データベース本番とプレビューで別の DB を WNAM（北米西部）に用意し、別であることを npm run check で確かめて。deploy:prod、deploy:preview で、check 後にマイグレーションと配置を行って。マイグレーションは追加のみ（列を足すのは NULL 可の列だけ）とし、破壊操作（改名・削除・型変更）は行わないで。revert でもスキーマとマイグレーションは残して。
日本から無料の Worker を利用すると北米西部で動くことが多いので、データベースを北米西部に置くと、アプリが速くなります。管理画面から作るとデータベースを日本（東京や大阪）に置くこともできますが、Worker から遠くなるため、アプリが遅くなります。なお、顧客の氏名などの個人データを保存する場合は、保存先の公表などが必要です。詳しくは「作るかどうかを判断する」で説明します。
作られたものは、「Claude Code Web の基本的な使い方」の手順で確認し、本番に反映します。今回は、プレビューと本番で、ポータルページを確認します。例えば、CLAUDE.md に書かれたことが分からなければ、次のように聞いてみてください。
xxxxxxxxxxCLAUDE.md の内容を、専門用語を使わずに箇条書きで説明してください。
プロンプトの例:
xxxxxxxxxx問い合わせ管理ボードを作って
これだけでも、一般的な形の問い合わせ管理ボードが作られます。管理する項目などが決まっているなら、次のように具体的に書くと、欲しい機能が実装されます。
プロンプトの例:
xxxxxxxxxx問い合わせ管理ボードを作って【解決したい業務】問い合わせがメール・電話メモ・Excel に分散していて、対応状況が共有できず、対応の遅れや漏れが発生している。【最小版に必要な機能】- 問い合わせの一覧表示- 新規登録（受付日、お客様の会社名、担当者名、受付経路、商品分類、内容）- 詳細表示- ステータスの変更（未対応／対応中／完了）- 担当者の設定- ステータスと担当者による絞り込み
プロンプトを入力すると、業務について質問が返ってきます。分からなければ「わからない」、複数の選択肢がよければ「1 と 3」のように答えて構いません。
アプリができたら、動作確認を行います。CI（機械が行う検査）は PR のたびに自動で行われ、問題があると赤く表示されます。人が確認する項目は AI が手順書にしてくれるので、それに従って確認してください。確認から本番への反映までは、「Claude Code Web の基本的な使い方」の手順で進めます。
プレビュー用のデータベースは本番とは別なので、プレビューで登録したデータは本番には出ません。
「Claude Code Web の基本的な使い方」と同じ手順で、新しいセッションを始めて指示します。これまでの経緯は CLAUDE.md、引き継ぎの記録、issue に残っているので、続きから作業できます。
ここでは、「問い合わせ管理ボード」で挙げた自社固有のルールを追加します。
商品分類・受付経路に応じた担当者の自動設定
2 営業日を過ぎても完了していない問い合わせの警告表示
コメント履歴、添付ファイル、優先度、監査履歴（余裕があれば）
プロンプトの例:
xxxxxxxxxx担当者を自動で決める機能を問い合わせ管理ボードに追加してください。【解決したい業務】問い合わせを受けたあと、誰が対応するかを人が判断して割り振っている。その判断に時間がかかり、割り振り漏れも起きている。【今回やりたいこと】- 商品分類と受付経路の組み合わせに応じて、担当者を自動で設定する- 組み合わせと担当者の対応は、画面から変更できるようにする
入力すると、提案と質問が返ってきます。質問に答え、提案を確かめて「進めてください」と返すと、実装が始まります。
対応表を画面から変えられるようにしておくと、ルールが変わっても開発せずに済みます。
この例では、「2 つの機能なので Pull Request を分けましょう」と提案されることがあります。対応表を管理する画面と、担当者を自動で設定する仕組みは、別の機能だからです。その場合は提案に従い、1 つ目をマージしてから、新しいセッションで 2 つ目を頼みます。
もし、できたものがいまいちなら、Claude Code に「クローズして」と頼んで、マージせずに Pull Request を閉じれば、本番のアプリは変わりません。ただし、データベースの項目を足す場合は注意が必要です（「データベースの項目を増やす場合」で説明します）。
間違えて本番に反映したときには戻すこともできます。GitHub には、Revert（マージした変更を打ち消す機能）があり、Claude Code に頼めば使ってくれます。打ち消すための変更も PR として作られるので、履歴に「取り消した」記録が残り、あとで確認できます。
新しいセッションを始め、次のように入力する。
xxxxxxxxxx先ほどマージした PR（#nnn）の変更を取り消して（revert して）。
打ち消すための PR が作られるので、いつもと同じようにプレビューで確認し、「マージして」と入力する。
マージすると、本番のアプリが元の状態に戻ります。
GitHub の PR 画面にも Revert ボタンがありますが、押さずに Claude Code に頼んでください。データベースの項目を足した PR をボタンで戻すと、マイグレーション（データベースを変更する手順を書いたファイル）まで消えるため、検査（npm run check）が失敗します。Claude Code に頼めば、最初のセッションで指示したとおり、このファイルを残して戻してくれます。
データベースの項目を足した PR を取り消した場合、画面や機能は元に戻りますが、足したテーブルや列はデータベースに残ります。残っていても業務データやアプリの動作に影響はありませんが、あとで同じ機能を別の形で作り直すときに、エラーになることがあります。データベースの項目を足した PR を戻すときは、先に Claude Code に「この PR を Revert してよいか、データベースへの影響を確認して」と相談してください。
取り消しが不要だったときは、取り消し PR をさらに Revert すると、機能が復活します。今回は練習なので、本番で機能が消えたことを確かめたら、この方法で機能を復活させておいてください。
「優先度を追加したい」のように、データベースの列（保存する項目）が増える場合も、手順は同じです。データベースの変更は、デプロイのときに自動で反映されます。
ただし、項目を削除・変更すると、アプリが動かなくなったり、入力したデータが消えたりします。そこで、この勉強会では、あえて削除しない方式にし、次のルールを CLAUDE.md で守らせています。
テーブルや列の追加だけを行う
削除・改名・型変更はしない
追加する列は「値が空でもよい」ものにする
適用済みのマイグレーションファイルは編集せず、新しいファイルを足す
試しに項目を足してみたものの、不要になることもあります。画面や機能の変更は、PR を閉じれば（マージしなければ）、本番のアプリには何も影響がありません。しかし、テーブルや列の追加は PR を作ったり更新したりしたときのビルドで実行されるので、PR を閉じてもプレビュー用データベースにはテーブルや列が残ります（本番のデータベースには影響しません）。
使わないテーブルや列が残っても、業務データやアプリの動作に影響はありませんが、不要なものが増えてしまいます。また、あとで同じ項目をもう一度足そうとすると、プレビューのビルドが「すでにある」というエラーで失敗したり、エラーは出ないのにプレビュー用データベースの項目がアプリの想定と合わなくなったりします。そうなったときや、不要なものが気になったときは、プレビュー用データベースを作り直してください。プレビュー用データベースにはテスト用のデータしかないので、業務への影響はありません（Claude Code に「プレビュー用のデータベースを作り直して」と頼めば対応してくれます）。
問い合わせ管理が動いたら、備品の貸出管理や日報を足していきます。新しいアプリは作らず、同じアプリに 2 つ目の業務として追加します。手順は機能追加と同じで、画面の見た目、登録と一覧の作り、アクセス制限、データベースの扱いは、これまでの方式が引き継がれます。
プロンプトの例:
xxxxxxxxxx2 つ目の業務として、備品の貸出管理を追加してください。トップページのメニューにも追加してください。【解決したい業務】誰が何を借りているか分からず、探し回ることがある。返却漏れも起きている。【今回やりたいこと】- 備品の一覧と登録（備品名、管理番号、保管場所）- 貸出と返却の記録（借りた人、貸出日、返却予定日、返却日）- 貸出中のものだけを絞り込んで表示する
提案された計画に、他の業務（問い合わせ管理）のファイルを変える項目があれば、承認せずに「他の業務のファイルは変更しないでください」と伝えてください。
アプリと AI では、得意なことが違います。アプリは、決まったルールに従う処理や計算、一覧や検索、状態や担当者の共有、期限切れの通知のように、毎回同じ結果が求められることが得意です。AI は、文章を読んで分類する、下書きを作るといった、ルールにしづらいことが得意です。しかし、関係者との調整や、責任を伴う判断は AI に任せられないので、人が行います。
Cloudflare には、アプリから AI を呼び出せる Workers AI という機能があり、Worker の設定を変更するだけで使えます（設定変更は Claude Code で可能）。問い合わせ管理ボードなら、問い合わせの内容から返信の下書きを作ったり、商品分類を提案したりできます。
プロンプトの例:
xxxxxxxxxx問い合わせの詳細画面に、返信の下書きを作るボタンを追加してください。【解決したい業務】よくある問い合わせにも、毎回ゼロから返信を書いていて時間がかかる。【今回やりたいこと】- 問い合わせの内容から、返信の下書きを作って画面に表示する- 下書きは表示するだけで、自動で送ったり保存したりしない- Workers AI の、無料プランで使えるモデルを使う
AI の出力は、もっともらしく間違えることがあります。下書きとして扱い、人が内容を確かめてから使ってください。
試すだけなら、Workers の無料プランで十分ですが、業務で本格的に使うなら、有料プラン（月 $5 から。2026 年 9 月時点）を検討してください。無料プランは利用量が上限に達すると AI の機能が止まりますが、有料プランなら止まらず、性能の高いモデルも使えます。
つまずいたときの対処をまとめます。上から順に試してください。
プレビューを見て、思ったものと違った。 Claude Code に、どう違うかを日本語で伝えて直してもらいます。何度でも作り直せます。
何度言っても直らない。 Claude Code に「クローズして」と頼んで PR を閉じ、セッションを終えます。新しいセッションで、指示の書き方を変えてやり直すほうが速いこともあります。
エラーの画面が出た。 エラーの文章をそのまま Claude Code に貼ります。多くはこれで直ります。直らなければ、「まだ同じエラーが出ます」と伝えて、調べ直してもらいます。
会話がかみ合わなくなった。
新しいセッションを始めます。経緯は CLAUDE.md、引き継ぎの記録、issue に残っているので、続きから作業できます。会話が長くなると指示が伝わりにくくなるので、依頼事項ごとに新しく始めるのが基本です。
本番に反映したあとで問題に気づいた。 「戻してみる」の手順で戻します。
社員がログインできない。 「Cloudflare Access の認証設定」の One-time PIN が設定されているか、「アクセスできる人を管理する」の条件にその人のメールアドレスやドメインが含まれているかを確認します。
どうしても分からない。 Claude Code に「何が起きているのか、専門家に説明するための文章を書いて」と頼み、その文章を持って専門家に相談してください。
うまくいかなくても、マージしなければ本番のアプリは壊れません。安心して何回でも試してください。
AI を使うと、開発やドキュメント作成の効率は大きく上がります。ただし、次のような特性もあるので、少しだけ気をつけてください。
事実と異なる内容を、もっともらしく出力することがある
出力の量が多く、人間がレビューしきれなくなる
そのままでは本番運用の品質に届いていないことがある
人間が作っても起きる問題が、開発が速いぶん短期間に数多く発生する
これらをすべてなくすのは難しいですが、今回の進め方（最初のセッションで決めたルール、自動の検査、プレビューでの確認）には、影響を小さくする工夫を入れています。
使っていて気になることが出てきたら、Claude Code に伝えて、CLAUDE.md のルールに足してもらってください。
アプリを作るべきか、作る価値があるかを、次の観点で考えます。
アプリの責任範囲の観点
アプリの扱うデータや業務上の責任が重すぎないですか。
そのアプリが止まったら、何が起きますか。
アプリの構造の観点
アプリの構造が複雑で高度すぎませんか。
業務手順の観点
業務を簡略化すれば解決しませんか。
投資の観点
その作業に、月に何時間かかっていますか。
その作業で、月に何件、間違いや漏れが出ていますか。
管理の観点
作ったアプリの修正や障害対応を、社内の誰が担当しますか。
同じことができる SaaS や、いまのシステムの設定変更で済みませんか。
まず、責任範囲と構造の観点です。社内にアプリケーションエンジニアがいない場合、次に当てはまるなら、専門家に相談することを強くおすすめします。
扱うデータや業務上の責任が重いもの
外部に漏れたら困る
要配慮個人情報（健康診断や病歴、信条、犯罪歴など）を扱う 漏洩は人数にかかわらず報告義務がある
財産的被害のおそれがある情報を扱う 漏洩は人数にかかわらず報告義務がある
マイナンバーを扱う
人事評価、給与、家族構成など、本人にとって機微な情報を扱う
1,000 人分を超える個人データを保有する 漏洩した本人の数が 1,000 人を超える場合は報告義務がある
秘密情報（パスワード、API キー、復元コード等）を扱う
取引先との契約で、国外への保存などが禁じられている情報を扱う
専門知識が必要
金銭取引そのものを扱う
法規に関連する業務を扱う
業務影響が大きい
停止したら業務が止まる
構造が複雑で高度なアプリ
外部の顧客やユーザーが利用する（一般公開する）
複数人が同じ画面を同時に編集する
複雑な画面操作が必要（ドラッグ操作、図形やレイアウトの編集など）
数十万件規模のデータを集計・分析する
インターネットに接続できない場所で使う
スマートフォンのアプリとして配布する
他のシステムとの自動連携が主な目的になる
なお、上に当てはまらない場合でも、個人データ（顧客や社員の氏名、連絡先など）を保存するなら、保存先の公表が必要です。Cloudflare の契約相手は米国の Cloudflare, Inc. なので、DB を東京や大阪に置いても、米国の個人情報保護の制度を把握したうえで、事業者とサーバーの国、講じている措置をプライバシーポリシーなどに書きます。書き方が分からない場合や、国内に保存したい場合は、専門家に相談してください。
そのうえで、作る価値があるかを考えます。
その作業が月 5 時間もかからず、間違いや漏れも起きていないなら、作らないほうが無難です。作る手間と管理する手間のほうが大きくなるからです。手順を減らす、様式をそろえるといった簡略化で済まないかも考えます。一方、月 5 時間を超える、または間違いや漏れが起きているなら、開発を検討する価値があります。
費用だけで比べれば、今回の構成はほとんどお金がかからないので（「費用の目安」で説明します）、SaaS より安く済みます。それでも、いま使っている会計ソフトやグループウェアの設定変更で済むなら、それが一番です。次に、自社の業務に合う SaaS があれば、SaaS をおすすめします。保守やセキュリティ対策、バックアップ、障害対応を提供会社に任せられるからです。設定変更では足りず、SaaS も自社のやり方に合わない、複数の SaaS が必要になる、契約するには人数が少なすぎる、といった場合に、アプリを作ります。
アプリを安全に運用するための補足です。
社内の小さな業務アプリなら、GitHub も Cloudflare も無料の範囲で使えます。無料の範囲は、おおよそ次のとおりです（2026 年 9 月時点。最新の条件は各社のサイトで確認してください）。
アプリを開く回数が 1 日あたり 10 万回まで
データベースの読み取りが 1 日あたり 500 万行、書き込みが 10 万行まで
データベースに保存するデータが 500 MB まで（データベース 1 つあたり）
アプリを利用する人が 50 人まで
アクセス制限の無料枠
超えた人はログインできなくなります
アプリを開く回数やデータベースの読み書きが上限を超えると、翌朝 9 時（日本時間）までアプリが使えなくなります。この範囲を超えそうなら、専門家に相談してください。
かかる費用は、次のとおりです。
作っている間：月額 $20 前後（Claude の Pro プラン）
作り終えて、使っているだけの間：月額 0 円
Claude の Pro プランは、開発しない間は解約できます。解約してもアプリはそのまま使えるので、機能追加や修正が必要なときだけ契約する方法でも構いません。
これは見落とされがちですが、とても大事なことです。
GitHub と Cloudflare を担当者の個人名義だけで使っていると、その人が辞めたとき、会社としてアプリを管理できなくなります。ソースも、データも、アプリの URL も、支払いも、その人しか触れないからです。
かといって、会社共用の ID を 1 つ作って使い回すのもやめてください。誰が何をしたか分からなくなるうえ、GitHub の利用規約でも、1 つのログインを複数人で使うことは禁じられています。ログインは各人が自分のアカウントで行い、資産は会社が持つ形にします。
GitHub 会社の Organization（組織アカウント）を作り、リポジトリはその下に置きます。各担当者は、自分の個人アカウントで Organization に参加します。Owner（所有者）は必ず 2 人以上にしてください。1 人だと、その人と連絡が取れなくなった時点で誰も触れなくなります。個人アカウントの下に作ったリポジトリは、あとから Organization に移せます。
Cloudflare
Cloudflare の Organization 機能は Enterprise 限定で、無料プランでは使えません。代わりに、設定や支払いをまとめる「アカウント」という単位（ログインとは別のもの）を使います。会社用のアカウントを 1 つ決め、Members（メンバー管理）の画面から、別の担当者をもう 1 人、Super Administrator（最上位の管理者）として招待します。ここでも各人は自分のログインを使い、支払い方法は会社のものを登録します。
ここでの管理者は、設定や課金を変えられる人のことです。Cloudflare Access で許可する「アプリを開ける人」とは別なので、混同しないでください。
誰が所有者で誰が管理者かは、管理台帳に書いておきます。あとから変えるのは手間がかかるので、最初に決めておくことをおすすめします。
Cloudflare Access でアクセスを許可した人は、入社や退職で変わっていくので、管理が必要です。
今、誰がこのアプリにアクセスできるのかを確認できるようにしておく
人が入ったとき、辞めたときに、この設定を見直す
見直す担当者と、見直す時期を決めておく
設定の確認や変更は、Cloudflare の管理画面で行います。
Cloudflare の管理画面で Workers & Pages を開き、Access タブを開く。Worker ごとの Access ポリシーが一覧で表示されます。
対象のポリシーを開くと、今、誰がアクセスできるのかが書かれています。
Email domain（Emails ending in）なら、そのドメインのメールアドレスを持つ人が開けます。
Emails なら、そこに並んでいるメールアドレスの人だけが開けます。
Cloudflare account なら、この Cloudflare アカウントのメンバーだけが開けます。
変更するときは、この条件を編集して保存します。人を増やすならメールアドレスを足し、辞めた人を外すならその行を消します。
細かい条件は、Zero Trust › Access controls › Applications からも編集できます。
本番用とプレビュー用が別のポリシーになっている場合があるので、両方を確認してください。
メールアドレスを個別に並べる方式は、人数が少ないうちは分かりやすいものの、更新を忘れがちです。会社のドメインで指定し、退職時にメールアカウントを止める運用とそろえておくほうが、見落としが起きにくくなります。どちらの方式でも、退職の手続きにこの確認を入れ、定期的に見直す時期も決めておいてください。
アクセス制限を変えても、データは消えません。辞めた人が登録したデータも残るので、安心して変更してください。
障害のとき、アプリをやめるとき、他の仕組みに移すときに備えて、本番のデータベースからデータを取り出す方法を用意しておきます。
次のどちらかを用意し、運用を始める前に一度試して、手順を管理台帳に書いておいてください。いざというときに初めて試すのでは間に合いません。
一覧を CSV で書き出す機能を、最初の機能追加として作っておく（担当者が自分で取り出せるので、おすすめです）
Claude Code に「Cloudflare コネクタでデータベースの内容をすべて読み出し、テーブルごとに CSV ファイルとしてリポジトリに保存して」と頼む
Cloudflare には、データベースを過去の時点に戻す機能（D1 Time Travel）もあります。ただし、戻せるのは無料プランで 7 日前まで（有料プランで 30 日前まで）で、コマンドラインでの操作が必要です（2026 年 9 月時点）。使うときは専門家に頼む前提で管理台帳に書いておき、これに頼りきらず、上の方法でデータを取り出しておいてください。
アプリが止まっている間、業務をどうするかも決めておきます。多くは「元の Excel やメールの運用に一時的に戻す」で足りますが、決めておくこと自体が大事です。
セキュリティ対策は、本来は最初から織り込むものです（そのために CLAUDE.md に書いています）。ただ、作ってみないと分からないこともあるので、最後にも確認します。
Cloudflare Access で利用者を絞っているので、一般公開するアプリよりリスクは小さいものの、レビューする価値はあります。
新しいセッションで、次のように入力します。
xxxxxxxxxxセキュリティレビューをして。- 見つかった問題は、深刻なものから順に、日本語で説明してください。- すぐに直さず、何をどう直すかを説明してから、承認を待ってください。- 専門家に相談したほうがよいものがあれば、そう言ってください。
ただし、レビューするのはコードを書いたのと同じ AI です。自分で作ったものを自分で点検するので、見落としが残ることがあります。
また、安全かどうかは、アプリが何を扱うかで大きく変わります。「作るかどうかを判断する」で挙げたもの（要配慮個人情報、マイナンバー、金銭取引、秘密情報など）を扱う場合や、一般公開する場合は、レビューの結果にかかわらず専門家に相談してください。
作ったアプリを会社として管理するために、管理台帳を埋めます。管理台帳は、最初のセッションでリポジトリの中に作られています。
台帳をリポジトリの中に置いているのは、アプリとその説明が離れないようにするためです。別の場所に作った管理表は、更新されなくなりがちです。
作った直後は空欄のままで構いませんが、運用を始める前に、アカウントの名義、アクセスできる人、データの取り出し方、やめるときの手順まで埋めてください。
台帳を埋めるのも、AI に手伝ってもらえます。新しいセッションで、次のように指示します。
xxxxxxxxxx最初のセッションで作った管理台帳を埋めるのを手伝ってください。台帳には、少なくとも次の項目を含めてください。- 本番 URL- 月額費用- アカウントの名義（GitHub と Cloudflare の所有者と管理者）- アクセスできる人（許可の方式、確認する場所、見直す担当者と時期）- データの取り出し方- 障害時の連絡先と、アプリが止まっている間の業務のやり方- やめるときの手順埋めるときは、次のようにしてください。- リポジトリや設定から分かることは、自分で調べて埋めてください。推測はせず、分からなければ「未確認」と書いてください。- 私しか答えられないことは、専門用語を使わず、一問ずつ聞いてください。- パスワードや API キーなどの秘密情報は書かないでください。- 決まっていない項目は「未定」とし、誰がいつ決めるかを添えてください。埋め終わったら、コミットして Pull Request を作ってください。
聞かれたことに答えていくと、台帳が埋まります。答えられない項目は、誰がいつ決めるかを書き残してください。
アプリが使っているパッケージ（部品）には、次々と新しいバージョンが出ます。一般には、セキュリティのために更新が推奨されますが、Cloudflare Access の内側にある社内アプリなら、必ずしも最新にする必要はありません。外部からアクセスされないのでリスクが小さく、土台の部分は Cloudflare 側で更新されるからです。
ただ、久しぶりに開発を再開すると、これが問題になることがあります。Cloudflare のビルド環境が更新されていると、使っているパッケージも更新が必要になり、その副作用で、これまで動いていた機能が動かなくなることがあるからです。
そこで、久しぶりのときは、いきなり機能追加を頼まず、新しいセッションでまず次のように指示します。
xxxxxxxxxx久しぶりに開発を再開します。機能追加の前に、パッケージの更新が必要か調べて。必要なら、パッケージの更新だけの PR を作って。
PR ができたら、プレビューで今までどおり動くことを確かめてマージし、そのあと、新しいセッションで機能追加を頼みます。こうすると、動かなくなっても、パッケージ更新と機能追加のどちらが原因かすぐに分かります。
作ったアプリも、いつかは使わなくなります。使われないまま動き続けるアプリは、費用も、アクセス権も、中のデータも、誰にも管理されなくなります。そこで、始める前に終わり方を決めておきます。
どうなったらやめるか（業務がなくなった、SaaS に移した、使われなくなった）
やめるときに、データをどう取り出して、どこに保管するか
アプリ、データベース、リポジトリ、アクセス設定を、誰がいつ消すか
利用者にいつ知らせるか
これも管理台帳に書いておきます。
今回の勉強会を通して、次のことが分かっていただけたら幸いです。
AI でアプリ開発がどれだけ手軽になったか
改善対象をどう選ぶか
どこから専門家が必要になるか
どのように失敗を戻せる形でアプリを作るか
作ったアプリをどのように会社で管理するか