なぜ大企業の生成AI導入は苦しいのか？#PERSOL CAREER Advent Calender2025

はじめに
3つの登場人物と、それぞれのニーズ
採用した手段
第1の壁：リスクの見直しと再定義
第2の壁：運用体制の確立
第3の壁：請求フローの整備
- （おまけ）トライアルの罠
次なる課題：MCP（Model Context Protocol）の統制
まとめ

はじめに

「なんで会社だと生成AIが使えないんですか？」

どうも、はじめまして。

ITマネジメント&インフラ統括部インフラ部クラウド基盤グループの戸田です。

私たちの仕事は、一言で言えば「プロダクトを開発する人たちが集中してものづくりできる環境を提供すること」です。普段はクラウド基盤や開発環境の整備を引き受けているのですが、昨今はこれに加えて「生成AI基盤」の整備という、なかなかにパンチのあるタスクと向き合っています。

さて、冒頭のセリフについて。現場から「最新の生成AIツール、使ってみたい！」とキラキラした目で要望されること、皆さんの職場でも増えていませんか？

気持ちは、痛いほど分かります。個人開発ならメアドひとつで登録して、1分後には「すごい！」と感動できる世界です。「なぜうちだとダメなのか？」「世の中に置いていかれる！」と焦る現場の気持ちも。正直「いや、なんなら管理者である私だって使いたいんだよ。」と思うこともあります。

しかし、セキュリティやコンプライアンスが何よりも重要視される環境では、話はそう単純ではありません。

会社のネットワークから、会社の資産を扱わせるとなると、クリアすべき基準は大きく異なります。そこには「個人の便利」と「組織の規律」という、深くて広いギャップが存在するからです。

今回は、私たちが管理する開発環境において、生成AIツール「Gemini CLI」を導入する際にぶつかった3つの壁を紹介します。

キラキラした技術話というよりは、泥臭い試行錯誤の記録に近いですが、同じように組織の壁と戦う社内IT部門やプラットフォーム担当者の背中を少しでも押せれば幸いです。

3つの登場人物と、それぞれのニーズ

新しい技術を導入する際、組織内には異なる視点を持つプレイヤーが存在します。今回の場合においても、3つの重要なステークホルダーが存在しました。

ユーザー部門（開発者/デザイナーなど）

視点:「早く最新の生成AIを使って、開発効率を上げたい」
アクション:変化の起点。自らコンプライアンス部門へ利用申請を行い、導入を推進するエンジン。

コンプライアンス部門

視点:「そのツールは社内規定に適合しているか？情報漏洩のリスクはないか？」
役割:組織のルールブックに照らし合わせ、導入の可否を判断するゲートキーパー。

プラットフォーム管理者（私）

視点:「開発環境内でGemini CLI の導入は可能か？導入した後、セキュアな状態で運用し続けられるか？ログは追えるか？持続可能な運用フローか？」
役割:ユーザー部門の要望とコンプライアンスの要件を、技術的なアーキテクチャと運用フローに落とし込むアーキテクト。

誤解してほしくないのは、これは決して敵対関係ではないということです。全員が「会社やプロダクトを良くしたい、守りたい」という想いは同じ。ただ、見ている景色と守備範囲が違うだけなんですよね。

私の役割は、この3者のニーズを技術と運用で噛み合わせることでした。

採用した手段

まず前提として、エンタープライズ環境でGemini CLIのような開発支援ツールを利用する場合、大きく分けて「Gemini Code Assist（定額ライセンス）」と「Vertex AI API（従量課金）」の2つの選択肢があります。

今回、私たちはVertex AI経由でPoCを行いましたが、みるみるうちにコストがかさんでいき、あっという間に想定していた予算を上回ってしまいました。PoC開始からわずか数日でGemini CLIを停止する事態に。。。
この経験から、「Vertex AI経由は、手軽で便利だけど財布の紐が緩みすぎる」と痛感しました。そこで私たちは、入力情報の学習防止といったセキュリティ要件は守りつつ、「毎月いくらかかるか」が確実に見える Gemini Code Assistへの一本化を決めました。

第1の壁：リスクの見直しと再定義

最初の壁は、導入前の「審査」でした。社内でも生成AIツールの承認事例はまだ少なく、コンプライアンス部門としても「未知のリスクをどう定義し、安全性をどう担保するか」について慎重にならざるを得ない状況でした。

このような状況下でコンプライアンス担当者と対話を重ね、導入におけるリスクと安全性の定義を以下のように整理しました。

リスクの再定義:「未知の外部SaaS」ではなく、「既に導入済みのサービスと利用形態の近いクライアントツール」という枠組みで捉え直す。
安全性の証明:セキュリティの要件は、既に承認済みの開発環境を拡張するツールと定義し、既存のセキュリティの枠組みに吸収する。

私はプラットフォーム管理者として、このロジックを裏付ける技術的なファクトを補足し、ユーザー部門の推進担当者をアシストする立場に徹しました。

第2の壁：運用体制の確立

コンプライアンス上の承認が降りても、運用が回らなければ意味がありません。特に課題となったのが「管理体制」と「利活用のサポート」でした。

Gemini Code Assistを利用する場合、監査ログの出力先はCLI側で指定したGoogle Cloudプロジェクトになります。しかし、今回の利用者はエンジニアだけでなくデザイナーや企画職も含まれます。全員に「各自でGoogle Cloudプロジェクトを作って管理してね」というのは、さすがに酷というものです。

そこで、管理者が「防波堤」となる以下の体制を整備しました。

管理プロジェクトの集約:Gemini CLI管理用のプロジェクトを一つ作成し、全ユーザーの監査ログをここに集約する構成としました。
申請フローの確立:Gemini CLI利用申請のフローを整備し、申請があったユーザーに対してGemini Code Assistのライセンス付与、およびGoogleグループを通じたIAMロールの付与を行う仕組みを作りました。
ガイドラインの整備:「どう設定すればいいの？」という問い合わせを減らすため、インストール手順や認証方法をまとめた社内ドキュメントを公開しました。

また、Gemini CLIの利活用ナレッジを共有するコミュニティチャンネルを開設し、利用者が自律的に改善が行えるような環境を整備しました。

第3の壁：請求フローの整備

最後に立ちはだかったのが、避けては通れない「お金」の話です。Google Cloudの運用において、コスト管理のベストプラクティスといえば「ラベル（タグ）による分類」ですが、残念ながらGemini Code Assistはこれに対応していません。請求書には「プロジェクトに紐づかない課金」として合算されて届いてしまいます。

これでは、どの部署がいくら使ったかが判別できません。そこで、管理者で泥臭く隙間を埋めることにしました。