https://knightli.com/ja/tags/harness/ Recent content in Harness on KnightLiブログ Hugo -- gohugo.io ja Mon, 27 Apr 2026 08:19:02 +0800 https://knightli.com/ja/2026/04/27/ralph-multi-agent-long-running-ai-workflows/ Mon, 27 Apr 2026 08:19:02 +0800 https://knightli.com/ja/2026/04/27/ralph-multi-agent-long-running-ai-workflows/ <p>最近 coding agent を使っていると、すぐにひとつの現実的な問題にぶつかります。<strong>AI は確かに仕事をしてくれる。でも、どうすれば何時間も動かし続けても途中で脱線せず、要件を忘れず、同じ作業をやり直さずに済むのか。</strong></p> <p><code>Ralph</code> やマルチエージェント協調をめぐる議論で本当に重要なのも、まさにこの点です。単にどのモデルが強いかを比べる話ではありません。より実用的な問いは、<strong>長いタスクでも AI が安定して動けるように、どうワークフローを設計するか</strong> です。</p> <p>この問題を分解すると、よく出てくるルートは大きく 2 つあります。</p> <ul> <li><code>Ralph</code> 方式：新しいセッションを繰り返し起動し、ファイルシステムで文脈をつなぐ</li> <li>マルチエージェント方式：リード Agent が調整し、子 Agent が分担して実行する</li> </ul> <p>もっと平たく言えば、問われているのは「どのモデルが強いか」ではなく、「どう AI を組織して、継続的に成果を出す小さなチームのように動かすか」です。</p> <h2 id="01-なぜ長時間タスクは崩れやすいのか">01 なぜ長時間タスクは崩れやすいのか </h2><p>短いタスクでは、多くの問題は表に出ません。指示を 1 つ出し、モデルが数ファイルを読み、少しコードを書き換えれば終わります。</p> <p>ところがタスクが長くなると、問題が一気に表面化します。</p> <ul> <li>会話が伸び続けてコンテキストが膨らむ</li> <li>初期の要件が新しい情報に押し流される</li> <li>ひとつの Agent が設計、実装、テストまで全部抱える</li> <li>明確な受け入れ確認がないと、「終わった」と「終わったと言っているだけ」が混ざる</li> </ul> <p>そのため、長時間 AI を動かすときに本当に問われるのは単発の出力性能ではなく、<strong>タスク分割、状態の受け渡し、役割分担、フィードバックループ</strong> です。</p> <h2 id="02-ralph-方式長いタスクを短いラウンドに分ける">02 Ralph 方式：長いタスクを短いラウンドに分ける </h2><p><code>Ralph</code> の考え方は、まず「コンテキストがどんどん汚れていく」問題を解くのに向いています。</p> <p>やっていることはシンプルです。</p> <ul> <li>ループで新しい agent セッションを何度も起動する</li> <li>各ラウンドでは十分小さなタスクを 1 つだけ扱う</li> <li>ラウンドをまたぐ状態は会話ではなくファイルに置く</li> </ul> <p>利点は明快です。毎回 fresh context から始まるので、1 ラウンドごとの集中が保ちやすく、過去の履歴に引きずられにくくなります。</p> <p><code>Ralph</code> 系のプロジェクトを見たことがあるなら、構造はかなり一貫しています。</p> <ul> <li>現在のタスクは構造化ファイルに書く</li> <li>途中の学びは進捗ファイルに残す</li> <li>コードの変化は git 履歴に残す</li> </ul> <p>つまり <code>Ralph</code> は、1 つの Agent に「全部を永遠に覚えさせる」ことを目指していません。記憶を意図的に外へ逃がし、セッションそのものを軽く保とうとします。</p> <p>この種の方式は、特に次のような条件で相性がいいです。</p> <ul> <li>作業がすでに小さな story に分けられている</li> <li>各 story が 1 つの context window に収まる</li> <li>プロジェクトに tests、typecheck、その他のチェックがある</li> </ul> <p>これは <strong>AI を一歩ずつ安定して前に進めるにはどうするか</strong> という問題への答えです。</p> <h2 id="03-マルチエージェント方式1-人では抱えきれない仕事を分担する">03 マルチエージェント方式：1 人では抱えきれない仕事を分担する </h2><p>もうひとつのルートがマルチエージェント協調です。</p> <p>この種のワークフロー設計でより有望なのは、リード Agent が自分で全部やるのではなく、調整役に回り、ほかの Agent が実装、テスト、確認、受け入れを分担する形です。</p> <p>ここが <code>Ralph</code> との大きな違いです。</p> <ul> <li><code>Ralph</code> は直列の反復に近い</li> <li>マルチエージェントは並列の分業に近い</li> </ul> <p>タスクの中に自然な役割分担があるなら、マルチエージェントのほうが扱いやすくなります。たとえば次のように分けられます。</p> <ul> <li>ひとりがタスク分解と実行計画を担当する</li> <li>ひとりが実装する</li> <li>ひとりがテストして検証する</li> <li>ひとりが結果が最初の要件に合っているか見直す</li> </ul> <p>大事なのは、ただウィンドウを増やすことではありません。価値があるのは役割を分離することです。もともと 1 つの Agent に押し込んでいた仕事を、より明確な段階に分けられます。</p> <p>役割の境界がはっきりすると、いくつかの問題が軽くなります。</p> <ul> <li>書く人とレビューする人を分けられる</li> <li>テストする側が毎回ゼロから要件を再構築しなくていい</li> <li>リード Agent が実装詳細に埋もれにくい</li> </ul> <p>これは <strong>AI を小さなチームのように協調させるにはどうするか</strong> という問題への答えです。</p> <h2 id="04-本当に重要なのは並列化ではなくどう分けるか">04 本当に重要なのは並列化ではなく、どう分けるか </h2><p><code>Ralph</code> を使うにしてもマルチエージェントを使うにしても、見落とされやすいのはこの点です。<strong>大事なのは Agent の数より、ワークフロー設計の質です。</strong></p> <p>タスク分解が悪ければ、Agent を増やしても混乱を並列化するだけです。</p> <p>より安定しやすい分け方には、だいたい次の特徴があります。</p> <ul> <li>1 タスクに 1 つの明確な目標がある</li> <li>1 役割に 1 種類の出力責任がある</li> <li>各ラウンドに明確な完了条件がある</li> <li>前のラウンドの成果が次のラウンドでそのまま使える</li> </ul> <p>たとえば「機能を全部作って」と一気に投げるより、次のように段階を切るほうが安定しやすいです。</p> <ul> <li>まず要件と境界を分ける</li> <li>次に実装を分ける</li> <li>次にテストを分ける</li> <li>最後に受け入れ確認を独立させる</li> </ul> <p>この分け方の利点は、問題が起きたときに、理解、実装、テスト、受け入れ基準のどこに原因があるのか見つけやすいことです。</p> <h2 id="05-なぜ受け入れ確認が重要なのか">05 なぜ受け入れ確認が重要なのか </h2><p>多くの AI ワークフローが崩れるのは、前半で何もしていないからではありません。最後に、本当に独立した確認ステップがないからです。</p> <p>長いタスクでは、「結果が生成された」と「その結果が本当に使える」のあいだに、かなり大きな差があることがよくあります。</p> <p>だからこそ、開発と受け入れを分けて考える方向が重要です。複雑な仕組みにしなくても、少なくとも次の問いは独立して投げる価値があります。</p> <ul> <li>最初のタスクを本当に完了しているか</li> <li>表面だけ直して根本原因を残していないか</li> <li>テストが都合のいい経路だけを見ていないか</li> <li>上流の要件を途中で勝手に変えていないか</li> </ul> <p>この層が欠けると、AI は長いフローの中で何度でも「成功した」と自己申告しがちです。</p> <h2 id="06-どう選ぶべきか">06 どう選ぶべきか </h2><p>手早い目安としては、次のように考えられます。</p> <ul> <li>いちばん痛いのがコンテキスト肥大化や長セッションの失焦なら <code>Ralph</code></li> <li>いちばん痛いのが 1 つの Agent に役割を詰め込みすぎていることならマルチエージェント</li> </ul> <p>もう少し具体的に言うと、</p> <ul> <li><code>Ralph</code> は、流れが明快で、粒度が細かく、ラウンド単位で進めやすい仕事に向く</li> <li>マルチエージェントは、役割分担が明確で、並行処理や相互検証が必要な仕事に向く</li> </ul> <p>実際には、この 2 つは対立するものではありません。むしろ成熟したやり方は組み合わせです。</p> <ul> <li>外側は <code>Ralph</code> のような反復ループで大きなタスクを進める</li> <li>内側は各ラウンドでマルチエージェントを使い、調査、実装、テスト、受け入れを分担する</li> </ul> <p>こうすれば、長いコンテキストの制御と、1 ラウンド内の協調効率を両方取りにいけます。</p> <h2 id="07-ひとことでまとめると">07 ひとことでまとめると </h2><p>これらの方法が重要なのは、<code>Ralph</code> やマルチエージェントそのものを単独で推しているからではありません。むしろ、ひとつの現実的な事実をはっきりさせているからです。<strong>AI を長時間安定して働かせる鍵は、モデル単体の強さよりも、コンテキスト、タスク、役割、受け入れ確認をどう設計したかにある。</strong></p> <p>すでに <code>Claude Code</code>、<code>Codex</code>、そのほかの coding agent に長めの実タスクを任せ始めているなら、こうしたワークフロー発想は「もっと強いモデルに替える」より優先して学ぶ価値があります。</p> https://knightli.com/ja/2026/04/10/anthropic-harness-agent-os/ Fri, 10 Apr 2026 09:22:56 +0800 https://knightli.com/ja/2026/04/10/anthropic-harness-agent-os/ <p>Anthropic は最近、Harness のエンジニアリング実践に関する記事を公開しました。表面的には製品の実装について話しているように見えますが、本質的には長期的な質問に答えています。</p> <p>**モデルの機能が変化し続ける場合、エージェント システムのどのレイヤーが安定している必要があり、どのレイヤーが迅速な置き換えを可能にする必要がありますか? **</p> <h2 id="核心判断">核心判断 </h2><p>この記事に関する私の基本的な理解は、エージェント インフラストラクチャがますます軽量の <strong>エージェント OS</strong> に近づいていくだろうということです。</p> <p>焦点は「今日の最良のプロセスをハードコーディングする」ことではなく、「長期的に安定したシステム抽象化を定義する」ことにあります。</p> <h2 id="これがなぜ重要なのでしょうか">これがなぜ重要なのでしょうか? </h2><p>多くのエージェント フレームワークに共通する問題は次のとおりです。</p> <ul> <li>モデルの一時的な欠点を永続的な構造に統合します。</li> <li>プロンプトプロジェクトをシステム境界と間違えた</li> <li>長期的な依存関係として一度有効なパッチを作成する</li> </ul> <p>モデルはより強力になり、今日合理的なパッチが明日には技術的負債になる可能性があります。</p> <h2 id="人間的ソリューション-コンクリートハーネスからメタハーネスへ">人間的ソリューション: コンクリートハーネスからメタハーネスへ </h2><p>このアイデアは、固定された配置方法を約束するものではありませんが、安定したインターフェイスの 3 つの層を抽象化します。</p> <ol> <li><code>session</code>: 回復可能なイベントとステータスの履歴</li> <li><code>harness</code>: 推論とスケジューリングのループ (脳)</li> <li><code>sandbox</code>: 実行環境とツールの機能 (ハンド)</li> </ol> <p>分離すると、システムの交換、復旧、拡張が容易になります。</p> <h2 id="1-セッションはコンテキスト-ウィンドウではありません">1) セッションはコンテキスト ウィンドウではありません </h2><p>重要な点は次のとおりです。 **セッションはモデル コンテキストと等しくありません。 **</p> <p>セッションは、モデルに直接接続された履歴のスプライシングではなく、クエリ可能、再生可能、および回復可能なイベント ログである必要があります。</p> <p>これを行うことの価値:</p> <ul> <li>トリミングは歴史の消滅を意味するものではありません</li> <li>圧縮は事実の損失と同等ではない</li> <li>クラッシュリカバリは、サマリーメモリに依存するのではなく、イベントレイヤーに戻ることができます</li> </ul> <h2 id="2-ハーネスは交換可能なオーケストレーション-レイヤーです">2) ハーネスは交換可能なオーケストレーション レイヤーです </h2><p>ハーネスは、ビジネス ステータスを保持することよりも、スケジュールを管理することに重点を置く必要があります。</p> <p>理想的なインターフェイスは次のようなものです。</p> <p><code>execute(name, input) -&gt; string</code></p> <p>これは、モデルが「どの機能を呼び出すことができるか」のみを考慮しており、特定のデバイス、コンテナー、オペレーティング システムに強く束縛されていないことを意味します。</p> <h2 id="3-サンドボックスは頭脳ではなく手です">3) サンドボックスは「頭脳」ではなく「手」です。 </h2><p>脳と手が切り離されると:</p> <ul> <li>ツール環境は独立して進化できる</li> <li>異なるインフラストラクチャに並行してアクセス可能</li> <li>セッションごとに実行環境全体をウォームアップする必要はありません</li> </ul> <p>これは、起動および拡張のパフォーマンスの向上に直接つながります。</p> <h2 id="パフォーマンスとセキュリティのインスピレーション">パフォーマンスとセキュリティのインスピレーション </h2><p>多くの場合、この分割によりパフォーマンスとセキュリティの両方が向上します。</p> <p>パフォーマンス：</p> <ul> <li>最初に脳を起動し、必要に応じて手を引き上げることができます</li> <li>最初のトークンの遅延を減らす (TTFT)</li> </ul> <p>安全性：</p> <ul> <li>機密性の高い認証情報をモデルに直接公開しないでください</li> <li>間接的な資格情報アクセスには制御されたプロキシ/ボールトを使用する</li> <li>安全境界はシステムの制約に基づいており、「モデルが実行できないこと」ではありません。</li> </ul> <h2 id="関連リンク">関連リンク </h2><ul> <li><a class="link" href="https://claude.com/blog/claude-managed-agents" target="_blank" rel="noopener" >Usage patterns and customer examples</a></li> <li><a class="link" href="https://www.anthropic.com/engineering/managed-agents" target="_blank" rel="noopener" >The design of Claude Managed Agents</a></li> <li><a class="link" href="https://platform.claude.com/docs/en/managed-agents/quickstart" target="_blank" rel="noopener" >Onboarding, quickstart, overview of the CLI and SKDs </a></li> </ul>