スキルエンジニアリングとワンショット AI デザインへの異論
Impeccable の Paul Bakaus は、AI エージェントの設計において「ワンショット」アプローチの限界を指摘し、人間が意図を制御できる「スキルエンジニアリング」という新たな分野の確立を提唱している。
キーポイント
ワンショット設計の限界とステアリングの重要性
AI エージェントに全体を一度に再設計させるのではなく、人間が「より大胆に」「より静かに」といった具体的な指針で結果を誘導する仕組みが必要である。
スキルエンジニアリングという新分野の確立
単なるプロンプト作成を超え、ドメイン知識と文脈を統合し、エージェントに設計言語を与える「スキルエンジニアリング」が独立した専門領域として台頭している。
モデル固有の差異への対応とルーティング
Claude Code や GitHub Copilot など異なる環境間で機能するスキルを構築するには、各モデルやハッチの能力差を考慮し、タスクを適切に振り分けるルーティング機構が不可欠である。
曖昧な用語の定義と一貫性の確保
デザイナーが使う「大胆さ」といった抽象的な概念を、AI エージェントが実行可能な具体的な設計原則(階層、スケール、タイポグラフィなど)に翻訳する必要がある。
Skill Engineering の重要性
AI に「大胆さ」のような抽象的な指示を出す際、専門用語やドメイン固有の概念(階層、スケールなど)を定義した「スキル」を用いることで、意図通りの結果を得られる。
役割の融合とスタックの上昇
デザインとエンジニアリングの境界が曖昧になりつつあり、単純な実装や外見の調整に留まる従来型の職種は自動化による圧力を受け、より本質的な「何を」を考える層へシフトする必要がある。
AI と人間の役割分担 (80/20 ルール)
AI は下地となるレイアウトや実装の 80% を迅速に生成し、残りの 20%(味付け、文脈、独自性)は人間が所有・決定するモデルを提唱している。
影響分析・編集コメントを表示
影響分析
この記事は、生成 AI を利用したソフトウェア開発やデザインプロセスにおける「人間と AI の協働」のあり方を再定義する重要な示唆を与えています。特に、万能なワンショット生成への過度な期待を戒め、ドメイン特化型のスキル体系(Skill Engineering)を構築することで、AI エージェントの実用性と制御性を高める方向性を提示しています。これは今後の AI エンジニアリングの標準的なプラクティスとして定着する可能性が高いです。
編集コメント
AI エージェントの進化において、単なるプロンプトの巧みさだけでなく、ドメイン知識を構造化した「スキル」を設計する能力が次世代のエンジニアリング競争力を決定づけるでしょう。

