業務課題から考えるAIの選び方と適用判断 | 生成AI時代のAI分類と業務活用判断の基礎 | AI活用概論

前半と後半があります。この章のねらいは、AI の機能名を覚えることではなく、目の前の業務課題を分解し、その課題に合う AI を選び、導入してよいかまで判断できるようになることです。

第1章では生成AIの基本、第2章前半では AI 機能分類の全体像と主要機能を学んだので、この章ではそれらを実務判断の型へ変換します。

NIST は AI の利用で、性能だけでなく文脈に応じたリスク管理や trustworthiness を重視しており、OECD も用途や影響を踏まえた責任ある AI 利用を求めています。つまりこの章は、「AI を知る」段階から「AI を選ぶ」段階へ進むための節です。

はじめに

ここまでで、生成AI、分類、抽出、要約、検索支援、予測、推薦、異常検知といった主要な機能は見えてきました。ただ、実務では「機能を知っている」だけでは足りません。

困りごとを前にしたときに、どの機能を当てるべきか、複数機能をどう組み合わせるべきか、そしてそもそも AI を入れるべきなのかを判断する必要があります。Google Cloud も生成AIを「ユースケース」単位で整理し、Document AI を文書分類・抽出・分割のような実務工程に結びつけて説明しています。

この章では、サービス名から考えるのではなく、業務課題から考えるという姿勢を一貫して取ります。これは初心者ほど大切です。なぜなら、有名なサービス名から入ると、課題より手段が先に立ちやすく、結果として「便利そうだが業務にはうまく入らない」選定になりやすいからです。

逆に、課題を分解し、必要な出力をはっきりさせると、生成・分類・抽出・検索支援・予測・推薦のどれが必要かがかなり見えやすくなります。

第1章では、生成AIとは何か、LLM がどんな役割を持つのか、何が得意で何が苦手か、人間とどう役割分担するべきかを学びました。ここで大切だったのは、生成AIを「ブラックボックス」として見るのではなく、文章・画像・コードなどを作るのが得意な機能として見ることでした。OpenAI の ChatGPT 概要でも、ChatGPT は writing、coding、data analysis などを支援するものとして説明されています。

1-2. 第2章前半で学んだこと

第2章前半では、AI を生成・分類・予測・抽出・推薦などの機能で分ける見方を整理し、さらに生成AIと識別AIの違いを見ました。そこで分かったのは、AI は一枚岩ではなく、返すものの種類が違う複数の部品として理解したほうが実務に強いということです。Document AI が文書の分類・抽出・分割を担い、生成AI が回答文や説明文の作成に向くように、同じ AI でも役割はかなり違います。

1-3. なぜ次に「AIの選び方」を学ぶのか

ここまでで「何があるか」は見えてきましたが、実務で必要なのは「何を選ぶか」です。NIST の AI RMF は、AI を設計・開発・使用・評価する全体で trustworthiness を考えるべきだとしています。つまり、AI の種類を知ったあとには、その AI をどの課題に当てるか、どこまで任せるか、何を人が確認するかを考える段階が必要です。この章は、その橋渡しです。

まとめ

第1章と第2章前半で得た知識は、「AI を説明できる」状態を作るものでした。この章ではそこから進んで、「AI を選び、適用し、導入してよいか判断する」状態を目指します。知識が地図だとすれば、この章は進む道を決めるコンパスにあたります。

2. 初心者が最初につまずくポイント

2-1. 「有名なAIを使えば解決する」と思ってしまう

最初のつまずきは、サービス名から考えてしまうことです。たとえば「社内の問い合わせ対応を効率化したい」と聞くと、すぐに ChatGPT や Gemini のような生成AIを思い浮かべがちです。しかし、その課題の中心が「問い合わせ内容を種類ごとに分けたい」なら、最初に必要なのは分類です。逆に「担当者が返信文を毎回ゼロから書くのが大変」なら、生成が向きます。同じ課題に見えても、どこが一番のボトルネックかで必要な機能は変わります。

2-2. 「生成AIだけでほとんどの業務を置き換えられる」と思ってしまう

生成AIは目立つので、つい「AI = 生成AI」と思いやすいです。しかし実務の入口には、分類、抽出、検索支援、予測のような、地味でも重要な工程が多くあります。Google Cloud の Document AI は、まさに文書を自動で分類し、必要データを抽出し、文書処理を自動化するためのサービスとして位置づけられています。つまり、業務では「作るAI」より先に「整えるAI」が必要になることが少なくありません。

