AIエージェントを試して、仕事は終わった。それでも、使い続けるかどうかは、仕事が終わったことだけでは決まりません。費用がいくらかかったか。何に触ったか。途中で何回聞かれたか。聞かれたのに気づかなかったことはないか。仕事の出来とは別に、こうした動作の条件を評価する必要があります。

2026年9月18日にarXivに出た論文「Value-Sensitive Delegation in Everyday AI Agent Use: Evidence from OpenClaw」は、この評価の向きに名前を付けています。この記事は、その論文の主な結果を読み、会社がエージェントを入れる前に自社で書いておく4つの条件に落とします。読者は、社内でエージェントの試用を始めた、または始めようとしている、情報システムの担当者と業務の責任者です。

結論を先に書きます。

  1. 利用者が気にしている価値は、エージェントの出力より、実行の周りに置く動作条件に結び付いていました。 論文は、73,093件の一人称のReddit投稿から21の価値を取り出し、6つのグループにまとめています。エージェントの各側面が投稿全体に占める割合を基準にすると、価値は、費用、触れる範囲、確認のしやすさ、使える人の範囲といった、どういう条件で動いたかの話に目立って結び付いていました
  2. 成果を語る投稿では価値が満たされる傾向があり、監督を語る投稿では満たされない傾向がありました。 6グループのうち5つで、成果についての投稿は満たされている側に寄り、監督についての投稿は6グループすべてで満たされていない側に寄りました
  3. 会社がエージェントを入れる前に書くのは、費用の上限、触れてよい範囲、承認の持続、完了の条件の4つです。 論文の設計への示唆を、当社が会社向けに置き直したものです。4つとも、道具の設定ではなく、会社が決めることです

論文が何をしたか

著者はRenkai Ma氏ら6名で、2026年9月18日にarXivに投稿された版を読みました。査読を経た論文かどうかは、arXivのページには書かれていません。確認日は2026年10月28日です。

対象はOpenClawというエージェントの利用者です。論文の説明では、OpenClawは利用者自身のコンピュータで動き、WhatsAppなどのチャットアプリから指示するオープンソースのエージェントで、通常の対話型のアシスタントと違い、実行の途中で利用者が確認できる機会が少なく、その間はエージェントが一連の作業を進めます。

方法は、Value Sensitive Designという設計の考え方を使い、OpenClawの利用について一人称で書かれたReddit投稿73,093件を、LLMの支援を受けて分類したものです。各投稿について、どの人間の価値に触れているか、エージェントのどの側面の話か、その価値が満たされているかを付け、利用者に起きた結果を読み取れる投稿には、その結果も付けています。

価値は21あり、6つのグループにまとまりました。グループの名前は論文のものを、当社が日本語にしています。

グループ（原文） 当社の読み方 含まれる価値
Dependable Operation 頼れる動作 信頼できること、信頼、直せること
Autonomous Operation 利用者の自律性を支える動作 利用者の自己決定、人の福利、落ち着き
Affordable Operation 払える費用での動作 費用の妥当さ、資源の節度、環境の持続性
Bounded Reach 触れる範囲の限定 セキュリティ、プライバシー、アイデンティティ、所有権、データの主権、文脈に応じた情報の扱いのルールを守ること
Reviewability 確認できること 透明性、人による意味のあるコントロール、説明責任、説明を理解したうえでの同意
Equitable Access 公平に使えること 誰でも使えること、偏りのなさ

論文は、Friedman氏らの価値の一覧を出発点に、先行研究も参照して分類の項目を足しています。信頼できること、直せること、費用の妥当さ、資源の節度、セキュリティ、データの主権、文脈に応じた情報の扱い、透明性、人による意味のあるコントロールが、この研究で足された側です。6グループの分け方は著者らの整理で、測定モデルとして検証したものではない、と限界に書いています。

価値は、出力ではなく動作条件に集まっていた

論文の主な結果は3つです。

