Generative-Ai

ドイツの裁判所がGoogleに対し、AI Overview機能が生成した誤情報への法的責任を認定した。セキュリティ研究者のBruce Schneierはこの判決を受け、「AIエージェントはそれを導入した企業の代理人であり、法的にも同じ扱いを受けるべきだ」と主張。生成AIを業務に組み込む企業にとって、看過できない問いを突きつけている。 判決の概要：GoogleのAI Overviewが生成した誤情報に「自社発言」と認定 今回のドイツ裁判所の判決は、Googleの検索結果上部に自動表示される要約機能「AI Overview」が誤情報を出力したケースに関するもの。裁判所はこれを「Googleが自ら発した言葉」と判断し、AI生成であることを理由とした免責を認めなかった。 Schneierはこの結論を「論理的に当然」と評した上で、次の論理を展開している。 「もし企業が人間のライターを雇って要約を書かせ、そこに誤情報があれば当然責任を負う。AIを使った場合だけ責任が免除されるなら、それは企業への莫大な利益供与であり、コーポレートガバナンスを根本から歪める」 AIが「安価な免責装置」になるリスク Schneierが最も強調するのは、AIに法的責任が認められない場合に生まれるインセンティブの歪みだ。 「AIが書いたから責任はない」が通るなら、企業はコスト削減のためにAIを活用しつつ、ミスが起きても言い逃れができる。その結果、品質と正確さへの責任を担う人間——ライター、弁護士、医師など——を雇う経済的動機が失われていく。低コストのまま責任だけが霧散する構造は、社会全体にとって危険だ。 実務への影響：日本企業が今すぐ整備すべきこと 日本においてもAI生成コンテンツの責任帰属はグレーゾーンが残るが、今回のドイツ判決は国際的な法整備の方向性を示す指標として無視できない。AI活用を進めるIT部門・法務部門が今すぐ対応すべきポイントを整理する。 AIアウトプットのレビュープロセスを必ず設ける：顧客向けコンテンツ（FAQ・商品説明・サポート回答）はAI生成であっても企業責任が問われる 「AIが生成した」を免責理由に使わない：社内規程と対外的な説明方針を今のうちに文書化する 高リスク領域（法律・医療・金融）では人間レビューを必須化：AIの活用範囲と人間の監督範囲を明確にドキュメント化する 利用規約・契約書にAI活用範囲を明示：顧客に透明性をもって伝える枠組みを整備する 筆者の見解 今回の判決とSchneierの指摘は、本質をついていると思う。AIはあくまでも企業が選択して導入する「手段」だ。その精度に問題があれば、選んだ側が責任を取る——これは当たり前の話であり、法的に明確になることでAI活用の質は上がるはずだ。 私はずっと「禁止するのではなく、安全に使える仕組みを作れ」という考え方を大切にしてきた。この判決はまさに、社会としてその「仕組み」を整備する一歩だと捉えている。責任の所在が明確であれば、企業はAIアウトプットの品質管理に真剣に向き合わざるを得なくなる。それは健全な競争圧力として機能する。 日本のIT企業はAI活用を急ぐあまり、ガバナンスの整備が後手に回りがちだ。「AIを導入して効率化した」と喜ぶ前に、「そのAIが出した回答の責任は誰が取るのか」を設計しておく必要がある。今のうちに社内のAI利用ポリシーとレビュープロセスを整備しておくことを、強くお勧めしたい。 出典: この記事は AI and Liability の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Google DeepMindは2026年6月24日、AIモデル「Gemini 3.5 Flash」に「Computer Use（コンピューター操作）」機能を標準搭載したと発表した。これまで別モデル「Gemini 2.5 computer use」としてのみ提供されていた機能が主力の高速モデルに統合され、ブラウザ・モバイル・デスクトップ環境を横断する自律エージェントの構築が開発者向けAPIで利用可能になった。 Computer Useとは何か Computer Useとは、AIモデルが画面を「見て」理解し、クリック・テキスト入力・スクロールなどの操作を自律的に実行する能力のことだ。人間がPCを操作するのとほぼ同じ方法で、AIがGUIアプリケーションを操作できる。 Anthropicが2024年にClaude向けに発表して以来、各社が追随してきたこの機能カテゴリに、GoogleもGemini 2.5ベースの専用モデルとして参入。今回それをGemini 3.5 Flashのビルトインツールとして統合した形だ。 Gemini 3.5 Flashへの統合が意味すること Geminiシリーズはこれまで、Function CallingやSearchグラウンディング、Mapsグラウンディングといったビルトインツールを持っていた。今回のComputer Use統合により、これらと同じレイヤーで「画面操作」が扱えるようになる。 公式に挙げられているユースケースは以下のとおりだ： 継続的ソフトウェアテスト: 実際のブラウザ上でUIテストを自動実行し、リグレッションを継続検知 ナレッジワークの自動化: 複数の業務アプリケーションを横断した情報収集・入力・転記作業 アクセシビリティ監査: 自社ドキュメントやWebサイトのアクセシビリティ問題を自動検出 「Gemini Enterprise Agent Platform」との組み合わせにより、エンタープライズ規模のワークフロー自動化が想定されている。 安全対策——プロンプトインジェクションへの多層防御 Computer Useはその性質上、外部コンテンツからの「プロンプトインジェクション」攻撃に脆弱だ。Webページや文書に悪意のある指示が埋め込まれ、エージェントが意図しない操作（ファイル送信、フォーム送信など）を実行してしまうリスクがある。 Googleは以下の三段構えの対策を講じている： 敵対的トレーニング: プロンプトインジェクションへの耐性をモデルレベルで強化 センシティブ操作の確認要求: 不可逆な操作の前に明示的なユーザー確認を要求するオプション 自動タスク停止: 間接的なプロンプトインジェクションを検知した場合にタスクを自動停止するオプション これをGoogleは「Defense-in-Depth（多層防御）」と位置付け、セキュアなサンドボックス化・ヒューマンインザループ検証・厳格なアクセス制御との組み合わせを推奨している。 試し方・利用開始の方法 Gemini API: 開発者が直接呼び出してカスタムエージェントを構築 Gemini Enterprise Agent Platform: エンタープライズ統合環境として利用 Browserbaseのデモ環境: Googleが提供するホスト型デモで即時動作確認が可能 リファレンス実装とドキュメントはGemini APIの公式ドキュメントとGemini Enterprise Agent Platformで公開されている。 実務への影響——日本のエンジニア・IT管理者へ RPA（ロボティック・プロセス・オートメーション）や自動テストを検討している現場には注目すべき動向だ。 従来のRPAはXPathやCSSセレクターに依存するため、アプリケーションのUI変更でスクリプトが壊れる問題が長年の課題だった。Computer UseベースのAIエージェントは視覚的に画面を理解するため、この脆弱性を原理的に回避できる可能性がある。 ただし実際に採用を検討する前に確認すべき点がある： 日本語UIへの対応精度: 英語環境中心の開発であり、日本語UIレイアウトや縦書き・IME操作への対応を自社環境で実際に検証する必要がある セキュリティポリシーとの整合: 社内システムへのアクセスを伴う場合、情報セキュリティ規程との整合確認が必須 APIコストのROI計算: 長時間実行するエージェントはAPIコストが積み上がるため、自動化対象業務の工数削減効果と比較した試算が欠かせない まずはBrowserbaseのデモ環境か社内開発環境で限定的に試し、「動いた」ではなく「業務として使い続けられる」水準かを小規模に検証することを強くお勧めする。 ...

