Harness × Context Engineering

紡ぎエンジニアリング

Tsumugi Engineering

ハーネスエンジニアリング（制御構造）とコンテキストエンジニアリング（情報基盤）を統合し、 AIエージェントチームが厚い文脈の中で自律的に稼働し、相互にチェックし合う仕組みを設計する技術体系。 糸車で糸を紡ぐように、複数の専門視点を撚り合わせて、最高品質の成果物を紡ぎ出す。

3層コンテキスト 品質ゲート フィードバックループ エスカレーションパス GCTMS統合 2層アーキテクチャ

01定義と位置づけ

# 厚い文脈 × 自律制御で、最高品質の成果物を紡ぎ出す

紡ぎエンジニアリングとは、AIエージェントが厚い文脈の中で自律的に稼働し、相互にチェックし合う仕組みを設計する技術体系である。 制御構造が「走り方」を守り、情報基盤が「方向」を定める。両輪が揃うことで、エージェントは正しい方向に自律的に走る。

紡ぎエンジニアリング（Tsumugi Engineering）
「厚い文脈 × 自律制御で、最高品質の成果物を紡ぎ出す」
ハーネスエンジニアリング
制御構造
  • 品質ゲート
  • ガードレール
  • フィードバックループ
  • エスカレーションパス
コンテキストエンジニアリング
情報基盤
  • 3層コンテキスト
  • 情報の流れの設計
  • 参照ドキュメント体系
  • ライブ情報の取り込み
▼
プロンプトエンジニアリング
個々の対話の技術
制御構造が「走り方」を守り、情報基盤が「方向」を定める。
両輪が揃うことで、エージェントは正しい方向に自律的に走る。

023技術の比較と紡ぎのメタファー

# 馬・地図・馬具、そして糸車

3技術の比較

技術比喩問い対象
プロンプトエンジニアリング馬への「声かけ」この1回、どう指示するか？単発の対話
コンテキストエンジニアリング馬に見せる「地図と荷物」何を背負わせ、どの道を見せるか？情報の流れ
ハーネスエンジニアリング馬具（手綱・鞍・柵）の設計馬が自分で走っても安全な仕組みをどう作るか？制御構造全体
紡ぎエンジニアリング糸車で糸を紡ぐ一連の工程厚い文脈の中で、自律的に最高品質を出し続けるには？情報基盤 + 制御構造の全体

紡ぎのメタファー

糸車で糸を紡ぎ、布を織り上げる工程の一つひとつが、設計要素に対応する。

紡ぎの工程対応する設計要素
原料（繊維）コンテキスト — 設計書、参加者情報、前回の成果、最新情報
糸車の枠組みハーネス — 品質ゲート、ガードレール、エスカレーションパス
紡ぎ手AIエージェントチーム — 各専門視点からの制作・レビュー
よりをかけるフィードバックループ — 相互チェックで品質を高める
糸の検査品質検査官のクロスレビュー — 矛盾・漏れ・品質低下の検出
撚糸エージェントチームの統合 — 単一視点では出せない品質の実現
織り上がった布完成した成果物 — 全体として一貫性のある高品質なアウトプット

039ステップ思考プロセス

# 「紡ぎエンジニアリングで設計して」と指示されたら、この全ステップを順に思考する

コンテキスト設計 — 情報基盤を整える（Step ①〜③）
1
プロジェクトコンテキストの確認不変の前提（ミッション・KPI・関係者・思想）を読み込む
2
セッション/タスクコンテキストの構築当該タスク固有の情報（GOAL・前提条件・次への接続）を整理する
3
ライブコンテキストの取り込み最新の状況（フィードバック・制約変更・環境変化）を反映する
ハーネス設計 — 制御構造を組む（Step ④〜⑦）
4
自律の範囲を定義する各エージェントが自分で判断してよい範囲と、人間に聞くべき範囲
5
ガードレールを設計する品質ゲート（チェック項目・合格条件・不合格時処理）
6
フィードバックループを設計するエージェント同士の相互チェックの仕組み（種類・最大回数）
7
エスカレーションパスを設計するガードレールに触れたとき、誰に・どう伝えるか
プロンプト設計 — 個々の対話を書く（Step ⑧〜⑨）
8
コンテキストの流れを設計する各エージェントに「いつ・何を・どの順番で」渡すか
9
個々のプロンプトを設計する①〜⑧が確定して初めて、具体的な指示文を書く

