[{"content":"Hugo 使用ガイド 対象バージョン：Hugo v0.168.0（Extended）。コマンドは macOS/Linux のシェル例を記載。Hugo 公式ドキュメントに基づき整理。テーマ固有の非公開設定は実際のテーマリポジトリに従ってください。\n1. インストールとバージョン確認 macOS（Homebrew）：\nbrew install hugo hugo version hugo env Linux では、対応するディストリビューションのパッケージ、または Hugo 公式がリリースするバイナリを利用できます。SCSS/Sass や一部テーマのアセットパイプラインを使う場合は、インストールしたバージョンに Extended 機能が含まれているか確認してください。\n2. プロジェクトの作成 hugo new project myblog cd myblog git init 典型的なディレクトリ構成：\nmyblog/ ├── archetypes/ # 新規記事のテンプレート ├── assets/ # リソースパイプラインで処理するアセット ├── content/ # Markdown コンテンツ ├── data/ # データファイル ├── i18n/ # テーマ UI の翻訳 ├── layouts/ # カスタムテンプレート（テーマを上書き可） ├── static/ # サイトのルートへそのままコピーされる ├── themes/ # ローカルテーマ／Git サブモジュール ├── hugo.toml # サイト設定（YAML など他形式も可） └── public/ # ビルド成果物（hugo 実行後に生成） Hugo 本体にはブログ用の完成した外観テーマは付属しません。利用可能なテーマや独自レイアウトがない場合、found no layout file for \u0026quot;html\u0026quot; のような警告が出ることがあります。\n3. 既存テーマを利用する（Git サブモジュール） 以下では、Hugo 公式クイックスタートで採用されている Ananke テーマを例に説明します。\ngit submodule add https://github.com/gohugo-ananke/ananke themes/ananke hugo.toml で設定します（同じ TOML キーを重複宣言しないでください）。\nbaseURL = \u0026#39;https://example.com/\u0026#39; title = \u0026#39;My Blog\u0026#39; theme = \u0026#39;ananke\u0026#39; プレビューを起動：\nhugo server -D テーマによってメニュー、ホームページ、パラメータ、Hugo バージョン、アセットのビルド依存関係は異なります。設定を移行する際は、テーマの README とサンプルサイトを優先して参照してください。他テーマの [params] をそのまま流用しないでください。\nGit サブモジュールの運用 新しいマシンでクローン：\ngit clone --recurse-submodules \u0026lt;リポジトリ URL\u0026gt; 既存クローンでサブモジュールを補完：\ngit submodule sync --recursive git submodule update --init --recursive サブモジュールの更新（設定されたリモートブランチを追跡します。変更を確認してからコミットしてください）：\ngit submodule update --remote --merge git diff --submodule git add .gitmodules themes/ git commit -m \u0026#39;Update Hugo theme\u0026#39; サブモジュールの Git URL を移行する場合は、まず .gitmodules の url を修正し、その後 git submodule sync --recursive を実行します。CI のネットワークが不安定な場合は、アクセス可能な Git ミラーへ切り替えることもできますが、ミラーが必要なコミットオブジェクトを保持していることを確認してください。あるいは、メインリポジトリをクローンした後でサブモジュールを自前で初期化する方法もあります。\n4. 記事の作成と編集 hugo new content posts/hello-world.md 記事の例：\n--- title: \u0026#34;Hello World\u0026#34; date: 2026-10-17T12:00:00+08:00 draft: false description: \u0026#34;記事の概要\u0026#34; tags: [\u0026#34;Hugo\u0026#34;, \u0026#34;ブログ\u0026#34;] categories: [\u0026#34;技術\u0026#34;] --- 本文です。 ## 第一節 **太字**、*斜体*、[外部リンク](https://gohugo.io)。 主要フィールド：\nフィールド 用途 title タイトル date 記事の日時 draft true で下書き。デフォルトの本番ビルドでは公開されない description 概要。表示するかはテーマ次第 tags, categories 分類。詳細ページの表示はテーマ次第 slug URL 末尾をカスタマイズ（実際のパスは permalink 設定にも影響される） 注意：未来日時の記事もデフォルトでは本番ビルドに含まれないことがあります。日付、タイムゾーン、--buildFuture を確認してください。\n画像と静的ファイル サイト全体の静的ファイルは static/images/logo.png に置き、記事から次のように参照します。\n![Logo](/images/logo.png) ページバンドルを使う場合は以下の構成が可能です。\ncontent/posts/hello/ ├── index.md └── cover.jpg index.md 内に ![Cover](cover.jpg) と記述します。テーマの画像処理やサムネイル機能を使う場合は、そのテーマのページリソース規約に従う必要があります。\n5. ローカル開発とビルド hugo server # 公開済み内容をプレビュー hugo server -D # 下書きも対象 hugo server --bind 0.0.0.0 # 他デバイスからの接続を許可。ネットワークアクセス制御に注意 hugo # public/ へ出力 hugo --gc --minify # 一般的な本番ビルド hugo -d dist # dist/ へ出力 Hugo のビルドコマンドは、ビルド前に出力ディレクトリを自動で消去しません。記事の削除、URL 変更、言語切替を行うと、古いファイルが残ることがあります。任意のパスを確認なしに削除するのではなく、CI の一時ビルドディレクトリ内で生成物をクリアしてからビルドすることを推奨します。\nrm -rf public hugo --gc --minify public/ が純粋なビルド成果物であり、ユーザーデータを含まないことが確認できた場合に限り、上記の削除を実行してください。\n6. 多言語サイト 以下は中国語と英語の基本設定例です。対応する言語メニューや切替方式はテーマによって異なります。\nbaseURL = \u0026#39;https://example.com/\u0026#39; title = \u0026#39;My Blog\u0026#39; defaultContentLanguage = \u0026#39;zh-cn\u0026#39; defaultContentLanguageInSubdir = false [languages] [languages.zh-cn] languageName = \u0026#39;Simplified Chinese\u0026#39; languageCode = \u0026#39;zh-CN\u0026#39; weight = 1 title = \u0026#39;我的博客\u0026#39; [languages.en] languageName = \u0026#39;English\u0026#39; languageCode = \u0026#39;en-US\u0026#39; weight = 2 title = \u0026#39;My Blog\u0026#39; 言語ディレクトリでコンテンツを整理する一例：\ncontent/ ├── zh-cn/ │ └── posts/hello.md └── en/ └── posts/hello.md 上記の言語ディレクトリ構成を使う前に、多言語コンテンツディレクトリ設定または言語マウントと組み合わせて、コンテンツが正しく所属するか確認してください。追加マウントが不要でより簡単な方法は、同じディレクトリ内で翻訳ファイル名（hello.zh-cn.md と hello.en.md など）を使うことです。デフォルト言語の URL もプロジェクト設定に応じて配置できます。\n推奨：すでに content/posts/ が存在するサイトでは、まずファイル名サフィックス方式を採用してください。\ncontent/posts/ ├── hello.zh-cn.md └── hello.en.md 翻訳ページには一貫した translationKey を設定するとよいでしょう（ファイルパスで直接関連付けられない場合のみ必要）。多言語メニューが誤ったページを指すのを防ぎます。\n7. Markdown 内で HTML を使う Hugo はデフォルトで Goldmark を使用します。ログに Raw HTML omitted while rendering と表示される場合、Markdown 内の生の HTML は描画されていません。記事内容を信頼できる場合にのみ、hugo.toml で以下を有効化してください。\n[markup.goldmark.renderer] unsafe = true 有効化すると、記事内の埋め込み HTML が出力に含まれるようになります。内容が信頼できない投稿源から来る場合は、スクリプトインジェクションのリスクを考慮してください。\n8. Git と Gitea Actions による公開 ソースリポジトリ（.gitmodules、content/、hugo.toml 等を含む）と静的公開リポジトリ／ブランチは分離することを推奨します。CI の典型的なフロー：\npush to source main │ ▼ ソースとテーマサブモジュールを取得 │ ▼ 指定バージョンの Hugo をインストール │ ▼ 一時ビルド出力をクリアし hugo --gc --minify を実行 │ ▼ public/ のファイルを公開リポジトリの main／公開ブランチへコミット │ ▼ Caddy / Nginx が静的ディレクトリを提供 ビルドコンテナ内で以下のコマンドをまず検証できます。\ngit submodule sync --recursive git submodule update --init --recursive rm -rf public hugo --gc --minify find public -maxdepth 2 -type f | head Gitea Actions のサンプルワークフローは、act_runner のラベル、コンテナイメージ、Git 認証、権限、Hugo のインストールパス、対象ブランチに応じて個別に設定する必要があります。GITHUB_SHA や独自の COMMIT_SHA がすべてのシェルステップに自動で存在するとは限りません。set -u を用いるスクリプトでは、未定義変数がビルドを直接失敗させます。ソースコミットの値を取得するには、チェックアウト済みの Git リポジトリ内で以下を実行してください。\nSOURCE_SHA=\u0026#34;$(git rev-parse HEAD)\u0026#34; 公開対象リポジトリには別の作業ディレクトリを使用し、ソースファイルの誤削除を防ぎます。プッシュ前にブランチの non-fast-forward 衝突を確認してください。チェックなしの git push --force を一般的な公開戦略としないことを推奨します。\n9. よくあるトラブルシューティング 9.1 found no layout file for \u0026quot;html\u0026quot; 原因は通常、テーマが正しく読み込まれていない、対応テンプレートがテーマに存在しない、または設定ファイルの theme 名が themes/ ディレクトリと一致しないことです。\nls -la themes/ cat .gitmodules hugo config | grep -i theme hugo --logLevel debug テーマディレクトリ内に layouts/ などのテンプレートファイルが実際に存在するか確認し、テーマ自身の利用ガイドも確認してください。空サイトの警告を無視して解決としないでください。\n9.2 Raw HTML omitted 第 7 節に従い markup.goldmark.renderer.unsafe を確認してください。生の HTML を Markdown や Hugo ショートコードに置き換えることも検討してください。\n9.3 Git サブモジュールディレクトリが空 git submodule status --recursive git submodule update --init --recursive ネットワークエラーが報告された場合は、ホスト側だけでなく .gitmodules の URL、認証情報、ビルドコンテナ内の DNS／プロキシを確認してください。\n9.4 ページが公開されない 記事の draft、日付、公開期限、言語、対象テーマのルーティングを確認してください。以下を実行して確認できます。\nhugo list all hugo list drafts hugo list future hugo list published 9.5 CI ビルドは成功したが公開内容が変わらない public/ に期待する HTML が含まれているか、公開ブランチが更新されたか、Web ルートが最新のデプロイ先を指しているか、ブラウザ／CDN が古いコンテンツをキャッシュしていないかを確認してください。最初に Hugo のキャッシュ問題と決めつけないでください。\n10. 推奨される日常ワークフロー # 1. 更新を取得（サブモジュール含む） git pull --ff-only git submodule update --init --recursive # 2. 新規記事を作成 hugo new content posts/new-post.md # 3. 編集してローカルでプレビュー hugo server -D # 4. 記事の front matter で draft を false に変更 # 5. コミットしてプッシュ（CI が自動でビルド／公開） git add content/ git commit -m \u0026#39;Add new post\u0026#39; git push 11. 参考資料 Hugo 公式ドキュメント クイックスタート コマンドラインリファレンス 基本使用方法 Markdown レンダリング設定 Hugo Modules ","permalink":"https://blog.imcaoxuan.cn/ja/posts/2026-10-17-hugo-usage-guide/","summary":"\u003ch1 id=\"hugo-使用ガイド\"\u003eHugo 使用ガイド\u003c/h1\u003e\n\u003cblockquote\u003e\n\u003cp\u003e対象バージョン：Hugo v0.168.0（Extended）。コマンドは macOS/Linux のシェル例を記載。Hugo 公式ドキュメントに基づき整理。テーマ固有の非公開設定は実際のテーマリポジトリに従ってください。\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"1-インストールとバージョン確認\"\u003e1. インストールとバージョン確認\u003c/h2\u003e\n\u003cp\u003emacOS（Homebrew）：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-bash\" data-lang=\"bash\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ebrew install hugo\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ehugo version\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ehugo env\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eLinux では、対応するディストリビューションのパッケージ、または Hugo 公式がリリースするバイナリを利用できます。SCSS/Sass や一部テーマのアセットパイプラインを使う場合は、インストールしたバージョンに Extended 機能が含まれているか確認してください。\u003c/p\u003e\n\u003ch2 id=\"2-プロジェクトの作成\"\u003e2. プロジェクトの作成\u003c/h2\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-bash\" data-lang=\"bash\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ehugo new project myblog\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ecd myblog\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003egit init\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003e典型的なディレクトリ構成：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-text\" data-lang=\"text\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003emyblog/\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e├── archetypes/       # 新規記事のテンプレート\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e├── assets/           # リソースパイプラインで処理するアセット\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e├── content/          # Markdown コンテンツ\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e├── data/             # データファイル\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e├── i18n/             # テーマ UI の翻訳\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e├── layouts/          # カスタムテンプレート（テーマを上書き可）\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e├── static/           # サイトのルートへそのままコピーされる\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e├── themes/           # ローカルテーマ／Git サブモジュール\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e├── hugo.toml         # サイト設定（YAML など他形式も可）\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e└── public/           # ビルド成果物（hugo 実行後に生成）\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eHugo 本体にはブログ用の完成した外観テーマは付属しません。利用可能なテーマや独自レイアウトがない場合、\u003ccode\u003efound no layout file for \u0026quot;html\u0026quot;\u003c/code\u003e のような警告が出ることがあります。\u003c/p\u003e","title":"Hugo 使用ガイド"},{"content":"バイパスルーティングとして使う Armbian 上で、sing-box と WireGuard を同時に稼働させている。このルーター自身は社内ドメインを解決できるのに、その IP を DNS サーバーに指定した下流クライアントは毎回タイムアウトする。原因は DNS のマッチングルールではなく、sing-box が上位 DNS へ送るトラフィックが誤った出力インターフェースを選んでいたことにあった。\n本稿のアドレスはすべて書き換えた架空の値であり、実際のネットワーク設定ではない。プライベートネットワークのトポロジ関係とプロトコルの挙動はそのまま保持している。\nトポロジと症状 役割 例示アドレス 用途 下流クライアント 192.168.10.20 DNS クライアント バイパスルート LAN 192.168.10.254 / eth0 sing-box DNS の待ち受けアドレス バイパスルート WireGuard 10.77.0.11 / wg0 トンネルクライアント 社内 DNS 10.77.0.1:53 WireGuard ピア側の DNS トポロジは次の構成になる。\nクライアント 192.168.10.20 │ DNS クエリ ▼ バイパスルート 192.168.10.254:53 (sing-box DNS 受信) │ 期待: wg0 から 10.77.0.1:53 へ問い合わせ ▼ WireGuard ピア側 DNS 10.77.0.1:53 社内テストドメインは service.home.arpa（例示）を使用した。観測された症状は以下のとおり。\nルーター自身ではこのドメインを正常に解決できる 下流クライアントがルーターの LAN IP を明示的に DNS サーバーに指定すると、一貫してタイムアウトする sing-box は UDP 53 を待ち受けしており、対応する受信側ルーティングルールは正常と確認済み 第 1 ステップ: 受信リクエストが届いていることを確認する バイパスルート上で下流クライアントの DNS トラフィックをキャプチャする。\nsudo tcpdump -i eth0 -nn -K -l \\ \u0026#39;host 192.168.10.20 and udp port 53\u0026#39; 同じ DNS Transaction ID を持つリクエストが数秒間隔で再送されているのに、対応する成功レスポンスは確認できない。つまりクライアントは確かにクエリをルーターへ渡しており、処理チェーンは最後まで到達していない。\n待ち受けポートを確認する。\nsudo ss -lnup | grep \u0026#39;:53 \u0026#39; sing-box がバイパスルートの LAN IP 上で UDP 53 を待ち受けていることを確認できる。\n第 2 ステップ: LAN と WireGuard の出力を分けて観察する 最初からすべての DNS トラフィックを出力しないこと。ターミナルを 2 つ開き、経路ごとに分けて観察する。\n# LAN: この下流クライアントのみ sudo tcpdump -i eth0 -nn -K -l \u0026#39;host 192.168.10.20 and udp port 53\u0026#39; # WireGuard: 対象の DNS のみ sudo tcpdump -i wg0 -nn -K -l \u0026#39;host 10.77.0.1 and udp port 53\u0026#39; その後、下流クライアントから明示的なクエリを 1 回発行する。\nnslookup -type=A service.home.arpa 192.168.10.254 今回のケースでは、下流のリクエストは確かに LAN に到達したが、sing-box の DNS 上位への新規クエリは WireGuard IP ではなく LAN アドレスをソースとして eth0 から送信されていた。\n重要な区別: DNS ルールが「どの上位サーバーを選ぶか」と、OS / アプリケーションが「そのサーバーにどのインターフェースで接続するか」は別の話である。ルールが正しくヒットしていても、実際の送信経路が間違っていればリクエストはタイムアウトし得る。\n第 3 ステップ: sing-box の DNS 上位にインターフェースをバインドする 障害発生時の上位設定は次のようなものだった。\n{ \u0026#34;type\u0026#34;: \u0026#34;udp\u0026#34;, \u0026#34;tag\u0026#34;: \u0026#34;internal-dns\u0026#34;, \u0026#34;server\u0026#34;: \u0026#34;10.77.0.1\u0026#34; } 修正後は次のようになる。\n{ \u0026#34;type\u0026#34;: \u0026#34;udp\u0026#34;, \u0026#34;tag\u0026#34;: \u0026#34;internal-dns\u0026#34;, \u0026#34;server\u0026#34;: \u0026#34;10.77.0.1\u0026#34;, \u0026#34;bind_interface\u0026#34;: \u0026#34;wg0\u0026#34; } bind_interface はその DNS サーバーに対するネットワークダイヤルに作用し、指定したインターフェースを使用させる。TUN・ポリシルート・WireGuard を併用する環境では、OS の自動経路選択だけに依存するより明確になる。\n設定ファイルを確認して再起動する（自分の設定パスに合わせて変更すること）。\nsudo sing-box check -c /etc/sing-box/config.json sudo systemctl restart sing-box その後、再度クエリを行い wg0 でキャプチャする。\nsudo tcpdump -i wg0 -nn -K -l \u0026#39;host 10.77.0.1 and udp port 53\u0026#39; wg0 上でリクエストと対応するレスポンスが確認できるはずである。今回のケースでは、bind_interface を追加したおかげで下流の DNS クエリが正常に戻った。\n付随する現象: A レコードの成功後に NXDOMAIN が発生する 調査中に別の種類の症状にも遭遇した。ある社内名称が CNAME 経由で単一ラベルのホスト名に解決され、A クエリはアドレスを正常に返すが、終端ホスト名に対する AAAA クエリが NXDOMAIN を返す。これは別途切り分けて調査すべき別の名前解決の異常であり、今回の下流クエリのタイムアウトの原因とみなしてはならない。\n同種の症状に遭遇した場合は、次を個別に実行する。\ndig @\u0026lt;DNS サーバーアドレス\u0026gt; service.home.arpa A dig @\u0026lt;DNS サーバーアドレス\u0026gt; service.home.arpa AAAA そして、CNAME が意図しない単一ラベル名称を指していないか、ローカルリゾルバと上位 DNS の結果が一致しているかを確認する。\nトラブルシューティングの要点 クライアント → バイパスルート受信 → 上位への出力 → 上位レスポンス → クライアントへのレスポンス の区間ごとにパケットキャプチャする。 検証するのはパケットの実際の出力インターフェースと送信元 IPであり、DNS 設定の server フィールドだけでは判断できない。 クライアントのリクエストは受け取ったが対応するレスポンスが見えない場合は、まず上位への出力経路を確認する。すでに正常と確認済みのルーティングルールを直ちに書き換える必要はない。 tcpdump が bad udp cksum を表示した場合、ローカル送信時の NIC チェックサムオフロードの結果である可能性がある。-K を付けるとキャプチャ時のチェックサム検証を無効化できる。 home.arpa はホームネットワーク向けの専用ドメインである。実際の公開ドメイン名、デバイス名、社内アドレス、トポロジ構成をそのまま公開ブログへ載せないこと。 結論: 最終的な障害箇所は、sing-box が社内 DNS へ送る上位 UDP クエリが WireGuard を通らず LAN インターフェースから送信されていたことにある。該当する DNS 上位サーバーに bind_interface: \u0026quot;wg0\u0026quot; を設定することで解消した。\n","permalink":"https://blog.imcaoxuan.cn/ja/posts/2026-10-23-troubleshooting-dns-timeouts-on-a-bypass-router-sing-box-upstream-queries-leave-through-the-wrong-network-interface/","summary":"\u003cp\u003eバイパスルーティングとして使う Armbian 上で、sing-box と WireGuard を同時に稼働させている。このルーター自身は社内ドメインを解決できるのに、その IP を DNS サーバーに指定した下流クライアントは毎回タイムアウトする。原因は DNS のマッチングルールではなく、\u003cstrong\u003esing-box が上位 DNS へ送るトラフィックが誤った出力インターフェースを選んでいた\u003c/strong\u003eことにあった。\u003c/p\u003e\n\u003cp\u003e本稿のアドレスはすべて\u003cstrong\u003e書き換えた架空の値\u003c/strong\u003eであり、実際のネットワーク設定ではない。プライベートネットワークのトポロジ関係とプロトコルの挙動はそのまま保持している。\u003c/p\u003e\n\u003ch2 id=\"トポロジと症状\"\u003eトポロジと症状\u003c/h2\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e役割\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e例示アドレス\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e用途\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e下流クライアント\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003e192.168.10.20\u003c/code\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eDNS クライアント\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eバイパスルート LAN\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003e192.168.10.254\u003c/code\u003e / \u003ccode\u003eeth0\u003c/code\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003esing-box DNS の待ち受けアドレス\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003eバイパスルート WireGuard\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003e10.77.0.11\u003c/code\u003e / \u003ccode\u003ewg0\u003c/code\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eトンネルクライアント\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e社内 DNS\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e\u003ccode\u003e10.77.0.1:53\u003c/code\u003e\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eWireGuard ピア側の DNS\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003eトポロジは次の構成になる。\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-text\" data-lang=\"text\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eクライアント 192.168.10.20\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  │ DNS クエリ\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  ▼\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eバイパスルート 192.168.10.254:53 (sing-box DNS 受信)\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  │ 期待: wg0 から 10.77.0.1:53 へ問い合わせ\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  ▼\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eWireGuard ピア側 DNS 10.77.0.1:53\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003e社内テストドメインは \u003ccode\u003eservice.home.arpa\u003c/code\u003e（例示）を使用した。観測された症状は以下のとおり。\u003c/p\u003e","title":"バイパスルートの DNS タイムアウト調査：sing-box の上位クエリが誤った NIC から送信される問題"},{"content":"Armbian に sing-box TUN をデプロイした後、少し分かりにくい問題が発生しました：IPv6 の ping は通るのに、auto_redirect を有効化すると IPv6 の HTTPS 接続がタイムアウトする的情况です。\n调查结果、障害の原因は IPv6 の公網ルートやプロキシノードではなく、Linux のループバックインターフェース lo に ::1/128 アドレスが存在しないことでした。本稿では、その切り分け Processes .Ordinal and 修正方法を記録します。\n環境 Linux：Armbian、ARM64、6.18 系カーネル sing-box：1.14.x ネットワーク管理：Netplan + NetworkManager 透過プロキシ：TUN、auto_route: true、auto_redirect: true IPv6：上位ネットワークから自動設定され、インターフェースにはグローバル IPv6 アドレスと RA によるデフォルトルートが設定済み プライバシーを保護するため、実際の公衆アドレス、MAC アドレス、ルーターアドレス、ドメイン名、およびカスタム内部ルーティングテーブル番号は省略しています。以下の例にある ULA アドレスとテスト対象は説明용です。\n障害的现象 IPv6 HTTPS を直接テストします。\ncurl --noproxy \u0026#39;*\u0026#39; -6 -v --connect-timeout 5 \\ --resolve \u0026#39;cloudflare.com:443:[2606:4700::6810:85e5]\u0026#39; \\ https://cloudflare.com/ sing-box を有効化した後：\n* Trying [2606:4700::6810:85e5]:443... * Connection timed out after 5002 milliseconds curl: (28) Connection timed out 比較テスト：\n状態 IPv6 HTTPS sing-box 停止中 正常 auto_redirect: true タイムアウト auto_redirect: false 正常 ただし、単純な ping -6 テストは成功する場合があります。ICMP の疎通確認だけでは、TCP/HTTPS のテストを代替できません。\n切り分け Processes.Ordinal 1. IPv6 アドレスとデフォルトルートの問題を排除 ip -6 addr show dev eth0 scope global ip -6 route show default インターフェースにはすでにグローバル IPv6 アドレスがあり、デフォルトルートは RA によって学習されています。形式は次のとおりです。\ndefault via fe80::... dev eth0 proto ra NetworkManager が IPv6 を管理している場合、net.ipv6.conf.eth0.accept_ra の値だけで RA が正常に機能しているかを判断してはいけません。実際のアドレスとルートを併せて確認する必要があります。\n2. TCP が tun0 または eth0 に直接現れないことを 발견 HTTPS 対象をパケットキャプチャで確認します。\nsudo tcpdump -ni tun0 \u0026#39;ip6 and tcp port 443\u0026#39; sudo tcpdump -ni eth0 \u0026#39;ip6 and tcp port 443\u0026#39; auto_redirect を有効化している場合、想定される宛先への IPv6 TCP SYN が確認できませんでした。これは必ずパケット損失を意味しません。sing-box の nftables ルールが、TCP をまずローカルポートへリダイレクトしている可能性があります。\n3. nftables のローカル REDIRECT を確認 sudo nft -a list table inet sing-box ルールには次のような内容が存在しました。\nmeta l4proto tcp ... queue flags bypass to 100 meta l4proto tcp ... redirect to :23457 return ここでのポートは、今回の切り分け環境における内部リスニングポートです。別のバージョンや設定では異なる場合があります。IPv6 のリスニング状態を確認します。\nsudo ss -6 -lntp \u0026#39;( sport = :23457 )\u0026#39; 確かに sing-box はそのポートをリスニングしていました。\n続いてループバックインターフェースもキャプチャします。\nsudo tcpdump -ni lo -vv \u0026#39;tcp port 23457\u0026#39; このとき、重要なパケットは次の形式でした。\nIP6 2001:db8::1234.4210 \u0026gt; ::1.23457: Flags [S] IP6 2001:db8::1234.4210 \u0026gt; ::1.23457: Flags [S] IP6 2001:db8::1234.4210 \u0026gt; ::1.23457: Flags [S] 上記の 2001:db8::/32 は文書専用の IPv6 プレフィックスであり、実際の公衆アドレスではありません。\nSYN が繰り返し再送され、SYN-ACK が返っていません。これは、接続がローカル ::1 へリダイレクトされているものの、ローカル TCP ハンドシェイクが完了していないことを示しています。\n4. 根本原因を特定：ループバックインターフェースに IPv6 アドレスがない ip -6 addr show dev lo 出力は驚くほど空でした。正常な場合、ループバックインターフェースには次が存在するはずです。\ninet6 ::1/128 scope host ::1/128 が存在しないため、IPv6 TCP REDIRECT でローカル ::1 を指定しても、接続を正常に確立できませんでした。これは、繰り返し送信された SYN と SYN-ACK がない現象と一致しています。\n修正方法 まず lo の IPv6 状態を確認します。\nip link show lo sysctl net.ipv6.conf.lo.disable_ipv6 ip -6 addr show dev lo IPv6 が無効になっている場合：\nsudo sysctl -w net.ipv6.conf.lo.disable_ipv6=0 ループバックインターフェースが有効になっていることを確認します。\nsudo ip link set lo up ::1/128 がまだ表示されない場合は、手動で追加します。\nsudo ip -6 addr add ::1/128 dev lo 検証します。\nip -6 addr show dev lo ping -6 -c 2 ::1 curl --noproxy \u0026#39;*\u0026#39; -6 --connect-timeout 5 https://api6.ipify.org auto_redirect: true の状態でも HTTPS が正常であることを確認して、ようやく障害が解決したといえることになります。\n問題が再起動後に発生する場合は、/etc/sysctl.d/ に lo の IPv6 を無効化する設定が存在しないか確認し、sysctl 設定ファイルで明示的に次のように設定できます。\nnet.ipv6.conf.lo.disable_ipv6 = 0 注意点として、この設定は lo の IPv6 が無効化されていないことを保証するだけにすぎ、::1/128 が常に存在することを自動的に保証するわけではありません。再起動後にアドレスが再び消えた場合は、起動順序や lo を管理するサービスの調査を継続する必要があります。\nまとめ IPv6 の ping が成功しても、IPv6 TCP プロキシが正常であるとは限らないため、実際の HTTPS リクエストで検証する必要があります。 sing-box の auto_redirect を有効化すると、一部の TCP トラフィックが nftables によってローカルポートへリダイレクトされます。eth0 または tun0 だけをキャプチャしても、想定した宛先へのトラフィックを確認できない場合があります。 ss でリスニング状態を確認し、tcpdump -i lo で SYN の再送信 발견することが、今回の切り分けにおける鍵となりました。 最終的な障害点は、lo に IPv6 ループバックアドレス ::1/128 が欠落していたことでした。 auto_redirect を一時的に無効化すれば問題を回避できますが、今回の障害に対する本来の実質的な修正は、ループバックインターフェースを修正することです。 診断コマンド早見表 ip -6 addr show dev lo sysctl net.ipv6.conf.lo.disable_ipv6 ip -6 route show default sudo nft -a list table inet sing-box sudo ss -6 -lntp \u0026#39;( sport = :23457 )\u0026#39; sudo tcpdump -ni lo \u0026#39;tcp port 23457\u0026#39; 補足：UFW を有効化した後、下流デバイスからインターネットに接続できない問題 IPv6 のループバック問題륧解決した後、Armbian で UFW を有効化したところ、新たな現象が発生しました：Armbian 本体はネットワークへ正常にアクセスできるのに、Armbian を経由している下流デバイスからはネットワークへ正常にアクセスできないという問題です。\nまず、UFW のブロックログを確認します。\nsudo ufw logging medium sudo journalctl -k -f -o cat | grep --line-buffered \u0026#39;UFW BLOCK\u0026#39; 以下は匿名化済みの代表的なログです。IP アドレスには RFC 5737 の文書用サンプルアドレスを使用しているため、実際のネットワーク設定へそのまま転用することはできません。\n[UFW BLOCK] IN=eth0 OUT= SRC=192.0.2.20 DST=192.0.2.254 PROTO=TCP DPT=9091 SYN [UFW BLOCK] IN=eth0 OUT= SRC=192.0.2.20 DST=192.0.2.254 PROTO=TCP DPT=22703 SYN ここで OUT= が空で、宛先がローカルアドレスになっているため、これらのリクエストは通常の FORWARD ではなく、**INPUT（Armbian 本体へのアクセス）**として识别されています。之前に deny routed を直接疑っただけでは、説明が完全ではありませんでした。\n続いて、次のコマンドでリスニングプロセスを確認します。\nsudo ss -lntup | grep -E \u0026#39;:(9091|22703)\\b\u0026#39; 結果では、2 つの TCP ポートのいずれも sing-box がリスニングしており、一方は LAN の IPv4 アドレス、もう一方はワイルドカードアドレスにバインドされていました。該当する inbound ポートを許可すると、下流デバイスからインターネットへ接続 Again became possible. ただし強調すべき点があります。これはポートの到達可能性と障害が関係することを証明しますが、リスニング結果だけから、これらが TUN ポートや特定機能のものであるとは推定できません。sing-box の設定を確認して、具体的な用途を特定する必要があります。\nサービスが LAN 内でのみ使用される場合、UFW のルール在实际の LAN アドレスとサブネットに限定するようにできます。以下は RFC 5737 のサンプルサブネットを使用するルールテンプレートであり、実際の値に置き換える必要があります。\nsudo ufw allow in on eth0 from 192.0.2.0/24 to 192.0.2.254 port 9091 proto tcp sudo ufw allow in on eth0 from 192.0.2.0/24 to 192.0.2.254 port 22703 proto tcp セキュリティ上の注意：送信元を制限していない ufw allow 22703/tcp の直接実行は推奨しません。ポートがワイルドカードアドレスでリスニングされている場合には、公衆 IPv6 へ意図せず公開されていないか特に確認してください。また、下流デバイスからインターネットへ接続できない状態を解消するため、すべての routed トラフィックを恒久的にデフォルト許可にするのも 바람직하지 않습니다。\n今回の補足における切り分けの要点は、まず IN / OUT で INPUT と FORWARD を区別し、次にリスニングプロセスを確認し、最後に実際の送信元に基づいて精密に許可することです。UFW のステータスページは nft list ruleset の代替にはなりません。sing-box の auto_redirect には 별도의 nftables ルールが存在するためです。\n","permalink":"https://blog.imcaoxuan.cn/ja/posts/2026-10-23-ipv6-https-timeouts-after-enabling-sing-box-auto-redirect-on-armbian-troubleshooting-a-missing-loopback-address/","summary":"\u003cp\u003eArmbian に sing-box TUN をデプロイした後、少し分かりにくい問題が発生しました：\u003cstrong\u003eIPv6 の ping は通るのに、\u003ccode\u003eauto_redirect\u003c/code\u003e を有効化すると IPv6 の HTTPS 接続がタイムアウトする\u003c/strong\u003e的情况です。\u003c/p\u003e\n\u003cp\u003e调查结果、障害の原因は IPv6 の公網ルートやプロキシノードではなく、\u003cstrong\u003eLinux のループバックインターフェース \u003ccode\u003elo\u003c/code\u003e に \u003ccode\u003e::1/128\u003c/code\u003e アドレスが存在しないこと\u003c/strong\u003eでした。本稿では、その切り分け Processes .Ordinal and 修正方法を記録します。\u003c/p\u003e\n\u003ch2 id=\"環境\"\u003e環境\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eLinux：Armbian、ARM64、6.18 系カーネル\u003c/li\u003e\n\u003cli\u003esing-box：1.14.x\u003c/li\u003e\n\u003cli\u003eネットワーク管理：Netplan + NetworkManager\u003c/li\u003e\n\u003cli\u003e透過プロキシ：TUN、\u003ccode\u003eauto_route: true\u003c/code\u003e、\u003ccode\u003eauto_redirect: true\u003c/code\u003e\u003c/li\u003e\n\u003cli\u003eIPv6：上位ネットワークから自動設定され、インターフェースにはグローバル IPv6 アドレスと RA によるデフォルトルートが設定済み\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eプライバシーを保護するため、実際の公衆アドレス、MAC アドレス、ルーターアドレス、ドメイン名、およびカスタム内部ルーティングテーブル番号は省略しています。以下の例にある ULA アドレスとテスト対象は説明용です。\u003c/p\u003e\n\u003ch2 id=\"障害的现象\"\u003e障害的现象\u003c/h2\u003e\n\u003cp\u003eIPv6 HTTPS を直接テストします。\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-bash\" data-lang=\"bash\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ecurl --noproxy \u003cspan style=\"color:#e6db74\"\u003e\u0026#39;*\u0026#39;\u003c/span\u003e -6 -v --connect-timeout \u003cspan style=\"color:#ae81ff\"\u003e5\u003c/span\u003e \u003cspan style=\"color:#ae81ff\"\u003e\\\n\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  --resolve \u003cspan style=\"color:#e6db74\"\u003e\u0026#39;cloudflare.com:443:[2606:4700::6810:85e5]\u0026#39;\u003c/span\u003e \u003cspan style=\"color:#ae81ff\"\u003e\\\n\u003c/span\u003e\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  https://cloudflare.com/\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003esing-box を有効化した後：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-text\" data-lang=\"text\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e* Trying [2606:4700::6810:85e5]:443...\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e* Connection timed out after 5002 milliseconds\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003ecurl: (28) Connection timed out\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003e比較テスト：\u003c/p\u003e","title":"Armbian 上 sing-box 开启 auto_redirect 后 IPv6 HTTPS 超时：一次回环地址缺失的排查"},{"content":"Linux バイパスルーター上で UFW と sing-box TUN を同時に実行すると、誤診しやすい障害が発生することがあります。sing-box 自体は正常に動作しているのに、LAN 上のデバイスがバイパスルーター経由でインターネットにアクセスできない状態です。その時点で遮断されていた TCP ポートを許可したとしても、sing-box を再起動すると問題が再発することがあります。\n本稿では、実際に観察された原因と、回帰検証待ちの修復方法を記録します。例はすべて文書予約アドレスを使用し、実際のネットワークには対応していません。\n環境と症状 Linux バイパスルーター。LAN インターフェースは eth0、アドレスは 192.0.2.1（例示のみ）。 下流端末 192.0.2.20 は、IPv4 ゲートウェイとしてバイパスルーターを使用します。 sing-box の TUN インターフェース名は tun0 で、auto_route と auto_redirect を有効にしています。 UFW は既定で、許可されていない着信トラフィックを拒否します。 sing-box の主要設定：\n{ \u0026#34;type\u0026#34;: \u0026#34;tun\u0026#34;, \u0026#34;interface_name\u0026#34;: \u0026#34;tun0\u0026#34;, \u0026#34;auto_route\u0026#34;: true, \u0026#34;auto_redirect\u0026#34;: true } 障害発生中のログは次のようなものです：\n[UFW BLOCK] IN=eth0 OUT= SRC=192.0.2.20 DST=192.0.2.1 PROTO=TCP DPT=24461 SYN DPT=24461 は一度の実行で観察された動的ポートにすぎないため、UFW に固定して書き込むべきではありません。OUT= が空であることから、このパケットは FORWARD 経路を通るだけでなく、本機の INPUT 経路に入り込んでいることが示唆されます。\nNAT リダイレクトの追跡 sing-box の待ち受けを確認します：\nsudo ss -lntup | grep sing-box nftables を確認します：\nsudo nft -a list ruleset | grep -n -C 8 -E \u0026#39;redirect|tproxy\u0026#39; 障害発生時のシナリオでは、次のようなルールが見られます：\nmeta l4proto tcp redirect to :24461 # 内部端口不允许直接连接 tcp dport 24461 ct status ! dnat reject with tcp reset つまり、sing-box はまず宛先の TCP 接続を本機の待ち受けポートにリダイレクトし、その後、UFW の INPUT ルールが許可するかどうかを決定します。この種類のトラフィックを通常の FORWARD パケットとして許可しても、観察された INPUT での遮断は通常解消されません。\n修復方針：動的ポートではなく DNAT 接続にマッチさせる 明確に信頼できる単一の下流端末については、一時的に次を試せます：\nsudo iptables -I ufw-before-input 1 \\ -i eth0 \\ -s 192.0.2.20/32 \\ -d 192.0.2.1 \\ -p tcp \\ -m conntrack --ctstate DNAT \\ -j ACCEPT 例示の IP とインターフェースを実際の値に置き換えてください。DNAT は --ctstate の有効な仮想状態であり、--ctstatus ではありません。--ctstatus を使用すると Bad ctstatus \u0026quot;DNAT\u0026quot; というエラーが発生します。\nこのルールには依然として安全上の制約があります。sing-box が作成した接続だけでなく、条件を満たす DNAT TCP 接続にもマッチします。したがって、送信元と入口インターフェースを制限し、手間を省くために INPUT 全体に対する許可設定を行うべきではありません。\n検証 下流デバイスで次を実行します：\ncurl -4 -v --connect-timeout 5 https://www.cloudflare.com/ バイパスルーター側でルールのマッチ数と遮断ログを監視します：\nsudo iptables -L ufw-before-input -n -v --line-numbers sudo journalctl -k --since \u0026#39;10 minutes ago\u0026#39; --grep=\u0026#39;UFW BLOCK\u0026#39; --no-pager カウンターが増加し、インターネット接続が復旧し、さらに sing-box を再起動して内部ポートが変化した後も正常であれば、この方法が現在の環境に適していると判断できます。\n永続化 検証が成功したことを確認したら、まずバックアップを取得します：\nsudo cp -a /etc/ufw/before.rules /etc/ufw/before.rules.bak sudo nano /etc/ufw/before.rules *filter セクションで、すべてのチェーン定義の後ろ、既存の ufw-before-input 処理ルールの前に次を追加します：\n-A ufw-before-input -i eth0 -s 192.0.2.20/32 -d 192.0.2.1 -p tcp -m conntrack --ctstate DNAT -j ACCEPT チェックしてからリロードします：\nsudo iptables-restore --test \u0026lt; /etc/ufw/before.rules sudo ufw reload ロールバック時は、バックアップを使ってファイルを復元し、sudo ufw reload を実行します。一時的なテストルールも、挿入時と完全に一致するマッチングパラメータを指定して iptables -D で削除できます。\n注意事項 ufw default allow routed を直接使用したり、UFW 全体を無効にするものを長期的な解決策にしないでください。 この方法は主に IPv4 TCP リダイレクト後の INPUT 遮断を対象とするものであり、すべての UDP、IPv6、WireGuard の障害に対する汎用的な修復ではありません。 API、DNS、SOCKS など、他の明示的に設定された待ち受けポートについては、実際の用途に応じてアクセス元を引き続き制限してください。 UFW と sing-box のどちらも nftables を変更する可能性があります。ルールのマッチカウンターが増加しても接続が失敗する場合は、他のベースチェーンのフック優先度や後続の破棄ルールも確認してください。 参考文献 sing-box 公式 TUN ドキュメント iptables-extensions：conntrack マッチングの説明 ","permalink":"https://blog.imcaoxuan.cn/ja/posts/2026-10-23-troubleshooting-ufw-and-sing-box-tun-auto-redirect-conflicts/","summary":"\u003cp\u003eLinux バイパスルーター上で UFW と sing-box TUN を同時に実行すると、誤診しやすい障害が発生することがあります。sing-box 自体は正常に動作しているのに、LAN 上のデバイスがバイパスルーター経由でインターネットにアクセスできない状態です。その時点で遮断されていた TCP ポートを許可したとしても、sing-box を再起動すると問題が再発することがあります。\u003c/p\u003e\n\u003cp\u003e本稿では、実際に観察された原因と、\u003cstrong\u003e回帰検証待ちの\u003c/strong\u003e修復方法を記録します。例はすべて文書予約アドレスを使用し、実際のネットワークには対応していません。\u003c/p\u003e\n\u003ch2 id=\"環境と症状\"\u003e環境と症状\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eLinux バイパスルーター。LAN インターフェースは \u003ccode\u003eeth0\u003c/code\u003e、アドレスは \u003ccode\u003e192.0.2.1\u003c/code\u003e（例示のみ）。\u003c/li\u003e\n\u003cli\u003e下流端末 \u003ccode\u003e192.0.2.20\u003c/code\u003e は、IPv4 ゲートウェイとしてバイパスルーターを使用します。\u003c/li\u003e\n\u003cli\u003esing-box の TUN インターフェース名は \u003ccode\u003etun0\u003c/code\u003e で、\u003ccode\u003eauto_route\u003c/code\u003e と \u003ccode\u003eauto_redirect\u003c/code\u003e を有効にしています。\u003c/li\u003e\n\u003cli\u003eUFW は既定で、許可されていない着信トラフィックを拒否します。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003esing-box の主要設定：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-json\" data-lang=\"json\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e{\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  \u003cspan style=\"color:#f92672\"\u003e\u0026#34;type\u0026#34;\u003c/span\u003e: \u003cspan style=\"color:#e6db74\"\u003e\u0026#34;tun\u0026#34;\u003c/span\u003e,\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  \u003cspan style=\"color:#f92672\"\u003e\u0026#34;interface_name\u0026#34;\u003c/span\u003e: \u003cspan style=\"color:#e6db74\"\u003e\u0026#34;tun0\u0026#34;\u003c/span\u003e,\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  \u003cspan style=\"color:#f92672\"\u003e\u0026#34;auto_route\u0026#34;\u003c/span\u003e: \u003cspan style=\"color:#66d9ef\"\u003etrue\u003c/span\u003e,\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  \u003cspan style=\"color:#f92672\"\u003e\u0026#34;auto_redirect\u0026#34;\u003c/span\u003e: \u003cspan style=\"color:#66d9ef\"\u003etrue\u003c/span\u003e\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e}\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003e障害発生中のログは次のようなものです：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-text\" data-lang=\"text\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e[UFW BLOCK] IN=eth0 OUT= SRC=192.0.2.20 DST=192.0.2.1 PROTO=TCP DPT=24461 SYN\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003e\u003ccode\u003eDPT=24461\u003c/code\u003e は一度の実行で観察された動的ポートにすぎないため、\u003cstrong\u003eUFW に固定して書き込むべきではありません\u003c/strong\u003e。\u003ccode\u003eOUT=\u003c/code\u003e が空であることから、このパケットは FORWARD 経路を通るだけでなく、本機の INPUT 経路に入り込んでいることが示唆されます。\u003c/p\u003e\n\u003ch2 id=\"nat-リダイレクトの追跡\"\u003eNAT リダイレクトの追跡\u003c/h2\u003e\n\u003cp\u003esing-box の待ち受けを確認します：\u003c/p\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-bash\" data-lang=\"bash\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003esudo ss -lntup | grep sing-box\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003enftables を確認します：\u003c/p\u003e","title":"UFW と sing-box TUN auto_redirect の競合：動的ポートが遮断される問題の調査"},{"content":"CrowdSec を使って Debian サーバーで悪意ある IP を自動ブロックする 公開サーバーは毎日、さまざまな自動スキャンに遭遇します。\nサービスを意図的に公開していなくても、SSH ポートには root、admin、test などのユーザー名に対するログイン試行が日常的に届きます。Web サービスでは .env、wp-admin、phpinfo.php などのパスに対する探索が行われます。\nこれらのリクエストの多くは自動化されたスキャナによるものです。実際の侵入に至るとは限りませんが、意味のないログを大量に発生させ、サービスの露出面（attack surface）を拡大させます。\n静的なファイアウォールルールだけでは、攻撃の挙動に応じてブロック対象リストを動的に調整することが困難です。\nそこで私は CrowdSec を試してみることにしました。サーバーログから悪意ある挙動を識別し、nftables と連携して攻撃元の IP を自動的にブロックします。\n本稿では、Debian 12 への CrowdSec の導入手順と、それが「ある IP をブロックすべきかどうか」をどのように判断するかを記録します。\n1. CrowdSec とは？ CrowdSec はオープンソースの侵入検知・セキュリティレスポンスシステムです。\nSSH や Web サーバーなどが生成するログを分析し、総当たり攻撃（ブルートフォース）、脆弱性スキャン、悪意あるクローラーなどの挙動を検知します。\n従来の静的な IP ブラックリストとは異なり、CrowdSec は主に挙動の特徴に基づいてブロックすべきかどうかを判断し、コミュニティの脅威インテリジェンスも利用できます。\nCrowdSec の処理は 2 つに分かれます。\nSecurity Engine：ログを読み込み、攻撃を識別し、ブロック判定を生成します。 Remediation Component（Bouncer）：ブロック判定を実行します。たとえばファイアウォールルールを変更します。 この 2 つは互いに独立しています。\nつまり、CrowdSec の Security Engine だけを導入しても、ネットワーク接続が自動的にブロックされるわけではありません。\n1.1 処理の流れ SSH / Caddy / Nginx | v Application Logs | v CrowdSec Parser | v Detection Scenarios | v Security Alerts | v Decision Profiles | v Local API | v Firewall Bouncer | v nftables | v Block IP ログ分析とファイアウォールの実行を切り離しているため、単一サーバーでも、中央 API を通じて複数サーバーにブロック判定を配信する場合でも同じように機能します。\n1.2 CrowdSec と Fail2ban の比較 Fail2ban は Linux 上でよく使われる自動ブロックツールです。\nどちらもログから SSH の総当たり攻撃を検知できますが、設計思想には違いがあります。\n特徴 CrowdSec Fail2ban SSH 総当たり攻撃の検知 対応 対応 Web 攻撃の検知 対応 対応（通常は対応する filter が必要） コミュニティの脅威インテリジェンス 対応 通常は追加の連携が必要 分散構成 ネイティブ対応 通常は自前で連携が必要 ブロック方式 Bouncer Action 検知ルール Parser + Scenario Filter + Jail 設定の複雑さ 比較的高い 比較的低い SSH のログイン失敗だけであれば IP をブロックするだけでいいなら、Fail2ban でも十分です。\n複数の Web サービス、SSH および他のネットワークサービスをまとめて保護したい場合、CrowdSec のモジュール化されたアーキテクチャのほうが拡張の余地があります。\n2. 導入環境 本稿では次の環境を使用します。\n項目 設定 OS Debian 12 Bookworm CrowdSec 1.8.x ファイアウォール nftables インストール方法 APT 検知対象 SSH、Caddy、Nginx ブロック方式 Firewall Bouncer Docker ではなくネイティブインストールを採用します。\n主な理由は、CrowdSec がホストの systemd ジャーナルを読み取り、Bouncer を通じて OS のファイアウォールを操作する必要があるためです。ネイティブインストールなら、余分な権限、ネットワーク、マウントの設定を省けます。\n3. CrowdSec のインストール 3.1 公式 APT リポジトリを追加する まず依存パッケージをインストールします。\nsudo apt update sudo apt install -y \\ debian-archive-keyring \\ ca-certificates \\ curl \\ gnupg キーリング用ディレクトリを作成します。\nsudo install -d -m 0755 /etc/apt/keyrings CrowdSec リポジトリの署名鍵をインポートします。\ncurl -fsSL \\ https://packagecloud.io/crowdsec/crowdsec/gpgkey | sudo gpg --dearmor \\ -o /etc/apt/keyrings/crowdsec.gpg リポジトリを追加します。\necho \\ \u0026#34;deb [signed-by=/etc/apt/keyrings/crowdsec.gpg] https://packagecloud.io/crowdsec/crowdsec/any any main\u0026#34; | sudo tee /etc/apt/sources.list.d/crowdsec.list APT キャッシュを更新します。\nsudo apt update パッケージの取得元を確認します。\napt-cache policy crowdsec 公式リポジトリであることを確認したらインストールします。\nsudo apt install -y crowdsec バージョンを確認します。\nsudo cscli version サービスの状態を確認します。\nsudo systemctl status crowdsec 3.2 Firewall Bouncer をインストールする CrowdSec 自体は検知を担当するだけで、ファイアウォールでのブロックは直接行いません。\nそのため、Firewall Bouncer を別途インストールする必要があります。\n本稿では nftables を使います。\nsudo apt install -y \\ crowdsec-firewall-bouncer-nftables 自動起動を設定します。\nsudo systemctl enable --now \\ crowdsec-firewall-bouncer 状態を確認します。\nsudo systemctl status \\ crowdsec-firewall-bouncer Bouncer が CrowdSec に登録されているか確認します。\nsudo cscli bouncers list 通常は次のように表示されます。\nName Valid Type firewall-bouncer true crowdsec-firewall-bouncer 名称は例にすぎず、実際にはインストール時に自動生成されたサフィックスが付くことがあります。\nBouncer の設定ファイルは通常次の位置にあります。\n/etc/crowdsec/bouncers/crowdsec-firewall-bouncer.yaml 特に確認したいのは以下の部分です。\nmode: nftables api_url: http://127.0.0.1:8080/ 加えて API Key も含まれます。\nAPT でインストールした場合は通常 API 登録が自動的に完了するため、設定ファイル全体を直接上書きすることは推奨しません。\n4. SSH 攻撃検知の設定 SSH は公開サーバーに対する攻撃の主要な入口のひとつです。\nパスワードログインを無効化していても、有効でないユーザー名の探索や公開鍵認証の試行は大量に届きます。\n4.1 SSH Collection をインストールする CrowdSec Hub には SSH 用の検知ルールが定義済みで用意されています。\nインストールします。\nsudo cscli collections install \\ crowdsecurity/sshd 確認します。\nsudo cscli collections list Collection とは Parser と Scenario の集合であり、\nParser は SSH ログを理解する役割を担い、 Scenario は攻撃とみなせるかどうかを判定する役割を担います。 4.2 journald の設定 Debian 12 は既定で systemd を使うため、SSH ログは journald から直接取得できます。\nまず確認します。\nsudo journalctl -u ssh.service \\ -n 20 --no-pager SSH のログイン記録が表示されれば、CrowdSec に該当ログを読み取らせることができます。\nファイルを作成します。\n/etc/crowdsec/acquis.d/ssh.yaml 内容を書き込みます。\nsource: journalctl journalctl_filter: - \u0026#34;_SYSTEMD_UNIT=ssh.service\u0026#34; labels: type: syslog ここでは 2 点注意が必要です。\n第一に、journalctl_filter は実際のログフィールドに一致していなければなりません。\n第二に、type: syslog は CrowdSec に該当するログ解析フローを使用させる指定です。気軽に sshd へ変更してはいけません。\nインストール時に自動検出されたログ取得元がすでに SSH を含んでいる場合、重複して収集しないようにしてください。\n設定を検証します。\nsudo crowdsec -t サービスを再起動します。\nsudo systemctl restart crowdsec 収集状況を確認します。\nsudo cscli metrics show acquisition 新しい SSH ログイベントが発生したら、収集統計に該当する取得元が表示されるはずです。\n4.3 SSH ログ解析の検証 cscli explain を使うとログパーサーをテストできます。\n以下ではドキュメント用の予約 IP を使い、実際の攻撃元が露出しないようにしています。\nsudo cscli explain \\ --log \u0026#39;Oct 19 18:48:40 server sshd[1234]: Invalid user test from 203.0.113.10 port 51878\u0026#39; \\ --type syslog 解析に成功すれば、対応する syslog と SSH の解析フローが表示されるはずです。\n注意：cscli explain はログ解析の診断ツールです。このテストレコード 1 件のために IP がブロックされることはありません。\n5. Caddy ログ検知の設定 SSH 以外にも、CrowdSec はリバースプロキシのアクセスログから悪意ある HTTP リクエストを識別できます。\nここでは Caddy を例にします。\n5.1 Caddy Collection をインストールする sudo cscli collections install \\ crowdsecurity/caddy Nginx も利用している場合は、追加で次を導入します。\nsudo cscli collections install \\ crowdsecurity/nginx 5.2 ログ取得の設定 Caddy のアクセスログが次の場所にあると仮定します。\n/var/log/caddy/ JSON 形式です。\n作成します。\n/etc/crowdsec/acquis.d/caddy.yaml 内容は次のとおりです。\nfilenames: - /var/log/caddy/*.log labels: type: caddy CrowdSec を再起動します。\nsudo crowdsec -t sudo systemctl restart crowdsec 確認します。\nsudo cscli metrics show acquisition ログが読み取られ解析されている表示があれば、acquisitor と parser は正常に動作しています。\nただし、これでは悪意あるリクエストが実際に検知されたことを意味しません。\n5.3 CrowdSec は HTTP 攻撃をどう判断する？ CrowdSec は異なる Scenario に基づいて、次のような点を判断します。\n機密ファイルへ連続してアクセスしているか。 存在しないパスを大量に探索しているか。 既知の脆弱性を突く挙動があるか。 異常な HTTP リクエスト頻度があるか。 悪意ある HTTP クライアントの挙動特徴に一致しているか。 たとえば次のようなパスへのアクセスです。\n/.env /wp-admin/ /phpinfo.php /.git/config これらは自動スキャンでよく現れるパスです。\nただし、1 回アクセスしただけでは必ずブロックされるわけではありません。\nCrowdSec は該当する Scenario のルールを組み合わせて判断し、通常のアクセスを攻撃と誤認しないようにしています。\n6. CrowdSec はいつ IP をブロックするのか これは CrowdSec を使う上で最も理解しておくべきポイントです。\nCrowdSec は SSH のログイン失敗を 1 回検出しただけで即座にブロックするのではなく、挙動が Scenario の検知条件を満たしたときにアラートとブロック判定を生成します。\n6.1 Leaky Bucket アルゴリズム CrowdSec の多くの Scenario は Leaky Bucket（漏斗）アルゴリズムを使います。\n各 IP を個別のバケットに例えることができます。\n条件に合致する攻撃イベントごとに、バケットへ 1 単位が加わります。 バケットは設定された速度で継続的に漏れます。 イベントの蓄積が漏れる速度を上回りバケットが溢れたとき、攻撃アラートが発火します。 たとえば、仮のルールは次のようになります。\ntype: leaky capacity: 5 leakspeed: \u0026#34;10s\u0026#34; これは次を意味します。\nバケットの容量は 5 です。 10 秒ごとに 1 件のイベントが漏れます。 蓄積イベントが容量を超えたときに溢れが発火します。 攻撃者が短時間に続けてログインを試みれば、ブロックが発火する可能性があります。\n数分おきにしか試行しない場合、イベントはしきい値に到達する前に漏（leak）してしまう可能性があります。\nこれが、ある IP が複数のユーザー名を連続でスキャンしたのに、すぐにはブロックされなかった理由でもあります。\n6.2 実際の検知しきい値を確認する CrowdSec の既定のしきい値を記憶に頼って判断しないでください。\nScenario や Hub のバージョン、ローカルでカスタマイズしたルールによってパラメータは異なります。\nSSH の総当たり攻撃ルールを確認します。\nsudo cscli scenarios inspect \\ crowdsecurity/ssh-bf インストール済みのルールファイルを直接見ることもできます。\ncat /etc/crowdsec/scenarios/ssh-bf.yaml 次の項目に注目します。\ncapacity: leakspeed: groupby: distinct: それぞれの意味は次のとおりです。\ncapacity はバケットの容量を決めます。 leakspeed はイベントが解消される速さを決めます。 groupby は通常、送信元 IP でグループ化します。 distinct は同じイベントが繰り返し数えられないようにします。 したがって、CrowdSec は「10 分間に 5 回失敗したらブロック」と単純に考えることはできません。\n実際の発火条件は Scenario の完全なルールが正となります。\n6.3 ブロックはどれくらい続くのか？ CrowdSec は Alert を生成した後、Profile によってブロックの Decision を作るかどうかを決めます。\n確認します。\ncat /etc/crowdsec/profiles.yaml 一般的な IP ブロックポリシーは次のようになります。\nname: default_ip_remediation filters: - Alert.Remediation == true \u0026amp;\u0026amp; Alert.GetScope() == \u0026#34;Ip\u0026#34; decisions: - type: ban duration: 4h on_success: break ここで、\nduration: 4h はブロックが 4 時間続くことを表します。\n実際にインストールされている Profile には他の条件やポリシーが含まれている可能性があります。編集前に設定全体を確認してください。同名のルールを二重に定義しないためです。\n6.4 アラートから実際のブロックまで Scenario が発火した後も、後続の条件を満たす必要があります。\n検知シナリオが Alert を生成する。 Profile が Alert を Decision に変換する。 Firewall Bouncer が Decision を取得する。 nftables が送信元 IP をブロック用セットに追加する。 実際のファイアウォールルールがその送信元 IP に一致する。 このいずれかが失敗すると、CrowdSec 上では攻撃アラートが表示されるのに、ネットワーク接続が実際にはブロックされないという事態になり得ます。\n7. 自動ブロックが機能しているかの検証 インストールが成功しただけでは、ブロックの連鎖全体が検証できたわけではありません。\n2 つに分けるのがよいです。まずファイアウォールの実行を検証し、次に攻撃の検知を検証します。\n7.1 Bouncer を確認する sudo cscli bouncers list 以下を確認します。\nBouncer が登録されている。 API 認証が有効である。 直近でも Decision を取得している。 7.2 テスト用ブロックを作成する RFC 5737 で予約されているドキュメント用の例示 IP を使います。\nsudo cscli decisions add \\ --ip 203.0.113.10 \\ --type ban \\ --duration 5m \\ --reason manual-test Decision を確認します。\nsudo cscli decisions list 続いて nftables を確認します。\nsudo nft list ruleset | grep -i crowdsec ブロック対象の IP が該当セットに入っているか確認します。\nsudo nft list ruleset | grep \u0026#39;203.0.113.10\u0026#39; テスト IP が確認でき、そのセットが有効なファイアウォールルールから参照されていれば、Bouncer がブロック判定をファイアウォールへ同期していることになります。\nテストが終わったら解除します。\nsudo cscli decisions delete \\ --ip 203.0.113.10 なお 203.0.113.10 はドキュメント用のテストアドレスです。判定の同期確認には適していますが、実際のネットワーク接続が遮断されるかを試す用途には使えません。\n7.3 実際の攻撃アラートを確認する sudo cscli alerts list ブロック判定を確認します。\nsudo cscli decisions list Scenario のメトリクスを確認します。\nsudo cscli metrics show scenarios 特定の Scenario の Overflow カウントが増加していれば、攻撃検知ルールが発火したことになります。\nただし、ブロックが発生したかどうかは Profile、Simulation、Decision を併せて判断する必要があります。\nSimulation の状態を確認します。\nsudo cscli simulation status Scenario がシミュレーションモードにある場合、検知結果だけが生成され、ブロックが実行されないことがあります。\n7.4 自分自身の管理 IP を誤ブロックしない 公開サーバーでブロックをテストするときには、最も重要なのは唯一の管理アクセス経路を閉じてしまわないことです。\n推奨事項：\nあらかじめクラウド事業者のコンソールを用意しておく。 現在の SSH クライアントの送信元 IP を直接ブロックしない。 信頼できる固定の管理アドレスには必要な AllowList を設定する。 ポリシーを変更する前に nftables のルールの優先順位を確認する。 実際の接続テストには別の管理下にあるデバイスを使う。 8. CrowdSec は古いログを見るのか？ 既定では、CrowdSec はリアルタイムのログ解析を中心とするもので、インストール前のすべての履歴ログを起動時に自動的に走査することを保証していません。\nたとえば、CrowdSec を導入する前就已经、SSH ログには数百回のログイン失敗が記録されていることがあります。\nそのイベントは、CrowdSec をインストールしたからといってすべて現在のブロック Decision に変わるわけではありません。\n8.1 通常の運用 状況 扱い 新たに生成された SSH ログ リアルタイム検知 新たに生成された Caddy ログ リアルタイム検知 インストール前の履歴ログ 通常は自動的に遡及処理されない 古いログを再解析したい場合 Replay Mode を使う 実際に読み取りを開始する位置は、データソースとその設定にも左右されます。\n8.2 履歴の SSH ログをエクスポートする 例として過去 24 時間分をエクスポートします。\nsudo journalctl -u ssh.service \\ --since \u0026#34;24 hours ago\u0026#34; \\ --output=short \\ --no-pager \\ \u0026gt; /tmp/ssh-history.log CrowdSec は Replay Mode を通じて既存のログファイルを解析できます。\nログに含まれる元のタイムスタンプに基づいてイベントを再生し、当時の時点で検知しきい値に達していたかどうかを判断します。\nただし、Replay は API にアラートを送信する可能性があるため、本番環境で大量の履歴攻撃ログをそのまま再生するのは避けるべきです。\nより安全な方法として、独立した設定とテスト環境を使い、実際のブロック判定に影響が及ばないようにしてください。\n公式ドキュメント：\nhttps://docs.crowdsec.net/u/user_guides/replay_mode/\n9. 日々の運用管理 CrowdSec はコマンドラインツール cscli を提供しており、日常の保守はほぼターミナルで完了できます。\n9.1 サービス状態を確認する systemctl status crowdsec systemctl status crowdsec-firewall-bouncer 9.2 ログ取得状況を確認する sudo cscli metrics show acquisition 9.3 Parser のメトリクスを確認する sudo cscli metrics show parsers 9.4 Scenario のメトリクスを確認する sudo cscli metrics show scenarios 9.5 ブロック中の IP を確認する sudo cscli decisions list 9.6 手動でブロックする sudo cscli decisions add \\ --ip 203.0.113.10 \\ --duration 4h \\ --reason manual-ban 9.7 手動で解除する sudo cscli decisions delete \\ --ip 203.0.113.10 9.8 CrowdSec のログを確認する sudo journalctl -u crowdsec -f Bouncer のログも確認します。\nsudo journalctl \\ -u crowdsec-firewall-bouncer -f 9.9 ルールを更新する CrowdSec Hub のルールは個別に更新できます。\nsudo cscli hub update sudo cscli hub upgrade 検知ルールの更新は、CrowdSec ソフトウェア自体のアップグレードとは別物です。ソフトウェアの更新は引き続き APT で管理します。\n10. よくある質問 CrowdSec は動いているのに、何もブロックされない まずログ取得を確認します。\nsudo cscli metrics show acquisition 次にパーサーを確認します。\nsudo cscli metrics show parsers さらに確認します。\nsudo cscli metrics show scenarios sudo cscli alerts list sudo cscli decisions list 最後に Bouncer と nftables を確認します。\nsudo cscli bouncers list sudo nft list ruleset 正しい切り分けの順序は次のとおりです。\nLog Acquisition ↓ Parser ↓ Scenario ↓ Alert ↓ Decision ↓ Bouncer ↓ Firewall ログが正しく読み取れていることを確認する前に、ブロックのしきい値を変更したりしないでください。\n攻撃ログは多いのに、ブロックが生成されないのはなぜ？ ログの行数と、検知条件を満たすイベントの数は同じではないからです。\n一部のログは正しく解析されていない可能性がありますし、Scenario の filter に合致しない場合もあります。\nまた、同じ IP が何度もログインに失敗していても、2 つのイベントの間隔が十分に長ければ、Leaky Bucket は溢れないことがあります。\nブロック済みと表示されるのに、まだアクセスできてしまうのはなぜ？ 考えられる原因は次のとおりです。\nBouncer がまだ Decision を同期していない。 nftables のルールが、トラフィックが実際に通過する Hook に正しく接続されていない。 ファイアウォールルールの順序が正しくない。 IPv4 と IPv6 の両方をカバーできていない。 実際のトラフィックがリバースプロキシを経由しており、ログの IP が実際のクライアントアドレスではない。 遮断された接続と、いま試している接続の送信元が一致していない。 したがって cscli decisions list は CrowdSec が Decision を生成したことを示すにすぎず、それだけではネットワーク層での遮断成功を証明できません。\nCrowdSec は自動的にブロックを解除するのか？ はい。\nブロック Decision の期限が来ると、Bouncer はファイアウォールのセットを更新し、該当 IP を削除するはずです。\nただし、同じ IP が他のファイアウォールルールでもブロックされている場合、CrowdSec による解除では、それらの独立したルールまで自動的に取り除かれるわけではありません。\n11. まとめ CrowdSec の本質的な価値は、IP の自動ブロックそのものだけでなく、ログ解析・挙動検知・ブロック実行を独立したコンポーネントに分割できることにあります。\nこれにより、SSH の総当たり攻撃対策という最も基本的な用途から、Web サービス、リバースプロキシ、複数サーバーの集中防御へと段階的に拡張できます。\n実際の導入では、3 点の理解が重要です。\n第一に、CrowdSec は固定の失敗回数で直接ブロックするわけではありません。 Scenario で挙動が異常かどうかを判定し、多くのルールは Leaky Bucket アルゴリズムを使うため、攻撃の頻度と持続時間の両方が検知結果に影響します。\n第二に、検知の成功はブロックの成功を意味しません。 Alert、Decision、Bouncer、ファイアウォールルールはそれぞれ別の段階です。問題を切り分けるときは、段階を一つずつ確認してください。\n第三に、CrowdSec は継続的に発生する新たなセキュリティイベントを監視するのに向いています。 履歴の攻撃を分析したい場合は Replay Mode が使えますが、履歴のアラートが意図せず本番のブロックに影響しないよう注意が必要です。\nすでに Debian、systemd、Caddy、Nginx を使っているサーバーであれば、CrowdSec と nftables の組み合わせは検討に値する自動化されたセキュリティ対策です。\nソフトウェアの定期的な更新、危険な設定の排除、SSH の公開鍵認証、最小権限の原則を置き換えるものではありませんが、繰り返し発生する大量の自動スキャンと総当たり攻撃リクエストを削減できます。\n参考資料 CrowdSec 公式サイト CrowdSec 公式ドキュメント Linux インストールガイド Firewall Bouncer Scenario の検知メカニズム Replay Mode CrowdSec GitHub ","permalink":"https://blog.imcaoxuan.cn/ja/posts/2026-10-19-automatically-banning-malicious-ips-on-a-debian-server-with-crowdsec/","summary":"\u003ch1 id=\"crowdsec-を使って-debian-サーバーで悪意ある-ip-を自動ブロックする\"\u003eCrowdSec を使って Debian サーバーで悪意ある IP を自動ブロックする\u003c/h1\u003e\n\u003cp\u003e公開サーバーは毎日、さまざまな自動スキャンに遭遇します。\u003c/p\u003e\n\u003cp\u003eサービスを意図的に公開していなくても、SSH ポートには \u003ccode\u003eroot\u003c/code\u003e、\u003ccode\u003eadmin\u003c/code\u003e、\u003ccode\u003etest\u003c/code\u003e などのユーザー名に対するログイン試行が日常的に届きます。Web サービスでは \u003ccode\u003e.env\u003c/code\u003e、\u003ccode\u003ewp-admin\u003c/code\u003e、\u003ccode\u003ephpinfo.php\u003c/code\u003e などのパスに対する探索が行われます。\u003c/p\u003e\n\u003cp\u003eこれらのリクエストの多くは自動化されたスキャナによるものです。実際の侵入に至るとは限りませんが、意味のないログを大量に発生させ、サービスの露出面（attack surface）を拡大させます。\u003c/p\u003e\n\u003cp\u003e静的なファイアウォールルールだけでは、攻撃の挙動に応じてブロック対象リストを動的に調整することが困難です。\u003c/p\u003e\n\u003cp\u003eそこで私は \u003ca href=\"https://www.crowdsec.net/\"\u003eCrowdSec\u003c/a\u003e を試してみることにしました。サーバーログから悪意ある挙動を識別し、nftables と連携して攻撃元の IP を自動的にブロックします。\u003c/p\u003e\n\u003cp\u003e本稿では、Debian 12 への CrowdSec の導入手順と、それが「ある IP をブロックすべきかどうか」をどのように判断するかを記録します。\u003c/p\u003e\n\u003ch2 id=\"1-crowdsec-とは\"\u003e1. CrowdSec とは？\u003c/h2\u003e\n\u003cp\u003eCrowdSec はオープンソースの侵入検知・セキュリティレスポンスシステムです。\u003c/p\u003e\n\u003cp\u003eSSH や Web サーバーなどが生成するログを分析し、総当たり攻撃（ブルートフォース）、脆弱性スキャン、悪意あるクローラーなどの挙動を検知します。\u003c/p\u003e\n\u003cp\u003e従来の静的な IP ブラックリストとは異なり、CrowdSec は主に挙動の特徴に基づいてブロックすべきかどうかを判断し、コミュニティの脅威インテリジェンスも利用できます。\u003c/p\u003e\n\u003cp\u003eCrowdSec の処理は 2 つに分かれます。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eSecurity Engine\u003c/strong\u003e：ログを読み込み、攻撃を識別し、ブロック判定を生成します。\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eRemediation Component（Bouncer）\u003c/strong\u003e：ブロック判定を実行します。たとえばファイアウォールルールを変更します。\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eこの 2 つは互いに独立しています。\u003c/p\u003e\n\u003cp\u003eつまり、CrowdSec の Security Engine だけを導入しても、ネットワーク接続が自動的にブロックされるわけではありません。\u003c/p\u003e\n\u003ch3 id=\"11-処理の流れ\"\u003e1.1 処理の流れ\u003c/h3\u003e\n\u003cdiv class=\"highlight\"\u003e\u003cpre tabindex=\"0\" style=\"color:#f8f8f2;background-color:#272822;-moz-tab-size:4;-o-tab-size:4;tab-size:4;-webkit-text-size-adjust:none;\"\u003e\u003ccode class=\"language-text\" data-lang=\"text\"\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003eSSH / Caddy / Nginx\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e         |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e         v\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    Application Logs\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e         |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e         v\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e   CrowdSec Parser\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e         |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e         v\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e  Detection Scenarios\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e         |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e         v\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e    Security Alerts\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e         |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e         v\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e   Decision Profiles\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e         |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e         v\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e      Local API\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e         |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e         v\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e   Firewall Bouncer\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e         |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e         v\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e       nftables\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e         |\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e         v\n\u003c/span\u003e\u003c/span\u003e\u003cspan style=\"display:flex;\"\u003e\u003cspan\u003e      Block IP\n\u003c/span\u003e\u003c/span\u003e\u003c/code\u003e\u003c/pre\u003e\u003c/div\u003e\u003cp\u003eログ分析とファイアウォールの実行を切り離しているため、単一サーバーでも、中央 API を通じて複数サーバーにブロック判定を配信する場合でも同じように機能します。\u003c/p\u003e","title":"CrowdSec を使って Debian サーバーで悪意ある IP を自動ブロックする"},{"content":"中国の稲わら等（秸秆）焼却禁止政策の歴史は、実のところ、中国の農業現代化、農村エネルギー転換、環境ガバナンス、そして末端行政の運営方式の変遷を映す縮図である。\n最も重要な歴史的結論は次の通りである。中国は古来から大規模などんよりの焼却問題を抱えてきたわけではなく、近年になってようやく焼却を禁止し始めたわけでもない。現代の稲わら焼却禁止制度は1990年代に段階的に整備され、1999年に全国的な管理規定として形をなし、2008年前後に明らかな強化が進み、2013年以降はさらに大気汚染防止体系の中に組み込まれた。\nより深く研究に値するのは、施策の目的と執行方式との変化である。\n当初の重点は公共安全であった。 特に空港、鉄道、高速道路付近での焼却リスクであり、大気汚染への配慮は従的位置づけだった。 その後、徐々に地域的な大気质量管理へと軸足が移った。 稲わら焼却は都市のスモッグやPM2.5対策と、より緊密に政策的に結びつけられるようになった。 さらにその後は、末端行政の執行範囲拡大と管理方式の強化という問題が現れた。 一部の地域では全面焼却禁止、グリッド（網区）巡回、責任追及が行われるようになり、政策コストと農家の生産ニーズとの矛盾が生じた。 政策論争の核心は、焼却が汚染を生むかどうかではなく、どこまで禁止すべきか、そして稲わら処理の経済的コストを誰が負担するかにある。 一、歴史的タイムライン：稲わら焼却禁止が段階的に形成された経緯 20世紀80年代以前\n稲わらは利用価値を持つ農業資源であった\n主に炊事・暖房燃料、家畜飼料、家畜小屋の敷料、堆肥、建築材として用いられた。野焼きは存在したものの、大量の稲わらが無用であったわけではない。\n1980年代末〜1990年代\n大規模かつ集中的な焼却が社会問題化\n農業機械化、農村家庭燃料の転換、食糧増産、農業労働力の他産業への流出が重なり、一部の地域では稲わらが集中して余るようになり、野焼きが急速な圃場処理手段となっていった。\n1999〜2000年\n全国的な焼却禁止管理制度が確立\n1999年に6部門が『稲わら焼却禁止及び総合利用管理弁法』を公布。2000年に『大気汚染防止法』を改訂し、特定区域における稲わらの野焼き禁止を明記。\n2008年\nオリンピック大気質確保が禁焼強化を後押し\n北京・天津および周辺各省が重点時期に厳格な禁焼を実施し、都市および重点地域の管理範囲が広がった。\n2013〜2017年\nPM2.5および大気汚染防止との一体化\n大気汚染防止行動計画が全面的に推進された。2015年の『大気汚染防止法』改訂では、省政府が禁焼区域を画定すること、関連法律責任を明確にすることが規定された。\n2018年〜現在\n末端の精緻な規制と政策論争の併存\nグリッド（網区）規制、人工衛星による火点モニタリング、稲わら総合利用の推進が続く一方、一部地域では区域別・時間帯別の焼却管理も摸索されている。\n上記の段階区分は、国家レベルの重要な政策節目に基づくものであり、全国が毎年同時に変化したと見なすものではない。\n二、1949〜1980年代：なぜかつて農民は大規模集中的な稲わら焼却をほとんど必要としなかったのか 今日の禁焼政策を説明するには、まず一つの歴史的変化を理解しなければならない。\n稲わらは、かつては生産・生活の資源であったものが、次第に一部の地域で処理に費用のかかる農業副産物へと変わっていったのである。\n1. 伝統的農村社会には比較的整った稲わら利用体系があった かつての零細農経済において、稲わらには多くの実際的な用途があった。\n用途 農村の典型的な做法 生活燃料 麦わら、稲わら、トウモロコシの茎で炊事・暖房 家畜飼料 稲わらを刻み、牛・羊などの反芻動物に給与 農業用肥料 堆肥、漉き込み、家畜小屋での堆積、直接鋤き込み 生活資材 むしろ作り、わら縄作り、屋根葺き 農業補助 地表被覆、保湿、一部の土壌侵食の防止 これは、過去に焼却が存在しなかったという意味ではない。農民もまた、刈株や雑草を焼いたり、植物灰で一部の無機養分を補ったりしていた。\nしかし物資匮乏の時代には、稲わらは燃料および生産資料としての役割を持ち、まとめて廃棄物とみなされることは通常なかった。\n2. 1980年代以降の変化が決定的であった 農村経済の発展に伴い、いくつかの変化が重なった。\n第一に、農村のエネルギー構造が変化した。 石炭、液化石油气、電力、そしてその後の天然ガスが徐々に稲わらの直接燃焼に取って代わり、家庭燃料需要を減らした。\n第二に、農業生産の機械化が進んだ。 コンバインは収穫効率を高めると同時に、大量の稲わらを短時間に圃場へ集中させることとなった。\n第三に、農家の収入と就業構造が変化した。 農村労働力が非農業部門へ流出し、稲わらの収集・乾燥・輸送・保管の機会費用が高くなった。\n第四に、農業の作付体系には厳格な時間要件がある。 特に稲麦二毛作、麦玉二毛作の地域では、収穫と次作の播種の間隔が非常に短い場合がある。\nこうして農民は、経済的な選択に直面した。\n圃場は速やかに片付けなければならないが、稲わらは売れず、運び出すには金がかかる、田畑に残しておくと播種の妨げになるかもしれない。\nこうして野焼きは、一部の地域でコストが最も低く、速度が最も速い処理方法となった。\n3. 公的文書がこの転換を裏付けている 2000年6月、全国稲わら禁焼及び総合利用工作会議において、国家環境保護総局の解振華局長は、当時の推計値として以下を示した。\n全国で年間約6.5億トンの農作物稲わらが発生。 約50%が肥料および飼料として利用。 約30%が燃料および工業原料として利用。 約20%が有効利用されていない。 一部の経済発達地域や大都市近郊では、稲わらの余剰比率が70〜80%に達する場合もある。 これらの数値は当時の政府による稲わら資源利用状況の推計であり、今日のデータとして直接読み替えるべきではない。\nここから、次のような重要な結論が導かれる。\n現代中国における大規模などんわら焼却問題の多くは、農業生産効率の向上と農村伝統的資源利用体系の衰退が進む一方で、機械化された回収・貯蔵および資源化利用体系が同調して構築されなかった結果である。\n三、1990年代：稲わら禁焼が真に制度化され始める 1. 初期のガバナンスは環境配慮だけではなかった 1990年代、稲わら焼却問題はすでに政府の関心を集めており、その大きな理由の一つは交通安全であった。\n集中的な焼却は局所的に短時間で煙濃度を急上昇させ、以下のものを直接脅かす。\n民航機の離着陸時の視程 高速道路の走行安全 鉄道交通の安全 高圧送電線、山火事予防、関連施設の安全 したがって稲わら禁焼には、明らかに公共安全ガバナンスの背景がある。\n2. 1999年：最初の画期的な全国的管理文書 1999年4月12日、国家環境保護総局は、農業部、財政部、鉄道部、交通部、中国民用航空総局と共同で以下を公布した。\n『稲わら焼却禁止及び総合利用管理弁法』（環発〔1999〕98号）\nこの文書は、中国の現代稲わら禁焼史を研究する上で最も重要な一次資料の一つである。\n特に注目すべきは、1999年の管理弁法が、全国のすべての農地を一律に焼却禁止と定めた単純な規定ではなかったことである。\n第四条では、重点禁焼区域が明確に規定されていた。\n1999年規定の重点禁焼範囲 15 km 空港中心からの半径\n2 km 高速道路・鉄道の両側それぞれ\n1 km 国道・省道の両側それぞれ\n同時に高圧送電線付近、地方人民政府が法に従って画定したその他の区域を含み、自然および気候の特性に応じて各範囲の調整を認めていた。\n出典：環発〔1999〕98号第四条。\nこれは、初期の制度設計が、全国の農田すべてに対する一律全面禁止ではなく、重点区域の禁止＋地方による区域画定＋総合利用推進を組み合わせた方式であったことを示している。\nもう一つ特に注目すべき歴史的細部がある。1999年の管理弁法第八条は、禁焼区域内の違法焼却について、直接責任者に対し20元以下の罰金を科すことを認めていた。これは、当時の管理制度と後年の罰則基準との間に明らかな差異があったことを示している。\n原文書は以下から閲覧可能：生態環境部：1999年『稲わら焼却禁止及び総合利用管理弁法』。\n四、2000〜2007年：部門管理から法的な明示禁止へ 2000年に改訂された『中華人民共和国大気汚染防止法』第四十一条は、稲わら禁焼を大気汚染防止の法制度の中に正式に位置づけた。\nその重点は引き続き以下の通りであった。\n人口集中地区 空港周辺 主要交通幹線付近 当地人民政府が画定したその他の禁焼区域 この時期、稲わら禁焼は環境保護部門の専項管理から、地方人民政府が恒常的に担うべき業務へと徐々に移行していった。\nしかし禁焼効果は安定しなかった。\n2008年、環境保護部の文書は2007年5〜6月の衛星モニタリングによる火点情況を回顧して次のように示している。\n省 2007年5〜6月モニタリング火点数 河南 1,013 江蘇 592 安徽 577 山東 357 河北 280 出典：環境保護部 環発〔2008〕22号。これらは特定のモニタリング期間の衛星火点数であり、年間焼却事件の総数とは同義ではない。\nこのことは、2007年時点で禁焼制度が長年実施されてきたにもかかわらず、黄淮海（黄河・淮河・海河流域）などの主要農業生産地域では焼却が依然として普遍的であったことを示している。\n特に河南、安徽、江蘇などでは、夏収穫後、次作の農業生産を迅速に組織する必要があり、集中的焼却問題は鮮明な季節性を持っていた。\n五、2008年：北京オリンピックはなぜ重要な転換点となったのか 2008年は稲わら禁焼政策史上、きわめて明瞭な転換点であった。\n2008年4月21日、環境保護部は『稲わら禁焼工作の更なる強化に関する通知』（環発〔2008〕22号）を公布した。\n文書は、オリンピック開催都市の大気質を確保するため、以下を明確に打ち出した。\n2008年5月初旬から9月末まで、北京、天津、河北、河南、山东、山西、安徽、江蘇、遼寧の9省・市は重点禁焼区域に指定され、全面禁焼が実施された。\nこれは1999年の重点区域禁焼とは明らかに異なる。\n1. ガバナンス範囲が著しく拡大 1999年の思路は主として空港、高速道路、鉄道などの重点場所の保護にあった。\n2008年には、大気汚染の地域間伝播が政策設計にこれまで以上に影響を及ぼすようになった。\n河南や河北の一枚の農地から生じる煙が、必ずしもその農地付近だけに影響を及ぼすわけではない。気象条件が整えば、汚染物質は行政境界を越えて地域の大気質に影響を及ぼす。\nしたがって2008年の禁焼管理は、すでに地域連携防止・共同管理（联防联控）の理念を体現していた。\n2. 行政責任メカニズムがさらに強化 2008年の政策は、地方人民政府が管轄区域内の稲わら禁焼工作に対して総責任を負うことを強調し、禁焼情況を環境保護目標考核に組み込んだ。\n同時に以下が強化された。\n専項巡回・督查 衛星リモートセンシングによる火点モニタリング 違法行為の調査・処理 禁焼工作落实情況の考核と責任追及 これは、稲わら焼却が単なる農家の生産行為の問題ではなく、地方人民政府の環境ガバナンス績效の問題でもあることを意味する。\n3. 2008年には総合利用政策も打ち出された 同年、国務院弁公庁は『農作物稲わら総合利用の加速推進に関する意見』（国辦発〔2008〕105号）を印发した。\nそこでは、稲わらを資源へ転換し、利用水準を引き上げ、機械化鋤き込み、飼料化、エネルギー化などの技術発展を推進することが強調された。\n制度設計の観点から言えば、2008年には実際には並行する二つの政策路線が存在した。禁焼の拘束を強化する路線と、代替的利用方式を発展させる路線である。\n真の問題は、行政的禁止は迅速に執行できる一方、稲わら利用産業、機械設備、回収・貯蔵・輸送ネットワークは通常より長い時間を要するということである。\nこの時間差が、その後も矛盾が繰り返されてきた重要な原因となっている。\n六、2013〜2017年：スモッグ対策が稲わら禁焼の政策的位置づけを変えた 1. 2013年の大気汚染防止行動計画 2013年、中国は大気汚染ガバナンスのより高強度の段階に入った。\n2013年9月、国務院は『大気汚染防止行動計画』（国発〔2013〕37号）、通称「大気十条」を公布した。\nこれはPM2.5などの微細粒子汚染および地域的な大気質問題を、国家環境ガバナンスの重要な位置に引き上げた。\n同年、国家関連部門は稲わら総合利用および禁焼工作を推進した。環境保護部は2013年冬季の大気汚染防止通知において、「一把の火も起こさず、一筋の煙も出さない」という厳格な執行要求まで打ち出した。\nただし、区別すべきは、こうした業務要求は、全国のすべての農地が法律上一律に禁焼区域に画定されていることを意味するものではないということである。\n2. 衛星モニタリングが稲わら禁焼を考核可能にした 2008年以前にも衛星リモートセンシング・モニタリングは用いられていた。環境保護部の後の答弁によれば、2009年から全国の夏秋収穫期間中に、常態的な火点衛星モニタリングと日報公開のメカニズムが構築された。2014年には月報、火点強度ランキング、情報公開がさらに強化された。\nこれは地方政府の管理方式に大きな影響を及ぼした。\n従来、圃場での焼却は分散的な農業行為であり、上級部門が各地域の情況を持続的に把握することは困難であった。\n衛星リモートセンシングにより、火点は位置特定可能、集計可能、比較可能となった。\n行政管理ロジックの変化\n農民が圃場で焼却\n衛星による火点モニタリング、地方による検証\n行政区域別の統計、通報、ランキング\n地方政府が責任分解、巡回、考核を強化\nこの制度には明らかな利点がある。環境違法行為の発見効率が向上する。\nしかし潜在的な問題もある。もし考核が火点の数に過度に依存するならば、地方は「火点を出さないこと」により関心を持ち、稲わらが実際に有効に処理されているかには関心が薄くなるかもしれない。\n後者は行政的インセンティブ・メカニズムに基づく分析であり、これによってすべての地域にそのような歪みがあると推論することはできない。\n3. 実際のモニタリングデータに明らかな変化が現れる 環境保護部が2015年に開示したデータによれば、\n2013年の数値は、公式に公表された2014年の5,034件（前年比2,844件の減少）から逆算したものである。\n2013〜2014年 前年比減少\n36.3% 統計は当時の衛星リモートセンシングと検証の口径によるものである。モニタリングされた火点の減少は、それだけでは、その減少がすべて禁焼政策によるものであることを証明するものではなく、PM2.5の改善割合を直接算出することもできない。\n4. 2015年『大気汚染防止法』改訂 2015年に改訂、2016年から施行された『大気汚染防止法』はさらに以下の点を明確化した。\n第76条：稲わらの資源化利用を奨励・支援し、回収・貯蔵・輸送・利用サービス体系の整備を定める。 第77条：省政府が野焼き禁止区域を画定する。 第119条：違法焼却行為に対する行政処罰を規定。 このうち第119条は、規定情形下における稲わらの野焼きについて、500〜2,000元の罰金範囲を明確に定めている。その具体的な適用は、違法地点と当時の法律条文を踏まえて判断する必要がある。\n1999年管理弁法の20元以下という罰金と比較すると、法的拘束が明らかに強化されていることがわかる。\n七、2018〜2024年：全面禁焼、グリッド化管理、末端ガバナンスの矛盾 2018年、国務院は『青空防衛戦三年行動計画』を公布した。\n文書は特に以下を要求した。\n地方政府の禁焼主体責任を強化 重点区域でグリード化（網区化）管理制度を確立 夏秋収穫期間に専項巡回を実施 東北地区では集中的焼却を対象とした専項方案を制定 遮断と疎通の結合、坚持し、2020年までに全国の稲わら総合利用率を85%に到達させる 注意すべきは、文書が東北地区に対し科学的に秩序だった疎通を強化することも明確に求めており、中央レベルの政策が常に無差別にすべての焼却を禁止することを主張していたわけではないことを示している点である。\n1. なぜ一部の地域ではより厳格な全面禁焼を採用したのか 三つの側面から説明できる。\n行政執行コスト： 区域別・時間帯別の管理には、地理的位置、気象条件、焼却規模、汚染拡散方向の分析が必要であり、管理の複雑性が高い。\n責任考核のプレッシャー： 末端管理者にとって、すべての田畑の火点を厳格に禁止する方が、個々の焼却のリスクが制御可能であることを示すよりも、運用しやすいことが多い。\n農業代替方案の不足： 稲わらの回収・貯蔵および総合利用がまだ十分に整備されていない段階では、焼却禁止は直ちに執行できる政策ツールとなる。\nこれらの要因が相まって、一部の地域における全域禁焼、巡回、定点值班などの措置を促した。\nただし、区別すべきは、地方の禁焼区域画定、巡回管理、行政処罰は、それぞれ相応の法律根拠と法定権限に合致している必要があるということであり、末端の宣伝スローガンをそのまま全国統一の法律と見なすことはできない。\n2. 矛盾は東北地区で特に顕著 東北は全国で最も典型的な地域の一つである。\n黄淮海の夏収穫地域と比べ、東北は冬が寒い、春の土壌解凍が遅い、稲わらの分解が比較的遅い、圃場面積が大きいといった条件にも直面している。\n稲わらの鋤き込みには、土壌を保全し有機物を増やすという価値があるが、もし機械作業、稲わら量、土壌水分、耕種体系が整合しなければ、次作の播種や出芽に影響する可能性もある。\n2024年、『半月談』の報道は、東北の一部地域が直面する現実的な困境として、稲わらの圃場外搬出コストが高い、鋤き込み後の腐熟が不十分、末端巡回の投入が大きいといった問題を指摘している。\nこうした報道は地方ガバナンスが直面する実際の困難を反映しているが、個別の農家が病虫害の変化を観察したからといって、稲わらの鋤き込みが一般的に病虫害を悪化させると直ちに証明することはできない。\n3. この矛盾は四種類のコストに整理できる コストの種類 主たる負担者 典型的な問題 大気汚染と健康被害 農村と都市の住民 野焼きが煙塵を放出し、地域汚染を形成 稲わら処理コスト 農家、合作社 粉砕、ベール化、輸送、鋤き込みに投入が必要 末端規制コスト 地方政府 巡回、值班、検証、執法が資源を占有 資源化産業コスト 企業と財政 回収・貯蔵・輸送ネットワーク、生産設備、安定市場 政策衝突の本質は次の通りである。焼却禁止は一部の社会的環境コストを下げることはできるが、稲わら処理コストを自動的に除去するわけではなく、他の方法でこれらのコストを負担することが求められる。\nもし後続の処理方式が経済的でないなら、禁焼は高強度の行政監督に依拠して長期的に維持される可能性がある。\n八、2025年：政策が「一刀両断」的問題を明確に是正し始める 2025年は、中国の稲わら禁焼政策史におけるもう一つの重要な転換点である。\n2025年中央一号文書『中共中央 国務院 農村の改革をさらに深化させ、田村全面的振興を着実に推進することに関する意見』は、以下を明確に打ち出した。\n稲わらの総合利用を支援し、禁焼範囲を精確に画定し、法に従って規制通りに禁焼管理要求を落实する。\nここで最も注目すべきは、「稲わら利用を支援」ではない（それは長年繰り返されてきたからである）。注目すべきは、禁焼範囲を精確に画定する、という点である。\nこれは、国家政策のレベルにおいて、大気環境、農業生産、ガバナンスコストを両立させ、全域全面禁焼で科学的管理を代替することを避ける方向への、より明瞭な要求を意味する。\n二つの代表的な地方政策変化 吉林：全域禁焼から計画焼却へ\n吉林省生態環境庁が2025年に公開した答弁で確認されたところによれば、当地は2018年以降、「二区」管理や全域禁焼など異なる方式を実施してきたが、2023年秋に稲わらおよび刈株の計画焼除（計画的焼却）に再調整された。\n2024年にはさらに、総合利用を優先とする基礎の上に、一部の余剰稲わらと機械化作業が困難な圃場について、適切な条件下で計画焼除を組織することが明確化された。\n湖南：禁焼区と限焼区の分類管理を実施\n2025年6月、湖南省は『稲わら禁焼区及び限焼区画定方案』を公布し、地理環境、汚染拡散特性、圃場情況に基づき、区域別・類別・級別・時間帯別での管理を強調した。\n方案は、単純な「一刀両断」式の禁止を防止することを明確に打ち出したが、これは限焼区内であればいつでも任意に焼却してよいという意味ではない。\nこうした地方政策の変化は、全国に完全同步で完全に一致した稲わら焼却管理模式が存在しないことを示している。\n実際、1999年の重点区域管理の思路、その後のいくつかの地域の全域禁焼実践、そして2025年の精確な区域画定要求は、一本の明瞭な政策進化の軌跡をなしている。\n九、2026年：生態環境法典が法体系を正式に変更する 2026年10月時点で、稲わら禁焼の歴史を研究するうえで無視できない最新の節目がこれである。\n2026年3月12日、全国人民代表大会は『中華人民共和国生態環境法典』を可決し、2026年8月15日から施行された。旧『大気汚染防止法』などの法律は同時に廃止され、関連制度は法典に引き継がれ調整された。\n法典第二百四十六条は、地方人民政府が稲わら等の焼却について科学的に精確に組織・指導・管理を強化すべきことを明確に規定し、同時に人口集中地区、空港周辺、交通幹線付近、省政府以上の人民政府が画定したその他の区域および規定時間帯における禁焼要求を明確にしている。\n第一千百三十一条は、違法構成要件に合致する焼却行為について、500〜2,000元の罰金を科すことを定めている。\n全国人大常委会法制工作委員会の責任者のこの改正に関する説明が特に重要である。すなわち、従来の簡素化・一刀両断の問題に対応し、重点区域での焼却禁止を明確化しつつ、その他の区域での禁焼画定をより規範化することを求めている。\n三つの時期における法理念の対比 時期 主要な法律・政策思路 1999〜2007 重点区域禁焼、地方による区域画定管理、総合利用を奨励 2008〜2024 地域大気質考核が強化、一部の地域で全域禁焼を実施 2025〜2026 精確な区域画定、依法管控、因地制宜で限焼・計画焼除を模索 2026年8月、吉林は新しい総合利用政策を打ち出し、一部の道路、空港周辺、林地付近などを禁焼区と明確に画定し、その他の区域は限焼管理とし、稲わらの鋤き込み、圃場外利用などの措置を配套した。これは新たな法体系が地方で落实される具体的な事例である。\n強調すべきは、2026年の政策調整は全国規模での稲わら焼却自由化ではない、ということである。ある禁焼区域内にいないからといって、無条件に火をつけてよいわけではない。地方政府が法に従って制定した時間帯、組織管理、消防安全などの要求を遵守する必要がある。\n十、稲わら禁焼にはそもそも科学的な根拠があるのか この問題は、環境汚染、農業生産、ガバナンスコストを分けて判断する必要がある。\n1. 稲わらの野焼きは実際に顕著な大気汚染を生む 燃焼過程において、稲わらはPM2.5、一酸化炭素、窒素酸化物、揮発性有機化合物、黒色炭素などの汚染物質を放出する。\n2015年に『Atmospheric Environment』に掲載された研究は、中国東部での圃場における稲わら焼却の実地測定を行い、作物の種類によって差はあるものの、稲わらの野焼きが粒子状物質および多様な気体汚染物質を放出することを確認した。\nしかし、このことから中国全体のスモッグの主因が稲わら焼却であるとは即断できない。\n定量研究の一例として：\n河北省の稲わら焼却による京津冀PM2.5への寄与シミュレーション 2014年の排出インベントリおよび大気モデルに基づく\n6月の月平均寄与割合\n4.2% 10月の月平均寄与割合\n5.5% 研究では、特定の汚染日において、河北省の稲わら焼却が北京市のPM2.5日平均濃度に対して最大25.7%まで寄与することが示された。\nこれは、京津冀地域における特定年・特定月・特定汚染日の河北省焼却源のシミュレーション結果であり、全国平均の寄与率ではない。また、すべての重度汚染天気を代表するものでもない。\nこのことは、稲わら焼却が通年で常に最も主要な汚染源であるとは限らないが、収穫期、大規模かつ集中的な焼却と不利な気象条件が重なる時には、実際に地域的大気汚染の重要な駆動要因となり得ることを示している。\n2. 焼却は農業的に全くの無意味というわけではない 従来、農民が焼却で圃場を片づけてきたのは明確な実際的理由があったからである。\n焼却は地表の残さを速やかに除去し、ある条件下では一部の雑草種子や病害虫のキャリアを減少させる。灰はカリウム、カルシウムなどの一部の無機成分を保持する。\nしかし同時に、燃焼は大量の有機炭素と一部の養分を失わせ、汚染物質を放出し、表層の土壌環境を損なう可能性がある。\nこれに対し、科学的な鋤き込みは土壌有機物のインプットを増やし得るが、分解過程、病虫害リスク、播種効果は具体的な土壌・気候・作業条件に依存する。\nしたがって、両極端な主張はいずれも正確ではない。\n「稲わら焼却は環境と土地に全く危害を加えない」 「稲わらをすべて圃場に鋤き込めば、どの地域でも必ず他の処理方式より優れている」 農業科学院系の関連研究のレビューでは、稲わら鋤き込みの長期的土壌便益と、分解の遅さ、病虫害、作物生育への影響などの適用性問題が既に明確に論じられている。\n十一、禁焼政策は経済的に何を変化させたのか 見過ごされがちな点は、稲わら禁焼が大気に影響を及ぼすだけでなく、農業経営コストを変え、さらに農地流動化や機械化投資にも影響を及ぼすということである。\n2026年に『Journal of Agricultural Economics』に掲載された研究は、2009〜2015年の農村家計パネルデータを用いて、省ごとに厳格な禁焼政策の施行時期に差があることを利用した分析を行った。\n研究によれば、その識別条件とサンプル範囲内において、禁焼政策は村内の農地流動化を促進し、生産効率の高い農家は経営面積を拡大し、効率の低い農家は一部の土地経営から退出する傾向があった。研究では、サンプル村レベルでの農業総産出と生産性がそれぞれ約5%と約3%上昇したと推計された。\n研究ではまた、近くにバイオマス発電所がある村では、禁焼後の農地流動化と生産調整がより顕著であったことが示された。\nここから、より複雑な結論が得られる。\n禁焼政策は、規模の農業化を同時に推進する可能性がある一方、資金、機械、労働力を持たない零細農家に対しては、相対的により大きな負担を強いる可能性がある。\n上記の5%と3%という数値は、特定のサンプルと計量モデルによる推計結果であり、全国・全年度の禁焼政策の確定的な効果として扱ってはならない。また、農家個人の所得増加と直接同義でもない。\n全国の稲わら総合利用はどの水準に達しているのか 農業農村部の公表データによれば、2024年時点で、\n稲わら総量\n8.7億トン 回収可能量\n7.3億トン 回収可能稲わらの総合利用率\n88%以上 統計の口径は回収可能稲わらの総合利用率であり、稲わら総産出量に対する直接利用率ではない。\n長年の発展を経て、中国は肥料化・飼料化を主体とし、能源化、基料化、原料化を補助とする利用格局を形成してきた。\nしかし総合利用率は、考核すべき唯一の指標ではない。処理コスト、実際の利用品質、長期的土壌便益、そして関連産業が継続的な高額補助なしでも維持可能かどうかも併せて判断する必要がある。\n十二、総合評価：この歴史は何を物語るか 公共政策史の観点から、中国の稲わら禁焼は三つの注目すべき転換を経験してきた。\n1. 資源利用問題から環境ガバナンス問題へ 初期の政府は稲わらをどう利用するかにより関心を持っていた。1990年代以降、集中した野焼きによる汚染と公共安全リスクがますます顕在化し、禁焼は次第に独立した重要な政策目標となっていった。\n1998年の一つの歴史的ニュースがとくに代表的である。\n1998年5月19日付の『人民日報』の報道によれば、成都双流空港は付近の農民の稲わら焼却による濃煙のため、24時間以内に3回の閉鎖を余儀なくされ、17便が遅延、引き返し、または代替着陸を強いられた。報道はまた、1996年から同空港で3年連続して類似の事件が発生していたことを指摘している。\nこうした事案は、なぜ1999年の最初の全国的管理規定が、空港および主要交通幹線付近の禁焼を特に強調したのかを具体的に説明する。\n2. 個別汚染への対応から、行政区域全体への考核へ 1999年は主として重点区域の管理であった。\n2008年には、より広範な地域連携防止・共同管理要求が示された。\n2013年以降、モニタリング、ランキング、目標考核、末端責任メカニズムが不断に強化された。\n公共ガバナンス問題が考核可能な指標へと転換されると、確かに執行効率は向上し得るが、同時に指標の単純化というリスクももたらす。\nしたがって稲わら禁焼の歴史は、典型的な行政管理研究上の価値を持っている。すなわち、政策目標が合理的であることは、すべての執行方法が合理的であることを意味しない。\n3. 単なる禁止から、農業経済规律への再重視へ 稲わらは作物生産の必然的な副産物である。\n農民は行政的禁令によって稲わら生産を止めるわけではない。鋤き込み、回収・貯蔵、その他の利用方式が実際の生産の中で実行可能となった時にのみ、野焼きの経済的動機は持続的に低下する。\nこれは、2025〜2026年の政策がより一層精確な区域画定、科学的管理、総合利用を重視するようになった深い理由でもある。\n国際経験に鑑みれば、アメリカ、イギリス、カナダなどの国々もまた、許可制、スモーク管理計画、特定区域・時間帯の制限などを使って農業焼却を管理してきた。全面禁止と全面自由化の二者択一を単純に選んできたわけではない。\n最終結論 約30年にわたる中国の稲わら禁焼史を合わせて眺めると、以下の判断が導かれる。\n第一に、禁焼は凭空から生まれた政策ではない。 現実の汚染防止と公共安全の基盤があり、特に1990年代の稲わら焼却の煙による空港影響事例がその根拠となっている。\n第二に、禁焼範囲の強化は段階的に発生した。 1999年に全国的な重点区域管理制度が確立され、2008年にオリンピック期間中の全面禁焼が強化され、2013年以降は大気汚染防止体系の下で考核がさらに強化された。地方の執行には明らかな差異がある。\n第三に、全面禁止と合理的な禁止は同義ではない。 高リスク区域の厳格な管理には十分な根拠があるが、すべての農地をいかなる条件下でも焼却禁止とすることは、農業生産、ガバナンスコスト、代替技術、法律授権を等しく考慮する必要がある。\n第四に、2025〜2026年の政策調整は実質的な歴史的意義を持つ。 それは従来の禁焼目標を否定するものではなく、環境保護と公共安全の制約を保持しつつ、長年存在した執行の硬直化問題をより明確に解決し始めている。\n最終的に、この歴史の核心は次のように要約できる。\n中国の稲わら禁焼政策は、「重点区域の禁止」から、「一部地域の全面禁焼」を経て、「法に基づく精確な区域画定、総合利用優先、科学的に秩序だった管理」へと進展してきた。それが映しているのは単なる環境政策の変化ではなく、行政管理が農業生産の规律に徐々に適応していく過程でもある。\n研究をさらに深めるのであれば、私自身が最も個別研究に値すると考えるのは、2008〜2015年の期間、すなわち中央政策、地方立法、衛星火点考核、末端禁焼執行がどのように相互に作用したかである。これは、一部の地域がなぜ初期の区域管理から全域禁焼に向かい、その後なぜ政策を再調整したのかを理解する上での鍵となる時期である。\n","permalink":"https://blog.imcaoxuan.cn/ja/posts/2026-10-17-the-history-of-china-s-straw-burning-ban-policy-from-traditional-farming-to-modern-environmental-governance/","summary":"\u003cp\u003e中国の稲わら等（秸秆）焼却禁止政策の歴史は、実のところ、中国の農業現代化、農村エネルギー転換、環境ガバナンス、そして末端行政の運営方式の変遷を映す縮図である。\u003c/p\u003e\n\u003cp\u003e最も重要な歴史的結論は次の通りである。中国は古来から大規模などんよりの焼却問題を抱えてきたわけではなく、近年になってようやく焼却を禁止し始めたわけでもない。現代の稲わら焼却禁止制度は1990年代に段階的に整備され、1999年に全国的な管理規定として形をなし、2008年前後に明らかな強化が進み、2013年以降はさらに大気汚染防止体系の中に組み込まれた。\u003c/p\u003e\n\u003cp\u003eより深く研究に値するのは、施策の目的と執行方式との変化である。\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e当初の重点は公共安全であった。 特に空港、鉄道、高速道路付近での焼却リスクであり、大気汚染への配慮は従的位置づけだった。\u003c/li\u003e\n\u003cli\u003eその後、徐々に地域的な大気质量管理へと軸足が移った。 稲わら焼却は都市のスモッグやPM2.5対策と、より緊密に政策的に結びつけられるようになった。\u003c/li\u003e\n\u003cli\u003eさらにその後は、末端行政の執行範囲拡大と管理方式の強化という問題が現れた。 一部の地域では全面焼却禁止、グリッド（網区）巡回、責任追及が行われるようになり、政策コストと農家の生産ニーズとの矛盾が生じた。\u003c/li\u003e\n\u003cli\u003e政策論争の核心は、焼却が汚染を生むかどうかではなく、どこまで禁止すべきか、そして稲わら処理の経済的コストを誰が負担するかにある。\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"一歴史的タイムライン稲わら焼却禁止が段階的に形成された経緯\"\u003e一、歴史的タイムライン：稲わら焼却禁止が段階的に形成された経緯\u003c/h2\u003e\n\u003cp\u003e\u003cimg alt=\"50〜60年前の泉州市の子どもたちの課外任務 ―泉州網｜泉州晩報社 泉州ニュースポータル\" loading=\"lazy\" src=\"https://blog-images.imcaoxuan.cn/2026/10/17/1792229387.jpeg\"\u003e\u003c/p\u003e\n\u003cp\u003e20世紀80年代以前\u003c/p\u003e\n\u003cp\u003e稲わらは利用価値を持つ農業資源であった\u003c/p\u003e\n\u003cp\u003e主に炊事・暖房燃料、家畜飼料、家畜小屋の敷料、堆肥、建築材として用いられた。野焼きは存在したものの、大量の稲わらが無用であったわけではない。\u003c/p\u003e\n\u003cp\u003e\u003cimg alt=\"CHINA-AGRICULTURE-HARVEST3\" loading=\"lazy\" src=\"https://blog-images.imcaoxuan.cn/2026/10/17/1792229401.jpeg\"\u003e\u003c/p\u003e\n\u003cp\u003e1980年代末〜1990年代\u003c/p\u003e\n\u003cp\u003e大規模かつ集中的な焼却が社会問題化\u003c/p\u003e\n\u003cp\u003e農業機械化、農村家庭燃料の転換、食糧増産、農業労働力の他産業への流出が重なり、一部の地域では稲わらが集中して余るようになり、野焼きが急速な圃場処理手段となっていった。\u003c/p\u003e\n\u003cp\u003e\u003cimg alt=\"CHINA-HEALTH-ENVIRONMENT-POLLUTION\" loading=\"lazy\" src=\"https://blog-images.imcaoxuan.cn/2026/10/17/1792229413.jpeg\"\u003e\u003c/p\u003e\n\u003cp\u003e1999〜2000年\u003c/p\u003e\n\u003cp\u003e全国的な焼却禁止管理制度が確立\u003c/p\u003e\n\u003cp\u003e1999年に6部門が『稲わら焼却禁止及び総合利用管理弁法』を公布。2000年に『大気汚染防止法』を改訂し、特定区域における稲わらの野焼き禁止を明記。\u003c/p\u003e\n\u003cp\u003e\u003cimg alt=\"This aerial picture shows the National S\" loading=\"lazy\" src=\"https://blog-images.imcaoxuan.cn/2026/10/17/1792229422.jpeg\"\u003e\u003c/p\u003e\n\u003cp\u003e2008年\u003c/p\u003e\n\u003cp\u003eオリンピック大気質確保が禁焼強化を後押し\u003c/p\u003e\n\u003cp\u003e北京・天津および周辺各省が重点時期に厳格な禁焼を実施し、都市および重点地域の管理範囲が広がった。\u003c/p\u003e\n\u003cp\u003e\u003cimg alt=\"天安門、2014年1月、汚染の下 ―Tiananmen sous la pollution, Pékin, janvier 2014 - Espace mondial : l\u0026rsquo;Atlas\" loading=\"lazy\" src=\"https://blog-images.imcaoxuan.cn/2026/10/17/1792229431.jpeg\"\u003e\u003c/p\u003e\n\u003cp\u003e2013〜2017年\u003c/p\u003e\n\u003cp\u003ePM2.5および大気汚染防止との一体化\u003c/p\u003e\n\u003cp\u003e大気汚染防止行動計画が全面的に推進された。2015年の『大気汚染防止法』改訂では、省政府が禁焼区域を画定すること、関連法律責任を明確にすることが規定された。\u003c/p\u003e\n\u003cp\u003e\u003cimg alt=\"一読でわかる ―稲わらが燃やせない理由\" loading=\"lazy\" src=\"https://blog-images.imcaoxuan.cn/2026/10/17/1792229439.jpeg\"\u003e\u003c/p\u003e\n\u003cp\u003e2018年〜現在\u003c/p\u003e\n\u003cp\u003e末端の精緻な規制と政策論争の併存\u003c/p\u003e\n\u003cp\u003eグリッド（網区）規制、人工衛星による火点モニタリング、稲わら総合利用の推進が続く一方、一部地域では区域別・時間帯別の焼却管理も摸索されている。\u003c/p\u003e\n\u003cp\u003e上記の段階区分は、国家レベルの重要な政策節目に基づくものであり、全国が毎年同時に変化したと見なすものではない。\u003c/p\u003e\n\u003ch2 id=\"二19491980年代なぜかつて農民は大規模集中的な稲わら焼却をほとんど必要としなかったのか\"\u003e二、1949〜1980年代：なぜかつて農民は大規模集中的な稲わら焼却をほとんど必要としなかったのか\u003c/h2\u003e\n\u003cp\u003e今日の禁焼政策を説明するには、まず一つの歴史的変化を理解しなければならない。\u003c/p\u003e\n\u003cp\u003e稲わらは、かつては生産・生活の資源であったものが、次第に一部の地域で処理に費用のかかる農業副産物へと変わっていったのである。\u003c/p\u003e\n\u003ch3 id=\"1-伝統的農村社会には比較的整った稲わら利用体系があった\"\u003e1. 伝統的農村社会には比較的整った稲わら利用体系があった\u003c/h3\u003e\n\u003cp\u003eかつての零細農経済において、稲わらには多くの実際的な用途があった。\u003c/p\u003e\n\u003ctable\u003e\n\t\u003cthead\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003cth\u003e用途\u003c/th\u003e\n\t\t\t\t\t\u003cth\u003e農村の典型的な做法\u003c/th\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/thead\u003e\n\t\u003ctbody\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e生活燃料\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e麦わら、稲わら、トウモロコシの茎で炊事・暖房\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e家畜飼料\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e稲わらを刻み、牛・羊などの反芻動物に給与\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e農業用肥料\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e堆肥、漉き込み、家畜小屋での堆積、直接鋤き込み\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e生活資材\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003eむしろ作り、わら縄作り、屋根葺き\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\t\t\u003ctr\u003e\n\t\t\t\t\t\u003ctd\u003e農業補助\u003c/td\u003e\n\t\t\t\t\t\u003ctd\u003e地表被覆、保湿、一部の土壌侵食の防止\u003c/td\u003e\n\t\t\t\u003c/tr\u003e\n\t\u003c/tbody\u003e\n\u003c/table\u003e\n\u003cp\u003eこれは、過去に焼却が存在しなかったという意味ではない。農民もまた、刈株や雑草を焼いたり、植物灰で一部の無機養分を補ったりしていた。\u003c/p\u003e","title":"中国の稲わら等焼却禁止政策の歴史：伝統的農耕から現代の環境ガバナンスへ"},{"content":"1999年、中国は重点区域を中心とする稲わら焼却禁止管理制度を整備した。空港周辺、主要交通幹線付近、人口集中地区が重点管理対象とされた。ところが2010年代になると、一部の省は全省行政区域に対して厳格な禁焼を実施し始めた。\nなぜ、当初は重点区域管理を中心としていた政策が、段階的に一部の地域の全域禁焼へと向かったのか？\nその答えは単純に「大気汚染が深刻化したから」とは言えない。2008〜2015年の政策文書を整理するとわかるのは、禁焼範囲の拡大、地方責任の強化、衛星リモートセンシングの普及、そして財政補助金と行政考核の組み合わせが、稲わら禁焼のガバナンス方式を共に変えたということである。\n特に注目すべきは、江蘇省は早くも2009年に、2012年末までに全省行政区域での野焼き禁止を実現する目標を提示していたことである。したがって、2013年の大気汚染対策以降に初めて全面禁焼が打ち出されたと単純に理解することは歴史的事実と整合しない。12\n本稿では、2008〜2015年という段階の制度的展開に焦点を当て、政策原文、地方での実践、そしてそこから生じたガバナンス・インセンティブを区別して論じる。\n一、2008〜2015年：禁焼政策はどのように段階的に落实されたか 現代の稲わら禁焼は単独の部門が独力で行ったのではなく、逐次的に分解されるガバナンス構造を通じて展開された。\n国家関連部門 が、環境ガバナンス、総合利用、責任落实の政策目標を提示する。 省政府と地方立法機関 が、禁焼範囲、地方制度、財政支援、考核方式を定める。 市・県政府 が、責任区域を画分し、補助資金を手配し、巡回を組織し、火点を検証する。 郷鎮、村組、農業経営者 が、圃場整理、機械化鋤き込み、稲わら回収・貯蔵、現場管理といった実務に直接向き合う。 この構造は他の公共政策の執行モデルと根本的に異なるものではないが、稲わら焼却にはいくつかの特殊性がある。発生箇所がきわめて分散しており、主に農繁期に集中する一方、その火点の一部は衛星によって検出可能である。\nこのことが、稲わら焼却を徐々に、分散的な農業生産行為から、統計・通報・ランキング可能な行政管理対象へと変えていった。\n二、2008年：オリンピック大気質確保が大規模厳格禁焼を推進 2008年4月21日、旧環境保護部は『稲わら禁焼工作の更なる強化に関する通知』（環発〔2008〕22号）を公布した。1\nこの文書は、直轄市、省都城市、副省級城市の管轄区域をすべて禁焼範囲に組み入れるよう求めただけでなく、特に次のように定めた。オリンピック期間中の大気質を確保するため、2008年5月初旬から9月末まで、北京、天津、河北、河南、山東、山西、安徽、江蘇、遼寧の9省市を重点禁焼区域に指定し、全面禁焼を実施する。\n同時に、文書は衛星リモートセンシングによる稲わら焼却のモニタリング、専項督查の組織化、情況通報の実施を求めた。\nこの変化は何を意味するか 1999年の『稲わら焼却禁止及び総合利用管理弁法』は空港・道路等の重点範囲を重視し、公共安全および局地的汚染防止の色彩が強かった。これに対し2008年のオリンピック大気質確保は、地域的大気質 をより前面に出すものだった。異なる省の汚染排出は、大気輸送によって都市の大気質に影響を及ぼす可能性がある。\nこうして、より広範囲かつ長期にわたる統一禁焼が、実践面での先例を得た。\nただし明確にしておくべきは、2008年のオリンピック大気質確保のための臨時全面禁焼が、その年から全国が永久に全域禁焼に移行したことを意味するものではない ということである。長期的な全面禁焼がその後確立されたかどうかは、地方の立法と具体的政策を見る必要がある。\n三、江蘇省：2009年に早くも全域禁焼目標を提示 江蘇省は、稲わら禁焼制度の拡大を研究する上で重要な事例である。\n2009年5月20日、江蘇省人民代表大会常務委員会は『農作物稲わら総合利用の促進に関する決定』を可決した。当該決定は、当初以下の重点禁焼範囲を画定していた。23\n区域類型 当時の規定による禁焼範囲 南京市 全行政区域 その他の設区市 都市建成区の周囲周囲 県級政府所在地等 建成区の周囲周囲 空港 周辺周囲 高速道路、国道・省道、鉄道 両側それぞれ周囲 その他の区域 設区市、県（市）政府が実情に応じて画定 さらに重要なことに、この決定は地方に対して段階的に禁焼区域を拡大するよう求め、2012年末までに全省行政区域で野焼きを禁止する ことを要求した。同年公布の『江蘇省農作物稲わら総合利用計画（2010〜2015年）』は、この時期目標を再度明確にした。23\n少なくとも江蘇省に関しては、全域禁焼は単なる末端の宣伝スローガンではなく、省政府レベルの明確な制度と計画上の根拠を持っていた。\n江蘇省はなぜ比較的早く管理範囲を拡大したのか これは江蘇省の経済地理および農業生産の特性と密接に関連する。\n一方面、都市、人口居住区、交通幹線、空港の分布が比較的密集している。これらの区域に対してそれぞれ禁焼保護範囲を設けると、実際にカバーされる農田はかなり広くなりうる。\n另一方面、江蘇省では稲麦二毛作が広く普及しており、収穫と次作の播種との間に時間的な逼迫がある。農民は田畑に残る大量の稲わらを迅速に処理する必要がある。\nしたがって江蘇省は、焼却を単独で禁止したのではなく、禁焼、機械化鋤き込み、財政補助、稲わら回収・貯蔵 を組み合わせようとした。\n環境保護部の2014年通報によれば、江蘇省は機械化鋤き込み作業に対する専用補助金として 5.2億元 を手配し、地方配套資金 1.7億元 と合わせて、補助基準を1ムーあたり 10元から20元 に引き上げた。同時に、江蘇省は衛星リモートセンシング、地上巡回、PM2.5自動モニタリングを活用し、ドローンやヘリコプターによる巡視も探索した。4\nこのモデルは二つの政策方向を体現している。一つは管理措置によって焼却を抑制すること、もう一つは財政資金によって農民の代替処理コストを下げることである。\n真に困難な問題は、地域・農家ごとに稲わら処理コストが異なることであり、統一的な補助基準では実際の支出を全てカバーできるとは限らない。\n四、安徽：2014年に衛星火点を財政補助金と連動 江蘇省が禁焼の空間範囲の制度化拡大を代表するならば、安徽の2014年の実践は、さらに重要な変化を明確に示している。焼却火点が、地方政府の手にする財政補助資金に直接影響を与え始めた ことである。\n環境保護部が2014年9月に発布した夏季稲わら禁焼工作通報には、次のように記載されている。4\n安徽の省財政は新たに 11.45億元 の補助資金を手配し、主産区の稲わら機械化鋤き込みおよびその他の総合利用プロジェクトを支援した。 県を単位として、重点区域で焼却火点が1件発見されるごとに、省補助金の 5%を控除 する。 非重点区域では、火点1件ごとに 2%を控除 する。 市別および省直管県の火点情況を毎日公開し、毎週テレビニュースで順位通報する。 当年夏収終了後、ランキング下位三市の蚌埠、淮北、滁州の政府主要責任者が、テレビニュースで情況を説明した。 注意：5%と2%は、当時の安徽における関連地方補助金の控除規則であり、農民個人への罰金でも、全国統一規則でもない。\nなぜこれが重要な転換点なのか 従来、ある農地で焼却が起きると、主に関係するのは現場の行為者、近隣住民、関連監督部門だった。\nしかし火点が財政補助金、公開ランキング、行政責任と結びついた瞬間、一件の火点が県全体の政策考核と資金手配に影響を及ぼしうるようになった。\nこうして、より強い行政インセンティブが形成された。\n火点が少なければ少ないほど、地方が財政補助金と行政考核の面で被るリスクは小さい。逆に、火点が発見されれば、追加の督查と責任追及が引き起こされうる。\nこれは、一部の地方が巡回の拡大と予防強度の引き上げに向かっていった理由を説明する。\nしかし、この制度には潜在的なリスクもある。考核が火点の数に過度に依存すると、管理者は「火点があるかどうか」により関心を持ち、稲わらが経済的・環境的・持続的な方法で処理されているかには関心が薄くなるかもしれない。\nこれはインセンティブ・メカニズムの分析であり、上記の規則のみをもって、当時の普遍的な違法執法または不適切な処罰が存在すると断じることはできない。\n五、2013〜2015年：禁焼と政府績效考核のさらなる結合 2013年5月14日、国家発展改革委員会、農業部、環境保護部は『農作物稲わら総合利用及び禁焼工作の強化に関する通知』（発改環資〔2013〕930号）を連合印发した。5\nこの文書は、注目すべき三つの要求を提示した。\n1. 地方責任の明確化 地方政府は管轄行政区域内の稲わら総合利用に対し総責任を負い、政府主要領導が第一責任者であり、目標責任制を確立して関連部門に責任を割り当てる必要がある。\n2. 「倒逼（逆押し）メカニズム」の形成 文書は、禁焼とプロジェクト審査、大気汚染物質総量削減考核、農村環境保護目標責任制考核とを連動させることを求めた。\n3. 衛星モニタリングと末端監督の強化 文書は、衛星応用プラットフォームに基づく禁焼監督情報システムの構築を提案し、同時に稲わらの粉砕、結束、鋤き込み、回収・貯蔵・輸送体系の整備を推進することを求めた。\n2014年には、『大気汚染防止行動計画』の実施情況考核に稲わら禁焼工作がさらに組み込まれた。環境保護部は、2014年の公式通報および2016年の全国人大代表建議への答弁において、いずれもこの変化を確認した。46\nここに到って、稲わら禁焼はもはや単なる農業生産と環境保護の問題ではなく、地方政府の績效考核体系により直接的に組み込まれた。\nなぜより厳格な管理方式が現れやすくなったのか 執行コストの観点から見ると、禁焼区・非禁焼区・特定圃場・特殊時間帯・管理条件を精密に区分するには、より詳細な調査と管理能力が求められる。\n一方、単純で統一的な全面禁焼規則は、宣伝、点検、責任追及がより容易である。\n比較項目 精密分区管理 単純な全面禁焼 規則の複雑度 高い 低い 圃場・時間帯の判定 個別の判断が必要 判定は比較的単純 農業生産の柔軟性 比較的高い 比較的低い 末端のコミュニケーションコスト 高い場合がある 初期には低い場合がある 環境リスク管理 技術力と執行能力により依存 事前全面予防をより強調 ガバナンス・インセンティブの観点から見ると、この行政インセンティブは一部の地方で管理範囲が拡大した動力を説明しうるが、行政の便宜性それ自体が、法に基づく禁焼範囲画定および処罰実施の法的根拠に取って代わることはできない。\nより重要なのは、監督を強化するだけでは稲わらの最終的な行き先を解決できない。\nたとえば統合された補助金標準は、実際の支出のすべてをカバーできるとは限らない。\n2015年6月、環境保護部は全国人大代表建議への答弁の中で、稲わら禁焼には証拠収集の難しさ、処罰の難しさ、末端執行力の不足といった問題があると明確に指摘した。一部の地方では、農繁期に末端職員が24時間体制で輪番巡回を行っても、すべての違法焼却を適時に発見・制止することはできなかった。同答弁は重要な原因を次のように帰結した。大量の余剰稲わらの出路が、まだ時宜を得て有効に解決されていない。7\nこれは非常に重要な公式認識である。当時の主管部門は、巡回と処罰のみによっては根本的に問題を解決できないことをすでに認識していた。\n六、湖北：2015年に正式に全省禁焼を実施 2015年2月1日、湖北省第十二期人民代表大会第三回会議は『農作物稲わら露天禁焼及び総合利用に関する決定』を可決した。この文書は、2015年5月1日より、湖北省全省行政区域で稲わらの露天焼却を禁止する ことを定めた。8\n同時にこの決定は、地方に対し防控メカニズムを整備し、総合利用を推進し、宣伝、村規民約、責任分解などの方式を通じて禁焼を落实するよう求めた。\n興味深いことに、湖北省人大が公布した草案修改説明には、立法過程における異なる意見も記録されている。9\n当時、多くの代表は全面禁焼の時期的段取りと、2020年までに稲わら総合利用率95%以上を目指す目標に同意したが、一部の代表から、実施時期と目標についてさらに検討すべきとの意見が提示された。\n最終的に、立法機関は2015年5月1日から全省禁焼を実施することを選択した。\nこれは、地方レベルの全面禁焼が形成される過程においても、全く議論がなかったわけではないことを示している。政策立案者もまた、大気質品質、農業生産サイクル、総合利用能力、実施時期の間で選択を行わざるを得なかった。\n七、2014〜2015年：火点は本当に減少したのか 環境保護部の二年連続の夏季通報によれば、5月20日から7月31日 というモニタリング期間において、以下の通りである。410\n年 全国砂の火点数（衛星モニタリング） 2014年 2,119件 2015年 1,158件 2015年は2014年比で 961件減少し、45.35%の低下 となった。\n一部の省では変化がより顕著である。\n省 2014年夏季 2015年夏季 前年比変化 安徽 644 32 -95.0% 湖北 79 14 -82.3% 河南 815 512 -37.2% 河北 106 196 +84.9% 安徽と湖北では大幅な減少が見られたが、河北では逆に明らかな増加が見られた。\nこれらの公式データは、対応するモニタリング条件下では、全国夏季に発見された稲わら焼却火点数が確かに明瞭に減少したものの、地域差が非常に大きい ことを示している。\nなぜ火点の数だけで全ての効果を評価できないのか 第一に、衛星火点はすべての焼却行為を網羅した記録ではない。\n雲が火点を覆い隠す可能性がある。 規模が小さく、燃焼時間が短い事象は捕捉されない可能性がある。 熱異常点は誤判定を除外するため、依然として地上検証が必要である。 一つの火点は一農家に等しいわけではなく、燃焼面積や汚染排出量に直接換算することもできない。 第二に、火点の変化は、気象、作付面積、収穫進捗、機械化レベル、執行力度、政策インセンティブなどの要因にも影響される。\n最後に、ある地域で火点が減少したとしても、それが直ちにその地域のPM2.5濃度が同じ割合で前年比低下したことを意味するとは限らない。\nしたがって、禁焼の効果を評価するには、理想的には大気質モニタリング、農業生産コスト、実際の稲わら処理量、ガバナンス支出を組み合わせる必要がある。\n八、江蘇省政策目標の時期的変化：制度的要求と実際の実現は別物 江蘇省は、2009年の省人大決定およびその後公布された計画の中で、いずれも 2012年末までに露天稲わら焼却を全面禁止する という目標を掲げていた。23\nしかし2014年12月20日、江蘇省政府の『農作物稲わら総合利用の全面的推進に関する意見』は、新たな段階的目標を提示した。11\n2015年までに、稲わら総合利用率を90%に到達させ、露天焼却を基本的に根絶する。 2017年までに、稲わら総合利用率を95%以上に高め、露天稲わら焼却の全面禁止を実現する。 この変化は注目に値する。\nこれは直ちに、以前の地方が全て執行に失敗したことを証明するものではない。しかし、全域禁焼の制度的枠組みを整備したとしても、現実には十分な代替処理能力がすでに構築されているとは限らない ことを示している。\n稲わらの収集、結束、輸送、貯蔵、加工、販売は、機械設備、農村労働力、季節物流、産業市場に関わるもので、行政命令の発布だけで即座に構築できるものではない。\n政策要求と技術・産業能力との間の時間差は、稲わら禁焼が繰り返し論争を呼んできた理由を理解する鍵である。\n九、禁焼政策は結局汚染を解決しているのか、コストを移転しているだけなのか この二つの問題を混同してはならない。\nまず、露天焼却は実際に大気汚染と公共安全リスクを生む。 人口密集地域、空港、主要交通幹線付近での厳格な管理には、明確な公共利益の基盤がある。\n次に、稲わらを処理しなければならない現実は、禁令によって消えるわけではない。 市場化された回収・貯蔵と経済的に実行可能な代替方式がなければ、農民は機械化鋤き込み、結束、輸送、その他圃場整備のコストを負わざるを得ない。\n最後に、監督自体にもコストがある。 衛星モニタリング、末端巡回、值班、通報、そして現場検証はいずれも公的資源を要する。\n各主体が負うコストを大まかに分けると以下の通りである。\nコスト 想定される負担主体 主な現れ 焼却汚染と公共安全の損害 住民、交通利用者、社会 煙塵、健康リスク、視程低下 稲わら処理コスト 農家、合作社、農業企業 粉砕、鋤き込み、結束、搬出、貯蔵 監督・執行コスト 各級政府 モニタリング、巡回、検証、執法 資源化利用への投資 企業、合作社、財政 回収・貯蔵・輸送ネットワーク、加工施設、補助金 禁焼は汚染による社会的コストを引き下げる可能性があるが、稲わら処理コストを自動的に除去するわけではない。\n2016年に『資源科学』に掲載された『蘇・浙・皖農家稲わら処理行動分析』は、473戸の農家に対する調査研究である。研究によれば、禁焼補助金、農家の認知、鋤き込み技術の指導、近隣に稲わら収購ステーションがあるかどうかといった要因が、焼却・鋤き込み・稲わら売却の選択と重要な関連を持っていた。12\nこれは、政策が長期的に有効かどうかは、監督強度だけでなく、代替処理方式が現実に実行可能かどうかに依存することも意味する。\n2015年11月、国家発展改革委等四部門はさらに『農作物稲わら総合利用及び禁焼工作の更なる加速推進に関する通知』（発改環資〔2015〕2651号）を公布し、「疎堵結合、以疏为主（遮断と疎通の組み合わせ、疎通を主とする）」 を強調し、2020年までに全国の稲わら総合利用率を85%以上とする目標を提示した。13\nこれは禁焼の否定ではなく、行政的禁止が農業技術、回収・貯蔵体系、市場需要と連動して機能する必要があることを示している。\n十、2008〜2015年の歴史は結局何を物語るか 主要な節目を合わせて見ると、政策変化の脈絡はきわめて明瞭である。\n時期 主要な変化 歴史的意義 2008年 オリンピック期間中の九省市全面禁焼 大規模統一厳格管理の重要な先例 2009年 江蘇省が2012年末までの全省禁焼目標を制定 全域禁焼が地方レベルで制度化を開始 2013年 国家文書が政府責任と倒逼メカニズムを強調 禁焼と行政考核のさらなる結合 2014年 安徽が火点を財政補助金の控除と連動 モニタリング指標が地方財政インセンティブに直接影響 2014年 禁焼が大気汚染防止行動計画考核に組み込まれる 環境ガバナンス績效の更なる強化 2015年 湖北が全省禁焼決定を可決 より多くの地域で全域禁焼が制度化 2015年 国家が総合利用と回収・貯蔵政策をさらに強化 禁焼単独依存の限界へのより明確な対応 この歴史における最も重要な変化は、人々が2008年になってようやく稲わら焼却が大気を汚染することに気づいたということではなく、元来分散的だった農業生産行為が、モニタリング・ランキング・考核・責任追及が可能な公共ガバナンス体系へと次第に組み込まれていった ことである。\nこの制度は短期的に地方資源を動員し、検出される火点を減らすことができるが、新たな問題も提起する。行政目標が農家の経済条件や地域の農業技術水準と完全には整合しない場合、禁焼コストは結局誰が負担するのか。\nある政策のガバナンス目標が正当性を持つことは、すべての執行方法が同様に合理的であることを意味しない。稲わら禁焼政策の成果を判断するには、環境改善を見るだけでなく、農業生産条件と実施コストも考慮する必要がある。\n2008年のオリンピック大気質確保から、2015年の全面禁焼と総合利用の並進に至るまで、中国の稲わら禁焼は地域防控から体系的行政管理への移行という重要な時期に入った。 これはその後に現れた全域禁焼論争、総合利用政策の調整、精密分区の議論の伏線ともなった。\n参考資料 以下は主に政府原典の政策文書、公式通報、学術研究を用いている。本文中の数値は、いずれも引用資料の対応する年および統計口径に従う。\n環境保護部：『稲わら禁焼工作の更なる強化に関する通知』（環発〔2008〕22号）、2008年4月21日 江蘇省人民政府：『江蘇省農作物稲わら総合利用計画（2010〜2015年）』、2009年12月2日 『江蘇省人民代表大会常務委員会 農作物稲わら総合利用の促進に関する決定』、2009年5月20日（法規転載） 環境保護部：『2014年夏季稲わら禁焼工作情況に関する通報』、2014年9月15日 国家発展改革委等：『農作物稲わら総合利用及び禁焼工作の強化に関する通知』（発改環資〔2013〕930号） 環境保護部：『第十二期全国人民代表大会第四回会議第7232号建議への答弁』、2016年 環境保護部：『第十二期全国人民代表大会第三回会議第5677号建議への答弁』、2015年6月23日 『湖北省人民代表大会 農作物稲わら露天禁焼及び総合利用に関する決定』、2015年2月1日 湖北省人大：『湖北省人民代表大会 農作物稲わら露天禁焼及び総合利用に関する決定（草案）修正情況の説明』 環境保護部：『2015年夏季稲わら焼却汚染防控工作情況に関する通報』、2015年10月8日 江蘇省人民政府：『農作物稲わら総合利用の全面的推進に関する意見』（蘇政発〔2014〕126号） 漆軍等：『蘇・浙・皖農家稲わら処理行動分析』、『資源科学』、第38巻第6期、2016年 国家発展改革委等：『農作物稲わら総合利用及び禁焼工作の更なる加速推進に関する通知』（発改環資〔2015〕2651号） 注記：本稿は2008〜2015年の政策展開を主に振り返る。引用ファイルの歴史的内容は2026年現在の有効な法律の完全な規定と等しいものではない。具体的な禁焼範囲・時間帯・処罰については、現在の法律および地域の最新規定に従うこと。\n","permalink":"https://blog.imcaoxuan.cn/ja/posts/straw-burning-ban-history-part-2/","summary":"2008年のオリンピック大気質確保は全面禁焼の重要な先例であり、江蘇省は2009年早くも全省禁焼目標を提示していた。2013年以降、衛星火点、績效考核、財政補助金が政策の執行ロジックを共に変えた。","title":"一本の火、三十年：なぜ中国稲わら禁焼は重点管理から全域禁焼に向かったのか？（後編）"}]