AI エンジニアの世界博覧会における Impeccable のポール・バカウス。
ポール・バカウスは、「スキルエンジニアリング」という新興分野が AI エージェントの能力を高めることができると考えていますが、同時に創造的プロセスから人間を排除することには絶対反対です。彼は Latent Space と対談し、AI 時代におけるデザインへのアプローチについて語りました。
バカウスは、コーディングエージェントにインターフェースを改善するための語彙を与えるオープンソースのデザインスキルシステム「Impeccable」の創設者です。エージェントに対してウェブサイトを一度で再設計するよう求めるのではなく、ユーザーは特定のセクションを「より大胆に」「より静かに」「より密度高く」、あるいは「より洗練されたものにする」と指示することができます。
これらの一見単純なコマンドの背後には、AI プロダクトがどのように構築されるべきかというより大きな議論があります。バカウスによれば、エージェントには指示だけでなく、ドメイン知識(専門分野の知識)、文脈、そして人間が結果を誘導するための明確に定義された方法が必要だと述べています。
「要点は、最終的にどのような成果物を得たいのかを誘導する方法を与えることです」と彼は AI エンジニアの世界博覧会でのセッションで語りました。「これは一度きりのデザインのためのツールには決してなりません。それが意図するところではありません。」
スキルエンジニアリングという新興の工芸
Impeccable は、Anthropic のフロントエンド設計スキルという比較的シンプルな拡張として始まりました。その聴衆が増えるにつれ、Bakaus はこれを複数のコンポーネントとワークフローを備えたより複雑なシステムへと発展させました。
このプロセスを通じて、彼はスキルエンジニアリングを独自の一分野として捉え直すようになりました。カンファレンスでの彼のワークショップでは、彼が「暗黒の芸術」と呼ぶスキルの構築について探求しました。
「興味深いトピックの一つは、ほとんどのスキルおよびほとんどのモデルは非常に創造的ではないということです」と Bakaus は私に語りました。「それらは一つの方向へと収束し、もし誰もが同じスキルを使ってフロントエンド設計作業やそれに類するものを行うなら、すべてが同じように見えてしまうことになります。」
スキルエンジニアはまた、エージェントハネス(agent harness)とモデル間の違いも考慮する必要があります。例えば、Codex と Claude は、サブエージェントや権限を必ずしも同じ方法で処理するわけではありません。Claude Code、Cursor、GitHub Copilot、および Codex 全体で実行されるように設計されたスキルは、これらがすべて同一の機能を提供すると仮定することはできません。
Bakaus はまた、スキル内部でのルーティング(routing)の実験も行っており、複数の機能を組み合わせ、タスクを関連する指示へと誘導できるようにしています。彼はこれをエキスパート混合モデル(mixture-of-experts model)に例え、トークンの節約と効果の向上のためにルーティングが使用されていると説明しました。
エージェントへの設計語彙の付与
Impeccable の核心的な革新は、デザイナーにとって馴染みのある用語を借用し、それらにエージェントに対してより精密な運用上の意味を与える点にあります。
支援なしのモデルにページを「太く」するよう指示すると、グラデーションやネオン効果、ガラスのような表面を追加してしまうかもしれません。しかし、Impeccable は、ヒエラルキー、スケール、決定的なタイポグラフィといった概念を通じて「太さ」を定義します。これらは既存のデザインシステムを壊すことなく注意を引く変更です。
「意味のない形容詞は単なる美しいアポストロフィに過ぎない」とバカウス氏は語りました。「エージェントに対して、あなたが何を意図しているのかを明確に伝える必要があるのです。」
彼はこれらの用語を、「意味が込められた言葉」であると説明しました。モデルにはすでに「太い」や「静かなる」といった単語の意味に関するある程度の概念がありますが、スキルはそれらを特定の専門分野へと翻訳します。
これが鍵となるのは、専門家には非専門家にはない独自の語彙が存在するからです。バカウス氏は、同じモデルを使用しているデザイナーとエンジニアの成果に大きな差があることを観察しており、それは単にデザイナーが望む結果を明確に表現する方法を知っているからだと述べています。
「私はその言語を、基本的にスキルやシステムへと圧縮し、より良く自己表現できるようにしようとしています」と彼は言いました。
しかし、デザインのすべての部分をこの抽象度の高いレベルから制御できるとは考えていません。小さな調整には間隔の直接操作が依然として最速の選択肢となる可能性があり、一方、オープンエンドのプロンプトは初期探索段階では有用です。
彼はその目的はすべてのツールをエージェントに置き換えることではないと強調した。重要なのは「制御の正確なレベル」を決定し、人間の判断が最も価値を発揮する点に人を配置することである。
デザイナーとエンジニアはスタックの上へ
Bakaus は、デザイン、エンジニアリング、プロダクトマネジメントの間の境界線がより不明瞭になっていく様子を見ている。
「デザイナーがコードの世界に入り込み、エンジニアがデザインの領域に進出し、その逆も起こっている」と彼は言った。「これらの世界はすべて衝突し合っている。」
既存のアートファクトを別の形式に変換することに主に従事している人々にとって、この変化は居心地の悪さをもたらすだろう。Figma のデザインをコードに変換することが主な業務であるエンジニアたちは、自動化の増加に直面しており、既存のインターフェースを有能に見せることだけに貢献が限定されているデザイナーたちも同様の圧力にさらされている。
「すべてのデザイナーはスタックで一つ上へ移動し、『何を』についてより深く考える必要がある」と彼は言った。「私はプロダクトマネージャーとデザイナーの役割が実際には収束しつつあると考えている。」
同時に、デザイナーたちは実装により近づき、コードの世界へと入っている。Bakaus は当初、Impeccable が主にエンジニアにアピールすると予想し、専門的なデザイナーたちがそれを嫌悪するかもしれないと考えていた。しかし実際には、彼は現在、デザイナーがその利用者の少なくとも半分を占めると推定している。
「つまり、デザイナーたちは直接コードの世界へ飛び込むのではなく、支援なしで取り組むのではなく」とBakaus はデザイナーについて語った、「彼らは Impeccable を橋渡しとして使う。なぜなら、それは彼らのコミュニケーション方法を理解して伝えるからだ。これは私が最初にこのツールを構築した当時は明らかではなかった。」
Impeccable には、視覚的な選択と背後にあるコーディングエージェントを組み合わせるライブモードも備わっています。ユーザーは開発環境内の特定のセクションを選択し、複数の代替レイアウトを要求したり(例えば)、より大胆な表現や落ち着いたトーンへの処理を依頼したりできます。このシステムは、第三者のデザインツールから孤立したモックアップを出力するのではなく、プロジェクトに既存のコードとデザインシステムの範囲内で動作します。
Bakaus はこれを、チャットと直接の視覚操作の交差点における潜在的な「デザインハネス」(design harness) と表現しました。
自動モードは存在しない
AI 業界では、完全な自動化が製品開発の自然な帰結として扱われることがよくあります。しかし Bakaus はその前提を否定しています。
彼が見ているのは、2 つの主要な陣営です。一方は従来の Figma を中心としたワークフローを維持しようとする人々であり、他方は「ループマックス」(loopmaxxing) の支持者で、エージェントが人間の介入を最小限に抑えて作業することを望む人々です。
"真実はその中間にあるのです」と彼は言いました。
彼の好むモデルは、AI がまず 80% を迅速に生成することです。つまり、従来であれば多くの時間を要するであろう有能なレイアウトと基本的な実装です。その後、人間が最終の 20% を担当し、そこで審美性、文脈、そして製品に独自の視点をもたらすことになります。これは、エージェント時代における Bakaus のデザイン哲学の中核を成す部分です。
"人々は目的を必要とし、自分が何らかの形で創造に関わりたいと望んでいます」と Bakaus は述べています。「エージェントと共に作業することで、製品に対する所有感がより強まるのです。"
ユーザーは頻繁に、システムがコマンドを自ら選択する自動モードを Impeccable に追加してほしいと依頼します。しかし、彼にはそのような意図はありません。
「自動機能はないし、今後もない」と彼は言いました。
ソフトウェア工場や、エンジニアリングから人間を完全に排除しようとする他のビジョンに関する言語について問われた際、彼の回答は明確でした。
「私はそれに真っ向から反対です」
原文を表示

