会計AIのBasis、Cursorを用いた長時間自律エージェントの開発手法を公開　税務申告を最大6倍高速化

要点

• 会計特化型AIを開発する北米のBasisが、AIコードエディタ「Cursor」を活用したエージェント開発手法を公開した。

• 米国パートナーシップ税務申告書（Form 1065）の作成業務において、人間の作業時間30〜40時間を6〜7時間に短縮し、最大6倍の高速化を実現した。

• 何百もの判断が連鎖する長時間の作業に対応するため、期待される挙動を定義する「ビヘイビア・スペック」を導入し、プロセスの妥当性を検証している。

• 自然言語で書かれた指示やスキルなどのコンテキストをコードと同等の本番入力として扱い、Cursor上で編集・推敲を行っている。

• BasisとBraintrustは、このビヘイビア・スペックの枠組みをオープンスタンダードとして一般公開した。

• Cursor Blogは2026年9月4日、会計向けAIエージェントを開発する北米企業Basisの取り組みを紹介する記事を公開した。Basisは創業当初からCursorを開発環境として活用しており、月次決算や税務申告、監査といった数時間規模の複雑な会計ワークフローを自律的に遂行するエージェントを構築している。米国のトップ25会計事務所の40%に採用されるなど、実務現場での導入が進んでいるという。

単一プロンプトでは解決できない長時間タスクの課題

Basisが手掛ける会計エージェントは、月次決算や法人・パートナーシップの税務申告書作成、監査計画および実査など、専門性が高く失敗の許されない業務を担っている。これらの業務ではエージェントが1つの成果物に対して5時間以上にわたり稼働し、一連の流れの中で何百もの意思決定を行う。

こうした長時間の処理（ロングホライズン）では、後続のステップが初期の判断に依存するため、初期段階での小さな誤りがその後の調査、計算、ツール呼び出し、生成物へと連鎖的に波及するリスクを抱えている。

さらに、会計分野におけるエージェント開発には以下の3つの難しさがあると説明されている。

1. 安価で客観的なテストの欠如: 多くの出力結果に対して、低コストで客観的に正誤を判定できるテストが存在しない。
2. 正解データ作成の高コスト性: 実際の現場業務に基づく正解データ（グラウンドトゥルース）の作成が高コストであり、大規模な用意が難しい。
3. 検証に要する時間: 最終結果の生成とレビュー自体に数時間から数日単位の時間を要する。

また、出力された税務申告書が形式上正しく見えても、一次資料の確認を怠っていたり、数値の参照元が保持されていなかったり、汎用性のない手順でワークシートが作成されていたりするなど、プロセスに信頼性の欠如が潜んでいる場合があるという。そのため、最終結果の評価だけでなく、一連の意思決定プロセスそのものを評価する仕組みが必要とされていた。

コンテキストを本番コードと同等に管理するアプローチ

Basisでは、エージェントに与える指示、専門知識、具体例、ツールの説明、スキル、メモリといった自然言語の情報を「本番環境への入力（プロダクション・インプット）」と位置づけている。

従来のプログラムとは異なり、言語モデルを基盤とするシステムでは、自然言語によるコンテキストの構成や言葉遣いの違いがモデルの振る舞いに直接影響を与える。曖昧な記述や見落とされやすい例外規定、誤解を招く具体例が含まれていると、本番環境での動作リスクにつながるため、エンジニア自身がコンテキストを注意深く確認し修正する必要がある。

Basisのエンジニアは、これらのコンテキストや仕様の作成・推敲をCursor上で行っている。Cursorを採用している理由として、以下の点が挙げられている。

• 自然言語のコンテキストや仕様書の文言を詳細に読み、編集できるエディタ機能
• 編集と同時に仕上がりを確認できるMarkdownプレビュー機能
• テキストと同じ作業環境内でAIモデルと直接対話しながら推敲できる点
• 検証時のモデル切り替えの容易さ
• ファイル編集画面とエージェント画面を並行して確認できる作業ループ

Basisの共同創業者であるMitch Troyanovsky氏は、Markdownプレビュー機能について、仕様書やスキル文書を反復的に改善する上で過小評価されている大きな強みであると述べている。

「ビヘイビア・スペック」によるプロセスの検証と開発ループ

プロセスの信頼性を担保するため、Basisは「ビヘイビア・スペック（行動仕様書）」と呼ばれる手法を考案した。これはエージェントに直接入力するプロンプトではなく、エージェントが実行した一連の行動や判断の記録（トラジェクトリ）を人間や評価システム（ジャッジ）が検証するためにMarkdown形式で定義された基準である。

スペックには、その挙動が適用される状況、エージェントが確認すべき証拠、下すべき判断、実行すべきアクション、証拠が不完全な場合の対処法、失敗とみなす基準などが明記される。

Basisにおける開発サイクルは、以下の手順で反復される。

1. 測定対象とする振る舞いを決定する。
2. エンジニアがCursor上でビヘイビア・スペックを作成または修正する。
3. エージェントが本番環境で業務を実行し、行動履歴（トラジェクトリ）を記録する。
4. 評価器がスペックと照合し、ツール呼び出しや参照ソースなどの証拠をもとに「true」「false」「NA」の判定を下す。
5. 「false」判定が出た場合、想定した挙動と実装とのギャップを特定する。
6. Cursorを用いて、コンテキスト、プロンプト、ツール、実行フレームワークの文言を修正する。
7. 再度エージェントを実行し、挙動の改善を測定する。

このアプローチにより、最終的な正解データが完全に揃っていなくても、特定の重要なプロセスごとに妥当性を評価することが可能になる。Basisと評価プラットフォームを提供するBraintrustは、他の開発チームも同様の形式でエージェントの挙動を定義・評価できるよう、このビヘイビア・スペックの仕様をオープンスタンダードとして共同公開した。

Troyanovsky氏は「正しい税務の回答であっても、好ましくないプロセスが隠れていることがある。申告書が正しいかだけでなく、エージェントが一次資料を確認したかどうかを知る必要があり、それを判定するのがスペックである」とコメントしている。

業務時間の大幅短縮と導入実績

公開された事例によると、Basisのエージェントは会計チームが判断や顧客対応に専念できるよう、レビュー可能な完成度の成果物を自律的に作成している。

実際の現場において、米国パートナーシップ税務申告書（Form 1065：複数人で共同出資するパートナーシップ企業向けの申告書類）の作成業務では、人間が通常30〜40時間かけていた作業をエージェントが約6〜7時間で完了させており、最大で約6倍の高速化を達成した。現在、全米トップ25の大手会計事務所のうち40%や、その他の主要な会計事務所において実務に活用されている。