Hi there 👋

DN42とは ルータの実験等のために作られた仮想NW（オーバレイネットワーク）のこと 公式ホーム wiki紹介 公式 github まあ正直、FRRとかって実際のインターネットではなかなか触る機会ないよね。 なんで、wireguardとかopenvpnとかで仮想ネットワーク作ってそこでFRRとか動かそうよって話だよな。 と言うことで勉強のためにDN42に参加しよう。実際にASも取得して見ちゃおうよ。楽しそうね。 色々メモ コレをみると、どうやらDN42のNWレンジが決まっていそうだぞ。 full dn42 ranges (172.20.0.0/14, fd00::/8) 172.20.0.14ということは、ホスト部が32-14=18bitなので、2^18つまり、262144このIPがこのネットワークには存在していそうだ。 すでにどこまで割り当てられているのだろう。調べたい。 それっぽい dn42 is a large, dynamic VPN that employs Internet technologies (BGP, whois database, DNS, etc.). Participants connect to each other using network tunnels (GRE, OpenVPN, WireGuard, Tinc, IPsec) and exchange routes using the Border Gateway Protocol. Network addresses are assigned in the 172.20.0.0/14 range with private AS numbers (see registry), as well as IPv6 addresses from the ULA range (fd00::/8) - see FAQ. ...

