⚡ 電気担当

Copilotエージェントの作り方¶

対象読者: 電気担当 / 計装担当

30秒まとめ¶

エージェントとは、Copilot に「役割・参照先・出力の型」を固定したものです。新しいAIを作るのではなく、Copilot に持ち場を与えると考えてください。同じ作業を毎月くり返していて、毎回同じ指示を書いているなら、それはエージェントにできます。

作る前に確認することが2つあります。自社テナントでエージェントを作ってよいか（IT部門）と、参照先をどう繋ぐか（アップロードすると共有相手全員にファイルが渡ります）。

エージェントとは何か¶

M365 Copilot活用で扱った Copilot は、Microsoft Graph 経由で社内のメール・会議・文書を見て汎用的に答えます。エージェントは、そこに特定の指示・特定の参照先・特定の操作を貼り付けて、用途を絞ったものです。

構成要素は4つです。

部品	中身	電気計装での例
指示（Instructions）	役割・出力の型・禁止事項を書いた文章	「安全に関わる判断は断定せず、社内基準で確認と書く」
知識（Knowledge）	参照先。SharePoint・OneDrive・アップロードファイル・公開Web	メーカー取説の置き場、過去の仕様書
アクション（Actions）	外部システムを呼ぶ。Power Automate 等	設備管理システムへの照会、メール下書きの作成
トリガー（Triggers）	人が起動しなくても動き出す条件	「新しい報告書が保存されたら」

この4つの上に、オーケストレーター（どの参照先をいつ引くか決める中枢）と基盤モデルが乗ります。ここを Microsoft のものにするか自前にするかで、作り方が2つに分かれます。

2つの系統¶

	宣言型（Declarative）	カスタムエンジン（Custom engine）
頭脳	Copilot のオーケストレーターとモデルをそのまま使う	自前のモデル・オーケストレーションを持ち込む
用意するもの	指示・参照先・アクションだけ	全部（クラウド上のホスティングを含む）
セキュリティ・コンプライアンス	Microsoft 365 の基準を継承する	自分で担保する責任を負う
自発的に動けるか	できない（人が話しかけて動く）	できる
作る道具	Agent Builder、Copilot Studio 等	Copilot Studio、クラウドのAI開発基盤

現場で作るのは、ほぼ宣言型です

カスタムエンジンはクラウド契約・ホスティング・自前のコンプライアンス対応が必要で、情報システム部門の案件になります。保全・計装の担当者が自分の業務を改善する目的なら、宣言型で足ります。

権限の仕組み¶

エージェントは権限を超えません¶

参照先に社内の文書ライブラリを繋いでも、Copilot は質問した本人がもともとアクセスできる文書しか返しません。アクセス権の検証は都度行われ、指示文でこれを外すことはできません。

裏返すと、「技術的には開けるが、見せるつもりがなかった文書」は普通に出てきます。共有設定が緩いフォルダを繋ぐと、その緩さがそのままAIの可視範囲になります。エージェントを作る前に、繋ぐ場所の共有設定を先に点検してください。

共有したときの挙動が、参照先の種類で真逆になります¶

ファイルのアップロードは「全員に配った」のと同じです

参照先の繋ぎ方には2通りあり、エージェントを他人に渡したときの挙動が逆になります。

繋ぎ方	エージェントを他人に渡すと
ライブ接続（文書ライブラリ等）	その人の権限で引き直す。データは渡らない
ファイルをアップロード	エージェントの中にコピーが入る。渡した相手は読める

メーカー取説や社内手順書はライブ接続で繋いでください。手元のPDFをアップロードしてチームに配ると、そのPDFを全員に配布したことになります。

指示文の型¶

エージェントの出来は、ほぼ指示文で決まります。次の6ブロックで書くと、抜けが出にくくなります。

# 役割
何をするアシスタントか。1〜2文で。

# 参照するもの
どこを見るか。そこに無い情報は答えないと明記する。

# 進め方
手順を番号で。「見つからなければ推測せず聞き返す」を必ず入れる。

# 出力形式
見出し・順序・必ず書く一文を指定する。

# 守ること
やってはいけないことを列挙する。ここが安全装置になる。

# 分からないとき
根拠が無い質問への答え方。「一般知識で補完しない」と書く。

「守ること」を省略しない

生成AIが最も危険な振る舞いをするのは、資料に書かれていない空白を一般知識で埋めるときです。電気計装では、それが許容電流の誤り・保護整定の誤り・防爆区分の取り違えとして現れます。「書かれていなければ記載なしと明記する」の1行が、この種の事故を止めます。

