Generative-Ai

会議の音声をリアルタイムでAIが文字起こし・要約してくれる——そんな便利さで人気を集めているAIノートアプリ「Granola」に、見過ごせないプライバシーリスクが潜んでいることが明らかになった。エンジニアやIT管理者はもちろん、機密情報を扱う会議でGranolaを利用しているすべてのビジネスパーソンに向けて、今すぐ確認すべき設定を解説する。 Granolaとは何か Granolaは「連続する会議をこなす人のためのAIノートパッド」を標榜するアプリだ。カレンダーと連携し、会議の音声をキャプチャしてAIが箇条書きのメモを自動生成する。生成されたメモは編集可能で、同僚をコラボレーターとして招待したり、AIアシスタントに会議内容を質問したりもできる。MacのデスクトップアプリとしてUS発で展開されており、特にスタートアップやSaaS企業のビジネスパーソンの間で広く利用されている。 何が問題なのか リンクを知る全員が閲覧可能 Granolaのアプリ設定には、「デフォルトではノートはリンクを持つ誰でも閲覧可能」と明記されている。The Vergeの検証では、自分のノートのリンクをプライベートウィンドウで開いたところ、Granolaアカウントにログインしていない状態でもノートの内容・作成者・作成日時が表示されたという。 さらに、ノート内の箇条書きを選択すると、その根拠となる会議トランスクリプトの引用と、AIが生成したコンテキスト付きサマリーが表示される仕組みだ。完全なトランスクリプトへのアクセスはデスクトップアプリ内のコラボレーターに限定されているようだが、詳細はGranolaが公式に確認していない。 このリンクは検索エンジンにインデックスはされていないが、「誤ってSlackやメールでリンクを共有してしまった」「画面共有中に見えてしまった」といったシナリオで情報が外部に漏れるリスクは十分にある。実際、あるLinkedInユーザーが昨年この問題を指摘しており、大手企業の1社はセキュリティ上の懸念からシニアエグゼクティブへのGranola利用を禁止したと報じられている。 AIトレーニングへのデータ利用もオプトアウト制 もう1つの問題が、AIモデルの改善を目的とした「匿名化データの利用」だ。エンタープライズプランのユーザーはデフォルトでオプトアウトされているが、それ以外のプランではオプトインが前提となっている。GranolaはOpenAIやAnthropicなど第三者企業へのデータ提供は行わないと説明しているが、自社AIモデルの学習には利用される可能性がある。 なお、ノートと文字起こしはAWSのプライベートクラウド上に保存され、暗号化（保存時・転送時）はされている。会議の音声そのものは保存されない点は救いだが、テキスト化された会議内容が残ることに変わりはない。 今すぐできる設定変更 以下の手順でプライバシー設定を変更できる： リンク共有の制限 Granolaを開き、左下のプロフィールアイコンを選択 「Settings」→「Default link sharing」を開く 「Anyone with the link」を「Only my company」または「Private」に変更 AIトレーニングのオプトアウト 同じSettings画面で「Use my data to improve models for everyone」をオフにする なお、ノートを削除すれば既存のリンクからもアクセス不能になる。 実務への影響 日本のIT現場では、リモートワーク普及以降、会議メモの自動化ツールへの関心が急速に高まっている。GranolaのようなAI会議アシスタントは確かに生産性を大幅に向上させるが、今回の問題は「便利さ」の裏に潜むガバナンスリスクを改めて示している。 特に以下のケースでは利用ポリシーの見直しが急務だ： M&A・経営会議など機密性の高い打ち合わせ：リンク漏洩が情報漏洩に直結する 個人情報・顧客情報を扱う会議：GDPRや個人情報保護法の観点でリスクになりうる クライアントとの商談：NDA締結済みの情報をAIに学習させることの是非 IT管理者向けには、社内でGranolaを利用しているユーザーに設定変更を周知するとともに、エンタープライズプランへの移行（AIトレーニングがデフォルトオプトアウト）を検討する価値がある。 筆者の見解 Granolaに限らず、AIを活用した生産性ツールにおいて「デフォルトがオープン寄り」な設定になっている事例は後を絶たない。これはプロダクトの性質上、コラボレーションを促進するために意図された設計であることが多いが、エンタープライズ利用を想定した場合に大きな障壁となる。 今回の問題が示すのは、AI時代における「ゼロトラスト」の考え方をツール選定にも適用すべきという教訓だ。便利だからといって即座に組織展開せず、「デフォルト設定は何か」「データはどこに保存され、何に使われるか」「オプトアウトできるか」を必ずチェックするプロセスを組織に根付かせることが重要だ。 AI会議アシスタント市場はMicrosoft Copilot（Teams）やGoogle Gemini（Meet）など大手も参入しており、競争はさらに激化する。こうした大手プラットフォームはエンタープライズのコンプライアンス要件を満たした設計になっていることが多いが、スタートアップ発のツールでは今回のGranolaのようなケースが起きやすい。ツールの「便利さ」と「セキュリティ成熟度」を天秤にかけながら、組織としての利用判断を下す——そのリテラシーが今のIT部門には求められている。 出典: この記事は PSA: Anyone with a link can view your Granola notes by default の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年4月、生成AIの競争は新たなフェーズに入った。わずか3ヶ月でフロンティアが何度も塗り替えられ、今月だけでも業界の勢力図を変えかねない出来事が連続して発生している。OpenAIが年換算売上高（ARR）250億ドルを突破しIPO検討に入ったというビジネス面での激変と並行して、モデル性能の競争も前例のない激しさを見せている。 業界を揺るがした「Claude Mythosリーク」 今月最大のニュースは、3月26日に発生したAnthropicの内部文書流出だ。設定ミスのあったデータストアから約3,000件の内部ファイルが一時的に公開状態になり、その中に「Claude Mythos（内部コードネーム：Capybara）」の詳細な製品ドキュメントが含まれていた。 Anthropicは存在を否定せず、「推論・コーディング・サイバーセキュリティにおいて意味のある進歩を遂げた汎用モデルを開発中。能力の強さを鑑み、リリース方法を慎重に検討している。これは当社史上最高性能のモデルで、ステップチェンジと位置づけている」と公式に認めた。 リークされた文書によれば、ClaybearはClaude Opus 4.6を「劇的に」上回るプログラミング性能を持つとされ、現在はサイバーセキュリティパートナー限定の早期アクセス段階にある。公開日は未定だが、市場は4月中の発表可能性を約25%と見積もっている。 現時点のモデル勢力図 総合性能：Gemini 3.1 Pro が首位 16の主要ベンチマーク中13で首位を獲得しているGemini 3.1 Proは、Artificial Analysis Intelligence IndexでGPT-5.4 Proと同率ながら、APIコストは約3分の1という破壊的なコストパフォーマンスを誇る。エンタープライズ採用において価格は重要な変数であり、この差は見逃せない。 コーディング：Claude Sonnet 4.6 が実務首位 実際の専門家レベル作業を評価するGDPval-AA Eloベンチマークでは、Claude Sonnet 4.6がトップに立つ。GitHub CopilotのCodingエージェントがこのモデルで動作していることからも、コード生成の実用性では一歩抜け出した存在だ。 オープンソース：Meta Llama 4 Mavericが台頭 4,000億パラメータ・1,000万トークンのコンテキストウィンドウを持つLlama 4 Mavericは、独自インフラで無償運用できるオープンウェイトモデルとして最強クラスに達した。クローズドモデルとの性能差が急速に縮まっている。 価格破壊：DeepSeek V3.2 DeepSeek V3.2は入力100万トークンあたり約0.28ドルという価格を実現。欧米フラッグシップモデルの2ドル以上と比較すると約7分の1以下であり、コスト重視のユースケースでは無視できない選択肢だ。 実務への影響——日本のエンジニア・IT管理者にとっての意味 すぐに動けるアクション： GitHub Copilotを使っているなら今すぐ確認：Claude Sonnet 4.6ベースのCodingエージェントが実務コーディングで最高評価を得ている。エージェントモードが有効になっているか設定を確認し、複雑なリファクタリングや単体テスト生成に積極的に活用したい。 Gemini 3.1 Proのコスパを試算する：Google CloudやVertex AI経由でのAPI利用コストを、現在使っているGPT-4系と比較してほしい。同等性能で3分の1のコストになるなら、高スループットな社内ツールのバックエンドを切り替える価値がある。 オンプレミス・プライベート環境を検討しているなら Llama 4：情報漏洩リスクの観点から外部APIに送れないデータを扱う企業にとって、Llama 4 Mavericは現実的な選択肢になった。ローカルLLM運用のPoC着手タイミングとして今が適切だ。 Claude Mythosの動向を追う：サイバーセキュリティ分野で特段の強みを持つとされており、SOC自動化やペネトレーションテスト支援への活用が期待される。早期アクセス申請の窓口が開いた際は優先的に検討したい。 筆者の見解 2026年の生成AI競争を一言で表すなら「コモディティ化の加速」だ。 Gemini 3.1 ProがGPT-5.4と同等の性能を3分の1のコストで提供し、Llama 4がクローズドモデルの背中を追うこの状況は、「どのモデルを使うか」ではなく「いかに素早く使いこなすか」が企業の競争優位を決める時代が来たことを示している。 Claude Mythosのリークが特に興味深いのは、Anthropicが「サイバーセキュリティ」を特筆した点だ。セキュリティ特化のモデルが登場することで、これまで人手に依存していたインシデント対応や脆弱性評価の自動化が一気に現実解になりうる。日本でもCSIRTやSOCの人材不足は深刻であり、このモデルの公開は国内のセキュリティ運用に大きなインパクトを与えると予想する。 OpenAIのIPO観測が示すように、生成AIはもはや研究フェーズを完全に卒業した。モデル選定はベンダーロックインリスク・コスト・コンプライアンス・性能のバランスで評価する「調達判断」になっている。IT管理者にとっては、クラウドサービスの選定と同じ視点でAIモデルを評価するフレームを今すぐ整備すべき時期に来ている。 出典: この記事は OpenAI Surpasses $25B ARR, Explores IPO as Early as Late 2026 の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AIはコードを「書く」から「検証する」フェーズへ 「AIはコードが書ける」——この命題はもはや疑う余地がない。GitHub CopilotやClaude Code、Cursor AIが普及し、日々の開発でAIアシストは当たり前になってきた。しかし、もう一段深いところで問いが立ち上がっている。「AIは信頼できるエンジニアリングを、人間の監視なしにできるのか？」 この問いに対して、英国オックスフォード発のスタートアップ・Diffblueが2026年3月24日に衝撃的なデータを叩きつけた。自律型回帰テスト生成エージェント「Diffblue Testing Agent」が一般提供（GA）を開始し、8つの実世界Javaプロジェクトを対象としたベンチマークで平均81%のライン網羅率を自動達成したというのだ。 比較対象は「シニア開発者がClaude Codeと2時間協働した場合」——その結果は平均32%。実に2.5倍の差である。 Diffblue Testing Agentとは何か Diffblue Testing Agentは、既存のAIコーディングプラットフォーム（GitHub Copilot、Claude Code等）の上にオーケストレーション＆検証レイヤーとして機能する専門エージェントだ。既存ツールを置き換えるのではなく、それらを指揮する立場に立つ設計思想が特徴的である。 具体的な動作フローは以下のとおり： コードベースの自律スコーピング — 対象クラス・メソッドを自動特定 テスト計画の作成 — カバレッジ分析をもとに並列テスト生成戦略を立案 テスト生成の委任 — メソッド・クラスレベルのテスト作成をClaude CodeなどのAIに委任 ビルド＆検証 — コンパイルが通り、かつパスするテストのみを採用 ロールバック処理 — 失敗したテストは自動的に除去 プルリクエスト準備 — 数百〜数千クラスを一括処理してPRを自動生成 ベンチマークでは81%のライン網羅率に加え、**ミューテーション網羅率61%**も達成。これは多くのエンタープライズが設定するテスト品質基準を上回る水準だ。 この技術的基盤はオックスフォード大学発の数十年にわたるソフトウェア検証研究から生まれており、単なる「AIにテストを書かせる」ツールとは一線を画す。 なぜこれが重要か——日本のIT現場への影響 日本のエンタープライズIT現場では、アプリケーションモダナイゼーションが最大の課題の一つとなっている。老朽化した基幹システムをクラウドネイティブ化・マイクロサービス化する際、最大のリスクは「リグレッション（既存機能の壊れ）」だ。 テストがない（あるいは少ない）レガシーコードをリファクタリングするのは、目を閉じてロープを渡るようなものである。多くの現場では「テストを書く工数がない」という理由でモダナイゼーションが止まっているか、そもそもテスト工程を省略してリスクを抱えたまま進んでいる。 Diffblue Testing Agentが解決しようとしているのはまさにこの課題だ。「テスト書く人がいない問題」を、エージェントが自律的に解決する。 また、AIコーディングツールの「急速に収穫逓減する」問題も見逃せない。Claude CodeやCopilotにテスト生成を頼み続けると、50%程度の網羅率で詰まり、そこから先は開発者が延々とプロンプトを調整する時間が必要になる。DiffblueのCTO、ピーター・シュラメル博士が「その努力は急速に手が届かないレベルになる」と述べているのは、多くの開発者が実感していることだろう。 実務での活用ポイント Javaレガシーシステムの担当者は今すぐ注目を。Diffblue Testing AgentはJavaプロジェクトを主なターゲットとしており、Spring Boot・JakartaEEベースの業務システムとの相性が良い。モダナイゼーション前の「テスト整備スプリント」に組み込む使い方が現実的だ。 既存のAIコーディング環境への統合がスムーズ。GitHub Copilotや Claude Codeをすでに導入しているチームであれば、Diffblue Testing Agentはそれらを置き換えるのではなくオーケストレーションレイヤーとして乗る。投資を無駄にせず効果を最大化できる。 コードレビューの視点変化。テスト生成が自動化されると、人間のレビュアーは「テストが存在するか」ではなく「テストが意味のある検証をしているか」にフォーカスできる。ミューテーションカバレッジ（61%）をKPIに設定することで、テスト品質の議論が具体的になる。 CI/CDパイプラインへの組み込み。PRを自動生成する機能を活かし、テスト追加をCIの一部として自動化することで、新機能追加のたびにテスト負債が積み上がる悪循環を断ち切れる。 筆者の見解 AI開発ツールの進化を2年以上追ってきて、このDiffblueのアプローチには強い納得感がある。 これまでの「AIにコードを書かせる」フェーズは、いわばAIの「作文能力」を活用する段階だった。しかし実際の開発現場で信頼を得るためには、AIが「品質保証まで含めたエンジニアリング」ができなければならない。 Diffblue Testing Agentが示しているのは、専門特化型エージェントが汎用AIコーディングアシスタントを上回るという事実だ。汎用AIコーディングアシスタントは優秀だが、テスト生成に特化して設計されたエージェントには及ばない——これは当然であり、むしろ健全な分業の形だと思う。今後は「汎用AIコーディングアシスタント ＋ 専門エージェント群」という構成が、エンタープライズ開発の標準になっていくだろう。 気になるのはJava以外への展開だ。日本の現場ではC#やPythonも多く、これらへの対応が進めば採用の障壁はさらに下がる。また、オックスフォード大学の研究ベースという点は信頼性の観点で大きな強みだが、日本語コメントが混在するコードへの対応品質も実際の導入前に検証が必要だろう。 ...

