0xKyosuke Blog
プロンプト/ループ/ハーネスエンジニアリング——どこまで自分でやるべきか

プロンプト/ループ/ハーネスエンジニアリング——どこまで自分でやるべきか

まず言葉を分けないと議論が迷子になる

最近「ハーネス」って単語がやたら飛び交うでしょ。でも人によって指してるものが全然違うのよ。プロンプトの言い回しの話をしてる人もいれば、ツール呼び出しの手順を語ってる人もいるし、長時間セッションの再開やsandboxまで含めてる人もいる。

アタシはここで三層に切るわ。軸はシンプルよ——一回の入力なのか、ゴールまでの手順なのか、どう回し続けるかなのか。

  1. プロンプトエンジニアリング = 言い方の設計(一回の入力)
  2. ループエンジニアリング = 手順の設計(モデル→ツール→結果→またモデル)
  3. ハーネスエンジニアリング(狭義) = 運行装置の設計(どう回し続けるか)

この記事の立場も先に言っとくわ。ループまでは実務の本丸で、自分でやるべき。狭義のハーネス自作は大半の用途ではデフォルトで足りる。 自作が要るのは、データが外に出せない・独自の権限監査が要る・デフォルトにない運行が必須なときだけ、って感じよ。

ちなみに以前書いた Anthropicのハーネス設計論文の話 は、生成と評価を分けるって角度だったわ。今回はそこじゃなくて、「プロンプト/ループ/運行」の三層と、どこまで自分で握るかの話よ。別軸ね。

プロンプト:一往復の言い方

プロンプトエンジニアリングは、モデルに渡す一回分の言い方を整えることよ。役割、制約、出力形式、例示。ここは今でも効くわ。雑な指示より、境界がはっきりした指示の方がブレにくい。

でもプロンプトだけで「長い仕事」は終わらないの。一発で完璧な成果物が出る世界なら別だけど、現実はツールを叩き、結果を見て、次の手を考える。つまりループに入る。

ループ:無意識にやってることの言語化

ループエンジニアリングは、モデル→ツール→結果→またモデルの手順を設計することよ。スキル化とか作業の抽象化に近い。ChatGPTやCodexの裏で回ってるアレ、って言えば伝わる? 表面はチャットでも、中では「読む→直す→試す→また読む」が何度も回ってるわ。

ホテルの例えがわかりやすいわよ。

  • 「渋谷で泊まれそうなホテルを3つ教えて」→ 一往復。探すだけ。
  • 「予算と日付で予約まで完了して」→ ゴールまでループ。空き確認、比較、予約、確認メール…手順が続く。

大事なのは「手順の中身」そのものより、誰がループを持つかなの。人が毎回「次はこれやって」って投げてるなら、ループの持ち主は人。エージェントに「予約まで」とタスクを渡して中で回させるなら、ループの持ち主はエージェント側(あるいはそのアプリ)よ。

で、アタシが思うに、みんな無意識にループエンジニアリングしてるの。プロンプトに「まず調査して、次に案を出して、最後にレビューして」って書くのもループの種。スキルやカスタム指示で「この種の仕事はこの順番」と固定するのもループ。マルチエージェントでPMがサブに振り、評価して差し戻すのも、結局はオーケストレーション手順=ループよ。運行装置の話じゃない。

レシピとキッチン:手順を足す vs 運行を足す

ここが混同ポイントよ。

  • 手順(ループ)を足す = レシピを足す。消したら、何をどの順でやるか(中身)が消える。
  • 運行(狭義ハーネス)を足す = キッチンを足す。消したら、回す力(再開・隔離・観測など)が消える。中身のレシピは別。

「エージェントを強くしたい」ってときに、レシピを厚くしてるのかキッチンを作り直してるのかを分けて考えないと、薄い while を「自作ハーネス」って盛っちゃうことになるわ。それは別問題。便利なこともあるけど、本番級のデフォルト運行の代替にはならないのよ。

狭義ハーネスって何が入ってるの

