CSSサブグリッドが制作現場の常識を変える、全ブラウザ対応で実用段階へ

つくば市のホームページ制作会社

長年にわたってCSS Grid開発者を悩ませてきた「ネストしたグリッドのアライメント問題」に、ついに根本的な解決策が登場した。CSSサブグリッド(subgrid)が2025年から2026年にかけて全ブラウザで利用可能となり、カードレイアウトや複雑な構造を持つサイトでの一貫した配置が、これまでになく簡単になっている。

CSSサブグリッドは2024年に全ブラウザサポートを達成し、2025年から2026年には97%のグローバルブラウザサポートを獲得している。具体的にはFirefox 71(2019年12月)、Safari 16.0(2022年9月)、Chrome 117(2023年9月)、Edge 117(2023年9月)でサポートされ、制作現場で安心して利用できる段階に達した。

サブグリッドが解決する現場の課題

CSS Gridにはひとつの大きな制限があった。グリッド内にグリッドをネストした場合、内側のグリッドは外側のグリッドのトラック定義と何の関係も持たない。この問題は特にカードレイアウトで顕著に現れ、各カードのヘッダー、本文、フッターの高さがそれぞれ異なってしまい、一列に並んだカードでも統一感のないレイアウトになってしまっていた。

サブグリッドはこの問題を解決する。子グリッドが親のトラック定義を採用できるため、ネストした要素も外側のグリッドに完璧に揃う。例えば、商品一覧ページで複数の商品カードを並べる際、各カードの画像、タイトル、説明文、価格ボタンが横一列で美しく揃うようになる。これまでは固定の高さ指定や複雑なJavaScriptを使っていた問題が、CSSだけでエレガントに解決される。

実装パターンと制作現場での活用

サブグリッドの基本的な実装は驚くほどシンプルだ。親要素でCSS Gridを定義し、子要素で`grid-template-rows: subgrid`または`grid-template-columns: subgrid`を指定するだけで、子要素が親のグリッドトラックを継承する。

WordPressなどのCMSから出力される大きなHTMLブロックに対してもサブグリッドは威力を発揮する。コンテンツラッパーを中央揃えにしつつ、複雑なブロックパターンを配置し、サブグリッドを使ってそれらの内容を再び内側に整列させることができる。これにより、ブログ記事内の画像や引用、表組みなどを統一感のあるレイアウトで表示できる。

HTMLがどれだけクリーンになるかも注目点だ。サブグリッドを使うことで、繰り返し使われるネストしたラッパー要素を避けることができる。従来は複数のdiv要素でレイアウトを組んでいた部分が、サブグリッドなら単一のクラスで済む場合も多い。

モバイル対応と実用的な考慮点

2026年の制作現場では、モバイルファーストの観点も重要だ。サブグリッドは主要ブラウザすべてで安定しており、ハッキーなマージン計算を使わずにSafariでもネストしたグリッド間でアイテムを整列させる最良の方法となっている。

モバイルサポートも万全で、iOS Safari 16+とChrome Android 117+で完全にサポートされている。地方の制作会社や中小企業のサイトでも、スマートフォンユーザーに配慮したレイアウトが簡単に実現できる。

2026年現在、ブラウザサポートは完全に普及しており、必要に応じて`@supports (grid-template-rows: subgrid)`を使ったプログレッシブエンハンスメントで対応できる。実際の制作現場では、フォールバック無しでサブグリッドを利用している開発者も多い。

今後のCSS Gridエコシステム

コンテナクエリと組み合わせることで、サブグリッドの可能性はさらに広がる。コンテナクエリではコンポーネントがビューポートではなく自身の幅に応じてレスポンシブ対応でき、一度作ったコンポーネントをどんな幅の場所にも配置できる。

つくばのようなテクノロジー集積地でも注目が集まっているように、サブグリッドは単なる新機能ではなく、ウェブ制作の方法論を変える技術だ。「いまやサブグリッド無しの制作は考えられない」「サブグリッドがあらゆる場所で見えてくる」という開発者の声が示すとおり、この技術は制作現場の新しいスタンダードとなりつつある。

Navigation APIが遂に実用段階へ。シングルページアプリ開発が劇的に変わる

つくば市のホームページ制作会社

2026年初頭、ウェブ制作の現場に大きな変化をもたらすNavigation APIがBaselineの「Newly Available」ステータスを獲得し、主要ブラウザ全体で利用可能になりました。これまでシングルページアプリ(SPA)の開発において、開発者が頭を悩ませてきたルーティング処理が、このAPIの登場により根本的に改善されます。

従来のHistory APIを使ったSPA開発では、複数のイベントリスナーと手動でのDOM更新を組み合わせる複雑な実装が必要でした。開発者は、リンクのクリックイベントをグローバルに監視し、preventDefault()を呼び出し、手動でhistory.pushState()を実行し、DOMを更新し、さらに別途popstateイベントを監視してブラウザの戻るボタンに対応する必要がありました。これは、まさにパズルのピースを組み合わせるような作業で、エラーが起きやすく保守性も低いものでした。

