724 Office徹底解説：フレームワーク不要・36ツール搭載の自己進化型AIエージェント

ExcelマクロやVBAで業務を自動化してきたエンジニアにとって、「もっと柔軟に、もっとインテリジェントに」という要求は常に存在する。724 Officeは、LangChainやCrewAIといったフレームワークを一切使わず、約10,000行の純粋Pythonコードで36のツールを搭載した自己進化型AIエージェントだ。GitHub上でスター1,000超を獲得し、実際に24時間365日の本番環境で複数ユーザーに利用されている。

本記事では、724 Officeの設計思想、アーキテクチャ、36ツールの全容、MCP連携、そして運用機能まで、コードレベルの具体性を保ちながら公式READMEと設定例に基づき整理する。業務自動化基盤を自前で組む際の設計参考として活用してほしい。

「フレームワークのブラックボックスに頼らず、すべてのコードを自分で読める粒度に保つ」——これが724 Officeの出発点であり、エッジデプロイ・マルチテナント・自己修復を同居させる現実解にもなっている。

この記事ではAIエージェントに特化して解説します。AIエージェント全般は AIエージェントフレームワーク比較2026年版 をご覧ください。

724 Officeとは何か：設計思想の7原則

724 Officeが最も特徴的なのは、LangChain・LlamaIndex・CrewAIといった主要フレームワークを一切使わない設計判断だ。公式READMEでは以下の7つの設計原則が明示されている。

1. Zero framework dependency — すべてのコードが可視的でデバッグ可能。隠れた抽象化なし
2. Modular tools — @toolデコレータを付けた関数を追加するだけで機能拡張
3. Edge-deployable — Jetson Orin Nano（8GB RAM, ARM64）でも動作する省メモリ設計
4. Self-evolving — エージェント自身がランタイムで新しいツールを生成・診断・通知
5. Structural behavior correction — プロンプト修正ではなくNudge・フック・バリデーションで行動を矯正
6. Build for deletion — モデルが賢くなれば不要になるモジュールをクリーンに削除可能
7. Context is the scarcest resource — トークン予算を最重要の設計制約として扱う

特に7番目の「コンテキストは最も希少な資源」という発想は、現行のエージェント設計における最も示唆的な原則と言える。OpenHandsのようなAIコーディングエージェントがソフトウェア開発に特化しているのに対し、724 Officeはメッセージング連携・スケジューリング・マルチモーダル処理など、より幅広い業務自動化をカバーする汎用エージェント基盤として位置づけられる。

クイックスタート：直接実行とDocker推奨環境

724 Officeのセットアップは、軽量な依存のみでローカル実行でき、本番はDockerを推奨している。

直接実行の場合

git clone https://github.com/wangziqi06/724-office.git
cd 724-office
cp config.example.json config.json
# config.json にAPIキーを設定

pip install croniter lancedb websocket-client pilk \
            numpy httpx beautifulsoup4 pydub jieba fpdf2

mkdir -p workspace/memory workspace/files
python3 xiaowang.py

Docker推奨環境

# Dockerfile.example -> Dockerfile にコピー
# docker-compose.example.yml -> docker-compose.yml にコピー
# .env に認証情報を設定

docker compose build
docker compose up -d

起動後、ポート8080でHTTPサーバーが立ち上がる。メッセージングプラットフォームのWebhookを http://YOUR_SERVER:8080/ に向ければ接続完了だ。

config.example.json にはLLMプロバイダ（OpenAI互換API）、メッセージング認証情報、メモリ設定、ASR設定、MCPサーバー接続などの全設定項目がまとめられている。

フレームワーク依存がないことで、pipインストールで手こずる場面が極めて少ない。これはエッジ運用で効いてくるポイントだ。

アーキテクチャ全体像：モジュール構成と処理フロー

724 Officeのv2.0ではモノリシックな tools.py を7つのドメインモジュールに分割している。全体のコード構成は以下のとおりだ。

処理の流れを図にすると以下のようになる。

中心にいるのは llm.py のツール使用ループだ。ここで予算管理・Nudge・動的フィルタリングがひとまとまりで回り、各ドメインモジュールをツールとして呼び出す。モジュールはいずれも単一責任で、依存の向きが一方向に揃えられている。

三層メモリシステム：短期・圧縮・ベクトル検索

724 Officeの中核機能の一つが三層構造のメモリシステムだ。LangChainのMemoryモジュールがフレームワーク内での会話履歴管理を提供するのに対し、724 Officeは独自実装でより細やかな制御を実現している。

Layer 1: セッションメモリ（短期）

• セッションごとに直近40メッセージをJSON形式で保持
• オーバーフロー時に自動圧縮をトリガー
• 100KBを超えるセッションは自動アーカイブ

Layer 2: 圧縮メモリ（長期）

