TECH PLAY

アクセシビリティ

むベント

マガゞン

技術ブログ

WebサむトやアプリケヌションのUIをデザむンする際、テキストの色や背景色にどのような「黒」を䜿っおいたすか CSSでずりあえず color: #000000; や color: black; ず指定しおいる゚ンゞニアの方も倚いかもしれたせん。しかし、倚くのサヌビスでは、テキストや背景に「完党な黒#000000」が䜿われおいたせん。黒に近いグレヌが䜿われおいたす。 䞀芋するず些现な違いに思えたすが、実はこの「黒の遞び方」には、人間の芖芚や画面の特性に基づいたロゞックが存圚したす。 今回は、なぜUIデザむンにおいお「真っ黒」を避けるのか、その論理的な理由ず、「良い黒」の䜜り方、そしお䟋倖的な䜿われ方を解説したす。 理由1コントラストが匷すぎるず目が疲れる 玙に印刷された黒い文字を読むのずは異なり、私たちが普段芋おいるPCやスマヌトフォンのディスプレむは「発光䜓」です。 真っ癜な背景#FFFFFFに真っ黒なテキスト#000000を配眮するず、画面の茝床の最倧倀100%の光ず最小倀0%の光が隣り合うこずになりたす。この極端なコントラストは、目に察しお匷い刺激を䞎えたす。 アクセシビリティの芳点から「コントラスト比は高い方が良い」ずされおいたすが、高ければ高いほど良いずいうわけではありたせん。芖芚過敏を持぀ナヌザヌや、乱芖のナヌザヌにずっおも、100%のコントラストは逆に可読性を䞋げおしたうのです。 理由2珟実䞖界に「玔粋な黒」はほずんど存圚しない 色圩心理孊や物理孊の芳点からも、#000000 は特異な色です。 珟実䞖界を芋枡しおみおください。アスファルト、カラスの矜、黒いスマヌトフォンケヌス  私たちが日垞で「黒」ず認識しおいるもののほずんどは、光をわずかに反射しおおり、環境光の圱響を受けおかすかに色味を持っおいたす。光の反射率が完党に0%の「玔粋な黒」は、光吞収玠材のような特殊な状況にしか存圚したせん。 そのため、人間の脳は画面䞊の #000000 を芋たずき、無意識に「䞍自然さ」や「重苊しさ」、あるいは画面に穎が空いおいるような「圧迫感」を感じ取りたす。 UIデザむンが目指すのは、珟実䞖界の物理法則に寄り添った自然な認知です。自然界に存圚しない完党な黒を避けるこずで、UI党䜓から人工的な違和感を取り陀くこずができたす。 理由3ダヌクモヌドで「奥行き」が衚珟できなくなる 近幎暙準ずなった「ダヌクモヌド」の蚭蚈においお、背景を #000000 にするこずはUIに制玄が発生する恐れがありたす。 UIデザむンは、ボタンやカヌドなどの芁玠に「ドロップシャドり圱」を぀けるこずで、芁玠が重なり合っおいる「Z軞奥行き」を衚珟したす。手前にある芁玠ほど圱が倧きく、背景から浮き䞊がっお芋えたす。 しかし、背景色が #000000これ以䞊暗くならない色の堎合、その䞊に芁玠を眮いお圱を぀けおも、背景ず同化しおしたい圱が芋えたせん。結果ずしお、どの芁玠が手前で、どれがクリック可胜なのかずいった階局構造゚レベヌションを芖芚的に䌝えるこずが難しくなりたす。 UIの「黒」の䜜り方 では、実際にコヌディングやデザむンをする際、どのような「黒」を䜿えばよいのでしょうか。 1. 無圩色のダヌクグレヌ 最もシンプルで倱敗がないのは、明床を10パヌセント皋床䞊げたダヌクグレヌです。 2. ブランドカラヌを混ぜた「リッチブラック」 玔粋なグレヌRGBの倀がすべお同じ色ではなく、ブランドのメむンカラヌプラむマリヌカラヌをわずかに混ぜた黒、通称「リッチブラック」を䜿甚する方法です。 䟋えば、䞊蚘の「Jira」のようにプラむマリヌカラヌが「青」のサヌビスなら、黒にも少しだけ青味を足したす。 これにより、画面党䜓の色調が銎染み、統䞀感ず高玚感が生たれたす。 あえお「完党な黒#000000」を利甚するケヌス ここたで「䜿うべきではない」ず解説しおきたしたが、 あえお #000000 を利甚するケヌス も存圚したす。 OLED有機ELディスプレむ機噚でのバッテリヌ節玄 有機ELディスプレむは、黒を衚瀺する際に「そのピクセルの発光を完党にオフにする」ずいう仕組みを持っおいたす。䟋えばスマヌトフォンアプリにお背景色を#000000ずすれば、該圓の端末でバッテリヌ消費を抑えるこずができたす。 ハむコントラストで䞖界芳を䌝える ブランドのコンセプトずしお、意図的に゚ッゞを効かせ、匷烈なコントラストで匷い印象を䞎えたい際に、あえお玔粋な黒ず癜をぶ぀ける堎合がありたす。 アクセシビリティ芁件ハむコントラストモヌド 芖芚障害を持぀ナヌザヌ向けにOSレベルで提䟛される「ハむコントラストモヌド」では、芖認性を最優先するため、#000000 ず #FFFFFF の組み合わせが意図的に䜿甚されたす。 たずめ色の蚭蚈は、たず「ロゞック」 「なぜその『黒』にするのか」を意識するだけで、UIのクオリティは向䞊したす。 目の疲れを防ぐためコントラストの調敎 自然な認知を促すため珟実䞖界ずのリンク 奥行きを衚珟するためダヌクモヌドの蚭蚈 UIデザむンはサヌビスの固有性を衚珟する芁玠もありたすが、前提ずしお人間の特性やデバむスの仕様に基づいた「ロゞック」がありたす。これにより、適切な配色が可胜になりたす。 Photo by Ricardo Avelar , Kyaw Zay Ya , Wander Fleur , Michael Maasen Eva Wilcock , Jordi Vich Navarro , Vivek Doshi , Aaron Burden on Unsplash ご芧いただきありがずうございたす この投皿はお圹に立ちたしたか 圹に立った 圹に立たなかった 0人がこの投皿は圹に立ったず蚀っおいたす。 The post 配色ロゞックなぜ、UIの「黒」は黒ではないのか first appeared on SIOS Tech Lab .
本蚘事は 2026 幎 1 月 12 日 に公開された「 Navigating architectural choices for a lakehouse using Amazon SageMaker 」を翻蚳したものです。 組織がデヌタを掻甚しお意思決定やむノベヌションを掚進する動きは加速しおいたす。ペタバむト芏暡の情報を扱う䞭で、埓来はデヌタレむクずデヌタりェアハりスずいう 2 ぀の異なるパラダむムに分かれおきたした。それぞれ特定のナヌスケヌスに匷みがある䞀方、デヌタ資産間に意図しない障壁を生むこずがありたす。 デヌタレむクは Amazon Simple Storage Service (Amazon S3) などのオブゞェクトストレヌゞ䞊に構築されるこずが倚く、倚様なデヌタ圢匏ずスキヌマ・オン・リヌド機胜をサポヌトする柔軟性を提䟛したす。そのため、 Apache Spark 、 Trino 、 Presto などの様々な凊理フレヌムワヌクが同じデヌタにク゚リできる マルチ゚ンゞンアクセス が可胜になりたす。䞀方、デヌタりェアハりス ( Amazon Redshift など) は、ACID (原子性、䞀貫性、分離性、耐久性) 準拠、パフォヌマンス最適化、簡単なデプロむメントに優れおおり、構造化された耇雑なク゚リに適しおいたす。デヌタ量の増加ず分析ニヌズの耇雑化に䌎い、組織はデヌタレむクずデヌタりェアハりスのサむロを橋枡しし、䞡方のパラダむムの匷みを掻甚しようずしおいたす。レむクハりスアヌキテクチャはデヌタ管理ず分析を統合的に扱うアプロヌチずしお泚目されおいたす。 時間の経過ずずもに、いく぀かの異なるレむクハりスアプロヌチが登堎したした。本蚘事では、ニヌズに合った適切なレむクハりスパタヌンの評䟡ず遞択方法を玹介したす。 デヌタレむク䞭心のレむクハりス アプロヌチは、オブゞェクトストレヌゞ䞊に構築された埓来のデヌタレむクのスケヌラビリティ、コスト効率、柔軟性から始たりたす。目暙は、䞻にオヌプンテヌブルフォヌマット ( Apache Hudi 、 Delta Lake 、 Apache Iceberg ) を通じお、埓来デヌタベヌスにあったトランザクション機胜ずデヌタ管理レむダヌを远加するこずです。オヌプンテヌブルフォヌマットはデヌタレむクの単䞀テヌブル操䜜に ACID 保蚌を導入する点で倧きく進歩したしたが、耇雑な参照敎合性制玄やゞョむンを䌎うマルチテヌブルトランザクションの実装は䟝然ずしお困難です。オブゞェクトストレヌゞ䞊のペタバむト芏暡のファむルに察するク゚リは、分散ク゚リ゚ンゞンを介するこずが倚く、高床に最適化・むンデックス化・マテリアラむズ化されたデヌタりェアハりスず比范するず、高い同時実行性でのむンタラクティブク゚リが遅くなる可胜性がありたす。オヌプンテヌブルフォヌマットはコンパクションずむンデックスを導入しおいたすが、成熟した独自仕様のデヌタりェアハりスに芋られる高床なストレヌゞ最適化機胜は、デヌタレむク䞭心のアヌキテクチャではただ発展途䞊です。 デヌタりェアハりス䞭心のレむクハりス アプロヌチは充実した分析機胜を提䟛したすが、盞互運甚性に倧きな課題がありたす。デヌタりェアハりスは倖郚アクセス甚に JDBC および ODBC ドラむバヌを提䟛しおいたすが、基盀ずなるデヌタは独自仕様の圢匏のたたであり、耇雑な ETL や API レむダヌなしでは倖郚ツヌルやサヌビスが盎接アクセスするこずが困難です。デヌタの重耇ずレむテンシヌに぀ながる可胜性がありたす。デヌタりェアハりスアヌキテクチャはオヌプンテヌブルフォヌマットの読み取りをサポヌトする堎合がありたすが、曞き蟌みやトランザクションレむダヌぞの参加胜力は限定的です。真の盞互運甚性が制限され、意図しないデヌタサむロが生たれる可胜性がありたす。 AWS では、デヌタりェアハりスずデヌタレむクの䞡方ぞの統合アクセスを実珟する モダンでオヌプンなレむクハりスアヌキテクチャ を構築できたす。このアプロヌチにより、デヌタの単䞀の信頌できる゜ヌスを維持しながら、高床な分析、機械孊習 (ML)、生成 AI アプリケヌションを構築できたす。デヌタレむクかデヌタりェアハりスかを遞ぶ必芁はありたせん。既存の投資を掻甚し、䞡方のパラダむムの匷みを維持し぀぀、それぞれの匱点を解消できたす。AWS のレむクハりスアヌキテクチャは、Apache Hudi、Delta Lake、Apache Iceberg などのオヌプンテヌブルフォヌマットを採甚しおいたす。 次䞖代の Amazon SageMaker でレむクハりスの導入を加速できたす。SageMaker はデヌタぞの統合アクセスを備えた分析ず AI の統合゚クスペリ゚ンスを提䟛したす。SageMaker は Apache Iceberg ず完党互換のオヌプンレむクハりスアヌキテクチャ䞊に構築されおいたす。Apache Iceberg REST API のサポヌトを拡匵するこずで、SageMaker は様々な Apache Iceberg 互換ク゚リ゚ンゞンやツヌル間の盞互運甚性ずアクセシビリティを倧幅に向䞊させおいたす。このアヌキテクチャの䞭栞には、 AWS Glue Data Catalog ず AWS Lake Formation 䞊に構築されたメタデヌタ管理レむダヌがあり、統合ガバナンスず䞀元的なアクセス制埡を提䟛したす。 Amazon SageMaker レむクハりスアヌキテクチャの基盀 Amazon SageMaker のレむクハりスアヌキテクチャには、統合デヌタプラットフォヌムを構成する 4 ぀の䞻芁コンポヌネントがありたす。 ワヌクロヌドパタヌンず芁件に適応する柔軟なストレヌゞ すべおのメタデヌタの単䞀の信頌できる゜ヌスずなるテクニカルカタログ すべおのデヌタ資産にわたるきめ现かなアクセス制埡を備えた統合暩限管理 Apache Iceberg REST API 䞊に構築された、ナニバヌサル互換性のためのオヌプンアクセスフレヌムワヌク カタログず暩限 オヌプンレむクハりスを構築する際、メタデヌタの䞭倮リポゞトリであるカタログは、デヌタ怜出ずガバナンスの重芁なコンポヌネントです。Amazon SageMaker のレむクハりスアヌキテクチャには、マネヌゞドカタログずフェデレヌテッドカタログの 2 皮類のカタログがありたす。 マネヌゞドカタログは、レむクハりスがメタデヌタを管理し、デヌタを汎甚 S3 バケットに保存する圢態です。 フェデレヌテッドカタログは、倖郚や既存のデヌタ゜ヌスをマりント・接続し、デヌタを移動せずに Amazon Redshift 、Snowflake、 Amazon DynamoDB などのデヌタ゜ヌスに盎接ク゚リできる圢態です。詳现は「 Data connections in the lakehouse architecture of Amazon SageMaker 」を参照しおください。 AWS Glue クロヌラヌ を䜿甚しお、 Data Catalog にメタデヌタを自動的に怜出・登録できたす。Data Catalog はデヌタ資産のスキヌマずテヌブルメタデヌタを保存し、ファむルを論理テヌブルに倉換したす。デヌタがカタログ化されたら、次の課題はアクセス制埡です。フォルダごずに耇雑な S3 バケットポリシヌを䜿甚するこずもできたすが、管理ずスケヌリングが困難です。 Lake Formation は Data Catalog 䞊にデヌタベヌススタむルの䞀元的な暩限モデルを提䟛し、個々のナヌザヌやロヌルに察しお行、列、セルレベルのきめ现かなアクセスを付䞎たたは取り消す柔軟性を備えおいたす。 Apache Iceberg REST API によるオヌプンアクセス 前述のレむクハりスアヌキテクチャ (以䞋の図の) は、サヌビス゚ンドポむントを通じお AWS Glue Iceberg REST カタログ も䜿甚しおいたす。OSS 互換性を提䟛し、Spark やその他のオヌプン゜ヌス分析゚ンゞン間で Iceberg テヌブルメタデヌタを管理するための盞互運甚性を向䞊させたす。テヌブルフォヌマットずナヌスケヌスの芁件に基づいお適切な API を遞択できたす。 本蚘事では、デヌタレむクずデヌタりェアハりスを最適に掻甚しおスケヌラブルで高パフォヌマンスなデヌタ゜リュヌションを構築する方法に焊点を圓お、様々なレむクハりスアヌキテクチャパタヌンを探りたす。 AWS でレむクハりスにデヌタを取り蟌む レむクハりスアヌキテクチャを構築する際、デヌタのアクセスず統合には 3 ぀の異なるパタヌンから遞択でき、それぞれ異なるナヌスケヌスに固有の利点を提䟛したす。 埓来の ETL は、デヌタを抜出し、倉換しおレむクハりスにロヌドする埓来の方法です。 䜿甚すべきケヌス: 耇雑な倉換が必芁で、パフォヌマンス向䞊のためにダりンストリヌムアプリケヌション向けに高床にキュレヌションされ最適化されたデヌタセットが必芁な堎合 過去デヌタの移行が必芁な堎合 倧芏暡なデヌタ品質の適甚ず暙準化が必芁な堎合 レむクハりスに高床にガバナンスされたキュレヌション枈みデヌタが必芁な堎合 Zero-ETL は、゜ヌスシステムからレむクハりスぞデヌタを最小限の手動介入やカスタムコヌドで自動的か぀継続的にレプリケヌトするモダンなアヌキテクチャパタヌンです。内郚的には、倉曎デヌタキャプチャ (CDC) を䜿甚しお、゜ヌスからタヌゲットぞのすべおの新芏挿入、曎新、削陀を自動的にストリヌミングしたす。このアヌキテクチャパタヌンは、゜ヌスシステムが高いデヌタクリヌンネスず構造を維持しおおり、ロヌド前の重い倉換の必芁性が最小限の堎合、たたはデヌタの粟補ず集玄がレむクハりス内のタヌゲット偎で行える堎合に効果的です。Zero-ETL は最小限の遅延でデヌタをレプリケヌトし、倉換ロゞックはむンサむトが生成される堎所に近いタヌゲット偎で、より効率的なロヌド埌フェヌズずしお実行されたす。 䜿甚すべきケヌス: 運甚の耇雑さを軜枛し、準リアルタむムずバッチの䞡方のナヌスケヌスでデヌタレプリケヌションを柔軟に制埡する必芁がある堎合 カスタマむズが限定的で十分な堎合。Zero-ETL は最小限の䜜業を意味したすが、レプリケヌトされたデヌタに軜い倉換が必芁な堎合もありたす 専門的な ETL の専門知識の必芁性を最小限に抑えたい堎合 凊理遅延なしでデヌタの鮮床を維持し、デヌタの䞍敎合リスクを軜枛する必芁がある堎合。Zero-ETL はむンサむトたでの時間を短瞮したす デヌタフェデレヌション (デヌタ移動なしのアプロヌチ) は、デヌタを単䞀の集䞭堎所に物理的に移動たたはコピヌせずに、耇数の異なる゜ヌスからデヌタをク゚リ・結合できる方法です。この ク゚リむンプレヌス アプロヌチにより、ク゚リ゚ンゞンが倖郚゜ヌスシステムに盎接接続し、ク゚リを委任・実行し、結果をオンザフラむで結合しおナヌザヌに提瀺できたす。このアヌキテクチャパタヌンの効果は、システム間のネットワヌクレむテンシヌ、゜ヌスシステムのパフォヌマンス胜力、ク゚リ゚ンゞンの述語のプッシュダりン胜力の 3 ぀の芁因に䟝存したす。このデヌタ移動なしのアプロヌチにより、゜ヌスデヌタぞのリアルタむムアクセスを提䟛しながら、デヌタの重耇ずストレヌゞコストを倧幅に削枛できたす。 䜿甚すべきケヌス: オペレヌショナル分析のために゜ヌスシステムに盎接ク゚リする必芁がある堎合 レむクハりス内のストレヌゞスペヌスず関連コストを節玄するためにデヌタを耇補したくない堎合 即時のデヌタ可甚性ずラむブデヌタの䞀回限りの分析のために、ク゚リパフォヌマンスずガバナンスの䞀郚をトレヌドオフしおもよい堎合 デヌタを頻繁にク゚リする必芁がない堎合 AWS でのレむクハりスのストレヌゞレむダヌを理解する レむクハりスにデヌタを取り蟌む様々な方法を確認したずころで、次の問題はデヌタの保存先です。以䞋の図のように、AWS ではデヌタレむク (Amazon S3 たたは Amazon S3 Tables ) たたはデヌタりェアハりス ( Redshift Managed Storage ) にデヌタを保存しおモダンなオヌプンレむクハりスを構築でき、ワヌクロヌド芁件に基づいお柔軟性ずパフォヌマンスの䞡方を最適化できたす。 モダンなレむクハりスは単䞀のストレヌゞ技術ではなく、それらの戊略的な組み合わせです。デヌタの保存堎所ず方法は、ダッシュボヌドの応答速床から ML モデルの効率たで幅広く圱響したす。ストレヌゞの初期コストだけでなく、デヌタ取埗の長期コスト、ナヌザヌが求めるレむテンシヌ、単䞀の信頌できる゜ヌスを維持するためのガバナンスも考慮が必芁です。このセクションでは、デヌタレむクずデヌタりェアハりスのアヌキテクチャパタヌンを掘り䞋げ、各ストレヌゞパタヌンをい぀䜿甚すべきかの明確なフレヌムワヌクを提䟛したす。か぀おは競合するアヌキテクチャず芋なされおいたしたが、モダンでオヌプンなレむクハりスアプロヌチは䞡方を掻甚しお単䞀の匷力なデヌタプラットフォヌムを構築したす。 汎甚 S3 Amazon S3 の 汎甚 S3 バケット は、オブゞェクトの保存に䜿甚される暙準的な基本バケットタむプです。厳栌な事前スキヌマなしでネむティブ圢匏のデヌタを保存できる柔軟性を提䟛したす。S3 バケットはストレヌゞずコンピュヌティングを分離できるため、高床にスケヌラブルな堎所にデヌタを保存しながら、様々なク゚リ゚ンゞンが独立しおアクセス・凊理できたす。デヌタの移動や耇補なしに、ゞョブに適したツヌルを遞択できたす。ストレヌゞ容量のプロビゞョニングや管理なしでペタバむト芏暡のデヌタを保存でき、 階局型ストレヌゞクラス により、アクセス頻床の䜎いデヌタをより手頃なストレヌゞに自動的に移動しお倧幅なコスト削枛を実珟したす。 既存の Data Catalog はマネヌゞドカタログずしお機胜したす。AWS アカりント番号で識別されるため、既存の Data Catalog の移行は䞍芁で、レむクハりスですでに利甚可胜であり、以䞋の図のように新しいデヌタのデフォルトカタログになりたす。 汎甚 S3 䞊の基本的なデヌタレむクは、远蚘専甚ワヌクロヌドに非垞に効率的です。ただし、ファむルベヌスの性質䞊、埓来のデヌタベヌスのトランザクション保蚌が欠けおいたす。Apache Hudi、Delta Lake、Apache Iceberg などのオヌプン゜ヌスのトランザクショナルテヌブルフォヌマットを掻甚するず、この課題を解決できたす。テヌブルフォヌマットによりマルチバヌゞョン同時実行制埡MVCCを実装でき、耇数のリヌダヌずラむタヌが競合なく同時に操䜜できたす。スナップショット分離を提䟛するため、曞き蟌み操䜜䞭でもリヌダヌはデヌタの䞀貫したビュヌを参照できたす。以䞋の図は Apache Iceberg を䜿甚した兞型的なメダリオンアヌキテクチャパタヌンを瀺しおいたす。AWS で Apache Iceberg を䜿甚しおレむクハりスを構築する堎合、Amazon S3 䞊のデヌタ保存には、セルフマネヌゞド Iceberg を䜿甚した汎甚 S3 バケットず、フルマネヌゞドの S3 Tables の 2 ぀の䞻芁なアプロヌチから遞択できたす。それぞれに明確な利点があり、制埡、パフォヌマンス、運甚負荷に察する具䜓的なニヌズによっお適切な遞択が異なりたす。 セルフマネヌゞド Iceberg を䜿甚した汎甚 S3 セルフマネヌゞド Iceberg を䜿甚した汎甚 S3 バケットは、デヌタず Iceberg メタデヌタファむルの䞡方を暙準 S3 バケットに保存する埓来のアプロヌチです。このオプションでは完党な制埡を維持したすが、コンパクションやガベヌゞコレクションなどの必須メンテナンスタスクを含む、Iceberg テヌブルのラむフサむクル党䜓を自分で管理する必芁がありたす。 䜿甚すべきケヌス: 最倧限の制埡: デヌタラむフサむクル党䜓を完党に制埡できたす。コンパクションのスケゞュヌルや戊略の定矩など、テヌブルメンテナンスのあらゆる偎面を埮調敎でき、特定の高パフォヌマンスワヌクロヌドやコスト最適化に重芁です。 柔軟性ずカスタマむズ: 匷力な瀟内デヌタ゚ンゞニアリング専門知識を持ち、より幅広いオヌプン゜ヌスツヌルやカスタムスクリプトずの統合が必芁な組織に最適です。 Amazon EMR や Apache Spark を䜿甚しおテヌブル操䜜を管理できたす。 初期コストの䜎さ: Amazon S3 ストレヌゞ、API リク゚スト、メンテナンス甚コンピュヌティングリ゜ヌスの料金のみ発生したす。継続的な自動最適化が䞍芁な小芏暡たたは䜎頻床のワヌクロヌドでは、よりコスト効率が高くなる可胜性がありたす。 泚意: ク゚リパフォヌマンスは最適化戊略に完党に䟝存したす。コンパクションの継続的なスケゞュヌルゞョブがないず、デヌタの断片化に䌎いパフォヌマンスが䜎䞋する可胜性がありたす。効率的なク゚リを確保するために、コンパクションゞョブを監芖する必芁がありたす。 S3 Tables S3 Tables は、分析ワヌクロヌドに最適化された S3 ストレヌゞを提䟛し、倧芏暡な衚圢匏デヌタを保存するための Apache Iceberg 互換性を備えおいたす。S3 テヌブルバケットずテヌブルを Data Catalog ず統合し、Lake Formation コン゜ヌルたたはサヌビス API で Lake Formation デヌタロケヌションずしおカタログを登録できたす (以䞋の図の)。このカタログはフェデレヌテッドレむクハりスカタログずしお登録・マりントされたす。 䜿甚すべきケヌス: 運甚の簡玠化: S3 Tables はコンパクション、スナップショット管理、孀立ファむルのクリヌンアップなどのテヌブルメンテナンスタスクをバックグラりンドで自動的に凊理したす。カスタムメンテナンスゞョブの構築・管理が䞍芁になり、運甚負荷を倧幅に軜枛できたす。 自動最適化: S3 Tables はク゚リパフォヌマンスを向䞊させる組み蟌みの自動最適化を提䟛したす。スモヌルファむル問題に察凊するファむルコンパクションや、衚圢匏デヌタに特化したデヌタレむアりト最適化などのバックグラりンドプロセスが含たれたす。ただし、自動化ず柔軟性はトレヌドオフの関係にありたす。コンパクション操䜜のタむミングや方法を制埡できないため、特定のパフォヌマンス芁件を持぀ワヌクロヌドではク゚リパフォヌマンスにばら぀きが生じる可胜性がありたす。 デヌタ掻甚ぞの集䞭: S3 Tables ぱンゞニアリングの負荷を軜枛し、デヌタの消費、デヌタガバナンス、䟡倀創造に焊点を移したす。 オヌプンテヌブルフォヌマットぞの簡単な導入: Apache Iceberg の抂念は初めおだが、デヌタレむクでトランザクション機胜を掻甚したいチヌムに適しおいたす。 倖郚カタログ䞍芁: 倖郚カタログを管理したくない小芏暡チヌムに適しおいたす。 Redshift Managed Storage デヌタレむクはすべおのデヌタの䞭倮の信頌できる゜ヌスずしお機胜したすが、すべおのゞョブに最適なデヌタストアではありたせん。最も芁求の厳しいビゞネスむンテリゞェンスずレポヌティングワヌクロヌドでは、デヌタレむクのオヌプンで柔軟な性質がパフォヌマンスの予枬䞍可胜性をもたらす可胜性がありたす。望たしいパフォヌマンスを確保するために、以䞋の理由でデヌタレむクからデヌタりェアハりスぞキュレヌション枈みデヌタのサブセットを移行するこずを怜蚎しおください: 高同時実行 BI ずレポヌティング: 数癟のビゞネスナヌザヌがラむブダッシュボヌドで耇雑なク゚リを同時に実行する堎合、デヌタりェアハりスは予枬可胜なサブ秒のク゚リレむテンシヌで高同時実行ワヌクロヌドを凊理するよう特別に最適化されおいたす。 予枬可胜なパフォヌマンス SLA: 財務レポヌトや日次売䞊分析など、保蚌された速床でデヌタを配信する必芁がある重芁なビゞネスプロセスでは、デヌタりェアハりスが䞀貫したパフォヌマンスを提䟛したす。 耇雑な SQL ワヌクロヌド: デヌタレむクは匷力ですが、倚数のゞョむンや倧芏暡な集玄を䌎う非垞に耇雑なク゚リでは苊戊する可胜性がありたす。デヌタりェアハりスは耇雑なリレヌショナルワヌクロヌドを効率的に実行するために構築されおいたす。 AWS のレむクハりスアヌキテクチャは Redshift Managed Storage (RMS) をサポヌトしおいたす。RMS は、Amazon Redshift が提䟛するフルマネヌゞドのストレヌゞオプションです。RMS ストレヌゞは、デヌタりェアハりゞングワヌクロヌド向けの組み蟌みク゚リ最適化、 自動マテリアラむズドビュヌ 、頻繁に実行されるワヌクロヌド向けの AI 駆動の最適化ずスケヌリング など、Amazon Redshift が提䟛する 自動テヌブル最適化 をサポヌトしおいたす。 フェデレヌテッド RMS カタログ: 既存の Amazon Redshift デヌタりェアハりスをレむクハりスにオンボヌド 既存の Amazon Redshift デヌタりェアハりスでフェデレヌテッドカタログを実装するず、デヌタ移動を必芁ずしないメタデヌタのみの統合が䜜成されたす。このアプロヌチにより、既存のワヌクフロヌずの互換性を維持しながら、確立された Amazon Redshift ぞの投資をモダンなオヌプンレむクハりスフレヌムワヌクに拡匵できたす。Amazon Redshift は階局的なデヌタ組織構造を䜿甚しおいたす: クラスタヌレベル : 名前空間から始たる デヌタベヌスレベル : 耇数のデヌタベヌスを含む スキヌマレベル : デヌタベヌス内のテヌブルを敎理する 既存の Amazon Redshift プロビゞョンドたたはサヌバヌレスの名前空間を Data Catalog のフェデレヌテッドカタログずしお登録するず、この階局がレむクハりスのメタデヌタレむダヌに盎接マッピングされたす。AWS のレむクハりス実装は、基盀ずなるストレヌゞメタデヌタを敎理・マッピングする動的階局を䜿甚しお耇数のカタログをサポヌトしおいたす。 名前空間を登録するず、フェデレヌテッドカタログは AWS リヌゞョンずアカりント内のすべおの Amazon Redshift デヌタりェアハりスに自動的にマりントされたす。登録プロセス䞭、Amazon Redshift はデヌタ共有に察応する倖郚デヌタベヌスを内郚的に䜜成したす。゚ンドナヌザヌからはこの仕組みは完党に隠蔜されおいたす。フェデレヌテッドカタログを䜿甚するこずで、デヌタ゚コシステム党䜓にわたる即時の可芖性ずアクセシビリティを実珟できたす。 フェデレヌテッドカタログの暩限 は、同䞀アカりントずクロスアカりントアクセスの䞡方で Lake Formation によっお管理できたす。 フェデレヌテッドカタログが特に効果を発揮するのは、 Amazon Athena 、 Amazon EMR 、オヌプン゜ヌス Spark などの倖郚 AWS ゚ンゞンから Amazon Redshift マネヌゞドストレヌゞにアクセスする堎面です。Amazon Redshift は Amazon Redshift ゚ンゞンのみがネむティブに読み取れる独自仕様のブロックベヌスストレヌゞを䜿甚しおいるため、AWS はバックグラりンドでサヌビスマネヌゞドの Amazon Redshift Serverless むンスタンスを自動的にプロビゞョニングしたす。このサヌビスマネヌゞドむンスタンスは、倖郚゚ンゞンず Amazon Redshift マネヌゞドストレヌゞ間の倉換レむダヌずしお機胜したす。AWS は、登録されたフェデレヌテッドカタログずサヌビスマネヌゞドの Amazon Redshift Serverless むンスタンス間に自動デヌタ共有を確立し、安党で効率的なデヌタアクセスを実珟したす。AWS はデヌタ転送甚のサヌビスマネヌゞド Amazon S3 バケットもバックグラりンドで䜜成したす。 Athena などの倖郚゚ンゞンが Amazon Redshift フェデレヌテッドカタログに察しおク゚リを送信するず、Lake Formation がリク゚ストサヌビスに䞀時的な認蚌情報を提䟛しおクレデンシャルベンディングを凊理したす。ク゚リはサヌビスマネヌゞドの Amazon Redshift Serverless を通じお実行され、自動的に確立されたデヌタ共有を通じおデヌタにアクセスし、結果を凊理しおサヌビスマネヌゞドの Amazon S3 ステヌゞング゚リアにオフロヌドし、元のリク゚スト゚ンゞンに結果を返したす。 既存の Amazon Redshift りェアハりスのフェデレヌテッドカタログのコンピュヌティングコストを远跡するには、以䞋のタグを䜿甚したす。 aws:redshift-serverless:LakehouseManagedWorkgroup value: "True" 請求むンサむトのために AWS 生成コスト配分タグを有効にするには、 有効化手順 に埓っおください。 AWS Billing でリ゜ヌスのコンピュヌティングコストも確認できたす。 䜿甚すべきケヌス: 既存の Amazon Redshift ぞの投資: フェデレヌテッドカタログは、既存の Amazon Redshift デプロむメントを持ち、移行なしで耇数のサヌビス間でデヌタを掻甚したい組織向けに蚭蚈されおいたす。 クロスサヌビスデヌタ共有: チヌムが既存の Amazon Redshift デヌタりェアハりスのデヌタを異なるりェアハりス間で共有し、暩限を䞀元管理できるように実装したす。 ゚ンタヌプラむズ統合芁件: 確立されたデヌタガバナンスずの統合が必芁な組織に適しおいたす。レむクハりス機胜を远加しながら、珟圚のワヌクフロヌずの互換性を維持したす。 むンフラストラクチャの制埡ず料金: 予枬可胜なワヌクロヌドに察しお既存のりェアハりスのコンピュヌティング容量を完党に制埡できたす。コンピュヌティング容量の最適化、オンデマンドずリザヌブドキャパシティの料金の遞択、パフォヌマンスパラメヌタの埮調敎が可胜です。䞀貫したワヌクロヌドに察しおコストの予枬可胜性ずパフォヌマンス制埡を提䟛したす。 耇数のカタログタむプを䜿甚しおレむクハりスアヌキテクチャを実装する堎合、パフォヌマンスずコスト最適化の䞡方にずっお適切なク゚リ゚ンゞンの遞択が重芁です。本蚘事ではレむクハりスのストレヌゞ基盀に焊点を圓おおいたすが、Amazon Redshift デヌタ操䜜を倚甚する重芁なワヌクロヌドでは、可胜な限り Amazon Redshift 内でク゚リを実行するか、Spark を䜿甚するこずを怜蚎しおください。耇数の Amazon Redshift テヌブルにたたがる耇雑なゞョむンを倖郚゚ンゞンで実行するず、゚ンゞンが完党な述語のプッシュダりンをサポヌトしおいない堎合、コンピュヌティングコストが高くなる可胜性がありたす。 その他のナヌスケヌス マルチりェアハりスアヌキテクチャの構築 Amazon Redshift は デヌタ共有 をサポヌトしおおり、゜ヌスずタヌゲットの Amazon Redshift クラスタヌ間でラむブデヌタを共有できたす。デヌタ共有を䜿甚するず、コピヌの䜜成やデヌタの移動なしでラむブデヌタを共有でき、ワヌクロヌド分離 (ハブアンドスポヌクアヌキテクチャ) やクロスグルヌプコラボレヌション (デヌタメッシュアヌキテクチャ) などのナヌスケヌスが可胜になりたす。レむクハりスアヌキテクチャがない堎合、゜ヌスずタヌゲットの Amazon Redshift クラスタヌ間に明瀺的なデヌタ共有を䜜成する必芁がありたす。小芏暡なデプロむメントではデヌタ共有の管理は比范的簡単ですが、デヌタメッシュアヌキテクチャでは耇雑になりたす。 レむクハりスアヌキテクチャはこの課題に察応し、既存の Amazon Redshift りェアハりスをフェデレヌテッドカタログずしお公開できたす。フェデレヌテッドカタログは、同䞀アカりントずリヌゞョン内の他のコンシュヌマヌ Amazon Redshift りェアハりスに倖郚デヌタベヌスずしお自動的にマりントされ、利甚可胜になりたす。デヌタの単䞀コピヌを維持しながら耇数のデヌタりェアハりスからク゚リでき、耇数のデヌタ共有の䜜成ず管理が䞍芁になり、ワヌクロヌド分離でスケヌルできたす。暩限管理は Lake Formation を通じお䞀元化され、マルチりェアハりス環境党䜓のガバナンスが効率化されたす。 パむプラむン管理䞍芁のペタバむト芏暡トランザクションデヌタの準リアルタむム分析: Zero-ETL 統合は、OLTP デヌタ゜ヌスから Amazon Redshift、汎甚 S3 (セルフマネヌゞド Iceberg)、たたは S3 Tables ぞトランザクションデヌタをシヌムレスにレプリケヌトしたす。ETL パむプラむンの維持が䞍芁になり、デヌタアヌキテクチャの可動郚品ず朜圚的な障害ポむントが削枛されたす。ビゞネスナヌザヌは、前回の ETL 実行からの叀いデヌタではなく、新鮮な運甚デヌタをすぐに分析できたす。 Amazon Redshift りェアハりスにレプリケヌトできる OLTP デヌタ゜ヌスの䞀芧は「 Aurora zero-ETL integrations 」を参照しおください。 既存の Amazon Redshift りェアハりス、セルフマネヌゞド Iceberg を䜿甚した汎甚 S3、S3 Tables にレプリケヌトできるその他のサポヌトされるデヌタ゜ヌスに぀いおは「 Zero-ETL integrations 」を参照しおください。 たずめ レむクハりスアヌキテクチャは、デヌタレむクずデヌタりェアハりスのどちらかを遞ぶものではありたせん。䞡方のフレヌムワヌクが統合デヌタアヌキテクチャ内で共存し、異なる目的を果たす盞互運甚性のアプロヌチです。基本的なストレヌゞパタヌンを理解し、効果的なカタログ戊略を実装し、ネむティブストレヌゞ機胜を掻甚するこずで、珟圚の分析ニヌズず将来のむノベヌションの䞡方をサポヌトする、スケヌラブルで高パフォヌマンスなデヌタアヌキテクチャを構築できたす。詳现は「 The lakehouse architecture of Amazon SageMaker 」を参照しおください。 著者に぀いお Lakshmi Nair Lakshmi は、AWS のシニアアナリティクススペシャリスト゜リュヌションアヌキテクトです。業界暪断で高床な分析システムの蚭蚈を専門ずしおいたす。クラりドベヌスのデヌタプラットフォヌムの構築、リアルタむムストリヌミング、ビッグデヌタ凊理、堅牢なデヌタガバナンスの実珟に泚力しおいたす。 Saman Irfan Saman は、ドむツのベルリンを拠点ずする Amazon Web Services のシニアスペシャリスト゜リュヌションアヌキテクトです。組織のデヌタアヌキテクチャのモダナむれヌションずデヌタの朜圚胜力を最倧限に匕き出し、むノベヌションずビゞネス倉革を掚進するこずに情熱を泚いでいたす。 この蚘事は Kiro が翻蚳を担圓し、Solutions Architect の Woosuk Choi がレビュヌしたした。
芖芚蚀語モデル 【連茉】自然蚀語凊理の研究動向 第9回 2026.3.25 株匏䌚瀟Laboro.AI リヌドMLリサヌチャヌ 趙 心怡 抂 芁 芖芚蚀語モデルVLMの登堎は、画像情報をベヌスずした蚀語生成を可胜にし、芖芚理解のあり方を劇的な倉化ぞず導きたした。か぀おは画像ずテキストを察応付ける研究が䞭心でしたが、珟圚のモデルはれロショット孊習や自由床の高いマルチモヌダル生成を実珟するたでに至っおいたす。本皿では、VLMのこれたでの進化を3段階に敎理した䞊で、次なる「第4の波」ずしお期埅される芖芚知胜の展望に぀いお考察したす。 連茉第1回「自然蚀語凊理の研究動向 党40トピックの俯瞰」は こちら 。 連茉第8回「議論マむニング」は こちら 。 目 次 ・ 芖芚蚀語モデルVLMずは ・ 䞻芁な技術的進歩 ・ 今埌の展望ず課題 芖芚蚀語モデルVLMずは これたで、自然蚀語凊理NLPずコンピュヌタビゞョンCVは、互いに独立した専門分野ずしお発展しおきたした。NLPが契玄曞やメヌルずいったテキスト解析を担う䞀方で、CVは監芖カメラの映像解析や補造ラむンの品質管理など、䞻に芖芚情報の凊理に特化しおきた経緯がありたす。しかし、今日の技術革新はその境界線を曖昧にし぀぀ありたす。 深局孊習ずモデルアヌキテクチャの急速な進展により、䞡者を統合した「芖芚蚀語モデルVLM」が登堎したした。埓来のモデルずは䞀線を画し、VLMは芖芚情報ずテキスト入力を同䞀の系で凊理するこずで、察象を芋お読み、掚論した結果をテキストずしお出力したす。VLMの根幹はNLPの原理にありたすが、その構造は埓来のアヌキテクチャから倧きく倉化したした。耇数のプログラムを組み合わせた脆匱なシステムから、倧芏暡デヌタを通じお画像やテキストを䞀぀の頭脳で理解する、よりシンプルで高床な仕組みぞず移行しおいたす。 このパラダむムシフトは、ビゞネスにおけるAIの可胜性を倧きく広げたす。埓来のCVツヌルは、特定の物䜓を怜知し枠で囲むずいった限定的なタスクに留たっおいたした。察照的に、珟代のVLMは「アクティブ・アナリスト」ずしおの圹割を果たしたす。画像のキャプション生成や耇雑なコンテキストぞの回答、さらにはチャヌトからのトレンド分析など、芖芚的な事象に基づいた高床な蚀語的掞察の提䟛が可胜になったのです。 䞻芁な技術的進歩 第1の波画像読解型 / 「構成芁玠の解析」の時代 (2019–2020) ViLBERT (2019) 、 LXMERT (2019) 、 VisualBERT (2019) などに代衚される第1の波は、テキストを読むために䜿甚されるTransformerアヌキテクチャが、画像も「読む」こずができるこずを蚌明したした。この時代のモデルは画像を文章のように扱い、写真をオブゞェクト領域䟋「車」「朚」「犬」のシヌケンスに分解。これらのビゞョントヌクンをテキストず共に凊理するこずで、䞡瀟の関連性を孊習したした。 このアプロヌチによっお、「車の色は䜕色か」ずいった芖芚的な問いに察し、甚意された遞択肢から回答する胜力が実珟したした。しかし、そこにはいく぀かの限界も存圚したした。第䞀に、芖芚領域の特定を倖郚の物䜓怜出噚に䟝存しおいたこず。第二に、孊習には厳密にラベル付けされた膚倧なデヌタセットを必芁ずしたこず。そしお第䞉に、これらのモデルは識別的discriminativeであり、人間のように自由な圢匏で回答を生成するのではなく、あらかじめ定矩されたリストから正解を分類するこずしかできなかったのです。 第2の波抂念統合型 / 「ベクトル察応」の時代 (2021–2022) OpenAIの CLIP (2021) やGoogleの ALIGN (2021) が䞻導した第2の波は、モデルのスケヌラビリティず汎甚性ぞの転換点ずなりたした。これらのモデルは、倖郚の物䜓怜出噚ぞの䟝存を排陀し、汎甚゚ンコヌダを䜿甚しお画像をホリスティック党䜓論的に凊理したす。目的は文法を深く解析するこずではなく、画像のベクトル䟋犬の写真が、テキスト蚘述のベクトル䟋「これは犬です」ず自然に䞀臎するような共通の埋め蟌み空間を孊習するこずにありたした。 これを実珟するために、研究者は厳密にラベル付けされたデヌタセットから離れ、むンタヌネットから収集された数億組のノむズを含む「画像ずテキストのペア」で孊習を行いたした。この倧芏暡なスケヌルが、驚くべき新胜力であるれロショット孊習を可胜にしたした。特定のカテゎリで孊習するこずなく、画像のベクトルが「これはカモノハシです」ずいうテキスト埋め蟌みず䞀臎するかを確認するだけで、モデルは「カモノハシ」のような党く新しい抂念を認識できるようになったのです。これにより、厳遞された孊習デヌタやタスク固有の埮調敎を必芁ずしない、拡匵可胜な画像怜玢および分類システムぞの道が開かれたした。 第3の波生成・察話型 / 「マルチモヌダル掚論」の時代 (2023–珟圚) 珟圚進行䞭の第3の波は、 BLIP-2 (2023) 、 LLaVA (2023) 、 GPT-4V (2023) に䟋瀺される「生成的な統合」を象城しおいたす。モデルをれロから構築するのではなく、研究者は高性胜な「芖芚の目」第2の波の成果を「蚀語の脳」倧芏暡蚀語モデルLLMず盎接融合させる方法を芋出したした。 この融合により、モデルの胜力は単なる画像照合の域を遥かに超えるものずなりたした。「蚀語の脳」を獲埗したこずで、屋倖環境での光孊文字認識OCR、耇雑なデヌタチャヌトの解釈、芖芚コンテンツに関する機埮に觊れた察話、さらにはミヌムむンタヌネット䞊のネタ画像のナヌモアの解説たでもが可胜になったのです。この倉革は、AIの圹割を受動的なタグ付けから胜動的な分析ぞずシフトさせたした。芖芚情報を単に芋るだけでなく、深く理解し、具䜓的なアクションに繋げる必芁がある゚ンタヌプラむズ・むンテリゞェンスや補品怜玢、アクセシビリティ、コンテンツ・モデレヌションずいった広範な分野においお、すでに倚倧な圱響を及がしおいたす。 今埌の展望ず課題 これたでに述べた3぀の朮流は、VLMが向かうべき「第4の波」の茪郭を浮き圫りにしおいたす。最新のトレンドに基づき、私たちは今埌の有望な方向性ずしお以䞋の芁玠を特定したした。 1.蚘憶ず掚論の導入 テキストLLMの進化を远随するように、芖芚モデルも「蚘憶」ず「掚論」の実装ぞず舵を切っおいたす。これには、 CoMemo (2025) に芋られるマルチモヌダル長期蚘憶の開発や、 Visual-CoT (2024) や LlamaV-o1 (2025) に代衚される、回答前にモデルが内省を行う思考の連鎖Chain-of-Thought機胜の高床化が含たれたす。 2.ビデオ理解ず掚論 動画の䞭の文脈を読み解くうえで、凊理の重さや時系列的な理解の限界は䟝然ずしお倧きな課題ですが、近幎では VideoLLM-online (2024) や StreamingVLM (2025) ずいった、このギャップを埋めるための革新的な詊みが続いおいたす。 3.統合TransformerUnified Transformers   CM3Leon (2023) 、 Mogao (2025) 、 ShapeLLM-Omni (2025) ずいった新䞖代のモデルは、ネむティブなむンタヌリヌブ生成テキストず非蚀語情報の混圚生成をサポヌトし始めおいたす。単䞀のモデルがテキスト、画像、さらには3Dコンテンツをシヌムレスに読み曞き・線集できるこの技術は、真のオムニモヌダル知胜ぞの道を開くものです。 しかし、胜力の拡倧に䌎い、安党性におけるリスクも増倧しおいたす。こうした脆匱性の倚くは、システムの認知的なバックボヌンであるテキストLLMから盎接匕き継がれたものです。䟋えば、根匷い課題であるハルシネヌション幻芚の圱響は、 Yang et al. (2025) や Min et al. (2025) の最近の研究が瀺すように、珟圚は芖芚ドメむンにも及んでいたす。 これら既存のリスクに加え、VLM特有のマルチモヌダル蚭蚈が新たな課題を浮き圫りにしおいたす。 Liu et al. (2025) は、芖芚入力を远加するだけでモデルの安党性指瀺ぞの準拠アラむメントが匱たり、䞍安党な回答を生成する可胜性が高たるこずを指摘したした。 結論ずしお、これらのリスクを特定するこず自䜓が、第4の波を乗りこなすためのロヌドマップずなりたす。慎重な蚭蚈ず暙的を絞ったセヌフガヌドを講じるこずで、次䞖代のVLMはより有胜になるだけでなく、より信頌できるものになるず期埅されおいたす。 執筆者 ゚ンゞニアリング郚 リヌドMLリサヌチャヌ 趙 心怡 自然蚀語凊理、機械孊習、ナレッゞグラフを䞭心ずした研究に埓事。これたで耇数のオヌプン゜ヌスのデヌタセットずモデルの構築に貢献しおきた。最近の研究ではLLMの実瀟䌚ぞの応甚を探求し、孊術研究ず実際のナヌスケヌスの橋枡しに情熱を泚いでいる。 The post 芖芚蚀語モデル 【連茉】自然蚀語凊理の研究動向 第9回 first appeared on 株匏䌚瀟Laboro.AI .

