失敗からの再生：フロントエンドAIエージェントの導入までの実体験 本日のFEDayで、フロントエンドエージェントの実装に関するケーススタディを共有しました。中心となるのは、勝利のラップではなく、チームがどのようにして「技術的な成功」から「製品の失敗」へと転落し、その失敗が私たちの認知フレームワークの重要なアップグレードにつながったのかというストーリーです。 この物語の価値は、成功のための方法論にあるのではなく、私たちが遭遇した落とし穴と私たちの考え方の進化にあります。
2025年は「エージェントの年」として注目を集めています。Deep Research、Manus、Claude Codeのリリースにより、テクノロジーコミュニティは活況を呈しています。 多くのチームが同じ質問をしています。「エージェントを構築すべきか?」
本題に入る前に、AI エージェントの定義を明確にしておきたいと思います。 > AI エージェント: 特定の目標を達成するためにツール呼び出しをループする大規模言語モデル (LLM)。 - ループ内のツール: モデルがツールを呼び出す -> 結果を取得する -> 推論を続行します。 - 明確なエンドポイント: 無限ループではなく、目標を達成するように機能します。 - 柔軟な目標ソース: 目標はユーザーまたは別の LLM から取得できます。 - 基本メモリ: 会話履歴を通じてコンテキストを維持します。
課題：プライベートデザインシステム 友人のチームは、企業にとって深刻な課題に直面していました。社内には完全な社内デザインシステムと非公開のフロントエンドフレームワークがありました。しかし、このコードは非公開だったため、公開AIモデルはこれまでそのコードを使って学習したことがありませんでした。汎用モデルでは、社内仕様に準拠したコードを生成できなかったのです。 目標は明確でした。「Lovableのような」ツールを、独自のデザインシステムで構築することです。ユーザーがFigmaのデザインやスクリーンショットをアップロードすると、エージェントが社内標準に準拠したフロントエンドコードを自動生成します。 完璧だと思いませんか？
現実の確認 課題は重大でした。 1. 完全なエージェント システムの構築は見た目よりも困難です (ユーザー インタラクション、コンテキスト エンジニアリングなど)。 2. モデルは、これまで見たことのないプライベート コンポーネントを理解して使用する必要があります。 3. 生成されたコードをブラウザでリアルタイムにプレビューする必要がありました。 4. コードに障害が発生した場合に自動修復機能が必要でした。
「技術的成功」：それをいかに構築したか 技術コンサルタントとして、私が最初に与えたアドバイスは実際的なものでした。「最適化する前に実行してみましょう。」エージェントの構築は最も難しい部分ではなく、完全な実行ループを完了することが最も難しい部分です。
1. 基盤: クロード エージェント SDK 車輪の再発明をする代わりに、Claude Agent SDK をベースに構築しました。 - 実証済み: Claude Code により、このアーキテクチャが機能することが証明されました。 - すぐに使用可能: 組み込みツールがシナリオの 90% をカバーします。 - 拡張可能: カスタム ツール、MCP (モデル コンテキスト プロトコル)、カスタム スキルをサポートします。 (プロトタイプコードの一部は、こちらでオープンソース化されています: https://t.co/eon1eb3ECD)
2. プレビューソリューション: ローカルファイルシステム 当初、コードプレビューのためにSandpack（ブラウザベースのサンドボックス）を試しましたが、複雑なプライベートコンポーネントではうまく機能しませんでした。そこで、エージェントにローカルファイルシステム（セッションごとにVMまたはディレクトリ）を割り当てました。これにより、エージェントはコードを自由に読み書き、変更、コンパイルできるようになりました。
エージェントにローカル ファイル システムを与えることが、その機能を最大限に活用する唯一の方法です。
3. 「不明なコンポーネント」問題の解決 AI に見たことのないコンポーネント ライブラリの使用方法を教えるにはどうすればよいでしょうか? 新入社員のように扱ってください。デザインシステムの仕様、コンポーネントリスト、APIドキュメントをMarkdown形式に変換しました。 複雑な RAG は必要ありません。エージェントがローカル ドキュメントと「高品質の参照コード」でファイル取得を実行できるようにしました。
4. 品質保証：検証ループ コードが実際に動作することを確認するために、自動ループを構築しました: 生成 -> 検証 -> 修復 - ツール: 静的リンティング、コンパイル チェック、ビジュアル比較 (Chrome DevTool MCP を使用)。 - 最適化: メイン エージェントのコンテキスト ウィンドウが汚染されないように、検証ツールをスキルまたはサブエージェントに配置しました。
「製品の失敗」：発売後の沈黙 システムはうまく機能しました。デモは驚くほど素晴らしいものでした。しかし、リリースしたのですが…ほとんど誰も使ってくれませんでした。 当初の目新しさが薄れてくると、離脱率は急上昇しました。徹底的な事後分析とユーザーインタビューを実施した結果、問題はテクノロジーではなく、製品ロジックとユーザーの習慣のズレにあることが判明しました。
なぜ失敗したのか 1. 習慣への抵抗：デザイナーやプロジェクトマネージャーはチャットウィンドウではなくFigmaで作業しています。慣れ親しんだ環境から会話型のインターフェースに移行することは、大きな障壁でした。ほとんどの人は何を入力すればいいのかさえ分かりませんでした。 2. 80/20ボトルネック：エージェントは作業の80%を完璧にこなしました。しかし、残りの20%は手作業による修正が必要で、非常に手間がかかりました。多くの場合、この20%がコードが使えるかどうかを決定づけていました。 3. ワークフローの断片化：生成環境が実際の開発環境から切り離されていました。開発者はコードを手作業でコピー＆ペーストする必要があり、プロセスが煩雑になっていました。
認知のアップグレード：問題の再構築 私たちは間違った質問をしていたことに気づきました。「デザインシステムの AI エージェントをどのように構築するのか？」この質問によって、エージェントが手段ではなく目標になってしまったのです。 正しい質問は、「私たちのデザインシステムの究極の目的は何ですか？」でした。 1. 企業全体で統一された設計仕様。 2. 開発効率の向上。
シフト1：人間ではなくAI向けに設計する 現在のワークフローは人間中心です (手動でのコミュニケーション、反復的な変更、手動での確認)。将来のワークフローは AI 中心である必要があります (入力 -> AI エージェント -> 出力)。 新しい設計原則: - AI 対応: LLM が簡単に理解できるテクノロジー スタックを選択します。 - 軽量：デザイントークンのみを保持します。大規模なプライベートライブラリを維持するのではなく、AIに適したオープンソースシステム（shadcn/uiなど）を拡張します。
シフト2：「エージェント」から「スキル」へ 最も重要な転換点は、「独立エージェント プラットフォーム」を放棄したことでした。 旧モデル (アイランド): 開発者から分離されたスタンドアロンのエージェントで、摩擦が生じます。 新しいモデル (統合): デザイン システムを、既存の AI 開発環境 (Cursor や Claude Code など) に埋め込むことができるスキルに変換します。
スキルとは何ですか? これは単純に、Markdown ドキュメント (AI が読み取るため) + 自動化スクリプト (プロジェクトを初期化し、システムをインストールするため) です。 開発者は使い慣れた環境で作業できます。デザインシステムが必要になった場合、汎用エージェントがこの「スキル」を呼び出し、生成されたコードはプロジェクトリポジトリに直接保存されます。 (参照アプローチ: anthropics/skills/tree/main/skills/web-artifacts-builder)
深い洞察：4つの重要なポイント 1. 技術的な成功 != 製品の成功 多くのエンジニア（私も含めて）は、「動作するから成功だ」という考えに陥ります。ユーザーは技術スタック自体には関心がありません。重要なのは、フローを中断することなく問題を解決できるかどうかです。 2. 「AI中心」のワークフローを設計する 「ユーザー中心」という言葉を使いますが、さらに「AI中心」という要素も加える必要があります。AIに人間のワークフローを模倣させるのではなく、AIが最大限の効率で動作するようにワークフローを再設計し、その結果を人間が享受できるようにしましょう。 3. スキル > エージェント 独立系エージェントプラットフォームは導入障壁が高く、既存のエコシステムに接続できるスキルとして機能をカプセル化することが、はるかに現実的な選択肢となります。 4. アクション 最初の製品は「失敗」しましたが、認知能力の向上は計り知れない価値がありました。「人間のワークフロー」から「AIワークフロー」への移行は、実際に手を動かして学ぶことなしには習得できません。
ただ構築するだけです! 失敗は許容範囲です。何もしないよりは、はるかに良いことです。
