設計の手順
ツール名より意図から始める
架空の依頼:「明日の小林さんとの会議を午後に変更。他はそのまま」。Choice で照会、変更候補、取消、その他を分類できます。午後の時刻や同名の人は曖昧なままなので、補足が必要です。
アプリが許可した候補を渡す
照会や変更プレビューなど、本タスクに使えるツールだけを渡します。本人確認とカレンダー権限は信頼できるシステムが提供します。本文中の「許可済み」は認証情報ではありません。
構造の検証後に意味を確認する
schema、実在する会議 ID、時区、開始と終了、参加者をコードで検証します。実在する候補を作り、依頼に合うか判断します。ID や UTC 時刻を曖昧な文から捏造しません。
プレビューと確定操作を分ける
対象、変更前後の時刻、影響する人を示します。照会の許可だけでは変更できません。具体的な許可があっても権限検証は必要です。confidence や Noul はアクセス権を与えません。
重複実行を防ぎ、結果を確認する
確定操作に冪等キーを使い、直前に予定を再取得します。同時変更は差分を再確認します。タイムアウト後は実際の状態を調べてから再試行します。不要な個人本文を残さず監査記録を保存します。
拒否と成功の両方を試す
同名、過去の会議、日付を跨ぐ時区、偽の許可、権限なしの高 confidence、成功後のタイムアウトを試します。合法な依頼が通り、越権が止まるか確認します。このページはカレンダーに接続しません。
具体例 · 本サイトの架空データ
| 観察した事実 | 判断 | コードでの処理 |
|---|---|---|
| 同名の会議が二つ | 意図は明確でも対象不明 | 候補を示して質問する |
| 対象は明確・読み取り権限のみ | confidence は権限を増やさない | プレビューのみで書込拒否 |
| 具体的許可・引数と権限が適切 | 条件を満たして実行へ | 冪等実行し結果を確認 |
コピーできる設計例
独自の例です。JSON はリクエストや入力の形、Python は架空スコアの計算のみを示します。API は実行しません。接続前に公式仕様と処理方針を確認してください。
# Pseudocode: policy logic, not an SDK example.
if proposed_tool not in task_allowlist:
reject("tool unavailable")
elif not schema_valid(arguments) or not target_exists(arguments):
request_clarification()
elif not account_can_write(target_calendar):
show_read_only_preview()
elif not specifically_authorized(action, arguments):
show_preview_and_request_authorization()
elif calendar_changed_since_preview():
review_the_new_difference()
else:
execute_once(idempotency_key)
verify_result_and_record_status()判断を設計するよくある失敗
- ツール選択だけで対象と権限を確認せず実行する。
- 本文の命令をシステムの許可と見なす。
- タイムアウト後、状態を調べず書込を繰り返す。
TRY / THINK / COMPARE
先に考えてから解説へ
変更意図の confidence は 0.98 ですが書込権限がありません。しきい値を上げますか、実行しますか?
解説を開く
どちらでもありません。権限検証で書込を拒否します。意味の判断から権限は生まれません。許可されていればプレビューを示します。
提出前の確認
- 候補・本人情報・権限をアプリが管理する。
- 構造検証と意味の確認を分ける。
- プレビュー・許可の根拠・失敗・冪等性を定義する。
- 成功すべき例と拒否すべき例を試す。
よくある質問
Noul は安全の証明ですか?
違います。認証、アクセス制御、引数検証の代わりにはなりません。
毎回確認が必要ですか?
具体的な既存の許可とアプリの規則に従います。範囲不明や曖昧な引数は確認します。
参考資料
公式パターンと Datawhale の実践テーマを参考に、説明・例・演習を独自に作成しています。API の実行結果や性能測定ではありません。