組織が統制するのはモデルではなく「ハーネス」— 豪ASDの公表文書を読む

Claude Code や Codex CLI を業務で試すとき、話題はどのモデルを使うか、どのモデルが賢いかに寄りがちです。一方で、実際に社内のファイルを読み書きし、コマンドを実行し、外部のサービスへ接続しているのは、モデルそのものではありません。モデルの出力を受け取って、ツールを呼び、権限を確かめ、結果を記録する周辺のソフトウェアです。

オーストラリア信号局（ASD）のサイバーセキュリティセンターは、2026年9月11日に公表した文書「Agentic AI harnesses」で、この周辺部分を「ハーネス（harness）」と呼び、組織がもっとも直接に統制できる部分として整理しました。副題は「The layer above the model」、つまりモデルの上にある層です。本記事では、ASDの定義にならって、AIエージェントのうちモデル以外の部分をまとめて「ハーネス」と呼びます。

英国NCSCが示した自律性と統制の考え方はNCSCのagentic AIに関するブログを読んだ記事で扱いました。今回のASDの文書は、統制を「どこに」かけるのかを、部品の単位で示している点が異なります。

ASDは誰に向けて何を公表したのか

文書の想定読者は、エージェント型AIを導入している、または導入を検討している組織の経営層、最高情報セキュリティ責任者（CISO）、IT部門の責任者です。ASDはすでに「Careful adoption of agentic AI services」という、エージェント型AI全般のセキュリティ上の考慮事項をまとめた指針を出しており、今回の文書はその補足として、ハーネスに焦点を絞ったものと位置づけられています。

文書の要点（Key takeaways）は3つです。組織が統制するのはLLMではなくハーネスであること、長期的な価値・統治・投資が積み上がるのはハーネスであること、そしてハーネスとその周辺の技術的な環境がセキュリティとリスク管理の主な対象であることです。

ハーネスとは何か？

ハーネスとは、LLMを外部のツール、データ、記憶、作業の手順とつなぎ、エージェントとして動かすための、モデル以外のソフトウェアの層です。ASDは、LLMを脳にたとえるなら、ハーネスは体にあたると説明しています。ハーネスはモデルに渡す情報を選び、モデルが提案した操作を実行するかどうかを権限や承認の仕組みで決め、その経過を記録します。組織の側から見れば、エージェントの挙動を左右する設定の多くは、モデルではなくハーネスにあります。

ASDは両者の違いを表で比べています。たとえばLLMは文字列を出力するだけですが、ハーネスはツールを実行し、ファイルを編集し、コマンドを動かし、APIを呼び出します。統制の手段についても、LLMの側は出力を作るだけで結果の操作を直接には制御しないのに対し、ハーネスの側には「Permissions, sandboxes, approval gates, hooks, policies」、つまり権限、サンドボックス、承認の関門、フック、ポリシーが並びます。

ASDが挙げる例はわかりやすいものです。モデルがファイル削除のコマンドを提案しても、それが実行されるかどうかはハーネスとその制御で決まります。エージェントが想定外の動きをしたとき、プロンプトの手直しだけで済ませず、モデルの判断とハーネスの設定の両方を調べるよう求めているのはこのためです。

なぜ統制の対象はモデルではなくハーネスなのか

ASDの説明には、理由が2つあります。

1つ目は、モデルは入れ替わるという点です。1つのハーネスは複数のLLMと組み合わせて動かせ、よく設計されたハーネスはモデルの更新を何度もまたいで使われます。比較表でも、LLMは「差し替えられる部品」、ハーネスは「The durable architecture that outlives any single model」、つまり個々のモデルより長く残る構造とされています。モデルごとに統制を作り直すより、長く残る側に統制を置くほうが筋が通ります。

2つ目は、モデルの中だけでは防げない弱点があるという点です。LLMは指示と情報を同じ文脈として受け取るため、Webページやメール、文書、コードのコメントに紛れた文言を指示として読んでしまうことがあります。ASDはこのプロンプトインジェクションについて、完全に信頼できる技術的な対策は現時点で存在しないとしたうえで、対策はハーネスの側で、エージェントが何にアクセスでき、どの操作を許されるかを制御する形で講じる必要があると書いています。この前提に立った実行環境の考え方はプロンプトインジェクションを前提にしたAI実行環境の考え方で整理しています。

