MCPの長時間タスクを士業事務所で回す途中経過と承認を記録に残す7手順

MCPの長時間タスクとは、完了まで時間のかかる処理を受付番号で追う仕組みのことです。

AIが会計ソフトや文書管理システムを操作する処理は、数秒で終わるものばかりではありません。月次データの一括取り込みや、過去の契約書の一括検索のように、数分から数時間かかる処理を任せたとき、途中経過がどこにも残っていないと、あとから「何が起きたのか」を説明できなくなります。本記事では、MCPに用意された長時間タスクの仕組みを、事務所の運用に引き直して、記録と承認の置き場所を七つの手順で整理します。本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁の公表資料で確認しています。MCP仕様の記述は、プロトコルの公式サイトに掲載された2026年7月28日版の変更点一覧に基づきます（出典: Model Context Protocol Key Changes 2026-07-28）。

接続の状態を持たない設計への変更そのものは、すでに別の記事で扱いました。ここでは、その変更とセットで動く長時間タスクと、途中での確認依頼に絞って書きます。

MCPの長時間タスクが2026年版で作り直された背景

2026年7月28日版の仕様では、これまで中核仕様の中にあった実験的なタスク機能が、公式の拡張機能へ移されました。名前はio.modelcontextprotocol/tasksで、結果を待ち続けるtasks/resultという呼び出しをやめ、tasks/getによる問い合わせに置き換えています。クライアントからサーバへ入力を返すtasks/updateが加わり、tasks/listは削除され、サーバが利用者の事前指定なしにタスクの受付番号を返せるようになりました（出典: Model Context Protocol Key Changes 2026-07-28）。

拡張機能の概要ページは、この仕組みが必要になる場面を説明しています。処理が長くなると、通信の途中にある機器や利用側の制限で接続が切れやすくなります。そこで、サーバは最終結果の代わりに、耐久性のある受付番号（taskId）を返し、クライアントが後から状態を問い合わせる形にします。クライアントが落ちたり再起動したりしても、同じ番号で問い合わせを再開できると説明されています（出典: MCP Tasks 拡張機能の概要）。

タスクの状態は五つです。作業中を示すworking、クライアントの入力待ちを示すinput_required、完了のcompleted、失敗のfailed、取り消しのcancelledです。このうち完了、失敗、取り消しの三つは終端の状態で、いったん到達すると以後は変わらないとされています（出典: MCP Tasks 拡張機能の概要）。サーバは作業を始めるときに、ttlMsとpollIntervalMsという二つの値を添えて返します。前者は保持期間の目安、後者は問い合わせの間隔の目安として扱います。

もう一つ、同じ版で加わったのが、途中で追加の入力を求めるための複数往復の仕組みです。サーバは従来のようにクライアントへ直接問い合わせを送るのではなく、結果の形で追加入力を求める旨を返し、クライアントが入力を添えて元の要求を出し直します。この結果の型がInputRequiredResultで、要求の中身はinputRequests、サーバが次回に備えて持たせる文字列はrequestStateと呼ばれます。この方式は、prompts/get、resources/read、tools/callの三つの要求で使えるとされています（出典: MCP Multi Round-Trip Requests）。

事務所の側から見ると、この二つの仕組みは、AIが長い処理を進める途中で「人に確認を取る」場面を、仕様の中に正式に置いたものと読めます。確認の依頼が来る場所、それに誰がどう答えたかを残す場所を、事務所があらかじめ決めておけるかどうかが、本記事の中心です。

長時間タスクの記録と承認を事務所に組み込む7手順

手順は、導入を検討する段階から、運用開始後の点検までの流れで並べます。各手順に、何を決め、何が残るかを添えます。

手順1は、どの処理を長時間タスクとして許すかを、業務単位で決めることです。月次試算表の一括生成、過去の顧問契約書の横断検索、登記関連書類の一括下書きのように、時間がかかる処理を洗い出し、それぞれについてAIに任せる範囲と有資格者の判断が入る箇所を一行で書きます。この一覧が、後の手順で承認を置く位置の根拠になります。

手順2は、接続先のサーバがタスクの仕組みに対応しているかを、導入前に文書で確認することです。サーバは自分の対応状況をserver/discoverで公開し、クライアントは要求ごとに自分の対応機能を伝える設計です。拡張機能の概要ページは、サーバがクライアントの対応を確かめずにタスクを返してはならないという趣旨で、返す前の確認を求めています。また、利用側の対応状況はクライアントごとに異なるとして、対応表を参照するよう案内しています（出典: MCP Tasks 拡張機能の概要）。事務所が使う製品がどちらの側にあるかを、ベンダーの資料で確かめます。