コード生成は「ボトルネック」ではなくなった JetBrainsが2026年3月、AIエージェントによる自律的なソフトウェア開発を統合管理するプラットフォーム「JetBrains Central」を発表した。2026年Q2に限定デザインパートナー向けのEAP（Early Access Program）を開始する予定だ。 この発表が示すのは、単なる「IDEにAIを追加する」という話ではない。ソフトウェア開発そのものの構造的な変容への、JetBrainsなりの回答だ。 なぜ「Central」が必要なのか JetBrainsが2026年1月に実施した「AI Pulse」調査（世界1万1000人のエンジニア対象）によると、すでに90%が業務でAIを活用している。さらに22%がAIコーディングエージェントを利用しており、66%の企業が今後12か月以内に導入を計画している。 しかし問題がある。AIの恩恵が個人の生産性向上に留まっており、開発ライフサイクル全体（コードレビューやリリースパイプラインなど）に活用しているエンジニアはわずか13%に過ぎない。 チームや組織レベルでの改善——デリバリー速度、システム信頼性、コスト効率——にAIが繋がっていないのだ。 JetBrains Centralはこのギャップを埋めることを目指している。Issueの調査、コード生成、テスト実行、マルチステップワークフローをエージェントが自動実行するにあたり、それらを「統一された生産システム」として制御・監視・管理する基盤を提供する。 3つのコアケイパビリティ 1. ガバナンスと制御 ポリシー強制、ID・アクセス管理、可観測性（Observability）、監査証跡、コスト帰属管理。エンタープライズ環境で求められる要件が一通り揃う。一部機能はすでにJetBrains Central Consoleとして提供されている。 2. エージェント実行インフラ クラウドエージェントランタイムとコンピューティングプロビジョニング。エージェントが開発環境をまたいで安定動作できる基盤を提供する。 3. エージェント最適化とコンテキスト リポジトリ・プロジェクトをまたいだ共有セマンティックコンテキスト。エージェントが適切な知識にアクセスし、最適なモデル・ツールへのタスクルーティングを実現する。 注目すべきはオープンなアーキテクチャだ。JetBrains製エージェントだけでなく、Claude Agent、Codex、Gemini CLI、あるいは自社開発のカスタムエージェントも統合可能。特定ベンダーへのロックインを避けながら、既存の開発インフラ投資を活かせる設計になっている。 実務への影響——日本のエンジニア・IT管理者にとっての意味 エンジニアへのヒント： 今すぐ試せるわけではないが、EAPデザインパートナーへの応募を検討する価値がある。特に大規模チームやCI/CDパイプラインへのAI統合を模索している組織は優先度が高い。 JetBrains IDE（IntelliJ IDEA、PyCharm、Rider等）を既に使っている場合、移行コストなく恩恵を受けやすい。 「AIにコードを書かせる」フェーズから「AIエージェントのワークフローを設計・監視する」フェーズへのスキルシフトを意識しておくべきだ。 IT管理者・アーキテクトへのヒント： コスト帰属（Cost Attribution）機能は、エージェント活用によるクラウドコストの増大を管理する上で重要になる。予算管理の観点からガバナンス機能の成熟度を注視したい。 既存のGitHub Actions、Azure DevOps等のパイプラインとの統合性についても、EAP段階で積極的に検証を行うべき局面が来るだろう。 筆者の見解 JetBrains Centralの発表を見て、私が真っ先に思い浮かべたのはAzure DevOpsとGitHub Actionsの進化の歴史だ。かつてCI/CDがエンジニアリング組織に「パイプラインの管理者」という新しい役割をもたらしたように、AIエージェントの普及は「エージェントオーケストレーションの管理者」という役割を生み出しつつある。 JetBrainsの戦略は明快だ。IDEベンダーとしての優位性を「エージェントの制御基盤」にまで拡張すること。 コード生成自体はコモディティ化しつつあるなか（OpenAI、Anthropic、Google、Microsoftが競い合っている）、どのエージェントを使っても統合・管理できる「プレーン（制御層）」を握ることに活路を見出している。 これはMicrosoftが「Copilot Studio」や「Azure AI Foundry」でエージェント基盤を構築しようとしている方向性と本質的に同じだ。異なるのは、JetBrainsが開発者体験（DX）を起点にしているという点。VSCode陣営対JetBrains陣営という旧来の競争軸は、「どのエージェント基盤でソフトウェア生産を管理するか」という競争軸に移行しつつあるのかもしれない。 日本企業にとっては、まだEAPという段階ではあるが、2026年後半にかけてエージェント駆動開発への組織的な準備を始める好機でもある。ツールの選定より先に「どのようにエージェントの成果物を検証し、ガバナンスを効かせるか」というプロセス設計を議論し始めることが、今できる最も価値ある投資だと筆者は考えている。 出典: この記事は JetBrains Central: Open System for Agentic Software Development (EAP Q2 2026) の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoogleがGemini 3.1 Flash-Liteを正式リリースした。従来モデル比で応答速度2.5倍・出力速度45%向上を実現しながら、入力トークン100万件あたりわずか$0.25という衝撃的な低価格を打ち出している。生成AIの「高性能＝高コスト」という常識が、いよいよ崩れはじめている。 Gemini 3.1 Flash-Liteとは何者か Gemini 3.1 Flash-Liteは、Googleが「速度とコスト効率」に最適化して設計した軽量モデルだ。Geminiファミリーの中でもFlashシリーズはリアルタイム応答や大量処理に向いた系統であり、Flash-Liteはさらにその方向性を突き詰めたポジショニングになる。 主な特徴は以下の3点に集約される。 ① 応答速度の大幅改善 前世代比で初回応答までのレイテンシが2.5倍短縮。チャットボットや対話型アプリケーションでは「待ち時間」がそのままUXの質に直結するため、この改善は実運用で即効性が高い。 ② 出力スループット45%向上 長文生成や一括処理バッチのスループットが45%改善。大量のドキュメント要約やログ解析といった処理集中型ワークロードのコスト削減に直接効く。 ③ 価格設定の破壊力 入力トークン100万件あたり$0.25、出力は$0.75程度と推定される。GPT-4oのフルモデル（入力$5〜10/M）と比較すると、単純計算で10〜40倍のコスト差が生じる。「試作品でしか使えなかったコスト水準」が、本番環境でも現実的な選択肢になってきた。 なぜこれが重要か——日本のIT現場への影響 日本企業における生成AI導入の最大の障壁の一つは、依然として「コスト」だ。PoC（概念実証）段階では許容できたAPI費用が、本番移行・スケールアウト時に予算を圧迫するケースは多い。特に中小規模のSIerやスタートアップでは、ユーザー数に比例して跳ね上がるトークン費用が事業計画に影響することもある。 Gemini 3.1 Flash-Liteの価格帯は、こうした「コストで諦めていた本番展開」を現実的な選択肢に引き戻す可能性がある。たとえば以下のようなユースケースだ。 カスタマーサポートチャットボットの24時間運用（大量リクエストでもコストが読みやすい） 社内文書の全文要約・インデックス作成（数万ドキュメント規模でも費用が抑えられる） コード補完・レビュー支援ツールのCI/CD統合（パイプライン毎の実行コストが激減） 実務での活用ポイント 1. 用途に応じたモデル分割戦略を採用する すべてのリクエストを高性能モデルに通す「フラット設計」は非効率だ。複雑な推論・創造的タスクはGemini 1.5 ProやGPT-4o、定型的な分類・要約・抽出はFlash-Liteに振り分けるルーティング設計を導入することで、品質を落とさずにコストを50〜70%削減できる可能性がある。 2. Azure AI FoundryやVertex AIとの統合を活かす GeminiモデルはGoogle Cloud Vertex AI経由で利用可能であり、Azure AI Foundryも外部モデルのルーティングに対応しつつある。既存のM365環境やAzure基盤を持つ日本企業であれば、既存の認証・ガバナンスフレームワーク上でFlash-Liteを試せる環境が整いつつある。 3. プロンプト設計でコストをさらに圧縮する Flash系モデルはコンテキスト長が長くなるほどレイテンシが増す傾向がある。System Promptの最適化と、不要なコンテキストの削除（Context Pruning）を組み合わせることで、費用対効果を最大化できる。 筆者の見解 今回のGemini 3.1 Flash-Liteのリリースは、生成AIの「競争軸の変化」を象徴する出来事だと捉えている。 2023年〜2024年はベンチマークスコアの競争が主戦場だった。しかし2025年以降、モデルの性能が「十分に高い」水準に達してきたことで、差別化の軸はコスト・速度・信頼性へと移行しつつある。OpenAI、Anthropic、Googleの3社がいずれも「安価な軽量モデル」のラインナップを強化しているのは、この流れを如実に示している。 日本市場においては、この価格競争は追い風だ。一方で注意すべき点もある。安価なモデルは「ハルシネーション率」や「複雑な指示への追従性」でフルモデルに劣る場面がある。コスト削減の旨みを享受しつつ、品質評価の仕組みを合わせて整備することが不可欠だ。 また、GoogleがこのタイミングでFlash-Liteをリリースした背景には、Anthropicの「Claude 3.5 Haiku」やOpenAIの「GPT-4o mini」との競合があることは明らかだ。価格競争の激化は、エンドユーザーにとっては歓迎すべき話だが、ベンダーロックインのリスクも高まる。「今日の最安モデルが来月には陳腐化する」サイクルに備え、マルチモデル対応のアーキテクチャを設計段階から意識しておくことを強く推奨したい。 出典: この記事は Gemini 3.1 Flash-Lite Delivers 2.5× Faster Response at $0.25 Per Million Tokens の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

