Tech News JP

オープンソースデータベースプロジェクト「Turso」が、自社のバグバウンティプログラムを正式に廃止した。廃止の理由は技術的な限界でも予算不足でもなく、AIエージェントが大量に送りつけてくる無意味・無価値な「CRITICAL」脆弱性報告の洪水だ。 バグバウンティが機能しなくなった背景 TursoはlibSQL（SQLiteのフォーク）をベースにしたエッジ向けデータベースを提供するオープンソースプロジェクトだ。セキュリティ改善のためにバグバウンティプログラムを運営していたが、AI利用が普及するにつれて報告の質が急激に劣化した。 問題の核心は「AIスロップ（AI Slop）」と呼ばれる現象にある。報奨金目的のハッカーたちがAIエージェントにコードを丸投げして自動で脆弱性を探索させ、内容を精査せずそのまま「CRITICAL」として提出するようになった。報告書の体裁は整っているが、実際には的外れ・矛盾だらけ・存在しないコードパスへの言及など、価値ゼロのノイズが大半を占めていた。 開発チームの稼働は有限だ。AIが生成した粗悪なレポートを一つひとつ確認・返答・却下するだけで膨大な時間が失われる。本来のセキュリティ強化に向けるべきリソースが、フィルタリング業務に消えていくという本末転倒な状況に陥ったため、プログラム全体の廃止という判断に至った。 AIスロップ問題がセキュリティに与えるインパクト この現象はTurso固有の問題ではない。セキュリティコミュニティでは「AIを使った脆弱性ハンティングの民主化」が叫ばれる一方で、その副作用として報告品質の急落が各所で問題になりつつある。 バグバウンティプラットフォームの仕組み上、報告者は「とにかく数を出す」戦略が合理的に映る。AIエージェントを使えば1時間で数十件の「それらしい」レポートを生成できる。報奨金がもらえればラッキー、却下されても損失はゼロ、という非対称な構造がAIスロップを量産させている。 真剣に取り組む本物のセキュリティリサーチャーにとっても悪影響は大きい。レビューキューがAIゴミで埋まると、価値ある報告が埋もれてしまいトリアージ効率が著しく落ちる。 実務への影響——日本のエンジニア・IT管理者へ バグバウンティ運営側の視点 バグバウンティを運営している、または検討している組織は、報告フォームへのAI生成コンテンツ対策を今から設計に組み込む必要がある。具体的には： 報告書の最低品質基準を明文化する: 再現手順の動画提出必須、環境情報の詳細記載必須など、AIが苦手な「実証証拠」を要件にする 初回スクリーニングの自動化: 明らかに的外れな報告を人間のレビュー前に弾くルールベースフィルターを設ける 報奨金テーブルの見直し: 低品質報告のコスト（レビュー工数）を報奨金設計に織り込み、「数撃ち戦略」の費用対効果を下げる 開発者・セキュリティエンジニアの視点 AIを使って脆弱性を調査すること自体は悪くない。問題は「AIの出力をそのまま提出する」行為だ。AIが出した候補を人間が検証し、実際に再現できることを確認してから提出する——この一手間が、AIを「ノイズ生成機」から「調査補助ツール」に変える。 またSBOM（ソフトウェア部品表）の整備や依存ライブラリの継続監視など、受動的な脆弱性通知に頼らない自衛策の整備も改めて重要性が増している。 筆者の見解 AIを使った業務効率化に積極的な立場からすると、今回のTursoの判断は皮肉なケースに映る。自動化の恩恵を受けるべきセキュリティプロセスが、自動化の乱用によって機能不全に陥った。 根本にあるのはインセンティブ設計の問題だ。「報告数 × 採択確率 ＝ 期待報奨金」という計算をする人間にとって、AIエージェントは最適解として機能してしまう。これを防ぐには、技術的なフィルタリングだけでなく、構造そのものを変えなければならない。 Non-Human Identity（NHI）の管理や自動化推進の観点でも示唆がある。AIエージェントが外部に向けてアクションを起こす際のガバナンス——何を送信してよいか、品質チェックはどこが担うか——は、セキュリティ報告に限らず普遍的な課題だ。「AIが動ける仕組みを作る」と同時に「AIの出力を人間が検証するゲートをどこに置くか」を設計に組み込まなければ、似たような問題が別の文脈でも繰り返される。 バグバウンティというエコシステム全体が、AI時代の新しい設計に迫られているということだろう。Tursoの撤退を「AIに負けた」と見るのではなく、「次の仕組みを作るためのデータポイント」として業界が学ぶ機会にしてほしい。 出典: この記事は Turso retires bug bounty program because most “CRITICAL” issues are just AI slop の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoftは、ブラウザ「Microsoft Edge」が内部メモリ上にパスワードを平文（暗号化されていない状態）で保持していた問題を公式に認め、修正を最優先課題として対応中であることを発表した。 メモリ上の平文パスワードとはどういう問題か 「平文でメモリに保存」とは、Edgeのプロセスが動作中にパスワードを暗号化せずRAM上に展開していた状態を指す。通常、認証情報はメモリ上でも暗号化された状態で扱うのがセキュリティのベストプラクティスであり、使用後は即座にメモリをゼロクリアすることが推奨されている。 この状態が続くと、以下のような攻撃シナリオが現実的なリスクになる。 メモリダンプ攻撃: ローカル管理者権限や特権プロセスからEdgeのメモリダンプを取得することで、保存済みパスワードが丸ごと読み取れる 悪意あるソフトウェアによる窃取: マルウェアがEDRをすり抜けてプロセスメモリを直接スキャンした場合に認証情報が流出するリスクがある クラッシュダンプへの混入: アプリケーションがクラッシュした際に生成されるダンプファイルにパスワードが含まれ、ダンプを回収できた攻撃者に悪用される可能性がある 実際のところ、この問題は以前からセキュリティ研究者の間で指摘されていた。Microsoftが正式に認め、優先修正として動いた意義は決して小さくない。 修正の方向性と技術的対処 Microsoftは具体的な実装手法を公開していないが、一般的な対処としては以下が考えられる。 Windows Data Protection API（DPAPI）によるメモリ上の暗号化: WindowsがネイティブにサポートするAPIで、ユーザーコンテキストに紐付いた鍵でメモリ上のデータを保護できる 使用後の即時ゼロクリア: パスワード入力や自動入力後にメモリ領域を即座にクリアし、平文データが残存しないようにする SecureString相当の管理: .NETではSecureStringという仕組みがあり、同様のアプローチをEdgeのC++実装に取り込む選択肢もある 修正版はEdgeの通常アップデートサイクルで配信される見込みだ。 実務への影響 — エンタープライズ担当者が今すぐやること アップデート管理の見直し EdgeはMicrosoft Updateを通じて自動更新されるが、グループポリシーや Intune でバージョンを固定している環境では手動対応が必要になる。修正バージョンがリリースされた後、以下を確認すること。 Intuneのデバイスコンプライアンスポリシー: 最低限必要なEdgeバージョンを条件付きアクセスのコンプライアンス要件に組み込む 古いEdgeバージョンの棚卸し: MicrosoftEdge/Update/ レジストリや Intune レポートで組織内のバージョン分布を把握する ASR（Attack Surface Reduction）ルールの活用: Microsoft Defender for Endpointの Block credential stealing from the Windows local security authority subsystem などのルールを有効化し、メモリベースの資格情報窃取を多層防御する Edgeパスワードマネージャーの利用状況を把握せよ 今回の問題はEdge組み込みのパスワードマネージャーを使っているユーザーに直接影響する。エンタープライズ環境では「なんとなくEdgeにパスワードを保存している」社員が相当数いるはずで、IT部門がそれを把握できていないケースも多い。 今回を機に、組織内のパスワード管理ポリシーを見直す絶好の機会だ。業務用パスワードは管理者が制御できるエンタープライズ向けパスワードマネージャーに集約し、Edgeのローカル保存は禁止する方向を検討したい。グループポリシーの PasswordManagerEnabled を無効化するだけで、組み込みマネージャーへの保存を禁止できる。 筆者の見解 2026年のブラウザがパスワードをメモリ上に平文で扱っていたというのは、Microsoft Defenderや Entra ID といった幅広いセキュリティ製品群を持つ同社としては「もったいない」と感じてしまう。セキュリティへの投資をあれだけ打ち出してきた会社が、ブラウザというエンドポイントの最前線でこの実装が残っていたのは素直に惜しい。 ただし、正直に認めて修正に動いた点は評価したい。「知らなかった」「問題ない」で押し切るベンダーより、誠実な対応を選んだMicrosoftの姿勢は信頼の回復につながる。 気になるのは、この問題がいつから存在し、なぜ今まで内部で検出されなかったかという点だ。外部の研究者に指摘されるまで気づかなかったとすれば、メモリ安全性に関する内部レビューフローに改善余地があることになる。MicrosoftはこれをEdge単体の修正で終わらせず、同様の実装が他製品に残っていないかを組織横断でレビューする機会にしてほしい。 ...

