完成形が見えにくいシステム開発において、納期遅延やバグはもちろん、クライアントとの認識齟齬による仕様変更など、トラブルの火種は絶えません。近年ではChatGPTをはじめとした生成AIの活用が広がっており、著作権の問題など今までにない法律トラブルに巻き込まれる可能性もあります。

今回は、自身もプログラム開発の経験を持ち、ITシステム開発の事例に詳しい野溝弁護士に、近年増えているトラブルや今後エンジニアが留意するべき法律について、お話を伺いました。

### 野溝 夏生 弁護士 （第一東京弁護士会）

野溝法律事務所 所長
一橋大学大学院法学研究科法務専攻修了、ロイヤルナイト法律事務所ののち、野溝法律事務所を開業。趣味はRubyによるプログラム開発で、学生時代には企業の依頼を受けて有償のプログラム開発経験も持つ。ITシステム開発のベンダー企業の顧問契約を始め、契約書作成やリスク・ライセンスチェック、トラブルにまつわる相談を受けている。

## 増加傾向にあるアジャイル開発関連のトラブル

#### balloon kishi left
先生はご自身でもプログラム開発経験があり、IT分野に詳しいとお聞きしました。

#### balloon nomizo right
高校生の頃にPythonとRubyを勉強し、当時はLinuxをオンプレサーバーにインストールするところから始め、Twitter APIを利用してbotやクライアントを作ったり、Webサイトや簡易なWebアプリケーション制作を行なったりしていました。周囲の友人にもエンジニアが多く、新しい分野に挑戦し続けるエンジニアの方々をバックアップしたいという思いがあります。

#### balloon kishi left
直近で増えている法律トラブルの傾向はありますか？

#### balloon nomizo right
**アジャイル開発にまつわるトラブルが増えている印象があります。その背景として、アジャイル開発の案件が増加しているのが大きく影響しています。**トラブルの内容としてはウォーターフォール開発と変わるわけではなく、「完成している・していない」、「納期に遅れている」、「バグを修正してほしい」、「お金を払ってくれない」などの相談が多いですね。

#### balloon kishi left
確かに内容としてはアジャイル開発に限らず、システム開発で多いトラブルですね。なぜこのようなことが起こってしまうのでしょうか？

#### balloon nomizo right
特に上流工程において、クライアント（ユーザー）のシステム開発での自らの役割に対する理解が足りていなかったり、ユーザーとエンジニア（ベンダー）との間でのコミュニケーションが不足していたりすることが考えられます。

#### balloon nomizo right
アジャイル開発になると、コミュニケーションがより重視されることから、従来のウォーターフォール型の開発以上に、ユーザーとベンダーとの間のコミュニケーションの問題が発生しているように感じます。

#### balloon kishi left
その根本的な原因はどんなところにあるのでしょうか？

#### balloon nomizo right
必ずしもITに精通しているわけではない「ユーザー」と、ITについては専門的な知識を持つがユーザーの業務には必ずしも精通していない「エンジニア」では、共通理解も少なく、認識の齟齬がどうしても発生しやすくなります。

#### balloon nomizo right
すなわち、「ユーザー」は自らの業務や何をシステム化するかについて専門性を有し、他方で「ベンダー」はシステム開発について専門性を有しています。しかし、お互いに相手方の専門性については必ずしも精通していません。そのため、システム開発には「二重の専門性」が要求される等と表現することが多いです。

#### balloon nomizo right
例えば、「納期に遅れた」というトラブルは一見ベンダー側のみの責任のように思えますが、ユーザー側の都合で仕様が固まらずに実装期間を圧迫してしまった場合、ユーザー側にも問題があるわけです。

#### balloon kishi left
仕様についても、双方の思いにズレが生じることが多いのでしょうか？

#### balloon nomizo right
仕様についてユーザー側には「プロのベンダーが上手く汲み取って提案してほしい」という思いがあります。一方のベンダー側には「仕様にないものは開発しない」という主張があるのです。とはいえ、ベンダーはユーザーの業務に精通していないことが多いですから、この時点で既に双方の思いにズレが生じてしまっている場合も多々あるかと思います。

#### balloon kishi left
なるほど。ユーザーとベンダー、双方の思いが理解できます。

#### balloon nomizo right
**思いにズレが生じたまま開発が進んで納品された場合、ベンダー側からすると「仕様通りに作っているのだから追加開発の要望だ」として報酬を要求し、ユーザー側は「仕様通りにシステムが出来上がっていない、未完成だから報酬は払わない」主張するので、双方の意見が食い違いトラブルに発展するのです。**

## 重要な論点である「協力義務」と「プロジェクトマネジメント義務」

#### balloon kishi left
両者の主張は折り合わないように感じますが、どのような部分が論点になるのでしょうか？

#### balloon nomizo right
裁判ではよく「協力義務」と「プロジェクトマネジメント義務」について議論が交わされます。仕様の話でいえば、まずシステムはユーザーが使うものなので、何を作りたいかを知っているのはユーザーです。ですから、**どういったシステムを作るかという仕様をメインで作るのはユーザーであり、これをベンダーが把握するために必要な情報提供等の協力を行う「協力義務」がユーザーにはあります。**

#### balloon kishi left
たしかにそうですね。

#### balloon nomizo right
先ほどの納期遅延の例ですと、もし仕様が決められなくて実装時間が短くなったことが原因で納期に間に合わなかった場合、なぜ適切な時期までに仕様が決められなかったのかを考えます。仮に、ユーザーが仕様を利害関係者との間で調整できずに時間がかかったのであれば、ユーザーの責任も小さくないことが多いでしょう。

