JA
作者が提供したKikiの猫の画像から作った、背景を透過した顔の派生画像
展示室へ戻る

Kiki

業務シグナルとエージェントの実行

提案が担当者の実行につながるように。

チームがAIエージェントを運用するのを助ける、PaperclipプラグインとSlack収集ツールです。

2026.04 — 2026.05

pinxlab AI R&Dフリーランス · 業務フローの企画・開発、実行停滞の原因調査と復旧経路の設計

  • プラグイン実装済み · Paperclip
  • MCPサーバー実装済み · Slack収集

割り当てと実際の実行のあいだの、観測と復旧の経路

業務シグナルをプロフィールとエージェントへの指示に変え、保守の提案の承認と実行の割り当てを分けています。割り当て済みのイシューの活動が止まると、イシューと担当者を含めて再び要求し、繰り返される無応答は上限、クールダウン、人の判断へと送ります。

業務シグナルをエージェントへの指示に変え、保守の提案、人による承認、担当の割り当て、停滞した実行の復旧を、それぞれ別の段階としてつなぎます。この流れを企画・開発しました。

リポジトリの最初の記録 April 3, 2026 · pinxlabへの参加 May 26, 2026まで

チームのPaperclip内でプラグインとして動作し、Slackの収集はMCPサーバーが担います。

実行フロー構成図 · 非公開の実装記録に基づく
Kikiのシグナル · 承認 · 実行の復旧アクセスできるSlackチャンネルの履歴から業務パターンを抽出し、会社ごとのプロフィールとエージェントごとの指示を作ります。保守分析エージェントは対象プロジェクトを調べ、担当者のいないbacklogのイシューとして提案を残します。各提案はSlackに投稿され、人がリアクションで承認または却下します。承認されたイシューがエージェントに割り当てられると、外部の実行システムが作業を行い、stage reaperが最近の活動を監視します。活動が止まると、イシューと担当者を含めて割り当てを再度要求し、連続した無応答が上限に達すると再呼び出しを止めて、Leadまたは運用者に引き渡します。Slackのシグナルアクセスできるチャンネルの履歴担当エージェント外部実行対象プロジェクト内容は非表示人 · 承認、却下SlackのリアクションLead · 運用者再割り当て · 通知シグナルの収集パターン抽出 · botを除外会社の状態会社プロフィールのマージエージェントの状態エージェントごとの指示実行の観測最近の実行 · 活動保守分析PO呼び出し · スコープを限ったプロンプトイシュートラッカー提案 · backlog実行イシュー · todo提案の投稿メッセージ ↔ イシューの対応表Stage reaper停滞の判定 · heartbeat復旧呼び出しイシュー + 担当者無応答の状態無応答回数 · イシューごと上限再呼び出しを停止 · クールダウンシグナル → 指示外部実行提案 → 人による承認復旧 · エスカレーション1チャンネル履歴2プロフィールのマージ3再生成4指示の注入1対象のスコープ2提案イシュー3提案を投稿4Slackメッセージ5リアクション6承認 → todo7却下 → cancelled8割り当て1実行記録2最後の活動3無応答+14新しい活動 → リセット5 再呼び出し · 停滞の判定 · heartbeat → イシュー + 担当者56イシュー + 担当者73回の後8再割り当て · 通知9警告のみ

シグナル → 指示

Slackの履歴からプロフィールとエージェントへの指示を作ります。指示はエージェントのコンテキストであり、どの提案の原因としても描いていません。

  1. Slackのシグナルチャンネル履歴パターン抽出 · botを除外シグナルの収集

    アクセスできるチャンネルの履歴を収集し、bot、参加、退出のメッセージは除外します。元のメッセージはこのページに載せていません。

  2. パターン抽出 · botを除外シグナルの収集プロフィールのマージ会社プロフィールのマージ会社の状態

    抽出したパターンはプロフィールのパッチとなり、会社プロフィールにマージされます。ヒューリスティックなパターンであり、従業員の業績評価ではありません。

  3. 会社プロフィールのマージ会社の状態再生成エージェントごとの指示エージェントの状態

    マージしたプロフィールから、エージェントごとの指示を再生成して保存します。

  4. エージェントごとの指示エージェントの状態指示の注入担当エージェント

    指示は、エージェントの作成時にそのコンテキストに入ります。特定の提案が特定のSlackシグナルから生まれたという意味ではありません。

提案 → 承認 → 割り当て

