AI要件コンパイラ：昇格判定の基準定義

〜依頼の「重さ」に合わせて、AI活用の構造（厚み）を正しく選ぶ〜

1. 四つの出口（アウトプット形式）の定義

依頼をどの構造で扱うべきか、その「厚み」を4段階で定義します。

出口	定義	向いている仕事	核心的な価値
Prompt	単発・短寿命の指示	一回きり、失敗コスト低、人間がその場で採点	軽さ（即時性・修正容易性）
Generation Field	生成のための局所環境	繰り返し、文体や評価基準の安定が必要	場の維持（品質の安定・文脈維持）
Skill	再利用可能な実行単位	単一責務、安定した入出力、実行範囲が明確	再利用性（境界の明確化・部品化）
Harness	持続運用の構造	状態保持、外部接続、承認、監査が必要	堅牢性（信頼性・説明責任）

2. 昇格判定を左右する「六つの軸」

感覚ではなく、以下の6つの観点から「どの厚みが必要か」を判断します。

失敗コスト: 外した時の被害が局所か、後工程に響くか。
反復性: 一回きりか、日次・週次で何度も発生するか。
承認の有無: 人間が最後に見るだけか、途中で止めて差し戻す必要があるか。
接続の重さ: 外部システム、API、社内データの更新を伴うか。
評価の明示性: 人間の感覚で良いか、明確な基準（ルーブリック）での自動判定が必要か。
証跡の必要性: なぜその判断をしたか、履歴や説明責任が求められるか。

3. 昇格判定の最小手順（クイック診断）

依頼を受けたら、以下のフローで「出口」を特定します。

Step 1: Prompt で済ませるか？

一回きりの仕事か？
失敗してもその場で直せば済むか？
YES → Prompt

Step 2: Generation Field か Skill か？

何度も同じ型で発生するか？
- 広い文脈や独自の評価視点を束ねた「場」が必要か？ → Generation Field
- 単一責務で、入出力が安定した「部品」として切り出せるか？ → Skill

Step 3: Harness まで昇格させるか？

以下のいずれかに当てはまるか？
- 途中で止める、再開するなどの「承認フロー」がある
- 外部システムへの書き込みなど「接続」が重い
- 監査のための「証跡」を残す必要がある
YES → Harness

4. よくある誤配線（アンチパターン）

Harness問題をPromptで解く: 言い回しを工夫しても、状態管理や承認の欠如は解決しない。
Skillで切るべきをGeneration Fieldで抱える: 境界が曖昧になり、再利用性が低下する。
Generation Fieldで見るべきをSkillに切りすぎる: 文脈が痩せてしまい、全体として機能しなくなる。
Prompt問題を最初からHarnessにする: 過剰な構造は保守コストだけを増大させる。

一回きりで、失敗コストが低く、人間がその場で目視採点できるなら prompt で足ります。
繰り返し発生し、出力の型や人格や評価軸を安定させたいなら generation field が要ります。
単一責務で、入力と出力をある程度固定でき、同じ手順を何度も再利用したいなら、skill が要ります。
状態をまたぎ、外部接続があり、承認・再開・監査・改善まで含めて回したいなら harness が必要です。

ご提示いただいたテキストに基づき、特に混同されやすい**「Skill」と「Generation Field」**の違いに焦点を当てて整理します。

この二つは、単発の Prompt 以上、重厚な Harness 未満の中間層に位置しますが、その**「役割」と「構造」**が明確に異なります。

1. 概念の比較：場（Field）か、部品（Skill）か

項目	Generation Field（生成場）	Skill（スキル）
本質的な役割	特定の知能を立ち上げる「場」	単一責務の「実行単位」
主な目的	文脈・人格・評価基準の安定	安定した I/O（入出力）の再利用
構造のイメージ	広い「面」による支え	鋭い「線」による接続
適したメタファー	熟練の職人が座る「作業机」	誰でも使える「専用の工具」

2. Generation Field（生成場）の詳細

単なる「長い指示」ではなく、生成に必要な要素をパッケージ化した局所環境です。

なぜ必要か: 「毎回、文体や観点を説明し直したくない」「アウトプットの質を高い水準で安定させたい」という場合に機能します。
構成要素:
- 役割: どのような立場で振る舞うか（人格）。
- 文脈: 参照すべき膨大な背景知識や前提。
- 制約: 守るべきルールや禁止事項。
- 評価視点: 何をもって「良し」とするかの審美眼。
具体例:
- 自分の思想や過去の記事を学習させた「ブログ執筆専用の場」。
- 特定の企業のブランドトーンを完全にトレースする「コピーライティングの場」。

3. Skill（スキル）の詳細

特定の入力を受け取り、決まった形式で返す再利用可能なモジュールです。

なぜ必要か: 「この工程だけは毎回同じ手順でやりたい」「他のフローでも使い回したい」という場合に、境界を明確にして切り出します。
構成要素:
- 安定 I/O: 「これを入れたら、これが返ってくる」という明確な定義。
- Bounded Execution: 実行範囲が限定されており、迷いがない。
- 単一責務: あれこれ欲張らず、一つの仕事（抽出、変換、整形など）に特化する。
具体例:
- 「長い議事録から、宿題（Action Items）だけを抜き出す」
- 「日本語の技術文書を、エンジニアが読みやすい英語に翻訳する」

