開発は速くなった。システムの捉え方も、
変わるべきだ。

機能はどんどん速く完成するのに、プロジェクト全体はつかみにくくなっていく。

ひとつのプロジェクト、ふたつのペース概念図 · 実測データではありません
機能を実装するスピード
広がっていく
理解のギャップ
システム理解の積み重ね
開発開始何度もの反復のあと

Agent が実装を進めるあいだ、Living はシステムの現状、重要な変化、開発記録をひとつにまとめます。プロジェクトがいまどうなっているのか、なぜこうなったのか、まだ何に目を向けるべきかが見えてきます。

はじめる

公開 Beta 準備中 · Coming Soon

コードには実装が残る。では、設計の理由はどこに?

散らばった開発資料を、問いから答えまでたどれるプロジェクトの文脈へ。

整理前資料があちこちに散らばっている

  • Agent 会話
  • Commit 8f2…
  • 設計案
  • テスト結果
  • 構成の変更
  • 要件メモ
  • 議事録
  • TODO

記録 · 分類 ·
関連づけ

プロジェクトの文脈ひとつの問いをめぐる手がかり

なぜ独立した検索サービスに切り替えたのか?

  1. 01現在のシステム

    いまの方式と構成

    • アプリ
    • 検索サービス
    • データストア
  2. 02重要な変化

    何を、なぜ変えたのか

    1. 以前データベースを直接検索
    2. その後独立した検索サービスを導入

    変更の経緯をたどれる

  3. 03根拠と未確認事項

    議論、検証、今後の確認

    • 設計の議論
    • 検証記録
    • 未確認の問い

ドキュメントをもう一つ増やすのではなく、問いから引き出せる開発の文脈を。

概念図 · 記録された開発情報の整理のされ方を示しています

3 つの視点

システムを見通す。判断をたどる。
全体を見渡す。

01システムの可視化

システムを見通す

「Agent がたくさんのファイルを変更した。いま、システム全体はどうなっている?」

先へ進む前に、今回の変更がどのモジュールやデータに関わるのかを知る必要があります。コードを最初から読み直すのではなく。

Living ができること
要件、実装方式、データリソースの関係を一枚の図にし、機能からシステム構成へ入っていけるようにします。
期待できること
システムを理解する入り口が早く見つかり、主なコンポーネントと関係、深く調べるべき箇所がわかります。

関係図は判断のための文脈です。開発の成熟度を評価するものではありません。

概念図 · 架空の資料検索アプリ

今回変更されたファイル

  • web/search-page.tsx
  • api/routes/search.ts
  • api/import/worker.ts
  • jobs/queue.ts
  • search/indexer.ts
  • db/migrations/0007.sql
  • … 全 14 ファイル
要件方式データ
資料の取り込み資料の検索取り込み処理検索処理ジョブキューインデックスデータベース

02判断の集約

判断をたどる

「またアーキテクチャを見直す。前回はなぜいまの方式を選んだのか?」

当時の背景や制約は、セッション、実験記録、Commit、ドキュメントに散らばっていて、議論のたびに一から調べ直すことになりがちです。

Living ができること
記録された技術的な選択を、変更の履歴、根拠、検証結果、未解決の事項とあわせてまとめます。
期待できること
いまの方式を選んだ理由、検討された他の選択肢がわかり、以前の判断がいまも通用するかを確かめられます。

判断を下すのは常に開発者です。Living は、判断に必要な情報を見つけやすくするだけです。

概念図 · 「バックグラウンド処理をどう実行するか」の経緯
  1. 最初の方式リクエスト内で同期処理実装が簡単で、小さなファイル向き
  2. 見直した理由大きなファイルの取り込みがタイムアウト課題の記録と Agent セッション 1 件
  3. 現在の選択独立したジョブキュー取り込みをバックグラウンドで実行
  4. 関連する根拠
    • 設計の議論
    • 負荷テストの記録
    • 未確認:失敗時の再試行方針

もう一度見直す前に当時の制約は、いまも成り立っているか?

03プロジェクトの俯瞰

全体を見渡す

「機能が増えてきたけれど、テストや復旧、運用については話し合っただろうか?」

