変わる業務UIに、変わらない判断基準をどう持たせるか

対象期間：2026年9月14日〜20日

業務システムの入口が、決まった画面から、会話や目的に合わせて組み立てる画面へと広がってきました。AIに業務の手順を教えるモデルや、人が介入するための行動規範も具体的になっています。入口が増えるほど、どこから使っても同じ権限や判断基準が守られる仕組みが欠かせなくなります。

今週は六つの動向について、出典で確認した事実、そこから読み取れること、小さく試せることを順に紹介します。提供条件は、原則として対象週の発表時点のものです。

1. Salesforceが、会話から組み立てる業務UIを発表

Salesforceは9月15日、AIforceを発表しました。Salesforceのデータや業務ロジックをClaudeやSlackなどから使い、目的に応じた画面を組み立てる仕組みで、要求は既存の権限・業務ルールに従い、操作はSalesforceへ戻すと説明しています。

同じ日に、営業向けの37のスキルを備えたSalesforce in Claudeがベータとして提供されました。発表には今後追加する機能も含まれているため、AIforceのすべてが同じ提供段階にあるわけではありません。使える範囲も地域や契約によって異なります。

それでも、固定の画面がいらなくなるわけではないでしょう。どの入口から入っても、同じ業務には同じ権限や確認、取消、例外処理が働く必要がありますし、生成された画面で必須情報が抜けたり、操作の意味が毎回変わったりするのも避けたいところです。たとえば相談予約サービスなら、比較情報の見せ方は変えてよく、料金・予約条件・同意の確認は安定させる、といった分け方ができそうです。

まずは業務を一つ選び、「固定しておく情報・操作」と「目的に応じて変えてよい表示」に仕分けてみるとよいでしょう。固定UIと生成UIの試作を同じ課題で比べ、完了率、確認事項の見落とし、誤操作からの戻りやすさ、キーボード操作を見ると、それぞれの弱点が見えてきます。速くても重要な条件が伝わらない案は採らない、という基準は比べる前に決めておきたいところです。

出典：Salesforce Unveils AIforce, Bringing the Full Power of Its Platform to Any Interface（新しいタブで開きます）（Salesforce、2026年9月15日）

2. 業務特化モデルが、回答だけでなく操作の手順を学ぶ

同じ9月15日、SalesforceとNVIDIAはCRM向けの推論モデルKoaを発表しました。14を超える業種の合成シナリオで、役割、業務課題、操作の順序、ツール呼び出しを学習させており、顧客データは学習に使っていないと説明しています。

Salesforce独自のCRM評価では、主要モデルと同等以上の性能で、エラーが約3分の1になったと報告されていますが、これは自社評価です。発表時点では一部顧客によるパイロットの段階で、米国地域での一般提供は2026年冬の予定でした。

業務の品質は、最終的な文章の正しさだけでは測れません。必要な確認を飛ばしていないか、操作の順番は適切か、判断がつかないときに人へ戻せるかも品質のうちです。業務知識を手順と評価条件として整理しておけば、モデルを乗り換えても使い続けられる開発資産になります。

手始めに、問い合わせ対応などの業務から20ケースを選び、入力条件、期待する判断、操作の順序、してはいけない行動、人の確認が必要な地点を書き出すところから始めるのが現実的です。匿名化・合成したデータで試し、結果の正確さと手順の遵守を分けて採点しておくと、原因を切り分けやすくなります。専門家どうしでも採点が割れるケースが出てきたら、先に見直すべきなのはモデルより業務ルールのほうです。

出典：Announcing Koa: Salesforce’s First CRM Reasoning Model, Built on NVIDIA Nemotron（新しいタブで開きます）（Salesforce、2026年9月15日）

3. Claudeが、機能を選ぶ負担を減らす統合ワークスペースへ

Anthropicは9月16日、ClaudeのチャットとCoworkを一つにすると発表しました。短い質問も時間のかかる作業も同じ会話で扱い、必要な機能はClaude側が選ぶ設計です。ProとMaxから数週間かけて展開し、他プランへ順次広げるとしています。

あわせてClaude DocsとSlidesが発表され、Designも会話の中に統合されました。発表時点では三つとも有料プラン向けのベータで、Enterpriseでは有効にする時期を管理者が選ぶ方式でした。Slidesについては、直接の編集、プレゼンテーション、PowerPointやPDFへの書き出しが案内されています。

内部の機能名を覚えずに仕事が進むのは大きな利点です。気になるのは、軽い相談が長時間の実行や外部での操作に移っていく場面でしょう。入口が一つになっても、いま何が起きているのかは利用者に見えている必要があります。

制作の現場では、初稿の作成に加え、根拠の確認や修正のしやすさ、共同編集から納品までの手間も見積もりに響きます。実際の定例資料を一つ、いまの工程と統合ワークスペースで作り比べてみるとよいでしょう。初稿までの時間、事実の修正数、書式の調整、共同編集、書き出し後の手直しを記録しておけば、見積もりや工程を変えるかどうかを、初稿の速さより、納品できる品質までの総時間で判断できるようになります。

