AI運用のリスク管理

業務の主導権を、AIプロバイダーに渡さないために

皆さん、こんにちは。

株式会社ヴィクセスという会社をやっております、林高行と申します。この記事では、今後益々企業活動の根幹になるAIを使う上での、リスク管理について書きたいと思います。

2026年8月28日時点で、私は様々な会社の方とお話してきましたが、AIエージェントに実際の業務を任せている会社には、まだ出会っていません。

一方、チャット型AIは多くの企業で利用されています。人が質問し、AIの回答をその場で確認する使い方です。

しかし、近い将来、業務そのものが人からAIへ移っていくと思います。AIが単なる「対話相手」ではなく、業務を担う存在になっていく流れは、すでに始まっています。

顧客からの問い合わせを読み、社内資料を探し、回答案を作る。メールやSlackを確認し、必要な仕事を登録する。Webブラウザや業務システムを操作し、処理結果を別のAIが確認する。請求書の計算チェック、外注先の請求書と契約書の突合。これら全て、AIに代替されると思います。筆者は、メールの添付ファイルを保存して移動することも、今はしなくなりました。基本的に全ての業務を、AIのアプリケーションと対話しながら進めるようになりました。

一時期RPAというものも流行っていましたが、RPAはwebサイトに微小な変更があってもその度に再構築の必要があり、AIを利用した場合とは、その運用コストは比較になりません。

AIを業務の根幹に据えるなら、性能の比較だけでは不十分でして、次のような問題も考えなければなりません。

• 機密情報を、どこまで外部のAIへ渡してよいのか
• AIの利用量が爆発的に増えたとき、費用をどう抑えるのか
• 利用しているAIサービスが障害などで止まったとき、業務をどう続けるのか
• AIの品質や回答速度が突然変わったら、どうするのか
• AIが間違った判断や操作をしたとき、誰が止めるのか

弊社ではこの数カ月間、ローカルLLM、複数のクラウドAI、いくつかのAIデスクトップアプリケーション、AI同士の役割分担、Webブラウザの操作、コンピューターの操作などを、自社環境で検討・検証してきました。

その過程で分かったのは、AI利用のリスクを下げるうえで重要なのは、一つの優れたAIを選ぶことではなく、複数のAIへ仕事を分け、必要に応じて切り替え、常に柔軟にAIを代替できる構成を作ることだということでした。

対話型AIと、業務を担うAIではリスクの大きさが違う

チャット型AIでは、人が質問し、回答をその場で確認します。品質が一時的に下がったり、サービスが停止したりしても、影響はその人の作業にとどまることが多いでしょう。

一方、AIが実際の業務を担う場合は事情が変わります。一つの依頼を複数の作業に分け、異なるAIが調査、整理、判断、確認、システム操作を行うため、人がすべての会話を見続けることはできません。

そのため、「チャット」と「タスク管理」は分けて考える必要があります。チャットはAIへ相談し、指示を出す場所です。タスク管理では、どの仕事をどのAIが担当し、どこまで進み、誰の確認を待っているのかを把握します。

当社では、Hermes Agentというアプリケーションを使い、AIに任せる仕事をカンバン形式で管理しています。依頼を小さなタスクに分け、全体管理、実作業、結果確認を異なるAIへ割り当てます。この構成なら、障害や品質低下が起きたときの引き継ぎ、業務ごとのコスト把握、別会社のAIによる確認、重要な操作の前の人による承認を、タスク単位で管理できます。

利用者はチャットで指示を出し、裏側で登録・実行されたタスクの結果をチャットで受け取ります。元来チャットはチャットであり、業務をチャットで遂行するのは向いていないと思います。

そして、このような形式で基盤を構築した背景は、AI利用の上で、チャット型のAIで「業務」を行う形式だと管理できない、様々なリスクの回避が必要になってきたことからでした。これは業務の遂行をAIに対応させるどの企業にも、管理が必要なリスクです。それを以下に説明してゆきたいと思います。

