Architecture Intelligence Platform

アーキテクチャインテリジェンスプラットフォーム

エージェントはアーキテクチャを再構築するのではなく、推論すべきです。

AIP は、コーディングエージェントに証拠に基づくアーキテクチャコンテキストを提供します。

宣言された API コントラクトと実行時に観測された動作を照合し、エージェントが次の項目を区別できるようにします。

• 宣言され、観測された依存関係
• 本番環境で確認されたものの、どこにも文書化されていない依存関係
• 選択された実行時の期間中に観測されなかった、宣言済みの関係
• AIP が安全に確立できない事実

すべての回答はスナップショットに紐付けられ、証拠まで追跡できます。エージェント向けツールは読み取り専用です。 4 つの実際のコーディングエージェントクライアントを、v0.4.2 に対してエンドツーエンドで検証しました。詳細は v0.4.2 互換性マトリックスをご覧ください。この 検証はその後、再実施されていません。

5 分間のデモを実行 · 実践的なデモ：Quarkus Super Heroes · MCP ツール · 仕組み

MCP レジストリ： io.github.michaelegner/architecture-intelligence-platform

LegacyPricingService は一度も宣言されていません。AIP は実行時にこの依存関係を OBSERVED_ONLY として観測し、その主張を裏付ける OpenTelemetry の証拠まで追跡します。

コーディングエージェント向けの、証拠に基づくアーキテクチャコンテキストの提供を解決したい課題だとお考えなら、AIP に ⭐ を付けてください。

動画による解説 · 評価 · 境界 · ドキュメント · 研究の動向

5 分で試す

Docker（Compose を含む）、curl、jq が必要です。LLM API キーは不要です。この手順ではモデルを呼び出しません。

git clone https://github.com/michaelegner/architecture-intelligence-platform.git
cd architecture-intelligence-platform
cp .env.example .env
examples/runtime-demo/mcp-demo.sh

このスクリプトは AIP、Neo4j、OTel Collector を起動し、同梱のアーキテクチャ例をインポートして、タイムスタンプを固定したランタイムテレメトリのバッチを 1 つシードします。その後、通常の HTTP/JSON-RPC を介して tools/list → get_architecture_drift → get_evidence を実行します。これは、互換性のある MCP クライアントが使用するものと同じリクエスト経路です。

order-service について get_architecture_drift を呼び出すと、次の 2 つの検出結果が返されます。

ProductService と PaymentService（payment-q 経由）は CONFIRMED です。宣言されており、かつ観測されているため、正しく結果には表示されません。ドリフトが返すのは不一致であり、一致ではありません。4 つすべてを一覧表示するツールは get_service_dependencies です。回答にはこの 2 つの主張に加えて、AIP が unused-q のコンシューマーを証拠なしに特定することを避けたことを示す limitations エントリも含まれます。各主張の evidence_refs を get_evidence で参照すると、同じ snapshot_id において、一方を宣言した asyncapi.yaml と、もう一方を観測した OpenTelemetry の期間が取得されます。

{
  "snapshot_id": "aip:snapshot:v1:685a34157b6842b00d7130b8490df63060c3d80871c2ed6f56cd9206e62342d8",
  "outcome": "PARTIAL",
  "limitations": [
    {
      "code": "UNRESOLVED_IDENTITY",
      "message": "queue:unused-q has no single evidenced consumer service; retained as the direct queue target rather than guessed.",
      "claim_ids": ["aip:claim:v1:ca0dd73ba391552edd6d2cc06cddd919a8af97f362cdb47392e78325219fd612"]
    }
  ],
  "claims": [
    {
      "dependency": "unused-q",
      "via": "unused-q",
      "qualification": "NOT_OBSERVED_IN_WINDOW",
      "evidence_refs": ["evidence:asyncapi:order-service"]
    },
    {
      "dependency": "LegacyPricingService",
      "via": "GET /pricing/{sku}",
      "qualification": "OBSERVED_ONLY",
      "evidence_refs": ["evidence:otel:demo:2026-08-26:bfae54276215"]
    }
  ]
}

