ハーネスのどこに、会社は投資するか 〜AIハーネス入門 第4回〜

では、自社は何をすればいいのか
ハーネスの話を3回読んで、「で、うちは何をすればいいのか」と思われたと思います。最終回は、その問いに答えます。
先に、答えの土台になる事実を1つ書きます。ハーネスの最適な作りは、モデルごとに違います。モデルが新しくなると、作り直しになる部分があります。だから、自社で作るものを間違えると、モデルが進化するたびに、せっかく作ったものが無駄になります。
ここまでの3回で、ハーネスの部品を見てきました。第2回は、AIに渡す情報を整えて「答えの質」を決める部品。第3回は、「任せられる範囲」を決める部品。最終回は、その部品のうち、どれを自社が用意し、どれをベンダー(製品やサービスを提供する会社)に任せるかを考えます。
この記事は、AIハーネス入門シリーズ(全4回)の第4回です。シリーズの一覧はこちら。
まず、「モデルごとに違う」とは具体的にどういうことかを、私たちの経験から話します。
推論能力が低いモデルには情報を絞り、高いモデルには全部渡す
私たちがハーネスを作る中で、繰り返し見てきたことがあります。
ここで言う「推論能力」は、モデルの考える力の高さのことです(第1回の「推論」は、学習の終わったモデルを動かして答えを出す段階を指す言葉でしたが、ここでは別の意味で使います)。
推論能力が低いモデルは、渡す情報が増えると、答えの質が大きく下がります。第2回で「情報が増えるほどAIは見落とす」と書きましたが、推論能力が低いモデルでは、見落としによる答えの質の下がり方がとくに大きいのです。こうしたモデルには、本当に必要な情報だけをハーネス側で選び抜いて渡した方が、うまく動きます。
一方、最近の推論能力が高いモデルは、逆です。その仕事の中でAIがそれまでに受け取った指示や途中の結果を、選別せずにすべてそのまま渡した方が、最終的な答えの質が高くなります。ハーネスが細かく選別して渡すより、全体を見せてモデル自身に取捨選択させた方が、よい結果になります。情報が増えても、答えの質の下がり方が小さいからです。
どちらが正しいという話ではありません。「どこまでなら、選別せずに渡した方がよいか」という境目が、モデルによってまったく違うのです。
これは、ハーネスの設計方針が正反対になることを意味します。情報を絞る方向に作るのか、できるだけ渡す方向に作るのか。絞る前提で作ったハーネスを推論能力の高いモデルに使うと、モデルの力を活かせません。逆に、全部渡す前提で作ったハーネスを推論能力の低いモデルに使うと、答えの質が落ちます。

