上原正吉（EarthLink Network Co., Ltd.）。Claude Codeを開発の主体に据え、20を超えるプロダクトを1人で同時に開発・運用しています。これは、その現場の実測記です。
Tessviaとは何か — 1つのシナリオから、4つの成果物を導く
結論
Tessvia（テスビア）は、利用者の画面操作の手順を、1つのシナリオ（おおもと）として1回だけ書き、そこから用途の違う4つの成果物を機械的に導き出すサービスです。4つとは、チュートリアルの再生、操作マニュアルの自動生成、E2E（End-to-End、利用者の操作をそのまま再現する）テスト、そして画面の生存監視です。同じ操作を、4回書かずに済みます。
私たちは自分たちの開発を1つずつAI（人工知能）に任せていく中で、このツールを作りました。テストも、手順書も、監視も、もとをたどれば「利用者が画面をこう操作する」という同じ手順を書いているだけです。それなら、その手順を1回書いて使い回せばいい。Tessvia はその素朴な発想から出発しています。このシリーズは、その Tessvia をどう作り、何を学んだかを順番に書いていきます。この記事はその入口として、まず「Tessvia が何をするものか」を、実際の画面とあわせて説明します。
なぜ4つを1つにまとめるのか
やりたいことは1つです。「利用者がこの画面をこう操作する」という手順（シナリオ）を、1回だけ書きます。そのシナリオを1つだけ、おおもととして管理します。あとは、その同じシナリオから、用途の違う4つの成果物を機械的に導き出します。
- チュートリアルの再生: 実際の画面の上に吹き出しや強調を重ねて、利用者に操作を案内します。
- 操作マニュアルの自動生成: 同じ操作をAIが実際になぞって撮影し、手順書のページに組み立てます。
- E2Eテスト: 同じ操作を Playwright（ブラウザ操作を自動化するツール）のテストとして実行し、画面が壊れていないかを確認します。
- 生存監視（設計段階）: 同じ操作を定期的に流して、本番の画面が動き続けているかを見張る——この4つめの使い方は、いま設計を用意している段階です（実装は他の3つが先行しています）。
ふつうは、この4つを別々の担当が別々に書きます。すると、少しずつ食い違っていきます。具体例で考えます。ある画面の「送信」ボタンが「保存して送信」に変わったとします。エンジニアはE2Eテストのボタン名を直します。でも、マニュアルに貼られた画像は撮り直されないまま古いボタン名で残ります。チュートリアルの吹き出しも、前の文言のままです。監視スクリプトは、運が悪ければボタンを見つけられずに誤検知します。1つの変更が、4か所に波及するのに、直されるのは気づいた1か所だけ。これが、別々に書くことの本当のコストです。
1つのシナリオから出していれば、そのシナリオのボタン名を直すだけで4つとも同時に変わります。同じ操作を4回書かなくていい。直し忘れによるずれが、原理的に起きません。作る動機も、そこにあります。同じ作業を何度も書く手間を、便利に減らしたい。それだけです。
シナリオはどんな形か
おおもととなる「シナリオ」は、特別な書き方を覚える必要はありません。「このボタンを押す」「この欄にこう入力する」といった手順を、自然言語（ふだんの言葉）で1つずつ並べるだけです。ステップごとに、タイトル（その手順の名前）と本文（何をするか）を書きます。
実行するときは、一気に最後まで流すのではなく、1手ずつ止めながら進められます。どの手順で画面の状態が変わるのかを確かめながら組み立てられるので、AIが提案した手順が正しいかどうかも、1歩ずつ目で追って確かめられます。
手順には枝分かれも書けます。たとえば「ログイン済みなら次へ進む、そうでなければ先にログインする」といった分岐です。現実の操作は、いつも同じ順番で進むとは限りません。状態によって道が分かれるところまで1つのシナリオに書けるので、テストもマニュアルも、実際に起こりうる流れをそのまま表現できます。
なぜ壊れにくいのか: 要素を探すのはAI
ここが、このツールでいちばん大事なところです。自然言語で書いた手順は、どうやって実際の操作になるのか。
従来のE2Eテスト——Playwright や MagicPod といったツール——では、「ログインボタンを押す」という操作を機械にやらせるために、そのボタンが画面のどこにあるかを DOMセレクタ（HTMLの構造の中で要素を指し示す書き方）として人が正確に指定する必要がありました。開発者ツールで要素をたどり、「ログインボタンはこの要素」と教え込む作業です。問題は、画面の作りが少し変わる——ボタンの位置が動く、HTMLの構造が組み替わる——だけで、その指定が通じなくなり、テストが壊れることです。機能そのものは何も壊れていないのに、セレクタがずれただけでテストが赤くなる。E2Eテストが「書くのも直すのも大変」と言われてきた最大の理由が、これです。
Tessvia は、そこをAIに任せます。人が書くのは「送信ボタンを押す」という、ふだんの言葉の手順だけです。実行するとき、AIがその一文といま開いている画面を照らし合わせ、「送信ボタン」がどの要素かを自分で探し当てて操作します。DOMセレクタを人が書いて固定する工程が、ありません。だから、ボタンの位置やHTMLの構造が多少変わっても、「送信ボタン」という意図さえ同じなら、AIは同じボタンを見つけ直せます。画面を少し作り替えただけでテストが片っ端から赤くなる、という事態が起きにくくなります。
この「人が書くのは意図、要素を探すのはAI」という形は、2つの効果を同時に生みます。1つは、シナリオが人にとって読みやすいこと。セレクタの羅列ではなく「ログインする」「送信ボタンを押す」という手順書そのものなので、書いた本人でなくても中身がわかります。もう1つは、テストが壊れにくいこと。もろさの元だったセレクタの固定を、実行時のAIの探索に置き換えたからです。読みやすさと壊れにくさは、ふつう両立しにくいものですが、ここでは同じ仕組みから両方が出てきます。そしてこの同じ手順が、テストだけでなくチュートリアル・マニュアル・監視にも回っていく——というのが、この記事の最初に書いた話です。
画面で見る（その1）: 拡張のコンソールからテストを実行する
言葉だけでは伝わりにくいので、実際の画面を見てもらいます。Tessvia には、ブラウザに入れて使う Chrome 拡張（拡張機能）があります。テストしたい画面を開いたまま、その上に縦長のパネル（操作盤）を開き、そこからシナリオを実行したり、マニュアルを作ったり、不具合を報告したりします。
下の画面が、その拡張のパネルです。左上に「Test & Record Console」（テストと記録のコンソール）とあり、右上の「Connected」は、自社（EarthLink Network）の作業場所につながっている状態を示します。Tessvia は、組織（会社やチーム）とプロジェクト（対象のアプリ）という単位で作業を整理します。ここでは「promptflow CI catalog」というプロジェクトを選んでいます。パネルは「テスト実行（Test Execution）」「マニュアル作成（Manual Authoring）」「不具合報告（Bugs）」の3つのタブに分かれ、いまはテスト実行のタブを開いています（タブ名は画面上は英語表記です）。
「テスト実行」タブには、登録済みのテストが並びます。この例では「CI 全量（promptflow）」というスイート（テストのまとまり）に361件のケースが入っていて、それが「chat（23件）」「auth（62件）」「billing（59件）」のように機能ごとのカテゴリに分かれています。カテゴリを開くと、1件ずつのケース名と、それぞれが何ステップの操作でできているか（たとえば「5 steps」）が見えます。どれも、人が自然言語で書いたシナリオがそのまま並んでいるだけです。
画面で見る（その2）: ケースを開いて、AIに流させる
ケースを1つ開くと、そのシナリオが何をするものかが、ステップごとに並びます。下の画面は「メッセージを送って AI 応答を受け取れる」というケースで、「チャット入力欄にプロンプトを入力する」「送信ボタンを押す」「応答がストリーミング表示される」……と、5つの手順がそのまま読めます。特別な記法はありません。人がふだんの言葉で書いた手順が、そのまま実行の単位になっています。
実行すると、さきほど書いたとおり、AIがこの手順を上から順に画面でなぞります。「送信ボタンを押す」とあれば、AIがいまの画面から送信ボタンを探して押す。セレクタを人が指定しなくても動き、画面が多少変わっても追従します。各ステップが通ったかどうかは、AIが自動で見ていきます。基本は全自動です。
そのうえで、画面の下の「JUDGE THIS CASE（このケースの合否）」から、人が「Pass（合格）」「Fail（不合格）」「Skip（飛ばす）」を手で付け替えることもできます。自動の結果が実態と合わないとき——たとえば一応は最後まで流れたが、人の目には不合格、というようなとき——に、最後は人が上書きできる、という位置づけです。手を動かして画面を操作するのはAI、結果の最終的な責任は人が持てる。手を動かす作業と、合否の責任を切り分けてある、ということです。
画面で見る（その3）: 不具合は、見つけたその場で報告する
テストやマニュアル作成の最中に画面のおかしなところを見つけたら、別のツールに移らず、その場で報告できます。下の画面が、その「不具合報告」のモーダル（小窓）です。見ている画面をそのまま取り込み、矢印（Arrow）・丸（Circle）・四角（Square）・文字（Text）の注釈を、色を選んで重ねられます。どこがどうおかしいのかを、言葉で書き写すのではなく、画像の上に直接しるしで示せます。あとはタイトルと説明を書いて「Register report（不具合管理へ登録）」を押すだけです。
報告した不具合は、同じ「不具合報告」タブの一覧にたまっていきます。下の画面の「RECENTLY REPORTED BUGS（最近の報告）」には、「モデル切替がリロードで既定に戻る」「比較モードで一部モデルの個別コストが NaN 表示」といった、実際に報告された項目が並んでいます。それぞれ、どのシナリオから報告されたかがひもづくので、あとから「どの画面のどの状態だったか」を思い出す必要がありません。
テストの結果（通ったか落ちたか、どのステップで止まったか）をどう見せるか、実際のテストシナリオをどう組むかは、シリーズのE2Eの回で詳しく扱います。この記事では、まず「同じシナリオから4つが出る」という全体像と、その操作が対象の画面のすぐ上で完結することを押さえてください。
なぜ Chrome 拡張という形なのか
テストやマニュアル作成のツールは、ふつう対象のアプリとは別の画面で動きます。すると、手順書と実際のアプリの画面を、別々のウィンドウで開くことになります。行き来しながら「この操作は、たしかあの画面の…」と記憶をたどることになり、その記憶が古くなると、手順書の内容と現実の画面が食い違っていきます。
拡張という形は、その行き来をなくすための選択です。テスト対象のページを開いたまま、その同じ画面の上にパネルを重ねます。いま見ているボタンを、その場で指し示し、その場で記録できます。手順を書く人と、実際に操作される画面が、同じ場所にある。だから、手順と現実がずれにくくなります。もう1つの利点は、マニュアルの各ステップに載るスクリーンショットが、この「見ている画面そのもの」から撮られることです。別途、撮影用の環境を立てて撮り直す必要がありません。
AIエージェントが実際の画面をなぞる
「マニュアルを自動生成する」と言うと、あらかじめ撮っておいた画像を並べるだけだと思われがちです。Tessvia は違います。自然言語で書いた手順を、AIエージェント（自動で画面を操作する仕組み）が実際になぞり、各ステップで本物の画面を撮ります。だから、アプリの見た目が変わっても、シナリオを走らせ直せば最新の画面でマニュアルが作り直せます。手作業でスクリーンショットを撮って貼り替える工程が、まるごと要りません。
実際に画面を操作する方法は、用途に応じて2つ用意しています。1つは「この場で生成」で、Tessvia のサーバ自身がブラウザを動かして撮影します。手元で完結し、追加の準備は要りません。もう1つは「runner（ランナー）経由」で、別のマシンで動く撮影役が代わりに操作します。サーバをどこかに置いたうえで、手元のマシンから社内向けのアプリを撮りたいときに使います。撮りたい画面がどこにあるかで、動かす場所を選べます。
ログインが必要なアプリも撮れます。事前にログイン済みのセッション情報を用意して渡すと、その状態から操作を始められます。認証の情報は環境変数（プログラムに外から渡す設定値）としてのみ渡し、ファイルやログには書き残しません。テスト対象の中身をできるだけ外に出さない、という設計を最初から守っています。
生存監視という4つめの使い方（設計段階）
4つめの使い方として、生存監視を設計しています。すでにあるシナリオを定期的に自動で流し、本番の画面がいまも動き続けているかを見張る、という構想です。テストは変更のたびに走らせますが、監視はそれとは別に、時間を決めて繰り返し流します。ある朝、ログインの手順が途中で止まるようになっていたら、利用者より先に気づける——それが監視で狙う形です。
ここで効いてくるのが、やはり「1つのシナリオ」です。監視のために新しく手順を書き起こすのではなく、すでにあるシナリオをそのまま時間割で回すだけで済みます。テストで確かめている流れと、監視で見張る流れが、同じものだと言えます。チュートリアル・マニュアル・テスト・監視の4つが、どれも同じ1つのシナリオから出ている状態を、最後まで保てます。なお、この生存監視は他の3つより実装が後発で、いまは連携の設計を用意している段階です。実際に動いているのは、これまでに画面で見せたチュートリアル再生・マニュアル自動生成・E2Eテストです。
使い方の流れ
全体の流れは単純です。
- シナリオを1回書く。「この画面をこう操作する」という手順を、自然言語（ふだんの言葉）で書きます。ステップごとにタイトルと本文を並べるだけです。
- AIに実際になぞらせる。書いた手順のとおりに、AIエージェントが実際の画面を操作し、各ステップのスクリーンショットを撮ります。数分でスクリーンショット付きの手順書ができ、そのままダウンロードもできます。
- 4つの用途に展開する。同じシナリオを、チュートリアルとして流す、マニュアルに組み立てる、E2Eテストとして実行する、監視として定期的に回す（監視は設計段階）——用途に応じて出し分けます。
ここで人間がやることは、手順を決めることと、出てきたものが意図と合っているかを確かめることの2つです。同じ操作を4回書き写す作業は、機械の側に寄せています。手を動かす速さより、何を・どういう順で作らせるかを決める速さと、その判断の質が、成果を左右します。
誰のためのツールか
Tessvia は、自分の開発や運用をできるだけ自動化したい人のためのツールです。少人数で複数のサービスを回している開発者や、個人で事業をやっている方を、まず念頭に置いています。こうした立場では、テストを書く人、手順書を作る人、監視を見る人が、たいてい同じ1人です。1人が4役を兼ねると、同じ操作を4回書く負担がそのまま効いてきます。だから、1回書けば4つに展開できる仕組みの価値が、いちばん大きく出ます。
私たち自身が、まさにその立場でこのツールを必要としました。自社の複数のサービスを少ない人数で開発・運用する中で、テストとマニュアルと監視を別々に用意する余裕はありませんでした。手が足りないなら、同じ作業を何度もさせない形にするしかない。Tessvia は、その必要から生まれたツールです。だからこのシリーズは、きれいな製品紹介ではなく、必要に迫られて作った過程の記録になります。
ある作業を自動化すると、次に自動化したい作業が見えてきます。テストを自動で作りたい、ならば手順書も自動で作りたい、ならば動いているかも自動で見張りたい——その連なりが1つのシナリオに集まったものが、今の Tessvia です。
このシリーズの読み方
今の Tessvia は、じつは別々に始めた2つのプロジェクトが後から1つに合流してできています。片方は「シナリオを作る」側、もう片方は「シナリオを届ける（配信する）」側でした。振り返ると、この2つは1つのサービスの両面だったのですが、当時は別々の文脈で走り出したので、しばらく別々のプロダクトとして育ちました。この二重の開発になぜ気づくのが遅れ、どう1つに畳んだかも、このシリーズで書きます。
このシリーズでは、その経緯を順番にたどります。次の記事では、Tessvia という名前が生まれた最初の3日間（誕生の記録）を書きます。仕様を一括で渡したら、その日のうちにモノレポ（複数のパッケージを1つのリポジトリでまとめて扱う仕組み）のMVP（実用最小限の製品）が立ち上がった話です。そのあと、ブラウザ拡張のE2Eをどう組んだか、AIの誤った生成をどう止めたか、二重に作ってしまった実装をどう1つに畳んだか、操作マニュアルの自動生成をどう実現したか、といった一つひとつを続けます。
きれいに完成した設計を後から清書したものではありません。作りながら間違え、直し、ときには丸ごと作り直した、その過程をそのまま書きます。同じように、自分の作業をAIで自動化しようとしている方に、実際のところ何が起きるのかが伝わればと思っています。
転用できる教訓
- 同じ操作は1回だけ書く。チュートリアル・マニュアル・テスト・監視は、見た目は別物でも中身は同じ「画面操作の手順」です。1つのシナリオにまとめれば、直し忘れによるずれが原理的に起きません。
- シナリオは機械が読める形で持つ。人が手で4か所を直す運用は、いつか必ずどこかがずれます。1か所を直せば全部が変わる作りにしておくと、ずれる余地がなくなります。
- 作業は対象の画面のすぐ上で。別のツールに切り替えるほど、手順書と実際の画面を別々に扱うことになり、食い違いが生まれます。見ている画面の上でそのまま実行できると、手順と現実がずれにくくなります。
- 人間は手順と判断に集中する。手を動かして4回書き写す作業は機械に寄せ、人間は何を作らせるかを決め、出てきたものが意図と合うかを確かめる。自動化が進むほど、この切り分けが効いてきます。
この 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 をご覧ください。