図４：マルチレイヤネットワーク

マルチレイヤネットワークの論理トポロジーの監視ではパス構成を把握する必要がある。パスを監視することにより故障による影響範囲を迅速に特定し、マルチレイヤネットワークの実現における課題を解決することができる。
例えば、MPLS(Multi Protocol Label Switching)を用いたネットワークでは、「ラベル」と呼ばれる目印を付加してフォワーディングを行う。ルーターに入ってきたパケットには、宛先IPアドレスとラベルテーブルを参照してラベルが付けられる。その後、MPLS網内ではラベルのみを見てフォワーディングが繰り返され、目的地まで到着したらラベルが外される。ラベルが付けられたパケットの道筋を「LSP（Label Switched Path）」と呼ぶ。これにより、単一の物理網に対して論理的に分割された複数のネットワークを構築することができる。MPLSネットワークでは論理トポロジーを監視するために、LSPを監視する。MPLSのLSPにサービスの情報を紐付けておくことで、故障時に発生するLSP断の情報から故障サービスを迅速に特定することが可能になる。
同様に、VPLS、PWE3、MPLS-TEといった技術で構成されたマルチレイヤネットワークのパス監視が実現できる。

図５：MPLSネットワーク監視の監視範囲

パス情報の収集には、ベンダー固有のMIBから収集する方法やTelnetとコマンドラインを用いた方法やがある。監視対象となる装置毎に実装方法が異なるため、開発コストが膨らむ可能性があり、パス情報取得方法の統一化はマルチレイヤネットワーク監視の実現における大きな課題となっている。パス情報取得方法が今後どうなるか、ベンダーの動向に注目していくべきである。

４－２．オープンフローネットワークの監視
ネットワークを柔軟に運用するための技術として、オープンフローがある。オープンフローでの通信は、ネットワークを一元的に管理するコントローラと、実際にフレームを処理するスイッチにより構成される。コントローラで定めたルールに基づいて、スイッチでフレームが転送される。

図６：オープンフローネットワーク

オープンフローを用いたネットワークでは、スイッチがコントローラにトポロジー情報を通知することで、コントローラ側でトポロジーの変化を把握することができる。
４－２の方法ではSNMPやTelnetを用いて定期的に情報を収集し、トポロジーを更新する必要があったが、オープンフローでは常時最新のトポロジー情報をコントローラで管理するため、ネットワーク故障により影響を受けたサービスやユーザーの把握を容易に実現できる。

これまで4回にわたり、最新の監視技術動向について紹介を行った。サービスの多様化により、ますます複雑化するネットワークにあわせて効率の良い監視を実現するために、それに対応した監視技術を導入することが必要である。

※略語説明
・MPLS：Multi Protocol Label Switching Traffic
・MPLS-TE：MPLS Traffic Engineering
・VPLS：Virtual Private LAN Service
・PWE3：Pseudo Wire Emulation Edge to Edge
・LSP：Label Switched Path
・MIB：Management information base

よく行われているのが「ネガポジ判定」と呼ばれている評判検索。あるキーワードに対してネット上でネガティブ（不評）な書き込みが多いかポジティブ（好評）な書き込みが多いか自動判定する。キーワードを含む書き込みを検索して中味を分析し、それがネガかポジかを判定するのだ。例えばTwitter上でのネガポジをリアルタイムで判定するtweetfeel（http://www.tweetfeel.com）というサービスがある。今のところ英語版のみのようだが、例えば“obama”と打ち込むと“I love obama”とか“hating obama”とかと言ったつぶやきが次々と検索されて、ネガとポジの割合がパーセント表示される。ちなみにobamaのネガポジは今のところ五分五分。日本語サイトのhttp://blog-hyoban.goo.ne.jp/では、８割がポジのようだ（ちょっと脱線…）。

最新の評判検索サービスが“評BAN”（http://www.hyohban.jp/）だ。こちらはTwitterやFacebookだけでなく様々なブログやニュースサイト等から評判情報を集めてきて総合的にネガポジ判定してくれる。業種や業態ごとの専用辞書を用いて文脈の解析を行うのでネガポジ判定の精度が高いそうだ。しかも１時間ごとに情報更新されるので評判の鮮度も高い。また、この即時性を活かしてサイトのバースト（いわゆる炎上）も検知してくれるそうだ。