[
  {
    "id": "evidence:asyncapi:order-service",
    "evidence_type": "DECLARED",
    "source_type": "ASYNCAPI",
    "source_locator": "examples/order-service/asyncapi.yaml"
  },
  {
    "id": "evidence:otel:demo:2026-08-26:bfae54276215",
    "evidence_type": "OBSERVED",
    "source_type": "OPENTELEMETRY",
    "source_locator": "opentelemetry"
  }
]

シードされたすべてのスパンは時刻から算出されるのではなく固定されているため、クリーンな状態から 2 回実行すると、同じ判定と同じ snapshot_id が得られます。examples/runtime-demo/mcp-demo.sh --down を実行すると、環境を停止できます。手順を追った説明については、各 curl の内容と回答の意味を示す examples/runtime-demo/hero-demo.md をご覧ください。

Quarkus Super Heroes：変更前に fight サービスを理解する

5 分のデモでは、小規模な合成システムを使用します。こちらでは、AIP の v0.5.0 実システム適格性評価で使用された、実際の複数サービスシステムである Quarkus Super Heroes を使用します。タスクは「rest-fights の画像ナレーションを変更する前に、何を知っておく必要があるか？」です。1 つのコマンドで、すでに適格性評価済みの証拠を再生できます。必要なのは Docker と curl だけです。Quarkus のビルド、Kafka、クラスター、モデルキーは不要です。

examples/quarkus-super-heroes-demo/run.sh

rest-fights の回答には、操作レベルの CALLS が 7 件表示されます。ランタイムで CONFIRMED されたものが 3 件、NOT_OBSERVED_IN_WINDOW が 4 件です。また、設定済みのマッピングを通じて解決された DEPLOYED_AS も表示されます。さらに、オペレーターが作成したことが明示された AsyncAPI オーバーレイで宣言されている、fights トピックへの PUBLISHES_TO も表示されます。そのコンシューマーは推測されず、明示的に UNRESOLVED_IDENTITY のままです。AIP がまだ回答できない gRPC 呼び出しは隠されず、回答の対象外としてラベル付けされています。

デモの README · 質問ごとのウォークスルー · 依存関係が確立される場所 · 記録された Claude Code の会話

Pitstop：これから変更するイベントを受信するサービスはどれですか？

ローカルで試す → · 公開ホストインスタンスでは現在、Sokol111 データセットを提供しています：ホスト環境で試す →

もう1つの実システム、Pitstop（RabbitMQ を使用する .NET のガレージ管理サンプル）を、別のブローカーと技術スタックで扱います。タスクは次のとおりです。MaintenanceJobFinished の StartTime と EndTime を置き換える前に、公開先のエクスチェンジから受信するのは誰で、まだ何を調べる必要がありますか？ 作成済みの固定された観測期間を1つのコマンドで再生します。必要なのは Docker と curl だけです。.NET、RabbitMQ、モデルキーは不要です。

examples/pitstop-demo/run.sh

パブリッシャーに尋ねてください。AIP はファンアウトエクスチェンジの5つの受信者を、それぞれの名前付きキューを通じて特定します。そのうちの1つ（ReportingService）は、どの Pitstop ドキュメントにも記載されていません。AIP は根拠とパブリッシャーによる限定条件も示します。また、ペイロードやフィールドレベルの知識がないことを隠さず明示するため、StartTime を読み取る受信者は自分で調べる必要があります。再現可能なモードはローカル再生です。v0.7.2 I2 までは、継続稼働する計装済みの Pitstop も公開ホストの AIP インスタンスにデータを提供していましたが、現在、そのインスタンスでは固定された Sokol111 Kafka データセットを提供しています（ローカルの --live モードには、非公開の計装済みフォークが必要です）。オプションの Claude Code プラグイン（および AIP の回答をエージェントの計画の隣に表示するオプションの mod）については、デモの README で説明しています。どちらも、このリポジトリの Claude Code マーケットプレイスからインストールできます（claude plugin marketplace add michaelegner/architecture-intelligence-platform）。