1つ目。価値は、エージェントの出力より、利用者が1回の実行の周りに置く動作条件に結び付いていました。 費用の上限をどう決めたか、どのファイルやアカウントに触れさせるか、どう導入したか、承認をどこに置いたか、何を記録に残すか。エージェントの各側面が投稿全体に占める割合を基準にすると、価値が語られる場面は、エージェントが作った成果物より、こうした条件の話に目立って結び付いていました。

2つ目。成果を語る投稿では価値が満たされる傾向があり、監督を語る投稿では満たされない傾向がありました。 6グループのうち5つで、利用者がエージェントの成果を語る投稿は、価値が満たされている側に寄りました。一方、利用者がエージェントの監督を語る投稿は、6グループすべてで、満たされていない側に寄りました。論文はこの形を、value-sensitive delegation、価値に敏感な委任、と名付けています。

3つ目。論文の結論は、エージェントが何を達成するかだけでなく、費用、アクセス、監督を含めて、利用者が委任の周りに置く条件に注意を向ける必要がある、というものです。

本文には、利用者の投稿の例も出てきます。頼んでいない定期的な確認にも料金がかかっていたことに後から気づいた人。画面の無いサーバーで動かしていて、承認を求める表示が出ず、ブラウザを開いたまま1段ずつ手で承認した人。一度承認した操作を何度も聞かれて、作業が止まった人。成果の話ではなく、条件の話です。

1回の実行の前と中と後で、利用者が置く条件と、エージェントが動く場所と、記録が残る場所を3つのレーンで示した図。価値が語られるのは、前に置く条件と、中に出る承認の求めと、後に読む記録

当社は、論文の議論を、実行の前、中、後に分けて読みました。前に置くのは、費用の上限、触れてよい範囲、完了の条件、承認をどこに置くか。中に出るのは、承認を求める表示。後に読むのは、何に触れ、いくら使ったかの記録。論文は、前に置く条件と後に読む記録は、見張り続けなくても管理できる仕組みである一方、前に置く条件は実行中に起きたことに応じては変わらず、後に読む記録は起きたことしか伝えない、と書いています。中に出る承認の求めは、一度決めたことを再び聞いたり、利用者に見えない場所に出たりして、負担を生みます。論文は、この3つの役割と、実行中の承認の求めで生じる負担を分けて論じています。

会社が入れる前に書く4つの条件

論文の設計への示唆は、エージェントを作る側に向けて書かれています。使える費用の上限をエージェントが超えられない形にする。触れる範囲を狭い初期設定にして利用者が広げる。承認を一度与えたら範囲内で持続させ、利用者が普段使う経路に届ける。利用者が実行の前に完了のテストを用意し、実行したエージェント以外が確かめ、再試行と検証の方針も先に決められるようにする。費用の上限、狭い範囲、持続する承認、完了のテストをエージェントに最初から組み込み、コマンドラインなしで調整できるようにする。

当社は、これを使う会社の側に置き直します。道具がこの形になっているかどうかにかかわらず、会社が先に書いておく条件は4つです。

エージェントに仕事を任せる前に会社が書く4つの条件を4段で示した図。費用の上限、触れてよい範囲、承認の持続、完了の条件の順に積む

1. 費用の上限。 1つのエージェントに、月にいくらまで使ってよいか。上限を超えたら止まるのか、通知が来るだけなのか。当社はAIの費用を誰が見るかの記事で、上限を決める人、設定する人、用途を書く人の3つの役を書きました。上限を文章で決めるだけでは、支出には気づけません。上限に加えて、利用額の計測、通知、超えたときの停止を、道具の側で設定します。論文の利用者が後から気づいた定期的な確認の料金は、この3つがあって初めて見えます。

2. 触れてよい範囲。 どのファイル、どのアカウント、どの社内システムに触れてよいか。論文は、初期設定の範囲が広すぎることを、実行の記録からは見えにくい問題として挙げています。当社はサンドボックスの記事とExecution Containersの記事で、どこで動かし、何に触れさせるかを書きました。範囲を決めるのは、その業務のデータの責任者です。

