何を任せられるかは「能力」と「安全」で決まる 〜AIハーネス入門 第3回〜

任せられる範囲は、賢さとは別の部品で決まる

毎朝8時に、人がいなくても動けるか。基幹システムに触れるか。紙の帳票を読めるか。間違えたときに止められるか。あとから何が起きたか分かるか。

AIエージェントに業務を任せるとき、本当に聞きたいのはこういうことです。そして、これらはどれも、モデルの賢さでは決まりません。

前回まで、ハーネスが「答えの質」をどう決めるかを見てきました。AIに渡す書類をどう整えるか、という話です。今回は、もう一方の「任せられる範囲」を見ます。何ができるのか。どこまで届くのか。情報が外に漏れないか。止められるのか。あとから何が残るのか。

この記事は、AIハーネス入門シリーズ（全4回）の第3回です。シリーズの一覧はこちら。

まず、前提を1つ言っておきます。任せられる範囲を決める部品は、モデルの賢さとは違い、製品ごとに「その部品があるか無いか」「どれだけ細かく設定できるか」で差がつきます。製品を選ぶときは、この差をそのまま比べればよいということです。

任せられる範囲は「できるか」という問いで整理する

第1回で挙げた7部品のうち、任せられる範囲に関わるのは「ツールと実行」「安全と権限」「拡張性」の3つです。

ただ、第1回の7部品は、プログラミング用のエージェントを調べて得られた整理です。業務で使うエージェントには、あと2つ足す必要があります。人がいないときにどう動き出すか（トリガー。起動のきっかけ）と、動いたあとに何が残るか（ログと監視。何が残り、誰が見るか）です。

推進担当の目線では、部品の名前より「それがあると何ができるのか」の方が大事です。そこで、部品ではなく「できるか」という問いの形で整理します。

問い合わせ対応エージェントを通し例に、順に見ていきます。

動けるか：トリガー

エージェントが動き出すきっかけは、3種類あります。

1つ目は、利用者の指示です。チャットで「A社の問い合わせに答えて」と頼まれて動く。今の製品の大半はこれです。

2つ目は、時刻です。毎朝8時に、夜のあいだに届いた問い合わせをまとめて処理する。

3つ目は、外部の出来事です。問い合わせのメールが届いた、注文の状態が変わった、配送が遅れた。出来事を合図に動き出します。この場合、基幹システムやメールの側に「出来事が起きたらハーネスに知らせる」設定が要ります。エージェント側だけでは成り立ちません。

時刻や出来事で動かすときの注意は1つです。人がその場にいないまま動く、ということです。間違えたときに止める人がいません。だから、時刻や出来事で動かすなら、どの操作を自動で実行し、どの操作を確認してから実行し、どの操作を提案として保留するか、を先に決めておく必要があります。この3段階の決め方は、業務オントロジー入門の第5回で整理しています。

次は、動き出したエージェントが何に触れるかです。

触れるか：ツールとMCP

エージェントが触れるシステムは、ツールとして用意されたものだけです。第1回で見たとおり、ツール定義にないものは呼べません。

ツールには、2つの面があります。「定義」と「実行」です。

定義は、ツールの名前、説明、受け取る条件（そのツールに渡す入力項目。たとえば「注文番号」）の一覧です。これはAIに渡す書類に入ります。モデルはこれを読んで、どのツールをどう使うかを決めます。

実行は、モデルが出力した「このツールをこの入力で使いたい」という要求を受け取って、実際にシステムを動かす部分です。これはモデルの外、ハーネスの側にあります。

ツールを足す方法として、2024年11月にAnthropicが公開した「MCP」（Model Context Protocolの略）という共通規格が広まりました。2025年12月に中立の団体へ寄贈され、OpenAIやGoogle、Microsoftも支持する標準になっています。

MCPは、電気のコンセントの規格のようなものです。規格が決まっているから、どの家電でもどの家のコンセントでも使える。同じように、MCPに対応したサービス（チャットツール、データベース、社内システム）は、どのエージェント製品からでもツールとして呼べます。つなぐだけでツールが増えます。

