おはようございます！今日は「AIに任せる前の下ごしらえ」というテーマが浮かび上がる6本です。設計図を自動で更新し続ける仕組み、サポート業務の知識整理、そして「AIは知っているのに思い出せない」という研究まで。さっそく見ていきましょう！
コードの変更に合わせて設計図を自動更新。金融の現場で動き出したAIエージェント
AWS Machine Learning Blogが紹介した事例です。ソフトウェア開発の現場には、システムの部品同士がどうつながっているかを描いた「アーキテクチャ図」を作るのに何時間もかかるのに、コードは毎日変わるので数週間で古くなってしまう、という長年の悩みがあります。図が古いままだと、新しく入った開発者の立ち上がりが遅れたり、監査のときに困ったりします。
これに対して、Amazon Bedrock AgentCore（AIエージェントを構築・運用するためのAWSの基盤）を使い、コードの変更をきっかけに設計図を自動生成する仕組みが紹介されています。AWS CodeCommit（AWSのコード保管サービス）にコードが登録されると、自律型エージェントが.NET（マイクロソフト系の開発技術）で書かれたコードを読み解き、図を生成し、記法にエラーがないか確認し、問題があれば自分で直し、SVG形式に変換したうえで、Amazon Bedrock Knowledge Bases（AIが検索して答えるための知識ベース）に取り込むところまで一気に進めます。ポイントは「作って終わり」ではなく「確認して直す」を組み込んだこと。1回きりのAPI呼び出しでは信頼性が65%だったのに対し、このエージェント方式では95%に達したそうです。
この仕組みは、金融市場でインターディーラーブローカー（金融機関同士の取引を仲介する業者）を営むグローバル企業と共同で検証され、2026年に入ってから同社の電子取引プラットフォームで本番運用が続いています。半年間の社内計測では、リポジトリ（コードの保管場所）ごとに2〜4時間かかっていたドキュメント作成が5分に、新人開発者の立ち上がりが4週間から1週間に、開発したものを届けるまでの期間が10日から3日に短縮したとのこと。ここから見えてくるのは、AIに任せる仕事でも「検証と自己修正のループ」を設計に入れるかどうかで、実務で使えるかが決まるということです。私たちの仕事でも、AIの出力をそのまま使うのではなく、確認の工程をどう組み込むかを考える視点が効いてきそうです。
出典：AWS Machine Learning Blog
https://aws.amazon.com/blogs/machine-learning/from-code-to-diagrams-agentic-architecture-documentation-with-amazon-bedrock-agentcore/
研修動画から手順書を自動生成。人を増やし続けなくてもサポート業務が回る仕組みとは
AWS Machine Learning Blogのもう1本は、サポート業務（問い合わせやトラブルの「チケット」に対応する仕事）の話です。チケットは増える一方で、SLA（対応や解決にかかる時間を約束した基準）は守らないといけない。でも人員をそれに比例して増やすことはできない。しかも、解決に必要な知識は手順書や録画、ベテランの頭の中に散らばっていて、担当者は答えを探す時間ばかりかかってしまう。そんな状況に対して、AWSの生成AIを組み合わせた運用の仕組みが解説されています。
仕組みは2つの層でできています。1つ目は「運用インテリジェンス層」で、Amazon Bedrockを使って研修動画やシステム操作の録画から標準作業手順書（SOP）を自動で作り、RAG（AIが手元の資料を検索してから答える仕組み）で受信したチケットに合った解決手順を提示します。複数のAIエージェントがチケットのタグ付けやコメント、ステータス更新といった作業も進めますが、正確さと統制を保つために人間が確認に入る（human-in-the-loop）枠組みの中で動く設計です。2つ目は「アナリティクス層」で、Amazon Quick（AWSのダッシュボード・分析サービス）を使って担当者ごとの負荷や件数を見える化し、機械学習でSLAを守れなくなりそうなチケットを予測して、先回りで優先順位を決められるようにします。
このニュースから見えてくるのは、AIを入れる前に「知識をどう構造化するか」が勝負だということです。研修で話したこと、先輩が口頭で教えたことを手順書という形に落とし、現場に返す仕組みがあって初めて、AIは力を発揮します。そして全部を自動化するのではなく、最後の確認は人が担う。この線引きは、サポート業務に限らず、どんな職場のAI導入にも当てはまりそうですね。
出典：AWS Machine Learning Blog
https://aws.amazon.com/blogs/machine-learning/modernizing-and-scaling-support-operations-with-generative-ai-on-aws/
「まず単純化、それから革新」。100以上の拠点を持つ製造大手Jabilが新技術より先に手をつけたこと
MIT Technology Reviewのポッドキャスト「Business Lab」の書き起こし記事です。このエピソードはSAP（企業向け業務ソフトウェアの大手）との提携で制作されたもので、製造業のグローバル企業JabilでSAP関連のIT部門を率いるHarish Manohar氏が、システム統合と単純化の取り組みについて語っています。
Jabilは30カ国以上に100を超える拠点を持ち、世界の大手ブランド400社以上と取引しています。拠点ごとに独自のツールや表計算、手作業の回避策が積み重なった結果、データがバラバラに分断され、問題の早期発見や障害への対応が遅れる原因になっていたそうです。そこで同社が掲げたのが「まず単純化、それから革新」という考え方。新しい技術を足す前に、業務プロセスを標準化し、可能なところは統合して、組織全体で一貫したデータの土台を整える。単純化なしの革新は複雑さを増やすだけだ、というのがManohar氏の見方です。個別の課題に対して単発のツールを買い足すのではなく、別の拠点にある既存の仕組みをできる限り再利用する方針だとのこと。そうやって整えた土台の上で、サプライチェーンの予測や例外処理へのAI活用を模索している段階だそうです。
私たちの仕事に引き寄せると、「AIを入れたいから」と新しいツールを次々に足すのは、Jabilが避けようとした道そのものです。まず今のやり方を整理して、データを信頼できる状態にする。そして、あらゆる変革は「測れるビジネス価値を生むか」で判断する。地味ですが、この順番を守れるかどうかが、AI活用の成否を分けそうです。
出典：MIT Technology Review
https://www.technologyreview.com/2026/09/02/1142879/facilitating-ai-integration-with-simplicity-at-scale/
Claudeで商取引向けのAIエージェントを数日で作るための「設計図」が登場
Anthropicの公式ブログによると、Claude上でコマースエージェント（ネット通販など商取引の場面で働くAIエージェント）を構築するためのブループリント（設計図）の公開を始めました。開発チームがコマースエージェントを数日で稼働させるために必要な、ハーネス（AIを動かし制御するための土台となる仕組み）やパターン、ガードレール（AIに不適切な動きをさせないための安全策）が含まれているとのことです。ゼロから作り込むのではなく、用意された型を取り入れて短期間で形にする。この進め方は、AI開発に限らず、私たちが新しい仕事に取りかかるときのヒントにもなりそうです。
出典：Anthropic
https://claude.com/blog/claude-for-commerce-agents
「そのメール、本当にAmazonから？」Alexaに聞けば確かめられるように
The Vergeの報道によると、Amazonは同社を装ったなりすまし詐欺への対策として、受け取ったメールやテキストメッセージ、電話が本当にAmazonから届いたものかをAIアシスタントで確かめられる新機能を用意しました。買い物向けの「Alexa for Shopping」に受信したメッセージについて尋ねると、AIがAmazonの全送信記録と照らし合わせ、内容や書式、送信者を分析して判断します。Amazonによれば、アシスタントが「本物です」と答えるのは完全に確実な場合だけとのこと。
「たぶん本物だろう」とは答えない、という設計は詐欺対策として筋が通っていますね。私たちの仕事でも、取引先や自社を装った怪しい連絡は日常的にやってきます。個人の勘に頼るのではなく、送信記録のような確かなデータで裏を取る。確信が持てないときは「本物」と断定しない。この2つの姿勢は、そのまま職場の情報管理にも当てはまりそうです。
出典：The Verge
https://www.theverge.com/tech/988518/amazon-alexa-for-shopping-verify-emails
AIは「知らない」のではなく「思い出せない」だけ？思考時間を足すと、思い出せなかった事実の最大65%を回収
VentureBeatが報じた、Google ResearchとTechnion（イスラエルの工科大学）の研究です。AIが事実と違う答えを返す「ハルシネーション」が起きると、開発者はふつう「モデルがその事実を知らないからだ」と考えます。ところがこの研究によると、GPT-5やGemini-3といった最先端モデルは、テストした事実の95〜98%を内部に記憶（エンコード）していました。それでも、思考の工程を挟まない状態では、記憶している事実のうち26〜34%を直接思い出せなかったそうです。引き出しの中に書類はちゃんと入っているのに、どの引き出しだったか分からない、という状態に近いですね。
面白いのは、その対処法です。回答の前に推論時の思考プロセスを挟むと、直接思い出せなかった事実の40〜65%を回収できたとのこと。一方で、モデルを大きくするだけでは思い出せない問題は解決しません。例えばGemma3というモデルを10億から270億パラメータに拡大すると、そもそも記憶していない事実は85%から23%に減った一方で、記憶しているのに思い出せない失敗はむしろ増え、思考を挟まない状態では最大で40%に達したそうです。記憶する事実が増えるほど、アクセスできない知識も増える可能性があるわけです。そのため、ハルシネーション対策として安易にRAG（外部の資料を検索してから答えさせる仕組み）を足したりモデルを大きくしたりするのではなく、思考しないと思い出せない事実は全体の10〜20%程度なので、そこにだけ選択的に推論時間を使うことや、生成した答えをモデル自身に検証させる工程が有効だとしています。
これは、私たちがAIを使うときの姿勢にも直結する話です。望む答えが返ってこなかったとき、「AIはこの情報を持っていない」と決めつける前に、問い方を変えてみる、考える手順をプロンプトに組み込む、出た答えを検証させる。この一手間で結果が変わることは、研究が示すとおり珍しくありません。そしてこれは人の育成にも通じます。成果が出ない原因を「知識不足」と片づける前に、その人の知っていることを引き出す問いかけができているか。そんな視点を持ちたいですね。
今日のまとめ ~ AIに任せる前の「下ごしらえ」が成果を分ける
今日の6本に共通していたのは、AIそのものの賢さより、その周りをどう整えるかで結果が決まるということでした。設計図の自動生成では検証と自己修正のループが信頼性を95%に押し上げ、サポート業務では散らばった知識を手順書にする工程が土台になり、Jabilは新技術より先に単純化を選びました。そしてAIが「思い出せない」ときは、問い方ひとつで答えが変わります。
これからの時代、大切なのは、
まずは足元の整理から。その先で、AIはきちんと応えてくれます！