0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

CopilotかGeminiか、ではない

0
Posted at

NRIの実践から考えるマルチAI時代の活用推進と統制

企業で使う生成AIは、どれを選ぶべきなのか。Microsoft 365 Copilot、Gemini、ChatGPT、Claude、コーディング支援AI、あるいは業務システムに組み込まれたAI機能か。

この問いを「最も優れたAIを一つ選ぶ」という製品比較にしてしまうと、企業の実態を見誤る。

メール、会議、文書作成ではMicrosoft 365 Copilotが業務へ入りやすい。複数資料の比較、根拠確認、情報の再利用にはGeminiやNotebookLM系の機能が向く。開発現場では、リポジトリ、テスト、CI/CDへ接続できるコーディングAIが必要になる。機密性の高い業務では、自社管理下のAI基盤を選ぶこともある。

つまり論点は、「どのAIを一つ選ぶか」から、複数のAIと人間が、どの業務をどう分担するかへ移っている。

AI Agent Day Summer 2026で紹介されたNRIの実践は、CopilotとGeminiの優劣を比べるものではない。二つのAIが置かれた業務環境の違いによって、活用推進、期待値設計、統制の方法を変える必要があることを示す事例である。

NRIは公開情報でも、Microsoft系を中心とするAI共創モデルに加え、Google Cloudへ対象を拡大し、社内でGemini、NotebookLM、Gemini Enterpriseの活用ノウハウを深める方針を示している。NRIのGoogle CloudへのAI共創モデル拡大

AI活用は「製品選定」から「仕事の分担設計」へ

企業のAI導入では、まず次の四つを決める。

  • どの仕事にAIを使うか
  • どのAIがその仕事に適するか
  • AIへ何を任せ、人間がどこを判断するか
  • データ、権限、品質、責任をどう管理するか

AI導入は、単なるライセンスの調達ではない。業務設計、データ設計、組織設計、統制設計を伴う。

業務の性質 主なAI活用 設計上の焦点
日常のオフィス業務 メール、会議、文書、表計算、資料作成 既存の仕事との役割分担、期待値調整
調査・知識活用 複数資料の比較、要約、根拠確認、論点整理 情報源、共有範囲、出典、再現性
ソフトウェア開発 コード生成、レビュー、テスト、調査 開発環境、権限、CI/CD、レビュー
機密・専門業務 顧客・契約・技術情報を使う支援・実行 最小権限、監査、人間承認、品質評価

「最も賢いモデル」を選んでも、業務に必要なデータへ安全に接続できず、出力を評価できず、責任分界が曖昧なら価値は生まれない。

Copilot導入で起きる「既存ツールへの期待」という壁

Microsoft 365 Copilotは、Word、Excel、PowerPoint、Outlook、Teamsなど、日常業務で使い慣れた環境に入る。そのため、利用者は高い期待を持ちやすい。

「資料を完成させてくれる」「Excel分析をすべて代行する」「会議後の作業をなくしてくれる」と期待する。しかし、AIが返すのは多くの場合、完成品ではなく、一定品質のたたき台である。

利用者の頭の中に100点の資料イメージがあるとき、AIが60〜80点の草案を出しても、その差分が不満になりやすい。本来、草案を短時間で作れること自体に価値があっても、「自分で作った方が速い」「期待した形にならない」と感じる。

講演で紹介されたCopilotトライアルの参加者数、NPS、ライセンス継続率は講演紹介値であり、公開資料で確認できる数値ではない。ただし、そこから得られる設計上の教訓は一般化できる。

既存ツールへAIを追加する場合、モデル能力だけでなく、利用者が既存ツールへ持つ完成形の期待値を管理しなければならない。

一斉研修だけでは、定着しない

勉強会で「何ができるか」「何が苦手か」を伝えれば、期待と現実の差はある程度縮まる。しかし一般的な機能紹介だけでは、利用者は自分の仕事への当てはめ方まで分からない。

「Wordで要約できる」「Excelで分析できる」と聞いても、「毎月行うこの集計にどう使うか」「この資料の品質基準を満たすか」は別の問題である。

そこで必要になるのが、全社向けの情報発信と、重点部署への伴走支援の組み合わせだ。

対象部署の業務を聞く
  ↓
AIを適用できる工程を洗い出す
  ↓
部署固有のユースケースと役割分担を設計する
  ↓
実務で試す
  ↓
品質・手戻り・利用者体験を評価する
  ↓
プロンプト、データ、業務手順を改善する

伴走支援で教えるべきなのは、操作方法だけではない。

  • どの作業をAIへ任せるか
  • 人間が確認すべき箇所はどこか
  • AIを使わない方がよい場面は何か
  • 出力をどの基準で評価するか
  • 何を成果として測るか

AI活用を、ツールの使い方ではなく、業務の役割分担として設計する必要がある。

「全部やってくれる」という期待を分解する

AI活用には、二つの壁がある。

第1の壁:何を頼めばよいか分からない

