月額高額なCRMは不要？Claude CodeとXserverで自営業向け専用CRMを自作してみた。

結論 : プログラムとシステムの専門知識に乏しくても「完全自作CRM」は動くところまで作れた

普段、企業で社内SEとして高機能なCRM（顧客管理システム）の運用管理をしている私が、「もし個人事業主や小規模事業者が、コストをかけずに自分専用のCRMを持てたら？」という検証のもと、AI（Claude Code）と一緒に業務CRMを自作しました。

結論から言うと、プログラミングコードを自分で一切書かなくても、レンタルサーバー（Xserver）上で実際に動作し、実務で使えるレベルのCRMが完成しました。

本記事では、中小企業の社内SEである私の視点から「AIにどのような要件を伝えたのか」「Xserverの制約（root権限なし等）をどうクリアしたか」「GitHubとrsyncを用いた運用・デプロイ体制の作り方」まで、具体的なプロセスを解説します。

「既成のCRMは高機能すぎて使いこなせない」「月額コストを抑えて自社専用の業務ツールを作りたい」と考えている方は、ぜひ参考にしてください。

完成したCRMのサンプル画像です。全てエラーなく動きました。

私は普段、社内SEとして企業向けのCRM製品を運用管理しています。高額なSalesforceや、それに比べるとお手頃と言われるZoho CRMをはじめ、高機能なCRMがどれだけ業務を楽にするか、身をもって知っている立場です。その一方で、個人事業主や小規模事業者の方には、その便利さがなかなか手の届かないところにあることも感じていました。

そこで試したのが、AI(Claude Code)に業務システムの開発をまるごと依頼するという方法です。題材に選んだのは、私が本業としている「PC・ネットワーク・OA機器のサポート業務」を営む、個人事業主向けのCRMという設定です。

顧客管理、案件・問い合わせ対応履歴、機器の資産管理、契約・保守期限の管理。この4つを一通り備えたシステムを、Xserverのスタンダードプラン(月額1,000円台から使える共用レンタルサーバー)の上で動かすところまで、実際にやってみました。

この記事では、

• 何を、どうAIに伝えたのか(発案・要件ヒアリング)
• AIがどんな設計方針を示し、どう実装したのか
• 実際にXserverへデプロイし、動かすまでに何をしたのか
• 「作って終わり」にしないための、GitHubとの連携・継続運用の仕組み

という一連の流れを、実際のやり取りに沿って順番にお伝えします。

システムやプログラムの専門知識がなくても、自分の業務に必要なシステムを、自分の言葉で形にできる。その手触りが、少しでも伝われば嬉しいです。

1. なぜ既製のCRMではなく「自分専用」を作ろうと思ったのか

1-1. 高機能CRM（Salesforce等）を知る社内SEだから感じた小規模事業の課題

私は本業として、社内SEを務めています。自社で導入している高機能なCRMを、日々運用・管理する立場です。

顧客対応の履歴が一元管理され、案件の進捗がひと目でわかり、必要なデータがワンクリックで取り出せる。そうした便利さが、営業やサポートの現場をどれだけ楽にするかを、日々の運用の中で実感しています。

1-2. だからこそ感じた「個人事業主・小規模事業者には手が届きにくい」という違和感

その一方で、ずっと引っかかっていたことがありました。そうした便利さは、ある程度の規模の企業だからこそ手が届くものだ、という現実です。

高機能なCRMには、相応の月額費用がかかります。一人、あるいは数人で事業を回している個人事業主にとって、それは決して小さな金額ではありません。

「便利さを一番必要としているのは、実は少人数で戦っている事業者の方なのでは」。そんな違和感が、頭の片隅にずっと残っていました。

1-3. 「もし自分が少人数で事業をしていたら」を想像した、”お試し”開発のきっかけ

もし自分が、たった一人でPC・ネットワーク・OA機器のサポート業を営んでいたら。顧客情報も、対応履歴も、機器の保証期限も、きっとExcelか紙で管理することになるはずです。そして事業が軌道に乗るほど、その管理はどこかで限界を迎えます。

そこで思いついたのが、「AIに頼めば、そのギャップを埋められるのではないか」という発想でした。

高機能な既製CRMほどの規模は要りません。必要なのは、顧客管理・案件対応履歴・機器資産管理・契約期限管理という、サポート業に絞った最小限の機能です。そこで、プログラム開発に優れると評価されているClaude Codeに開発を依頼してみることにしました。

1-4. 想像を超える完成度で、正直かなり驚いた

結果から言うと、この実験成果は想像を大きく超える完成度で返ってきました。その驚きについては、実際のプロセスを紹介したあと、7章で改めてお話しします。まずは、AIに何をどう伝えたのか、発案の段階から見ていきます。

