Knowledge Harness Charter#

目的#

生成AIに記事全体を一括で任せず、仕事を再現可能なOperationへ分解し、知識ハーネスとして段階的に構築する。

実行主体は次の優先順位で割り当てる。

  1. 再現可能な処理はProgram化し、冪等にする

  2. 役割と手順を固定できるAI処理はSkill / Agent化する

  3. 規則化しにくい意味判断はAI Judgeへ割り当てる

  4. 人間は欲望の発生源、方針所有者、例外判断者、最終公開権限者を担う

非目的#

  • 毎週必ず記事を公開すること

  • AIに記事全体を一括生成させること

  • 人間の最終公開判断を自動化すること

  • 過去記事を継続的に全面改稿すること

  • Sphinx / ablogを置き換えること

設計原則#

記事生成#

  • 意味のある変化がなければ、公開しないことを正常終了とする

  • 記事生成より前に、出典、過去との差分、不確実性を含む根拠パケットを作る

  • 過去記事は原則として公開時点のスナップショットとし、改善は将来の記事へ反映する

  • 公開日、情報基準日、最終確認日、対象バージョン、記事状態を区別する

  • 生成動機、AIの担当範囲、人間の確認範囲を記事の早い段階で示す

人間介在#

  • 通常処理はProgram、Skill / Agent、AI Judgeだけで承認待ちまで進める

  • 人間が毎回行うのは公開候補の最終判断だけとする

  • 公開候補がない場合は人間を呼ばない

  • 人間が応答しない場合は公開せず保留し、他の定期処理は継続する

  • 反復する人間判断は、Program、Skill / Agent、AI Judgeの順で移管を検討する

知識欲型の記事#

  • 公開可能な「知りたいこと」をGitHub Issueとして捕捉する

  • Issue作成だけでは処理を開始せず、明示的な実行ラベルを開始条件とする

  • 公開Issueには私的情報、会社情報、非公開会話を含めない

  • 必須入力は「知りたいこと」と公開可能性の確認だけにする

記事レビュー#

  • Draft PRのマージを公開承認とする

  • 修正要求、棄却、方針変更候補を区別する

  • 指定がなければ人間のコメントは今回の記事だけに適用する

  • 「今後も適用」と明示された場合だけ恒久方針の変更候補にする

  • 同一記事のAI修正は原則2回までにする

評価#

KPIは次の三群とする。

  1. External Reader Value Metrics

  2. Harness Operation Metrics

  3. Forward Improvement Metrics

「将来の自分への効用」は理念に含めてもKPIにはしない。

Phase 0の境界#

Phase 0では継続基盤だけを扱う。

スコープ#

  • Issueによる状態管理

  • セッション中断・再開プロトコル

  • 目的、決定事項、現在地、次の一手を保持するリポジトリ内文書

  • ChatGPT / VS Codeの双方が読める再開指示

スコープ外#

  • 週次収集

  • AIによる記事生成

  • Issue Form

  • GitHub Actions

  • Search Console / AdSense連携

  • Sphinx / ablogの置き換え

  • 既存記事の書き換え

  • 既存AGENTS.mdの方針への追随

Phase 1の境界#

Phase 1では、知識ハーネスを実装可能なOperationへ分解し、人間の判断を例外と最終公開判断へ限定する。

目的#

  • 記事候補の受付から公開判断までを、再開可能で監査可能な状態遷移として定義する

  • 各Operationの入力、出力、担当、成功条件、停止条件を固定する

  • 反復する判断をProgram、Skill / Agent、AI Judgeへ移し、人間への質問を減らす

スコープ#

  • パイプラインの状態遷移

  • Operation一覧と実行契約

  • Program、Skill / Agent、AI Judge、人間の責務分担

  • 正常終了、保留、再試行、例外、公開承認の扱い

  • 人間へエスカレーションする条件と判断予算

  • 代表シナリオによる設計上の通し確認

