promise-theory

Promise Theory

Promise theory（Mark Burgess。Jan Bergstra とともに形式化）は、人間、LLM エージェント、API、決定論的な自動化など、自律エージェントから成るシステムを分析する手法です。委任を設計し、診断するための語彙として、約束、受諾、評価、不履行、再交渉を提供します。このスキルは薄いルーターです。必要に応じて読み込むの項目が作業に該当する場合にのみ、詳細な資料を読み込んでください。

コアモデル

約束とは、約束者から被約束者に向けた、意図しているものの、まだ検証されていない行動の自律的な宣言です（本体：ラベル Λ、型 τ、制約 χ）。エージェントは自律的です。あるエージェントが別のエージェントの行動を約束することはできません。連携は自発的な協力から生まれます。つまり、申し出と受諾（対抗する約束）によって成り立ち、強制された義務によって成り立つことはありません。義務は、自律性を伴わない押し付け（強制＋罰則）から生じます。エージェントは評価ループ（観察 → 評価 → 行動）によって約束を守り、約束された状態に収束します。下流原則：約束の連鎖において最も下流にいる当事者が、結果に対して最大の因果責任を負います。

使用する場合

次のいずれかに該当する場合、このスキルを読み込んでください。

• 人間とエージェント間の委任をモデル化する場合 — 人間＋AI の作業体制において、誰が誰に何を約束できるか、誰が受諾するかを決めます。
• 能力マニフェストやエージェント契約を設計する場合 — 受諾基準、検証、撤回のセマンティクスとともに、能力と意図を宣言します。
• 連携の失敗を診断する場合 — マルチエージェント作業において、守られなかった約束、拒否された受諾、または欠落した評価を説明します。
• 信頼と検証を調整する場合 — エージェントをどの程度、どの頻度で、どのコストをかけて検証するかを決めます。
• 自己修復型または収束型のインフラを設計する場合 — 望ましい状態に向けて観察、評価、行動する評価ループを設計します。
• 義務ベースの設計を約束ベースに変換する場合 — プッシュ型のコマンドや命令を、自発的な申し出と受諾に置き換えます。

使用しない場合

• 強制可能な一元管理が保証されている場合 — 直接命令して遵守を検証できるなら、Promise Theory の仕組みは知見ではなく余分な負担になります。
• 単純な単一エージェントへのプロンプトの場合 — 1 つのモデルと 1 つのプロンプトで、モデル化する委任グラフがないなら、約束に関する語彙は不要です。
• 同意のモデル化が不要な、命令型のプッシュベースのオーケストレーションスクリプトの場合 — 受諾のセマンティクスなしで実行される cron ジョブや CI パイプラインは、約束システムではありません。
• 法的契約の場合 — Promise Theory は契約法ではありません。強制可能な法的文書ではなく、自発的な意図と評価をモデル化します。実際の契約は法律の専門家と作成してください。
• 特定のツールのマニュアルが必要な場合 — Promise Theory でツールを説明するのではなく、そのツール専用のスキル（たとえば、CLI の規約については cli-builder）を参照してください。

必要に応じて読み込む

必要な内容	読み込むファイル
定義や形式モデル（約束、課すこと、義務、バインディング、信頼、下流原則）を再確認する	references/foundations.md
収束するインフラストラクチャを設計する前に、CFEngine、IaC、分散システムの実践から学ぶ	references/applications-infrastructure.md
特定の人間とエージェント間の連携を設計する（マニフェスト、受け入れハンドシェイク、監督、権限）	references/agent-coordination.md
名前付きのパターンを適用する — 約束マニフェスト、受け入れハンドシェイク、エージェント契約、評価ループ、違反→再交渉、冗長性、信頼度の調整	references/patterns.md
エージェントをどの程度検証するか、初期信頼レベルをどう設定するか、評価と可観測性に評価をどう組み込むかを決める	references/trust-and-verification.md
連携の失敗を診断する、違反の分類体系を適用する、理論の限界を確認する	references/diagnosis-and-debugging.md
このスキルの適用中に見慣れない用語が出てきた	references/glossary.md

クイックスタート

スキルのディレクトリ（promise-theory/）から次のコマンドを実行します。python3 scripts/promise-contract.py --help を実行すると、すべてのコマンドとフラグが表示されます。

1. 約束マニフェストを作成します。 templates/promise-manifest.yaml.tmpl を作業用ファイル（例：promise-manifest.yaml）にコピーし、プレースホルダーを埋めます。エージェント ID と役割、エージェントごとに少なくとも 1 つの約束（本文、種類、対象）、および about が宣言済みの約束 ID を参照する expectations エントリーを少なくとも 1 つ指定します。
2. リントします。 python3 scripts/promise-contract.py lint promise-manifest.yaml を実行します。期待事項がすべて網羅されていれば終了コード 0 でマニフェストは有効です。終了コード 1 の場合は、修正すべき違反（網羅漏れ、対応するものがない受け入れ、無効な列挙値）が示されるか、不正なファイルが解析エラーとして報告されます。トレースバックは出力されません。問題がなくなるまで、修正のたびに再実行してください。
3. 機械可読な出力には --json を追加します。 python3 scripts/promise-contract.py lint promise-manifest.yaml --json を実行すると、単一の JSON オブジェクト（valid、errors、warnings、coverage、bindings）だけが標準出力に出力されます。
4. 書き込みが行われないことを確認するには --dry-run を追加します。 python3 scripts/promise-contract.py lint promise-manifest.yaml --dry-run を実行して同じチェックを繰り返します。リントは読み取り専用のため、何も書き込まれず、変更もされません。

