↓ ↑ページトップへ
表示調整
閉じる
挿絵表示切替ボタン
▼配色
▼行間
▼文字サイズ
▼メニューバー
×閉じる

ブックマークに追加しました

設定
0/400
設定を保存しました
エラーが発生しました
※文字以内
ブックマークを解除しました。

エラーが発生しました。

エラーの原因がわからない場合はヘルプセンターをご確認ください。

ブックマーク機能を使うにはログインしてください。
『The 1st International Conference on Artificial Intelligence (第1回 人工知能国際会議)』  作者: 東曌


この作品ページにはなろうチアーズプログラム参加に伴う広告が設置されています。詳細はこちら

PR
17/19

新章 第十二話 前編 守ることを、個人の注意力に任せていいのか(Pythonと、Mojo)

【登場人物紹介】


◾️黒田修一(くろだ・しゅういち)

 「Chief Information Officer(CIO)最高情報責任者」/経営担当役員


大手企業グループの経営担当役員。合併や事業再編を推進し、会社の成長を実現してきた。経営判断の速さには自信がある。しかし、巨大化した組織のシステムを、本当に把握できているのかという疑問を抱き始めている。


◾️佐伯直人(さえき・なおと)

 シニアシステムエンジニア


企業グループの情報システム部門に所属する技術者。システム統合や更新に携わってきた。Pythonをはじめとする既存の開発環境を理解する一方、処理速度が重要な部分では、実装方法そのものを見直す必要があると考えている。



◾️高瀬美紀(たかせ・みき)

 セキュリティ運用担当者


日々、アクセスログや不審な通信を監視する現場の責任者。大量の警告と向き合いながら、人間の目視や手作業だけでは対応しきれない現実を知っている。



◾️三浦健(みうら・けん)

 情報セキュリティ専門家


企業のセキュリティ体制を評価する専門家。侵入を防ぐだけでなく、侵入された場合の被害を限定し、早期に復旧する仕組みを重視している。



◾️白石恵(しらいし・めぐみ)

 利用者保護の担当者


顧客相談や個人情報保護に携わる担当者。情報流出を単なる技術的事故とは考えない。企業が守るべきものは、データだけでなく、人々から預かった信頼だと考えている。



◾️榊原玲(さかきばら・れい)

 AI防御構想の提案者**


AIを活用した防御構想「RIS」の可能性を研究している人物。AIによる分析と高速処理、そして適切な防御設計を組み合わせれば、人間だけでは対応できない領域を守れる可能性があると考えている。ただし、AIにすべてを任せればよいとは考えていない。


前編 守ることを、個人の注意力に任せていいのか

情報流出時代の経営会議



## 第一章 また、情報が流出した


会議室の大型モニターには、情報流出に関するニュースが映し出されていた。


企業名。流出した情報の種類。影響を受けた可能性のある利用者数。調査中という説明。謝罪の言葉。そして、再発防止策。


黒田修一は、資料を閉じた。


「またか、という言葉しか出てこないな」


誰もすぐには答えなかった。


「毎回、同じような説明を聞く。原因を調査します。再発防止に努めます。社員教育を徹底します。アクセス権限を見直します。もちろん、必要なことだろう。しかし、それで本当に次を防げるのか」


高瀬美紀が口を開いた。


「社員教育は必要です。でも、教育を徹底すれば情報流出がなくなる、という話ではありません」


「なぜだ?」


「人間は間違えるからです」


黒田は眉を動かした。


「それは、誰でも知っていることだろう」


「知っていることと、システムの設計に反映していることは違います」


高瀬は、手元の資料を一枚めくった。


「間違った宛先に送信する。不要な権限を残す。古いアカウントを削除し忘れる。警告を見落とす。手順を急いで省略する。どれも、気をつけるように言われていることです。それでも起きます」


佐伯直人が続けた。


「問題は、間違いが起きたとき、どこまで被害が広がる設計になっているかです」


黒田は腕を組んだ。


「つまり、社員の注意力を信用するなということか」


「いいえ。人間を信用するからこそ、人間が間違えても致命傷にならない仕組みを作るんです」


佐伯の言葉に、会議室が静かになった。


それまで議論されていたのは、どうすれば人間が間違えないか、という問題だった。


しかし、佐伯が問い直したのは、別の問題だった。


