NIST耐量子暗号指針：鍵確立と署名の移行を逆算する

01

最終化されたのは、移行の道筋

暗号方式の標準があっても、その機能が業務の完了へつながるまでには、製品と相手の準備がある。NISTの最終移行指針を読む際にも、何を、どの順序で置き換えるかが企業の問いになる。鍵確立と署名を一つの完了日にまとめると、先にできた機能が、まだ使えない工程を隠してしまう。見積を読む単位を二本の目的へ分けると、短縮料金の意味や、取引先を待つ時間も説明しやすい。

対象となる連邦システムには、既に別の政策上の時計がある。2026年6月22日の大統領令14412は、国家安全保障システムを除く高価値資産と高影響システムについて、鍵確立を2030年12月31日、デジタル署名を2031年12月31日までに移行するための指針を求めた。この二つの期限が10月27日に初めて生まれたわけではない。また、同じ日付を世界のすべての民間企業へ一律に課す規定でもない。[C3]

読者に残る仕事は、自分が使う一つの業務を、その二つの目的へ分けて工程表を作ることだ。取引データを送る経路が更新できても、取引先が署名を受け入れる準備は別に残り得る。逆に、証明書を発行できても、通信の鍵を作る機能まで替わったとは限らない。本文の例では、その違いを必要月数と開始時期へ移す。表を読むだけでなく、自分の資料のどの欄を埋めれば比較が進むかが分かる。

ここで使えるのは、無料で閲覧できる静的な工程図、計算例、確認表だ。実際の構成情報、相手の対応予定、試験に必要な期間は、利用者が手元で用意する。ページへ機器情報や秘密鍵を入力する必要はなく、接続の探索、設定変更、適合性の自動判定も行わない。紙や表計算へ例を写し、自分の工程と並べる使い方を想定する。最終的な適用範囲と受入れ条件は、所管者や契約上の相手と確かめる。

02

同じ業務でも、守る仕事は二本に分かれる

鍵確立は、通信する当事者が共通の秘密鍵を得るための仕組みだ。NISTのFIPS 203は、そのためのML-KEMを定める。得られた鍵は、通信内容を守る共通鍵暗号などと組み合わせて使われる。一方、FIPS 204のML-DSAは署名の生成と検証を扱う。署名はデータの改変や署名者の確認に関わる。名前が似ている製品機能でも、どちらの役割を提供するのかによって必要な相手と試験は変わる。[C4][C6]

架空の業務として、部品メーカーが取引先へ設計変更を送り、承認済みの更新ファイルを工場装置へ配る流れを考える。設計変更を運ぶ通信では、情報を読める相手と鍵を共有する準備が要る。更新ファイルでは、受け取る装置が正しい署名を検証できなければ配布を終えられない。送り手の準備が同じ日に整っても、二つの仕事が同じ日に完成するとは限らない。業務名を一行にまとめた台帳では、この差が埋もれやすい。

工程を分ける際は、製品名よりも、渡すものと受け取るものを先に書くとよい。通信側なら、相手と同じ条件で鍵を得られたという試験記録が次の工程への入力になる。署名側なら、どの装置と検証器が、どの形式のファイルを受け入れたかが入力になる。同じベンダーの製品を買ったという共通点は、これらの受渡しを省略する理由にならない。担当者同士が合意する成果物が明確なら、待ち時間の所在も追いやすい。

この分け方は、同じ基盤への依存を消すものではない。二本とも同じ暗号ライブラリ、調達窓口、試験担当へ戻るなら、そこには共有する制約がある。最初は目的別に分け、次に共通の資源を線で結ぶ。そうすると、二つの予算を別々に承認したために、同じ試験枠を二度使えると思い込む誤りを防げる。費用の所属と、実際に作業できる人や設備の所属をそろえることが、工程表を事業計画へつなぐ。

役割の基礎は、通信権限と暗号の役割を照合する。

03

所要期間を置く前に、例の境界を決める

以下の数値は、SG Groupが作成した架空の工程である。特定の製品の納期、連邦機関の計画、実際の企業の費用や実装を表さない。開始からの経過月を用い、月の途中の日数は計算しない。各工程の所要期間は、その工程を始めるための条件が満たされた時から数える。まず必要な人員と試験枠が別々に確保されている条件を置き、後で一つの試験班を共有する場合へ変える。