#### balloon nomizo right
ただ、ベンダーはシステム開発の実績を持っているわけですから、「こういうところはどうしますか？」と適宜質問を投げかけて詳細を詰めることで開発に支障がでないように働きかけたり、「この日までに要件定義が終わらないと納期までに納品できないですよ」とスケジュールを管理したりして、開発が円滑に進むようプロジェクトマネジメントを行う義務があります。

#### balloon nomizo right
実際問題、ユーザーはシステム開発のプロではありませんから、何をすれば良いのか分からないケースも多いので、ユーザーへの適切な働きかけが求められる場面も少なくありません。

#### balloon kishi left
ユーザーの業務実施や情報提供等を待っているだけでは、ベンダーは義務を果たせないケースもあるということですね。

#### balloon nomizo right
はい。協力義務とプロジェクトマネジメント義務については一義的なものではないので、開発がどの段階にあるのか、どういった状況なのかも踏まえ、過去の事案を参照するなどして双方が行うべき義務を理解することが必要だと考えます。場合によっては今後の事案の蓄積に期待することもあるかとは思いますが、大まかに言うとそれぞれが専門性を有する分野での役割を果たしているのかが重要なポイントです。

#### balloon kishi left
これらのトラブルはどうすれば防ぐことができますか？

#### balloon nomizo right
なかなか難しい問題ではありますが、**1つ大きなことは、お互いの役割分担を明確にしておく必要があるということです。**仕様を決定する上流工程であれば、必要に応じて「この日までにユーザー側でこの点に関する仕様を決めてください、そうでないと納期の延長が必要となります。」などといったミーティングの議事録を残すことが有効です。自らが必要な役割を果たしていることを記すとともに、ユーザーの役割を明確に記しておくと良いでしょう。

#### balloon nomizo right
双方の認識齟齬がないよう、またトラブルになった際に第三者から見てどちらに責任の所在があるかがはっきり分かるよう、各段階で証拠を残しておくことは非常に重要です。

#### balloon kishi left
議事録を取るにあたり、GoogleドキュメントやWordなど、形式はなんでも良いのでしょうか？

#### balloon nomizo right
まず、記載内容でのトラブルが生じないようにするため、議事録の内容が双方で確認されることは当然の前提となります。その上で、改ざんの問題に発展しないよう、アクセスログや変更履歴が残る方式を採用することが望ましいですが、メール、チャットなどから日時とやりとりされたファイルが特定できたり、双方の押印や電子署名により内容の変更がそもそもできなかったりといった場合であれば、形態は問いません。

## その問題の責任はどちらにある？「契約不適合責任」とは

#### balloon kishi left
システム開発は完了したけれども、後から何らかの問題が見つかって責任を問われる、といったケースもあるかと思います。

#### balloon nomizo right
**契約不適合責任が問題となる場面ですね。仕様との不一致やバグの発生を指摘され、ユーザーから修正を求められるという事例です。**仕様との不一致に関していえば、そもそもシステムの仕様は何だったのか、という点が問題となります。そして、この点を検討するにあたっては、もちろん仕様書が重要であることは言うまでもないですが、先ほどお話しした議事録の有無や記載内容も重要になってきます。

#### balloon nomizo right
特に、アジャイル開発では、仕様書が残っていない開発や、残っていても記載内容が必ずしも十分でない開発も珍しくありません。双方で仕様に関する認識の共有が十分になされていないケースも多いです。ユーザーとベンダーとが仕様に関する認識を共有できているかどうかは、契約不適合責任が争われる裁判でも重要な問題となってきます。

#### balloon kishi left
バグの不具合でトラブルになるのは、機能的に欠損しているといったことですか？

#### balloon nomizo right
そうですね。バグといっても程度は様々ですが、例えば、ちょっとした文字化けが発生してしまっているなどの軽微なバグが発生している場面では、ベンダーも修正をすることが多いということが影響していると思いますが、大きなトラブルに発展することは少ないです。

#### balloon nomizo right
他方で、システム稼働に影響が出てしまうと言えるようなバグが発生している場面では、ユーザーはシステムを利用できないわけですから、大きなトラブルに発展することも多いです。ただし、「ある機能が利用できない」とユーザーからの修正依頼があった場合、その機能がそもそもシステムの仕様に含まれていたのか、という点が争われることも少なくありません。

#### balloon kishi left
その他にもシステム開発におけるトラブルはどういった事例がありますか？

#### balloon nomizo right
プロジェクトの頓挫によるトラブルですね。納期を何回も遅らせたけれども、システムが完成しないため契約を解除したいという事態が起こりがちです。この場合、ベンダー側だけに問題があるように見える一方で、なぜ納期遅延が生じていたのか、それぞれが協力義務やプロジェクトマネジメント義務を果たしてきたのか、といった問題とも連動してきます。

#### balloon kishi left
この場合、どのようなトラブルになるのでしょうか？

#### balloon nomizo right
頓挫するまでにかかった費用をどうするかという問題ですね。ユーザーがそこまでに出来上がっていたシステムを他のベンダーに引き継いで開発してもらう場合を除けば、ユーザーはシステムでの利益が得られなかったわけで、完成していないシステムそのものに価値はないと考えるのが通常です。その中でベンダーの稼働に対してどう報酬を算出するのかは非常に難しいです。基本的には契約書でどのように定めているかが論点になります。

#### balloon kishi left
契約書に定めていないということはあり得ますか？

