受託開発とイネーブルメントの境界が溶けていく

Executive Summary

これまでビジネスにおけるタスク遂行の構図は「人 → ソフトウェア → タスク」だった。業務を効率化したければソフトウェアを作り、ソフトウェアを通じてタスクを完遂する。受託開発とはまさにこの媒介物——ソフトウェア——を作る行為だった。しかしAIエージェントの成熟により、この構図が「人 + エージェント → タスク」へと変わり始めている。ソフトウェアという媒介物なしに、人がエージェントと直接タスクを遂行できる世界が現実になりつつあるのだ。この変化は受託開発というビジネスモデルの前提そのものを揺るがし、その先にあるのはイネーブルメント——組織がエージェントを使いこなせる状態を作ること——への収斂である。そしてこの流れは、シリコンバレーで急速に広がるFDE（Forward Deployed Engineer）という新しいエンジニア像とも合流しつつある。

01｜ソフトウェアの媒介が外れ始めた

2026年2月24日、野村総合研究所（NRI）はAnthropic Japanとのパートナーシップ拡大を発表した。注目すべきは、その内容が単なるAPI再販ではなく、「Claude導入支援サービスの確立」と「全社的なClaude for Enterprise内部展開」の二本柱であることだ。NRIは自社内でClaude Coworkの実務検証も進めており、コンサルティング知見とAI実装能力を組み合わせた「エンドツーエンドの支援」を打ち出している。ここで注目してほしいのは、NRIが売ろうとしているのが「ソフトウェア」ではなく「Claudeを使いこなせる組織体制」だという点だ。

同じ2月、SIerのテックファームは「半年で全案件AI駆動開発を標準化した」と発表し、「AIが書き、エンジニアが決める」という開発パラダイムへの移行を宣言した。さらに3月23日には、ソフトウェアテスト大手のベリサーブが新卒約100名の研修に生成AI教育を全面導入。4ヶ月間にわたるプログラムで、プロンプトエンジニアリングからAIアプリ開発、品質保証までを一気通貫で学ばせる。

もう一つ象徴的な事例がある。個人開発者がGitHubで公開したOSSプロジェクト「LINE Harness」だ。LINE公式アカウントのCRM機能——ステップ配信、セグメント配信、リッチメニュー、フォーム、Stripe決済連携、IF-THEN自動化——を、Cloudflare Workers上で永久無料で提供する。月額数万円のSaaS（Lステップ等）の上位互換を謳い、MITライセンスで全コードを公開している。開発者は「AI進化により、あらゆるSaaSは民主化される時代が来ている」と宣言している。

LINE Harnessが興味深いのは、単にSaaSを無料化したことではない。このプロジェクトはClaude Code対応を明示しており、REST APIを全公開している。つまり、管理画面をポチポチ操作する代わりに、Claude Codeから直接LINE配信を設計・実行できる設計になっている。ここには「人 → SaaS（ソフトウェア） → LINE配信」という旧来の構図が、「人 + Claude Code → LINE配信」へ転換する未来が既に織り込まれている。

これらの動きに共通するのは、タスク遂行の媒介としてのソフトウェアの地位が、急速に低下しているという事実だ。

02｜「AIでこれできない？」への回答が変わった

私自身、クライアントから「AIでこういうことはできないか」という相談を受ける機会は多い。これまでの典型的な回答は、AIエージェントを実装し、動作するシステムとして納品する——つまり受託開発の形態だった。「人 → ソフトウェア → タスク」の構図に沿って、媒介となるソフトウェアを作るわけだ。

しかし最近、別の選択肢が現実的になってきた。クライアントの環境にClaude Codeをインストールし、必要なskillsファイルやプロンプトテンプレートを整備し、「やりたいタスクをClaude Codeに直接実行させる構造」を組織の中に構築するというアプローチだ。

この場合、納品物はソフトウェアではない。skillsファイル（実態はMarkdownとシェルスクリプト）、設定ファイル、そしてそれを使いこなすためのノウハウ——極端に言えば、テキストファイルと知識だ。構図は「人 + エージェント → タスク」であり、間にソフトウェアが挟まらない。

こちら側のメリットは明確で、保守という概念が存在しない。ソフトウェアのバグ修正もバージョンアップ対応も発生しない。手離れが圧倒的に良い。

