ソフトウェア開発でAIツールを活用することは、もはや1つのプロンプトを書いて回答を待つだけにとどまらない。開発者たちは、反復的な実行ループ、複数のエージェント、モデルを取り囲んで方向づけるシステムについて、 increasingly 語るようになっている。GitHub Blogは、Marlene MhangamiとGPSが参加したGitHub Podcastでの議論をもとに、Cassidy Williamsが2026年9月2日に公開したガイドで、これらの概念を整理しようとしている。
これらの用語の一部は新しい実践パターンを表し、一部は以前から存在していた考え方に新しい名前を与えている。一方で、別の用語については、いまだ意味が形成されつつある段階だ。そのため、このガイドはこれらの言葉を最終的な標準として提示するのではなく、ソフトウェア開発チームの間で交わされている議論を理解するための方法として提示している。
単一のプロンプトからループエンジニアリングへ
ループエンジニアリングとは、エージェントに毎回手作業で単一のタスクを実行させるのではなく、エージェントを中心に反復可能なシステムを設計することを意味する。示されている例は、スケジュールされたプロセスで新しいプロジェクト課題を取得し、それをエージェントに渡して要約と修正案を作成させ、その出力を検証したうえで、未解決のケースを別の経路へエスカレーションするというものだ。
この意味で、ループはAI向けに設定されたcronジョブに似ているように見えるが、スケジューリング以上の要素が必要になる。ガイドは、具体的なスキル、動作の監視、出力の検証、タスクの指示、そして介入やレビューが可能な停止点を挙げている。
Ralph loopsは、ループという考え方をより単純かつ直接的に適用したものだ。エージェントには、通常は要件や仕様を起点とした詳細なタスクの説明が与えられ、エージェントがタスクを完了したと判断するまで作業を続ける。この方法は、計画、実行、確認を繰り返すサイクルに作業を分割するのに役立つ場合があるが、各サイクルでより多くのトークン、コンテキスト、計算能力を消費すると、コストが高く非効率になる可能性がある。
チーム、フリート、ハーネスの違い
squadsとfleetsは、複数のエージェント間で作業をどのように分配するかを表す。チームとは、異なる役割を持つエージェントの集まりである。1体が計画を立て、別の1体が計画をレビューし、3体目が実装し、4体目がテストし、5体目が結果をレビューする。一方、フリートは、同時にタスクへ並列で取り組むエージェントを指す。完全なチームを並列フリート内で実行することも、役割を順番に編成することもできる。
ここでの実践的な考え方は、1体のエージェントにすべてを任せるのではなく、専門化と並列化を行うことだ。ただし、複数のエージェントが存在するだけで、品質が自動的に向上するわけではない。本文自体も、その利点はチームが役割を分配・管理し、出力を検証できる能力と結びついているとしている。
実行ハーネス、またはharnessとは、モデルをワークフロー内で利用可能にするためにモデルを取り囲むすべてのもの、すなわちツール、権限、メモリ、コンテキスト、タスク間の調整を指す。ガイドは、モデルをコードベース、エディター、プルリクエスト、ターミナルに接続するシステムの例として、GitHub Copilotを挙げている。一方、ハーネスエンジニアリングとは、モデルを取り囲むこのシステムを設計し、改善することだ。
フィードバックによる改善
hill climbingという用語は、フィードバックに基づいてエージェントとハーネスを段階的に改善することを表す。チームはまず評価テストによってエージェントの性能を測定し、その結果が十分に正確でない場合に、ツール、コンテキスト、または指示の仕組みを変更することがある。
たとえばプルリクエストのレビューでは、測定対象はエージェントがコメントを生成できるかどうかだけではなく、意味のあるバグを見つけ、有用な提案を提示できるかどうかも含まれる。ここから得られる実践的な理解は、エージェントをワークフローに導入することが終着点ではなく、その後に測定と調整の継続的なサイクルが始まるということだ。
役割とモデルに関する用語
フィールドエンジニアは、AIの波が到来する以前から存在していた役割を表す。たとえば、顧客と直接関わるソフトウェアエンジニア、セールスエンジニア、ソリューションエンジニアなどだ。AIの文脈では、この役割はチームがツール、ワークフロー、エージェントを適応させ、既存のシステムに統合するのを支援する。
クローズドモデルは、APIまたはホスト型製品を通じて提供されるが、重み、トレーニングデータ、トレーニング方法はユーザーに公開されない。オープンウェイトモデルでは、重みをダウンロードしてユーザーのローカル環境またはインフラ上で実行できるが、データやトレーニング方法まで利用可能であるとは限らない。オープンソースモデルでは、利用可能な範囲がさらに広く、検査、再利用、変更のために、モデル、コード、データ、トレーニングプロセスが含まれる。
このガイドが重要な理由
実際の変化は、単に新しい用語集が登場したことではなく、議論が「モデルは何を生成できるのか」という問いから、「モデルを中心に、反復可能で測定可能なシステムをどのように構築するのか」という問いへ移行したことにある。これは、ワークフロー内でエージェントを稼働させることを検討している開発チームにとって重要だ。なぜなら、用語を選ぶだけでは、権限、検証の仕組み、人間が介入するポイント、反復のコストを定義したことにはならないからである。
それでも、情報源は用語が安定していないことを認めている。定着するものもあれば、消えるものや、より正確な表現に置き換えられるものもある。そのため、より重要な問いは実践的なものにとどまる。ワークフローを信頼性のある形で繰り返せるか。結果をどのようにレビューするか。人間はいつ介入するのか。モデルにどの程度依存することが許容されるのか。本文によれば、これらの問いは、流行するすべての言葉に追随することよりも重要である。