僕の考えた最強のハーネスエンジニアリング時代のWebアプリケーション技術選定

みなさん、ハーネスエンジニアリングやってますか？

最近は「AIにコードを書かせる」がかなり現実的になってきました。Claude、GPT、Codex、Cursor などを使っていると、もう普通に人間より速い場面が多いです。正直、この流れはもう止まらないと思っています。

とはいえ、じゃあエンジニアがゼロになるのかというと、そこまではまだ行かないとも思っています。
コードを書く量は減っていく。でも、何を作るか、どう設計するか、どういう制約を与えるか はまだ人間の仕事です。

特に、自分みたいに新規事業やPoCを一人または少人数で立ち上げるケースだと、この「AIにどう書かせるか」はかなり重要です。雑に技術を選ぶと、AIは普通に迷うし、普通に間違えます。

なので今回は、自分が実際に新規サービスを作るにあたって考えた、ハーネスエンジニアリング時代のWebアプリケーション技術選定 をまとめてみます。かなり個人的な話ですが、同じように AI 主体で開発している人の参考にはなるはずです。

背景: AI時代の技術選定について

今のAIは、Web技術回りだと特に以下の領域に強いと考えています。

• React
• TypeScript
• hooks
• component設計
• fetch/queryまわり
• file-based routing
• モダンなフロントエンドエコシステム

まあ、つまりは一番流行っているWebシステムの技術構成が強いってことですね(Wordpressは例外ってことで・・・)。これは実際のところ、学習元のデータが多いからと言う話でもあります。

逆に、文脈が分断されやすい構成はあまり強くありません。

たとえば、

• フロントは TypeScript
• API は別言語
• ORM も別文脈
• バリデーションも別
• テンプレートも別

みたいな構成だと、AIがどこで何を見ればいいかを見失いやすいです。または調べるのに時間がかかると思います。

人間でも複雑な構成はつらいんだから、AIもそりゃつらいよね、という話です。

なので今回かなり重視したのは、AIが理解しやすい構成にすること でした。

今回重視したこと

最終的に、重視したポイントはこのあたりです。

• AIを活用した高速開発がしやすいこと
• ほぼ一人、または少人数で回しやすいこと
• TypeScript中心で開発体験を統一できること
• 型安全によってAIの自己修正が効きやすいこと
• ディレクトリや責務が明確で、AIが迷いにくいこと

特に大きいのは TypeScriptで閉じること です。

TypeScriptで統一しておくと、コンパイラがかなり強いフィードバック装置になります。AIが書いたコードで型不整合が出ても、エラー内容がはっきり出るので、そのまま自己修正させやすいんですよね。

これが言語をまたぐと一気に難しくなる。
なので、AIに大量に書かせる前提なら、単一言語で寄せた方がかなり強いです。

TanStack Start を選んだ理由

今回メインで採用したのは TanStack Start です。

競合としては Next.js が真っ先に上がると思います。Next.js も悪くないですし、実際かなり強いです。ただ、自分の中では今のタイミングだと TanStack Start の方がしっくり来ました。

理由としてはこんな感じです。

• フルスタックフレームワークである
• React / TypeScript を中心に統一できる
• TanStack Query / TanStack Router との統合が自然
• Server Functions が比較的シンプル
• サーバとフロントエンドで共通した型安全なコードを書くことが出来る
• AIに書かせる時に、明示的な構造のおかげで素直で扱いやすい
• Vercel前提の空気感が比較的薄い

特に、AIに書かせた時に変な魔法が少ない のが大きいです。

Next.js は便利な反面、App Router 以降かなり複雑になってきている印象があります。もちろんそれがハマるケースも多いのですが、AI主体で高速に試作していくなら、もう少し素直な構造の方が相性が良いと感じました。

これ以外にもいろんな理由があります。Tanstack Start公式がTanStack Start vs Next.jsというドキュメントを出しているので、気になる方はこちらを参考にしてください。

素直な構成ということで、Remix や Astro も候補にはありました。
ただ今回は、静的サイト寄りというより Webサービスをフルスタックで作る のが目的だったので、最終的に TanStack Start を選んでいます。

最終的な技術構成

現時点ではだいたい以下の構成にしています。

• フレームワーク: TanStack Start
• 実行環境: Bun
• フロントエンド: React / TypeScript
• ルーティング・データ取得: TanStack Router / TanStack Query
• 認証: Better Auth
• ORM: Drizzle ORM
• バリデーション: Zod
• API分離が必要な場合: Hono
• DB: PostgreSQL
• UI: Tailwind CSS

Bun

