• MiTiR：多数のAI Agent・アプリ・サービス・知識を束ねる長期プロジェクト
• MiTiR-Base：MiTiR全体の司令塔／Control Plane
• 開発体制：開発者↔️ChatGPT.Plus.Prj.↔️Github::Repository::SDD↔️Codex@VSCode::SDD
• 基本UX：人間は主にSecretary AIと会話し、裏側のAgent群を直接管理しない
• 初期Agent構成：Secretary → Research / Information / Investment / System-Development
• AgentとServiceの分離：判断・委任するのがAgent、決められた機能を実行するのがService
• 3本柱：Agent組織 / Docker上のApps・Services・PoCs / Obsidian中心のKnowledge
• Repository方針：MiTiR-Baseに全部詰め込まず、大きい既存アプリは独立RepoのままRegistry経由で利用
• InsightForge連携：AI Research Scan（日次）とTurbine Research Scan（週次）を再利用
• Daily Intelligence：AIニュース等を収集し、重要3〜5件をInformation Agentが抽出してSecretaryへ報告
• Research Copilot：週次論文をRecommended / Optional / Skipで評価し、人間が選択してDeep Research
• Research Note：要約・新規性・技術要点・適用可能性・追加課題・出典＋図解を保存
• Virtual Trading Lab：週末に人間＋AIでWeekly Strategyを決め、平日はPaper Tradingを自動実行
• Trading日次レビュー：P&L、保有、売買理由、リスク、CONTINUE / ADJUST / REVIEW_REQUIREDを報告
• Docker方針：内部通信はDocker Network内、Host公開PortはGateway/Secretaryなど最小限
• SDD：Spec → Architecture → Task → Implementation → Test → Docs Update → Commit
• Test方針：Small / Medium / Large変更ごとに必須テストを定義
• Registry：App / Agent / Serviceの所在・依存・状態・権限・RuntimeをYAMLで機械可読管理
• Logging：実行者、入力、結果、エラー、時間、モデル、Costなどを監査可能に保存
• Knowledge方針：大量ログはDB等、重要な研究成果・レポートだけObsidianへ昇格
• 開発体制：Human＝目的と判断、ChatGPT＝設計・仕様・レビュー、Codex＝実装・テスト
• 開発戦略：共通基盤＋Daily / Research / Tradingを並列開発
• v0.1ゴール：Secretaryに「今日どうだった？」と聞くと、3領域の実データをまとめて答える
• 長期思想：AIが増えるほど、人間が直接見るものは減るシステムを目指す

はじめに

生成AIを使ったアプリケーションを作っていると、ある時点から別の問題が出てくる。

AIニュースを集めるアプリ、論文を調査するアプリ、文章を生成するアプリ、投資を分析するアプリ、社内業務を支援するアプリ……。

個々のアプリケーションを作ること自体は、生成AIとCodexのようなコーディングエージェントの登場によって急速に容易になってきた。

しかし、アプリケーションが10個、50個、100個と増えたらどうするのか。

さらに、それぞれのアプリをAI Agentが使い、そのAgentを別のManager Agentが管理するようになったら、人間が個々のAgentやアプリケーションを直接監視する方式はすぐに限界を迎える。

そこで考え始めたのが、MiTiRである。

MiTiRは単なるAIチャットアプリではない。

目標は、

多数のAI Agent、アプリケーション、サービス、知識を組織として管理し、人間は上位のAIと会話するだけで、その組織全体を利用できるようにすること

である。

そして今回、その長期構想を実現するための基盤として開発を始めたのが、MiTiR-Baseである。

---

1. MiTiRとMiTiR-Base

最初に名称を明確にしておく。

MiTiRはプロジェクト全体の名称である。

一方、今回GitHub上で開発しているMiTiR-Baseは、そのMiTiRを支える基盤、つまりControl Planeに相当する。

イメージとしては、

MiTiR
│
├── MiTiR-Base
│   ├── Agent組織管理
│   ├── Service管理
│   ├── App Registry
│   ├── Secretary
│   ├── GUI
│   ├── Logging / Audit
│   └── Infrastructure
│
├── 独立Application A
├── 独立Application B
├── 独立Application C
│
└── Knowledge / Obsidian

