SE曳野の仮想デスクトップとAI / 開発内製化シリーズ 第1回
作りたいものは、現場が知っている。あなたのチームでも内製化を始めませんか?
環境・スキル・資産の3つの壁と、Windows 365 × GitHub Copilot × GitHub Enterprise

はじめに:「これ、自分たちで直せたらいいのに」
月末、いくつものファイルを開き、必要な列だけをコピーして一つの表にまとめる。終わったと思ったら、会議用の資料にも同じ数字を転記する。翌月には集計する分類が一つ増えて、また手順を直す。そんな仕事に心当たりはないでしょうか。
あるいは、新しい担当者が来るたびに、同じ操作を説明している。「この手順、短い動画にしておけたら」。申請の状況をメールで追いかけている。「一覧で確認できる小さなアプリがあれば」。何を作りたいかは、すでに現場にあります。
それでも、実際に作るところまでは進まない。開発環境を用意できない。コードが分からない。作った後に誰が面倒を見るのか決まっていない。一つずつはもっともな理由ですが、重なると「今回も手作業で」が続いてしまいます。
この3回では、その状態から最初の一歩を踏み出す方法を考えます。第1回は全体像、第2回は具体的な作り方と別の仕事への応用、第3回はチームで続けるための効果測定と役割分担です。読み終えたときに、自分の部署で最初に試す題材を一つ選べる。まずは、そこを目指しましょう。
月次レポートの「作り方」を変えてみる
最初の題材として、CSVファイルから月次レポートを作る仕事を考えてみます。以下は特定企業の導入事例ではなく、利用場面を具体化するための例です。
今は担当者が、対象月のデータを選び、部署ごとの件数を数え、分類別の内訳を作り、Excelに整えています。ここで欲しいのは、入力ファイルを選ぶと集計表を作ってくれる、小さなツールです。会社全体のシステムを作り直す必要はありません。
| 作業 | いまの進め方 | 目指す使い方 |
|---|---|---|
| 対象データの抽出 | 担当者が毎回、日付と条件を指定する | 対象月と条件を指定して処理する |
| 分類と集計 | 表計算の操作を繰り返す | 確認済みの処理で同じ集計を行う |
| 結果の確認 | 手作業の漏れや転記ミスを探す | 元データとの照合や、例外の確認に時間を使う |
| 翌月の変更 | 担当者の記憶を頼りに手順を変える | 変更理由を残し、テストしてから使う |
ここで変えたいのは、最後の行まで含めた仕事の進め方です。一度だけ集計できても、翌月の分類変更に対応できなければ、また手作業に戻ってしまいます。作れることに加えて、自分たちで直せること。それが、今回の内製化の入口です。
現場は、完成した姿を知っている
「コードが書けないので、私は開発には関係ありません」。そう感じた方もいるかもしれません。しかし、このレポートの完成条件を説明できるのは誰でしょうか。
月末の深夜に入ったデータを、当月と翌月のどちらに入れるのか。同じ受付番号が二つあるとき、二件と数えるのか。未分類の行があったら、勝手に除いてよいのか。こうした判断は、プログラミングの文法だけからは出てきません。業務を知る人が持っている知識です。
AIによる開発支援を使うと、この知識を自然言語で伝え、コードの作成や修正を支援してもらえます。最初から完璧な仕様書を書く必要はありません。小さな例を示し、「この入力なら、この結果になる」と一緒に確かめていけばよいのです。
何を作りたいかを知っている人が、作る過程にも参加できるようにする。
もちろん、専門的な設計やレビューが必要な場面はあります。だからこそ、業務を知る人と開発を知る人の席を近づける意味があります。現場の説明が具体的になれば、専門家も、どこを重点的に確認すべきか判断しやすくなります。
内製化を止める、3つの壁
では、現場の知識があるのに、なぜ始められないのでしょうか。今回は、障害を「環境」「スキル」「資産・保守」の3つに分けます。製品の公式分類ではなく、内製化に必要なものを整理するための見方です。
| 壁 | 現場で起きていること | 用意したいもの |
|---|---|---|
| 環境の壁 | 業務PCに開発ツールを入れられず、試す場所がない | 会社が管理する、開発・検証のための環境 |
| スキルの壁 | 作りたいものは説明できるが、実装方法が分からない | 実装を支援するAIと、相談・確認できる人 |
| 資産・保守の壁 | 作った人のPCにしかなく、変更理由も分からない | コード・手順・変更履歴を共有し、引き継ぐ仕組み |
AIだけを用意しても、動かす場所がなければ止まります。開発環境だけを用意しても、何をどう作るかで止まります。何とか作れても、担当者が異動したら使えなくなる。それでは、組織としての内製化には育ちません。
この3つを、同時に考える。ここで、Windows 365、GitHub Copilot、GitHub Enterpriseの役割がつながります。
Windows 365:作るための席を用意する
Windows 365 Enterprise は、ユーザーに専用のCloud PCを提供するサービスです。Microsoft Intuneで構成やアプリを管理し、Microsoft Entra IDでIDとアクセスを管理できます。ここでは、そのCloud PCを開発用の席として活用します。詳しくはWindows 365 Enterpriseの概要をご覧ください。
いつもの業務PCで開発ツールの追加が難しくても、IT部門と相談して、開発に必要なアプリを備えた環境を別に用意する。二人目、三人目にも、決めた構成を提供する。現場の担当者が、それぞれの判断で物理PCを買い、ばらばらに設定する負担を抑えられます。
図2:作る場所を、企業が管理できる席として用意する。紹介資料・スライド4のイラストより。利用者ごとのCloud PC割り当てや接続制御は実際の構成に合わせて設計します。ただし、Cloud PCを用意するだけで、社内の制限や情報管理の課題が自動的に解消するわけではありません。どのデータを使うか、どこへ接続するか、どのツールを許可するかを決める必要があります。IT部門と、試してよい場所を作る。これが環境の壁への向き合い方です。
既に管理された開発環境やAzure Virtual Desktopを利用しているなら、活かせる部分もあるでしょう。本シリーズでは、共通の説明の土台としてWindows 365 Enterpriseを取り上げます。
GitHub Copilot:現場の言葉を、作る作業につなげる
次に、その席で作業を助けるのがGitHub Copilotです。たとえばVisual Studio Codeで、「このCSVを部署別に集計したい」と依頼し、コードの提案や修正の支援を受ける。エージェント機能では、利用できるツールと権限の範囲でファイルの編集やコマンドの実行、結果の確認へ進めます。操作の詳細はVisual Studio Codeの公式ドキュメントで確認できます。
担当者は、最初の結果を見て「この分類は別に集計したい」「該当データがなければ、そのことを表示してほしい」と伝えます。会話と確認を繰り返すことで、頭の中にあった業務の条件を、動くものへ近づけていきます。
自然言語で意図を伝えながら作るスタイルを、バイブコーディングと呼ぶこともあります。ただ、本シリーズで大切にしたいのは、動いた結果を、自分たちの業務の正解と照らし合わせることです。AIがもっともらしいコードを書いたことと、現場で安心して使えることは、別々に確かめます。
GitHub:作ったものを、チームの資産にする
最後は、できたものを置く場所です。作成者のPCだけに保存されているツールは、その人が休むと直せなくなりがちです。そこで、コードや説明書をGitHubのリポジトリに置きます。リポジトリとは、ファイルと変更履歴をまとめて管理する場所です。
「いつ、誰が、何を変えたか」に加え、「なぜ変えたか」を残す。変更するときは、ほかの人に確認してもらう。翌月の担当者は、コードと一緒に、この経緯を受け取れます。
GitHub Enterprise は、こうした共同作業を企業として管理する選択肢です。たとえばGitHub Enterprise Cloudでは、複数の組織を企業アカウントから管理できます。コードの共有や変更提案そのものはGitHubの基本的な仕組みであり、すべてがEnterpriseだけの機能というわけではありません。必要な管理機能とプランを合わせて選びます。GitHub Enterprise Cloudの概要に、主な違いが整理されています。
会社が管理する環境で、開発と検証を進める。
作る支援:GitHub Copilot
現場の意図を伝え、コードの作成・修正を支援してもらう。
残して直す仕組み:GitHub Enterprise
コードと変更理由を共有し、確認しながら育てる。
作る対象は、アプリだけではない
ここで、一度視野を広げてみましょう。月次レポートを作るために整理したデータは、会議用のPowerPointにも使えます。ツールの使い方を説明する台本は、短い動画にもできます。毎月同じ入力をしているなら、入力画面を持つアプリへ発展させることも考えられます。
たとえば、資料を生成するプログラムや、動画を構成するコードをAIに支援してもらい、それぞれの制作ツールでファイルにする進め方です。最終的に使うものは、コードではなく、資料や動画でも構いません。
必要な制作ソフトウェア、ライブラリー、素材、ライセンスは用途ごとに異なります。3製品を入れればすべてを直接生成できる、という話ではありません。しかし、目的を伝え、試作を確認し、直して使うという進め方には共通点があります。次回は、この応用の仕方も具体的に見ていきます。
「早い・安い・巧い」を、自分たちの数字で確かめる
内製化に期待することを、短く言えば「早い・安い・巧い」かもしれません。ここは、期待を実際の結果と照らし合わせたいところです。
早いは、試作品ができるまでだけでなく、業務で使えるまでを測ります。安いは、外注費とライセンス代だけの比較で終わらせず、社内の制作・確認・教育・保守も含めます。巧いは、見た目のよさに加えて、正しく動き、別の人にも引き継げるかを確かめます。
たとえば、毎月の集計時間が減っても、誤集計の確認にそれ以上の時間がかかるなら、まだ改善の途中です。一方、金額の差が小さくても、現場が必要な変更をすぐ試せることに価値がある場合もあります。何を成果とするかを、先に決めておきましょう。
得られる自由と一緒に、引き受ける仕事も増えます。その両方を見えるようにすることで、「便利そう」で終わらない、続けられる内製化になります。
まとめ:最初に変えたい仕事を、一つ選ぶ
最初から、会社中の仕組みを作り直す必要はありません。毎回繰り返していて、結果の正しさを確認でき、失敗しても元の方法へ戻せる。そんな仕事を一つ選んでみてください。
月次レポートでも、説明資料でも、作業手順の動画でも構いません。そして、その横に「作る人」「確かめる人」「使い続けるための担当者」を書いてみる。これが、内製化を始めるための最初の座席表です。
作りたいものは、現場が知っている。その知識を、最初の一つにしてみましょう。
次回は、月次レポート用のツールを題材に、依頼から検証・共有までをたどります。さらに、同じ進め方をPowerPoint、動画、業務アプリへどう応用できるのかをお話しします。実際に手を動かす「開発内製化体験会」についても、このシリーズの最後にご案内します。
参考リンク(Microsoft Learn・公式ドキュメント)
- Microsoft Learn:Windows 365 Enterpriseの概要
- Microsoft Learn:Cloud PCのプロビジョニング
- Visual Studio Code:Use tools with agents
- GitHub:GitHub Enterprise Cloudの概要
本記事は情報提供を目的としています。利用例は説明のための想定であり、導入効果を保証するものではありません。製品・サービスの機能、提供条件、ライセンスは変更される場合があります。© Microsoft 2026. All rights reserved.
Join the conversation