クライアント側にとっても、メンテナンスが必要な重いソフトウェアを抱えるより、シンプルなテキストファイルとノウハウを手にする方が合理的だ。何より、次に似たようなことをやりたくなったとき、外部に依頼するのではなく「自分たちで作ればいい」状態になれる。これは受託開発では決して実現しない価値だ。

LINE Harnessの事例に引き寄せて言えば、かつてならLINE公式アカウントの自動配信をやりたいクライアントに対しては、配信システムを開発して納品するか、既存SaaSの導入を支援していた。今なら、LINE HarnessをデプロイしてClaude Codeのskillsを整備し、「配信設計からセグメント設定まで、Claude Codeに指示すればできる状態」を作って引き渡すことができる。クライアントはLINEマーケティングのたびにベンダーに発注する必要がなくなる。

03｜「人 → SW → タスク」から「人 + エージェント → タスク」へ

なぜ今、ソフトウェアの媒介が外れ始めたのか。3つの構造的要因がある。

第一に、エージェントがAPIとファイルシステムを直接操作できるようになった。 vol.3で論じたように、AIエージェントの設計思想はWeb APIではなくOSのプリミティブ——シェルコマンドとファイルシステム——に直接アクセスする方向に向かっている。Claude CodeやCodecsはその具現だ。従来「ソフトウェア」が担っていた役割——APIの呼び出し、データの整形、UIを通じた操作——を、エージェントが直接引き受ける。LINE HarnessがREST APIを全公開しClaude Code対応を謳うのは、まさにこの潮流を先読みした設計だ。

第二に、エージェントの学習曲線が証明されたこと。 Anthropicの調査によれば、6ヶ月以上の利用経験を持つユーザーは、新規ユーザーに比べて会話成功率が約4ポイント高く、より複雑なタスクに取り組む傾向がある。つまり「使い込むほど強くなる」のはソフトウェアではなく、人とエージェントの協働関係そのものだ。ソフトウェアを納品するよりも、この協働関係を組織に根付かせることの方が、長期的な生産性向上に寄与する。

第三に、SIerへの圧力と既存SaaSの解体。 テックファームの事例が象徴するように、クライアントから「AIを使えばもっと早くできるよね？」という問いが投げかけられる時代になった。同時に、LINE Harnessのようなプロジェクトが、月額課金SaaSの存在意義を根底から問い直している。ソフトウェアを作る側も、ソフトウェアを売る側も、「ソフトウェアが媒介として本当に必要か？」という問いに直面している。

04｜FDE——「前線に配備されるエンジニア」という解

ここで、この構造変化を体現する職種概念に触れておきたい。FDE（Forward Deployed Engineer）だ。

FDEとは、顧客の現場に深く入り込み、プロダクトの導入から定着までを一貫して支援するエンジニアを指す。このモデルを確立したのは、2003年創業のPalantir Technologiesだ。同社はデータ分析プラットフォームを汎用SaaSとして売るのではなく、FDEを顧客先に数ヶ月間常駐させ、顧客固有のデータ環境に入り込んでソリューションを構築・定着させるアプローチで急成長した。2024年には株価が340%以上上昇し、2026年現在も時価総額で世界有数のソフトウェア企業であり続けている。

元OpenAI首席研究責任者のBob McGrew氏はFDEを「プロダクト化されたコンサルティング」と表現した。これは的確だ。受託開発でもなく、SaaS提供でもなく、コンサルティングでもない——その中間に位置する。

注目すべきは、FDEが今まさにAIエージェント時代に再発見されていることだ。LinkedInでのFDE求人は800〜1,000%増加しており、日本でもLayerX、SmartHR、AI ShiftといったSaaS企業がFDE体制の構築を始めている。その理由は明確で、AIプロダクトには従来のSaaSにはない特性——出力の確率的不確実性、既存業務フローへの統合の難しさ、継続的チューニングの必要性、Human-in-the-Loop設計のドメイン依存性——があり、「導入して終わり」では価値が出ないからだ。

ここで本稿の論旨と接続する。「人 → ソフトウェア → タスク」の時代には、ソフトウェアを作って渡せば仕事は完了した。しかし「人 + エージェント → タスク」の時代には、エージェントとの協働関係を顧客の現場で設計し、定着させなければ価値が出ない。FDEとは、まさにこの「定着」を担うエンジニアだ。

