コーディングエージェントプラグイン:ターミナルから離れずにアーキテクチャを管理 - Archyl Blog

Claude Code、Codex、その他のコーディングエージェントにArchylの200以上のMCPツールへのフルアクセスを提供するプラグインをオープンソースで公開しました。システムの作成、ADRの記述、ドリフトの確認、準拠性の強制 — すべてをターミナル上の自然言語の会話から行えます。

コーディングエージェントプラグイン:ターミナルから離れずにアーキテクチャを管理

先月、チームの開発者がありえないと思えるようなことをするのを目の当たりにしました。

彼はClaude Codeでリファクタリングの真っ最中で、モノリシックなサービスを3つの小さなサービスに分割していました。途中で、こう入力したのです:「ArchylのECommerceシステムの下に、OrderService、InventoryService、NotificationServiceの3つの新しいコンテナを作成して。OrderServiceから他の2つへの'calls'リレーションシップも追加して。」

10秒後、Archylの C4 model には3つの新しいコンテナが、リレーションシップが正しく接続された状態で、アーキテクチャの適切な場所にきちんと配置されていました。彼はタブを切り替えることもなく、ブラウザを開くこともなく、ただコーディングを続けました。

その瞬間、このプラグインはリリースする準備ができたと確信しました。

コンテキストスイッチの問題

アーキテクチャドキュメントには根本的なUXの問題があります。それはコードとは別の場所に存在するということです。

あなたはIDEの中にいます。モジュールの構造を変更し、3つのサービスの名前を変え、データベースを読み取り用と書き込み用のレプリカに分割しました。コードは完成です。次にアーキテクチャを更新する必要があります。それはArchylをブラウザで開き、正しいプロジェクトを見つけ、正しいダイアグラムに移動し、コンテナを更新し、リレーションシップを追加し、変更理由を説明するADRを書くことを意味します。

5分で終わります。しかし、その5分には隠れたコストがあります。コンテキストスイッチです。脳はコードから離れ、ビジュアルダイアグラムモードに入り、今やったことを思い出し、それをアーキテクチャの概念に変換し、そしてまたコーディングに戻らなければなりません。ほとんどの開発者は...やりません。後でドキュメントを更新しようと自分に言い聞かせます。その「後で」は永遠に来ません。

これがアーキテクチャドリフトが存在する理由です。チームがドキュメントを気にしないからではなく、ツールが間違った場所に間違ったタイミングで存在しているからです。

会話の中にアーキテクチャを

Archyl Developer Pluginは、アーキテクチャ全体をコーディングエージェントのコンテキストに組み込みます。これはClaude Code用のプラグインで(CodexやほかのエージェントとCも互換性があります)、Archylの200以上のMCPツールすべての使い方をエージェントに教えます。

実際にはどういうことでしょうか?つまり、こんなことができるのです:

リファクタリング中に、エージェントにアーキテクチャの更新を指示:

I just split the PaymentService into PaymentProcessor and PaymentGateway.
Update the architecture — remove the old container, create the two new ones,
and move all existing relationships to the appropriate new container.

コードレビュー中に、アーキテクチャのコンテキストを確認:

Get the full C4 model and tell me which components depend on the UserRepository.
Are there any conformance rules I should know about before changing the data layer?

作業計画中に、ドキュメントが最新かどうかを確認:

What's the current drift score? Show me which elements have drifted
and what the AI thinks is out of date.

設計ミーティングの後に、ターミナルから離れずに決定を記録:

Create an ADR: we decided to migrate from REST to gRPC for all internal
service communication. Context: latency requirements from the mobile team.
Link it to the ApiGateway and all backend service containers.

エージェントがMCP呼び出しを処理し、プロジェクトIDを管理し、操作を連鎖させます。あなたは自然言語でやりたいことを説明するだけです。

プラグインがカバーする範囲

プラグインは7つのドメインにわたる構造化された知識をエージェントに提供します:

C4 Modeling — システム、コンテナ、コンポーネント、コード要素、リレーションシップの作成と管理。エージェントはC4階層を理解し、適切な命名規則を強制します(システムとコンテナにはPascalCase、コード要素には正確なシンボル名)。

Documentation — ADRの作成、プロジェクトドキュメントの作成、ユーザーフローの定義、AI生成のインサイトのレビュー。ADRは影響を与えるC4要素にリンクされるため、アーキテクチャの決定がアーキテクチャと結びついたままになります。