更にもっと賢い評判検索もある。まだ研究段階のようだが、単純なネガポジ判定では無く、何の、どこが、どうであるかといった評判内容そのものを自動分析してくれる（http://www.ntt.co.jp/RD/OFIS/keyword/vol7.html）。例えば、「携帯電話のX905iという機種の、画面が、見やすかった」といった評判を抽出してくれるのだ。それをもとに、画面に関する評判が何件、デザインが何件、そのうち好評が何件といった分析までしてくれる。ここまでくると「評判検索」というよりは「評判分析」と呼べるだろう。わざわざアンケートやインタビューをしなくても、生のタイムリーな“声”が聞き取れるようになりそうである。それにしても冒頭の「やらせ」問題は何らかの手を打たなければいけない。ここもＩＣＴの出番ではないだろうか。

３－２．動的閾値監視（複数監視項目）
動的閾値監視では１つの監視項目の過去データから閾値を作成する方式だけでなく、「CPUとメモリ」や「CPUとI/O」などの複数の監視項目の相関性を考慮して閾値を作成する方式もある。
【CPUとI/Oの相関関係（CPUが高いと、I/Oが低い）を使用した例】
・CPU負荷が高く、I/Oが低い場合：通常状態であり、問題なし
・CPU負荷が低く、I/Oが高い場合：アラーム通知（通常運用状態と違う動作であれば、障害の可能性あり）

図３：動的閾値監視の複数監視項目の相関関係

次回は、マルチレイヤネットワークの監視技術について説明する。

新規システムだと、どうしても仕様がきっちり詰まっているかとか、方式の課題はどうかというところに主力作業が偏ってしまいがちになる。そうすると、ソフトの流用についての検討は2の次になる。もう少し具体的に書くと、ソフトの流用を最大に活かそうとすると、流用できそうなソフトの熟知というのは仕様書作成や方式検討と並んで開発初期に実施しておかねばならない作業となる。本来、開発量や開発作業量を見積もるためにソフト流用は考えねばならないポイントなのだが、ソフト開発のプロジェクトマネージメントを書いた本でも、まず流用したいソフトの理解を開発初期段階で徹底的にやりましょうとは書いていない。仕様書や方式課題のマネージメントがしっかりできるプロジェクトマネージャでも、流用したいソフトをシステム開発をやるプロジェクトのメンバに熟読させる時間を開発当初に作れるかというと、なかなかそうはいかないのである。

流用したいソフトを熟知している前提で開発を始めるとか、一部の開発メンバだけの理解で開発を始めた場合、ソフト流用せずに新規でソフトを作ったほうが早いということになったり、流用したものの流用母体のソフトを見切れていないことによるバグに苦しんだりする。こういう場合の多くは、それぞれのソフトを開発した人のスキルが悪かったからだという理由にされたりするが、流用したいソフトの熟読期間を与えなかったプロジェクトマネージャのミスが隠れている場合が多い。

ちょっとくどい文章になってしまったが、ソフト流用には、開発初期での流用ソフトを熟知する時間が必要だ。ソフト流用は開発の効率化や品質向上には欠かせないのだから、開発初期のソフト熟知の時間は是非確保したいものである。

課題１：静的閾値の値が適切に設定されておらず、低い値が静的閾値に設定されている場合、システムは正常状態にもかかわらず多くのアラーム通知される場合がある。アラーム通知によって監視者は常に装置の状態を把握するための確認作業を行う必要があり、保守稼働の増加につながる。また、適切な静的閾値を決めるために、一定期間の正常状態のトラフィック量・リソース使用状況を調査し、その結果から人が静的閾値を判断しなければならない。

課題２：サーバーへのアクセス頻度が低い時間帯（昼間帯等）に、閾値を超えない範囲で、通常時とは異なるリソース使用率の変化（＝異常状態）があった場合、閾値を超えていないため、アラーム通知せず、サイレント故障の状態となる。

２－２．動的閾値監視
２－１の課題解決方法として、監視対象装置の過去のリソース使用状況を収集し、正常状態を示す動的なベースラインを作成し、そのベースラインに基づきリソースを閾値監視すること（以下、動的閾値監視）により、正常な状態であるが静的閾値超過アラームを通知するアラーム誤検知を防止する（課題１の解決）。また、通常時と異なるリソース利用率の変化を検知することで静的閾値監視ではエラーメッセージの出ない性能劣化等のサイレント故障を防止する（課題２の解決）。

