AI導入の前にやめる業務を決める

AIで報告書を作れるようになっても、従来のExcelへの転記と上司への個別説明が残ると、担当者の負担が思うほど減らないことがあります。AIへの入力、出力の確認、旧手順への書き戻しまで増えることもあります。

AI導入を検討する経営者や部門責任者に、最初に考えてほしいのは「導入後、どの作業をやめられるか」です。Netsujoは、その判断を顧客と整理し、業務の変更条件を実装チームへつなぐところから支援します。

その作業は何のために残っているか

たとえば、各拠点の報告を本部がまとめる業務を考えます。ここでは説明用の例として、拠点ごとのファイルを担当者が転記し、責任者が内容を確認している状況を置きます。

転記をAIに任せても、責任者が元ファイルをすべて読み直すなら、業務全体の負担はあまり変わらないかもしれません。一方、読み直しには、数字の整合確認や異常の発見という目的があります。その確認まで一緒に外すと、守っていた品質を失います。

そこで、作業の名前より先に目的を確かめます。

この整理から、転記は自動化の候補になり、異常への判断は人が持つ、といった分担を検討できます。自動化する部分が少なくても、不要な転記や重複した報告自体を減らせれば、改善につながります。AIを使う範囲は、残すべき仕事が見えてから決められます。

自社では重複した自動検査の起動を見直した

Netsujoの自社開発でも、AIによる修正と確認が増え、同じ目的の自動検査（CI）が繰り返し起動する問題がありました。コードを変えていない文書の修正でも、データベースやブラウザの検査環境を用意していたのです。

そこで、変更内容を実行の入口で分類し、文書の変更には不要な環境を起動しない構成へ変えました。文書でも壊れうる契約表現や実行上の安全条件の検査は残し、分類できない変更は広い検査へ戻す設計にしています。

2026年8月公開、10月18日更新の実施記録にある、文書だけを変更した実際のPR一件の確認結果は次のとおりです。PRは、変更をまとめて確認する単位です。

経過時間の短縮は7分22秒、77.4%でした。これは一件の検査時間の短縮率です。月額の請求削減率は別に集計する必要があります。

ここで扱ったのは、作業の目的と実行条件です。必要な確認を残し、今回の変更に不要な処理を止めました。顧客の業務でも同じように、残すべき確認と重複している作業を分け、何をやめてよいかの判断を支援します。

速くする前に、起動する理由を問い直した

この見直しで大切だったのは、「すべての処理を少しずつ速くする」という問いから離れたことです。環境の用意に時間がかかるなら、キャッシュや実行環境を調整する方法があります。しかし、文書しか変えていない回に、その環境は必要なのか。まずそこを確かめました。

CIは、変更が問題を起こしていないかを自動で検査する仕組みです。導入時には広く検査するほうが分かりやすくても、変更の種類や実行回数が増えると、その前提を見直す余地が生まれます。毎回同じ手順を回すことと、毎回必要な品質を確かめることは、分けて考えられます。

実施記録では、入口の分類によって、アプリのコード、ブラウザ、データベースに関する検査が必要かを判断しています。分類を、重い準備が終わったあとへ置くと、検査を省いても準備の待ち時間は残ります。今回の変更に何が要るかを、準備の前で決めることに意味がありました。

これは顧客業務へ持ち込める問いでもあります。たとえば、会議のために資料を毎週整形しているなら、整形をAIに代行させる前に、誰がどの項目を意思決定に使うかを確かめます。利用されない項目まで高速に作ると、作る量だけが増えます。使う項目、異常時だけ見る項目、今は使われていない項目を分ければ、必要な仕組みも変わります。ここでの会議資料は、顧客実績を述べたものではなく、考え方を業務へ置き換えた例です。

分類できないときに、何を残すか

不要な起動を減らすには、間違って省く場合も考える必要があります。新しい種類のファイルが増えたときや、変更の一覧を取得できなかったときまで、文書だけの変更と扱ってよいでしょうか。

自社の設計では、分類が確定しない場合は広い検査へ戻します。速い経路へ進む根拠がなければ、確認を増やす側へ倒すわけです。また、実施していない検査は「未実施」として残します。省いた検査まで合格したと記録すると、後で何を確認済みなのか分からなくなります。