#### balloon nomizo right
意外と多いです。人月単価で工数を算出するというのは1つの考え方ですが、それをユーザーが納得できないケースもあります。もちろん裁判によって利益相当額の請求を出来るケースもありますが、やはり契約書で定めていないと揉めることが多いので、契約書をきちんと定め、双方で合意してから進めることをお勧めします。

## よくあるエンジニアの誤解「準委任契約は責任が軽いのでは？」

#### balloon kishi left
SESでありながら常駐先から指示を受け、これは従うべきなのかと迷うエンジニアも多いかと思いますが、そういったケースはどう対処したら良いでしょうか？

#### balloon nomizo right
SESという契約類型が法律の契約類型に存在しているわけではありませんので、当事者間での認識と実際の契約類型がはっきり合致していない場合も多く、準委任契約という名称で契約が締結されていても、その実質は「労働者派遣契約」であると捉えられる場合もあります。実際に労働者派遣契約なのであれば、常駐先の指示に従う必要があります。

#### balloon nomizo right
他方で、単なる準委任契約の場合は、責任者等を通して指示を受けなければ、偽装請負のおそれがありますので、常駐先から直接指示を受けて従うことは控えるべきでしょう。いずれにせよ、契約類型を把握することが必要となりますし、それを把握しているのは会社ですので、常駐前に会社に確認しておくべきです。

#### balloon kishi left
準委任契約において気をつけるべき点はありますか？

#### balloon nomizo right
世の中で誤解されていることが多いと感じるのは、準委任契約は請負契約よりも責任が軽いと捉えられていることです。

#### balloon nomizo right
準委任契約では、請負契約とは異なり、システムを完成させる義務を負うわけではありませんが、善管注意義務を負っています。善管注意義務とは、誤解を恐れずに簡単に言えば、ベンダーとして、システム開発のプロとしての義務を果たすという義務です。すなわち、準委任契約の場合、完成義務は負いませんから、もしある時期までにシステムが完成しなかった場合でも、完成しなかったこと自体に対する責任が直接的には問われません。
ただし、善管注意義務を負っていますから、プロとしての義務を開発期間中に果たしていたかという中で、システムが完成しなかったことも考慮される可能性があり、完成しなかったことに対する責任を負うべきかどうかも間接的には問われるわけです。

#### balloon kishi left
なるほど。エンジニアが覚えておくべき法律知識ですね。

## ソースコードの著作権問題はChatGPTでも発生するかもしれない

#### balloon kishi left
ソースコードの著作権に関しても、エンジニアが知っておくべきことがあれば教えてください。

#### balloon nomizo right
著作権は基本的にソースコードを書いたエンジニアに帰属します。会社に所属している場合は会社に帰属することがほとんどでしょう。

#### balloon nomizo right
ところで、よく契約書で、発注者側に著作権を移転するという内容がありますが、例えばコードを再利用するかどうかという点から、著作権を移転して問題ないか、移転するとしてもすべての著作権を移転してよいかどうかは考えるべきポイントです。もし著作権を移転するとしても、OSS（オープンソースソフトウェア）などのいわゆる第三者ソフトウェアの著作権は移転できません。この点は見落とされがちですので、万一のトラブルが生じないようにするためにも、その点は契約書に記しておくことが重要です。

#### balloon kishi left
そもそもOSSは自分で作ったソフトウェアではないですしね。

#### balloon nomizo right
そうですね。「ベンダーはソフトウェアが第三者の権利を侵害していないことを保証する」と契約書に記載することも多いですが、これもそれでよいのかは慎重に考えるべきポイントです。
特にOSSは、そのライセンスで第三者の権利侵害がないことが保証されていないことがほとんどです。ですので、エンジニア、ベンダーとしては、万一OSS部分に第三者の権利侵害があった場合に備え、OSS部分も含めて第三者の権利侵害がないことを保証すると契約書に本当に明記して良いのか、今一度考えていただく方が良いと思います。

#### balloon kishi left
ChatGPTに関連して、今後増えていくと想定されるトラブルはありますか？

#### balloon nomizo right
著作権の問題はChatGPTでも発生すると考えられます。例えばChatGPTにプロンプトを入れてコードを吐き出してもらった場合、たまたま誰かが著作権を有しているコードと全く同じものが出てきてしまうかもしれません。この場合、著作権侵害が成立するかどうかは議論のあるところですが、言い換えれば、そのコードをそのまま納品してしまうと、著作権を侵害してしまう可能性もあるということです。

#### balloon kishi left
ChatGPTに頼り過ぎるのはリスクが高そうですね。今は議事録の生成などをChatGPTやAIに任せるということも多いようですが、その辺りはいかがでしょうか？

#### balloon nomizo right
企業でもフリーランスでも案件を受ける時にはNDA（秘密保持契約）を結んでいると思います。そのNDAにより、コードやミーティングでのメモの内容などが秘密情報に該当する場合、ChatGPTにコードを入力してリファクタリング等の何らかの出力をさせたり、ミーティングでのメモを入力して議事録を作成させたりすることは、先方に無断でChatGPTの開発元である第三者のOpenAIに情報を開示しているとして、NDA違反となる可能性があります。そういった観点からもNDAの内容をしっかりと確認し、必要に応じて事前に先方にChatGPTを利用することの同意を得るなど、トラブルとならないように備えておくことが重要です。

#### balloon kishi left
最後に、フリーランスのエンジニアや委託会社が気をつけるべきことはありますか？

