業務システムへの組み込み作成2026-08-21 01:03約17分

AI機能を本番に出すのが怖い｜機能フラグと段階リリースの型

検証環境では、いい感じに動いていた。デモも通った。あとは本番に出すだけ——のはずなのに、当日になって手が止まる。

「これ、全員に出して大丈夫だろうか」

その迷いは、実力不足のサインではありません。AI機能は、バグがあるから怖いのではなく、正解が一本に決まっていないから怖いんです。テストが全部通っていても、明日おかしな返事を返さない保証は、誰にも出せません。ここで一拍置けているのは、むしろまっとうな感覚です。

とはいえ、怖いから出さない、を続けるわけにもいきません。上からは「AIを活用しろ」と言われている。

この記事では、出す判断そのものを軽くするやり方を整理します。「完璧になったら出す」ではなく、「いつでも戻せるから出せる」に切り替える段取りの話です。

結論：AI機能を本番へ出すときは、順番が3つです。①分ける——AI機能を既存の処理から切り離し、スイッチ1つで消せる形にする。そのとき、AIなしでも仕事が回る従来の道を必ず残す。②細く出す——全員ではなく、自分 → チーム → 一部の利用者、と誰に出すかを絞って進める。③すぐ戻す——出す前に「どうなったら戻すか」を数字で決め、戻す手順と、戻していい人を先に決めておく。

覚え方は 分ける → 細く出す → すぐ戻す。順番が大事で、①を飛ばすと、戻したくなった日に「戻す先がない」状態になります。

全部を今日やる必要はありません。①の「スイッチ1つで消せるか」を確かめるだけでも、リリース当日の重さはかなり変わります。

何が起きているのか——AI機能は「壊れたから」ではなく「ゆらいだから」戻すことになる

大きな箱から小さな箱を取り分ける場面、並んだ大勢のうち先頭のひとりにだけ配る場面、壁のレバーを倒して切る場面を並べた図 — AI機能は「分ける・細く出す・すぐ戻す」の順で出す。①を飛ばすと、戻したい日に戻す先がなくなる

普通の機能とAI機能で、いちばん違うのは「戻す理由」です。ここが分かると、準備すべきものがはっきりします。

1つ目は、落ちないのに、じわじわ外れること。普通の不具合ならエラーが出て、監視が鳴って、気づけます。AI機能は違います。エラーは1件も出ていないのに、返している内容が少しずつ外している。数字の上では正常なので、誰かが「これ、なんか違うんですけど」と言ってくれるまで分かりません。

2つ目は、自分が何も変えていなくても挙動が変わること。モデルの提供側は改良を続けていて、こちらのコードを1行も触っていない日に、返り方の傾向が変わることがあります。「直近のデプロイを戻せば元に戻る」という前提が、AI機能では成り立たない場面があるわけです（AIの回答が日によって変わる｜再現性のなさと付き合う型）。

3つ目は、コストが利用量に比例して伸びること。普通の機能なら、使われるほど嬉しい。AI機能は、使われるほどお金がかかります。想定の何倍か使われた月末に気づく、というのがいちばん痛い形です（AI APIの料金とレート制限を見積もる｜本番前の型）。

4つ目は、「一部の人にとってだけ外れる」ことがあること。全体の精度は悪くないのに、特定の部署の書き方、特定の商材、特定の言い回しでだけうまくいかない。全員に一度に出すと、この偏りが見えないまま広がります。

5つ目は、印象が先に固まってしまうこと。ここがいちばん厄介かもしれません。最初に触った人がおかしな出力を1回引くと、「AIは使えない」という結論だけが社内に残ります。あとから精度を上げても、その評判はなかなか動きません。技術の問題というより、出し方の問題です（「AIならできる」の期待値を現実に着地させる説明術）。