Appleがハイエンド向けMacチップのM6シリーズ（M6 Pro/Max/Ultra）を飛ばし、AI処理に特化した「M7 Pro」「M7 Max」「M7 Ultra」を直接投入する方針であることをBloombergが報じた。 M6上位モデルをスキップした背景 Bloombergの報道によれば、エントリー向けの「M6（無印）」は予定通り展開しつつも、Pro・Max・Ultraの上位バリアントについてはM6世代を丸ごと飛ばし、M7世代に直接移行するとのことだ。 この決断の根底にあるのは、AI処理能力への集中投資だ。近年のAI推論ワークロードは、汎用CPUやGPU性能よりも専用のNeural Engine（ニューラルエンジン）と統合メモリ帯域幅の性能に依存する割合が急増している。M7シリーズではこの点を従来世代から大幅に引き上げることが最優先事項とされているとみられる。 ハイエンドMacユーザーへの影響 Mac ProやMac Studioの主要ユーザー——映像クリエイター、音楽プロデューサー、機械学習エンジニア——にとっては、待機期間こそ延びるが、M7世代を直接入手できるメリットがある。 特にAI・機械学習開発を行うエンジニアにとって影響は大きい。AppleシリコンのUnified Memory（統合メモリ）アーキテクチャは、大規模言語モデル（LLM）をローカル実行する際のコストパフォーマンスが際立って高い。M7 Ultraともなれば数百GBの統合メモリを積む可能性もあり、数百億パラメータ規模のモデルをローカルで動かすことが現実的な選択肢になりうる。 Apple Intelligenceとチップ戦略の一体化 AppleはApple Intelligence（AI機能群）の強化に向けて、チップレベルからの設計見直しを進めている。M7シリーズは単なる性能向上ではなく、プライバシーを担保しながらオンデバイスでAI処理を完結させるAppleの中長期戦略を支えるコアコンポーネントとして位置づけられている。 クラウドに送らずデバイス内でAI推論を行う方向性は、情報漏洩リスクを気にするエンタープライズ向けにも響く。MacをAIワークステーションとして業務採用するケースが今後加速するだろう。 実務への影響 AI開発者・MLエンジニアへ: M6上位モデルを飛ばしてM7に直行する方が長期コストパフォーマンスに優れる。現行のMac Pro/Mac Studioの購入はM7世代のリリーススケジュールを確認してから判断したい。 IT調達担当者へ: 法人向けMac導入計画をM6ベースで組んでいる場合は要再検討。特にAI活用を見据えた用途ならM7世代まで待つ合理性がある。 一般ユーザーへ: 文書作成・Web閲覧・コミュニケーション程度の用途はM6（無印）で十分。上位チップが必要な重い処理用途のみM7世代を検討する価値がある。 筆者の見解 半導体ロードマップを世代単位でスキップする決断は珍しいが、Appleの意図は読みやすい。「次の製品発表でAIを語るとき、チップが足を引っ張ってはならない」という強い意思表示だろう。 ハードウェアメーカーが製品ロードマップをAI性能中心に再設計する流れは、今後さらに加速する。M7世代でローカルLLM実行の現実性が一気に高まれば、クラウド依存を減らしながらAIを活用したいエンタープライズにとって選択肢が広がる。セキュリティ要件の厳しい組織ほど、この動きに注目する価値がある。 一方で、世代スキップはM6ベースのMacを長く使い続けるユーザーへのメッセージでもある。Appleが全力でAIに賭けるほど、既存ユーザーとの関係設計——サポート年数や移行支援——も問われてくる。 AIがチップ設計そのものを変えてしまっている。その変化の速さに、私たちの調達・評価サイクルも追いつかなければならない。 出典: この記事は Apple to skip high-end M6 Mac chips in favor of AI-focused M7 line の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIチップメーカーのCerebras Systemsは上場後初の四半期決算を発表したが、翌日の株価は約20%急落し、IPO公開価格に迫る水準まで下落した。業績自体は市場予想を上回っていただけに、「良決算なのに株価急落」という典型的なガイダンスショックの構図となった。 何が起きたのか Cerebrasの2026年第1四半期（1〜3月）売上高は1億9,300万ドルで、前年同期比94%増という圧倒的な成長を見せた。純損失も2,390万ドルから1,400万ドルへと縮小しており、数字の上では順調な黒字化への歩みを示している。 ところが投資家がパニックを起こしたのは業績数字ではなく、通期の粗利率ガイダンスだった。第1四半期の粗利率47%に対し、通期見通しを38〜41%に設定したことで「業績は良くてもマージンが悪化している」と受け取られ、売りが殺到した。 なぜ粗利率が下がるのか CEOのアンドリュー・フェルドマン氏はCNBCのインタビューで、投資家の誤解だと説明した。 問題の核心は自社データセンター建設中の過渡的なコストにある。Cerebrasはキャパシティを早期に提供するため、一時的に既存顧客から自社機器を「リースバック」（一度顧客に提供した設備を借り直す形）しながら、並行して自社データセンターの建設・展開を進めている。このリースバック構造が今期に限って収益性を圧迫しており、自社設備が整い次第、粗利率は正常化する見込みだという。 つまり構造的な競争力低下ではなく、成長投資に伴う一時的なコスト増だというのがCerebrasの主張だ。 Cerebrasとはどのような企業か Cerebrasはウェーハスケールエンジン（WSE）と呼ばれる独自の超大型チップを武器に、AI推論の高速化を図る半導体スタートアップだ。NVIDIAが複数のGPUを並列接続する設計を採用するのに対し、Cerebrasはシリコンウェーハをほぼそのままチップとして使い、チップ間通信のオーバーヘッドをゼロにするアーキテクチャを採る。特に大規模言語モデル（LLM）の推論速度で実績を持ち、特定のワークロードではNVIDIAのH100クラスタを数倍のスループットで上回ると主張している。 日本のIT現場にとっての意味 現状、日本企業がCerebrasチップを直接調達するケースはまだ限定的だが、今回の決算が示す構造は見逃せない。 AI推論インフラへの需要拡大は本物だ。 売上高94%増という数字は、企業がAIの推論処理にどれだけの予算を投じ始めているかを示している。生成AIを業務システムに組み込む際のインフラ選定において、「NVIDIAだけが選択肢ではない」という現実を意識する価値がある。 また、Cerebrasが経験しているデータセンター移行コストは、AI時代のインフラ投資の難しさを端的に示す例でもある。高スループットを実現するには設備への先行投資が不可欠で、移行期には必ずコスト構造が乱れる。クラウドプロバイダーが提供するAI推論APIの価格が変動しやすい理由を理解する上でも、このような構造は参考になる。 筆者の見解 NVIDIAの一強が続くAIチップ市場において、Cerebrasのような異なるアーキテクチャのプレーヤーが上場し、実際に数百億円規模の売上を上げていること自体は健全な競争の証だと思う。 ただ、今回の株価急落を「投資家の誤解」という話で片付けられるほど単純ではないとも感じる。リースバックによる移行コストの説明は合理的だが、その構造を上場前・決算前に丁寧に伝え切れなかったIRのコミュニケーション問題も否定できない。技術力とIR力は別物だ。 AIエージェントが自律的にループで動き続ける時代には、推論コストと推論速度の最適化を担うチップの多様性は不可欠になる。Cerebrasにはその役割を果たせるポテンシャルがある。今後の四半期で粗利率が見通し通り回復すれば、今回の急落は杞憂で終わる。逆に計画通りに進まなければ、より深刻な信頼問題に発展しうる。注視したい企業の一つだ。 出典: この記事は Cerebras stock plunges after earnings as CEO says margin outlook was misunderstood の内容をもとに、筆者の見解を加えて独自に執筆したものです。

2026年8月にも、米ニューメキシコ州のSceye（スカイ）社が開発した全長約60メートルの太陽光駆動飛行船が日本の沿岸上空約18キロメートルの成層圏に展開し、SoftBankの5Gネットワークを補完する通信テストを実施する。端末への直接データ送信も含まれるこのテストは、HAPS（高高度プラットフォームシステム）技術の実用化に向けた重要な節目となる。 HAPSとは——地上基地局でも衛星でもない第3の選択肢 通信インフラには大きく分けて、地上の基地局と宇宙の衛星という2つのアプローチがある。HAPSはその中間、高度約18〜20キロメートルの成層圏に「準静止」する飛行体を使った第3の選択肢だ。 成層圏は気象の影響をほぼ受けず、風も比較的安定している。低軌道衛星（LEO）は最低軌道でも地表から約200キロメートル離れているが、HAPSはその10分の1以下の距離にある。信号の遅延が小さく送信に必要な電力も少ない。SceyeのCEO、ミッケル・フェスタガール・フランセン氏は「宇宙のような環境を、宇宙に行くコストなしで、軌道にいる複雑さなしで提供できる」と表現する。 Sceye飛行船の技術的なポイント Sceye機はヘリウムで浮力を得る飛行船型で、外皮には軽量かつ反射性の高い特殊ファブリックを採用。太陽光パネルで昼間に発電し、夜間用に電力を蓄積することで24時間稼働する電動ファンを駆動し、風に押されても定位置に戻る「ステーションキーピング」を実現する。2024年のテストフライトでこの能力を実証済みで、2026年春には南米ブラジル沖への飛行で12日間の滞空と合計88時間以上の定点停滞を達成した。 Airbus傘下のAaltoなど複数の企業もHAPS開発を進めており、災害時の通信確保や地表監視など多目的な活用が構想されている。 SoftBankとの日本テスト——何を検証するのか 今回のテストでは、Sceye機が日本の沿岸上空に展開し、専用アンテナでSoftBankの5Gを補完する。注目すべきは「既存デバイスへの直接データ送信」が含まれる点だ。専用の受信端末を必要とせず、手持ちのスマートフォンへの送信が実現すれば、展開コストが大きく下がる可能性がある。将来的には衛星事業者と連携して、基地局整備が難しい離島・山間部・洋上エリアをカバーする役割も期待されている。 実務への影響——インフラ担当者が今から意識すべきこと 災害対策BCP: 地震・台風で地上インフラが壊滅してもHAPSが成層圏に残れば通信を維持できる。自治体・企業のBCP計画に「成層圏通信」を選択肢として加える議論が現実味を帯びてくる。 農業・物流・海洋分野: 離島や沿岸の広域IoTセンサー、船舶通信、農業用ドローンの制御など、これまで衛星しか選択肢のなかった用途でコスト低減が期待できる。 都市部の容量補完: 大規模イベントや災害時の高密度エリアで一時的なキャパシティ増強に使える可能性もある。 ただし、現時点はテスト段階だ。商用展開に向けたコスト構造・航空規制・運用オペレーションには未解決の課題が多い。中長期のインフラロードマップに「選択肢として存在する」と意識する段階であり、今すぐ発注できる技術ではない。 筆者の見解 地上基地局・低軌道衛星・HAPSと、通信インフラのレイヤーが増えていくのは、全体最適を考えると理にかなった方向性だと思う。どれか一つで全てを解決しようとするのではなく、用途・地域・コストに合わせてレイヤーを使い分ける設計が、結果的に堅牢で経済合理性の高いシステムを生む。 日本は地震・台風と向き合い続ける国であり、基幹通信が止まるリスクは常に存在する。成層圏に常駐できる通信プラットフォームは、レジリエンスという観点で非常に魅力的な選択肢になりうる。特にSoftBankのような大手キャリアがテストパートナーになっているという事実は、単なる研究段階を超えて商用化の道筋を探り始めているサインとして受け取るべきだろう。 今回のテストが成功すれば、国内での実証例として業界全体の議論を加速させるはずだ。「空からの通信」が絵空事ではなくなりつつある現実を、インフラ関係者は今から頭に入れておいてほしい。 出典: この記事は This flying solar-powered platform could deliver better internet from the air の内容をもとに、筆者の見解を加えて独自に執筆したものです。

NVIDIAは2026年6月、ロボティクス・自動運転・産業用デジタルツインを対象とした「Physical AI」向けの大規模なオープンソースAIエージェントツール・スキル集を公開した。Foxconn、Siemens、TSMCなど世界大手の製造業が相次いで採用を表明しており、製造現場のAIエージェント化が一気に加速する兆しを見せている。 Physical AIエージェントスキル集とは 今回公開されたツール群の最大の特徴は、複雑な物理AIワークフローをAIエージェントが実行可能なタスク単位へ自動分解・実行できる点にある。 対応フレームワークは以下の通りだ： NVIDIA Omniverse — 3D物理シミュレーション・デジタルツイン環境 Cosmos — 物理世界の動作を理解・予測するワールドモデル Metropolis — エッジAI・インテリジェントビデオ解析プラットフォーム これらのフレームワークをまたぐワークフローを、AIエージェントが自律的に組み立て・実行・検証できるようにするのが今回のスキル集のコア価値だ。同時に発表されたBioNeMo Agent Toolkitは、創薬・材料科学など科学的発見分野への展開も示唆しており、製造業にとどまらない広がりがある。 なぜ「エージェント化」が製造業に刺さるのか 従来の工場自動化は「人間がシーケンスを設計→機械が繰り返す」モデルだった。これを「エージェントが目標を受け取り、ステップを自律的に判断・実行・検証する」モデルに変換することで、設計工数の大幅削減と異常対応の自律化が期待できる。 特に注目すべきはCosmosのワールドモデルとの統合だ。デジタルツイン上でエージェントが試行錯誤しながら学習し、そのまま実機へ展開するサイクルが短縮される。「工場を止めずに新しい動作パターンを安全に検証する」というシナリオが現実的になってくる。 日本の製造業・エンジニアへの実務的影響 Foxconn・Siemens・TSMCは日本企業との取引・連携が極めて深い。これらの大手がNVIDIAのPhysical AIエコシステムに本格参入することで、サプライチェーンを通じたプラットフォーム統合圧力は、いずれ日本の製造業にも確実に届く。 明日から動ける実務ポイントを整理する： デジタルツインから小さく始める — Omniverseでシミュレーション環境を構築し、エージェントによる自動化をリスクなく検証する入口として活用する 既存制御系との段階的統合 — ROSやPLC系を使っている現場では、MetropolisのエッジAI解析と組み合わせることで既存資産を活かしながらエージェント化できる オープンソース活用でベンダーロック回避 — 今回の公開はOSS形式。社内でカスタマイズしてNVIDIA依存を最小化しながら採用できる点は評価できる 筆者の見解 今回のNVIDIAの動きで最も注目したいのは、「AIエージェントが自律的にループで動く」設計を物理世界に持ち込んでいる点だ。 ソフトウェアの世界ではすでに、エージェントが自分で判断・実行・検証を繰り返す「ハーネスループ」の概念が急速に定着しつつある。今回のPhysical AIスキル集は、このパラダイムを工場・ロボット・自動運転にまで拡張しようという試みであり、その方向性自体は正しいと思っている。 「目標を与えればあとはエージェントが自律的にやりきる」設計こそが本質的な価値を生む。確認・承認を人間が都度求められる副操縦士型では、結局人間のボトルネックが残る。Physical AIが本来の力を発揮するには、実行ループを人間の外に置くアーキテクチャが大前提だ。 Foxconn・Siemens・TSMCという世界的製造大手が採用を表明することで、このアーキテクチャが産業標準として定着する可能性は十分ある。日本の製造業が「様子見」を続けていられる時間は少ない。オープンソースで公開された今こそ、自社の生産プロセスのどこをエージェント化できるか棚卸しするタイミングだと感じている。 出典: この記事は NVIDIA Releases Major Collection of Open Source Agent Tools and Skills for Physical AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