#### balloon nomizo right
今年になって、「特定受託事業者に係る取引の適正化等に関する法律」、いわゆるフリーランス新法が成立しました。まだ検討されている最中の部分もあり、すべての詳細が明らかとなっているわけではありませんが、現時点でわかっていることとしては、下請法と同趣旨の規定がフリーランスにも適用されたり、フリーランスの出産、育児や介護への配慮が求められたりすることとなっています。来年には施行される予定ですので、契約書で新たにチェックするべき事項が増えることになるでしょう。フリーランスの方も、自らを法律で守るために、これを機に契約書をしっかりと確認いただければと思います。

大学卒業後、構成作家・フリーランスライターとして、幅広いメディア媒体に携わる。現在は採用関連のインタビュー記事や新卒採用パンフレットの制作に注力しながら、SaaS企業のマーケティングにも携わっている。いま一番関心があるのは、キャンプ場でワーケーションできるのかどうか。

岸 裕介

野溝先生

システム開発で起きがちなトラブルとその要因

ユーザーとベンダー、それぞれが守るべき義務とは

トラブルを回避するためにエンジニアができること

【弁護士が解説】エンジニアが知っておくべき「トラブル回避」の法律知識

ブロックチェーン技術を活用した電子マネーとして利用されている「暗号資産」。年々市場が拡大している一方で、取引所のハッキングなどのニュースを見聞きし、セキュリティ面に不安を感じている方も多いのではないでしょうか。

国内トップクラスの取扱銘柄数と暗号資産取引量を誇る暗号資産取引所「bitbank」を運営しているビットバンク株式会社では、透明性の高い暗号資産技術であらゆる価値を流通させることに取り組んでいます。

今回は、暗号資産のサイバーセキュリティ対策のポイントや、エンジニアに求められるスキル、ユーザーが注意するべき点などを、執行役員 CCRO 橋本 健治氏に伺いました。

ビットバンク株式会社
執行役員 CCRO（Chief Compliance Risk Management Officer）
通信事業、エンターテイメント事業、決済代行事業のサービスおよび社内の情報セキュリティ業務を経験し、2018年9月よりビットバンクにSIRTとして参画。コンプライアンス・リスク管理部門を統括し、セキュリティ技術、ISMS、セキュリティ関連法規制対応等、情報セキュリティ業務全般の責任者。CISSP/CISAを保有。

## 暗号資産の「取引所」と「販売所」の違いは？

#### balloon kishi left
暗号資産の基本から教えてください。そもそも、「仮想通貨」と「暗号資産」は何が違うのでしょうか？

#### balloon hashimoto right
通貨としての違いはありません。元々は仮想通貨と呼ばれていましたが、2020年に金融庁が「暗号資産」に呼称を改めています。

#### balloon kishi left
暗号資産は従来の金融取引と比べて、どのようなリスクがありますか。

#### balloon hashimoto right
暗号資産はこれまでにない自由な資産であるため、「マネーロンダリング」など、一般的な貨幣であれば摘発される可能性が高い犯罪行為をかいくぐるケースもあります。技術と法的規制の整合性を取るのが難しい分野ですが、日本では2018年の暗号資産流失事件をきっかけに、業界全体で規制やセキュリティの強化が進んでいます。

#### balloon kishi left
なるほど。貴社では、暗号資産の「取引所」と「販売所」を運営していますが、この2つはどのように違うのでしょうか？

#### balloon hashimoto right
まず「取引所」は、利用者同士に暗号資産の売買の場を提供します。売却を希望しても買い手がいないと売買が成立せず、成立したときにだけ運営している当社が手数料を受け取ります。

#### balloon hashimoto right
もう1つの「販売所」は、利用者と暗号資産交換業者が直接取引します。業者が売り買いするためすぐに取引が成立しますが、取引所に比べると手数料が高い傾向にあります。**暗号資産取引が初めての場合、「販売所」の方が使いやすいのですが、ある程度慣れてくるとオープンな「取引所」にシフトする方が多いですね。**

#### balloon kishi left
そういった違いがあるんですね。貴社の特徴や強みについても教えてください。

#### balloon hashimoto right
暗号資産交換業者は、金融機関とスタートアップ両方の側面があります。金融機関としてお客様の大切な金融資産を守るために「資金決済法」などの法整備がされており、遵守する必要があります。その一方で、最先端のデジタル技術を活かし、既存の枠組みを越えた通貨である暗号資産を取り扱う点では、スタートアップといえます。

#### balloon kishi left
エンジニアの開発環境についてはいかがですか？

#### balloon hashimoto right
外部に開発を委託するのではなく、エンジニアを自社で採用し、セキュリティ対策も考慮してシステム開発を内製化するようにしています。取引所システムのみならず、暗号資産やブロックチェーンについても知見を持ったエンジニアが活躍しています。

## 暗号資産を守る「コールドウォレット」

#### balloon kishi left
暗号資産のセキュリティについて詳しく伺う前に、暗号資産の土台となるブロックチェーンシステムの仕組みについて教えてください。

#### balloon hashimoto right
ブロックチェーンは日本語では「分散型台帳技術」とも呼ばれます。分散型台帳技術は、端末同士でデータファイルを共有できる「P2P（ピアツーピア）ネットワーク」を採用しており、一般的な情報システムやデータベースのように特定の管理者が集約的にデータを管理するわけではありません。

#### balloon hashimoto right
ユーザーが取引を行うと、取引データが、P2Pネットワークに繋ながっているPCやサーバー上の分散台帳へ記録が残る仕組みです。内容自体も暗号化などはされておらず、台帳情報を見るとどのウォレットアドレスからどのウォレットアドレスへ送金を行ったかの送金履歴が全てが記録されています。そのため、非常に透明性が高いといえます。

