ハーネスエンジニアリング白書

PHPerTeaNight#35

Transcript

1. M&A CLOUD ／ ENGINEERING SHARE 2026.04 HARNESS ENGINEERING ／ WHITE PAPER ハーネスエンジニアリング⽩書 PART I — 概念編 ／ PART II — 実践編 KenjiroKubota ／@kubotak_public PREPARED 2026年4⽉ 調査レポートより
2. AGENDA ／ TWO-PART MAP 本⽇のマップ ∕ ⼆部構成 PART I 概念編 ハーネスとは何か ∕ 誰が⾔い始めたのか ∕ 何でできているのか 01 定義と位置づけ ∕ Agent = Model + Harness 02 進化の系譜 ∕ プロンプト→コンテキスト→ハーネス 03 ⽤語の起源と主要な論者 04 ハーネスの構成要素 ∕ ガイドとセンサー 05 定量的な効果 ∕ 42% → 78% の実証 PART II 実践編 明⽇から⼿を動かすための、6つのステップとアンチパターン 06 核⼼原則 ∕ Enforce with mechanisms 07 実践の6ステップ ∕ 指⽰→CI→教育→ガード→観測→掃除 08 推奨リポジトリ構成とアンチパターン 09 明⽇のチェックリスト 10 タイムライン ∕ まとめ ∕ 参考⽂献 HARNESS ENGINEERING 02 / 32
3. THE CORE EQUATION Agent エージェント = Model モデル + Harness ハーネス 同じモデルを使っていても、ハーネスが違えば別物 になる。 ハーネスとは、モデル以外のすべてを包含する概念である。 HARNESS ENGINEERING 03 / 32
4. “ OPENAI CODEX — FEB 2026 Agents aren't hard; the Harness is hard. エージェントは難しくない。 ハーネスが難しいのだ。 — Ryan Lopopolo ／ "Harness engineering: leveraging Codex in an agent-first world" HARNESS ENGINEERING 04 / 32
5. WHITE PAPER ／ VOLUME 01 ・ SLIDE 05 / 31 PART I CONCEPTS ／ FOUNDATIONS 概念編 ハーネスエンジニアリングとは何か。 誰が、いつ⾔語化し、どのような要素で構成されるのか。 実践に⼊る前に、地図を共有する。 01 定義と 位置づけ 02 進化の系譜 03 ⽤語の起源と 論者 04 構成要素 ガイド∕センサー
6. I DEFINITION ハーネスエンジニアリングとは AIエージェントが⾃律的に動作する 「環境そのもの」を設計するエンジニアリング分野。 エージェントに対して何を⾒せ、どう動かし、どう評価し、どう運⽤するかを 設計することで、 エージェントの能⼒を最⼤限に引き出しつつ、 安全性と再現 性を担保する取り組みを指す。 SCOPE ツール、制約、フィードバックループ、 観測レイヤー、ワー クフロー定義 ORIGIN 2026年2⽉ ∕ Mitchell Hashimoto NOT TO BE CONFUSED WITH ⾃動⾞‧航空機のワイヤーハーネス設計 HARNESS ENGINEERING 06 / 32
7. I EVOLUTION プロンプト → コンテキスト → ハーネス 2022 – 2024 プロンプト エンジニアリング 単⼀インタラクションにおける⼊⼒最適化。個別 タスクへの指⽰を、うまく表現する技術。 FOCUS 何を聞くか (what to ask) 2025 コンテキスト エンジニアリング コンテキストウィンドウに、タスクが解決可能と なる情報を過不⾜なく充填する技術。 FOCUS 何を⾒せるか (what to send) 2026 — ハーネス エンジニアリング ⾃律的エージェントの、完全な運⽤環境そのもの を設計する。ツール、規約、CI/CD、観測を含む。 FOCUS 全体がどう動くか (how it operates) 三者の関係は⼊れ⼦構造。ハーネスを解く⼈は、同時にコンテキストもプロンプトも解いている。 HARNESS ENGINEERING 07 / 32
8. I ORIGIN STORY ⽤語の発案者 ∕ Mitchell Hashimoto Mitchell Hashimoto HashiCorp共同創業者 Terraform 開発者 2026.02.05 ／ My AI Adoption Journey エージェントがミスを犯すたびに、 そのミスを⼆度と繰り返さないように 仕組みを設計する、という考え⽅。 ⾃⾝のAI活⽤の歩みを6つのステップで紹介し、そのステップ5を Engineer the Harness（ハーネスを設計せよ） と名付けた。 「このブログ記事はすべて⼿書きで、⾃分⾃⾝の⾔葉で書いた」と明記されており、 AI⽣成ではない⼿書きの記事であることが強調されている。 HARNESS ENGINEERING 08 / 32
9. I PROOF AT SCALE OpenAI ∕ ⼿書きゼロで100万⾏の実験 EXPERIMENT 2025年8⽉末、空のリポジトリから Codexのみで構築 を開始。 5ヶ⽉でプロダクションシステムを完成。 アプリロジック、インフラ、ツール、テスト、CI、ドキュメント、 社内 ツールのすべてをAIエージェントが記述。 レビューも段階的にエージェン ト間レビューへ移⾏。 ⽣成コード量 1M lines プルリクエスト数 ∕ 期間 1,500 PRs ⼿書き⽐ ∕ 構築期間 1/10 time “Humans steer. Agents execute.” ／ 人間が舵を取り、エージェントが実行する。 HARNESS ENGINEERING 09 / 32
10. I MULTI-AGENT HARNESS Anthropic ∕ 3エージェント構成 01 — PLANNER 計画 プロダクト仕様を、⼩さく扱いやすいチャ ンクに分解する。 「何を作るか」のみ指定 し、「どう作るか」はエージェントに委ね る。 02 — GENERATOR ⽣成 ⼀度に⼀つの機能を実装する。スプリント ⽅式。 React + Vite + FastAPI + SQLite と いった現実的スタックで動作。 03 — EVALUATOR 評価 Playwrightで実際のブラウザ操作を実⾏。 クリック、⼊⼒、スクリーンショット、 API、DB状態の全てを⾃動検証。 SINGLE AGENT — NO HARNESS 20分 ∕ $9 かろうじて動くプロトタイプ 3-AGENT HARNESS 6時間 ∕ $200 本当に使えるアプリケーション HARNESS ENGINEERING 10 / 32
11. I TWO CONTROL MECHANISMS ハーネスは2つの制御で構成される ① FEEDFORWARD Guides ∕ ガイド エージェントが⾏動する前に、振る舞いを⽅向づける仕組み。 •ゴールデンプリンシプル •プロンプトテンプレート‧宣⾔的指⽰ •エージェント向けに整えたリポジトリ構造 ② FEEDBACK Sensors ∕ センサー エージェントが⾏動した後に、逸脱を検出し⾃動修正する仕組み。 •計算的センサー ∕ 推論的センサー •CI/CDパイプライン •エージェント間レビュー ⽚⽅だけでは機能しない。両者が揃って初めてハーネスになる。 HARNESS ENGINEERING 11 / 32
12. I GUIDES — FEEDFORWARD ガイド ∕ ⾏動「前」に⽅向づけ 1 ゴールデンプリンシプル リポジトリに直接埋め込む、独断的かつ機 械的なルール。 エージェントは既存パター ンを複製する傾向があるため、 「正しいパ ターン」を意図的に埋め込む ことでアーキ テクチャのドリフトを防ぐ。 2 プロンプトテンプレート エージェントに渡す構造化された指 ⽰。 タスクの範囲、制約条件、期待す る出⼒形式を 事前に定義する宣⾔的指 ⽰の束。 3 リポジトリ構造 エージェントが参照‧学習するコード ベースの構造そのもの。 エージェント にとって 読みやすく⼀貫性のある形 に 設計する。 TERMINOLOGY アーキテクチャのドリフト — コードベースが当初の設計⽅針から徐々にずれていく現象。 エージェントは暗黙知を持たず、⽣成速度も速いため、⼈ 間のチームより深刻化しやすい。 HARNESS ENGINEERING 12 / 32
13. I SENSORS — FEEDBACK センサー ∕ ⾏動「後」に検出‧修正 COMPUTATIONAL 計算的センサー 重複コード検出、サイクロマティック複雑度、カバレッジ、スタイル違反など。 決定論的 低コスト 実績豊富 INFERENTIAL 推論的センサー LLMで意味的な重複コード、冗⻑テスト、過剰に複雑な設計を検出する。 確率論的 高コスト 意味理解 CI/CDパイプライン テスト‧リント‧型チェックを通過しなければマージできない仕組み。 エージェント間レビュー ⼈間のレビューを段階的にエージェント同⼠のレビューへ移⾏する。 HARNESS ENGINEERING 13 / 32
14. I THE LOOP フィードバックループ ∕ ⼆重の制御 ① FEEDFORWARD ガイドで 事前に誘導する エージェントが正しいコードを⽣成する確率を事前に⾼める。 •ゴールデンプリンシプル •プロンプトテンプレート •整ったリポジトリ構造 → A G E N T R U N → ② FEEDBACK センサーで 事後に修正する 問題が⼈間の⽬に届く前に、可能な限り⾃動で修正する。 •計算的∕推論的センサー •CI/CDパイプライン •エージェント間レビュー ⼈間の役割は「コードを書く」から 「エージェントが正しいコードを書く環境を設計する」へシフトする。 HARNESS ENGINEERING 14 / 32
15. I MEASURED IMPACT ハーネス改善のみで、効果は⼤きく変わる Task Success Rate 42% → 78% 同⼀モデル‧同⼀データ‧同⼀プロンプト で、 ハーネス構成の改善のみで達成。 Solve Rate Lift +64% 独⽴研究での解決率向上幅。 基本セットアップとの⽐較。 Build Time 1/10 OpenAIの100万⾏実験。 ⼿書きコードとの⽐較。 HARNESS ENGINEERING 15 / 32
16. TIMELINE 10ヶ⽉で確⽴された分野 2025.06 「コンテキストエンジニアリング」という⽤語が広く議論される Tobi Lütke ∕ Andrej Karpathy 2025.08 末 OpenAIチームがCodexによる⼿書きコードゼロの実験を開始 Ryan Lopopolo ∕ OpenAI 2025.11 Anthropicが⻑時間稼働エージェントのハーネス設計記事を公開 Anthropic Engineering 2026.02.05 Mitchell Hashimoto が "Engineer the Harness" の概念を発表 Mitchell Hashimoto 2026.02.11 OpenAI がハーネスエンジニアリングの実証記事を公開 Ryan Lopopolo ∕ OpenAI 2026.03 Anthropic がマルチエージェントハーネスに関する続編を公開 Anthropic Engineering 2026.04.02 Birgitta Böckelerが実務者向けハーネスエンジニアリング記事を公開 Martin Fowler ∕ Birgitta Böckeler — End of Part I ／ Concepts — Next → Part II ／ Practice HARNESS ENGINEERING 16 / 32
17. WHITE PAPER ／ VOLUME 01 ・ SLIDE 16 / 31 PART II PRACTICE ／ PLAYBOOK 実践編 明⽇から⼿を動かすための、6つのステップ。 “Enforce quality with mechanisms, not prompts.” STEP 1 指⽰ファイル STEP 2 フィードバック ループ STEP 3 教育的 エラーメッセージ STEP 4 ガードレール STEP 5 可観測性 STEP 6 定期クリーンアップ
18. CORE PRINCIPLE ／ PART II Enforce quality with mechanisms , not prompts. ハーネスエンジニアリングの核⼼は 「プロンプトではなく仕組みで品質を強制する」 こと — Sakasegawa's Blog ／ Harness Engineering Best Practices for Claude Code / Codex Users HARNESS ENGINEERING 18 / 32
19. II SIX PRACTICAL STEPS 実践 ∕ 明⽇から始める6ステップ 01 エージェント指⽰ファイル CLAUDE.md, AGENTS.md, .cursorrules をリポジトリ直下 に。50〜100⾏が⽬安。 02 フィードバックループ 書く→テスト→修正のサイクル。CIを通らなければマージ させない。 03 教育的エラーメッセージ 「違反‧理由‧修正⽅法」を1メッセージに。ツールが エージェントを教育する。 04 ガードレール パーミッション / Pre-commit / PreToolUseフック。最初 は厳しく、信頼で緩和。 05 可観測性 トレース‧ツール呼び出し‧判断‧失敗の4軸で記録。観 測なしに改善なし。 06 定期クリーンアップ 掃除専⽤エージェントをスケジュール実⾏。AIスロップを ⾃動で刈り取る。 HARNESS ENGINEERING 19 / 32
20. II STEP 01 — INSTRUCTION FILES Step 1 ∕ エージェント指⽰ファイル ツール ファイル名 Claude Code CLAUDE.md OpenAI Codex CLI AGENTS.md Cursor .cursorrules GitHub Copilot .github/copilot-instructions.md 短く保つ ∕ 50〜100⾏が⽬安 1,000⾏超のAGENTS.mdは、質問が始まる前にコンテキストを⾷い潰す。 「⽬次」として使う 詳細は docs/ 配下に分割し、 ポインタで誘導する形に。 記述する内容 プロジェクト規約 ∕ ディレクトリ構成 ∕ テストコマンド ∕ アーキテクチャ制約 HARNESS ENGINEERING 20 / 32
21. II STEP 02 — FEEDBACK LOOP Step 2 ∕ フィードバックループの構築 エージェントの出⼒品質と最も強く相関するのは、⾃分の仕事を検証できるかどうか 。 最⼩構成のループは「書く → テスト → 修正」である。 01 書く エージェントがコードを変更する 02 テスト 変更のたびに⾃動でテスト実⾏ 03 修正 失敗なら成功宣⾔前に⾃⼒で修正 → GATE CI / CD 通過しなければ マージできない リンター‧型チェック‧フォーマッタを必ず通す。 バックプレッシャーで品質を⾃律維持。 バックプレッシャー（backpressure） — テストやリンターがエージェントの出⼒に圧をかけ、品質を⾃律的に維持する仕組み。 HARNESS ENGINEERING 21 / 32
22. II STEP 03 — EDUCATIONAL ERRORS Step 3 ∕ 教育的エラーメッセージ BEFORE Error: Import from 'utils/legacy' is not allowed. 違反内容のみ。エージェントは修正の⼿がかりを持たない。 AFTER — for agents Error: Import from 'utils/legacy' is not allowed. Rule: no-legacy-imports Violation: Uses deprecated utils/legacy package. Remediation: Replace with import from '@app/utils/v2'. See docs/migration-guide.md for old → new mapping. OPENAI'S FRAMING “A positive form of prompt injection ” — リンターのエラーメッセージがそのままエージェントのコンテキストに注⼊ され、 ツールがエージェントを教育する構造になる。 HARNESS ENGINEERING 22 / 32
23. II STEP 04 — GUARDRAILS Step 4 ∕ ガードレール ∕ ⾏動範囲の明⽰ ## Permissions (CLAUDE.md / AGENTS.md) READ: src/, tests/, docs/ WRITE: src/, tests/ NEVER MODIFY: .env, infrastructure/, deploy/ NEVER EXECUTE: rm -rf, DROP TABLE, git push --force Pre-commitフック コミット直前に、リポジトリに⼊る前の最後の防壁。 HARNESS ENGINEERING 23 / 32 PreToolUseフック Claude Code固有。ツール呼び出し直前に危険パターンを検出しブロック。 段階的緩和の原則 最初は厳しく設定し、信頼が蓄積されるにつれて緩和していく。
24. II STEP 05 — OBSERVABILITY Step 5 ∕ 可観測性 ∕ 4つの柱で記録する 柱 記録する内容 例 トレース Traces ユーザーリクエストからの処理の全体像 PR #142生成 → 計画 → コード生成 → テスト → レビュー → マージ ツール呼び出し Tool Calls どのツールに何を渡し、何が返ったか bash("npm test") → exit 1, "TypeError..." 判断ステップ Decision Steps 各ステージでモデルが何を考えたか プロンプト / 出力 / トークン使用量 失敗 Failures エラー、リトライ、タイムアウト、 不正な出⼒ テスト失敗3回後にリトライ上限到達 最⼩構成はJSONLログで⼗分。本格化するなら Langfuse ／ W&B Weave ／ MLflow。 観測できなければ、ハーネスは改善できない。 HARNESS ENGINEERING 24 / 32
25. II STEP 06 — AUTOMATED CLEANUP Step 6 ∕ 定期クリーンアップ ∕ 掃除専⽤エージェント THE PROBLEM 週20%をAIスロップ掃除に 費やしていた。 AIエージェントが⼤量に⽣成するコードは、個々のPRは問 題なくても、 全体では微妙な不整合が蓄積していく。命名 のブレ、重複ユーティリティ、 ドキュメントと実装の乖離 など。これを AIスロップ と呼ぶ。 ※ AIスロップ — AIが⼤量⽣成した低品質なデジタルコンテンツ。 Merriam-Webster 2025年「今年の⾔葉」。 THE SOLUTION 掃除専⽤エージェントを 別に動かす。 ◆ ドキュメントと実装の乖離 ∕ 整合性チェック ◆ ゴールデンプリンシプル逸脱スキャン ◆ 重複コード‧冗⻑テストの検出と統合提案 ◆ 依存関係の監査 ∕ 不要パッケージ‧脆弱性 OpenAIチームはこれらをバックグラウンドCodexタスクで実⾏し、 ⾦曜⽇の ⼿動クリーンアップを廃⽌した 。 HARNESS ENGINEERING 25 / 32
26. II REFERENCE REPOSITORY LAYOUT 推奨リポジトリ構成 ∕ 6ステップを配置する project-root/ ├── CLAUDE.md # Step 1 ├── AGENTS.md # Step 1 ├── .cursorrules # Step 1 ├── .github/ │ └── copilot-instructions.md # Step 1 ├── docs/ │ ├── architecture.md # Step 1 目次 │ ├── golden-principles.md # Step 1 ガイド │ ├── migration-guide.md # Step 3 誘導先 │ └── quality-scores.md # Step 5 観測 ├── scripts/ │ ├── lint-for-agents.sh # Step 3 │ └── cleanup-agent.sh # Step 6 ├── .pre-commit-config.yaml # Step 2, 4 └── src/ ... ルート直下の指⽰ファイル Step 1。各ツールが⾃動参照。短く⽬次的に。 docs/ — 参照ドキュメント ゴールデンプリンシプル、移⾏ガイド、品質スコアをここに集約。 scripts/ — ⾃動化の実体 教育的リンター、定期クリーンアップをスクリプトで管理。 .pre-commit-config.yaml リント‧フォーマット‧型チェックを決定論的に強制する最終防壁。 HARNESS ENGINEERING 26 / 32
27. II ANTIPATTERNS 避けるべき5つのアンチパターン ANTIPATTERN 01 — MOST COMMON 最初から 過剰設計しない 初⽇からフック、MCPサーバー、マルチエージェントオーケ ストレーションを⽤意する必要はない。 最良のハーネスは、 実際の失敗パターンから有機的に育つも の であり、理論的要件からトップダウンで設計するものでは ない。 ANTIPATTERN 02 ⽚⽅だけに偏る フィードバックだけ → エージェントが同じミスを 繰り返す。フィードフォワードだけ → ルールが機 能しているか検証されない。 ANTIPATTERN 03 指⽰ファイルの肥⼤化 すべてを「重要」とすると、何も重要でなくな る。巨⼤なドキュメントはすぐに陳腐化する。 ANTIPATTERN 04 プロンプトで品質を強制 「規約を守って」は確率論的遵守。リンターでPR をブロックするのが決定論的制約。 ANTIPATTERN 05 ハーネスの放置 モデルが進化すれば前提も変わる。不要になった スキャフォールディングは取り除く。 HARNESS ENGINEERING 27 / 32
28. II TOMORROW'S CHECKLIST 明⽇のチェックリスト ∕ 3段階で整える WEEK 1 ／ 土台 書く環境を 整える ☐ CLAUDE.md / AGENTS.md を置く ☐ 50〜100⾏に収める ☐ テストコマンドを明記 ☐ docs/architecture.md を作る WEEK 2-3 ／ 防壁 壊させない 仕組みを作る ☐ pre-commit でリント∕型 ☐ CIでマージブロック ☐ Permissions セクション記述 ☐ リンターに理由と修正⽅法 ☐ 危険コマンドをフックで阻⽌ WEEK 4+ ／ 自動運転 観測して 育てる ☐ JSONLログを保存 ☐ 失敗パターンを棚卸し ☐ 定期クリーンアップを起動 ☐ 不要なガードを削る ☐ 失敗から次の1⼿を設計 ⼀度に全てを導⼊しない。「失敗を観察 → 1つ⾜す」を週次で繰り返すのが、最も速く、最も壊れにくい育て⽅。 HARNESS ENGINEERING 28 / 32
29. KEY TAKEAWAYS 持ち帰っていただきたい3つのこと 01 合算で考える Agent = Model + Harness。 モデルを変えずに、 ハーネスで成果を動かせる。 02 メカニズムで強制する プロンプトで頼まない。リンター、CI、フックで 決定論的にブロックする。 03 失敗から育てる 理論でトップダウン設計せず、 観測された失敗か ら、有機的に積み上げる。 “Humans steer. Agents execute.” HARNESS ENGINEERING 29 / 32
30. REFERENCES — PRIMARY SOURCES 主要な参考⽂献 ∕ ⼀次資料 ORIGIN 2026.02.05 Mitchell Hashimoto — "My AI Adoption Journey" HashiCorp 共同創業者。Step 5 "Engineer the Harness" で⽤語を初出。 https://mitchellh.com/writing/my-ai-adoption-journey PROOF 2026.02.11 Ryan Lopopolo / OpenAI — "Harness engineering: leveraging Codex in an agent-first world" 5 ヶ⽉ / 100 万⾏ / 1,500 PR / ⼿書きコード 0 ⾏の実証記録。本⽩書の中核事例。 https://openai.com/index/harness-engineering/ MULTI-AGENT 2025.11 Anthropic — "Harness design for long-running application development" ⻑時間稼働エージェントのハーネス設計。Planning / Generation / Evaluation の分離を提唱。 https://www.anthropic.com/engineering/harness-design-long-running-apps MULTI-AGENT 2026.03 Anthropic — "Effective harnesses for long-running agents" マルチエージェントハーネスの続編。3 エージェント構成のアーキテクチャパターン。 https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents TAXONOMY 2026.04.02 Birgitta Böckeler / Martin Fowler — "Harness engineering for coding agent users" Guides (feedforward) / Sensors (feedback) 分類の確⽴。業界標準語彙の源流。 https://martinfowler.com/articles/harness-engineering.html CONTEXT 2025.06 Tobi Lütke / Simon Willison — "Context engineering" ⽤語の直接の前⾝。Shopify CEOとSimon Willisonによる2025年6⽉の議論。 https://x.com/tobi/status/1935533422589399127 ／ simonwillison.net/2025/Jun/27/context-engineering/ ⼀次資料 ∕ 原著者による発表記事‧発信 続く → 分析‧実践⽂献 HARNESS ENGINEERING 30 / 32
31. REFERENCES — ANALYSIS, PRACTICE & RELATED 主要な参考⽂献 ∕ 分析‧実践‧周辺 INDUSTRY REPORT ／ 2026.02 InfoQ — "OpenAI Introduces Harness Engineering" www.infoq.com/news/2026/02/openai-harness-engineering-codex/ INDUSTRY REPORT ／ 2026.04 InfoQ — "Anthropic Designs Three-Agent Harness" www.infoq.com/news/2026/04/anthropic-three-agent-harness-ai/ INTERVIEW ／ 2026.04 Latent Space — Ryan Lopopolo "Extreme Harness Engineering" www.latent.space/p/harness-eng JAPANESE PRACTICE ／ 2026 Sakasegawa's Blog — "Harness Engineering Best Practices for Claude Code / Codex Users" nyosegawa.com/en/posts/harness-engineering-best-practices-2026/ PRACTICE GUIDE ／ 2026 Augment Code — "Harness Engineering for AI Coding Agents" www.augmentcode.com/guides/harness-engineering-ai-coding-agents CONFIG GUIDE ／ 2026 DeployHQ — "How to Configure Every AI Coding Assistant" www.deployhq.com/blog/ai-coding-config-files-guide ENTERPRISE GUIDE ／ 2026 Software Mansion — "Harness engineering (Agentic Engineering)" agentic-engineering.swmansion.com/becoming-productive/harness-engineering/ STRUCTURED WORKFLOW ／ 2026.04.07 Red Hat Developers — "Harness engineering: structured workflows" developers.redhat.com/articles/2026/04/07/harness-engineering-structured-workflows-ai-assisted-development PATTERN SERIES ／ 2026 Ken Huang — "Claude Code Harness Pattern 4: Permissions" kenhuangus.substack.com/p/claude-code-harness-pattern-4-permission EVOLUTION ／ 2026 Epsilla — "The Third Evolution: Why Harness Engineering Replaced Prompting" www.epsilla.com/blogs/harness-engineering-evolution-prompt-context-autonomous-agents OBSERVABILITY ／ 2026 LangChain / groundcover — "AI Agent Observability" www.langchain.com/articles/agent-observability ／ www.groundcover.com/learn/observability/ai-agent-observability CULTURAL CONTEXT ／ 2025 Wikipedia / PBS News — "AI slop" (Merriam-Webster Word of the Year) en.wikipedia.org/wiki/AI_slop ／ www.pbs.org/newshour/nation/merriam-websters-word-of-the-year-for-2025-is-ais-slop FAILURE MODES ／ 2026 Devplan / HumanLayer — "The Harness Is Everything" www.devplan.com/blog/the-harness-is-everything-why-your-ai-coding-agent-keeps-failing 本レポートは Web 上の公開⽂献に基づいて作成 ∕ 31 / 32
32. COLOPHON ／ ABOUT THIS DOCUMENT MADE WITH CLAUDE この資料について 本⽩書は、M&A Cloud エンジニアリング組織における AI活 ⽤のリファレンス資料として、 Claude を⽤いた⼆段階の 制作フローで作成されました。 01 — RESEARCH Claude Cowork Web上の公開⽂献を横断的に調査し、 ⼀次資料‧⼆次資料を構造化し てレポート化。 02 — DESIGN Claude Design 調査レポートをもとに、M&A Cloud の デザインシステムで本スライド を構成。 M&A Cloud ／ Engineering Share 2026.04 ／ Harness Engineering White Paper HARNESS ENGINEERING 32 / 32