NCC NCC NETWORK CHANGE COMPLETION
第三者が検証できるネットワーク変更

ネットワーク変更を、「実施した」から「確かめられる」へ。

NCCは、ネットワーク変更の前後を同じ計画と固定ルールで観測・評価し、変更1件ごとに、署名・信頼時刻・透明性証明を備えたNCC証明書を発行するサービスです。受け取った相手は、登録なしで真正性を検証できます。

CERTIFICATE CHAIN 変更1件ごとに1通
対象と条件を固定 01

対象ドメインを認証し、変更前後の条件・観測期間・判定基準を申請に結合します。

変更を観測 02

署名済みジョブに基づき、DNS・TCP・TLS・HTTPを許可された範囲で観測します。

検証・判定 03

検証し、PASS/FAIL/INCONCLUSIVEを決めます。PASSのみ証明書発行へ。

署名・時刻・透明性 04

証明書に電子署名し、検証済みの時刻証明と透明性の記録を結合します。

受領者が検証 05

公開URLまたはオフラインパッケージで、誰でも改ざんと真正性を確認できます。

変更前後を同一計画で観測 判定はルールで決まる 署名と信頼時刻 受領者は登録不要

入口:Portal、API、MCP(OAuth)。どこから使っても同じ認可と上限が適用されます。時刻証明には同シリーズのPP-TSAを利用しています。

作業報告を、証明書にする

「変更しました」という報告と画面キャプチャの代わりに、検証可能なNCC証明書1通を引き渡します。

判定に人の裁量を挟まない

合否は、事前に固定した観測計画とルールだけで決まります。AIは説明の補助に限定され、判定には関与しません。

受け取った側が確かめられる

証明書の受領者は、NCCに登録せずに公開URLで署名・時刻・透明性を検証できます。

01 / 課題

「変更しました」は、証明になりません。

ネットワーク変更の完了報告は、作業者のログと画面キャプチャに頼りがちです。受け取る側は、それが本当に・その時刻に・その条件で確認されたのかを確かめる手段を持ちません。

01
作業ログは作業者のもの

ログもキャプチャも、作成した側があとから直せます。発注者や監査が求めるのは、作業者から独立した確認です。

独立した観測者が変更前後を確認する。
02
確認の条件があいまい

「つながることを確認した」だけでは、いつ・どこから・何を・どの基準で見たのかが残りません。

条件と判定基準を、観測の前に固定する。
03
受領側に検証手段がない

報告書を受け取っても、真正性を確かめる方法がなければ、信頼は担当者への信頼に戻ってしまいます。

誰でも検証できる形式で引き渡す。
02 / 証明の仕組み

NCC証明書が示すこと

1行ごとにひとつの主張と、その範囲外を明記しています。行をクリックすると詳細が開きます。

01 対象が本物であること 証明書の対象ドメインが、申請者の管理下にあると確認されたこと。
示せること

対象ドメインはHTTPSチャレンジで認証されます。証明書は、認証済みの対象と、申請時に固定した条件・期間・判定基準に結び付きます。

防げること

他者のドメインについての発行、そして「どの対象についての確認だったのか」という後からの争い。

02 実際に観測したこと 変更の前後が、署名済みジョブに基づいて実際に観測されたこと。
示せること

観測はDNS・TCP・TLS・HTTPを対象に、許可された範囲でのみ行われます。実行ノード、時刻、生データの指紋が記録されます。

防げること

観測していない結果の主張、範囲外への勝手なアクセス、そして観測記録の後からの差し替え。

03 判定がルールで決まったこと 合否が、バージョン固定のルールによる決定論的な評価であること。
示せること

正規化した観測結果を固定ルールで評価し、PASS/FAIL/INCONCLUSIVEを返します。同じ入力からは同じ結果になります。AIは説明の補助に限定されます。

防げること

担当者の裁量による合否、あいまいな結果の合格扱い、そして再評価のたびに変わる判定。

04 証明書が改ざんされていないこと 発行後の書き換えが、署名の検証で検知できること。
示せること

正規形の証明書に電子署名(ES256 detached JWS)を付与します。1文字の変更でも署名検証が失敗します。

防げること

発行後の書き換え、偽造された証明書、そして「その内容で発行されたか」という争い。

05 発行時刻が信頼できること 発行時点が、検証済みの時刻証明で裏付けられていること。
示せること

同シリーズのPP-TSAによる署名付きタイムスタンプを結合します。時刻は発行者の自己申告ではありません。

