C# で AI ワークスペースを業務向けに拡張する設計メモ

Posted at 2026-03-26

📚 Copilot Cowork 開発シリーズ

今回は、Copilot Cowork の C# 拡張について書きます。

ただし、最初に一点はっきりさせます。2026 年 3 月 11 日時点で、.NET worker 自体はまだ未実装です。

📋 この記事の前提

C# / .NET の基本文法がわかる
Copilot Cowork の構成を知っている（前回記事で解説）
「AI アプリに C# の業務ロジックをどう組み込むか」の設計判断に興味がある方向け
実装コードではなく設計メモとして読んでください

いま動いているのは、Electron + React + GitHub Copilot SDK を使った UI とセッション基盤です。この記事は「C# の文書生成スキルを実装した報告」ではなく、なぜ C# を後段に置くのか、どこをどう切り出すかの設計メモです。

未実装のものを未実装のまま書くのは遠回りに見えるかもしれません。ただ、製造業寄りの業務機能は後から雑に継ぎ足すと壊れやすいので、先に境界を固めておきたいと考えています。

まず前提: C# は agent runtime の代わりではない

ここが一番大事です。

Copilot Cowork の設計では、C# は Copilot SDK の代替ではありません。役割分担は次の通りです。

層	役割	技術
AI orchestration	セッション、推論、tool 呼び出し、permission	GitHub Copilot SDK
デスクトップ UX	chat、settings、trace、永続化	Electron + React + TypeScript
業務向け custom tool	文書生成、データ処理、計測器連携	.NET / C#

つまり、C# は AI の頭脳ではなく、成果物を安定して作る backend として使います。

この方が自然です。

会話や planning は Copilot が得意
PowerPoint や Excel の厳密な出力は C# が得意
既存 Windows 資産との接続も C# が得意

無理に 1 つの言語に寄せるより、得意な場所に配置した方が全体の設計がきれいになります。

なぜ C# なのか

私が C# を選ぶ理由は、単に得意だからではありません。やりたいことに対して、かなり素直に刺さるからです。

1. Office 文書の取り回しが安定している

製造業の現場では、最終成果物が

PowerPoint
Excel
Word
PDF

になることが珍しくありません。

AI に「それっぽい文章」を書かせるだけでは足りず、最終的には社内でそのまま使えるファイルが必要です。

そのとき、C# には次の選択肢があります。

DocumentFormat.OpenXml
ClosedXML
QuestPDF

このあたりは、後段の deterministic な処理に向いています。

2. Windows 資産との距離が近い

将来的にやりたいのは、文書生成だけではありません。

既存 WinForms / WPF アプリとの連携
計測器制御
CSV や試験データの整形

この領域は、C# を持っていると選択肢がかなり増えます。

3. 最終出力を AI に丸投げしなくて済む

私はここをかなり重要視しています。

AI には、

何を出すか
どんな構成にするか
どのデータを使うか

を考えてもらう。

一方で、

ファイル形式の整合性
セル位置やスライド構成
テンプレートへの埋め込み

は、C# 側で deterministic に作る。

この分担の方が、再現性が高いです。

どういう形で接続するか

現時点で考えている接続は、Node 側の custom tool registry から .NET worker を呼ぶ構成です。

Copilot SDK
  ↓ tool call
Node custom tool registry
  ↓ stdio / JSON-RPC
.NET worker
  ↓
PPTX / XLSX / DOCX / PDF / 将来の計測器連携

ここで Named Pipes ではなく、まず stdio + JSON-RPC を想定しています。

理由は単純で、最初の一歩として扱いやすいからです。

単一プロセスの spawn で始められる
packaging を考えると境界が分かりやすい
リクエスト、レスポンス、エラーを JSON で揃えやすい

あとから高機能化が必要になれば見直しますが、Phase 1 から Phase 2 にかけてはこれで十分だと見ています。

Node 側に持たせる責務

Node 側は「C# を呼ぶだけ」にしません。ここは中継点というより、Copilot runtime と業務ツールの境界管理を担う場所です。

持たせたい責務は次の通りです。

tool 定義の登録
入力 schema の検証
workspace path の正規化
permission / audit の制御
.NET worker の起動と終了管理
C# 側エラーの UI 向け整形

つまり、Copilot から見えるのは Node 側の tool であり、C# はその裏側の実行 backend です。

この構造なら、将来的に

一部は TypeScript のまま実装する
一部だけ C# に逃がす

という分け方もしやすくなります。

C# worker 側に持たせる責務

C# 側では、できるだけ「結果を安定して返す処理」に寄せます。