デモの README · 質問ごとの手順 · 入力データの出所

できること

誰も記録していない依存関係を見つける。 実際のトラフィックから、仕様書、マニフェスト、図のいずれにも存在しない呼び出しが明らかになります。AIP は、上記のデモにある OrderService -> LegacyPricingService のような依存関係を、観測期間とともに OBSERVED_ONLY として表示します。

宣言したアーキテクチャが実際に稼働しているものと一致するか確認する。 依存関係ごとに、両方向の乖離が報告されます。宣言されているものの観測されていない依存関係と、観測されているものの一度も宣言されていない依存関係のそれぞれについて、断定ではなく根拠に基づいて示します。

コーディングエージェントに引用可能なコンテキストを提供する。 6つの読み取り専用 MCP ツールが、直接の依存関係、乖離、出所、呼び出し元のローカリティ、API コンシューマーの使用状況、Kafka Topic のコンシューマーをエージェントに提供します。これらはそれぞれ1つのグラフスナップショットに紐付いているため、エージェントは事実と推測を区別でき、読み取り元のモデルに書き込むこともありません。

AIP をコーディングエージェントに接続する

スクリプト化された MCP 呼び出しを自分で実行せずに、再現可能なデモを準備します。

examples/runtime-demo/mcp-demo.sh --serve

AIP は http://localhost:8000/mcp で利用できるようになりました。以下の例を使ってコーディングエージェントのクライアントを設定してください。設定構文は、各クライアントの最新の公式ドキュメントに照らして検証済みです。

認定済みのクライアントとプラットフォームの組み合わせは、 v0.4.2 互換性マトリックスに記載されています。これらは v0.4.2 に対して認定されており、それ以降は再認定されていません。記載のない組み合わせは、 検証されていません。

Codex CLI

codex mcp add aip --url http://localhost:8000/mcp

Claude Code

claude mcp add --transport http --scope local aip http://localhost:8000/mcp

{ "mcpServers": { "aip": { "url": "http://localhost:8000/mcp" } } }

{ "servers": { "aip": { "type": "http", "url": "http://localhost:8000/mcp" } } }

次のように質問します。

AIP を使って、デモ環境の service:order-service について、2026-08-26T00:00:00Z から 2026-08-27T00:00:00Z までの期間におけるアーキテクチャのドリフトを調べてください。各検出結果について、 判定の根拠を説明し、同じスナップショットを使ってエビデンスを解決してください。AIP が立証していない事実を推測しないでください。

AIP の想定される検出結果：

• LegacyPricingService — OBSERVED_ONLY（実行時に観測されたが、宣言されたことはない）
• unused-q — NOT_OBSERVED_IN_WINDOW（宣言されているが、この期間には確認されなかった。「未使用」や「デッド」とは表現しない）

Codex CLI が実際にこれを実行している様子です。

この手順は、ローカルで実行中のクライアントを対象としています。ホスト型／クラウド型エージェントは、通常 localhost に接続できません。/mcp にはパブリックインターネット向けの認証機能がありません。ローカルまたは信頼できるネットワーク内でのみ使用してください。この経路では AIP 自体に LLM API キーは不要ですが、クライアント側では独自のキーが必要な場合があります。

クライアントごとの詳しい設定、検証ソース、クリーンアップ手順 →

なぜ必要なのか？

サービスを変更するエージェントは、そのサービスが実際に何と通信しているかを知る必要があります。現在、その情報は問題のある 2 つの情報源から得られることがよくあります。実態から乖離している可能性のあるアーキテクチャ文書と、コンテキストウィンドウに収まったコードから導かれた、もっともらしい推測です。どちらも同じくらい確信ありげに見えますが、どちらからも事実と推測を区別できません。

