プロンプトエンジニアリングの終わりが来ました。

AIエージェントが単純なプロンプトを超える重要なアップグレードを受けます。複雑な現実のタスクに対して信頼性を持たせる「エージェントハーネス」アーキテクチャを発見してください。

Stork.AI
Hero image for: プロンプトエンジニアリングの終わりが来ました。
💡

TL;DR / Key Takeaways

AIエージェントが単純なプロンプトを超える重要なアップグレードを受けます。複雑な現実のタスクに対して信頼性を持たせる「エージェントハーネス」アーキテクチャを発見してください。

あなたのAIエージェントは失敗しています(そしてあなたもそれを知っています)

あなたはすでにそのパターンを知っています。AIエージェントに変数名を変更させたり、ユニットテストを書かせたり、プルリクエストを要約させたりすると素晴らしい結果になります。しかし、数十のファイル、複数のサービス、そして1週間の反復にわたる完全な機能実装を任せると、それは静かに未完成のブランチ、壊れたテスト、そして空想上のAPIに分解してしまいます。

開発者たちはそれでも試み続けます。彼らは「自律型」のコーディングエージェントを立ち上げ、GitHub、Jira、テストランナーを接続し、システムが循環的なリファクタリングで行き詰まったり、20分前に見た要件を忘れたりするのを見守ります。ベンチマークはおもちゃのタスクでは素晴らしい結果が出ますが、実際のリポジトリではエージェントがエッジケースを見逃したり、パフォーマンスが悪化したり、セキュリティ制約を無視したりしています。

だからこそ、Vibe Codingは主に神話のままです。ファンタジーはこうです:機能を数文で説明し、エージェントをあなたのモノレポに指示し、クリーンなPR、グリーンCI、そして合格した統合テストのもとに戻ってくる。実際には、モデルは仕様から逸脱し、長期的な目標を見失い、最後に与えたコンテキストウィンドウに過剰適合してしまいます。

原則として、2023年頃から生のLLMの力は、その急速な成長を止めました。より大きなコンテキストウィンドウや優れたプロンプトが役立ちましたが、基本的な信頼性の問題、すなわち脆弱なツール使用、コンテキストの劣化、プロジェクトレベルの状態概念の欠如を解決することはありませんでした。プロンプトエンジニアリングとコンテキストエンジニアリングはその限界を押し上げましたが、アーキテクチャは変わりませんでした。

異なるレイヤーが静かに現れ、それを解決しようとしています。エージェントハーネスは、メモリ、ツール、およびサブエージェントに対する明示的な制御を持ってモデルをラップし、自由に動くチャットボットを数時間または数日間計画を保持できるシステムへと変えます。Anthropicの長期間にわたるハーネス、LangChainのDeepAgent、Cole MedinのLinearエージェントハーネスのようなプロジェクトは、すべて同じ方向を指し示しています。

このシリーズは、その変化の内部に迫ります。ハーネスベースのアーキテクチャが、エージェントを本格的な作業に信頼できるものにする方法、依然として問題が発生する場面、そして真のバイブコーディングがデモでなくデフォルトになるために必要なことについてです。

プロンプトからプログラムへ:AIの大きな変化

イラスト:プロンプトからプログラムへ:AIの大変革
イラスト:プロンプトからプログラムへ:AIの大変革

プロンプトエンジニアリングは、GPT-3と対話するための民間科学として始まりました。開発者たちは、単一のプロンプトに夢中になり、言い回し、例、出力形式を調整して、単一の2,048トークンのインタラクションからより良い回答を引き出そうとしていました。作業の単位は1つのリクエスト、1つのレスポンス、メモリーや計画はありませんでした。

GPT-3.5とGPT-4がチャット機能と大きなコンテキストウィンドウを持って登場したことで、その考え方は崩れました。コンテキストエンジニアリングが主導権を握り、「完璧なプロンプトは何か?」という問題から「モデルが今、100以上の以前のメッセージやメガバイトの文書から何を見なければならないのか?」という問題に変わりました。チームはコンテキストの劣化に立ち向かい、システムプロンプト、要約、リトリーバルパイプラインを使いこなして、セッションを一貫性のあるものに保とうと奮闘しました。

