LLMにおける「ハーネス理論」とは何か

Minecraftで考える、賢いモデルより”うまく動ける仕組み”が重要な理由

最近、LLMはどんどん賢くなっています。

文章を書く。 要約する。 コードを書く。 質問に答える。

こうした単発のタスクでは、すでにかなり高い水準に達しています。 一方で、実際にLLMを使って何かを”やらせる”側に回ると、別の壁にぶつかります。

最初は良さそうに見えるのに、途中で方針がブレる。 長いタスクになると前提を忘れる。 失敗したあとに立て直せない。 前にうまくいったやり方を再利用できない。

要するに、頭は良さそうなのに、仕事としては完走しないのです。

この記事では、この問題を理解するための視点として、**LLMにおける「ハーネス理論」**を扱います。 これは、LLMの強さはモデル単体ではなく、どんな仕組みで世界と接続し、記憶し、試し、失敗から回復できるかで決まる、という考え方です。

そしてこの話を理解するのに、驚くほど相性がいい題材が Minecraft です。

1. LLMは「賢い」だけでは足りない

LLMの話になると、つい「どのモデルが一番賢いか」という議論になりがちです。 もちろん、それは重要です。

ただ、実際のタスクではそれだけでは足りません。

たとえば誰かに「家を建てて」と頼むと、人間なら自然にこう考えます。

  • 今どこに何があるか
  • 材料は足りるか
  • どこに建てるか
  • 危険はないか
  • 途中で失敗したらどうするか
  • 今日はどこまで進めたか

ところが、LLMにただ「家を建てて」と言うだけだと、もっともらしい計画は返してきても、実際の行動になると詰まりやすい。 なぜなら、現実のタスクには思考以外の機能が必要だからです。

  • 状態を観測すること
  • 途中経過を記憶すること
  • 必要に応じてツールを使うこと
  • 失敗からやり直すこと
  • 前回の続きを再開すること
  • 成功したやり方を再利用すること

この”足回り”が弱いと、どれだけモデルが賢くても、実行力は出ません。

2. ハーネスとは何か

「ハーネス」という言葉は、もともと馬具や安全帯の意味があります。 LLMの文脈では、もっとざっくり言えば、

モデルを現実のタスクに接続して、ちゃんと働けるようにする枠組み

くらいに捉えると分かりやすいです。

LLM本体が”脳”だとしたら、ハーネスはその脳を実際の世界で動かすための、

  • 目
  • 手
  • 作業記憶
  • 手順書
  • ログ
  • チェックリスト
  • 再試行の仕組み

のようなものです。

LLM単体では、賢そうな返答はできます。 でも、仕事を完遂するには、周囲にしっかりした実行基盤が必要です。

Anthropicは長時間稼働するエージェントの設計において、LLMが複数セッションをまたぐと記憶の断絶が起きやすく、単にモデルが賢いだけでは長い仕事を安定して進めにくいと指摘しています。さらに、それを補う枠組みとして agent harness を説明しています。

図1. ハーネス理論の全体像

LLMにおけるハーネス理論の全体像。LLM本体を中心に、観測、記憶、ツール接続、再試行・修復が支える構造を示した図

図1：LLM単体ではなく、観測・記憶・ツール・再試行まで含めた実行基盤が「ハーネス」であることを示す全体図。

3. なぜMinecraftがちょうどいい例なのか

この話を説明するのに、Minecraftはかなり優れた題材です。 なぜなら、Minecraftでは「考えるだけ」では何も進まないからです。

木を集める。 道具を作る。 食料を確保する。 拠点を作る。 夜をしのぐ。 危険を避ける。 必要なら採掘する。

どれも、状況に応じて判断しながら進める必要があります。

しかもMinecraftの面白いところは、タスクが一本道ではないことです。

家を建てるにしても、

  • まず木を探すのか
  • 先に石を集めるのか
  • 夜になる前に簡易拠点を作るのか
  • 食料確保を先にするのか

といったように、状況次第で順番が変わります。

さらに、世界の状態は常に変化します。

  • 今どこにいるか
  • インベントリに何があるか
  • 近くに敵がいるか
  • 日没までどのくらいか
  • 前に作った拠点がどこか

こういう情報を踏まえて動かないと、すぐに破綻します。

