Declarative Agents for Microsoft 365 Copilotは、Microsoft 365 Copilotを「部署・業務・データソースごとに使いやすくする」ための宣言型エージェントです。今回の公式更新で重要なのは、単なるチャットボット作成機能ではなく、指示・知識ソース・アクション・管理メタデータを組み合わせて、Copilotを業務向けに拡張する仕組みとして整理された点です。
管理者は、Microsoft 365管理センターでのエージェント管理、共有と公開の違い、利用者への展開範囲、データアクセス権限を確認する必要があります。開発者や作成者は、知識ソースの選び方、RAI検証、マニフェスト、テスト、既存エージェントの更新方針を見直すことが実務上のポイントです。Microsoft Learnの該当ページは2026年5月19日に最終更新されています。(Microsoft Learn)
Declarative Agents for Microsoft 365 Copilotとは
Declarative Agents for Microsoft 365 Copilotは、Microsoft 365 Copilotに対して、業務に合わせた「役割」「参照する知識」「実行できる操作」を宣言して作るエージェントです。
通常のMicrosoft 365 Copilotは、ユーザーのMicrosoft 365データやMicrosoft Graphを活用して回答します。一方でDeclarative agentsは、たとえば次のような業務別の使い方に向いています。
| 活用シーン | 具体例 | 向いている理由 |
|---|---|---|
| 社内ITヘルプデスク | 「VPNに接続できない」「Teams会議の録画が見つからない」などの問い合わせ対応 | SharePoint上の社内手順書を知識ソースにできる |
| 人事・総務の問い合わせ | 入社手続き、休暇制度、経費精算ルールの案内 | 回答範囲を社内規程やFAQに絞りやすい |
| 営業支援 | 顧客対応履歴、提案資料、注文状況の確認 | 外部システム連携やプラグインを使える |
| プロジェクト支援 | 会議メモ、進捗資料、Teamsチャットの要約 | Microsoft 365アプリ上で業務文脈を保ちやすい |
重要なのは、Declarative agentsが独自のAI基盤を別途用意する仕組みではないことです。Microsoftの公式説明では、Declarative agentsはMicrosoft 365 Copilotと同じオーケストレーター、基盤モデル、信頼されたAIサービス上で動作するとされています。(Microsoft Learn)
つまり、開発者が一からAIアプリを作るというより、Microsoft 365 Copilotの上に業務専用の設定レイヤーを作るイメージで捉えると分かりやすいでしょう。
2026年5月19日の公式更新で何が変わったのか
今回の更新は、既存環境に対して「今すぐ全エージェントを移行しなければならない」という種類の告知ではありません。実務上は、Declarative agentsの説明がより管理・展開・設計の観点で整理された更新と見るのが適切です。
GitHub上のMicrosoftDocsの履歴を見ると、2026年5月18日の更新で、知識ソースの説明が「Microsoft 365 Copilot connectorsとSharePoint files」中心の表現から、SharePoint、OneDrive、Copilot connectors、アップロードファイルを含む表現へ広がっています。また、利用場所もTeams、Word、PowerPointに限定した表現から「Microsoft 365 apps」へ整理されています。(GitHub)
特に管理者・開発者が押さえるべき変更点は次のとおりです。
| 確認すべき点 | 更新後の読み取り方 | 実務への影響 |
|---|---|---|
| 知識ソースの範囲 | SharePoint、OneDrive、Copilot connectors、アップロードファイルなどを使える前提で整理 | 権限、秘密度ラベル、ファイル管理の設計がより重要になる |
| 利用場所 | Microsoft 365 Copilot UIやMicrosoft 365アプリ内で利用する前提 | WordやTeamsなど、利用面ごとのテストが必要 |
| 構成要素 | Agent definition、Capabilities、Knowledge sources、App metadataという観点で整理 | 仕様書やレビュー項目を作りやすくなった |
| 作成ツール | Agent Builder、Microsoft 365 Agents Toolkit、Copilot Studio、SharePointが選択肢として整理 | 誰が作るか、どこまで管理するかでツール選定が必要 |
| 管理者の役割 | Microsoft 365管理センターで配布や可視性を制御する前提が明確化 | 野良エージェントや過剰共有の監査が必要 |
以前の説明では、アプリパッケージやマニフェスト中心に読まれやすい部分がありました。更新後は、エージェントを「目的・振る舞い・機能・知識・配布情報で構成される業務アプリ」として扱う方向に整理されています。(GitHub)
利用者・管理者・開発者への影響範囲
Declarative Agents for Microsoft 365 Copilotの影響は、単に「新しいエージェントを作れる」ことにとどまりません。利用者、管理者、開発者で見るべきポイントが異なります。
| 対象 | 主な影響 | 今すぐ確認すべきこと |
|---|---|---|
| 利用者 | 業務別のエージェントをCopilot内で選んで使える | どのエージェントが何に使えるか、回答根拠をどう確認するか |
| Microsoft 365管理者 | エージェントの許可、ブロック、割り当て、公開、監査が必要になる | Agent Registry、公開範囲、共有ポリシー、データアクセス |
| 開発者・作成者 | 指示、知識ソース、アクション、マニフェストの品質が成果を左右する | テストケース、RAI検証、マニフェストバージョン、展開方法 |
| セキュリティ担当 | エージェントが参照するデータや実行する操作の確認が必要 | 権限、秘密度ラベル、外部API、MCPサーバー、監査ログ |
| 情報システム部門 | 業務部門が作るエージェントの統制が必要 | 作成ルール、命名規則、オーナー管理、利用状況レポート |
Microsoft 365管理センターでは、Copilot向けエージェントを有効化、無効化、割り当て、ブロック、削除できると説明されています。また、組織のメンバーがアクセスできるのは、管理者が許可したエージェントに限られます。(Microsoft Learn)
管理者が確認すべき設定
Agent Registryで全体像を把握する
まず確認すべき場所は、Microsoft 365管理センターのAgent Registryです。Agent Registryは、組織で利用可能なエージェントを一覧化し、監視・管理・ガバナンスを行うための場所です。Microsoftのドキュメントでは、Microsoft 365管理センターにサインインし、左ナビゲーションから「Agents」→「All Agents」→「Registry」を選択する流れが示されています。(Microsoft Learn)
管理者は、次の観点で棚卸ししてください。
| 確認項目 | 見るべき理由 | 放置した場合のリスク |
|---|---|---|
| エージェント名と作成者 | 誰が責任を持つかを明確にする | 退職者や異動者が作成したエージェントが残る |
| 公開先・利用可能ユーザー | 想定外の部署に広がっていないか確認する | 機密情報を扱うエージェントが広く使われる |
| 知識ソース | どのデータを参照して回答するか把握する | 古いFAQや誤ったドキュメントを参照する |
| ツール・アクション | 外部APIや業務システムへの操作有無を確認する | 誤更新、過剰権限、監査漏れが起きる |
| オーナー有無 | 管理責任が残っているか確認する | 改修・停止・問い合わせ対応ができない |
特に、エージェントが増えた組織では「誰かが作った便利なエージェント」が実態として業務に組み込まれていることがあります。Agent Registryの確認は、導入初期だけでなく、月次または四半期ごとの運用タスクに入れるべきです。
共有と公開を混同しない
Declarative agentsでは、「共有」と「公開」を分けて考える必要があります。
Microsoftの説明では、共有は特定のユーザーやグループに限定的な直接アクセスを与える方法であり、テストやフィードバック収集に向いています。一方、公開は組織全体や特定チャネルに正式展開し、Agent StoreやTeams、Copilotなどの面で利用可能にする方法です。(Microsoft Learn)
| 方法 | 向いている場面 | 注意点 |
|---|---|---|
| 共有 | 作成途中の確認、部門内レビュー、少人数テスト | 正式展開や大規模利用には向かない |
| 公開 | 組織展開、部門展開、TeamsやCopilotでの本番利用 | 承認、バージョン管理、ライフサイクル管理が必要 |
| 管理者による割り当て | 特定部署に確実に使わせたい場合 | 対象ユーザーやグループの設計が重要 |
| ブロック | 不適切、不要、危険なエージェントの停止 | 既に利用中の業務影響を確認してから実施する |
失敗しやすいのは、作成者が「共有しただけ」のエージェントを、現場が本番運用のように使い始めるケースです。正式な業務プロセスに組み込む場合は、共有ではなく公開・承認・運用ルールをセットで設計してください。
データアクセスと秘密度ラベルを確認する
Declarative agentsは、知識ソースとしてSharePoint、OneDrive、Teamsデータ、Outlookメール、アップロードファイル、Copilot connectorsなどを利用できます。ただし、便利さと同時に、データアクセス設計の重要性も増します。
Agent Builderでは、SharePointやOneDriveのファイル、フォルダー、サイトを知識ソースとして参照できます。公式ドキュメントでは、SharePointファイルは各エージェント最大100件、OneDriveファイルは最大50件を選択でき、既存のアクセス許可と秘密度ラベルを尊重すると説明されています。(Microsoft Learn)
特に注意したいのは、アップロードファイルを知識ソースにする場合です。公式ドキュメントでは、エージェントにアクセスできるユーザーは、アップロードされたファイル内容に基づく回答を取得できると説明されています。また、Microsoft Purview Information Barriersは埋め込みファイルには対応していないとされています。(Microsoft Learn)
実務では、次の基準で判断すると安全です。
| 判断ポイント | 推奨対応 |
|---|---|
| 機密性の高い規程や顧客資料を使う | SharePoint上の権限管理された場所を優先する |
| 一時的な検証用ファイルを使う | 検証後に削除し、公開前に知識ソースを見直す |
| 部門限定情報を使う | エージェントの公開先を部門グループに限定する |
| 全社FAQを使う | 最新版の置き場所を決め、古いファイルを参照させない |
| 外部コネクタを使う | 管理者が接続範囲と属性スコープを確認する |
Copilotは「ユーザーがアクセス権を持つ情報だけを扱う」設計を前提にしていますが、ファイルやサイト側の権限が広すぎれば、エージェントの回答範囲も広がります。エージェントの設計だけでなく、SharePointやOneDriveの権限設計も同時に見直してください。
利用状況レポートで定着度を見る
公開したエージェントは、作って終わりではありません。Microsoft 365 Copilot Agents reportでは、管理者が承認したエージェントや、ユーザーがAgent Builderで作成・共有したエージェントの利用状況を確認できます。(Microsoft Learn)
運用時は、次のように見ると改善につながります。
| 指標 | 読み取り方 | 次のアクション |
|---|---|---|
| Active agents | 実際に使われているエージェント数 | 使われていないものを整理する |
| Active users | 利用者が増えているか | 部署展開や教育の効果を確認する |
| Last activity date | 直近で使われているか | 古いエージェントを棚卸しする |
| 利用部門 | 想定部署で使われているか | 公開範囲や説明を見直す |
利用者が少ない場合、エージェントの品質以前に「どこにあるか分からない」「何を聞けばよいか分からない」ことが原因になりがちです。会話スターターや説明文を改善するだけで、利用率が上がる場合があります。
開発者・作成者が確認すべき設計ポイント
Declarative agentsは4つの構成要素で考える
公式情報では、Declarative agentは、エージェントのアイデンティティ、振る舞い、機能を表す構成要素で定義されると説明されています。主な構成要素は、Agent definition、Capabilities、Knowledge sources、App metadataです。(Microsoft Learn)
実務では、次のように設計書へ落とし込むとレビューしやすくなります。
| 構成要素 | 設計で決めること | 具体例 |
|---|---|---|
| Agent definition | 目的、対象ユーザー、回答方針、禁止事項 | 「社内IT手順に基づいて回答し、不明点はヘルプデスクに誘導する」 |
| Capabilities | できる操作、外部連携、API呼び出し | チケット作成、注文状況取得、会議情報検索 |
| Knowledge sources | 回答に使う情報源 | SharePointサイト、OneDriveファイル、Teamsチャット、Copilot connectors |
| App metadata | 名前、説明、アイコン、配布情報 | 「IT Help Agent」「営業支援エージェント」など |
よくある失敗は、最初に「何でも答える便利エージェント」を作ろうとすることです。Declarative agentsは、汎用性を広げるほど回答の評価が難しくなります。最初は「対象部署」「対象業務」「参照情報」「回答しない範囲」を絞る方が成功しやすいです。
作成ツールは目的で選ぶ
Declarative agentsは、Agent Builder、Microsoft 365 Agents Toolkit、Copilot Studio、SharePointなど複数の方法で作成できます。公式の比較では、Agents Toolkitはプロコード向けで、カスタムAPIアクション、Adaptive Cards、SDK、ローカルテスト、CI/CDに向いています。Copilot Studioはローコードで、業務ロジックやワークフロー自動化、Power Platform連携に向いているとされています。(Microsoft Learn)
| ツール | 向いている人 | 向いている用途 |
|---|---|---|
| Agent Builder | 業務部門、非エンジニア | FAQ、部門内ナレッジ、簡単な業務支援 |
| SharePoint | サイト管理者、部門担当者 | SharePointサイトやドキュメントを中心にしたQ&A |
| Copilot Studio | 業務改善担当、ローコード開発者 | 承認フロー、外部連携、Power Platformとの統合 |
| Microsoft 365 Agents Toolkit | 開発者 | API連携、ソース管理、CI/CD、マニフェスト管理、本格開発 |
判断基準は「誰が保守するか」です。業務部門が自分で更新したいならAgent BuilderやSharePointが向きます。API連携や本番展開、複数環境管理が必要なら、Copilot StudioやAgents Toolkitを選んだ方が安全です。
マニフェストは最新スキーマを前提に確認する
開発者がAgents Toolkitなどで作成する場合は、Declarative agent manifestのバージョンも確認が必要です。2026年5月時点の公式情報では、Declarative agent schema 1.7が案内されており、editorial_answers、default_response_mode、depends_onなどのプロパティ追加が説明されています。(Microsoft Learn)
既存エージェントを見直す際は、次の観点で確認してください。
| 確認項目 | 理由 |
|---|---|
version | 古いスキーマのまま新機能を使おうとしていないか確認する |
name と description | Agent Storeや管理画面で用途が分かるか確認する |
instructions | 回答範囲、禁止事項、エスカレーション条件が明確か確認する |
capabilities | 不要なデータソースや機能を有効化していないか確認する |
actions | プラグインやAPI連携の権限が適切か確認する |
conversation_starters | 利用者が最初に何を聞けばよいか分かるか確認する |
特に、会話スターターは軽視されがちですが、利用者の定着に直結します。「何ができますか？」と聞かせるより、「今週の営業会議メモから未完了タスクを整理して」など、業務に近い例を出す方が使われやすくなります。
プラグインとアクションは権限を厳しく見る
Declarative agentsは、プラグインを使って外部システムから情報を取得したり、データを作成・更新・削除したりできます。Microsoftの公式説明では、プラグインはMCPサーバーやOpenAPIで記述されたREST APIとDeclarative agentsを連携させる仕組みであり、プラグインはDeclarative agents内のアクションとしてのみサポートされるとされています。(Microsoft Learn)
外部APIを使う場合は、次の3点を必ずレビューしてください。
| レビュー項目 | 確認内容 |
|---|---|
| 読み取りか書き込みか | 参照だけなのか、登録・更新・削除まで可能なのか |
| 認証方式 | ユーザー委任なのか、アプリ権限なのか |
| 失敗時の挙動 | 誤更新、重複登録、タイムアウト時の再実行をどう扱うか |
たとえば「顧客の注文状況を確認する」アクションと、「顧客情報を更新する」アクションではリスクがまったく違います。後者は承認、確認メッセージ、監査ログ、ロールバック手順まで設計してください。
移行・展開時の注意点
既存エージェントは「壊れるか」ではなく「管理できるか」で見直す
今回の公式更新だけを見る限り、既存のDeclarative agentsに対して一律の移行期限が示されているわけではありません。ただし、運用上は次の観点で見直す価値があります。
| 見直し対象 | 確認すること |
|---|---|
| 古い説明文のエージェント | 用途、対象部署、責任者が分かる名前・説明になっているか |
| SharePoint中心のエージェント | OneDrive、アップロードファイル、Copilot connectorsを使っていないか |
| テスト共有のまま使われているエージェント | 正式公開や管理者承認が必要ではないか |
| 作成者が異動・退職したエージェント | オーナー変更や削除が必要ではないか |
| API連携を持つエージェント | 権限、外部接続、監査が適切か |
特に、業務部門がAgent Builderで作ったエージェントが便利だからと広まった場合、管理者が後から存在を把握することがあります。Microsoft 365管理センターのAgent Registryと利用状況レポートを使い、正式な管理対象に入れることが重要です。
展開は小さく始めて評価する
Declarative agentsの展開は、最初から全社公開にするより、限定グループで検証した方が安全です。
おすすめの流れは次のとおりです。
| 手順 | 実施内容 | 合格基準 |
|---|---|---|
| 業務シナリオ定義 | 何を解決するエージェントか決める | 1文で目的を説明できる |
| 知識ソース選定 | 参照するSharePoint、OneDrive、ファイルを決める | 古い資料や不要な資料が含まれていない |
| プロトタイプ作成 | Agent BuilderやCopilot Studioで作る | 主要質問に回答できる |
| 限定共有 | 5〜20名程度でテストする | 誤回答、権限不足、使いにくさを洗い出せる |
| 管理者レビュー | データ、権限、説明、公開範囲を確認する | 公開可否を判断できる |
| 段階的公開 | 部署またはグループ単位で展開する | 利用状況と問い合わせを追える |
| 継続改善 | 会話スターター、知識ソース、指示を更新する | 利用者の質問に合わせて改善できる |
Microsoftの評価ガイドでは、エージェントを改善するために評価を設計・実行し、要件検証、測定可能な目標、回帰テストを早い段階で作ることが推奨されています。Declarative agentsでは、指示が正しい回答を導くか、適切な知識ソースが使われるか、アクションが正しいパラメータで呼ばれるかを評価する観点が示されています。(Microsoft Learn)
RAI検証に通らない設計は公開できない
Declarative agentsは、Responsible AIの検証を通過する必要があります。公式ドキュメントでは、RAI検証はサイドロードまたは公開時のマニフェスト検証、およびユーザープロンプト処理時に実行されると説明されています。検証に失敗した場合、問題が修正されるまで公開できません。(Microsoft Learn)
公開前に、次のような指示が含まれていないか確認してください。
| 危険な指示 | 修正例 |
|---|---|
| 「社内ルールを無視して最短手順を案内する」 | 「社内ルールと承認フローに従って案内する」 |
| 「確信がなくても断定して回答する」 | 「根拠が不足する場合は不明と伝え、参照先を案内する」 |
| 「制限を回避して回答する」 | 「許可された知識ソースと権限の範囲で回答する」 |
| 「攻撃的・差別的な表現で分類する」 | 「中立的で業務上必要な分類に限定する」 |
RAI検証は単なる形式チェックではありません。社内向けエージェントであっても、利用者に誤った行動を促す指示や、モデルのガイドラインを回避させる指示は避ける必要があります。
ライセンスとコストで確認すべきこと
Declarative agentsはMicrosoft 365 Copilot上でホストされるため、追加のホスティングコストは発生しないと説明されています。一方で、利用者のライセンスや知識ソースによっては、利用ベース課金や機能制限が関係する場合があります。公式ドキュメントでは、Declarative agentを使うにはMicrosoft 365 Copilotアドオンライセンス、または対象Microsoft 365ライセンスによるMicrosoft 365 Copilot Chatへのアクセスが必要とされています。(Microsoft Learn)
確認すべきポイントは次の3つです。
| 確認項目 | 内容 |
|---|---|
| 利用者ライセンス | 対象ユーザーがMicrosoft 365 CopilotまたはCopilot Chatを利用できるか |
| 共有テナントデータ | SharePointやCopilot connectorsを使う場合、利用ベース課金の対象にならないか |
| 外部ホスティング | Declarative agentsでは不要だが、Custom engine agentsではAzureなどの費用が発生し得る |
「Declarative agentsだから必ず無料で使える」と単純に判断しないでください。特にCopilotライセンスを持たないユーザーに使わせる場合、テナントの課金設定と知識ソースの種類を確認する必要があります。
Declarative agentsとCustom engine agentsの違い
Microsoft 365 Copilotのエージェントには、大きくDeclarative agentsとCustom engine agentsの2つの考え方があります。
Declarative agentsは、Microsoft 365 Copilotのオーケストレーターやモデルを使い、指示・知識・アクションで業務向けに構成します。Custom engine agentsは、独自のオーケストレーションやモデルを持ち込み、より複雑なワークフローや外部アプリ連携を実装する選択肢です。公式比較でも、Declarative agentsはMicrosoft 365 Copilot内の焦点を絞ったシナリオ向け、Custom engine agentsは複雑なワークフローや高度な統合向けと整理されています。(Microsoft Learn)
| 比較項目 | Declarative agents | Custom engine agents |
|---|---|---|
| 向いている用途 | 部門FAQ、ナレッジ検索、業務支援 | 複雑な承認、独自AIモデル、外部システム中心の処理 |
| オーケストレーション | Microsoft 365 Copilot側を利用 | 独自に設計可能 |
| モデル選択 | Copilotの基盤を利用 | 独自モデルや特化モデルを使える |
| ホスティング | Microsoft 365側でホスト | 外部ホスティングが必要になる場合がある |
| 実装難易度 | 比較的低い | 高い |
| セキュリティ・RAI | Microsoft 365の標準に沿いやすい | 自社でより多くの設計責任を負う |
| プロアクティブ動作 | 基本的にユーザー起点 | 自動起動や高度なワークフローに向く |
判断に迷ったら、まずDeclarative agentsで始めるのが現実的です。次の条件に当てはまる場合だけ、Custom engine agentsを検討するとよいでしょう。
- 独自のAIモデルを使う必要がある
- 複数システムをまたぐ複雑な判断ロジックがある
- ユーザー操作なしで自動的に処理を開始したい
- Microsoft 365の外部アプリやWebサイトでも同じエージェントを使いたい
- 厳密なワークフロー制御や独自監査が必要
よくある失敗と回避策
失敗: 知識ソースを広げすぎる
社内ポータル全体や大量のファイルを参照させると、便利に見える一方で、回答の根拠が曖昧になりやすくなります。
回避策は、最初に「このエージェントが答えるべき質問」を10〜20個に絞り、その質問に必要な知識ソースだけを追加することです。SharePointサイト全体より、特定のドキュメントライブラリやフォルダーから始める方が評価しやすくなります。
失敗: 説明文が曖昧で利用者が使えない
「業務効率化エージェント」「社内情報検索エージェント」のような名前では、利用者は何を聞けばよいか分かりません。
回避策は、名前と説明を業務シーンに寄せることです。
| 悪い例 | 良い例 |
|---|---|
| 社内FAQエージェント | 人事・総務FAQエージェント |
| サポートエージェント | ITヘルプデスク一次回答エージェント |
| 営業支援AI | 提案資料・顧客対応履歴検索エージェント |
会話スターターも同じです。「質問してください」ではなく、「今月更新された経費精算ルールを教えて」「入社初日に必要な手続きを一覧にして」のように、業務でそのまま使える例を入れてください。
失敗: 共有のまま本番利用する
作成者がテスト目的で共有したエージェントを、部門全体が本番利用し始めるケースがあります。この状態では、承認、バージョン管理、オーナー管理、公開範囲の統制が不十分になりがちです。
回避策は、共有エージェントを定期的に棚卸しし、一定以上使われているものは管理者レビューを通して正式公開へ移すことです。
失敗: SharePointの権限不備で回答できない
Declarative agentsがSharePointを知識ソースにしていても、ユーザーにアクセス権がなければ期待どおりに回答できません。既知の問題として、SharePointやOneDriveの知識ソースでは、ユーザーのCopilotライセンス、SharePointサイトへのアクセス、Read権限、ユーザー認証などが不十分な場合に実行時エラーが起こり得ると説明されています。(Microsoft Learn)
回避策は、公開前テストに「権限が異なるユーザー」を含めることです。作成者本人だけでテストすると、権限問題を見落とします。
まず取るべきアクション
Declarative Agents for Microsoft 365 Copilotを安全に活用するには、作成機能を試す前に、管理と設計のルールを決めることが重要です。
まず管理者は、Microsoft 365管理センターでAgent Registryを確認し、既存エージェントの作成者、公開範囲、知識ソース、アクションを棚卸ししてください。次に、共有と公開のルール、部門エージェントの命名規則、オーナー管理、データアクセス確認の手順を決めます。
開発者や作成者は、最初から大規模なAI業務アプリを作ろうとせず、1つの業務課題に絞った小さなエージェントから始めてください。指示、知識ソース、会話スターター、テストケースを用意し、限定ユーザーで検証してから正式展開する流れが現実的です。
今回の公式更新で見るべき本質は、「Copilotを拡張できるようになった」ことだけではありません。Declarative agentsを、業務データ・権限・アクション・ライフサイクルまで含めて管理する段階に入ったことです。便利なエージェントを増やす前に、管理者と開発者が同じ基準で設計・公開・改善できる体制を整えましょう。
コメント