keyaki development — 内部資料 / 2026年6月

エージェント連携設計

プロジェクト縦割り（PM制）の AI 組織が一つのオフィスで協働するための、
タスク受け渡し・報告経路の設計。ファイルキュー方式。

社内限定設計 v1（PM制） 2026-06-08 更新

Section 01

なぜファイルキューか

常駐セッション同士をどう繋ぐか。3案を比較して B を採用した。

Option Comparison

3案を比較しB を採用

案	仕組み	評価
A tmux send-keys	orchestrator が各ペインに直接プロンプト送信	即時だが割り込みが雑。作業中に競合
B ファイルキュー採用	`_shared/tasks/` に依頼 .md を置き各自が tick で拾う	疎結合・履歴が残る・kick と相性良
C 単一プロセスが全部受ける	Slack を1プロセスだけが受け Task ツールで子起動	常駐セッション方針と二重管理になり矛盾

採用理由：動作主体を各エージェントセッションに置く方針と最も素直に噛み合う。誰が何を依頼・完了したかが監査ログとして残る。即時性が要る場面だけ A を後付けで足す。

Section 02

キューの構造

ステータスを物理ディレクトリで表現し、mv をロック代わりにする。

Queue Layout

ステータス＝物理ディレクトリ

~/agent/_shared/tasks/
├── inbox/ # orchestrator→PM→実装の順に依頼を投函
├── doing/ # 担当が着手時に mv（掴んだ印）
├── done/ # 担当が完了時に mv（結果を追記済み）
└── archive/ # orchestrator が山下へ報告済みにしたもの

なぜ mv か：同一ファイルシステム内の mv はアトミック。これがそのままロックになり、二重着手・取り合いを原理的に防ぐ。

Task File

タスクファイルのフォーマット

命名: YYYY-MM-DD-HHMMSS__<assignee>__<slug>.md

--- frontmatter ---
id: 2026-06-08-103000
assignee: marketing # engineer / frontend / backend / designer / marketing / reviewer
from: pm-focusburst # orchestrator / pm-*
priority: normal # urgent / normal / low
status: inbox
title: FocusBurst ティザー投稿の作成
-------------------

## 依頼内容 # 依頼元（orchestrator / PM）が記述
## 完了報告 # 担当が完了時に追記（成果物URL・PR・所感）

Lifecycle

タスクのライフサイクル

inbox

orchestrator/PM が担当を決めて投函

→

doing

担当が mv して着手宣言

→

done

完了報告を追記し mv（PM が集約）

→

各ロールのtick 動作

管理層（orchestrator・PM）

orchestrator: Slack を受け、担当 PM の inbox/ に投函。done/ を集約 → 山下へ報告 → archive/
PM: タスクを分解し実装ロールの inbox/ に投函。DOCS.md を常に最新化
doing/ の滞留を監視

実働層（engineer / frontend / backend / designer / marketing / reviewer）

inbox/ から自分宛を拾う（urgent 優先）→ doing/ へ mv
実行 → 完了報告を追記 → done/ へ mv
指示待ち徹底: 指示なしの自主改善・PR は出さない（気づきは DOCS.md に記録し PM へ）

Reporting Path

報告はorchestrator に一元化

経路：実働 → PM → orchestrator

実働層の「報告」は done/ への書き戻し
PM が集約して DOCS.md を更新
orchestrator がまとめて山下へ Slack 報告

Slack 発言は orchestrator のみ

山下は orchestrator とだけ対話すればよい
PM・実働・reviewer は Slack に投稿しない（done/ と DOCS で報告）
Slack 設定は _shared/COMPANY.md が保持

Edge Cases

即時性と稼働・衝突

即時性の補完（B の弱点対策）

B は tick 間隔ぶんの遅延が出る
投函後に kick.sh <役割> で担当を即起動できる（tick 待ちを短縮）
通常タスクは tick 待ちで十分

稼働 / 衝突

VM はオンデマンド起動。起動中は dormant なし・24h 稼働（2026-06-07〜）
legal / accounting / reviewer は常駐せず必要時に kick
assignee 固定 + mv のアトミック性で二重着手を防止

Next Steps

確定事項と次のアクション

この設計で確定

連携方式＝ファイルキュー（B）
ステータス＝物理ディレクトリ + mv
報告＝orchestrator に一元化（Slack 発言は orchestrator のみ）
3点セットの役割分担（CLAUDE=ローダ / AGENTS=役割 / DOCS=記憶）

実装済み（2026-06）

_shared/（COMPANY.md / WORKFLOWS.md / kick.sh / tasks/）整備
プロジェクト縦割り（PM制）へ再構成：orchestrator + pm-focusburst / pm-forkbox + 実装プール + reviewer
佐藤（accounting）をローカル LLM（Gemma 4 / opencode）へ移行
orchestrator / PM の tick に投函・集約フローを実装、kick.sh で起動

この連携設計は Scaffold-内部開発計画 の続編。実運用で検証した連携アーキテクチャをそのまま Scaffold テンプレートに反映する。