図２：静的閾値監視と動的閾値監視

次回は静的閾値監視と動的閾値監視のメリット、デメリットと、動的閾値監視（複数監視項目）について説明する。

１-２．早期かつ正確な故障検知を実現する仕組み
ネットワーク、サーバーの監視の代表的な監視技術としてSNMPがある。SNMPは図1のように監視システムが監視対象にMIBとよばれる装置状態をポーリングによって取得することで、ネットワーク、サーバーの情報をすることができる。また、SNMPには監視対象装置インタフェースのリンクアップ、リンクダウンなど特定の状態変化に伴って、監視対象装置自身が監視システムにアラートをあげる「SNMP-Trap」と呼ばれる仕組みも存在する。SNMP-Trapは異常を即座に監視システムに伝えることができるが、途中でTrapが損失してしまうと、監視システムで検知することができない。

図１：SNMPを利用した監視イメージ

本連載では次回以降、故障検知を効率化する仕組みとして、下記2つの技術を紹介する。

1)　 監視対象装置の過去のリソース使用状況を収集して、統計的に正常状態を示すベースラインを作成し、そのベースラインに基づいてリソースの監視を行い、サイレント故障など正常時と異なるリソース利用率の変化を検知するリソース閾値監視の仕組みについて説明する。

2)　柔軟に構成されたネットワークにおいて、故障により影響を受けたサービスやユーザーを即座に把握するために、論理ネットワークのトポロジー監視を行う仕組みがある。マルチレイヤネットワークとオープンフローネットワークについて、それぞれの監視を紹介する。

※略語説明
・SNMP：Simple Network Management Protocol

今売られている家電も既に“頭脳”は持ちつつある。Ｐ社の「エコナビ」が有名だが、同等のものが各社から出ている。例えば冷蔵庫。ドアの開閉状況を検知しその家庭の生活パターンを記憶・予測、外出中や就寝時など冷蔵庫を使わない時間帯は自動的に節電運転し、食事時間には通常運転に戻したりすることで電力使用を少なくする。こういった機能が２０種類以上の家電に搭載されている。我が家の温水便座も生活パターンに合わせて節電動作しているようだ（生活パターンから外れて座るとちょっと辛いが・・・）。

で、こういった“頭脳”がネットで“つながれ”ばスマート家電となるのだ。ただ、“頭脳”は各社が創意工夫してこしらえているので、独自に作られたものを相互につなげるのはそう簡単ではない。家電・通信・電力など１０社が参加して、ＨＥＭＳ（Home Energy Management System）アライアンスという組織が昨年立ち上げられた。通信の手順を決めて相互にやりとりできるようにすることは、技術的にはやればできることであるが、それ以前に解決すべき課題が多いという。例えば不具合が出た場合原因をどう切り分けるのか、ウイルス等の被害予測と対策はどうなのか、個人情報漏洩等の問題は出ないのか等々。ＨＥＭＳアライアンス含め、こういった技術以前の議論がしっかりなされたうえで、ようやくつながり始めることになるのだろう。

成熟商品が多い家電であるが、スマート家電の登場でメーカーさんにとっては大きなビジネスチャンスが到来しそうだ。自動車業界がハイブリッド車や電気自動車で活況を呈しているように…。更に、全ての家電がネットにつながることで、新たなネットワークサービスも出てきそうだ。テレビとステレオと照明が連動して演出するエンタテインメントアプリとか…。もしかして、スマート家電でもGoogleのようなポータルサイトが出てきたりして？

ケータイでテレビを見ると言えばワンセグがお馴染だが、ワンセグとモバキャスは何が違うのだろうか。最も大きな違いは、ワンセグが地デジと同じ番組（コンテンツ）を流しているのに対して、モバキャスは専用のオリジナルコンテンツを流すこと。また、従来のテレビのようなリアルタイム放送だけでなく、蓄積型呼ばれる放送がある。コンテンツが一旦ファイルとして受信機に蓄積され、好きな時間に再生・視聴できるサービスである。TwitterやFacebookとの連動機能も有り、１台のスマホでスポーツ中継を観戦しながら“つぶやき合う”ということもできる。いわば、放送と通信の良いとこ取りをしたサービスだそうだ。映像の品質もワンセグに比べ１０倍高画質だそうだ。

