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

はじめに

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

【前編】では、カスタム指示書と「開発用エージェント（Playbook_Developer）」を用いて、Cisco IOSXE向けのVLAN設定自動化Playbookを作成しました。

しかし、AIが生成したコードには、まだ改善の余地や潜在的なバグが潜んでいる可能性があります。 そこで【後編】となる今回は、もう一人のエージェント「Playbook_Reviewer」に登場してもらい、AIが書いたコードをAI自身にレビュー・修正させるプロセスを検証します。

また、開発ガイドラインの変更への追従や、ドキュメント（コメント）生成など、実務で役立つCopilot活用テクニックも併せて紹介します。

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

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

4. GitHub CopilotにAnsible Playbookをレビューしてもらう

それでは、前回作成したPlaybookをレビュー用エージェントである「Playbook_Reviewer」にチェックしてもらいましょう。

プロンプトはシンプルに「このワークスペースのPlaybookのレビューしてください。」としてみます。

なお、重要なポイントとして、Playbook_Reviewerにはファイルの編集権限を持たせていません。 あくまで指摘出しに徹してもらい、修正するかどうかは人間（または開発用エージェントへの指示）が判断する運用にします。

Playbook_Reviewerから返ってきたレビュー結果は以下の通りです。良い点と改善が必要な点を整理して教えてくれました。

最後には確認事項および優先順位の設定をしてくれていました。

指摘内容は非常に的確だと感じました。特に確認事項や優先順位付けまで行ってくれる点は、人間がレビューする際の手間を大きく省いてくれます。指摘自体は熟練のエンジニアなら気付けるレベルですが、「網羅的に・瞬時に」指摘してくれるのがAIレビューの最大の強みだと感じました。

5. GitHub CopilotにAnsible Playbookを修正してもらおう

レビューで得られた指摘をもとに、今度はCopilotに修正を依頼します。

今回は指摘事項のうちすべてではなく一部を修正することにします。 他のレビュー結果は レビュー結果.md としてGitHubに保存していますので、よろしければ実際のコードと併せて確認してみてください。

5.1 レビューの指摘事項の修正

まず、レビューで「セキュリティリスク」と指摘された以下の箇所を修正します。

2. YAMLフォーマットの統一性
問題: deploy_vlans.yml:44-45 に不要なデバッグタスクが残っている

理由:

タスク名とタスク内容が一致していない（ansible_date_time を表示するという名前だが ansible_user を表示）
本番環境で認証情報を表示するのはセキュリティリスク
推奨:

このタスクが不要であれば削除する
必要であれば no_log: true を設定し、タスク名を修正する

問題のコード(deploy_vlans.yml)：

# 前回のエラー調査用コードが残ってしまっていた
- debug:
    var: ansible_user

このままではVaultで暗号化したはずの認証情報がログに出力されてしまいます。

チャットで「Playbook_Developer」を指定し、修正を依頼します。

結果、依頼通り該当のタスクのみがきれいに削除されました！

5.2 コーディングポリシーの更新

次に、実務的なシナリオとして「チームの開発ガイドラインが途中で変更された場合」を試してみます。

新たに以下のポリシー:

• boolean値は yes/no を使用せず、 true/false に統一する

これを手動ですべて書き換えるのは手間ですが、Copilotならすぐにやってくれます。 ここでの工夫は、いきなりコードを直させるのではなく、「まず指示書（Instructions）を更新し、それを元にコードを修正させる」という2段階の手順を踏むことです。

Step 1: 指示書の更新

コンテキストに copilot-instructions.md とエージェントファイルを指定し、ポリシーの変更を伝えます。

結果、こちらの意図通りに指示書ファイルとエージェントファイルにポリシーを反映してくれました！

Step 2: コードへの反映

指示書が更新された状態で、Playbookの修正を依頼します。

結果、Playbook内の become: yes が become: true に書き換わるなど、新しいルールが正しく適用されました。

このように「ルール（指示書、エージェントファイル）→ 実装」の順でAIを操作することで、プロジェクト全体の一貫性を保ちやすくなりました。

6. GitHub CopilotにAnsible Playbookへコメントを書いてもらう

コード内のコメントは、新メンバーのキャッチアップや将来の保守において極めて重要です。 私自身、コメントは「あればあるほど良い」と考えていますが、詳細なコメントを書くのは開発者にとって負担が大きい作業でもあります。

そこで私が最もおすすめするCopilot活用法が、「事後コメント追記」です。 やり方は簡単で、チャットで「Playbookに詳しいコメントを書いてください」と依頼するだけです。

これだけで、Copilotが処理の内容を解釈し、非常に丁寧で分かりやすいコメントをコードに埋め込んでくれました。 「Copilotをどう使っていいか分からない」という方は、まずこのコメント生成から始めてみるのがおすすめです。

7. GitHub CopilotにAnsible Playbookの詳細を質問しよう

最後に紹介するのは、チャット機能を使ってコードベースについて質問する方法です。 単に開いているファイルだけでなく、ワークスペース全体を考慮して回答させることができます。

7.1 暗黙的なコンテキスト

Copilotは通常、現在開いているファイルをコンテキスト（文脈）として読み取りますが、チャット欄で明示的にファイルを指定することも可能です。

例えば、 deploy_vlans.yml と copilot-instructions.md の2つを同時に参照させたい場合、チャット入力欄の「＋（添付）」ボタンや、ドラッグ＆ドロップでファイルを追加することで、それらにフォーカスした回答を得られます。

他にもチャット内の左上のホッチキスマークから、様々なファイル・コンテキストを追加できます。

7.2 @workspaceコマンドの活用

ワークスペース全体（プロジェクト全体）を横断して調査したい場合は、 @workspace コマンドが有効です。

プロンプト例：

@workspace このPlaybookの変数はどこで定義されていますか？

7.3 #fetchで参照するWebのURLを指定

#fetch を使うことで参照したいURLを指定できます。

ansible-core 2.20の大きな変更点を教えてください #fetch https://github.com/ansible/ansible/blob/stable-2.20/changelogs/CHANGELOG-v2.20.rst

その他にも便利なコマンドがあり、これらをうまく使うことで複雑なプロジェクトでも内容を把握するための大きな助けになります。

おわりに

前編・後編にわたり、GitHub Copilotに「Ansibleエキスパート」という人格を与えて開発を行ってみました。

一連の検証を通して感じたのは、AIを利用することでエンジニアの仕事や役割が徐々に変化していくという実感でした。

以前なら時間をかけて調べていた構文エラーや、面倒で後回しにしがちなコメント記述。これらをAIに任せることで、人間は「全体の設計」や「安全性の判断」といった、より本質的な業務に集中できるようになります。

もちろん、AIは完璧ではありません。しかし、今回のように「開発担当」と「レビュー担当」を分け、適切なルール（指示書）を与えることで、その精度は飛躍的に高まります。

これからのインフラエンジニアには、Ansibleの知識だけでなく、こうした「AIを使いこなすためのプロンプトエンジニアリング力」も必須スキルになっていくのかもしれません。