便利ですが、ここで前回の話が効いてきます。つないだツールの「定義」は、全部、AIに渡す書類に入ります。モデルに一度に渡せる文章の量には上限があるため、ツールが増えるほど、ほかの内容を入れる余裕（以下「渡せる量の余裕」）は減り、モデルは書類の中身を見落としやすくなります。主要な製品は、「ツール定義を最初から全部渡さず、必要になったときに探して渡す」という作りに移っています。裏を返せば、ツール定義はそれほど多くの渡せる量を消費するということです。

もう1つ、Anthropicが挙げている注意があります。「既存のシステムのAPI（プログラム同士の接続口）を1つずつそのままツールにする」のは、よくある失敗だという点です。APIの数だけツールが増え、渡せる量の余裕が減り、しかもモデルはどれをどう組み合わせるべきか迷います。業務オントロジー入門の第5回で「AIに渡すのは、探す・計算する・動かすの3種類の道具（ツール）だけ」と書いたのは、この失敗を避けるためでもあります。ツールは、APIの操作1つずつではなく、「注文の状況を調べる」のような業務上の1つの仕事を単位にまとめて渡します。

ツールの中には、少し特殊なものがあります。

APIが無いシステムにも触れるか：ブラウザ

社内のシステムには、プログラムから呼べるAPIが無いものも多くあります。画面を人が操作することだけを前提に作られた、古い業務システムや外部のWebサービスです。配送状況が配送会社のWebサイトでしか確認できない、という場面がこれです。

そこで、エージェントにブラウザをツールとして持たせ、人と同じように画面を見て、クリックし、入力させる方法があります。APIが無いシステムにも触れるため、ツールの中では任せられる範囲を最も大きく広げるものです。

一方で、代償も大きくなります。画面を読むには、画面の画像か、画面に並ぶ文字やボタンを文章の形に書き出したものを書類に加える必要があり、1画面ごとに渡せる量の余裕が大きく減ります。そして、画面の中の文章は、自社が管理していない外部の人が書いたものです。そこに紛れた指示をAIが命令として読んでしまう危険（プロンプトインジェクションと呼ばれます）の入口にもなります。

いま「画面を読む」と書きました。画面に限らず、画像そのものを読む能力について、もう少し説明します。

読めるか：画像の読み取り

第1回で、モデルの入力は基本的に文字列だ、と書きました。ここで、その例外を説明します。

最近のモデルは、画像やPDFを受け取れます。図面、帳票、手書きのメモ、画面のスクリーンショット。これらを読めるかどうかで、任せられる業務の幅が変わります。送られてきた注文書の画像を読んで注文を登録する、といった仕事は、画像が読めないと始まりません。

ただし、画像は書類の中で大きな場所を取ります。1枚の画像は、大きさにもよりますが、トークンにして千前後、文章なら原稿用紙2〜3枚分に相当します。実際、主要な製品では、書類が上限に近づくと中身を減らす処理（圧縮）が走り、その処理はまず画像を「[画像]」という印に置き換えて場所を空けます。

1枚なら読めても、帳票を10枚読ませれば上限に届きます。読めるかどうかと、何枚まで読ませてよいかは、別の問題です。

次は、エージェントが「作る」側の能力です。

作れるか、届くか、漏れないか：実行環境

エージェントがツールを実行する場所を、実行環境と呼びます。ここには4つの要素があり、それぞれが別の問いに答えます。

認証情報については、1つ具体的な作り方を挙げます。AIの見える場所には、本物ではなくダミーの文字列だけを置く。AIがそのダミーを使って外部に接続しようとすると、通信が外に出る直前に必ず通る中継のプログラムが、ダミーを本物に差し替える。こうすると、AIは一度も本物の鍵を見ないまま仕事ができます。

実行環境を外から隔離することを、サンドボックスと呼びます。サンドボックスの中で何をしても、外には影響しない、という意味です。AIが失敗しても、外にある本番のシステムやデータは壊れません。

ここで、推進担当にとって大事な事実を2つ。

