業務自動化の仕様を整理する｜入力・処理・出力・例外の4項目

「週報を自動化してほしい」という依頼だけでは、担当者へ確認用の下書きを渡すのか、全社員へ配信するのかが分かりません。この記事では、業務自動化を相談する前に作る仕様メモを、週次報告の仮想例で説明します。特定のツール操作やコードではなく、仕事の流れを合意するための準備です。

4項目は、最初の仕様メモを作るための整理方法

ここで使う4項目はMakeAIの編集上の整理です。これだけでシステムの要件定義が完成するわけではありません。実装へ進む際には、権限、保存期間、性能、運用体制、費用なども詰める必要があります。

例えばBlue Prism公式の要件定義に関する解説では、入力データや例外だけでなく、自動化の範囲、前提条件、対象システムの制約なども文書に含めることを勧めています。最初のメモで、すでに決まっていることと、後で決めることを見えるようにしておきます。

項目	業務担当者へ聞くこと	曖昧な書き方
入力	誰が用意した、どの場所の、どんな形式の情報を受け取るか	必要な資料を使う
処理	どの順番で、どんな条件に沿って整理・計算・判断するか	AIが適切にまとめる
出力	誰に、どんな形式で渡し、どこまでを完了とするか	週報が完成する
例外	材料不足や処理失敗が起きたら、どこで止めて誰に知らせるか	エラーは適宜対応する

仮想例：活動記録から週次報告の下書きを作る

以下は仕様の書き方を示す架空の業務です。実際の顧客案件や、動作を検証したシステムではありません。元の活動記録は変更せず、確認用の下書きを作るところまでを対象にします。

1．入力：場所・必須項目・対象範囲を指定する

入力は、指定された社内フォルダに業務担当者が置く活動記録の表です。「記録ID、実施日、案件名、活動内容、承認状態」を必須項目にします。対象期間の開始日と終了日は担当者が指定し、期間内で承認状態が「承認済み」の行だけを報告対象にします。

開始の合図は、担当者が入力ファイルと対象期間を指定して実行すること、と決めます。この段階では、毎週の無人実行や複数フォルダの探索は対象に含めません。

記録ID・実施日（仮想）	内容	承認状態
R01・9月7日	案件A：提案資料の見直し項目を確認した	承認済み
R02・9月8日	案件B：次回説明会の資料を準備した	承認済み
R03・9月9日	案件C：日程調整について担当者に確認中	確認中

対象期間を同じ年の9月7〜13日と指定した場合、R01とR02が対象です。R03は承認状態が条件に合わないため、報告本文には含めず除外件数へ記録します。実際の仕様では年も含む日付形式を決め、対象期間と同じ基準で判定します。

2．処理：決まった規則とAIへ任せる整理を分ける

まず必須項目と日付、記録IDの重複を確認します。問題がなければ、対象期間と承認状態で行を絞り、件数を数えます。このように条件が決まった抽出や計算は、規則として記述します。

その後、対象になった活動内容をAIで読みやすい短文へ整える案にします。元の記録にない成果、契約金額、確定した予定は補わせず、各文に元の記録IDを付けます。AIへの依頼にも、この制約を明記します。

対象行の活動内容を、社内週次報告の下書きへ整理してください。
活動内容に書かれた事実だけを使います。
成果の評価、契約状況、日付や金額を推測で追加しないでください。
各項目の末尾に、参照した記録IDを残してください。
意味を確定できない箇所は、本文とは別の「要確認」に記載してください。

これは指示例であり、出力の正しさを保証するものではありません。件数は前段の集計結果を使い、AIが文章中で数え直した値へ置き換えない設計にします。

3．出力：受け渡す場所と、完了の意味を決める

出力先は入力フォルダとは別の「確認用下書き」フォルダとし、対象期間と作成時刻を含むファイル名で保存する案です。既存のファイルを勝手に上書きしません。読み手は報告担当者で、社員への配信は担当者の確認後に別の工程で行います。

先ほどの入力に対して、期待する下書きは次のように書けます。これは仕様説明用に人が用意した出力例です。

週次報告 下書き：9月7〜13日
対象：承認済み2件／承認状態による除外1件

