AIで作れる時代に、企業はどう手分けするか

2026/11/06

少人数の探索と組織での実用化、そして「作る・買う」の経営判断

AIを使い、これまでチームで取り組んでいた規模の開発を、1人や少人数で進めた事例が出てきています。

事例	人的リソース	報告された成果	AI活用	情報源・留意点
Copilot Cowork開発	9人のエンジニア（1,211件のPRを取り込んだ日の人数）	空のリポジトリから約4.5か月で世界向けの一般提供。2026年10月21日に1,211件のPRを取り込み	AIエージェントがコードの大部分を記述	Microsoft公式の開発報告。[1]
GitHub CopilotランタイムのRust移植	主に1人の開発者。連携部分の実装やレビューなどには他のメンバーも参加	数か月で80万行超の本番用Rustコードへ移植。128件のPR	AIエージェントがコードの大部分を記述	GitHub公式の開発報告。「従来ならチームで1〜2年」は執筆者の見積もり。[2]
One Developer Is All You Need	1人の熟練エンジニア＋4つのAIエージェント	4人のチームを想定した案件を予定期間の半分で提供。直接人員コスト85%以上削減と報告	仕様駆動の開発で、AI生成コードの初回レビュー受入率90%	単一案件を扱う研究論文。対照群との同時比較ではなく、総保有コスト全体の削減率でもない。[3]
キヤノンITソリューションズのAI Coding Agent活用	約3か月の業務適用検証に57人が参加	検証内のSNSバズ検知PoCで開発スピード約3倍と報告	Amazon Q Developerによる開発支援	キヤノンITS／AWS共同記事。全社一律の改善率ではない。[4]
Claude Codeによる個人開発事例	1人	「4人×6か月」想定の案件を「1人×2か月」で出荷したとの報告	Claude Codeによる開発支援	共有された調査に含まれる個人事例。元記事のURLがなく、一次情報は未確認。参考情報として掲載。

※各行の数値は、対象業務や比較方法が異なります。共通の条件で測定した生産性ランキングではありません。

コードを書く速度が上がるだけでなく、1人が扱える仕事の範囲が広がっている。そんな変化を感じさせる報告です。

私がこれらの事例から考えたいのは、組織の中でどう手分けするか、という点です。

先行する少数の人が、アイデアや着想を具体的な形にまとめる。その成果を受けて、後続の人たちが実用化や業務への定着に取り組む。AIによって探索を小さく速く進められるなら、組織としての力のかけ方も、それに合わせて考え直す必要があると思います。

さらに、この変化は自社だけで起きるものではありません。外部のサービス提供者もAIを使って開発を進めています。利用者である企業には、自分たちで作るか、外部から調達するかという選択があります。社内での役割分担と、社外のサービスを含めた分担。この二つを合わせて考えることが、これからのAI活用では重要になりそうです。

少人数の開発事例は、何を示しているのか

Microsoftが公開したCopilot Coworkの開発記事では、空のリポジトリから世界向けの一般提供まで約4.5か月で到達し、2026年10月21日には9人のエンジニアが1,211件のプルリクエストをメインブランチに取り込んだと報告しています。コードの大部分はAIエージェントが書き、人間は作業の定義、設計やセキュリティの境界、高リスクな変更の判断などを担っていました。[1]

GitHubによるCopilotのランタイム移植も印象的です。TypeScript／Node.jsから80万行超の本番用Rustコードへの移植を、主に1人の開発者が数か月で進めたと説明しています。ただし、連携部分の実装やパッケージング、レビューなどには他のメンバーも関わっています。「チームなら1〜2年かかった」という比較も、同じ案件を並行して実施した実験ではなく、執筆者による見積もりです。[2]

研究としては、ブラジルの金融機関における既存システムを伴う開発を扱った『One Developer Is All You Need』があります。4人のチームを想定した案件を、1人の熟練エンジニアと4つのAIエージェントで進め、予定の半分の期間で提供したと報告しています。著者らは、仕様の品質と、そのエンジニアが持つ組織・システムへの知識を成功の重要な要因に挙げています。ただし、単一案件の研究であり、同時に実施した対照群はありません。arXiv掲載版だけから査読状況を断定することも避けるべきでしょう。[3]