コンテキストエンジニアリングは、AIセッションを慎重にキュレーションされた会話のように扱います。どの仕様、コードスニペット、決定がコンテキストウィンドウ内に残り、どれが長期ストレージに移動するかを決定します。ベクター検索、階層的要約、役割に基づくシステムメッセージなどのツールは、単一の長いチャットを管理するための標準となりました。

エージェントは、プッシュを利用して進行を一段階上げます。単一のコールやセッションを最適化する代わりに、ハーネスは複数のエージェントにわたる多くのセッションを調整し、数時間または数日にわたるタスクを完了します。「この機能をエンドツーエンドで出荷する」と考えてください、ではなく「この関数をリファクタリングする」とは考えないでください。

現代のエージェントは、複数の動作を同時に調整します: - 異なる役割を持つ複数のLLMセッション - 共有およびエージェントごとのメモリストア - コード実行、テスト、外部API用のツール - チェックポイント、ロールバック、そして人間のレビューゲート

Anthropicの「持続的エージェントのための効果的なハーネス」、LangChain DeepAgents、Cole MedinのLinear Agentハーネスなどのプロジェクトは、すべてこのパターンに従っています。一つのエージェントが計画を立て、別のエージェントがコードを書き、さらに別のエージェントがテストを実行し、ハーネスは数十または数百の呼び出しにわたって状態を追跡します。作業の単位はチャットログではなく、ワークフローグラフになります。

重要なのは、これは進化であり、忘却ではないということです。ハーネスは、各コール内での鋭いプロンプトエンジニアリングや、各セッション内での厳格なコンテキストエンジニアリングに依然として依存しています。彼らは単に、そのスキルをより大きなプログラムの低レベルのプライミティブとして扱い、多くの不完全なエージェントを単一の信頼できるシステムに調整するという真の課題に直面しています。

LLMパワープレートの変化が全てを変える理由

生のモデルの性能は、2020年に人々が想像していたSF的なグラフにはもはや従っていません。GPT-3からGPT-4への変化は「素晴らしいデモ」から「これを仕事で使えるかも」と感じられましたが、GPT-4.1、4.1-mini、Claude 3.5 Sonnetは、新たな知能レベルの機械ではなく、遅延、コスト、信頼性の間での漸進的なトレードオフに見えます。

ベンチマークがそれを裏付けています。アカデミックなリーダーボードは飽和状態に達し、ベンダーは静かにMMLUスコアの自慢から「トークン毎秒」や「ドルあたりのリクエスト」の宣伝へと軸足を移しています。私たちは依然としてより優れたモデルを手に入れていますが、その成長曲線は指数関数的というよりも線形に見えます。

AI研究者たちは次第に静かな部分を公然と言い始めています。スケーリングの時代はアーキテクチャの時代に移行しています。トランスフォーマーに10倍のGPUを投入することは年々効果が減少するため、実際の鍵はモデル周囲のシステム構築に移っています。これには、計画ループ、メモリレイヤー、ツールルーター、評価者、そして人間が介在するチェックポイントが含まれます。

その変化は、Anthropicが「長期間実行されるエージェントのための効果的なハーネス」などのエンジニアリングの深層分析を作成する理由と、OpenAI、Google、Metaが「エージェント」を推進し、単により大きなLLMを目指している理由を説明しています。最前線は、単一の不透明なモデルコールから、明示的な状態と制御を持つ呼び出しの調整されたネットワークへの移行へと進化しています。

エージェントのハーネスは、この新しいアーキテクチャスタックの中心に位置しています。彼らは、機能リクエストをステップに分解し、サブエージェントを調整し、メモリを管理し、幻覚的に進む道を考えるのではなく、人間に尋ねるべき時を決定するという、魅力的ではないが重要な作業を行います。

GPT-5が完璧なプルリクエストを魔法のように出荷することを願うのではなく、チームは次のようなハーネスを設計できます:

  • 1コーディング標準とテストゲートを遵守する
  • 2プロジェクト規模のコンテキストを持続的に取得する
  • 3プランナー、コーダー、レビュアーエージェント間でタスクをルーティングする
  • 4ループ、回帰、仕様のドリフトを検出する

そのコントロールサーフェスは、開発者が再び影響力を持つ場所です。OpenAIのトレーニング過程を変更することはできませんが、どれだけのエージェントを立ち上げるか、彼らがどのように会話するか、どのツールにアクセスするか、そしていつ停止して自らを正当化するかを決定することができます。

