パイロットがPRを承認する時代、番外編『ハーネス・グラフ・ファクトリー』――指揮者が次に設計するもの

1. はじめに――「腕のいい新人」が一人いても、工場は回らない

腕のいい新人が一人入ってきた、としましょう。

マニュアルを渡し、合格基準を伝えれば、自分で試行錯誤して仕事を進めてくれる。

前回までのシリーズで書いたのは、まさにこの話でした。

でも、現場を回したことのある人なら知っています。

新人が一人優秀でも、チームや工場は回らない。

作業する机と道具が要る。

誰が何を担当し、どこで合流するかの段取りが要る。

入館証と、あとから「誰が何をしたか」をたどれる記録も要る。

AIエージェントも、ちょうどこの段階に来ています。

Googleは2026年4月、新しく書かれるコードの75%がAIによって生成され、エンジニアの承認を経ていると公表しました。

Spotifyも2026年2月の決算説明会で、社内のトップエンジニアたちは2025年12月以来、コードを一行も書いていない、と語っています。

「AIにコードを書かせる」段階は、もう終わりつつある......。

いま問われているのは、AIが書く仕事を、どういう仕組みで回すかです。

今回は「パイロットがPRを承認する時代」シリーズの番外編(シリーズ１，２、３）として、前回までに書ききれなかった3つの層――ハーネス、グラフ、ソフトウェアファクトリー――を取り上げます。

一人のエージェントを育てる話から、エージェントの「職場」と「工場」を設計する話へ。

2. まず地図を描く――エージェント設計は「層」で考える

最近、海外では「〇〇エンジニアリング」という言葉が次々に生まれています。

プロンプト、コンテキスト、ハーネス、ループ、グラフ......。

正直、「また新しい言葉か」と思った方も多いはずです。

ただ、2026年8月に公開された論文「Graph Engineering in the Era of LLM Agents」は、これらを競合する流行語ではなく、別々の層として整理しています。

プロンプトとコンテキストは、モデルが一回考えるときの話。

ハーネスとループは、モデルを「働き続けるエージェント」にする話。

グラフは、複数のエージェントを一つのシステムとして組織する話です。

これにソフトウェアファクトリーを加えて、職場のたとえで並べてみます。

こう並べると、下の層ほど「一回の会話」、上の層ほど「組織」の話になっているのが分かります。

新しい言葉が増えたのではなく、設計する範囲が広がっただけ。

3. ハーネスエンジニアリング――馬は優秀でも、手綱がなければ走らない

「ハーネス（harness）」は、もともと馬具の意味です。

どれほど速い馬でも、手綱と鞍がなければ、乗り手の行きたい方向には走ってくれません。

この言葉がAIの文脈で広まったのは、2026年2月のことです。

Terraformの生みの親として知られるMitchell Hashimoto氏が、個人ブログで「ハーネスを設計する」という考え方を書きました。

エージェントが失敗するたびに、プロンプトで言い直すのではなく、同じ失敗が二度と起きないように環境そのものを直す。

数日後にはOpenAIもエンジニアリングブログでこの考え方を取り上げ、言葉は一気に定着しました。

いまよく使われる式は、とてもシンプルです。

エージェント ＝ モデル ＋ ハーネス

つまり、モデル以外のすべてがハーネスです。

具体的には、次のようなものが含まれます。

• 道具：ファイル編集、シェル、ブラウザ、MCPでつながる外部サービス
• 実行環境：サンドボックスやコンテナなど、失敗しても壊れない作業場
• 状態の保持：コンテキストが溢れそうになっても、目的や進捗を失わない仕組み
• 検証：テスト、リンター、レビュー用エージェントなど、出力を自動でチェックする関所

中でも大事なのが、最後の「検証」です。

コードを変えたら、テストを流す。

落ちたら、そのエラーログをもう一度エージェントに読ませて、通るまで直させる。

人間が毎回手で確かめていたら、自動化の意味がありません。

シリーズ（3）で取り上げたサンドボックスも、実はこのハーネスの一部です。

モデルを替えるより、ハーネスを直すほうが効く場面は多い。

4. グラフエンジニアリング――「応援メンバー」と「チーム編成」は別物

シリーズ（2）で、サブエージェントを「調査を頼む応援メンバー」にたとえました。

ライブラリの仕様を調べてきてもらい、要点だけを持ち帰ってもらう。

目的は、メインのエージェントのコンテキストを汚さないことでした。

グラフエンジニアリングで出てくるエージェントは、これとは役割が違います。

こちらは最初から役割を分けて組んだチームです。

たとえば新機能の開発なら、こんな段取りになります。

1. 「要件を整理する係」と「既存コードの構造を調べる係」が、同時に動く
2. 2つの結果を「実装係」が受け取って、コードを書く
3. 「テスト係」と「セキュリティ確認係」が、並行してチェックする
4. どちらかが不合格なら、実装係に差し戻す

誰が、どの順で、何を受け取って、どこに渡すか。

この「配線図」を設計するのが、グラフエンジニアリングです。

シリーズ（2）のループが一人の作業サイクルだとすれば、グラフはそのループをいくつも束ねた組織図です。

ただし、注意点が一つあります。

エージェントを並列に走らせれば、そのぶんトークンも並列に消費されます。

分担を増やすほど、請求書も増えるのです。

以前「LLMルーター」の記事で書いたように、係ごとにモデルの大きさを変えるのは有効な手です。

そもそも単独のエージェントとしっかりしたハーネスで足りるなら、グラフを組まないほうがシンプルなこともあります。

チームを組む前に、一人で足りないのかを確かめる。

5. ソフトウェアファクトリー――深夜3時の判断を、翌朝説明できるか

ハーネスで一人の作業場を整え、グラフでチームを組む。

これを開発ライフサイクル全体に広げたものが、AIソフトウェアファクトリーです。

タスク管理、実装、テスト作成、セキュリティ確認、リリース。

各工程に専門のエージェントを置き、バトンリレーのように仕事を流していきます。

工場と聞くと、つい「全部自動で動くライン」を想像しがちです。

でも、本物の工場を支えているのは、ベルトコンベアだけではありません。

区切られた作業スペース。

社員証と入退室の管理。

そして、何かあったときにさかのぼれる記録。

ソフトウェアファクトリーにも、同じ3つが要ります。

特に効いてくるのが、3つ目の可観測性です。

朝出社したら、夜のあいだにエージェントがリポジトリを書き換えていた。

そのとき「深夜3時に、何を根拠に、どのファイルを変えたのか」を説明できるか。

説明できなければ、どれほど速いラインでも、安心して本番には流せません。

振り返ってみると、このブログで書いてきた権限制御やAgentOpsの話は、すべてこの工場の部品だったわけです。

工場の価値は、速さよりも「あとから説明できること」で決まる。

6. 明日からできること――工場を建てる前に、作業台を一つ

個人や小さなチームで、いきなりソフトウェアファクトリーを建てる必要はありません。

まずはハーネスの一番小さな部品から始めましょう。

• エージェントの失敗を1つ、環境の修正に変える：同じミスを注意し直すのではなく、AGENTS.mdやスキルにルールを書く、あるいはリンターやテストで機械的に止める
• エージェントの作業ログを残す設定にする：どのツールを呼び、どのファイルを変えたかを後から読めるようにしておく。これが可観測性の第一歩

どちらも、1時間あれば試せます。

失敗を言い直すのではなく、仕組みに刻む。それがハーネスづくりの最初の一歩。

7. 結論：新しい言葉の正体は、昔からある「段取り」

ハーネス、グラフ、ソフトウェアファクトリー。

並べると目新しく見えますが、中身をよく見ると見覚えのあるものばかりです。

テストハーネス、CIパイプライン、ワークフロー設計、権限管理、ログ監査......。

どれも、私たちが何十年もかけて磨いてきたシステム設計の知恵です。

変わったのは、そのライン上で働くのが人間ではなく、AIエージェントになったこと。

だからこそ、エージェントに仕事を任せるほど、伝統的なエンジニアリングの素養が効いてくるのだと思います。

シリーズ（1）で書いたように、開発者は「実装者」から「指揮者」へと移りつつあります。

今回の答えを一言でまとめるなら、こうです。

指揮者の次の仕事は、楽団が演奏し続けられる「ホール」を設計すること。

あなたの現場では、エージェントにどんな「作業台」と「記録」を用意していますか？

出典・参考

• 元記事：https://www.youtube.com/watch?v=SIZsFGvtClM
• Google：Google CEO says 75% of company's new code is AI-generated（Semafor, 2026年4月24日）
• Spotify：Spotify says its best developers haven't written a line of code since December, thanks to AI（TechCrunch, 2026年2月12日）
• ハーネスエンジニアリングの由来：Harness Engineering, Explained（BrainGrid）
• グラフエンジニアリング論文の解説：From Agent Harness to System Intelligence（TrueFoundry, 2026年8月28日）
• シリーズ本編：パイロットがPRを承認する時代（2）ループとコンテキスト