多重下請けから、AI CoE と顧問のパートナーへ

--- title: "AI CoE の内製化で、パートナー企業はどうすればいいのか ― 人月から「顧問」へ" url: "https://www.geekfujiwara.com/ai-coe/9553/" author: ギークフジワラ published: "2026-10-26T23:41:03+00:00" updated: "2026-10-26T23:53:24+00:00" categories: [AI CoE] tags: [AI CoE, Copilot Cowork, FDE, パートナー, 内製化, 開発標準] description: "ユーザー企業の AI CoE が内製を始めると、多重下請けと人月のビジネスは縮みます。一方で、AI CoE の立ち上げ支援、Cowork スキルハッカソン、レビューや保守の「顧問」のビジネスが生まれます。FDE との違い、フルスタックビルダー、サブスクリプションの指標を図と例で紹介します。" --- # AI CoE の内製化で、パートナー企業はどうすればいいのか ― 人月から「顧問」へユーザー企業の AI CoE が、外注費を減らすために内製を始めています。では、これまでシステムを受託してきた**パートナー企業**は、どうしたらよいのでしょうか。結論から書きます。==工数を切り売りする人月のビジネスは縮みます。一方で、内製を支える「顧問」のビジネスが生まれます。==この記事では、何が変わり、パートナー企業がどちらの道を選べるのかを、図と例でまとめます。 {.point} - AI CoE の内製で、多重下請けの産業構造がどう変わるか - 減るビジネスと、増えるビジネス - AI CoE のプロセスのどこを支援するか（プロセス図） - FDE（プロトタイプして納める）と、内製の支援のどちらを選ぶか - 「フルスタックビルダー」による顧問のビジネスモデル - パートナー企業の成功の指標は、人月からサブスクリプションへ > [!NOTE] > この記事は、ユーザー企業の AI CoE とパートナー企業の関係について、私の考えをまとめたものです。AI CoE の全体像は[こちらの記事](https://www.geekfujiwara.com/ai-coe/9549/)にあります。 ## 多重下請けの構造が崩れるこれまでのシステム開発は、元請けが受けて、一次・二次の下請けに分けて作る、多段階の構造でした。ユーザー企業は工数（人月）に対価を払い、各社が工数を積み上げて売上にしてきました。 AI CoE が内製を始めると、この構造の土台が変わります。GitHub Copilot と開発標準で、ユーザー企業の少ない人数でもアプリを作れるようになるからです。 :::raw

::: ### 工数の切り売りから、価値への対価へ AI 駆動の開発では、同じものを作る時間が大きく縮みます。==時間で値段を決めると、AI でうまく作るほど売上が減る==という矛盾が起きます。だから、対価の決め方が変わります。かかった時間ではなく、生み出した価値（外注費の削減、立ち上げの速さ、品質、人が育つこと）に対価を払ってもらうモデルです。そのためには、まず==お客様の KPI を知り、それを同じ目標にする==ことが出発点になります。 | | これまで（人月） | これから（価値） | | --- | --- | --- | | 何に払うか | かかった工数 | 生み出した価値・継続して使えるサービス | | AI で速く作ると | 売上が減る | 同じ人数でより多くの顧客を支えられる | | 契約 | 案件ごとの請負・準委任 | 月額の顧問・サービス | | 強み | 人数・体制 | 知見・開発標準・個人の実績 | ## 減るビジネスと、増えるビジネス減るのは、仕様を受けて作って納める、工数の積み上げのビジネスです。一方で、内製するユーザー企業を支える仕事が増えます。 ### IT 部門向け：AI CoE の立ち上げ支援 AI CoE を作っても、最初の一歩でつまずく会社は多いです。そこを支えるメニューです。 {.check} - 本部 AI CoE の役割と KPI の設計（外注費の削減を 1 番目に） - 外注費の棚卸しと、内製する候補の選び方 - 環境・ライセンス・ガバナンスの整理 - 開発標準の導入と、自社の標準への作り替え - 経営に説明するためのプロトタイプづくりの伴走 ### ビジネス部門向け：Cowork スキルハッカソンなどのイベント支援現場の人が、自分の仕事を Copilot Cowork のスキルにするハッカソンです。企画・運営・審査・振り返りまでを支援します。 https://github.com/geekfujiwara/Copilot-Cowork-Skills ### 内製チームの中に入る「プロジェクト支援チーム」時間で精算するのではなく、==ユーザー企業の内製チームに、いつも一緒にいる==支援です。AI CoE の一員のように、プロジェクト全体を支えます。作るのはユーザー企業で、パートナー企業は設計の相談、レビュー、詰まったときの手助けを受け持ちます。 ## プロセスのどこを支援するか増えるビジネスを、ユーザー企業の AI CoE のプロセスに重ねると、次のようになります。==どの段階でも、お客様の KPI を知り、それを同じ目標にする==のが前提です。 :::raw

