AI活用概論

【演習】AI活用要件と適用条件の言語化

概論AI活用ChatGPTGeminiClaude基礎から学ぶ

この章のねらいは、ここまで学んだ AI の機能分類、データ構造、精度・限界・リスクの知識を使って、自分で AI 活用要件と適用条件を言葉にできるようになることです。

第1章では生成AIの基本と人間との役割分担を学び、第2章前半では「どの AI が何に向くか」を整理してきたので、この章では言語化し、再現できる状態につなげていきます。「知っている」から「書ける・説明できる」状態に進めていきます。

はじめに

ここまでの章では、生成、分類、抽出、要約、検索支援、予測、推薦、異常検知など、AI にはいくつもの機能があることを見てきました。ただ、実務や学校の企画では、機能名を知っているだけでは足りません。必要なのは、「どんな課題に、どの AI を、どの条件で入れるのか」を、ほかの人が読んでも分かる形で書けることです。たとえば、「AI で学習支援をしたい」と言うだけでは、何を入力にして、何を出力にして、誰が確認するのかが分かりません。ここを言語化できないと、アイデアはあっても設計になりません。これは、AI を使う現場だけでなく、文化祭の運営、部活動の連絡整理、学校の資料作成のような身近な場面でも同じです。

この章ではまず、「思いつき」と「要件」の違いを整理します。そのうえで、AI 活用要件と AI 適用条件を分けて考え、良い言語化と弱い言語化を比較しながら、自分で書けるところまで進みます。ここでいう要件とは、「AI に何をさせたいか」を具体的にしたものです。適用条件とは、「どんな条件ならその AI を入れてよいか」を決めるものです。この二つを分けて書けるようになると、AI を使った企画や要件定義の精度が一気に上がります。

参考文献

1. なぜ「言語化」の演習が必要なのか

1-1. AI 活用で言語化が必要になる場面

AI を使う場面では、実は「AI を動かす」前に「AI を説明する」ことが何度も必要になります。たとえば、先生や上司に提案するとき、チームで役割分担するとき、開発者へ依頼するとき、あるいは導入後に運用ルールを決めるときです。ここで説明が曖昧だと、同じ言葉を使っていても、人によって思い描く仕組みがズレます。Google Cloud が生成AIや Document AI をユースケースや処理フローで整理しているのは、まさに「何にどう使うのか」を言語化しないと導入判断ができないからです。

高校生にも分かりやすく言うと、これは「なんとなく文化祭を盛り上げたい」と言うのと、「来場者の質問にすぐ答えられる案内チャットを作りたい」と言うのとの差に近いです。前者は気持ちですが、後者は設計の入口です。AI 活用でも同じで、気持ちや願望を、入力・出力・条件まで含めた文章へ変える力が必要です。ここで言語化が弱いと、便利そうなサービスを見つけても、実際の課題と結びつかず、導入が空回りしやすくなります。

1-2. 「思いつき」と「要件」は違う

「AI を使ってみたい」「学校の質問対応を自動化したい」「SNS 運用を効率化したい」というのは、出発点としては良い思いつきです。ただし、これだけでは要件にはなっていません。なぜなら、何を入力として、何を返し、どこまで自動化し、誰が確認するかが書かれていないからです。思いつき は方向性で、要件 は実行可能な形に整えた条件付きの文章です。ここを分けて考えられるようになると、AI 活用は急に現実的になります。

たとえば、「AI で問い合わせ対応をしたい」という一文はまだ広すぎます。これを要件へ近づけるなら、「問い合わせメール本文を入力とし、内容を返品・配送・支払いに分類したうえで、各カテゴリに対応した返信案を作る」と書く必要があります。この時点で、分類と生成の二つの機能が必要だと見えます。さらに、「返信は必ず担当者が確認してから送信する」と付ければ、適用条件も見えてきます。ここまで書けて初めて、実際に作る仕組みの輪郭が立ちます。

1-3. なぜこの章は第2章の後半に置くのか

この章が第2章の後半にあるのは、ここまでの知識がそろって初めて、良い言語化ができるからです。生成AIと識別AIの違いを知らなければ、どの機能を書けばよいか分かりません。データ構造の違いを知らなければ、入力の書き方が曖昧になります。精度・限界・リスクを知らなければ、適用条件が薄くなります。つまり、この章は知識のまとめではなく、知識を文章へ変える演習の章です。

まとめ

この節で持ち帰ってほしいのは、AI 活用では「分かっている」だけでは足りず、「他人が読んでも分かる形で書ける」ことが必要だという点です。思いつきと要件は違います。そして、この違いを言葉にできるようになることが、この章の出発点です。

参考文献

2. 初心者が最初に混同しやすい三つのもの

2-1. 業務課題と AI でやりたいこと

