【11/14 AIニュース】Google高速「Gemini 4 Hydrogen」発表／JR九州の非IT部門がアプリ内製／所要時間半減の社内AI育成／Notion「データ非保持」の盲点

• 「Gemini 4 Carbon」をベースに速度と効率を高めた日常エージェント・開発向けの主力モデル。「Gemini 3.8 Flash」比で約2.5倍速くタスクを完了し、第三者評価（Artificial Analysis Intelligence Index）では標準設定で51ポイントと「Gemini 4 Argon」（50ポイント）を上回るスコアを記録。
• 思考レベルを「low / medium / high（初期設定）/ xhigh（新設）」の4段階から選択可能。最大100万トークン対応で、API料金は文字量によらず一律で100万トークンあたり入力1.5ドル・出力7.5ドル（12月1日以降のArgon/Carbon通常価格4ドル/20ドルの半額以下）。
• Geminiアプリ（無料版でも自動選択で利用可）、Google検索、Gemini for Business、スプレッドシート、開発環境「Google Antigravity」で一斉提供。Antigravityでは1セッション内でCarbonとHydrogenの切り替えに加え、PC電源オフでもクラウド上で作業を続ける「リモートエージェント」機能も順次展開。

11月11日に最上位の「Carbon」が一般公開されたばかりですが、わずか2日後に「Hydrogen（水素＝宇宙で最も軽く豊富な元素）」が登場したことで、Googleの狙いがはっきり見えました。それは「Carbonで鍛えた高い知能をベースにしつつ、日常の9割の作業を2.5倍速・半額以下のHydrogenでストレスなく回せるようにする」という戦略です。

特に注目すべきは、標準設定（high）の知能スコアで従来の主力機「Argon」を逆転していながら料金が安く、さらに推論の深さを4段階（low〜xhigh）で細かく絞れる点です（※一方でモデルカード上、画像を含む指示などで安全のために過剰拒否する割合が約5.6ポイント増えている癖も正直に開示されています）。

今日からの実践として一番おすすめなのは、開発やドキュメント作成の現場で「最初の全体設計と最後の穴探しはCarbon、途中の細かな画面修正やデータ整理は高速なHydrogen」と1つの作業セッション内で切り替える使い方です。

また、APIで社内ツールを作る際も、簡単な定型処理は思考レベル「low / medium」で待ち時間と費用を最小限に抑え、少し複雑な判断だけ「high / xhigh」に上げる設定にしておくと、12月以降に上位モデルの割引期間が終わった後もずっと低コストで運用し続けられます。

• 「IT部門の人手不足」と「外部ベンダー委託のコスト・期間」の壁を打破するため、「Google Workspace with Gemini」を導入し非IT部門による業務アプリ内製化を推進。
• 運輸部門では日本語で要件を伝えてコードの9割以上をAIに記述させ、Python（Streamlit）で「営業運転中の車両データ常時監視アプリ」と「夜勤・休日・個人スキルを考慮した勤務シフト自動生成アプリ」を外注時の数分の1となる2〜3カ月で完成。
• 専任エンジニア不在の営業部門でも、LPの複数サンプル作成、予約手続きへ直結する「区間・日時検索窓」の実装、観光列車のSEO対策（スコア約40点→約70点へ改善）を内製化し、手書き報告書も「Gemini Notebook」へ集約して技術継承に活用。

多くの伝統的な大企業や地方企業では、「プログラミングができる社員がいないから、業務システムもWebページの改善もすべて外注するしかない」と諦めがちです。しかし外注すると、現場ならではの細かいルール（夜勤や休日当番、個人のスキル差など）を仕様書で伝えるだけで何カ月もかかってしまいます。

JR九州の事例が素晴らしいのは、「現場の課題を一番深く知っている担当者自身が、自然言語でAIと対話しながら動く試作品を作り、検証と手直しを自分で回した」点にあります。さらにその結果として、情シス部門が細かな開発対応から解放され、本来のセキュリティ統制や基盤づくりに集中できるようになったという「全社の好循環」が最大のポイントです。

非エンジニアの部門でこれから業務ツールの内製化を始めるなら、JR九州も採用した「Python × Streamlit（データ可視化やシフト作成などの業務用Web画面を短いコードですぐ動かせる仕組み）」や、「予約・問い合わせ導線の改善サンプルをまずAIに3パターン出させるやり方」がとても再現しやすい王道ルートです。

