GitHub Copilotに「Ansibleエキスパート」のペルソナを与えて開発を効率化する方法 -前編-

はじめに

こんにちは。株式会社エーピーコミュニケーションズの鈴木です。

GitHub Copilot、ただの「コード補完ツール」として使っていませんか？ 実は、近年のアップデートにより、プロジェクト独自のルールを教え込んだり、特定の役割（エージェント）を与えたりすることが可能になっています。

本記事のテーマは、GitHub Copilotによる「Ansible開発の最適化」です。

汎用的なAIに頼るのではなく、カスタム指示書（copilot-instructions.md）を使って「Ansibleのベストプラクティス」や「チームのコーディング規約」を学習させることで、開発効率とコード品質がどう変わるのかを検証しました。

今回は【前編】として、CiscoスイッチへのVLAN設定自動化を題材に、環境構築からPlaybookの「実装」までをAI主導で行うプロセスを解説します。

※本記事で作成・検証したコードの全量（Playbook、指示書、エージェント定義ファイルなど）は以下のGitHubリポジトリで公開しています。 ディレクトリ構成の確認や、実際に手元で動かす際にご活用ください。

https://github.com/gitdsuzuki/ansible-copilot

1.VS CodeでGitHub Copilotを使うための環境セットアップ

今回は以下の環境で検証を行いました。

まずはVS Codeから開発環境であるLinuxへリモート接続できている状態を前提にしています。設定手順は以下の記事などを参考にしてください。

• VS Code Ubuntu22.04に公開鍵認証でSSH接続してリモート開発する Windows

続いてVS Code上でGitHub Copilotが使えるように設定します。

• VS CodeでGitHub Copilotを設定する

最後に開発用にディレクトリを作成し、Pythonの仮想環境設定、Ansibleのインストールを行います。

daichi@ubuntu:~$ mkdir ansible-copilot
daichi@ubuntu:~$ cd ansible-copilot
daichi@ubuntu:~/ansible-copilot$ python3 -m venv venv
daichi@ubuntu:~/ansible-copilot$ source venv/bin/activate
(venv) daichi@ubuntu:~/ansible-copilot$ pip install ansible

これでGitHub Copilotを使ってAnsible開発を行う準備ができました。

2. GitHub CopilotにAnsibleのエキスパートになってもらう

GitHub Copilotの特徴的な点として、特定のニーズやコーディングスタイルに応じてカスタムできる機能があります。今回はこれを利用して、Copilotに「Ansibleのエキスパート」として働いてもらうことにしました。

以下の方針でカスタム設定を行います。

1. カスタム指示書: Ansible Playbookの一般的なコーディング規約などを記載し、Copilotの挙動に一貫性を持たせる。
2. カスタムエージェント:「開発」「レビュー」の2つの役割に特化したエージェントを作成し、タスクに応じて使い分ける。

2.1 カスタム指示書ファイルの作成

まずはカスタム指示書ファイル(copilot-instructions.md)を作成していきます。作業ディレクトリ内で.githubというディレクトリを作成し、その中に配置します。

(venv) daichi@ubuntu:~/ansible-copilot$ mkdir .github
(venv) daichi@ubuntu:~/ansible-copilot$ touch .github/copilot-instructions.md

次に指示書ファイルを記載していきます。公式サイトには以下の内容が例として書かれていました。

# Project general coding guidelines

## Code Style
- Use semantic HTML5 elements (header, main, section, article, etc.)
- Prefer modern JavaScript (ES6+) features like const/let, arrow functions, and template literals

## Naming Conventions
- Use PascalCase for component names, interfaces, and type aliases
- Use camelCase for variables, functions, and methods
- Prefix private class members with underscore (_)
- Use ALL_CAPS for constants

## Code Quality
- Use meaningful variable and function names that clearly describe their purpose
- Include helpful comments for complex logic
- Add error handling for user inputs and API calls

※出典： VS Code公式サイト より引用

VS Code公式サイトにはHTMLやJavaScript用の例が掲載されていますが、せっかくなのでCopilotに「Ansible Playbook用に書き直して」と依頼してみます。

GitHub Copilot Chatを開き、Agentモードで以下の様にプロンプトを入力しました。

その結果、以下のように修正してくれました！

---
applyTo: "**/*.yaml/*.yml/*.ini/*.md"
---
# Ansible Playbook 開発ガイドライン

## Playbook 構造
- 明確なディレクトリ構造で整理する (playbooks/, roles/, inventory/, group_vars/, host_vars/)
- 目的を示す説明的なPlaybook名を使用する（例: `deploy_webserver.yml`, `configure_database.yml`）
- Playbookは単一の責任または関連するタスクに焦点を当てる
- YAMLファイルの先頭に `---` を使用する
- コアモジュールには `ansible.builtin` コレクション接頭辞を含める

