PoC と本番の線引きは、たいてい誰も引きません。
動くものができると、それを誰かに見せます。良い反応が返る。もう少し人を増やして使ってもらう。気づくと、何人かが日常的に使っている。でも、それが「本番」になった瞬間は、どこにもありません。
リリース判定をした覚えもないし、運用に乗せた覚えもない。PoC のつもりのものを、いつのまにか人が頼りにしている。
それでしばらく回ります。回ってしまうから、線を引く動機もない。
うお、これ本番じゃん、と気づくのは、たいてい何かが変わるときです。
線がないと、消えるときも静か
本番なら、止めるときに手続きがあります。誰に影響するか確認して、代替を用意して、告知して、止める。
でも、本番だと誰も思っていないものには、その手続きが発動しません。
作った人が異動する。チームの体制が変わる。部署ごと解散する。そのとき、誰も「あのツール、止めて大丈夫ですか」と聞かない。本番じゃないから。PoC の延長だと、全員が思っているから。
そして、静かに消えます。
困るのは、黙って使っていた人
ここが、自分が一番引っかかったところでした。
消えたとき、作った人は困りません。もう別のことをやっている。止めた組織も困りません。そんなものがあったことすら、把握していないこともある。
困るのは、それを日々の作業にこっそり組み込んでいた人です。
毎朝それで確認していた。資料を探すのに使っていた。下書きを作らせていた。声の大きい使い方ではない。誰にも申告していない。ただ、自分の手元が、それで少し軽くなっていた。
ある日、それが動かなくなる。問い合わせ先もない。代替もアナウンスされない。
え？ と思う。でも、誰に言えばいいのかも分からない。本番のツールではなかったから、困っていることを表明する窓口すらない。
地味に、でも確実に、その人の作業は元に戻ります。軽くなっていたぶんだけ、重くなる。
そして、もう一人困る人がいます。データを出した人です。
この手のものは、たいてい誰かの協力で立ち上がっています。BKM を言語化してくれたベテラン。ラベル付けに付き合ってくれた人。「業務改善になるなら」と、暗黙知を資料に起こしてくれた人。その協力には、これは本番で役に立つはず、という前提が乗っていました。
入り方は、たいてい軽いんです。「こんなのできたんですけど、ちょっとデータ見せてもらえませんか」。断る理由もない、小さなお願いから始まります。そこから、ラベルを付けてほしい、この判断の基準を言葉にしてほしい、と少しずつ広がる。気づくと、一番手を動かしているのは、最初に軽く頼まれたドメイン側の人です。フットインザドアで入って、結局いちばん働いたのが提供者だった、という形になります。
それが、線を引かれないまま静かに消える。残るのは、あれは何だったんだ、という感覚です。散々協力したのに、何に使われ、なぜ消えたのかも知らされない。
これは、使っていた人が困るのとは質が違います。使っていた人は、これから手が重くなる。データを出した人は、過去の自分の協力が、後から宙に浮く。
協力には、信用が乗っています。これは本番にする、と作り手が口で言わなくても、提供する側はそう受け取って手を動かす。線を引かないまま消すというのは、その前借りした信用を、黙って踏み倒すことに近い。
これは、設計の失敗ではない
面白いのは、これは技術的な失敗ではないことです。
コードは動いていた。精度も足りていた。使われてもいた。直せなくて死んだわけでも、使い所が分からず消えたわけでもない。
死んだ理由は、PoC と本番の境界を、誰も引かなかったこと。それだけです。
境界がないものは、本番として扱われない。本番として扱われないものは、止めるときも本番の手続きを踏まない。だから、依存していた人と、協力した人だけが、予告なく取り残される。
決めていなかった場所だけが、後から問題になる。これは、その一番静かな形です。
では、どこで線を引くか
難しいのは、「いつから本番か」を作った人が宣言しても、あまり意味がないことです。本番かどうかを決めるのは、作り手の宣言ではなく、誰かがそれに依存し始めた事実の方だからです。
だとすると、引くべき線はこうなります。
このシステムに、申告していないかたちで依存している人がいるか。いるなら、それはもう本番です。止めるときには、その人に届く手続きが要る。
誰のための agent / RAG なのか。それが決まっていれば、止めるときに誰へ届ければいいかも決まる。決まっていなければ、止まったことに誰も気づかないまま、依存していた人と、データを出した人だけが困る。
そして、線を引くというのは、使う前の約束でもあります。誰かにデータを出してもらう時点で、これを本番にする責任を、こちらは前借りしている。引くべき線は、止めるときだけでなく、協力してもらうその瞬間にもある。
結局これも、責務の話に戻ります。動くかどうかでも、設計が正しいかどうかでもなく、誰がそれに依存し、誰がそれに協力したか。そして止まったとき、誰がその人たちに責任を持つのか。その一点を、PoC のうちに決めておくか、本番になってから事故で気づくか。
その差だけです。
これは、一回では終わらない
もう一つ、これを個人の話で終わらせられない理由があります。このパターンは、一回ごとに信用を削っていくからです。
そもそも、ドメイン側の協力を十分に得られず、壁を越えられないまま静かにフェードアウトした PoC も、同じ跡を残します。壁の手前までは、それでも誰かに一度は「データを見せて」と頼んでいる。そして、その多くも、本番にならずに消えていく。
これが、機械学習や深層学習が流行った頃から、各社で何度も繰り返されてきました。データを少し出してくれ、ラベル付けを手伝ってくれ、ナレッジを言語化してくれ。その多くが、線を引かれないまま PoC で終わった。提供した人は、そのたびに「あれは何だったんだ」を一つずつ積みます。
一回ごとは、ただの地味な失望です。でも、回数を重ねると「またか」になり、最後は「どうせ消えるんでしょ」になる。ドメインの壁は、技術だけで高いのではなく、こうやって年々高くなっています。
残酷なのは、この枯渇が次のプロジェクトに課税されることです。今、真面目に「本番にするつもりでデータをください」と頼んでも、相手はもう、何度も同じお願いが PoC で消えるのを見てきている。作り手個人の誠実さとは関係なく、業界が前借りした信用を踏み倒し続けたツケを、後発の真面目な人が払う。
LLM や RAG のブームで、また同じ「データください」が大量に発生しています。線を引かないまま進むと、そのうちの多くがまた静かに消えて、次に「データを見せてくれ」と言う人のハードルを、もう一段高くします。
線を引くというのは、だから自分のプロジェクトを守る話だけではない。次にデータを頼む誰かのために、信用をこれ以上削らない話でもあります。
では、PoC で終わらせないために
ここまでの話は、結局すべて「PoC のうちに、誰のどんな責務を引き受けるのかを決めておく」一点に戻ってきます。誰が依存し、誰が協力し、止まったとき誰が責任を持つのか。それは、本番で事故ってから考えることではなく、動くものができた時点で言葉にしておけることです。
この話で出てきた「誰のためか」「誰が止まったことに気づくか」「誰が責任を持つか」を、自分の設計に当てて一問ずつ確認できる形にしたものがあります。
点数も合否も出しません。一行で答えられるかだけを見ます。答えに詰まった問いが、そのシステムが本番化で死ぬ場所です。
→ 運用の現場から見た、本番で動かないRAG / AI Agentの設計チェックリスト