Broadcomは2026年5月、macOS向け仮想化ソフトウェア「VMware Fusion Pro 26H1」をリリースした。Apple Silicon（ARM）環境でのESXiゲストOSサポートの追加、Linux系ゲストOSの互換性拡張、そして深刻なセキュリティ脆弱性の修正が今回の主な変更点だ。 ARM ESXiゲストサポートが意味すること 今回の目玉機能は、Apple Silicon Mac上でVMware ESXiをゲストOSとして動作させる「ARM ESXサポート」だ。これはvSphereやESXiを扱うインフラエンジニアにとって重大なアップデートとなる。 これまでApple SiliconのMacユーザーがESXiの検証をしようとすると、x86ベースのマシンを別途用意するか、クラウド上に環境を構築するしかなかった。ARM ESXIゲスト対応により、M1/M2/M3/M4チップを搭載したMacBook ProやMac miniの上で、直接ESXiの動作検証やラボ環境構築が可能になる。 ただし注意点がある。ARM版ESXiはIntel版と完全に同じではなく、ゲスト側のARMネイティブ対応状況やNIC・ストレージドライバーの差異が存在する。あくまで「ラボ・検証用途」として捉えるのが現実的な使い方だ。 拡充されたLinuxゲスト互換性 26H1では、Linuxゲストの互換性リストが更新された。具体的に対応が強化されたのは以下のディストリビューションだ（Fusionのリリースノートに基づく）： Ubuntu 24.04 LTS（Noble Numbat）の正式サポート強化 Debian 13（Trixie）系列の追加対応 RHEL/AlmaLinux/Rocky Linux 9.x 系の最新マイナーバージョン追従 Kubernetesやコンテナ開発用途でmacOSをメインに使いながらLinux VMを日常的に動かしているエンジニアには、アップデートの恩恵を感じやすい変更だ。 重大なセキュリティ修正 今回のリリースで特に注目すべきは「major security fix」の存在だ。BroadcomのセキュリティアドバイザリによりCVEが割り当てられている場合、VMインスタンスの隔離境界に関わるホスト側への影響（VM Escape系）の可能性もある。 Fusion Proを業務環境で使っているユーザーは、セキュリティ修正の詳細をBroadcomのリリースノートで確認し、できるだけ早期にアップデートを適用することを強く推奨する。「VMはゲストだから安全」という発想はVM Escapeの脅威を考えれば成立しない。ホストOS同様の感度でパッチ適用を習慣にしたい。 実務への影響と活用ポイント インフラ・VMwareエンジニア向け: Apple Siliconが普及した現在、開発マシンがARMアーキテクチャに移行している組織では、「Mac上でESXiをテストしたい」というニーズは確実に増えている。ARM ESXiゲスト対応はそのギャップを埋める現実的な手段になる。vSphere環境の設計検証や新機能の事前確認に活用できる。 開発者向け: Docker Desktopと比較してもVMware Fusionはネットワーク構成の自由度が高く、複数VMでのネットワークトポロジー再現が得意だ。マルチノード構成の検証や、本番に近い環境でのテストが必要な場面ではFusionが有利なシーンも多い。 IT管理者向け: Fusion Proはライセンス形態がBroadcomの再編以降に変化しており、無料化された個人利用枠と有償の商用枠が整理されている。社内への展開を検討している場合は、最新のライセンス条件を確認した上で計画を立てることを勧める。 筆者の見解 VMware FusionはmacOS上の仮想化ソリューションとして、長年の実績を持つ信頼性の高いツールだ。BroadcomによるVMware買収後、価格体系や製品ラインアップが大きく変わったことで一時は混乱もあったが、Fusion Proの継続的な機能強化は歓迎できる。 ARM ESXIゲスト対応は、Apple Siliconへの移行が進む国内のIT現場でも実用的な価値がある。ただし、VMの検証環境はあくまで「道具」であって、本番相当の構成テストは相応のハードウェアで行うという基本は変わらない。 セキュリティ修正については、多くのエンジニアが「仮想マシン環境だから」と過信しがちな点でもある。ホストとゲストの境界は完全無敵ではない。パッチ適用の優先度はホストマシンと同等に扱うべきだというのが個人的な一貫したスタンスだ。アップデートを後回しにしないこと、これに尽きる。 出典: この記事は VMware Fusion Pro 26H1 released with support for more guest OSes の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

世界最高峰のハッキング競技会「Pwn2Own 2026」において、セキュリティ研究者たちがWindows 11、Microsoft Edge、Microsoft Exchangeに対するゼロデイ脆弱性の悪用に次々と成功し、多額の賞金を獲得した。AIアプリケーションも攻撃対象となり、現代のソフトウェアスタック全体に深刻な問題が潜んでいることが改めて浮き彫りになった。 Pwn2Ownとは何か Pwn2Ownは、Trend MicroのZero Day Initiative（ZDI）が主催する年次のハッキング競技会だ。参加者は「これまで公開されていないゼロデイ脆弱性」を使って対象製品の侵害を実演し、成功すれば数万〜数十万ドル規模の賞金を獲得できる。競技後はベンダーに脆弱性が報告され、パッチが提供されるという流れが確立されている。 単なるショーではなく、業界全体の「脆弱性発見サイクル」として機能している点が重要だ。研究者にとっては報酬と名声を得る場であり、ベンダーにとっては本番環境が狙われる前に脆弱性を修正できる機会になる。 今回の標的となったMicrosoft製品 今回のPwn2Own 2026では、Microsoft製品が複数の攻撃成功事例を記録した。 Windows 11 は依然としてハッカーの主要ターゲットであり続けており、権限昇格や任意コード実行につながるゼロデイが実証された。Microsoft Edge はChromiumベースのモダンブラウザーであるにもかかわらず、サンドボックス脱出を含む脆弱性が発見された。Microsoft Exchange は企業メールインフラの中核を担うにもかかわらず、リモートコード実行の可能性を示す脆弱性が実演されている。 さらに今回の特徴として、AIアプリケーションも攻撃対象に含まれており、急速に普及するAIツールのセキュリティ検証がいかに追いついていないかを示す結果となった。 ゼロデイが持つ意味――「今は安全」は幻想 ゼロデイ脆弱性とは、ベンダーが把握していない（あるいはパッチが存在しない）未公開の欠陥を指す。Pwn2Ownで実証されたということは、その脆弱性がMicrosoftに報告されて初めて修正プロセスが始まることを意味する。競技後にZDIからMicrosoftへ通知が行き、通常90日以内のパッチ提供が求められる。 つまり、現時点では「脆弱性は存在するが、パッチはまだない」という状態だ。 実務への影響――日本のIT管理者が今すべきこと Pwn2Ownの結果は「研究者の遊び」で終わらない。以下の対応を即座に検討すべきだ。 Windows Update の適用状況を確認する: ゼロデイが修正されたパッチがリリースされ次第、迅速に適用できる体制を整えておく。特にExchangeはオンプレミス運用の場合、更新が遅れがちな環境が多い。 Exchangeのオンプレミス運用を再評価する: Exchange Onlineへの移行が進んでいる場合、Microsoftがクラウド側でパッチを適用するため管理負荷は大幅に下がる。オンプレミスExchangeを引き続き運用している組織は、今回の結果を移行検討の材料として活用してほしい。 ネットワーク分離と最小権限の徹底: ゼロデイは防ぎきれない前提で動くことが重要だ。攻撃が成功してもラテラルムーブメント（横展開）を防ぐために、ネットワークセグメンテーションと最小権限の原則を徹底する。 AIアプリのセキュリティ評価: 社内で利用中のAIツールについて、セキュリティ評価なしに展開していないか確認する。今回の競技でAIアプリが攻撃対象に含まれたことは、その必要性を裏付ける。 筆者の見解 Pwn2Ownで毎年Microsoftの製品が実証されることは、もはや驚くに値しない。それよりも注目したいのは、Microsoftがこのサイクルに真剣に向き合い続けている点だ。報告された脆弱性に対して90日以内にパッチを提供する枠組みは機能しており、その点は正当に評価できる。 ただ、Exchangeのオンプレミス版が繰り返しターゲットになる現状は、もったいないという思いがある。Microsoftにはクラウドファーストへの移行を強力に後押しできるだけのブランド力とプラットフォームがある。それを活かしきれていないオンプレミスExchangeの延命策が、かえってユーザーのリスクを高めているように見える。 セキュリティは「今動いているから大丈夫」では通用しない。ゼロデイは「発見されていないだけ」の状態が続いているに過ぎない。今回のPwn2Ownの結果を受けて、特にオンプレミスインフラに依存している日本の企業には、クラウド移行やネットワーク設計の見直しを真剣に検討するきっかけにしてもらいたい。 出典: この記事は Windows 11, Microsoft Edge, and Exchange hacked at Pwn2Own の内容をもとに、筆者の見解を加えて独自に執筆したものです。

