こんにちは。ITコンサルティングと受託開発、それにプログラミングスクールをやっている会社の代表、沼田です。17人・フルリモートの小さな会社をやっています。
この一年、中堅企業から増えた相談があります。少し前は「AIで、こういうの作れますか？」でした。それが最近、こう変わってきたんです。「AIで、動くものは作れたんです。……でも、これ、この先どうしたらいいですか？」
作れた。でも、支えられない。今日は、この"作った後"の話を書きます。結論から言うと、2026年に本当に足りていないのは、AIを"作れる"会社ではなく、AIを"支え続けられる"会社のほうでした。
「作れる」ハードルは下がった。「支える」ハードルは、変わっていない
まず、この数年で何が起きたかを整理します。生成AIのおかげで、"動くもの"を作るハードルは、劇的に下がりました。ノーコードのツールもあるし、AIに指示すれば、それらしいアプリやスクリプトが出てくる。エンジニアでない人が、社内の困りごとを自分でツールにする、なんてことも普通になってきました。
これ自体は、すごくいいことです。現場の人がいちばん困りごとを知っているわけですから、その人が手を動かせるのは強い。
ところが、ここに落とし穴があります。"作る"ハードルは下がったのに、"支え続ける"ハードルは、まったく下がっていないんです。
作ったツールは、作った瞬間がゴールではありません。そこからが長い。仕様が変われば直さないといけないし、AIのモデルが更新されれば挙動が変わる。エラーが出れば原因を追わないといけないし、作った本人が異動や退職でいなくなれば、誰も中身を分からないブラックボックスが残ります。この"作った後"の作業量は、AIがあっても、ほとんど減っていない。
特に中堅企業でこれが深刻なのは、そもそも情シス（社内の情報システム担当）がいない、あるいは他の仕事と兼任の1人だけ、というケースが多いからです。作る人はいても、支える人がいない。だから「動くものは作れたけど、この先どうすれば」で止まってしまう。動いているうちはいいんですが、止まった瞬間に、誰も直せない。これがいちばん怖い。
AIの内製で問われる、3つの責任
「作った後」を支えるって、具体的に何をすることなのか。うちがお客さんと整理するとき、僕はいつも3つの責任に分けて話します。
ひとつめは、品質を判定する責任。AIが出した結果が、本当に正しいのか。業務に使っていいレベルなのか。これを誰かが判断しないといけません。AIは、それらしい間違いを、自信たっぷりに返してきます。「なんか動いてるからOK」で流していると、気づかないうちに、間違った出力が業務に混ざり込む。誰が、どの基準で、品質を判定するのか。ここを決めておかないと、静かに事故ります。
ふたつめは、運用を続ける責任。エラーが出たとき、モデルが変わって挙動がおかしくなったとき、誰が対応するのか。使う人が増えてコストが膨らんだとき、誰が見張るのか。動かし続けるには、地味だけど継続的な世話が必要です。作った人が「あとはよろしく」で去ってしまうと、この責任が宙に浮きます。
みっつめは、引き継ぐ責任。作った本人しか中身を分からない状態は、時限爆弾です。その人がいなくなったら終わり。だから、どう作ったか、なぜそうしたかを、他の人が引き継げる形で残しておく。ドキュメントでも、コードの整理でもいい。属人化を放置しないことが、内製を"資産"にするか"負債"にするかの分かれ目です。
大事なのは、この3つを、作り始める"前"に、社内のどこに置くかを決めておくことです。作ってから「で、誰が面倒見るの？」と探し始めると、たいてい押し付け合いになって、結局は誰も見ない。順番が逆なんです。支える体制を先に決めてから、作る。
17人ITコンサルは、"支える体制"ごと引き受ける
じゃあ、情シスもいない中堅は、どうすればいいのか。うちがやっているのは、「全部作る受託」でも「丸投げの内製」でもない、その真ん中です。
昔ながらの受託は、こちらが全部作って、納品して、終わり。これだと、お客さんの社内にノウハウが残りません。かといって、完全に内製で丸投げにすると、さっきの3つの責任が空白のまま、ブラックボックスだけが増えていく。どちらも、中堅にはハマりません。
そこでうちは、月額の伴走という形で入ります。作るところだけを請け負うのではなく、品質をどう判定するか、運用をどう回すか、社内の誰にどう引き継ぐか、その"支える体制"ごと一緒に設計する。そして、こちらが手を動かしながらも、意図的にお客さんの社内にノウハウを残していく。半年後、一年後に、少しずつ自分たちで回せるようにしていく。伴走の理想は、最後に「もう、うちだけで大丈夫です」と言ってもらうことです。
AIの受託市場は、いま大きく分かれ始めています。単発で作って納める受託、道具を売る受託、そして導入から運用まで並走する伴走型。うちが立っているのは、いちばん最後の"PoC〜運用伴走型"です。「作れる」がコモディティ化した時代に、受託の価値は、作る技術そのものではなく、"作った後も一緒に走り続けられること"に移ったと思っています。
前職のスタートアップITコンサルにいた頃、立派なシステムを納品したのに、半年後に見に行ったら誰も使っていなかった、という現場を何度も見ました。作ることが目的になって、支えることが誰の仕事でもなかったからです。だから独立して自分の会社を持ったとき、「作って終わりにしない」を受託のルールにしました。24歳で起業して、この3期目（27歳）まで、地味ですがこれを守っています。うち自身、17人でいくつものAIを日常的に回していますが、案件ごとにトークン消費まで記録して、"作った後"を追える運用にしている。小さいからこそ、そこまで見きれる。これは規模が小さいことの特権です。
こうやって"作った後"まで一緒に見る仕事を、うちは本気で面白いと思ってやっています。もし「作って終わり」にしない開発に興味があるエンジニアがいたら、K.Platinumのエンジニア募集要項ものぞいてみてください。同じ景色を見てくれる人を、いつでも探しています。
売るのは「作ること」でなく、「一緒に走り続けられる状態」
まとめます。2026年、生成AIで"動くもの"を作るハードルは下がりました。でも、"支え続ける"ハードルは、何も変わっていません。むしろ、誰でも作れるようになったぶん、支えきれないツールが社内に溜まりやすくなった。情シスのいない中堅ほど、この「作れたけど支えられない」に直面しています。
支えるとは、品質を判定し、運用を続け、引き継ぐこと。この3つの責任を、作り始める前に、社内のどこに置くかを決めておく。そして、全部作る受託でも、丸投げの内製でもなく、月額の伴走で"支える体制"ごと設計し、ノウハウを社内に残していく。うちが売っているのは、「AIを作ること」ではありません。「AIと一緒に、走り続けられる状態」のほうです。
もし今、「動くものは作れたけど、この先どうすれば」で止まっているAIが社内にあるなら、もう一度作り直す前に、"誰が支えるか"を決めるところから始めてみてください。中堅の内製は、外の伴走とセットにして、はじめてちゃんと回ります。
沼田海斗（ぬまた・かいと）
株式会社K.Platinum 代表。ITコンサルティング・受託開発・プログラミングスクールを手がける。「作って終わりにしない」開発を信条に、17人・フルリモートの組織を率いている。
K.Platinumでは一緒に働くエンジニアを募集しています。「実力で正当に評価される環境」に興味がある方は、ぜひ採用ページをご覧ください。