AIでつくる過程を、チームで判断できる形にする

Figmaのコードと仕様を共有する新機能、Mistralのデザイン会社買収、Anthropicの第三者評価を読む。AIでつくる速さを、比較・合意・検証につなげるための実務上の判断と小さな実験を整理する。

三方から差し出された板が、中央の円形の開口に合わせて重なるイラスト。

対象期間:2026年10月12日〜18日

AIで試作品をつくりやすくなっても、チームがその案を選んだ理由や、実装してよい条件まで共有できるとは限りません。今週のFigmaの変更は、動くコードと仕様を共同作業の場へ戻すものでした。Mistralの組織づくりにも、モデルを現場の製品や業務へつなぐデザインの役割が表れています。

Anthropicは、第三者評価者が内部情報に触れる範囲と公表の権利を具体的に示しました。制作と安全評価は別の話題に見えますが、どちらも「ほかの人が判断できる材料をどう渡すか」に関わっています。今週は4件について、確認できた事実と、そこから読み取れること、現場で試せることを順に紹介します。

1. 動く試作品を、チームで並べて比較できる場へ

Figmaは10月15日、code layersのオープンベータを全プラン向けに順次開始しました。コードで動く試作品をキャンバス上に置き、複製して別案を試し、横に並べてレビューできます。GitHubやローカルから取り込めるのは、対応する軽量なプロトタイピング用のコードベースで、大規模な本番システムをそのまま扱えるわけではありません。編集結果はブランチへ送ってプルリクエストでレビューできます。AIクレジットを使う仕組みですが、有料プランでは作成・編集が2026年11月4日まで無料と案内されています。Figmaが紹介するMerkleの事例では、反復・機能開発が30%速くなり、文書作成が50%減ったとされていますが、提供元が掲載した顧客事例で、一般的な効果や因果関係を示す数値ではありません。

この機能で注目したいのは、生成の速さよりも比較のしやすさです。たとえば入力フォームを検討するとき、静止画だけでは、入力ミスのあとの戻りやすさやキーボード操作の違いまでは評価しきれません。複数の案を同じ場所で動かせれば、デザイナー以外の人も、実際の操作を根拠に議論できます。もっとも、動く試作品は品質保証の代わりにはなりません。見た目と操作が成り立っていても、実データの権限、読み上げ、例外処理、本番運用の条件は、別に確かめる必要があります。

試すなら、一つの入力フローで2案を用意し、同じタスクで比べてみるとよいでしょう。完了までの時間、入力ミス、戻りやすさ、キーボードだけで完了できるかを記録し、採用した理由も残しておきます。制作時間だけでなく、レビューと修正を含めた総時間が減ったかどうかを見れば、使い続ける価値があるかを判断できます。

出典:Figma「Design together with code layers on the canvas」(新しいタブで開きます)/「Build by design: New workflows for new ways of building」(新しいタブで開きます)(ともに10月15日)

2. 仕様書を、AIと人が共有する判断の記録にする

同じ10月15日、FigmaはSpecsのオープンベータをWeb・デスクトップ・モバイルで順次開始し、全有料プランを対象にすると発表しました。Markdownをキャンバスに取り込み、画面や図、code layersなどを参照する仕様を共同で編集できます。エージェントはコメントの読み書きにも対応し、Figma MCP serverを通じて、仕様と関連する画面・図・Code Connectの情報をコーディングエージェントへ渡せます。同社は、エンジニアが例外条件の原則とフロー図を仕様にまとめ、同僚のコメントとあわせてAIへ渡した自社の開発例を紹介していますが、これは運用の例で、不具合が減ったことを比べた実験ではありません。

とはいえ、仕様が画面の近くにあるだけで、中身の正しさが保たれるわけではありません。大切になるのは、「確定したこと」「試していること」「まだ決まっていないこと」を分けて扱う運用です。AIが試案を承認済みの仕様として扱ってしまえば、情報を一か所に集めたことがかえって誤った実装を広げます。そう考えると、仕様は完成した文書というより、判断の状態を示す記録として扱うほうが実態に合います。購入手続きであれば、画面の説明に加えて、決済に失敗したときの挙動、未確認の条件、承認者を対応づけておくと、実装のときに何を確かめればよいかがはっきりします。

まずは進行中の1機能について、目的、確定事項、例外条件、未決事項、承認者を1枚にまとめ、関連する画面へリンクしてみるのが現実的です。AIに実装を頼む前とあとで、仕様の読み違いによる手戻りの件数と、仕様の更新にかかる時間を記録しておくと、効果が見えてきます。試験中の案が確定事項に紛れ込むようなら、ツールの利用を広げる前に、承認の手順を見直す時期です。

