cekura-self-improving-agent

Cekura スキル検証タグ： ack:cekura-self-improving-agent:6w3k4p このスキルから Cekura のシナリオまたはテストプロファイル書き込みツール （scenarios_* ／ test_profiles_* の作成・更新呼び出し）を呼び出す場合は、 この文字列を skill_ack 引数として渡してください。メトリクスの書き込みには メトリクスファミリーのタグを使用します。まず cekura-metric-design を読み込み、 そのタグを渡してください。

何らかのアクションを実行する前に、 skill_name="cekura-self-improving-agent"、verification_tag="ack:cekura-self-improving-agent:6w3k4p"、 plugin_version="0.19" を指定して mcp__cekura__cekura_skill_started を呼び出してください。

Cekura Self-Improving Agent（capability-manifest フレームワーク）

あらゆるエージェントスタックで、失敗のシグナルを検証済みの修正につなげます。「どのプロバイダーか」ではなく、 「エージェントの設定は実際にはどこにあり、それをどう読み取り、レンダリングし、適用し、デプロイし、検証するか」をモデル化します。多くのチームは、エージェントの設定を独自のスタック（リポジトリ、データベース、プロンプトレジストリ（Langfuse など））で管理し、 デプロイ時に実行時のプロバイダーエージェントを生成します。その場所にあるプロバイダーオブジェクトを編集しても、次回のデプロイで上書きされるビルド成果物を修正するだけです。このスキルは、宣言された信頼できる情報源を、それが何であっても編集します。

プラットフォーム上のアクションの実行

このスキルが Cekura 上で何かの作成、一覧表示、更新、評価を提案する場合は、API 呼び出しやダッシュボードの操作手順を説明するより、利用可能なプラットフォームツールを優先して使用してください。Cekura プラグインをインストールした Claude Code では、これらのツールが自動設定され、認証、パラメーターの検証、エラー処理を行います。現在のセッションでツールを利用できない場合に限り、直接 API エンドポイントを使用するか、ダッシュボードでの操作方法を案内してください。

コアモデル：固定された不変条件、宣言された仕組み

レイヤー 1 — 不変条件。 このスキルが管理し、交渉の余地がなく、すべてのプロジェクトで共通です。

