AI に「今日のタスクを確認して」と頼む操作と、「このタスクを完了にして」と頼む操作は、分けて設計できます。前者は予定の読み取り、後者は保存済みデータの変更です。ツールが同じ接続から呼べても、操作の意味は同じではありません。
ここでは、私が開発している WeekOrbit の MCP ツールを例に、対象を取り違えないための流れを整理します。WeekOrbit は Today、Week、Month、Group の各ビューを持つ個人向けプランナーで、外部アシスタントは MCP または API から同じタスクを扱えます。
- 最初は必要な範囲だけ読む
list_tasks に date を渡すと、指定日のタスクに絞れます。例として {"date":"2026-10-29"} は一日分の取得です。日付は利用者のタイムゾーンで決めます。返ってくる title は説明用、id は操作対象を識別するために使います。画面で振った「4番」のような連番は、その一覧でだけ有効な選択番号です。
- 選択番号を、そのとき取得した id に結び付ける
ユーザーが番号を選んだら、同じ一覧の対応関係から id を取り出します。タイトルで全件を再検索して先頭を選ぶと、同名タスクや繰り返し予定を取り違えるおそれがあります。実行前に get_task({"task_id":"実際に取得したid"}) でタイトル、日付、完了状態を確認します。これは実際の id を必要とする説明例であり、この文字列をそのまま実行するものではありません。
- 書き込みは、依頼された操作に限定する
一覧を確認しただけで完了状態は変更しません。完了の指示がある場合に限り、対象の update_task へ completed=true を渡す設計にします。一つの繰り返し予定を完了にすることと、シリーズのルールを変えることも分けます。外部サイトへの投稿や支払いは、タスクの取得・更新とは別の操作です。
- 保存結果を読み直す
更新 API の応答だけで説明を終えず、元の task_id を get_task で取得し、completed など変更した項目を確認します。ツールが通信エラーになった場合は、まず同じ id の現在値を読んで、成功済みか未変更かを確認します。同じ変更要求を何度も送ることを既定の対処にしないためです。
この流れは WeekOrbit だけの最適化ではありません。AI が扱う対象の識別子、ユーザーの指示が認めた操作、保存後の状態を別々に確認する、という設計です。先に読み取りで対象を絞り、必要なときだけ書き込み、最後に読み直す。これだけでも、実装とユーザーへの説明を整理できます。
製品情報： https://weekorbit.com
この記事は開発者本人による説明です。上の JSON はインターフェースの説明例です。本記事では未実施の書き込みを実行済みと主張せず、性能向上率や安全性の保証も示していません。