Navigation APIが解決する従来の課題

Navigation APIは、これらの複雑な処理を一本化します。単一の中央集約されたNavigateEventで、ユーザーがリンクをクリックする、フォームを送信する、戻るボタンを押す、またはコードでnavigation.navigate()を呼び出すといった、あらゆるナビゲーションを統一的に処理できるようになります。

event.intercept()関数が重要な処理を自動化します。アドレスバーと履歴スタックの更新、フォーカス管理などのアクセシビリティ機能の自動処理、戻るボタンとクリックイベントの統一的な処理など、これまで開発者が個別に実装していた機能が、APIレベルで提供されるようになりました。

具体的なコード例を見ると、その簡潔さは一目瞭然です。従来なら数十行にわたって書いていたルーティング処理が、Navigation APIでは中心となるイベントリスナー一つで済みます。navigateイベントは、同一文書内のフォーム送信も自動的にキャッチし、NavigateEvent.formDataプロパティでデータにアクセス可能になるため、フォーム処理の実装もシンプルになります。

開発体験とパフォーマンスの向上

Navigation APIの恩恵は、単にコードがシンプルになることだけではありません。このAPIはSPAの特別な要求に特化して設計されており、従来のHistory APIやwindow.locationの欠点を解決します。SPAでは、ページテンプレートは使用中も同じ状態を保ち、ユーザーが異なるページや機能を訪問する際にコンテンツが動的に書き換えられる特性があります。

従来のHistory APIでは、この動的な性質に対応するのが困難でした。しかし、Navigation APIは最初からSPAの動作パターンを想定して設計されています。現在のブラウジングコンテキストで作成され、現在のページと同じオリジンを持つ履歴エントリのみを公開し、アプリケーション専用の正確な過去の履歴エントリリストを提供します。これにより、履歴の移動が従来のHistory APIよりもはるかに堅牢になります。

また、navigateイベントによって、SPAフレームワークのルーティング機能に理想的な、すべてのページナビゲーションを一つの中央から制御できます。これはHistory APIでは困難だった、すべてのナビゲーションの検出と応答が可能になるという大きなメリットもあります。

実際の制作現場への影響

この変化は、ウェブ制作の現場にどのような影響をもたらすでしょうか。まず、SPAフレームワークの選定において、Navigation API対応が重要な判断基準になります。React、Vue.js、Angularなどの主要フレームワークは、すでにこのAPIを活用したルーティングソリューションの開発を進めており、2026年後半には多くのプロジェクトで恩恵を受けることになるでしょう。

中小企業や地方の制作会社にとっても、これは朗報です。複雑なルーティングロジックに頭を悩ませることなく、より直感的でメンテナンスしやすいSPAを構築できるようになります。特に、既存のサイトをSPA化するリニューアル案件では、Navigation APIの恩恵を実感しやすいはずです。

バグの発生しやすい複数のイベントハンドリングから解放されることで、開発者はより本質的な機能開発に集中できます。また、アクセシビリティ対応が自動化される点も、制作現場にとって大きなメリットです。フォーカス管理などの細かな配慮が、API側で処理されることで、品質の高いアプリケーションをより効率的に構築できるようになります。

2026年のウェブ制作を見据えた準備

Navigation APIのBaseline入りは、ウェブ制作技術の標準化が進む大きな流れの一部です。同時期に、ビュートランジション用の:active-view-transition CSSセレクタもBaseline入りしており、開発者がドキュメントのルート要素を、ビュートランジションの進行中に限定してスタイル設定できるようになっています。これは、トランジションオーバーレイの背景色変更や、特定のレイヤーのz-index調整など、よりスムーズな視覚効果の実現に役立ちます。

また、Service Workerでも、すべての主要ブラウザエンジンでJavaScriptモジュールがサポートされ、navigator.serviceWorker.register()でtype: ‘module’オプションを設定することで、標準的なimport/export文を利用できるようになっています。

これらの技術進歩は相互に関連しており、より統合された開発体験を提供します。Navigation APIでスムーズなページ遷移を実現し、ビュートランジションで視覚的な連続性を保ち、モジュール対応Service Workerでオフライン対応を強化するといった組み合わせが、標準的な実装パターンになっていくでしょう。つくばのような地方都市の制作現場でも、これらの最新技術を活用することで、大手制作会社に劣らない品質のウェブアプリケーションを提供できる時代が到来しています。

Interop 2026で加速する新しいCSS機能、主要ブラウザが統一歩調でウェブ制作を変える

つくば市のホームページ制作会社

ブラウザ間でのCSS機能の実装差に悩まされることがもうすぐ終わりそうだ。Interop 2026が今年もスタートし、Google、Igalia、Microsoft、Mozillaが5年連続で協力してウェブ技術の一貫性向上に取り組む。今回は20の重点分野をカバーする野心的な内容で、15が新規、5が前年からの継続となっている。

Interop Projectは主要ブラウザエンジンを集めて同じ年に同じ機能群を改善することで、各機能が正式なウェブ標準と完全に整合するかどうかを判定している。これによりウェブ制作者は実装の違いを気にせず、より信頼できるプラットフォーム上で開発できるようになる。

