はてなブックマーク

はじめに 認証や認可の実現方法は、システム開発における頻出の関心事の一つかと思います。そんな中、JSON Web Token（JWT）／OAuth2.0／Open ID Connect（OIDC）という言葉もよく耳にするところです。 しかし、「JWTって結局どう使うの？」「OAuth2.0やOIDCってJWTとどう関係するの？」「OAuth2.0とOIDCの違いって何？」という疑問を持つ方も多いのではないでしょうか。 また、JWTに「署名」や「検証」といったキーワードが絡んでくると、途端にハードルが上がったように感じるものです。 これらのキーワードについては既に沢山の記事が公開されていますが、本記事では以下に焦点を当てて解説していこうと思います。 JWT／OAuth2.0／OIDCの関係性を明らかにする OAuth2.0／OIDCより先にJWTを理解することで混乱を防ぐ JWTをシステム開

はじめに 世の中には5Gなどのモバイル規格やTV放送、ETCなど電波を用いて無線で様々な情報を伝送する規格が存在します。一方、電波行政を管轄する総務省の電波利用ポータルによると、 「一方で、電波は大変デリケートなので、ルールを守らないと混信や妨害を起こしてしまいます。 電波の利用ルールをご理解いただき、クリーンな電波利用環境の維持にご協力下さい。」 との注意喚起が行われています。 そのため、各種無線規格には電波法及び関連法令により様々な制限が課されているため、我々は許された範囲内で電波を有効利用する必要があります。本シリーズでは、電波法で許された範囲内で電波を有効利用するため、各種無線規格をとことん使ってみた結果をご紹介いたします。 総務省　電波利用ポータル　電波の利用ルール　より https://www.tele.soumu.go.jp/j/adm/monitoring/summary/

はじめに はじめまして。NTTデータの奥村です。 最近は内部向けのちょっとしたドキュメントをMarkdown形式で記載することは結構あるのかなと思います。GitHubなどのリポジトリサービスやNotionなどのドキュメント共有サービスを全員が利用できればよいのですが、コストや組織のポリシーなどの関係でそうしたサービスが利用できないケースだと、関係者限定でMarkdownのファイルを見やすい形で共有するのに困ることがあります。 本記事では、上記のようなケースで役に立つ仕組みをAmazon Web Services (AWS)を利用して構築する方法を紹介させていただきます。 全体構成 まず、ドキュメント執筆者は何らかのリポジトリサービスにMarkdownファイルを配置します。次に、CI/CDサービスのCodePipelineがビルドサービスのCodeBuildを呼び出し、静的サイトジェネレータ

注目を集めるPostgreSQL＋Analytics 先日、SnowflakeとDatabricksのそれぞれの年次イベントでPostgreSQLに関連する企業の買収が大々的に発表されました。 両社は分析系（OLAP）のソリューションを提供する比較的大きなベンダーであり、過去にはOLTP系への進出を目指したデータストアの開発が注目されたこともありました（SnowflakeのUnistoreが典型です）。 彼らは今後、PostgreSQLを自社がカバーできていなかった領域で適用することで、現在のメガクラウドのようにOLTP用途のRDBとOLAPのソリューションを統合してくることが予想されます。 そして、多くの利用者を持つオープンソースのPostgreSQL（コミュニティ版と言っても良いかも知れません）においても、OLAPとの統合という流れは今後確実に訪れるというのが、私個人の予想です。 今回

