[{"data":1,"prerenderedAt":132},["ShallowReactive",2],{"pqWMxGXzB0":3,"BsJYbO1tvf":57,"5fiubVK4TF":107,"BlogAbstract-passkey":128},{"createdAt":4,"updatedAt":5,"publishedAt":4,"revisedAt":5,"title":6,"subTitle":7,"author":8,"portalEyecatch":9,"portalEyecatchCom":13,"pickupEntry":14,"topLink1":38,"topLink2":44,"topLink3":52},"2021-11-13T07:20:45.441Z","2025-06-01T04:12:21.773Z","fragmentary notes","ITエンジニアの気まぐれメモ","shunya_wisteria",{"url":10,"height":11,"width":12},"https://images.microcms-assets.io/assets/16526c12b52b4a198b9cd25f4e1f803e/7867e0be54e544d7a486f665ca8877df/chojuji.webp",1600,2400,"休日コーディングの嗜み",{"id":15,"createdAt":16,"updatedAt":17,"publishedAt":18,"revisedAt":17,"title":19,"abstract":20,"eyecatch":21,"toc":25,"body":26,"category":27,"tags":29},"architect2506","2025-06-01T04:09:39.256Z","2026-05-11T11:42:59.454Z","2025-06-01T04:12:27.705Z","ブログアーキテクチャ ver.202506 - LLM本文要約機能の追加","LLM（生成AI）を用いた本文要約機能を実装してみたので、それを踏まえたブログシステムアーキテクチャをまとめてみます。",{"url":22,"height":23,"width":24},"https://images.microcms-assets.io/assets/16526c12b52b4a198b9cd25f4e1f803e/bea3c1bfe18d49609b7c8404f7cf604b/237A6184.webp",800,1200,true,"\u003Ch2 id=\"h8d027c8ed3\">はじめに\u003C/h2>\u003Cp style=\"text-align: start\">変化の流れがはやすぎて、ついていけていない生成AI事情。とはいえ何かしら活用してみたいなと思い、今更ながらAPI経由でのLLM callを試しながら、当ブログに本文要約機能を実装してみる。\u003C/p>\u003Cp style=\"text-align: start\">併せて、ここ最近でいろいろと組み替えた部分も踏まえて、改めて2025/6時点のシステムアーキテクチャをまとめてみました。\u003C/p>\u003Ch2 id=\"h7c8e70c948\">LLM本文要約機能\u003C/h2>\u003Cp style=\"text-align: start\">LLM本文要約機能は、Cloudflare Workers上にWEB APIとして実装。リクエストされたブログ本文をプロンプトとともにLLMに渡して本文要約、要約結果をレスポンスする作りとしています。\u003C/p>\u003Cp style=\"text-align: start\">呼び出し側（Nuxt3のフロントエンド）は、ビルド時にこのAPIをcallし得られた要約文をページに埋め込んで静的生成しています。この流れは、ブログのコンテンツをmicroCMSからビルド時に引っ張っている動きと同様。\u003C/p>\u003Cp style=\"text-align: start\">LLMのモデルは、GoogleのGemini\u003Cs> 2.0 Flash\u003C/s> 2.5 Flash-Liteを採用（2025/12/9 モデルを変更）。\u003C/p>\u003Cul>\u003Cli>APIが無料である程度のボリューム使用できること\u003C/li>\u003Cli>本文要約自体はそれほど難しいタスクではないと思うので、\u003Cs>最新の2.5でなくても十分\u003C/s>\u003Cbr>→ いつの間にかGemini 2.0 Flashが利用できなくなっているようなので、2.5 Flash-Lite に変更（2025/12/9）\u003C/li>\u003C/ul>\u003Cp style=\"text-align: start\">というの採用の理由、あまり深い意味はありません。\u003C/p>\u003Cp style=\"text-align: start\">要約結果は、Cloudflare KV上にキャッシュさせ、LLMへのリクエストは初回のみ、以降はキャッシュされた結果を利用するようにもしています。これは\u003C/p>\u003Cul>\u003Cli>LLMへのリクエスト回数を絞ること\u003C/li>\u003Cli>要約結果の変動を防ぐこと\u003C/li>\u003Cli>必要に応じて要約結果を人が修正できるようにすること\u003C/li>\u003C/ul>\u003Cp style=\"text-align: start\">を目的としたもの。\u003C/p>\u003Cp style=\"text-align: start\">特に3つ目にも記載しましたが、LLMによる要約を完全に信頼してはいないため、必ず要約結果を確認し必要に応じて修正できる仕組みであることを重視しました。\u003C/p>\u003Cfigure>\u003Cimg src=\"https://images.microcms-assets.io/assets/16526c12b52b4a198b9cd25f4e1f803e/7c67f43cc795444293c03407ccbc7504/blog-abstract-sequence.webp\" alt=\"\" width=\"1215\" height=\"822\">\u003C/figure>\u003Cp style=\"text-align: start\">動かし始めてまだ日が浅いですが、今のところはよい感じで動いてくれてそう。\u003C/p>\u003Ch2 id=\"h1331c56b22\">作ってみた感想\u003C/h2>\u003Cp style=\"text-align: start\">仕組み自体はWEB API callをしているだけなので、大して難しいわけでもなく、すんなり作れたのですが。。。ちょっと苦戦したのはプロンプトの作成。\u003C/p>\u003Cp style=\"text-align: start\">要約結果がなかなか思うようにならずに、LLMに指示する表現を色々変えながらTry & Errorを繰り返しました。特に、今回出力されたものをそのままページに埋め込む仕組みにしていますが、LLMがMarkdownのCode Block形式で出力してくる点が面倒でした。これをそのまま埋め込むとCode Blockとして表示されてしまうため、色々な言い回しを試し、何とかCode Block形式にしない出力が得られるようになりました。このあたりが自然言語をInputとするプロンプトの難しさね。AIを使いこなすにはプロンプト力が試されるわけか。\u003C/p>\u003Cp style=\"text-align: start\">また要約結果を眺めていると、自分視点の要約結果と、第三者視点の要約結果（「筆者は〇〇と述べている」みたいな表現）が混在している点も気になっています。このあたりもゆくゆくはプロンプトを修正してどちらかに統一するようにしてみたいなと思います。\u003C/p>\u003Ch2 id=\"h18ae72303e\">ブログシステムアーキテクチャ ver.202506\u003C/h2>\u003Cp style=\"text-align: start\">以上を踏まえた上で、2025/6時点のJamstackブログのシステムアーキテクチャは次の通り。 \u003C/p>\u003Cfigure>\u003Cimg src=\"https://images.microcms-assets.io/assets/16526c12b52b4a198b9cd25f4e1f803e/d8b74c8be1d541b9a31ef04f0f18051a/blog-architect-202506.webp\" alt=\"\" width=\"1368\" height=\"831\">\u003C/figure>\u003Cp style=\"text-align: start\">最近 Cloudflare領域が拡大していますね。これなら静的ページのホスティング自体もnetlifyからCloudflare Pagesに移管してしまってもよいのでは？と思うこともありますが、1プラットフォームに依存・固めすぎるのも面白くないという理由でしばらくはこの構成で行こうかと（単純に移行するのが面倒でもあり）。\u003C/p>",{"id":28},"tech-tips",[30,32,34,36],{"id":31},"llm",{"id":33},"jamstack",{"id":35},"cloudflare",{"id":37},"blog-mng",{"fieldId":39,"title":40,"url":41,"photo":42,"external":25},"toplink","Photo Blog","https://amaoto.swisteria.com",{"url":43,"height":23,"width":24},"https://images.microcms-assets.io/assets/16526c12b52b4a198b9cd25f4e1f803e/cfff2880c38d48829e729bfef255d29a/IMG_0683s.webp",{"fieldId":39,"title":45,"url":46,"photo":47,"external":51},"My TIPS","categories/tech-tips/",{"url":48,"height":49,"width":50},"https://images.microcms-assets.io/assets/16526c12b52b4a198b9cd25f4e1f803e/23d28881bd10453ea89ecc024e64a4c1/technology-g25b3232d5_1280.webp",720,1280,false,{"fieldId":39,"title":53,"url":54,"photo":55,"external":51},"About Me","about/",{"url":56,"height":23,"width":24},"https://images.microcms-assets.io/assets/16526c12b52b4a198b9cd25f4e1f803e/f41c2daad68f40cc8ad394ae591d4ffe/IMG_2691s.webp",{"createdAt":58,"updatedAt":59,"revisedAt":59,"about":60,"author":61,"desc":62,"prof":63,"sns":66},"2019-10-06T13:13:55.050Z","2025-01-19T12:25:38.989Z","\u003Cp>仕事や趣味、何気ない日常の中で気になったこと/気に入ったこと（IT・業務知識、プログラム関係の覚書、行ってみたい/行ってみた場所、使ってみたい/使ってみたガジェットやWEBサービスetc）に触れながら、感想・気づき・ボヤキ等を、忘備録的に綴る楽描ノート。\u003C/p>","shunya","\u003Cp>1990年10月生まれ。 岐阜県美濃地方出身、東京都内在住のITエンジニア。\u003Cbr>\u003Cbr>根っからの新しい物好き / 飽きっぽい性格と、なんやかんやあり、広く（浅く）いろんなことを経験しながら引き出しと視野を広げるキャリアを疾走中。\u003Cbr>\u003Cbr>休日は、部屋に引きこもりPCと戯れる or ふらっとどこかに出かけ散歩しながら写真撮影を楽しむ。お城や寺社仏閣、古い街並みあたりをキーワードに次の目的地を探す日々。自己満足写真は、\u003Ca href=\"https://shunya-wisteria.tumblr.com\" target=\"_blank\" rel=\"noopener noreferrer\">tumblrブログ\u003C/a>参照。\u003C/p>",{"url":64,"height":65,"width":65},"https://images.microcms-assets.io/assets/16526c12b52b4a198b9cd25f4e1f803e/de44ebfd86294d01a7994ffae55b09f2/PXL_20230625_040816231.jpg",1000,[67,73,77,82,87,92,97,102],{"fieldId":68,"type":69,"text":70,"url":71,"mdicon":72},"sns","github","GitHub","https://github.com/shunya-wisteria","mdi-github",{"fieldId":68,"type":74,"text":8,"url":75,"mdicon":76},"twitter","https://twitter.com/shunya_wisteria","mdi-twitter",{"fieldId":68,"type":78,"text":79,"url":80,"mdicon":81},"mastodon","@wisteriaWithS@vivaldi.net","https://social.vivaldi.net/@wisteriaWithS","mdi-mastodon",{"fieldId":68,"type":83,"text":84,"url":85,"mdicon":86},"contact","Mail","https://www.swisteria.com/contact/","mdi-email-outline",{"fieldId":68,"type":88,"text":89,"url":90,"mdicon":91},"instagram","Instagram","https://www.instagram.com/wisteria.shunya/","mdi-instagram",{"fieldId":68,"type":93,"text":94,"url":95,"mdicon":96},"tumblr","雨音日録 - Photo Blog","https://shunya-wisteria.tumblr.com","mdi-alpha-t-box-outline",{"fieldId":68,"type":98,"text":99,"url":100,"mdicon":101},"bluesky","@swisteria.bsky.social","https://bsky.app/profile/swisteria.bsky.social","mdi-butterfly-outline",{"fieldId":68,"type":103,"text":104,"url":105,"mdicon":106},"threads","@wisteria.shunya@threads.net","https://www.threads.net/@wisteria.shunya","mdi-message-outline",{"id":108,"createdAt":109,"updatedAt":110,"publishedAt":110,"revisedAt":110,"title":111,"abstract":112,"eyecatch":113,"toc":25,"body":116,"category":117,"tags":122},"passkey","2026-06-28T15:27:58.839Z","2026-06-28T15:28:43.783Z","分かったようでよく分からないパスキー認証の仕組み - なぜ注目される？","パスワード認証に変わる認証方法として期待されるパスキー認証の仕組みについて、調べてみた理解をまとめてみた。",{"url":114,"height":24,"width":115},"https://images.microcms-assets.io/assets/16526c12b52b4a198b9cd25f4e1f803e/05100073c6254dccb2faf408a3d11614/hanagasa.jpg",1800,"\u003Ch2 id=\"hef725b6a43\">Introduction\u003C/h2>\u003Cp style=\"text-align: start\">WEBの世界では、ユーザーを認証する仕組みとしてパスワード認証が長らく主流となっています。これはクライアント（PC・スマートフォン等の端末）がユーザーIDとパスワードを認証先のサービス（Google、Apple、MS、Amazon、etc）に送信し、サービス側はあらかじめ登録されているユーザーIDとパスワード（通常はハッシュ化され元の文字列が分からない状態のもの）の組み合わせと比較、合致した場合は認証を成功とするものです。すなわち、パスワードという秘密の合言葉を知っている=本人であるとみなすシンプルな仕組み、一見極めて効率的なものと考えられていました。\u003C/p>\u003Cp style=\"text-align: start\">ところが、ひとたびパスワードが第三者に知れ渡ってしまえば、いとも簡単になりすますことが可能な仕組みとも言えます。昨今 正規のログインページを模した偽のページにパスワードを入力させることでだまし取る手口が蔓延したり、パスワードを保持するサービス側が攻撃を受け情報を流出する等、パスワードの安全性は日々侵され続けています。直近でも\u003Ca href=\"https://www.kddi-webcommunications.co.jp/news/emergency/20260623a.html\" target=\"_blank\" rel=\"noopener noreferrer\">大手ISPが提供するメールサービスが攻撃を受け、パスワードを含む顧客情報が流出した可能性がある\u003C/a>というニュースが世間に衝撃を与えました。もはやパスワードのみに頼った認証では十分とは言い切れず、二段階認証等のパスワード認証を補完する仕組みも提案されていますが、パスワード自体は廃することはできていません。\u003C/p>\u003Cp style=\"text-align: start\">そんな今日、パスワード自体を使わない新しい認証方式として注目されているものがパスキー認証です。Google、Apple、MS、Amazonといった大手プラットフォーマーから始まり、徐々に各種サービスでも採用する動きが広がってきています。\u003C/p>\u003Cp style=\"text-align: start\">「パスキーは安全！」という一言で片づけられがちですが、何で安全・安心といえるのか？そもそもどんな仕組みなのか？利用者の視点でみたときに穴はないのか？\u003C/p>\u003Cp style=\"text-align: start\">何となくは分かっているつもりでも、ちゃんとは説明できない、いつもの状態に陥っていたので、改めて自分なりに調べてみました。\u003C/p>\u003Cp style=\"text-align: start\">このエントリーでは私の理解をもとに、パスキーについてまとめてみますが、「パスキーは安全だから使いましょう」という話ではなく、「なぜ安全と言われるのか」「どこまで安全で、どこに限界があるのか」を、できるだけ仕組みから整理してみます。\u003C/p>\u003Ch2 id=\"h0175a1252c\">パスキーとは？\u003C/h2>\u003Cp style=\"text-align: start\">パスキーとは、FIDO（Fast IDentity Online）で標準化された技術を利用した認証方式で、パスワードに代わり安全かつ便利な認証方法を目指して作られた仕組みです。\u003C/p>\u003Cp style=\"text-align: start\">パスワード認証では「秘密の合言葉（パスワード）を知っていること」を本人確認に利用します。一方、パスキー認証では、パスワードをサーバーへ送ることなく、「秘密鍵を持っていること（もちろん秘密鍵自体も送らず）」を証明することで本人確認を行います。\u003C/p>\u003Cp style=\"text-align: start\">利用者から見れば、生体認証やPINを入力するだけでログインできますが、その裏では公開鍵暗号方式を利用した認証が行われています。\u003C/p>\u003Cp style=\"text-align: start\">具体的な認証の流れを例え話を用いて説明してみます。\u003C/p>\u003Ch2 id=\"h367430e0da\">認証フロー\u003C/h2>\u003Cfigure>\u003Cimg src=\"https://images.microcms-assets.io/assets/16526c12b52b4a198b9cd25f4e1f803e/f24e8adabffd4a2c8db03881e02a002c/passkey.webp\" alt=\"\" width=\"1408\" height=\"768\">\u003C/figure>\u003Cp style=\"text-align: start\">最初におさらいもかねてパスワード認証の仕組みを見てみましょう。\u003Cbr>パスワード認証はあなたがユーザIDとパスワードをサーバーに送り、サーバーがその情報の正しさを検証することで、あなた本人からの正規の要求と判断するものです（パスワードを知っている=本人である）。\u003C/p>\u003Cp style=\"text-align: start\">次にパスキーの仕組みは次の通りです。\u003Cbr>あなたが認証をしたいページを訪れた際、サーバーはあなた宛にチャレンジと呼ばれる文書を送ってきます。あなたはその文書に押印し、サーバーへ返送します。このとき使用する印鑑は端末上の番人によって厳重に管理され、生体情報やPINからあなたからの依頼と判断された場合のみ押印してくれます。サーバー側は押印されたチャレンジと事前に提出された印鑑証明を照合し、合致すれば本人からの正規の要求と判断するものです（チャレンジに押印できる人=本人である）。\u003C/p>\u003Cp style=\"text-align: start\">パスワード認証とパスキー認証の最も大きな違いは、パスワード認証が「パスワード」という本人であることを証明するもの自体をサーバーに送るのに対し、パスキーは本人であることを証明する「印鑑」は端末から出ていくことはなく、それによって押印された文書（チャレンジ）のみがサーバーに送られること。パスワードと違い、押印された文書（チャレンジ）はそのサーバーに対する、その時限りの要求にしか使えません、仮に流失しても悪用できません、第三者があなたになりすますための情報としては価値がありません。これがパスワードとパスキーの最も大きな違いであり、その強みとも言えます。\u003C/p>\u003Cp style=\"text-align: start\">もう少しシステマチックに表現すると、サーバーから受け取ったチャレンジに対しクライアント上の認証器（生体認証やPINを確認し、秘密鍵を管理する端末内の仕組み）がユーザー本人からの要求であることを確認した上で、秘密鍵を用いてチャレンジに電子署名を付与する。電子署名が付与されたチャレンジを受け取ったサーバー側は公開鍵を用いて電子署名の正当性を検証、成功したら本人からの正規の要求と判断するものです（公開鍵暗号の仕組みについては後述）。\u003C/p>\u003Cp style=\"text-align: start\">パスキーのこの仕組みは公開鍵暗号と呼ばれる現在最もポピュラーで安全性の高いといわれる仕組みの上で成り立ち、印鑑は「秘密鍵」、印鑑証明は「公開鍵」と呼ばれます。\u003C/p>\u003Cp style=\"text-align: start\">パスキーがどんなものか、少しイメージはついてきたでしょうか？次にここまで理解した中で私が疑問に思ったポイントについて紐解いていこうと思います。\u003C/p>\u003Ch2 id=\"h07dccf862c\">よくある疑問\u003C/h2>\u003Ch3 id=\"hb06eab062f\">PINや生体認証情報はサーバーに送られない？\u003C/h3>\u003Cp style=\"text-align: start\">送られません。PINや生体情報は電子署名を付与する際、認証器が本人確認するためだけに使用するものであり、サーバー側に送られることはありません。サーバー側で持っておくメリットがそもそもありません。\u003C/p>\u003Ch3 id=\"h4ef1e81e00\">秘密鍵は端末内で厳重管理、端末を紛失したり機種交換したらどうなる？\u003C/h3>\u003Cp style=\"text-align: start\">ここがパスキーを理解する上で一番混乱したポイントでした。パスキーには2つの運用形態があります。\u003C/p>\u003Cul>\u003Cli>デバイス固定パスキー\u003C/li>\u003Cli>同期パスキー\u003C/li>\u003C/ul>\u003Cp style=\"text-align: start\">前者は完全に端末内で閉じたものとなり、もし端末を紛失したり機種変更した場合は再度パスキーの設定が必要になります。一方の後者は大手プラットフォーマー（Google、Apple、MS）が提供するアカウントに紐づけられ、同じアカウントでログインした端末間では相互利用できる仕組みとなっています。故に新しい端末が増えたケースであっても同じアカウントでログインすればパスキーも引き継がれ、これまでと同じように利用することができます。\u003C/p>\u003Cp style=\"text-align: start\">セキュリティ的な観点で見たとき、一見するとデバイス固有パスキーの方が安全に思えますが（秘密鍵を外部に置かないため）、そこは利便性とのトレードオフなのかなと。\u003C/p>\u003Ch3 id=\"he25938236b\">偽のサイトがチャレンジを送ってきたらどうなる？\u003C/h3>\u003Cp style=\"text-align: start\">チャレンジや電子署名に使用する鍵にはRP ID（Relying Party Identifier）と呼ばれる認証先のサービスを識別する情報が付与されています。ここにはパスキーをリクエストするドメイン名が当てられるため、仮に偽のサイトがチャレンジを送ったとしても正規のRP IDは設定されないため（偽サイトと正規のサイトではドメインが異なるため）、クライアント側は該当する（偽サイトの）RP IDの鍵がなくチャレンジは成功しません。よって偽サイトがチャレンジを送ってきたとしても何もできません。\u003C/p>\u003Cp style=\"text-align: start\">仮に偽サイト用のパスキーが作成されたとしても、それはあくまで偽サイト専用です。正規サイトに対する認証には利用できません。\u003C/p>\u003Ch3 id=\"hd73812f8cd\">サーバー側が公開鍵を漏洩したらどうなる？\u003C/h3>\u003Cp style=\"text-align: start\">公開鍵はその名の通り「公開されること」を前提とした鍵です。公開鍵は電子署名を検証するためにしか利用できないため、仮に漏洩したとしても何の害もありません。\u003C/p>\u003Cp style=\"text-align: start\">公開鍵から秘密鍵（電子署名する際に使用する鍵）をリバースすることは理論上 不可能ではありませんが、現代最高峰のコンピューターを駆使したとしても。。。現実的な時間では解読できないといわれています。\u003C/p>\u003Ch3 id=\"h4236273470\">もし電子署名付チャレンジが盗まれたら？\u003C/h3>\u003Cp style=\"text-align: start\">前述した通り、チャレンジはあるタイミングのリクエストに対して1回限りしか利用できません。またチャレンジの有効期間は長くて数分と短いものです。それ故に仮に盗んだとしてもパスワードのように1度入手すれば何度も使うことができるような代物ではありません。\u003C/p>\u003Cp style=\"text-align: start\">さらに現実には通信自体もTLSで暗号化されているため、チャレンジを盗み見ること自体も容易ではありません。（もしそれができれば、チャレンジやパスワードを盗まなくてもやりたい放題できちゃう。。。）。\u003C/p>\u003Ch3 id=\"h4b5b7ac737\">パスキーなら絶対安全？\u003C/h3>\u003Cp style=\"text-align: start\">パスキー認証は確かにパスワード認証と比べリスクの小さい方式ではありますが、だからと言って絶対安全、盲目的に信用してよいもではありません。セキュリティの世界に「絶対」は存在しません。\u003C/p>\u003Cp style=\"text-align: start\">パスキーを導入した認証システム全体の問題の1つにパスワード認証が並行し残っている現実があります。現在パスキーは過渡期といえ、パスキーだけですべての認証が賄える状態に至ってはいません。設定したパスキーが正しく動かないケースや予期せぬ端末の故障等に備え、多くのサービスがパスワードによる認証を残しています。つまりそのパスワード使った認証が残っている以上、パスキーを使っていても絶対安全とは言えないのです。\u003C/p>\u003Cp style=\"text-align: start\">例えば、悪意のある第三者が「パスキーの再設定が必要になりました、パスワードを入力し再設定してください」とメールを送ってきたらどうなるでしょう？ユーザー目線ではパスキーの再設定なのでパスキーは使えない→バックアップ用のパスワードの入力を求められることは至極自然なことに感じてしまいます。そうしてパスワードを盗まれてしまうと、そのパスワード認証が残っている限り、アカウントへの不正アクセスにつながるおそれがあります。\u003C/p>\u003Cp style=\"text-align: start\">パスキーによって玄関の防御をいくら高めても、裏口（パスワード認証）が今まで通り残っていればそこを突かれてしまう、パスキーを使っていれば絶対安全とは言えない一例にあたります。\u003C/p>\u003Cp style=\"text-align: start\">パスキーは、パスワード認証が抱えていた多くの問題を解決してくれる、とても優れた技術です。しかし、セキュリティは認証方式ひとつで決まるものではありません。アカウント復旧や例外時の運用を含めた「認証システム全体」で考える必要があります。\u003C/p>\u003Cp style=\"text-align: start\">「パスキーだから安全」ではなく、「どこまで攻撃の余地を減らせるか」。その積み重ねこそが、現実のセキュリティ設計なのだと思います。\u003C/p>\u003Ch2 id=\"h8aaba2f937\">パスキーを支える公開鍵暗号とは\u003C/h2>\u003Cp style=\"text-align: start\">最後にパスキーを支える公開鍵暗号方式について簡単に説明したいと思います、興味がある方はぜひ。\u003C/p>\u003Cp style=\"text-align: start\">この方式は現代において最も普及している方式で、情報を暗号化して安全に送る用途だけでなく、電子署名によって送信者が本人であることを証明する用途にも利用されています。\u003C/p>\u003Cp style=\"text-align: start\">大きな特徴として、公開鍵と秘密鍵という鍵のペアが作られる点が挙げられます。この2つの鍵は対になる関係にあり、それぞれ役割が決まっています。例えば、秘密鍵でしかできない処理や、公開鍵でしかできない処理があります。\u003C/p>\u003Cp style=\"text-align: start\">パスキーで利用される電子署名では、秘密鍵を持つ人だけが文書に電子署名を付与できます。一方、その電子署名が本物かどうかは、誰でも公開鍵を使って検証できます。\u003C/p>\u003Cp style=\"text-align: start\">つまり、\u003C/p>\u003Cul>\u003Cli>電子署名を作成できるのは秘密鍵を持つ本人だけ\u003C/li>\u003Cli>電子署名が正しいかどうかは公開鍵で誰でも確認できる\u003C/li>\u003C/ul>\u003Cp style=\"text-align: start\">という役割分担になっています。\u003C/p>\u003Cp style=\"text-align: start\">パスキー認証では、この性質を利用してサーバーが送ったチャレンジに対し、クライアントが秘密鍵で電子署名を付与します。サーバーはあらかじめ登録されている公開鍵を使ってその電子署名を検証し、正しいことが確認できれば「秘密鍵を持つ本人からの要求」であると判断します。\u003C/p>\u003Cp style=\"text-align: start\">重要なのは、秘密鍵は認証時であっても端末の外へ送られないという点です。サーバーへ送られるのは電子署名が付与されたチャレンジだけであり、秘密鍵そのものが漏えいすることはありません。\u003C/p>\u003Cp style=\"text-align: start\">もちろん、公開鍵から秘密鍵を求めることは理論上不可能ではありません。しかし公開鍵暗号方式は、現在知られている計算方法では現実的な時間で解くことが極めて困難な数学的性質を利用しています。そのため、現代の計算能力では十分に安全な方式として、パスキーだけでなくインターネット上の暗号通信や電子証明書など、さまざまな場面で利用されています。\u003C/p>\u003Ch2 id=\"ha214098e44\">まとめ\u003C/h2>\u003Cp style=\"text-align: start\">パスキーという何だか掴みどころのないものについて、その仕組みやぱっと思いつく疑問点、パスワード認証との比較についてまとめてみました。\u003C/p>\u003Cp style=\"text-align: start\">パスキーの仕組み、パスワードに比べた優位性は腹落ちしたものの、パスワード認証がバックアップ的に残っている現状等も加味すると、それ単独で導入したから絶対安全といえるものではない、という点も改めて理解できました。\u003C/p>\u003Cp style=\"text-align: start\">セキュリティ対策は、個々の技術だけを見て評価するものではなく、アカウント復旧や例外時の運用も含めた「認証システム全体」で考え、リスクと利便性のトレードオフを見極めることが大切と改めて感じました。\u003C/p>\u003Ch2 id=\"h7605dc6208\">参考文献\u003C/h2>\u003Cblockquote>\u003Cp>\u003Ca href=\"https://techblog.yahoo.co.jp/entry/2023080730431354/\" target=\"_blank\" rel=\"noopener noreferrer\">FIDO認証＆パスキー総復習（認証の仕組みやパスキー登場までの経緯）- Yahoo! JAPAN Tech Blog\u003C/a>\u003C/p>\u003C/blockquote>",{"id":28,"createdAt":118,"updatedAt":119,"publishedAt":118,"revisedAt":120,"cat_name":121},"2021-11-03T11:59:30.255Z","2021-12-04T15:57:56.241Z","2021-12-04T15:57:46.597Z","Tech-TIPS",[123],{"id":124,"createdAt":125,"updatedAt":126,"publishedAt":125,"revisedAt":125,"name":127},"ittips","2024-04-14T14:36:01.704Z","2024-05-07T13:58:58.11Z","IT知識",{"status":129,"code":130,"abstract":131,"useCache":51,"saveCache":25},"S","000","\u003Cp>パスキー認証は、パスワードに代わる新しい認証方式です。公開鍵暗号技術を利用し、パスワードをサーバーに送信せずに本人確認を行います。利用者は生体認証やPIN入力だけでログインでき、秘密鍵は端末内で厳重に管理されます。チャレンジと呼ばれる文書に電子署名を付与してサーバーに送る仕組みで、偽サイトからの攻撃や秘密鍵の漏洩リスクを低減します。ただし、パスワード認証が残っている現状では絶対安全とは言えず、認証システム全体での対策が重要です。\u003C/p>",1782660601223]