「3か月と言われた機能が、2日で動いたんですよ」。
こういう話を、この1年で何度聞いたか分かりません。私たち自身がそうです。受託開発の現場でClaude CodeやCodexを毎日走らせていて、設計の下書きも、実装も、テストコードも、データ移行のスクリプトも、人が書く作業から「エージェントが書いたものを人が確かめる」作業へ置き換わりました。
だったら、外に出す必要はないですよね。同じツールを自社のエンジニアが使えばいい。内製化のご相談が増えているのは、当たり前の流れだと思います。
ただ、相談を聞いていると、妙なことに気づくんです。詰まる場所が、どの会社でもほぼ同じなんですよね。
エージェントが書けなくて止まるのではありません。書けたものが業務に乗らない。作り直す。また乗らない。その回数が読めないまま、予算と期日だけが減っていきます。
失敗が起きる場所は、経験上4つです。どれも「作ってみるまで分からない」性質を持っていて、分かった瞬間に、作ったものの一部が捨てられます。
安くなったのは、実装工程だけ
工程を並べてみます。
何を作るか決める。設計する。実装する。検証する。セキュリティを確認する。運用して直し続ける。このうち、エージェントが直接短くしたのは実装と、テストコードの下書きだけなんですよね。私たちの受託でも、実装に充てる時間は目に見えて減りました。
その前後はどうでしょうか。ほとんど減っていません。業務のどこを変えれば効果が出るのかを決める作業、出てきたものが現場のルールに合っているかを確かめる作業。これらはコードを書く速度とは別の時計で動いています。
つまり、開発費のうち実装が占める割合が大きい案件ほど、内製化の効果は素直に出ます。逆に、要件が固まっていなくて業務側と何度も擦り合わせが要る案件だと、実装が何倍速くなっても全体の期間はほとんど動きません。短くなった工程が費用に占める割合。それが、内製化で取れる利益の上限です。
進め方が変わったのは事実です。以前は要件を文書で固めてから見積もりを出していました。いまは先に小さく動くものを作って見てもらい、それを見ながら要件を決める場面が増えています。文書に対する「はい、それで結構です」って、動くものを見た瞬間に平気で覆るんですよね。安く試せるなら、覆るのは早いほうがいい。
それと、見落とされがちな点が一つあります。実装が安くなったのは、内製に限った話ではないんですよね。私たちのような受託側も同じツールを使っています。だから見積もりに乗る実装の工数は、こちらでも下がっています。内製にしても外注にしても、実装が安くなるぶんは同じように効く。ここで差はつきません。差がつくのは、残りの工程のほうです。
ここまでは、たぶん多くの現場で共有されている実感だと思います。問題はその先でした。
プロンプトに書けない業務ルール
一つめは、言語化されていない業務ルールです。
「字幕を自動生成する」。要件はこの一行で書けます。ところが納品物の実態はどうでしょうか。局ごとに1行あたりの文字数が違います。改行位置の決め方、句読点の扱い、話者が変わるときの記号、画面上のテロップを避ける位置調整。全部決まっています。しかもその多くは規格書に載っていません。現場の運用として、人の中に溜まっているだけなんですよね。
こういう知識を学習しているモデルは、ありません。ARIBの字幕構造も、その局だけのテロップ規則も、外の世界にほとんど書かれていないからです。そしてエージェントは、渡されなかった制約を「存在しない制約」として扱います。もっともらしく動くものが出てくる。現場に見せる。「これ、違います」。
厄介なのは、事前に聞いても出てこないことです。長年やっている人にとって、それは判断ではなく反射なんですよね。だから言葉にならない。言葉になるのは、間違ったものを見せられた瞬間だけです。
ここで行き詰まると、もっと新しいモデルを試す現場をよく見ます。気持ちは分かります。ただ、この部分は性能では埋まりません。埋まるのは、担当者の頭の中にある規則を文書に出して、エージェントが毎回参照できる場所へ置いたときです。局ごとの改行規則、禁則、過去に指摘された事項。私たちが放送局向けの機能を作るときに一番時間を使っているのも、コードではなくここです。工程の全体像は、AI字幕生成の仕組みと工程で整理しています。
内製なら現場が近いぶん有利だ、という反論はまったく正しいと思います。ただ、条件が一つあります。業務を知っている人が、暗黙のルールを言語化する時間を取れること。そしてその人はたいてい現場の主戦力で、その時間がないんですよね。
もう一つ、どこまでをAIに任せて、どこから先を人が引き取るのかも決めておく必要があります。字幕なら、生成は任せて最終確認は人が持つ、という線になります。この線を引かないまま自動化を進めた現場は、間違いが出た瞬間に「誰の責任か」で止まります。
道具の選定は、あとから設計に染み出す
二つめは、エージェントに持たせる道具です。
内製化の検討では、まずどのエージェントを使うかが議論になります。Claude Codeか、Codexか、ほかのコーディングエージェントか。私たちも複数を併用していますが、正直に言うと、ここでの選択が案件の成否を分けた記憶はほとんどないんですよね。差が出るのは、そのエージェントに何を読ませて、何を実行させて、何の結果で合否を判定するか。そちらです。
呼び出せる社内データ、外部API、実行を許すスクリプト。文字起こしを含む機能なら、どの音声認識APIを選ぶかで精度も費用も変わります。ただ、選定を誤ったときに効いてくるのは単価の差ではありません。APIは薄い層で、あとから差し替えられると思われがちなんですが、実際には出力の形が設計に染み出すんですよね。タイムコードの粒度。話者情報の持ち方。信頼度スコアの有無。ここが変わると、後段は書き直しです。
どのAPIがどこで破綻するのかは、カタログの比較では分かりません。実際の素材で動かして、期待どおりにならなかった記憶が溜まって、ようやく判断できるようになります。文字起こしAIの比較でエンジンごとの得手不得手を並べていますが、そこに書けるのも私たちが試した範囲だけです。初めて内製化する組織には、その蓄積がまだありません。
社内データへの接続も同じです。どの範囲のドキュメントを検索させるか、書き込みまで許すか、実行結果を人が承認してから反映するか。これはもう権限の設計そのもので、次に挙げるセキュリティと地続きです。
動いていることと、正しいことは別
三つめは、正しさを誰が判定するかです。
エージェントはテストコードを書きます。ただし書けるのは「コードが意図どおりに動くか」のテストです。「その意図が業務上正しいか」は書けません。仕様のほうが間違っていれば、間違った仕様を忠実に守るテストが、気持ちよく全部通ります。
受託開発でも同じ問題は起きます。違うのは、検収という工程があることです。正しさの判定を業務側が担うと契約に書いてある。内製化すると、この境界が消えるんですよね。作った人が正しさも判定することになって、その人が理解した範囲でしか検証されません。動いているように見えるものが本番に出て、運用で発覚します。
判定の基準も、精度が何パーセント、では足りません。どの種類の間違いなら運用で吸収できて、どの種類は絶対に出してはいけないのか。放送でいえば、軽微な誤字と放送禁止用語の見落としが同じ重みのはずがありません。この重みづけは、業務側にしか作れないものです。
内製化を決める前に決めておくべきなのは、開発体制よりも、この判定を誰がどの基準でやるかのほうだと思います。
セキュリティは、動いてからでは足せない
四つめはセキュリティです。
エージェントに開発をさせると、行き来する情報が増えます。ソースコード、認証情報、テストに使う実データ。どこまでを外部のモデルに渡していいかは、現場の判断ではなく、組織として決める話ですよね。
放送素材のように、公開前の映像そのものが機密である領域だと、そもそもクラウドに上げていいかが最初の設計判断になります。オンプレとクラウドの切り分け、鍵の管理、ログの残し方。放送素材をオンプレミスで扱うときの構成に書いたとおり、あとから足せる要素ではありません。
そして内製化の初期は、ここが一番飛ばされやすい。動くものを早く出すことが目的になっているからです。動いてから権限設計をやり直す。4つの中で、これがいちばん高くつきます。
やり直しの回数が、内製化の費用を決める
4つ並べると、内製化はやめておけという話に読めるかもしれません。そうではないんです。回数の問題なんですよね。
内製化の見積もりが外れる原因は、1回あたりの開発が高いことではありません。捨てる回数が、最初から数えられていないことです。実装が5倍速くなっても、3回作り直せば元の工数に戻ります。速くなったぶんは、きれいにやり直しへ吸われます。
だから、始める場所の選び方が効きます。基幹の設備をいきなり置き換えにいくと、4つが同時に襲ってきます。手元の集計作業、チェック作業の支援、素材へのメタデータ付与、社内ドキュメントの検索。この辺りから始めれば、間違えても業務は止まりませんし、捨てるコストも小さい。段を上げるたびに、検証と権限の要求が一段ずつ厳しくなります。いきなり最上段から入るのが、いちばんよくある失敗です。
受託に任せたほうが結果として安く済む場合がある、というのはこの意味です。外に出しているのは、コードを書く速度ではありません。どこで間違えると高くつくかの記憶のほうだと思っています。
決める人がいない内製化は、使われないリポジトリを残す
ここまで技術の話をしてきましたが、実際にいちばん効くのは技術ではないんですよね。方針を決める人がいるかどうかです。
決めるのは細部ではありません。どの業務を対象にするか。何を確かめられたら成功とみなすか。誰が本番投入を承認するか。外部のサービスに何を渡していいか。ここさえ決まっていれば、実装の進め方は現場に任せて構いません。
空白のまま人員だけ配置すると、どうなるでしょうか。判断が要るたびに、各チームが独自に決めます。それぞれのやり方でエージェントが走って、似て非なる小さなツールが増えていく。どれも動きます。ただし誰も保守できません。半年後に残るのは、使われないリポジトリの束と、消えた工数です。
この役割は外から補えます。ただ、丸投げはできません。決めるのは組織の側で、外部にできるのは判断材料を揃えるところまでです。
内製か外注かではなく、どの工程を自社で持つか
議論を内製か外注かの二択にすると、たいてい間違えます。工程ごとに答えが違うからです。
業務ルールの言語化と、正しさの判定。これは自社で持つしかありません。外に出せない。逆に、道具の選定と初期の設計、セキュリティの線引きは、失敗の記憶を持っている側に任せたほうが、やり直しの回数は減ります。実装はどちらでもいい。エージェントが書くんだから、と言い切ってしまっていい部分です。
AIで開発が安くなった。この話自体は正しいと思います。ただ、安くなったのは、いま挙げた工程のうち一つだけなんですよね。残りをどう分けるかを決めないまま人員と予算を組み替えたとき、半年後の自社に何が残っているでしょうか。保守できるコードと、それを判断できる人。この2つが揃っているかどうかで、たぶん決まります。