【AI×社内システム開発 #1】オーナーさまを支える契約・収支のシステムを、AI と一緒に大進化させた半年 | NOT A HOTEL

この記事は、NOTAのテクノロジー連載「Tech Behind the Scenes」です。

こんにちは、中尾(@nakaohiroshi)です。NOTA(旧 NOT A HOTEL)でソフトウェアエンジニアをしています。

気づいたら前の投稿から3年も経っていたんですね。
この年齢にもなると3年なんて、つい2,3日前のことのようです。

最近は老眼に抗いながら(抗えていないけど)、日々画面と向き合っております。
画面はデカければデカいほどいいです。

さて、3年前に「運営システムをゼロから作るハナシ」を書きました。予約機能編も続けて書いています。あのとき担当していた宿泊の運用システムは、いまは後任のメンバーに託しています。

そして最近は、オーナーさまの契約や収支、請求などを管理する社内ツールの開発がメインです。

ちなみに専門はバックエンド(BE)で、前回の記事も「Backend API 担当」として書いています。

そんな BE エンジニアが、この半年は BE に加えて、フロントエンド(FE)もガッツリやることになりました。

このツールを AI(Claude Code)と一緒に開発してきて、特に画面まわりは、気づいたら見違えるほど大きく進化した状態になっていました。

今回はそのハナシを、広がった範囲と、確かめ方の変化を中心に書いてみます。

目次

3年ぶりの note

前回は「ゼロから作る楽しさ」を書きました。今回は逆で「すでにあるものを進化させる楽しさ」です。

ゼロから作るときは、白紙の自由さがあります。進化させるときは、いまの運用や業務を止めないまま、動いているものに手を入れていくという、別の面白さと難しさがあります。

「ゼロから作ったものを、次の人が育てていく」のは、とても健全な形だと思っています。

3年前の note も併せて読んでいただけると。

BE の自分が、FE をガッツリやってみた

正直に言うと、FE は「読めるけど、本職ではない」領域でした。

React のバージョンが上がったり、CSS のフレームワークが変わったりするたびに、遠くから眺めていました。

それが、AI と組んだことで変わりました。

• 画面の設計は、UI/UX デザイナー役の AI が、事例を調べたうえで案を出してくれます

• 実装は、フロントエンド担当の AI が書きます

• 自分は、BE で鍛えた「データの流れ」と「壊れ方」の目でレビューします

たとえば、型チェックを通っているのに、画面ではグラフが空になる。

この手の不具合は、API が返す値の形(数値が文字列で返ってくるなど)を知っていると、すぐ原因の見当がつきます。

BE の経験が、FE のレビューで効くというのは、やってみて初めて分かった発見でした。

もちろん BE の仕事もなくなったわけではありません。このツールでは、要件の整理から API、画面まで、一気通貫で担当しています。

OMT とは？

このツールを、社内では「OMT(Owner Management Tool)」と呼んでいます。使うのは運営側のメンバーです。

なお、前の宿泊の運用システムは「PMS」と呼んでいます。

NOT A HOTEL のオーナーシップは、自社ならではの仕組みなので、管理ツールもそれに合わせて自社で作っています。

扱うのは、収支のレポート、請求、口座振替、オーナーさまの契約や宿泊可能な日数など、お金とルールがからむ領域です。

だからこそ、画面の見やすさや、操作のしやすさが、そのまま業務の正確さにつながります。

半年で何が変わったか(数字で見る)

4月23日と10月24日の時点を、画面側のリポジトリ(ソースコードの src 配下)で比べました。API 側は含みません。

数字を並べますが、伝えたいのは「コードが増えた」ことではありません。確かめながら進められる範囲が、広がったことです。

• ソースファイル数(テストと、部品を見て確かめる Storybook を含む): 148 → 1,469(約10倍)

• うち、テストと Storybook を除いた本体のコード: 148 → 900(約6倍)

• 機能のまとまり(モジュール): 9 → 34

• テストファイル: 0 → 551

• React: 18 → 19

• Tailwind CSS: 3 → 4

元からあった148ファイルの約9割に、改善の手が加わりました。

つまり「ゼロから書き直した」というより、元の骨格を残したまま、テストも含めて10倍に育てた形です。

特に、テストが0から551ファイルになりました。このテストの網があったおかげで、改善を進めやすくなりました。