AIP は、すでに存在し、通常の開発の一環としてすでに管理されているエビデンスをもとに、この問いに答えます。OpenAPI／AsyncAPI の仕様、表現できない唯一の情報（誰が何を呼び出すか）を示す最小限のマニフェスト、そして任意の実際の OpenTelemetry トラフィックです。依存関係やドリフトに関する回答では、各主張を裏付けるエビデンス、実行時の観測結果が宣言内容と一致するかどうか、そして AIP が立証できなかったことが明示されます。観測されなかった依存関係は、「存在しない」とはせず「未観測」として報告され、特定できない ID が推測されることもありません。エビデンスの詳細表示では、同じスナップショットに基づいてエビデンスへの参照を解決し、新たなアーキテクチャ上の主張を生み出すことはありません。

AIP はエージェントのアーキテクチャに関する推論を支援できますが、エージェントがアーキテクチャ上の真実の情報源になってはなりません。— ROADMAP.md の v0.4 の原則

MCP ツール

AIP は、標準のネゴシエーション方式による MCP クライアント初期化（境界を参照）を通じて、検証済みのアーキテクチャモデルを /mcp で公開し、次の 読み取り専用 ツールをちょうど 6 つ提供します。

6 つのツールはいずれもグラフへの書き込みを一切行わず、LLM API キーも不要です。提供する機能はすべて決定的です。また、未解決の事実を捏造、推測したり、確定した事実に格上げしたりすることはありません。証拠が不十分な場合は、何も返さずに済ませるのではなく、limitations の項目として返します。

各回答に含まれる内容、その適用範囲、そしてこの機能が意図的に行わないことについては、以下の境界を参照してください。正確な JSON-RPC 呼び出し形式を含む完全なリファレンスは、docs/mcp.mdを参照してください。

クイックスタート

デモだけでなく、プラットフォーム全体（REST API、Service Explorer、MCP エンドポイント）を実行するには：

cp .env.example .env
docker compose up

.env.example の NEO4J_PASSWORD はローカル限定の固定デフォルト値（change-me-local）です。試用には問題ありませんが、ご利用のマシンの外部からアクセスできる環境では絶対に使用しないでください。

次に http://localhost:8000 を開きます。config.yaml はすでにこのリポジトリの examples/ フィクスチャサービスを参照するよう設定されているため、すぐにそれらに対して POST /api/import を実行できます。Docker を使わずにローカルで実行する方法、テストスイート、リンティングについては、docs/development.mdを参照してください。

AIP の仕組み

証拠を入力し、条件を明示したアーキテクチャの事実を出力します。

OpenAPI · AsyncAPI · architecture.yaml   (declared)
OpenTelemetry traces                     (observed)
        -> canonical model -> evidence-backed graph -> qualified claims -> MCP tools / REST / UI

手作業で保守するアーキテクチャ文書は、システムとの整合性を強制するものがないため、実態と乖離します。AIP は、根拠となる証拠なしにアーキテクチャ上の事実を保存することはありません。そのため、宣言されたシグナルと観測されたシグナルは、区別のないひとつの「真実」にまとめられることなく、別々に扱われます。

宣言済みと観測済み

グラフ内のすべての関係には証拠が付随し、その証拠は DECLARED（仕様／マニフェスト由来）、OBSERVED（実際のテレメトリー由来）、またはその両方です。それに基づいてステータスが決まります。

古くなった宣言を削除しても、観測済みの証拠が残っている関係は削除されません。代わりに CONFIRMED から OBSERVED_ONLY に変わります。この仕組みが保証する正確な不変条件とその重要性については、docs/graph-model.mdを参照してください。上記の依存関係 MCP ツールとドリフト MCP ツールは、これらの条件をそのまま返します。返却時に事実を格上げしたり、曖昧にしたりすることはありません。

取り込み