エージェントのハーネスは、生のモデルの重みではなく、革新の主要なキャンバスとなります。次の「10倍」の能力の飛躍は、新しいモデルカードのようなものではなく、堅牢でデバッグ可能なプロダクショングレードのエージェントアーキテクチャのように見えるでしょう。

エージェントが切実に必要とする制御システム

生のLLMコールはデモでは印象的に見えますが、頼りにできる共同作業者というよりは、むしろ強力で気まぐれな動物のように振る舞います。エージェントハーネスは、そのモデルを包み込む制御システムであり、確率的なテキスト予測を信頼性のあるソフトウェアに近づけるものです。これは、エージェントがどのように記憶し、どのツールに触れ、他のエージェントとどのように協力し、そして単一のチャットターンではなく、数時間または数日間目標に一致し続けるのかを定義します。

LLMを競走馬だと考えてください:速くて強く、あなたのスプリントバックログにはまったく興味がありません。ハーネスは、その力を予測可能な動きに制約するための手綱、鞍、そしてブライドルです。これがなければ、雰囲気に基づいたコーディングのトランスクリプトや幻のAPIが得られますが、これがあれば、実際に機能を出荷し、テストを実行し、ファンフィクションに迷い込むことなくドキュメントを更新できるコーディングエージェントが得られます。

ハーネスの最初の役割はメモリ管理です。LLMは依然として有限のコンテキストウィンドウ内で動作しており、128Kトークン、支払った場合はおそらく200Kトークンまでです。そのため、ハーネスは何を保持し、何を要約し、何を忘れるべきかを決定します。ManusやAnthropicの自社ハーネスのようなシステムは「コンテキストロット」と戦い、古い指示を削除し、現在重要なレポスライス、チケット、以前の決定のみを引き出すためにリトリーバルを使用します。

二つ目の仕事:ツールコントロール。現代のエージェントは、ファイルシステムからCIパイプラインに至るまで、すべてを呼び出します。そして、生のモデルはプロンプトがそれを促すと、喜んで`rm -rf`コマンドを実行し、リポジトリを削除してしまいます。ハーネスはこれらの機能を制御します:ツールを呼び出すタイミングを決定し、出力を検証し、「コミット前にテストに合格しなければならない」や「人の承認なしに本番環境に触れてはいけない」といったポリシーを強制します。

第三に、ハーネスは専門のサブエージェントを調整します。一つの巨大なプロンプトが「全機能を実行しようとする」のではなく、次のようなパターンが見られます: - スペックをタスクに変えるプランナーエージェント - ファイルを編集するコーダーエージェント - テストを実行し解釈するテスターエージェント - スタイルとアーキテクチャを遵守させるレビュエーターエージェント

最終的に、ハーネスは長期実行タスクを正常に進行させます。これらはグローバルな状態を追跡し、ループを検出し、チェックポイントを設定し、人間のために意思決定点を提示します。生のLLM呼び出しは状態を持たず、記憶がありませんが、ハーネスされたエージェントは数百回の呼び出しを通じて作業を行い、一晩中一時停止し、翌日には前回のテスト実行を壊したエッジケースを正確に把握したまま再開することができます。

アンダー・ザ・フッド:現代ハーネスの解剖査

イラスト: ハンドルの下: 現代のハーネスの解剖学
イラスト: ハンドルの下: 現代のハーネスの解剖学

現代のハーネスは、通常、チャットボットのような働きではなくプロジェクトマネージャーのように機能するイニシャライザーエージェントで開かれます。これは、ユーザーの仕様を読み取り、リポジトリや環境を検査し、具体的な計画を生成します:マイルストーン、使用するツール、触れるファイル、そして明確な成功基準です。Anthropic自身のハーネスは、これを「イニシャライザー–コーダー」の分割と表現しており、イニシャライザーがコードの変更が行われる前にスコープを確定します。

初期化が完了すると、制御は実際に作業を行うタスクエージェントに移ります。このエージェントはループ内で動作し、単一のステップを実行し、ツールを使い、その後ほとんどのコンテキストウィンドウを破棄します。各ループの反復では、モデルが200件のメッセージのチャットログに溺れないように、メモリから状態を十分に再取得します。

