Harness Engineeringと責任OS――AIを「働かせる」工学と、責任ある業務実行をつなぐ工学

kanna qed
2 日前
読了時間: 10分

Agentが「できる」ことと、企業が「実行してよい」ことは同じではない

AIエージェントの進化によって、AI開発の焦点はモデルの性能だけではなく、その「外側」へ広がり始めている。

AIにどのような環境を与えるのか。

どのようなツールを使わせるのか。

どのように状態を維持し、評価し、フィードバックを返し、必要な境界を守らせるのか。

2026年2月11日、OpenAIはこうした問題をHarness Engineeringという言葉で論じた。

その記事には、象徴的な一文がある。

“Humans steer. Agents execute.”

OpenAIは、人間の主要な仕事がコードを直接書くことから、エージェントが信頼性高く仕事を進められる環境を設計し、意図を明確化し、フィードバックループを構築することへ変化したと説明している。

Anthropicも2026年1月、agent harnessを、モデルがagentとして行動することを可能にするシステムとして説明した。入力の処理、tool callのオーケストレーション、結果の返却などを含み、agentを評価するときにはharnessとmodelが組み合わされたシステムを評価するとしている。

AIを理解する単位が、モデル単体から、モデルを取り巻くシステムへ広がっている。

しかしAIが「行動できるもの」になったことで、もう一つの問いが前面に出てくる。

AIがその行為を実行できることと、企業がその行為を正式な業務行為として実行してよいことは、同じなのだろうか。

私たちは、ここにHarness Engineeringとは区別して考えるべき工学的な境界があると考えている。

それが、GhostDrift数理研究所が取り組む**責任OS（Responsibility OS）**である。

1．Harness Engineeringは、モデルの「外側」を工学する

従来の生成AIでは、「モデルに何を入力し、どのような回答を得るか」が大きな関心事だった。

AIエージェントでは事情が変わる。

Agentはツールを利用し、環境と相互作用し、状態を維持しながら複数の処理を連続して進める。

OpenAIが2026年2月4日に公開したCodex harnessの技術解説では、ユーザー、モデル、ツールの相互作用を調整するagent loopを中核としながら、その周囲にthreadの永続性、設定・認証、sandbox内でのtool execution、MCP等の拡張機構などが構成されている。必要な場合にはagent側からapprovalを要求し、クライアントが応答するまで処理を停止する仕組みも存在する。

つまり、現代のAIエージェントは、

Model

だけではなく、

Model + Tools + State + Environment + Feedback + Constraints

というシステムとして考えなければならない。

OpenAIのHarness Engineeringの記事が示唆的なのは、エージェントの自由度を単純に高めればよいとはしていない点である。

実際には、アーキテクチャ上の境界や依存関係を定め、custom linterやstructural testによって機械的に制約している。そのうえで、境界の内側ではagentに大きな自由度を与えている。OpenAI自身も、境界を中央で強制しつつ、その内部ではagentに相当な自由を認める設計を説明している。

Anthropicも2026年3月、long-running autonomous software engineeringにおいて、harness designがagentic codingの性能に大きく影響すると報告している。

Harness Engineeringは、単なるPrompt Engineeringの言い換えではない。

AIが継続的に仕事を遂行できる環境そのものを工学する考え方として捉える方が適切だろう。

2．Harnessにも、すでに安全・制御の仕組みはある

ここは重要な点である。

Harness Engineeringを「AIを動かす技術」、責任OSを「それを安全にする技術」と単純に分けるのは正確ではない。

前述したCodex harnessには、authentication、sandbox、policy model、approvalといった仕組みがすでに存在する。

OpenAIのHarness Engineeringでも、境界、correctness、reproducibilityを重視し、それらを機械的に強制する設計が示されている。

したがって、

Harness Engineering＝自律性

Responsibility OS＝安全性

ではない。

違いは、どちらが安全かではなく、

何を問い、どの境界を扱うか

にある。

3．「実行できる」と「企業として実行してよい」は別の問いである

例えば、AIエージェントが何らかの業務操作を技術的に実行できるとする。

必要なツールへアクセスできる。

認証も成立している。

Harness上のpolicyにも反していない。

Agent自身もタスクを正常に完了できる。

それでも企業活動では、別の問いが残る。

その行為を、この組織が正式な業務行為として採用し、実行してよいのか。

これは、ツールへのアクセス権だけでは決まらない。

