GitHub Podcast、AI 開発用語のループやハッチェスなどを解説

最近、AI ツールの普及によりソフトウェア開発の現場で次々と新しい用語が登場し、戸惑うこともあるかもしれません。

これらの新語の中には、人々が新たに採用している有用なパターンを指すものもあれば、すでに存在する概念に華やかな名前をつけただけのものもあります。また、現在も定義が進行中の用語も少なくありません。

最新の GitHub Podcast エピソードでは、GPS のマルレン・ムハンガミ氏と私が、開発者が今まさに学んでいる AI 関連の用語について議論しました。具体的には「ループエンジニアリング」「ラルフ・ループ（Ralph loops）」「スクワッド」「ハネスエンジニアリング」「ヒルクライミング」「フォワードデプロイエンジニア」「クローズドモデル」「オープンウェイト」「オープンソースモデル」などです。

聴取者ではなく、この記事を読む方へ。これらの用語が何を意味し、なぜ重要なのか、どう捉えるべきかについて解説します。

完全なエピソードは以下のリンクからどうぞ！👇

ループエンジニアリング：ワンショットプロンプトを超えて

ループエンジニアリングとは、エージェントに対して一度きりのタスクを手動で指示するのではなく、エージェントを中心に反復可能なシステムを設計する実践です。

簡単な例を挙げましょう。毎朝、新しい課題（issues）を確認し、要約し、修正案を提案するようにエージェントに指示する代わりに、スケジュールに従って実行されるループを作成します。このループは課題を取得し、エージェントに引き渡し、出力を検証し、行き詰まったものはエスカレーションするという仕組みです。いわば、AI ネイティブな cron ジョブの進化版と言えます。

ラルフ・ループ：ループエンジニアリングの brute-force 的な親戚

「ラルフ・ループ」は、この「ループ」概念の具体的な実装の一つです。エージェントに製品要件定義書や仕様書などから詳細なタスクを与え、作業が完了するまで継続的に実行させる仕組みです。

これは特に、大規模なタスクを「計画→実行→検証」というサイクルに分解して処理する際に有用です。一方で、各反復でトークン数、コンテキスト量、計算リソースが増加するため、コストが高く非効率になるリスクもあります。

ループ工学は、このパターンをより構造化することを目的としています。エージェントに対して「もう一度試してください」という指示を繰り返す必要のない設計を目指します。適切に設計されたループには、スキル、観測性、検証機能、ルーティング、チェックポイントなどの基本要素が組み込まれます。

スクワッド、フリート、マルチエージェントワークフロー

ループがワークフローの定義を行うなら、「スクワッド」や「フリート」は、複数のエージェントがそのワークフローにどのように参加するかを説明する概念です。

スクワッドとは、異なる役割を持つエージェントのグループのことです。これは現実世界のチーム構成を反映していることが多く、あるエージェントが計画を立て、別のエージェントがその計画を検証し、さらに別の実行担当者が実装し、テスト担当者が検証し、最終的にレビュー担当者が確認するというように、役割分担が行われます。

フリートとは、並列してタスクに取り組む複数のエージェントを指します。スクワッドを並列で動作させることも、順次で実行することも可能です。

このような運用により、異なるエージェントがプロセスの異なる部分を担うことができ、各エージェントに特定のスキルを与えて微調整・専門化することで、全体の効率性を高めることが可能になります。

核となる考え方は並列化と専門化です。一つのエージェントが全てをこなそうとするのではなく、異なるエージェントが開発プロセスの各部分を担当します。

Harnesses（ハルネス）：モデルを取り巻くシステム

モデルが生成するもの以外に、ワークフローで有用にするために必要な周囲の環境すべてを「ハルネス」と呼びます。

具体的には、ツールや権限、メモリ、文脈、オーケストレーションなど、モデルの振る舞いを導く要素が含まれます。覚え方としては、馬用のハーネス（鞍具）に由来する名前だと考えると分かりやすいでしょう。馬は野生のまま走ることがありますが、ハルネスを使えばその重さを安全に制御しながらタスクを完了できます。