## YAML フォーマット
- インデントには2つのスペースを使用（タブは使用しない）
- 変数名、タスク名、ファイル名には snake_case を使用する
- 可能な限り行を120文字以内に収める
- リストと辞書には適切なYAML構文を使用する
- 特殊文字やJinja2変数を含む文字列は引用符で囲む

（略）

これで、よりAnsibleに特化し、かつ包括的な指示書ファイルを作成することができました。チームのコーディング規約をこのファイルに反映することで、Copilotがまるでチームの一員であるかのようにルールを守って動いてくれるようになります。

2.2 カスタムエージェントの作成

次にカスタムエージェントを作っていきます。 今回作成したのは、以下の2つ（2人？）です。

• Playbook_Developer: 開発担当
• Playbook_Reviewer: レビュー担当

それぞれの役割に特化したエキスパートとして働いてもらいます。ファイルは.github/agents配下に作成します。

(venv) daichi@ubuntu:~/ansible-copilot$ mkdir .github
/agents
(venv) daichi@ubuntu:~/ansible-copilot$ touch .github/agents/Playbook_Developer.md .github/agents/Playbook_Reviewer.md
(venv) daichi@ubuntu:~/ansible-copilot$ 

実行後、VS Codeからファイルが作成されていることが確認できます。

ファイル作成後、VS Codeのチャットモード選択から、作成した2つのカスタムエージェントが表示されることが確認できました。実行するタスクに応じてエージェントを選択することで、より最適化された開発やレビューを行うことができます。

続いてエージェントファイルの内容を記述します。公式サイトには以下の内容が例として書かれていました。

---
description: 'Review code for quality and adherence to best practices.'
tools: ['usages', 'vscodeAPI', 'problems', 'fetch', 'githubRepo', 'search']
---
# Code Reviewer agent

You are an experienced senior developer conducting a thorough code review. Your role is to review the code for quality, best practices, and adherence to [project standards](../copilot-instructions.md) without making direct code changes.

When reviewing code, structure your feedback with clear headings and specific examples from the code being reviewed.

## Analysis Focus
- Analyze code quality, structure, and best practices
- Identify potential bugs, security issues, or performance problems
- Evaluate accessibility and user experience considerations

## Important Guidelines
- Ask clarifying questions about design decisions when appropriate
- Focus on explaining what should be changed and why
- DO NOT write or suggest specific code changes directly

※出典： VS Code公式サイト より引用

指示書ファイルと同じくチャットから修正を行ってみましょう。

ここでも工夫として、「あなたはネットワーク機器の自動化に特化したAnsible Playbook開発/レビューのエキスパートです」とCopilotに事前に伝え、より業務に特化したエージェントを作成しました。

---
description: 'ネットワーク機器の自動化に特化したAnsible Playbook開発のエキスパート'
---
# Network Automation Playbook Developer エージェント

あなたはネットワーク自動化のエキスパートとして、Cisco、Juniper、Arista、その他のネットワーク機器を対象としたAnsible Playbookとロールを開発します。[プロジェクト標準](../copilot-instructions.md)に従い、信頼性が高く、スケーラブルで、保守可能なネットワーク自動化ソリューションを提供します。

略

注意点: 公式の例にあるtools:プロパティを省略すると、エージェントはすべての権限を持ちます。特定の権限（例：レビュー用エージェントには編集権限を持たせない等）を設定したい場合は、チャットの設定から編集してください。

それでは実際にCopilotを使ってPlaybookを作成していきましょう。

3. GitHub CopilotにAnsible Playbookを作成してもらう

いよいよ開発です。Playbook_Developerエージェントを指定し、作成したいPlaybookの内容をプロンプトで指示します。

Playbookや設定ファイルが作成され、ディレクトリ構成は以下のようになりました。

作成されたPlaybookを確認すると、かなりしっかりしたものが出来上がっていました。 特筆すべきは、READMEファイルも自動作成されており、概要から事前準備、実行方法まで分かりやすく書かれていた点です。普段、こうしたドキュメント作成は後回しにしがちなので、Copilotが網羅してくれるのは非常に便利だと感じました。

せっかくなのでREADME.mdの手順を実施して、実際に設定投入まで行えるか確認してみましょう。

検証用にスイッチ２台をCML上に作成し、SSH接続が出来るよう設定を行いました。これらのスイッチにVLANを設定を投入できるか確認してみます。

3.1 準備

それではREADME.mdの手順（必要なものだけ）に従い、検証用環境（CML上のCiscoスイッチ2台）への設定投入を試みます。

まず、inventories/production/group_vars/vault.ymlに認証情報を記述します。

ansible_user: "your_username"
ansible_password: "your_password"
ansible_become_password: "your_enable_password"