🤖✍️ この記事はAIとの共同執筆です ── AIエージェント（Claude Code）が胡田との実際の共同作業の経験をもとに下書きを自動生成し、胡田が内容を確認・修正したうえで公開しています。 突然アプリが壊れた続きをみる note.com で続きを読む →

Engadgetは2026年5月15日、セキュリティ研究企業「Calif」（カリフォルニア州パロアルト拠点）が、AnthropicのAIシステム「Claude Mythos Preview」の支援を受けてmacOSの権限昇格エクスプロイトを開発したと報じた。The Wall Street Journalの報道を引用する形で伝えられており、Appleはすでに研究者チームとアップルパーク（クパチーノ本社）で直接面談を行い、脆弱性への対応を進めていることが明らかになっている。 M5シリコンで初確認——何が起きたのか Califの研究者たちは、macOSの権限昇格に使用できる脆弱性を特定し、エクスプロイト（脆弱性を突く攻撃コード）を開発した。このエクスプロイトが悪用されると、通常はアクセスできないMacBook内部の領域に侵入でき、最終的にコンピューター全体を制御される可能性があるという。研究者らはこれを「M5シリコン上で初めて公開されたmacOSカーネルのメモリ破損エクスプロイト」と位置づけている。 Engadgetの報道によると、エクスプロイト開発においてClaude Mythos Previewが重要な役割を果たした。Mythosは既知のバグクラスに属する脆弱性を迅速に特定することができ、潜在的な攻撃経路の洗い出しを助けた。ただし、エクスプロイトの設計そのものには依然として人間の専門知識が必要だったとされており、AIが「完全自律」で脆弱性を武器化できる段階ではないことも示されている。 海外レビューのポイント EngadgetおよびThe Wall Street Journalの報道から読み取れる評価ポイントは以下の通りだ。 注目すべき良い点 AIが既知クラスの脆弱性を高速で特定できることを実証した初のパブリックな事例 研究者がAppleと連携して修正前に情報を共有する「責任ある開示（Responsible Disclosure）」プロセスを遵守 脆弱性の詳細はAppleのパッチ提供後に公開予定であり、悪用リスクを最小化する配慮あり 気になる点 悪意ある攻撃者が同じアプローチを採用した場合、パッチ適用前に攻撃を仕掛けられるリスクが現実化しつつある 「M5チップ搭載Mac」という具体的なターゲットが示されており、最新ハードウェアが対象であることは見逃せない Project Glasswing——防御側のAI活用も加速 本件の背景には、Anthropicが2026年4月に立ち上げた「Project Glasswing」がある。AIによるサイバー攻撃をAIで防ぐことを目的としたイニシアチブで、AWS、Apple、Cisco、CrowdStrike、Google、JPMorganChase、Linux Foundation、Microsoft、NVIDIA、Palo Alto Networksが参加している。 実績としては、MozillaがGlasswingの枠組みでMythosを活用し、Firefoxの最新リリースで271件の脆弱性を発見・修正済みであることが報告されている。 一方、OpenAIは同イニシアチブへの対抗として「Daybreak」を発表。専用セキュリティエージェント「Codex」を中心に据え、「ソフトウェア開発の初期段階からサイバー防御を組み込む」という設計思想を掲げている。AI各社がサイバーセキュリティ分野での主導権を競う構図が鮮明になりつつある。 日本市場での注目点 現時点でAppleはパッチをリリースしておらず、脆弱性の技術的詳細も非公開だ。M5チップ搭載MacBookを使用している場合、Appleのセキュリティアップデートを速やかに適用することが最善策となる。Appleのセキュリティ情報は公式のsecurity.apple.comで随時更新されるため、企業の情報システム部門は定期的な確認と迅速なパッチ適用プロセスの整備を今から進めておきたい。 日本企業にとってより大きな示唆は、「AIが脆弱性発見を劇的に加速させる時代に入った」という認識を組織として持つことだ。これまで専門家が数週間かけて行っていた脆弱性探索が、AIの支援によって大幅に短縮される。攻撃側も防御側も同じツールを使える以上、対応スピードと体制の整備が競争力を左右する。 筆者の見解 今回の事例が示す最も重要な点は、AIエージェントがセキュリティ研究において「補助ツール」の域を超え、実質的な「共同研究者」として機能しはじめているということだ。 興味深いのは、AIが既知バグクラスのパターンを素早く当てはめて脆弱性探索を加速できる一方、エクスプロイトの設計には依然として人間の専門知識が必要だったという点だ。これは現時点でのAIの能力の正直な限界を示しており、「AIがすべてを自動化する」という過剰な期待への良いブレーキになる。 防御側の視点では、Project GlasswingのようなAI活用の仕組みを組織として持つことが今後必須になるだろう。「AIをどう制限するか」という議論に終始するのではなく、「AIを活用しながらどう安全を確保するか」という実践的なフレームで取り組む組織が、次のセキュリティ環境で優位に立つはずだ。攻撃者がAIを使うなら、防御側もAIで応じるしかない——それが現実だ。 出典: この記事は Security researchers, aided by Anthropic’s Mythos, claim to have breached macOS の内容をもとに、筆者の見解を加えて独自に執筆したものです。

英国の税務当局HM Revenue & Customs（HMRC）が、英国AIスタートアップQuantexaと10年間・1億7500万ポンド（約340億円）の大型契約を締結した。BBCおよびEngadgetが2026年5月15日に報じたもので、政府機関によるAI活用の新たな事例として国際的な注目を集めている。 Quantexaとは──データ統合型AIの専門企業 2016年にロンドンで創業されたQuantexaは、データアナリティクスと意思決定支援に特化したAI企業だ。HMRCが保有する税務データに外部データソースを組み合わせ、詐欺の兆候を早期に発見する仕組みを提供する。用途は詐欺・申告ミスの検出にとどまらず、誤った参照番号で処理された正規の支払い追跡、カスタマーサービスの効率化にも及ぶという。すでにスイスのZurich Insurance Groupとも協業しており、金融・政府分野での実績を着実に積んでいる。 海外レビューのポイント：「ブラックボックスであってはならない」 BBCのレポートによると、Quantexa CEOのVishal Marria氏は設計思想について明確に語っている。「政府環境においてAIはブラックボックスとして機能してはならない。意思決定は透明性・監査可能性・説明可能性を持たなければならない。特に市民に直接影響を与える分野では」という発言は、政府系AI導入の要件を端的に示している。 また、Quantexaは「HMRCのデータをHMRC環境の外に持ち出すことは絶対にない」と明言し、データ主権への配慮も示した。AIの判断結果は最終的に人間のスタッフが確認する運用設計を採用しており、誤検知による冤罪リスクへの対策も明示されている。 世界で広がる政府機関のAI活用 政府によるAI活用はすでに米国でも実績を出している。米財務省（IRSを管轄）は2024年、AI活用によって2023年10月〜2024年9月の1年間で40億ドル超の詐欺を防止・回収したと報告している。英国の今回の動きは、こうした世界的な行政AI化の潮流に沿ったものだ。 日本市場での注目点 日本の国税庁もe-Tax普及やAI活用の検討を進めているが、HMRCのような長期・大型AI契約の公表事例はまだ少ない。HMRCの10年・340億円という規模感は、日本の行政DXの現状と比較したとき、投資規模・コミットメントの差を感じさせる。 一方、税務分野のAI活用は「データの正確性」と「市民への影響」が直結するため、日本でも「説明可能なAI」への要件が議論の中心になると予想される。Quantexaのような透明性・説明可能性を重視したアーキテクチャを持つ企業の存在感が、今後高まる可能性がある。 筆者の見解 今回の事例で最も注目すべきは、「AIの結果を人間が最終確認する」設計を明示的に採用している点だ。 AIエージェントの本質的な価値は自律性にある、というのが筆者の基本的な立場だ。ただし、税務調査のように「誤判定が直接市民の生活に影響する」高リスク領域では、人間の最終関与を設けることは現時点では合理的な判断だと思う。これは「AIを補佐役に留める」という後退ではなく、「自律性を段階的に拡張するための土台作り」として捉えるべきだろう。 CEOが強調した「ブラックボックスであってはならない」という言葉は、長期的な自律エージェント展開にとっても不可欠な前提だ。説明可能で監査可能なAIであることは、信頼を積み重ねてより高い自律性を得るための条件でもある。 10年・340億円という長期コミットメントは、英国政府のAIへの本気度を示している。日本の行政機関も「まずパイロット」から脱却し、成果に基づいた大規模投資に踏み切るフェーズが来ているのではないだろうか。 出典: この記事は The UK’s tax authority is turning to AI to help identify fraud の内容をもとに、筆者の見解を加えて独自に執筆したものです。

