「AI制御は怖い」を過去にする。製造現場のログだけで安全に賢くなる「保守的Q学習（CQL）」の実装と検証

シリコンバレーのスタートアップから日本の大手製造業の現場まで、AIプロジェクトにおいて共通する課題があります。

「AIで自動化したい。でも、学習のためにラインを止めるわけにはいかないし、ましてやAIが暴走して設備を壊すなんて論外だ」

皆さんも、似たようなジレンマを抱えていませんか？

強化学習（Reinforcement Learning）は、囲碁や将棋で人間を超えたように、産業用ロボットやプラント制御でも最適解を導き出すポテンシャルを持っています。しかし、その学習プロセスには「試行錯誤」が不可欠です。失敗から学ぶ。これこそが強化学習の本質ですが、数億円の設備や人命がかかる現場で「あ、失敗しちゃった」は許されません。

そこで今、AI研究者と実務家が熱い視線を注いでいるのが「オフライン強化学習（Offline RL）」、特に「保守的Q学習（Conservative Q-Learning: CQL）」という技術です。

これは、「現場で失敗しながら学ぶ」のではなく、「過去の熟練工の操作ログ（データ）だけを見て、安全な範囲で賢くなる」アプローチです。AIに冒険をさせず、しかし人間以上の精度を目指す。

今回は、この「CQL」が本当に現場で使える代物なのか、理論だけでなく実装ツールとしての使い勝手や、標準的な手法との比較検証を通じて、その実力をジャッジしていきましょう。まずは動くものを作り、仮説を即座に形にして検証する。それが技術の本質を見抜き、ビジネスへの最短距離を描くアプローチです。

「現場で学習させる」リスクと、オフライン強化学習への期待

まず、なぜ実務の現場でこれほどまでに「オフライン」にこだわる必要があるのか、リスク管理の観点から整理しておきましょう。

なぜ従来の強化学習は産業現場で使えないのか

従来の強化学習（オンライン強化学習）は、エージェント（AI）が環境（機械など）と相互作用しながらデータを集めます。これは、生まれたての子供が熱いヤカンに触れて「熱い！」と学ぶプロセスと同じです。

しかし、産業現場でこれをやるとどうなるでしょうか。

• 物理的損壊リスク: ロボットアームがあり得ない角度に曲がろうとしてモーターが焼き切れる。
• 生産ロスの発生: 最適化のためにあえて「悪い設定」を試す必要があり、その間の歩留まりが低下する。
• 安全性の欠如: 化学プラントで温度制御をAIに任せた結果、危険な温度域まで上昇させてしまう。

「それならシミュレータを使えばいい」という声も聞こえてきそうです。確かに、デジタルツインやシミュレータ上で学習させるアプローチは有効です。しかし、高精度なシミュレータの構築には莫大なコストがかかりますし、どれだけ精巧に作っても現実世界との微妙なズレ（摩擦係数の変化や経年劣化など）が生じます。これを「Sim2Real問題」と呼びますが、シミュレータで完璧に動いたAIが、実機に乗せた瞬間に使い物にならないケースも考えられます。

「死の谷」を超えるためのオフライン強化学習

ここで登場するのが「オフライン強化学習」です。これは、AIが環境と一切インタラクションせず、手元にある「過去のデータセット（ログ）」のみを使って学習する方法です。

製造業やインフラ産業には、実は宝の山があります。それは、熟練オペレーターが長年積み重ねてきた操作ログや、DCS（分散制御システム）に記録されたセンサーデータです。これまでは単なる記録としてHDDの肥やしになっていたこれらのデータを、「AIの教材」として再利用するのです。

• 実機リスクゼロ: すでにあるデータで学習するため、ラインを止める必要も、壊すリスクもありません。
• 低コスト: 新たなシミュレータ開発やデータ収集実験が不要です。
• 熟練の技を継承: ベテランの操作ログから、その「勘とコツ」を数理的に抽出できます。

まさに、DX推進担当者が待ち望んでいた「安全第一」のAI開発手法と言えるでしょう。しかし、単に過去データで学習させるだけでは、AIは思わぬ落とし穴にハマります。そこで必要になるのが、今回の主役である「CQL」です。

保守的Q学習（CQL）は何を解決するツールなのか

オフライン強化学習には、「分布シフト（Distribution Shift）」という厄介な問題があります。これを解決するために考案されたのがCQLです。

AIの「知ったかぶり」を防ぐ数学的アプローチ

少し想像してみてください。あなたが一度も行ったことのない森の地図を渡され、「最短ルートを探せ」と言われたとします。地図には、過去に誰かが通った道（データ）だけが記されています。

普通のAI（標準的なQ学習）は、地図にない空白地帯に対して「ここを通れば近道かもしれない！」と楽観的な予測をしてしまいがちです。これを「Q値の過大評価」と呼びます。データがない場所ほど、AIは「もしかしたらすごい報酬が得られるかも」と妄想（幻覚）を抱きやすいのです。