ここまでは「渡す情報の量」の話でした。「指示の細かさ」でも、同じことが起きています。
製品を作る側も、モデルに任せる方向に動いている
Anthropicは2025年9月の記事で、「賢いモデルほど、細かく手順を指示する作りが要らなくなる」と書いています。モデルが賢くなるにつれて、ハーネスが細かく面倒を見る部分は減り、モデルに任せる部分が増える、という見通しです。
実際の製品にも、同じ変化が現れています。
第2回で触れたとおり、Codex(OpenAIのプログラミング支援エージェント)は、モデルの世代ごとに別のシステムプロンプト(AIへの基本の指示文)を用意し、利用者の手元のソフトには埋め込まず、製品を作る会社のサーバーからその都度取り出す形にしています。モデルが更新されたとき、手元のソフトを配り直すことなく指示文だけを差し替えるためです。
AIエージェント製品各社のシステムプロンプトを2026年の4月と7月で比べると、変化が見えます。4月の時点では、多くの製品に「頼まれていない改良を勝手に加えるな」という禁止文がありました。7月の時点では、最新世代のモデル向けの指示文から、この文が消えた製品があります。モデルがその振る舞いを学習で身につけたので、文章で言い聞かせる必要がなくなったのです。加えて、禁止事項を文章で伝える代わりに、製品の設定項目として持つようになったことも理由です。
Googleのエンジニアで、ハーネスの設計について発信しているAddy Osmaniは、このことを一般化して、こう書いています。「ハーネスの各部品は、モデルがまだ自力でできないことについての仮定を埋め込んでいる。モデルができるようになれば、その部品は外れる」。言い換えると、ハーネスの部品の多くは「今のモデルにはまだできないこと」を補うためにあり、モデルが進化すると要らなくなる、ということです。
渡す情報の量も、指示の細かさも、最適な作りはモデルごとに変わります。ここまでを認めると、次の問いは「では、モデルが更新されるたびにハーネスを合わせ直すのは誰か」になります。
モデルの更新に合わせ直すのは、モデルを作る会社の方が早い
モデルが更新されたとき、ハーネスを合わせ直す速さは、立場で違います。
モデルを作っている会社は、モデルの更新と同じ日に、自社のハーネスを合わせ直せます。新しいモデルの癖を、誰よりも先に知っているからです。外からモデルを使う側は、新しいモデルが出てから癖を観察し、それに合わせてハーネスを直すことになります。やればできますが、モデルが更新されるたびに、その費用を払い続けることになります。
AIに渡す情報の整え方、製品が組み込むシステムプロンプト、長くなったやり取りを要点だけに縮めてAIに渡す仕組み、たくさんのツールの中から今の仕事に必要なものを探し出す仕組み。こうしたハーネスの部品を業務ごとに自前で作り、モデルの更新のたびに直し続けるのは、割に合いません。
実際、モデルを作る会社は、ハーネスそのものを部品として配るようになりました。Anthropicは、自社のプログラミング支援エージェントであるClaude Codeの中身をAgent SDK(利用する側が自分のプログラムに組み込める部品のセット)として切り出し、誰でも組み込めるようにしています。OpenAIも、プログラムの中身を公開して誰でも使えるようにしているオープンソースの開発者たちも、同じように部品として配り始めました。第1回で触れた論文は、この状況を「ハーネスを自分で組み立てる時代から、配られているハーネスの中から選ぶ時代に変わった」という趣旨で書いています。
では、会社は何もしなくてよいのでしょうか。そんなことはありません。モデルを作る会社が配っているのは、ハーネスの「本体」です。本体だけでは、自社の仕事は何もできません。
ハーネスには、「本体」と「渡すもの」がある
Agent SDKのような部品を手に入れたとします。これをそのまま動かしても、自社の問い合わせ対応はできません。本体は、自社の注文がどこにあるかも、返金をどう案内するかも知らないからです。動かすには、会社の側から渡さなければならないものがあります。
- カスタム指示。「お届け予定日は配送会社の最新の見込みで答える」のような、会社の決まりごとや用語を書いた指示文
- ツール定義。AIに使わせる操作は何か(注文を検索する、返信を送る、など)。それぞれ何を受け取り、何を返すか
- スキル(仕事の手順書)。自社の注文書の読み方、顧客への連絡の仕方
- 止めるルール。どの操作は自動で実行してよく、どの操作は人が確認してから実行し、どの操作は提案だけにとどめるか
- 書庫(ナレッジベース)に置く資料。案内の規程、顧客ごとのこれまでの経緯。それと、AIが仕事の中で覚えたことを、誰が確認してから保存するかの取り決め
- 記録の扱い。何を記録に残し、誰がいつ見るか
本体が持っているのは「仕組み」です。第1回で見た「ツールを呼ぶループ」を回す、AIに渡す情報を組み立てる、長くなったやり取りを要点だけに縮める、ツールを実行する、ツールを実行する前と後に「そのまま進めてよいか」の判定を挟む、記録を書き出す。この仕組みに上の6つを渡して、初めて自社の業務のエージェントになります。
このシリーズでは、この仕組みの側を「本体」、会社が用意して本体に渡す上の6つを「渡すもの」と呼びます。


