Microsoft developer platform更新：Pythonの実験的TodoProviderで確認すべき変更点

Microsoft developer platformの2026年5月5日更新で注目すべき点は、Microsoft Agent FrameworkのPython Coreに、実験的なTodoリスト用Harness Context Providerが追加されたことです。すぐに既存アプリの修正が必要な破壊的変更ではありませんが、Pythonで長時間実行型のAIエージェント、計画実行型エージェント、セッション状態を使うエージェントを開発しているチームは確認しておくべき更新です。特に、TodoProvider、TodoSessionStore、TodoFileStoreを利用する可能性がある場合は、永続化方式、source_id、ファイル保存時のセッションID・所有者IDの扱いを早めに点検しましょう。

何が更新されたのか

今回の更新は、Microsoftのmicrosoft/agent-frameworkリポジトリにおけるPull Request #5612「Python: Core: add experimental todo-list harness context provider」として、2026年5月5日にmainブランチへマージされたものです。変更内容はPython Core向けで、実験的なAgent Harness機能の一部として、Todoリストを管理するContext Providerを追加しています。(GitHub)

Microsoft Agent Frameworkは、Pythonと.NETでAIエージェントやマルチエージェントワークフローを構築するためのフレームワークです。公式ドキュメントでは、セッションベースの状態管理、型安全、ミドルウェア、テレメトリ、ワークフローなどを組み合わせた基盤として説明されています。(Microsoft Learn)

今回追加されたTodoリスト用Harness Context Providerは、エージェントが「これから何をするか」「どこまで完了したか」をセッション内で管理しやすくするための仕組みです。PRの説明では、長時間実行されるplan-and-execute型エージェントで、永続的なセッション状態を扱いやすくするContext Provider群の一部とされています。(GitHub)

追加された主な機能

今回の変更で中心になるのは、Python向けのTodoProviderです。これは.NET側のTodoProviderに対応するPython実装として追加され、PythonではContextProviderベースで実装されています。PRでは、Python側のツール名はsnake_caseを採用し、ストレージバックエンドを差し替え可能にしている点が明記されています。(GitHub)

追加・変更された要素	内容	開発者が見るべきポイント
TodoProvider	エージェントにTodo管理用の命令・ツール・現在のTodo一覧を提供	計画実行型エージェントに組み込む候補になる
TodoItem	既存Todoを表すモデル	id、title、description、is_completeの扱いを確認
TodoInput	新規Todo作成時の入力モデル	空タイトルや不正なdescriptionはエラーになる
TodoStore	Todo保存先の抽象インターフェイス	独自ストレージ実装の差し込み口になる
TodoSessionStore	AgentSession.state内にTodo状態を保存	短期・セッション単位の管理に向く
TodoFileStore	JSONファイルとしてTodo状態を保存	長期保存や再起動後の復元を検討する場合に確認が必要
DEFAULT_TODO_SOURCE_ID	既定のsource ID	他Providerと名前が衝突しないか確認

TodoProviderは、エージェントに対してTodo管理用のツールを提供します。追加されたツールは、add_todos、complete_todos、remove_todos、get_remaining_todos、get_all_todosです。PRでは、.NET側のTodoList_Addなどに対して、Pythonではsnake_caseのツール名を使う構成になっています。(GitHub)

既存アプリへの影響範囲

今回の更新は、実験的機能として追加されているため、通常のチャットエージェントや、Microsoft Agent Frameworkを単純なLLM呼び出しに使っているだけのアプリには直接影響しません。PRのContribution Checklistでも、破壊的変更ではなく@experimental(ExperimentalFeature.HARNESS)配下にある変更として整理されています。(GitHub)

一方で、次のような開発チームは影響を確認する価値があります。

対象	確認すべき理由
PythonでAgent Frameworkを使っているチーム	新しい公開シンボルがagent_frameworkから参照可能になる可能性がある
長時間実行型エージェントを作っているチーム	タスク分解・進捗管理・未完了タスク確認をProviderで扱える
.NET版Agent FrameworkとPython版を併用しているチーム	.NET側TodoProviderとの機能差や命名差を確認する必要がある
独自のContext Providerを作っているチーム	_harness名前空間やExperimentalFeature.HARNESSとの関係を確認したい
ファイル永続化を使う予定のチーム	TodoFileStoreの保存パス、所有者ID、セッションIDの設計が重要になる

特に、マルチテナント環境やユーザーごとに状態を分離するアプリでは、TodoFileStoreの設定を軽く見ないほうがよいです。Todo自体は小さな状態情報ですが、ユーザーの作業内容、処理対象、業務上の意図が含まれる可能性があります。保存先、アクセス権、ログ出力、削除ポリシーまで含めて設計しましょう。

TodoProviderでできること

TodoProviderは、エージェントに「作業リスト」を持たせるためのContext Providerです。エージェントが複雑な依頼を受けたとき、作業を細かいTodoに分解し、完了した項目をマークし、不要になった項目を削除できます。

たとえば、ユーザーが次のように依頼したとします。

社内FAQデータを確認して、問い合わせ傾向を分類し、改善案を出して

