AIに「お願い」する時代の終わり — ハーネス設計と、経営者の新しい仕事

こんにちは。Goodpatchで社長室と管理部を管掌している執行役員の坂口（ぐっさん）です。

先日、Goodpatchの管理部20名が1ヶ月で30件のClaude活用事例を実装した記録をnoteに書きました。IR決算説明資料の品質チェックは8人時から0.5人時へ、英文決算短信のドラフトは6時間から1.5時間へ。「上場会社のバックオフィスはAI活用が最も難しい」と言われる領域で何が起きたかの記録です。公開後、社外のCEO・CFOを含めた経営者の方々から「うちでも展開したい」「具体的にどうやったか聞きたい」と声をかけていただく機会が増えました。

ここで一つ、はっきり言いたいことがあります。

AI活用が個人レベルで止まっている組織と、組織のスループットを着実に上げている組織。両者の違いは、AIツールでもプロンプトでもありません。AIが動く環境を、経営者自身が設計しているかどうかです。これが今回、最も伝えたい一点です。

相談の場でいただく質問の多くは「どのAIツールを使ったか」「プロンプトはどう書いているか」といった、手段に関するものです。私自身、他社の事例を聞くときに同じ問いから入ります。自然な疑問だと思います。

ただ、振り返ると、私たちが管理部でやっていたのは、手段の選択と並行して、もう一つ別のレイヤーを動かす作業でした。業務効率化は確かに目的の一つです。8人時を0.5人時に、6時間を1.5時間に短縮する。数字として明確に取りに行きました。同時に走っていたのは、全員にAIを使う前提を作り、組織としてAIが動く土台を組み立てる作業。つまり、ハーネス設計そのものでした。

今回はその続編として、「なぜハーネス設計と、それを育てる仕組みづくりこそが、これからの経営者の仕事なのか」、その理由を、私の実装と合わせて書きます。

1. AI活用は3段階で進化している

ここ数年のAI活用は、おおむね3段階で語られるようになっています。

• 〜2024：プロンプトエンジニアリング（指示をどう書くか）

• 〜2025：コンテキストエンジニアリング（情報をどう与えるか）

• 2026〜：ハーネスエンジニアリング（環境をどう設計するか）

「プロンプトをどう書くか」が議論の中心だった2024年から、「文脈をどう与えるか」（RAGやMCP）が議論の中心になった2025年、そして2026年は焦点がさらに上のレイヤー、すなわちAIが作業する環境そのものをどう設計するかに移りつつあります。

この概念を「ハーネスエンジニアリング」と命名・提唱したのは、HashiCorp（Vagrant・Terraform）の創業者で、ターミナルエミュレータ「Ghostty」の作者でもある Mitchell Hashimoto氏です。2026年2月5日に公開された氏のエッセイ「My AI Adoption Journey」の中で、こう書かれています。

同月、OpenAI（Ryan Lopopolo氏）「Harness Engineering: Leveraging Codex in an agent-first world」、LangChain「Improving Deep Agents with Harness Engineering」、そしてMartin Fowler氏（Birgitta Böckeler氏との共著）「Harness Engineering」が相次いで発表され、用語は急速に広まりました。Anthropicも前後して関連する設計論「Effective Harnesses for Long-Running Agents」（2026年1月）を公開しています。

これは個人のテクニックの話ではありません。明確に方法論として確立されつつある領域です。実際、AIにソフトウェアのバグ修正を解かせる業界標準のベンチマークでは、同じAIモデルでも、ハーネス（環境）の出来不出来だけで22ポイントもの差が出ることが報告されています。モデルの賢さよりも、その周囲を整える設計のほうが、成果を大きく左右する。プロンプトより、環境。これが今の段階の結論です。

2. ハーネスとは何か — 馬具と「失敗できない仕組み」

「ハーネス（harness）」はもともと馬具を意味する英語です。

どんなに優秀な名馬でも、馬具がなければただ草を食むだけ。手綱で方向を示し、鞍で安定を保つことで、馬は目的地へ向かって走り出します。

エンジニアリングの文脈では、ハーネスはもう少し広義に「強力なエネルギーや能力を、安全かつ意図した形で引き出す仕組み」を指します。ソフトウェア開発における「テストハーネス」が代表例で、テストを単に実行するだけでなく、環境のセットアップから結果の検証までを体系化した「足場」を意味します。