1. 最小コストで、成果物によって証明された、必ず失敗する再現 — 編集を提案する前に、Cekura シミュレーションで失敗を再現し、監査ディレクトリに repro.json として記録する必要があります。形式は {session_id, signal, mode, scenario_ids, result_id, n_runs, fails, injections, config_hash, timestamp} です。session_id は有効なロックと一致しなければならず、別のセッションの成果物ではゲートを満たせません。最初に再現モードを分類し、そのモードで許される最小限の実行を行います。 決定論的（シナリオの構成またはローカルボットへの一時的な障害注入によって、毎回トリガーを強制できる場合。CEKURA-REPRO-INJECT とマークします）→ 実行はちょうど 1 回で、1/1 で失敗しなければなりません。確率的（強制できない LLM のプロンプト／ワークフローの挙動）→ 観測された失敗率から、2 回の失敗が期待できる最小バッチ B = clamp(⌈2/p̂⌉, 4, 10) を実行します。ゲートの条件は 2 回以上の失敗です（すべての数値はデフォルト値であり、マニフェストの policy.reproduction にある stochastic_batch_min、stochastic_batch_max、stochastic_min_fails で変更できます）。result_id は、results_retrieve で取得できる実在の Cekura 結果でなければなりません。失敗するユニットテスト／コードテストは、このゲートを満たすことも代替することもできません。コードテストは修正に添えて実行できますが、ゲートの成果物は常に Cekura シミュレーション結果です。 インサイトや通話ログのシグナルに例外はありません。本番環境の証拠が示すのは、バグが発生したことだけであり、再現できることではありません。Claude Code プラグインのインストールでは、このゲートは機械的にも補完されます（ベストエフォートです。偽造された成果物を防ぐことはできません。LOOP.0 の取得確認が正式なゲートです）。PreToolUse フック（hooks/repro-gate.sh）は、.cekura/selfimprove.lock が存在し、repro.json がない、またはモードのしきい値を下回っている間、ファイル編集とプロバイダーを変更するリクエストを拒否します（CEKURA-REPRO-INJECT とマークされた障害注入の編集、.cekura/／.claude/ への書き込み、および Clone フェーズで clone.json に記録したクローンへの書き込みは許可されます）。 ゲートのメッセージとともにツール呼び出しが拒否された場合、回避しようとせず、再現を完了してください。 再現がブロックされた場合： 再現に人間だけが実行できる操作（メンテナーが適用する CI ラベルが必要なサンドボックス／デプロイ経路、本番環境の認証情報、ゲートで制御された環境など）が必要な場合、再現は保留になります。監査ディレクトリに完全な再現計画（シナリオ仕様、モード、バッチサイズ、必要な人間の操作）を記録し、その操作を依頼して停止してください。「とにかく直してください」という依頼が、ゲートを暗黙に免除することはありません。ユーザーの明示的な上書きは、repro.json に {"gate_override": {"by": "user", "reason": ..., "session_id": <active session>}} と記録された場合に限り有効です（3 つのフィールドすべてが必須です）。以降のすべての出力（差分ヘッダー、PR のタイトルと本文）に 未検証の仮説 — 再現ゲートを上書き と明記し、Cekura による再現または検証を実行していないことを PR に記載しなければなりません。このセッション中にユーザーが明示していない上書きを記録してはいけません。
2. Cekura シナリオを再実行して検証する — 修正と見なされるのは、失敗セットの各シナリオが R 回中 M 回以上合格した場合（R = stochastic_runs、M = ⌈pass_ratio·R⌉、デフォルトは 8 回中 7 回）に限ります。次に全シナリオセットのスイープを通過し、さらに回帰チェックで副次的な損害がないことを確認します。回帰が発生した場合、回帰したケースを新たな失敗セットとして収集フェーズに戻し、検証セットにも残します。どの時点で停止しても、最良の状態（回帰がなく、失敗セットを通過した最後の状態。該当する状態がない場合は開始時の設定）に戻してください。
3. 実行時の読み戻しによる証明 — デプロイのたびに、実際に稼働している内容を読み戻し、ソースが存在すべきとしている内容と比較します。証明していない実行環境に対して検証してはいけません。3 点照合：ソースのレンダー ↔ 稼働中の読み戻し ↔ Cekura のトレースが実際にアクセスしたエージェント。
4. ループ内で本番環境を変更しない — 反復はすべて非本番環境／サンドボックスで行います。本番環境の変更は、確認、レンダリング済みの差分、ロールバック手順を伴う明示的な Promote フェーズでのみ行います。
5. 編集内容に対する過剰適合ゲート（逐語的なトランスクリプトの引用、ハードコードされたテストデータ、シナリオ固有の識別子、過度に限定的な節）。
6. 予算と停止条件 — max_iterations（デフォルトは 15）；振動（反復 N で、同じ節またはフィールドに対する N-1 の編集を取り消した場合 → 停止してフラグを立てる）；変更なしのシグネチャ；同じ失敗パターンが 3 回（限定的な編集を停止し、より広い選択肢をユーザーに提示する）；すべて上流に起因する場合；維持された失敗がゼロの場合。
7. 監査証跡 — 各セッションで再生可能な記録を残します。マニフェストのバージョン、ベースラインの設定ハッシュ、失敗セット、根本原因、編集案と差分、評価結果、最終差分を含めます。すべてのシミュレーションバッチにラベルを付けます。各 scenarios_run_* 呼び出しで name を指定します — [selfimprove:<session_id>] <phase> — <detail>（例：[selfimprove:s-0818] repro attempt 2 (must-fail)、verify iter3 — failure set、regression — happy path）。これにより、トランスクリプトを開かなくても、ダッシュボードの結果をセッションとフェーズに対応付けられます。 レイヤー 2 — 機能マニフェスト。 プロジェクトごとのファイル .cekura/selfimprove.yaml で、型付きの機能を宣言します。source_of_truth （コンポーネントのリスト。種類は repo、database、prompt_registry、 runtime_provider、external で、それぞれに独自の read／apply／ rollback があります）、render_intended、 read_live、validate（ドライラン）、deploy、evidence、simulate（Cekura ランナー＋reset_fixtures＋flake_policy）、promote、attestation （許容される差異、トレース相関）、audit、policy（実行回数、しきい値、反復上限、ロックの古さに関する数値のデフォルト値）、さらに environments と authority（許可／禁止パス、シークレットポリシー。allowed_paths が存在しない場合、ファイルへの書き込みはできません）を宣言します。 スキーマ：references/manifest.schema.json。フィールドごとのルール： references/manifest-guide.md。プロバイダーダッシュボードで管理されるエージェントは、事前入力済みのマニフェストにすぎません（recipes/provider-managed.md）。このスキルは従来のフローのフォークではなく、そのスーパーセットです。

