「小さな出費に気をつけよ。小さな穴が大きな船を沈める。」 — ベンジャミン・フランクリン

多くの創業者が痛いほど理解しているスタートアップの財務管理の現実があります。それは劇的なものではありません。取締役会の資料に載るようなことでもありません。誰も疑問に思わなかったクラウド利用料の請求書や、4ヶ月前に退職した社員のIDが実質的にまだ使われていること、誰にも交渉する時間がなかったために18%増で自動更新されてしまった契約などに現れるものです。

スタートアップはスピード感を持って行動することには非常に長けていますが、実際に何を支出しているかを管理するという、小さく退屈で面倒な作業は極めて苦手です。創業者が無責任だからではありません。彼らにとって「注意」こそが最も希少なリソースであり、交渉を自動化する方法を誰も見つけられていないからです。

消費者向けには、忘れ去られたサブスクリプションを見つけ出して解約してくれるツールがあります。しかし、スタートアップには何もありませんでした。

LEGRのチームは、この現状を誤りだと判断しました。

彼らが直面した問題

インスピレーションはリサーチから生まれたのではなく、スタートアップを運営する中で生まれました。

もっと安価な代替手段があるのに、誤ったモデルを呼び出し続けて発生する高額な利用料。すでに退職した社員のゴーストID。加入したことすら忘れていたサブスクリプション。ベンダーと数日間やり取りする暇がないために自動で値上がりしてしまう更新契約。

彼らの洞察は、スタートアップには「より優れたダッシュボードが必要だ」というものではありませんでした。ダッシュボードはすでに存在します。しかし、問題が見えても、それを修正することとは全くの別物であるため、結局無視されてしまいます。チームが作りたかったのは、無駄を可視化するだけのツールではありません。実際に手を下してくれるツールでした。メールの下書きを作成し、交渉を行い、週末を跨いでもタスクを継続し、完了した時にだけ通知を送ってくれるような存在です。

彼らが常に立ち返っていたのは、「優秀なCFOは単にレポートを渡して待つようなことはしない」という考え方でした。優れたCFOなら自分で事態を収拾し、重要な局面で報告し、確実にやり遂げるはずです。

LEGRは、これまでは雇う余裕がなかったとしても、誰もが喉から手が出るほど欲しかったCFOなのです。

LEGRができること

このプロダクトには3つの役割があります。

1つ目は、AI利用料の無駄を排除することです。モデルのルーティング設定が最適でなく、目に見えないところでコストが積み重なるパターンです。安価なモデルで同じ結果が得られるはずなのに、高コストなモデルが使われている場合や、アイドル状態のクレジット、忘れられたバッチ処理などを検知します。これらは会話の中ではなくログファイルに潜んでいるため、誰も気づきません。
2つ目は、SaaSの過剰導入を抑制することです。スタートアップはツールを増やしがちです。その中には、すでに退職したメンバーや不要になったワークフローのために、契約やIDが残り続けているものがあります。LEGRは請求書と実際の利用状況を照合することでそれらを発見し、どのダッシュボードもできなかった「自律的な更新交渉」を、必要な日数をかけて行います。
3つ目は、経費規定への準拠です。すべての取引を規定と照らし合わせてスコアリングし、問題がなければ静かに見守り、人間の判断が必要な場合にのみアラートを出します。

創業者にとっての体験はこのようなものです：メッセージが届きます。「更新時期が近づいています。交渉しますか？ Y/N」。彼らがYと返すと、3日後に追伸が届きます。「完了しました。4,140ドル節約しました」。

たった3文字の返信だけで、本来なら40時間かかったであろうやり取りが完了したのです。

その背景にある思考

チームが解決すべきアーキテクチャ上の問いはこれでした。「数秒で終わる仕事」と「数日かかる仕事」は異なる問題であり、同じように扱うべきではないということです。