裏を返すと、AI機能はいつでも消せる形にしておけば、それだけで怖さの大半が落ちます。「完璧にしてから出す」を目指すと永遠に出せませんが、「おかしかったら30秒で消せる」なら、今日出せます。機能フラグ——コードを変えずに機能のオン・オフを切り替える仕組み——は、そのための道具です。難しい製品を入れなくても、設定値ひとつから始められます。

具体例——つい、やってしまいがちな出し方

責める話ではありません。どれも「早く形にしたい」から出てくる自然な動きです。心当たりのある行があれば、そこだけ見直せば十分です。

いきなり全ユーザーに出す：検証で問題がなかったので、そのまま全体へ。悪い出力を引いた人の数だけ、あとで説明が必要になります。
既存機能をAIで置き換えて、古い道を消す：いちばん危ないのがこれです。AI機能を止めた瞬間に、業務そのものが止まります。戻したくても戻す先がない。
フラグはあるが、デプロイし直さないと切り替わらない：ifで分けてはいるものの、値がビルドに埋まっている。慌てている最中にビルドを待つのは、思っているより長い時間です。
「様子を見ます」で出す：戻す条件を決めずに出すと、多少おかしくても「もう少し様子を」と続いてしまいます。判断は、渦中にいる人ほど鈍ります。
誰に出ているか分からない：フラグを足したことは覚えていても、いま誰にオンなのかを一覧できない。障害の切り分けで最初につまずくところです。
上限を決めずに出す：コストも、呼び出し回数も、天井がない。使われて嬉しいはずが、翌月に説明資料を作ることになります。
AIの出力を、いきなり本番データに書き込む：フラグを切っても、書かれたデータは戻りません。ここだけは「戻せる」の外側にあります（AI出力を業務データに書き戻す前のバリデーション設計｜守る順番）。
フラグが増えすぎて、本番の姿が分からない：これは半年後に効いてくる問題です。片づけの予定を決めずに足し続けると、組み合わせが誰にも読めなくなります。

影響——「戻せない」と、止めるか耐えるかの二択になる

段取りを飛ばして困るのは、作業量が増えるからではありません。選択肢がなくなるからです。

止めるか、耐えるか、しか残らない：戻す仕組みがないと、機能ごと落とすか、おかしいまま使い続けるかの二択になります。どちらを選んでも、現場に負担がいきます。
原因の切り分けに時間がかかる：AI機能を出したのと同じデプロイに、他の修正も混ざっている。「AIのせいか、別の変更か」を切り分けるところから始まると、復旧が遠のきます。AI機能だけを単独で消せると、この工程が丸ごと消えます。
社内の空気が先に決まる：一度「AIはダメだった」となると、次の提案が通りにくくなります。技術より先に、信頼が削れる形です。
クライアントへの説明が難しくなる：受託なら「どの期間、誰に、どの挙動が出ていたか」を聞かれます。段階的に出していれば答えられますが、一斉に出していると範囲を特定できません。
担当者が、次から出すのが怖くなる：一度ひやっとすると、リリースそのものが重くなります。これは個人の資質の話ではなく、戻せない状態に置かれたことの結果です。

少しだけ希望のある話をすると、ここは高度な設計力ではなく段取りで防げる領域です。専用のサービスを導入しなくても、設定値ひとつでオン・オフできる分岐を1か所作るだけで、最悪の形はかなり避けられます。今日から変えられる部分です。

明日からやること（分ける・細く出す・すぐ戻す）

上から順に、小さく始められます。今日は①だけで構いません。

1. 分ける——スイッチ1つで消せる形にする

飛ばされやすいのに、いちばん効く工程です。ここができていれば、②と③はあとから足せます。