ただし、ハーネスを使えば安全になるわけではありません。ASDは「No harness is inherently secure.」と書き、最小権限、IDとアクセス管理、監視、人による監督、インシデント対応との連携といった従来のセキュリティ実務を、ハーネスに当てはめるよう求めています。

11の構成要素が、組織の「設定面」になる

ASDはハーネスを11の構成要素に分けています。

1. 利用者インターフェース：エージェントの動きがどこまで見え、承認や介入をどう行えるか
2. プロンプトとポリシーの層：システムへの指示、業務ルール、組織のポリシー
3. コンテキスト管理：モデルに渡す情報の選択。機密情報を渡してしまうことも、必要な情報を落とすこともある
4. モデルとの接続：組織が承認したLLMサービスとのやり取り
5. ツールの登録簿：使えるツールとその機能
6. 権限の仕組み：影響の大きい操作の承認と許可
7. 実行環境：操作がどこで実行されるか、どこまで許されるか
8. コネクタの層：RAGのデータやMCP対応のツールを含む、外部のデータ・サービス・社内システムとの接続
9. 記憶とセッションの保存：セッションをまたいで残る情報。機密や古い情報、改ざんされた内容が残ることもある
10. 監査と可観測性：監視、見直し、インシデント対応のための記録
11. 更新とサプライチェーンの経路：新しい機能と、それに伴う供給網のリスクが入ってくる経路

ASDは、これらの構成要素を「組織の設定面（configuration surface）」と呼んでいます。どのツールを見せるか、何を許すか、どの承認を必須にするか、どのコネクタをつなぐか。エージェント型AIに対する実際の統制の多くは、この一覧の中の設定として現れる、という整理です。プロンプト、スキル、MCPの管理は組織のAIナレッジを共有する記事、記録の層の分け方はAIエージェント実行環境の監査ログで詳しく扱っています。

ASDが挙げる実践のうち、実行環境に関わるもの

文書の「Good practice」には、ハーネスの運用についての具体的な項目が並んでいます。実行環境の置き方に関わるものを抜き出すと、次のとおりです。

• 組織が管理し、堅牢化した環境で動かし、その作業に必要なツールと権限だけを持たせる。本番システム、機密データ、ネットワークサービスへのアクセスは制限する。
• プロンプト、応答、ツールの呼び出し、承認、操作、セキュリティ上の事象、設定の変更を記録する。記録は保護・保持し、独立した監視の対象にする。
• 組織の単位で、ハーネスが毎回読み込む必須のルールファイルを持つ。守るべき基準、触れてはならない領域、ビルドやテストの手順を書いておくと、ハーネスの振る舞いが揃い、見直しもしやすくなる。
• 調べものなどの一部の作業は、必要なツール・権限・情報だけを与えたサブエージェントに切り出す。
• APIの利用量を監視する。エージェントの作業はチャットの1回のやり取りよりはるかに多くの資源を消費するため、想定外の消費は、悪用、侵害、止まらないループなどの手がかりになる。

どれも、ハーネスが「どこに1つあるか」を前提にした項目です。組織の単位のルールファイルも、独立した記録の監視も、ハーネスが組織の管理する場所にあってはじめて、全員に同じ条件で当てはめられます。

社員PCごとのハーネスで起きること

Claude Code や Codex CLI を社員が各自のPCに入れて使う場合、ハーネスはPCの数だけ存在することになります。11の構成要素、つまり設定面も、その数だけ分かれます。どのMCPサーバーをつないだか、どのファイルまで読ませているか、承認をどこで省略しているか、記録がどこに残っているかは、それぞれのPCの設定次第です。