並行して進められる準備は、終わるのが遅い方を待つ。例えば六か月と九か月の準備を同時に始め、その両方が必要なら、次の工程を始められるのは九か月後だ。十五か月にはならない。一方、前の試験を終えないと次へ進めない工程は、必要月数を順番に足す。並行と直列の違いを先に決めるだけで、予算書の各行に書かれた期間を、全部足したり、一番長い一行だけ選んだりする誤りを避けられる。

ただし、矢印を引くだけで作業を同時に実行できるわけではない。二つの作業が同じ担当者を必要とするなら、人員を増やすか、順番を決める必要がある。外部の相手が同じ試験期間しか提供しない場合も、社内だけでは並行化できない。工程表には、成果物の依存と資源の競合を分けて残したい。前者は前提がそろうまで始められない関係であり、後者は前提がそろっていても順番を待つ関係だ。

もう一つの境界は、完了の定義である。例では、対象となる業務経路へ展開し、合意した受入れを終えるまでを数える。製品の出荷、契約締結、暗号機能の搭載を、それぞれ完成日へ置き換えない。試験で想定外の問題が出た場合は、再作業の工程を追加して計算し直す。工程を後から増やすことは計画の失敗を隠すためではなく、何が前提から外れたのかを説明するために必要になる。

04

鍵確立の例：九か月の準備が全体を支配する

鍵確立の準備を二本に分ける。アプリケーションで使うライブラリの準備を六か月、相手と接続するゲートウェイの準備を九か月とする。この二本を同時に始め、両方の完了後に四か月の組込み、三か月の相互接続試験、二か月の段階展開を行う。図3の横軸は開始後の月数だ。準備の二本が重なり、その後の三工程がつながる様子を、自分の案件の順序と比べられる。

全体の所要期間は、max（6、9）＋4＋3＋2＝18か月になる。maxは大きい方を選ぶ計算である。ライブラリが終わる六か月目から九か月目までは、次へ進む条件がまだそろわない。ただし、その三か月を無駄と決めつける必要はない。文書の整備や別の試験準備へ使えるなら、そこで行う仕事を明記できる。組込みの開始を早められる場合には、例とは違う依存関係として描き直す。

ライブラリの準備を六か月から三か月へ縮めても、ゲートウェイが九か月のままなら全体は18か月だ。見積上で三か月短縮した項目があっても、業務の開始日は変わらない。一方、ライブラリが十二か月へ延びると、今度はその枝が遅い方になり、全体は21か月へ伸びる。短縮の価値と遅延の損失は、同じ項目でも対称にはならない。現在どの枝が次の仕事を待たせているかで判断が変わる。

調達側が短縮料金を検討するなら、その料金で何の完成日が動くかを問える。三か月早いライブラリに支払う価値は、今回の完成日以外に、試験の余裕や他業務への転用があるかもしれない。だが、それを今回の三か月早い展開として計上すると、便益を取り違える。契約では、準備完了の成果物と、それを受け取る工程を対応させる。納品日を守ったという報告が、業務開始の前倒しを意味するかを検算できるようになる。

05

署名の例：作る側と確かめる側をつなぐ

署名側では、検証する機器の準備を十二か月、証明書を発行・運用する基盤の準備を八か月と置く。両方を待ち、アプリケーションの改修を五か月、取引先を含む受入れ試験を四か月、対象機器への展開を六か月とする。最後の六か月は対象群へ順番に展開するための期間であり、装置の耐用年数や情報を秘密に保つ期間とは別の入力だ。

全体はmax（12、8）＋5＋4＋6＝27か月となる。鍵確立の18か月より九か月長いが、その差から暗号方式の優劣は決まらない。例で置いた受渡しと対象機器の条件が違うためである。署名を作る機能だけが早く完成しても、検証する装置や取引先が受け入れられなければ、配布する業務は終わらない。送り手の製品資料と受け手の試験記録を、同じ工程の入口と出口として照合する必要がある。

この例で証明書基盤の八か月を六か月へ短縮しても、十二か月かかる検証機器が残るため、完成は27か月のままだ。反対に、基盤の準備が十四か月になれば、全体は29か月へ延びる。工程の支配的な枝は、プロジェクトの途中で入れ替わる。最初に作った遅延対策を固定したままにせず、前提が変わった時に次の工程の開始日を計算し直すことが、追加予算の使い道を考える助けになる。

