Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
ハーネスは育てるもの
Search
suda0033
August 02, 2026
Technology
15
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
ハーネスは育てるもの
ハーネスエンジニアリングのやり方についての紹介
suda0033
August 02, 2026
More Decks by suda0033
See All by suda0033
AI駆動開発で実践してきたこと
suda0033
0
6
仕様(spec)駆動開発、仕様はどう書く?
suda0033
0
20
PDFでドキュメントをレビュー -コメント記入マニュアル
suda0033
0
7
AIはどこまでタスクを自動化できるのか
suda0033
0
8
なぜAI駆動開発でExcelは嫌われるのか
suda0033
0
15
はじめてのClaude Code
suda0033
0
13
Vivliostyle -MarkdownをPDFドキュメントに-
suda0033
0
7
Other Decks in Technology
See All in Technology
aws-iot-platform-architecture-use-cases.pdf
ma2shita
0
320
AI時代の「技術的負債」の変質ー概念の終焉と再解釈、エージェントと共に向かう先
nwiizo
1
2.9k
なぜ「決定性」が 決定的に重要なのか? Durable Execution 基盤の数理的理解 #serverlessjp / ServerlessDays Tokyo 2026
ytaka23
3
670
HRC_Frontend_Conference_Fukuoka_2026.pdf
ts020
0
750
SREの視点で考えるSIEM活用術 〜AWS環境でのセキュリティ強化〜
cscengineer
PRO
0
110
AIによるクリエイティブ生成を行う上での試行錯誤
plaidtech
PRO
0
160
Issue 駆動でスペシャリストの意図を届ける、AI 実装のアクセシビリティ向上
thkt
0
120
10Xに技術的負債をもたらした「2つの境界の歪み」その構造と解消への営み
10xinc
0
2.1k
「守り」で活用するオンデバイスLLM 〜写ってはいけないを総力戦で防ぐ〜 / iOSDC Japan 2026
nakamuuu
0
170
2026_devsumi_ozono.pdf
o3
3
520
俺の仕事は AIに奪われないし、たぶんその BIも要らない
hikaruri
0
520
AIは推し活である。
kurazuuuuuu
1
550
Featured
See All Featured
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
35
2.6k
Site-Speed That Sticks
csswizardry
13
1.5k
Exploring the Power of Turbo Streams & Action Cable | RailsConf2023
kevinliebholz
37
6.6k
Leading Effective Engineering Teams in the AI Era
addyosmani
9
2.6k
Practical Orchestrator
shlominoach
192
12k
4 Signs Your Business is Dying
shpigford
187
23k
Fantastic passwords and where to find them - at NoRuKo
philnash
52
3.8k
Writing Fast Ruby
sferik
630
63k
How to Think Like a Performance Engineer
csswizardry
28
2.8k
Bioeconomy Workshop: Dr. Julius Ecuru, Opportunities for a Bioeconomy in West Africa
akademiya2063
PRO
1
360
Embracing the Ebb and Flow
colly
88
5.2k
Dealing with People You Can't Stand - Big Design 2015
cassininazir
367
27k
Transcript
H ハーネスは育てるもの 〜AIのミスを、チームの資産に変える実践〜
RECAP 振り返り:Agent = Model + Harness 同じモデルでも、ハーネス次第で成果は大きく変わる Model モデル本体 +
Harness 取り巻く環境 = Agent 自律的に働くAI ハーネス=モデルを取り巻く環境の総体 ルール・自動チェック・手順書・ツール連携 構成要素:CLAUDE.md / hook / Skill / subagent / MCP 構成要素のカタログは前回やった。今日は「どう育てるか」の話 ハーネスは育てるもの 2 / 16
TERMINOLOGY 用語の整理:「◯◯エンジニアリング」の現在地 設計の焦点は「言い方→見せ方→環境→回し方→つなぎ方」へと外側に拡大してきた。今日は「環境」の話 用語 設計対象 一言で プロンプトエンジニアリング 何を言うか 指示の出し方。全員が毎日使う コンテキストエンジニアリング
何を見せるか コンテキストに何を入れ、何を入れないか ハーネスエンジニアリング どんな環境を用意するか ルール・チェック・手順書 ←今日の主役 ループエンジニアリング いつ・どれだけ反復させるか 実装→検証の回し方の設計 グラフエンジニアリング 複数のループをどうつなぐか 複数エージェントや承認の配線 ※ ループ(2026年・Addy Osmani氏が命名)/グラフ(2026年夏〜)は新しい層。どちらもハーネスが土台にある点は変わらない ハーネスは育てるもの 3 / 16
PROBLEM セッションが変わったAIは「別人」 セッションが切り替わった瞬間、AIは記憶ゼロの「別人」に入れ替わっている。引き継がれるのは環境だけ あるある 「またテスト消して直したことにした」「また絵文字入れた」「前も言ったのに」 ドキュメントやコードを爆速で読めるので賢く「見える」が、前のセッションで注意したことは何も引き継いでいない 人間の新人なら一度注意すれば覚える。AIは毎回、初日の新人が来ている状態 これを知らずに「注意」を繰り返して消耗している人が多い だから対策は「注意」ではなく「環境」に刻む 環境(ルール・チェック・手順書)だけがセッションを跨いで残る
ハーネスは育てるもの 4 / 16
FRAMEWORK 核心フレーム:ミスの受け皿は4段階 左ほど手軽だが揮発し、右ほど手間だが確実に資産になる ① 毎回言う プロンプト → ② 常に読ませる CLAUDE.md・ルール
→ ③ 機械的に検証する hook・lint・型・テスト → ④ 手順書化する Skill ①は使い捨て、②はAIの「注意力」頼み、③は確実、④は再現可能 ミスが起きるたびに、対策をこの4段階のどこかに入れる これが「ハーネスを育てる」の正体 今日はこのフレームに沿って ②③④ の実践を見ていく ハーネスは育てるもの 5 / 16
DECISION 判断フロー:ミスが起きたらどこに入れるか 「機械で検出できるか」「定型手順か」の2つの質問で置き場所が決まる ミス・指示の性質 置き場所 機械的に検出・強制できる ③ hook / lint
/ CI 毎回必要な前提知識・方針 ② CLAUDE.md 繰り返す定型ワークフロー ④ Skill 今回限りの指示 ① プロンプトでOK 迷ったら右(③④)に寄せる 文章ルールは守られないことがある。機械チェックは守られる ハーネスは育てるもの 6 / 16
PRACTICE: CLAUDE.MD CLAUDE.md実践:書き方 短く・具体的に・行動レベルで。「良いコードを書く」は書くだけ無駄 効かない例(一般論・ポエム) 効く例(行動レベルの1行) 「保守性を意識する」 「DBアクセスは必ずrepository層を経由する」 「きれいなコードを書く」 「コミットメッセージは日本語・命令形で書く」
一般論はAIの行動を変えない。行動が変わる粒度まで具体化する ミスが起きるたびに1行追加、が基本の育て方 ハーネスは育てるもの 7 / 16
A N T I - PAT T E R N
CLAUDE.mdアンチパターン:肥大化 「書くほど効く」は幻想。長くなるほど1行あたりの効きは薄まる ルールは常にコンテキストに載る 量が増えるほど、本題に使えるコンテキストを圧迫する ルールが守られなくなったら、まず量を疑う。定期的に棚卸しする 逃がし先を持つ 機械チェックできるルール 「フォーマットを守る」など 特定ファイル限定のルール 「このディレクトリでは〜」など ハーネスは育てるもの → ③ hook / lint へ移す → 条件付きRuleへ移す 8 / 16
PRACTICE: HOOK hook実践:機械で検証できるものは文章にしない 「実行して検証する」hookは確実に効く。「操作をブロックする」hookは保険程度と心得る hook=指定タイミングでコマンドを自動実行する仕組み(例:ツール実行後、セッション開始時) 効くやつ:編集のたびに formatter / lint を自動実行
AIが指摘を見て自分で直す。文章ルールと違いコンテキストも消費しない 保険程度:危険コマンド・保護ファイルへの操作ブロック コマンド文字列のパターンマッチは別コマンド・別経路で回避されうる(公式もベストエフォートと明言) 本当に守りたいものはOS・環境レベルで守る(コンテナ隔離、そもそも権限を渡さない) ハーネスは育てるもの 9 / 16
PRACTICE: SKILL Skill実践:定型ワークフローは手順書にする 「毎回同じ説明をしている作業」はSkill(手順書)にすると、品質が再現可能になる Skill=AIが読む作業手順書 手順+チェックリスト+テンプレートのセット 向いている作業:定型の成果物作成、リリース作業、レビュー観点、調査の型 プロンプトとの違い プロンプトで毎回説明 説明の質に依存してブレる
ハーネスは育てるもの vs Skillに手順書化 誰が頼んでも同じ品質 10 / 16
CASE STUDY 実例:このスライドもSkillで作られている スライド作成Skillは、実際にミスのたびに手順書へ追記して育てた Skillに実際に追記されたルール(すべて実際のミス由来) 「絵文字はPDF化で描画されない → 使用禁止」 「HTMLが末尾で切れることがある →
PDF化前に毎回末尾チェック」 「はみ出しに気づけない → 全ページ画像化して目視検証を必須化」 最初は崩れたスライドを出してきた → 今は骨子レビューから検証まで同じ手順で安定して回る ミス発生 → 手順書に1行追記 → 同じミスが再発しなくなる ↻ ※ ミス1つ→追記1行の積み重ねが、そのまま品質の履歴になっている ハーネスは育てるもの 11 / 16
NEXT STEP 拡張ポイント:subagent / MCP ハーネスが育ってきたら、責務分離(subagent)と外部連携(MCP)で伸ばす subagent:役割を分けたAIに作業を委譲する どのタイミングで何を委譲するかは次ページで図解 MCP:外部ツール連携で、AIの見える範囲・触れる範囲を広げる どちらも「入れると強いが、最初からは要らない」
②CLAUDE.md ③hook ④Skill が回ってからでいい さらにその先が、冒頭で触れたループ/グラフ層(回し方・つなぎ方の設計) ハーネスは育てるもの 12 / 16
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
TEAM チーム展開:ハーネスもコードとして扱う ハーネスはリポジトリに入れてPRでレビューする。個人の秘伝のタレにしない CLAUDE.md・hook・Skill をプロジェクトのリポジトリで共有 新メンバー(人もAIも)が初日から同じ品質で作業できる ハーネスの変更もPRでレビューする 「このルール追加で何のミスを防ぐのか」が履歴に残る CI(claude-code-action等)にも同じCLAUDE.mdが効く 手元のAIも、CIのAIも、同じ規範で動く
ハーネスは育てるもの 14 / 16
SUMMARY まとめ ミス1つを恒久対策1つに。受け皿は「ルール→機械チェック→手順書」の順で右に寄せる ① プロンプト → ② CLAUDE.md → ③
hook・lint・テスト → ④ Skill セッションが変わればAIは「別人」。注意は消えるが、環境は残る AIのミスは「注意」ではなく「環境」で再発防止する ハーネスはコードとして共有・レビューし、チームの資産として育てる 今日の「またやらかした」を、明日の1行に変えよう ハーネスは育てるもの 15 / 16
H CLOSING ミス1つを、恒久対策1つに ハーネスはチームの資産として育つ ご清聴ありがとうございました