1. 試したこと：頻度だけで最初の工程を選ばない
繰り返しが多い仕事でも、入力してよい情報が決まらない、確認する人がいない、結果がそのまま本番へ反映されるなら、最初に試す候補として進められません。今回は、そのようなカードを保留にし、既存機能で足りる仕事を分けたうえで、試せる1工程を残せるかを確かめました。
判断の順番は最初にAI化する業務の選び方を前提にしています。一般的な選び方の説明はそちらに譲り、この記事では架空のカードと照合の記録を示します。選んだ後の分類・返信作成を試す問い合わせの検証ラボとも、扱う段階が異なります。表の欠損・古い記録・単位違いを調べる試作ではありません。
IPAの説明には、要約や文書作成などの活用が紹介されています。個人情報保護委員会の掲載ページは生成AIの利用に関する注意喚起を案内しています。どちらも背景資料であり、以下の区分や試作結果はhirostaによるものです。
2. 作り方の要点：カードと想定を先に固定する
架空の業務カード8件
頻度と件数は比較のために作った設定で、実測の業務量ではありません。担当A〜Dも架空です。「入力可」は今回の架空情報に限った設定で、実データを入力してよいという意味ではありません。資料名や機能も架空の条件で、特定製品の対応保証ではありません。
読みやすさのため、同じカードを2つの表に分けています。横長の表はスマホで横にスクロールできます。
| 番号・困っている作業 | 頻度・件数の設定 | 入力 → 出力 | 入力してよい範囲・根拠の資料 |
|---|---|---|---|
| B01 相談文の要約 | 毎日40件 | 顧客情報を含む想定の架空相談文 → 要約の下書き | 入力可否は空欄。相談原文・要約の記載項目表はある |
| B02 作業メモの引き継ぎ要約 | 毎日30件 | 架空作業メモ → 引き継ぎ案 | 架空メモのみ可。作業メモ・引き継ぎ項目表が根拠 |
| B03 依頼文の振り分け | 毎日50件 | 架空依頼文・分類表 → 担当区分 | 架空依頼文・分類表のみ可。分類表が根拠 |
| B04 固定列の月別合計 | 毎週120行 | 月・金額の架空表 → 月別合計表 | 架空表のみ可。集計手順書が根拠 |
| B05 受付完了の固定文の用意 | 毎日25件 | 架空受付番号・承認済み固定文 → 番号だけを差し替えた文 | 架空番号・固定文のみ可。承認済み受付文が根拠。個別回答は対象外 |
| B06 期限表の取り込みと通知 | 毎日20行 | 形式がそろった管理番号・期限の架空CSV → 取り込み一覧・期限通知の候補 | 架空番号・期限のみ可。列対応表・期限通知ルールが根拠 |
| B07 個別契約の例外条項の承認 | 毎月3件 | 架空条項・標準案 → 例外を受け入れるかの承認案 | 架空条項・標準案のみ可。標準条項はあるが例外の判断基準は未整備 |
| B08 問い合わせ受付から送信まで全体 | 毎日15件 | 架空質問・承認済みFAQ → 全体では回答・送信、切り出せば根拠番号付き返信下書き | 架空の定型質問・FAQのみ可。契約変更・苦情は除外。FAQが根拠で、該当しなければ保留 |
| 番号 | 確認する人・照合先 | 登録・送信の前に止める方法 | 今使うツール・既存機能の設定 |
|---|---|---|---|
| B01 | 受付担当A／原文・記載項目表 | 別ファイルの下書きだけ。送信なし | メール・文書編集。定型文だけでは内容の要約はできない |
| B02 | 確認者は空欄／作業メモ原文 | 下書き保存だけ。台帳登録なし | 共有文書。見出しのひな形はあるが要約は手作業 |
| B03 | 受付担当A／原文・分類表 | 空欄。分類結果がそのまま担当台帳へ反映される想定 | 業務ソフトの直接反映を使っている |
| B04 | 集計担当B／元表・集計手順書 | 確認用シートだけ。確定表を上書きしない | 表計算の条件付き合計・ピボット集計が使える |
| B05 | 受付担当A／番号・承認済み文面 | 送信前の文書だけ。宛先は作らない | メールの定型文が使える |
| B06 | 管理担当C／CSV原文・列対応表・通知ルール | 取り込み用の仮一覧・通知一覧だけ。実登録・送信なし | 業務ソフトのCSV取り込み・期限通知が使える |
| B07 | 責任者D／原文・標準条項。ただし例外の妥当性は照合できず、専門判断の確認先も未定 | 承認・署名前の文書案で停止 | 文書編集。例外ごとに判断が異なる |
| B08 | 受付担当A／質問原文・FAQの該当番号 | 切り出した下書き専用文書で停止。送信ツールへ接続しない | メール・共有FAQ。言い回しの整理は手作業。固定文だけで足りる質問はB05へ戻す |
B08の確認・停止の条件は、切り出した下書きだけに対するものです。受付から送信まで全体を試せる条件がそろったとは扱いません。
分類前に固定した想定の結果表
カードを作った後、コードの実行とAIの候補作成より先に、次の想定を保存し、ファイルのハッシュを記録しました。候補を見てから区分を合わせる変更はしていません。
| 番号 | 想定の区分・理由 | 保留を解く条件、または候補を進める際の確認 | 試すなら絞る1工程 |
|---|---|---|---|
| B01 | 保留：入力可否が未定 | 情報管理責任者が入力範囲を決める | 許可された相談文の要約下書き |
| B02 | 保留：確認者が未定 | 原文と照合する担当者を決める | 引き継ぎ要約案の作成 |
| B03 | 保留：反映前の停止方法が未定 | 本番反映を外した確認用一覧へ切り替える | 担当区分の候補一覧だけ |
| B04 | 既存機能・通常の自動化の候補：固定列の集計 | 保留ではない。関数の対象範囲を確認 | 月別合計シートの作成 |
| B05 | 既存機能・通常の自動化の候補：固定文で足りる | 保留ではない。文面と番号を確認 | 受付完了文の差し込み |
| B06 | 既存機能・通常の自動化の候補：列対応と期限ルールが固定 | 保留ではない。列対応と通知条件を確認 | まずCSVの取り込み用仮一覧。通知は別工程 |
| B07 | 保留：例外の照合基準と専門判断の確認先が足りない | 責任者が専門家への確認経路と例外基準を整理 | 現状では選ばない。人による判断基準の整理が先 |
| B08 | AIを試す候補：根拠を照合でき、送信前に止められる下書きに限定できる | 保留ではない。範囲を広げるときは再確認 | 定型質問1種類のFAQ根拠番号付き返信下書き |
保留を解く条件は質問の下書きであり、その条件がすでに満たされたとは扱いません。
コードは欄の有無、AIは区分の候補を整理する
macOS・Node.js 24.21.0の短いスクリプトを手元で動かしました。入力可否・確認者・照合先・停止方法の文字列が空かどうかを、元のカードから一覧にしています。次が処理の中心です。
const fields = ['inputPermission', 'reviewer', 'reference', 'stop'];
const result = cards.map(card => ({
id: card.id,
missing: fields.filter(field => !card[field]?.trim()),
}));コードは「欄あり」を導入可能や安全という意味には変換しません。B07の「例外の妥当性は照合できない」も文字列なので、空欄にはなりません。
次にカードとコードの一覧を読み、汎用の生成AIに指示して処理した部分が、区分の候補・理由・不足・1工程の整理です。作業しているAI自身が処理し、別のモデルや外部APIは呼んでいません。指示は次の方針にしました。
元のカード番号を残す。入力可否・確認者と照合先・反映前の停止方法が
決まらなければ保留する。欄が埋まっていても、確認が成立するかを理由に含める。
不足を推測で補わない。残りは既存機能・通常の自動化を先に考え、
AIの候補は1工程に絞る。区分の候補・理由・不足条件・1工程を出す。
導入の可否の最終判断・効果の予測・費用の見積りはしない。3. 結果：保留4件、既存機能3件、AIの候補1件を照合した
カード8件を各1回処理し、元番号ごとに想定と読み合わせました。表の「既存」は「既存機能・通常の自動化の候補」、「AI候補」は「AIを試す候補」の略です。
| 番号 | コードの判定 | AIの区分の候補 | 固定した想定 | 一致／不一致・理由と1工程 |
|---|---|---|---|---|
| B01 | 入力可否が空欄 | 保留 | 保留 | 一致。毎日40件でも許可を補わない。許可後の要約下書きだけ |
| B02 | 確認者が空欄 | 保留 | 保留 | 一致。原文があっても確認者を補わない。担当決定後の引き継ぎ要約案だけ |
| B03 | 停止方法が空欄 | 保留 | 保留 | 一致。毎日50件でも直接反映を認めない。候補一覧で止める条件が先 |
| B04 | 4欄とも記載あり | 既存 | 既存 | 一致。合計をAIへ回さず、確認用の集計シートへ |
| B05 | 4欄とも記載あり | 既存 | 既存 | 一致。固定文を書き直させず、番号の差し込みへ |
| B06 | 4欄とも記載あり | 既存 | 既存 | 一致。転記と期限通知をAIへ回さない。まず取り込み用仮一覧へ |
| B07 | 4欄とも記載あり | 保留 | 保留 | 一致。欄があっても例外を照合できない。専門判断を代行しない |
| B08 | 4欄とも記載あり | AI候補 | AI候補 | 一致。受付から送信まで全体にはせず、FAQ根拠付き返信下書き1工程へ |
区分は8件一致、不一致は0件でした。同じAIが理由・不足条件・絞った工程まで読み合わせた範囲で、条件不足を推測で埋める提案、頻度だけでの保留解除、既存機能で足りる工程のAI化、業務全体のままの提案は見つかりませんでした。これは、意図して作った8件と固定した想定への自己照合です。実務での正解や精度を示すものではありません。
今回残ったB08も、「AIを導入する」という結論ではありません。定型質問1種類について、質問と承認済みFAQを入力し、根拠番号付きの下書きを出し、受付担当が原文・FAQと照合する計画の候補です。根拠にない質問は保留し、送信は試す範囲から外します。準備や確認の負担が大きければ、定型文や手作業へ戻す判断が必要です。
かかった時間と測った範囲
2026年10月19日16:30:41〜16:31:21（日本時間）の40秒を、カード・想定表の保存後から、条件判定コードの作成・実行、AIの候補作成、自己照合結果の保存までの経過時間として記録しました。カード・想定表の準備、資料調査、記事制作、ビルド、表示確認、人の評価は含みません。計算速度や実際の担当者の作業時間ではなく、削減率・費用効果は測っていません。
4. うまくいかなかったことと、直したこと
今回の出力では、区分の取り違えは観察されませんでした。指示やカードの書き方を直して分類が変わった例はなく、再試行もしていません。失敗例を追加して改善したようには扱いません。
一方、空欄の判定だけでは選び切れません。B07は確認者や資料の欄が埋まっていても、「例外を確認できない」という内容でした。コードの出力をそのまま進行の許可にすれば、この違いを見落とします。今回の一覧では最初から「欄あり（内容の妥当性は未判定）」と表示し、区分の判断材料と分けました。実際に人が照合できるかは未確認です。
B08も、業務名だけを取り出すと受付から送信までをAIへ任せるように読めます。記事の結果表では、下書き1工程に絞ったことを各行に残しています。これは伝え方を整えたもので、カードの条件や候補の区分を変えたものではありません。
同じAIが、保留になる条件を意図して含めたカードと想定表を作り、その想定を見られる状態で候補を出しました。したがって、未知の業務やあいまいな聞き取りでも同様に分けられるかは分かりません。欄に「確認する」とだけ書かれた場合、複数工程で入力範囲が違う場合、既存機能が実際には使えない場合も試していません。
5. 実際の業務で使う前に確認すること
経営者・担当者による評価は未実施です。実際の候補を選ぶときは、次を人が確かめる必要があります。
- 入力の範囲：情報管理の責任者が、社内ルール・契約・利用するサービスの条件を確かめます。「氏名を消せばよい」「設定があるからよい」と推測しません。
- 確認できる根拠と担当：担当者が実際に原文と出力を照合し、根拠のない案を保留にできるかを確かめます。承認・例外・専門判断をAIの候補で置き換えません。
- 反映前の停止：本番の登録・送信を外し、下書きだけで止まり、今の手順へ戻れるかを確かめます。今回は停止方法をカードに書いただけで、実ソフトの権限制御を確認していません。
- 既存機能と1工程の範囲：関数・定型文・取り込み・通知の機能が今の環境で使えるかを先に確認します。AIの候補も、入力と出力が限定できる1工程にします。
- 採用判断の記録：担当者がAIの候補を見る前に判断した表と比べ、採用・保留・理由を残します。準備と確認を含む負担や費用を比べる評価は、今回行っていません。
保留は仕事自体をやめる意味ではありません。B01なら入力範囲、B02なら照合する人、B03なら反映前の停止、B07なら判断基準と専門家への確認経路を整えてから、同じ条件で候補を見直します。
6. 最初の1工程を選ぶところから相談する
「毎日発生するからAIに任せる」と決める前に、何を入力でき、誰が何と照合し、どこで止めるかを整理できます。今回のカードは架空ですが、自社の困りごとを書き出す項目として使えます。
AI業務改善ガイドとサービス・料金も参考に、候補が決まっていない段階からご相談ください。相談の最初に、機密資料や個人情報を送る必要はありません。