ブログとGitHubから分析する、コンピュータ分野における自分の強みと弱み 自分のブログとGitHubをChatGPTに見てもらい、コンピュータの各分野について、強みと弱みを5段階で評価してもらった。研究で書いたミドルウェアと、その研究に対応する論文の受賞実績も判断材料に含めている。 きっかけは、自己紹介記事の末尾に書いた「もはやコンピュータの分野で学べることはこれ以上ないのではないか」という感覚だった。自分では見えていない分野や理解の穴を洗い出し、今後どういう技術者を目指すか考えたかった。 以下は、その分析をブログ掲載用にまとめたもの。点数そのものより、何を根拠に評価したか、何がまだ分からないか、次に何をできるようになると伸びるかを重視している。 分析対象と評価の前提 分析には、次の資料を使った。 対象 確認した範囲 この資料から分かること ブログ 自己紹介記事から年代順に、サイトマップ上の公開記事164件の本文。短いメモや雛形を含む。コード・設定は評価に関係する箇所を確認 学習の経緯、構築・運用経験、障害の切り分け方、当時の理解 GitHub 公開29リポジトリの一覧・構成。そのうちfork以外18件、fork 11件。主要なリポジトリのソース・テスト・評価プログラムと、一部のコミット履歴を確認 公開されている実装、実験方法、テストの範囲、コードから読み取れる課題 論文・受賞記録 論文の公開情報、APDCM公式の受賞記録・開催案内 研究成果の発表と、研究コミュニティによる評価 主に読んだ公開コードは、The_Middleware、zwidy、gslb-prober、renogy-bt2-module-exporter、c-compiler、atcoder、opt_using_scip_or-toolsなど。全リポジトリの全行を監査したわけではない。 コードのビルド、テスト実行、実機での性能測定は行っていない。 コード上の問題については、実行で再現した不具合と混同しないよう、静的レビュー上の指摘として記載する。仕事上の非公開成果物も評価に含めていない。 また、以下の点を前提とする。 古い記事の誤りが、現在も同じ理解のままであることを意味するとは限らない。 公開された証拠が少ない分野の低得点は、「実力が低い」という断定より、今回確認できた到達度の下限に近い。 リポジトリの所有やコミット名だけでは、共同開発の担当範囲や、各部分を独力で説明できる深さまでは確定できない。 fork元や同梱された外部ライブラリの実装全体を、本人の実績として数えていない。 研究としての貢献、実用システムの運用品質、教材に沿った学習成果は、それぞれ評価する内容が異なる。 コードに対する具体的な指摘では、確認したコミットへのリンクを使った。以後の修正で解消されている可能性がある。 全体像：強みはシステム構築と、研究に基づく性能改善 最も強い領域は、大きく二つある。 一つは、Linux・ネットワーク・アプリケーションをつなぎ、必要なシステムを構築・運用する力。VPN、経路制御、プロキシ、コンテナ、監視まで、複数の層にまたがって問題を追っている。 もう一つは、科学技術データの転送・圧縮・キャッシュを組み合わせ、性能改善の仕組みを研究・実装・評価する力。こちらには公開コードに加え、国際ワークショップでのBest Paper受賞という外部評価がある。 一方、伸ばす余地が大きいのは、並行動作や障害時の正しさを保証し、他人が再現・運用できる形に仕上げる力。テスト経験や実装経験はあるが、公開された複数の成果物に、同期・異常系・再現性に関する課題が見える。 「広く触ってきたため次に学ぶ対象が見えにくい」という感覚は理解できる。ただ、資料からは、専門性を深める余地と、既存の実装をさらに完成させる余地の両方が確認できる。 5段階評価の基準 一般の人との比較ではなく、その分野でどの程度の問題を扱えるかを目安にした。採用試験や資格のような標準化された測定ではなく、公開資料に基づく推定である。 点数 目安 1 入門段階。概念や基本操作を学んでいる 2 基礎を学び、例や資料を参考に実装・実験できる 3 通常の課題を、自分で組み立てて実装・検証できる 4 複雑な課題や研究課題に対し、設計・実装・評価を組み合わせて成果を出せる 5 難しい課題を継続して主導し、成果を他者の利用・指導・分野への貢献につなげられる 4から5の差は、知っている製品名の数より、扱う課題の難しさ、成果の継続性、他者への波及にある。 一度の受賞だけで5を確定することも、公開資料だけで5の能力がないと断定することもできない。 以下の「根拠の厚さ」は点数の精密さを表すものではない。「厚い」は複数の具体的成果があり、「中程度」は経験が確認できるが範囲や現在の深さに不明点があり、「限定的」は資料が少ないことを示す。 分野別の評価 強みの中心となる分野 分野 評価 根拠の厚さ 判断の根拠・現在見える限界 Linuxサーバ構築・運用 4/5 厚い 自宅サーバ運用、systemd、権限、ストレージ、障害調査の蓄積がある。カーネル実装の熟練度とは分けて評価。Linuxの学習記録 ネットワーク・VPN 4/5 厚い NAT、戻り経路、OpenVPN内部経路、FRR・OSPFの実験に加え、zwidyのTUN・TLS通信実装がある。OpenVPNとFRR、zwidy 複数レイヤをまたぐシステム構築 4/5 厚い VPS、VPN、自宅オリジン、プロキシ、DBなどを接続し、用途を実現している。VPNクライアントとDocker 科学技術データのI/O・キャッシュ設計と性能評価 4/5 厚い 多段キャッシュ、先読み、圧縮、転送を組み合わせた実装・評価と、対応する研究の受賞実績がある。カーネル・DB内部など性能全般を一律4とする評価ではない。The_Middleware システム研究の遂行・成果の論文化 4/5 厚い 共同研究による論文発表とAPDCM 2024 Best Paper受賞。継続した研究主導や研究指導の実績は今回の資料では判断できない。公式受賞記録 HTTP・Nginx・リバースプロキシ 4/5 厚い 複数ドメイン、TLS終端、WebSocket、オリジンへの転送を運用している。複数サービスの公開 Docker・コンテナ利用 4/5 厚い Compose、永続化、containerd、Singularity、GPU環境まで利用範囲が広い。コンテナランタイム自体の開発とは区別。コンテナの学習記録 監視・ログ収集基盤 4/5 厚い Prometheus、Grafana、Vector、OpenSearchの構築に加え、機器データ用exporterも実装している。O11y、Renogy exporter 実践経験があり、さらに深められる分野 分野 評価 根拠の厚さ 判断の根拠・現在見える限界 Kubernetes 3/5 中程度 クラスタ、Service、Ingress、Probe、更新・障害調査まで実践。多数のサービスを長期運用する深さは不明。学習記録 IaC・構成管理・CI/CD 3/5 中程度 Ansibleの業務利用や構成管理の経験がある。テスト・配布・ロールバックまで一貫した自動化の公開証拠は限定的。Ansible 可用性・バックアップ設計 3/5 中程度 UPS、別拠点への同期、フェイルオーバ試験まで経験。復元時の整合性、復旧時間、データ損失量の定量化は追加材料が欲しい。ドライブの冗長化 バックエンド・API開発 3/5 厚い REST、WebSocket、DB連携、GSLB制御などの実装経験がある。入力検証・認可・並行更新・互換性まで含めた品質は伸ばせる。API設計、gslb-prober SQL・データベース利用／設計 3/5 中程度 スキーマ、JOIN、集計、MySQL・PostgreSQLの利用経験がある。高度な実行計画分析やトランザクション設計の材料は少なめ。JOINの振り返り HPC・科学技術計算の環境構築 3/5 中程度 Slurm、MPI、GPU、コンテナ、圧縮ライブラリを扱っている。大規模クラスタの管理やMPIアプリ全般の最適化まで4とは判断しない。Slurm C/C++・システムプログラミング 3/5 中程度 ソケット、ライブラリ、CMake、Pythonとのバインディングなどの経験がある。大規模なC/C++製品のメモリ安全性・保守品質は未確認。Pybind Goによるネットワークサービス実装 3/5 中程度 gslb-proberとzwidyで、ネットワークI/O、goroutine、設定・状態管理、メトリクスを実装。完成度は成果物ごとに異なる。GSLBのソース 並行処理の実装 3/5 中程度 Pythonの先読みスレッド・ワーカープール、Goの送受信・監視処理の経験がある。安全な同期や終了処理の保証が次の課題。ClientAPI、zwidyクライアント TLS・証明書・認証基盤の利用 3/5 中程度 OpenSSL、SAN、mTLS、Athenzの学習・実践とTLS接続テストがある。暗号理論やシステム全体の安全性評価は別途必要。TLSの記事 機器連携・データ収集 3/5 中程度 BLE機器への要求・応答とPrometheusへの出力を実装。組み込みファームウェア全般の評価ではない。exporter.py LLM・RAG・エージェントの組み込み 3/5 中程度 自前推論、ベクトルDB、Gmail・Slack連携などを実践。精度、失敗率、権限、安全性の体系的評価は確認材料が少ない。RAG アルゴリズム・データ構造 3/5 中程度 競プロコードの探索・順序付き集合、自作DPとソルバーの比較を確認。問題ファイルの存在だけで正答や競技水準は保証できない。AtCoderのコード、ナップサックの照合 基礎経験はあるが、公開資料上は厚みが足りない分野 分野 評価 根拠の厚さ 判断の根拠・現在見える限界 DBエンジン・分散アルゴリズムの実装 2/5 限定的 バッファプールやRaftの学習記録はある。完成した自作エンジンと、再起動・通信断・リーダー交代時の検証は確認できない。分散システム テスト・品質保証の体系化 2/5 中程度 単体テスト、TLS接続テスト、結果照合はある。一方、異常系・システム全体のテスト・再現可能なビルドを継続して整備した証拠は薄い。テスト未経験という意味ではない フロントエンド・UI/UX 2/5 限定的 HTML/CSS/JSの経験はある。複雑な状態管理、アクセシビリティ、ユーザー評価までの実践は未確認。React 機械学習・予測モデルの評価 2/5 限定的 Keras、scikit-learn、予測モデルの経験はある。汎化性能、データ漏洩、モデル選択の体系的検証は資料が少ない。システムの性能実験における統計集計とは分けて評価。機械学習 コンパイラ 2/5 中程度 教材に沿い、数値・加減算のトークン化、アセンブリ出力、簡単なテストを実装。型・関数・最適化などを備えた処理系の実績ではない。学習用コンパイラ AWS/GCPのクラウド設計、モバイル開発、組み込みファームウェア、カーネル・ドライバ開発、暗号アルゴリズムの設計などは、今回の資料では採点する材料が足りない。未評価を一律に1点として扱うことはしない。 ...

