Kliv

    このページは英語から翻訳されています。

    法務サービス

    AI活用の法律文書の生成・管理システムを構築する

    受け入れの回答が、自事務所の条項テンプレートから組まれた初稿になる。案件の上で版を持ち、共同経営者の承認で開き、次の取引のために検索できる形で。

    kliv.dev

    テキスト ボックスにアイデアを入力するだけで、AIがそれを構築します。

    110 文字

    なぜ自前の文書システムを作るのか

    三田・オセイ法律事務所は共同経営者2人の商業リースの実務で、その本当の資産はレターヘッドではありません。14年ぶんの交渉済み条項です。仲裁を生き延びた賃料改定の算式、手強い賃貸人がついに受け入れたステップイン権の文言。汎用の文書ツールはファイルを保管します。案件も、当事者も、2019年の補償の除外がなぜ存在するのかも知りません。

    Klivは、その実務の周りにシステムを構築します。テンプレートは事務所自身の先例で、草案は受け入れの回答から組み上がり、版はすべて案件の上に残り、そして公開のゲートが、共同経営者の読んだ文書にだけ事務所の名が載ることを確かにします。

    実務が覚えていること

    文書は決して、ただのファイルではありません。案件に、当事者に、そして決定の連なりに属します。その下の構造を示します。

    案件と当事者

    文書はすべて案件に属し、案件は当事者、担当チーム、期限を知っています。案件にいない人には、短い一覧が見えるのではありません。何も見えません。

    テンプレート一式

    事務所の先例を、生きたテンプレートとして。変数を持つ条項、条件を持つ選択肢。型付きのサーバー側関数が、受け入れの回答から数秒で草案を組みます。組み立てのロジックは、事務所が読めるコードです。

    版

    生成のたび、編集のたびに、作成者と時刻を持つ新しい版になります。何も上書きされません。だから「3月に何を送ったか」は、発掘作業ではなく参照です。

    公開の状態

    草案、レビュー済み、公開。データベースの中の状態機械です。クライアント向けのダウンロードは、共同経営者が状態を切り替えるまで存在せず、その切り替えは記録されます。

    先例エージェント

    「小売のテナントにステップイン権を使ったのはどこで、どう和らげたか」。エージェントは、事務所自身の意味索引された案件とテンプレートから引き、事務所の文言をそのまま返します。

    クライアントへの受け渡し

    公開されたパッケージは、クライアントごとの領域に、既定で非公開のまま現れます。クライアントには自分の文書が見え、その機構は決して見えません。

    あるリース案件の一生

    商業リース1件を、問い合わせから書庫まで追い、誰も何かを覚えずに済んだ回数を数えます。

    01

    月曜——受け入れ

    クライアントが質問票に答えます。期間、物件、中途解約の選択肢が、受信箱の散文としてではなく、案件の上の構造化フィールドとして落ちます。

    02

    月曜、少しあと——草案が組み上がる

    テンプレートにフィールドを足せば、完成した初稿になります。担当の弁護士が開く第9条は、もう調整済みです。前の取引の置換ミスを抱えた白紙ではありません。

    03

    水曜——編集

    担当が中途解約の通知期間を締めます。版の記録が、誰が第9条に触れ、いつ、その前は何と書いてあったかを残します。

    04

    木曜——ゲート

    共同経営者が読み、承認し、状態が公開へ切り替わります。その瞬間まで、送信ボタンはほかの誰にも存在しません。

    05

    金曜——受け渡しと長い記憶

    クライアントは自分の領域からダウンロードします。署名済みの写しが返れば案件に綴じられ、次の取引が引く、検索できるコーパスに加わります。

    3つの実務、3つの文

    kliv.dev

    商業リースのパッケージ

    受け入れから共同経営者承認の公開まで。

    “文書システムを作って。受け入れの質問票が、うちの条項テンプレートからリースの草案を組んで、版は案件ファイルの上に残って、公開には共同経営者の承認を要するようにして。”

    kliv.dev

    在留資格の申請一式

    チェックリスト、案件の状況、クライアントのアップロード。

    “申請一式のシステムを作って。うちのチェックリストから申請パッケージを組んで、各案件の書類の状況を追って、クライアントが証拠を自分の非公開領域にアップロードできるようにして。”

    kliv.dev

    相続対策のワークフロー

    質問票から、弁護士がレビューした草案へ。

    “相続文書のワークフローを作って。質問票の回答が、うちの先例から遺言と信託の草案を組んで、どの草案もクライアントが見る前に弁護士の承認を要するようにして。”

    どう組み上がるか

    組み立てはコードであって、マクロではありません。 草案の生成は型付きのTypeScriptサーバー関数で走ります。誰も開けたがらないWordのマクロではなく、レビューでき、テストできるロジックです。組み立てのコードは、作られている最中に本物の単体テストを得て、Scenarioテストが道のり全体——受け入れ、共同経営者の承認、クライアントのダウンロード——を、使い捨てのデータの複製に対して歩き、何が許され何が拒まれたかの控えを出します。

    コーパスは複利で効きます。 閉じた案件はすべて、先例エージェントを賢くします。検索が事務所自身の文書の上を走るからです。意味検索で、別に運用する基盤はありません。エージェントは、自らの権限で何かを起草することはありません。見つけて引用し、決めるのは弁護士です。

    定額の料金は、先に回収。 商品化された仕事は自然に収まります。8万円のリース確認パッケージを、事務所自身のStripeアカウントの決済で売り、支払いが着いたときに案件が開きます。

    文書生成は、たいていサービス業の中の1部屋です。建物の残り——提案書、ポータル、顧問契約——がサービス業のソリューションページの主題です。

    事務所が承認する前に

    エージェントは法律業務をしているのですか?

    いいえ。事務所自身のテンプレートと過去の案件を引いて引用します。クライアントに助言はせず、あなたの弁護士が書いた文言からしか起草しません。判断は、弁護士会が言う場所に留まります。

    案件は誰が見られますか?

    そこに割り当てられたチームです。アクセスはデータベースで行ごとに強制されるので、他人の案件のURLやIDは何も返しません。権限エラーですらなく、無です。

    うちにはもうWordのテンプレートがあります。どう取り込みますか?

    アップロードして、会話の中で変数を説明してください。AIが構築しながら、それを構造化テンプレートに変えます。一番よく組む3つの文書から始めて、残りは出てきたときに足してください。

    クライアントは、着手前に支払えますか?

    はい。定額のパッケージは事務所のStripeアカウントの決済を通り、支払いが着いたときにだけ案件が開くよう設定できます。

    14年の先例は、共有ドライブより良い扱いに値する

    文書、承認の連なり、そして誰が何を見てよいかを説明してください。それを強制するシステムを、Klivが構築します。