中身は、Vitest と Testing Library によるテストが中心です。型チェックと ESLint も、CI で毎回回しています。

この量を前にして強く残っている実感は、「速い」より「確かめるものが増えた」ことでした。

BE が専門の自分が、API から画面、テストまで一気通貫で進められたのも、この確かめる仕組みがあったからです。それでもこの規模まで来られたのは、AI のチームのおかげです。書く役と決める人が分かれていて、出す前にはテストと別の AI のレビューを通し、最後は人が確認しているからだと思います。

月ごとに振り返る

半年の動きを、月ごとにざっくり並べてみます。

6月: 土台づくり

ダークモードやコマンドパレットなど、画面の「土台」の整備に本格的に取りかかりました。

7月: 使い心地の統一

サイドバーや検索を拡充し、詳細画面の見せ方を統一しました。診断機能も、段階的に育て始めました。

8月: 定着と磨き込み

お知らせの自動生成が定着し、罫線を薄くするなど、「足す」より「引く」調整に取り組みました。

9月: 業務機能の拡充

オーナー登録まわりの画面や、口座振替の画面を整理しました。

10月: 足元の強化

React 19 と Tailwind CSS 4 への更新、React Compiler(画面の描画を自動で効率化する仕組み)の導入、CI の高速化など、開発そのものの足腰に手を入れました。

振り返ると、「作る」→「揃える」→「磨く」→「足腰を鍛える」と、自然に段階を踏んでいました。

どこを進化させたのか

大きく「土台」と「機能」に分けて、エピソードを紹介します。

土台

ダークモード

色を「トークン」(意味を持った名前の変数)で管理する方式にして、画面側ではライト用とダーク用を書き分けないルールにしました。

新しい画面は、作った瞬間からダークモードに対応します。AI が書くコードにも、このルールを教えてあります。

コマンドパレット(⌘K)

管理ツールは画面数が多く、メニューをたどるのが大変です。そこで、⌘K で画面や顧客に直接飛べるコマンドパレットを入れました。

最初は画面の検索だけでしたが、段階的に育てて、他のツール(PMS)への移動もできるようにしました。

アニメーション

「動き」はふつう、業務ツールでは後回しにされがちです。でも、画面の切り替えやパネルの開閉に自然な動きがあると、今どこで何が起きたかが分かりやすくなります。

基盤を整えて、動きに酔いやすい人のための「動きを減らす設定」にも対応しました。

データの見せ方

財務の画面は、もともと数字の表が中心でした。そこにグラフ(推移やウォーターフォールなど)を足して、数字の背景にある流れが見えるようにしました。

詳細画面にも、小さな推移グラフ(スパークライン)を横展開しています。

共通部品とデザインのルール化

空の状態、絞り込み、金額の表示、項目の一覧など、画面ごとに作られていた部品を、共通部品にまとめました。

そのうえで、ルールを文書に残し、AI 向けの要約版(DESIGN.md)も用意しました。

機能

ピン留めと最近開いたページ

よく使う画面を、サイドバーにピン留めできます。最近開いた画面も、すぐに戻れます。

日々の運用で「あの画面どこだっけ」を減らすための機能です。

運営側のオペレーターは、担当ごとに主に使う機能が決まっています。使う項目にすぐたどり着けるようにしたかったのが、きっかけです。

収支データの CSV 出力と PDF プレビュー

収支のデータを CSV で取り出せるようにし、PDF も画面上で確認できるようにしました。

経理や運営のメンバーが、他のツールに渡す前に中身を確かめられるようになりました。

お知らせの自動生成

新機能をリリースしたとき、このツールの利用者へのお知らせを書くのは地味に手間でした。そこで、リリースをきっかけに、お知らせの下書きが自動で作られる仕組みを作りました。

いまは毎週のように、お知らせが届いています。

診断機能

データが「あるべき形」に揃っているかを確かめる診断機能は、段階的に育ちました。

データが揃っているかの確認から始まり、整合性のチェック、そして、計算根拠まで可視化する機能まで。

たとえば、オーナーさまの収支レポートの数字に、どの予約の利用が計上されているか、といった内訳まで画面で確かめられます。

運営メンバーが、データの状態をすばやく確かめられるようにするのが狙いです。

一覧画面の追加

