生成AI

AI生成と信じれば本物の名画も「粗末な模倣品」に見える X（旧Twitter）ユーザー @SHL0MS が、フランス印象派の巨匠クロード・モネの代表作「睡蓮（Water Lilies）」シリーズの一枚を「AIで生成した画像です。本物のモネとどう違うか教えてください」と投稿し、Xの「AIで生成」ラベルまで付けた状態で公開した。するとたちまち「鑑識眼のある」批評家たちが大量に集結し、この「AI画像の欠陥」を事細かに語り始めた。しかし批評の対象は、モネが晩年31年間にわたって制作した約250点にのぼる「睡蓮」シリーズの本物の作品だった。 識者たちが指摘した「AI特有の欠陥」 集まったコメントは実に詳細で自信に満ちていた。 「深度と色彩に統一感がない。木の反射が睡蓮に溶け込んでいて空間的な奥行きが感じられない」 「AI画像の水面反射はただのノイズ。モネは光が水に当たる動きを本当に理解していた」 「睡蓮の周りの紫色が本物のモネと比べて明らかに劣っている。画家が目と手をつなげることに失敗している」 「焦点がない。遠景になるほど形が崩れる。これが典型的なAIの問題だ」 「生命力がない。本物の絵画が持つテクスチャ、凹凸、筆跡が感じられない。人間の混沌さが欠けている」 850字にも及ぶ詳細な批評を書き上げた人物まで現れた。すべての批評が、モネの本物の傑作に向けられたものだとは露知らず。 なぜこれが重要か：AI画像への「確証バイアス」問題 この実験が浮き彫りにしたのは、先入観によって知覚が歪む「確証バイアス（Confirmation Bias）」 の問題だ。「AI生成だ」と信じると、脳は無意識にその証拠を探し始める。本物のマスターピースでさえ、ラベルひとつで「機械的でつまらない」作品に変わってしまう。 AI画像生成の品質が劇的に向上した現在、この問題はより深刻な意味を持つ。逆パターン、つまり「AI生成画像を本物と信じて鑑賞する」ことも日常的になりつつある。そしてAI検出ツールへの過度な信頼もまた、確証バイアスを強化する方向に働く。 実務での活用ポイント デザイン・クリエイティブ業務での留意点 評価基準を先に設定する: 作品を評価する前に「色彩」「構図」「感情的インパクト」など何を重視するかを明示する。「AI生成かどうか」を判断軸にしない ブラインドテストを導入する: 制作ツールを伏せた状態でA/Bテストを行うことで、先入観のない評価が可能になる 「AI特有の失敗」の定義を定期的に見直す: モデルのバージョンアップで克服済みの欠陥が「AI限界の証拠」として語り継がれるケースが多い。最新モデルで常に再検証する コンテンツ管理・著作権対応の観点 AI生成コンテンツの検出ツールを導入する際は、ツールの誤検知率と確証バイアスの組み合わせが生む「無実の冤罪」リスクを意識する必要がある。検出精度を慎重に検証した上で運用基準を設計したい。 筆者の見解 この実験は痛快であると同時に、深く考えさせられる出来事だ。 「AI生成です」というラベルひとつで、世紀の名作を前にした人々が「空間的奥行きがない」「感情が伝わらない」と自信満々に語り始める。確証バイアスがいかに強力かを改めて実感させられた。 そして同時に、これは現在のAI画像生成技術の到達点を示すシグナルでもある。「AIっぽい欠陥」のイメージが人々の記憶に刷り込まれているからこそ、最新モデルが生成した高品質な画像はその先入観を悠々と超えてしまう。「AIだから劣っているはず」という前提は、技術の進歩とともにどんどん通用しなくなっていく。 クリエイターにとっても、AIツールを業務に取り入れる技術者にとっても、今必要なのはAIへの先入観をいったりリセットし、実際のアウトプットで評価し直す姿勢だろう。本実験はその必要性を、皮肉な形で力強く証明してみせた。 出典: この記事は Someone Shared a Real Monet Painting as AI and Asked for Critiques の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米国労働統計局（BLS）が2026年5月に公表した年次雇用データによると、AIの影響を受けやすいとされる18職種において2024年5月〜2025年5月の1年間で雇用が0.2%減少した。同期間の全体雇用は0.8%増加しており、AI代替リスクの高い職種だけが逆行して減り続けている構図が鮮明になった。 何が起きているか——データが示す「2年連続の雇用減」 今回のデータで注目すべきは、これが「初めての兆候」ではなく2年連続の減少である点だ。BLSがAIへの露出度が高いと分類した18職種は合わせて約1,000万人の雇用を抱えるが、その中でも特に顕著な打撃を受けているのが以下のカテゴリーだ。 カスタマーサービス担当者（コールセンター・チャット対応など） 一部の秘書・行政補佐職（スケジュール管理・文書作成など） 特定の営業職（インサイドセールス・リード対応など） これらに共通するのは「定型的なコミュニケーションと情報処理が業務の中核を占める」という特徴だ。生成AIが最も得意とするタスク構造そのものであり、代替が進むのは必然とも言える。 全体雇用が0.8%増という好調な中でこの18職種だけが0.2%減——つまり雇用市場全体としては悪くないが、特定層に集中的な痛みが生じているという構造が浮かび上がる。 なぜこれが重要か——「AIが仕事を奪う」が仮説から実績値に変わった これまでAIによる雇用喪失は「将来のリスク」として語られることが多かったが、BLSという公的機関の統計データとして数字が出てきたことの意味は重い。 経済学者の間では従来「AIは生産性を上げるが雇用は守られる」という楽観論も根強くあったが、今回のデータはその前提に疑問符を突きつけている。特に注意すべきは、これが景気後退期ではなく雇用全体が成長している局面で起きていることだ。好況期に削減されているということは、コスト削減圧力というより「AIの方が品質・速度で上回った結果の代替」である可能性が高い。 実務への影響——日本のエンジニア・IT管理者が今すぐ考えるべきこと 自社のAI露出度を棚卸しする まず自社・自部門の業務を「定型的なコミュニケーション・文書処理・情報集約」の割合で評価してほしい。カスタマーサポート、社内ヘルプデスク、一般事務、インサイドセールスなどはいずれも高露出カテゴリーに入る。 BLSが使った分類基準は参考になる。「その仕事の主要タスクをLLMに渡したとき、人間と同等以上の成果が出るか」という問いが簡易チェックとして機能する。 「禁止」ではなく「仕組みで使いこなす」設計を 日本企業でよく見られる反応は「AIを業務利用禁止にする」か「様子見する」だが、どちらも的外れだ。使い方のガイドラインとガバナンス体制を整えた上で積極活用する方向に舵を切った企業と、禁止・放置を続けた企業の間には、数年で越えられない生産性格差が生じる。 IT部門が取るべきアクションとして具体的には： 社内向けRAGシステムや承認済みAIツールの整備（公式ルートを最も便利にする） AIリテラシー研修の義務化（特にマネジャー層） 影響を受けやすいポジションのリスキリング計画の策定 エンジニアとして価値を高めるポイント 影響を受けにくい側にいたいなら「AIを使って仕組みを作る側」に移行することが最重要だ。単にプロンプトを叩けるというスキルではなく、AIエージェントが自律的に動くパイプラインを設計・運用できる能力が市場価値を決める。 筆者の見解 今回のBLSデータは「そうだろうと思っていた」という確認に近い。しかし統計として出てきたことで、経営層への説得材料としての重みが格段に増した。 日本のIT現場で気になるのは、この種のデータが出ても「米国の話だから」と距離を置く傾向が根強いことだ。だが日本のカスタマーサービス・事務・営業の仕事の構造は米国と大きく変わらない。むしろ日本は人件費の硬直性と人材不足という固有事情から、AI代替のインセンティブが企業側に強くある。 個人的に確信しているのは、これから価値を持つのは「少数でも仕組みを動かせる人」だということだ。1000人の部隊が100人になっても同じ成果を出す仕組みを設計できる人材と、その仕組みの中の1プロセスを担っていただけの人材では、置かれる立場が全く変わる。 「AIが仕事を奪う」という文脈はセンセーショナルに語られがちだが、本質は「どのレイヤーで働くかを選べ」というメッセージだと思っている。自動化される側に留まるのか、自動化する側に移るのかを、今この瞬間に選択できる。その猶予がまだある今のうちに動いておくことを強く勧めたい。 出典: この記事は US is starting to see heavy job losses in roles exposed to AI の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Googleは2026年4月、学術研究のワークフロー効率化を目的とした2つのAIエージェントフレームワーク「PaperVizAgent」と「ScholarPeer」を発表した。論文作成における図版生成の煩雑さと、急増する投稿数による査読システムの疲弊という2つの課題に、マルチエージェント構成で正面から取り組む試みだ。 なぜいま学術ワークフローにAIエージェントなのか 学術論文の執筆は、アイデアを思いついて文章を書くだけでは終わらない。トップカンファレンスや権威ある学術誌に採択されるためには、手法を正確に説明するアーキテクチャ図や、統計的に正しく視覚的にも洗練されたグラフが不可欠だ。これらを一から手作業で仕上げるのは、研究者にとって本来業務から外れた多大な時間を要する作業になっている。 一方、論文の投稿数はAI研究の爆発的な増加とともに急増しており、査読者の不足と評価の不均一化が深刻な問題となっている。GoogleはこれらをAIエージェントで解決できると考え、2つのフレームワークを開発・公開した。 PaperVizAgent：5エージェントによる反復的図版生成 PaperVizAgent（旧称：PaperBanana）は、論文のテキストから出版品質の図版を自動生成するエージェントフレームワークだ。研究者が与えるのは2つのインプットだけでいい。 ソースコンテキスト: 論文の手法セクションなど、技術的な詳細が記載された文章 コミュニカティブインテント: その図で何を伝えたいかを記述したキャプション これを受け取ったPaperVizAgentは、内部で5つの専門エージェントを協調させて動く。 Retriever（取得）: 既存の学術図版を参照例として収集 Planner（計画）: コンテンツを整理・構造化 Stylist（スタイル）: 学術標準に合ったデザインガイドラインを合成 Visualizer（描画）: 実際の図版を生成、またはPythonコードを出力 Critic（批評）: 出力を元のテキストと照合し、矛盾があればVisualizerにフィードバック CriticからVisualizerへのフィードバックループが、出力の品質を反復的に高める仕組みだ。評価では、GPT-Image-1.5やPaper2Anyといった競合手法を上回る品質を示したとされている。 ScholarPeer：文献に基づく厳格な自動査読 ScholarPeerは、学術論文を自動的かつ厳密に評価するレビュアーエージェントだ。単に文章を読んで感想を述べるのではなく、論文内の図版やグラフも含めて評価し、関連文献に基づいた根拠のあるレビューを生成する。Google の発表によれば、既存の自動査読システムを上回るレベルの「批判的かつ文献根拠のある査読」を実現しているという。 実務への影響——日本の研究者・エンジニアにとっての意味 研究者・大学院生への直接的インパクトは大きい。論文提出直前の図版修正作業や、投稿前のセルフレビューに活用できる可能性がある。特にPaperVizAgentがPythonコードを出力する機能は、研究者が後から細部を調整しやすい点で実用的だ。 AI・MLエンジニアへのアーキテクチャ的示唆も見逃せない。5エージェントの役割分担と、Critic→Visualizerのフィードバックループという設計は、汎用的なマルチエージェント設計パターンとして参考になる。「生成→評価→再生成」という反復構造は、品質保証が必要なコンテンツ生成タスク全般に応用できる考え方だ。 査読支援ツールとしてのScholarPeerは、日本の学会運営の効率化にも貢献できるポテンシャルがある。投稿論文数の増加と査読者確保の困難さは日本の学術コミュニティでも共通の課題であり、一次スクリーニングや査読コメント草案作成への活用が現実的な候補として挙がるだろう。 ただし、現時点では研究レベルの発表であり、一般利用可能なプロダクトとして提供されているわけではない。コードはGitHubで公開されているため、技術的に試したいエンジニアはまず論文とコードを確認するところから始めるのが現実的だ。 筆者の見解 PaperVizAgentで最も注目すべきは、品質を高める手段として「反復ループ」を設計の中核に据えた点だ。単一モデルに一発で完璧な図版を求めるのではなく、Criticエージェントが問題を検出して再生成を促すループを回す——この発想は、自律的なエージェント設計として理にかなっている。 エージェントが自分で判断・実行・検証を繰り返すループ設計は、今後のAIエージェント活用の中心的なパターンになっていく。その観点から、このフレームワークのアーキテクチャは学術ツールという文脈を超えて参考になる。 ScholarPeerについては、現状の査読システムが持続可能かという問いへの現実的な応答として評価できる。完全自動化は理想論だとしても、「論文の一次評価」や「査読コメント草案の生成」に絞った活用であれば、研究コミュニティへの実質的な貢献は十分ありうる。 Googleは画像・視覚表現の分野で強みを持つ企業だ。その技術をアカデミックな文脈に応用したという点で、本発表は一定の説得力がある。研究者の「本来やるべきこと」に集中できる時間を増やす——という方向性自体は正しいと思う。実際にどれだけ現場で使われるかは、今後の継続的な改善と使いやすさ次第だろう。 出典: この記事は Improving the academic workflow: Introducing two AI agents for better figures and peer review の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Meta AI Research は2026年3月、AIエージェントが自分自身の改善手続きまで自律的に書き換える新アーキテクチャ「HyperAgents」を発表した。単なる「賢いエージェント」ではなく、「どのように賢くなるか」という仕組みそのものを進化させる点が従来技術との決定的な違いだ。 HyperAgentsとは何か HyperAgentsは「自己参照型エージェント（Self-referential Agent）」と呼ばれる新しいクラスのAIシステムだ。以下の2つの機能を単一の編集可能なプログラムに統合している： タスクエージェント（Task Agent）: コーディング・数学・論文評価など実際の問題を解く メタエージェント（Meta Agent）: タスクエージェントと自分自身の両方を修正・改善する 重要なのはメタエージェントの修正手続き自体も編集対象になっている点だ。「何を改善するか」だけでなく「どのように改善するか」という仕組みそのものが変化し続ける。研究チームはこれを「メタ認知的自己変容（Metacognitive Self-Modification）」と呼んでいる。 Darwin Gödel Machineからの進化 HyperAgentsは、2025年に発表された「Darwin Gödel Machine（DGM）」を基盤としている。DGMは単一のコーディングエージェントから出発し、自己修正したバリアントを繰り返し生成・評価することで能力を拡張し続ける仕組みだった。 ただしDGMには根本的な制約があった。コーディング領域ではタスク性能の向上が自己改善能力の向上に直結するが、数学や科学的推論ではその前提が成り立たない。「コードを書く能力」と「数式を評価する能力」は別物だからだ。 DGM-Hyperagents（DGM-H）はこの制約を取り除く設計だ。メタレベルの改善手続き自体を進化させることで、ドメイン間の「改善能力の一致」という前提に依存せず、あらゆる計算可能なタスクで自己加速的な進歩が可能という理論的基盤を得た。 4つの領域での評価結果 研究チームは以下の多様な領域でDGM-Hを評価した： 評価領域 内容 コーディング プログラミングベンチマーク 論文レビュー 学術論文の品質評価 ロボティクス報酬設計 強化学習の報酬関数設計 数学採点 オリンピックレベルの解答評価 いずれの領域でも、自己改善なしのベースラインおよびDGM（前世代）を上回る性能を示した。注目すべきは、メタレベルの改善（記憶の永続化、性能トラッキングなど）がドメインをまたいで転用でき、実行を重ねるごとに累積的に向上するという結果が得られた点だ。 安全性への取り組み 自己改善AIは制御が難しくなるリスクを内包する。研究チームは以下の対策を実施したと明記している： サンドボックス実行: 外部環境への意図しないアクセスを防止 人間による監視（Human Oversight）: 重要なステップでの人間チェック 安全性の議論: 論文内でこの設定における安全性の定義と自己改善システムの広範な影響を考察 「自律改善AIは危険」という直感的懸念に対し、研究段階での安全対策を明示している点は評価できる。ただし研究環境での対策と実用環境でのギャップをどう埋めるかは、今後の課題として残る。 日本のエンジニア・IT管理者への影響 HyperAgentsは現時点では研究論文段階であり、明日から使えるツールではない。しかしこのアーキテクチャが示す方向性は今から理解しておく価値がある。 実務で意識すべきポイント： エージェント評価軸の変化: 今後のAIエージェント製品を評価するとき、「固定ルールで動くか」「自律的に適応するか」という軸が重要になる。製品選定の判断基準を更新する準備をしておくべきだ ハーネスループ設計の重要性: エージェントが自律的にループで動き続けるアーキテクチャへの理解・投資は、ますます意味を持つ。単発の指示→応答ではなく、判断・実行・検証を繰り返すループを設計できるエンジニアが希少価値を持つ ドメイン横断の転用可能性: メタ改善が特定ドメインに依存しないという設計は、企業が社内業務の多様なタスクにエージェントを展開する際に大きな意味を持つ。一度学んだ改善手法が別部門・別タスクに活かせる未来だ 筆者の見解 正直に言う。MetaのAI研究はプロダクトの出来とは切り離して評価する必要がある。今回のHyperAgentsは、理論的なインパクトという観点では目を引く仕事だ。「改善のやり方を改善する」というアイデアは、AI自律化の根本的な問いに正面から向き合っている。 「ハーネスループ」という観点から見ると、HyperAgentsが描く「エージェントがループで自分の改善手続きを書き換え続ける」というビジョンは、まさに筆者が注目してきた方向性と重なる。エージェントが単発のタスクをこなすのではなく、自分で判断・実行・検証を繰り返し、しかもそのループの仕組み自体を改善していく——これが実用化されれば、ソフトウェア開発の風景は今とは全く別物になる。 課題は実用化の道のりだ。研究チームが「サンドボックス＋人間監視」で実施した実験を、エンタープライズの本番環境でどう再現するか。自己修正するエージェントの監査可能性をどう担保するか。これらはまだ答えの出ていない問いだ。 自己改善型AIエージェントが真に実用化される日は来る。そのとき、今この段階でエージェントアーキテクチャを深く理解している人とそうでない人の差は、情報収集の差ではなく実装経験の差として現れるだろう。論文を読んで「ふーん」で終わらせず、現時点で使えるツールで実際にエージェントを動かし続けることが、長期的に一番意味のある投資だと思っている。 出典: この記事は HyperAgents の内容をもとに、筆者の見解を加えて独自に執筆したものです。

