Opening
Claude CodeやCursorを社内で使い始めている方へ。
それらが社内データに自由にアクセスしてよいか、誰が、どのように判断していますか？
Chapter 01: AIの手綱を握る『ハーネスエンジニアリング』とは何か？
現在、最先端のIT業界では、AIを安全に使いこなすために「ハーネスエンジニアリング」という新しい考え方が注目されています。
「ハーネス」とは、命綱や「手綱（たづな）」のことです。AIが会社のデータを勝手に外部に出したり、システムを壊したりしないよう、「ここから先のデータは触っちゃダメ」という安全な枠組み（ハーネス）を作ること。
そして、その安全な枠組みを社内のルールやシステムとしてどう設計し、どう管理していくかという仕組み作りのことを「ハーネスエンジニアリング」と呼びます。
『ハーネスエンジニアリング』言葉の発生 — わずか数ヶ月で定着した最新トレンド
実はこの言葉、2026年に入ってから世界のトップエンジニアやAI企業がこぞって使い始め、わずか数ヶ月で業界の常識として定着したばかりの最新キーワードなのです。
| 時期 | 主体 | 内容 |
|---|---|---|
| 2026.02 | Mitchell Hashimoto | ブログで「engineering the harness」と表現 |
| 2026.02 | OpenAI | 3人チームで100万行の本番コードを出荷した事例を公開 |
| 2025.11 / 2026.03 | Anthropic | 長時間自律動作のためのharness設計を論文化 |
| 2026.04 | Martin Fowler | エッセイで "everything surrounding the model" として定義 |
Prompt Engineering → Context Engineering → Harness Engineering という系譜の中で登場した用語である。
これまで、AIを上手く使うコツといえば「どう指示を出すか（プロンプトエンジニアリング）」が有名でしたが、これからは「AIが働く環境をどう整えるか（ハーネスエンジニアリング）」が重要になる時代へと進化している、というわけです。
〇 【参考】ハーネスエンジニアリングに関する主要文献
この新しい考え方が定着するきっかけとなった、主要な文献や事例は以下の通りです。
〇 主要文献 (1/5) — Mitchell Hashimoto: 言葉の起点
「2026.02 / 個人ブログ / HashiCorp・Terraform 共同創設者」
KEY IDEA
エージェントのミスに都度対処するのではなく、環境そのものに恒久的な修正を埋め込む実践を "engineering the harness" と名付けた。以降、業界でこの語が使われ始めた。
本記事との接続
インフラ自動化の系譜にいる人物が、AIエージェント環境を "インフラ化" する発想で命名したという出自が重要。ハーネスエンジニアリングは最初から "エージェントを賢くする" より "環境を整える" という側面を持って生まれた。
〇 主要文献 (2/5) — OpenAI: スケール実証
「2026.02 / OpenAI エンジニアリングブログ / Codex チーム」
KEY IDEA
3人のエンジニアが、人間が一行もコードを書かずに100万行超の本番システムを出荷。 カギは AGENTS.md, 再現可能な開発環境, CIでの機械的不変条件の強制。
本記事との接続
「小さなチームが大規模な成果を出す」という文脈で語られがちだが、裏を返せば "少人数での統制設計が鍵" とも読める。AGENTS.md や CIの不変条件は、Policy as Code / Guardrails の発想と地続き。
〇 主要文献 (3/5) — Anthropic: 長時間自律動作の設計
「2025.11 / 2026.03 / Anthropic Engineering Blog」
KEY IDEA
課題: エージェントはコンテキスト窓ごとにセッションが切れ、過去の作業記憶を失う。
解決: 初期化エージェント + 実行エージェントの二段構成。進捗ファイル / git履歴を外部メモリとして使い、セッション間を橋渡しする。
本記事との接続
後続記事では「ハーネスはモデルが賢くなると陳腐化する仮定を内包する」という重要な自己批判も示されています。 — 設計物ではなく、継続的に見直される規律として扱うべき領域。
〇 主要文献 (4/5) — Martin Fowler: 整理と分類学
「2026.04 / martinfowler.com / 著者: Birgitta Böckeler (Thoughtworks)」
4つの分類軸
| Computational (決定的) | Inferential (推論的) | |
|---|---|---|
| Guides (事前制御) | ルール・型チェッカー・スクリプト | 指示文書・知識注入 |
| Sensors (事後観測) | 静的解析・自動テスト | LLM-as-judge / レビューエージェント |
本記事との接続
ハーネスの三層モデル (model / builder's harness / user's harness) を提示し、"誰が設計するか" を明示化。利用側が構築する "user's harness" という概念が、運用・ガバナンスの議論を可能にする。
〇 主要文献 (5/5) — CSA / NIST: ガバナンス視点
「2026.01〜 / NIST CAISI・NCCoE・Cloud Security Alliance」
KEY IDEA
論点: AIエージェントは新たな非人間アイデンティティ (NHI) であり、従来のIDガバナンスの拡張として扱う必要がある。
方向性: 既存の OAuth 2.0 / Zero Trust (SP 800-207) / Digital Identity Guidelines (SP 800-63-4) をエージェント向けに拡張する概念ペーパーが2026年初頭に公表。
本記事との接続
IAM / Zero Trust / ID管理 の既存発想が、AIエージェント統制にそのまま延長される方向性。後述する「運用・ガバナンス」で掘り下げる論点の、理論的な裏付けとなる一次資料群。
参考文献リスト
起点 / 定義
Mitchell Hashimoto "Engineering the Harness" (2026.02)
Martin Fowler / Birgitta Böckeler "Harness engineering for coding agent users" (2026.04)
実装・設計パターン
Anthropic "Effective harnesses for long-running agents" (2025.11)
Anthropic "Harness design for long-running application development" (2026.03)
OpenAI Codex チーム "100万行を人間が書かずに出荷した事例" (2026.02)
NIST CAISI "AI Agent Identity and Authorization" 概念ペーパー (2026.01)
NCCoE "Accelerating the Adoption of Software and AI Agent Identity and Authorization" (2026.02.05) —（同上）
Cloud Security Alliance "AI Agent Governance Framework Gap" (2026.04)
〇 立場によって違う 「ハーネス」の捉え方
実はこの「ハーネス」という言葉、立場によって注目するポイントが異なります。
軸 1: AIを作る側
作る側 (Anthropic / OpenAI 等) は "長時間自律動作の実行環境" としてみています。 使う側はさらに立場で分かれます。(軸2へ)。
軸 2: 使う側の3つの立場
アプリ開発者 = 個人の生産性 / プラットフォーム = 共通基盤 / ガバナンス担当 = 組織全体の統制。 それぞれの立場によって、関心の焦点が全く異なります。
軸 3: 粒度 (ミクロな視点か / マクロな視点か)
目の前の個別AIの設計（ミクロな視点）と、会社全体のAI管理や緊急停止の仕組み（マクロな視点）。これらは全く別の話に見えますが、実は「AIをどう安全にコントロールするか」という同じ問題を、違う言葉で話しています。
本記事ではこう捉える
ハーネスエンジニアリングとは、とても広いテーマですが、この記事では『AIエージェントの実行環境 (データ境界・ツール権限・検証・監査) を設計する仕組み』として捉えます。
その上で、私たちが明日から取り組むべきテーマを、
- 個人の実装（現場でどう安全に使うか）
- 組織のガバナンス（会社としてどうルールを作るか） の2つの視点に分けて、順番に整理していきます。
Chapter 02: ハーネスは何で構成されるか？
ハーネスの代表的な分類軸 (Fowler / Böckeler による整理)
| Computational (決定的) | Inferential (推論的) | |
|---|---|---|
| Guides (事前制御) | ルール・型チェッカー・スクリプト(リンタ設定, codemod, ビルドスクリプト) | 指示文書・知識注入(AGENTS.md, CLAUDE.md, 参考ドキュメント) |
| Sensors (事後観測) | 静的解析・自動テスト(型検査, ユニットテスト, 構造検査) | LLM-as-judge / レビューエージェント(意味解析, 生成物の自動レビュー) |
このほか、複数エージェントの分業、外部メモリ (進捗ファイル等)、人間の承認ゲート、停止条件、行動ログなど、多様な要素が組み合わされます。
Chapter 03: ハーネスエンジニアリングと運用・ガバナンス
ここでは4つの論点で掘り下げていきます。
- データ境界の設計 — エージェントに渡してよいデータ / 渡してはならないデータ。MCPサーバーの権限スコープ、RAG対象データの選別、機密情報のマスキング。
- ツール実行権限の分離 — Read-only と Write-able の分離。人間の承認ゲート (HITL) をどこに挟むか。Claude Codeの権限モデル・hooks機構が参考実装。
- プロンプトインジェクション対策 — 外部データを取り込むエージェント特有のリスク。信頼境界の設計と、入力に対する防御の発想が求められる領域。
- 監査性・追跡可能性 — エージェントの行動ログをどう残すか。既存のオブザーバビリティ基盤との接続。インシデント時に追える状態を担保する。
〇 論点 01: データ境界の設計
具体例
| 判定 | 内容 |
|---|---|
| ○ | 公開ドキュメント、API仕様、OSS設定 |
| ○ | 匿名化済みのサンプルデータ |
| × | 顧客個人情報 (PII) |
| × | 認証情報・APIキー・秘密鍵 |
| × | 未公開の契約・財務情報 |
方法論
データを機密度で分類し、レベル別に扱いを定義
MCPサーバー / RAGの対象データを明示的に列挙 (許可リスト方式)
機密情報の自動マスキング・レダクション層を挟む
エージェント向けには "必要最小限のデータ" のみ提供
判断原則: 「そのデータがエージェント経由で外部 (モデル提供者) に渡ることを許容できるか?」を起点に設計する。
〇 論点 02: ツール実行権限の分離
権限の3層モデル
L1: Read-only
情報の読み取りのみ。影響範囲が閉じているため比較的自由に許可できる。
例: ドキュメント検索, 読み取りAPI呼び出し, ログ参照
L2: Write-able (限定)
状態を変更するが、影響範囲が限定的・可逆的なもの。
例: Issue作成, ブランチ操作, 下書き保存, サンドボックス環境での実行
L3: 承認必須 (HITL)
本番環境への影響・不可逆な変更は、必ず人間の承認を挟む。
例: 本番デプロイ, 顧客通知送信, DB書き込み, 決済処理
実装参考: Claude Codeの permission モード / hooks 機構、MCPサーバーのツール権限スコープ、承認フロー付きのエージェント設計
〇 論点 03: プロンプトインジェクション対策
代表的な攻撃パターン
| パターン | 説明 |
|---|---|
| 直接インジェクション | ユーザ入力に悪意ある指示を含める |
| 間接インジェクション | エージェントが読み込む外部文書・Webページに指示を埋め込む |
| ツール結果経由 | API応答・検索結果・メール本文に隠された指示 |
| データ汚染 | RAG対象ドキュメントに指示を混入させる |
方法論
| 対策 | 説明 |
|---|---|
| 信頼境界の明示 | 信頼するソースと信頼しないソースを構造的に区別 |
| 特権操作の隔離 | 外部データを扱うエージェントとツール実行エージェントを分離 |
| 出力の検証 | エージェントの判断結果を別系統でサニタイズ / 検証 |
| HITL | 高リスク操作は必ず人間の承認を挟む |
前提: 完全な防御は困難。"信頼しない入力が混入した場合、どこまで被害を抑えられるか" の発想で多層防御を設計する。
〇 論点 04: 監査性・追跡可能性
ログに残すべき項目
| 項目 | 内容 |
|---|---|
| Who | どのエージェント (ID・バージョン) が実行したか |
| What | 呼び出されたツール・API・モデル |
| Input | 与えられたコンテキスト・プロンプト (機密配慮) |
| Output | 生成物・判断結果・副作用 |
| When | タイムスタンプ / セッションID / トレースID |
既存基盤との接続パターン
OpenTelemetry 準拠 — span / trace としてエージェントの1実行を記録
構造化ログ (JSON) — 既存のログ集約基盤にそのまま流し込める形式で
コスト / 利用量も同時計測 — トークン消費・APIコストを可観測化
センシティブ情報の除去 — ログ段階でPII・秘密情報をマスキング
設計指針: インシデント時に "あのエージェントが何を見て、何を判断し、何をしたか" を時系列で再現できる状態を最低限担保する。
なぜ今「ガバナンス実装」なのか
| 数値 | 内容 | 出典 |
|---|---|---|
| 92% | AIアイデンティティの完全な可視性を欠いている | 2026 CISO AI Risk Report (n=235) |
| 86% | AIアイデンティティにアクセスポリシーを強制していない | 同上 |
| 40% | 2026年末までの企業アプリへのAIエージェント組込予測 | Gartner |
NIST / NCCoE は既存の Zero Trust (SP 800-207) と Digital Identity (SP 800-63-4) を AIエージェントに拡張する方向で検討中。
Chapter 04: 明日から何をやるか
私として 必要だと思うこと (個人の実装レベル)
自分が使うエージェントのツール権限とデータアクセス範囲を明示する
AGENTS.md / CLAUDE.md 等でコンテキストを継続的に整備する
プロンプトインジェクションを想定した入力の信頼境界設計
エージェントの行動ログを取得できる状態を維持する
組織として 必要だと思うこと (ガバナンスレベル)
社内で使われている AIエージェント / ツールの棚卸し・インベントリ化
エージェントを非人間アイデンティティとして扱う権限モデル整備
エージェント関連の情報取り扱い指針の策定と周知
ガバナンス文書への「AIエージェント」章の段階的追加
個人の対策は、明日からでもすぐに着手できます。一方で組織全体のルール作りは、関係部署との議論が必要です。まずはこの両輪を同時に走らせていくことが、私たちが安全にAIを活用するための現実的な第一歩となります。
