2.税関等関係当局の取組と課題
先の政府方針にそって税関等関係当局の間でIT化の取り組みがおこなわれ、輸出入・港湾手続関係のシステムも今後、さらなる拡張が予定されています。
ここでは、4つのキーワードで整理してみます。
［1］ワンストップ化
［2］シングル・ウインドウ化
［3］G7による標準化・簡素化、共通電子申告フォーマットの開発
［4］オープン化
2.1 NACCSを中心とした当面のワンストップ化(接続・連携)の動向
| 昭和53年(1978) |
NACCSの航空システム導入(Air-NACCS) |
| 平成03年(1991) |
NACCSの海上システム導入(Sea-NACCS) |
| 平成08年(1996) |
食品衛生法手続に関するシステム(FAINS)導入/NACCS連携(厚生労働省) |
| 平成09年(1997) |
植物検疫手続に関するシステム(PQ-NETWORK)導入/NACCS連携(農林水産省)
|
| |
動物検疫手続に関するシステム(ANIPAS)導入/NACCS連携(農林水産省) |
| 平成11年(1999) |
Sea-NACCSの更改
|
| |
港湾EDIシステム導入(国土交通省(港長)地方公共団体(港湾管理者)
|
| |
外為法の輸出入手続に関するシステム(JETRAS)導入(経済産業省) |
| 平成13年度(2001) |
港湾EDIシステムのNACCS接続・連携(平成14年1月から)
|
| |
インターネット申告の実験を計画 |
| 平成14年度(2002) |
税関手続申請システムインボイス等申告関係書類の電子提出(NACCS経由)を計画
|
| |
外為法の輸出入手続に関するシステム(JETRAS)NACCS接続を計画 |
| |
乗員上陸許可に関する手続システムのシステム化、NACCS・港湾EDIに連携を計画 |
| 平成15年度(2003) |
関税等を含めた電子的納付を検討(マルチペイントネットワーク48が前程) |
48マルチペイントネットワーク:収納機関と金融機関との間をネットワークで結ぶことにより、輸入者はインターネット等を利用して関税や手数料労の支払ができ、即時に消し込み情報が収納機関に通知されるサービス。平成12年5月に発足した「日本マルチペイントネットワーク推進協議会」(事務局:富士銀行、郵政事業庁、NTTデータ)において平成14年度までに開発される予定
NACCSと港湾EDIの接続・連携が平成14年1月28日から本格稼動し、NACCS端末から港湾EDIを通じて港湾管理者に対する船舶の入出港届・係留施設使用届当を入力することができるようになりました。処理できる手続は港湾によって異なりますが、船社・船社代理店にとってのメリットが考えられます。
NACCSとJETRASとの接続・連携は平成14年度を目途に計画が進められていますが、(社)日本通関業連合会「税関手続の電子化等に関する研究会」の報告書では、連携にかかる(社)日本通関業連合会と産業経済省との意見交換の際、個別許可書に参考としてHSコード番号を入れて欲しい、NACCS端末から輸入者当の許可内容を参照できるようにして欲しい等の要請が出されている。現行と比べ、外為法上の許可書等の電子裏落しや、そのハードコピーの税関提出が不要となる等のメリットが考えられます。
ワンストップ化のイメージ
（拡大画面： 76 KB）
上記、イメージ図のようにNACCSの利用者は1台のPC(NACCS端末)から、NACCS経由で他のシステムの画面を呼出し、手続を行うことができます。例えばNACCSを導入している利用者の端末では、NACCSに接続・連携された他のシステム(例えば食品申請等の他方令処理)の画面を呼出すことができるようになってきており、複数の機器、複数のソフトウェアの導入は行わないで済むようになってきている訳です。
2.1.1 課題
それぞれのシステムは開発時期が異なり、クローズ型・オープン型と開発思想も違います。従って基本的にはそれぞれの業務事情に合わせたシステムとなっており、システム間のインターフェイスは進んでも、プロトコル・項目定義などの仕様において全体最適な業務プロセスが実現するようなグランドデザインの設計が成されているとはいえません。このシステムを利用する民間企業にとっては、依然として個別の対応が必要となる部分が少なくないなど、利便性の向上に向けた改善が課題となります。
また、民間企業がこれらのシステムに接続して行く過程では、従来の書類併用などの過渡的な対応が必要となる場合があり、システムへの投資負担に見合うコスト削減効果が得られていないケースがあります。
これらについては、平成13年3月のe-JAPAN重点計画でその整備が決定された関係府省間の検討体制により、平成13年度中にネットワークを通じた情報の共有・活用を含めた整備。統計情報を含めた提出書類の標準化や申請フォーマットの集約化が検討される予定となっており、その成果を期待するものです。
2.2 シングルウインドウ化
利用者が希望する手続に必要な情報(例えば輸入申告に関する情報、船舶に関連する情報)をハブシステムとしてのNACCSに送ると、自動的に情報の切り分けがされ、関係省庁等に必要な情報が分配される。従って利用者は1回の送信で要件を済ますことができることになり、その点がワンストップ化との相違点といえます。
平成14年1月31日の第9回IT戦略本部からの報告で、シングルウインドウ化に向けたシステムの骨格が報告されました。(平成14年2月4日 日本海事新聞掲載)
● 貨物に関する手続はSea-NACCS、船舶入出港に関する手続は港湾EDIをそれぞれ中核的なシステムとし、システム間接続を行うことで、1回の入力・送信で要件を済ませる。
● 2002年度にプログラムの開発、システム間の相互接続をおこない、テストを経て2003年度の早期に共用を開始する。
● NACCSへは専用回線、港湾EDIにはインターネット経由による接続という現行システムの骨格は残すが、インターネット経由でNACCSへのアクセスを可能にする。
● 法務省が開発中の「乗員上陸許可支援システム(仮称)」や厚生労働省の「船舶・船員検疫」についても接続または機能に加える。
● 重複入力を回避するなど複数行政機関への申請を容易にするため、クライアントソフトを国土交通省で開発する。
● 今後は、各省庁間のコード統一やG7に関連した標準化・簡素化を踏まえてシステム開発を進める。
港湾関連手続では、横浜市港湾局が上記のシングルウインドウ化報告に沿った、連携システム「横浜港港湾情報システム」を構築すると表明しました。
このシステムでは、1回の画面入力により、港湾管理者・港長・税関・入国管理・検疫といった異なる官署へ必要な情報が届くようになります。
また、現行Sea-NACCSの利用料については更改当初(平成11年10月)より割高であるという指摘が多く、結果、船会社の導入がさみだれ的であったり、倉庫事業者がその導入を見送っていた点に関連し、日本船主協会・外国船舶協会等からの料金引下げ要請がされていました。
シングルウインドウ化へ向けた各省庁間での協議でもこの間題が取り上げられ、これを受けて財務省では平成14年4月1日から基本料金・従量料金・パッケージソフト使用料を大幅に引下げることを表明しています。
シングルウインドウのイメージ
（拡大画面： 83 KB）
2.2.1 課題
シングルウインドウ化では、上記のようにその骨子が固まり、概略設計の段階に入っています。「各省庁間でのコード統一」や後述する「G7での標準化・簡素化」といった問題を踏まえたシステムの開発が必要となるわけで、今後はその調整が重要なポイントとなってくることでしょう。
また、港湾関連手続については、横浜市港湾局での対応について触れましたが、他の港湾におけるシングルウインドウ化に向けた対応がどのようになるか、足並みや、処理内容についての調和といった点が課題となってくるものと考えます。
2.3 G7による標準化・簡素化、共通電子申告フォーマットの開発
G7の税関当局においては1996年(平成8年)6月のリヨンサミットでの合意を受け、税関専門家会合により以下の開発作業が行われ、これまでに主要な作業については完了しているとのことです。今後我が国を始め、G7各国で共通フォーマット等による申告のトライアル、更にこうしたトライアルを踏まえて必要な修正を行う予定であり、日本では可能なら2005年(平成17年)を目標に共通フォーマットによる申告の実施を導入することが計画されています。
また、食品衛生および動・植物検疫に係る申告項目についてもG7での標準化作業が2000年より始まっています。
| 税関が要求する申告項目(データエレメント)の標準化・簡素化 |
| 電子申告フォーマットの開発 |
| 税関以外の他省庁が要求するデータエレメントの標準化 |
| プロトタイプの確立 |
● データエレメントの簡素化・標準化
名称・定義の標準化と要求データの簡素化(UNTDED49をベースに作成)
49UNTED:United Nations Trade Data Element Directory(国連貿易データエレメント集)
輸入申告においては
| リヨンサミット時点(96年6月) |
→ |
00年12月現在 |
| 800項目 |
|
115項目 |
データエレメントの標準化とはどのようなことか、以下の例を参照して下さい。
＜グロスウェイトとは？＞
同じグロス重量でも、共通部と明細の欄部では申告すべき値(重量)が違う。
G7ではデータエレメントを共通部のグロスウェイトと欄部のグロスウェイトで区別し、各国がどちらのグロスウェイトを求めているか明確にした。(日本は、共通部のグロスウェイト)
＜積載航空機とは？＞
同じ積載航空機でも機体番号と航空機便名で申告すべき値(番号)が違う。
機体番号は、運送手段を物理的に特定するもの
航空機便名は、飛行ルートを特定するもの
G7ではデータエレメントを区別し、各国がどちらの値を求めているか明確にした。(日本は、航空機便名)
＜入港年月日とは？＞
同じ入港年月日でもファーストポートと取卸港では申告すべき値(日付)が違う。
G7ではデータエレメントを区別し、各国がどちらの日付を求めているか明確にした。(日本は、取卸港への入港年月日)
品目ごとの数量(データエレメントの統合)
＜品目数量とは？＞
従来、日・米・加では、申告欄部ごとに「Tariff quantity」のみを使用。
欧州諸国では、申告欄部ごとに「Tariff quantity」と「Net net weight」を使用。
標準化の結果、各国とも日・米・加と同じデータエレメントに統合
削減された項目例
| 貨物容積・容積単位(共通部での削減。欄部では必要となる場合がある。) |
| 配送先住所(但し、輸入者および荷受人の情報は必要) |
| 実輸入者情報(実輸入者コード・名前・住所・電話番号) |
| 実輸出者情報(実輸出者コード・名前・住所・電話番号) |
他の削減項目を合わせると、現行NACCSの申告項目数で18項目を削減することとなる。
G7共通電子申告フォーマットの開発
従来、G7各国では輸出入申告用に様々なフォーマットが存在していますが、そのままだとより多くの機器、より多くのソフトウェアが必要となるため、会合では、これをG7共通のデータセット(G7共通データエレメントのリスト)とG7共通電子申告フォーマット(UN/EDIFACT50をベース)にて、輸出入申告用G7共通電子申告フォーマットとしています。また、申告データとしてはテキストの入力よりコード入力を推奨し、標準化の作業が行われています。
50 UN/EDIFACT: United Nations Electric Data Interchange For Administration, Commerce and Transportation(行政、商業及び運輸のための電子データ交換国連規則)
国際標準コードの採用例
国:ISO51国コード
通貨:ISO通貨コード
港・空港:国連LOCODE52
荷姿形態:UN/ECE53勧告第21号
51 ISO: International Organization for Standardization(国際標準化機関)工業関連分野の規格統一や標準化を行う国際機関。分野ごとに専門員会(TC)、分科会(SC)、作業部会(WG)が設置されている。規格案は数段階の審議を経て最終的にIS(International Standard)となる。
52 UN/LOCODE:国際連合・地名コード
53 UN/ECE:国際連合・欧州経済委員会
G7共通コードの開発・国際標準コードリストへのコード登録例
支払手段:G7共通コードリストを開発
数量単位:UN/ECE勧告第20号のコードリストに必要コードを追加
減免税コード:UN/EDIFACTのコードとして登録
国内コードの使用例
輸入者コード:各国が選択するナンバリングシステム(日本はJASTPRO日本輸出入者標準コードを使用)
● 税関以外の他省庁が要求するデータ・エレメントの標準化
我が国の場合、他方令該当貨物の約90％を占める動物検疫・植物検疫・食品衛生の分野で必要な申告項目の標準化作業をおこない、2000年末までにデータセットのDraft版が作成されています。今後はこのデータセットを更に標準化・簡素化していくことし、必要に応じてこれら3分野以外にも対象範囲を拡大していくとしています。
● G7プロトタイプの確立
G7プロトタイプとは、G7各国のスケジュールに基づき、合意されたデータセット、共通電子申告フォーマット及びコードを用いて実施するトライアルであり、G7各国は自国のシステムを改変しG7標準を採用する予定としています。
日本では、合意されたデータセットや電子フォーマットをテストするためのプロトタイプを2003年までに実施し、その結果を踏まえ可能ならば、2005年までに標準化された電子申告フォーマットを実施すると表明しています。
2.4 オープン化
2.4.1インターネットの活用
官側では、平成11年12月19日に内閣総理大臣決定された「ミレニアムプロジェクト」これをうけた「大蔵省アクションプラン」。また、東京商工会議所からの問題提起、市場開放問題苦情処理推進会議第6回報告書を踏まえて、平成13年度中に技術的な問題点をクリアーにするための検証実験を行い、実施するかどうかを検討する。としていましたが、シングルウインドウ化(2.2)で延べたように、NACCSへのインターネット経由のアクセスを可能とする表明がなされました。
NACCSを利用するユーザーの立場、目的、条件、頻度、資格といった切り口からみてみますと、接続方法がおのずと分かれ、すみわけがされていくと判断します。ただ、インターネットの活用にあったては、後述するシステムのセキュリティー対策が重要で、改竄、なりすまし、盗み見、ウイルス等に対処する技術的な問題解決、本人確認をおこなうといつた電子認証制度の確立(平成15年度を目途)が必須な条件として、検討が行われているようです。
2.4.2 民間システムとの連携における指摘
前述してきた行政手続のNACCSにおける「ワンストップ化」「シングルウィンドウ化」「標準化・簡素化」と、民間が開発してきたシステムとの連携をどの様に捕らえるかが指摘さてれています。
ITと国際物流に関する懇談会(第9回)議事要旨では、「CCS−J54やPOLINET55といった民間システムとの連携等も視野に入れるべき。」として、以下の取り纏めがされています。
54 CCS-J:航空貨物輸送関係者の間で航空貨物情報を電子的に自動交換処理するシステム。
55 POLINET:海貨、検量、検数、船社の業種間を結ぶ輸出船積み貨物情報の授受伝達を行うオンラインネットワークシステム
●NACCSにより通関手続きは既に迅速化されており、むしろ申告の前段階・後段階の迅速化について政府は取組むべきで、例えばハブ港の機能を高めるような行改管轄の在り方や投資バランスを考えるべき。。
●NACCSセンターを中心に他の関係当局のシステムを集約させて、民間も含め、あるべきシステムを検討すべきではないか。
●NACCSのカバーする機能は、運送部分・通関部分・関税の納付部分に分けられるが、このうち運送部分はSCM56の状況を見ても変化が早いため、こうした三つの機能別に分けてNACCSのシステムの見直しを行っても良いのではないか。
●全体最適を考えたシステム設計が必要で、現実的にはそのリーダーシップを税関がとるべき。その際、まずNACCSが民民情報についてカバーできる範囲を明確にすることが重要で、その上で他の民間システムの普及を併せて考えるべき。
●国際物流には様々な当局が関わっているが、グランドデザインを描き全体最適化を考えることが重要である。
56 SCM:サプライチェーン・マネジメント Supply Chain Management日経BPデジタル大事典2001−2002年版より情報ネットワークを活用した経営手法の一つ。SCMと略される。部品供給会社(サプライヤー)から製造会社、卸や小売りなど顧客に至るまでのサプライチェーン全体をネットワークで結び、生産や在庫、購買、販売、物流などすべての情報をリアルタイムに交換することで、チェーン全体の効率を大幅に向上させることを目指す。複数の企業や組織の壁を越え、一つのビジネス・プロセスとして経営資源や情報を共有し、チェーン全体の最適化を目指してプロセスの無駄を徹底的に削減することが狙い。国内でも電子商取引推進協議会(ECOM)が2000年度から日本型サプライチェーン・マネジメントの具体的なビジネス・モデルを検討するなど、採用が広まりつつある。
2.4.3 課題
民間における貿易手続システムと行政システムとの連携については、民間側のオープン化されたシステムが、標準化され普及すれば、という記事をよく見かけます。
大手企業では、専用線を使った独自のネットワークが既に確立しており、グループ企業・子会社間とのシステムが構築されているため、そのような企業では、TEDI57やBOLERO58を利用するメリットが見出せず、その普及が限られる。 POLINET(当委員会平成10年度の報告書でもSea−NACCSとPOLINETは重複する業務で書式が異なっている点を指摘)にしてもその普及率からいえば、限られた利用となってしまう。
57 TEDI: Trade Electronic Data Interchange1999年4月から通産省主導でスタートした貿易関係書類全体の電子化プロジェクトで「貿易金融EDI共通基盤システム。2000年11月にTEDI Clubという任意団体が設立されている。
http://www.tediclub.comを参照
58 BOLERO1998年12月に設立された貿易金融EDIのネットワークを提供する営利団体で、国際的な船会社・運輸会社・港湾当局で構成された相互団体であるTT Club(Through Transport Club)と、国際的な銀行間の決済ネットワークを運営する非営利組織SWIFT(The Society for Worldwide Interbank Financial Telecommunications)が出資し、電子化された貿易取引関係書類のインターネットによる送受信、認証、船荷証券の権利移転、管理等のサービスを行っている。
先の国際物流改革プランでも、行政システムと民間システムの連携を目指すという方向性は示されていると判断しますが、これに沿って、例えば、接続・連携を中間で代行するサービス・法整備等も考慮した具体的な検討・方向性が見えてきても良い時期であろうと考えます。
2.4.4.税関手続申請システムについて
さて、財務省では先の「大蔵省アクションプラン」を受けて、「税関手続申請システム」の開発・導入に向けた作業を進めており、以下のような内容がまとまってきています。当システムは、平成14年度中の稼動を目指しており、今後その進捗にあわせて民間利用者への周知がなされていくことになっています。関連して総務省においては、電子政府の基盤構築に係る法令整備が進行中です。
税関手続申請システム(Customs Procedure Entry System ＜CuPES:カペス＞)
● 対象業務
税関手続申請申請システムでは、既にNACCSで行われている申告・申請業務を除いた、現在書面により行われている全ての業務(ただし、旅客の携帯品に対する輸出入申告等、電子化に馴染まないものを除く)を対象としています。
平成14年度に実施予定となっているものは、「134の手続」と「インボイス関係」の業務です。
134手続の内訳
監視関係手続 : 28手続
業務関係手続 : 21手続
調査保税関係手続 : 83手続
共通手続 : 2手続
合計 : 134手続
インボイス関係手続の概要
［1］輸出入者によるインボイス情報の登録59
［2］輸出入者が登録したインボイス情報について、通関業者による連結・仕分け・内取等の処理60
［3］NACCSの事項登録用データへの変換(外部ファイル経由)61
［4］インボイス情報の参照62
59 インボイス情報は、CSV形式で送信し登録する。CSV形式:データを項目ごとにカンマで区切って羅列するファイル形式。主にデータベース・ソフトや表計算ソフトのデータを保存する際に使用される。必要に応じ、運賃明細書、保険料明細書等をEXCEL等生還で参照可能なファイル形式(1ファイル300キロバイト、最大10ファイルまで)で添付して送信することも可能。CSV形式によるインボイスは最大で、60欄までとなるが、これを超えることとなったインボイスについては、インボイス自体を添付ファイル(1ファイル300キロバイト、最大999欄、10ファイルまで)として送信することも可能
60 複数インボイスについて1つの申告とする場合、インボイス上の欄統合をする場合、1インボイスの貨物を分割して申告するためにインボイス情報を加工する場合に行う業務であり、これらの業務によりNACCSの事項登録への利用が可能となる。尚、インボイスを連結した後に欄数が制限値の60欄を超えた場合やインボイスを添付ファイルとした場合等、後続の業務が不可能となる場合がある。
61 インボイス情報の「受理番号」及び「システム区分(A−航空:B−海上)」を入力し、NACCSの事項登録可能なデータに変換する。ただし、税関手続申請システムとNACCSは直接連動していないことから、変換されたデータを外部ファイルへ保存し、該当ファイルをNACCSの事項登録画面で参照することとなる。
62 添付ファイルとして登録されたインボイス情報以外のインボイス情報、仕分情報、内取情報等の照会を可能としている。
● 対象利用者
平成14年に予定している稼動当初においては、NACCS利用者及び輸出入者のうち、利用希望者(平成14年1月以降募集する予定)を対象とするが、輸出入者については、インボイスの登録業務のみが可能となります。
●システム運用・使用ソフト
システムの運用時間は、現行NACCSに準拠(メンテナンス時間を含み通年24時間運用)し、周知事項はNACCS同様に掲示板に掲載される予定です。
使用ソフトは、Windows98/ME/NT・Workstaion4.0・Windows2000Professional上で動作するパッケージソフト(初回は無料CD-ROMを配布、それ以降の改正分はダウンロード)容量については、ドキュメント類を除き、最大見積りで約30MB。
民間利用者における処理方式は、全てメール処理方式(メールボックスが必要)となり、NACCS同様利用者コード、パスワード、メールパスワードを使用する。
平成15年度以降おいては、政府認証基盤63(GPKI)および財務省認証局の整備に併せ、インターネット対応を図り、対象を一般利用者に拡大することになっています。
63 政府認証基盤「GPKI: Government Public Key Infrastructure」
"Public Key Infrastructure"が示すとおり、この仕組みは、公開鍵暗号方式によるデジタル署名を用いた認証システムにより実現します。
政府認証基盤は、具体的には、ブリッジ認証局及び府省認証局から構成され、ブリッジ認証局は総務省、府省認証局は各府省において整備されます。
一方、申請者側にも民間認証局等による民間側認証基盤が必要です。政府認証基盤と民間側認証基盤とが相互に信頼関係を結ぶ(行政機関側の認証局と民間側の認証局との間で相互認証を行う)ことにより、行政機関の処分権者と申請者との間の申請・届出等手続のやり取りをインターネット上で行える仕組みが実現します。
行政機関側の認証局としては、政府認証基盤を構成するブリッジ認証局及び府省認証局があり、一方、民間側の認証局には、法務省が運営している商業登記制度に基礎を置き法人代表者等を認証する認証局(以下「商業登記認証局」といいます。)や民間企業が運営している認証局(以下「民間認証局」といいます。)があります。また、地方公共団体による認証局についても、今後整備が予定されています。
ブリッジ認証局と府省認証局の役割
政府認証基盤を構成するブリッジ認証局と府省認証局は、それぞれ次の役割を果たします。
(1)ブリッジ認証局
ブリッジ認証局は、府省認証局と民間認証局等との間の信頼関係(以下「相互認証」といいます。)を仲介することにより、府省認証局と民間認証局とが個別に相互認証することの煩雑さを解消します。
また、府省認証局が発行する処分権者の公開鍵証明書(以下「官職証明書」といいます。)及びその失効情報を一元的に提供することにより、申請者は、当該公開鍵証明書の有効性の検証を効率的に行うことができます。
さらに、ブリッジ認証局は、民間認証局等が発行する申請者の公開鍵証明書(以下「申請者証明書」といいます。)の有効性検証機能を各府省に対して提供することにより、政府認証基盤全体の効率的な構築・運用を可能なものとしています。
(2)府省認証局
府省認証局は、申請者に対する結果の通知等の作成者が処分権看であること及び結果の通知等の内容が改ざんされていないことを証明するため、処分権者である大臣等の官職証明書を発行します。
なお、申請者に対しては、商業登記認証局や民間認証局から申請者証明書が発行されます。
（拡大画面： 74 KB）
