月次決算バッチをAIエージェントに任せる前に知っておきたい、MCP「Tasks」仕様確定の話

顧問先の月次決算チェックや、大量の証憑を突き合わせる作業をAIエージェントに任せてみたいと思ったことがある方は多いと思います。ただ実際に試すと、「処理に数分〜数十分かかる作業を、AIとの接続を保持したまま待たせ続ける」という設計上のネックにぶつかります。接続が切れれば進捗が失われ、サーバーを再起動すればやり直しです。

この長時間実行タスクの扱いが、AIエージェントとツールをつなぐ標準規格「MCP（Model Context Protocol）」の2026年7月28日付の仕様改定で正式に整理されました。本稿執筆時点（2026年7月29日）はまさにこの仕様が確定した翌日にあたります。今回は、何が変わったのか、そして顧問先の業務自動化にどう関係するのかを整理します。

MCPとは何か、簡単に

MCPは、ChatGPTやClaudeのようなAIエージェントが外部のツール（会計ソフトのAPI、社内システム、ファイルサーバーなど）を呼び出すときの「共通の話し方」を定めた規格です。以前このブログで紹介したLINEの領収書自動保存botや銀行明細の仕訳下書きを作る際も、AIにどうツールを呼ばせるかという設計は避けて通れませんでした。MCPはこの部分を規格化することで、AIエージェントとツールの組み合わせを増やしやすくする狙いがあります。

何が変わったのか ― Tasksが「実験的機能」から「正式な拡張仕様」へ

MCPの公式チェンジログによると、2026-07-28仕様での大きな変更点の一つが、長時間実行タスクを扱う「Tasks」機能の再設計です。

Move experimental tasks out of the core protocol and into an official extension (io.modelcontextprotocol/tasks). The redesigned extension replaces the blocking tasks/result method with polling via tasks/get and a new tasks/update for client-to-server input, removes tasks/list, and allows servers to return task handles unsolicited without per-request opt-in.

（筆者訳: 実験的だったTasksをコアプロトコルから切り離し、正式な拡張仕様（io.modelcontextprotocol/tasks）にした。再設計された拡張では、完了まで待たせるtasks/resultをやめ、tasks/getによるポーリングと、クライアントからの入力を受け付ける新しいtasks/updateに置き換えた。tasks/listは廃止し、サーバー側は事前の申告なしにタスクのハンドル（後から状態を確認するための識別子）を返せるようになった）

要するに、「作業を投げたら、あとは好きなタイミングで進捗を聞きに行けばいい」という形に変わったということです。しかも今回の改定ではMCP全体が「ステートレス」な設計に寄せられており（initializeのハンドシェイクや接続単位のセッションIDが廃止されています）、タスクの状態も特定の接続やサーバーインスタンスに紐づかない前提になりました。つまり、タスクを登録したサーバーが再起動しても、状態を引き継げる別のインスタンスが処理を続けられる、という設計です。

旧方式と新方式、実務では何が変わるのか

観点	旧方式（〜2025-11-25仕様、実験的Tasks）	新方式（2026-07-28仕様）
完了の待ち方	tasks/resultが返るまで実質ブロッキング	tasks/getでいつでもポーリング可能
状態の持ち方	接続・サーバーインスタンスに依存しがち	状態は外部化され、別インスタンスからも再開・更新可能
タスクの申告	サーバー側は事前opt-inが必要	求めていなくてもサーバーがタスクハンドルを返せる
処理中の入力	仕組みとして弱い	tasks/updateでクライアントから追加入力を渡せる
クライアントの実装難度	接続を張りっぱなしにする分、タイムアウト設計が難しい	ポーリング間隔を自分で決められる、実装がシンプル

会計事務所の実務に引き直すと、月次決算のチェックのように「20分かかっても構わないが、途中経過は見たいし、担当者のPCがスリープしても処理を続けていてほしい」という作業には、新方式の方が明らかに向いています。逆に、勘定科目の推測のように数秒で終わる処理には、この変更はほとんど関係ありません。

実際に最小構成で挙動を確認してみた

仕様書を読んだだけでは実感が湧かないので、Pythonで新旧方式の違いだけを再現する最小限のスクリプトを書いて動かしてみました（実際のMCP SDKではなく、考え方を再現した概念実証です）。

# 旧方式のイメージ: 完了するまで呼び出し元が待ち続ける
def old_style_blocking_task(work_items):
    for item in work_items:
        process(item)  # ここで数分〜数十分かかる想定
    return {"status": "complete"}

# 新方式のイメージ: 登録したら即座にハンドルを返し、進捗は別途確認する
TASKS_STORE = {}

def new_style_submit_task(task_id, work_items):
    TASKS_STORE[task_id] = {"status": "working", "done": 0, "total": len(work_items)}
    return {"task_id": task_id, "status": "accepted"}  # ここで呼び出し元は解放される

def new_style_poll_task(task_id):
    return TASKS_STORE[task_id]  # tasks/get 相当。いつ呼んでもよい

新方式を模したコードを動かすと、new_style_submit_taskを呼んだ時点で処理はすぐに返り、その後は好きなタイミングでnew_style_poll_taskを呼んで進捗（done: 3/20 → done: 20/20）を確認できました。当たり前の挙動ではあるのですが、「呼び出し元が処理の完了を待つ必要がない」という設計を自分の手で再現してみると、月次決算のような重いバッチ処理をAIエージェント経由で回す際に、担当者側の画面やスクリプトを固定しなくて済むメリットが具体的に見えてきます。

よくある誤解

Q. MCPのTasksが正式仕様になったから、もう長時間バッチはAIに全部任せて大丈夫？

A. いいえ。Tasksが解決するのは「処理中に接続を待たせずに済む」という通信設計の問題だけです。処理内容そのもの（例えば仕訳判定の精度や、消費税区分の判断）の正しさは別問題で、これまで通り人がチェックする体制は必要です。この点は以前の銀行明細の仕訳自動化の記事でも書いた通り、「どこまで任せてどこから人が見るか」という線引きは変わりません。

Q. 自分でMCPサーバーを実装しないと関係ない話？

A. 直接サーバーを書かなくても、今後MCP対応をうたう会計ソフトや業務ツールが増えれば、ユーザー側は意識せずにこの恩恵を受けることになります。裏側の設計が変わったというニュースとして押さえておく程度で十分です。

判断軸：この変更を気にすべきか

• 顧問先ごとの月次バッチ処理、大量データの突き合わせなど「数分以上かかる作業」をAIエージェント経由で自動化したい場合は、対応ツール・SDKが出揃うタイミングで検討する価値があります
• 数秒で終わる単発の判定作業（仕訳の科目推測など）には、この変更のメリットはほとんどありません。既存の仕組みのままで問題ないという判断も十分あり得ます
• 「新しい仕様だから」という理由だけで既存の自動化を作り替える必要はありません。移行期間が設けられているため、今すぐ対応しなければならない仕様変更ではないという点も踏まえておくとよいと思います

まとめ

MCPの2026-07-28仕様で、長時間実行タスクの扱いが「接続を保持して待つ」方式から「登録してポーリングする」方式に正式に切り替わりました。会計事務所の実務で言えば、月次決算のバッチ処理のような「重いが、待っていられる作業」をAIエージェントに任せる際の技術的な土台が整ったということです。ただし、これは通信設計の話であり、判断の正しさを保証するものではない点は変わりません。対応するツールが増えてきたタイミングで、改めて自動化の範囲を見直すのがよさそうです。

参考

• The 2026-07-28 Specification | Model Context Protocol Blog
• Key Changes（公式チェンジログ）| Model Context Protocol