という関係になる。

重要なのは、MiTiR-Baseの中にすべてのアプリケーションコードを詰め込まないことである。

MiTiR-Baseは巨大なモノリスではなく、

「どのAgentが存在し、どのApplication/Serviceを利用でき、どこに何があり、現在どういう状態なのか」

を管理するControl Planeとして設計する。これは当初からの基本Architectureにも明記した。

---

2. なぜ「AI組織」という考え方にしたのか

将来的に100個のAgentが存在すると仮定する。

人間が100 Agentすべての状態を見るのは現実的ではない。

そこで、人間の会社と同じように階層構造を作る。

初期構成は非常にシンプルである。

Human
  │
  ▼
Secretary Agent
  │
  ├── Research Agent
  ├── Information Agent
  ├── Investment Agent
  └── System / Development Agent

人間は基本的にSecretary Agentと会話する。

Secretaryは必要に応じて各専門Agentへ仕事を依頼する。

例えば、

「今日どうだった？」

と聞けば、

Information Agentから今日のAIニュースを取得し、Research Agentから研究状況を取得し、Investment Agentから今日の仮想取引結果を取得して、それらを統合して回答する。

重要なのは、最初から三層、四層の巨大な組織を作らないことである。

当面は、

Human → Secretary → Specialist Agent

という二層で始める。

Agentが増えて管理不能になった領域だけ、その下にManagerを追加して三層化する。

つまり、

必要になる前に組織階層を増やさない。

という設計思想である。

---

3. MiTiRの三本柱

議論を進める中で、長期的なMiTiRは大きく三本柱で構成することにした。

                 MiTiR
                   │
       ┌───────────┼───────────┐
       ▼           ▼           ▼
    Agents      Apps/PoCs    Knowledge
   Organization   Services    / Obsidian

第一の柱はAgent組織。

第二の柱はApplication / PoC / Service群。

第三の柱はKnowledge Systemである。

Agentは考え、判断し、仕事を委任する。

ApplicationやServiceは実際の処理を行う。

そして重要な結果や研究成果はKnowledge Systemへ蓄積する。

この3つを分離しておくことで、将来Applicationが入れ替わってもAgent組織を作り直す必要がない。

逆にLLMやAgent構成を変更しても、既存Applicationをそのまま再利用できる。

---

4. AgentとServiceをどう区別するか

設計上かなり重要だった議論の一つが、

「LLMを使ったらAgentなのか？」

という問題だった。

結論はNoである。

MiTiRでは、AgentとServiceの違いをLLMを使うかどうかではなく、自律的に判断するかどうかで決める。

例えば、

今日どの論文を読むべきか決める
        ↓
      Agent

arXivを検索する
        ↓
     Service

である。

同じように、

どの投資情報が重要か判断する
        ↓
   Investment Agent

与えられた市場データを要約する
        ↓
      Service

となる。

Service内部でLLMを使っても構わない。

ただし、Serviceは与えられた仕事を実行するものであり、組織として「次に何をすべきか」を決めない。

この境界を明確にしたことで、Agentが何でも行う巨大なプログラムになるのを避けられる。

---

5. MiTiR-BaseのRepository構成

MiTiR-Baseでは、基本構成を次のようにした。

MiTiR-BASE/
├── apps/
├── agents/
├── services/
├── poc/
├── infra/
├── docs/
│   ├── architecture/
│   ├── specs/
│   ├── tasks/
│   ├── decisions/
│   └── roadmap/
├── app-registry/
├── AGENTS.md
└── README.md

それぞれには明確な責務を持たせる。

agents/ は自律判断するAgent。

services/ は検索、収集、分析、要約、Knowledge操作、Report生成、Executionなどの再利用可能機能。

apps/ はMiTiR本体に属するユーザー向けApplication。

poc/ は実験場である。

PoCについては、

PoC
 ↓
採用
 ↓
App / Service
 ↓
十分大きくなったら独立Repository