この本体と渡すものの境目が、会社が投資する部分とベンダーに任せる部分を切り分ける線になります。
本体は、モデルが変わると作り直しになります。前の節で見たとおりです。一方、渡すものは、モデルが変わっても変わりません。「お届け予定日は配送会社の最新の見込みで答える」という決まりも、「返金の案内は担当者が確認してから」というルールも、モデルがどれだけ賢くなっても変わらないからです。
言い換えると、どこに投資するかを判断する基準は「その部分は、何が変わると作り直しになるか」です。モデルが変わると作り直しになる部分は、モデルを作る会社の仕事。自社の業務やデータ、規程、組織が変わると作り直しになる部分は、自社の仕事。本体と渡すものの境目は、この基準で引いた線とほぼ一致します。
ただし、渡すものは、ひとりでに揃うわけではありません。
渡すものを作り、貯め、本体に渡す場所が要る
会社が本体に渡すものは、どれも会社の中にある知識です。業務で使う言葉、やってよい操作、判断の基準、顧客との過去の経緯。ところが、これらは今、担当者の頭の中、基幹システム、表計算のファイル、規程集に散らばっています。
散らばった知識を集めて、定義として書き起こし、必要なデータを取り込み、ルールとして書き、本体に渡す。そして、AIが動いた結果を記録として貯め、人が確認し、次の定義に反映する。この一連の作業を行うには、作業する場所、つまりシステムが要ります。
なぜ場所が要るのか。全従業員が、Agent SDKのようなプログラムの部品を直接触るわけではないからです。担当者は画面からAIに頼み、画面で承認し、画面で記録を見ます。基幹システムのデータは、誰かがAIの使える形に取り込み、結果を基幹システムに書き戻す必要があります。記録は、改ざんできない形で保管する必要があります。
つまり、ハーネスの本体と、会社の中に散らばる知識との間に、もう1つ別のシステムが要ります。渡すものを作り、貯め、本体に渡す場所です。
この場所を自前で作るか、製品を使うか。これは、どのハーネスの本体を使うかと並ぶ、会社の意思決定です。

会社が用意する4つと、1つの決定
ここまでを、推進担当の言葉でまとめ直します。先ほど6つ挙げた「渡すもの」は、会社が用意するものとして4つに整理でき、意思決定は1つにまとまります(カスタム指示に書く会社の言葉やルールは、業務の型と統制に含めて数えます。スキルの手順は業務の型に含めます)。問い合わせ対応エージェントを例に、何を用意するのか、社内の誰が担うのかも添えます。
1つ目、業務の型。 AIに渡すツール定義の中身です。自社にとって「注文」とは何か、「出荷済み」とはどの時点を指すか、返金の案内は誰がどんな条件で出してよいか。これを定義表にします。問い合わせ対応エージェントなら、「注文を検索する」ツールが受け取る条件と返す項目、「返信を送る」ツールをAIがどの条件で使ってよいか、を書きます。これは自社の業務の定義そのものなので、モデルを作る会社には書きようがありません。業務部門が言葉を出し、推進担当が定義表にまとめます。作り方は業務オントロジー入門の全7回で扱っています。
2つ目、書庫と記憶。 AIに参照させる資料と、AIが覚えたことの扱いです。配送が遅れたときの案内の規程や、顧客ごとのこれまでの経緯を、検索で引ける単位に分け、部署や改定日といった手がかりを付けて、書庫に置きます。AIが仕事の中で「A社への返信は、担当のBさんにも写しを送る」と覚えたとき、それを誰が確認してから保存するかを決めます。資料の中身は自社にしかなく、覚えたことが正しいか確認できる人も自社にしかいません。資料の整備は業務部門と情報システム部門が、覚えたことの確認は業務の担当者が担います。
3つ目、統制。 どの操作をAIにどこまで任せるかの取り決めです。「注文の検索は自動で実行してよい。返信の送信は担当者が確認してから。返金の案内は提案だけにとどめる」のように、操作ごとに決めます。あわせて、承認を操作1回ごとに求めるのか、ひとまとまりの仕事ごとに求めるのか、AIが動く環境を社内の他のシステムやインターネットからどこまで切り離すかも決めます。これらは業務への影響の大きさと取り消しやすさで決まるもので、モデルの賢さとは関係がありません。業務部門と、内部統制や監査の担当が、操作ごとに決めます。
4つ目、ログと監視。 何を記録に残し、誰がいつ見て、何が起きたらAIを止めるか。第3回で見たとおり、ここは会社の体制そのものです。「毎週月曜に、先週AIが提案したものと、担当者が却下したものの一覧を営業部長が見る」まで決めて、初めて記録は意味を持ちます。記録を残す仕組みは情報システム部門が、記録を見るのは業務の責任者が担います。
そして1つの決定。 どのハーネスの本体を使い、渡すものをどこで作って貯めるか。本体を自社の環境で動かすのか、ベンダーの環境に預けるのか。渡すものを作る場所を自前で作るのか、製品を使うのか。この選択で、別の製品への乗り換えの手間も、社内での管理の仕方も決まります(ベンダー各社は、他社の製品で作った設定を取り込む機能を出し始めていますが、乗り換えはまだ簡単ではありません)。推進担当と情報システム部門が案を作り、経営が決めます。
逆に言えば、この4つと1つ以外は、ベンダーに任せてよい、ということになります。

