GitHub Copilotのドキュメント生成｜/docが出ない原因とdocstring・READMEの作り方【2026年10月】

GitHub Copilot に docstring や README を書かせようとして、チャット欄に /doc と打っても候補に出てこない。2026年10月時点の VS Code（1.143）でまず確かめたいのは、チャットビューに打っていないか、Ctrl+I がチャットビューへ送られていないか、古い解説の @workspace /doc をなぞっていないか、の3点です。この記事では、2026年10月21日更新の VS Code 公式ドキュメントに沿って、関数単位の docstring とプロジェクト単位の文書の作り方を分け、書式と手順をリポジトリに保存する方法、Copilot に任せない文書の線引きまでを示します。

まとめ：文書の粒度に応じた入口の選び方

docstring のように関数・クラス1つに付く文書は、エディタの右クリック［Generate Code］＞［Generate Docs］か、インラインチャットの /doc で作ります。README や設計メモのように複数ファイルを読む文書は、チャットビューで Ask か Agent に頼みます。/doc はチャットビューでは動きません。

書式の揺れは毎回のプロンプトではなく、applyTo 付きの .instructions.md で抑えます。README の生成手順を使い回すなら、プロンプトファイルではなく skill にしてください。既定の Copilot ハーネスではプロンプトファイルが動かないためです。外部に提出する仕様書や API 契約書の最終版は、生成物のまま確定させないでください。

VS Codeでのdocstring生成の2つの入口

2026年10月時点の VS Code では、Copilot Chat は組み込みの機能で、拡張機能を探してインストールする手順はありません。初期設定がまだならVS CodeでGitHub Copilotを使うには？導入手順・使い方・料金を解説【2026年10月版】で済ませてから進めてください。docstring の入口は、プロンプトを書かない右クリックと、指示を足せるインラインチャットの2つです。

右クリックのGenerate Docsによる生成

VS Code 公式のスマートアクションのドキュメントは、文書生成を次の手順で案内しています。プロンプトを書く必要がないので、最初に試すならこちらです。

1. 対象のコードファイルを開きます。
2. 文書化したい関数やクラスを選択します（選択は任意）。
3. 右クリックして［Generate Code］＞［Generate Docs］を選びます。
4. インラインに出た差分を確認し、［Keep］で反映、［Undo］で破棄します。

公式の手順に添えられた画像の説明は「Inline chat /doc example」です。古い解説の［Copilot］＞［ドキュメントの生成］は、現行の英語UIでは［Generate Code］配下にあります。

インラインチャットの/docによる生成

書式や言語を指定したいときはインラインチャットを開きます。VS Code の AI機能チートシートは /doc を「Generate documentation comments from editor inline chat.」と定義しており、実行場所はエディタのインラインチャットに限られます。

1. 対象の関数・クラスを選択します。
2. Ctrl+I（macOS は Cmd+I）でインラインチャットを開きます。
3. /doc Googleスタイルで、説明文は日本語で のように、コマンドの後ろに条件を書いて送ります。
4. 差分を確認して［Keep］か［Undo］を選びます。

公式はインラインチャットを見えているコードへの限定的な編集向けとし、複数ファイルの作業にはチャットビューを勧めています。対象が数ファイルを超えたら、後述の Plan と Agent に切り替えてください。

/docが出ない・使えないときの3つの原因

/doc は VS Code の現行チートシートに載っており、廃止されていません。使えないときは、次の3点を上から順に確かめてください。

チャットビューへの/doc入力

サイドバーのチャットビューで / を打っても /doc は候補に出ません。インラインチャット専用のコマンドだからです。紛らわしいのは、GitHub 側のCopilot Chat チートシートが IDE ごとに別の一覧を載せていることです。VS Code 欄に並ぶのは /clear、/explain、/fix、/fixTestFailure、/help、/new、/tests の7個で、/doc はありません。