3. 承認の持続。 何を一度承認したら、次からは聞かないか。何は毎回聞くか。承認の求めは、利用者が普段見ている場所に届くか。論文の利用者は、一度決めたことを何度も聞かれて止まったり、見えない場所に出た承認に気づかなかったりしています。当社はhookの記事で、毎回聞く操作と、聞かずに止める操作を、設定として書く形を書きました。

4. 完了の条件。 何ができたら終わりか、それを誰がどう確かめるか。論文は、利用者が実行の前に完了のテストを用意し、実行したエージェント以外が確かめ、再試行と検証の方針も先に決められるようにすべきだ、としています。本文には、失敗を知らせずに不完全な結果を置いて先に進むモデルに対して、利用者が自分で検証を引き受けるようになった例があります。完了の条件と確かめ方は、その業務を知っている人が書きます。

4つとも、道具の設定画面に書く前に、会社が文章で決めることです。決める人は、費用は経営、範囲はデータの責任者、承認と完了は業務の責任者です。

注意点

論文はOpenClawの利用者のReddit投稿で、会社の導入の調査ではありません。 公開初期の早期採用者の投稿が中心で、体験を書きたくなった人の投稿が集まっている、と論文自身が限界に書いています。割合は利用者ではなく投稿の単位です。他のエージェントにどこまで当てはまるかは、今後の検証課題とされています。会社の導入に読み替えたのは当社です。

論文の数字を、自社の見込みに使わないでください。 73,093件という規模と、6つのうち5つ、6つすべて、という結果の形は引用できますが、自社のエージェントで監督の負担がどれだけ出るかは、自社で測るしかありません。

4つの条件を書いても、監督の負担は消えません。 論文は、監督の負担を、特定の監督の手段の代償というより、委任そのものにかかる費用として読んでいます。条件を書くのは、負担をどこに置くかを決めるためで、無くすためではありません。

OpenClawの現在の仕様は、この記事では確かめていません。 論文の記述をもとに書いています。当社でOpenClawを動かしてはいません。

KOIYALの見解

エージェントの評価を、仕事を終えたかどうかで測ると、この論文の利用者が語っていたことが見えません。当社は、終えた仕事の横に、いくら使ったか、何に触れたか、何回聞かれたか、どう完了を確かめたかを並べて、使い続けるかどうかの判断材料にすることを勧めています。エージェントの試用では、この4つを成果と同じ表に書きます。

当社は、インハウス経営（AIを活用し、自社で業務を改善し、自社で仕組みをつくる経営）を自社の中心に置いています。読者の会社が自社でできるようになることを1つ挙げるなら、エージェントに仕事を任せる前に、費用の上限、触れてよい範囲、承認の持続、完了の条件を、自社の言葉で1枚に書くことです。この1枚の観点は、道具が変わっても使えます。上限の金額や承認の範囲といった具体的な値は、道具の費用体系や業務が変われば見直しますが、何を決めるかという観点は変わらないからです。

次の行動

  1. 社内で試しているエージェントを1つ選び、先月の費用、触れたファイルとアカウント、承認を求められた回数、完了をどう確かめたかを、分かる範囲で書き出す
  2. 書けなかった項目に印を付け、条件を決めていないのか、記録や集計が足りないのかを分ける
  3. 条件を決めていない項目から、費用の上限、触れてよい範囲、承認の持続、完了の条件を、誰が決めるかと一緒に1枚に書く

3つ書けたら、それを持って相談に来てください。AIコンサルティングでは、4つの条件を自社の業務の言葉で書き、道具の設定に落とすところまでを一緒に行い、次のエージェントからは自社で書ける形にします。お問い合わせの本文に、エージェントの名前と、書けなかった項目の数を書いていただければ、初回の打ち合わせはそこから始めます。

参考