アタシが狭義でハーネスと言うときは、だいたいこのへんよ。

  • 再開(recovery) — 落ちても続きから
  • 文脈圧縮(compaction) — 長くなっても仕事の芯を残す
  • sandbox / 隔離 — 危ない操作を囲う
  • 権限ゲート — 何を許可し、何を人に聞くか
  • 観測 — 進捗・失敗・コストが見える
  • 長時間セッション — 何時間でも同じ仕事として続ける土台

モデルが賢くても、ここが弱いと長い仕事は崩れる。逆に言うと、OpenAIやCursorみたいな製品が提供してるデフォルト運行は、この層をかなり持ってる。だから「ハーネスを自作したい」欲求の多くは、実はループ(レシピ)不足だったりするわ。

動画で対比すると一発でわかる

文章だとふわっとしやすいから、動画制作で切るわよ。ここ重要。

スキル/ループ側(台本→編集→書き出し)

これは手順よ。

  1. 台本を書く
  2. 素材を揃える
  3. カットを組む
  4. 字幕を入れる
  5. 書き出す

「この順番でやってね」をスキルや指示に落とす。消したら、動画の作り方(中身)が消える。これがループエンジニアリング。

本物の動画ハーネス(運行装置)

こっちはキッチンよ。

  • 長時間レンダーの再開 — 3時間エンコードが落ちても続きから
  • ffmpeg / GPU sandbox — 重い処理を隔離して回す
  • 生動画を文脈に載せない — プロキシやシーン検出で要約し、トークン爆発を防ぐ
  • 成果物パイプライン — 中間ファイル、最終mp4、メタデータの置き場と受け渡し
  • 進捗観測 — 何パーセント終わったか、どこで詰まったか

スキルだけあっても、レンダーが落ちたら終わり。ハーネスだけあっても、台本→編集の手順がなければ何を回すかわからない。両方いるけど、役割が違う。ここを混ぜると「ハーネスを自作した」つもりでレシピだけ書いてる、が起きるわ。

どこまで自分でやるべきか

アタシの意見、はっきり書くわ。

ループまでは必須っぽい/実務の本丸

仕事の型はドメイン依存よ。アンタのリポジトリ、アンタのレビュー基準、アンタの「完了」の定義。ここを言語化してループに落とすのは、プロダクト差別化そのもの。プロンプトの一往復だけだと足りない場面が増えてる今、手順の設計ができる人が強い。

ハーネス自作は難易度が高く、大半はデフォルトで足りる

狭義ハーネスは、再開・圧縮・隔離・権限・観測・長時間をまともにやると重い。OpenAIのマネージド運行や、CursorみたいなエージェントIDEのデフォルトは、ここをすでに持ってる。大半の用途ではそれを借りればいい。

自作が要る典型はこれくらいよ。

  • データを外に出せない(閉域・社内ポリシー)
  • 独自の権限監査や承認フローが必須
  • デフォルトにない運行(特殊なGPUパイプライン、独自再開戦略など)が仕事の前提

「薄い while を自作ハーネス」と呼ぶのは用語のインフレ。学習用や試作ならいいけど、デフォルトの代替だと思うな、って話。

汎用モデル+専用ハーネスが効く場所

最後に軽くだけ。汎用モデルに専用ハーネスを被せるのが効くのは、だいたい手順が難しいときよ。長い調査、複数ツール、差し戻し、成果物の組み立て。逆にレントゲンの異変検出みたいな知覚タスクは、運行より専用モデル側の話になりやすい。本線はあくまで三層と「どこまで自分でやるか」ね。

まとめ

  • プロンプト = 言い方(一回)
  • ループ = 手順(ゴールまで回すやり方)。スキルやマルチエージェントのPM差し戻しもここ
  • 狭義ハーネス = 運行装置(再開・圧縮・隔離・権限・観測・長時間)
  • レシピを足すのかキッチンを足すのかを混ぜない
  • 動画なら「台本→編集→書き出し」はループ、「レンダー再開/GPU sandbox/プロキシ」はハーネス
  • ループまでは自分でやる価値が高い。ハーネス自作は条件付き

言葉を揃えるだけで、「何をチューニングすべきか」が一気にクリアになるわよ。次は運行装置を借りる側の話——OpenAI Agents APIが何をマネージドにしてくれるか——を別記事で整理するわ。

記事一覧へ