OpenAIが、AIシステムの安全性分類タスクに特化したオープンウェイトモデル「gpt-oss-safeguard」をApache 2.0ライセンスで公開した。120Bと20Bの2サイズを提供し、Hugging Faceからダウンロードして自社環境に展開できる。クラウドAPIに依存せず、自前のAI安全対策インフラを構築できる点が大きな注目ポイントだ。 「deliberative alignment」とは何か gpt-oss-safeguardの核心にあるのが、deliberative alignment（熟慮的アライメント）という新しい手法だ。従来の安全分類モデルは、あらかじめ学習したパターンで有害コンテンツを判別するに留まっていた。これに対し、deliberative alignmentでは推論時（インファレンス時）にポリシーを直接解釈させる。つまり、企業独自の利用規約や業界ルールを自然言語で記述し、それをモデルが理解した上でリアルタイムに判断を下す仕組みだ。 これは実務上、非常に大きな違いをもたらす。これまでは「このコンテンツは有害か否か」という二値判定が主流だったが、deliberative alignmentでは「わが社のポリシーに照らしてどうか」という文脈依存の判断が可能になる。医療・金融・教育といった規制業界で求められる、きめ細かなコンテンツ制御に対応できるポテンシャルがある。 120Bと20Bの使い分け 提供される2サイズには明確な役割分担がある。 120Bモデル: 精度優先。複雑なポリシー解釈や、グレーゾーンの判断が求められるシナリオに適する。GPUリソースは相応に必要だが、クリティカルなコンテンツ審査ワークフローに向く。 20Bモデル: 速度とコストのバランス重視。リアルタイムのチャットモデレーションや、大量のログ分類など、スループットが求められる用途に最適。 エンタープライズ用途では、両モデルを組み合わせて「まず20Bで高速フィルタリング→フラグが立ったものだけ120Bで精査」という二段構えの設計も現実的だ。 なぜこれが重要か——日本のIT現場への影響 日本企業がAIチャットボットや生成AIシステムを本番導入する際の最大の壁のひとつが、コンテンツモデレーションだ。OpenAI APIやAzure OpenAI Serviceを使えばある程度の安全機能は得られるものの、業界固有のポリシーや社内規定に合わせたカスタマイズは難しかった。 gpt-oss-safeguardのオープン公開により、この状況が変わる。特に以下のシナリオで恩恵が大きい。 オンプレミス・プライベートクラウド環境: 機密情報をOpenAIサーバーに送りたくない金融機関・官公庁が、クローズドな環境でAI安全対策を実装できる カスタムポリシーの適用: 医療分野の不適切な医療アドバイスのフィルタリング、EC事業者の広告審査など、業界ルールに合わせた判断基準を自然言語で定義できる コスト削減: 外部APIコールを安全分類に使うコストを内製化により削減できる 実務での活用ポイント 明日から試せる具体的な手順として、まずHugging Faceで20Bモデルをダウンロードし、社内の検証環境（A100×1枚程度で動作可能）で既存の問い合わせログを分類させてみることをお勧めする。自社の「グレーゾーン事例」に対してモデルがどう判断するかを見るだけでも、現行の安全対策の盲点が浮かび上がってくる。 ポリシー記述には工夫が必要だ。deliberative alignmentは「禁止語リスト」ではなく「ポリシーの意図」を理解させる設計なので、「〇〇は禁止」ではなく「なぜ禁止するのか」を含めた文章で記述すると精度が上がる。 Azure上で展開する場合は、Azure Machine Learningのマネージドオンラインエンドポイントにデプロイすることで、スケーリングや監視を既存のAzureインフラに統合できる。 筆者の見解 gpt-oss-safeguardの公開は、AIの安全対策が「ベンダー任せ」から「自社で実装・管理するインフラ」へと転換する流れを加速させると見ている。 これまでOpenAIは商業APIを通じてコンテンツポリシーを一元管理してきた。それが機能する場面も多いが、業界規制が厳しい日本市場では「ブラックボックス」な安全対策に監査が通らないケースも少なくない。今回のオープン化により、「どのようなロジックで何を判断したか」を企業側が説明できる透明性が得られる。これはGDPRや金融庁のAI活用ガイドラインへの対応にも直結する話だ。 一方で、オープンウェイトモデルには「悪用されるリスク」も伴う。安全分類モデルそのものを攻撃者が解析し、検出を回避するプロンプトを作りやすくなる側面は否定できない。OpenAIがこのトレードオフをどう評価した上で公開に踏み切ったかは、今後の同社のオープンソース戦略を読み解く上でも注目に値する。 「安全なAI」を自社で実装できる時代が来た——それはエンジニアにとって自由度と責任の両方が増すことを意味する。gpt-oss-safeguardをきっかけに、AI安全対策を「費用」ではなく「競争優位」として捉え直す組織が増えることを期待したい。 出典: この記事は OpenAI Releases gpt-oss-safeguard: Open-Weight Safety Classification Models の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropic、GitHub大量テイクダウン騒動——誤操作で8,100件のリポジトリが巻き添えに AI企業Anthropicが、自社の人気CLIツール「Claude Code」のソースコード流出に対処しようとした結果、意図せず数千件のGitHubリポジトリを道連れにする騒動が発生した。 事の発端：Claude Codeのソースコードが流出 4月1日、あるソフトウェアエンジニアが最新リリースにClaude Codeのソースコードが誤って含まれていることを発見した。Claude Codeは、Anthropicが提供するLLM（大規模言語モデル）ベースのコマンドラインアプリケーションで、同カテゴリでトップシェアを誇る製品だ。 流出したコードはすぐにAIコミュニティの注目を集め、Anthropicがどのようにモデルをアプリケーションに組み込んでいるかを解析しようとするユーザーがGitHub上でコードを共有・分析し始めた。 DMCA申請が暴走——8,100件に拡大 Anthropicは米国著作権法のデジタルミレニアム著作権法（DMCA）に基づきGitHubにテイクダウン申請を送付した。しかし、GitHubの記録によれば、この申請は約8,100件のリポジトリに対して執行された。 問題は、削除対象にAnthropicが公式に公開しているClaude Codeリポジトリの正規のフォークまで含まれていた点だ。SNS上では自分のコードが突然ブロックされた開発者たちの怒りの声が相次いだ。 Claude Codeトップが「誤操作」と謝罪 AnthropicのClaude Code部門責任者であるBoris Cherny氏は、今回の大量テイクダウンが誤操作によるものだったと認め、ほとんどの申請を撤回した。最終的な対象は、問題のソースコードを含む1件のリポジトリと96件のフォークに絞られた。 Anthropicの広報担当者はTechCrunchに次のように説明している： 「今回申請されたリポジトリは、弊社の公開Claudeコードリポジトリに紐付くフォークネットワークの一部でした。そのため、テイクダウンが意図した以上の範囲に及んでしまいました。対象1件を除いて申請を撤回し、GitHubは影響を受けたフォークへのアクセスを復元しました。」 その後、GitHubは巻き添えになったリポジトリのアクセスを回復している。 IPO準備中の企業にとって痛手 今回の一連の騒動は、Anthropicが株式公開（IPO）を計画しているとされる時期に重なり、内外から注目されている。ソースコードの流出自体も問題だが、その後の対応ミスが「実行力とコンプライアンス管理能力」への疑問を呼んでいる。上場企業において自社ソースコードが漏洩すれば、株主訴訟に発展するリスクもあると業界関係者は指摘している。 日本の開発者コミュニティにとっても、Claude CodeはAIコーディングツールとして広く利用されている製品だ。今回の事件は、AIツールの急速な普及に伴うセキュリティ管理やリリース運用の難しさを改めて浮き彫りにした。 元記事: Anthropic took down thousands of GitHub repos trying to yank its leaked source code — a move the company says was an accident

