本稿の場面設定は , ソースコードを利用した立証をしたい ものの , ソースコードを所持していないことが前提となるの で , 以下 , 文書提出命令の問題に重点を置いて論じることとす る。また , 本稿では , 私文書たるソースコードに限定して検討 する。 3. 文書提出命令への壁 文書提出命令については , ニつの壁がある。 ーっ目は , 文書提出理由の有無であり , 民訴法 220 条が , 一般的に提出義務を法定しつつ , 同条 4 号イ ~ ホにおいて除 外事由を設けていることが問題となる。ソースコードでは , 特 に 4 号ニの専ら文書の所持者の利用に供するための文書 ( 自 己専文書 ) に該当するかが問題となるであろう。この点 , オー プンソースであったり , 契約当事者へのソースコードの提供 が約定されていたりすると , 自己専文書に該当するとはいえ ない。しかし , 特許権侵害のように , 契約関係にない当事者間 での紛争の場合 , ソースコードを提供すべき状況が考えがた く , また , ソースコードがノウハウの塊であることからすると , 自己専文書該当性が争われるように考えられる。 なお , 特許訴訟や著作権訴訟においては , 民訴法上の文書 提出義務除外事由である技術又は職業の秘密に関する文書 ( 民訴法 220 条 4 号ハ , 197 条 1 項 3 号 ) であっても , 正当な理 由がなければ提出を拒むことができないとされている ( 特許 法 105 条 1 項 , 著作権法 114 条の 3 ) 。 しかし , 実務上より大きな壁となるのは証拠調べの必要性 ( 民訴法 181 条 1 項 ) である。裁判所は , たとえ当事者が申し 出た証拠方法であっても , 取り調べの必要性がなければこれ を却下することができる。ここで , 文書提出命令の申立てにつ いての決定に対しては , 即時抗告ができるが ( 民訴法 223 条 7 項 ) , 申立てを却下した理由が , 証拠調べの必要性なしであ る場合は , 即時抗告ができす判決理由に対する不服申立手 段である控訴によらなければならない 7 。法文の定めに反する との見解もあり得ようが , そもそも却下決定に対する抗告と は , 口頭弁論を経ないで訴訟手続に関する申立を却下した決 定に対する不服申立てであり ( 民訴法 328 条 1 項 ) , 口頭弁論 を経てなされる裁判である判決に対する不服で賄われるもの は対象とならない。証拠調べの必要性なしとは , 換言すれば , これを取り調べなくても事実認定ができるとの証拠価値の判 断の問題であり , 自由心証主義 ( 民訴法 247 条 ) の問題であ るから , 判決に対する不服申立である上訴によって検討され るべき問題である 8 。 さて , 一般論としていうと , 文書所持者が書証として文書を 提出することについて , 裁判所が証拠調べの必要性をいちい ち精査し , 個別に採否を検討することはないといってよい 9 。し かし , 鑑定・検証・証人尋問・文書提出命令等 , 手続が重くな ればなるにつれ , 裁判所は , 証拠調べの必要性について慎重 な判断を行う傾向がある。これは , 証拠収集については , 第一 次的に当事者が行うべきという弁論主義の建前によるものと 考えられるが , それ故代替方法による立証が可能であり , か つ , そちらで心証形成が十分にできるのであれば , 必要性な しとして却下されることが多いといえるのである。 このことは , 主張立証責任を負う側が文書提出命令の申立 を行う場合 , 特に深刻になる。すなわち , 正面突破をしようと して文書提出命令を申し立てたら , 脇道で敗訴の心証を取ら れ , 本案ごと文書提出命令の申立ても却下されるという , 踏ん だり蹴ったりの状態ができることとなるのである。 1 。 なお , 手続面にも若千付言する。証拠調べの必要性の有無 については , 民訴法と特許法では若干異なる問題がある。す なわち , 当事者としては , 文書提出命令の判断が出る前は , 証 拠を見てもらっていないのであるが , それなのに必要性がな いとはどういうことか , という疑問が生じる。この点 , 民訴法 223 条 4 ~ 6 項は , 文書提出義務の存否を判断するために , 裁判所が , 裁判所限りで文書を閲覧することができる , いわゆ るインカメラ手続を定める。しかし , これはあくまでも文書提 出義務の存否の判断のための手続であって , 証拠調べの必要 性のための手続ではない。そのため , 証拠調べの必要性につ し、て , 同手続を利用することはできない。 一方 , 特許法 105 条 2 項は , 特許法上の文書提出義務の除 外事由である「正当な理由」を判断するためにインカメラ手続 を利用することができるところ , かかる正当な理由とは営業 秘密であることの他 , 訴訟追行上の必要性をも加味して総合 的に判断されるものとされており , 具体的には , 営業秘密の開 示により所持者が受ける不利益と書類が提出されないことに より申立当事者が受ける不利益が比較衡量されることとな る 11 。ただし , 特許法 105 条 2 項は , 当事者間でのみしか使え す第三者に対し提出を求める場合は , なお , 民訴法の規定に 7 最高裁平成 1 1 年 ( 許 ) 第 20 号同 12 年 3 月 1 0 日宰ー小法廷決定・民集 54 巻 3 号 1073 頁。 8 逆にいうと , 文書提出理由なしで却下する場合 , 取調べの必要性は肯定されているのであるから , 取調べをすれば心証が変わる可能性がある。そうすると , 当該審級における 判断を尽くさせる必要があるので , 抗告によって判断の誤りを是正させる必要があるといえる。 9 例外は , 時機に後れた攻撃防御方法である場合 ( 民訴法 1 57 条 ) や , 違法収集証拠等を理由とし証拠能力が争われる場合などであろう。 10 文書提出命令の申立てに対し , 独立した決定書が作られる事例もないではないが . 実務上口頭弁論終結の際には判断を留保し判決書において , 代替方法による心証形 成ができており , 必要性があるとはいえないとして却下される事例も少なくない。理論的には , 口頭弁論は , 訴訟が裁判をするのに熟したときに終結するので ( 民訴法 243 条 1 項 ) , 判断留保の状態で口頭弁論を終結するということは取り調べなくても裁判をするのに熟している , すなわち取調べの必要性がないといっているのに等しいといえる。ただ し , 口頭弁論終結後 , 判決書作成をしている際に取調べの必要性があると判断するに至り , 改めて口頭弁論を再開することもないとはいえないだろう。 1 1 中山信弘「注解特許法第 3 版」 ( 青林書院 ) 1 182 頁 5

