それはAIでやるべきか、普通のプログラムで十分か

最近、AIという言葉をよく見ます。

その熱気自体は悪いことではありません。 新しい技術に触れる人が増え、仕事の進め方を見直すきっかけにもなっています。 AIツールによって、非エンジニアでも自分でアプリや業務ツールを作り始められるようになったことも、大きな変化です。 現場をよく知っている人が、自分の困りごとを自分で形にできるようになるのは、とても良いことだと思います。

ただ、「作れること」と「適切な技術を選べること」は別です。

近頃のAIに関する発言を見ていると、少し浅い理解のまま話が進んでいると感じることがあります。 先日も、PythonそのものをAIだと誤解している方に会いました。 もちろん、最初から正確に理解している必要はありません。 私自身も、新しい技術は使いながら理解していくものだと思っています。

それでも、本質を取り違えたまま業務で使い方を決めると、余計なコストをかけたり、向いていない技術を選んだり、大事な意思決定を誤ったりすることがあります。 「エンジニアがいなくても作れる」という感覚が広がる時代だからこそ、何をAIでやるべきで、何は普通のプログラムで十分なのかを切り分ける力が必要になります。

この記事では、AIという言葉を少し分解します。 普通のプログラム、RPA、画像認識、LLM、AIエージェントをどう切り分けるかを整理します。

目次

• そもそもAIとは何か
• まず、普通のプログラムで十分なもの
• RPAが向いているもの
• 画像認識モデルが向いているもの
• LLMが向いているもの
• AIエージェントが向いているもの
• 判断の順番
• 例で考える
• まとめ

仕事で「AIを使いたい」と言うとき、その中身はいろいろです。

顔を見分けたいのか。 文章を読ませたいのか。 画像から異常を見つけたいのか。 毎日同じ作業を自動化したいのか。 社内資料を探して回答させたいのか。

どれも広い意味ではAIの話に見えます。 でも、必要な技術はかなり違います。

場合によっては、AIを使わずに普通のプログラムで十分です。 そのほうが安く、速く、安定することもあります。

最初に大事なのは、「AIを入れるかどうか」ではありません。 その仕事に必要なのは、判定なのか、生成なのか、検索なのか、操作なのか、ただのルール処理なのかを分けることです。

この記事の整理を先に表にすると、次のようになります。

上の図は、この記事で作りたいイメージです。 最初に業務を見て、ルールで済むもの、定型作業、画像や音声、文章、複数ステップの仕事に分けて考えます。 実際に公開する際は、この内容を1枚の図として入れると読みやすくなります。

そもそもAIとは何か

AIは、とても広い言葉です。

もともとは、人間が行っている知的な活動を、機械で実現しようとする研究領域として始まりました。 言葉を使う。 概念を扱う。 問題を解く。 経験から改善する。

こうした、人間の認知活動に近いものを機械で扱おうとする技術の総称として、AIという言葉があります。

そのため、AIは特定のツール名でも、特定のプログラミング言語でもありません。 PythonはAIそのものではなく、AIを実装するときにも使われるプログラミング言語の一つです。

人の顔を見分けるものもAIと呼ばれます。 写真から不良品を見つけるものもAIと呼ばれます。 ChatGPTのように文章で答えるものもAIと呼ばれます。 売上を予測するモデルもAIと呼ばれることがあります。

ここで分けて考えたいのは、AIという大きな概念と、それを実現する具体的な方法です。

AIの実現方法には、いろいろな考え方があります。 人がルールを細かく書く方法もあります。 探索や推論を使う方法もあります。 統計や機械学習を使う方法もあります。

近年、大きな成果を出しているのは、統計、機械学習、深層学習を使う方法です。 大量のデータや例から特徴やパターンを学び、入力に対して分類、予測、生成などを行います。

つまり、「AIとは過去データにもとづいて確率的に出力するもの」とだけ言い切るのは狭すぎます。 より正確には、AIは人間の知的な活動を機械で実現しようとする広い概念であり、現在よく使われているAIの多くでは、統計的な手法が強い成果を出している、という理解が近いです。

普通のプログラムでは、人があらかじめルールを書きます。

「金額が10万円以上なら承認者を変える」 「日付が今日より前なら期限切れにする」 「郵便番号が7桁でなければエラーにする」

このように、条件と処理を人が決めます。

一方で、機械学習を使うAIでは、すべてのルールを人が手で書くのではなく、過去のデータや大量の例から、特徴やパターンを学びます。

