開発開始から72時間で新サービスのbetaをリリース — Tessvia誕生の記録
上原正吉（EarthLink Network Co., Ltd.）。Claude Codeを開発の主体に据え、20を超えるプロダクトを1人で同時に開発・運用しています。これは、その現場の実測記です。
開発開始から72時間で新サービスのbetaをリリース — Tessvia誕生の記録
結論
この記事は、Tessvia（テスビア）という製品の名前が生まれた、最初の3日間の記録です。Tessvia が何をするサービスかは、シリーズの入口記事「Tessviaとは何か」で説明しています。ここでは、その Tessvia の最初の版がどう生まれたか——仕様を一括で渡してから、72時間で動くbetaと製品名にたどり着いた3日間——を書きます。
2026年6月10日、Minimum Viable Product（MVP、実用最小限の製品）の仕様を、AIコーディング環境の Claude Code へ一括で渡しました。その日のうちに、Turborepo（複数のパッケージを1つのリポジトリでまとめて扱う仕組み）のモノレポ11パッケージ、Chrome拡張、コマンドラインインターフェース（CLI、Command Line Interface、文字入力で操作する画面）ができました。CLIのスモークテスト（最低限の動作確認）は15件すべて通りました。翌日にはブラウザ拡張のE2E（End-to-End、利用者の一連の操作を最初から最後まで再現して動作を確認するテスト）手法を確立し、3日目にはドメイン名を機械で調べて「Tessvia」と命名しました。仕様投入から命名まで、72時間です。
3日で、動くbeta版と製品の名前が揃いました。どれも勢いだけで進んだのではありません。何を・どういう順で作らせるかを決めていたからです。この記事では、その3日のあいだに実際に何をしたのかを、1日ずつ具体的に追っていきます。
本文（読了 約8分）
1日目: 仕様を一括投入したら、その日のうちにMVPが立った
最初の日の目標は、はっきりしていました。自然言語の指示から Playwright（ブラウザ操作を自動化するツール）のE2Eシナリオを生成し、編集し、1ステップずつ実行できる、手元で完結する（ローカルファースト、手元のパソコンだけで動く）ツールです。
「手元で完結する」ことには理由があります。テストしたい画面や操作の中身を、できるだけ外に出したくないからです。AIに文章を作らせる部分だけ gpt-4o（OpenAI の言語モデル）に頼り、それ以外は手元のパソコンの中で動かす。この切り分けを、最初から設計に入れていました。
やり方で、もう1つ決めていたことがあります。仕様を小出しにしませんでした。全体の構成（アーキテクチャ）まで含めたMVPの仕様を、1回でまとめて渡しました。渡したのは、機能の一覧だけではありません。パッケージの分け方、パッケージ同士の呼び出し方、データの持ち方まで、設計を先に文章にしてから渡しました。
すると、core、ai、cli、local-bridge、ui、sdk、extension、web など、役割の違う11個のパッケージが一度に組み上がりました。1つのリポジトリで、それらをまとめて扱うモノレポの形です。その日のうちに、CLIのスモークテスト（最低限の動作確認）を走らせました。15件すべて通りました。動く土台が初日に手元にある、という状態です。
パッケージの役割も、先に決めた設計のとおりに分かれました。core がシナリオの中身を扱い、ai が自然言語からシナリオを作る部分を担います。cli は文字入力で操作する入口、local-bridge は手元のパソコンの中で各部品をつなぐ橋渡し役です。extension はブラウザ拡張、ui は画面部品、sdk は外から呼び出すための窓口、web は表に見せる画面です。役割ごとに分けておくと、あとで一部だけ差し替えたり、片方だけテストしたりが楽になります。設計を先に文章で固めていたので、AIはこの分け方のとおりに、矛盾なく11個を組めました。どこに何があるかが最初から決まっていれば、AIが構造を推測で補う必要がなく、こちらも後から探し回らずに済みます。
「動く土台」と言っても抽象的なので、補足します。初日の時点で、自然言語の指示を1つ入れると、それが Playwright のシナリオに変換され、CLIから1ステップずつ実行できる。ここまでが動いていました。作り込みは、もちろんこれからです。でも、「入力から実行まで途切れずつながっている」状態を初日に持てたことが大きい。あとは、この土台のまわりを厚くしていくだけになります。ゼロから全体像を探る段階を、初日に飛び越えられました。
なぜ小出しにしなかったのか。小さく渡すと、AIはその都度、周りの構造を推測で埋めます。あとで全体を見たときに、辻褄の合わない設計が混ざります。ところが、全体像を先に渡すと、AIは一貫した土台をまとめて作れます。手戻りが減った分だけ、余分な時間を使わずに済みました。
2日目: ブラウザ拡張そのものを自動テストにかける方法を見つけた
翌6月11日は、この3日でいちばん手を動かした日でした。この日の作業の記録は435件残っています。
この日の山は、Chrome拡張をどう自動テストにかけるか、でした。ブラウザ拡張（Chromeなどのブラウザに後から入れて機能を足す、小さなプログラム。Tessvia はこれを通してブラウザの画面を操作します）は、ふつうのWebページとは動く場所が違います。ブラウザの仕組みの中に組み込まれて動くため、テスト用のブラウザから素直には操作できません。だから「拡張は自動テストにかけられない」と諦められがちです。
でも、実際には方法があります。本物の拡張を読み込んだまま、chrome という拡張専用のAPI（Application Programming Interface、機能を呼び出す窓口）だけを差し替え役（スタブ）に置き換えます。こうすると、拡張の中身はそのままに、外側とのやり取りだけを手元で制御してテストできます。ブラウザ拡張を「自動テストにかけられないもの」から「かけられるもの」へ動かした、という日でした。
これは小さく見えて、大きな一歩でした。ブラウザ操作を通したテスト、チュートリアル、マニュアル、監視——Tessvia がやりたいことは、どれも「拡張を通して実際の画面を操作する」ことが土台になります。その拡張そのものを自動テストにかけられなければ、この上に載せる4つの用途すべてが動作確認できないまま残ります。逆に、ここが固まれば、同じ仕組みの上に4つの用途を載せていけます。2日目にこの土台を固められたことが、このあとの開発をまっすぐにしました。作る順番を決めるとは、こういう「先に固めるべき土台」を見極めることでもあります。
あわせて、この日に「1ステップずつ実行する仕組み」も作りました。シナリオを一気に流すのではなく、1手ずつ止めながら進められるようにしたのです。これがあると、AIが生成した手順を1歩ずつ目で追って確かめられます。誤った手順を、流し切る前にその場で見つけられる。拡張のテスト手法と並ぶ、この日のもう1つの成果でした（この仕組みの詳しい意味は入口記事「Tessviaとは何か」で説明しています）。
同じ日に、分岐のあるシナリオも設計しました。「ログイン済みなら進む、そうでなければログインする」のような枝分かれです。ただ、この日はうまくいったことばかりではありません。ステップごとにスクリプトを何度も読み込ませると、同じ変数を二重に宣言してしまうバグも出ました。画面を開くたびに拡張のスクリプトを差し込む作りだったので、2回目の差し込みで「その名前はもう宣言済み」とエラーになり、拡張がそこで止まってしまいます。その場しのぎで避けても、別の場所で同じ問題がぶり返しました。この二重注入の話と、分岐の設計をあとで作り直した話は、このシリーズの別の記事で詳しく書きます。
3日目: ドメインを50件超調べて「Tessvia」と決めた
3日目の6月12日、名前を決めました。
名前は、あとから変えるほど高くつきます。パッケージの名前、リポジトリの名前、ドメイン、表に出す製品名。決めたあとで全部を付け替えるのは、手間がかかります。だから、使える名前かどうかを先に確かめておきたいわけです。
そこで、RDAP（Registration Data Access Protocol、ドメインの登録状況を機械で問い合わせる仕組み）を使いました。候補のドメインを50件超、一括で空き状況を確認しました。3つのバッチと最終確認に分けて、使える候補を機械的に絞ります。感覚で1つずつ調べるより、ずっと速く、見落としも減ります。
こうして「Tessvia」と決まりました。それまで @eln/ai-test-builder-* だったパッケージ名を、@tessvia/* へ一括で付け替えました。付け替えは、11個あるパッケージすべてに及びます。名前を先に機械で確かめておいたので、ここで「やっぱり別の名前に」と迷い直すことはありませんでした。先に調べておくと、あとの作業が素直に進みます。仕様を渡した最初の日から、ここまでで72時間です。
なぜ、名前をこんなに早く決めたのか。名前は、開発が進むほど付け替える箇所が増えるからです。パッケージ名、リポジトリ名、ドメイン、外に出す製品名、資料の中の表記。3日目の時点なら、付け替えるのは11パッケージの名前とリポジトリくらいで済みます。これが数か月後なら、公開したURLや配った資料まで巻き込みます。早いうちに、しかも空いている名前かどうかを機械で確かめてから決める。そうすれば、あとで名前のことで作業が止まりません。人が候補を1つずつ思いつきで調べるより速く、「実は取られていた」という見落としも減ります。決めることを先に済ませておくのは、作る速さそのものを上げる投資です。
作れた理由: 設計を先に文章で固めてから、AIに実装させた
3日でここまで進んだのは、勢いだけではありません。進め方を決めていました。
まず、何を作るかを文章で書きます。どういう画面で、どんな操作を、どのパッケージが担うか。それから、期待する動きをテストとして先に書きます。最後に、そのテストが通るように中身を実装させます。仕様を先に決めてから実装する、この順番です（テスト駆動開発、TDD、Test-Driven Development、先にテストを書いてから中身を作る進め方）。
AIに任せるほど、この順番が効きました。実装が満たすべき条件を先に文章で固めておくと、AIが構造を推測で補う余地が減ります。逆に、その条件が曖昧なまま「いい感じに作って」と頼むと、それらしいけれど後で辻褄が合わないコードが増えます。人間がやることは、コードを1行ずつ書くことから、「何を・どういう順で作らせるか」を決めることへ移りました。手を動かす速さより、決める速さが成果を左右します。
具体的には、こういうことです。「この操作をしたら、この結果になるはず」というテストを先に書いておくと、AIはその結果を満たすようにコードを書きます。行き先が条件で示されているので、解釈の幅が狭くなります。逆に、テストがないまま「いい感じにE2Eを動かして」と頼むと、AIは一見それらしいコードを返しますが、何をもって正しいとするかが決まっていないので、あとで辻褄が合わなくなります。テストは、AIにとっての「合格の条件」です。合格の条件を先に文章にしておくほど、出てくるものが安定しました。3日で形になった背景には、この「先に条件を決める」進め方があります。
この速さを支えたものが、もう1つあります。作業を1人で抱え込まないことです。調べる、実装する、確かめる。この一連を、できる範囲でAIに任せます。私がやるのは、仕様を決めること、そして出てきたものが意図と合っているかを判断すること。この2つに集中できたから、3日で命名まで進みました。進みを決めていたのは、手を動かす人数ではありません。何を・どういう順で作らせるかを決める速さと、その判断の質でした。
この進め方は、たまたまこの製品でうまくいった、という話ではありません。私たちは、自分たちの仕事を1つずつAIに任せていくという方針で開発を進めています。人間の役割は、手を動かす側から、何をどう作らせるかを決め、出てきたものを判断する側へ移ります。決めることと、確かめること。この2つに人間の時間を寄せるほど、少ない人数でも複数の製品を並行して立ち上げられるようになります。Tessvia の最初の3日間は、その進め方を実際の製品づくりで試した、ひとつの記録でもあります。
3日で、どこまで動いたか
3日で名前まで決まったあとも、手は止めませんでした。6月13日の時点で、拡張のE2E（ブラウザ操作を通したテスト）は27本、テストのまとまりは3,367行になっていました。細かい設定の画面や、日本語と英語の切り替えも入れました。試作（プロトタイプ）の段階は越えて、動くbetaと呼べる状態になっていました。
たった3日で、自然言語の指示からシナリオを生成し、1手ずつ実行し、拡張をテストできる土台ができました（日本語・英語の対応は、この直後の6月13日に加わりました）。ここまで来られたのは、初日に「入力から実行まで途切れずつながった土台」を持てたからです。土台が先にあれば、あとはそのまわりを厚くしていくだけになります。ゼロから全体像を探す時間を、初日に飛び越えていました。作る順番を決めておくと、3日でこれだけのものが形になります。逆に言えば、この3日でできたのは「動くbeta版」までです。ここから先の作り込みと、実際に使える製品へどう育てていったかは、このあとのシリーズで一つひとつ続けます。
この3日が、今の Tessvia につながる
ここまでが、Tessvia という名前が生まれるまでの3日間です。仕様を一括で渡し、初日に動く土台を立て、2日目にブラウザ拡張をテストできるようにし、3日目に名前を決める。3日で、動くbeta版ができました。
このあとシリーズでは、ここで作った最初の版が、どう今の Tessvia になっていったかを書きます。ブラウザ拡張のE2Eをどう組んだか、AIの誤った生成をどう止めたか、操作マニュアルの自動生成をどう実現したか、そして別々に始めた2つのプロジェクトをどう1つに畳んだか。一つひとつを順番に続けます。今の Tessvia が何をするサービスかは、入口記事「Tessviaとは何か」にまとめています。
3日という短さは、勢いの結果ではありません。何を・どういう順で作らせるかを先に決め、出てきたものが意図と合うかを判断する——この3日は、その進め方を最初の製品づくりで試した記録です。ここで立てた土台の上に、このあと何を積んでいったのかを、次の記事から順に書きます。
転用できる教訓
- 仕様は小出しより一括投入。全体の構成まで含めてまとめて渡すと、AIは一貫した土台を作れます。あとから継ぎ足すより、辻褄の合った土台が早く手に入ります。
- 設計を先に、実装を後に。何を作るかを文章で固め、期待する動きをテストで書いてから実装させます。行き先が曖昧なままだと、それらしくて後で辻褄の合わないコードが増えます。
- 命名は機械で調べる。感覚で候補を消していくより、RDAPなどでドメインの空きを一括で確認したほうが速く、取りこぼしも減ります。
- 初日に「動く土台」を持つ。入力から実行まで途切れずつながった土台を最初に立てると、あとはそのまわりを厚くするだけになります。ゼロから全体像を探す段階を初日に飛び越えられると、残りの時間を作り込みに回せます。
この Tessvia についての記事は、開発の経緯・どんな機能があるか・どう実装したかを、順次シリーズとして公開していきます。 興味のある方は、ぜひ「いいね」と記事の購読をお願いいたします。
Tessvia は、物語シナリオを1つの正本から複数プラットフォームへ展開するサービスです。詳しくは https://tessvia.com をご覧ください。 そのほかの自社プロダクトは https://www.eln.ne.jp/products にまとめています。
筆者について
上原正吉。EarthLink Network Co., Ltd. でAI開発をしています。2025年からClaude Codeを開発の主体に据え、今は20を超えるプロダクトを1人で同時に開発・運用しています。この連載では、その現場で実際に起きたこと（うまくいったことも、失敗も）を、数字と一緒に書いていきます。
また、AIで業務や開発を組み替えたい会社・チーム向けに、AI活用のコンサルティングも受け付けています。ご相談は www.eln.ne.jp からどうぞ。
EarthLink Network は、会社の全業務を AI で回すために、必要になったものを自社で作っています。いま作っているプロダクトの一覧と概要は、こちらにまとめています。
→ EarthLink Network が自社でつくっている18のプロダクト
会社と各プロダクトの詳細は、公式サイト www.eln.ne.jp をご覧ください。