第 1 部 1 . はじめに 民事訴訟におけるソースコードの取扱いについて 民事訴訟において , ソフトウェアの仕様が問題となる事例は いくつか考えられるが , その多くは , ①特許権侵害 , 著作権 侵害 , 不正競争防止法等を理由とする知的財産訴訟 , ②シ ステム開発に関連する損害賠償請求にニ分される。 1 これらの訴訟においては , 当事者からソースコードの提出 を求められることが少なくない。 しかし , 現実にソースコードを精査して判決をすることはあ まりないように思われる。例えば , 株式会社マネーフォワード の仕訳システムが , フリー株式会社の仕訳システムに関する 特許権を侵害していたか否かが問題となった裁判例 2 におい て , 原告であるフリー株式会社は , 株式会社マネーフォワード に対し , 仕訳システムのソースの開示を求めたが , 裁判所はこ れを認めなかった。 一方 , 技術者からすれば , ソースコードはノウハウの塊とい う意識があり , これを見れば請求の当否は一目瞭然であると の意識があるようにも思われる。 そこで本項では , 民事訴訟におけるソースコードの取扱に ついて検討し , 技術者と裁判所の発想のずれを考察したい。 弁護士法人淀屋橋・山上合同 弁護士・応用情報技術者伊藤太一 2. ソースコードの訴訟法上の取扱い ソースコードは , 訴訟法上 , 記載されている字面を問題とす るのではなく , 記載されている思想的意味内容を証拠資料と して収得するものであるから , 書証 ( 民訴法 219 条 ) として取 り調べられることとなる。 3 書証の申出は , ①所持者自ら提出する方法 , ②自ら所 持しない場合に , 所持者に文書の送付を嘱託する方法 , ③ 提出を拒む相手に対し , 文書提出命令の申立を行う方法があ る ( 民訴法 219 条 , 226 条 ) 。このうち , ②の文書送付嘱託に ついては , あくまでも任意の送付を嘱託するものであり , 裁判 所を介した嘱託がなされるとはいえ , 提出義務が課されるも のではないし 4 , 従わない場合の制裁もない。一方 , ③の文書 提出命令であれば , 命令の対象が訴訟当事者であって , かっ , これに従わない場合 , 裁判所は文書の記載に関する文書提出 命令申立人の主張を真実と認めることができる ( 民訴法 224 条 1 項 ) 5 。ただし , 第三者が従わない場合は , 決定で 20 万円 以下の過料に処せられるのみであり , 真実擬制効は働かない ( 民訴法 225 条 1 項 ) 。 6 1 平成 29 年 9 月 26 日午前 1 1 時の時点で株式会社工ル・アイ・シー提供の判例検索システムである判例秘書において「ソースコード」をキーワードとして民事事件全体を検索 したところ , 128 件がヒットした。概観ではあるが , そのうち , 1 00 件程度は知財訴訟であるように見受けられた。 2 東京地判平成 29 年 7 月 27 日。なお , 特許権侵害は否定されている。 3 なお , HDD や DVD に保存されたデータについても , 準文書として . 紙媒体としての文書に準じた規律が及ぶので ( 民訴法 231 条 ) , 以下 , 紙媒体によるかデータによるかを問 わず検討する。なお , データについては . 必要な場合 , プリントアウトして可読な状態にすることが想定されていることを理由に , データの提出義務が認められる場合 . これをア ウトブットするためのプログラムも提供する義務を負うという裁判例 ( 大阪高決昭和 53 年 3 月 6 日高民集 31 巻 1 号 38 頁 ) がある。 4 通説ではあるが , 近時 , 個人情報保護を理由とする提出の拒絶が頻発することで訴訟という公的手続における資料収集に支障を来しているとの問題意識から , 少なくとも 公法上の義務が課され , 開示について正当な理由があることを理論づけるものとして梅本吉彦「民事訴訟手続における個人情報保護」法曹時報 60 巻 1 1 号 3409 頁がある。 調査嘱託 ( 民訴法 186 条 ) が . 調査対象団体に公法上の回答義務を負わせることについては争いがないところ , 調査嘱託と文書送付嘱託で主体が , 裁判所と当事者という 点で異なるが , 手続保障の上での真実発見の要請という公益的目的に基づく制度であることにおいて両者に違いはない。また , 調査嘱託は , 当事者の主観に依らない客観的事 項について回答を求めることとされていることに鑑みれば , 裁判所が自らこれを調査しても公平性の問題がないので裁判所が主体となっているに過ぎないとも解しうること , 実務上も , 当事者からの申出に基づき裁判所が嘱託することがほとんどであることを併せ考えるなら , 文書送付嘱託の場合に公法上の義務を課して差し支えないと考える。 5 あくまでも文書の記載に関する主張であって , 文書から立証しようとしている事実について真実擬制が働くわけではないことに注意が必要である。ソースコードを例に取る と , ソースコードに「 p 「 in 廿 ("hogehoge つ」という記載があるとの主張が真実であると認められることがあったとしても , 当該記載が特許権を侵害しているという主張が真実と 認められるわけではない。また , 裁判所は , 真実と認めることが「できる」だけであって認めなければならないわけではないことにも留意が必要である。 6 ただし当該第三者が , 命令の対象者と実質的に同一とみられるような特別な関係があり , 命令の対象者が提出を拒ませているような場合等は , 法律上 , 真実擬制をするこ とができなくとも , 弁論の全趣旨 ( 民訴法 247 条 ) や訴訟上の信義則 ( 民訴法 2 条 ) によって真実擬制と同様の効果を及ぼすという立論があり得るように思われる。 4

よるしかない。 以上を要約すると , 技術者と法律家の間でソースコードに 対する見解の相違があるとすれば , 証拠調べの必要性が鍵に なると考えられる。では , どのように裁判所が証拠調べの必要 性なしと考えているのかを検討することとしたい。 4 知財訴訟におけるソースコード 誤解を恐れすにいうなら , 知財訴訟というのは , インテリジ ェンス間違い探しであるから , 侵害製品とされているもののソ ースコードを比較すれば侵害が明らかになるように思われる し被告側にとっても , ソースコードを比較させれば侵害して いないことが一目瞭然であるといえそうである。 しかし , ソースコード , 特にアルゴリズムが端的に表れてい る部分は , 正にプログラムのコア中のコアというべきであり , オープンソース化しない限り , これを競業他社に開示すると いうことはあり得ない。つまり , 攻撃・防御をする側いずれに とっても 12 , ソースコードを提出することは避けたいという事 情がある。 また , 知財訴訟では , 技術的範囲に属するか否カ功ー問題と なり , この点は , ソースコードを検討した方が良いのかも知れ ない。しかし一般論として , ソースコードをデッドコビーして いるというのは考えがたく , 結局は , ソースコード同士を比較 して , 技術的範囲に属するか否か , 特にアルゴリズムの解析が 問題となってしまうように思われる。そうであると , ソースコー ドを検討したところで , 得られるものが大きいとはいえないよ うにも考えられる。 一方 , 前記マネーフォワード事件では , 入力された摘要と出 力される勘定科目の比較を行った結果 , 異なる出力 ( より正 確には , フリー株式会社のシステムからは出現し得ない出力 ) が得られたことから , 特許権侵害を否定した。いわば , 入力と 出力という容易に可読な範囲から , プラックボックスとなって いる内部構造の非同一性を認定するという手法をとったとい えるし , 得られる成果が異なるのであれば技術的範囲に属さ ないともいえるのであるから , これで足りるともいえよう。そも そも , プログラムを作成する際には , 如何なる入力に対してど のような発想で出力をするかを検討しこれを実現するため の手段としてコーティングを行うのであるから , 入出力から得 られるもののほうがより本質的な特徴を捉えているといえる 場面も少なくないように思われる。 そうすると , 入出力等の内部構造を見なくとも技術的範囲 に属するか否かが判断できるのであれば 13 , ソースコードを 取り調べる必要性がある事例は限定されるのではないかと 考える。 5 システム開発訴訟におけるソースコード システム開発訴訟では , ユーザーから , べンダーが作成した ソフトウェアには瑕疵がある又は仕事として完成していない という主張がなされることが多い。ここで , ユーザーが求める 機能と現実のソフトウェアの差が瑕疵として主張されこの立 証手段としてソースコードを解読することが必要であると主 張される。 しかし , そもそもユーザーとべンダーの間で , ソースコード レベルで合意するということがあるのであろうか。現実には , ユーザー側が要件定義や要求スペックを定め , これを実現す るための内部設計についてはべンダー側が責任を持っという ものであると思われる。そうすると , 債務不履行といえるか , 或いは瑕疵といえるかは , 双方が合意した要件定義や要求ス ペックを満たしているか否かが問題となるのであってソース コードの出来不出来が , 直接 , 瑕疵の存在や債務不履行を起 訴づけるものではないように思われる。 なお , ソースコードにはバグがある場合が多く , これをもっ て瑕疵という主張を行うことも想定される。しかし , 開発する システムの規模にもよるが , 一般論としていうと , ソフトウェア 開発においてバグはつきものとさえいえるものであり , 些細な バグであれば保守の中で修復されることが多い。そうすると , 単にバグがあるからといっても , 当該部分だけで個別にバグ が修復できるのであれば瑕疵とはいえないように考えられる から , この点でもソースコードを見るべき必要性は乏しいよう に思われる 14 。 6 終わりに 以上検討したように , 一般論として , これまでに提訴されて いる民事訴訟の類型では , ソースコードそのものを利用しな ければならない立証というのは相当限定されるように思われ る。技術者からすると違和感があるところであろうが , 紛争が 起こってから , 過去を振り返り , 主張立証責任というルールの 中で解決する法的紛争において求められる立証と , As-Is か ら To - Be に向けてタスクを実現しなければならない技術者と して検討する際の資料が異なるということで整理ができない 出だろうか。もちろん , 筆者としても , ソースコードが必要とな る場面が存することを否定するものではない。しかし , 一般論 としていうと , ソースコードは判読が困難で , 裁判所において も , 敬遠される証拠の一つといって良いのではないかと思わ れる。そうであるなら , よりわかりやすい立証を行うという観 1 2 もっとも , 文書提出命令の申立てをする段階で攻撃する側は自分のソースコードも開示しなければならないことは覚悟ができているであろう。 1 3 もちろん 100 % 同じ入出力になると言うことは考えがたいが . 入出力から推認される刃しゴリズム部分が同一といえるかは検討できるように思われる。 14 著者が関与した判決ではあるが , 大阪地判平成 26 年 1 月 23 日判例時報 2278 号 83 頁が , 債務不履行に当たるか否かを判断する際の一般論として同旨のことを判示して いる。また , 東京地判平成 9 年 2 月 18 日判例タイムズ 964 号 1 72 頁も同様の判示をしている。 6

だった。契約書は偽造されたものだ。」と主張しているとしよ う。ここで、この契約書が信用できるかどうかを検討するに は、いくつかの推理を経る必要がある。 まず、契約書の最後の署名欄を見ると、売主の名前が手書 きで署名され、その横に売主の実印 ( 役所に届け出て、必要に 応じて印鑑登録証明書の交付を受けられる印章 ) が押印され ている。ところで、日本はハンコ社会であり、特に実印に対す る信用が厚い。それは、普通は実印を大切に管理しており、安 易に他人に貸したりはしないという前提があるからである。そ こで、紙面に実印が押印されているときは、その押印は本人 ( 売主 ) の意思に基づいてなされたものに違いないという推定 が働く。そして押印した者は、その書面に記載された内容が 自己の意思に反しているときに押印するようなことはないだ ろうから、押印が意思に基づいている以上、紙面に記載されて いる内容のとおりの意思表示があったのであろうという推定 が働く。 このような推論過程を、法律の世界では「ニ段の推定」と呼 んでおり、ニ段目の推定は法律で規定されている。すなわち、 民事訴訟法 228 条 4 項は、文書が紙媒体で作成される場合 において本人又は代理人の署名又は押印があれば、その文 書は真正に成立したものと法律上推定するとしている。「真正 に成立する」とは、署名又は押印をした者 ( 文書作成者 ) の意 思が表示されたものと認められるという意味である。もっと も、署名又は押印自体には、その文書がいつから存在したか、 作成後に内容が改ざんされていないかといった点について は、何の確実性も担保していない。文書が電子的なデータで あるとき、紙媒体における署名又は押印に代わる存在が電子 署名である。電子署名は、実印の保管のような経験則による 推定ではなく、暗号技術によって新たな推論過程を構築して いる。 2 電子署名 スマートコントラクトに活用されているプロックチェーンを 利用した仕組みにおいては、取引 (Transaction) を行う当 事者間での本人確認及び非改ざん検証において、公開鍵を利 用した電子署名の検証により行われる。プロックチェーン技 術自体の解説は後編に委ね、本稿ではまず電子署名の技術 的な仕組みを概観する。 ( 1 ) 電子署名とは 作成される文書が電子データの形式の場合には、筆跡鑑 定や印影の対照 ( 押印された跡と印章の比較 ) による文書の 真正な成立の確認を行うことができない。また、紙へ記録さ れる文書とは異なり、電子テータは容易に複製や改ざんがで きてしまうため、原本 ( Original) と複製 ( Copy ) の区別が本 質的に不可能である。そのため、電子テータについて民事訴 訟における証拠力を確保するためには、署名又は押印に代わ る電子テータ作成者の新たな証拠が必要となる。このような 要請をハッシュ関数と公開鍵基盤 ( PKI) という要素技術の組 み合わせにより可能とした技術が、電子署名である。 9 ここでいう電子署名とは、電磁的記録に記録された情報 ( 電子テータ ) について作成者を示す目的で行われる暗号化 等の措置で、改変が行われていないかどうか確認することが できるものをいうと法律上定義されている ( 電子署名及び認 証業務に関する法律 2 条 1 項 ) 。 ( 2 ) ハッシュ関数と公開鍵基盤 ( PKD 電子署名の仕組みが、ハッシュ関数と公開鍵基盤を用いて どのように作成者と改変が行われていなことを確認するかの 基本的な仕組みを図 1 に示す。ここでは、電子証明書を利用 した電子データの安全な送信方法についてのみ説明し、電子 証明書の発行処理及び認証局の働きについては詳論しない。 まず、①送信者は、電子データをハッシュ関数により変換し てハッシュ値を生成する。ハッシュ関数とは、任意長の電子テ ータから固定長のハッシュ値 9 という数列を計算する数学的 処理である。ここで用いられるハッシュ関数は、元の電子デー タが 1 ビットでも変化したら、ハッシュ値が非常に高い確率で 異なる値になる性質 ( 衝突耐性 ) 1 。と、ハッシュ値から元の電 子テータを逆算できない性質 ( 一方向性 ) を有している必要 がある 11 。 次に、②送信者は、このハッシュ値を電子証明書で証明さ れている公開鍵に対応する秘密鍵で暗号化する。この暗号化 された結果が電子署名である。公開鍵と秘密鍵は常にペアで 生成され、秘密鍵で暗号化された情報は対応する公開鍵での み復号可能である。秘密鍵は送信者のみが有しており、第三 者とは共有しない。 その後、③送信者は、電子データ ( 平文 ) と電子署名を結合 し、④先ほどの秘密鍵に対応する公開鍵を証明する電子証明 書とともに受信者へ送信する。⑤受信者は、電子証明書が失 効されていないかなどの電子証明書の有効性を、認証局 (C A) に対して確認した上で 12 、⑦公開鍵で電子署名を復号す る。そして、送信者のものであることが証明された公開鍵で電 子署名が復号できたということは、この電子署名は当該公開 鍵に対応する秘密鍵で暗号化されたことを意味している。 よって、この電子署名が秘密鍵の所有者である送信者によっ てなされたものであることが検証できたこととなる。 9 例えば、本稿脱稿時において時刻認証業務認定事業者が採用する SHA -256 というハッシュ関数を用いた場合には、元の電子データのファイルサイズにかかわらず、ハッシュ値 は常に 256 ビットとなる。 1 0 仮に衝突耐性が低いと、ハッシュ値が同じでも元の電子データが異なるおそれがあり、改変が行われていなし、か否かの検証 ( 手順⑧ ) にハッシュ値を用いることができない。 1 1 結城浩「暗号技術入門第 3 版」 ()B Creative 、 201 5 ) 174 頁 1 2 公開鍵基盤における認証局の役割は、誤解を恐れすに言えば、印鑑登録証明における地方自治体や法務局の役割と類似する。 1 7

利用の申込 ( 電子証明害 1 ) 3 電子証明書の取得 発行申請 ) 電子証明書 送信者 A さん ( 認証業務の利用者 ) A の公開鍵 電子証明書発行 認証局 電子証明書登録 有効性確認 電子証明害 リホジトリ : C 日 L 等を 格納し公表するデータ 電子データ ( 平文 ) 受信者日さん ( 検証者 ) 電子署名 電子証明言 A の公開鍵 有効な A の公開鍵 1 , →ロ A の秘巒鍵で暗号化 ハッシュ関数 2 結合 電子証明書 A の公開鍵 電子データ ( 平文 ) 十 電子著名 電子データ ( 平文 ) 送信 関数 ハッシュ 復号 ハッシュ値 6 ハッシュ値 8 ・改ざんの有無 一致→なし 不一致→あり ハッシュ関数 : 文字や数字などのデータ ( 入力値 ) を一定の長さのデータ ( 出力値 ) に変換する関数 図 1 電子署名・認証の仕組み ( 公開鍵暗号方式 ) 13 また、⑥受信した電子データ ( 平文 ) について、送信者と同じ ハッシュ関数を用いてハッシュ値を生成し、⑧先の手順⑦の 復号の結果得られたハッシュ値と同じであることが確認され たときは、ハッシュ関数が強い衝突耐性を有している限り、電 子テータが途中で改ざんされていないことが検証できたこと となる。 14 ( 3 ) 電子署名の法律上の取扱い 電子署名の法的な取扱いについては、紙媒体の文書におけ る署名又は押印と同様である。すなわち、「電磁的記録であっ て情報を表すために作成されたもの・・・・・・は、当該電磁的記録 に記録された情報について本人による電子署名にれを行う ために必要な符号及び物件を適正に管理することにより、本 人だけが行うことができることとなるものに限る。 ) が行われ ているときは、真正に成立したものと推定」される ( 電子署名 及び認証業務に関する法律第 3 条 ) 。 書面への押印から文書の成立の真正を推定する過程で、印 章 ( ハンコ ) が適切に管理され、本人以外は押印できないであ ろうという前提があったのと同様に、電子署名の場合には、 ( 電子署名を ) 行うために必要な符号及び物件を適正に管理す ることにより、本人だけが行うことができる状況、すなわち、電 子署名時の暗号化に使用された秘密鍵を適正に管理し、第 1 3 総務省「電子署名・認証・タイムスタンプ ~ その役割と活用 ? 」 ( 2009 年 3 月 ) 2 頁 三者にみだりに所持されないようにしていることが、電子署 名が付された電磁的記録の真正な成立の推定の要件とされ ているのである。プロックチェーン技術により、第三者が取引 履歴を改ざんするコストが上昇したため、結果的に非改ざん 証明は容易となっているが、そもそも秘密鍵を第三者に取得 されてしまった場合は、正常な取引として配信されてしまうか ら、暗号鍵の保管は極めて重要である。 ( 後編では、プロックチェーン技術を利用した非改ざん検証の 仕組みと、裁判所においてスマートコントラクトを証拠として 取り調べる方法を検討する。 ) ※なお、本稿中の意見に渡る部分は、すべて筆者の個人的見 解に基づくものであって筆者が所属する組織の見解を示す ものではない。 足立昌聰 東京大学工学部システム創成学科生体情報システムコース、同大学院法学政治 学研究科法曹養成専攻修了。弁護士登録後、外国法共同事業ジョーンズ・ティ 法律事務所を経て、現在は弁護士活動を休止し、特許庁で法制専門官として執 務中。情報処理安全確保支援士 ( 登録セキスペ ) 、弁理士、 MCPC 認定 IoT シス テム技術者 ( 中級 ) 。 14 秘密鍵が第三者に流出すると、送信者 A を装った第三者が送信者 A の秘密鍵を使って電子署名を生成できるため、受信者 B は、電子証明書上の公開鍵に対応する秘密鍵 の正当な保有者から送信されたと認識してしまう。秘密鍵が流出した場合には、速やかに電子証明書を失効させ、新たな鍵ペアを生成する必要がある。