GitHub 側の一覧はチャットビューで使うコマンドを基準にしているので、インラインチャット専用の /doc は VS Code 欄から構造的に落ちます。VS Code で使えるかどうかは、VS Code 側のチートシートで確かめてください。Visual Studio や Xcode 向けの手順を VS Code に当てはめているケースもあり、IDE ごとの違いは後の章で整理します。

編集中のファイルでのCtrl+IのAsk in Chat切り替え

インラインチャットを開いたつもりがチャットビューに入力欄が出る場合は、この仕様に当たっています。インラインチャットの公式ドキュメントによると、エージェントが編集中のファイル（アクティブなチャット編集セッションに属するファイル）で Ctrl+I を押すと、通常のインラインチャットではなくチャットビューの「Ask in Chat」が開きます。右クリックメニューも［Open Inline Chat］が［Ask in Chat］に置き換わります。

この挙動は設定 inlineChat.askInChat で決まり、公式は false にすると常に通常のインラインチャットが開くと案内しています。Agent に README を書かせている最中に、同じセッションで触ったファイルへ /doc を当てようとすると入口が消えたように見えます。セッションを終えてから開き直すか、次の設定で常に通常のインラインチャットを開くようにします。

// settings.json
{
  "inlineChat.askInChat": false
}

@workspace /docの旧手順と現行ハーネスの違い

2024〜2025年の解説や Microsoft Learn の一部の演習には、@workspace /doc や /explain #codebase を使う手順が残っています。VS Code 1.143 のリリースノート（2026-10-21）のとおり、新しいセッションの既定は Copilot ハーネスになりました。チートシートは @workspace などのチャット参加者を「deprecated」とし、Copilot ハーネスでは使えないと明記しています。#codebase も、現行の Local ハーネスでは #search/codebase という名前です。Copilot ハーネスでは、エージェントが検索ツールを自分で選んでワークスペースを調べるため、ツール名を書く必要はありません。古い手順は、チャット参加者やツール名を外して依頼内容をそのまま書く形に読み替え、/doc だけはインラインチャットで実行してください。

Visual Studio・JetBrains・Xcodeのドキュメント生成機能

同じ GitHub Copilot でも、ドキュメント生成の入口は IDE ごとに違います。GitHub の Chat チートシートと IDE 別の手順ページで確かめた内容は次のとおりです。

Visual Studioの///入力によるコメント提案

Visual Studio には、コメントの開始記号を打つと Copilot が説明文を提案する機能があります。GitHub Docs の Visual Studio 向け手順では、対象は C# と C++、対応は Visual Studio 17.14 Preview 2 以降です。C# の場合は次の2か所を設定します。

1. Tools ＞ Options ＞ Languages ＞ C# ＞ More Settings ＞ Advanced の Comments で「Generate XML documentation comments for ///」をオンにします。
2. 同じ Options の GitHub ＞ Copilot ＞ Editor で「Enable AI generated descriptions for auto-inserted documentation comments in supported languages」をオンにします。
3. メソッドの直前で /// と打ち、提案を Tab で受け入れます（Alt+/ で修正、Esc で破棄）。

C++ は Text Editor ＞ C++ ＞ Code Style ＞ General の Comments で「Xml Doc Comments」を選んでから同じ Copilot の設定をオンにします。Copilot Free の利用者の場合、このコメント提案はコード補完ではなくチャットの月間利用量に数えられる点に注意してください。

JetBrains IDEとXcodeでの生成手順

JetBrains IDE の Copilot プラグイン（JetBrains Marketplace の更新一覧で2026年10月26日に確認した最新版は 1.19.2）は、GitHub のチートシートに /doc が載っていません。エディタで対象を選び、右クリックの［GitHub Copilot］＞［Copilot: Inline Chat］か Ctrl+Shift+I でインラインチャットを開き、「この関数に KDoc を付けて」のように依頼します。Xcode はチートシートに /doc（Generate documentation for this symbol.）があるので、対象のシンボルを選んでチャットで実行します。

READMEとプロジェクト文書のチャットでの生成