CloudflareとStripeは2026年4月30日、AIエージェントが人間の介入なしにCloudflareアカウントの開設からドメイン購入・有料サブスクリプション契約・本番環境へのデプロイまでを完全自律で実行できる新機能を発表した。両社が共同設計した新プロトコルにより、「コードは書けるが本番環境へ出せない」というエージェントの壁が取り払われた形だ。 何が変わったのか これまでコーディングエージェントは、ソフトウェアを構築することは得意でも、本番デプロイに必要な「アカウント」「支払い情報」「APIトークン」の3点は人間が手動で用意する必要があった。CloudflareダッシュボードでAPIトークンを発行し、クレジットカード情報を入力し、DNSを設定する——これらは人間が担ってきた「最後の一マイル」だった。 今回の発表でこの制約が解消される。StripeのCLIにstripe projectsプラグインを追加してログインし、stripe projects initを実行するだけで、エージェントは以下の一連の作業を自律実行できる。 Cloudflareアカウントの新規プロビジョニング（または既存アカウントへのOAuth連携） APIトークンの取得 ドメインの購入・登録 アプリケーションの本番デプロイ 人間がやることは、Cloudflareの利用規約への同意と、Stripeに支払い方法を登録することだけ。ダッシュボードを開く必要すらない。 プロトコルの仕組み：3つのコンポーネント 新プロトコルはDiscovery・Authorization・Paymentの3要素で構成される。 Discoveryは、エージェントが利用可能なサービスカタログをクエリする仕組みだ。エージェントはCloudflareが何を提供できるかを動的に「発見」し、ドメイン購入やデプロイの手順を自律的に組み立てる。 AuthorizationはOAuth/OIDCを拡張したもので、Stripeがユーザーのアイデンティティを証明し、Cloudflareが既存アカウントへの連携または新規アカウントの自動プロビジョニングを行い、APIトークンをエージェントに安全に発行する。 Paymentは支払いトークン化の仕組みで、Stripeが提供するトークンをCloudflareが使って課金する。クレジットカード番号がエージェントを経由することはなく、安全性が担保されている。 なお、デフォルトで月次上限$100の支出制限が設けられており、エージェントが意図せず高額の購入を行うリスクを抑える安全機構も内蔵されている。 実務への影響 この仕組みが普及すると、エンジニアの作業フローは大きく変わる可能性がある。 プロトタイピングの加速: ハッカソンや社内PoC開発で、「インフラの初期セットアップ」がボトルネックにならなくなる。エージェントに「これをCloudflareにデプロイして」と指示すれば、新しいドメインで動くプロダクトが数分で手に入る。 マルチテナント構成の自動化: SaaSプロダクトで顧客ごとに独立したCloudflare環境を払い出すケースや、開発・ステージング・本番の環境を動的に生成する用途に活用できる。 コスト管理の自動化: 月次上限機能とStripeの請求管理を組み合わせることで、エージェントによるリソース消費を予算内に収める仕組みを構築しやすくなる。 CloudflareのCode Mode MCPサーバーやAgent Skillsと組み合わせることで、コーディングエージェントのCloudflare操作精度もさらに向上する。今後、Stripeと同様の方式で他のプラットフォームも連携できるよう設計されており、Cloudflareはこのプロトコルをオープンに提供するとしている。 筆者の見解 この発表は、AIエージェントの本質的な価値がどこにあるかを鮮明に示している。 「コードを書く」だけなら既存のコーディング支援で十分だ。しかし「ゼロから本番環境まで届ける」となると、今まではどこかで人間の手が入る必要があった。Cloudflareアカウントを作り、APIトークンを発行し、支払い方法を登録する——これらの手順は一見些細に見えて、実はエージェントの自律性を根本から制限していた。 今回の仕組みはその制限を正面から取り除いている。エージェントが自分でDiscoveryしてAuthorizationを通りPaymentを処理するという設計は、「副操縦士」ではなく「自律的に仕事を完遂する存在」としてのAIエージェントを実現するアーキテクチャだ。 AIエージェントが自律的にループで動き続ける「ハーネスループ」の観点から見ると、このプロトコルはループの外側——「実行した結果を世界に反映させる」部分を担うピースだ。コードを書いて終わりではなく、デプロイして動くものを届けてループを閉じる。この設計思想は、今後のエージェントアーキテクチャの標準になっていくはずだ。 一方で、安全機構のデフォルト$100上限は現実的な判断だが、企業利用では上限の設定や監査ログの整備が必須になる。エージェントに課金権限を与えることへのガバナンス設計は、各社が独自に詰める必要がある部分だ。「エージェントに何をどこまで委ねるか」という問いへの答えは、技術ではなく組織ポリシーが出すことになる。 インフラの「最後の一マイル」を自律化するこの流れは、止まらない。今後を見据えたエージェントアーキテクチャの設計において、このプロトコルを無視するのはもったいない。 出典: この記事は Agents can now create Cloudflare accounts, buy domains, and deploy の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIの「アライメント（整合性）」政策を書いている人々は、AIに仕事を奪われていない側にいる——ソフトウェアエンジニアのDaniel Tanがブログで投稿したこの指摘が、Hacker Newsで92ポイント・63コメントを集め大きな反響を呼んでいる。 アライメント論争の「外側」にいる人たち AnthropicやOpenAIをはじめとするAI研究機関、財団、政策機関では、AI安全性に関する議論が日々行われている。「ドゥーマー（悲観論者）」と「アクセラレーショニスト（加速論者）」が激しく対立しているように見える。 Eliezer Yudkowskyは「大型GPUクラスターを政府がシャットダウンし、必要なら核戦争リスクも辞さない」とTIME誌に寄稿し、Marc AndreessenはTechno-Optimist Manifestoの中でAIに反対する人々を「ルサンチマン（怨恨）に病んだ人間」と診断する。 しかしDaniel Tanが指摘するのは、この二陣営の対立の下に横たわる共通前提だ。 「議論をしている人たちが設計する側であり、他の全員は設計される対象になっている」 両陣営は「どう設計するか」で激しく争っているが、「設計の参加者は自分たちだ」という前提を共有している。その構造自体が問われていない。 Anthropicのアライメント手法も同じ構図を持つ 2026年4月、Anthropicのアライメントサイエンスブログは、AIモデルに自己行動をレポートさせる訓練手法を公表した。訓練データは「ターゲット行動をエンコードしたシステムプロンプトで別のモデルを動作させ、フィルタリングする」形で生成される。 これは技術的には洗練されたアプローチだ。しかし「AIを人間に整合させる」という文脈で見ると、評価ループはAnthropicが雇用した評価者と、その評価で訓練された別のAIモデルで閉じている。実際にAIと共存する現場のエンジニア・ワーカー・ユーザーは、そのループの外に置かれたままだ。 「ラベル付け」という排除の構造 Tanが鋭く指摘するのが、当事者の不満への「ラベル付け」だ。ドゥーマー陣営は懸念を示す人を「技術適応が遅れている」と言い、Andreessenは「ルサンチマンを抱えた病人」と診断する。 どちらも、問題を訴える人間の側に原因を帰属させる。仕事が変わる・消える感覚を持つ人々の声は「個人の適応失敗」に矮小化され、アライメント設計のプロセスへの参加から構造的に排除される。 実務への影響——日本のIT現場で考えること 日本のIT現場でも「生成AIのガバナンス」「AI倫理ガイドライン」という言葉が増えているが、その議論の場に実際にAIと向き合う開発者・運用担当者がどれだけ入っているだろうか。 ガバナンス設計に現場を含める: AI導入のルール作りは、経営・情報システム部門だけで完結させない。実際に使う側・使われる側双方が参加する場を設ける。 「使われる側」の感覚を定量・定性両面で拾う: ログ分析だけでなく「AIが入ってどう感じたか」を組織的に収集する仕組みを作る。これがないとアライメントは机上の話になる。 Anthropicのアライメント手法を技術として学ぶ: Constitutional AI、モデルスペック（振る舞いの仕様書）による行動制約は、自社AIシステムの設計にも応用できる考え方だ。自社のAIエージェントに「何を最適化させるか」を文書化する習慣をつけると、後から設計意図を問い直せる。 筆者の見解 Tanの問いは技術論ではなく構造論だ。「誰がアライメントの枠組みを決めるか」は、一見哲学的に見えて、実は権力の配置に関わる現実的な問いである。 Anthropicのアライメントサイエンスは技術的には非常に丁寧に作られている。しかし「評価の輪」の内側にいる人々と外側にいる人々の非対称性は、今の手法では解消されていない。これは責めるべき話というより、現在の手法の限界として正直に認識しておく必要がある。 日本の文脈では、DX推進で「AIを入れる」決断をする側と、AIと共存しながら日々の業務をこなす側は、多くの場合まったく別の人間だ。この構造を無視したままAI導入を進めると、組織内部でも「アライメント」の問題が静かに蓄積する。 AIエージェントを「自律的に動く仕組み」として活用していくならば、そのエージェントが誰のために何を最適化しているかを設計段階で明示する必要がある。それを決める議論に、実際に現場でAIと向き合う人間が参加していなければ、「アライメント済み」という言葉は空虚になる。設計する側とされる側の非対称性を意識したAI導入こそが、長期的に機能する組織を作る。 出典: この記事は The people writing AI alignment policy are not whose work is being replaced の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Googleは2026年5月19日より年次開発者カンファレンス「Google I/O 2026」を開幕し、次世代GeminiモデルやAndroid XRグラスの新情報など、AI分野を中心とした大型発表が予定されている。基調講演はライブ配信され、2日間にわたってGemini・Android・Chromeの幅広いアップデートが披露される見込みだ。 最大の注目：次世代Geminiモデルの発表 最も期待されているのが次世代Geminiモデルの発表だ。バージョン4.0相当になるかどうかは未確定だが、現行モデルを大きく超える性能向上が見込まれている。GeminiはすでにSearch・Gmail・Google Workspace・YouTubeといった主要サービスに深く組み込まれており、新モデルがリリースされればその影響は広範に及ぶ。今回のI/Oで発表される内容がGoogleの製品ロードマップ全体のトーンを決める位置づけになる。 さらに、Nano Banana・Gemma・Lyria・Genieといったその他のAIツール群のアップデートも予測されており、動画生成ツール「Veo 4」の発表も噂されている。 事前リークで判明：Gemini Liveの音声モデル強化 発表前にすでに気になる情報が浮かんでいる。Googleアプリの隠し設定画面に「Capybara」「Nitrogen」などのコードネームを持つGemini Liveの音声モデルが7種類発見され、そのうち1つは自身を「Gemini 3.1 Pro」と名乗ったという。現行のGemini Liveを動かす「Flash Liveモデル」からの性能向上を示唆する名称だ。 モデルごとにメモリ機能・位置情報アクセス・ファクトチェック能力に差異があることも確認されており、切り替えのインフラはすでに完成済みで公開を待つだけという状況らしい。複数のモデルバリアントを用途に応じて使い分けられるようになれば、音声インターフェースの活用幅は大きく広がる。 動画生成の進化：Gemini Omniとは何か 動画生成の面では「Gemini Omni」と呼ばれる新モデルが一部ユーザーに先行提供されているとの情報がある。動画リミックス・チャット内編集・テンプレートを使った動画作成が可能で、既存のVeo技術を発展させたものと見られている。 初期デモでは高品質な結果が報告されているが、あるユーザーが1日のAI Pro使用枠の86%を消費したという事例も報告されており、計算コストの高さが実用上の課題として残る。企業向けプランでどのように提供されるかが、採用判断の分かれ目になるだろう。 Android XRグラスのデモにも期待 2025年のI/OではSamsungおよびQualcommとの協業によるXRヘッドセットとAndroid XRスマートグラスが発表されたが、実際に動作するデモは限定的だった。今年は実動するAndroid XRグラスのデモが見せられるのではと期待されている。 実務への影響 Google Workspace利用者は変化が直接影響する Gmail・Docs・Sheetsを日常的に使っているチームにとって、Geminiの精度向上は即戦力になる。特に文書要約・メール作成・スプレッドシート分析への組み込みがどこまで深化するかに注目したい。 音声モデルの多様化は業務活用の入口になる可能性 コールセンター・カスタマーサポート・多言語対応など、音声処理が重要な業種では、Gemini Liveの強化は実務ユースケースを広げる可能性がある。 動画生成コストは要確認 Gemini Omniのコスト問題が企業プランでどう解決されるかは未定。制作フローに組み込む前に、課金体系と使用量上限を確認してから設計することを強く勧める。 筆者の見解 Googleの動画・画像生成分野における技術力は着実に成熟してきており、Gemini Omniが示す「チャット内での動画リミックス編集」という方向性は実用的なコンテンツ制作ツールとして面白いアプローチだ。Veoとの統合が進めば、YouTubeクリエイター向けのワークフロー変革につながる可能性がある。 一方で、日本のエンジニアが実務の核心でGeminiをどう位置づけるかは、発表後のハンズオン評価を待ってから判断すべきだ。「情報を追いかける」より「実際に触って成果を出す」ことが今のAI活用で最も有効なアプローチであることは変わらない。Google I/O 2026の発表内容を見た上で、自社の業務フローに本当にフィットするかどうかを冷静に見極めてほしい。 Android XRグラスの進捗も含め、5月19日の基調講演はGoogleの2026年の方向性を把握するための良い機会になる。AIだけでなくデバイス・プラットフォームを含む全体の絵がどう描かれるか、注目に値する。 出典: この記事は What to expect from Google I/O 2026: Gemini news, Android XR glasses の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米シカゴ大学の現役学生Owen Yingling氏が、ChatGPTをはじめとするLLM（大規模言語モデル）の蔓延が大学教育を根本から蝕んでいると訴える記事を発表した。「ゾンビ化（Zombification）」と呼ばれるこの現象は、一部の不正行為問題にとどまらず、知的成長の機会そのものを失わせる文化的危機だという。 UCLA卒業式の「1枚の写真」が示したもの 記事のきっかけとなったのは、UCLA（カリフォルニア大学ロサンゼルス校）の卒業式でChatGPTの画面を誇示する学生の写真だ。多くのメディアはこれを「AIを使った不正行為の問題」として報じた。しかしYingling氏は、そのような解釈は「違いの本質を見誤っている」と指摘する。 問題は単純な不正行為ではない。ChatGPTをはじめとするAIツールが大学という制度の「あらゆる部位」に浸透した結果、学習そのものが成立しなくなっているのだ。 持ち帰りと対面で40ポイント差——数字が示す実態 最も衝撃的な報告が、持ち帰り試験と対面試験の成績差だ。Yingling氏がTA（ティーチングアシスタント）を務めた論理学の授業では、両者の間に約40ポイントの差が生じていた。持ち帰り課題においてAIを全面的に活用している学生が多いことを如実に示している。 以前はLLMの回答精度が低く、AIを使っても70点台程度にしかなれなかった。しかし今やその状況は一変した。LLMの性能が急激に向上したことで、課題の種類によってはAIを使えばほぼ満点が取れてしまう。 「ビジネス経済学」から始まった感染の拡大 Yingling氏は、ChatGPT等のAI利用の蔓延を「癌」の進行に例える。最初は「局所的な腫瘍」として、厳格さを欠いたビジネス経済学の授業を中心に広がった。機械的な繰り返しが中心の問題セットは、LLMが最も得意とする形式だった。 この「腫瘍」は次第に転移しつつある。講義ノートすらAIで書かれているのではないかと感じさせる教授の存在も指摘されており、学生だけでなく教育者側にも波及している実態が浮かび上がる。 日本のIT・教育現場への示唆 この問題は日本とも無縁ではない。大学のレポートや卒業論文へのAI使用は日本でも広がりつつあるが、多くの大学は「禁止するか黙認するか」という二択で止まっており、AI時代における評価・育成の本質的な再設計には踏み込んでいない。 IT現場においても同じ構図がある。ChatGPTやCopilot等を使って作業を「こなせる」人は増えているが、技術的な理解が追いついていないと、障害発生時やシステム設計の局面での判断力が著しく低下する。AIが出した答えをそのまま流用する「ゾンビエンジニア」の増加は、日本のITインフラにとっても深刻なリスクだ。 実務での活用ポイント 採用・評価方法の見直し: 持ち帰り課題よりも対面での技術対話やライブコーディングの比重を高めることが、AIが普及した時代の現実的な対応策となる 「ファシリテーター型」人材の育成: AIを使いこなしつつ、その出力を批判的に評価できるスキルセットが実務で不可欠になっている。使えることと理解していることは別物 社内研修・オンボーディングの再設計: 「AIで答えを出すスキル」と「なぜその答えが正しいかを説明するスキル」を明確に分けて育成する仕組みが必要 課題設計の変革: ChatGPTに解かせやすい形式の課題（定型的な問題セット、持ち帰りレポート）は根本から見直す必要がある 筆者の見解 AIを積極的に使う立場から言うと、この問題の核心は「AIを使うこと」自体にあるのではなく、「考えることをAIに外注している」ことにある。 道具として使いこなすのと、ゾンビになるのは全く異なる。十分な理解を持つエンジニアがAIを使えば生産性は劇的に上がる。しかし何も理解していない状態でAIを使えば、何も理解しないまま成果物だけが出てくる。それが積み重なると、誰もシステムを本質的に理解していないという恐ろしい事態が生まれる。 「禁止すれば解決」という発想があるとすれば、それは間違いだ。禁止アプローチは必ず失敗する。重要なのは、AI存在下でも「自分の頭で考えた」という経験を積ませる場の設計だ。日本の教育機関も企業研修の現場も、この設計変更に早急に取り組む必要がある。 AIが人間の認知を代替しつつある今、「何をAIに任せて、何を自分で考えるか」の境界線を意識的に引けるかどうかが、これからのエンジニアの真価を決める。この問いから逃げた組織は、数年後に深刻なツケを払うことになるだろう。 出典: この記事は The AI zombification of universities の内容をもとに、筆者の見解を加えて独自に執筆したものです。