という昇格経路を想定している。

---

6. 巨大Repositoryにしない

当初、MiTiR-Baseの下にすべてのApplicationを置く案も考えた。

しかし、それでは将来的にRepositoryが巨大化する。

そこで採用した原則が、

大きなApplicationは独立Repositoryとして維持し、MiTiR-BaseにはRegistryだけ置く。

という方式である。

その最初の実例がInsightForgeである。

現在Mac miniでは、

~/work/
├── MiTiR-Base/
└── 0110_InsightForge/

というように、MiTiR-BaseとInsightForgeは兄弟Directoryとして存在する。

InsightForgeのコードをMiTiR-Baseへコピーしない。

MiTiR側では、

app-registry/
└── insightforge.yaml

によって、

• Application名
• 所在地
• 呼び出し方式
• Capability
• 出力形式
• 利用するAgent

などを登録する。

これによって将来InsightForgeをDocker化したり、別マシンへ移したりしても、MiTiR側のAgent設計を変更する必要がない。

---

7. InsightForgeを再利用する

InsightForgeはすでにかなり完成度の高い独立Applicationだった。

内部には、

daily_research/
├── adapters/
├── application/
├── domain/
├── entrypoints/
├── llm/
├── presentation/
└── research/

があり、

Search Adapterとして、

• arXiv
• RSS
• Tavily

なども分離されている。

Application Layer、Domain Layer、Repository、LLM Provider、Presentationなども分離され、Integration TestやUnit Testも存在している。

さらに重要だったのが、公開CLIがすでに存在したことである。

daily-research

というCommandを外部Interfaceとして利用できる。

したがってMiTiRからInsightForge内部のPython Moduleを直接importしない。

MiTiR
   │
   ▼
InsightForge CLI
   │
   ▼
Research Pipeline
   │
   ▼
Markdown / Obsidian

という疎結合構造にした。

現在のMiTiR v0.1 Architectureでも、InsightForge内部Moduleをimportせず、公開CLIだけを利用することが明示されている。

---

8. Dockerは「大量のPortを管理しない」

将来Applicationが大量に増えると、

App A : 8001
App B : 8002
App C : 8003
...

のようにHost Portを割り当てる方式は管理が難しくなる。

そこでMiTiRでは、内部Application/Serviceを基本的にDocker Network内部に閉じ込める。

Internet / LAN
      │
      ▼
Gateway / Secretary
      │
      ▼
Docker Internal Network
 ├── Service A
 ├── Service B
 ├── Agent A
 ├── Agent B
 └── Database

内部通信はDocker Service Nameで行う。

Hostへ公開するPortはGatewayなど必要最小限にする。

現在のv0.1でもSecretaryがHost-facing edge networkとMiTiR内部Networkの両方に接続し、Host Portを公開するのはSecretaryだけという構成まで実装されている。

---

9. KnowledgeはObsidianへ

すべての実行ログをObsidianへ入れるわけではない。

ここも役割を分ける。

日々のExecution Log、Error、Duration、Job IDなどはOperational Storeへ置く。

一方、

• Research Note
• 重要なReport
• 再利用価値のある結論
• 長期間残すべきKnowledge

などをObsidianへ昇格させる。

つまり、

大量のOperational Data
        │
        ├── Logs / DB
        │
        └── 重要な知識だけ
                 ↓
              Obsidian

という構造である。

これによってObsidianが単なるログ置き場になるのを防ぐ。

---

10. Spec-Driven Developmentを開発ルールにする

MiTiRでは、生成AIやCodexが大量のコードを高速生成することを前提にしている。

だからこそ、「コードを書く速度」よりも「仕様とコードが乖離しない仕組み」の方が重要になる。

そこで開発Lifecycleを、

Spec
 ↓
Architecture
 ↓
Task
 ↓
Implementation
 ↓
Test
 ↓
Docs Update
 ↓
Commit

とした。

docs/ の中に、

docs/
├── specs/
├── architecture/
├── tasks/
├── decisions/
└── roadmap/

を置く。

GitHubをEngineering上のSource of Truthとする。

