Matrix AI Placement

マトリックスAI配置理論

複数のAIを役割と工程に配置し、業務システム開発を判断単位まで分解して進めるためのRoundtableの設計思想です。

Roundtable は、ひとつのAIに長い依頼を投げる仕組みではありません。要件を聞くAI、設計を整えるAI、実装するAI、検証するAI、運用判断を補助するAIを、タスクの状態や関連情報に合わせて配置し、作業を細かい判断へ分解して進めます。

位置づけ

マトリックスAI配置理論は、Roundtable と auto-task をまとめて説明するための設計名です。横軸に業務システム開発の工程、縦軸にAIの役割を置き、それぞれの交点で「何を確認し、何を判断し、どの次アクションへ進むか」を定義します。

狙い人間が毎回「次に何をして」と指示するのではなく、AI群がタスクの文脈、過去対応、他タスクとの関係、検証結果を読みながら、作業を次の判断へ進める状態を目指します。

AI配置マトリックス

各AIは縦割りで固定されるのではなく、工程ごとに見る観点が変わります。要件AIは受付時だけでなく、検証で仕様の曖昧さが出た時にも戻って確認し、運用AIは他タスクやリリース待ちの状態も見ながら順序を判断します。

AIの役割	受付・理解	設計	実装	検証	運用判断
顧客対応AI	依頼文、添付、過去履歴から要望を抽出	確認すべき業務ルールを整理	実装中の確認待ちを言語化	期待結果との差分を説明	返答待ち、完了、保留を判断
設計AI	業務の粒度と対象データを確認	画面、DB、権限、通知へ分解	実装方針のずれを検出	仕様観点のテスト条件を作る	後続改善や別タスク化を提案
実装AI	既存コードと対象範囲を特定	既存パターンに沿う実装単位を決める	コード、テンプレート、設定を変更	エラーや表示崩れを修正	反映可能な状態かを整理
検証AI	再現条件と成功条件を読む	確認観点を小さく分ける	途中結果の破綻を検出	CLI、画面、スクリーンショットで確認	未検証リスクを残す
運用AI	他タスク、リリース待ち、障害状況を見る	作業順序と影響範囲を判断	同時変更の衝突を避ける	本番反映前の条件を確認	次の自動実行、保留、通知を決める

リファレンス駆動プロンプト圧縮

AI同士のコミュニケーションでは、仕様、過去タスク、検証条件、関連コメントを毎回プロンプトへ全文で貼ると、すぐに長大化します。Roundtable では、長い本文を直接渡す代わりに、snapshot、spec task、previous task、required section などの参照キーを渡し、受け取ったAIが必要な情報だけを読み直す設計にします。

例: RT_SPEC_REFERENCE snapshot_id、target_appcode、current_task_id、spec_task_id、previous_task_ids、required_sections、読み込みルールを短く渡し、AIは参照先から必要範囲を復元します。

トークン効率 全仕様を毎回コピーせず、参照IDと読み込み範囲だけを渡すため、AI間の受け渡しを短く保てます。

文脈の一貫性 同じ参照元を読むため、担当AIごとに違う要約を持ち回るより、過去判断や仕様の取り違えを減らせます。

必要範囲だけ読む 実装範囲、検証条件、公開側要否など、作業に必要な section だけを指定して読み込みます。

監査しやすい引き継ぎ どの snapshot と task を根拠にしたかが残るため、後続AIや人間が判断の出どころを追いやすくなります。

auto-task による完全自動化への実験

auto-task は、Roundtable が会社全体の業務をAI化していくための実験的な仕組みです。人間が毎回細かく指示しなくても、AIが状況を読み取り、次に必要なタスクを判断し、実行候補を積み上げていくことを目指します。

Roundtable が目指しているのは、単なる作業補助ではなく、業務システム開発と運用の完全自動化です。ただし、完全自動化は一度で完成するものではありません。AIの判断結果を人間が確認し、改善点を与え、方針や例外条件を調整することで、自動化の精度を高めていきます。

細かい判断へ分解 タスク取得、対象判定、影響確認、実装、検証、証跡作成、ステータス更新をひとつずつ分けて扱います。

関連タスクを読む 同じ顧客、同じ機能、未完了タスク、リリース待ち、過去の保留理由を見て、単発対応にならないようにします。

改善点を受け取る AIが自動で進めた結果を人間が確認し、方針、例外条件、責任ある判断を与えることで次の自動実行をよくします。

証跡を残す 何を読んで、何を変更し、何を確認し、何が未確認かを残すことで、後から人間や別AIが引き継げます。

Persistent Fix Loop

Persistent Fix Loop は、階層型AIシステムを「計画 → 実行 → 評価 → 完了」の直線で捉えるのではなく、「検知 → 計画 → 修正 → リリース → 監視 → ループ」として安定化させ続ける考え方です。現実の業務や本番環境では、計画は実行中にずれ、評価条件は外部状況で変わり、AIだけでは完了を断定できないことがあります。

参考記事 Persistent Fix Loop (PFL) は、完了指向のパイプラインを、観測と小さな修正を続ける安定化モデルへ置き換えるための設計メモです。

計画は仮説 最初の計画を絶対視せず、実装中の制約、検証結果、顧客返答、関連タスクの変化に応じて見直します。

修正は小さく局所的に 一度に大きく作り切るのではなく、影響範囲を限定した修正を積み重ね、戻せる単位で安定化します。

評価は観測 AIが「完了」と宣言したかではなく、画面、ログ、ユーザー確認、再発有無など外部の挙動で安定を判断します。

完了より安定 問題が直ったかを一度だけ判定するのではなく、再発、別タスクへの影響、リリース後の状態まで見て閉じます。

完全自動化へ向けた改善フロー

01取得新規タスク、コメント、添付、対象プロジェクトを読む

02理解要望、制約、確認待ち、関連タスクを整理する

03計画編集範囲、検証方法、止める条件を決める

04実行既存パターンに沿って実装・同期・検証する

05判断完了、返答待ち、保留、方針調整、リリース待ちを切り分ける

06改善結果、証跡、残リスク、次の自動実行に渡す条件を残す

人間の役割

完全自動化への実験は、人間の判断をなくすことではありません。人間の役割は「AIに毎回作業を依頼すること」から、「AIが自動で進めた結果を見て、会社としての方針・責任・改善を与えること」へ移っていきます。AI群は、その前後にある調査、整理、実装、検証、記録を細かく進め、人間が判断すべき情報を揃えます。

Roundtable の違い チャットの回答で終わらせず、画面、DB、通知、帳票、運用タスク、検証証跡までを同じ文脈で扱うことが、マトリックスAI配置理論の中心です。