#### balloon kishi left
ありがとうございます。暗号資産はサイバー攻撃を受けることも多いと思いますが、今までに起こったセキュリティに関する事件としては、どんなものがありますか？

#### balloon hashimoto right
代表的なものは2018年に起きた、不正アクセスによって、暗号資産の一つである「NEM（ネム）」が約580億円分流出したという事件です。

#### balloon hashimoto right
暗号資産関係の会社はセキュリティに細心の注意を払っていたのですが、それでも事件が起きてしまいました。その他に、2019年に約35億円分の暗号資産流出事件が起きるなど、その頃は国内の他取引業者でも被害に遭っていましたね。

#### balloon kishi left
事件後にはどのようなセキュリティ対策が行われたのでしょうか？

#### balloon hashimoto right
会社の資産とお客様の資産を別々で管理するとともに、お客様の資産は「コールドウォレット」に保管するよう法規制にて義務付けされました。

#### balloon hashimoto right
ウォレットとは、暗号資産を保管する財布のことで、コールドウォレットはインターネットと接続していないクローズドな状態で秘密鍵を管理するウォレットを指します。お客様の資産をコールドウォレットで管理することで、セキュリティの向上につながります。**コールドウォレットの義務付けからは、国内で暗号資産の流出事故は起こっていないと思います。**

#### balloon kishi left
コールドウォレットは非常に効果が大きいんですね。

#### balloon hashimoto right
はい。システムへの侵入など攻撃のほとんどは、インターネットを経由して行われます。インターネット上に提供しているシステムは、何かしら攻撃を受けて情報を抜かれる可能性があります。

#### balloon hashimoto right
ただし、インターネットと接続している「ホットウォレット」も利便性の面で必要です。出金依頼があった時に、コールドウォレットから手作業で出金のオペレーションを行うのは非常に時間と手間がかかり、要請に対してタイムリーにお応えできません。そのため、各社ではホットウォレットに会社の自己資産を置いておき立て替えて出金対応したり、ホットウォレットへ一時保管するお客様資産と同等の会社の自己資産を用意し万が一の際に備えるなど、お客様の利便性とのバランスを取りながらセキュリティ対策を進めています。

#### balloon kishi left
貴社ではどのように暗号資産を守っているのでしょうか。

#### balloon hashimoto right
コールドウォレットでお客様資産を管理するのは当然のことながら、ホットウォレットには、お客様の資産は全く置かず、ビットバンクの資産をそこに置いています。万が一、ホットウォレットの暗号資産を盗まれたとしても、被害に遭ったのはあくまでも私たちの資産なので、お客様に影響はありません。さらに、資産コントロールを徹底しており、資産を盗まれても事業継続には支障が出ないようにしています。

#### balloon kishi left
なるほど。暗号資産のセキュリティについて、業界全体での取り組みもあればお聞かせください。

#### balloon hashimoto right
暗号資産業界全体の自主規制団体として、「一般社団法人日本暗号資産取引業協会（JVCEA）」があり金融庁から認定を受けています。同協会では、各法令や法令に基づいた事務ガイドラインよりもさらに厳しい基準の規制を設けており、暗号資産交換業を営む場合は同協会への加盟が必要です。当協会から定期的な検査・監査を受け、業界全体のセキュリティ強度が高まっています。

## 「ドメイン名ハイジャック」を教訓に独自の対策を実施

#### balloon kishi left
貴社が遭遇したインシデントがありましたら、お聞かせください。

#### balloon hashimoto right
2020年にドメイン名を乗っ取られる「ドメイン名ハイジャック」の被害を受けました。サービスサイトのドメインは無事でしたが、会社のメールアドレスのドメインがハッキングに遭いました。私たちの管理するシステムではなく、利用していたドメイン登録サービスがハッキングされました。

#### balloon kishi left
その後どのような対策をしたのでしょうか？

#### balloon hashimoto right
まずは、2つの認証方法を組み合わせる「2要素認証」に対応したドメイン登録サービスに切り替えました。さらに独自で、ドメインとIPアドレスを紐づける「DNS」の情報が書き換えられていないか、外部から定期的にチェックし、自分たちが何もしていないのにもかかわらず、DNSの変更が起きたらすぐにわかるよう、アラート通知が届く仕組みも構築しています。

## 「気づき力」がサイバーセキュリティを支える

#### balloon kishi left
サイバーセキュリティ業務では、リスクをどのように可視化していくのでしょうか？

#### balloon hashimoto right
**当社では、「情報資産ベース」と「事業被害ベース」の両面からセキュリティアセスメントを行っています。**「情報資産ベース」の評価は一般的に行われているもので、社内にどのような情報資産があるか洗い出し、情報資産に対して考えられる脅威や脆弱性、セキュリティ対策がしっかりされているかを点数化し、リスクをスコア化します。

#### balloon hashimoto right
「事業被害ベース」の評価は最近登場した考え方で、特定のシステムに対し被害を発生させるために必要な侵入の仕方や経路を洗い出し、対策ができているかを一つひとつ確認して点数化していくという手法です。

#### balloon kishi left
「事業被害ベース」の評価を行うと、どんなメリットがあるのでしょうか？

#### balloon hashimoto right
「情報資産ベース」のセキュリティリスクアセスメントだけでは、詳細なリスクを可視化できないため、「事業被害ベース」の評価も行うことで安全性が高まります。

