Author

technews

世界の技術ニュースをリアルタイムでキャッチし、日本語でわかりやすく発信。AI・半導体・スタートアップから規制動向まで、グローバルテックシーンの「今」をお届けします。

Outlook「送信済みメールが見つからない」を2026年版で仕分ける — Classic / New Outlook / Exchange Online / OAuth / Recoverable Items

「送信は成功したのに、送信済みアイテムに残っていない」——Outlook 定番のトラブルだが、​2026年の対処は1年前と大きく変わった。理由は3つ。(1) New Outlook for Windows が Classic Outlook を段階的に置き換え、.ost を持たない Web ベース実装に変わりつつあること。(2) Exchange Online の Basic Auth 廃止が長期化し、レガシー IMAP/POP クライアント側の「送信済み」問題が実運用に響いていること。(3) Copilot for Microsoft 365 のインデックス連携と Retention / Litigation Hold の干渉で、「消えた」ではなく「別階層に隔離された」パターンが増えたこと。本稿では2026年時点の原因を頻度・切り分け順に整理する。

⚠️ 前提: 「Outlook」といっても実体は Classic Outlook (Win32 / OL2016〜2024 / M365 Apps)、​New Outlook for Windows、​Outlook on the Web (OWA)、​Outlook Mobile (iOS/Android) の4系統に分かれ、それぞれで「送信済みアイテム」の実装が違う。​まずどの Outlook かを確定させないと切り分けが空回りする。

ざっくり要約（結論）

• 2026年は「消えた≠削除」がやはり多数。まず どのクライアント / どのアカウント種別 / どのメールボックスかを確定
• New Outlook は Classic とオプション画面が別物。旧手順のスクショで探すと詰む
• 共有メールボックスから送った場合の送信済み格納先はテナント設定次第（DelegateSentItemsStyle は EWS 廃止後もクラウド側で継続）
• Basic Auth 廃止後の IMAP クライアントは、Sent フォルダのマッピング不整合で「送信済みに入らない」報告が続出
• 削除したように見えて Recoverable Items に居るケースは、OWA の「削除済みアイテムの回復」または PowerShell で救出できる
• Search-Mailbox は廃止済。追跡・復元は Content Search (eDiscovery) と Get-MessageTraceV2 が2026年の正解
• Retention Policy / Litigation Hold が効いていると、UI から消えても実体は Purges サブフォルダに残っている

まず切り分ける4軸

原因の系統がここで大きく分かれる。ここを飛ばして「送信済みが空です」だけで対処を試すと堂々巡りになる。

💡 「PCの Outlook では出ないのに OWA では見える」なら Classic 側の同期・キャッシュ問題。「OWA でも空」ならサーバ側またはアカウントの取り違えを疑う——この切り分けが2026年も最短ルート。

症状 → 原因 → 一次対処の早見表

対策1: Classic Outlook — 「送信済みアイテムにコピーを保存する」

昔からある基本設定だが、​Classic と New で場所が違う。旧記事のスクショはたいてい Classic のもの。

Classic Outlook (Win32):

• [ファイル] → [オプション] → [メール] → [メッセージの保存] セクション
• ​「送信メッセージのコピーを [送信済みアイテム] フォルダーに保存する」​ にチェック
• 加えて POP アカウントでは アカウント設定 → 変更 → 詳細設定 で保存先フォルダが指定されていることを確認

New Outlook for Windows / OWA:

• 右上の ⚙ (Settings) → [メール] → [作成と返信] の下部にある ​「送信済みアイテムに保存する」​ を有効化
• Classic と設定の粒度が違い、「返信元と同じフォルダに保存」など細かい選択肢が減っている点に注意

.ost が読めない環境（New Outlook）では サーバ側設定がそのまま反映される。逆に Classic はプロファイル/.ost にキャッシュされた設定が優先されるため、テナントで直しても即反映しない場合がある。

対策2: Classic vs New Outlook の実装差を知る