AIを呼ぶ場所を1か所にまとめる。あちこちから直接呼んでいると、消すのが大仕事になります。窓口をひとつにしておくと、そこだけ切れば止まります（AIモデル・ベンダーの乗り換えに備える設計｜疎結合の作り方）。
オン・オフをコードの外に出す。設定ファイル、環境変数、DBの1行、管理画面の項目——形式は何でも構いません。条件はひとつ、再デプロイなしで切り替えられることです。
AIなしで回る道を必ず残す。従来の手入力、既存のルールベースの処理、空欄のまま人が埋める運用。置き換えではなく、上に乗せる形にしておくと、切ったときに業務が止まりません。
書き込みは、別のフラグにする。「AIに提案させる」と「その結果を保存する」は分けます。提案どまりなら、切れば何も残りません。まず提案だけで出すのが、いちばん安全な第一歩です。
AI機能は、単独でデプロイする。他の変更と混ぜないだけで、切り分けが劇的に楽になります。

「大きく作り込む前に、切れる形かどうかを先に確かめる」。この順番だけでも、あとがずいぶん違います（業務フローにAIを差し込む｜「小さく試す」試験導入の設計）。

2. 細く出す——誰に出すかを、段で区切る

一気に広げず、段を作ります。それぞれの段で「何を見るか」を1つだけ決めるのがコツです。

段の切り方の例：①自分だけ → ②チームの数人 → ③協力的な部署ひとつ → ④利用者の一部 → ⑤全体。飛ばしても構いませんが、①と②は省かないほうがいいです。文句を言いやすい相手に最初に見てもらうのが、いちばん学べます。
各段の「見るもの」を1つ決める。①は明らかな崩れがないか。②は業務で使えるか。③は自分たちが想定していなかった入力が来ないか。④は数字。全部を毎回見ようとすると疲れて続きません。
出す前に、測る場所を仕込んでおく。あとから足すのは大変です。呼び出し回数、失敗した回数、応答にかかった時間、そしてAIの提案がそのまま採用された割合／人が直した割合。この最後のひとつが、AI機能の効き目をいちばん正直に表します（AI機能の効果測定｜導入後に見るログと指標の設計）。
モデルとプロンプトも、切り替えの対象にする。フラグは「機能のオン・オフ」だけではありません。どのプロンプトの版を使うかを外から差し替えられると、丸ごと止めずに、中身だけ戻せます（本番プロンプトのバージョン管理｜変更で壊さない運用の始め方）。
上限を先に入れる。1日あたりの呼び出し回数、1人あたりの回数、月のコスト。天井にぶつかったら、エラーではなく従来の道に静かに落ちるようにしておくと、利用者は困りません（AI出力が不安定なときのフォールバック設計｜リトライの型）。
段を上げる前に、人の確認をどこに挟むか決める。広げるほど、目が届かなくなります。範囲が広い段ほど、確認の仕組みを厚くします（人の確認を挟むAIワークフロー｜HITLの組み方）。

なお、段を上げる判断は日付では決めないほうがいいです。「来週には全体へ」ではなく、「②で1週間、直しが入った割合が○割を下回ったら③へ」。条件で決めると、迷いが減ります。

3. すぐ戻す——戻す条件と手順を、出す前に書く

事故は起きうる前提で、起きたときに小さく収める準備をします。10分でできて、効果が長く続く工程です。

戻す条件を、数字で先に書く。たとえば「人が直した割合が○割を超えたら」「エラー率が○％を超えたら」「1日のコストが○円を超えたら」「同じ苦情が3件来たら」。渦中では判断できないので、落ち着いているうちに決めておくのが要点です。
戻す手順を1〜2行のメモにして、見える場所に置く。どこの何をどう変えれば切れるか。慌てている最中に調べ方を探すのが、いちばん時間を溶かします。
戻していい人を決めておく。「気づいた人が切っていい」と先に決めておくと、夜中に誰かの許可を待たずに済みます。切る判断のハードルは、低くしておくほうが安全です。
戻したあと何が残るかを確認する。AIが書き込んだデータ、送ってしまった通知、外部に渡ったもの。フラグで戻せるのは「これから」だけです。だからこそ、①で書き込みを分けておく意味があります。
戻すのは失敗ではない、とチームで先に言っておく。これは仕組みではなく、空気の話です。「切り戻したら負け」という空気があると、切るのが遅れます。切り戻しは、設計どおりに動いた証拠です。
フラグの店じまい日を決める。全体に出して落ち着いたら、フラグと古い道を片づける日を決めます。「安定したら」ではなく、カレンダーに日付を置くほうが実行されます。