たとえば顔認識なら、多くの顔画像から「顔らしさ」や「同じ人らしさ」を学びます。 文章を扱うAIなら、大量の文章から、言葉のつながりや文脈、質問と回答のパターンを学びます。

そのため、機械学習やLLMを使うAIの出力は、普通のプログラムのように人が書いたルールをそのまま実行した結果とは性質が違います。 「絶対に正しい答え」というより、学習したパターンや文脈から見て妥当そうな答えを出している、と考えるほうが近いです。

ここが大事です。

特にLLMは、統計的な性質を持つモデルです。 つまり、同じ質問でも、聞き方や前後の文脈によって答えが変わることがあります。 もっともらしい文章を書けても、事実を間違えることもあります。 それらしい分類をしても、例外を見落とすこともあります。

だから、LLMや機械学習を使うAIは「判断を助けるもの」としては強いですが、「常に正解を返す機械」と考えると危険です。

AIを使うときは、次のように考えると分かりやすいです。

• ルールが明確なら、普通のプログラムでよい
• 例や傾向から判断したいなら、機械学習が候補になる
• 文章や意味を扱うなら、LLMが候補になる
• 画像や音声を扱うなら、画像認識や音声認識のモデルが候補になる
• 複数の手順を進めたいなら、AIエージェントが候補になる
• 間違えると困る判断は、人が確認する

AIは、人の代わりにすべてを決めるものではありません。 人間の認知活動に近い処理を、機械で扱いやすくするための技術群です。 その代わり、出力には揺れがあり、確認も必要です。

この前提を持っておくと、「AIでやるべきか、普通のプログラムで十分か」を考えやすくなります。

まず、普通のプログラムで十分なもの

最初に疑うべきなのは、普通のプログラムでできないかです。

たとえば、次のような仕事です。

• 金額が10万円以上なら承認者を変える
• 日付が過ぎていたら通知する
• CSVの列を並べ替える
• Excelの決まったセルを集計する
• ファイル名に日付を付ける
• 入力漏れがあればエラーにする

これはAIでなくてよいです。 ルールがはっきりしているなら、普通のプログラムのほうが向いています。

普通のプログラムは、同じ入力に対して同じ結果を返しやすいです。 動作も説明しやすい。 テストもしやすい。 コストも読みやすい。

AIを使う前に、「if文で書けるか」「表のルールで表せるか」「正規表現や集計で済むか」を見たほうがよいです。

RPAが向いているもの

RPAは、人がPC上で行っている定型作業を、ソフトウェアロボットに代行させる考え方です。

画面操作に限るものではありません。 Excel、ファイル、メール、ブラウザ、業務システム、場合によってはAPI連携まで含めて語られることがあります。

たとえば、次のような仕事です。

• 毎朝、管理画面にログインして数字を取る
• ダウンロードしたファイルを所定のフォルダに置く
• Excelの内容を別システムへ入力する
• 決まった画面で検索して結果を保存する
• メールの添付ファイルを保存し、管理表へ反映する
• 複数のシステムから情報を集めて、定型レポートを作る

人が毎回同じ判断基準で、同じような手順を繰り返しているなら、RPAの候補になります。

ただし、RPAにも注意点があります。

画面操作に依存する作り方をすると、画面変更に弱くなります。 ボタンの位置が変わる。 項目名が変わる。 ログイン手順が変わる。

そうすると止まります。

APIで直接つなげるなら、RPAよりAPI連携や普通のプログラムのほうが安定することもあります。 一方で、APIがない、既存システムを大きく変えられない、短期間で現場の手作業を減らしたい、といった場合はRPAが現実的な選択肢になります。

画像認識モデルが向いているもの

画像や映像を見て判断したいなら、画像認識モデルを考えます。

たとえば、次のような仕事です。

• 顔を検出する
• 商品画像を分類する
• 工場の画像から傷や異常を見つける
• 書類画像から文字を読む
• 防犯カメラ映像から人や車を検出する

これは、LLMやチャットAIだけで考える話ではありません。 画像を扱うモデル、OCR、物体検出、顔認識、異常検知などの領域です。

ただし、画像認識はデータの質が大事です。

明るさが違う。 角度が違う。 カメラが違う。 現場ごとに背景が違う。 異常データが少ない。

こうした条件で精度が変わります。

顔認識のように個人を扱うものは、プライバシーや同意も考える必要があります。 「技術的にできる」だけでは足りません。 業務で使ってよい設計か、保存しないで済むか、誰が確認するかまで考えます。

LLMが向いているもの

