インフラエンジニアの羅針盤

インフラエンジニア1〜3年目のための技術ガイド

AIエージェントエンジニアリング入門

公開更新

AIエージェントエンジニアリング入門

� この記事について

この記事は生成AI(Claude)を活用して執筆し、運営者が内容を確認・編集しています。

目次
  1. はじめに
  2. 前提条件
    1. 必要な環境
  3. AIエージェントとは何か ― LLM + ツール + ループ
    1. 従来のLLM利用とエージェントの違い
    2. エージェントの3つの構成要素
    3. ワークフローとエージェントの違い(Anthropic公式分類)
    4. 5つの構成パターン
    5. エージェントの分類
  4. Claude Codeの導入と基本操作
    1. Claude Codeとは
    2. インストール手順
    3. 基本操作
    4. Claude Codeが持つツール一覧
  5. CLAUDE.mdによるエージェントの制御
    1. CLAUDE.mdとは
    2. CLAUDE.mdの階層構造
    3. CLAUDE.mdの基本的な書き方
    4. 本ブログの実例 ― 多層CLAUDE.md構成
  6. 実践 ― インフラ業務でのエージェント活用
    1. 実践1: 5分ハンズオン ― サーバーログ分析(入門)
    2. 実践2: Before/After比較 ― プロンプト単体 vs エージェント(中級)
    3. 実践3: 構築手順の自動生成 + 実行検証エージェント(上級)
  7. エージェントが変えるインフラエンジニアの仕事
    1. 工程別エージェント活用の俯瞰
    2. Agent Team ― マルチエージェント構成の紹介
  8. まとめ
    1. 次にやること
    2. 前の記事・次の記事

はじめに

記事①では、プロンプト単体の設計技術を扱いました。6つの構成要素を使って指示を構造化し、Zero-shot / Few-shot / Chain-of-Thoughtを使い分けることで、AIの出力品質を高める方法を学びました。

しかし、1回のプロンプトでは完結しない業務も多くあります。たとえば、サーバーのログを確認し、異常があれば設定を修正し、反映結果を確認する。この一連のタスクをプロンプト単体で処理しようとすると、人間が「ログを見せて」「次はこのファイルを編集して」「構文チェックして」と1ステップずつ手動で指示を送る必要があります。

ここで登場するのがAIエージェントです。エージェントとは「LLM(大規模言語モデル)がツールを使いながら、ループでタスクを自律的に進める仕組み」です。人間が最初の指示を出すだけで、エージェントは自分で「次に何をすべきか」を判断し、ツールを実行し、結果を確認し、必要なら修正を繰り返します。

この記事では、以下の3つを扱います。

  1. AIエージェントの構成要素(LLM + ツール + ループ)とその分類
  2. Claude Codeのインストールと基本操作
  3. CLAUDE.mdによるエージェント制御の実践

プロンプト設計の基礎用語(6構成要素、Zero-shot / Few-shot / Chain-of-Thought等)は記事①で解説済みのため、この記事では再説明しません。未読の方は先に①を読むことを推奨します。


前提条件

この記事は、以下の前提知識を持つ方を対象としています。

  • コマンドライン操作(Linux / Windows)ができる
  • 記事①の内容(プロンプトの6構成要素、基本テクニック)を理解している

必要な環境

項目内容
ターミナル環境macOS / Linux / Windows のいずれか
AnthropicアカウントPro / Max / Teams / Enterprise プラン、またはConsole(API)アカウント
Windows環境の場合Git for Windows または WSL が必要

ポイント

記事①のプロンプト設計の基礎知識を前提とします。未読の方は先に①プロンプトエンジニアリングをお読みください。

注意

Claude Codeの利用にはAnthropicのサブスクリプションが必要です。料金・プラン詳細は公式ドキュメントを参照してください。ネイティブインストーラーを使用する場合、Node.jsは不要です(npm経由は非推奨)。また、APIキーを使用する場合は、キーの管理に注意してください。不要になったキーは無効化し、公開リポジトリにキーをコミットしないようにしてください。

� Maxプランについて

本記事の基本操作・単一エージェントの実践はProプランでも実行できます。ただし、後半で紹介するAgent Team(マルチエージェント構成)を実際に運用する場合は、複数のサブエージェントが同時にコンテキストウィンドウを消費するため、Claude Maxプランが事実上必要です。