戻す条件を洗い出すとき、AI自身に手伝ってもらうこともできます。答えを鵜呑みにせず、抜けを探すための叩き台として使うのがちょうどいい距離感です。

これから、既存システムにAI機能を追加して本番リリースしようとしています。段階的に出して、必要なら切り戻せるようにしたいので、手伝ってください。

①この機能をフラグで切ったとき、業務が止まってしまう箇所を挙げてください。
②切り戻しても元に戻らないもの（書き込み済みデータ、送信済みの通知、外部への連携など）を挙げてください。
③誰に、どの順番で出すかの段階案を、各段で確認すべきことを1つずつ添えて出してください。
④「こうなったら戻す」の条件案を、測れる形（割合・件数・金額・時間）で挙げてください。
⑤フラグをオンにする前に、仕込んでおくべき記録・計測を挙げてください。

なお、確実でない部分は「不明」と書いてください。埋めなくて構いません。

機能の内容：（　）　利用者：（　）　既存の業務フロー：（　）

②を必ず聞くのがコツです。「戻せないもの」が先に見えると、どこを分けるべきかが具体的になります。

AI機能の段階リリースチェックリスト（コピーして使えます）

上から順に見ていくためのリストです。全部に○が要るわけではありません。気になった行だけで十分です。

① 分ける（作り込む前）

AIを呼ぶ場所を1か所にまとめたか
再デプロイなしでオン・オフを切り替えられるか
AIなしでも業務が回る従来の道を残したか（置き換えていないか）
AIの出力を保存する処理を、別のフラグに分けたか
まず「提案どまり」で出せる形にできないか検討したか
AI機能を、他の変更と混ぜずに単独でデプロイできるか

② 細く出す（出すとき）

誰に出すかの段を決めたか（自分 → チーム → 一部 → 全体）
各段で「何を見るか」を1つ決めたか
呼び出し回数・失敗率・応答時間を記録する仕込みを入れたか
AIの提案が採用された割合／人が直した割合を測れるようにしたか
使うプロンプトやモデルを、外から差し替えられる形にしたか
1日・1人・月あたりの上限を入れたか
上限に達したとき、エラーではなく従来の道に落ちるようにしたか
段を上げる条件を、日付ではなく数字で決めたか

③ すぐ戻す（出す前に決めておく）

「こうなったら戻す」条件を、測れる形で書いたか
戻す手順を1〜2行にして、見える場所に置いたか
誰が戻していいかを決めたか（許可待ちにならないか）
戻しても元に戻らないもの（保存済みデータ・送信済み通知）を洗ったか
「切り戻しは失敗ではない」をチームで共有したか
いま誰にオンになっているかを、後から一覧できるか
フラグと古い道を片づける日を決めたか

この記事のまとめ

AI機能を本番に出す話は、「精度が十分かどうか」の話ではありません。おかしかったときに、どれだけ小さく収められるかという、段取りの話です。

やることは3つ。①分ける——AIを呼ぶ場所をまとめ、再デプロイなしで切れる形にする。AIなしで回る道は消さない。書き込みは別に分ける。②細く出す——自分 → チーム → 一部 → 全体と段を区切り、各段で見るものを1つ決める。上限と記録を先に仕込む。③すぐ戻す——戻す条件を数字で決め、手順と、戻していい人を先に決めておく。

この3つがあると、リリース当日にやることは「フラグを1つオンにする」だけになります。そこまで用意できていれば、もっと気楽に、もっと早く試せるようになります。