::: | STEP | AI CoE のプロセス | パートナー企業の支援 | 一緒に追う KPI の例 | | --- | --- | --- | --- | | 1 | 立ち上げ | 役割と KPI の設計、環境・ライセンス・ガバナンスの整理 | KPI が決まり、経営の合意がとれたか | | 2 | 棚卸し | 外注費の一覧から、内製する候補を選ぶ伴走 | 削減できる外注費の見込み額 | | 3 | プロトタイプ | パートナーの環境で作って見せ、経営への説明を手伝う | 経営の承認、プロトタイプまでの日数 | | 4 | 1 つ目の展開 | 開発標準の導入、内製チームに入って開発を伴走 | 外注費の削減額、使う人の数 | | 5 | 事業部へ | Cowork スキルハッカソン、作る人の育成 | 内製したアプリ・スキルの数、育った人の数 | | 6 | 運用 | アプリ・エージェントのレビュー、内製アプリの保守 | 障害の数、改善のリリースの数 | > [!IMPORTANT] お客様の KPI を、自分たちの目標にする > 顧問の価値は、作業の量ではなく、お客様の成果で測られます。最初に==お客様の KPI を知り、それを同じ目標にする==こと。外注費の削減額が増えれば、顧問としての価値も上がります。目標が同じなら、AI で速く作るほど、お客様にもパートナー企業にも良い結果になります。 ## FDE か、内製の支援か最近よく聞く **FDE**（Forward Deployed Engineer）は、パートナー企業のエンジニアがユーザー企業の現場に入り、プロトタイプを作って納める形です。速く成果が出る一方で、作る力はパートナー企業の側に残ります。これは、==ユーザー企業が自分で人材を育てていく AI CoE の内製とは、反対の方向のアプローチ==です。どちらが正解というわけではありません。内製を進めるのか、作ってもらって使う側でいるのかは、その会社の人材と KPI に関わる戦略です。企業の文化とあわせて選びましょう。 | | 内製の支援（AI CoE が作る） | FDE（パートナーが作って納める） | | --- | --- | --- | | 作る力が残る場所 | ユーザー企業 | パートナー企業 | | 速さ | 最初はゆっくり、育つほど速い | 最初から速い | | 費用 | 育成と内製の人件費。外注費が下がる | 成果に対する対価が続く | | 向いている KPI | 外注費の削減、人材育成、内製の生産性 | 早く成果を出すこと、本業への集中 | ### 合っている企業の文化の例 | 内製の支援が合う文化 | FDE が合う文化 | | --- | --- | | 現場で改善を重ねる文化がある（製造の改善活動、店舗の工夫など） | IT を競争力の中心に置かず、本業に集中したい | | 自分たちの業務を、自分たちで変えたい人がいる | 短い期間で成果を見せる必要がある | | 人を育てることに投資する（研修、社内の勉強会） | 人の異動が多く、作る人を社内に残しにくい | | 業務の変化が速く、外に頼むと間に合わない | 専門の人材を持たない方針で、外の力を使い分ける | | 失敗を許して、小さく試す | 決まった品質を、決まった期日に求める | 1 つの会社の中でも、部門によって合う形が違うことがあります。==事業部 AI CoE ごとに、どちらの形にするかを決めてもよい==のです。 ## パートナー企業の 2 つの道パートナー企業にも、選ぶ道が 2 つあります。 :::raw