2. AIに何を伝えたか : 発案・要件ヒアリングのリアル

2-1. 最初に聞かれたこと(管理したい情報・権限・ホスティング環境・通知機能)

最初にやったことは、手間のかかる要件定義書を書くことではありません。「こういうCRMを作ってほしい」というシンプルな依頼文、想定した事業者になりきって答えた、簡単な箇条書きだけでした。

PC・ネットワーク・OA機器のサポート業務向けCRMを作ってください。エックスサーバー(スタンダードプラン)にデプロイする前提です。

最初のプロンプトはたったこれだけ。

システム開発の緻密さを知る開発職の方からすると、雑を通り越し過ぎて唖然とするしかない「完璧な素人のお願いごと」です。

でも大丈夫、最初から細かい指示は必要ありません。AIも非常に賢くなったもので、目的に対し情報が不足すると、しっかり質問で確認し引き出してくれるのです。

Claudeに伝えたのは、「PC・ネットワーク・OA機器のサポート業務向けCRMを、Xserverのスタンダードプランにデプロイする前提で作ってほしい」という、一文です。

すると、本格的な設計に入る前に、いくつかの質問が返ってきました。

管理したい情報は何か。

顧客管理・案件と問い合わせの対応履歴・保有機器の資産管理・契約と保守期限の管理、この4つすべてが必要だと答えました。

利用する人数と権限はどうするか。

個人事業なので、管理者(自分)と一般ユーザーの2種類で十分だと伝えました。

ホスティング環境はどうか。ここが一番技術的なな質問でした。

Xserverのスタンダードプランで、SSHのroot権限はなく、cronだけは使えること。FTPで自分が管理者としてアップロードするだけで動くPHPアプリにしてほしいこと。これをそのまま伝えました。

さらに、FileMakerで管理していた既存の顧客データと、テキストファイルで持っている機器情報を取り込みたいこと。保守期限が近づいた機器を、メールで知らせてほしいこと。この2つも、実際の業務でつまずきそうなポイントとして付け加えました。

2-2. 専門用語がわからなくても、対話しながら理解できた

正直に言うと、このやり取りの中に、専門用語がなかったわけではありません。「SSH root権限」「cron」といった言葉は、多少システム関連の知識があれば耳にしたことあるかな？というレベル。

ただ、これらはIT業界の人間なら知っていて当然の言葉ではあっても、完璧に理解している必要はありませんでした。わからない言葉が出てきたら、その都度AIに「それは何か」を聞き返せばいいだけだからです。聞けば、専門用語は平易な言葉に置き換えて説明してくれます。

例えるなら、これは工務店に家を頼むときの会話に近いものでした。「延床30坪でお願いします」くらいの言葉は使っても、構造計算の細かい話まで自分で理解している必要はありません。「家族4人が住めて、在宅ワークができる部屋がほしい」という要望さえ伝われば、専門的な部分はプロ側が業務の言葉から組み立ててくれます。そのような話です。

管理したい情報、使う人数、動かす場所、取り込みたいデータ、欲しい通知。この5つを軸に、わかる範囲の言葉で箇条書きにしただけで、次に出てきたのは具体的なデータベース設計の話でした。

3. AIが示したXserverで動かすための設計方針（DB・フォルダ構成）

3-1. Xserver（root権限なし・PHP/MySQL）の制約をどうクリアしたか

ヒアリングのあと、実装に入る前に、設計方針の説明がありました。ここで効いてきたのが、「SSHのroot権限はなく、cronだけは使える」という、最初に伝えた制約です。

一般的なWebアプリの開発では、サーバーに直接入って環境を構築するのが当たり前です。しかし今回のXserverスタンダードプランでは、それができません。

そこでAIが選んだのは、Composerなどのライブラリもビルドツールも一切使わない、プレーンなPHPだけの構成でした。ログインのセッション管理も、PHPに標準で備わっている仕組みだけで組み立てられています。専門的な環境構築の手順が必要ないので、そのままFTPでアップロードすれば動く状態になります。

唯一「サーバー側で動かす処理」として使ったのが、利用可能だったcronです。保守期限が近づいた機器を毎朝チェックして、メールで知らせる。この定期処理だけを、cronに任せる設計になっていました。

3-2. 「FTPで置くだけで動く」初期セットアップ（setup.php）の工夫

もう一つ印象的だったのが、フォルダの中身をどう分けるか、という工夫です。

crmというフォルダの中には、画面を表示するための入り口となるファイルと、顧客・案件・機器・契約のデータを扱う本体部分、そして設定ファイルやログを置く場所が、それぞれ別のフォルダに分けられていました。