国内では、キヤノンITソリューションズとAWSが共同で、約3か月のAI Coding Agent活用検証を紹介しています。その中のSNSバズ検知に関するPoCで、開発スピードが約3倍になったと報告されています。全社の開発が一律に3倍になったという意味ではありませんが、業務の中で効果を検証し、展開につなげようとする例として参考になります。[4]

これらは、対象も測定方法も異なる事例です。プルリクエストの件数やコード行数は、それだけで業務価値や品質を表すものでもありません。一方で、少人数がAIを使って広い範囲の開発を進められる条件を考える材料にはなります。

ここから先は、こうした報告を踏まえた私の考察です。

先行する少人数が、着想を検証できるところまで進める

新しいアイデアがあっても、説明資料だけでは、どの程度役立つのかを判断しにくいことがあります。関係者の認識をそろえるために、実際に触れるものを作りたい。しかし、そのために開発体制を組む必要があると、試す前の調整に時間がかかります。

AIを活用することで、この段階を少人数で進められる可能性が広がります。業務課題を理解する人と、技術的な判断ができる人が、着想を整理し、試作品を作り、利用者の反応を確かめる。場合によっては、その役割を1人が兼ねることもできるでしょう。

たとえば、社内の問い合わせ対応を改善したいとします。まず限られた文書と利用者で、AIがどこまで回答できるかを試す。回答の正しさに加えて、文書を探す時間が減るか、確認漏れを防げるか、担当者が判断しやすくなるかを確かめる。この段階で得たいのは、機能の動作だけでなく、取り組みを続ける価値があるかという判断材料です。

少人数でこの探索を進められれば、まだ不確かな案に大きな体制を用意する負担を抑えつつ、有望な案を見つけやすくなります。先行する人たちの仕事には、アイデアを形にすることに加え、その価値と限界を他の人が判断できるようにすることも含まれます。

後続が担うのは、実際の業務で使い続けられる形にする仕事

試作品が役立ったとしても、そのまま組織全体で使えるとは限りません。

問い合わせ対応の例なら、利用者ごとの閲覧権限を守れるか、元文書の更新を回答に反映できるか、誤回答を誰が確認するか、といった課題が残ります。障害時の対応、費用の管理、問い合わせ窓口、運用担当者への引き継ぎも必要です。

そこで、先行する少人数の探索を受けて、業務部門や開発・運用・セキュリティの担当者が、実用化に向けて取り組む分担が考えられます。

先行する少人数から実用化を担う人たち、業務で活用する人たちへ成果を渡し、制約・課題や改善要求を前の段階へ戻して共有する役割分担 — 図1：探索・実用化・業務での活用を担う人たちの分担。成果を渡す流れに加え、制約・課題や改善要求を共有して行き来する関係を示します。本文で提案する分担の概念図です。クリックすると拡大できます。

役割	主に確かめること	次につなぐ成果
先行する少人数	何が課題か、どの解決案に価値があるか	試作品、検証結果、前提条件、未解決の課題
実用化を担う人たち	実際の利用条件で、安全かつ継続的に提供できるか	本番の仕組み、受入基準、運用手順、責任分担
業務で活用する人たち	業務の成果が改善するか、使い続けられるか	業務への組み込み、効果の評価、改善要求

企画、試作、本番化という分担自体は、以前からあります。今回の変化は、AIによって少人数が探索から実装までを広く扱えるようになり、次の人たちへ渡せる成果の具体性が変わる点にあると考えます。説明だけだった着想を、動く試作品と検証結果を伴う形で渡せるようになるのです。

ただし、これは一方向の引き継ぎではありません。探索の段階でも、扱うデータや実行権限の最低限の条件は必要です。実用化の担当者が早い段階で制約を伝えれば、試す範囲を適切に絞れます。反対に、実用化の過程で分かった課題は、着想や設計に戻して考える必要があります。

また、先行する人たちだけが事情を理解している状態では、後続は成果を引き受けられません。何を確かめたのか、何を確かめていないのか、なぜその設計にしたのかを残すことが、分担を成立させます。後続にも探索や判断に参加する機会を設け、知識と経験を組織に広げていくことが大切です。