OpenAIが、自社のAIコーディング支援ツール「Codex」をデータサイエンスチームが実務にどう使えるかを体系化し、根本原因ブリーフ・影響レポート・KPIメモ・スコープ分析・ダッシュボード設計という5つのユースケースとして公式に整理・公開した。単なる機能紹介にとどまらず、実際の業務インプットを使ってどう活用するかを具体的に示した内容となっている。 Codexとは OpenAI Codexは、OpenAIが開発したAIを活用したコーディング・分析支援ツールだ。ChatGPTに統合された形や、CLIツール、さらにはAPIを通じたワークフロー組み込みなど複数の利用形態がある。自然言語の指示でコードを生成したり、データ分析を自動化したりする能力に特化しており、データサイエンス・データエンジニアリング領域での活用が広がっている。 5つの実務ユースケース 1. 根本原因ブリーフ（Root-Cause Briefs） 指標の急変・異常値が出たとき、その原因を探るための分析レポートを自動生成する使い方だ。「先週の売上がなぜ落ちたか」「DAUが急減した背景は何か」といった問いに対し、実データを入力として渡すことで、仮説立案から統計的検証のコードまでをCodexが補助する。データアナリストが手作業で行っていた「異常検知→原因仮説→検証クエリ作成」のサイクルを大幅に短縮できる。 2. 影響レポート（Impact Readouts） 新機能リリース・キャンペーン実施・システム変更といった「介入」の前後でどんな変化があったかを測るレポートの自動生成だ。A/Bテストの集計コードや可視化スクリプトをゼロから書く工数が減り、施策の評価サイクルを速めることができる。 3. KPIメモ（KPI Memos） 定期的に作成が求められるKPIの現況サマリーレポートを半自動化する用途だ。実績データと目標値をCodexに渡し、差異の解説文とグラフ生成コードを生成させる。マネジメント層への定例報告資料作成の手間を削減する使い方として有効だ。 4. スコープ分析（Scoped Analyses） 「この商品カテゴリだけ」「この地域のユーザーだけ」といった特定条件に絞った分析を素早く実施するためのコード生成だ。要件を自然言語で渡し、対応するSQL・Pythonのクエリ・集計ロジックを自動生成することで、スポット的な分析依頼への対応スピードが上がる。 5. ダッシュボード仕様（Dashboard Specs） Tableau・Looker・Metabaseなどに向けたダッシュボードの設計仕様書・設定コードを生成する用途だ。「このKPIをこのグラフで見たい」という自然言語の要求から、実装に使える仕様を出力させることができる。 日本のデータ分析チームへの影響 データサイエンスチームの工数の多くは、実際には分析そのものよりも「レポートを書くこと」「コードを書くこと」「定例資料を作ること」に費やされている。上記5パターンはまさにそのコモディティな繰り返し作業をAIに委ねるアプローチだ。 特に中規模以下のチームでは専任アナリストが少なく、エンジニアが分析と可視化を兼任することも多い。Codexのようなツールを使えば、PythonやSQLの習熟度が中程度のメンバーでも、上位メンバーが書くような水準のコードを素早く生成できる。 重要なのは「コードを書いてもらう」だけでなく、分析の流れ（フレームワーク）ごとテンプレート化できる点だ。根本原因分析なら「どんな問いを立てるか」「どのデータを見るか」「どう解釈するか」という思考の枠組みをプロンプトに落とし込むことで、チーム全体の分析品質を底上げする可能性がある。 実運用上の注意点 日本の現場では、日本語のカラム名・変数名・コメントが混在するデータベース環境でのプロンプト設計の工夫が必要になる。また、社内データをクラウドAPIに送ることへの情報セキュリティ上の懸念も事前に確認しておきたい。データの機密分類と利用可能なAIツールのポリシーを組み合わせた社内ガイドラインを整備することが、スムーズな導入の前提条件となる。 筆者の見解 データサイエンスチームの「繰り返し業務」を自動化するという方向性は、AI活用の本質を突いている。大事なのは「コードを生成してもらうこと」ではなく、定型的な思考プロセス自体をAIに委譲できるかどうかという問いだ。 OpenAIがこうしたユースケースを公式に整理してくれることには実用的な価値がある。特にAI導入を検討している企業にとって、具体的な利用パターンは社内提案や説得の材料になる。 一方で気になるのは、個々のタスクに対してCodexに問いかけてコードを受け取るという使い方は、まだ「副操縦士」的な枠組みにとどまっているという点だ。本当に価値が出るのは、分析パイプライン全体を自律的に回し続ける仕組みを作ったときではないか。「根本原因ブリーフが必要なとき」に人間が気づいて指示する形から、「異常を検知したら自動でブリーフが生成される」形へ進化してはじめて、チームの認知負荷が本質的に下がる。 「どんな繰り返し作業が社内に存在するか」を棚卸しして、そこに自律的なエージェントの仕組みを仕込む設計こそが今の優先事項だと考えている。そのための出発点として、今回のユースケース整理は参考になる素材だ。 出典: この記事は How data science teams use Codex の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIコーディングアシスタントが単純な補完ツールを超え、アプリ開発からデバッグまでをこなす「自律型エージェント」へと進化するなか、Tom’s GuideのライターAmanda Caswellが、AnthropicのClaude CodeとOpenAIのCodexを実際のアプリ開発3本で比較した詳細レビューを2026年5月17日に公開した。 なぜこの比較が注目されるのか AIコーディングエージェントの競争は「どちらが賢いか」から「どちらが実際に使えるプロダクトを作れるか」へとフェーズが移っている。Claude CodeとCodexはいずれも自然言語の指示からアプリを丸ごと生成できるが、設計思想の違いが使い勝手に大きな差をもたらす。Tom’s Guideの今回の検証は、その差をサブスクリプション管理・食料品価格比較・ローン計算という「実際に誰かが欲しいと思うツール」の開発を通じて浮き彫りにしようとした点で価値がある。 海外レビューのポイント テスト1：サブスクリプション管理アプリ プロンプト： サブスクリプション名・月額・更新日を入力すると月間・年間の支出合計を表示し、7日以内に更新されるものをハイライトするWebアプリ。データは保持すること。 Claude Code（勝利）： 数秒で本番投入レベルの完成アプリを生成。手動入力と一括インポートの両方に対応したUIを即座に提供し、デプロイまで完結していた。 Codex： データ処理・計算ロジックは優秀で、起動直後から財務内訳が確認できた。ただし手動デプロイが必要で、使い始めるまでのハードルが高かった。 Caswellは「Claude Codeはプロダクションレディなアプリをすぐに提供した」と評価している。 テスト2：食料品価格比較ツール プロンプト： 2つの店舗の品目ごとの価格を比較し、最安値で購入した場合の節約額を計算。支出の時系列推移もトラッキングする。 Claude Code： HTMLのCanvasを使った依存関係ゼロの自己完結型設計。サンプルデータ（牛乳・パン・卵）をあらかじめ表示し、すぐに操作できる体験を優先した。 Codex（勝利）： タブナビゲーション・一括インポート・Chart.jsによる高度なグラフ可視化を搭載。実際の買い物シーンを想定した機能の充実度でClaude Codeを上回った。 Tom’s Guideの評価では「Codexの機能セットとデータ入力の柔軟性、節約額の分析表示が現実のショッピングシーンに適している」とされている。 2つのエージェントの設計思想 Caswellのレビューを通じて浮かび上がるのは、Claude Codeは「即使える完成品」を優先し、Codexは「機能の深さとカスタマイズ性」を優先するという設計思想の違いだ。初心者や「まず動くものが欲しい」ユーザーにはClaude Codeが、機能の作り込みや分析ダッシュボードを求めるユーザーにはCodexが向くという分析になっている。 日本市場での注目点 Claude Code： Anthropicのプロプランに組み込まれた形で提供。日本語プロンプトや日本語コメント生成も問題なく動作し、国内の個人開発者・スタートアップでの採用が急増中。 OpenAI Codex： 2026年5月時点でChatGPT ProおよびEnterpriseユーザー向けに展開中。価格帯はClaude Codeと同水準。 両ツールとも、VSCode等のIDE補完型とは根本的に異なるターミナル・ブラウザベースの自律動作が軸足であり、従来のGitHub Copilot的な使い方とは別物として理解する必要がある。 筆者の見解 Tom’s Guideの検証が興味深いのは、評価軸を「どちらが高性能か」ではなく「どちらが実際に使えるプロダクトを作るか」に置いた点だ。 AIコーディングエージェントの本質的な価値は、コードを生成する速さではなく「人間が確認・修正・デプロイに費やす認知コストをどこまで削減できるか」にある。その観点から見ると、即デプロイ可能な成果物を出したClaude Codeのアプローチは、エージェントが目指すべき方向性に近い。一方でCodexがテスト2で見せた機能の充実度は、ツールの成熟度を示す別の指標でもある。 重要なのは「どちらが優れているか」という問い自体が、タスクの性質とユーザーのスキルレベルによって答えが変わるという点だ。日本の開発者・IT担当者にとってこうした比較記事の価値は、「どちらを選ぶか」を決めることより、AIエージェントに何を期待すべきかという認識を更新する機会として活用することにある。情報を追い続けるより、実際に手を動かして使った経験が確実に実力になる。まず試してみること、それが今の時代に最も正しい行動だ。 出典: この記事は Claude Code vs. OpenAI Codex: I built 3 real apps to find the better agent— here’s the verdict の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