本体部分や設定ファイルのフォルダには、ブラウザから直接アクセスできないよう、鍵をかける設定(.htaccess)も一緒に用意されています。

さらに、URLの仕組みも「配置場所を選ばない」ことを意識してつくられていました。ドメイン直下に置いても、サブフォルダに置いても、設定を変えずにそのまま動く形です。これは、あとから配置場所を変えたくなっても困らないようにするための工夫だと聞いて、なるほどと思いました。

データベースの中身は、顧客企業とその担当者、案件と対応履歴、機器の資産情報、契約と保守期限。この4つのかたまりが、それぞれ「どの顧客のものか」で紐づく形に整理されていました。1件の機器がどの顧客のものか、その機器にどんな契約がついているか。複雑な設定を一つもしていないのに、この紐づけだけで、ヒアリングで伝えた要望はすべてカバーされていました。

驚いたのは、それだけではありません。

たとえば「案件の対応履歴」は、1件の記録として終わらせず、1つの案件に何度でも追記できるタイムライン形式になっていました。サポート業務の現場では、1回の問い合わせに対して電話・訪問・再訪問と、やり取りが何往復もするのが普通です。

そこまでは、ヒアリングで一言も伝えていません。言葉にして伝えたのは「対応履歴を管理したい」という一文だけです。それなのに、「実際の現場では、履歴は一度きりでは終わらないはずだ」という、言葉にしていなかった部分まで汲み取られていました。

伝えた要望の先にある、伝えていなかった要望まで拾われていたことに、率直に驚きました。

4. 実装した主要機能とセキュリティ対策

4-1. 顧客管理・機器管理・保守期限のアラート通知（Cron）

設計方針が固まったあとは、実際に動く画面として形になっていきました。

顧客(会社・担当者)、案件・問い合わせの対応履歴、機器の資産情報、契約と保守期限。この4つそれぞれに、一覧・詳細・登録・編集・削除ができる画面が用意され、管理者と一般ユーザーの2つの権限で使い分けられるようになっていました。

実務想定面でありがたかったのが、既存データの取り込み機能です。FileMakerから書き出したCSVや、機器情報をまとめたテキストファイルを、そのままアップロードするだけで済みます。やることは3ステップだけです。ファイルをアップロードし、どの列を「会社名」「機器名」といった項目に当てはめるかを画面上で選び、プレビューを確認して取り込む。文字コードがUTF-8でもShift-JISでも、区切り文字がカンマでもタブでも、自動で判定してくれるので、ファイルの形式を気にする必要がありません。

もう一つの実務的な機能が、保守期限のアラートメールです。「何日前に知らせてほしいか」を、たとえば「30日前と7日前」のように自分で設定できます。毎日決まった時刻に、cronがその日に該当する機器と契約をチェックし、メールで知らせてくれる仕組みです。同じ通知を二重に送らないよう、送信済みの記録も裏側できちんと管理されていました。

4-2. config.php等の機密情報を守るセキュリティ設計

実装の中で、特に意識していなかったのに配慮されていたのが、セキュリティ面です。

データベースのパスワードなど、接続情報が入るファイルは、ブラウザから直接開けないよう設定されていました。Gitでソースを管理するときも、このファイルだけは含めず、中身が空の雛形だけを共有する形になっています。これにより、コードを見せる相手や配布先が変わっても、パスワードそのものが漏れる心配はありません。

もう一つが、初回のセットアップ専用ページの扱いです。データベースのテーブルを作り、最初の管理者アカウントを登録するためだけの画面が用意されていましたが、「使い終わったら必ず削除してください」という案内が添えられていました。言われた通りに、セットアップが終わったタイミングでこのページを削除しています。

ログイン機能そのものにも、パスワードを暗号化して保存する仕組みや、不正なフォーム送信を防ぐ仕組みが、特に指示していないのに標準で組み込まれていました。

「動けばいい」ではなく、「安全に動き続ける」ところまで見込んで作られている。実装が進むほど、そのことを実感する場面が増えていきました。

5. 運用を自動化する開発環境（GitHub × SSH × rsync）

5-1. setup.php一つでテーブル作成〜管理者アカウント作成まで

実装が終わったら、いよいよXserverに載せる番です。

まず、Xserverのサーバーパネルにある「MySQL設定」で、データベースとユーザーを作成します。ホスト名・データベース名・ユーザー名・パスワードの4つを控えておきます。

次に、FTPソフトを使って、フォルダの中身をpublic_html以下にアップロードします。そのあと、あらかじめ用意されていた設定ファイルの雛形をコピーして、控えておいた4つの接続情報を書き込み、再度アップロードし直しました。