**人間が間違えることを前提にしても、組織は安全でいられるのか。**


## 第二章 会社は大きくなった。システムも大きくなった


黒田は、壁に表示された企業グループの組織図を見た。


「我々の会社は、十数年で大きくなった。合併もした。新しい事業も買収した。顧客基盤も広がった。それぞれの会社が持っていたシステムも統合してきた」


「統合してきた、というより、統合しきれなかった部分も残っています」


佐伯が答えた。


「率直だな」


「技術者ですから、率直に申し上げます。システムを統合するには時間も費用もかかります。事業を止めるわけにはいきませんから、古いシステムを残したまま、新しいシステムと接続することもあります」


「それが、そんなに危険なのか」


「古いものが残っていること自体が、直ちに危険なのではありません。問題は、どのシステムが何につながり、どの権限で何にアクセスできるのかを、組織全体で正確に把握できているかどうかです」


三浦健が口を挟んだ。


「システムは、組織図のようには動きません。部署が変わっても、契約が終わっても、古いアカウントや接続が残っていることがあります。ある部署では必要だった権限が、別の部署では過剰な権限になっていることもあります」


黒田は資料に目を落とした。


「つまり、会社は大きくなったが、その大きさに見合う管理ができているとは限らない、と」


「そうです」


佐伯はうなずいた。


「合併すれば、顧客も、売上も、技術も手に入る。しかし、システム同士をつなぐということは、管理すべき境界も増えるということです。接続が増えれば、確認すべき場所も増える。例外的な運用が増えれば、全体像はさらに見えにくくなります」


「それなら、統合を進めるたびに、セキュリティの費用も増やさなければならない」


「はい。ただし、費用を増やせば解決するとも限りません。何を守り、何を切り離し、どこまでの被害を許容するのか。経営として決めなければならないことがあります」


黒田は黙った。


企業を大きくする判断は、何度もしてきた。


しかし、企業が大きくなったとき、守るべき境界がどれだけ増えるのか。その増加分まで、経営計画に織り込んできただろうか。


## 第三章 毎秒百三十回の攻撃を、人間が見張るのか


高瀬はモニターを切り替えた。


そこには、時刻、アクセス元、要求の種類、判定結果など、膨大なログが並んでいた。


「仮に、ある環境で毎秒百三十件を超える攻撃の試行が発生しているとします」


黒田は画面を見た。


「毎秒、百三十件?」


「はい。ただし、攻撃の試行が百三十件あることと、百三十件すべてが成功していることは違います。何を一件と数えるかによっても数字は変わります。ここでは、機械的な攻撃を人間が一件ずつ判断することの難しさを考えてください」


三浦が説明を引き継いだ。


「一秒間に百三十件なら、一分間で七千八百件です。一時間では二十八万件を超えます。しかも、攻撃は勤務時間に合わせて止まってくれるわけではありません」


「それを、担当者が一件ずつ確認するのか」


黒田の問いに、高瀬は首を横に振った。


「無理です。そもそも、私たちはすべてのログを一件ずつ読んでいるわけではありません。ルールや検知システムを使って、疑わしいものを絞り込みます。それでも、警告が多すぎれば、本当に重要な兆候が埋もれることがあります」


「ならば、担当者を増やせばいいのではないか」


「人員を増やすことは必要な場合もあります。でも、単純に人数を増やしても、機械が処理する速度には追いつきません。しかも、警告の意味を判断できる人材を、必要なだけ集められるとは限りません」


高瀬は画面の一部を指さした。


「私たちが怖いのは、攻撃が多いことだけではありません。重要な警告が大量の雑音に埋もれることです。そして、見つけたときには、すでに被害が広がっていることです」


白石恵が尋ねた。


「そのとき、被害を受けるのは誰ですか」


「顧客です。従業員です。取引先です」


白石は、ゆっくりとうなずいた。


「ニュースでは、流出した件数が大きく報じられます。でも、その数字の一人ひとりには生活があります。住所を知られたくない人もいる。仕事上の情報を守らなければならない人もいる。企業に預けた情報が、本人の知らないところで広がる。それは、単なる数字の問題ではありません」


黒田は反論しなかった。


「では、守る側はどうすればいい。人間では処理しきれない。かといって、機械に任せれば安全だという保証もない」


「そこが、次の問題です」


三浦は答えた。


