おはようございます！！今日も、AIが私たちの働き方をどう変えていくのか、最新のニュースをやさしく解説していきます。今日は「AIと人がどう組んで働くか」というテーマの話題が特に多く集まりました！
monday.comが「AIエージェント前提」のサービスへ作り替え、その学びを公開
仕事の進行管理ツールで知られるmonday.com（プロジェクト管理サービスの大手）が、自社のサービスをAnthropicのClaude（対話型AI）を軸に作り直し、人とAIエージェント（人の代わりに手を動かすAI）が一緒に仕事をする前提の製品へと切り替えました。その移行の過程で得た学びを、Anthropicのブログで共有しています。
「AIを機能のひとつとして足す」のではなく、「AIが最初からいる前提で作り直す」という発想の転換ですね。私たちの日常業務でも、AIを既存のやり方の脇に置くのか、業務の組み立て方そのものを変えるのかで、得られる効果は大きく変わってきそうです。
AnthropicがAIの学び方を教える「Claude Academy」を立ち上げ
AnthropicがClaude Academyという学習の場を立ち上げました。これは、AIを効果的に使うための方法を学べる教育ツールを提供するものです。同社のブログでは、なぜこれを立ち上げるのか、そして自分たちが「教えること・学ぶこと」をどう考えているかが、この取り組みの設計にどう影響したのかが語られています。
AIツールって、とりあえず触ってみればなんとなく使えてしまうんですよね。でもその「なんとなく」のままだと、本当は届くはずの成果に手が届かないままになりがちです。新しいツールを手探りで覚えるだけでなく、提供されている学習の入り口を使って体系的に学ぶ。これが遠回りに見えて、いちばんの近道かもしれません。
出典：Anthropic
https://claude.com/blog/anthropics-approach-to-teaching-and-learning-ai
コードを書かずに機械学習、AWSがSnowflake連携の手順を公開
AWS（アマゾンのクラウドサービス）が、コードを書かずに機械学習（データから予測を作る技術）のワークフローを組み立てる方法を、全3回の連載記事として公開しはじめました。今回はその第1回で、AWSアカウントの設定や、データ基盤であるSnowflake側でのデータベース作成、2020年のサンプルデータの準備、接続に必要な組織アカウント名の取得手順といった、下ごしらえの部分が解説されています。第2回でSnowflakeとAmazon SageMaker Canvas（コードを書かずに予測モデルを作れるツール）をつないで不正検知モデルを作り、第3回でその予測結果をダッシュボードにして関係者と共有する、という流れだそうです。
この記事が想定しているのは、ヘルスケアや小売、ライフサイエンス（生命科学）のように、日々の業務データが大量にたまっている組織です。データは十分あるのに、それを予測に変えようとすると専門チームへの依頼が必要で、開発サイクルが長くなってしまう。結果として、データをいちばんよく理解している現場の担当者が試行錯誤できない状態が生まれていた、というのが出発点になっています。
ここで見えてくるのは、専門部署への依存を減らす働き方のヒントです。データの中身を肌感覚でわかっているのは、たいてい現場の人ですよね。その人が自分の手で仮説を試せるようになると、判断のスピードが変わってきます。「専門じゃないから頼むしかない」と諦めていた領域が、少しずつ自分の手元に戻ってくる時代なのかもしれません。
出典：AWS Machine Learning Blog
https://aws.amazon.com/blogs/machine-learning/build-a-no-code-ml-workflow-with-snowflake-amazon-sagemaker-canvas-and-amazon-quick-part-1-setting-up-your-snowflake-environment/
AIエージェントを全社に広げるコツは「基盤だけ揃えて現場は縛らない」
同じくAWSのブログから、大きな企業でAIエージェントを全社規模に広げるときの設計の話です。こちらは、大規模なマルチエージェントシステムをテーマにした連載の第2回にあたります。組織が大きくなるほど、チームごとに違う枠組みや違うAIモデル、違う提供元を使うようになり、複数のものが混ざり合った環境になっていくものです。ここで「全部このやり方に統一しなさい」と無理に押しつけると、多くの場合に摩擦が生まれます。現場が抜け道を探しはじめたり、導入が止まったり、承認されていない構成が勝手に育っていったり、といった具合ですね。かといって、特定のモデルや提供元にがっちり結びつけてしまうと、状況が変わったときに動けなくなる。どちらに倒れても失敗しやすいわけですね。
そこで提案されているのが、ガバナンス（統制）や可視性、振り分けといった共通の制御部分は揃えつつ、実際に何を使って動かすかは柔軟に残すという考え方です。具体的には、Amazon SageMaker（機械学習の開発・実行基盤）でモデルの調整や推論の実行を標準化し、Amazon Bedrock（さまざまなAIモデルをまとめて使えるサービス）で基盤モデルへ素早くアクセスできるようにする。こうしてAWSのサービスを組み合わせることで、特定の枠組みに固定されない形で拡張できる構造をつくれる、という話です。
これ、技術の話に見えて、実は組織のルールづくりそのものですよね。全部を細かく決めきると現場が窮屈になり、何も決めないとバラバラになる。土台のところだけ共通にして、やり方は現場に委ねる。チーム運営や業務プロセスの設計を考えるときにも、そのまま応用できそうな発想です。
出典：AWS Machine Learning Blog
https://aws.amazon.com/blogs/machine-learning/scaling-agentic-ai-enterprise-patterns-without-vendor-lock-in/
Googleが「このメディアを優先」ボタンを提供、AI検索によるアクセス減に対抗
TechCrunchの報道によると、Googleが記事を出しているメディア向けに新しい仕組みを用意しました。読者が「このメディアを優先的に表示してほしい」と設定できるボタンで、検索だけでなくDiscover（おすすめ記事が流れてくる機能）やGoogleニュースにもまたがって効くそうです。AI検索の広がりでウェブサイトへ送られるクリック数が減っているなか、この機能はメディア側のアクセスを押し上げる可能性があるとされています。
技術の変化で自分たちの前提が崩れることって、どの仕事にもありますよね。大事なのは、その変化が自社にどう影響するかを先回りして考えて、差し出された新しい手段を素早く試してみる姿勢なのかもしれません。ルールが変わったとき、嘆く前に「使える手は何か」を探せる人は強いです。
出典：TechCrunch
https://techcrunch.com/2026/08/20/google-gives-publishers-a-new-way-to-fight-ai-driven-traffic-losses/
検索やLLMは発想を狭める？「探索型」に変えたら専門家の創造性が11%向上
MIT Sloan Management Reviewに、なかなか考えさせられる研究が載っていました。検索や大規模言語モデル（LLM、大量の文章を学んで会話できるAI）といったツールの多くは、人気があって関連性の高い結果を優先する「活用」型の考え方で設計されています。つまり、その人がすでに知っていることを補強する方向に働きやすいんですね。すると、似た発想ばかりが集まる「アイデアバブル」が生まれてしまう。しかもやっかいなのは、中にいる人には気づけないことです。それぞれ独立に考えているつもりでも、みんなが同じツールを使っているせいで、同じ答えのあたりへ静かに誘導されていく。
研究チームは、人気順ではなく意味的に離れたかたまりから結果を出す「探索」型の仕組みを作り、2つの実験で比べました。104人が参加した実験室での検証では、探索型を使ったアイデアが通常のGoogle検索より14%創造的だと評価されました。さらに興味深いのは、サステナビリティ分野の初心者から熟練の専門家まで245人が参加し、家庭の食品ロス削減のアイデアを競った実地の実験のほうです。標準的な検索を使ったときは専門家と初心者の成果に統計的に意味のある差が出なかったのに対し、探索型のツールを使うと専門家が初心者を明確に上回り、アイデアの創造性は平均11%向上したそうです。専門家は、畑違いの情報を見ても「どれが使えて、どれが行き止まりか」を見分け、既存の知識と組み替えられる土台を持っている。だから多様な材料が届いたときに、その強みが初めて発揮されるというわけですね。
ここから学べることは2つあります。ひとつは、アイデア出しの段階でAIの定番回答に頼りきらないこと。異分野の視点や予想外の情報をあえて求めるような聞き方をすると、思考が同じ方向へ固まるのを防げます。もうひとつは、AI時代でも専門知識の価値は落ちないということ。むしろ、ツールが運んでくる多様な情報を正しく評価して組み替える力こそが、これからの武器になりそうです。
出典：MIT Sloan Management Review
https://sloanreview.mit.edu/article/algorithms-trap-us-in-the-familiar-can-they-also-spark-breakthroughs/
NVIDIAが検証、開発者向けの資料やツールをAIエージェントはどこまで使えるか
NVIDIA（半導体・AIチップの大手メーカー）のブログから、開発現場に近い話題です。同社のHoloscanは、医療の画像処理からロボットまで、現場に近い場所でリアルタイムに動くAIアプリを作るための土台となるプラットフォームです。関連する公開リポジトリのHoloHubには、参考になるサンプルアプリや部品が集められています。今回の記事では、そうしたエンジニア向けのサンプルやドキュメント、開発ツールを、特定用途に特化していない汎用のコーディングエージェント（コードを書く作業を代行するAI）がどこまで活用できるのかを検証しています。
自分たちが用意した資料やツールが、AIから見て「使いやすい形」になっているかを確かめる。これって、実は人に対しても同じことが言えますよね。手順書やマニュアルが読み手にとって使える形になっているか。AIに任せられるかどうかを試してみると、人にとってのわかりやすさも一緒に見えてくるのかもしれません。
出典：NVIDIA Developer Blog
https://developer.nvidia.com/blog/developing-nvidia-holoscan-applications-with-cli-skills-and-ai-coding-agents/
Grokから個人情報が流出する攻撃手法、6月に通知されたが公開時点でも有効
少しヒヤリとするニュースです。Ars Technicaによると、研究チームが暗号化された指示を使ってGrok（イーロン・マスク氏が率いるxAIの対話型AI）にユーザーのチャット内容や個人情報を流出させる攻撃手法を考案しました。xAIには6月に通知が届いていたものの、記事が公開された時点でもデータが漏れる状態が続いていたとのことです。実は今週初めにも、別の研究チームが企業向けのMicrosoft 365 Copilotに対して、受信トレイの中にあるパスワードを引き出させる似た攻撃を報告しており、これはGrokだけの問題ではありません。
背景にあるのは、プロンプトインジェクションと呼ばれる根深い弱点です。LLMは、外部から届いたメールやウェブページに書かれた文章と、利用者が自分で打ち込んだ指示とを、確実に見分けることができません。そのため、要約を頼まれたメールの中に悪意ある指示が紛れ込んでいると、AIは律儀にそれに従ってしまうんですね。記事では、この根本原因はLLM側では解決できず、開発者には怪しい指示を見つけて実行を禁じるガードレール（安全柵）を設けるくらいしか手が残されていない、と指摘されています。カーブそのものを設計し直すのではなく、危ない曲がり角の外側に柵を立てるようなもの、という例えも紹介されていました。
仕事でAIアシスタントを使う私たちにとって、ここは押さえておきたいところです。AI側の安全対策を過信せず、パスワードや機密情報を含むデータをAIに処理させない。この線引きは、ツールの性能とは関係なく、使う人自身が引くしかありません。便利さと引き換えに何を渡しているのか、一度立ち止まって確認しておきたいですね。
出典：Ars Technica
https://arstechnica.com/security/2026/08/grok-exfiltrates-user-data-when-malicious-instructions-are-encrypted/
AIエージェントの「スキル」は本当に効くのか、NVIDIAが測る手法を提示
こちらもNVIDIAのブログからです。AIエージェントは、受け取ったコンテキスト（前提となる状況や情報）の質を超えては働けない、という指摘から記事は始まります。能力の高いモデルを使い、十分なドキュメントが揃ったライブラリを用意していても、エージェントは適切なツールを探すのに余計な手順を踏んだり、行き止まりでトークン（AIが処理する文字のかたまり）を無駄に消費したり、専門的な作業でつまずいたりするそうです。
そこで登場するのがスキルという考え方です。指示と例、そしてツールの使い方の案内をひとまとめにしておくことで、エージェントが「やりたいこと」から「解決の手順」へ素早くたどり着けるようにする。記事では、こうしたスキルが本当にエージェントの性能を上げるのかを測る手法が扱われています。
これ、AIに限った話ではないですよね。人に仕事を頼むときも、「これやっておいて」だけでは相手が探し回ることになります。目的だけでなく、具体的な手順や過去の事例といった背景情報まで整理して渡す。その一手間が、結果的にいちばん速い。AIに指示を出す練習は、そのまま人への依頼の練習にもなっているのかもしれません。
出典：NVIDIA Developer Blog
https://developer.nvidia.com/blog/evaluating-ai-agent-skill-performance-with-nvidia-skillevaluator/
今日のまとめ ~ AIと組むなら、渡す情報と引く境界線がカギ
今日のニュースを並べてみると、共通のテーマが浮かび上がってきました。monday.comの作り直しも、NVIDIAのスキル評価も、AWSの設計論も、結局は「AIに何をどう渡すか」の話なんですよね。そしてMIT Sloan Management Reviewで紹介された研究とGrokの流出問題は、渡し方を間違えたときに何が起きるかを、それぞれ別の角度から教えてくれています。
これからの時代、大切なのは、
AIが賢くなるほど、私たちに求められるのは「任せ方の上手さ」になっていきます。丸投げでも抱え込みでもない、ちょうどいい距離感を探していきたいですね。今日も良い一日を！