外部サービスを使うことも、広い意味での手分けになる

同じ発想を社外に広げると、作るか買うかという判断につながります。

AIで開発しやすくなったとき、自社でもさまざまな仕組みを作りたくなるでしょう。しかし、サービス提供者も同じ変化の中にいます。自社で作ろうとしている機能が、既存のサービスやその組み合わせで実現できる場合もあります。

そのときに比べたいのは、最初の実装にかかる時間に加え、利用期間を通じて自社が引き受ける仕事です。

自社で作れば、機能の改善、障害対応、脆弱性への対応、AIモデルや外部APIの変更への追随も、自社側で体制を考える必要があります。外部サービスを使う場合には、提供者が担う範囲を確認したうえで、その継続的な開発や運用を利用できます。

GitHubのランタイム移植記事でも、複数の製品が共通のランタイムを利用し、各製品が自分たちの提供価値に集中する考え方が説明されています。[2] これは外部調達そのものの事例ではありませんが、共通部分を引き受ける主体と、それを使って価値を生む主体を分ける発想として参考になります。

私は、外部サービスの利用も、広い意味での手分けだと考えています。どの部分を自社の責任で作り続け、どの部分を他者の専門性や投資に委ねるかを決めることだからです。

調達によって、自社が注力するガバナンスを絞る

外部サービスを調達しても、利用企業の責任がなくなるわけではありません。扱うデータの範囲、利用者の権限、AIの出力を業務でどう使うかといった判断は、利用する組織の側に残ります。

ただし、サービスが必要な管理機能を備え、契約や運用条件も自社の要件を満たすなら、自前で仕組みを構築・維持する負担を抑えられる可能性があります。その分、自社の業務に固有の判断へ力をかけられます。

たとえば問い合わせ対応であれば、基盤の構築や更新の一部をサービス提供者に委ね、自社では「どの情報を回答に利用させるか」「誰に何を見せるか」「どの回答には人の確認を必要とするか」に注力する、といった分担です。

ガバナンスを整える対象は、技術の管理と業務の管理にまたがります。調達を通じて前者の一部を任せられれば、自社でしか決められない後者に、限られた人と時間を向けやすくなります。

もちろん、サービスが要件を満たさなければ、この分担は成立しません。必要な監査記録が取れるか、データを取り出せるか、終了時に移行できるかまで含めて、実際に任せられる範囲を見極める必要があります。

「作る・買う」を、経営として選び続ける

作るか買うかを考えるとき、私は次の観点をそろえることが大切だと思います。

判断の観点	確認したいこと
自社の競争力	独自に作ることが、顧客価値や業務の強みにつながるか
要件への適合	既存サービスで、業務・権限・データ管理の条件を満たせるか
継続的な負担	開発後の改善、運用、評価、障害対応を誰が担うか
総費用	開発費、利用料、AI実行費用、運用費、移行費を含めてどうか
変更への対応	自社の業務変更や提供者の仕様変更に対応できるか
業務成果	時間短縮に加え、判断の質、正確さ、利用者の体験が改善するか

実際には、全面的な内製か全面的な調達かという二択になるとは限りません。共通基盤は調達し、自社の業務に固有の部分を作る方法もあります。少人数で試して要件を理解した後に、製品を調達する選択もあるでしょう。試作の価値は、そのコードを本番に残すことだけにあるわけではありません。

AIによって作り始める負担が下がるほど、作り続ける対象の選別が重要になります。個々の現場で作れるかどうかに加え、会社としてどこに独自性を持ち、どの責任を引き受けるかを判断する必要があるからです。

先行する少人数が着想を具体化し、組織が実用化と定着を担う。共通的な機能は外部の力も使い、自社の力を注ぐ対象を選ぶ。私は、この二つの手分けを設計することが、AIで広がった可能性を継続的な業務成果へつなぐ鍵になると考えています。

参考資料

一次情報の確認日：2026年11月6日。数値は各資料の報告値です。本稿で提案した組織内の分担と内製・調達の判断枠組みは、それらを踏まえた筆者の考察です。