人間、ChatGPT、Codexの三者が、同じSpecとArchitectureを見ながら開発できるようにする。

---

11. コードを変更したら必ずTestする

SDDへ追加した重要な原則がTest Policyである。

変更をSmall / Medium / Largeに分ける。

Small ChangeではTargeted Unit TestとLint/Type Check。

Medium ChangeではUnit Test、Integration Test、Regression Test。

Large ChangeではさらにE2E、Docker Startup、Health Check、必要ならPerformance/Recovery Testまで行う。

つまり、

コードを書いたことではなく、必要なTestが通ったところまでを「実装完了」とする。

Codexにもこのルールを守らせる。

---

12. v0.1で何を実証するのか

長期構想を全部作ろうとすると完成しない。

そこでMiTiR v0.1では、3つの具体的Use Caseを実際に動かすことにした。

                 Secretary
        ┌──────────┼──────────┐
        ▼          ▼          ▼
     Daily      Research    Virtual
 Intelligence   Copilot    Trading Lab

最終的なデモ目標は非常にシンプルである。

人間がSecretaryへ、

「今日どうだった？」

と聞く。

Secretaryが3つのDomainから情報を集めて回答する。

つまり、AI組織と会話できることを実証する。

これがv0.1の中心Goalである。

---

13. Use Case 1 ― Daily Intelligence

Daily Intelligenceについては新しい情報収集Systemを作らない。

すでにInsightForgeに、

AI Research Scan (Daily)

が存在する。

これをそのまま利用する。

処理は、

AI Research Scan (Daily)
        ↓
InsightForge
        ↓
情報収集 / Research / LLM処理
        ↓
Markdown
        ↓
Obsidian
        ↓
Information Agent
        ↓
重要情報 3〜5件
        ↓
Secretary

となる。

Information Agentは大量の記事をそのままSecretaryへ渡すのではない。

重要度、新規性、関連性などから3〜5件程度を選ぶ。

そしてSecretaryが、

• 今日何が起きたか
• なぜ重要か
• 詳細を見るべきものは何か

を人間へ伝える。

実装では、InsightForgeのpublic CLI smoke testまで通り、実際のAI Research Scan artifactから3件のDaily Intelligence summaryを生成できるところまで進んでいる。

---

14. Use Case 2 ― Research Copilot

二つ目はResearch Copilot。

こちらもInsightForgeを入口として利用するが、対象はDaily Scanではなく、

Turbine Research Scan (Weekly)

である。

対象分野は、

• Turbomachinery
• Steam Turbine Design
• CFD
• Blade Vibration / Flutter
• Physical AI
• AI-assisted Turbine Design

など。

ただしWeekly Scanの結果を全部Deep Researchするのは効率が悪い。

そこでAIと人間の役割を分けた。

Research Copilotが各論文・記事を、

Recommended
Optional
Skip

に分類する。

GUI上ではRecommendedのものを最初からCheck状態にする。

ただし最終判断は人間が行う。

人間はCheckを外してもいいし、Optionalを追加してもいい。

そして、

Deep Researchを実行

すると、Checkされた対象だけを詳細調査する。

---

15. Deep Researchを無限ループにしない

Agentに「徹底的に調べろ」とだけ指示すると、調査範囲が制御不能になる可能性がある。

そこでv0.1ではDeep Researchをbounded operationにした。

Weekly Scan
    ↓
AI Recommendation
    ↓
Human Selection
    ↓
Deep Research 1 pass
    ↓
Research Note
    ↓
Human Review
    ↓
必要なら追加Research

最初は一段だけ深掘りする。

さらに必要なら、人間が明示的に追加Researchを指示する。

これによってCost、時間、品質を管理できる。

---

16. Research Noteは文章だけにしない

Research Noteには最低でも、

• Summary
• Novelty
• Technical Points
• Turbine Designへの適用可能性
• Open Questions
• Follow-up Research
• Sources

を入れる。

さらに重要なのがVisual Informationである。

論文の内容は文章だけでは理解しづらい。

そこでResearch Noteには、利用可能なSource Figureの参照や、必要に応じて、