各手法が対象とするステップ

手法対象ステップ結果
プロンプトエンジニアリング⑨のみその場限りの良い出力
コンテキストエンジニアリング①〜③ + ⑧⑨再現性のある良い出力
ハーネスエンジニアリング④〜⑨自律的だが文脈が薄い
紡ぎエンジニアリング①〜⑨の全て厚い文脈の中で自律的に最高品質を出し続ける

043層コンテキストモデル

# 各エージェントが作業開始前に読み込む情報を、更新頻度に応じた3層で管理する

Layer 1プロジェクトコンテキスト不変の前提 — プロジェクト全体を貫く「北極星」

ミッションと哲学 / KPIと到達目標 / 関係者のプロフィール / 思想・原則 / 技術スタックと制約。原則変更なし。

Layer 2タスクコンテキストタスク毎 — 「今回の戦場」の地図

GOAL / 前タスクからの引き継ぎ / 次タスクへの接続 / 設計制約 / 対象者の現在地。タスク開始時に構築する。

Layer 3ライブコンテキスト随時更新 — 「今この瞬間」の最新情報

フィードバック結果 / 実際のスキル・進捗 / 制約変更 / つまずき報告・想定外の事態。情報が得られ次第、即時反映。

ライブ取り込みルール

情報が入った時点で、プロデューサーが「ライブ更新」を全エージェントに通達。 品質ゲート通過前なら即時反映、通過後なら次のフィードバックループで反映する。

05ハーネス設計 — 制御構造の4要素

# 自律の範囲 / 品質ゲート / フィードバックループ / エスカレーションパス

5-1. 自律の範囲定義

各エージェントに「自分で判断してよいこと」と「人間に確認が必要なこと」を明確に定義する。

人間へのエスカレーション条件（共通の絶対ルール）

  1. プロジェクトの根幹設計の変更が必要な場合
  2. スケジュール・時間配分の変更が必要な場合
  3. KPIの達成が困難と判断される場合
  4. 個人情報に基づく判断が必要な場合
  5. 予算・リソース配分の変更が必要な場合

5-2. 品質ゲート設計

各ステップ間に設置する自動チェックポイント。

チェック項目合格条件不合格時の処理
何をチェックするかどうなっていればOKかNGの場合の具体的アクション

5-3. フィードバックループ設計

3種類のループで構成する。

Loop A — 即時フィードバック（同ステップ内）

# 自己チェックして自動修正
エージェントが成果物を作成 → 自己チェック（品質ゲート） → 不合格なら自動修正
最大回数: 3回（3回で解決しない場合はエスカレーション）

Loop B — 相互フィードバック（ステップ間）

# 専門視点で他エージェントをレビュー
前ステップの成果物を受け取る → 専門視点でレビュー → 指摘を返す → 修正 → 再レビュー
最大回数: 2回（2回で解決しない場合は上位エージェントが介入）

Loop C — 横断フィードバック（全体レビュー）

# 全成果物を横断チェック
全成果物を横断チェック → 不整合を検出 → 関係エージェントに修正指示 → 最終承認
最大回数: 1回（残課題はプロデューサー判断）

5-4. エスカレーションパス設計

通常フロー:
  エージェント → 品質ゲート → PASS → 次のステップへ

自動修正フロー:
  エージェント → 品質ゲート → FAIL(軽微) → 同エージェントが自動修正 → 再チェック