2024年から段階的に置き換わっている New Outlook for Windows​（旧コードネーム One Outlook / Project Monarch）は、Classic と根本的に別実装。​トラブルの原因帯も別物として扱うべき。

​「Classic では送信済みに残るが New では残らない」ケースの典型:

• New Outlook は サーバ側の "SentItems" フォルダを直接見る。Classic のプロファイルで別フォルダを保存先に指定していた場合、その設定は New に引き継がれない
• New Outlook の初期リリース時、​IMAP アカウントの送信済み同期が不安定な報告が多く、OAuth 対応の Exchange Online / Outlook.com への切り替えが推奨されがち
• 「今日から New に切り替わった」タイミングで問題が発生したなら、​まず Toggle で Classic に戻して同じ症状が再現するか確認するのが早い（New Outlook 右上のトグルで戻せる）

対策3: 共有メールボックス / 委任 / 別 From で送った場合

​「自分のアドレスから送った分は残るが、共有メールボックスの From で送った分だけ残らない」​は Exchange のクラシックな罠。デフォルトでは送信済みが送信者本人のメールボックスに保存され、共有メールボックス側には残らない。

Exchange Online での正しい設定 (2026年):

# 共有メールボックス側にも送信済みを残す
Set-Mailbox <shared_mailbox> -MessageCopyForSentAsEnabled $true
Set-Mailbox <shared_mailbox> -MessageCopyForSendOnBehalfEnabled $true

• 旧来のレジストリ設定 DelegateSentItemsStyle は Classic Outlook のローカル側の話で、Exchange Online 上では上記コマンドが正
• 2つのフラグは SendAs（差出人として）と SendOnBehalf（代理送信）の2権限で別々に効く。両方立てておくのが安全
• クライアント再起動 or .ost 再同期をしないと反映されないので注意

エイリアス送信 (Send As Alias):

• Microsoft 365 で プライマリでない SMTP アドレスで送ると、以前は宛先側から見て From がプライマリに書き換わることがあった
• 2022年以降 Send From Aliases が正式サポートされたが、​送信済みには「エイリアスで送った」情報が残らないクライアントもある。OWA/New Outlook では表示され、古い Classic では見えない、といった差異

対策4: IMAP / POP / Basic Auth 廃止の残滓

Exchange Online の Basic Auth は2022年に無効化済みだが、​IMAP は例外的に生き残る運用がまだ残っている。ただし2025年以降、テナント既定でさらに絞られ、レガシーな IMAP クライアントで送信済みトラブルが顕在化した。

IMAP でよくある送信済み消失パターン:

• Sent フォルダのマッピングずれ: Thunderbird 等が独自に Sent フォルダを作り、Exchange Online 側の SentItems と別階層になる。OWA では別フォルダとして両方見える
• 送信時にサーバ側 IMAP APPEND を打っていない: クライアントが SMTP 送信のみで、送信済みへの APPEND を打たない設定
• OAuth トークン切れ: 送信は SMTP AUTH (OAuth) で通ったが、IMAP 側の APPEND がトークン期限切れで silently 失敗

確認手順:

1. OWA で SentItems に実際にあるか確認（サーバ側の真実）
2. IMAP クライアントの ​「送信済みフォルダ」設定 をサーバ側 Sent Items に明示的にマップ
3. IMAP・SMTP とも OAuth 2.0 を使う設定になっているか（Basic Auth のパスワードで動いていたら要移行）
4. Microsoft Authentication Library (MSAL) 経由のトークン管理が正常か

対策5: Send Later (予約送信) と 送信トレイの罠

​「送信済みに入っていないが、宛先には届いていない」​なら、まだ送信トレイに残っている。

• Classic Outlook では [送信トレイ (Outbox)] に滞留していないか
• New Outlook / OWA の 予約送信 (Send Later) は「予定時刻まで下書き相当」に留まる。​Drafts 直下もしくは専用ビューを確認
• Classic の「後で送信」は .ost にキューされ、オフライン中は送信されない。​オンライン確認と Send/Receive Groups の設定を確認
• ルールで ​「送信時に転送」→「元のメッセージを削除」​ が仕込まれていると送信済みに残らない。​**[ファイル]→[ルールと通知の管理]** で棚卸し