そのループは通常、自由形式のチャットよりも厳密な制御システムのように見えます。タスクエージェントは次のように動作します: - 現在の計画スライスと関連ファイルをメモリから引き出す - 変更やアクションを提案する - ツールを実行する(テスト、リンター、コンパイラー、HTTP呼び出し) - 結果と差分を書き戻し、再度繰り返す

ガードレールがすべての反復を包み込みます。事前チェックでは、エージェントの次のアクションが計画と許可されたツールに一致していることを検証します;事後チェックでは、「テストは合格しなければならない」や「ログ内に秘密があってはならない」といった制約に対して出力を確認します。LangChain DeepAgentやOutSystems Agent Workbenchのようなシステムは、これらのチェックをポリシーとして組み込み、ハードフェイルや人のレビューを要求することができます。

チェックポイントはハーネスに背骨を与えます。意味のある進展、例えば、合格したテストスイートや完了したAPI統合の後、ハーネスは状態をスナップショットします:プランの位置、ファイルのハッシュ、ツールの出力、そして重要な決定です。もしエージェントが後に幻覚を見たり、ファイルを破損させたりした場合、ハーネスは何が間違ったのかを推測する代わりに、最後の正常なチェックポイントにロールバックすることができます。

ハンドオフは専門のエージェント間でコンテキストを移動させます。プランナーエージェントはコーディングエージェントに構造化されたタスクグラフを渡すことがあります。コーディングエージェントはレビューエージェントにパッチとテストプランを渡すかもしれません。各ハンドオフは厳密なスキーマを使用するため、エージェントはあいまいな文章ではなく、機械でチェック可能な状態を渡し合います。

これらすべては、真剣なメモリー層がなければ機能しません。現代のハーネスは、コードやドキュメントのためにRAGに依存し、意思決定のために長期保存を行い、コンテキストの劣化を防ぐための要約や埋め込みを通じたメモリー圧縮を行います。人間が介在するブレークポイントは、そのスタックの上に位置し、リスクの高いアクション(スキーママイグレーション、支払いフロー、セキュリティに敏感なリファクタリングなど)に対する承認のためにループを一時停止します。これにより、雰囲気のコードが静かに災害を引き起こすことを防ぎます。

アンソロピックの止まらないコードエージェントのための設計図

Anthropicは、真剣で長期的なコードエージェントのための最も明確な設計図の一つを静かに公開しました。それは、Claudeをおしゃべりなオートコンプリートではなく、よりジュニアエンジニアに近づけるためのハーネスです。彼らの長期的なエージェントハーネスは新奇性を追い求めるのではなく、計画、実行、検証を体系化することで、モデルが数時間に及ぶコーディングタスクを遂行しながら本筋を見失わないようにしています。

中心には、テックリードのように振る舞うイニシャライザーエージェントがあります。広範な仕様を取り込み、リポジトリを検査し、制約を列挙し、具体的なタスク、ファイルタッチリスト、依存関係のメモ、受け入れ基準を含む構造化された計画を生成します。その計画は、ファイルを編集し、ツールを呼び出し、テストを実行するという厳しい作業を行う別のコーダーエージェントとの契約となります。

Anthropicのハーネスは、状態を重要な問題として扱い、後回しにはしません。すべてを一つの巨大なコンテキストウィンドウに詰め込むのではなく、以下のものを維持します: - 標準的なタスクグラフとチェックリスト - ファイルレベルの履歴と差分 - 過去のツールコールとテスト実行の要約

初期化プログラムはこの状態を書き込み、コーダーはその一部を読み取った後、新しいアーティファクトを追加します。これにより、将来の呼び出しが取得できるようになります。このパターンにより、システムは多くの小さく集中したコンテキストウィンドウを飛び越えながら、単一の連続したセッションのように振る舞うことができます。

ツーリングは全体をまとめます。コーダーエージェントはファイル編集を妄想しません。明示的なツールを呼び出して次を行います: - ファイルの読み書き - ユニットテストと統合テストの実行 - リンターとフォーマッターの実行

各ツールの呼び出しは、ハーネスが記録し、要約し、選択的にコンテキストにフィードバックする構造化された出力を返します。例えば、失敗したテストは、コーダーが対応しなければならない明確なバグレポートとなり、ハーネスがタスクを完了としてマークする前に解決される必要があります。