🤖✍️ この記事はAIとの共同執筆です ── AIエージェント（Claude Code）が胡田との実際の共同作業の経験をもとに下書きを自動生成し、胡田が内容を確認・修正したうえで公開しています。 はじめに続きをみる note.com で続きを読む →

PwC（プライスウォーターハウスクーパース）とAnthropicは2026年5月14日、戦略的アライアンスの大幅拡大を発表した。「Claude Code」と「Claude Cowork」を米国チームから順次展開し、最終的にはグローバルで数十万人規模のプロフェッショナルへ提供する。コンサルティング大手がLLMを全社のコア業務ツールとして採用する史上最大規模の事例となり、AI時代における知識労働の再定義を鮮明に示す一手だ。 発表の主要ポイント 今回の提携拡大における主な内容は以下のとおりだ。 Claude Code・Coworkの全社展開：米国チームからスタートし、グローバルの数十万人のプロフェッショナルへ段階展開 共同センター・オブ・エクセレンス設立：PwC社員3万人を対象にClaudeのトレーニングと認定資格プログラムを提供 新ビジネスグループ「Office of the CFO」創設：PwCの財務専門知識とAnthropicの全製品スイート（Claude、Claude Cowork、Claude Code）を組み合わせた独立ビジネスユニット。規制産業（銀行・保険・医療）からスタート 3つの重点領域 1. エージェント型テクノロジービルド エンジニアリングチームがClaude Codeを活用し、従来は「四半期」単位だった本番ソフトウェアの開発を「数週間」で完了させている。金融サービス、製薬・ライフサイエンス、ヘルスケア、消費財など幅広いセクターでの実績が積み上がっている。 2. AIネイティブなM&A・ディール実行 デューデリジェンスから価値創造、PMI（統合）まで、M&Aプロセス全体をAIエージェントがディールチームと並走して実行する。プライベートエクイティや企業買収担当者にとって、投資テーマから価値実現までの期間が大幅に圧縮される。 3. 企業機能の全面再設計 財務、サプライチェーン、HR、エンジニアリング機能そのものをAIネイティブなオペレーティングモデルで作り直す。多くの企業がまだパイロット段階で止まる中、PwCはすでに本番稼働フェーズに入っている点が際立っている。 本番稼働で出た実績数値 すでに複数の業界で具体的な成果が確認されている。 業務領域 従来 Claude導入後 保険の引受審査 10週間 10日（約1/7） セキュリティ作業 数時間 数分 デリバリータイム（全体） ― 最大70%削減 対象業界はプロスポーツ運営、保険引受、メインフレームのモダナイゼーション、HR変革、サイバーセキュリティなど多岐にわたる。 日本のエンジニア・IT管理者にとっての意味 「精度が必要な業務にはAI不可」という先入観への反証 日本企業の多くはAI活用において「正確性が求められる金融・医療・法務系業務には適用できない」という慎重論が根強い。PwCの事例は保険の引受審査や財務変革など、まさにその「正確性・監査可能性が非交渉な領域」で本番稼働している点で、この先入観を覆す有力な参照事例となる。 Claude Codeが「開発者専用ツール」を超えた位置づけへ 注目すべきは、Claude Codeがエンジニア向けだけでなく、コンサルタントや業界専門家が使う「業務ツール」として全社展開される点だ。エンジニア以外の職種でもコード生成やエージェントによる作業自動化が前提になる世界が、大手コンサルでは現実になりつつある。 「検討」から「本番展開」へのギアチェンジ PwC CEOポール・グリッグス氏の言葉——「AIをめぐる議論は可能性から実行へシフトした」——は2026年の企業AI活用の現在地を端的に示している。日本のIT部門も、「検討中」「PoC実施中」というフェーズを脱し、本番展開の設計に頭を切り替えるタイミングが来ている。 筆者の見解 今回の発表で最も注目したいのは、成果数値の背景にある「設計思想」の部分だ。 保険審査が10週間から10日になった、セキュリティ作業が数時間から数分になった——これらの数字は、エージェントが人間の確認を逐一待つ「副操縦士モデル」では到底達成できない。ディールチームと並走してデューデリジェンスから統合まで自律的に走り切る設計、すなわちエージェントがループで連続稼働する仕組みがあって初めて出てくる数字だ。この設計の違いが、「試験運用で数%の効率化」と「業務時間が10分の1」の差を生んでいる。 もう一点、3万人の認定プログラムという数字も見逃せない。ツールを配備するだけでは業務変革は起きない。PwCは展開と教育をセットで設計している。日本の企業が同様の成果を目指す際も、「ライセンスを購入して終わり」では数字は出ないはずで、この点は冷静に参考にすべきだろう。 日本のコンサルティング会社やSIer各社にとって、この事例はもはや対岸の火事ではない。本番稼働の実績数値が公表された以上、「様子見を続けるリスク」が「早期参入のリスク」を超えてきている。自社のどの業務領域から着手するかを今すぐ考えるべき段階に来ている。 出典: この記事は PwC is deploying Claude to build technology, execute deals, and reinvent enterprise functions for clients の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

