スキャン→フォルダ→自動処理をつなぐ設計

「スキャナは買った。フォルダにも入っている。それでも結局、誰かがExcelに手で打ち込んでいる」——紙をデータにする取り組みは、この状態で止まりがちです。

結論から言うと、詰まっているのはスキャナと処理をつなぐ3つの接ぎ目です。保存先の一本化、ファイル名の決まり方、処理を起動する条件。この3つを設計しないと、機器を増やしても手入力は残ります。

株式会社Fyveは中小企業の業務をAI前提に組み替える立場から、この記事では機器の紹介ではなく、つなぎ目の設計と運用ルールの決め方を扱います。

「スキャンしたのに何も起きない」の正体

紙をデータ化する流れを1本の線として見ていると、なぜ手入力が残るのか分かりません。実際には少なくとも3つの接ぎ目があり、どれか1つでも切れていると、その先はすべて人の手作業に戻ります。

• 接ぎ目1：スキャナ → フォルダ——読み取った紙が、どのフォルダにどんな名前で置かれるか
• 接ぎ目2：フォルダ → クラウド——そのフォルダが自分のPCの中だけなのか、社内の誰からも見える場所なのか
• 接ぎ目3：フォルダ → 処理——ファイルが置かれたことをきっかけに、何かが自動で動くのか

よくある状態は、接ぎ目1だけがつながっていて、2と3が切れているケースです。スキャナ付属のソフトが自動でPCの「スキャン」フォルダに保存してくれる。ここまでは動く。しかしそのフォルダは担当者のPCの中にあり、他の人には見えず、そこから先は担当者が1件ずつ開いて内容を確認し、Excelに転記している。スキャナは紙を画像にしただけで、業務は1ミリも変わっていない状態です。

この記事では接ぎ目ごとに、決めるべきことと詰まりどころを分けて整理します。順番も重要で、3から作ろうとすると必ず崩れます。1と2が固まっていないうちに自動処理を組むと、フォルダ構成を変えた瞬間に全部止まるからです。

接ぎ目1：保存先を1本に決める

最初にやるのは、スキャンした紙が置かれる場所を1つに決めることです。当たり前に聞こえますが、実際には複数の入口が併存している会社が多いです。

• 複合機のスキャン機能で、メールに添付して自分に送る
• 複合機から共有フォルダに直接保存する
• 卓上のシートフィードスキャナで、PCのローカルフォルダに保存する
• スマホのカメラで撮って、そのままスマホの写真に入っている

この4つが同時に走っていると、「あの書類はどこにあるか」が人の記憶に依存します。まず入口を1つに決めて、残りは使わないと宣言する。使えないようにするのではなく、使ってよい入口を1つだけ明示するのが現実的です。

取り込み方式の選び方

入口を決めるときの判断軸は、紙が発生する場所と件数です。

• 紙が1か所にまとまって届き、件数が多い：シートフィードスキャナまたは複合機。まとめて通せる形が効きます
• 紙が現場に分散していて、その場で処理したい：スマホのカメラ。持ち歩ける利点が大きい
• 大きさや紙質がばらつく：スキャナに通すと詰まるものがあるため、スマホと併用する前提で設計します

スキャナ本体の選定より重要なのは、付属ソフトで保存先とファイル名の規則を固定できるかです。読み取りボタンを押すたびに保存先を選ばせる設定になっていると、置き場所は必ずばらけます。読み取り設定を用途ごとに登録しておき、担当者は「どのボタンを押すか」だけを選ぶ形にします。具体的な設定方法は機種ごとに違うので、使っている機種の公式マニュアルで、保存先の固定とファイル名の自動生成に対応しているかを確認してください。

PDFと画像のどちらで保存するか

後段の処理を考えるなら、1件＝1ファイルになる形を優先します。複数枚の紙を1つのPDFにまとめる設定は、書類がもともと複数ページの契約書なら正しいですが、レシート20枚を1つのPDFにすると、後で1件ずつに分ける作業が発生します。何を1件として数えるかを決めてから、ファイルの区切りを合わせます。