証を取得します。認証取得の際に数台のサンプルに対して検 査があります。一方で、工事設計認証は、製品の設計図や、製 造段階の品質に対しての認証となります。技術基準適合証明 とは異なり、認証取得の際に検査をするのは 1 台だけです。モ ジュールに対しての認証、とすると、工事設計認証という名称 は若干の違和感を覚えるかもしれません。近年、部品の小型 化が進んで、無線通信機能をモジュール部品として作れるよ うになりました。それに伴い、「モジュール認証」という考え方 が生まれました。それに対する考え方は、 " 製品 " に対する認証 で「製品認証」と呼びます。日本では、モジュール認証への対 応方法として、モジュールを、「モジュール上の特定無線設備」 と定義し、従来の工事設計認証の制度で対応させることにし ました。その結果、工事設計認証を取得しているモジュールを 使用して商品を作れば、製品自体で技術基準適合証明を取 得しないでも、無線通信モジュールを使用し、モジュールメー カーが取得している工事設計認証の通りに設計することで電 波を送信することができる認証を取得済みの製品を作れるよ うになりました。モジュール認証の場合、認証取得の主体はモ ジュール部品のメーカーになります。認証済みのモジュール を使用して製品化した場合も、技適マーク及び技適番号を表 示する必要があります。ここで表示する技適番号は、モジュー ル部品メーカーが取得した工事設計認証の番号を転記する こととなります。 ちなみに、モジュール認証の制度が世界中のすべての国で あるわけではありません。例えば、アメリカ合衆国の FCC で は、モジュール認証の考え方はありません。製品に対して認証 を取得する必要があります。ただし、認証済のモジュールを使 用している場合、製品認証の取得が簡単になるという制度は あります。 余談ではありますが、 " 技適 " は日本独自の認証です。海外の 認証機関でも技適の取得をすることができますが、日本独自 とは言え、「 Giteki Ce はⅲ cation 」では通じません。英語に すると「 M 旧 Certification 」 ( 経産省認証 ) となります。海外 の認証機関や、部品仕入先などのやり取りをする際にはこ注 意のほどを。 簡単にまとめると、工事設計認証を取得しているモジュー ルを使用して製造した商品は、製品に対して技術基準適合証 明を取得しなくてもリリースが可能、ということです。 参考 総務省電波利用ホームページ http://www.tele.soumu.go.jp/j/adm/monitoring/summary/qa/g- iteki_ma rk/ 6 http://www.meti.go.jp/policy/consumer/seian/denan/index.htm 法令テータベース電波法 http://elaw s. e-gov ・ go.jp/search/elawsSearch/eIaws - search/l sg0500/detail?law 旧 = 325AC0000000131 ne rCode = 1 日本における無線通信機器の基準認証制度の概要 ( 総務省 総合通信基盤局電波環境課認証推進室 ) http:〃www.jate.or.jp/jp/chousa/contents/pdf/mic-mra.mu- sen01. pdf 無線設備の技術基準適合証明及び工事設計認証 一般財団法人テレコムエンジニアリングセンター (TELEC) https://www.telec.or.jp/services/tech/index.html 日本の「モジュール認証等」の検討状況℃ CJ ガイドライン WG http://www.tele.soumu ・ go.jp/resource/j/equ/mra/pd- f/24/j-05. pdf 3. PSE マーク PSE マークというものを聞かれたことのある方は多いかと 思います。では、 PSE マークとは何のことなのでしようか ? PSE マークの根拠法は、電気用品安全法です。 PS マークと は、この法律および関連する政令・省令などで定められた安 全基準に適当した電気製品に表示されるものです。 PS 特定電気用品 PS 特定電気用品以外の電気用品 電気用品を製造または輸入を行う事業者に対して、基準に 適合するようにすることは義務付けられています。しかし、技 適マークとは異なり、実は PSE マークを表示することは義務 付けられていません。したがって、 PSE マークがないからと言 って、直ちに適法ではない商品、ということではありません。 「電気用品」とは、建物に設置されているコンセントに接続 して、用いられる機械、器具又は材料のことです。 ( 電気用品安 全法第 2 条 ) そのうち、特に危険又は障害の発生するおそれ が多い電気用品を、特定電気用品として定めています。特定 電気用品に対しては、◇形の PSE マークが付されます。特定 電気用品、特定電気用品以外の電気用品の一覧は、経済産業 省のホームページに記されています。また、どの用品にあたる のかわかりにくいような用品や、同法の対象・非対称について 不定期に同省のホームページ 6 に法解釈についての情報が公 27