技術的なpermissionと、組織としてのauthorityは同じではない。

モデルがoutputを生成したことと、企業がそのoutputに基づいて意思決定することも同じではない。

Agentがtaskをcompleteしたことと、その結果を組織が正式なactionとしてacceptすることも同じではない。

この違いを短く表すなら、

Tool Permission is not Organizational Authority.

である。

責任OSが扱おうとしているのは、まさにこの境界である。

Harnessを置き換えるのではない。

Agentの推論を置き換えるものでもない。

AIの行為を、組織のルールや責任構造、判断根拠、実際の業務状況と接続し、「責任ある業務実行」として扱える状態にあるかを確かめる。

そのための技術レイヤーとして、私たちは責任OSを位置づけている。

4．NISTも、AIの問題をモデル性能だけでは捉えていない

この問題を考えるうえで参考になるのが、米国国立標準技術研究所（NIST）のAI Risk Management Framework（AI RMF）である。

まず明確にしておきたいのは、AI RMFは法令ではないということである。

NIST自身が、AI RMFを**voluntary（任意利用）**で、業種やユースケースに依存しないフレームワークとして位置づけている。

そのうえでAI RMF Coreは、AIリスクを扱う組織のaccountability structureについて明確な考え方を示している。

Govern 2では、適切なチームや個人がAIリスクの把握・測定・管理について権限を与えられ、責任を持ち、訓練されるためのaccountability structureを置く。

さらにGovern 2.3では、

“Executive leadership of the organization takes responsibility for decisions about risks associated with AI system development and deployment.”

と明記されている。

つまり、AIの技術的性能だけでなく、

誰がそのリスク判断に責任を持つのか

が組織設計の問題として置かれている。

さらにAI RMFのMap機能では、AIシステムをdesign、develop、deployするかどうかについて、組織がinitial go/no-go decisionを行うために十分な文脈的知識を得ることが想定されている。

NIST Playbookも、AI RMF Coreを実装するためのSuggested Actionsを示している。ただしPlaybook自身が、これは完全なチェックリストではなく、提案は任意で利用するものだと明記している。

ここから重要な構造が見える。

AIが技術的に何をできるかという問題と、

組織がリスクを引き受けてgoと判断すること

は、同じ問題ではない。

5．EU AI Actでも、AIのoutputと現実のactionは同一視されていない

法制度側からも同じ境界を見ることができる。

本稿では、EUR-Lexに掲載されている**2026年7月27日時点のConsolidated Text（統合版）**を参照する。なおEUR-Lex自身が、この統合文書はdocumentation toolであり、法的効力を持つ真正な本文はOfficial Journalに掲載された各法令であると注意書きを付している。

EU AI ActのArticle 13では、高リスクAIシステムについて、deployerがシステムのoutputを解釈し、適切に利用できるだけの透明性を確保することが定められている。

Article 14のhuman oversightでは、監督を担当する者が、高リスクAIシステムの能力と限界を理解し、動作を監視し、そのoutputを正しく解釈できることが想定されている。

さらに、状況に応じてAIシステムを使用しない、outputを無視する、overrideまたはreverseする、あるいはシステムへ介入し安全な状態で停止するといったことができるようにすることも規定されている。

Article 26では、高リスクAIシステムのdeployerがhuman oversightを担当する自然人に必要なcompetence, training and authorityを持たせること、システムの運用をmonitorすること、一定のリスクが認められる場合には利用をsuspendすることなどが定められている。

もちろん、これは、

「EU AI Actが責任OSを要求している」

という意味ではない。

責任OSはEU AI Act上の概念ではない。

しかし、高リスクAIにおいて、

AIがoutputを出したこと

と、

組織がそのoutputに基づいて現実のactionを取ること

が同一の問題として扱われていないことは重要である。

間には、監督、解釈、authority、monitoring、停止といった問題が存在する。

6．日本でもAIエージェント固有の「観測と制御」が論点になった

日本でも、AIエージェントへの評価の視点は変化している。

AIセーフティ・インスティテュート（AISI）は2026年7月7日、「AIセーフティに関する評価観点ガイド（第1.20版）」を公表した。

AISIは、AIエージェントシステムが自律的に行動し、外部システムや物理環境へ影響を与え得ることから、従来のLLMシステムでは十分に想定されていなかったリスクへの対応が求められると説明している。

そして今回、AIエージェントシステム特有の評価観点として**「観測と制御」**を設け、「自律的な挙動」と「外部環境との相互作用」に関する評価項目を追加した。