接ぎ目2：ローカルからクラウドへ移す

保存先がPCのローカルフォルダのままだと、その先の設計が全部詰まります。他の人が見られない、自動処理を組んでも動くのはそのPCが起動しているときだけ、そのPCが壊れたら消える。データ化の意味の半分はここで失われます。

Microsoft 365を使っている会社なら、置き場所はOneDriveかSharePointのドキュメントライブラリになります。使い分けの原則はシンプルです。

• OneDrive：個人の作業領域。その人が主に扱うもの、下書き、一時的なもの
• SharePoint：組織の共有領域。業務として複数人が扱うもの、記録として残すもの

スキャンした請求書やレシートは業務の記録なので、SharePointのドキュメントライブラリに置くのが筋です。担当者のOneDriveに置くと、その人が退職したときにアクセス権の整理が必要になります。「個人が持っている業務データ」という状態を作らないのが原則です。

同期フォルダを経由するときの注意

スキャナがネットワーク上のクラウドに直接保存できない場合、PCのOneDrive同期フォルダに保存して、同期でクラウドへ上げる形になります。この構成は動きますが、同期の性質を理解しておく必要があります。

Microsoftの公式ドキュメントでは、OneDriveやSharePointのコネクタについて、ファイルを別のライブラリへ移動・同期した場合、作成日時などのメタデータは変更されないため、そのライブラリのファイル更新を検知するフローはトリガーされないと説明されています。つまり「同期で上がってきたファイル」は、条件によっては新規作成として扱われないことがあります。自動処理を同期経由のファイルで動かす設計にする場合は、この点を実機で確認してから本番に載せてください。

ファイル命名規則の設計

命名規則は、地味なのに後段のすべてに効く部分です。ここが崩れていると、探せない・重複に気づけない・自動処理で振り分けられない、の3つが同時に起きます。

使えない文字を先に把握する

Microsoftの公式サポート情報では、OneDriveおよびSharePointでファイル名・フォルダー名に使用できない文字として次が挙げられています。

• 使用できない文字：" * : < > ? / \ |
• ファイル名またはフォルダー名の先頭と末尾のスペース
• 一部の組織では # と %
• 使用できない名前：.lock、CON、PRN、AUX、NUL、COM0〜COM9、LPT0〜LPT9、_vti_、desktop.ini、~$ で始まる名前

実務で引っかかるのは、日付の区切りに使いたくなる「/」と、金額や備考に入りがちな「:」です。取引先名に「株式会社○○/△△支店」のような表記が入ることもあります。命名規則を作るときは、この文字を含まない構成にすると決めておきます。

命名の構成要素

後で機械的に扱えることを優先すると、次の順序が扱いやすいです。

• 日付を先頭に置く：20260806 の形。ハイフン区切りでも構いませんが、桁数を固定します。ファイル名順に並べるだけで時系列になります
• 種別：invoice receipt slip など。日本語でも動きますが、後で処理する際に表記ゆれが出にくいのは英字です
• 識別子：取引先の略称や店舗コード。ここで表記ゆれが出るので、選択肢から選ばせる形にします
• 連番：同じ日・同じ種別・同じ相手で複数ある場合の枝番

例：20260806_receipt_A01_02

命名は人に任せない

いちばん重要な原則です。人が自由入力で名前を付けると、必ずばらけます。「請求書」「請求書_○○社」「20260806請求書」「スキャン0001」が同じフォルダに並ぶ状態は、ルールを文書で配っても解決しません。

対応は2つです。自動で付けるか、選ぶだけで決まるようにするか。スキャナ付属ソフトの自動命名で日付と連番を入れ、種別と識別子はボタン（プロファイル）ごとに固定する。スマホからならフォーム経由で選択させ、ファイル名はフロー側で組み立てる。自由入力欄を作らないのが設計の要点です。

フォルダ設計は「処理の状態」で切る

フォルダ構成でよく見るのが、年月で細かく切る形です。2026/08/ のように分けると人間の感覚には合いますが、自動処理を載せると扱いにくくなります。理由は次の節で触れるトリガーの制約です。