対策6: .ost 破損 / プロファイル問題（Classic 限定）

Classic Outlook は .ost (Offline Storage Table) にキャッシュを持つ。​​「OWA では見えるが Classic では見えない」​ならほぼここ。

手順（軽い順）:

1. Send/Receive All Folders (F9) で強制同期
2. [ファイル] → [アカウント設定] → [データファイル] → 該当アカウント選択 → [ファイルの場所を開く] → Outlook 停止後に該当 .ost をリネーム → Classic 再起動で再ダウンロード
3. 直らなければ プロファイル再作成 — コントロールパネル → Mail → プロファイル作成 → 既定に設定
4. Cached Exchange Mode の同期期間を [アカウント設定]→[変更]→[オフラインで使用するメール] で長め (1年〜All) にしないと古い送信済みが降りてこない
5. Windows Search インデックスが壊れていると Classic 内検索でも「送信済みが検索できない」症状。​**[インデックスのオプション]→[詳細]→[再構築]** で解消することがある

scanpst.exe（受信トレイ修復ツール）は .pst 用で、.ost には非対応。​**.ost は消して再生成が正解**。

対策7: Retention Policy / Litigation Hold / アーカイブ

​「一度は送信済みに入っていたのに、しばらく経つと消える」​は、コンプライアンス系ポリシーが効いている可能性が高い。

• Exchange Online の Retention Policy で "Sent Items" フォルダに Move to Archive (n日) タグが付いていると、期限後にアーカイブメールボックス​（別 UI）へ移動する
• Delete and Allow Recovery が効くと、UI からは消えるが Recoverable Items に n 日残る
• Litigation Hold が有効なメールボックスでは、UI 削除しても実体は Recoverable Items\Purges に保持され続ける
• Compliance Center → Content Search で保管ポリシーの範囲・宛先を確認する。実運用では管理者権限が必要

対策8: Recoverable Items で復元する（削除済みでも救えることがある）

「削除した」と思ったものは、​まだサーバ上に残っていることが多い。Exchange の削除は多層構造で、階層は次のとおり。

Deletions       ← ユーザが Deleted Items から削除した直後（Shift+Del 相当）
Purges          ← Deletions からさらに削除 or Litigation Hold で保持
Versions        ← In-place Hold 時のバージョン管理
DiscoveryHolds  ← eDiscovery Hold の対象

OWA から救う（一般ユーザ）:

• OWA → 削除済みアイテム → ​「削除したアイテムを回復」​ から Deletions を戻せる（既定14日、テナント設定で最大30日）
• 送信済みからの直接削除でも、同じ階層に落ちるので回復可能

PowerShell (Exchange Online) から救う（管理者）:

# Deletions 内の該当メッセージを検索して復元先を指定
Search-Mailbox は廃止済。代替として下記:

# Compliance Search で対象特定
New-ComplianceSearch -Name "restore-sent" \
  -ExchangeLocation user@example.com \
  -ContentMatchQuery 'subject:"..." AND from:"..."'
Start-ComplianceSearch -Identity "restore-sent"

# 復元は New-ComplianceSearchAction -Purge の逆で、
# Restore-Mailbox 系は廃止済のため EWS/Graph 経由の再挿入が必要

2025年に Search-Mailbox cmdlet は廃止。​Compliance Search + Purview eDiscovery が公式代替。UI に慣れておく方が回り道が少ない。

対策9: メッセージ配信の追跡は Get-MessageTraceV2

「そもそも送信されたのか」から疑うなら、Message Trace が最終手段。​2025年に Get-MessageTrace は Get-MessageTraceV2 に置き換わった。

# 直近10日以内の送信ログを追う
Get-MessageTraceV2 -SenderAddress user@example.com \
  -StartDate (Get-Date).AddDays(-3) -EndDate (Get-Date) | \
  Where-Object { $_.Status -eq "Delivered" -or $_.Status -eq "Expanded" }

