10日かかる業務をAIエージェントに任せる：Arcaの顧客ごとの記録と安全装置

エージェントが「何時間動き続けられるか」は、長い仕事を任せられるかの目安としてよく話題になります。ところが業務の長い仕事は、ずっと動き続けるものばかりではありません。顧客の返事を待ち、別の担当者に回り、数日後に再開します。米国の資産運用会社Arcaの事例は、この「動いている時間は短いが、終わるまでが長い」仕事をエージェントに任せる方法を、顧客ごとの記録、安全装置、変更の記録、毎晩の改善の4点で具体的に語っています。

元になったのはLatent Spaceが10月31日に公開したインタビュー記事です。2026年のAI Engineer New Yorkの会場で、ArcaのAIプラットフォームのチームを率いるAman Singh氏が答えています。以下の数値や仕組みは、記事と書き起こしにあるSingh氏の説明によるもので、Arcaは性能や失敗率の数値を出していません。

Arcaはどんな会社か#

Arcaは資産運用の助言、税や保険、相続の計画を顧客に提供する投資助言会社です。2026年6月25日のWealthManagement.comと6月26日のInvestmentNewsの報道によると、預かり資産は10億ドルを超え、従業員は28人で、そのうち9人が助言担当者でした。調達額はVenrockが主導した1550万ドルのシードと、General Catalystが主導した4850万ドルのシリーズAを合わせて6400万ドルです。

ソフトウェアを売る会社ではなく、自分たちが助言会社として顧客を持っている点が、この事例の前提です。顧客がAIと直接やり取りすることはなく、窓口はいつも人の助言担当者です。出資したGeneral Catalystの説明では、準備や事務の作業の大半をエージェントが受け持ち、助言担当者は最後の5〜10%、人の関係が価値を生む部分を受け持つとしています。

10日かかるのは待ち時間と引き継ぎがあるから#

Singh氏は金融の仕事は「長くかかる」けれども「長く動き続ける」わけではないと説明しています。例に挙げたのは顧客から10万ドルの税金の請求が来たとメールで相談される案件です。今の資産の配分を調べ、どこを売れば10万ドルを最も有利に用意できるかを考え、担当者が確かめて売買を実行するまでに、最長で10日かかります。その間には「止まっては進み、間に何人もの担当者がいて、判断の分かれ目と引き継ぎがたくさんある」と述べています。

この形の仕事では1つのエージェントが会話を続けて最後までやり切る、という前提が成り立ちません。途中で電話がかかってくれば、それは進行中のどの処理にもつながっていない新しい知らせです。7番目の段階を受け持つ人は、最初の日にはまだ呼ぶ必要がありません。エージェントを動かす仕組み（ハーネス）は、作業を再開するたびに「今どこまで来ているか」を取り戻せなければなりません。

状態は会話ではなく顧客ごとの記録に持たせる#

Arcaの答えは顧客ごとの記録を社内に持つことでした。この記録には、それぞれのエージェントが書き足していきます。記録には、今何が起きていて何に対応しようとしているかと、これまでに何があったかが入っています。さらに、この数日ですぐに必要なことと長い目で追っていること、誰が何を受け持ち、どの人がどの操作に責任を持つかも記録します。

知らせの種類によって、受け取るエージェントが変わります。既に進んでいるメールのやり取りへの返信は、そのスレッドを読んでいる同じエージェントに届く仕組みです。途中で入った電話のように、どの処理にもつながらない新しい知らせには、新しいエージェントが起動します。新しいエージェントは顧客の記録を読み、「今は大きな税金の支払いを進めている」と状況をつかんでから、自分の知らせがその案件に関わるかを判断して記録に書き足します。

もう1つの仕組みとして、Singh氏が「夢を見るような」と呼ぶ振り返りの処理があります。顧客の状況全体を見直して記録を更新するもので、別の箇所では毎日の振り返りと説明しています。適切な人を適切な時に呼べるのは、この長く残る記録と毎日の振り返りがあるからだとしています。

Arcaの設計が扱う問題は、Anthropicが2025年11月26日に公開した長く動くエージェントのハーネスについての記事と同じです。Anthropicの記事は、新しいセッションは前のことを何も覚えていないという前提から始まり、作業の記録のファイルとgitの履歴を残させて、次のセッションがすぐに状況をつかめるようにしました。Arcaの記録はその「次の担当への申し送り」を、作業の単位ではなく顧客の単位で持っている形です。同じ問題を論文の側から扱った例として、長く動くエージェントに「今の理解」を持たせる論文の記事も書いています。

売買や送金はモデルに任せずルールで止める#

Singh氏は「安全のための制限は全て決定的（ルールで判定する）で、判断をエージェントの手から取り上げている」と述べています。例えば記録を残すような単純な道具は、エージェントが自分で実行します。資産の売却や送金は、保管機関（カストディアン）のAPIで技術的には実行できても、人が加わらなければ実行できない設定です。顧客への直接の連絡も、人が加わらなければ行えません。エージェントは分析を終えると、担当者を呼び、見直して調整できる計画を渡します。

そのほかに、Singh氏が挙げた検査は次の4つです。

• データベースに書き込む道具が呼ばれるたびに、速いLLMの呼び出しでその書き込みを検証する
• 外から入るメール、文書、電話の内容は、プロンプトインジェクションの手口が含まれていないかを受け取った時点で調べる
• Web検索やカレンダーの招待のように、データが外へ出るときは、個人情報をルールで調べ、さらに複数の小型モデルの合議で持ち出しの試みがないかを確かめる
• エージェントが作った計画書（PDF）は、口座番号がそのまま入っていないかをルールで、利回りを約束するような規制に反する書き方がないかを小型モデルで調べてから公開する

