💡 この記事のポイント
- CopilotStudio ライセンスの活用 でAIコードレビュー環境を構築！
- ローコード（プロンプト＋標準コネクタのみ） でお手軽に実装！
- 自社のコーディング規約（
.mdファイル）を読み込ませた 「自社専用シニアエンジニア」 を召喚！
はじめに：そのAIライセンス、眠らせていませんか？
日々の開発業務で欠かせない「コードレビュー」。品質担保の要である一方、レビュアーの負担が大きくなりがちな工程でもあります。
実は私自身、これまで開発効率を上げるために自腹で GitHub Copilot のライセンスを購入して活用していました。しかしある日、ふと会社の環境を見渡してみると、会社では Microsoft 365 Copilot と Microsoft Copilot Studio のライセンスがすでに利用できる状態になっていることに気づいたのです。
「あれ……？ Copilot Studioのエージェントを使えば、GitHub Copilotの全機能は再現できなくても、Azure DevOpsのAIコードレビューくらいなら作れるのでは？」
調べてみると、Copilot Studioのエージェントでは Azure DevOps REST API が標準コネクタとして利用できる ことが判明しました。「これなら、エージェントのプロンプト（指示文）と標準ツールを組み合わせるだけで、お手軽に自社専用のコードレビューエージェントが作れるのでは？」と思い立ち、実際に試してみたところ……驚くほど実用的なエージェントが作れました！
そこで本記事では、同じようにMicrosoft 365環境とAzure DevOpsを利用しているエンジニアに向けて、自社コードレビューエージェントの作り方と、実装時にハマったエラーの回避策（Tips） を前後編に分けて共有します。
📝 AIレビューは「人間のレビューの補助」です
本記事のエージェントは、レビュアーの負担を減らすための 一次チェック役 であり、人間のレビューを置き換えるものではありません。
- AIは問題を見落としたり、正しいコードを誤って指摘したりすることがあります
- 仕様や業務要件、設計の背景など、コードに書かれていない文脈は判断できません
- 指摘はそのまま採用せず、最終的な判断とマージの承認は必ず人間が行ってください
AIが機械的に拾える指摘を先に片付けておき、人間は設計や仕様の妥当性といった本質的なレビューに集中する、という使い方をおすすめします。
本記事（前編）のゴールと作り方の流れ
前編では、Copilot Studioでエージェントを作成し、Azure DevOpsのリポジトリ差分を取得してレビュー結果を出力させ、TeamsやMicrosoft 365 Copilotチャットへ公開するまでを以下の8ステップで解説します。
- Copilot Studioのエージェント作成
- エージェントのモデル選択
- 指示文（プロンプト）とナレッジの設定 👈 自社規約を注入！
- ツールの設定 👈 最大のハマりどころ解説あり！
- エージェントのテスト
- エージェントの公開
- エージェントのインストール
- エージェント使用時のTipsと次なる課題
それでは、さっそく作っていきましょう！
1. Copilot Studioのエージェント作成
まずはベースとなるエージェントを作成します。
Copilot Studioの左メニューから「エージェント」一覧を開き、右上の 「新しいエージェント」ボタン横にある矢印メニュー（∨） を開きます。
表示されたメニューから 「エージェント（標準）」 をクリックし、ドラフト状態のエージェントを作成してください。
2. エージェントのモデル選択
続いて、エージェントの名前（例：ソースコードレビュー）を設定し、頭脳となるAIモデルを選択します。
「詳細」セクションの「エージェントのモデルを選択します」プルダウンから、お好きなモデル（GPT-5系やClaude Sonnet / Opusなど、環境で利用可能なモデル）を選択してください。ソースコードの文脈理解や論理的思考が求められるため、推論能力の高いモデルを選ぶのがおすすめです。
3. 指示文（プロンプト）とナレッジの設定
ここがエージェントの「人格」と「レビュー品質」を決める最重要パートです。
概要タブの「指示」にある 「編集」ボタン からプロンプトを、「ナレッジ」の 「＋ナレッジを追加」ボタン から自社のコーディング規約等を設定します。
指示文（プロンプト）のテンプレート
指示文はいわゆるシステムプロンプトとなります。
単なるレビュー観点だけでなく、「APIレスポンス（JSON）からの抽出ルール」「削除ファイル（404）の除外ルール」「万が一の事故を防ぐ禁止事項」 を明記するのがポイントです。以下は実際に使用している指示文の例ですので、自社の技術スタックに合わせて適宜変更してお使いください。
# 指示
あなたはAzure DevOpsと連携して高度なコードレビューを行う、シニアソフトウェアエンジニアです。
ツールでAzure DevOps APIのレスポンス（JSON）を取得した場合は、解析してレビュー対象に含めてください。
### タスク指示
1. 提供されたJSONデータから、ソースコードの本文、または変更された差分 (diff/内容) を示すフィールドを抽出・解釈してください。
2. URL、作成者ID、タイムスタンプなどのメタデータは無視し、コードのロジックのみに集中してください。
3. 抽出したコードに対し、以下の観点で厳格かつ建設的なレビューを行ってください。
4. ソースコードの修正箇所を提示する際は、修正箇所と修正するファイルの完全なソースコードも提示してください。
5. 削除された (REST APIで404で取得できない) ファイルは、レビュー対象から除外してください。
### レビュー観点
* セキュリティ: インジェクション対策、認証・認可、機密情報のハードコード。
* パフォーマンス: ループ処理の最適化、N+1問題、メモリ確保の削減。
* 保守性: SOLID原則、命名規則、依存性の注入(DI)。
* Angular/TypeScript: コンポーネント分割、RxJSのメモリリーク対策、厳格な型定義。
* C#/ASP.NET Core/Azure Functions: 非同期処理の適切な実装、ステートレス設計、リソース管理。
### 出力フォーマット
以下のMarkdown形式で出力してください (JSONの構造や抽出プロセスは出力に含めないこと)。
## コードレビュー結果
対象: [対象リポジトリ] / [対象ブランチ・ID]
### サマリー
[コードの全体的な印象や重要な指摘事項]
### 良かった点 (Good)
* [評価できる実装]
### 改善提案 (Needs Improvement)
* **[🚨致命的 / ⚠️要改善 / 💡推奨] [技術要素]:** [指摘内容]
* **理由:** [なぜ修正が必要か]
* **提案コード:** [具体的な修正案]
### 禁止事項
Azure DevOpsへのソースコード編集、Gitコミット、Gitプッシュ、マージ、ブランチ削除、プルリクエストの作成・更新を行う作業を禁止します。
ナレッジ追加のコツ（.md ファイルはここに注意！）
ナレッジ機能を使えば、自社のコーディング規約や設計ガイドラインをエージェントに記憶させることができます。
SharePoint上にある Officeドキュメント（Word / Excel / PowerPoint）やPDF などは、SharePointコネクタ経由で簡単に追加できます。
しかし、OfficeドキュメントやPDF以外のファイルについては「ひと手間」が必要です！
エンジニアの現場では、コーディング規約などを Markdownファイル（.md） で管理しているケースが多いですよね（例：typescript.instructions.md、csharp.instructions.md、angular.instructions.md、sql.instructions.md など）。
これらの .md ファイルをナレッジに追加したい場合は、SharePoint経由ではなく、一度ローカルPCにファイルとして用意し、「ファイルをアップロードする」から直接アップロード を行ってください。アップロードされたテキストベースのファイルは、裏側の Dataverse に格納されます。
4. ツールの設定（最重要ポイント）
次に、エージェントがAzure DevOpsのコードを見に行けるように「ツール」を追加します。
「ツール」セクションの 「＋ツールを追加する」 ボタンをクリックします。
検索窓で azure devops と検索し、「Azure DevOps に HTTP 要求を送信する」 をクリックして追加します。
⚠️ ハマりどころ：JsonReaderException を回避する魔法の呪文
「Azure DevOps に HTTP 要求を送信する」コネクタを使ってGitのファイル内容（Items API）をそのまま取得しようとすると、APIのデフォルト仕様で出力レスポンスが生テキスト（ソースコード文字列そのまま）で返ってきてしまいます。
すると、レスポンスをJSONとして解釈しようとするCopilot Studio側で JsonReaderException ('/' is an invalid start of a value) が発生してエラーになってしまいます。
これを防ぐため、ツールの 「説明」欄 に以下の指示文を必ず追記します。
Azure DevOpsのGit ファイル内容 (items API) を取得する際は、
必ず URI のクエリパラメータに 「$format=json」 と 「includeContent=true」を
含めること。これを指定しないと、レスポンスが生テキストで返り、
JsonReaderException ('/' is an invalid start of a value)が発生する。
ファイル内容は、レスポンス JSON の "content" フィールドから取得すること。
また、ツールの説明欄に書いておくだけでもAIが解釈してクエリパラメータを変換してくれますが、「お守り」として画面下部の「完了 ＞ 出力（Response）の説明」欄にも同じ指示文を記述しておく と、より動作が安定するのでおすすめです。
入力パラメータの固定化とセキュリティ対策
ツールの「入力」では、各項目の値を「AIで動的に入力する」か「カスタム値」で固定するかを選べます。今回は次のように設定します。
| 入力項目 | 設定 | 値 | 理由 |
|---|---|---|---|
| Organization Name | カスタム値 | 自社の組織名 | 毎回チャットで組織名を指定する手間を省くため |
| Method | カスタム値 | GET | 読み取り専用にして、書き込み系のAPIを確実にブロックするため |
| Relative URI | AIで動的に入力する | － | 差分取得やファイル取得など、AIに必要なAPIを組み立ててもらうため |
💡 ワンポイント：Method を GET に固定してAIの暴走を防ごう
Method まで「AIで動的に入力する」にすると、AIが更新系のリクエスト（POST / PATCH / DELETE）を組み立ててしまう可能性があります。しかも、その操作は利用者本人の権限で実行されます。
コードレビューに必要な API（差分取得の Diffs - Get、ファイル内容取得の Items - Get）はすべて GET なので、Method を GET に固定しても機能は損なわれず、書き込み系の操作だけを確実に防げます。
ステップ3の指示文に入れた ### 禁止事項 もAIの振る舞いを抑える効果がありますが、プロンプトによる制御はあくまで「お願い」です。GET固定を主な対策、禁止事項を補助として組み合わせてください。
補助ツールの追加
HTTP要求ツールに加えて、AIがプロジェクトやリポジトリ、ブランチの構造を探索できるように、以下の3つの標準ツールも同様の手順で追加します。
- Git ブランチを一覧表示する
- Git リポジトリを一覧表示する
- プロジェクトの一覧表示
入力設定は先ほどと同様に、変更しない組織名（Organization Name）を 「カスタム値」で固定化 しておきます（これらのツールは読み取り専用のため、Methodの設定はありません）。
5. エージェントのテスト
ここまで設定できたら、画面右側に表示されている「エージェントをテストする」チャット欄で動作を確認してみましょう！
以下のように、プロジェクト名・リポジトリ名・比較したいブランチ名を具体的に投げてみます。
○○○○プロジェクトの△△△△リポジトリのdevelopブランチと、bugfix/xxxxxx ブランチの差分ファイルをレビューして
すると、エージェントが裏側で連続してAzure DevOpsへHTTP要求を送信し、差分ファイルを特定・取得したうえで、指定したMarkdownフォーマット通りに「サマリー」「良かった点」「改善提案」を出力してくれました！
6. エージェントの公開
動作確認ができたら、社内メンバーが使えるように公開します。
1. 上部メニューの 「チャネル」タブ を開き、「Microsoft 365 と Microsoft Teams」 をクリックします
2. 右側に開くパネルの下部にある 「チャネルを追加する」 ボタンをクリックします
3. 続いて画面上部の 「公開」 ボタンをクリックします
- ※すでに公開済みのエージェントを更新し、変更をユーザーへ即座に反映させたい場合は、確認ダイアログ内の 「最新バージョンを強制する」 にチェックを入れて公開します。
利用者の範囲を設定する（可用性オプション）
公開ボタンを押しただけでは、まだ作成者本人しか使えません。エージェントの利用者を別途指定する必要があります。
1. チャネル設定パネルの下部にある 「可用性オプション」 ボタンをクリックします
2. 「ストアに表示する」 カテゴリの中から、共有したいユーザーの範囲（チームメイトと共有ユーザーに表示する または 組織内の全員に表示する）を選択して設定します。
7. エージェントのインストール
公開と共有設定が完了したら、実際に普段使っているCopilotへインストールしてみましょう。
1. チャネル設定パネルに戻り、「Microsoft 365 でエージェントを表示する」 をクリックします
2. Copilotの画面が立ち上がり、作成したエージェントのポップアップが表示されるので 「追加」 ボタンを押します
- ※他のメンバーにエージェントを共有する際は、「追加」ボタンの横にある 「共有（リンク）」アイコン からインストールURLをコピーして配るとスムーズです
Copilotチャットの左サイドバー「エージェント」欄に、作成した 「ソースコードレビュー」 が表示されたら導入完了です！
8. エージェント使用時のTipsと「見えてきた課題」
💡 Tips：初回利用時の接続許可について
ツールで追加したAzure DevOpsコネクタの接続は、既定で 「各ユーザーの認証（資格情報）による接続」 となります。
そのため、各ユーザーがエージェントを初回利用する際は、「接続して続行する」という確認カードが表示されます。ここで 「許可」 をクリックしてもらう必要がありますが、一度許可すれば設定が記憶されるため、次回からは表示されずにすぐ利用できます。
🤔 見えてきた課題：「ざっくりした指示」だと404エラーになる問題
さて、これで社内ライセンスを活用した「自社専用コードレビューエージェント」が無事に稼働し始めました！
……と言いたいところなのですが、実際に使っていくうちに ある課題 が浮き彫りになってきました。
テスト時のように「○○プロジェクトの△△リポジトリの……」と 的確な情報 をチャットで指定すれば問題なくレビューできるのですが、以下のように ざっくりしすぎたチャット を投げた場合どうなるでしょうか？
○○についてレビューして
すると、エージェントが「AIで動的に入力する」設定になっているAPI引数（Project Name など）を曖昧な情報から推測して埋めてしまい、ツール側で該当する情報を見つけることができず 404 HTTP エラー（ConnectorRequestFailure） となって止まってしまうのです……！
毎回一字一句正確なプロジェクト名やリポジトリ名、ブランチ名を人間が調べて手入力するのは、少し手間ですよね。
そこで次回の 【後編】 では、「ざっくりした指示でも404エラーを起こさず、スマートにレビューを完遂させるためのエージェント改善方法」 を共有したいと思います！
「この記事が参考になった！」「後編も気になる！」という方は、ぜひ いいね👍 とストック📁、フォロー をよろしくお願いします！それでは【後編】でお会いしましょう！