Impeccable’s Paul Bakaus at the AI Engineer World’s Fair.
Paul Bakaus thinks the emerging discipline of “skill engineering” can make AI agents more capable — but he absolutely does not want to remove people from the creative process. He chats to Latent Space about his approach to design in the AI age.
Bakaus is the creator of Impeccable, an open-source design skills system that gives coding agents a vocabulary for improving interfaces. Instead of asking an agent to redesign an entire website in one shot, users can tell it to make a section “bolder,” “quieter,” “denser,” or more polished.
Behind those apparently simple commands is a larger argument about how AI products should be built. Agents need more than instructions, Bakaus said: they need domain knowledge, context and carefully defined ways for humans to steer the result.
“The point is to give you a way to steer what you want to end up with,” he said during a session at the AI Engineer World’s Fair. “It’s never going to be a tool for one-shot design. That’s not the intent.”
The emerging craft of skill engineering
Impeccable began as a relatively simple extension of Anthropic’s frontend design skill. As its audience grew, Bakaus expanded it into a more complex system with multiple components and workflows.
That process led him to start thinking of skill engineering as a discipline in its own right. His workshop at the conference explored what he called the “dark arts” of building skills.
“One of the interesting topics was that most skills — [and] most models — are not very creative,” Bakaus told me. “They converge in one direction, and if everybody uses the same skill to do frontend design work or something like that, everything ends up looking the same.”
Skill engineers must also account for differences between agent harnesses and models. Codex and Claude, for example, do not necessarily handle subagents or permissions in the same way. A skill intended to run across Claude Code, Cursor, GitHub Copilot and Codex cannot assume they all provide identical capabilities.
Bakaus has also experimented with routing inside a skill, allowing it to combine several capabilities and direct a task toward the relevant instructions. He compared this to a mixture-of-experts model, with routing used both to conserve tokens and improve effectiveness.
Giving agents a design vocabulary
Impeccable’s core innovation is to take terms familiar to designers and give them a more precise operational meaning for an agent.
An unassisted model asked to make a page “bolder” may add gradients, neon effects or glass-like surfaces. Impeccable instead defines boldness through concepts such as hierarchy, scale and decisive typography — changes that attract attention without necessarily breaking the existing design system.
“An adjective with nothing behind it is just a nice apostrophe,” Bakaus said. “You really have to tell the agent what you mean.”
He described these terms as words that have been “imbued with meaning.” The model already has some conception of what words such as “bold” or “quiet” mean, but the skill translates them into a specific professional domain.
This is the key, because experts often possess a vocabulary that non-experts do not. Bakaus said he had observed large differences between the work produced by a designer and an engineer using the same model, simply because the designer knew how to articulate the desired result.
“I’ve been trying to put that language — basically compress it into a skill and into a system — to be able to express yourselves better,” he said.
However, he does not believe every part of design can be controlled from this level of abstraction. Directly manipulating spacing may still be the fastest option for a small adjustment, while open-ended prompting can be useful during initial exploration.
The objective is not to replace every tool with an agent, he insisted. It is to determine “the exact level of control” and insert the person at the point where their judgment is most valuable.
Designers and engineers move up the stack
Bakaus sees the boundaries between design, engineering and product management becoming less distinct.
“Designers are moving into code, engineers are moving into design, and vice versa,” he said. “These worlds are all colliding.”
That shift will be uncomfortable for people whose work primarily consists of translating an existing artifact into another form. Engineers who mainly turn Figma designs into code face growing automation, while designers whose contribution is limited to making an existing interface look competent face similar pressure.
“Designers all have to move one layer up the stack to think more about the what,” he said. “I think the role of the product manager and designer is actually converging.”
At the same time, designers are moving closer to implementation — into code. Bakaus initially expected Impeccable to appeal mostly to engineers and assumed professional designers might resent that. Instead, he estimates that designers now make up at least half of its audience.
“So rather than moving directly into code and, you know, having no help,” Bakaus said about designers, “they use Impeccable as a bridge, because it communicates the way they communicate. And that was not obvious to me when I first built it.”
Impeccable also has a live mode that combines visual selection with an underlying coding agent. A user can select a section inside a development environment and request several alternative layouts or (for example) ask for a bolder or quieter treatment. The system operates within the project’s existing code and design system rather than exporting an isolated mockup from a third-party design tool.
Bakaus described this as a potential “design harness” at the intersection of chat and direct visual manipulation.
There will be no auto mode
The AI industry often treats complete automation as the natural endpoint of product development. Bakaus rejects that premise.
He sees two dominant camps: people trying to preserve the traditional Figma-centered workflow, and on the other side advocates of “loopmaxxing” who want agents to work with as little human intervention as possible.
“The truth is somewhere in the middle,” he said.
His preferred model is for AI to produce the first 80% quickly: the competent layout and basic implementation that would otherwise consume a lot of time. The person then owns the final 20%, where taste, context and a distinctive point of view enter the product. This is a key part of Bakaus’s design philosophy in the agentic era.
“People need purpose, and they want to play a role in whatever they create,” Bakaus said. “When you work with the agent, then you feel more ownership of the product.”
Users regularly ask him to add an automatic mode to Impeccable so that the system chooses the commands itself. He has no intention of doing so.
“There is no auto,” he said, “and there will be no auto.”
Asked about the language of software factories and other visions that appear to remove people from engineering altogether, his response was unambiguous.
“I’m squarely against that.”
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み