いきなり完璧な基幹システムを作ろうとせず、まずは「毎月エクセルと手作業で何時間も悩んでいるシフト表や集計作業」を1つ選び、現場の担当者とAIで「動く見本」を1つ作ってみるところから始めてみてください。

• 公開データだけを学んだ汎用AIでは対応しにくい「社内独自の設計ルールやライブラリ」に合わせるため、Geminiに社内の開発プロセス全体から集めた1兆トークン規模のデータを学習させた専用モデル「GfG」を構築（汎用能力を落とさない「中間学習介入」と「データリプレイ」を併用）。
• 最大の工夫は、完成コードだけでなく「コードレビューでの指摘と修正前後の差分」「社内ドキュメントやQ&A」「ビルドエラーが解消されるまでの変更履歴」といった試行錯誤の過程を組み込んだ点。
• 社内エンジニア2万9,000人の実測テストで、汎用モデル比でタスク完了までのやり取り回数が23.1%減少、14日後も書き直されずに残る「コード生存率」が16.8%向上。広告部門の大規模改修では所要時間が推定50%削減（変更の80%をAIが作成）。

一般の中小・中堅企業がいきなりGoogleのように「1兆トークンの独自モデル学習」を行う必要はありません。しかし、この研究が証明した「AIを自社仕様に賢くするのに一番効くデータは、完成品ではなく『レビューでの赤入れ（修正前後の差分）』と『現場のQ&A』である」という事実は、業種や規模を問わずすべての仕事にそのまま当てはまります。

新入社員を育てるときも、完成した企画書を10部渡すより「最初はこう書いたけれど、上司からここを指摘されてこう直した」という赤入れ履歴を3つ見せた方が圧倒的に早く育つのと全く同じ原理です。

プロンプトやAI用の指示書（マニュアル）を整えるときは、綺麗なルール文だけを書くのではなく、普段の仕事でAIの出力を手直ししたときに「【NG例（修正前）】➔【指摘理由】➔【OK例（修正後）】」を3行セットで1つのメモ帳やルールファイルに貯めていく運用をぜひ取り入れてみてください。

記事執筆でも、営業メールでも、システム開発でも、この「社内の赤入れ事例集」が10〜20個貯まった瞬間から、AIが一発で出せる合格率が目に見えて跳ね上がります。

• 米Notion Labsが11月9日に公表していた「AI処理の委託先（米Fireworks.ai）への不正アクセスによるチャット記録漏えいの恐れ」について、法人向けプランでZDR（ゼロデータ保持）を利用するユーザーも影響を受けた可能性があると追加公表。
• 原因は二重の構造にあり、①Notion AIの利用状況を分析する「Insights」機能自体がそもそも法人ZDRの対象外でリクエストと回答を委託先へ送っていたこと、②さらにFireworks側と交わしていた「データ非保持」の契約にもかかわらず、利用していた接続先（エンドポイント）でデータが保持されていたことが判明。
• 現在NotionはFireworks.aiとの接続をすべて停止し、他のAI推論・データ処理の委託先事業者についてもデータ保持が最小限になっているか総点検を実施中。

現在、多くの企業がSaaS型のAIツールを導入する際、「法人向けEnterpriseプランでZDR（ゼロデータ保持・学習利用なし）だから大丈夫」と判断して全社展開を進めています。今回のNotionの誠実な情報開示は、Notion固有の問題にとどまらず、すべてのAI搭載SaaSに共通するサプライチェーン上の構造リスクを浮き彫りにしました。

具体的には、SaaS事業者が自社でAIモデルを動かしているのではなく裏側で外部の推論クラウドへ委託している場合、「① メイン機能以外の新機能（レポート・分析系）がZDRの例外になっていないか」「② 委託先の技術的な設定が契約通りに非保持になっているか」という2つの死角が生まれやすいという重要な教訓です。

Notionを法人利用している企業は、まず管理画面と公式ヘルプから自社のプラン・Insights機能の利用有無を確認しておきましょう。その上で、他のAI搭載ツールも含めて「管理画面で『利用状況の分析』『品質改善のためのログ送信』といったZDR例外になりやすいオプション機能がONになっていないか」を今日中に一度点検しておくことをおすすめします。

また現場ルールとしても、「法人プランだから顧客の実名リストや口座番号までそのまま貼っていい」と過信せず、「個人を特定できる情報は伏せ字・仮名にしてからAIに渡す」という基本マナーを徹底しておくだけで、万が一の外部障害時にも事業ダメージを最小限に食い止められます。