モジュール式の Python モノリス（単一の FastAPI プロセス）で、外部の永続化依存関係は Neo4j のみです。取り込みは厳密に段階化されたパイプライン（scan -> parse -> source-validate -> map to canonical model -> canonical-validate -> reconcile/diff -> transactional graph write）で行われます。サービスのインポートは完全に成功するか、全体が破棄されるかのいずれかであり、中途半端な状態が残ることはありません。ソースアダプターが Neo4j に直接書き込むことはなく、すべて共通の Canonical Model にマッピングしてから処理します。グラフ／エビデンスモデルやすべての API ルートを含む詳細については、docs/architecture.md を参照してください。

決定論的な分析

宣言されたアーキテクチャを対象とする、パラメーター化された固定の Cypher 分析が 5 つあります（キューの送信元／コンシューマー、孤立キュー、混在アーキテクチャの影響範囲）。さらに、宣言データと観測されたランタイムデータを対象とする分析が 5 つあります（実際に観測されたもの、確認済みのもの、観測のみのもの、宣言のみのもの、サービスごとのテレメトリーカバレッジ）。これらに LLM は一切関与しません。分析の一覧と各分析が答える内容については、docs/analyses.md を参照してください。

主な機能

• 6 つの読み取り専用 MCP ツールによる、エビデンスに基づくサービス依存関係とアーキテクチャの乖離
• OpenAPI、AsyncAPI、OpenTelemetry のエビデンスを 1 つのグラフに統合
• キューと、ソースに依存しない Pub/Sub のセマンティクス。トピックのファンアウトは明示的に宣言された Subscription のみで表現され、Kafka のコンシューマーグループが Subscription として扱われることはありません。
• スナップショットに紐づく来歴。すべての主張は、それを生成した仕様ファイル、マニフェスト、または観測ウィンドウまでたどれます。
• バッチをまたいだ OTel の相関付けを含む、宣言データと観測データの決定論的な照合
• エビデンスの欠落や未解決の識別情報を保守的に処理。推測や暗黙の破棄は行いません。
• オプションの Service Explorer UI を備えた、Neo4j ベースのアーキテクチャモデル

アーキテクチャと機能のドキュメントを見る → · 相関モード →

例

同梱の examples/ フィクスチャは、4 つのサービスから成る小規模な完全合成のシステムです。

コンシューマーのいない送信元である unused-q と、既知の送信元のないコンシューマーである unknown-producer-q は、孤立キューの分析を実行するために含まれています。POST /api/import を 1 回呼び出すと、すべてが読み込まれます。

評価

AIP は、AIP 自身の出力から生成された期待値ではなく、独立して作成された正解データに対して評価され、決定論的な PASS/FAIL で判定されます。

• 宣言／観測された関係の事実に関する、決定論的なシナリオ 10 件
• 3 つすべての MCP ツールにまたがる ArchitectureAnswer シナリオ 23 件
• ArchitectureAnswer をクリーンな状態で 2 回実行した結果は意味的に同一です。ヒーローデモの structuredContent は、クリーンな状態で繰り返し実行してもバイト単位で同一です。
• Quarkus Super Heroes および Apache Airflow に対する実システムの検証

uv run python -m evaluation run       # ten relation-fact scenarios
uv run python -m evaluation answers   # 23 ArchitectureAnswer scenarios

LLM プロバイダーのキーは不要です。どちらのテストスイートも自然言語クエリレイヤーには触れません。シナリオ一覧、正解データの形式、失敗レポートの例については、evaluation/README.md を参照してください。

実システムでのテスト

AIP のモデルは、設計対象ではなかった Quarkus Super Heroes と Apache Airflow の 2 つのシステムでも検証されました。重要なのは、AIP が「すべてを発見した」ことではありません。未対応のケースや解決できなかったケースが、もっともらしいアーキテクチャ上の事実に変換されず、明示されたままになったことです。独立した正解データのルール、ドシエの構成、各システムの調査結果については、docs/real-world-validation/README.md をご覧ください。Quarkus システムを実際に試すには、Quarkus Super Heroes のデモを実行してください。