スコープ外#

  • Operationの実コード

  • Issue Formと実行ラベルの実装

  • GitHub Actionsと定期実行

  • 外部サービス連携

  • 記事本文の自動生成

  • 保護ブランチにある旧Seed処理の復活

完了条件#

  • PIPELINE.mdに状態遷移とOperation契約が一意に定義されている

  • 人間の必須判断と、質問せず自動終了する条件が区別されている

  • 通常公開、公開候補なし、情報不足、修正上限到達の代表シナリオを追跡できる

  • 最初に実装するOperationを一件に絞れる

  • Draft PRを人間が確認してマージする

Phase 6の境界#

Phase 6では、O-04 Collect Evidenceを実装し、安全性確認済みRequestから、欠落や矛盾を含めて監査可能なEvidence Setを作る。

目的#

  • 公式・一次情報を優先しつつ、一般Web上の説明、評価、懸念も区別して収集する

  • 取得できた事実だけでなく、取得不能、根拠不足、対象範囲の曖昧さ、情報間の矛盾を保持する

  • 後続Operationが出典、情報基準日、対象バージョン、不確実性を検証できるEvidence Setを作る

スコープ#

  • O-03のSCREENED / ADVANCE成果物の契約検証

  • 公開情報源の検索・取得と、一次、二次、コミュニティ、発見専用への分類

  • 出典、取得日時、発行日、該当箇所、要約、対象バージョン、確からしさと理由の保存

  • 取得不能、根拠不足、矛盾、対象範囲の曖昧さを消さずに保存

  • 重複排除、上限付き収集、一時的な取得失敗の再試行

  • run_id単位の冪等な保存

  • 検索・取得・採用・不足を見直すためのMetrics記録

  • CLI、単体テスト、運用文書

スコープ外#

  • 根拠を統合して主張を作ること

  • 根拠充足性、新規性、読者価値、記事候補の採否判断

  • 記事構成と本文の生成

  • 情報間の矛盾を解消したように見せること

  • 検索結果の多数意見を事実の正しさとして扱うこと

  • 認証が必要な非公開情報、有料情報、アクセス制限を回避した取得

  • GitHub Actions、定期実行、新しい外部検索サービスとの本格連携

  • Metricsに基づく上限値や恒久方針の自動変更

完了条件#

  • O-03の正常な成果物だけを入力できる

  • 情報源を分類し、必須メタデータとともにEvidence Setへ保存できる

  • 一次情報と世間的な評価を区別できる

  • 重複排除、収集上限、早期終了、限定的な再試行が実装されている

  • 根拠不足、取得不能、矛盾、対象範囲の曖昧さを成果物へ明示できる

  • 何らかの証拠が得られた場合は、不足があっても後続へ渡せる

  • 全面的な取得不能と一時的な取得失敗を区別できる

  • 同一入力と同一取得結果で不要な書き換えを行わない

  • O-04のMetricsをO-13で記録し、初期値を後から見直せる

  • CLI、単体テスト、既存Operationの回帰テストが成功する

  • Draft PRを人間が確認してマージする

Phase 7の境界#

Phase 7では、O-05 Build Evidence Packetを実装し、O-04のEvidence Setを、後続のAI Judgeが主張と不確実性を出典まで追跡できるEvidence Packetへ整理する。

目的#

  • 取得済み証拠を、事実、推測、未確認事項、世間的反応、矛盾へ分離する

  • 各記述を一件以上のEvidence Set内source_idへ結び付け、根拠のない補完を防ぐ

  • 過去記事との差分と、新しく記事にする理由の候補を、事実と推測を混同せず後続へ渡す