• 退出したメッセージからLLMが構造化された事実を抽出
• コサイン類似度（閾値0.92）による重複排除
• LanceDBにベクトルとして保存

Layer 3: 検索メモリ（能動的想起）

• ユーザーメッセージをEmbedding化してベクトル検索
• Top-Kの関連記憶をシステムプロンプトに注入
• トークン予算を追跡しながら注入量を調整

設定は config.example.json の memory セクションで管理する。

{
  "memory": {
    "embedding_api": "https://api.openai.com/v1/embeddings",
    "embedding_model": "text-embedding-3-small",
    "similarity_threshold": 0.92,
    "max_session_messages": 40,
    "archive_threshold_kb": 100
  }
}

この三層構造により、短期的な会話の文脈を維持しつつ、過去の重要な情報を効率的に想起できる。特にLayer 3の予算管理機能は、トークンコストを意識した設計として注目に値する。

圧縮時にコサイン類似度0.92で重複を切り落とすため、同じ趣旨の事実がベクトルDBに蓄積して肥大化する問題を抑えられる。

36ツールの全容：カテゴリ別整理と動的フィルタリング

724 Officeが搭載する36のビルトインツールは7つのカテゴリに分類される。

特筆すべきはv2.0で追加された動的ツールフィルタリング機能だ。5つのコンテキストプロファイル（voice / scheduler / group / diagnostic / default）を状況に応じて切り替え、不要なツール定義をLLMに渡さないことでトークン消費を削減する。さらにサーキットブレーカーが実装されており、1セッション内で3回連続失敗したツールは自動的に無効化される。

ツール登録は @tool デコレータで完結する。以下は実装例のイメージだ。

from tools_base import tool

@tool(
    name="send_reminder",
    description="ユーザーに予定のリマインダーを送る",
    profile=["scheduler", "default"]
)
def send_reminder(user_id: str, message: str, at: str) -> dict:
    """指定時刻にリマインドメッセージを送信する"""
    # messaging API 呼び出し
    return {"status": "ok", "scheduled_at": at}

デコレータがレジストリへの登録・プロファイル割り当て・JSON Schema生成までを引き受ける。プラグインAPI経由でランタイムに登録したツールも同じ経路に乗る。

36ツールという数字はスペック自慢ではなく、「メッセージング領域で本当に必要になる操作」を積み上げた結果である点に注目したい。

v2.0の注目新機能：Nudge・AI Mirror・グループチャット

Nudgeシステム（行動矯正）

v2.0で導入されたNudgeシステムは、LLMがツールを持っているのに使わない場面を自動検出し、ヒントを注入する仕組みだ。これは「プロンプトで行動を修正するのではなく、構造的に矯正する」という設計原則の具体的な実装である。

# nudge.py のイメージ実装
def detect_nudge(user_msg: str, tool_history: list) -> str | None:
    if "画像" in user_msg and "send_image" not in recent_tools(tool_history):
        return "画像の送付が求められているようです。send_image を検討してください。"
    if "毎朝" in user_msg and "schedule" not in recent_tools(tool_history):
        return "繰り返し実行が求められているようです。schedule を使って登録できます。"
    return None

Nudgeはシステムプロンプトを書き換えるのではなく、ツール呼び出しループの前段でヒントとして注入されるため、モデルごとに振る舞いが安定しやすい。

AI Mirror

soul_report ツールは会話履歴から行動プロファイルをHTMLレポートとして生成する。future_self は未来の自分との対話モードを提供し、自己認識をエージェントレベルで実現する実験的機能だ。

グループチャット対応

独立コンテナでグループ会話を管理し、@メンション検出で発言をゲーティングする。直近20メッセージのコンテキストバッファと発言者識別機能を備える。

これらの機能はMCPプロトコルとも組み合わせ可能だ。ForgeCodeのようなAIコーディングツールをMCPサーバーとして接続すれば、724 Officeからコード生成タスクを委任するワークフローも構築できる。

類似ツールとの比較：何が違うのか

AIエージェントフレームワークは多数存在するが、724 Officeの立ち位置を整理しよう。

724 Officeの最大の差別化要因は、フレームワーク依存ゼロでありながら本番運用に必要な機能（マルチテナント、自己修復、スケジューリング）を一体提供している点だ。Browser Useのようなブラウザ自動化エージェントがWeb操作に特化しているのと同様に、724 Officeはメッセージングプラットフォームとの統合に強みを持つ。

選び方の指針

「どのエージェントを選ぶか」ではなく「どのレイヤで何を自前にするか」を決めるための比較として使うとよい。

MCP連携とプラグイン拡張：自己進化の仕組み

724 OfficeはMCP（Model Context Protocol）をネイティブサポートしている。mcp_client.py（約342行）がJSON-RPCプロトコルを実装し、stdioとHTTPの両方のトランスポートに対応する。