AIエージェントとは何か ― LLM + ツール + ループ

従来のLLM利用とエージェントの違い

従来のLLM利用は、以下のような流れです。

  1. 人間がプロンプトを送信する
  2. LLMが回答を返す
  3. 人間が結果を判断し、次のアクションを決める
  4. 再び人間がプロンプトを送信する

これは「手動運転」に近い形です。LLMが優秀でも、各ステップで人間が介入し、次の指示を出す必要があります。

エージェントは、これを「自動運転」に変えます。

  1. 人間がタスクを依頼する
  2. LLMが「次に何をすべきか」を自ら判断する
  3. ツール(コマンド実行、ファイル操作等)を実行する
  4. 実行結果を確認する
  5. タスクが完了するまで、2〜4を自律的に繰り返す
  6. 完了したら、結果を人間に返す

人間が介入するのは最初の依頼と最後の結果確認だけです。途中の判断・実行・検証はエージェントが自律的に行います。

エージェントの3つの構成要素

Anthropicは2024年12月公開のブログ記事「Building effective agents」において、エージェントを以下のように定義しています。

エージェント = LLMがツールを自律的にループで使用するシステム
(”LLMs autonomously using tools in a loop”)

この定義をもとに、本記事ではエージェントの構成要素を以下の3つに整理します(Anthropic公式の分類とは異なる、本記事独自の整理です)。

構成要素役割具体例
LLM(頭脳)タスクの理解・判断・次のアクションの決定Claude Sonnet / Opus
ツール(手足)ファイル操作、コマンド実行、Web検索などの実行手段Bash、Read、Write、Grep等
ループ(行動サイクル)「判断→実行→結果確認→次の判断」の繰り返しタスク完了まで自律的に継続

ツールを持たないLLMはただのチャットボットです。ループしないLLMはただの1回限りのAPI呼び出しです。3要素すべてが揃って初めてエージェントとして機能します。

エージェントのループ構造

  1. 人間がタスクを依頼する
  2. LLM(頭脳)が判断する ― 次に何をすべきかを決定
  3. ツール(手足)を実行する ― Bash / Read / Write / Grep 等
  4. 結果を確認する ― 期待通りか検証
  5. タスク完了?
    • No → 手順2に戻り、次の判断を行う
    • Yes → 人間に結果を返す
構成要素役割上記フローでの該当箇所
LLM(頭脳)タスクの理解・判断・次のアクションの決定手順2「LLMが判断する」
ツール(手足)ファイル操作、コマンド実行、Web検索などの実行手段手順3「ツールを実行する」
ループ(行動サイクル)「判断→実行→結果確認→次の判断」の繰り返し手順2〜5の繰り返し

ワークフローとエージェントの違い(Anthropic公式分類)

Anthropicはエージェントシステムを、以下の2つに分類しています。

分類定義特徴
ワークフロー(Workflows)LLMとツールが事前定義されたコードパスで制御されるシステム処理の流れが固定されている
エージェント(Agents)LLMが自らの処理とツール使用を動的に指揮するシステムタスクの達成方法を自律的に決定する

ワークフローは「手順書通りに実行するスクリプト」、エージェントは「状況に応じて判断する担当者」と考えると分かりやすいです。

5つの構成パターン

Anthropicは、ワークフローの構成パターンとして以下の5つを提示しています。エージェントはこれらとは別に、LLMが処理を動的に制御する独立した概念として定義されています。

パターン説明インフラ業務での例
プロンプトチェイニング各LLM呼び出しが前の出力を処理する逐次実行手順書の逐次実行(ステップ1の結果を受けてステップ2を実行)
ルーティング入力を分類し、専門的な処理に振り分けるアラート分類(CPU高負荷→リソース調査、ディスク逼迫→容量確認)
並列化独立したタスクを同時に実行し、結果を集約する複数サーバーの状態を同時取得して一覧化
オーケストレーター・ワーカー中央のLLMがタスクを動的に分解し、ワーカーに委任マルチサーバー構成の一括構築(各サーバーの設定をワーカーが並行処理)
評価者・最適化一方が生成し、他方が評価するループ設定ファイル生成→構文チェック→修正→再チェックの繰り返し

