こんにちは、ソフトクリエイトでエンジニアをしているＫです。 以前、 こちらのブログ で「AI Challenge Day」へ参加した感想を投稿した以来、久しぶりの投稿になります！ 最近は、主にAIエージェント周りの開発や検証に取り組んでいます。 はじめに

はじめに こんにちは！ KINTO開発部 KINTOシステム開発G マスターメンテナンスツール開発チーム、技術広報部兼務、Osaka Tech Lab 所属の high-g（ @high_g_engineer ）です。フロントエンドエンジニアをやっています。 以前、社内で開催しているフロントエンド勉強会について紹介しました。 https://blog.kinto-technologies.com/posts/2025-06-30-frontend-study-group/ あれから勉強会は続き、2026年10月で第91回を迎えました。 今回はその中で、2026年8月〜9月に全5回で実施した 『HTML解体新書』の輪読会 について紹介します。 正直なところ、書籍の輪読会はフロントエンド勉強会では前例がなく、とりわけ、分厚い技術書の輪読会となると、「途中で失速しがち」「ただ読み上げるだけの会になりがち」という印象があり、少しハードルを高く感じていました。 実際、私自身も前職で同じ本の輪読会を経験したとき、内容を理解しないまま読み進めるだけの会になってしまった苦い思い出があります。 ですが、今回は最後まで走り切れたうえに、参加者全員が前のめりに議論する場になりました。 この記事では、その経緯と進め方、うまくいった理由などをまとめます。 題材にした書籍 https://www.borndigital.co.jp/book/25999/ 『HTML解体新書 ―仕様から紐解く本格入門』は、HTMLの仕様（HTML Standard）をベースに、各要素の意味や使い方、アクセシビリティとの関係を丁寧に解説した書籍です。 なぜHTMLの輪読会をすることになったのか 「次に何をやるか」をみんなで話し合った 輪読会を始める直前、勉強会ではTSKaigi 2026のセッション動画をみんなで視聴していました。ただ、最近のフロントエンド勉強会はTypeScriptの型の話に寄りがちな内容になっていて、動画を見るだけの会が続いていたこともあり、「もう少し現場に寄り添った勉強会にしたい」と考えていました。 そこで7月に2回ほど時間を取り、参加者が所属する各チームで実際に起きているフロントエンドの課題をヒアリングしました。 すると、チームは違っても次のような悩みが共通して挙がりました。 デザイナーとの協業の進め方に課題がある UI / UXに関する知識をもっと伸ばしたい アクセシビリティを最終的にコードへどう落とし込むか、どう周囲を巻き込むか キーワードは「情報設計」 議論を重ねるうちに見えてきたのが、「 情報設計 」というキーワードでした。 勉強会で立てた仮説はこうです。 正しく情報設計されているUI ≒ 正しくマークアップされている ≒ Webアクセシビリティを満たしている デザイナーと協業するうえでも、アクセシビリティを満たしたコンテンツを作るうえでも、土台になるのはHTMLの正しい理解です。 「HTMLの知識を強化することが、情報設計の理解につながり、ひいてはフロントエンドの全チームに共通する課題の解決につながるかもしれない」と考え、まずは h1 〜 h6 を正しい順序で使うという基礎的なレベルから理解し直そう、という結論になりました。その教材としてうってつけだったのが『HTML解体新書』です。 いきなり始めず「本を紹介する会」を挟んだ とはいえ、この本は全352ページというなかなかの厚さです。いきなり「来週から輪読会をやります」と言うと、参加のハードルが一気に上がってしまいます。 一方で「みんなの準備が整ったらやろう」では、いつまでも始まらない可能性が高いです。 そこで、まずは すでに本を持っている人に持参してもらい、どんな本なのかを紹介する会 を一度挟みました。 この会で中身をパラパラと眺めたことで「とりあえず買って一読してみます」「今Kindleで買いました」という声が出て、その場で進め方のルールも決めることができました。 また、マネージャーの承認をもらい、東京（室町）と大阪のオフィスに1冊ずつ会社で書籍を購入できました。 ただ、ふたを開けてみると多くの参加者が自分で購入していて、「会社で買わなくても、みんな持っていたかもしれない」というくらいでした。 輪読会の進め方 ルール ルールはシンプルにしました。 参加者はできる限り事前に読んでくる（ もちろん、読めなくても大丈夫 ） 説明担当は担当箇所を事前に精読し、当日に説明する（ 説明方法はおまかせ ） 書籍は会社購入分を貸し出し可（個人での用意もOK） 「読めなくても大丈夫」と明言しておくことで、担当以外の人も気軽に参加できるようにしています。 1回（約1時間）のタイムテーブル 時間 内容 10〜30分 担当者が担当箇所をざっくり説明 20〜30分 全員で感想や気になったことを話す 3分 次回の担当決めルーレット 次回の担当は、Claude Artifactsで作ったルーレットで決めました。ちょっとしたゲーム感覚があり、「誰になるかな」と盛り上がるポイントでもありました。 範囲は「主要な節だけ」に絞った 全章を読むと長期戦になってしまうため、CHAPTER 3の要素解説から、特に業務に関わりが深い5つの節に絞りました。 回 開催日 範囲 担当 第1回 8/7 セクション 花輪さん 第2回 8/28 グルーピングコンテンツ 三上さん 第3回 9/4 テキストレベルセマンティクス 齋藤さん 第4回 9/11 フォーム その1 high-g 第5回 9/18 フォーム その2 溝口さん お盆や私の休暇で何度かスキップを挟みましたが、当初の見込みどおり5回で完走できました。 アクセシビリティの有識者が参加してくれた 今回の輪読会で大きかったのが、社内のアクセシビリティの有識者である 辻さん 、 守谷さん が参加してくれたことです。 本に書かれている内容に対して「実際のスクリーンリーダーではこう読み上げられる」「昔はこう使われていた」といった、 本の一歩先の知見 をその場で補足してもらえたことで、議論の質が大きく上がりました。 各回の様子 各回とも、担当者が本の内容をなぞるだけでなく、独自の切り口でテキストベースのまとめを作ってきてくれました。ここでは各回で印象に残ったトピックをいくつか紹介します。 第1回：セクション section / article / aside / nav といったセクショニングコンテンツや、 header / footer がランドマークになる条件などを扱いました。 印象的だったのは、書籍の刊行と同じ2022年に アウトラインアルゴリズムがHTML Standardから削除されている ことです。 https://github.com/whatwg/html/pull/7829 現在は、 section で囲んでも見出しレベルは上がらず、 h1 〜 h6 の数字で決まります。 また、「Reactアプリケーションでは、最終的にレンダリングされたHTML全体を目にする機会がほとんどありません。セクション構造が正しいことを日々の開発でどう検証すればよいか？」という、コンポーネント開発ならではの悩みも話題になりました。 第2回：グルーピングコンテンツ p 、 ul 、 ol 、 dl 、 figure 、 main など「毎日書いている要素」がテーマでしたが、担当の三上さんは意味の深い説明よりも、個人的に「そうなんだ」と感じた部分を中心にまとめてくれました。 たとえば、 p の中に ul を書くとエラーにはならず、パーサーが黙って p を閉じてしまいます。 <!-- 書いたつもりのHTML --> <p> <ul> <li>項目</li> </ul> </p> <!-- パース後のDOM --> <p></p> <ul> <li>項目</li> </ul> <p></p> その結果、 p > ul を前提にしたCSSが効かなくなったり、末尾に生える空の p で余白が増えたりします。SSR環境ではサーバーで生成したHTMLとクライアントのDOMが食い違い、hydrationエラーの原因にもなります。 ほかにも、次のような話題で盛り上がりました。 ol の番号はDOMに存在しないため、コピー＆ペーストすると消える main は hidden 属性を付けたものを含めれば、1ページに複数置ける hr は「線」ではなく、段落レベルのテーマの区切り。スクリーンリーダーでは「区切り」と読み上げられる dl の読み上げはブラウザとスクリーンリーダーの組み合わせによって差があるが、セマンティクスとして正しいなら使う価値がある この回で特に印象に残ったのが、「セマンティクス＝スクリーンリーダーのため」というチャットの発言に対する、辻さんのひと言です。 「スクリーンリーダーのため」ってのはたぶんちょっと違うな。スクリーンリーダーはHTMLの仕様に合わせて解釈する側なので。 スクリーンリーダーで思いどおりに読ませるためにコンテンツを曲げるのではなく、仕様に沿って正しくマークアップし、スクリーンリーダー側がそれを正しく解釈する。アクセシビリティを考えるうえでの順序を、改めて確認できました。 第3回：テキストレベルセマンティクス em と strong 、 small 、 s 、 time 、 ruby 、 bdi 、 br 、 wbr などを扱いました。 担当の齋藤さんからは「普段はフレームワーク上でコンポーネント単位でしかHTMLを書かないので、要素そのものを意識したことがなかった」という率直な感想があり、まさにこの輪読会の狙いどおりの気づきが共有されました。 書籍の刊行後に仕様側で変わった点も話題になりました。たとえば、書籍の時点では対応するARIAロールがなかった要素にも、WAI-ARIA 1.2ではロールが割り当てられています。 HTML要素 WAI-ARIA 1.2でのロール em emphasis strong strong del / ins deletion / insertion sub / sup subscript / superscript b / i / small / s / u generic ほかにも、 <p>H<sub>2</sub>O</p> をVoiceOverで読ませると「エイチ・ツー・オー」ではなく「エイチニオー」と読まれた、日本語にはイタリック体の文化がないので i 要素はマークアップと見た目が一致しにくい、といった実際に試してみたからこその話も出ました。 チャットでは、昔使っていたHTMLエディタの話や、ガラケーでHTMLを書いていた思い出話で世代を超えて盛り上がる一幕もありました。 第4回：フォーム その1 私の担当回です。 form 、 label 、各種 input の type 、バリデーション属性、 autocomplete などを扱いました。 特に強調したのは、 label の for 属性の落とし穴です。存在しない id を指定するとHTMLチェッカーでエラーとして検出できますが、 別の要素の id を指定してしまった場合はHTMLチェッカーでは検出できません。 ラベルをコピー＆ペーストして for を直し忘れると、コピーしたラベルまで最初の入力欄に紐づいてしまう、といった事故が起こり得ます。 これは目で見ても気づきにくい一方、スクリーンリーダーで読み上げるとすぐに分かる、という話が辻さんからありました。 そのほかにも、次のような話題が出ました。 type="hidden" は「秘密」にはならない（値は改ざんできる） pattern 属性はセキュリティのためのものではない placeholder はラベルの代わりにならない 電話番号を「ハイフンなし」と注釈して type="number" で受け取るのは避けたい KINTOのサービスには申込フォームが多いので、そのまま業務に生かせる内容だったと思います。 第5回：フォーム その2 最終回は溝口さんの担当で、 button 、 select 、 datalist 、 progress / meter 、 fieldset / legend などを扱いました。 溝口さんの切り口がとても面白く、「今はゼロからフォーム部品を手書きすることは少なく、UIライブラリを使うことがほとんど」という前提に立って、 MUI・Ant Design・Radix UIがそれぞれの要素をどう実装しているか を、書籍の内容と突き合わせてくれました。 たとえばスイッチ（Switch）コンポーネントひとつとっても、実装方針はライブラリごとに異なります。 ライブラリ Switchの実装 MUI 見た目用の span と、透明な <input type="checkbox" role="switch"> Ant Design input を使わず <button type="button" role="switch" aria-checked> Radix UI <button role="switch" aria-checked> に加え、フォーム内でのみ非表示の input を追加 select も同様で、ネイティブの select を使わずに role="combobox" と role="listbox" を組み合わせて再現していたり、フォーム互換のために見えない select を置いていたりと、各ライブラリの工夫が見えてきました。 「アクセシブルな複数選択UIを自前で実装するのはかなり大変なので、ライブラリを使うのがおすすめ」という結論にも説得力がありました。 また、スイッチは「押した瞬間に反映されるもの」なので、「保存」ボタンと組み合わせたり、月額／年額のような二択に使ったりするのは本来の用途とずれる、というSwitchとトグルボタンの使い分けの話も盛り上がりました。 ふりかえり 全5回を終えたあと、勉強会の1回分を使ってふりかえりを行いました。 フレームワークには、KPTではなく Fun / Done / Learn を採用しています。KPTだと特に問題がなくてもProblemを挙げる必要があり、ネガティブな空気になりやすいと考えたためです。 Fun：楽しかったこと 輪読会は負荷の高いフォーマットなのに、担当者が理解したことを積極的にシェアしてくれた ただ読んでくるだけでなく、担当者が独自の解釈を織り交ぜて、より高度な内容に仕上げてくれた（UIライブラリの対応状況など） 発表者ごとに本のどこに着目しているかが資料に表れていて、他の人がどう技術書を読んでいるのかを知ることができた 有識者のアクセシビリティの知見を踏まえて本を読み進める体験ができた 発表後のディスカッションで、全員が前のめりに建設的な意見を出す場になった 辻さんからは、こんなコメントももらいました。 昔のWeb制作者は、HTML解体新書に書いてあるくらいのことは普段使いしていた。今の時代は、そうした知識がなくてもプロダクトが作れてしまう。だからこそ、この輪読会を通してみなさんが知ろうとしてくれていることがうれしかった。 さらに、「世の中の登壇には、画面を見ていないと置いていかれるものが意外と多いけれど、今回のみなさんの発表は、画面を見ていなくても話として理解できた」という、うれしい言葉もいただきました。辻さんがこの点について書いた記事も紹介されていたので、発表をする方にはぜひ読んでほしいです。 https://note.com/debugon/n/nae7f164bf8a7 Done：やり遂げたこと フロントエンド勉強会で書籍を輪読するスタイルは初めてだったが、無事に完走できた 社内に『HTML解体新書』の存在を広められた 複数回にわたって1冊の技術書を読む、というスタイルを勉強会として1つ確立できた 一人で読むのがつらい本でも、勉強会に持ち込んでみんなで読む、という選択肢ができたのは大きな収穫です。 Learn：学んだこと HTMLの現行仕様は常に更新され続けるHTML Standardなので、書籍の内容はすでに古くなっている部分もある。だからこそ 書籍は取っかかりとして使い、怪しいと思ったら仕様を引く セクショニングコンテンツ、グルーピングコンテンツ、テキストレベルセマンティクスといったHTMLの原点を改めて思い出せた a 要素の内容モデルはTransparent（透過的）で、親がフローコンテンツなら a の中に div などを置くこともできる セマンティックなHTMLを書けばアクセシビリティを網羅できるわけではない。 結局、見出しやラベルを適切に付けることが、アクセシビリティ的に一番重要 見た目に頼っていたマークアップを、要素の意味から考え直すきっかけになった 担当になった人は誰も発表を避けず、1週間で1時間分の議論ができる資料を作ってきてくれた。 1回あたりの適切なボリューム感 もつかめた うまくいった理由をふりかえってみる ふりかえりの内容も踏まえて、今回の輪読会がうまくいった理由を整理すると、次の4つだと思います。 現場の課題から題材を選んだ 「なんとなく良さそうな本」ではなく、各チームへのヒアリングで見えた共通課題（情報設計・アクセシビリティ）から逆算して本を選びました。そのため、参加者にとって「自分ごと」になりやすかったのだと思います。 始めるハードルを徹底的に下げた 紹介する会を挟む、「読めなくても大丈夫」と明言する、範囲を主要な節に絞る、書籍を会社で用意する、といった工夫で、参加の心理的なハードルを下げました。 説明方法を担当者に任せた 本の内容をなぞるのではなく、「そうなんだ」と感じた点に絞る、UIライブラリと突き合わせる、など担当者ごとの切り口が生まれ、毎回違った面白さがありました。 有識者が一緒に読んでくれた 書籍の内容を、現在の仕様や実際のスクリーンリーダーの挙動と照らし合わせて補足してもらえたことで、「読むだけの会」から「理解して議論する会」になりました。 おわりに 今回の輪読会を通して、HTMLの知識そのものはもちろん、「勉強会で1冊の本を読み切る」という新しい型を手に入れることができました。 ふりかえりでは、次の題材としてReactの公式ドキュメントのような無料で読めるリファレンスを読むのも良さそう、という声や、書籍の内容を起点に、現在のHTMLの仕様やAI時代のマークアップについてさらに議論を深める場をつくれないか、というアイデアも出ています。 少人数のふりかえりではありましたが、この輪読会を乗り越えたことで、新しいことができそうな可能性を感じています。 社内で輪読会を企画しようとしている方の参考になればうれしいです。

