diff --git a/ja/proc-ietf.md b/ja/proc-ietf.md
index 79d7a8ee..909d7afe 100644
--- a/ja/proc-ietf.md
+++ b/ja/proc-ietf.md
@@ -6,7 +6,7 @@ IETF によってプロトコルの標準化が始まり、QUIC ワーキング
 
 HTTP 以外のプロトコルにも適用したいという要求を満たすため、IETF QUIC プロトコルのアーキテクチャは2つの異なるレイヤーに分割されました。"transport QUIC" レイヤーと "HTTP over QUIC" レイヤーです (後者は2018年11月に HTTP/3 に名前を変更しました)。
 
-このレイヤー分割は、一見無害のようにも見えますが、IETF-QUIC と Google-QUIC で大きな差分を生み出しました。
+このレイヤー分割は、一見些細に思えますが、その結果、IETF-QUIC は元の Google-QUIC とは大きく異なるものになりました。
 
 ワーキンググループは QUIC の最初のバージョンを予定通りに提供するために、HTTP に範囲を絞り、HTTP で無いものは後に回すことにしました。
 
diff --git a/ja/proc-status.md b/ja/proc-status.md
index b2484459..77884a07 100644
--- a/ja/proc-status.md
+++ b/ja/proc-status.md
@@ -28,7 +28,7 @@ curl は最初の実験的な HTTP/3 サポート (draft-22) を2019年9月11日
 
 QUIC は TLS 1.3 を暗号化とセキュリティのために採用することにしました。これは車輪の再発明を避け、信頼できる既存のプロトコルを利用するためです。しかしながら、これと並行して、QUIC での TLS の利用を本当に効率化することにしました。QUIC では "TLS messages" のみを利用し "TLS records" は利用しないことにしました。
 
-これは無害な変更に聞こえますが、この決定は QUIC を実装している人たちにとってとても高いハードルとなりました。既存の TLS 1.3 をサポートしているライブラリにはこれらの機能にアクセスする API が不足しており、QUIC ではアクセスできないのです。一方で多くの QUIC の実装者は大きな組織に所属しており、それぞれがもっている TLS スタックを別々に使用しているため、全員にとって問題とはなっていません。
+これは一見些細な変更に思えますが、実際には多くの QUIC スタックの実装者にとって大きな障害となりました。既存の TLS 1.3 をサポートしているライブラリにはこれらの機能にアクセスする API が不足しており、QUIC ではアクセスできないのです。一方で多くの QUIC の実装者は大きな組織に所属しており、それぞれがもっている TLS スタックを別々に使用しているため、全員にとって問題とはなっていません。
 
 2018年11月現在、例えば広く使われているオープンソースの OpenSSL では、これらの必要な API は全くなく、また近々で追加するような要望も上がっていません。