出典: Building Effective AI Agents – Anthropic

エージェントの分類

エージェントは規模に応じて、以下の2つに分類できます。

  • 単一エージェント: 1つのLLMが1つのループでタスクを処理する。本記事の実践例はこの形式
  • マルチエージェント(Agent Team): 複数のエージェントが役割分担して協調動作する。本ブログの執筆フローが実例(後述)

この記事では単一エージェントの基礎を学びます。マルチエージェントの概念は後半で紹介しますが、詳細な設計手法は記事③で扱います。


Claude Codeの導入と基本操作

Claude Codeとは

Claude Codeは、Anthropicが提供するCLI(コマンドラインインタフェース)型のAIエージェントです。ターミナル上で動作し、ファイル操作・コマンド実行・コード編集・Web検索などのツールを組み込みで備えています。

つまり、前章で説明した「LLM + ツール + ループ」がすでに統合されたエージェント環境です。インストールした時点で、エージェントとして動作する準備が整います。

VS Code拡張としても利用可能ですが、本記事ではCLI版を使用します。

インストール手順

推奨はネイティブインストーラーです。依存関係が不要で、自動更新にも対応しています。

macOS / Linux:

curl -fsSL https://claude.ai/install.sh | bash

Windows(PowerShell):

irm https://claude.ai/install.ps1 | iex

注意

npm経由のインストール(npm install -g @anthropic-ai/claude-code)は非推奨です。Node.js 18以上が必要になるほか、今後ネイティブインストーラーに一本化される方針のため、新規インストールではネイティブインストーラーを使用してください。

インストール後の確認:

claude doctor    # インストールの検証(環境チェック)
claude --version # バージョン確認

� バージョンについて

Claude Codeは頻繁に更新されます。バージョン番号は claude --version で確認してください。ネイティブインストーラー使用時はバックグラウンドで自動更新されます。

初回起動と認証:

claude

初回実行時にAnthropicアカウントでの認証が求められます。ブラウザが開き、認証が完了するとターミナルに戻ります。

出典: Set up Claude Code – Anthropic

基本操作

Claude Codeには3つの実行モードがあります。

コマンドモード用途
claude対話モードターミナル上で対話形式で作業する
claude "質問内容"ワンショットモード1つの質問に回答して終了する
claude -p "質問内容"パイプモードスクリプトから呼び出す(標準入出力を使用)

対話モード中は、スラッシュコマンドで各種操作が可能です。

コマンド説明
/helpヘルプ表示
/model使用モデルの切り替え
/compactコンテキストの圧縮(会話が長くなった場合に使用)
/clear会話のリセット
/cost現在のセッションの使用コスト確認

パーミッションモデル(承認フロー):

Claude Codeはファイル操作やコマンド実行の前に、ユーザーの承認を求めます。たとえば、rm コマンドを実行しようとすると「このコマンドを実行しますか?」と確認が表示されます。安全性を確保しつつ、許可リストに登録したツールは自動で承認することも可能です。

Claude Codeが持つツール一覧

Claude Codeには以下のツールが組み込まれています。

ツール名機能インフラ業務での用途
Bashシェルコマンドの実行ログ確認、サービス操作、構文チェック
Readファイルの読み取り設定ファイルの確認、ログの読み込み
Writeファイルの新規作成・上書き設定ファイルの生成、レポート出力
Edit既存ファイルの差分編集設定ファイルの一部変更
Grepファイル内容のパターン検索(ripgrep(高速検索ツール)ベース)エラーパターンの検索
Globファイル名パターン検索設定ファイルの一覧取得
Agentサブエージェントへのタスク委任大きなタスクの分割実行
WebFetchURL先のコンテンツ取得公式ドキュメントの参照
WebSearchWeb検索エラーメッセージの調査
NotebookEditJupyterノートブックの編集データ分析作業

これらのツールが揃っているため、Claude Codeはインストール直後からエージェントとして機能します。人間が「ログを分析して」と指示を出すだけで、Claude Codeは自律的にRead(ログ読み取り)→ Grep(パターン検索)→ Bash(追加調査)→ Write(レポート出力)とツールを組み合わせて作業を進めます。


CLAUDE.mdによるエージェントの制御