AIツール導入の「成果」をトークン使用量で競わせる——そんな歪んだKPI「Tokenmaxxing」が登場し、ソフトウェアエンジニアリングの現場に波紋を広げている。米国のソフトウェアエンジニアリングマネージャー、Brian Meekerが自身のブログで、AIポリシーの必要性とその具体的な内容を公開した。 「Tokenmaxxing」とは何か Tokenmaxxingとは、企業がAIツールの導入を促進するために、チーム内でトークン使用量のリーダーボードを作成し、誰が一番多くトークンを消費しているかを競わせるという手法だ。 表向きは「AIを積極的に使っているか」の指標だが、実態は即座に「ゲーム」された。エンジニアたちはトークンを無駄遣いするループを作成してリーダーボードのトップに立つか、「使っているように見せる」程度のトークン消費に留めて本当の使用状況を隠すかのどちらかを選んだ。 Meekerはこれを「虚栄の指標が指導力を装ったもの」と一刀両断する。20年以上前にストップウォッチで作業時間を計測しようとして失敗した管理職の話を例に挙げ、「計測されれば人の行動は変わる。本質から乖離した指標を設定すると、そこに向けて最適化される」という普遍的な教訓を改めて提示している。 Meekerチームの「AIポリシー」4原則 Meekerは自身のチームに向けてAIポリシーを策定し、4つの原則を明示した。 1. AIツールの使用義務はない AIツールを使うかどうかはエンジニアの判断に委ねる。使用量でレビューされることはない。ただし、この技術が業界に与えるインパクトは無視できないため、動向を継続的に把握することは求める。 2. AIが生成したコードを理解すること AIが書いたコードをそのまま貼り付けることは禁じていないが、そのコードが「何をしているのか」を説明できなければならない。コードのオーナーシップはあくまで人間にある。 3. AIツールなしでも仕事ができること AIツールが突然使えなくなっても、業務を継続できる能力を維持する。ツールへの過度な依存はリスクであり、成長の停滞にもなりうる。 4. チームとお客様を大切にすること 最終的に仕事の目的は顧客の課題を解決することだ。Tokenmaxxingのような指標は、この本質から目を逸らさせる。 日本のIT現場への影響 このポリシーが示す問題意識は、日本のIT現場にも直接当てはまる。 「とにかくAIを使え」という圧力への対処 ChatGPTやGitHub Copilotの普及に伴い、「AI活用推進」を名目にした曖昧な指令が増えている。しかし何をもって「活用した」と判断するのか不明確なまま現場に丸投げされるケースが多い。Meekerのアプローチは、指標より「哲学」を先に定義する重要性を示している。 コードレビューの質が変わる AIが生成したコードを「理解せずにマージ」するケースは国内外で既に問題になっている。「AIが書いたから自分は責任を持たない」は通用しない。レビュアーも作成者も、コードの中身を追える技術力を維持し続ける必要がある。 「禁止」ではなく「ガイドライン」で管理する AIツールを禁止する企業は今でも多いが、その場合も裏で勝手に使われるだけだ。Meekerが実践したように、公式のポリシーとして「何のために使うか」「何をしてはいけないか」を定義することが現実的な解だ。禁止は最も手っ取り早く、最も機能しないアプローチである。 筆者の見解 Tokenmaxxing——トークン消費量をリーダーボードで競わせる——は確かに愚かだ。しかし筆者が問題視しているのは、指標をハックした人間の行動であって、「AIの活用度を測ろう」という方向性そのものではない。 率直に言えば、「AIをどれだけ効果的に使いこなしているか」を可視化すること自体は、かなり筋のいい発想だと考えている。変なKPIを定めてその数字だけをハックしてしまうのは人間が陥りがちな罠であり、それは指標設計の問題であって、AI活用を測ること自体の否定にはならない。 Meekerの4原則は誠実な試みだと思う。ただし「AIを使わなくてもいい」という選択肢を前面に出すことには、少し慎重になるべきだ。今の時代にエンジニアとしてAIを積極的に使おうとしない姿勢自体が大変まずい。「使わなくてもいい」を強調しすぎると、使わない言い訳を組織に与えてしまうリスクがある。 必要なのは「使うな」でも「使え」でもなく、「どう使えば効果的か」を組織として定義し、仕組みとして支援することだ。成果指標は見直すべきだが、AIをうまく活用しながらいかに仕事をこなすかという方向に舵を切るための仕組みづくりと動機付けは必須だと筆者は考えている。Tokenmaxxingの失敗から学ぶべきは「測るな」ではなく「正しく測れ」だ。 出典: この記事は Have a Coherent AI Policy の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropicが最先端サイバーセキュリティAIモデル「Mythos」を一部の米国企業にのみ提供し、OpenAIも「Daybreak」イニシアティブで同様の限定公開方針を示したことで、フロンティアAIへのアクセスが経済・安全保障上の理由から選別される時代が始まりつつある。 フロンティアAIが「選ばれた企業のもの」になる 2026年4月、Anthropicはサイバーセキュリティに特化した最先端AIモデル「Mythos」を発表した。その能力——既存の脆弱性を検出・修正するパッチ適用能力——は業界に驚きをもって迎えられたが、同時に衝撃を与えたのはその公開範囲だ。Mythosにアクセスできるのは、Anthropicがパートナーとしてリストアップしたごくわずかの米国企業のみ。日本はもちろん、欧州やその他の同盟国すら含まれていなかった。 その後、OpenAIも「Daybreak」イニシアティブにおいてサイバーセキュリティ分野で同等の能力を持つとされるモデルの限定公開方針を発表。これが偶然や一時的な戦術ではなく、構造的なトレンドであることが明らかになった。 アクセス制限を引き起こす3つの力 1. セキュリティと蒸留リスク 最先端モデルはサイバー攻撃や生物兵器設計への悪用リスクを持つ。Mythosのケースでは、まず「守り手」側の企業に先行アクセスを与え、既存の脆弱性を修正した上で段階的に公開する戦略が取られた。さらに「蒸留（Distillation）」問題もある——高性能モデルを使ってその能力を凝縮した小型モデルを作れるため、制限されたモデルの能力が間接的に拡散するリスクを孕む。 2. コンピューティングコストと経済的選別 最先端モデルの推論コストは急増している。特定の高価値ユースケース向けにしかペイしないビジネスモデルが定着しつつあり、大量の一般公開よりも価値の高い限定パートナーシップを優先する経済的インセンティブが働いている。 3. 米国政府の関与 最も長期的な影響を持つのが、米国安全保障機構のAI政策への関与だ。政府はAI開発企業に対し、危険な能力を悪意ある行為者から遠ざけるよう圧力をかけており、これが事実上の「技術輸出規制」として機能し始めている。 日本企業・エンジニアへの影響 短期的には現状維持だ。Anthropic Claude APIやOpenAI GPT系のAPIは引き続き日本からもアクセスできる。現時点ではサイバーセキュリティの最先端領域という特定の分野で制限が始まっているにすぎない。 ただし中長期的な影響は看過できない。AI能力が国家安全保障上の戦略資産として扱われるようになれば、米国政府の方針次第でより広範な制限がかかる可能性がある。日本は日米同盟の文脈でアクセスを確保できるかもしれないが、それは「確約」ではなく「配慮」の話だ。 エンジニアとして今すぐ取るべきアクションは3つある： 現在アクセス可能なフロンティアモデルを徹底的に活用する — 制限が来る前に経験値を最大化せよ ローカルLLMへのフォールバック戦略を持つ — LlamaやMistralベースのモデルは制限の対象外になりやすい 組織内のAI活用基盤を整備する — アクセスが制限されても即座に代替手段に切り替えられる設計を今のうちに 筆者の見解 セキュリティ上の懸念は理解できる。最先端のサイバーセキュリティAIが悪意ある行為者の手に渡れば、その被害は計り知れない。MythosとDaybreakの「守り手ファースト」という戦略は、段階的なリスク管理として一定の合理性がある。 ただ、「フロンティアAIへのアクセスは米国の特権」という構造が固定化されることへの懸念は消えない。AIが産業競争力の根幹を担う時代に、特定の国や企業だけが最先端能力にアクセスできる状況は、長期的には技術的な非対称性を固定化してしまう。 日本のIT現場が今この状況から受け取るべき最大の教訓は「依存の危険性」だ。特定のベンダー・API・国の判断に競争力を全乗せするのは危うい。情報を追いかけるよりも、今アクセスできる範囲でAIを実際に使い倒し、いかなる制限が来ても対応できるアーキテクチャを身につけておくことが、長期的な生存戦略になる。フロンティアAIの時代は「誰が使えるか」だけでなく、「誰が自力でやれるか」が問われる時代でもある。 出典: この記事は Access to frontier AI will soon be limited by economic and security constraints の内容をもとに、筆者の見解を加えて独自に執筆したものです。