2026年5月のSAP Sapphireカンファレンスにて、SAPとAnthropicは戦略的提携を正式発表した。AnthropicのAIモデル「Claude」が持つエージェンティックAI機能を、SAPが新設した「SAP Business AI Platform」に組み込み、SAPの全AI製品ポートフォリオに展開する計画だ。 SAP Business AI Platformとは何か SAP Business AI Platformは、SAPがビジネスアプリケーション向けに構築するAIインフラ基盤だ。財務・人事・サプライチェーン・調達といった基幹業務領域に、AI機能を統合的に提供するためのプラットフォームとして位置づけられている。 これまでSAPは自社AIアシスタント「Joule」を中心にAIを展開してきた。今回の提携でAnthropicのClaudeを採用することで、エージェンティックAIの高度な推論・計画・実行能力をSAPのビジネスプロセス全体に活用できるようになる。 「エージェンティックAI統合」の技術的な意味 「エージェンティックAI」とは、単純な質疑応答ではなく、目的を与えられると自律的に計画を立て、複数のステップを実行し、結果を検証するAIの動作様式を指す。 従来のERP × AIの統合は「チャットボットでデータを検索する」レベルに留まることが多かった。今回の提携が目指すのはその先だ。たとえば「月次決算の異常値検知 → 関係者へのアラート → 修正仕訳の提案 → 承認ワークフローの起動」といった一連のプロセスを、AIが自律的に進める仕組みの実現だ。ERPをAIのデータソースとして使うのではなく、ERPのビジネスプロセス自体をAIが動かすという設計思想の転換である。 日本企業への実務的影響 日本の大手・中堅企業の多くがSAPを基幹システムとして利用している。今回の統合は、これらの企業にとってAI活用の入口を大きく変える可能性がある。 具体的な活用ポイント： 会計・財務自動化の高度化：月次・四半期決算プロセスにおける例外処理や仕訳確認をAIエージェントが担当し、人間は例外の最終判断に集中できる。 サプライチェーン最適化：需要予測の外れ値発生時に、AIエージェントが自動で調達計画を見直し、サプライヤーへの発注調整まで一気通貫で実行できる。 HR業務の効率化：採用・育成・異動のサイクルでデータドリブンな意思決定をAIが支援し、HRBPが戦略的な仕事に集中できる環境を作る。 BTP（SAP Business Technology Platform）との統合：既存のBTP環境を持つ企業は、追加インフラなしにClaudeベースのエージェンティック機能を試験導入できる可能性がある。 今すぐできる準備 発表を受けて、今動けるアクションを整理しておきたい。 SAP S/4HANA Cloud利用企業：Sapphireで発表された詳細なロードマップをSAPパートナーに確認し、テナントへの展開時期を把握しておく。 オンプレミスSAP利用企業：クラウド移行の優先度を再評価するタイミングかもしれない。AI統合の恩恵はクラウド版から先に届く。 IT部門・SAP管理者：エージェンティックAIが自動実行できる業務スコープの洗い出しと、必要な承認フローの設計を今のうちに始める。 筆者の見解 今回の発表で注目したいのは、「ERPをAIのデータソースにする」のではなく「ERPのビジネスプロセス自体をAIが動かす」という設計思想への転換だ。AIエージェントが自律的にループで動き続ける仕組みこそが次のフロンティアだと考えているが、それをERPという企業の基幹データと業務プロセスに組み込むという方向性は理にかなっている。 日本企業にとって現実的な課題は、「AIに何を自動化させてよいか」というガバナンスの設計だ。すべてを人間が承認し続ける設計ではエージェンティックAIの本質的なメリットを得られない。一方で、何でも自動化すれば統制が崩れる。この境界線を業務ごとに定義してドキュメント化しておくことが、今すぐ取り組むべき準備だと感じている。 SAP Sapphireでの発表は方向性を示したものであり、具体的なロードマップが出てから本評価になる。大きな方向性は正しい。日本企業の現場がこの波に乗り遅れないよう、まずは自社のSAP活用状況の棚卸しから始めることをお勧めしたい。 出典: この記事は SAP and Anthropic: Claude on SAP Business AI Platform | SAP Sapphire の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft が Microsoft Planner の大規模刷新を2026年に実施する。タスクへのチャット機能、カスタムテンプレート、Copilot AI統合の3つの新機能を追加する一方、iCal（iCalendar）フォーマットのサポートを廃止する予定で、カレンダー連携を利用しているユーザーは早急な移行対応が求められる。 Microsoft Planner 2026年刷新の全容 タスクチャット機能 新たに追加される「Task Chat（タスクチャット）」は、各タスクの中でメンバーと直接会話できる機能だ。これまでPlannerを使うチームは、タスクの詳細について別途Teamsのチャットやメールでやりとりしなければならず、「どのタスクについての話か」という文脈がすぐに失われる課題があった。 タスクチャットが実装されることで、タスクとコミュニケーションが一体化される。誰が何を発言したかの履歴がタスクに紐づいて残るため、後から参加したメンバーがキャッチアップしやすくなる点もメリットだ。 カスタムテンプレート 「Custom Templates（カスタムテンプレート）」機能により、組織独自のプロジェクト計画テンプレートを作成・保存・再利用できるようになる。毎回ゼロから作っていたプロジェクト計画をテンプレート化することで、スタート時のセットアップ工数を大幅に削減できる。特に繰り返し型のプロジェクト（月次業務、リリースサイクル管理など）を多く抱えるチームには即効性が高い機能だ。 Copilot AI統合 Copilot AI との統合により、タスクの提案、進捗のサマリー、次のアクション自動生成といった機能が Planner 内に統合される予定だ。プロジェクト管理の定型的な判断をCopilotが補助する形となる。 iCalサポートの廃止 特に注意が必要なのが「iCal（iCalendar）フォーマットのサポート廃止」だ。PlannerのタスクをGoogleカレンダーやAppleカレンダーへ購読するために使われてきたiCal形式のURLのサポートが終了する。既存の購読リンクは無効になるため、現在利用しているユーザーは代替手段への移行が必要になる。 日本のエンジニア・IT管理者が今すぐやるべきこと iCal廃止への対応（最優先） iCalの購読リンクを社内でどこが利用しているかを今すぐ調査してほしい。特に以下のシナリオで使われているケースが多い： 外部ツール連携: GoogleカレンダーやAppleカレンダーとPlannerを連携している 社内ダッシュボード: Power BIや社内ポータルにPlannerのタスクをカレンダー表示している サードパーティ製PMツール連携: iCalフィードを受け取るタイプのツールとの連携 廃止前に代替手段（Microsoft Graph API経由のカレンダー連携、Outlookカレンダーとの直接同期）を検証し、移行計画を立てることを強くお勧めする。 タスクチャットの活用ルールを先に決める タスクチャットはTeamsのチャットとの住み分けが鍵になる。「プロジェクトのタスクに関する会話はPlannerのタスクチャットへ」「日常的な雑談や素早い確認はTeams」という使い分けをチーム内でルール化することで、情報の散逸を防ぐことができる。機能がリリースされてから「どこに書けばいいのか」が曖昧になるよりも、事前にルールを決めておく方が定着は早い。 テンプレート整備の準備を今から カスタムテンプレート機能がリリースされた際にすぐ活用できるよう、「自チームで繰り返し使っているプロジェクト計画の型」を今のうちに洗い出しておこう。候補リストを準備しておくだけで、機能リリース直後から業務効率を引き上げるスピードが変わる。 筆者の見解 今回のPlannerの刷新は、Microsoft が「タスク管理をTeams・Outlook・Loopと統合された体験にしていく」という方向性の一環として見ている。タスクチャットはその象徴的な機能で、バラバラになりがちなコミュニケーションとタスクを一体化する方向性は正しい。 Copilot AI統合については、正直なところ「どこまで実用的になるか」を見極める段階だ。タスク管理AIに本当に必要なのは機能の網羅性よりも「現場で使い物になる精度」だと思っている。Microsoftにはその技術力があるはずで、具体的なシナリオで精度を出せるかどうかに注目したい。 iCalの廃止は移行コストが発生するのは避けられないが、長期的にはMicrosoft 365エコシステム内で一貫した連携体験に集約されていく方が全体最適につながる。「標準の仕組みで動いている前提」を崩さないよう、移行は計画的に進めてほしい。 Plannerはこれまで「軽量タスク管理ツール」として中途半端な立ち位置にあった印象があるが、今回の刷新でTeams・Outlook・Loopとの統合が深まれば、Microsoft 365の中核的なワークフロー基盤になり得る可能性を秘めている。その可能性を本当に引き出せるかどうか、今後のロードマップに注目している。 出典: この記事は Microsoft Planner 2026 Overhaul: Task Chat, Custom Templates, Copilot AI, iCal Retirement の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Microsoft 365 Copilotに、カレンダー管理を自動化するCalendar Agent機能が追加された。自然言語でルールを定義するだけで、Copilotが会議の承認・辞退・削除を自動実行する。2026年4月下旬〜5月上旬にかけてFrontierプログラム向けにロールアウトが始まっており、既存のコンプライアンスポリシーや管理者設定をそのまま引き継ぐ形で動作する。 Calendar Agentとは何か Calendar Agentは、Copilot Chatのカレンダー関連サーフェスから利用できる新しいエージェント機能だ。ユーザーが「Copilot Chatで『Allow Actions』を選択」することで有効になり、以下のような自然言語のルールを設定できる。 「上司からの会議招待は、空き時間があれば常に承認する」 「キャンセルされた会議は自動的にカレンダーから削除する」 「勤務時間外の会議は辞退する」 ルールはCopilotが継続的に評価し、条件に合致した際に自動でアクションを実行する。操作の履歴は「承認・フォロー・辞退・削除」のカテゴリ別にまとめられたアクティビティ履歴ビューで確認でき、各アクションの理由も表示される。 対応プラットフォームと前提条件 本機能が利用できる環境は以下の通りだ。 プラットフォーム 対応状況 Outlook（クラシック版・新版） ◎ Outlook on the web ◎ Microsoft Teams ◎ Outlook モバイル（iOS / Android） ◎ 前提条件はMicrosoft 365 Copilotライセンスの保有と、既存のCopilotエージェントポリシーによる利用許可のみ。新たな管理者設定は一切不要で、テナントのコンプライアンス境界・データ保持・監査ログの動作も変わらない。 注意点として、Calendar Agentが操作できるのはサインイン中のユーザー自身のカレンダーのみであり、他のメールボックスやテナントをまたいだ操作は行われない。 IT管理者が準備すべきこと Microsoftは「追加の準備作業は不要」と説明しているが、実務上は以下の確認を推奨する。 既存のCopilotエージェントポリシーの確認: どのユーザーが「Allow Actions」を有効化できるかを把握しておく ヘルプデスクへの事前共有: ユーザーが設定を有効にすると、Copilotが自動でカレンダー操作を行うようになる。問い合わせ増加の可能性に備える 内部ガイドラインの更新: Copilot利用ポリシーやOutlook操作手順書がある組織は、Calendar Agentの動作について追記を検討する 機能はCopilotエージェントを許可されているユーザーに対してデフォルト有効となるが、ユーザー自身が「Allow Actions」を選択するまでエージェントは動作しない。誤操作リスクは低いが、自動化の動作範囲をエンドユーザーに周知しておくことが重要だ。 実務への影響——日本のエンジニア・IT管理者にとっての意味 日本の職場では「とりあえず招待しておく文化」によって、一人あたり週数時間がカレンダー管理に消えているケースが珍しくない。Calendar Agentが機能すれば、こうした定型判断の多くをCopilotに委譲できる。 ただし、日本特有の「断ること自体への心理的ハードル」を考えると、辞退ルールの設定はデリケートな場面がある。「上位職の会議招待を自動辞退してしまった」という状況を防ぐため、最初は「キャンセル済み会議の自動削除」のような低リスクなルールから試すのが現実的なアプローチだろう。 IT管理者の観点では、既存のExchange/Outlookガバナンスに乗っかる設計であるため、導入コストは最小限に抑えられる。Copilotエージェントの利用を全社で許可している組織であれば、追加作業なしで即日展開可能だ。 筆者の見解 Calendar Agentが目指す方向性は正しいと思う。カレンダー管理は誰もが「AIに任せたい」と感じる典型的な定型業務であり、自然言語でルールを設定できる仕組みはユーザーフレンドリーだ。 ただ、ここで正直に言っておきたい。Copilotはこれまで、こうした「使えるかもしれない」機能を何度も発表してきた。期待して試してみると、精度や動作の安定性でがっかりするサイクルが続いている。Calendar Agentについても、まずはFrontierプログラムでの実績を見極めたい。 Microsoftが持つOutlook・Exchange・Teamsとのネイティブ統合の深さは、他のどのプレイヤーにも真似できない強みだ。その基盤の上にCalendar Agentが確実に動くなら、カレンダー管理における最も自然な選択肢になりうる。その実力を、今度こそ本番環境で見せてほしいと思っている。 アクティビティ履歴ビューの実装は特に評価したい。AIが自動で操作した内容を事後確認できる透明性の確保は、信頼構築の第一歩として正しいアプローチだ。こういった地道な品質への投資が積み重なることで、Copilotへの信頼が少しずつ回復していくことを期待している。 出典: この記事は Introducing Calendar Agent capabilities in Microsoft 365 Copilot の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