最初に混同しやすいのは、困っていること と AI にやらせたい処理 の違いです。たとえば、「返信が遅い」は課題です。「返信文を自動生成したい」は AI にやらせたいことです。この二つを区別しないと、課題を解く前に手段だけ先に決めてしまいます。AI を使うかどうか以前に、まず何が困りごとなのかを言葉にする必要があります。NIST の AI RMF は、AI を扱うときに context、つまり文脈を重視しており、課題の整理なしに適切な設計はできないことを示しています。

たとえば、EC サイトで「売上を伸ばしたい」というのは課題ですが、AI にやらせたいことは一つではありません。商品説明文を良くしたいのか、レコメンドを強くしたいのか、問い合わせ対応を速くしたいのかで、必要な AI は変わります。つまり、課題は広く、AI の処理は細かい。この関係を見誤ると、AI 活用要件はふわっとした文章になりやすいです。

2-2. 活用要件と適用条件

次に混同しやすいのが、活用要件 と 適用条件 です。活用要件は、「AI に何をさせたいか」を書くものです。たとえば、「問い合わせ本文をカテゴリ分類し、返信案を作る」「会議録音を文字起こしして要約する」「学習履歴から次の教材候補を出す」といった内容です。一方で適用条件は、「どんな条件なら、その AI を入れてよいか」を書くものです。たとえば、「返信は必ず担当者が確認する」「誤分類率が一定以下であること」「個人情報を含むデータは外部送信しない」といった条件です。

ここで初心者が陥りやすいのは、両方を一つの段落へ混ぜてしまうことです。すると、「何をしたいのか」と「どういう条件なら許されるのか」が読みにくくなります。良い文章は、この二つを分けて書きます。活用要件は機能の話、適用条件は運用・安全・責任の話、と覚えるとかなり整理しやすくなります。

2-3. AI 機能とサービス名

もう一つ重要なのが、AI 機能 と サービス名 を分けることです。生成、分類、抽出、要約、検索支援、予測、推薦といったものは機能です。ChatGPT、Document AI、BigQuery の AI.CLASSIFY などはサービスや機能提供の仕組みです。初心者は、サービス名から考え始めやすいです。しかし、実際には先に必要なのは「分類か、抽出か、生成か」といった機能の整理です。Google Cloud の Document AI も、文書分類、抽出、分割などの機能単位で説明されています。

たとえば、「ChatGPT を使いたい」はサービス名ベースの発想です。「問い合わせを分類して、返信案を作りたい」は機能ベースの発想です。後者のほうが、別の手段へ置き換えることも、組み合わせることもやりやすいです。つまり、言語化ではサービス名より先に機能を書くほうが強いのです。

まとめ

この節で整理したいのは三つです。課題と AI の処理は違う。活用要件と適用条件は違う。機能とサービス名は違う。この三つが分かれるだけで、AI 活用の文章はかなり読みやすく、判断しやすくなります。

参考文献

3. AI活用要件を言語化する基本フォーマット

3-1. 何を改善したいのかを書く

AI 活用要件の最初の一文は、「何を改善したいのか」から始めると安定します。ここで書くのは、夢や理想ではなく、現場の困りごとです。たとえば、「問い合わせ返信に時間がかかる」「授業後の質問整理に手間がかかる」「会議録の共有が遅い」「商品説明の質が担当者ごとにばらつく」といった書き方です。こうすると、AI を入れる理由が明確になります。

初心者は「AI で効率化したい」のような言い方をしがちですが、これはまだ広すぎます。良い書き方は、「誰が、どの作業で、何に困っているか」が見える文章です。たとえば、「学校の先生が、生徒からの放課後質問を整理するのに時間がかかっている」と書けると、後で入力や出力を書きやすくなります。つまり、活用要件は目的を狭くすることから始まります。

3-2. 何を入力として使うのかを書く

次に必要なのは、入力を書くことです。ここでいう入力とは、AI が受け取る情報のことです。問い合わせメール本文なのか、請求書 PDF なのか、会議録音なのか、学習履歴の表なのかで、向く AI は変わります。前の章で見た通り、AI 機能とデータ構造の相性は重要です。だから、要件の中で入力が曖昧だと、AI の選び方も曖昧になります。

たとえば、「質問に答える AI を作る」と書くだけでは弱いです。これを「生徒が入力する自然文の質問文を入力とし、学校の教材 PDF と FAQ 文書を参照して答える」と書けると、必要なのが検索支援、要約、生成の組み合わせだと見えます。つまり、入力を書くことで、必要な AI 機能がかなりはっきりします。

3-3. 何を出力として返したいのかを書く

その次に必要なのが、出力を書くことです。出力とは、AI が最終的に返すものです。文章なのか、カテゴリなのか、抽出項目なのか、予測値なのか、候補一覧なのか。ここを曖昧にすると、途中の処理がどれだけ良くても「結局何がほしかったのか」が不明になります。