製品を選ぶときは、この5つを聞く
4つの渡すものと1つの決定を、製品を選ぶ場面で聞く質問に直しておきます。ベンダーの説明が「モデルの賢さ」に寄っているときほど、この5つを聞いてください。
何について | 聞くこと | 何を確かめているか |
|---|---|---|
業務の型 | 自社の業務の言葉と、AIにやらせてよい操作を、こちらで定義して渡せるか。それはどこに、どんな形で書くのか | ツール定義の中身を会社が決められるか。決められなければ、AIは自社の業務をデータベースの項目名から推測することになる |
書庫と記憶 | AIに参照させる規程や過去の経緯は、どんな形式で、どこに置けばよいか。AIが仕事の中で覚えたことを、人が確認してから保存する仕組みがあるか | 資料の置き方と、AIの記憶の確認が、会社の手の中にあるか |
統制 | 操作ごとに「自動で実行」「人が確認してから実行」「提案だけ」を分けられるか。全自動の設定にしても、必ず人の確認を要する操作を決めておけるか | ルールの中身を会社が書けるか。そのルールを設定として取り出して、監査に出せるか |
ログと監視 | AIが各回で何を見て、どのツールを呼び、何を提案し、人がどう判断したかが、改ざんできない形で残るか。その記録を自社で取り出せるか | 操作の記録が会社の手元にあるか。無ければ、間違いの原因も分からず、任せる範囲を広げる根拠も作れない |
本体と場所 | 本体はどこで動くか。パスワードや鍵はAIから見えない作りか。モデルが更新されたとき、誰がいつ本体を合わせ直すのか。別の製品に移るとき、定義やルールや記録は持ち出せるか | 実行環境を会社が選べるか。本体の更新をベンダーが引き受けているか。渡すものが特定の製品に閉じ込められないか |
5つとも、まともな答えは「できます」「できません」ではなく、「この画面のここで、こうやって」という具体的なものになるはずです。具体的な答えが返ってこなければ、その部分は会社の手で変えられない、ということです。