法社会制度のプロトタイプを作ろうというものだ。 具体的には、ドローン、シェアリングエコノミー、宇宙ビジネ スなど、社会に変革をもたらしうるテクノロジーや、それによ って生まれるビジネスを題材にして、それらが広まった社会で 必要な法や社会制度を描いてみるという取り組みである。 たとえばドローンであれば、 1 0 年後の社会において、ド ローンが普及した世界でどのようなサービスが生まれている のか、アイテアを出し合う。すると、個人に衛星のように張り 付くドローンや、地域の商品を運搬するドローンなどのアイデ アが出る。次いで、それらが実現するための、社会ビジョン、現 状における課題や悩み、ビジョンを実現する法社会制度を描 いていく。 1 日のワークショップなので、緻密に描き切れるも のではないが、法を創造するという視点で、社会像から必要 であろう制度までを考えることができる。 テクノロジーと法、そして政治 元々の執筆の命題であったハッカソンと知的財産権から大 きく論点が広がりすぎたが、これらはすべて一本の線で繋が っている。サービス創出の手段としてハッカソンがひろがると したら、ハッカソンとは、人々が体験できる新たな価値を表現 するプロトタイビングの場となる。解決すべき課題の具体的 な当事者が目の前にいて .IT で解決をはかる作り手が、ロジ カルな問いの整理と、工モーショナルな創意の発揮を通じて、 世の中に小さな一石を投じる。その一石は、ハッカソン以降の プロセスで、社会にボジテイプな変革をもたらすサービスと そのとき、法は新しい自由と秩序を獲得するための進化が 求められ、その議論は、法を扱う人々のみならず、課題の当事 者や解決の担い手たちとともに行われていくことになる。一方 で、規制と支援の両面で、人々の暮らしや産業の発展を支え た行政は、単体では課題解決のすべてを担うことができない。 最終的に創造されるべきは、ハッカソンを通じて生まれる サービスではなく、その先にある新しい自由と秩序である と考えた場合、法とは解釈のみならず、創造するものとして広 く認知を得るべきものであり、これまで行政が事実上大半を 担ってきた立法のあり方も、再検討の時期に達しているので はないだろうか。 たとえば、ハッカソンで経験を積んだシビックテックのエン ジニアが、地域の立法を担うために地方議会の議員になるか もしれない。オープンの定義に則った社会像を描き、憲法を語 る政党が現れるかもしれない。そのとき、彼の背後を支えるの はどんなプレイヤーたちであろうか。 灯工ンジニアと法を扱う人々に共通するのは、物事をロジ カルに考え、その整合性を強く意識する点である。現状の枠 の中で物事を整理するのではなく、あらゆる挑戦とそこから 生まれる多様なイレギュラーを包含した社会を描くべく、その 力を存分に活かしていく。ハッカソンはそのための小さな実験 の場だと感じてもらえれば幸いである。 原亮 みやぎモバイルビジネス研究会会長 / 工イチタス株式会社代表取締役社長 1974 年生まれ。東京都品川区出身。法政大学法学部政治学科卒。編集者・ラ イターを経て 20C4 年、仙台に拠点を置くモバイルコンテンツの制作プロダク ションへ入社をしてモバイル業界へ。営業、ディレクター、取締役等を歴任した のち、 2009 年、フリーランスへ転身。同年、地元行政、企業と「みやぎモバイル ビジネス研究会」立ち上げ。 2011 年 rFandroid EAST JAPAN 」設立。 20 14 年℃ lob Lab SENDA し代表幹事。団体や企業を立ち上げながら、地域 で自走する人や組織、社会を作るための活動を展開。地方を舞台に .IT など新し い分野で活躍するプレーヤーの輩出と場の創造を目指している。 2016 年 2 月 よりエイチタス株式会社を設立し、代表取締役に就任。主著に「アイテアソン ! 」 ( 2016 年、徳間書店、共著 ) など。 33

