Rails歴10年の俺が、コードをほぼ見ずに在庫管理システムを納品した

コードをかかないAIエンジニア

2026/03/02

先日納品した在庫管理システム、コード自体はほとんど見てないです。

Rails歴10年以上、一応シニアエンジニアを名乗ってるんですけど、今回の案件でやったことの大半は「コードを書く」じゃなくて「Claude Codeに書かせる」でした。

「それってエンジニアの仕事なの？」と思うかもしれません。

自分でも最初はそう思ってました。でも実際にやってみて分かったのは、コードを書かないことと、エンジニアリングをしないことは全然違うということです。

何を作ったか

クライアントから依頼された在庫管理システムです。

技術スタック: Rails 8 + Hotwire + Docker
デプロイ: VPSにDockerでデプロイ
バックアップ: DBデータのみS3に退避
規模: 中規模のCRUDアプリ（在庫数約10,000種類、入出庫管理、レポート等）

技術スタックは全部自分で選びました。理由はシンプルです。

Railsは10年書いてきた一番の得意分野。AI駆動開発でも、自分が中身を理解できるフレームワークでやるのが安全だと判断しました。

Hotwireは実は今回が初めて。これまではHotwireをオフにして、ReactやVueを別で立てることが多かった。ただ、在庫管理システムにフロントエンドを別管理するのは明らかにオーバースペック。Rails 8に標準バンドルされているHotwireをそのまま使うのが一番合理的でした。

VPS + Dockerは予算の制約から。クライアントはソフトウェア開発を外注するのが初めてで、予算も潤沢ではない。AWSのようなクラウドは月額が読みにくいし、この規模には過剰。定額のVPSにDockerイメージを置いて、

docker compose build && docker compose up -d

で適用する素朴なデプロイです。社内ツールなのでアクセス数も限られていて、瞬断もダウンタイムも許容範囲。DBデータだけS3にバックアップを取って、最低限の安全策は確保してます。

正直、技術的にはそこまで難しくない案件です。似たようなシステムは過去に何度も作ってる。

ただ、今回は開発プロセスが根本的に変わりました。

自分がやったこと / やらなかったこと

やったこと

クライアントとの仕様調整（これが一番時間かかった）
テスト設計（「こういうテストを書いて」とClaude Codeに指示）
mdファイルによるルール定義（N+1防止、命名規則等）
仕様書・契約書の作成（これもClaude Codeと相談しながら）
最終的な動作確認

やらなかったこと

コードを1行1行書くこと
コードレビュー（ほぼしてない）
デバッグの大半（Claude Codeが自分で修正する）

この「やらなかったこと」リストを見て、エンジニアとしてヤバくない？と思った人もいると思います。

でも結果として、品質は問題なく、納期も余裕で間に合い、クライアントからの評価も高かった。

なぜ「コードを見ない」が成立するのか

答えはシンプルです。テストがあるから。

自分がやってるのはこういうフローです：

1. 仕様をmdファイルに書く
2. テスト設計を考える
3. Claude Codeに「この仕様でテストを書いて」と指示
4. テストが通るようにコードを書かせる
5. テストが全部グリーンなら、コード自体は見ない

つまり、テストが仕様の代わりになっている。テストが通っているということは、仕様通りに動いているということ。コードの中身がどうなっていようが、テストが保証してくれる。

これが成り立つのは、自分にテスト設計の経験があるからです。10年Railsを書いてきた中で「どういうテストを書けば品質が担保できるか」が分かってる。だから「テストだけ書かせて、あとは任せる」ができる。

テストなしでAIにコードを書かせると暴走します。これは断言できます。

mdファイルによるAI制御

Claude Codeを使う上で、自分が一番効果を感じてるのがmdファイルによるルール制御です。

例えば、Railsで一番よくあるパフォーマンス問題 ― N+1クエリ。これを防ぐために、プロジェクトのルールファイルにこう書いてます：

## データベースクエリのルール
- ActiveRecordで関連データを取得する場合、必ずincludes/preloadを使うこと
- コントローラーでのクエリは必ずeager loadingを検討すること
- N+1が発生する可能性があるコードを書いた場合、必ず指摘すること

こういうルールをmdファイルに書いておくと、Claude Codeがコードを生成するときに自動的にこのルールに従ってくれる。人間のジュニアエンジニアに「N+1に気をつけて」と言うよりよっぽど確実です。

他にも：

命名規則（変数名、メソッド名のルール）
エラーハンドリングの方針
テストの書き方のルール
コミットメッセージのフォーマット

こういうのを全部mdファイルに書いておく。するとClaude Codeは毎回忠実にそれに従ってくれる。

バックエンドもフロントエンドも速い

バックエンドはマジで速い

Railsのモデル、コントローラー、マイグレーション、テスト ― この辺りはびっくりするほど速いです。自分が書くより確実に速い。しかもRails 8の新しい書き方もちゃんと知ってる。

デバッグも速い。エラーログを貼り付けるだけで、原因特定から修正まで一気にやってくれることが多い。

フロントエンドも速い。ただし条件がある

今回、CSSフレームワークにTailwindCSSを採用しました。これが大正解だった。

TailwindCSSはWebに情報が大量にあるので、AIが学習データとして十分に持っている。だから修正がめちゃくちゃ速い。「この余白を詰めて」「モバイルでは2カラムにして」みたいな指示を出すだけで、一発で正しいクラスを当ててくれる。

CSSは本当に一行も書いてないし、見てもいない。

実は別のプロジェクトで、CSSフレームワークを一切使わず自前でCSSを書いていたことがあります。そのプロジェクトでは、ブラウザでの動作確認が必要になるたびにサイクルが激遅になった。Chrome立ち上げて、画面を見て、「ここが崩れてる」「この動きが違う」みたいなやり取りが入ると、途端にAI駆動開発の速度メリットが消える。

この経験から、AI駆動開発でCSSを自前で書くべきではないと確信しました。AIがよく知っているフレームワークに乗るのが正解。TailwindCSSはその筆頭です。