スコープ#

  • O-04のEVIDENCE_READY / ADVANCE成果物の契約検証

  • Evidence Setの情報源、取得失敗、矛盾、不確実性、Metricsの読み取り

  • 論点単位での事実、推測、未確認事項、世間的反応、矛盾の整理

  • Packet内の全記述とsource_idの対応付け

  • 一次情報と二次・コミュニティ情報の区別維持

  • 過去記事参照がある場合の既知事項、差分候補、再確認が必要な事項の整理

  • 根拠不足、取得不能、矛盾を欠落させない日本語要約

  • run_id単位の冪等な保存

  • CLI、単体テスト、運用文書

スコープ外#

  • 新しい情報源の検索・取得とO-04成果物の書き換え

  • 根拠充足性、新規性、読者価値、記事候補の採否判断

  • 矛盾の解消、確証のない事実認定、根拠のない補完

  • 記事の中心メッセージ、構成、本文の生成

  • 過去記事の書き換え

  • GitHub Actionsと定期実行

完了条件#

  • O-04の正常なEvidence Setだけを入力できる

  • 事実、推測、未確認事項、世間的反応、矛盾を区別して保存できる

  • Packet内の全記述を存在するsource_idへ追跡できる

  • 一次情報と一般的評価を混同しない

  • 取得失敗と不確実性をEvidence Setから欠落させない

  • 過去記事参照がある場合は、既知事項と差分候補を区別できる

  • 根拠がない記述、存在しないsource_id、空の説明を拒否できる

  • 同一入力では不要な書き換えを行わない

  • CLI、単体テスト、既存Operationの回帰テストが成功する

  • Draft PRを人間が確認してマージする

Phase 8の境界#

Phase 8では、O-06 Judge Candidateを実装し、Evidence Packetから記事候補として先へ進めるかを、理由と確信度を伴う再検証可能なAI Judge判定として保存する。

目的#

  • 根拠充足性、新規性、外部読者が再利用できる価値、著者固有の問いまたは判断、不確実性の影響を独立評価する

  • 公開本数を増やす圧力から評価を分離し、根拠不足や新規性不足を正常な非公開終了として扱う

  • 後続Operationと人間が、判定理由と参照したPacket項目を追跡できるCandidate Decisionを作る

スコープ#

  • O-05のPACKET_READY / ADVANCE成果物の契約検証

  • 5評価軸それぞれのPASS、FAIL、UNCERTAIN判定

  • 各評価軸の確信度、理由、参照Packet項目、不確実性の記録

  • 評価基準バージョンとJudge識別子の記録

  • CANDIDATE_ACCEPTED / ADVANCE、NO_CANDIDATE、HOLDの決定規則

  • 人間へ質問しない安全な非公開終了

  • run_id単位の冪等な保存

  • CLI、単体テスト、運用文書

スコープ外#

  • 新しい情報の取得、Evidence Packetの補完・書き換え

  • 記事の中心メッセージ、対象読者、構成、本文の生成

  • 公開本数を確保するための評価閾値引き下げ

  • AI Judgeによる恒久方針と評価基準の自動変更

  • 人間による技術的事実や根拠不足の穴埋め

  • 最終公開判断

  • GitHub Actionsと定期実行

完了条件#

  • O-05の正常なEvidence Packetだけを入力できる

  • 5評価軸を独立に判定し、理由、確信度、参照項目を保存できる

  • 判定に使う参照項目がEvidence Packetに実在することを検証できる

  • 必須軸のFAILをNO_CANDIDATEとして正常終了できる

  • FAILはないがUNCERTAINまたは高影響の不確実性がある場合にHOLDできる

  • 全必須軸がPASSし、高影響の未解決不確実性がない場合だけCANDIDATE_ACCEPTEDへ進める

  • 確信度0.70未満のPASSを受け入れず、UNCERTAINとして扱える

  • 判定理由を空にできず、記事数を増やすために閾値を下げない

  • 同一入力と同一判定では不要な書き換えを行わない

  • CLI、単体テスト、既存Operationの回帰テストが成功する

  • Draft PRを人間が確認してマージする

Recent Posts

Tags

Categories

Archives