OpenTelemetry によるランタイムエビデンス

AIP は OTLP トレースを追加のテレメトリーコンシューマーとして取り込みます。可観測性バックエンドの代わりではありません。 OTel Collector の転送先が AIP だけになることは決してあってはならず、AIP 自体の可用性がアプリケーションの通常の可観測性に影響することもあってはなりません。

同梱のランタイムデモでは、継続的に合成トラフィックを生成し、API と Service Explorer の両方で CONFIRMED、OBSERVED_ONLY、NOT_OBSERVED_IN_WINDOW の関係がリアルタイムに表示される様子を確認できます。

OpenTelemetry との統合 → · ランタイムデモの解説 →

オプションの自然言語クエリインターフェース

POST /api/query は、対話的な探索のための自然言語の質問にも回答します。可能な場合は既存の決定論的な分析に振り分け、それ以外の場合は LLM が生成した Cypher を使用します。この Cypher は、Neo4j に送られる前に、厳格な読み取り専用許可リストバリデーターを通過する必要があります。LLM が書き込み用の認証情報を保持することはなく、追跡可能性を確保するため、生成した Cypher は常に表示されます。完全にオプションの機能です。LLM プロバイダーを設定しなくてもプラットフォームは動作し、MCP ツールがこの機能に依存することもありません。詳しくは docs/semantic-validation.md をご覧ください。

境界

MCP ツールが返す内容と、意図的に返さない内容です。最初の 3 つのツールは、以下の ArchitectureAnswer エンベロープを共有します。4 つ目は別途バージョン管理された ローカリティ契約、5 つ目は別途バージョン管理された API コンシューマー使用状況契約、6 つ目は 宛先コンシューマー契約を追加します。

1 つのエンベロープ。 最初の 3 つのツールは、同じ ArchitectureAnswer（schema_version、producer、 tool、outcome、snapshot、observation_context、data、claims、evidence_refs、 limitations）を返し、公開済みのクローズドな JSON Schema に照らして検証されます。依存関係とドリフトの回答では claims／evidence_refsに値が設定されます。一方、get_evidenceはエビデンスレコードをdataに解決し、 トップレベルの配列は意図的に空のままにします。

履歴ではなく現在の状態。 各回答は、安定したグラフスナップショット ID（現在のグラフ状態の フィンガープリント）に紐付けられます。これにより、関連する 2 つの回答が同じ特定のグラフ状態を 参照していることを証明できます。履歴または特定時点のクエリを実行する仕組みはなく、現在のものではない snapshot_idを指定すると、古いデータから回答するのではなく、SNAPSHOT_NOT_AVAILABLE制限によって 拒否されます。

観測コンテキストの明示。 実行時の状況に依存する依存関係ツールとドリフトツールは、すべての回答に 環境と時間枠を含めます。一方、get_evidenceは意図的に観測コンテキストを持たず、明示的な snapshot_idを必要とします。

直接依存関係のみ。 1 ホップのみです。推移的な探索はなく、ツールの背後に汎用的な Cypher クエリや グラフクエリを実行する仕組みもありません。

宣言済みの Pub/Sub のみ。 トピックとサブスクリプションは、宣言済みの AsyncAPI（または設定済みの マッピング）からのみ取得されます。実行時テレメトリによる確認はできますが、テレメトリによってそれらが 新たに作られることはありません。また、AIP には Kafka、Azure Service Bus、Google Pub/Sub、 RabbitMQ のライブブローカー検出機能はありません（ docs/ingestion.mdを参照）。

1 つのパス、1 つの接続モード。 /mcpが提供するのは、標準のネゴシエーション済み MCP のみです（ docs/mcp.mdを参照）。v0.4.xの直接エンベロープは廃止されており、有効な ネゴシエーション済み MCP トラフィックではないリクエストは拒否されます。