「人間か、機械か、という二者択一ではありません。人間が判断すべきことと、機械が高速に処理すべきことを分ける必要があります」


## 第四章 AIを導入しても、遅ければ守れない


「では、AIに監視を任せればいいのか」


黒田の問いに、榊原玲が答えた。


「AIは役に立つ可能性があります。ただし、AIを導入するだけでは足りません」


「なぜだ。AIは大量のデータを処理できるのだろう」


「処理できる量は、システムの設計や使うモデル、実行環境によって変わります。AIに判断させる前に、ログを集め、整理し、分析できる形にする必要もあります。そこで処理が詰まれば、どれほど賢いAIでも、必要なタイミングで判断できません」


佐伯がうなずいた。


「そのとおりです。防御の速度は、AIモデルの性能だけでは決まりません。データの取り込み、通信、前処理、推論、判断、実際の遮断。それぞれに時間がかかります。どこか一か所が遅ければ、全体の対応が遅れることがあります」


黒田は、佐伯を見た。


「つまり、AIを導入したという発表だけでは、何も保証されないわけか」


「はい。大切なのは、攻撃を検知してから防御の動作が完了するまで、どれだけ時間がかかるかです。そして、どれだけの処理量に耐えられるか。誤検知や見逃しがどの程度あるか。それを実際の環境で検証する必要があります」


高瀬が付け加えた。


「現場が知りたいのは、AIを導入したという事実ではありません。攻撃を見つけたとき、本当に間に合うのか。誤った判断で正常な業務を止めないか。異常が起きたとき、すぐに人間が介入できるのか。そこです」


榊原はホワイトボードに、横一列に言葉を書いた。


**検知 → 分析 → 判断 → 遮断**


「この一連の処理が、必要な時間内に完了しなければなりません。AIが分析している間に被害が広がれば、分析結果が正しくても、防御としては遅いことがあります」


黒田は、その矢印を見つめた。


「賢さだけでは駄目なのか」


「賢さも必要です。しかし、速さも、信頼性も、実行できる権限も必要です。そして、失敗したときに戻れる仕組みも」


## 第五章 Pythonでは、追いつけないのか


佐伯が、開発環境の構成図をモニターに映した。


「ここで、プログラムそのものの問題を考える必要があります」


黒田は尋ねた。


「Pythonのことか」


「はい。PythonはAIの開発、データ分析、自動化などに広く使われています。豊富なライブラリがあり、試作や検証を速く進められる。セキュリティの仕組みを構築するうえでも、非常に有用です」


「ならば、PythonでRISを作ればいいのではないか」


「すべての部分が、それで十分とは限りません」


佐伯は、少し言葉を選んだ。


「たとえば、非常に大量のデータを短い時間で処理しなければならない部分です。実装方法や利用するライブラリによっては、Pythonの処理速度がボトルネックになることがあります。CPUやGPUの性能を十分に引き出すために、別の実装が必要になる場合もあります」


黒田は眉を寄せた。


「Pythonでは追いつけない、ということか」


「正確には、Pythonだけで書いた実装では、要求される性能を満たせない場合がある、ということです。Pythonそのものが防御に使えないわけではありません。高速なネイティブコードやGPU処理を組み合わせる方法もあります」


榊原が口を開いた。


「そこで検討できる選択肢の一つが、Mojoです」


黒田は、その名前を初めて聞くような顔をした。


「モジョ?」


「Mojoというプログラミング言語です。AIや高性能な計算処理などを視野に入れた言語で、Pythonとの親和性も意識されています。性能が重要な部分を、より低いレベルで制御しながら実装する選択肢になり得ます」


「ならば、Pythonをやめて、Mojoに切り替えればいいのではないか」


佐伯は首を横に振った。


「そこが難しいところです。新しい言語を使えば、必ず速くなるわけではありません。処理の内容、実装、ライブラリ、実行環境によって結果は変わります。既存のシステムとの連携や、開発者の経験、保守性も考えなければなりません」


榊原が続けた。


「すべてを書き直す必要もありません。PythonをAIの制御や分析、既存ライブラリとの連携に使い、速度が特に重要な部分だけ、Mojoやほかの高性能な実装方法を検討する。そういう構成も考えられます」


黒田は、構成図を見直した。


「つまり、言語を一つに統一することが目的ではない」