ハーネスの本質は、力を抑えることではなく、力を正しい方向へ引き出す構造を設計することにあります。

AIも同じです。どんなに高性能なモデルでも、適切な環境が整っていなければ、その力を引き出すことはできません。プロンプトが「その場の口頭指示」だとすれば、ハーネスは「職場環境の整備」に近い。

ハーネス設計の本質を、私は一行でこう捉えています。

Mitchell Hashimoto氏が示した核心思想も同じです。エージェントがミスを犯したとき、そのミスが二度と起きないよう環境を改修する。失敗のたびにプロンプトでパッチを当てるのではない。仕組みに刻み込むのです。

Martin Fowler氏はこれを一行で定式化しています。

AIエージェントの成果はモデルの賢さだけでは決まりません。それを取り囲む環境設計の質と、等しく重要なのです。

そしてハーネスは、固定された設計図ではありません。AIが進化すれば、必要なガードレールも変わる。だからハーネスは、設計したあとに育て続けるものです。

3. 「ハーネス」と「ハーネス設計」は別物

ここで一つ整理しておきます。「ハーネス」と「ハーネス設計」は別の概念です。

• ハーネス ＝ モノ（what）。AIや人間の動きを束ね、正しい方向へ引き出す仕組み・環境そのもの

• ハーネス設計 ＝ コト（how）。ハーネスを組み立て、運用しながら育てていく方法論、および経営者がそれを使いこなすための実践

組織設計、制度設計、戦略設計と同じ系統の言葉です。経営者が扱うのは後者、つまり「設計する」と「育てる」を回し続ける営みです。個別のハーネス（ガードレール、評価ループ、社内ガイドライン）を一つひとつ作る作業ではなく、それらをどう組み合わせ、運用し、育てていくかという上位の意思決定領域。

なお、業界では「ハーネスエンジニアリング」という呼び方が広がりつつあります（先述のMitchell Hashimoto氏らの提唱による）。本稿では、経営者にとっての実践という観点から「ハーネス設計」と呼ぶことにします。

ハーネスの構成要素は、おおむね次の3つに整理できます。

• 判断基準の言語化(何を「自社らしい」「正しい」とするかを構造化)

• 生成と評価のループ(AIが生成 → 基準でセルフチェック → 人間が判断)

• 継続的なチューニング(上記のループを回しながら改善し続ける)

4. ハーネスの2軸 — エージェント側とユーザー側

ハーネスは大きく2つに分かれます。裏側のハーネスと表側のハーネスです。

エージェントハーネス（裏側の土台） AIエージェントが正しく、確実に動作するように支える仕組み。

• ガードレール（安全に使えるよう制御）

• ツール連携（外部システムやデータと接続）

• 評価・監視（結果の品質をチェック・改善）

AIが「正しく判断し、適切に行動できる」ように整える土台です。エンジニア・データチームの領域に近いですが、何を「正しい」「適切」とするかの判断基準を決めるのは経営の仕事です。

ユーザーハーネス（表側の設計） ユーザーがAIを迷わず、安心して使えるように支える仕組み。

• 迷わせない（入口・導線・テンプレートで使い方を明示）

• 理解させる（AIの判断根拠・確信度の可視化）

• 成果を出させる（出力を業務に反映・活用する導線）

ユーザーが「迷わず、理解しながら、最大成果を得られる」ように支える設計です。これはUX・組織設計・現場運用の話で、経営者が一番関与すべき領域です。

興味深いのは、ユーザーハーネスの一形態は、すでに日常業務に組み込まれていることが多い点です。AIでドラフトを生成し、レビューして選択・修正する。このプロセス自体がユーザーハーネスです。これを意識的・体系的に設計するかどうかが、組織の成果を分けます。

経営者の仕事は、この2軸を両方とも視野に入れて設計することにあります。エンジニア任せだとエージェント側に偏り、現場任せだとユーザー側に偏る。両方の整合を取れるのは経営層しかいません。

5. なぜ経営者がこれを知るべきか

ハーネス設計は、経営者が普段やっていることと、構造的に同じです。

文化、ルール、レビュー体制、引き継ぎ資料、役割分掌、評価基準。これらはすべて、「毎回口頭で言わなくても組織が回るようにする」ための仕組みです。