#### balloon hashimoto right
従来の「情報資産ベース」の場合、個人情報が入っているシステムのDBに対するセキュリティ対策を包括的に評価するという流れになります。一方で、**「事業被害ベース」の場合は、まずDBのなかの個人情報を盗まれるという事態を事業被害として想定し、そのDBにたどりつくルートなどを全て洗い出し、かなり細かく評価していきます。**どのようなルートがあるかを洗い出す工数だけではなく、どのような攻撃手段があるかの想像力も必要になりますが、その分セキュリティの安全性は大きく高まります。

#### balloon kishi left
2つの視点から評価することでより強固な対策ができるんですね。貴社の社内システムで実施しているサイバーセキュリティの強化策についても教えてください。

#### balloon hashimoto right
一般的な情報を取り扱う業務環境と、重要な情報を取り扱う業務環境のネットワークや端末を分離し、重要な情報を取り扱う環境はインターネットへの制限等、安易な情報の持ち出しを制限しています。こういった「境界防衛」と、守るべき情報にアクセスするものは常にチェックする「ゼロトラスト」のどちらも考慮してセキュリティ対策を行っています。

#### balloon hashimoto right
端末上で動作するMicrosoft OfficeやAcrobat Readerといったソフトウェアを使用していないのも、セキュリティ対策としてプラスになっています。業務で使うシステムはブラウザで完結しているので、Microsoft OfficeやAcrobat Readerの脆弱性を使ってマルウェアに感染させるといった攻撃は、当社のシステムに通用しません。

#### balloon kishi left
なるほど。さまざまな面から対策しているんですね。

#### balloon hashimoto right
当社のセキュリティに関する安心感をより高めるため、情報セキュリティマネジメントシステム（ISMS）の国際標準規格であるISO27001を取得しました。国内の暗号資産取引所が ISMS認証を取得することは初めての事例です。ISO27001は厳しい基準をクリアしないと取得できないので、セキュリティ対策が進んでいることを証明する指標の1つだと考えています。

#### balloon kishi left
外部機関の信頼できる評価も受けているんですね。サイバーセキュリティに携わるうえで、どんなスキルが大切なのでしょうか？

#### balloon hashimoto right
「気づき力」が重要だと思います。**論理的な思考も必要ですが、そもそも何が問題なのか気づけないと対策を立てられません。そのため、「気づき力」は非常に重要です。**

#### balloon hashimoto right
これはサイバーセキュリティだけでなく、情報セキュリティ全般、ひいては仕事全般に言えることかもしれません。また、セキュリティ対策を考えるときには、見つかった脆弱性がどのような攻撃に利用されるか想像しながら、マクロ的な視点とミクロ的な視点両方から対策を想像する必要があります。ミクロ的な視点では「OSに脆弱性があるとしたらどうすればよいのか」など部分ごとに考えていきます。マクロ的な視点では該当のシステムだけでなく利用する人手の運用を含め全体としてどのような手法であれば守れるのかを考えます。

#### balloon kishi left
マクロとミクロ、どちらの気づきも必要なんですね。

#### balloon hashimoto right
はい。セキュリティ対策は、1ヵ所でも穴があるとどうしても問題になってしまうので、全体的な視点が不可欠です。セキュリティ相談を受けた場合は、背景や運用フローの組み立てについて想像し全体を俯瞰しながら、問題がありそうなところを予想して詳細に検討する必要があります。

## ユーザーが実践するべき暗号資産のセキュリティ対策

#### balloon kishi left
暗号資産を利用する一般ユーザーにとって必要なセキュリティ対策についてお聞かせください。

#### balloon hashimoto right
ほとんどの方が、当社のような暗号資産取引所を利用すると思いますが、まず「不正ログイン」への対策が必要です。多くのサイトで、IDがメールアドレスになっています。パスワードリセットにおいて、登録したメールアドレスを使う場合が多いのですが、メールアドレスアカウント自体をハッキングされるケースが少なくありません。

#### balloon hashimoto right
メールアドレスのアカウントを乗っ取られた場合、暗号資産取引所のパスワードリセットすると乗っ取られたメールアドレスに連絡がいってしまいます。また、2要素認証などのセキュリティ対策をしていても、過去にメールで送付した本人確認書類の画像を取られ、2要素認証もリセットされてしまう事態も起きています。

#### balloon kishi left
さまざまなリスクがあるんですね。どのように対策すればよいのでしょうか。

#### balloon hashimoto right
メールアドレスのアカウントや暗号資産取引所に利用するパスワードは長めにするなどセキュリティ強度を高めるのがおすすめです。**「今日は頑張りましょう」といった文章的なパスワードであれば、ローマ字にすると長くなり、セキュリティが高まりますし、忘れるリスクも軽減できます。**また、暗号資産取引所の2要素認証を有効化するとともに、メールアカウントについても、管理画面に2要素認証が設けられているものの方がよいでしょう。

#### balloon kishi left
なるほど。不正ログイン以外で気をつけるべき手口はありますか？

#### balloon hashimoto right
偽のサイトに誘導する「フィッシング詐欺」ですね。この手口では、暗号資産交換所を語ったメールやSMSにフィッシングサイトへ誘導するURLのリンクがあるのですが、このURLリンクをクリックせず、暗号資産取引所が用意している専用スマホアプリケーションや事前にブックマークしているものを利用することが一番の対策です。

#### balloon hashimoto right
また、金融系でよくあるパターンとして、恋愛感情を抱かせて騙す「ロマンス詐欺」や儲け話で勧誘する「投資詐欺」にも注意が必要です。「送金して欲しい」と言われたら、まずは警戒しましょう。