この切り分けが当てはまらない3つの場面
ここまでの線引きは、大まかな方向性の整理です。当てはまらない場面を3つ挙げておきます。
1つ目。誰でも入手して自分のサーバーで動かせる形で公開されているモデルを、自社のサーバーで運用している会社は、本体の側も自社で持つことになります。モデルをいつ更新するかを自社で決めているので、本体を合わせ直すのも自社の仕事になるからです。
2つ目。「渡すもの」の中にも、ハーネスの知識が要るものがあります。たとえば、AIに使わせる操作を、どのくらいの大きさのまとまりで1つのツールにするか、AIが仕事の中で覚えたことのうち何を残すか。こうした判断には、業務の知識と、ハーネスがどう振る舞うかの理解の両方が要ります。業務部門だけでも、ベンダーだけでも決められません。
3つ目。本体はベンダーに任せるとしても、製品を選ぶ以上、本体の作りの良し悪しを見分ける目は要ります。このシリーズを書いたのは、その見分ける目を持ってもらうためです。
推進担当が押さえる要点
- 最適なハーネスはモデルごとに違う。推論能力が低いモデルには情報を絞って渡し、高いモデルには全部渡す。モデルが変わると、ハーネスの設計方針が正反対になることもある
- モデルの更新にハーネスを合わせ直すのは、モデルを作る会社の方が早い。本体を業務ごとに自前で作り、更新のたびに直し続けるのは割に合わない
- ハーネスには「本体」と「渡すもの」がある。本体はモデルが変わると作り直しになり、渡すものは変わらない。切り分けの基準は「何が変わると作り直しになるか」
- 渡すものはひとりでに揃わない。作り、貯め、本体に渡す場所が要る。その場所を自前で作るか製品を使うかは、会社の決定
- 会社が用意するのは、業務の型、書庫と記憶、統制、ログと監視の4つ。製品を選ぶときは、これに本体と場所を加えた5つを聞き、具体的な答えが返るかを見る
モデルが変わっても変わらないものを、見分ける
モデルは、これからも速く進化します。そのたびに、ハーネスの本体は作り直されます。
この連載で示したかったのは、その中で「何が変わり、何が変わらないか」を見分ける基準です。モデルが変わると作り直しになる部分は、モデルを作る会社が追いかけます。自社の業務、データ、組織、規程に根ざした部分は、モデルが変わっても残ります。
投資の判断は、この基準に照らせば自分でできます。今から作ろうとしているものは、次のモデルが出たときに残るのか、作り直しになるのか。製品を選ぶときも、ベンダーの説明を聞くときも、同じ問いが使えます。
AIエージェントの構造は、第1回で見たとおり単純です。単純だからこそ、どこに自社の判断が要るのかは、技術者でなくても見分けられます。この連載が、その見分けの助けになれば幸いです。
シリーズの目次
- AIエージェントは「ツールを呼ぶループ」でできている 〜AIハーネス入門 第1回〜
- AIが見ているのは「渡された書類」だけ 〜AIハーネス入門 第2回〜
- 何を任せられるかは「能力」と「安全」で決まる 〜AIハーネス入門 第3回〜
- ハーネスのどこに、会社は投資するか 〜AIハーネス入門 第4回〜(この記事)
関連記事
- なぜ今、業務に「型」が要るのか 〜業務オントロジー入門 第1回〜:会社の側に残る「業務の型」とは何か
- 基幹システムは置き換えない 〜業務オントロジー入門 第4回〜:データは今の場所のまま、型で束ねる
- 最初の1業務を型にする 〜業務オントロジー入門 第7回〜:小さく始める手順
- AIエージェントの責任は誰が負う?システムと運用の責任分界:ベンダーと会社の責任の線
参考資料
- Anthropic「Effective context engineering for AI agents」(2025年9月、https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents (2026年11月2日確認))
- 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日確認))
- Addy Osmani「Agent Harness Engineering」(2026年、https://addyosmani.com/blog/agent-harness-engineering/ (2026年11月2日確認))
- Anthropic「Claude Agent SDK」および「Claude Managed Agents」(Claude Platform ドキュメント (2026年11月2日確認))
Askhubについて
Askhubは、日本の中堅・大企業がAIに業務を任せるための基盤です。業務の型(オントロジー)でAIに許す操作を定め、承認と判断ログで任せる範囲を広げながら、国産の基幹システムまで書き込めるようにします。導入はコンサルタントが伴走します。
この記事の言葉で言えば、Askhubは「渡すものを作り、貯め、本体に渡す場所」にあたります。
※Askhubのサービスに関する記載は、2026年11月時点の情報です。
自社の業務をどう型にし、AIに何を任せるかを相談したい方は、お問い合わせからご連絡ください。業務の洗い出しから定義表づくりまで、伴走支援のコンサルタントが一緒に進めます。
この記事の内容について相談する
自社の業務でどう進めるか、相談したい方はこちらのフォームからご連絡ください。1〜2営業日以内に担当者よりご連絡します。