カナダの終身在職権（テニュア）教授、Abe Oudshoorn氏が「AIはすでに学術界を殺した」と題した論考を公開し、ClaudeやConsensusなどのAIツールを組み合わせれば1日1本のペースで掲載可能な研究論文を量産できる現実を具体的に示した。学術界の「量ベース」評価体系が根本から崩壊しつつあると、その内側にいる「勝者」が告発した点で大きな注目を集めている。 学術界の崩壊は2つの層で同時進行している Oudshoorn氏はテニュア教授・研究椅子・国際学術誌の編集長と、「学術界のゲームに勝ちきった」側の人物だ。その立場から「ゲームがもう成立しない」と宣言する重みは小さくない。 問題は2つの層で同時に起きている。 第一の層：学生課題の崩壊 学生が2つの有料AIアカウント（例：ClaudeとChatGPT）を持ち、一方に草稿を書かせ、もう一方に批評・改善させ、参考文献の誤りまで二重チェックするループを回せば、出来上がる文章は「不自然さゼロ・論理構造完璧・AI検出ツールも通過」という代物になる。 皮肉なのは、このやり方が「ズル」ではなく「合理的選択」になりつつある点だ。AIを使わず人間の文章を提出した学生は純粋に不利になり、粗雑なAI活用をして捕まった学生はゼロ点、洗練されたAI活用をした学生（＝より多くのAIツールに課金できた学生）が最高得点を得る。成績評価システムが実質的に「AIリテラシーと課金力の測定ツール」に変質してしまっている。 第二の層：研究論文の量産 Oudshoorn氏が「個人的に最も衝撃を受けた」と述べるのが研究面だ。ClaudeとConsensus（AI支援文献検索ツール）のProサブスクリプションを組み合わせれば、レビュー論文・メソドロジー論文・理論合成論文などを「ほぼ1日1本ペース」で生産できると指摘する。 粗いAI生成原稿はレビュアーに見抜かれる。しかし洗練されたプロンプト設計と多段階のAIレビューループを組めば、品質は査読通過ラインを超える。量を打ち続ければ相当数が採録される計算になる。 従来の学術業績評価は「どれだけ多くの論文を書いたか」という量ベースで動いてきた。h-indexも被引用数も、その延長線上にある。その前提が崩れれば、既存の評価指標はすべて意味をなさなくなる。 実務への影響——企業・組織の評価設計にも同じ構造がある 「自分たちには関係ない」と思ったエンジニアやIT管理者がいるとすれば、少し立ち止まって考えてほしい。「量」で測っていた指標はすべて同じリスクを抱えている。 GitHubのコミット数・PR数 ドキュメントの更新ページ数 コードレビューのコメント量 週次レポートの字数・件数 AIが「量の無限生産」を可能にした今、量ベースKPIは「AI活用リテラシーの測定ツール」にすり替わる。これは必ずしも悪い話だけではないが、「成果の質」「判断の精度」「実際のビジネスインパクト」といった本来重要な指標に、組織が真剣に向き合うことを迫られている。 直近の調査では「開発者の97%がAIコーディングツールを使っているが、ガバナンスが整っている組織はわずか33%」という数字が出ている。評価基準の見直しは急務だ。 明日から着手できるアクション: 既存のKPIを「量」から「質・インパクト」へ棚卸しする AIを「使うかどうか」ではなく「どう使えば効果的か」を組織として定義する AIアシストのアウトプットに対して「人間が何を判断・保証したか」を記録する仕組みを整備する 筆者の見解 Oudshoorn氏の告発は学術界に限った話ではなく、「量で人を評価してきたあらゆる組織」への警告として読める。 AIが量の壁をなくした今、真に問われるのは「何を、なぜ、誰のために生み出すか」という問いに正面から向き合えるかどうかだ。学術界でいえば「実際に社会課題に向き合い、知を生み出す」という原点回帰が否応なく迫られている。 日本のIT現場でも同じ構図が急速に広がっている。AIを使った量産が可能になったからこそ、評価される側も評価する側も「何が本当の価値なのか」を言語化しなければならない。この変化に気づいていない組織は、知らないうちに「AIにとって都合のいい評価システム」を運用し続けることになる。 変化の速さには正直驚く。しかしこれは「AIが怖い」という話ではなく、「評価設計を本気でやらなければならない」という当たり前の問いが、もう先送りできなくなっただけとも言える。AIが使える今こそ、本当に重要なことに集中できる仕組みを作る絶好のタイミングではないだろうか。 出典: この記事は AI has already killed academia as we know it? の内容をもとに、筆者の見解を加えて独自に執筆したものです。