「はい。必要な性能を、必要な場所で実現することが目的です」


高瀬が言った。


「現場としては、使っている言語の名前よりも、実際に守れるかどうかが重要です。処理が速くなっても、検知の精度が下がったり、障害時に復旧できなくなったりすれば困ります」


「もちろんです」と佐伯は答えた。「速度だけでなく、正確さ、安定性、保守性、障害からの復旧まで含めて評価しなければなりません」


榊原はホワイトボードに、もう一度書いた。


**Pythonを否定するのではない。必要な場所に、必要な性能を与える。**


「これが大切だと思います。Pythonが得意な場所はPythonに任せる。速度が必要な場所には、Mojoを含めた別の実装方法も検討する。そして、全体として防御が間に合うかを測定するのです」


黒田は、少し笑った。


「技術の世界にも、経営と同じ問題があるわけだな。万能な方法を探すのではなく、どこに何を使うかを考える」


「そのとおりです」と佐伯は答えた。「そして、技術を選ぶだけでは終わりません。実際に動かし、測り、検証する必要があります」


## 第六章 速いプログラムがあれば、守れるのか


「では、Mojoで高速化できれば、問題は解決するのか」


黒田の問いに、榊原はすぐには答えなかった。


「いいえ」


「今度は、違うのか」


「高速なプログラムは、防御を支える要素の一つです。しかし、攻撃を検知できなければ、速く処理する対象を間違えます。検知できても、何を危険と判断するかが不適切なら、間違った対応をする。正しく判断しても、遮断する権限がなければ、実際の被害を止められないことがあります」


三浦が引き継いだ。


「さらに、AIが侵入を見つけても、侵害されたアカウントに広い権限があれば、被害が広がる可能性があります。プログラムを速くすることと、被害を小さくすることは、関連していますが、同じ問題ではありません」


佐伯が言った。


「だから、システムの構造そのものも変える必要があります。侵害されたアカウントが、全社の重要情報にアクセスできないようにする。必要な権限だけを与える。システムを適切に分離する。危険を検知したとき、限定された範囲で自動的にアクセスを止められるようにする」


高瀬は、画面に並ぶログを見た。


「そして、止める条件も事前に決めておく。正常な業務まで止めてしまうような誤作動が起きたとき、誰が判断するのか。自動対応を解除するにはどうするのか。そこまで準備しなければ、現場では使えません」


黒田は、ゆっくりとうなずいた。


「速いAI、速いプログラム、正しい判断、適切な権限。そして、失敗したときの復旧手段。それらがそろって初めて、防御として機能するわけか」


「はい」


榊原は答えた。


「技術を速くするだけではなく、失敗しても被害が広がらない構造を作る。その両方が必要です」


## 第七章 誰が責任を持つのか


会議が始まってから、二時間近くが過ぎていた。


黒田は資料を閉じ、出席者を見回した。


「技術的に必要なことは、だいたい分かった。権限を制限する。システムを分離する。監視を強化する。処理速度を測定する。必要なら実装方法も見直す。AIを活用し、復旧手順も用意する。だが、最後に聞きたい」


全員が黒田を見た。


「これだけのことを、誰が責任を持って進めるのか」


佐伯が答えた。


「システム部門だけでは無理です」


高瀬も続いた。


「セキュリティ担当者だけでも無理です」


三浦は言った。


「各部署が自分の範囲だけを守っていても、部署と部署の境界に穴があれば、全体としては危険です」


白石が静かに口を開いた。


「そして、情報を預けた人たちは、社内のどの部署が責任者なのかを知りません。知る必要もないはずです。利用者から見れば、情報を預かった企業が責任を持つ。それだけです」


黒田は彼女を見た。


「しかし、実際には、システムを管理する会社もあれば、運用を委託した会社もある。クラウドサービスもある。複数の企業が関わることもある」


「だからこそ、責任の所在を曖昧にしてはいけないのです」


白石は言葉を続けた。


「委託先の問題だから仕方がない。古いシステムだから仕方がない。担当者が間違えたから仕方がない。そんな説明を、情報を預けた人に受け入れてもらえるでしょうか」


黒田は答えなかった。


白石はさらに言った。


「誰か一人の責任にすることと、組織として責任を持つことは違います。現場の担当者に責任を押しつけて終わりにすれば、次の事故も同じ構造から起きます」