AISIの評価観点ガイドも法律ではない。

しかし、その問題設定は重要である。

AIが「回答するもの」から「環境へ作用するもの」へ変われば、評価すべき対象も、

何を答えたか

だけでは足りない。

何をしようとしているのか。何をしたのか。その挙動を観測し、必要なら制御できるのか。

そこまで広がる。

7．Harness Engineeringと責任OSは、競合する概念ではない

ここまで挙げたOpenAI、Anthropic、NIST、EU、AISIが、同じ概念を提唱しているわけではない。

目的も対象も法的位置づけも異なる。

これらを「世界が責任OSを求めている」という話にまとめるのは適切ではない。

しかし、一次文献を並べることで一つの変化は見えてくる。

OpenAIやAnthropicが示しているのは、AIエージェントの能力を実際の仕事へ接続するためには、モデルだけでなくHarnessを工学する必要があるということである。

一方、AIを実際の組織活動へ接続する場面では、NIST、EU AI Act、AISIがそれぞれ異なる目的から、accountability、go/no-go、human oversight、authority、monitoring、controlといった論点を扱っている。

したがって、ここで重要なのは、

「Harnessには何かが欠けている」

と主張することではない。

そうではなく、

Harnessをどう設計するかという問いと、組織がagentの行為を正式な業務実行として受け入れてよいかという問いは、分析上区別できる

ということである。

私たちは後者を、責任OSの工学領域として捉えている。

8．Agentの自律性を奪うのではなく、責任の境界をつくる

AIエージェントの責任問題に対して、

「すべて最後は人間に確認させればよい」

とするのは、一つの解ではある。

しかし、それだけではAIエージェントによって実現しようとしている自律性や速度の多くを失う。

必要なのは、agentを弱くすることではない。

自律性と責任を混同しないことである。

Harnessの中では、高度なagentが柔軟に考え、ツールを利用し、仕事を進めることができる。

一方、その成果を現実の企業活動へ接続する境界では、それを組織として受け入れてよいのかという別の問いを置く。

私たちはこの考え方を、

Autonomy inside. Accountability at the boundary.

と表現している。

これはHarness Engineeringへの反論ではない。

むしろ、強力なagentをより重要な業務へ接続していくための補完的な考え方である。

9．「働くAI」の次に来る問い

生成AIの中心的な問いは、

AIは何を答えられるか

だった。

AIエージェントでは、

AIは何を実行できるか

という問いが大きくなった。

Harness Engineeringは、その変化を象徴する重要な工学的潮流である。

そしてAIが企業システムや現実世界へ深く接続されるほど、その先でもう一つの問いが大きくなる。

その行為を、組織として実行してよいのか。

GhostDrift数理研究所では現在、責任OSの考え方を個別の業務ユースケースへ適用し、PoC・実装検証を進めている。

現時点で責任OSを完成済みの一般基盤として主張するものではない。

一方で、AIエージェントの自律性が高まるほど、

「何ができるか」と「何を実行してよいか」を区別する

ことの重要性は高まると考えている。

Harness Engineeringと責任OSの関係を、一文で表すならこうなる。

Harness Engineering makes agents capable of acting.Responsibility OS makes actions eligible for accountable execution.

AIを「働かせる」工学が進歩したからこそ、責任は抽象的な理念ではなく、実装すべきシステム境界の問題として現れ始めている。

そこを、私たちは責任OSの領域として考えている。

主な一次文献

OpenAI, “Harness engineering: leveraging Codex in an agent-first world,” 2026年2月11日。
OpenAI, “Unlocking the Codex harness: how we built the App Server,” 2026年2月4日。
OpenAI, “Unrolling the Codex agent loop,” 2026年1月23日。
Anthropic, “Demystifying evals for AI agents,” 2026年1月9日。
Anthropic, “Harness design for long-running application development,” 2026年3月24日。
NIST, Artificial Intelligence Risk Management Framework (AI RMF 1.0) / AI RMF Playbook。AI RMFはvoluntary frameworkであり、PlaybookもSuggested Actionsとして提供されている。
European Union, Regulation (EU) 2024/1689, EUR-Lex Consolidated Text, 2026年7月27日時点。Article 13、14、26等を参照。
AIセーフティ・インスティテュート（AISI）, 「AIセーフティに関する評価観点ガイド（第1.20版）」2026年7月7日公表。