CSS機能の実用化が一気に進む

今年の目玉は、長らく「対応待ち」だった強力なCSS機能群の実用化だ。Anchor Positioningは前年から継続で、要素同士を相対的に配置できる強力なレイアウト機能として仕様の明確化とテスト修正に注力する。これによりツールチップやポップアップの配置が、JavaScriptを使わずCSSだけで正確に制御可能になる。

CSS attr()関数の拡張版も注目で、HTML属性の値をCSS内で直接活用し、型変換もサポートして属性値を色や長さ、角度などのデータ型として利用可能になる。構造データと視覚表現の橋渡しが、JavaScriptなしで実現できる画期的な機能だ。

contrast-color()関数は指定した前景色や背景色に対してコントラストが保証される色を自動選択し、クロスドキュメント間でのView Transitionsも含まれる。さらにzoom CSSプロパティも継続項目として、要素のサイズをスケールしページレイアウトに影響を与える機能の標準化が進む。

Container Style QueriesやScroll-Driven Animationsといった機能も含まれ、これらによりJavaScriptに頼らずスムーズで魅力的な体験が作れるようになる。特にスクロール連動アニメーションは、パフォーマンスの良いインタラクションをCSSだけで実現する強力なツールだ。

地方の制作現場でも、これらの機能統一により「このブラウザでは動かない」という問題が大幅に減ることが期待される。複雑なフォールバックコードを書く手間が省け、デザインの表現力向上に集中できる環境が整いつつある。進捗はInterop 2026 dashboardで追跡可能なので、実用化のタイミングを見極めて新機能を取り入れていけるだろう。

CSS Anchor Positioningが実用段階へ、JavaScriptライブラリからの卒業が現実的に

つくば市のホームページ制作会社

ツールチップやドロップダウンメニューの位置調整を、Pure CSSだけで実現する時代がついに到来している。2026年1月以降、CSS Anchor Positioningが最新のデバイスとブラウザで動作するようになり、これまでPopper.jsやFloating UIといったJavaScriptライブラリに依存していた制作現場にとって、新しい選択肢が広がっている。

ブラウザサポートが急速に拡大

CSS Anchor Positioningの最大の変化は、ブラウザサポートの進展だ。2025年9月にSafari 26でアンカーポジショニングがリリースされ、主要ブラウザ3社のうち2社がサポートする状況となった。FirefoxについてもNightly版でのテスト進展が印象的で、まもなく到着予定とされている。

これまでJavaScriptで複雑性とパフォーマンス問題を抱えていた実装が、CSS(とHTML)で宣言的に実現できるようになった意味は大きい。特に中小企業のウェブサイトでは、外部ライブラリへの依存を減らしつつ、パフォーマンスを向上させられる可能性がある。

基本的な仕組みと実装方法

CSS Anchor Positioningは、要素同士を紐づけて、アンカー要素のサイズと位置を基準に、アンカー配置要素のサイズと位置を設定できる機能を提供する。

基本的な実装は2ステップだ。まずアンカーとなる要素にanchor-nameプロパティでダッシュ付きの識別子を設定し、次に配置したい要素でposition-anchorプロパティを使ってアンカー名を指定する。

anchor()関数をinsetプロパティ値で使用することで、関連するアンカー要素のエッジ位置を基準とした長さ値を取得できる仕組みになっている。これまでのような座標計算をJavaScriptで行う必要がなくなり、ブラウザが自動的に位置を調整してくれる。

フォールバック機能と実用的な配慮

CSS Anchor Positioningの優れた点は、複数の代替位置をCSS単体で指定できる仕組みを提供していることだ。例えばツールチップがデフォルト位置で画面外にはみ出しそうな場合、ブラウザが自動的に別の提案位置で表示を試すか、必要に応じて完全に隠すかを選択できる。

ただし現在のブラウザ実装には課題もある。SafariとChromeで、配置要素が包含ブロックに対してどう調整されるかの動作が異なっている状況があり、実際のプロジェクトでは動作確認が重要になる。

またポップオーバー要素と組み合わせる場合、position-areaが設定されていればmargin: autoが無効化される仕様変更により、将来的にはより使いやすくなる予定だ。

制作現場での採用判断

実用性の観点では、CSS Anchor Positioningはブラウザネイティブの解決策として、配置要素を純粋なCSSでアンカー要素に紐づけ、スペース不足時の自動フォールバック位置まで対応している点が魅力だ。

ただし導入時期については慎重な判断が必要だろう。現状ではBaselineに近づいているものの、より多くの人々が試用する中で改善点やブラウザ間の違いが発見されている段階だ。特にFirefoxサポートが本格化するまでは、重要なUI要素での採用は段階的に進めるのが現実的かもしれない。

とはいえ長年Popper.jsやFloating UIが浮動要素配置の標準だった状況を考えると、将来的にはCSS Anchor Positioningがこれらの用途の多くを置き換えていく可能性は高い。制作効率とパフォーマンス向上の両面で、この技術の動向は注目しておきたいところだ。