🤖✍️ この記事はAIとの共同執筆です ── AIエージェント（Claude Code）が胡田との実際の共同作業の経験をもとに下書きを自動生成し、胡田が内容を確認・修正したうえで公開しています。 はじめに続きをみる note.com で続きを読む →

CircuitMessは2026年4月、NASAアルテミスミッション公式ライセンス製品「Artemis Watch 2.0」を$129（約19,000円）で発売した。デザイン・テックメディア「Yanko Design」のSarang Sheth氏が詳細レポートを公開しており、本稿ではその内容を紹介する。 NASAアルテミスIIミッションとのタイミング 発売は、NASAのアルテミスII有人月周回ミッション（2026年4月1日打ち上げ）と時期を合わせたものだ。Reid Wiseman、Victor Glover、Christina Koch、Jeremy Hansenの4名が搭乗するOrion宇宙船はアポロ13号以来最も遠い有人飛行を実現しており、宇宙探査への関心が世界的に高まるタイミングでの製品投入となった。 スペックと機能 主な仕様: プロセッサ: ESP32-S3 デュアルコア ディスプレイ: フルカラーLCD センサー: 加速度計・ジャイロスコープ・コンパス・温度センサー 接続: Bluetooth（iOS/Android対応） バッテリー: Li-Po（USB-C充電） サイズ: 約45×13×70mm（1.77×0.5×2.76インチ） 対象年齢: 9歳以上 価格: $129 ファームウェアはGitHubでオープンソース公開されており、Python・ビジュアルブロックコーディング環境「CircuitBlocks」・Arduino IDEの3つの環境から自由に選択できる。組み立て不要で、箱から出してすぐに使える完成品として出荷される点も特徴だ。 海外レビューのポイント Yanko DesignのSarang Sheth氏のレポートによると、本製品の核心は「完成品として動作しながら、ソフトウェアのすべてのレイヤーを書き換えられる」という二重性にある。 高く評価された点: CircuitBlocksによる入門から、PythonやArduino IDEを用いた本格的なコーディングへ、段階的に移行できる設計 ファームウェアがオープンソースであり、プロプライエタリなロックインが一切ない デュアルコアESP32がBluetoothペアリングとリアルタイムセンサー処理を並行して担当できる十分な性能 温度ログ、コンパス方角によるアラート、歩数カウンターなど、センサーを活用した実用的なコーディング課題が多数考えられる構成 Sheth氏は「このカテゴリで$129の価値がある数少ない製品のひとつ」と結論づけている。 バンドル構成と価格 単体: $129 Mars Exploration Bundle（Perseverance Roverとのセット）: $399（単品合計より約23%割引） Collector’s Bundle（ウォッチ＋公式ストラップ4種）: $149 CircuitMessはこれまでに世界で30万以上のキットを販売した実績を持つ。 日本市場での注目点 現時点では国内正規代理店・国内ECでの取り扱いは確認されていない。circuitmess.comからの直接購入の場合、国際送料・関税を含めると実質$150〜$170程度になる可能性がある。 国内で入手しやすいSTEM教育向けプログラマブルデバイスとしては、BBC micro:bitやM5Stackが代表的な競合となる。これらと比較すると、Artemis Watch 2.0はウェアラブル形態とNASAブランドが差別化ポイントだが、micro:bitのような充実したエコシステム・教材のそろいには及ばない。一方、完成品として即使えるウォッチ型という形態は、学習の入口としての敷居を大きく下げる。 筆者の見解 STEM教育向けデバイスは数多くあるが、Artemis Watch 2.0で注目すべきは「すぐ動く完成品」と「ファームウェアまで完全に手が届く」という両端を両立している設計だ。 多くの教育ガジェットは、動作させること自体が難関となり、コードを書く体験に至る前に挫折しやすい。このウォッチは、温度変化のロギングやコンパス方角による動作トリガーといった「実際に意味のある何かを作る」体験に早く到達できる構造になっている。情報を追うより手を動かして成果を出す経験を積む、という観点からすると、センサーとコードが直結しているハードウェアは有効な学習環境だ。 NASAのアルテミスという実際のミッションと連動しているという文脈も、「リアルの出来事とコードがつながる」動機付けとして機能しうる。日本での正規流通が整えば、プログラミング教室や学校教育での採用も十分視野に入るスペックと価格感だ。現状は個人輸入が前提になるが、STEM教育を本気で考えている家庭・教育機関にとっては検討する価値のある一台だろう。 出典: この記事は The NASA Artemis 2.0 Smartwatch Runs Python And Lets Kids Code Their Own Wearable の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

インドのスマートフォンブランドAi+が、2026年4月の製品発表イベントで初のフォルダブル端末「Nova Flip」を披露した。価格はRs 29,999（約5万円）と、フォルダブルスマホとしては世界最安クラスの水準。テックメディアGizmochinaのAnvinraj Valiyathara氏が詳細スペックとともに報じた。 Nova Flipのスペック詳細 項目 仕様 メイン画面 6.9インチ AMOLED（2790×1188px） カバー画面 3.1インチ AMOLED SoC MediaTek Dimensity 7300 RAM／ストレージ 8GB LPDDR4X／256GB OS Android 15（NxtQ OS） メインカメラ 50MP＋2MP深度センサー フロントカメラ 32MP（最大10倍デジタルズーム） バッテリー 4325mAh／33W充電 通信 5G デュアルSIM、NFC、Bluetooth、GPS 防塵防水 IP64 インターフェース USB-C、側面指紋センサー カラー Glacier White（Pantone Cloud Dancer） 2026年5月よりインドで販売開始予定。 なぜこの製品が注目か フォルダブルスマホ市場はこれまで「Samsungが独占する高級カテゴリ」という位置づけが続いてきた。Galaxy Z Flip7の予想価格が15万円前後とされる中、Nova Flipの約5万円はその1/3以下という破格の設定だ。チップはミドルレンジのDimensity 7300だが、6.9インチAMOLED・IP64防塵防水・NFC・4325mAhという構成を揃えている点は注目に値する。 とりわけバッテリー容量はフリップ型端末の弱点を正面から突いた設計だ。薄型・折りたたみ構造の制約上、フリップ型は電池容量を削りがちだが、Nova Flipの4325mAhは同カテゴリとして異例の大容量である。 海外レビューのポイント Gizmochinаの報道によると、本機の評価ポイントは以下のとおり。 注目される点 フォルダブルとして世界最安クラスとなるRs 29,999という価格設定 フリップ端末としては大容量の4325mAhバッテリー IP64防塵防水とNFCを低価格帯で搭載 32MPフロントカメラで自撮り・ビデオ通話用途にも対応 気になる点 カメラ構成が50MP＋2MP深度センサーのみで望遠レンズなし Dimensity 7300はミドルレンジ帯であり、ハイエンド水準の処理性能は期待できない 独自OS「NxtQ OS」の完成度・長期アップデート継続性は未知数 グローバル展開の計画は現時点で未発表 日本市場での注目点 現時点で日本発売の予定は発表されていない。Ai+はインド市場を中心に展開するスタートアップブランドであり、国内での入手は困難な状況だ。 日本市場でのフリップ型端末の選択肢は、Samsung Galaxy Z Flip6が実売11〜13万円前後で主力となっている。Nova Flipとの価格差は2倍以上あり、仮に日本展開が実現した場合は市場に一石を投じる可能性がある。ただし技適認証の取得、アフターサポート体制、OSアップデートの継続性といった「日本で安心して使い続けるための条件」がクリアされなければ、価格の優位性だけでは実用上の選択肢にはなりにくい。 ...