はじめに TailscaleはWireGuardベースのメッシュVPNを簡単に構築できる。 一方、通常はTailscale社のコントロールプレーンを利用する。 今回はオープンソースの Headscale をVPS上に構築し、端末の登録・管理を自分のサーバーで行う。 実際に構築した環境では、MacとiPhoneの接続に成功し、最初はDERPリレー経由だった通信が、その後IPv4・IPv6の直接P2P通信に切り替わった。 Headscaleは制御サーバーであり、通常の端末間データ通信を中継するVPNハブではない。直接接続できない場合はDERPリレーを利用する。なお、今回利用したDERPはHeadscale自身でホストしたものではない。 構成 項目 内容 サーバー Xserver VPS / Ubuntu 22.04.5 公開ドメイン headscale.ingenboy.com Headscale v0.28.0 Docker Docker Engine + Compose v2 HTTPS Nginx + Let’s Encrypt (Certbot) macOS Tailscale Homebrew版 v1.104.4 端末 MacBook Pro、iPhone Tailnet IP Mac 100.64.0.1、iPhone 100.64.0.2 通信経路は以下のとおり。 Mac / iPhone ── HTTPS ──> Nginx :443 ── HTTP ──> Headscale :8080 │ (制御・端末管理) └──────── WireGuard P2P ──────── 相手の端末 └─ P2P不可ならDERPリレー VPSでは既存のNginxが80/443番ポートを利用しているため、Headscaleコンテナの8080番ポートを ホストの127.0.0.1:18080 にだけ公開した。これならHeadscaleのHTTPポートをインターネットへ直接公開せずに済む。 ...