・案件Aの提案資料について、見直し項目を確認した。（R01）
・案件Bの次回説明会に向け、資料を準備した。（R02）

確認状態：担当者の確認待ち
配信：未実施

この例の「自動化が完了した状態」は、対象件数と照合可能な記録IDを含む下書きが保存され、確認担当者が見られることです。下書きが作れたことを、報告の承認や配信の完了として扱いません。

4．例外：成功と区別できる終了状態を書く

材料を読めなかった状態と、正しく読んだうえで対象が0件だった状態を分けます。どちらも空の報告として出してしまうと、担当者が処理の失敗に気づけません。

起きたこと	今回の仕様メモで決める対応
入力ファイルにアクセスできない	処理を止めて「入力取得失敗」と通知。報告の下書きを作らない
必須項目の欠落、読めない日付、記録IDの重複がある	該当する行と理由を担当者へ返し、修正されるまで処理を止める
正常に読み込めたが、対象行が0件	「対象なし」の確認記録を残す。前回の報告を流用しない
AIの処理失敗、または保存先へ書き込めない	「下書き未完成」と通知。完成扱いにせず、再実行するかを担当者が判断

通知先は報告担当者とし、不在時の連絡先も仕様メモへ加えます。ここでは最初の業務の境界を決めています。再実行時の重複防止や復旧の細部は、実装する方式に合わせて別途設計します。

仕様メモの食い違いを、小さな入力例で見つける

業務担当者と作る人が、同じ入力例から同じ期待結果を説明できるか確かめます。次の確認表は、設計段階で使う例です。システムの試験を実施済みという意味ではありません。

用意する入力	期待する結果	合意する点
承認済み2行、確認中1行	報告対象2件・除外1件。本文にR03の活動を含めない	承認状態の表記と除外の扱い
形式は正しいが対象期間の行が0件	対象なしの確認記録。報告本文は生成しない	0件と処理失敗の区別
同じ記録IDが2行にある	処理停止。重複した行を担当者に返す	勝手に一方を選ばない
実施日が日付として読めない	処理停止。修正対象を担当者に返す	AIに日付を推測させない

期待結果が割れた箇所は、作り始める前に業務ルールを決めます。仕様が変わったら、入力例と期待結果も同時に更新すると、古い説明のまま進むことを防げます。

相談へ持ち込むための仕様メモ

目的：［誰の、どの手間や困りごとを減らしたいか］
対象範囲：［始まり → 終わり］
入力：［用意する人／場所／形式／必須項目／対象期間］
処理：［決まった規則／AIへ任せる整理／人が判断する点］
出力：［成果物／保存先／受け取る人／完成の条件］
例外：［起き得る問題／止め方／通知先／修正する人］
記入例：［具体的な入力と、期待する出力を一つずつ］
対象外：［今回は自動化しない工程］
未決事項：［権限・保存期間・運用条件など／確認者／期限］

分からない欄を推測で埋める必要はありません。「保存先は情報システム担当と確認」と残せば、次に誰へ何を聞くかが明確になります。

よくある質問

ツールを決めてから仕様を書いたほうがよいですか。

仕事の入力・出力と完成条件は先に整理できます。その後で、候補ツールが接続先や情報の取り扱い条件に合うかを確認します。ツール選びで分かった制約があれば、仕様の範囲を戻って調整してください。

AIを使わない自動化にも、このメモは使えますか。

使えます。決まった転記や集計だけなら、処理欄へ規則を書きます。AIによる文章整理が必要な箇所がなければ、無理に追加する必要はありません。

社内資料を渡せない場合は、相談できませんか。

最初は項目名、形式、架空の入力・出力例から整理できます。ただし、実装を判断する段階では、権限や接続条件、実データ特有の例外を確認する必要があります。秘密情報を含む資料を、そのまま問い合わせフォームへ貼り付けないでください。

入力の列は、名前だけでなく意味を定義する

同じ「日付」という列でも、活動した日、入力した日、承認した日では対象期間の判定が変わります。週次報告の例では実施日を使うと決めているため、入力日や承認日で代用しないことを仕様へ書きます。作る人が業務の意味を推測しなくて済むよう、各列に短い説明を付けます。