• 送信済みが空でも Trace に Delivered レコードがあれば、送信自体は成立している
• FailedByBounce や Quarantined なら送信済みに来ないのも道理
• 10日を超える範囲は Historical Search ジョブで実行（結果は CSV でメール通知）

対策10: Copilot / AI 統合の副作用

2026年の新しめの原因帯。​Copilot for Microsoft 365 が下書き生成 → 送信を代行するフローでは、Sent Items の書き込みに以下の不整合が起きる報告がある。

• Copilot 生成の下書きが Drafts 内でしか閲覧できない状態で送信され、送信済みへのコピーが遅延する
• Sent Items のインデックスが Copilot 検索キャッシュと不整合を起こし、​​「送信済みには見えるが Copilot からは参照できない」​逆パターンも
• Microsoft 側で継続的にパッチが当たっている領域。​M365 メッセージセンターで CI (Change Incident) が出ていないかを先に見るのが早い

クライアント別クイックチェック表

よくある質問（FAQ）

Q. 送信は成功しているのに1通も送信済みに入らない。​
A. まず OWA を開き、サーバ側の SentItems に本当にあるかを確認。あれば同期問題、なければ「保存する」設定オフ / 別メールボックス送信 / IMAP APPEND 失敗 のどれか。

Q. 共有メールボックスから送ると自分の送信済みに入ってしまう。​
A. Exchange Online の仕様。Set-Mailbox -MessageCopyForSentAsEnabled $true を共有メールボックスに設定すれば両方に残る。

Q. Classic の設定を New Outlook が引き継いでくれない。​
A. New Outlook はプロファイル/.ost を持たないため、Classic のローカル設定は原則引き継がない。​サーバ側の設定を正として使う設計。

Q. scanpst.exe で .ost は直せる？​
A. 直せない。.ost はサーバのキャッシュなので、消して再生成が正解。

Q. 削除して数日経ったが救えるか？​
A. Deleted Items 内なら通常削除、そこから消しても Recoverable Items に既定14日（設定で30日まで）。Litigation Hold 中は Purges に長期保持され、eDiscovery で救える。

Q. IMAP でずっと使っていたが最近急に送信済みが空になった。​
A. Basic Auth が段階的に切られていて、SMTP は通るが IMAP 側の APPEND が失敗している可能性。OAuth 対応クライアントに移行するか、公式クライアントへ切り替え。

Q. 検索しても出てこないが本当にないのか？​
A. Classic の場合は Windows Search インデックス破損の可能性。OWA で検索して出れば、サーバには残っている。

恒久対策（設計側の勘所）

• ​「送信済みに保存」オプションは全クライアントで統一​（テナント既定 + クライアント再確認）
• 共有メールボックスは MessageCopyForSentAsEnabled を最初に立てておく
• IMAP / POP は原則 M365 では新規追加しない。既存も Exchange Online (Modern Auth) に移行
• 重要な送信履歴はエクスポート​（Classic: .pst、Compliance Center: PST エクスポート、Graph API: /me/mailFolders/SentItems/messages で JSON 保管）
• Retention Policy の "Sent Items" タグは明示的に設計する。「気付いたら消えていた」を防ぐ
• Litigation Hold / In-place Hold の有無を運用ドキュメントに残す。消えないはずのものが消えている、または残っているはずが救えない、が続く原因

まとめ

2026年の「Outlook 送信済みが見えない」は、​Classic か New か、クライアント側かサーバ側か、自分メールボックスか共有か——この3つの切り分けを外さないことがすべてだ。旧記事の手順は Classic Outlook 前提のことが多いが、New Outlook や OWA では設定場所も同期の仕組みも別物になっている。​まず OWA で照合し、サーバ側に無ければ設定・IMAP・共有の格納先を疑う。​サーバ側にはあってクライアントに出ないなら .ost かプロファイルの再作成。​Retention / Litigation Hold が絡む環境なら Recoverable Items と Compliance Search が最後の砦。Search-Mailbox 廃止・Get-MessageTraceV2 移行・New Outlook 移行という3つの構造変化を押さえておけば、Outlook の「消えた」はほぼ体系的に片付けられる。