ここまで終えたら、ブラウザでセットアップ専用のページを開くだけです。「テーブルを作成する」というボタンを押すと、データベースの中身が自動で組み上がります。続けて、氏名・メールアドレス・パスワードを入力する画面が表示され、それを入力すれば管理者アカウントの完成です。

データベースの中を手作業で触ることも、コマンドを打つことも、一度もありませんでした。ボタンを2〜3回押しただけで、システムの土台が整った形です。

セットアップが終わったら、このページはFTPで削除しました。「使い終わったら必ず削除してください」という案内どおりに動いただけですが、こうした注意点まで前もって示されていたのは、正直ありがたいところでした。

5-2. 動作確認までに確認しておいたポイント

実際のところ、今回はデプロイでも動作確認でも、大きなトラブルはありませんでした。それは運が良かったからというより、事前に用意されていた導入マニュアルに沿って、一つずつ確認しながら進めたからだと思います。

たとえば、XserverのPHPバージョンです。サーバーパネルの「PHP Ver.切替」で、8.1以上になっているかを先に確認しました。マニュアルには「バージョンが古いと真っ白な画面になることがある」と書かれており、最初に見ておくべき項目だとわかりました。

データベースの接続情報も、1文字でも間違えるとエラーになる部分です。ホスト名・データベース名・ユーザー名・パスワードを、控えたメモと見比べながら、慎重に貼り付けました。

保守期限アラートのcronについても、実際に設置したフォルダのパスを、コマンドの中にそのまま書き込む必要があります。どこに何を置いたかさえ把握していれば迷う部分ではありませんが、パスを一つ間違えるだけで動かなくなる場所でもあるため、ここも指示された通りに落ち着いて確認しました。

最後に、ログイン画面から実際にログインし、テストの顧客データを1件登録してみます。登録した内容がそのまま画面に表示されたのを見て、ここでようやく「本当に動いている」という実感が持てました。

6. 運用を自動化する開発環境（GitHub × SSH × rsync）

6-1. 「作って終わり」にしないためのバージョン管理（GitHub）

動作確認が終わったところで、次に考えたのは「これから先、どう育てていくか」でした。

システムは、作って終わりではありません。機能を直したり、新しい要望に応じて手を加えたりする場面は、必ずこの先に出てきます。そのたびに「どこを、いつ、どう変えたか」がわからなくなるのは、避けたいところでした。

そこで選んだのが、GitHubでのバージョン管理です。ちょうどGitHubの新しいアカウントを作ったばかりで、axlという名前のリポジトリとブランチだけが用意されている状態でした。このリポジトリに、手元のコードをそのまま載せる形で管理を始めました。

一つだけ気をつけたのが、データベースのパスワードが書かれた設定ファイルです。このファイルだけはバージョン管理の対象から外し、中身が空の雛形だけを一緒に管理する形にしました。パスワードが記録され続けてしまう事態を、最初の段階で防いだ形です。

最初のコミットをGitHubへ送る場面では、認証のところで一度立ち止まりました。このやり取りをしているパソコンには、GitHubへの認証情報が何も設定されていなかったからです。パスワードやアクセス用のトークンは、AI側が代わりに入力することはできません。そこは自分の手で、認証用のトークンを発行して設定しました。

6-2. ローカルからコマンド一発でXserverへ本番反映する仕組み

GitHubでの管理ができたところで、次に伝えたのが「Xserverへの反映も、ここでの指示だけで完結させたい」という要望です。

まず確認したのが、XserverでSSH接続が使えるかどうかでした。契約しているスタンダードプランでSSHが有効になっていたので、この方式で進めることになりました。

デプロイ専用の鍵を新しく作り、その公開鍵をXserverのサーバーパネルに登録します。ホスト名やユーザー名、設置しているフォルダの場所といった接続情報を伝えると、SSHでの接続が確認できました。(これらの具体的な値は、セキュリティ上の理由からこの記事では伏せています)

その上で用意されたのが、rsyncという仕組みを使った、1本のデプロイ用スクリプトです。このスクリプトにも、config.phpと同じ考え方で「触ってはいけない場所」が組み込まれていました。データベースの接続情報、ログ、取り込み中の一時ファイル。これらはサーバー側の状態を優先し、上書きも削除もしないよう、あらかじめ除外されています。

使い方はとてもシンプルです。何もつけずに実行すれば、実際には転送せず、変更点だけを表示してくれる「ドライラン」になります。中身を確認し、問題なければ、あとから同じコマンドに「反映する」という指示を付け足すだけです。

