【ITニュース解説】How AI changed the way I build software, and why I ended up building an open source shell for Angular

ニュース記事は、AIが現代のソフトウェア開発にどのような変化をもたらし、その変化に対応するためにどのような新しいアプローチが必要とされているかについて語っている。筆者は、数年前と比べて自身の開発スタイルが劇的に変わったと述べている。以前はコードのほとんど全てを自分で書いていたことに誇りを感じていたが、今ではAIに具体的な仕様を伝え、AIが生成したコードをレビューすることが主な作業になっているという。この変化によって、新しいアイデアをより迅速に実現できるようになった一方で、AIが繰り返し同じような落とし穴にはまるリスクも感じている。

特に筆者が直面したのは、新しいプロジェクトを始めるたびに、AIに基本的なアーキテクチャやルールを何度も説明しなければならないという問題だった。例えば、「この部分はプラグインにするべきだ」「コアにはドメインロジックを含めないでほしい」「タブの機能は既存の方法を踏襲してほしい」といった指示をAIに与えても、しばらくすると少し異なる実装で同じような問題が再発することがあったという。この経験から、AIが推測に頼らず、一貫性のある「確固たる基盤」の上で作業できる環境の重要性を強く認識した。このような背景から、AIが理解し、すぐに利用できるような確立されたソリューションを基盤として構築することを目指し、最終的にオープンソースのシェル「LoomWeaver」を開発するに至ったのだ。筆者がAngularという開発フレームワークを選んだのは、過去10年間の経験から、これが優れたフレームワークだと確信しているためである。

LoomWeaverは、Angularアプリケーション向けの「ワークベンチシェル」と呼ばれるものだ。これは単なるUIコンポーネントの集合体ではない。具体的なイメージとしては、人気のある統合開発環境であるVS Codeの画面フレームを想像するとわかりやすい。左側のレール、サイドバー、上部のバー、ステータスバー、そして中央に配置されたタブやペインといった、アプリケーションの基本的な「枠組み」を提供する。多くのワークベンチスタイルの製品は、このようなフレームを毎回独自に、わずかに異なる形で構築する傾向があるが、LoomWeaverはこの共通のフレームを開発者に提供し、製品固有の機能（ドメインロジック）は「プラグイン」としてこのフレームに組み込む形をとる。LoomWeaverのコア部分には、製品固有のドメインロジックは一切含まれていない。これは、自身の製品のUIですら、第三者が利用するのと同じプラグインの契約（ルール）を通じて提供される徹底ぶりだ。このような設計は、後述するAIとの連携において非常に重要な役割を果たす。

LoomWeaverには、タブのグループ化や分割、コマンドパレット、クイックオープン、独自のレイアウトを記憶するワークスペースといった、豊富な機能が最初から搭載されている。テーマ機能はCSS変数に対応し、Tailwind CSSやBootstrapといった既存のCSSフレームワークと共存できる。多言語対応（i18n）やWebアクセシビリティ（WCAG 2.1 AA）にも準拠しているため、幅広いユーザーに対応できる。また、更新がスムーズなPWA（プログレッシブウェブアプリ）機能、複数のウィンドウやタブ間でのリアルタイムな状態同期、未保存作業の管理機能も備わっている。認証機能も内蔵されており、プラグインが必要とするアクセス権限に応じてシェルが反応する仕組みだ。プラグインシステムは、信頼レベルに応じて安全な実行環境を提供し、柔軟な拡張性を実現する。さらに、AG-UIというオープンなプロトコルに対応しており、AIエージェントがこの標準を介してアプリケーションのコマンドを実行できるようになっている。重要な点として、LoomWeaver自体はサーバー機能を持たない。設定や秘密情報などは、既存のバックエンドシステムと連携するよう設計されている。

LoomWeaverの導入は非常に簡単で、既存のAngularアプリケーションにもスムーズに組み込める。コマンドラインツールを使って数分で基本的な環境をセットアップでき、わずか11個のファイルが追加されるだけで、既存のプロジェクトファイルを変更することはない。LoomWeaverにおけるプラグインは「Weaver」と呼ばれており、これは織り機（loom）で布を織る（weave）ように、機能が製品に組み込まれていく様子を表現している。Weaverは、IDや名前、そして必要な機能（capability）を定義するマニフェストと、起動時に実行されるactivate()関数で構成される。このcapabilityはデフォルトで拒否されており、Weaverが必要な機能のみを明示的に宣言することで、セキュリティが確保される。Weaverがワークベンチに提供するのは、通常のスタンドアロンAngularコンポーネントであり、既存のAngularの書き方を変更する必要はない。

このプロジェクトの最も重要な部分は、AIとの連携にある。LoomWeaverは、AIが繰り返し陥る問題を解決するために、いくつかの工夫を凝らしている。第一に、プラットフォームが提供するすべての機能は、明確な「仕様書」としてリポジトリに記述されている。これは単なる説明文ではなく、テストの基盤となる確固たる契約だ。この「確定的基盤」があることで、AIアシスタントはタブの動作や他の機能について推測する必要がなくなり、常に正確な情報に基づいてコードを生成できるようになる。第二に、これらの仕様書はAIが直接読み取れる形式で提供されている。llms.txtやllms-full.txtというファイル、そしてMCPサーバーを通じて、開発者のAIアシスタントがLoomWeaverの契約を直接参照し、プラグインやディストリビューションの生成作業を支援できる。これにより、AIはより的確なコードを生成し、開発者はそのレビューに集中できる。第三に、LoomWeaverのワークベンチはAG-UIという、ユーザー向けアプリケーションとAIエージェント間のオープンなプロトコルをサポートしている。これにより、アプリケーションの内部アクションをAIエージェントに改めて説明する必要がなくなる。例えば、callable: trueと設定されたコマンドは、AIエージェントにとって利用可能な「ツール」として提供される。AIエージェントからのコマンド呼び出しは、ユーザー操作と同じ経路を通るため、権限やアクセス制御が重複して確認されることはなく、AIによる自動操作も人間による操作と同レベルのセキュリティと制御の下で実行される。高コストな操作の前に確認を求めるフックも設定できる。

LoomWeaverはCSSの選択肢も豊富に提供する。ベースはTailwind CSSで構築されているが、シェルはプリコンパイルされたスタイルシートとCSS変数で提供されるため、開発プロジェクトにTailwind CSSを導入する必要はない。Bootstrapなどの好きなCSSフレームワークと共存でき、トークンマッピングのプリセットも用意されている。さらに、プラグインはAngularである必要もない。サンドボックス化されたiframe内でReact、Vue、Svelte、あるいはプレーンなJavaScriptなど、任意の技術スタックで開発できるため、異なる技術を組み合わせた開発も容易になる。

筆者は、LoomWeaverがまだ開発の初期段階にあることを正直に述べている。Angular 22とNode 24以降を対象とし、複数の情報を同時に扱う「ワークベンチ型」製品の開発に適している。シンプルなウェブサイトや単なるUIコンポーネントライブラリ向けではない。コードの多くはAIの支援を受けているが、レビュー、テスト、リリースされるのは、仕様書に基づく契約とエンドツーエンドテストによって保証されている。筆者は建設的なフィードバックを求めており、オープンソースとして多くの開発者が関わることを歓迎している。