検査を置く場所について、Singh氏は「能力の端で抑え込み、それより手前では抑えない」という原則を挙げています。上の4つの検査の置き場所を見ると、エージェントに考えさせる部分は広く残し、データが書き込まれる所、外に出る所、顧客に届く所で止める考え方のようです。

計算の扱いもこの原則に沿っているように見えます。エージェント自体はサンドボックスの中にいませんが、計算はサンドボックスに任せる形です。エージェントが書いたデータの問い合わせのコードは、決められた厳密な形式に変換され、コードそのものは捨てられます。エージェントはコードでデータを集計したり加工したりできますが、その形式に対して制限をかけてから、検査済みの形式だけを社内のシステムに届けます。

変更の記録を監査とエージェントの両方に使う#

金融業界の規制で求められるのは、後から何が起きたかを追えることだとSingh氏は言います。Arcaではエージェントのあらゆる操作が、何が変わったか、誰が変えたか、システムのどこから変えたか、いつ変えたかの記録を残します。人が画面で顧客の情報を変えたときも、同じ記録が残ります。

この記録は監査に使うほか、人が画面で何かを変えたときに、エージェントへ変更を知らせるのにも使われています。

自前のハーネスにした理由#

ArcaはAnthropicとOpenAIのモデルを使っていて、今主に使っているのはClaudeです（以前はGeminiを使い、OpenAI、Anthropicの順に移ってきました）。モデルの選択は社内のベンチマークで決めていて、外部のベンチマークで評価の高かったモデルを試したところ、遅すぎて費用もかかり、期待どおりにはいかなかった例も挙げています。

使うモデルは作業の複雑さで段階に分けています。税の分析のような作業には一番重い段階のモデル（Opus級やSonnet級、重いGPTのモデル）を使い、裏で動く多くの作業には軽い段階のモデルを使います。この選択は社内で決めていて、助言担当者が意識することはありません。

ハーネスは社内で作り、特定のモデルに依存しない形にしています。AnthropicのManaged Agentsのような、ハーネスを提供する製品には頼っていません。Singh氏によると、そうした製品の要点は、モデルが何を記憶し、どんな業務の知識を使うかにあります。そこを外に任せると、自社の業務に合わせて作り込む余地を失う、というのが理由です。

自前のハーネスの例として挙げたのが、古い事実への対策です。モデルは2025年の税率の区分を使って分析し、それで完了としてしまうことがあるそうです。Arcaのハーネスは、モデルが金融の推奨を出そうとしているのを検知すると、今日時点で確かめた事実を集めた社内の知識ベースか、Web検索を使うようモデルに促します。

現場の直しを毎晩の改善に回す#

スタッフがエージェントの仕事を直したり取り消したりするときは、必ず理由を書くようにしています。Arcaは自分たちが助言会社なので、スタッフに理由の入力を求められる、というのがSingh氏の説明です。理由はその仕事をしたエージェントの実行記録と組にして保存されます。

毎晩、実際の業務で動いたエージェントの実行記録を集め、その上でメタエージェントを動かして、ハーネスへの変更案を出させます。見つかるのは誤解を招く道具、エラーになった操作、知識ベースに足りない知識などです。ただし、プロンプトを変える前には人のエンジニアが確かめています。エージェントに任せると「小さな直しのたびに、それがプロンプト全体になってしまう」ため、直しを一般化したプロンプトにまとめられないからだとしています。

業務の知識はファイルの形で知識ベースに置かれ、製品の画面の「Knowledge」というタブから、社内の専門家が直接直せます。エージェントは仕事の中で知識ベースを引用するので、知識の誤りが実行記録の分析で見つかり、専門家がその場で直す、という流れができています。

成果の例としてSingh氏が挙げたのは、顧客になる前の相談者の資料を読ませた件です。相談者は今の助言担当者に1500ドルを払っていると話していました。エージェントは資料から相談者が知らなかった手数料を見つけ、その担当者が顧客の利益のために行動する義務（フィデューシャリー）を負っていないことも示しました。

業務の長いタスクに置き換えると#

金融以外の業務に持ち込むなら、Arcaの事例から次の5つを点検の項目にできそうです。これはSingh氏の説明を一般の業務に読み替えたもので、Arcaが他の業種で確かめたものではありません。

点検の項目	Arcaでの形
再開したエージェントは、どこから状況を読むか	顧客ごとの記録。担当、次の予定、長期の予定、責任者を持つ
新しい知らせを、どのエージェントが受けるか	続きの返信は同じエージェント、新しい知らせは新しいエージェント
モデルに判断させない操作はどれか	売買、送金、顧客への直接の連絡は人が行う
検査をどこに置くか	書き込み、外から入るデータ、外へ出るデータ、顧客に届く成果物
現場の直しをどう改善に回すか	理由付きで保存し、毎晩分析し、プロンプトの変更は人が確かめる

社内の申請や問い合わせの対応のように、数日かけて何人もの手を渡る仕事なら、1つ目と3つ目から決めるのがよさそうです。状態の置き場所が決まらないと、エージェントを止めても再開できません。人が行う操作が決まらないと、検査をどこに置くかも決まりません。

分からないこと#

記録をどんな形式で持ち、どう検索しているか、エージェントが記録を誤って書き換えたときにどう気づくかは、インタビューでは語られていません（データを書き込む操作には毎回LLMの検証がかかりますが、顧客ごとの記録への書き込みにも同じ検証がかかるのかは分かりません）。書き込みの検証や持ち出しの検査が、どれだけの誤りを止めたかという数値もありません。案件ごとに何体のエージェントが関わり、モデルの利用にどれだけの費用がかかっているかも公開されていません。