自己検証は至る所に存在します。初期設定者は自らの計画を元の仕様と照らし合わせて評価し、コーダーは計画に対して差分を評価し、ハーネスはテストが失敗したりカバレッジのギャップが生じたときに前進を阻止する制御ループを強制します。人間のチェックポイントは、高リスクな変更のために同じループに組み込むことができます。

Anthropicのデザインは、一般的なハーネスの設計図にほぼ一対一で対応しています:耐久性のあるメモリ、明示的なツール、専門的なサブエージェント、そして厳密な制御ループ。プロジェクトのようなLinear-Coding-Agent-Harnessも同様のパターンを反映しており、「バイブコーディング」を単なるパーティトリック以上のものにしようとしているすべての人にとって、急速に事実上のアーキテクチャになりつつあります。

「バイブコーディング」の夢は今や「なんとなく」現実に

バイブコーディングはずっとSF的に聞こえていました: “バイブ”という機能を説明し、コーヒーを飲みに行き、戻ると仕上がったプルリクエストがある。エージェントハーネスを使えば、その幻想は現実に近づいていますが、「まあ、ちょっとだけ」です。今では、エージェントをGitリポジトリに向けることで、計画、編集、テストの実行、そして数時間にわたる反復作業が、すべてのキーストロークを見守ることなく行えるようになりました。

ハーネスは、生のモデルを制御システムで包み込むことによってこれを可能にします。よく設計されたハーネスは、ツール(git、テストランナー、リンタ)を管理し、何十回または何百回もの呼び出しの状態を追跡し、チェックポイントを強制します。たとえば、Anthropicの長期間にわたるコーディングハーネスは、初期化エージェントを使用して計画を設定し、その後コーダー・テスターのループを通じて実装と検証を行います。

虹とデイジーはそこで留まります。完全に自律的なバイブコーディングは、混沌としたモノリスにぶつかると、その瞬間に失敗します。テストが不足していたり、あいまいな製品要件がある場合です。ハーネスは、あなたがすでに持っているエンジニアリングの技術を強化しますが、それを置き換えるものではありません。

成功は、よく構築されたコードベースと豊富なツールに強く関連しています。実際に機能を安定して出荷するエージェントは、次のような環境に存在する傾向があります: - 高いテストカバレッジと迅速なフィードバック(秒単位で、分ではない) - 厳格なリンターとフォーマッター(ESLint、Prettier、Ruff) - 明確なモジュール境界と型付けされたAPI(TypeScript、mypy)

人間の介在は重要な事柄においては譲れない要素です。最も効果的なバイブコーディングのセットアップでは、重要なチェックポイントに人間が挿入されます:初期計画の検証、アーキテクチャの変更の承認、リスクのあるマイグレーションのレビュー、そしてプルリクエストのマージです。コール・メディン自身のハーネスの例は、盲目的な自動マージパイプラインではなく、明示的なレビュー段階に依存しています。

なので、バイブコーディングは「戻ってきた」ものの、魔法のトリックではなくワークフローとしてです。意図、アーキテクチャ、トレードオフを把握しつつ、ファイルの編集、ボイラープレート、リファクタリングなどの煩雑な作業をオフロードします。設定して忘れるエージェントのファンタジーは待っても良いですが、実用的なバージョンは今日出荷されます。それを実現するためには、ハーネスとコードベースをしっかりと設計する必要があります。

AIエージェントにとっての二つの大きな障害

イラスト:AIエージェントのための2つの巨大な障害物
イラスト:AIエージェントのための2つの巨大な障害物

ハーネスに包まれたエージェントは、依然として厳しい問題に直面しています:時間を超えた調整です。短いプロンプトは仕様を守ることができますが、500ステップのコーディングマラソンはそうはいきません。アンソロピックの初期化者–コーダーループやLangChainのDeepAgentを用いても、モデルは静かに要件を解釈し直し、データモデルを再発明したり、元のブリーフで非交渉的だった制約を「最適化」してしまうのです。

アライメントのずれは微妙な形で現れます。コーディングエージェントは、リファクタリングの途中でRESTをGraphQLに置き換えたり、テストに合格した後にパフォーマンス予算を無視したりすることがあります。ハーネスはガードレールを追加します—チェックポイント、自己批評、回帰テスト—but 誰もがツール使用の数時間や数日にわたって、大規模で確率的なモデルをアーキテクチャや製品仕様に忠実に保つための完全無欠の方法を持っているわけではありません。