この考え方は、AIが帳票を処理する場合にも使えます。必要項目がそろい、照合条件を満たす帳票だけを自動処理し、形式が違うものや読めないものは担当者へ渡す。人へ渡す条件を決めれば、通常の処理を軽くしながら、判断が必要な案件を埋もれさせずに済みます。どの誤りを許容できるかは業務ごとに異なるため、顧客の責任者と決めます。

速さを得た理由と、品質を守った条件を一緒に説明できること。この二つがそろって、次の変更にも使える改善になります。

業務を変える合意を誰とつくるか

現場担当者は手間を知り、部門責任者は業務の目的と品質に責任を持っています。情報システムの担当者は、データや接続先の制約を把握しています。いずれか一人の判断だけで導入を進めると、運用を始める段階で決まっていない条件が表に出ることがあります。

Netsujoが支援するのは、この間にある論点を整理する仕事です。何に時間がかかっているかを聞き、今回変える範囲を絞り、利用するデータと必要な確認を実装条件へ落とします。業務変更の最終判断は顧客側の責任者が持ちます。

代表の飯田は、顧客課題の整理、技術的な範囲の設定、PoC、本番導入後の評価をつなぐTechnical BizDev / AI Deploymentを担当します。プロダクト本体や専門領域の実装は、CTOや担当エンジニアと分担します。顧客との会話で決めたことが、開発や受入の段階でも使える形を目指します。

旧手順をやめる日と戻す条件を決める

新しい方法を試す間は、新旧を並行して確かめる必要もあります。ただし、比較の目的と終了条件が曖昧なまま続けると、二つの手順が日常業務として残ります。

試行前に、どの条件を満たせば旧手順を止めるかを決めます。先ほどの例なら、必要項目の欠落を検出できること、元の報告までたどれること、例外を担当者へ渡せることが確認項目になります。そのうえで、誰が切替えを判断するか、問題が起きたらどの手順へ戻すかを合意します。

やめる対象は、業務の一部でも構いません。すべての報告を変える必要はなく、定型項目の転記だけを先に見直す進め方もあります。小さく変え、残った確認負担を見て、次の判断をする。その繰り返しに必要な範囲を設計します。

最初の打ち合わせで、一件の流れを確かめる

業務の説明を聞くときは、「いつも大変です」という感覚だけで範囲を決めず、最近処理した一件をたどる方法が役立ちます。どこから依頼が来て、誰が情報を探し、どの表へ転記し、どこで承認が止まったか。実物と順番を合わせると、作業の境目が見えてきます。

拠点報告の例なら、集計担当者の画面だけで完結させず、報告を受け取る責任者が何を見ているかまで確認します。集計を速くしても、責任者が必要とする出典や異常の理由が失われれば、確認の往復が増えるためです。

その場で残したいのは、立派な業務フロー図より、次の実装判断に使える短い記録です。

これは実施済み案件のログではなく、打ち合わせで埋める記録の例です。実案件では、担当者名、対象期間、基準値、具体的な判定方法を入れます。決められなかった項目も空欄のまま共有し、誰がいつ確認するかを定めます。

削減した時間を、何へ振り向けるか

作業時間が減ったあとに何をするかまで、業務改善の目的に含めます。転記の時間を、異常の原因確認へ回すのか。担当者が顧客への返答に使うのか。残業の削減を目指すのか。目的によって、測る指標と必要な運用が変わります。

自社のCIの例で確認できたのは、一件の検査の待ち時間が短くなったことです。その数字から、会社全体の開発速度や利益の改善までは言い切れません。顧客への提案でも、観測した変化と、その先に期待する価値を分けて説明します。そのうえで、次に何を測れば事業上の判断ができるかを決めます。

Netsujoに相談できること

「AIで何かしたい」という段階でも、困っている業務が分かれば検討を始められます。実際に使っている帳票や、同じ内容を何度も説明している場面から、作業の目的、変更できる部分、顧客側に残す判断を整理します。

NetsujoのAI導入支援では、業務の整理からPoC、評価設計、既存システムとの連携、本番実装、運用設計までを扱います。助言やレビューを中心とする支援と、実装・運用を引き受ける範囲は個別に合意します。

まずは、日々繰り返している作業を一つ挙げてください。「なぜ続けているか」と「何が確かめられればやめられるか」を、一緒に整理します。

AI導入支援の内容を見る ／ 対象業務について相談する

参照

• Netsujoの支援内容と責任範囲
• 飯田と実装チームの役割