私は趣味でSaaSを作っています。Jurfiを公開した時点でも、これらのプロジェクトからの売上はまだゼロでした。少し痛い事実ですが、これもこの話の一部です。それでも作り続けるのは、プロダクトを作ること自体が本当に好きだからです。Jurfi.comは、その最新のプロジェクトです。
Jurfiは、構造化された法務文書のドラフトを作るためのブラウザ型スタジオです。出発点は、かなり具体的な不満でした。白紙から書き始めるのは大変です。一方で、曖昧なAI回答は逆の問題を生みます。文章量は多いのに、文書としての構造が見えず、どこをどう確認すればよいのかも分かりにくい。そこで私は、入力項目を明確にし、文書の形を定め、内容を「信じる」のではなく「確認できる」作業ドラフトを作れる中間の仕組みを目指しました。
白紙ではなく、構造から始める
実務的な文書の多くは、同じような問いから始まります。何を書けばよいのか。どの順番で書くのか。何を見落としているのか。Jurfiは、WebサイトやSaaSのポリシー、サービス契約、賃貸関連書類、各種レター、請求・申立て文書、受領書など、実際に必要になる文書でこの負担を減らすことを狙っています。
基本的な考え方は単純です。白紙から始めるのではなく、フォームやテンプレートから始める。必要な情報を入力し、構造化された作業ドラフトを作り、その後で内容を確認・修正します。
- シンプルなフォームとテンプレートから法務文書のドラフトを作る。
- 構造化されたドラフトをブラウザ上で生成する。
- 各バージョンを使い捨ての文章にせず、ドラフトをローカルに保持する。
- 文書作成の混乱と、繰り返し発生する手作業の組み立てを減らす。
私は意図的に成果物をドラフトと呼んでいます。見た目が整っていても、特定の法域、契約、事業、紛争に適しているとは限りません。きれいな文章や書式は、法的な正しさの証明にはなりません。
機能一覧より、できないことを明確にする
一番重要だったプロダクト上の判断は、テンプレートをもう一つ増やすことではありませんでした。Jurfiが何を装ってはいけないかを決めることでした。Jurfiは弁護士ではありませんし、複雑な法的問題をすべて解決できるシステムとしても提示していません。
私が狙っている価値は、もっと限定的で実務的です。速さ、構造、分かりやすさ。白紙から一貫した作業ドラフトまでの時間を短くし、入力情報を明示し、繰り返しの組み立て作業を減らし、そのうえで結果を批判的に読む。法的・金銭的なリスクが大きい文書であれば、専門家による確認が次の妥当なステップです。
この境界は重要です。生成された文章は自信ありげに見えても、不完全だったり間違っていたりします。法務文書のツールでその不確実性を隠すのは、良いプロダクト判断ではありません。私は「魔法のように見せる」より、限界を見える形にしたいと考えています。
このプロジェクトでの「ブラウザ型」の意味
作業フローはブラウザを中心に設計しており、ドラフトはローカルに保持できます。文書の改訂版がタブ、チャット、コピーした断片に散らばると、作業はすぐに混乱するからです。
ただし、この機能から根拠以上のプライバシー主張をするつもりはありません。確認できる具体的な機能は「ドラフトをローカルに保持できる」ことです。あらゆる処理が、あらゆるケースで必ず端末内だけで完結する、という意味ではありません。実務上のポイントはもっと単純です。ドラフトを一回きりの回答ではなく、継続して扱える文書として残せることです。
公開したからといって、見つけてもらえるとは限らない
公開後、最も不確実なのは発見されるかどうかです。私は文言、レビューの流れ、文書品質にかなり手を入れました。その先には、自分では直接制御できない部分があります。そもそも人に見つけてもらえるのか、という問題です。
感情的には「ここからはGoogleが仕事をしてくれればいい」と言いたくなります。しかし技術的には、もっと慎重に考える必要があります。Google自身も、要件を満たすページであっても、クロール、インデックス、Searchでの表示は保証されないと説明しています。クロール、インデックス、ランキング、トラフィックは別の段階です。丁寧に公開しただけで自動的に得られるものではありません。
サイドプロジェクトでは、この区別が重要です。何を作るか、何を公開するか、どう説明するかは自分でコントロールできます。しかし、検索がいつ発見するか、その発見がユーザーにつながるかまではコントロールできません。
このプロジェクトから持ち帰ること
成長が遅くても、Jurfiを作ってよかったと思っています。私が得た教訓は「法務文書は簡単だ」とか「AIが難しい部分を消してくれる」ということではありません。むしろ逆です。文書の影響が大きいほど、明確な作業フローと見える限界が重要になります。
- 出力の形がある程度決まっているなら、入力も構造化する。
- 生成文は正しさの証明ではなく、作業ドラフトとして扱う。
- ソフトウェアによる支援と専門家の判断の境界を明確にする。
- 生成をゴールにせず、レビューを作業フローに残す。
- プロダクト品質と検索結果を分けて考える。一方が他方を保証するわけではない。
jurfi.comで目指したのは、そのような基準です。文書作業の混乱を減らし、繰り返し作業を減らし、「この文書が必要だ」から「自分で確認できるドラフトがある」までの道筋を分かりやすくすることです。