CSSコンテナクエリがついに実用段階に。レスポンシブの概念が変わる新しいウェブデザイン

つくば市のホームページ制作会社

従来のレスポンシブデザインといえばメディアクエリを使ったビューポート(画面幅)ベースの実装が主流でしたが、2026年現在、CSSコンテナクエリがブラウザサポート95%を超えて実用段階に入り、コンポーネントレベルでのレスポンシブデザインという新しい概念が現場に浸透しています。これまでのような「画面幅が何px以下なら」ではなく、「コンポーネントを囲む親要素の幅が何px以下なら」という条件で、より柔軟で再利用しやすいレスポンシブ要素を作れるようになりました。

コンテナクエリが解決する根本的な問題

メディアクエリの最大の制約は、コンポーネントがどんな文脈で使われるかを知らないことでした。コンポーネントは親コンテナがどのくらいのスペースを持っているかしか知らず、ビューポートのサイズは関係ありません。コンテナクエリは、コンテナのサイズに基づいてスタイルを定義することで、コンポーネントを真に移植可能にします。

たとえば、カードコンポーネントをメインコンテンツエリアで使う場合とサイドバーで使う場合、従来は異なるCSSクラスを作るか、JavaScriptで制御する必要がありました。2026年では、同じCSSクラスのカードコンポーネントが、フルワイドヒーローレイアウトでもサイドバーの小さなサムネイルでも自動的に適応します。

ブラウザサポート状況と実装の現状

サイズコンテナクエリは、Chrome 105+、Firefox 110+、Safari 16+、Edge 105+でサポートされ、2026年時点で95%以上のグローバルカバレッジを実現しています。一方で、スタイルクエリ(@container style())は、Chrome 111+とEdge 111+のみで、FirefoxとSafariはまだ開発中です。

カスタムプロパティを条件とするコンテナスタイルクエリについては、Firefox側の対応次第で、2026年中には実用的になる見込みが高いとされています。実用性を重視するなら、当面はサイズクエリを中心に実装を進めるのが賢明でしょう。

現場で使えるコンテナクエリの基本実装

コンテナクエリの基本構文は、まず親要素にcontainment contextを設定することから始まります:

`.card-container { container: card / inline-size; }` のようにコンテナタイプを `inline-size` に設定することで、親の横方向(英語のような左から右への言語では幅)をクエリできます。続いて子要素に対して `@container (max-width: 400px) { .card-child { grid-template-columns: 1fr; } }` のように条件付きスタイルを適用します。

2026年時点で、:has()疑似クラスも全主要ブラウザで100%サポートされ、プロダクション環境で安全に使える標準ツールとなりました。これにより、コンテナクエリと組み合わせて、より複雑な条件分岐をCSSだけで実現できます。

メディアクエリからの移行戦略

コンテナクエリは既存のメディアクエリを完全に置き換えるものではありません。ページレベルのレイアウト決定(グリッドカラム、サイドバー表示、ナビゲーションスタイル)にはメディアクエリを使い、コンポーネントレベルのレイアウト決定(カードレイアウト、ウィジェット密度、テキスト折り返し)にはコンテナクエリを使うという使い分けが重要です。

移行は段階的に進めます。複数のレイアウトコンテキストで使われるコンポーネント(カード、ウィジェット、ナビゲーション)を特定し、それらの親ラッパーに `container-type: inline-size` を追加します。各コンポーネントの @media ルールを @container ルールに変換し、ブレイクポイント値を調整します(コンテナ幅はビューポート幅より小さくなるため)。

古いブラウザへの配慮として、@supports (container-type: inline-size) を使ってメディアクエリフォールバックを提供し、@supportsでプログレッシブエンハンスメントを行うことで、古いブラウザでもメディアクエリに適切にフォールバックします。

中小企業のウェブ制作現場では、まず最もよく再利用されるコンポーネントから移行を始め、固定幅コンテキストでのみ使用されるものは後回しにするという現実的なアプローチが効果的です。2026年のモダンCSSは、クライアントサイドJavaScriptなしで、真にモジュラーで弾力性があり、高パフォーマンスなUIを構築できる段階に達しています。

OpenAIのCodexが「コード書き」卒業。いきなりMacを操作してアプリ間で仕事してしまう

つくば市のホームページ制作会社

4月16日、OpenAIがCodexの大型アップデートを発表しました。今度の更新はタイトルからして遊び心たっぷりで「Codex for (almost) everything」。でも内容は真面目そのもの、開発者の働き方を根本から変えてしまいそうな機能が詰まっています。

いきなりMac画面に現れて作業を代行する

一番驚いたのがバックグラウンドでのコンピュータ操作機能。Codexが自分専用のマウスカーソルを持って、あなたが他のアプリで作業している間に勝手にクリック・タイプして複数のアプリを行き来する。しかも複数のエージェントが並行稼働するから、あなたの作業を邪魔することもない。