概要 opencode + 自前ollama (gemma4-31b) を使って自前でコーディングエージェントを構築するハウツー 前提 ollamaが疎通可能なNWで動いていること ray@kami:~$ curl http://192.168.0.97:11434/v1/models | jq . % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 835 100 835 0 0 465k 0 --:--:-- --:--:-- --:--:-- 815k { "object": "list", "data": [ { "id": "gemma4:latest", "object": "model", "created": 1781793873, "owned_by": "library" }, { "id": "gemma4:31b", "object": "model", "created": 1775797746, "owned_by": "library" }, { "id": "glm-4.7-flash:latest", "object": "model", "created": 1773826681, "owned_by": "library" }, { "id": "olmo-3:32b", "object": "model", "created": 1766060501, "owned_by": "library" }, { "id": "deepseek-r1:32b", "object": "model", "created": 1759021785, "owned_by": "library" }, { "id": "mixtral:8x7b", "object": "model", "created": 1758984309, "owned_by": "library" }, { "id": "phi4:14b", "object": "model", "created": 1758639295, "owned_by": "library" }, { "id": "qwen3:32b", "object": "model", "created": 1758637355, "owned_by": "library" }, { "id": "gemma3:27b", "object": "model", "created": 1758636814, "owned_by": "library" }, { "id": "gpt-oss:20b", "object": "model", "created": 1758636489, "owned_by": "library" } ] } 手順 1. opencodeをインストール opencodeホームページ ...

openclawで業務を全てを自動化する。 最終的にやりたいこと。 人間がやっていることをopenclawにやらせる。 予約管理システムがある。 gmailもある。 そして、運用ポリシーもある。（マニュアルはまだない） つまり、人間に仕事をやらせる準備はできているのです。 その辺をslackからopenclawに指示するだけで全部やってくれるようにしたい。 正直、これはかなり未来を感じています。 事務職が淘汰されると言われて久しいが、それを実感してしまった。 codexやclaudeではダメなのか？ これら二つのAIエージェントは、デーモンプロセスでない。 一方で、openclawはデーモンプロセス。常駐しており、マジで自律的に動くAIエージェント。 OpenClaw → 常駐してタスク実行・監視・通知までやる“運用AI” → SlackやLINE感覚で指示できる Claude Code → 大規模コードを理解して設計・改善してくれる“頭脳担当” Codex → コード生成・実行・CIまでサクサクやる“作業担当” 一言で言うと OpenClaw：「動くAI秘書（常駐エージェント）」 Claude Code：「考えてくれるシニアエンジニア」 Codex：「手を動かす高速コーダー」 と言うことなので、マジで自律的に動くAIエージェントです。 slack経由で質問して、なんでも答えてくれるようになったら、これほど便利なものはないと思っている。 定期実行もしてくれるし、何かをトリガーにして実行もしてくれる。 なんでも相談できる。どんなシステムでも、しっかりAPIを設計して、openclawと繋げることで、slack経由で非常に便利なものができると思っている。 これは、もう本当にすごいことだと思います。 アーキテクチャ slack -> openclaw(local net) -> LLM(ollama) -> (openclaw) -> gmail, system API みたいな流れでデータと処理が走る。 ollama用のopenclawをインストール 最初にnodeをインストール curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm install --lts openclawをインストール ray@kami:~$ ollama launch openclaw Installing OpenClaw... npm warn deprecated node-domexception@1.0.0: Use your platform's native DOMException instead added 540 packages in 14s 89 packages are looking for funding run `npm fund` for details npm notice npm notice New minor version of npm available! 11.9.0 -> 11.11.1 npm notice Changelog: https://github.com/npm/cli/releases/tag/v11.11.1 npm notice To update run: npm install -g npm@11.11.1 npm notice OpenClaw installed successfully Select models for OpenClaw: Type to filter... Recommended ▸ glm-4.7-flash Reasoning and code generation locally, ~25GB, (not downloaded) qwen3.5 Reasoning, coding, and visual understanding locally, ~11GB, (not downloade kimi-k2.5:cloud Multimodal reasoning with subagents qwen3.5:cloud Reasoning, coding, and agentic tool use with vision glm-5:cloud Reasoning and code generation minimax-m2.5:cloud Fast, efficient coding and real-world productivity More deepseek-r1:32b gemma3:27b gpt-oss:20b mixtral:8x7b ... and 3 more Download glm-4.7-flash? Yes No ←/→ navigate • enter confirm • esc cancel glm-4.7-flashがおすすめのようなので、これを使うことにした。ちなみになんだこれ。 ...