1つ目。隔離の強さは、製品によって大きく違います。広く使われている製品でも隔離の仕組みを持たないものがあり、隔離の有無は製品の知名度や規模ではなく、作り手の選択で決まります。社内の多くの人で1つのエージェントを使ったり、人がいないまま自動で動かしたりする用途では、次の3つを揃えることを私たちは勧めます。

• コンピュータの土台（OS）の機能を使った隔離
• ルールをファイルに書いた権限管理
• エージェントごとの監査記録

2つ目。どこで動かすかも、選択です。Anthropicは、自社の環境にエージェントを組み込むための部品のセット（Agent SDK。SDKはソフトウェア開発キットの略）と、Anthropicの環境で実行環境ごと預かるサービス（Managed Agents、2026年4月から試験提供中）の両方を出しています。自社のサーバー（自社で管理するコンピュータ）で動かして実行環境を自分で持つのか、実行環境ごとベンダーに預けるのか。預けた場合も、AIに何を許すかの設定は自社が決めます。隔離の仕組みを作るのは製品を提供する会社（ベンダー）ですが、どの仕組みを選び、どこまで制限を厳しくするかを決めるのは、利用する会社です。

作れる、届く、漏れない。次は、止められるかです。

止められるか：フックと権限

AIが「A社に返信を送ろう」と決めたとき、それをそのまま実行させてよいか。この判定を、AIの外側で行う仕組みがフックです。

フックは、ツールを実行する直前と直後に必ず呼び出される、あらかじめ決めておいた処理です（英語のhook＝引っかける、から来ています）。直前のフックは、実行してよいかを判定します。許可する、拒否する、人に尋ねる。直後のフックは、結果を検証し、記録します。

業務オントロジー入門では、AIの操作を通すか止めるかの判定を「関門」と呼んできました。関門は2段あります。1段目が、ハーネス側のフックです。2段目は、業務操作そのものに付いている前提条件（たとえば「出荷済みの注文は取り消せない」）で、オントロジー入門の第5回で扱いました。フックが通しても、2段目の条件を満たさなければ、操作は実行されません。

Claude Code（Anthropicのプログラミング支援エージェント）は、1段目の関門であるフックの中を、さらに3段階に分けています。まず設定ファイルに書かれたルールと照合し、決まらなければ別のAIが「許可・確認・拒否」に分類し、それでも決まらなければ人に画面で尋ねる。判定にかかる時間が短いものから順に試す作りです。

ここで大事なのは、ルールを「プログラムの中」ではなく「設定ファイル」に書くことです。主要な製品は、そろってこの形を採っています。理由は2つあります。ハーネスのプログラムを更新したり別の製品に替えたりしても、ルールのファイルはそのまま使えること。そして、ルールだけを取り出して「何を許しているか」を監査できること。

もう1つ、大事な設計があります。人に確認せず動かす「全自動モード」を持つ製品でも、全自動の設定にしたとしても自動では実行されない操作を、あらかじめ決めておくことです。プログラミング用の製品では、ディスクの全消去のような取り返しのつかない命令がこれにあたります。業務なら、過去の記録の削除や、支払いの実行がこれにあたるでしょう。この一線が無いと、AIが外部の文書に紛れた指示に従ってしまったとき、止める場所がありません。

業務オントロジー入門の第3回で「判断はAIが、判定は機械が」と書きました。何をすべきかの判断はAIに任せてよいが、それを実行してよいかの判定は、AIの外にある決まった仕組みで行う、という意味です。AIの判断がどれだけ賢くても、実行してよいかはAIの外で決まります。

止められることと、あとから分かることは別です。

残るか：ログと監視

エージェントが動いたあとに、何が残るか。ここで言うログは、第2回のメッセージ履歴（モデルに入力する側の記録）とは別に、あとから人が見るために残す操作の記録（監査ログ）のことです。

プログラミング用のエージェントではあまり語られない部分ですが、業務で使うなら、何をどれだけ残すべきかが業種や社内の規程によって最も大きく変わる部品です。

残すべきものは4つあります。

1つ目は、ループの1回ごとにモデルへ渡したコンテキストの全文、つまりそのとき渡された書類に何があったかです。AIがそのとき何を見て判断したのか。これが無いと、間違いの原因を「モデルの出来のせい」としか言えません。書類に何が足りなかったのか、何が余計だったのかが分かれば、直せます。

