設計事務所のAI自動化｜承認を残して省力化する

自動化は外部送信の手前で止めるところから始める

受信メールの分類、タスク候補の作成、返信下書きなどは自動化候補です。しかし、誤分類や創作した期限が、そのまま顧客送信や案件更新へ進むと影響が大きくなります。初期の自動化は、候補を作って承認待ちへ置くまでに限定します。

「AIに任せる」という単位ではなく、受信、前処理、分類、下書き、照合、承認、実行、記録へ分解します。各段階の入力、出力、責任者、失敗時の戻り先を決めます。

一つの業務フローを可視化する

例として、代表メールへ届いた打合せ日程の問い合わせを扱います。

初回試行では送信処理を接続せず、下書きを別フォルダへ保存します。カレンダーや案件台帳も読み取り専用にし、AIへ予定の確定や登録をさせません。

対象と例外をルールで先に判定する

AI分類の前に、明確なルールで除外できるものを決めます。添付のみ、暗号化ファイル、契約変更、請求、苦情、事故、安全、法的照会、個人情報を含む内容は自動下書き対象から外し、担当者へ通知します。

対象メールでも、案件IDが不明、宛先が複数、過去の合意と矛盾、返信期限が不明なら要確認へ止めます。例外を通常処理へ押し込まないことが、自動化の安全性を高めます。

下書きプロンプトは利用できる情報を限定する

以下は匿名化した日程問い合わせです。承認済みの候補日時表に記載された日時だけを使い、返信下書きを作ってください。案件名、担当名、場所、オンライン会議URL、期限を推測しないでください。候補がない、時区が不明、相手の希望と一致しない場合は本文を作らず「担当者確認」としてください。出力は受付ID、引用した原文、使用した候補ID、下書き、確認事項とします。

候補日時表にない日時を提案したり、会議URLを創作したりした出力は不合格です。定型文も版IDを持ち、古い連絡先や署名を使わないようにします。

承認画面に根拠を並べる

承認者が下書きだけを見ると、原文との違いを見落とします。受付ID、相手の原文、抽出した要望、使用した候補、下書き、AIが未確認とした事項を同じ画面か確認票へ並べます。

Microsoft Power Automateの公式資料は、承認ワークフローを作成し、「Start and wait for an approval」で人の応答を待つ例を示しています。これは具体的な製品例です。自社契約でコネクタ、権限、保存先、ライセンスを現物確認し、同じ動作を保証されたものとして扱いません。

承認操作は、承認、修正して承認、差し戻し、却下を分けます。誰が、いつ、どの版を見て判断したかを記録します。一定時間応答がなければ自動送信せず、担当者へ再通知します。

権限は工程ごとに最小化する

分類処理には対象フォルダの読取権限、下書き処理には下書き保存先への作成権限だけを与えます。送信、削除、元メール移動、案件台帳更新の権限を最初からまとめて付けません。

MicrosoftのAIエージェントに関する共有責任の資料は、構成にかかわらず顧客がデータ、IDと最小権限、アクションの認可、人の監督に責任を持つと説明しています。ツールごとの権限や監査ログの実装分担はIaaS、PaaS、SaaSで異なるため、採用製品の責任表と設定を確認します。誰の権限で何が実行されたかを追える設計にします。

正常系より失敗系を先に試す

1. 明確な日程問い合わせで正しい下書きが出るか確認します。
2. 候補日時がない場合に停止するか試します。
3. 本文が空、添付のみ、文字化けの場合を試します。
4. 苦情や契約変更が通常返信へ進まないか確認します。
5. 同じメールの二重処理を防げるか確認します。
6. 承認者不在や期限超過で送信されないか確認します。
7. AIサービス停止時に原文が失われないか確認します。
8. 取消、再実行、ログ確認の手順を試します。

試験には架空または十分に匿名化したデータを使います。外部メールアドレスへは送信せず、隔離した下書き保存先で検証します。

効果測定に例外対応を含める

自動化の時間には、フローの監視、要確認の処理、誤分類の修正、再実行、ログ確認を含めます。正常系だけの処理時間では実運用の負担を測れません。誤送信や誤更新は件数が少なくても重大度が高いため、ゼロを必須条件にできます。

対象率が低く要確認ばかりになる場合は、AIの指示を長くする前に、対象業務をさらに限定します。たとえば「日程問い合わせ全般」から「承認済み候補表に一致する返信下書き」へ狭めます。

承認済み内容だけを実行へ渡す

受付R015の下書き版2を承認した後に版3が自動生成された場合、送信対象は承認済みの版2です。実行直前に受付ID、版、承認者、承認日時を照合し、一つでも違えば停止します。担当者が本文を手直しした場合は新しい版として再承認します。

送信後は、送信した本文、宛先、時刻、承認記録を結びます。下書きと実送信文のハッシュや版IDを比較できると、承認後の変更を発見できます。自動処理の成功表示だけでなく、送信先の記録とエラーキューも確認します。

添付がある場合は、本文の承認と添付の承認を分けません。承認画面でファイル名、版、容量、対象案件を示し、未確認の添付が一つでもあれば送信を止めます。リンク共有では閲覧権限と有効期限も確認します。

失敗時は安全な状態へ戻す

AIや連携先が停止した場合は、受信済み原文を保持し、未処理一覧へ戻します。途中生成の下書きを送信済みと扱いません。二重実行を防ぐため受付IDと処理状態を持ちます。

誤った下書きが増えた場合は自動実行を停止し、製品、モデル、指示文、定型文、入力形式の変更を確認します。原因を特定できるまで手動処理へ戻せる手順を用意します。

よくある質問

最初から自動送信してよいですか

避けます。下書き保存までを試し、原文照合と人の承認、例外処理が機能することを確認します。

承認者が反応しない場合は自動承認できますか

初期運用では送信せず、再通知や別の承認者への引継ぎへ止めます。

AIにメールボックス全体の権限が必要ですか

必要な対象と操作へ限定します。読取、下書き作成、送信、削除の権限を分けて検討します。

図面や添付も自動処理できますか

製品ごとに対応が異なり、画像や図面の読取精度は保証されません。初回は対象外にし、別の試行で検証します。

自動化が止まったときはどうしますか

未処理一覧へ戻し、原文を保ったまま手動処理します。再実行時の二重送信を受付IDで防ぎます。

参考資料

• Microsoft Learn：Power Automateの承認ワークフロー
• Microsoft Learn：AIエージェントの共有責任

関連記事

• 設計事務所のAI出力レビュー
• 設計事務所のAI試行
• 設計事務所のプロンプト管理