それから裏方の話ではあるが、モバキャスは“上下分離方式”という新しい事業形態でサービスされる。従来の放送は番組作りから電波を発信するところまで１つの放送会社が行っていた（垂直統合型）が、モバキャスでは放送設備を運営するハード会社（下位層）と番組制作・編成を行うソフト会社（上位層）に分かれてサービスされる。ハード会社は、ジャパンモバイル・キャスティングという１社のみで、その設備を利用して複数のソフト会社が番組を提供することになる。

いまのところ、ソフト会社はまだ「ＮＯＴＴＶ（ノッティービィー）」を提供するｍｍｂｉ社のみだが、それだけでもかなりメニューが用意されている。地デジと違い有料サービスだ。月額４２０円でリアルタイム放送３チャンネルと蓄積型の番組が提供される。また別料金でスポーツ中継や音楽ライブ等のコンテンツも用意される予定。ＳＮＳ連動を利用して視聴者参加型のクイズ番組なども揃えるという。４月のサービス開始時点では、関東、関西等の地域限定であるが、３年で人口カバー率90％以上にするそうだ。対応端末はドコモからスマホとタブレット端末を各1機種が用意され、逐次機種追加の予定。

長年言われてきた、“放送と通信の融合”がモバキャスで一歩前進しそうだ。仕組みはできたので、後は魂であるコンテンツ次第といったところであろうか？

●電力線
G.hnの電力線通信は、ITU-Tでベースバンド帯(2～100MHz)が規定されている（日本国内においては電波法の規制上30MHz以下の帯域に制限される）ため、HD-PLC、UPA（Universal Powerline Association）、Home Plug AVなど他の電力線通信方式と周波数帯域が重複し、干渉を起こすこと考えられる。そのためITU-Tにて既存電力線通信方式との共存規格としてITU-T Ｇ.9972がある。ITU-T Ｇ.9972は各電力線通信方式との間で、規定されたマップに従い時分割多重して共存する方式である。ITU-T 標準上では、ITU-T Ｇ.9972の仕組みをG.hnに搭載することを「強く推奨する」と記載されている。

●同軸線
G.hn同軸線通信は、ベースバンド帯に加えて、300MHz～2500MHz(日本仕様であるAnnex Cでは350MHz～2950MHz)が使用周波数帯として規定されている 。しかし、同軸線を使用する既存サービスである地デジ、地アナ、ケーブルテレビ、BS、CSなどとの干渉を考慮すると図4に示すA、B、C、D帯が利用可能な周波数帯域である。
どの周波数帯を利用するかは、各周波数帯でのパフォーマンスと、近隣の周波数を使用している通信、およびアンテナからの放射による無線への影響を鑑みて、見極めていく必要がある。

●通信線
通信線通信は、主に集合住宅やオフィスなどの既存の建物に新規配線せず高速なインターネット環境を構築する手段（VDSLなど）として普及しているが、宅内の利用では、電話線は電力線、同軸線と比べて各部屋に敷設されていないことが多く、まずは利用形態の有無から見極めていく必要がある。

図4　同軸線上の周波数帯利用状況

現在、G.hnについては複数のチップベンダが参入を表明している。今後はG.hn技術、既存通信との共存の可否を見極めると共に、主にWi-Fiなどの無線技術と組み合わせることにより最適な宅内ネットワークに向けて取り組んでいくことが重要と考える。

上記のようなデータベースを利用しているシステムの方式設計時に、興味深い話があった。リアルタイムでトラヒックを集計して出したいのだが、トラヒック収集情報自体が膨大なために、リアルタイムトラヒック集計処理がある時間内に完了しないかもしれないので、方式検討を実施する必要があるという内容だった。リアルタイムのトラヒック集計と言っても10分単位程度のトラヒック収集情報を1分程度で集計するもので、ただトラヒック情報自体は膨大でかつ種類も多い。データベース上にあるトラヒック収集情報を検索して、トラヒック集計することを検討しているが、データ量も多いので検索ロジックとかデータベースのチューニングでトラヒック集計が時間内に収まるようにしたいという考え方であった。

まあ、確かにデータベースがあるのだからその情報をうまく検索して、必要な情報を集計できればいいのだが、こういう処理を行うと一時的にCPU負荷がかかるし、他の処理との競合もあり、あまり好ましいものではない。