本ブログは 2026 年 8 月 28 日に公開された AWS Blog “ Extend your data perimeter to the AWS Management Console with Private Access ” を翻訳したものです。 金融サービス、政府、防衛、ヘルスケアなどの規制対象業界の組織は、機密性の高いワークロードを、パブリックインターネットにアクセスできない分離されたネットワーク環境に限定しています。これまでも、AWS マネジメントコンソールへのアクセスを承認済みの AWS アカウントと企業ネットワークに制限することはできましたが、コンソール自体にはインターネット接続が必要でした。そのため、運用上の利便性とネットワークセキュリティ統制が相反する状況が生じていました。 このたび、AWS マネジメントコンソール プライベートアクセス が、インターネット接続のない仮想プライベートクラウド (VPC) に対応し、一般提供を開始したことをお知らせします。ワークロードを分離されたネットワーク環境に限定している規制対象業界の組織は、サポート対象のサービスコンソールのすべてのトラフィックを  AWS PrivateLink  の VPC エンドポイント経由でルーティングできるようになりました。対象となるトラフィックには、認証フロー、静的アセット (JavaScript、CSS、画像)、コンソール専用 API、AWS サービスの API コールが含まれます。これにより、インターネットゲートウェイ、NAT ゲートウェイ、パブリックインターネットへのルートが一切不要になります。この機能は、すべての AWS 商用リージョン において、一部の サポート対象のサービスコンソール で利用できます。 AWS は 2023 年に AWS マネジメントコンソールプライベートアクセスをリリースしました。この機能では、コンソール、サインイン、サービスの API コールを VPC エンドポイント経由でルーティングして、コンソールに接続できます。ただし、コンソールにアクセスする際、静的アセットとコンソール専用 API にはインターネット接続が必要でした。その結果、セキュリティチームは、コンソールを使用するためにインターネット接続を許可するか、ネットワークが分離された環境で作業するオペレーターのコンソールアクセスを拒否するかの選択を迫られていました。 今回のリリースにより、AWS マネジメントコンソールプライベートアクセスは、次の 2 つの一般的なシナリオに対応します。 インターネットアクセスが制限されたネットワークでのコンソールトラフィック : サポート対象のサービスコンソールのトラフィックが、すべて VPC エンドポイント経由で流れるようになりました。プロキシの許可リストを維持する必要も、TLS インターセプトプロキシを運用する必要もありません。妥協策として CLI のみのワークフローを受け入れる必要もありません。同じ経路は、 Amazon WorkSpaces 、 Amazon Elastic Compute Cloud (Amazon EC2)  インスタンス、および  AWS Direct Connect  または  AWS Site-to-Site VPN で接続されたオンプレミスネットワークからもシームレスに利用できます。サインイン用のリソースコントロールポリシー (RCP) とサインインリソースポリシーを組み合わせると、想定されたネットワークからのみコンソール認証が成功するように設定できます。有効な認証情報が別の場所で提示されても、そのセッションは拒否されます。これまで制限付きのエグレスルールや手動のドメイン許可リストに頼っていたチームも、既に信頼している同じネットワーク統制のもとで、コンソールに全面的にアクセスできるようになります。 データ流出の防止 : プライベートアクセスを使用すると、VPC 内から AWS マネジメントコンソールを使用できる AWS アカウントと組織のアイデンティティを制限できます。これにより、個人アカウントや組織外のアカウントからのアクセスを防止できます。 aws:ResourceOrgID  条件を含む VPC エンドポイントポリシーをアタッチすると、コンソールで実行するアクションの対象が自動的に組織内のリソースに限定されます。さらにサインイン RCP によって、境界内のネットワークからの認証のみが成功するようになり、2 つ目の防御層が加わります。これらの統制を組み合わせることで、複雑なネットワークレイヤーの回避策を講じなくても、サポート対象のサービスコンソールを使用して個人アカウントなど組織外のアカウントのリソースにアクセスすることを防止できます。 この記事では、インターネット接続のない環境で AWS マネジメントコンソールプライベートアクセスがどのように機能するかを説明します。また、VPC エンドポイントポリシーとサインイン RCP を使用してアクセス統制を多層化し、データ境界を強化する方法も紹介します。 ソリューションの概要 AWS マネジメントコンソールプライベートアクセスとサインイン RCP は、API トラフィックに既に使用しているサービスコントロールポリシー (SCP)、RCP、VPC エンドポイントポリシーを自然に拡張したもので、これらの統制をコンソールセッション自体にも適用します。プログラムによるアクセスを保護しているアイデンティティ、リソース、ネットワークのデータ境界の統制によって、インタラクティブなブラウザセッションも同じように保護されます。 境界 統制の目的 ポリシーの構成要素 実装手順 アイデンティティ 信頼できるアイデンティティのみが自組織のリソースにアクセスできる サインイン RCP とリソースベースのポリシー (RBP) コンソールにサインインできるプリンシパルを制限します。認証前は、 signin:PrincipalArn を除外の指定にのみ使用できます。認証後は、RCP で組織、アカウント、またはプリンシパルのレベルで制限し ( aws:PrincipalOrgID 、 aws:PrincipalAccount 、 aws:PrincipalArn )、RBP でアカウントまたはプリンシパルのレベルで制限します。 アイデンティティ 自組織のネットワークからは信頼できるアイデンティティのみを許可する コンソールの VPC エンドポイントポリシーとサインインの VPC エンドポイントポリシー コンソールエンドポイント: サインイン済みのアイデンティティに対して aws:PrincipalOrgID または aws:PrincipalAccount を使用します。サインインエンドポイント: 認証前は aws:ResourceOrgID または aws:ResourceAccount を、認証後はプリンシパルキーとリソースキーを使用します。これにより、自組織のネットワークから個人アカウントなど組織外のアカウントへのサインインをブロックします。 リソース 自組織のアイデンティティは信頼できるリソースにのみアクセスできる SCP aws:ResourceOrgID を使用したリソース境界 SCP は、すべてのコンソールセッションでプリンシパルに適用されます。コンソールがプリンシパルに代わって行う各サービス API コールは、対象リソースが組織外にある場合に拒否されます。 リソース 自組織のネットワークからは信頼できるリソースにのみアクセスできる コンソールの VPC エンドポイントポリシーとサービスの VPC エンドポイントポリシー コンソールエンドポイントポリシーで aws:ResourceOrgID と aws:ResourceAccount を使用して、ネットワーク経由でコンソールがアクセスできる範囲を限定します。 ネットワーク 自組織のアイデンティティは想定されたネットワークからのみリソースにアクセスできる SCP aws:SourceVpc を使用するネットワーク境界 SCP は、想定されたネットワークの外部から行われるプリンシパルのサービス呼び出しを拒否します。プライベートアクセスでは、コンソールがサポート対象のサービスにプロキシするリクエストの aws:SourceVpc には、プライベートアクセスエンドポイントをホストしている VPC が設定されます。ブラウザからの直接リクエストに VPC コンテキストが含まれるのは、そのサービスに独自の VPC エンドポイントがある場合に限られます。そのため、使用するすべてのサービスにエンドポイントを設定してください。AWS が条件に使用することを推奨しているのは aws:SourceVpc であり、特定の aws:SourceVpce の値ではありません。 ネットワーク 自組織のリソースには想定されたネットワークからのみアクセスできる サインイン RBP と RCP、およびネットワーク境界 RCP サインインポリシーは、認証前と認証後の両方のステートメントで aws:SourceIp 、 aws:SourceVpc 、 aws:SourceVpce 、 aws:VpcSourceIp を使用して、想定外のネットワークからのコンソール認証を拒否します。ネットワーク境界 RCP は、アクセス経路にかかわらず、データリソースに同じネットワーク条件を適用します。 今回のリリースにより、コンソールプライベートアクセスは、サポート対象のサービスコンソールのブラウザトラフィックを VPC エンドポイント経由でルーティングします。対象となるトラフィックは次のとおりです。 認証フロー  – サインイン、認証情報の交換、セッショントークンのリクエスト 静的アセット  – コンソール UI をレンダリングする JavaScript、CSS、画像 サービスコンソールの API コール  – ユーザーがサービスコンソールを操作するときに発生するバックエンドリクエスト プライベート VPC 内のワークロードからのトラフィックは、パブリックインターネットへの経路を一切使用せずに、3 つのプライベートアクセスエンドポイントを経由します。その流れは次のとおりです (図 1 を参照)。 オペレーターのブラウザが  <region>.console.aws.amazon.com をリクエストします。 企業の DNS フォワーダーが、VPC 内に設定された  Amazon Route 53  Resolver インバウンドエンドポイントにクエリを転送し、このエンドポイントがトラフィックをコンソールの VPC エンドポイントに転送します。 ブラウザトラフィックは、オンプレミスから Direct Connect (または  AWS Site-to-Site VPN ) を経由して VPC に到達し、VPC エンドポイントが AWS プライベートネットワーク経由でトラフィックをコンソールサービスにルーティングします。 コンソールサービスは、ブラウザセッションを確立するために、サインインエンドポイント  <region>.signin.aws.amazon.com  にリダイレクトします。 DNS によって、サインインのドメインがサインインの VPC エンドポイントのプライベート IP アドレスに解決され、ブラウザトラフィックは AWS プライベートネットワーク経由でサインインサービスに送信されます。 認証情報が入力されると、サインインサービスは RBP と RCP に加えて VPC エンドポイントポリシーを評価し、コンソールに戻るようリダイレクトします。 コンソールは VPC エンドポイントポリシーを評価し、コンソール API の VPC エンドポイントから静的コンテンツを読み込みます。また、AWS サービス API を呼び出す際に、アイデンティティとリソースの制限を適用します。 これで、ユーザーはプライベートアクセス経由で AWS マネジメントコンソールにアクセスできるようになります。 図 1: ネットワーク分離アーキテクチャ AWS マネジメントコンソールプライベートアクセスをパイロット導入する ここでは、1 つの組織単位 (OU) 内の単一の AWS リージョンを対象に、AWS マネジメントコンソールプライベートアクセスをセットアップする手順の概要を説明します。段階的に展開することをお勧めします。追加のリージョンや OU に拡大する前に、各ステップを検証してください。 完全なソリューションを構築する前に、プライベートアクセスのデプロイの仕組みを検証したい場合は、 「テスト環境での開始方法」ガイド を参照してください。このガイドでは、単一の VPC に 3 つのプライベートアクセスエンドポイントと制限の緩いポリシーを設定する最小限の構成を、順を追って説明しています。この記事で後述するデプロイとは別に、実際に動作する環境で試すことができます。ユーザーがコンソールにアクセスする際に、サインインポリシーでユーザーのネットワークロケーションを検証する方法については、 「リソースベースのポリシーとリソースコントロールポリシーによるコンソールアクセスの制御」 を参照してください。 前提条件 次の前提条件を満たしている必要があります。 AWS Organizations の組織に所属している  AWS アカウント 。ステップ 6 の RCP の例では、管理アカウントへのアクセスが必要です。 選択した AWS リージョンにある VPC。企業ネットワークからの接続は任意です。VPC へのアクセス手段としては、 AWS Direct Connect  接続、 AWS Site-to-Site VPN 、または VPC 内で直接実行される  Amazon WorkSpaces  や  Amazon EC2  のブラウジング用インスタンスなどのワークロードを使用できます。 AWS CloudTrail  が同じリージョンで有効になっており、記録された  ConsoleLogin  イベントを確認できること。 AWS PrivateLink のインターフェイスエンドポイント と AWS Identity and Access Management (IAM) のポリシー評価 に関する知識。 ステップ 1: 現在のコンソールアクセスのベースラインを把握する 変更を加える前に、CloudTrail を使用して、ユーザーが現在どのようにコンソールにアクセスしているかを把握します。代表的な期間 (30 日を推奨します) を対象に  eventName = ConsoleLogin  を検索し、 sourceIPAddress 、 vpcEndpointId 、 awsRegion  の各フィールドを確認します。 ルートユーザー 、 IAM ユーザー 、SAML フェデレーション、 AWS IAM Identity Center のうち、どのアイデンティティの種類が使用されているかを特定し、パイロットを実施する OU またはアカウントを決定します。 注 : サインインポリシーの設定を誤ると、ユーザーがコンソールからロックアウトされる可能性があります。本番アカウントや共有アカウントでのパイロットは避け、専用のテストアカウントを使用してください。また、アクセス制御の適用を有効にする前に、ブレークグラス (緊急アクセス用) プリンシパルを設定してください (ステップ 6 で説明します)。 ステップ 2: プライベートアクセスの VPC エンドポイントを作成する 選択したリージョンで、エンドポイントをホストする VPC を作成するか、既存の VPC を選択します。次に、その VPC に 3 つの インターフェイス VPC エンドポイント を作成します。 com.amazonaws.<region>.console  はコンソール用です。 com.amazonaws.<region>.signin  は AWS サインイン用です。 com.amazonaws.<region>.console-static  はコンソール専用 API 用です。このエンドポイントは、VPC にインターネットへの経路がない場合にのみ必要です。 ステップ 3: AWS マネジメントコンソールプライベートアクセス用にプライベート DNS を設定する AWS マネジメントコンソールプライベートアクセスを使用するには、プライベート DNS を設定して、コンソールドメイン ( .console.aws.amazon.com 、 .signin.aws.amazon.com 、および関連する静的コンテンツドメイン) が VPC 内にあるインターフェイスエンドポイントのネットワークインターフェイスに解決されるようにする必要があります。 VPC 内のワークロードの場合 : VPC 内のワークロードがデフォルトの  Amazon Route 53 Resolver を使用している場合、追加の DNS 設定は必要ありません。各インターフェイスエンドポイントの作成時に、プライベート DNS 名のオプションを有効にします (PrivateDnsEnabled = true に設定)。これにより、パブリックのコンソールドメインが、VPC 内にあるエンドポイントのネットワークインターフェイスに自動的に解決されます。カスタム DNS リゾルバーまたはプライベートホストゾーンを使用する場合は、コンソールドメインをエンドポイントアドレスにマッピングするよう明示的に設定する必要があります。詳細については、 「プライベートホストゾーンの使用」 を参照してください。ドメインの完全なリストと DNS 設定の詳細な手順については、 AWS マネジメントコンソールプライベートアクセスに必要なエンドポイントに関するドキュメント を参照してください。 VPC 外のワークロードの場合 : AWS Direct Connect や AWS Site-to-Site VPN で接続する企業オフィスなど、VPC の外部からエンドポイントにアクセスするワークロードでは、企業の DNS リゾルバーがこれらのドメインに対してエンドポイントアドレスを返すように設定してください。詳細については、 「Route 53 Resolver でマルチアカウント環境の DNS 管理を簡素化する」 を参照してください。 ステップ 4: プライベート接続を検証する VPC 内のワークロードからコンソールにサインインします。コンソールが通常どおり読み込まれるはずです。トラフィックが VPC エンドポイント経由でルーティングされていることを確認するには、コンソールのナビゲーションバーに鍵アイコンが表示されているかを確認します (図 2 を参照)。 図 2: コンソールプライベートアクセス CloudTrail で、最近の  ConsoleLogin  イベントの  vpcEndpointId  フィールドに、いずれかのエンドポイント ID が入力されていることも確認できます。次に示すのは、CloudTrail の  ConsoleLogin  イベントのスニペットの例で、 vpcEndpointId  フィールドが含まれています。 { "eventVersion": "1.08", "userIdentity": { "type": "AssumedRole", "principalId": "AROA3XFRBF23EXAMPLE:john.doe", "arn": "arn:aws:sts::123456789012:assumed-role/Admin/john.doe", "accountId": "123456789012" }, "eventTime": "2026-07-08T19:15:32Z", "eventSource": "signin.amazonaws.com", "eventName": "ConsoleLogin", "awsRegion": "us-east-1", "sourceIPAddress": "10.0.1.47", "userAgent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)...", "requestParameters": null, "responseElements": { "ConsoleLogin": "Success" }, "additionalEventData": { "LoginTo": "https://console.aws.amazon.com/console/home", "MobileVersion": "No", "MFAUsed": "Yes", "vpcEndpointId": "vpce-0abc123def456789a" }, "eventID": "a1b2c3d4-5678-90ab-cdef-EXAMPLE11111", "eventType": "AwsConsoleSignIn", "recipientAccountId": "123456789012" } AWS マネジメントコンソールが読み込まれない場合は、次の項目を確認してください。 各インターフェイスエンドポイントでプライベート DNS が有効になっている (またはカスタムリゾルバーがエンドポイントアドレスを返す) プライベート DNS を有効にすると、AWS は、サービスドメイン (例:  console.aws.amazon.com ) を VPC エンドポイントのプライベート IP アドレスに解決する DNS エントリを自動的に作成します。この設定が無効の場合、ブラウザは引き続きパブリックの AWS エンドポイントにルーティングされ、プライベートアクセスの設定が完全にバイパスされます。 各エンドポイントで  PrivateDnsEnabled が有効になっていることを確認します。 aws ec2 describe-vpc-endpoints \ --filters "Name=vpc-endpoint-type,Values=Interface" \ --query "VpcEndpoints[].{Id:VpcEndpointId,Service:ServiceName,PrivateDns:PrivateDnsEnabled}" \ --output table 次に、VPC 内から、ドメインがプライベートアドレスに解決されることを確認します。 nslookup console.aws.amazon.com nslookup signin.aws.amazon.com # パブリック IP ではなく、プライベート IP (例: 10.x.x.x) が返されるはずです いずれのクエリでも、VPC の CIDR 範囲内のプライベート IP アドレスが返されるはずです。Amazon 提供の DNS ではなくカスタム DNS リゾルバーを使用している場合は、転送ルールで AWS ドメインのクエリを VPC 内の Route 53 Resolver インバウンドエンドポイントに転送するよう設定してください。 エンドポイントのセキュリティグループで、ワークロードのサブネットからの HTTPS (TCP 443) が許可されている 各 VPC エンドポイントはサブネット内に Elastic Network Interface (ENI) を作成し、これらの ENI はセキュリティグループによって制御されます。セキュリティグループでワークロードからのインバウンド HTTPS トラフィックが許可されていない場合、接続はエラーが表示されないまま失敗します。 エンドポイントにアタッチされているセキュリティグループを特定します。 aws ec2 describe-vpc-endpoints --vpc-endpoint-ids vpce-0abc123def456789a \ --query "VpcEndpoints[].Groups[].GroupId" --output text 次に、各セキュリティグループでワークロードのサブネットからのインバウンド TCP 443 が許可されていることを確認します。 aws ec2 describe-security-groups --group-ids sg-xxxxxxxx \ --query "SecurityGroups[].IpPermissions[?ToPort==\`443\`]" \ --output json VPC の外部からのトラフィック (Direct Connect または Site-to-Site VPN) の場合、企業の DNS がエンドポイントの IP を返し、ルートが正しく伝播されている AWS Direct Connect または AWS Site-to-Site VPN で接続されたオンプレミスのワークステーションからコンソールにアクセスする場合は、さらに 2 つの条件を満たす必要があります。 1 つ目に、企業の DNS が AWS ドメインを VPC エンドポイントのプライベート IP に解決する必要があります。オンプレミスのマシンから次のコマンドを実行します。 nslookup console.aws.amazon.com パブリックの AWS IP が返される場合、企業の DNS は Route 53 Resolver 経由でクエリを転送していません。 aws.amazon.com と amazonaws.com のドメインについて、Resolver インバウンドエンドポイントの IP への条件付き転送を設定してください。 2 つ目に、ネットワークルートが正しく伝播されている必要があります。戻りのトラフィックがオンプレミスネットワークに到達できるように、エンドポイントのサブネットに関連付けられたルートテーブルに、仮想プライベートゲートウェイ (VGW) またはトランジットゲートウェイからのルートが伝播されていることを確認してください。次のコマンドで確認できます。 aws ec2 describe-route-tables \ --filters "Name=association.subnet-id,Values=subnet-xxxxx" \ --query "RouteTables[].PropagatingVgws" 簡単なエンドツーエンドの検証 : ワークステーションから  traceroute console.aws.amazon.com  を実行し、経路にプライベートホップのみが含まれ、パブリックインターネットを経由するトラフィックがないことを確認します。 コンソールは読み込まれるが鍵アイコンが表示されない場合 コンソールは読み込まれるものの接続がプライベートになっていない場合 (例えば、鍵アイコンが表示されない場合)、ブラウザは VPC エンドポイントではなく、パブリックインターネット経由でコンソールにアクセスしています。 VPC 内のワークロードから  nslookup console.aws.amazon.com  を実行します。VPC の CIDR 範囲内のプライベート IP が返されれば正常です。パブリック IP が返される場合は、DNS がエンドポイントをバイパスしています。通常は、インターフェイスエンドポイントでプライベート DNS が有効になっていないことが原因です。この場合は、 PrivateDnsEnabled = true に設定してください。 VPC 外のワークロードの場合は、企業の DNS がコンソールドメインのクエリを VPC 内に転送するように設定してください。例えば、 Amazon Route 53 Resolver インバウンドエンドポイント を経由して転送できます。 ステップ 5: VPC エンドポイントポリシーを適用する コンソールと AWS サインインのエンドポイントに、アクセスを組織内のアイデンティティに制限するエンドポイントポリシーをアタッチします。なお、静的コンテンツのエンドポイントはエンドポイントポリシーをサポートしていません。 まず、制限の緩い  Allow *  ポリシーを使用して、トラフィックがエンドポイント経由でルーティングされていることを確認します (CloudTrail のコンソールイベントで  vpcEndpointId  フィールドに値が入力されていれば確認できます)。ルーティングを確認できたら、VPC エンドポイントポリシーに制限を追加し、トラフィックを監視します。 初期ポリシーでは 2 つの条件キーを使用します。 aws:PrincipalOrgID  でアイデンティティを組織内に制限し、 aws:ResourceOrgID  でコンソールがアクセスできるリソースを組織のリソースに制限します。追加の条件キーやリソース制限のパターンを含む完全なリファレンスについては、 AWS マネジメントコンソールプライベートアクセスのユーザーガイド を参照してください。 パイロット以降のポリシーについては、 「AWS のデータ境界」 を参照してください。また、 データ境界ポリシーの例 を収録した GitHub リポジトリでは、環境にデータ境界を実装する際のサービス固有の考慮事項を紹介しています。 ステップ 6: サインインポリシーを適用する サインインポリシーは、ネットワークまたはプリンシパルの条件に一致しないコンソール認証リクエストを拒否します。このポリシーは、 signin:Authenticate  を対象とする認証前のステートメントと、 signin:AuthorizeOAuth2Access  および  signin:CreateOAuth2Token を対象とする認証後のステートメントで構成されます。必ず両方のステートメントを含めてください。 パイロットでは、AWS Organizations の管理アカウントから、ポリシーを RCP としてデプロイします。RCP を有効にすると組織内のすべてのアカウントに適用されるため、本格的に展開する前に、専用のテスト組織でパイロットを実施することをお勧めします。適用を有効にするには、us-east-1 リージョンで組織を対象に  signin:PutConsoleAuthorizationConfiguration  API を呼び出します (AWS サインインは、このリージョンからポリシーをグローバルにレプリケートします)。コンソール認可を有効にするまで、リソースのアクセス許可ステートメントは効力を持ちません。 重要 : RCP を有効にする前に、ブレークグラス用の経路として、除外プリンシパルを少なくとも 1 つ設定してください。除外プリンシパルには、専用の IAM ロールを使用することをお勧めします。 ネットワーク条件を定義するアクセス許可ステートメントを記述します。 例 – アクセス元を企業 VPC に制限する aws signin put-resource-permission-statement \ --source-vpc vpc-0abc123def456789 \ --requested-region us-west-2 \ --excluded-principal "arn:aws:iam::123456789012:user/EmergencyAdmin" \ --region us-east-1 例 – アクセス元を特定の IP 範囲に制限する aws signin put-resource-permission-statement \ --source-ip "IP_ADDRESS" \ --excluded-principal "arn:aws:iam::123456789012:role/BreakGlassRole" \ --region us-east-1 組織のコンソール認可を有効にして、ポリシーの適用を開始します。 aws signin put-console-authorization-configuration \ --target-id <your-target-id> \ --region us-east-1 現在有効になっている統合ポリシーを確認します。 aws signin get-resource-policy --region us-east-1 ポリシーの例、 AWS コマンドラインインターフェイス (AWS CLI)  のリファレンス、ロックアウトからの復旧手順については、 「AWS マネジメントコンソールへのアクセスを想定するネットワークに制限」 のブログ記事と 「リソースベースのポリシーによるコンソールアクセスの制御」 のドキュメントを参照してください。このドキュメントでは、組織全体の RCP の代わりに、単一のアカウントにアタッチした RBP を使用する、アカウント単位の代替方法についても説明しています。 ステップ 7: サービスの VPC エンドポイントを追加する ここまでで、コンソールシェルが読み込まれ、鍵アイコンが表示され、サインインポリシーによって承認されたアイデンティティのみがサインインできるようになりました。しかし、 AWS Key Management Service (AWS KMS)  コンソールなどのサービスコンソールを開くと、リソースの読み込みに失敗したり、ページが応答しなくなったりする場合があります。プライベートアクセスエンドポイントが伝送するのはコンソールシェルのトラフィックであり、コンソールがユーザーに代わって行うサービス API コールは含まれないためです。インターネットゲートウェイのない VPC では、これらの呼び出しがサービスに到達する経路がありません。 そこで、サービス自体の VPC エンドポイントを追加します。パイロットでは、 AWS KMS インターフェイスエンドポイント  ( com.amazonaws.<region>.kms ) を同じ VPC に作成し、プライベート DNS を有効にします。VPC 内から AWS KMS コンソールを開き、キーのリストが読み込まれることを確認します。ユーザーが初日から必要とするサービスごとに、この手順を繰り返します。なお、1 つのサービスコンソールが複数の AWS サービス API を呼び出すことはよくあります。コンソールは読み込まれるものの、ページの一部にエラーが表示されたり、空のままになったりする場合、主な原因は、そのコンソールが依存するいずれかのサービスのエンドポイントが不足していることです。 PrivateLink をサポートするサービスの最新のリストは、 AWS PrivateLink のドキュメント に記載されています。PrivateLink をサポートしていないサービスのコンソールは、インターネットに接続されていない VPC では機能しないため、別途対処する必要があります。 ステップ 8: 設定していないリージョンとサービスを非表示にする (オプション) エンドポイントを用意していないサービスやリージョンへのコンソールリンクは、VPC 内では機能しません。ユーザーが機能しないページに移動しないようにするには、 User Experience Customization (UXC)  を使用して、プライベートアクセスのデプロイに含まれていないリージョンとサービスを非表示にします。UXC はアカウントレベルで設定し、ナビゲーション、検索結果、サービス選択のドロップダウンに適用されます。 ステップ 9: 検証してから拡大する 1 つのパイロットアカウントにエンドポイントポリシーとサインイン RCP を適用したら、次の手順を実行します。 企業ネットワーク内からサインインします。セッションが正常に確立されることを確認します。 企業ネットワーク外からサインインします。コンソールに到達する前に、サインインのステップでセッションが拒否されることを確認します。 CloudTrail で、ネットワーク内からのトラフィックの  ConsoleLogin  イベントに  vpcEndpointId  が入力されていることを確認します。 想定外の拒否が発生した場合は、CloudTrail で ConsoleLogin イベントのうち、エラーメッセージに Authorization denied because of a resource-based policy (リソースベースのポリシーにより認可が拒否されました) または Authorization denied because of a resource control policy (リソースコントロールポリシーにより認可が拒否されました) が含まれるものを探し、原因となったステートメントを特定します。 考慮事項 この設計を採用する前に、次の点に注意してください。 AWS IAM Identity Center:  IAM Identity Center  のサインインは、現時点では VPC エンドポイント経由ではサポートされていません。最初のシングルサインオン (SSO) 認証は、引き続きインターネット経由で行う必要があります。 プログラムによるアクセス: サインイン RBP と RCP が制御するのは、インタラクティブなコンソールサインインです。SigV4 で署名された AWS SDK と AWS CLI のリクエストは影響を受けません。これは復旧経路としても利用できます。コンソール認可の設定を誤った場合でも、 signin:DeleteConsoleAuthorizationConfiguration  アクセス許可を持つプリンシパルであれば、プログラムによって適用を無効にできます。 AWS サインインと統合されたアプリ: Amazon Connect 、 Amazon WorkSpaces 、 Amazon QuickSight 、 AWS Health Dashboard 、 Amazon AppStream 2.0 、 Amazon Lightsail  が認証に AWS サインインを使用する場合、サインインポリシーはこれらのアプリケーションにも適用されます。 AWS マネジメントコンソールプライベートアクセスはすべての AWS 商用リージョンで利用できますが、サポートしているのは AWS サービスコンソールの一部のみです。詳細については、 「プライベートアクセスでサポートされている AWS リージョン、サービスコンソール、機能」 のドキュメントを参照してください。 サポートされていないサービスがあっても、他のコンソールには引き続き移動できます。ただし、サポートされていないサービスコンソールとコンソール専用 API には、インターネット接続が必要です。 コスト: デプロイするエンドポイントとリージョンごとに、通常の  AWS PrivateLink エンドポイント料金 とデータ処理料金が発生します。対象となる料金項目は、3 つのプライベートアクセスエンドポイント ( console 、 signin 、 console-static ) と、既に使用しているサービスエンドポイントです。 まとめ この記事では、AWS のデータ境界フレームワークを AWS マネジメントコンソールに拡張する方法を説明しました。AWS マネジメントコンソールプライベートアクセスを使用して、VPC エンドポイント経由でコンソールトラフィックをルーティングし、サインイン RBP と RCP を使用して、ネットワークと組織に基づいてコンソールサインインを制限しました。さらに、インターネットゲートウェイのない VPC でコンソールが動作するように設定しました。これにより、API トラフィックに既に適用している 4 つの統制目的が、コンソールにも適用されるようになります。 使用を開始するには、 AWS マネジメントコンソールプライベートアクセスのドキュメント を参照してください。デプロイパターンとリージョンごとの考慮事項については、 AWS マネジメントコンソールプライベートアクセスのリファレンスアーキテクチャ を参照してください。データ境界の全体像については、 「AWS でのデータ境界の確立」 を参照してください。 この記事に関するご質問は、 AWS re:Post の IAM フォーラム で新しいスレッドを作成するか、 AWS サポートにお問い合わせ ください。 Madhur Kulkarni Madhur は AWS の Sr. Customer Solutions Manager です。Strategic Accounts のお客様と協力し、クラウド導入の加速とビジネス成果の創出に取り組んでいます。カスタマーエンジニアリング、AWS サービスチーム、スペシャリスト組織にまたがる部門横断的なチームと連携し、エンタープライズ規模のクラウドソリューションを提供しています。 Mateusz Jaworski Mateusz は AWS の Principal Engineer で、AWS マネジメントコンソールの開発に携わっています。 Sujay Ghosh Sujay は AWS の Software Development Manager で、AWS マネジメントコンソールへの安全で信頼性の高いアクセスを実現するチームを率いています。何百万ものお客様がクラウドリソースを安全かつ効率的に管理できるよう、スケーラブルなインフラストラクチャの構築に情熱を注いでいます。 Abhijit Barde Abhijit は AWS の Principal Product Manager です。AWS を利用するすべてのお客様が対話型アシスタントと生成 AI を使用して、AWS インフラストラクチャを簡単に検出、モニタリング、運用できるようにすることに注力しています。 本ブログは Security Solutions Architect の 中島 章博 が翻訳しました。