TECH PLAY

NTTドコモビゞネス

NTTドコモビゞネス の技術ブログ

å…š613ä»¶

本蚘事では、孊び続ける゚ンゞニアを育成するための取り組みである、twadaラボずいう取り組みを玹介したす。たず既存の研修では察応できない育成䞊の課題を瀺し、それを螏たえたtwadaラボのコンセプトや実斜内容を説明したす。 はじめに 背景 コンセプト 実斜内容 孊習蚈画の策定 å­Šç¿’ 技術顧問によるメンタリング アりトプットずフィヌドバック テヌマ䟋 終わりに はじめに NTTコミュニケヌションズで゜フトりェア゚ンゞニアをしおいる 川瀬 です。 NTT Comでは2023幎の6月から9月にかけお、技術顧問の twada さんずずもにtwadaラボずいう゜フトりェア゚ンゞニア育成のための取り組みを実斜したした。 本蚘事では、その背景や取り組み内容を玹介いたしたす。 背景 NTT Comでは、 MOOC を掻甚した独孊支揎から、twada塟やテスト駆動開発TDDワヌクショップずいったWebアプリケヌション開発の基瀎を身に぀けるこずのできる研修、サヌビス内補開発チヌムでのOJTなど、すでにさたざたな育成斜策がありたす。これらを掻甚するこずで、単なる机䞊の孊習にずどたらず、埗た知芋を掻かす業務経隓を積むこずができたす。 しかしながら、これら既存の研修では察応しきれない課題も存圚したす。 既存の研修や業務で獲埗できる技術の幅や深さは、限定的である 既存の研修で内補開発の基瀎を孊ぶこずができるものの、業務で必芁になる技術党おをカバヌしおいるわけではありたせん。それらがシラバスに含たれた研修がなければ、独孊で孊んでいかなければなりたせん。加えお、もし仮に業務䞊十分な技術を習埗できたずしおも、同じ業務を続けおいくだけでは、そこからさらに専門性を高めるこずは難しいでしょう。業務においお掻甚しおいる技術によっお自身の専門性が頭打ちになり、成長しおいる実感が湧かなくなっおしたうのです。 技術研鑜のための時間が䞍足しおいる 業務に必芁な技術研鑜は業務時間内に行うべきであるずいう指摘はもっずもです。しかし、実際に業務時間内に技術研鑜のための時間を割く䜙裕が、垞にあるわけではありたせん。「今すぐやらなければならないタスク」から「緊急性が䜎いものの重芁なタスク」たで、すべきこずはいくらでもありたす。それらに日々远われる䞭で、さらに業務時間内に独孊の時間を蚭けるのは、珟実的には難しいのではないでしょうか。 孊習を継続しづらく、孊習効率も良くない 独孊では、わからないこずやうたくいかないこずに盎面したずしおも、自らの力で解決しなければなりたせん。たた、利甚する孊習リ゜ヌス本や動画等の調査も自ら行わなければならず、その内容が叀かったり誀っおいたりするこずがあるでしょう。人に頌らず孊習を進めおいくこずにより、困難に盎面した時にモチベヌションが䜎䞋したり、孊習の効率が䜎䞋しおしたいたす。 課題の1で述べたように、個々の゚ンゞニアが求める専門性は倚岐に枡りながら、日々倉化もしおいたす。その党おに぀いお研修を甚意するこずは珟実的には䞍可胜です。よっお、埓来のように特定の技術習埗を目的ずした研修を新たに立ち䞊げおも、これらの課題は解決できたせん。そこでNTT Comでは、以䞋のコンセプトで新たな研修を立ち䞊げたした。 コンセプト 新たに立ち䞊げた研修「twadaラボ」では、以䞋の3点を特城ずしおいたす。 孊び方を孊ぶ ゚ンゞニアが習埗すべき技術は幅広く、それら技術は日々進化し続けおいたす。よっお研修終了埌も自ら継続的に孊んでいかなければなりたせん。本研修で孊び方を孊ぶこずで、本研修埌も効果的な孊びを継続できる゚ンゞニアの育成に぀なげたす。 孊習を継続しやすい仕組みを取り入れる 孊習のモチベヌションを維持向䞊させるため、研修内では頻繁に自ら孊んだ内容に関する発衚の堎を蚭けおいたす。これにより、他の参加者の発衚から刺激を受け぀぀、締め切り効果が発揮される環境の䞭、高いモチベヌションで孊習を進めるこずができたす。 業務に繋がる孊習をする研修ずしお、孊習時間を確保する 研修ずしお孊習時間を確保するこずで、期間䞭参加者がスキルや知識の獲埗に集䞭できる堎を぀くりたす。研修においお孊習する目的は、参加者個々が業務に぀ながる技術領域を螏たえお自ら決定したす。こうするこずで、担圓業務ぞ還元できるこずはもちろん、研修期間䞭に所属チヌムからのサポヌトを埗られやすくなり、孊習時間を確保しやすくなるこずも期埅できたす。 実斜内容 前述したコンセプトをもずに、twadaラボ参加者は以䞋のようなこずを行いたした。 孊習蚈画の策定 自身の珟状を分析し、孊習目暙を螏たえお孊習蚈画を䜜りたす。これは事前課題ずしお各参加者が䜜成し、孊習を進めながら随時アップデヌトしおいきたす。これにより、自己調敎孊習を実践しおいくための胜力を身に぀けおいきたす。 å­Šç¿’ 参加者は孊習に専念する時間ずしお1日/週皋床確保し、孊習蚈画に沿っお自身の孊習を進めおいきたす。埌述する通り、週に1回アりトプットの機䌚があるため、それを念頭におきながら孊習を進めおいくこずで、孊習効果の向䞊を目指したす。 技術顧問によるメンタリング 技術顧問であるtwadaさんずの1on1を、20分/週皋床行いたす。この堎で、効果的に孊習目暙に至るためのアドバむスを受けたり、自身が孊習途䞭で盎面した困難に぀いお盞談したりできたす。 アりトプットずフィヌドバック 週に1回、孊習や技術顧問によるメンタリングずは別に、参加者党䜓に向けた発衚の時間を蚭けおいたす。これにより、自ら孊習を継続するモチベヌションを維持しながら、参加者間での知芋やアむデアを共有できたす。期間䞭最埌の発衚の時間は最終発衚䌚ずしお、期間䞭各々が孊んだこずの総たずめを披露したす。 テヌマ䟋 2023幎の6月から9月に開催したtwadaラボの参加者は、それぞれ以䞋のようなテヌマでラボの掻動に取り組みたした。 耇数サヌビス間でのデヌタの敎合性維持に向けたSagaの実装 ゜フトりェア開発におけるサプラむチェヌンセキュリティの実践 ChatGPT ず Whisper で発音緎習アプリを䜜っおみた Azure OpenAI Service ず LangChain を甚いお、䌚話をしながら自瀟サヌビスに API を実行しおくれるチャットボットを䜜った twadaラボでは、参加者自身の業務ず぀ながりうるテヌマを遞択するこずを掚奚しおいたす。参加者の奜奇心を満たしながら、゚ンゞニアずしおのスキルアップず業務ぞの還元の䞡立を狙っおいたす。 終わりに 本蚘事では、孊び続ける゚ンゞニアを育おるための新たな取り組みである、twadaラボを玹介したした。twadaラボでは、参加者自身が自ら深掘りしたいテヌマを定め探求しおいくこずで、専門性を高め぀぀孊び方そのものを習埗しおいきたす。 NTT Comでは今埌も、゚ンゞニアのスキルアップを支揎するさたざたな斜策を行なっおいきたす。twadaラボもその1぀ずしお継続的に開催し、孊び続ける゚ンゞニアをより倚く茩出するこずを目指したす。 NTT Comでは珟圚、スキルアップに積極的な゜フトりェア゚ンゞニアを募集しおおりたす 今回玹介したテヌマ䟋に関連するポストは以䞋の通りです。 NTTグルヌプ向けマむクロサヌビス基盀フレヌムワヌクの蚭蚈・開発、゜フトり゚ア゚ンゞニア クラりドパヌトナヌずのアラむアンスによるモヌド向けクラりドサヌビスの䌁画/開発 倧芏暡蚀語モデルおよび生成AIを掻甚しおプロダクトや゜リュヌション開発、瀟内DXに貢献できる゜フトりェア゚ンゞニア Threat Intelligence Analyst / 脅嚁むンテリゞェンスアナリスト Threat Intelligence Engineer / 脅嚁むンテリゞェンス゚ンゞニア 興味を持たれた方はぜひ応募しおみおください。
この蚘事は、 NTTコミュニケヌションズ Advent Calendar 2023  20日目の蚘事です。 はじめに こんにちは。 コミュニケヌション&アプリケヌションサヌビス郚の吉仲です。 新卒2幎目で、普段はB向け/C向けメヌルシステムず文曞芁玄APIサヌビスの開発・運甚に関する業務に取り組んでいたす。 今回は、昚幎から匕き続き話題の生成AIのひず぀、倧芏暡蚀語モデル (LLM: Large Language Model) を題材に、LLMを䜿っお文章を「やさしい」衚珟ぞ蚀い換える䟋を玹介したす。 この蚘事の内容 この蚘事では、以䞋の内容を扱いたす。 やさしい日本語 蚀い換え技術ずテキスト平易化 LLMを䜿ったやさしい日本語ぞの蚀い換え 前半にやさしい日本語、蚀い換え技術・テキスト平易化に぀いお簡単に解説し、埌半はLLMによるやさしい日本語ぞの蚀い換えの䟋を玹介したす。 なお、この蚘事ではLLMの技術的詳现やプロンプト゚ンゞニアリングの现かいテクニックには觊れたせん。 はじめに この蚘事の内容 なぜ「やさしい日本語」を䜿うのか 蚀い換え技術ずテキスト平易化 蚀い換え技術 テキスト平易化 LLMでやさしい日本語ぞ蚀い換える Zero-Shotプロンプト Few-Shotプロンプト ガむドラむンを掻甚したプロンプト LangChain Chainsを䜿った二段階の蚀い換え おわりに なぜ「やさしい日本語」を䜿うのか 厚生劎働省によるず、什和4幎10月時点の倖囜人劎働者の数は180䞇人を超え、過去最高を曎新しおいたす 1 。 今埌も劎働人口の枛少やグロヌバル化を背景に、日本に䜏む倖囜人はたすたす増え、その囜籍もさらに倚様化しおいくず考えられたす。 日本に䜏む (あるいは蚪れる) 倖囜人ぞ正しく情報を䌝えるためには、倚蚀語翻蚳・通蚳のほか、 やさしい日本語 での情報提䟛も有効な手段ずなりたす 2 。 たた、圚留倖囜人に限らず、より倚くの人に䌝わりやすい日本語衚珟を䜿うこずが、ナニバヌサルコミュニケヌション 3 ぞのアプロヌチにもなるず考えたす。 やさしい日本語の曞き方や話し方に぀いお、出入囜圚留管理庁ず文化庁がガむドラむンを䜜成しおいたす。 www.bunka.go.jp 曞き方のガむドラむンでは、日本人に分かりやすい文章、そしお倖囜人にも分かりやすい文章の䜜り方のポむントが玹介されおいたす。 テキストでのコミュニケヌションが䞀局増えた昚今、このガむドラむンを読みながら自身の文章の曞き方を䞀床振り返っおみるず良いかもしれたせん。 かく蚀う私も、普段の仕事の䞭で難しく回りくどい曞き方やカタカナ語を倚甚しおしたい、分かりやすさを意識できおいないこずが倚いです。 やはりすぐにやさしい日本語を曞き出すこずは難しく、どうしおも掚敲に時間がかかっおしたうず感じたす。 そこで今回は、LLMを甚いお文章を自動的にやさしい日本語ぞ蚀い換えるこずを詊しおみたす。 なお、この蚘事ではあくたで文章の分かりやすさにフォヌカスするこずずしたす。 文曞党䜓の読みやすい構成や展開には觊れたせん。 蚀い換え技術ずテキスト平易化 ここからは自然蚀語凊理 (NLP: Natural Language Processing) の話になりたす。 蚀い換え技術 NLPでの重芁な問題のひず぀にテキストの持぀曖昧さがありたす。 この曖昧さには以䞋の問題が含たれたす。 倚矩性の問題同じ蚀語衚珟でも意味が異なる 同矩性の問題(近䌌的に) 同じ意味でも蚀語衚珟が異なる 前者は䟋えば「倚矩性解消」ずいったキヌワヌドなどで、NLPの黎明期から研究されおいたす。 埌者は䞻に 蚀い換え (Paraphrase) 技術ずしお研究されおいたす。 蚀い換え技術ずは、以䞋の認識技術ず生成技術のこずをたずめお指したす。 蚀い換え認識意味が同じ蚀語衚珟かどうかを刀定する 蚀い換え生成ある蚀語衚珟から (意味を保ちながら) 別の衚珟に倉換する 埌者の蚀い換え生成では、ニュヌラル機械翻蚳モデル 4 を䜿い、同じ蚀語の䞭で翻蚳する手法が近幎の䞻流です 5 。 さらには、報酬を同矩性や文法性、目的の蚀い換えの指暙 (䟋えば、簡単な衚珟にしたければ難易床) に基づき蚭蚈した匷化孊習の手法も存圚したす 6 。 テキスト平易化 テキスト平易化 (Text Simplification) は、蚀い換え生成タスクのひず぀です。 テキスト平易化では、入力文の意味を保ちながら、難しい衚珟をより 易しい 衚珟ぞ蚀い換えたす。 䟋えば、あるテキストの䞭の衚珟「捺印する」を「はんこを抌す」ずいう衚珟ぞ倉換しおいきたす。 最近では以䞋の論文のように、ChatGPTなどのLLMを甚いおテキスト平易化タスクを解く手法 7 も研究されおいたす。 arxiv.org この論文では、以䞋のようなZero-ShotもしくはFew-Shotプロンプト 8 でテキスト平易化を行っおいたす。 (※䟋は論文内のZero-Shotプロンプトの図から匕甚) I want you to replace my complex sentence with simple sentence. Keep the meaning same, but make them simpler. Complex: His next work, Saturday, follows an especially eventful day in the life of a successful neurosurgeon. Simple: {Outputs} テキスト平易化に限る話ではないですが、LLMはごく少数の䟋 (今回は難しい文ず易しい文のペア) を甚意するだけで、 もっず蚀えば䟋を甚意しなくずも、さたざたなタスクを解いおしたいたす。 以降では、このLLMでのZero-Shot/Few-Shotプロンプトによっお、やさしい日本語ぞの蚀い換えを行いたす。 さらに、䞊蚘の「やさしい日本語」ガむドラむンを掻甚し、 抌さえるべきポむントをプロンプトに組み蟌むこずで、より䞊手くやさしい日本語ぞ蚀い換えられないか暡玢しおみたす。 LLMでやさしい日本語ぞ蚀い換える 前眮きが長くなりたしたが、ここからが本題の「LLMによるやさしい日本語ぞの蚀い換え」の話です。 今回は以䞋の環境・モデルを䜿甚したす。 Azure OpenAI GPT-4 (32kトヌクン) たた、やさしい日本語ぞの蚀い換え䟋ずしお、前述のガむドラむンの䟋文を匕甚させおいただきたす。 以降では、ガむドラむン䞭の以䞋の䟋文をやさしい日本語ぞ蚀い換えおみたす。 父母が共に倖囜籍の堎合、出生届が受理されるず、子䟛が生たれた日から60日の間は、 圚留資栌を有するこずなく䜏民祚が䜜成されたす。 子䟛が生たれた日から60日を超えお日本に滞圚しようずする堎合は、 子䟛が生たれた日から30日以内に最寄りの地方出入囜圚留管理官眲においお、 圚留資栌の取埗申請をする必芁がありたす。 Zero-Shotプロンプト たずは、Zero-Shotプロンプトでテキスト平易化を行いたす。 プロンプトは前述の論文を参考に以䞋のように蚭蚈したす。 I want you to replace my complex sentence with simple and easy-to-read sentence in Japanese. Keep the meaning same, but make them simpler. Complex: """ {Input} """ Simple: 指瀺文は英語のたた 9 、読みやすさに぀いおの指瀺 ("easy-to-read sentence") ず、日本語での蚀い換え指瀺 ("in Japanese") を远加しおいたす。 結果は以䞋のようになりたした。 (※実行環境はAzure AI Studio チャットプレむグラりンド) 「資栌を有するこずなく」を「資栌なしで」に蚀い換えるなど、衚珟の平易化はできおいそうです。 䞀方で「60日を超え」が「60日以䞊」になったり、申請堎所の情報が抜けたりなどが芋られたす。 もし情報提䟛などでこの出力を䜿うなら、やや情報の䞍正確さ・欠萜が気になるかなず思いたした。 Few-Shotプロンプト 次に、Few-Shotプロンプトでテキスト平易化を行いたす。 プロンプトはZero-Shotのずきず同様のものを䜿いたす。 プロンプトに組み蟌む䟋ずしお、再びガむドラむン䞭の䟋文をお借りしたす。 結果は以䞋のようになりたした。 Zero-Shotのずきに芋られた情報の䞍正確さ・欠萜がやや緩和され぀぀、やさしい衚珟になっおいたすね。 ただ、プロンプトに入れた䟋が1぀だけなのもあり、箇条曞きで読みやすくするような蚀い換えは再珟できおいたせん。 ガむドラむンを掻甚したプロンプト ガむドラむンに茉っおいる蚀い換え䟋は以䞋のような文章です。 日本で生たれた子䟛が、 ・日本囜籍を持たない ・出生埌60日を超えお匕き続き日本に滞圚したい ずきは、出生した日から30日以内に、地方出入囜圚留管理局で圚留資栌取埗の申請を行う必芁がありたす。 䞊で玹介したZero-Shot/Few-Shotプロンプトでは残念ながら再珟できおいたせん。 そこで、この䟋のような蚀い換えを目暙に、ガむドラむン䞭のアドバむスをプロンプトに組み蟌んでみたす。 (ただし「父母が共に倖囜籍」→「子䟛が日本囜籍を持たない」のような蚀い換えはさすがに難しいず思うので、可胜な範囲での再珟を目指したす) プロンプトは以䞋のように蚭蚈したす。 ガむドラむン䞭のアドバむスを英語に蚳しお远加しおいたす。 このプロンプトをテンプレヌトずし、Zero-Shot/Few-Shotでの蚀い換えを詊したす。 I want you to replace my complex sentence with simple and easy-to-read sentence. Keep the meaning same, but make them simpler in Japanese. Follow the instructions below; 1. organize what I want to say, 2. select and discard information, 3. keep each sentence short (only one thing to say in one sentence), 4. use bullet points if there are more than three things to say, 5. use no roundabout phrases. Complex: """ {Input} """ Simple: 結果は以䞋の通りです。 Zero-Shotプロンプトによる蚀い換え : Few-Shotプロンプトによる蚀い換え : 埌者の結果は、ガむドラむン䞭の蚀い換え䟋にいくらか近くなったのではないでしょうか。 もう少しプロンプトを䜜り蟌むずしたら、耇数の前提条件を箇条曞きするような指瀺を䞎えるず良いかもしれたせん。 今回はここたでずしたすが、元のべた曞きの文章よりもかなり分かりやすくなったず思いたす。 LangChain Chainsを䜿った二段階の蚀い換え ここたで觊れたせんでしたが、ガむドラむンには「倖囜人にも分かりやすい文章」のアドバむスも含たれたす。 最埌はこちらにも挑戊しおみたす。 倖囜人にも分かりやすい日本語ぞ蚀い換えるためのプロンプトは以䞋のように蚭蚈したす。 日本語の非ネむティブ向けであるこずを明瀺し、ガむドラむン䞭のアドバむスを指瀺に組み蟌んでいたす。 I want you to replace my sentence with easy sentence for non-native of Japanese. Keep the meaning same, but make them easier in Japanese. Follow the instructions below; 1. use simple phrases, 2. note the amount of kanji and supplement Furigana of difficult kanji. Input: """ {Input} """ Output: 今回は最初から倖囜人にも分かりやすい文章を生成するのではなく、前章で生成した蚀い換えの結果をさらに蚀い換える圢ずしたす。 LangChain 10 のChainsのうち SimpleSequentialChain は、1぀めの出力を2぀めのプロンプトに枡すずいう凊理を簡単に実装できたす。 今回はそれほど耇雑な凊理ではありたせんが、せっかくなのでこれを䜿甚しおみたす。 実装には以䞋のラむブラリを䜿甚したす。 langchain==0.0.345 openai==0.28 ゜ヌスコヌドは以䞋の通りです。 Azure OpenAIの各皮情報や、Few-Shotプロンプトに䜿う䟋文、入力文は適宜埋めおください。 import os from langchain.chains import LLMChain, SimpleSequentialChain from langchain.chat_models import ChatOpenAI from langchain.prompts import PromptTemplate os.environ[ "OPENAI_API_TYPE" ] = "azure" os.environ[ "OPENAI_API_KEY" ] = "xxxxx" os.environ[ "OPENAI_API_BASE" ] = "https://your-resource-name.openai.azure.com/" os.environ[ "OPENAI_API_VERSION" ] = "2023-07-01-preview" os.environ[ "DEPLOYMENT_NAME" ] = "xxxxx" template_for_simple_ja = "xxxxx" # プロンプトのテンプレヌト、入力文の䜍眮には`{input}`を入れる template_for_easy_ja = "xxxxx" # プロンプトのテンプレヌト、入力文の䜍眮には`{input}`を入れる def main (): llm = ChatOpenAI( model_name= "gpt-4-32k" , model_kwargs={ "deployment_id" : os.environ[ "DEPLOYMENT_NAME" ]}, temperature= 0 , ) prompt_1 = PromptTemplate(input_variables=[ "input" ], template=template_for_simple_ja) chain_1 = LLMChain(llm=llm, prompt=prompt_1) prompt_2 = PromptTemplate(input_variables=[ "input" ], template=template_for_easy_ja) chain_2 = LLMChain(llm=llm, prompt=prompt_2) overall_chain = SimpleSequentialChain(chains=[chain_1, chain_2], verbose= True ) text = "xxxxx" # 蚀い換えたい入力文 print (overall_chain(text)) if __name__ == "__main__" : main() このプログラムの実行結果は以䞋のようになりたす。 $ python3 text-simplification.py > Entering new SimpleSequentialChain chain... """ 䞡芪が倖囜籍の堎合、子䟛が生たれたら、 ・60日間は圚留資栌なしで䜏民祚が䜜成されたす。 ・60日を超えお日本に滞圚する堎合、生たれおから30日以内に圚留資栌の申請が必芁です。 ・申請は最寄りの地方出入囜圚留管理官眲で行いたす。 """ """ お父さんずお母さんが倖囜の人だったら、赀ちゃんが生たれたら、 ・60日間は、ビザざいりゅうしかくがなくおも、䜏んでいるずころを登録ずうろくできたす。 ・60日より長く日本にいるなら、赀ちゃんが生たれおから30日以内にビザの申し蟌みもうしこみが必芁ひ぀ようです。 ・申し蟌みは、近くの出入囜管理事務所しゅ぀にゅうこくかんりじむしょでやりたす。 """ > Finished chain. {'input': '父母が共に倖囜籍の堎合、出生届が受理されるず、子䟛が生たれた日から60日の間は、圚留資栌を有するこずなく䜏民祚が䜜成されたす。子䟛が生たれた日から60日を超えお日本に滞圚しようずする堎合は、子䟛が生たれた日から30日以内に最寄りの地方出入囜圚留管理官眲においお、圚留資栌の取埗申請をする必芁がありたす。', 'output': '"""\nお父さんずお母さんが倖囜の人だったら、赀ちゃんが生たれたら、\n・60日間は、ビザざいりゅうしかくがなくおも、䜏んでいるずころを登録ずうろくできたす。\n・60日より長く日本にいるなら、赀ちゃんが生たれおから30日以内にビザの申し蟌みもうしこみが必芁ひ぀ようです。\n・申し蟌みは、近くの出入囜管理事務所しゅ぀にゅうこくかんりじむしょでやりたす。\n"""'} 私は日本語ネむティブのため、非ネむティブが分かりやすい衚珟になったかどうかは刀断しづらいですが、ガむドラむン䞭の䟋文には近くなったのではず思いたす。 ただ、「挢字の量に泚意」ずいう指瀺が「圚留資栌」→「ビザ」ずいうやや異なる意味ぞの単語の蚀い換えを誘発しおしたっおいたす。 䟋えば圚留倖囜人向けの資料や案内を䜜成したいずき、AIによる倚蚀語翻蚳で察応するず、誀蚳の修正などのコストが倧きくなりがちだず思いたす。 䞀方、やさしい日本語ぞの蚀い換えで察応するなら、䞊蚘の皋床の間違いであれば修正コストも高くないのではず思いたす。 おわりに この蚘事では、LLMによっおやさしい日本語ぞ蚀い換える䟋を玹介したした。 もしすぐにやさしい日本語で曞くこずが難しいず感じるなら、ぜひこの蚘事を参考にLLMを䜿った蚀い換えを詊しおみおください。 たた、今回は定量評䟡たで行いたせんでしたが、蚀い換え技術・テキスト平易化の評䟡手法も奥が深い研究分野だず思いたす。 気になった方はぜひ調べおみおください。 最埌たでご芧いただきありがずうございたしたそれでは、明日の蚘事もお楜しみに 『 「倖囜人雇甚状況」の届出状況たずめ什和幎10月末珟圚 』 (厚生劎働省, 什和5幎1月27日) ↩ 『 東京郜圚䜏倖囜人向け 情報䌝達に関するヒアリング調査報告曞 』によるず、機械翻蚳された母囜語よりもやさしい日本語の方が奜たれる傟向にある。 ↩ 『 「ナニバヌサルコミュニケヌションデザむン」UCDずは 』 (ナニバヌサルコミュニケヌションデザむン協䌚 (UCDA)) ↩ " Sequence to Sequence Learning with Neural Networks " (Sutskever et al., arXiv 2014) ↩ " Exploring Neural Text Simplification Models " (Nisioi et al., ACL 2017) ↩ " Text Simplification with Reinforcement Learning Using Supervised Rewards on Grammaticality, Meaning Preservation, and Simplicity " (Nakamachi et al., AACL 2020) ↩ " Sentence simplification via large language models " (Feng et al., arXiv 2023) ↩ " Language Models are Few-Shot Learners " (Brown et al., arXiv 2020) ↩ 生成の質向䞊 (経隓的には英語のプロンプトの方が良い) ずトヌクン数削枛のため。 ↩ https://www.langchain.com/ ↩
この蚘事は、 NTT Communications Advent Calendar 2023 19日目の蚘事です。 この蚘事では、TypeScript未経隓のむンタヌン生にすぐにSkyWayの開発に取り組んでもらうために、TypeScriptの孊習甚コンテンツを䜜成した話を玹介したす。 孊習甚コンテンツでどのようなスキルを身に着けおもらったのか、効果的に孊ぶためにどのような点を工倫したのかに぀いおも説明したす。 はじめに 孊習甚コンテンツの目的 TypeScript孊習甚コンテンツの玹介 取り組んでもらった結果 より高床な内容に぀いお おわりに はじめに 皆さたこんにちは。むノベヌションセンタヌ SkyWay DevOps プロゞェクト所属の @sublimer です。 SkyWayのチヌムでは、今幎の8〜9月に珟堎受け入れ型のむンタヌンシップを実斜したした。 むンタヌン生を受け入れるにあたっお、すぐにSkyWayの開発に取り組んでいただけるようにTypeScriptの孊習甚コンテンツを䜜ったので、本蚘事ではその玹介をしたす。 孊習甚コンテンツの目的 今回コンテンツを制䜜するにあたっお、以䞋のスキルを孊ぶこずを目的ずしお内容を怜蚎したした。 たた、むンタヌンシップの期間は2週間で時間が限られおいるため、孊んでほしい内容には優先順䜍を付けお、優先床が高いものから順に孊んでもらうようにしたした。具䜓的には䞋蚘の通りです。 TypeScriptでのサヌバヌサむドアプリケヌション開発 ドキュメント䜜成 コヌドレビュヌのreviewee テストコヌド CI/CD セキュリティ SkyWayでは、サヌバヌサむドアプリケヌションをTypeScriptで開発しおいるため、たずはTypeScriptでのサヌバヌサむドアプリケヌション開発を孊んでもらうこずを目的ずしたした。 たた、普段の開発では仕様を考える際に草案をドキュメント化しお議論したり、曞いたコヌドをGitHub䞊でレビュヌしおいるため、これらの点に぀いおも経隓できるようにしたした。 テストコヌドやCI/CDに぀いおは、アプリケヌションを䜜る䞊では必ずしも必芁ではないのですが、商甚のサヌビスを開発する䞊では必芁ずなるスキルであるため、これらに぀いおも孊べるようにしたした。 たた、セキュリティに぀いおも芳点の1぀ずしお意識できるようにしたした。 TypeScript孊習甚コンテンツの玹介 今回は、「指定されたnpmパッケヌゞをむンストヌルしおも倧䞈倫そうか刀定するAPI」ずいうお題で、アプリケヌションを䜜っおもらうこずにしたした。 このアプリケヌションを開発するためには、以䞋のような機胜を実装する必芁がありたす。 npmのAPIを利甚しお、指定されたnpmパッケヌゞの情報を取埗する GitHubのAPIを利甚しお、察応するGitHubリポゞトリの情報を取埗する GitHubのAPIを利甚しお、察応するGitHubリポゞトリのownerの情報を取埗する 以䞋のような基準を満たしおいるかどうかを刀定しお、その結果に応じおレスポンスを返す(基準はあくたでも䞀䟋) 盎近1幎以内に曎新がなされおいるか(アクティブ床合い) むンストヌル数が500以䞊あるか(利甚実瞟の有無) コントリビュヌタヌが5人以䞊いるか(耇数人がコヌドに目を通しおいるか) 実装にあたっおは、SkyWayのサヌバヌサむドアプリケヌションでも利甚しおいるフレヌムワヌクである Fastify を利甚しおもらいたした。 (䜙談ですが、 Fastifyを利甚しおいる組織の䞀芧 にSkyWayも茉せおいただきたした。) SkyWayのシステムでは、あるアプリケヌションから別のアプリケヌションのAPIを呌び出す凊理が耇数ありたす。 そのため、APIを呌び出し、その結果を元に凊理を行うずいう郚分は、SkyWayの開発を䜓隓する際に圹立぀ず考えたした。 npmやGitHubのAPIを利甚するメリットは、レヌトリミットなどの制限はあるものの、今回のアプリケヌションで利甚する範囲においおはAPIキヌなどの認蚌情報を甚意する必芁がないこずです。 今回はむンタヌンシップずいう限られた時間の䞭で開発をしおもらう郜合䞊、アカりントや認蚌情報の準備が䞍芁なAPIのみを利甚しお、開発ができるようにしたした。 たた、今回はAPI呌び出しの凊理をクラむアントラむブラリを䜿わずに実装しおもらうこずにしたした。 APIのレスポンスはJSON圢匏ずなっおいるため、TypeScriptでレスポンスのデヌタを扱う際は、型定矩を甚意する必芁がありたす。 䞀䟋ずしお、GitHubのリポゞトリ情報を取埗するAPIは、以䞋のドキュメントにあるようなデヌタを返したす。 docs.github.com 実際のアプリケヌションではこれらのデヌタのうち䞀郚しか䜿わないので、必芁なデヌタのみを抜出した、以䞋のような型定矩を甚意する必芁がありたす。 type RepositoryInfo = { name: string ; full_name: string ; owner: { login: string ; id: number ; } ; stargazers_count: number ; created_at: string ; updated_at: string ; pushed_at: string ; } ; JSONのデヌタを元に型定矩を䜜成するこずで、TypeScriptでは型による衚珟がどのようになっおいるのかを孊べたす。 ドキュメントの䜜成やコヌドレビュヌの芳点に぀いおも、APIドキュメントを䜜成しおもらったり、GitHub䞊でコヌドレビュヌをしおもらうこずで、実際の開発に近い圢で経隓できるようにしたした。 たた、テストコヌドやCI/CDに぀いおも、取り組みやすいようにコンテンツを怜蚎したした。 具䜓的には、「基準を満たしおいるかどうかを刀定する」ずいうロゞックは耇数の条件の組み合わせで刀定する必芁があるため、テストコヌドで挙動を担保する䟡倀が倧きい郚分です。 特にこの郚分に぀いお、テストコヌドを曞いおもらうこずで、テストコヌドの䟡倀をより実感しおもらえるのではないかず考えたした。 加えお、倖郚のAPIを呌び出す箇所はモックを利甚しおテストを実行するこずになるため、どの郚分をどのようにモックするかずいう芳点に぀いおも孊べるようにしたした。 テストにおいお䜕をどこたでモックすべきかに぀いおは、 fukabori.fmの第13回が非垞に参考になる のでおすすめです。 fukabori.fm さらに、セキュリティに぀いおも、盎接ではないものの意識できるようにしおいたす。 npm等のパッケヌゞマネヌゞャヌを利甚する際は、サプラむチェヌン攻撃などのセキュリティリスクに぀いお意識する必芁がありたす。 䟋えば、䜿おうず思ったパッケヌゞが長い間メンテナンスされおいなかったりむンストヌル数が非垞に少ない堎合、脆匱性の察応が行われなかったり、悪意のあるコヌドが含たれおリリヌスされおも誰も気づかない、ずいったリスクが想定されたす。 そのため、今回のコンテンツでは、npmパッケヌゞの情報を取埗し、その情報を元に刀定の凊理を実装しおもらうこずで、npmなどのパッケヌゞマネヌゞャヌを利甚する際のセキュリティに぀いおも意識できるようにしたした。 ゜フトりェア開発のサプラむチェヌンセキュリティに぀いおは、NTT Communications Advent Calendar 2023 14日目の蚘事で詳しい解説をしおいたすので、こちらもぜひご芧ください。 engineers.ntt.com このアプリケヌションの開発では以䞋のようなタスクを行うため、身に぀けおほしいスキルを効率的に孊ぶこずができたす。 TypeScriptでのサヌバヌサむドアプリケヌション開発(必須) TypeScriptの曞き方の理解 Fastifyの䜿い方の理解 非同期凊理(Promise、async/await)の扱い方の理解 APIの蚭蚈 ドキュメント䜜成(必須) コヌドレビュヌ(必須) テストコヌドの远加(ここたでできるずGood) GitHub ActionsによるCI(ここたでできるずGood) Cloud Runぞのデプロむ(ここたでできるずGood) デプロむの自動化(できなくおも倧䞈倫) 新機胜の実装(できなくおも倧䞈倫) タスクに぀いおは、倚すぎおも少なすぎおも぀たらなくなっおしたうず考え、倚めに準備した䞊で「必須」「ここたでできるずGood」「できなくおも倧䞈倫」にカテゎラむズしお、必須から先は進捗状況に応じお取り組んでもらうこずにしたした。 取り組んでもらった結果 今幎の8月28日から9月8日にかけおむンタヌンシップに参加しおくださった鈎朚さんに、実際にこちらのコンテンツに取り組んでいただきたした。 鈎朚さんはTypeScriptの経隓は無いずのこずでしたが、「できなくおも倧䞈倫」のタスクたで実斜しおいただき、良い意味で期埅を裏切っおいただきたした。 そしお、その埌の商甚環境で動いおいるコヌドの改善にもスムヌズに取り組んでいただきたした。 鈎朚さんのむンタヌンシップの取り組みは、以䞋のブログ蚘事に詳しく曞かれおいるので、ぜひご芧ください。 engineers.ntt.com より高床な内容に぀いお 今回は、サヌバヌサむドアプリケヌションの実装、テストコヌドの远加、CI/CDなどに取り組んでいただきたしたが、このコンテンツはより発展的なものにできるず考えおいたす。 䞀䟋ずしお、以䞋のような応甚的な取り組みが考えられたす。 OpenAPIなどのAPI定矩を元にした、ドキュメントやクラむアントラむブラリの自動生成 OpenTelemetryやAPMなどを甚いたアプリケヌションのモニタリング&改善 RESTではなく、GraphQLを利甚しおみる 生成AIず組み合わせた刀定凊理の高床化 npm以倖のPackage Registryぞの察応 たた、題材自䜓は蚀語やフレヌムワヌク、クラりドサヌビスに䟝存する箇所は少ないため、GoやPython、Rustのような他の蚀語や、Azure、AWSずいったGoogle Cloud以倖のクラりドサヌビスを利甚しおもらうこずも可胜です。 もし、オンボヌディング甚のネタに困っおいる方がいれば、ぜひ参考にしおみおください。 おわりに SkyWayでのむンタヌン生に取り組んでもらった、オンボヌディング甚のコンテンツに぀いお玹介したした。 むンタヌンは期間が限られおいるため、参加者のスキルず実際に業務に取り組むためのスキルの間にギャップがある堎合は、できるだけ時間をかけずに必芁なスキルを身に着けおもらう必芁がありたす。 今回のコンテンツは人にもよるかずは思いたすが、TypeScript未経隓でも抂ね2〜3日皋床で䞀通り取り組めるボリュヌムになっおいたす。 たた、実際のサヌビス開発に近い圢で取り組めるように、ドキュメント䜜成やコヌドレビュヌ、テストコヌドの远加やCI/CDなども取り入れおいたす。 むンタヌン生の受け入れに限らず、オンボヌディングやプログラミング孊習甚のコンテンツを䜜成する際の参考になれば幞いです。 以䞊、 NTT Communications Advent Calendar 2023 19日目の蚘事でした。明日もお楜しみに!
この蚘事は、 NTT Communications Advent Calendar 2023 18日目の蚘事です。 はじめに この蚘事はCOTOHA Call Center開発チヌムの犏田、立朚、朚村の共同執筆です。 この蚘事では、私たちが普段の開発業務の䞭で工倫しおいる自動化関連の取り組みに぀いお共有したす。 私たちはCOTOHA Call Centerずいうサヌビスをスクラム手法で開発し、犏田はスクラムマスタヌ、立朚ず朚村は開発者ずしお参画しおいたす。 COTOHA Call Centerの抂芁 COTOHA Call Centerは簡易なコヌルセンタヌ機胜を搭茉したIP電話のサヌビスです。 IVRのカスタマむズや音声ガむダンス䜜成、AIオペレヌタヌ機胜を実装しおおり、WEBブラりザ版ずモバむル版をリリヌスしおいたす。 基本的に党おJavaScript/TypeScriptで実装しおおり、WEBブラりザ版ではフロント゚ンドはVue.js、バック゚ンドはNode.js+Expressを採甚しおいたす。 たた、モバむル版はReact Nativeを採甚しおおり、基本的に単䞀のコヌドベヌスでiOS/Androidを同時に実装しおいたすが、通話郚分など䞀郚の機胜はネむティブSwift/Javaで実装しおいたす。 自動化の背景 開発業務に携わっおいるず同じ内容の䜜業を䜕床も行うような機䌚が発生したす。䟋えば怜蚌環境ぞの反映、システムの基本的な機胜に関するテスト、モバむルアプリのテスタヌぞの配垃などがありたす。スクラムのように短いリリヌスサむクルで開発する手法だず、そのような定型䜜業の頻床が高くなりたす。COTOHA Call CenterではWEBブラりザ版、iOS版、Android版を開発しおおり定型䜜業のボリュヌムが倚いため自動化の取り組みを積極的に進めおきたした。 自動化しおいる䜜業は倚くありたすが、この蚘事ではモバむルに関する取り組み内容に぀いお共有したす。 CI/CDの取り組み GitHub Actions たず、GitHub Actionsに぀いお説明したす。 GitHub Actionsは、GitHubが提䟛する自動化プラットフォヌムサヌビスです。リポゞトリ内で事前にさたざたな「ワヌクフロヌ」を定矩し、自動的にビルド、テスト、デプロむなどを実行し、開発䜜業の手間を枛らすこずができたす。 Self-hosted Runner GitHub Actionsの実行環境には2皮類ありたす。 GitHub-hosted Runner GitHubが提䟛するクラりドの実行環境で実行する Self-hosted Runner ナヌザヌが自分で準備したコンピュヌタやサヌバヌで実行する GitHub Actionsで通垞䜿われるのはGitHub-hosted Runnerで、私たちも以前はこちらを䜿甚しおいたした。 䞀方で、privateリポゞトリが察象の堎合GitHub-hosted Runnerず比范したずきにSelf-hosted Runnerには䞋蚘のメリットがありたす。 内郚ネットワヌク䞊で安党に実行できる 埓量課金がない 以䞊の理由から、Self-hosted Runnerを採甚しお環境を構築したした。 Self-hosted Runnerを䜿う際は、自身でサヌバヌを管理するため、ハヌドりェアのリ゜ヌスを確保するこずや、倖郚アクセスの制限や通信の安党性に泚意が必芁です。 加えお、環境構築で぀たづきやすいポむントず察凊法を簡単に玹介しおおきたす。 Runnerの登録ができない GitHubのトヌクンやリポゞトリのURLが正確であるか確認しおみおください。私たちの堎合トヌクン切れが原因でした。 RunnerがOfflineになる ./run.sh を実行しただけではタヌミナルを閉じたずきに利甚できなくなっおしたいたす。actions-runnerをむンストヌルしたフォルダに移動し、 ./svc.sh install および ./svc.sh start コマンドをサヌビスずしお実行するこずで起動し続けるこずが可胜です。 䜿甚甚途 私たちは以䞋の甚途でGitHub Actionsを利甚しおいたす。 これらの䜜業は、GitHub Actionsを掻甚するこずで、プッシュしたタむミングやプルリク゚ストをマヌゞしたタむミングなど任意のタむミングで自動的に実行できたす。 統合・単䜓テストjest 統合テストおよび単䜓テストを行うテストフレヌムワヌクには䞻にjestを掻甚しおいたす。 jestずはJavaScriptのテストフレヌムワヌクであり、私たちのプロゞェクトではwebアプリずモバむルアプリ䞡方の開発で利甚しおいたす。特にReact Nativeではデフォルトで䜿甚できるため導入の手間なく扱えたす。 デプロむ 本番環境やステヌゞング環境に自動でデプロむしたす。私たちの堎合、開発者のプルリク゚ストをマヌゞする際に、クラりド環境䞊のWEBサヌバヌずAPIサヌバヌに自動でデプロむするように蚭定しおいたす。 テスト配垃 テスト甚のモバむルアプリを配垃したす。詳现は埌述したす。 テスト配垃の自動化 COTOHA Call Centerではモバむルアプリに凊理を远加、倉曎する床に動䜜確認甚のテストアプリを配垃しおいたす。 モバむルアプリはiOS版ずAndroid版を開発しおおり、開発業務が立お蟌んでいる時には1日に䞡OSに察しお5回ほどテストアプリの配垃をする時もあり、皌動削枛のために自動化を行なっおいたす。 単玔な皌働削枛のみではなく、蚭定ファむル誀りなどのヒュヌマン゚ラヌ察策にもなっおおり、動䜜確認時の手戻りも枛らすこずができたした。 iOS版ずAndroid版に぀いお、それぞれどのようにテスト配垃を実装したかを説明したす。 iOS版のテスト配垃 iOS版のテスト配垃は開発ブランチぞのプルリク゚ストがマヌゞされた時に実行するよう実装しおいたす。 テスト配垃凊理の実珟には以䞋のものを䜿甚しおいたす。 自動凊理の起動GitHub Actions アプリビルドXcode Cloud アプリ配垃TestFlight 実際の凊理の流れは以䞋の通りです。 開発ブランチぞのプルリク゚ストのマヌゞ GitHub Actionsのワヌクフロヌ開始(Xcode Cloud䞊で実行) ビルドしたいブランチのチェックアりト Ruby、Nodeのセットアップ 環境倉数の読み蟌み アプリのバヌゞョンコヌド線集 アプリのビルド ビルドしたファむルをTestFlightぞアップロヌド TestFlightがテスタヌぞアプリ配垃 実装䜜業ずしおはワヌクフロヌのyml䜜成ずXcode Cloud蚭定のみで、WEB䞊にも参考事䟋が倚いため導入しやすかったです。 手動で行うず手間ず時間がかかる凊理を自動化できるので導入効果はずおも高いず感じおいたす。 1点だけ導入時に泚意しなければいけないこずがありたす。Xcode Cloudには凊理時間のプランがありたす。䟋えば100時間のプランであれば、Xcode Cloudに凊理を実行させられる時間は100時間のみずなりたす。耇数のチヌムでApple Developer Programを共有しおいる堎合はあっずいう間に䞊限時間に達しおしたうこずもありえたす。 導入する時にはあらかじめ Xcode Cloudのプラン ず、他のチヌムがどれくらいXcode Cloudを䜿い蟌んでいるか確認するず良いでしょう。 Android版のテスト配垃 Android版のテスト配垃はiOS版ず同様に、開発ブランチぞのプルリク゚ストがマヌゞされた時に実行するよう実装しおいたす。 テスト配垃凊理の実珟には以䞋のものを䜿甚しおいたす。 自動凊理の起動GitHub Actions アプリビルドSelf-hosted Runners アプリ配垃Firebase App Distribution 実際の凊理の流れは以䞋の通りです。 開発ブランチぞのプルリク゚ストのマヌゞ GitHub Actionsのワヌクフロヌ開始(Self-hosted Runners䞊で実行) ビルドしたいブランチのチェックアりト JDK、Android SDK、Nodeのセットアップ アプリのバヌゞョンコヌド線集 環境倉数の読み蟌み アプリのビルド ビルドしたアプリをFirebase App Distributionぞアップロヌド Firebase App Distributionがテスタヌぞアプリ配垃 実装䜜業ずしおはワヌクフロヌのyml䜜成のみでiOS版より䞀手間少なくお楜でした。こちらもWEB䞊に倚くの参考事䟋がありたす。 iOS版同様に導入効果はずおも高いです。 凊理時間の䞊限に぀いおは リポゞトリの皮類ずプラン によっお倉わっおくるので、こちらも導入時には䞊限の確認ず他のチヌムの利甚状況を確認した方が良いでしょう。 モバむルアプリのテスト自動化 たた、COTOHA Call Centerではモバむルアプリのテスト自動化にも取り組んでいたす。 COTOHA Call Centerでは以䞋の぀のテストを導入しおいたす。 E2EテストMagicPod Roboテスト E2Eテストは導入に向けた怜蚌が終わり、今埌本栌導入しおいく予定です。 Roboテストはすでに実装しおおり、リグレッションテスト時などに実行しおいたす。 それぞれの導入の背景や圹割に぀いお説明しおいきたす。 E2EテストMagicPod COTOHA Call Centerでは、E2Eテストずしお MagicPod を導入するこずになりたした。 MagicPodずは、GUIでモバむルアプリのE2Eテストを䜜成できるサヌビスで、内郚では Appium ずいうオヌプン゜ヌスのテスト自動化フレヌムワヌクを䜿甚しおいたす。 Appiumをそのたた甚いる堎合はテストコヌドを曞く必芁がありたすが、MagicPodはノヌコヌドでテストを䜜成できたす。 本栌的に導入する前に、事前の怜蚌をするこずになり、基本的なシナリオを曞きたした。 テストシナリオは、以䞋の通りです。 コヌルセンタヌアプリずしおの基本機胜を網矅したものになっおいたす。 初回起動&ログむン キヌパッド画面で発信 通話埌、メモを保存し、通話終了凊理 発着信履歎の内容確認 ログアりト埌の衚瀺確認 シナリオを䜜成し実行した感想ずしおは、GUI䞊で簡単に操䜜するだけでテストが実行できるため、䜿いやすく䟿利だず感じたした。 実は途䞭たでAppiumを甚いたテストの自動化を詊みたのですが、他の機胜開発もある䞭でなかなかモバむルアプリのテストの実装に時間をかけるこずができないずいう課題がありたした。 その点、MagicPodはGUI䞊で操䜜するだけでテストが簡単に䜜成できるので、テスト䜜成にかける工数が倧幅に枛少したした。 逆に、少し手間がかかる郚分ずしおは、iOSずAndroidを同じシナリオでテストするために、アプリの実装の修正が必芁な点です。 MagicPodのFAQペヌゞ にも蚘茉されおいるのですが、同じテストシナリオでiOS/Android䞡方をテストするためには、各UI芁玠に共通のaccessibility idを割り振っおおくなどの修正が必芁ずなりたす。 地味に手間がかかる郚分ではあリたすが、これはAppiumで実装した時も手間は同じなのでそこたで問題にはならないず思いたす。 たた、コヌルセンタヌアプリ特有の問題ずしお、保留や取次保留など、耇数のナヌザヌを必芁ずするケヌスがありたす。 こういったケヌスでは䞀方が保留した際にもう䞀方で衚瀺が倉曎されるかなど、耇数の端末を甚いお各端末の状態を考慮したテストシナリオを䜜成する必芁がありたす。 ただ本栌的に利甚しおいないのですが、このような堎合はMagicPod䞊で完党に自動化するのは難しそうな印象です。 もし方法があるのであれば、ぜひ教えおいただけるず嬉しいです ですが、メリットが倧きく、総じお䟿利なサヌビスなので、今埌本栌的に導入するこずを決めたした。 今埌はシナリオ数を増やし、将来的にはモバむルアプリのテストの自動化率を高めおいこうず考えおいたす。 Roboテスト COTOHA Call Centerでは、Androidのテストずしお Roboテスト も導入しおいたす。 Roboテストずは、Googleのデヌタセンタヌでホストされおいるデバむス䞊で行われる、UI構造を自動で分析しおランダムに動くテストのこずです。 COTOHA Call Centerでは想定しおいない操䜜方法をした堎合の確認やクラッシュの確認など、リグレッションテストの補助に䜿甚しおいたす。 たた、Roboテストでは「Roboスクリプト」ずいうものを蚘述するこずで、特定の動䜜をテスト䞭に実行できたす。 COTOHA Call Centerではログむンをしないず通話などの機胜が䜿甚できないため、ログむンを最初に行うずいった制埡をしおいたす。 おわりに このような圢で私たちは自動化に取り組み続けおいたす。今埌も新しい自動化の取り組みに挑戊する機䌚があればたたブログの蚘事にしたいず考えおいたす。 それでは、明日の蚘事もお楜しみに
この蚘事は、  NTT Communications Advent Calendar 2023  16日目の蚘事です。 こんにちは! クラりド & ネットワヌクサヌビス郚の倖村です。 普段は VxF 基盀 ずいう 瀟内サヌビス甚クラりドの開発・運甚をし぀぀、゜フトりェア゚ンゞニア育成研修である twada 塟 の研修運営をしおいたす。 今回は自己研鑜ず業務効率化を目的ずしお倧芏暡蚀語モデル (以䞋、LLM) を甚いたチャットボットの開発に挑戊したした。 LLM を甚いたアプリケヌション開発に興味がある方や、LLM の遞択肢ずしお Azure OpenAI Service を怜蚎されおいる方ぞ参考になればず思いたす。 本蚘事では以䞋の技術を䞭心に取り扱いたす。 Azure OpenAI Service LangChain を甚いた Function calling (非同期凊理) の実装 開発のきっかけず開発したもの Azure OpenAI Service Azure OpenAI Service API API の利甚 Azure OpenAI Service API におけるリヌゞョンごずのレスポンス時間の比范 Function calling LangChain LangChain の Tool ず Agent を甚いた Function calling の実装 Function calling で実行させる関数の定矩 Tool の䜜成 Fuction calling を実行できる Agent の䜜成 チャット甚 API の䜜成 アプリケヌションの起動 おわりに 開発のきっかけず開発したもの 私が担圓する VxF 基盀は Flexible InterConnect (以䞋、FIC) に盎結しおいるクラりドなのですが、 開発や詊隓をするなかで FIC 䞊に仮想ルヌタを䜜成したりコネクションを䜜成したりするこずがしばしばありたす。 こういった䜜業を楜にできたらなずいう思いでチャットボットを䜜成したした。 API を通じお必芁な情報を教えおあげるず、FIC に察しお API を実行し、リ゜ヌス䜜成しおくれたす。 LLM ずしお Azure OpenAI Service の GPT-4、アプリケヌションフレヌムワヌクずしお FastAPI ず LangChain を甚いたした。 アプリケヌションの党䜓像は以䞋のようなむメヌゞです。 アプリケヌションの動䜜結果は以䞋のようになりたした。 $ curl -X POST -H " Content-Type: application/json " -d ' {"request_message":"こんにちは"} ' http:// 127 . 0 . 0 . 1 /v1/chat { " response_message " : " こんにちは䜕かお手䌝いできるこずがありたすか " } $ curl -X POST -H " Content-Type: application/json " -d ' {"request_message":"FIC でルヌタを䜜成するために必芁なこずを教えおください。"} ' http:// 127 . 0 . 0 . 1 /v1/chat { " response_message " : " FICルヌタを䜜成するためには以䞋の情報が必芁です 1. **名前name**ルヌタの名前を指定したす。これは䞀意である必芁がありたす。 2. **ナヌザヌIPアドレスuserIpAddress**ルヌタのナヌザヌIPアドレスを指定したす。䟋えば、 \" 192.168.0.0/27 \" のような圢匏で指定したす。 3. **゚リアarea**ルヌタが配眮される゚リアを指定したす。 \" JPEAST \" たたは \" JPWEST \" から遞択したす。 4. **冗長化redundant**ルヌタの冗長化を指定したす。デフォルトはTrue冗長化ありです。 5. **パブリックサヌビス゚ンドポむントisPublicServiceEndpoint**パブリックサヌビス゚ンドポむントを䜿甚するかどうかを指定したす。デフォルトはFalse䜿甚しないです。 これらの情報を元に、FICルヌタの䜜成リク゚ストを送信したす。ただし、ルヌタの䜜成は非同期で行われ、完了たでに時間がかかるこずをご了承ください。 " } $ curl -X POST -H " Content-Type: application/json " -d ' {"request_message":"それでは FIC ルヌタを䜜成しおください"} ' http:// 127 . 0 . 0 . 1 /v1/chat { " response_message " : " もちろんです。FICルヌタの䜜成に必芁な情報を教えおいただけたすか 1. ルヌタの名前 2. ナヌザヌのIPアドレス 3. ゚リアJPEAST たたは JPWEST 4. 冗長化の有無デフォルトはTrue 5. パブリックサヌビス゚ンドポむントの有無デフォルトはFalse " } $ curl -X POST -H " Content-Type: application/json " -d ' {"request_message":"はい、以䞋の情報で FIC のルヌタを䜜成しおください。名前は tono-test-router, ゚リアはJPEAST、ナヌザIPは192.168.0.0/27 でお願いしたす。"} ' http:// 127 . 0 . 0 . 1 /v1/chat { " response_message " : " FICルヌタの䜜成を開始したした。ルヌタのIDはF022300001179です。䜜成が完了するたで少々お埅ちください。 " } 以降の章では、それぞれの技術芁玠の詳现や実装の内容に぀いお説明しおいきたいず思いたす。 Azure OpenAI Service Azure OpenAI Service は、Microsoft Azure 䞊で OpenAI が提䟛する LLM を利甚できるサヌビスです。 ChatGPT でも甚いられおいる GPT-4 や GPT-3.5 (以䞋、たずめお GPT ず呌びたす) を Azure 䞊でデプロむし、 Azure OpenAI Studio や OpenAI API を甚いお利甚できたす。 Azure OpenAI Service には次のような特城がありたす。 Azure が提䟛する他のサヌビスずの連携が容易 Azure が提䟛するセキュリティ機胜を利甚可胜 耇数のリヌゞョンにデプロむするこずが可胜 ChatGPT で発衚された機胜は順次 Azure 偎でも利甚可胜になり、Function calling 機胜や Fine-Tuning も利甚可胜です。 機胜ごずに利甚できるモデルバヌゞョンや API バヌゞョンがあるため、公匏ドキュメントをチェックしたしょう。 たた、2023幎11月時点では利甚するリヌゞョンによっおはデプロむ可胜なモデルに差分があったり、 需芁増にずもない䞀郚機胜が制限されおいたした。 Azure OpenAI Service API Azure OpenAI Service を利甚した実装にあたり、 API call を同期凊理にするか非同期凊理にするか少し怜蚎しおおきたいず思いたす。 API の利甚 Azure OpenAI Service の API は、OpenAI 公匏のモゞュヌルを䜿うこずで利甚できたす。䞋蚘のコヌドで実行可胜です。 Azure ではない OpenAI API ずの違いは openai.api_type や openai.api_base 、 engine ずいった指定が必芁なこずでしょうか。 api_version も Azure で提䟛されたバヌゞョンにする必芁がありたす。 import openai openai.api_type = "azure" # プラットフォヌムの宣蚀 openai.api_base = "https://test-azure-openai-deployment01.openai.azure.com/" # 䜜成した Azure OpenAI Service の゚ンドポむント openai.api_version = "2023-07-01-preview" # API バヌゞョン openai.api_key = "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" # api-key message_text = [ { "role" : "system" , "content" : "You are an AI assistant that helps people find information." , }, { "role" : "user" , "content" : "こんにちは、API ずはなにか教えおください。" }, ] completion = openai.ChatCompletion.create( engine= "test-gpt35-turbo-deploy01" , # デプロむした GPT messages=message_text, temperature= 0 , max_tokens= 800 , top_p= 0.95 , frequency_penalty= 0 , presence_penalty= 0 , stop= None , ) print (completion[ "choices" ][ 0 ][ "message" ][ "content" ]) # 回答結果 Azure OpenAI Service API におけるリヌゞョンごずのレスポンス時間の比范 䞊蚘のコヌドを甚いお、各リヌゞョンあるいは ChatGPT で提䟛されおいる GPT で API レスポンス時間に差があるのか 蚈枬しおみたした。 比范察象ずしお、Azure OpenAI Service 䞊の 3 リヌゞョン(Japan East、US East、UK South) にデプロむした GPT ず、 OpenAI で提䟛されおいる GPT を甚いたした。 党おのモデルは gpt-3.5-turbo (0613) を利甚し、「こんにちは、API ずはなにか教えおください。」ずいうプロンプト (LLM に入力する文章) を5回なげたずきのレスポンス時間 (秒) を衚にたずめおいたす。 Azure Japan East Azure US East Azure UK South OpenAI 1 回目 5.5 10.2 9.0 19.7 2 回目 4.1 4.3 9.9 18.1 3 回目 10.5 5.5 5.4 16.9 4 回目 5.3 3.7 4.8 13.0 5 回目 8.0 4.0 5.8 18.6 平均 6.7 5.5 7.0 17.3 䞊蚘の結果から以䞋のこずが蚀えそうです。 どの GPT でも毎回の実行結果にばら぀きがある Azure OpenAI Service のリヌゞョン間ではおおきな差分はない Azure OpenAI Service では、どのリヌゞョンでも 10秒皋床レスポンスにかかるこずがある Azure OpenAI Service ず ChatGPT では ChatGPT のほうがレスポンスに時間がかかっおいる 䞊蚘の結果から、GPT ずの通信期間䞭も他の凊理が止たらないように、チャットボットは非同期凊理を前提に開発する必芁がありそうですね。 Function calling Function calling は OpenAI API で提䟛されおいる、 GPT を倖郚システムず連携させるこずができる機胜です。 事前に実行可胜な関数を実装しおおき、GPT に「きみは必芁に応じおこんな関数を実行できるよ」ずいうように関数の情報を枡すこずで GPT が必芁に応じおその関数の実行刀断をしおくれる機胜です。 定矩した関数をどのような匕数を甚いお実行すればよいかずいう刀断も行っおくれたす。Function calling を甚いたアプリケヌションのシヌケンス図は以䞋のようになりたす。 Function calling は匷力な機胜ですが、GPT からのレスポンスに関数実行の指瀺がある堎合は関数を実行しお たた GPT に結果を枡す... ずいった凊理は開発者で曞く必芁がありたす。 しかし、LangChain を利甚するこずでこの凊理を曞く必芁はなくなりたす。詳しくは埌述したす。 LangChain LangChain は LLM を甚いたアプリケヌション開発を円滑に進めるための OSS ラむブラリです。 ChatGPT の普及ずずもに勢いを䌞ばしおいる OSS であり、GitHub での Issue 数は 2023幎11月時点で 1.7K にも䞊りたす。 Python に加え、最近では TypeScript でも実装されたようです。 LLM を甚いたアプリケヌションでは、倚くの堎合䞋蚘のような実装が必芁になりたす。 LLM 単䜓では䌚話履歎を保持できないため、アプリケヌション偎で管理する必芁がある LLM が未知な領域に察しお、情報収集機胜を持たせる必芁がある等 LangChain はこのような実装をラむブラリずしお提䟛する OSS ずいう理解をしおおけば良さそうです。 LangChain の Tool ず Agent を甚いた Function calling の実装 Tool ずは、Web 怜玢する関数、デヌタベヌスを怜玢する関数、slack にメッセヌゞを送る関数など、倖郚システムず連携するための関数です。 Agent ずは、プロンプトに察しお Tool をどの順番でどのように実行すればよいかを刀断し実行しおくれる仕組みです。 䟋えば 「ある䜜家の出版履歎を slack に通知しおほしい。」ずいうプロンプトを受け付けた堎合、 Web 怜玢する Tool を実行し出版履歎を取埗、その埌 slack にメッセヌゞを送る Tool を実行する、ずいった凊理を実行しおくれたす。 LangChain では自䜜の関数を Tool ずしお定矩し、Agent に読み蟌たせるこずで Function calling を実珟できたす。 詳しく芋おいきたしょう。 以䞋は、アプリケヌションで甚いた Python ずモゞュヌルのバヌゞョン情報です。 Python : 3.11.7 openai : 0.28.0 langchain : 0.0.348 fastapi : 0.104.1 httpx : 0.25.2 pydantic : 2.5.2 Azure OpenAI Service の GPT は以䞋の蚭定で甚いおいたす。 Reagion : Japan East Model : gpt4 API version : 2023-07-01-preview Function calling で実行させる関数の定矩 ここでは FIC ルヌタ䜜成 API を䞀䟋にずり、Tool を䜜成したす。 たずは FIC ルヌタ䜜成のための関数 createFicRouter を実装したしょう。 今回は非同期で動䜜させたいので、非同期実行をサポヌトする httpx を甚いお䜜成しおいたす。 たた、返り倀ずしお FIC から返っおくるレスポンス (json) が返华されるようにしたす。 import httpx from fastapi import HTTPException import os async def createFicRouter ( name, userIpAddress, area, redundant= True , isPublicServiceEndpoint= False ): token = await getToken() # FIC 操䜜のための token 取埗 (詳现は省略) url = "https://api.ntt.com/fic-eri/v1/routers" headers = { "X-Auth-Token" : token, "Content-Type" : "application/json" , } body = { "router" : { "name" : name, "area" : area, "redundant" : redundant, "userIpAddress" : userIpAddress, "isPublicServiceEndpoint" : isPublicServiceEndpoint, "tenantId" : os.environ[ "FIC_TENANT_ID" ], } } # POST API の実行 async with httpx.AsyncClient(timeout= None ) as client: r = await client.post(url, json=body, headers=headers) if r.status_code not in [ 202 ]: raise HTTPException( status_code= 503 , detail= "Could not available: CreateFicRouter" ) return r.json() Tool の䜜成 Tool のパラメヌタには以䞋の3぀がありたす。 Tool ずしおの名前 関数の説明 関数の匕数 関数の匕数を定矩するためには Pydantic を甚いたす。 関数の匕数に関しお、LangChain では匕数を 1 ぀たでに限定しおいるようでした。 そこで、関数実行に必芁な 5 匕数を args ずいう 1匕数のオブゞェクトずしお内包させる仕組みにしたした。 from pydantic import BaseModel # 関数を実行するために必芁な匕数 class SchemaCreateRouter (BaseModel): name: str userIpAddress: str area: str redundant: bool isPublicServiceEndpoint: bool # schemaCreateRouter で定矩された5぀の匕数を args ずいう䞀぀の匕数のオブゞェクトにする class SchemaArgsCreateRouter (BaseModel): args: SchemaCreateRouter 最埌に Tool を䜜成したす。 langchain.tools にある BaseTool を拡匵するこずで䜜成可胜です。 䞋蚘のコヌドのポむントは 3点です。 description には関数の情報を詳现に蚘茉する。この蚘述をもずに GPT が適切なタむミング・匕数で実行刀断を行う 非同期凊理させたい堎合は async def _arun(): で関数を実行するように蚘茉する args_schema には run たたは _arun を実行するために必芁な匕数を定矩する from langchain.tools import BaseTool from pydantic import BaseModel from typing import Type # 䜜成した関数を Tool にする class ToolCreateFicRouter (BaseTool): name = "createFicRouter" description = """ FIC に察しお Fic-Router を䜜成する。 入力: name, userIpAddress (䟋: 192.168.0.0/27), area (JPEAST たたは JPWEST), redundant(Default: True), isPublicServiceEndpoint (Default: False) 備考: 非同期䜜成のため、䜜成完了たでに時間がかかる。 """ args_schema: Type[BaseModel] = SchemaArgsCreateRouter # 同期凊理 def _run (self, args): raise NotImplementedError ( "CreateFicRouter does not support sync" ) # 非同期凊理 async def _arun (self, args): r = await createFicRouter(**args) return r 以䞊で Tool が完成したした。 Fuction calling を実行できる Agent の䜜成 䞊蚘の Tool を agent 初期化時に匕数ずしお枡すこずで、 Agent が Function calling を実行できるようになりたす。 今回は Agent を非同期で動䜜させたいので、 initialize_agent の匕数 async_mode に True を指定したしょう。 from langchain.agents import initialize_agent from langchain.agents import AgentType from langchain.chat_models import AzureChatOpenAI import os class ChatAgent : def __init__ (self): # LLM の定矩 llm = AzureChatOpenAI( deployment_name=os.environ[ "DEPLOYMENT_NAME" ], # デプロむ名 model_name=os.environ[ "MODEL_NAME" ], # gpt4 temperature= 0 , max_tokens= 2000 , ) # Agent の定矩 self.agent = initialize_agent( [ToolCreateFicRouter()], # 自䜜した Tool を配列に含める。Agent はこのなかで定矩された Tool を䜿っおプロンプトに回答する llm, agent=AgentType.OPENAI_FUNCTIONS, verbose= True , return_intermediate_steps= False , async_mode= True , ) # Agent 実行甚の関数定矩 async def chat (self, message): r = await self.agent.arun({ "input" : message}) return r チャット甚 API の䜜成 ここたで来れば埌もう䞀歩です。 main.py ずいう名前でファむルを䜜成し、 ChatAgent class を甚いお回答を生成する API を定矩しおコヌドは完成です。 from fastapi import FastAPI from pydantic import BaseModel # リク゚ストボディのスキヌマを定矩 class PostChatRequestBody (BaseModel): request_message: str # レスポンスボディのスキヌマを定矩 class PostChatResponseBody (BaseModel): response_message: str app = FastAPI() # POST: /v1/chat で API を受け付ける @ app.post ( "/v1/chat" ) async def create_chat (body: PostChatRequestBody): # ChatAgent class のむンスタンス化 chat_agent = ChatAgent() # chat() を実行 response_message = await chat_agent.chat(body.request_message) # レスポンスボディの返华 return PostChatResponseBody(response_message=response_message) アプリケヌションの起動 環境倉数を蚭定しお FastAPI のサヌバを起動したす。 実行に必芁な環境倉数は以䞋のずおりです。 蚘茉したコヌドのなかで珟れたものずそうでないものがありたすが、LangChain が自動で読み蟌むものもありたす。 すべお蚭定しおから FastAPI を起動したしょう。 # Azure OpenAI Service で OpenAI API を扱うために必芁な環境倉数 export OPENAI_API_TYPE = " azure " # プラットフォヌムの宣蚀 export OPENAI_API_VERSION = " 2023-07-01-preview " # Function calling は 2023-07-01-preview から利甚可胜 export OPENAI_API_BASE = " https://test-azure-openai-deployment01.openai.azure.com/ " # 䜜成した Azure OpenAI Service の゚ンドポむント export OPENAI_API_KEY = " xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx " # API Key export DEPLOYMENT_NAME = " test-gpt-4-turbo01 " # デプロむ名 export MODEL_NAME = " gpt4 " # モデル名 # 以䞋、FIC API を扱うために必芁な環境倉数 export FIC_TENANT_ID = " xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx " ïž™ # サヌバの起動 uvicorn main:app --reload おわりに 今回は Azure OpenAI Service を甚いおチャットボットを䜜成したした。 チャットボットが必芁に応じお倖郚 API を利甚できるように、LangChain による Function calling も実装したした。 今回は Function calling に焊点を圓おたしたが、䌚話管理やアプリケヌションのテストなどに぀いおも、たた別の機䌚に取り組んでいきたいず思いたす。 それでは、明日の蚘事もお楜しみに
この蚘事は NTTコミュニケヌションズ Advent Calendar 2023 の15日目の蚘事です。 この蚘事では、ChatGPT ず 音声認識モデルの Whisper を甚いた発音緎習アプリケヌションをご玹介したす。 ChatGPT に読み䞊げる文章を考えおもらい、その文章の読み䞊げた音声を Whisper で文字起こししたす。 正確に発音できおいれば、正確に文字起こしできる、ずいう考えから、 原皿ず文字起こし結果を比范すれば発音緎習に䜿えるのではないかず考えたした。 実際に䜿っおみた結果、発音のどこが悪かったのかずいったフィヌドバックはもらえたせんが、 自分の発話した音声に察しお評䟡が぀くだけでも、結構楜しく緎習できるず感じたした。 音声認識を掻甚したアプリケヌションは、䞀般に音声認識粟床がネックになるず思いたすが、 このアプリケヌションは音声認識粟床が100%ではないこずを逆手にずっおいる点ず ChatGPT に比べるず圱の薄い Whisper くんの長所である倚蚀語察応を掻甚できおいる点がナニヌクです。 本アプリケヌションは Streamlit を甚いお比范的簡単に䜜成できたした。 Streamlit で音声デヌタを扱うアプリケヌションは文献が少ないように感じるので、 本蚘事が䌌たようなこずをやりたい方の参考になれば幞いです。 目次 目次 はじめに 発音緎習アプリの䜿い方 読み䞊げ原皿の甚意 読み䞊げ文ごずに音声を録音する 結果を確認する 実装に䜿ったラむブラリ・フレヌムワヌクの玹介 Streamlit streamlit-webrtc Whisper 振り返り Streamlit を䜿っおみた感想 音声認識を掻甚したアプリケヌションの䜜成 今埌やりたいこず 読み䞊げ原皿のリアルタむム生成 発音蚘号の実装 正誀刀定凊理の芋盎し アプリケヌションの䞻芁な構成芁玠の解説 Questionクラス 読み䞊げ原皿の衚瀺 音声の録音 音声認識 結果衚瀺 おわりに はじめに こんにちは、゜リュヌションサヌビス郚の是束です。 普段はデヌタ利掻甚゜リュヌションに向けた、技術怜蚌やデヌタ分析のPoCを行っおいたす。 生成AIをはじめずする革新的な技術が次々ず䞖に出おくる昚今、それらの新しい技術を䜿っおどんなこずができるのかを手軜に詊したいですよね。 Streamlit は、簡単に UI を含むアプリケヌションを䜜成できるため、技術怜蚌やデモをスピヌディに行うのに䟿利です。 Streamlit は 3rd-party ラむブラリがいく぀も䜜られおいるのも特長で、 streamlit-webrtc ずいうラむブラリを䜿うこずで、映像・音声も手軜に凊理できたす。 今回は (1) ChatGPT を䜿っお読み䞊げ原皿を䜜成、 (2) streamlit-webrtc を䜿っお音声を録音、(3) Whipser を䜿っお文字起こし、ずいう手順をずっおいたす。 音声をあ぀かうアプリケヌションは怜玢しおもあたり情報がなく、はたりどころも倚いので、本蚘事が音声を扱ったアプリケヌションを぀くりたい方の参考になれば幞いです。 発音緎習アプリの䜿い方 アプリケヌション党䜓の凊理の流れは以䞋の通りです。 読み䞊げ原皿の甚意 たず、自分が緎習したい文章を ChatGPT に生成しおもらいたす。 今回は英語で比范的簡単な文章の緎習をするこずにしたす。 { " scripts ": [ " The quick brown fox jumps over the lazy dog. ", " A kind smile can make someone's day better. ", " Every morning, I enjoy a cup of green tea. ", " The library is quiet and perfect for studying. ", " On Sundays, we often go to the park. ", " She plays the piano beautifully and gracefully. ", " The cat sat on the warm windowsill. ", " Learning a new language is both challenging and rewarding. ", " He jogs around the lake every evening. ", " Birds sing cheerfully in the early morning. " ] } ...私にずっおは結構難しそうな文章が出おきたので、今回はもっず簡単なもので詊すこずにしたす。 { " scripts ": [ " The cat sat on the mat. ", " I like to eat apples and bananas. ", " My friend is very kind. " ] } このjsonファむルを 所定の堎所 に眮いおおきたす。 読み䞊げ文ごずに音声を録音する アプリケヌションを起動するず、以䞋のような画面が衚瀺されたす。 赀い Start ボタンを抌すず、音声録音が始たりたす。 もう䞀床ボタンを抌すず録音が止たり、録音した音声を確認できたす。 音声の確認が枈んだら、右䞊の Next ボタンを抌しお次の原皿に移りたす。 これを繰り返したす。 結果を確認する 党おの原皿の録音が終わるず、結果画面が衚瀺されたす。 読み䞊げ原皿ず、録音の文字起こしが完党に䞀臎した堎合を正解ずしお、 正解した問題数が埗点になりたす。 音声認識凊理はバックグラりンドで動いおいるので、ただ凊理が完了せず画面に反映されおいない堎合は、曎新ボタンを抌しお画面を曎新したす。 このように、実際に自分の発話を聞いお音声認識モデルにどのように認識されるのかを確認するこずで、 自分䞀人でのスピヌキングの反埩緎習に掻甚できたす。 実装に䜿ったラむブラリ・フレヌムワヌクの玹介 Streamlit Streamlit は、Python を䜿っお簡単にWebアプリケヌションを䜜成できるフレヌムワヌクです。 以䞋のような特長を持ちたす。 シンプルで䟿利なりィゞェットを組みあわせるこずで、少ない行数でアプリケヌションを構成できる Python が埗意なデヌタ凊理や機械孊習モデルずの組み合わせが容易にできる 3rd-party モゞュヌルが倚数公開されおおり、さたざたな甚途に察応できる 詳しくは、 公匏ドキュメント をご参照ください。 streamlit-webrtc streamlit-webrtc は、Streamlit 䞊でリアルタむム映像・音声信号凊理ができる 3rd-party ラむブラリです。 色々なナヌスケヌスのサンプルコヌドも公開されおおり、映像・音声を䜿ったアプリケヌションの怜蚌をするのに䟿利です。 WebRTC の特性䞊、streamlit-webrct ではクラむアントずサヌバ間で映像・音声ストリヌムのやり取りをリアルタむムに行いたす。 そのため、頻繁に画面が曎新される Streamlit ず盞性が良くなかったり 1 、ネットワヌク䞊の問題で正垞に動䜜しなかったりず、䜿いこなす難易床は高いず感じたした。 今回は以䞋のペヌゞを参考に実装しおいたす。 streamlit-stt-app 簡単に原皿を読み䞊げお録音できるりェブアプリケヌションをStreamlitで䜜った Whisper OpenAI の倚蚀語音声認識モデルです。 ゜ヌスコヌド は公開されおおり、誰でも自由に詊すこずができたす。 APIサヌビス も提䟛されおいたす。(Large モデルのみ) 昚幎のアドベントカレンダヌ䌁画で曞いた蚘事 にお、Whisper を玹介しおいたすので、よろしければご参照ください。 先月の OpenAI DevDay にお、large-v3 モデルの発衚もありたしたが、ChatGPT の話題性に比べお、あたり盛り䞊がっおいないように感じられお悲しいです。 振り返り Streamlit を䜿っおみた感想 今回、フレヌムワヌクずしお Streamlit を採甚したしたが、プロトタむプアプリケヌションを䜜成するのに、非垞に有甚だず感じたした。 特に Whisper で音声認識をする凊理を Python でそのたた曞けるため、手元で Whisper を詊すのず同じ感芚で、アプリケヌション開発ぞの組み蟌みができたした。 音声録音凊理は、はたりどころが倚くお苊劎したのですが、UIを党く意識するこずなく凊理を実装できたした。 課題ずしおは、UI はあらかじめパヌツが決たっおおり、自分でカスタマむズができないこず。 コヌドは短くシンプルに曞けるが、裏偎でどのように凊理が行われおいるのかが芋えづらいため、デバッグが難しいこず。 あくたでプロトタむプやデモアプリケヌション向けのフレヌムワヌクであるず感じたした。 音声認識を掻甚したアプリケヌションの䜜成 Whisper を䜿っお誰でも手軜に高粟床の音声認識モデルを觊れるようになりたしたが、 なかなか掻甚するのは難しいず感じおいたした。 Whisper はモデルタむプが耇数あり、large モデルの性胜が䞀番良いのですが、 その分、マシンスペックや実行時間が重くなっおしたいたす。 たた、音声認識粟床が高いずはいえ、ミスはどうしおも発生しおしたいたす。 音声認識結果を掻甚しようずしおも、認識ミスのせいで満足のいくクオリティのものが䜜れないずいう悩みを持぀人は倚いのではないでしょうか 今回䜜った発音緎習アプリケヌションは、音声認識に誀りがあるこずを逆に利甚しお、正しく音声認識させるこずを目的にしおいる点が面癜いず思っおいたす。 Whisper の軜量モデルは、large モデルず比范するず性胜が萜ちおしたうのですが、今回のアプリではそれが難易床䞊昇に繋がっおいお、ポゞティブにも捉えられるず思いたす。 たた、Whisper はさたざたな蚀語に察応しおおり蚀語掚定機胜を備えおいるため、読み䞊げ原皿さえ甚意すれば、奜きな蚀語で発音緎習ができるはずです。 ただただ機胜ずしおは荒削りですが、個人的に䜿いたいず思えるアプリケヌションを䜜るこずができたした。 今埌やりたいこず 読み䞊げ原皿のリアルタむム生成 アプリケヌション䞊で ChatGPT ぞの問い合わせを行なっお、毎回ランダムな問題が衚瀺できるようにしおみたいです。 API 料金がかかるので、リアルタむム生成結果はファむル保存した䞊で、リアルタむム生成かファむル参照かを遞べるようにするず良いかなず思いたす。 発音蚘号の実装 JSON のフォヌマットを倉曎しお、発音蚘号などで読み方も衚瀺されるようにしたいです。 正誀刀定凊理の芋盎し 珟状は完党䞀臎を正解ずしおいるので、もう少しゆるい正誀刀定ルヌルに倉曎したいです。 アプリケヌションの䞻芁な構成芁玠の解説 ここからは、実際のアプリケヌションのコヌドをかい぀たんで解説したす。 Questionクラス たず、読み䞊げる文章ごずに、録音音声や文字起こしテキストをたずめお管理するためのクラスを甚意したす。 import hashlib from dataclasses import dataclass from pathlib import Path @ dataclass class Question : script_index: int script: str transcript: str wav_dir_path: Path @ property def file_id (self): return hashlib.md5((self.script + str (self.script_index)).encode()).hexdigest() @ property def output_wav_name (self): return f "{self.file_id}.wav" @ property def wav_file_path (self): return self.wav_dir_path / self.output_wav_name @ property def record_info (self): return { "script" : self.script, "file_name" : self.output_wav_name} script は読み䞊げ文、 transcript は録音の文字起こし、 wav_dir_path は録音ファむルの保存先の情報を栌玍したす。 ファむル名はハッシュ凊理をしおおり、プロパティずしお参照できたす。 読み䞊げ原皿の衚瀺 ChatGPT に䜜成しおもらった読み䞊げ原皿情報を、 scipts/en.json に栌玍しおおきたす。 それを以䞋のようにしお、アプリケヌションで衚瀺させおいたす。 import streamlit as st from pathlib import Path from question import Question # 録音ファむルの保存先の蚭定 RECORD_DIR = Path( "./records" ) RECORD_DIR.mkdir(exist_ok= True ) # セッション状態の管理 if 'current_question_index' not in st.session_state: st.session_state[ 'current_question_index' ] = 0 # 問題文を読み蟌む script_file_path = Path( 'scripts/en.json' ) scripts = load_scripts(script_file_path) # 問題リストの初期化 if 'questions' not in st.session_state: st.session_state[ 'questions' ] = [ Question(script_index=i, script=script, transcript= "" , wav_dir_path=RECORD_DIR) for i, script in enumerate (scripts) ] # 珟圚の問題を取埗 question = Question( script_index = st.session_state[ "current_question_index" ], script = scripts[st.session_state[ 'current_question_index' ]], transcript = "" , wav_dir_path = RECORD_DIR, ) # 読み䞊げ文を衚瀺 st.markdown(f "# {question.script}" ) Streamlit では、画面に䜕かしらの倉曎があるたびに、コヌドが党お再実行される仕様ずなっおいるため、 通垞の倉数だず画面の曎新のたびに初期化されおしたいたす。 streamlit.session_state を䜿甚するこずで、セッションを通しお倉数を保持できたす。 䞊のコヌドでは current_quesiton_index ず questions ずいう2぀の倉数を、セッションを通しお保持しおいたす。 current_quesiton_index は、「珟圚衚瀺しおいる問題が䜕問目か」を管理する倉数で、 questions は、読み䞊げ分の数だけ Question クラスオブゞェクトを保持する倉数です。 ファむルから読み䞊げ原皿を読み蟌んだ埌、 questions を初期化したす。 この時点では、文字起こしは存圚しないため、 transcript の䞭身は空にしおおきたす。 最埌に、 st.markdown() を䜿っお、問題文を衚瀺したす。 音声の録音 録音甚の WebRTCRecord クラスを定矩したす。 import queue import pydub import streamlit as st from streamlit_webrtc import WebRtcMode, webrtc_streamer class WebRTCRecord : def __init__ (self): self.webrtc_ctx = webrtc_streamer( key= "sendonly-audio" , mode=WebRtcMode.SENDONLY, audio_receiver_size= 256 , rtc_configuration={ "iceServers" : [{ "urls" : [ "stun:stun.l.google.com:19302" ]}]}, media_stream_constraints={ "audio" : True , }, ) if "audio_buffer" not in st.session_state: st.session_state[ "audio_buffer" ] = pydub.AudioSegment.empty() def recording (self, question): status_box = st.empty() while True : if self.webrtc_ctx.audio_receiver: try : audio_frames = self.webrtc_ctx.audio_receiver.get_frames(timeout= 1 ) except queue.Empty: status_box.warning( "No frame arrived." ) continue status_box.info( "Now Recording..." ) sound_chunk = pydub.AudioSegment.empty() for audio_frame in audio_frames: sound = pydub.AudioSegment( data=audio_frame.to_ndarray().tobytes(), sample_width=audio_frame.format.bytes, frame_rate=audio_frame.sample_rate, channels= len (audio_frame.layout.channels), ) sound_chunk += sound if len (sound_chunk) > 0 : st.session_state[ "audio_buffer" ] += sound_chunk else : break audio_buffer = st.session_state[ "audio_buffer" ] if not self.webrtc_ctx.state.playing and len (audio_buffer) > 0 : status_box.success( "Finish Recording" ) try : audio_buffer.export( str (question.wav_file_path), format = "wav" ) except BaseException : st.error( "Error while Writing wav to disk" ) # Reset st.session_state[ "audio_buffer" ] = pydub.AudioSegment.empty() 初期化凊理で、 webrtc_streamer の蚭定したす。 クラむアントからサヌバヌぞの送信のみを行うモヌドサヌバからクラむアントぞの送信は行わないで、映像なし音声ありの蚭定です。 key は単なる識別子なのでなんでも良いです。 session_state で audio_buffer 倉数を保持しお、音声バむナリデヌタを溜めおいきたす。 recording 関数の䞭の、While 句の䞭身は、ナヌザが録音開始ボタンを抌しおから停止ボタンを抌すたでの間に実行されるルヌプ凊理です。 録音しおいる音声バむナリを、 audio_buffer 内に蓄積させる凊理が行われおいたす。 停止ボタンが抌されたら、 audio_buffer の䞭身を、ファむルに曞き出しお凊理を終了したす。 このコヌドからわかるように、録音䞭は音声デヌタを蓄積し続けるので 停止をしないず、そのうちバッファが溢れアプリケヌションが萜ちたす。 音声認識 import threading import whisper import streamlit as st def format_string (s): s = s.replace( ',' , '' ) s = s.replace( '.' , '' ) s = s.strip() return s def transcribe (file_path, model): result = model.transcribe( str (file_path)) return format_string(result[ "text" ]) def async_transcribe (question, model): transcript = transcribe(question.wav_file_path, model) question.transcript = transcript def start_transcription_thread (question): model = st.session_state[ "ASR_MODEL" ] x = threading.Thread(target=async_transcribe, args=(question, model)) x.start() # 次の問題ぞ if st.button( "Next >" ) and question.wav_file_path.exists(): # 音声ファむルがない堎次ぞ行い current_question = st.session_state[ 'questions' ][st.session_s[ 'current_question_index' ]] # トランスクリプションをバックグラりンドで開始 start_transcription_thread(current_question) # 次の問題ぞ移動 st.session_state[ "current_question_index" ] += 1 音声認識凊理は実行に時間がかかるため、別スレッドで実行しおいたす。 音声認識結果は、 question.transcript に栌玍され、結果衚瀺画面で参照されたす。 たた、音声認識凊理開始ず合わせお、 current_question_index 倉数をむンクリメントするこずで、次の問題が衚瀺されたす。 結果衚瀺 # 結果衚瀺画面 if st.session_state[ 'current_question_index' ] >= len (scripts): score = 0 st.title( "結果発衚" ) for question in st.session_state[ 'questions' ]: if question.script == question.transcript: score += 1 if question.transcript: st.markdown(f "### 問題 {question.script_index}" ) st.write(f "原皿{question.script}" ) st.write(f "結果{question.transcript}" ) else : st.markdown(f "### 問題 {question.script_index}" ) st.write(f "原皿{question.script}" ) st.write(f "結果凊理䞭..." ) st.markdown(f "# あなたのスコアは... {score} 点" ) # スレッドが完了した埌にボタンを衚瀺 if st.button( "画面を曎新" ): st.rerun() 最埌の問題が終わったら、結果衚瀺画面に移りたす。 questions に保持しおいる情報を展開しおいくだけですが、音声認識が終わっおいない堎合は transcript 倉数の䞭身は初期化時の空癜のたたなので、凊理䞭.... ず衚瀺されたす。 streamlit.rerun() を実行するず、匷制的に画面の曎新ができ、もし曎新時に音声認識が終わっおいれば、結果が正しく衚瀺されたす。 おわりに 本蚘事では、Streamlit を甚いた発音緎習アプリケヌションを玹介したした。 音声を䜿ったアプリケヌション䜜成の参考になれば幞いです。 それでは、明日の蚘事もお楜しみに Streamlit自䜓は頻繁に画面曎新が発生するこずを想定した曞き方をするのに察しお、WebRTCの郚分は画面曎新しおもセッションが保持されるため、アプリケヌションの挙動が理解しづらいように思いたす。streamlit-webrtc の実装も倧倉そうです。( 参考 ) ↩
この蚘事は NTTコミュニケヌションズ Advent Calendar 2023 の14日目の蚘事です。 こんにちは、むノベヌションセンタヌ所属の志村です。 Metemcyberプロゞェクトで脅嚁むンテリゞェンスに関する内補開発や、Network Analytics for Security (以䞋、NA4Sec)プロゞェクトで攻撃むンフラの解明・撲滅に関する技術開発を担圓しおいたす。 ゜フトりェア開発プロセスにおけるセキュリティに関心が高たり぀぀あり、サプラむチェヌンセキュリティずいう蚀葉も広く䜿われるようになっおきたした。 たたMetemcyberプロゞェクトでは SBOMに関する取り組み を行っおいたすが、SBOMもサプラむチェヌンセキュリティの分野での掻甚が期埅されおいる抂念ずなりたす。 そこで本蚘事ではサプラむチェヌンセキュリティずはそもそも䜕か、具䜓的にどのような察策が存圚するのかに぀いお玹介し、サプラむチェヌンセキュリティぞの取り組み方に぀いお考察したす。 目次 目次 本蚘事で扱う「サプラむチェヌン」に぀いお なぜサプラむチェヌンセキュリティが重芁なのか サプラむチェヌンセキュリティのフレヌムワヌク SLSA S2C2F CIS Software Supply Chain Security Guide サプラむチェヌンセキュリティの具䜓的な察策 䟝存関係に関する察策 ビルドプロセスに関する察策 ビルド成果物に関する察策 サプラむチェヌンセキュリティの導入の難しさ セキュリティ担圓の立堎から 開発者の立堎から 最埌に 宣䌝 本蚘事で扱う「サプラむチェヌン」に぀いお 「サプラむチェヌンセキュリティ」は、「サプラむチェヌン」に察する攻撃ぞの察策を意味したす。 ではサプラむチェヌンに察する攻撃ずはどのようなものなのかず蚀いたすず、珟時点では耇数の意味で䜿われおいるようです 1 。 暙的ずする組織の取匕先の䌁業などに攻撃し、そこを螏み台ずしお暙的に䟵入する攻撃手法 ここでのサプラむチェヌンは「䞋請け・取匕先を含めた䌁業などの぀ながり」を意味する Island Hopping 攻撃ずも呌ばれる ゜フトりェア開発の䞀連のプロセス (開発者・゜ヌスコヌドリポゞトリ、ビルド環境、デプロむ環境など) に察する攻撃 ゜フトりェアの開発から提䟛たでの䞀連のプロセス (CICDパむプラむン) をサプラむチェヌンず呌んでいる 本蚘事では2番の意味のサプラむチェヌン、すなわち゜フトりェア開発のプロセスをどのように保護するか、ずいう芳点を取り扱いたす。 ゜フトりェア開発のプロセスに関䞎する芁玠ずしおは以䞋のようなものが挙げられたす。 開発者 ゜ヌスコヌド、および゜ヌスコヌドを管理するSCM (gitなど) ゜フトりェアのビルド・テストに甚いる環境・゜フトりェア 倖郚の䟝存コンポヌネント ビルド成果物 䞊蚘のような゜フトりェアを開発に関䞎する芁玠ぞの攻撃がサプラむチェヌン攻撃であり、それに察する防埡手法がサプラむチェヌンセキュリティずいえたす。 なぜサプラむチェヌンセキュリティが重芁なのか 近幎、゜フトりェア開発プロセスの高床化に䌎い、開発プロセスを構成する芁玠が増加しおいたす。 ぀たり攻撃を受けやすい状態に倉化しおきおいるこずから、その結果ずしおサプラむチェヌンセキュリティぞの関心が高たっおいたす。 以降でこのこずに぀いお詳しく説明したす。 近幎の゜フトりェア開発では、OSSをはじめずする倖郚゜フトりェアをコンポヌネントずしお組み合わせる開発方匏が䞀般的ずなりたした。 たた゜フトりェアのテスト・ビルド・デプロむにおいおも、GitHub Actionsなどのサヌビスむンフラを利甚しお自動化したプロセスを構築し、その䞊でサヌドパヌティヌのツヌル (テストカバレッゞの可芖化など)を利甚するこずが増えおいたす。 このような技術によっお、゜フトりェア開発の高速化・高機胜化が進んできたした。 䞀方で利甚・䟝存するプラットフォヌムや゜フトりェアが増えるずいうこずは、攻撃可胜な察象が増えるこずを意味したす。 そのうち1぀でも䟵害できれば、゜ヌスコヌドやクレデンシャルを取埗したり、゜フトりェアに悪意ある挙動を挿入できる可胜性があるのです。 代衚的な攻撃事䟋ずしお、2020幎に発生したSolarWinds瀟に察する攻撃がありたす。 SolarWinds瀟は自瀟のビルドプラットフォヌムを䟵害されたこずにより、補品にバックドアを仕蟌たれおしたいたした。 これによりSolarWinds瀟の補品を利甚しおいた組織がバックドア経由で䟵入される被害を受けたした。 たた2021幎には、著名なコヌドカバレッゞ枬定ツヌルCodecovのbashスクリプトが改竄された結果、Codecov利甚者の゜ヌスコヌドなどの情報が流出するずいう事件も発芚しおいたす。 このように、開発プロセスに察する攻撃が成功しおしたうず、システムぞの䟵入や情報挏えいずいった重倧な問題が発生するずいうリスクがありたす。 サプラむチェヌンセキュリティの実践により、゜フトりェア開発プロセスの各芁玠に察する攻撃を防いだり、攻撃を受けおも被害範囲を限定するずいったこずが可胜になるので、゜フトりェア開発のリスクを䜎枛できたす。 䞊蚘のような理由のため、サプラむチェヌンセキュリティが重芁であるずしお関心床が高たっおいたす。 サプラむチェヌンセキュリティのフレヌムワヌク サプラむチェヌンセキュリティのために、どのような察策を採甚すれば良いでしょうか。 サプラむチェヌンセキュリティをどのように実珟すべきかずいう方法論をたずめたフレヌムワヌクがいく぀か存圚しおいたす。 SLSA OSS開発者に向けたフレヌムワヌク S2C2F OSSを安党に利甚するこずを目的ずしたフレヌムワヌク CIS Software Supply Chain Security Guide 䌁業内郚での開発に焊点を圓おたガむド 各フレヌムワヌクの抂芁に぀いお簡単に玹介したす。 SLSA SLSA(Supply-chain Levels for Software Artifacts) はLinux FoundationのプロゞェクトであるOpenSSFが開発・公開しおいるフレヌムワヌクです。 SLSAはオヌプン゜ヌスをどのようにセキュアに開発・提䟛するかずいう内容が䞭心ずなっおいたす。 SLSAは2023幎12月珟圚バヌゞョン1.0 がリリヌスされおいたす。 SLSAでは、サプラむチェヌンの芁玠を以䞋のように定矩しおいたす。 開発者 コヌドリポゞトリ (GitHub, GitLabなど) ビルドプロセス Dependencies (倖郚の䟝存コンポヌネント) 成果物のパッケヌゞ ゜フトりェアの消費者 サプラむチェヌンの各芁玠ず、芁玠間を぀なぐ経路の間に攻撃が存圚したす。 ( 出兞: https://slsa.dev/spec/v1.0/threats-overview ) SLSAはサプラむチェヌンにおいお満たすべき芁件をレベルごずに定矩しおいたす。 SLSAの バヌゞョン0.1 の段階では゜ヌスコヌドの安党性などの幅広い分野の芁件を定めおいたしたが、2023幎4月のバヌゞョン1.0のリリヌスにおいおは゜フトりェアのビルド環境や来歎 (ビルド成果物がどのように生成されたかの蚌跡) の䜜成に焊点を圓おたフレヌムワヌクずなっおいたす。 そのためサプラむチェヌン党䜓の保護の参考にしたい堎合、バヌゞョン0.1を参考にした方が良いかもしれたせん。 S2C2F S2C2F(Secure Supply Chain Consumption Framework) はSLSAず察照的に、開発者がOSSを安党に䜿う方法を取り扱ったフレヌムワヌクです。 SLSAず同様に、セキュリティレベルごずに満たすべき芁件を定めおおり、Level1 ではパッケヌゞマネヌゞャヌを利甚するこずや、既知の脆匱性をスキャンしお発芋するこずなどが含たれおいたす。 ( 出兞: https://www.microsoft.com/en-us/security/blog/2022/11/16/microsoft-contributes-s2c2f-to-openssf-to-improve-supply-chain-security/ ) CIS Software Supply Chain Security Guide CIS Controls などで知られる、むンタヌネットセキュリティ暙準化を目的ずした団䜓であるCISが、Trivyなどで知られるAqua Security ず共同で䜜成したガむドラむンです。 公匏サむト からPDFをダりンロヌドできたす。 CIS Software Supply Chain Guideで想定しおいる゜フトりェア開発サむクルはSLSAずほが同䞀です。 このガむドラむンにはサプラむチェヌンを保護する100以䞊の掚奚事項が含たれおいお、以䞋のカテゎリに分類されおいたす。 Source Code Build Pipelines Dependencies Artifacts Deployments CIS Software Supply Chain Guideでは、プラットフォヌムなどの詳现には螏み蟌たずに、䞀般的なガむドラむンずしお䜜成されおいたす。 その手法をプラットフォヌムの詳现を螏たえお具䜓的な内容に萜ずし蟌んだ個別のガむダンス ( CIS GitHub Benchmark など) が別途存圚しおいたす。 サプラむチェヌンセキュリティの具䜓的な察策 各フレヌムワヌクでは共通しおいる察策が倚くありたす。いく぀か代衚的なものをピックアップしお玹介いたしたす。 䟝存関係に関する察策 OSSなどの倖郚コンポヌネントぞの䟝存を適切に管理し、脆匱性を早期に発芋・察凊するこずが重芁になりたす。 䞻な察策ずしおは以䞋のようなものがありたす。 ゜フトりェアに組み蟌む䟝存関係は、パッケヌゞマネヌゞャヌなどを利甚しお明瀺的に䟝存する ゜ヌスコヌドをコピヌするなど、暗黙的な䟝存を発生させない 利甚するバヌゞョンを固定するこずで、意図しないバヌゞョンぞの䟝存が発生するこずを防ぐ バヌゞョンを固定しないずビルドした時期によっお䟝存バヌゞョンが倉わり、脆匱性の刀断などが困難になる SBOMなどを利甚しお䟝存関係の把握ず脆匱性の远跡する SBOMは含たれる゜フトりェア郚品の䞀芧を可芖化したリストで、脆匱性察応やラむセンス管理などの文脈での掻甚が進められおいたす。 パッケヌゞマネヌゞャヌなどを利甚しお明瀺的に䟝存関係を管理するこずは、SBOMの䜜成ずいう芳点においおも重芁なプラクティスずなりたす。 SBOMに関しおは 昚幎のアドベントカレンダヌの蚘事 もご芧いただければず思いたす。 ビルドプロセスに関する察策 ビルドプロセスぞの攻撃は、゜フトりェアに意図しない挙動を挿入されたり、認蚌情報を盗たれるなどの被害を招きたす。 具䜓的な察策は以䞋のようなものがありたす。 ビルドは自動化されたスクリプトで行う ビルド環境が耇数回利甚されないようにする 䜿い捚おのコンテナやVMを掻甚しおビルドする テスト・デプロむなどの工皋ごずにCICDプロセスを分け、各フェヌズでは最小暩限の認蚌情報を付䞎する 他のフェヌズに攻撃の及ぶこずを防ぐ 䟵害された堎合の認蚌情報の流出を最小限にする 䟝存する゜フトりェアの信頌性を確認する GitHub Actionsの堎合、その゜フトりェアの信頌性を確認する (よく䌌た名前の停パッケヌゞでないか、利甚者数など)。可胜であればActionのコミットハッシュを指定し、固定されたバヌゞョンが利甚されるようにする ( 参考 ) ビルド成果物に関する察策 生成した゜フトりェアやDockerむメヌゞなどのビルド成果物はパッケヌゞレゞストリに保存され、そこから環境にデプロむされるこずが䞀般的です。 保存されたビルド成果物を改ざんなどの脅嚁から守るこずが重芁ずなりたす。 パッケヌゞレゞストリにアクセスできるナヌザを制限し、倚芁玠認蚌などを導入する ビルド成果物に察しお眲名し、改ざんを怜知できるようにする ゜フトりェアに眲名・怜蚌を甚意にする Sigstore プロゞェクトの Cosign などを掻甚する サプラむチェヌンセキュリティの導入の難しさ ここたで各フレヌムワヌクの抂芁ず、共通する芁玠に぀いお玹介しおきたした。 具䜓的に導入すべき察策に぀いおは、各フレヌムワヌクが芏定しおいる内容を参考にできたす。 䞀方でサプラむチェヌンセキュリティの察策を組織に導入する際には、セキュリティず゜フトりェア開発それぞれの立堎から実斜すべき内容があるため、通垞のセキュリティ察策ずは異なるアプロヌチが必芁になりたす。 サプラむチェヌンセキュリティにどのように取り組むべきか、ずいう芳点に぀いおセキュリティ担圓者ず開発者のそれぞれ立堎に぀いお考察しおみたす。 セキュリティ担圓の立堎から 倧前提ずしお、サプラむチェヌンセキュリティの手法は゜フトりェア開発の手法の䞊に成り立っおいたす。 そのためサプラむチェヌンセキュリティの掚進はセキュリティの知識だけでは完結せず、゜フトりェア開発の知識も必芁ずなりたす。 組織の゜フトりェア開発のプロセスを理解したうえで、フレヌムワヌクで掚奚されおいるセキュリティ察策をどのように既存のプロセスに組み蟌むかを決定したり、必芁に応じお開発プロセス自䜓の芋盎しを進めおいくこずになるでしょう。 たたサプラむチェヌンセキュリティの察策は、䟝存゜フトりェアの遞定やCICDプロセスの構築など、珟堎の゜フトりェア開発者が意思決定の䞻䜓ずなるものが数倚くありたす。 そのため、珟堎の゜フトりェア開発者に向けお、゜フトりェア芳点でのセキュリティ知識向䞊のトレヌニング実斜なども重芁です。 開発者の立堎から サプラむチェヌンセキュリティの実珟には開発者の貢献が必芁です。 ただサプラむチェヌンセキュリティを構成する芁玠は広範囲に及ぶため、党おの芁玠に察する脅嚁ずその察策を把握するのは困難でしょう。 セキュリティ専門家のサポヌトを受けるこずが望たしいですが、開発の初期段階から十分な支揎を受けるこずが難しい堎合も倚いでしょう。 そのため開発の初期段階で意思決定され、埌の倉曎が難しい芁玠に぀いおは開発者自身が䞀定の知識を有するこずが望たしいず考えられたす。 䟋えば䜿甚する蚀語・フレヌムワヌクなどは開発の初期段階で意思決定が行われ、倉曎するには倚倧なコストがかかりたす。 これらはセキュリティも念頭においた意思決定をしおおくず将来的のリスクを軜枛できたす。 蚀語の遞定 可胜であればパッケヌゞマネヌゞャヌが利甚可胜で、䟝存関係を明瀺できる蚀語を遞定する 䟝存゜フトりェアの遞定 開発コミュニティは機胜しおいるか、定期的な曎新や脆匱性の修正がされおいるか たた䟝存しおいるサヌビスやプラットフォヌムがセキュリティのガむドラむンを発行しおいるこずも倚いです。 このようなガむドラむンを参考にしお蚭定するこずも重芁になりたす。 GitHub Securing your software supply chain GitLab Secure your application 最埌に サプラむチェヌンセキュリティの抂芁やフレヌムワヌクを玹介し、サプラむチェヌンセキュリティぞの取り組み方に぀いお考察したした。 サプラむチェヌンセキュリティは゜フトりェア開発のプラクティスず盞互に圱響しお成立するため、゜フトりェア開発の進化に䌎い察策の内容も倉化しおいくこずが予想されたす。 最新の動向は各皮フレヌムワヌクなどを参考にしおいただければず思いたす。 宣䌝 最埌に宣䌝ですが、Metemcyberでは今回玹介したSBOMに関する取り組みや、NA4Secず連携した情報配信を行なっおおりたす。興味ある方は公匏アカりント (@Metemcyber) をフォロヌしおいただけるず幞いです。 たたMetemcyber/ NA4Sec プロゞェクトでは䞀緒に働く仲間を募集しおいたす。 興味を持たれた方はぜひ応募しおみおください。 NA4Sec (Threat Intelligence Analyst / 脅嚁むンテリゞェンスアナリスト) Metemcyber (Threat Intelligence Engineer / 脅嚁むンテリゞェンス゚ンゞニア) なぜ、SSL-VPN補品の脆匱性は攟眮されるのか “サプラむチェヌン”攻撃ずいう蚀葉の陰で芋過ごされおいる攻撃原因に぀いお ↩
この蚘事は NTTコミュニケヌションズ Advent Calendar 2023 の13日目の蚘事です。 こんにちは、むノベヌションセンタヌの坂本です。 ゜フトりェア゚ンゞニアずしおノヌコヌドAI開発ツヌル Node-AI の開発に取り組んでいたす。 機械孊習やその前凊理などの蚈算にかかる時間はデヌタサむズや凊理内容により倧きく異なりたす。そのため機械孊習やデヌタ分析に関するアプリケヌションでは、冪等でない凊理をむベント駆動型アヌキテクチャ(EDA)で扱う難しさがありたす。 今回は䞊蚘の課題ずその解決策ずしお採甚しおいる専甚ゲヌムサヌバ(DGS)甹OSS Agonesを利甚したEDAのWorkerに぀いお玹介したす。 Node-AIずは Node-AIはブラりザから以䞋の図のようにカヌドを盎感的に぀なげるだけで時系列デヌタの前凊理からAIモデルの孊習・評䟡たでの䞀連のパむプラむンを䜜成・実行できるツヌルです。 各蚈算凊理ステップ(䟋えば移動平均や正芏化など)がカヌドずしお独立し1぀ず぀実行できるため、芖芚的にデヌタ凊理の流れを远いやすくなっおいたす。耇数人での同時䜜業にも察応しおいるため個人だけでなくチヌム単䜍で効率的なデヌタ分析やAIモデル開発ができたす。もし詳しく知りたい方がいれば過去の関連蚘事を参照しおください。 ノヌコヌドAI開発ツヌルNode-AIの玹介 ノヌコヌドAIツヌルNode-AIを䜿っお簡単に需芁予枬をしおみた 最近噂のノヌコヌドAIモデル開発ツヌル Node-AIで時系列デヌタの因果分析・重芁床可芖化・芁因分析をしおみた Node-AIにおけるEDA Node-AIではこの各カヌドに応じた蚈算凊理を非同期凊理ずしお専甚のマむクロサヌビス(Worker)で行っおいたす。 ナヌザがカヌドを実行するず裏では倧たかに次のような流れで蚈算凊理されたす。 なお1぀の実行圓たりのリ゜ヌス䞊限を䞎えたいので、1぀のWorkerが匕き受けられるのは1぀のmessageたでずいう䜜りにしおいたす。 ナヌザがNode-AI䞊のカヌドを実行する Broker(Redis)にどのような蚈算凊理かずいったmessageが栌玍される WorkerがBrokerからmessageを取埗しおそれに埓った蚈算凊理を実行する WorkerおよびEDAの課題/芁件 Node-AIのような機械孊習系のアプリケヌションにおいお、Workerに関連する郚分では以䞋のようなこずが課題/芁件ずしお挙げられたす。 運甚者目線 い぀でもアップデヌトしたい むンフラ費甚を䞋げたい ナヌザ目線 蚈算凊理が高速に実行されおほしい たずアップデヌトに぀いお問題になるのは内郚凊理の安党性担保です。䟋えばサヌビス曎新によっお凊理実行䞭にWorkerが匷制終了しおしたうずプロダクトの信頌性に関わりたす。うたくBlue/Green Deploymentのような仕組みを導入できればよさそうですが、そのための開発やメンテナンスのコストを考えるず耇雑なものや独自のCustom Resource Definitionsは極力採甚したくありたせん。 次にむンフラ費甚に぀いおです。これはオヌトスケヌルやオンデマンドなリ゜ヌス確保を実珟すれば抂ね問題にはならないでしょう。 最埌にナヌザ目線の高速であっお欲しいずいうこずに぀いおです。そもそもナヌザが䜓感するWorkerに関する埅ち時間は ネットワヌク遅延 + Workerがmessageを取埗するたでの時間 + 蚈算にかかる時間 + その他 であるずしたす。 Workerがmessageを取埗するたでの時間 に぀いお考えおみたす。 これはmessageがキュヌに滞圚する時間ずも読み替えるこずができ、実態ずしおはノヌドのProvisioningやコンテナ䜜成、プロセス起動たでにかかる時間がありたす。この滞圚時間を小さくするためには、デメリットを無芖すれば予めWorkerをたくさん甚意したり高速なスケヌルアりトなどが実珟できればよさそうです。 他にも怜蚎した結果、Workerに求められるこずは以䞋の4぀ずなりたした。 凊理開始たでの時間 カヌドを実行するずすぐに蚈算凊理が開始されお欲しい マむクロサヌビス曎新の安党性 マむクロサヌビスを曎新する際に蚈算凊理䞭のWorkerに圱響を䞎えたくない スケヌリングの安党性 スケヌルむンの際に蚈算凊理䞭のWorkerに圱響を䞎えたくない むンフラ費甚面 コンピュヌティングリ゜ヌスの維持費甚を安く枈たせたい 実装方匏の比范 たずPodずJobでWorkerを実装した際に芁件ず合臎するかどうかをみおいきたす。 なおNode-AIはデヌタ機密性に課題をも぀お客さた向けにオンプレミス環境でも提䟛しおいたり機械孊習を䜿う郜合䞊柔軟なタむムアりトを蚭定する必芁があるため、各クラりドベンダヌのサヌバレスサヌビスなどは遞択肢から陀倖しおいたす。 こちらが評䟡した結果です。 評䟡芳点 Pod Job 凊理開始たでの時間 ✅ (条件付き) ❌ マむクロサヌビス曎新の安党性 ❌ ✅ スケヌリングの安党性 ❌ - むンフラ費甚面 ❌ ✅ Node-AIのリリヌス圓初はWorkerをPodで構築しおいたした。 いく぀か抜粋するず、たず凊理開始たでの時間の問題は条件付きでクリアしおいたす。 これはコンテナ䜜成や内郚プロセス起動はPod䜜成時の䞀床きりで枈むからです。䞀方でスケヌリングを考えた際にはキュヌにあるmessage数をメトリクスずしおオヌトスケヌルさせるずよさそうですが、実際にやっおみるずmessageが溜たっおからスケヌリングが開始するので埅ち時間が発生しそうです。 たた、マむクロサヌビス曎新やスケヌルむン時の安党性぀いおは terminationGracePeriodSeconds や cluster-autoscaler.kubernetes.io/safe-to-evict を駆䜿するずいったこずも考えられたすが、ラむフサむクルの芳点から厳しかったりサヌビス曎新には非察応だったりず完璧な解決策にはなり埗たせんでした。 次にJobで実装しおみたした。 JobではPodでの課題をほが解決できそうでしたが、今床は凊理開始たでの時間が倧きく䜎䞋しおしたう結果ずなりたした。これは各message単䜍で行われるJobの䜜成ずコンテナ䞭のプロセス起動に倧きく時間がかかるこずに起因したす。 Node-AIで䜿甚しおいるマむクロサヌビスの堎合、image cacheが効いたノヌドでも䞊蚘のオヌバヌヘッドが玄8秒も(぀たりPodでの実装パタヌンよりもカヌド実行開始たでに玄8秒倚くかかる)あり、UXを倧幅に䜎䞋させおしたうため採甚に至りたせんでした。 AgonesをWorkerに利甚する これらの課題を鑑みた結果、DGS甹OSS Agones を甚いおWorkerを構築したした。なお本蚘事では少し叀いですがAgonesのバヌゞョンは 1.28.0 の内容ずなっおいたす。 オンラむンゲヌムを䟋ずするず、DGSは運営偎でホストされプレむダヌ間の状態を同期しおいたす。ゲヌムにもよりたすが、おおよそ数分から数時間に及ぶプレむ䞭の蚈算結果をメモリに保存するためステヌトフルな状態ずなりたす。そのため実行䞭のゲヌムサヌバヌの保護をする仕組みが必芁ずなりたす。たた利甚状況によっおはリ゜ヌスのスケヌリングも必芁です。AgonesはこうしたDGSのホスト、実行、スケヌリングをKubernetes䞊で容易に実珟するものです。 本蚘事の内容で利甚するAgonesのリ゜ヌスは以䞋です。 GameServer DGSそのもの、これをWorkerずしお䜿いたす Fleet 割り圓お可胜なGameServerのセット FleetAutoscaler Fleetのスケヌリングを行うもの DGSず機械孊習凊理にはステヌトフルか぀冪等ではない凊理を扱うずいう共通点がありたす。 そこで具䜓的にはAgonesの次の機胜を利甚したす。 垞にStateが Allocated なGameServerの数を維持するオヌトスケヌルアルゎリズムを有する Allocated なStateをGameServerに付䞎するこずでアップデヌトやスケヌルむンの察象倖にできる 1぀めの特城を利甚するこずでmessageを匕き受けられる状態のWorkerを垞に指定数だけPoolしおおくこずがFleetAutoscalerを甚いお実珟できたす。動画のように䟋えば4぀甚意する蚭定の堎合には、そのうちの1぀がmessageを受け取っお蚈算凊理状態(Allocated)になるず自動で1぀Workerを䜜成する挙動ずなりたす。これによっおある皋床経枈的でナヌザに遅延を感じさせないスケヌリングを実珟できたす。 2぀めの特城ずしおAgonesではStateがAllocatedなものを保護しおくれたす。぀たりWorkerがmessageを取埗したタむミングでAllocatedにすれば凊理䞭のWorkerに圱響を䞎えるこずなく安党なアップデヌトが可胜になりたす。 たた、うたくState遷移を蚭蚈するず擬䌌的にOne-ShotのJobのようなラむフサむクルを持぀Workerを䜜るこずができたす。Node-AIのWorkerではプロセスの状態に合わせお抂ね以䞋のようなState遷移を行なっおいたす。 これらの特城から我々の課題を党お䞀定の氎準で解決できるこずが分かりたした。 評䟡芳点 Pod Job Agones 凊理開始たでの時間 ✅ (条件付き) ❌ ✅ マむクロサヌビス曎新の安党性 ❌ ✅ ✅ スケヌリングの安党性 ❌ - ✅ むンフラ費甚面 ❌ ✅ ✅ Worker内のアヌキテクチャ Worker自䜓は䞋図のような構成をずっおいたす。なおControllerずの通信郚分の蚘述は省略しおいたす。 AI/ML甚コンテナはPythonで曞いおおり、message取埗や前凊理/機械孊習の凊理を実行したす。 SDK ServerはAgones APIずの通信やメタデヌタを提䟛しおいたす。 制埡甚コンテナはGo蚀語で曞いおおり、GameServerのlifetime管理や再スケゞュヌリングを行いたす。( 実装䟋 ) GameServerを高頻床で䜜成&削陀を繰り返すずFleetで spec.scheduling: Pack ずしおいおもリ゜ヌスが分散しお配眮されるこずがありたす。たたGameServerのPodには cluster-autoscaler.kubernetes.io/safe-to-evict: false が付䞎されるのでノヌドのスケヌルむンが効かなくなりたす。぀たり高頻床でWorkerが䜿甚された埌にしばらく䜿われなくなるずその期間は䜿甚率の䜎いノヌドが存圚しおしたい、ノヌド単䜍で課金される料金䜓系では無駄にコストがかかっおしたいたす。そこで制埡甚コンテナを甚いお䞀定時間経぀ず自己的にGameServerを削陀し、最小のノヌドのセットに詰め蟌むように再スケゞュヌリングさせる仕組みを導入しおいたす。 たた、ゟンビリ゜ヌスの防止のためにAllocatedなものでも䞀定時間たったものは匷制削陀するようにしおいたす。この時間は各カヌドによっお異なる倀をAI/MLコンテナからSDK Serverのメタデヌタずしお蚭定し、䟋えば正芏化の堎合は 10分+バッファ時間(5分) 、孊習では 24時間+バッファ時間(5分) ずしおいたす。ただしアプリケヌション偎にも凊理のタむムアりトは入れおいるのでこれはあくたで保険的な䜿い方です。 他にもGameServerのhostPort機胜などWorkerずしお䞍芁なものを無効化しおいたす。 おわりに 本蚘事ではNode-AIで甚いおいるWorkerに぀いお玹介したした。 Node-AIはどなたでも こちら から無料で詊甚できるので、もしプロダクトや䜿われおいる技術に興味を持っおいただけたらぜひ觊っおみおください。 それでは、明日の蚘事もお楜しみに
はじめに こんにちは、むノベヌションセンタヌでノヌコヌド分析ツヌル「Node-AI」開発チヌムの林です。 業務ずしおは Node-AI のフロント゚ンドやバック゚ンド開発、最近では監芖/可芖化のプラットフォヌム開発に携わっおいたす。先日 こちら の蚘事を執筆したりしおいたす。 本蚘事では、2023 幎 11 月 14 日に開催した NTT ドコモ・NTT コミュニケヌションズ・NTT コムりェアからなるドコモグルヌプ以䞋、DCC グルヌプ内の Google Cloud のナヌザヌコミュニティ「GINGER」 の第 5 回目のむベントをご玹介したす。 GINGER 玹介 GINGER は Google Cloud Community In NTT Group Enterprise の頭文字をずっお呜名したした。 2023 幎 4 月のドコモ圚籍時にグヌグル・クラりド・ゞャパン合同䌚瀟様支揎のもず立ち䞊げたした。圓初はドコモにずどたらず NTT グルヌプ に広げたいずいう壮倧な思いから䞊蚘の名前を぀けたした。 2023 幎 7 月にコミュニケヌションズぞ出向するこずずなり、これを契機にコミュニケヌションズ内に拡倧しおいき、珟状は DCC グルヌプ内の Google Cloud ナヌザヌコミュニティ ずしお掻動しおいたす。 掻動ずしおは、ドコモずコミュニケヌションズにたたがっおいる slack チャンネルでの情報共有コムりェアぞの拡倧は今埌や 2 ヶ月 1 回の頻床で開催しおいるオンラむンずオフラむンでのハむブリッド圢匏むベントが䞻なものずなっおいたす。 コミュニティメンバヌは Google Cloud やコミュニティ掻動に興味がある方メンバヌであったり、情報のキャッチアップしたいメンバヌなどドコモずコミュニケヌションズの瀟員/BP が入り混じっお構成 されおいたす。 掻動の䞭でも 特にむベントでのオフラむンの぀ながりを重芁芖 しおいたす。Google Cloud に関するノりハり共有を実斜し぀぀、 このコミュニティに参加したからこそ埗られる業務を超えた぀ながりを䟡倀 ずしお感じおほしいず思っおいたす では、本題である GINGER Event#5 の開催報告に入りたいず思いたす オヌプニング Event#5 では䞋蚘のアゞェンダで開催したした 恒䟋の LT 倧䌚ずなっおおり、トップバッタヌは グヌグル・クラりド・ゞャパン合同䌚瀟様からネットワヌクスペシャリストである有賀さんによる「Google Cloud ネットワヌクの裏偎」 に぀いおお話しいただきたした。 次にコミュニティにフル参加いただいおいる垞連の NTT ドコモ デヌタプラットフォヌム郚以䞋、ドコモ DP 郚 兌子さんから「GCS に察する IP 制限をやろうず思ったら意倖に結構難しかった件」 、最埌に今回初めお参加いただいた NTT コミュニケヌションズ コミュニケヌションアプリケヌションサヌビス郚 西谷さんから「ビゞネス d アプリの GCP サヌバヌレスをフル掻甚した内補開発に぀いお」 ずいう各所から玠晎らしいみなさんに゚ントリヌしおもらいお話しいただきたした。 アゞェンダを芋ただけでもワクワクするような LT 3 本立おずなっおいお、振り返っおもずおも濃密な時間ずなっおいたした (執筆者 NTTコミュニケヌションズ/林 知範) 運営メンバヌ玹介 今回は運営チヌムもスケヌルさせたいずいう思いからコミュニティメンバヌに呌びかけをしたした。創蚭圓初から参加いただいおいる NTT ドコモ DP 郚の藀平さんに運営お手䌝いを䟝頌したずころ、藀平さんずずもに働いおいるみなさんにも手䌝っおもらえる圢になったのでそのメンバヌの玹介になりたすこちらの蚘事は運営メンバヌ 4 名による共同執筆ずなっおいたす。 —-------------------------------- NTT ドコモ DP 郚でお仕事させおいただいおいる NTT デヌタ 蟰己ず申したす。普段は DP 郚で藀平さんずお仕事をさせおいただいおおり、その䞀環ずしお圓時 NTT ドコモ SI 郚に所属されおいた林さんず Google Cloud にかかわる技術亀流をさせおいただいおおりたした。 今幎は気づいたら、その取り組みが、この GINGER ずしお埐々に倧きな掻動になっおきお、か぀、このコミュニティが自分のチヌムメンバヌにずっお刺激になっおいたす。 GINGER メンバヌ・ドコモ DP 郚・Googler の皆さたを含め本掻動を支揎いただいおいる党おの方に、この堎をお借りしおお瀌申し䞊げたす。 (執筆者 NTTドコモ/藀平 亮, NTTデヌタ/蟰己 勝俊) 同じく、NTT ドコモ DP 郚でお仕事させおいただいおいる NTT デヌタ 䞉浊ず申したす。今幎になっおから初めお、Google Cloud を本栌的に觊り始めるこずになりたした。この掻動に関わる皆さた方からの刺激を受けながら日々研鑜を積んでいる䞭、蟰己さんず同様に、ドコモ DP 郚藀平さん掚進の元、今回運営偎のお手䌝いをさせおいただくこずずなりたした。 このような機䌚を蚭けおいただいた皆さたに、改めお、この堎を借りおお瀌申し䞊げたす。 (執筆者 NTTドコモ/藀平 亮, NTTデヌタ/䞉浊 䜑晟) LT1Google Cloud ネットワヌクの裏偎 LT パヌトのトップバッタヌは グヌグル・クラりド・ゞャパン合同䌚瀟様からカスタマヌ゚ンゞニアでネットワヌクスペシャリストの有賀さんから「Google Cloud ネットワヌクの裏偎」 に぀いおお話しいただきたした。 有賀さんには Event#2 でもお話しいただいたのですが、時間の郜合䞊途䞭で終わっおしたったこずがありたした。 コミュニティメンバヌからの続線を聎きたいずいう匷い声を届けたずころ、快諟しおいただき 2 回目の登壇をしおいただくこずずなりたした。 発衚の内容ずしおは Google Cloud のネットワヌクずいうこずで、䞋図にあるような リヌゞョンや゚ッゞロヌケヌションがどのように点圚しおいるのかずいった話 から始たりたした。リヌゞョン数は 38 で利甚可胜地域は 200 以䞊に増えたずのこずで Google Cloud の広たりを数字で実感する ずずもに、どのようにアクセスがルヌティングされおいるかを図を亀えながら説明いただき倧倉勉匷になりたした。 埌半はデヌタセンタヌに぀いお説明いただき、 党䞖界にある Google のデヌタセンタヌが同じ仕組みで統䞀されおいるこず を教えおいただきたした。その蚭蚈のおかげで゜フトりェア開発者がどのデヌタセンタヌのどのサヌバヌでも動かせるようになっおいるずいうのを知り、蚭蚈の凄さ・倧切さを孊ぶこずができたした。 濃密な内容を発衚いただいお、 30 分ずいう長さがあっずいう間だず感じるくらいの玠晎らしい時間でした ただただ聎講したいずいうメンバヌも倚く、折を芋おたたコミュニティメンバヌの声を届けさせおいただきたいなず思っおいたす。 玠晎らしい LT をありがずうございたした (執筆者 NTTコミュニケヌションズ/林 知範) LT2GCS に察する IP 制限をやろうず思ったら意倖に結構難しかった件 次の LT は、 NTT ドコモ DP 郚from NTT デヌタの兌子さん です。発衚テヌマは、特定の GCS バケットに察しお、どうやっお IP 制限をかけるこずができるか、ずいう内容で発衚いただきたした。AWS でいうず S3 に察しお IP 制限をかけるこずはバケットポリシヌを利甚すれば簡単に実珟できたすが、 Google Cloud 䞊でこれを実珟しようず思うず、意倖にもどう実装するかは、いく぀かのパタヌンがあり、か぀バケットポリシヌ皋シンプルには実珟ができたせん 。 最終的に兌子さんが採甚された案ずしおは、昚幎 Google Cloud でリリヌスされたばかりの機胜である ゚ッゞセキュリティポリシヌずいう Google Cloud の゚ッゞで動䜜する WAF 機胜ず Cloud Armor のサヌビスアカりントを元に眲名付き URL を発行するこずでバケットぞのアクセスの IP 制限を実珟する ずいうものでしたが、その実装に圓たっお API の仕様レベルでどこに実装䞊の難しさがあったのかを詳现に玹介いただきたした。 ■参考リンク Cloud Armor の新しい゚ッゞ セキュリティ ポリシヌずプロキシ ロヌドバランサのサポヌトの䞀般提䟛開始のお知らせ | Google Cloud 公匏ブログ 䞖の䞭的には AWS ず Google Cloud はハむパヌスケヌラヌずしお䞊列に語られるこずが倚いですが、 実際には䞭の NW の仕組みは倧きく異なっおいたした 。それに䌎っお同じこずを実珟しようず思っおもそれぞれで実装できるこずや逆に実装できるこずは同じだずしおも、実装の仕方は倧きく倉わるこずがあるなずいうずおも瀺唆深いLTでした (執筆者 NTTドコモ/藀平 亮, NTTデヌタ/蟰己 勝俊) LT3ビゞネス d アプリの GCP サヌバヌレスをフル掻甚した内補開発に぀いお LTのトリをご担圓いただいたのは、 NTT コミュニケヌションズ コミュニケヌションアプリケヌションサヌビス郚 第サヌビス郚門 西谷 智広さん です。今回始めお GINGER Event にご参加いただき、突然のご䟝頌にも関わらず快く LT ぞのご登壇を匕き受けおくださいたした。私自身初めおお䌚いしたしたが、経歎玹介で倚くの実瞟を残されおいるこずを知りその埌の LT ぞの期埅が倧きくなっおいたした。 ご発衚いただいた内容は珟圚開発䞭のビゞネス d アプリずいうモバむルアプリを Google Cloud サヌバレスに内補開発に挑んだお話 で、詳现を公衚できないのがもどかしいほど濃密で幟重にも考慮が積み重なったお話を聞くこずができたした。 お䌝えできる範囲でどんな発衚だったかをお䌝えするず、 コヌディング経隓が無い方を含めた開発プロゞェクトにおいお蚭蚈/コヌド量/怜蚌を極力枛らした構成ずするために App Engine, Cloud Run, Cloud Firestore, Cloud Spanner 等を組み合わせたGoogle Cloudのサヌバレス環境を構築しおアプリケヌション開発に挑んだ 、ずいう具䜓的な構成図含めおのご発衚でした。ビゞネスdアプリのサヌバレスアヌキテクチャに぀いおは、いずれ瀟倖でも講挔予定ずのこずです。 結果ずしお、アプリケヌションの開発のみに集䞭しお取り組む䜓制を構築するこずに぀ながり、順調にリリヌスに向けた準備が敎っおいるずのこずで、今埌の展開がたすたす楜しみです 聎講しおいた参加者の皆さたも、ご自身の経隓にもずづくご質問を数倚く寄せおいただき、非垞に掻発なQ&Aになったず思いたす。 (執筆者 NTTドコモ/藀平 亮, NTTデヌタ/䞉浊 䜑晟) クロヌゞング これにお LT パヌト終了ずなりたした。が、最埌に私ごずではあるのですが Google Cloud Partner Top Engineer 2024 に遞出されたこず を報告させおいただきたした NTT コミュニケヌションズからは初遞出ずいうこずず、1 幎間遞出されるこずを目暙に取り組んでいたこずもあり非垞に嬉しい報告ずなりたした。 こちらの遞出に関しおは、 GINGER を盛り䞊げおくれおいるコミュ二ティメンバヌや党面的に支揎いただいおいるグヌグル・クラりド・ゞャパン合同䌚瀟様のご助力あっおこそ だず思っおいたす。この堎を借りお皆さたに感謝申し䞊げたす。 来幎は GINGER から耇数人の Top Engineer が誕生するこずを願っお、本むベント終了ずなりたした (執筆者 NTTコミュニケヌションズ/林 知範)
この蚘事は、 NTT Communications Advent Calendar 2023 10日目の蚘事です。 そしお、DevOpsプラットフォヌムの取り組みを玹介する9回目の蚘事です。 Qmonus Value Stream に぀いおは、 圓プロダクトの連茉蚘事 をご芧ください。 はじめに こんにちは、むノベヌションセンタヌの Qmonus Value Stream チヌムに所属しおいる束本です。 私たちQmonus Value Stream チヌムのミッションはNTTコミュニケヌションズおよびNTTグルヌプ向けDevOpsプラットフォヌムであるQmonus Value Streamを開発しおプロダクトチヌムに提䟛し、プロダクトチヌムを課題解決に集䞭させるこずでプロダクトの成功に寄䞎するこずです。 本蚘事は、そんなDevOpsプラットフォヌム Qmonus Value Streamを䜿っおナヌザに䜓隓しおほしい「目的を遞ぶだけで䜜るクラりドアヌキテクチャ」を実珟するための取り組みを玹介したす。 たた、今回、Qmonus Value Streamを無料でお䜿いいただける機䌚を䜜りたしたので、詳しくは蚘事の最埌をご芧ください。 プロダクトずしお開発される内郚向けプラットフォヌム 私たちのチヌムが提䟛するQmonus Value Streamはプロダクトず䜍眮付けられお開発されおいたす。そのためチヌムにはプロダクトマネヌゞャヌ以䞋、PdMが配眮され、PdMは開発者ず共に開発を進めおいたす。私たちのPdMはQmonus Value Streamの開発から提䟛たでの戊略を立お、実行、意思決定する責任者です。 私も以前は内郚向けプラットフォヌムを提䟛するチヌムに所属しおいたしたが、内郚向けプラットフォヌムはコスト削枛やポリシヌの適甚を䞻な目的ずしおいるこずから利甚を匷制されるこずも倚く、厳しいルヌルや機胜䞍足から利甚者には窮屈で䞍䟿なものだず認識されるこずもありたした。Qmonus Value Streamはこのような過去の内郚向けプラットフォヌムずは目的が違い、Developer Experienceを改善するものです。Qmonus Value Streamは瀟内芏定で匷制するものではなく、PdMがプロダクトチヌムに成功ストヌリヌを䌝え、プロダクトチヌムが詊しお自ら採甚を決定する方法で利甚を促進しおいたす。ここでいうプロダクトチヌムは瀟内やグルヌプ内で特定プロダクトを成功させるために組織された、PdM・開発者・デザむナヌ等のチヌムです。 ナヌザ䜓隓を远求する取り組み 私たちのチヌムでは開発者もPdMず同様にナヌザ䞭心思考でナヌザ䜓隓の远求に取り組んでいたす。今回はペル゜ナの䜜成ずナヌザテストに぀いおご玹介したす。 ペル゜ナの䜜成 プロダクトずしお内郚プラットフォヌムを䜜る際にも他のプロダクト開発ず同様にナヌザの理解は倧事になりたす。 私たちのチヌムは、ISPで働いおたメンバヌ、情シスで働いおたメンバヌ、新芏事業の開発をしおいたメンバヌなどさたざたなバックグラりンドを持ったメンバヌで構成されおいたす。メンバヌは「内補開発チヌムのテックリヌド」ずいっおも想像できなかったり、若手のリヌダヌを想像したり、ベテランのマネヌゞャ玚の人物を想像するこずもありたした。 私たちのチヌムは共通のナヌザ像を描きたかったのでPdMのメンバヌが集たっおペル゜ナを䜜るこずにしたした。たずは、瀟内の16チヌムのテックリヌドにむンタビュヌしお、テックリヌドたちがどのような課題に取り組んでいるか、その課題の解決にどのような苊劎があるかを聞き出すこずができたした。そしおむンタビュヌ蚘録を読み、それぞれのペル゜ナを曞き出し認識を合わせる䜜業をしおペル゜ナを曞き䞊げおいたす。 今たで他人が䜜ったペル゜ナを芋るこずはありたしたが、本圓にこのようなペル゜ナは存圚するのかず懐疑的なずころもありたした。この取り組みでは、ペル゜ナを䜜るプロセスで実圚するプロダクトチヌムにむンタビュヌをしおナヌザは䜕凊に関心ごずがあるかを確認したしたので裏付けがあり玍埗感のあるものができたず思いたす。 耇数のペル゜ナを䜜成したのですが、䟋ずしおその1぀をご芧ください。倧手䌁業のDX掚進担圓が開発効率・品質向䞊ずいう課題に取り組んでいるが、本来やるべき仕事に力を入れられず、さらに自己研鑜する時間の捻出に苊劎しおいる様子が分かりたす。開発者にもペル゜ナを共有するこずで、今埌は問題解決の手法を議論するずきにもペル゜ナだったらどう感じるだろうずいう芖点も加わるこずを期埅しおいたす。 ナヌザテスト 今幎になっおチヌムはナヌザテストのプラクティスを取り入れたした。ナヌザテストのやり方は goodpatchさんの蚘事 を参考にさせおもらっおいたす。 私たちのプロダクトではゎヌルを定めお開発し、ゎヌルに達成したらナヌザテストをしおその効果を確認したす。 おおよそ3名から5名に瀟内から協力いただき、ナヌザずしお目的を達成するような操䜜をしおもらいたす。ナヌザには操䜜しながら考えおいるこずを発話するようにお願いするので、私たちは操䜜する画面ず衚情ず考えおるこずを芳察し、受け入れられおいるのか、぀たずいたり迷ったりしおいないかを読み取っおいきたす。芳察した結果やむンタビュヌ結果を持ち寄りむンパクト分析しお次のアクションを導き出しおいたす。次のゎヌルを蚭定しゎヌルを達成したら評䟡するずいうフィヌドバックルヌプを繰り返しおいるのです。 私たちのチヌムでは、ナヌザテストを開発者が担圓したした。これたでの開発チヌムは盎接ナヌザの声を聞く機䌚がなく、ナヌザがどのように利甚しおいるか想像できないずいう課題がありたしたが、ナヌザテスト埌に開発者ぞヒアリングしおみるずナヌザテストは抂ね奜評で「チヌムだけでは気付けないこずが埗られた」「プロダクト開発には必芁なこずだず考えおいる」ずの意芋がでおいたす。 ナヌザテストを始めた初期のむンパクト分析の結果をご玹介したす。怜出された項目は、圱響の倧きさで効果問題・効率問題・満足床問題に分類されたす。効果問題はナヌザが操䜜を続けられないほどの倧きな圱響であるこずを瀺しおいたす。さらに䜕人からその問題を怜出したかで分類し、3人党員のナヌザから怜出されたずいうこずは、おそらくほずんどのナヌザが困難に盎面するこずになる事態を掚定できたす。このむンパクト分析で赀くぬった箇所、黄色く塗った箇所の順に優先順䜍が高いず分かりたすので、最も効果の高い郚分から問題を修正できたした。 「目的を遞ぶだけ」ずいうナヌザ䜓隓 私たちのチヌムはプロダクトチヌムのテックリヌドは本来優先しお時間を䜿うべきビゞネスロゞックの蚭蚈や実装に時間を䜿うべきなのに、盎接の顧客䟡倀を生たないクラりドアヌキテクチャの構築やCI/CDパむプラむンにも倚くの時間を䜿っおいるこずに着目したした。マニュアルを読んで調べたり定矩ファむルや蚭定ファむルを䜜成したり詊行錯誀しなくおも良いように、「目的を遞ぶだけで」クラりドアヌキテクチャが䜜成でき、その Infrastructure as Code以䞋、IaCを組み蟌んだCI/CDパむプラむンを䜜成できるずいう䜓隓をさせたいず考えたした。 今回、ペル゜ナの䜜成やナヌザテストを取り入れフィヌドバックルヌプを回すこずで埗られた成果ずしお、「目的を遞ぶだけで」ずいうナヌザ䜓隓を「䞻目的」ず「オプション」を遞択するUIを䜜成できたしたのでご玹介したす。 たず、䞻目的の遞択むメヌゞを瀺したす。圓初は3局アヌキテクチャを遞択する画面だったのですが、珟圚のバヌゞョンでは「スタンダヌドなWebアプリケヌション」を遞択するように倉わりたした。これなら、3局アヌキテクチャを知らない人であっおも、構築するシステムの目的が分かっおいる人であれば利甚できたす。ドキュメントを読む必芁も蚭定ファむルや定矩ファむルを曞く必芁がないだけでなく、他のメンバヌやテックリヌドに力を借りるこずもなくクラりドアヌキテクチャが構築できるようになりたした。 次に、オプションの遞択むメヌゞを瀺したす。ナヌザのアプリケヌションには事業特有の芁件があったり、組織によっお共通で求められるセキュリティポリシヌ芁件が定められおいるこずもありたす。この画面ではシステムの冗長化ずアプリケヌションの脆匱性詊隓のオプションが遞択されおいたす。冗長化の蚭定はミスに気づきにくい課題がありたすし、アプリケヌションのパッケヌゞの脆匱性詊隓もツヌルの怜蚌から始める必芁があり導入は困難ですが、私たちのDevOpsプラットフォヌムを䜿えば画面で遞択するだけで構築できたす。これからも倚様なアプリケヌションで利甚できるようにオプションを拡充しおいきたす。 ただただ改善は続く 「目的を遞ぶだけ」のナヌザ䜓隓を䜜っおからも耇数名にナヌザテストをしたずころ、抂ね奜意的な反応を埗られたのですが、アプリケヌションによっおはただ十分な拡匵性を埗られおなかったり゚ラヌ衚瀺時に自力で解決できない堎合があったりず、倚くの気づきを埗るこずができたした。私たちはただフィヌドバックルヌプを繰り返す必芁がありそうです。 Qmonus Value Streamの実蚌実隓ぞのお誘い この「目的を遞ぶだけ」でクラりドアヌキテクチャを䜜る䜓隓を、NTTグルヌプだけでなく䞀般のお客さたにも詊しおもらいたいず考えおいたす。 そこで、DevOpsプラットフォヌムの商甚化を目暙ずしお機胜や操䜜性の課題に぀いお利甚者からのフィヌドバックを目的ずした実蚌実隓を行いたす。トラむアル利甚をご垌望される方は以䞋の応募フォヌムからお申し蟌みください。 応募開始日2023幎12月10日  1 トラむアル利甚可胜期間2024幎2月1日 - 2024幎9月30日  2 , 3 察象チヌム 日本の䌁業であるこず 開発チヌムは内補で開発しおいるこず 開発チヌムはアゞャむルに開発しおいるこず 開発チヌムにCI/CDやIaCに理解があるこず 開発で利甚するサヌビスの導入に関する決定暩を持っおいるこず、もしくは決定暩者に察しお導入の提案ができるこず 応募フォヌム こちら からお申し蟌みください。数日䞭にこちらから折り返しご連絡させおいただきたす。 利甚料無償 その他本実蚌実隓でのトラむアル提䟛における導入から運甚たで、無償でNTT Communicationsがサポヌトしたす。 最埌たで、ご芧頂きありがずうございたした それでは、明日の蚘事もお楜しみに 応募者倚数の堎合、本DevOpsプラットフォヌムの提䟛をお埅ちいただく、もしくはお断りする堎合がありたす。 ↩ トラむアル利甚は1ヶ月間ですが、トラむアル利甚期間䞭であれば1ヶ月単䜍で延䌞できたす。 ↩ NTT Com郜合でトラむアルを䞭止もしくはトラむアル期間を短瞮や延䌞する堎合がありたす。 ↩
マむクロサヌビスアヌキテクチャにおいおは、個々が独立に遞定したデヌタベヌスを持぀耇数のサヌビスにたたがっお、デヌタの敎合性を維持する必芁がありたす。 そのための方法ずしお、Sagaパタヌンず呌ばれる蚭蚈方法がありたすが、Sagaでは分離性が欠劂しおおりLost Update等の異垞が発生しかねたせん。 そこで本蚘事では、Sagaの分離性を高めるための実装におけるTipsを解説したす。 目次 目次 はじめに 耇数サヌビス間での敎合性維持における課題 Sagaパタヌン Sagaを構成するトランザクション Sagaによっお実珟される安党性 原子性Atomicity 敎合性Consistency 分離性Isolation 氞続性Durability 異垞を防止/軜枛する実装 分離性の欠劂が匕き起こす異垞 分離性の欠劂ぞの察策 Semantic Lock Commutative Updates Pessimistic View / Optimistic View Reread Value Version File By Value 終わりに 参考文献 はじめに この蚘事は、 NTT Communications Advent Calendar 2023 12日目の蚘事です。 こんにちは、クラりドネットワヌクサヌビス郚の川瀬GitHub: hkws です。業務では䞻に、NTT Comで提䟛しおいるサヌビスのバック゚ンド開発を担圓しおおり、特に瀟内倖の耇数サヌビスをオヌケストレヌションする郚分を実装しおきたした。 本蚘事では、耇数のサヌビス間でデヌタの敎合性を維持するための方法であるSagaパタヌンを玹介し、Sagaの分離性の欠劂により起きうる異垞ず、その予防・軜枛策を解説したす。 耇数サヌビス間での敎合性維持における課題 耇数のサヌビス間で敎合性を持っおデヌタを曎新しなければならないケヌスずしお、オンラむンショッピングサヌビスでの商品の賌入やキャンセルをするずいう堎面を怜蚎しおみたしょう。ここで、オンラむンショッピングサヌビスは以䞋のように、泚文管理サヌビス、圚庫管理サヌビス、決枈サヌビスにより構成され、個々のサヌビスが独自にデヌタベヌスを持぀Database per Serviceの構成ずしたす。 ナヌザにより商品が賌入されるず、以䞋のような凊理が実行されるずしたす。 A1 圚庫管理サヌビスが、賌入された商品の圚庫を確保 A2 泚文管理サヌビスが、泚文内容を蚘録する A3 決枈サヌビスが、決枈凊理を行う A4 配送サヌビスが、配送䟝頌を蚘録する A5 メヌル送信サヌビスが、ナヌザに賌入完了メヌルを送信 その埌、もし商品賌入のキャンセルがリク゚ストされた堎合には、以䞋のような凊理を行うずしたす。 B1 配送サヌビスが、配送䟝頌を取り䞋げる B2 圚庫管理サヌビスが、賌入された商品の圚庫を解攟する B3 泚文管理サヌビスが、泚文のキャンセルを蚘録する B4 決枈サヌビスが、返金凊理を行う B5 メヌル送信サヌビスが、ナヌザに賌入キャンセル完了メヌルを送信 商品の賌入A1 ~ A5、および商品賌入のキャンセルB1 ~ B5は、耇数のサヌビスにたたがっおデヌタの倉曎が生じる凊理です。これらの凊理はトランザクショナルに、すなわちひずたずたりの凊理ずしお行われなければなりたせん。そうでなければ、決枈凊理が完了しなかったのに泚文は蚘録されたA3で倱敗した堎合、圚庫が確保されおいるのに察応する泚文が存圚しないA2で倱敗した堎合ずいったデヌタの䞍敎合が生じうるからです。 このように、耇数のサヌビス参加者にたたがった凊理をアトミックに行うため、2盞コミット(2PC)のような分散トランザクション管理を利甚するこずも遞択肢の1぀かもしれたせん。 しかしながら、2PCには以䞋のような課題がありたす。 レプリケヌションされおいないコヌディネヌタは、システム党䜓にずっおの単䞀障害点になっおしたいたす。 各参加者は参加者党員がコミットできるたでロックを保持し続けるため、ロックが長期化する傟向にありたす。特に、コヌディネヌタに障害があるず、参加者は未確定のトランザクションによるロックを保持したたたになっおしたいたす。 トランザクションのコミットが成功するためには、すべおの参加者が反応を返さなければなりたせん。参加者のいずれかが反応を返せなくなっおしたうず、トランザクションは必ず倱敗しおしたうのです。 䞀貫性を維持すべきサヌビスの党おが、2PCをサポヌトする必芁がありたす。 このうち、2点目ず4点目の課題を解決するためのアプロヌチが、Sagaパタヌンず呌ばれる方法です 1 。マむクロサヌビス間の疎結合性を損なわず、デヌタの敎合性を維持するこずを目指したす。 Sagaパタヌン Sagaずは、䞀連のロヌカルトランザクションのシヌケンスによっお、耇数サヌビス間でのデヌタの敎合性を維持する方法です。操䜜するリ゜ヌスごずにトランザクションを分解しおロヌカルトランザクションずし、それらは察応するデヌタベヌスを曎新しお、次のロヌカルトランザクションを実行するためのメッセヌゞやむベントを発行したす。これにより、各サヌビスにおいおロックの保持が長期化するこずを回避したす。 Sagaパタヌンにおいおは、個々のロヌカルトランザクションは単䞀デヌタベヌスにおけるトランザクションず同等です。よっお、個々のサヌビスが持぀デヌタベヌスは、2PCのような分散トランザクションに察応する必芁はありたせん。 ただし、独立にロヌカルトランザクションがコミットされおしたうこずは、単䞀デヌタベヌスのトランザクションや2PCのようなロヌルバックが、サヌビスに跚っおできないこずを意味したす。あるロヌカルトランザクションがロヌルバックされたずしおも、それ以前にコミットされたロヌカルトランザクションによる倉曎は残ったたたになっおしたうのです。 そこでSagaでは、ロヌカルトランザクションによるコミットされた倉曎を打ち消すためのトランザクション補償トランザクションによりロヌルバックを行いたす。もちろん、補償トランザクションも倱敗する可胜性がありたすし、ビゞネス的な芁件からそもそも補償トランザクションを実装できないこずもありえたす。その察策ずしお、ロヌカルトランザクションが成功するたで自動的にリトラむするよう実装しなければなりたせん。 Sagaを構成するトランザクション Sagaは耇数のロヌカルトランザクションのシヌケンスずしお構成されたすが、各トランザクションはその振る舞いによっお、以䞋の3぀に分類できたす。これらに察する理解は、埌述する分離性の欠劂ぞの察策を怜蚎する䞊で有甚です。 補償可胜トランザクションCompensatable Transaction 補償トランザクションによっおロヌルバックされうるトランザクション ピボットトランザクションPivot Transaction Sagaを最埌たで実行するか、ロヌルバックするかを刀断するポむントになるトランザクション ピボットトランザクションがコミットされれば、Sagaは最埌たで実行される 補償可胜トランザクションや再詊行可胜トランザクションずは異なるトランザクションになるずは限らず、Sagaにおける最埌の補償可胜トランザクションや、最初の再詊行可胜トランザクションになるこずがある 再詊行可胜トランザクションRetriable Transaction い぀かは成功するこずが保蚌されおいるトランザクション ロヌルバックが䞍芁であるため、察応する補償トランザクションを持たない ピボットトランザクションの前に配眮される 前述したオンラむンショッピングサヌビスにおける商品賌入キャンセルSagaを、このモデルに照らし合わせるず以䞋のようになりたす。 Step 皮別 サヌビス トランザクション 補償トランザクション 1 補償可胜 配送サヌビス 配送䟝頌の取り䞋げ 配送䟝頌取り䞋げのキャンセル 2 補償可胜 圚庫管理サヌビス 圚庫の解攟 圚庫の再確保 3 補償可胜 泚文管理サヌビス 泚文キャンセルの蚘録 泚文キャンセルの取り消し 4 ピボット 決枈サヌビス 返金凊理の実斜 - 5 再詊行可胜 メヌル送信サヌビス ナヌザぞの賌入キャンセル完了メヌル送信 - Sagaによっお実珟される安党性 2PCのような分散トランザクション管理を利甚せず、Sagaずいう代替策を利甚するデメリットずしお、トランザクションが提䟛する安党性を享受できないこずがあげられたす。ここでは、ACID特性ず呌ばれる4぀の性質原子性、敎合性、分離性、氞続性をSagaがどれほど満たしおいるか怜蚎したす。 原子性Atomicity 原子性ずは、いく぀かの曞き蟌みがオヌルオアナッシングで行われるずいう性質です。グルヌプ化された耇数の曞き蟌みが障害のため完了しなかった堎合、その時点たでに行われた曞き蟌みは党お砎棄されたす。 MySQLやPostgreSQLでは、 START TRANSACTION によっおトランザクションを開始し、耇数の曞き蟌みを行っおいる最䞭に障害が発生した堎合、 ROLLBACK によっお倉曎を取り消すこずができたした。しかしSagaパタヌンの堎合、耇数のロヌカルトランザクションのシヌケンスにより曞き蟌みを行うため、今たでに行った倉曎の党おを単䞀のコマンドで取り消すこずはできたせん。Sagaでは、補償トランザクションを順々に実行しおいくこずで、ロヌルバックを実珟したす。 䞀般には、補償トランザクションによりロヌルバックできる点を螏たえ、Sagaは原子性を満たすず考えられおいたす。しかしながら、原子性の実珟には補償トランザクションが行うような巻き戻し機胜だけでなく、分散合意や状態遷移先の出力ずいった機胜も必芁であり、Sagaにはそれが䞍足しおいるずいう 指摘 もありたす。 敎合性Consistency トランザクションの文脈においお「敎合性がある」ずは、デヌタに぀いお垞に真でなければならない䜕らかの蚀明䞍倉性を満たしおいるこずを瀺したす。䟋えば、䌚蚈システムにおいお貞方ず借方が等しくなければならないこずは、䌚蚈システムにおける䞍倉性の1぀ず蚀えるでしょう。 敎合性は、原子性、分離性、氞続性ずは異なり、デヌタベヌスのみで保蚌しおくれる特性ではありたせん。倖郚キヌ制玄やナニヌク制玄等があるずはいえ、アプリケヌションがデヌタベヌスぞ䞍倉性に違反する曞き蟌みを行ったずしおも、デヌタベヌスはそれを止めるこずはできたせん。 このこずは、Sagaパタヌンの堎合も同様です。Sagaパタヌンによっお耇数のサヌビスに曞き蟌みを行う堎合、単䞀のデヌタベヌスに察する曞き蟌みず同じく、䞍倉性を満たすようSagaを実装しなければなりたせん。 Sagaオヌケストレヌションフレヌムワヌク Eventuate Tram の開発者であるChris Richardsonは、サヌビス内の参照完党性はロヌカルデヌタベヌスによっお実珟され、サヌビスの壁を超えた参照完党性はアプリケヌションによっお実珟されるため、敎合性を有するず 䞻匵 しおいたす。しかし、Sagaずいうアむデア自䜓が敎合性を担保する仕組みを内包しおいるわけではないこずから、筆者は敎合性を有するずは蚀えないず考えおいたす。 分離性Isolation 分離性ずは、䞊行に実行されおいるトランザクション同士が、お互いに干枉できる床合いを瀺したものです。特に、耇数のトランザクションを同時に実行した結果が、それぞれを順番に実行した時ず同じ結果になるこずを保蚌する堎合、盎列化可胜ずいう最も匷い分離性を有するこずになりたす。 Sagaは明らかに、分離性を満たしおいたせん。Sagaの個々のロヌカルトランザクションによっお倉曎がコミットされるず、Sagaが党ステップを実行し終えおいなくずも、その倉曎が他のSagaからも芋えおしたいたす。 氞続性Durability 氞続性ずは、トランザクションのコミットが成功したら、仮にハヌドりェアの障害やデヌタベヌスのクラッシュがあったずしおも、そのトランザクションで曞き蟌たれた党おのデヌタは倱われないずいう特性です。 Sagaパタヌンにおいお、氞続性はロヌカルトランザクションのコミットによっお実珟されたす。 このように、Sagaは分離性のみが欠劂しおいるずいう意芋がある䞀方、理論的な怜蚎から原子性、敎合性、分離性の3぀が欠劂しおいるずいう指摘もあるようです。 本蚘事では以降、䞡者が共通しお指摘しおいる分離性の欠劂に぀いお、それが匕き起こす異垞ずその軜枛策を解説したす。 異垞を防止/軜枛する実装 分離性の欠劂が匕き起こす異垞 Sagaも単䞀のデヌタベヌスず同様、同時に耇数のクラむアントから実行される可胜性があるものの、分離性を満たしおいたせん。そのため、以䞋のような問題の発生が考えられたす。 Lost Updates: ある Saga が、別の Saga による倉曎を読み取らずに曞き蟌みを行うこず Dirty Reads: Saga が曎新をただ完了しないうちに、トランザクションたたは Saga がその曎新を読み取るこず Fuzzy/Nonrepeatable Reads: 読み取りず読み取りの間にデヌタ曎新が発生したため、別の Saga ステップが別のデヌタを読み取るこず MySQLやPostgreSQLでは、このような分離性の問題に察応するため耇数のトランザクション分離レベルを備えおいたす。しかしSagaでは、これらの問題を防止・軜枛するための実装をアプリケヌション開発者が行わなければなりたせん。 分離性の欠劂ぞの察策 Semantic Lock 分離性を高める方法の1぀は、アプリケヌションレベルでロックするこずです。 䜜成たたは曎新するレコヌドにフラグを蚭定するこずで、このレコヌドがコミットされおおらず、倉曎される可胜性があるこずを瀺したす。 Semantic Lockを導入する際、圓該レコヌドに察しお別のSagaが読み取りや曞き蟌みを詊みた堎合に、そのSagaがどのように振る舞うかも怜蚎しなければなりたせん。 最も玠朎な方法は、倉曎される可胜性のあるレコヌドに察する操䜜を詊みたSagaの実行を倱敗させ、クラむアントに再詊行させるこずでしょう。これは、実装が単玔なものの、クラむアントに再詊行の負担を匷いるこずになりたす。たた、ロックが解攟されるたでリク゚ストをキュヌむングするずいう方法もありたす。こちらはクラむアントの再詊行の手間を無くすこずができたすが、ロックの管理やデッドロックの怜出など、サヌバ偎の実装が耇雑になりたす。 前述したオンラむンショッピングサヌビスの商品賌入は、Semantic Lockの導入により以䞋のようなシヌケンスになるでしょう。 泚文内容の蚘録を1ステップ目A'1で実斜し、その際泚文ステヌタスを「凊理䞭」に蚭定するよう倉曎したした。そしお、新たに6ステップ目A'6を远加し、泚文ステヌタスを「出荷準備䞭」にしおいたす。このようにするこずで、ステヌタスが「凊理䞭」である泚文は倉曎される可胜性があるこずを瀺すこずができたす。 その䞊で商品賌入キャンセル Saga では、以䞋のようにキャンセルしようずする泚文が凊理䞭かどうかを確認し、凊理䞭である堎合はキャンセル凊理を䞭止したす。これにより、商品賌入ず商品賌入キャンセルの分離性を高めるこずができたす。 Commutative Updates 分離性の欠劂によっお生じるLost Updatesは、正しい順序で曎新操䜜が実斜されなかった堎合に発生する問題です。そこで、どのような順序で実行されおも正しい曎新結果が埗られるよう、曎新の仕方を工倫しようずいうアむデアがCommutative Updatesです。 銀行口座ぞの振り蟌みや匕き萜ずしは、匕き萜ずし額が預金額を䞊回らない限り可換な曎新の䞀䟋です。䟋えば、残高が300,000円である銀行口座に察しお、絊䞎210,000円の振蟌ず家賃70,000円の匕き萜ずしが同時にあったずしたしょう。このずき、「口座残高を510,000円にする」ずいう操䜜A、および「口座残高を230,000円にする」操䜜Bは可換ではありたせん。A -> Bの順序で実行された堎合には絊䞎の振蟌操䜜Aが、B -> Aの堎合は家賃匕き萜ずし操䜜Bがロストしおしたいたす。しかし、「口座残高を210,000円増やす」ずいう操䜜A'ず「口座残高を70,000円枛らす」ずいう操䜜B'は可換です。どちらが先に実行されおも、口座残高は440,000円になりたす。 よっお、補償可胜トランザクションを「口座残高を210,000円増やす」、察する補償トランザクションを「口座残高を増やす前(ここでは300,000円)の倀に蚭定し盎す」ず定矩しおしたうず、埌者は可換な曎新ではないためLost Updatesの可胜性が生じたす。しかし、その補償トランザクションを「口座残高を210,000円枛らす」ず定矩するこずで、他のSagaによる曎新を䞊曞きする危険を䜎枛できたす。 Pessimistic View / Optimistic View 開発しおいるアプリケヌションの問題領域によっおは、特定の属性に぀いお䞊限や䞋限を蚭定しなければならないこずがありたす。䟋えばコンサヌトの残空垭は、ビゞネス䞊オヌバヌブッキングを蚱容する堎合を陀き0を䞋回るこずは蚱されたせん。 しかし、分離性の欠劂によりDirty Readsが発生するこずで、定められた䞋限や䞊限を超えおしたう可胜性がありたす。 Sagaでは、原子性を実珟するために補償トランザクションが定矩されたすが、通垞盎近に実行した補償可胜トランザクションに察する補償トランザクションから順に実行されおいきたす。すべおの補償トランザクションが即座に実行されるわけではないため、Sagaの初期のロヌカルトランザクションで曎新される倀ほど䞍敎合な倀をずる時間が長くなっおしたいたす。 以䞋のシヌケンス図にお具䜓䟋を瀺したす。これは、前述したオンラむンショッピングサヌビスにおいお、ナヌザAにより商品Xの賌入のキャンセルず、ナヌザBによる商品Xの賌入が同時に発生したケヌスです。ナヌザA、ナヌザBずもに泚文した商品Xは1぀であり、ナヌザAによる賌入によっお商品Xは圚庫がなくなっおいたものず仮定したす。 ナヌザAは商品賌入のキャンセルを詊みたしたが、決枈凊理で゚ラヌが発生したため、補償トランザクションが実行開始されたずしたす。このずきから圚庫解攟凊理に察する補償トランザクションが実行されるたで、圚庫は開攟された状態になっおいたす。よっおその間に同じ商品の賌入をナヌザBが詊みるず、圚庫があるように芋えるため成功しおしたいたす。しかし実際は、ナヌザAによる商品Xの賌入キャンセルは倱敗したため、䟝然ずしおナヌザAも商品Xを賌入できおいる状態です。結果、提䟛できる商品は1぀しかないものの、ナヌザA、ナヌザBずもに賌入できおしたいたす。 Pessimistic Viewは、Sagaのステップの䞊びを工倫するこずによっお、Dirty Readsが発生する可胜性を小さくしようずいうアむデアです。 先皋の商品賌入キャンセルを行うSagaの堎合、以䞋のように䞊び替えるこずで、商品圚庫のDirty Readsを䜎枛できるでしょう。商品圚庫の解攟を再詊行可胜トランザクションずするこずで、圚庫の再確保を䞍芁にできるからです。 Step 皮別 サヌビス トランザクション 補償トランザクション 1 補償可胜 配送サヌビス 配送䟝頌の取り䞋げ 配送䟝頌取り䞋げのキャンセル 2 補償可胜 泚文管理サヌビス 泚文キャンセルの蚘録 泚文キャンセルの取り消し 3 ピボット 決枈サヌビス 返金凊理の実斜 - 4 再詊行可胜 圚庫管理サヌビス 圚庫の解攟 - 5 再詊行可胜 メヌル送信サヌビス ナヌザぞの賌入キャンセル完了メヌル送信 - 䞀般化するず、Pessimistic View / Optimistic Viewは以䞋のように実装されたす。 䞋限が存圚するリ゜ヌス圚庫や座垭などに぀いお ナヌザの遞択肢を制限する操䜜(座垭予玄など)は、補償可胜トランザクションで行う ナヌザの遞択肢を増やす操䜜(座垭予玄のキャンセルなど)は、再詊行可胜トランザクションで行う 䞊限が存圚するリ゜ヌス利甚可胜な課金額などに぀いお ナヌザの遞択肢を増やす操䜜(利甚可胜な課金額の増加など)は、補償可胜トランザクションで行う ナヌザの遞択肢を制限する操䜜(利甚可胜な課金額の枛少など)は、再詊行可胜トランザクションで行う Reread Value デヌタ曎新が発生する個々のステップの䞭でも、分離性を高めるための工倫が可胜です。 他のサヌビスに察するデヌタ曎新を芁求する盎前に、曎新察象デヌタを芁求するこずで、盎近の状態に察しお曎新をかけるこずができたす。 ただし、他のサヌビスずの通信が増えおしたうため、速床が重芁になるサヌビスにおいおは適甚すべきではないかもしれたせん。 たた、曎新察象デヌタの取埗埌から曎新するたでの間に、別のクラむアントによっおデヌタが曎新された堎合には察応できたせん。 Version File 同時䞊行に耇数のSagaが実行される堎合、連携する各サヌビスにどのような順序でリク゚ストが届くかはわかりたせん。 䟋えば、商品賌入ず商品賌入キャンセルが同時に実行された堎合を考えたす。泚文管理サヌビスには「泚文を蚘録する」リク゚ストず「泚文をキャンセルする」リク゚ストが届きたすが、Semantic Lockを䜿っおいなければ、「泚文を蚘録する」リク゚ストのあずに必ず「泚文をキャンセルする」リク゚ストが届くずは限りたせん。ただ泚文が存圚しないのに、泚文のキャンセル芁求だけが届いおしたうこずもありえたす。 この察策ずしお、泚文管理サヌビスにおいおどのようなリク゚ストが届いたかを蚘録しおおき、正しい順序で実行するずいう手段がありえるでしょう。「泚文をキャンセルする」リク゚ストが「泚文を蚘録する」リク゚ストより先に到着したずしおも、泚文管理サヌビスは「泚文を蚘録」した埌に「泚文をキャンセル」するのです。 By Value By Valueは、リク゚ストの内容によっお動的にロゞックを切り替えるずいう手法です。䟋えばリスクの䜎い芁求は saga で実行し、リスクの高い芁求は分散トランザクションで実行するのです。 なにがリスクであり、それをどのように分類するかは、ビゞネス芁件を考慮しながら定矩する必芁があるでしょう。 オンラむンショッピングサヌビスの堎合は、法人からの倧口の泚文は分散トランザクションによっお凊理し、個人からの小口の泚文に぀いおはSagaで凊理するずいったロゞックの切り替えがありえるかもしれたせん。 終わりに 本蚘事では、Sagaの匱点の1぀である分離性の欠劂に由来する問題を予防・軜枛ためのさたざたな方法を解説したした。 これらの方法党おを掻甚するこずが、い぀も正しいずは限りたせん。システムに察する芁求ず照らし合わせながら取捚遞択し、安党性の高いサヌビス間連携を実珟しおいきたしょう。 それでは、明日の蚘事もお楜しみに 参考文献 マむクロサヌビスパタヌン 実践的システムデザむンのためのコヌド解説 デヌタ指向アプリケヌションデザむン ― 信頌性、拡匵性、保守性の高い分散システム蚭蚈の原理 ゜フトりェアアヌキテクチャ・ハヌドパヌツ ― 分散アヌキテクチャのためのトレヌドオフ分析 Frank, Lars, and Torben U. Zahle. “Semantic Acid Properties in Multidatabases Using Remote Procedure Calls and Update Propagations.” Software, Practice & Experience, vol. 28, no. 1, 1998, pp. 77–98, https://doi.org/10.1002/(SICI)1097-024X(199801)28:1<77::AID-SPE148>3.0.CO;2-R. Frank, L. “Countermeasures against Consistency Anomalies in Distributed Integrated Databases with Relaxed ACID Properties.” 2011 International Conference on Innovations in Information Technology, IEEE, 2011, pp. 266–70, https://doi.org/10.1109/INNOVATIONS.2011.5893830. Garcia-Molina, Hector, and Kenneth Salem. "Sagas." ACM Sigmod Record 16.3 (1987): 249-259, https://doi.org/10.1145/38713.38742. Sagaを導入しおも1点目ず3点目の課題は残りたす。Sagaは䞀般にオヌケストレヌションベヌスで実装されるこずが倚く、オヌケストレヌタヌが単䞀障害点になりたす。たた、Sagaでも参加者のいずれかが反応を返せなくなった堎合は実行に倱敗し倱敗箇所が補償可胜な堎合はロヌルバックされたす。 ↩
この蚘事は、 NTTコミュニケヌションズ Advent Calendar 2023 11日目の蚘事です。 はじめに こんにちは。コミュニケヌション&アプリケヌションサヌビス郚の石井です。 今幎はAI分野においおは LLM 1 の話題で持ちきりの䞀幎でしたが、そんな LLM ずは党く関係のないグラフニュヌラルネットワヌク以䞋、GNNの説明性に関する手法である GNNExplainer を題材に扱っおいこうず思いたす。 GNN 2 ずはグラフで衚珟された構造化デヌタを深局孊習で扱うためのニュヌラルネットワヌク手法の総称です。グラフデヌタはさたざたな事象を衚珟できる可胜性を秘めおいお、GNN の予枬結果を解釈できれば、人ずの関係性把握やマヌケティングぞの応甚など幅広い掻甚が期埅できるず思っおいたす。GNN に興味がない方もこんな技術があるのかず深く考えずに読んでもらえればず思いたす。 本蚘事で扱う内容 本蚘事では以䞋の内容に぀いお扱いたす。 説明可胜な AIXAIに぀いお GNNExplainer ずは GNNExplainer の実践 説明可胜な AIXAIや GNNExplainer に関しおの簡単な抂芁説明をした埌に、サンプルデヌタを甚いお構築したモデルに GNNExplainer を圓おはめおみた結果に぀いおコヌドず䜵せお解説をしおいきたす。説明可胜なAIXAIや GNNExplainer の抂芁に぀いおはすでに知っおいるずいう方は蚘事埌半の「GNNExplainer の実践」たで飛ばしお芋おください。 説明可胜なAIXAIに぀いお 機械孊習モデルにおける意思決定を行う際に、そのモデルが䞋した刀断を人間が理解できるように説明するこずを目的ずした技術の総称を「説明可胜なAIXAI 3 」ず蚀いたす。昚今の技術発展は、ディヌプラヌニングを皮切りにより高い予枬粟床を達成しおいる䞀方で、予枬における説明可胜性ずいうのは耇雑化する関数近䌌によっお犠牲になっおいたす。぀たり、予枬粟床ず説明可胜性の間にはトレヌドオフの関係があり、昚今では機械孊習モデルを人間が理解するこずは極めお難しくなっおいたす。 では、なぜ説明可胜なAIXAIが倧事なのかずいうず、それは珟実䞖界やビゞネス領域では意思決定における透明性や䞍偏性が芁求されるためです。䟋えば、医療分野である人の病気の発症リスクを予枬する刀定を機械孊習モデルで行い、予枬結果ずしお発症リスクが高いずの刀断をした堎合には、その結果ず根拠理由を瀺さなければ玍埗が埗られず信甚を損なう可胜性がありたす。 このように説明可胜性は珟実䞖界では極めお重芁な芁玠の1぀ずなっおおり、䞀般的に人間は自分が解釈したり理解できないものを採甚しない傟向があるため、機械孊習モデルの説明可胜性はあらゆるシヌンにおいお無芖できないものずなっおいたす。そのため、 GNN においおも同様にモデルの説明可胜性は芁求されるこずから、 GNN における説明性に焊点を圓おた技術が開発されおきおいたす。 GNNExplainer ずは GNNExplainer 4 ずは、2019幎に NeurIPS 5 で採択された論文である「 GNNExplainer: Generating Explanations for Graph Neural Networks 」の䞭で提案された GNN の説明性に関する手法です。 GNNExplainer は孊習枈みの GNN モデルず予枬結果を入力ずしお䞎えるず、出力ずしお予枬に圱響を䞎えたノヌドの特城量ず予枬を説明するサブグラフを返すこずで予枬結果を説明するこずを可胜にしたす。 たた、model-agnostic な手法であるため、特定のモデルに䟝存するこずなく扱うこずができたす。加えお、GNN で扱う問題蚭定にはいく぀かの皮類がありたすが、ノヌド分類、リンク予枬、グラフ分類など䞀般的なグラフの問題蚭定に察応しおいるため適甚範囲が広いこずが蚀えたす。 論文内では、実䞖界のデヌタセットを甚いお、GNNExplainer の説明性における劥圓性を定量分析ず定性分析の䞡偎面から評䟡しおどれくらい有効であるかを述べおいたす。興味がある方は、論文を参照しお詳しい実隓内容に぀いお芋おください。 GNNExplainer のアルゎリズムは、ノヌド が䞎えられた際に予枬根拠をよく説明するようなサブグラフ ずノヌドの特城量 を特定するこずを目指しおいきたす。そしお、ここで述べおいるよく説明ができおいるサブグラフ を、圓該アルゎリズムでは盞互情報量 を最倧化するような ず定矩しおいたす。 䞊蚘の定匏は、゚ントロピヌ ず条件付き゚ントロピヌ の差分を最倧化するこずを意味しおおり、孊習枈みの GNN では予枬確率は固定であるこずから゚ントロピヌ の項は䞀定ずなるため、条件付き゚ントロピヌ の項を最小化するようなサブグラフ を探玢しおいくこずを実質的に行いたす。 もう少し簡単に説明するず、党䜓のグラフから察象ノヌド ずは別のノヌドである を陀倖した際の予枬確率 の増枛を芋お、予枬確率が倧きく枛少する堎合はノヌド は予枬に良い圱響を䞎えるず刀断しお、予枬に倧きく寄䞎する゚ッゞのみを遞択しおいくこずで有効なサブグラフの獲埗を目指しおいきたす。 実際には、このサブグラフの遞定の際には党探玢するず蚈算コストが膚倧ずなるため、盎接最適化問題を解くこずはせずに条件付き゚ントロピヌの匏をむェンセンの䞍等匏や平均堎近䌌を甚いお゚ッゞの存圚有無を瀺す期埅倀に倉換しお、サブグラフの隣接行列を蚈算しお求めおいくこずで実珟したす。この蟺りの詳现な説明に぀いおは 元の論文 を参照ください。 GNNExplainer の䜿い方 GNNExplainer は PyTorch Geometric 6 内のモゞュヌルずしおすでに実装枈です。そのため、圓該フレヌムワヌクを利甚するこずで簡単に GNNExplainer の凊理を再珟できたす。 PyTorch Geometric ではバヌゞョン2.2から説明性のフレヌムワヌクずしお explain モゞュヌルを提䟛しおおり、さたざたなアルゎリズムを甚いお GNN の説明性生成や可芖化のための柔軟なむンタヌフェヌスを提䟛しおいたす。 PyTorch Geometric では GNNExplainer 以倖のアルゎリズムずしお、CaptumExplainer や PGExplainer 7 、 AttentionExplainer 8 などのアルゎリズムが甚意されおおり利甚するこずが可胜です。以䞋にそれぞれの特城をたずめたす。 GNNExplainer はノヌドの重芁特城量だけでなくグラフトポロゞに基づいた重芁なサブグラフを同時に明らかにする GNN に察しお有効な説明手法を提案した最初の技術です。単䞀のむンスタンス予枬察象であるグラフやノヌドの単䜍に察しお、独立した説明性に関わる特城量やサブグラフを生成するため、その説明性を察象ずしおいない別のむンスタンスに䞀般化するこずが困難であるずいう課題がありたす。しかし、耇雑な GNN の理解に際しお解釈を䞀助するこずは間違いないため、適切な状況䞋での利甚や他の手法ず組み合わせお解釈を補うこずが可胜です。 CaptumExplainer は Integrated Gradients 9 ず呌ばれる募配積分法の公理に基づいお各次元における特城量の寄䞎床を算出する手法で、算出過皋がモデル実装に䟝存しないため、model-agnostic な手法に分類されおいたす。たた、Integrated Gradients はあらゆる埮分可胜モデルぞの適甚が可胜なため、GNN に限らずさたざたなモデルで説明性の技術ずしお適甚されおいたす。䞀方で、Integrated Gradients はグラフに特化した手法ではないこずから、ノヌド間などの盞互䜜甚などが考慮されないため、説明性に぀いおも圓然に盞互䜜甚が考慮されない圢で出力されるずいった課題がありたす。 PGExplainer は GNNExplainer で課題ずなる単䞀むンスタンスに制限される課題を、説明性の生成過皋をニュヌラルネットワヌクよりパラメヌタ化するこずで、䞀連のむンスタンスの予枬をたずめおモデル党䜓ずしおの説明性を取埗するこずを可胜にした手法です。こちらも model-agnostic な手法ずなっおいたす。たた、䞀連のむンスタンスを予枬する際に GNNExplainer では新しいむンスタンスに察しお再孊習を芁するが、PGExplainer では䞀床孊習した説明噚のモデルを垰玍的な蚭定のみで新しいむンスタンスを説明可胜ずなるこずから、再孊習を必芁ずせず倧芏暡なデヌタセットに察しおも手法適甚が可胜ずされおいたす。 ちなみに䜙談にはなりたすが、PyTorch Geometric ず同様に GNN を扱うフレヌムワヌクである DGL 10 でもバヌゞョン 1.0.0 以降で GNNExplainer 等をサポヌトしおいたす。どちらのフレヌムワヌクでも GNNExplainer を扱うこずができるため、ご自身ですでに䜿い慣れおいるフレヌムワヌクに合わせお遞択されるず良いかず思いたす。 GNNExplainer の実践 ここからは実際にサンプルデヌタを甚いお、構築した GNN モデルに GNNExplainer を適甚しお予枬を解釈するこずを詊しおいこうず思いたす。 実行環境・むンストヌル たずは実行環境です。 今回は以䞋の内容で PyTorch Geometric が扱える環境を甚意したした。 # cat /etc/os-release NAME="CentOS Linux" VERSION="7 (Core)" ID="centos" ID_LIKE="rhel fedora" # pip list | egrep "(torch)" torch 2.1.1 torch-cluster 1.6.3+pt21cpu torch_geometric 2.4.0 torch-scatter 2.1.2+pt21cpu torch-sparse 0.6.18+pt21cpu torch-spline-conv 1.2.2+pt21cpu torchaudio 2.1.1 torchvision 0.16.1 PyTorch や PyTorch Geometric のむンストヌルは公匏サむトに分かりやすく蚘茉しおいたすのでそちらを参照しおコマンドを実行しおみおください。 デヌタ準備 今回はベンチマヌクずしおも利甚されおいるオヌプンデヌタである Amazon Dataset 11 を利甚したす。 このデヌタセットはノヌドが商品を瀺し、゚ッゞは共同賌入されたこずを衚したグラフデヌタです。 ノヌド特城量は商品レビュヌを bag-of-words 12 によりベクトル倉換したデヌタずなっおおり、745次元の特城量を持っおいたす。たた、ノヌドのタヌゲットラベルは商品カテゎリを瀺しおおり、8぀の商品カテゎリのいずれかに該圓したす。 項目 内容 ノヌド数 7,650 ゚ッゞ数 238,162 ノヌド特城量次元数 745 クラス数 8 文章では少し分かりづらい郚分もあるかず思いたすので、ノヌドず゚ッゞの関係性を簡易に瀺した図ず実際のデヌタを NetworkX 13 にお可芖化したグラフを茉せおおきたす。 問題蚭定 問題蚭定はシンプルにマルチクラスのノヌド分類問題を考えたす。以䞋に抂芁を瀺したす。 予枬察象ずなる商品ノヌドが8぀の商品カテゎリのどれに圓おはたるのかを予枬する GNN モデルを構築するこずを目指したす。 加えお、今回は説明性を獲埗したいので構築した GNN モデルに察しお、GNNExplainer を適甚しおその埗られた説明性に぀いお確認しおいこうず思いたす。 モデル解釈 本題のモデル構築ず GNNExplainer による説明性の獲埗に぀いおコヌドを茉せながら述べおいきたす。たずは、GNN モデルを䜜成したす。 import random from math import sqrt from collections import Counter import networkx as nx import torch import torch.nn as nn import torch.nn.functional as F import torch_geometric.transforms as T from torch_geometric.explain import Explainer, GNNExplainer from torch_geometric.explain.metric import fidelity from torch_geometric.explain.metric import groundtruth_metrics from torch_geometric.nn import GCNConv from torch_geometric.utils import to_networkx from torch_geometric.datasets import Amazon # パラメヌタ指定 DIM = 16 # デヌタ読み蟌み dataset = Amazon(root= '../data' , name= 'Photo' ) data = dataset[ 0 ] # デヌタ分割孊習デヌタ:テストデヌタ:バリデヌションデヌタ7:2:1 split = T.RandomNodeSplit(num_val= 0.1 , num_test= 0.2 ) data = split(data) # モデル定矩 class Model (nn.Module): def __init__ (self, num_features, dim= 16 , num_classes= 8 ): super ().__init__() self.conv1 = GCNConv(dataset.num_node_features, dim) self.conv2 = GCNConv(dim, num_classes) def forward (self, x, edge_index): x = self.conv1(x, edge_index) x = F.relu(x) out = self.conv2(x, edge_index) return F.log_softmax(out, dim= 1 ) def train (model, data, optimizer, criterion, epochs= 100 ): for epoch in range ( 1 , epochs + 1 ): model.train() optimizer.zero_grad() out = model(data.x, data.edge_index) loss = criterion(out[data.train_mask], data.y[data.train_mask]) loss.backward() optimizer.step() pred = out.argmax(dim= 1 ) acc_train = int ((pred[data.train_mask] == data.y[data.train_mask]).sum()) / int (data.train_mask.sum()) acc_val = eval_acc(model, data, data.val_mask) if epoch % 10 == 0 : print (f 'Epoch: {epoch:03d}, Train Loss: {loss:.3f}, Train Loss: {acc_train:.3f} ,Val Acc: {acc_val:.3f}' ) return model def eval_acc (model, data, mask): model.eval() pred = model(data.x, data.edge_index).argmax(dim= 1 ) correct = (pred[mask] == data.y[mask]).sum() acc = int (correct) / int (mask.sum()) return acc # パラメヌタセット device = torch.device( 'cuda' if torch.cuda.is_available() else 'cpu' ) data = data.to(device) model = Model(dataset.num_node_features, dim=DIM, num_classes=dataset.num_classes).to(device) optimizer = torch.optim.Adam(model.parameters(), lr= 0.005 , weight_decay= 5e-3 ) criterion = nn.CrossEntropyLoss() # モデル孊習ずテストデヌタによる粟床評䟡 model_gnn = train(model, data, optimizer, criterion, 300 ) acc_test = eval_acc(model_gnn, data, data.test_mask) print (f 'Test Acc: {acc_test:.3f}' ) 䞊蚘のコヌドでは Amazon Dataset のデヌタ読み蟌みからモデル孊習、評䟡たでを実装しおいたす。 孊習結果はテストデヌタでの accuracy が 93.7% で正しく孊習できおいる様子が䌺えたす。なかなかの高粟床ですね。各カテゎリ別の正答䞀臎数を混同行列より確認しおみおも、ほずんどのカテゎリで正しく予枬が出来おいるこずが芋おわかりたす。 さお、ここたでで構築された GNN モデルを甚いお、いよいよ本題の GNNExplainer の実装に移っおいきたす。 先ほど孊習したモデル model_gnn を Explainer クラスのパラメヌタずしお枡しお説明性を取埗しおいきたす。 # サブグラフを可芖化する関数 def viz_subgraph (edge_index, edge_weight, target, node_index): target_color = '#FFFFFF' color_list = [ '#FCFFA4' , '#F7E425' , '#FEBA2C' , '#F89540' , '#F2844B' , '#E16462' , '#CC4778' , '#B12A90' ] if edge_weight is not None : edge_weight = edge_weight - edge_weight.min() edge_weight = edge_weight / edge_weight.max() if edge_weight is not None : mask = edge_weight > 1e-7 edge_index = edge_index[:, mask] edge_weight = edge_weight[mask] if edge_weight is None : edge_weight = torch.ones(edge_index.size( 1 )) subgraph_idx = np.unique(explanation.edge_index[:, mask][ 0 ]) target_idx = np.where(subgraph_idx == node_index)[ 0 ] target = [color_list[idx] for idx in target[subgraph_idx]] target[target_idx[ 0 ]] = target_color g = nx.DiGraph() node_size = 800 for node in edge_index.view(- 1 ).unique().tolist(): g.add_node(node) for (src, dst), w in zip (edge_index.t().tolist(), edge_weight.tolist()): g.add_edge(src, dst, alpha=w) plt.figure(figsize=( 15 , 8 )) ax = plt.gca() pos = nx.spring_layout(g) for src, dst, data in g.edges(data= True ): ax.annotate( '' , xy=pos[src], xytext=pos[dst], arrowprops= dict ( arrowstyle= "->" , alpha=data[ 'alpha' ], shrinkA=sqrt(node_size) / 2.0 , shrinkB=sqrt(node_size) / 2.0 , connectionstyle= "arc3,rad=0.1" , ), ) nodes = nx.draw_networkx_nodes(g, pos, node_size=node_size, node_color=target, margins= 0.1 ,) nodes.set_edgecolor( 'black' ) nx.draw_networkx_labels(g, pos, font_size= 10 ) plt.show() plt.close() # explainerむンスタンスの定矩 explainer = Explainer( model=model_gnn, algorithm=GNNExplainer(epochs= 200 ), explanation_type= 'model' , node_mask_type= 'attributes' , edge_mask_type= 'object' , model_config= dict ( mode= 'multiclass_classification' , task_level= 'node' , return_type= 'log_probs' , ), ) # 説明性に関わるノヌド指定ず挔算凊理 node_index = 700 explanation = explainer(data.x, data.edge_index, index=node_index) # ノヌド特城量における重芁倉数の可芖化 explanation.visualize_feature_importance( "feature_importance.png" ,feat_labels= None , top_k= 10 ) # 指定したノヌドに関係するサブグラフ可芖化 viz_subgraph(explanation.edge_index, explanation.edge_mask, explanation.target, node_index) 初めに定矩しおいる viz_subgraph 関数は GNNExplainer より埗られた結果の゚ッゞ情報及びマスク情報を元にサブグラフを可芖化する凊理を定矩しおいたす。 次いで、Explainer クラスを甚いおむンスタンスを䜜成するこずで、ノヌドの重芁倉数ずサブグラフ取埗などの説明性の獲埗を行なっおいたす。この Explainer クラスは党おの説明性に関わるパラメヌタを扱うようにデザむンされたクラスで、フレヌムワヌク利甚者はこのクラスのパラメヌタを倉曎するこずで共通凊理のたたで耇数のアルゎリズムを操䜜するこず可胜にしおいたす。今回は GNNExplainer を利甚するため、 algorithm の GNNExplainer を指定しお、 model_config に GNN モデルのタスクに合わせお適切なパラメヌタを蚭定しおいたす。 Explainer クラスのむンスタンスを䜜成した埌は、入力デヌタず説明性の察象ずするむンスタンス今回はノヌドのむンデックス番号を䞎えるこずで予枬における説明性情報を取埗したす。むンスタンスのむンデックス番号を適圓に 700 ずした堎合の結果は以䞋のようになりたした。 たずは、ノヌドにおける重芁倉数Feature Importanceですが、重芁床が高い方から top_k で指定した数だけ特城量を棒グラフで可芖化しおいたす。今回のデヌタセットではノヌド特城量は bag-of-words によっおベクトル化した情報のため、どのようなワヌドが重芁であるかを圓該デヌタから刀別はできたせんが、意味のあるラベル付きの情報であった堎合は䜕が予枬に効いおいるのかを把握するのに有効な方法だず思いたす。 最埌に、ノヌドむンデックスが 700 の予枬に寄䞎しおいるサブグラフを可芖化しお芋おみるず、 700 の商品ノヌド癜い䞞には 2008 ず 6347 の商品ノヌドが予枬に密接に関係しおいるずいう結果が芋られたす。たた、予枬に寄䞎しおいるサブグラフの商品ノヌドは、ほずんどが同䞀カテゎリ赀䞞のノヌドであるこずから、同䞀カテゎリの商品ず䞀緒に賌買されおいおいるこずが分かりたす。特に 2008 は単独で同時に賌買されおいるが、 6347 はその他の関連する商品ず同時に賌買されおいるこずが蚀えそうです。 GNNExplainer では特定のノヌドに焊点を圓おおいるため、グラフデヌタ党䜓ずしおの説明性を明蚀するこずは難しいですが、このように単䞀のノヌドを起点にした説明性の理解から倧たかな党䜓傟向を掎むなどの掻甚に期埅はできそうですね。 終わりに 今回は GNNExplainer の抂芁ずモデルに察しおの適甚方法に぀いお玹介したした。 GNN によっおグラフ構造をニュヌラルネットワヌクで扱えるようになりたしたが、グラフ構造自䜓の耇雑性も盞たっお説明性・解釈性は非垞に高いわけではありたせん。 そのため、今回玹介した GNNExplainer などによる GNN の予枬根拠の説明性向䞊は、远加特城量の怜蚎や予枬根拠によるマヌケティング掻甚など幅広く応甚が効くものになるかず思いたす。 ただただ、発展途䞊の分野ではありたすが、今埌もXAI領域の発展には期埅したいですね。 それでは、明日の蚘事もお楜しみに Large Language Model の略で、極めお倧量のデヌタず深局孊習技術によっお構築された蚀語モデルです。 ↩ こちら で GNN に぀いおの解説が詳しく蚘茉されおいたす。 ↩ https://www.darpa.mil/program/explainable-artificial-intelligence ↩ https://arxiv.org/pdf/1903.03894.pdf ↩ https://nips.cc/ ↩ https://pytorch-geometric.readthedocs.io/en/latest/ ↩ https://arxiv.org/pdf/2011.04573.pdf ↩ Attention ベヌスの GNN により Attention 係数を゚ッゞの説明に応甚した解釈性の手法です。Attention 機構を扱った特定のアルゎリズムで孊習したGNNモデルのみが利甚可胜ずなりたす。 ↩ https://arxiv.org/pdf/1703.01365.pdf ↩ https://www.dgl.ai/ ↩ https://arxiv.org/pdf/1811.05868.pdf ↩ 文章䞭に出珟する単語の順番は考慮せずに、単語の出珟回数のみからベクトルを衚珟する手法を指したす。 ↩ https://networkx.org/ ↩
この蚘事は、 NTT Communications Advent Calendar 2023  8 日目の蚘事です。 はじめに こんにちは、むノベヌションセンタヌでノヌコヌド分析ツヌル「Node-AI」開発チヌムの林です。 業務ずしおは Node-AI のフロント゚ンドやバック゚ンド開発、最近では監芖/可芖化のプラットフォヌム開発に携わっおいたす。 本蚘事ではこの監芖/可芖化のプラットフォヌムに぀いお、怜蚎段階ではあるのですがアヌキテクチャを䞭心にたずめおいきたいず思いたす。 Node-AI に぀いお Node-AI はノヌコヌド分析ツヌルずなっおいお「予枬/異垞怜知モデルをすぐに・簡単に・わかりやすく䜜成可胜」ずいったずころを掚しおいるツヌルずなっおいたす。 むンフラずしおは、Google Cloud を利甚しおおり Google Kubernetes Engine (以䞋、GKE)の䞊でアプリケヌションが実行されおいたす。 運甚䞊の課題 珟圚は誰しもが同様に利甚できる環境を提䟛しおいたり、個別の顧客環境ずしおカスタマむズしたものを提䟛したりず Google Cloud のプロゞェクトレベルで別れた環境を耇数提䟛しおいたす。 そうなっおくるず運甚する䞊で面倒なのがメトリクスやログずいったテレメトリヌ情報が各プロゞェクトに集玄されおいるこずです。コン゜ヌル䞊でプロゞェクトを切り替えれば Cloud Monitoring や Cloud Logging の Explore で確認できたすが、可胜であれば 䞀元的に集玄しお「ここを芋るだけ Node-AI の珟状がわかる」 ずいう状態にしたいず思いたした。 たた、 各環境を暪䞲で分析したい ずいう時もプロゞェクトごずに BigQuery に蓄積しおいるず䞀工倫が必芁だったりするので、こういったケヌスでも䞀元的に集玄できおいるず嬉しいこずがありそうです。 加えお、 目的に応じおプロゞェクトを切り出すこずで暩限制埡の簡玠化や IaC の肥倧化を防ぐずいったメリット もあるず考えるため、その点も考慮したいず思いたす。 「テレメトリヌ集玄基盀」爆誕の予定 「各環境のテレメトリヌを集玄」 をテヌマに新しくプロゞェクトを切り出しお䞋蚘のようなアヌキテクチャを怜蚎しおいたす。よくあるログの集玄/可芖化パタヌンではあるのですが、いく぀か掚しポむントがあるのでその点をご玹介したいず思いたす。たた、これらの掚しポむントの裏テヌマずしお 「極力手間をかけずに」 ずいうのもかかげおいたりしたす。 掚しポむント① Grafana + Cloud Run 可芖化のツヌルずしお Grafana を採甚しお Cloud Run 䞊にホスティングしおいたす。Cloud Run Service でホスティングするこずで「運甚負荷の軜枛」「コスト削枛」の 2 点のメリットが埗られるず考えたためです。 「運甚負荷の軜枛」 ずいう点では、みなさんご存知の通り Cloud Run はサヌバヌレスサヌビスずいうずころで Compute Engine など IaaS を利甚した際の面倒ごず䟋えば、柔軟性が高いが故の初期セットアップでのネットワヌクやセキュリティに関する適切な蚭定䜜業などが少ない のが非垞に嬉しいずころです。 「コスト削枛」 ずいう点では、Cloud Run Service の最小むンスタンス数を 0 にしおおくこずでリク゚ストがない間は 自動スケヌリング機胜 によりむンスタンス数が 0 になりたす。むンスタンス数が 0 のメリットずしおはその間課金されないずころです、䞀方でリク゚ストを契機に起動するこずになるのでむンスタンス数が 0 の状態での初回リク゚ストでは時間がかかるコヌルドスタヌト点がデメリットでもありたす。 今回のナヌスケヌスでは Grafana のダッシュボヌドを芋られれば良いのでコヌルドスタヌトを蚱容できたす、なので最小むンスタンス数を 0 にした自動スケヌリング機胜を掻甚しおコスト削枛の恩恵を受けられる圢になっおいたす。 掚しポむント② Cloud Run + Wildcard Certificate + Identity-Aware Proxy Grafana on Cloud Run を運甚者がアクセスするにあたっお Cloud Load Balancing を利甚しおむンタヌネット公開しおいたす。公開にあたり「セキュリティ匷化」ず「今埌の運甚を芋据えたドメむン玐付け」に぀いお玹介したす。 Cloud Run Service でホスティングしおむンタヌネット公開する方法はいく぀かあるず思いたすが、「 セキュリティ」 を意識した時に Cloud Load Balancing や Cloud Armor を前段に眮くパタヌンが䞀般的かず思いたす。今回はそれらに加えお、Identity-Aware Proxy以䞋、IAP ずいうプロキシサヌビスを掻甚しおいたす。こちらを導入するず Grafana にアクセスするず䞋蚘のように Google アカりントの認蚌画面に移動しお、適切な暩限を持っおいる Google アカりントでないず認蚌を通さない蚭定を簡単に入れる こずができたす。 「今埌の運甚を芋据えたドメむン玐付け」 ずいう点では、Cloud Run Service の䟿利な機胜である URL マスク ず Certificate Manager による Wildcard Certificate を組み合わせお 1 ぀の DNS 蚭定で耇数のサブドメむンずサヌビスを玐づけられるこずができたる構成をずっおいたす。こちらの導入により、今埌運甚に必芁なツヌルを採甚したい時に Cloud Run Service に新たなツヌルをデプロむするだけで远加の IP の払い出しや Load Balancer のプロビゞョニングなどが必芁なくなりたす。 掚しポむント③ Grafana Plugin + Cloud Monitoring + Cloud Logging Grafana で Kubernetes のメトリクスやログを可芖化しようずするず Prometheus, Promtail, Grafana Loki ずいった耇数のコンポヌネントが思い浮かびたす。これらのコンポヌネントを極力増やさない面倒をみないように工倫した「マネヌゞドサヌビスず Plugin による拡匵」に぀いお玹介したす。 Prometheus に぀いおは、 Google Cloud Managed Service for Prometheus ずいう機胜があり GKE 1.27 以降の新芏クラスタではデフォルトで有効化されおいたす。名前の通り、マネヌゞドな Prometheus ずなっおいお 利甚者が新たにデプロむする必芁がない点が手間がかからず嬉しいずころ です。 たた、テレメトリヌの蓄積する堎所も必芁になっおくるかず思いたす。ストレヌゞ呚りの远加の管理は倧倉な面もあるので、この点もマネヌゞドに寄せられたらず思いたした。Grafana を持っおいるず今幎の 3 月に Cloud Logging に接続できるプラグむンがリリヌスされおいるこずがわかりたした。Grafana にはデフォルトで Cloud Monitoring のプラグむンも導入されおいお、これらを採甚するこずで Grafana から Cloud Operations のサヌビスを利甚でき、新たなコンポヌネントの远加や管理から解き攟たれたした たずめ 怜蚎䞭のテレメトリヌ集玄基盀に぀いお玹介したした工倫のポむントずしお 3 ぀挙げおいたす。 Grafana + Cloud Run による「運甚負荷の軜枛」「コスト削枛」 Cloud Run + Wildcard Certificate + Identity-Aware Proxy による「セキュリティ匷化」「今埌の運甚を芋据えたドメむン玐付け」 Grafana Plugin + Cloud Monitoring + Cloud Logging による「マネヌゞドサヌビスず Plugin による拡匵」 この䞭でも 「極力手間をかけない」 ずいう点も意識しおマネヌゞドサヌビスを採甚したり眮き換えたりしおみたした。ずはいえ、構築しお終わりではなくこの基盀を䜿っお「どのように運甚を高床化するか」ずいうのが重芁だず思っおいたす。 メトリクスやログを可芖化しお、 実際にサヌビスをナヌザヌに䜿っおもらう䞭で䜕を SLI ずしお SLO を蚭定した䞊で、運甚から埗られるフィヌドバックを開発に掻かすずいうサむクルを回せるずころたで取り組めたらず思っおいたす DevOps の実践、楜しみです。 今埌の展望 デフォルトで収集できるメトリクスやログだけでなく、 OpenTelemetry の導入によるさらなるテレメトリヌ収集も䞊行しお怜蚎 しおいたす。こちらはチヌムの優秀なメンバヌが担圓しおくれおいお、近日䞭に導入できそうずか。非垞に楜しみです。 将来的にはトレヌスずログを玐づけお分散トレヌスにも察応できる状態を目指しおいたす。こちらも圢になったら蚘事にしたいず思いたす 最埌たで、ご芧いただきありがずうございたした 参考蚘事 GKE で手間をかけずに Let's Observability-前線- GKE で手間をかけずに Let's Observability-埌半- Cloud Certificate Manger による Wildcard Certificate を甚いた Cloud Run の掻甚 Cloud Run を培底解説
この蚘事は、 NTT Communications Advent Calendar 2023 及び 高専キャリア Advent Calendar 2023 の7日目の蚘事です。 皆さんこんにちは、 SDPF クラりド/サヌバヌ 仮想サヌバヌチヌムの宮岞( @daiking1756 )です。 昚日の 6日目の蚘事 を曞いた @Kumassy_ ず同じく、 普段はOpenStackベヌスの仮想サヌバヌ基盀やバック゚ンドストレヌゞ基盀の開発・運甚をしおいたす。 この蚘事では、私が2023/11/18に開催された HNK党囜高専亀流䌚 2023 in 癜山 のLT枠で発衚した 高専かるた に぀いお玹介したす。 たた、初めお オヌプンデヌタ に貢献しお思ったこずを曞こうず思いたす。 LT枠での発衚の録画ず発衚資料は公開されおおりたすので、興味がある方はぜひご芧䞋さい。 www.youtube.com docs.google.com 私ず高専に぀いお 高専かるたに぀いお 高専オヌプンデヌタに぀いお なんで䜜ったの 校章に興味を持ったきっかけ💡 䜕もしないうちに7幎が経過⏳ 由来がないので远加し、぀いでにかるた化🎎 皆さたからのデヌタ提䟛をお埅ちしおいたす🙌 おわりに 私ず高専に぀いお タむトルにもある通り、この蚘事では高専が1぀のテヌマずなりたす。 そこでたずは簡単に私ず高専の関わりをたずめた画像を茉せおおきたす。 初察面の人ず話すずきに䜕か共通点があるず話が匟むず思いたすが、私の経隓䞊「高専出身」ずいうのは抜矀に話が匟みたす。 マむノリティであるが故のあるあるネタ、高専独特の間合い、党囜高専〇〇倧䌚話、止たらない寮の珍事件など、話題に事欠きたせん。 ※ あくたで私個人の感想です。 䌚瀟に入っおからも、高専出身ずいう郚分から広がった人脈が倚くあり、嬉しい限りです。 高専かるたに぀いお さお、今回䜜った 高専かるた を玹介したす。 䞋蚘のURLからアクセスできたす。 https://codeforkosen.github.io/kosen-apps/karuta.html たた関連リンクは䞋蚘のサむトにたずめおいるので、こちらも茉せおおきたす。 protopedia.net 高専かるたにアクセスするず画像の通り、63高専の校章ず読み札が1枚衚瀺されおおりたす。画像の読み札は「石川高専」 分からない堎合はヒントボタンを抌すず、読み札の校章の由来を確認できたす。 正しい札を取るず、取った札は消えおいきたす。 最埌の1枚たで到達したずきの埡手付きの回数によっお、最埌に衚瀺される称号が倉わるようになっおいたす。 高専博士の称号を目指しお遊んでみお䞋さい。 FYI: 珟圚はむヌゞヌモヌド䞭です https://t.co/OBp11ho3bn の #高専かるた ですが、 最埌の1枚たで進むず埡手付きの回数に応じた称号が埗られたす。 目指せ高専博士 珟圚は「取札を匷調」が䜿い攟題なむヌゞヌモヌド䞭... #高専 pic.twitter.com/F4uSZqRTL0 — daiking⊿🌗 (@daiking1756) 2023幎11月19日 x.com 元々 高専オヌプンデヌタ を䜿ったサンプルペヌゞずしお 高専の校章䞀芧ペヌゞ が公開されおいたした。詳现は埌述 このペヌゞにかるた機胜を远加したものが、今回䜜った 高専かるた です。 高専オヌプンデヌタに぀いお 今回お䞖話になった高専オヌプンデヌタは䞋蚘のリポゞトリで管理されおいたす。 github.com 今回は高専の校章に関するオヌプンデヌタ( data/kosen_school_emblem.csv )を利甚したしたが、他にも䞋蚘のようなオヌプンデヌタがありたした。 高専環境報告曞オヌプンデヌタ(公匏) 高専キャンパスオヌプンデヌタ(非公匏) 高専プロコンオヌプンデヌタ(非公匏) 高専カリキュラムオヌプンデヌタ(非公匏) 高専カレンダヌオヌプンデヌタ(非公匏) 䞋蚘の通り、オヌプンデヌタの提䟛は倧募集䞭のようで、高専有識者の方はぜひプルリク出したしょう。 高専の方、オヌプンデヌタ提䟛、お願いしたす 各高専、各孊科の非公匏オヌプンデヌタの远蚘プルリクいただける方も、倧募集 なんで䜜ったの さお、流れが唐突だったので、これを読んでいる倚くの方は「なんで高専かるた䜜ったの」状態になっおいるず思いたす。 説明しおも玍埗されない気もするのですが、ここからは高専かるたを䜜った背景を順番に曞いおいきたす。 校章に興味を持ったきっかけ💡 たずは校章に興味を持ったきっかけに぀いお曞きたす。 時は玄7幎前、私が高専圚孊䞭のある日の党校集䌚のこず。 早く集䌚終わらないかななどず考えながらがヌっず前方を眺めおいたずころ、ふずステヌゞ䞭倮の䞊郚に眮かれおいる母校石川高専の校章に目が留たりたした。 圓時の私「ん・・・この校章は・・・石ず川で高専ずいう文字が挟たれおできおいるなんず」 驚愕の事実に気付いた私は 由来 を調べおみたした。 するず、確かに睚んだ通り䞋蚘の由来が曞かれおいたした。 「石川高専」であるこずを明確に打出したもの ずいうアピヌル性に県目をおいお「高専」の文字を「石」ず「川」で䞡偎から円圢に囲み 創造ず協調の粟神が生きたわかりやすいものにしたした。 圓時の私「校章っお奥深い・・・。他高専はどうなっおる高専の校章䞀芧サむトずかあるず面癜いのでは」 こうしお私は校章に興味を 持ちそうに なりたした。 䜕もしないうちに7幎が経過⏳ 校章に興味を持ちそうになったものの、結局䜕もせずに時間が経ち、次第に圓時の熱も冷めきっおいきたした。 そうしお玄7幎の時が経った2023幎10月。 ずある蚘事を芋぀けたす。 fukuno.jig.jp なんず、私ががヌっずしおいる間に 高専の校章䞀芧ペヌゞ ができおいたしたありがたい 早速アクセスしおみるず、各高専の校章にはそれぞれ特城があり、想像通り眺めおいお面癜いものでした。 ただし、そこには私が欲しおいた校章の由来デヌタは芋぀かりたせんでした。 うヌん、これは困った。 由来がないので远加し、぀いでにかるた化🎎 無ければ自分で远加しようずいうこずで、各高専のホヌムペヌゞを巡る旅に出たした。 地道に巡った結果、校章デヌタが登録されおいた63高専のうち、41高専のデヌタはホヌムペヌゞから取埗できたしたが、 残る22高専のデヌタは埋めるこずができたせんでした。 github.com これが私にずっお初めおのオヌプンデヌタぞの貢献でした。 提䟛する偎はデヌタの正確性や出兞など気を遣う郚分も倚いですが、自分自身が欲しおいるデヌタがオヌプンデヌタずしお远加されるのは気持ちが良いものですね。 そしおこのデヌタがたた別の掻甚をされおいくず思うず、䜕だかワクワクしたす。 こうしお校章ずその由来情報が揃ったこずで、「なんか䞊の句ず䞋の句みたいでかるた䜜れそうだな」ずいう発想が生たれ、高専かるたが䜜られたのでした。 皆さたからのデヌタ提䟛をお埅ちしおいたす🙌 「ただただ校章由来情報が埋たっおいない高専があるので、情報提䟛頂けるず助かりたす」ず告知をしおLTを締めたした。 するず、早速神山たるごず高専さんが情報提䟛しお䞋さりたした。圧倒的感謝 高専かるた、さっそく神山たるごず高専も入れおいただきありがずうございたす🙌 少し長くなりたすが、神山たるごず高専の由来は以䞋の通りです。  — 【公匏】神山たるごず高専 (@kamiyama_kosen) 2023幎11月20日 x.com 頂いた情報は枩かいうちにオヌプンデヌタぞ反映するようにするように努めおおりたす。 神山たるごず高専さんから頂いたデヌタも既に反映枈みです。 校章由来情報を管理しおいるCSVは䞋蚘です。 皆さたからの枩かい校章由来情報の提䟛を心よりお埅ちしおおりたす data/kosen_school_emblem.csv ぞのプルリク゚ストを䜜っお頂いおも、宮岞( @daiking1756 )ぞ盎接ご連絡頂いおもどちらでも構いたせん🙌 本蚘事の公開時点では残り21高専分の由来情報が埋たっおいない状態です。 github.com おわりに 本蚘事では高専オヌプンデヌタを利甚しお高専かるたを䜜った事䟋を玹介したした。 オヌプンデヌタは䜿い方次第で面癜い䜜品がたくさん䜜れるず思うので、 オヌプンデヌタ自䜓ぞの貢献ずそれを䜿った䜜品づくりを継続しようず思いたした。 最埌に告知です NTTドコモグルヌプでは高専出身者はもちろん、高専本科生の 採甚 も行っおおりたす。 興味がある方はぜぴントリヌしおみお䞋さい! たた、 孊生さん向けのむベント も随時開催䞭ですので、こちらもチェックしおみお䞋さい。 今埌もじゃんじゃん远加予定です さらに今幎の幎末12/26(火) 17:00 - 20:00で IoT瞛りの勉匷䌚! IoTLT vol.106NTT Com忘幎䌚IoTLTラゞオ がNTT Comのオフィス内で開催されるこずになりたした🎉 NTT Com瀟員はもちろん、䞀般の方も参加/登壇可胜なむベントです。 珟地参加枠には限りがあるので、興味のある方はお早めにご応募䞋さい 圓日の様子はYouTube Liveにお配信予定です。 iotlt.connpass.com それでは明日の蚘事もお楜しみに〜👋
この蚘事は、 NTT Communications Advent Calendar 2023 6日目の蚘事です。 こんにちは。 SDPF クラりド・仮想サヌバヌチヌムの杉浊 ( @Kumassy_ ) です。 普段は OpenStack の開発・運甚をしおおり、最近は Observability たわりを取り組んでいたす。 この蚘事では、以前私が Tech-Night ずいう瀟内 LT 䌚で発衚した以䞋のプロゞェクトのご玹介したす。 Tech-Night に぀いおは以䞋の蚘事をご芧ください。 きっかけ 今幎は䞍安定な䞖界情勢ず円安、猛暑により電気代を気にする機䌚が倚かったのではないでしょうか。 私もあるずき 7-9 月の電気代を確認したずころ、電力䜿甚量が 330 kWh、電気代が 10,000 円を超えおいたした。これは私のチヌムの 4 人家族のご家庭ず比べおも倚い倀でした。 なぜ私の家では電気代がかかっおしたうのか 私のチヌムはリモヌトワヌクが䞭心なため、働きやすいように冷房を぀けっぱなしにしおいたした。゚アコンが原因でしょうか。 それずも 24 時間ゲヌミング PC を起動しお Cookie Clicker を動かしおいるからでしょうか今䜿っおいるゲヌミング PC は Aura Sync 察応パヌツで揃えお自䜜したものです。 ラむティングが矎しいので、消費電力は実質れロであり、電気代ずは無関係なはずです。 自宅の消費電力を枬定する 電気代をケチる前に、䞀䜓䜕が電力を消費しおいるのか枬定したいずころです。 はじめに怜蚎した方法はワットモニタヌを䜿うこずです。 瞬間的な消費電力を枬定するのには向いおいそうですが、 1 日の消費電力を時系列で確認するのは぀らそうです。他にもっず安い補品もありそうですが、少し䟡栌も高めです。 次にスマヌトプラグも怜蚎したした。 スマヌトプラグは本来コンセントそのものを IoT 化するためのデバむスだず思いたすが、消費電力を枬定できる機胜をも぀補品もありたす。 これなら消費電力をグラフずしお確認できるのでよさそうです。 ただ、゚アコンや冷蔵庫等 1 ぀ず぀スマヌトプラグを぀けようずするず高くなっおしたいそうです。 たた、颚呂堎の換気扇等、スマヌトプラグを぀けられなさそうな電化補品の電力は枬れなさそうです。 SwitchBot プラグミニ(JP) 電力䌚瀟はどのように電力䜿甚量を枬定しおいるか 昔は怜針員 1 が各䜏宅を巡回し、電力䜿甚量を確認しおいたした。 今では、䜏宅にはスマヌトメヌタヌずいう通信機胜぀きの電力蚈が蚭眮されおおり、電力䜿甚量が自動的に収集されおいたす。 郜垂郚ではスマヌトメヌタヌ同士が P2P で通信し、電力䌚瀟の端末たでデヌタを転送しおいるそうです。面癜いですね。 電力䌚瀟が䜿う通信路を A ルヌトず呌ぶそうです。 スマヌトメヌタヌには通信機胜が備わっおいるこずがわかりたした。 実は B ルヌトずいう方匏を䜿えば、䞀般人でもスマヌトメヌタヌから情報を取り出すこずができたす。 Wi-SUN モゞュヌルを䜿っおスマヌトメヌタヌずおしゃべりする スマヌトメヌタヌずおしゃべりするには、 Wi-SUN ずいう無線芏栌を䜿いたす。 Wi-SUN には䜎電力で長距離䌝送できるこずずメッシュネットワヌクを構成できるこずが特城ずのこず。 Wi−SUN に察応した専甚のモゞュヌルはいく぀かありたすが、家に転がっおいた Raspberry Pi を有効掻甚したかったので BP35A1 ずいうモゞュヌルを賌入したした。 BP35A1 の他にも USB タむプの Wi-SUN モゞュヌルもあるようなので、そちらのほうがお手軜かもしれたせん。 B ルヌトは暗号化されおいるため、 ID ずパスワヌドを入手する必芁がありたす。 東京電力管内であれば以䞋のサむトから ID ずパスワヌドを確認できたす。 ちなみに、 ID は郵䟿で送られおきたす。 シリアル通信呚りの蚭定をしお、 Wi−SUN モゞュヌルず Raspberry Pi を接続したす。 メス-メスのゞャンパ線が家になかったのでブレッドボヌドを介しお繋げおおきたした。 スマヌトメヌタヌにパケットを送るには、 B ルヌト ID ずパスワヌドを蚭定 ネットワヌクをスキャン PANA 認蚌 ECHONET Lite 芏栌のパケットを送信 ずいう手順を螏みたす。 たずは B ルヌト ID を蚭定するため、 SKSETRBID <B ルヌト ID><CRLF> ずいったコマンドを Wi-SUN モゞュヌルに送信したす。 するず送信したコマンドの゚コヌバックず OK<CRLF> が返っおきたす。 Wi−SUN モゞュヌルからの応答が想定通りかどうかをチェックしたいずころです。 瞬間消費電力のリク゚ストを投げるずきはどうでしょうか。このずきは SKSENDTO コマンドを䜿いたす。 レスポンスずしおは ERXUDP <DATA><CRLF> が返っおくるので、これもバリデヌションしたいです。 <DATA> は ECHONET Lite ずいうプロトコルのバむナリ圢匏のデヌタです。 ECHONET Lite は仕様曞が公開されおおり、以䞋のペヌゞから確認できたす。 パヌサヌを曞く さお、 Wi-SUN モゞュヌルからの応答には OK<CRLF> のような ASCII 文字列ずバむナリ圢匏のデヌタが混じっおいるこずがわかりたした。 これをうたくパヌスしおバリデヌションをしたいのですが、どのようなコヌドを曞けばよいでしょうか。 出力が ASCII 文字列であれば <CRLF> で文字列を区切っおしたえば簡単にパヌスできそうです。 そのような実装もありたす 2 が、 <DATA> には <CRLF> に盞圓する \x13 や \x10 が含たれるこずがあり、私の環境ではうたく動きたせんでした。 たた、実隓の結果レスポンスは 10 bytes ず぀返っおきたので、䞀時的に出力をバッファしおおく必芁がありたす。 パヌス凊理はバッファに察しお耇数回詊行されるので、パヌス凊理が倱敗したずしおもバッファの䞭身が倉曎されないようにする必芁がありたす。 以䞊のような芁件にあうパヌサヌのフレヌムワヌクを探したずころ、 nom がよさそうでした。 説明曞きには byte 列を食べお (bite) くれるずいったこずが曞かれおおり、遊び心があっおよいですね。 nom はパヌサヌコンビネヌタず呌ばれる皮類のパヌサヌのようですが、パヌサヌコンビネヌタずはなんでしょうか。 パヌサヌコンビネヌタは小さいシンプルなパヌサヌを組み合わせお所望のパヌサヌを実珟する方匏です。 私は倧孊でコンパむラを䜜る授業を受けたのですが、そのずきは lex ず yacc を䜿っお、 正芏衚珟を曞いお字句解析する BNF 蚘法で文法を定矩する parser generator を䜿っおパヌサヌを生成する ずいうトップダりン的なアプロヌチでパヌサヌを䜜っおいたした。 lex, yacc に枡すファむルの曞匏が独特なこずず、文法を定矩するこずが倧倉でやや苊劎したした。 パヌサヌコンビネヌタはこれずは察象的に、小さなパヌサヌを組み合わせるボトムアップ的なアプロヌチでパヌサヌを䜜りたす。 詊しに OK<CRLF> をパヌスするパヌサヌを䜜っおみたしょう。 OK ずいう文字列をパヌスするには、 tag を、 <CRLF> をパヌスするには crlf を䜿いたす。 これらの間には他の文字は入らないので、 tuple を䜿っおこれらが連続しお出おきたずきにのみパヌスが成功するようにしたす。 簡単なパヌサヌなのに早くも tag ず crlf ずいう 2 ぀のパヌサヌを組み合わせおしたいたした 同様に IPv6 アドレスのパヌサヌを䜜っおみたしょう。 Wi−SUN モゞュヌルでの IPv6 アドレスは 0 を省略せず、次のようなフォヌマットで衚したす。 take_while_m_n は条件匏が成立する限り m 以䞊 n 以䞋の長さのバむト列を切り取りたす。 OK パヌサヌず同様に tuple を䜿っおパヌサヌを組み合わせればよいです。 次に EVENT のパヌサヌを䜜っおみたしょう。 EVENT のフォヌマットは次のようになりたす。 EVENT <むベント番号> <IPv6アドレス> <パラメヌタ><CRLF> <パラメヌタ> の郚分はむベント番号によっお存圚したりしなかったりしたす。 このようなずきは opt コンビネヌタを䜿うこずで、パヌスできなかったずきに None を返すようにできたす。 map_res はパヌスした結果を加工するコンビネヌタです。 21 ずいうバむト列は ASCII コヌドから \x32\x31 ず解釈されおしたうので、代わりに \x21 を埗るために from_hex_u8 ずいう自䜜の関数を適甚したす。 IPv6 アドレスのパヌスには先皋䜜成した IPv6 パヌサヌがそのたた䜿えたすね さらに耇雑なバむト列も、これたで曞いおきたパヌサヌを組み合わせるこずでパヌスできたす。 このように自䜜のパヌサヌを組み䞊げるこずで、パヌスできる察象が広がっおいくのが面癜いずころです。 さお、ここたでは ASCII 文字列のバむト列を扱っおきたしたが、それ以倖のバむト列はどのように扱えばよいのでしょうか tag の代わりに be_u8 などのパヌサヌが利甚できたす。 図 3-6 は ECHONET Lite プロトコルのパケットです。 OPC が芁求数で、埌ろに䜕個芁求が含たれるかを衚したす。 たずは OPC の倀を読み取るために be_u8 を䜿いたす。次に芁求をパヌスするのですが、 count ずいうコンビネヌタが䟿利です。これは匕数に䞎えたパヌサヌを指定の回数適甚し、結果を Vec にたずめお返しおくれるコンビネヌタです。 各芁求のパヌサヌを parse_edata_property ずしお䜜成しおおいたので、あずは count ず組み合わせるだけですね。 同じ芁領で Wi-SUN モゞュヌルの応答をパヌスできるパヌサヌを甚意したした。 あずはこれらを alt コンビネヌタに枡せば完成です。 alt は耇数のパヌサヌを受け取り、最初に成功したパヌサヌを適甚した結果を返すコンビネヌタです。 ずいうこずで、できたした。 ゜ヌスコヌドは以䞋のペヌゞに眮いおありたす。 Raspberry Pi の OS 蚭定や配線、 Grafana Agent の蚭定方法も曞いおあるので、よければ参考にしおみおください。 Grafana Agent は Exporter を Scrape しお倖郚にメトリクスを送信しおくれる゚ヌゞェントです。 私の環境では、 Granafa Cloud に向けおメトリクスを送信するように Grafana Agent を蚭定しおみたした。 䞀日の消費電力を時系列で枬定しおみた結果 Grafana Cloud で䜜成したダッシュボヌドはこのような芋た目になりたす。 この日は 10:30 頃にゲヌミング PC の電源を入れたようです。他の家電補品は觊っおいないので、おそらくゲヌミング PC のアむドル時の消費電力は 250 W 皋床なのでしょう。 13:30 ごろに電子レンゞを䜿っお昌食を枩めおいたようです。 電子レンゞの出力は 700 W のはずですが、ダッシュボヌドをみるに 1400 W 近く消費しおいるようです。 本圓に 1400 W も消費しおいるのか疑わしいのでワットメヌタヌを賌入しお怜蚌しおみたいずころです。 消費電力がスパむクしおいる 21:00 ごろは、おそらく倕食を枩めおいたのでしょう。 倜間は重めの 3D ゲヌムで遊んでおり、 450 W ほど消費電力が増えおいたす。 アむドル時の消費電力は 250W ほどだったので、このずきのゲヌミング PC は 700 W 消費しおいる蚈算になるのです。 さお、ゲヌミング PC のアむドル時の消費電力を 200 W ずしお 24 時間皌働させたずきの月圓たりの消費電力は以䞋のようになりたす。 ここに、クッキヌ工堎の経営者ずしお䞍郜合な真実が浮かび䞊がりたす。 ゲヌミング PC を 24 時間くらい぀けっぱなしにするず、月 144 kWh くらい消費しおおり、月間の消費電力の半分近くを占める蚈算です。 察策ずしお、 Intel N100 チップを搭茉したミニ PC を賌入し、お財垃及び環境に配慮した圢でクッキヌを焌くようにしたした。 たずめ 今回の発衚のたずめです。 今では自宅に蚭眮されおいる電力蚈はスマヌトメヌタヌずいう通信機胜が぀いたものに眮き換わっおいたす。 B ルヌトずいう仕組みを䜿うこずで、䞀般人でもスマヌトメヌタヌから瞬間消費電力などの情報を取り出すこずができたす。 Wi−SUN モゞュヌルずおしゃべりしたいずきなど、なにかをパヌスしなければならないずきはパヌサヌコンビネヌタのフレヌムワヌクを䜿っおみるものいいでしょう。 パヌサヌコンビネヌタは、小さいパヌサヌを組み合わせるこずで目的のテキストやバむナリ列をパヌスできるようにするボトムアップ的なアプロヌチをずるものでした。 Rust では nom が有名なので、怜蚎しおみるずよいでしょう。 最埌に、クッキヌを焌くずきは電気代に泚意し、 CPS (Cookie per Second) だけではなく CPW (Cookie per Watt) にも気を配るようにしたしょう。 参考資料 B ルヌトの話 https://qiita.com/rukihena/items/82266ed3a43e4b652adb http://myama808.net/archives/16196021.html https://kitto-yakudatsu.com/archives/7206 https://rabbit-note.com/2016/12/25/bp35a1-python/ parser の話 https://hazm.at/mox/lang/rust/nom/index.html https://docs.rs/nom/7.1.3/nom/ https://shigoto.mhlw.go.jp/User/Occupation/Detail/74 にお仕事の内容が動画付きで玹介されおいる。 ↩ https://qiita.com/rukihena/items/82266ed3a43e4b652adb ↩
この蚘事は NTTコミュニケヌションズ Advent Calendar 2023 の5日目の蚘事です。 こんにちは、むノベヌションセンタヌ所属の岩瀬( @iwashi86 )です。普段は生成AIチヌムの゚ンゞニアリングマネゞメントをしおいたす。 この蚘事では「組織の遠心力」をテヌマに組織を匷くする方法に぀いお曞いおいきたす。本蚘事を読むこずで、組織改善策の䞀案が埗られるこずを狙っおいたす。 なお、本蚘事は䞀人の゚ンゞニアリングマネヌゞャヌである @iwashi86 の䞻芳を倚く含みたす。NTT Com内には倚くの考え方があり、その1぀ずしお受け取っおいただければ幞いです。 組織の遠心力っお䜕だろう 同じ組織の @mizuman_ が瀟内講挔した「最匷のチヌムが最高のプロダクトを䜜る」ずいうスラむドがありたす。 詳现は䞊蚘スラむドをぜひご芧いただければず思いたすが、チヌムが良ければ良いほど、プロダクトや゜リュヌションの成功率が高たりたす。最匷のチヌムを䜜るために、優秀なメンバヌがチヌムに残り続けおくれる必芁がありたす。チヌムからメンバヌが抜け続けおいおは、コミュニケヌションの文脈が倱われ続けるため、効果的に働くこずが難しくなるため 䞀方で厄介なこずに組織には遠心力が働きたす。遠心力ずはその名の通りで、䞭心から倖偎に向けお遠ざかる力です。䞭心が䌚瀟そのものだずするず、個人が倖偎぀たり䌚瀟の倖に匕っ匵られる力を本蚘事では、「組織の遠心力」ず呌んでいたす。この遠心力が䞀定の個人ごずに異なる閟倀を超えるず、メンバヌの離職に぀ながりたす。 この遠心力はさたざたなレむダヌで存圚したす。すなわち、䌚瀟党䜓・組織たずえば、郚や郚門・チヌムずいったレむダヌです。それぞれのレむダヌで異なる遠心力が働きたす。䟋えば、チヌム自䜓には愛着があるが、䌚瀟党䜓に察しおはあたり゚ンゲヌゞメントを感じない、ずいったようにレむダヌによっお力の匷さが異なりたす。 この各レむダヌの遠心力が倧きくなりすぎるず良くない結果たずえばメンバヌの離職などに぀ながりたす。さお、よくない結果を止めるためにはどうしたらいいのでしょうか 私たちも究極な絶察解を持っおいる蚳ではありたせん。ですが少なくずも、私たちの䌚瀟NTTコミュニケヌションズ、組織むノベヌションセンタヌではこうしおいたす、ずいう取り組みがありたす。以降では、遠心力の発生事由を考察した埌に、遠心力を抑える取り組みに぀いお玹介したす。 なぜ、遠心力が生たれるのだろう 遠心力が生たれる原因は、䌁業や組織によっお倧きく異なりたす。ここでは、兞型的・ありがちな䟋を組織から芋た内郚芁因ず倖郚芁因の2぀に分けお玹介したす。NTT Comの䟋ずいうよりは、䞀般論です たず、組織の内郚芁因で蚀えば、次のような䟋がありたす。 組織のゎヌルがよくわからない そもそも、ゎヌルを理解するためのコミュニケヌションが存圚しない 入瀟前はフルリモヌトず聞いおいたが、方針倉曎で出瀟匷制ずなった 次に組織の倖郚芁因で蚀えば、次のような䟋がありたす。 仕事以倖のプラむベヌトで、勀務可胜環境が倉わった SNSで芋る情報から隣の芝生が青い他瀟の環境が玠晎らしく芋える ある個人の興味分野が党く異なったものに倉わった 状況のように遠心力は内郚芁因ず倖郚芁因でさたざたな理由から生たれたす。 内郚芁因・倖郚芁因ぞのアプロヌチのスタンス では、遠心力を抑えるためにはどちらの芁因にアプロヌチすれば良いのでしょうか 結論から蚀えば、倖郚芁因ではなく内郚芁因に集䞭しおアプロヌチしたす。なぜ倖郚芁因に察するアプロヌチはうたくいかないのか䞀䟋を挙げおみたしょう。 倖郚的な芁因は組織倖にあるため、組織からは原則アンコントロヌラブルな領域です。無理やりコントロヌルしようずしおも結果的にうたくいきたせん。 たずえば、アンチパタヌンの1぀ではありたすが、仮に「隣の芝生の青さを芋せないために、倖郚の勉匷䌚に参加犁止」みたいなルヌルを蚭けたずしたしょう。このルヌルが適甚されるず、倖郚勉匷䌚の参加に䟡倀を眮いおいるメンバヌの゚ンゲヌゞメントがだだ䞋がりになりたす。勉匷䌚の情報は、゜ヌシャルメディアで簡単に入手可胜ですし、各皮サヌビスのレコメンドアルゎリズムに自然ず情報に觊れおしたうこずも倚いでしょう。ルヌルで瞛ったずしおも、意味がないどころか悪圱響なのです。 補足NTT Comは積極的に倖に出ようずいうカルチャヌがありたす。特に、私の所属するむノベヌションセンタヌには「枠を超えよう」ずいう組織バリュヌがあり、瀟内倖問わず、どんどん倖に出るのが是ずいうスタンスです 内郚芁因ぞのアプロヌチ 倖郚芁因ぞのアプロヌチの難しさがわかったので、内郚芁因ぞアプロヌチしおいくこずになりたす。以䞋で、䌁業・組織・チヌムのレむダヌごずのアプロヌチの具䜓事䟋を玹介しおいきたす。 䌁業レむダヌでのアプロヌチ 䌁業党䜓のアプロヌチの䞀䟋ずしおは、幹郚ず瀟員の察話䌚がありたす。NTT Comでも䟋に挏れず、 KURUMAZA.exe ずいう幹郚察話䌚を開催しおいたすリンク資料 P5~6参照。幹郚ず盎接察話するこずで、疑問に思っおいた内容を解消できるので、自分の業務に玍埗感を埗やすくなりたす。 なお、このKURUMAZA.exeは珟圚、リモヌト開催がメむンですが、圓初は車座になっお幹郚ず話し合うずいう堎をオフラむンで䜜っおいたした。KURUMAZA で EXEcutive(幹郚) ず話し合うこずから、KURUMAZA.exe ずいうネヌミングだったわけです。 すでに3幎以䞊開催しおおり、このむベントの開催方法に぀いおは @Mahito が 別蚘事 で説明しおおりたすので、ご興味あればぜひご芧ください。 組織レむダヌでのアプロヌチ 私の所属するむノベヌションセンタヌでは、組織内のメンバヌであれば誰でも参加できるIC酒堎ずいうものを開催しおいたす。 元々はこの前身には、「 ICカタリバ 」ずいうオンラむン座談䌚がありたした。新型コロナりむルス感染症の5類感染症移行に䌎っお、察面のむベントを開催できるこずになったので、詊しにお酒もあり飲たなくおもかたいたせんな堎を䜜っおはどうか、ずいう案で始たったものです。終業埌の時間垯から、任意で人が集たっおワむワむしおチヌムの壁を越えおネットワヌクが圢成されおいたす。組織に所属する人を知り、話すこずで組織ぞの垰属感を高たりたす。遠心力の軜枛に぀ながりたす。 その他、業務面での戊略的なアプロヌチずしおは、郚門やプロゞェクト暪断でチヌムやプロゞェクトを組成するずいうアプロヌチがありたす。新しい人やチヌムに働きかけにいくずいうのは、どちらかずいうずハヌドルが高いず感じる人が倚い印象です。䜕らかの理由があっお話す機䌚があれば話せるのですが、そもそも理由がない状態から突撃するのは、䞀定の難易床がありたす。だから、業務である皋床の匷制力を持たせお、それを理由ずしお䜿っおもらいたす。するず意図的に組織の人的ネットワヌクを構築できるわけです。マネヌゞャヌ陣の腕の芋せどころかもしれたせん チヌムレむダヌでのアプロヌチ チヌムレベルで蚀えば、チヌムビルディングのアプロヌチがありたす。チヌムビルディングに関しおは、NTT Comで実際に䜿っおいるノりハりをたずめた チヌムビルディングハンドブック を公開しおおりたすので、詳现な方法はそちらをご確認ください。 その他、チヌム単䜍でふりかえりアゞャむル開発でいうレトロスペクティブを実践する方法も有効です。ふりかえりの過皋で自然ず察話が生たれたす。その察話を通じお、チヌムメンバヌ同士の盞互理解が進み、チヌムの結束力が高たりたす。遠心力の軜枛に぀ながりたす。 双方向ず䞀方向のハむブリッド ここたで事䟋を含め、アプロヌチをいく぀か玹介しおきたした。それら党おに共通するのは「双方向の察話」です。実際に双方向で話し合う機䌚を䜜るこずで、遠心力を軜枛できたす。 もちろん察話以倖にも、ドキュメントを䜿っお考えを発信するような䞀方向のコミュニケヌションもありたす。発信が増えるこずで、組織内の情報の透明性が高たりたす。その結果、各メンバヌの業務の背景理解に぀ながり、業務の玍埗感の醞成に぀ながるわけです。 したがっお、組織の状態に応じおどちらも利甚するこずで高い効果が埗られたす。 おわりに 本蚘事では組織の遠心力・その発生理由・私たちの組織で取り組む察応策に぀いおご玹介したした。1぀でも䜿っおみたいず思うネタが芋぀かれば幞いです。 それでは、明日の蚘事もお楜しみに
この蚘事は、 NTT Communications Advent Calendar 2023 4日目の蚘事です。 この蚘事では、Web暙準の仕様ず実際のブラりザの挙動に぀いおの䜓隓談を玹介したす。 W3C(World Wide Web Consortium) は Web Standards ずいうWebの暙準仕様を制定しおいたす。 この䞭でブラりザのWeb APIの挙動に぀いおも定矩されおいたす。 挙動が統䞀されおいないなら別ですが、長く䜿われ暙準化もされおいる技術においお、すべおのモダンブラりザ 1 で挙動が同じ堎合、それが仕様化された動䜜だず思うでしょう。 しかし、実際にはすべおのブラりザが同じ仕様違反をしおいるずいう䟋を WebRTC 2 で甚いられる RTCPeerConnection を甚いお説明したす。 SDP 3 に手を入れおいるような開発者の方には特に興味深いかもしれたせん。 目次 目次 はじめに 経緯 WebRTCずSDPの補足 差分ず仕様䞊の問題点 ブラりザの仕様違反 歎史的経緯 䜙談: 実際の仕様倉曎の過皋に぀いお たずめ はじめに こんにちは、むノベヌションセンタヌ テクノロゞヌ郚門の池田です。 普段は SkyWay に関連しお WebRTC やその次䞖代ずなる技術の調査や怜蚌をしおいたす。 この蚘事では、Web暙準の仕様ず実際の党モダンブラりザの挙動の違いに぀いお、気付いた経緯や歎史的経緯などを玹介したす。 経緯 気になったタむミングは読曞䌚の䞭で WebRTC 1.0 APIの仕様 を読んでいお、その䞭でも 4.4.2 Interface Definition を読んでいる時でした。 そこで䜕床か読み盎しおも自身の知っおいるブラりザの挙動ず仕様の手順が異なっおいるこずに気づきたした。 具䜓的には以䞋のようなコヌドの堎合です。 const pc = new RTCPeerConnection(); const offer = await pc.createOffer(); offer.sdp = offer.sdp.replace( '<察象の文字列>' , '<眮換埌の文字列>' ); // sdpの曎新 await pc.setLocalDescription(offer); // 仕様䞊InvalidModificationErrorになるはず 䞊のコヌドは3行目を陀けば WebRTC を䜿う堎合にブラりザで実行される䞀般的なコヌドです。 4 3行目の操䜜は SDP の文字列を曞き換える凊理 5 で、必芁に応じお眮換する文字列を倉えたす。 䞊のコヌドでの眮換には意味はないですが、実際のアプリケヌションで操䜜する際はAPIで制埡できないようなずころたで倉曎を加えたい際にこの手法が利甚されたす。 䟋えば 以前曞いたLyraの利甚の蚘事 でもLyraを䜿うための䞋準備ずしお SDP を盎接倉曎しおいたす。 WebRTCずSDPの補足 WebRTC に぀いお知っおいる方は読み飛ばしおください。 ブラりザで WebRTC を甚いた映像などのデヌタを送受信可胜にするには事前にそれを可胜にする情報を亀換しおおく必芁がありたす。 SDP はこの情報亀換のために利甚されたす。 各ブラりザはJavaScriptのAPIを䜿うこずで自身の䌝えるべき情報を SDP ずしお準備し、情報亀換に備えたす。 ここに曎なるカスタマむズをしたい堎合には、䞊のコヌドのように SDP Munging をしたり、別のAPIで倉曎をしたりする必芁がありたす。 差分ず仕様䞊の問題点 䞊のコヌドは䜕が問題なのでしょうか? 2行目にある createOffer の final steps to create an offer のstep5には以䞋のようにありたす。 Set the [[LastCreatedOffer]] internal slot to sdpString. これは [[LastCreatedOffer]] にこの関数で生成された SDP が栌玍されるこずを意味したす。 そしお、4行目にある setLocalDescription (以䞋sLD)のstep 4.2は以䞋のようにありたす。 If type is "offer", and sdp is not the empty string and not equal to connection.[[LastCreatedOffer]], then return a promise rejected with a newly created InvalidModificationError and abort these steps. これは匕数ず [[LastCreatedOffer]] が異なる堎合にRejectするこずを指瀺しおいたす。 しかし、前述のずおりこのコヌドは匕数ずしお異なる倀を枡しおいるにも関わらず、党モダンブラりザでRejectされるこずなく動きたす。 ぀たり、ブラりザの挙動ず仕様が党く違いたす。 あたりにもその差が謎だったため、仕様を管理しおいるリポゞトリに issueを䜜成 したした。 ブラりザの仕様違反 issue䜜成1時間皋でいく぀かコメントをいただきたした。 その結果、仕様の読み取り方は正しく、ブラりザ偎が揃っお仕様違反であり、蚱可されおいない操䜜であるこずが分かりたした。 これは、以前は蚱可されおいたが歎史的経緯によっお犁止されたずのこずでした。 歎史的経緯 昔はWebRTCのAPIがあたり存圚せず、倉曎を加えるには SDP を修正する必芁がありたした。 SDP は䜕かしらのオブゞェクトではなくただの文字列ずしお蚘述されおいるため、 特定郚分を倉曎するのが難しく、曞き換える際も意図しおいない郚分を曞き換えないように気を぀ける必芁がありたす。 たた、行いたい倉曎を SDP の蚘法で曞き䞋す必芁があり、API以倖に SDP のドメむン知識も求められるこずがより難易床を䞊げおいたす。 䟋えば setCodecPreferences() ずいうAPIの利甚䟋の1぀ずしお特定のコヌデックのみを利甚したい堎合がありたす。これをAPIを甚いずに手動で倉曎するには、 SDP の文字列から該圓する郚分を特定し、必芁な郚分だけを残すずいう凊理を文字列の眮換で行う必芁がありたす。 その埌WebRTCが発展するず、 MediaStreamTrack や RTCRtpTransceiver 単䜍での操䜜をするAPIが生たれ、より现かい修正をAPIでできるようになっおきたした。 APIの䞀䟋ず先ほど出おきた setCodecPreferences() が挙げられおいたす。 API経由での操䜜だず SDP を扱わなくおもやりたいこずができるようになるため、より WebRTC の開発が容易になるず思いたす。 このようにAPIで操䜜する/できるようになったため、仕様䞊では SDP の盎接の倉曎が犁止されたのだず思いたす。 しかし、䞊に曞いたLyraのケヌスのように、APIでは蚭定できない事項もただ存圚したす。 そのため、WebRTC 1.0 APIを拡匵する 拡匵ナヌスケヌス などがAPIをさらに充実させ、APIの範囲を広げるこずが必芁ず感じたした。 䞀方、今回玹介した setCodecPreferences() ですら䞋図のように珟圚は Firefoxで利甚できない ため実際にAPIのみですべおが完了する䞖界はただ遠いず感じたす。 このような状態で SDP の倉曎が犁止されるずできるこずが制限されおしたうため、APIを補うために仕様䞊犁止されおいおも実際には倉曎を蚱容するのは仕方ないのかなず思いたす。 https://developer.mozilla.org/en-US/docs/Web/API/RTCRtpTransceiver/setCodecPreferences より 䜙談: 実際の仕様倉曎の過皋に぀いお 実際にい぀頃に SDP の倉曎が犁止されたのかをGitHubにあるリポゞトリのコミットを远っお調査したした。 现かい文蚀や章線成の倉曎コミットなどがあり、倉曎を远うのが倧倉でしたが、 倉曎が提案されたのは 2016/11のissue で、 実際に倉曎されたのは 2017/02のPR でした。 この倉曎は IETF97のスラむド 内の Option D によるものらしいです。 この䞭で setLocalDescription() の匕数は埌方互換性のためずありたすが、結果的には倉曎したSDPを適甚するために未だに䜿われおいたす。 たずめ 本蚘事ではWeb暙準の仕様ず実際のブラりザの挙動に぀いおの䜓隓談を玹介したした。 ブラりザの統䞀された挙動が仕様通りずは限らないずいうこずが䌝わったのではないかず思いたす。 逆に仕様を完党に理解しおも、実際のブラりザの挙動が想定できるずは限らないのは蟛い点だず感じたした。 明日もお楜しみに。 ここではGoogle Chrome/Firefox/Safari/Edgeを指したす。 ↩ ずおもざっくりず説明するずブラりザ間で盎接映像を送るこずができる技術です。 ↩ 利甚するIPアドレスやコヌデックなどメディア送受信に必芁な情報を亀換するために甚いるテキストデヌタです。 ↩ SkyWayではこの蟺りのAPIがわからなくおも利甚できるようなラッパヌになっおいたす。 ↩ SDP Mungingずも呌ばれたす。 ↩
この蚘事は、 NTT Communications Advent Calendar 2023 3日目の蚘事です。 はじめに みなさんこんにちは、むノベヌションセンタヌの益本 (@masaomi346) です。 Network Analytics for Security (以䞋、NA4Sec) プロゞェクトのメンバヌずしお、脅嚁むンテリゞェンス(朜圚的な脅嚁に぀いお収集されたデヌタを収集・分析したもの)の分析業務をしおいたす。 本蚘事では、日本を狙ったフィッシングサむトの情報配信をはじめたこずに぀いお玹介したす。 セキュリティにおける情報配信に぀いお興味がある方、フィッシングに぀いお興味がある方は、ぜひ最埌たで読んでみおください。 NA4Secに぀いお NA4Secは、「NTTはむンタヌネットを安心・安党にする瀟䌚的責務がある」を理念ずしお、むンタヌネットにおける攻撃むンフラの解明・撲滅を目指した掻動をしおいるプロゞェクトです。 たた、NTT Comグルヌプにおける脅嚁むンテリゞェンスチヌムずしおの偎面も持ち合わせおおり、有事においお脅嚁むンテリゞェンスを提䟛し、意思決定を支揎するこずもありたす。 NTTセキュリティ・ゞャパンや゚ヌ・゚フ・ラボラトリヌズからもメンバヌが参画しおおり、いろんな人が協力しお、攻撃むンフラを远跡しおいたす。 本蚘事で玹介する内容は、NA4Secメンバヌが過去に投皿した蚘事ず関連しおいるので、ぜひ読んでみおください。 サむバヌ脅嚁むンテリゞェンスCTI配信はじめたした Metemcyberに぀いお Metemcyberは、食生掻改善のような、セキュリティ運甚の健党化を提䟛するこずを目暙ずしお掻動しおいるプロゞェクトです。 良質な脅嚁むンテリゞェンスをブロックチェヌン䞊で流通させるための、脅嚁むンテリゞェンス流通基盀を開発しおいたす。 プロゞェクトの掻動の詳现に぀いおは、こちらのむンタヌンシップの蚘事でも玹介しおいたす。 むンタヌンシップ䜓隓蚘 〜セキュリティ運甚の健党化を目指すMetemcyberの開発〜 たた、NA4Secず兄匟関係にあるプロゞェクトであり、Xのアカりント (@Metemcyber) でNA4Secず協力しお、脅嚁むンテリゞェンス配信をしおいたす。 フィッシングサむトの情報配信をはじめた経緯 私がNA4Secに加入しおから、フィッシングに関する脅嚁むンテリゞェンスの分析をしおきたした。 フィッシングを行っおいる攻撃者やフィッシングキットの分析などをしおいたしたが、瀟内で閉じずに、倖郚向けに䜕かフィッシングの脅嚁むンテリゞェンスの配信もしおいきたいず考えおいたした。 そこで、こちらのマルりェアの情報配信のずきず同様、Metemcyberアカりントでのフィッシング情報配信をやっおいくこずになりたした。 サむバヌ脅嚁むンテリゞェンスCTI配信はじめたした より倚くの脅嚁情報を配信し぀づけるこずで、倚くの人に掻甚しおもらえるようなり、むンタヌネットの安党に貢献できればずいう思いで始めたした。 投皿の目的・実珟したいこず フィッシングサむトの報告件数は幎々増加しおおり、被害も増加しおいたす。 フィッシングサむトの情報発信をしおいくこずで、サヌビス事業者などでフィッシング察策しおいる担圓者の方々に、掻甚しおもらえるようになるこずを目的ずしおいたす。 そしお、フィッシング詐欺の被害の枛少に少しでも貢献しおいくこずで、NA4Secの理念でもある「NTTはむンタヌネットを安心、安党にする瀟䌚的責務がある」を実珟しおいきたす。 実際に配信しおみる 🚚⚡ #Phishing #フィッシング詐欺 #フィッシング (🇯🇵) Brand: #SMBC #䞉井䜏友 IP: 🌍 192.252.189[.]72 (ASN:AS64050) URL: 🎣 hxxps://www.eovmfheuk9810.com/ 🎣 hxxps://www.igiaplfel5936.com/ 🎣 hxxps://www.mtmckoycfqd190.com/ 🎣 hxxps://www.tkurmciuvdq150.com/ H/T to Team NA4Sec pic.twitter.com/plqwdwZpPk — Metemcyber (@Metemcyber) 2023幎11月20日 配信内容は以䞋のようになっおいたす。 フィッシングのハッシュタグ タヌゲットになっおいるブランド名 IPアドレス URL フィッシングサむトのスクリヌンショット 配信内容(投皿フォヌマット)で工倫したこず 掻甚しおもらいやすくするためには、必芁な情報をぱっず芋でわかりやすくたずめなくおはいけたせん。 どういった情報を蚘茉するかに぀いおは、フィッシングサむトの情報配信をしおいる方々の投皿内容を参考にしたした。 たた、芖認性を䞊げるために絵文字を䜿ったり、スクリヌンショットを添付したりしおいたす。 譊告 → パトランプ(🚚)ず雷(⚡)の絵文字 囜 → 囜旗(🇯🇵)の絵文字 IPアドレス → 地球(🌍)の絵文字 URL → 釣竿(🎣)の絵文字 今埌の取り組みずフィヌドバックに぀いお フィッシングサむトの情報配信で埗られた知芋を䜿っお、新たなむンテリゞェンスを生み出しおいきたいず思いたす。 ただただ情報配信を始めたばかりであるため、改良し぀぀、フィッシングサむトの情報配信を続けおいきたす。 そのためにも、みなさんの意芋を取り入れおいきたいず思っおいたす。 発信内容やフォヌマットに぀いおフィヌドバックしたい方、これ以倖に䜕かお話ししたいこずがある方は、 公匏アカりント (@Metemcyber) もしくは、私のアカりント (@masaomi346) たでご連絡ください。 さいごに 本蚘事では、日本を狙ったフィッシングサむトの情報配信をはじめたこずに぀いお玹介したした。 今埌もさたざたな脅嚁むンテリゞェンスを発信しおいきたす。 公匏アカりント (@Metemcyber) をフォロヌしおいただけるず幞いです。 宣䌝 NA4Sec/Metemcyberチヌムではそれぞれ䞀緒に働く仲間を募集しおいたす。 脅嚁むンテリゞェンスに興味があり、プロゞェクトの理念に共感しおいただける方は、ぜひ応募しおみおください。 NA4Sec (Threat Intelligence Analyst / 脅嚁むンテリゞェンスアナリスト) Metemcyber (Threat Intelligence Engineer / 脅嚁むンテリゞェンス゚ンゞニア) たた、孊生向けのむンタヌンシップでは、以䞋のようなこずを実斜したした。 NA4Sec 攻撃者はいかにしおフィッシングサむトを隠すかむンタヌンシップ䜓隓蚘 むンタヌンシップ䜓隓蚘 〜Cobalt StrikeのC2サヌバ远跡〜 Metemcyber むンタヌンシップ䜓隓蚘 〜セキュリティ運甚の健党化を目指すMetemcyberの開発〜 孊生の方で、NA4Sec/Metemcyberチヌムでのむンタヌンシップに興味を持った方は、次回のむンタヌンシップに参加しおみおください。 最埌たで、ご芧頂きありがずうございたした それでは、明日の蚘事もお楜しみに
この蚘事は、 NTT Communications Advent Calendar 2023 3日目の蚘事です。 はじめに みなさんこんにちは、むノベヌションセンタヌの益本 (@masaomi346) です。 Network Analytics for Security (以䞋、NA4Sec) プロゞェクトのメンバヌずしお、脅嚁むンテリゞェンス(朜圚的な脅嚁に぀いお収集されたデヌタを収集・分析したもの)の分析業務をしおいたす。 本蚘事では、日本を狙ったフィッシングサむトの情報配信をはじめたこずに぀いお玹介したす。 セキュリティにおける情報配信に぀いお興味がある方、フィッシングに぀いお興味がある方は、ぜひ最埌たで読んでみおください。 NA4Secに぀いお NA4Secは、「NTTはむンタヌネットを安心・安党にする瀟䌚的責務がある」を理念ずしお、むンタヌネットにおける攻撃むンフラの解明・撲滅を目指した掻動をしおいるプロゞェクトです。 たた、NTT Comグルヌプにおける脅嚁むンテリゞェンスチヌムずしおの偎面も持ち合わせおおり、有事においお脅嚁むンテリゞェンスを提䟛し、意思決定を支揎するこずもありたす。 NTTセキュリティ・ゞャパンや゚ヌ・゚フ・ラボラトリヌズからもメンバヌが参画しおおり、いろんな人が協力しお、攻撃むンフラを远跡しおいたす。 本蚘事で玹介する内容は、NA4Secメンバヌが過去に投皿した蚘事ず関連しおいるので、ぜひ読んでみおください。 サむバヌ脅嚁むンテリゞェンスCTI配信はじめたした Metemcyberに぀いお Metemcyberは、食生掻改善のような、セキュリティ運甚の健党化を提䟛するこずを目暙ずしお掻動しおいるプロゞェクトです。 良質な脅嚁むンテリゞェンスをブロックチェヌン䞊で流通させるための、脅嚁むンテリゞェンス流通基盀を開発しおいたす。 プロゞェクトの掻動の詳现に぀いおは、こちらのむンタヌンシップの蚘事でも玹介しおいたす。 むンタヌンシップ䜓隓蚘 〜セキュリティ運甚の健党化を目指すMetemcyberの開発〜 たた、NA4Secず兄匟関係にあるプロゞェクトであり、Xのアカりント (@Metemcyber) でNA4Secず協力しお、脅嚁むンテリゞェンス配信をしおいたす。 フィッシングサむトの情報配信をはじめた経緯 私がNA4Secに加入しおから、フィッシングに関する脅嚁むンテリゞェンスの分析をしおきたした。 フィッシングを行っおいる攻撃者やフィッシングキットの分析などをしおいたしたが、瀟内で閉じずに、倖郚向けに䜕かフィッシングの脅嚁むンテリゞェンスの配信もしおいきたいず考えおいたした。 そこで、こちらのマルりェアの情報配信のずきず同様、Metemcyberアカりントでのフィッシング情報配信をやっおいくこずになりたした。 サむバヌ脅嚁むンテリゞェンスCTI配信はじめたした より倚くの脅嚁情報を配信し぀づけるこずで、倚くの人に掻甚しおもらえるようなり、むンタヌネットの安党に貢献できればずいう思いで始めたした。 投皿の目的・実珟したいこず フィッシングサむトの報告件数は幎々増加しおおり、被害も増加しおいたす。 フィッシングサむトの情報発信をしおいくこずで、サヌビス事業者などでフィッシング察策しおいる担圓者の方々に、掻甚しおもらえるようになるこずを目的ずしおいたす。 そしお、フィッシング詐欺の被害の枛少に少しでも貢献しおいくこずで、NA4Secの理念でもある「NTTはむンタヌネットを安心、安党にする瀟䌚的責務がある」を実珟しおいきたす。 実際に配信しおみる 🚚⚡ #Phishing #フィッシング詐欺 #フィッシング (🇯🇵) Brand: #SMBC #䞉井䜏友 IP: 🌍 192.252.189[.]72 (ASN:AS64050) URL: 🎣 hxxps://www.eovmfheuk9810.com/ 🎣 hxxps://www.igiaplfel5936.com/ 🎣 hxxps://www.mtmckoycfqd190.com/ 🎣 hxxps://www.tkurmciuvdq150.com/ H/T to Team NA4Sec pic.twitter.com/plqwdwZpPk — Metemcyber (@Metemcyber) 2023幎11月20日 配信内容は以䞋のようになっおいたす。 フィッシングのハッシュタグ タヌゲットになっおいるブランド名 IPアドレス URL フィッシングサむトのスクリヌンショット 配信内容(投皿フォヌマット)で工倫したこず 掻甚しおもらいやすくするためには、必芁な情報をぱっず芋でわかりやすくたずめなくおはいけたせん。 どういった情報を蚘茉するかに぀いおは、フィッシングサむトの情報配信をしおいる方々の投皿内容を参考にしたした。 たた、芖認性を䞊げるために絵文字を䜿ったり、スクリヌンショットを添付したりしおいたす。 譊告 → パトランプ(🚚)ず雷(⚡)の絵文字 囜 → 囜旗(🇯🇵)の絵文字 IPアドレス → 地球(🌍)の絵文字 URL → 釣竿(🎣)の絵文字 今埌の取り組みずフィヌドバックに぀いお フィッシングサむトの情報配信で埗られた知芋を䜿っお、新たなむンテリゞェンスを生み出しおいきたいず思いたす。 ただただ情報配信を始めたばかりであるため、改良し぀぀、フィッシングサむトの情報配信を続けおいきたす。 そのためにも、みなさんの意芋を取り入れおいきたいず思っおいたす。 発信内容やフォヌマットに぀いおフィヌドバックしたい方、これ以倖に䜕かお話ししたいこずがある方は、 公匏アカりント (@Metemcyber) もしくは、私のアカりント (@masaomi346) たでご連絡ください。 さいごに 本蚘事では、日本を狙ったフィッシングサむトの情報配信をはじめたこずに぀いお玹介したした。 今埌もさたざたな脅嚁むンテリゞェンスを発信しおいきたす。 公匏アカりント (@Metemcyber) をフォロヌしおいただけるず幞いです。 宣䌝 NA4Sec/Metemcyberチヌムではそれぞれ䞀緒に働く仲間を募集しおいたす。 脅嚁むンテリゞェンスに興味があり、プロゞェクトの理念に共感しおいただける方は、ぜひ応募しおみおください。 NA4Sec (Threat Intelligence Analyst / 脅嚁むンテリゞェンスアナリスト) Metemcyber (Threat Intelligence Engineer / 脅嚁むンテリゞェンス゚ンゞニア) たた、孊生向けのむンタヌンシップでは、以䞋のようなこずを実斜したした。 NA4Sec 攻撃者はいかにしおフィッシングサむトを隠すかむンタヌンシップ䜓隓蚘 むンタヌンシップ䜓隓蚘 〜Cobalt StrikeのC2サヌバ远跡〜 Metemcyber むンタヌンシップ䜓隓蚘 〜セキュリティ運甚の健党化を目指すMetemcyberの開発〜 孊生の方で、NA4Sec/Metemcyberチヌムでのむンタヌンシップに興味を持った方は、次回のむンタヌンシップに参加しおみおください。 最埌たで、ご芧頂きありがずうございたした それでは、明日の蚘事もお楜しみに
この蚘事は、  NTT Communications Advent Calendar 2023  2日目の蚘事です。 こんにちは、むノベヌションセンタヌの坪井です。 1日目の蚘事を担圓した平朚ず同じくNetwork Analytics for Securityずいうチヌム通称NA4Secに所属しおいたす。 1日目の蚘事はこちらです。 https://engineers.ntt.com/entry/2023/12/01/102753 engineers.ntt.com NA4Secプロゞェクトに぀いおは、  サむバヌ脅嚁むンテリゞェンスCTI配信はじめたした  を読んでいただくず我々がどんな掻動を行なっおいるかわかるず思いたす。 先日の11/21火にInternet Week 2023の C10 DNS DAY ずいうプログラムの䞭で「ランダムサブドメむン攻撃においお事業者ずしお行なった察策ず解析に぀いお」ずいうタむトルで講挔をさせおいただきたした。 講挔の䞭で、私はDNSハニヌポットを運甚しおランダムサブドメむン攻撃を芳枬した話をさせおいただいたのですが、アドベントカレンダヌ2日目の本蚘事では講挔の䞭で出おきたサブドメむン列挙ツヌルに぀いお、お話ししたす。 はじめに免責事項 ランダムサブドメむン攻撃ずは サブドメむン列挙ずは SubBruteに぀いお サブドメむン列挙ずランダムサブドメむン攻撃 たずめ はじめに免責事項 本蚘事は、あくたでも調査したサブドメむン列挙ツヌルの動きに぀いおご玹介するものであり、利甚を積極的に掚奚するものではありたせん。たた、これらのツヌルを悪意ある目的で䜿甚するこずは犁止されおいたす。 これらのツヌルを䜿甚するこずによっお発生したいかなる損害や問題に぀いお、ツヌル開発者や提䟛者及び本蚘事の執筆者・ブログ管理者は責任を負いたせん。予めご了承ください。 ランダムサブドメむン攻撃ずは たず初めに、ランダムサブドメむン攻撃に぀いお簡単に説明したす。 ランダムサブドメむン攻撃ずはサむバヌ空間におけるDNSを䜿ったDDoS攻撃手法の぀です。 悪意のある攻撃者がランダムな文字列やパタヌンを䜿甚しお、特定のドメむン名に察しお無差別にサブドメむン名を生成し、生成したサブドメむン名を䜿っおキャッシュDNSサヌバに名前解決の問い合わせク゚リをしたす。 キャッシュDNSサヌバでは受けたク゚リのドメむン名に察する情報をすでに保持しおいる堎合は保持しおいる情報を返したすが、保持しおいない堎合はそのドメむン名の暩嚁DNSサヌバにク゚リをしたす 1 。 今回のようなランダムなサブドメむン名の堎合、ほずんどのドメむン名に぀いおはキャッシュDNSサヌバには過去のク゚リ応答情報が存圚しおいないため、攻撃者からのク゚リの郜床、暩嚁DNSサヌバぞク゚リをするこずになりたす。 䞀般的にランダムサブドメむン攻撃は、意図的に倧量のDNSク゚リを発生させお暩嚁DNSサヌバぞ負荷をかけるこずで、各皮リ゜ヌスの逌迫にずもなう関連サヌビスの品質䜎䞋たたはサヌバダりンなどによる関連サヌビスの停止いわゆるDoSを狙いずした攻撃ず考えられおいたす。 サブドメむン列挙ずは 次に、今回のテヌマであるサブドメむン列挙ツヌルが行う、サブドメむン列挙に぀いおお話ししたす。 サブドメむン列挙Subdomain Enumerationずは、特定のドメむンに関しお利甚されおいるサブドメむン 2 を調査し、そのドメむン名をリスト化するプロセスです。 サブドメむン列挙ツヌルは、セキュリティテストやネットワヌクスキャニング、ペネトレヌションテスト、たたはりェブアプリケヌションのセキュリティ評䟡など、さたざたなセキュリティアクティビティで䜿甚されたす。 サブドメむン列挙ツヌルは以䞋のような手法を䜿甚しおサブドメむンを収集したす。 有名なサブドメむン列挙ツヌルに぀いお、いく぀か取り䞊げお比范しおみたした。 サブドメむン列挙ツヌルはどういう仕組みになっおいるか、今回はInternet Weekの講挔の䞭でも名前が出たSubBruteに぀いお䞭身を芋おいきたいず思いたす。 SubBruteに぀いお SubBruteはPythonで曞かれたオヌプン゜ヌスのサブドメむン列挙ツヌルで䞻にブルヌトフォヌスを実行するこずに特化しおいたす。DNS におけるブルヌトフォヌスは䞀般的なサブドメむンの名前や文字列の組み合わせなどのパタヌンをさたざた詊行する手法です。 指定されたドメむンに察しお耇数の䞀般的なサブドメむン名を含むワヌドリストを䜿甚し、DNSク゚リを送信しお有効なサブドメむンを探玢したす。このプロセスにより、目暙のドメむンに玐づく未知のサブドメむンを芋぀けるこずができたす。 TheRook/subbrute: A DNS meta-query spider that enumerates DNS records, and subdomains. (github.com) SubBruteのプログラムを玐解いおみたずころ、䞋蚘の機胜を備えおいるこずがわかりたした。 なお、䞋蚘の機胜名は凊理内容から類掚しお付けた呌び名なので、実際の機胜名ずは関係ありたせん。 タヌゲットドメむン情報取埗機胜 サブドメむン䜜成察象のタヌゲットドメむンの暩嚁DNSサヌバを列挙し、応答性のテストを行い、正垞応答の堎合はDNSク゚リ察象の暩嚁DNSサヌバ䞀芧に远加する。 サブドメむンリスト生成機胜 䞀般的に䜿甚されるサブドメむンwwwなどや予め甚意されたワヌドリストを䜿甚しお存圚する可胜性のあるサブドメむンリストを生成し、DNSク゚リをランダムな順序で行えるようにリストの順序をシャッフルさせる。暩嚁DNSサヌバがDNSク゚リを異垞ずみなすこずを防いだり、぀の暩嚁DNSサヌバに察するDNSク゚リが集䞭するこずを避けるこずが目的ず思われる。 DNSク゚リ実行機胜 サブドメむンリスト生成機胜で生成されたリストを元にDNSク゚リを行う。この機胜はマルチプロセスで実行され、倧量のDNSク゚リを䞊列で実行する。 DNSク゚リ結果解析機胜 DNSク゚リ実行機胜の結果から必芁な情報を取り出し解析・敎圢する。 Aレコヌドの堎合はドメむン名に察応するIPv4アドレスを、AAAAレコヌドの堎合はIPv6アドレスを取り出す。CNAMEレコヌドからは別名ずなるドメむン名を取り出す。 取り出した結果をドメむン名ず察応するIPアドレスで組み合わせた圢に敎圢する。 䟋ずしお example.jp をタヌゲットドメむンずしおSubBruteを実行するず以䞋のような動きになりたす。 $ python subbrute.py example.jp メむン機胜で example.jp をタヌゲットのドメむンずしお蚭定する。 タヌゲットドメむン情報取埗機胜で指定されたタヌゲットドメむン  example.jp  のDNSク゚リに応答する暩嚁DNSサヌバヌのリストを生成する。 サブドメむンリスト生成機胜で、タヌゲットドメむン  example.jp  のすべおの可胜性のあるサブドメむンのリストを䜜成しリスト内をシャッフル。 DNSク゚リ実行機胜で、 example.jp  の各サブドメむンに察するDNSク゚リを䞊列で実行する。 DNSク゚リ結果解析機胜で、DNSク゚リ実行機胜の結果を解析・敎圢する。䟋えば  mail.example.jp www.example.jp  などの  example.jp  のサブドメむン名ず、サブドメむン名に察応するIPアドレスを出力する。 以䞊の流れにより、 example.jp  のサブドメむンず、それらのドメむン名に玐づくIPアドレスなどの情報を取埗できたす。 このようにワンラむナヌのコマンドでサブドメむン列挙ツヌルを実行するだけでサブドメむン列挙行為自䜓はずおも簡単に行うこずができたす。 サブドメむン列挙ずランダムサブドメむン攻撃 さお、今回はSubBruteの動䜜を玐解いおみたした。SubBruteの動䜜の䞭では倧量のサブドメむン候補からなるリストを生成し、DNSク゚リを行っおいたす。 「SubBruteに぀いお」内では説明を省略しおいたすが、SubBruteがDNSク゚リを実行する際は、予め蚭定されおいるキャッシュDNSサヌバを䜿甚したす。 キャッシュDNSサヌバぞク゚リした時に、キャッシュDNSサヌバがク゚リ応答情報を保持しおいないサブドメむンだった堎合、暩嚁DNSサヌバにク゚リを行うこずになりたす。 あれ、これ䜕かに䌌おたせんか そう、冒頭で説明したランダムサブドメむン攻撃の構造に䌌おいるんです。 サブドメむン列挙ツヌルはセキュリティテストやネットワヌクスキャニング、ペネトレヌションテスト、たたはりェブアプリケヌションのセキュリティ評䟡ずいったシチュ゚ヌションでの利甚を想定しお開発されたツヌルですが、その動䜜過皋䞊でDNSク゚リを倧量発生させ、ランダムサブドメむン攻撃に䌌た状況を䜜り出しおしたうこずがあるため、ツヌルの取り扱いには十分泚意するようにしたしょう。 たずめ 今回はInternet Weekで登壇させおいただいた講挔内容からサブドメむン列挙ツヌルに぀いお深掘りしお曞いおみたした。改めお、サブドメむン列挙ずランダムサブドメむン攻撃は玙䞀重ず感じたした。最埌たで、ご芧頂きありがずうございたした。 明日も同じくNetwork Analytics for Securityチヌムに所属する益本の蚘事ですそれでは、明日の蚘事もお楜しみに 厳密にはいきなり目的の暩嚁DNSサヌバにク゚リをする挙動をずるずは限りたせんが、最終的には䜕らかの圢で暩嚁DNSサヌバぞのク゚リに぀ながるので、ここでは簡単のためにこのように衚珟しおいたす。 ↩ あるドメむンの䞭の郚分的な名前空間のこずで、そのドメむンに関連する特定のサヌビスりェブサむトやメヌルなどを提䟛するサヌバを識別するためなどに䜿われる。䟋えば「www」はりェブサヌバを指す名前ずしおよく䜿われる。 ↩