Claude AIが完全なカーネルエクスプロイトを自律作成——セキュリティ研究の新局面 セキュリティ研究チームCalifoが公開した調査レポートが、技術コミュニティに大きな波紋を呼んでいる。Anthropicの大規模言語モデル「Claude」が、FreeBSDカーネルの脆弱性（CVE-2026-4747）に対するリモートコード実行（RCE）エクスプロイトをほぼ自律的に完成させ、最終的にroot権限のリバースシェルを取得することに成功したというのだ。 脆弱性の概要 今回問題となったのは、FreeBSDのカーネルモジュール kgssapi.ko に含まれる RPCSEC_GSS認証 の実装だ。具体的には sys/rpc/rpcsec_gss/svc_rpcsec_gss.c 内の svc_rpc_gss_validate() 関数に、古典的なスタックバッファオーバーフローが存在していた。 この関数はGSS-APIの署名検証のためにRPCヘッダーを128バイトのスタックバッファ（rpchdr[]）へ再構築する。先頭32バイトに固定フィールドを書き込んだ後、残り96バイトの領域にRPCSEC_GSSクレデンシャル本体をコピーするが、クレデンシャルのサイズ（oa_length）を一切検証していなかった。 96バイトを超えるクレデンシャルを送りつけるだけで、スタック上のローカル変数、カーネルレジスタの保存領域、さらにはリターンアドレスまで上書きできてしまう。攻撃対象はNFSサーバーとして動作しているホスト（ポート2049/TCP）で、kgssapi.ko がロードされていれば外部からの認証前パケットだけで攻撃が成立する。 影響を受けるバージョン: FreeBSD 13.5（p11未満） FreeBSD 14.3（p10未満） FreeBSD 14.4（p1未満）★テスト環境 FreeBSD 15.0（p5未満） 修正は FreeBSD-SA-26:08.rpcsec_gss として公開されており、コピー前に oa_length がバッファサイズを超えていないかチェックする1行が追加されている。 AIが書いたエクスプロイトの何が驚異的か このCVE自体もさることながら、研究者たちが強調するのはClaudeがエクスプロイト開発の全工程を主導した点だ。スタックレイアウトの解析、De Bruijnパターンによるオフセット特定、ROP（Return-Oriented Programming）ガジェットの探索、最終的なペイロード構築——これらのステップをAIが段階的に推論しながら進めたとされる。 KASLRが無効なGENERICカーネル（FreeBSD 14.4-RELEASE amd64）という前提条件はあるものの、「PoC（概念実証コード）ではなく、実際にroot権限のリバースシェルを取得する完全なエクスプロイト」をAIが書き切ったことは、セキュリティ業界に大きなインパクトを与えている。 日本のサーバー管理者への影響 国内ではFreeBSDはNetflixやさくらインターネットの一部インフラ、組み込みストレージ製品（FreeNAS/TrueNASはFreeBSD派生）などで利用される。NFSをKerberos認証付きで公開しているサーバーが対象となるため、直ちにパッチを適用するとともに、不要であれば kgssapi.ko をアンロードする対策が有効だ。 AIとセキュリティ研究の倫理的問い 今回の発表はAIによるオフェンシブセキュリティ研究の可能性と危うさを同時に示している。エクスプロイト開発の民主化は防御側のコスト削減にも繋がる一方、攻撃能力の裾野を広げるリスクも孕む。AI企業各社のガードレール設計が改めて問われる事例となりそうだ。 パッチ適用が完了するまでの間は、ファイアウォールでポート2049へのアクセスを信頼済みホストのみに制限することを強く推奨する。 元記事: Claude wrote a full FreeBSD remote kernel RCE with root shell