おすすめは、まず処理の状態で切ることです。

• 01_受信箱：スキャンした直後のファイルが入る。処理待ち
• 02_要確認：読み取れなかった、値が疑わしいなど、人の判断が必要なもの
• 03_処理済み：データ化と確認が終わったもの。ここから月別に分けてもよい

この形にすると、受信箱を見れば残件が分かるという状態になります。年月で切っていると、今日やるべきものがどこにあるのか一目で分かりません。「未処理が視覚的に見える」ことが、運用が続くかどうかを左右します。

月別の整理は、処理済みの中で行えば十分です。検索はフォルダ構成に依存せずファイル名やメタデータでできるので、探すために深い階層を作る必要はありません。階層は浅く、状態で分ける。これが自動処理と相性のよい形です。

接ぎ目3：処理を起動する条件と、その落とし穴

ここが技術的にいちばん詰まるところです。Microsoft 365環境ならPower Automateのフローで、フォルダにファイルが置かれたことをきっかけに処理を動かすのが基本形になります。ただし、トリガーの選び方と制約を知らずに組むと、動いたり動かなかったりする不安定な仕組みになります。以下はMicrosoftの公式ドキュメントに記載されている内容です。

サブフォルダーで発火しないトリガーがある

SharePointコネクタの「フォルダーにファイルが作成されたとき」というトリガーについて、公式ドキュメントにはこのトリガーが動作しているフォルダー内のサブフォルダーにファイルを追加または更新した場合、このトリガーは実行されないと明記されています。サブフォルダーでトリガーしたい場合は、サブフォルダーごとに別のフローを作る必要があるとされています。「フォルダー内でファイルが作成または変更された場合」も同様の制約が記載されています。

さらに、この2つのトリガーは非推奨と表示されており、期待どおりに機能しない可能性があるとされています。推奨される代替として、それぞれ「ファイルの作成時 (プロパティのみ)」「ファイルが作成または変更されたとき (プロパティのみ)」が挙げられています。後者については、特定のフォルダーを対象とする場合は "Folder" プロパティに値を指定し、指定しなければライブラリ全体が対象になると説明されています。

この制約が、前節で「フォルダ階層を浅くする」と書いた理由です。年月で深く切ったフォルダに投入する設計にすると、フォルダを増やすたびにフローを増やすことになります。受信箱を1つにしておけば、監視対象は1つで済みます。

移動したファイルは新規と見なされない

OneDriveコネクタの「ファイルの作成時」トリガーには、OneDrive内で移動されたファイルは新しいファイルとは見なされないと記載されています。SharePointコネクタの既知の制限にも、ライブラリ間でファイルを移動しても作成日時などのメタデータは変更されないため、移動先のライブラリに関連付けられたファイル更新のフローはトリガーされない、という説明があります。

「いったん仮置きフォルダに入れて、確認したら処理フォルダへ移動し、そこで自動処理が走る」という設計を考えたくなりますが、この制約により意図どおり動かない可能性があります。移動をきっかけにするのではなく、作成をきっかけにするのが基本です。

サイズと件数の上限がある

OneDriveコネクタでは、ファイルの作成時・変更時トリガーは50MBを超えるファイルをスキップすると記載されています。また、新規ファイルと変更ファイルのトリガーは、2つのトリガーポーリングの間に約30を超える保留中の変更があると問題が発生する可能性があるとされています。調整制限としては接続ごとのAPI呼び出しが60秒あたり100回と示されています。

この制約は、まとめてスキャンする運用と衝突します。月末に100件を一気に投入するという使い方は、まさにこの上限に当たりやすい形です。週次や日次に分散させる運用ルールは、業務負荷の平準化のためだけでなく、仕組みを安定させるためにも必要になります。高解像度でスキャンした大量ページのPDFがサイズ上限に触れる可能性もあるため、解像度の設定は「要件を満たす範囲で必要以上に上げない」のが実務的です。

起動は即時ではない

