古いPHP5の日報をClaude Codeで作り替え本番保守まで続けた記録

私が経営する理美容室では、各店のスタッフが日々の売上や実績を日報システムへ入力しています。税理士も証憑を閲覧します。そのシステムは2000年代に外注で作ったものです。中身は PHP5.5、古いフレームワーク、グラフは Flash。スマホ非対応で、HTTPS にも対応していませんでした。保守できる人がいなくなっていた、というのが出発点です。

私は非エンジニアで、プログラミングの経験はありません。それでも計画書を書いてから Claude Code と対話し、実装と検証を繰り返し、並行稼働を経て本番へ切り替え、切替後の保守も自分で回しています。この記事は、当社の場合にやったこと、日付が分かっている期間、つまずき、やらなかったことを書きます。同じ手順が他社でも通るかは、環境が違うのでここでは判断しません。

作り替え前の日報システム

問題は「古い」ことそのものより、保守できる人がいなくなっていたことです。動かなくなったときに直せる人が社内にいない。私はエンジニアではないので、ソースを自分で読んで直すこともできませんでした。一方で日報は毎日使います。各店のスタッフが入力し、税理士が証憑を見ます。止めるわけにはいきません。

だから「新しい画面を一気に本番へ載せる」のではなく、計画書を書いてから作り、旧を正として並行稼働し、数字が合ってから切り替える、という順にしました。本番で動いていると言える状態になるまで旧を捨てない。これが前提でした。

計画書を書いてから実装する進め方

作り替えは、経営者本人の私が Claude Code と対話しながら進めました。順は計画書、実装、検証です。先に動く画面を量産するのではなく、何を残し、何を今の環境に合わせるかを計画書に書いてから実装に入りました。

新しい構成は PHP 8、SQLite、Chart.js です。画面はレスポンシブにし、通信は HTTPS にしました。グラフは Flash をやめ、Chart.js に置き換えています。私はプログラミング経験ゼロなので、コードの意味を一行ずつ自分で設計したわけではありません。対話の中で計画書の範囲を実装させ、動きを確認し、ずれたら計画書と突き合わせて直す、という回り方です。

手軽だったとは言いません。ただ、計画書が先にあったおかげで、実装の途中で目的を見失うことは少なかったと感じています。

並行稼働から本番切替までの日程

日付が残っている範囲だけ書きます。

2026年7月9日、並行稼働を開始しました。この時点では旧システムが正で、新システムはお試し入力です。スタッフは旧へ正式な日報を入れつつ、新でも入力して画面と数字を見ます。新だけを正にすると、ずれに気づく基準が消える、という判断です。

2026年7月23日、総点検を行い、19件を修正しました。並行稼働のあいだに出てきたずれです。19件の内訳は書けません。本番前に点検して直した、という事実だけが残っています。

2026年8月1日、新システムへ本番切替しました。並行稼働の開始から本番切替まで、日付の上では23日です。

かかった時間も書いておきます（コミット時刻を集計した当社の概算です）。最初の作り込みは、7月8日の夜に旧システムから全データを吸い出すところから始め、翌9日の昼に新システムを本番URLで動かし、同じ日の午後にはスタッフが試しに日報を入れ、夜に「当面は旧が正」と運用方針を決めるまで、ほぼ一続きでした。その後、7月10日から8月23日までの修正と改修は14日間で、作業セッションの合計はおよそ26時間です。作業した日は初日を含めて16日。まとまった時間を確保したのは最初の一晩と翌日だけで、残りは1日1〜3時間の積み重ねです。

2026年8月19日、入力画面のバリデーション改善を本番へ反映しました。切替で終わりではなく、入力の段階で誤りを止める改修が、切替から18日後にも入っています。旧システムは捨てていません。アーカイブとして残置しています。切替直後に旧を消す判断は、していません。

データ移行と売上合計の検算

旧システムから、日報 約29,000日分、スタイリスト別実績 約85,000件、経費、目標を吸い出し、SQLite に載せました。件数は概数です。

切替の前に、売上合計が旧システムの会計表と一致することを検証しました。画面の見た目が新しいことより、会計表の合計が旧と同じであることを、切替の条件にしました。一致を確認してから本番へ移しています。「見た感じ合っている」で済ませず、旧の会計表を基準に合計を合わせました。

本番で使っている機能