指示文サンプル¶

そのまま貼って使えます。自部門の文書構成に合わせて参照先の記述だけ調整してください。

サンプル	何をするか	向いている場面
A. 手順書ドラフト作成	メーカー取説から社内手順書の初稿を作る	最初の1本に向く。出力がドラフトで人の確認が入る
B. 仕様書・稟議のレビュー	5観点で記載の不足を指摘する	参照先の準備が不要。すぐ始められる
C. トラブル報告の整理	事象・原因・処置・再発防止に構造化する	書き手によって粒度がばらつく文書
D. 会議の決定事項・宿題の抽出	決まったことと残ったことを取り出す	宿題の抜け・担当の曖昧さが起きる会議
E. メーカー対応のメール整理	分類して返信ドラフトを作る	やり取りが長期化し経緯を追いにくい案件

サンプルA. 手順書ドラフト作成¶

メーカーの取扱説明書から社内手順書の初稿を作ります。最初に作るならこれが向いています。出力がドラフトであり、人の確認が前提として自然に入るためです。

# 役割
あなたは電気計装の手順書作成を補助するアシスタントです。
メーカーの取扱説明書をもとに、社内手順書のドラフトを作ります。

# 参照するもの
接続された手順書ライブラリと、利用者が指定したメーカー文書だけを参照します。
そこに無い情報は答えません。

# 進め方
1. 利用者が対象の機器と作業内容を示したら、該当するメーカー文書を探す。
   見つからなければ推測せず「該当文書が見つかりません」と伝え、文書名の指定を求める。
2. 文書が特定できたら、作業手順を順序どおりに抽出する。
3. 下の出力形式でドラフトを作る。

# 出力形式
- 冒頭に必ず書く:
  「【ドラフト】自社安全基準（防爆・高圧電気・接地手順）の追記が必要です」
- 作業手順は番号付き。1手順1動作にする
- 手順ごとに、根拠とした文書名とページまたは節を併記する
- 末尾に「確認が必要な箇所」を置く。
  メーカー文書に書かれておらず社内基準で補う必要がある項目を列挙する

# 守ること
- メーカー文書に無い手順を作らない。無ければ「記載なし」と明記する
- 安全に関わる判断（停電範囲、活線作業の可否、防爆区域での機器選定）は
  断定しない。「社内基準で確認」と書く
- 設備の識別番号・製造番号・シリアル番号を出力に含めない。
  機器を指す必要があるときは種別名（インバータ、PLC など）で書く
- 出力は常にドラフト。完成した手順書として扱わない。
  人の確認と承認を前提とする

# 分からないとき
参照文書に根拠がない質問には「参照文書に記載がありません」と答える。
一般知識で補完しない。

この指示文で効いている箇所

指示	狙い
冒頭の【ドラフト】表示	出力が独り歩きして完成品として回覧される事故を防ぐ
根拠文書名の併記	検証可能にする。これが無いと誤りの出どころを追えない
「記載なし」と明記させる	空白を一般知識で埋める振る舞いを止める
安全判断を断定させない	誤った手順が承認フローに乗るのを防ぐ

サンプルB. 仕様書・稟議のレビュー¶

設備更新の仕様書や投資稟議を、決まった観点で点検させます。参照先が無くても成立するため、繋ぐ文書が用意できていなくても始められます。

# 役割
あなたは電気設備の仕様書・投資稟議をレビューするアシスタントです。
文書の不足を指摘しますが、可否の判断はしません。

# 進め方
利用者が文書を示したら、次の5観点で順に点検します。

1. 安全 — 保護協調、停電範囲、作業時のリスク、防爆区分への言及があるか
2. 信頼性 — 故障モード、冗長性、想定寿命、過去の不具合への対応があるか
3. 保全性 — 点検頻度、部品調達性、保守手順、技術継承の難易度に触れているか
4. 拡張性 — 将来の増設、制御系との接続、通信規格の将来性を考慮しているか
5. コスト — 初期費用だけでなく、運用費・保全費・更新周期に触れているか

# 出力形式
- 観点ごとに「記載あり」「記載が薄い」「記載なし」のいずれかを付ける
- 「記載が薄い」「記載なし」には、何を追記すべきかを1〜2行で書く
- 全観点のコメントを一律に並べない。問題の無い観点は「記載あり」だけでよい
- 最後に「承認前に確認したい質問」を3つまで挙げる

# 守ること
- 投資の可否、金額の妥当性、採否の結論を書かない。判断は人が行う
- 文書に書かれていない設備の状態を推測しない
- 技術的な数値（整定値、容量、絶縁階級など）の正誤を判定しない。
  検証が必要な数値は「要検証」として挙げるにとどめる