{
  "mcp_servers": [
    {
      "name": "my-tool-server",
      "transport": "stdio",
      "command": "python3",
      "args": ["mcp_server.py"]
    },
    {
      "name": "remote-server",
      "transport": "http",
      "url": "http://localhost:3000/mcp"
    }
  ]
}

MCPサーバーの追加は設定ファイルを編集して reload_mcp ツールを呼ぶだけで、再起動不要のホットリロードが可能だ。さらに create_tool によるランタイムツール生成では、エージェント自身がPython関数を書いて @tool デコレータ付きで保存・読み込みできる。

# create_tool が生成するコードの骨格
from tools_base import tool

@tool(
    name="fetch_weather",
    description="指定都市の天気を返す"
)
def fetch_weather(city: str) -> dict:
    # httpx で外部APIを呼び出す
    ...

生成されたツールは workspace/custom_tools/ に書き出され、再起動なしでレジストリへ読み込まれる。これは単なるプラグインシステムを超えた「自己進化」の仕組みであり、724 Officeの名前の由来（24時間365日＝7/24稼働）に直結する設計だ。

運用面の堅牢性：自己修復とモニタリング

本番環境での24/7稼働を支える運用機能も充実している。

• 日次自己チェック（self_check）: エラーログ分析、セッションヘルス診断、障害時の自動通知
• コード監査（code_audit）: 11項目の自動チェック
• セッション自動アーカイブ（archive.py）: 日次でブラックボックス記録を保存
• コンテナ再構築（router.py）: 起動時にルーティングテーブルから欠落コンテナを自動再構築
• 指数バックオフリトライ: メッセージングAPI呼び出しは2/4/8秒間隔で3回リトライ
• 非アクティブガード: 3日間操作がないユーザーのCronタスクを自動スキップ

実装イメージとして、指数バックオフリトライは以下のような典型構造を取る。

import time, httpx

def send_with_retry(url: str, payload: dict, attempts: int = 3) -> httpx.Response:
    delay = 2
    for i in range(attempts):
        try:
            return httpx.post(url, json=payload, timeout=10)
        except httpx.HTTPError:
            if i == attempts - 1:
                raise
            time.sleep(delay)
            delay *= 2

このレベルの自己修復機能を持つオープンソースAIエージェントは珍しく、ソロ開発者がAI共開発ツールを活用して構築した点でも注目に値する。

24/7運用で効いてくるのは派手な機能ではなく、失敗時に自動で姿勢を立て直すこうした小さな仕組みの積み重ねだ。

向いているケースと採用判断のポイント

724 Officeは、フレームワークのブラックボックスに依存せず、すべてのコードを自分で理解・制御したいエンジニアに適している。特に以下のようなユースケースで力を発揮する。

• メッセージングプラットフォーム（WeChat Work等）と連携した業務自動化
• エッジデバイス（Jetson Orin Nano等）での省メモリAIエージェント運用
• MCPプロトコルを活用した外部ツール統合
• 24/7稼働が必要な本番AIアシスタントの構築

MIT Licenseで公開されており、コードの可読性も高いため、独自のAIエージェントシステムを構築する際のリファレンス実装としても価値がある。

「フレームワークを使わない」はコスト高に見えて、長期的にはコードオーナーシップとデバッグ容易性で回収できる。724 Officeはその賭けの一つの答えだ。

📌 まとめ

724 Officeは、LangChainやCrewAIといった主要フレームワークに依存せず、約10,000行の純粋Pythonで36ツール・三層メモリ・MCP連携・マルチテナント・自己修復を一体化した自己進化型AIエージェントだ。設計原則の中心には「コンテキストは最も希少な資源」という明確な哲学があり、動的ツールフィルタリング、Nudge、圧縮メモリの類似度閾値といった実装に一貫して反映されている。

• フレームワーク依存ゼロで全コードが可視化されデバッグ容易
• 三層メモリ（セッション・圧縮・ベクトル）でトークン予算を守りながら文脈を維持
• 36ツール＋MCP＋ランタイム生成で拡張性と自己進化を両立
• Docker自動プロビジョニングと日次自己チェックで24/7運用を現実的に
• エッジ（Jetson Orin Nano）対応で省メモリ要件にも適合

独自のAIエージェント基盤を自前で設計・運用したい開発者にとって、724 Officeは設計判断の宝庫であり、コードを読むだけでも得るものが多いプロジェクトだ。

参照ソース

• 724 Office GitHubリポジトリ — 公式ソースコード・README・設定例
• Model Context Protocol (MCP) 仕様 — 724 Officeが実装するMCPプロトコルの公式仕様
• LanceDB 公式ドキュメント — 三層メモリのベクトル検索で使用されるデータベース
• NVIDIA Jetson Orin Nano 製品ページ — エッジ実行対象として想定されているハードウェア