だからMinecraftは、LLMの本質的な弱点と、ハーネスの重要性をとても分かりやすく見せてくれます。

VoyagerはMinecraft上で動くLLMエージェントとして、自動カリキュラム、スキルライブラリ、環境フィードバックを使った反復改善を組み合わせることで、オープンエンドな探索と長期的な成長を示しました。

4. 「家を建てる」で考える、弱いLLMと強いLLMの違い

たとえば、MinecraftでLLMに「家を建てて」と頼むとします。

ハーネスが弱い場合

この場合、LLMはたぶんそれっぽいことを言います。

「まず木材を集めます。作業台を作ります。必要なブロックを集めて、家を建てます」

文章としては正しい。 でも、実際にはかなり危ういです。

  • そもそも木が近くにあるのか
  • 今は昼か夜か
  • 敵はいるのか
  • 斧はあるのか
  • インベントリに空きはあるのか
  • 建てる場所は安全か

こうした情報を踏まえずに進むと、途中で止まります。 しかも、止まった理由がログとして残らなければ、次も同じ失敗を繰り返します。

ハーネスが強い場合

一方で、ハーネスが強いと、同じ「家を建てて」でも動きが変わります。

まず現在の状態を観測します。

  • 所持品
  • 周囲の地形
  • 時間帯
  • 敵の有無
  • 建築候補地

そのうえで、

  1. 危険なら退避
  2. 資材が足りなければ収集
  3. 必要なら既存スキルを呼び出す
  4. 途中で失敗したら原因を記録
  5. 進捗を保存
  6. 次回はその続きから再開

というふうに進められる。

ここまでくると、単なる”賢そうな返答”ではなく、ちゃんと仕事をするシステムになってきます。

図2. Minecraftにおけるハーネスの実行フロー

Minecraftで「家を建てる」という目標を、観測、小タスク化、スキル呼び出し、実行、失敗記録、進捗保存、再開へつなぐLLMハーネスの流れを示した図

図2：「家を建てる」という曖昧な目標が、観測・小タスク化・実行・記録・再開可能なワークフローに変換される様子。

5. Minecraftで見える、ハーネスの4つの役割

Minecraftを例にすると、ハーネスの役割は特に4つに分けて考えやすいです。

5-1. 観測する

まず必要なのは、今の世界をちゃんと読むことです。

木はどこにあるのか。 近くに敵がいるのか。 食料はあるのか。 暗くなってきたのか。 今いる場所は安全なのか。

当たり前ですが、見えていないものには対応できません。 LLMが弱いというより、世界を観測する手段が弱いと、賢さを発揮する前に詰みます。

5-2. 記憶する

次に必要なのは、状態を持ち越すことです。

  • 拠点の座標
  • チェストの中身
  • 前回どこまで進めたか
  • 以前失敗したルート
  • よく使う建築手順

これがないと、毎回ゼロからやり直しになります。

Minecraft上の memory-aware agent を評価する MineNPC-Task でも、メモリの読み書きや計画・行動・修復の一貫性が重要な評価対象として扱われています。

5-3. スキルを再利用する

毎回「木を集める方法」をゼロから考える必要はありません。 一度うまくいった手順は、次も使えるようにしたい。 それがスキルの再利用です。

Minecraftなら、

  • 安全に木を集める
  • 石のツルハシを作る
  • 迷わず拠点に戻る
  • 最低限のシェルターを作る

といった行動は、部品化しておくと強いです。

Voyagerでは成功した行動を再利用可能なスキルライブラリとして蓄積し、新しい課題にも転用できるようにしています。

5-4. 失敗から立て直す

ここがかなり重要です。

LLMは、失敗すること自体よりも、失敗を次に活かせないことが痛い。

木を切ろうとして失敗した。 その理由は何でしょうか。

  • 斧がなかった
  • 木が見えていなかった
  • 夜で危険だった
  • 持ち物がいっぱいだった
  • そもそも対象を間違えていた

この失敗を「失敗しました」で終わらせるのではなく、原因として取り込めるかどうか。 ここでハーネスの差が出ます。

最近の modular harness 研究でも、ゲーム環境において perception、memory、reasoning を切り分けた構成が有効であり、単なる一発推論より安定した性能向上につながることが示されています。