Bun は単純に速いですし、TanStack Start との相性も悪くありません。 Bunは最近Anthropicが買収したこともあって、今後とも一番AIとの相性が良いJavaScriptランタイムであり続ける可能性が高いと見ています。 将来的に互換性の問題が出たら Node.js に戻せばいいので、今はそこまで重く考えていません。

Better Auth

認証を自前実装したくないので採用です。
ログイン、OAuth、Passkey、2FA など、このあたりをちゃんと押さえられるのは大きい。

Drizzle ORM

Prisma も強いですが、Drizzle ORM の方が SQL に近くて薄いです。
AIに書かせた時も、過剰に抽象化されたコードになりにくい印象があります。

Hono

最初から必須ではないですが、Webhook や外部公開 API、モバイル向け API を分けたくなった時に逃げ道として持っておけるのが良いです。

アーキテクチャ方針

今回、フレームワーク選定と同じくらい重要だったのがここです。

TanStack Start は Laravel や Rails みたいな全部入りではありません。
つまり自由度が高い。自由度が高いということは、ちゃんと決めないと普通に散らかる ということでもあります。

なので最初から、責務分離とディレクトリ戦略をかなり意識しました。

自分の方針としては、Laravel っぽい責務分離をかなり参考にしています。たとえば、

• ルーターは薄く保つ
• ビジネスロジックは service に寄せる
• validation を分ける
• query / policy / domain を分ける
• テストについてどこまでやるか決める

みたいな感じです。これをDocsとskillsで最初にきっちり定義しました。

これをやる理由は単純で、AIが迷わなくなるから です。

AIって、自由に書かせると本当にいろんな場所にコードを生やします。
でも、「ルーターは薄く」「ロジックは service」「validation はここ」と最初からルール化しておくと、かなり安定します。

人間にとっても保守しやすいし、AIにとっても書きやすい。ここは本当に効きました。

実際に2週間、ほぼAIに全部書かせてみた結果

ここが一番大事なところなんですが、実際にこの構成で2週間くらい回してみました。使っているのはCodex(GPT-5.5 Fast)です。

結果から言うと かなり良いです。　(AI並の感想)

まず、2週間でだいたい 5万行くらい 書きました。
しかも、ほぼ全てのコードをAIに任せています。

その上で感じたことは以下です。

• 責務分離を決めたことで、コードの見通しがかなり良い
• ルーターが薄く保たれやすい
• サービス層にロジックを寄せやすい
• AIが設計思想を大きく崩しにくい
• TypeScriptの型エラーをそのまま修正させやすい

特に良かったのは、フロントとサーバー、DBのつながりで大きく破綻しにくい ことです。

外部 API まわりでは多少つまづくことはありました。
でも、アプリ内部のデータ受け渡しや、DB から取って表示するようなところはかなり安定しています。

これはやっぱり、TypeScript で閉じていて、型安全が効いている恩恵が大きいです。

少なくとも「型ズレで雑に壊れる」みたいなことはかなり減りました。
AIが実行して、エラーを見て、そのまま直すフローが普通に回るんですよね。これは結構感動しました。

セキュリティや全体的なパフォーマンスも、それなりと思います。流石に実際に動かしたりして見ると微妙なところもあるけれど、最初に書いたコードと考えれば全然容認できる範囲って感じです。

もちろん、これで大規模サービスが何でも作れると言い切るつもりはまだありません。
でも少なくとも、PoCから初期プロダクトをかなりの速度で前に進める という意味では、今のところかなり手応えがあります。

最後に

この2週間くらい、かなりの量のコードをAIに書かせてきました。
その上で思うのは、もう「AIがコードを書く」は前提として受け入れた方がいい、ということです。

正直、人間が生で全部書いて速度で勝つのはかなり厳しいです。 だから今後のエンジニアに必要なのは、いかにうまくハーネスエンジニアリングするか なんじゃないかと思っています。

AIを使ったコーディングは全てを雑に投げれば、完成したものが仕上がってくるわけでは無いです。そのためにも

• どの技術を選ぶか
• どう責務を分けるか
• どういうルールで書かせるか
• どういうフィードバックを返せる構成にするか

ここを設計できる人が結局必要になると思います。少なくとも・・・ここ1年は。 1年後はどうなってるかわからないのが怖いところです。

自分は今のところ、TanStack Start + TypeScript中心のフルスタック構成 はかなり良い選択だったと感じています。少なくとも、AI主体で高速にWebサービスを作るという目的にはかなりハマっています。

ハーネスエンジニアリングについては、OpenAI の以下の記事がかなり参考になりました。この記事よりもはるかに参考になると思うので、是非読んでみてください。

Harness Engineering

今後もしばらくは、この方向で開発していくと思います。
多分もう、こうしないとやっていけないんじゃないかなと思うので・・・。自分は何とかまだ生き残っていきたい。

以上です。