Generative-Ai

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

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

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

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

SonyがXperia 1 XIIIに搭載した「AI Camera Assistant」が公開直後から批判を集め、同社は機能の仕組みを改めて説明する事態になった。しかし新たに投稿されたサンプル写真も品質面の課題を抱えており、議論は収まっていない。 AI Camera Assistantの仕組み AI Camera Assistantは、カメラが捉えた被写体・ライティング・被写界深度を分析し、露出・色調・背景ぼかしの調整案を4択で提示する機能だ。Sonyが強調するのは「写真を自動編集するのではなく、あくまでも提案を行う」という点で、最終的な選択はユーザーに委ねられる。 製品動画では「最も映える角度を提案する」機能も紹介されているが、実際に示されているのは「ズームインする」という提案のみ。構図そのものを変える提案とは異なり、説明と内容の間にギャップがある。 サンプル写真が示す現実 5月14日にSonyがXへ投稿した最初のサンプルは、白飛びや露出オーバーが顕著で広く批判された。翌日に投稿し直したサンプルは幾分改善されたものの、4択のいずれもオリジナルより劣る結果となっている。 提案1: 彩度が過剰で不自然な仕上がり 提案2: フラットで処理過多な印象 提案3: 料理が合成写真のように浮いて見える 提案4: コントラストが極端に高すぎる The Vergeの評価は「現時点ではAI Camera Assistantの提案は無視するのが最善」というものだ。 実務への影響 スマートフォンカメラのAI機能は、各社が競う主要な差別化要素になっている。日本市場では特にXperiaシリーズが「カメラ品質重視層」から支持されてきた歴史がある。AI Camera Assistantが実際の写真体験を向上させるかどうかは、今後のソフトウェアアップデートにかかっているといえる。 UI設計の観点でも興味深い事例だ。「4択を提示してユーザーに選ばせる」設計は、一見ユーザーコントロールを重視しているように見える。しかし提案の品質が低い場合、ユーザーはオリジナルと4択を毎回比較するという余計な判断コストを負うことになる。 筆者の見解 AIを冠した機能が登場するたびに自分が問うのは、「この機能は実際にユーザーの課題を解決しているか」という一点だ。 AI Camera Assistantの設計思想——提案してユーザーが選ぶ——は、一つの合理的なアプローチではある。しかし提案の品質が伴わなければ、認知負荷を下げるどころか増やす本末転倒の構造になってしまう。今回のサンプルはまさにその状態だ。 Sonyには世界トップクラスの光学技術とイメージセンサー技術がある。その強固な基盤の上にAIを乗せるのであれば、「AI搭載」の訴求より前に、使って良かったと感じられる体験品質を確立してほしい。リリース後にSNSで説明対応に追われる状況は、本来であれば発売前のQAプロセスで解消されているべきものだ。 AI機能の真価は「搭載しているか」ではなく「使って本当に良くなるか」で決まる。今後のアップデートで、この機能が実力を発揮してくれることを期待している。 出典: この記事は Sony tries to explain that its AI Camera Assistant doesn’t suck の内容をもとに、筆者の見解を加えて独自に執筆したものです。

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 の内容をもとに、筆者の見解を加えて独自に執筆したものです。