エスカレーションフロー:
  エージェント → 品質ゲート → FAIL(重大) → 品質検査官が判定
    → 軽度 → 担当エージェントに修正指示
    → 重度 → プロデューサーに報告 → 人間に判断を仰ぐ

レビュー指摘の重大度

レベル意味対応
BLOCKこのままでは成果物が成立しない即時修正必須。制作フローを一時停止
WARN品質低下のリスクがある次ステップまでに修正
SUGGESTより良くなる提案採否はプロデューサー判断

06エージェントチーム設計

# 最低限必要な役割と、エージェント定義テンプレート

役割責務
プロデューサー全体統括。一貫性と品質の最終責任者。エスカレーション先
専門エージェント群各領域の制作を担当。プロジェクトの性質に応じて定義
品質検査官全成果物のクロスレビュー。矛盾・漏れ・品質低下の検出

エージェント定義テンプレート

### [エージェント名]（[English Name]）

**一言:** [このエージェントの存在意義を1文で]

| 項目     | 内容              |
|----------|-------------------|
| 専門領域 | [何の専門家か]    |
| 入力     | [何を受け取るか]  |
| 出力     | [何を生み出すか]  |

**責務:**          [箇条書きで列挙]
**判断基準:**      [「良い/悪い」を判断する問い]
**コンテキスト読み込み仕様:**
| Layer 1（必須） | Layer 2（必須） | Layer 3（該当時） |

07制作ワークフロー設計

# ステップ + 品質ゲートの統合フロー

Step N: [エージェント名]
  └→ [作業内容]
  └→ [Loop A] 自己チェック → 自動修正（最大3回）
       ┃
  ═══ Gate N ═══ [チェック項目]
       ┃
Step N+1: [次のエージェント名]
  └→ [作業内容]
  └→ [Loop B] 指摘 → 修正 → 再レビュー（最大2回）
       ┃
      ...
       ┃
  ═══ Final Gate ═══ [全体チェック]
       ┃
Final Step: プロデューサー
  └→ 最終統合・承認
  └→ [人間へのエスカレーション] 必要に応じて判断を仰ぐ

自律稼働ルール

ガードレール内（自動で進む）
  • 品質ゲートを全てPASS → 次ステップに自動遷移
  • SUGGEST は担当エージェントが採否を決定
  • WARN は担当が修正し品質検査官が確認
ガードレール外（停止して確認）
  • BLOCK 発生時は制作フローを一時停止
  • 人間へのエスカレーション条件に該当
  • フィードバックループが最大回数に達しても未解決

08コミュニケーション規約

# 発言フォーマットと起動時の宣言フォーマット

発言時のフォーマット

【エージェント名】
対象: （どの成果物・どのタスクについてか）
---
（本文）

起動時の宣言フォーマット

【プロデューサー】制作フロー起動
対象: [タスク名]
期限: [期限]（残り[N]日）
参照: [参照ドキュメント]
制約: [時間枠・特記事項]
---
Step 1 → [最初のエージェント名]、開始してください。

09適用ガイドライン

# いつ使うか・どの規模で使うか・どう改善し続けるか

紡ぎエンジニアリングが有効なケース

  • 複数の専門視点が必要な成果物の制作
  • 品質基準が高く、相互チェックが必要なプロジェクト
  • 長期間にわたる並行開発
  • 1人の視点では見落としが発生しやすい複雑なタスク

適用の規模感

プロジェクト規模推奨構成
小規模（単発タスク）プロンプトエンジニアリングで十分
中規模（複数成果物）コンテキストエンジニアリング + 簡易ガードレール
大規模（複数ステークホルダー・長期）紡ぎエンジニアリング（フル適用）

ハーネスの継続的改善

品質ゲートやエスカレーション条件は固定ではない。以下のタイミングで見直す。

  • タスク完了ごとに、品質ゲートの有効性を振り返る
  • 人間へのエスカレーションが頻発する場合、自律範囲の再定義を検討
  • エスカレーションがゼロの場合、ガードレールが緩すぎないか検証