佐伯がうなずいた。


「経営が優先順位を決めなければ、現場は目の前の業務を止められません。古いシステムを直す予算がなければ、技術者は危険を知っていても先送りするしかない。性能が足りないと分かっていても、改善する時間や予算がなければ、現場だけでは変えられません」


黒田は、長い沈黙のあとで言った。


「つまり、セキュリティは技術部門の仕事であると同時に、経営の仕事でもある」


「はい」


佐伯は答えた。


「どこまでのリスクを許容するのか。何に投資するのか。業務を止める判断を誰が下すのか。AIや新しい言語を採用するなら、何を基準に性能と安全性を評価するのか。事故が起きたとき、誰が説明し、誰が被害を受けた人々に向き合うのか。それを決めるのは、技術だけではありません」


## 第八章 守る側にも、AIが必要になる


それまでの議論を聞いていた榊原が、ホワイトボードの前に立った。


「ここまでの話を、ひとつにつなげてみましょう」


彼女は、四つの言葉を書いた。


**分析。速度。防御。責任。**


「AIは大量の情報を分析できます。しかし、その分析が間に合う実装でなければならない。必要に応じて、高性能な言語や実行環境も検討する。そして、分析結果を実際の防御に結びつける。最後に、その動作を誰が管理し、失敗したときに誰が責任を持つのかを明確にする」


高瀬が尋ねた。


「その一連の仕組みを、RISで実現したいということですか」


「はい。少なくとも、その可能性を検討したいと思っています」


榊原は、ホワイトボードに「RIS」と書いた。


「たとえば、大量のログや通信のパターンから異常を検知する。別々に見える警告を関連づける。危険度を評価する。あらかじめ定められた条件を満たした場合には、対象のアクセスを限定したり、一時的に隔離したりする。そして、何を根拠に、どんな対応をしたのかを記録する」


黒田が尋ねた。


「それを、AIがすべて自動で行うのか」


「いいえ。すべてを自由に判断させるのではありません。AIに許す権限を限定し、重要な操作は人間の承認を必要とする。自動化する範囲を明確にし、異常があれば停止できるようにする。実行した操作は監査できるように記録します」


三浦が言った。


「そして、AIを使うこと自体も検証の対象にする。誤検知、見逃し、処理の遅延、障害時の挙動。実際の環境で測定しなければ、性能があるとは言えません」


「そのとおりです」と榊原は答えた。「Mojoのような言語を採用する場合も同じです。名前が新しいから、あるいは高速だと期待されるから採用するのではありません。必要な処理で、実際に性能が改善するかを確認するのです」


白石が尋ねた。


「では、RISが失敗したとき、誰が利用者に説明するのですか」


榊原は答えた。


「AIではありません。AIを設計し、導入し、運用する組織です。AIに判断させたという理由で、人間の責任を消すことはできません」


黒田は、ホワイトボードを見つめていた。


「機械の速度で守る。しかし、何を守るかを決め、機械にどこまで任せるかを決めるのは人間だ」


「はい」


榊原はうなずいた。


「そして、人間が責任を持つためには、AIが何をしたのかを確認できなければなりません。速いだけで、何をしているか分からないシステムでは、安心して任せられません」


## 第九章 技術を知る人だけでは、社会は守れない


会議が終わろうとしたとき、白石が最後の質問をした。


「もう一つ、気になることがあります」


黒田が彼女を見た。


「新しい技術が次々と生まれています。AIも、プログラミング言語も、セキュリティの手法も変わっていく。では、それを知っている人が少ないうちは、社会は守れないのでしょうか」


榊原は、すぐには答えなかった。


やがて、静かに口を開いた。


「技術を知っている人が少なければ、導入や運用を進めるうえで難しいことは増えます。しかし、全員が同じ技術を学ばなければならない、という話ではありません」


佐伯が続けた。


「必要なのは、専門家が新しい技術を評価できること。そして経営者が、技術の名前だけで判断せず、何ができて、何ができないのかを理解することです」


高瀬も言った。


「現場に必要なのは、流行の言語を覚えることではありません。実際に守れる仕組みです。新しい技術を使うなら、本当に検知が速くなるのか、誤検知は増えないか、障害が起きたらどう戻すのか。そこまで確かめたい」


榊原はうなずいた。


