Opsfield
Claude Codeを触り始めて、Skillsの構築やAIエージェントの作成までは手が届いた、という方は多いと思います。ただ、画面があって他の人が使えるアプリとなると、まだ最後まで形にしたことがない。そのあたりで足が止まる話をよく聞きます。
Claude CodeでWebアプリを作ること自体は、専門の開発経験がなくても十分に届く範囲にあります。一方で、作ったものを社外に出して使ってもらう段階になると、作る力とは別の知識が求められます。この線引きを知らないまま進めると、動くところまでは行けても、公開したあとで止まります。
本記事では、Claude CodeでWebアプリを作る流れを7つの手順に分けて解説します。あわせて、作り始める前に決めておくこと、公開するときに確かめること、公開後に動かし続けるために必要なことまで扱います。
目次
Claude CodeでWebアプリはどこまで作れるのか
結論から言えば、Claude Codeだけで形になるのは、社内の数人が使う道具と、検証用の試作までです。社外の人に使ってもらうサービスにするとなると、作る力とは別の知識が必要になります。
例えば、問い合わせ内容を入力して一覧で表示するだけの社内フォームなら、1本目から形にできます。Claude Codeはファイルを直接書き換え、コマンドの実行までこなすため、画面を作る、入力内容を保存する、公開の準備をする、という流れを止めずに進められます。
かかる時間も、この範囲なら現実的です。実際に作った人の記録では、1画面だけのツールが数十分で動いた例もあれば、複数画面のアプリに数日かけた例もありました。
一方、社外に出すとなると、無料枠の制限、開ける人の制限、部品の更新、壊れたときの戻し方といった運用の仕事が乗ります。出てきた結果が業務として正しいかを判定するのも、引き続き人の側です。境界線を決めるのは機能の難しさではなく、出来上がったあとに誰が手入れを続けるのかです。1画面だけのアプリでも、見る人がいなければいつか止まります。
Claude CodeでWebアプリを作る前に決めておく3つのこと
Webアプリを作り始める前に決めておくと、後戻りが減る論点が3つあります。
その場限りで使い捨てるか、業務で使い続けるか
1つ目は、そのアプリを使い捨てるのか、業務に組み込んで使い続けるのかです。これは作り方より先に決めます。
1回だけデータを整形して終わるなら、動けば十分で、後片付けも要りません。一方、毎月の請求確認のように業務へ組み込むなら、動かし続ける仕事が発生します。使っている部品の更新、止まったときの復旧、業務が変わったときの直し。この3つは作る作業とは性質が違い、Claude Codeに指示を出せば済む話ではなくなります。
つまり、この判断がそのまま保守の要否を決めます。使い続ける側に倒すなら、誰がその面倒を見るのかまで、着手前に決めておいた方が安全です。担当者が決まらないまま公開されたアプリは、半年後に壊れて、そのまま使われなくなります。
自分だけが使うか、社内の誰かに渡すか
2つ目は、使う人の範囲です。自分ひとりで使うのか、部署の数人に渡すのかで、必要になる作りが変わります。
自分だけなら、多少の操作の癖は頭に入っているので問題になりません。ところが他人に渡した瞬間、想定外の入力が来ます。空欄のまま送信する、同じボタンを連打する、全角の数字を入れる。こうした操作で落ちないようにする手当ては、機能そのものより手間がかかることも珍しくありません。
また、渡す相手が増えるほど、誰が使ってよいのかを決める必要も出てきます。社内の全員なのか、特定の部署だけなのか。ここを曖昧にしたまま公開すると、あとから制限をかけ直す作り直しが発生します。ログインの仕組みは後付けするほど高くつくので、渡す相手が1人でも増えるなら最初から見込んでおきます。
扱うデータをどこに置くか
3つ目は、データの置き場所です。ブラウザの中だけで完結させるのか、外部のデータベースに保存するのかを先に決めます。
このうちブラウザの中に保存する方式は、追加の準備が要らない代わりに、別の端末からは中身が見えません。共有して使うならデータベースが必要になり、そこには接続情報の管理と、無料枠の制限という別の論点がついてきます。例えば、しばらく使わないと止まる無料データベースを選ぶと、月初にだけ開く業務では毎回止まった状態に出くわします。
特に、個人情報や取引先の情報を入れるつもりなら、社内でどのサービスに置いてよいかの確認を先に通しておきます。作ってから置き場所を変えるのは、作り直しに近い手間がかかります。
Claude CodeでWebアプリを作る7つの手順
ここからは実際に手を動かす流れです。作る場所を決めるところから、前に動いていた機能が壊れていないと確かめるまでを、7つの手順に分けて追っていきます。
ローカルとクラウドのどちらで作るかを決める
1つ目の手順は、Webアプリを作る場所を決めることです。
Claude Codeには、手元の端末にインストールして使う方法と、ブラウザから使う方法（Claude Code on the web）があります。後者はGitHubのアカウントをつなぐだけで始められるので、社内の端末にソフトを入れにくいならこちらが早いです。
なお、どちらもClaude.aiの無料プランでは使えません。手元の端末ではPro・Max・Team・EnterpriseかConsole（API従量課金）のアカウントが要ります（公式のセットアップ手順）。ブラウザから使う方の対象は、Pro・Max・Teamと一部の席を持つEnterpriseです（公式ドキュメント）。
場所が決まったら、作業用のフォルダを新しく1つ作り、その中でClaude Codeを起動します。既存のファイルが混ざった場所だと、何を触られたのかが追えません。ブラウザから使う場合は、GitHubのリポジトリ（コードの保管場所）を1つ用意する作業がこれに当たります。
| 比較する観点 | ローカル（手元の端末） | クラウド（ブラウザ） |
|---|---|---|
| 必要な準備 | 対応OSの確認と端末へのインストール | ブラウザとGitHubアカウントの接続 |
| 作業できる場所 | インストールした端末のみ | ブラウザとスマートフォンのアプリ |
| 向く作りもの | 手元のファイルや社内データにつなぐもの | GitHub上のコードだけで完結するもの |
作るものを1機能に絞り、要件をファイルに残す
2つ目の手順は、作るものを1機能に絞り、決めた内容をファイルに書き残すことです。
注意したいのは、会話の中で伝えた仕様がセッションをまたいで残らないことです。そのため、扱う項目、入力の制限、やらないことを、リポジトリの中のテキストファイルに書いておきます。例えば社内の備品申請なら、扱うのは申請者・品目・数量・希望日の4項目だけ、承認機能は作らない、と1行ずつ書く。この粒度で十分です。
ここで効いてくるのは、作らないものを先に書くことです。AIは頼めば機能を足してくれるので、止める側の線を引いておかないと、確認しきれない量に膨らみます。書いたファイルは、次に指示を出すときにそのまま読ませます。セッションが切れても、このファイルさえあれば同じ前提から再開できます。
技術の組み合わせをClaude Codeに提案させる
3つ目の手順は、何で作るかをClaude Codeに提案させることです。
ここでも、使う言語やフレームワークを自分で決める必要はありません。前の手順で書いた要件のファイルを読ませたうえで、公開先の候補と保守のしやすさを条件に挙げ、選択肢を出させます。その際、選んだ理由と、他の候補を外した理由まで説明させると、後から見直すときの手がかりが残ります。
とはいえ、提案をそのまま受け入れる必要もありません。社内ですでに使っているサービスがあるなら、それに寄せた方が運用は楽になります。判断材料が足りないと感じたら、候補を2つに絞らせて、それぞれの扱いやすさを比べさせます。珍しい組み合わせを選ぶと、詰まったときに調べても情報が出てこず、そこで行き詰まります。
操作画面から作り、動かしながら直す
4つ目の手順は、操作画面から作ることです。データの構造より先に、人が触る部分を形にします。
というのも、操作画面が出来ていると、足りない項目や不自然な並びがその場で分かるからです。逆に、裏側の仕組みから積み上げると、出来上がってから作り直す範囲が大きくなりがちです。まずは保存もしない見た目だけの画面を出させ、ブラウザで開き、気になった箇所をその場で伝えて直させます。
このとき、直す単位は小さく保ちます。一度に5か所直させると、どの変更が効いて動かなくなったのかを追えません。1つ直すたびに動かして確かめる。地味ですが、これが結局いちばん速い進め方です。指示も、見た目の希望を並べるより、ボタンの位置を1つ動かす依頼を重ねた方が狙いどおりに収まります。
データの保存と読み出しをつなぐ
5つ目の手順は、入力した内容を保存して、あとから読み出せるようにすることです。
ここで初めて、データベースやファイルへの保存が入ってきます。作り始める前に決めた置き場所に合わせ、保存する処理と一覧で読み出す処理をセットで作らせます。例えば申請フォームなら、送信した内容が一覧画面にそのまま出るところまでを1回で確かめます。
また、保存の失敗も試しておきます。必須項目を空にして送る、極端に長い文字列を入れる、同じ内容を二重に送る。この3つを通してみて、画面が固まらずにメッセージが出れば、最低限の作りにはなっています。うまくいく場合だけを確かめて先へ進むと、他人に渡した初日にここでつまずきます。二重送信は特に見落としやすく、同じ申請が2件並んでから気づくことになりがちです。
鍵や個人情報をコードの中に置いたままにしない
6つ目の手順は、接続情報をコードの中から追い出すことです。ここは非エンジニアがもっとも踏みやすい落とし穴になります。
そもそも外部サービスにつなぐと、APIキー（外部サービスを使うための鍵）や、データベースの接続文字列が必要になります。これをコードに直接書いたままリポジトリに上げると、誰でも読める状態に置かれかねません。そのため、環境変数（実行時に外から渡す設定値）に移し、鍵を書いたファイルはGitの管理対象から外します。
なお、GitHubにはリポジトリ内のシークレットを自動で検出する仕組みがあり、公開リポジトリでは無償で動きます。公開リポジトリへのプッシュはプッシュ保護が既定で働き、鍵を含むプッシュをその場で止めます。プライベートリポジトリで同じ保護をかけるには、有料のGitHub Secret Protectionが必要です。ただし、これは最後の網にすぎません。止められた時点で、その鍵は作り直します。
テストで前の機能が壊れていないことを確かめる
7つ目の手順は、自動で動くテストを用意することです。
実のところ、Webアプリは機能を足すたびに、前から動いていた部分が静かに壊れます。人が毎回すべての画面を触って確かめるのは現実的ではないため、主要な動作を確かめるコードをClaude Codeに書かせ、変更のたびに実行します。申請が保存される、一覧に出る、必須項目が空なら弾かれる。この程度の数から始めて構いません。
ここで大事なのは、テストを書かせること自体より、何を合格とするかを人が決めることです。AIは指示した観点なら網羅してくれますが、業務として何がまずいのかまでは分かりません。例えば、申請の数量にマイナスが入っても保存できてしまう作りは、動作としては正常でも業務としては失格です。合否の基準を持つのは、引き続き人の側になります。
作ったWebアプリを公開するときに確かめること
作ったものは、手元で動くだけでは業務に乗りません。公開先の決め方から、公開ボタンを押す直前に自分の目で見る点まで、順に3つ挙げます。
公開先は誰に使わせるかで決まる
1つ目は、公開先の決め方です。機能ではなく、誰に使わせるかで選びます。
まず、社内の数人が使うだけなら、無料枠のあるホスティングサービスで十分です。ただし、無料枠には利用目的の条件が付いていることがあります。例えばVercelのHobbyプランは非商用の個人利用に限られ、公式の規定では、給与を受け取っている社員がそのコードを書いた場合も商用利用に含まれるとされています。業務で使うならProまたはEnterpriseが必要です。
そのため、社内ツールだから無料で構わない、とは限りません。料金以前に、規約に沿っているかの話になります。公開先を決めるときは、料金表と同じくらい利用条件の欄を読んでおきましょう。
任せられる作業と、自分の手に残す作業を分ける
2つ目は、公開の作業のうちどこを自分でやるかです。手順が決まっている部分は、Claude Codeに任せて差し支えありません。
実際のところ、公開先を伝えれば、必要な設定ファイルの追加、ビルドの設定、コマンドの実行まで進めてくれます。途中でエラーが出ても、内容を読んで直すところまで任せて構いません。自分で調べながら進めれば半日かかる作業が、うまくいけば数十分で片付きます。
ただし、接続情報だけは自分で入れましょう。公開先の管理画面に環境変数として登録する作業は、鍵そのものを扱うので人の手に残しておいた方が安全です。ここを会話の中に貼って渡すと、履歴に鍵が残ってしまいます。
なお、公開が一度通れば、2回目以降は数分で終わります。完成してからまとめて公開するより、動く状態になった早い段階で一度通しておく方が確実です。
公開ボタンを押す前に自分で確かめる3点
3つ目は、公開ボタンを押す前の最終確認です。見ておく点は3つあります。
まず、鍵や接続情報が画面のソースに出ていないこと。ブラウザでページのソースを表示し、それらしい文字列を検索すれば分かります。次に、公開先の設定で、意図した範囲の人しか開けない状態になっていること。最後に、入力した内容がどこに保存されるのかを自分の言葉で説明できることです。
この3つは、どれもAIに聞いて済ませず、自分で画面を開いて確かめます。動作が正しいかの確認と違い、ここは間違えたときの影響が社外に出ます。大丈夫だという返事をもらっても、それは確認したことにはなりません。確かめた結果は、日付とあわせてメモに残しておくと、あとで問われたときに答えられます。
公開したWebアプリを動かし続けるために必要なこと
ここが、作れることと提供できることの分かれ目になります。公開した瞬間から動かし続ける仕事が始まり、これはClaude Codeに指示を出すだけでは片付きません。必要になることを4つに分けて説明します。
無料枠では止まる前提で公開先を選ぶ
1つ目は、無料枠がどこまで持つかを見込んでおくことです。無料は費用がかからないという意味であって、止まらないという意味ではありません。
例えばRenderの無料プランでは、15分間リクエストがないWebサービスは停止し、次のアクセスで起動し直すまでに約1分かかります。無料のPostgresデータベースは作成から30日で期限切れになり、猶予期間を過ぎると削除されます（公式ドキュメント）。Supabaseの無料プランでも、7日間データベースへの活動が少ないとプロジェクトが一時停止されます。
つまり、月初にしか開かない業務用のアプリほど、無料枠と相性が悪くなります。なお、Claude Code自体もClaude.aiの無料プランでは使えません。作る側と動かす側の両方に、最低限の費用は発生すると見ておきます。
誰が開けるアプリなのかを決めて制限する
2つ目は、開ける人を絞ることです。URLを知っている人だけが使う、という運用は制限になっていません。
実際、公開したURLは、検索に載ることもあれば、社内チャットの転送で社外に渡ることもあります。制限をかけるなら、ログインを求めるか、公開先の機能で鍵をかけるかの二択です。ただし後者は無料枠に入っていないことが多く、例えばVercelのパスワード保護はHobbyプランでは使えず、Proでは保護するプロジェクトごとに月20ドルかかります（公式ドキュメント）。同じVercelでも、そのプロジェクトへのアクセス権を持つメンバーにログインを求める方式なら、追加費用なしで使えます。
そのため、誰に見せるのかは公開先を決める段階で確定させます。社内だけに閉じたいのか、取引先にも渡すのか。ここが後から変わると、作り直しではなく契約の見直しから始まることになります。
使っている部品を定期的に更新する
3つ目は、使っている部品の更新です。Webアプリは、外部の部品を何十個も組み合わせて動いています。
ところが、これらの部品には、脆弱性が見つかって修正版が出ることがあります。放置すると、ある日を境にデプロイ（更新した内容を公開先へ反映する処理）が通らなくなったり、つないでいるサービス側の仕様変更で連携が切れたりします。半年放置したアプリが原因の見当もつかないまま止まるのは、この積み重ねによるものです。
対処としては、GitHubに標準で備わっているDependabot（依存関係の更新を検知して自動でプルリクエストを作る機能）を有効にし、月に一度まとめて上げるだけでも違います。更新したら、手順7で用意したテストを走らせ、壊れていないことを確かめる。この2つが揃って、初めて動かし続けられる状態になります。
壊れたときに前の状態へ戻せるようにする
4つ目は、戻し方を先に用意しておくことです。
そもそも、直そうとして手を入れた結果、さらに壊れる場面は必ず来ます。そのとき、動いていた時点に戻せるかどうかで被害の大きさが変わります。Gitで変更をこまめにコミットしておけば、動いていた時点を指定して戻せます。多くのホスティングサービスにも、過去の公開状態に切り替え直す機能があります。
とはいえ、データベースの中身は戻りません。コードを戻しても、消えたデータは戻らない。この違いを分かったうえで、大事なデータは別にバックアップを取る段取りまで決めておきます。無料枠のデータベースには自動のバックアップが付かないこともあるため、そこは公開前に確認しておきたい点です。ここまでやって、やっと社外の人に使ってもらえる土台になります。
Webアプリ開発でつまずきやすい場面と抜け出し方
ここまでの手順をなぞっても、途中で手が止まる場面は出てきます。どれも作り方の問題ではなく、進め方を変えれば抜け出せるものばかりです。つまずきやすい場面とその抜け出し方を4つ取り上げます。
同じエラーを直し続けて前に進まなくなる
1つ目は、同じエラーの周りを回り続ける状態です。直しては別の場所が壊れ、また戻る。これが3往復続いたら、やり方の方を変えます。
まず、会話を一度切って、新しいセッションで始め直します。長い会話の中では、前に試して失敗した方針が文脈に残り、そこへ引きずられるためです。そのうえで、エラーの文面をそのまま貼り、何をどう直そうとして失敗したかを最初に伝えます。
それでも抜けない場合は、その機能を一度消し、要件を書き直してから作り直させた方が早いこともあります。継ぎはぎを直し続けるより、小さく作り直す。目安は、同じ箇所を5回直しても収まらないかどうかです。そこまで来たら、原因は書き方ではなく、最初に渡した要件の曖昧さにあると考えた方が当たります。
機能を足したら前に動いていた部分が壊れる
2つ目は、機能を足した途端に、前から動いていた部分が動かなくなる場面です。
原因の多くは、1回の指示で触らせた範囲が広すぎることにあります。そのため、機能を足す前にコミットを1つ作り、足したあとで動作を確かめ、問題なければまたコミットする。この刻みを守るだけで、疑うべき原因が直前の変更に限定されます。
また、壊れた箇所を伝えるときは、症状ではなく再現の手順を渡します。うまく動かないと伝えるより、どの画面でどう操作したら何が起きたかを順に書く方が、直るまでが短くなります。ブラウザに出ているエラーの文面をそのまま貼れば、さらに早く収まるはずです。
その点で、手順7のテストが効いてくるのもここです。壊れた瞬間にテストが落ちれば、原因を探す範囲は直前の変更だけで済みます。
動いてはいるが中身を誰も説明できない
3つ目は、動いてはいるものの、何がどう動いているのかを誰も説明できない状態です。属人化ならまだ良い方で、実際には誰の担当でもない状態に近くなります。
しかも、こうなったアプリは、不具合が出た瞬間に手が出せません。防ぐには、作りながら説明を残させます。主要なファイルが何をしているのか、データがどこを通るのかを、Claude Codeに日本語で書き出させてリポジトリに置いておく。作業のついでなら手間はほとんどかかりません。
もちろん、すべてを理解する必要はありません。ただし、どこを触ると何が変わるのかの見取り図だけは持っておきます。これがないまま人に渡すと、渡された側が最初にやるのは作り直しです。引き継げない業務はAIにも引き継げない、という話は、そのまま自分で作ったアプリにも当てはまります。
指示どおりに作られたのに、使うと業務に合わない
4つ目は、指示したとおりに出来上がったのに、実際の業務では使えない場面です。これがもっとも起こりやすいつまずきになります。
原因ははっきりしています。いまの業務のやり方を、そのまま画面に写したことです。紙の申請書を画面に置き換えると、紙だから必要だった項目まで残ります。例えば、担当者名を手書きする欄は、ログインしていれば不要です。
そのため、作る前に工程を分解し、何を残して何をやめるかを決めておきます。ツールを決めるのは、そのあとです。この順番を逆にすると、動くけれど誰も開かないアプリが1つ増えます。
とはいえ、分解といっても難しい作業ではありません。誰が、いつ、何を見て、どう判断しているかを工程ごとに書き出すだけで、AIに渡せる部分と人が持つべき部分は自然に分かれます。ここまで済ませてから作れば、出来上がったものが業務から外れることはまずありません。
まとめ
Claude CodeでWebアプリを作る流れは、作る場所を決め、要件を絞り、画面を作り、データをつなぎ、鍵を分け、テストで確かめるまでの7つに整理できます。この範囲であれば、専門の開発経験がなくても手が届く領域です。
一方、社外に提供するサービスとして成り立たせるには、無料枠の制限、開ける人の制限、部品の更新、戻し方の用意といった運用の仕事が乗ります。ここはClaude Codeへの指示だけでは埋まらず、別の知識が要る領域です。だからこそ、着手前に使い捨てるのか使い続けるのかを決めておく意味があります。
まずは1画面・1機能に絞り、扱う項目とやらないことを4行で書き出すところから始めてみてください。それが、7つの手順に入る一番速い入り口になります。
