先生と生徒の会話形式で理解しよう

生徒

「Azure DevOpsでパイプラインを動かしたいのですが、会社の厳しいセキュリティルールでクラウド上の共有マシンが使えないんです。どうすればいいですか？」

先生

「それなら『セルフホストエージェント』を構築するのが一番ですね。自分たちの仮想マシンやオンプレミスサーバーをビルド環境として登録できる仕組みですよ。」

生徒

「自分専用のビルドサーバーを作るということですね！設定は難しいのでしょうか？」

先生

「手順を追えば初心者の方でも大丈夫です。独自のツールをインストールしたり、ネットワーク制限をかけたりと自由自在ですよ。具体的な作り方を解説しましょう！」

1. Azureセルフホストエージェントとは？

Azure DevOps（アジュール・デブオプス）のパイプラインを実行する際、通常はマイクロソフトが用意した「Microsoft-hosted agent（マイクロソフト・ホステッド・エージェント）」が使われます。しかし、特定のソフトウェアが必要だったり、社内ネットワーク内のリソースにアクセスしたかったりする場合には、自分たちで管理するマシンをエージェントとして利用する必要があります。これがセルフホストエージェント（Self-hosted agent）です。

読み方は「セルフホストエージェント」で、直訳すると「自分で主催・管理する代理人」という意味になります。ビルド（プログラムを動かせる形に組み立てること）やデプロイ（サーバーに配備すること）といった作業を、自分の好きなスペックのパソコンやサーバーに肩代わりさせるイメージです。特に、機密性の高いデータを扱うプロジェクトや、巨大なソースコードを高速に処理したい場合に非常に有効な手段となります。

2. セルフホストエージェントを導入するメリット

なぜ標準の環境ではなく、わざわざ自分で環境を作るのでしょうか。最大の理由はカスタマイズ性とセキュリティにあります。標準環境では、実行のたびにクリーンなマシンが割り当てられるため、重いライブラリのダウンロードに時間がかかることがあります。しかし、セルフホスト環境であればキャッシュを活用して時間を短縮できます。

また、VNET（仮想ネットワーク）の中に配置することで、インターネットに公開していないデータベースやファイルサーバーと通信しながらテストを行うことも可能です。企業独自のセキュリティポリシー（機密保持規定）に従った運用ができるため、エンタープライズ（大規模企業）開発では必須の知識といえるでしょう。

3. 事前準備とパーソナルアクセストークンの発行

エージェントを構築する前に、Azure DevOpsと通信するための「合言葉」を作成する必要があります。これをPAT（Personal Access Token：パーソナル・アクセス・トークン）と呼びます。これはパスワードの代わりになる非常に重要な文字列です。

Azure DevOpsの設定画面から「User settings」を選択し、「Personal access tokens」をクリックして新しいトークンを発行します。スコープ（権限）は「Agent Pools (Read & Manage)」を選択しましょう。このトークンは一度しか表示されないので、必ずメモ帳などに控えておいてください。

ここでは、エージェント情報を管理するための簡単なデータベース構成例を見てみましょう。管理台帳を作る際のイメージです。


id | agent_name   | status  | pool_name
---+--------------+---------+------------
1  | BUILD-SRV-01 | Online  | Default
2  | BUILD-SRV-02 | Offline | Default
3  | TEST-NODE-A  | Online  | TestingPool
4  | LINUX-AGT-01 | Online  | LinuxPool

このように、複数のエージェントを「エージェントプール」というグループで管理することが一般的です。

4. Linux環境でのエージェントインストール手順

それでは、実際にLinux（リナックス）サーバーにエージェントをインストールしてみましょう。まずは公式サイトからエージェントのパッケージをダウンロードし、解凍します。コマンドラインでの操作になりますが、一つずつ実行すれば怖くありません。


mkdir myagent && cd myagent
wget https://vstsagentpackage.azureedge.net/agent/3.225.0/vsts-agent-linux-x64-3.225.0.tar.gz
tar zxvf vsts-agent-linux-x64-3.225.0.tar.gz
./config.sh

./config.shを実行すると、対話形式で設定が始まります。サーバーのURLや先ほど作成したPATを入力することで、自分のマシンがAzure DevOpsに登録されます。登録が完了すると、管理画面に自分のパソコンの名前が表示されるようになります。