SharePointコネクタの既知の制限には、Power Automateがトリガーで構成されたリストまたはライブラリの変更を定期的にチェックすると説明されています。ほとんどの場合、変更から数分以内にフロー実行が発生する可能性があるとしつつ、最後の変更からの間隔や後続の編集により、1回の実行で複数の変更をまとめて拾う場合があるとされています。

つまりスキャンした瞬間に結果が返ってくる仕組みにはならないということです。現場に「スキャンしたらすぐ結果が出る」と説明すると、数分の待ちがクレームになります。「翌営業日の朝までに処理される」といった約束の仕方にしておくほうが、運用として無理がありません。

「誰がいつスキャンするか」を先に決める

ここまで技術的な接ぎ目を扱いましたが、実際に運用が止まる最大の原因は仕組みではなく担当と頻度が決まっていないことです。

決めるべきことは4つだけです。

• 誰が：スキャンする人を役割で決める。「気づいた人」は決まっていないのと同じです
• いつ：曜日と時刻。「週の初めに」ではなく「月曜の始業後」まで落とします
• 何を：対象の書類の種類。全部ではなく、まず1種類から始めます
• 終わったことをどう示すか：処理済みフォルダへ移す、原本に印を付ける、など

最後の項目が抜けがちです。スキャン済みの紙とまだの紙が机の上で混ざると、二重にスキャンするか、抜けるかのどちらかが起きます。物理的な区別（トレイを2つに分ける、済んだものにスタンプを押す）を決めておくのが確実です。

担当を1人に固定すると、その人が休んだ日に止まります。主担当と副担当を決めて、副担当も月に一度は実際にやってみる形にしておくと、手順書が現実と乖離しているかどうかも分かります。

失敗を検知できるようにする

自動化の落とし穴は、止まったことに気づけないことです。人がやっていれば「今日は終わらなかった」と分かりますが、フローは黙って失敗します。

最低限、次の2つは組み込みます。

• 失敗の通知：フローがエラーになったときに担当者へ通知が飛ぶようにする
• 残件の可視化：受信箱フォルダに何件残っているかを、毎朝または週次で確認する運びにする

「要確認」フォルダも同じ役割を持ちます。読み取れなかったものが黙って捨てられる設計ではなく、明示的にそこへ溜まる設計にしておけば、件数を見るだけで異常が分かります。件数を見る習慣がひとつあれば、仕組みが壊れていても気づけます。

どこから作るか

順番を間違えると、作ったものを作り直すことになります。

• 第1段階：置き場所と命名を固める。SharePointに受信箱・要確認・処理済みの3つを作り、命名規則を決めて、スキャナ側の設定に反映する。自動処理はまだ組みません。この段階だけで「書類が行方不明になる」問題は解消します
• 第2段階：運用ルールを回す。誰がいつスキャンするかを決めて2〜4週間回します。ここで実際に来るファイルの種類・サイズ・件数・例外の実態が分かります。この情報がないまま自動処理を設計すると、想定外の入力で壊れます
• 第3段階：自動処理を1本だけ載せる。最初は「受信箱にファイルが置かれたら一覧表に1行追加する」程度から始めます。読み取りや振り分けは、この1本が安定してから足します

逆にやらないほうがよいことも挙げておきます。

• いきなり全書類を対象にする：書類の種類ごとに例外が違うため、複雑さが掛け算で増えます
• フォルダ階層を先に細かく作る：トリガーの制約と衝突し、フロー本数が増えます
• 担当者のPCローカルで完結させる：属人化が固定され、後で移すコストが大きくなります
• 結果の確認を人がやらない設計にする：間違いに気づくのが決算になります

読み取りと集計をどうつなぐか

フォルダまで届いたファイルから項目を取り出す部分は、この記事の範囲の外側にあります。ただし設計としてひとつ言えるのは、読み取り精度は入力の質と候補の絞り方で変わるということです。取引先名や商品名をマスタとして持たせ、候補集合を制限する考え方は別記事で扱っています。

CopilotAIの読み取り精度を上げるマスタ設計

取り出したあとの集計をExcelで持つ場合、Copilotに任せられるのは表の形が整ってからです。基本的な操作や環境の前提は基礎編を参照してください。Microsoft 365 Copilotの使い方とExcelのCopilot使い方で扱っています。導入前の環境設定はCopilotのインストールと有効化の手順にまとめています。

