1. 業務の非効率に終止符を打つ
日々の業務で「これ、手作業じゃなくてもいいんじゃないか？」と感じたことはありませんか？
ツール開発の勉強を始めてから、やたらと気になるようになりました。
毎日毎日毎日毎日毎日、週に5日は思っています（現在進行形）。
毎日毎日、まるで餃子を皮から手作りしている気分です。
お店に行けば、安くて早くておいしい餃子が食べられるのに。
皮から手作りするのは、たまにでいいんです。
この記事では、そんな課題に対し、これまで触れたことのなかった "Power Automate Desktop (PAD)" を使い、通常業務をこなしながら、常業務をこなしながら、格闘すること3日、2つのプロトタイプを制作しました。
完璧を求めず、まず動くものを作ることの重要性を学んだ、失敗だらけの奮闘記です。
2. 解決したい課題の設定
今回の取り組みで解決を目指したのは、以下の2つの業務です。
どちらも、私とチームメンバーが共通して抱えていた 「地味だが面倒」 な作業でした。
仲間にツールを提供するというよりも、ツールを使って自動で情報を収集、加工、提供することが最終目標。
みんなが手作り餃子を作るのではなく、お店で手軽に食べられるようにするイメージ。
課題1：週報作成における数値拾い
毎週、複数ページにまたがるWebサイトから特定の数値を手動で集計し、Excelに転記していました。
Excel関数を駆使し効率化していますが、それでもデータ拾いに11分かかりました（記事を書くにあたって計測してみました）。
手作業で数値転記しているほかのチームメンバーは30分くらいかかっているだろうなぁ。
数値管理の必要性は理解しつつも、非効率の極みだと感じていました。
課題2：感染症情報センター週報の取得と通知
本業は、チェーン薬局のエリア担当で、複数店舗のサポート業務をしています。
感染症情報センターが毎週発行するPDF週報から、必要な情報だけを抽出し、関係者にメールで共有する作業もその一つです。
毎週木曜日の不定時に更新されるため、まだかなーって思いながら更新ボタンをクリックしています。
最新情報を評価して、見やすく加工して、今後の推移予測などを添えて、金曜日の発注時間に間に合うように、担当する薬局に医薬品の在庫管理や人員体制のアドバイスをしています。
手動での情報収集と加工が面倒なためか、他のエリア担当はあまり活用していません。
重要な情報資産が埋もれていくのは見過ごせません。
日々の業務が、だんだん餃子の手作りに見えてきませんか？
3. 選定したツール：Power Automate Desktopを選んだ理由
これらの課題解決に、私は Power Automate Desktop (PAD) を選びました。
会社のIT基盤がMicrosoft製品で統一されているため、PADとの連携がスムーズだと考えたからです。
また、Windowsに標準装備されているため、専門知識がなくても直感的に操作できる点も、短期間でのプロトタイプ制作に適していると判断しました。
（個人的にはGeminiとお友達なのでGoogle系のツールで取り組みたかった）
4. 制作したプロトタイプと実装内容
プロトタイプ1：週報作成における数値拾いの自動化×２
実装内容
- 指定されたWebページにログイン
- 日付によって操作を分岐
- ブラウザ全画面表示とマウス座標の固定で数値を自動取得
- 取得した数値をExcelに書き出し
- 同様に、同じシステムから別のデータを取得
動画は雰囲気だけ。コードも不掲載です。
どこに機密情報が書かれているか判断できないので、ごめんなさい。
失敗と妥協点
理想はHTML要素を指定して安定的にデータを取得することでした。
しかし、ブラウザの自動化アクションはエラーを連発。
「DOM要素の動的な変化に対応」 という、初心者がぶちあたる壁らしいですね。
袋小路に迷い込んで手作業のほうが効率が良くなってしまうほどでしたが、「とりあえず動かす」ことを最優先に、確実性は低いと知りつつも、マウス座標の固定という荒業で乗り切るという大きな妥協点を受け入れました。
全画面表示にすれば、要素の位置はかわらんでしょ？？？
2つ目の数値拾いは同じシステムなので、1つ目のコピペ＆「自動化のステップを取得」であっという間に完成。
なんか、ちょっと、コツをつかんできたかも（うぬぼれ）。
餃子に入れるニンニクやショウガはみじん切りにしたいところですが、チューブで我慢。
とりあえずは、他人のPCで動かすことを想定せず、得られた情報を共有していく方針です。
これなら不具合が出ても自身で修正が可能と割り切りました。
これって業務の属人化につながるのでは、という危機感を持ちつつも、 今できることはここまで。
プロトタイプ2：感染症情報センター週報の取得と通知
実装内容
- WebサイトのPDFへのリンクを自動取得し、更新をチェック
- 最新の週報PDFをダウンロード
- PDFから必要な情報を抽出
- メール本文に箇条書きで記載して送信
Pdf.ExtractTablesFromPDF.ExtractTablesFromPage PDFFile: $'''...\\最新週報.pdf''' PageNumber: 9 MultiPageTables: True ...
SET TargetTable TO ExtractedPDFTables[0]
# --- 挫折した、理想の実装（PDFの表をHTMLテーブルに整形しようと試みた部分）---
Text.CreateHTMLContent HtmlEditor: $'''<p><table><thead><tr><th>#</th>...''' HtmlContent=> HtmlTable
...
# --- 妥協した、現実の実装（表を諦め、文字列を抜き出してメール本文を生成）---
SET InfluenzaBody TO $'''インフルエンザ 定点あたり
'''
SET CoronaBody TO $'''
新型コロナ 定点あたり
'''
LOOP FOREACH CurrentRow IN ExtractedTable
SET InfluenzaBody TO $'''%InfluenzaBody%・%CurrentRow['Column1']%： %CurrentRow[2]%
'''
SET CoronaBody TO $'''%CoronaBody%・%CurrentRow['Column1']%： %CurrentRow[4]%
'''
END
SET MailBody TO $'''%InfluenzaBody%%CoronaBody%'''
Email.SendEmail.AuthenticateAndSend ... Body: $'''%MailBody% ...''' IsBodyHtml: False ...
失敗と妥協点
PDF内の表データをテーブルとして抜き出し、表としてきれいに整形するという理想的な実装を目指しました
。コードの冒頭にある Pdf.ExtractTablesFromPDF アクションがその試みです。
しかし、表の構造を正しく読み取ることができず、途中で挫折。
AIとの長い長い試行錯誤が始まりました。
結局、LOOP FOREACH でデータを一行ずつ取り出し、SET アクションで箇条書きの文字列として整形するという、最低限の情報伝達に妥協しました。
このコードブロックは、理想と現実のギャップをそのまま示しています。
必要なのは情報、美しさではない、と自分に言い聞かせるしかありませんでした。
毎日の食卓には、最高にこだわった手作り餃子は必要ない。
※元のPDFファイル9ページ目の表
※フローの一部
※メール本文
5. 周囲からのフィードバックと考察
今回のプロトタイプについて、チームの同僚に試してもらい、率直なフィードバックをもらいました。
Oさん （プロトタイプ1について）
週報の数値拾いですか？
まぁ、業務の合間を見つけてやってますね。
スキマスキマでやっているので、何分かかっているかって言われても...。
でも、データをくれるなら、そりゃありがたいですよ.
この短いコメントは、私に多くの気づきを与えてくれました。
私はこれまで、自身の業務を 「お金を生み出す業務」 と 「そうでない業務」 に無意識に分類していました。
時間をかけて手作業で数値を拾う行為では 「お金」 は生まれません。
与えられた課題に盲目的に従う、それは、私自身も深く陥っていた「 カエルさん （思考停止状態）」です。
「データをくれるならありがたい」という言葉は、プロトタイプが一定の価値を認めてくれた証拠です。
しかし、それと同時に、このツールが提供する「業務効率化」という本質的な価値を、まだ 相手に伝えきれていない ことの表れでもありました。
今回の取り組みは、単にツールを作るだけでなく、「非効率に向き合うこと」、そして「その重要性を周囲にどう伝えるか」という、より大きな課題を浮き彫りにしました。
Uさん （プロトタイプ1について）
週報の数値拾いは、5～10分くらいです。
いろんなところを見ないといけないのが非効率ですよね。
3つのサイトからそれぞれいくつかのデータをダウンロードして、エクセルの関数を使って統合しています。
統合されたデータを送ってくれたらありがたいですけど、誰がやるんですか？
本社の仕事ですよね？
自動化っていってもPC起動できない休日はできないじゃないですか？
Uさんは、医療人でありながらITにも強い彼の視点から、より本質的な課題を指摘するものでした。
彼は作業時間を具体的に把握し、非効率性を認識している一方で、自動化の 「主体」 と 「環境」 に関する疑問を投げかけました。
この言葉は、私に多くの気づきを与えてくれました。
また、デスクトップアプリであるPADの弱点についても鋭い指摘がありました。
「PC起動できない休日はできないじゃないですか」 という言葉は、PADの自動化が、ローカル環境という制約に縛られていることを正確に見抜いていました。
Kさん （プロトタイプ2について）
解熱剤などの在庫確保などの役に立つと思います。
情報量はこのくらい少ない量で適切かなと感じました。
詳細を知りたいときは自分でページに飛べばよいですもんね。
定点当たりの数値が高い順など、比較しやすい並び順だといいかもしれません。
Kさんは、このプロトタイプが 「価値ある情報」 を効率的に提供している点を評価してくれました。
「情報量はこのくらいで適切」という評価は、PDFの表をきれいに整形することを諦めたことによる視認性の悪化は心配するほどでもなかったことを示していると思います。
また、「比較しやすい並び順」という改善案は、次のステップで何をすべきかを明確に示してくれました。
6. まとめと今後の展望
目指すのは町中華
今回の取り組みで得られた最大の学びは、 「完璧な完成度より、まず動くプロトタイプを作ることの重要性」 でした。
技術的な壁にぶつかった時、理想を追い続けるのではなく、 「とりあえず動く状態にする」 という割り切りがなければ、途中で投げ出していたことでしょう。
また、AIを万能な解決策として頼りきっていた自分に、初めて大きな壁が立ちはだかりました。
これまでは、ノーコードツールを使ったり、コード生成させたりして、とりあえず使えるものっていうのは簡単に作れていました（ブラッシュアップに膨大な時間がかかりましたが）。
PADについては、全然ダメ。
わからないこと、できないことだらけ。
AIが示すアクションが実際には存在しなかったり、コピペしても記述ルールが違ったりする現実に直面しました。
プログラミングの知識以前に、そのロジックがわからなくて袋小路に迷い込んだりもした。
基礎をすっとばして、ノーコードツールとAIで乗り切ってきたことで、ここで足踏みしてしまいました。
最終的には自分の力で試行錯誤する、泥臭いプロセスの大切さを痛感しました。
とりあえず動くものを作る、ゴールテープを大幅に引き直して、第一ステージをクリアしました。
求められているのは、着飾っていく高級中華料理店のような完璧な製品ではない。
うまくて安くて早い、町中華の普通の餃子。
主役はラーメンだったり、肉野菜炒めだったり、チャーハンだったり。
当たり前のようについてくる普通の餃子を作りたい。
今後の展望
プロトタイプ1 週報作成における数値拾い
今回の数値拾い自動化は必要な情報の一部に過ぎません。
いまは餃子の皮だけスーパーで買ってきただけで、お店のメニューに出せる状態ではない。
割り切りの姿勢と成功体験を活かし、次の自動化に取り組みたいです。
必要な数値をすべて拾えれば、データをセットした状態でチームに配って大きな効率化を果たせると思うのです。
拾い集める数値ごとにフローを作り、最後に連続実行して1つのファイルに統合する、やるべきことは見えてきました。
あと、マウス操作のトレースから脱却したい。
プロトタイプ2 感染症情報センター週報の取得と通知
現在はWindowsのタスクスケジューラで動かしていますが、ローカルでは制約が大きい。
この機能をWebで動くよう再構築し、環境によらず安定して情報取得できるようにしたい。
メール本文があまりにもそっけないので、もう少しだけ美しさにこだわりたい。
PADから自分宛てにメール送信し、Outlookの自動転送を使って各メンバーに転送するよう計画していますが、スマートじゃないですよね。
試作段階なので宛先が少ないですが、多くなったらExcelなどで宛先管理します。
餃子押しの記事でしたが、横浜中華街の海員閣の「焼売」が最高に旨いので最後に紹介しておきます。
同じ通りにある安記の中華粥もおいしいです。