毎回同じ連絡を書いていると、すぐに自動化したくなります。ただ、連絡文を作ることと、内容を確認して相手へ届けることは別の仕事です。まず引き継ぎの順番を整理すると、AIに任せたい部分も見えやすくなります。

Relay Appには、入社時の準備、週次報告、情報整理などのワークフロー例があります。現在のAboutページでは、relayapp.orgは独立した運営のサイトで、元のRelay.appの資料を出典付きで利用していると説明されています。この記事は公開ページの例をもとにした業務整理の提案です。実際の自動化を実行した体験談や、各連携機能の動作確認ではありません。

Relay App public homepage; illustrated workflow, not a tested run

最初に完了の形を決める

入社準備なら、「新しい人が入ったら必要なことを全部やる」という依頼は少し広すぎます。「担当者が確認できる準備一覧と案内文の下書きを作る」と書くと、どこまで進めればよいか具体的になります。

ホームページの入社例では、新しい社員をきっかけに、ワークスペースへの招待、グループへの追加、歓迎メールへ進む流れが描かれています。これは順番を考える材料になりますが、今使っているサービスで同じ操作ができるとは限りません。実装するときは、それぞれの権限や利用条件を確認する必要があります。

紙のチェックリストでも、開始条件、必要な情報、完成物を決められます。氏名、所属、開始日がそろっているか。案内の宛先は誰か。確認前の文面はどこに置くか。こうした小さな決定が、次の人の迷いを減らします。

Public workflow examples with original Relay.app archive attribution

情報が足りないときの行き先を書く

資料から名前や日付を取り出す作業は、AIの利用を考えやすい部分です。Relay Appの説明でも、情報の抽出、文章の要約、分類が別の項目として紹介されています。何でも一度に依頼せず、必要な項目ごとに考えると確認しやすくなります。

開始日が書かれていないときは、推測して埋めるよりも担当者へ確認する流れが必要です。「未確認」という状態を残し、その理由と元の資料を添えれば、次の人は調べ直す時間を減らせます。

文章が自然でも、取り出した情報が正しいとは限りません。案内文の横に確認元の資料を置くなど、内容と根拠を一緒に渡す方法を考えます。これは業務設計上の提案であり、特定の実装に保存機能があると確認したわけではありません。

確認と送信を分ける

同サイトの人が参加する工程には、AI出力の確認、承認の依頼、追加情報の依頼が登場します。この三つは似ていますが、引き継ぐ目的が違います。不足情報を答えた人が、そのまま最終メールの送信を承認したとは限りません。

誰が何を確認するかを決めます。案内の日付、所属、必要なリンクを確認する人と、送信先を確認する人が同じなら、その役割も一覧に書いておきます。下書きが修正されたら、確認済みの内容との違いが分かるようにします。

締め切りまでに返事がなかった場合も考えておきたいところです。返事がないことを承認として扱わず、待つのか、別の担当者へ相談するのかを先に決めます。予定どおり進まないときの道筋があると、自動化の途中でも状況を説明しやすくなります。

Relay App page explaining human review, approval and information requests

一度分の下書きで試す

最初は実際の相手への自動送信をせず、一度分の準備一覧と下書きで確認します。通常の例に加えて、日付がない例や、担当者が修正を求める例もあると、止まるべき場所が見えてきます。

その後、選んだ実際のサービスで必要な操作と結果を確認します。ページに例が載っていること、下書きができたこと、外部への連絡が届いたことは、それぞれ別の証拠で確かめます。元のRelay.app資料と現在のサイトの役割も混同しないようにします。

AIを使う前に、開始条件、必要な情報、確認する人、完成物を一枚にまとめる。忙しい仕事ほど、こうした引き継ぎの整理から始めると、自動化に任せたい仕事が具体的になります。