Governance — 準拠ルールの作成、コンプライアンスチェックの実行、アーキテクチャドリフトの監視。エージェントはAIコーディングセッションが始まる前にガードレールを設定できます。

Operations — 環境間のリリース追跡、APIコントラクトのドキュメント化(OpenAPI、gRPC、GraphQL)、イベントチャネルのマッピング(Kafka、NATS、SQS)、テクノロジーレーダーの管理。

Collaboration — コメントの追加、変更リクエストの作成(アーキテクチャ版のPRのようなもの)、ホワイトボードの管理。アーキテクチャの議論がコードの議論と同じ場所で行われます。

History — スナップショットの取得、アーキテクチャバージョンのタイムトラベル、変更の差分確認。「マイグレーション前のアーキテクチャはどうなっていた?」と聞かれたとき、エージェントが答えられます。

Integrations — アーキテクチャ変更通知用のWebhookの設定、マーケットプレイスウィジェットの管理、組織内の全プロジェクトにわたるグローバルアーキテクチャの表示。

セットアップは3ステップ

セットアップは簡単です:

1. マーケットプレイスを追加してプラグインをインストール:

/plugin marketplace add archyl-com/agent-skills
/plugin install archyl-developer@archyl-com-agent-skills

2. プロジェクトの.mcp.jsonにMCPサーバーを追加:

{
    "mcpServers": {
        "archyl": {
            "type": "http",
            "url": "https://api.archyl.com/mcp",
            "headers": {
                "X-API-Key": "arch_your_api_key_here"
            }
        }
    }
}

3. エージェントを再起動して、アーキテクチャと会話を始めましょう。

以上です。プラグインは自動的に読み込まれ、エージェントはすべてのツールの使い方を理解します。設定ファイルもカスタムプロンプトも手動での接続も不要です。

なぜオープンソースなのか

プラグインはgithub.com/archyl-com/agent-skillsで完全にオープンソースです。理由はいくつかあります。

まず、透明性。プラグインがAIエージェントにアーキテクチャとのやり取り方法を教えるとき、それが与えるすべての指示を読めるべきです。スキル定義、リファレンスファイル、ワークフローの例 — すべてがプレーンなMarkdownで公開されています。

次に、コントリビューション。Archylには200以上のMCPツールがあり、最も優れたワークフローは実際の使用から生まれます。あるチームが有効なパターンを発見したとき — たとえばメジャーリリース前のアーキテクチャ監査ワークフロー — それをコントリビュートできます。コミュニティが使うことで、プラグインはより良くなります。

そして、ポータビリティ。スキルコンテンツはClaude Codeに固定されていません。プラグインフォーマットをサポートする任意のエージェントで動作します。.claude-plugin.codex-pluginのマニフェストが両方含まれています。来月プラグインサポート付きの新しいコーディングエージェントが登場しても、スキルコンテンツはそのまま移行できます。

何が変わるのか

変化は微妙ですが、大きな意味を持ちます。

プラグインがない以前は、アーキテクチャドキュメントは別の作業でした。コードを書き、その後ドキュメントを書く。2つのワークフロー、2つのツール、2つのメンタルモード。ドキュメントは常に一歩遅れていました。それは常に一歩離れた場所にあったからです。

プラグインがあれば、アーキテクチャドキュメントはコーディングの会話の一部になります。「ドキュメントを更新する」のではなく、何が変わったかを伝えるだけでエージェントが処理します。アーキテクチャが同期し続けるのは、誰かが更新を忘れなかったからではなく、更新することが手間でなくなったからです。

これはエージェントワークフローにおいて特に強力です。AIエージェントがコードベースに変更を加えるとき、同時にアーキテクチャを更新できます。コードをリファクタリングするのと同じセッションで、C4 modelを更新し、ADRを記録し、準拠性チェックを実行します。アーキテクチャガバナンスは開発フローの自然な一部となり、後付けではなくなります。

始めましょう

プラグインをインストールし、MCPサーバーを接続して、エージェントにアーキテクチャを説明してもらうことから始めてみてください。そして変更を加えるよう依頼してみてください。ターミナルの会話からC4 modelを初めて更新したとき、なぜ今までこれ以外の方法でやっていたのかと不思議に思うでしょう。

プラグインは今すぐ利用可能です。完全なドキュメントはガイドにあり、ソースコードはGitHubで公開されています。

アーキテクチャは別のタブに存在すべきではありません。もうその必要はなくなりました。