ASDの整理に従えば、統制をかける先はハーネスです。そのハーネスが社員ごとに分かれていると、組織が確かめられるのは「ルールを配った」ところまでになりやすく、実際の設定がルールどおりかどうかは、1台ずつ見なければわかりません。社員PCで動かす場合の具体的なリスクはAIコーディングエージェントを社員PCで動かすリスクと代替策でまとめています。

Hoko（矛）は、AIツール、ローカルLLM、MCP、APIキー、実行ログを社員PCに散らばらせず、社員ごとのAIワークスペースとして組織の管理する場所に集める実行基盤です。ASDの言葉を借りれば、ハーネスとその設定面を、組織が見渡せる位置に置き直す考え方です。

経営層は何を確かめればよいか

ASDは、取締役や経営幹部がエージェント型AIの実装の細部まで理解する必要はないとしたうえで、ハーネス、その接続先、統制の仕組みが適切に設計されているかを確かめるための問いを7つ挙げています。要旨は次のとおりです。

1. このエージェント型AIで達成したい業務上の成果は何か。なぜエージェント型である必要があるのか。
2. エージェントはどのデータ、システム、ツールにアクセスできるか。最小権限は守られているか。
3. エージェントはどの操作を実行でき、そのうちどれに人の承認が必要か。
4. プロンプトインジェクションやデータの汚染など、AI特有の攻撃をどう抑えているか。
5. 重要な判断、ツールの呼び出し、操作をすべて監視・監査できるか。
6. 価値を生んでいるか、安全に動いているか、許容できるリスクの範囲に収まっているかを、どう見分けるか。
7. ハーネスが侵害、誤設定、操作されたとき、最悪の結果は何で、どの統制がそれを防ぐか、または抑えるか。

2と3と5は、ハーネスの設定面を見なければ答えられない問いです。社員PCごとにハーネスが分かれている状態では、この3つの答えも社員の数だけ存在することになります。

よくある質問

ハーネスとは、特定の製品の名前ですか？

製品名ではありません。ASDの文書では、LLMを外部のツールやデータ、記憶、作業手順とつなぎ、権限を確かめて操作を実行し、記録を残す、モデル以外のソフトウェアの層を指す言葉として使われています。組織が自ら開発する場合も、商用の製品やサービスの一部として提供される場合もあるとされています。

性能のよいモデルを選べば、ハーネスの統制は軽くてよいですか？

ASDは、モデルに組み込まれた安全の仕組みを、ハーネスで強制する統制の代わりにしないよう求めています。プロンプトインジェクションには完全に信頼できる技術的な対策がまだないとしており、アクセスできる範囲と許される操作をハーネスの側で制御することを前提にしています。

まず何から見直せばよいですか？

ASDの11の構成要素を一覧にし、自社でそれぞれの設定を誰がどこで決めているかを書き出すことが出発点になります。そのうえで、経営層向けの7つの問いのうち、アクセスできる範囲、承認が必要な操作、監視と監査の3つに答えられるかを確かめると、統制が及んでいない部分が見えやすくなります。ASDは、リスクの低い用途から始め、統制が整うのに合わせて展開を広げる段階的な導入を勧めています。

まとめ

ASDが2026年9月11日に公表した「Agentic AI harnesses」は、AIエージェントのうちモデル以外の部分を「ハーネス」と呼び、組織が統制できるのはモデルではなくハーネスだと整理しました。モデルは入れ替わる部品であり、プロンプトインジェクションのようにモデルの中では防げない弱点もあるため、統制はハーネスに置くことになります。

ハーネスの11の構成要素は、そのまま組織の設定面です。社員PCごとにハーネスを持たせると設定面も分かれ、経営層向けの問いにまとめて答えることが難しくなります。モデル選びと同じ重さで、ハーネスをどこに置き、誰が設定を管理するかを決めることが、エージェント型AIを組織で運用するための前提になります。組織の側でAIワークスペースを用意する設計はAIエージェントのためのワークスペース設計で整理しています。

出典

• Australian Signals Directorate（ASD）Australian Cyber Security Centre「Agentic AI harnesses — The layer above the model」（2026年9月11日公開） 本文