ローカルまたは信頼できるネットワーク。 AIP のその他の部分と同様に、/mcpはローカルまたは 信頼できるネットワークでの利用を想定して構築されています。パブリックインターネットに直接公開するための 堅牢化はされていません。docs/security-model.mdを参照してください。

ドキュメント

• docs/mcp.md — AI エージェント向けの読み取り専用 MCP ツール6種類と、実行可能なヒーローデモの手順
• docs/architecture.md — パイプライン、API の概要
• docs/canonical-model.md — エンティティと決定論的 ID
• docs/graph-model.md — 関係、事実／エビデンスの不変条件、観測された PROVIDES
• docs/evidence.md — プロベナンス、Evidence ノード、相関モード
• docs/ingestion.md — 宣言されている3種類のソースアダプター
• docs/analyses.md — A1-A5 と O1-O5
• docs/semantic-validation.md — 自然言語クエリのパイプライン
• docs/opentelemetry.md — 実行時の観測、属性の許可リスト、カバレッジ
• evaluation/README.md — 決定論的評価スイート：シナリオ、グラウンドトゥルース形式、実行方法、失敗レポートの読み方
• real_world_validation/README.md と docs/real-world-validation/README.md — v0.3 の 実環境検証契約：検出事項の語彙、expected.yaml の形式、ドシエの構造
• docs/configuration.md — すべての設定とそのデフォルト値
• docs/security-model.md — 信頼境界
• docs/development.md — ローカル開発、テスト、リンティング
• docs/adapter-development.md — 新しいソースを追加して AIP を拡張する方法
• docs/reviews/architecture-review-0.4.0.md — v0.4.0 後の アーキテクチャレビュー：維持された点、4つの構造上の所見、測定された読み取りコスト
• docs/reviews/code-health-review-2026-10-08.md — v0.6.2 におけるコードの健全性と 設計レビュー：優先度順に並べた5つの所見
• docs/product-doctrine-and-strategic-direction.md — プロダクトの理念、意味上の境界、戦略的方向性、ロードマップの根拠
• docs/adr/ — アーキテクチャ決定記録：Neo4j を採用した理由、Canonical Model を採用した理由、LLM が読み取り専用であり、決して信頼できる情報源ではない理由など
• docs/specifications/ — プラットフォームが現在の形になった経緯を追跡できる、オリジナルの設計仕様
• docs/landscape.md — 調査の展望：形式的基盤、関連プラットフォーム、エージェントのコンテキスト、アーキテクチャ上の意図、ガバナンス、検証
• ROADMAP.md / CHANGELOG.md — 今後の方向性と、これまでにリリースされた内容

貢献

開発環境のセットアップ、テスト／リンティング／フォーマットのコマンド、アダプターのコントリビューションガイドについては、CONTRIBUTING.md を参照してください。質問やアイデアはディスカッションへ、バグ報告や機能リクエストには issue テンプレートをご利用ください。セキュリティ脆弱性を公開 issue として報告しないでください。詳細は SECURITY.md を参照してください。このプロジェクトはContributor Covenantに準拠しています。

プロジェクトの状況

最新リリース： v0.7.2 — コンテキストエンジンの相互運用性 + プロダクト境界の適格性確認。

1.0 より前の段階では、REST／MCP のインターフェース、Graph Schema、Canonical Model、Adapter SPI、設定形式は、マイナーバージョンの更新で変更される可能性があります。各リリースでは、公開アーティファクトの検証記録が公開されます。最新の記録は docs/release-validation/v0.7.2-release-record.md です。各リリースで公開された内容については CHANGELOG.md を、今後の予定については ROADMAP.md を参照してください。

ライセンス

Apache License, Version 2.0 の下でライセンスされています。 LICENSE をご覧ください。サードパーティ依存関係のライセンスについては、THIRD_PARTY_LICENSES.md をご覧ください。