社会保障・税番号大綱に対するパブリックコメントが募集されていたので、以下の意見を提出した。*1
（見やすいように、長い括弧には強調表示をした。）
（p.13 「3.番号制度に必要な3つの仕組み (1)付番」における、「国民一人ひとりに一つの番号が付与されていること（悉皆性）」「全員が唯一無二の番号を持っていること（唯一無二性）」との記述）
ひとりに一つの番号が付与されていることが「唯一無二性」であり、そのような唯一無二の番号が全員に付与されていることが「悉皆性」であるはず。
（p.13 「3.番号制度に必要な3つの仕組み (1)付番」における、「最新の基本4情報が関連付けられていること」との記述、およびp.13脚註10）
「最新の基本4情報が関連付けられていること」に対する脚註として、2点の理由が挙げられており、1番目の理由として、「同姓同名同生年月日の人同士を区別するために必要」とあるが、「番号」が付されて以降はその番号によって人が区別されるのであり、「同姓同名同生年月日の人同士を区別するために」基本4情報は「必要」ではないから、これは理由になっていない。また、2番目の理由として、「地方における社会保障給付や課税などを、どの地方公共団体が行うべきか定めるために必須」とあるが、その目的では、市区町村名しか必要としておらず、最新の基本4情報を必要とするわけではなく、何らかの方法で市区町村名のみ最新化すれば足り、基本4情報を「必須」とするのは誤りであり、理由になっていない。
理由を示せないのであれば、「最新の基本4情報が関連付けられていること」を、「番号」の特性から除外するべきである。
（p.26「II個人に付番する「番号」 1.付番」の(2)および(3)）
「住民票に当該「番号」を記録するものとする」とあるが、理由がない。
「出生等により新たに住民票に住民票コードを記載した場合には、後記第3 VII 1.に規定する番号生成機関から指定された、住民票コードに一対一対応した「番号」を書面により個人に通知する」という点に異論はないが、その事務のために、住民票に「番号」を記載する必要はない。番号生成機関から指定された「番号」を通知すればよい。新たに住民票コードを付番したとき以外（後に何らかの理由で「番号」の通知が必要になったとき）に「番号」の通知をする際には、住民票コードに対応する「番号」を番号生成機関から取得して通知すればよく、住民票に記載する必要はない。
大綱p.17の脚註13で、「情報連携基盤の構築に当たっては、将来的に幅広い行政分野における情報連携を可能とすることに留意する」とあるように、将来、「番号」以外にも、社会保障や税の分野以外で同様の番号が用いられるようになる可能性がある。それらを「番号その2」、「番号その3」等と呼ぶことにすると、「番号その2」や「番号その3」も、住民票に記載することとなるのか。
そうしたすべての分野の番号を住民票に記載することになれば、住民票が、情報連携基盤と同等の「符号」変換表としての機能を持つことになり、「符号」の変換が可能なのは情報連携基盤のみとする情報連携基盤の基本的意義が崩壊し、住民票を管理する住基ネットが情報連携基盤と同等の「符号」変換能力を持ってしまう。したがって、「番号その2」や「番号その3」を住民票に記載してはならない。
そして、社会保障と税の「番号」だけは例外的に住民票に記載するというのは不自然である。そうしなければならない理由がないのであれば、記載しないとするべきである。
（p.34 「（注2）」）
「「番号」を一定の関数、手順等を用いて変換することで（複数回にわたって変換することを含む。）、新たに符号を生成した場合であって、生成した符号が「番号」と一対一に対応する関係にあるときは、生成した符号についても、「番号」に該当することとする。」とあるが、「番号」と多対一対応の生成符号であっても、「番号」と一対一に対応する生成符号と同様に、プライバシー上のリスクを生じさせるものであるところ、このままの記述では、「多々一対応であるから一対一対応ではない」として、法の抜け穴となりかねない。よって、多対一対応のものも同様に「番号」に該当するものとするべきである。
例：「番号」が「12345」であるときの、MD5関数値は d577273ff885c3f84dadb8578bb41399 であるが、これに数字等を付け加えた d577273ff885c3f84dadb8578bb413990 や d577273ff885c3f84dadb8578bb413991、d577273ff885c3f84dadb8578bb413992、d577273ff885c3f84dadb8578bb413993、d577273ff885c3f84dadb8578bb413994 といった符号は、「番号」である「12345」に多対1対応する符号である。これらの符号が、「番号」に対応する「裏番号」として用いられる可能性がある。
（p.35 「2.「番号」のみで本人確認を行うことの禁止」）
「何人も、著しく異常かつ激甚な非常災害への対応等特別の理由がある場合をのぞき、「番号」のみで本人確認をしてはならない。」とあるが、これは、「番号」は「見える番号」であり、広く様々な事業者で業務上取り扱われる符号であって、秘密情報とはならないことから、「番号」が正しいことをもって本人確認とすることは、米国におけるSSNや韓国における住民登録番号の利用形態の実情のように、なりすましの温床となる（p.15参照）ことから、このように書かれたものと推察する。
しかし、大綱のこの記述では、「「番号」のみで」となっていることから、例えば、「番号」と基本4情報のみを用いる方法（「番号」と対応する基本4情報が一致することをもって本人確認とする方法）は禁止されていない。これは、「番号」を本人確認に用いるものであり、従来において基本4情報の提示だけでは本人確認として足りない場面において、「番号」を追加することによって本人確認として足りるとするのであれば、それは、「番号」によるなりすましの温床を生むものとなる。
よって、「「番号」のみで本人確認をしてはならない。」との記述は、「「番号」を本人確認の手段としてはならない。」と改めるべきである。
同様の記述が、p.15にもあり、「本人確認を行う際は、「番号」のみをもって本人確認の手段としない」とあるが、「本人確認を行う際は、「番号」を本人確認の手段としない」と改めるべきである。
（p.36 「2.「番号」の告知要求の制限」）
「何人も不当な目的で「番号」の告知を求めてはならない」とあるが、「不当な目的」とはどのようなものを指すのかが明らかでない。
p.36脚註23によれば、「法令に基づき「番号」を取り扱い得る事業以外に、他人の「番号」を知り得る業務」として、一般の事業者が「番号」の記されたICカードを用いた本人確認を実施する場合を想定し、「ICカードを挙示すること等が、実質的に「番号」の告知要求に当たり得ることから」という理由で、「一切の告知要求を禁止することは妥当でない」としているが、その一方で、「1.「番号」の告知義務」（p.36）として、「正当な利用目的で「番号」の告知を求められた者は、「番号」を告知しなければならず、正当な理由なく、「番号」の告知を忌避してはならない。」とある。
脚註23の想定は、例えば、レンタルビデオ店が会員登録時に本人確認のために当該ICカードの挙示を求める場合のことを含んでいると推察される（個人情報保護ワーキンググループの「個人情報保護方策の概要（座長試案）」より）が、そうすると、レンタルビデオ店による当該ICカードの挙示要求は、「番号」の告知要求に該当するものであり、かつ、「不当な目的」ではないことを意味する。不当な目的でないということは、正当な目的、すなわち「正当な利用目的で」する要求であることになるから、レンタルビデオ店からICカードの挙示による「番号」の告知を求められたら、求められた者は「告知しなければならず」、「正当な理由なく、「番号」の告知を忌避」することは違法となってしまう。これは明らかに番号制度の趣旨に反している。
また、レンタルビデオ店が会員登録のために番号の告知を求めることが「不当な目的」に該当しないのだとすれば、ほとんどの事業者の行為が「不当な目的」に該当しないことととなり、この禁止規定は死文化していることになる。
唯一無二で悉皆という「番号」と同様の性質を持つ住民票コードにおいても、住民基本台帳法第三十条の四十二〜第三十条四十三において、「何人も（略）住民票コードを告知することを求めてはならない」といった告知要求の禁止規定があり、そこには「不当な目的で」といった限定はない。住民基本台帳法のこの規定の趣旨に鑑みれば、同様の性質を持つ「番号」も同様に禁止規定を置くべきである。
そもそも、レンタルビデオ店が本人確認のためにICカードの挙示を求めるのは、「番号」を告知するよう求めているのではなく、結果として番号が告知されるにすぎないのであるから、「何人も「番号」の告知を求めてはならない」との規定であっても、レンタルビデオ店が本人確認のためにICカードの挙示を求めることは、この規定に違反しないのではないか。
法解釈上、それが違反することになると言わざるを得ないというのであれば、この規定を、「何人も「番号」を取得する目的で「番号」の告知を求めてはならない」などとすればよいのではないか。
（p.36 「4.「番号」を利用する個別法による罰則の検討」）
「番号」の取り扱いについての処罰規定について、社会保障又は税務の個別法に設けることを検討するとされているが、「本人確認等義務」、「告知義務」、「告知要求制限」、「虚偽の告知の禁止」のうち、「告知義務」と「虚偽の告知の禁止」と「本人確認等義務」については、社会保障や税務の業務の遂行のために必要な措置であるから、処罰規定を社会保障又は税務の個別法に設けることは自然であるが、「告知要求制限」については、業務遂行のために必要なのではなく、国民等のプライバシーを保護するための禁止規定であることから、XI章で記されている第三者機関による監督の対象とするべきである。
このことから、「告知要求制限」については、社会保障又は税務の個別法に設けるのではなく、番号法に処罰規定を設けるべきである。
また、「告知要求制限」についての違反行為に対する処罰は、唯一無二で悉皆という「番号」と同じ性質を持つ住民票コードと同様に、住民基本台帳法第三十条の四十三第4項および第5項等と同様の間接罰とするのが自然であり、間接罰のために必要な、勧告や命令の権限は第三者機関が担うのが相応しい。
（p.37 「5.「番号」に係る個人情報の閲覧、複製及び保管等の制限 (5)」）
「事業者又はその従業者等が業務により「番号」（法令に基づき「番号」を取り扱い得る事業により知り得た「番号」を除く。）を知った場合、当該「番号」を他人に知らせ、若しくは不当な目的に利用し、又は文書、図画若しくは電磁的記録に記録して保管してはならない。」とあるが、「不当な目的に利用し」の「不当な目的」がいかなる基準で定まるのかが明らかでない。
脚註26にあるように、このような規定の必要性が生じたのは、「「番号」が券面に記載されているICカードを本人確認書類として用いた場合」を想定してのことであるが、そうした事業者は、券面に記載された「番号」は一切使用する必要がないのであるから、「不当な目的」に限定することなく、一切の利用を禁止して何ら差し支えないはずである。
よって、「若しくは不当な目的に利用し」との記述は「若しくは利用し」に改めるべきである。
（p.41 「VII 「番号」を生成する機関 1.組織形態」）
まず、「「番号」を生成する機関」との用語が用いられているが、p.26では「付番」との用語も用いられており、「「番号」の生成」と「付番」が同一の概念なのか異なる概念なのかが判然としない。
p.26では「「番号」の付番に係る制度の所管は、総務省とする。」とある一方で、p.23の脚註19では、「付番機関について、社会保障制度や税制の改革の方向性に照らして「歳入庁の創設」の検討を進めるとともに、「まずはどの既存省庁の下に設置すべきか」については、基本方針を踏まえる。」とあるように、「番号」の付番に係る制度の所管は総務省に確定していないとの記述になっており、両者は矛盾している。
それにも関わらず、p.41には、「「番号」の生成を行う機関（以下「番号生成機関」という。）については、住民基本台帳法に規定する指定情報処理機関を基礎とした地方共同法人（地方公共団体のガバナンスが強化された特別の法律に基づく法人）とする。」と書かれており、これは、脚註19と矛盾した記述になっているか、さもなくば、「番号生成機関」と「付番機関」が異なるものとして書かれていると考えられるが、どちらなのか判然としない。まず、どちらなのかを明確にするべきである。
「番号生成機関」が「付番機関」とは異なるものであるとすると、「付番」の意義を、付番対象となるすべての個人に対して何らかの番号（「番号」ではなく一般的な意味での番号）を最初に付与することを言うものと解すれば、その意味での「付番機関」は、住民票コードを付与する機関こそが「付番機関」であって、その所管が総務省であるということに異論はない。
しかし、「「番号」の生成」は、総務省が所管する機関によって行う必然性がない。なぜなら、番号制度の導入によって情報連携基盤が整備され、どの情報保有機関も、情報連携基盤を通じて、（既に付番済みの）住民票コードに一対一対応した「符号（旧リンクコード）」を取得することができるのであるから、その「符号」を用いて、「番号」を重複なく自動的に生成することが容易にできる。「番号」に係る業務（社会保障や税務）を所管する官庁が「番号生成機関」を所管するのが自然であり、それを否定する理由もない。
p.41には、「「番号」は住民票コードと一対一対応する新たな番号であり、その付番は住民票コードの住民票への記載事務と円滑に連携して行う必要がある。「番号」の重複付番を防止し、付番事務を安定的かつ確実に実施するためには、「番号」の生成を一の主体が行うことが必要となる。」との理由を掲げて、番号生成機関を、「住民基本台帳法に規定する指定情報処理機関を基礎とした地方共同法人とする」としているが、「番号」の重複付番の防止は、情報連携基盤を通じた「符号（旧リンクコード）」によって自動的に達成されるのであるから、住基ネットの運営機関でなくても、「「番号」の生成」は確実かつ容易に実現できる。また、「付番は住民票コードの住民票への記載事務と円滑に連携して行う必要がある」というが、情報連携基盤があれば、「番号生成機関」が、住基ネットの運営機関以外であっても、当該事務は「円滑に連携して行う」ことができるのであり、これも理由にならない。
また、大綱p.17の脚註13で、「情報連携基盤の構築に当たっては、将来的に幅広い行政分野における情報連携を可能とすることに留意する」とあるように、将来、「番号」以外にも、社会保障や税の分野以外で同様の番号が用いられるようになる可能性がある。それらを「番号その2」、「番号その3」等と呼ぶことにすると、「番号その2」や「番号その3」についてまで、番号生成機関を「住民基本台帳法に規定する指定情報処理機関を基礎とした地方共同法人」（以下「地方共同法人」という。）とするつもりなのか。そうしたすべての分野の番号について番号生成機関を「地方共同法人」が担うことになれば、「地方共同法人」が、情報連携基盤と同等の「符号」変換能力を持つことになり、「符号」の変換が可能なのは情報連携基盤のみとする情報連携基盤の基本的意義が崩壊してしまう。したがって、「番号その2」や「番号その3」の番号生成機関を「地方共同法人」としてはならない。そして、社会保障と税の「番号」だけは例外的に「地方共同法人」を番号生成機関とするというのは、不自然である。
以上のように、番号生成機関を「地方共同法人」とする理由はなく、社会保障・税番号についてだけ番号生成機関を「地方共同法人」とするのは不自然であることから、社会保障・税番号の番号生成機関は、社会保障や税務を所管する官庁が所管するべきである。
（p.42 「VII 情報連携 1.「番号」に係る個人情報の提供等 (3)」）
「上記(1)(2)の際、「番号」は「民-民-官で広く利用される「見える番号」であることから、個人情報保護の観点から、これを直接、個人を特定する共通の識別子として用いてはならないこととする。」とあるが、これは理由になっていない。
「見える番号」だから「個人を特定する共通の識別子として用いてはならない」というのは理屈にならないし、「個人情報保護の観点から」というが、情報漏洩防止の観点からは、情報連携において「番号」を直接使うことも、使わないこと（情報連携基盤用の「符号」を用いる）ことも、どちらも脅威は同一であり、「番号」を「直接、個人を特定する共通の識別子として用いてはならない」とする理由にならない。
本当の理由が何であるかを明確にするべきである。
補足：推察するに、連携基盤において個人を特定する識別子の秘匿性が担保されなければセキュリティが保てないシステムを想定しているのであれば、「見える番号」だから「個人を特定する共通の識別子として用いてはならない」という理屈は成り立つが、そもそも、個人識別子の秘匿性に頼ったシステム設計は、情報セキュリティ上、不適切な設計であって、そのような設計をしてはならない。
（p.43 「3.情報保有機関が保有する基本4情報の住基ネット基本4情報との同期化」）
「3.情報保有機関が保有する基本4情報の住基ネット基本4情報との同期化」の「(1)」は、「番号制度導入時において」として、情報保有機関が保有する基本4情報を「住基ネットの基本4情報に突合するよう努めることとする」とあるが、まず、「突合するよう努める」は意味が判然としない。
番号制度導入時において必要となる突合作業は、情報保有機関が保有している個人情報を、情報連携基盤から与えられる「符号（旧リンクコード）」と紐付けるために、基本4情報の突合等によって紐付ける作業を指すものとして理解されるところ、「(1)」の記述は、「住基ネットの基本4情報と突合」ではなく、「住基ネットの基本4情報に突合」と書かれており、また、この節の見出しが「同期化」であることから推察にするに、これは突合のことを言っているのではなく、情報保有機関が保有する基本4情報を住基ネットの基本4情報に合わせる（合っていない場合は情報保有機関の方の基本4情報を変更する）という意味のつもりで書かれたものと考えられる。そうであるならば、まず、少なくともそのように書き直すべきである。
その意味であるとして、そのような記述は削除するべきである。情報保有機関が保有する基本4情報を、住基ネットの基本4情報に合わせる必要がない（番号制度導入時に突合作業によって、情報保有機関の保有する各個人情報が、住基ネットが保有する各個人情報と同一人であることの紐付けが行われれば、それ以降は、「番号」や「符号」によって個人が特定されることとなるのであるから、基本4情報は同一人か否かの判断に不要なものであり、情報保有機関と住基ネットとで基本4情報が一致している必要がない）のであり、このような努力規定を設ける理由がない。
同様に、「(3) (1)で住基ネットの基本4情報と突合した、情報連携基盤とつなぐ各情報保有機関が保有する基本4情報について、情報連携基盤とつなぐ各情報保有機関は、必要な頻度で住基ネットの基本4情報との同期化に努めることとする」とあるが、理由がない。
p.13の脚註10に、「最新の基本4情報が関連付けられていること」に対して2点の理由が挙げられているが、「同姓同名同生年月日の人同士を区別するために必要」との理由は、「番号」が付されて以降はその番号によって人が区別されるのであって、「同姓同名同生年月日の人同士を区別するために」基本4情報の同期は「必要」ではないから、これは理由になっていないし、「地方における社会保障給付や課税などを、どの地方公共団体が行うべきか定めるために必須」との理由は、その目的では、市区町村名しか必要としておらず、最新の基本4情報を必要とするわけではなく、理由になっていない。
また、もし基本4情報が常に同期化されることになれば、基本4情報が、「番号」に近い性質の（唯一無二かつ悉皆な）識別子の能力を持つこととなり、「番号」を一部の分野にしか用いないよう配慮したことや、情報連携基盤において情報保有期間ごとに異なる「符号」を用いて連携することとした意義が台無しとなって、連携基盤の「符号」変換方式は無用の長物ということになってしまう。
以上のように、同期化する理由がない上に、同期化することには問題があることから、「3.情報保有機関が保有する基本4情報の住基ネット基本4情報との同期化」の節全体を削除するべきである。
（p.44「4.情報連携基盤の運営機関」）
情報連携基盤が、情報保有機関ごとに異なる「符号」を用いて個人情報を連携するという、符号変換方式を採用しているのは、共通の識別子によって個人情報が管理されると、情報保有機関同士の結託によって個人情報がその識別子でマッチングされてしまうという「国家による一元管理」の問題が生ずると考えられ、これを避けるためであると考えられるところ、もし、情報連携基盤の運営機関が、情報保有機関でもあるならば、その情報保有機関は結託によって個人情報のマッチングが可能となってしまうのであり、そのような設計は、情報連携基盤の符号変換方式の意義を失わせるものとなる。
大綱p.44には「情報連携基盤の運営機関の具体的な組織の在り方については、引き続き検討する」と書かれているが、少なくとも、情報連携基盤の運営機関は、情報保有機関とならないところとする必要があり、情報連携基盤の運営機関には他の機関からの独立性が求められることから、情報連携基盤の運営機関と情報保有機関は所管官庁が同一であってはならない。
（p.44 「IX4.自己情報の管理に資するマイ・ポータル 4.運営機関」）
「マイ・ポータルの運営機関は、情報連携基盤の運営機関と同一の機関とする」とあるが、理由がない。
マイ・ポータルの運営機関には、利用者について関連する個人情報がすべて集約されることとなる。たとえ、すぐに個人情報を消去するよう運用したとしても、一元管理しようとすれば可能（たとえば、消去するまでの間にリアルタイムに情報を分析、集約するなど）である限り、マイ・ポータル運営機関は、国家による一元管理が可能な機関とみなされる虞れがある。
情報連携基盤は、「符号」の変換だけを担い、個人情報自体を取り扱わないことによって、国家による一元管理が可能な機関とならないようにすることができるのであるから、その点で、情報連携基盤の運営機関とマイ・ポータルの運営機関を同一とすることは避けたいところである。
しかし、マイ・ポータルをいずれかの情報保有機関が運営することも、その情報保有機関が、国家による一元管理が可能な機関となってしまうことから、これでは、国の機関ではどこもマイ・ポータルの運営を所管できないことになってしまう。
ここで、マイ・ポータルの利用が利用者の意志に基づくものであることに着目すれば、個人情報の集約は利用者のマイ・ポータルを利用する意思によって承諾されるものとして扱うことができると考えられる。個人情報の集約を望まない者は、マイ・ポータルの利用をしないという選択肢があるという考え方である。マイ・ポータルで個人情報が集約されるのは利用者の承諾によるものとすれば、マイ・ポータルは、情報保有機関や情報連携基盤が運営してもよいと言えるかもしれない。
しかしながら、マイ・ポータルは、自己情報の管理のための機能を提供するものであり、特に、自己の「番号」に係る個人情報についてのアクセス記録の確認の機能は、行政機関を単純には信用できない者が使用することにこそ意義があるものであるから、マイ・ポータルの運営機関を信用しない者が、マイ・ポータルを利用せざるを得ないという矛盾を抱えることとなる。
この矛盾を回避してマイ・ポータルを実現するには、マイ・ポータル運営機関を、制度の開始当初から複数用意して、利用者が信用する運営機関を選択して利用できるようにする必要がある。また、このとき、マイ・ポータルの運営機関に民間事業者が含まれることが望ましいと考える。
（全般）
報道機関の大綱についての報道では、「番号」が社会保障と税の6分野（年金、医療、介護保険、福祉、労働保険、税務）で共通の番号として使われる「共通番号制度」として報道されているが、大綱では、「共通番号」との語は用いられておらず、「番号」を一人ひとりに唯一無二の番号として位置付けてはいるものの、そのような唯一無二の「番号」を複数種類用意することを否定していない。大綱の書きぶりでは、「番号」が分野ごとに別の種類として複数用意されるものとして読解することも可能である一方、「番号」が6分野で共通の番号として用いられるものとして読解することもでき、どちらが計画されているのか判然としない。
大綱で導入を前提としている情報連携基盤は、情報保有期間ごとに異なる「符号」を用いて、情報保有機関同士で個人情報を連携するという、符号変換方式を採用しており、そのような仕組みを採用する趣旨は、共通の識別子によって個人情報が管理されると情報保有機関同士の結託によって個人情報がその識別子でマッチングされてしまうという「国家による一元管理」の問題、これを避けるためと考えられるところであるが、その一方で、「番号」が6分野で共通の番号として使われるのであれば、その6分野の間では、「番号」を用いることで個人情報のマッチングが可能となるのであって、情報連携基盤で符号変換方式を採用していることの意義が失われてしまう。
もっとも、情報連携基盤は、社会保障・税番号のためだけに用意されるものではなく、「将来的に幅広い行政分野における情報連携を可能とする」（p.17脚註13）ものであるから、社会保障・税の「番号」が6分野共通であるとしても、情報連携基盤の符号変換方式が無用なものとまで言えるわけではない。
しかしながら、そもそも、このような符号変換方式による情報連携基盤を計画した背景には、いわゆる「フラットモデル」（すべての分野で共通の番号を用いる方式）を避けて、いわゆる「セクトラルモデル」（分野ごとに別々の番号を用いて連携させる方式）的なものを採用することを基本的な方針としてきた経緯があるのであり、それに鑑みれば、この6分野は、国民の大半が関わる行政分野としては、そうとう広い範囲を占めていると言え、ほとんどの分野をカバーしてしまっているのではないかと言うこともでき、そのような見地からすれば、これは事実上の「フラットモデル」ではないかと指摘することもできると思われる。
事実上の「フラットモデル」であるとなれば、国家による一元管理を避けるべきとの理由で番号制度の実現自体に反対する人々の理解を得ることができず、番号制度自体が実現できなくなるのではないかと危惧する。
この点を踏まえて改めて考えてみれば、年金、医療、介護保険、福祉、労働保険、税務の各分野は、それぞれ、共通の番号を使用する必要性があるのか疑問がある。各分野をまたがった個人情報の連携が必要であるならば、情報連携基盤による符号変換方式によって連携は可能となるのであり、そこに番号が共通である必然性はない。
番号を分野間で共通とした方がよい場合があるとすれば、「見える番号」としての使われ方において、共通であることの意義があるかどうかである。大綱では、そうした検討がなされておらず、番号を共通とする必要性についての理由が書かれていない。
その必要がないのであれば、分野ごとに別の「番号」を用いる方法を検討するべきである。そして、その方法が妥当であるか否かを見極めるために、「見える番号」としての番号が分野間で共通の番号として利用される必要性について検討し、示すべきである。
*1 文章を推敲する時間的余裕がなかったので、いまいち読みにくいと思われ、悔いが残るところ。