2-3. 「一つの課題に一つのAIだけを使う」と思ってしまう

初心者は、課題と AI を一対一で結びつけがちです。けれど現実の業務フローは、もっと分解できます。たとえば請求書処理なら、文書の種類判定、必要項目の抽出、例外ケースの検知、最後の整形や説明文作成という複数の工程があります。Document AI の公式説明でも、分類、抽出、分割など複数の文書処理が並んでいます。つまり、一つの課題の中に複数の AI 機能が入ることが普通です。

2-4. 「AIの精度が高ければ導入判断は終わり」と思ってしまう

これはかなり危険な誤解です。AI の精度が高くても、コストが高すぎる、応答が遅い、現場で確認が追いつかない、責任の所在が曖昧、という理由で導入が失敗することがあります。NIST の AI RMF は、AI リスク管理を単なるモデル性能の問題ではなく、運用、影響、ガバナンスまで含めたものとして整理しています。つまり、高精度 = 導入してよいではありません。

2-5. なぜこの誤解を先に解く必要があるのか

これらの誤解を残したまま進むと、あとで機能分類や適用判断を学んでも、結局はサービス名中心の思考へ戻ってしまいます。だからこの章では、最初に「どこで間違えやすいか」を見える化します。ここを越えると、AI を流行の道具ではなく、業務に埋め込む機能として見やすくなります。

まとめ

初心者の失敗は、知識不足そのものより、考え始める位置を間違えることから起こりやすいです。サービス名から入らず、課題から入る。精度だけで決めず、運用まで見る。この二つが、この章の前提になります。

3. AI選定の出発点は「業務課題」である

3-1. 業務課題とは何か

ここでいう業務課題とは、「AI を入れたい理由」ではなく、現場で本当に困っていることです。たとえば、「問い合わせが多い」だけでは課題として広すぎます。「問い合わせの振り分けに時間がかかる」「回答作成が属人化している」「FAQ があるのに見つからない」というように、困りごとをもう少し細かく言い換える必要があります。こうすると、課題が AI の機能に対応づけやすくなります。

3-2. 課題をそのままAI導入テーマにしてはいけない理由

「売上を伸ばしたい」「ナレッジを活用したい」「教育をよくしたい」のような課題は、そのままでは広すぎます。広すぎる課題は、AI に必要な入力と出力が見えにくく、結果として「何でもできるAI」を探し始めてしまいます。ここで必要なのは、課題を AI が扱える粒度まで分解することです。Google Cloud の生成 AI ユースケースも、顧客サービス改善、生産性向上、検索強化など、用途ごとに整理されています。

3-3. 課題をAIが扱える形へ分解する

分解の基本は五つです。

入力は何か。
出力は何か。
誰が使うか。
どこで判断が必要か。
最終責任は誰が持つか。

たとえば「社内ナレッジを活用したい」という課題なら、入力は文書群や質問文、出力は関連文書・要約・回答案、使うのは社員、判断は「どの情報が正しいか」、最終責任は人間の担当者、というように整理できます。こうすると、検索支援、要約、生成のどれが必要かが見えます。

3-4. なぜ分解が重要なのか

分解のよいところは、AI の選定だけでなく、評価基準まで見えることです。入力と出力がはっきりすると、「分類の正解率を見るのか」「生成文の妥当性を見るのか」「検索のヒット率を見るのか」が決めやすくなります。さらに、一つの課題に複数機能が必要なことも自然に見えてきます。たとえば問い合わせ対応なら、分類 → 抽出 → 検索支援 → 生成という流れが見えます。ここで初めて、AI を「一つの箱」ではなく「複数の工程に置く部品」として見られるようになります。

まとめ

業務課題をそのまま AI 導入テーマにすると、曖昧さが残ります。だからこそ、入力、出力、利用者、判断、責任へ分解することが重要です。分解できると、必要な AI 機能も、見るべき評価基準も、かなり明確になります。

4. 課題からAI機能を選ぶ基本マップ

4-1. 作りたいのか、見分けたいのか

最初の分かれ道はここです。何かを作りたいなら生成が第一候補です。何かを見分けたいなら分類や異常検知が候補になります。たとえば、投稿文の下書きなら生成、レビューの感情判定なら分類です。この問いは単純ですが、かなり強力です。多くの迷いは、ここでほぼ半分まで減らせます。

4-2. 見つけたいのか、抜き出したいのか