これまでのAIコーディングツールって「コード補完がうまい」「バグ修正が得意」みたいな局所的な手伝いだったじゃないですか。でもCodexは違う方向に進んでいる。開発者が日常的にやっている「ブラウザでドキュメント調べて、スクリーンショット撮って、別のアプリに貼り付けて…」みたいな面倒な流れ作業を、丸ごと自動化してくれる方向に向かってる。

「コード生成ツール」から「開発環境そのもの」に

OpenAIは明らかにCodexのポジションを変えにきました。プレスリリースを読んでいて気づいたのは、もう「コードを書くための補助ツール」じゃなくて「開発作業が起きる場所」になろうとしてること。

実際、既存ユーザーの50%がコーディング以外のタスクにCodexを使っていたという数字も発表されてます。だったら最初から全部対応してしまえ、というのがOpenAIの判断みたい。

新機能の一覧を見ると、その狙いがよく分かります:

  • ウェブブラウザをアプリ内に統合(プロトタイピング→コメント→修正のサイクルを高速化)
  • 画像生成機能の追加
  • 過去の操作を学習して記憶する機能
  • SSH経由でリモート開発環境への接続
  • GitHub のPR レビュー機能強化
  • 90以上の新しいプラグイン

これ全部、「開発者の一日の流れ」に沿って設計されてる。朝イチでPRをチェックして、ブラウザで仕様を確認して、リモート環境で作業して、テストして、また別のツールに移る…みたいな。

現場で使うなら「権限管理」が最重要

ここまで強力になると、セキュリティ面の配慮は必須です。RESONIXでクライアントのシステム構築をやってきた経験から言うと、AI エージェントに何でもやらせるのは危険すぎる。

記事によると、最低権限の原則で運用して、必要最小限のアクセス権だけ与えるのが鉄則。それと、AIが何を変更したか必ずログを残すこと。「便利だから」で野放しにすると、後で取り返しのつかないことになりかねません。

特に中小企業の現場では、「人手が足りないからAIにお任せ」という発想になりがちですが、むしろ最初は限定的な範囲で試運転して、徐々に範囲を広げるアプローチが安全でしょう。

競争の軸が「モデルの賢さ」から「統合の滑らかさ」へ

今回のアップデートで面白いのは、OpenAIがAI開発ツールの競争軸を変えようとしてることです。もう「どのモデルが一番賢いか」じゃなくて「どの環境が一番ストレスなく作業を続けられるか」で勝負しようとしている。

これは正しい戦略だと思います。実際の開発現場で本当に辛いのって、コード自体を書くことじゃなくて、その前後の雑多な作業なんですよね。イシューを読んで、仕様を確認して、環境を準備して、テストして、レビューして…。

Codexがその全工程をシームレスに繋げてくれるなら、開発者の生産性は確実に上がるはず。ただし、うまく使いこなせるかどうかは導入する会社次第。整理されたワークフローを持っている組織ほど効果が大きく、逆にぐちゃぐちゃな環境だとAIも混乱してしまう可能性が高いです。

月額500ドルという価格設定も、個人開発者ではなく組織での導入を想定した本気度の表れでしょう。これから半年くらいで、開発チームの働き方が大きく変わってきそうな予感がします。

AIが書いたフィッシング詐欺にもう騙される。中小企業が2026年に直面する現実

つくば市のホームページ制作会社

つくばの中小企業の皆さん、正直に言います。もうフィッシング詐欺が見抜けない時代になりました。

攻撃者がAIを使ってより説得力のあるフィッシングメッセージを作成し、文体を模倣し、同僚や取引先、幹部から来たように見える現実的な偽の要求を作成しているんです。文法の間違いや不自然な表現といった詐欺の古い兆候は、以前ほど信頼できなくなったのが実情です。

もう「文法がおかしいから詐欺」は通用しない

これまでなら「あ、日本語変だし怪しいな」って気づけた詐欺メールも、今はAIが完璧な日本語で書いてくる。RESONIXが長年やってきた中で、つくばの会社でも「完全に本物だと思った」って声が実際に出てるんですよ。

小規模企業にとって、これはメールセキュリティとスタッフの意識向上において重要度を高めている。トレーニングは依然として重要だが、現在の脅威に合わせる必要があるわけです。つまり、従業員教育をアップデートしないとまずいってこと。

小さい会社ほど狙われやすい理由

5人のオフィスは500人の会社と同じくらい攻撃者にとって魅力的で、時にはそれ以上。小規模な組織はしばしば迅速に動き、つぎはぎのツールに依存し、自分たちは小さすぎて標的にならないと思い込んでいる。

この思い込み、本当に危険です。うちのクライアントでも「うちなんて誰も狙わないでしょ」って言う経営者がいるけど、それこそが攻撃者の思うツボなんです。

アイデンティティ窃盗リソースセンターによると、中小企業の81%が過去1年間にセキュリティ侵害および/またはデータ侵害を受けたという数字が全てを物語っています。これ、10社中8社ですからね。

費用対効果を考えた現実的な対策