ソフトウェアにおけるハルネスの好例が GitHub Copilot です。これはモデルをコードベースやエディター、プルリクエスト、ターミナルなどに接続します。

「Harness engineering（ハルネスエンジニアリング）」という用語を見かけることがありますが、これはモデルを取り巻くシステムを設計・改善する作業を指します。

Hill climbing（ヒルクライミング）：フィードバックによるエージェントの向上

「ヒルクライミング」という用語は、時間とともにエージェントやハルネスを改善していくプロセスを表す際に使われます。

例えば、評価指標（evals）を用いてエージェントが適切な出力を生み出しているかを測定し、結果が改善されるまでハルネスを調整するといったケースがあります。

別の例として、プルリクエストのレビューを行うべきエージェントの場合、実際に意味のあるバグを見つけ有用な推奨事項を出せているかを確認し、そのためにツールを調整して性能を高めることがヒルクライミングに含まれます。

フォワードデプロイエンジニア：AI 時代における馴染み深い役割

「フォワードデプロイエンジニア」という職種は以前から存在しましたが、AI というラベルがつくことで、まるで最先端で革新的な仕事のように見られるようになりました。実態は顧客と直接関わるソフトウェアエンジニア、あるいはセールスエンジニアやソリューションエンジニアであり、最近では AI への注力度が特に高まっています。

これらの肩書きを初めて目にする方もいるでしょうが、この役割の人は通常、顧客と密接に連携して技術的なソリューションを実装したり、顧客の環境に適応させたりします。AI に特化した場合とは、既存システムへ AI ツールやワークフロー、エージェントなどを統合する支援を行うことを意味します。

クローズドモデル、オープンウェイト、そしてオープンソースモデル

すべてのモデルが同じ方法で共有されているわけではありません。

クローズドモデルは、API を通じてアクセスするか、ホストされた製品として利用されます。開発者はこのモデルを使用できますが、背後にある重み（ウェイト）やトレーニングデータ、学習プロセスにはアクセスできません。よく耳にする大規模な最先端モデルの多くは、実はすべてクローズドモデルなのです。

オープンウェイトモデルでは、モデルの重みが公開されています。これは特定の入力がどれほど重要かを決定する「ダイヤル」のようなものだと考えてください。開発者はこれらのモデルをダウンロードして実行でき、ローカル環境や自社のインフラ上で動かすことが可能です。ただし注意すべきは、データセットやトレーニング手法が完全に公開されているわけではない点です。

オープンソースモデルはさらに一歩進んでいます。モデルそのものとコード、データ、そして学習プロセスまですべてが公開され、検証・再利用・改変が可能になっています。

モデルの開放度が高くなるほど、実行、カスタマイズ、監査、そして信頼性の確保が容易になります。

用語は常に進化し続けています

これは、最近よく耳にする用語の一部を抜粋したものです。中には定着するものもあれば、記憶の彼方に消えていくもの、そして業界が成熟するにつれてより適切な言葉に置き換わっていくものもあるでしょう。

流行語について取り残されることを心配する必要はありません。あれらは単なる言葉に過ぎません。重要なのは、その背後にある実践です。「ワークフローは確実に繰り返し実行できるか」「タスクの検証方法は何か」「人間が介入すべき（あるいはすべきでない）タイミングはいつか」「モデルへの依存度はどこまで許容できるか」「システムをどう改善していくか」。これらこそが問われるべき点です。これはエンジニアリングの新時代ですが、ベストプラクティスの重要性は変わりません。

GitHub Podcast に登録して、エピソードを見逃さないようにしましょう！

この記事「Decoding the new AI lingo: Loops, harnesses, squads, hill climbing… oh my!」は、The GitHub Blog で最初に公開されました。