次の分かれ道は、情報を探したいのか、文書の中から必要項目だけ抜き出したいのかです。探したいなら検索支援、抜き出したいなら抽出が向きます。たとえば「規程集から関連ルールを見つけたい」は検索支援、「契約書から更新日だけ欲しい」は抽出です。初心者はここをよく混同しますが、探す対象が文書全体か、項目かでかなり違います。Document AI が抽出・分類・分割を前面に出しているのは、この区別が業務で重要だからです。

4-3. 未来を見たいのか、次の候補を出したいのか

将来の数値や発生確率を知りたいなら予測、今の人に合いそうな候補を並べたいなら推薦です。たとえば「来月の売上を見積もる」は予測、「このユーザーにどの商品を見せるか」は推薦です。どちらも「次」に関係しますが、予測は未来の値、推薦は候補の順位という違いがあります。ここを区別できると、EC や教育支援、メディア運営の設計がかなり読みやすくなります。

4-4. 一つの課題に複数のAI機能が必要になる理由

現実の課題は、一つの機能で終わらないことが多いです。問い合わせ対応なら、分類して、必要項目を抽出して、関連情報を探して、最後に返信文を作るかもしれません。社内ナレッジ活用なら、検索支援で候補文書を出し、要約で短くし、生成で説明文を整えるかもしれません。この章で持ち帰ってほしい新しい見方は、課題とAIは一対一ではなく、工程ごとに複数の機能を置くものだということです。

まとめ

課題から AI を選ぶときは、作る・見分ける・探す・抜き出す・見積もる・勧める、のどれが中心かを見るとかなり整理できます。そして実務では、一つの課題の中に複数の中心があることも普通です。

5. AIを選ぶときに見るべき判断基準

5-1. 出力の正しさ

AI を選ぶとき、最初に気になるのは「正しいかどうか」です。ただし、ここでいう正しさは、機能によって意味が違います。分類なら正解率や見逃しの少なさ、抽出なら必要項目をどれだけ漏らさず拾えるか、予測なら誤差の小ささ、生成なら妥当性や一貫性が中心になります。初心者がよくする失敗は、すべての AI を同じ物差しで見ようとすることです。実際には、何を返すAIかによって、見るべき指標が変わります。

ここで専門用語を二つだけ整理します。適合率は「AI が正しいと言ったもののうち、本当に正しかった割合」です。再現率は「本当に拾うべきもののうち、どれだけ拾えたか」です。危険なスパムや不正を見逃したくないときは再現率が大切になりやすく、誤判定で通常データを弾きたくないときは適合率も重要になります。言い換えると、どちらを重視するかは業務の文脈で決まります。

5-2. 業務への影響

性能が良くても、ミスしたときの影響が大きければ、導入判断は慎重にすべきです。たとえば、商品説明の下書きが少し不自然でも人が直せば済みますが、不正取引を誤って見逃す、あるいは正常な取引を止めてしまうと、影響は大きくなります。NIST の AI RMF が、技術性能だけでなく組織・社会への影響まで含めてリスクを考えるべきだとしているのは、この差があるからです。

ここで初心者が意識したいのは、ミスの回復可能性です。間違っても後で直せる仕事か、間違いがそのまま損失や不利益につながる仕事かで、AI をどこまで自動化するかは変わります。生成AIのドラフト作成は補助で済みやすい一方、審査、評価、不正検知、重要文書処理のような仕事は、人間確認を厚く残すほうが安全です。

5-3. コストと速度

AI は精度が高ければよい、では終わりません。実際の運用では、コスト、応答速度、同時に何件さばけるか、現場での使いやすさが効いてきます。Google Cloud の Document AI には価格ページがあり、機能ごとに課金があることが示されています。これはつまり、「使えるか」だけでなく、「回し続けられるか」を考える必要があるということです。

高校生向けに言い換えるなら、文化祭で便利な機械を借りても、準備が大変すぎたり、維持費が高すぎたりすれば回らないのと同じです。AI も、導入時だけでなく、毎日使えるかで見ないといけません。PoC、つまり小さな試験導入では良く見えても、本番で件数が増えたとたん運用が苦しくなることがあります。

5-4. データの準備しやすさ

AI は魔法ではなく、入力データが必要です。分類ならラベル付きデータ、抽出なら対象文書、検索支援なら検索対象となる知識ベース、予測なら過去実績データが要ります。Google Cloud の Document AI は、構造化・非構造化データから情報を抽出すると説明しており、データの性質が機能の前提になることが分かります。つまり、やりたいことがあっても、必要なデータがなければ精度は安定しにくいということです。