とはいえ、つくばの中小企業に大手企業と同じセキュリティ対策をしろとは言いません。現実的に考えましょう。

フォーチュン500のセキュリティチームと同等になることは非現実的かもしれないが、基本的な脆弱性を強化することで曲線の先を行き、攻撃者にとってのターゲットになりにくくすることができるんです。

具体的には:

  • 二要素認証の導入 – もう必須です
  • 従業員の個別アカウント作成 – 各従業員は個別のアカウントを持つべきで、管理者権限は制限すべき
  • 退職者のアカウント即座削除 – 退職するスタッフは退職した日のうちに削除すべき

解決策は華やかではないが効果的なものばかり。派手なツールを買う前に、基本をきっちり固めることから始めませんか?

現場で見えてきた変化

実際にRESONIXで支援してきた中で感じるのは、現在のサイバーセキュリティトレンドは一つの大きなツールを購入することよりも、日常的なリスクを減らすことに関するもので、これをうまくやっている企業はセキュリティを別のプロジェクトとしてではなく、仕事を進める方法の一部として扱っているということ。

つまり、セキュリティって特別なものじゃなくて、普段の業務に組み込んじゃうのが一番ってこと。経理担当者には「こんな請求書詐欺があるよ」、営業担当者には「SNS経由でこんな攻撃があるよ」みたいに、実際のワークフローに結び付いた職種別の訓練が効果的です。

承認フローが命綱になる

支払い、アカウント変更、機密ファイルアクセスの承認ワークフローは、信頼できる電子メールだけではもはや信頼できないため、これまで以上に重要になりました。

どんなに完璧に見えるメールでも、お金が動く案件は必ず電話や対面で確認する。この一手間が会社を守ります。手間に感じるかもしれないけど、1回騙されたら失う金額を考えれば安いもんです。

つくば市の中小企業なら、まずは基本的なセキュリティ対策から。大げさなシステムじゃなくても、日々の業務の中でできることから始めてみてください。気になることがあれば、RESONIXでも相談に乗りますよ。

【NO.145】バイバイ、チャッピー

バイバイ、チャッピー

世界的なChat GPTの解約ムーブが起きています。

AIで世界を変えてくれたのは、Chat GPTが始まりでしたので
これ以上ないくらい感謝はしています。

だがしかしっ!今回は話しが違う。

わたしは「倫理」を大切にしてます。
なので今回は、惜しみもなく「バイバイ、チャッピー!」とお別れしました。

みなさんの中でも、今回の件でChat GPTを解約された人は多いのではないでしょうか?

「え?何が起きたの?」
という方もいると思うので、何が起きたかを登場人物と時系列順に簡単に説明させて頂きます。

まず登場人物
・ウォール・ストリート・ジャーナル、ご存じ老舗の報道機関です。
・Axios(アクシオス)、新興の政治専門のデジタルメディアです。
・Anthropic(アンソロピック)、Claude(クロード)AIを開発している企業。CEOはダリル・アモデイ
・OPenAI、ご存じChat GPTを開発している企業。CEOはサム・アルトマン
・国防総省(ペンタゴン)、現在の国防長官はピート・ヘグセス
・パランティア、軍事・安全保障向けの技術やシステムを提供する民間企業

2026年2月13日
ウォール・ストリート・ジャーナルが、軍がパランティアのプラットフォーム経由でClaudeを使用し、ベネズエラのマドゥロ大統領拘束作戦を行ったと報じました。
その後、Axios(アクシオス)が、「作戦の準備段階だけでなく、実際の作戦行動中にもClaudeが使用された」と追って報じました。

そして、Axiosが、国防総省の匿名高官の話として、「Anthropicがパランティアの幹部に対し、マドゥロ拘束作戦におけるClaudeの使用について問い合わせを行った」と報道。
民間企業が軍の機密作戦を「監査」しようとしているという見方は国防総省側の激しい怒りを買った。

ここまでの経緯を簡単にいうと
マドゥロ大統領拘束作戦にClaudeが使われたと報道されて、アモデイがパランティアに「あの報道まじすか?」と質問したら、ペンタゴンが「はぁ?民間が機密作戦に口出してんじゃねえよ」って激オコしたってことです。

2026年2月24日
ヘグセス国防長官がAnthropicのダリオ・アモデイCEOと会談し、2月27日の午後5時1分を期限として、軍事利用の制限を撤廃するよう最後通告を突きつけました。要求に応じない場合は、契約打ち切り、国防生産法(DPA)の発動、および「サプライチェーンリスク」への指定を行うと脅迫しました。

激オコの国防長官が、ペンタゴンにアモデイCEOを呼び出して
Claudeの制限を解除して、すべての機能を軍事的に使えるようにしろ、さもないとサプライチェーンリスク、つまり敵国のIT企業と同等のブラックリスト入りさせるぞ!と脅迫したわけです。

2026年2月26日
アモデイCEOは声明を発表し、「良心に従い要求には応じられない」として、大量監視と自律型兵器への使用禁止というセーフガードを維持する姿勢を明確にして、国防総省の要求を公式に拒否しました。