提案はまず担当者のいないbacklogのイシューとして生まれ、人のリアクションが状態の変更を要求し、割り当てと実行は外部のシステムが担います。

  1. 対象プロジェクト対象のスコープPO呼び出し · スコープを限ったプロンプト保守分析

    保守ジョブは、対象プロジェクトにスコープを限ったプロンプトでPOエージェントを呼び出します。ソースの内容は表示しません。

  2. PO呼び出し · スコープを限ったプロンプト保守分析提案イシュー提案 · backlogイシュートラッカー

    プロンプトは、確認済みのパスだけを含む提案を担当者のいないbacklogのイシューとして作り、DBの移行を実行しないよう求めます。決定論的に強制する仕組みではなく、製品のエージェントへの指示です。

  3. 提案 · backlogイシュートラッカー提案を投稿メッセージ ↔ イシューの対応表提案の投稿

    各提案をSlackに投稿し、メッセージとイシューの対応を保存します。投稿済みの提案は再投稿せず、保存する対応表は最新の50件です。

  4. メッセージ ↔ イシューの対応表提案の投稿Slackメッセージ人 · 承認、却下

    人は投稿された提案をSlackで見ます。

  5. 人 · 承認、却下リアクションメッセージ ↔ イシューの対応表提案の投稿

    メッセージへのリアクションから、対応表でイシューを見つけます。自動承認はありません。

  6. メッセージ ↔ イシューの対応表提案の投稿承認 → todo実行イシュー · todoイシュートラッカー

    承認されると、保留中の提案イシューをtodoへ移すよう要求し、対応表とスレッドの通知を更新します。このハンドラはレスポンスコードを確認せずに対応表を承認済みにするため、フェイルクローズドのトランザクションではありません。

  7. メッセージ ↔ イシューの対応表提案の投稿却下 → cancelled提案 · backlogイシュートラッカー

    却下されると、同じイシューをcancelledへ移すよう要求します。イシューは承認の前から存在し、承認がイシューを作るのではありません。

  8. 実行イシュー · todoイシュートラッカー割り当て担当エージェント

    todoのイシューの割り当てと実行は、外部の実行システムが担います。イシューをtodoに移しても、作業が始まったことは保証されません。

停滞 → 復旧 → 人

活動が止まった割り当て済みのイシューは、イシューと担当者を含めて再要求し、連続した無応答が上限に達すると人に引き渡します。

  1. 担当エージェント実行記録最近の実行 · 活動実行の観測

    担当エージェントの実行と最近のシグナルが観測として記録されます。活動は完了の証拠ではありません。

  2. 最近の実行 · 活動実行の観測最後の活動停滞の判定 · heartbeatStage reaper

    reaperは、done、cancelled、blockedのいずれでもなく担当者のいるイシューだけを見て、最新のシグナルとstageの経過時間を計算します。

  3. 停滞の判定 · heartbeatStage reaper無応答+1無応答回数 · イシューごと無応答の状態

    連続した無応答をエージェントとイシューの組ごとに数え、状態に保存します。

  4. 最近の実行 · 活動実行の観測新しい活動 → リセット無応答回数 · イシューごと無応答の状態

    新しい活動があると回数をリセットします。

  5. 停滞の判定 · heartbeatStage reaper再呼び出しイシュー + 担当者復旧呼び出し

    heartbeatを超え、回数が上限未満であれば、復旧呼び出しを行います。

  6. イシュー + 担当者復旧呼び出しイシュー + 担当者実行イシュー · todoイシュートラッカー

    イシュー、担当エージェント、説明のコメントを含めて割り当てを再要求し、HTTPレスポンスを確認します。legacy経路では1回の起動呼び出しで代替します。

  7. 無応答回数 · イシューごと無応答の状態3回の後再呼び出しを停止 · クールダウン上限

    連続した無応答が上限（既定3回）に達すると、再呼び出しを止めます。上限は状態フックが回数を読み書きする場合にのみ守られ、保存に失敗すると弱まることがあります。

  8. 再呼び出しを停止 · クールダウン上限再割り当て · 通知Lead · 運用者

    可能ならLeadに再割り当てし、その機能が有効な場合に限りin_progressをtodoに戻します。そうでなければコメントとベストエフォートの通知を残し、上限到達後のクールダウンを記録します。

  9. 停滞の判定 · heartbeatStage reaper警告のみLead · 運用者

    stageが長く続きすぎると、運用者向けの警告コメントだけを残します。状態は自動では変えません。

すべての接続を同じ太さで表示します。フローを選ぶと、その経路だけを番号付きで強調します。

  • 実線 · 入力、結果、記録の流れる方向
  • 破線 · 実行、判定、要求
  • 長い点線 · 観測と報告、判定とは別
  • 短い破線 · 失敗、停止、上限
  • 太い黒線 · 選んだフロー。番号は順序
  • ボックス · コードまたは状態の境界、見出しに名前
  • 内側のチップ · その境界の構成要素
  • 点線ボックス · その境界の外
  • オレンジの枠 · モデルが判断する場所
  • エージェント呼び出し · 復旧呼び出し
  • 状態 · 記録
  • 停滞の判定 · 上限
  • 収集 · 投稿

非公開の実装記録と開発記録から作図しました。チーム、イシュー、Slackの識別子と元のメッセージは表示していません。デプロイ、コンテナ、認証情報は、このプラグインの外の担当者のものです。

1件の観測
2026年4月28日のレポート：変更前の手動診断で、67時間実行されていなかったイシュー1件について、イシューと担当者を含めて割り当てを再要求したところ、5秒以内に新しい実行がキューに入りました。完了、平均復旧時間、デプロイ後の効果は測定していません。
承認処理の限界
復旧呼び出しと異なり、承認処理はレスポンスコードを確認せずに対応表を承認済みにします。アトミックな、あるいはフェイルクローズドの承認トランザクションとしては記述していません。
上限が守られる条件
3回の上限は、状態フックがある場合に守られる実装です。あらゆる失敗でエスカレーションがちょうど1回になることを保証するものではありません。