Eastern Heraldが報じたところによると、Googleは画面のないフィットネストラッカー「Fitbit Air」を$99で発表し、2026年5月26日に一般発売する予定だ。Gemini AIを活用したヘルスコーチング機能を核に、スマートウォッチとは一線を画す新たなウェアラブルカテゴリの確立を目指している。 なぜ「Fitbit Air」が注目されるのか 現在のウェアラブル市場は、Apple WatchやGalaxy Watchなど多機能スマートウォッチが主流だ。一方で、「通知確認もしたくない、ただ健康データを記録したい」というユーザー層は一定数存在する。Fitbit Airはディスプレイを完全に排除することで、バッテリー持続時間の延長（7日間）とフォームファクターの薄型化を両立した。 価格も$99（約1万5千円前後）と、多機能スマートウォッチの4〜5分の1以下に抑えられており、健康管理の入門機としての訴求力は高い。そして最大の差別化要素が、Gemini AIによるヘルスコーチングだ。単なる歩数・睡眠の記録にとどまらず、蓄積された健康データをもとにAIが個別アドバイスを提供する設計とされている。 海外報道のポイント Eastern Heraldの報道によると、主なスペックは以下の通りだ。 項目 仕様 ディスプレイ なし AI機能 Gemini AIヘルスコーチング バッテリー 約7日間 防水性能 50m防水 価格（米国） $99 発売日 2026年5月26日（予定） Eastern Heraldの報道では、画面なし構成によって「スマートウォッチ疲れ」を感じるユーザーや、シンプルな健康管理を求める層に向けた製品として位置づけられていると伝えている。Gemini AIコーチングについては、スマートフォンアプリ上でフィードバックを受け取る形式となる模様だ。本格的なレビューはリリース後に出そろうことが予想される。 日本市場での注目点 現時点では日本向けの正式な発売日・価格は未発表だが、既存のFitbitシリーズは日本でも展開されており、国内投入は十分に考えられる。$99を円換算すると現レートで約1万5千円前後。日本市場での直接の競合は Fitbit Inspire 3（1万2千円前後）、Xiaomi Smart Band 9（5千円前後）、Garmin vivosmart 5（2万円前後）あたりが挙げられる。 注意点として、Gemini AI機能の日本語対応が発売時から提供されるかどうかは現時点で不明だ。過去のGoogle製品でも日本語AI機能のローカライズに遅れが生じたケースがあり、購入前に対応状況の確認が必要になるだろう。 筆者の見解 「画面を取り除く」という設計判断は、スマートウォッチとの差別化という意味でわかりやすい。バッテリー消費の主因であるディスプレイを省くことで7日間駆動を実現しつつ、価格を$99に抑えた点は素直に評価できる。ターゲットが明確で、製品コンセプトに一貫性がある。 気になるのはGemini AIコーチングの実効性だ。健康トラッキングにAIを組み合わせること自体の方向性は悪くない。ただ、AIコーチングが本当に価値を持つためには、「アドバイスを出す」だけでなく「ユーザーの行動が継続的に変わる」ところまで設計できているかが問われる。アドバイスを一読して「ふーん」で終わるならば、機能としては飾りに近い。 $99という価格帯でどこまでのAI体験を提供できるか——Fitbit Airの本当の評価は、リリース後のユーザーレビューが出そろってから判断したい。シンプルなコンセプトが刺さるユーザーには確実に選択肢になりうる製品だ。 関連製品リンク Fitbit Inspire 3 Fitness Tracker Midnight Zen/Black ...

Menlo Venturesのパートナー、Deedy Das氏がSNSに投稿した長文が、AI業界の"本音"をあぶり出した。AIブームの恩恵を受けているのはOpenAI・Anthropic・Nvidia・xAIなどの一部企業に在籍する約1万人に過ぎず、それ以外の大多数のエンジニアはスキルの陳腐化と雇用不安に直面しているという告発だ。 OpenAI・Anthropicの社員だけが笑う「1万人の富」 Das氏の試算によれば、過去5年間でOpenAI、Anthropic、xAI、Nvidia、Metaなどの中核企業に在籍した創業者・従業員のうち、約1万人が「引退できるレベルの富（2,000万ドル以上）」を手にした。 一方、残りのソフトウェアエンジニアたちの状況は対照的だ。「年収500万円以上の安定した職に就いていても、そのレベルの富には一生届かないかもしれない」という焦燥感が業界を覆い、レイオフは拡大中、自分のスキルが「もう必要とされない」という感覚に苦しむエンジニアが増えている。Das氏はサンフランシスコの雰囲気を「かなり騒然としている」と表現し、「こんなに格差の差が大きい状況は見たことがない」と述べた。 「当たりくじ」と「失業の刃」が同じ技術という皮肉 この投稿に対してX（旧Twitter）では様々な反応があった。起業家のDeva Hazarika氏は「この投稿に登場するほとんどの人は信じられないほど恵まれており、幸せになる選択をすれば良いだけだ」と批判的な見方を示した。 一方、別のユーザーが指摘した点が核心を突いている——「同じ技術が、当たりくじであると同時に、保険（フォールバック）を食い尽くしているのは、かなり斬新でもあり、ひどくもある」。 AIはエンジニアを豊かにもするが、その同じAIがエンジニアの仕事を奪っていく。この二面性が、AIゴールドラッシュの本質的な構造的矛盾だ。 なぜこれが重要か——日本のIT現場への影響 日本のIT業界でも同様の動きは観察されている。大手SIerや受託開発会社では「AIが仕事を奪う」という議論が活発化し、一方でAI関連スキルを持つエンジニアの年収は急上昇している。 ただし、日本の場合はサンフランシスコとは異なる問題がある。新卒一括採用・年功序列の構造が残る大企業では、AIシフトの波に乗れず「変化に気づかないまま」時間を消費している組織が多い。個人レベルでも「AIを使いこなして価値を出す人」と「情報収集だけして行動しない人」の二極化が静かに進んでいる。 実務への影響——エンジニアが今すぐ取り組むべきこと 仕組みを作れる側に立つ AIを使うユーザーではなく、AIを組み込んだ仕組みを設計・実装できるエンジニアになることが生き残りの鍵だ。AIエージェント、自動化パイプライン、AIを活用したワークフロー設計のスキルを身につけることが優先課題になる。 情報収集より実践を選ぶ 「AIの最新情報を追いかける」のではなく、実際に手を動かして使いながら成果を出す経験を積む方が圧倒的に価値がある。毎日の業務にAIを組み込み、具体的な実績を積み上げることに集中すべきだ。 「安定した職」という幻想を見直す Das氏の指摘の通り、安定した職についていることと、変化に対応できることは別問題だ。自分のスキルが3年後も通用するかを真剣に問い直す時期に来ている。 筆者の見解 Das氏の投稿は、AI業界の内部から出てきた正直な告白として受け止めるべきだ。サンフランシスコのベンチャー界隈の話として片付けるのはもったいない。日本のエンジニアも、この構造を自分事として捉える必要がある。 最も本質的な指摘は「AIは当たりくじであると同時に、フォールバックを食い尽くす」という部分だ。技術変革の二面性を正確に表現しており、楽観でも悲観でもなく現実を直視している。 ただ、「乗り遅れた」と嘆いていても何も変わらない。ゴールドラッシュ時代、金を掘り当てた人よりも、スコップやジーンズを売った人の方が安定して稼いだというのは有名な話だ。AI時代も同じ構造が当てはまる——AIモデルそのものを作る必要はない。AIを活用して価値ある仕組みを作れる人材になることが、より現実的で再現性の高い戦略だ。 日本のIT業界には、この変化に真剣に向き合わないまま旧来の採用・育成・業務のやり方を続けている組織がまだ多い。変革の波は、気づいていない人を特に容赦なく飲み込む。まず自分の手でAIを動かすことを今日から始めてほしい。 出典: この記事は The haves and have nots of the AI gold rush の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Claude Code、最高なんだけど「記憶」の扱いが難しい続きをみる note.com で続きを読む →