CLAUDE.mdとは

CLAUDE.mdは、Claude Codeの動作を制御するMarkdown形式の設定ファイルです。プロジェクトのディレクトリに配置すると、Claude Codeが会話開始時に自動で読み込みます。

記事①で学んだプロンプト設計を思い出してください。「役割」「制約」「出力形式」などを毎回プロンプトに書いていたのは手間でした。CLAUDE.mdは、こうした指示をファイルとして永続化・体系化したものです。毎回プロンプトに書かなくても、CLAUDE.mdに記載しておけば自動で適用されます。

CLAUDE.mdの階層構造

CLAUDE.mdは4つのレベルで設定を管理できます。

レベル配置場所用途
ユーザー設定~/.claude/CLAUDE.md全プロジェクト共通の個人設定
プロジェクト設定プロジェクトルート/CLAUDE.md特定プロジェクトに適用(チーム共有可)
サブディレクトリ設定サブディレクトリ/CLAUDE.md特定ディレクトリに適用
マネージドポリシー管理者が設定組織全体のポリシー(除外不可)

優先順位は「マネージド > サブディレクトリ > プロジェクト > ユーザー」です。下位の設定が上位の設定を上書きし、マネージドポリシーは常に最優先で適用されます。

優先度レベル配置場所用途
最高マネージドポリシー管理者が設定組織全体のポリシー(除外不可)
プロジェクト設定./CLAUDE.md特定プロジェクトに適用(チーム共有可)
サブディレクトリ設定サブディレクトリ/CLAUDE.md特定ディレクトリに適用
ユーザー設定~/.claude/CLAUDE.md全プロジェクト共通の個人設定

� 優先順位

上位レベルの設定が下位レベルの設定を上書きします。マネージドポリシーはすべてのレベルに優先し、除外できません。

この階層構造は、インフラエンジニアに馴染みのある設定管理の考え方と共通しています。たとえばAnsibleのvariable precedence(変数の優先順位)や、nginxの設定ファイルの継承構造と似た概念です。グローバルなデフォルト値を定義しつつ、個別のプロジェクトやディレクトリで上書きできる仕組みです。

また、CLAUDE.mdに加えて.claude/rules/ディレクトリにルールファイルを分割配置することも可能です。

� Auto Memoryについて

CLAUDE.md(手動メモリ)のほかに、Claude Codeが作業中に自動保存するAuto Memory(自動メモリ)もあります。ビルドコマンドやデバッグの知見などが ~/.claude/projects/<project>/memory/ に保存され、次回の会話開始時に自動で読み込まれます。

CLAUDE.mdの基本的な書き方

インフラ業務向けのシンプルなCLAUDE.mdの例を示します。

# CLAUDE.md

## プロジェクト情報
- サーバーOS: AlmaLinux 10
- 管理対象: nginx 1.26 / PHP-FPM 8.3 / MariaDB 10.11

## 基本ルール
- コマンドは必ずsudo付きで出力する
- 設定変更前にバックアップコマンドを含める
- SELinuxが有効であることを前提とする

## 出力形式
- シェルスクリプト形式で出力する
- 各コマンドにコメントを付記する

このCLAUDE.mdがあるディレクトリでClaude Codeを起動すると、上記ルールが自動で適用されます。たとえば「nginxの設定を変更して」と指示すると、sudoコマンド付きで、バックアップ処理を含めた手順が出力されます。CLAUDE.mdがなければ、これらの条件を毎回プロンプトに書く必要があります。

本ブログの実例 ― 多層CLAUDE.md構成

本ブログ(インフラエンジニアの羅針盤)では、実際にCLAUDE.mdの階層構造を活用して記事を執筆しています。

本ブログの実例

C:\ClaudeWorkspaces\
├── CLAUDE.md                  ← プロジェクト設定(言語・文体・チーム定義)
└── series\generative-ai\
    └── CLAUDE.md              ← サブディレクトリ設定(記事構成・キーワード)
グローバルCLAUDE.mdで文体ルール・品質基準を一元管理し、シリーズCLAUDE.mdで記事固有の設定を追加しています。

グローバルCLAUDE.md(上位)に定義している内容:

  • 言語設定(日本語で出力)
  • 文体ルール(です・ます調、禁止表現の一覧)
  • Agent Team構成(6つのInstanceの役割定義)
  • HTML納品ルール(WordPress / PersonalNote向け)