コロラド州が2026年6月30日、米国初の包括的な州レベルAI規制「コロラド州AI法（Colorado AI Act）」を施行する。AI開発者・デプロイヤーに対してアルゴリズム差別の回避、リスク管理ポリシーの策定、影響評価（Impact Assessment）の実施を法的に義務付けるもので、施行直前となった今も多くの企業が急ピッチで対応を迫られている。 コロラド州AI法が課す3つの義務 コロラド州AI法が対象とするのは、住宅・雇用・医療・金融など「高リスク領域」でAIを活用する開発者とデプロイヤーだ。具体的には次の3要件が課される。 1. アルゴリズム差別の回避 人種・性別・年齢・宗教などを根拠とした差別的な結果を生まないよう、設計・運用レベルでプロセスを整備する義務。意図せぬバイアスも対象となるため、モデル選定から出力の評価基準まで幅広く見直しが求められる。 2. リスク管理ポリシーの策定と文書化 高リスクAIシステムに対する体系的なリスク評価・管理の仕組みを構築し、書面で記録する義務。「動いているから問題なし」では通らず、定期的な評価サイクルの組み込みが必要になる。 3. 影響評価（Impact Assessment）の実施 消費者の重大な決定（採用・融資・医療判断など）に関わるAIシステムについて、事前に潜在的な影響を評価・記録する義務。外部監査や開示を求める条項も含まれる。 AIエージェントのガバナンスが「緊急事態」に コロラド州AI法の施行と時を同じくして、企業のAIエージェント運用に深刻な問題が噴出している。Gartner・TELUS Digital・Sinchの調査によれば、本番環境に展開されたAIエージェントが高い割合でロールバック（撤回）されており、その主因はPII（個人識別情報）の漏洩とハルシネーション（幻覚）だ。 この状況を受け、TrendAI・MIT Sloan・Mayer Brown・NiCE・Attentiveなど複数の機関が相次いでガバナンスフレームワークを公開した。これらが共通して下す診断は明快だ。 「企業はAIエージェントをソフトウェア展開の問題として扱っているが、本質は制御アーキテクチャの問題である」 TrendAIが提唱する「最小エージェンシー原則（Least-Agency Principle）」は、ソフトウェアセキュリティの「最小権限の原則」に対応するAIエージェント版として注目されている。推奨される具体策は次の3点だ。 エージェントごとの一意アイデンティティ（Agent Identity）の付与 意思決定の監査トレイル（Audit Trail）——推論過程も含めた記録 権限スコープと意思決定予算（Decision Budget）の明示的な設定 OWASPも「State of Agentic AI Security and Governance 2.0」を公開し、ツールポイズニングやマルチエージェントの連鎖障害に対する制御を標準化しようとしている。これらの仕様が企業の調達要件や保険条件に組み込まれていけば、事実上の業界標準となる可能性が高い。 AIモデルの輸出規制——一夜でアクセスが消えるリスク 今週もう一つ見逃せないのがAIモデルへの輸出規制だ。2026年6月12日、米国政府はAnthropicのFable 5・Mythos 5を対象とした輸出規制を発動し、特定ユーザーへのアクセスが突如停止された。 このインシデントは「ベンダー集中リスク（Vendor Concentration Risk）」の現実を生々しく示した。特定モデルに業務フローを丸ごと依存させると、ルール変更一つで業務が止まる。リスク管理の観点から、代替モデルの選定とフォールバック基準の文書化が急務となっている。 日本のIT組織にとっての意味 コロラド州AI法は米国の話だが、日本企業にとって他人事ではない。 グローバル展開企業は米国拠点のシステムで直接対応が必要だ。米国でサービスを提供するSaaSや、米国籍のユーザーを持つプラットフォームは対象となりうる。 国内企業も、EU AI Actが段階的に施行中であり、日本の規制環境も数年内に類似した方向へ収斂していく公算が大きい。「欧米の話」と見ている間に後れを取る。 AIエージェントの管理体制については、今が整備のタイミングだ。開発者の97%がAIコーディングツールを活用する時代に、ガバナンスを整備できている組織はわずか33%という現実がある。エージェントを「動いていればよい」で放置している組織は、この数字に含まれている可能性が高い。 筆者の見解 「エージェントAIは制御アーキテクチャ問題だ」という診断は、本質を突いていると思う。エージェントが自律的に判断・実行・検証をループで繰り返す設計においては、「とりあえず動いた」では絶対に済まない。エージェントIDを持たせ、意思決定の予算を決め、監査トレイルを残す——これはソフトウェアエンジニアリングの基本と変わらない話で、AIだから特別に難しいわけでも、特別に免除されるわけでもない。 「禁止ではなく安全に使える仕組みを」という考えは、AIガバナンスにもそのまま当てはまる。制御の仕組みが整っていないからエージェントを止める、ではなく、適切なアーキテクチャで安全に動かし続ける方向に設計を向けていくことが、IT組織に今求められている判断だ。 コロラド州AI法やOWASPのフレームワークを「対応義務のない組織には無関係」と見過ごすのはもったいない。これらは実装可能なチェックリストとして十分使えるリソースだ。規制対応でなくとも、エージェントAIのガバナンス設計の参考として積極的に活用していくことをお勧めする。AIエージェントを本番で動かすすべての組織にとって、今は「仕組みを作る側に回るか、問題が起きてから慌てるか」の分岐点にある。 出典: この記事は AI Governance Weekly - June 19, 2026: Colorado AI Act Deadline Approaching の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Black Duck Securityの最新調査が、開発者の97%がAIコーディングツールを業務で利用しているにもかかわらず、ガバナンスフレームワークを整備している組織はわずか約3分の1（33%）に過ぎないという現実を数字で裏付けた。技術リーダーの93%は本番環境へのAI生成コード投入に懸念を持ちながら、組織的な対策が追いついていない矛盾が浮き彫りになっている。 AI活用は「当たり前」になったが、組織の準備は置き去り Black Duck Security（旧Synopsys Software Integrity Group）が実施したソフトウェアリスク調査によると、開発者の97%が何らかのAIコーディング支援ツールを日常的に使用していることが明らかになった。GitHub Copilot、Amazon Q Developer、Claude Code、TabNineといったツールが開発現場に急速に浸透し、AIなしのコーディングワークフローはもはや非現実的という状況だ。 しかし、その普及スピードに組織のガバナンスが追いついていない。利用ポリシー、品質基準、セキュリティレビュー規程といったガバナンスフレームワークを整備しているのは全体の約33%。残りの約67%の組織では、事実上「ルールなし」のままAI生成コードが本番環境に流れ込んでいる状態だ。 技術リーダーの93%が「本番品質」に懸念を持ちながら動けない より深刻なのは、技術リーダーの93%がAI生成コードのリスクを認識しながらも対策が追いついていない、という矛盾だ。懸念として挙げられている主要リスクは以下のとおりだ。 セキュリティ脆弱性の混入: AIは既知のパターンを模倣するが、コンテキストを理解せず危険な実装を出力するケースがある ライセンス汚染リスク: オープンソースを学習したモデルが著作権的にグレーなコードを生成する可能性 品質のバラつき: レビューなしで本番マージされるAI生成コードのテストカバレッジや例外処理が不十分なケース 説明責任の曖昧化: 「誰が書いたコードか」の追跡が困難になることによるインシデント対応の遅延 日本のIT現場における固有のリスク 日本企業でも状況は同様、あるいはより深刻な側面がある。 コンプライアンス要件の複雑さ: 金融・医療・インフラ系システムでは、コードの品質保証プロセスが法令や業界ガイドラインで定められているケースが多い。AI生成コードがそのプロセスをバイパスしていないかの確認が急務だ。 多重下請け構造の問題: SIer→1次請け→2次請けという構造では、どの段階でAIツールを使用しているかの把握が困難になる。発注元がガバナンスを定義しても末端まで届かないリスクは現実的だ。 明日から使えるガバナンスの第一歩: まず「AIツール利用の届出制度」だけでも導入する（把握→管理の順番） CI/CDパイプラインにSAST（静的解析）を組み込み、AI生成コードを自動スキャン コードレビュー時に「このコードはAI生成か」を確認する項目を追加 ライセンス管理ツール（Black Duck、FOSSA等）でOSSコンポーネントを追跡 筆者の見解 この調査が示す97%という普及率は、AIコーディングツールがもはや一部のエンジニアの先進的な試みではなく、業界標準のインフラになっていることを意味する。この現実を正面から受け止めた上で、組織として何をすべきかを考える必要がある。 最も避けるべき判断は「懸念があるからAIコーディングツールを制限・禁止する」という方向性だ。禁止アプローチは必ず失敗する。開発者はすでにAIなしでは競合と戦えない状況にあり、制限すれば自社の競争力を削るだけだ。ガバナンスとは「使えなくする仕組み」ではなく「安全に使い続けられる仕組み」のことだ。 93%の技術リーダーが懸念を持ちながら対策を打てていないのは、怠慢ではなくスピードの問題だ。AIの普及速度が組織の学習・整備能力を大幅に上回った結果であり、今からでも遅くない。まず現状把握から始め、ポリシー整備→自動化という順序で積み重ねていけばいい。 そして、視野をもう少し先に広げると、単発のコード補完を超えてAIエージェントがリポジトリ全体を自律的に改変し続ける時代はすでに目前だ。そのフェーズに入ったとき、ガバナンスなしのコードベースがどうなるかは想像に難くない。「ガバナンス整備は急がなくてもいい課題」という認識は、早急に改める必要がある。 出典: この記事は 97% of developers use AI coding tools but only 1 in 3 organizations have governance frameworks — Black Duck Security の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Google DeepMindは、インディー映画スタジオA24に7,500万ドル（約110億円）を投資し、映画制作向けAIツールを共同開発するパートナーシップを締結したと発表した。同社CEOのデミス・ハサビス氏は「アーティストを支援するツールを作る最善の方法は、彼らと直接協力することだ」と述べており、A24からのフィードバックを受けながらツール開発を進める「業界初の取り組み」として位置づけている。 A24はどんなスタジオか A24は、アカデミー賞を席巻した『エブリシング・エブリウェア・オール・アット・ワンス』や、最新話題作『Backrooms』などで知られるインディー映画スタジオだ。ティモシー・シャラメやアン・ハサウェイといった大物俳優とのプロジェクトでも存在感を示しており、ハリウッドにおける「芸術性と興行成績の両立」を体現するスタジオとして高く評価されている。 このA24を提携先に選んだことは、Google DeepMindのメッセージとして明確だ——「AI映像生成は商業コンテンツの量産ではなく、作家性ある表現を支援するものだ」という宣言に近い。 「アーティスト主導」のAI開発という設計思想 今回の提携で注目すべきは、その構造だ。Google DeepMindがA24から「フィードバックと指導（feedback and guidance）」を受ける形でツールを開発するという設計は、技術企業がプロダクトを作ってから現場に押し付けるアプローチとは逆向きになっている。 映画監督や制作スタッフなど実際の創作者が設計段階から関与することで、「技術ありきのAI」ではなく「創造の道具としてのAI」を目指す意図が読み取れる。ハサビス氏が語る「authentic, meaningful storytelling（真摯で意味のあるストーリーテリング）」という言葉は、これまでのAI映像生成に向けられてきた「本物らしさがない」「表現が空虚だ」という批判への直接的な回答でもある。 ハリウッドにおけるAI導入の潮流 A24とGoogle DeepMindの提携は、ハリウッドにおけるAI活用の大きな流れの一部だ。 Netflix: 2026年初頭、ベン・アフレック率いる映画制作向けAIツール会社InterPositiveを買収 Amazon MGM Studios: テレビ・映画制作ツールに特化したAIユニットを設立 一方で、AI活用への反発も根強い。俳優組合（SAG-AFTRA）や脚本家組合（WGA）は、AIによる俳優の映像・声の無断使用や脚本の自動生成を主要争点として大規模ストライキを行った経緯がある。A24は比較的アーティスト寄りのスタジオとして知られているだけに、今回の提携が組合側とどう折り合いをつけるかは引き続き注目点だ。 日本の映像制作・エンタメ業界への示唆 日本でも映像制作にAIを活用する動きは始まっており、CM制作やアニメの中間素材生成、字幕翻訳の自動化などは実用段階に入りつつある。Google DeepMindとA24の提携から生まれるツールが実用化されれば、以下のような応用が想定される。 プリプロダクション段階: 絵コンテや世界観設定のビジュアライゼーション支援 ポストプロダクション: VFX処理の自動化・効率化 配給・マーケティング: 地域ごとのポスターやトレーラー素材の生成 ただし、日本では映像著作権の扱いや権利処理の慣習が欧米と異なる部分も多く、ツールの直輸入が難しいケースも出てくるだろう。法制度面での整備と並行した、慎重な導入検討が求められる。 筆者の見解 AIと創造の関係を巡る議論は、「使うべきか否か」という二項対立で語られがちだ。しかし今回の提携が面白いのは、その問いに対して「アーティスト自身が設計に参加する」という形で答えようとしている点にある。 「禁止するか、丸投げするか」ではなく、「創作者が主体的に使いこなせる仕組みを作る」というアプローチは、AIツール開発のあるべき姿に近い考え方だ。AI活用で本当に重要なのは、技術そのものの性能よりも「誰が、どのような文脈で、何のために使うか」を設計の起点に置くことだからだ。 映画は数千人規模のクリエイターが関わる巨大な共同作業だ。AIがその連携を加速させ、表現の幅を広げる方向で機能するなら、歓迎すべき変化といえる。一方、コスト削減を目的に人間の仕事を機械的に置き換えるだけの使われ方になれば、技術への反発はさらに強まるだろう。 今後はA24の実際の作品の中で、アーティストたちがこのツールをどう評価するか——その声が、AI映像制作ツールの設計に関する最も信頼できるフィードバックになると思っている。 出典: この記事は Google DeepMind bets $75M on AI’s future in Hollywood with A24 deal の内容をもとに、筆者の見解を加えて独自に執筆したものです。