もう避けては通れない MCPサーバを作って既存のシステムと連携させようって流れが顕著すぎるよね。 まあ、簡単に言うと、MCPサーバは既存のAPIの前に立ち、AIとのAPIを繋ぐ架け橋になるってわけだよね。 これ、って概念は簡単にわかるんだけど、やっぱり実物を作ってみないとわからんと言うことでね。 作ってみようと思います！

背景 いや、ちょっとこれも恥ずかしい話なんですがね。 僕は長いこと、「自作パスワード管理システム」的なものを運用していました。 どうやっていたかというと、 自前ホストしているRocket.Chat に、自分専用のチャンネルをひっそり立てて、 誰も入れないように鍵をかけて、 そのスレッドに “ログイン情報をラベル付きで投稿する” という、 ある意味 究極のアナログ DX をやっていたわけです。 もちろん一応、安全面は全く考えてなかったわけではなくて、 Rocket.Chat のデータは gocryptfs で暗号化されたストレージに保存 通信経路は https で暗号化 サーバは自分の管理下 チャンネルは自分しかアクセスできない と、一応「最低限の安全性」は確保しているつもりでした。 だけど、世の中ではみんな LastPass だの 1Password だの Bitwarden だのと言っているじゃないですか。 僕はこういう “流行り物” に疎いところがちょっとあって、 「パスワード管理ツールって本当に必要？」 と長年スルーしていたんですよね。 そんなとき、エンジニアの先輩から 「Bitwarden の OSS クローンで Vaultwarden っていうのがあって、自前ホストも簡単で、めっちゃ良いよ」 とすすめられました。 で、触ってみたら、UI も綺麗だし、ストレージ管理もラクだし、 正直「これはかなりイケてるな」と感じたわけです。 しかし、ここから僕の悪い癖が発動します。 “仕組みが分かっていないものに重要な情報を預けるのが嫌” これは性格なんですが、 ブラックボックスは信用できない。 暗号化の仕組みがわからないと不安になる。 果たして、 自前のサーバ（しかもレンタル）に Vaultwarden を置いて、 そこに人生の全パスワードをぶち込んで大丈夫なのか？ という疑念がどうしても消えない。 結論から言うと： Vaultwarden（Bitwarden）は、むしろ「Rocket.Chatにパスワードを書いてた頃の比じゃないほど安全」だった。 調べれば調べるほど「これは信頼できる暗号設計だな」と感じたので、 今回はその 安全性の仕組み をブログとしてまとめたいと思う。 安全性の評価 Bitwarden / Vaultwarden が扱う暗号モデルは、 いわゆる ゼロ知識暗号（Zero-Knowledge Encryption） である。 ...