このような依頼では、エージェントがいきなり最終回答を生成するよりも、次のように作業を分けるほうが安定します。

Todo例	目的
FAQデータの対象範囲を確認する	前提条件の取り違えを防ぐ
問い合わせ内容をカテゴリ別に分類する	分析結果の粒度をそろえる
件数が多いカテゴリを抽出する	改善優先度を判断しやすくする
改善案を3つに絞る	出力を実行可能な形にする
最終レポートを作成する	ユーザーに提出できる形に整える

これをTodoとして管理できれば、途中でユーザーが「FAQではなくチャットログも含めて」と方針変更した場合にも、エージェントは不要なTodoを削除し、新しいTodoを追加できます。PR内の既定命令でも、複雑なタスクを管理可能なTodoに分解すること、ユーザーからフィードバックがあればTodoを調整すること、完了した項目をマークすることが示されています。(GitHub)

TodoSessionStoreとTodoFileStoreの使い分け

今回の更新で重要なのは、Todoの保存先を選べる点です。PRでは、セッション内保存のTodoSessionStoreと、JSONファイル保存のTodoFileStoreが追加されています。(GitHub)

保存方式	向いている用途	注意点
TodoSessionStore	1回の会話、短期的な作業管理、プロトタイプ	セッション破棄後に状態が残らない可能性がある
TodoFileStore	再起動後もTodoを復元したいケース、長時間実行、ローカル検証	ファイル保存先、権限、ユーザー分離、削除運用が必要
独自TodoStore	DB、Redis、クラウドストレージ、監査ログ連携	保存形式と並行更新の整合性を自前で確認する必要がある

最初に検証するならTodoSessionStoreで十分です。実運用に近い検証では、セッション再開やプロセス再起動後の復元が必要になるため、TodoFileStoreまたは独自のTodoStoreを検討します。

ただし、Todoをファイル保存する場合は、単に「JSONで保存できるから便利」と考えるのは危険です。保存されるTodoには、顧客名、案件名、ファイル名、作業内容などが含まれる可能性があります。社内利用でも、保存先ディレクトリのアクセス権、バックアップ対象、暗号化、保持期間を決めてから使うべきです。

移行対応が必要か判断する基準

今回の更新は、すべてのMicrosoft developer platform利用者が即対応すべき変更ではありません。次の表で、自分のプロジェクトが確認対象か判断できます。

状況	対応優先度	やること
Agent Frameworkを使っていない	低	対応不要
Agent FrameworkをPythonで使っているが、単発応答のみ	低	リリースノート確認程度でよい
PythonでContext Providerを使っている	中	source_idや公開APIの衝突を確認
長時間実行型エージェントを開発中	高	TodoProviderの導入可否を検証
.NET版とPython版を横断して実装している	高	ツール名、モデル名、保存方式の差分を整理
ファイル永続化を使う予定	高	TodoFileStoreの保存パスと権限を設計

実験的機能である以上、本番環境へ直接組み込むよりも、まずは検証環境で「Todo管理によりエージェントの失敗が減るか」を確認するのが現実的です。たとえば、複数ステップのタスクで途中抜けが多い、完了済み作業を繰り返す、方針変更後に古い作業を続ける、といった課題がある場合は試す価値があります。

設定確認で見るべきポイント

TodoProviderを使う前に、次の観点を確認してください。

確認項目	具体的なチェック内容
インストール済みバージョン	利用中のagent-frameworkでTodoProviderなどが公開されているか確認する
実験的機能の扱い	API変更の可能性を前提に、アプリ側で依存箇所を分離する
source_id	他のContext Providerや状態管理キーと衝突しない名前にする
保存方式	セッション内保存か、ファイル保存か、独自ストアかを決める
ファイル保存先	アプリユーザーが不要に読めない場所にする
セッションID	推測しやすいIDやパスに使いにくい値を避ける
所有者ID	マルチテナントではユーザー・組織単位の分離を設計する
テスト	追加・完了・削除・未完了一覧・全件取得を自動テストに入れる

実装確認では、まず次のように公開シンボルが参照できるかを見るとよいでしょう。

from agent_framework import TodoProvider, TodoSessionStore, TodoFileStore

ファイル保存を検証する場合は、概念的には次のように保存先と所有者キーを明示します。

from agent_framework import TodoFileStore, TodoProvider

todo_store = TodoFileStore(
    base_path="./agent-state",
    owner_state_key="user_id",
)

todo_provider = TodoProvider(
    source_id="todo",
    store=todo_store,
)

この例では、session.state["user_id"]にユーザー識別子が入っていることが前提です。値が未設定の場合、ファイル保存側でエラーになる設計なので、セッション作成時点で必ず設定する運用にします。

ファイル永続化で失敗しやすいポイント

TodoFileStoreを使う場合、最も注意したいのは「Todoの保存パスがアプリの責任範囲内に収まっているか」です。PR上の自動レビューでは、初期段階でパストラバーサルの懸念が指摘されており、その後の実装ではパスセグメントの安全化、base directoryからの逸脱チェック、原子的なJSON書き込みなどが入っています。(GitHub)