シリーズCLAUDE.md(下位)に定義している内容:

  • 記事ごとの詳細設定(カバーする内容、含めないもの)
  • キーワード戦略(メインキーワード、サブキーワード)
  • 各Instanceへの追加指示(シリーズ固有の注意事項)

この構成のメリットは、グローバルなルール(文体・品質基準)を1箇所で管理しつつ、シリーズ固有の設定を分離できる点です。グローバルCLAUDE.mdを変更すれば、全シリーズに反映されます。

ポイント

CLAUDE.mdは記事③で扱うコンテキストエンジニアリングの実践例でもあります。「エージェントに何を伝えるか」の設計手法は③で体系的に扱います。

実践 ― インフラ業務でのエージェント活用

ここからは、Claude Codeを使って実際にエージェントを動かします。3つの実践例を難易度順に配置しています。

実践タスクエージェントの動作難易度
実践1サーバーログ分析Read → Grep → LLM分析 → 結果出力入門
実践2nginx設定の生成と検証Write → Bash(nginx -t)→ 修正ループ中級
実践3構築手順の自動生成 + 実行検証draft生成 → Bash実行 → エラー修正 → 再実行上級

実践1: 5分ハンズオン ― サーバーログ分析(入門)

最初の実践は、コピー&ペーストで即再現できる最小構成です。エージェントの動作を最短で体験します。

ステップ1: CLAUDE.mdを作成する

作業ディレクトリに以下の内容でCLAUDE.mdを作成します。

# CLAUDE.md
- 対象OS: AlmaLinux 10
- ログ分析時は ERROR / CRITICAL / OOM を重点的に確認する
- 分析結果は「検出項目・重要度・推奨対応」の表形式で出力する

ステップ2: Claude Codeで1行の指示を実行する

claude "直近の /var/log/messages を分析して異常がないか確認してください"

ステップ3: エージェントの動作を観察する

Claude Codeは以下のようにツールを組み合わせて自律的に作業を進めます。

  1. Read でログファイルを読み取る
  2. Grep でERROR / CRITICAL / OOMパターンを検索する
  3. LLMが検出結果を分析し、重要度を判定する
  4. CLAUDE.mdで指定した表形式で結果を出力する

たった1行の指示で、Claude Codeは「どのツールを使うか」「どの順番で処理するか」を自分で判断し、ループで作業を進めます。これがエージェントの基本動作です。

� 動作のポイント

Claude Codeはタスクの完了条件を自分で判断し、必要なツールを自動選択します。CLAUDE.mdで指定した出力形式(表形式)も自動で反映されます。

実践2: Before/After比較 ― プロンプト単体 vs エージェント(中級)

記事①で扱ったnginx設定生成のタスクを題材に、「プロンプト単体」と「エージェント」の違いを具体的に比較します。

Before: プロンプト単体のアプローチ(記事①の方法)

Before: プロンプト単体

記事①で紹介した6構成要素のプロンプトを使い、nginxのリバースプロキシ設定を生成します。

実行結果:

  • 設定ファイルのテキストが出力される
  • 構文が正しいかは人間が手動で nginx -t を実行して確認する必要がある
  • エラーがあれば、人間がプロンプトを修正して再度生成を依頼する

つまり、「生成して終わり」です。検証と修正は人間の仕事になります。

After: エージェントのアプローチ(この記事の方法)

After: エージェント

CLAUDE.mdに環境情報を記載した上で、Claude Codeに以下の指示を出します。
app.example.com のリバースプロキシ設定を作成して、構文チェックまで実行してください。
バックエンドは localhost:8080 です。HTTPS必須で、HTTP/2を有効にしてください。

Claude Codeの動作:

  1. Write で設定ファイルを /etc/nginx/conf.d/app.example.com.conf に出力する
  2. Bashnginx -t を実行する
  3. 構文エラーがあれば、Edit で設定ファイルを修正する
  4. 再び Bashnginx -t を実行する
  5. syntax is ok が返るまでループを繰り返す
  6. 検証済みの設定ファイルと実行結果を報告する

「生成→検証→修正」をループで自律的に回します。

