ソフトウェア開発者、テックリード、DevOps エンジニアの多くは、ビルダーとしてキャリアを歩み始めます。

システム、アプリ、コンポーネント、テーマ、パターン、モジュール、パイプラインを作る。レイアウトを最適化し、エッジケースを潰し、互換性を保ち、コミットを一つずつ重ねてシステムを前へ進めていく。仕事は緻密で実践的、そして深く技術的です。

けれど、ある時点で何かが変わります。

優れた実践者は、作ることをやめるわけではありません。ただ、システムとして考えるようになるのです。

ビルダーからシステム思考者へ

視点の転換:成果物からルールへ

ビルダーが見ているのは成果物です。コンポーネント、テンプレート、ページ、機能、ライブラリ、アプリケーション。

システム思考者の関心はルールへと移ります。制約、相互作用、フィードバックループです。

「このコンポーネントはどんな見た目か」と問う代わりに、システム思考者は別の問いを立てます。このコンポーネントを支配するルールは何か。何が関わることを許されているのか。変化の中でどう振る舞うのか。意図は時間を経てもどう生き残るのか。

この転換は、自然とエージェント型システムへとつながっていきます。

デザインが静的であることをやめるとき

現代のデザインシステムは、すでにロジックを内包しています。トークンが制約を定め、コンポーネントが構造を定め、パターンが振る舞いを定める。

それでも多くのシステムは、依然として人手による重い調整に頼っています。

AI エージェントは別のモデルをもたらします。システム自身がルールを適用し、判断を継続的に検証し、文脈に反応し、内部で連携する。そんなモデルです。

ここでデザインは、ドキュメントから実行可能なロジックへと進化します。

これから向かう先

いま力を注いでいるのは、これらの考えを実際に動くシステムとして実装することです。実験ではなく、土台として。

1. デザインツール(Figma)とのより深い AI エージェント統合

エージェント型デザインシステムへ

デザインツールは、受け身のキャンバスであってはなりません。

目指すのは、デザイントークンやコンポーネントの制約を理解し、判断をリアルタイムで検証し、デザインの意図をシステムレベルのルールへと翻訳し、書き出し役ではなく協働者として動く AI エージェントを Figma と統合することです。

これによりデザインは上流へ移り、意図は後から推測されるのではなく、そのまま保たれます。

2. スケーラブルな AI エージェント管理

目標:150 のエージェント、コンポーネントごとに一つ

汎用の AI を一つ置くのではなく、チームは多数の専門特化したエージェントへと移行しつつあります。

各コンポーネントが、明確な責務、はっきりした境界、関連コンポーネントへの認識を備えた専用のエージェントを持ちます。

これは、健全なシステムがスケールする仕組みと同じです。専門化、連携、そして明確な契約によって。

3. 本物のスキル、ツール、プラグインを備えたエージェント

エージェントは行動できなければなりません。

そのためには、スキル(アクセシビリティの推論、デザインの検証、パフォーマンスへの意識)、ツール(リンター、テストランナー、デザイン API)、プラグイン(Storybook、Drupal、CI パイプライン、Figma 連携)を持たせる必要があります。

ツールのないエージェントは理論上の存在にすぎません。ツールを持ったエージェントは、システムそのものの一部になります。

4. よりスマートな機能受け入れテストの自動化

AI 駆動で、意図を理解する

従来のテストは出力を確認します。エージェント駆動のテストは振る舞いを理解します。

焦点は、ユーザージャーニーを推論する AI エージェント、セレクターだけでなく意図を理解する機能テスト、コンポーネントとともにテストも進化させるシステム、そして壊れやすいテストを減らしつつ意味的な信頼性を高めることにあります。

テストは、システムの知性のもう一つの層になります。

AI 時代の TDD と BDD:AI エージェントがテストファースト開発をこれまで以上に求める理由

なぜ重要なのか

チームは、作り手よりも長く生き続け、絶えず適応し、長期的な設計判断を先へと運んでいくシステムを築いています。

そんな世界では、手作業による制御はスケールしません。けれど、よく定義されたルールはスケールします。

デザイナー、開発者、そして AI エージェントは、同じ論理的な枠組みの中、つまり制約と意図を共有する一つのシステムの中で動く必要があります。

ビルダーからシステム思考者への移行は、実装を手放すことではありません。システムを部品の寄せ集め以上のものとして捉えることです。

次の一歩は、システムが推論し、適応し、進化できるようにするルールを設計することです。

この転換を果たしたソフトウェア開発者、テックリード、DevOps エンジニアは、ただ作っているのではありません。システムが自ら築かれていくための条件を築いているのです。