README、セットアップ手順、ディレクトリ構成の説明は、複数ファイルを読まないと書けません。こうした文書はインラインチャットではなくチャットビューに頼みます。Microsoft の公式トレーニング「Generate project documentation using GitHub Copilot」も、プロジェクト文書はチャットビューの Ask・Plan・Agent のいずれかで作るものとして手順を分けています。

Ask・Plan・Agentの使い分け

判断の基準は「生成物をファイルに書き込ませるか」です。README のように1ファイルで済み、内容を見てから置きたい文書は Ask で下書きを受け取り、自分で README.md に貼ります。数十ファイルに docstring を付けるなら、先に Plan で対象ファイルの一覧と手順を出させ、確認してから［Start Implementation］で Agent に渡します。Microsoft Learn のインラインコード文書の演習（unit 6）もこの順序で、Agent に「JSON や Markdown には付けない」「テストプロジェクトは除く」「付与後にビルドが通ること」と除外条件と完了条件を書かせています。

費用の面でも差があります。Copilot は2026年6月1日にリクエスト数ベースから使用量ベースの課金へ移り、使ったモデルとトークン量を AI Credits（1クレジット＝0.01米ドル）に換算して数えます。コード補完は AI Credits の対象外です。Agent は計画・読み込み・編集・検証を繰り返す分だけトークンを使うので、README 1本なら Ask で足ります。

Agent は1回の依頼で多くのファイルに差分を出すので、レビューの単位を先に決めておいてください。確認では、引数・戻り値・例外の記述が実装と合っているかを関数ごとに照合し、合わないものはその差分だけ戻します。モードごとの承認設定と料金の扱いはGitHub Copilotエージェントモードの使い方｜Ask・Plan・Agentの違いと承認設定・料金で扱っています。

README生成時の参照ファイルの指定

Ask で README を頼むときは、何を根拠に書くかをプロンプトに含めます。VS Code の Tools and context reference は、掲載している #search/codebase などのツール名は Local ハーネス用で、Copilot ハーネスのツールにそのまま対応すると考えないよう注記しています。ハーネスに依存しないのは、# に続けてファイル名やフォルダー名を選ぶ添付か、［Add Context］での添付です。依頼文は次のように、章立てと参照先を指定すると手直しが減ります。

ワークスペースのコードを調べて、README.md の下書きを Markdown で作ってください。
章立て: 概要 / 必要環境 / インストール / 使い方 / 設定項目 / ライセンス
- 必要環境のバージョンは package.json と .nvmrc から読み取る
- 設定項目は src/config.ts の型定義に載っているものだけを書く
- コードから読み取れない内容（連絡先・貢献ルール）は「TODO」と書く

最後の1行が効きます。連絡先や貢献ルールのようにコードに無い情報を指定しないと、もっともらしい文が埋まります。Microsoft Learn の演習も、Contributing・Credits・Contact の章はワークスペースだけでは足りず、別のファイルをコンテキストに足す必要があるとしています。

文書の書式と生成手順のリポジトリへの保存

毎回「Google スタイルで」「日本語で」と書き足す運用は続きません。書式は指示ファイルに、手順は skill に置きます。指示ファイル全般の書き方はcopilot-instructions.mdとは？書き方とサンプル・配置場所、AGENTS.mdとの違い【2026年10月】で扱っており、ここではドキュメント生成で使う部分に絞ります。

.instructions.mdによるdocstringの書式指定

VS Code のカスタム指示のドキュメントは、.instructions.md の用途の1つに「テストファイルやドキュメント向けの専用ルール」を挙げています。applyTo の glob に一致するファイルをエージェントが作成・変更するとき、自動で添付されます。Python と TypeScript で規約が違うリポジトリなら、ファイルを分けます。次の内容を .github/instructions/python-docstring.instructions.md として保存します。

---
description: 'Use when writing or updating Python docstrings.'
applyTo: '**/*.py'
---
- docstring は Google スタイル（Args / Returns / Raises）で書く。
- 説明文は日本語、引数名・型名・例外名は英語のまま書く。
- 実装から読み取れない性質（スレッド安全性、計算量、None を返す条件）は推測で書かない。
- 既存の docstring は、依頼がない限り書き換えない。