プロンプト単体では「生成」で止まります。エージェントは「生成→検証→修正」のループを回します。この差がエージェントを使う利点です。

注意

検証環境での実行を推奨します。本番サーバーでClaude Codeに直接操作させることは推奨しません。Claude Codeのパーミッションモデルで承認は求められますが、本番環境への影響を考慮し、検証環境で動作を確認してから本番に適用する運用を取ってください。

実践3: 構築手順の自動生成 + 実行検証エージェント(上級)

エージェントのループが最も効果を発揮するのは、「生成→実行→検証→修正」のフルサイクルです。

タスク: AlmaLinux 10にnginx + PHP-FPM環境を構築する手順書を生成し、各コマンドの実行可否を検証する。

ステップ1: CLAUDE.mdに環境と出力形式を定義する

# CLAUDE.md

## 環境
- OS: AlmaLinux 10 minimal
- SELinux: 有効

## 手順書フォーマット
各ステップは以下の3点を必ず含めること:
1. 実行コマンド(sudo付き・コピー&ペースト可能)
2. 期待結果(コマンド実行後に確認すべき出力)
3. 補足(注意点や背景情報)

ステップ2: Claude Codeに手順書の生成と検証を指示する

claude "nginx + PHP-FPM環境の構築手順書を作成してください。各コマンドは実際に実行して動作確認し、エラーがあれば手順を修正してください。"

ステップ3: Claude Codeのフルサイクル動作

Claude Codeは以下のサイクルを自律的に実行します。

  1. Write で手順書のドラフトを作成する
  2. Bash で手順書内の各コマンドを実行する
  3. エラーが発生した場合、Edit で手順書を修正する
  4. 修正したコマンドを再び Bash で実行する
  5. 全コマンドが正常に通るまでループを繰り返す
  6. 検証済みの手順書を出力する

記事①の「ドキュメント作成」プロンプト例では、手順書を「生成」するだけでした。エージェントを使うと、生成した手順を実際に実行し、動かない箇所を自動で修正します。手順書の品質がループのたびに上がっていく点が、エージェントの強みです。


エージェントが変えるインフラエンジニアの仕事

工程別エージェント活用の俯瞰

インフラエンジニアの担当工程ごとに、エージェント活用で「何が変わるか」を整理します。

工程エージェントにできること人間が担う役割
要件定義ヒアリングメモから要件項目の洗い出し・抜け漏れチェック・定義書ドラフト生成ステークホルダーとの合意、最終判断
基本設計要件定義書を入力 → サーバー構成案・NW構成案を複数パターン生成 → 比較表作成アーキテクチャの意思決定
詳細設計基本設計書を入力 → パラメータシート・IP設計表・FW設定一覧・設定ファイル雛形を一括生成既存環境との整合性確認
構築詳細設計書を入力 → 構築スクリプト生成 → 検証環境で実行 → エラー修正ループ本番適用の判断・承認
単体テスト詳細設計書を入力 → テスト項目自動生成 → テストスクリプト生成・実行 → エビデンス整形結果の妥当性確認
結合テスト基本設計書を入力 → E2Eシナリオ生成 → 実行可能な範囲は自動実行 → 結果レポート実行判断、障害時の切り分け
運用設計システム構成を入力 → 監視項目一覧・閾値案・障害対応フロー・エスカレーション基準を生成SLA合意、運用体制の決定
運用・保守アラート受信 → ログ分析 → 原因候補と対処案を提示 → 定期レポート生成対処の実行判断、根本対策の立案

この表で重要なのは、すべての工程で「人間が担う役割」が残っている点です。エージェント導入後も、判断・承認・意思決定は人間の仕事です。エージェントが担うのは「ドラフト生成・検証・定型作業の自動化」の部分であり、人間の役割は「作業者」から「判断者・レビュアー」に変わります。

ポイント

エージェントは人間の作業を代替するのではなく、人間が判断に集中できる環境を作ります。各工程の具体的な活用方法は、今後の記事で扱う予定です。

Agent Team ― マルチエージェント構成の紹介

単一エージェントにすべてを任せると、タスクが複雑になるほど品質が下がります。調査・執筆・検証・レビューを1つのエージェントに同時にやらせると、各作業の専門性が薄れるためです。