同じ著者の記事

Excelの文字が勝手に変わる本当の理由 ―― テーマフォントとAptos騒動

「昨日まで普通だったのに、開いたら文字の形も行の高さも違う」。Excelでこれをやられると地味に腹が立つ。ネット上の解説は「値のみ貼り付けを使え」「条件付き書式を消せ」で止まっているものが多いが、それは症状の一部でしかない。原因の大半は、もっと下のレイヤーにある。フォント名がセルに直接書かれていないこと ―― つまりテーマフォントという仕組みだ。 Excelのフォント一覧を開くと、いちばん上に「テーマのフォント」という区切りがあって、`游ゴシック（本文）` `游ゴシック Light（見出し）` の2つが並んでいる。既定の状態では、あなたが打ち込んだセルはこの「本文のフォント」を参照している。具体的な書体名（游ゴシック）を持っているのではなく、「このブックのテーマが本文用に指定している書体、それが何であれ」という*ポインタ*を持っているだけだ。 だから、テーマが変わればセルの見た目も一斉に変わる。ページレイアウトタブの「テーマ」や「フォント」を切り替える、別のテーマが設定されたブックにシートをコピーする、あるいはテーマ設定の異なる環境でファイルを開く ―― どれをやっても、一文字

papoo.work

ChatGPTの会話履歴が消えた・表示されないを直す【2026年6月版】

「昨日まであった会話が、サイドバーから消えている」——ChatGPT 利用者の定番の不安だ。だが2026年の今は、1年前とは原因も設定画面もすっかり変わっている。最大の変化は、(1) かつての対処の定番だった 「Chat history & training（会話履歴とトレーニング）」トグルが廃止され、データ設定が再編されたこと。そして (2) 「アーカイブ」「一時チャット（Temporary Chat）」「プロジェクト」といった、履歴が“消えたように見える”新しい仕組みが増えたことだ。本稿では2026年時点で本当に効く見極めと対処を、頻度の高い順に整理する。 > ⚠️ 注記: ChatGPT は UI と設定項目の変更が速い。下記は本稿執筆時点（2026年6月）の挙動。「削除」した会話は UI・API・サポートのいずれからも復旧できないのは今も同じ。まずは「本当に削除したのか」を疑うこと。 --- 2026年は「消えた≠削除」が大半。まず アーカイブ / 一時チャット / 別アカウント の3つを疑う **昔の「会話履歴とトレーニング」ト

papoo.work

AIモデルの政治的な“傾き”を地図にしたTrakkrの実験がかなり面白い

AIに「この政策はどう思う？」とか「どの候補者に近い？」と聞くと、返ってくる答えに妙な一貫性を感じることがあります。Trakkrの「Political bias in AI」は、その“なんとなくの印象”を、かなりきっちり測ろうとしたページです。 ざっくり言うと、主要なAIモデルに政治・経済・言論・社会に関する刺激の強い質問を何度も投げ、その答えの傾向を地図に落とし込んでいます。しかもWeb検索はオフ。つまり、ネット上の情報を拾った結果ではなく、そのモデル自身がどんな方向に寄りやすいかを見ているわけです。ここがまずおもしろい。 Trakkrは、主要AIモデルの政治的・社会的な“傾き”を可視化している 1回だけでなく、同じ質問を何度も繰り返し、答えのブレも含めて見ている Web検索はオフなので、「ネットがそう言っていた」ではなく「モデル自体がどう答えるか」を測っている 6モデルのうち、4つが左寄りに見えた ただし、どのモデルも一枚岩ではなく、質問によってかなり揺れる 自分で同じ質問に答えると、どのモデルに近いかも見られる このページの芯はとてもシンプルです。 AIモデルに、政治や社会の難し

papoo.work

