Figma エイアル・ブルム氏：コードエージェントの組織導入と品質担保

Figma エンジニアが語る、AI エージェント導入の真実：失敗から信頼回復へ至る 3 つの段階と組織文化の変革

Figma のソフトウェアエンジニアであるエヤル・ブルム氏は、生成 AI エージェントを組織に導入する過程が単なるツールの追加ではなく、「非線形的な学習曲線」を描くものであると指摘します。初期の「10 倍速い」という成功体験から、大規模課題での失敗による信頼崩壊を経て、最終的に適切なガードレールと文脈管理で本格的なスケールを実現するまでのプロセスを解き明かしました。

この動画は、AI エージェントの導入が技術的な課題だけでなく、開発者の主体性喪失やベテランエンジニアのボトルネック化といった組織風土の問題を伴うことを示唆しています。ブルム氏は、これらの課題を解決するために「検証の左シフト」「詳細な計画による主体性の回復」「透明性のあるコミュニケーション」という 3 つの具体的なアプローチを提唱します。

AI エージェント導入には「3 つの段階」がある

組織や個人が AI エージェントを導入する際、直線的に上達していくわけではありません。ブルム氏は、このプロセスを「3 つの幕（アクト）」に分けて説明しています。

最初の段階は、特定の単純な作業で AI を使いこなす時期です。多くのチームがここで「10 倍速く処理できた」という成功体験を得て、AI への期待が高まります。しかし、この成功体験をそのまま大規模な課題や複雑なシステムに応用しようとすると、事態は一転します。

「同じ手法を大きな問題に適用すると、AI はひどく失敗し、バグだらけのコードを生成します。そこで、これまで築いてきた信頼が崩壊するのです」

この「信頼崩壊」の段階を経て初めて、組織は本格的なスキルを獲得します。適切なガードレールの設定、プロンプトエンジニアリング、そして文脈管理（コンテキスト管理）を学び、初めて AI をスケール可能な形で活用できるようになるのです。

この非線形的なプロセスにより、組織内には「AI 先進チーム」と「まだ実験段階にあるチーム」が混在する状態が生じます。ブルム氏は、これらの異なるフェーズにいるチームが共存し、全員を最終段階へと導くサポート体制の重要性を強調しています。

開発者の主体性喪失とベテランエンジニアの悲劇

AI エージェントの導入が進む中で、組織は深刻な副作用に直面しました。一つ目は「開発者の主体性の喪失」です。

コードを書くことへの喜びや没入感（フロー状態）を失い、AI の出力を待つだけの「プロンプトサイクル」に陥るエンジニアが増えています。これにより、多くの人が燃え尽き症候群（バーンアウト）を感じています。

二つ目は、「ベテランエンジニアがボトルネック化する」という逆説的な現象です。組織の最優秀エンジニアほど、AI の限界やコードベースの落とし穴を熟知しています。彼らは AI が生成する不具合を防ぐために、脳内で「メンタルな接着剤」のような役割を果たし、すべてのバグを止める負担を背負わされています。

「彼らは組織内の暗黙知（インスティチュショナル・コンテクト）をすべて抱え込み、結果として最も導入が遅れ、最大のボトルネックとなってしまいます」

さらに、AI を使うことでドキュメントや Slack メッセージの長さが数倍に膨張し、コミュニケーションの非効率化も顕在化しました。何が重要で何が不要かを見極めるコストが上がり、品質の基準を維持することが困難になっています。

解決策 1：検証の左シフトと TDD 様式の採用

これらの課題に対するブルム氏が提唱する第一の解決策は、「検証（Verification）への投資」です。特に重要なのは、人間の作業を AI に任せる前に、テストや設計目標を設定する「検証の左シフト」です。

具体的には、Playwright や MCP などのツールを使って、エージェントがコードを探索・検証できるようにします。また、エージェントが見つけた有用なパターンは、すぐに決定論的なフロー（Deterministic Flow）として定着させます。これにより、トークンコストや時間を節約しつつ、LLM が推論が必要な場面と、すでに確立されたルールで処理できる場面の使い分けが可能になります。

さらに、テスト駆動開発（TDD）のスタイルを AI に適用することが有効です。

「コードを書いてからテストを書くのではなく、『赤→緑→赤→緑』という TDD のサイクルでエージェントに指示を出すと、圧倒的に良い結果が得られます」

これは、AI が「コードに合わせてテストを作る」のではなく、「検証基準を満たすためにコードを書く」ことを強いるためです。テストピラミッドの下部にあるリンティングやコンパイル、ユニットテストといった決定論的な分析をエージェントに委譲し、人間は機能性やアーキテクチャの妥当性といった上位層のレビューに集中する体制が理想的です。

解決策 2：詳細な計画で主体性を回復させる

開発者の創造的喜びを取り戻すためには、「プロンプト」ではなく「計画（Planning）」に重きを置く必要があります。ブルム氏は、人間が詳細な設計ドキュメントを作成し、実装のみをエージェントに任せるアプローチを推奨します。

この計画には、以下の要素が含まれるべきです：

1. Why（なぜやるのか）: ドキュメントの冒頭に明確な目的を書き、AI のドリフト（逸脱）を防ぎます。AI が後から「もっと良い方法がある」と判断して設計を歪めないようにするためです。
2. フェーズ分け: 計画を独立して検証可能な小さなパーツに分割します。
3. 検証ゲート: 各フェーズごとに明確な検証基準や例外処理の条件を設定します。

「良いサイズの目安は、自分がその PR を一気読みできるかです。もしコーヒーを一杯飲む必要があるほど長ければ、それは大きすぎます」

このように人間が「なぜ」「どのように」行うかを徹底的に計画し、レビューを重ねてから初めてエージェントへ実装を依頼します。ブルム氏の実例では、数週間の設計と調整を経て、エージェントが一晩で 6 週間分のコーディングを実行するといった 5 倍のスピードアップを実現しました。

解決策 3：透明性のあるコミュニケーション文化の構築

技術的な導入以上に重要なのが、組織内のコミュニケーション文化の変革です。AI 生成コンテンツと人間が作成したコンテンツを明確に区別し、AI の出力に対する適切な疑念と人間の文脈判断を促す仕組みが必要です。

具体的には、PR（プルリクエスト）の記述や Slack メッセージで「この部分は AI が生成しました」と明記する文化を作ります。Slack でのエージェントタグ活用も有効です。これにより、「AI の出力は盲信せず、人間が最終的な文脈判断を行う」という意識が組織に根付きます。

また、AI に懐疑的なベテランエンジニアを排除するのではなく、彼らを「AI を安全にするロードマップの作成者」として巻き込むべきです。彼らの不満や指摘こそが、システム改善の道しるべになります。

「彼らに AI 使用を強制しようとするのではなく、彼らに『AI の安全性向上』の責任を持たせてください。そうすれば、彼らが実際に自分の生活が良くなる変化を実感した時点で、自然と導入が進みます」

まとめ：人間中心の AI 活用へ

Figma の事例が示すのは、AI エージェントの導入は「ツールの変更」ではなく、「開発プロセスと組織文化の根本的な再設計」を必要とするという事実です。検証の自動化と詳細な計画による主体性の回復、そして透明性のあるコミュニケーション文化——これら 3 つの要素が揃って初めて、AI は開発者の負担を減らし、創造性を高める真のパートナーとなり得ます。

ブルム氏の提唱するアプローチは、生成 AI が単なる効率化ツールを超えて、組織の成熟度を試す指標となっている現代において、エンタープライズレベルでの実装における重要な指針となるでしょう。