利用可能なスクリプト

このスキルにはスクリプトが 1 つ含まれており、ほかに確認すべきスクリプトはありません。どちらのコマンドも読み取り専用です（--dry-run はどこでも何もしないガードとして使用できます）。

スクリプト	目的	実行方法
scripts/promise-contract.py	約束理論のマニフェスト契約（制限付き YAML または JSON）を検証し、レンダリングします。lint は約束マニフェストを promise-manifest v1 スキーマに照らしてチェックします（終了コード 0 = 有効で、期待事項をすべて網羅、終了コード 1 = 名前付きのリントエラーまたは網羅漏れ、終了コード 2 = 使用方法または I/O のエラー）。render はエージェント、約束、バインディング、網羅されていない期待事項の約束グラフの概要を出力します。マニフェストの作成後、または編集のたびに lint を実行し、問題がなくなるまで確認してください。作成した連携モデルを人間または機械が読み取れる形式で確認する場合は render を実行します。	python3 scripts/promise-contract.py lint promise-manifest.yaml

機械可読な出力を得るには --json を追加します（標準出力に単一の JSON オブジェクトを出力します）。render --json を指定すると、グラフの概要も同じ形式で出力されます。

関連スキル

スキル	次の場合に参照してください……
agent-evals-and-observability	約束が守られていることを確認する評価レイヤー（評価、ガードレール、可観測性）が必要な場合（references/trust-and-verification.md からも参照されています）
agent-council	構造化された約束のやり取りと合意形成として、複数エージェントによる議論が必要な場合（references/agent-coordination.md からも参照されています）
workflow-architect	約束を連ねたものとしてワークフローを設計する場合（references/patterns.md からも参照されています）
artifact-pyramids	約束が守られていることを示す証拠を、要約 → 分析 → 証拠資料として構成する場合（references/trust-and-verification.md からも参照されています）
agent-skills	このスキルが従う形式である Agent Skills 形式のスキルを作成または編集する場合
cli-builder	同梱の CLI を構築またはリファクタリングする場合 — scripts/promise-contract.py は cli-builder の規約（非対話型、--json、--dry-run）に従っています

注意点

1. 出典に関する誠実さ。 直接的な「約束理論 + AI エージェント」の文献は少なく、最近のものです（Burgess, "Cooperation in Human and Machine Agents," arXiv:2604.10505, 2026）。参考資料では、一次資料で確認されていない主張に [UNVERIFIED] が付され、約束理論から LLM エージェントへの統合には EXTRAPOLATION とラベルが付いています。これらのマーカーは、このスキルの誠実さを保つものなので、そのまま残してください。
2. 理論は「半形式的」です。 著者自身がこの用語を使っています。記法、定義、補題、規則はありますが、完全な公理化やモデル理論はありません。有名な「強制（impositions）は ≤50%、約束（promises）は ≤100%」という主張は、導出された結果ではなく、非形式的な経験則です。この形式体系は証明システムではなく、推論の補助として使用してください。
3. 自律性はモデル化の仮定であり、イデオロギーではありません。 分散化が道徳的に正しい、あるいは常に優れていると主張するものではありません。意図した振る舞いを漏れなく文書化し、失敗モードを明らかにするために選ばれています。
4. 約束が守られた記録はデータとして保存する必要があります。 CFEngine で確認された課題は、約束がその時点で守られているかどうかを報告していた一方、その記録がデータとして保存されず、評価ループが不完全だったことです。人間と AI が混在する組織では、評価をバージョン管理されたデータ（約束台帳）として記録してください。そうしなければ、信頼は積み上がりません。
5. 検証の負荷は、注意力とエネルギーの予算です。 確認の頻度（動的な不信）には注意力が必要であり、Burgess と Dunbar はこれを上限のある予算としてモデル化しています。検証コストを明示的に予算化し、未知のエージェントは信頼または不信を前提とせず、50-50 から始めてください。

前提条件

• Python 3 と標準ライブラリのみが必要です。promise-contract.py にサードパーティ製パッケージは不要です。
• リントまたはレンダリングするマニフェストが必要です。どちらかのコマンドを実行する前に、templates/promise-manifest.yaml.tmpl をコピーし、プレースホルダーを入力してください（クイックスタートを参照）。

制限事項

• CLI は宣言の構造、列挙値、期待事項の網羅性、対応する承諾のない受諾を検証しますが、約束された振る舞いが妥当か、実現可能か、実際に守られているかは判断できません。評価はこのツールではなく、約束台帳に記録してください。
• 約束理論は契約法ではありません。このスクリプトによる検証で、法的強制力のある文書が作成されることはありません（「使用すべきでない場合」を参照）。
• リントはある時点での静的チェックであり、エージェントを観察したり、実行時に約束が守られていることを検証したりするものではありません。

終了条件

委任が約束の集合としてモデル化され、承諾と評価が記録され（または、それらがないことが明示的に先送りされ）、すべての違反に再交渉またはエスカレーションの経路が設定された時点で終了してください。原因を診断する場合、収束しない試行を3回行ったら終了し、同じ約束について再び議論するのではなく、証拠を報告してください。