はじめに 本連載記事「非機能要求グレードの歩き方」シリーズでは、 30年以上にわたり金融IT基盤に携わる中で得た経験と知識をもとに、 「やらかしがちな」技術的課題について、IPA[1]の非機能要求グレード[2]に沿って解説します。 （※筆者は非機能要求グレード初版の執筆に関わった経験があり、行間を含めて解説します。） 併せて「😱あったら怖い本当の話」として、実際に起きたことを、脱色デフォルメしたフィクションにして紹介します。 共通の注意事項（用語説明） 非機能要求グレード表には、多くの項目が含まれています。 大項目(6)、中項目(35)、小項目(118)、メトリクス(238) 用語説明(非機能要求グレードより抜粋） (非機能要求グレード 2018 利用ガイド [解説編] P19[3] より抜粋) 小項目: ユーザとベンダの間で合意される非機能要求を示す項目。 重要項目: 非機能要求を検討

はじめに RSA暗号は、巨大な整数の素因数分解の困難性を安全性の根拠とする公開鍵暗号方式です。特にRSA-2048は、2048ビット長の合成数（10進数で約600桁）を利用しており、現代のスーパーコンピューターをもってしても、既存の素因数分解アルゴリズムでは現実的な時間内での分解は困難です。しかし、もし非常に大規模な量子コンピューターが実現すれば、従来のアルゴリズムと比較して飛躍的に高速な素因数分解アルゴリズムが実行可能になると予想されています。 では、RSA-2048を解読するためには、どの程度の規模の量子コンピューターが必要になるのでしょうか？ 2019年、GidneyとEkeråは、誤り率0.1%以下の2000万量子ビットを持つ量子コンピューターがあれば、RSA-2048を8時間で解読できるという推定を発表しました[1]。この件に関する日本語の解説は、以下の記事にまとめられています。

はじめに 本シリーズでは、Amazon Web Services (AWS) が提供しているAWS Well-Architected Frameworkのハイブリッドネットワーキングレンズを取り上げ、実際にどのような観点でチェックすべきか、そのポイントを前編と後編の2回にわたってご紹介します。本記事では、後編の信頼性、パフォーマンス効率、コスト最適化のチェックポイントについてご紹介します。 AWS Well-Architected Frameworkおよびハイブリッドネットワーキングレンズの概要については、前編の記事をご覧下さい。 本記事で得られるメリット ハイブリッドネットワーキングレンズは関連する追加のベストプラクティスが提供されていますが、「どのような時に何をすればよいか」が一目で分かりづらいことがあります。そこで、本記事はベストプラクティスをシンプルかつ明解なチェックポイントに要約

はじめに Amazon Web Services (AWS) が提供するAWS Well-Architected Frameworkは、AWSアーキテクチャを評価するためのベストプラクティスとして広く知られています。このフレームワークをベースとし、特定の業界やテクノロジー領域に特化した観点を提供するレンズがあることをご存じでしょうか。 本シリーズでは、ハイブリッドネットワーキングレンズを取り上げ、実際にどのような観点でチェックすべきか、そのポイントを前編と後編の2回にわたってご紹介します。本記事では、前編のオペレーショナルエクセレンス、セキュリティのチェックポイントについてご紹介します。 AWS Well-Architected Framework AWS Well-Architected Frameworkは、アーキテクチャを評価するためのベストプラクティスを提供しています。オペレーショ

近年話題のRAG（Retrieval-Augmented Generation）ですが、「社内資料」や「業務ドキュメント」としてよく使われる パワポ（PowerPoint）資料 に対しても応用できたら便利だと思いませんか？ この記事では、 「Cohere Embed 4」 + 「Gemini」 + 「FAISS」 を使って、 パワポ資料向けRAGシステム を構築する手順を紹介します。 初心者でも動かしやすいように、今回は一連のシステムをライトに構築・解説します。 はじめに：自己紹介 はじめまして。株式会社NTTデータグループ 技術革新統括本部 Innovation技術部の 割田 祥（わりた あきら） と申します。 業務では ローカルLLMのビジネス適用 を目指したFine-Tuning技術やアーキテクチャ設計などの研究開発を行っています。 今回は本業とは少し離れてはいますが、Cohereが

はじめに データエンジニアをやっておりますTaichiです。 最近Apache Icebergという単語をよく耳にするようになりました。 Icebergの処理エンジンといえば Apache Spark Apache Flink Trino などでしょうか。このラインナップ、構築/運用するのは結構ハードなものが多いと思いませんか？ 例えば、私のプロジェクトではSparkを使った構成でデータ処理を実施していますが、以下のような具体的な課題に直面しました。 Apache Hadoopのクラスタ構築作業や、Sparkを動かすために専用の記述（PySpark）が必要になる等、一定の学習が必要。 PySparkの記述の仕方によっては、性能が全然出ずにレスポンスが返ってこなかったり、OutOfMemoryになる場合があり、かつ解析やチューニングの難易度が高い。 クラウド前提であれば、マネージドHadoo

30年以上にわたり金融IT基盤に携わる中で得た経験と知識をもとに、「やらかしがちな」技術的課題について、IPA[1]の非機能要求グレード[2]に沿って解説します。 ※筆者は非機能要求グレード初版の執筆に関わった経験があり、行間を含めて解説します。 本記事では、オンライン性能要件における「B.1 業務処理量」に焦点を当てて解説します。 B.1 業務処理量の定義とオンライン性能要件 オンライン性能要件をまとめる際には、システムの性能目標値を決定する前に、その前提となる「業務処理量」を具体に定義することが重要です。 これは、1つの業務処理で発生する取引数は、インターフェース設計に依存して大幅に異なることがあるからです。 最初に着手するべきは、設計に依存しない業務処理量を明確にすることです。 下表は、非機能要求グレード 大項目「B:性能・拡張性」-中項目「B.1 業務処理量」のうち、オンライン性能

はじめに 昨今、欧州や日本を中心に発展しつつある「データスペース」について、皆さんに手を動かしながら体験頂けるようなブログを書いてみます。 本記事の想定読者 ITの基礎的素養はあるけど、データスペースのことをあまり知らない方 様々な分野でデータ利活用を検討している方 そもそもデータスペースとは データスペースとは、参加する組織・企業同士が互いに信頼できる仕組みのもとで、安全かつ自由にデータをやり取りできる制度と技術基盤が整った空間のことを指します。 こうした制度・技術の構築・標準化により、業界・組織・企業間のコラボレーションを加速し、横断的な課題解決や新たなデジタルサービスの創出を支えることができます。 データスペースは、近年欧州や日本を中心に広がりを見せています。以下の図はデータスペースの概念を表しています。データスペースの各参加者は、「コネクタ」と呼ばれるソフトウェアを用いて、「カタロ