2027年までに自社開発される可能性が最も高いソフトウェアカテゴリ

2027年までに、内製開発される可能性が最も高いソフトウェアカテゴリは、ワークフロー自動化、社内管理ツール、ダッシュボードとBIレポート、簡易CRM、プロジェクト管理、そしてカスタマーサポートツールです。その境界線は「プロセス」か「正確性」かという点にあります。自社のビジネスの仕組みを定義するソフトウェアは、今やレンタルするよりも構築する方が安価です。一方で、給与計算、決済、元帳、税務など、常に100%正確でなければならないソフトウェアは、今後も外部調達のまま残るでしょう。

どのソフトウェアカテゴリが最初に内製へとシフトするか？

最初に移行するのはワークフローと管理ツールです。Retoolの2026年版 内製 vs 外部調達レポート（817人の開発者を対象とした調査）によると、35%がすでに少なくとも1つのSaaSツールをカスタム開発に置き換えており、78%が2026年中にさらに多くのツールを構築する予定であると回答しています。最も置き換えの圧力が強いカテゴリは、ワークフロー自動化（35%）、社内管理ツール（33%）、BIツール（29%）、CRMおよびフォーム作成ツール（25%）、プロジェクト管理（23%）、カスタマーサポート（21%）となっています。

これらのカテゴリの共通点に注目してください。これらは、自社のデータを自社のプロセスに沿って動かすものです。高度なコンピュータサイエンスを必要とするものはなく、その価値は常にワークフロー自体にあり、そのワークフローはベンダーのものではなく自社のものです。汎用ツールが自社プロセスの70%しかカバーしていないにもかかわらず、アカウントごとに利用料を請求される場合、100%をカバーできるAI支援のカスタム開発の方が、スプレッドシート上の計算で勝ち始めます。また、失敗したときのコストも低いです。社内ダッシュボードが一時的に壊れても、失うのは半日の時間であり、訴訟沙汰にはなりません。

なぜ今これが起きているのか？

エージェント型コーディングの登場により、「いつか構築すべき」だったものが2日間のタスクへと変わりました。Gartnerは、2027年までにエージェント型コーディングを使用するエンジニアリングチームの65%以上が、IDE（統合開発環境）をオプション（必須ではないもの）として扱うようになると予測しています。制御、ガバナンス、検証は自動化されたプラットフォームへと移行します。ソフトウェア開発は、コードを入力するものから、監督するものへと変化しつつあります。

前述のRetoolの調査は、成熟したAI開発が現場でどのように行われているかを示しています。実用的なソフトウェアをリリースした開発者のうち、72%はAIを自ら統合する個別のコード断片の作成に使用しており、プロンプトだけでアプリ全体を完成させているのは31%にすぎず、AIが生成したコードを修正なしでそのままリリースしているのはわずか8%です。プロンプトからアプリを丸ごと作成する手法は、依然として少数派です。変化したのは、カスタムソフトウェアの構築コストが十分に下がり、ツールカテゴリ全体で「内製か外部調達か」のデフォルト設定が逆転したことです。しかも、この変化は静かに起きています。調査対象となった開発者の60%が、過去1年間にIT部門の監視外で何らかのツールをリリースしています。

Klarnaは何を証明したのか？

Klarnaが証明したのは、誇大広告ではなく、明確な「切り分け」です。2024年、同社のCEOはSalesforceとWorkdayの利用を停止すると発表し、メディアはSaaSの終焉を報じました。しかし、その後の追跡レポートはヘッドラインよりもはるかに有益なものでした。CX Todayの確認によると、KlarnaはWorkdayを別のベンダーのHRプラットフォームに置き換え、CRM機能については、小規模なSaaSツールと内製の連携システムを組み合わせ、その上にAIを重ねる形で再構築していました。

これを注意深く読めば、先ほど挙げたカテゴリリストの正しさが裏付けられます。Klarnaが内製したのは、データの統合、社内ワークフロー、自社独自のプロセスが存在するレイヤーといった「結合組織」の部分です。コアとなる銀行勘定系元帳を、感覚的なAIコーディング（Vibe Coding）で構築したわけではありません。Klarnaは認可を受けた銀行です。常に正確性が求められるソフトウェアは専門ベンダーに任せ、プロセスを扱うソフトウェアを内製へと移行しました。これこそが、2027年までに多くの企業が下すことになる決断と同じトレードオフです。

どのソフトウェアが外部調達のまま残るか？

誤った処理が金銭的損失やライセンス違反につながるすべてのものです。給与計算や税務エンジン。会計のシステム・オブ・レコード（公式記録システム）。決済処理とPCI準拠。認定された対面決済用ハードウェア。2つのレジが同じ秒数に最後の1個を販売しても、在庫数が正しく維持されるような同時実行制御下の在庫管理。1分1秒、1円単位まで一致させる必要のある照合レポートなどです。

AIはこうしたコードを流暢かつ自信ありげに書きますが、それこそが問題です。流暢で自信ありげであることは、高負荷環境下での正確性、監査への対応、認証の取得とは異なります。これらの特性は、何年にもわたる本番環境でのトラフィック処理とコンプライアンス対応の実績から得られるものであり、いかなるコーディングエージェントもそのプロセスをショートカットすることはできません。「AIでスタック全体を構築した」というストーリーを詳しく調べれば、その下には必ず外部調達されたコアシステムが存在していることが分かります。

この切り分けにおいて、POSはどこに位置するのか？

POSは、この境界線の両側に同時にまたがっており、非常に分かりやすいテストケースとなります。POSのフロントエンド、つまりチェックアウトフロー、画面表示、販売後の処理、スタッフの注文操作などは「プロセスソフトウェア」であり、他の業界で内製化が進んでいる社内ツールと同じ性質のものです。だからこそ、カスタムPOSの需要は伸び続けています。加盟店は、ベンダーが用意したテンプレートに自店のカウンターワークフローを無理に合わせることに限界を感じています。しかし、そのレイヤーの下にある決済処理、在庫の真実、照合レポートなどは、確実に「外部調達のまま残る」カテゴリに属します。

2027年に向けた現実的なパターンは、自社独自のこだわりがあるレイヤーを構築し、それを他社が正確性を担保しているインフラの上に載せることです。Finalはこの切り分けを軸に構築されています。自然言語でPOSの要件を記述するか、MCPを介して独自のAIを接続すると、作成したフローが管理済みのコマースインフラ上で動作します。在庫管理、レポート作成、そして決済プロセッサーや認定端末を通じた決済はFinal Payが処理します。このパターンを実際に確認するには、ChatGPT-5.6を使用したカスタムPOSの構築のチュートリアルをご覧ください。AIがどこを担当し、インフラがどこを引き継ぐのかが正確に示されています。