本番で動かしている機能は次のとおりです。ログイン。本日の各店売上と入力状況。日報入力（売上、時間帯別、年代別、常連と新規、クーポン、スタッフ別、雑費備品）。月次グリッドと CSV 出力。券売機伝票の撮影から OCR、検算、保存（写真も証憑として保存）。経費領収書の撮影から OCR、勘定科目との突合（税理士も閲覧と修正ができる）。変更ログ（誰が、いつ、何から何へ）。粗利の会計表（画面名は「MQ会計表」）。分析グラフ。店舗と従業員のマスター。目標入力。

粗利の会計表は、売上から変動費を引いて粗利、粗利から固定費を引いて利益、という旧算式を移植したものです。画面では西順一郎氏の戦略会計の呼び方で「MQ会計表」としています。新しい経営指標に作り替えたのではありません。現場が使ってきた計算を、今の環境へ移した、という位置づけです。算式を見直す判断は、この作り替えではしていません。

券売機伝票と経費領収書は、撮影して OCR し、数字を検算してから保存します。写真は証憑として残します。税理士が証憑を閲覧し、修正できる点は、日報を店舗の入力だけで閉じないための仕様です。変更ログは、誰が、いつ、何から何へ変えたかを残します。後から数字の変化を追えるようにするためです。

セキュリティは、HTTPS（TLS1.3）と HSTS、パスワードの bcrypt、CSRF トークン、総当たり対策、クエリはプリペアドステートメント、データベースは公開領域の外、WAF を入れています。サーバー名やパスは書きません。

利用者は、各店のスタッフ（日々の入力）と、税理士（証憑の閲覧）です。

本番の画面です。店名と数値は伏せています。

券売機と領収書をOCRにした理由。店ごとに毎日締めたい

作り替えで一番やりたかったのは、店舗ごとに毎日、売上・経費・粗利を締めて見ることです。月末にまとめて数字を知っても、その月にはもう手が打てません。4店舗のどこが、どの日に、何で落ちたのかを翌日に見たい。これが出発点でした。

障害は私自身でした。券売機の伝票も経費の領収書も、一度私の手元に集まってから税理士に渡る流れだったので、私が出張で不在にすると、その間の経理がまるごと止まります。税理士は資料が届かなければ動けず、日次で締めるどころか月次も遅れる。ボトルネックは経営者本人、という状態です。

そこで、現場が伝票と領収書をその場で撮影し、OCRで読み取って検算し、写真を証憑として保存する形にしました。税理士はその画面を直接見て、勘定科目の突合だけでなく、金額・日付・店名・伝票の売上まで修正できます。誤りの訂正まで私を経由していては、在席依存を外した意味がないからです。担保として、誰が・いつ・何から何へ変えたかを変更ログに残しています。私を経路から外した、というのがこの機能の本質です。

数字の組み立ては単純です。売上は券売機の伝票から、変動費は日報の入力から、固定費は領収書の積み上げから、それぞれ毎日入ります。売上から変動費を引けば粗利、粗利から固定費を引けば利益。領収書で上がってくる費用はすべて固定費として扱うので、3つの材料が毎日揃った時点で、店ごとの日次決算は成立します。私が不在でも、この3つが止まらなくなったことが、作り替えの成果です。

総点検と、やらなかったこと

つまずきで日付と件数が残っているのは、2026年7月23日の総点検で19件修正したことです。並行稼働中に見つかったずれを、本番前に直しています。

切替後の事実としては、2026年8月19日に入力画面のバリデーションを本番反映したことがあります。切替時点では、入力の止め方がまだ足りない箇所があった、ということです。当社の場合、本番切替は終わりではなく、入力品質の改修が続いています。

やらなかったことも、事実として書ける範囲に限ります。会計の算式は新しく設計せず、旧算式を粗利の会計表へ移植しました。旧システムは切替後に破棄せず、アーカイブとして残置しました。一気に旧を止めて新だけにする判断は、7月9日の時点ではしていません。正は旧のまま、新はお試し入力から入っています。

プログラミング経験ゼロの私が、フレームワークの自作や、インフラの細部を一人で設計した、という話ではありません。計画書の範囲を Claude Code と対話しながら実装し、検証してから切替した、というのが当社の場合です。

切替後も続く保守

本番切替のあとも、機能改善と不具合修正は、経営者本人の私が Claude Code で続けています。保守は「一度出して終わり」ではなく、現に発生し続けています。2026年8月19日のバリデーション改善は、その一例です。入力画面で誤りを先に止める改修を、切替後に本番へ載せています。

この回り方が成立している前提は、計画書と、本番で動いている実物と、並行稼働中に直した19件のような検証です。