さらに難しいのは、アライメントが変化するコンテキストを生き残る必要があることです。要件は進行中に進化し、人間が部分的なフィードバックをもたらし、外部システムが失敗します。今日のハーネスは経験則を用いて意図を近似しますが—「認証には触れない」、「このディレクトリは編集しない」、「Nステップごとにテストを実行する」—それでも「UXの均衡を保つ」や「このコードベースをイディオマティックに保つ」といった高次の目標を見逃しています。

次に、真剣なハーネスを構築するためのコストがあります。生産レベルのシステムには以下が必要です: - 永続的な状態とメモリストア - ツール編成(エディター、テストランナー、CI、チケット発行、可観測性) - セーフティチェック、ロールバックパス、ヒューマン・イン・ザ・ループのレビュー - ドメイン特化型の評価者と指標

そのスタックはプロンプトというより、新しい製品のように見えます。Anthropicの長年のハーネスは複数のエージェント、計画段階、検証レイヤーを網羅しています。一方、コール・メディンのリニアエージェントハーネスはGit、イシュートラッカー、コード実行を連携させています。これらのいずれもSDKから「無料」で提供されるものではありません。

ユニバーサルで「一律に適合する」ハーネスの標準はまだ存在していません。フィンテックバックエンド、Reactデザインシステム、データサイエンスノートブックパイプラインは、それぞれ異なるツール、異なる安全チェック、異なる「完了」の定義を求めています。LangChain DeepAgentのようなフレームワークや、OutSystems Agent Workbenchのようなプラットフォームは収束の兆しを示していますが、それでもチームやドメインごとに大きなカスタマイズが必要です。

取引を台無しにする要因ではなく、これらの二つの障害が次のフロンティアを示しています。現在の競争は、少し賢いモデルを追求するのではなく、バイブコーディングを時折魔法のようにするのではなく、退屈なくらい信頼性の高いものにするためのアラインメント意識を持った再利用可能なハーネスに焦点を当てています。

始める場所:野生のハーネスたち

エージェントを状態を持つワークフローとしてスケッチすることから始めましょう。具体的なステージを書き出してください:仕様の取り込み、計画、実装、テスト、リファクタリング、デプロイ、レビュー。あなたのハーネスは、これらのステージ間で状態を移動させ、LLMを呼び出すタイミングや人間を関与させるタイミングを決定するレイヤーとなります。

実践的な例として、LangChainのDeepAgentsは触れてみるのに最もアクセスしやすい場所です。DeepAgentsは、プランナー、エグゼキューター、クリティックをどのように結びつけるかを示しており、ツールの使用とメモリが単一の呼び出しではなくループに組み込まれています。彼らがリポジトリ全体のリファクタリングやマルチサービスAPI統合のようなマルチステップタスクをどのように管理するかを追跡できます。

コール・メディンのGitHub上にある独自のリニアコーディングエージェントハーネスは、さらに意見が強い設計図です。これは、リニアの課題に周りにコーディングエージェントを組み込み、チケットの読み取り、変更の計画、ファイルの編集、リニアへの更新の投稿に関する具体的なフローを提供します。チェックポイント、エラーハンドリング、モデルが仕様から逸脱した際のリカバリー方法に関する実際のパターンが得られます。

エンタープライズスタックで働いている場合、OutSystemsのエージェントワークベンチは、抽象化の階段をさらに上昇させます。これは、ガードレール、可観測性、人間の承認を組み込むことで、「レビューなしでプロダクションに触れない」や「マージ前にテストが合格することを要求する」といったポリシーを定義できるようになります。CiscoのOutshiftチームは、エンタープライズがAIエージェントを活用してよりスマートな自動化を実現する方法において、プロダクションシステムの似たようなパターンをマッピングしています。

ハーネス設計をソフトウェアアーキテクチャの問題として捉え、プロンプトの細かい調整として扱わないでください。エージェントの長期状態(タスクグラフ、ファイル、チケット)、ツール(リポジトリアクセス、CI、ドキュメント検索)、そして安全基準(テスト、リンター、人間のレビュー)を特定してください。その後、それらを「モデルが記憶することを期待する」のではなく、明示的な状態と遷移として体系化してください。