取引がポリシーに違反しているかを確認するのは、高速でステートレスなタスクです。実行すればすぐに答えが出るからです。しかし、ソフトウェアの更新交渉はステートレスではありません。何日もかかります。ベンダーは彼らのペースで返信してきます。相手の返信内容に応じて、次のメッセージを変える必要があります。システムは、処理の途中で再起動されても、状態を維持できなければなりません。

チームはこれら2種類の作業を明確に分離しました。高速で完結するタスクは短い処理として実行し、長期にわたる交渉は、それぞれ固有のメモリとスレッド履歴を持ち、どの交渉カードを使い、何が残っているかを理解している永続的なプロセスとして構築しました。

各交渉プロセスは状態ファイルを持ちます。現在のラウンド、全履歴、既に行った議論などを保持します。ベンダーが「上司に確認します」と返信した場合、システムはそれを「承諾」でも「拒否」でもなく「時間稼ぎ」と適切に分類し、忍耐強く対応しなければなりません。この分類器の作成が、構築作業の中で最も試行錯誤を要した部分だとチームは語ります。

しかし、最も困難だったのは技術的な問題ではなく、「抑制」でした。

最初のバージョンのインターフェースは、イベントのたびにメッセージを送っていました。しかし1時間もしないうちに、それは「ノイズ」になってしまいました。常に通知が来るものは、人間は読むのをやめてしまうからです。修正案として、3段階のメッセージングシステムを導入しました。何も問題がない時は沈黙を守り、知るべき進展がある時だけ情報を共有し、人間の判断が必要な時だけ実際に通知を送るという仕組みです。「いつ話さないでおくか」を知ることこそが、このプロダクトにおいて最も重要な設計選択でした。

彼らが最も誇りに思うこと

彼らがステージでデモした瞬間です。実行中の交渉プロセスを途中で停止させ、再起動し、状態ファイルを読み込んで中断したところから完璧に再開する様子。永続的ステートは機能説明ではなく、リアルタイムで証明されました。

創業者が3単語をタイピングし、システムが数日間動き続け、最後の一通で交渉が完結する。これは単なるデモ用フローではなく、設計通りに動くプロダクトそのものでした。

105人の参加者。38のプロジェクト。36時間のイベント。私たちはその週末に何が生まれたかを追いかけてきましたが、彼らの思考の質が注目を集め続けています。

ちなみに、私たちもSaaSの過剰導入問題は身をもって知っています。「Enter」は、製品をリリースするために7つのツール（デザインエディタ、バックエンド、データベース、デプロイ、コラボレーションレイヤーなど）をバラバラに契約する必要がないように作られました。ひとつのサブスクリプション、ひとつのプラットフォーム。忘れられたサブスクリプションを排除するプロジェクトを取り上げている私たちが言うのもなんですが、その皮肉は十分に理解しています。

LEGRがこのシリーズで取り上げられたのは、問題が本物であり、解決策が具体的であり、チームが「自律エージェント構築の難しさは自動化そのものにあるのではなく、いつ一歩引いて人間を介入させるかを知ることにある」という重要なことを理解していたからです。設計思想としての「抑制」。それは耳にする以上に希少な才能です。

これから

短期的には、ベンダーの管理画面に直接ログインし、スクリーンショット付きの証跡を残して解約処理を実行するプロセスを実装する予定です。複数の交渉を共通のインテリジェンス層で共有し、一つの交渉での勝利を次の交渉への武器にする。創業者の好みやリスク許容度、バーンレートに基づいた永続的なモデルの構築などが見込まれます。

長期的には、ファイナンスはあくまで入り口です。高速なタスク用エージェントと、数日かかる仕事のための永続的プロセスという同じアーキテクチャは、法務オペレーション、ベンダー管理、人事コンプライアンスにも応用できます。チームはこれを「スタートアップが最初に接続し、財務担当者を雇う直前まで使い続けられる最後のツール」と表現しました。

そのような野心こそが、プリンストンでの週末にふさわしいものです。

これまでのエピソードはこちら： → Vol. 1 — Heritage in Pixels → Vol. 2 — Terra Zone AI *→ Vol. 3: *reAgent *→ Vol. 4: *TaleTailor