付録A 下書き・承認・チケット登録を分ける
本付録は初稿です。
A.1 この付録で学ぶこと
基礎編では、検索して回答するところまでを扱いました。ここからは、外部の状態を変更する操作を加えたときの違いを学びます。基礎編の修了に、この付録の実装は必要ありません。
題材は、解決しない相談をチケットへ登録する機能です。目標は、下書き、本人の承認、プログラムによる登録、結果の確認を分けて説明できることです。本番のチケットシステムへの接続は行いません。
A.2 読み取りから更新へ進むと何が変わるか
検索では、情報を取得して回答へ使います。チケット登録では、外部システムへ新しい記録を作ります。誤った回答の修正だけでなく、誤登録や二重登録への対処が必要になります。
図A-1 提案、許可、実行、結果を一つの「登録」にまとめない。 矢印は業務上の処理順序です。ひし形は検証や結果判定を表します。教材独自の設計であり、Foundry が標準で提供する承認ワークフローではありません。
| 操作の例 | 役割 | 最低限考えること |
|---|---|---|
search_knowledge | 閲覧可能な資料を取得する | 文書の認可と根拠の扱い |
prepare_ticket | 問い合わせの下書きを作る | 事実、不足情報、送信する内容 |
submit_ticket | 承認された内容を登録する | 権限、承認、重複防止、結果確認 |
これらは独自の名前です。三つすべてをモデルに選択させる必要もありません。登録は、承認画面の操作からサーバーが直接実行する構成にできます。
A.3 下書きは登録の許可ではない
社員が「まだ直りません。問い合わせをお願いします」と伝えたら、困りごと、OS、試した手順、不足項目を整理します。登録先、本文、添付を下書きとして表示し、利用者が何を送るか確認できるようにします。
| 下書きの項目 | 例 |
|---|---|
| 件名 | Windows で VPN 接続できない |
| 確認済みの事実 | 利用者が Windows と申告した |
| 実施した確認 | 利用者が実施したと確認できるものだけ |
| 未確認 | エラー表示、発生時期など |
| 送信先と添付 | テスト用の窓口、添付なし |
モデルが提案した手順と、利用者が実施した手順を混ぜてはいけません。また、取得した社内資料の全文や別の会話を、必要性を確認せず外部へ送らないようにします。
A.4 承認を実行時にも確認する
承認は「利用者が、どの内容を、どの操作で、いつまで許可したか」へ結び付けます。モデルに approved: true と出力させても、本人の承認にはなりません。
たとえば、下書き ID、内容の版、承認した利用者、登録先、操作、有効期限をサーバーで記録します。登録時には、現在の利用者権限と承認対象が一致するかを再確認します。承認後に本文や登録先が変わったら、元の承認を転用せず、改めて確認します。
これはサーバー側で保証する契約です。モデルへの指示だけ、ボタンの表示だけで成立したと考えません。
A.5 応答がないことと、登録されていないことは違う
チケット API へ送信した後で応答だけが失われると、外部では登録済みかもしれません。再送すると、同じ相談を二件登録する可能性があります。
公式の Retry パターンも、処理は成功したが応答を返せなかった場合に、再送が重複した副作用を生む可能性を説明しています。[^retry-pattern] 本教材では、操作を識別する ID と状態を保存し、接続先が対応する重複防止や照会の契約を確認する設計にします。結果不明なら、同じ操作の記録や外部の状態を照合します。確認できなければ成功・失敗を断定せず、担当者へ引き継ぎます。
| 状態 | 利用者へ伝えることの例 | 次にすること |
|---|---|---|
| 未承認 | 下書きの確認待ち | 登録しない |
| 登録成功を確認できた | 確認できたチケット ID と結果 | 完了を記録する |
| 登録失敗を確認できた | 登録できなかった理由と次の案内 | 失敗を記録し、必要な修正を行う |
| 送信後に結果が不明 | 登録結果を確認中 | 照合し、安易に再送しない |
| 内容・承認が不一致 | 内容の再確認が必要 | 新しい下書きで承認し直す |
A.6 小さな実習と確認課題
外部 API を使わず、紙上で次の条件を試します。実装する場合もテスト用の保存先だけを使います。
- 下書きを作ったが、承認していない。
- 承認後に本文を変更した。
- 同じ登録操作を二回要求した。
- テスト用の登録先では保存できたが、応答が届かなかった。
それぞれについて「登録を許可するか」「何を記録するか」「利用者へ何を伝えるか」を書きます。4では、登録先の状態を確認せずに失敗と断定しないことがポイントです。
さらに、第6章の通信台帳へ「登録実行元 → テスト用 API」を追加してください。Function calling をアプリ側で実行するなら、Foundry からではなく、そのアプリからの接続になります。
A.7 まとめ
モデルによる下書きは提案であり、本人の承認は許可、API 呼び出しは実行、登録 ID の確認は結果の証拠です。この四つを分ける考え方を持って、詳細な開発・運用の設計へ進んでください。
A.8 参考情報
- Microsoft Foundry で AI エージェントの開発と運用 — 承認、冪等性、障害対応、継続運用を学ぶ別冊
- Retry pattern — 応答を失った場合の重複実行と、再試行時に考慮する冪等性
[^retry-pattern]: Retry pattern — Microsoft