2つ目は、ツール呼び出しとその結果です。何を呼び、何が返ったか。

3つ目は、AIの提案と、人の承認・却下です。AIが「返金を案内しよう」と言い、担当者が「待て、先に配送会社に確認する」と言った。この記録が溜まると、どの種類の提案なら人がほぼ毎回そのまま承認しているかが見えてきます。そうした種類の操作から順に自動承認に移していく、という進め方の根拠になります。

4つ目は、誰の権限で動いたかです。AIの操作と人の操作が記録上で区別できないと、あとから監査ができません。

これらを「改ざんできない形」で残す必要があります。AIが自分の記録を書き換えられる場所に置いてはいけません。

そして、残したものを誰が見るのか、何を検知したら止めるのか。これは、ハーネスの仕組みではなく、会社の体制の問題です。どれだけ優れたハーネスも、自社の誰が月曜の朝に記録を見るかまでは決めてくれません。

最後に、ここまで見た能力と自社の業務知識を組み合わせて、1つの仕事としてエージェントに持たせる仕組みを紹介します。

仕事のやり方を持たせられるか：スキル

スキルは、ある仕事のやり方を1つのフォルダにまとめたものです。中には、手順を書いたファイル（SKILL.md）と、必要に応じて参照資料や実行できるプログラムが入ります。「配送遅延の案内の仕方」をスキルにするなら、案内文の型、確認する順番、配送会社の問い合わせ先、といった手順が入ります。

スキルがどう使われるかは、ここまでの話の組み合わせです。

起動時に書類に入るのは、スキルの名前と一行の説明だけです。モデルがその説明を見て「この仕事だ」と判断したとき、ハーネスが手順書の本文を書類に加えます。さらに細かい資料は、必要になったときだけ加えます。書類の量を節約しながら、必要な知識を必要なときに出す。前回紹介した、書類に入れない内容を外に置いておく「退避」の応用です。

そして、スキルには実行できるプログラムを同梱できます。たとえば「PDFの注文書から項目を抜き出す」処理を、毎回AIにプログラムを書かせるのではなく、あらかじめ書いて入れておく。AIはそれを呼ぶだけです。結果は毎回同じで、速く、間違えません。これは実行環境（プログラムの実行）があって初めて成り立つ能力です。

スキルは主要な製品のほぼ全部に広がり、MCPと並ぶ標準になっています。使い分けは、MCPは外部のサービスとつなぐため、スキルは仕事のやり方や業務知識を詰めるため、と考えると整理しやすいです。

ここで、第4回につながる見方を1つ。スキルの「形式」は製品が決めます。しかし、スキルの「中身」、つまり自社の注文書をどう読むか、自社の配送遅延をどう案内するかは、自社にしか書けません。

つなぐほど、答えの質は下がる

この記事で見てきた部品が、前回の「渡された書類」の量にどう影響するかをまとめます。

• MCPでつないだツールは、定義が書類に入る
• ブラウザは、画面1枚ごとに渡せる量の余裕を減らす
• 画像は、1枚で原稿用紙2〜3枚分のトークンを使う
• 逆に、ファイルの置き場は、書類から外した内容や途中のメモを保存しておく場所になり、渡す量を減らす

任せられる範囲を広げることは、答えの質と引き換えです。「つなげられるものは全部つなげておく」が正解にならないのは、このためです。何に触れさせ、何を読ませるかは、その業務に必要な分だけ、と決める必要があります。

推進担当が押さえる要点

• 任せられる範囲は「できるか」という問いで整理する。動けるか、触れるか、読めるか、作れるか・届くか・漏れないか、止められるか、残るか、やり方を持たせられるか
• 時刻や出来事で動かすなら、自動・確認・保留の3段階を先に決める。出来事で動かすには、知らせる側の設定も要る
• ツールはMCPでつなぐだけで増やせるが、定義は書類に入る。APIを1つずつツールにせず、業務の単位でまとめる
• 隔離の強さと、どこで動かすかは、選択。隔離の仕組みはベンダーが作るが、選ぶのは会社
• 止める判定はAIの外（フック）で行い、ルールは設定ファイルに書く。全自動でも実行できない操作を残す
• 操作の記録は、渡した書類の全文・ツールの実行結果・提案と承認・誰の権限か。改ざんできない形で。誰が見て何で止めるかは会社の体制
• つなぐほど答えの質は下がる。必要な分だけつなぐ

