exe.devを使って気づいた最高の開発体験

作成日: 2026-01-11 作成者: Morix

エンジニア 開発手法

exe.dev というVMのホスティングサービスがある。 次のような機能がある。

  • 永続的仮想マシン：セッション終了後もディスク状態を維持
  • SSHサインアップ：初回接続のみでアカウント作成・認証を完結
  • 特権アクセス：OSレベルのカスタマイズを可能にするsudo権限の付与
  • HTTPS自動プロキシ：サーバー起動と同時にセキュアな外部公開URLを自動発行
  • 簡易共有機能：Googleドキュメント感覚のメール招待やリンク共有
  • AIエージェント「Shelley」：VMと統合したマルチモーダルな開発支援
  • CLI統合管理：VM操作、共有設定、SSH接続をターミナルで完結
  • リソース共有：ユーザー・チーム間でのCPU/RAMリソースの効率的活用
  • 組み込み認証：ホストプロジェクトに対する即座のアクセス制御機能
  • カスタムドメイン：独自ドメインを利用したプロジェクト公開に対応

VM上で公開しているサービスの認証機構やVM操作の手軽さが売りのホスティングサービスだ。

このサービスが面白いのは次の点だ。

  • ShelleyというAIに作成したいWebアプリ仕様を伝えると作成してくれる
  • 作成したWebアプリを本番公開してくれる
    • ドメインも払い出される
  • 開発中は自分しか見れないところで動作確認ができる
  • sshやアプリ作成などモバイルで完結可能

このexe.devを使って2つほどサービスを作ってみた。

このようなAIに口頭で指示するだけでサービスを形にするプロダクトはあったが、それを本番公開まで一気通貫でやってくれるというのが新しい。全体公開はもちろん認証機構も備わってるので限られた人のみアクセスさせることもできる。
ここまでやれてしまうと、この程度の機能のサービスを人間が作る必要はない。もし作ったとしても簡単に模倣することができる。

今後は既存プロダクトの使い勝手が気に入らなかったら、自分で作成し公開することが増えてくると思う。なので今後プロダクトを作るとしたら模倣のしづらさ・参入障壁の高さは意識していかないといけない。たとえばNani翻訳は翻訳体験の気持ちよさを突き詰めており、これを模倣することは相当難しい。そういうものを作るのが今後人間に求められるんだと思う。

さて、本題はここからだ。
exe.devのShelleyを使ったサービス開発を通じて、今後AIを使った開発に求められる体験を痛感した。

どんな体験が良かったのかというと、それは「AIがどのように品質保証してるのかが可視化される」ということだ。

次はShelleyが動作確認してる様子。

Screenshot_20260111-203629.png

大事なのはキャプチャを人間に見せていることだ。キャプチャを取ってLLMがそれを確認し、想定通り動いているのを確認するだけなら人間にキャプチャを見せる必要はないはず。それをあえて見せているのは人間に安心感を持たせるためだと思う。
Shelleyでの開発は基本的にコードは確認できない。（厳密には見れる。VSCodeで見たりもできる。が、スマホだと厳しい） コードを見せずに人間に承認を求めるなら、動作確認内容をはっきり見せるべきなのだ。
もちろんただ見せるだけではだめで、人間に実際に触ってもらうことも必要。結局エッジケースは触ってみないと炙り出せないのだ。

ということで、コードを見なくてもLLMの成果物を信用するには次の要素を満たしている必要があるというのを実感できた。

  • 動作確認内容を可視化していること
  • 成果物を人間が触れること

結局これは相手が人間であっても同じことで、これらの要素がないままレビュー依頼を出したものは信用に値しなかった。AIにも同じことを求められるようになったということなんだろう。
自分はそこの認識が甘かった。LLMを過小評価してた。LLMにモノを作らせるやり方は整備してたし満足もいってた。ただその最終的な動作確認は人間だけでやっていた。（これは今自分がやっているプロダクトが音声AIだからというのも理由にはあるが）

このことに気づく数日前からLLMの出力したコードを見ないようにするため、IDEの使用をやめていた。理由としては、AI開発環境の整備の結果、コードにケチつける頻度が下がったためだ。「そろそろコード見なくてもいけんじゃね？」という実感が湧き、そういうチャレンジをしていた。
なぜそのようなチャレンジをしてるかというと、開発環境がクラウドにシフトしてるという潮流を感じたから。特に最近Claude Code Webが話題に挙がっているが、このようなコードを見れない環境でもClaude Code開発者はガンガン開発しているという。この流れに乗らないと置いていかれる予感がした。なのでチャレンジしている。

このコードを見ない取り組みと、前述したLLMの成果物を信用する方法を組み合わせることで、人間の品質保証というボトルネックになりがちな部分をだいぶ省略でき、デリバリースピードを上げられるなと思った。

なので直近自分がやるべきAI開発の改善は「コーディングエージェントがE2Eの動作確認をでき、テスト結果・内容を人間に知らせるようにできる」ということだ。いま自分は音声AIプロダクトをやっているので、次のようなことをできるようにする必要がある。

  1. コーディングエージェントが音声AIをローカルで起動できる
  2. 音声AIの発話内容を文字起こしし、コーディングエージェントに返答内容を考えさせ、結果を音声に変換する
  3. 会話履歴や結果を報告。録音データも聴ける
  4. 成果物を電話で確認できる

難しいのは2だ。というか2以外は現状できてる。まぁここは粛々とやっていこうと思う。

ここまでやれればコーディングエージェントの成果物の品質もあがるし、人間の指示も減る。よって1タスクにかける人間の時間は減らせられるので、並列開発もできるようになる。

あとはこれをやれる環境を作ることも必要。現状Claude Code Webは動作確認のようなことはできない認識。なのでなにかしらのVMホスティングサービスが必要。これはexe.devが一番手軽でいいかもしれない。このあたりは模索していく。

ちなみに、プロダクトではなくコードの品質を確認すべきという意見もあるだろうが、実装手法をTDDにさせテストしやすい構造にさえしとけば大きな間違いにはならないんじゃないかと思ってる。テスタビリティの高いコードならそれでいいでしょう。アーキテクチャとかは知らん。そんなものよりドキュメントを如何にメンテするかの方が大事。あとテストね。E2Eになるべく近いテスト。ドキュメントとテストをちゃんと整備してさえいれば、コードなんてものは再生成させればいいんだから。

ドキュメントとテストが整備できてるからコードを見なくていいというアプローチをしてる。