初心者はここで「AI を選ぶ前にデータを見ろ」という原則を持つと、判断を誤りにくくなります。たとえば、FAQ が整っていないのに検索支援だけを入れても強くなりませんし、問い合わせの正しい分類履歴がないのに自動分類をすぐ高精度で回すのは難しいことがあります。

5-5. なぜ「性能が高い」だけでは選べないのか

ここまでをまとめると、AI 選定で見るべきなのは、性能、影響、コスト、速度、データ、人間確認です。NIST や OECD が共通して重視しているのも、技術のすごさだけでなく、実際の利用文脈に応じた適切さです。だから「一番賢そうな AI を選ぶ」ではなく、「この課題に対して、適切に回せる AI を選ぶ」と考えるほうが実務に合います。

まとめ

AI 選定で見るべきなのは、精度だけではありません。ミスの影響、運用コスト、応答速度、データの準備状況、人間確認の必要性まで含めて、はじめて適用判断になります。

6. AI適用判断で必ず確認したいこと

6-1. その業務は本当にAI化すべきか

ここは、意外に抜けやすい問いです。技術的に可能でも、AI を入れる意味が薄い仕事はあります。たとえば、処理件数が極端に少ない、ルールが単純で既存の自動化で十分、ミスの影響が大きすぎる、といった場合です。NIST の AI RMF がリスク管理を強調する背景には、「導入できる」ことと「導入すべき」ことが違う、という発想があります。

6-2. 人間確認を残すべきか

次に重要なのは、どこまで人間を残すかです。AI の出力をそのまま確定してよいのか、一次案として扱うべきか、危険なものだけ人が確認するのかで、設計は大きく変わります。NIST や OECD は、人間による監督と説明責任を重視しています。これは、「AI を止めるため」ではなく、AI が間違えたときに誰が整えるかを先に決めるためです。

6-3. どの工程を自動化し、どの工程を補助にするべきか

ここでは、全自動、半自動、補助利用の三段階で考えると分かりやすいです。全自動は、AI が処理してそのまま反映する型です。半自動は、AI が候補を作り、人が確認して確定します。補助利用は、人の作業を速くするだけで、最終決定は人が持ちます。たとえば、商品説明文の下書きは補助利用で入りやすいですが、重要な審査や不正判定は半自動か人間中心のほうが安全です。

6-4. 誤りが出たときに誰が対応するのか

これは運用設計の核心です。AI は導入した瞬間より、誤ったときの対応で真価が問われます。問い合わせ分類が外れたら誰が戻すのか。抽出が漏れたらどこで拾うのか。生成文が不適切だったら誰が差し止めるのか。ここが曖昧だと、導入しても現場の不安が強く、使われなくなりやすいです。

6-5. なぜ「導入できる」と「導入すべき」は違うのか

技術的に実装できることと、実務で価値が出ることは別です。ここでの新しい発見は、AI 適用判断は「どのモデルが賢いか」より、「この業務に入れたとき、全体が安定するか」を見る仕事だということです。だから、適用判断は技術選定であると同時に、運用設計でもあります。

まとめ

AI 適用判断では、技術の可否だけでなく、監督、責任、誤り対応、業務への影響まで確認する必要があります。ここを見ると、「導入可能性」と「導入妥当性」を分けて考えられるようになります。

7. 実務ではどう組み合わせて設計するのか

7-1. 単一機能で終わるケース

単一機能で十分なケースもあります。たとえば、短い説明文の下書きだけなら生成一つで回ることがあります。迷惑メールの一次判定だけなら分類だけで足りることもあります。こうしたケースは、課題が狭く、入力と出力がシンプルで、責任範囲も明確です。

7-2. 複数機能を連携させるケース

しかし多くの業務は、複数機能の連携で考えたほうが自然です。問い合わせ対応なら分類 → 抽出 → 検索支援 → 生成、社内ナレッジ活用なら検索支援 → 要約 → 生成、EC なら予測 → 推薦 → 生成というように、工程ごとに役割が分かれます。ここで大事なのは、「AI を何台使うか」ではなく、どの工程にどの役割を置くかです。

7-3. 生成・識別・検索・抽出の連携パターン

言い換えると、これは文化祭の運営に少し似ています。まず案内係が来場者の質問を分類し、必要情報を確認し、該当資料を探し、最後に案内文を整えて返す、という流れです。AI も同じで、分類・抽出・検索・生成を連携させると、かなり現実的な仕組みになります。生成AIだけに期待しすぎると、入口の整理が弱くなりやすいので、ここが設計の分かれ目です。