昔だと、そんなことしたらシステムダウンになりかねない問題なので、一気に行うトラヒック集計処理ではなく、トラヒック収集側の一つ一つの小さな処理の中にトラヒック集計が簡単になる仕掛けを入れておくようなことをやっていた。多少トラヒック収集自体は負荷がかかるものの、システム全体への影響をなくす配慮だった。

システムの基盤としてデータベースが用意され、高性能なCPUや余裕のあるメモリ量があると、簡単にソフトウェアが組めるのは事実であり良いことだが、ちょっとした処理方式の工夫で簡単に要求条件をクリアできることもある。最近の主流の実現方式で困ったとき、昔はどうやっていたか？を顧みてみると案外答えが見つかるかも知れない。

G.hnのプロトコルスタックについては図3の通り

図3　G.hnのプロトコルスタック

●ITU-T Ｇ.9960(PHY)の特徴については以下の通り
・電力線、同軸線、通信線に共通の送受信器を定義している
・誤り訂正符号（LDPC-BC）を使用している
・デジタル信号処理部とアナログ信号処理部で構成され、デジタル信号処理部は全媒体共通、アナログ信号処理部は媒体毎に異なる
・送受信器間でクロックの転送が可能である。
よって、「面的な広がり（カバレッジの拡大）」、「広帯域かつ安定化」の実現が期待できる。