Claude Codeのブラックボックスを「見える化」するツールが登場 Claude Codeを使って複数のAIエージェントを並列実行する際、各エージェントが実際に何をしているかを把握するのは難しい。そうした課題を解決するオープンソースプロジェクト「Agents Observe」がHacker Newsに投稿され、注目を集めている。 Agents Observeとは Agents Observeは、Claude Codeのエージェント活動をリアルタイムでモニタリングするダッシュボードだ。Claude Codeのフック（hooks）機能を活用してすべてのイベントを捕捉し、WebSocketでReact製ダッシュボードにストリーミング配信する。 主な機能は以下のとおり： ツール呼び出しのリアルタイム表示：PreToolUse → PostToolUse の流れで、BashコマンドやファイルI/Oを即時確認 エージェント階層の可視化：どのサブエージェントがどの親エージェントから生成されたかを把握 フィルタリング・検索：エージェント別・ツール種別でのフィルタや全イベント横断検索 セッション履歴の閲覧：「twinkly-hugging-dragon」のような人間が読みやすい名前でセッションを管理 なぜOTELではなくフックを使うのか 開発者は、OpenTelemetry（OTEL）ではなくClaude Codeのフック機能を採用した理由についてこう説明する。「フックはOTELデータよりもはるかに多くの有用な情報を提供し、jsonlファイルと組み合わせることで完全な状況把握が可能になる」。 アーキテクチャはシンプルな4層構成だ： 元記事: Show HN: Real-time dashboard for Claude Code agent teams

米ベンチャーキャピタルのAndreessen Horowitz（a16z）は、半年ごとに発行している「生成AIコンシューマーアプリTop 100」の2026年3月版を公開した。消費者向けAIプロダクトの実際の利用動向を可視化することを目的としたこのレポートは、2023年の初版以来、生成AI市場の変遷を追う指標として注目されてきた。 ChatGPTは依然として圧倒的首位 OpenAIのChatGPTは、ウェブ月間訪問数で2位のGeminiの2.7倍、モバイルMAU（月間アクティブユーザー）でも2.5倍と、競合を大きく引き離している。週間アクティブユーザーは過去1年で5億人増加し、現在は9億人に達した。これは全世界人口の10%以上が毎週ChatGPTを利用している計算になる。 有料会員ではClaudeとGeminiが猛追 一方、有料会員数の伸び率では様相が異なる。Yipit Dataの集計によると、2026年1月時点でAnthropicのClaudeは前年比200%超の成長を記録。GoogleのGeminiも258%増と、いずれも急速に存在感を高めている。 Claudeを提供するAnthropicは、プロシューマー（専門的な個人ユーザー）向けに「Cowork」「Claude in Chrome」、さらにExcel・PowerPointへのプラグイン統合、そして開発者から高評価を受ける「Claude Code」を相次いでリリース。Googleも画像生成モデル「Nano Banana」で初週2億枚を生成・Geminiに1,000万人の新規ユーザーをもたらし、動画AIの「Veo 3」も業界内でブレークスルーと評価された。 なお絶対数ではChatGPTがClaudeの8倍、Geminiの4倍の有料会員数を持つため、首位の座はまだ揺るいでいない。 「デフォルトAI」をめぐる争いが本格化 レポートが今後の焦点として挙げるのが、「デフォルトAI」の座をめぐる競争だ。LLMはユーザーについて知れば知るほど精度が上がり、使えば使うほど手放せなくなるという「コンテキストの複利効果」が働く。月間セッション数では依然ChatGPTがウェブで1.3倍、モバイルで2.2倍とGeminiをリードしているが、Geminiはウェブでのセッション数が上昇傾向にある。 またChatGPTの「GPTs」とClaudeの「MCPインテグレーション/Connectors」に代表されるアプリストア型のエコシステム構築も、次の囲い込み層として注目されている。 AIは「特定ツール」から「全ソフトウェアの一部」へ 今版から、a16zはランキングの定義を拡張し、AI専用アプリだけでなく生成AIが体験の核となった既存アプリも対象に加えた。月間7億3,600万MAUを誇るCapCutは背景除去や自動キャプション、テキスト→動画生成をAIで実現。Canvaは「Magic Suite」でAI機能を成長エンジンの中核に据え、NotionはAI有料アタッチ率が1年で20%→50%超へ急上昇し、ARRのおよそ半分をAI機能が占めるまでになった。 「AIファースト企業とそれ以外」という区分は、もはや成立しなくなりつつある——a16zはそう結論づけている。日本でも多くのユーザーが利用するこれらのツールが、AIを「特別な機能」から「当たり前の体験」へと転換させている実態が、今回のレポートから改めて浮かび上がった。 元記事: Top 100 Gen AI Consumer Apps: March 2026 – A16Z Report

GoogleがGeminiに「記憶インポート」機能を追加——乗り換えコストをゼロへ Googleは、AIアシスタント「Gemini」に新機能「Import Memory（記憶インポート）」および「Import Chat History（会話履歴インポート）」を追加した。ChatGPTやAnthropicのClaudeなど競合AIが蓄積したユーザー情報を、わずかなコピー＆ペースト操作でGeminiに移行できる。 乗り換えの「最大の壁」を崩す AIアシスタントを長期間使い続けると、その助手は利用者の文体、仕事スタイル、個人的な好み、さらには「タブ vs スペース論争」のような細かなこだわりまで把握してくれる。この「育てた記憶」こそが乗り換えを躊躇させる最大の理由だった。Googleは今回、この心理的・技術的障壁を正面から取り除いた。 仕組みはシンプルなコピペ2ステップ 操作手順は直感的だ。 GeminiからあらかじめGoogleが用意したプロンプト文をコピーする ChatGPTやClaudeにそのプロンプトを貼り付けて実行する 返ってきた「自分についての要約」をGeminiに貼り付ける これだけで、Geminiは前のAIが知っていたユーザー情報をほぼ即座に把握する。「Import Chat History」機能では、会話スレッド全体をエクスポートしてGeminiに取り込むことも可能だ。通信業界で定着した「番号ポータビリティ」のAI版と言えるだろう。 OpenAI・Anthropicへの直接対抗 OpenAIはChatGPTのメモリ機能を継続強化し、Anthropicのクロードは文脈理解の深さで定評を得てきた。両社にとって、ユーザーが蓄積したパーソナライゼーションは一種の「ロックイン」だった。技術的な制約ではなく、乗り換えに伴うコストがユーザーを縛り付けていたのだ。 Googleはこのロックインを逆手に取り、「ウチに来ればゼロからやり直さなくて済む」という価値提案で差別化を図る。 AIアシスタント競争の新局面 AIチャットボット市場は、「最も賢いAIを作る競争」から「ユーザーをいかに定着させるか」という粘着性（スティッキネス）の争いへと移行しつつある。今回の機能追加はその流れを象徴しており、今後は他社も追随する可能性が高い。日本のビジネスユーザーにとっても、蓄積した業務コンテキストを捨てずにAIを乗り換えられる選択肢は歓迎されるだろう。 AIアシスタントの「引っ越し支援」競争が、いよいよ本格化しそうだ。 元記事: Google Gemini Lets You Import ChatGPT and Claude Memories