列	意味	確認する条件
記録ID	活動記録を識別する番号	空欄と重複がないこと
実施日	活動が行われた日	年を含み、日付として確認できること
案件名	報告で使う案件の名称	どの案件か判別できること
活動内容	実施した活動の記録	空欄の場合の扱いを決めること
承認状態	報告へ含めてよい状態か	採用する値を「承認済み」として定義すること

列名を変えて受け取る可能性がある場合は、どこまで対応するかも決めます。「実施日」が「日付」になっていても自動で同じ列だと解釈するのか、形式違いとして担当者へ戻すのかを合意します。自動化の入口を厳密にするか柔軟にするかは、実際の入力と確認の負担から選びます。

出力例から、完成の判定条件を作る

期待する下書きが書けたら、その内容を確認項目へ変えます。「読みやすい週報」という表現だけでは、担当者と実装者で完成の判断が分かれます。件数、記録ID、含めない情報、保存先、確認状態など、確認できる条件を並べます。

今回の完成条件：
・指定期間の承認済み行だけを報告へ含める。
・報告の対象件数と、抽出した行数が一致する。
・各文から元の記録IDへ戻れる。
・R03のような確認中の活動を、承認済みの本文へ含めない。
・保存された下書きを、報告担当者が閲覧できる。
・下書きの確認状態と、配信が未実施であることが分かる。

こうした条件は、実装後の確認にも使います。自然な文章が出ても対象外の行が含まれていれば、今回の仕様では完成ではありません。保存できたが担当者が開けない場合も同様です。生成、保存、受け渡しを別々に確認できる状態にします。

再実行するときの扱いを、運用前に決める

処理に失敗してやり直す場合、同じ期間の下書きが複数できることがあります。また、担当者が連続して実行した場合にも、どちらを確認すればよいかが分からなくなります。対象期間、入力ファイルの版、実行時刻を記録し、今回の出力を見分けられるようにします。

この例では、元の下書きを自動で上書きせず、新しい実行の出力を別に保存する案が考えられます。その場合、担当者はどの版を採用するかを決め、旧版を参照しないよう案内します。実装方式によっては同じ入力の重複実行を検出する設計もありますが、何を同じ入力とみなすかの条件が必要です。

状況	仕様メモで決めること
途中で失敗し、保存が済んだか不明	出力と実行記録を確認してから再実行する
入力の一行を直して再実行	入力の版と変更行を記録し、新しい出力を識別する
同じ入力で二度実行	重複を検出するか、別の出力として残すかを決める
古い下書きを既に確認した	更新後にどの確認をやり直すかを決める

「エラーなら自動で何度でも再試行」とだけ書かず、どの処理まで終わったかを調べられるようにします。外部への配信を将来追加する場合は、下書き生成の再実行と、送信の再実行を同じ扱いにしない設計が必要です。

仕様の変更は、入力例と期待結果も一緒に直す

運用中に「確認中の行も参考として載せたい」と要望が出たら、本文へ含めるのか、別の確認欄へ載せるのかを決めます。承認済みと同じ形式で混ぜると、最初に決めた報告の意味が変わります。変更する出力と、変えない抽出条件を分けて記録してください。

仕様メモだけを書き換え、確認用の入力例をそのままにすると、作る人がどちらを基準にすればよいか迷います。変更した日、理由、合意した人、対応する入力例と期待結果を残します。以前の通常例も再確認し、別の条件へ影響が出ていないかを見ます。

相談時には、未決事項を担当者付きで渡す

仕様メモの空欄は、分からないことを隠さず、誰に確認するかを記入します。保存先の権限は情報システム担当、報告対象の状態は業務責任者、実際の確認手順は報告担当者、といった形で相談先を分けると、実装を始める前に必要な確認が見えます。

自動化する業務自体をまだ選んでいない場合は、AI化する業務の棚卸しと優先順位の付け方を先に使えます。一つの業務を選んだ後、この記事の4項目と入力・出力の例を揃え、どこまで作れば役立つかを具体的にしてから相談してください。