オープンソースAIスタートアップのReflection AIは、SpaceXと月額1億5,000万ドル（約225億円）の計算資源契約を2026年7月1日から締結した。AnthropicとGoogleに続く形で、米テネシー州メンフィス近郊のColossus 2データセンターにてNvidiaの最新GB300チップを確保し、オープンウェイトAIモデルの大規模開発を加速させる。 Reflection AIとは——元Google DeepMind研究者が立ち上げたオープンソースの挑戦者 Reflection AIは2024年、元Google DeepMindの研究者2名が共同創業したスタートアップだ。AnthropicやOpenAIのような「クローズドフロンティアラボ」への対抗軸として、オープンウェイト（open-weight）戦略を核に据えている。 オープンウェイトモデルとは、学習済みパラメータを公開するAIモデルのこと。MetaのLlamaシリーズがその代表例だ。クローズドモデルのAPIを介してのみ利用するアプローチとは異なり、モデルそのものを入手してオンプレミスやプライベートクラウドで稼働させられるため、データ主権やコスト管理の観点から企業・政府に支持されている。 契約の詳細——最大63億ドル規模の3年間合意 今回の契約は同社にとって初の大型計算資源契約となる。主な条件は以下のとおりだ。 契約期間: 2026年7月1日〜2029年 月額: 1億5,000万ドル（約225億円） 総額: 最大63億ドル（約9,450億円） 施設: SpaceXのColossus 2データセンター（テネシー州メンフィス近郊） ハードウェア: NvidiaのGB300 AIチップおよび関連機材 解約条件: 最初の3ヵ月経過後、90日前通知でどちらからでも解除可能 同規模の契約を比較すると、Anthropicは月12億5,000万ドル、Googleは月9億2,000万ドルでSpaceXと契約している。Reflection AIはこれらより規模が小さいものの、「オープンソース陣営として最大規模のAIインフラ投資」と自社を位置づけている。 なぜColossus 2なのか——xAI統合後のSpaceXがインフラハブへ Colossus 2データセンターは、もともとイーロン・マスク氏が設立したAI企業xAIが自社AI開発のために建設したものだ。しかし内部プロジェクトの進行が計画通りに進まなかったこともあり、xAIはSpaceXに統合された。SpaceXはこの膨大なGPUリソースを第三者に貸し出すビジネスモデルに転換し、世界トップクラスのAIラボへ提供している。 GPUリソースを持つ企業が「クラウドプロバイダー」化するという動きは、かつてのAWSの誕生を彷彿とさせる。余剰インフラの収益化が新たなビジネスモデルとして定着しつつある。 オープンウェイトAIへの追い風——政府の政策変化が後押し Reflection AIが今回の契約発表で強調したのが「オープンソースの重要性」だ。クローズドモデルへの依存リスクを各国政府・企業が意識するようになったことが、同社の戦略への共感を生んでいるという。 「特定の企業のクローズドモデルだけに依存するリスクとコストを、より多くの国家・企業が認識するようになっている」——同社はこう声明で述べ、オープン戦略の優位性を訴えた。 実務への影響——日本のエンジニア・IT管理者が今押さえるべきポイント 1. ベンダーロックインリスクの再評価 「特定ベンダーのAPIだけに依存する」リスクは日本企業でも普遍的だ。AIガバナンスの観点から、社内インフラに展開できるオープンウェイトモデルの選択肢を一度棚卸しすることを推奨する。 2. GB300チップ世代の計算力スケールを把握する NvidiaのGB300（Blackwell Ultra世代）は、現行のH100/H200と比べてメモリ帯域・推論スループットが大幅に向上している。この規模のチップを各社が確保していることは、次世代フロンティアモデルの学習・推論コストが今後さらに下がる可能性を示唆している。API料金の低下という形で、数年以内に企業の実務にも恩恵が及ぶだろう。 3. 機密データを扱う業種はオープンウェイト展開を本格検討する時期 金融・医療・製造など機密データを扱う業種では、クラウドAPIを介さずモデルを社内展開する「オープンウェイト自前運用」が優位になるケースが増えている。Reflection AIのような企業の台頭は、その選択肢の質と量を底上げする。 筆者の見解 「オープンvsクローズド」の議論は単なる思想の対立ではなく、AIインフラの地政学として現実に形になりつつある。Reflection AIのような企業が大規模な計算資源を確保し、オープンウェイトモデルの開発を本格化させることは、AI生態系の多様性という観点から歓迎できる動きだ。特定の少数企業がフロンティアモデルを独占する状況が続けば、価格支配力・サービス停止リスク・政策変更リスクが企業に集中する。その意味で、競争軸が増えることは利用者側に有利だ。 ただし「オープン=安全」「クローズド=危険」という単純図式には注意が必要だ。公開されたモデルパラメータが悪意ある利用者に渡るリスクも現実に存在し、安全管理のコストを誰がどう負担するかという問いに、業界全体がまだ明確な答えを出せていない。 より注目すべきは、SpaceXのColossusが世界トップ級のAIラボが集結するインフラハブになりつつあるという事実だ。GPUリソースの争奪戦はもはや企業間の技術競争であると同時に、国家レベルの産業政策の問題でもある。このトレンドの中で、日本はAIインフラへの投資姿勢をいつまでも「様子見」で済ませることができない局面に来ている。産業界と行政双方の戦略的判断が、今問われている。 出典: この記事は SpaceX inks compute deal with Reflection AI, an open source AI lab の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Claude CodeのExtended Thinkingセッションログに含まれる「思考ブロック（thinking blocks）」が、実際の推論プロセスではなく暗号化された要約に過ぎないことが、エンジニアのPatrick McCanna氏の調査で明らかになった。ローカルに保存されたログには600文字のシグネチャが含まれるだけで、モデルが実際に行った推論テキストは含まれていない。 Extended Thinkingログの実態 Claude Codeはセッションを自動的にディスクに記録し、そのログには「思考ブロック」と呼ばれるセクションが含まれる。多くのユーザーがこれをモデルの実際の推論過程と理解していたが、Anthropicの公式ドキュメントには以下の仕様が記載されている。 推論は暗号化される: Claudeの推論はシグネチャに暗号化されており、復号キーはAnthropicが保有する APIが返すのは要約: ローカルに記録されるのは実際の推論そのものではなく、推論プロセスの「要約（summary）」 フル出力はエンタープライズ限定: 実際の思考プロセスへのアクセスにはエンタープライズ契約が必要 McCanna氏はこの状況を「JPEGをBMPとして保存し直してから編集し、元のJPEGですと提示するようなもの」と表現している。形式は似ているが変換によって情報が失われているという指摘だ。 なお、Ctrl+Oで表示されるExtended Thinking出力も、モデルの思考の要約であり、セッション中にエージェントの動作を実際に駆動した推論そのものではない点も合わせて指摘されている。 ドキュメントの記述が不明瞭 問題をより複雑にしているのが、Anthropicの公式ドキュメントにおける記述のあいまいさだ。「extended thinkingはClaude の完全な思考プロセスの要約を返す（returns a summary of Claude’s full thinking process）」という記述は存在するものの、サラッと読むと実際の推論ログが手元にあると誤解しやすい構成になっている。 McCanna氏は「コーヒーを飲む前に流し読みすると気づかないレベルの間接的な表現」と指摘しており、Hacker Newsでも170件以上のコメントが集まる議論に発展している。 実務への影響：監査・コンプライアンスの観点から 監査証跡として使えるか？ 現時点では使えない、が結論だ。AIエージェントが何らかの判断を下した際に「なぜそう判断したか」の根拠をローカルログから再現することは不可能で、記録できるのは以下に限られる。 入力（プロンプト・コンテキスト） 出力（レスポンス） 実行されたアクション（ファイル操作・コマンドなど） 判断の根拠となった内部推論は手元には残らない。 コンプライアンス要件がある環境での注意点 金融・医療・行政など、意思決定の説明責任（Explainability）が厳しく問われる業種では、この仕様が導入上の制約になりうる。「AIがこの推論でこう判断したから」を証明できないと困る場面では、エンタープライズ契約の検討か、代替手段の設計が必要になる。 現実的な対策 推論トレースが必要なケースでは以下の対応を検討したい。 Anthropicのエンタープライズプランを検討する — フル思考出力にアクセスできる可能性がある 入出力ログを徹底的に記録する — 推論そのものは取れないが、コンテキストの再現性は高められる 高リスクな判断ポイントに人間レビューを組み込む — エージェントを完全自律にしない設計 チームや顧客への説明を正確にする — 「思考ログがある」と言い切らない 筆者の見解 Claude Codeは今も自分が最も信頼して使い倒しているツールだ。その前提を置いた上で、今回の件については率直に書く。 技術的な理由は理解できる。推論を暗号化してAnthropicがキーを保持することには、モデル保護やビジネス上の合理性があるだろう。しかし、ユーザーがローカルに保存されたファイルを「自分のエージェントの推論ログ」と思って作業しているとき、その認識が間違っているとしたら、それはドキュメントが正面から説明すべき事実だ。 「要約を返す」という記述が存在するのに、それが埋もれてしまっているのはもったいない。Anthropicの技術力は本物で、AIエージェントの分野での先進性も疑っていない。だからこそ、仕様の透明性という点でももっと正面から向き合えるはずだ、と感じる。 AIエージェントが業務の意思決定に関与する場面が増えるほど、「エージェントが何を考えてその行動を取ったか」の説明責任は重要になる。今後のアップデートでこの点の透明性がさらに改善されることを期待している。 エンタープライズ導入を検討している場合や監査証跡が必要なユースケースでは、「ローカルのthinkingログ＝完全な推論記録」という前提を見直すことが第一歩だ。 出典: この記事は The text in Claude Code’s “Extended Thinking” output の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