つまり、ペンタゴンの脅迫に対して「やだっ!」って答えたわけです(笑)

2026年2月26日
Anthropicが国防総省の要求を公式に拒否した同日夜、アルトマン氏は従業員宛てに社内メモを送付しました。メモの中でアルトマン氏は、「事の経緯はどうであれ、これはもはやAnthropicと戦争省(国防総省)だけの問題ではない。これは業界全体の問題であり、私たちの立場を明確にすることが重要だ」と述べ、アモデイ氏を支持する態度を明確にしました。また、大量監視や自律型兵器の禁止といったAnthropicの「超えてはならない一線(レッドライン)」をOpenAIも共有しているとし、事態の沈静化に協力したいと記していました。

ここが、結構重要なんです。
アモデイは元Open AIの人間で、アルトマンとの思想の違いから別企業であるAnthropicを立ち上げ、バチバチにやり合ってるライバル企業で、バチバチに仲が悪いんです。だけど、この件に対してはアルトマンは擁護に回ったのです。
なので、この時は世間はアルトマンを称賛しました。

2026年2月27日
期限の数時間前、トランプ大統領がSNSでアンソロピックを「急進左派のAI企業」と非難し、連邦政府のすべての機関に対してAnthropicの技術の使用を直ちに停止(6ヶ月の段階的移行期間を設定)するよう指示しました。
期限経過後、ヘグセス国防長官はアンソロピックを国家安全保障上の「サプライチェーンリスク」に指定しました。

期限前にアモデイが「やだっ!」って答えましたからね。
期限前にトランプ大統領もオコでした。
結果、Anthropicがブラックリスト入り。

で、ここがビックリ。
同日の27日
ライバル企業であるOpenAIが、国防総省との間で機密システムへのAI導入契約で合意したと発表しました。OpenAIのサム・アルトマンCEOは、Anthropicと同様の「大量監視と自律型兵器の禁止」という原則を法律やポリシーの枠内で合意に盛り込んだと主張しています。

これが世間を「はぁああぁぁあああぁぁああああぁぁあああぁあああ!」とさせたのです。

アルトマン、君は昨晩ライバルであるアモデイを擁護してたよね?
だからみんな称賛したんだよね?
なのに裏で交渉進めてたの?
Anthropicの主張と同じ内容で契約したってどういうこと?
なんでAnthropicはダメで、OpenAIなら同じ条件をペンタゴンが飲むの?それきな臭い!
と、なったわけです。

ブラックリスト入りさせといて、軍はその後のイランへの攻撃にClaude使ってるって、報道されて。

結果、Chat GPTの解約ムーブが始まりました。
アルトマンは解約を阻止したいので
その後、いくつもアップデートやサービスを公開。

やらしいんだよね動きが。
美しくない。

みなさんは、今回の事どう思いました?

サム・アルトマンの功績は、確かに素晴らしいと思うんですよ。
今の世界的なAIの進化は、サム・アルトマンのおかげと言っても間違いないと思いますからね。
だけど、今回の件はわたしはドン引きしました。

あと、今回の件でビックリしたのは
元々、軍事利用にAIの制限があったんだなということ。
わたしは既に制限なんかないと思ってました。

AIはさまざまなリスクも伴うものなので
Anthropicみたいな企業にアモデイのようなトップがいることは
わたしは安心できるなと思いました。

Just be hopeful.

【NO.144】英語の壁、AIでぶっ壊せる。
「わかりやすい日本語にして」のひと言が最強だった件

1日で人生を変える方法 「わかりやすい日本語訳版」

2025年ももう2ヶ月が過ぎました。
年始に「今年こそは○○するぞ」と目標を立てた人、正直に言ってほしい。今も続いてます?
安心してください、別に責めてるわけじゃない。むしろ今日は、そんなあなたにピッタリの話を持ってきました。

1月中旬、Xでやたらシェアされている投稿を見かけた。
海外のクリエイター、ダン・コーという人物が書いた英語のテキストで、テーマは「1日で人生を変える方法」。

今年の目標が続かない人に刺さる内容らしく、かなり拡散されていた。気になったので読んでみることにした。
ただ、当然ながら英語だ。

ブラウザの翻訳機能で日本語にしてみたけど、正直よくわからない。心理学の話やアドラーの引用が出てくるし、抽象的な概念が多い。直訳された日本語を読んでも「なんとなくわかるけど、腹落ちしない」という状態になる。
そこで試しに、このテキストをAIに貼り付けて「わかりやすい日本語に翻訳して」と頼んでみた。

これが驚くほど違った。
同じ内容なのに、すっと頭に入ってくる。AIは直訳ではなく、意味を理解した上で日本語として自然な文章に組み替えてくれる。文脈を読んで、省略されている主語を補い、日本人が読んで「なるほど」と思える表現に変えてくれる。
たったひと言「わかりやすい日本語にして」と付け加えるだけで、理解度がまるで変わる。

おかげでこの投稿の内容をしっかり理解できた。そして読んでみたら、これがかなり面白い。
せっかくなので、この内容を動画にしてみました。
動画は上に埋め込んでます。