リスク1：機密情報を外部へ共有してしまう

対話型AIでは、社員が機密情報を入力しないように周知することが、情報管理の中心になります。しかし、AIが業務システムとつながり、情報を自動的に読み取るようになると、周知だけでは管理できません。

AIが扱う可能性があるのは、例えば次のような情報です。

• 顧客情報
• 契約書
• 社内文書
• メール
• Slack上の会話
• ソースコード
• 売上や原価の情報
• 採用候補者の情報
• 認証情報

どのAIが、どの情報を、どこまで閲覧できるのか。外部へ送ってよい情報と、社内だけで扱う情報を分ける必要があります。

この問題への一つの対応策として、ローカルLLM、というものがあります。

ローカルLLMとは何か

ローカルLLMとは、自社保有のパソコンやサーバー上で動かすAIです。

一般的なクラウドAIでは、入力した文章やファイルが、AIサービスを提供する会社の設備へ送られ、そこで処理されます。

一方、ローカルLLMは、処理する情報を社外へ送らず、自社の機器の中で扱います。

簡単に言えば、クラウドAIが「外部の設備を借りて使うAI」であるのに対し、ローカルLLMは「自社内に置くAI」です。

ローカルLLMには、クラウドAIと比べて、次のような使い道があります。

• 社外へ出せない文書を読む
• 顧客名や個人名を含む情報を整理する
• 社内文書を検索する
• クラウドAIへ渡す前に、機密情報を取り除く

例えば、ローカルLLMで契約書を読み、会社名、個人名、金額などを伏せたうえで、難しい判断だけを高性能なクラウドAIへ任せることも考えられます。

とはいえ、ローカルLLMは強い「機器の制約」を受けます。

弊社でもローカルLLMを導入しましたが、実際の業務で運用できるレベルのものではありませんでした。

AIを動かすには、モデル本体だけでなく、AIが文章を記憶しながら処理するための領域も必要です。扱う文章はドキュメントやスプレッドシート等の場合、とても長くなりますので、その分だけ、必要なマシンのスペックも大きくなる、というわけです。

最近の技術では、量子化と言って、モデルの能力をなるべく落とさずに、小さく圧縮して、動かしやすくなる技術も進んできてはいます。しかし量子化を行うと、能力が下がる場合があります。しかもマシンのスペックも重要で、処理速度が遅ければ、業務では使いにくくなります。

ローカルLLMを使う場合は、次のことも自社で考えなければなりません。

• どの機器で動かすか
• どの程度の速さが必要か
• どの程度の文章量を扱うか
• 誰が更新や保守をするか
• 故障した場合にどうするか
• ローカルLLMの回答を誰が確認するか

よって、ローカルLLMは、クラウドAIよりビジネス的な観点で、絶対的な優劣があるわけではありません。

社外に出せない仕事や、繰り返しの多い仕事を担当させる選択肢として考えるのが現実的です。

リスク2：利用量増大に伴うコスト増の回避

AIが事業の根幹を担うようになると、社員が必要なときだけチャットAIを使う場合より、利用量は大きく増えます。

例えば、弊社の場合、具体的にAIが毎日以下の業務を行っています。

• 過去の資料の調査
• 別のAIによる回答の確認
• メールの下書き作成
• 業務システムへの情報の登録
• 処理結果の報告
• ファイルの整理・編集
• slackの依頼を整理
• 請求書の作成
• 外注先からの請求書の確認
• 請求書と契約書の整合性の検証
• 見積書の作成

単一の業務であっても、複数回AIを実行することになりますが、これが何十件、何百件と積み重なれば、相当なコストになります。

AIが文章を読み書きする量は「トークン」という単位で計算されます。一般に、長い資料を読み、高性能なモデルに長く考えさせ、長い回答を出させるほどトークン量は増えて、費用は増えます。

