おはようございます！今日はAIをどう「使いこなす側」に回るか、というテーマが自然と浮かび上がる7本が集まりました。研修のやり方から、AIに任せた仕事の安全確認まで、現場で効いてくる話ばかりです。さっそく見ていきましょう！
Atosが400人のエンジニアを「ゲーム形式」でAI人材に育てた話
ITサービス大手のAtosが、AWS Machine Learning Blogで公開した事例が興味深いです。同社はAWSと組んで、400人のエンジニアを対象に3日間の「agentic AI League」というイベントを開催しました。エージェント型AI（人間が細かく指示しなくても、自分で手順を考えて作業を進めるAI）を、講義ではなく手を動かして学んでもらう取り組みです。
参加者のレベルはバラバラでした。AWSの経験があるエンジニアもいれば、初めて触る人や、プロダクトオーナー・プロジェクトマネージャーといった技術職以外の人も混ざっていたそうです。エージェント型AIについて「まったく知らない」が5%、「聞いたことはある」が25%、「理解はしているが手を動かしたことはない」が50%、「実務経験あり」が20%という内訳でした。そんな面々が3日間で、ダンジョンの迷路を攻略するマルチエージェントシステム（複数のAIが役割分担して動く仕組み）を組み上げます。Amazon BedrockやAWS Lambdaといった実務でも使うサービスを使い、成績はリーダーボードに公開されて競い合う形式です。
面白いのは、採点が「正解できたか」だけではなかった点です。処理時間やコスト効率も点数に反映されるため、動くものを作った時点はまだスタートラインで、そこから無駄をそぎ落とす作業が本番になったといいます。ガードレール（AIに不適切な出力をさせないための制限）の設定も、厳しすぎると別の課題が解けなくなり、緩すぎると危険な出力を止められない、というジレンマを実地で味わったそうです。学びを実務に結びつけたいとき、「制約つきで競わせる」という設計は、私たちの職場の勉強会にもそのまま応用できそうですね。
出典：AWS Machine Learning Blog
https://aws.amazon.com/blogs/machine-learning/from-theory-to-delivery-how-atos-upskilled-400-engineers-in-agentic-ai/
テストは全部合格、でも「見えてはいけない書類」を答えていたAIアシスタント
VentureBeatが報じた、ちょっと背筋が寒くなる話です。イタリア・ミラノのMicrosoftパートナー企業SynSphere ItaliaのEgiziago Cioffi氏が、Azure OpenAIを使った社内向けのメール対応アシスタントを自作しました。SharePoint（社内の書類を共有・保管する仕組み）とつなぎ、受信メールの約6割を自動で処理できるところまで仕上げ、社内の評価テストも単体テストもすべて合格していたそうです。
ところがCioffi氏が、権限の低いアカウントで同じ質問を投げてみたところ、権限の高いアカウントのときと答えが食い違いました。本来その人には開けないはずのSharePointの中身を、アシスタントが平然と答えてしまっていたのです。原因は、自作した検索の仕組みが、検索する時点で「この人にこの書類を見せていいか」を確認する工程を通っていなかったことでした。AIが「書類を集めた側の権限」で答えてしまい、「質問した人の権限」で答えていなかった、という構図ですね。
対策そのものは大がかりではなく、質問された時点で利用者の権限を確認するフィルターを1つ足しただけ。もちろん代償はあって、これまで答えに使えていた資料のうち、質問した人の権限が届かないものは対象外になりました。それでも、その後もアシスタントは受信メールの約6割を自動で解決し続けているそうです。ここから学べるのは、AIツールの「答えの正しさ」を測るテストだけでは、権限の穴は見抜けないということ。立場や権限の違うアカウントで同じ質問をして、答えが変わるかどうかを比べる。この一手間を入れるかどうかで、安心して使えるツールになるかが決まりそうです。
出典：VentureBeat
https://venturebeat.com/security/azure-openai-agent-passed-every-evaluation-served-files-user-couldnt-open
古いシステムの刷新を、AIで6割の時間短縮。医療保険大手Bupaの現場
MIT Technology Reviewのポッドキャスト「Business Lab」の書き起こし記事から。これはInfosysとの提携で制作されたコンテンツで、医療保険大手BupaのCIOであるAsifa Sherazi氏と、InfosysのSanjeev Tripathi氏が、古くなったシステムの刷新について語っています。
Bupaが取り組んだのは、自社アプリをXamarin（かつて使われていたアプリ開発の仕組み）から、iPhone向けのSwiftとAndroid向けのKotlinという、それぞれの端末に最適化された言語へ作り直すことでした。ここでAIを活用した手法を組み込んだ結果、AIがなかった時代と比べておよそ6割少ない時間で移行を終えられたそうです。効果は数字にも出ていて、アプリの評価は3.7から4.7へ上昇。利用者が体感するクラッシュ率はAndroidで約24ポイント、iOSで8ポイント下がりました。
ただ、お二人が強調していたのは技術の話だけではありません。古い技術を扱える人材が年々減っていくこと、つまり「動いているから」と放置するほど、直せる人がいなくなっていくという現実です。そして刷新の場面では、社内に蓄積された知識をどう引き継ぐか、チームが新しい環境に慣れる余裕をどう作るかという、人にまつわる部分が欠かせないと語られていました。AIで作業時間が浮くというのは、その浮いた時間を人の適応やお客さんの体験づくりに回せる、ということなんですね。
出典：MIT Technology Review
https://www.technologyreview.com/2026/09/01/1142180/making-the-ai-powered-case-for-legacy-modernization/
AIが人の承認なしに2000万件の支払い。それでも成立させた「役割分担」
AWS Machine Learning Blogが紹介した、t54という企業の事例です。AIエージェントは調べものも段取りも自分でこなせますが、有料のサービスにぶつかった瞬間に止まってしまいます。財布もカードも持っていないからです。t54はそこを解決する「信頼層」として、Amazon Bedrock AgentCore payments上に「x402-secure」という仕組みを作りました。
すでに2000万件を超えるエージェント発の決済を、人が1件も承認しないまま処理しているそうです。ただし1件あたりは0.001〜0.01ドルという極小額。そもそも、この速さと量を人が目視で確認するのは不可能だ、という前提に立った設計です。とはいえ野放しではありません。支払う前に相手先を評価して、危なそうなら決済を止める「トラストゲート」が働きます。判断材料は、支払い先の取引履歴やページの正当性、SNS上の実績、APIの稼働状況など複数の信号を組み合わせたもので、1つの弱い信号だけで支払いが通ることはない設計になっています。
注目したいのは、権限をきっちり分けている点です。使う上限を設定する役割と、実際に支払いを実行する役割が分離されていて、エージェント自身が自分の上限を書き換えたり、鍵に直接触ったりはできません。上限を使い切ればそこで止まり、自分で補充する道もない。人に仕事を任せるときの「決裁権と実行権を分ける」という発想が、そのままAIにも当てはまるということですね。AIに任せる範囲を広げるほど、任せ方の設計が腕の見せどころになりそうです。
出典：AWS Machine Learning Blog
https://aws.amazon.com/blogs/machine-learning/how-t54-built-a-trust-layer-with-amazon-bedrock-agentcore-payments/
OpenAIの新モデル「Astra」はシステム侵入が得意。公開前に安全対策を先出し
TechCrunchによると、OpenAIが近く公開予定の大規模言語モデル「Astra」について、自社が講じている予防措置を先に公開しました。Astraは、OpenAIが定める「サイバーセキュリティの危険水準」に達した初めての大規模言語モデルとされ、コンピュータの未知のセキュリティ上の弱点を、人の指示なしに見つけて突くことができるとのことです。安全対策を公開前に出したのは、それだけの力を持つモデルだから、ということですね。ただしTechCrunchは、第三者による検証がないため、OpenAIの安全性に関する説明を評価するのは難しいとも指摘しています。強力な道具ほど、使い方の作法も一緒に届ける必要がある。新しいAIを仕事に取り入れるときは、何ができるかと同じくらい、提供元が何に気をつけているか、そしてそれを誰が確かめたのかを読んでおきたいですね。
出典：TechCrunch
https://techcrunch.com/2026/09/01/open-ais-astra-model-is-on-the-way-and-very-good-at-breaking-into-computer-systems/
機密ファイルはMacから出さない。Perplexityの「ハイブリッド」という答え
VentureBeatが報じたPerplexityの新機能が、なかなか実務的です。同社のエージェント型プラットフォーム「Computer」に、クラウド上の高性能モデルと、手元のMacで動く小さめのモデルとで作業を分担させる「ハイブリッドコンピューティング」が追加されました。機密データに触れる部分は手元のMacで処理し、端末の外に出さないという発想です。
要になるのは「プライバシーゲート」と呼ばれる仕組みで、端末上で動く判定器が、名前・住所・口座番号といった個人を特定できる情報をクラウドに送る前に検知します。引っかかったときは、その部分をローカルで処理するか共有するかを利用者が選べる形です。同社によれば、クラウドで始めた作業の機密部分だけを、やり直しも文脈の喪失もなく手元のモデルへ引き継げるのは初めてとのこと。デモでは、弁護士が手元の機密ファイルを参照しながら書面を更新する一方、クラウド側は公開されている判例を調べる、という並行作業が示されました。
利用にはmacOS 15以降のApple silicon搭載Macが必要で、オプトインした企業顧客とPro/Max加入者が対象。手元で動かすモデルはGoogleのGemmaやAlibabaのQwenベースのものから選べますが、メモリ32GB以上といったハードウェア要件もあり、誰の手元でもすぐ動くわけではありません。それでも、法務・金融・医療のように「クラウドに送れないから、AIを使えない」と諦めていた仕事に道が開ける可能性はありますね。企業の管理者が組織全体の基準を決め、何が端末の外に出たかの記録を確認できる点も、導入を検討する側には効いてきそうです。
出典：VentureBeat
https://venturebeat.com/orchestration/your-files-stay-put-perplexitys-hybrid-ai-keeps-confidential-data-off-the-cloud
AIが「研究者」として働き始める、その手前の風景
NVIDIA（半導体・AIチップの大手メーカー）の開発者向けブログが、エージェント型AIが研究のやり方を変えつつある、と書いています。論文を読み、仮説を立て、モデルを呼び出し、次にどの実験を優先すべきかを決める。そんな「AIサイエンティスト」が現実味を帯びてきた、という話です。
同ブログが引き合いに出すのは、ソフトウェア開発の分野です。コーディングエージェントは最初に価値を証明した領域で、いまや本番で動くコードを書き、テストし、リリースするところまで担っています。一方で科学研究は、もっと要求が高く反復の多い領域になりがちだ、とも書かれています。研究者は証拠を評価し続け、仮説を練り直し続けるからですね。
AIが下ごしらえをしてくれるようになるほど、人に残るのは「その証拠は妥当か」「この仮説を追う価値はあるか」を見極める部分になります。これは研究職に限った話ではなく、AIの出力を鵜呑みにせず、根拠をたどって判断する姿勢が、どの仕事でも効いてくるということなのだと思います。
出典：NVIDIA Developer Blog
https://developer.nvidia.com/blog/run-nvidia-bionemo-nim-microservices-for-protein-structure-prediction-in-claude-science/
今日のまとめ ~ AIに任せるほど、任せ方が問われる
今日の7本を並べてみると、共通しているのは「AIをどう動かすか」より「AIをどう囲うか」という視点でした。Atosは制約つきの競争でエンジニアを鍛え、Cioffi氏は権限の違うアカウントで答えを比べ、t54は決裁権と実行権を分け、Perplexityは機密を端末の外に出さない線を引きました。どれも、AIの力を削ぐのではなく、安心して踏み込むための設計です。
これからの時代、大切なのは、
AIが賢くなるほど、人の仕事は「作業」から「見極めと設計」へ移っていきます。今日紹介した事例は、どれもその移行を先に体験した現場の記録でした。まずは自分の仕事のなかで、AIに任せてよい範囲と、自分が握っておくべき判断はどこかを、線を引いてみるところから始めてみませんか。今日も良い一日を！