• Concept Diagram
• Flow Diagram
• Comparison Diagram
• Architecture Diagram

などを生成する。

現在のv0.1実装では、まずMermaidによる説明DiagramをResearch Noteへ含めるところまで実装されている。Weekly artifactから候補を選択し、実際にdurable Research Noteを生成するE2Eも完了している。

---

17. Use Case 3 ― Virtual Trading Lab

三つ目がVirtual Trading Lab。

当初は「割安株を10銘柄選んで自動取引する」といった固定Strategyも考えた。

しかし議論を進めるうちに、それでは面白くないことに気付いた。

本当に作りたいのは、

人間とAIが週末に市場について議論し、その週のInvestment Strategyを一緒に決め、平日はAIがそのStrategyに従って自動運用する研究環境

である。

そこでWeekly Strategy Sessionという考え方を導入した。

---

18. Weekly Strategy Session

土日など週末に、人間とInvestment Agentが壁打ちする。

例えば、

• 現在の市場環境
• 金利
• 景気
• Sector Rotation
• Earnings
• AI関連動向
• Valuation

などについて話す。

その結果、

「今週は大型割安株を狙う」

「AI Infrastructure関連の押し目を狙う」

「今週はDefensive中心にする」

などのInvestment Thesisを決める。

重要なのは、Strategyを永久固定しないことである。

毎週、市況に応じてテーマそのものを人間とAIが考える。

---

19. Weekly Strategyを機械可読にする

壁打ちで決めただけでは自動取引できない。

そこで合意したStrategyをMachine-readableなWeekly Strategyとして保存する。

最低限、

Market / Universe
Investment Thesis
Selection Criteria
Risk Limits
Maximum Positions
Trade Constraints
Prohibited Actions

などを持たせる。

Investment Agentは平日、このWeekly Strategyの範囲内だけで自律行動できる。

---

20. 平日は自動運転

Weekly Strategyが承認されたら、平日は人間を介さない。

Market / News / Fundamentals
          ↓
   Investment Agent
          ↓
      Decision
          ↓
     Risk Service
          ↓
   Paper Trading
          ↓
    Position / P&L

Investment Agentは情報収集、分析、Candidate Selection、売買判断を行う。

ただしExecution前にRisk Serviceを通す。

v0.1ではPaper Tradingのみである。

実資金への発注経路そのものを作らない。

これは単なるUI上の禁止ではなくArchitecture上のSafety Boundaryとしている。

---

21. 毎日のTrading Report

週次Strategyだけでは十分ではない。

毎日のMarket Close後に、

Daily Trading Report

を生成する。

内容は、

• Daily P&L
• Cumulative P&L
• Positions
• Trades
• 売買理由
• 重要Market News
• Risk Status
• Weekly Strategyに対する進捗
• Benchmarkとの比較

など。

そしてInvestment Agentがその日の最後に、

CONTINUE
ADJUST
REVIEW_REQUIRED

のいずれかを判定する。

CONTINUEならそのまま翌日へ。

ADJUSTならWeekly Strategyの範囲内で戦術的微調整を行う。

REVIEW_REQUIREDならStrategyの前提そのものが崩れた可能性があるので、勝手に別Strategyへ変更せずSecretaryへEscalationする。

つまり、

Weekend
 Human + AI
 Strategy Session
      ↓
 Weekly Strategy
      ↓
Mon ─ Tue ─ Wed ─ Thu ─ Fri
 │     │     │     │     │
Auto  Auto  Auto  Auto  Auto
Trade Trade Trade Trade Trade
 │     │     │     │     │
Daily Daily Daily Daily Daily
Report Report Report Report Report
      ↓
 Weekly Review
      ↓
Next Strategy Session

というLearning Loopになる。

---

22. Trading Labの現在の実装

v0.1では、外部Brokerへいきなり依存せず、Adapter-neutralなLocal Paper Ledgerを採用した。

Weekly Strategy Schema、Approval Transition、Market Snapshot Interface、Investment Decision、Risk Check、Paper Execution、Position/P&L Persistence、Daily Trading Reportまで実装されている。

