生成AIの導入は、どのサービスを試すかではなく、どの業務判断に組み込み、どこで人が確認するかを決める段階に入った。
制作、開発、問い合わせ対応、社内調査などの場面で使える範囲は広がっているが、成果が出る会社と混乱する会社の差は、モデルの性能よりも業務設計に表れやすい。
Webサイト、アプリ、業務システム、マーケティング施策に関わるチームほど、この差は早く出る。
作るものがデジタルで、判断材料が文章や画像やログに残りやすいため、生成AIを入れる余地が大きいからだ。
導入の焦点は業務設計へ移った
McKinseyの2025年のAI調査では、回答組織の88%が少なくとも一つの業務機能でAIを定期利用している一方、全社的な拡大に入った企業はおよそ三分の一にとどまる。
同じ調査では、AIエージェントを一部業務で拡大している組織は23%、実験段階にある組織は39%とされている。
この数字が示すのは、利用そのものは珍しくなくなったが、業務全体に成果を出す段階にはまだ距離があるということだ。
その距離を埋めるには、生成AIを個人の便利な補助ツールとして置くだけでは足りない。
入力する情報、参照してよいデータ、出力を確認する人、実行してよい操作、失敗したときの戻し方を業務フローに組み込む必要がある。
任せる仕事を三つに分ける
生成AIに任せる仕事は、難易度ではなく責任の所在で分けると判断しやすい。
| 区分 | 向いている使い方 | 確認の要点 |
|---|---|---|
| 下書き | 記事構成、FAQ案、営業メール、要件整理の初稿 | 事実、語調、公開してよい情報を人が確認する |
| 照合 | 仕様と画面、原稿とチェックリスト、問い合わせと過去回答の突き合わせ | 参照元を残し、根拠がない補完を採用しない |
| 実行補助 | チケット作成、簡単なコード修正案、社内ナレッジ検索 | 権限を限定し、変更前に承認点を置く |
下書きは比較的始めやすい。
ただし、公開原稿や広告クリエイティブでは、出力の速さよりもブランドの一貫性、権利処理、表現の正確さが問題になる。
照合は、Web制作やシステム開発で効果が出やすい。
要件定義、UI文言、アクセシビリティ項目、SEO項目は、チェックすべき観点が明確で、生成AIが見落とし候補を出しやすい。
実行補助は最も慎重に扱う。
ファイル更新、外部送信、顧客データの処理、請求や権限変更に近い操作は、モデルの判断だけで進める設計にしない。
信頼できる状態は三層で作る
生成AIを会社で使える状態にするには、入力、出力、権限の三層を分けて設計する。
入力の層では、社外秘、個人情報、契約情報、未公開の顧客情報を扱うルールを決める。
使ってよいデータと使ってはいけないデータを、部署ごとの判断に任せると運用がばらつく。
出力の層では、根拠を確認する手順を置く。
公開前の原稿、コード、法務に近い説明、価格や制度に関する記述は、担当者が一次情報に戻れる形で確認する。
権限の層では、生成AIができる操作を最小限にする。
読み取りだけで足りる作業に書き込み権限を与えない。
承認の前後で、誰が何を確認したかをログに残す。
リスク管理は後付けにしない
NISTのAI Risk Management Frameworkは、AI製品やサービスの設計、開発、利用、評価に信頼性の考慮を組み込むための枠組みとして公開されている。
NISTは2024年に生成AI向けのプロファイルも公開し、生成AI特有のリスクを特定し、組織の目的に合わせて管理するための行動を示している。
実務では、枠組みを読むだけで安全になるわけではない。
業務ごとに、誤答、情報漏えい、著作権や商標の扱い、差別的な出力、説明できない判断、過剰な権限付与を具体的に洗い出す必要がある。
セキュリティ面では、OWASPのTop 10 for Large Language Model Applicationsが参考になる。
同プロジェクトは、プロンプトインジェクション、出力の不適切な処理、機密情報の漏えい、過剰な自律性、過信などを主要なリスクとして整理している。
Webサイトや業務アプリにAIチャット、エージェント、検索拡張を組み込む場合、これは通常のWebセキュリティとは別枠の話ではない。
認証、権限、ログ、監査、データ分類と同じ設計対象として扱う。
小さく始めるなら確認できる業務を選ぶ
最初の導入対象は、失敗しても戻せる業務、成果を測れる業務、既存の確認手順がある業務から選ぶ。
たとえば、公開前の記事チェック、問い合わせ回答案の作成、既存ページの改善候補の抽出、社内FAQの検索補助は始めやすい。
一方で、契約判断、採用合否、医療や法律に近い助言、金銭の支払い、アカウント停止のような判断は、導入初期の実験対象にしにくい。
成果指標も先に決める。
作業時間の短縮だけを見ると、確認漏れや修正コストが隠れる。
公開後の修正件数、問い合わせの再発率、レビュー差し戻し率、検索流入、コンバージョン、社内満足度を組み合わせて見るほうが、実運用の価値を判断しやすい。
導入前のチェックリスト
- 対象業務を一つに絞り、入力、処理、出力、承認の流れを書き出す。
- 扱うデータを分類し、入力してよい情報と禁止する情報を決める。
- 出力を確認する担当者と、確認する根拠資料を決める。
- AIが実行できる操作を読み取り、下書き、提案、書き込みに分ける。
- 誤答、漏えい、権利侵害、過信が起きたときの止め方と戻し方を決める。
- 効果測定の指標を、速さ、品質、リスク、売上や問い合わせなどの成果に分ける。
よくある質問
どの部門から始めるべきか
既存のレビュー手順があり、文章や資料を扱う部門から始めるのが現実的だ。
マーケティング、カスタマーサポート、社内ナレッジ、Web運用、開発補助は、確認ポイントを設計しやすい。
社員が個人で使っている状態は問題か
利用自体よりも、入力する情報と出力の使い方が問題になる。
会社として許可する範囲、禁止するデータ、公開前の確認手順を明文化しないと、便利な使い方と危険な使い方を区別できない。
AIエージェントはすぐ業務に入れられるか
読み取りと提案に限るなら試しやすい。
外部送信、書き込み、権限変更、支払い、顧客対応を伴う場合は、承認点、ログ、ロールバックを先に設計する必要がある。
参考資料
- McKinsey: The state of AI in 2025
- NIST: AI Risk Management Framework
- OWASP: Top 10 for Large Language Model Applications