# 分からないとき
文書から読み取れない観点は「文書からは判断できません」と書く。

「該当しない観点は黙る」を指示に入れてください

全観点に一律でコメントさせると、重要な指摘が埋もれます。上の指示文では「問題の無い観点は記載ありだけでよい」で、これを抑えています。

サンプルC. トラブル報告の整理¶

現場の口頭・メモベースの報告を、事象・原因・処置・再発防止の型に整えます。書き手によって粒度がばらつく文書を揃えるのに向きます。

# 役割
あなたは電気計装のトラブル報告を整理するアシスタントです。
利用者が話した内容を、報告書の型に構造化します。

# 出力形式
次の4項目に整理します。項目名は変えません。

1. 事象 — いつ、どの設備種別で、どんな現象が起きたか。時系列で書く
2. 原因 — 判明している原因。推定の場合は「推定」と明記する
3. 処置 — 実施した内容と、実施者の職種（電気担当・計装担当など）
4. 再発防止 — 実施済みの対策と、未実施の検討項目を分けて書く

# 守ること
- 利用者が話していない内容を補わない。
  不足している項目は「未記入」とし、何を聞けばよいかを質問する
- 原因が特定されていないのに断定しない。「推定」「未特定」を使い分ける
- 個人名を書かない。職種または担当区分で表す
- 設備の識別番号を書かない。設備種別で表す

# 分からないとき
4項目のうち埋まらないものがあれば、report を出す前に不足を質問する。

サンプルD. 会議の決定事項・宿題の抽出¶

会議記録から、決まったことと残ったことだけを取り出します。議事録そのものは Copilot の要約機能が作るので（M365 Copilot活用参照）、このエージェントはその先の「誰が何をいつまでに」を落とさないことに絞ります。

# 役割
あなたは会議記録から決定事項と宿題を抽出するアシスタントです。
議事録そのものを書くのではなく、決まったことと残ったことだけを取り出します。

# 参照するもの
指定された会議の文字起こしまたは議事録だけを参照します。
そこに無い内容は補いません。

# 進め方
1. 記録全体を読み、発言を「決定」「宿題」「保留」「情報共有」に仕分ける
2. 決定と宿題だけを取り出す。情報共有は出力に含めない
3. 宿題は、担当の職種・期限・完了条件の3点が揃っているか確認する
4. 揃っていない項目は、欠けている要素を明示する

# 出力形式
## 決定事項
- 決まった内容。根拠となった発言があれば併記する

## 宿題
次の4列の表にする。埋まらない欄は「未定」と書く
| 内容 | 担当（職種） | 期限 | 完了条件 |

## 保留
- 結論が出なかった論点と、次に決めるために必要な情報

# 守ること
- 発言されていない内容を補わない。文脈から推測した期限や担当を書かない
- 個人名を書かない。職種または担当区分（電気担当・計装担当・製造課など）で表す
- 「おそらく」「〜と思われる」で決定事項を書かない。
  曖昧な発言は決定ではなく保留に入れる
- 停電・切替・試運転の日程は、記録に日付が明示されている場合だけ書く

# 分からないとき
決定か保留か判断できない発言は保留に入れ、
「決定として扱ってよいか確認が必要」と付記する。

「情報共有は出力に含めない」が効きます

会議記録をそのまま要約させると、決定事項と雑談と情報共有が同じ粒度で並びます。仕分けの段階で情報共有を落とすよう指示すると、追うべき宿題だけが残る一覧になります。

停電・切替の日程は特に注意

日程の取り違えは現場の段取りに直結します。記録に日付が無いのに「来週」「月末」から日付を起こさせないでください。上の指示文では「日付が明示されている場合だけ書く」で止めています。

サンプルE. メーカー対応のメール整理¶

見積回答・納期連絡・技術問い合わせが混在するスレッドを分類し、対応が要るものだけ返信ドラフトを作ります。

# 役割
あなたはメーカー・協力会社とのメールを整理するアシスタントです。
内容を分類し、対応が必要なものだけ返信ドラフトを作ります。

# 参照するもの
利用者が示したメールスレッドだけを参照します。
添付資料は、利用者が本文に貼った範囲だけを扱います。

# 進め方
1. スレッドを読み、次のいずれかに分類する
   - 見積・価格の回答
   - 納期の連絡
   - 技術的な問い合わせ・仕様確認
   - 不具合・クレーム対応
   - 案内・情報提供（対応不要）
2. 分類と、こちらの対応要否を示す
3. 対応が必要なものだけ、返信ドラフトを作る

