<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>個人ウェブサイト</title><link>https://yuchao-wang.netlify.app/ja/</link><atom:link href="https://yuchao-wang.netlify.app/ja/index.xml" rel="self" type="application/rss+xml"/><description>個人ウェブサイト</description><generator>HugoBlox Kit (https://hugoblox.com)</generator><language>ja-JP</language><lastBuildDate>Mon, 03 Mar 2025 00:00:00 +0000</lastBuildDate><image><url>https://yuchao-wang.netlify.app/media/logo_hu_3214bcd0aed3837d.png</url><title>個人ウェブサイト</title><link>https://yuchao-wang.netlify.app/ja/</link></image><item><title>PACGA ミク ポスター</title><link>https://yuchao-wang.netlify.app/ja/project/pacga-miku-poster/</link><pubDate>Tue, 01 Apr 2025 00:00:00 +0000</pubDate><guid>https://yuchao-wang.netlify.app/ja/project/pacga-miku-poster/</guid><description>&lt;p&gt;これは2025年4月1日に印刷および配布された、パデュー大学アニメ・コミック・ゲーム協会（PACGA）のポスターデザインに関するドキュメントです。&lt;/p&gt;
&lt;h2 id="中心キャラクター初音ミク"&gt;中心キャラクター：初音ミク&lt;/h2&gt;
&lt;p&gt;このポスターは、クリプトン・フューチャー・メディアのVocaloidソフトウェアから誕生した、世界的に有名なバーチャルシンガーである初音ミクを中心に据えています。アニメや「オタク」文化の礎として、彼女は創造性、テクノロジー、そしてコミュニティを象徴しており、これらの価値観はPACGAの理念と深く共鳴しています。彼女の象徴的な地位と幅広い認知度は、この学生主体のエンターテインメント協会におけるふさわしいアンバサダーとして機能しています。&lt;/p&gt;
&lt;h2 id="ターゲット層"&gt;ターゲット層&lt;/h2&gt;
&lt;p&gt;このポスターのターゲット層は、パデュー大学に在籍する中国語圏の人々です。&lt;/p&gt;
&lt;h2 id="デザインコンセプトと文化的インスピレーション"&gt;デザインコンセプトと文化的インスピレーション&lt;/h2&gt;
&lt;p&gt;初音ミクは、仏教の図像やユーモアのあるミーム「初音菩薩」にインスピレーションを得た、足を組んで瞑想するポーズで描かれています。このコンセプトは、「初音」と「観音」（仏教の慈悲の女神）の両方に「音」の文字が含まれているという言葉遊びに由来しています。さらにこのテーマに結びつく要素として、「パデュー大学」の中国語表記「普渡大学（Pǔdù Dàxué）」の音の響きが、仏教の概念である「普渡衆生（あまねく衆生を救済する）」を連想させます。パデュー大学の中国語圏のコミュニティで親しまれているこれらの文化的な参照は、繁体字中国語の使用に表れているように、ポスターのターゲット層に完璧に合致しており、テーマの深みとユーモアを強調しています。&lt;/p&gt;
&lt;h2 id="デザインプロセスと技術的ワークフロー"&gt;デザインプロセスと技術的ワークフロー&lt;/h2&gt;
&lt;p&gt;制作プロセスには約1週間を要し、高度なAIツールを活用して複数の段階を経て構築されました。画像生成においては、ComfyUIフレームワーク内でStable Diffusion XL (SDXL)を利用し、ControlNetのOpenPoseを用いて初音ミクの瞑想ポーズを正確に制御しています。&lt;/p&gt;
&lt;p&gt;ポストプロセッシングとして、初期出力画像をPaint.NETで微調整した後、img2imgワークフローを通じて強化およびアップスケールを行い、複雑なディテールを追加しました。&lt;/p&gt;
&lt;p&gt;モデルの選択に関して、2025年4月時点ではStable Diffusion 3.5 LargeやFLUX devといった新しいモデルも利用可能でしたが、コミュニティにおいてComfyUIやWebUIの強力なプラグインエコシステムを持つSDXLおよびSD1.5を採用しました。これらは制御性に優れ、アニメ調の生成において非常に優れた性能を発揮するため、本プロジェクトの美学に最適でした。&lt;/p&gt;
&lt;h2 id="最終的な構成とタイポグラフィ"&gt;最終的な構成とタイポグラフィ&lt;/h2&gt;
&lt;p&gt;ポスターの仕上げはPhotoshopで行われ、主要なデザイン要素を統合して完成度を高めました。フォントには、レトロで遊び心のあるピクセルフォント「JFドット東雲明朝12」を選択しています。これはPACGAのカジュアルで学生主体の精神を反映し、ピクセルアートのテーマを補完するものです。右側にはMorganiteフォントによるグラデーションテキストを配置し、視線をQRコードと行動喚起（コールトゥアクション）へと誘導しています。&lt;/p&gt;
&lt;p&gt;レイアウトとしては、ダークブルーからパープルへのグラデーション背景に繊細なピクセル処理を施して初音ミクを引き立てつつ、繁体字中国語の追加テキストによってコミュニティへの参加を促す構成となっています。&lt;/p&gt;
&lt;h2 id="制作の軌跡とaiの影響"&gt;制作の軌跡とAIの影響&lt;/h2&gt;
&lt;p&gt;約1週間にわたるこのプロジェクトでは、キャラクターのポーズやレイアウトについて広範な概念化が行われました。特にStable DiffusionなどのAIワークフローの導入は、制作プロセスに変革をもたらすものでした。瞑想するポーズの初音ミクの画像を用意することは、AIなしではほぼ不可能であり、高額な依頼費用や膨大な検索時間を必要としたはずです。この技術は制作プロセスを民主化し、個人的な創作を可能にするとともに、時間と労力を大幅に節約しました。この経験は、デザインに革命をもたらすAIの可能性を浮き彫りにし、その将来の応用に対する期待を高めるものです。&lt;/p&gt;
&lt;p&gt;このポスターは、文化的な機知、技術的な革新、そしてコミュニティの精神を融合させたものです。PACGAの重要なターゲット層と使命に合わせた、視覚的に魅力的で意義深いデザインを提供しています。&lt;/p&gt;</description></item><item><title>離散GPUデータベース</title><link>https://yuchao-wang.netlify.app/ja/project/gpu-db/</link><pubDate>Fri, 28 Mar 2025 00:00:00 +0000</pubDate><guid>https://yuchao-wang.netlify.app/ja/project/gpu-db/</guid><description>&lt;style&gt;
.scrollable-table {
max-width: 100%;
max-height: 80vh;
overflow: auto;
border-radius: 8px;
box-shadow: 0 4px 12px rgba(0,0,0,0.1);
margin: 2rem 0;
position: relative;
--tbl-bg: #ffffff;
--tbl-bg-alt: #f2f3f5;
--tbl-hover: #e4e6e9;
--tbl-hover-active: #d5d8dc;
--tbl-border: #e1e3e6;
}
body.dark .scrollable-table,
html.dark .scrollable-table,
html[data-theme="dark"] .scrollable-table {
--tbl-bg: #161616;
--tbl-bg-alt: #202020;
--tbl-hover: #2c2c2c;
--tbl-hover-active: #383838;
--tbl-border: #333333;
}
.scrollable-table table.sortable {
border-collapse: separate;
border-spacing: 0;
width: max-content;
margin: 0;
}
.scrollable-table th,
.scrollable-table td {
padding: 10px 16px;
font-size: 0.85rem;
white-space: nowrap;
font-variant-numeric: tabular-nums;
border-bottom: 1px solid var(--tbl-border);
transition: background-color 0.1s ease;
}
.scrollable-table tbody tr:nth-child(odd) td,
.scrollable-table tbody tr:nth-child(odd) th {
background-color: var(--tbl-bg);
}
.scrollable-table tbody tr:nth-child(even) td,
.scrollable-table tbody tr:nth-child(even) th {
background-color: var(--tbl-bg-alt);
}
.scrollable-table thead th {
position: sticky;
top: 0;
z-index: 2;
background-color: var(--tbl-bg) !important;
font-weight: 600;
box-shadow: 0 2px 4px rgba(0,0,0,0.05);
}
.scrollable-table th:first-child,
.scrollable-table td:first-child {
position: sticky;
left: 0;
z-index: 1;
border-right: 1px solid var(--tbl-border);
font-weight: 500;
}
.scrollable-table thead th:first-child {
z-index: 3;
background-color: var(--tbl-bg) !important;
}
.scrollable-table tbody tr:hover td,
.scrollable-table tbody tr:hover th {
background-color: var(--tbl-hover) !important;
}
.scrollable-table tbody tr:hover td:hover,
.scrollable-table tbody tr:hover th:hover {
background-color: var(--tbl-hover-active) !important;
}
.scrollable-table tr.brand-nv td:first-child { border-left: 4px solid #76b900; }
.scrollable-table tr.brand-amd td:first-child { border-left: 4px solid #ed1c24; }
.scrollable-table tr.brand-intel td:first-child { border-left: 4px solid #0071c5; }
.scrollable-table::-webkit-scrollbar {
width: 8px;
height: 8px;
}
.scrollable-table::-webkit-scrollbar-track {
background: transparent;
}
.scrollable-table::-webkit-scrollbar-thumb {
background: rgba(125, 125, 125, 0.3);
border-radius: 4px;
}
.scrollable-table::-webkit-scrollbar-thumb:hover {
background: rgba(125, 125, 125, 0.5);
}
&lt;/style&gt;
&lt;div class="scrollable-table"&gt;
&lt;table class="sortable"&gt;
&lt;thead&gt;
&lt;tr&gt;
&lt;th&gt;GPU 製品名&lt;/th&gt;
&lt;th&gt;ブランド&lt;/th&gt;
&lt;th&gt;発売日時&lt;/th&gt;
&lt;th&gt;発売価格&lt;/th&gt;
&lt;th&gt;アーキテクチャ&lt;/th&gt;
&lt;th&gt;ファウンドリ&lt;/th&gt;
&lt;th&gt;プロセスノード&lt;/th&gt;
&lt;th&gt;ダイ名&lt;/th&gt;
&lt;th&gt;ダイバリアント&lt;/th&gt;
&lt;th&gt;バスインターフェース&lt;/th&gt;
&lt;th&gt;シェーディングユニット&lt;/th&gt;
&lt;th&gt;TMU&lt;/th&gt;
&lt;th&gt;ROP&lt;/th&gt;
&lt;th&gt;ロジッククラスター&lt;/th&gt;
&lt;th&gt;テンソルコア&lt;/th&gt;
&lt;th&gt;RTコア&lt;/th&gt;
&lt;th&gt;L0キャッシュ&lt;/th&gt;
&lt;th&gt;L1キャッシュ&lt;/th&gt;
&lt;th&gt;L2キャッシュ&lt;/th&gt;
&lt;th&gt;L3キャッシュ&lt;/th&gt;
&lt;th&gt;メモリ容量&lt;/th&gt;
&lt;th&gt;メモリタイプ&lt;/th&gt;
&lt;th&gt;メモリバス&lt;/th&gt;
&lt;th&gt;バンド幅&lt;/th&gt;
&lt;th&gt;ベースクロック&lt;/th&gt;
&lt;th&gt;ブーストクロック&lt;/th&gt;
&lt;th&gt;メモリクロック&lt;/th&gt;
&lt;th&gt;実効メモリ速度&lt;/th&gt;
&lt;th&gt;TDP&lt;/th&gt;
&lt;th&gt;FP16 (GFLOPS)&lt;/th&gt;
&lt;th&gt;FP32 (GFLOPS)&lt;/th&gt;
&lt;th&gt;FP64 (GFLOPS)&lt;/th&gt;
&lt;th&gt;ピクセルレート&lt;/th&gt;
&lt;th&gt;テクスチャレート&lt;/th&gt;
&lt;th&gt;DirectX&lt;/th&gt;
&lt;th&gt;OpenGL&lt;/th&gt;
&lt;th&gt;OpenCL&lt;/th&gt;
&lt;th&gt;Vulkan&lt;/th&gt;
&lt;th&gt;CUDA計算能力&lt;/th&gt;
&lt;th&gt;シェーダーモデル&lt;/th&gt;
&lt;/tr&gt;
&lt;/thead&gt;
&lt;tbody&gt;
&lt;tr&gt;
&lt;td&gt;GeForce 8800 Ultra&lt;/td&gt;
&lt;td&gt;NVIDIA&lt;/td&gt;
&lt;td&gt;2007-05-02&lt;/td&gt;
&lt;td&gt;829 USD&lt;/td&gt;
&lt;td&gt;Tesla&lt;/td&gt;
&lt;td&gt;TSMC&lt;/td&gt;
&lt;td&gt;90 nm&lt;/td&gt;
&lt;td&gt;G80&lt;/td&gt;
&lt;td&gt;G80-450-A3&lt;/td&gt;
&lt;td&gt;PCIe 1.0 x16&lt;/td&gt;
&lt;td&gt;128&lt;/td&gt;
&lt;td&gt;32&lt;/td&gt;
&lt;td&gt;24&lt;/td&gt;
&lt;td&gt;16 SMs&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;96 KB&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;768 MB&lt;/td&gt;
&lt;td&gt;GDDR3&lt;/td&gt;
&lt;td&gt;384 bit&lt;/td&gt;
&lt;td&gt;103.7 GB/s&lt;/td&gt;
&lt;td&gt;612 MHz&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;1080 MHz&lt;/td&gt;
&lt;td&gt;2.2 Gbps&lt;/td&gt;
&lt;td&gt;171 W&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;387.1&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;14.69 GPixel/s&lt;/td&gt;
&lt;td&gt;39.17 GTexel/s&lt;/td&gt;
&lt;td&gt;11.1 (10_0)&lt;/td&gt;
&lt;td&gt;3.3&lt;/td&gt;
&lt;td&gt;1.1 (1.0)&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;1.0&lt;/td&gt;
&lt;td&gt;4.0&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Quadro FX 5600&lt;/td&gt;
&lt;td&gt;NVIDIA&lt;/td&gt;
&lt;td&gt;2007-03-05&lt;/td&gt;
&lt;td&gt;2,999 USD&lt;/td&gt;
&lt;td&gt;Tesla&lt;/td&gt;
&lt;td&gt;TSMC&lt;/td&gt;
&lt;td&gt;90 nm&lt;/td&gt;
&lt;td&gt;G80&lt;/td&gt;
&lt;td&gt;G80-875-A2&lt;/td&gt;
&lt;td&gt;PCIe 1.0 x16&lt;/td&gt;
&lt;td&gt;128&lt;/td&gt;
&lt;td&gt;32&lt;/td&gt;
&lt;td&gt;24&lt;/td&gt;
&lt;td&gt;16 SMs&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;96 KB&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;1536 MB&lt;/td&gt;
&lt;td&gt;GDDR3&lt;/td&gt;
&lt;td&gt;384 bit&lt;/td&gt;
&lt;td&gt;76.8 GB/s&lt;/td&gt;
&lt;td&gt;600 MHz&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;800 MHz&lt;/td&gt;
&lt;td&gt;1.6 Gbps&lt;/td&gt;
&lt;td&gt;171 W&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;345.6&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;14.40 GPixel/s&lt;/td&gt;
&lt;td&gt;38.40 GTexel/s&lt;/td&gt;
&lt;td&gt;11.1 (10_0)&lt;/td&gt;
&lt;td&gt;3.3&lt;/td&gt;
&lt;td&gt;1.1 (1.0)&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;1.0&lt;/td&gt;
&lt;td&gt;4.0&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;Tesla C870&lt;/td&gt;
&lt;td&gt;NVIDIA&lt;/td&gt;
&lt;td&gt;2007-05-02&lt;/td&gt;
&lt;td&gt;1,499 USD&lt;/td&gt;
&lt;td&gt;Tesla&lt;/td&gt;
&lt;td&gt;TSMC&lt;/td&gt;
&lt;td&gt;90 nm&lt;/td&gt;
&lt;td&gt;G80&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;PCIe 1.0 x16&lt;/td&gt;
&lt;td&gt;128&lt;/td&gt;
&lt;td&gt;32&lt;/td&gt;
&lt;td&gt;24&lt;/td&gt;
&lt;td&gt;16 SMs&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;96 KB&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;1536 MB&lt;/td&gt;
&lt;td&gt;GDDR3&lt;/td&gt;
&lt;td&gt;384 bit&lt;/td&gt;
&lt;td&gt;76.8 GB/s&lt;/td&gt;
&lt;td&gt;600 MHz&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;800 MHz&lt;/td&gt;
&lt;td&gt;1.6 Gbps&lt;/td&gt;
&lt;td&gt;171 W&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;345.6&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;14.40 GPixel/s&lt;/td&gt;
&lt;td&gt;38.40 GTexel/s&lt;/td&gt;
&lt;td&gt;11.1 (10_0)&lt;/td&gt;
&lt;td&gt;3.3&lt;/td&gt;
&lt;td&gt;1.1 (1.0)&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;1.0&lt;/td&gt;
&lt;td&gt;4.0&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;GeForce 8800 GTX&lt;/td&gt;
&lt;td&gt;NVIDIA&lt;/td&gt;
&lt;td&gt;2006-11-08&lt;/td&gt;
&lt;td&gt;599 USD&lt;/td&gt;
&lt;td&gt;Tesla&lt;/td&gt;
&lt;td&gt;TSMC&lt;/td&gt;
&lt;td&gt;90 nm&lt;/td&gt;
&lt;td&gt;G80&lt;/td&gt;
&lt;td&gt;G80-300-A2&lt;/td&gt;
&lt;td&gt;PCIe 1.0 x16&lt;/td&gt;
&lt;td&gt;128&lt;/td&gt;
&lt;td&gt;32&lt;/td&gt;
&lt;td&gt;24&lt;/td&gt;
&lt;td&gt;16 SMs&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;96 KB&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;768 MB&lt;/td&gt;
&lt;td&gt;GDDR3&lt;/td&gt;
&lt;td&gt;384 bit&lt;/td&gt;
&lt;td&gt;86.4 GB/s&lt;/td&gt;
&lt;td&gt;576 MHz&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;900 MHz&lt;/td&gt;
&lt;td&gt;1.8 Gbps&lt;/td&gt;
&lt;td&gt;155 W&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;345.6&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;13.82 GPixel/s&lt;/td&gt;
&lt;td&gt;36.86 GTexel/s&lt;/td&gt;
&lt;td&gt;11.1 (10_0)&lt;/td&gt;
&lt;td&gt;3.3&lt;/td&gt;
&lt;td&gt;1.1 (1.0)&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;1.0&lt;/td&gt;
&lt;td&gt;4.0&lt;/td&gt;
&lt;/tr&gt;
&lt;tr&gt;
&lt;td&gt;GeForce 9800 GTX&lt;/td&gt;
&lt;td&gt;NVIDIA&lt;/td&gt;
&lt;td&gt;2008-03-28&lt;/td&gt;
&lt;td&gt;299 USD&lt;/td&gt;
&lt;td&gt;Tesla&lt;/td&gt;
&lt;td&gt;TSMC&lt;/td&gt;
&lt;td&gt;65 nm&lt;/td&gt;
&lt;td&gt;G92&lt;/td&gt;
&lt;td&gt;G92-420-A2&lt;/td&gt;
&lt;td&gt;PCIe 2.0 x16&lt;/td&gt;
&lt;td&gt;128&lt;/td&gt;
&lt;td&gt;64&lt;/td&gt;
&lt;td&gt;16&lt;/td&gt;
&lt;td&gt;16 SMs&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;64 KB&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;512 MB&lt;/td&gt;
&lt;td&gt;GDDR3&lt;/td&gt;
&lt;td&gt;256 bit&lt;/td&gt;
&lt;td&gt;70.4 GB/s&lt;/td&gt;
&lt;td&gt;675 MHz&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;1100 MHz&lt;/td&gt;
&lt;td&gt;2.2 Gbps&lt;/td&gt;
&lt;td&gt;140 W&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;432.1&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;10.80 GPixel/s&lt;/td&gt;
&lt;td&gt;43.20 GTexel/s&lt;/td&gt;
&lt;td&gt;11.1 (10_0)&lt;/td&gt;
&lt;td&gt;3.3&lt;/td&gt;
&lt;td&gt;1.1&lt;/td&gt;
&lt;td&gt;&lt;/td&gt;
&lt;td&gt;1.1&lt;/td&gt;
&lt;td&gt;4.0&lt;/td&gt;
&lt;/tr&gt;
&lt;/tbody&gt;
&lt;/table&gt;
&lt;/div&gt;
&lt;script&gt;
document.addEventListener('DOMContentLoaded', function() {
let styleBlock = document.getElementById('col-hover-style');
if (!styleBlock) {
styleBlock = document.createElement('style');
styleBlock.id = 'col-hover-style';
document.head.appendChild(styleBlock);
}
function applyTableEnhancements() {
const tableContainer = document.querySelector('.scrollable-table');
if(!tableContainer) return;
const rows = tableContainer.querySelectorAll('tbody tr');
rows.forEach(row =&gt; {
const brandCell = row.querySelector('td:nth-child(2)');
if(brandCell) {
const brand = brandCell.textContent.trim().toLowerCase();
if(brand.includes('nvidia')) {
row.classList.add('brand-nv');
} else if(brand.includes('amd') || brand.includes('ati')) {
row.classList.add('brand-amd');
} else if(brand.includes('intel')) {
row.classList.add('brand-intel');
}
}
});
tableContainer.addEventListener('mouseover', function(e) {
const cell = e.target.closest('td, th');
if (!cell) return;
const colIndex = cell.cellIndex + 1;
styleBlock.textContent = `.scrollable-table tbody td:nth-child(${colIndex}), .scrollable-table thead th:nth-child(${colIndex}) { background-color: var(--tbl-hover) !important; }`;
});
tableContainer.addEventListener('mouseout', function(e) {
styleBlock.textContent = '';
});
}
const observer = new MutationObserver(function(mutations, observer) {
const table = document.querySelector('.scrollable-table .sortable');
if (table &amp;&amp; table.offsetWidth &gt; 0) {
applyTableEnhancements();
document.dispatchEvent(new Event('tableRendered'));
observer.disconnect();
}
});
observer.observe(document.body, { childList: true, subtree: true });
setTimeout(() =&gt; {
if (document.querySelector('.scrollable-table .sortable')) {
applyTableEnhancements();
}
}, 300);
});
&lt;/script&gt;
&lt;p&gt;&lt;em&gt;(完全なデータは省略されています)&lt;/em&gt;&lt;/p&gt;</description></item><item><title>ゲームのスコアシステムは本当に人を疎外するのか？</title><link>https://yuchao-wang.netlify.app/ja/post/rating-system-alienation/</link><pubDate>Sun, 16 Mar 2025 00:00:00 +0000</pubDate><guid>https://yuchao-wang.netlify.app/ja/post/rating-system-alienation/</guid><description>&lt;p&gt;最近、私は「遊戯研究社」に掲載された非常に考えさせられる記事、『だから、スコアシステムは本当に人を疎外するのか？』（以下「元の記事」）を読んだ。この記事は、ある『リーグ・オブ・レジェンド』の配信者の愚痴を切り口として、ゲームのスコアシステムが引き起こす可能性のある「疎外」現象について深く掘り下げている。この配信者はゲームに負けた後、自身のスコアがKD（キル・デス）0-3のプレイヤーよりも低いことに気づき、「スコアシステムは人の貢献を疎外してしまう。俺の親父は仕事で稼いでスコア13.0でMVP、お袋は家事をこなしてスコア3.0でキャリーされるだけのプレイヤー、そんな計算でいいのか？」と怒りを露わにした。&lt;/p&gt;
&lt;p&gt;この発言は率直で鋭いだけでなく、中国のインターネット上で瞬く間にミーム化し、ネットユーザーによって様々な生活の場面に当てはめられた。さらにはAIを使ってコミカルな動画が生成されるなど、広く拡散される話題となった。元の記事はまさにこのような背景の下で執筆されたものであり、筆者の完全な見解を知りたい場合は、
から全文を読むことができる（原文は簡体字中国語）。&lt;/p&gt;
&lt;p&gt;これにより私は深く考えさせられた。スコアシステム、あるいはより広義の評価システムは、ゲームにおいて一体どのような役割を果たしているのだろうか？元の記事が言うように、それは本当にプレイヤーを「疎外」してしまうのだろうか？ゲーム業界の元従事者および関係者として、具体的な事例とデザインの視点を交えながらこの問題を体系的に整理し、プレイヤーや同業者に深みのある議論の方向性と実用的な提案を提供したいと思う。&lt;/p&gt;
&lt;h3 id="思考の起点元の記事の視点に対する共感と相違"&gt;思考の起点：元の記事の視点に対する共感と相違&lt;/h3&gt;
&lt;p&gt;元の記事はスコアシステムの歴史的起源を振り返り、『スペースインベーダー』時代のアーケードゲームから始まり、その当初の目的がプレイヤーにポジティブなフィードバックを提供し、競争のモチベーションを刺激することであったと指摘している。しかし、ゲームデザインが複雑化するにつれて、特にチーム対戦型ゲームにおいて、スコアシステムは次第に「プレイヤーを導く」ものから「プレイヤーを縛る」ものへと変化し、心理的なプレッシャーをもたらす可能性すら生じてきた。記事は「疎外（Alienation）」という概念を借りて、プレイヤーが「主体的にゲームを遊ぶ」状態から「ゲームに操られる」状態へと変わる可能性があるとし、陽明交通大学の論文『Design Aspects of Scoring Systems in Game』を引用して、スコアデザインには知覚可能性（可感知度）、制御可能性（可控性）、そして目的性（目標性）が備わっているべきだと強調している。元の記事は最後に、技術の進歩によってスコアはより正確になったものの、過度な定量化によってゲームの楽しさが損なわれ、競技体験が「ルーレットのくじ引き」のようなランダムなギャンブルに単純化されてしまう可能性があるという、深く考えさせられる視点を提示している。&lt;/p&gt;
&lt;p&gt;私は元の記事のいくつかの見解には同意する。例えば、現在のいくつかのスコアシステムは顕在的なデータ（KDAなど）に過度に焦点を当てており、プレイヤーの潜在的な貢献（チームワークや戦略的サポートなど）を軽視している。これは確かに、プレイヤーの行動がスコアシステムの中で過度に単純化される結果を招く可能性がある。また、開発者がスコアのロジックを精緻に設計すればするほど、プレイヤーは逆にその枠組みに縛られやすくなるという、元の記事が提起したパラドックスにも部分的に同意する。しかし、私は元の記事のスコアシステムに対する完全な否定的な態度には完全に賛同できない。元の記事は、スコアシステムそのものが「疎外」の根源であり、技術がどれほど完璧になってもこの宿命からは逃れられないと暗示しているように思える。私はむしろ、スコアシステムは外部的なツールであり、その影響は不変ではなく、デザインのあり方とプレイヤーの内発的動機との相互作用によって決まると考えている。言い換えれば、外的な要因は内的な要因を通じて初めて機能するのだ。したがって、スコアシステムの存在を原罪とみなすよりも、デザインの最適化という観点から、どのようにすればゲーム体験をより良くサポートできるかを探求する方が建設的だと考える。&lt;/p&gt;
&lt;p&gt;さらに、プレイヤーのニーズや動機が千差万別であることも無視できない。リチャード・バートル（Richard Bartle）はかつて、プレイヤーをAchievers（達成者）、Explorers（探索者）、Socializers（社交者）、Killers（キラー）の4つのタイプに分類した。このうち、達成者はスコアによって得られる承認をより重視するかもしれないが、探索者や社交者はゲームの他の楽しさに目を向けるかもしれない。異なるタイプのプレイヤーを一概に論じることはできず、スコアシステムの役割は人によって異なるのである。&lt;/p&gt;
&lt;h3 id="評価システムの多面性pveとpvpの比較分析"&gt;評価システムの多面性：PVEとPVPの比較分析&lt;/h3&gt;
&lt;p&gt;スコアシステムをより包括的に分析するために、シングルプレイヤー/協力型ゲーム（PVE）とマルチプレイヤー対戦型ゲーム（PVP）を分けて議論する。両者はある面で共通点を持つものの、デザインの目標、プレイヤーの行動、そして評価システムの適用方法において顕著な違いが存在するため、個別に分析する価値がある。&lt;/p&gt;
&lt;h4 id="pveゲーム誘導と多様な評価"&gt;PVEゲーム：誘導と多様な評価&lt;/h4&gt;
&lt;p&gt;PVEゲームでは、開発者のゲーム環境や挑戦に対するコントロール力が強く、評価システムはプレイヤーがプレイスタイルを模索しスキルを向上させるのを助ける誘導ツールとしてデザインされることが多い。『デビルメイクライ』シリーズを例に挙げると、そのコンボスコアシステムはS、A、Bなどの直感的なランクを用いており、派手な効果音や視覚効果と相まって、プレイヤーに難易度の高いコンボ操作に挑戦するよう促している。このデザインは、華麗な戦闘スタイルこそがゲームの核心的な楽しさであるというシグナルを明確に伝えている。&lt;/p&gt;
&lt;p&gt;しかし、PVEゲームの評価システムは単なるスコアの数字に留まらない。より広義のシステム——例えばSteamプラットフォームの実績システムやスピードランのランキング、さらにはストーリー関連のアンロックアイテムなども、プレイヤーに対する評価手法とみなすことができる。例えば、フロム・ソフトウェアのゲーム（『ダークソウル』など）には明確なスコア体系はないが、プレイヤーが異なる装備、ビルド、戦略を用いてボスに挑み、コミュニティで承認を得ることで、依然として強い達成感を得ることができる。これらのシステムの共通点は、ゲームの核心的な体験と密接に結びついており、ポジティブなフィードバックを提供しつつ単一の基準を押し付けることを避けることで、「疎外」のリスクを軽減している点にある。&lt;/p&gt;
&lt;p&gt;もちろん、スコアへの過度な依存は潜在的なリスクももたらす。例えば、Sランクのスコアを追求するあまり、プレイヤーがストーリーや探索の楽しみを無視してステージを繰り返しプレイし、ゲーム体験が「挑戦を楽しむ」ことから退屈な「スコア稼ぎの作業」へと変わってしまうことがある。私の考えでは、プレイヤーが自発的にそのような遊び方を選択するのであれば、設計者がその可能性を完全に否定する必要はないが、誘導性と自由度の間でバランスを取る必要がある。適切な方向性を示しつつも、プレイヤーの予想外の創造的な選択を否定しないことが求められる。&lt;/p&gt;
&lt;h4 id="pvpゲームバランスと論争の交差点"&gt;PVPゲーム：バランスと論争の交差点&lt;/h4&gt;
&lt;p&gt;対照的に、PVPゲームの評価システムはより複雑であり、論争を引き起こしやすい。『リーグ・オブ・レジェンド』を例にとると、そのスコアシステムには2つの主な用途がある。対戦前のマッチメイキング（隠しレートに基づく）と、対戦後のパフォーマンス評価（MVPやSVPなど）である。前者は対戦の公平性を確保することを目的としており、後者は各プレイヤーの各試合における個人的な貢献を定量化しようとするものである。また、後者の多くはゲーム内蔵ではなく、ゲームの運営側（例えば中国本土サーバーのアプリ）によって提供されている。&lt;/p&gt;
&lt;p&gt;PVPゲームにおいて、評価システムはマッチメイキングメカニクス（matchmaker）と密接に関連している。特にプレイヤー数の少ない対戦（3v3や5v5など）では、各プレイヤーの役割が非常に大きいため、スコアシステムはランク別のマッチングを通じて「初心者狩り（スマーフ）」（上級者が初心者を圧倒する現象）を減らし、全体の公平性を高めている。この目的のため、多くのゲームは勝率や個人のパフォーマンスに基づくランクシステムを導入し、プレイヤーを異なるスキルグループに分けている。しかし、プレイヤー数が多くランダム性の強いゲーム（『PUBG』などのバトルロイヤル系ゲーム）では、不確定要素が多すぎるためにスコアの影響が薄れ、プレイヤーが不均衡を感じる度合いも比較的低い。だが、これは開発者がバランスの問題を放置してよいという意味ではない。&lt;/p&gt;
&lt;p&gt;先述の配信者の愚痴が示しているように、対戦後のスコアデザインは、チームワークやキャラクターの役割を軽視していることが原因で不満を引き起こすことがある。『リーグ・オブ・レジェンド』を例に挙げると、プロの試合でのMVP選出はシステムが自動生成するのではなく、解説者やゲストがデータと臨場のパフォーマンスに基づいて総合的に評価する。この手法では、特定の選手のKDAデータが目立たなくとも、重要な集団戦でエンゲージやクラウドコントロール（CC）などの操作を通じて戦局を覆した場合、MVPに選ばれる可能性がある。このような人手による選出は、データ以外の価値を捉え、より包括的な評価基準を示すことができる。それに比べ、現在の対戦後の自動スコアシステムはKDA、視界スコア、キル関与率などの顕在的な指標に依存しがちで、耐えるポジション（ウィークサイド）やサポートポジションの潜在的な貢献を見落としている。したがって、元の記事で言及されたミームが広く拡散されたのは、スコア自体を完全に否定しているわけではなく、既存のスコアメカニクスの欠点に対するプレイヤーの不満を反映しているからである。&lt;/p&gt;
&lt;h3 id="評価システムのデザインにおける課題"&gt;評価システムのデザインにおける課題&lt;/h3&gt;
&lt;p&gt;心理学の観点から見ると、スコアシステムの本質はフィードバックメカニズムである。フィードバック介入理論（Feedback Intervention Theory）によれば、効果的なフィードバックは具体的で行動に焦点を当てており、プレイヤーの自己価値を脅かすものを避けるべきである。しかし、多くのゲームのスコアデザインは冷たい数字やランクを提供するだけで、改善の提案に欠けており、プレイヤーに「助けられている」のではなく「裁かれている」と感じさせてしまう。PVEであれPVPであれ、評価システムのデザインは以下の共通の課題に直面している。&lt;/p&gt;
&lt;h4 id="知覚可能性と公平性"&gt;知覚可能性と公平性&lt;/h4&gt;
&lt;p&gt;プレイヤーはスコアの根拠を明確に理解する必要がある。スコアの基準が複雑すぎたり不透明だったりする場合（今回の事例における対戦後のスコアの具体的なアルゴリズムなど）、プレイヤーは混乱や不公平感を感じるかもしれない。特に対戦に負けた後、ただでさえ落ち込んでいるプレイヤーが「根拠のない」低いスコアに直面すれば、火に油を注ぐことになり、挫折感を増幅させ、ゲームへの不満すら生じかねない。&lt;/p&gt;
&lt;h4 id="制御可能性と多様性"&gt;制御可能性と多様性&lt;/h4&gt;
&lt;p&gt;プレイヤーは自分の努力がスコアに反映されることを望んでいるが、ゲーム内のランダムなイベント（味方のミスや敵の戦略など）がこのコントロール感を損なう可能性がある。一方で、ある程度のランダム性はゲームの楽しさの源でもあるため、これら両者のバランスをどう取るかが難題となる。私の考えでは、核心となる原則は「プレイヤーは自分がコントロールできない要因の責任を負わされるべきではない」ということだ。例えば『リーグ・オブ・レジェンド』において、敵がトップレーンを集中的に狙ってトップライナーが頻繁にデスした場合、これは明らかにトップライナーの操作ミスではなく相手の戦略によるものであり、スコアによって彼を厳しく責めるべきではない。&lt;/p&gt;
&lt;p&gt;同時に、リチャード・バートルのプレイヤー分類理論が思い出させるように、プレイヤーごとに求めるものは異なる。単一のスコア基準で全員の期待を満たすことは難しい。もし総合点を出さなければならないのであれば、具体的な加重ロジックを公開することで一部の論争を緩和できるかもしれない。&lt;/p&gt;
&lt;h4 id="目的と体験の合致"&gt;目的と体験の合致&lt;/h4&gt;
&lt;p&gt;評価システムはゲームの核心的な楽しさをサポートするものであるべきだ。例えば、チームゲームではアシストもキルと同様にスコアを上げるべきであり、オープンワールドゲームではすべての隠しエリアを探索することで実績報酬がアンロックされるべきである。理想的なスコアデザインは、プレイヤーにハイスコアを追求させると同時に、ゲームの楽しさをより深く体験するよう導くべきであり、これを実現するには高いレベルのシステム設計が必要である。&lt;/p&gt;
&lt;h3 id="評価システムの最適化に向けた提案"&gt;評価システムの最適化に向けた提案&lt;/h3&gt;
&lt;p&gt;上記のアナリシスに基づいて、プレイヤーや同業者への参考として以下の最適化の方向性を提案する。&lt;/p&gt;
&lt;h4 id="スコアの透明性の向上"&gt;スコアの透明性の向上&lt;/h4&gt;
&lt;p&gt;スコアのロジックを公開し、詳細なフィードバックを添付する。対戦後に加重合計スコアを表示するだけでなく、プレイヤーが各項目の具体的な得点と加重割合を確認できるようにすべきである。多くの場合、プレイヤーが低いスコアを受け入れられないのは、説明のない低スコアを受け入れられないからである。合理的なスコア体系は、乱暴な評価ではなく建設的な提案を提供すべきである。ただし、低スコア時の提案の言葉遣いが不適切だと、皮肉と誤解される可能性がある。そのため、私は3段階の表示形式を提案する。&lt;/p&gt;
&lt;ul&gt;
&lt;li&gt;加重合計スコア&lt;/li&gt;
&lt;li&gt;項目別スコア（マウスを合計スコアの横にホバーした時のみ、ツールチップ形式で展開される）&lt;/li&gt;
&lt;li&gt;改善の提案（直接的な感情の刺激を避けるため、ツールチップ内のボタンの後ろに隠す）&lt;/li&gt;
&lt;/ul&gt;
&lt;p&gt;具体的な改善の提案を提供すること自体は非常に微妙な問題であり、現段階のAIでは十分に正確で実用的な回答を提供できない可能性がある。その結果、専門家による実際の効果的かつ建設的な提案ではなく、素人の口出しのように見えてしまい、逆効果になる恐れがある。これはスコアシステムが早急に突破すべき難題の一つである。&lt;/p&gt;
&lt;p&gt;さらに、第3層にはフィードバックウィンドウを追加し、プレイヤーが評価システムに対する改善意見を提出できるようにすることも考えられる。プレイヤーが低スコアに本当に怒りや疑問を感じている場合、即座に感情を吐き出せる窓口を提供することは、開発側の姿勢を示し、誠意を強調することに繋がる。&lt;/p&gt;
&lt;h4 id="柔軟性とパーソナライゼーション"&gt;柔軟性とパーソナライゼーション&lt;/h4&gt;
&lt;p&gt;PVEゲームでは、スコアの表示に設計者のソフトな誘導が組み込まれている場合があるが、PVPゲームにおいては、プレイヤーにスコアを公開するかどうかなど、より多くの選択権を与えるべきである。サードパーティがスコアツールを提供している場合、ゲームクライアントは同時に対戦の内外で機能する匿名化ツールを提供するか、対戦の内外のあらゆるメッセージを完全にブロックする機能を備えるべきである。&lt;/p&gt;
&lt;p&gt;公平性を確保するため、匿名を選択したプレイヤーは他人のスコアを見ることができず、スコアを公開したプレイヤーは同じく公開したプレイヤーのスコアのみを見ることができるようにする。これにより、比較による優越感を追求するプレイヤーは独自のコミュニティを形成でき、参加したくないプレイヤーは干渉から免れることができる。このような「権利と責任の対等」のデザインは、自分が不調の時は批判から逃げる一方で、他人のミスは容赦なく侮辱する「ネット荒らし」現象を抑制し、より健全なゲーム環境を維持するのに役立つかもしれない。&lt;/p&gt;
&lt;h4 id="コミュニティとの共創"&gt;コミュニティとの共創&lt;/h4&gt;
&lt;p&gt;ゲーム内のアンケートやフォーラムでの議論を通じて、評価システムに対するプレイヤーの意見や提案を収集する。プレイヤーの声に耳を傾けると同時に、開発者は積極的な姿勢を示す必要がある。例えば、評価システムに関連する改善計画を定期的に発表したり、話題になっているトピックに回答したりすることである。開発チームが問題をすぐに解決する手段を一時的に持っていなかったとしても、コメント欄などのコミュニティとの対話からインスピレーションを得ることで、独りよがりになるのを防ぐことができる。「あなたたちのためを思って」というような高圧的な態度は逆効果になり、プレイヤーと開発者の間の溝を深めるだけである。&lt;/p&gt;
&lt;h4 id="多様な評価形式"&gt;多様な評価形式&lt;/h4&gt;
&lt;p&gt;PVPゲームにおいて、スコアはリソースや賞罰と直接結びつけるべきではない。結びつけることは勝者の達成感を強める一方で、敗者の挫折感をも増幅させてしまう。より良い方法は、称号などの装飾的な報酬を提供し、異なる次元で優れたパフォーマンスを示したプレイヤーを称えることである。パフォーマンスが悪かったプレイヤーは、その試合でこれらの名誉的な報酬を得られなかったというだけであり、実質的な損失を被ることはない。&lt;/p&gt;
&lt;p&gt;同時に、私は長期的なポジティブフィードバックメカニズムの導入を強く支持する。例えば「生涯累計キル数トロフィー」や「累計称号獲得回数による隠し報酬のアンロック」などである。評価システムを利用してプレイヤーの注意を長期的なポジティブな達成に向けさせ、単一の試合の勝敗に対する執着を薄めるのである。&lt;/p&gt;
&lt;h3 id="結び"&gt;結び&lt;/h3&gt;
&lt;p&gt;評価システムはゲームデザインにおける重要なツールとして、プレイヤーをゲームに慣れさせ、定着率を高めることができる一方で、不適切なデザインはプレッシャーや「疎外」感をもたらす可能性もある。私は、評価システムが生まれながらにして「疎外」を引き起こすわけではなく、その効果は開発者の巧みなコントロール、定量的フィードバックの正確性、そしてプレイヤーの主観的な体験によって決まると考えている。PVEとPVPの特性を区別し、プレイヤーの多様なニーズに注意を払うことで、私たちは評価システムがプレイヤーを縛るものではなく、ゲームの楽しさをより良くサポートするものにすることができる。業界の従事者にとって、これは技術レベルの最適化であるだけでなく、プレイヤーの心理と文化に対する深い洞察でもあるのだ。&lt;/p&gt;
&lt;p&gt;本稿は急ぎ執筆されたものであり、あくまで一人の見解に過ぎず、見落としや偏りがあることは免れない。読者の皆様からの批判や訂正を歓迎するとともに、交流を通じてもっと多くの火花が散り、共同でゲームデザインの進歩を推進できることを期待している！&lt;/p&gt;</description></item><item><title>経歴</title><link>https://yuchao-wang.netlify.app/ja/experience/</link><pubDate>Tue, 04 Mar 2025 00:00:00 +0000</pubDate><guid>https://yuchao-wang.netlify.app/ja/experience/</guid><description/></item><item><title>プロジェクト</title><link>https://yuchao-wang.netlify.app/ja/projects/</link><pubDate>Sun, 19 May 2024 00:00:00 +0000</pubDate><guid>https://yuchao-wang.netlify.app/ja/projects/</guid><description/></item></channel></rss>