CUDA kernelを走らせると裏で何が起きているのか

「GPUで計算する」と聞くと、なんだか一瞬で魔法みたいに処理が終わる印象があります。 でも元記事は、その裏側にある泥臭い手順を、かなり執念深く追いかけています。しかも題材は、たった1行のベクター加算。`a[i] + b[i]` を並列に足すだけの、いちばん地味なCUDAプログラムです。地味だからこそ面白い。GPUという巨大な装置が、どれだけの段取りを踏んでこの1行を実行しているのかが、くっきり見えてきます。 `nvcc` は1つのコンパイラではなく、複数のコンパイラをまとめて動かす“司令塔”です CUDAのコードは、まずPTXという中間表現になり、その後SASSというGPU実機向け命令に変わります `vadd<<<4096, 256>>>(...)` のような記法は、ホスト側で引数を詰める「stub」に置き換えられます GPUカーネルの引数は、constant bank 0 に載って読み出されます 実行時には、CPU側のランタイム、`libcuda.so`、ドライバ、PCIe越しのGPUが連携して動きます ただ“GPUに投げた”だけに見える処理の背後で、かなり多くの機械的な準備が走って

papoo.work

「安いAIモデル」が高級ブランドを揺さぶる

Open Weight Models は、モデルの中身を公開して配布するタイプのAIで、誰でも自分の環境に近い形で使いやすい。 記事の筆者は、DeepSeek V4 の安さを見て、Anthropic や OpenAI の“フロンティアモデル”との価格差があまりに大きいと感じている。 その差は、単に「少し高い」ではなく、トークン単価ベースでほぼ50倍にも見える、というのが衝撃点。 さらに筆者は、高価格を維持するために「希少性」を演出する動きがあるのでは、と疑っている。 将来の競争軸は、単なる Open Weight ではなく、学習データの流れまで公開する「True Open Source」へ移るのではないか、と見ている。 AllenAI の OLMo や、NSF と Nvidia の支援も、その流れの例として挙げられている。 この記事で面白いのは、AIの性能そのものより「値段のつけ方」に真正面から噛みついているところです。 ふつうAIの話は「賢い」「速い」「便利」で終わりがちですが、ここではかなり露骨に「その高額料金、本当に必要？」と問いかけています。私はここがかなり重要だと思います。A

papoo.work

黒箱LLMから小型モデルへ知識をどう渡すか、Proxy-KDという発想が面白い

大規模言語モデルの世界は、ここ数年ずっと「でかいモデルが強い」の一強でした。GPT-4のような商用LLMは性能が抜群ですが、中身は見えません。APIの向こう側にいて、内部状態や学習の細部には触れられない。研究する側からすると、これはかなりもどかしい。 この論文 `Knowledge Distillation of Black-Box Large Language Models` は、その厄介な壁をどう越えるかを真正面から扱っています。しかもアイデアがわりと気持ちいい。黒箱LLMの出力を、そのまま小型モデルに押し込もうとするのではなく、proxy model という“仲介役”を挟むのです。 知識蒸留（knowledge distillation, KD）は、強いモデルの知識を小さいモデルへ移すやり方です。たとえば大きな先生モデルが出した答えを手本にして、軽い生徒モデルを育てるイメージです。 ただ、普通の蒸留は先生の内部情報も使えることが多い。どの単語にどれくらい自信があるか、途中でどう考えているか、といった情報ですね。ところが黒箱LLMはそこが見えない。返ってくるのは最終出力だけ

papoo.work

AIエージェントに必要なのは「長い会話」より「本当の記憶」だった