6. ハーネス理論の本質は「賢さの外部化」

ここがこの記事でいちばん言いたいところです。

LLMがうまく動かないとき、つい「もっと賢いモデルに変えよう」と考えがちです。 もちろん、それで改善することもあります。

でも、実際には別の打ち手もかなり大きい。 それは、賢さの一部をモデルの外に出すことです。

たとえば、

  • 記憶は外部メモリに置く
  • 状態はログとして残す
  • 行動はツールに分解する
  • 長い目標は小さなタスクに分ける
  • 成功手順はスキルとして保存する
  • 出力はチェッカーで検証する

こうすると、モデル本体が全部を抱え込まなくて済みます。

これは「モデルを甘やかす」という話ではありません。 むしろ逆で、モデルが本当に得意な推論や言語化に集中できるようにする設計です。

OpenAIの Agents SDK でも、Web Search、File Search、Code Interpreter、MCP などのツール接続を前提に、モデルを外界と連携させる設計が採られています。これも、ハーネスの実装例として捉えられます。

7. Minecraftの話は、そのまま業務AIの話になる

ここまで読むと、「それはゲームの話でしょう」と感じるかもしれません。 でも、実はかなりそのまま業務に置き換えられます。

Minecraftで木を集めることは、業務でいえば必要情報の収集です。 道具を作ることは、テンプレートやスクリプトの準備です。 拠点に戻ることは、前回の状態の復元です。 スキルを覚えることは、再利用可能な手順の部品化です。 失敗から学ぶことは、ログと改善の仕組みそのものです。

だから、業務でLLMを使うときに本当に問うべきことは、 「どのモデルが一番賢いか」だけではありません。

むしろ先に考えるべきなのは、

  • 何を観測できるのか
  • 状態をどこに残すのか
  • どうやって前回の続きから始めるのか
  • 成功手順をどう再利用するのか
  • 失敗をどう検知して修正するのか

です。

この設計が弱いままだと、どれだけ高性能なモデルを入れても、現場では不安定なままです。

図3. Minecraftと業務AIの対応関係

Minecraftでの木材収集、道具作成、拠点復帰、スキル習得、失敗学習が、業務AIでは情報収集、ツール化、状態復元、ワークフロー資産化、品質改善に対応することを示した図

図3：Minecraft上の行動が、そのまま業務AI設計の要素に対応していることを示す対応関係図。

8. まとめ

LLM時代になると、ついモデルそのものの性能ばかりを見てしまいます。 でも、実際に”動くAI”を作るうえで重要なのは、それだけではありません。

Minecraftを例にするとよく分かります。

強いエージェントに必要なのは、

  • 世界を観測できること
  • 状態を記憶できること
  • スキルを再利用できること
  • 失敗から立て直せること
  • 長い時間軸で進捗を引き継げること

です。

つまり、LLMの強さは、モデルの賢さだけで決まらない。 どんなハーネスで動かしているかで決まる。

これが、この記事でいう「LLMにおけるハーネス理論」です。 そしてMinecraftは、その本質をとても分かりやすく見せてくれる世界です。

参考文献

  • Anthropic, Effective harnesses for long-running agents（2025）
  • Wang et al., Voyager: An Open-Ended Embodied Agent with Large Language Models（2023）
  • Doss et al., MineNPC-Task: Task Suite for Memory-Aware Minecraft Agents（2026）
  • General Modular Harness for LLM Agents in Multi-Turn Gaming Environments（2025）
  • OpenAI Agents SDK Tools Documentation

ここまで読んでいただき、ありがとうございます。

この記事で伝えたかったのは、LLMの活用を考えるときに、モデル単体の性能だけでなく、そのモデルをどう働かせるかまで含めて設計する必要がある、ということです。

今後、業務AIやAIエージェントを本格的に設計していくなら、注目すべきなのは「どのモデルを使うか」だけではなく、

  • どの情報を観測させるか
  • どこに状態を残すか
  • どうやって再試行させるか
  • 成功手順をどう部品化するか

といった、ハーネスの設計そのものです。

mak246.com では、こうした 経営・事業・開発の交差点にある実践知 を、現場目線で整理していきます。 興味が近い方は、ほかの記事もぜひご覧ください。