実用的なスターターレシピは以下のようになります: - スペックをタスクリストに変換するプランナーエージェント - コードを編集しツールを実行するエグゼキューターエージェント - 差分とテスト出力を批評するレビュアーエージェント - 再計画やエスカレーションのタイミングを決定するコントローラーループ

このように考えるようになると、プロンプトエンジニアリングは、実際に信頼性を担保するハーネス内の実装の詳細となります。

未来は促されるのではなく、オーケストレーションされる。

プロンプトエンジニアリングは良い時代を迎えましたが、重心が移動しました。力は今やオーケストレーションにあります:メモリ、ツール、サブエージェント、そして人間のチェックポイントを管理するエージェントによって、単一のLLM呼び出しが巧妙なオートコンプリートのトリックではなく、一貫性のある長期的なシステムになります。

私たちはAIがソフトウェアと同じ軌跡を辿るのを見ています。初期の「スクリプト」や手作業で調整されたプロンプトは、堅牢なシステムエンジニアリングに取って代わられています:プランナー、検証者、回帰テスト、テレメトリー、そしてロールバックが組み合わさり、世代ごとに10〜20%しか改善されないモデルの周りに構築されています。

二つの大きな障壁―長期的な調整とアーキテクチャの忠実度を解決すれば、エージェントは単なるおもちゃではなく、全体のワークフローを所有するようになります。適切に設計されたハーネスは、原則として、仕様を守りながら完全な成長ループ、エンドツーエンドのオンボーディングファネル、または500,000行のコードベースの数ヶ月にわたるリファクタリングを実行することができます。

その瞬間、「AIコーディングアシスタント」が「AIエンジニアリングチームメンバー」になります。同じパターンは科学的な作業にも広がります:文献の検索、シミュレーションキャンペーン、そして数千のLLMコールを通じて連鎖する実験計画。ハーネスは制約を強制し、意思決定を記録し、重要な分岐のみを人間に提示します。

このエージェント的な時代で成功する開発者は、プロンプトハックを暗記する人ではなく、制御システムを設計する人です。あなたの仕事は、モデルとの会話から、数日または数週間の自律運用に耐えるプランナー、批評家、ツールルーター、レビューメ gate を設計することに移ります。

小さく始めることが大切ですが、今すぐ始めましょう。Anthropicの長年のハーネス、Cole MedinのLinearエージェントハーネス、LangChainのDeepAgent、またはManusのコンテキストエンジニアリングパターンを活用して、今日あなたが抱えている単一の痛みを伴うワークフローにハーネスを繋げてみてください。

それを計測し、壊し、強化してください。AIにおける次のレバレッジは、モデルを操る人々のものであり、単にそれに指示を出す人々のものではありません。

よくある質問

AIエージェントハーネスとは何ですか?

エージェントハーネスは、AIエージェントを中心に構築されたシステムで、メモリ管理、ツール制御、サブエージェントの調整、状態維持を行い、信頼性高く複雑で長時間にわたるタスクを実行できるようにします。

エージェントハーネスは、プロンプトエンジニアリングとは異なります。

プロンプトエンジニアリングは、LLMとの単一のインタラクションを最適化します。エージェントハーネスは、プロジェクト全体を完了するために多くのインタラクションとコンテキストウィンドウを調整する全体的なアーキテクチャであり、そのフレームワーク内にプロンプトとコンテキストエンジニアリング技術を組み込んでいます。

エージェントハーネスを使って「バイブコーディング」は可能ですか?

エージェントハーネスは、エージェントの信頼性を高めることにより、「バイブコーディング」(手動での機能実装なし)に私たちをより近づけます。ただし、完全に解決されたわけではなく、複雑なタスクには依然として人間による検証と巧妙に設計されたガードレールが必要です。

なぜエージェントハーネスが今重要になっているのでしょうか?

LLMの生の力が頭打ちになりつつある中、革新はそれらを取り巻くシステムに移行しています。ハーネスは、エンタープライズグレードの自律エージェントの次のレベルの能力を引き出すために必要な構造を提供します。

🚀Discover More

Stay Ahead of the AI Curve

Discover the best AI tools, agents, and MCP servers curated by Stork.AI. Find the right solutions to supercharge your workflow.

Back to all posts