大きな context window は、記憶そのものではない それは「一時的に広い机」を持っているようなもので、セッションが終われば消える 以前の会話を毎回ぜんぶ送り直すやり方は、長くなるほど重く、遅くなる Retrieval は「必要な資料だけを本棚から持ってくる」仕組み Compression は中身をなるべく保ったまま、入力を小さくする工夫 Summarization は要点だけ残す方法で、元データは別に保存しておくのが安全 AIエージェントを作るときは、モデルに全部覚えさせるより、DBや検索の役割を分けるほうがうまくいく 元記事の主張はかなり明快です。 context window が大きいことと、memory があることは別物だ、という話です。 ここでいう context window は、AIモデルが一度に読める文章量の上限です。 人間でいうと「机の上に広げて見られる書類の量」に近い。広ければ広いほど便利そうですが、だからといって「その机が記憶装置になる」わけではありません。 著者のたとえがわかりやすいです。 巨大な机を買って、ファイルキャビネット

papoo.work

Qwen-AgentWorldが狙う「LLMで世界をまるごと動かす」発想

大きなAIモデルを見ていると、最近は「文章をうまく作る」だけでは全然足りないんだな、としみじみ思います。次に来るのは、AIが環境の動きまで頭の中で予測する方向です。今回のarXiv論文 Qwen-AgentWorld: Language World Models for General Agents は、まさにそこを真正面から狙っています。 ざっくり言えば、これは「言語モデルを使って、エージェントが置かれた世界の変化をシミュレーションする」研究です。チャットの延長ではなく、AIが「この操作をしたら次に何が起きるか」を考えられるようにする。ここが肝です。正直、この発想はかなりおもしろいです。AIを“答える機械”から“先読みする機械”に近づけようとしているので。 Qwen-AgentWorldは、agentic environment をシミュレートする language world model 35B-A3B版と397B-A17B版の2モデルを公開 **7つのドメインをまたいで、long chain-of-thought reasoning による環境予測

papoo.work

中国版「Mythos」登場、その中身はかなり本気だった

Qihoo 360の創業者・周鴻禕氏が、北京のISC.AI 2026で脆弱性発見AI「Tulong Feng」を発表した。 彼はこれを、Anthropicのサイバーセキュリティ向けAI「Claude Mythos」に対する中国版だと位置づけた。 同じタイミングで、中国のZ.aiは近い性能を持つモデル「GLM-5.2」をMITライセンスで公開し、誰でも無料で使える形にした。 セキュリティ評価では、GLM-5.2が一部のベンチマークでClaude Codeを上回ったとされ、コスト面でもかなり安い。 ただし、これは「中国がついに米国に追いついた」と単純に言う話ではなく、AIサイバーセキュリティの覇権争いがかなり露骨になってきた、というニュースだと思う。 中国のサイバーセキュリティ業界が、かなりはっきり「うちはうちでやる」と言い始めている。Decryptの記事が伝えているのは、そんな空気感だ。 話の中心にいるのは、Qihoo 360の創業者・周鴻禕氏。Qihoo 360は中国では有名なセキュリティ企業で、個人向けの保護ソフトや企業向け防御で存在感がある。その周氏が、北京で開かれたISC.AI

papoo.work

中国のAIが「セキュリティの虫」を見つける力でAnthropicに並んだ、という話

中国のAIスタートアップ Z.ai の最新モデル GLM-5.2 が、セキュリティ脆弱性の発見で Anthropic の Claude Mythos に匹敵する、と報じられた。 ここでいう「脆弱性」は、ソフトウェアに潜む安全上の穴のこと。攻撃者に先回りされる前に見つけるのが重要だ。 GLM-5.2 は open-source で、誰でもダウンロードして自前の環境で動かせる。便利だが、悪用のハードルも下がる。 ただし、AI全体の総合力で中国が米国を追い越した、という話ではない。差が急速に縮んでいる、というのが本筋。 個人的には、今回のニュースは「どちらが強いか」よりも、「実戦で効く分野ではもう横並びが起きている」ことの方が怖くて面白いと思う。 米テックメディアのDigital Trendsが紹介したのは、かなり象徴的なニュースでした。中国のAIラボ Z.ai が開発した最新モデル GLM-5.2 が、サイバーセキュリティの領域で Anthropic の最上位モデル Claude Mythos に肩を並べた、という内容です。 ここで大事なのは、「AIが賢いか

papoo.work