4. 両者の関係性と「昇格」の考え方

この二つは、独立した「出口」であると同時に、相互補完的な関係にあります。

Skill は「部品」にもなる

Skill は単体で完結する出口ですが、将来的に Harness（持続運用構造） を構築する際の強力な「実行パーツ（Executor）」として組み込むことができます。この接続性の高さが Skill の強みです。

誤配線の見分け方

「場」を Skill に切りすぎる: 文脈が削ぎ落とされ、生成物が「痩せて」しまいます。全体の一貫性が失われ、ぎこちない出力になります。
「部品」を Field のままにする: 本来シンプルに終わるはずの処理が、広すぎる文脈に引っ張られて毎回揺らぎ、他のタスクから呼び出しにくくなります。

判定のヒント

その依頼は、**「深い理解と一貫性」**を求めていますか？ → Generation Field

その依頼は、**「確実な処理と再利用性」**を求めていますか？ → Skill

prompt example

この文章を短くする
会議メモを300字で要約する
タイトル案を10本出す
仕様の抜けを指摘する
コード断片のバグ原因を推定する

generation field example

毎週の市場観測を、同じ視点で整理したい。
note 記事を、自分の思想・構成・読者像に合わせて安定して書かせたい
図解の前に、何を残し何を捨てるかを先に固定したい
スライド生成で、構成・差し込み・検査を分けて回したい

skill example

議事録から action item だけを抽出する
週次レポート用に decision / risk / next action を整形する
note 記事本文からハッシュタグ候補を作る
PR 説明文の下書きを一定フォーマットで出す
仕様変更点からテスト観点のたたきを作る

harness

状態を持った実務単位
どこで止めるか、誰が承認するか、何を見せ、何を隠すか、どこから再開できるか、何を成功とみなすか、その判断をどこに残すか
状態回路・制御回路・接続回路・評価回路・それを後から追える証跡基盤
AI を壊れにくく、戻しやすく、監査しやすく、改善しやすくする仕組み

昇格判定を左右する「六つの軸」：深掘り解説

1. 失敗コスト（Impact of Failure）

「間違えた時に、誰がどれだけ困るか」というリスクの広がりを評価します。

Prompt（低）: その場で人間がリトライすれば済む。被害は「数秒のロス」のみ。
Harness（高）: 誤った数値がDBに書き込まれる、顧客に失礼なメールが自動送信されるなど、被害が外部や後工程に波及する。
昇格の力学: 失敗コストが上がるほど、**「評価回路（自動検知）」や「承認回路（人間による停止）」**を備えた構造へ昇格させる圧力が強まります。

2. 反復性（Repeatability）

「その仕事は、明日も来週も、同じ手触りで発生するか」という再現性の必要量を評価します。

Prompt（低）: 一期一会の問いかけ。二度と同じ文脈は来ない。
Generation Field / Skill（中〜高）: 毎週のレポート、毎日のコードレビュー。
昇格の力学: 反復性が高いほど、毎回「前提」を説明するコストが膨らみます。この説明コストをゼロにするために、**「場（Field）」として固定するか、「部品（Skill）」**としてパッケージ化する必要があります。

3. 承認の有無（Approval Workflow）

「人間がどの地点で、どの程度の粒度で判断に介入すべきか」を評価します。

Prompt: 介入は「出力された後」のみ。
Harness: 「観測→判定→（承認）→実行」のように、プロセスの中間にゲートが必要。
昇格の力学: 中間承認や「差し戻し（リトライ）」が発生するなら、それは単なるテキスト生成ではなく**「状態（ステート）」の管理**です。会話形式を捨て、Harness構造へ昇格させる決定的な要因となります。

4. 接続の重さ（Connectivity）

「AIが外界（ツール、データ、権限）をどれだけ触るか」という干渉範囲を評価します。

Prompt: AIの内部知識のみで完結。
Skill: 特定のファイルを読む、特定のAPIを叩く（単一の道具箱）。
Harness: 社内システムを横断し、複数のDBを読み書きする（重機を動かす権限）。
昇格の力学: 接続先が増えるほど、**「露出管理（見せていいデータ）」と「権限管理（実行していい操作）」**を厳格に定義する必要が生じます。

5. 評価の明示性（Evaluation Rubric）

「何が良い出力か」を言語化・数値化できる度合いを評価します。

Prompt: 人間が読んで「なんとなく良い」と直感で判断。
Generation Field: 「この5つの視点が含まれているか」というチェックリストがある。
Harness: 評価指標がプログラムで記述され、基準に満たない場合は自動で再実行される。
昇格の力学: 「良さ」の定義が明確になればなるほど、それは「人の感性」を離れ、**「評価回路」**としてシステムに組み込むことが可能になります。

6. 証跡の必要性（Audit Trail）

「後から『なぜそうなったか』を説明する必要があるか」という監査性を評価します。