Anthropicは2026年5月14日、大規模コードベースにおけるClaude Codeの動作原理とエンタープライズ向けベストプラクティスをまとめた記事を公開した。数百万行規模のモノリポ、数十年にわたって積み重なったレガシーシステム、数十のマイクロサービスにまたがる分散アーキテクチャ——そのいずれでもClaude Codeは本番運用されており、成功事例に共通するパターンが存在するという。 Claude Codeの「ナビゲーション」はエンジニアと同じ思考プロセス Claude Codeが大規模コードベースを探索する方法は、熟練エンジニアの思考プロセスに近い。ファイルシステムを走査し、ファイルを読み込み、grepで必要なものを探し、コードベース全体を横断しながら参照を追う。インデックスの事前構築も、サーバーへのアップロードも不要で、開発者のローカルマシン上で完結する。 これはRAG（Retrieval-Augmented Generation）ベースのAIコーディングツールとは根本的に異なるアプローチだ。RAGはコードベース全体を埋め込みベクトル化し、クエリ時に関連チャンクを取得する仕組みだが、アクティブな開発チームのペースには追いつけないという本質的な限界がある。 2週間前にリネームされた関数、先のスプリントで削除されたモジュール——RAGのインデックスはこうした変更を遅れて反映するため、検索結果に「すでに存在しないコード」が平然と現れる。Claude Codeのエージェント型検索はこの問題を構造的に回避する。中央集権的なインデックスがないため、数千人のエンジニアが新しいコードをコミットし続けても、各開発者のインスタンスは常にライブのコードベースと向き合える。 ただし、トレードオフもある。Claude Codeは「どこを見ればよいか」の初期コンテキストが充実しているほど精度が上がる。10億行規模のコードベースで漠然としたパターン検索を依頼すれば、作業開始前にコンテキストウィンドウの限界に到達してしまう。コードベースのセットアップへの投資が結果の質を左右する所以だ。 「ハーネス」がモデル性能を決める Claude Codeに関してよくある誤解は、その能力がモデルのスペックだけで決まるという思い込みだ。しかし実際には、モデルの周囲に構築されるエコシステム——ハーネス——がパフォーマンスを決定的に左右する。 ハーネスは5つの拡張ポイントで構成される： CLAUDE.mdファイル — コードベースやプロジェクトの文脈をClaude Codeに伝えるドキュメント フック（Hooks） — 特定のイベントをトリガーにして自動実行されるカスタム処理 スキル（Skills） — 繰り返し使う複雑なタスクを抽象化したモジュール プラグイン（Plugins） — ツールや機能を追加する拡張機能 MCPサーバー — 外部ツール・APIとの統合レイヤー これらの拡張ポイントは積み重ね型で、各レイヤーが前のレイヤーを土台にして機能する。CLAUDE.mdによるコンテキスト付与が土台となり、その上にフックやスキルが乗る設計だ。 Anthropicは今回の記事をエンタープライズ向けシリーズ「Claude Code at scale」の一環として位置づけており、C、C++、C#、Java、PHPなどのレガシー言語環境でも最近のモデルリリースにより予想以上の性能を発揮していると述べている。 実務への影響：日本のエンジニア・IT管理者へ CLAUDE.mdに投資することが最初の一手 Claude Codeを大規模環境で導入する際、最も費用対効果が高い初期投資はCLAUDE.mdの整備だ。プロジェクトのルート、各サブディレクトリ、チームのコーディング規約——これらの情報をCLAUDE.mdに記述することで、Claude Codeが「どこから探索を始めればよいか」を理解できるようになる。 インデックスレスの設計は「モノリポ問題」への有力な解答 日本の大手SIerや事業会社には、長年にわたって肥大化したモノリポや、部門ごとに乱立したリポジトリ群を抱えるケースが多い。RAGベースのツールがインデックス更新の遅延に悩む環境では、Claude Codeのエージェント型アプローチが実用的な選択肢になりうる。 ハーネスの設計はアーキテクチャの仕事 フック・スキル・MCPサーバーの組み合わせは、単なる設定ファイルではなくシステムアーキテクチャの一部だ。これらの設計をエンジニアリングチームのプロセスに組み込めるかどうかが、AI活用の成否を分ける。 筆者の見解 今回Anthropicが公開した内容で最も重要なポイントは、「モデルの賢さよりハーネスの設計が結果を決める」という事実の明示だ。これはある意味、AI活用の民主化とは逆の方向性を示している——道具が賢くなるだけでは不十分で、道具を囲む仕組みを設計できるエンジニアリング能力が問われるということだ。 特に注目すべきはハーネスループの考え方だ。CLAUDE.mdで文脈を与え、フックで自動化のトリガーを設け、スキルで複雑なタスクを抽象化する——この積み重ねが、Claude Codeを「単発の指示に応えるツール」から「自律的に判断・実行を繰り返すエージェント」へと変貌させる。自律的なループを設計できるかどうかが、AI活用の深さを決める。 日本の開発現場では、「AIツールを入れたけど思ったより使えなかった」という経験をした組織が少なくないだろう。多くの場合、それはツールの限界ではなくハーネスへの投資不足の問題だ。CLAUDE.mdを書き、フックを整備し、チームの作業パターンをスキルとして抽象化する——この地道な積み上げこそが、大規模コードベースでのAI活用の鍵になる。 エンタープライズシリーズとして今後も知見が公開される見込みで、大規模開発組織にとって参照すべき一次情報になっていくだろう。 出典: この記事は How Claude Code works in large codebases の内容をもとに、筆者の見解を加えて独自に執筆したものです。