長く使う装置では、更新ファイルを確認する機能を後から変更できるかが、購入時点の問いになる。最終報告はコード署名の用途を取り上げ、製造後に検証コードを更新しにくい場合を指摘する。自社の対象で同じ制約があるなら、ソフトウェア更新の注文だけでは工程を埋められない。装置の交換、別の検証経路、業務から外す手順のどれが可能かを、供給者の正式な説明と実機の条件に沿って検討する。[C2]

長く使う機器の変更条件は、制御装置の設定・保守・更新条件を確認する。

06

二つの期限から、着手する月を逆算する

工程の月数を日付へ移す際は、完了を数える境界を決める。ここでは2030年末までの完了を2031年1月1日の直前、2031年末までの完了を2032年1月1日の直前とする。月単位の例なので、その境界から必要月数を引く。鍵確立の18か月を前者から引くと2029年7月1日、署名の27か月を後者から引くと2029年10月1日が、余裕を置かない着手日の境界になる。前日までに各工程を完了する条件だ。月数は月初から次の月初までの区間長として数え、右端の日付そのものを稼働日へ含めない。2029年7月1日から18か月を確保する例では、2030年12月の末までを使う。

署名の方が九か月長くかかるのに、この例の着手境界は三か月遅い。署名には十二か月後の期限を当てているためだ。この差は、署名の準備を遅らせてよいという一般的な助言ではない。自分の業務で署名側がさらに六か月長くかかるなら、関係は逆転する。期限の早い項目だけを順番に並べる方法も、必要月数が長い項目だけを優先する方法も、この二つの入力を同時には反映していない。

各経路へ三か月の予備期間を追加すると、計画に確保する長さは鍵確立21か月、署名30か月になる。着手境界はそれぞれ2029年4月1日、2029年7月1日へ動く。三か月は説明のための仮定で、NISTの推奨値や安全の保証ではない。予備期間を審査待ち、障害対応、再試験のどれに使うかまで書けば、単に全項目へ一定割合を上乗せする場合より、どの変化で余裕を使うかを説明できる。

この表を民間の案件へ移す場合は、まず日付の欄を自分の契約や実施計画に替える。連邦向けの納入があるというだけで、大統領令の対象資産や契約条項まで同一だとは決められない。調達要件の発効、製品の提供、利用者の受入れを一つの日付にまとめず、それぞれの資料と責任者を付ける。日単位の作業日、休業、変更禁止期間が重要な案件では、月単位の結果をそのまま確定日として使わず、実際の暦へ展開する。

07

試験班が一つなら、並行工程に待ち行列ができる

次に、鍵確立のゲートウェイ準備だけが九か月から十三か月へ延びた場合を考える。組込みの四か月を終えると、鍵確立側は17か月目に試験へ進める。署名側も十二か月の準備と五か月の改修を終え、同じ17か月目に試験を始められる。試験班が別々なら、鍵確立は17＋3＋2＝22か月、署名は17＋4＋6＝27か月で終わる。遅延の影響を受けるのは鍵確立側だけだ。

同じ試験班が一方ずつ担当し、署名を先にするなら、17か月目から21か月目まで署名を試験する。その後に鍵確立の三か月を実施し、24か月目から二か月の展開へ進む。鍵確立の完成は26か月目だ。追加の四か月は新しい暗号の処理速度が遅いためではなく、試験枠を待つために生まれる。工程の依存だけを見る図と、実際の資源を割り当てた計画の違いが表れる。

鍵確立を先にする順序なら、試験は17から20か月目、展開を経た完成は22か月目になる。署名の試験は20から24か月目へずれ、六か月の展開を終えるのは30か月目だ。どちらを先にしても、同じ試験班が七か月働く量は変わらないが、完成する時期の組合せは変わる。担当部署ごとに自分の案件を最優先と申告するだけでは解けず、二つの期限と、待つ間に残る業務上の負担を合わせて決める必要がある。

追加の試験班を買えば、この例では待ち行列を取り除ける。ただし、相手の試験環境や承認者が一つしかないなら、社内の人数だけを増やしても同じ結果にならない。二班が同じ設備の予約を取り合う場合や、試験のやり方が揃わず再試験が増える場合もある。外注費の比較では、削れる待ち時間、その後に残る六か月の展開、品質を揃える仕事を別に見積もる。追加支出が工程のどこを変えるかが分かって初めて、短縮の対価を評価できる。

