公開日:
本記事では、AIエージェントのハーネス設計を、モデルの外側にある知識、ツール、実行環境、検証、承認、記録を整える実務設計として扱います。
- 要点1: プロンプトだけでなく、参照情報やツール、権限、テストまで設計する
- 要点2: 知識層、実行層、統制・評価層の3層で整理する
- 要点3: 自律性を上げる前に、最小権限と人の承認を組み込む
対象読者：AIエージェントを業務導入する経営者、DX推進担当者、情報システム部門
今日やること: 対象業務を1つ選び、AIが参照する情報、使えるツール、承認が必要な操作を書き出す
この記事の目次
AIエージェント活用では、モデルの選定やプロンプト改善に注目が集まりがちです。しかし、実務の成否を左右するのは、AIの外側にある仕事環境です。
2026年8月30日、木本一博氏（@kinopee_ai）は、Xへの投稿で、自身のSpeaker Deck資料「ハーネス設計入門」を紹介しました。投稿は取得時点で多くの反応を集めています。
企業が今取り組むべきことは、より長い指示を書くことではありません。知識、実行、統制・評価の3層を整え、小さな業務で再現性を検証することです。
ハーネス設計とは何ですか？
木本氏の資料では、ハーネスを「LLMの周辺環境全体」と整理し、コンテキスト、ツール、フィードバック、実行環境、ガードレール、観測可能性、状態管理を論点に挙げています。本記事では、この整理とOpenAIの「Harness engineering」を踏まえ、企業業務における参照文書、ツール、権限、テスト、ログ、承認までを含む実務設計として扱います。
プロンプトは重要です。しかし、社内規程へアクセスできないAIに「正確に回答して」と頼んでも、根拠は増えません。更新権限を持たないAIに「データを修正して」と頼んでも実行できません。反対に、過剰な権限を渡せば誤操作の影響が大きくなります。
なぜモデル性能だけでは成果が安定しないのですか？
同じモデルでも、仕事環境が違えば結果は変わります。必要な資料を見つけられるか、操作結果を確認できるか、失敗時に安全に戻れるかが異なるためです。
OpenAIはHarness engineeringで、Codexを使った開発経験を公開しています。同社は、エージェントがUI、ログ、メトリクス、テストを読み取れる形にし、制約を文書だけでなくリンター、構造テスト、CIで機械的に強制しています。
ここで重要なのは「モデルへもっと頑張らせる」のではなく、失敗の原因を環境側で直す考え方です。根拠が足りないなら知識を整えます。操作できないなら道具を追加します。確認できないならテストやログを用意します。
一方、AnthropicはBuilding Effective AI Agentsで、まず最も単純な解決策を選ぶよう推奨しています。経路を事前定義できる業務ではワークフローが適する場合があり、モデルによる柔軟な判断や動的なツール選択が必要な場合にエージェントを検討します。
つまり、ハーネス設計は自律性を最大化する競争ではありません。必要な範囲だけ判断を任せ、残りを仕組みで固定する作業です。
企業が整えるハーネス設計の3層
本記事では、木本氏とOpenAIが示した論点を企業導入へ落とし込むため、Nexaの実務上の整理として、ハーネスを知識層、実行層、統制・評価層の3つに分けます。これは各社が定めた公式分類ではありません。
1. 知識層：正本へたどり着けるようにする
知識層は、AIが何を根拠に判断するかを定めます。社内規程、製品仕様、手順書、顧客対応基準など、承認済みの正本を決めます。
OpenAIのHarness engineeringは、AGENTS.mdを情報を詰め込む百科事典ではなく「地図」として使い、詳細はdocs/を正本にする設計を示しています。一方、2026年8月29日公開のAGENTS.md公式ガイドでは、グローバル指示とプロジェクト固有指示を階層的に結合し、読み込む指示の合計サイズは既定で32 KiBと説明しています。ルールは簡潔に保ち、整形やlintなど機械的に確認できる条件はCIへ移すよう案内しています。
企業でも同じです。すべての規程を1つの指示へ貼るのではなく、短い入口から必要な文書へ段階的に移動できる構造にします。更新日、責任者、有効範囲も記録してください。
AGENTS.mdの具体的な書き方は、AGENTS.mdとは？書き方とテンプレートで解説しています。
2. 実行層：使える道具と権限を限定する
実行層は、AIが使えるAPI、ブラウザ、データベース、ファイル、業務システムを定めます。読み取り、下書き、更新、送信、削除を同じ権限で扱わないことが重要です。
最初のPoCでは、読み取りと下書きから始めます。本番更新や社外送信、削除、決済は自動実行を避け、人の承認対象とします。将来対象にする場合も、金額上限、対象範囲、承認者、取り消し手順を先に決めます。
実行環境は業務ごとに分離します。テスト用データと本番データを混ぜず、APIキーは指示ファイルへ書きません。AIができることを増やすほど、認証情報と権限の管理が重要になります。
3. 統制・評価層：結果を検証し、止められるようにする
統制・評価層は、AIの成果を判定し、異常時に止める仕組みです。入力、実行した操作、参照した根拠、出力、承認結果を追跡できるようにします。
評価は「それらしい回答」ではなく、観察可能な条件で行います。たとえば、必須項目の欠落、根拠URLの有無、計算結果、禁止表現、承認差し戻し、再作業の発生を確認します。
失敗例は次のテストへ追加します。文書更新で回答が変わるか、権限がない操作を拒否できるか、外部文書の不正な指示を無視できるかも検証対象です。
AIガバナンスの全体像は、AIガバナンスとは？中小企業が90日で構築する実践ガイドも参考にしてください。
プロンプト、AGENTS.md、ハーネスの違い
3つは競合する手段ではなく、範囲が異なります。
| 項目 | プロンプト | AGENTS.md | ハーネス |
|---|---|---|---|
| 主な役割 | 個別タスクや共通方針を伝える | リポジトリ内の作業規則を渡す | AIが働く環境全体を構成する |
| 対象 | 会話、API呼び出し | 主にコーディングエージェント | 開発、営業、管理など業務全般 |
| 含むもの | 役割、目的、制約、形式 | コマンド、規約、参照先 | 知識、ツール、権限、テスト、ログ、承認 |
| 強制力 | モデルが解釈する | モデルが解釈する | 権限やCIで技術的に制御できる |
| 主な弱点 | 長文化、競合、解釈の揺れ | 陳腐化、上限、配置ミス | 構築と保守に運用コストがかかる |
システムプロンプトはハーネスの一部です。役割や出力形式を伝えられますが、アクセス権を遮断したり、誤送信を取り消したりはできません。詳しくはシステムプロンプトとは？書き方と実例、安全な運用法をご覧ください。
企業が30日で試す5ステップ
大規模な基盤を先に作る必要はありません。以下は、Nexaが提案する30日PoC（概念実証）の進め方です。期間は公式資料が指定したものではなく、対象業務を1つに絞って最小構成を検証するための目安です。
ステップ1：対象業務を1つに絞る
問い合わせ回答の下書き、定例レポート作成、社内規程の検索など、完了条件を観察できる業務を選びます。採用、法務、与信、決済など、誤りが人の権利や財産へ大きく影響する業務は、初回PoCの対象から外すのが無難です。
ステップ2：正本と入力境界を決める
AIが参照してよい文書と、入力してはいけない情報を定義します。文書ごとに更新責任者と有効期限を持たせます。外部Webページや受信メールは、命令ではなく未信頼データとして扱います。
ステップ3：道具を最小権限で接続する
最初は読み取り専用にします。成果が安定したら下書き保存を許可し、本番反映は承認付きにします。利用するAPI、対象フォルダ、実行時間、回数上限を明文化します。
ステップ4：テストと承認を組み込む
正常例だけでなく、資料不足、矛盾、権限外、禁止データを含む異常例も用意します。外部送信、本番更新、削除など、戻しにくい操作の直前に人の承認を置きます。
ステップ5：KPIを測り、失敗を環境へ戻す
完了率、再作業率、承認差し戻し、処理時間、API費用を記録します。失敗原因を知識、ツール、検証、権限のどこにあるか分類し、次の改善へつなげます。
失敗したときは何を見直しますか？
失敗時は指示を長くする前に、原因を環境側で分類します。
| 原因 | 見直すもの |
|---|---|
| 知識不足 | 正本、文書構造、参照経路 |
| ツール不足 | API、検索、確認手段 |
| 検証不足 | テスト、入力検査、ログ |
| 権限設計 | 読み取り・更新・送信権限、承認 |
文章で繰り返し守らせている条件は、可能であれば権限制御、リンター、テスト、CIへ移します。
導入時に注意すべき5つの点
ハーネスを整えても、AIの出力や操作が完全に正しくなるわけではありません。企業導入では次を守ります。
- 秘密情報を指示へ書かない：APIキーはシークレット管理を使い、個人情報はアクセス制御された承認済みデータストアで扱う
- 最小権限にする：読み取りと更新、下書きと送信を分離する
- 人の責任を残す：法務、財務、人事など重大判断は担当者が確認する
- ログを管理する：保存期間、閲覧者、削除手順を決める
- 費用上限を設ける：実行時間、回数、API予算を監視する
自律性が高いほど優れているとは限りません。予測可能な業務はワークフローで固定し、例外判断が必要な部分だけAIへ任せる方が、安全性と費用を管理しやすくなります。
AIエージェントのハーネス設計でよくある質問
Q. エンジニア以外の業務でもハーネス設計は必要ですか？
必要です。営業メールの下書きなら、参照できる顧客情報、禁止表現、承認者、送信権限、記録方法がハーネスに当たります。コード開発に限らず、AIが情報や道具へ接続する業務で必要になります。
Q. AGENTS.mdを用意すれば十分ですか？
十分ではありません。AGENTS.mdは作業規則や参照先を伝える重要な入口ですが、API権限、実行環境、テスト、ログ、承認までは単独で制御できません。機械判定できる条件はCIや権限設定へ移します。
Q. どの業務から始めるべきですか？
入力と完了条件が明確で、誤りを人が確認できる業務から始めます。社内検索、定例レポート、回答下書きなどが候補です。採用判断、契約判断、送金など、取り消しにくい業務は初期PoCに向きません。
Q. 何をKPIにすればよいですか？
完了率だけでなく、再作業率、承認差し戻し、根拠の欠落、処理時間、API費用、重大事故件数を見ます。速さだけを追うと、確認作業やリスクが別工程へ移る可能性があります。
まとめ
AIエージェントの成果は、モデルやプロンプトだけでは決まりません。正しい情報へたどり着ける知識層、必要な道具を最小権限で使う実行層、結果を検証して止められる統制・評価層が必要です。
まずは対象業務を1つ選び、AIが参照する情報、使えるツール、承認が必要な操作を書き出してください。30日PoCで完了率と再作業を測り、失敗を指示の追加ではなく環境改善へ戻すことが第一歩です。
株式会社Nexaでは、業務選定、権限設計、評価指標を含むAI導入をご支援しています。自社でどこから始めるべきか整理したい方は、AI顧問サービスのご相談はこちらからお問い合わせください。
一次情報
- 木本一博氏のX投稿（2026年8月30日）
- 木本一博氏「ハーネス設計入門」（Speaker Deck）
- OpenAI「Harness engineering」
- OpenAI Developers「Custom instructions with AGENTS.md」
- Anthropic「Building Effective AI Agents」