この問題を解決するのが、マルチエージェント(Agent Team)です。複数の専門エージェントが役割を分担し、協調動作する構成です。

本ブログの執筆フローを実例として紹介します。

Lead(指揮官)← 全体の進行管理・最終統合
├── Researcher(技術調査)← 公式ドキュメント・最新情報の収集
├── Writer(記事執筆)← draft.md / final.html の執筆
├── Verifier(コード検証)← コマンド・手順の動作検証
├── Reviewer(品質監査)← 文体・AdSense・E-E-A-Tチェック
└── Designer(ビジュアル設計)← アイキャッチ仕様・図解・レイアウト

Agent Team 実行フロー

  1. Lead(指揮官) ― 全体の進行管理を開始
  2. Researcher(技術調査) ― 公式ドキュメント・最新情報を収集
  3. Writer(記事執筆) ― outline.md → draft.md を執筆
  4. 並列実行フェーズ(以下3つが同時に作業)
    • Verifier(コード検証) ― コマンド・手順の動作検証
    • Designer(ビジュアル設計) ― アイキャッチ仕様・図解作成
    • Reviewer(品質監査) ― 文体・品質・AdSenseチェック
  5. Writer(記事執筆) ― 各Instanceの指摘を反映し final.html を出力
  6. Lead(指揮官) ― final.html を運営者に提示

Agent Teamの利点:

  • 専門性の分離: 各エージェントが1つの役割に集中するため、出力品質が高い
  • 並列実行による効率化: Verifier・Designer・Reviewerが同時に作業できる
  • 品質の多角的チェック: 技術検証・文体チェック・ビジュアル確認を別々のエージェントが担当する

Claude CodeのAgentツールを使うと、メインのエージェント(Lead)からサブエージェントを起動できます。サブエージェントは独立したコンテキストウィンドウで動作し、完了後に結果だけをメインに返します。

注意

Agent Teamのようなマルチエージェント構成では、複数のサブエージェントが同時にコンテキストウィンドウを消費するため、Claude Maxプランが事実上必要です。Proプランではレート制限に到達しやすく、実用的な運用は困難です。

� メモ

このAgent Team構成はCLAUDE.mdで定義しています。各エージェントの役割・指示・実行フローをすべてCLAUDE.mdに記載し、Claude Codeが読み込んで実行します。定義方法の詳細は記事③で扱います。

まとめ

この記事で扱った内容を整理します。

記事②のポイント:

エージェント = LLM + ツール + ループ。プロンプト単体では「生成」で止まるが、エージェントは「生成→検証→修正」を自律的にループする。
  • AIエージェントの3要素: LLM(頭脳)+ ツール(手足)+ ループ(行動サイクル)。3要素すべてが揃って初めてエージェントとして機能する
  • ワークフローとエージェントの違い: ワークフローは処理の流れが固定。エージェントはタスクの達成方法を自律的に決定する
  • Claude Codeの導入: ネイティブインストーラーでインストールし、CLAUDE.mdで動作を制御する
  • 実践例: ログ分析(入門)、nginx設定のBefore/After比較(中級)、構築手順の生成+検証(上級)の3つを通じて、エージェントの「生成→検証→修正」ループを体験した
  • 工程別俯瞰: インフラエンジニアの全工程でエージェントは「ドラフト生成・検証・定型作業」を担い、人間は「判断・承認・意思決定」に集中する

次にやること

  1. Claude Codeをインストールし、実践1(5分ハンズオン)を自分の環境で実行する
  2. 自分の作業ディレクトリにCLAUDE.mdを1つ作成し、普段の業務タスクをエージェントに任せてみる
  3. 工程別俯瞰表を見て、自分の担当工程で最もエージェント化の効果が高そうな作業を1つ選ぶ

前の記事・次の記事

前の記事 → ①プロンプトエンジニアリング

次の記事では、エージェントの品質を決める「コンテキスト(情報設計)」の技術を扱います。エージェントの出力品質は、与えるコンテキスト ― CLAUDE.md・ドキュメント・ツール定義 ― の設計で決まります。この「情報設計」を体系的に学ぶのが記事③(コンテキストエンジニアリング)です。

次の記事 → ③コンテキストエンジニアリング

前の記事
次の記事