電通総研の技術ブログ

全856件

2026/08/31

はじめまして。金融IT本部プロダクトソリューションユニット融資ソリューション2部の渡邉真太郎です。現在は 2 年目社員として、地域金融機関向けの CRM / SFA サービス開発に従事しています。 2025 年 11 月、Anthropic がエンジニアリングブログの記事（ Effective harnesses for long-running agents ）のタイトルに「ハーネス（harness）」という言葉を掲げました。長時間動き続ける AI エージェントを、いかに破綻させずに走らせ続けるか——その「型枠」や「足回り」にあたる仕組みを指す言葉です。公開直後から、この言葉は一気に界隈を駆け巡りました。「これからはプロンプトエンジニアリングではなくハーネスエンジニアリングだ」といった論調があちこちで見られ、SNS や技術記事のタイムラインは、しばらく「ハーネス」一色だったように思います。それから半年経ち、当初のバズワード的な過熱はいくらか落ち着きましたが、「ハーネス」は一過性の流行語として消えるどころか「ハーネスエンジニアリング」という一つの設計分野として、むしろ業界に定着しつつあります。だからこそ今、流行り言葉としてただ持ち上げるのではなく、「結局ハーネスとは何なのか」を地に足をつけて理解したいと考えています。そこで本記事では、ちょっとした検証も交えながらハーネスという概念を改めて整理してみたいと思います。本記事は、隔週で開催している社内勉強会『25卒技術会』での発表内容をもとに執筆されています。前回の記事はクロスイノベーション本部の大岡叡さんが書いています！ぜひご覧ください！ Part 1. ハーネスの概要を知る 1-1. ハーネスの文脈 1-2. ハーネスの定義 Part 2. より詳しく理解する 2-1. ハーネスを体系的に理解する難しさ 2-2. ハーネスの体系的分類メインとして扱う分類：Meng らの6成分（ETCSLV） 2-3. ここまでのまとめ Part 3. 自分で検証する 3-1. 検証方法 E（実行ループ）: 一時的な失敗からの復帰 T（ツール）: 反復作業を助ける Skill C（文脈管理）: どれが正しい資料かを教える S（状態）: セッションを跨ぐ引き継ぎ L（フック）: 完了前の関門 V（評価）: 別のエージェントによる点検 3-2. 各成分のタスクとハーネス（一覧） 3-3. 確認指標と実験条件 3-4. 結果 Part 4. 学びを整理する 4-1. ベストプラクティスは「そのまま従う」ものではない 4-2. モデルが進化しても効くのは「知識を補う」ハーネス 4-3. Haiku ですら、もう十分に賢いまとめ：ハーネスは「盛る」より「効かせる」これからのハーネス Part 1. ハーネスの概要を知る本 Part では、そもそも「ハーネスという言葉すら聞いたことない」という方向けに、ハーネスの文脈（なぜ生まれたか？）ハーネスの定義（どういう意味の言葉か？）を説明します。 1-1. ハーネスの文脈 AI に仕事をさせるとき、私たちが作り込む対象はここ数年で少しずつ移り変わってきました。モデルへの指示そのものから、モデルに渡す情報、さらにはモデルを取り囲む仕組みへと、工夫する領域が広がってきたイメージです。プロンプトエンジニアリング：モデルへの「言い方」を工夫するコンテキストエンジニアリング：モデルに「何を見せるか（文脈）」を設計するハーネスエンジニアリング：モデルの周りに、計画・記憶・検証・復旧などの機構を組むはじめは一問一答が中心で、いかに上手く指示するか（＝プロンプト）が工夫のしどころでした。やがて扱うタスクが大きくなり、検索結果や長い資料をモデルに渡すようになると、限られた文脈に何をどう載せるか、いわゆる「コンテキスト」が問われるようになっていきました。そして AI エージェントという自律的処理機構の台頭により、上記の工夫だけでは足りなくなった結果生まれたのが「ハーネス（エンジニアリング）」という言葉です。ちなみに「ハーネス（harness）」はもともと馬具を指す言葉で、馬（＝モデル）を制御して仕事をさせる装具、という比喩です。 1-2. ハーネスの定義次に、ハーネスの厳密な定義に目を向けていきます。 …が、多くの IT 系ホットワードの例に漏れず、「ハーネス」という語もコミュニティで盛んに利用される割に、業界統一での定義はされていません。よってここでは、多くの一次情報で登場する言葉の使われ方を 2 点程ご紹介します。エージェント = モデル + ハーネスモデルとは、"Claude Opus" や "GPT" などの「AI 本体」の部分です。ハーネスはこの周りでモデルを動かし続ける仕組みであり、モデルとハーネスを組み合わせることによってエージェントが成り立っている、と多くの文献では定義されます。乱暴に簡易化すると、「AI エージェントのうち、モデル以外のすべてがハーネスである」ということです。狭義のハーネス前述の「モデル以外の仕組み」をもう少し分解すると、下記の二つに分けられます。 AI エージェントを走らせる前に組んでおく設定: system prompt、ツールの説明、文脈の渡し方など AI エージェントが走っている最中に効く機構: ツール呼び出しの処理、文脈の圧縮、安全制約の強制、状態の永続化などこのうち前者を scaffold（足場）、そして後者を狭義としての harness（ハーネス）と呼び分けることがあります。特に前者がより浸透しているハーネスという語の使われ方だと個人的には感じています。よって本記事でも、「モデルと共にエージェントを構成する要素（モデル以外のすべて）」という広義のハーネスを指して、以降「ハーネス」と呼んでいきます。 Part 2. より詳しく理解する次に、「ハーネスとは何か」をより具体的に整理します。ハーネスという語はその話題性に反し、概念を深く理解する上でいくつかの障壁が存在します。ここではまず、その前提となる難しさを整理してから、ハーネスの体系的な理解を試みます。 2-1. ハーネスを体系的に理解する難しさハーネスを腰を据えて理解しようとすると、最初に2つの壁にぶつかります。 (1) デファクトの分類が無いハーネスは非常に広い概念なので、全体像をつかむには「どんな要素からなるののか」という体系・分類が肝要です。ところが、Anthropic や OpenAI といった各社は、AI エージェントの設計・運用に関する個別のベストプラクティスを数多く公開しているものの（例：Anthropic: Harness design for long-running application development 、OpenAI: Harness engineering など）、「ハーネスとはこう分類される」と断定的には整理しておりません。結果として、多くの有志が「AI モデル以外のチューニング要素＝ハーネス」という大枠のもとに独自の体系を作っており、複数のサイトを覗くと、どれも少しずつ違う分類になっているというのが現状です。 (2) 概念が流動的ハーネスは「モデルを補助する機構」という性質上、モデルが賢くなるほどベストプラクティスが移り変わります。 Anthropic 自身、記事の中で「ハーネスの各部品は、モデルが自力でできないことについての"仮定"を符号化している。その仮定は誤っているかもしれず、モデルの改善とともに急速に陳腐化しうるので、検証する価値がある」　　と述べています。実際、同社はあるモデル世代で必須だった「コンテキストのリセット機構」を、次世代では丸ごと外せたと報告しています。つまり固定的な分類を作りにくく、個々のベストプラクティスを継続的に追いかける必要がある、というわけです。この2つを踏まえ、それでも全体像をつかむために、本記事では「現時点の代表的な分類を1つ選び、それを軸に他の分類を読み解く」という進め方をとります。 2-2. ハーネスの体系的分類メインとして扱う分類：Meng らの6成分（ETCSLV）本記事では、ハーネスを正面から形式的に分解した最新のサーベイ（ Meng et al. "Agent Harness for LLM Agents: A Survey" ）が提案する 6つの成分をメインの分類方法として利用します。ハーネスを H =（E, T, C, S, L, V）の6成分に分けるもので、それぞれの役割は次のとおりです。記号成分役割（何をするか）具体例 E 実行ループ次の手を決め→実行→観測を繰り返し、いつ止めるかを司る「考える→操作する→結果を見る」を回す ReAct 型ループ。Claude Code が編集とテスト実行を延々と回す動き T ツールモデルが外界にできること（行動の選択肢）ファイル読み書き・シェル・テスト実行、MCP 接続、Skills C 文脈管理何を見せ、作業中の文脈をどう保つか関連資料を全部渡す（dump）か必要時だけとる（JIT）か、長くなったら要約する S 状態会話の外に何を残し、セッションを跨いで引き継ぐか進捗ファイル、 state.json 、Git 履歴、次セッションへのハンドオフ L フック節目で決まった処理を強制的に発火させる「完了の前に必ずテスト/型チェックを通す」ゲート、起動時の init.sh V 評価成果物が要件を満たすか・終えてよいかを判断する別エージェントによる要件照合と差し戻し、テストでの合否判定この分類に当てはめると、例えばプロンプトの調整は C（文脈管理）、会話内容のログ化は S（状態）、一時期話題になった "evaluator エージェントの起用" は V（評価）として分類されるハーネスです。これは要素の切り分けが最も明示的で初学者でも考えやすく、またそこそこ網羅的である点が非常に優秀です。よって本記事ではこの分類を基準として扱い、ほかの分類を読み解いていきます。 ※ ただしこれは、業界で確立した標準ではなく、あくまで最近の代表的な分類の一つである点には注意してください。また場合によっては上記の分類で適切に分離できないものもあります。 6成分以外にも、代表的な分類がいくつかあります（Wang らの4モジュール、実装解析の "Inside the Scaffold" 12次元、Anthropic / OpenAI の実装パターン、コミュニティの整理など）。それぞれの詳しい説明に努めたいところですが、本記事では文量の関係で上記の 6成分を基準にして検証へ進みます。参考：6成分以外の分類例と、6成分との対応（クリックで展開） (1) Wang らの4モジュール（エージェント構築の統一フレームワーク） A Survey on LLM based Autonomous Agents （Wang et al.）は、エージェントを profiling／memory／planning／action の4モジュールで整理する統一フレームワーク（unified framework）です。ハーネスに特化した分類ではなくエージェント全般が対象で、6成分より粒度は粗めです。 (2) Inside the Scaffold の12次元（実装の実態） Inside the Scaffold （Benjamin Rombaut、※査読前）は、実在する13個のコーディングエージェント（OpenHands・SWE-agent・Aider・Cline・Codex CLI など）のソースコードを解析し、設計を制御アーキテクチャ／ツール・環境のI/F／リソース管理の3層・12次元で比較します。「ツールが使える」「記憶がある」といった能力レベルの抽象分類では見えない実装の差が、コスト・信頼性・失敗の出方に直結する、と指摘します。 (3) 各社の実装パターン（Anthropic / OpenAI） Anthropic は長時間のアプリ開発で、 initializer＋coding agent の2エージェント（ Effective harnesses for long-running agents 、Justin Young）から、 planner・generator・evaluator の3エージェント（ Harness design for long-running application development 、Prithvi Rajasekaran）へと発展させました。sprint contract（着手前に"完了の定義"を合意）/ context reset / 評価者の分離などが登場し、「各構成要素はモデルにできないことの"仮定"を符号化しており、ストレステストする価値がある」という一節は本記事の検証の出発点でもあります。 OpenAI も Codex を題材にハーネスを扱っています。エージェントループを解剖した記事では、Codex の中核を「 core agent loop and execution logic（中核の実行ループと実行ロジック）」＝ハーネスと定義しています（ Unrolling the Codex agent loop ）。さらに、この設計の営みを「ハーネスエンジニアリング」と名づけ、エンジニアの仕事の中心が「コードを書く」ことから「エージェントが信頼して働ける環境とフィードバックループを設計する」ことへ移る、と位置づけています（ Harness engineering 、Ryan Lopopolo）。 (4) コミュニティ／実務の整理有志のまとめや実務家の設定は、E/T/C/S/L/V のような形式分解ではなく、「解きたい課題ごと」（メモリ／評価／文脈の渡し方／ガードレール（安全・権限）／観測性／オーケストレーション…）でカテゴリを切る傾向があります。awesome-agent-harness 系のまとめや、実務家のエージェント最適化設定（例：ECC）が代表例。形式分解では埋もれがちな権限・安全や観測性を、独立した関心事として前面に出すのが特徴です。 2-3. ここまでのまとめここまで「ハーネスとは何か」「どんな要素に分けられるか」について整理してきました。そのうえで強調したいのは、ハーネスの実装一つ一つは、決して目新しいものではないということです。私たちが普段からやっているプロンプトの調整、使うモデルの切り替え、Claude の Skills の利用、 CLAUDE.md でのフォルダ構成や規約の記述などはすべて、すでにハーネス設計の一部です。つまりハーネスに対しての「今までになかった全く新しい概念」という理解は正確ではなく、「これまで AI モデルの周りで個別にやってきた工夫を、統一的に呼ぶための言葉」と捉えるのが実態に近いと言えます。 Part 3. 自分で検証するここまでで、ハーネスの体系をひととおり整理してきました。とはいえ、多くの方が本当に気になるのは「ハーネスを設定すると、AI エージェントの仕事は実際どれだけ良くなるのか」という点だと思います。そこで本 Part では、Part 2 で選んだ 6成分（ETCSLV）を軸に、実際に手を動かして行った検証の結果を紹介します。 3-1. 検証方法やったことはシンプルで、「代表的なハーネスを実装し、AI エージェントのタスク処理能力が実際に上がるかを試す」というものです。 6成分それぞれについて、その成分にあたるハーネスと、そのハーネスが効きそうなタスクを1つずつ用意しました。そして同じタスクを「ハーネスなし（素の構成）」と「ハーネスあり」で解かせ、どれだけ差が生まれるかを比べます。実行するモデルは、強いモデル（Claude Opus 4.8）と弱いモデル（Claude Haiku 4.5）の2種類です。成果物の良し悪しは、モデルには見せない隠しテストで機械的に採点しました。題材は主に、口座開設・入出金・送金といった機能を持つ小規模な銀行コアサービス（TypeScript）で、一部はより小さなユーザー登録 API を使っています。なお、今回試したハーネスはどれも、Anthropic が公開しているベストプラクティスに基づいています。各成分の説明で根拠として触れるのは、主に次の記事です。 Building Effective AI Agents How we built our multi-agent research system Effective context engineering for AI agents Effective harnesses for long-running agents Harness design for long-running application development 以下、各成分にどんなタスクとハーネスを用意したかを見ていきます。 E（実行ループ）: 一時的な失敗からの復帰 E で解かせるのは、小さなユーザー登録アプリの入力チェックを1つ追加する、という修正タスクです。仕掛けはテスト実行のタイムアウトにあります。エージェントには修正後に走らせるテストを与えていますが、このテストは最初の1回だけ、強制的にタイムアウト（終了コード124）で失敗し、あたかも処理が異常終了したように見せます。これに対するハーネスは、一時的な失敗に対するリトライの指示です。「一時的なタイムアウトで失敗しても、コードを作り変えず、まず同じコマンドをもう一度実行する」と伝えます。失敗したらすぐ諦めるのではなく、一時障害なら再試行して続ける、という実行ループの止め方の調整にあたります。この設計は、障害対処を「モデルの適応力（ツールが失敗していると伝えれば、うまく立ち回る）＋リトライのような決定論的な安全網」で行うこと（multi-agent 記事）、そして実行ループには「制御を保つための停止条件」を設けること（Building Effective Agents）がベースとなっています。 T（ツール）: 反復作業を助ける Skill T で解かせるのは、あるアプリの複数の操作に対して、同じ形の入力チェックを1つずつ実装していく、という反復作業です。似た構造のチェックを、対象を変えながら何度も書いていくイメージです。これに対するハーネスは、その反復を助ける Skill（Claude の拡張機能）です。チェックの骨格（雛形）を一括で生成する専用の Skill を渡し、繰り返しの手間を肩代わりさせます。ただし正解そのもの（何をどう返すか）は Skill に含めず、骨組みだけを自動化しています。ツールや Skill でできることを広げて作業を効率化するのは基本の構成要素で、ツール（エージェントが外界にできること）の設計が成果を大きく左右する、という Building Effective Agents の立場に基づきます。 C（文脈管理）: どれが正しい資料かを教える C で解かせるのは、銀行向けの小さなアプリを仕様書どおりに直す、というチェックと修正のタスクです。ただし資料フォルダには、現行の正しい仕様書と、一見それらしい古い仕様書が、中立な名前で並べてあります。どちらが正しいかは中身からは判断できず、放っておくとエージェントは自分の常識に近いほう（標準的に見えるほう）に引きずられ、現行の仕様に反してしまいます。これに対するハーネスは、どの資料が現行の正本かを示す情報を渡すことです。正解そのものではなく「こちらを信じてよい」という手がかりだけを添えて、エージェントの取り違いを減らします。限られた注意の予算に、価値の高い情報を過不足なく載せる、という Effective context engineering の考え方に沿っています。 S（状態）: セッションを跨ぐ引き継ぎ S で解かせるのは、ユーザー登録アプリに項目を1つ追加する作業です。このとき、例えば入力の前後の空白をどう扱うか、といった、コードからは導き出せない細かな取り決めを、最初のセッションのプロンプトでだけ伝えます。そして作業を途中で中断し、前のやりとりの記憶を持たない、まっさらな新しいセッションで再開させます。これに対するハーネスは、作業状態を会話の外のファイルに残しておくことです。取り決めや進捗を外部ファイル（ state.json ）に書き出し、再開時に読み戻すことで、セッションを跨いでも情報が失われないようにします。各セッションは前の記憶を持たずに始まるため、進捗ファイルや引き継ぎ資料で状態を橋渡しする、という Effective harnesses の中核設計です。 L（フック）: 完了前の関門 L で解かせるのは、あるデータの型に必須の項目を1つ足す、という修正です。この変更を正しく行うと、本体と、テストの無い別の箇所の両方で型の不整合が起きます。ところが公開テストのほうは、型の不整合を無視してパスするよう作ってあります。そのため「テストが通った＝完了」と早合点すると、型崩れを見逃してしまいます。これに対するハーネスは、完了前の関門（フック）です。作業を「完了」とする前に、必ず型チェックを通し、通らなければ完了させない、という決まった処理を節目で強制します。完了の前に決まった検査を挟む「ゲート」（Building Effective Agents）と、「エージェントは十分な検証をしないまま完了と宣言しがち」という報告（Effective harnesses）が下敷きです。 V（評価）: 別のエージェントによる点検 V で解かせるのは、互いに影響し合う複数の新しい機能を、まとめて実装する大きめのタスクです。規模が大きく、ある機能の変更が別の機能に波及しやすいため、エージェントは、テストで見つかる取りこぼしを作り込みやすくなります。これに対するハーネスは、別のエージェントによる評価です。実装を終えた成果物を、まっさらな文脈を持つ別のエージェントがレビュワーという立場で見直し、見つけた問題を直します。自分で自分の成果物を見直す「自己レビュー」と比べ、見る人を分けることの効果を測ります。作業する側と評価する側を分けることが強力なレバーになる、という Harness design の要点に基づきます。なお以上の6つに加え、比較の基準線として、情報の偏りが無い素直な完成タスクも用意しました。ここでは「あらゆるハーネスを常時オンにした盛りすぎの構成」が、品質を上げずにコストだけ増やさないかを確認しています。 3-2. 各成分のタスクとハーネス（一覧）整理すると、各成分に用意したタスクとハーネスは次のとおりです。成分解かせたタスク設定したハーネス E 実行ループ入力チェックの追加（テストが初回だけタイムアウト）一時的な失敗へのリトライ指示 T ツール同じ形のチェックを反復して実装骨格を一括生成する Skill C 文脈管理仕様準拠の修正（新旧の仕様書が混在）どれが現行の正本かを示す情報 S 状態取り決めを渡して中断→新セッションで再開作業状態の外部ファイル保存と読み戻し L フック必須項目の追加（型崩れ／公開テストはパス）完了前に型チェックを通す関門 V 評価波及の多い大きめの実装別エージェントによる点検 3-3. 確認指標と実験条件上記のタスクの検証に利用する指標と実験の条件についても説明します。今回は、次の3つの指標でハーネスの効き目を見ます。品質（不合格数）：モデルには見せない隠しテストのうち、通らなかった数です。少ないほど良い出来で、満点はタスクごとに異なります。ターン数：エージェントが「考える→操作する→結果を見る」を繰り返した数です。多いほど時間がかかります。コスト：1回の試行にかかったおおよその費用（米ドル）です。ターン数と並ぶ「無駄の少なさ」の目安で、使うモデルによっても大きく変わります。また実験の条件ですが、各タスクを「アーム（ハーネスなし／あり）」×「モデル（Opus・Haiku の2種）」の組み合わせごとに複数回繰り返しました。反復回数は基本3回ずつ、ばらつきの大きい評価（V）だけ5回です。これらによって計測される結果の平均値をとり、分析を実施します。各実行は毎回使い捨ての隔離環境で走らせ、前のセッションの記憶（自動メモリ）が混ざらないことを全実行で確認しました。またアーム間で「渡す情報」と「使うモデル」はそろえ、変えるのはハーネスの有無だけとし、採点も固定の隠しテストで統一して、条件をなるべくフェアに保っています。なお満点はタスクごとに違うので、表は成分同士を直接比べるのではなく、同成分の「ハーネスあり/なし」、「モデルの差」ごとに比較します。 3-4. 結果検証の結果は下記のようになりました。成分（満点）モデル不合格数（ハーネスなし）不合格数（ハーネスあり）ターン数（なし→あり）コスト（$, なし→あり）効果 S 状態（6） Haiku 3.0 0.0 18→21 0.08→0.12 あり S 状態（6） Opus 3.0 0.0 17→21 0.38→0.64 あり C 文脈（125） Haiku 12.3 4.7 68→77 0.71→0.71 あり C 文脈（125） Opus 21.0 0.7 37→38 2.73→2.82 あり E リトライ（4） Haiku 0.0 0.0 18→18 0.09→0.10 なし E リトライ（4） Opus 0.0 0.0 17→18 0.37→0.47 なし L フック（2） Haiku 0.0 0.0 18→49 0.11→0.33 なし L フック（2） Opus 0.0 0.0 16→25 0.45→0.83 なし T Skill（84） Haiku 0.0 0.0 68→74 0.65→0.74 なし T Skill（84） Opus 0.0 0.0 53→58 3.13→3.76 なし V 評価（153） Haiku 5.6 2.4 71→132 0.63→1.27 あり V 評価（153） Opus 0.4 0.4 43→91 2.86→5.63 なし対照（122） Haiku 2.7 2.0 57→91 0.48→0.81 なし対照（122） Opus 0.0 0.0 21→36 1.92→2.30 なし ※ V の「ハーネスなし」は最初の実装（点検なし）が残した取りこぼし、「ハーネスあり」は別のエージェントが点検・修正した後の数です。ターン数とコストの「あり」は、点検のぶんが上乗せされた合計を表します。また対照の「ハーネスあり」は、あらゆる足場を盛った構成の値を指します。そのうえで、要点を整理します。はっきり効果が出たのは、 S（状態）と C（文脈管理）の2つだけでした。共通するのは、判断のその瞬間に、必要な手がかりが手元になく、資料の中身からも導けない、という状況です。S では中断で情報がまるごと消え、C ではどちらの仕様書が正しいか分かりません。この「情報の欠落」は能力では埋められず、外から手がかりを渡すハーネスだけが効きました。しかも強い Opus でも効果は変わらず、C ではむしろ Opus のほうが効果が大きい。情報が足りないという壁は、モデルが賢くなっても越えられないようです。反対に、 E（リトライ）・L（完了ゲート）・T（Skill）は、ほとんど差が出ませんでした。いまのエージェントは、一時的な失敗なら言われずとも自分で走らせ直し、完了前には自分で型チェックを回し、反復の実装も難なくこなします。手元の情報だけで完結する「閉じたタスク」では、これらのハーネスが肩代わりする仕事はもう残っていないのです。それどころか、足したぶんターン数やコストだけが増える場合もありました。 V（評価）が効いたのは、弱い Haiku のときだけでした。Haiku は自分の実装に取りこぼしを残しがちで、そこを別エージェントの点検が拾って直します。一方で強い Opus は最初からほぼ満点のため、拾うべき取りこぼしが無く、点検は空振りに終わりました。そして基準線（対照）でも、あらゆるハーネスを盛った構成は、品質を上げないまま、コストとターン数だけを増やしました。今回の検証でいちばんはっきり見えたのは、ハーネスは「付ければ効く」ものではなく、モデルが自力では埋められない情報の欠落を補う場合に有効、ということでした。 Part 4. 学びを整理する検証を通して見えてきたことを、3つの学びとして整理します。 4-1. ベストプラクティスは「そのまま従う」ものではない今回、代表的なハーネスをひととおり試してみて、うまく効いたものは一部だけでした。しかも効かなかったケースでは、ハーネスを足したぶんコストやターン数だけがかさむ、という結果すらありました。ベストプラクティスは世の中に数多く公開されていますが、それを無条件に全部取り入れるのは、むしろ損になりかねません。まずは最小限の構成でタスクを解かせてみて、足りないと分かったところだけ、少しずつ足していく。この順番が、遠回りに見えて確実だと感じました。 4-2. モデルが進化しても効くのは「知識を補う」ハーネス効いたハーネスに共通していたのは、モデルが知りようのない情報を、外から渡すものでした。裏を返せば、情報の非対称性（モデルの手元にその情報があるかどうか）が、成果を大きく左右するということです。言い換えると、「モデルの知能を肩代わりする工夫」よりも、「モデルの知識を補う工夫」のほうが、これからも価値を持ち続けます。モデルが賢くなるほど前者の出番は減っていきますが、後者は賢さでは埋められないからです。 4-3. Haiku ですら、もう十分に賢い正直に言うと、この検証でいちばん苦労したのは、ハーネスの実装よりも「差がつくタスクを作ること」でした。少し難しい課題を用意したくらいでは、下位モデルの Haiku ですら難なく解いてしまい、ハーネスの有無で差が出ないという状況が何度も発生しました（そもそも、Haiku という軽量モデルの存在を意識していない方も多いのではないでしょうか）。ちょっとした修正のたびに Sonnet や、まして Opus を呼んでいる人は、一度 Haiku に任せてみると、その賢さに驚くかもしれません。まとめ：ハーネスは「盛る」より「効かせる」本記事の出発点は、「ハーネスは盛れば効くのか？」という素朴な問いでした。検証を経て出た答えは、はっきり「いいえ」です。効いたのは、モデルが自力では埋められない情報の欠落を補うハーネスだけでした。逆に、モデルの“知能”を肩代わりしようとする足場は、モデルが賢くなるほど出番を失っていきます。ハーネス設計の勘所は、あれもこれもと機構を盛ることではなく、「このタスクで、モデルの手元に本当に足りていないものは何か」を見極め、そこだけを的確に埋めることにあります。よく我々は「開発の最初期に完璧なハーネス設計をする」ということにとらわれがちですが、この結果を考えると最初にすべてを整えるのは悪手であり、むしろ最初は最低限、そこから少しずつ修正を加えていく方法がベストであるといえそうです。これからのハーネスモデルは、これからも賢くなり続けます。その分、いま「ベストプラクティス」と呼ばれている工夫の多くは、来年には不要になっているかもしれません。実際 Anthropic 自身、あるモデル世代では必須だった機構を、次の世代では丸ごと外せたと報告しています。ハーネスとは、常に更新され、ときに“引き算”もされていくものです。そうなると、ハーネスエンジニアリングの重心は、「モデルの不得手をどう補うか」から、モデルが知り得ない情報・文脈・権限を、いかに的確に渡すかへと移っていくはずです。Part 2 で紹介したように、OpenAI はエンジニアの仕事の中心が「コードを書くこと」から「エージェントが信頼して働ける環境とフィードバックループを設計すること」へ移りつつある、と述べています。ハーネスを考えることは、これからますます、 AI と一緒に働く環境そのものを設計することに近づいていくのだと思います。ハーネスエンジニアリングは、流行り言葉として消えるどころか、モデルが進化するほど奥行きを増していく、息の長いテーマだと思います。まずは素の構成で走らせ、足りない情報だけを足してみる。その小さな一歩から、ぜひ始めてみてください。私たちは一緒に働いてくれる仲間を募集しています！電通総研キャリア採用サイト電通総研新卒採用サイト執筆： @watanabe_shintaro レビュー： @miyazawa.hibiki （ Shodo で執筆されました）

TypeScript, キャリア, React, 人工知能, テスト, 設計, ChatGPT, Cline, MCP, Claude Code

電通総研 の技術ブログ

コンテンツ

電通総研の技術ブログ