注意はどうしても目の前の機能に向かいます。テスト、セキュリティ、パフォーマンス、運用といったテーマを記憶だけで見守り続けるのは難しいものです。

Living ができること
プロジェクト全体から、記録のあるテーマ、確認が必要な判断、まだはっきりした資料が見つからないテーマを示します。
期待できること
議論や検証が必要なテーマに気づきやすくなり、次に何を調べるかを決めやすくなります。

現在の Beta資料のカバー状況と状態をまとめて表示。探索中記録と観察を自動で更新し続けること。

概念図 · 開発領域ごとの資料のカバー状況
  • 記録あり
  • 要確認
  • 記録なし
  • 要件記録あり要件メモと変更の説明
  • 設計記録あり設計メモとアーキテクチャ変更
  • データ要確認移行記録あり、内容は未確認
  • テスト記録あり検証の範囲と結果
  • 性能要確認負荷テスト 1 回、結論は未確定
  • 安全性記録なし資料にはまだ見当たらない
  • 運用記録なしバックアップと復旧の資料なし

「記録なし」は、資料の中にまだ見つからないという意味で、対応していないという意味ではありません。

3 つの視点がたどり着くところ

  1. システムを見通す
  2. 判断をたどる
  3. 全体を見渡す
  4. プロジェクトを再び掌握する

すぐに得られること

プロジェクトを理解しやすくなり、判断の根拠を見つけ直し、注意すべき問題に気づけます。

長い目で期待すること

情報の断絶や理解のやり直しを減らし、技術的な判断に一貫性を持たせ、プロジェクトをコントロールしやすくすること。

これは Living のプロダクト仮説で、まだ実験による検証はしていません。

Living はあなたの代わりに決めません。
判断に必要な視点を、あなたの手に渡します。

これらの視点は、すでに実際のワークスペースになりつつあります。

アーキテクチャは、
最終的な形だけではない。

これは現在の Living Beta にある、実際の画面のひとつです。システム構成を起点に、重要なアーキテクチャ上の選択、関連する設計上の制約、その根拠へとたどっていけます。

エンジニアリング成果システムアーキテクチャ設計

  • アーキテクチャ概要
  • コード構成と設計規約
  • API とインターフェース設計

観察範囲 固定ケース『水滸伝』の知識 Q&A プロジェクト現在の稼働状況は未確認最後に確実に観測した日 候補データ正式な Knowledge ではない

いまどうなっているかシステム構成

デプロイ先ホスト · Docker Compose

外部へ接続できるネットワーク

appアプリケーション

内部ネットワーク · 外部接続なし

searchOpenSearch
falkordbFalkorDB
tools必要時 · 初期化と確認

ホスト上のデータ · ネットワークサービスではない

beta.db利用枠とフィードバック
Dataset凍結データセット · オフライン

アーキテクチャ判断に関わる部分

なぜこうなったかアーキテクチャ判断

関連 searchfalkordbDataset

オンラインの知識を、なぜ SQLite から直接提供しなくなったのか?

  1. 以前の方式オンラインのアプリが知識用 SQLite を直接読み込む
  2. 見直した理由凍結データセットをオフラインの根拠に限定し、オンラインのアプリには知識ファイルをマウントしない
  3. 現在の選択オンラインの知識は OpenSearch と FalkorDB から提供利用枠とフィードバックは引き続き beta.db に保存
  • 関連する設計メモ設計上の制約と信頼の前提 5 件。たとえば、データベースには内部ネットワークからのみ到達できる
  • 実施と検証の記録実験環境で確認(10/24)· GraphRAG の事例で Beta 環境を切り替え(10/25)
  • 未確認事項2 つのデータベースのリリースは、まだ 1 回のアトミックな操作になっていない

提案採用は間接的な伝聞でしか確認できていないため、この判断はまだ正式な決定として記録されていません。

実際の Beta 画面の内容 · 固定ケースをもとに簡略化して再描画バージョン番号、外部サービス、ネットワークの細部の一部を省いています。図はリアルタイムの稼働状況を示しません。資料は候補データで、正式な Knowledge ではありません。