全ての仕事を一つの高性能モデルに任せると、費用が膨らみます。難しい判断には高性能なAIが必要でも、文章の分類、短い要約、情報整理、定型的な下書きまで、同じ高価なAIに任せる必要はありません。一つの依頼を複数のタスクに分け、難易度に応じて使い分けます。

• 簡単なタスクは、安価で速いクラウドAIに任せる
• 難しい判断だけ、高性能なクラウドAIに任せる
• 社内で大量に繰り返すタスクは、ローカルLLMに担当させる
• 複数のAI提供会社のモデルを使い、その時点で費用対効果の高いモデルを選ぶ
• 同じ資料を何度も最初から読ませない
• 本当に確認が必要な仕事だけ、別のAIに確認させる

ただし、常に最も安いAIを使えばよいわけではありません。間違いが増え、人によるやり直しが発生すれば、人件費と社員の精神的な負荷が大きくなります。

企業が見るべきなのは、AI一回当たりの料金ではなく、その仕事を必要な品質で終わらせるための総費用です。

料金変更にも備え、複数のモデルを平時から使い、総費用と品質を見ながら担当を変えられる状態にしておくべきです。

リスク3：AIサービスの障害で業務が止まる

AIが顧客対応、受発注、営業活動、社内申請、情報整理などを担うようになると、AIサービスの障害は自社業務の停止に直結します。そのため、複数のAIサービスを利用できる運用を準備しておく必要があります。

ただし、二社と契約しているだけでは不十分で、普段全く使っていないAIを障害時だけ急に使おうとしても、すぐには、実務上、運用可能なレベルにはならないです。

• 同じ指示を出しても、期待した答えにならない
• 回答の形式が異なる
• 外部のシステムへ接続できない
• 文章の長さや内容が変わる
• どの仕事まで代わりに任せられるか分からない

そのため、複数のAIは、緊急時の予備として置いておくだけではなく、平時から役割を持たせておくことが重要です。

例えば、日常的な文章整理はA社、難しい判断はB社、結果の確認はC社というように、普段から使い分けます。

そうしておけば、A社のサービスが止まった場合にも、B社やC社へ仕事を移しやすくなります。

障害時の対応としては、

• 優先度の低い仕事は止める
• 機密性の高い仕事は、対応可能な範囲でローカルLLMへ切り替える
• 重要な仕事は別のクラウドAIへ移す
• AIを使えない仕事は人へ戻す

というプランを持っておくべきです。

AIが止まったときに初めて対応を考えるのではなく、どの業務を止め、どの業務を継続するかを先に決めておくことです。これは部署ごとに決めておく必要がありますね。

リスク4：AIのナーフ

クラウドAIは、自社が設定を変更していなくても、以前と同じ状態で使い続けられるとは限りません。

AIの利用者の間では、モデルの性能や使い勝手が以前より悪くなることを、俗に「ナーフ」と呼ぶことがあります。

例えば、提供会社側の調整、不具合、混雑などにより、次のような変化が起こることがあります。

• 同じ業務なのに、以前より多くのトークンを使う
• 回答の質が下がる
• 指示を正確に守らなくなる
• 回答内容が必要以上に長くなる
• 回答までの時間が長くなる
• 外部ツールの操作に失敗しやすくなる
• 以前はできていた仕事が、うまくできなくなる

こうした変化の原因が、一時的な不具合なのか、提供会社側の調整なのか、利用者側からすぐには分からない場合もあります。

AIが毎日大量の業務を処理している場合、わずかな変化でも大きな影響が出ます。

回答が長くなれば、トークン使用量が増え、コスト増になります。回答時間が長くなれば、それだけ業務時間が長くなってしまいます。そして、品質が下がれば、人による修正が増えます。

一つのモデルだけに依存していると、状態が悪くなったときに選択肢がありません。回答の質、費用、回答時間を日常的に確認し、同じ仕事を別会社のAIでも処理できるようにします。