AIを使ってコードを書かずにアプリを作る「バイブコーディング」が急速に普及する中、The Vergeが複数の実被害事例を取り上げ、個人利用から業務利用への「境界線」を踏み越えた瞬間にセキュリティ基準が根本的に変わることを警告している。 「すぐ動いた」が「ずっと安全」ではない プロジェクトマネージャーのBob Starr氏は、米国の税金がどのテック企業に流れているかを可視化するウェブサイト「Boomberg」をバイブコーディングで構築し、すぐに公開した。数ヶ月後に気づいたのは、深刻なSQLインジェクション脆弱性だった。攻撃者に悪用されれば、データの読み取りや改ざんが可能な状態だったという。 他にも、PocketOSの創業者Jer Crane氏のケースでは、AIコーディングエージェントが本番データベースを丸ごと消去するという事故が発生。あるシリアル起業家はデモ用に作ったWebアプリがハッキングされ、「今はZoom越しにローカルマシンからデモする。完全にレガシーな方法に戻った」と苦笑している。 問題の本質は「個人用→業務用」のドリフト AIサイバーセキュリティ企業SentinelOneのGabriel Bernadett-Shapiro氏は、「バイブコーディングそのものが悪いわけではない。素人がソフトウェアを作れるようになったのは、むしろ良いことだ」と評価した上で、核心的なリスクを指摘する。 「個人の頭痛記録や食事管理、配達追跡アプリなら問題ない。しかし顧客ログ、医療データ、財務記録、社内文書を扱う瞬間、基準は変わる。午後一番で作ったアプリであっても、他人の個人データに触れる時点で別次元の責任が生じる」 セキュリティスタートアップCorridorのCEO、Jack Cable氏も「プロトタイプや個人フィットネストラッカーには向いているが、公開インターネット上で他人のデータを扱う場合は、脅威モデルを真剣に考える必要がある」と同調する。 実際、決済スタートアップPrivyのCOO、Max Segall氏は子どもと一緒に走った距離に応じてEthereumを付与するアプリ「EzRun」をバイブコーディングで構築。リリース前に同僚が発見したのは、任意のユーザーアカウントを乗っ取れるという致命的な欠陥だった。早期発見が間に合ったのは、セキュリティ知識を持つエンジニアが周囲にいたからに過ぎない。 バイブコーディングのセキュリティチェックリスト（実務向け） AIが生成したコードは「動く」が「安全」とは限らない。特に以下の点は人間が必ず確認する必要がある。 公開前に確認すべき3つの問い 誰のデータを扱うか？ — 自分だけか、他人のデータも含まれるか インターネットに公開するか？ — ローカル専用か、外部アクセス可能か 入力値はどこから来るか？ — ユーザー入力や外部APIを直接SQLやコマンドに渡していないか AIが生成したコードで特に脆弱になりやすい箇所 SQLクエリへの直接の文字列結合（SQLインジェクション） 認証チェックの漏れ（任意ユーザーなりすまし） 環境変数ではなくコードに直書きされたAPIキー エラーメッセージによるシステム情報の漏洩 AIに「このコードをセキュリティの観点でレビューして」と依頼するだけでも多くのリスクを洗い出せる。作ったAIに確認させるというアプローチは現実的で有効だ。 実務への影響 日本の企業でも、部署単位でのシャドーIT的なバイブコーディングは急増している。「業務効率化ツールをAIで作った」と部下から報告を受けたとき、IT管理者が確認すべきは技術的な動作だけでなく、「そのアプリはどのデータにアクセスしているか」「誰がアクセスできるか」「認証はどこで管理されているか」の3点だ。 バイブコーディングで生まれたアプリを正式な業務ツールとして採用する場合、最低限のセキュリティレビューを義務付けるプロセスを社内に設けることを強く推奨する。 筆者の見解 バイブコーディングの普及自体は歓迎すべき変化だと思っている。ノーコード・ローコードが「作れる人」を広げてきたように、AIコーディングは「自分のツールを自分で作る」民主化の次の段階だ。問題は技術ではなく、使う側のリテラシーにある。 今回の記事が指摘する「個人用から業務用へのドリフト」は、実はクラウドサービスのシャドーIT問題と構造的に同じだ。使いやすいから広がる、広がるから重要なデータが乗る、気づいたときには管理外になっている——この流れはずっと繰り返されてきた。 AIが生成するコードは確かに「動く」。しかし「安全に動く」かどうかは、利用者が問いを立てなければAIは保証できない。「セキュリティレビューして」と一言添えるだけで大きく変わる。ツールの問題ではなく、使い方の問題だ。 自律的なAIエージェントが普及し、コードが大量に自動生成される時代に、セキュリティは「後から直す」ものではなく「プロセスに組み込む」ものになっていく。本番データベースを消去したケースのように、エージェントに強い権限を与えながらセーフガードを設けないのは、ハサミを子どもに渡すのと変わらない。自律実行の力と安全設計はセットで考えるべきだ。 出典: この記事は Read this before you vibe-code another app の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIチップメーカーのGroqは2026年6月、Nvidiaによる技術ライセンス契約とCEO引き抜きという「擬似買収（not-acqui-hire）」から約6ヶ月を経て、新たに6億5000万ドル（約950億円）の資金調達を完了し、ネオクラウド事業への本格ピボットを発表した。 「not-acqui-hire」とは何だったのか 2025年12月、NvidiaはGroqと非独占ライセンス契約を締結し、Groqが独自開発したLPU（Language Processing Unit）の技術IPを取得した。それだけでなく、Groqの創業者でCEOだったJonathan Ross（元Google、TPU開発を主導した人物）、PresidentのSunny Madraをはじめとした中核人材を大規模に引き抜いた。 「会社を買収せずに、技術と人材だけを手に入れる」手法がnot-acqui-hireだ。Groqの株主は手厚い補償を受けたとされ、表向きはWin-Winに見えるが、会社としてはコアリソースを失った状態からの再出発を余儀なくされる。 LPUの喪失とネオクラウドへのピボット Groqが開発したLPUは、LLM推論（インファレンス）処理に特化したカスタムチップ。GPUより高速かつ省エネで推論を実行できるとして業界から注目されていた。しかし今やそのIPはNvidiaが保有しており、Nvidiaは2026年3月のGTCイベントで「Nvidia Groq 3 LPX」推論ハードウェアシステムを発表している。 LPUビジネスの主導権を失ったGroqが差別化の軸として選んだのがネオクラウド事業だ。既存の大手クラウド（AWS・Azure・GCP）と異なる、AI推論に特化したクラウドサービスを提供するモデルである。2024年に買収したAIデータ分析企業「Definitive Intelligence」の事業が母体となり、現在は北米・欧州・中東・アジア太平洋の13データセンターに拡大。500万人以上の開発者と数千社のAI企業が利用し、毎週数兆トークンを処理するまでに成長している。 新体制のエグゼクティブ陣 GroqはCOO・CTO・CPOを一新した。 Alan Rice（COO）: 元xAI・Meta。米海軍出身のエグゼクティブ Sinclair Schuller（CTO）: エンタープライズクラウドソフト企業Apprendaの創業者 Rakesh Malhotra（CPO）: Microsoft クラウド製品を約10年担当後、SchullerとNuvalenceを共同創業（2024年にEYが買収） 現CEOはGroq共同創業者のDoug Wightman（Nvidiaへの移籍を選ばずGroqに残留した人物）が務める。 実務への影響：日本のエンジニア・IT管理者への示唆 推論特化クラウドという選択肢を知っておく GroqCloudのAPIはAI推論を高速・低レイテンシで提供するサービスとして、国内の一部開発者やスタートアップに利用されている。今回の資金調達によりAPACリージョンの拡充も期待できる。特に大量推論が必要なバッチ処理やエージェント系ワークロードを組む際の選択肢として把握しておきたい。 「推論コスト」が経営課題になる時代 LLMの利用が業務に本格的に組み込まれると、推論コストは無視できない固定費になる。汎用クラウド一択ではなく、GroqのようなAI推論特化型サービスをワークロードに応じて使い分けるアーキテクチャ設計が、今後のシステム設計における重要な論点になる。 not-acqui-hireは今後も増える Scale AIがMetaとの同様の取引後も$10億ドル収益達成に向けて順調に成長しているという事例も紹介されている。会社を丸ごと買収するよりコストが低く、技術・人材を集中取得できるこのモデルは、AI業界でさらに増える可能性が高い。 筆者の見解 GroqのLPUは登場時から「GPUとは設計思想の違うアプローチだ」と感じていた。推論に特化したアーキテクチャとしての実力は本物で、NvidiaがわざわざIPライセンスを取りに来たこと自体がその証明だ。 鍵はネオクラウド事業がこの先どこまで差別化を維持できるかにある。Nvidiaが「Groq 3 LPX」を市場に出してきた今、Groqの優位性はハードウェアではなく、積み上げてきたソフトウェアスタックと開発者エコシステムに移った。500万開発者というユーザー基盤は、ゼロから作るのは容易ではないアセットだ。 インファレンス市場は現在まさに急拡大中だ。AIエージェントが自律的にループで処理を回し続けるような設計では、「大量の推論をいかに安く速く実行するか」がそのままシステムの経済性に直結する。そのニーズに応え続けられれば、Groqがネオクラウドとして独自のポジションを確立するシナリオは十分にある。 not-acqui-hireという手法が成立してしまう今のAI業界の勢いは、改めて凄まじいと感じる。技術と人材だけを切り出して取引できてしまう構造は、今後のスタートアップ戦略にも大きな示唆を持つだろう。 出典: この記事は AI chipmaker Groq confirms $650M raise, re-staffs after Nvidia’s $20B not-acqui-hire deal の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Cloudflareは2026年6月21日、アカウント登録不要でCloudflare Workersを60分間デプロイできる「Temporary Accounts」機能を公開した。npx wrangler deploy --temporary の1コマンドで即座に本番URLが発行されるこの機能は、AIエージェントが自律的にデプロイ・検証ループを回すための環境整備として注目を集めている。 何ができるのか これまでCloudflare Workersにアプリをデプロイするには、アカウント作成→APIキー取得→wrangler設定という一連の手順が必要だった。新機能ではこのプロセスをまるごとスキップできる。 npx wrangler deploy –temporary このコマンドを実行すると、Cloudflareが裏側で一時アカウントを自動生成し、Workersプロジェクトをデプロイする。数秒で外部からアクセス可能な本番URLが発行される。 一時デプロイは60分後に自動削除される。ただし、デプロイ完了時に「クレームURL」も同時に発行される。このURLからCloudflareアカウントへの紐付け（クレーム）を行えば、プロジェクトは永続化し、通常のWorkersとして管理し続けることができる。 「AIエージェント向け」だが、すべての開発者にとって有用 Cloudflareは「AI agents向け」と打ち出しているが、ブログ著者のSimon Willisonが指摘するように、この機能の恩恵はAIエージェントに限らない。 AIエージェントの文脈では確かに威力を発揮する。エージェントがコードを生成しても、「どこかに実際にデプロイして動作確認する」ステップはこれまで厄介なボトルネックだった。アカウント作成やAPIキー管理をエージェントに委ねるのはセキュリティ上の問題があり、人間が事前にセットアップして渡す手間も発生していた。一時アカウント機能はこの摩擦を一気に解消する。 一方、人間のエンジニアにとっても活用場面は多い： プロトタイプの即共有：ローカルで動くものをすぐ他者に確認してもらいたいとき ハンズオン・デモ環境：セミナーや勉強会で一時的な「動く環境」を用意するとき CIパイプラインのプレビュー：PRごとにWorkersを立ち上げてエンドツーエンドテストを走らせるとき Simon Willisonは実際にOpenAI Codex Desktop上でHTTPリダイレクト解決ツールをAIにビルドさせ、一時デプロイが問題なく機能することを確認している。 実務での活用ポイント エージェントの自律ループに組み込む AIエージェントが「コードを書いて→デプロイして→動作確認して→修正する」という自律ループを回す際、Cloudflare Workersはエッジで動作しHTTPエンドポイントとして公開できるため、エージェントが生成したツールをAPIとして即座にテストする用途にフィットする。アカウント管理を人間側に委ねる必要がなくなるため、エージェントの自律性が大きく高まる。 ガバナンスへの配慮も忘れずに 企業で利用する場合、「アカウント不要」という特性はガバナンスの観点から注意が必要だ。誰がどの一時Workersをデプロイしたかを把握しにくくなる可能性があるため、利用ポリシーの整備を検討したい。60分後の自動削除は、放置された環境が永続化するリスクを抑える合理的な設計だが、企業の情報セキュリティポリシーとの整合性は別途確認が必要だ。 筆者の見解 AIエージェントの真の自律性は、コードを生成するだけでなく、実際に動かして結果を検証するところまで完結して初めて実現する。「おそらく動くと思います」で止まるエージェントと、「HTTPステータス200を確認しました」まで完結するエージェントとでは、信頼性と実用性に根本的な差がある。 Cloudflareの一時デプロイ機能は、その「最後の一歩」を支えるインフラだ。アカウントという摩擦を取り除くことで、エージェントが自律的に動ける領域が一つ広がった。地味に見えるが、エージェントが回す自律ループの質を底上げする本質的な改善だと感じる。 また「AIエージェント向け」というラベルに引きずられず、普通の開発者ツールとして今日から使い始める発想も大切にしたい。プロトタイプをすぐ共有できる手軽さは、日本のエンジニアが「まず試す」カルチャーを育てる上でも確実に意味がある。仕組みを整えれば、AI活用の効率は着実に上がっていく。 出典: この記事は Temporary Cloudflare Accounts for AI agents の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GitHubのプロダクトアナリティクス部門が、GitHub Copilotを活用した社内データ分析AIエージェント「Qubot（クボット）」を開発・運用し、その構築過程で得た知見を公式ブログで公開した。非エンジニアを含む全GitHub社員が、SQLを書かずに自然言語でデータへ問い合わせ、リアルタイムに分析結果を得られる社内ツールだ。 Qubotとは何か Qubotは、GitHub Copilotを中核エンジンとして構築された社内向けデータアナリティクスエージェントだ。「先月のリポジトリ新規作成数は？」「GitHub Actionsの利用が増えているカテゴリは？」といった自然言語の問いかけに対し、エージェントが自律的にデータベースへのクエリを生成・実行し、結果を返す。 このようなText-to-SQL型のエージェントを実用化するには、単にLLMをDBに繋いで終わりというわけにはいかない。GitHubチームが公開した知見の核心は、まさにそこにある。 構築上の主な課題と学び スキーマコンテキストの設計 LLMが「どのテーブルに何のデータがあるか」を正確に理解するためのコンテキスト設計が、精度に直結する。テーブル数が多い大規模DBでは全スキーマをプロンプトに詰め込むとトークン上限に引っかかるため、クエリ内容に合わせて関連スキーマだけを動的に提示する仕組みが必要になる。 SQLの検証と自己修正ループ LLMが生成するSQLは常に正確とは限らない。実行エラーをLLMへフィードバックして再試行させるリフレクションループが、実用レベルの精度を実現するうえで不可欠だ。このループの洗練度が、プロトタイプと実運用ツールの差を決める。 データアクセス制御の統合 「誰でも何でも聞けば答える」構成はセキュリティ上のリスクを孕む。既存のデータアクセスポリシーとの統合、読み取り専用クエリの強制、機密データのマスキングといった制御を、エージェントのレイヤーに透過的に組み込む設計が求められる。 日本の現場への影響——今すぐ参考にできること 日本企業の多くで、データ分析はBIツールを使いこなせるか、SQLが書けるエンジニアだけの特権になっている。Qubotのアプローチは、この「データアクセス格差」を解消する具体的なモデルとして参考になる。 実装の出発点として検討できる選択肢： GitHub Copilot Extensionsを使ったチャット拡張で、社内DBへの自然言語問い合わせBotを試験実装できる Azure OpenAI Service + Azure SQL / Synapse Analyticsの組み合わせで、Microsoft技術スタックのまま同様の構成を実現可能 Semantic Kernelのプラグイン機構は、SQL実行エージェントを組み込む際の標準的な出発点として機能する いずれにせよ、まずは「社内でよく聞かれるデータ的な質問トップ10」をAIに答えさせる小規模なPoC（概念実証）から着手することを勧めたい。データレイクやDWHがすでに存在する企業であれば、AIレイヤーを追加するコストは以前より大幅に低下している。 筆者の見解 GitHubがQubotの構築経験を外部に公開したことは、率直に評価したい。「うまくいった」ことだけでなく「学んだこと」を具体的に語る技術記事は、同じ課題を抱える開発チームにとって価値が高い。 注目したいのは、このエージェントの設計思想だ。毎回人間がSQLを承認・実行するフローではなく、エージェントが問いを受け取り、クエリ生成・検証・実行を自律的に完結させる。AIエージェントが本来もたらすべき価値は認知負荷の削減であり、確認のたびに人間を挟む構成ではその価値は半減する。Qubotはその点で正しい方向に設計されている。 日本企業がこの事例から学べる最大のポイントは、「AIを使わせる」より「AIなしでは回らない仕組みを先に作る」という発想の転換だ。Qubotはデータチームへの依頼待ちというボトルネックを構造的に解消する仕組みとして機能している。ツール導入ではなくワークフローの再設計——この視点こそが、AI活用を組織に根付かせる鍵になる。 出典: この記事は How we built an internal data analytics agent の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AnthropicのサイバーセキュリティAI「Mythos」が、ホワイトハウスの輸出規制命令を受けて突然オフラインになった。通知からわずか約90分でアクセスを全面制限するという異例の対応——その背景には、過去30年にわたって繰り返されてきた「危険なサイバー技術を封じ込めようとした政府の試み」と、その失敗の歴史がある。 MythosとFable——なぜこれほど騒ぎになっているのか Anthropicが今年4月にローンチしたMythosは、サイバーセキュリティ特化型の強力なAIモデルだ。同社自身が「広く流通すればインターネットに甚大な被害をもたらしうる」と説明するほどの性能を持つとされており、リリース当初から約150の審査済み企業・政府機関だけに限定提供されていた。 想定用途は防御側のためのもの——悪用者よりも先に脆弱性を発見・修正するための「ホワイトハット側の兵器」だ。 今回の規制対象はMythosに加え、最新モデル「Fable 5」も含まれる。両モデルは先週から米国外のユーザーはもちろん、米国内の外国籍ユーザーにも提供停止となっている。 規制発動の2つのトリガー 今回の輸出規制発動には、2つの具体的なきっかけがあったとされる。 第一：韓国大手通信会社へのアクセス付与 Anthropicは限定パートナープログラムを通じ、韓国の大手通信会社（広く報じられているのはSK Telecom）にMythosへのアクセスを提供した。米当局はこの企業を「中国との関係が疑われる」と判断し問題視した。SK Telecom側は中国との関係を否定している。 第二：Fable 5の安全策回避報告 Amazon CEOのアンディ・ジャシー氏が、Amazon社内の研究者たちがFable 5の安全策を迂回する方法を発見したとして政権に報告した。Anthropicはこれを「ジェイルブレイク」と呼ぶことを否定し、「狭い範囲のすでにパッチ済みの問題」と反論しているが、当局の懸念を払拭するには至らなかった。 歴史が示す「サイバー技術封じ込め」の実績 今回の事態が特に注目されるのは、過去30年で繰り返されてきたパターンと重なるからだ。 PGP暗号化と「クリプトウォーズ」（1990年代） 1990年代初頭、Phil Zimmermann氏は「Pretty Good Privacy（PGP）」という暗号化ソフトウェアを開発した。傍受されても解読不可能な通信を実現したこのソフトに対し、米政府は「武器輸出規制違反」として刑事調査を開始した。 Zimmermann氏の反撃は鮮やかだった。PGPのソースコードを書籍として印刷・出版したのだ。書籍は表現の自由で保護されるため輸出規制の適用外。この抵抗は「クリプトウォーズ」として歴史に刻まれ、調査は最終的に打ち切りとなった。今日のSignalやWhatsAppが使うエンドツーエンド暗号化の礎はこうして築かれた。 ワッセナー協定とスパイウェア規制（2010年代） 2010年代には西側製スパイウェアが中東の反体制派活動家への監視に使われていることが次々と発覚。各国政府は「ワッセナー協定」を拡大し、監視・ハッキングソフトウェアをデュアルユース技術として分類、輸出ライセンスを義務付けた。 結果は規制の形骸化だった。イスラエルのNSO GroupのPegasusスパイウェアは規制後も世界中への拡散を続けた。 日本のエンジニア・IT管理者への実務的影響 現時点で日本の一般ユーザーへの直接的な影響は限定的だ。Mythosはもともと限定提供であり、Claude 3系など他のAnthropicモデルは通常通り利用できる。 ただし以下の点は注視が必要だ： AI輸出規制の前例形成：今回の枠組みが定着すれば、他のAIラボの製品にも同様の規制が波及しうる。特にサイバーセキュリティ用途のAIは今後より厳しい審査対象になる可能性がある 企業のAI調達リスク管理：安全保障分野に近いサービスを活用する企業は、突然のサービス停止リスクを調達戦略・BCP計画に織り込む必要が出てくる 「限定提供」モデルへの規制：公開型ではなく審査制でアクセスを絞る仕組みを採用しているAIサービスが、今後どういった規制の対象になるかは不透明だ 筆者の見解 歴史の教訓は明快だ。PGP、スパイウェア、そして今回のMythos——「危険な技術を輸出規制で封じ込める」試みは30年にわたって繰り返されてきたが、成功例はほとんどない。技術は本質的に拡散する。知識は書籍になり、コードはコピーされ、手法は伝播する。規制は流通を遅らせることはできても、止めることはほぼできない。 とはいえ、今回の規制発動には無視できない背景がある。「中国との関係が疑われる企業へのMythosアクセス付与」という具体的なインシデントが存在するからだ。純粋な予防的規制ではなく、実際の懸念事象への対応という側面がある以上、一概に「的外れ」とも言い切れない。 問題は手段の実効性だ。輸出規制という19世紀的な枠組みが、コードで表現されたフロンティアAIの拡散を本当に止められるのか。それとも、Anthropicのような企業が自主的な安全策として設計してきた「審査制限定提供」という仕組みの方が、現実に即した対策なのか。 今回の「90分以内に全アクセス制限」という対応が示したのは、AIラボと政府の間にある力学の変化だ。この判断の落としどころが、フロンティアAI全体の「輸出ルールブック」を形成することになる。その行方を、日本のIT業界も他人事として見過ごすわけにはいかない。 出典: この記事は Encryption, spyware, and now Mythos: History shows why cyber export control doesn’t work の内容をもとに、筆者の見解を加えて独自に執筆したものです。