運用側で特に避けたい失敗は次の3つです。

失敗例	起きる問題	対策
base_pathを共有ディレクトリにする	他ユーザーや他アプリから読める可能性がある	アプリ専用ディレクトリを作り、権限を最小化する
owner_state_keyを設定したのに値を入れ忘れる	セッション開始後に保存・読み込みでエラーになる	セッション初期化処理で必ず設定する
Todoに機密情報をそのまま入れる	ファイルやログから情報漏えいする	Todoの粒度を作業名中心にし、秘密情報は別管理する

Todoリストは「軽い作業メモ」に見えますが、AIエージェントの実務利用では重要な業務コンテキストになります。たとえば「A社向け障害報告書を作成する」「給与データを分類する」のようなTodoが残るだけでも、組織によっては機密情報に該当します。

.NET版との違いをどう見るべきか

PRでは、今回のPython実装は.NET側のTodoProviderに対応するものと説明されています。一方で、Python固有の違いとして、ContextProviderベースであること、ツール名がsnake_caseであること、TodoStoreバックエンドを差し替え可能にしていることが示されています。(GitHub)

.NETとPythonを併用しているチームでは、以下を揃えておくと混乱を減らせます。

比較観点	.NET側	Python側
Todo追加ツール名	TodoList_Add系	add_todos
Todo完了ツール名	TodoList_Complete系	complete_todos
Todo削除ツール名	TodoList_Remove系	remove_todos
未完了一覧	TodoList_GetRemaining系	get_remaining_todos
全件取得	TodoList_GetAll系	get_all_todos
保存設計	.NET側の状態管理に依存	TodoSessionStore、TodoFileStore、独自TodoStore

社内ドキュメントやプロンプトにツール名を書いている場合、.NETとPythonで名称が異なる点に注意してください。特に、ツール呼び出しログや評価データを横断的に分析している場合は、同じ意味の操作を別名として扱えるようにマッピングしておくと便利です。

実務での導入ステップ

実験的機能をいきなり本番投入するのではなく、次の順序で検証すると安全です。

ステップ	作業	判断基準
1	現在のAgent Framework環境でTodoProviderが使えるか確認	importできるか、ドキュメントと実装の差分がないか
2	TodoSessionStoreで最小検証	Todoの追加・完了・削除が期待通りか
3	複雑なタスクで比較	Todoなしより途中抜けや重複作業が減るか
4	必要ならTodoFileStoreを検証	再起動後に状態が復元できるか
5	セキュリティレビュー	保存先、権限、保持期間、削除手順を確認
6	本番向けラッパーを作る	実験的API変更に備えて依存箇所を局所化する

検証時は、成功ケースだけでなく、途中でユーザーが方針を変えるケースを必ず試してください。Todo管理の価値が出るのは、単純な直線タスクよりも、作業が分岐したり、前提が変わったり、長時間にわたって状態を保持したりする場面です。

本番利用前の注意点

Microsoft Agent Frameworkはバージョン1.0として安定APIや長期サポートへのコミットメントが示されていますが、同時に一部機能はプレビュー・実験的な位置づけで提供されることがあります。今回のTodo Harness Context ProviderもExperimentalFeature.HARNESS配下であるため、APIや挙動が今後変わる可能性を前提に扱うべきです。(Microsoft for Developers)

本番に近い環境で使うなら、少なくとも次の対策を入れてください。

対策	理由
TodoProviderを直接アプリ全体に散らさない	API変更時の修正範囲を狭める
保存データのスキーマを把握する	既存Todoの移行や削除に備える
ユーザー単位・テナント単位で分離する	他ユーザーのTodo混入を防ぐ
Todo内容を監査対象にするか決める	業務ログとして扱う可能性がある
失敗時の復旧手順を用意する	JSON破損、権限エラー、保存先容量不足に備える

また、エージェントにTodo管理を任せても、ビジネス上の承認やセキュリティ判断まで自動化されるわけではありません。Todoはあくまで計画と進捗の補助です。ファイル削除、外部API呼び出し、個人情報処理などの高リスク操作は、別途承認フローやガードレールを組み合わせる必要があります。

まとめ：まず確認すべきこと

今回のMicrosoft developer platform更新は、Python版Microsoft Agent Frameworkで計画実行型エージェントを作る開発者にとって重要な布石です。既存アプリを急いで修正する必要はありませんが、長時間実行、セッション状態、タスク分解、進捗管理を扱う場合は、TodoProviderの検証を始める価値があります。

最初にやるべきことは3つです。

優先度	やること
高	利用中のagent-frameworkでTodoProviderが公開されているか確認する
高	Todo状態をセッション内に置くか、ファイルに永続化するか決める
中	本番利用を見据えて、保存先・権限・API変更時の影響範囲を整理する

単なる新機能として眺めるのではなく、「自社のエージェントが途中で迷子にならないようにする仕組み」として評価すると、導入判断がしやすくなります。複雑な依頼を扱うAIエージェントほど、Todo管理のような小さな状態管理が品質差につながります。