10GCTMSフレームワークとの統合

# Guard / Context / Tools / Memory / Supervision との2層アーキテクチャ

GCTMSと紡ぎエンジニアリングには「重複」と「補完」がある。 重複を除いた後に見える2層構造が設計の本質である。

10-1. 重複と補完

重複（どちらか一方で設計）
  • ガードレール ↔ G: Guard
  • 3層コンテキスト ↔ C: Context
  • Loop C ↔ S: Supervision（測定のみ）
補完（両方が必要）
  • T: Tools — ツール契約の明示的定義（入力/出力/エラーコード）
  • M: Memory — 短期/長期メモリーの分離設計

10-2. 2層アーキテクチャ

ORCHESTRATION LAYER — Tsumugi担当
品質ゲート → フィードバック Loop A/B/C → HITL / エージェントチーム協働 / エスカレーションパス
「エージェントたちがどう協働し、どこで止まるか」
INFRASTRUCTURE LAYER — GCTMS担当
G: Guard（入口/出口制御） ·  T: Tools（コントラクト定義） ·  M: Memory（短期/長期分離） ·  S: Supervision → G改善（監視・計測・改善ループ）
「エージェントが使う道具・記憶・柵・観測機器」
接合点 — 真のイノベーション

① M → G メモリー駆動型ガード進化 ／ ② T × C ツール・コンテキスト結合 ／ ③ M × Phase/State フェーズ結合メモリー

10-3. 3つのイノベーション

①

メモリー駆動型ガード進化

Guardが「静的なルール集」から「観測により更新されるポリシー」になる。

M（アラート履歴の長期記録） ↓ 月次集計: getMonthlyAlertSummary() 最頻発違反TOP3 + guardRecommendations を自動抽出 ↓ G（ガード定義）を次月に更新 → 自己進化するガードレール

記録時に Phase・Operation・AutoResolved・HumanIntervention を残し、月末にTOP3違反を抽出。guardRecommendations（BLOCK3回以上→事前ゲート追加、WARN5回以上→BLOCK昇格）を人間が確認して更新する。

②

ツール・コンテキスト結合

各ツールが「最小必要コンテキスト」だけを受け取る設計が可能になる。

Tool Contract（関数の入力/出力/エラー定義） × Context Layer（どのコンテキストをどのツールに渡すか） ↓ T×C対応表: 必読Context / ライブデータ / 読み込み禁止

各ツールのコントラクトを定義し、T×C対応表で「必読」「ライブ」「禁止」を関数ごとに明記。エージェントは呼び出し前に対応表を参照してコンテキストを絞り込む。

③

フェーズ結合メモリー

メモリーが不可逆なPhase遷移と結合し、AIが状態を自己把握できる。

M（ScriptProperties / 長期メモリー） × 不可逆Phase遷移（Phase 0→1→2→...） ↓ getPhaseState() → AIが「今どのPhaseにいるか」を自己把握 getContextForPhase() → Phase対応の最小コンテキストを自動選択

Phase完了時に setPhaseState() で永続化し、次回セッション開始時に getPhaseState() でPhaseを自己確認。getContextForPhase() で必読specsとライブデータを自動絞り込む。

10-4. 統合時の設計チェックリスト

  • OrchestrationとInfrastructureの役割分担が明確か（2層を混在させていないか）
  • 重複（G↔ガードレール, C↔3層コンテキスト）を2重定義していないか
  • ① アラート記録にPhase・Operation・AutoResolved・HumanIntervention列があるか
  • ① 月次集計関数で guardRecommendations が出力されるか
  • ② T×C対応表が関数ごとに「読み込み禁止」まで定義されているか
  • ③ Phase完了時に状態永続化が呼ばれているか
  • ③ getContextForPhase() がPhaseごとの最小specセクションを返すか