レシートや小口現金のように少額多件数の書類を対象にする場合は、締めのタイミングと立替精算の設計が先に来ます。

Copilotレシート・小口現金のデータ化｜運用設計の手順

店舗の売上データを同じ受け皿に集める場合は、フォルダ設計に店舗コードを組み込む形になります。締めの定義から順に整理した内容は店舗の売上集計をデジタル化する設計で扱っています。

よくある質問

複合機のスキャン機能だけで足りますか

共有フォルダに直接保存でき、保存先とファイル名の規則を固定できるなら足ります。判断のポイントは機器の性能ではなく、操作する人が毎回選択せずに済むかです。読み取りのたびに宛先や名前を入力させる設定になっているなら、そこがばらつきの原因になります。

OneDriveとSharePointはどちらに置くべきですか

業務の記録として複数人が扱うものはSharePointです。個人の下書きや一時的な作業ファイルはOneDrive。スキャンした請求書やレシートは業務記録なので、SharePointのドキュメントライブラリが適切です。担当者のOneDriveに置くと、異動や退職のときにアクセス権の整理が必要になります。

ファイル名を日本語にしても大丈夫ですか

日本語のファイル名自体は使えます。ただし使用できない文字（" * : < > ? / \ |）は日本語の文書名にも混ざりやすいので注意が必要です。また、一部のアクションではファイル名のマルチバイト文字がサポートされない場合があるとMicrosoftの公式ドキュメントに記載されています。自動処理の対象にするファイルは英数字と記号を限定した命名にしておくと、想定外の詰まりを避けられます。

スキャンした紙はいつ捨てられますか

これは電子帳簿保存法の要件を満たしているかどうかで決まり、税務の判断が絡みます。要件の充足と自社への当てはめは顧問税理士に確認してください。仕組みの側でできるのは、要件を満たせる形で保存・検索できる状態を作るところまでです。

フローが動かないときは何を見ればよいですか

順番に切り分けます。ファイルは想定した場所に置かれているか（接ぎ目1）、クラウド側に上がっているか（接ぎ目2）、トリガーの対象フォルダは合っているか、サブフォルダに入っていないか、移動で持ち込んだファイルではないか、サイズが上限を超えていないか（接ぎ目3）。この順で見ると、たいていどこかで止まっています。

スキャンから処理までどれくらいで終わりますか

即時ではありません。Microsoftの公式ドキュメントでは、Power Automateがライブラリの変更を定期的にチェックし、多くの場合は変更から数分以内に実行される可能性があるとされていますが、複数の変更をまとめて拾う場合もあると説明されています。現場への説明では「数分後」ではなく「その日のうち」程度の約束にしておくほうが安全です。

紙とデータの二重管理を避けるにはどうすればよいですか

二重管理が起きるのは、どちらが正なのかを決めていないときです。データ化した後は原本を業務で参照しない、というルールを明示し、原本は保管箱に入れて日常の動線から外します。原本が机の上に残っている限り、人はそちらを見ます。

まとめ

スキャナから処理までをつなぐには、3つの接ぎ目を順番に固めます。

• 入口を1つに決める。読み取りのたびに保存先とファイル名を選ばせない
• 置き場所はローカルではなくクラウドの共有領域に。業務記録は個人の領域に置かない
• 命名は人に任せず、自動生成か選択式にする。使えない文字を先に把握する
• フォルダは年月ではなく処理の状態で切る。階層は浅くする
• トリガーの制約を前提に設計する。サブフォルダで発火しないもの、移動では発火しないもの、サイズ上限、実行は即時でないこと
• 誰がいつ何をスキャンし、済んだことをどう示すかを決める
• 失敗の通知と残件の可視化を必ず入れる
• 置き場所と運用を2〜4週間回してから、自動処理を1本だけ載せる

機器を増やしても業務は変わりません。変わるのは、接ぎ目が全部つながったときだけです。私はこの順番で組むことを勧めています。