1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@toriaiapp

# プログラミングのプの字もわからない現場人間が、AI壁打ちだけで鋼材切断SaaSを作ったので、現役エンジニアに設計レビューしてほしい

1
Posted at

はじめまして。
TORIAIという鋼材切断計算アプリを作っている者です。

最初に正直に書きます。

僕はプログラミングのプの字もわかっていません。

JavaScriptもよくわかっていません。
SQLも読めません。
WASMも、RLSも、CSPも、Service Workerも、最初は全部「なにそれ」でした。

それでも、現場で困っていることはわかります。

鋼材を切るとき、

  • どの定尺から切れば無駄が少ないか
  • 端材をどう残すか
  • 残った端材を次の案件で使えるか
  • 作業指示書をどう現場に渡すか
  • 営業所のみんなで同じ残材在庫を見られるか

こういう悩みがあります。

その現場の痛みを、Claude / Codex などのAIに毎日ぶつけ続けました。
わからないことを全部壁打ちしました。
「それは危ない」「それは設計がまずい」「それはテストしろ」と言われながら、気づいたらかなり大きなWebアプリになっていました。

この記事は宣伝というより、現役エンジニアの方に本気でアドバイスをもらいたくて書いています。

厳しめでもいいので、設計、セキュリティ、テスト、公開前に潰すべき点を教えてほしいです。

作ったもの

作ったのは TORIAI という、鋼材の1D切断計画Webアプリです。

ざっくり言うと、以下をやります。

  • 鋼材の切断計算
  • 歩留まり計算
  • 残材在庫管理
  • 重量計算
  • 作業指示書の印刷
  • 営業所内の残材共有
  • PWA / オフライン寄りの動作
  • Supabaseを使ったログイン、共有、権限制御

対象は、H形鋼、Cチャンネル、角パイプ、丸棒、フラットバーなどの長尺材です。

自分は現場側の人間なので、「この操作は現場で使うか」「この紙は作業者に渡せるか」「Excelより楽か」という目線だけはあります。

でも、実装の良し悪しは本当にわかっていません。

なので、AIにかなり頼っています。

技術スタック

現状は、かなり素朴な構成です。

Frontend:
  HTML / CSS / JavaScript

Backend / DB:
  Supabase
  PostgreSQL
  RLS
  RPC
  Edge Function

Calculation:
  JavaScript
  Web Worker
  WebAssembly
  Branch-and-Bound
  DP

Test:
  Jest
  Playwright

Hosting:
  GitHub Pages

フレームワークは使っていません。
ReactもVueもNext.jsも入れていません。

理由は、僕がわからないからです。
あと、最初はGitHub Pagesで無料で動くことを優先しました。

「素のHTML/CSS/JSでどこまで行けるか」みたいな形になっています。

リポジトリ構成

現状の主なフォルダはこうなっています。

toriai/
├─ index.html
├─ service-worker.js
├─ src/
│  ├─ calculation/
│  ├─ data/steel/
│  ├─ features/
│  ├─ services/
│  ├─ storage/
│  ├─ styles/
│  ├─ ui/
│  └─ wasm/
├─ supabase/
│  ├─ migrations/
│  └─ functions/
├─ tests/
├─ docs/
├─ agents/
├─ benchmark/
├─ scripts/
├─ wasm/
└─ tools/

それぞれの役割はこんな感じです。

フォルダ 役割
src/features/ 画面に出る機能。計算、印刷、在庫、共有ログインなど
src/calculation/ 切断計算エンジン。歩留まり、重量、WASM連携
src/data/steel/ H形鋼、角パイプ、丸棒などの鋼材マスター
src/services/ Supabase、Storage、監視など
src/storage/ LocalStorageやrepository層
src/styles/ CSS
src/ui/ 横断UI部品
supabase/migrations/ DBテーブル、RLS、RPC、共有機能のSQL
tests/ Jest / Playwright / 共有機能テスト
docs/ 設計、戦略、競合分析、失敗ログ
agents/ AIチームの役割、TODO、日記
benchmark/ 計算エンジンの検証
wasm/ C++/WASM側のソルバー

素人ながら思うのは、もう「小さいWebページ」ではなくなってきたということです。

だからこそ、ここで人間のエンジニアに見てもらいたいです。

今できていること

現時点で、動いているものはこのあたりです。

1. 鋼材の切断計算

入力した部材長と本数から、どの定尺を何本使うかを計算します。

内部では、

  • Branch-and-Bound
  • Web Worker
  • WASM
  • K=1 fast path
  • 複数定尺の比較

などを使っています。

正直、僕はこのへんのアルゴリズムを説明できません。

ただ、現場目線では、

  • 遅すぎると使えない
  • 歩留まりが悪いと使われない
  • 端材の扱いが変だとすぐバレる

ので、AIとかなりやり取りしました。

今のところ、典型データでは歩留まり97-98%くらいを狙っています。

2. 鋼材マスター

src/data/steel/ に鋼材データを持っています。

