業務自動化はどのツールで作る？Gem・GAS・Canvasの判断基準

業務自動化の話が出ると、必ずこの議論から始まります。
「それは何のツールで作るのか」。

そこから議論が長引くか、あるいはその場にいた人の得意な手段で決まるかのどちらかになります。
前者だと着手が遅れますし、後者だと保守できない仕組みが増えていきます。
どちらも後から問題になります。

今回は、この判断を毎回の議論から外すための基準を整理していきます。
自動化を組織で回す全体像のほうはAIによる業務自動化の全体像。手段の選び方とコスト設計にまとめてあります。

なぜ「何で作るか」で毎回止まるのか

なぜ、いつも同じところで足踏みするのか？
原因を突き詰めると、2つに整理できます。

ひとつが、それぞれの手段の限界が共有されていないことです。
どこで詰まるかを知らないので、「できそう」という感触だけで議論することになります。

もうひとつが、判断の観点そのものが定まっていないことです。
ある人は開発の速さで話し、ある人は保守のしやすさで話し、ある人は費用で話すというように、観点が揃っていない状態では、いくら話しても結論は出ません。
必要なのは、限界を含めた性質の整理と、観点を絞った判断フローの2つです。
この2つをA4 1枚にまとめてしまえば、議論は30秒で終わるようになります。

4つの手段は、向く処理と限界がそれぞれ違う

まずAIボット（Gemなど）は、判断や文章生成を含む処理に向いていて、人が起動する型が中心です。
作るのが最も簡単なので現場が自分で作れる一方で、限界は正確な計算に使えず、自動でも起動できないところです。
人が使いに来ないと動きません。

次にノーコードの自動化フローは、時刻の起動とイベントの起動に向きます。
設定画面で組めるので情シス以外でも作れますが、限界は複雑な分岐が苦手で、共有や権限にも制約が出るところです。
作った人のアカウントに紐づく構成になりがちなので、異動のときに困ります。

GAS（Google Apps Script）は、データの転記・集計・突合のような確実性が要る処理に向いていて、細かい制御ができて無料の枠でも動きます。
とはいえ限界は書ける人が限られ、実行時間や実行回数にも上限がある点で、大量のデータを一度に処理する用途では詰まります。

また、ブラウザで動くツール（Canvasアプリなど）は、人が手元で使う変換・整形・チェックに向きます。
データが外に出ないのが利点ですが、限界は自動で動かず、社内のデータと連携させるには別の仕組みが要る点です。
3つの使い分けそのものはNotebookLM・Gem・Canvasの使い分け。目的別の判断基準で扱っています。

作るかどうかを先に決め、手段は3問で決める

手段の前に、そもそも作るべきかどうかを判定します。
ここを飛ばすと、作る価値のないものを作ることになるからです。

見るのは3つです。
ひとつが頻度で、「月1回」なら人がやってもよく、「週1回以上」なら仕組みにする価値があります。
2つ目が関与人数で、「1人しか使わない」ならその人が作れる手段で十分ですし、全社で使うなら保守を考えた手段を選びます。

最後が削減される時間です。
1回あたり何分減るか×頻度で出して、ここが「月1時間」を下回るようなら、作る工数と保守の手間のほうが大きい可能性があります。
対象を並べる手順そのものは業務のAI化の進め方。棚卸しから優先順位付け・実装までの手順にまとめてあります。

「作る」と決まってから、ようやく手段の判断に入ります。
この順序を守るだけで、無駄な開発はかなり減ります。
手段そのものを決める問いは、全部で3つです。

「人が起動するのか、自動で動くべきなのか」が1問目で、自動（時刻・イベント）ならノーコードの自動化フローかGAS、人が起動するなら2問目に進みます。
「正確な計算や確実な転記が必要か」が2問目です。
必要ならGASかブラウザで動くツールになりますし、判断や文章生成が中心ならAIボットを選びます。

「処理が単純か、条件分岐が複雑か」が自動側の3問目です。
「受信したら記録する」「時刻に集計する」といった単純なものならノーコードの自動化フロー、条件によって処理が変わるものや突合が必要なものならGASです。

保守と費用を判断に入れないと、あとで痛む

なぜここが見落とされるのか？
後から最も痛むのが、この観点です。