☆ 2016 / 10 / 15 ネットが生み出したボーダレス社会における情報発信と著作 前参議院議員山田太郎さま 【この年の参議院選挙で 29 万票という膨大な票を得たにも かかわらず落選した直後にお越しいただきました。有害図書 や TPP についてご講演いただきました】 2016 / 11 / 12 触感 VR によって生まれる新しいエンタメ体験とは H2L 株式会社代表取締役岩崎健一郎さま ☆ 2016 / 12 / 10 web メディアにおける SEO と著作権 - 各社の対応とこれか らの web メティア ランダープルー株式会社代表取締役 コンサルタント永江一石さま 【医療系情報サイト WELQ 問題が勃発した直後、 Twi れ er で 積極的に発言していらっしやった永江さんにお越しいただき ました。講演内容は下記にて寄稿しています。 永江一石さんが語った、 Web メティアにおける SEO と著作 権、その利活用例とは ? ℃ od Q MAGAZINE https://codeiq.jp/magazine/201 7 / 01 / 48532 / 】 2017 / 1 / 14 工ンタメ系業界の動向まるわかり ! ? 登壇者が気になる話 ~ 海 公益社団法人日本漫画家協会理事赤松健さま 株式会社 J コミックテラス取締役会長 賊版を倒せる唯一の方法 ~ 絶版書を用いた電子書籍ビジネスとアーカイプ構築 ☆ 2017 / 5 / 13 安高特許会計事務所安高史朗氏 株式会社ドワンゴ湯浅竜氏 株式会社コロプラ佐竹星爾氏 題をぶつけ合うエンタメ知財座談会 取り扱いについて投げかけられた点もあり、未解決な領域で 作者の確認が取れないままにネット上で流通している作品の 違法配信の現状を赤裸々にお話しいただけたことと同時に、 【大学の wifi からでは接続できないサイトまで、現状の漫画の 羽生雄毅さま インテグリカルチャー株式会社代表取締役 の成り立ちと最新事情に迫る 日本のオタク文化と似て非なる「海外のアキバカルチャー」そ 2017 / 6 / 1 0 あることを再認識しました】 ☆ 2017 / 7 / 8 「技術と法律」 ~ テータの利活用とテジタル時代の法律設計 ( 全体セッション ) ・オープニングセッション 政策研究大学院大学教授隅蔵康ー先生 ・「可視化法学の概要、ソフトウェアプログラマーから見た code ( ソースコード ) code ( 法令 ) について」 ソフトウェア工ンジニア芝尾幸一郎さま ・「ライプ演出でのレーザーや電波を発する際、国内外の電波 法などの規制をどう気づき安全を確保するか」 hi-farm Laserist, programmer 武内満さま ・「法律の壁を乗り越えるスタートアップ事例紹介」 バロット行政書士事務所行政書士新井秀美 ( 分科会 ) ・「レギュラトリー・サンドボックスの概要」 株式会社野村総合研究所 金融イノベーション事業本部 FinTech 研究室 上級研究員柏木亮ニさま ・「メガバンクがバブリッククラウドを採用する背景 ~ クラウ 弁護士日置巴美さま 弁護士法人内田・鮫島法律事務所 析を射程に捉える個人情報保護法から考える」 ・「技術と法律は友好関係を築けるか ? - 生体情報、テータ分 運営委員渥美俊英さま 社団法人クラウド利用促進機構 ドと金融庁 / 日 SC の最新動向」 35 http://cruel.org/candybox/law code innovation. pptx 】 こちら。 ンでのメイカー話もあり。トビックに上がった本など、資料は テクチャと読むべき本についてお話しをお伺いしました。深セ 【前回を踏まえ、この本を作ることも前提にあったのでアーキ 講師 : 翻訳家山形浩生さま 工ンジニアと法律家をつなぐ code とお互いを学べる書籍 ☆ 2017 / 10 / 14 ことが結構あるなと頭の中で整理された回でした】 様々な方面からお話しいただきました。この方向性でやれる は何なのかなど、全体セッションから分科会までの 3 時間を なければならないことは何なのか、また技術的にできること まぐるしいスピードで展開されている中で、本当に現状対応し 廃もしくは規制の趣旨を考え直さなければならない事例が目 【法律の規制があるものの、技術の発展による規制の緩和・撤

