はてなブックマーク

はじめに 世よの中なかには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の基礎きそ的てき素養そようはあるけど、データスペースのことをあまり知しらない方ほう 様々さまざまな分野ぶんやでデータ利り活用かつようを検討けんとうしている方ほう そもそもデータスペースとは データスペースとは、参加さんかする組織そしき・企業きぎょう同士どうしが互たがいに信頼しんらいできる仕組しくみのもとで、安全あんぜんかつ自由じゆうにデータをやり取とりできる制度せいどと技術ぎじゅつ基盤きばんが整ととのった空間くうかんのことを指さします。 こうした制度せいど・技術ぎじゅつの構築こうちく・標準ひょうじゅん化かにより、業界ぎょうかい・組織そしき・企業きぎょう間あいだのコラボレーションを加速かそくし、横断おうだん的てきな課題かだい解決かいけつや新あらたなデジタルサービスの創出そうしゅつを支ささえることができます。 データスペースは、近年きんねん欧州おうしゅうや日本にっぽんを中心ちゅうしんに広ひろがりを見みせています。以下いかの図ずはデータスペースの概念がいねんを表あらわしています。データスペースの各かく参加さんか者しゃは、「コネクタ」と呼よばれるソフトウェアを用もちいて、「カタロ