動画

曞籍

おすすめマガゞン

蚘事の写真

クルマの䟡倀を匕き出す「芋えない土台」 ──NTTデヌタMSEの車茉プラットフォヌム開発

蚘事の写真

【北九州垂】デゞタルで"皌げるたち"をどうアップデヌトする―産孊トップランナヌず語る【KITAKYUSHU Tech...

蚘事の写真

【#TUC Growth Summit 2025】孊び続ける者だけが、未来を倉える。 ——その䞀歩が、あなたの人生を動か...

蚘事の写真

【ブラザヌ工業】AWSサヌバヌレスで䞖界䞭のデバむスず぀なぐ──AWSアカりント管理ず、フルサヌバヌレスIoTプラットフ...

蚘事の写真

運転空間をたるごず蚭蚈する──Hondaが描く未来の運転空間ず「スマヌトキャビン」構想ずは

新着動画

蚘事の写真

【ゞュニアは育おるべきか】AI時代の若手育成の本質「シニアはい぀か死に絶える」 / ロゞカルシンキングず非認知スキル /...

蚘事の写真

【砎壊防止】意図しないリ゜ヌス削陀を防ぐTerraform䞀行コヌド株匏䌚瀟ディヌカレットDCPThe OneLi...

蚘事の写真

【AIは60点しか出せない】基瀎力がないず芋抜けない / ゞュニア゚ンゞニア䞍芁論の栞心 / ミノ駆動氏『良いコヌド/...