- ソフトウェア時代の終焉は ハーネス(harness)時代の始まり を意味し、固定ワークフローとマネージドDBで動いていたSaaSは、知能を備えたAIへと置き換わりつつある
- AIは強力だが、野生馬のようにまだ飼いならされておらず、その力を活用するには 体系的な制御(domestication) が必要
- AIエージェントのハーネスは、中核のLLMを取り巻く 7つの中核構成要素 で定義され、各要素が本番レベルの信頼性と性能を左右する
- すべての企業が同じモデルにアクセスできる時代では、モデルそのものではなく ハーネスをよりうまく設計・運用する側(best rider) が勝つ
- ビッグラボが優先しない 数千の分離した市場 が、スタートアップにとっての機会として残る
ハーネス時代の意味
- AIは、固定ワークフロー型SaaSとマネージドデータベースを 知能(intelligence)で置き換える ことで、ソフトウェアのパラダイムを再定義している
- AIはマスタング(野生馬)にたとえられ、強力だが荒々しく、そのままでは使えないため、飼いならす作業こそがハーネス となる
- 飼いならしの本質は、LLMを中心に据え、その周囲に7つの構成要素を放射状に配置するアーキテクチャにある
AIエージェント・ハーネスの7つの構成要素
-
1. Context & Memory (コンテキストとメモリ)
- 汎用モデルには 用途別のカスタム検索(bespoke retrieval) が必要であり、放射線科医向けのコンテキスト検索システムと法務アシスタント向けのシステムが同じであるはずはない
- 短期メモリ（「エージェントは45秒前に何をしていたか」）、大規模画像検索（放射線・画像生成）、数十億文書のキーワード検索など、ケースごとにシステムは異なる
- 検索の隣には コンテキストデータベース があり、ビジネスが実際にどのように運営されているかを記した「レシピブック」の役割を果たす
- 人々が頭の中に入れて出社する標準運用手順(SOP)こそが、そのレシピである
- 初期の取り込みと、人・プロセスの変化に応じた進化が、コンテキストDBの本質である
-
2. Tools & Action (ツールとアクション)
- ツールはエージェントが外部世界に影響を与える手段であり、コンテキストDBのレシピが「何をするか」だとすれば、ツールは それを実際に実行する材料と器具 に当たる
- 現代のハーネスは レジストリ(registry) を通じてツールを公開し、モデルが渡した引数を検証し、呼び出しをディスパッチし、機密性の高い作業は承認ゲートを通し、その結果をエージェントループでパースする
- MCP がツール接続のための結合組織(connective tissue)として台頭している
- ハーネスの品質は、安全に公開できるツールの数と、失敗をきれいに処理する能力によって決まる
-
3. Orchestration & Loop (オーケストレーションとループ)
- エージェントループは 思考(think) → 行動(act) → 観察(observe) → 反復(repeat) という構造を持つ
- 計画立案、タスク分解、サブエージェント、リトライ、中断条件が、仕事の進め方を規定する
- 使うほど改善されるべきであり、各実行から学習する クローズドループ・パターン がベンダー間の差別化要因となる
-
4. State & Persistence (状態と永続性)
- 多数の人員が同時にシステムを利用する大規模エンタープライズでは、レジリエンス(resilient) が必須となる
- 10段階の作業の7段階目でハーネスがクラッシュした場合、最初からではなく 8段階目から再開 できなければならない
- ファイルシステム、チェックポイント、セッションスレッド、アーティファクトストアが、作業損失を防ぐ仕組みとなる
-
5. Sandbox & Compute (サンドボックスとコンピュート)
- 各エージェントには 独立した作業空間(サンドボックス) が必要
- 分離されたUnixワークスペース、制御されたネットワークegress、モデル外に保管される認証情報(credentials)が、安全性・機密性・大規模な速度を担保する
-
6. Observability & Governance (可観測性とガバナンス)
- 「見えないものは信頼できない」— すべてのステップを追跡し、すべてのツール呼び出しをログに記録し、回帰テストとしてevalsを実行し、最高リスクの判断には human-in-the-loop を入れることが、デモを本番システムへと変える
- ガードレール(Guardrails) はポリシーを強制し、Evals は顧客より先にリグレッションを捉える
-
7. Cost & Workflow Optimization (コストとワークフロー最適化)
- 7つ目は アーキテクチャ上の判断力(architectural judgment) である
- 決定論的に処理すべき領域と非決定論的に処理すべき領域を分け、ステップごとに適切なモデル（最先端・中規模・小規模・ファインチューニング）を選び、知識をスキルに置くかメモリに置くかを判断する
新たな競争構図
- その結果、ソフトウェアにおける新たな競争ダイナミクスが生まれるが、すべてのカテゴリに同じように当てはまるわけではない
- メジャーラボ（主要AI研究所）が優先する市場では、迅速な実行力とモデルへの直接的な統制 が利益をもたらす
- しかし、それ以外の 数千の個別市場 はスタートアップに開かれている
- すべての企業が同じモデルを使える時代には、「最もうまく乗りこなす者(best riders)」が勝つ — つまり、ハーネスの設計・運用能力こそが中核的な競争力となる
9件のコメント
pi はとても軽いので、エージェントツールとして愛用しています。さらに Claude Code や Gemini もつなげようと
pi-shell-acpを作って、便利に使っています。スキルをいくつも作って使っていますが、試せば試すほど自分向けに合わせやすいのがいいですね。Claude Code や Codex などをそのまま使うときは、YOLOモードでビルトインツールは pi レベルまでほぼ全部オフにしています。新機能は、ぴょんまんちで打ち込むように、まず即オフです。私は自分に設定していたハーネス設定をすべて削除しました。
ハーネスは、モデルが進化すればするほど、モデルの性能を制約する要因として働きます。
中途半端なハーネス設定は、むしろより質の低い結果を生み出します。
すでに4.7以下で使われていたハーネス設定は、4.8ではもはや意味がなく、
GPT 5.5でも足かせになるだけです。
本文で言及されているハーネスの構成要素は、単にLLMの知能が高くなるだけで解決するような内容ではありません。
ハーネスの定義が不明確だった時代のハーネスを指しているのであれば、そう考えることもできると思いますが、本文の内容でいうハーネスであれば、今後も継続的に管理していくべき領域のように見えます。
知能の問題というより、モデルは知能とは別に、オーケストレーションやツールといった利用能力も一緒に伸ばしています。もともとオーケストレーション分野は Harness の中核の一つでしたが、それまでサポートする状態になっています。では、現時点で自作のオーケストレーションと純正のオーケストレーションがあるとしたら、どちらを使うのが適切でしょうか？
同感です。一緒に対応開発しなければなりません。
OpenAIのホームページに、harnessingについて公式に発表した投稿があります。OpenAI内部でどのようにharnessingを使ったのか、その経験談とコツを共有する内容です。つまり、OpenAIでさえ自社の内部プロジェクトにharnessingを使っているということです。harnessingは間違いなく必要であり、最終的な実装クオリティに直接影響します。何より、同じクオリティの成果物を実装するのにかかるトークンを半分にまで減らせます。性能と価格の両方を押さえられるのだから、使わない理由はありません。
Opus 4.8で
ultracode effortが追加され、これにより以前は開発者の手作りハーネスモードが担っていた作業を、よりうまく解決できるようになりました。したがって現時点では、これまでお使いだったハーネスモードからオーケストレーション部分を削除するのがよりよいと考えます。同意します。私も 4.7 向けの手作りオーケストレーションや冗長なプランニングの強制は、4.8 では邪魔なので外しました。
ただ、数十万行を何年も保守してきたコードベースでは、ハーネスの本当の価値はオーケストレーションではなく、ultracode が代替できない層（ナレッジグラフ、ドメイン規約、検証の不変条件）にあるので、そのコンテキスト層は残し、本当に独立した区間だけを workflow で並列化しました。
逆に新規プロジェクトなら、あえてハーネスなしで ultracode が適していると思います。結局のところ、「消すか残すか」ではなく、コードベースの年齢や結合度によって分かれる問題のようです.
はい、その通りです。オーケストレーションの部分を除いても、依然として価値があります。