08

TLS対応と、業務の受入れを別の証拠で確かめる

最終報告は、連邦機関のTLS 1.3対応日として2030年1月2日を示す。これは鍵確立や署名のPQC移行期限と同じ意味ではない。TLS 1.3の仕様自体も、通信の鍵交換と認証を別の機構として扱っている。製品がTLS 1.3を話せるという説明から、その通信が特定の耐量子方式を使い、相手との業務試験も完了したという結論へ飛ぶことはできない。[C2][C7]

工程の受入れでは、対応できる方式の一覧と、実際に選ばれた方式の記録を分ける。前者は製品の候補範囲を示し、後者はその試験で成立した組合せを示す。相手や経路が変われば、同じ製品でも結果が変わり得る。例の三か月の試験には、通常の相手だけでなく、重要な例外経路を含むという条件を置く。試験対象を減らして予定を守った場合は、同じ完成を早めたとは数えず、残った対象を工程表へ戻す。

署名では、作成できるという試験と、対象機器で検証できるという試験を組にする。正しいファイルだけでなく、合意した範囲で変更したファイルが拒まれるか、期限や失効の状態をどう処理するかも受入れの論点になる。具体的な実施は担当者が安全な試験環境で設計する仕事だ。ニュースの比較表が、そのまま本番機器へ送る試験手順になるわけではない。完了報告には、対象群と条件を読める成果物が必要になる。

NCCoEの移行プロジェクトには、暗号の利用箇所を調べる仕事と、相互接続性を試す仕事がある。この二つの役割を工程へ写すと、探索で対象が増えた時は試験量を、相互接続で問題が出た時は組込みや相手対応の期間を見直せる。発見した件数が多いだけで移行が進んだとはいえず、試験の成功が多いだけで未知の対象が消えるわけでもない。どの資料がどの工程の入力を変えたかを残すと、進捗の報告が具体的になる。[C5]

09

機密性の期間は、工程の期限と別に残る

暗号通信を集め、将来解読する脅威がある。一方、署名の検証には、将来も使う装置が正しい更新を受け入れられるかという別の時間が関わる。二本の工程の完成日を揃えるだけでは、この二つの露出期間は測れない。扱う記録と装置について、いつまで価値や利用が続くかを別の欄へ置く必要がある。[C1]

例えば2027年初めに作った設計情報を2034年末まで秘密にする架空条件を置く。通信経路の移行が2029年半ばに終わっても、それ以前に外部へ複製された古い通信まで遡って保護できたことにはならない。過去の複製の有無や将来の解読能力は、この工程表からは分からない。読者が比較できるのは、今後どの期間の新しい通信へ変更が適用されるかと、情報を秘密にしておきたい期限の重なりである。

この例で量子計算機の登場を特定の年に置き、安全な最終着手日を認定することはできない。到来時期が不確実なままでも、移行に18か月かかるという見積や、秘密にしておきたい情報の期限は調べられる。期間を短く見積もれば安心できるという話でもない。対象を減らしたために短くなったのか、実際の依存工程を短縮できたのかを確かめる。工程の改善と、危険が消えたという判断を同じ尺度にしない方がよい。

装置側では、使う期間を短くすれば交換対象を減らせる場合がある。しかし、生産設備を早く廃止すれば、製造能力や代替投資の条件も変わる。情報の保存期間を変える場合にも、記録の必要性や適用ルールが介在する。安全性のために業務上必要な原本を勝手に消す、という結論にはならない。機密情報の保護、装置の利用、記録の保存について、同じ年月が書かれていても何の期限かを対応させて検討する。

保管情報に残る問いは、保存原文と情報移転の境界を確認する。

10

支出は、完成日を動かす工程へ届くか

国際的な企業への伝達は、標準の発表から直ちに売上が増えるという一段の話ではない。機器や基盤の提供者は開発と検証の仕事を持ち、利用企業は調達と業務試験の負担を持つ。その間に契約、提供可能な版、相手側の対応がある。今回の指針は、その連なりを工程として見る理由を強める。世界の需要額や個別企業の利益を、対象システム数が分からないまま金額へ換算することはできない。

利用企業の調達では、既存契約の更新と、追加の移行作業を分けると費用の中身が見える。新しい版への権利が既に料金へ含まれていても、機器の交換や相手との試験は別に発注するかもしれない。反対に、機能を買い足す契約でも、統合や運用支援が含まれる場合がある。総額の安い順に並べる前に、例のどの工程が各見積に入っているかを埋める。重複する作業と、誰も引き受けていない受渡しを見つけられる。