●ITU-T Ｇ.9960(DataLink) の特徴については以下の通り
・パラメータベースQoS(帯域、遅延などの性能を保証）と、プライオリティベースQoS (割り当てた帯域をシェアして、優先順位を決めて使用する方式)を同一のフロー内で混在させて設定することが可能である。例えば、電話サービスはパラメータベースQoSを使用し、インターネットサービスはプライオリティベースのQoSを使用することが可能となる

G.hnの使用については電力線などの既存有線媒体を利用する。その為、既に導入されているPLC等の技術との共存が課題と思われる。
次回は既存技術との共存について紹介する。

モバイルでデータ通信する場合、端末毎に月額使用料がかかるのが一般的だし、公衆ホットスポットでも端末毎に月額使用料がかかったりする。モバイルWiFiルータを利用すると、端末毎の月額使用料を一つにまとめることができるので月額使用料が減らせることになるはずだ。さらに、どこでもつながるし、最適な通信速度も選べたり、複数端末の同時利用もできるとなるとメリットが大きくなるだろう。

さて、話は変わるが、先日自分で使っているスマートフォンにAGEPhoneというIP電話ソフトを入れてみた。自宅でフレッツ光ネクストに入っているのだが、このソフトを使うと自宅の電話の子機としてスマートフォンを使うことができる。実際に使ってみると、音声品質も良く、スマートフォン子機同士の内線通話もでき、携帯電話より料金安く通話できたりするので、なかなか良いアプリである。WiFi利用で出来る通信が広がっているいい例だと思う。データ通信だけでなく、電話も固定と携帯の垣根を越えて利用できるようになっていくのだろう。

モバイルWiFiルータ機能は端末機能として垣根を越えるものだと思うが、ネットワーク機能の垣根も端末機能によって越える日が近いような気がする。

Ｗｅｂと検索サービスで、大量の情報にアクセスできるようになった。しかも、ホームページ等のスタティックな情報だけでなく、TwitterやFacebookで本来ならその場で消えてなくなる“つぶやき”まで知ることができる。ただその量があまりにも膨大になったので、それら全てに目を通すことは不可能であり、google検索しても思うところの情報を見つけ出すのに大変苦労する時代になった。そこで人気を集め始めたのがキュレーターによる「まとめサイト」なのである。グーグルのように、全世界の情報を“ロボット”で集めてきて索引を作って何でも１秒もかからずに引き出せるようになったが、とても使いきれなくて、その方面に詳しい“人”が整理してくれたところから選んで来るということなのだろう。

「まとめサイト」の代表例が“ＮＡＶＥＲ（ネイバー）まとめ”だ。トップページは「まとめのまとめ」になっていて、ニュース・政治経済・ファッション等々いろんなテーマの「まとめ」にアクセスでき、そこから関連情報を簡単に手にできる。もちろん自分がキュレーターになって「まとめ」を作成することもできる。ネイバーによると、誰でも情報をデザインできる場所、だそうだ。インターネット上で見つけた、あらゆる情報を、自由に組み合わせ、ひとつのページにまとめて、保存、紹介できる。ＩＤとパスワードを取得してログインし、まとめ作成のページを開く。白紙のページにまとめのタイトル名を付け、アイテム追加機能を使って、リンク・写真・動画などペタペタと張っていけばそれで「まとめ」ページが出来上がる。もちろんTwitterも貼付け可能だ。ドラッグ＆ドロップでページレイアウトも自由に変えられる。面白いのは「まとめ」ページの中に広告のスペースがあり、ここから「まとめ」作成者に利益還元もされるのだ。これなら誰でもキュレーターになれそうだ。

ブログやＳＮＳ等様々な情報発信がされるようになってきたが、キュレーションという形での“情報の存在を知らせる情報”の発信は益々重要度を増してくるに違いないだろう。

図2　G.hnと既存伝送方式(有線)との比較

主な特徴としては、以下が挙げられる。
・通信速度(最大1Gbps)は従来の電力線，同軸線、通信線での通信規格に勝る
・既存の家庭内の任意のコンセント（電力線、同軸線、通信線）間で通信が可能
・同軸線では外部ノイズの干渉などが少ない
各通信媒体の特徴を用いることにより、「広帯域かつ安定化」、「面的な広がり（カバレッジの拡大）」の両要求を満足する規格と考えられる。

G.hnに関するその他の技術的特徴については以下の通り。
・変調復調方式：OFDM(Orthogonal Frequency Division Multiplexing)方式
・使用帯域幅：25、50、100、200ＭＨz(媒体ごとに使用帯域が規定されている。200ＭＨｚは日本仕様のみに記述されている。)
・最大物理速度：最大１Gｂｐｓ
・接続形態：同一伝送媒体を複数のノードで共有している。
・媒体アクセス方式：同一媒体上で同時複数接続が可能である。
・QoS制御：Priority-based QoS/Prameter-based QoS

次回はG.hnの標準化動向について紹介する。

自動車の歴史を振り返ると、ＩＣＴの原点である「電気」は、最初は燃料の点火やヘッドライトに使われていた。その後カーラジオが搭載されて、この辺から「カーエレクトロニクス」という言葉が使われるようになった。ちなみに、初期のカーラジオは真空管式だったそうだ。エレクトロニクスはアナログからデジタルになり、やがてＣＰＵが搭載されエンジンを細かく制御し、排ガスをクリーンにし、燃費・馬力を向上させた。そのＣＰＵはエンジンだけでなく車のあらゆる機能を制御するようになった。そして、そう遠くない未来に“カーＩＣＴ”を搭載した“スマートカー”が街にあふれるのだろう。

“カーＩＣＴ”の最大の特徴はクラウド連携だ。車はクラウド端末となり、各種サービスを提供してくれるサーバーとやりとりをしながら走ることになる。最も実現が早そうなのが、走行支援サービス。カーナビの単なるルート案内ではなく、電気自動車に欠かせない充電ポイントの指示や走行ペースのガイドをしてくれる。部品の消耗や故障・不具合の状況もサーバーで管理され、適切な対処が示される。また、家の車庫に入っている時には家庭向けの充電設備としての役割を果たす。コミュニケーション機能の充実も“カーＩＣＴ”のウリだ。カーラジオの如くＳＮＳが車内に標準装備され、アフターサービス含めた販売店とのやりとりや、オーナー同士のコミュニティーでの交流がなされる。車とオーナーの間でもやりとりができる。スマホからの遠隔操作でバッテリーの残量を確認したり、出かける前にエアコンを作動させることも可能だ。ソフトのバージョンアップのお知らせも届くに違いない。

話を第４２回東京モーターショーに戻そう。筆者が最も注目したのはTOYOTAのFun-Vii（ファン・ビー）。“タイヤを履いた走るスマートフォン”というコンセプトだそうだ。車の外も中もタッチパネル型ディスプレイで覆われている。カメラで本人が認証され、その日の気分で外装を好きな色に変えられる。スマホの中に入ったかのようなインテリア。これはもはや車ではなく電気製品だ。ジャヤパネットたかたで自動車を買う時代はもうそこまで来ている！？