5. エージェントをサービスとして登録・実行する

設定が終わっただけでは、パソコンを再起動したときにエージェントが止まってしまいます。そのため、OSの起動と同時に自動で動き出すサービス（Service）として登録しましょう。これにより、人間がログインしていなくても裏側で常にビルドを待ち構えてくれるようになります。


sudo ./svc.sh install
sudo ./svc.sh start
sudo ./svc.sh status
active (running) since Tue 2026-03-31 10:00:00 JST

これで、セキュアなビルド環境が常駐するようになりました。ファイアウォールの設定で、外部からの入力（インバウンド）を許可する必要はありません。エージェント側からAzure DevOpsへ通信（アウトバウンド）ができれば動作するため、ネットワークセキュリティ的にも非常に安全な仕組みです。

6. パイプライン（YAML）での呼び出し方

作成した独自のビルド環境をパイプラインから使うには、設定ファイルであるYAML（ヤムル）ファイルに「どのプールを使うか」を記述します。デフォルトの記述を書き換えるだけで、すぐに独自の環境で処理が走り出します。


pool:
  name: 'Default'
  demands:
    - agent.name -equals BUILD-SRV-01

steps:
- script: echo "自前のサーバーでビルドを開始します！"
  displayName: '実行テスト'

上記のようにpoolセクションで名前を指定することで、特定のセルフホストエージェントを指名してジョブを実行させることができます。非常に柔軟ですね。

7. セキュリティ強化とメンテナンスのコツ

運用を始めた後に大切なのがメンテナンスです。エージェントソフト自体は、Azure DevOpsが自動でアップデートしてくれる機能がありますが、サーバーOS自体のセキュリティパッチ適用は自分たちで行う必要があります。また、ビルドで発生した一時ファイルがディスクを圧迫することがあるため、定期的な掃除も欠かせません。

安全性を高めるために、エージェントを実行するユーザーには最小限の権限（一般ユーザー権限）のみを与え、管理者権限での実行は避けるようにしましょう。また、不要なツールはインストールせず、必要最小限の環境を保つことが、攻撃リスクを減らす近道となります。

8. トラブルシューティングとログの確認

もしパイプラインが動かない場合は、エージェントのログを確認しましょう。インストールディレクトリにある「_diag」フォルダの中に、詳細な通信記録が残っています。初心者の方が陥りやすいミスとしては、「PATの期限切れ」や「プロキシサーバーの設定漏れ」が挙げられます。

ネットワークの状態を確認する簡単なスクリプトを書いて、接続テストを行うのも良い方法です。例えば、特定のポートが開放されているか確認するプログラムを事前に走らせておくと、原因の特定が早まります。


using System;
using System.Net.NetworkInformation;

class ConnectionCheck
{
    static void Main()
    {
        Ping pingSender = new Ping();
        PingReply reply = pingSender.Send("dev.azure.com");

        if (reply.Status == IPStatus.Success)
        {
            Console.WriteLine("Azure DevOpsへの接続は正常です！");
        }
        else
        {
            Console.WriteLine("接続に失敗しました。ネットワークを確認してください。");
        }
    }
}

実行結果は以下のようになります。


Azure DevOpsへの接続は正常です！

9. 実践的なSQLによるビルド履歴の管理

最後に、セルフホストエージェントで行ったビルド結果をデータベースで集計するシーンを想定してみましょう。どのエージェントがどれくらい働いているかを可視化するのは、リソース計画を立てる上で重要です。


id | build_id | agent_id | result  | duration_sec
---+----------+----------+---------+-------------
1  | 101      | 1        | Success | 120
2  | 102      | 1        | Failed  | 45
3  | 103      | 3        | Success | 300
4  | 104      | 4        | Success | 150

このデータから、失敗したビルドだけを抽出して原因を調査するSQL文は次のようになります。


SELECT build_id, agent_id, duration_sec
FROM build_history
WHERE result = 'Failed'
ORDER BY duration_sec DESC;

このように、独自の環境を構築することで、ログの収集から分析まで自分たちの思い通りに制御できるようになります。セルフホストエージェントは、プロフェッショナルな開発現場への第一歩といえるでしょう。

まとめ