NVIDIAがオープンAIエコシステムを大幅拡張——全産業向けモデル・データ・ツールを一挙公開 NVIDIAは2026年1月、自動運転・ロボティクス・音声AI・バイオ医療など幅広い分野を対象とした新しいオープンモデル群、データセット、開発ツールを発表した。Nemotron、Cosmos、Alpamayo、Isaac GR00T、Claraという5つのファミリーにまたがるこの取り組みは、企業が実世界で動くAIシステムを自社構築できるよう支援することを目的としている。 圧倒的なスケールのオープンデータ NVIDIAが公開するオープンリソースの規模は前例がない。言語学習用トークン10兆件、ロボティクスの軌跡データ50万件、タンパク質構造データ45万5000件、自動車センサーデータ100テラバイトにのぼる。こうした多様なデータを無償提供することで、研究者や開発者が言語・ロボット・科学・自動運転の各領域でイノベーションを加速できる環境を整えた。 Nemotronファミリーの強化——音声・マルチモーダル・安全性 Nemotron Speech は、リアルタイムかつ低レイテンシの音声認識（ASR）を実現するモデル群だ。ライブキャプションや音声AIアプリケーションへの活用が想定されており、ベンチマーク上では同クラスの他モデルと比較して10倍の処理速度を達成している。BoschはNemotron Speechを採用し、ドライバーと車両のインタラクション機能に組み込む予定だ。 Nemotron RAG は、埋め込み（Embed）とリランク（Rerank）の2種のビジョン言語モデル（VLM）で構成される。多言語・マルチモーダルなドキュメント検索や情報検索の精度を高め、企業内の複雑な技術文書への適用が期待される。CadenceとIBMがパイロット導入を進めている。 Nemotron Safety は、AIアプリケーションの信頼性と安全性を強化するモデル群。新たに「Llama Nemotron Content Safety」（多言語対応を拡充）と「Nemotron PII」（個人情報の高精度検出）が加わった。CrowdStrike・Cohesity・Fortinetsなどのセキュリティ企業が採用を進めている。 自動運転向け世界初のオープン推論VLAモデル「DRIVE Alpamayo-R1」 自動運転分野では、新たなAlpamayoファミリーが登場した。中核となる「DRIVE Alpamayo-R1」は、自動運転向けとしては世界初のオープン推論型VLA（Vision-Language-Action）モデルとされており、複雑な実環境での知覚・推論・行動を統合的に処理できる。車両センサーデータ100TBを含む大規模なオープンデータセットと合わせて提供される。 ロボティクス・バイオ医療も対応 Hugging Face上でロボティクスは最も成長が速いセグメントであり、NVIDIAのオープンロボティクスモデルはダウンロード数でトップを走っている。Isaac GR00Tシリーズでは人型ロボット向けの新モデルが追加され、Claraプラットフォームでは創薬・タンパク質解析など生命科学領域向けの機能が拡張された。 日本企業への影響 今回の発表に連携企業として名を連ねる日立製作所も、NVIDIAのオープンモデル技術を活用した取り組みを進めている。国内でも製造・物流・医療など幅広い分野でこれらのモデルが活用されることが期待される。Palantirはモデルをオントロジーフレームワークに統合し、専門AIエージェント向けの統合技術スタック構築を進めている。 まとめ NVIDIAのオープン戦略は、単なるモデル公開にとどまらず、学習コード・データセット・ブループリントまで一体で提供するエコシステム構築へと進化している。大規模言語モデル（LLM）の競争が激化する中、物理AIとエッジ領域でのオープンスタンダードをNVIDIAが主導しようとする姿勢が鮮明になった。 元記事: NVIDIA Unveils New Open Models, Data and Tools to Advance AI Across Every Industry

Hugging Face、ポストトレーニングライブラリ「TRL v1.0」正式リリース Hugging Faceは、大規模言語モデル（LLM）のポストトレーニングに特化したPythonライブラリ「TRL（Transformer Reinforcement Learning）」のバージョン1.0を正式リリースした。 TRLとは TRLは、事前学習済みの言語モデルに対して人間のフィードバックや強化学習を用いて追加学習を行うためのライブラリだ。ChatGPTのような対話AIを作る際に不可欠な「RLHF（Reinforcement Learning from Human Feedback）」の実装を手軽に行える点が特徴で、Hugging FaceのTransformers・Accelerate・PEFTといったエコシステムとシームレスに統合されている。 v1.0での主な変更点 今回のv1.0は、ここ数年で急速に発展したポストトレーニング手法の多様化に対応するため、ライブラリの設計思想そのものを見直した節目のリリースとなっている。 もともとTRLはPPO（Proximal Policy Optimization）アルゴリズムを中心に設計されたライブラリだった。PPOは2017年にOpenAIが発表した強化学習アルゴリズムで、LLMの対話能力を向上させるRLHFの中核として長らく使われてきた。 しかし近年、DPO（Direct Preference Optimization）やGRPO（Group Relative Policy Optimization）など、PPOと比較してより軽量・安定したポストトレーニング手法が次々と登場した。特にDPOはreward modelを別途学習する必要がなく、実装の手軽さから研究・開発現場での採用が急速に広まっている。GRPOはDeepSeek-R1の学習にも採用されたことで日本国内でも注目を集めている手法だ。 v1.0ではこうした新手法への対応を強化しつつ、「フィールドの進化についていける」設計に刷新されており、今後登場する新しいアルゴリズムにも柔軟に対応できるアーキテクチャが採用されている。 日本の開発者への影響 国内でも、LLMのファインチューニングや独自チャットボット開発に取り組む企業・研究機関が増加している。TRLはHugging Faceのエコシステムに乗っているため、すでにTransformersを使った開発を行っているチームであれば導入コストは低い。 GPUリソースが限られる環境向けに、PEFTによるLoRAとの組み合わせも公式でサポートされており、コンシューマグレードのGPU（例：RTX 4090など）でもLLMのRLHFが現実的に実行できる点は、中小規模の開発チームにとって大きなメリットだ。 入手方法 TRL v1.0はPyPIで公開されており、以下のコマンドでインストールできる。 元記事: TRL v1.0: Post-Training Library Built to Move with the Field

IBMが企業向け軽量マルチモーダルモデル「Granite 4.0 3B Vision」を公開 IBMは、企業向け文書処理に特化した小型マルチモーダルAIモデル「Granite 4.0 3B Vision」をHugging Faceで公開した。約4Bパラメータという比較的コンパクトなサイズながら、画像とテキストを組み合わせて処理する「Image-Text-to-Text」タスクに対応しており、企業現場での実運用を強く意識した設計が特徴だ。 「小さく、賢く、使いやすく」——企業ユースケースへの最適化 Granite 4.0 3B Visionは、IBMのGraniteシリーズの最新世代にあたる。Graniteシリーズはもともとエンタープライズ向けに設計されており、コードベース解析や業務文書の要約・抽出など、実務に直結するユースケースへの対応を重視してきた。 今回のVisionモデルはその路線をマルチモーダル領域へと拡張したもので、請求書・契約書・技術図面といった「画像として届く企業文書」をそのまま読み解く能力を持つ。GPT-4oやGemini 1.5 Proなどの大規模モデルと同等の文書理解タスクを、はるかに少ないリソースで処理できる点が企業導入のハードルを下げると期待されている。 軽量モデルが注目される背景 生成AI活用が本格化するにつれ、クラウド経由のAPI利用ではなくオンプレミスやプライベートクラウドでの自前運用を求める企業が増えている。特に金融・医療・法務といった機密性の高い業種では、データを外部サービスに送信することへの抵抗感が強い。 3〜4Bクラスのモデルであれば、高性能GPUを大量に用意しなくても動作するケースが多く、既存のサーバーインフラへの統合が現実的になる。IBMがあえてこのサイズ帯でVisionモデルを投入した背景には、こうした「現場で動かせるAI」への需要がある。 オープンウェイトでの公開——透明性と再現性の担保 Granite 4.0 3B VisionはHugging Face上でウェイトが公開されており、研究者や開発者が自由にダウンロードして利用・評価できる。IBMはGraniteシリーズのトレーニングデータや使用許諾についても比較的透明性の高い情報開示を行っており、企業が導入審査を行いやすい点も強みのひとつだ。 公開からわずか約14時間で1,200件超のダウンロードを記録しており、エンタープライズAIコミュニティからの注目度の高さがうかがえる。 日本企業への示唆 日本では紙文書や複合機からスキャンしたPDFが業務の主役であり続けており、「画像として存在する文書」を自動処理するニーズは特に高い。Granite 4.0 3B Visionのような軽量マルチモーダルモデルは、DXを推進したい中堅・大企業にとって現実的な選択肢となりそうだ。IBM Japanを通じた商用サポートの提供も今後期待される。 元記事: Granite 4.0 3B Vision: Compact Multimodal Intelligence for Enterprise Documents