数年前まで、英語圏の最新情報をリアルタイムで理解するには、相当な英語力が必要だった。留学経験があるとか、英語で仕事をしているとか、そういう人だけが持てる「情報のアドバンテージ」があった。
今はもう違う。AIに「わかりやすい日本語にして」と言えるかどうか。知っているか、知らないか。ただそれだけの差になりつつある。

英語の論文だって、技術的な知識だって、海外の料理レシピだって。
今まで「英語だから」と敬遠していた情報が、たったひと言で手に届くようになった。
知りたいことがあるのに、言語の壁で諦めていた時代は終わりつつある。世界中の知識はあなたのすぐそばにある。
また世界が一歩近づきました。

Just be hopeful.

【NO.143】たぶん、OpenAIの噂のデバイスはこれ。「画面のないAI」が目指す未来

OpenAIとLoveFromが開発中と噂される
コードネーム「Gumdrop」と、コードネーム「Sweetpea」。
今日は、このデバイスが目指してるんじゃないかと思う未来についてお話します。

今のところの有力な情報としては
「画面がない」

なるほど、謎に満ちてていいですね。
そうなると、わたしの予測としてはこれです。

ジョニー・アイブ氏がデザインするので、形状はもっとスタイリッシュになると思います。
最初からこれが完成するのは難しいと思いますが、これを目標にしてるんじゃないかと願望に近い予測をしてます。

先ほどの、画像でピンと来た人もいると思います。
そうです。
映画「『her/世界でひとつの彼女』に出てくる人工知能型OSの「OS1」です。
経口補水液のOS-1じゃないですよ。

この映画を見た人は、ご存知だと思いますが
このOS1のサマンサを声で演技するのはスカーレット・ヨハンソンです。

ここまで話すと、なるほどと思う人も多いと思います。

話は2年前に遡ります。
2024年5月、OpenAIが発表した「GPT-4o」のデモで使用された音声のひとつ「Sky(スカイ)」が
映画『her/世界でひとつの彼女』のスカーレット・ヨハンソンの声に酷似しているとして、大きな騒動になりました。

この騒動の主な経緯はこんな感じです。

  1. 公開と同時に「似ている」と話題に
    OpenAIがGPT-4oのリアルタイム音声対話をデモした際、その声のトーンや話し方が『her』のサマンサ(スカーレット・ヨハンソン)を彷彿とさせると、SNSを中心に大きな話題となりました。
  2. サム・アルトマン氏のツイート
    さらに騒ぎを大きくしたのが、OpenAIのCEOサム・アルトマン氏による投稿です。彼は発表の際、X(旧Twitter)に一言だけ「her」とポストしました。これが「映画を意識して作った」という決定的な証拠と見なされました。
  3. スカーレット・ヨハンソン氏による抗議声明
    その後、スカーレット・ヨハンソン氏本人が弁護士を通じて声明を発表し、以下の事実が明らかになりました。
    OpenAIからの出演依頼: 発表の約9ヶ月前、サム・アルトマン氏から「システムの声を務めてほしい」と直接依頼があったが、彼女は個人的な理由で辞退していた。

直前の再依頼: 発表の2日前にも再度依頼があったが、返事をする前に音声が公開された。

本人の怒り: 彼女は「あまりに似すぎていて、親しい友人やニュースメディアですら区別がつかないほどだったと、怒りとショックを感じる」と述べました。

  1. OpenAIの対応
    OpenAIは最終的に、Skyの音声を削除しました。 ただし、OpenAI側は「Skyの声は別のプロの声優のものであり、スカーレットを模倣したものではない」と主張し、意図的なコピーについては否定しています。

と、まぁこんなことがあったわけです。

スカーレット・ヨハンソン氏と和解したかどうかは分かりません。
出来れば和解していて欲しい(笑)
ほんと魅力的な声ですからね。
日本語版は、ぜひ林原めぐみさんが担当してほしいです。

サム・アルトマン氏が「her」とポストしたわけで
映画『her/世界でひとつの彼女』は、まず見ていて意識してるわけで

一回の失敗で、諦めるとは思えないのですよ。
発表の9ヶ月前に依頼があったということは、2023年8月頃ですよね。
現在のサム・アルトマン氏の認知度と力は、当時とは桁外れですからね。
しかも今回は、ジョニー・アイブ氏もタッグ組んでます。

コードネーム「Gumdrop」はペン型という噂もあります。
ペン型であってもいいけど、書ける必要はわたしはあまり感じないんですよね?
どうなんだろ?

もうひとつの最近の噂は、コードネーム「Sweetpea」
これはイヤホン型と噂があります。もしかしたら、こちらの方がOS1には近いかも。

個人的には、形状はどんなでもいいんですが
人工知能型OSが欲しいです。

あるんじゃないかなぁ〜(願望)
OS1みたいなデバイス。

劇中の「恋は、公認の狂気だ」ってセリフが好きです。
まだ映画を見られてない方、ぜひ。

Just be hopeful.