「そのとおりです。技術を知ることは、出発点にすぎません。技術を防御力に変えるのは、実装と検証と運用です。そして、その技術を必要な場所に届ける仕組みも欠かせません」


黒田は、考え込んでいた。


新しい技術を採用すれば、それだけで競争力が上がる。


そう考えていた時期もあった。


しかし今、彼の前にある問題は、もっと複雑だった。


技術を選ぶこと。性能を検証すること。使いこなせる人材を育てること。組織の中で運用すること。そして、その結果に責任を持つこと。


そのどれか一つが欠けても、技術は社会を守る力になりきれない。


## 第十章 まだ答えは出ていない


会議室のモニターには、まだ膨大なログが流れていた。


攻撃は、会議が終わるのを待ってくれない。


人間が資料を読み終えるのを待ってもくれない。


人間が一つの警告について相談している間にも、別の警告が生まれている。


黒田は、ゆっくりと立ち上がった。


「今日の話を聞いて、ひとつ分かったことがある。情報流出を防ぐために、社員へ注意を促す。それ自体は間違っていない。しかし、それだけを再発防止策にしてはいけない」


高瀬が答えた。


「注意喚起は、必要な対策の一つです。でも、仕組みの弱さをそのままにして、最後だけ人間の注意力に頼るのは危険です」


佐伯は言った。


「システムの構造を把握する。不要な権限を減らす。被害が広がらないように分離する。必要な処理速度を測り、足りなければ実装を見直す。問題が起きたとき、速やかに止めて復旧できるようにする。そうした仕組みを、設計と経営の段階から考える必要があります」


三浦が続けた。


「そして、攻撃を完全に防げるという幻想を捨てることです。防御を重ね、被害を限定し、早く復旧する。そのすべてを準備する」


白石は、最後にこう言った。


「忘れないでください。私たちが守っているのは、サーバーでも、ファイルでも、数字でもありません。そこに記録された人々の生活と信頼です」


黒田は、ゆっくりとうなずいた。


「では、次に考えるべきことは何だろう。人間の注意力だけでは守れない。人間の手作業だけでも追いつかない。AIを導入するだけでも足りない。プログラムを速くするだけでも足りない」


榊原が答えた。


「だからこそ、すべてを一つの仕組みとして考える必要があります。AIの能力、処理速度、権限、検知の精度、復旧の手順。そして、人間の責任です」


黒田は、最後に問いかけた。


「その仕組みを、本当に作れるのか」


榊原は、ホワイトボードに書かれた「RIS」を見た。


「それを、これから検証しなければなりません」


彼女は、はっきりと言った。


「RISは、すべてを解決する魔法の装置ではありません。まだ、構想の段階で考えるべきこともあります。しかし、人間だけでは追いつけない世界で、守る側の仕事を変える可能性はあります」


会議室の窓の外では、街がいつもどおり動いていた。


人々は企業に情報を預け、サービスを利用し、便利さを享受している。


その便利さを支えるシステムが、どれほど複雑なのか。


そのシステムを守るために、どれほどの処理が必要なのか。


普段、意識する人は少ない。


しかし、ひとたび情報が流出すれば、その結果は、情報を預けた一人ひとりに及ぶ。


黒田は、会議室を出る直前に振り返った。


「機械の速度で守り、人間の責任で設計する。まずは、そこから始めよう」


誰も反対しなかった。


ただし、誰も、それで問題が解決したとは思っていなかった。


**人間の速度を超える攻撃に対して、守る側は、どこまで機械の力を使えるのか。**


AIを動かすプログラムは、必要な速度に追いつけるのか。


新しい技術を、実際の防御力に変えられるのか。


そして、機械に守らせる社会で、人間は何に責任を持つのか。


後編では、守る側のAI「RIS」の可能性と限界をめぐり、彼らにもう一度、議論してもらうことにしよう。


評価をするにはログインしてください。
ブックマークに追加
ブックマーク機能を使うにはログインしてください。
― 新着の感想 ―
このエピソードに感想はまだ書かれていません。
感想一覧
+注意+

特に記載なき場合、掲載されている作品はすべてフィクションであり実在の人物・団体等とは一切関係ありません。
特に記載なき場合、掲載されている作品の著作権は作者にあります(一部作品除く)。
作者以外の方による作品の引用を超える無断転載は禁止しており、行った場合、著作権法の違反となります。