LLMは、文章を読んだり書いたりするモデルです。

たとえば、次のような仕事です。

• メールを要約する
• 議事録からタスクを抜き出す
• 問い合わせ内容を分類する
• 社内資料をもとに回答案を作る
• 文章の表現を整える
• 仕様書や手順書のたたき台を作る

文章の揺れがある。 人によって書き方が違う。 正解がひとつではない。 人が読めば判断できるが、毎回読むのが大変。

こうした仕事はLLMに向いています。

ただし、LLMは計算機ではありません。 数字の正確な処理、厳密な照合、最終判断をそのまま任せるのは危険です。

LLMは、下書き、分類、要約、観点出しに使う。 正本は人が確認する。 この分け方が現実的です。

AIエージェントが向いているもの

AIエージェントは、LLMがツールを使いながら複数の手順を進める仕組みです。

単に文章を返すだけではなく、資料を探す、システムを呼び出す、結果を見て次の作業を選ぶ、といった動きをします。

たとえば、次のような仕事です。

• 問い合わせを読み、過去資料を探し、返信案を作る
• 会議メモからタスクを整理し、担当者ごとに通知案を作る
• 毎朝必要な情報を集め、変化点をまとめる
• 社内ドキュメントを検索し、根拠付きで回答案を出す
• 記事テーマを調査し、構成案と参考リンクをまとめる

AIエージェントに向いているのは、目的があり、複数ステップがあり、途中で情報を見ながら進める仕事です。

逆に、強い権限をいきなり渡すのは危険です。

メールを送る。 顧客情報を書き換える。 請求書を発行する。 ファイルを削除する。 支払いを実行する。

こうした操作は、AIエージェントにできるかどうかではなく、任せてよいかで考えます。 最初は、送信ではなく下書き。 更新ではなく変更案。 削除ではなく削除候補。

人が確認できる形にするのが大事です。

判断の順番

業務でAIを使うか迷ったら、次の順番で考えると整理しやすいです。

ルールで書けるなら、まず普通のプログラムでよいです。 PC上の定型作業なら、RPA、API連携、普通のプログラムのどれが安定するかを見ます。 画像なら画像認識モデルを考えます。 文章ならLLMを考えます。 複数の手順を進めるならAIエージェントを考えます。

この順番で見ると、「AIを使いたい」という話が少し具体的になります。

例で考える

たとえば、請求書処理で考えてみます。

PDFから文字を読むならOCRです。 読み取った金額や日付をチェックするなら、普通のプログラムでできます。 請求内容を分類するなら、LLMが使えるかもしれません。 会計システムへ入力するなら、API連携やRPAが候補になります。 不明点を担当者へ確認し、回答を見て処理を続けるなら、AIエージェントの領域に近づきます。

ひとつの業務の中でも、必要な技術は分かれます。

だから、「請求書処理をAI化する」という言い方だけでは、まだ粗いです。 どの部分を、どの技術で処理するかを分けて考える必要があります。

個人的に大事だと思うこと

私は、技術は人の時間と選べることを増やすために使うものだと思っています。

だからこそ、AIを使うこと自体を目的にしないほうがよいです。

普通のプログラムで十分なら、それでよい。 RPAで早く楽になるなら、それでよい。 LLMが下書きを作ってくれるなら、それでよい。 AIエージェントが複数の手順をつないでくれるなら、それを使えばよい。

大事なのは、現場の不自由が減ることです。

ExcelからExcelへ転記する時間。 同じ資料を何度も探す時間。 毎回同じ説明文を書く時間。 確認漏れがないか不安になる時間。

そうしたものを少しずつ減らして、人が本来向き合いたい仕事に時間を戻す。 そのために、AIやITを選ぶ順番で考えたいです。

まとめ

AIという言葉は広いです。 顔認識、画像認識、LLM、AIエージェント、RPA、普通のプログラムは、それぞれ得意なことが違います。

最初から「AIでやる」と決める必要はありません。

ルールで済むなら、普通のプログラム。 PC上の定型作業なら、RPA、API連携、普通のプログラム。 画像を見るなら、画像認識。 文章を扱うなら、LLM。 複数の手順を進めるなら、AIエージェント。

このように分けて考えると、無理のない業務改善にしやすくなります。

愛葉では、「AIを入れたい」という段階から、そもそもAIが必要か、普通のプログラムでよいか、RPAやAIエージェントを使うべきかまで一緒に整理します。 技術選定の前に、まず業務の流れを見て、何を減らすべきかを決めるところから始められます。