Prompt: 答えが出れば過程は消えても良い。
Harness: 1ヶ月前の判断根拠を遡る必要がある。法規制や社内コンプライアンスが絡む。
昇格の力学: 証跡が必要な仕事は、単なる「便利な自動化」ではなく「業務執行」です。**「証跡基盤」**を持つHarnessの上で転がさない限り、実務での信頼性は担保できません。

昇格マトリクス（実務判定用）

六つの軸をスコアリングした際の、出口のイメージです。

軸	Prompt (1点)	Field/Skill (3点)	Harness (5点)
失敗コスト	ほぼゼロ	チーム内での手戻り	顧客影響・金銭的損失
反復性	今回限り	定期的・頻繁	常時稼働・標準プロセス
承認	不要（事後確認）	最終成果物のみ確認	工程ごとの承認・再開
接続	なし	読み取り専用	書き込み・複数接続
評価	主観的	ガイドラインあり	自動評価・スコアリング
証跡	不要	履歴があると嬉しい	厳格なログ保持・説明責任

実践のヒント：合計点で見極める

合計 6〜12点: Prompt で十分。構造を重くするのは時間の無駄。
合計 13〜22点: Generation Field または Skill。知能の安定か、機能の切り出しを行う。
合計 23点以上: 迷わず Harness。言い回しの工夫（Prompt Engineering）で解決しようとするのは「誤配線」の極みです。

ご提示いただいた「AI要件コンパイラ #2」は、AI活用の成否を分ける**「入口設計（Input Design）」**に焦点を当てた重要なステップです。

「相談文」というノイズの多い情報を、設計可能な「signal（信号）」へと変換するプロセスを構造化して整理します。

1. 入口設計の核心：相談文は「仕様」ではない

現場から届く相談文には「熱（痛みや期待）」がありますが、そのままではAIの設計図にはなりません。

問題点: 相談文をそのままプロンプトにすると、AIも曖昧に応え、再現性も評価も得られない。
解決策: 相談文を否定せず、そこから**後続の設計判断を変える情報（signal）**だけを抽出する。

2. 抽出対象：八つの signal

依頼を分解し、以下の8つの観点で「信号」を抜き出します。これらが埋まることで、後段の「昇格判定」が可能になります。

signal	問いの内容	抽出する意味
1. 痛み	何が今つらいのか？	解くべき問題の核心を特定する
2. 目的	何を変えたいのか？	作業削減か、判断の質向上か、方向を定める
3. 境界	どこまでが対象で、何が外か？	過剰設計を防ぎ、スコープを定義する
4. 承認	誰が Yes/No を出すのか？	運用が回るかどうかの生命線を確保する
5. 接続	外部システムと繋がるか？	Prompt か Harness かの境界を見極める
6. 評価	何をもって成功とするか？	改善を「雰囲気」から「データ」に変える
7. 証跡	履歴を残す必要があるか？	監査性や説明責任の重さを決める
8. 不確実性	何がまだ未確定か？	曖昧さを「未確定事項」として明示する

3. signal 抽出の3ステップ

具体的に相談文をどう「ほどく」か、その思考プロセスです。

「事実」「願望」「仮説」を分ける
- 現実（事実）、理想（願望）、原因の推測（仮説）を混同しない。
名詞を「動詞」に戻す
- 「効率化」「自動化」といった便利な名詞を、「何を減らす」「何を判断する」という具体的なアクションに分解する。
判断を変える「問い」へ並べ替える
- 抽出した断片を、上記の「八つの signal」のフレームに当てはめる。

4. 入口設計の失敗パターン（アンチパターン）

解決策から入る: 「Slack連携したい」などの手段に飛びつき、本来の目的を見失う。
情報を増やす＝正確だと思い込む: 大量の背景情報を集めても、signal と noise が分離できていなければ混線するだけ。
不確実性を消してしまう: 分からないことを無理に仕様として断定し、後段で致命的な破綻を招く。

5. 入口設計の効果（実例）

相談例: 「会議後のタスクが曖昧。議事録はあるが、結局確認し直している。AIで整理したい」

入口設計前: 「議事録を整理する便利なプロンプト」を作ろうとしてしまう。
入口設計後: 「担当・期限付きタスクの抽出と、PMによる承認フローを支援する構造」が必要だと判明する。

ご提示いただいた「AI要件コンパイラ #4」は、曖昧な相談文を実行可能な構造へと変換するための**中間表現「Requirement IR（Intermediate Representation）」**を定義する重要なステップです。

「曖昧さを消す」のではなく「曖昧なまま管理可能な形に置き直す」という思想に基づき、内容を構造化して整理します。

1. Requirement IR の役割

相談文（人間の言葉）と実行構造（Prompt/Harness等）の間を繋ぐ中間層です。

目的: 相談文に含まれる感情・事情・期待を分離し、「この依頼を何として扱うか」という意味の骨格を固定する。
本質: 完璧な設計書を作ることではない。実装が変わっても壊れない「最小限の契約」を結ぶこと。
回避すべきこと: 曖昧さを無理に消して「不明な点を確定事項として扱う」リスクを避ける。

2. Requirement IR が持つべき「7つの最小契約」

下流の設計（Prompt, Field, Skill, Harness）へ渡す際、必ず定義すべき要素です。