利用者がAIへ適切な目的、入力、制約を渡せなければ、期待した結果は得にくい。この壁は、実務に近いユースケース、テンプレート、部署内の相談相手、短い試行で越えやすくなる。

第2の壁:多くは正しくても、一部を間違う

使い方が分かると、次は品質の問題が見える。総務、経理、法務、人事のように正確性が重要な業務では、わずかな誤りでもそのまま自動実行できない。

この段階で必要なのは、AIを万能な自動化装置として見せないことだ。

  • 参照情報を追加・整備する
  • 入力形式と業務ルールを標準化する
  • 根拠と未確認事項を表示する
  • 人間の検証・承認を残す
  • 使える範囲と使えない範囲を明示する

期待値を下げるのではない。AIと人間が得意な部分を正しく分け、実務で価値が出る期待値に合わせることである。

Gemini・NotebookLM系は「新しい仕事の仕方」を見せやすい

NRIの講演では、GeminiやNotebookLM系の活用は、既存Office業務への追加とは異なる受け入れられ方をしたと説明された。

複数の資料を読み込み、要約する。資料同士を比較する。根拠箇所を確認する。論点を整理する。必要な形式の成果物へ変換する。この用途は、「この情報を入れれば、こう使える」という関係を示しやすい。

重要なのは、成果物だけでなく、その基礎となる情報源も共有できることである。

従来は、会議後に誰かが要約や報告書を作り、完成品を配布していた。受け取る側は、何を根拠に作られたのか、別の観点で分析できないかを確認しにくい。

情報源とAIの対話空間を共有すれば、同じ会議記録からでも、経営層向けの要約、営業担当向けのアクション、技術者向けの論点、リスク管理部門向けの懸念事項を、それぞれが作れる。

これは単なる要約の効率化ではない。

将来の用途を予測して成果物を作る働き方から、情報を整備し、必要な人が必要な時に成果物を生成する働き方への転換である。

この使い方では、ソースの版管理、情報分類、共有範囲、引用確認、回答不能時の扱い、再現性が重要になる。共有が便利になるほど、どの資料を誰と共有し、いつ更新・廃止するかを管理しなければならない。

製品の優劣ではなく、導入文脈の違いを見る

Copilotには伴走支援が必要で、Geminiは新しい使い方を示すと広がりやすい。この結果だけで、どちらか一方が常に優れていると結論づけるべきではない。

既存業務が強く定着している領域では、AIは完成された仕事の習慣の中へ入る。利用者の期待値を調整し、仕事を分解し、人間とAIの役割を丁寧に定義する必要がある。

新しいAI環境を導入する場合は、情報の保存、共有、再利用という新しい仕事の仕方を具体例で見せ、現場が自分の用途を発見できるようにすることが有効である。

導入文脈 推進で重視すること
既存ツールへAIを追加 期待値調整、業務分解、役割分担、伴走支援
新しいAI環境を導入 成功体験、情報源の整備、共有モデル、用途発見
高リスク業務へ適用 データ、権限、根拠、人間承認、評価、監査

推進策は、製品名で一律に決めるのではなく、自社の利用習慣、データの置き場所、業務プロセス、導入目的に合わせて変える。

マルチAIは、失敗ではなく企業の現実である

企業は、AIを一つに統一したいと考えがちだ。教育、契約、セキュリティ審査、問い合わせ窓口を一本化できるからである。

しかし現実には、マルチAIは自然に生まれる。

  • Microsoft 365を使えばCopilotが入る
  • Google WorkspaceやGoogle CloudではGemini系が入る
  • 開発現場にはコーディングAIが必要になる
  • 各種SaaSに独自のAI機能が追加される
  • 機密・専門業務には自社管理下のAI基盤が必要になる

NRIも、Microsoft系とGoogle Cloud系の両方を含むAI共創モデルを展開している。Microsoft系AI共創モデルGoogle Cloudへの拡大は、AIの選択肢を複数持つことが、顧客業務や技術特性に合わせるための現実的な戦略であることを示す。

重要なのは、無制限に製品を増やすことではない。共通用途では主力ツールを絞り、専門用途には必要な選択肢を残すことだ。

統制原則は共通化し、実装は連邦型にする

複数AIを使うと、各製品で共通の問いが発生する。

  • どの情報を入力してよいか
  • どのデータを参照させてよいか
  • AIエージェントに何を実行させてよいか
  • どこに人間の承認を置くか
  • コストと品質をどう管理するか
  • 問題が起きたとき、どう止め、調べ、説明するか

これらを製品ごとに別の基準で判断すると、利用者は迷い、全社としての一貫性が失われる。統制原則は全社で共通化する必要がある。

一方で、MicrosoftやGoogleなど各基盤には、認証、アクセス制御、データ保護、監査、エージェント管理といったネイティブな管理機能がある。すべてを独自の巨大基盤へ置き換える必要はない。

ここで有効なのが、連邦型の統制である。