状態の悪化を機に、別のクラウドAIへ全面移行するだけでは十分ではありません。移行先でも同じことが起こり得るからです。どのクラウドAIも変化し得ると考え、タスク単位で担当を切り替えられる運用が必要です。

リスク5：AIが誤った判断や操作をする

AIはいつでも正しいわけではないです。間違えます。

ただ、人間が最終確認するフローが組み込まれているタスクであれば、もし間違ったとしてもミスは回避が可能です。

とはいえ、リスク管理の基本は「リスクを最小化しながら、リターンを最大化すること」です。そのため、可能ならば人間による確認も、減らせるに越したことはありません。

例えば、次のような事態は避けつつ、AIで対応できればよいと思います。

• 誤った相手にメールを送る
• 顧客へ間違った情報を回答する
• 必要な情報を見落とす
• 誤った内容を業務システムへ登録する
• ファイルを上書きする
• 不要な処理を繰り返す
• 外部サイト上の誤った指示に従う

このリスクを小さくするために、当社では、AIにも役割を分けることが必要だと考えています。

複数のモデルを使う

複数のAIが協力して仕事を行う仕組みでは、主に次の役割があります。

仕事を分ける役: デコンポーザー

大きな依頼を、実行可能な小さなタスクに分割します。

例えば、「競合企業を調べ、提案書を作る」という依頼を、

• 調査する
• 情報を整理する
• 比較する
• 提案内容を考える
• 文章にまとめる
• 内容を確認する

というタスクに分割します。

この役割は、Decomposerと呼ばれ、ここにも一つのモデルを割り当てます。

全体を管理する役: オーケストレーター

どの仕事を、どのAIへ任せるかを決めます。

簡単な仕事は安価なAI、難しい判断は高性能なAI、機密情報を扱う仕事はローカルLLMというように、担当を振り分けます。

複数の結果をまとめ、次に何をするかを判断する役でもあります。

この役割は、Orchestratorと呼ばれることがあります。

実際に作業する役: ワーカー

調査、要約、文章作成、データ整理、Webブラウザの操作など、個別の仕事を実行します。

この役割は、Workerと呼ばれます。

別の立場から確認する役: レビュワー

作業したAIとは別に、結果を確認します。

• 事実に間違いがないか
• 重要な点を見落としていないか
• 指示から外れていないか
• 前後で矛盾していないか
• 不自然な結論になっていないか

を確認します。

この役割は、Reviewerと呼ばれます。

特に重要なのは、作業者としてのAIと確認者としてのAIを別のモデルに割り当てることだと思います。

一つのAIに、

「自分の回答に間違いがないか確認してください」

と頼んでも、自分が最初に行った間違いに気づかない場合があります。

そのため、作業を行ったモデルとは別のモデル、できれば別会社のモデルに確認させます。

別会社のAIであれば、考え方や回答の傾向が異なるため、一つのAIだけで処理するよりも、見落としを発見できる可能性が高まります。

ただし、別のAIに確認させれば、必ず正しくなるわけではありません。

二つのAIが同じように間違うこともあります。

そのため、次のような重要な操作は、人が最後に確認します。

• 顧客への送信
• 契約に関わる判断
• 支払いや発注
• ファイルの削除
• 重要情報の変更
• 外部への公開

AIによる確認と、人による確認は、どちらか一方を選ぶものではありません。

仕事の重要度に応じて、両方を組み合わせます。

役割分担の具体例

例えば、次のような流れが考えられます。

1. ローカルLLMが、社内の機密文書を読む
2. 社名や個人名を除いた情報を、安価なクラウドAIへ渡す
3. 安価なAIが、必要な情報を整理する
4. 高性能なAIが、全体を見て結論を出す
5. 別会社のAIが、間違いや見落としを確認する
6. 人が重要部分を確認する
7. 操作を得意とするAIが、承認された内容をシステムへ登録する

このように役割を分ければ、情報、費用、障害、品質、誤操作のリスクを分散でき、担当AIの状態が悪いときも仕事を移しやすくなります。