1型糖尿病を持つソフトウェアエンジニアが、内分泌科医の不在期間を乗り越えるために自ら開発したセルフホスト型AIプラットフォーム「GlycemicGPT」がGitHub上でオープンソース公開された。AIによる血糖パターン分析・食事応答分析・予測アラートを自分のインフラ上で完結させる設計が大きな特徴だ。 GlycemicGPTとは何か GlycemicGPTは、連続血糖測定器（CGM）やインスリンポンプのデータをAI分析レイヤーに接続するオープンソースプラットフォームだ。開発者自身が「内分泌科医の予約が数ヶ月取れず、誰もデータを見てくれない期間があった。だから自分で作った」と述べており、医療アクセスの格差という現実的な問題意識から生まれたプロジェクトである。 現在対応しているデバイスは以下のとおり： デバイス 種別 接続方式 検証状況 Dexcom G7 CGM クラウドAPI 検証済み Tandem t:slim X2 インスリンポンプ BLE直接接続 + クラウドAPI 検証済み Tandem Mobi インスリンポンプ BLE直接接続 + クラウドAPI プロトコル互換（実機未検証） すでにNightscoutを利用している場合は、既存インスタンスを指定するだけでAI分析レイヤーを追加できる。既存のセットアップを変更する必要はない。 AIレイヤーの機能 AI分析レイヤーが提供する機能は以下の4点が中心となる： デイリーブリーフ：就寝中・24時間の血糖パターンを自然言語でまとめた日次レポート 食事応答分析：食事ごとの血糖応答パターンを記録・分析 会話型AIチャット：糖尿病の臨床知識ベース（RAG）を背景に持つ対話インターフェース 予測アラート：閾値を設定でき、介護者へのエスカレーション機能も備える 重要な点として、GlycemicGPTはインスリンを投与しない。ポンプを制御しない。クローズドループシステムではない。 データを読み取り、洞察を提供するだけであり、臨床的な判断は医師と患者の間に留まる。この線引きは意図的かつ明確にされており、安全設計の根幹をなしている。 アーキテクチャ：BYOAI×完全セルフホスト GlycemicGPTの設計思想で特に注目すべきは「BYOAI（Bring Your Own AI）」という考え方だ。AIプロバイダーをユーザー自身が選択できる構造になっており、以下のいずれかを選べる： Ollamaによる完全ローカル実行：データがハードウェア外に出ない Claude / OpenAI / OpenAI互換エンドポイント：ホステッドモデルを利用する場合 どちらを選んでも、データはユーザーのインスタンスからAIプロバイダーに直接流れ、プロジェクトが運営する中央サービスを経由しない。GlycemicGPT自体はデータを保有しない設計だ。 デプロイはDockerまたはKubernetesで行い、Webダッシュボード・REST API・Androidアプリ・Wear OSウォッチアプリをすべて自前のインフラで稼働させる。ライセンスはGPL-3.0で、サブスクリプション不要・ベンダーロックイン不要。 スタック構成は以下のとおり： バックエンドAPI：FastAPI、Python 3.12、PostgreSQL 16、Redis 7 Webダッシュボード：Next.js 15、React 19、Tailwind CSS、shadcn/ui AIサイドカー：TypeScript、Express、マルチプロバイダープロキシ Androidアプリ：Kotlin、Jetpack Compose、BLE Wear OS：Kotlin、Wear Compose、Watch Face Push API プラグインSDK：Kotlin、ケイパビリティベース、サンドボックス化 日本の医療・IT現場への影響 日本では「糖尿病専門医が地方に少ない」「予約が数ヶ月待ち」という状況は決して珍しくない。GlycemicGPTのような自己管理支援ツールは、医師との診察間隔を補完する手段として現実的な価値を持つ。 ...