::: ### 道 B の始め方：まずはパートナーの環境で作って見せる道 B で大事なのは、==いち早くユーザー企業のプロセスに入り込み、経験を積み始める==ことです。そのとき、次の進め方が効きます。 {.steps} 1. **お客様の KPI を知り、それを同じ目標にします。** 外注費の削減額など、お客様が経営に約束している数字を、最初に一緒に確かめます。 1. **顧客のデータは、まず使いません。** 架空のデータや公開の情報で作ります。 2. **環境の準備にハードルがあるときは、パートナー企業の環境で作って見せます。** 動くものを見せると、インパクトが伝わります。 3. **デモを見ながら、一緒に要件を固めます。** 文書のやりとりより、ずっと速く進みます。 4. **ガバナンスの整理が終わったら、ユーザー企業の環境に移します。** > [!TIP] パートナー企業と組むメリット > ユーザー企業の環境やガバナンスの整理がまだでも、パートナー企業の環境で始められます。スピードが上がり、デモでのコミュニケーションも早くなります。これは、ユーザー企業がパートナー企業と協業する大きなメリットです。 ### 知見を、組織の開発標準にためる道 B で積んだ経験は、パートナー企業の==開発標準==としてためます。スキル、テンプレート、レビューの観点、つまずきやすい点です。メンバーはその標準を使って、次の企業に、より速く、新しい価値を提案できます。 https://www.geekfujiwara.com/tech/powerplatform/8554/ ## フルスタックビルダーの「顧問」になるこれまでの開発のプロジェクトには、PMO、機能のコンサルタント、開発者が、それぞれ別にいました。AI を使えば、==この 3 つの役割を 1 人が担う「フルスタックビルダー」==が成り立ちます。 | これまでの役割 | フルスタックビルダーが AI を使ってすること | | --- | --- | | PMO | 進め方の設計、課題の管理、経営への説明の資料づくり | | 機能のコンサルタント | 業務の理解、要件の整理、製品の機能の選び方 | | 開発者 | GitHub Copilot と開発標準での、プロトタイプとレビュー | このフルスタックビルダーを、1 社に固定で置くのではなく、==複数の企業にサービスとして提供==します。イメージは、税理士の**税務顧問**です。毎月決まった顧問料で、困ったときに相談でき、定期的に見てもらえる。必要なときは、もっと深く入ってもらう。そうなると、ブランドも変わります。「大手の元請けだから頼む」から、==「この人に見てもらいたいから頼む」==へ。企業のブランドから、個人のブランドになっていきます。 ## さらに生まれる新しいビジネス顧問の形になると、内製するユーザー企業の周りに、新しい仕事が生まれます。 | ビジネス | 中身 | | --- | --- | | 開発標準のレビュー | ユーザー企業が作った自社の開発標準を、プロの開発組織の目で見る | | アプリのレビュー | 内製したアプリの設計・セキュリティ・性能を確かめる | | エージェントのレビュー | Copilot Studio のエージェントや Cowork のスキルの、権限・外部への作用・品質を確かめる | | ハッカソンの顧問 | Cowork スキルハッカソンの進め方、審査の基準、人材育成につなげる方法を助言する | | 内製アプリの保守 | ユーザー企業が作ったアプリを、決まった範囲で保守するサービス | ### 例：Cowork スキルハッカソンの審査の基準ハッカソンの顧問では、表彰の基準を一緒に決めます。==人材育成につながる基準==にするのがポイントです。 | 観点 | 見るところ | 配点の例 | | --- | --- | --- | | 業務へのインパクト | 減る時間や外注費が、数字で示せるか | 30 | | 再利用できるか | ほかの人や部署でも使えるように、汎用化されているか | 20 | | 安全か | 送信や共有など外への作用は、人が確かめる作りか。権限の範囲は最小か | 20 | | 動くか | 実際の仕事で、最後まで動くか | 15 | | 人に伝わるか | 使い方を説明でき、ほかの人が改善を続けられるか | 15 | > [!TIP] 人材育成につなげるコツ > 1 位だけを決めるのではなく、上位のスキルを AI CoE が「全社のスキル」として配り、作った人を次のハッカソンのメンターにします。作った人が教える側に回ると、育成が続きます。 ## 成功の指標は、人月からサブスクリプションへビジネスの形が変わると、パートナー企業の成功の指標も変わります。 | | 人月のビジネスの指標 | サブスクリプションのような指標 | | --- | --- | --- | | 売上 | 稼働した人月 × 単価 | 月ごとの継続の売上（MRR）、年間（ARR） | | 効率 | 稼働率 | 1 人のビルダーが支える顧問先の数 | | 健全さ | 案件の受注残 | 継続率・解約率、既存の顧客の売上の伸び（NRR） | | 顧客の価値 | 納品したかどうか | 顧客の外注費の削減額、内製したアプリの数、育った人の数 | ### 例：人月のエンジニアと、顧問のビルダーあくまで考え方の例です。 :::raw

::: 人月のエンジニアは、1 社に常駐すると、売上は時間で頭打ちになります。顧問のビルダーは、AI と開発標準で 1 社あたりの手間を小さくし、==顧問先を増やすほど売上が積み上がります。==顧問先が続く限り、毎月の売上も続きます。 ## まとめ {.check} - AI CoE の内製で、多重下請けと工数の切り売りのビジネスは縮みます。対価は、時間ではなく価値に払われるようになります。 - 増えるのは、AI CoE の立ち上げ支援、Cowork スキルハッカソンなどのイベント支援、内製チームの中に入るプロジェクト支援です。 - どの段階の支援でも、お客様の KPI を知り、それを同じ目標にします。 - FDE と内製の支援は、反対の方向のアプローチです。どちらが正解ではなく、ユーザー企業の人材と KPI と文化で選びます。 - 内製の流れに乗るなら、まずパートナーの環境で作って見せ、知見を開発標準にため、フルスタックビルダーの顧問として複数の企業に提供します。 - 開発標準・アプリ・エージェントのレビュー、ハッカソンの顧問、内製アプリの保守といった、新しいビジネスも生まれます。 - 成功の指標は、人月と稼働率から、継続の売上・継続率・顧客の外注費の削減額へ変わります。ユーザー企業側の AI CoE の進め方は、こちらの記事にまとめました。 https://www.geekfujiwara.com/ai-coe/9549/ https://www.geekfujiwara.com/ai-coe/9485/ 内製で作り直すシステムの選び方とコストの試算、個人の仕事を任せる Cowork の始め方は、こちらです。 https://www.geekfujiwara.com/tech/powerplatform/9527/ https://www.geekfujiwara.com/copilot/9490/