独学のAIエンジニアでアマチュア言語学者のTom Di Minoが、100年以上にわたって世界中の言語学者を悩ませてきた古代ミノア文明の文字体系「線文字A（Linear A）」の解読に成功したと主張している。この主張は現在、ラトガーズ大学とケンブリッジ大学の言語学専門家によって検証が進められている。 線文字Aとは何か 線文字Aは紀元前1800年頃から紀元前1450年頃まで使われた古代ミノア文明の文字体系だ。クレタ島がミケーネ・ギリシャ人に征服された際に使用が途絶え、ミケーネ人はこれをベースに「線文字B（Linear B）」を作り上げた。 線文字Bは1952年に英国人建築家・暗号解読者のMichael Ventrisによって解読され、古代ギリシャ語であることが判明した（ニューヨーク・タイムズの一面を飾るほどの快挙だった）。Brooklyn CollegeのAlice Koberが積み上げた文法・統計的分析の功績なしに、Ventrisの解読は実現しなかったともいわれる。 線文字Aと線文字Bは60個のコア音節を共有しているため、線文字Aの文字がどんな「音」を表すかはある程度推測できていた。しかし「その音が何を意味するか」が完全に不明で、さらに線文字Bに存在しない13個の追加記号が含まれているため、解読は長年の難題であり続けた。 Di Minoが辿り着いたブレークスルー Di Minoは18歳から古典史・言語学を独学で研究し、線文字Aを7年間学んできた。クレタ島を2度訪れ、2026年1月に解読作業を本格開始。5月22日に決定的な洞察を得たという。 ブレークスルーのきっかけは、クレタ島内の5か所の神殿遺跡に共通する「祈祷定型文」の分析だった。各行の冒頭に現れる動詞が線文字B由来の既知記号5文字と線文字A固有の「*301」という記号で構成され、かつ地域ごとに異なる変化形を持つことに気づいた。このパターンを手がかりに言語の構造を解析し、「線文字Aは古代セム語族の言語を記したものであり、聖書ヘブライ語の前身にあたる——ちょうどラテン語がイタリア語の前身であるように」という結論に至った。 セム語族説は1957年にCyrus Gordonが学術誌で主張したことがあるが、実際の翻訳を導くには至らず、学界での受け入れは限定的だった。Di Minoの解読が翻訳として機能するかどうかは、現在進行中の専門家検証の結果を待つ必要がある。 実務への影響——AIが変えたアマチュアの可能性 このニュースが示唆するのは、「AIと深いドメイン知識の掛け合わせ」が専門家集団を超えるアウトカムを生み出し得るという現実だ。日本のITエンジニアにとって実感しやすいポイントをまとめる。 ドメイン知識×AIが最強の組み合わせ: Di Minoは7年間の蓄積なしにAIを使っても解読に至らなかったはず。「AIだけ使えばいい」ではなく、深い専門知識があってこそAIが武器になる パターン認識タスクへのAI活用: 大量の碑文から統計的パターンを見つける作業は機械学習が得意とする領域。考古学・歴史言語学での応用は今後加速するだろう 検証プロセスの設計が鍵: Di Minoの主張は現在ラトガーズ・ケンブリッジで検証中。AIの出力を適切に評価・検証する仕組みを整えることの重要性を改めて示している 筆者の見解 このニュースを読んで真っ先に感じたのは「これはAI時代の縮図だ」という感覚だ。 世界最高水準の言語学者たちが100年以上解けなかった謎を、独学エンジニアが半年で突破した（主張が正しければ）。ここにあるのは「AIがすごい」というシンプルな話ではなく、「一つのテーマに7年間深く潜り続けた人間が、適切なタイミングでAIを武器として使うと何が起きるか」という問いへの示唆だ。 情報の表面を広く追いかけるよりも、一点に集中して深く掘り下げること。そしてその深みのある文脈の中でAIを道具として活かすこと。Di Minoのアプローチはその典型に見える。 もちろん、この解読主張が専門家の検証を通過するかどうかは全くの別問題だ。過去のセム語族説がそうだったように、「翻訳として機能する」ことを証明するハードルは高い。解読の真偽はしばらく注目し続けたい。 出典: この記事は AI Engineer Claims to Have Cracked Linear A の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Elastic（Elasticsearch開発元）は、AIエージェントに本物の長期記憶を持たせるための永続メモリ層をElasticsearchで構築し、その設計思想と実装の詳細を公開した。168問のQA評価でR@10が平均0.89に達し、かつユーザー間のデータ漏洩ゼロを達成したこのアーキテクチャは、エージェント開発者が直面する「記憶問題」に対して実践的な解を示している。 コンテキストウィンドウは「記憶」ではない 多くのAIエージェント実装では、過去の会話履歴をそのままコンテキストウィンドウに詰め込む手法が採られている。しかしこのアプローチには3つの根本的な問題がある。 まずコスト——長い履歴はそのままトークンコストに直結する。次にレイテンシ——大量のコンテキストは推論速度を落とす。そして「中間消失（Lost in the Middle）」効果——研究で示されているように、モデルはプロンプトの端（冒頭・末尾）に近い情報は拾うが、中間に埋もれた情報は無視しがちだ。 100万トークンのコンテキストウィンドウは「作業メモ」であって「記憶」ではない。セッションをまたいで生き残り、年単位でスケールし、内容・時刻・ユーザーで検索できる永続ストアこそが本物の長期記憶だ、というのが本実装の出発点である。 3種類の記憶：認知科学からの借用 Elasticのチームは認知科学の知見（COALAフレームワーク）を参照し、記憶をエピソード・意味・手続きの3種類に分類。それぞれをElasticsearchの独立したインデックスにマッピングした。 エピソード記憶（Episodic Memory）: タイムスタンプ付きの生イベント。各ユーザーターンをそのまま蓄積する。短命なものが多く、後で重要な事実を抽出するための素材となる。 意味記憶（Semantic Memory）: ユーザーに関する安定した事実。「Sarah は Lumio Hub v2 を所有している」「Sarah の iOS バージョンは 17.4」のような蒸留済みのアサーション。セッションをまたいで永続し、エージェントが推論の根拠とする情報がここに入る。 手続き記憶（Procedural Memory）: 複数ステップのプレイブック。「Zigbee接続切断のトラブルシュート手順」のような、事実ではなくプロセスを保存する。 この分類の重要な点は、書き込み頻度とエイジング（鮮度の扱い）がタイプごとに異なることだ。単一の記憶モデルで混在させるとハイスタック化する。タイプ別管理により、検索精度と更新コストを両立させている。 ハイブリッド想起・上書き処理・ユーザー分離 想起クエリにはRRF（Reciprocal Rank Fusion）とクロスエンコーダー再ランカーを組み合わせたハイブリッド検索を採用している。ベクター検索によるセマンティックマッチと全文検索によるキーワードマッチを融合させ、どちらか一方に頼るより精度を高めている。 矛盾する事実が生じた場合は「削除」ではなく「上書き（Supersession）」で処理する。旧バージョンを残しつつステータスを変更するため、監査証跡が完全に保たれる。 マルチユーザー展開では、ElasticsearchのDLS（Document Level Security）をユーザーID単位で適用することでテナント間のデータ漏洩を防ぐ。168問の評価でクロステナント漏洩ゼロという結果は、本実装が単なるプロトタイプではないことを示している。 また、このメモリ層はMCP（Model Context Protocol）対応クライアントであれば何でも接続できる設計になっており、特定のエージェントフレームワークに依存しない。 実務への影響 日本のエンジニアにとって、このアーキテクチャが示す教訓はいくつかある。 「専用ベクターDBでなくてよい」という選択肢: Elasticsearch（またはOpenSearch）がすでに自社インフラにあるなら、それをエージェントメモリとして転用できる。新たなマネージドサービスを増やさずにアーキテクチャをシンプルに保てる点は、運用コストの観点からも現実的だ。 エイジングと鮮度管理の設計思想: 記憶が古くなれば重みを下げ、よく参照される記憶は沈まないようにする——時間とアクセス頻度に基づくスコアリングは、RAGシステム設計全般に応用できる考え方だ。 DLSによるマルチテナント分離: 企業向けSaaSやB2B SaaSを構築する際に即座に参考にできるパターンだ。エージェントが複数ユーザーの記憶を混同するリスクは、セキュリティインシデントとして深刻なものになりうる。 実装はGitHubで公開されており、Agent BuilderとしてElastic CloudでもGA（一般提供）済みだ。 筆者の見解 今回のElasticのアーキテクチャは、「エージェントに本物の記憶を持たせる」という課題に対して、認知科学の分類を実装レベルで具体化した点で評価できる。 私が特に注目するのは「上書き（Supersession）」と「エイジング」の組み合わせだ。記憶は単に保存するだけでは意味がない。矛盾を処理し、鮮度を管理し、重要度の下がった情報を静かに沈め、必要なものを浮かび上がらせる——この仕組みなしに、エージェントは長期間使うほど「ゴミ屋敷化」する。 エージェントが自律的にループで動き続ける「ハーネスループ」の設計においても、セッションをまたぐ文脈保持は最大のボトルネックのひとつだ。毎回コンテキストをゼロから渡し直すモデルでは、エージェントが真の意味で「学習する」ことができない。ループが本当に賢くなるには、今回のような永続記憶層が前提条件になる。 Elasticsearchをすでに使っていない環境では導入コストも無視できないが、「新しいベクターDBを追加するか、既存の検索インフラを転用するか」という問いに後者で答えられる可能性を示したことは実践的だ。3つのインデックス構造・ハイブリッド検索・DLSは、それぞれ単独では枯れた技術。組み合わせ方にこそノウハウがある。エージェントに「セッションをまたいだ文脈」を持たせたいすべての開発者に一読を勧めたい内容だ。 出典: この記事は We built a persistent agent memory layer on Elasticsearch with 0.89 recall の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