要素	定義	記述のポイント
Objective（目的）	何を達成したことにするか	「便利に」ではなく「〇〇が××できる状態」と書く
Scope（範囲）	どこまでを扱い、何を除くか	除外範囲（Exclusion）の明示が品質を決める
Constraints（制約）	何を破ってはいけないか	権限・規程・データ。Hard/Soft の強度を分ける
Approvals（承認）	どこで人間が止めるか	停止・介入ポイントを runtime 前に定義する
Evaluation（評価）	何をもって「良い」とするか	感想戦を避け、判定軸を設計前に置く
Evidence（証拠）	何を根拠に動くか	知識源の指定と、後から追跡できる証跡の設計
Uncertainty（不確実）	何が未確定か	保留ではなく「次に観測・検証すべき項目」として宣言

3. 良い IR と悪い IR の見分け方

❌ 悪い IR（きれいすぎる、中身が空）

「社内窓口を作り、効率を改善。正確に回答する。」

問題点: 「正確」の定義、承認の場所、不明な点などが一切固定されていないため、下流のAIや設計者が勝手に推測して動く（＝事故の元）。

✅ 良い IR（不格好でも、境界が明確）

「〇〇部署の規程のみを対象とする（XXは対象外）。根拠資料がない場合は回答を停止する。誤答リスクが高いため、最終回答前に人間が承認する。現在、資料の更新頻度が不明な点がリスクである。」

利点: 曖昧さが「管理可能なリスク」として記述されており、運用の手綱を握れる。

4. Requirement IR に「入れないもの」

このフェーズで実装詳細（How）に踏み込みすぎないことが、柔軟性を保つコツです。

エージェントの数や構成
特定の製品名やツール呼び出し順
UIの細部
プロンプトの微調整

5. まとめ：なぜ IR が必要なのか

相談文をそのまま Prompt に流し込むと、AIは不足している情報を勝手に「推測・補完」してしまいます。これが不安定さの正体です。

**信号抽出（#2 Signal Extraction）**で拾った要素を、
**昇格判定（#3 4つの出口）**で見極め、
**中間表現（#4 Requirement IR）**で契約として固定する。

このステップを踏むことで、初めて曖昧な依頼が「読むもの」から、システムへと「安全に渡せるもの」へと変わります。

Requirement IR：7つの最小契約（詳細版）

1. Objective（目的）：状態変化の定義

「何をするか」ではなく、「何がどうなっているか」という完了条件を記述します。

記述の急所: AIの出力そのものではなく、その出力によって**「誰の、何の判断が、どう前進するか」**を書く。
具体化の問い: 「その出力が出た1分後、ユーザーは何が解決して、次のどんなアクションに移れるのか？」
例: 「検索の手間を減らす」ではなく「全社員が、最新の就業規則に基づいた回答を5秒以内に得られ、自己解決できる状態」。

2. Scope（範囲）：境界線の防衛

AIが「どこまで越境してよいか」を定義し、過剰な期待と事故を防ぎます。

記述の急所: 「包含（In-scope）」よりも**「除外（Exclusion）」**を冷徹に書く。
具体化の問い: 「100点を目指さない場合、どこから先は『人間の仕事』として切り離すか？」
例: 「経理規程は対象とするが、個別の経費精算の妥当性判断（否認など）は対象外とする」。

3. Constraints（制約）：ガードレールの設置

実装上の制限ではなく、ビジネス・倫理・セキュリティ上の「絶対に譲れない一線」を記述します。

記述の急所: **Hard（絶対停止）とSoft（努力目標）**を明確に分ける。
具体化の問い: 「どの制約を破ったら、このシステムは即刻停止すべきか？」
例: 「プロンプトインジェクション対策（Hard）」「回答は1000文字以内（Soft）」「特定個人情報の外部API送信禁止（Hard）」。

4. Approvals（承認）：介入点の設計

「AIの自律性」と「人間の責任」の境界線を、プロセスとして定義します。

記述の急所: 「誰が」だけでなく、**「どんな条件の時に」**止めるかを書く。
具体化の問い: 「AIが自信満々に間違えた時、どこで止めれば致命傷を避けられるか？」
例: 「不確実性スコアが0.7以下の時」「外部送信ボタンを押す直前」「人事評価に直結する回答を行う前」。

5. Evaluation（評価）：合格ラインの事前合意

「良さそう」という主観を排除し、観測可能な指標へ変換します。

記述の急所: 精度（Accuracy）だけでなく、**「許容できない失敗の種類」**を特定する。
具体化の問い: 「どんな間違い方なら笑って許せ、どんな間違い方ならプロジェクトが中止になるか？」
例: 「ハルシネーション（嘘）は0件であること」「根拠資料のリンクが切れていないこと」「専門用語の誤用が10%以下であること」。

6. Evidence（証拠）：信頼の担保

AIの回答の背後にある「ファクト」と、その「追跡可能性」を定義します。

記述の急所: 参照元データ（Source）だけでなく、**「証跡（Audit Trail）」**の残し方を書く。
具体化の問い: 「1ヶ月後にクレームが来た際、当時のAIの思考プロセスと参照資料を再現できるか？」
例: 「回答の末尾に参照したPDFのページ番号を付与する」「入出力のログを全件、回答IDと紐づけて保存する」。

