## 今月の経営キーワード `ハーネス・エンジニアリング` 「LLM（生成AI）で成果が安定しない」「指示を工夫しても限界がある」。それは、頼み方でなく仕組みの問題かもしれません。LLMが成果を出せる作業環境を設計する技術が、ハーネス・エンジニアリングです。 ## ミニクイズ 次のうち、ハーネス・エンジニアリングの考え方に**最も近い**取り組みはどれでしょう？ A. LLMへの指示文を人間が何度も書き直し、良い回答が出る言い回しを探し続ける。 B. LLMに議事録の要約をさせ、結果をそのまま参加者に共有する。 C. LLMに議事録の要約をさせ、担当者がチェックリストで確認し、問題があれば修正指示を出すフローを定める。 D. LLMに社内規程の原案を書かせ、出力の品質が高かったので採用する。 →[回答とその理由は記事の最後に掲載しています](#答え) ## 解説 ### 数学の難問を解いたのは「仕組み」だった 2026年に入り、[AIが数学の未解決問題を解いた報告](https://news.jp/i/1417683400603631631)が相次いでいます。長年、数学者が答えを出せなかった問題にLLMが迫りはじめた。LLMが驚くほど進化した証拠と言えるでしょう。 ただここで見落としたくないことがあります。未解決問題を解いたのは、LLMの性能だけではありません。LLMに証明の候補を出させ、Leanのような証明支援ソフトで検証するケースもあります。間違いがあれば修正して再探索する。こうした「LLMの使い方」も劇的に進化しています。 つまり、 ``` 候補を生成する → 評価する → 検証する → 修正する → 再探索する ``` この繰り返しの仕組みが、難問を解く力の正体です。言い換えれば、未解決問題を解いたのは、LLMを働かせ、確かめ、直し、もう一度試す「ハーネス」の力でもあったのです。 ### プロンプト・エンジニアリングとの違い LLM活用の技術は、おおむね次のように発展してきました。 ``` プロンプト・エンジニアリング（どう頼むか） → コンテクスト・エンジニアリング（何を渡すか） → ハーネス・エンジニアリング（どう作業させ、検証し、修正するか） ``` たとえばLLMに「会議録を要約してください」と頼む場面なら、 - **プロンプト**：「会議録を要約してください」という指示の工夫 - **コンテクスト**：用語集・過去資料・業界知識など、渡す情報の設計 - **ハーネス**：文字起こし→用語補正→要約→要件に基づくチェック→修正→再チェック ハーネス・エンジニアリングとは、LLMにうまく指示する技術ではなく、**LLMが成果を出せる作業環境を設計する技術**です。試す・確かめる・直す、というループを仕組化して回すことがポイントです。 ### ビジネス実務への翻訳：LLMが働ける「業務設計」 ビジネス実務的に言い換えれば、ハーネス・エンジニアリングは「LLM用の業務設計」です。 人間に仕事を任せるときも、「やっておいて」だけでは不十分です。目的・前提資料・作業手順・判断基準・チェック項目・レビュー・やり直し基準・最終責任者、こういった設計があってはじめて仕事が動きます。LLM活用も同じです。 ここから導かれる示唆は明確です。 > **LLM活用スキルは、「うまい指示文を書く力」だけではありません。どの仕事を渡し、何を基準に確かめ、間違いをどう直すかまで設計する力が問われます。** その意味で、LLM活用の中心は「個人の使いこなし」から「業務プロセスの設計」へ移りつつあります。 ### 実務への展開 ハーネスの考え方は、提案書作成・議事録作成・調査・営業資料・社内規程・採用・教育など、あらゆる業務に応用できます。 具体的には次のような問いが出発点になります。 - この業務で、何ができれば「OK」と言えるか？ - LLMが出しやすい間違いは何か？ - その間違いをどう検出するか？ - どう修正し、再チェックするか？ こうした「出す→確かめる→直す→もう一度試す」感覚を体感するなら、Claude CodeやCodexのようなコーディングエージェントを一度触ってみるのも近道です。 ## LLMに聞いてみよう > [!check] ChatGPTやGemini、ClaudeなどのLLMに下記のような質問をしてみてください。 - ハーネス・エンジニアリングとは何ですか？プロンプトエンジニアリングとの違いも含めて、わかりやすく説明してください。 - 私たちの業務（例：〇〇）でLLMを使う場合、何ができれば「OK」と言えるかを整理してください。 - Claude CodeやCodexのようなコーディングエージェントでは、「出す→確かめる→直す→もう一度試す」ループはどのように動いていますか？ ### 経営キーワードの過去記事で関連するもの - [[📘経営キーワード_2025年05号：LLM（生成AI）の現在地]] （LLMの技術的な現在地を整理した号。ハーネスの「前段」にあたる文脈として関連） - [[📘経営キーワード_2024年10号：Amazonのパワポ禁止]] （LLMへの「丸投げ」ではなく、思考の構造化を重視する文脈として関連） - [[📘経営キーワード_2025年04号：デザイン思考]] （試作・検証・修正を繰り返す思考法として、ハーネスの設計思想と共鳴する） ## 答え 正解は **C. LLMに議事録の要約をさせ、担当者がチェックリストで確認し、問題があれば修正指示を出すフローを定める。** です。 ハーネス・エンジニアリングのポイントは、LLMを「単発で答えさせる」のではなく「生成→検証→修正」のループに組み込む設計にあります。 - **A（指示文の工夫）**：これはプロンプトエンジニアリングです。「どう頼むか」の最適化であり、ハーネスとは異なります。 - **B（結果をそのまま共有）**：検証・修正のステップがなく、ハーネスの考え方とは逆です。LLMの誤りがそのまま外に出てしまうリスクがあります。 - **C（チェックと修正フローを定める）**：生成→確認→修正という作業ループが設計されており、ハーネス・エンジニアリングの考え方に最も近い取り組みです。 - **D（そのまま採用）**：品質が高く見えても、検証・修正のプロセスが欠けています。 ハーネスの本質は「LLMが間違えることを前提として、間違いを発見・修正できる仕組みを作ること」です。完璧な指示を探すより、失敗を回収できる設計を先に作る。この発想の転換が、LLM活用の次のステージへの入口です。 <div style="text-align: right;"> 以上 </div>