先に、結論を3行で書きます。
- AIで業務アプリを作る前に、対象業務を「やめる・減らす・まとめる・残す」に分けてみます。
- アプリが動くことと、会社全体の仕事が減ることは別の成果です。
- 評価指標はアプリ数だけでなく、承認件数、転記、例外処理、運用コスト、廃止まで含めます。
時間に合わせて、読み方を選べます。
- 少し忙しい人向け：5分で読める要約版（個人サイト）
- もっと深掘りしたい人は、このまま本文へどうぞ。
生成AIとAIエージェントのおかげで、フォームや一覧画面は以前よりずっと気軽に作れるようになりました。Claude CodeやCodexを触っていると、「このExcelもWebアプリにできるな」と考える場面は増えます。
そこで一度、手を止めたい。そもそも、その業務は必要なのでしょうか。
これは特定の製品や現場の評価ではありません。AIを使って社内アプリを作るときに、後で困らないための設計上のメモです。
まず、作る前に4つへ仕分けてみる
アプリの要件定義を始める前に、対象業務を次の4種類に分類します。
| 選択肢 | 確認したいこと | 例（架空） |
|---|---|---|
| やめる | 法令・契約・内部統制上、本当に必要か | 誰にも参照されない重複した報告 |
| 減らす | 件数、頻度、承認段階、入力項目を削れるか | 低額申請の承認回数を見直す |
| まとめる | 部署間で同じ情報を何度も持っていないか | 共通マスタに統一する |
| 残す | 必要な処理を、安全かつ手間なく続けられるか | 監査証跡が必要な申請を電子化する |
「やめる」は強い言葉です。実際には、現場の担当者だけで廃止を決められない業務もあります。法務・監査・経営など、意思決定の責任者に確認することが前提です。
それでも、この仕分けをしないままWeb化すると、いらない工程を丁寧に電子化してしまう可能性があります。
1990年にMichael Hammerが出した論考「Reengineering Work: Don't Automate, Obliterate」は、既存の仕事を技術でそのまま自動化する発想そのものに疑問を投げかけました。AI以前からあった話です。
原典：https://hbr.org/1990/07/reengineering-work-dont-automate-obliterate
「Excelがなくなった」を成功条件にしない
考えやすいように、架空の総務業務を置きます。
ある申請が年間5,000件。申請者と確認者、承認者を合わせて1件20分かかっているとします。年間の延べ処理時間は約1,667時間です。
フォーム入力を便利にして15分へ短縮すれば、年間約1,250時間。約417時間の削減になります。
一方、申請そのものを見直し、不要な手続きを廃止して年間2,500件まで減らしたうえで、15分の画面へ置き換えたらどうでしょう。約625時間です。元の業務から約1,042時間削減できます。
| 試算（すべて架空） | 年間件数 | 1件の延べ時間 | 年間延べ時間 |
|---|---|---|---|
| 変更前 | 5,000件 | 20分 | 約1,667時間 |
| Web化のみ | 5,000件 | 15分 | 1,250時間 |
| 業務見直し＋Web化 | 2,500件 | 15分 | 625時間 |
件数を半減してよいという前提には、根拠が必要です。この数字は実績ではなく、何を測ると結果が違って見えるかを説明するための算数です。
Web化そのものに価値がない、と言いたいのでもありません。履歴、検索、監査、権限分離、在宅からの利用が改善することもあります。ただし、ツールの入れ替えと業務全体の最適化は、別の評価軸で測る必要があります。
タスクが速くなっても、仕事の総量が減るとは限らない
これは直感だけの話でもないようです。
パーソル総合研究所「生成AIとはたらき方に関する実態調査」（2026年2月公表）によると、生成AIを使ったタスクでは所要時間が平均16.7％短縮した一方、業務時間が減った生成AI利用者は25.4％でした。また、業務時間を削減できた人に限ると、浮いた時間の61.2％が仕事に再投入されていました。61.2％は人数の割合ではなく、削減できた時間の使い道を表す数字です。
本調査は2025年10月に実施された、正規雇用者3,000人（生成AI利用群1,500人、非利用群1,500人）を対象とするインターネット調査です。自己申告に基づく結果であり、AI導入の因果効果を実験で測った数字ではありません。
調査概要と結果：https://rc.persol-group.co.jp/thinktank/data/generative-ai/
調査報告書の該当箇所：同ページの全文PDF、7〜8ページ（タスクの時間削減と、削減できた時間の使い道）。
この数字は「AIの効果が低い」という意味ではありません。タスクの時間短縮と、仕事の総時間の変化は分母も性質も違うということです。余った時間をもっと価値のある業務へ回すのも立派な成果です。
IPAの「DX動向2026」も、AI導入が進む一方、成果が効率化・迅速化に偏り、事業変革までつなげることを課題として挙げています。
IPA：https://www.ipa.go.jp/pressrelease/2026/press20260716.html
数値を見ていて思ったのは、計測場所を間違えると成功の定義も変わる、ということでした。
アプリを作れる人が増えたら、廃止する人も決める
ローコードやAIエージェントで社内アプリが作りやすくなるほど、「小さな便利」が大量に生まれます。これは良いことです。
ただ、部門Aと部門Bがそれぞれ社員マスタを持ち、似た申請画面を作り、どちらが正本なのか決まっていなければ、Excelの乱立がWebアプリの乱立に変わります。
MicrosoftはPower PlatformのCenter of Excellence（CoE）に関するガイドで、こうした市民開発の普及とガバナンスをセットで考えるよう案内しています。アプリの用途や利用状況を把握し、必要性を定期的に見直す運用も考えておきたいところです。
Microsoft公式：https://learn.microsoft.com/en-us/power-platform/guidance/adoption/common-vision/establish-coe
そこで、新しい業務アプリごとに最低限の台帳を持つ案を考えました。以下は、実在の会社のテーブルではない架空の例です。
application:
business_purpose: "備品購入の申請"
owner_role: "総務の業務責任者"
decision_owner_role: "規程を変更できる承認者"
users: ["申請者", "承認者"]
master_data_owner: "社員情報の正本を管理する部署"
duplicate_work: "現行手続きとの二重入力を確認"
retirement_condition: "統合先が確定して業務移行が完了"
review_interval: "半期ごと"
success_metrics:
- "申請の総件数"
- "承認までの時間"
- "差戻し率"
- "二重入力の件数"
実装技術よりも先に、誰が使い、誰が責任を持ち、何をもって廃止するかを書いておく。
アプリの生成コードをGitで管理することはできます。では、不要になったアプリをやめる判断は、誰がするのでしょう。
技術の課題と、組織の課題を分けて置く
ここはAIエージェントに任せにくい領域です。
- 技術の課題：フォーム、API、権限制御、監査ログ、データの整合性、バックアップ。
- 業務の課題：何を判断するための入力か、重複工程はどこか、どこまで短縮できるか。
- 組織の課題：誰が廃止を決めるか、部署の予算や役割に何が起きるか、従業員の仕事をどう再配置するか。
３番目の話を「現場に聞けばわかる」で片付けるのは危険です。業務改革によって担当部署の規模や権限、責任が変わるなら、現場だけでは合意できない場合があります。逆に、承認が不要に見えても、監査上は重要な工程かもしれません。
以前、AIに設計上の前提を渡せず議論が空転した経験を「不文律」の記事にまとめました。今回考えたいのは、その一歩先です。資料に書かれていないのは、設定値だけではなく、組織の事情かもしれない。
関連する過去記事：実装計画まで6時間半。遅かったのはAIではなく、渡していない「不文律」だった
そもそも「誰にとって使いやすいか」が揃っているか
| 立場 | まず見たい成果 | 見落としがちなもの |
|---|---|---|
| 現場担当者 | 入力が速い、迷わない | 他部署の転記 |
| 部門管理者 | 業務が止まらない、統制が効く | 全社の重複 |
| 情報システム部門 | 安全に維持できる | 現場の操作負担 |
| 経営層 | 全体の生産性、サービス品質 | 現場の移行コスト |
| ベンダー | 利用・導入・継続契約 | 顧客側の業務廃止 |
ベンダーがサブスクリプションで収益を得ることは、もちろん悪いことではありません。継続的な価値を提供しているなら、継続料金は自然です。
ただし、顧客側の成果指標まで「導入したアプリ数」「利用者数」だけにすると、何のために作るのかがぼやけます。異なる立場の評価軸を同じ会議で並べてみる価値はあります。
小さな実践として、次のヒアリングで何を聞くか
すべての企業で、最初から大規模なBPRを実施するべきだとは思いません。既存の書類やExcelを小さくWeb化し、そこから業務を理解する進め方もあります。最初から大改革を掲げると、業務が止まるリスクもあります。
それでも、アプリ開発の着手前に少なくとも次の問いを持っておきたいです。
- この書類を最後に使う人は誰ですか。
- その判断は何のために必要ですか。法令・規程上の根拠はありますか。
- 同じ情報を、別の部署でも入力していませんか。
- この処理を作らずに済む条件はありますか。
- 工数が減ったら、その時間を何に振り向けますか。
- アプリを統合・廃止する判断者は誰ですか。
この質問を毎回全部投げるわけではありません。相手を責めるのではなく、実態を教えてもらうための問いです。運用してきた理由も含めて尊重したい。
あわせて読みたい
- 「機能は増えたのに、業務は楽にならない」を戦略と戦術の5階層で読み解く（「ツールを作ること」が目的になる問題を、別の観点で整理した記事です）
姉妹記事：人間と組織の側から同じ問いを考える
この記事では、業務を「やめる・減らす・まとめる・残す」に分けて、AIで作る前に何を確認するかを考えました。
一方、姉妹記事のnote「『サピエンス全史』から考える、会社がなかなか変わらない理由。そして、一人の社員としての折り合いのつけ方」では、合理的な改革が組織で止まる理由や、判断する立場の違いを、人間・組織の側から考えています。
こちらが技術編、あちらが人間・組織編。同じ問いを別々の角度から書いた、どちらからでも読める2本です。
おわりに
AIで作れるものが増えました。便利なのは間違いありません。だからこそ、作る前に少しだけ問い直したい。
「このアプリは作れるか」だけでなく、「作らないで済む仕事はないか」。
全部を一人で決める必要はありません。決められないなら、決める人と合意するための材料を作る。それも設計の仕事の一部だと思っています。
※ ヘッダー画像は AI（画像生成）で作成しています。
※ インフォグラフィックと本文図はプログラムで作図しています。
書いた人: ishizakahiroshi
群馬の北部で、保護猫2匹と暮らす、在宅エンジニア（何でも屋）
https://ishizakahiroshi.com/
https://github.com/ishizakahiroshi
X（業務委託・各種相談はこちら）：
https://x.com/ishizakahiroshi
バックエンド・インフラ・AI連携まわりで、業務委託のご相談を受け付けています。フルリモートです。スポットや週2〜3時間からでも歓迎で、いろんな案件に携われたらうれしいです。こんな相談、歓迎です。