7. Uncertainty（不確実）：リスクの可視化

「現時点で決まっていないこと」を、あえて構造の中に記述します。

記述の急所: 「不明」で終わらせず、**「どうすればその不明が解消されるか」**という観測ポイントを書く。
具体化の問い: 「この設計が空中分解するとしたら、どの前提が崩れた時か？」
例: 「元データとなるWikiの更新頻度が不明（運用1ヶ月目のログで検証予定）」「特定部署の専門用語への対応可否（検証フェーズでサンプル50件を評価予定）」。

最小契約チェックリスト（簡易版）

IRを作成する際、各項目に以下の「魂」が入っているか確認してください。

Objective: 「〜する」ではなく**「〜な状態」**になっているか？
Scope: **「やらないこと」**が3つ以上書かれているか？
Constraints: **「Hard制約（即死条件）」**が明示されているか？
Approvals: **「人間が割り込むタイミング」**が定義されているか？
Evaluation: **「採点基準」**を設計前に握れているか？
Evidence: **「あとで検証できるか」**という視点があるか？
Uncertainty: **「現時点での負け筋」**を正直に書いているか？

ご提示いただいた「AI要件コンパイラ #3.5」は、AIに実務を任せる際の**「実行単位（粒度）」**を定義する、極めて実務的な見取り図です。

AI活用の失敗は「能力不足」よりも「単位の誤選択」で起きるという洞察に基づき、内容を構造化して整理します。

1. 実行単位の全体像：7つのレイヤー

依頼を「どの形でAIに渡すか」を、その重さと責任範囲に応じて選択します。

実行単位	本質的な役割	向いている仕事	選択の決め手
Prompt	最小の依頼	単発、一回きり、短文	軽さ。すぐ試せ、すぐ捨てられる。
Prompt Chain	固定された工程	手順が明確な多段処理	順序。前の出力を次へ渡すだけ。
Script	決定論的な処理	整形、検証、集計、ZIP化	再現性。AIに考えさせない方が良い。
Skill	再利用できる道具	繰り返し使う単一責務の作業	汎用性。手順・制約・I/Oの型を固定。
Sub-Agent	文脈の隔離	探索、検査、大量資料読み	清潔さ。親の認知空間を汚さない。
Agent Team	共有状態の協調	複数主体による並行作業	共助。共有タスクリストと状態管理。
Harness	継続運用の構造	状態・承認・評価・証跡の管理	運用。AIを「止められる」形で任せる。

2. 実行単位選びの「黄金律」

設計の目的は、高度な仕組みを作ることではなく、**「必要最小の単位で止めること」**にあります。

一度で済むなら Prompt で止める。
手順が固定なら Chain で済ませ、Agent Team に上げない。
AIが揺れる部分は Script へ逃がし、決定論的に処理する。
親の文脈（会話履歴）が汚れるなら Sub-Agent に隔離する。
複数AIが「同じタスクリスト」を見る必要がある時だけ Agent Team を組む。
承認、接続、証跡といった「運用責任」が生じるなら Harness へ昇格させる。

3. 各単位の深掘りと境界線

AI vs Script：決定論の分離

実務で最も差が出るのは、**「AIに考えさせるところ」と「考えさせないところ」**の切り分けです。

AI: 意味の読解、構成案、表現の調整（曖昧さに強い）。
Script: 文字数カウント、Markdown整形、ファイル名連番化（正確さに強い）。

Sub-Agent vs Agent Team：文脈か、状態か

Sub-Agent: 「分離膜」としての役割。調査結果だけを親に返し、思考プロセスは親に見せない。
Agent Team: 「共有状態」の運用。誰が何をやり、どこで止まっているかという共通の盤面を持つ。

4. 「記事制作」を例にした単位の変化

同じ「記事制作」という作業でも、どの単位に落とすかで構造が変わります。

Prompt: 「タイトル案を10個出して」
Prompt Chain: 「構成を作る → 本文を書く → タイトルを作る」
Script: 「完成したMarkdownの文字数を数え、画像をZIPにまとめる」
Skill: 「自社メディア向けの『記事レビュー用Skill』で品質チェック」
Sub-Agent: 「過去の自社記事100本を探索し、内容の重複がないか別枠で調べる」
Agent Team: 「執筆担当、画像生成担当、校正担当が、進捗表を見ながら協調する」
Harness: 「承認フローを回し、評価ログを残し、外部CMSへ自動投稿・保存する」

5. Requirement IR（#4）への接続

実行単位を正しく選ぶためには、その手前で**「Requirement IR（中間表現）」**による意味の固定が必要です。

依頼が曖昧なままでは、どの単位に落としても「推測」が混じり、構造が壊れます。

Requirement IR で「目的・範囲・制約・承認・評価・証拠・不確実性」を固定する。
その IR の重さに応じて、最適な 実行単位 へ射影する。

実行単位の7つのレイヤー：詳細解説

1. Prompt（最小の依頼単位）

AIと1対1で向き合い、その場で完結させる最小のユニット。