そしてFDEに求められるスキルセットは、従来のソフトウェアエンジニアとは大きく異なる。Goodpatchの整理によれば、Business（顧客事業理解とROI設計）、Technology（AIデプロイと運用能力）、Creativity（課題特定とプロトタイピング）の3領域——いわゆるBTCの交差点に立つ人材だ。コードを書く力だけでなく、顧客のドメインを理解し、組織変革を推進する力が求められる。

05｜「受託」でも「研修」でもない第三の形態

この構図の転換とFDEの台頭を踏まえて整理すると、いま起きていることはこうだ。

この「第三の形態」は、受託開発の即効性と、研修・イネーブルメントの自立支援を兼ね備える。実態としては、環境構築→初期skills開発→ハンズオン→自走支援というフェーズを経る伴走型プロジェクトだ。PalantirがFDSE（Forward Deployed Software Engineer）を顧客先に送り込んでデータ分析基盤を立ち上げ、最終的に顧客が自走できる状態にして引き上げるのと、構造的には同じことをやっている。

みずほフィナンシャルグループがグループ約3万人にClaudeを展開し、楽天グループがClaude Codeで新機能実装時間を80%削減した事例は、大企業がすでにこの方向に動いていることを示している。問題は、中堅・中小企業がこの波にどう乗るかだ。そこにFDE的な立ち位置で伴走できるプレイヤーの価値は、従来型の受託開発会社とは質的に異なる。

06｜研修事業との接続

DELTAはこれまで、受託開発を主軸としつつも、研修事業を着実に進めてきた。正直に言えば、大々的に打ち出してきた領域ではない。しかし振り返れば、この二つの事業ラインが交差する地点こそが、まさに本稿で論じた「第三の形態」——FDE的なアプローチそのものだ。

クライアントの組織にエージェント環境を構築し、初期のskillsを設計し、使いこなすための伴走を行う。これは「開発」なのか「研修」なのか。答えは、もはやどちらでもある。受託開発の技術力と、研修事業で培った「人に教え、自走させる」能力の両方が要る。FDEに求められるBTC——Business、Technology、Creativity——のすべてが試される領域だ。

「人 → ソフトウェア → タスク」の時代には、ソフトウェアを作る技術力が競争優位だった。「人 + エージェント → タスク」の時代には、人とエージェントの協働関係を設計し、組織に定着させる力が競争優位になる。ベリサーブが新卒研修でプロンプトエンジニアリングからAIアプリ開発までを教えるように、エージェントを使いこなす力は、今後あらゆる組織の基礎体力になる。その基礎体力をつける支援——FDEとして顧客の前線に立ち、エージェント環境を構築し、自走できる状態まで伴走する——これが、受託開発とイネーブルメントの境界が溶けた先にある仕事の形だと考えている。

経営者が今すぐ問うべき3つの問い

1. 自社の「AIでこれできない？」案件に、本当にソフトウェアという媒介物が必要か。 「人 + エージェント → タスク」で解決できるなら、保守コストゼロ・ベンダー依存ゼロの選択肢を検討すべきだ。 
2. 外部への依頼は「ソフトウェアを買う」か「エージェントとの協働力を身につける」か。 前者は一時的な課題解決、後者は恒久的な組織能力の獲得。FDE的な伴走を受け、最終的に「自分たちでやれる状態」を目指す方が、中長期の競争力に寄与するのではないか。 
3. 自社の研修・育成プログラムに「エージェント活用」は組み込まれているか。 Anthropicのデータが示す6ヶ月の学習曲線を考えれば、始めるなら今だ。FDEに求められるBTC人材は、社内からも育てていく必要がある。 

参考：
・野村総合研究所、Anthropic Japanとのパートナーシップを拡大（2026/2/24）
・SIerでもAI駆動開発はできる——テックファームの現在地（2026/2/17）
・ベリサーブ、新卒社員研修に生成AI教育を導入（2026/3/23）
・LINE Harness — L社やU社の上位互換を、なぜ0円で公開するのか
・FDE（フォワードデプロイドエンジニア）とは何か——AI時代に求められる「現場に入り込む」スキルセット（Goodpatch）
・FDE（Forward Deployed Engineer）はDX現場をどう動かす？（メンバーズ）