出典について
これらの資料はどこから来るのか?Living が Coding Agent とどう連携するかを見る

しくみ

いまの開発の流れに溶け込む。
置き換えるのではなく。

開発は、使い慣れた Coding Agent がこれまでどおり行います。Living は、長く残す価値のある開発情報だけを、ひとつの明確な経路で蓄積していきます。

図はローカル Beta の stdio アダプター構成です。「はじめる」で案内しているリモート HTTP MCP 接続は一般公開に向けて準備中です。

Aあなたのプロジェクト

Living Skillsどの情報を残すべきか、どう記録と知識にまとめるかを定める
公開済み
Coding AgentClaude Code や Codex がいつもどおり開発を進める
.living/ ローカルの開発記録記録、知識オブジェクト、同期の状態はプロジェクト内に残る

BMCP 連携レイヤー

MCP Adapter
  • コンテキストの取得
  • Knowledge と契約の読み込み
  • 構造化された記録の検証
  • 明示的な同期の送信
  • 同期結果の返却
公開予定

Agent とは:stdio
Backend とは:HTTP Agent API
自身はデータを保存しない

CLiving コアプロダクトの中核

Living Backend
  • データ契約の検証
  • 構造化された同期とバージョン履歴
  • 開発資料の関連づけと投影
  • 根拠と出典の追跡
Living Webシステムと機能 · エンジニアリング成果 · 変遷

エンジニアリングインデックスは現在、同期とは別に準備・導入しています。

  1. 1Agent が Skills に沿って開発情報を整理し、プロジェクト内の .living/ に書き込みます。
  2. 2あなたが明示的に同期を依頼すると、Agent は MCP を通じてまず検証し、それから送信します。
  3. 3Backend がまとめて検証して一括で書き込み、受領記録をプロジェクトに返します。
  4. 4Living は同期された資料を、可視化され、たどることのできる開発の視点に整理します。

同期はあなたが依頼したときだけAgent のセッションを自動収集しないMCP はデータを保存しないLiving Web はプロジェクトのフォルダを読み書きしない

なぜ MCP でつなぐのか

  1. いまの Coding Agent を置き換えない

    Living はもう一つの Agent を作りません。対応するツールインターフェースを持つクライアントであれば、Living の開発コンテキストを読み、同期を送信できます。現在は Claude Code と Codex 向けの対応を実装済みで、その他のクライアントは未検証です。

  2. 開発と知識の管理を分ける

    開発は使い慣れたツールで続け、送信された構造化された開発情報の保存と整理は Living が担います。一回一回の開発が、プロジェクトの長期的な理解の一部になります。

  3. インターフェースとデータの境界が明確

    MCP Adapter は Living のデータベースを直接操作せず、検証と書き込みはすべて Backend が行います。Agent がプロジェクトのファイルに対して行う操作が、Living の正式なデータを直接変えることはありません。

現在のバージョン · Beta 0.3

開発を見ることから、
見守り続けることへ。

Living は現在、作者のローカル環境で動くシングルユーザーの Beta です。一般向けのインストールはまだ提供しておらず、登録や試用の手続きもありません。

いまできること現在の Beta の機能

  • システムと機能の可視化要件、方式、データリソースの関係と、それぞれの背後にある記録。
  • エンジニアリング成果と資料のカバー状況各開発領域にどんな資料があるか。システムアーキテクチャ、コード構成、API の概要。
  • プロジェクトの変遷と出典の追跡プロジェクトの段階と重要な変化。資料は元の記録までたどれます。

連携の部分は開き、
プロダクトの中核は進化させ続ける。

公開済み
Living Skills のソースファイル。バージョンごとに固定。公開されていて読めますが、オープンソースライセンスはまだ付けていません。
公開予定
ローカルの MCP Adapter、コマンドラインツール、導入例、インターフェース契約。ライセンスと時期は未定です。
プロダクトの中核
Backend、Web の可視化、開発の分析。クローズドソースのまま、独自に進化させます。
連携の流れを知りたい方は「はじめる」へ

コードは前へ進める。理解はプロジェクトに残す。

Living Engineering Workspace

ローカル・シングルユーザー Beta · 初期の探索段階