Upgrade to Pro — share decks privately, control downloads, hide ads and more …

ハーネスは育てるもの

Avatar for suda0033 suda0033
August 02, 2026

 ハーネスは育てるもの

ハーネスエンジニアリングのやり方についての紹介

Avatar for suda0033

suda0033

August 02, 2026

More Decks by suda0033

Other Decks in Technology

Transcript

  1. RECAP 振り返り:Agent = Model + Harness 同じモデルでも、ハーネス次第で成果は大きく変わる Model モデル本体 +

    Harness 取り巻く環境 = Agent 自律的に働くAI ハーネス=モデルを取り巻く環境の総体 ルール・自動チェック・手順書・ツール連携 構成要素:CLAUDE.md / hook / Skill / subagent / MCP 構成要素のカタログは前回やった。今日は「どう育てるか」の話 ハーネスは育てるもの 2 / 16
  2. TERMINOLOGY 用語の整理:「◯◯エンジニアリング」の現在地 設計の焦点は「言い方→見せ方→環境→回し方→つなぎ方」へと外側に拡大してきた。今日は「環境」の話 用語 設計対象 一言で プロンプトエンジニアリング 何を言うか 指示の出し方。全員が毎日使う コンテキストエンジニアリング

    何を見せるか コンテキストに何を入れ、何を入れないか ハーネスエンジニアリング どんな環境を用意するか ルール・チェック・手順書 ←今日の主役 ループエンジニアリング いつ・どれだけ反復させるか 実装→検証の回し方の設計 グラフエンジニアリング 複数のループをどうつなぐか 複数エージェントや承認の配線 ※ ループ(2026年・Addy Osmani氏が命名)/グラフ(2026年夏〜)は新しい層。どちらもハーネスが土台にある点は変わらない ハーネスは育てるもの 3 / 16
  3. FRAMEWORK 核心フレーム:ミスの受け皿は4段階 左ほど手軽だが揮発し、右ほど手間だが確実に資産になる ① 毎回言う プロンプト → ② 常に読ませる CLAUDE.md・ルール

    → ③ 機械的に検証する hook・lint・型・テスト → ④ 手順書化する Skill ①は使い捨て、②はAIの「注意力」頼み、③は確実、④は再現可能 ミスが起きるたびに、対策をこの4段階のどこかに入れる これが「ハーネスを育てる」の正体 今日はこのフレームに沿って ②③④ の実践を見ていく ハーネスは育てるもの 5 / 16
  4. DECISION 判断フロー:ミスが起きたらどこに入れるか 「機械で検出できるか」「定型手順か」の2つの質問で置き場所が決まる ミス・指示の性質 置き場所 機械的に検出・強制できる ③ hook / lint

    / CI 毎回必要な前提知識・方針 ② CLAUDE.md 繰り返す定型ワークフロー ④ Skill 今回限りの指示 ① プロンプトでOK 迷ったら右(③④)に寄せる 文章ルールは守られないことがある。機械チェックは守られる ハーネスは育てるもの 6 / 16
  5. A N T I - PAT T E R N

    CLAUDE.mdアンチパターン:肥大化 「書くほど効く」は幻想。長くなるほど1行あたりの効きは薄まる ルールは常にコンテキストに載る 量が増えるほど、本題に使えるコンテキストを圧迫する ルールが守られなくなったら、まず量を疑う。定期的に棚卸しする 逃がし先を持つ 機械チェックできるルール 「フォーマットを守る」など 特定ファイル限定のルール 「このディレクトリでは〜」など ハーネスは育てるもの → ③ hook / lint へ移す → 条件付きRuleへ移す 8 / 16
  6. PRACTICE: HOOK hook実践:機械で検証できるものは文章にしない 「実行して検証する」hookは確実に効く。「操作をブロックする」hookは保険程度と心得る hook=指定タイミングでコマンドを自動実行する仕組み(例:ツール実行後、セッション開始時) 効くやつ:編集のたびに formatter / lint を自動実行

    AIが指摘を見て自分で直す。文章ルールと違いコンテキストも消費しない 保険程度:危険コマンド・保護ファイルへの操作ブロック コマンド文字列のパターンマッチは別コマンド・別経路で回避されうる(公式もベストエフォートと明言) 本当に守りたいものはOS・環境レベルで守る(コンテナ隔離、そもそも権限を渡さない) ハーネスは育てるもの 9 / 16
  7. CASE STUDY 実例:このスライドもSkillで作られている スライド作成Skillは、実際にミスのたびに手順書へ追記して育てた Skillに実際に追記されたルール(すべて実際のミス由来) 「絵文字はPDF化で描画されない → 使用禁止」 「HTMLが末尾で切れることがある →

    PDF化前に毎回末尾チェック」 「はみ出しに気づけない → 全ページ画像化して目視検証を必須化」 最初は崩れたスライドを出してきた → 今は骨子レビューから検証まで同じ手順で安定して回る ミス発生 → 手順書に1行追記 → 同じミスが再発しなくなる ↻ ※ ミス1つ→追記1行の積み重ねが、そのまま品質の履歴になっている ハーネスは育てるもの 11 / 16
  8. DEEP DIVE subagentの動き方:委譲で何が変わるか レビューは「空のコンテキストで読む他人」に任せられる。複雑なタスクは司令塔が分割して委譲する 枠線=メインAI / 塗り=subagent(呼ばれるたびに空のコンテキストで起動し、渡されたものだけを見る) メインAI A:subagentなし 実装

    メインAI B:レビューを委譲 実装 セルフレビュー → 差分+レビュー観点 → メインAI(司令塔) C:司令塔パターン メインAI 経緯を覚えたまま タスク分割・指揮 レビューsubagent まっさらな目でレビュー 指示+文脈 → =自分の答案を自分で採点。思い込みも一緒に持ち込む 実装subagent 実装 指摘リスト → 差分 → メインAI 指摘を反映 レビューsubagent レビュー =「他人の目」になる 報告 → メインAI 統合・判断 =メインは指揮情報だけ持つ。大きいタスクでもコンテキストが溢れない 使い分けの目安:小さな修正は A、品質を上げたい実装は B、複雑・大きいタスクは C ※ subagent同士が直接やり取りしながら進める「Agent Teams(エージェントチーム)」という発展形もある(使いどころは限られる) ハーネスは育てるもの 13 / 16
  9. SUMMARY まとめ ミス1つを恒久対策1つに。受け皿は「ルール→機械チェック→手順書」の順で右に寄せる ① プロンプト → ② CLAUDE.md → ③

    hook・lint・テスト → ④ Skill セッションが変わればAIは「別人」。注意は消えるが、環境は残る AIのミスは「注意」ではなく「環境」で再発防止する ハーネスはコードとして共有・レビューし、チームの資産として育てる 今日の「またやらかした」を、明日の1行に変えよう ハーネスは育てるもの 15 / 16