たとえば初期段階で想定しているのは、こんな tool です。

tool 名	役割	まず欲しい理由
generate_pptx_report	PowerPoint の下書き生成	社内説明やレビュー資料に直結する
generate_xlsx_summary	Excel 集計表の生成	試験データや集計の自動化に使いやすい
generate_docx_report	報告書のベース作成	文書テンプレート化しやすい
generate_pdf_handout	配布用 PDF の出力	最終成果物として扱いやすい

インターフェースのイメージは、たとえば次のような形です。

public sealed record ToolRequest(
    string RequestId,
    string ToolName,
    string WorkspacePath,
    JsonElement Input
);

public sealed record ToolResponse(
    string RequestId,
    bool Success,
    string Message,
    string? OutputPath
);

ここでは AI 的な曖昧さを減らして、

入力を受ける
検証する
ファイルを生成する
結果パスを返す

という deterministic な処理に寄せたいです。

文書生成で特に大事だと思っていること

PowerPoint や Excel は、単にファイルが生成できれば終わりではありません。

私が重要だと思っているのは、次の 3 点です。

1. テンプレート前提にすること

LLM に見た目まで丸投げするより、社内テンプレートや自分の定型を前提にした方が安定します。

AI は「中身の素案」を考える。
レイアウトや章立ての型はテンプレートで固定する。

この方が使い回しやすいです。

2. 出力前に検証を入れること

たとえば Excel なら、

必須列がそろっているか
数値が正しく入っているか
参照式が壊れていないか

を確認したいです。

PDF や Word でも、空欄や文字数超過を検出したい。

こういう検証は、AI 本体より C# 側でやる方が筋がいいです。

3. 最終成果物のパスを返すだけで終わらないこと

最終的には、

どこに生成したか
どのテンプレートを使ったか
何件のデータを処理したか

まで返したいです。

trace や監査の観点でも、生成結果のメタ情報は残した方が後で助かります。

製造業の業務とどうつながるか

この設計は、単なる「AI で Office 文書を作る話」ではありません。

私が見ているのは、次のような流れです。

調査、整理、下書きは Copilot 側に寄せる
文書や表の出力は C# 側で安定生成する
将来的に試験データや計測器の情報までつなぐ

つまり、AI をチャットの中だけで終わらせず、現場の成果物までつなぐための設計です。

ここに C# を入れる意味があります。

実装の優先順位

今のところ、実装順はこう考えています。

.NET worker の最小 scaffold を作る
Node 側から 1 tool だけ呼べるようにする
PPTX か XLSX のどちらかを最初の成功例にする
trace と error surface を整える
その後に DOCX、PDF、CSV 処理へ広げる

計測器制御や既存アプリ連携は、その後です。いきなり重いものへ行くより、まずは文書生成の 1 本線を通した方が全体の品質を上げやすいと考えています。

まとめ

C# は Copilot SDK の代替ではなく、業務向け custom tool backend として使う
AI は構成や判断、C# は deterministic な成果物生成を担当する
接続はまず stdio + JSON-RPC を想定している
最初の対象は PPTX、XLSX、DOCX、PDF などの文書生成
将来的には計測器制御や既存 Windows 資産との連携まで広げる

次は、この設計を実際の worker scaffold に落とし込む段階です。実装できたら、設計メモではなく実コードベースで続きを書きます。

よくある質問

Q: C# でなく Python でも同じことはできますか？

A: Python でも文書生成ライブラリ（python-pptx、openpyxl 等）はあります。ただし、既存の Windows アプリ（WinForms/WPF）との連携や COM 経由の Excel 操作など、Windows 環境に深く入り込む処理では C# / .NET の方が自然です。著者の実務経験が C# にあることも選定理由の一つです。

Q: .NET worker との接続方式は stdio 以外に何がありますか？

A: Named Pipes、gRPC、HTTP（localhost）などが候補です。ただし Phase 1 では spawn + stdio + JSON-RPC が最もシンプルで、パッケージングの境界も分かりやすいため、まずこれで始めます。

Q: まだ未実装の段階で設計記事を書く意味はありますか？

A: あります。製造業寄りの業務機能は後から雑に継ぎ足すと壊れやすいため、先に境界を言語化しておくことで実装時の迷いが減ります。また、設計判断の記録は実装後に「なぜこうしたか」を振り返る材料にもなります。

この記事が参考になったら「いいね」で応援お願いします！
C# 拡張は派手さよりも「実務で壊れにくい境界」を優先して進めていきます。

📝 この記事は Zenn で最初に公開されました。
最新版はZennをご覧ください。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up