これで、コードを直す指示を出してから、GitHubに記録を残し、Xserver上の本番環境に反映するところまで。すべてを、この会話のやり取りだけで完結できる状態が整いました。

7. Claude Codeでの自作開発を通じて分かった知見と限界

7-1. Claudeのコーディング能力は、事前の期待値をはるかに超えていた

一通り作り終えたいま、率直な感想を書きます。Claudeのコーディング能力が高いことは、社内SEとして仕事をする中で、前提知識として知っていました。

それでも、実際に自分の業務システムを一から作らせてみると、その期待値をはるかに超えてきました。DB設計、Xserverの制約への対応、セキュリティ面の配慮まで、いちいち指示していない部分に、何度も驚かされたからです。

知識として知っていることと、実際に自分ごととして体験することの間には、大きな差があります。今回、その差を思い知らされた形になりました。

7-2. プロンプトは、正直「雑」だった――それでもここまで動いた

ここで強調しておきたいのは、こちらが出した指示の中身です。

2章で書いた通り、伝えたのは業務要件を箇条書きにした程度のものでした。正直に言えば、決して細やかで漏れのない指示ではなく、はっきり言って雑なプロンプトです。

にもかかわらず、案件の対応履歴をタイムライン形式にするといった、言葉にしていなかった部分まで汲み取られていました。雑な指示の裏にある「本当はこうしたいはずだ」という意図まで、拾われていた印象です。

丁寧な設計書を書く技術がなくても、ここまでのものができる。これは、今回の一番大きな発見でした。

7-3. イメージと言語化さえ手を抜かなければ、非エンジニアの”救世主”になり得ると本気で思った

ここまでの体験を踏まえて、本気でそう思ったことがあります。これは、非エンジニアとして働くすべての人にとって、救世主になり得る技術だということです。

必要なのは、プログラミングの知識でも、設計書を書く技術でもありません。「自分の仕事で何に困っていて、何があれば楽になるか」というイメージと、それを自分の言葉にする最低限の作業だけです。

このイメージと言語化さえ頑張れば、あとはAIが形にしてくれます。特殊技能ではなく、誰もが持つ能力だけあれば良い。専門知識という壁が、とんでもない水準で低くなった。そう実感した出来事でした。

7-4. AIに任せた部分・自分で判断した部分の線引き

一方で、すべてをAIに委ねたわけではありません。振り返ると、任せた部分と、自分で判断した部分には、はっきりした線引きがありました。

任せたのは、データベース設計の細部、実際のコードの実装、セキュリティ面の実装、デプロイスクリプトの中身といった、技術的な組み立てそのものです。ここは、専門知識がなくても任せて問題ない領域でした。

一方で、自分の手で判断・実行したことも、いくつかあります。

「何を管理したいか」という業務要件そのものを言葉にすること。GitHubやXserverへの認証情報を発行し、設定すること。リポジトリの構成をどうするか、SSHを使うかどうかを決めること。

こうした判断や、パスワード・トークンといった認証情報の入力は、AI側が代わりに行うことはできません。ここだけは、最後まで自分の役目として残っていました。

7-5. どんな人に向いていそうか

最後に、同じことをやってみたい人に向けて、率直な感触を書いておきます。

向いているのは、自分の業務の実情を、自分の言葉で説明できる人。わからない専門用語が出てきたときに、その場で聞き返したり、調べたりする根気があれば、なお心強いと思います。

逆に、少し時間がかかりそうなのは、「何を管理したいか」自体がまだ曖昧な人です。

AIは、伝えられた要望の先にある意図までは汲み取ってくれますが、要望そのものがなければ、汲み取る土台がありません。その場合は、ヒアリングに入る前に、自分の業務を一度棚卸ししてみることから始めるのがよさそうです。

まとめ:同じことをやりたい人が、最初にAIへ伝えるべきこと

ここまで、発案から設計、実装、Xserverへのデプロイ、そしてGitHubを使った継続運用の仕組みまでを見てきました。

振り返ってみると、最初にやったことは、たった一つです。自分の業務を、箇条書きにして伝えただけでした。

このとき伝えた項目は、次の5つです。

• 管理したい情報は何か(顧客・案件・機器・契約など)
• 使う人数と、必要な権限の種類
• どこで動かすか(契約しているサーバーの環境)
• 取り込みたい既存データがあるか
• 欲しい通知はあるか

これから同じことを試してみたい方は、まずこの5つを、自分の言葉で書き出してみてください。

完璧な文章である必要はありません。イメージと言語化さえ手を抜かなければ、あとはAIが形にしてくれます。

専門知識がないことは、もう理由にならない時代に入っている。今回の経験を通して、そのことを実感しています。