手順3は、受付番号の保管先と、問い合わせの担当者を決めることです。受付番号は、クライアントが再起動しても問い合わせを再開できる耐久的な手がかりですが、番号そのものが案件の情報とひもづきます。事務所の案件管理に、番号、開始日時、依頼した人、対象の顧問先、処理の種類を一行で残す欄を作ります。番号だけが担当者のメモアプリに散らばる状態は、あとで追えなくなります。

手順4は、入力待ちの状態になったときの対応者と期限を決めることです。拡張機能では、タスクがinput_requiredになると、問い合わせの応答にinputRequestsが含まれ、クライアントがtasks/updateで答える設計とされています（出典: MCP Tasks 拡張機能の概要）。つまり、AIが長い処理の途中で顧問先への送付の可否や書き換えの範囲を尋ねてくる場面が、仕様上の通常の動きとして起こり得ます。これに誰が答えるのか、答えは有資格者に限るのか、担当者が不在のときは止めるのか、を先に決めます。

手順5は、承認の記録を、AIの画面の外にも残すことです。入力待ちへの回答は、クライアントの画面の中で完結することが多く、画面を閉じるとログが読めなくなる製品もあります。そこで、承認した人、時刻、承認した内容の要約、対象の受付番号を、事務所側の案件記録に一行で転記します。記録の粒度は、全文ではなく、誰がどの範囲を許したかが分かる程度で足ります。

手順6は、取り消しの扱いを運用に書いておくことです。拡張機能には、取り消しを要求するtasks/cancelがあり、サーバは受け付けたことを返しますが、取り消しは協調的な動作とされ、サーバが作業を止める義務を負うわけではありません（出典: MCP Tasks 拡張機能の概要）。取り消しを押したのに、書き込み済みのデータが残っていた、という状況を想定して、取り消し後に結果の確認と手戻りの手順を行う、と規程に書いておきます。

手順7は、完了したタスクの結果を、有資格者が一次資料と照合してから確定することです。タスクがcompletedになっても、それは処理が終わったことを示すだけで、結果が正しいことの保証ではありません。会計データなら元の帳票と、条文を引いた書面ならe-Gov法令検索の原文と、一つずつ突き合わせます。照合した人と日付を、手順3で作った欄に追記します。

ここで、手順1から手順4の設計に使える、依頼文の例を二つ示します。いずれも、実在の顧問先を想起させない仮名で書いています。

あなたは会計事務所の業務補助AIです。A社の月次データ取り込み処理を、長時間タスクとして実行する前に、事務所が決めておくべき項目を洗い出してください。
条件: 対象は仕訳データの一括取り込み。実行中に入力待ちが発生し得る。
出力: (1)開始前に記録する項目 (2)入力待ちが来たときに回答できる人の条件 (3)取り消しが効かなかった場合の確認項目。各項目は一行で書き、条文の引用はしないでください。

以下は、事務所の長時間タスク運用メモの下書きです。抜けている確認工程を指摘してください。
メモ: 処理を開始したら担当者が受付番号を案件欄に控える。入力待ちには手が空いた人が答える。完了したら結果を顧問先に送る。
出力: 有資格者の確認が必要な工程の候補を箇条書きで3つ。断定せず、事務所が検討する論点として書いてください。

どちらの依頼でも、AIの出力は論点の洗い出しにとどまります。事務所の規程に採用するかどうかは、有資格者が判断します。

顧問先の情報をタスクに流す前に、事務所で決めておく三つのこと

長時間タスクは、顧問先の情報が、事務所の端末を離れて、外部のサーバの上で長く保持される時間を生みます。守秘義務と規程の論点は、三つに整理できます。

一つ目は、各士業の守秘義務の条文との関係です。弁護士法第23条は、弁護士又は弁護士であつた者に、職務上知り得た秘密を保持する権利を認め、義務を課しています（出典: 弁護士法第23条）。税理士法第38条は、税理士が正当な理由なく税理士業務に関して知り得た秘密を他に洩らし、又は窃用することを禁じています（出典: 税理士法第38条）。公認会計士法第27条は、正当な理由なく業務上取り扱ったことについて知り得た秘密を他に漏らし、又は盗用することを禁じています（出典: 公認会計士法第27条）。司法書士法第24条は、正当な事由がある場合でなければ、業務上取り扱った事件について知ることのできた秘密を他に漏らしてはならないとしています（出典: 司法書士法第24条）。社会保険労務士法第21条も、開業社会保険労務士又は社会保険労務士法人の社員に、正当な理由なく業務に関して知り得た秘密を他に漏らし、又は盗用することを禁じています（出典: 社会保険労務士法第21条）。

