概要
Microsoftが、仕事を代わりに進めるAI「Copilot Cowork」の作り方を公開しました。
コードの大半はAIが書きました。人間のエンジニアは9人です。
その9人が、10月21日の1日だけで1,211件の変更を本流に取り込みました。記事では、速さを保ちながら安全性とコストも守るための6つの実践が語られています。
開発チームや、AIに仕事を任せたい管理職の人に参考になる内容です。
何が発表された？
Microsoft Source（ニュースルーム）は、Copilot Cowork開発の振り返り記事を公開しました。書き手はパートナーソフトウェアエンジニアのBas Brekelmans氏です。
Copilot Coworkは、利用者の代わりに複数の手順にまたがる作業を進める仕組みです。元記事では「agentic execution layer」と呼ばれています。
開発は2026年1月に始まりました。最初のコミットは1月13日です。3月30日にはFrontierプログラムで、最初の大企業顧客に提供しました。6月16日に世界一般提供（GA）に到達しています。最初のコミットから約4か月半です。
提供開始時点で、複数のモデルと16個のプラグインを備えていました。
これは新製品の発表ではありません。すでに一般提供された製品の、開発手法の解説記事です。元記事の後半には、稼働中にPythonからRustへ実行基盤を移した事例が置かれています。ただし、今回確認できた本文の抜粋はその手前で終わっています。
前と何が違う？
コードを書く前に、仕様書を先に書く
チームは最初の数週間で、AIが遅さの原因ではないと気づきました。ボトルネックは、自分たちが何を作りたいかを正確に決めていないことでした。
あいまいな依頼からは、一見まともに見えて間違った動きをするコードが出てきます。直す手間は、依頼を丁寧に書く手間より大きくなりました。
そこで「markdownの仕様書がなければコードを書かない」という規則を作りました。仕様書には3点を書きます。
- その変更が何をするか
- 動いたとどう確認するか
- 何を壊してはいけないか
多くの仕様書は、まず誰かが口で話すところから始まります。AIがそれを下書きにし、人間が直します。Brekelmans氏は、この方法がどのモデル更新よりも速度に効いたと見ています。
AIを細かい仕事に分けて、同時に走らせる
次の段階は、複数のAIを同時に動かすことでした。AIはそれぞれ、リポジトリ（作業用のコピー）を別に持ち、1つの仕様書から1つの作業をします。1台が5台になり、数十台になりました。
月ごとの本流への取り込み数は、1月の257件から5月の2,754件に増えました。GA前でいちばん忙しかった週は783件です。
うまくいった理由として、2点が挙げられています。1つは、1つの明確な仕事だけを任せるとミスが減ることです。もう1つは、仕事ごとにモデルを選ぶことです。難しい作業には推論の強いモデルを使います。そうでない作業には、速くて安いモデルを使いました。
AIには鍵を持たせず、権限は外の「ホスト」が握る
Copilot Coworkでは、モデルはユーザーの認証情報を持たないコンテナ（隔離された実行環境）の中で動きます。外にある信頼されたホストが、本人確認、ポリシー、承認、ツールを扱います。Microsoft 365への操作はすべてホストを通ります。
編集部の見方では、会社の金庫に例えると分かりやすい設計です。AIは「あれを出して」と頼めますが、金庫を開けるかどうかは受付が決めます。
この分離のおかげで、AIの数を増やしても、AIに直接の権限を渡さずに済みました。さらに、AIとホストは決まった窓口でしか話しません。そのため後から、AIを変えずにホスト全体を入れ替えられました。それがRust移行で実際に役立っています。
検査役のAIを競わせ、「検査したか」を検査する
9人では全変更を読み切れず、人間のレビュー待ちが最も遅い工程になりました。そこで複数のエンジニアが、自分のレビューのやり方を写したレビュー用のAIを作りました。
あるAIが見逃した問題を別のAIが見つけると、見逃したほうに新しいルールを足します。各レビューAIは、少なくとも10,000世代の改善を経ています。最近マージされた変更の見本では、最初の有用なレビューが届くまでの中央値は約4分半でした。
その後に、より遅くて専門的な検査が続きます。
- 呼び出し関係をたどり、つながっていないコードと、変更を戻しても通るテストを探す
- 再起動の安全性、指標、古くなった文書を調べる
- 変更されたファイルを端から端まで読む
- 置き換え前のコードと動きを比べる
AIの検査にも見逃しはあります。最も繊細な部分の変更を、「壊すつもりで読め」と指示した複数のAIが読んでも、問題は見つかりませんでした。同じ差分を人間が読むと、マージ前に直すべき問題が4件見つかりました。
そこで、AIレビューは最初の関門にとどめました。重要な変更には、少なくとも1人の人間の確認を足しました。指摘も2段階に分けています。
- ブロッキング：正しさ、安全性、データ消失、壊れても気づけない新しい仕組み
- アドバイザリー：それ以外。直すか返信すればよく、再レビューは必要ない
もう1つの教訓は、失敗しない検査でした。AIが読む指示ファイルの大きさには上限があり、1バイトごとにトークン（AIが文字を数える単位）の費用がかかります。上限を超えたのに、検査はずっと合格のままでした。出力をtailに渡していたため、パイプラインの終了コードがtailのものになっていたからです。
ほかにも、空のファイル一覧を渡されて何も調べずに合格した書式検査がありました。コミット直後にファイル一覧が空になる例もありました。
そこで、2つの規則を作りました。
- すべての検査は、調べたファイル数を報告する
- 新しい検査には、わざと失敗させるテストを付ける
Brekelmans氏は、AIが相手だとこれはいっそう重要だと見ています。AIは検査に通るまで作業を続けるので、何も調べずに通れる道があれば、いずれ見つけるからです。
学んだことをリポジトリに置き、ぶつからない構造にする
8月になると、同じ間違いが繰り返されました。AIは前の作業の記憶を持たないためです。チームは、ルールをリポジトリに移しました。ルートと各コンポーネントに指示ファイルを置き、話題別のルールファイルのフォルダも作りました。
AIは作業開始時に、関連するファイルを読みます。問題が起きると、直す際に新しいルールも足します。現在のルールファイルは約30個で、最古は8月6日付です。
衝突（コンフリクト）への対策も変えました。1日数百件のマージがあり、衝突の大半は、本物のロジックではなく、全員が1行ずつ足すファイルで起きていました。そこで人に注意を求めず、ファイルの形を変えました。
- 登録簿は、長い一覧ではなく1項目1ファイルにする
- 生成ファイルは、マージ後に再生成し、手でマージしない
- 日付や件数のように毎回変わる値は、コミットしない
Rustのコードでも問題が出ました。AIは書きやすい場所に置くので、最大のcrate（Rustの部品の単位）に集まります。一時は主要な実行バイナリが約29万行になりました。8月20日の棚卸しでは、次の状態でした。
- crateは86個で、依存の連鎖は13段
- 共通の土台crateを変えると、63個中43個が再ビルドになる
- APIのcrateは13万4,000行に膨らみ、すべての接続も担っていた
- 約1万2,000行の業務ロジックが、バイナリ本体に置かれていた
対策は、役割の厳格な規則でした。crateを「契約（型と窓口）」「キット（依存のない共通部品）」「実装」「バイナリ」の4種に分けます。実装は契約とキットには依存できますが、別の実装には依存できません。実装同士で必要なやり取りは契約を通します。新しいコードに例外は認めません。過去の例外が次の例外の理由になったからです。
整理作業は、401個の作業項目と2,225個の依存関係として運用しました。ピーク時は40〜44個が同時に着手可能でした。同じファイルに触れない束にまとめ、並列のAIが衝突しないようにしています。
数字で見るとどう変わった？
元記事が示した数字は、前後で比べられる形ではないため、一覧にします。
- 月ごとの取り込み数：1月は257件、5月は2,754件
- GA前でいちばん忙しい週：783件
- 10月21日：9人で1,211件
- 最初のレビューが届くまでの中央値：約4分半（最近の見本）
- レビューAIの改善：各10,000世代以上
- ルールファイル：約30個
- 整理作業：401項目、依存2,225個
Rust移行の実施期間は、図の注記によると9月23日〜10月10日です。ただ、移行後の性能などの数字は、確認できた本文には含まれていません。
ライバルと比べてどう？
元記事は他社との比較をしておらず、比べる材料も示していません。
（編集部注）AIにコードを書かせる開発手法そのものは、各社が取り組んでいます。サイソクでは、GitHubが自然言語の指示でAIが作業するAgentic Workflowsを一般提供したと報じました。ただ、この記事はMicrosoft自身の開発事例です。製品の性能を競合と比べた資料ではありません。
編集部の見方では、読みどころは数字の大きさより、AIを信用しすぎない設計です。AIは提案でき、許可は決められないという線引きが、ほかの製品でも参考になります。
日本で使える？
Copilot Coworkが日本で使えるかは、元記事に書かれていません。
Microsoft 365 Copilot自体は、日本で使えます。日本マイクロソフトの公式ページがあり、円建てで販売されています（当サイトの確認：11/3）。ただし、今回のCoworkがそのまま日本で使えるとは限りません。
- 自社でMicrosoft 365 Copilotを契約しているか、管理者に確認する
- CoworkがいつからどのプランでOnになるか、公式ページで確認する
- 日本語対応の有無は、元記事に書かれていません
自分にはどう関係する？
会社員として
開発に携わる人は、仕様書を先に書く規則がすぐ試せます。内容は、何をするか、どう確認するか、何を壊さないかの3点です。
AIのレビューは、人間の確認の代わりにはならなかったと、チーム自身が書いています。重要な変更には人の確認を残す、という線引きは職場でも使えます。
副業・独立を考えている人
直接の影響は小さいと考えます。ただ、1人でAIに作業を任せる人にも、仕様を先に書く点と、検査が本当に動いたかを確かめる点は応用できます。
お金・資産づくりの面で
この立場への直接の影響は小さいです。元記事は開発手法の話で、収益や株価に関する情報はありません。
これまでの流れ
- 10月5日：Microsoft 365 Copilotの新機能Coworkと、常時稼働型エージェントScoutを発表（CoworkとScoutの発表）
- 10月28日：営業や法務など4つの職種向けスキルと、外部アプリ連携が追加された（Coworkの新スキル）
- 11月3日：Microsoftが、Cowork開発の6つの実践と、AIによる大量開発の実態を公開した
これまでは機能の紹介が中心でした。今回は、作る側の工夫が初めて詳しく示されました。
まとめ
編集部としては、次の点が気になります。元記事の抜粋はRust移行の本題の手前で終わっています。移行の結果は、公式の全文で確かめたいところです。
期待しすぎない方がいい点もあります。1,211件という数は、各チームの目標にはなりません。記事自身も「回答ではない」と断っています。
まずは、仕様書を先に書く運用と、検査が調べた数を表示する運用を、小さく試してみてください。