供給者を比べる際にも、早い出荷と早い受入れは別の評価になる。部品の準備を早める企業、検証機器を供給する企業、相互接続の調整を担う企業では、短縮できる枝が違う。図3の六か月を短くする会社に価値がないわけではないが、九か月の枝を動かす会社と同じ完成日前倒しとして扱えない。受注や開発費から収益を考える人は、納品条件と顧客の受入れのどちらで対価が生じるかも資料で確かめたい。

費用を抑える反論として、共通サービスを利用して各社の開発を減らす選択がある。対象が共通化でき、サービス提供者と利用者の責任が合意できれば、準備を共有する利点は大きい。一方、複数社が同じ試験枠や同じ更新時期を待つなら、混雑は共通の制約になる。海外拠点を含む企業では、各地域の相手、契約、保守時間が同じかも調べる。共通化の便益と集中による待ち時間を、同じ工程表へ戻して比較する。

11

SG Groupの見方：短縮できる枝と、評価を変える証拠

SG Groupは、今回の最終指針を、暗号製品の購入額だけで評価するより、業務の完成日を動かす依存関係から読む方が有用だと考える。例では、並行する短い枝をさらに短縮しても完成は早まらず、支配的な枝の遅延や試験班の待ち時間が全体を変える。遅い方の準備が変わらなければ完成日は動かず、支配的な枝が替われば優先する仕事も替わる。予算の消化率や対応機能の数だけでは、この違いを説明できない。

この見方への有力な反論は、現場では準備と組込みを一部重ねられるというものだ。仮にゲートウェイの完成前に安全な検証環境で組込みの一部を進められるなら、図3の完全な直列は厳し過ぎる。そこで短くできる作業と、完成品を待つ作業を分割し、依存の線を引き直す必要がある。単に全体を短く見積もるのではなく、何を先に始められるようになったかという証拠が、18か月という計算を変える。

逆方向の反証は、見落としていた相手や機器が試験対象へ加わる場合だ。外部の認証基盤や保守用の接続が後から見つかれば、元の四か月や三か月の前提では終わらないかもしれない。そのときは、発見件数の増加を機械的に遅延月数へ換算せず、新たに必要な成果物と、その作業を始められる時点を調べる。数十の対象を同じ試験で扱える場合と、一つの特殊機器が長い交換を要する場合では結果が違う。

もう一つの評価変更条件は、共通サービスが依存をまとめて引き受ける場合である。提供者が複数の工程を実際に完了し、利用者の受入れまで含むなら、自社側の工程図は短くなり得る。ただし、短い契約説明だけで省略を認めず、どの対象と版で受入れが成立したかを見る。自社開発が少ないことと、供給者の待ち時間が短いことは別だ。誰が作業をするかが変わった際も、完成までのつながりを追い直せる表にしたい。

12

自分の一業務を、八欄の確認表へ移す

実際の比較を始めるなら、会社全体の機器を一度に並べる前に、一つの業務と完了条件を選ぶ。図7の最初の欄へ、送り手、受け手、通る基盤、対象となる版や機器群を書く。次に鍵確立と署名を二行へ分け、それぞれの成果物を置く。製品を複数の部署で使っていても、同じ名前だから同じ行へ統合するとは限らない。用途と受入れの相手が違うなら、工程の終点も別に残す。

依存する工程の欄には、前の工程番号と、必要な成果物を書く。所要期間だけを並べても、六か月と九か月を足すのか、大きい方を選ぶのかが分からないためだ。次に、使う人員、設備、相手側の試験枠を対応させ、同じ期間に重ねられるかを確かめる。対象の担当者が未定なら、人が無限に使える条件を暗黙に置かず、資源の欄を未定のままにして、計算の暫定性を残す。

期限の欄には、日付だけでなく、その日付を決める文書と対象を書く。最後の欄では、工程を完了とする証拠と、やり直す条件を対にする。例えば、対象版での相互接続結果を受け入れるのか、機器群への配布完了まで求めるのかで、同じ試験終了という報告の意味が変わる。見積、相手の通知、試験報告に別々の日付がある場合も、どれが次の工程を始める条件になるかを対応させる。