外部のサーバにタスクの状態や結果が保持されることが、これらの条文でいう「漏らす」に当たるかは、サービスの仕組みと契約条件によって評価が分かれ得る論点です。本記事は当てはめを行いません。事務所としては、タスクの結果がどこに、どのくらいの期間保持されるかを、ベンダーに文書で確認することが出発点になります。ttlMsは保持期間の目安として設計された値なので、その値が実際の保持と削除の運用とどう対応するのかも、確認項目に入ります。

二つ目は、個人情報保護法の安全管理と委託先の監督です。同法第23条は、取り扱う個人データの漏えい、滅失又は毀損の防止その他の安全管理のために必要かつ適切な措置を講じることを求めています（出典: 個人情報保護法第23条）。同法第25条は、個人データの取扱いを委託する場合に、委託先に対する必要かつ適切な監督を求めています（出典: 個人情報保護法第25条）。タスクを動かすサーバが事務所の外にある場合、そこを委託先と見るかどうかは、契約の形に左右されます。その整理も、有資格者や法務の担当者が判断する領域です。

三つ目は、途中確認の仕組みが持つ、技術上の注意点を、導入時の質問に変えることです。複数往復の仕組みでは、requestStateがクライアントを通過して戻ってくるため、仕様は、サーバがこの値を攻撃者が操作し得る入力として扱うよう定めています。認可や資源へのアクセスに影響する場合は、改ざんの検知を行い、検証に失敗した値は拒否するとされ、再利用を防ぐために、認証された利用者、短い有効期限、元の要求を示す識別子を含めることが勧められています（出典: MCP Multi Round-Trip Requests）。事務所の側では、実装を確かめる代わりに、状態の改ざん対策の方式と、別の利用者の状態を受け付けない設計かどうかを、ベンダーに質問する形にしておくと、現実的です。認可まわりの確認項目は、MCP接続のセキュリティ要件事務所が審査する7つのチェック項目にまとめています。

事務所規程への落とし方は、次のような運用例が考えられます。ここに挙げるのは規範ではなく、規程の書き方の一例です。

長時間タスクで処理する対象は、事務所が定めた業務の一覧に載せたものに限る、という趣旨の条項
入力待ちへの回答は、有資格者または事務所が指名した者が行い、回答の内容を案件記録に残す、という趣旨の条項
取り消しを行った場合は、書き込み済みのデータの有無を確認し、結果を記録する、という趣旨の条項
タスクの完了後、結果は一次資料と照合してから顧問先へ提供する、という趣旨の条項

規程は、一度作って終わりではなく、製品の仕様や条件が変わるたびに点検の対象になります。点検の回し方は、事務所の生成AI利用規程を四半期で点検する7手順で整理しています。

長時間タスクで起きやすい失敗と、手順への戻し方

実際に起こり得る失敗を、三つのシナリオで考えます。いずれも仕様の動きから想定した例で、特定の事務所の事例ではありません。

一つ目は、入力待ちが放置されるケースです。月次データの取り込み中に、AIが未登録の勘定科目を新設してよいかを尋ねる状態でタスクが止まります。担当者は、処理が動いていると思い込み、そのまま数日が過ぎます。決算の直前に初めて気づき、作業が間に合わなくなります。手順4で、入力待ちの通知先と、回答までの期限を決めておけば、止まったことに気づく仕組みが生まれます。

二つ目は、取り消しが効いたと誤解するケースです。担当者が誤った顧問先に対して処理を始めたことに気づき、取り消しを押します。画面は取り消し済みと表示されますが、拡張機能の説明にあるとおり、取り消しは協調的な動作です。サーバは受け付けても、すでに書き込まれたデータが残ることがあります。手順6のように、取り消し後に結果を確認する工程を決めておくと、データの混在に早く気づけます。

三つ目は、受付番号が担当者の手元にしか残らず、退職や異動で追えなくなるケースです。耐久的な番号が残っていても、誰が何のために開始したのかが分からなければ、結果を読んでよいのか判断できません。手順3の案件欄に番号と目的をひもづけておくことが、そのまま引き継ぎの資料になります。

三つの失敗に共通するのは、AIの画面の中だけで完結していた情報が、事務所の記録に出てこないという点です。仕様が整えたのは、途中経過を問い合わせる手段と、入力を返す手段です。それを事務所の案件管理につなぐ作業は、事務所が行います。

導入に必要な費用・工数・体制の考え方