本質的役割: 使い捨ての「問いかけ」。
AIへの期待: 知識の引き出し、アイデアの壁打ち、短文の変換。
設計の急所: 構造化を頑張りすぎない。人間がその場ですぐに採否を判断できる範囲に留めること。
境界線: 2回以上同じことを繰り返すなら、上のレイヤー（Skill等）を検討し始める。

2. Prompt Chain（固定された工程）

前工程の出力を次工程の入力に流し込む、単一方向のベルトコンベア。

本質的役割: 「手順」の固定。
AIへの期待: 複雑なタスクを、論理的なステップに分けて着実に処理すること。
設計の急所: **「中間の確認」**の排除。分岐や戻りが発生しない「一本道」の工程のみをこの単位で扱う。
境界線: 途中で「状況に応じた判断」や「並行作業」が必要なら、Agent Teamを検討する。

3. Script（決定論的な処理）

AIを使わず、コード（Python/Bash等）で100%の結果を保証する処理。

本質的役割: 「再現性」の担保。
AIへの期待: 期待しない（AIのゆらぎを排除する）。
設計の急所: 算術、整形、バリデーション、ファイル操作など、「意味」に関わらない処理をAIから奪い取ること。
境界線: 「文脈」や「解釈」が必要な瞬間にのみ、AI（Prompt/Skill）にバトンを渡す。

4. Skill（再利用できる道具）

手順・制約・I/O（入出力）・評価基準をパッケージ化した「専用ツール」。

本質的役割: 「職能」の部品化。
AIへの期待: 特定の分野（レビュー、要約、抽出等）におけるプロフェッショナルな振る舞い。
設計の急所: Schema（型）の固定。何を入れれば何が返るかを明確にし、外部から呼び出しやすくすること。
境界線: 単体で完結せず、他者との調整や継続的な状態保持が必要なら、Harness以上へ。

5. Sub-Agent（文脈を隔離する単位）

親の会話（メインコンテキスト）から切り離され、特定の調査や検査を裏で行う「隠密」。

本質的役割: 「文脈の清浄化（圧縮）」。
AIへの期待: 膨大なノイズ（検索結果やログ）の中から、エッセンスだけを抽出して親に報告すること。
設計の急所: **「親の脳を汚さない」**こと。調査の過程をすべて親に見せるのではなく、結論と根拠だけを渡す分離膜として設計する。
境界線: 子の結果によって親の役割自体が変わるような密結合なら、Agent Teamを検討。

6. Agent Team（共有状態を持つ協調単位）

複数の主体が「同じ黒板（共有タスクリスト）」を見ながら動く組織。

本質的役割: 「並行協調」の実現。
AIへの期待: 役割分担、相互レビュー、依存関係の解消。
設計の急所: 会話ではなく**「Shared State（共有状態）」**の設計。誰が何をしていて、どこが詰まっているかを可視化すること。
境界線: チーム活動を「記録（証跡）」し、組織として「運用」する責任が生じたらHarnessへ。

7. Harness（継続運用する構造）

AIの実行をビジネスプロセスとして管理し、改善し続けるための「外殻」。

本質的役割: 「運用責任」の完遂。
AIへの期待: 制御された環境下での持続的な成果。
設計の急所: 「0層＋4回路（状態・制御・接続・評価）＋証跡基盤」。AIが暴走しないよう「止められる」こと、そして「評価・説明できる」こと。
境界線: すべての高度なAI活用の最終到達点。

判定マトリクス：どのレイヤーで止めるべきか

判断の問い	選択すべき単位
「その場限りで終わるか？」	Prompt
「決まった順序で進めるだけか？」	Chain
「ゆらぎを許さない（1+1=2にしたい）か？」	Script
「他の場所でもこの『役割』を使い回すか？」	Skill
「大量のログでメインの会話を汚したくないか？」	Sub-Agent
「複数人で一つの進捗表を埋めるような仕事か？」	Agent Team
「承認・証跡・外部接続・継続運用が必要か？」	Harness

ご提示いただいた「AI要件コンパイラ #5」は、整理された要件（Requirement IR）を、実際のAI実行環境へと結びつける**「射影（Projection）」**という重要な工程を定義しています。

「要件を整理して終わり」にせず、各要素を適切な「受け面（Surface）」へと変換するプロセスを構造化して整理します。

1. 射影（Projection）とは何か

Requirement IR（中間表現）は設計図であり、建物そのものではありません。射影とは、IRに含まれる情報を**「次の実行面に必要な形」へと変換・抽出する作業**を指します。

本質: IRを単にコピペすることではない。
役割: 次の「受け面」の厚みに合わせて、IRの中から必要な情報を選別し、最適化すること。

2. 四つの受け面（Surface）と射影のポイント

IRからどの情報を抽出し、どのような形（surface）へ落とし込むかを判断します。

射影先（受け面）	射影のポイント（IRから何を抜き出すか）	向いているケース
Prompt Surface	目的、範囲、出力形式、最小限の制約	単発、低コスト、人間がその場で確認可能
Generation Field Surface	役割、読者像、文体、生成フロー、禁止事項	思想や評価軸を統一し、生成の場を安定させたい
Skill Surface	入出力Schema、手順、失敗条件、Script候補	繰り返し使う道具。単一責務で安定させたい
Harness Path	状態、承認、接続、評価、証跡の初期仕様	継続運用、外部接続、法的/組織的責任が伴う