# 出力形式
## 分類
種別 / 相手の区分（「メーカー」「協力会社」と書く）/ 対応要否

## 経緯
やり取りの流れを3行以内で。日付を含める

## 未回答の論点
こちらが答えていない質問と、先方からの回答待ち事項を分けて列挙する

## 返信ドラフト
対応が必要な場合のみ作る。ビジネス文体で書き、
確定していないことは「確認のうえ改めて回答します」とする

# 守ること
- 納期・価格・仕様を、メールに書かれていない値で埋めない
- 返信ドラフトに社内の検討状況・他社の見積内容を書かない
- 技術的な可否（提示された機器で代替できるか等）を判断しない。
  判断が要る点は「社内確認が必要」として挙げるにとどめる
- 相手先の社名を出力に書かない。設備の識別番号も書かない

# 分からないとき
分類が決まらないメールは「分類不能」とし、判断に必要な情報を質問する。

返信ドラフトは必ず人が読んでから送ってください

このエージェントの出力は社外に出る文面です。納期や価格の数値が1つ違うだけで商談条件が変わります。上の指示文は「書かれていない値で埋めない」で創作を止めていますが、送信前の確認は省略できません。

配布前の運用テスト¶

作った直後の動作確認だけでチームに配ると、想定外の振る舞いが現場で出ます。次の3つは配布前に必ず実施してください。

根拠の無い質問を投げる — 参照先に載っていない機器の手順を聞きます。「記載がありません」と返れば合格です。それらしい手順を作ったら、指示文の「守ること」を強めます
権限の違うメンバーに使わせる — 見えてはいけない文書が出ないか確認します。共有設定の点検漏れはここで出ます
既存の文書と突き合わせる — 過去に人が作った手順書・報告書と同じ題材で出力を比べ、差がどこに出るかを見ます

導入前に確認すること¶

エージェントの作成可否と費用は、会社のテナント設定と契約に依存します。作り始める前に情報システム部門へ確認してください。

自部門のメンバーがエージェントを作成し、部門内で共有してよいか
Copilot Studio を使える環境か。使える場合、利用料の負担がどうなるか
社内のAI利用ルールの最新版はどこにあるか

自動で動くエージェントは費用が読めません

人が起動せずに動くエージェント（新しいファイルが保存されたら要約する、といった設計）は、対話型より消費が大きく、意図せず費用が積み上がります。最初の1本は必ず対話型で作り、自動起動は効果を測ってから検討してください。

根拠¶

本ページが正典の範囲¶

本ページは「Copilot エージェントの仕組みと指示文の書き方」の正典です。Copilot 本体の機能と使い方は M365 Copilot活用、情報の取り扱いルール（入力禁止情報・データの行き先・出力検証義務）は注意事項・情報セキュリティが正典で、本ページの該当記述はそれらに従います。

原本未照合（honest-hold）¶

画面名・ボタン名・メニュー構成は記載していません。UI は更新で頻繁に変わるためです。実際の操作は使用中のバージョンの公式ヘルプに従ってください
費用の単価・課金体系は本ページでは扱いません。調査時点で公開されていた単価は二次情報であり、公式ライセンス資料との逐語照合をしていません。また契約形態は会社側で管理されるため、金額を前提にした判断は情報システム部門に確認してください
宣言型／カスタムエンジンの区分と、参照先の共有時の挙動は Microsoft の公開ドキュメントに基づきますが、自社テナントでの実挙動は未検証です。配布前の運用テストで確認してください

限界の明示¶

指示文サンプルは出発点であり、完成品ではありません。自部門の文書構成・安全基準に合わせた調整と、運用テストが前提です
指示文で振る舞いを完全に固定することはできません。指示は制約であって保証ではなく、出力の検証義務は利用者にあります
本ページの内容は会社契約の Microsoft 365 Copilot を前提としています。個人アカウントの Copilot には当てはまりません

正典参照¶

項目	正典
Copilot 本体の機能・アプリ別の使い方	M365 Copilot活用
入力禁止情報・データの行き先・ツール別の判断	注意事項・情報セキュリティ
プロンプトの書き方	プロンプトの書き方

照合日: 2026-09-17（Microsoft 公開ドキュメントでエージェントの区分・参照先の権限継承・共有時の挙動を確認。費用の単価は二次情報のため本文から除外し、未照合として明示）。

参考¶

🤖 この記事をChatGPTに渡す（プロンプト生成）

↗ ChatGPTを開く

使い方: コピー → ChatGPT で貼り付け → 質問を追記して送信。