2026年6月8日、AppleはWWDC 2026の基調講演でiOS 27 Extensionsを発表し、SiriやWriting Tools・Image PlaygroundなどすべてのApple Intelligence機能において、Claude（Anthropic）・ChatGPT（OpenAI）・Gemini（Google）・Grok（xAI）の中からデフォルトのAIプロバイダーをユーザーが自由に選択できるようになる。 iOS 27 Extensionsとは iOS 27 Extensionsは、Apple Intelligence全体をサードパーティのAIプロバイダーに開放するフレームワークだ。専用のApp Storeマーケットプレイスを通じてAIプロバイダーが配信され、ユーザーはiOSの「設定」画面からデフォルトのAIを切り替えられる。 これまでAppleはChatGPT（OpenAI）との独占的なパートナーシップを維持してきたが、iOS 27 Extensionsではその単一プロバイダーモデルを廃止し、オープンな競争プラットフォームへとシフトする。最初のサードパーティパートナーとしてAnthropicのClaudeとGoogleのGeminiが採用され、既存のChatGPT統合と並んで提供される予定だ。 対象機能と選択の仕組み iOS 27 Extensionsが対象とするApple Intelligence機能は以下の通りだ： Siri：音声アシスタントのバックエンドAIをユーザーが選択可能 Writing Tools：文章作成支援（要約・校正・書き換えなど） Image Playground：画像生成機能 設定画面から「デフォルトAI」を一度選べば、これらすべての機能でそのAIが使われる。Apple Intelligenceのシステムレベルに統合された形で動作するため、アプリをまたいで一貫したAI体験が得られる設計だ。 開発者向けビジネスモデル 注目すべきは小規模開発者への優遇措置だ。年間売上100万ドル（約1.5億円）未満の開発者には、クラウドAI統合のAPIコストが無償となる。個人開発者やスタートアップが、エンタープライズ品質のAIをコストゼロで自社アプリに統合できることを意味する。 AnthropicやOpenAI、Googleにとっては、10億台を超えるAppleデバイスへの直接配信チャネルが開かれることになり、各社の市場拡大において極めて重要な転換点となる。 実務への影響——日本のエンジニア・IT管理者の視点から 開発者への影響：iOSアプリへのAI機能組み込みにおいて、これまでは自前でAPIを呼び出す実装が必要だったが、Extension経由でシステムレベルのAI機能を活用できるようになる。小規模スタートアップにとっては開発コストの大幅削減が期待できる。 企業のデバイス管理：法人向けiOSを管理するIT管理者にとっては、MDM（モバイルデバイス管理）によるAIプロバイダーの制限・指定が新たな課題になる。社内データがどのAIサービスに送信されるかを管理するポリシーの整備が急務だ。情報漏洩対策の観点から、企業ポリシーとユーザーの選択の自由のバランスをどう設計するかが問われる。 ユーザー体験の変化：これまでiPhoneを使うとデフォルトでChatGPTに接続される体験だったが、今後はユーザー自身がAIを選択・管理する時代になる。どのAIに何が送られているかを理解する情報リテラシーが、一般ユーザーにも求められるようになる。 筆者の見解 AppleがAIのシングルプロバイダーモデルから競争プラットフォームへとかじを切ったことは、業界全体にとって健全な変化だと思う。1社依存のエコシステムはリスクを集中させ、イノベーションの速度を鈍らせる。複数のAIプロバイダーが10億台のデバイス上で競争する環境は、長期的には技術の質を高める方向に働くだろう。 この動きの本質は、AIの「OS化」だと筆者は捉えている。スマートフォンが「どのアプリを入れるか」を競った時代と同様に、「どのAIを使うか」という選択がユーザーの日常の一部になる。各AIプロバイダーは10億ユーザーへのリーチを得る一方で、ユーザーに「選ばれ続ける」ための品質競争にさらされることになる。これは消費者にとって間違いなくいいことだ。 日本のエンタープライズへの波及という観点では、セキュリティガバナンスの整備が先決だ。「iPhoneを使ったら社内情報が見知らぬAIサービスに送られていた」という事態を防ぐため、IT部門がExtensionsのポリシー管理に早期から取り組む必要がある。MDMベンダー各社の対応状況を注視しておきたい。 小規模開発者への無償API提供は参入障壁を下げる点で歓迎できるが、「無料枠の上限に達した途端にコストが急増する」構造への注意も必要だ。事業規模に応じたコスト設計は引き続き重要な検討事項となる。 AppleがこのExtensionsフレームワークでどこまで公平な競争環境を保証できるか——その設計の透明性が、今後のAI市場全体の信頼性を左右する重要な試金石になると見ている。 出典: この記事は Apple iOS 27 Extensions: Users Can Now Set Claude, ChatGPT, or Gemini as Default AI Across All Apple Intelligence Features の内容をもとに、筆者の見解を加えて独自に執筆したものです。