AIエージェント時代のハーネスエンジニアリング Claude Code実装編

本資料は、AIの自律性を最大限に引き出しつつ、暴走を防いで望む方向に誘導する技術ハーネスエンジニアリングの実践的な実装手法を解説したガイドです 。
単発のプロンプトでは限界がある長時間・大規模なタスクにおいて、AIを信頼できるチームメンバへと変えるための具体的なファイル構成や自動化の仕組みを公開します 。
エンジニアがコードを書くことからAIを動かす環境を設計することへと役割をシフトさせるための、次世代のエンジニアリング指針を提示します 。

・本資料のハイライト
ハーネスエンジニアリングを構成する5段階の実装レイヤー
第1段階 ルール層：CLAUDE.mdによる行動原則と技術スタックの構造化
第2段階 コンテキスト層：MEMORY.mdを用いた、セッションを跨ぐ記憶と局所文脈の分離
第3段階 フック層：実行前後の自動検査（hooks）による、破壊的操作を防ぐガードレール
第4段階 スキル層：繰り返し作業を「型」化し、チーム全体の品質を底上げする仕組み
第5段階 エージェント・MCP層：Planner/Generator/Evaluatorによる役割分担と外部ツール連携の統合

こんな方におすすめ
・自律型AIエージェントの実装力と安全性を両立させたいエンジニア
・AIを活用した開発プロセスの標準化・自動化を推進するテックリードやPM
・AIを「ツール」ではなく「チーム」として組織に組み込みたいDX担当者

Transcript

