個人開発画像

Harness Engineeringでスマホである程度個人開発できる状態までに整備したこと

2026/03/01

謝罪

2025年末から書きたいと思いつつ放置した結果、次のような変化があり、焦ってブログを書いています。

  • Claude Code Remote Controlがリリース
  • Harness Engineeringという言葉の登場
  • 社内でLinter整備の機運が向上
  • 社内でコードのブラックボックス化の動きをする部署やチームの出現

スピード優先で書いたため、違和感を感じる内容もあると思いますが、ご容赦ください。
タイトルにHarness Engineeringという言葉を入れたのも、正直ちゃんと理解できていないまま少し流行りに乗った部分があります。すみません。

背景

昔から個人開発が大好きで、出先でも時間があればPCを開いて作業することが多かったです。
ただ、出先で暇な時間ができるかもしれないと思うたびにPCを持ち歩く必要があり、正直かなり面倒でした。
「スマホだけで開発できたらいいな」と何度も思っていたのですが、実際にスマホでプログラミングしようとすると個人開発の楽しさよりストレスが上回ってしまい、結局PCを持ち歩く状態に戻っていました。

2025年の初めからAIを使った開発をメインにして1年ほど経ち、ようやくスマホだけでも満足できるくらい個人開発ができるようになりました。
そこで今回は、自分の環境を整理してみます。

結論

今の開発スタイルは、スマホのChatGPTアプリからCodex Cloudにやりたいことを伝えてPRを作ってもらい、タブレットのGitHubアプリでPRを確認してマージする流れです。
（基本ざっと見て即マージですが、どこがAIに荒らされていて、仕組みを作るべきかを把握するため）
ただのVibe Codingじゃんって思われるかもしれませんが、環境整備には結構投資しているので、品質担保ができる仕組みは整えてあります。

ここからは、どんな投資をしているのかを実際の整備内容に沿って記載していきます。

1. Contextの整備

今では当たり前になっていると思いますが、2025年4月ごろに最初にやったのはAgent Ruleの整備でした。
現在、 37ファイル のRulesファイルが存在します。

Agent Rules

  • 個人開発しているTogelloというのはどんなサービスで、どんな人たち向けに作っているプロダクトか
  • どんな所にこだわって作っているか
  • プロダクトのアーキテクチャ構成
  • コーディングルール、命名規則
  • フロントエンドのコンポーネント分割ルールやデザインルール
  • バックエンドのアーキテクチャ構成やファイルごとの責務ルール
  • Hooks / API / Repository / Domainのテストの書き方

などをAgent Rulesファイルとして記載しました。
Agent Rulesを増やしていくことで、出力されるコードがよくなっていく実感はあったのですが、同時にファイル数が増えた際に限界も感じるようになりました。
全てのルールに従ったコードはどうしても出てこず、人間がちゃんと確認して違反しているルールファイルを伝える作業はなくなりませんでした。

2. Linter の整備

そこでたどり着いたのがLinterです。
僕が一番拘っているのはここです。

※2025年8月頃に社内でLinter製造マシーンになったのも、これが理由です