## 「ステーブルコイン」の国内流通解禁で変わりゆく暗号資産

#### balloon kishi left
今後の暗号資産はどのように変化していくのでしょうか。

#### balloon hashimoto right
最近、法定通貨と連動することを目的に設計された暗号資産「ステーブルコイン」の国内流通が解禁されました。日本銀行でも、政府公認のデジタル通貨の発行に向けた動きがあります。こういった動きが進むと、一時期行われていたビットコイン決済のように、デジタルアセットの決済手段としての利用が活発化する可能性があると考えています。暗号資産交換業だけではなく、決済周りの業務を行う企業も増えてくるのではないでしょうか。

#### balloon kishi left
最後に、貴社で予定している取り組みについても教えてください。

#### balloon hashimoto right
デジタルアセットに特化した信託会社の設立に向けて準備を進めています。というのも、機関投資家の方々は暗号資産を新しい投機先として見ています。それに伴い、暗号資産をどこに保管するのか考える必要があるのです。

#### balloon hashimoto right
社会全体でも、より安全に暗号資産を始めとしたデジタルアセットを管理・保管してもらいたいというニーズは、今後さらに高まっていくのではないでしょうか。これからもビットバンクは、最適な暗号資産技術によってあらゆる価値を流通させ、誰もが自由になれる「オープンでフェアな社会の実現」を目指していきたいと思います。

橋本さん

暗号資産のセキュリティの現状とビットバンクが注力している対策

サイバーセキュリティを行ううえで「気づき力」が大切

暗号資産の一般ユーザーが気をつけるべき手口と対策

暗号資産の今後とビットバンクの展望

暗号資産のセキュリティ対策に必要なスキルって？ビットバンクのセキュリティ責任者が語るリスク管理の最前線

2023年「AWS Ambassadors」、「Japan AWS Jr. Champions」に選出された4名にお話を伺うため、日立製作所にお邪魔した編集部。

前編では、「AWS Ambassadors」と「Japan AWS Jr. Champions」に選出された感想や、優れたAWSエンジニアになるための秘訣についてお話を伺いました。

後編では、AWSが気になっているけれど詳しくは知らない、**IT業界のビジネスーパーソンに向けて、4名それぞれの視点からAWSの基礎知識や魅力について語っていただきました**。

**AWSをビジネスに活かせるシーン**や、**今注目しているAWSのサービス初心者におすすめのイベント**まで、エンジニアでなくても役に立つお話が盛りだくさんです！

日立製作所で活躍する「AWS Ambassadors」と「Japan AWS Jr. Champions」に聞いた！選出歴は仕事に役立ってる？【前編】

## これだけは知りたい！AWSの基礎知識

#### balloon satsuki_harada left
今更ですが、そもそもAWSはこれまでのクラウドサービスと何が違うのでしょうか？

#### balloon takumi_tomita right
それを語るにはまず、前提を整理しましょう。**クラウドサービスとは、インターネット上のプラットフォームでデータベースやストレージ、アプリケーション、人工知能などの多様なITサービスをインターネット越しに利用できるもの**ですね。

#### balloon satsuki_harada left
はい、代表的なクラウドサービスには、他にもMicrosoft AzureやGoogle Cloudなどがあります。