たとえば、「書類処理を楽にしたい」という課題に対して、出力が「抽出された金額・日付・会社名」なのか、「処理結果の要約文」なのかで、必要な機能は変わります。前者は抽出が中心で、後者は抽出の後に要約や生成が入るかもしれません。だから、良い要件は、入力と出力の形が読んだだけで分かるものです。

3-4. どの AI 機能を使うのかを書く

最後に、入力と出力をつないでいる AI 機能を書きます。ここでは、生成、分類, 抽出、要約、検索支援、予測、推薦などの言葉を使います。重要なのは、一つしか選んではいけないと思わないことです。実際の業務では、分類してから生成する、抽出してから要約する、検索してから回答生成する、というように複数機能が連携することがよくあります。

たとえば、「問い合わせ本文を分類し、関連する FAQ を検索し、その内容をもとに返信案を生成する」という書き方なら、分類・検索支援・生成の三つが入っています。ここまで書けると、読む人は仕組みの流れを具体的に想像できます。つまり、良い活用要件は、課題 → 入力 → 出力 → 機能 の流れがつながっている文章です。

まとめ

AI 活用要件を言語化するときの基本は四つです。何を改善したいか。何を入力にするか。何を出力にするか。どの AI 機能を使うか。この四つを書けるようになると、思いつきはかなり設計に近づきます。

参考文献

4. AI適用条件を言語化する基本フォーマット

4-1. どこまで自動化してよいかを書く

AI 活用要件だけでは不十分です。次に必要なのが、どこまで自動化してよいか を書くことです。これは適用条件の中心です。たとえば、AI が作った下書きを人が確認してから使うのか、AI の分類結果をそのまま反映してよいのか、危険なものだけ人が見るのかで、設計はかなり変わります。NIST は AI の利用で human oversight、つまり人間による監督の重要性を強調しています。

ここで初心者がつまずきやすいのは、「AI を使う = 全自動化」と思うことです。ですが、現実には補助利用、半自動、全自動の段階があります。たとえば、SNS 投稿案の作成なら補助利用で入りやすいです。一方で、重要書類の判定や進路に関わる助言は、必ず人間確認を挟むほうが安全です。適用条件では、この境界を明示する必要があります。

4-2. 人間確認をどこに残すかを書く

適用条件の中でも特に重要なのが、人間確認の位置です。誰が、どの段階で、何を確認するのかを書かなければ、AI が出した結果をそのまま確定してよいのか分からなくなります。たとえば、「返信案は担当者が確認する」「抽出結果は経理担当が確認する」「学習推薦は先生が承認する」と書けると、責任の流れがはっきりします。

ここで大切なのは、確認を“保険”として書くのではなく、運用の一部として書くことです。つまり、「AI が間違えるかもしれないから人が見る」だけではなく、「この工程は人の判断を残すべきだから確認する」と考えることです。これは、責任の所在をあいまいにしないためにも重要です。

4-3. どんなミスが許されないかを書く

適用条件では、「どんな間違いが危険か」も明示する必要があります。生成AIなら誤った説明や不適切な表現、分類AIなら重要な問い合わせの見逃し、抽出AIなら契約期間や金額の抜け漏れ、推薦AIなら偏った候補の提示などが考えられます。ここを先に書いておくと、どのくらいの精度が必要か、人間確認をどこへ置くかも決めやすくなります。

初心者は「精度が高ければ大丈夫」と書きがちですが、それでは弱いです。必要なのは、「危険なミスは何か」を先に書くことです。たとえば、「危険な問い合わせを一般的な質問へ誤分類しないこと」「個人情報を含む内容をそのまま公開しないこと」「重要項目の抽出漏れを起こした場合は差し戻すこと」といった形です。

4-4. どの条件なら導入してよいかを書く

最後に、導入判断の条件を書きます。ここでは、精度だけでなく、速度、コスト、データ準備、運用負荷も含めます。たとえば、「返信案は 10 秒以内に生成されること」「誤分類率が一定以下であること」「入力データの匿名化ができること」「月間処理件数に対して運用が回ること」などです。Google Cloud の各サービスが、機能だけでなく利用条件やワークフローを示しているのは、導入判断が性能だけで決まらないからです。

まとめ

適用条件を書くときは、どこまで自動化してよいか、人間確認をどこに残すか、どんなミスが危険か、どんな条件なら導入してよいかを書く必要があります。これが書けると、要件は「やりたいこと」から「導入してよい設計」へ進みます。

参考文献

前の節AI分類ごとに異なる精度・限界・リスクの理解次の節次章への接続：生成AI活用のためのプロンプト設計へ
教材トップへ戻る