追記

なので、会社にAIを導入する立場の人は、どの業務にはどのモデルを割り当てるべきか、を適切に行う必要があり、そのためには業務、モデル特性どちらも理解しておく必要がある、ということですね。とても重要な仕事だと思います。

企業がAIを業務の根幹に組み込む前に決めること

企業がAI活用を広げる前に、少なくとも次のことを決めておく必要があります。

1. 業務の切り分け

どの仕事をAIに任せ、どの判断を人に残すのかを決めます。

2. 外部へ送ってよい情報

クラウドAIへ送ってよい情報、名前や金額を伏せて送る情報、社外へ出してはいけない情報を分けます。

3. ローカルLLMに任せる仕事

機密情報を扱う仕事、大量の繰り返し作業、クラウド障害時にも継続する必要がある機密性の高い仕事を候補にします。

4. AIごとの役割

簡単な仕事、難しい判断、結果の確認、システム操作を、どのAIへ任せるか決めます。

5. 別のAIへの切り替え方

主に使っているAIが停止した場合、費用が上がった場合、品質が下がった場合に、どのAIへ切り替えるか決めます。

6. 確認方法

どの仕事を別のAIに確認させ、どの仕事を人が確認するか決めます。

7. AIに与える権限

読むだけでよいAIに、書き込みや送信の権限まで与えないようにします。

8. 問題が起きたときの責任者

誰がAIを止め、業務を人へ戻し、別のAIへ切り替えるかを決めます。

AI活用時代に必要となる人材

AIを業務の根幹へ組み込む場合、必要なのは、特定のAIサービスを使える人だけではありません。

• 業務を細かな仕事へ分けられる
• ローカルLLMとクラウドAIを使い分けられる
• 複数のAIサービスへ役割を分けられる
• 情報をどこまで外部へ出せるか判断できる
• AIの利用コストを管理できる
• AIが止まったときの代わりを用意できる
• AIの回答を別のAIや人に確認させられる
• ブラウザやPC操作の権限を適切に制限できる
• 問題を発見し、自ら改善案を提案できる
• 経営者、業務部門、情報システム部門と会話できる

こうした力が必要になります。

AI・LLMの知識だけでなく、業務、システム、情報管理、費用、障害対応を横断して考える必要があります。

AIの動作が不安定なときにも冷静に原因を探し、関係者へ分かりやすく説明し、必要な対応を提案できる人材が求められます。

業務の根幹を、一社・一モデルに預けない

AIが業務の根幹を担うなら、一社・一モデルへの依存は避けるべきです。仕事を小さく分け、機密性、難易度、費用、速度に応じて、ローカルLLMと複数のクラウドAIを使い分けます。ワーカーによるタスクの実行結果は、別モデルのAIがレビュワーとして確認し、重要な判断や操作は人が承認します。

企業側に残すべき主導権は、担当を選び、止め、切り替える権限です。この状態を作ることが、AI活用のリスク管理になると考えます。

AI・LLM案件に対応できる人材をお探しの企業へ

Excellent Partnersでは、採用市場や一般的な業務委託市場ではほぼ見つからない、上位0.1%のプロフェッショナル人材に特化し、AI・LLM案件を含む重要プロジェクトの実装・開発・PM体制の強化をご支援しています。

ご紹介するのは、東京大学、東京科学大学、東北大学、東京理科大学などの理工系修士・博士人材を中心に、10年程度の開発経験を持つシニアエンジニア、開発PM、日英バイリンガルPM、アルゴリズム・データサイエンス人材などです。技術力だけでなく、協働性、主体性、提案力、円熟したコミュニケーション、既存チームに入りながら案件を前に進める実行力も重視しています。

AI・LLM案件に対応できる経験豊富な人材、AIを業務へ組み込むための体制構築は、Excellent Partnersへお声掛け頂けましたら幸いです。