第 8 部 ハッカソンから考える法と政策制度 ~ いくつかの論点提示の試み みやぎモバイルビジネス研究会会長 / 工イチタス株式会社代表取締役社長 1 . ハッカソンの広がりと論点のはじまり 技術の一般化と作り手の拡大 の進化はあらゆるプロダクトやサービスを生み出し、人 々の生活に様々な利便性や快適さをもたらしている。クラウド やセンサー、 loT 、ドローン、プロックチェーン、 AR 、 VR 技術 も、一般の T 工ンジニアたちにとって扱いやすい水準となって きたことで、作り手も裾野へと広がり、少人数でユニークなプ ロダクトやサービスを生み出すことが可能となってきた。 そうした技術を扱って、大企業では実現しにくい創造的か つ革新的なプロダクトやサービスを世に出すべンチャー企業 や、さらには、新たな市場を開拓することで急成長を狙う、い わゆるスタートアップを目指す起業家の存在もクローズアッ プされている。 あらゆる人々が、市場に登場した新しい T を用いて、ユニ クなプロダクトやサービスを作れる環境が整ってきたことで、 即興と言っていいスビードで試作をすることも可能になって きた。この試作をイベントのような形で、人々が行う場が目立 つようになってきた。これがハッカソンと呼ばれる取り組みで ある。 活用が進むハッカソン ハッカソンとは、 Hack ( ハック ) と Marathon ( マラソン ) の 掛け合わせによる造語で、ハッカーと称される腕利きの工 ンジニアたちが、一堂に会して 1 日、 2 日の短期間で、アプリケ ーションなどの開発を試みる取り組みを指す。近年、国内でも サービスの試作品を開発するイベントとして、週末に開催 されるケースが増えている。 主催者は、企業であったり、自治体であったり SIT コミュニ ティと呼ばれる工ンジニアの勉強会や団体などが挙げら れ、目的も、企業によるサービス創出や、地域課題解決に資す るアプリケーションの開発 SIT と一次産業など異分野連携の 事例づくりなど多様化し、あらゆる場面での活用が進んでい る。 灯の活用によって、社会課題の解決や、新たなビジネスを 生み出せるのではないかという期待が、ここ数年で高まって 原亮 おり、実際、ハッカソンをきっかけに作られたアプリケーショ ンが、自治体と連携したサービスとしてリリースされるケース や、一次産業向けのサービスとしてリリースしたチームが、起 業をして全国展開をはかる事例も生まれている。 サービス創出の手段としてハッカソンがひろがることで、社 会と法、あるいは政策制度の領域に携わる者に、どのような 議論が求められていくのか。本稿でいくつかの論点の提示を 試みたい。 2. 知的財産権とハッカソン 漠然とした不安 ハッカソンを開催する際によく問われるのが、ハッカソンで 生み出された作品に発生すると思われる権利とその扱いにつ いてである。 この議論に入口で、ひとつ留意しておきたいのは、現場にお いてこの問いを提起するのが、知的財産権などの知識や理解 があるわけでもなく、また、何が問題として起こるのかを必ず しも具体的に想定していない人々が多いという点だ。 主催や運営する側にとっては、参加者が生み出す創作物に は何かしらの権利が発生し、権利とはすなわち何かしらの紛 争を起こしうる要素であり、ハッカソンとは、そうした紛争を 生み出す場になるのではないか、という漠然とした不安であ る。自治体主催でも、企業主催でも、それそれの担当者からこ うした声を聴くことがしばしばある。 参加者の間には、自分たちが生み出した作品にかかる権利 を、他の参加者や主催者に奪われてしまうのではないかとい う不安を抱く者もいる。実際、コンテスト形式で開催されたハ ッカソンで、受賞作品を利用する権利や発生しうる知的著作 権の一切を主催者に帰属させ、かっ対価の支払いも行わない とする規約が掲げられ、反発の声が多くあがったケースもあ る。 権利に対するイメージ こうした問いが発生する背景として、権利とは人と人の間 に、厄介ごとを生む不安要素であり、弱者にとって奪い取られ 29

技術の世界において、 工ンジニアがコンピュータを動作させるために組み上げるプログラムのことを 「コード ( Code ) 」と呼びます。 一方、法律の世界において、 3 足立昌聰 「技術と法律」共同編集代表 2017 年 10 月吉日 ここに「技術と法律」の準備号を刊行します。 2 つの「コード」が共に発展する一助となることを祈念し、 まだまだ試行錯誤の状況ですが、 「 Study Code 」です。 技術者と法律家の交流を図る会 技術者と法律家が、それそれ自身の分野の情報を他方に提供し、 もうひとつは、 「技術と法律」です。 自由に論稿を投稿できる 技術者と法律家が、技術と法律が交錯するテーマについて、 ひとつは、 2 つのプラットフォームを作ることにしました。 わたしたちは、技術者と法律家は互いの「コード」を理解するための場として、 2 つの「コード」が密接に関係する時代の中で、 人工知能や仮想通貨に対する規制論や、リーガルテックのような新ビジネスが勃興するなど、 交わることなく、それそれの進化を遂げてきました。 技術者と法律家という全く異なる人たちにより、 2 つの「コード」は、 「コード ( Code ) 」と呼ばれます。 立法者が、国や組織の行動のルールとして作り上げる法令のことも