今回の記事では、Azure DevOpsにおけるセルフホストエージェント（Self-hosted agent）の構築方法から運用、セキュリティ対策、そしてトラブルシューティングまでを詳しく解説してきました。クラウド上の共有環境である「Microsoft-hosted agent」は手軽で便利ですが、社内システムの厳しいセキュリティ要件や、特定のソフトウェア環境、独自のネットワーク閉域網（VNET）へのアクセスが必要な場面では、自分たちで管理する「セルフホスト型」が非常に強力な武器となります。

セルフホストエージェント運用の要点

導入のステップをおさらいすると、まずはAzure DevOps上でPAT（パーソナルアクセストークン）を発行し、エージェントプログラムをLinuxやWindowsなどの対象マシンにダウンロード、そして構成スクリプトを実行するという流れでした。特にLinux環境では、コマンドラインでの操作が中心となりますが、一度設定してしまえば「サービス」として登録することで、サーバーの再起動後も自動的にビルドを待機する状態を作ることができます。

また、運用面ではセキュリティの最小権限原則を意識することが重要です。エージェントを動かすユーザーアカウントに不必要な管理者権限を与えないことや、アウトバウンド（外部への通信）のみを許可するネットワーク構成にすることで、インバウンド（外部からの接続）を遮断したまま安全にクラウドと連携できるのがこの仕組みの大きなメリットです。

実践的なデータ管理と自動化

セルフホストエージェントを活用する現場では、ビルドのパフォーマンスやエラー発生率を独自に集計したいケースも多いでしょう。例えば、エージェントごとの稼働状況をデータベースで管理し、特定のビルド失敗傾向を分析することで、開発パイプラインのボトルネックを解消できます。

以下に、エージェントの負荷状況やエラーログを集計するためのデータベース構造の例と、特定の期間内に発生したエラーを抽出するSQLクエリを示します。

エージェント稼働ログのデータ構造例


id | agent_id | build_number | status  | error_code | execution_time_sec | created_at
---+----------+--------------+---------+------------+--------------------+--------------------
1  | 101      | 20260331-01  | Success | NULL       | 185                | 2026-03-31 10:00:00
2  | 101      | 20260331-02  | Failed  | E_AUTH_01  | 12                 | 2026-03-31 10:15:00
3  | 102      | 20260331-03  | Success | NULL       | 210                | 2026-03-31 11:00:00
4  | 101      | 20260331-04  | Success | NULL       | 190                | 2026-03-31 11:30:00
5  | 103      | 20260331-05  | Failed  | E_DISK_FULL| 5                  | 2026-03-31 12:00:00

特定のエージェントで発生した失敗ログを抽出するSQL


SELECT agent_id, build_number, error_code, execution_time_sec
FROM agent_logs
WHERE status = 'Failed'
AND created_at >= '2026-03-01'
ORDER BY created_at DESC;

このように、自分たちのサーバーで動かしているからこそ、詳細な実行ログを自由に扱い、改善に繋げることができます。最初は難しく感じるかもしれませんが、PATの発行とエージェントのインストールさえ完了すれば、あとはYAMLファイルでプール名を指定するだけです。ぜひ、独自のセキュアなビルド環境を手に入れて、効率的なDevOpsライフを送りましょう！

先生と生徒の振り返り会話

生徒

「先生、ありがとうございました！セルフホストエージェントの仕組みがよく分かりました。自分のサーバーがAzure DevOpsとつながって、自動でビルドが始まるのを見ると感動しますね。」

先生

「それは良かったです！特にLinux環境でのサービス登録は、実務でも非常によく使う手順ですよ。何か設定でつまずいたところはありましたか？」

生徒

「最初はPAT（パーソナルアクセストークン）の権限設定で少し迷いました。でも、『Agent Pools (Read & Manage)』を選べばいいと分かってからはスムーズにいきました。」

先生

「素晴らしいですね。PATの権限を絞ることはセキュリティの基本ですから、その感覚は大切にしてください。ちなみに、複数のエージェントを同時に動かすことも考えていますか？」

生徒

「はい！ビルド待ち時間を減らすために、古いPCや予備のサーバーもエージェントにして、エージェントプールに追加してみようと思います。SQLで集計して、どっちが速いか比べるのも面白そうですね。」

先生