ツールチップやドロップダウンメニュー、吹き出し。ボタンの近くに小さな要素をぴたりと寄り添わせる場面は、ウェブサイトのあちこちにあります。ところが、この「ある要素を別の要素のそばに置く」という一見単純な処理が、これまでのCSSでは驚くほど手間のかかる作業でした。その状況を根本から変えるアンカーポジショニング(anchor positioning)が、2026年に入って主要ブラウザすべてで使えるようになりました。単なる新プロパティの追加ではなく、位置決めという古くからの悩みに対する設計思想の転換なので、少し腰を据えて整理しておきたいと思います。

これまでの位置決めがなぜ面倒だったのか

従来のCSSで要素を任意の場所に置く手段は、position: absolute でした。ただしこれは「親要素を基準にした座標」でしか位置を決められません。ボタンの真下にメニューを出したいとき、ボタンそのものを基準にすることができず、共通の親を用意して相対位置を調整する、といった回りくどい組み立てが必要でした。

さらに厄介だったのが、画面のスクロールやウィンドウのリサイズです。ボタンが動けばメニューも追従させなければなりませんが、CSSだけではそれを追いかけられません。そこで多くの現場が JavaScript に頼りました。要素の座標を getBoundingClientRect で毎回計測し、スクロールやリサイズのたびに再計算して位置を書き換える。この処理を安定して動かすのは意外に難しく、Floating UI や Popper.js といった専用ライブラリが広く使われてきたのは、まさにこの面倒を肩代わりするためでした。

つまり「要素を別の要素のそばに置く」という日常的な要件のために、数十KBのライブラリを読み込み、イベント監視のコードを書く。この構図が長らく当たり前になっていたのです。位置ずれの不具合報告が絶えなかったり、スクロール中にメニューがわずかにガタつく、といった細かな粗さに悩まされた記憶のある制作者も多いのではないでしょうか。

アンカーポジショニングの基本的な考え方

アンカーポジショニングは、この関係を CSS だけで宣言的に記述できるようにします。仕組みは素直です。基準にしたい要素、つまり錨(いかり)となる要素に anchor-name というプロパティで名前を付けます。名前はカスタムプロパティと同じくハイフン二つで始まる文字列です。一方、寄り添わせたい側の要素には position-anchor でその名前を指定し、どの要素に結びつくかを宣言します。

あとは anchor() 関数を使って、錨のどの辺を基準に自分をどこへ置くかを書きます。たとえば錨の下端を自分の上端に合わせれば、ボタンの真下にメニューが並びます。座標を計算するのはブラウザの役目です。錨が動けば結びついた要素も自動で追従し、スクロールしてもリサイズしても関係は保たれます。JavaScript のイベント監視も、再計算のループも要りません。ひとつの錨に対して複数の要素を結びつけることもでき、たとえばボタンにツールチップと補助メニューの両方をぶら下げる、といった構成も素直に書けます。位置の面倒をブラウザに任せられると、制作者は見た目の設計そのものに集中できるようになります。

position-areaで方向をわかりやすく指定する

anchor() 関数は柔軟ですが、上下左右の細かな指定を辺ごとに書くのはやや冗長になりがちです。そこで用意されているのが position-area というプロパティです。これは錨の周囲を九つのマス目に見立て、そのどこに要素を置くかを言葉で指定できる仕組みです。「錨の上」「右下」といった感覚で配置を書けるため、コードの意図が読み取りやすくなります。

ちなみにこのプロパティは策定の途中で inset-area という名前から position-area へ改称された経緯があり、Chrome でも 129 で名称が揃いました。少し前の解説記事では古い名前で書かれている場合があるので、参照するときは注意しておくとよいでしょう。

はみ出しを自動で回避するフォールバック

位置決めで最も神経を使うのが、画面の端での挙動です。ボタンの下にメニューを出す設計でも、そのボタンが画面の下端近くにあれば、メニューが見切れてしまいます。従来はこの判定も JavaScript で書く必要がありました。空きスペースを測り、足りなければ上に開く、といった条件分岐です。

アンカーポジショニングには、この切り替えを CSS だけで完結させる仕組みが備わっています。position-try-fallbacks というプロパティに候補の配置を並べておくと、既定の位置ではみ出しが起きたときにブラウザが順番に候補を試し、収まる配置を自動で選びます。より込み入った代替案は @position-try という規則で定義できます。判定はレイアウトの過程で自動的に行われ、リサイズ監視のコードは一切必要ありません。下に空きがなければ上へ、横が詰まっていれば別の向きへ、といった気配りをブラウザが肩代わりしてくれるわけです。

Popover APIやdialogと組み合わせて真価を発揮する

アンカーポジショニングが特に力を発揮するのは、HTML の popover 属性や dialog 要素と組み合わせたときです。popover 属性は、追加のコードなしで開閉できる小さな重ね表示をブラウザ標準で実現する仕組みで、メニューやツールチップの土台に向いています。ただし popover 属性だけでは「どこに出すか」までは面倒を見てくれません。ここに位置決めを担うアンカーポジショニングを重ねることで、開閉と配置の両方を標準機能だけで組み立てられます。

しかもこの組み合わせにはアクセシビリティ上の利点もあります。popover 属性や dialog 要素と一緒にアンカーポジショニングを使うと、キーボード操作の順序、つまりフォーカスの移動をブラウザが適切に補正してくれます。錨となるボタンから開いた要素へ自然に焦点が移るため、支援技術を使う利用者にも扱いやすい構造になります。メニュー、サブメニュー、設定ダイアログといった部品を、ライブラリ抜きで組み立てられる土台が整ったことになります。

導入をどう見極めるか

気になる対応状況ですが、アンカーポジショニングは Chrome が 125 から、Safari が 18.2 から対応し、最後まで残っていた Firefox も 147 で既定有効となりました。これで主要なブラウザエンジンがすべて出そろい、2026年時点でおよそ9割の利用環境をカバーする水準に達しています。新しい制作案件であれば、実務で採用できる段階に入ったと言ってよいでしょう。

とはいえ、少し前のバージョンのブラウザを使う利用者が一定数残るサイトもあります。中小企業のサイトで慎重に進めるなら、アンカーポジショニングが効かない環境でも致命的に崩れない設計、たとえば従来の配置を素の状態として残し、対応ブラウザではより洗練された位置決めが効く、という重ね方が現実的です。位置が多少ずれても内容は読める、という状態を保っておけば安全に導入できます。

ツールチップ一つのために外部ライブラリを読み込む時代が、静かに区切りを迎えつつあります。読み込むコードが減れば表示は軽くなり、保守すべき依存も減ります。派手さはないものの、こうした基盤の更新こそ、日々サイトを預かる制作者にとって地味に効いてくる変化だと感じています。