「AIエージェントのハーネスを自作する」というテーマの有料教材を見かけました。価格は14,800円〜19,800円。無料部分を読んだ限り、エージェントコアの設計パターンやコンテキストエンジニアリングの基礎について触れている内容のようでした。
正直なところ、この価格に見合う情報密度かと聞かれると微妙だと感じたんですよね。Anthropicが公式に公開しているドキュメントや、オープンソースプロジェクトのソースコードを読めば、同等以上の知識が無料で手に入ります。そこで、自分で徹底的に調べて記事にまとめてみました。
そもそも「エージェントハーネス」とは何か
AIエージェントの世界で「ハーネス」という言葉を聞くと、少し身構えてしまうかもしれません。でも概念自体はシンプルで、LLMを中心に据えて、ツール・メモリ・ワークフローを統合的に管理する仕組みのことを指しています。
馬具のハーネスが馬の力を制御して方向づけるように、エージェントハーネスはLLMの能力を制御し、適切なタスクに向けて力を発揮させる役割を担っているわけですね。
具体的には、以下の要素で構成されるのが一般的です。
- エージェントコア：LLMとの対話を管理するメインループ
- ツール管理：外部APIやファイル操作などの機能を提供・制御する仕組み
- メモリ管理：短期記憶（コンテキスト）と長期記憶（永続化データ）の管理
- コンテキストエンジニアリング：LLMに渡す情報を最適化する技術
- スキル・サブエージェント：特定のタスクに特化した処理モジュール
有料教材ではこれらを「独自のフレームワーク」として紹介していることが多いのですが、実態としてはAnthropicやOpenAIが公開しているベストプラクティスに沿ったものがほとんどだと感じました。
有料フレームワークvs自作vsOSS｜どれを選ぶべきか
エージェントハーネスを手に入れる方法は大きく3つあります。それぞれのメリット・デメリットを整理してみましょう。
| 方法 | コスト | カスタマイズ性 | 学習コスト | メンテナンス | おすすめ度 |
|---|---|---|---|---|---|
| 既存フレームワーク（LangChain等） | 無料 | 中 | 中 | 低（コミュニティ依存） | ★★★★☆ |
| 自作ハーネス | 無料（開発時間） | 最高 | 高 | 高（自己責任） | ★★★☆☆ |
| SaaS型（OpenClaw, Dify等） | 無料〜有料 | 低〜中 | 低 | 最低 | ★★★★★ |
| 有料教材のハーネス | 1〜2万円 | 中 | 中 | 自己責任 | ★★☆☆☆ |
Anthropicの公式ブログでも「最もシンプルな解決策から始めて、必要に応じて複雑さを追加する」ことが推奨されています。フレームワークを使う場合でも、内部で何が起きているかを理解しておくことが重要だと強調されていますね。
個人的には、まずSaaS型で動くものを触ってみて、物足りなくなったら自作に挑戦するのが最も効率的なルートだと感じました。いきなり自作から入ると、車輪の再発明に時間を取られて本来やりたいことに辿り着けないケースが多いようです。
Anthropic公式が教える5つのエージェント設計パターン
有料教材の核心部分とされる「エージェントコアの設計パターン」ですが、実はAnthropicが2024年12月に公開した「Building Effective Agents」という記事で、ほぼ全てが無料で解説されています。ここではその5パターンを日本語で噛み砕いて解説しますね。
パターン1：プロンプトチェーン（直列処理）
タスクを複数のステップに分解して、各ステップの出力を次のステップの入力にする方法です。たとえば「記事の構成案を作る → 構成が基準を満たすかチェック → 本文を書く」という流れ。シンプルだけど、各ステップのLLM呼び出しが簡単なタスクになるため精度が上がるのがポイント。
パターン2：ルーティング（分岐処理）
入力を分類して、適切な専門処理に振り分けるパターンですね。カスタマーサポートで「一般的な質問」「返金リクエスト」「技術サポート」を別々のフローに流すイメージ。簡単な質問は軽量モデル（Claude Haiku等）に、難しい質問は高性能モデル（Claude Sonnet等）に振り分けるコスト最適化もこのパターンの応用になります。
パターン3：並列化（パラレル処理）
複数のLLM呼び出しを同時に実行して結果を統合する方法。2つのバリエーションがあって、タスクを独立した部分に分けて並行実行する「セクショニング」と、同じタスクを複数回実行して多様な出力を得る「ボーティング」に分かれます。コードのセキュリティレビューで複数のプロンプトから脆弱性を検出する、といった使い方が効果的だそうです。
パターン4：オーケストレーター・ワーカー
中央のLLM（オーケストレーター）がタスクを動的に分解して、ワーカーLLMに委任し、結果を統合するパターン。コーディングエージェントが典型例で、「どのファイルを変更すべきか」をオーケストレーターが判断して、各ファイルの変更をワーカーに任せる形ですね。並列化との違いは、サブタスクが事前に定義されるのではなく動的に決まる点にあります。
パターン5：評価者・最適化（ループ処理）
一方のLLMがレスポンスを生成し、もう一方が評価・フィードバックを返すループ。人間のライターが推敲を重ねるプロセスに似ていますね。翻訳のニュアンス調整や、複数回の検索・分析が必要な調査タスクで威力を発揮するパターンです。
コンテキストエンジニアリング｜プロンプトエンジニアリングの次
有料教材でも触れられている「コンテキストエンジニアリング」は、2025年後半から急速に注目を集めている概念ですね。プロンプトエンジニアリングが「何を聞くか」に焦点を当てるのに対して、コンテキストエンジニアリングは「LLMにどんな情報を、どのタイミングで、どれだけ渡すか」を設計する技術になります。
エージェントが複雑なタスクをこなす際、コンテキストウィンドウ（LLMが一度に処理できる情報量）の管理が成否を分けるんですよね。具体的には以下の要素を最適化していきます。
システムプロンプトの設計
エージェントの「性格」「能力」「制約」を定義する部分。ここが曖昧だとエージェントの挙動がブレます。実践的なコツとしては、役割を明確に定義すること、利用可能なツールの説明を構造化して記述すること、出力フォーマットを具体的に指定することが挙げられますね。
動的コンテキストの注入
タスクの進行に応じて、必要な情報だけをコンテキストに追加する仕組み。全ての情報を常に渡すのではなく、RAG（検索拡張生成）やメモリシステムを使って「今必要な情報」を選択的に注入するのがポイントになります。
コンテキストの圧縮と要約
長時間稼働するエージェントでは、会話履歴がコンテキストウィンドウを圧迫する問題も出てきますね。定期的に過去の会話を要約してトークンを節約する「コンパクション」という手法が一般的に使われていますね。
| 手法 | 説明 | トークン節約率 | 情報損失 |
|---|---|---|---|
| 全履歴保持 | 会話をそのまま保持 | 0% | なし |
| スライディングウィンドウ | 直近N件のみ保持 | 50〜80% | 中 |
| 要約コンパクション | LLMが過去を要約 | 60〜90% | 低〜中 |
| セマンティック検索 | 関連する履歴のみ取得 | 70〜95% | 低 |
スキルとサブエージェント｜モジュール化の実践
エージェントを実用的に運用するには、機能をモジュール化する必要があります。有料教材では「スキル」と「サブエージェント」という概念が紹介されていますが、これもオープンな情報から学べる内容ですね。
スキル（Tool/Function）
特定の機能を関数として切り出したもの。ファイル操作、Web検索、API呼び出しなど。重要なのはツールの説明文を丁寧に書くこと。Anthropicも「エージェントの性能はツールの説明文の品質に大きく左右される」と明言していて、ツール名、パラメータの説明、使用例、エッジケースの処理方法を明確に記述することが推奨されています。
サブエージェント
メインのエージェントから独立したコンテキストで動く子プロセスのようなもの。メインエージェントのコンテキストを汚さずに、重い処理を別セッションで実行できるメリットがあります。ただし、サブエージェントの品質管理は難しいところがあって、結果を必ず検証する仕組みを組み込んでおく必要がありますね。
ナレッジ管理｜エージェントの「記憶」をどう設計するか
長期間運用するエージェントにとって、記憶の管理は避けて通れないテーマです。人間が日記をつけるように、エージェントも「何を覚えておくべきか」を設計する必要があります。
短期記憶（コンテキスト内）
現在のセッション中の会話履歴やツールの実行結果。コンテキストウィンドウのサイズに制約されるため、前述のコンパクション技術が重要になってきます。
長期記憶（永続化）
セッションをまたいで保持すべき情報。ユーザーの好み、過去の決定事項、学習した教訓など。ファイルベース（Markdownファイル）、データベース（SQLite、PostgreSQL）、ベクトルストア（Pinecone、Chroma）など、用途に応じた保存方法を選択していくのが一般的ですね。
| 記憶の種類 | 保存場所 | 用途 | 検索方法 |
|---|---|---|---|
| 会話履歴 | セッション内 | 直近の文脈維持 | 直接参照 |
| ユーザー設定 | 設定ファイル | 好み・制約の記憶 | キー指定 |
| 作業ログ | 日次ファイル | 何をしたかの記録 | 日付指定 |
| 学習済み知識 | ベクトルDB | 過去の知見の再利用 | セマンティック検索 |
| 長期記憶 | 構造化ファイル | 重要な判断・教訓 | キーワード検索 |
自律型エージェントの設計思想｜「いつ人間に聞くか」
完全に自律的なエージェントは理想的に聞こえますが、実運用では「いつ自律的に動き、いつ人間に確認するか」のバランス設計が最も難しいポイントだと感じています。
Anthropicの推奨する原則は3つです。
- シンプルさを維持する：エージェントの設計は可能な限りシンプルにする
- 透明性を優先する：エージェントの計画ステップを明示的に表示する
- ツールインターフェースを丁寧に作る：ツールのドキュメントとテストを徹底する
自律性のレベルを段階的に設計するのが実践的なアプローチですね。
| レベル | 自律度 | 人間の関与 | 適用場面 |
|---|---|---|---|
| L1: 承認必須 | 低 | 全アクションに承認 | 外部送信、課金操作 |
| L2: 通知付き | 中 | 実行後に報告 | ファイル編集、設定変更 |
| L3: 自律実行 | 高 | 定期レポートのみ | 情報収集、分析 |
| L4: 完全自律 | 最高 | 異常時のみ通知 | モニタリング、定型処理 |
実装例｜最小構成のエージェントハーネスを作る
ここからは具体的なコードで、最小構成のエージェントハーネスがどういうものかを示していきます。Pythonで数十行で書けるレベルです。
基本構造は「ループの中でLLMを呼び出し、ツール呼び出しがあれば実行し、結果を返す」というシンプルなもの。
import anthropic
client = anthropic.Anthropic()
def run_agent(system_prompt, tools, user_message, max_turns=10):
messages = [{"role": "user", "content": user_message}]
for turn in range(max_turns):
response = client.messages.create(
model="claude-sonnet-4-5-20250514",
max_tokens=4096,
system=system_prompt,
tools=tools,
messages=messages
)
# レスポンスをメッセージ履歴に追加
messages.append({"role": "assistant", "content": response.content})
# ツール呼び出しがなければ完了
tool_calls = [b for b in response.content if b.type == "tool_use"]
if not tool_calls:
break
# ツールを実行して結果を返す
tool_results = []
for tc in tool_calls:
result = execute_tool(tc.name, tc.input)
tool_results.append({
"type": "tool_result",
"tool_use_id": tc.id,
"content": str(result)
})
messages.append({"role": "user", "content": tool_results})
return messagesこのコアループに、メモリ管理やエラーハンドリング、ログ記録を追加していくことで、実用的なエージェントハーネスに成長させることができます。フレームワークを使わなくても、この程度のコードで基本的なエージェントは動くんですよね。
主要フレームワーク比較｜自作の前に知っておくべき選択肢
| フレームワーク | 提供元 | 特徴 | 学習コスト | おすすめ用途 |
|---|---|---|---|---|
| Claude Agent SDK | Anthropic | 公式SDK、シンプル設計 | 低 | Claude特化の開発 |
| LangChain / LangGraph | LangChain Inc. | 豊富なインテグレーション | 中〜高 | 複雑なワークフロー |
| Strands Agents SDK | AWS | AWS連携が強い | 中 | AWS環境での開発 |
| CrewAI | OSS | マルチエージェント特化 | 中 | チーム型エージェント |
| OpenClaw | OSS | 個人向け自律エージェント | 低 | パーソナルAIアシスタント |
Anthropicは「フレームワークは手早く始めるのに役立つが、本番環境に移行する際には抽象化レイヤーを減らし、基本的なコンポーネントで構築することを躊躇しないでほしい」と述べています。フレームワークの便利さに依存しすぎると、デバッグが困難になるリスクがあるわけですね。
失敗パターン5選と回避策
失敗1：最初から複雑なアーキテクチャを組む
マルチエージェント、RAG、ベクトルDB、MCPサーバー…と全部盛りにした結果、デバッグ不能になるパターン。まずはシンプルなプロンプトチェーンから始めて、実際にボトルネックになっている部分だけを改善していくのが正解でしょう。
失敗2：ツールの説明文が雑
「ファイルを読む関数」程度の説明しか書かずに、エージェントが正しくツールを選択できないパターン。ツール名、引数の意味、戻り値の形式、使用すべき場面と使用すべきでない場面まで書くのがベストプラクティスになります。
失敗3：コンテキストウィンドウの管理を怠る
長時間の会話でコンテキストが溢れて、エージェントの性能が劇的に低下するパターン。コンパクションの仕組みを最初から設計に組み込んでおくことが重要ですね。
失敗4：エラーハンドリングがない
API呼び出しの失敗、ツールのタイムアウト、予期しないレスポンス形式に対処できず、エージェントが停止するパターン。リトライ機構と、失敗時のフォールバック処理を必ず実装しておきましょう。
失敗5：人間のフィードバックループがない
エージェントが間違った方向に進んでいても気づけない設計。チェックポイントを設けて人間が介入できるタイミングを作ること、そしてエージェントの行動ログを人間が読める形式で残すことが重要だと感じました。
よくある質問（FAQ）
Q: プログラミング初心者でもエージェントハーネスは作れますか？
A: いきなりゼロからの自作は難しいですが、Claude Agent SDKやOpenClawのようなツールを使えば、コードを書かずにエージェントを運用することは可能です。まずは既存ツールで「エージェントとは何か」を体験してから、自作に挑戦するのが効率的だと思いますよ。
Q: LangChainと自作、どちらが良いですか？
A: 用途によります。プロトタイプを素早く作りたいならLangChainが便利ですが、本番運用ではフレームワークの抽象化がデバッグの障壁になることがあるんですよね。Anthropicも「LLM APIを直接使うところから始めることを推奨」しています。
Q: エージェントのコストはどのくらいかかりますか？
A: タスクの複雑さによって大きく異なりますが、1回のタスク実行で数セント〜数ドル程度が一般的です。ルーティングパターンで簡単なタスクを安価なモデルに振り分けることで、コストを最適化できるでしょう。
Q: 有料教材を買う価値はありますか？
A: 体系的に学びたい場合や、コミュニティに参加したい場合は価値があるかもしれません。ただし、技術的な情報自体はAnthropicの公式ドキュメント、GitHub上のオープンソースプロジェクト、Qiitaやzennの解説記事で十分にカバーされている印象です。
まとめ
AIエージェントハーネスの設計は、2026年現在では「秘密のノウハウ」ではなくなりつつあります。Anthropicを筆頭に、主要なAI企業がベストプラクティスを無料で公開していますし、オープンソースの実装例も豊富です。
大事なのは以下の3点だと感じました。
- シンプルに始める：最初から複雑なアーキテクチャを組まない。単純なLLM呼び出しで済むなら、エージェント化する必要はない
- ツールの品質にこだわる：エージェントの性能は、ツールの説明文とインターフェースの品質に大きく依存する
- 人間のフィードバックを組み込む：完全自律は理想だが、現実的にはチェックポイントと介入の仕組みが必要
14,800円の有料教材を買う前に、まずAnthropicの公式記事を読んでみてください。エージェント設計の核心部分が、無料で・一次情報として手に入ります。
AIエージェントの活用に興味がある方は、AI×雑学ショート動画で収益化する方法やObsidianで第二の脳を構築する方法もあわせてチェックしてみてください。