防げること

日付の遡り、そして「いつ確認したのか」を発行者の言葉だけに頼ること。

06 発行の記録が公開されていること 発行が追記のみの透明性記録に残り、あとから消せないこと。
示せること

証明書は7種の成果物(原本JSON、署名、時刻応答、透明性証明、マニフェスト、オフラインパッケージ、PDF)として提供され、公開IDだけでブラウザから検証できます。

防げること

発行済み証明書の静かな取り消しや差し替え、そして受領者が発行者に問い合わせないと検証できない状態。

証明すること、しないこと

NCC証明書が示すのは、承認された対象・条件で観測し、固定ルールで評価し、改ざんを検知できる形で発行したことです。ネットワーク変更そのものの妥当性、将来の可用性、監査・認証規格への適合を自動的に保証するものではありません。INCONCLUSIVEをPASSとして扱うこともありません。

03 / 使い方

サインアップしたら、すぐ発行できます

STEP 01
サインアップ

メールアドレスで登録すると、その場で組織用の環境が作られます。

STEP 02
プランを選ぶ

発行する証明書の量に合わせて選択します。あとから変更できます。

STEP 03
対象を認証して申請

対象ドメインをHTTPSチャレンジで認証し、変更前後の条件と判定基準を固定して申請します。

STEP 04
発行して引き渡す

観測と判定がPASSなら証明書が発行されます。公開URLかオフラインパッケージで相手に渡します。

PORTAL / API
発行する側

Portalの画面から、またはAPI・OAuth・MCP経由で申請・発行します。どの入口でも同じ認可と上限が適用され、APIキーや監査ログなどの管理機能も揃っています。

PUBLIC / OFFLINE
受け取る側

公開IDだけで、署名・鍵・時刻・透明性・失効状態をブラウザから検証できます。ネットワークが使えない環境向けに、オフラインパッケージでの検証にも対応します。

04 / 活用例

変更を「引き渡す」すべての場面へ

自社の記録のためではなく、相手に確からしさを渡すためのサービスです。

ネットワーク運用会社

顧客への作業完了報告を、検証可能な証明書で引き渡します。報告書の真正性をめぐるやり取りがなくなります。

SIer・パートナー

自社発行に加え、配下の顧客の招待・発行件数・プラン・請求までをまとめて管理できます。

企業のIT部門

外部委託したネットワーク変更の完了を、委託先の報告ではなく独立した観測と固定ルールの判定で受け取れます。

監査・レビューの対応

変更管理の証跡として、いつ・何を・どの基準で確認したかを、第三者が検証できる形で提示できます。

05 / 安全性

信頼に足る証明書のための設計

証明書の信頼は、観測の範囲と判定の決め方で決まります。どちらも最初から明確に定めています。

許可された範囲だけを観測する

観測は、認証済みの対象に対して、署名済みジョブで許可された範囲でのみ行われます。範囲外への探索は行いません。

判定に裁量を挟まない

合否はバージョン固定のルールで決定論的に決まります。AIは説明の補助に限定され、判定には関与しません。

結果を丸めない

PASS/FAIL/INCONCLUSIVEを区別して返します。判定できないものを合格として扱うことはありません。

どの入口でも同じ統制

Portal・API・OAuth・MCPのすべてで同じ認可と上限が適用されます。二要素認証、APIキー管理、監査ログを備えています。

06 / よくある質問

よくある質問

受け取った証明書の検証に、NCCへの登録は必要ですか

不要です。公開URLをブラウザで開くだけで、署名・鍵・時刻・透明性・失効状態を検証できます。オフラインパッケージでの検証にも対応します。

使い始めるまでに何が必要ですか

メールアドレスでのサインアップと、プランの選択だけです。営業とのやり取りや事前審査はありません。

合否の判定にAIは使われますか

判定には使われません。合否は事前に固定したルールによる決定論的な評価で決まり、同じ入力からは同じ結果になります。AIは結果の説明を補助するだけです。

証明書があれば、変更内容が正しかったと言えますか

言えません。示せるのは、承認された対象・条件で観測し、固定ルールで評価し、改ざんを検知できる形で発行したことです。変更内容の妥当性や将来の可用性は別の問題です。

判定がINCONCLUSIVEになった場合はどうなりますか

証明書は発行されません。INCONCLUSIVEはPASSともFAILとも区別して扱われ、合格として丸められることはありません。条件を見直して再申請できます。

次のネットワーク変更から、証明書で引き渡す。