さらに、

Approved Strategy → Decision → Risk → Paper Fill → Daily Report

というE2E Testも通っている。

そしてProduction Execution Routeが存在しないこと自体もRegression Testの対象としている。

---

23. Secretaryがすべてをまとめる

3つのUse Caseを別々のWeb Applicationとして見せるだけではMiTiRの意味が薄い。

MiTiRの中心はSecretaryである。

Secretary自身が各Domainの実装詳細を知る必要はない。

各Agentから共通形式で、

domain
reporting timestamp
status
headline / summary
important items
source artifact references
alerts / actions

を受け取る。

Secretaryはそれらを統合する。

そのため人間は、

「今日どうだった？」

「今週の研究どう？」

「今日トレードどうだった？」

「この論文を深掘りして」

といった自然な会話でAI組織を操作できる。

---

24. GUIの考え方

将来的にAgentが100体存在しても、100体分のDashboardを最初から表示するつもりはない。

GUIではまず、

Agent Organization Tree

を見せる。

そして必要なAgentを開くと、

• Status
• Responsibilities
• Applications
• Services
• Recent Reports
• Health
• Execution History

などを見られるようにする。

一方、通常利用ではSecretaryとのConversationを中心にする。

つまりGUIには、

┌──────────────────────────────┐
│          Secretary           │
│                              │
│  「今日どうだった？」        │
│                              │
├─────────┬─────────┬──────────┤
│ Daily   │Research │ Trading  │
│ Intel.  │Copilot  │ Lab      │
└─────────┴─────────┴──────────┘

のような形を想定している。

v0.1ではすでにConversation Areaと3つのDomain Cardを持つSingle-page Prototype UIまで実装されている。

---

25. RegistryがMiTiRをつなぐ

MiTiRではRegistryが非常に重要になる。

例えばInsightForgeなら、

id: insightforge
type: app
name: InsightForge Daily Research
status: active

integration:
  kind: cli
  command: daily-research

provides:
  - ai-research-scan-daily
  - turbine-research-scan-weekly

consumers:
  - information-agent
  - research-agent

のような情報を持つ。

将来的にはこのRegistryから、

• Agent Tree
• Dependency Graph
• Runtime Status
• Repository Location
• Health
• Permissions

などをGUIへ自動表示できる。

つまりRegistryは単なる設定ファイルではなく、AI組織の機械可読な組織台帳になる。

---

26. Human、ChatGPT、Codexの役割分担

今回の開発では、もう一つ特徴的な構造を採用している。

Human
  │
  ├── Goal / Judgment
  │
ChatGPT
  │
  ├── Architecture
  ├── Specification
  ├── Review
  └── Coordination
  │
GitHub
  │
  ├── Spec
  ├── Architecture
  └── Tasks
  │
Codex
  │
  ├── Implementation
  └── Test

人間は「何を作りたいか」と重要な判断を担当する。

ChatGPTとは壁打ちしながらArchitectureとSpecを固める。

それをGitHubへSource of Truthとして残す。

CodexはそのRepositoryを読み、実装とTestを行う。

これによってChatの中だけで仕様が消えてしまう問題を避ける。

---

27. 5日しかないので最初から並列開発する

今回、実際に開発へ使える期間は一週間ではなく、実質約5日だった。

そこで最初から直列開発をやめた。

Taskを4 Laneに分割した。

Lane P
Shared Platform
Secretary / Registry / Logging / UI / Docker

Lane A
Daily Intelligence

Lane B
Research Copilot

Lane C
Virtual Trading Lab

A、B、Cは可能な限り互いの内部実装に依存しない。

共通ContractだけLane Pが提供する。

これにより、

        ┌─ Lane A ─┐
        │          │
Lane P ─┼─ Lane B ─┼─ Integration
        │          │
        └─ Lane C ─┘

という並列開発ができる。

「Platformが全部完成してからApplicationを作る」のではなく、Vertical Sliceを先に通す。

これは今回かなり重要な判断だった。

---

28. 当初の5日間Plan

計画は次のようにした。

