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

ハーネスは育てるもの

Sponsored · Ship Features Fearlessly Turn features on and off without deploys. Used by thousands of Ruby developers.
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