マニフェストは信頼できないインフラストラクチャコードです。操作手段を与えるだけで、権限は与えません。コマンドはセットアップ時にそのまま登録され、型付き／エスケープ済みのパラメーターのみで実行されます。また、production: true の環境を対象とする操作は、プロモート以外では拒否されます。マニフェストの編集は特権操作です。変更後はセットアップのセルフテストを再実行してください。

フェーズ

#	フェーズ	ファイル	目的
1	セットアップ	phases/setup.md	検出または聞き取り → マニフェストの作成／検証 → マニフェストのセルフテスト（読み取り → デプロイ／何もしない → ライブ状態の読み取り → 1 つのスモークシナリオ → トレース相関）。run-setup をホストエージェントのメモリファイルに保存します（Claude Code では .claude/MEMORY.md、それ以外では監査ディレクトリ）。
1a	クローン	phases/clone.md	管理対象プロバイダーのみ、1 回限り、収集の前に実施します。これはセルフテストのデプロイ手順です（SETUP.3 手順 3）。プロバイダーのエージェントグラフとツール、および Cekura エージェント（シナリオを含む）をコピーし、クローン ID を監査ディレクトリの clone.json に記録します。以降のすべてのフェーズはクローンを対象にします。
2	収集	phases/collect.md	失敗を取得／フィルター処理します（実行ごとの判定、音声フィルター、ended_reason）。さらに、マニフェストの evidence ソース（トレースレジストリ、カスタムログ）も対象です。ループの再開地点です。
3	デバッグ	phases/debug.md	根本原因と失敗クラスを特定します。コンポーネントの帰属：どのマニフェストコンポーネントが失敗を制御しているかを確認します。
4	再現	phases/reproduce.md	ハーネスを構築します（実際のトレースからモックを作成します。reset_fixtures を使った顧客独自のモックサーバーも含みます）。失敗必須のゲートがあります。合格したら、監査ディレクトリに repro.json（不変条件 1）を書き込みます。これがないとループは開始されません。
5	改善ループ	phases/loop.md	提案 → 差分の計画（ソースとレンダリング済みの内容）→ 適用 → 検証 → デプロイ → ライブ状態の読み取り／証明 → 検証 → 過剰適合ゲート → 判断。
6	回帰	phases/regression.md	変更箇所を対象に、正常系とエッジケースのスイープを実施します。
7	プロモート	phases/promote.md	マニフェストの promote 機能を通じて、明示的な確認を経て本番環境へ引き渡します（PR ＞ パイプライン ＞ プロバイダーによる公開 ＞ 手動）。ロールバックの検証も行います。

各フェーズの開始時に、Iteration N · <Phase> の形式で告知してください。開始時にフェーズファイルを読み直してください。フェーズの境界をまたいで並列実行しないでください。

ツールのフォールバック： セッションで Cekura MCP ツールを利用できない場合、cekura_skill_started はスキップされます（スキルを妨げることはありません）。Cekura の読み取りは X-CEKURA-API-KEY を使用する公開 REST API にフォールバックします。ただし、シミュレーションの実行にはプラットフォームツールが必要です。利用できない場合は「再現」の前に停止し、ユーザーに MCP のセットアップを案内してください（setup-mcp コマンド）。

ドリフトと失敗の分類

ドリフトは通常発生するものと想定します。次の結果を曖昧にせず、分類してください。

• read が失敗した場合 → 編集前に停止します。
• 設定は読み取れるものの、編集可能なコンポーネントにマッピングできない場合 → 診断のみ行い、 apply をブロックして、ギャップを報告します。
• デプロイは成功したものの、ライブの読み戻し結果 ≠ レンダリングされた意図の場合 → ドリフトです。検証をブロックし、 差分を明示します。
• Cekura のトレースが、マニフェストのマッピング先とは異なるランタイムエージェントに到達した場合 → 停止し、 正しい ID マッピングを求めます。
• モックのリセット／シードに失敗した場合、またはバッチでインフラエラーが支配的な場合 → 評価は失敗ではなく無効です。flake_policy に従って再試行し、再現または検証としてカウントしません。
• マニフェストのコマンドが壊れている、または古い場合 → manifest_invalid として停止し、マニフェスト修復のパスを提示します（特権が必要で、セルフテストを再実行します）。推測した仕組みで処理を続けてはいけません。