長時間タスクの仕組みそのものに、追加の利用料が決まっているわけではありません。拡張機能は、公式の仕様の一部として公開されており、対応する製品でどのような料金が発生するかは、ベンダーごとの契約条件によります。事務所が見積もるべきは、製品の料金よりも、運用の工数です。

工数は、大きく三つに分かれます。最初に、手順1の業務一覧と手順4の回答者の決め方に、事務所内の合意の時間が要ります。次に、手順3と手順5の記録欄を既存の案件管理に追加する作業です。新しいシステムを入れなくても、既存の案件管理の項目を足すだけで始められます。最後に、四半期の点検で、タスクの記録を抜き取って読む時間です。

体制では、運用の担当者を一人置き、有資格者が回答者になる、という分担が考えられます。担当者は記録の整備と点検を受け持ち、入力待ちへの回答と最終確認は、有資格者が受け持ちます。小規模な事務所では、代表者が両方を兼ねる形になりますが、その場合でも、記録を残す行為だけは別の工程として手順に書いておくと、後から説明しやすくなります。

非同期処理が前提になったあとの論点

2026年7月28日版の仕様は、接続の状態を持たない設計、複数往復の確認、長時間タスクの拡張機能という、三つの変更を同時に進めました（出典: Model Context Protocol Key Changes 2026-07-28）。これらが組み合わさると、AIの処理はその場で終わる呼び出しから、あとで結果を受け取る依頼へと性格を変えていきます。論点になるのは、依頼から結果の受領までのあいだ、誰が責任を持って状態を把握するのかという点です。

処理が非同期になるほど、事務所の内部統制は、画面を見ている時間ではなく、記録が残る仕組みに依存する度合いが高まります。承認と記録を手順の中に置くことは、AIを遅くするためではなく、あとから説明できる形で任せるための準備です。ベンダー側でも、拡張機能の対応状況は製品ごとに異なる段階にあります。今後は、事務所が選ぶ製品が、どの機能にどこまで対応しているかを、導入時の質問票に入れる運用が論点になります。

よくある質問

長時間タスクは事務所として使う前提になりますか

使うかどうかは、事務所が接続する製品の対応によります。拡張機能はサーバと利用側の双方が明示的に対応して初めて働く設計であり、片方が未対応なら、従来どおりの動作が続きます（出典: MCP Tasks 拡張機能の概要）。

受付番号を知られると、他人が結果を読めてしまいますか

仕様の公開資料からは、この点の扱いを断定できません。事務所としては、受付番号と利用者の認証がどうひもづいているかを、ベンダーに文書で質問する運用が考えられます。

入力待ちに誰が答えても構いませんか

仕様は回答の手段を定めており、回答者の資格までは定めていません。誰が答えるかは事務所が決める事項で、有資格者に限る運用や、担当者の指名制にする運用があります。

取り消しを押せば処理は止まりますか

取り消しは協調的な動作とされ、サーバは受け付けても、作業を止める義務を負うわけではありません（出典: MCP Tasks 拡張機能の概要）。取り消し後の確認工程を設けておくことが、運用上の論点になります。

旧来の形式のサーバは、いつまで使えますか

仕様は、機能の廃止について、最低でも一定の猶予期間を置く方針を公開しています（出典: Model Context Protocol Key Changes 2026-07-28）。個別の製品の更新予定は、ベンダーの公表資料で確認します。

小規模な事務所でもここまで記録が必要ですか

必要な粒度は事務所の規模で変わります。最小限は、受付番号、開始した人、処理の種類、承認した人、照合した日付の五項目を一行で残す形です。それ以上は、扱う顧問先の数と取り扱う情報の重さに合わせて、事務所が決めます。

参考文献

※士業のチカラでは、生成AIの導入支援から運用最適化まで、貴事務所の業務に合わせたカスタマイズ提案を行っています。無料相談（30分）も実施中ですので、お気軽にお問い合わせください。
https://shigyonochikara.jp/contact/

本記事の作成体制について

本記事は士業のチカラ編集部が、公表されている一次情報のみを根拠に作成しています。法令の条文はe-Gov法令検索の原文で、行政の見解は各府省庁の公表資料で、それぞれ確認したうえで記載しています。引用元は本文中および参考文献にすべて明示しています。

本記事には特定の資格者による監修は入っていません。個別の事案について法令の当てはめや手続の可否を判断する必要がある場合は、当該分野の有資格者にご相談ください。本記事は一般的な情報提供を目的としたものであり、個別具体的な法律判断・税務判断・労務判断を提供するものではありません。

記載内容に誤りを見つけられた場合は、お問い合わせよりご指摘ください。確認のうえ速やかに訂正し、訂正履歴を記事内に残します。編集方針の詳細は運営者情報をご覧ください。