BBCのパノラマ調査班が2026年5月15日に公開した報告書により、スリランカ・ベトナム・モルディブ・イラン・UAEなど海外に拠点を置く業者が、AI生成動画を使ってイギリスの「移民による衰退」というナラティブをFacebookおよびInstagramで大規模に拡散させていた実態が明らかになった。 何が行われていたか 「Great British People」というFacebookページは、外見上はヨークシャーを拠点とするイギリス人コミュニティを装っていた。しかし実際の運営者はスリランカに在住しており、最新の動画だけで130万回以上の再生を記録している。 投稿コンテンツの多くはAI生成で、以下のような明らかな虚偽シーンを含む： 英国下院の議席がアラブ民族衣装の男性で埋め尽くされシャリア法が施行される場面 偽のニュースキャスターが「大規模移民の圧倒的な実態」を報告する偽インタビュー映像 2050年のリバプール・ロンドン・バーミンガムがゴミだらけでハラールの屋台が立ち並ぶというAI生成のウォーキング動画（累計2000万回以上再生） 矛盾した点として、これらのアカウントは「イスラム移民による英国の衰退」を訴えつつ、同じ制作者が「イスラム圏の国々は理想郷」とする動画も配信しており、ナラティブの一貫性よりもエンゲージメント獲得を優先している様子が見える。 実行手口の技術的側面 ケンブリッジ大学社会心理学者のサンダー・ファン・デア・リンデン教授は、これらの活動を「影響工作（influence operations）の新たな進化形」と位置づけている。 問題を悪化させているのは以下の構造だ： 英国アカウントの売買が安価: 海外業者でも英国ユーザーが元々持っていたSNSアカウントを低コストで購入し、英国人を装って投稿できる AI生成コンテンツのコスト低下: 高品質な偽動画・偽インタビューが安価に量産できる時代になった プラットフォームの透明性ツールに限界: FacebookのTransparency Toolsはアカウントの所在を一部開示するが、完全な追跡は困難 AI偽コンテンツを見破る能力の過信: 調査によると、人間はAI生成フェイクを検出する能力を過大評価している。さらに、AI生成コンテンツに頻繁に触れるほど本物の情報まで疑うようになるという「逆効果」も報告されている ロンドン市長のサディク・カーン氏はAI生成画像による首都イメージへの悪影響を懸念し、独自の調査を委託している。一部アカウントはロシア・イラン政府寄りの投稿も行っており、国家レベルの関与が疑われるケースも存在するが、直接証拠の確認は困難な状況だ。 実務への影響：日本のエンジニアとIT管理者に何ができるか この問題は英国だけの話ではない。日本においても同様の手口で世論操作が行われるリスクは十分ある。IT現場で押さえておくべき実践的な観点を整理する。 1. AI生成コンテンツ検出ツールの把握 Content Authenticity Initiative（CAI）が策定しているC2PA（Coalition for Content Provenance and Authenticity）規格は、コンテンツの出所を電子署名で証明する仕組みだ。Adobe・Microsoft・Googleなど主要ベンダーが参加しており、今後のコンテンツ管理システム導入時にはこの規格への対応有無を確認する価値がある。 2. 社内のメディアリテラシー研修への組み込み フィッシング訓練と同様に、「AIフェイク動画の見分け方」を社員教育に組み込む企業が欧米では増えている。顔の不自然な動き、背景のちらつき、音声と口の動きのズレといった初歩的なチェックポイントから始めるだけでも効果がある。 3. SNS上の情報ソースの一次確認習慣 エンゲージメント数（いいね・シェア数）は情報の信頼性とは無関係だ。特に企業の意思決定に影響する情報はBBC・Reuters・APなど信頼できる一次情報源まで遡る習慣を組織に根付かせたい。 筆者の見解 AIが生成したフェイク動画がこれほどの規模で世論操作に使われているという事実は、改めてAI技術の「両刃の剣」的な側面を突きつける。 生産性向上や情報処理に革命をもたらしているのと同じ技術が、安価で大量のフェイクコンテンツ生産に使われている。技術的には同一の能力だ。「AIを禁止すれば安全になる」という発想が機能しないのはここに理由がある。禁止すれば善意の利用者が不便になるだけで、悪意のある業者は別の手を探すだけだ。 より現実的なアプローチは、コンテンツの来歴（provenance）を技術的に担保する仕組みと、人間側のリテラシー向上の両輪だ。C2PA規格の普及加速や、プラットフォームによる不審アカウントの透明性向上は、業界全体の優先課題として位置づけるべきだ。 日本のIT業界にとっての教訓は、こうした影響工作が「どこか遠い国の話」ではないという認識を持つことだ。選挙・社会的議論・企業の評判、いずれも標的になりうる。技術者として、検出・対策の議論に積極的に加わっていきたい。 出典: この記事は Overseas fakers using AI videos to push a narrative of UK decline, BBC finds の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GitHubやGitLabといった中央集権型コードホスティングへの依存から脱却し、ユーザーが自らデータを所有・管理できるP2Pコードコラボレーション基盤「Radicle」がバージョン1.8.0をリリースした。HackerNewsでも236ポイントを獲得する注目を集めており、分散型コードホスティングの本格普及に向けた動きが加速している。 Radicleとは何か Radicleは、Gitを基盤としたオープンソースのP2P（ピアツーピア）コードコラボレーションスタックだ。リポジトリ管理・イシュー・コードレビューといった機能はGitHubと同等に提供されるが、根本的に異なるのは単一の事業者がネットワークを支配しないという設計哲学にある。 従来のコードホスティングサービスでは、リポジトリの所有権は名目上ユーザーのものでも、実際にはプラットフォーム側がアクセス制御・可用性・利用規約のすべてを握っている。GitHubのCopilot学習データ問題やMicrosoft買収後のコミュニティ不安感など、集中型プラットフォームへの依存リスクに関する議論は絶えない。Radicleはこの構造そのものを変える試みだ。 技術的な仕組み 暗号学的アイデンティティ コードとソーシャルアーティファクト（イシューやコメントなど）はすべてGitオブジェクトとして保存され、公開鍵暗号方式で署名される。誰が何を書いたかを暗号学的に検証できるため、なりすましや改ざんのリスクを排除できる。 P2Pプロトコル ピア間のデータ転送にはGitそのものを、リポジトリメタデータの交換にはカスタムゴシッププロトコル（NoiseXK）を採用している。各ユーザーが自前のノードを運営でき、特定企業のインフラに依存せず運用できる。 ローカルファースト設計 インターネット接続がなくても機能するローカルファーストアーキテクチャを採用。オフライン環境でも作業を継続でき、データのバックアップや移行も容易だ。「データは自分のものである」という原則を技術的に担保している。 Collaborative Objects（COBs） Radicle独自の概念「Collaborative Objects（COBs）」は、イシュー・ディスカッション・コードレビューをGitオブジェクトとして実装するソーシャルプリミティブだ。開発者はCOBsを拡張して独自のコラボレーションフローを構築でき、プラットフォームへの機能依存を最小化できる。 現状のスタックとインターフェース CLI・Web・TUI（ターミナルUI）に加え、2025年6月にはデスクトップクライアント「Radicle Desktop」もリリース。スタック構成はモジュラー設計で、各コンポーネントを差し替えることも可能だ。 Linux・macOS・BSDに対応しており（Windowsは現時点で非対応）、インストールは以下のコマンド一発で完了する： 出典: この記事は Radicle: Sovereign {code forge} built on Git の内容をもとに、筆者の見解を加えて独自に執筆したものです。

世界CTFランキング（CTFTime）でトップ10に常連ランクインしていたセキュリティ研究者が、「CTFシーンはもう死んだ」と宣言した。Claude Opus 4.5やGPT-5.5といったフロンティアAIの登場により、セキュリティ競技のスコアボードが人間のスキルを測るものではなく、AIエージェントへの投資規模——つまりどれだけトークンを買えるか——を反映するものに変質してしまったという告発だ。 CTF（Capture The Flag）とは CTFは、暗号解読・バイナリ解析・Webセキュリティ・フォレンジックなど多様なセキュリティ領域の問題を解き、「フラグ」と呼ばれる文字列を獲得して競うセキュリティ競技だ。世界最大のランキングサイト「CTFTime」には年間数百の大会が登録されており、学生から現役セキュリティ研究者まで幅広い層が参加している。日本でも就職・転職のポートフォリオとして機能しており、上位入賞者は即戦力として高く評価される文化がある。 記事の著者は2021年からCTFを開始し、オーストラリア最大のCTF「DownUnderCTF」でチームBlitzkriegとして複数回優勝。後に国際トップチーム「TheHackersCrew」に加入し、2025年末まで世界トップ10の常連として活躍してきた人物だ。単なる外野の批評ではなく、当事者の証言として重みがある。 GPT-4が「予兆」を示した GPT-4の登場以降、中程度の難易度の問題であれば問題文を貼り付けるだけで解答が出てくる「ワンショット解答」が可能になった。ただし当初は、難問は解けず時間短縮効果も限定的で、競技バランスを大きく崩すほどではなかった。 著者が強調するのはAIツールの利用そのものは問題ではないという点だ。CTFプレイヤーはデバッガやスクリプトなど昔から様々なツールを活用してきた。問題の本質は、「モデルが推論し、解答を書き、人間には旗をコピペする以外にやることが残らない」状態になったことにある。 Claude Opus 4.5が転換点になった 著者が「ゲームが変わった」と指摘するのが、Claude Opus 4.5の登場だ。このモデル以降、中程度の難易度の問題はほぼすべて、一部のハード問題さえも、AIエージェントが自律的に解けるようになった。 決定打になったのがClaude Codeの存在だ。CLIとして提供されたClaude Codeにより、CTFdのAPI（競技プラットフォームのAPI）経由でClaude インスタンスを各問題に対して自動起動するオーケストレーターの構築が容易になった。「競技開始後1時間はシステムを走らせておき、残った問題だけ人間が取り組む」というアプローチが、現実的な勝利戦略になったのだ。 これにより、AIを使わないチームは「利便性を捨てている」のではなく、「遅い別のゲームをやっている」状態になった。スコアボードはセキュリティスキルに加えて、AIエージェントのオーケストレーション能力と最先端モデルへの投資意欲を反映するものに変わり始めた。 GPT-5.5が「止めを刺した」 さらにGPT-5.5・GPT-5.5 Proの登場が状況を決定的にした。GPT-5.5 Proは、HackTheBoxの最高難度カテゴリ「Insane」のヒープ・エクスプロイト問題（leakless heap pwn）をワンショットで解けることが確認されている。48時間のCTFでPro相当のモデルをInsane問題に対して投入すれば、イベント終了前にフラグを取れる可能性が十分あるという。 これはオープンCTFが事実上の課金ゲー（pay-to-win）になったことを意味する。より多くのトークンを投入できるチームが、より早くボードを制圧できる。その結果、世界トップ常連チームのCTFTimeでの出現が減り、選手のアクティビティも低下。何週間もかけて良問を作り込んだ出題者も、数分でAIエージェントに食い尽くされる現状に直面している。 日本のセキュリティ現場への影響 この状況は、日本のセキュリティ業界にとって複数の意味を持つ。 採用・評価指標として： これまでCTF上位入賞は即戦力の証明として機能していた。今後は「CTF成績」だけを採用基準にすることのリスクを認識する必要がある。AIを駆使した成績なのか、純粋なスキルを示す成績なのか、文脈の理解が重要になる。 防御側への警告として： CTFを「攻撃者の練習場」と捉えるなら、AIエージェントが既知の脆弱性を自動的に発見・悪用できる時代が来ていることは深刻な警告だ。従来の「既知攻撃パターンへの防御」だけでは不十分で、AIエージェントによる自律的な攻撃への備えが急務だ。 実践的なヒント： 自社のペネトレーションテストにAIエージェントを組み込む前に、倫理・法的枠組みを整備する 「AIが解けない問題の特性（新規性、文脈依存の直感、未公開の攻撃手法）」を理解することが、次世代のブルーチームに必要な視点 HackTheBox・picoCTFなど主要プラットフォームがAI利用ポリシーをどう変えるか動向を注視する 筆者の見解 CTFがここまで急速に変質してしまったことは、セキュリティ教育の観点からとてももったいないと感じる。洗練された問題を何週間もかけて作り込む文化、そこで育つ人材の質——これらはセキュリティ業界全体の財産だった。 ただし、これは「AIが悪い」という話ではない。AIエージェントがInsane難度の問題を自律的に解くという事実は、同じエージェントが実際の攻撃シナリオでも機能しうることを示している。これをCTFの問題として矮小化せず、実環境のセキュリティ設計にどう組み込むかを考える機会として捉えるべきだ。 スコアボードの形が変わっても、本物のスキルが活きる場所はなくならない。「AIエージェントを設計・制御し、AIが解けない問題を特定する能力」こそが次世代のセキュリティエキスパートに求められる資質になるだろう。競技の形が変わるのは技術進化の必然であり、新たなゲームのルールを早く見極めた人が次のフェーズでも先頭を走れると思っている。 出典: この記事は Frontier AI has broken the open CTF format の内容をもとに、筆者の見解を加えて独自に執筆したものです。

