Microsoft developer platform documentation updateの中でも、2026年5月5日にmicrosoft/conductorへマージされた「feat: add workspace instructions support（--workspace-instructions）」は、AIエージェントワークフローを運用しているチームほど早めに確認すべき変更です。結論から言うと、Conductorで実行する各エージェントのプロンプトに、リポジトリ内のAGENTS.md、CLAUDE.md、.github/copilot-instructions.mdなどのワークスペース指示ファイルを自動または明示的に注入できるようになりました。(GitHub)
この更新で便利になるのは、コーディング規約やレビュー方針、アーキテクチャ上の注意点を、毎回個別のプロンプトへ書かなくてもよくなる点です。一方で、指示ファイルの内容が全エージェントに入るため、古いルール、機密情報、曖昧な指示があると出力品質やトークン消費に影響します。この記事では、Microsoft developer platformのConductor更新について、変更点、影響範囲、移行時の確認ポイントを実務目線で整理します。
Microsoft developer platformの更新概要：--workspace-instructionsで何が変わったか
今回の対象は、Microsoftのmicrosoft/conductorリポジトリに含まれるConductorです。Conductorは、GitHub Copilot SDKやAnthropic Claudeを使ったマルチエージェントワークフローをYAMLで定義・実行するCLIツールとして説明されています。(GitHub)
2026年5月5日にマージされたPR #141では、ワークスペース指示ファイルを検出し、全エージェントのプロンプトへ前置きとして追加するためのCLIフラグ、YAML設定、エンジン側の処理が追加されました。PR本文では、instructions.pyモジュール、--workspace-instructions、--instructions、WorkflowDefのinstructionsフィールド、サブワークフロー継承、チェックポイント永続化、32件のテスト追加が挙げられています。(GitHub)
| 項目 | 変更内容 | 確認すべきこと |
|---|---|---|
| CLI | conductor runに--workspace-instructionsと--instructions PATHが追加 | CIや手元の実行コマンドにフラグを入れるべきか判断する |
| 自動検出 | AGENTS.md、CLAUDE.md、.github/copilot-instructions.mdをCWDからGitルートまで探索 | 実行ディレクトリが想定どおりか確認する |
| YAML | workflow.instructionsで追加の指示ファイルを指定可能 | ワークフロー固定のルールはYAMLに書くか検討する |
| エンジン | 指示内容を全エージェントのレンダリング済みプロンプトに前置き | 全エージェントに見せてよい内容か確認する |
| サブワークフロー | 親ワークフローの指示がサブワークフローへ継承される | 子ワークフロー側の指示と矛盾しないか確認する |
| 再開実行 | 指示はチェックポイントに保存され、resume時も同じ指示を使う | 指示変更後に古い実行を再開するか、新規実行するか判断する |
使い方：CLIフラグとYAML設定の基本
もっとも分かりやすい使い方は、conductor runに--workspace-instructionsを付ける方法です。CLIリファレンスでは、このフラグはCWDからGitルートまで規約ファイルを探索し、見つかった内容を連結して各エージェントのプロンプトへ前置きすると説明されています。--instructions PATHは明示的な指示ファイルを指定するフラグで、複数回指定でき、自動検出と組み合わせられます。(GitHub)
# リポジトリ内の規約ファイルを自動検出して実行
conductor run workflow.yaml --workspace-instructions
# 自動検出に加えて、追加のスタイルガイドも注入
conductor run workflow.yaml --workspace-instructions --instructions ./style-guide.mdワークフロー単位で常に同じ指示を使いたい場合は、YAML側のinstructionsを使います。Workflow Syntax Referenceでは、workflow設定の中にinstructionsリストを置き、指示ファイルを全エージェントプロンプトへ前置きする例が示されています。(GitHub)
workflow:
name: review-workflow
description: Repository-aware code review workflow
entry_point: reviewer
instructions:
- ./docs/conventions.md
- ./AGENTS.md判断基準はシンプルです。リポジトリ全体の共通ルールを使いたいなら--workspace-instructions、ワークフローに固定したいルールならYAMLのinstructions、一時的なレビュー観点や案件固有の補足なら--instructions PATHが向いています。
自動検出される指示ファイルと役割
--workspace-instructionsが便利なのは、既にリポジトリに置かれているAI向けの指示ファイルを再利用できる点です。ただし、ファイル名ごとに想定される文脈が異なるため、単に存在するから使うのではなく、内容を整理してから有効化したほうが安全です。
| ファイル | 主な用途 | 見直すポイント |
|---|---|---|
AGENTS.md | AIエージェント全般向けの作業方針、設計原則、禁止事項 | 全エージェントに適用して問題ないか |
CLAUDE.md | Claude利用時の開発ルールやプロンプト方針 | Claude専用の表現がCopilot実行時にも混ざってよいか |
.github/copilot-instructions.md | GitHub Copilot向けのリポジトリ指示 | Conductorの全エージェントに入れても矛盾しないか |
注意したいのは、今回の仕組みが「プロバイダー別に都合よく解釈してくれる機能」ではなく、見つかった指示ファイルをワークスペース指示として注入する仕組みである点です。たとえばCLAUDE.mdに「Claudeだけが使える機能を前提にする」といった文言がある場合、Copilot側のエージェントにもその指示が入る可能性があります。プロバイダー固有の内容は、ファイル内で明確に条件分岐した書き方にするか、Conductor用の共通指示ファイルへ整理するのが実務上は安全です。
影響を受けるユーザーと対応優先度
このMicrosoft developer platform documentation updateは、Conductorを使っていないユーザーには直接の影響は小さいです。一方で、Conductorで複数エージェントのレビュー、設計、調査、コード生成を自動化しているチームには、プロンプトの前提条件が大きく変わる可能性があります。
| 対象者 | 影響 | 対応優先度 |
|---|---|---|
| Conductorでワークフローを実行している開発者 | 実行時にリポジトリルールを自動注入できる | 高 |
AGENTS.mdやCopilot指示ファイルを管理しているリポジトリオーナー | 既存ファイルの内容が全エージェントに影響し得る | 高 |
| CI/CDでConductorを実行している担当者 | CWDや実行コマンド次第で読み込まれる指示が変わる | 高 |
| サブワークフローを使っているチーム | 親の指示と子の指示が結合される | 中〜高 |
| 単発の手動プロンプトだけを使うユーザー | 直接影響は限定的 | 低 |
特にCI/CDでは、実行ディレクトリが重要です。--workspace-instructionsはワークフローファイルの場所ではなく、CWDからGitルートへ向かって探索するため、CIジョブでcdする場所が変わると、検出対象も変わります。CLIリファレンスとWorkflow Syntax Referenceのどちらでも、探索起点はCWDであることが説明されています。(GitHub)
移行時に確認すべき設定チェックリスト
既存ワークフローへすぐに--workspace-instructionsを追加する前に、次の順で確認すると失敗を避けやすくなります。
手元のConductorでフラグが使えるか確認する
PR #141は2026年5月5日にmainへマージされています。一方、CHANGELOG上ではWorkspace instructions supportが0.1.11 - 2026-05-04のAdded項目として記載されています。実際の利用時は、インストール済みのConductorが該当フラグを持っているか、conductor run --helpなどで確認してからCIへ反映するのが安全です。(GitHub)
conductor run --helpヘルプに--workspace-instructionsと--instructionsが表示されない場合は、Conductorの更新または対象ブランチ・タグの確認が必要です。
リポジトリ内の指示ファイルを棚卸しする
まず、読み込まれる可能性があるファイルを確認します。
find . -name AGENTS.md -o -name CLAUDE.md -o -path '*/.github/copilot-instructions.md'複数階層に同名ファイルがある場合、実装上は開始ディレクトリに近いファイルが優先され、検出結果は規約ファイルの定義順に返されます。また、指示ファイル全体が50KBを超えると、毎回のエージェント呼び出しでトークンを消費するため警告対象になります。(GitHub)
指示の内容を「全エージェント向け」に整える
全エージェントに前置きされる指示には、次のような内容が向いています。
| 入れるべき内容 | 避けるべき内容 |
|---|---|
| コーディング規約、命名規則、レビュー観点 | 個人のアクセストークンや内部URL |
| アーキテクチャ上の制約 | 期限切れの移行方針 |
| テスト実行方針 | 特定エージェントだけに必要な細かい手順 |
| 禁止している変更パターン | 「必ず」「絶対」ばかりの曖昧な強制文 |
| 参照すべきドキュメントの相対パス | ローカルPC固有の絶対パス |
たとえば、次のような指示は実用的です。
## Repository rules
- TypeScriptの型エラーを無視しない
- 既存のAPIレスポンス形式を変更する場合は、互換性への影響を説明する
- UI変更ではアクセシビリティとキーボード操作を確認する
- テストを追加できない場合は、その理由をレビューコメントに残す逆に、次のような指示は避けるべきです。
- とにかく最速で修正する
- 既存コードは古いので自由に書き換えてよい
- 社内Wikiの秘密ページを参照する
- /Users/taro/private/spec.md を必ず読むAIエージェントに渡す指示は、厳密な仕様書というより「判断基準の圧縮版」として書くと効果が出やすくなります。長大なルールを貼るより、失敗しやすい判断だけを短く明示したほうが、トークン消費と出力品質のバランスを取りやすくなります。
--instructionsとYAML instructionsの使い分け
今回の更新では、自動検出だけでなく、明示的にファイルを追加する--instructions PATHと、YAMLレベルのinstructionsも使えます。実装上、指示ソースは自動検出、YAMLのinstructions、CLIの--instructionsの順に結合されます。(GitHub)
| 使い方 | 向いているケース | 例 |
|---|---|---|
--workspace-instructions | リポジトリ共通のルールを読み込みたい | 通常のコードレビュー、設計レビュー |
--instructions ./file.md | 一時的な観点を追加したい | リリース前チェック、脆弱性観点レビュー |
YAML instructions | ワークフローに固定したい前提を持たせたい | 特定の審査フロー、定型の品質チェック |
実務では、共通ルールはAGENTS.mdや.github/copilot-instructions.mdに集約し、案件固有の補足だけを--instructionsで追加する運用が扱いやすいです。YAMLのinstructionsは、ワークフローそのものの品質を保つための「固定コンテキスト」と考えるとよいでしょう。
サブワークフロー利用時の注意点
Conductorでサブワークフローを使っている場合、今回の更新は特に重要です。Workflow Syntax Referenceでは、指示ファイルは一度読み込まれ、全エージェントのレンダリング済みプロンプトに前置きされ、サブワークフローへ継承され、チェックポイントにも保存されると説明されています。(GitHub)
たとえば、親ワークフローで「フロントエンドのレビュー観点」を読み込み、子ワークフローで「バックエンドAPIのレビュー観点」を追加すると、子ワークフロー側では両方の指示が入ります。これは便利ですが、指示が増えすぎると次の問題が起きます。
| 起こりやすい問題 | 原因 | 対策 |
|---|---|---|
| 出力が過剰に慎重になる | 禁止事項が多すぎる | 優先順位を明記する |
| レビュー観点がぶれる | 親と子で矛盾したルールがある | 共通ルールと個別ルールを分ける |
| 実行コストが増える | 長い指示が全エージェントに入る | 重要な判断基準だけに絞る |
| resume後に古い指示で動く | チェックポイントに指示が保存される | 指示変更後は新規実行を検討する |
サブワークフローを多用するチームは、親に「共通原則」、子に「専門領域の追加ルール」を置く設計にすると運用しやすくなります。
既存ワークフローに導入する手順
既存のConductorワークフローへ導入する場合は、次の流れで進めると安全です。
小さなワークフローで検証する
いきなり本番のCIに入れるのではなく、まずは1つの小さなワークフローで試します。
conductor run workflow.yaml --workspace-instructions --log-file debug.logConductorのWeb dashboardでは、エージェント詳細パネルでレンダリング済みプロンプトや出力を確認できると説明されています。指示が期待どおり入っているかを見るには、ログやダッシュボードを使った確認が有効です。(GitHub)
CIではCWDを明示する
CIで使う場合は、実行前に対象リポジトリのルートまたは意図したサブディレクトリへ移動してから実行します。
cd "$GITHUB_WORKSPACE"
conductor run workflows/review.yaml --workspace-instructionsサブディレクトリごとにAGENTS.mdを分けている場合は、どの階層から実行するかをCI定義にコメントとして残しておくと、後から見た担当者が意図を理解しやすくなります。
指示ファイルをレビュー対象に含める
AGENTS.mdや.github/copilot-instructions.mdは、AI出力に直接影響する設定ファイルです。今後は、コード規約やCI設定と同じようにレビュー対象として扱うべきです。
特に次の変更は、通常のドキュメント変更より慎重にレビューしましょう。
| 変更内容 | レビュー観点 |
|---|---|
| 禁止事項の追加 | 開発効率を過度に下げないか |
| 技術選定ルールの変更 | 既存設計と矛盾しないか |
| セキュリティ方針の追加 | 機密情報を含んでいないか |
| プロバイダー固有の指示 | 他のプロバイダー実行時に混乱しないか |
| 長文の背景説明追加 | 毎回のトークン消費に見合うか |
よくある失敗と回避策
CLAUDE.mdとCopilot指示が矛盾する
CLAUDE.mdにはClaude向けの書き方、.github/copilot-instructions.mdにはCopilot向けの書き方が残っていることがあります。どちらも自動検出対象に入るため、内容が矛盾しているとエージェントの判断が揺れます。
回避策は、プロバイダー固有の指示を減らし、共通化できる内容はAGENTS.mdへ寄せることです。どうしても固有の指示が必要な場合は、「Claudeを使う場合のみ」「Copilot実行時は無視」のように条件を明記します。
指示ファイルが長すぎて出力が鈍くなる
長いドキュメントを丸ごと入れると、全エージェント呼び出しでトークンを消費します。実装上も大きな指示ファイルは警告対象になっており、長い指示は毎回のエージェント呼び出しでトークンを消費する旨が示されています。(GitHub)
回避策は、指示ファイルを「読むべき全文」ではなく「判断基準の要約」にすることです。詳細ドキュメントは相対パスで案内し、常に守るべき原則だけを短く書きます。
CIでは動くがローカルでは違う結果になる
--workspace-instructionsの探索はCWDに依存します。ローカルではpackages/frontendから実行し、CIではリポジトリルートから実行している場合、近い階層にある指示ファイルの扱いが変わる可能性があります。
回避策は、実行ディレクトリを明示し、READMEやCI定義に「どこからConductorを実行するか」を残すことです。チームで再現性を重視するなら、共通の実行スクリプトを作るのも有効です。
導入判断：すぐ有効化すべきケース、待ったほうがよいケース
--workspace-instructionsは便利ですが、すべてのチームが即時有効化すべきとは限りません。判断基準は、既存の指示ファイルが「AIに渡してよい品質」になっているかです。
| 状況 | 判断 |
|---|---|
AGENTS.mdに明確な開発ルールが整理されている | 早めに有効化して効果を確認する |
| Copilot指示ファイルが既にレビュー済み | 小規模ワークフローから試す |
| 指示ファイルに古い移行方針が残っている | 修正してから有効化する |
| 機密URLや個人環境のパスが書かれている | 有効化前に必ず削除する |
| サブワークフローごとに強い個別ルールがある | 親子の指示設計を見直してから導入する |
迷った場合は、まず--instructions ./review-rules.mdで小さな追加指示を試し、効果を確認してから--workspace-instructionsへ広げると安全です。
まとめ：次に取るべき行動
今回のMicrosoft developer platform documentation updateでは、Conductorがワークスペース指示ファイルを自動検出し、全エージェントプロンプトへ注入できるようになりました。これにより、リポジトリ固有の規約やレビュー観点をAIエージェントに一貫して伝えやすくなります。PR #141の変更内容は、CLIフラグ、YAML設定、エンジン処理、サブワークフロー継承、チェックポイント永続化まで含むため、単なるドキュメント更新ではなく運用設計にも関わる変更です。(GitHub)
まずやるべきことは、手元のConductorで--workspace-instructionsが使えるか確認し、リポジトリ内のAGENTS.md、CLAUDE.md、.github/copilot-instructions.mdを棚卸しすることです。そのうえで、全エージェントに渡してよい内容だけに整理し、小さなワークフローでログやダッシュボードを確認してからCIへ展開しましょう。
コメント