第3回金融EDIにおける商流情報等のあり方検討会議(第3回)　議事要旨

日時：平成28年11月1日(火)10:00～12:00
場所：経済産業省別館1階別館108各省庁共用会議室

議事要旨

○	新システムの構築が銀行界の中でも協議中で決定している訳ではないが、構築をする仮定で申し上げると、最低限必要な項目にあるトランザクションＩＤを新システムにて付与する20桁のＫＥＹ情報で代替する等の対応については、検討は可能であると考える。つまり、20桁のＫＥＹ情報を取引の一意性を担保するために取り込むこと自体の検討は可能と考える。新システムで20桁のＫＥＹをプロットしたものを受け取り側でも認識できるので、あとはＸＭＬ電文のどこに載せるかという、定義の問題ではないかと考えている。ＸＭＬは柔軟性が1つのポイントのため、今後システム要件定義の際に是々非々で決めることだが、意見交換の上、産業界のイノベーションに寄与できるようなことを考えていきたい。もう1点、以前からお話があった法人番号の取り扱いについてはしっかりとした議論が必要だと認識をしている。つまり、仮名の企業名による特定には限界があるというのが前回の議論であったと理解している。税・社会保障でマイナンバーができ、法人番号が政府としても推進され始めてきているという現状では、特に支払側の法人番号が、受取側での消込のための非常に大きなキーになると考えている。
○	受領したデータで会計処理を自動化、または入金消込を自動化する場合には、支払人企業法人コードは非常に重要。1回目の入金処理から正確に処理できるといったことも担保されるため、支払人企業法人コードについては、ぜひ必須項目として取り込んで頂きたい。
○	支払いの企業名や支払法人コードは、ＥＤＩ情報欄の外枠にきちんと整備されていると考えており、その部分と重複させて項目を設定する必要はないと思慮。アプリケーションは、ＥＤＩ情報欄の外枠も一緒に必ず見ているはずで、アプリケーションのほうで判断可能と認識。もう1点、取引の一意性という場合、これは銀行に対する一意性なのか、企業内で請求・支払を管理するための一意性かで、情報の中身が大きく変わると思われる。取引の一意性という意味であれば、それは請求で出される際に情報を出さないとつかめない。あくまでも振込依頼を出した後の20桁というのは、ＡＳＰにてつけられ、相手に流れていくため、もともと振込依頼を出した企業は情報を持っていない形になると思う。この辺りはＩＴベンダーやアプリケーションをつくる側が、もともとのＸＭＬの情報の中身をよく知悉しているはずで、情報の網羅性や必要な情報について議論していただきたい。そこが明確になれば、流通業としては、この部分だけの項目でいいといった、はっきりしたことが言える。、あた。現在の固定長でＥＤＩ情報欄以外のところで持っている情報というのは、多分ＣａｍｔだとかＰａｉｎでも入る項目が必ずあると認識。
○	実証実験の際には、トランザクションＩＤを必須せずとも基本的には成立。もっとも、様々なニーズをとらえた、議論が必要と認識。新システムはトランザクションＩＤがなくても運用可能な形で実証実験もやっていた認識でいる。ＥＤＩ欄の外側にもともと入っている項目がある点については、先ほどの指摘の通り。企業側の事情によってはＥＤＩ欄以外を見るのは特定の目的だけであり、また、全部ＥＤＩ項目欄に入っていないと、情報の参照面がアプリケーションとして大変な場合もあるかもしれないが重複していても、やはりこの項目はＥＤＩ欄に入れてほしいということがない限りは、ＥＤＩ欄の外側と合わせて見ればよいので、ＥＤＩ欄の項目自体は絞るべき。ＥＤＩ欄にどこまで重複してもいいから入れ込むかについては他の委員のご意見もうかがいたいところ。トランザクションＩＤは、必要性に応じて検討すべきものであり、必ずしも新システムだけで必須ということではない。
○	例えば受取人企業名や支払企業名といった項目は、ＥＤＩ情報欄以外に予め入る仕様となっているので重複となると理解。受取人企業名や支払人企業名、支払合計金額、支払日時等は、最初からセットされており、ＥＤＩ情報として入れる必要はないということか。
○	送金に必須なＥＤＩ以外の項目として、どの銀行の、どの口座から、指定のどの口座へ幾ら送金する、といった基本の情報がある。その送金情報にアドオンするのが金融ＥＤＩとした場合に、本体に前述の項目があり、必ずしもＥＤＩ情報として入れる必要はない。
○	一意性を担保するためのＩＤには2つの意味があると認識。1つが金融機関によっては、当日の入金明細を自分たちで取得し、2回取得すると2回送ってくることにより重複するというケースや何らかの通信障害でデータを再取得しなければいけない場合にデータが重複する可能性があるケースで重複を削除するためにユニークなＩＤが必要ということ。もう一つが、取引の明細として特定できるＫＥＹ。これはＥＤＩのシステムによって、どこに織り込まれているかはそれぞれ違い、それをどう対処するのかはこれからの課題である。少なくとも、入出金の明細を特定でき、重複を排除できるための一意性のＫＥＹが必要ではないか。企業名については、企業コードがあれば全くなくていい。アプリケーション側ではそういった情報は別に持っており、むしろ片側の情報の不備や記載の仕方が異なる場合も、推定をして、消込をしているというのが実態。もっとも、多くの中小零細企業では、こういうコードで処理していくというのは無理があり、紙もしくは画面上で目視で確認しているため、人間が見てわかる仮名や漢字等、名称がついていること自体は、多少冗長になっても実務面での配慮としては望ましい。
○	今の議論は、おそらく大きな意味での金融ＥＤＩと、狭義な意味での金融ＥＤＩが混在している。大きな意味での金融EDIとしてＰａｉｎという振込電文全体を見たときには、法人番号を載せるということの要否について検討が必要ではあるが、法人番号も20桁の「ＫＥＹ情報」も、狭い意味での金融ＥＤＩ領域に載せることは必須ではない（広い意味での金融EDIはPain電文全体、狭義な意味での金融EDIはPainで言えばPainの中のRemittance InformationあるいはSupplementary Dataの領域を指す）。会計システムでは、その電文を受ける狭義の金融ＥＤＩ欄（Remittance InformationあるいはSupplementary Data）ではない他の項目に、一意性を保てるＫＥＹがあれば、消込は十分できると思慮。銀行界にとっては、金融ＥＤＩ欄に何を載せるかというのが重要であるほかに、Ｐａｉｎ、Ｃａｍｔの電文にも載せなければいけないというのは非常に重要だと感じている。ＸＭＬ電文は柔軟性が特長の一つであり、一意性を担保する20桁のＫＥＹや法人番号のＫＥＹを載せるという議論があってもいいかもしれない。ただし、着地をどこに見据えるかというのが1つ重要なところである。
○	議論としては狭義、広義ともにあり得るとは思うが、産業界としてどういう情報項目が振込によって利用できるかという観点で議論いただければと思っている。当然、ＰａｉｎやＣａｍｔのそれぞれで既に定義されている項目があるということであれば、ＥＤＩ欄には重複して記載しない扱いにするというのは十分にあり得るのではないかと考えている。そのような前提で議論いただければと思う。
○	法人番号自体は実証実験の際にはなかったものの、期待が高いためどこかに必ず入れ込むとするなら、狭義での金融ＥＤＩの中にせよ外にせよ、Ｐａｉｎ、Ｃａｍｔを定義する際に適切な入れどころに入れていくことを議論すればよい。どちらであっても、入れ込むことは技術的に可能と認識。
○	法人番号から企業を特定して、会社名等の情報を引っ張るということは非常に正確にできるが、法人名等から法人番号を引くというのは意味がない。会社の名前でマッチングをするのは、古い時代のやり方である。これからの時代は、完全に一致できるという、正確性を担保できる仕組みとすべき。
○	情報の整理案を見ると、発注番号から受注番号、単価や数量まで書いてあり、送金の際に載せるＥＤＩ情報としては、これほど必要ではないと思う。送金に載せたものが、その前段階でやりとりされている受発注情報と紐づけられる何かがあるだけで、基本は十分なはず。裏に多くの情報が載っているということは、例えば受発注や請求の段階で何をやりとりする、といった整理がされてないということだと感じている。ＥＤＩを産業界全体で使う際に、どこまで決めるかの話は飛ばして、金融ＥＤＩの付加情報欄に何を載せるかという話をここでするということなのか。それとも、受発注を様々な産業で行っているが、そこで共通するものをこの場で決定するということであれば、段階ごとに、次に送金する段階では何を入れるべきかを分けて議論しないと、話が複雑になる気がする。
○	おそらく実際の金融ＥＤＩにおける上流の商流のところは、業界ごとでかなり大きく中身が異なり、利用されていない先もかなり多い。今回そういう意味で、まず金融ＥＤＩに入れるところを決めていくということかと思うが、利用すべき、可能とすべき項目については、まさに任意の項目であり、使っても使わなくても構わないという位置づけになっている。
○	おそらく受発注自体は日時でものすごい量が行われていて、支払いは月締めで行われるので、受発注と支払の紐づけは多対一になっているはず。企業が送金して、それを消込するときに、この紐つけのルールがきちんとできていれば、ＥＤＩ情報欄に載せる情報は絞っても問題ないと感じている。新システムでは送金情報に多くの情報を載せることが可能となるが、受発注の情報と送金の情報を結びつける仕組みをどうすべきかを考えて、掲載情報毎に掲載上のルールを決めるといった方法があるのではないか。
○	既にＥＤＩを使っている大会社の系列会社では、支払書についても困っていないと聞いている。そうでないのは中小企業だが、中小企業も発注側になることは当然あり、下請けとの間でＦＡＸでの受発注処理が行われている。そこをどういう形で持っていくかということだが、例えば今、6割以上の中小企業はパッケージで受発注の処理をしているという話があるが、パッケージでは製造や物流といったところの情報は実は持っていない。そのため、既存の大会社が行われているような全部のＥＤＩ情報をカバーしようとすると、データ処理がとても重くなり、利便性を損なってしまう。核になるような基本的な部分だけをデータ交換すれば、入出金や消込は問題なく処理できるわけであり、絞った情報を最後の入出金のところまで回して頂ければ良い。受発注や納品段階で流れる情報については、今後の中小企業のＥＤＩをどうやって普及させるかが課題になる。今回、デファクトの用語の定義というような形を使って統一化が図られるので、上流のところを次第に固めていけるのではないかと期待。中小企業庁の事業もある中、このようなところを成果として出していき、中小企業のＥＤＩが実現できるように尽力したい。
○	少ない項目から、まずはスモールで始めていくというところは賛成。例えば項目をどんどん削り、請求書番号のみの交換であとは芋づる式にいろいろな情報を裏から引っ張って消し込めればベストだが最低限ここの項目があれば消込ができるというものとしてどのような項目が必須と皆さんが考えているかをご教示いただきたい。
○	消込にもいろいろなレベルがある。一番簡単なレベルは、入金額の総額が請求額と一致しているかどうか。今回、金融ＥＤＩの明細を利用すると、一歩先にいける。明細レベルでの消し込みができるようになると、不一致があった場合に、その内訳として消込時に請求しているものと支払い明細の間で、実は払われていないものがある等といった問題が中小企業であれば起こると思うが、そのような間違いをソフトウェアで調べることが可能となる。こうした自動化においては、まず初めに企業を特定し、金額の総額が合っているかどうかを一致させ、そうでない場合には明細のところを一つ一つマッチングしていくというフローをとる。内訳を調べる際も精度が問題になるが、どの部署に対して請求する、もしくは同じものでも別のところに請求するといったケースもありえ、様々な違いがある。それを一つ一つ正確に把握しようとすると、製品コードと金額だけではわからない。発注側の注文の内訳のキーになる情報があると、一意で特定できるので、どこで違っているのかを正確に分析可能。システム未導入の企業、特に零細企業では、実は会計システムで対応していても、製品単位でチェックするというのは、専用の販売管理ソフトを導入しているなど、在庫情報を持っていないとできない。中小企業や零細企業のレベルで、会計ソフトといっても財務会計しか使っていないのであれば、それは月額1,000円～3,000円のクラウドサービスで十分できることであり、そのレベルで止めるのか、もう一歩進んでほとんどの処理を自動化するのかということである。ほとんどの処理を自動化できるレベルまでＫＥＹになるコードや企業コードといったものを埋め込んでおくと、よりよい未来につながるのではないか。
○	先行きは、より高度な自動化ができるよう、利用可能とすべき項目を色々入れているが、全部いきなりとなると、中小企業側としては対応が厳しいため、ある程度段階を踏めるようにしているのが現在の形。
○	アンケート最終報告書の68ページ以降にフリーアンサーがあり、賛成意見や反対意見がまとめられている。中小企業や小規模企業については、紙や手入力で事務を行っているため、現状反対意見のほうが多いとは思う。おそらくまだ理解が追い付いておらず、大企業とは相当な落差があるのではないか。まずこのギャップをどうやって埋めていくのかが重要と感じている。反対意見を見ると、手間暇や取引情報をどこまで開示するのか、費用負担がどうなのか、情報漏洩がどうなのか、もともと業務量が少ないので必要ない、という声が多い。他方で賛成意見については、便利になるからいいという声もあるが、やはり大企業である取引先から情報入力を要望されれば断れないという意見もあり、手間だけ増える可能性がある。また、費用もかかるという声もあるので、こうした意見を丁寧に拾う必要。理想としては、国も生産性向上と言っているが小規模・零細を含め、全体的にバックオフィス業務が自動化されると良いと思っているが、現状では相当落差があり、手当が必要。その場合、以前から申し上げている通り、取引先から要望を受けた際により簡便にできる仕組みを作るべきである。最低限必要な項目についても全て手入力で画面入力なり、ファクスなりで打つとなると大変なので、何らかのシステムで裏側から読むことにより、入力が請求書番号や法人番号、法人コード程度で済むような形で負担が極力少なくなるようにすることが必要。
○	支払通知番号や支払通知発行日というのは、振り込む企業が実際手で記入しなければならないのか、それとも自動的に発行できるものなのか。
○	システム的にどう作るのかという点については、議論されているとおり、全部手で打つ必要はなく、手元で使っているコンピューター等で生成することも可能ではある。ただし、支払通知番号のようなものを、銀行が出すものなのか、それとも支払う企業が払い出すものなのか、それとも請求したときの番号をそのまま入れるべきものなのかという、業務的部分を整理することが必要。実現する方法としてはいろいろあり得るが現在は業界あるいは相対で決めているので、一律にこれでやれというと、いきなり移行することが難しいのではないか。長期的にはコンセンサスをつくっていく必要があろう。
○	基礎的な質問が2つ、意見が1つある。1つは請求書番号について、中小企業で手数料節約のために3通まとめて送った場合の請求書番号はどのようなイメージになるのか。また、請求書発行はしていないが送金するケースというものについてはどう捉えるのか。2つ目は、支払合計金額と、実際に送金される金額が違うケースの扱いについて教えてほしい。3つ目は、ＳａａＳサービスにすらたどり着かない零細企業が存在する中、銀行の法人向けインターネットバンキングの中だけで業務が終わるようなことを考えた場合に、電文自体がインターネットバンキングで見られないケースもあるが、銀行側できれいに見られるようにして頂くとそうした企業も幸せにできる制度になると考えている。
○	請求書番号は請求書がない場合は、いわゆる支払案内番号のような番号になる。しかしながら、代表ＩＤのような話ではわからなくなるので、請求書番号等の一連のユニーク番号という意味合いであらかじめ合意しておき、様々なＩＤをこの中に入れるということであったと記憶している。請求書番号の中にさらに細かく名前を切っておくべきなのかは、ユーザー側の意見を聞いていく必要があるのではないか。まとめ合算払いの場合は、請求書番号が複数つくといった形となる。
○	現在の振込は、依頼人側では振込指定日と受取人の銀行、支店、科目、口座番号、受取人名の仮名、そして依頼人名の仮名を指定して振込をしている。受取側も主に入金日と依頼人名の仮名、金額だけでマッチングをしているという状況で、金額も月締めの合算で入ってきおり、消込に非常に手間を割いているのが現状だと思われる。現状、固定長の20桁のＥＤＩ欄が既にあるが、銀行によってサービスを申し込まないと、これを取得できる銀行とできない銀行がバラバラな状況のため、あまり使われていないという問題点がある。翻って、本件の取り組みは、銀行全体が統一のフォーマットで取得することを1つのトリガーとして社会全体のＩＴ化を進める取り組みだと理解。その中で、金融ＥＤＩとして必要な項目が決まれば、新システムから情報を取ると、ほぼ同じような情報が画一的に取れることとなる。そこで最初は60点、70点から始まり、100点を目指していく段階的なステップを踏んでいくのだと思われるが、いかにユーザー側でわかりやすく利益実感を得て、これ便利だという世界を工夫してつくるかということが重要だと考えている。中小企業の視点からいうと、できる限りそれ（XML電文や金融EDI）を意識させないということが必要だと思っている。店頭やＡＴＭで（金融EDI等をご利用者に）打たせるということは、なかなか機能しないのではないかと考えており、インターネットバンキングやリモートチャネルを中心に、わかりやすく便利だと利益実感を得てもらい、ＩＴ化を進めるというのが非常に重要。
○	法人番号については、自動化みたいな形で入力するということはできないのかという意見が団体内で聞かれた。
○	困っているのは、ＥＤＩの仕組みができ上がっていない取引がかなり多いこと。購買側は、当然欲しいものを入れていただき、恒常的に取引があるのでＥＤＩが確立されるものの、販売側は多種多様な顧客がいる中で、販売側でＥＤＩを確立することが難しく、請求書を出して、その請求書に対してお支払いいただき、請求書ナンバーを入れたデータで振込をしてもらいたいところ。ところが、現状の振込データに請求書ナンバーを入れる箇所がなく、金融ＥＤＩ欄があるものの、一昨年のデータでは金融ＥＤＩ欄に文字入力されているデータは1％しか入っていない。全然使われていないので、ぜひＸＭＬ化してデータ量を増やしてほしいと考えている。利用可能とすべき項目は多いほうが非常に嬉しい。もう一つは、請求書番号というのは受取人側が発行するものなので、支払人側は請求書番号のデータを持っているわけではない。受取人がデータを出した時点で初めて請求書番号というのがわかり、請求書番号を入力することになるが、そもそも支払人までデータが流れてくるかというと、多くないのが現状。また、手で入力する場合、500件の請求に対して1振込となると、支払側は請求書番号500件を全部入力するという話になり、現実的ではない。できるだけ使いやすく、簡単にスタートできるようなものにしたいと思うので、請求書番号というのはあれば嬉しいが、どうしても必須とする必要はないのではないか。また、利用可能とすべき項目に発注番号があるが、発注番号は支払側がデータを持っているということで、ここでいう必須項目にはデータを入れないものの、発注番号の一番下の部分にはデータを入れるというような柔軟な対応ができるようなシステムにして頂きたい。もう一つ、請求書番号が入るのは望ましいが、請求書番号に対する金額もあれば非常にありがたい。これがあると確実に消し込める。また、振込手数料を受取人負担にする場合、手数料が引かれた金額しか入ってこない。請求に対する差額部分を概ね手数料として認識はしているが、これが確実にわかるようなシステムができ上がると非常にありがたい。
○	消込のところで議論がずれるところがある。2種類の消込があり、1つは既にＥＤＩでは請求書レベルの消込をやっているので、そういう細かいものは要らない。低レベルでＥＤＩをやっていないところについては、細かい納品レベルの消込をやっているので、全体が欲しいということであり、2種類が混同するとよくわからなくなってしまう。今回、既にＥＤＩをやっているところは、金融ＥＤＩ連携のところで明細は不要ということで、別に入れなくてもいいということになるかと思うが、納品レベルで消込をやらなければいけない、ＥＤＩのない小さい会社のところについては、もしここに請求書しかなければ、別の仕組みをつくらなければいけないので、一緒にやれると嬉しいため、両方入れてくれると嬉しいという、2つのことなのかと感じている。また、項目のところで最初に業界区分というのがあるが、中小企業になると、自分の属する業界はなんであるかというのがよくわからず、多分業界団体に入っている会社の多くは大企業で、中小企業の皆さんはそういう業界団体に入っていないので、ここで区分として何を入れていいかよくわからないということになる。業界ではっきりしているところは、そのコードを入れればいいと思うが、そうではないところについては、「999」のような形にするのが良いのではないか。全体の項目については、まずはバージョン1.0ということでとりあえず決めて、その後は追加変更できるようにしておくということで決着したらいいのではないか。
○	金額が重要な項目だと改めて認識したところではあるが、狭義の意味での金融ＥＤＩという項目以外の、振込のメッセージのところに送金金額があるが、その金額をＥＤＩ欄にも入れておくべきということでは必ずしもないのか。
○	合算で振り込まれるので、内訳が欲しいということ。
○	では各請求書が多くついていたとして、その請求書の金額が入っていれば問題ないということか。
○	その通りである。請求書単位の番号と金額が内訳としてわかれば良い。
○	振込手数料の負担をどちらがするのかという点について、ＥＤＩ欄の外にあったほうがいいのか、内にあったほうがいいのかというところについてどのように考えるべきか。
○	ヘッダー情報としてマイナス手数料が幾らというのがあれば、それはそれで構わない。
○	補足すると手数料の支払いはどちら負担というのは契約書の条文を持っているので問題はないはずだが、現状の金融ＥＤＩ、固定長でも手数料のところは、おそらく金額をもらえていない。自分が振り込むか、相手から振り込まれるか、どちらの負担ということではなく、企業によって振込手数料の金額が違うという現状がある。大手企業は、金融機関との取引の中で、振込手数料が異なることがあるというのが前提にあり、何となく企業側で処理しているため、情報としてきちんと明細が入ってくれば、それで問題ないという話だと思慮。また、言葉として、金融ＥＤＩという言葉が定義されていないので、ＥＤＩ情報欄と金融ＥＤＩの全体というように切り分けて話をしてなければわかりにくい。あくまでＥＤＩ情報欄というのは付加情報であり、通常の振込に関するところは金融ＥＤＩとして持っているというような形でお話をいただいたほうがわかりやすい。また、通常はＥＤＩ情報欄を見なくても判断できる企業も多いと思う。請求1つに対して支払いが1回だということであれば、ＥＤＩ情報欄に細かい情報をつけなくても見られるという企業も、かなり多くあるかと思う。先ほど大手企業は売り掛けや消込を苦労していないというが、逆に大手企業であるほど、複数の請求書に対して一括で振り込まれ、だからこそ付加情報が必要だという形もあるかもしれない。そこで先ほどから出ているのが、仮名文字ではわからないから、そこに法人コードがあると、より正確に消し込みができるという話と認識。しかし、それに加えてプラスアルファの情報がないと、消込ができない企業もあるということで、そこはＥＤＩ情報欄にどういう付加情報を入れたらいいのかという議論と認識している。
○	個人事業者に対しては法人コードが振られていない。そういう意味ではこれを必須としたほうが利便性が高まることは理解しているが、全ての中小事業者・個人事業主が排除されないようなシステムづくりをお願いしたい。
○	個人事業主にも法人番号を検討すると聞いている。任意団体は申請すれば付番されるのであるべき形としては個人事業主にも法人番号を振り、本件のように活用できるようにすべき。
○	法人マイナンバーがあれば問題ないということか。それとも、例えば中小企業であっても、法人ならばマイナンバーを入れるというのは、中小企業にとっては負担になってしまうものか。
○	法人番号を新たに入れることは、手間と言えば手間だが、それぐらいは必要ではないかと思う。ただし、先ほど申し上げたとおり、個人事業主に現状はないので、そこは排除しないでほしいという話をしている。先ほどご意見があったように個人事業主にも番号があったほうがいいとは思うが、そこまでには期間がありその間の過渡的な措置として排除されない処置をして頂きたい。
○	支払側から情報をもらわなければ、受取側は何が引かれて差額が出ているのかわからない。振込金額が一定金額を超えると、支払手数料の額が変わる等もあり支払手数料の額を計算上入れたほうが良い。
○	振込手数料は、銀行側で入れることは難しい。銀行としては幾らの出金を許容するかという行為と、幾ら振り込むかというところの承認を得ているのみである。振込手数料は当然、依頼銀行側で課しているが、その原因となる商取引でどれほど引いているかは把握していないためである。もっとも、手数料は確かに不一致が多いということは承知をしており、金融ＥＤＩ側で情報があると、確からしさは大分上がるのではないかと考える。
○	手数料のところで、100円の振込、手数料は受取人負担というデータを送り支払う場合、その手数料は振込人側では100円で振り込んでいるが、受取人には90円で入ってくる。それは支払人にはわからないというケースがあったと記憶しているが現状は異なるのか。
○	内国為替ではないと思う。外国為替で受取銀行側の手数料があるので、幾ら取られるかはわからない側面があるが、内国為替については、例えば100円の振込プラス手数料という形で依頼銀行側で手数料を徴収するので、100円ということで指定すれば、必ず100円になる。
○	別の話ではあるが、先行き、様々な項目を入れてくれという話があるかと思われる。最低限の部分は絞るべきと申し上げているが、他方で取引先からあれもこれも入れてくれと言われたときに、どうしても対応せざるを得ない懸念があるので、下請法等で場合によっては手も打っていただく必要もあるのではないか。