Day 1はContract、Registry、Secretary、UI Skeletonと各Laneの入口。

Day 2はDaily Intelligenceを実データまで通し、ResearchとTradingを並列実装。

Day 3はResearch CopilotをE2Eまで通し、Tradingを進める。

Day 4は3 LaneをSecretaryへ接続し、ConversationとDocker Integrationを確認。

Day 5はE2Eを繰り返し、GUI、Obsidian、Audit、Paper Trading SafetyをHardeningする。

そして、もし時間が足りなくなったら、

Vertical Sliceを削るのではなく、Polishを削る。

というCut Lineを設定した。

---

29. 予想より速く進んだv0.1

実際にはCodexによる並列実装がかなり速く進んだ。

現在、Task Plan上ではShared Platform、Daily Intelligence、Research Copilot、Virtual Trading Labの主要Taskがすべて完了状態になっている。

Dailyでは実InsightForge CLIとArtifactを利用したSmoke Testが成功。

Researchでは実Weekly Artifactを読み、Candidateを選択してResearch Noteを生成。

TradingではDemo Weekly Strategyを作成・承認し、Paper FillとReport生成まで実施。

DockerについてもBuild、Startup、Container Health、Host Gateway Healthまで確認されている。

つまり、当初「5日間で到達したい」と考えていた基本Vertical Sliceは、かなり早い段階で形になった。

---

30. MiTiRで最終的に実現したいもの

MiTiRの最終目的はDashboardそのものではない。

Agent Treeを見ることでもない。

本当に作りたいUser Experienceはもっと単純である。

Mac miniが常時稼働している。

その中ではAgent、Service、Applicationが仕事をしている。

朝、人間がMiTiRへ話しかける。

「昨日から何かあった？」

Secretaryが答える。

AIニュースで重要な変化があった。

タービン研究では面白い論文が3本見つかった。

そのうち2本をResearch CopilotがRecommendedにしている。

昨日のVirtual Trading Labはプラスだった。

ただし一つの銘柄でRiskが上がっている。

今日確認した方がいいのはこの2件。

——それで十分なのである。

人間が100 Agentを見る必要はない。

100 Applicationを起動する必要もない。

100 Reportを読む必要もない。

AI組織が裏で仕事をして、人間はその組織のSecretaryと会話する。

これがMiTiRで実現したい世界である。

---

31. MiTiR-Baseの役割

その意味でMiTiR-Baseは、単なるApplication Frameworkではない。

これは、

Agent Organization + Application Registry + Execution Infrastructure + Knowledge + Human Interface

を束ねる基盤である。

そして重要なのは、MiTiR-Base自身が巨大化しすぎないこと。

優れたApplicationがすでに存在するなら再実装しない。

独立Applicationとして残し、InterfaceだけRegistryへ登録する。

必要になればCLIからHTTPへ変更する。

必要になればLocal ProcessからDockerへ変更する。

必要になれば別MacやCloudへ移動する。

しかしSecretaryやAgentから見たCapability Contractは維持する。

この疎結合性が、5年、10年と使えるSystemにするための重要な条件になると考えている。

---

おわりに

今回のMiTiR開発で最初に作ろうとしているのは、巨大な完成品ではない。

まずは、

Daily Intelligence

Research Copilot

Virtual Trading Lab

という性格のまったく違う3つの仕事を、本当にAI組織の下で動かす。

そしてSecretaryへ、

「今日どうだった？」

と聞けば、それらをまとめて答えてくれる。

そこまでをMiTiR v0.1の最初の到達点とした。正式Specでも、3 Domainを実際のApplication FlowまたはPaper/Sandbox Execution PathでEnd-to-Endに一度以上動かし、Secretaryの一つのConversation Surfaceから利用できることをDefinition of Doneとしている。

ここから先、AgentもApplicationも増えていくだろう。

しかし、そのたびに人間の管理負荷まで増えてしまったらAIを使う意味がない。

だからMiTiRでは逆を目指す。

AIが増えるほど、人間が見るものは少なくなる。

そのための土台が、今回開発を始めたMiTiR-Baseである。