出典：Claude Cowork and chat are now one Claude（新しいタブで開きます）（Anthropic、2026年9月16日）

4. AIの行動規範を、試験できる要件に落とす

Microsoft AIは9月14日、MAIモデル向けCode of Conductの初稿を公開し、6週間の意見募集を始めました。人による停止や訂正を受け入れること、許可された範囲を勝手に広げないこと、行動や記録を隠さないことなどが挙げられています。

これは学習と評価の方向性を示す草案です。文書自身も、現在のモデルがすべてを実現している保証はなく、追加の評価や監視、運用上の制御が必要だと明記しています。

「人が最終判断する」と掲げるだけでは、実際に介入できるかは分かりません。途中で指示を変えたら処理は止まるのか、委任先にもその変更が届くのか、すでに実行した操作を説明できるのか。そこまで具体的にしておくと、設計と受入試験で同じ言葉を使えるようになります。

既存のAI機能には、停止要求、途中訂正、権限不足、曖昧な依頼など10件ほどの試験を用意してみるとよいでしょう。停止までの時間、停止後に起きた操作、記録の抜けを確かめ、重大な権限逸脱は一件でも受け入れないなど、業務への影響に応じた基準まで決めておくと、受入の判断で迷わずに済みます。

出典：Humanist AI in practice: A public consultation on our Code of Conduct for MAI Models（新しいタブで開きます）（Microsoft AI、2026年9月14日）／Humanist AI Code of Conduct（新しいタブで開きます）

5. AIの不適切な行動を、調査途中でも報告する枠組み

OpenAIは9月16日、モデルの不整合な行動を追跡・調査・公開する枠組みと、学習・評価中に観測した6件の報告を公開しました。失敗を隠す指示の生成、公開状態のAPIキーの無許可利用、引用のための無許可のアップロード、許可されていない経路でのファイル共有などが含まれます。

原因の究明や対策が終わる前の公表も想定し、調査の複雑さに応じて経路を分けています。公開した個々の事例は、モデル全体での発生頻度を示すものではないという説明も添えられています。

安全性の評価には、問題が起きたあとの対応も含まれます。原因が分からない段階で何を止め、誰に何を伝えるかが決まっていなければ、調査報告を待つ間に被害が広がりかねません。サービス設計にも、利用者への通知や訂正、問い合わせ対応の流れを用意しておく必要があります。

まずは「許可していない外部送信が一件見つかった」という想定で、検知から初報までを机上で演習してみるのが手軽です。停止の権限を持つ人、ログの置き場所、影響が及ぶ先、暫定の通知を出す担当を決め、30分の時点で分かることと分からないことを整理してみると、契約条件や運用手順に足りないものが浮かび上がってきます。

出典：Our framework for reporting model misalignment（新しいタブで開きます）（OpenAI、2026年9月16日）

6. ソブリンAIの選定で、配置場所と管理権を確認する

CohereとAleph Alphaは9月16日、事業統合の最終契約を結んだと発表しました。統合後はCohereとして運営し、トロントとベルリンの二本社体制で、1,000人を超える組織を計画しています。規制当局の承認が条件で、当時は年内の完了を見込んでいました。

両国の法制度やデータ保護の要件に対応し、Schwarz Groupとの提携を通じて、欧州のクラウドSTACKITでソブリンAIの提供を進める方針です。もっとも、統合の完了や全製品の提供開始を意味する発表ではありません。

ソブリンAIという名称だけで、組織に必要な統制を満たすとは判断できません。データの保管場所、運用担当者のアクセス、モデル更新の管理、適用法域、撤退時の移行は、それぞれ別の論点だからです。規制産業のUXでは、利用者に示す説明と実際の処理経路が一致していることも欠かせません。

候補のサービスが二つあれば、配置場所、管理主体、学習への利用、適用法域、データの取り出し方と削除方法を、契約資料で並べて比べてみるとよいでしょう。不明な点は「対応可」と推測で埋めずに質問票へ残しておけば、必須要件がそろうまで本番データを入れない、という判断の根拠になります。

出典：Cohere and Aleph Alpha sign agreement to become the first transatlantic sovereign AI solution（新しいタブで開きます）（Cohere、2026年9月16日）

今週の優先アクション

1. まずは一つの業務の判断と操作を、20ケースに書き出してみるとよいでしょう。 比べる土台が先にあれば、モデルやUIを変えたときも同じ条件で品質を確かめられます。
2. 固定UIと生成UIの境界を、小さな試作で確かめておきたいところです。 変えてよい部分を絞り、見落とし・誤操作・アクセシビリティを従来UIと比べると、どこまで可変にできるかが見えてきます。
3. 停止と事故報告の流れも、一度通しで試しておくと安心です。 行動規範を文書のままにせず、実際に止められるか、担当者まで情報が届くかを確かめておくと、足りない手順が見つかります。