注意点が2つあります。まず、公式は入力中のインライン補完（ゴーストテキスト）には指示ファイルが使われないと明記しています。次に、インラインチャットの /doc に applyTo がどう効くかは公式に書かれていません。書式を厳密に揃えたい一括作業は、自動添付が明記されているチャットビューの Agent で行う方が確実です。

README生成用skillの作成と/create-readmeでの呼び出し

GitHub Docs には、.github/prompts/create-readme.prompt.md を置いてチャットで /create-readme と打つ例が載っています。ただし VS Code のプロンプトファイルのドキュメントは、プロンプトファイルが動くのは Local ハーネスのセッションだけで、ほかのハーネスでは skill を作るか変換するよう書いています。既定が Copilot ハーネスになった今は、最初から skill で作る方が手戻りがありません。次の内容を .github/skills/create-readme/SKILL.md として保存します。

---
name: create-readme
description: Create or update README.md from the code in this repository. Use when asked to write, refresh, or restructure the README.
---
1. package.json、pyproject.toml、Dockerfile を読み、必要環境とインストール手順を確定する。
2. 章立ては 概要 / 必要環境 / インストール / 使い方 / 設定項目 / ライセンス とする。
3. コマンド例は package.json の scripts、Makefile、pyproject.toml、Dockerfile など、リポジトリ内で確認できるものだけを使う。
4. コードから確定できない項目は「TODO」と書き、推測で埋めない。

skill のドキュメントによると、name は小文字・数字・ハイフンだけで親ディレクトリ名と一致させる必要があり、使えない文字を含むと読み込みが黙って失敗します。description は最大1,024文字で、「何をするか」と「いつ使うか」の両方を書くとエージェントが関連する依頼で自動的に読み込みます。手動でだけ呼びたいなら disable-model-invocation: true を足します。skill は Copilot CLI や Copilot cloud agent でも同じファイルが使えます。

awesome-copilotの文書系skillを使うときの確認点

一から書く前に、GitHub の github/awesome-copilot を見ると文書生成向けの skill がそろっています。create-readme、readme-blueprint-generator、C# の XML コメントを扱う csharp-docs、Javadoc 用の java-docs、Diátaxis の枠組みで書く documentation-writer、コードと文書のずれを読み取り専用で点検する docs-sync-audit などです。

このリポジトリは README で「サードパーティの開発者による提供物」と断っており、導入前に中身を読むよう求めています。create-readme は「プロジェクトとワークスペース全体を読む」と指示しているため、大きなモノレポでは読み込む範囲をディレクトリで絞る一文を足してから使ってください。java-docs のように「検証していない挙動を書かない」「依頼がない限り既存コメントを書き換えない」と明記しているものは、そのまま社内規約の叩き台にできます。

既存のドキュメントツールとの分担と鮮度管理

Copilot はコメントの文面を書く道具で、API リファレンスのサイトを組み立てる道具ではありません。Sphinx、JSDoc、TypeDoc、Doxygen はソースのコメントからリファレンスを生成するので、Copilot には各ツールの記法で docstring を書かせ、サイトの生成と公開はツールに任せます。.instructions.md に「JSDoc の @param と @returns を必ず書く」と入れておけば、ツールの警告も減ります。

文書の問題は、書いた直後より、コードが変わった後に起きます。生成した README や docstring は、コードを変えても自動では追従しません。リリース前やまとまった変更の後に、先の docs-sync-audit のような読み取り専用の点検を Ask で回し、ずれの一覧を受け取ってから直す方が、毎回の全面再生成より差分が小さく済みます。Issue に「README の手順を v3 の設定項目に合わせる」と書いて Copilot cloud agent に割り当てる方法もあります。GitHub Docs によると、エージェントが作ったプルリクエストに変更を push しても GitHub Actions は既定では自動実行されず、［Approve and run workflows］で許可が要ります。文書のリンク切れ検査などを CI で回している場合は、承認してワークフローを走らせ、結果を確かめてからマージしてください。CI を必須のステータスチェックにしておくと、検査前のマージを防げます。

