1 / 6
社内勉強会資料

Anthropicが提唱する
AIエージェントの出力品質を向上させる 「ハーネス設計」

〜長時間コーディングを安定させるマルチエージェント構成の実践〜

本日の目的

単一AIの限界を理解し、自社環境（Codex等）で高品質な出力を維持するための設計手法を学ぶ。

なぜ長時間稼働で品質が落ちるのか？

⚠️ 単一AIの限界（構造的問題）

  • 1
    コンテキスト不安 会話履歴が長くなると「早く終わらせなきゃ」とAIが焦り、未完成のままタスクを切り上げてしまう。
  • 2
    自己評価の甘さ 自身が書いたコードを自身でレビューさせても、「よくできています」と評価してしまい品質が上がらない。

💡 解決策：ハーネス設計

「何を言うか」ではなく「どう動かすか（外部構造）」の設計。
生成AIと評価AIを分離し、フィードバックループを回す。

※履歴の要約ではなく、状態をファイルに書き出す「コンテキストリセット」が重要。

自己改善ループ Planner 仕様書を作る (初回のみ) Generator 1機能ずつ 実装する Evaluator ブラウザ実操作 で検証・採点 完成 仕様書 実装コード 全パス 不合格 合格

3エージェント構成の役割（フルハーネス）

🗺️

Planner （プランナー）

役割

短い指示から詳細な「仕様書」を作成。

特徴

実装詳細（どう作るか）には踏み込まず、「何を作るか」の定義に特化することで、後工程の混乱を防ぐ。

▶
💻

Generator （ジェネレーター）

役割

仕様書に基づき実装を行う実行部隊。

特徴

作業着手前に、Evaluatorと「スプリント契約（何をもって完了とするかの事前合意）」を結び、曖昧な実装を防ぐ。

▶
🛡️

Evaluator （エバリュエーター）

役割

成果物をテスト・採点し、問題があれば不合格にして差し戻す。

特徴

コードを読むだけでなく、テストツール等を用いて「実際にアプリを操作する」動的テストを実施。基準に対して厳格にチューニングされる。

自社環境（Codex等）での実装方法

ハーネス設計を実際の開発環境でどのように運用するかの具体例です。

1
📄

README.md を活用した「共通ルール」の定義

  • 役割と合格基準の明文化：「Generator（作る）」「Evaluator（検査）」の役割と、「一項目でも未達なら不合格」という明確なラインを記載します。
  • 「お手本」の参照：過去の成功データ（DSL）をルールに紐付け、AIが迷わず一貫した品質で作成できるようにします。
2
重要設定
⚙️

Skillsを活用した「役割の分担」

  • 担当ごとの専用指示書：構築特化AIと検査（QA）特化AIで、持たせる「スキル」を完全に切り分けます。
  • 検査担当への厳格な命令：「妥協を許さない検査官として、実際にツールを動かし、不備があれば即座に作り直しを命じる」といった指示を与えます。
3
🔄

「合格するまで作り直す」サイクルの自動化

  • バトンタッチの仕組み：検査担当が不合格理由をファイルに書き出し、構築担当へ自動で引き継ぎます。
  • 納得いくまで繰り返す：AI同士がバトン形式で「検査」と「修正」を繰り返し、全基準をクリアするまで自動でブラッシュアップします。

ハーネス設計のメリデメと運用方針

👍 ■ メリット：確実な品質向上

  • ●
    自己評価のバイアスがなくなり、静的解析では見抜けないユーザー体験に関わるバグを発見・修正しやすくなる。
  • ●
    無難でテンプレート的な出力（AIスロップ）から脱却しやすくなる。

📉 ■ デメリット：コンテキスト消費量の増大

  • ●
    エージェント間で会話のやり取りが複数回発生するため、トークン消費量（コスト）と実行時間が大きく増加する。

🎯 実運用に向けた推奨アプローチ（結論）

1 要件明確 / 主観的品質重視 の場合

Plannerを省略し、Generator ＋ Evaluatorの2エージェント構成で消費を抑える。

2 数時間にわたる大規模構築 の場合

構造的な品質低下を防ぐため、フルハーネス（3エージェント）構成を採用する。

💡

【マインドセット】
ハーネスは「AIの苦手を補う仕組み」。AIモデルの進化に合わせて不要な手順は削り、運用を最適化していく姿勢が求められます。

実践事例：Dify DSLデータ作成のハーネス運用

単発生成から反復型フローへ。過去資産を活用し、高品質なDSLを安定構築する仕組み

🔄 3エージェントの具体的な役割（反復型フロー）

🗺️

Planner（要件すり合わせ）

  • 役割：短い指示から「要件すり合わせメモ」を作成。
  • 特徴：DB設計やAPI詳細など「どう作るか」には踏み込まず、「何を作るか」の定義に集中する。
💻

Generator（スプリント開発）

  • 役割：1機能ずつ、1スプリント単位で組み上げる。
  • 特徴：ゼロベースで作らず、過去DSLやテンプレート（references）を参照して実装。自己点検を行ってから次へ渡す。
🛡️

Evaluator（実操作検証）

  • 役割：実環境でのテストと合否判定。
  • 特徴：Playwright MCPを使用した実操作（インポート・画面操作）で確認。
    1つでも基準未達があれば不合格とし、即座に修正ループへ回す。

📁 Dify_harness フォルダ構成

Dify_harness/
├─ roles/ ... 各役割の指示書
├─ references/ ... 過去DSL・テンプレ（※参照用）
├─ output/ ... 中間成果物・評価結果の置き場
└─ skill/ ... ハーネス動作用 Codex Skill

📌 運用上の重要ルール

1

過去資産の徹底活用

ゼロから作らず、必ず references の台帳を参照する。共通価値が高いDSLは原本へ随時フィードバックする。

2

正本の厳密な分離

中間メモや合否履歴は output に留め、最終合格したDSLのみを対象部門の「正本フォルダ」へ保存する。