現在、フロントエンドとバックエンドを合わせて、107件のルールがあります。
フロントエンドだと

  • コンポーネントファイル内の定義順を Type -> Component -> Style に揃える
  • JSX のネイティブ <select> を禁止し、DropdownSelect の利用を促す
  • Page コンポーネントでの filter / sort / reduce 呼び出しを禁止する。
  • React Query の import 禁止に加えて、css/styled（@/styled-system/*）の import を禁止する
  • export 関数でオブジェクト引数を扱うとき、args.foo 形式や受け取り後の分割代入を禁止し、引数位置での分割代入を強制する。

バックエンドだと

  • Controller は HTTP メソッドや API パスと整合する命名・配置を強制する
  • Repository は配置先・ファイル名・テストファイル対応の規約を強制、関数は命名・引数順・戻り値・ロック系命名などのシグネチャ規約を強制する
  • Domain / Domain Service は層の責務分離を守り、不適切な依存や引数設計を禁止する
  • SQL や文字列の書き方（const 化、改行表現など）を統一し、揺れを禁止する
  • テストはテーブル駆動を前提に、name / want / prepare / t.Run(tt.name, ...) の基本骨格を強制する
  • t.Run 本文での if / switch / for/range を禁止する
  • got の後処理やテーブルケースのミューテーション（再代入・インデックス代入）を禁止する
  • アサーションは want / wantErr ベースに統一し、assert.NoError や prepare 内 assertion などを禁止する
  • Controller / Repository / QueryService / Domain / Fixture ごとに、レイヤー別のテスト・実装パターンを強制する
  • テーブル内の関数型フィールドを prepare 以外禁止し、prepare 関数内での assertion を禁止する
  • Repositoryでnil, nil を返す関数名に OrNil を必須化し、FOR UPDATE を使う関数名に ForLock を必須化する
  • print 系ログより構造化ログ利用を強制する
  • 生 SQL 文字列/直接実行を禁止し、抽象化利用を促す

のような感じです。
本当にこれは一部のルールです。

Linterでゴリゴリルールを固めると、基本的に意図しないコードが出てくることはほとんどないです。
僕が確認するのは、ドメインの名前が気に入るかどうか、データ保存の情報とライフサイクルが適切かどうかくらいです。
Controller/Application Service / Domain Service / Domain / Repositoryの配置場所、書き方、ファイル名、関数名、内部で使える関数などは決まっているため、AIくんは禁止されている中でパズルを当てはめるように実装するだけです。

テスト実装も強制され、書き方も強制されています。
テスト対象ごとにテーブルテストのプロパティの名前や型まで制限を受けており、書き方や使う関数まで制限を受けています。
なので、僕はテーブルテストのname, prepare, args, want を見れば挙動を把握できるようになっています。
テストファイルやテストごとに書き方の違いはないので、ノイズは極限まで減らされています。

フロントエンドも、コンポーネントファイルではHooks呼び出しとレンダリング以外は禁止されており、Hooksはテストを書くことを強制されているので、挙動を把握できます。

3. IaC化

Google Cloudで管理している機能はTerraformでIaC化していたのですが、AWSのリソースは歴史的な背景もありIaC化できていませんでした。
インフラ構成を把握できていないと、なぜそのアーキテクチャにしたんだ？と思う時もたまにあったので、まずはexportしてコードベースにし、それを要約したファイルを作りました。

これで、適切に本番環境構成を考慮した上で設計をしてくれるようになりました。

4. StorybookとChromaticの本格導入

元々Storybookは導入していたのですが、PCで作業している時はローカルでそのまま検証してしまうことが多かったです。
ローカルで検証している限り、PCから逃れることはできません。

バックエンドのコードは見れば理解できますが、フロントエンドの挙動をコードだけ見て脳みそでデバッグできるほど、僕の脳みそは優秀ではないので、ビジュアルで確認できるようにする必要がありました。

Codex Cloudくんはブラウザを操作してスクショを撮ってくれるので、全てのコンポーネントのStorybookを実装してもらいました。
また、Chromaticを導入することで、コンポーネントレベルで挙動をスマホで動作確認できるようにしました。

5. LLM as a Judge

意図したコードや意図したUIを出せるようにはなりました。
ですが、細かい考慮はLinterだと限界があります。

そこで、CodexレビューとCodeRabbitを導入しました。
Agent Rulesが守れているかの防御はここで防いでもらっています。

6. CloudWatch Logsの強化とLangfuse / New Relicの導入

どれだけ仕組み化をしても、一定数は本番に出してみないとわからないことがあります。
その際に、すぐAIに修正してもらえる仕組みづくりも進めました。

なるべくログ情報は多く出す仕組みにしておき、起きている事象ごとに適切なサービスを見に行き、スクショを撮ってAIに渡せば修正できる状況をつくりました。

Sentryの導入やロールバックの仕組みも整備したいと思いつつ、優先度が低く、時間やコストの問題で後回しにしています。

7. Codex Cloudの環境整備

Codex Cloudは、セキュリティ面を考慮しているからなのか単なる機能不足なのか、Codex CLIでできることが制限されていることが多いです。
制限されている以上、PCのCLI以上のパフォーマンスを出すのは難しいですが、それでもやれることはやりました。

Codex Cloud用のカスタムプロンプトはあるので、そこにCLIだと標準で動いてくれる機能などを自然言語で記載しています。
Codex Cloudはネットワークエラーなどが発生しやすいため、502が発生しても達成できるまで実行してほしい旨や、Skillsの話をされたらSkillsのファイルを読んでほしいことなどを伝えています。
Storybookのスクショも、コンポーネントを開いてから30秒経過してから撮るように伝えています。

他にもTogelloはフロントエンドとバックエンドのリポジトリが分かれており、Codex Cloudではghコマンドなどを実行することを禁止されているため、setup scriptでGitHubのトークンを渡しています。
その上で、worktree配下にお互いのコードをcloneしてくるところまで実装しています。
バックエンドに関してはPostgreSQLもインストールして立ち上げてあります。

バイナリファイルに変更があるとPRを作れないという制約もあるため、bun.lockbからbun.lockに移行もしました。

8. Skillsの整備

Contextの整備と被る部分はあるのですが、Skillsの整備もしています。
Codex Cloudは音声入力ができるため、考えていることをつらつら伝えれば良いというのもあるのですが、いつも音声入力できるとは限りません。

いかに少ないプロンプトで詳細な意図を伝えられるかを重視し、Skillsを大量に作っておいて、Skillsの名前と意図を伝えるだけで適切なコンテキストを渡せるようにしています。

最後に

半年以上、次のループを回してきました。
AIにコードを書かせる → 出力に不満があればフィードバックする → フィードバックと修正結果からAgent Rules / Skills / Linterを整備する → それでも防げない場合は環境に手を加える。
環境を整備することで、品質を落とすことなく、意図を伝えることだけである程度開発できるようになりました。
バックエンドは、PRでAPIのテストコードを軽く見れば意図した通りに実装されたか確認可能です。
フロントエンドは、スクショとStorybookの挙動を軽く見れば意図通り実装されたか確認可能です。

個人開発レベルだから、一定成り立っている面があることも理解しています。
（バックエンド98,000行、フロントエンド58,381行、テーブル数47件、API数141件、画面数29画面なので、それなりの規模ではあります）
それでも、Linterを大量に用意すれば、かなりのコード品質は担保できると個人的には思っています。（コードのブラックボックス化は可能）

もっとStg環境の整備などをしていけば、バックエンドの軽いコードレビューも不要になるとは思うのですが、円安によって本番環境のインフラ環境の値段でも苦しいので、もっと先になりそうです。

AI Native個人開発

Twitterフォロー待ってます！