議事5:討議(アンケート集計結果について)

○	問29の集計結果が興味深い。表計算ソフトが49.3％で、パッケージソフトが59.9％として、複数選択を可としていることから、会計ソフトをメインに使っていても、表計算ソフトも使っているというのは非常によくあるケースであり、それを排除したほうが実態が分かると思慮。パッケージか、クラウドか、統合システムはＥＲＰと呼ばれているソフトなのか、そのあたりのソフトの使われている割合も把握できると良いのではないか。
○	前回の中間報告と比較し、大きく数字は変わっていないという理解。従来から述べているとおり、今回の取り組みはＸＭＬやＥＤＩ等、中小企業の理解が進んでいない状況でのアンケートと理解しているため、興味が湧かず、短期的には導入しにくいといった回答は予想されていたところ。ファクトからしても、やはり通帳が多いというのもある程度予想していたところであり、ここをいかに消込作業の利便性を向上させて、新サービスを利用できるようにするのが今回の取り組みの主戦場。まさに、労働人口が減少する中での非常に大きな取り組みと理解している。
○	本件取り組みはスタートしたばかりであり、大きなギャップがある中でどこまでいけるか、ギャップをどう埋めていくかについて、全員で取り組む必要があると思っている。また、前回も申し上げたが、振込の際に店頭・ＡＴＭやＦＡＸ等、いわゆるＸＭＬの対象外のチャネルを多く使っている実態もあるので、そういう人たちも排除されないよう考える必要がある。また、取引先から何か言われたときに対応が必要となる点を気にしている。制度的なり、システム的になり、また、下請法や取引適正化として何らかの枠をはめるのか等、総合的な対応が必要と認識。
○	アンケートを見た殆どの小規模事業者が、消込に困っていないのになぜアンケートが来たのかという認識だと思う。先ほどの調査結果の発表の際も紙ベースがあまりにも多いというお話しがあった。生産性向上については我々も推進していかなければならないが、認識のギャップがどうしてもあるので、今回の取り組みについては、小さく産んで大きく育てるという視点でお願いをしたい。小さく産んだ際に目を向けてくれるよう、ギャップ埋めに向けぜひ知恵を絞っていきたい。
○	情報漏洩への懸念が多く寄せられている点に関連して実際の運用が始まってからの話なのかもしれないが、ビッグデータ活用のようなところにどう取り組み、誰のために活用するかの議論も踏まえ、例えば暗号をうまく使い、見せないところは見せないといった工夫が必要なのではないか。その際にはこれから決まっていく当初運用のフォーマットを少し変えるだけで対応できるのか、新たな仕組みが必要なのか、その場合、仕組みはどこでシステムを持つのか、といったことも重要な検討課題になると考える。
○	金融機関に対し情報を提供するかしないかという話にいて、思った以上に提供するという回答が多く驚いている。「情報を提供する」と「関係性によっては提供する」という先が60％以上となっており、見られる情報を限定するなりしながら、漏洩しないよう対策がされるということであれば、何かのメリットがあれば見てもいいという可能性がある。いわゆる商流情報を分析して何か活用していくといったこと等、消込以外のところにもメリットを生み出し、少しでも普及促進に努めるということを考えると、必須項目から当然やっていくということであろうが、その他の項目についても検討は重要。ポイントはデータ区分であり、この情報はこういう目的を目指してここまでをいろいろ入れている情報である、これは消込のためだけに入れる情報である、といった分類が何かしらで認識できれば有用ではないか。
○	ＥＤＩの項目の検討は、全銀協側でやっているＸＭＬ電文化と並行する形で、よりお互いが効果、メリットを出していけるようにということでやっていると理解。また、アンケート結果についても、これを踏まえてどこにどういう形で働きかけていけば理解が進み、より使ってもらえるようなシステムにできるかという着地が少しずつ見えてくると認識。そういう意味では、金融界もＸＭＬ化対応に生かしていく必要があると思われ、経産省、中小企業庁でも、アンケート結果を活用し、企業側への働きかけを強めて頂きたいと考えている。
○	概ね考えていた傾向と同じようなアンケート結果が出た印象。ただし、新サービスについては中小企業、特に小規模事業者では知らないのが実態と思われる。ＪＩＳＡですら業界関係者向けにＩＳＤＮの廃止に向けた状況を説明している段階であり、中小企業はまだ全然知らないと考えている。一方、新サービスに対して関心がある、商流情報を流して構わないというような結果が想定対比多かったので、考えられる余地はあると思慮。なお、商流ＥＤＩ・受発注のＥＤＩについては、委託先の公募中であり、委託先決定後、10程度の実証実験を実施予定。興味を示している金融機関もあり、商流情報と金融情報がうまく連携できれば入力の手間が省けてくるとの期待の声がある。中小企業も金融機関にＥＤＩに関するコンサルティングを期待しているため、コンサルティングサービスも加味されれば、良い仕組みができるのではないか。
○	アンケートを実施前に想定していたよりも前向きな結果であったと思慮。今後どのように新サービスのメリットや、負担軽減の方策を検討し、産業界と金融界が連携してしっかりした仕組みにしていくことが肝要であるということを示していると認識している。

＜お問い合わせ＞ 中小企業庁事業環境部金融課 電話:03-3501-2876