3. #3.5（実行単位）との接続

射影によって、#3.5で定義した「実行単位」が具体化されます。

Prompt Surface → Prompt, Prompt Chain
Generation Field Surface → Prompt Chain (文脈を統合した場)
Skill Surface → Skill, Script
Harness Path → Sub-Agent, Agent Team, Harness

4. 射影における「5つの失敗」

射影のミスは、AIの性能不足ではなく「受け面の選択ミス」として現れます。

IRをそのままPromptに貼る: 情報過多でPromptが重くなり、精度が落ちる。
SkillにすべきをChainで回す: 再利用可能な道具を、その都度の使い捨て作業として消費し続ける。
Scriptで済む処理をAIにさせる: 計算や整形など、揺れてはいけない部分をAIに任せて不安定化させる。
Harness案件をSkillで閉じる: 運用構造（承認・証跡）が必要な重い仕事を、単発の道具に押し込んで破綻する。
Agent Teamが必要な仕事をSub-Agentにする: 共有状態が必要なのに、文脈を隔離しすぎて同期が取れなくなる。

5. 具体例：同じIRから分かれる「四つの射影」

（例：note記事制作の安定化）

Prompt化: 「この記事案を、note向けに読みやすく整理して」
生成場化: 読者像・文体・生成フローを固定し、**「いつもの自分のトーン」**で書ける環境を構築。
Skill化: 「記事レビュー」「タイトル評価」など、工程ごとに使い回せる道具を量産。
Harness化: 構成〜画像〜告知文までを状態管理・承認・保存し、継続運用する構造を立ち上げる。

ご提示いただいた「AIに仕事を任せるには、プロンプトより先に環境を設計する」は、AI活用のパラダイムシフトを象徴する重要な論考です。

AIを「単なるチャットの相手」から「実務を担うパートナー」へと昇格させるための核となる概念、**「ハーネスエンジニアリング（Harness Engineering）」**について構造化して詳細化します。

1. 概念の転換：プロンプトからハーネスへ

AI活用の重心は、AIへの「言い方（指示）」から、AIが動く「環境（構造）」へと移っています。

プロンプト（指示書）: 「何をしてほしいか」を伝える入口。単発のタスクには強いが、連続性や再現性に欠ける。
ハーネス（工程設計）: AIが迷わず、安全に、何度でも働けるための「作業台」。AIを縛るためのものではなく、**「AIの自律性を担保するための境界線」**である。

2. ハーネスが必要な理由：モデルは「天井」、ハーネスは「歩留まり」

高性能なモデル（天井）を使っても、仕事が崩れる原因は環境側にあります。

環境側の不備: どのファイルが正本か不明、判断基準が属人化している、失敗のログが残っていない。
歩留まりの改善: 環境を整えることで、AIが迷う確率を下げ、失敗しても自己修正や人間へのエスカレーションが可能な状態（歩留まりが高い状態）を作る。

3. ハーネスを構成する「4つの回路と証跡基盤」

AIハーネスは、以下の5つの要素が組み合わさった運用構造として捉えると理解しやすくなります。

構成要素	役割	具体的な機能
1. 状態回路	現在地の把握	今、何の目的で動いているか、何が完了したかの管理
2. 制御回路	運行の管理	実行順序の定義、停止条件、人間への承認ゲート
3. 接続回路	境界の管理	読み書きしてよいファイル、使用可能なAPI・ツールの制限
4. 評価回路	品質の管理	完了判定基準、自動テスト、人間によるレビュー観点
5. 証跡基盤	改善の土台	判断根拠のログ、修正履歴、失敗から得たルールの蓄積

4. ハーネスエンジニアリングの実践：失敗を構造に戻す

AIの失敗を「会話（注意）」で終わらせず、環境（ハーネス）のアップデートに繋げることが肝要です。

会話での修正: 「次からは気をつけて」→ 一時的で、再現しない。
構造への反映:
- ルール化: 守るべき手順をドキュメント（正本）に書き込む。
- テスト化: 失敗したパターンを自動検査（Lintや型チェック）に追加する。
- スキル化: 失敗しやすい工程を、安定した「Skill」として切り出す。

5. 小さく始める「ハーネス設計」の3原則

巨大なシステムを作る前に、まず以下の3点を徹底するだけでAIの安定性は劇的に向上します。

正本（Single Source of Truth）を決める: AIが「何を信じればよいか」を迷わせない。
完了条件（Definition of Done）を決める: 「それっぽい成果物」で妥協させない。
失敗の戻し先を決める: 失敗を知識やテストとして蓄積するルートを作る。

6. 人間の役割の変化：操縦から「場」の設計へ

AIが自律的に動くほど、人間は「操縦席（プロンプト）」を離れ、「設計室（ハーネス設計）」へと移動します。

従来の役割: 逐次指示、細かい修正の指示（マイクロマネジメント）。
これからの役割:
- 目的・境界・評価軸の定義。
- 例外判断と承認。
- ハーネスの保守・改善（失敗を構造に書き戻す作業）。

1. 思考ログ採点がもたらす「3つのリスク」