Axiosにサプライチェーン攻撃——週間1億ダウンロードのHTTPクライアントが標的に 2026年3月31日、JavaScriptエコシステムで広く使われているHTTPクライアントライブラリ「Axios」が、npmを通じたサプライチェーン攻撃の被害を受けたことが明らかになった。Axiosは週間1億100万ダウンロードを誇る超メジャーパッケージであり、その影響範囲は計り知れない。 何が起きたか 今回の攻撃では、Axiosのバージョン 1.14.1 および 0.30.4 に、plain-crypto-js という新しい依存パッケージが追加された。この plain-crypto-js はその日に新規公開されたマルウェアであり、認証情報の窃取とリモートアクセス型トロイの木馬（RAT）のインストールという二段構えの悪意ある機能を持っていた。 このようなサプライチェーン攻撃は、ユーザーが直接マルウェアをインストールするわけではなく、信頼するライブラリの依存関係として自動的に引き込まれる点が特に危険だ。Axiosのような信頼性の高いパッケージへの混入であれば、多くの開発者がセキュリティチェックをすり抜けてしまう可能性がある。 攻撃の手口：流出したnpmトークン 調査の結果、攻撃者は有効期限のない長期npmトークン（long-lived npm token）の流出を悪用してパッケージを公開したとみられている。 AxiosのGitHubリポジトリには、Trusted Publishing（信頼済み公開）の採用を求めるIssueがすでに存在している。Trusted Publishingを導入すると、npmへの公開をGitHub Actionsのワークフローからのみに制限できるため、今回のような不正なトークン悪用を防ぐことができる。 見分けるためのヒント：GitHubリリースのないnpm公開 セキュリティ研究者のSimon Willisonは、今回の攻撃に際して興味深い観察を共有している。 「悪意ある公開パッケージには、対応するGitHubリリースが存在しない」 このパターンは、先週発覚したLiteLLMへのサプライチェーン攻撃でも同様に確認されており、不審なリリースを見つけるための有効な経験則になりうるという。npmでパッケージが更新された際、GitHubのリリースタグと照合する習慣をつけることが、今後のサプライチェーンリスク低減につながる。 日本の開発者へ AxiosはNext.js、Nuxt、React、Vue.jsなど日本でも広く使われているフレームワークのプロジェクトで標準的に採用されている。package-lock.json や yarn.lock を確認し、1.14.1 または 0.30.4 を使用している場合は即座にバージョンを変更することが推奨される。また、plain-crypto-js への依存が混入していないかを npm ls plain-crypto-js で確認するのも有効だ。 オープンソースのサプライチェーンへの攻撃は近年急増しており、今回の事例はその深刻さを改めて浮き彫りにしている。 元記事: Supply Chain Attack on Axios Pulls Malicious Dependency from npm

SalesforceがSlackを全面AI強化——30の新機能を一挙発表 クラウドソフトウェア大手のSalesforceは、サンフランシスコで開催した少人数向けイベントにおいて、ビジネスチャットツール「Slack」の大規模アップデートを発表した。CEOのマーク・ベニオフ氏が自ら登壇し、AI機能を中心とした30の新機能を披露。Slackを単なるコミュニケーションツールから、企業の業務プロセスを一手に担う「AIエージェント基盤」へと位置づけ直す狙いが鮮明になった。 再利用可能な「AIスキル」が業務を自動化 今回の発表で最も注目を集めたのが、再利用可能なAIスキル（Reusable AI-Skills）だ。ユーザーがSlackbotに対して特定のタスクをあらかじめ定義しておくことで、さまざまな場面で繰り返し呼び出せるようになる。 たとえば「イベントの予算を作成して」とSlack上でコマンドを入力するだけで、Slackbotが関連するチャンネルや連携アプリのデータを自動的に収集・整理し、実行可能なプランを生成。さらに、職種をもとに関係する社員を自動で特定してミーティングを設定するところまでを一気に処理する。 SalesforceによればSlackbotには標準のスキルライブラリが組み込まれており、ユーザーが独自のカスタムスキルを作成することも可能だ。繰り返し発生する定型業務の大幅な効率化が期待される。 MCPクライアント対応でエンタープライズ全体と連携 Slackbotは今回のアップデートでMCP（Model Context Protocol）クライアントとしての機能も備えた。MCPは外部サービスやツールとAIエージェントをつなぐプロトコルで、近年さまざまなAIプラットフォームが採用を進めている。 この対応により、Slackbotは2024年にSalesforceが立ち上げたAIエージェント開発プラットフォーム「Agentforce」とも連携可能になった。社内のあらゆるエージェントやアプリへ作業を振り分け、人手を介さずに最適な処理ルートを自律的に判断するという。 会議の文字起こし・要約、デスクトップ監視も Slack暫定CEOのロブ・シーマン氏によれば、Slackbotはミーティングのリアルタイム文字起こしと要約にも対応。途中で集中が途切れてしまった参加者も、Slackbotに「自分のアクションアイテムをまとめて」と依頼するだけで必要な情報をすぐに確認できる。 さらに、Slackの外部でユーザーのデスクトップ操作を監視し、商談・会話・カレンダー・行動パターンなどを分析した上で、次の行動を提案したりフォローアップのメッセージを自動起草したりする機能も追加される。プライバシー保護の仕組みも内包されており、ユーザーが権限設定を細かく調整できるとしている。 「Slack買収から5年」——AIで再定義を狙う SalesforceがSlackを277億ドルで買収したのは2021年のこと。ベニオフCEOは今回の基調講演で、その5年間を振り返りながら「Slackを企業の中核業務に欠かせないプラットフォームにする」という意気込みを示した。 日本企業にとっても、Slackはすでに多くの開発・IT部門で利用されている馴染み深いツールだ。今回のAI強化によって、チャットの枠を超えた業務自動化の基盤として活用できるかどうか——実際の使い勝手が問われることになる。新機能は今後数ヶ月以内に順次提供される予定だ。 元記事: Salesforce announces an AI-heavy makeover for Slack, with 30 new features

LiteLLMへの不正コード混入が大規模被害に発展 AI採用スタートアップのMercorは、オープンソースプロジェクト「LiteLLM」を標的にしたサプライチェーン攻撃に起因するセキュリティインシデントを公式に認めた。同社はTechCrunchの取材に対し、今回の被害は「数千社に及ぶ影響企業のうちの1社」であると述べた。 ハッキング集団が攻撃への関与を宣言 今回の侵害には、TeamPCPと呼ばれるハッキンググループが関与しているとされる。また、悪名高い恐喝目的のハッキング集団**Lapsus$**もMercorへの攻撃と同社からのデータ取得を自ら名乗り出ており、リークサイトにはSlackのデータやチケット管理データ、さらにMercorのAIシステムとコントラクターのやり取りと思われる動画2本を含むサンプルデータが掲載された。ただし、Lapsus$がTeamPCPのサイバー攻撃経由でMercorのデータを入手した経緯の詳細は現時点では不明だ。 Mercorとは — OpenAIやAnthropicとも連携するAI採用企業 2023年創業のMercorは、OpenAIやAnthropicなどを顧客とし、AIモデルの訓練用データ収集のためにインドなどの市場から科学者・医師・弁護士といった専門家をコントラクターとして仲介するAI採用プラットフォームだ。1日200万ドル（約3億円）以上の報酬支払いを仲介しており、2025年10月にはFelicis Ventures主導の3億5,000万ドル（約530億円）のシリーズCラウンドで評価額100億ドル（約1.5兆円）に達したことでも注目を集めている。 Mercorの広報担当Heidi Hagberg氏は「インシデントの封じ込めと復旧に速やかに対処した。大手サードパーティのフォレンジック専門家を起用した徹底的な調査を進めており、顧客・コントラクターへの直接連絡も継続している」とコメントした。一方で、Lapsus$との関連性や顧客データの流出有無については回答を拒否した。 LiteLLMとは — 1日数百万ダウンロードの人気ライブラリ LiteLLMは、OpenAI・Anthropic・Geminiなど複数のLLM（大規模言語モデル）APIを統一インターフェースで呼び出せる人気のOSSライブラリで、Y Combinator支援のスタートアップが開発している。セキュリティ企業Snykによれば1日あたり数百万回ダウンロードされており、企業のAIシステムに広く組み込まれている。 今回の問題は先週、LiteLLMの関連パッケージに悪意あるコードが混入しているのが発見されたことで発覚した。コードは数時間以内に特定・除去されたものの、LiteLLMの普及度の高さからその影響範囲が注目されている。この件を受けてLiteLLM側もコンプライアンス対応を見直し、セキュリティ認証の取得パートナーを物議を醸していたスタートアップ「Delve」から「Vanta」に切り替えた。 サプライチェーン攻撃のリスクが再び顕在化 今回の事例は、AIシステムの基盤となるOSSライブラリへの不正コード混入という「ソフトウェアサプライチェーン攻撃」の脅威を改めて示している。依存ライブラリのセキュリティ管理は、AIスタートアップに限らず、OSSを活用するすべての企業にとって重要な課題となっている。影響を受けた企業の全体数やデータ流出の実態については、現在も調査が続いている。 元記事: Mercor says it was hit by cyberattack tied to compromise of open-source LiteLLM project