AIエージェントが組織に大量に増えていく時、それは「新しい従業員が一斉に入社する」のと同じです。一人ひとりに毎朝オンボーディングし直すのか、それとも仕組みとして整備するのか。答えは明らかです。

ここで便利な診断フレームがあります。AIのアウトプットの品質が上がらないとき、原因はどちらか。

• 「AIへの説明が足りない」 → コンテキストの問題（情報を補完すれば直る）

• 「同じミスが繰り返される」 → ハーネスの問題（仕組みに組み込まないと再発する）

繰り返されるミスをプロンプトでパッチし続けるのは、新入社員に毎朝同じ注意をするのと同じです。チェックリスト・テスト・運用ルールに落とし込んで、構造的に発生しなくなるようにする。それがハーネス設計です。

そして経営者がやらなければ、組織レベルのハーネス設計は誰もやりません。エンジニアは自分のリポジトリのハーネスは設計します。しかし、会社全体としてのハーネス設計、判断基準、「やらないこと」、チェック体制、開示プロセス、評価基準は経営者の領域です。AI活用の話だからといってCIO・CTOに丸投げできる類のものではありません。

6. 「使うAI」と「作るAI」 — 自社はどこにいるか

現代のAI活用は、大きく2軸に分かれます。

• 使うAI：チャット型のAIで仕事する（ChatGPT、Claude.ai など）

• 作るAI：エージェント・自動化・MCPを業務に埋め込む（Claude Code、各種カスタムエージェント）

多くの組織は、まだ「使うAI」のフェーズに留まっています。私が社外の経営者から受ける相談のほぼすべても、この段階のものです。「ChatGPTを全社配布した、で次はどうする？」「個人活用は進んだが、組織のアウトプットには反映されない」。これらはまさに「使うAI」のレイヤーで止まっているサインです。

興味深いのは、規模や業種を問わずほぼ同じ壁にぶつかっていることです。共通項は「AIに何をさせるか」は議論しているが、「AIが動く環境をどう設計するか」は議論していない、ということ。ハーネスの不在です。

ハーネス設計の議論は主に「作るAI」の文脈で語られます。ただし、「使うAI」のチームでも、共有プロンプト・テンプレート・チェックリスト・社内ガイドラインはすべてハーネスの一部です。

経営者として問うべきは、自社が今どちらにいるか、そしてどちらに向かうべきか。「使うAI」だけで止まる会社と、「作るAI」まで進む会社では、3年後のレバレッジが全く違います。

7. 私の実践 — Goodpatchで何をやっているか

私自身、執行役員業務をまるごとハーネス化する（設計し、育てていく）試みを進めています。冒頭で触れた管理部20名・1ヶ月30件の取り組みも、その一環です。取り組みは大きく個人レイヤーと組織レイヤーに分かれます。

個人レイヤー(経営者自身の業務にAIを実装する)

• gucci-agent：Gmail／Googleカレンダー／各種MCP連携。毎朝6:30、11:30、17:30に経営情報がSlackへ自動配信される。「AIに聞きに行く」のをやめて「AIから来させる」設計

• 40エージェント戦略分析システム：Claude Codeで7部門・48ファイル・40エージェントを構成し、経営戦略課題を多角的に分析

• 業務エージェント群：業界動向ウォッチエージェント、週次営業レポートbot、tl;dv→Slack議事録自動要約など

組織レイヤー(上場会社としての推進と統制)

• 管理部20名による1ヶ月30件のClaude活用実装（IR決算資料の品質チェック工数を94%削減（8人時→0.5人時）、英文決算短信のドラフト作成を75%削減（6時間→1.5時間）等。詳細は前回記事参照）

• AIホワイトリスト＋利活用ガイドライン（統制と推進の両立）

• 管理部の業務フロー再構築（法務・経理・総務・情シス・経営企画へのAI組み込み）

• 経営情報の社内Slack配信フォーマット化

• 社内AI活用事例の可視化ダッシュボード（社内ナレッジツールで #Claude タグの投稿状況を集約）

これらに共通するのは、個別の業務効率化を積み上げているのではなく、AIと組織が協働するための土台を作っているという発想です。

率直に書くと、現在地はこうです。正直、ちょっとざわざわしています。