1. AIエージェント時代の ハーネスエンジニアリング Claude Code実装編 国家資格キャリアコンサルタント 為安圭介 1
2. ハーネスエンジニアリングとは AIエージェントの自律性と安全性を両立させるため、人間が望む方向に誘導する 「手綱（ハーネス）となる環境」と「フィードバックループ」を設計する技術 https://www.philschmid.de/agent-harness-2026 より ハーネスエンジニアリングを構成する3つの柱 「エージェントハーネスは、AIモデルを包括し、長期実行タスクを 管理するインフラストラクチャです」 AIに背景と目的、何を したいのかを伝えつつ、 特定のタスクに必要な 仕様や現在の状態だけ を精選して渡す仕組み AIが「やってはいけな いこと（依存関係の ルール違反など）」を 機械的にブロックする 仕組み コンテキスト管理 アーキテクチャ 制約とガードレール 品質評価と多角的な フィードバック 1 2 3 人間ではなく、自動化 されたテスト環境や評 価用AI等を使って、AI の出力を継続的に検 証・改善する仕組み 2
3. ハーネスエンジニアリングとは 2 Planner 計画/設計エージェント Generator 実装エージェント Evaluator 検証エージェント コンテキスト不安 ⚫ 長時間のタスクでは、一貫性の喪失や、早め に作業を切り上げようとする「コンテキスト 不安」が発生 ⚫ コンパクション（履歴要約）では解消されず、 コンテキストリセット（完全クリア＋新エー ジェント起動）が必要 ✓ 実装前にスコープと仕 様を定義する ✓ タスクを小さく分ける ✓ 品質の定量化と明確 な評価基準を定める ✓ 各スプリントの開始前 には、生成エージェン トと評価エージェント の間で完了基準をを合 意させる 定期的なハーネス更新 ⚫ 新しいモデルが登場した際には、ハーネス設 計を再評価する ⚫ その際は「可能な限りシンプルな解決策を。 必要な場合にのみ複雑さを増す」という原則 に従う 設計の注意点 AIエージェントは「使う」のはなく「設計する」 Harness design for long-running application development(Anthropic公式) 3 自己評価バイアス ⚫ エージェントは自分の成果物を称賛する傾向 ⚫ Evaluatorを分離しただけでは不十分で、懐 疑的に見るよう明示的にチューニング タスクを計画、実装、検証の3エージェントで遂行する
4. ハーネスの要素を 5段階に分けて実装する 5段階の実装ステップ ルール層 ルール層 コンテキスト層 コンテキスト層 フック層 フック層 スキル層 スキル層 エージェント・ MCP層 エージェント・ MCP層 ↑ 抽象 ↓ 基盤 役割 役割 実装場所 実装場所 AIの行動原則・ロール定義＋権限設定 AIの行動原則・ロール定義＋権限設定 CLAUDE.md / .claude/settings.json CLAUDE.md / .claude/settings.json セッション横断の記憶・エージェント別局所文脈 セッション横断の記憶・エージェント別局所文脈 memory/MEMORY.md memory/MEMORY.md ツール実行前後のガードレール実装 ツール実行前後のガードレール実装 settings.json > hooks / check_*.py settings.json > hooks / check_*.py 繰り返し作業の型化 繰り返し作業の型化 .claude/skills/<name>/SKILL.md .claude/skills/<name>/SKILL.md 役割分担AIと外部ツール連携の統合管理 役割分担AIと外部ツール連携の統合管理 .claude/agents/*.md / .mcp.json .claude/agents/*.md / .mcp.json 1 1 2 2 3 3 4 4 5 5 Step 4
5. ハーネス はファイルで定義する ハーネスを定義するファイルを、AIとの対話で作成する ハーネスエンジニアリングの成果物はファイル ハーネスエンジニアリングの成果物はファイル ⚫CLAUDE.md がAIのルールを定義する ⚫hooks/*.py がAIの行動を制御する ⚫skills/*.md がAIの仕事を型化する ⚫agents/*.md がAIのチームを設計する ⚫CLAUDE.md がAIのルールを定義する ⚫hooks/*.py がAIの行動を制御する ⚫skills/*.md がAIの仕事を型化する ⚫agents/*.md がAIのチームを設計する コードを書くことは必須ではない 「何をしてほしいか」を正確に伝える 例 CLAUDE.md CLAUDE.md 「ロールはWebアプリ開発エンジニア。 実装はReact+FastAPI+PostgreSQL構成で。 本番DBと本番環境への変更は必ず確認を取って」 「ロールはWebアプリ開発エンジニア。 実装はReact+FastAPI+PostgreSQL構成で。 本番DBと本番環境への変更は必ず確認を取って」 → プロジェクト用 CLAUDE.md を自動生成 → プロジェクト用 CLAUDE.md を自動生成 hooks hooks 「本番データベースに直接 DELETE や DROP を実行しようとしたとき、 必ず確認を取るようにして」 「本番データベースに直接 DELETE や DROP を実行しようとしたとき、 必ず確認を取るようにして」 → 削除前確認のガードファイル生成 → 削除前確認のガードファイル生成 skills skills 「新機能の実装フローをスキルにしたい。 API設計→バックエンド実装→フロントエンド実装→テストの順で、 各ステップで私の承認を入れて。 /add-featureで呼び出せるようにして」 「新機能の実装フローをスキルにしたい。 API設計→バックエンド実装→フロントエンド実装→テストの順で、 各ステップで私の承認を入れて。 /add-featureで呼び出せるようにして」 → .claude/skills/add-feature/SKILL.md生成 → .claude/skills/add-feature/SKILL.md生成 必要なのは何をしてほしいかを言語化する力 5
6. 実装例① ルール層 Step1 ルール層はAIへの法律。構造化することでふるまいが安定する Before Before ReactとFastAPIでCRUDアプリを作って。 PostgreSQLをDBに使って。 コードは綺麗に書いて。 ×ロール・制約・禁止事項がバラバラ ×セッションごとに挙動がブレる ×何を守れば良いかAIが判断できない ReactとFastAPIでCRUDアプリを作って。 PostgreSQLをDBに使って。 コードは綺麗に書いて。 ×ロール・制約・禁止事項がバラバラ ×セッションごとに挙動がブレる ×何を守れば良いかAIが判断できない After 構造化CLAUDE.md After 構造化CLAUDE.md # IMPORTANT (絶対に守るべき最優先事項をここに書く) # プロジェクト概要 (プロジェクトの核心的な目的を書く) ## 技術スタック - Frontend: React + TypeScript + Vite - Backend: FastAPI（Python）/ DB: PostgreSQL ## 禁止事項 （制約ややってはいけないことを書く） # IMPORTANT (絶対に守るべき最優先事項をここに書く) # プロジェクト概要 (プロジェクトの核心的な目的を書く) ## 技術スタック - Frontend: React + TypeScript + Vite - Backend: FastAPI（Python）/ DB: PostgreSQL ## 禁止事項 （制約ややってはいけないことを書く） 作り方 構造化の要素 AIの「役割」を明示。複数ロールを 番号付きで列挙する。 AIの「役割」を明示。複数ロールを 番号付きで列挙する。 ロール定義 ロール定義 使用技術・フレームワーク・バージ ョンを明示。AIが一貫した実装判断 を行える基盤。 使用技術・フレームワーク・バージ ョンを明示。AIが一貫した実装判断 を行える基盤。 技術スタック 技術スタック やってはいけないことを明示する。 やってはいけないことを明示する。 禁止事項 禁止事項 出力フォーマット（箇条書き・文字 数・レイアウト等）を指定。 「important」で重要ルールを強調で きる 出力フォーマット（箇条書き・文字 数・レイアウト等）を指定。 「important」で重要ルールを強調で きる 出力形式 出力形式 CLAUDE.md は200行以内が推奨。ルールが増えたら .claude/rules/ フォルダに分割して管理できる 6 「AIのロールと守ってほしいルールを CLAUDE.mdに書いて」と話しかける 「AIのロールと守ってほしいルールを CLAUDE.mdに書いて」と話しかける ロールはXX、技術スタックはXX、と構造的に伝 える。また、禁止事項は明確に禁止事項、注意 事項、等と内容を伝える。 ロールはXX、技術スタックはXX、と構造的に伝 える。また、禁止事項は明確に禁止事項、注意 事項、等と内容を伝える。 コマンド許可追加時は「コマンド許可対象とし て、npm・pip・psqlを追加して」と伝え、 settings.jsonの権限設定を追加 コマンド許可追加時は「コマンド許可対象とし て、npm・pip・psqlを追加して」と伝え、 settings.jsonの権限設定を追加
7. 全コード + 全DB設計書 + 全API仕様 + テスト結果 + 会議メモ をそのまま 渡す × トークン爆発でコスト増大 × 無関係情報でエラーやハルシネー ションが増加 全コード + 全DB設計書 + 全API仕様 + テスト結果 + 会議メモ をそのまま 渡す × トークン爆発でコスト増大 × 無関係情報でエラーやハルシネー ションが増加 実装例② 第2段階 コンテキスト層 Step2 コンテキスト層は全体・セッション・エージェントを分けて設計する コンテキスト分離 第1段階 CLAUDE.md 第1段階 CLAUDE.md 全体文脈 全セッション共通の原則・ロール ・禁止事項 第2段階 MEMORY.md 第2段階 MEMORY.md セッション文脈 セッション横断の記憶・プロジェ クト状態・途中経過 第2段階 agents/*.md 第2段階 agents/*.md 局所文脈 各エージェント専用の役割・制約 （最小限） Before 全情報一括渡し Before 全情報一括渡し After コンテキスト層で分離 After コンテキスト層で分離 CLAUDE.md → 技術スタック・禁止事項 などの共通ルール MEMORY.md → 実装進捗・直近の設計決 定のみ agents/backend.md → バックエンドAI専 用の役割のみ ◎ 各層が最小限の情報だけ持つ ◎ コスト削減＋精度向上 作り方 7 CLAUDE.mdに「全体文脈」を記述(/initでもよい） 「今の作業状況を覚えておいて」 「◦◦エージェントの役割定義ファイルを作って」 # Backend API Implementation Agent ## 役割 FastAPIを用いたバックエンド実装のスペシャリスト。 **責務**: エンドポイントの実装、Pydanticスキーマ定義、SQLAlchemy/Tortoise等 のDB操作、ビジネスロジック。 **範囲外**: フロントエンド(React等)、CI/CDパイプラインの設定、CSS/UIの変更。 ## 設計指針 (詳細な設計方針を記載） ## 検証手順 実装完了後、以下のコマンドを順に実行して自己検証すること。 **静的解析** **型チェック** **テスト実行** ## Context (コンテキスト)- **全体原則**: ルートの `CLAUDE.md` に従う。 **進捗管理**: 現在のタスクステータスは `MEMORY.md` を参照。 **DB定義**: `src/models/` 以下の既存スキーマを最優先で尊重し、勝手なマイグ レーション作成前に必ず確認をとること。 # Backend API Implementation Agent ## 役割 FastAPIを用いたバックエンド実装のスペシャリスト。 **責務**: エンドポイントの実装、Pydanticスキーマ定義、SQLAlchemy/Tortoise等 のDB操作、ビジネスロジック。 **範囲外**: フロントエンド(React等)、CI/CDパイプラインの設定、CSS/UIの変更。 ## 設計指針 (詳細な設計方針を記載） ## 検証手順 実装完了後、以下のコマンドを順に実行して自己検証すること。 **静的解析** **型チェック** **テスト実行** ## Context (コンテキスト)- **全体原則**: ルートの `CLAUDE.md` に従う。 **進捗管理**: 現在のタスクステータスは `MEMORY.md` を参照。 **DB定義**: `src/models/` 以下の既存スキーマを最優先で尊重し、勝手なマイグ レーション作成前に必ず確認をとること。 生成指示例：「バックエンドAPIの実装担当エージェントを作って。FastAPIのエンドポ イント実装のみ担当」 生成指示例：「バックエンドAPIの実装担当エージェントを作って。FastAPIのエンドポ イント実装のみ担当」
8. 実装例③ 第3段階 フック層 Step3 ある実行の前後に検査を挟むことでガードレールを敷く Before フックなし Before フックなし AIが自由にツールを実行 → 本番DBにDELETE/DROPが即時実行 → 未テストのコードが本番環境にデプロイ → DBマイグレーションが意図せず実行される AIが自由にツールを実行 → 本番DBにDELETE/DROPが即時実行 → 未テストのコードが本番環境にデプロイ → DBマイグレーションが意図せず実行される After フックあり After フックあり PreToolUse でコマンドを事前検査 → 危険パターン検出でブロック＆警告 → PostToolUse で出力の品質チェック → Stop フックで最終確認・ログ記録 PreToolUse でコマンドを事前検査 → 危険パターン検出でブロック＆警告 → PostToolUse で出力の品質チェック → Stop フックで最終確認・ログ記録 作り方 生成指示例：「本番DBにDELETE/TRUNCATE/DROPを実行しようとしたとき、確認を取る安全装置を作って」→ 以下を生成： 生成指示例：「本番DBにDELETE/TRUNCATE/DROPを実行しようとしたとき、確認を取る安全装置を作って」→ 以下を生成： // settings.json（hooks設定） "hooks": { "PreToolUse": [{ "matcher": "Bash", "hooks": [{"type": "command", "command": "python check_dangerous.py"}]}] } // settings.json（hooks設定） "hooks": { "PreToolUse": [{ "matcher": "Bash", "hooks": [{"type": "command", "command": "python check_dangerous.py"}]}] } # .claude/hooks/check_dangerous.py（PreToolUse） import sys, json data = json.load(sys.stdin) cmd = data.get("command", "") DANGER = ["DROP TABLE", "TRUNCATE", "DELETE FROM", "--force"] for d in DANGER: if d in cmd: print(f"{d}を含む操作は禁止", file=sys.stderr); sys.exit(2) # .claude/hooks/check_dangerous.py（PreToolUse） import sys, json data = json.load(sys.stdin) cmd = data.get("command", "") DANGER = ["DROP TABLE", "TRUNCATE", "DELETE FROM", "--force"] for d in DANGER: if d in cmd: print(f"{d}を含む操作は禁止", file=sys.stderr); sys.exit(2) 8 追加すべき「安全な動作」を日本語で説明する 例：「本番DBにDELETE/DROPを実行する前に、 必ず確認を取るようにして」 AIがPythonスクリプトを生成 + settings.jsonのhooks設定を自動更新 「今の安全設定を教えて」と話しかけるか、 /hooksコマンドで設定一覧を確認 ツール呼び出し ツール呼び出し → PreToolUse 検査 PreToolUse 検査 → ツール実行 ツール実行 → PostToolUse 検査 PostToolUse 検査 → Stop Stop → 完了 / Block 完了 / Block
9. 実装例④ 第4段階 スキル層 Step4 スキル層＝繰り返し作業を型にする 作り方 Before 毎回自然言語で指示 Before 毎回自然言語で指示 「従業員登録のAPIを追加して。バリデーション入れて、 テストも書いて、DBマイグレーションも忘れずに。」 → 毎回同じ手順 / ステップの抜け漏れが起きる 「従業員登録のAPIを追加して。バリデーション入れて、 テストも書いて、DBマイグレーションも忘れずに。」 → 毎回同じ手順 / ステップの抜け漏れが起きる After /add-feature で一貫実装（Skills形式） After /add-feature で一貫実装（Skills形式） # .claude/skills/add-feature/SKILL.md ## 1.要件確認・承認（承認ポイント①） ## 2.FastAPIエンドポイントを実装 ## DBマイグレーションを生成・実行 ## Reactコンポーネントを実装 # .claude/skills/add-feature/SKILL.md ## 1.要件確認・承認（承認ポイント①） ## 2.FastAPIエンドポイントを実装 ## DBマイグレーションを生成・実行 ## Reactコンポーネントを実装 9 スキルの4分類 「この順番で進めて」を定 義する 毎回やっている手順をAIに委譲 する。手順の抜け漏れがなくな り、常に同じ品質で実行できる 。4分類の中で最も作りやすく 、最初の1つとして最適。 例：/add-feature（要件 →API→DB→UI→テスト→レビ ュー） 「この順番で進めて」を定 義する 毎回やっている手順をAIに委譲 する。手順の抜け漏れがなくな り、常に同じ品質で実行できる 。4分類の中で最も作りやすく 、最初の1つとして最適。 例：/add-feature（要件 →API→DB→UI→テスト→レビ ュー） A.ワークフロー制御スキル A.ワークフロー制御スキル 「こう考えて」という暗黙知 を委譲 レビュー観点・設計判断などの暗 黙知をSkillに落とし込む。言語化 が最も難しいが、効果が最も大き い分類。自分は確実にそう判断し ているが、まだ明文化していない 基準がある。 例：XSS・SQLインジェクション ・エラーハンドリングの粒度・命 名の基準 「こう考えて」という暗黙知 を委譲 レビュー観点・設計判断などの暗 黙知をSkillに落とし込む。言語化 が最も難しいが、効果が最も大き い分類。自分は確実にそう判断し ているが、まだ明文化していない 基準がある。 例：XSS・SQLインジェクション ・エラーハンドリングの粒度・命 名の基準 C.判断スキル C.判断スキル 繰り返し作業を自然言語で説明する 例：「新機能を実装するたびにAPIとUIとテストを同じ手順で作る。 一言で実行できるようにして」 「これはNG」を仕組み化す る コード規約・禁止ライブラリを Skillに定義する。毎回「〇〇は使 わないで」とプロンプトに書く手 間がなくなる。ルールが細かい場 合はCLAUDE.mdより管理しやす い。 例：実DBに接続（モック禁止）／ envはconfigモジュール経由 「これはNG」を仕組み化す る コード規約・禁止ライブラリを Skillに定義する。毎回「〇〇は使 わないで」とプロンプトに書く手 間がなくなる。ルールが細かい場 合はCLAUDE.mdより管理しやす い。 例：実DBに接続（モック禁止）／ envはconfigモジュール経由 D.ガードレールスキル D.ガードレールスキル コマンドの「勘所」を渡す 公式ドキュメントでなく、自分 の実践知を渡す。MCPが接続な らSkillは「操作ノウハウ」。AI が詳しくないCLIを毎回説明し ているなら、Skillにまとめると 便利。 例：alembicのmigrationコマン ド手順／psqlでのスキーマ確認 コマンドの「勘所」を渡す 公式ドキュメントでなく、自分 の実践知を渡す。MCPが接続な らSkillは「操作ノウハウ」。AI が詳しくないCLIを毎回説明し ているなら、Skillにまとめると 便利。 例：alembicのmigrationコマン ド手順／psqlでのスキーマ確認 B.ツール使用スキル B.ツール使用スキル
10. 実装例⑤ 第5段階 エージェント・ MCP 層 Step5 エージェント・MCP層を設計する エージェントは役割を与えられたAI個体 。MCPはAIが外部サービスを操作するための標準プロトコル ユーザ ユーザ 一言で指示 AI（例:Claude Code） AI（例:Claude Code） 全体を指揮・タスクを振り分ける Frontend UI実装担当 Backend API実装担当 Reviewer コードレビュー担当 MCP MCP MCP GitHub GitHub コード管理・PR作成 Playwright Playwright ブラウザ自動テスト PostgreSQL MCP PostgreSQL MCP DBスキーマ確認 エージェントの作り方 エージェントの作り方 「◦◦という役割のエージェントを作って。担当は〜のみ」 → .claude/agents/◦◦.md が生成される 「◦◦という役割のエージェントを作って。担当は〜のみ」 → .claude/agents/◦◦.md が生成される MCPの接続方法 MCPの接続方法 10 CLIコマンドで追加 claude mcp add --transport http <name> <url> → --scope project で .mcp.json に保存 対話で追加 「GitHubのMCPサーバ を追加して。 リポジトリ読み書きと PR操作を許可して」 → .mcp.json に自動追記 設定結果（.mcp.json） "mcpServers": { "github": { "command": "npx", "args": [...] } } エージェント
11. 実装例⑥ 品質評価・フィードバックループ レビューエージェントはデフォルトでLLM生成物に寛容なため「懐疑的に見て」と指示してチューニングが必要（作るだけでは不十分）。 フックはCLAUDE.mdの指示より強力に実行される。（Anthropic Engineering より） 品質評価の要はAIが自分で検証できる手段を与えること。 フィードバックループ（Step3+Step5） 1 1 AIが出力を生成 AIが出力を生成 ↓ 2 2 PostToolUse hook が実行 （check_output.py） PostToolUse hook が実行 （check_output.py） ↓ 3 3 テスト・Lintが失敗なら Claudeが自動修正 テスト・Lintが失敗なら Claudeが自動修正 ↓ 4 4 レビューエージェントが 最終確認 レビューエージェントが 最終確認 ↓ 5 5 改善点を次回の指示・ルールに反映 改善点を次回の指示・ルールに反映 ↺ リトライ 実装ファイル一覧 ファイル ファイル 実装内容 実装内容 Step3 出力検証 Step3 出力検証 .claude/hooks/ check_output.py .claude/hooks/ check_output.py PostToolUseで品質チェック PostToolUseで品質チェック Step5 レビュー担当 Step5 レビュー担当 .claude/agents/reviewer.md .claude/agents/reviewer.md 実装者と別コンテキストでレビュー （Generator/Evaluator） 実装者と別コンテキストでレビュー （Generator/Evaluator） Step1 ルール改善 Step1 ルール改善 CLAUDE.md CLAUDE.md 気づいたパターンをルールとして追記 気づいたパターンをルールとして追記 生成指示例（レビューエージェント）：「実装内容をチェックするレビュー担当AIを作って」 生成指示例（レビューエージェント）：「実装内容をチェックするレビュー担当AIを作って」 # .claude/agents/reviewer.md ## Role 実装者と別コンテキストで客観評価 ## Checklist - [ ] 依頼された要件をすべて満たしているか - [ ] SQLインジェクション・XSSなどの脆弱性がないか - [ ] エラーハンドリングが適切に実装されているか - [ ] APIレスポンスコードとバリデーションが正しいか ## Output: 問題あり→【要修正】＋理由 / 問題なし→【承認】＋1文評価 # .claude/agents/reviewer.md ## Role 実装者と別コンテキストで客観評価 ## Checklist - [ ] 依頼された要件をすべて満たしているか - [ ] SQLインジェクション・XSSなどの脆弱性がないか - [ ] エラーハンドリングが適切に実装されているか - [ ] APIレスポンスコードとバリデーションが正しいか ## Output: 問題あり→【要修正】＋理由 / 問題なし→【承認】＋1文評価 11 「作業のたびにテストを自動実行 して、失敗したら修正して」 「実装内容をチェックする レビュー担当AIを作って。 問題点を厳しく指摘して」 「このフォーマットで毎回確認 して」と検証基準を最初に伝える 作り方 Step1 リトライ制御 Step1 リトライ制御 settings.json settings.json hooks.PostToolUseにcheck_output.py登録 hooks.PostToolUseにcheck_output.py登録
12. まとめ： ハーネス の概念を5段階で実装 概念 概念 → 実装 実装 問 1 AIに何を・どう渡すか？ （コンテキスト設計） → 第1段階 ルール層（CLAUDE.md）でルールを固定 第1段階 ルール層（CLAUDE.md）でルールを固定 第2段階 コンテキスト層（MEMORY.md）で文脈を継続 第2段階 コンテキスト層（MEMORY.md）で文脈を継続 問 2 AIの違反をどう防ぐか？ （制約・ガードレール） → 第1段階 ルール層（settings.json）で権限制御 第1段階 ルール層（settings.json）で権限制御 第3段階 フック層（hooks）で実行前後をガード 第3段階 フック層（hooks）で実行前後をガード 問 3 品質をどう担保するか？ （評価・フィードバック） → 第3段階 フック層（PostToolUse）で出力検証 第3段階 フック層（PostToolUse）で出力検証 第4段階 スキル層（skills）でワークフローを型化 第4段階 スキル層（skills）でワークフローを型化 第5段階 エージェント・MCP層でレビュー担当を分離 第5段階 エージェント・MCP層でレビュー担当を分離 概念を型に落とすことがエンジニアの仕事 12
13. 実装ステップ 役割 対応エージェント 第1段階 CLAUDE.md （ルール層） Plannerへの制約・ロール定義 Planner 第2段階 コンテキスト層 （MEMORY.md） Context Anxiety防止・長時間動作の土 台 Generator 第3段階 フック層 （hooks/） 自動検証・ガードレール実行 Evaluator 第4段階 スキル層 （skills/） ワークフロー蓄積（/add-feature 等） Planner 第5段階 エージェント ・MCP層 Generator+Evaluatorの実装本体 Generator /Evaluator Step1～4はGeneratorが長時間・高品質に動くための土台 [補足] Anthropic の3エージェント設計との比較 13