この記事の対象読者
AIエージェント開発に興味があるエンジニア、GitHub Copilotの裏側に興味がある方を想定しています。
はじめに
近年の生成AIやAIエージェントの急速な発展に伴い、開発の現場では新しい専門用語やスラングが次々と生まれています。
「ループエンジニアリング？」「エージェントのスクワッド？」「ハーネスって何？」と、情報のキャッチアップに追われて戸惑っているエンジニアの方も多いのではないでしょうか。
この記事では、GitHub Podcast（EP48）およびGitHubブログで解説された「いまソフトウェア開発者が知っておくべきAI関連の新用語」を分かりやすく整理して解説します。ただのバズワードなのか、それとも実務で役立つ重要な設計パターンなのか、その本質を紐解いていきましょう。
目次
- ループエンジニアリング（Loop Engineering）：単発プロンプトからの脱却
- ラルフ・ループ（Ralph Loops）：力まかせの実行パターンとその課題
- スクワッドとフリート（Squads & Fleets）：マルチエージェントの組織論
- ハーネス（Harnesses）：モデルの力を引き出す外側の仕組み
- 山登り法（Hill Climbing）：評価と改善のサイクル
- フォワードデプロイエンジニア（FDE）：現場密着型のAI導入エンジニア
- モデルの3つの形態：クローズド／オープンウェイト／オープンソース
- まとめ：バズワードに惑わされないために
1. ループエンジニアリング（Loop Engineering）：単発プロンプトからの脱却
従来のLLM利用は「1回の指示に対して1回の回答を得る（ワンショット）」使い方が中心でした。しかし、AIエージェントを活用する現場では、エージェントを組み込んだ再現可能なシステムを設計する手法へと移行しています。これが「ループエンジニアリング（Loop Engineering）」です。
具体例
毎朝人間が「新しいIssueを要約して修正案を出して」とプロンプトを手動入力する代わりに、定期実行されるループ（ワークフロー）を構築します。
- スケジュールに従って未解決Issueを取得
- エージェントに解析・修正案を作成させる
- 出力結果の自動検証を行う
- 判断に迷う部分だけを人間にエスカレーションする
いわば「AIネイティブ時代の洗練されたcronジョブ」とも言える仕組みです。
2. ラルフ・ループ（Ralph Loops）：力まかせの自動化とその注意点
ループの一種として登場したのが「ラルフ・ループ（Ralph Loop）」と呼ばれるパターンです。
仕組み
PRD（製品要件定義書）やタスク仕様をエージェントに渡し、「タスクが完了するまで試行錯誤（計画 → 実行 → 検証のサイクル）を自律的に繰り返させる」アプローチです。
メリットと課題
- メリット：大きなタスクを渡して放置できるため、手離れが良い。
- 課題：力まかせ（ブルートフォース）で回すため、イテレーションごとにコンテキストが膨らみ、トークン消費や計算コストが跳ね上がるリスクがある。
そのため、現在はこのラルフ・ループをより構造化し、スキル定義・可観測性（オブザーバビリティ）・検証ルール・ルーティング・チェックポイントを組み込んで賢く制御する設計（ループエンジニアリング）が求められています。
3. スクワッドとフリート（Squads & Fleets）：マルチエージェントの協調
ループが「ワークフローの流れ」を定義するものだとすれば、そこに登場する複数エージェントの配置・組織形態を表すのがスクワッド（Squad）とフリート（Fleet）です。
スクワッド（Squad：分科会・チーム）
人間の開発チームのように、異なる専門性・役割を持ったエージェントのグループです。
- 計画担当エージェント：タスクの分解とロードマップ作成
- 実装担当エージェント：コード生成
- テスト担当エージェント：テストケース作成と実行
- レビュー担当エージェント：コード品質やセキュリティのチェック
フリート（Fleet：船団・並列実行群）
複数のタスクを同時並列で処理するエージェント群を指します。
なぜ重要か？
1つの汎用エージェントにすべてをやらせるのではなく、「並列化」と「専門特化」を行うことで、精度向上とコスト削減を両立させるアプローチです。
4. ハーネス（Harnesses）：モデルの力を引き出す外側の仕組み
「ハーネス（Harness）」とは、モデル（LLM）の周囲を取り囲み、実務のワークフローで安全・有用に機能させるための周辺システム全体（ツール、権限管理、メモリ、コンテキスト注入、オーケストレーションなど）を指します。
馬のハーネス（馬具）に例えると分かりやすい
馬（モデル）は野性的で力強い存在ですが、そのままでは制御できません。安全に方向を制御し、重い荷物を運ばせるために装着するのが「ハーネス」です。
代表例：GitHub Copilot
LLMモデル単体ではなく、モデルをエディタ、コードベース、ターミナル、Pull Requestと結びつけ、適切な権限とコンテキストを渡しているシステム全体が「ハーネス」にあたります。
この外側の仕組みをいかに堅牢かつ効率的に作るかを追求する領域が「ハーネスエンジニアリング（Harness Engineering）」です。
5. 山登り法（Hill Climbing）：継続的なフィードバックと改善
「山登り法（Hill Climbing）」は元々最適化アルゴリズムの用語ですが、ここではエージェントやハーネスの性能を継続的に評価・改善していくプロセスを指す言葉として使われています。
具体的な流れ
- 評価（Evals）の実施：エージェントの出力精度をテストケースやベンチマークで測定する（例：PRレビューエージェントが実用的なバグを発見できているか）。
- ハーネスやプロンプトの調整：ツールの連携設定、プロンプト、コンテキスト付与ロジックをチューニングする。
- 成果の確認：スコアが以前より向上したかを確認し、次の改善へ進む。
勘や一発勝負に頼るのではなく、計測可能な指標をもとに一歩一歩性能を「登っていく」エンジニアリング手法です。
6. フォワードデプロイエンジニア（FDE）：現場密着型のAI導入
「Forward Deployed Engineer（FDE）」という職種名も、AI分野で再び脚光を浴びています。
従来のソリューションエンジニアやセールスエンジニアに近い役割ですが、AIの文脈では「顧客の現場に入り込み、顧客固有の環境・システムにAIツールやエージェントワークフローを組み込む実装支援を行うエンジニア」を指します。
モデルが優秀でも、各企業の社内システムやデータ構造と繋ぎ込むハーネスがなければ実用化できないため、現場に深く入り込めるエンジニアの需要が急増しています。
7. モデルの3つの形態：クローズド／オープンウェイト／オープンソース
モデルの提供形態についても、正確な使い分けが重要視されています。
| 形態 | 特徴 | 主なメリット・課題 |
|---|---|---|
| クローズドモデル |
(Closed Models) | APIやSaaS経由でのみ利用可能。重みや学習データは完全非公開。 | 業界最高峰の性能をすぐに使えるが、内部の挙動監査や自社環境への完全ホスティングは不可。 |
| オープンウェイトモデル
(Open Weights) | モデルの「重み（パラメータ）」が公開されており、自社インフラやローカルで実行可能。 | コスト制御やデータプライバシーに優れる。ただし学習データセットや学習レシピは非公開な場合がある。 |
| オープンソースモデル
(Open Source Models) | モデル、ソースコード、学習データセット、トレーニング手順のすべてが公開されている。 | 完全な監査性・再現性・改変の自由がある真のオープンソース。 |
8. まとめ：言葉に振り回されず、設計の本質を見極めよう
次々と新しい用語が登場すると焦りを感じがちですが、元記事でCassidy Williams氏が指摘している通り、「重要なのは言葉そのものではなく、その下にある実践（ベストプラクティス）」です。
AIエージェントをプロダクション環境に導入する際は、以下の問いに立ち返ることが大切です。
- ワークフローは安定的・再現可能に回るか？（ループ設計）
- タスクの検証・評価は自動化されているか？（評価と山登り法）
- 人間の介入（Human-in-the-loop）はどこに配置すべきか？
- モデルを支えるツールや権限の設計は安全か？（ハーネスエンジニアリング）
新語をチーム内の共通言語として上手に活用しつつ、堅実なAIエンジニアリングを実践していきましょう。