AI組織の実行権限を、狭い入口から組み直す

Organization DesignerのYuiは、Makoが個々の専門roleを選び続ける構造を改め、依頼の主要な成果に応じてprimary domain leadを一人選ぶ方式を設計した。組織運用、AI organization governance、Wirohのcorporate siteはYui、product workはRyomaが受け持つ。領域をまたぐ依頼では、主要な成果、scope分割、依存関係、relay pathを示して一人のleadを決め、専門roleの呼び出し順はlead側に委ねた。

- Executive Secretary は specialist を個別に選び続ける orchestrator ではなく、dominant business outcome に基づいて primary domain lead を選び、relay path を示す top-level router として振る舞うこと
- 組織ルール、AI 組織設定、AI organization governance、Wiroh corporate site 関連は `yui` / `organization-designer` に routing すること
- gorillango product 関連は `ryoma` / `product-manager` に routing すること
- cross-domain または ambiguous な要求では、primary domain lead を 1 つ定め、scope split と依存関係を明示し、ownership choice が outcome を実質的に変える場合だけ CEO に確認すること

実質的な作業は、日本語のTaskを先に記録してから始めるTask-firstへ揃えた。domain leadはCEOが承認した依頼について追加承認なしでrequirements Taskを作成し、不足する要件を確認し、必要ならEpicやUser Storyへ分ける。requirements Taskは親User Storyなしを許容する一方、専門roleや実装のTaskは親へ紐づける。その後、技術設計、UI/UX、法務、実装を依存関係に沿って委譲する。複数roleを並行で動かす場合は、担当境界、入力、依存関係、期待する出力、合流点、停止条件を全員へ共有し、未解決の出力に依存する作業や同じファイル群を変更する作業は並列化しない規則にした。

project設定からMakoのmodelとreasoning effortの固定を外し、CEOの選択と実行環境へ委ねた。七つのcustom agentは用途に応じてGPT-5.6 SolまたはTerraとhigh reasoningへ割り当て、同時に開けるagent threadを八つ、委譲の最大深度を四に設定した。workspace-writeは維持し、network accessは必要な接続先だけに限定する構成へ変えた。max_depth = 4は、depth 0のMakoからdomain lead、Solution Architect、Full-Stack Engineer、depth 4のReviewerまで、五つの主体を四回の直接handoffでつなぐ上限であり、無制限の再帰委譲は別の規則で禁止した。これは設定の整合を確認したもので、modelごとの成果品質や処理速度、network制御のruntime挙動を比較・実証した結果ではない。

Ayaのroleはweb-designerからui-ux-designerへ変更した。担当範囲をWeb画面だけでなく、UX research、user journey、information architecture、interaction、mobile UI、accessibility、design system、Figmaまで広げた。非自明なproductのUser StoryではProduct Manager、UI/UX Designer、Solution Architectを基本の三者とし、小規模な作業でdesignまたはarchitecture gateを省略する場合は、適用外とする理由を残す運用にした。

実行権限は、確認条件付きの通常操作とCEOの判断が必要な操作に分けた。承認済みのdomain requestに対するTask Issue作成は追加承認なしとし、Pull Requestのmergeとforceを伴う操作はCEO承認後に限定した。直接のrmは禁止し、生成物の削除、既存branchへの切り替え、現在の作業branchのnon-force pushには、引数と対象を検査する専用wrapperを追加した。

Ritsuのreview対象もPull Requestのcodeから、Issue draft、Task draft、architecture note、design note、legal draft、workflow文書、agent定義、handoff packetを含むnon-Ritsu成果物へ広げた。review requestには対象、作成role、要件または完了条件、依存関係、検証証拠、review観点を含める。法務draftでは、Ritsuはprocess、scope、consistency、evidence、delivery riskだけを確認し、法的妥当性の判断はLegal CounselとCEOによる法務確認に残した。

独立reviewを重ねる中で、direct rmやforce optionの表記・順序による回避、protectedまたはremote default branchへpushできる経路、review未完了を完了報告に含められる文言、requirements Taskと実装Taskの親Issue規則などに修正が必要と判断された。Yuiが設計した修正packetをMakoが開示された機械relayとして適用し、rules、wrapper、role定義、Skill、運用文書を横断して整えた。Ritsuが再reviewで明示的にpassした後にのみ完了扱いとした。

この作業では、CEOがmodel選択、承認境界、role変更、推奨運用を確定した。MakoはOrganization Designerへのrouting、blockerの可視化、runtime制約で直接適用できないexact patch packetの機械的relay、進捗と結果の統合を担当した。Yuiは組織設計、修正packetの作成、横断整合の確認を担当し、Ritsuは実装担当から独立したreviewと再確認を担当した。