「使うAI」の組織展開は前進しました。前述の通り、管理部20名が1ヶ月で30件の活用事例を実装し、現場までAIが届きました。社内AIホワイトリスト・ガイドライン・利活用文化の整備も進みました。ここは素直に手応えがあります。

一方で、これらの「作るAI」を組織のスケーラブルな運用に乗せるには、もう一段下の基盤を敷く必要があります。判断基準、関係者の役割、「やらないこと」、レビュー観点のチェックリスト。個人レベルでは私の頭の中の暗黙知で回せますが、組織にエージェントを展開するには、これらが文書化されていなければなりません。そこは、まだ整っていません。まだまだもったいない状態だな、と感じています。

私個人の生産性は上がりました。一方で「作るAI」、つまり自律エージェントが組織の業務プロセスを日常的に動かす状態、組織のスケーラブルな運用設計、AI推進KPIとの接続。これらは、いま組織に実装している最中です。

8. 経営者の新しい仕事 — そして、あなたの最初の一手

経営者がAIに「上手く使ってね」とお願いする時代は、もう終わると思っています。

これからの経営者の仕事は、AI（と人間）が動く環境を設計し、それを育て続けることになるんじゃないか。私はそう感じています。判断基準を明文化する、「やらないこと」を定義する、レビュー観点をチェックリスト化する、引き継ぎを仕組み化する、専門エージェントに役割を分担させる、自動チェックでミスを構造的に防ぐ。

「やっている人にはやっている」と言われそうです。実際そうです。しかしこれらが個人スキルではなく組織能力として埋め込まれている会社は、まだ少ない。「使うAI」レベルでは現場まで届いていても、「作るAI」レベル、つまり自律エージェントが業務プロセスを回す段階まで到達している組織は、まだほとんどありません。私たちも例外ではなく、いま業務プロセスに組み込んでいる最中です。

それを組織に組み込むのが、経営者の仕事です。

そしてその第一歩は、たった数行のテキストから始められます。最小限のハーネスは、こんなふうに始められます。

1. 自分が関わる業務領域を3つ列挙する

2. 主要な関係者の役割を一行ずつ書く

3. 「やらないこと」を3つ書く

このメモを、ChatGPTのカスタムインストラクション、Claudeのプロジェクト機能、Claude Codeの CLAUDE.md、あるいはNotionでもメモアプリでも、自分のAIに渡せる場所に置けばいい。

これだけで、明日からのAI活用の質が変わります。AIがあなたの組織文脈を理解した状態で作業を始め、毎回ゼロから前提を共有する必要がなくなります。

ここが大事です。この最初の数行は、経営者であるあなた自身が書くことに価値があります。部下に丸投げしない。なぜなら、自分の業務の判断基準と禁止事項を明文化するという行為そのものが、自分の経営の輪郭を見直す作業になるからです。

ハーネスは、一度設計して終わりではありません。設計したあとに、育てていくものです。今日のあなたの最初の数行は、あなた自身のハーネスそのもの。明日もう一行足す。来週は新しいルールを足す。半年後、あなたのハーネスは見違えるほど豊かになっています。

おわりに

経営者として、今日からできることが一つあります。 自分自身のハーネスの「最初の一行」を書いてみてください。

ChatGPTのカスタムインストラクションでも、Claudeのプロジェクト機能でも、Notionのメモでも、場所はどこでもいい。「自分が関わる業務領域を3つ」「主要な関係者の役割」「やらないこと3つ」。これだけで、明日からのAI活用の景色が変わります。実際に、私の仕事も、景色も変わりました。

AIに「お願い」する時代は終わる。 経営者の新しい仕事は、ハーネスを設計し、育てていくことだと、私は思っています。

そして、それは今日始められます。

参考

• Mitchell Hashimoto「My AI Adoption Journey」：https://mitchellh.com/writing/my-ai-adoption-journey

• Anthropic「Effective Harnesses for Long-Running Agents」：https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents

• LangChain「Improving Deep Agents with Harness Engineering」：https://blog.langchain.com/improving-deep-agents-with-harness-engineering/

• OpenAI「Harness Engineering」： https://openai.com/ja-JP/index/harness-engineering/

• Martin Fowler「Harness Engineering」：https://martinfowler.com/articles/harness-engineering.html