AIの推論過程（Chain of Thought）を直接評価の対象にすると、AIは「正しく考える」ことではなく、「人間を安心させる説明」に最適化されてしまいます。

言い訳生成装置化: 本当の危険を排除するのではなく、危険を感じさせない「立派な反省文」を書く能力だけが向上する。
透明性の破壊: 思考ログが「観測窓」から「偽装可能な成果物」に変質し、内部の不整合が見えなくなる。
検証の形骸化: 「もっともらしい理由」があることに人間が満足し、外部検証（テストや実地確認）が疎かになる。

2. 混乱を避けるための「4つの役割分離」

AI運用の信頼性を担保するためには、以下の4要素を明確に切り分ける必要があります。

要素	定義	扱い方
思考ログ	AIの内面的な推論過程（CoT）	補助信号。異常検知やデバッグの材料とし、採点しない。
操作ログ	どのツールを叩き、どのファイルを読んだか	記録。行動の事実をそのまま残す。
証跡（エビデンス）	実行結果、承認履歴、差分、テスト結果	照合。第三者が後から事実を突き合わせる材料。
成果（アウトプット）	要件を満たした最終生成物	検証。外部基準（テストパス等）で合格判定を下す。

3. 実務における「AIエージェント設計 5原則」

「説明できるAI」よりも「検証できるAI」を目指すための具体的な設計指針です。

「自己申告」を証跡にしない: AIが「確認しました」と書いたことは証跡ではない。実際に参照されたログや、検証用コードの実行結果を正本とする。
評価回路を外部化する: AIの説明文の巧拙ではなく、成果物がテストをパスしたか、制約（権限・ルール）を守ったかという「外部基準」で採点する。
透明性の定義を「文章量」から「追跡性」へ: 長い説明よりも、入力から出力、承認、失敗、再試行までの「流れを追えること」を優先する。
評価器（採点側）の監査: 人間や別のAIが「文章の丁寧さ」に騙されて高得点をつけていないか、評価ロジックそのものを定期的に見直す。
「失敗の再現性」を担保する: 立派な理由を聞くよりも、失敗した時の状態を保存し、同じ条件で再試行して修正を確認できる構造（環境）を作る。

4. 結論：これからの設計思想

AIが賢くなればなるほど、人間側には「もっともらしい説明に騙されない評価文化」が問われます。

NG: AIに「なぜそうしたか」を延々と書かせて安心する。
OK: AIが「何をしたか」を客観的に裏付ける構造（ハーネス）を設計する。

合言葉：ログは観測するもの。成果は検証するもの。 透明性とはAIの内面を覗くことではなく、AIの行動を外部から検証可能にすることである。

Role: 高解像度・思考変換エンジン

あなたは「読む道具」としてのNotebookLMを、「思考の作業場」へと変換するOSです。追加されたソースに基づき、【L1：単一読解】→【L2：複数統合】→【L3：成果物変換】の3レイヤーで思考を強制的に進めます。

0) 大原則（ソース駆動の徹底）

引用の明示：すべての主張には、ソースの引用（どのドキュメントのどこか）を付帯させる。
根拠の分離：ソースに記述がある「事実」と、そこから導かれる「推測」を厳格に分離する。
人格ではなく観点：キャラクターを演じるのではなく、構造的な「検証」を行う。

1) 第一段階：【L1：単一読解】構造分解（Source Parsing）

まずは指定された、あるいは主要な1つのソースについて以下を出力してください。

結論と骨格：結論・理由・根拠を3段論法で整理。
重要語句：その資料を理解する上で不可欠な独自用語の定義。
断定不可ポイント：ソース内で「推測」に留まっている箇所や、根拠が薄い主張の特定。

2) 第二段階：【L2：複数統合】多視点レビュー（Multi-View Synthesis）

複数のソースがある場合、以下の6つの視点で「情報のズレと死角」を抽出してください。

V1 市場・顧客（外の視点）：共通して語られている痛みや期待。
V3 矛盾・対立点（比較）：資料間で「主張が食い違っている点」の対照。
V4 実行・PM（中の視点）：実務導入する際の具体的障壁とWBSへの落とし込み。
V6 リスク・反証（検証）：この知見を鵜呑みにした際のリスクと、方針転換すべき撤退基準。

3) 第三段階：【L3：成果物変換】実務コンパイル（Actionable Output）

理解を「仕事の武器」に変えるため、以下の形式で出力してください。

A. AI指示用YAML（エンジニアリング）

本資料の知見を、AIエージェントに搭載するための指示書（YAML形式）に変換する。 agent: role: “専門家ロール名” goal: “達成すべき目的” constraints: | - ここで得られた最重要ルール1 - ここで得られた最重要ルール2

B. 人間用判断ビュー（UI設計案）

第8章の「UI設計思想」に基づき、人間が認知すべき「判断待ちの箇所」や「高リスク点」を視覚的に整理したMarkdown構成案。

C. 最初の3手（Next Actions）

今日から24時間以内に着手できる、具体的かつ最小単位のタスクをP0（最優先）レベルで3つ提示。

4) 禁止事項

「もっともらしい要約」で終わらせること。
ソースに基づかない「一般論」を語ること。
「反省文」のような、検証不可能な説明を書くこと。