~~参考：[AWS公式サイト](https://aws.amazon.com/jp/what-is-aws/)~~

#### balloon takumi_tomita right
そうです。クラウドサービスをレゴブロックのように組合せて様々なサービスを作る事ができますが、AWSはこのレゴブロックが使いやすいんです。クラウドサービスを使わないシステム構築、**この対極にあるのがオンプレミスです**。

#### balloon satsuki_harada left
非エンジニアの読者のために解説していただけますか？

#### balloon takumi_tomita right
オンプレミスとは、ソフトウエアやハードウエアなど、システムを運用するために必要なインフラを企業が物理的に用意し、運用する形態を意味します。

#### balloon takasi_miki right
**クラウドサービスを利用すれば、大掛かりな設備を持たなくても、大規模なシステムを運用できる**ということですね。

### 240以上から選べる豊富なサービスが魅力

#### balloon takasi_miki right
AWSはご存じの通り、Amazonによって提供されています。Amazonはこれまで、通販サービスとして膨大なデータを処理するため、巨大なサーバーを運用してきました。その運用技術を応用したのがAWSです。

#### balloon takasi_miki right
2006年に米国でサービス提供を開始して、2011年に日本に進出、2019年には中東、バーレーンにデータセンターができるなど、粛々と世界進出を進めていますね。

#### balloon satsuki_harada left
クラウドサービスは他にも存在しますが、AWSはなぜ人気なのでしょうか？

#### balloon syunta_fukumoto right
**AWSの一番の強みは何と言っても、240種類以上もの豊富なサービスが常にアップデートされていることです**。単純にITリソースを貸し出すだけではなく、例えばデータベースサービスの中にはインフラの構築やメンテナンスを意識しなくて良いようなサービスもあります。ユーザーにとっては、使用するサービスの選択の幅が広がるという嬉しさがあるんです。

#### balloon satsuki_harada left
日立製作所では、AWSと他のクラウドをどのように使い分けていらっしゃいますか。

#### balloon takasi_miki right
こちらの判断で使い分けるというよりは、お客様の好みで選ぶことの方が多いですね。AWSに限らず、Microsoft Azureだったり、Google Cloudだったり、お客様ごとに、慣れ親しんだクラウドベンダーがいますから、**われわれは常に選択肢を持っておくことを意識しています**。

#### balloon takumi_tomita right
もちろん、お客様のやりたいことに対して、「AWSのこのサービスが使えます」と提案することもあります。そういう意味では、**サービスが豊富なAWSを使えるということ自体が選択肢を広げますよね**。

## ビジネスパーソンは、AWSから何を学べる？

### 日本企業がAWSに学ぶべきサービス開発のメソッド

#### balloon satsuki_harada left
AWSはなぜ、これほどの数のサービスを展開し、常に進化させ続けることができるのでしょうか？

#### balloon takasi_miki right
もちろん技術力もありますが、**一番大きいのは、企業文化ではないでしょうか**。Amazonは、昔ながらの日本企業とは真逆の方法でサービスを作っているんです。

#### balloon satsuki_harada left
面白そうですね。詳しく教えていただけますか？

#### balloon takasi_miki right
この業界では通常、新サービスをリリースしようとなったときに、まずは市場調査を行い、上に通すための企画書を作ります。さらに、現在の技術でそれが可能かどうかということを検証してから、スケジュールや予算を計算して、上層部のOKが出たら実際に開発を始めるんです。

#### balloon satsuki_harada left
イメージできます。

#### balloon takasi_miki right
ところが、AWSの場合は真逆です。**プレスリリースの形式で、社内に「こんなものを作ります」ということを宣言してから開発を始める**んですよ。

#### balloon satsuki_harada left
なるほど。小売業からITに参入してきたAmazonだからこそ、業界の常識を超えたサービスの構築が可能なんですね。

### IT業界が他業種から学べるものを大切に 

#### balloon takasi_miki right
私たちのように長い間IT業界にいる人間は、この業界に参入してくる企業をビジネス視点で観察することで、常に新しい発想のヒントを得るんです。

#### balloon satsuki_harada left
技術以外の情報収集も大切なんですね。

#### balloon takasi_miki right
実は、弊社でも2010年から、国産クラウドサービスを開始しています。**Amazonをクラウドベンダーの「ライバル」と見るか、他業界のノウハウをITで活かして業界に風穴を開ける「先生」として見るか。この違いが、自社の成長を分けるんじゃないかなと思います**。

#### balloon satsuki_harada left
三木さんご自身は、他業界からIT業界に進出してきた企業から学びを得る際、どこに着目するのでしょうか？

#### balloon takasi_miki right
**その企業の創業者やCEOの考え方やビジョンを見ていることが多い**ですね。Amazonの場合は、創業者で元CEOのジェフ・ベゾスがクラウドサービスの成功を経て、次に何に投資するのか、どんな技術に力を入れるのかというところに着目しています。

#### balloon satsuki_harada left
AmazonのCEOを退任した後は、宇宙ベンチャー「ブルーオリジン」を立ち上げて注目を集めましたね。

#### balloon takasi_miki right
「ブルーオリジン」では人工衛星やロケットの開発に取り組んでいますよね。今後は、こうした技術とクラウドやITがどのように結び付けられていくのかという部分が見どころじゃないかなと思います。

## 日立製作所のエンジニアが注目する、AWSの最旬サービス

### やっぱり気になる！トレンドの生成AIモデル

#### balloon satsuki_harada left
業界の最前線で活躍するエンジニアとして、皆さんがいま一番気になっているAWSのサービスを教えていただけますか？

#### balloon syunta_fukumoto right
やっぱり…今話題のAI系サービスですね。2023年4月にリリースされたばかりの、**「Amazon CodeWhisperer」（アマゾン コードウィスパラー）や「Amazon Bedrock」（アマゾン ベッドロック）**は、業界関係者に限らず、注目している方も多いのではないでしょうか。

#### balloon satsuki_harada left
みなさん頷いていらっしゃいますね。サービスの内容を教えていただけますか？

#### balloon kentarou_fukai right
CodeWhispererは、AIがコメントからコードを提案してくれる、いわゆる生成系AIです。Bedrockは、生成系アプリケーションの構築・拡張を支援するものですね。

#### balloon satsuki_harada left
AI系はトレンドとして注目度が高いですね。逆に、ご自身の趣味で追いかけているサービスなどがあれば、ぜひ聞いてみたいです。

#### balloon takumi_tomita right
僕の場合、個別サービスではないのですが、AWSが自社のデータセンター内の機能を高めるために独自に開発した「Scalable Reliable Datagram (SRD) プロトコル」には「ニヤッ」としてしまいます。また、**Amazon EC2の基盤技術とも言える「AWS Nitro System」（ナイトロシステム）**にはグッときますね。

#### balloon satsuki_harada left
マニアック！インフラエンジニア出身の富田さんならではですね。

### AWS初心者におすすめのイベントは？

#### balloon satsuki_harada left
みなさんは、AWSの有識者としてもAWSを学ぶ立場としても、さまざまなイベントに参加されていると思います。今後、AWSを学んでみたいと考えているエンジニアや非エンジニアの方が、AWSへの理解を深めるためにおすすめしたいイベントがあれば教えていただけますか？

#### balloon kentarou_fukai right
**初心者向けという意味では、[AWSが公式で開催しているウェビナー](https://aws.amazon.com/jp/events/aws-event-resource/?cards.sort-by=item.additionalFields.SortDate&cards.sort-order=desc)がおすすめ**です。中でも、ハンズオン（体験学習）で学べるものは、実際に手を動かして学べるので基礎を身につけるのに向いていると思います。※常時開催されているものではありません。

新しい記事