しかし、現実の森（現場）で地図にない道を進めば、崖から落ちるかもしれません。製造装置で言えば、過去に誰も試したことのないパラメータ設定を行い、システムをダウンさせることに相当します。

CQLは、この「知ったかぶり」を許しません。その名の通り、Conservative（保守的）に振る舞います。

分布外行動（OOD）に対するペナルティの仕組み

CQLのアルゴリズムを直感的に説明すると、「データセットに存在しない行動をとろうとしたら、罰則（ペナルティ）を与える」という仕組みを持っています。

具体的には、AIが学習する際、以下のような調整を行います。

1. データにある行動: 実際に観測されたデータに近い行動であれば、その評価（Q値）をそのまま、あるいは少し高めに見積もる。
2. データにない行動: データセットに含まれていない、未知の行動（Out-of-Distribution: OOD）に対しては、その評価（Q値）を強制的に低く見積もる。

これにより、AIは「知らないことはしない」「確実なデータがある範囲内で、最も良い行動を選ぶ」ようになります。ビジネスにおいて、一発逆転の大ホームランよりも、確実に三振しないことが求められる場面は多いはずです。CQLは、まさにそのような「堅実なAI」を作るための安全装置なのです。

実装ツール（d3rlpy等）のユーザビリティと機能評価

理論が素晴らしくても、実装が難しければ現場には導入できません。ここでは、CQLを実装するための代表的なライブラリとして、日本発のOSSである「d3rlpy」を取り上げ、そのユーザビリティを評価します。プロトタイプ思考の観点からも、いかに素早く仮説検証サイクルを回せるかが鍵となります。

Pythonライブラリとしての成熟度と導入ハードル

d3rlpyは、「エンジニアフレンドリーな設計」であると考えられます。AI研究者向けのライブラリの多くは、複雑な設定や深い理論理解を要求しますが、d3rlpyはデータサイエンティストにとって馴染み深い「scikit-learn」のようなインターフェースを採用しています。

例えば、CQLの学習コードはシンプルに記述できます。

import d3rlpy

# データセットの準備（MDPDataset形式）
dataset = d3rlpy.dataset.MDPDataset(
    observations=observations, # センサー値など
    actions=actions,           # 操作量など
    rewards=rewards,           # 成果（品質や生産量など）
    terminals=terminals        # 終了フラグ
)

# CQLアルゴリズムの定義
cql = d3rlpy.algos.CQL()

# 学習開始
cql.fit(dataset, n_steps=10000)

これだけで、最先端のオフライン強化学習が走り出します。裏側にある複雑な数式やニューラルネットワークの構築は、ライブラリが抽象化してくれています。GitHub Copilotなどのツールと組み合わせれば、さらに高速なプロトタイピングが可能です。

データセット形式と前処理の要件

現場導入で一番苦労するのはデータの準備ですが、d3rlpyはここも柔軟です。基本的には以下の4つの配列があれば学習可能です。

1. Observations (観測): 温度、圧力、振動などのセンサーデータ。
2. Actions (行動): バルブ開度、モーター回転数などの操作ログ。
3. Rewards (報酬): その操作の結果どうなったか（良品なら+1、不良なら-1、電力消費削減ならプラスなど）。
4. Terminals (終了): エピソードの終わり（1日の操業終了など）。

CSV形式で保存されている時系列データがあれば、簡単なPandas操作でこの形式に変換できます。画像データにも対応していますが、製造現場の数値ログであれば、軽量かつ高速に学習が進みます。

学習状況の可視化機能

「AIが何を学んでいるか分からない」というブラックボックス化を防ぐため、d3rlpyには学習曲線やQ値の推移を可視化する機能も充実しています。特に、CQL特有の「保守性」が効いているかどうかを確認するためのメトリクスも用意されており、エンジニアは「ちゃんと未知の行動を抑制できているか」をグラフで監視しながらチューニングできます。

【検証】標準的なQ学習 vs CQL：挙動の安定性を比較

では、実際にCQLはどれほど「安全」なのでしょうか。一般的な検証プロジェクト（化学プラントのバルブ制御を模したシミュレーション環境）の結果を例に、標準的なDQN（Deep Q-Network）とCQLの挙動を比較してみましょう。

この検証では、あえて「不完全なデータセット」を使用しました。特定の温度範囲（例：50℃〜80℃）のデータしか含まれていないログをAIに学習させ、テスト時に「100℃」という未知の状況に遭遇した際の反応を見ました。

標準DQNが陥る「幻覚」による誤作動

標準的なDQNで学習させたエージェントは、100℃という未知の状況に直面した際、極端な挙動を示すことがありました。