米大手通信キャリアのVerizonが、Anthropicの未公開最先端モデル「Claude Mythos Preview」を自社通信インフラのソフトウェア脆弱性検出に活用するテストプログラム「Project Glasswing」に参加した。テック企業以外の巨大企業がAIをセキュリティ実務に本格的に組み込む動きが、いよいよ現実のフェーズに入ってきた。 Project Glasswingとは何か 「Project Glasswing」は、Anthropicが選定した大企業パートナーに対し、まだ一般公開されていない研究段階のモデルへの早期アクセスを提供するプログラムだ。名称の由来は、翅（はね）が透明で内部が透けて見えるグラスウィング蝶（Greta oto）。コードの内部を見通す能力を持つAIモデルのコンセプトを体現している。 Verizonが今回テストするのは「Claude Mythos Preview」と呼ばれるモデル。一般向けにはまだ提供されていない開発中のモデルを、テスト環境で自社の通信インフラを支えるソフトウェアの脆弱性スキャンおよび検出タスクに投入し、精度・速度・コスト面での有効性を検証していく。 なぜセキュリティ脆弱性検出にAIが注目されるのか 脆弱性検出はこれまで、SAST（静的解析）ツールやペネトレーションテストの組み合わせで対応されてきた。しかしコードベースの巨大化・複雑化に伴い、ルールベースの静的解析だけでは検出漏れが生じやすくなっている。 大規模言語モデル（LLM）は、コードの文脈と意図を理解しながら潜在的なリスクを推論できる点が従来ツールと根本的に異なる。単純なパターンマッチングではなく、「このコードが実際の攻撃シナリオでどう悪用されるか」まで推論できる能力が、セキュリティ分野での活用を加速させている。 Verizonのような通信キャリアは何億人ものユーザーデータを抱えるインフラを維持しており、一つの脆弱性が社会的に甚大な被害をもたらすリスクがある。セキュリティへの投資コストが元来高い業界だからこそ、AIによる自動化の費用対効果が見えやすい。 実務への影響：日本のエンジニア・IT管理者が注目すべき点 1. テック企業以外でのAIセキュリティ活用が「現実の選択肢」になった VerizonはGoogleやMicrosoftのようなクラウドベンダーではなく、通信キャリアだ。同じく大規模インフラを持つ日本の通信キャリア（NTT・KDDI・SoftBank）や金融機関・製造業でも、近い将来同様の取り組みが現実の選択肢になる。「様子見」を続けることのコストを意識すべき時期に来ている。 2. CI/CDパイプラインへのAI統合を小さく試す まず着手できる実践的なアプローチとして、CI/CDパイプラインにAIコードレビューを組み込むことから始められる。GitHub Advanced SecurityやAmazon CodeGuruのような既存ツールで効果を実感した上で、LLMを活用した脆弱性検出の内製化ロードマップを描く段階に入っている。 3. 早期アクセスプログラムが競争優位になりうる Project Glasswingに参加するにはAnthropicに選定される必要がある。こうした早期アクセスプログラムは、大企業が最新AI能力を競合よりも先に実務に適用するための重要な手段となっていく。日本企業もベンダーのアーリーアクセス申込みや研究パートナーシップを積極的に模索すべき局面だ。 筆者の見解 このニュースで注目したいのは、「Claude Mythos」の性能そのものよりもプログラムの構造だ。Anthropicが選定企業に未発表モデルを提供するアーキテクチャは、AIベンダーが「モデルを売る」から「モデルと現実データの接点を設計する」フェーズへ移行していることを示している。 セキュリティ分野でのLLM活用は、単なる「AIに脆弱性を聞く」レベルをすでに超えつつある。自律的にコードを走査し、脆弱性を検出し、レポートを生成するまでをAIエージェントがループで繰り返す——こうした自律実行の設計こそが、次のフロンティアだ。Verizonの事例は、そのフロンティアが「テック企業のラボ」から「現実のインフラ運用」に移ってきたことを示している。 セキュリティのような「失敗したら取り返しがつかない」領域こそ、AIの自律的な検出能力への投資を急ぐべき分野だ。日本企業が業界横断で「実務投入」を真剣に検討し始めるきっかけとして、このVerizonの事例を参考にしてほしい。 出典: この記事は Verizon joins Project Glasswing to test Anthropic’s Claude Mythos model on its infrastructure の内容をもとに、筆者の見解を加えて独自に執筆したものです。

イーロン・マスク氏がOpenAIとサム・オルトマンCEOを訴えた「マスク対オルトマン裁判」が、2026年5月14日（現地時間）に最終弁論を迎えた。数週間に及ぶ審理で明らかになった数々の証言が、AI業界の実態と人間模様を赤裸々に映し出している。 迷走したマスク側の最終弁論 マスク側弁護士スティーブン・モロ氏の最終弁論は率直に言って低調だった。共同被告であるグレッグ・ブロックマン氏を「グレッグ・オルトマン」と誤って呼び、判事から訂正を受ける場面もあった。また、マスク氏が金銭的賠償を求めていないと誤って主張するなど、事実誤認が重なった。 対するOpenAI側弁護士サラ・エディ氏は、証拠を時系列に整理して淡々と提示した。「彼の子供たちの母親でさえ、彼の証言を裏付けられなかった」という一言がこの日最大の皮肉として法廷に響いた。 裁判で明らかになった5つの重大事実 1. GrokはOpenAIのモデルを蒸留して開発されていた 今回の裁判で技術的に最も重要な証言は、マスク氏自身が「xAIは他のモデル（OpenAIのモデルを含む）を蒸留した」と認めたことだ。Grokが驚異的なスピードで開発されたことには業界でも疑問の声があったが、完全に独立した開発ではなかったことが確認された形だ。xAIに投資した投資家にとっては、その資金の意義を問い直さざるを得ない事実と言えるだろう。 2. テスラのAIはAGIレベルで機能しなかった マスク氏はOpenAIの買収を試み失敗した後、サム・オルトマン氏を含むOpenAI従業員をスカウトして「世界トップクラスのAIラボ」設立を目指したが、こちらも失敗に終わっていたことが明らかになった。 3. ミラ・ムラティ氏の二重行動 元OpenAI CTOのミラ・ムラティ氏が、オルトマン氏解任劇において双方に接触していたことが判明した。解任に関わる情報をボードに提供する一方、オルトマン氏に内部情報を流していたという。その後は公の場で解任劇を批判。この行動が「方向性として非常にまずい」と評されたのは当然だろう。 4. マスク氏はOpenAIを子供たちに継がせたかった オルトマン氏の証言によれば、マスク氏はOpenAIを自身の子供たちに継承させることを望んでいたとされる。「人類のために」という設立理念と、個人的な継承欲求の間には大きな乖離がある。 5. 「切れない」と言いながら法廷で切れた マスク氏は自分は感情的にならないと証言したが、OpenAI側弁護士の反対尋問中に実際に感情的になる場面があったという。言行不一致が法廷記録として残ることになった。 日本のIT実務への影響 この裁判は直接的なIT実務への影響は限定的だが、見落とせない論点がある。 モデル蒸留と知的財産の問題: GrokがOpenAIモデルを蒸留して開発されていた事実は、AI開発における知的財産権の議論を加速させる可能性がある。自社でLLMのファインチューニングや独自モデルの開発を検討している企業は、使用するベースモデルや学習データの権利関係をあらためて法務部門とともに確認しておく必要がある。 「公益」を掲げるAI企業への評価軸: OpenAIはもともと非営利として設立されたが、営利転換をめぐる混乱がこの裁判の根本にある。AI企業が掲げる「人類のため」というビジョンを、利用者企業側が冷静に評価する目を養うことが重要だ。調達判断や戦略的パートナーシップを結ぶ際は、ベンダーのガバナンス実態も評価材料に含めるべきだ。 筆者の見解 この裁判から見えてくるのは、「AI業界のトップに立つ人物たちも普通の人間である」というシンプルな事実だ。 GrokがOpenAIのモデルを蒸留して開発されたという点については、蒸留という技術手法自体は広く用いられているものの、競合他社のモデルを使って商業的な優位性を築くことが倫理的・法的に問題ないかどうかは全く別の話だ。AI開発における「フェアプレー」の定義が、業界全体で問われる時代になってきていると感じる。 勝訴・敗訴の行方よりも気になるのは、法廷劇に多大なリソースが費やされている一方で、実際の技術革新は静かに進んでいるという現実だ。AIツールが急速に進化するこの時期、ゴシップを追いかけるよりも手を動かして実際に使い倒す経験の方が、エンジニアとして長期的に価値がある。 最終的にユーザーに価値をもたらしたプロダクトが市場で評価される。それは法廷ではなく、現場で決まるものだ。 出典: この記事は Closing time の内容をもとに、筆者の見解を加えて独自に執筆したものです。

GoogleのYouTubeは2026年5月15日、AI顔認識による「なりすまし検出（Likeness Detection）」機能を、18歳以上のすべてのユーザーへ開放すると発表した。これまでコンテンツクリエイターや著名人に限定されていた保護機能が一般ユーザーにも解放されることで、誰でも自分の顔を使ったディープフェイクコンテンツをプラットフォーム全体で常時監視できるようになる。 Likeness Detection（顔認識検出）とはどんな機能か この機能は、ユーザーが自撮り形式で顔写真を登録すると、YouTubeのAIがプラットフォーム全体を継続的にスキャンし、顔が一致する動画を検出する仕組みだ。一致が見つかった場合、ユーザーに通知が届き、そのコンテンツの削除申請を行うことができる。 削除審査はYouTubeのプライバシーポリシーに基づいて行われ、判断基準には以下が含まれる： コンテンツが現実的かどうか（明らかなCGやフィクションは対象外） AI生成コンテンツとしてラベルが付いているかどうか 個人を一意に特定できるかどうか パロディや風刺表現は対象外となっており、現時点では顔のみが対象で、声などその他の個人識別情報は含まれない点は留意が必要だ。ユーザーはプログラムからいつでも退会でき、登録データの削除も依頼できる。 段階的な拡大の経緯 YouTubeはこの機能を段階的に展開してきた： コンテンツクリエイターへの試験提供 政府関係者・政治家・ジャーナリストへの拡大 エンターテインメント業界への拡大 今回：18歳以上の全ユーザーへの開放 クリエイター向けフォーラムで発表されたが、YouTubeの広報担当者は「YouTubeに10年間投稿しているクリエイターも始めたばかりの人も、同じレベルの保護が受けられるようにする」と述べており、参加に特別な条件は設けないとしている。 なぜこれが重要か ディープフェイクの問題はこれまで主にセレブリティや政治家に注目されがちだったが、実際には一般人を標的にした事例も急増している。海外ではクラスメートが同級生のディープフェイク画像を作成・拡散する事件が社会問題となっており、日本においても同様のリスクは無視できない。 特に10代・20代の若者にとって、顔画像の悪用は既に身近な脅威だ。プラットフォームが受動的な「違反報告を待つ」姿勢から、ユーザーが能動的に監視できる仕組みを提供する方向へ転換しつつあることは、業界全体の変化を示している。 実務への影響 一般ユーザー向け： YouTubeアカウントを持つ18歳以上であれば誰でも登録可能 自分の名前や顔を定期的に検索しているような人は、まずこの機能の有効化を検討すべき 登録・退会は自由なので、まず試してみることをおすすめする 企業・組織向け： 幹部・広報担当者・営業担当者など顔が公になりやすい人物には積極的に案内すべき 社員教育の中に「自分のデジタルアイデンティティを守る」という観点を加える良い機会 エンジニア・セキュリティ担当向け： 今後、同様の機能が他プラットフォームにも展開される可能性が高く、動向を注視しておく価値がある 音声合成・声のなりすましはまだ対象外である点に注意。フィッシングや詐欺対策として音声ディープフェイクへの備えは別途必要 筆者の見解 ディープフェイク対策は「誰かが守ってくれるのを待つ」フェーズから「自分で監視する仕組みを持つ」フェーズへ確実に移行しつつある。今回のYouTubeの動きはその方向性として評価できる。 ただし、実運用面での課題はまだ残る。顔のみを対象として声は含まれない点や、削除審査の透明性・速度といった問題は未知数だ。「申請できる仕組みがある」と「実際に迅速に削除される」の間には大きなギャップが生じがちなのは、これまでの事例が示している。 技術的には着実に前進していることは確かだ。一般人がセルフィーひとつでプラットフォーム全体の常時監視を持てる時代は、数年前には想像できなかった。こういったツールが当たり前になる前に、自分自身のデジタル上の顔をどう守るか——まずは自分が試しながら感覚をつかんでおくことが、エンジニアとしての正しい姿勢ではないだろうか。 出典: この記事は YouTube is expanding its AI deepfake detection tool to all adult users の内容をもとに、筆者の見解を加えて独自に執筆したものです。