任せる範囲は、能力と安全の組み合わせで広がる

AIに何を任せられるかは、モデルがどれだけ賢いかではなく、ハーネスがどんな能力を持ち、どこで止められ、何が残るかで決まります。能力だけを足しても、渡せる量の余裕が減って答えの質が下がります。また、止める仕組みが無ければ、そもそも任せられません。

ここまでの3回で、ハーネスの部品を一通り見ました。最終回は、「では、どの部品に自社は力を入れるべきか」を考えます。鍵になるのは、最適なハーネスがモデルごとに違う、という事実です。

シリーズの目次

• AIエージェントは「ツールを呼ぶループ」でできている 〜AIハーネス入門 第1回〜
• AIが見ているのは「渡された書類」だけ 〜AIハーネス入門 第2回〜
• 何を任せられるかは「能力」と「安全」で決まる 〜AIハーネス入門 第3回〜（この記事）
• ハーネスのどこに、会社は投資するか 〜AIハーネス入門 第4回〜

関連記事

• AIエージェントは型の上でどう動くか 〜業務オントロジー入門 第5回〜：自動・確認・保留の3段階の決め方
• 状態遷移図から業務操作を定義する 〜業務オントロジー入門 第3回〜：判断はAIが、判定は機械が
• AIエージェントの承認はどの粒度で？承認疲れと自動承認ルール：提案と承認の記録から、任せる範囲を広げる
• AIエージェントは誰の権限で動くのか：AIの操作を人と区別して記録する
• AIエージェントの監視と停止：改ざんできない記録と、止める手段
• プロンプトインジェクションとは？：外部の文書に紛れた指示への対策

参考資料

• Paul Barbaste ほか, "Harness Engineering: Anatomy, Architecture, and Evolution of Coding Agents," arXiv:2609.00006（2026年7月、https://arxiv.org/abs/2609.00006 （2026年11月2日確認））
• Anthropic「Equipping agents for the real world with Agent Skills」（2025年10月、https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills （2026年11月2日確認））
• Anthropic「Writing effective tools for agents」（2025年9月、APIを1つずつツールにする失敗について、https://www.anthropic.com/engineering/writing-tools-for-agents （2026年11月2日確認））
• Anthropic「Introducing the Model Context Protocol」（2024年11月、https://www.anthropic.com/news/model-context-protocol （2026年11月2日確認））
• Anthropic「Donating the Model Context Protocol and establishing of the Agentic AI Foundation」（2025年12月、https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation （2026年11月2日確認））
• Anthropic「Vision」（Claude Platform ドキュメント、画像1枚のトークン換算について、https://platform.claude.com/docs/en/build-with-claude/vision （2026年11月2日確認））
• Anthropic「Claude Code hooks」（Claude Code ドキュメント、https://code.claude.com/docs/en/hooks （2026年11月2日確認））

Askhubについて

Askhubは、日本の中堅・大企業がAIに業務を任せるための基盤です。業務の型（オントロジー）でAIに許す操作を定め、承認と判断ログで任せる範囲を広げながら、国産の基幹システムまで書き込めるようにします。導入はコンサルタントが伴走します。

この記事の言葉で言えば、Askhubは「止められるか」と「残るか」を製品の前提にしたハーネスです。AIの提案は人と同じ関門で判定され、提案と承認・却下は判断ログに残ります。認証情報は、本文で挙げた「外に出る直前に差し替える」方式で、AIの見えない場所に置きます。

※Askhubのサービスに関する記載は、2026年11月時点の情報です。

関連するページ：AIエージェント、承認

自社の業務にAIエージェントをどう導入するか相談したい方は、お問い合わせからご連絡ください。