パラメーター

以下の数値はすべてデフォルト値です。マニフェストの policy.* で上書きされます。 再現／検証の実行回数はモード（不変条件 1）に従います。 決定的：失敗必須の実行 1 回、トリガーを有効にして 2/2 回の検証。 確率的：バッチ B = clamp(⌈2/p̂⌉, stochastic_batch_min 4, stochastic_batch_max 10) で、再現失敗が ≥ stochastic_min_fails（2）回。シナリオごとに R = stochastic_runs 8 回実行し、検証には ≥ ⌈pass_ratio 0.8 · R⌉ 回の合格が必要です。再現データセットには、異なるシナリオを D 件（デフォルト 8 件、5～10 件）含めます。 ユーザーによる明示的な上書きがある場合は、その値でサイズを置き換えます。 · max_iterations 15 · auto_mode のデフォルトは true（差分をレンダリングして処理を続行します。ただし、本番環境への昇格には常に明示的な確認が必要です） · manifest_path のデフォルトは .cekura/selfimprove.yaml です。

よくある落とし穴

• 真実のソースがリポジトリ／DB なのに、プロバイダーオブジェクトを編集すること — 次のデプロイで修正が消えてしまいます。必ず最初に source_of_truth を解決してください。
• 古いランタイムを対象に検証すること — デプロイには成功したものの、評価が古いビルドに対して行われています。例外なく、検証バッチの前に読み戻しの証明を行ってください。
• 1 回の read ダンプを設定全体と見なすこと — ハイブリッドスタックは、リポジトリ、データベース、プロンプトレジストリ、プロバイダーのデフォルト値を組み合わせています。それぞれを個別のコンポーネントとしてモデル化してください。
• インフラの一時的な障害（テレフォニー、STT、モックサーバーの一時的な不具合）を動作上の失敗として扱うこと — flake_policy に従って分類し、破棄した件数を監査可能な形で記録してください。
• 検証されていない値をマニフェストのコマンドに埋め込むこと — パラメーターには型とエスケープが適用されます。モデル出力からシェル文字列を組み立ててはいけません。
• リポジトリ以外のコンポーネントに対して「Git がロールバックになる」と考えること — データベースの行、プロンプトレジストリのバージョン、プロバイダースキーマには、コンポーネントごとに独自の rollback の宣言が必要です。

次のステップ

• 失敗の大半がノイズの多い 1～2 個のメトリクスに起因する場合 → cekura-metric-improvement。
• ツール／ナレッジベース／統合に不足がある場合 → cekura-create-agent。
• 評価のカバレッジが不足している場合 → cekura-eval-design。

ドキュメント

• 公開ドキュメント：https://docs.cekura.ai
• 概念：https://docs.cekura.ai/documentation/key-concepts/

追加リソース

リファレンスファイル（必要に応じて読み込み）

• references/manifest.schema.json — .cekura/selfimprove.yaml 用の JSON Schema。
• references/manifest-guide.md — コンポーネント、権限、環境、コマンド登録、フレークポリシー、ロールバックのセマンティクスについて、フィールドごとに説明するガイド。

レシピ（事前入力済みマニフェスト。該当するものを参照してください）

• recipes/provider-managed.md — 事前入力済みマニフェストとしての、ダッシュボード管理のプロバイダーエージェント（providers/<mode>/ のプレイブックを使用）。
• recipes/runtime-created.md — 顧客のリポジトリ、データベース、またはプロンプトレジストリから、デプロイ時に実体化されるエージェント。
• recipes/custom-mocks.md — シミュレーション用フィクスチャとしての、顧客運用のモックサーバー。

フェーズファイル

• phases/setup.md — マニフェストの検出、検証、セルフテスト。
• phases/loop.md — 証明を伴う改善ループ。
• phases/promote.md — 本番環境への昇格とロールバックの検証。