問うのは1つで、「作った本人が異動したら、誰が直すのか」。
答えられない手段は選ばないほうがいいです。

例えばGASは書ける人が社内に1人だけという状況が起きやすく、その1人が異動した時点で、動いているものが誰も触れない資産になります。
判断に入れる形にすると、まず社内に書ける人が2人以上いる手段を優先します。
1人だけならその手段は「重要な業務には使わない」という線を引きます。

もちろん、止まったときに手作業で回せるかという代替手段も確認して、回せないものはより保守しやすい手段で作り直します。
引き継ぎの資料を作る前提で作ることも欠かせません。
何をする仕組みか、どこを直せば何が変わるかは、作った直後なら10分で書けます。
引き継ぎの様式は担当が変わってもAI業務が止まらない。引き継ぎパッケージの設計で扱っています。

作った仕組みの記録を個人の手元で終わらせず、組織の情報として積み上げていく土台づくりそのものは、社内ナレッジをAIで活用する方法。ツール導入・RAG・手持ちのAIの選び方の主題です。

費用についても同じ枠で見ておきます。
処理の量に応じて課金される構成なら、展開の前に1件あたりの処理量×想定件数で試算しておきます。
10人で使っていたときは月数千円だったものが、300人に広げた途端に想定を超えることがあるからです。

下げ方としては、すべての処理を高性能なものに通すのではなく、単純な絞り込みは安い手段で行って、判断が要る部分だけを高性能に回す形にします。
そのうえで費用が読めない手段は、全社展開の前に上限の仕組みを入れます。
上限に近づいたときのアラートと承認者を、先に決めておきます。

A4 1枚にまとめ、依頼する側にも配る

ここまでをA4 1枚にまとめると、載せるのは作るかどうかの3問（頻度・人数・削減時間）、手段を決める3問（起動・計算の必要性・分岐の複雑さ）、4手段の適性と限界の表、保守の問いの4つです。
A4 1枚に収めることが条件で、2枚になった時点で参照されなくなります。
配る先は、作る人だけでなく依頼する人にも広げます。
依頼する側がこの基準を知っていると、「これは仕組みにする価値がない」という判断が現場でできるようになるので、依頼の総量そのものが減っていきます。

失敗の型も一緒に添えておくと効きます。
手段から入ってしまう、作るかどうかの判定を飛ばす、保守の観点を入れない、費用の試算を飛ばす、基準を2枚にしてしまう。
どれも順序を守れば起きません。

判断を誤ると、保守が破綻する

ここまで書いてきた観点のうち、実務でいちばん重いのは保守です。
保守の破綻は、選んだ時点では見えません。

作った直後は誰も困らないのが厄介なところです。
1年後に作った人が異動して、仕様を知る人がいなくなって、しかもその仕組みが業務に組み込まれている。
この状態になってから対処すると、結局は作り直しになります。

判断基準を作るには、複数の手段を実際に使った経験が要ります。
使ったことのない手段の限界は判断できません。
表で比べても、どこで詰まるかは触らないと分かりません。
ここが社内だけで基準を作りにくい理由です。

私たちが提供しているAIコンサル＆伴走支援では、この判断基準づくりから入って、実際のワークフローの実装まで一緒に手を動かしています。
「何で作るか」で毎回止まっている場合は、進め方の参考になるかもしれません。

手段選びは、順序を守れば議論にならない

「何で作るか」の議論が毎回起きるのは、それぞれの手段の限界が共有されていないことと、判断の観点が定まっていないことが原因です。
順序としては、作るかどうかを頻度・人数・削減時間で先に決めて、それから手段を3問で決めます。
人が起動するか自動か、正確な計算が必要か、条件分岐が複雑か。

保守の観点も必ず入れます。
「作った本人が異動したら誰が直すのか」に答えられない手段は選びません。
書ける人が社内に1人だけの手段は、重要な業務には使わないという線を引いておきます。

費用は展開の前に試算して、段階処理で下げて、上限の仕組みを入れます。
これらをA4 1枚にまとめて、作る人だけでなく依頼する人にも配ります。
直近で自動化を検討している業務を1つ選んで、この3問を通してみると、判断の軸がそろいます。