出典:Figma「Introducing Specs: Markdown as a medium」(新しいタブで開きます)/「Build by design: New workflows for new ways of building」(新しいタブで開きます)(ともに10月15日)

3. Mistralがデザイン会社を迎え、顧客との共同開発を組織化

New MaterialがMistralによる買収を公表し、Mistralも公式アカウントで同社の参加を歓迎しました。10月15日のDealroomの報道でも確認されています。新しく設けるSolutions Designチームは、デザイン・エンジニアリング・AIを横断し、顧客と一緒に製品や業務フローをつくる方針です。狙いとして示されたのは、現場への導入で得た知見をMistralの製品へ戻す循環でした。買収金額は非公表と報じられており、発表は組織と方針についてのもので、導入成果が改善したことが示されたわけではありません。

この買収一件で、業界全体の方向を言い切ることはできません。それでも、AI企業が製品化の力を組織の中に取り込んだ例として注目に値します。モデルの能力を説明することと、現場で無理なく使える業務にすることの間には、まだ距離があるからです。デザインや開発のリーダーにとっては、役割分担を見直す材料になります。リサーチの結果を仕様に渡して終わる体制では、導入後に見つかった例外や確認の負担が、次の開発に戻ってきにくくなります。業務の観察、試作、実装、導入後の評価までをつなぐ担い手が、もう一人いてもよいのかもしれません。

AIを導入している業務が一つあるなら、現場の担当者・デザイナー・開発者による30分の週次レビューを、2週間だけ設けてみるとよいでしょう。使うのをやめた場面、手作業に戻した理由、確認にかかった時間を持ち寄り、毎回一つずつ直していきます。利用回数だけでなく、差し戻しや確認の負担が減ったかを見ていけば、この体制を続けるかどうかの判断材料がそろいます。

出典:New Material「New Material joins Mistral to design the frontier」(新しいタブで開きます)(公式サイトは2026年10月表記)/Mistral公式投稿掲載ページ(新しいタブで開きます)/Dealroom「Mistral buys design agency New Material to build enterprise AI team」(新しいタブで開きます)(10月15日)

4. 第三者評価は「誰が、どこまで見て、公表できるか」へ

Anthropicは10月15日、独立評価機関METRの6人に、社内のリスク評価担当に近いアクセスを提供し始めたと発表しました。機材や執務場所、内部のツール・システムへのアクセスを含みますが、顧客データや弁護士秘匿情報、モデルの構造などは例外です。METRは分析を公表でき、Anthropicに公表を拒む権利はありません。ただし、あらかじめ決めた情報の区分については削除を求めることができ、その区分に当たるかどうかは最終的にAnthropicが判断します。METRは、受け取った情報やアクセスの程度についても一定の説明を公表できます。この条件は10月16日に追記されたものです。ほかの評価者との協力には、アクセスや公表の権利がより限られた段階もあり、評価の体制が始まったことを、安全性の認証を得たことと読み替えることはできません。

先日の自主協定から一歩進み、外部の評価者が何を見られるのかが具体的になりました。調達の場で「第三者評価あり」とだけ確かめても、評価の強さは比べられません。評価者が公開APIしか使えない場合と、事故の記録や内部の安全対策まで確認できる場合とでは、見つけられる問題が違ってくるからです。また、基盤モデルの評価が、自社の業務フローや権限設定の安全性まで保証してくれるわけではありません。ベンダーの評価と、自分たちが組み立てたサービスの受入試験は、分けて考える必要があります。

手始めに、候補のベンダー1社について、公開資料から評価者、対象のモデルと時点、閲覧の範囲、公表の権利、非公開の事項を整理してみるとよいでしょう。分からない欄は「確認済み」とせず、質問事項として残しておきます。そのうえで自社側の試験に、誤操作や権限外の要求、停止したあとの挙動を加え、誰が合否を決めるのかまで決めておくと、受入の段階で迷わずに済みます。

出典:Anthropic「An update on independent evaluators」(新しいタブで開きます)(10月15日、16日追記)

今週の優先アクション

  1. 一つの仕様に、確定事項と未決事項を分けて書いてみる。 前提があいまいなまま生成や自動化を増やすと、確認と手戻りも増えます。まずは情報を整理するところから始めるのが近道です。
  2. 一つの操作を2案で比べてみる。 動く試作品で、完了時間・誤操作・キーボード操作・レビューの工数を測れば、制作の速さが判断や品質の改善につながったのかが見えてきます。
  3. ベンダー1社で、第三者評価の範囲を確かめておく。 評価者が見られる範囲と公表の権利を調べておけば、自社で残すべき受入試験を切り分けられ、「評価あり」を合格の代わりにせずに済みます。

記事に近い課題や、まだ整理できていない段階のご相談も受け付けています。

プロジェクトについて相談する

Discuss a project

INSIGHTS 一覧へ