全社共通の原則
  ├─ リスク分類、データ分類、最小権限、承認、監査、品質基準
  ↓
各AI基盤のネイティブ統制
  ├─ Microsoft系のID・権限・監査
  ├─ Google系のID・権限・監査
  └─ 開発・業務SaaS・自社基盤の統制
  ↓
共通補完レイヤー
  ├─ 横断ログ分析、モデル・API接続制御、MCP管理、評価、リスク監視

中央が全てを直接制御するのではない。共通の原則の下で、各基盤の強みを生かし、不足する部分だけを共通レイヤーで補う。

人間向けの統制を、そのままエージェントへ適用しない

人間の従業員には、本人認証、職務権限、上長承認、教育、監査といった統制がある。しかし、AIエージェントは責任を負わず、高速かつ大量に処理し、外部文書の指示にも影響され、複数のツールをまたいで行動する。

システムプロンプトにルールを書くだけでは、十分に制御できない。エージェントには、実行環境で強制されるガードレールが必要になる。

統制対象 必要な設計
身元 エージェントごとのID、所有者、業務責任者
権限 最小権限、利用者代理、目的・時間・対象を限定した委任
実行 許可リスト、実行上限、高リスク操作の人間承認
データ 機密区分、持ち出し制御、根拠・出典の記録
監視 ツール呼び出し、異常、コスト、品質劣化の検知
復旧 キルスイッチ、ロールバック、インシデント対応

NRIの講演で紹介された「エンタープライズ・ハーネス」は、こうした組織の利用原則を、ID、権限、スキル、API、MCP、ワークフロー、承認、ログ、評価といった実行環境へ反映する考え方として理解できる。

規程に「顧客データの外部送信は禁止」と書くだけでは足りない。エージェントが外部APIへ送信しようとした時点で止める。「一定金額以上は承認が必要」と決めたなら、エージェントが自動実行せず承認を求める。このように、組織の判断をシステムの振る舞いへ変換することが必要になる。

ルールを固定せず、企業がAIから学ぶ仕組みを作る

AIの機能、リスク、利用方法は短期間で変わる。新モデル、エージェント機能、外部連携、攻撃手法、現場の想定外の使い方が次々に現れる。

したがって、AI統制は一度作ったガイドラインを配布して終わりではない。現場と統制部門を結び、学習し続ける運用体制が必要になる。

現場・製品の変化を捉える
  ↓
AI推進、セキュリティ、法務、知財、リスク管理が評価する
  ↓
許可・条件付き許可・検証環境限定・禁止を判断する
  ↓
ポリシー、教育、システム設定、監視へ反映する
  ↓
利用結果・事故・未回答から学び、再び更新する

講演で紹介されたAX推進体制は、こうしたバーチャルな横断組織として捉えられる。役割は、AI活用を一度決めることではない。企業がAIから学び、判断を継続的に更新する仕組みを作ることだ。

IT技術者がマルチAI時代に設計すべきこと

マルチAI環境では、IT技術者の役割は製品の導入担当にとどまらない。

  1. 業務とAIの対応表を作る:用途、利用者、データ、期待する成果、人間の判断を整理する。
  2. 共通のリスク分類を定義する:データ、権限、外部接続、自律性、事業影響で許可条件を決める。
  3. 製品ごとの管理機能を把握する:ID、データ保護、監査、ログ、エージェント管理を確認する。
  4. 横断で必要な制御を補う:MCP・API接続、横断ログ、評価、コスト、インシデント対応を設計する。
  5. 推進方法を導入文脈で変える:既存業務では伴走支援、新しい環境では情報源と成果モデルを示す。
  6. エージェントの実行を段階化する:読み取り専用から始め、テストデータ、許可リスト、人間承認、実行上限、キルスイッチへ進む。
  7. 利用率ではなく業務成果を測る:時間短縮だけでなく、手戻り、判断品質、顧客体験、再利用できる知識、業務KPIを確認する。

まとめ――企業が選ぶべきなのはAIではなく、AIとの働き方である

CopilotとGeminiのどちらを選ぶべきか。この問いに一つの答えはない。

既存のMicrosoft 365業務を強く持つ企業ではCopilotの強みが生きる。複数の資料を根拠付きで整理し、情報源から新しい成果物を作る業務ではGeminiやNotebookLM系の強みが生きる。開発、分析、機密業務では、さらに別のAIが必要になる。

重要なのは製品の優劣ではない。それぞれのAIを、どの業務へ、どの役割で、どのデータと権限の下に配置するかである。

現場では、利用者の期待を調整し、仕事を分解し、AIと人間の役割を決め、具体的な成果を示す。全社では、複数AIに共通するリスク・権限・監査・品質の原則を作り、各基盤の機能を生かしながら、学習し続ける統制を実装する。

企業が本当に選ぶべきなのは、CopilotかGeminiかではない。人と複数のAIが、どのように仕事を分担し、どのようなルールの下で協働するかという、新しい働き方そのものである。


作成日: 2026年7月24日

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?