必要な入力がそろったら、先に経過月の図を作り、後から暦へ移すと検算しやすい。並行準備の最大値、直列部分の合計、共有資源による待ちを一回ずつ入れる。未確定の期間があるなら、一つの確定値へ潰さず、短い場合と長い場合を別の行で比べる。ただし、幅のある見積を確率分布や成功率へ変換する根拠はない。自分の比較に必要なのは、どの入力が変わると着手境界が動くかを見つけることだ。

13

切替の失敗を、残る作業と業務継続へつなぐ

段階展開の二か月や六か月には、対象へ設定を配る時間だけを入れるのか、問題が出た群を戻して再試験する時間まで入れるのかで意味が変わる。例の基準計算は、再作業なしで受入れを終える条件だ。失敗した時の手順を考える際には、どの成果物を使えなくなったと判定し、前のどの工程まで戻るかを指定する。全体を初日へ戻す場合と、一つの相手の試験だけをやり直す場合では、必要な余裕が大きく違う。

例えば、鍵確立の基準工程の18か月目の完了判定で、追加の三か月の相互接続試験が必要になる条件を置く。他の作業を戻さず、専用の試験枠をすぐ使えるなら、全体は21か月となる。三か月の予備期間はちょうど消える。しかし、別の案件がその枠を使っているなら、三か月だけを足す計算では足りない。失敗した内容と、やり直しを始められる時点の両方を、次の見積に反映させる必要がある。

業務を続けるための代替経路は、使える条件と承認者を事前に決める。古い保護方式へ戻せるというだけでは、情報の機密性や対象システムの要件を満たすとは限らない。一方、代替を一切認めないなら、止める業務、連絡する相手、再開に要る証拠を計画へ入れる。どちらの選択も、ニュースの一般例から自動的には決まらない。例外を承認する責任と、その期間に残る負担を、完成日の短縮と別に記録する。

原本や承認記録を保つ仕事も、戻し作業と同時に考えたい。試験結果を上書きして最新版だけを残すと、どの対象で問題が起きたのか、なぜ元の完成日を変えたのかが追いにくくなる。新旧の構成と受入れ記録を対応させれば、再試験の範囲を狭く説明できる場合がある。記録の保存は単なる管理コストではなく、工程を全部やり直す必要があるかを判断するための材料になる。保存場所やアクセス権も実際の機密性に合わせて設計する。

代替の業務と受渡しは、停止時の代替手順と業務の受渡しを読む。

14

次の資料では、どの工程が動いたかを見る

次に読む資料は、自分の工程で未定になっている欄から選べる。技術仕様なら使える機能と版、提供者の予定なら成果物と納期、取引先の通知なら試験窓と受入れ条件を照合する。政策文書では、対象と目的、日付をそろえる。最終報告の公表だけで、個々の製品や業務が既に移行したとはいえない。反対に、既に準備が進む対象では、新たな計画をゼロから作り直さず、今回の文書で変わった条件だけを差し替えられる。

NIST IR 8547は、用途別の詳しい指針を今後更新していく方針も示している。個別の更新日をここで予測する必要はない。所管する基準や製品の版が変わった時に、自分の二本の工程のどこへ影響するかを見ればよい。対応機能の追加なら準備の枝、形式の変更なら組込みと相手の試験、対象範囲の変更なら展開と受入れの群が動く。この対応があれば、文書の更新を見つけただけで全計画が進んだと誤解しにくい。[C2]

世界の供給者と利用企業の間では、同じ標準名を使っていても、受入れに至る工程が揃うかが商取引の条件になる。相手へ最初に尋ねる質問は、会社全体が対応済みかという二択より、対象業務のどの成果物をいつ渡し、誰が受け入れるかの方が答えやすい。遅延が見えた際も、値下げや追加費用の要求だけに進まず、短縮できる枝と共有資源を確かめる。工程が動く根拠を持てれば、調達と開発の話合いを同じ完成条件へ戻せる。

要約で指針の結論を知った人も、本文の図3・図4へ自分の月数を写し、図5の期限を自分の対象文書の日付へ置き換える作業が残る。二つを合わせれば、早い期限と長い工程のどちらが着手を決めるかを確かめられる。図7では、その結果を変える未定の相手、資源、受入れ証拠を選べる。必要なのは安全だという一つの印ではなく、次の資料で書き換える入力と、その入力が動かす工程を自分の条件で見つけることだ。