「ハーネス」「仕様駆動」「ループエンジニアリング」開発現場の最前線
本セッションの核心となったのが、AIエージェントを現場の開発プロセスへ組み込むための最新技術動向とコンテキスト設計に関する議論である。登壇者らからは、AIネイティブ開発を象徴する3つのキーワードが提示され、それぞれの技術的背景や具体的ツールが深掘りされた。
開発環境とコンテキストを整える「ハーネス（Harness）」の全貌
コーディングエージェントに対して「こういうアプリを作って」と指示を出しても、プロジェクト全体のディレクトリ構造やコーディングルール、ファイル間の依存関係をAIが理解していなければ、支離滅裂なコードが生成されてしまう。そこで、エージェントが開発を円滑に進められるように周辺のコンテキスト設定や制御ロジック、指示ファイル（CLAUDE.mdやAgent Skillsなど）を体系的に構築・提供する取り組みを総称して「ハーネス（Harness）」と呼ぶ。
上田氏は、巨大なコードベースをエージェントに理解させるアプローチとして、「コードスペース自体をナレッジ（メモリ）化する技術」の重要性を挙げた。
具体的には、GitHub上で提供されているオープンソースライブラリ「git-nexus」などを例に挙げ、プログラムのソースコード全体をグラフデータベース（Graph DB）としてインデックス化し、ファイル間の関係性を保持したままエージェントに受け渡すハーネスが実際の現場で多用されていると説明した。これにより、人間が毎回手動で関連ファイルを指定しなくても、裏側でAIがグラフ構造を辿り、大規模なコードベースから必要な情報を的確に自律検索できるようになる。
大坪氏はサードパーティツールにとどまらず、従来から存在する開発者向けプロトコル「LSP（Language Server Protocol）」の再評価とエージェント連携を提言した。
LSPは元々、VS Codeなどのエディタ上で関数の定義ジャンプや自動補完を行うために開発されたプロトコルだが、これをAIエージェントに繋ぐ仕組みが整ってきている。TypeScriptやPythonなどの言語解析情報をLSP経由でエージェントに提供することで、AIはファイル間の正確な依存関係を把握できるようになり、最初からエラーの少ない「一発で動くコード」を出力する精度が劇的に向上すると大坪氏は解説した。なお、このLSPの「エディタと言語解析の共通化」という思想こそが、現在の標準プロトコルであるMCPの着想元にもなっているという裏話も明かされた。
御田氏は「まずはCLAUDE.mdやAgent Skillsといった標準的な設定ファイルからライトに始め、コードベースの肥大化に伴ってgit-nexusやLSPなどの外部ハーネスツールを結合していくのが現実的かつ効果的な進め方です」とまとめた。
「バイブコーディング」からの脱却を果たす「仕様駆動開発（SDD）」
次なるトレンドとして語られたのが「仕様駆動開発（Spec-Driven Development／SDD）」である。AIに曖昧なプロンプトを与えて一気にコードを出力させる試み（いわゆるバイブコーディング）は一見手軽だが、意図しない実装を生みやすく、結局はデバッグや修正の手戻りで大量のトークンと時間を浪費することになる。
仕様駆動開発の本質について御田氏は、「実装に入る前に、AIエージェントと対話的に壁打ちを行い、動作要件、画面仕様、エラー時の挙動、採用する技術スタックなどの仕様（Spec）を認識齟齬が完全にゼロになる状態まで事前に固め切ること。仕様が固まった段階で、あとはAIに機械的に実装を行わせるアプローチです」と定義した。
この領域における歴史的変遷とツール進化について上田氏は、約1年前に登場した開発環境「Kiro」における仕様駆動開発機能の搭載から始まり、GitHubが公開したSpec Kit、そしてccsttを経て、現在急速に支持を集めているOpenSpecに至る経緯を辿った。
「新規のまっさらなプロジェクトであれば仕様駆動開発は容易ですが、既存の巨大なコードが存在する現場への導入は困難を極めます。その中でOpenSpecが愛用されている理由は、既存のコードベースの実装をナレッジとして参照しつつ、新規タスクの仕様を追加・管理できる機能が備わっているためです。過去の実装方針からのブレを防げるため、実務で非常に強みを発揮します」と上田氏は強調した。
大坪氏は、仕様駆動開発を成功させるための人間側のキーポイントとして「アーティファクト（AIが生成した仕様ドキュメント）を読み切る読解力」を挙げた。
「AIが書き出した仕様書を人間側が雑に読み流してしまうと、結局上がってくるコードもいい加減なものになります。自社のチームにとって最も扱いやすい仕様フォーマット（Markdownなど）をカスタマイズし、人間とAIが正解を共有できる仕組みを作ることこそが仕様駆動開発の本質です」と大坪氏はアドバイスを加えた。
人間がプロンプトを投げない時代へ「ループエンジニアリング（Loop Engineering）」
ハーネスと仕様駆動開発の成熟によって生まれた最新の概念が「ループエンジニアリング（Loop Engineering）」である。プロンプトエンジニアリング、コンテキストエンジニアリングに続く第3の波として、2026年6月頃からフロンティアモデルの主要開発者らの間で一気にバズワード化した。
上田氏は、OpenClawの作者やClaude Codeの開発責任者（Boris氏）らが「もはや自分たちはプロンプトを投げていない、ループしか使っていない」と言及し始めたことがきっかけであると説明した。ループエンジニアリングとは、人間が手動でプロンプトを打ち込んで指示を出すのをやめ、AIエージェント群が自律的かつ永久に業務を循環させる仕組みを指す。
ループエンジニアリングを成立させるための核となる2つの要素が提示された。
- タスクの自動発見機構：GitHubなどのリポジトリに新しいIssueが作成されたタイミングをAIが自動検知し、自発的にタスクを開始するトリガー構造。
- 作業エージェントとレビューエージェントの二重構造：上がってきたコードを人間がレビューするのではなく、検証専用の「レビューエージェント（サブエージェント）」を別途用意する。レビューエージェントには、過去のナレッジ参照権限やテスト自動化ツールの実行権限を持たせ、作業エージェントが作成したコードが仕様を満たしているかを自動テスト・評価させる。不合格であれば作業エージェントにフィードバックが戻り、自律的な改善ループが回る。
大坪氏は「このループエンジニアリングは決して魔法ではなく、これまで培ってきたハーネス（サブエージェント設計、MCP連携、コンテキスト管理など）の土台があってこそ成り立つ高度な応用系です」と補足した。また、ループ回遊に伴うコンテキストの肥大化やトークン溢れに対しては、定期的なコンパクション（圧縮）やダンプファイルへの情報退避といったメモリ管理プラクティスをハーネス側で組み込むことが必須であると語られた。