いつもnatの設定を忘れてしまうのでここに残しておきたい ss@kong:~$ sudo sysctl -w net.ipv4.ip_forward=1 && \ sudo iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -d 192.168.10.0/24 -o enp9s0 -j MASQUERADE && \ sudo iptables -A FORWARD -i tun0 -o enp9s0 -s 10.8.0.0/24 -d 192.168.10.0/24 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT && \ sudo iptables -A FORWARD -i enp9s0 -o tun0 -s 192.168.10.0/24 -d 10.8.0.0/24 -m state --state ESTABLISHED,RELATED -j ACCEPT backupのトンネルの方はこっち rr@kong:~$ sudo sysctl -w net.ipv4.ip_forward=1 && sudo iptables -t nat -A POSTROUTING -s 10.10.0.0/24 -d 192.168.10.0/24 -o enp9s0 -j MASQUERADE && sudo iptables -A FORWARD -i tun1 -o enp9s0 -s 10.10.0.0/24 -d 192.168.10.0/24 -m state --state NEW,ESTABLISHED,RELATED -j ACCEPT && sudo iptables -A FORWARD -i enp9s0 -o tun1 -s 192.168.10.0/24 -d 10.10.0.0/24 -m state --state ESTABLISHED,RELATED -j ACCEPT net.ipv4.ip_forward = 1 これ、一応意味書いておくか。 ...

SRE本を読んでいく こちら

背景 複数拠点（A, B, Cなど）を OpenVPN 経由で接続し、 **2系統のVPNトンネル（10.8.0.0/24 と 10.10.0.0/24）**を経由して経路冗長化したい。（openvpnサーバは独立した2マシン） そんなニーズから検証を始めました。 各拠点はそれぞれローカルLAN（例: 192.168.1.0/24, 192.168.2.0/24, 192.168.3.0/24）を持ち、 それらを OSPF (FRRouting) で自動経路学習させて、 VPNトンネル越しに相互通信できるようにしたい、という構成です。 やりたかったこと OpenVPNで各拠点を接続（多拠点site-to-site VPN） FRR (OSPF) を使って動的ルーティング トンネルごとにコストを設定して経路選択 できれば route-nopull で手動ルーティングを制御 目標は「OpenVPNトンネルを2本走らせて、FRRで経路選択を任せる」ことでした。 これを実現するにあたり、色々とハマったので知見をまとめておこうと思います。 OpenVPNのルーティングの構造 OpenVPNはユーザランドで動作し、/dev/net/tun デバイスを通じて通信します。 Linuxカーネルはtunデバイスにパケットを出す そこから先は**OpenVPNプロセス（ユーザランド）**が受け取り、独自の内部ルーティングテーブルで転送を行う つまり、Linuxのルーティングテーブル（ip route）とは別世界で動いています。（ここが非常に大事です。openvpnサーバないのルーティングテーブルがちゃんと設定されていないと、クライアントから届いたパケットをどのクライアントに転送すればいいかがわかりません。ちなみに、openvpnのルーティングテーブルは/var/log/openvpn-status.logから確認可能です） push と route-nopull の関係 OpenVPNサーバはクライアントに対して push “route …” を送ることで、 クライアントのOSにもユーザランドにもルート情報を注入します。 一方、クライアント設定で route-nopull を有効にすると、 その push 情報をすべて拒否します。 frrでルーティングをさせたい場合には、route-nopullにしておかないと、0.0.0.0/1と128.0.0.1/1がOSのルーティングテーブルに登録され、すべてのパケットが特定のnicから出るように設定されてしまうので注意が必要（server側で**push “redirect-gateway def1 bypass-dhcp”**が入っている場合） FRR(OSPF)を組み合わせても解決しない理由 FRRでOSPFを走らせると、 VPNトンネル越しに相手拠点のLAN情報（例: 192.168.x.x/24）が学習されます。 これにより、OSレベルのルーティングテーブルは更新されます。 しかし！ OpenVPNサーバはそのOSルートを全く参照しません。 OpenVPNプロセスは独自に「このLANはどのクライアントの背後にあるか」を iroute で知っていなければ、パケットをどこに転送すべきか判断できません。 自分の場合は、openvpnサーバの/etc/openvpn/ccd以下に書くルーティングファイルの情報が間違っており、クライアント1 -> サーバはパケットが届いていたが、サーバがクライアント2宛のパケットをうまく転送できずdropしてしまっていたのが原因ですね。 ...