AIの導入効果を、個人の作業短縮から組織の成果へ

対象期間：2026年10月5日〜11日

AIを使えば、資料や画面、コードを短時間でつくれるようになりました。とはいえ、一つひとつの作業が速くなっても、サービスの改善や事業の成果がそのぶん早く届くとは限りません。レビューや承認で待ち時間が生まれたり、確認作業が増えたりすれば、制作段階で縮めた時間は後ろの工程で消えてしまいます。

今週は、業務フローの再設計、AI開発の品質管理、デザインシステムの保守、職種を横断する学習など、導入したAIを組織の仕事に組み込もうとする動きが目立ちました。端末内とクラウドを使い分けるAIの発表も、情報の扱い方や利用者の同意をどう設計するかという課題につながっています。

話題ごとに、発表の内容、そこから読み取れること、現場で試せることの順にたどっていきましょう。

1. 個人の生産性向上を、業務全体の成果につなげる

McKinseyは10月5日公開の記事で、同社の2026年AI調査を引用しました。AIによる個人の生産性向上を報告した回答者が80％だった一方で、EBIT（利払い・税引き前利益）へのプラス効果を報告した割合は37％でした。また、同社が高成果企業に分類した組織では約4分の3が業務フローを大幅に再設計したと答えており、その他の組織ではその割合が約4分の1でした。

いずれも回答者の申告に基づく結果で、再設計と高い成果の関連は示していても、再設計だけが成果を生んだと証明するものではありません。なお、10月5日は記事の公開日で、調査の実施日ではありません。

80％と37％の差を見ると、AI導入の効果を何で測るのかを考え直したくなります。担当者が節約できた時間だけでなく、後の工程まで含めて仕事がどう変わったかを見ておきたいところです。たとえば画面設計の時間が半分になっても、仕様の確認に数日かかり、実装後に認識のずれが見つかるようなら、公開までの期間はあまり変わらないかもしれません。制作の速さと業務全体の速さは、分けて考えたほうがよさそうです。

そう考えると、デザインやDXの対象は画面だけではありません。誰が何を確認し、どの情報で判断し、次の担当者へ何を渡すかという仕事の流れも含まれます。

まずは一つの機能改善を取り上げ、企画から公開までの工程を並べて、それぞれの「作業時間」「待ち時間」「手戻り」を書き出してみるとよいでしょう。そのうえで、最も長い待ち時間を生んでいる箇所を一つ選び、確認資料や承認手順を少しだけ変えてみるのが現実的です。前後で公開までの日数が縮んだか、手戻りや利用者の問題が増えていないかを比べれば、どこに手を入れると効くのかが見えてきます。

出典：McKinsey
AI is changing work. Now it has to change the organization（新しいタブで開きます）（2026年10月5日）

2. AI開発では、生成したコードを公開するまでの仕組みが問われる

GitLabは10月6日、企画から本番公開までを組織の方針と基準に沿ってつなぐ「Governed Software Factory」の基盤を発表しました。工程間の作業をつなぐエージェント機能、成果物管理、問題のある依存パッケージの制御、AIの費用と成果を把握する分析機能などを含みます。

提供段階は機能によって異なります。成果物管理のGitLab Artifact CentralはGitLab.comでベータ提供中で、Self-Managed版は同月後半の予定です。Duo Agent Platform Impact Analyticsは早期アクセスの段階にあり、セキュリティ対策の評価基準であるGitLab Security Standardは発表時点で利用可能とされています。

AIで実装量が増えれば、レビューやテスト、承認の仕事も増えます。コードを書く工程だけを自動化すれば、確認の負荷が後ろの工程へ移るだけになりかねません。今回の発表は、生成から公開までを一続きの工程として扱おうとする方向を示しています。もっとも、ツールを入れれば製品ごとの品質基準まで決まるわけではありません。

UXの立場から言えば、公開の判断には処理が成功するかどうかに加えて、失敗したときに戻れるか、操作できない人を生んでいないか、利用者が次に何をすればよいかわかるかも含めておきたいところです。

実際に試すなら、AIで実装する機能を一つ選び、着手前に受入条件を書き出すところから始めるのが現実的です。フォームであれば、入力エラー、通信失敗、二重送信、キーボード操作、フォーカス移動などが確認の対象になります。変更内容にテスト結果と承認者をひも付け、レビュー時間や差し戻し回数、公開後の不具合を記録しておけば、確認の負荷が増えていないかもわかります。生成は速くなったのに負荷が増えているなら、自動化する範囲を見直す時期です。

出典：GitLab
GitLab Announces the Foundation for the Governed Software Factory（新しいタブで開きます）（2026年10月6日）

3. 端末内とクラウドを使い分けるAIは、情報と権限の設計を変える

Microsoftは10月7日、端末内とクラウドのAIを組み合わせるWindowsの「Hybrid Intelligence」を発表しました。用途に応じた処理の振り分けに加え、端末内の情報参照や操作を扱う構想も示しています。

GitHub Copilotアプリ、CLI、Visual Studio Code向けの関連機能は10月後半に実験的プレビューの予定で、Copilot+ PC向けの関連機能も今後数か月で展開を始める予定です。利用条件や時期は端末、市場、ハードウェアによって異なり、10月7日の時点で全面提供されたわけではありません。

