5月23日に「東京生成AIコミュニティ」でHarnessに関する内容を共有しました。ここではそれを記事としてまとめ、みなさんに共有します！
一、ChatからAgentへの進化
私たちは、AIが2022年に登場して以来、チャットボックスの形で現れたことを知っています。ですので、その後2、3年が経つと、みんなはどうやってプロンプトを書けば、より正確な回答を引き出せるのかを一生懸命学ぶようになりました。
また、chat型のAIは一問一答であり、状態が失われることも知っています。では、なぜ2回のやり取りの間に連続性があるのでしょうか？ それは、毎回のやり取りのたびに履歴を持ち込んでいるからです。つまり、「前回までのあらすじ」です。
AIの各種大規模言語モデルの能力が向上し、2025年に向けて発展していく中で、Agentが非常にホットな話題となり、業界では2025年をAgent元年と位置づけています。
そして2026年初頭には、Harnessというもの、あるいは思想が提起されました。ではHarnessとは何でしょうか？
実は、これは具体的なプラットフォームでも、特定の技術でもなく、一組の組み合わせであり、理念であり、思想です。
では何をするのでしょうか？
第一に、ツールを呼び出します。もちろん自分自身が呼び出すのではなく、モデルに呼び出させるよう指揮します。
さらに、長期間動作できるという、大規模言語モデルにはない能力を持たせます。データの永続化メモリ、長期記憶、短期記憶などを含め、大規模言語モデルを長期にわたって動作させることができます。
また、現実の本番環境では、タスク実行時にチェックポイントからの復元能力が必須ですが、それも備えています。
さらに細分化すると、これは大きく2段階です。——ChatからAgentへの移行です。
工学の観点では、最初はPrompt Engineeringで、次にContext Engineeringが提起されました。これらはみなさんにもおなじみでしょう。さらに2026年3月ごろには、Harness Engineeringも提起されました。
それぞれのEngineeringは、段階を上がっていくプロセスであり、扱う問題はますます複雑になっています。
簡単に言えば、Promptは何をするのか？
それはAIにタスクを理解させることです。
Context Engineeringは何をするのか？
AIが内容を受け取る際に根拠を持たせ、無秩序に与えたり、大量の情報を与えたからといって何でも受け入れさせたりしないようにすることです。
そしてHarnessはさらに高度で、AIが複雑な操作を正確かつ制御可能に完了するようにするものです。
だから私のタイトルは「AIのオペレーティングシステム」としたのですが、実際にはHarnessというカーネルを使って構築していくものです。
二、わかりやすい比喩：馬具と馬
わかりやすい例を挙げましょう。この図はみなさん見たことがあるはずです。Xや公众号をよく見ていると出てくるかもしれません。——すべての大規模言語モデルは一頭の馬であり、Harnessはその馬に付ける鐙、鞍、手綱などです。これらを装着して初めて、馬を効果的に制御できます。
考えてみましょう。もしこの馬にそれらがなかったら、馬の役割は何でしょうか？
一つは食べることに使える、ですよね？ 中国では食にこだわりますから、馬肉は食べられます。
二つ目は、手綱がなければ野原を走り回ることはでき、景色も良いでしょう。基本的にはこの2つくらいしかありません。
しかし一度これらの馬具を付けるとどうなるでしょうか？
第一に、交通手段として使える。
第二に、戦争の道具として使える。
さらにオリンピックの金メダルを取ったり、馬術ショーに使ったりもできます。
馬具があれば、できることがどんどん増えるのです。
今のAgent、Harnessと大規模言語モデルの関係は、まさにこの典型です。
大規模言語モデルにHarnessという馬具を付けなければ、好き勝手に暴走し、無駄にお金を使い、しかも回答の質が非常に悪くなります。
一度この馬具を付ければ、私たちの制御下に置けるのです。
三、プロダクション級Agentとコンシューマー級Agentの違い
プロダクション級のAgentとは、OpenAI、Claude、あるいは他のAgentのHarnessそのものではありません。
それらはただの自律型Agentプラットフォームです。つまり、打ち込めばすぐ使え、何をしているのか分からなくても何でもできる、というものです。
それは本番運用向けという意味ではなく、コンシューマー向けの自律型Agentです。
実際には、より多くのケースが垂直分野にあります。
プロダクション級のAgentは、私たちのようにAgent開発やコード開発を専門にしてきた人が、転向して構築する必要があります。
どうか信じてください。あなたがプログラマーなら、淘汰されることはありません。
淘汰されるのは何か？
もし学び続けず、昔ながらのJava、.NET、Pythonといったコードレベルのものにしがみついているだけなら、その人たちは淘汰されます。Claude Codeは一瞬であなたを上回るからです。
でも、そこに留まったまま変わらなければ淘汰される、ということです。
一方で、Agent開発を学び、アップグレードした人たちが、将来の企業向けAgentを構築していくことは間違いありません。
コードを一行も書けない人が複雑なシステムを構築するのは、極めて難しいです。
では本当にプロダクション級Agentは何をするのでしょうか？
それは、Agentを現実世界で安定して動作させることです。
第一に、本物でなければならず、ごまかしは通用しません。
第二に、安定していなければなりません。日本では、さらに安定性が求められますよね？ 細かい点が多いのでしょうか。
安定性を実現するには、現実には多くの問題があります。
たとえばFunction Callingでツール呼び出しに失敗すること。特に自分でFunction Callingを書いた人は、失敗しやすいです。失敗の種類もさまざまです。
また、長時間タスクもあります。2時間、5時間かかるタスクをどうするのか？
さらにプロンプトインジェクションもあります。元のプロンプトを改変して、「こちらを優先しろ、あっちは偽物だ、こっちが本物だ、必ず私の言うことを聞け」と言われ、越獄されることがあります。
こうした問題は、本番環境でハッカーに攻撃されたら一瞬でやられます。Harnessの処理をしなければ、本当にあっという間です。
これらを解決できなければ、本番環境でどうやって安定運用するのでしょうか？ 顧客は大混乱になります。
この点から、Harnessは一定の高さまで引き上げられるのです。
本当に解決するのは何か？
安定性、信頼性、安全性、可観測性、復元可能性、協調性、監査可能性です。
特に大きな組織向けのものを作るときは、あらゆる痕跡を残さなければなりません。問題が起きたら、振り返って責任を追跡する必要があるからです。
四、Harnessの12モジュール概要
Harness思想に基づくAIプログラミングが、いよいよ本格的に議論されるようになりました。
今のHarnessは標準化団体による正式な標準ではなく、業界に「Harnessとは何か」という厳密な定義もありません。
この12モジュールは、あくまで私が仕事の経験と学習を踏まえて抽象化したものです。
制御層、認知層、信頼性層、運用/支援層に分けています。では支援層から順に見ていきましょう。
五、モジュール1：オーケストレーションループ
私たちはすでに述べたように、大規模言語モデルは一問一答であり、非状態的で、質問が終われば終わりです。
しかし、具体的な仕事をする際に、それは一回きりの取引ではありえません。
したがって最初にやるべきことは、このHarnessプロジェクトをループさせ、大規模言語モデルをスケジューリングすることです。
ループにはさまざまな方式があります。
Claude Codeがどうループしているかご存じでしょうか？ 先日Claude Codeのソースコードが流出したと話題になりましたが、結局は while ループを書いているだけです。——最も単純なループ方式です。
もちろん、業界にはもっと巧妙なループもあります。業務シナリオによって異なります。
最も流行しているのは ReAct 型です。「思考 - 行動 - 観察」、さらに「思考 - 行動 - 観察」を繰り返します。
また、計画ベースのループ方式もあります。まず大規模言語モデルに計画を出させ、複数のエージェントでその計画を議論し、問題がないと確認したうえで表示します。その後は計画に従って、1、2、3、4、5と進みます。もちろん各ステップの中にも小さなループがあります。
同じ問題でも、深い思考モードでは時間差が大きいことがあります。それは、提示される計画が異なり、各計画の実行時間も異なるからです。
Claude Code、Codex、ChatGPTであっても、自律型エージェントではありますが、まだプロダクション級ではなく、コンシューマー級です。
プロダクション級でよく使うループには何があるでしょうか？
一つは、Claude Codeの while ループのような単純な継続ループです。
もう一つは、ワークフローに基づくループです。企業レベルでは段階ごとに処理があり、承認や引き継ぎが必要になるため、ワークフロー型のループが必要です。
さらに、Actor モデルに基づくものもあります。1つのActorが1つのアクションを担当する方式で、たとえば AutoGen は Microsoft のAgentフレームワークで、この方式でループします。
どのループを使うかは業務次第です。どんな場面にも万能なループがあるわけではなく、業務に応じて定義する必要があります。
ループを作る際に注意すべき点がいくつかあります。
第一に、必ず最大ループ数を設定することです。AIには幻覚があり、不確定だからです。AIだけでなく、後で人間も不確定だという話もします。
トークン上限、最大試行回数、開発界隈での並列計算、複数スレッドの並列実行などもあります。直列にすべきところは直列に、並列にすべきところは並列にします。
また、人に引き継ぐべき場面では必ず人に渡します。重要な節目では人へ必ずエスカレーションするべきです。
これらはループの中で注意すべきポイントです。
六、モジュール2：ツールシステム
2つ目のモジュールはツールシステムです。
AIの能力は非常に限られており、学習が終わった時点でその知識は止まります。
「今日は何月何日？」と聞くと、多くのAIは訓練の締め切り日のまま返してきます。
現在の天気などは知りません。知っている情報は、ツールを追加したものだけです。
今のChatGPTには「今日は何日？」「天気はどう？」といった能力がありますが、それは裏側でツールを呼び出しているからです。
プロダクション級では、必ずツールがあります。なぜなら企業内部のプライベートデータがあり、それらをさまざまなツールとして使えるようにするからです。
ツールにはどんなものがあるか、簡単に挙げましょう。
最初は Function Calling です。これは初期の各モデル企業が自社モデルを作る際にすでに備えていた能力です。
悲しいのは、各社の呼び出し方式が異なり、統一されていなかったことです。
Anthropic はかなり抜け目がなく、ダリオは少ししたたかですが、非常に賢い人です。そこで同社は MCP を打ち出しました。
「ツールを呼び出すなら、世界中のAIに共通の規格を持たせよう」——これは開発者にとって非常に親切です。
開発者は「このプロトコルを出してくれて助かった。コードは一度書けばいいし、モデル側で下層の違いを吸収してくれる」と考えます。だからAnthropicは良いと言われるのです。このツールを推進したからです。
その後、Google は A2A を出しました。Anthropic がツールプロトコルを出したなら、こちらはエージェント間の通信プロトコルである A2A を出す、というわけです。
これらのプロトコルは今も発展しています。今日見たからといってそれで固定ではありません。AIはまだ初期段階であり、進化し続けているからです。
最後は Skill です。ネットで共有する際にも考えましたが、本質的には外部ツールではありません。
Skill は最終的に一組のプロンプトに変換され、大規模言語モデルに与えられます。
ただし Skill には専門能力があり、使い方はまるでツールのようです。そのため、ここではツールとして扱っています。
もちろん、コンテキストのプロンプト組み立て側に置くこともできます。それでも構いません。
先ほどMCPにも触れましたが、実際に何を解決しているのでしょうか？
各フレームワークが個別にツール接続していたものを、オープンで相互接続可能なプロトコルに変えることです。
これはクライアントが大規模言語モデルを呼び出すときに与える能力です。
ツールシステムを作るうえで、権限は非常に重要です。
権限の領域は、昔から悪用されやすい脆弱性でした。
ですからツールを作るとき、特にシステムを作った場合、異なる役割ごとに使えるツール権限が異なります。
たとえばAI製品を使うとき、ある情報は見えず、財務担当だけが見える、といったことがあります。給与は見えないですよね。
したがって、ツール呼び出し時には各ロールの権限をここで統一管理する必要があります。承認方法も含めて、権限がない呼び出しには承認や拡張が必要です。最も厳格なものはサンドボックス隔離を行います。
さらに、各ツール呼び出しの入力・出力、呼び出し時間なども追跡しなければなりません。
トラッキングと監視は生命線です。システムを作るなら、これは最も基本的な生命線です。
特にAI製品では、AIは大規模言語モデルに対して人間のような振る舞いをするため、どう考えているか分かりません。
だから、AIプロジェクトではトラッキングをしっかり行うことが非常に重要です。
七、モジュール3：構造化出力
大規模言語モデルには幻覚があります。
同じ質問を、同じモデルに3秒空けて聞いただけでも、結果が変わることがあります。
人間の言語を元に学習しているので、典型的には言葉の連鎖であり、次に何が続くか分からないからです。
しかし、私たちがコードを書くときや企業向けアプリケーションでは、出力が不確定であれば誰も受け入れられません。
今日100円預けたのに、50円しか入金されていなかったらどうでしょう？ 銀行口座に50円しかなかったら、ありえませんよね。
あるいはMCPを使って支払いを行い、10円支払ったのに相手が20円受け取る、そんなこともありえません。
だからこそ、この構造化出力は、Agent同士、あるいは私たちと大規模言語モデルのコミュニケーションにおける中核なのです。
入力と出力は必ず構造化しなければなりません。構造化とは、すなわち確定性を意味します。
もちろん構造化だけではなく、PydanticのようなPythonのバリデーションライブラリもあります。返ってきた結果は検証しなければなりません。
さらに高度な方法として、モデルの微調整を行うときに、最初から欲しい構造化形式を出すように訓練することもできます。
前者の2つは、どんな場面でも使える基本手段です。
ツールを呼び出す際には必ず検証し、合っていなければ再試行を追加します。
大規模言語モデルが良くなるほど成功率は上がります。1回失敗しても、もう1回再試行すれば成功率は大きく向上することがあります。
文脈を使って修復できる、あるいは自動修復できるなら、ロールバックする必要はありません。
それでもダメなら人に渡し、人が判断します。AIやシステムはその代わりに意思決定します。
八、モジュール4：メモリシステム
次はメモリシステムです。これはかなり重要なシステムです。
大規模言語モデルはステートレスなので、何も覚えていません。
しかし、だからといってすべてを覚えさせることもできません。いくら優秀な大規模言語モデルでも、トークンウィンドウがあるからです。
つまり、どれだけお金持ちでも、ビル・ゲイツでも、私たちだってこのウィンドウには注意しなければならないのです。さもないと全部なくなります。
Agentに毎回ゼロからやり直させない。要するに「ちゃんと覚えておけ、必ずこの件を覚えておけ」ということです。
ではどうするのか？ 実際には長期記憶と短期記憶に分けます。
長期記憶とは、そのタスクやプロジェクトが何をするものか、成果物は何か、といったマクロなデータを保存する場所です。
短期記憶とは、この会話や直近数分の情報を保存するものです。
たとえば「3分後に何をするか」という指示があれば、メモリシステムがそれを覚えておく必要があります。
現在時刻がいつで、3分後がいつなのかは、当然短期記憶に入れます。
ただし3分後になったら、その短期記憶に残した内容はまだ意味があるのでしょうか？ 意味がなくなるかもしれません。
ですから3分後には、その短期記憶を削除してもよいのです。
このようなものについては、短期記憶と長期記憶を制御し、有効な記憶だけを保存するシステムを構築する必要があります。
難しいのは、保存するかどうかではありません。
保存したものが役に立つかどうか、これがメモリシステムの核心です。
全部覚えるのもダメ、全部覚えないのもダメ。
しかし、ときには内容の腐敗を防がなければなりません。
実際にはもう使えないのにずっと保存し続け、やり取りのたびに持ち込むのは、トークンの無駄です。
九、モジュール5：コンテキスト管理
コンテキスト管理は、モデルが今回のやり取りで何を見たかを決めます。
「メモリシステムがあるなら、コンテキスト管理はもういらないのでは？」と思うかもしれません。
しかしコンテキスト管理とメモリは異なります。こう考えると分かりやすいです。
メモリは倉庫、あるいはその倉庫への出し入れを処理する仕組み。プロンプトは、現在の会話ウィンドウのオーケストレーターです。
これはメモリ倉庫全体とは別物です。したがって、1回のプロンプトのコンテキストウィンドウを組み立てる役割だけを担います。
コンテキストを組み立てる際には、長期・短期のメモリDBのデータを見に行くこともありますし、RAG用のDBやリレーショナルデータベースを見ることもあります。
実装時には、次の4つの操作が必要です。
第一はトリミング、別名圧縮。
第二は検索です。RAGでよく使うものですが、Harness全体の中では、これはこうした用途で有効です。
さらにフィルタリング。
そしてリランキング。
コンテキストを組み立てる全体工程では、これら4つの操作を使ってプロンプトの価値を高めます。
ここで注意すべき災害が2つあります。
第一の災害は、「何でも役に立つ気がするから全部入れる」というものです。
もちろん不可能ではありませんが、研究によれば、1回の会話ウィンドウに入る内容が多すぎると、大規模言語モデルは前半と後半に注目し、中間部分を見落としやすくなります。
内容が増えるほど、モデルは歪み、脱線し、不確定な出力を生みやすくなります。
ですから、多ければ多いほど良いわけではありません。
ソフトウェア工学の観点からは、極限まで少なくすることが大事です。そうすれば結果は非常に正確になります。目的を達成できれば十分で、極限まで少なくするべきです。
中国には文言文がありますよね。何百字もの内容を非常に短く表現できます。文言文プロンプトの効果を試してみるのもよいでしょう。
第二の災害は腐敗と崩壊です。
無効な情報を入れると、大規模言語モデルは脱線し、全体の効果が非常に悪くなります。
ですから、Memory と Context は必ず区別しなければなりません。
一つは倉庫、もう一つは現在の会話ウィンドウです。
十、モジュール6：プロンプト
またプロンプトが出てきました。不思議ですよね。
実はHarnessにおけるプロンプトは、単なる一文ではありません。
私たちはプログラムが動く前、特に高級言語ではコンパイルを行うことを知っています。
ここでも同じで、このテキストをコンパイルして大規模言語モデルに与えるのです。
先ほどのように、平易な説明を精密な文言文に変換して大規模言語モデルに与える、というのも同じ理屈です。コンパイルしているのです。
ではどうコンパイルするのか？ いくつか方法があります。
まず、最初に学ぶのがシステムプロンプトです。
システムプロンプトはモデルの基本能力を指揮する場所なので、きちんと組み立てる必要があります。
次に、特に業務に基づくAgentでは、その目標を明確にし、何をするタスクなのかを明確にしなければなりません。
また、プロンプトをコンパイルする際には、今回の対話でどのツールが使えるのかも決めます。
現実のツールは非常に多いですが、今回の対話で使うツールは必ず限られています。
1000個、100個、10個のツールを与えるなら、10個のほうが確実に正確です。
1時間のやり取りで1000回対話する場合、各対話で大規模言語モデルに渡すツールは異なるかもしれません。なぜなら、毎回の対話の目的が異なるからです。
次に、コンテキスト、つまりメモリシステムからデータを検索し、RAGのように使います。
最後に、結果出力の構造を決めます。
プロンプト組み立ては、この観点に集中します。
「何が入ってくるか」「何が出ていくか」「プロンプトは何か」「呼び出せるツールは何か」——この軸をしっかり押さえることが重要です。
プロンプトを設計しただけでは終わりではありません。テスト可能性にも注意する必要があります。
たとえば、今回の起動プロンプトがどんな内容で、結果がどうだったかをすべて記録しておく必要があります。
キャッシュも重要です。システムプロンプトは同じAgent内では通常変わりません。
そうすると大規模言語モデルはそれをキャッシュし、コストを少し抑えられます。
大規模言語モデルでは、キャッシュ利用時と通常の入出力では料金が異なるからです。
したがって、システムプロンプトが大きい場合は、できるだけキャッシュしやすいようにしておくべきです。
さらに、説明可能性も必要です。システムをより最適化するためです。
十一、モジュール7：状態とチェックポイント
先ほど、プロダクション向けAgentは長時間動作すると述べました。
いつ問題が起きるか分かりません。
そこで状態とは、その時点の状態を保存し、どの状態からでも復元できるようにする能力です。
もしあなたのエージェントが一回きり、二回きりの処理なら、これは必要ありません。
Harnessエンジニアリングは、Agentシステムを作るなら12モジュールすべてを必ず使わなければならない、という意味ではありません。
違います。これは積み木のように柔軟に組み合わせるもので、状況に応じて何を使うか使わないかを選びます。
このモジュールは、長期タスクやデータ量が多いタスクに適しており、進捗を保存しておけば、途中で落ちても追いつけます。
第一に、実行時間が長いこと。
第二に、人の承認が必要なケースです。
AIが画面を出したり、SMSを送ったりして、人による審査を求めることがあります。
その人が10日間休暇中なら、戻ってきてから承認することになるので、その10日間は状態を保存しておく必要があります。
もちろん保存期間は5日でもよく、自分で最大上限を決めて構いません。
人の介入がある場合は、必ず介入前に状態を保存しなければなりません。
また、バックエンドの非同期処理もあります。非同期処理では、どれが先に戻ってくるか後に戻ってくるか分かりません。
そのため、この状態も保存が必要です。
復元が必要なデータも処理しなければなりません。
基本的に、状態とチェックポイントは、実行中のデータをいつでも停止・復元できるようにし、さらに保存して回帰できるようにするものです。
時間の巻き戻し、つまり再実行も可能です。
私は以前マーケットで取引していたとき、あるシステムでリプレイを作りました。
今日は3,000万件の取引を行い、それを記録しておきます。新しいシステムが出たら、その3,000万件を再生して、新システムの本番投入に問題がないかを確認するのです。ここでも使えます。
時間のシミュレーションや巻き戻しなども、同じ考え方です。
十二、モジュール8：エラー処理
コードを書くときも、大規模言語モデルも間違えますし、私たちプログラマーはなおさらミスをします。
ですからエラー処理は、どのシステムにも必須です。
最も単純なエラー処理は Try Catch ですが、Harnessでは単なる Try Catch ではありません。
それは、システムを復元可能にすることが中心です。
すでにエラーが起きたら、当然復元しなければなりません。単なるアラートや通知の仕組みではありません。すでにエラーが発生しているからです。
Harnessのエラー処理システムでは、エラーは多くの種類に分かれます。
最も一般的なのは一時的エラーです。たとえばネットワークの揺らぎや429などです。
これは大丈夫で、次に試せばよいのですが、どのエラーが長いのか短いのか、どう再試行するのかをきちんと区別する必要があります。
次に構造化エラーです。たとえば大規模言語モデルが返してきた結果が間違っている場合、その結果が間違っているなら、このやり取りを再スケジュールして最初からやり直します。
それでも間違っているなら、指数バックオフの再試行を行います。たとえば1秒後に失敗したら1秒後に再試行し、また失敗したら3秒、さらに失敗したら5秒や7秒にするなどです。
再試行戦略は必ず必要で、エラーごとに異なります。
また、ビジネスロジックのエラーもあります。たとえば、注文数量がマイナスになったら、お金を払う側になってしまいます。
こうしたエラーもHarnessに含まれます。なぜなら、すべてAgentの仕事だからです。
こうした境界をうまく抑えられず、エラー処理ができなければ、相手が商品を買ったのに300元を振り込んでしまう、といったことも起こりえます。
ですのでAgentでは、この領域を備えており、ビジネスロジックのエラーもすべて含めて考える必要があります。
この点は、コードを書いたことがある人ならどう処理するか分かるはずです。ここでは深くは説明しません。
今話しているのはすべて理論ですが、これらの理論は今やさまざまなAI Agentで実際のコードとして実装されています。
具体的なコードの段階になったら、みなさんに具体例を挙げることができます。
十三、モジュール9：ガードレール
次はHarnessの中でもかなり特徴的なもの、ガードレールです。
ガードレールは何をするのでしょうか？ AI Agentシステムの中核、安全の中核です。
ちょうどオペレーティングシステムを作るときに、それぞれのOSにウイルス対策やネットワーク防御が入っていたり、外部で別途ウイルス対策ソフトを入れたりするのと同じです。
つまり、セキュリティはとても重要です。
では、通常どのようなものをガードレールで守るのでしょうか？
第一に入力です。
誰が入力したのか分からず、その内容が必要なデータに合致しているかどうかを検知する必要があります。
第二に、コンテキスト組み立て時です。
データベースやRAGからデータを取り込む際、それらが汚染されていたら、大規模言語モデルに渡すのは非常に危険です。したがってチェックが必要です。
次にツール呼び出し時です。
キーにアクセス権があるか、あるいはそのキーが大規模言語モデルに渡されたのか、別のプロセスで保存されたのか、などを確認しなければなりません。
キーの乱用や、ツール呼び出し時のパラメータなども防御対象です。
さらに出力の防御もあります。
広く言えば暴力やポルノなどは大規模言語モデル側ですでに防いでいますが、垂直領域では、あなたの業務データの権限まではモデルは知りません。
そのデータを出してしまうかもしれないし、そもそもその人に閲覧権限がないかもしれません。
あるいはプロンプトインジェクションで越獄され、その人が見えてしまうこともあります。
ですから、こうしたものも保護しなければなりません。
つまり、これら4層で防御します。
また、高リスク操作にもガードレールが必要です。
一つはShell端末コマンドの実行です。特に手間を省こうとして、大規模言語モデルにShellを生成させ、そのままツールで実行させると、思わぬ事故が起こることがあります。
他にもSQLインジェクション、ファイル操作、外部取引、特に金銭を伴う取引は注意が必要です。
たとえばCodexでは、コードを書く際にフォルダを指定すると、そのフォルダの外には出られません。フォルダ内では自由にできますが、他の場所のフォルダを操作することはできません。
これがCodexにおけるガードレールの一例です。
十四、モジュール10：検証とフィードバック
検証とフィードバックは、いわばクローズドループです。
このAgent、あるいは今回の回答が信頼できるのか、次にどう直すのか、どう改善して次のシステムをより良くするのか、ということです。
基本的には3つの側面があります。
第一はオフラインテストです。
本番前や新機能開発後には、必ずオフラインでのテストが必要です。本番環境でいきなり試すわけではありません。
たとえば新しいAgentを作った、あるいはアップグレードしたとします。プロンプトはまだ正確か？
モデルをアップグレードしてモデルIDだけ変えた場合、以前と何も変わっていなくても、正確さはどうか？
こうした評価システムを作って結果を確認し、問題があれば改善します。
回帰テストを行い、モデル切り替えなども含めて対応します。
第二はオンライン評価です。
先ほど、なぜリプレイできるのか、すべてのトラフィックを録音しておくのかを話しました。
ここでも同様で、実際のトラフィックを——もちろんリプレイ用ではなく評価用として——抽出します。
3秒以内、時間ベース、件数ベース、たとえば10回リクエストごとに1回、などのサンプリングを行い、その結果を評価します。
さらに人によるフィードバックもあります。
記録したうえで人が介入すると、「このAgentのこのプロンプトは本当に良い、100回動かして問題ない」というケースもあれば、
「これは100回のうち10回エラーが出た、成功率90%では低い」ということもあります。
人がこうした情報をすべて記録して評価DBに入れれば、評価DBはある程度、アラートを出すべきところは出し、プロンプト工程の最適化が必要なところは最適化し、良い分岐を通して悪い分岐を避けるようになります。
そのため、人による介入フィードバックが必要なのです。良い検証・フィードバックシステムを作る際にも、これらは含まれます。
これは基本的に、日常のプロセスにおけるトラッキング、監視、ログなどを記録し、それを分析し、分析後に検証DBとしてまとめて、後の工程で使うという実践です。
十五、モジュール11：マルチAgentオーケストレーション
次はマルチAgentオーケストレーションです。
主流のAgent SDKにはこの機能がありますが、SDKごとに能力は多少異なります。
実際、複数のAgentに仕事をさせるというのは、本質的には分散システムであり、それぞれが役割を分担し、1つのAgentが終わったら次のAgentにデータを渡します。
オーケストレーションのパターンはいくつかあります。よく使われるモデルを簡単に挙げます。
たとえば委任パターンです。
自分がリーダーで、開発者、テスター、プロダクトマネージャーがいる。仕事を割り振って「やってくれ」というものです。これが委任パターンです。
並列パターンでは、同じタスクに対して2人の役割が同じであれば、両方にやらせ、結果の良いほうを採用します。
議論・ディベートパターンは、特に意見が分かれるものに向いています。ブレーンストーミングのように、A、B、Cと進めます。
まずAが話し、その結果と問題点を必ずBに渡します。Bは自分の考えも踏まえてAの内容と自分の内容を組み合わせて話します。CはAとBの内容を踏まえて話し、その後AがBとCを踏まえて話す、というように回していきます。
次はハンドオフパターンです。
実は上にもハンドオフはありますし、ループの中でも引き継ぎがあります。
ただここでは、特に人への引き継ぎを強調しています。必ず人に引き継ぐべきです。外部システムでも、コンソールでも、スマホでも、必ず人に引き継ぎます。
OpenAIやAnthropicはこの点をかなりうまくやっています。会話の途中で重要な局面になると、「この制御権をあなたに渡します。これを実行してよいですか？」と出てきて、あなたに決定させます。Claude Codeにもあります。重要な操作は人に出して承認させる必要があるからです。
また、1組のAgentを別の組のAgentのツールとして呼び出すこともできます。
この能力は必須です。大規模システムを作るなら、1つのAgentだけでは不十分で、3000個のAgentがいるかもしれません。
50個1組、または80個1組といった具合に、それぞれが相互に呼び出し、依存関係を持つことがあるからです。
すべての機能はツール化できる。
AI処理をするとき、一度ツール化すれば、大規模言語モデルはすべて呼び出せるようになります。
一度ツール化してしまえば、大規模言語モデルは1回の問答でそれを利用できます。
ですから、ツール化は暗黙の制約なのです。
もう一つ、私自身とても深く感じている点があります。
未完了のタスクを抱えたまま、3つのマイクロタスクを一気に完了させようとしないこと。
今のAIは非常に強力で、1回の問答で解決してしまうこともあるからです。
したがって、タスクが来たら、いきなりAgentを作るのではなく、まずはChatGPTの最良モデルやClaude Codeのモデルで直接試してみて、効果を見てください。
もし効果があなたの期待から大きく外れるなら、もっと構成を工夫して対処します。
それほど悪くないなら、プロンプトを最適化するだけで十分で、複数Agentは不要かもしれません。
つまり、Agentが多ければ多いほど良いわけではありません。
みなさん、今の自律型Agentはかなりコストが高いことをご存じでしょう。
トークンを大量に消費します。なぜなら、「あなたのために、私のために」「あなたが私に、私があなたに」とやり取りし、無駄な会話が増えるからです。
先ほど話した記憶の要約も、すべてAgentが要約しているのであって、人が延々と話したあとに人間が要約して記憶庫に入れているわけではありません。
別のAgentが要約しているのです。
こうしたものは少ないほどトークン消費も少ないです。
ですから、Agentを使わなくても解決できるなら、対話で解決できるなら、できるだけAgentを使わないようにするべきです。
十六、モジュール12：ランタイムとライフサイクル
最後のモジュールです。機能はそろったので、それらをまとめて動かすためのものが必要です。それがランタイムとライフサイクルです。
これがシステムの起動、実行、ホスティング、隔離、スケールアウト/スケールインなどを担います。
どのモジュールに何をさせるかを指揮するのです。もちろん、いつ停止するか、いつ休止するか、といった一連の管理も含まれます。
例を挙げると、起動時にはまず多くの設定パラメータを読み込む必要があります。
どのパラメータがツール用なのか、どれがシステムプロンプト用なのか、どれがメモリシステム用なのか、どれは今すぐ読み込む必要があるのか、どれは後で非同期に読み込めるのか、などをここで計画しておきます。
このランタイムの核心機能は、環境を再現可能にすることです。
つまり、一度電源を切っても再起動でき、起動後の挙動が変わらないことです。
電源を切って再起動したらブルースクリーンになった、というのでは困ります。
もしブルースクリーンになるなら、そのAgentの設計が良くないということです。
第二に、安全隔離です。
安全は非常に重要です。特に大規模言語モデルは人間のような能力を持つため、何をするか分かりません。
さらにサンドボックスの再利用もあります。ただし、状態とチェックポイントがあれば、サンドボックスをできるだけ再利用してトークンを節約できます。
サンドボックスとは隔離や保存など、さまざまな場面で使える環境の指標です。
十七、まとめ
Harnessの本質を、最初の話に戻して言うと、これはプラットフォームでもなければ、どこかの会社が出したソフトウェア製品でもありません。
思想と言ってもよいし、デザインパターンと言ってもよいです。
それは、Agentを持つシステムをどう開発するかを導くものです。
しかしより正確には、従来のソフトウェア開発の考え方と、人間のようなシステムを融合させるためのフレームワークに近いのです。
そういう概念だからこそ、プロダクション級AI Agentのオペレーティングシステムのようなものになるのです。
あらゆる面をほぼ網羅しています。
最終的な目的は何でしょうか？
制御可能、復元可能、可観測、統治可能、進化可能です。
そうすれば、大規模言語モデルがどれだけ進化しても、Harnessは変わりません。
最初に示した「ChatからAgentへ」という図をさらに単純化すると、実際にはプロンプトエンジニアリングから、AIを本当にランタイムとして動かすための工学へと進む、ということです。
それはもはや一回きりの取引ではなく、長期間動作可能なプロセスなのです。
最後に大規模言語モデルの比喩に戻りましょう。
大規模言語モデルをうまく動かすために、12のモジュールを設計し、Harnessの馬具のようにこの馬に装着します。そうすると、この馬の役割はどんどん増えていきます。
今はこうでも、明日には別の馬具に変えたり追加したりすれば、貨物を引くこともできる。さらに変えれば、離地することもできる。
大規模言語モデル自体の能力は変わらなくても、Harnessの仕組みは柔軟に組み立てて発展させることができます。荷車を引くことだってできます。できることは、できる限り何でもできます。
ですから現実の世界ではこうなります。異なる大規模言語モデルは盛衰し、能力も盛衰します。
しかし、私たちが開発したHarnessは、どの馬にも同じではないでしょうか？
ツール群を作ってしまえば、相手が誰に変わっても、それが私の価値であり、このプラットフォームの価値であり、そこに蓄積されていくのです。
(Translated by GPT)
元のリンク：https://mp.weixin.qq.com/s/aEoUFP7D46IFKmUWPbpxHg?token=639931501&lang=zh_CN&wt.mc_id=MVP_325642