Basis は会計士のために設計された AI エージェントを構築しています。長いホライズンで複雑な会計ワークフローをバックグラウンドで自律的に完了し、レビューできる状態の成果物を返すため、会計チームは判断業務とクライアント対応に集中できます。

これらのエージェントは、月次決算、法人税およびパートナーシップ税の申告、監査の計画と実地作業など、大手会計チームが抱える数時間規模で重要度の高い業務を引き受けます。Basis は創業初日から Cursor 上で会社を築いてきました。エージェントが読み込むコンテキスト (プロンプト、スキル、指示、ツールの説明) をコードと同じ厳密さで扱っており、それを読み、手を入れる場が Cursor なのです。

#単一のプロンプトには還元できない業務

長いホライズンとは、単にエージェントが数時間動き続けることを指すのではありません。1つのトラジェクトリの中で数百もの判断が下され、後続のステップが先行するステップに依存することも多い、ということです。システムは関連する状態を保持し、ツール呼び出しの結果を取り込み、失敗から回復しなければなりません。しかもそれは、単一のコンテキストウィンドウに収まりきらない量の情報にまたがることもあります。エラーは積み重なっていきます。初期の誤りがその後のリサーチ、計算、ツール呼び出し、アーティファクトに影響を及ぼす一方で、最終結果を見ても問題がどこで生じたのかは分からないことがあります。

会計業務では、次の3つの理由からこれがいっそう難しくなります。

1. 多くの成果には、安価で客観的なテストが存在しない。
2. 実際の本番業務から得られる正解データの例は、作成にコストがかかり、規模を拡大しにくい。
3. 最終的な成果を生み出し、レビューするまでに数時間から数日かかることがある。

最終結果が正しくても、その裏に信頼できないプロセスが隠れている場合があります。エージェントが調査上の根拠を欠いたまま正しい納税申告書にたどり着いたり、出典を保持しないまま正しい数値を抽出したり、汎用性のないプロセスで使えるワークブックを作り上げてしまうこともあります。成果の評価は依然として重要ですが、実行にはコストがかかり、長いトラジェクトリの中で重要な意味を持つすべての判断を説明できるわけではありません。

#コンテキストは本番の入力である

エージェントの最終的な出力は、システムの一部にすぎません。その挙動は、作業の過程で受け取るコンテキスト、すなわち指示、ドメイン知識、例、ツールの説明、スキル、メモリ、その他の実行時情報に左右されます。こうしたコンテキストは自然言語で書かれているため、エンジニア自身が読む必要があります。

従来のプログラムは、ファイルの整理具合にかかわらず、同じ有効なコードを常に同じように解釈します。しかし言語モデルでは、コンテキストの構成や言い回しによって、モデルが次に取る行動が変わります。曖昧な一文、埋もれた例外、誤解を招く例が、本番環境での挙動を変えてしまうこともあります。コンテキストファイルを生成し、読まないままリリースすることは、本番環境におけるリスクです。

#挙動仕様が基準を明示する

挙動仕様 (behavior spec) とは、特定の状況でエージェントに期待される繰り返しの振る舞いを定義した Markdown ファイルです。記録されたトラジェクトリをレビューする人やジャッジに向けて書かれるもので、プロンプトではなく、エージェントに提示されることもありません。

役に立つ仕様は、その挙動がどんなときに適用されるのか、エージェントはどの証跡を検査すべきか、どのような判断を下すべきか、その判断の後にどのアクションを取るべきか、証跡が不完全な場合はどうするか、そして失敗とはどのような状態かを明確にします。目指すのは、手順を一つひとつ指定しなくても挙動をジャッジできるようにすることです。

ジャッジは、仕様、観測可能なトラジェクトリ、そして証跡 (ツール呼び出し、アーティファクト、取得したソース、判断の記録) を受け取り、true、false、NA のいずれかを返します。これにより、チームはタスク全体の完全な正解がなくても、プロセスのうち選んだ部分を評価できます。

#エージェントを練り直す場所、それがCursor

Basisは、エージェントの構築と改良にCursorを使っています。あるエンジニアは、Markdownで書かれた挙動仕様を開いています。一文ずつ検査し、曖昧すぎないか、壊れやすくないかをモデルに尋ね、その箇所を書き直し、仕上がった文書を同じウィンドウでプレビューする。エージェントが実際に目にするプロンプトとコンテキスト (スキル、指示、ツールの説明) の改良にも、同じ環境を使っています。

その作業の場としてCursorが選ばれる理由:

• 本物のエディタであること。コンテキストや仕様の文言をそのまま読み、書き直せます。
• Markdownプレビュー (編集とライブプレビューを同時に) 。Basisの共同創業者Mitch Troyanovskyは、仕様やスキル、その他のMarkdown文書を反復するうえで過小評価されている差別化要因だと語っています。
• テキストと同じ環境で、モデルと直接やり取りできること。
• 反復しながら手軽にモデルを切り替えられること。
• 並べて表示: ファイルとエージェントウィンドウをひとつのループとして回せること。エージェントウィンドウは誰でも持っています。違いは、コンテキストを検査して変更できるかどうかです。

#開発ループ

Basis のエンジニアは、Cursor で挙動仕様 (behavior spec) を記述し、改良していきます。エージェントは Basis のランタイム上で実行され、ジャッジが記録されたトラジェクトリを仕様と照らし合わせて評価します。

1. チームが、測定する価値のある繰り返し発生する挙動について合意します。
2. エンジニアが Cursor で挙動仕様を記述、または改良します。
3. エージェントが本番環境で作業を行い、トラジェクトリが記録されます。
4. ジャッジが各挙動を仕様と照らして評価し、true、false、NA のいずれかを返します。
5. false という判定は、意図した挙動とランタイム実装との間のギャップを示します。
6. チームはランタイムのコンテキスト、ツール、プロンプト、または実行フレームワークを更新します。その文言は Cursor で修正されます。
7. チームはエージェントを再度実行し、挙動が改善したかどうかを測定します。

仕様とランタイムは分離されたままです。仕様が基準であり、エージェントが一貫してそれを満たすまで実装を変更していきます。

この挙動仕様のアプローチは、Basis が会計向けの本番エージェントを構築してきた経験から生まれました。Basis と Braintrust はこれをオープンスタンダードとして公開しており、他のチームも同じ汎用的な形式でエージェントの挙動を定義・評価できます。

#成果物そのものが証明

本番環境での実際の働きは、次のようなものです。

• Basis のエージェントは、1つの成果物に対して5時間以上の作業を行います。
• Form 1065 のパートナーシップ申告では、人手なら約30〜40時間かかる作業を、Basis のエージェントは約6〜7時間で完了できます。
• Basis は上位25社の会計事務所の40%に、さらに広く主要な会計事務所に信頼されています。

最も強力な証明は成果物そのものです。エージェントは長い軌跡 (トラジェクトリ) にわたって数多くの意思決定を行い、プロの会計士がレビューし実際に使う成果を届けています。

エージェントがより長く、より重大な仕事を担うようになるにつれ、そのコンテキストは本番の入力そのものになります。エンジニアはそれを検査し、理解し、修正する必要があります。

Basis はそのコンテキストを Cursor で維持しています。挙動仕様 は、定めた期待値を明示します。Braintrust は、それらの挙動が実際の軌跡に現れたかどうかを評価します。失敗からは、ランタイムの何を変えるべきかがチームに見えてきます。