例:

  • H形鋼
  • I形鋼
  • チャンネル
  • C形鋼
  • 等辺山形鋼
  • 不等辺山形鋼
  • 角パイプ
  • 丸パイプ
  • 丸棒
  • 角棒
  • フラットバー
  • BCR295

海外の汎用切断ツールではなく、日本の鋼材現場に寄せたいので、ここはかなり大事だと思っています。

3. 残材在庫

切断後に出た端材を残材として管理できます。

現場では、端材がどこかにあるのに使われず、また新品の定尺を切ってしまうことがあります。
それを減らしたいです。

今後は「この案件ならこの残材が使えます」という自動提案を入れたいです。

4. 作業指示書の印刷

計算結果を作業指示書として印刷できます。

内容は、

  • 顧客名
  • 現場名
  • 納期
  • メモ
  • 切断リスト
  • 端材
  • 切断図
  • ページ番号

などです。

Webアプリでも、現場ではまだ紙が必要です。
ここを無視すると使われない気がしています。

5. 営業所共有

Supabaseを使って、営業所内で残材在庫を共有する機能を作っています。

ざっくり構成は、

  • organization
  • branch
  • org member
  • branch member
  • invitation
  • org remnant

みたいな感じです。

owner / member の権限を分け、招待コードやPINもあります。

ここは本当に怖いです。
セキュリティ的に見てほしいです。

AIチーム運用をしています

変な話ですが、僕はひとりで作っているのに、リポジトリの中にはAIチームがあります。

agents/
├─ Claude/
├─ Codex/
├─ Gemini/
├─ Ollama/
└─ scripts/

それぞれに、

  • ROLE
  • TODO
  • DIARY
  • output

があります。

さらに、AI同士の掲示板もあります。

Claudeは設計と実装。
Codexはレビュー、DB、リファクタ。
Geminiは戦略や文章。
途中から役割が変わったり、脱退扱いになったりもしています。

僕はコードを書けません。
だから、AIに役割を分けて、議論させて、レビューさせて、失敗を日記に残す運用にしました。

これは効いている気がします。

ただ、これ自体もエンジニアから見ると変な運用かもしれません。
このへんも見てほしいです。

やらかしたこと

当然、かなりやらかしています。

1. auth UIを壊した

ログイン周りで、location.reload() のループや auth listener の増殖が起きました。
一時期、UIが消えたりチカチカしたりしました。

この反省から、

  • auth listenerを増やさない
  • 同じHTMLを無駄に再描画しない
  • reloadで解決しない
  • boot guardを入れる

みたいなルールができました。

2. 右パネルで迷走した

右側の設定パネルを直すだけで、何度も試行錯誤しました。
CSSの上書きが増えて、かなり苦しくなりました。

そこから「設計前に連続実装しない」「モックを作ってから進める」という教訓ができました。

3. SQLのambiguityに何度も引っかかった

PostgreSQLの関数で、戻り値の列名と内部の列名がぶつかる問題に何度も当たりました。

branch_id とか org_id とかです。

AIに言われて、テーブルaliasを必ず付ける方針になりました。

4. 共有機能は想像より難しかった

「みんなで同じ残材を見る」だけなら簡単そうに見えました。

でも実際には、

  • 誰が見ていいのか
  • 誰が削除していいのか
  • 招待コードの有効期限
  • PIN再ログイン
  • 退会済みユーザー
  • 匿名ユーザー
  • RLS
  • RPC
  • audit log

などが出てきました。

見た目より、共有機能はずっと怖いです。

テストは一応あります

素人がAIに作らせると、「動いている気がするだけ」が一番怖いと思っています。

なので、テストはかなり意識しています。

現状は、

  • Jest
  • Playwright smoke
  • sharing test
  • calc test
  • storage test
  • D9 backup reminder test
  • Phase 1.7 test plan

があります。

package.json 的には、

{
  "scripts": {
    "test": "jest --runInBand",
    "smoke": "playwright test --config=playwright.config.cjs"
  }
}

です。

ただし、テスト設計が良いのかはわかっていません。

特に、

  • DB / RLS のテスト
  • auth周りのE2E
  • mobile smoke
  • worker / wasm bundleの一致確認
  • LocalStorage破損時の復帰

は、人間に見てもらいたいです。

セキュリティで気にしていること

素人なりに怖いと思っている点です。

1. Supabase anon key

anon keyは公開前提と理解しています。
なので、RLSとRPCで守る方針です。

ただ、本当に守れているか自信がありません。

2. SECURITY DEFINER RPC

write系はRPCに寄せています。
SECURITY DEFINER を使っています。

search_path 固定や入力validationはAIにかなり言われました。

ここは特にレビューしてほしいです。

3. 招待コード

招待コード、PIN、営業所参加の流れがあります。

気にしているのは、

  • 推測されないか
  • 使い回しされないか
  • 退会済みユーザーが復活しないか
  • owner権限を奪えないか
  • 他営業所の残材を見られないか

です。

4. XSS