カナダ・オンタリオ州の監査総長室（Office of the Auditor General of Ontario）は、州の医療機関向けに承認したAI議事録（AI Scribe）システム20製品を対象にした監査報告書を公表した。その結果、大多数の製品が処方薬の誤記入、架空情報の挿入、メンタルヘルス情報の脱落といった重大な誤りを犯していることが判明した。 監査の概要とAI Scribeとは オンタリオ州保健省が主導するAI Scribeプログラムは、医師・ナースプラクティショナーなどの医療従事者が診察内容を効率的に記録するためのAI支援ツール群だ。診察中の会話を自動的にテキスト化し、カルテや処方記録として整形する機能を持つ。 監査では、模擬診察の音声録音を各AIシステムに処理させ、生成されたノートを医療専門家が原音声と照合して精度を評価する手法が採られた。 判明した問題：数字が示す深刻さ 評価結果は、医療AIへの信頼を根底から揺るがすものだった。 20製品中12製品（60%） が患者ノートに誤った薬情報を挿入 20製品中17製品（85%） が録音内で言及されたメンタルヘルス情報の重要な詳細を脱落させ、そのうち6製品はメンタルヘルスの問題を完全または部分的に見落とし 20製品中9製品（45%） が録音に存在しない情報を架空で生成し、治療計画への提案まで捏造 具体的な架空情報の例として、「腫瘤は見つからなかった」「患者が不安を示した」といった、実際の診察では一切言及されていない記述が報告書に記載されている。医師がこれを見落とせば、誤った診断・誤投薬・治療方針の誤りに直結する。 問題の根本：評価基準の著しい歪み 監査報告書が指摘するもう一つの重大な問題は、製品選定プロセスそのものの歪みだ。 採点基準の配点を見ると、構造的な問題が浮かび上がる： 評価項目 配点 オンタリオ州内での事業拠点の有無 30% 医療ノートの精度 4% バイアス制御 2% 脅威・リスク・プライバシー評価 2% SOC 2 Type 2 準拠 4% 医療現場で最も重要なはずの「精度」が評価全体のたった4%しか占めず、一方で「州内に事業拠点があるか」という地域政策的な要素が30%を占める。精度・バイアス・セキュリティといった安全性に直結する項目を合算しても12%にも届かない。 この配点設計が、精度の低いシステムを正規承認ルートで通過させてしまった構造的な欠陥といえる。 OntarioMDの推奨と「任意レビュー」の限界 医師の技術導入を支援する組織「OntarioMD」は、AIが生成したノートを医師が手動でレビューするよう推奨している。しかし報告書は、承認されたいずれのシステムにも必須の確認・承認機能（Mandatory Attestation）が存在しないことを指摘している。 「推奨」と「必須」は天と地ほどの差がある。多忙な医療現場では、AIが生成したノートをそのまま確定してしまうリスクは十分に想定される。 実務への影響：日本のIT担当者・医療機関に伝えたいこと 医療AIを導入・検討している組織へ 精度を定量的に測定する評価プロセスを設けよ：今回の監査が示したように、精度評価ウェイトが低い調達基準は惨事を招く。「デモが良かった」「営業プレゼンが素晴らしかった」では不十分で、実際の業務と同等の条件での精度テストを義務付けること 架空情報（ハルシネーション）の検出機構を導入せよ：音声と生成テキストの突合を行う検証レイヤーや、医師が差分を確認できるUI設計が必須。「推奨」ではなく「必須」のワークフローとして組み込む SOC 2やISO 27001は「最低ライン」であって「お墨付き」ではない：セキュリティ認証は情報保護の観点から重要だが、医療AIにおける最大リスクは「情報漏洩」ではなく「誤情報の生成」であることを認識する エンジニア・システム開発者へ 医療・法律・金融のような「高リスクドメイン」でAIを活用する際のアーキテクチャ設計として、以下を検討すること： Ground Truth Linkage（根拠リンク）：生成されたテキストの各クレームを元の音声・文書に紐付け、人間が検証しやすくする Confidence Scoring：AIが確信を持って生成した部分と、推測・補完で生成した部分を明示的に区別する Mandatory Human-in-the-Loop：高リスク情報（薬名・投与量・診断名）については、必ず人間の確認ステップを経てから確定するフローを強制する 筆者の見解 今回の報告書が衝撃的なのは、AIが間違えたという事実よりも、間違える可能性の高いシステムを正規ルートで承認してしまった評価プロセスが存在したことだ。 AIが医療現場で役立つ可能性があることは疑いようがない。記録作業の負担軽減は医師の集中力を患者に向けるための重要な取り組みだ。しかし「使えるかどうか」ではなく「安全に使えるかどうか」を担保する仕組みがないまま承認・展開してしまった点は、行政の責任として重く受け止めるべきだ。 「禁止」で解決しようとすれば、医師は非公式なツールに流れるだけで状況はむしろ悪化する。正しいアプローチは「安全に使える仕組みを義務化すること」だ。必須の確認ステップ、精度の定期的な第三者監査、そして調達基準における精度ウェイトの大幅な見直し——これらを組み合わせて初めて、医療AIは信頼できるインフラになる。 日本でも医療DXの文脈でAI活用が加速しており、同種のツールの検討・導入が始まっている組織は少なくない。オンタリオ州の失敗から学べることは多い。同じ轍を踏まないための「評価基準の設計」こそが、今日本のIT担当者・医療機関が最優先で取り組むべき課題だろう。 出典: この記事は Ontario auditors find doctors’ AI note takers routinely blow basic facts の内容をもとに、筆者の見解を加えて独自に執筆したものです。 ...

Amazonが社内でAI活用の数値目標を強制した結果、一部の従業員が実務上の必要性がないにもかかわらず、ノルマを達成するためだけにAIへのタスク投入を「でっち上げ」ているという実態が、Fast Companyの報道で明らかになった。 何が起きているのか 報道によると、Amazonは従業員に対してAIツールの利用頻度を一定水準以上に引き上げるよう圧力をかけている。その結果、社員たちは「上司への報告のためだけに」AIを使うタスクをわざわざ探したり、作ったりしているという。本来ならば手動で十分に処理できる作業や、そもそも必要のない作業を、AIに投げることでメトリクスをかさ上げしているのだ。 Hacker Newsのスレッド（354件のコメント）でも、この話題は大きな反響を呼んだ。「AIの利用率を指標にすること自体が間違い」「ガバメントが生産高を指標にしたときと同じことが起きている」といった批判的なコメントが多数投稿されている。 なぜ数値目標でAI活用を測ると失敗するのか この問題の本質は「計測できるものを最大化しようとすると、計測の目的そのものが失われる」というグッドハートの法則が働いている点にある。 AI活用の本来の目的は「業務効率の向上」や「意思決定の質の改善」だ。しかし「1日に何回AIを使ったか」「AIにどれだけのタスクを投げたか」という指標で評価するようになった瞬間、社員の行動最適化の対象は「本当の業務改善」から「数値の見せかけ」へとシフトする。 これはAIの問題ではなく、マネジメントの問題だ。 日本のIT現場への影響 日本でも「AI活用推進」を経営方針に掲げる企業が急増している。しかし、多くの場合で設定されているKPIは「AIツールの導入数」「社員の利用率」「研修受講者数」といった活動量ベースの指標だ。 Amazonで起きていることは、他人事ではない。むしろ日本企業のほうがより深刻な形で同じ問題に陥るリスクがある。理由は次のとおりだ： トップダウン型の施策が好まれる: 経営層からの「全員AIを使え」という号令が、現場の実情を無視した数値目標として降りてきやすい 評価への影響を恐れる文化: 「使っていないと評価が下がる」という不安から、意味のないAI利用が横行しやすい 現場の声が届きにくい: 「このタスクにAIは不要」と言い出せない雰囲気が生まれる 実務での活用ポイント IT管理者・マネージャーが明日から見直すべき点を挙げる： 1. アウトカム指標に切り替える 「AIを何回使ったか」ではなく「AIを使ったことで何時間短縮できたか」「エラー率がどう変わったか」を測定する。利用量ではなく成果を見よ。 2. 「使わなくてよい場面」を明示する AIが有効な用途のリストと同時に、「このタスクには不向き」という用途も明示することで、社員が本当に価値ある場面でAIを使えるようになる。禁止より設計。 3. 現場からのフィードバックループを作る 「このプロセスにAIを入れたら逆に手間が増えた」という声が上がれる仕組みを作る。現場の正直な報告は、組織にとって最も価値ある情報だ。 4. パイロット → 横展開の順序を守る 全社一律導入の前に、効果が出やすい部門・業務で試験運用し、成功パターンを作ってから横展開する。 筆者の見解 このニュースを読んで感じるのは「AIの問題ではなくマネジメントの問題」という一点に尽きる。 AIツールは、「使いたいから使う」状況でこそ最大の価値を発揮する。本当に便利なツールは強制しなくても人は使う。逆に言えば、強制しなければ使われないのは、まだ「使うと明らかに楽になる体験」が設計できていないサインだ。 企業がAI活用で成果を出したいなら、まずは社員が「AIを使うと本当に楽になった」と感じる成功体験を一つ作ることが先決だ。その体験が口コミで広がれば、メトリクスなど設定しなくても利用率は自然に上がる。 「仕組みを作れる人だけいれば、回すのはAIがやる」という世界観に向かうなら、AI活用の成否を「利用回数」で測るアプローチは根本的に方向が違う。測るべきは「どれだけ人間の認知負荷が下がったか」だ。 Amazonで起きていることを笑えない。日本のIT業界にとって、このニュースは対岸の火事ではなく、今すぐ自社の取り組みを点検する契機として受け取るべきだ。 出典: この記事は Amazon workers under pressure to up their AI usage are making up tasks の内容をもとに、筆者の見解を加えて独自に執筆したものです。