JavaプロジェクトにSonarQubeを導入すると、コードの問題をコミット前に自動で検出できるようになります。
対象はNullPointerExceptionやリソースリーク、セキュリティ脆弱性など多岐にわたります。コードを動かさずにバグの芽を摘み取れる。
これが静的解析の最大の価値です。
SonarQubeとは、ソースコードを実行せずに解析し、バグ・脆弱性・保守性の低下（Code Smells）を検出するオープンソースの静的解析ツールです。
Community Build（無料版）でも商用利用でき、Docker1つで手元の環境に立ち上げられます。
この記事では、Javaバックエンドエンジニアとしての開発経験をもとに、以下をすべて解説します。
この記事でわかること
- SonarQubeのDockerインストール（5分で起動）
- sonar-project.propertiesの最小構成
- Maven／GradleでのJavaプロジェクト解析手順
- 解析結果（Bugs／Vulnerabilities／Code Smells）の読み方
- GitHub Actionsへの組み込み方
- SonarLintを使ったIDE連携
「警告が出すぎて放置している」「チームに導入したが形骸化している」という悩みにも、具体的な運用ルールを交えて答えます。
若手のころ、ベテランの先輩にコードレビューで何十個もの指摘をもらい、鼻をへし折られたことがあります。
そんな私が「機械に任せられる部分は機械に任せる」という答えにたどり着くまでの実体験もあわせてお伝えします。
PARTS LIST ／目次
SonarQubeのJava要件とバージョン対応表
セットアップの前に、バージョンの組み合わせを確認しておきましょう。
「動かない」という問い合わせの多くは、JavaとSonarQubeのバージョン不一致が原因です。ポイントは、サーバー・スキャナー・解析対象プロジェクトで必要なJavaが別々に決まっていることです（2026年9月時点の公式ドキュメント準拠）。
SonarQubeのバージョン体系は2025年からカレンダーベースに移行しました。有償版のSonarQube Serverは「2026.1 LTA」のような年.番号形式、無料のCommunity Buildは「26.9」のような年.月形式でほぼ毎月リリースされます。
JRE自動プロビジョニング（対応スキャナーではデフォルト有効）が有効な場合、解析に使うJavaはサーバーから自動取得されるため、手元はJava 11以上で動作します。
無効化している場合は、Java 21以上へのアップグレードが必要です。
注意点は2つあります。まず、SonarQubeサーバーやスキャナーが使うJavaと、解析対象のJavaプロジェクトのバージョンは別物です。
スキャナーはJava 21で動かしつつ、解析対象のプロジェクトはJava 8でも構いません。Maven／Gradleならsonar.java.sourceは自動設定され、手動で書く場合はJava 8ならsonar.java.source=1.8と指定します。
次に、ビルド全体をJava 21に上げられない場合は、解析ステップの直前だけJAVA_HOMEをJava 21に切り替える方法が公式ドキュメントで案内されています。まず自分の環境のJavaバージョンを確認してください。
java -version
# 出力例: openjdk version "21.0.8" 2025-07-15DockerでSonarQubeサーバーを起動する
SonarQubeはサーバーとデータベース、解析を実行するスキャナーが連携して動きます。
個人学習やチームへの導入を試したいなら、Dockerを使うのが最短ルートです。
コマンド1つで起動する（開発・学習向け）
内蔵のH2データベースを使う簡易構成です。データの永続化はされませんが、試すには十分です。
docker run -d \
--name sonarqube \
-p 9000:9000 \
sonarqube:community無料版（Community Build）のイメージタグはcommunityです。古い記事でよく見かけるlts-communityタグは2025年9月以降更新されていないため、新規導入では使わないでください。バージョンを固定したい場合は26.9.0.129388-communityのようにDocker Hubのタグを明示します。
起動後、ブラウザで http://localhost:9000 にアクセスします。初回ログインのID／パスワードはともに admin です。
ログイン後すぐにパスワード変更を求められるので、忘れないようにメモしておきましょう。
PostgreSQLと組み合わせる（チーム・本番向け）
チームで継続利用する場合は、PostgreSQLと組み合わせて解析履歴を永続化します。
# docker-compose.yml
services:
sonarqube:
image: sonarqube:community
ports:
- "9000:9000"
environment:
SONAR_JDBC_URL: jdbc:postgresql://db:5432/sonar
SONAR_JDBC_USERNAME: sonar
SONAR_JDBC_PASSWORD: sonar
volumes:
- sonarqube_data:/opt/sonarqube/data
- sonarqube_extensions:/opt/sonarqube/extensions
- sonarqube_logs:/opt/sonarqube/logs
depends_on:
- db
db:
image: postgres:17
environment:
POSTGRES_USER: sonar
POSTGRES_PASSWORD: sonar
POSTGRES_DB: sonar
volumes:
- postgresql_data:/var/lib/postgresql/data
volumes:
sonarqube_data:
sonarqube_extensions:
sonarqube_logs:
postgresql_data:docker compose up -d起動したら、管理画面でプロジェクトを作成し、解析用のトークンを発行します。このトークンは後の手順で必要になるので控えておいてください。
sonar-project.propertiesの最小構成を書く
プロジェクトのルートに sonar-project.properties ファイルを置くことで、スキャン時のオプションを省略できます。以下が最小構成です。
# sonar-project.properties
sonar.projectKey=my-java-project
sonar.projectName=My Java Project
sonar.projectVersion=1.0
# ソースコードの場所
sonar.sources=src/main/java
sonar.tests=src/test/java
# 解析対象プロジェクトのJavaバージョン（サーバーとは別）
sonar.java.source=17
# コンパイル済みバイナリの場所（解析精度向上のために推奨）
sonar.java.binaries=target/classes
# JaCoCoカバレッジレポートの場所（テストカバレッジを計測する場合）
sonar.coverage.jacoco.xmlReportPaths=target/site/jacoco/jacoco.xml
# SonarQubeサーバーの接続先
sonar.host.url=http://localhost:9000
sonar.token=your-token-here認証にはsonar.tokenを使います。以前のsonar.loginは非推奨になっているため、古い設定を流用する場合は書き換えておきましょう。トークンをファイルに書いたままコミットしないよう、実運用では環境変数SONAR_TOKENで渡すのが安全です。
なお、sonar-project.propertiesを読むのはSonarScanner CLIです。次章のMaven／Gradleプラグインで解析する場合は、同じ設定をpom.xml・build.gradleやコマンドの-D引数で指定します。
sonar.java.binaries を指定しないと「バイナリが見つからない」エラーが出ることがあります。
先に mvn compile や ./gradlew classes でビルドを通してからスキャンするのが安全です。
Maven・GradleでJavaプロジェクトを解析する
Javaエンジニアなら、MavenかGradleのプラグインを使うのが最もスマートです。
ビルドの一環として解析が走るため、CI連携とも相性が良くなります。
Mavenプロジェクトの場合
SonarScanner for Mavenはpom.xmlに宣言しなくても実行できますが、公式ドキュメントではバージョンをpluginManagementで固定する書き方が推奨されています（この記事は2026年9月時点の5.8.0.7211をもとにしています）。
<build>
<pluginManagement>
<plugins>
<plugin>
<groupId>org.sonarsource.scanner.maven</groupId>
<artifactId>sonar-maven-plugin</artifactId>
<version>5.8.0.7211</version>
</plugin>
</plugins>
</pluginManagement>
</build>以下のコマンドで解析を実行します。短縮形のmvn sonar:sonarでも動きますが、公式ドキュメントはプラグインを完全修飾名で指定する形を案内しています。
# ビルドしてから解析（カバレッジも取得する場合）
mvn clean verify org.sonarsource.scanner.maven:sonar-maven-plugin:sonar \
-Dsonar.host.url=http://localhost:9000 \
-Dsonar.token=your-token-hereGradleプロジェクトの場合
build.gradle にプラグインを追加します（この記事は2026年9月時点の7.5.0.8588をもとにしています）。設定ブロック名とタスク名はsonarです。古い記事にあるsonarqube { }ブロックや./gradlew sonarqubeタスクは旧名称なので、新規に書くならsonarに揃えましょう。
plugins {
id "java"
id "jacoco" // カバレッジを計測する場合
id "org.sonarqube" version "7.5.0.8588"
}
sonar {
properties {
property "sonar.projectKey", "my-java-project"
property "sonar.host.url", "http://localhost:9000"
// トークンは環境変数 SONAR_TOKEN から自動で読み込まれる
}
}# 環境変数でトークンを渡して実行（ビルド・テスト後に解析）
SONAR_TOKEN=your-token-here ./gradlew build sonarコマンドを叩いてしばらく待つと、解析結果がSonarQubeサーバーに送信されます。
ブラウザで http://localhost:9000 を開くと、プロジェクトのダッシュボードに結果が表示されています。
解析結果の読み方とSonarQubeの基本操作
解析が終わると、画面には大量の数字やグラフが表示されます。これを見て「うわ、面倒くさそう」と拒絶反応を起こしてはいけません。
項目の意味さえ分かれば、どこを優先して直すべきかが自然と見えてきます。
Bugs・Vulnerabilities・Code Smellsの違い
「Bugs」は今すぐ修正が必要な動作不良、「Vulnerabilities」はセキュリティ上の欠陥を指します。
一方で「Code Smells」は、動作には問題ないものの、将来的にメンテナンスを困難にする書き方です。
これらを混同すると修正の優先順位を付け間違えます。
まずはBugsとVulnerabilitiesの2つに絞って対策を立てるのが、賢いエンジニアの立ち回りです。
ただし、命名のようなCode Smellsの範囲外にある設計判断は、SonarQubeでは拾いきれません。
以前レビューで「このメソッド名、何をするのかわからない」と指摘されたことがあります。
doProcess()をapplyDiscountIfEligible()に変えたら、周辺のコメントがまるごと不要になりました。
機械が拾えない領域は、やはり人間のレビューで補うしかありません。
初心者がまず見るべき画面と指標
最初に見るべきは、プロジェクトトップにある「Overview」タブです。
全体的な評価がAからEのランクで表示されており、直感的に今の状態を把握できます。まずは「New Code」という項目に注目してください。
過去の負債は一旦置いておき、新しく追加したコードに問題がないかを確認するだけで、プロジェクトの品質が今以上に悪化するのを防げます。
Quality Gateの判定の仕組み
Quality Gateは、プロジェクトがリリース可能な品質を満たしているかを判定する門番です。
「新規コードのバグが0個であること」や「テスト網羅率が80%以上」といった条件を自由に設定できます。
このゲートが「OK」にならない限り次の工程に進ませないといった運用により、客観的な指標でチーム内の議論をシンプルにできます。
SonarQubeがJavaで検出する問題とは
静的解析は、プログラムを実行せずにソースコードの「形」を見て問題を指摘する仕組みです。
ルールに基づいてコードをチェックするため、誰が解析しても同じ結果が出るのが特徴。
1,000行を超えるような巨大なクラスでも、一瞬で問題点をリストアップしてくれます。
Javaで見落としやすいバグ・臭いの例
実際に私が担当したプロジェクトでは、SonarQube導入前にNullPointerExceptionが原因で本番障害が月2〜3件発生していました。
SonarQubeを入れた翌月には、その件数がゼロになりました。「機械に怒られる」だけで、チームの書き方が変わるのです。
SonarQubeが検出するJava特有の問題を具体的なコードで見てみましょう。
// Before: SonarQube警告 java:S2095「リソースを閉じ忘れている」
public String readFile(String path) throws IOException {
InputStream is = new FileInputStream(path); // ← 閉じ忘れ警告
byte[] data = is.readAllBytes();
return new String(data);
}
// After: try-with-resourcesで修正
public String readFile(String path) throws IOException {
try (InputStream is = new FileInputStream(path)) {
byte[] data = is.readAllBytes();
return new String(data);
}
}他にも、catch (Exception e) {} のような大雑把な例外処理（java:S2221）や、複雑にネストされたif文（java:S3776：Cognitive Complexity超過）なども厳しく指摘されます。
警告の説明文には「なぜダメなのか」と「どう直すのか」が書かれているので、読み込むだけでJavaの深い知識が自然と身につきます。
SonarQubeのルール一覧はどこで確認する？
SonarQubeのWeb UI上部メニュー「Quality Profiles」から、Java用のデフォルトルールセットを確認できます。デフォルトのルールセット名は「Sonar way」です。各ルールにはjava:S2095のようなルールキーと、説明・修正例が紐づいています。
プロジェクト固有にルールを無効化・カスタマイズしたい場合は、Quality Profileを複製してから対象のルールの有効/無効を切り替えます。
切り替えたProfileを対象プロジェクトに割り当てれば完了です。デフォルトのSonar wayをそのまま使う場合は、この設定は不要です。
特定のメソッドやクラスだけ指摘を抑止したいときは、@SuppressWarnings("java:S2077")のようにルールキーを指定します。ファイル単位でルールを外したい場合は、Web UIの除外設定（Advanced exclusions）を使うのが公式の案内です。
コードレビューとの役割分担
機械に任せられる部分はすべてSonarQubeに任せ、人間はロジックの本質に集中しましょう。
インデントの乱れや命名規則の違反を人間が指摘するのは時間の無駄でしかありません。
設計の妥当性や業務仕様の整合性は人間がチェックし、定型的なミスはツールが弾く。
この分担を徹底することで、レビューの時間を短縮しつつ、質も上げられます。
コードレビュー文化のないチームでは、レビュープロセスを入れるだけでも本番に流れるバグは減りやすくなります。SonarQubeはそのレビューの前段で、機械的に拾える指摘を自動化する役割を担います。
SonarQubeでNullPointerExceptionを機械的に潰し、人間のレビューで設計判断を補う。
両方を揃えたときの効果は、片方だけの合計より大きくなります。
なお、PMDやSpotBugsはビルドに組み込んで単体で動かす解析ツールで、SonarQubeはサーバーに結果を蓄積してQuality Gateでチームの基準を管理するツールです。ビルドだけで完結させたいならPMD、バイトコードレベルのバグ検出ならSpotBugsの記事も参考にしてください。
警告を活かす運用ルール（Clean as You Code）
ツールを導入したものの、警告が多すぎて結局放置されるケースは少なくありません。これは、すべての指摘を均等に扱おうとするのが原因です。
「捨てる勇気」を持ち、現実的な運用ルールを作ることが、ツールを形骸化させないための秘訣です。
既存コードと新規コードを分けて考える
10年以上続くプロジェクトにSonarQubeを入れると、数万件の指摘が出ることも珍しくありません。
これをすべて直すのは現実的ではないため、既存コードの負債は「現状維持」と割り切るのも一つの手です。
その代わり、新しく書くコードに対しては厳格な基準を適用します。
この「Clean as You Code」という考え方を採用すれば、徐々に全体の品質を改善していけます。
SonarQubeのダッシュボードでも「New Code」ビューがあり、新規コードだけを対象に評価する機能が標準で備わっています。
重要度の高い指摘と後回しでよい指摘の見分け方
まずBugs（バグ）とVulnerabilities（脆弱性）だけを対象にするなど、スモールステップで始めるのが定石です。
システム停止や情報漏えいにつながるリスクがある指摘を最優先で修正し、Code Smells（コードの臭い）は余裕がある時に対処すれば十分です。
「週に1時間だけリファクタリングの時間を設ける」といった、ゆるいルールから始めましょう。
チームメンバーが「このツールは自分たちの味方だ」と感じられるようになります。
CIへの組み込みでレビュー補助を自動化する
手動でスキャンを実行する手間を省くために、CI（継続的インテグレーション）への組み込みは必須です。
開発者がコードをプッシュするたびに自動で解析が走り、Quality Gateを満たさなければCIのジョブを失敗させられます。プルリクエストへの結果コメント（PRデコレーション）はDeveloper Edition以上かSonarQube Cloudの機能で、無料のCommunity Buildではmainブランチの解析が対象です。
この仕組みを整えることで、SonarQubeは24時間365日働く「最強の副操縦士」へと進化します。
解析からQuality Gate判定、CIの成否までの流れを図にすると、次のようになります。
mvn verifyビルド・テスト・JaCoCosonar.qualitygate.wait=true で失敗させる。ダッシュボードで指摘を確認して修正し、1 の git push からやり直す
GitHub ActionsでSonarQube解析を自動化する
以下の設定を .github/workflows/sonarqube.yml として保存するだけで、pushやPRのたびに自動解析が走ります。
# .github/workflows/sonarqube.yml
name: SonarQube Analysis
on:
push:
branches: [main] # Community Buildはmainブランチのみ解析できる
jobs:
sonarqube:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v7
with:
fetch-depth: 0 # 差分解析の精度向上のため浅いクローンを無効化
- name: Set up JDK 21
uses: actions/setup-java@v6
with:
java-version: '21'
distribution: 'temurin'
cache: 'maven'
- name: Build and analyze
env:
SONAR_TOKEN: ${{ secrets.SONAR_TOKEN }}
SONAR_HOST_URL: ${{ secrets.SONAR_HOST_URL }}
run: |
mvn -B verify org.sonarsource.scanner.maven:sonar-maven-plugin:sonar \
-Dsonar.projectKey=my-java-project \
-Dsonar.qualitygate.wait=trueGitHubリポジトリの「Settings → Secrets and variables → Actions」に SONAR_TOKEN と SONAR_HOST_URL を登録しておきましょう。
-Dsonar.qualitygate.wait=trueを付けると、スキャナーがサーバー側のQuality Gate判定を待ち、不合格ならジョブを失敗させます。トリガーをpushのmainだけにしているのは、Community Buildが複数ブランチやPRの解析に対応していないためです。
セルフホスト型のSonarQubeサーバーはインターネットに公開されていないため、外部CIからアクセスできないこともあります。
その場合は SonarQube Cloud（旧SonarCloud、クラウド版）の利用も選択肢です。
Pull Request解析のメリットと利用条件
Developer Edition以上またはSonarQube Cloudなら、プルリクエストを出すとその変更差分だけに絞ってSonarQubeが解析結果をフィードバックしてくれます。Community Buildの場合は、mainへのマージ後に解析してQuality Gateで検知する運用になります。
レビュー依頼を出す前に自分でミスに気づけるため、レビューをする側も機械的なチェックが済んだ状態のコードを読めるので、本質的な議論に時間を割けるようになります。
まさに全員が幸せになれる仕組みです。
CI連携でよくつまずくポイントと対処の考え方
CI連携で多いのは、解析に時間がかかりすぎて開発のリズムが崩れることです。プロジェクトが大規模になると、解析だけで数十分かかる場合があります。
これを避けるために、差分解析（fetch-depth: 0 の設定）をうまく活用しましょう。
また、セルフホスト型のSonarQubeサーバーとCI環境のネットワーク疎通が取れているかも事前に確認が必要です。
メモリ不足（heap space）エラーの対処法
大規模プロジェクトの解析中にjava.lang.OutOfMemoryError: Java heap spaceが発生することがあります。
Scanner実行時に環境変数SONAR_SCANNER_OPTS=-Xmx2048mのようにヒープサイズを拡張すると解消するケースが多いです。
サーバー側でメモリ不足が起きている場合は、sonar.web.javaOptsやsonar.ce.javaOpts（コンピュートエンジン用）でヒープサイズを個別に調整します。
Docker運用時は、コンテナ自体のメモリ上限も合わせて見直しましょう。
Java開発での効果的なSonarQube活用法
Javaという言語の特性上、よく発生するミスのパターンが決まっています。
SonarQubeには長年の歴史で培われたJava専用のルール（SonarWay）が大量に組み込まれており、これを活用しない手はありません。
null安全・例外処理・条件分岐でよく出る指摘
Javaで最も多い実行時エラーはNullPointerException。
SonarQubeは変数がnullになる可能性を先読みして、事前にチェックするよう促します。
前述した大雑把な例外処理（java:S2221）や、ネストが深いif文によるCognitive Complexity超過（java:S3776）も、このカテゴリの代表的な指摘です。
これらを改善するだけで、コードの堅牢性と読みやすさが驚くほど向上します。
パフォーマンスと可読性に関する典型的な警告
ループ内での文字列連結（+ 演算子の多用）など、Javaでパフォーマンス劣化を招く定番の書き方を教えてくれます。
使われていない変数やインポート文も削除するよう促されるため、コードがスッキリします。機械的な指摘に従うだけで、中級者以上のコードに近づけます。
チーム開発で品質を揃えるための使いどころ
複数人で開発していると、人によってコードの書き方が大きく異なる問題が発生します。
SonarQubeの解析ルールをプロジェクトで共有すれば、誰が書いても同じような構造になります。
後から入ってきたメンバーがコードを理解するスピードを早める効果もあります。
個人のこだわりを捨て、ツールが推奨する「標準」に合わせることが、チーム全体の利益につながります。
SonarQube for IDE（旧SonarLint）でIDE連携
SonarQubeと合わせて使いたいのが「SonarLint」です。現在は「SonarQube for IDE」に名称が変わっていますが、機能は同じ無料のIDE拡張です。この記事では検索されやすい旧名のSonarLintも併記します。
VSCodeやIntelliJ IDEAのプラグインとしてインストールでき、コードを書きながらリアルタイムで警告を確認できます。
サーバーを起動しなくても動作するため、個人の開発段階でコミット前に問題を修正できます。
VSCode・IntelliJへの導入手順
- VSCode: 拡張機能マーケットプレースで「SonarQube for IDE」（旧SonarLint）を検索してインストール
- IntelliJ IDEA: Plugins → Marketplace → 「SonarQube for IDE」（旧SonarLint）を検索してインストール
インストール後は設定不要で、エディタ上に赤・黄色の下線でリアルタイム警告が表示されます。
さらに、SonarQubeサーバーの接続設定（Connected Mode）を有効にすれば、サーバー側で設定したカスタムルールをIDEでも共有できます。
チームのルールブックをIDEに持ち込める、という感覚です。
よくある質問
Q1. SonarQubeとは何ですか？
A1. ソースコードを実行せずに解析し、バグ・脆弱性・Code Smells（保守性を下げる書き方）を検出するオープンソースの静的解析ツールです。5,000以上のルールで20以上の言語に対応しています。
Q2. SonarQubeの利用は無料ですか？
A2. はい、無料版のCommunity Build（LGPL-3.0ライセンス）は商用利用も含めて無料で使えます。ただしブランチ解析やプルリクエストへの結果コメント表示など一部機能は有料版（Developer Edition以上）限定です。
Q3. Java 8のプロジェクトでもSonarQubeを使えますか？
A3. はい、使えます。SonarQubeサーバー自体の起動に必要なJavaバージョンと、解析対象プロジェクトのJavaバージョンは別物です。Maven／Gradleなら自動で設定され、手動ならsonar.java.source=1.8と指定すれば、サーバーが新しいJavaで動いていてもJava 8のプロジェクトを解析できます。
Q4. Spring BootプロジェクトでもSonarQubeを使えますか？
A4. はい、使えます。Spring BootもMaven/Gradleで管理される通常のJavaプロジェクトのため、この記事で紹介したsonar-maven-pluginまたはorg.sonarqube Gradleプラグインをそのまま追加するだけで解析できます。
Q5. SonarLintとSonarQubeの違いは何ですか？
A5. SonarQubeはサーバー型で、チーム全体の解析結果を蓄積・共有します。SonarLintはIDEにインストールするプラグインで、サーバーを起動しなくてもコードを書きながらリアルタイムで警告を確認できます。両方を組み合わせるのが基本です。
SonarQubeは品質を下げない仕組み
このツールを導入したからといって、魔法のようにすべてのバグが消え去るわけではありません。
静的解析はあくまでコードの構造を見ているだけで、実行時のデータの流れや外部システムとの連携までは完全に追えません。
論理的な矛盾や、ユーザーの要求とのズレを検知するのも苦手です。バグをゼロにするには、適切な単体テストや結合テスト、そして人の目による検証が欠かせません。
SonarQubeは、それらの活動をより効率的にするための土台に過ぎません。
それでも私が静的解析ツールを手放さないのは、「崩壊を防ぐための堤防」になることを知っているからです。
完璧を目指して疲弊するのではなく、昨日より少しだけ綺麗なコードを書く。
「H2の簡易構成のままでいいのか、PostgreSQLに切り替えるべきか」で迷う方も多いと思います。
私の目安はシンプルで、チームで継続利用するなら初日からPostgreSQL構成にしておき、個人の一時的な検証ならH2で十分というだけです。
後からPostgreSQLへ移行すると解析履歴が引き継げないため、チーム導入が前提なら最初から本番構成で始めるのが結局は近道です。
そのための良き相棒として、SonarQubeを長く使いこなしてください。
| REV. | DATE | 内容 |
|---|---|---|
| 4 | 2026-10-16 | 図解を描き直し（図面のデザインにそろえた） |
| 3 | 2026-10-14 | 一人称と言い回しの表記をそろえた |
| 2 | 2026-09-02 | 2026年9月時点の情報で全体を見直し（古い記述を6件更新） |
| 1 | 2026-02-07 | 初版 |