【Google Cloud Next 2026】AI 開発ツールを組織に根付かせる
- 4月27日
- 読了時間: 8分
著者：駒場 成美（金融NEXT企画部）
Google Cloud Next 2026 のブレイクアウトセッション "Developer AI : Tools, tactics, and team adoption" に参加してきました。基調講演やハンズオンが「何をできるか（What）」を語るものだとすれば、このセッションは最初から最後まで 「どうやって組織・チームに定着させるか（How）」 に的を絞った、実践的な内容でした。
登壇者が冒頭で「今日は技術の話はほとんどしません。話すのは、人のこと、感情のこと、プロセスのこと、そして組織の変化の作り方です」と宣言したとおり、AI 開発ツールの導入現場で多くの組織がぶつかる壁について、Google の社内事例も交えながら率直に語られました。
セッション概要
登壇者（執筆者撮影）
登壇者は2名でした。
Aja Hammerly（Google Cloud, Director, Builder Relations） — Google 社内外で AI 開発ツールの導入を数多く手がけてきたディレクター
Maja Bilic（Google Cloud, Senior Product Manager） — 毎日のように顧客と対話し、現場の声を製品に反映させるプロダクトマネージャ
セッションの構成は、導入プロセスを以下3つのフェーズに分け、それぞれで押さえるべき勘所を語るものでした。
ツールを見極める（Evaluation）
社内に広げる（Roll out）
本当に使われる状態を作る（Drive adoption）
Maja が早々に放った一言が印象的でした。
「いまは誰もまだ使いこなせていません。でもみんな、"他社はもう使いこなしているはず" と思い込んでいます。」
現場感のある率直さに満ちたセッションでした。
見極めのフェーズ — 何を選ぶか、誰を選ぶか
"自社が何に困っているか" から始める
Maja が繰り返し強調したのは、ツール選びの出発点を 「他社が使っているから」ではなく「自社の開発者がどこで困っているか」 に置くべき、という原則でした。
確認するべき観点は次のあたりです。
ツールの形: コマンドライン、IDE プラグイン、Web UI — 開発者がどこで作業したいかで決まる
モデル: ひとつに絞り込まない。Gemini・Claude などのファミリーと、Pro/Flash などのティアを 用途ごとに使い分ける前提 で評価する
役割分担: どこまでを AI に任せ、どこからを人間が判断するかを設計する
「Google の プロダクトマネージャ ですが 敢えて"Gemini を選べ"とは申しません。自社のニーズに合うモデル群を選んでください」という率直な発言は、会場の空気を和らげていました。
"AI チャンピオン" を選ぶ
会場の様子（執筆者撮影）
Maja が本セッションで最もこだわったのが、ツールより先に "人" を選ぶ という話です。社内の推進役 — セッション内では AI Champions と呼ばれていました — の選定条件は次のとおり。
経営・会社が 信頼している 人物
社内で 影響力 がある人物
AI という技術そのものに 前向き で、新しいものを触ること自体を楽しめる人
複数のツールを比較して「ここが良い、ここが物足りない」と率直に語れる人
否定的な人は、どれだけ影響力があっても選ばない
このチャンピオンが次のチャンピオンを育て、やがて社員全体へ広がる — "人のネットワーク" で規模の経済を作る 考え方です。
「"このツールを使え" と上から指示されて喜ぶ人はいません。でも "これ、すごいよ" と信頼する同僚が言うなら、触ってみたくなる」という Maja の指摘は単純ですが、組織に AI を根付かせるうえでの核心だと感じました。
PoC は "現場の仕事" で検証する
続いて登壇した Aja からは、PoC でよく起こる失敗パターンの共有がありました。
"Snake ゲームを AI に作らせました！" 系のデモはやめる
検証には 長年積み上げてきたレガシーコード（古い Java の業務ロジックなど）を使う
チャンピオンには 特別プロジェクトのエース部隊ではなく、日常的に現場のコードを書いているエンジニア を選ぶ
障害対応や緊急バグ を扱うエンジニアを必ず入れる — 緊急時に威力を発揮できれば、それ自体が最強の導入材料になる
既存の課題管理システム、ページングツール、何十年も前に誰かが作った社内独自のデータ構造 — こうした "現場の泥臭さ" と繋げられるかを見る
「特別チームだけで PoC を回しても、本番のコードベースでは通用しない」という指摘は、PoC が本番に進まない理由を鋭く突いていました。
広げて定着させるフェーズ — "使われ続ける状態"を作る
会場の様子（執筆者撮影）
チャンピオンには自由に語らせる
PoC が終わったら、次に大事なのは チャンピオンが忖度なしにフィードバックを出せる環境を作る ことです。
経営の "代弁者" ではなく、自分の言葉で話してよい立場にする
「良い／悪い」だけでなく、詳細な使用感 を残させる
導入の前後で 何がどう変わったか を記録し、比較できるようにする
KPI の設計を間違えない
Aja が「絶対に設定してはいけない指標」として挙げたのは次の2つです。
トークン消費量のランキング — コスト削減が叫ばれる時代に、トークンを多く使う人を讃えるのは本末転倒
"どれだけ速く書けたか" だけの計測 — 品質を犠牲にすれば数字は簡単に上がる
代わりに見るべき指標として、
バグが増えたか、減ったか
依存関係が不必要に増えていないか
開発者自身の満足度（Google 社内ではエンジニアの満足度サーベイを毎週実施しているとのこと）
「エンジニアの満足度は、他のあらゆる生産性指標にプラスに働く」という研究結果の紹介も印象に残りました。
リーダーは "試行錯誤の過程" を共有する
リーダーが最も避けるべきは 「AI ツールを押し付ける」姿勢 だ、と繰り返し強調されました。Maja はこう語りました。
「Google の AI 導入初期、多くのエンジニアが "AI ツールを無理やり飲み込まされた" と感じていました。私たちが、自分たちの試行錯誤の過程を共有しなかったからです」
何を試し、何がうまくいかず、どう判断したのか — その過程をリーダー自身がオープンに共有することで、チームは 「一緒に進んでいる」という感覚 を持てる。上から命令されて動くのではなく、道を共に歩んでいる感覚です。
"変化が速すぎる" 前提で設計する
ロードマップが「3日前のものでも古い」と言われるほど変化が速い領域でも、エンジニアリングとして成立させる方法はある、と Aja は語りました。
ツールは差し替えられる前提で設計する。生成 AI コーディングツールは、今の時点ではどれもほぼ同等に扱えるレベルに達している
プロセス・教育・運用目的を先に固めておけば、ツールは後から入れ替えできる
シャドー IT には注意 — PoC 段階では自由に触らせても構わないが、本展開では 譲れない条件（例：セキュリティ） を必ず守らせる
不確実性が高い状況でも、今すぐ取り組めることとして次が挙げられていました。
計画する力を磨く — AI の時代こそ、何をどの順で進めるかの設計が効く
すべてのタスクを まず AI に投げてみる 習慣を作る
ひとつのツールに頼らず、LLM・差分ビューア・デザインツールなど複数を併用 する
標準化を優先する
魔法ではなくエンジニアリングである ことを忘れない。
まとめ
会場の様子（執筆者撮影）
スピーカーが最後に提示した3つの要点は、そのまま金融機関の AI 導入にも当てはまる普遍的なメッセージだと感じました。
イノベーションと好奇心を後押しする — チームが安心して試せる信頼関係を先に築く
基盤への投資を惜しまない — ポリシー、プロセス、コンテキスト、ガバナンス
自社のチャンピオンを把握しておく — 規模の経済は、人のネットワークから生まれる
金融業界にとっての示唆を、本セッションの論点に即して整理すると以下の通りです。
「ツールの性能差よりも、導入プロセスと人選のほうがプロジェクトの成否を大きく左右する」という現実認識。 AI PoC が本番に進めない多くの理由は、ツールではなく、推進役の選定ミス・レガシー系との統合検証不足・経営層の透明性欠如 にあります
KPI 設計には要注意。トークン量や単純な処理速度を評価軸に据えると、業務品質・コンプライアンス遵守・リスク管理といった本来重視すべき観点が歪みます。障害対応時間・品質指標・開発者満足度など、業務の実体に即した指標に落とし込む必要があります
「ツールは差し替えられる前提で作る」という発想は、特定ベンダーへのロックインを避けたい金融機関にとって特に示唆的です。モデル・ツールを抽象化して差し替えられるアーキテクチャは、中長期の調達とリスク管理の両面で効果的です
「わからないことは、わからないと言っていい」 という Maja の姿勢は、規制と監査を意識せざるを得ない金融業界でも十分に取り入れる価値があります。不確実性を隠さずに可視化したうえで、それでも守るべき絶対条件（セキュリティ、監査証跡、データ主権など）を明確にしておくスタンスは、むしろ規制業種でこそ機能するはずです
基調講演やハンズオンでは扱われなかった "導入の現場論" として、本セッションは非常に濃密な時間でした。AI ツールの評価・導入をご検討中の企業の皆様におかれましては、ツール選定の議論に入る前に、まず「推進役となる人材」「レガシー統合の段取り」「本当に測るべき KPI」を固める ことが、成功への近道になると改めて感じました。