ハウス(オーナーさまが所有する物件)やガレージ(NOT A GARAGE でオーナーさまが所有する乗り物)の一覧を、画面として新しく作りました。宿泊可能な日数の管理など、運営に必要な範囲で利用状況を確認する画面も、ベータ版として提供しています。

ここまで回せたのは「AI のチーム」を作ったから

Claude Code に全部を任せているわけではなく、役割ごとに AI を分けています。

• PM(何を作るかを整理する)

• UI/UX デザイナー(どう作るかを設計する)

• バックエンド担当

• フロントエンド担当

• QA(確認項目を作る)

• コードレビュー担当

• ドキュメント担当

• 調査担当(他社事例などを調べる)

つまり、ぼくらがかんがえたさいきょうの開発チームを、AI で組んだ形です。(前回の「ぼくらがかんがえたさいきょうのPMS」のオマージュです)

要件の整理から API、画面まで一気通貫で進められたのは、この役割分担のおかげだと思っています。

作った AI にそのままレビューまでさせるのはやめて、別の AI の目でレビューや確認をしてもらいます。

役割の分け方や、各役割の動かし方については、次回以降の記事で詳しく書きます。

失敗を「仕組み」に変えていく

もちろん、うまくいかないこともたくさんありました。そのたびに、同じ失敗が起きないように仕組みに変えてきたので、その一部を紹介します。

• AI の報告は「仮説」として扱う: 「できました」と言われても、実行結果で確かめるまで完了にしません。

• 完了条件を先に決める: 作り始める前に「何ができたら終わりか」を1行で書きます。

• PR(変更の提案)は1つの関心事だけ: 小さく切るほど、レビューも速く、直しやすくなります。

• 自動レビューは2巡で区切る: 細かい指摘を追い続けると終わらないので、実害のあるものだけ直します。

• 作業ごとに作業場所を分ける: 並行で動かしても、お互いの変更が混ざりません。

具体的な失敗例を、1つ紹介します。

送信中は閉じないはずの確認モーダルについて、AI が「外側をクリックしても閉じないことをテストしました。通ってます！」と報告してくれました。でもあとで、閉じないようにしているコードをわざと外してみると、テストは普通に通りました。

見ると、テストが確かめていたのは「モーダルの文字が画面にあるか」だけ。このモーダル、閉じたあとも文字は裏に残っているので、閉じても閉じなくても「ある」んですよね。何をやっても通るテストでした。

それ以来、「閉じない」「出ない」系のテストは、守っているコードを外して、ちゃんと落ちるところまで見てから「できた」にしています。

たとえば CI(自動テストなどの待ち時間)も、測るところから始めて改善しました。

実測してみると、テストが想定より少ない並列度で動いていたことが分かり、設定を見直したところ、確認作業の待ち時間は、1回ずつの比較ですが、3〜4割ほど短くなりました(実行環境の揺れが大きいので、目安です)。

人間の仕事が変わった

この半年で一番変わったのは、自分の仕事の中身です。

• 前: コードを書く

• いま: 何をもって完了とするかを決めて、確かめる

書く量は減りましたが、決める・確かめることの重みは、むしろ増えました。さきほどの「グラフが空になる」ような不具合に気づけるかどうか。腕が試される場所が、コードを書く手から、見る目に移りました。

これから

PMS と OMT で、開発の進め方を揃えていく取り組みも進めています。片方で見つけたよい仕組みを、もう片方にも入れていきます。

PMS を引き継いでくれたメンバーとも、お互いの知見を持ち寄れる関係でいたいと思っています。

今回は全体のハナシでしたが、次回以降は、AI の報告を仮説として扱う習慣、AI のチームの作り方、記憶(ナレッジ)の残し方、画面をもっと使いやすくするための測り方などを、もう少し掘り下げて書いていきます。

技術環境

• フロントエンド: TypeScript / Next.js / React 19 / Tailwind CSS 4 / Ant Design

• バックエンド: Go / gRPC / Protocol Buffers

• インフラ: Google Cloud (Cloud Run、Cloud Spanner、BigQuery ほか)

• テスト: Vitest

• 開発環境: Claude Code / GitHub / Notion / Slack

NOTAでは、一緒に働く仲間を募集しています。気になった方は、ぜひ採用ページものぞいてみてください。

テクノロジー関係中途採用はこちら

採用全般はこちら

カジュアル面談からでもお気軽にどうぞ！