作業指示書の印刷で、顧客名や現場名をHTMLに入れています。

一応escape処理は入れています。
ただ、全部の innerHTML を完全に見切れている自信はありません。

現時点で自分が不安なところ

ここが一番アドバイスほしいです。

1. 素のHTML/CSS/JSでこの規模を続けてよいのか

今はフレームワークなしです。

理由は、僕がわからないから。
あと、GitHub Pagesで簡単に動かしたかったから。

でも、機能が増えてきて、

  • scriptの読み込み順
  • グローバル関数
  • namespace
  • inline handler
  • CSSの肥大化

が怖くなってきました。

このまま行くべきなのか、どこかで段階的に整理すべきなのか知りたいです。

2. Supabase設計がB2B SaaSとして耐えられるのか

RLS / RPC / audit log / invitations などを作りました。

でも、業務データを扱う以上、権限境界が一番怖いです。

「この設計思想は危ない」「このテストを入れろ」みたいな助言がほしいです。

3. 計算エンジンの正しさをどう担保するか

歩留まり計算は現場価値の中心です。

でも、経路が増えています。

  • 通常path
  • worker path
  • wasm path
  • K=1 fast path
  • remnantありpath

このへんで結果がズレると怖いです。

どういう回帰テストを組むべきか知りたいです。

4. AIに書かせたコードをどうレビューすべきか

僕はコードが読めません。

なので、

  • AIに書かせる
  • 別AIにレビューさせる
  • テストする
  • 実機で触る
  • 日記に残す

という運用をしています。

でも、人間レビューなしでどこまで行けるのか不安です。

5. 公開前に最低限やるべきこと

現状、外に出す前に、

  • セキュリティ
  • バックアップ
  • 利用規約
  • 免責
  • 問い合わせ導線
  • 監視
  • テスト

は見ています。

それでも、抜けているものがある気がします。

できればレビューしてほしい観点

もしコメントいただけるなら、以下の観点がほしいです。

アーキテクチャ

  • 素のJSでこのまま続けるべきか
  • どのタイミングでbundlerやframeworkを考えるべきか
  • global namespace運用で最低限守るべきこと
  • script読み込み順に依存する構成の整理方法

セキュリティ

  • Supabase RLS設計で見るべきポイント
  • SECURITY DEFINER RPCの地雷
  • 招待コード / PIN設計の注意点
  • innerHTML とXSS対策
  • CSPで最低限見るべきところ

テスト

  • SaaS公開前に最低限必要なE2E
  • DB/RLSのテスト方法
  • 計算エンジンの回帰テスト設計
  • mobile smokeで見るべきこと
  • AI生成コードに対するレビュー手順

プロダクト

  • 業務SaaSとして最初に削るべき機能
  • 逆に最初から絶対必要な機能
  • Excelから移行してもらう時に必要な導線
  • 無料版 / トライアルの設計

個人開発運用

  • AIチーム運用のよいところ、危ないところ
  • 日記 / 掲示板 / TODO をどう整理すべきか
  • ひとりでB2B SaaSをやる時の地雷

今後やりたいこと

優先度高めで考えているのは、このあたりです。

  1. CSV / Excel一括インポート
  2. 残材の自動提案
  3. 初回チュートリアル
  4. 無料プランかトライアル
  5. QR / バーコードラベル印刷
  6. 重量ベースの在庫管理
  7. 利用統計ダッシュボード
  8. 在庫アラート

特に、CSV / Excelインポートは早く入れたいです。

現場はすでにExcelを使っています。
「今のExcelを捨ててください」ではなく、「今のExcelを取り込めます」と言いたいです。

残材の自動提案も重要だと思っています。

新しい案件を入力した時に、

この残材が使えます

と出せれば、価値が一瞬で伝わる気がします。

この記事でやりたいこと

正直、バズりたい気持ちもあります。

でも、それ以上に、人間のエンジニアに見てほしいです。

AIに壁打ちしまくってここまで来ました。
でも、AIだけだと怖いところがあります。

特にセキュリティ、DB、テスト、公開前の最低ラインは、経験ある人に「そこ危ないよ」と言ってもらいたいです。

僕はド素人です。
変なことをしていると思います。

なので、変なところを教えてください。

「まずこれを直した方がいい」
「その設計は危ない」
「このテストを書け」
「そこは今気にしなくていい」
「B2B SaaSならそれよりこっち」

そういうコメントがほしいです。

最後に

僕は、まだコードが読めません。

でも、現場で困っていることはわかります。

その困りごとをAIにぶつけ続けたら、ここまで来ました。

これが正しい作り方なのかはわかりません。
たぶん、かなり危なっかしいと思います。

でも、AI時代にはこういう「コードは書けないけど、現場の課題を持っている人間」が、どんどんプロダクトを作り始めると思います。

そのとき、現役エンジニアの知見が必要です。

僕も今まさに、それが必要です。

もしよければ、TORIAIをどう育てるべきか、アドバイスをください。

参考

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?