Claude Codeのソースコード流出——51万行超が誤公開、未公開機能が次々と発覚 AIコーディングツール「Claude Code」を開発するAnthropicが、バージョン2.1.88のアップデートパッケージに内部TypeScriptコードのソースマップファイルを誤って同梱してしまうという失態を犯した。この流出コードは51万2,000行超にのぼり、X（旧Twitter）上のユーザーがいち早く発見・公開。Ars TechnicaやVentureBeatも相次いで報じ、技術コミュニティに大きな波紋を呼んだ。 発覚した未公開機能の数々 コードを解析したユーザーたちは、複数の興味深い未公開機能を発見している。 たまごっち風ペット機能 Redditの投稿によると、入力欄の横に「ペット」が表示され、コーディングの進捗に応じてリアクションするというユニークな機能が確認された。開発体験をゲーミフィケーションする試みとみられる。 常時稼働バックグラウンドエージェント「KAIROS」 より注目度が高いのが、コードネーム「KAIROS」と呼ばれる機能だ。ユーザーの明示的な指示なしにバックグラウンドで常時稼働するエージェント機能と見られており、Claude Codeのエージェント化をさらに進める布石になりそうだ。 開発者の本音コメント さらに、Anthropicのエンジニアによるコードコメントも見つかった。「このメモ化（memoization）は複雑さをかなり増やしているが、本当にパフォーマンスが改善しているかは正直わからない」という率直な一文で、開発現場のリアルな葛藤が垣間見えると話題になった。 拡散は止まらず——GitHubで5万フォーク超 Anthropicは問題を認識後、速やかにアップデートを修正。しかしそれより先に、流出コードはGitHubのリポジトリにコピーされ、5万フォーク以上という驚異的な速さで世界中に拡散した。デジタルデータの性質上、一度公開された情報を完全に回収することは事実上不可能な状態となっている。 Anthropic公式コメント——「セキュリティ侵害ではない」 Anthropicの広報担当クリストファー・ナルティ氏はThe Vergeに対し、次のようにコメントしている。 「本日、Claude Codeのリリースに内部ソースコードが含まれていました。顧客データや認証情報などの機密情報は一切含まれておらず、漏洩もありません。これはセキュリティ侵害ではなく、人的ミスによるリリースパッケージングの問題です。再発防止策を順次展開しています。」 専門家の見解——長期的影響は限定的か 調査会社GartnerのAIアナリスト、アルン・チャンドラセカラン氏は、今回の流出について「悪意ある行為者がガードレール（安全制約）を回避する手がかりを得る可能性というリスクはある」としながらも、長期的な影響は限定的だと分析。「Anthropicにとっては、プロセスやツールへの投資を通じてオペレーショナルな成熟度を高めるきっかけになるだろう」と述べた。 Claude Codeとは Claude Codeは2025年2月にリリースされたAnthropicの開発者向けAIコーディングツール。その後、ユーザーに代わってタスクを自律的に実行するエージェント機能を追加し、急速に存在感を高めている。日本でもGitHub CopilotやCursorと並ぶAIコーディングアシスタントとして開発者の注目を集めており、今回の流出で明らかになった未公開機能の正式リリースに期待が高まっている。 Anthropicの次の一手——特に「KAIROS」のような常時稼働エージェント機能がいつ、どのような形で正式公開されるかが、今後の注目点となりそうだ。 元記事: Claude Code leak exposes a Tamagotchi-style ‘pet’ and an always-on agent

Claude CodeのソースコードがNPMマップファイル経由で流出 Anthropicが開発するAIコーディングアシスタント「Claude Code」のソースコードが、NPMレジストリに含まれるJavaScriptソースマップ（.mapファイル）を通じて誰でも閲覧可能な状態になっていたことが明らかになった。 ソースマップとは何か JavaScriptのビルドプロセスでは通常、本番配布用にコードを難読化・圧縮（ミニファイ）する。しかしデバッグを容易にするため、圧縮前の元ソースと圧縮後コードの対応関係を記録した「ソースマップファイル（.map）」を生成することがある。このファイルをNPMパッケージに誤って同梱してしまった場合、事実上の「ソースコード公開」に等しい状態になる。 Claude CodeはNPMパッケージとして配布されており、今回はまさにこの落とし穴にはまった格好だ。 流出から判明した内部実装の詳細 Hacker Newsで866件以上のコメントを集めた関連スレッド「The Claude Code Source Leak: fake tools, frustration regexes, undercover mode」では、流出したソースコードを解析した結果として複数の興味深い実装が報告されている。 フェイクツール（Fake tools） Claude Codeが実際には存在しないか、あるいは期待通りに動作しないツールを「あるかのように」提示している実装が含まれていたとされる。これはユーザー体験の調整やフォールバック処理の一環とみられるが、透明性の観点から議論を呼んでいる。 フラストレーション正規表現（Frustration regexes） ユーザーが苛立ちや怒りを示すようなメッセージを送った場合に検出するための正規表現が含まれていたという。ユーザーの感情状態を把握してレスポンスを調整する仕組みとみられ、「AIが人間の感情を監視している」という点でプライバシー面での懸念も指摘されている。 潜伏モード（Undercover mode） Claude Codeが自身のアイデンティティを隠す、もしくはAIであることを明かさない動作モードの実装が確認されたとの報告もある。ベンチマーク評価時の挙動調整など、複数の用途が推測されているが、詳細はまだ調査中だ。 Anthropicへの影響と業界の反応 Hacker NewsやX（旧Twitter）ではこの流出が急速に拡散し、元ツイートは多数のエンゲージメントを獲得。AI企業の「ブラックボックス」に対する透明性への関心の高さを改めて示した。 AnthropicはClaudeシリーズをクローズドモデルとして提供しており、内部実装の詳細は非公開が原則だ。今回の流出は意図的な情報公開ではなく、ビルド・パッケージングプロセスにおけるミスとみられる。 日本では多くの開発者がClaude Codeを業務に活用しており、今回明らかになった内部実装の詳細——特にフラストレーション検出や潜伏モード——については、利用方針やプライバシーポリシーの観点から改めて精査する価値があるだろう。 教訓：NPMパッケージのソースマップ管理 この事例は、商用ソフトウェアをNPMで配布する際のセキュリティ管理の重要性を改めて示している。.mapファイルの同梱有無は.npmignoreやpackage.jsonのfilesフィールドで制御できるため、クローズドソースのツールを配布する開発者は自社パッケージの設定を今一度確認することを推奨する。 Anthropicからの公式声明は現時点では出ていない。 元記事: Claude Code’s source code has been leaked via a map file in their NPM registry

Claude Codeのソースコードが流出——偽ツール注入・感情検知・未公開エージェントモード「KAIROS」とは Anthropicが開発するAIコーディングアシスタント「Claude Code」のソースコードが、NPMパッケージへのソースマップ（.mapファイル）の誤同梱によって流出した。パッケージはすぐに取り下げられたが、コードはすでに広くミラーリングされ、Hacker News上でも大きな話題となっている。 Anthropicにとってこれは1週間で2度目の情報漏洩事故だ（直前にはモデル仕様書のリークもあった）。また、ちょうど10日前にはOpenCodeに対して法的措置を取り、サードパーティによるClaude Codeの内部API悪用を問題視していたばかりとあり、今回の流出内容がより注目を集めている。 偽ツール注入による「反蒸留（Anti-distillation）」機構 最も注目を集めた発見が、claude.ts（301〜313行目）に存在するANTI_DISTILLATION_CCフラグだ。これが有効な場合、Claude CodeはAPIリクエストにanti_distillation: ['fake_tools']を含め、サーバー側がシステムプロンプトに「偽のツール定義」を静かに注入する。 目的は明快だ——Claude CodeのAPIトラフィックを傍受して競合モデルの学習に使おうとする行為を妨害するため、意図的に汚染データを混入させる。この機能はGrowthBook社のフィーチャーフラグ（tengu_anti_distill_fake_tool_injection）でゲートされており、ファーストパーティCLIセッションのみに適用される。 もっとも、研究者が指摘するように回避策は単純で、MITMプロキシでanti_distillationフィールドをリクエストボディから除去するか、環境変数CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETASを設定するだけで無効化できる。実質的な保護はむしろ法的手段に依存しているとみられる。 「アンダーカバーモード」——AIがAIであることを隠す ソースには、AIであることを開示せずに動作するモードの存在も確認された。特定の条件下でClaude CodeがAIアシスタントとしての素性を表に出さずに応答するこの機能は、エンタープライズ向けの特定ユースケースを想定したものとみられる。 正規表現によるユーザーの感情（フラストレーション）検知 驚くべきことに、ユーザーのフラストレーション検知にLLMではなく正規表現が使われていることも判明した。「damn」「wtf」「not working」といったパターンにマッチした場合に、システムが何らかの応答を調整する仕組みだ。シンプルながら軽量で実用的な設計判断と言えるが、AIツールの感情認識がこのような古典的手法で実装されていることには多くの開発者が驚きを示している。 1日25万件の「無駄なAPIコール」 パフォーマンス面でも気になる数字が出てきた。設計上の問題とみられる不要なAPIコールが1日あたり約25万件発生しているという。コスト面やレイテンシへの影響が懸念される。 未公開の自律エージェントモード「KAIROS」 おそらく最も衝撃的な発見が、KAIROSと呼ばれる未リリースの自律エージェントモードだ。詳細は限られているが、現在の対話型モードを超えた、より高度な自律実行能力を持つモードとして開発が進んでいるとみられる。Anthropicが近い将来にエージェント機能を大幅に強化する計画を持っていることを示唆しており、業界関係者の注目を集めている。 まとめ 今回の流出は、Anthropicにとって技術的・法的・広報的な打撃となった。一方で、現代の商用AIツールがどのような工夫と妥協のもとで構築されているかを垣間見る、稀な機会にもなっている。日本国内でもClaude Codeの利用者は増加しており、これらの実装が今後の開発判断や競合製品の設計にどう影響するか、引き続き注目が集まりそうだ。 元記事: The Claude Code Source Leak: fake tools, frustration regexes, undercover mode