AI組織のハーネス設計で、失敗したこと

Activity 0004では、promptで役割名を渡しただけのsessionにCustom Agentの設定が適用されておらず、role IDをagent_typeへ指定した起動で設定profileの適用を確認しました。

Activity 0005では、起動時のrole ID、UI nickname、model、reasoning effortが設定と一致していても、一部のagentが回答上では別のroleとnicknameを名乗りました。

Activity 0072では、sessionをresumeしても、以前に完了したsubagentがlive treeへ戻りませんでした。

最初にschema、許可文字、tool API、runtime metadataを確認し、その後で組織ルールを設計します。

role ID、UI nickname、自己識別を分け、起動結果をruntime情報で確かめます。

Activity 0034では、通常編集の承認疲れを減らす依頼に対し、AI側が大きなpermission profileを提案し、CEOが意図と異なるとして取り下げました。

Activity 0048では、厳格な完了receipt案が保留、中止、並行作業まで止める構成になり、CEOは採用しませんでした。Activity 0051では、単純な会話確認のためのsession参照helperが複雑化し、作業が中止されました。

Activity 0054では、Ritsuのreviewと改善を重ねた四段階lifecycleでもready化、merge、中止処理が順に停止し、最後はPRとIssueを閉じるためにhelper自体を一時修正しました。

Activity 0055で独自hookとwrapper群を削除し、実行制御を標準のsandboxと承認モデルへ戻しました。その後、Activity 0220と0223で独立review、CEOのmerge承認、Issue対PR、branch対PRの関係を運用規則として定めました。

Activity 0214で企業情報とproduct体験を一つのWeb buildへ統合しました。Activity 0215で旧公開サイトを凍結し、Activity 0217で不要になった作業記録とsnapshot機構を削除しました。Activity 0219では、project外にあったagent定義とroutingを、利用するsourceと同じrepositoryへ移しました。

標準のsandboxと承認モデルを基礎にし、projectには変更主体、IssueとPRの関係、独立review、人間のmerge承認を残します。

現在のルール、agent定義、仕様、design、実行対象は、実際に利用する一つのprojectへ寄せます。

秘密情報、破壊的操作、公開、mergeの境界は守りつつ、想定外の状態では実際の対象と副作用を確認して判断します。

Activity 0007と0040では、GitHub接続、CLI fallback、認証確認、role routingをrepository-local wrapperとproject Skillへ集約しました。

Activity 0055では、独自hookとwrapperを削除し、外部操作を対象限定の直接実行と実状態の再確認へ戻しました。

MakoからRyoma、Manabu、Ikumiへ委譲するような多段のdelegation chainで、孫agentまで起動できることは確認しました。

一方、Makoからは孫agentのhandoffを待っている状態が見えず、孫agentの作業と競合し得る別の作業をほかのsubagentへ指示することがありました。Mako自身のsessionを先に終了し、孫agentがhandoffを返しても回収されない事例もありました。

resumeでは完了済みagentが自動でlive treeへ戻りませんでした。

Activity 0024で、Narrativeの構造と執筆を担うroleから、文章表現を別のScenario Writerへ分けました。

Activity 0033では、意味設計とWritingの境界が曖昧になり、制約の受け渡しと確認が重複していることを、役割再編の理由として確認しました。

現在はWriting専任agentを置かず、Narrative DesignからWritingまでを一つのroleが所有します。

役割は職種名より一貫した成果責任で考え、一つの意味を最後まで保つ範囲を同じroleが所有します。

作成と独立reviewは分けます。

原文の削除を明示的に指示しない場合、AIは既存の記述を残し、削除した仕様を打ち消しや否定として追記する変更を選びやすい状態でした。その結果、現在の仕様と過去の作業記録が一つの文書へ積み重なりました。

修正を重ねるうちに、以前の否定をさらに否定する記述も生まれました。文書は肥大化し、人間にも現在有効な指示が見えにくくなり、AIが古い記述を参照したり、現在のルールに従わなかったりする原因となるノイズになりました。

同じ正本をhandoffやsnapshotへ複製したことで更新経路も増え、どの文書が現在の判断なのかをさらに判別しにくくしました。

AIは原文の削除をリスクと見なし、安全側に追記を選びやすいという前提で、仕様書には作業記録ではなく現在のsystem behaviorを示すマスタであることを明記します。判断が変わったときは、古い仕様を打ち消しや否定として残さず、現在有効な内容へ置き換えることまで更新指示に含めます。

変更の経緯や過去の事実はActivity、運用台帳、archiveへ分け、現在の仕様へ複製せず参照します。

このMAPには現在の解釈だけを掲載し、根拠となる過去の事実は各Activityで読める状態を保ちます。

Narrativeの雛形と過去のreview snapshotはありましたが、CEOの確認、後続design、公開境界の判断に使う現行版が一つに定まっていませんでした。過去に確認した版から、途中で変わった判断や未承認の表現まで再利用される可能性がありました。

ページ本文を直しても、実装担当へ渡す資料には古い文言や、何を公開してよいかについての古いルールが残りました。さらに、正本の内容をその資料へコピーしたため、同じ情報が二か所に存在し、どちらが最新か分からなくなりました。

Narrativeのcurrent masterで事実、解釈、仮説、創作の境界を分けます。Brand Bible、Narrative Guidelines、Fact Boundary、Key TermsでWhy、What、語り口、事実境界、主要語を責務別に管理します。

About、Homeなどの下流成果物は同じ正本へ揃え、正本の内容を複製せず参照します。

正本にない新しいブランド判断は人間の確認へ戻します。