一番の懸念は、機密データの保護だ。Microsoft 365は、データラベル（秘密度ラベル）でファイル自体を暗号化し、共有の制限やロックダウンができる。一方のGoogle Workspaceは、組織単位や共有ドライブ単位でのDLPルール適用が主で、同粒度の制御をシステムだけで再現すれば利便性を損なう。

　同社はその解決のために、システム側だけで全てを解決するのを諦めるという判断を下した。機密データのラベル運用は強制ロックに頼らず、ルールを周知する教育と、不適切な共有がないかをガバナンス部門が継続監視する仕組みをセットにする。この組み合わせによって、実質的にMicrosoft 365と同等の安全性を確保する設計とした。

　この運用によって、ソニーグループの厳格な基準を満たすことを可能とした。重要なのは管理機能の一致ではなく、情報が実質的に守られている状態をどう作り出すかだ。

　吉田氏は、「Microsoftは指針ではありますが、絶対ではありません。管理機能を単純に置き換えるという考え方はやめて、付帯サービスも勘案しながら、広くセキュリティを確保できるように考えるべきです」と語った。

　この設計を半年で実現できた要因は組織構造にもある。ITやセキュリティ、ガバナンスの各部署を同一オーナーの下で同じプロジェクトに配置したことで、部門間の利害衝突を抑え、早期提供という共通目標に集中できたという。

選択肢の引き算でユーザーのストレス軽減

　2つの環境を維持する上で同社が徹底したのは、足し算ではなく引き算だった。機能が重複する個別ツールを棚卸しして削減し、選択肢を物理的に少なくした上で、IT部門から推奨ツールを示す。その上で、使い分けによるストレスをユーザーに与えないよう、メールとカレンダーの情報が両環境で参照できる設計にした。

　同社は、社外とのメールの送受信に従来のMicrosoft 365環境を利用している。一方、Geminiに過去のメールの内容を踏まえた支援をさせるには、Google Workspace側にもメールデータを連携する必要があった。

　会議招待や予定変更の通知はメールで届き、その情報がカレンダーに反映される。そのため、対外メールをMicrosoft側で受ける同社では、カレンダーを一方の環境へ単純に統一できなかった。そこで、会議招待や予定変更に関するメールに絞って転送をかけ、どちらの環境でも予定を把握できるようにした。

　共有単位となるグループについても、ソニー全体で使うMicrosoftのセキュリティグループを定期的にミラーリングするスクリプトを用意した。この地道な同期が、現場の混乱を防いでいるという。

共存環境の全体像（出典：セッション投影資料）

　教育では、解説動画やマニュアル配布で終わらせなかった。立ち上げ期には役員からメンバーまで全層に3時間の双方向ハンズオンを実施した。部署ごとに内容をカスタマイズし、実際の業務ファイルでGeminiを体験してもらった。

　吉田氏はハンズオンの利点を、「自分のこの業務はAIでできるのか」といった質問にその場でプロンプトをたたいて実演し、即時回答できることだと説明する。この即時フィードバックが利用モチベーションに直結し、ハンズオン後の利用率は上がり続けているという。

残り25％を動かす、3段階のエコシステム設計

　こうした活動によりGemini利用率は約75％（講演時点で約80％）まで上昇した。しかし吉田氏が目を向けたのは、残り25％を占める未利用層だ。分析したところ、その原因は2つあった。

　1つ目は、手作業やRPAで業務が確立しており、AI導入の必要性が乏しい業務だ。すでに最適化された定型業務では、自由なプロンプト入力を求めても機能しにくい。確実性が求められる業務では、AI出力のランダム性がリスクになる。

　そこで同社はこの層に能動的なチャット利用を求めることを諦め、チャットUIはアイデア出しなど非連続的な思考を支える企画業務に向く、と割り切った。その代わりに取った手段が、Geminiの「Gem」機能や「Gemini Notebook」の利用を推奨するアプローチだ。

　社内規定や業務マニュアルを知識としてアップロードすれば、ハルシネーションを抑えた小規模なRAG環境を作れる。それをGoogleドライブの権限で部署内に共有すれば、プロンプトを考えずに情報を引き出せる。

　2つ目の理由は、社外やグループ会社との連携上、アウトプットをGoogle Workspace外に出す必要があることだ。財務や決算、営業資料といった最終成果物は、「Microsoft Excel」や「Microsoft Word」「Microsoft PowerPoint」での作成が求められるためだ。

　ここでも同社は完全移行の強制をしなかった。入り口はGeminiやGemini Notebookを使い、出口は使い慣れたMicrosoft環境へコピーする。このハイブリッド運用を公式に推奨し、コピペ依存を認めた上で、システム間の摩擦はインフラ側で吸収した。

　吉田氏は、組織導入に向けた3ステップのプロセスを次のように整理する。

　ステップ1は「AI単体体験とMicrosoft容認」だ。移行や使い分けを求めず、アウトプットは使い慣れた「Microsoft Teams」やWordなどへコピーして構わないとし、利用ハードルを下げる。

　ステップ2は「つながる心地よさの体験」だ。Google Meetの議事録作成など単体でも使いやすい機能をフックに、エコシステムのつながりへ自然に気付いてもらう段階で、同社の主な利用層は現在ここに位置しているという。

　ステップ3は「Google Workspaceネイティブ」への移行だ。高度な自動化を求める現場が、ファイルをドライブに置く方が楽だと自ら気付く段階に位置する。

組織導入に向けた3段階プロセス（出典：セッション投影資料）

　ここまでの歩みを経て、同社はAI活用の評価指標そのものを問い直している。「チャットを使うだけで上がる利用率を追う意味はない」（吉田氏）からだ。次のゴールは、ユーザーが機能とAIの特性、リスクを理解し、自発的に業務プロセスに組み込めている状態だ。同社では現在、部署ごとのAI組み込み度を測る仕組みを検討している。

　ルールで現場を縛るのではなく、確かな指針と自由な余地、伴走の安心感を提供し続ける。この泥臭い設計こそが、複数環境が併存する組織でAIを定着させる現実的な道筋だ。