こうした仕組みが広がれば、企業向けAIを選ぶ際には、回答の性能に加えて、どの情報をどこで処理するかも判断材料になります。端末内で扱うべき情報とクラウドを利用してよい情報を、業務ごとに整理しておく必要が出てくるでしょう。

影響は利用者の体験にも及びます。ファイルの参照を許可したからといって、その内容を外部へ送ることや、ファイルを書き換えることにまで同意したとは言えません。「AIの利用を許可する」という一つの設定にまとめると、この違いが見えなくなります。参照、送信、実行を区別して理解できる体験をどうつくるかが、設計の課題になります。

手始めに、ファイルを扱うAI機能を一つ選び、参照する情報、外部へ送る情報、実行する操作を一覧にしてみるとよいでしょう。その内容を確認できる画面を試作し、想定利用者に「何を許可したか」「どこへ情報が送られるか」「実行を止めるにはどうするか」を説明してもらうと、伝わっていない箇所がはっきりします。そこを直したうえで、権限を与えない場合でも仕事を続けられるかまで確かめておきたいところです。

出典：Microsoft
Building Windows for hybrid intelligence（新しいタブで開きます）（2026年10月7日）

4. デザインシステムの維持に、AIを組み込む方法が具体化する

Figmaは10月6日、エージェントを使ったデザインシステムの保守方法を公開しました。仕様書の下書き、命名の統一、デザイントークンの使用状況の点検、既存コンポーネントへの置き換えなどが紹介されています。事例として、Uberではコンポーネントの仕様説明や色の仕様の作成、Granolaでは取り込んだ画面の部品を既存のデザインシステムへ対応させる取り組みが挙がっています。いずれもFigmaによる事例紹介で、一般的な削減効果を示す独立した比較試験ではありません。

利用には条件があります。記事の時点では対象プランのFull seatを中心に利用可能とされ、Starterプランは限定提供、Collab・Dev・View seatでは下書き内で利用できる、といった形です。

デザインシステムは、部品がそろえば完成というものではありません。製品の変化に合わせて仕様を更新し、例外を判断し、画面と実装のずれを直し続ける必要があります。AIが役に立つのは、人が見落としやすい不整合を探し出し、判断が必要な箇所を絞り込む場面です。とはいえ、見た目が似ていても用途や操作上の意味が違う部品はあり、何でも機械的にそろえればよいわけではありません。どこまで共通化し、どの例外を残すのか、その理由を説明できることが、保守を自動化するうえでも土台になるはずです。

手軽なのは、代表的な3画面を複製し、既存コンポーネントとの対応、色や余白の直書き、命名の不一致を点検するところから始める方法です。最初は自動修正をせず、検出結果を人が確認する運用にしておくと安心です。検出数、誤検出、見逃し、確認と修正にかかった時間を記録し、置き換えたあとの状態表示やコントラストまで確かめておけば、見た目の統一と使いやすさを両立できているかを判断する材料がそろいます。

出典：Figma
How to lighten design system upkeep with the Figma agent（新しいタブで開きます）（2026年10月6日）

5. AIの学習は、操作方法から成果を判断する力へ

Figmaは10月10日、Figma、Sephora、Mercari、AtlassianのAI学習に関する取り組みを紹介しました。Figmaでは関心のある技能ごとに少人数の学習グループをつくり、週1時間・6週間の実践を行っています。Sephoraは、完成品中心の発表から、試した過程や失敗も共有する形式へ切り替えました。Mercariでは、デザイナーが開発の基礎を、開発者が視覚的な優先順位などデザインの基礎を学ぶ取り組みが紹介されています。記事は各社の実践報告で、研修方法の優劣を比べた研究ではありません。なお、10月10日は紹介記事の公開日です。

AIのおかげで専門外の成果物をつくりやすくなっても、その品質を見極める知識まで一緒に身につくとは限りません。デザイナーが動く画面をつくれたとしても、保守性や権限管理を確かめるには開発の知識が要りますし、開発者がUIを生成した場合も、情報の優先順位や利用者に伝わるかを検証する視点が欠かせません。

チームで学ぶときは、使い方を教え合うだけでなく、「何を良いとするか」「どこから専門家の確認が必要か」までそろえておきたいところです。

取り入れやすいのは、定例の15分を使って、AIでつくった成果物を別の職種の人にレビューしてもらう方法です。完成品だけでなく、最初の出力、見つかった問題、直していった過程も一つずつ見せ合い、次の担当者が同じ方法を再現できたか、同じ問題に早く気づけたかを確かめてみるとよいでしょう。参加人数や発表回数だけでなく、再利用できた判断基準も学習の成果として残しておくと、次につながります。

出典：Figma
4 team rituals that drive AI adoption（新しいタブで開きます）（2026年10月10日）

今週の優先アクション

1. まずは一つの業務で、作業時間と待ち時間を記録してみましょう。
   最初に手をつけたいのは現状の把握です。改善前の状態がわからなければ、AIが成果を生んだのか、負荷を別の担当者へ移しただけなのかを判断できません。
2. AIでつくる機能の受入条件は、着手前に決めておきましょう。
   正常に動くかどうかに加えて、失敗時の復帰、権限、アクセシビリティ、確認の責任まで整理しておけば、公開直前の手戻りを減らすことにつながります。
3. 既存の3画面で、デザインシステムの監査を試してみましょう。
   対象を絞って、検出の精度と人の確認時間を測ってみるとよいでしょう。新しくつくる速さだけでなく、維持管理の負担が軽くなるかどうかも見えてきます。