• 挙動: バルブを全開（100%）にする。
• AIの思考（推定Q値）: 「この状況は見たことないけど、全開にすれば凄まじい報酬が得られる気がする！」（過大評価）

結果、タンク内の圧力は急上昇し、シミュレーション上では安全弁が作動して緊急停止しました。これが「幻覚」です。データがない領域で、AIは根拠のない自信を持って危険な行動を選択してしまったのです。

CQLが示す「分からなければ動かない」という挙動

一方、同じデータセットで学習させたCQLエージェントの反応は対照的でした。

• 挙動: バルブを現状維持、または安全側にゆっくり閉じる。
• AIの思考（推定Q値）: 「100℃のデータはない。だから、ここで派手な操作をするとペナルティを受ける可能性が高い。Q値を低く見積もって、過去のデータに近い、リスクの低い行動を選ぼう。」

CQLは、未知の状況に対して「自信がない」ことを認め、保守的な判断を下しました。結果として、システムは暴走せず、制御可能な範囲に留まりました。

定量的なスコア比較と定性的な挙動分析

スコア（報酬の総和）で見ても、DQNは学習データに含まれる状況下では高スコアを出すものの、少しでも条件が変わるとスコアが急落（マイナス）しました。対してCQLは、最高スコアこそDQNと変わらないものの、未知の状況下でも大崩れせず、安定したスコアを維持しました。

ビジネス現場において、「平均90点だが、たまに-1000点を出すAI」と、「常に80〜90点を出し続けるAI」のどちらが採用されるかは明白です。経営者視点で見ても、CQLは後者を実現するための極めて実用的な技術なのです。

現場導入における「良い点」と「課題点」

CQLは魔法の杖ではありません。実務家の視点で、公平にメリットとデメリットを整理します。

メリット：過去資産の即時バリュー化と安全性

最大のメリットは、やはり「今あるデータですぐに始められる」点です。高価なセンサーを追加したり、リスクを冒して実験したりする必要がありません。数年分の操業ログがあれば、それがそのままAIモデルという資産に変わります。

また、前述の通り「暴走しにくい」という特性は、経営層や現場責任者を説得する際の強力な材料になります。「AIは怖い」という心理的ハードルを、技術的な根拠（Proof）を持って下げることができます。

デメリット：過度な保守性とデータの質への依存

一方で、課題もあります。

1. 過度な保守性: CQLは「データにないこと」を嫌うため、データセットに正解が含まれていない場合、それ以上の改善（探索）を行うことが苦手です。「人間を超える新しい戦術を見つける」というよりは、「熟練工のベストプラクティスを忠実に再現し、ミスを減らす」という使い方が適しています。
2. データの質（カバレッジ）: 学習データが極端に偏っていると、AIが対応できる範囲も狭まります。「ゴミを入れればゴミが出てくる（Garbage In, Garbage Out）」の原則は変わりません。ある程度、多様な状況を含んだログデータが必要です。

計算リソースと学習時間

計算コストに関しては、オンライン強化学習に比べれば軽微ですが、それでも深層学習を用いるためGPU環境は推奨されます。ただし、LLM（大規模言語モデル）のような巨大なリソースは不要で、一般的なワークステーションレベルで十分実用的な時間内に学習が完了します。

結論：CQLは「守りのDX」における最適解になり得るか

製造業やインフラ産業におけるAI活用は、これまでの「攻めのDX（新規事業創出）」から、足元の効率化や安全性向上を目指す「守りのDX」へとフェーズが移りつつあると考えられます。その文脈において、保守的Q学習（CQL）は現実的かつ強力な選択肢です。

推奨される組織とユースケース

特に以下のような状況において、CQLの導入が推奨されます。

• 熟練工の退職が迫っている: 彼らの操作ログをAIに学習させ、技術伝承を行いたい。
• 24時間365日稼働の設備: 学習のためにラインを止めることが許されない。
• 過去のトラブルデータが豊富: 異常時の対応ログがあれば、AIは「どうすれば事故を防げるか」を安全に学習できる。

まずはPoCで検証すべきステップ

いきなり本番環境に投入する必要はありません。まずは、手元のCSVログデータをd3rlpyに読み込ませ、以下のステップでPoC（概念実証）を行ってみてください。

1. データ整備: 過去ログを「観測・行動・報酬」の形式に整理する。
2. オフライン学習: CQLでモデルを構築する。
3. オフライン評価（OPE）: 過去の別のデータセットを使って、「もしAIが操作していたらどうなっていたか」をシミュレーション評価する。

このプロセスなら、追加コストはほぼゼロ、リスクもゼロで、「AIがどれくらい賢くなれるか」を確認できます。まずは動くプロトタイプを作り、その実力を体感することが重要です。

「AI制御は怖い」という常識は、技術の進化によって過去のものになりつつあります。現場に眠るデータを目覚めさせ、安全で賢い自律制御への第一歩を踏み出してみませんか？