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を人間が確認してマージする

Recent Posts

Tags

Categories

Archives