テストコードの生成と確かめ方はGitHub Copilotでテストコードを自動生成する方法｜/testsの使い方と生成テストの確かめ方【2026年10月】で別に扱っています。

Copilotに任せるべきでない文書

Copilot が文書を書くときの根拠は、コードと、こちらが添付したファイルや Web ページなどの情報です。会議で決めた要件や却下した案のように、どこにも書かれていない判断は補えません。この前提から、任せてはいけない文書がはっきりします。

外部に提出する仕様書・設計書の最終版は、生成物のまま確定させないでください。要件の背景、却下した代替案、非機能要件の根拠はコードに書かれていません。Copilot はコードから読める範囲を仕様書の体裁で出力できてしまうため、抜けている前提が本文から見えなくなります。既存システムのコードから仕様を起こす作業は、コードの読解・仕様の復元・テストでの確認を分けて進める必要があり、その手順は生成AIモダナイゼーションの実装手順｜コード解読・仕様復元・テスト生成と限界で扱っています。

API の外部契約を記述する文書も同じです。実装だけを根拠に生成すると、実装の誤りがそのまま仕様として文書に書かれます。仕様と実装のずれを探すなら、正しい仕様書を別に渡して比較させる作業として依頼し、生成とは分けてください。docstring の一括付与も、1回のレビューで読み切れる量に区切ってください。社内で生成AIを開発工程に組み込む範囲やレビュー体制から設計したい場合は、生成AI導入支援で相談を受けています。

よくある質問

VS CodeのCopilot Chatで/docが使えないのはなぜですか？

/doc はインラインチャット専用で、チャットビューでは候補に出ません。対象を選択して Ctrl+I（macOS は Cmd+I）で開いたインラインチャットで実行します。Ctrl+I でチャットビューが開くなら、設定 inlineChat.askInChat を false にしてください。

GitHub Copilotで仕様書や設計書は作れますか？

コードから読み取れる範囲の記述は作れますが、外部に提出する最終版には向きません。要件の背景や非機能要件の根拠はコードに無く、Copilot はそれを補えないためです。棚卸しメモや引き継ぎ資料の下書きに用途を絞り、コードに無い項目は「TODO」と書かせてください。

docstringを日本語で書かせるにはどうすればよいですか？

1回だけならインラインチャットで /doc 説明文は日本語で のように条件を添えます。継続して揃えるなら、.github/instructions/ に applyTo 付きの .instructions.md を置き、「説明文は日本語、引数名と型名は英語」と書きます。指示ファイルはエージェントがファイルを作成・変更するときに自動で添付されます。

無料のCopilot Freeでもドキュメント生成は使えますか？

使えます。Microsoft の公式トレーニングも、演習には Copilot Free への登録で足りるとしています。ただし Free には月間の利用量に上限があり、Visual Studio のコメント提案もチャットの利用量として数えられます。リポジトリ全体に Agent で docstring を付けるような使い方は利用量を多く使うので、プランごとの上限はGitHub Copilotの料金（pricing）｜AI Credits移行後のプラン比較とBilling APIでの使用量集計【2026年10月】で確かめてください。

プロジェクト全体のドキュメントを一度に生成できますか？

チャットビューの Agent なら複数ファイルにまとめて書き込めます。ただし一度に出させるとレビューが追いつかないので、先に Plan で対象ファイルの一覧を出させ、ディレクトリ単位に分けて Agent に渡してください。

関連記事

• VS CodeでGitHub Copilotを使うには？導入手順・使い方・料金を解説【2026年10月版】
• copilot-instructions.mdとは？書き方とサンプル・配置場所、AGENTS.mdとの違い【2026年10月】
• GitHub Copilotエージェントモードの使い方｜Ask・Plan・Agentの違いと承認設定・料金
• GitHub Copilotでテストコードを自動生成する方法｜/testsの使い方と生成テストの確かめ方【2026年10月】