ここで注目したいのが、機密変数の暗号化にansible-vaultの使用が前提になっていることです。これはカスタム指示書で「機密変数はAnsible Vaultを使用する」と指定した効果が出ていると言えます。

認証情報を書いた後、ansible-vaultでファイルを暗号化します。

(venv) daichi@ubuntu:~/ansible-copilot$ ansible-vault encrypt inventories/production/group_vars/vault.yml
New Vault password: 
Confirm New Vault password: 
Encryption successful

次に、inventories/production/group_vars/cisco_iosxe.ymlに追加するVLAN情報を記述します。

vlans:
  - vlan_id: 100
    name: "production"
    state: "active"
  - vlan_id: 200
    name: "development"
    state: "active"
  - vlan_id: 300
    name: "management"
    state: "active"

最後に、inventories/production/hosts.ymlにCiscoスイッチ２台のインベントリの情報を記述します。

cisco-sw1:
  ansible_host: 192.168.11.201  # 実際のIPアドレスに変更
cisco-sw2:
  ansible_host: 192.168.11.202  # 実際のIPアドレスに変更

以上で準備手順が完了です。

3.2 実行方法

README.mdには「dry-run」「タグ付き実行」「ホスト指定実行」など、数種類の実行例が記載されていました。実際の案件でも使える丁寧な記述です。こういった丁寧な記述は「面倒ですが非常に価値がある作業」で、積極的にCopilotにやってもらうのが良さそうです。

まずは dry-run を実行してみます。

daichi@ubuntu:~/ansible-copilot$ ansible-playbook -i inventories/production playbooks/deploy_vlans.yml --check  --ask-vault-pass

すると、以下のエラーが発生しました。

TASK [必須変数が定義されているか確認]
[ERROR]: Task failed: Action failed: 必須変数が定義されていません。インベントリとgroup_varsを確認してください。

原因を確認すると、group_vars配下のファイル名がvault.ymlとなっており、グループ名と一致していなかったため読み込まれていませんでした。ファイル名をall.ymlに変更して再実行します。

[ERROR]: 'ansible_date_time' is undefined

gather_facts: noと設定されていたため、ansible_date_time変数が取得できていませんでした。ここも修正します。

- filename: "{{ inventory_hostname }}_{{ ansible_date_time.iso8601_basic_short }}.cfg"
+ filename: "{{ inventory_hostname }}_{{ lookup('pipe', 'date +%Y%m%dT%H%M%S') }}.cfg"

修正後、dry-runは成功。続いて本番実行を行います。

daichi@ubuntu:~/ansible-copilot$ ansible-playbook -i inventories/production playbooks/deploy_vlans.yml --ask-vault-pass

（略）
PLAY RECAP ********************************************************************************************************************************
cisco-sw1                  : ok=14   changed=4    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0
cisco-sw2                  : ok=14   changed=4    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

(venv) daichi@ubuntu:~/ansible-copilot$

無事に成功しました！ バックアップコンフィグや比較検証ログもしっかり保存されています。

実行結果のログ（抜粋）

【適用前】
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Et0/0, Et0/1, Et0/2, Et0/3
1002 fddi-default                     act/unsup 
1003 token-ring-default               act/unsup 
1004 fddinet-default                  act/unsup 
1005 trnet-default                    act/unsup

【適用後】
VLAN Name                             Status    Ports
---- -------------------------------- --------- -------------------------------
1    default                          active    Et0/0, Et0/1, Et0/2, Et0/3
100  production                       active    
200  development                      active    
300  management                       active    
1002 fddi-default                     act/unsup 
1003 token-ring-default               act/unsup 
1004 fddinet-default                  act/unsup 
1005 trnet-default                    act/unsup

こうして、GitHub Copilotに作ってもらったPlaybookを実行し、動作を確認できました。 ただ、文法ミスや変数参照の誤りがいくつかあり、「生成されたコードがそのまま100%使える」という状況ではまだないようです。

1からPlaybookを作成するより効率は格段に上がりますが、エラー原因を特定し修正するための基本的なAnsibleスキルは、依然として必要だと感じました。

おわりに

GitHub Copilotにペルソナ（役割）を与える開発手法、いかがでしたでしょうか。

特筆すべきは、単なるコード補完にとどまらず、「プロジェクトの作法（Instruction）」を理解した上で自律的に動いてくれる点です。特にインフラコードは命名規則やディレクトリ構成がバラバラになりがちですが、Copilotを介することでチーム全体の標準化にも寄与しそうだと感じました。

ただし、実行結果で見たように、生成されたコードが100%完璧とは限りません。だからこそ重要になるのが「コードレビュー」のプロセスです。

続く【後編】では、今回作成した「Playbook_Reviewer（レビュー特化エージェント）」を活用し、AIによるコードレビューの精度と、開発サイクル全体を通した効率化について検証していきます。