保守を私以外の担当者へ渡した、という事実はありません。いまのところ、非エンジニアの経営者が自分で作り替えたあと、自分で保守も回している、という状態です。

外注していたら、いくらだったか

相見積を取った金額ではありません。公開されている市場相場から、今回やった作業を人月に置き直して積み上げた机上の概算です。実際の見積は要件・業者・地域で大きく変わります。それでも、この数字を置かないと「自分でやる」の意味が伝わらないので、前提ごと書きます。

「0円でできた」と読むと誤ります。ツールの月額は他の業務と共用しているだけで無料ではなく、私自身の時間は現金では出ていきませんが、機会費用としては発生しています。外注には、契約不適合責任、保守の約束、担当者の引き継ぎという、この進め方には無い価値があります。安いから良い、ではありません。保守が私とAIに依存している点は、この記事の弱点として「切替後も続く保守」に書いたとおりです。

それでも差額の意味は大きいと考えています。440万円の見積が来れば、効果が確実だと分かるまで着手できません。サブスクの範囲で済むなら、「その週のうちに動くか」で判断できます。金額の差より、判断の単位が「数百万円の投資」から「今週やるかどうか」に変わったことが、自分で作り替えた一番の効果です。同じサーバーに同居していた会員システムの記録は「ソースも管理者パスワードも無い会員システムを、Claude Codeと一晩で作り直した記録」に書きました。

概算の前提にした公開相場: 発注ラウンジ「人月単価とは？」（進行管理70〜130万円／人月、プログラマー60〜70万円／人月、地方は首都圏より安い）、SIA「受託開発費用相場」（小規模で人月100〜180万円、運用保守は開発費の15〜25%／年）、ITトレンド「システム開発費用の相場」（小規模100〜500万円・1〜3か月、保守は年10〜20%）。リンクの生存は2026年8月22日に確認。概算は当社の一例で、同様の条件で同じ金額になることを保証するものではありません。

自分でやる型と任せたい型

ここまで書いたのは、私が自分の理美容室の日報を、計画書から本番切替、保守まで自分で回した記録です。自分で手を動かしたい経営者には、ai株式会社の「自分でやる型（伴走）」があります。業務システムの作り替えや運用を任せたい場合は、「任せたい型（受託）」として受けます。窓口は ai株式会社、実装と保守はグループの株式会社GlobalBが担当します。内容に応じた個別見積です。まずは「無料で相談する」からで構いません。

よくある質問

プログラミング経験は必要でしたか

私は非エンジニアで、プログラミング経験はゼロでした。当社の場合は、計画書を書いてから Claude Code と対話し、実装と検証を繰り返しました。経験ゼロでも当社では本番まで到達しました。ただ、他の会社でも同じになるとは限りません。

本番切替まで何日かかりましたか

並行稼働の開始は2026年7月9日、本番切替は2026年8月1日で、この区間は23日です。最初の作り込みは7月8日夜から9日夜までのほぼ一続きの作業で、その後の修正・改修は8月23日までに14日・合計およそ26時間（コミット時刻の集計による当社の概算）です。総点検は7月23日、切替後のバリデーション改善は8月19日です。

データ移行で何を確認しましたか

日報 約29,000日分、スタイリスト別実績 約85,000件、経費、目標を旧から吸い出して SQLite 化しました。切替前に、売上合計が旧システムの会計表と一致することを検証しています。一致を確認してから本番へ移しました。

切替後の保守は誰がしていますか

切替後も、機能改善と不具合修正は経営者本人の私が Claude Code で続けています。2026年8月19日の入力画面バリデーション改善も、その保守の中で本番反映しています。税理士は証憑の閲覧と修正ができます。日々の入力は各店のスタッフです。

まとめ

• 2000年代の日報（PHP5.5・Flashグラフ、スマホ非対応、HTTPS非対応）を、保守できる人がいない状態から作り替えた。
• 非エンジニアの私が、計画書→実装→検証の順で Claude Code と対話し、PHP 8＋SQLite＋Chart.js、レスポンシブ、HTTPS にした。
• 2026年7月9日並行稼働（旧が正）、7月23日総点検で19件修正、8月1日本番切替、8月19日入力バリデーションを本番反映。旧はアーカイブ残置。
• 日報約29,000日分、スタイリスト別実績約85,000件などを移行し、売上合計が旧会計表と一致することを検証してから切り替えた。
• 自分で手を動かす場合は「自分でやる型（伴走）」、作り替えと運用を任せる場合は「任せたい型（受託、実装・保守は株式会社GlobalB）」。入口は無料で相談する。